From xen-devel-bounces@lists.xen.org Fri Jun 01 00:12:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 00: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 1SaFTQ-0007u9-Uj; Fri, 01 Jun 2012 00:12:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1SaFTP-0007ty-MU
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 00:12:11 +0000
Received: from [193.109.254.147:16766] by server-11.bemta-14.messagelabs.com
	id A6/AF-01965-AD808CF4; Fri, 01 Jun 2012 00:12:10 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338509530!4567431!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21791 invoked from network); 1 Jun 2012 00:12:10 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-7.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 00:12:10 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 4036D1F880B1
	for <xen-devel@lists.xen.org>; Thu, 31 May 2012 20:14:46 -0400 (EDT)
Received: (qmail 8502 invoked by uid 108); 31 May 2012 20:12:09 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.189.210.134)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 31 May 2012 20:12:09 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 976FD812007; Thu, 31 May 2012 19:12:08 -0500 (CDT)
Date: Thu, 31 May 2012 19:12:08 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Dario Faggioli <raistlin@linux.it>
Message-ID: <20120601001208.GA2123@imp.flyn.org>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<1338508475.9414.18.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338508475.9414.18.camel@Abyss>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> tools, blockers:
>> 
>> ...
>> 
>> * xl compatibility with xm:
>> 
>>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
>>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
>> 
>>         * does not automatically try to select a (set of) node(s) on
>>           which to create a VM and pin its vcpus there. (Dario
>>           Faggioli, patches posted)

I also noted another discrepancy (and provided a patch) between xm and
xl in:

	http://lists.xen.org/archives/html/xen-devel/2012-05/msg02285.html

-- 
Mike

:wq

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 00:12:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 00: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 1SaFTQ-0007u9-Uj; Fri, 01 Jun 2012 00:12:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1SaFTP-0007ty-MU
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 00:12:11 +0000
Received: from [193.109.254.147:16766] by server-11.bemta-14.messagelabs.com
	id A6/AF-01965-AD808CF4; Fri, 01 Jun 2012 00:12:10 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338509530!4567431!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21791 invoked from network); 1 Jun 2012 00:12:10 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-7.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 00:12:10 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 4036D1F880B1
	for <xen-devel@lists.xen.org>; Thu, 31 May 2012 20:14:46 -0400 (EDT)
Received: (qmail 8502 invoked by uid 108); 31 May 2012 20:12:09 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.189.210.134)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 31 May 2012 20:12:09 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 976FD812007; Thu, 31 May 2012 19:12:08 -0500 (CDT)
Date: Thu, 31 May 2012 19:12:08 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Dario Faggioli <raistlin@linux.it>
Message-ID: <20120601001208.GA2123@imp.flyn.org>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<1338508475.9414.18.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338508475.9414.18.camel@Abyss>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> tools, blockers:
>> 
>> ...
>> 
>> * xl compatibility with xm:
>> 
>>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
>>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
>> 
>>         * does not automatically try to select a (set of) node(s) on
>>           which to create a VM and pin its vcpus there. (Dario
>>           Faggioli, patches posted)

I also noted another discrepancy (and provided a patch) between xm and
xl in:

	http://lists.xen.org/archives/html/xen-devel/2012-05/msg02285.html

-- 
Mike

:wq

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 00:47:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 00:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaG1X-0008Pg-SY; Fri, 01 Jun 2012 00:47:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SaG1U-0008Pb-TQ
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 00:47:26 +0000
Received: from [85.158.143.35:31905] by server-3.bemta-4.messagelabs.com id
	1F/3C-04252-C1118CF4; Fri, 01 Jun 2012 00:47:24 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338511642!18341712!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjkwMTU4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1172 invoked from network); 1 Jun 2012 00:47:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 00:47:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 May 2012 17:46:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="150188047"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 31 May 2012 17:46:21 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 31 May 2012 17:46:20 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.94]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 08:46:18 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Thread-Topic: [PATCH v2 0/4] XEN: fix vmx exception mistake
Thread-Index: AQHNPlCm0ErPzgLEKE+cn2xIVxGOfpbiLOlAgAAT4h+AAOO1AIAA4P2AgACdrLA=
Date: Fri, 1 Jun 2012 00:46:17 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDCC2A5@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FDCB4CB@SHSMSX102.ccr.corp.intel.com>
	<CBEBCF4D.41899%keir@xen.org>
	<403610A45A2B5242BD291EDAE8B37D300FDCBB4F@SHSMSX102.ccr.corp.intel.com>
	<CAB10MZA=TanSaMzhD4+qBoHkdXFfArTa6b8LQD+i86+eEYPhbA@mail.gmail.com>
In-Reply-To: <CAB10MZA=TanSaMzhD4+qBoHkdXFfArTa6b8LQD+i86+eEYPhbA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] XEN: fix vmx exception mistake
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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: Aravindh Puthiyaparambil [mailto:aravindh@virtuata.com]
> Sent: Friday, June 01, 2012 7:22 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Dong, Eddie; Ian Jackson; Keir Fraser;
> JBeulich@suse.com; Zhang, Xiantao
> Subject: Re: [PATCH v2 0/4] XEN: fix vmx exception mistake
> =

> On Wed, May 30, 2012 at 7:00 PM, Hao, Xudong <xudong.hao@intel.com>
> wrote:
> > Hi, Aravindh
> >
> > This series patches has be checked in xen unstable tree
> Cset#25424~25429(except for #25426), can you test by your case?
> =

> I ran my tests (injecting software interrupts and hardware exceptions)
> and they all passed.
> =


That's good, thanks for testing.


> Thanks,
> Aravindh
> =

> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> >> Sent: Wednesday, May 30, 2012 8:21 PM
> >> To: Hao, Xudong; JBeulich@suse.com
> >> Cc: xen-devel@lists.xen.org; Dong, Eddie; Aravindh Puthiyaparambil; Ian
> >> Jackson
> >> Subject: Re: [PATCH v2 0/4] XEN: fix vmx exception mistake
> >>
> >> On 30/05/2012 12:16, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> >>
> >> >> -----Original Message-----
> >> >> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fra=
ser
> >> >> Sent: Wednesday, May 30, 2012 6:40 PM
> >> >> To: Hao, Xudong; JBeulich@suse.com
> >> >> Cc: xen-devel@lists.xen.org; Dong, Eddie; Aravindh Puthiyaparambil;=
 Ian
> >> >> Jackson
> >> >> Subject: Re: [PATCH v2 0/4] XEN: fix vmx exception mistake
> >> >>
> >> >> On 30/05/2012 03:35, "Xudong Hao" <xudong.hao@intel.com> wrote:
> >> >>
> >> >>> Changes from v1:
> >> >>> - Define new struct hvm_trap to represent information of trap, inc=
lude
> >> >>> =A0 instruction length.
> >> >>> - Renames hvm_inject_exception to hvm_inject_trap. Then define a
> couple
> >> of
> >> >>> =A0 wrappers around that function for existing callers, so that th=
eir
> >> >>> parameter
> >> >>> =A0 lists actually *shrink*.
> >> >>
> >> >> I checked in the series, except for the bit that infers trap type f=
rom
> >> >> within vmx_inject_trap(). Instead I plumbed through a trap-type fie=
ld to
> >> >> dom0 toolstack, so the type can be specified by the caller.
> >> >>
> >> >
> >> > Thanks, that's more clean.
> >> >
> >> > The INT3 trap type should be HVMOP_TRAP_sw_exc in
> >> > tools/tests/xen-access/xen-access.c.
> >>
> >> Thanks I'll fix it and renam einslen -> insn_len as Jan suggested.
> >>
> >> =A0-- Keir
> >>
> >>
> >

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 00:47:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 00:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaG1X-0008Pg-SY; Fri, 01 Jun 2012 00:47:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SaG1U-0008Pb-TQ
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 00:47:26 +0000
Received: from [85.158.143.35:31905] by server-3.bemta-4.messagelabs.com id
	1F/3C-04252-C1118CF4; Fri, 01 Jun 2012 00:47:24 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338511642!18341712!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjkwMTU4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1172 invoked from network); 1 Jun 2012 00:47:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 00:47:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 May 2012 17:46:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="150188047"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 31 May 2012 17:46:21 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 31 May 2012 17:46:20 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.94]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 08:46:18 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Aravindh Puthiyaparambil <aravindh@virtuata.com>
Thread-Topic: [PATCH v2 0/4] XEN: fix vmx exception mistake
Thread-Index: AQHNPlCm0ErPzgLEKE+cn2xIVxGOfpbiLOlAgAAT4h+AAOO1AIAA4P2AgACdrLA=
Date: Fri, 1 Jun 2012 00:46:17 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDCC2A5@SHSMSX102.ccr.corp.intel.com>
References: <403610A45A2B5242BD291EDAE8B37D300FDCB4CB@SHSMSX102.ccr.corp.intel.com>
	<CBEBCF4D.41899%keir@xen.org>
	<403610A45A2B5242BD291EDAE8B37D300FDCBB4F@SHSMSX102.ccr.corp.intel.com>
	<CAB10MZA=TanSaMzhD4+qBoHkdXFfArTa6b8LQD+i86+eEYPhbA@mail.gmail.com>
In-Reply-To: <CAB10MZA=TanSaMzhD4+qBoHkdXFfArTa6b8LQD+i86+eEYPhbA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] XEN: fix vmx exception mistake
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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: Aravindh Puthiyaparambil [mailto:aravindh@virtuata.com]
> Sent: Friday, June 01, 2012 7:22 AM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Dong, Eddie; Ian Jackson; Keir Fraser;
> JBeulich@suse.com; Zhang, Xiantao
> Subject: Re: [PATCH v2 0/4] XEN: fix vmx exception mistake
> =

> On Wed, May 30, 2012 at 7:00 PM, Hao, Xudong <xudong.hao@intel.com>
> wrote:
> > Hi, Aravindh
> >
> > This series patches has be checked in xen unstable tree
> Cset#25424~25429(except for #25426), can you test by your case?
> =

> I ran my tests (injecting software interrupts and hardware exceptions)
> and they all passed.
> =


That's good, thanks for testing.


> Thanks,
> Aravindh
> =

> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> >> Sent: Wednesday, May 30, 2012 8:21 PM
> >> To: Hao, Xudong; JBeulich@suse.com
> >> Cc: xen-devel@lists.xen.org; Dong, Eddie; Aravindh Puthiyaparambil; Ian
> >> Jackson
> >> Subject: Re: [PATCH v2 0/4] XEN: fix vmx exception mistake
> >>
> >> On 30/05/2012 12:16, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> >>
> >> >> -----Original Message-----
> >> >> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fra=
ser
> >> >> Sent: Wednesday, May 30, 2012 6:40 PM
> >> >> To: Hao, Xudong; JBeulich@suse.com
> >> >> Cc: xen-devel@lists.xen.org; Dong, Eddie; Aravindh Puthiyaparambil;=
 Ian
> >> >> Jackson
> >> >> Subject: Re: [PATCH v2 0/4] XEN: fix vmx exception mistake
> >> >>
> >> >> On 30/05/2012 03:35, "Xudong Hao" <xudong.hao@intel.com> wrote:
> >> >>
> >> >>> Changes from v1:
> >> >>> - Define new struct hvm_trap to represent information of trap, inc=
lude
> >> >>> =A0 instruction length.
> >> >>> - Renames hvm_inject_exception to hvm_inject_trap. Then define a
> couple
> >> of
> >> >>> =A0 wrappers around that function for existing callers, so that th=
eir
> >> >>> parameter
> >> >>> =A0 lists actually *shrink*.
> >> >>
> >> >> I checked in the series, except for the bit that infers trap type f=
rom
> >> >> within vmx_inject_trap(). Instead I plumbed through a trap-type fie=
ld to
> >> >> dom0 toolstack, so the type can be specified by the caller.
> >> >>
> >> >
> >> > Thanks, that's more clean.
> >> >
> >> > The INT3 trap type should be HVMOP_TRAP_sw_exc in
> >> > tools/tests/xen-access/xen-access.c.
> >>
> >> Thanks I'll fix it and renam einslen -> insn_len as Jan suggested.
> >>
> >> =A0-- Keir
> >>
> >>
> >

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 02:42:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 02:42: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 1SaHo5-0003TR-OR; Fri, 01 Jun 2012 02:41:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SaHo3-0003TM-Py
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 02:41:40 +0000
Received: from [85.158.143.35:40195] by server-2.bemta-4.messagelabs.com id
	54/FB-11595-3EB28CF4; Fri, 01 Jun 2012 02:41:39 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338518496!18350156!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjkwMTU4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6116 invoked from network); 1 Jun 2012 02:41:37 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 02:41:37 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 31 May 2012 19:41:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106551532"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 31 May 2012 19:41:34 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 31 May 2012 19:41:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 10:41:31 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v2 ]libxl: allow to allocate cpumap with specific size
Thread-Index: Ac0/oAzR1UcKVOHmRQuWrPpJjCzXCg==
Date: Fri, 1 Jun 2012 02:41:30 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E162559@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
	specific 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

Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_cpus. In some place, we may want to allocate specific size of cpumap.
This patch allow to pass a argument to specific the size that you want to allocate. If pass 0, it means the size is equal to number of max_cpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c       Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl.c       Fri Jun 01 09:27:17 2012 +0800
@@ -577,7 +577,7 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         ptr[i].poolid = info->cpupool_id;
         ptr[i].sched = info->sched_id;
         ptr[i].n_dom = info->n_dom;
-        if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap, 0)) {
             xc_cpupool_infofree(ctx->xch, info);
             break;
         }
@@ -3177,7 +3177,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
     }

     for (*nb_vcpu = 0; *nb_vcpu <= domaininfo.max_vcpu_id; ++*nb_vcpu, ++ptr) {
-        if (libxl_cpumap_alloc(ctx, &ptr->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &ptr->cpumap, 0)) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpumap");
             return NULL;
         }
@@ -3854,8 +3854,8 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     if ((info->cpupool_id != poolid) || (info->n_dom))
         goto out;

-    rc = ERROR_NOMEM;
-    if (libxl_cpumap_alloc(ctx, &cpumap))
+    rc = libxl_cpumap_alloc(ctx, &cpumap, 0);
+    if (rc)
         goto out;

     memcpy(cpumap.map, info->cpumap, cpumap.size);
diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
@@ -150,8 +150,8 @@ int libxl__domain_build_info_setdefault(
         b_info->cur_vcpus = 1;

     if (!b_info->cpumap.size) {
-        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
-            return ERROR_NOMEM;
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
+            return ERROR_FAIL;
         libxl_cpumap_set_any(&b_info->cpumap);
     }

diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
@@ -490,19 +490,19 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus)
 {
-    int max_cpus;
     int sz;

-    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus < 0)
+        return ERROR_INVAL;
+    if (max_cpus == 0)
+        max_cpus = libxl_get_max_cpus(ctx);
     if (max_cpus == 0)
         return ERROR_FAIL;

     sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
-        return ERROR_NOMEM;
+    cpumap->map = libxl__calloc(NULL, sizeof(*cpumap->map), sz);
     cpumap->size = sz;
     return 0;
 }
diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
@@ -63,7 +63,7 @@ int libxl_devid_to_device_nic(libxl_ctx
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus);
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
@@ -503,7 +503,7 @@ static int vcpupin_parse(char *cpu, libx
         return 0;
     }

-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap, 0)) {
         fprintf(stderr, "Error: Failed to allocate cpumap.\n");
         return ENOMEM;
     }
@@ -659,7 +659,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -695,7 +695,7 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -1782,7 +1782,9 @@ start:
     if (vcpu_to_pcpu) {
         libxl_cpumap vcpu_cpumap;

-        libxl_cpumap_alloc(ctx, &vcpu_cpumap);
+        ret = libxl_cpumap_alloc(ctx, &vcpu_cpumap, 0);
+        if (ret)
+            goto error_out;
         for (i = 0; i < d_config.b_info.max_vcpus; i++) {

             if (vcpu_to_pcpu[i] != -1) {
@@ -4054,7 +4056,7 @@ static void vcpupin(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         goto vcpupin_out;
     }

@@ -4111,7 +4113,7 @@ static void vcpuset(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "libxl_cpumap_alloc failed\n");
         return;
     }
@@ -5970,7 +5972,7 @@ int main_cpupoolcreate(int argc, char **
         fprintf(stderr, "libxl_get_freecpus failed\n");
         goto out_cfg;
     }
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         goto out_cfg;
     }
@@ -6337,7 +6339,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 02:42:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 02:42: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 1SaHo5-0003TR-OR; Fri, 01 Jun 2012 02:41:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SaHo3-0003TM-Py
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 02:41:40 +0000
Received: from [85.158.143.35:40195] by server-2.bemta-4.messagelabs.com id
	54/FB-11595-3EB28CF4; Fri, 01 Jun 2012 02:41:39 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338518496!18350156!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjkwMTU4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6116 invoked from network); 1 Jun 2012 02:41:37 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 02:41:37 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 31 May 2012 19:41:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106551532"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 31 May 2012 19:41:34 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 31 May 2012 19:41:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 10:41:31 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v2 ]libxl: allow to allocate cpumap with specific size
Thread-Index: Ac0/oAzR1UcKVOHmRQuWrPpJjCzXCg==
Date: Fri, 1 Jun 2012 02:41:30 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E162559@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
	specific 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

Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_cpus. In some place, we may want to allocate specific size of cpumap.
This patch allow to pass a argument to specific the size that you want to allocate. If pass 0, it means the size is equal to number of max_cpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c       Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl.c       Fri Jun 01 09:27:17 2012 +0800
@@ -577,7 +577,7 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         ptr[i].poolid = info->cpupool_id;
         ptr[i].sched = info->sched_id;
         ptr[i].n_dom = info->n_dom;
-        if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap, 0)) {
             xc_cpupool_infofree(ctx->xch, info);
             break;
         }
@@ -3177,7 +3177,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
     }

     for (*nb_vcpu = 0; *nb_vcpu <= domaininfo.max_vcpu_id; ++*nb_vcpu, ++ptr) {
-        if (libxl_cpumap_alloc(ctx, &ptr->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &ptr->cpumap, 0)) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpumap");
             return NULL;
         }
@@ -3854,8 +3854,8 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     if ((info->cpupool_id != poolid) || (info->n_dom))
         goto out;

-    rc = ERROR_NOMEM;
-    if (libxl_cpumap_alloc(ctx, &cpumap))
+    rc = libxl_cpumap_alloc(ctx, &cpumap, 0);
+    if (rc)
         goto out;

     memcpy(cpumap.map, info->cpumap, cpumap.size);
diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
@@ -150,8 +150,8 @@ int libxl__domain_build_info_setdefault(
         b_info->cur_vcpus = 1;

     if (!b_info->cpumap.size) {
-        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
-            return ERROR_NOMEM;
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
+            return ERROR_FAIL;
         libxl_cpumap_set_any(&b_info->cpumap);
     }

diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
@@ -490,19 +490,19 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus)
 {
-    int max_cpus;
     int sz;

-    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus < 0)
+        return ERROR_INVAL;
+    if (max_cpus == 0)
+        max_cpus = libxl_get_max_cpus(ctx);
     if (max_cpus == 0)
         return ERROR_FAIL;

     sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
-        return ERROR_NOMEM;
+    cpumap->map = libxl__calloc(NULL, sizeof(*cpumap->map), sz);
     cpumap->size = sz;
     return 0;
 }
diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
@@ -63,7 +63,7 @@ int libxl_devid_to_device_nic(libxl_ctx
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus);
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
diff -r d7318231cfe3 -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
@@ -503,7 +503,7 @@ static int vcpupin_parse(char *cpu, libx
         return 0;
     }

-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap, 0)) {
         fprintf(stderr, "Error: Failed to allocate cpumap.\n");
         return ENOMEM;
     }
@@ -659,7 +659,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -695,7 +695,7 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -1782,7 +1782,9 @@ start:
     if (vcpu_to_pcpu) {
         libxl_cpumap vcpu_cpumap;

-        libxl_cpumap_alloc(ctx, &vcpu_cpumap);
+        ret = libxl_cpumap_alloc(ctx, &vcpu_cpumap, 0);
+        if (ret)
+            goto error_out;
         for (i = 0; i < d_config.b_info.max_vcpus; i++) {

             if (vcpu_to_pcpu[i] != -1) {
@@ -4054,7 +4056,7 @@ static void vcpupin(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         goto vcpupin_out;
     }

@@ -4111,7 +4113,7 @@ static void vcpuset(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "libxl_cpumap_alloc failed\n");
         return;
     }
@@ -5970,7 +5972,7 @@ int main_cpupoolcreate(int argc, char **
         fprintf(stderr, "libxl_get_freecpus failed\n");
         goto out_cfg;
     }
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         goto out_cfg;
     }
@@ -6337,7 +6339,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 02:49:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 02:49: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 1SaHuz-0003cG-LM; Fri, 01 Jun 2012 02:48:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SaHuy-0003cB-MY
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 02:48:49 +0000
Received: from [85.158.139.83:20683] by server-8.bemta-5.messagelabs.com id
	BB/6E-25689-F8D28CF4; Fri, 01 Jun 2012 02:48:47 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1338518921!24255471!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ0NDQy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32682 invoked from network); 1 Jun 2012 02:48:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	1 Jun 2012 02:48:42 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 31 May 2012 19:48:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106553609"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 31 May 2012 19:48:39 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 31 May 2012 19:48:38 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 10:48:36 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v3 ]libxl: allow to set more than 31 vcpus
Thread-Index: Ac0/oQmLbu06FE6qS2aPDp2Yn0HQxw==
Date: Fri, 1 Jun 2012 02:48:34 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E162576@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 from v2:
Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
According to Ian's comments, modified some codes to make the logic more reasonable.

In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r 3b0eed731020 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
@@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(

     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
-    if (!b_info->cur_vcpus)
-        b_info->cur_vcpus = 1;
+    if (!b_info->avail_vcpus.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
+            return ERROR_FAIL;
+        libxl_cpumap_set(&b_info->avail_vcpus, 0);
+    }

     if (!b_info->cpumap.size) {
         if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
diff -r 3b0eed731020 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
@@ -160,6 +160,8 @@ static char ** libxl__build_device_model
     }
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
+        int nr_set_cpus = 0;
+        char *s;

         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
@@ -200,11 +202,14 @@ static char ** libxl__build_device_model
                               libxl__sprintf(gc, "%d", b_info->max_vcpus),
                               NULL);
         }
-        if (b_info->cur_vcpus) {
-            flexarray_vappend(dm_args, "-vcpu_avail",
-                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
-                              NULL);
-        }
+
+        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
+        flexarray_vappend(dm_args, "-vcpu_avail",
+                libxl__sprintf(gc, "0x%s", s),
+                NULL);
+        free(s);
+
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
@@ -441,11 +446,14 @@ static char ** libxl__build_device_model
         }
         if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (b_info->cur_vcpus)
+            if (b_info->avail_vcpus.size) {
+                int nr_set_cpus = 0;
+                nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
                                                          b_info->max_vcpus,
-                                                         b_info->cur_vcpus));
-            else
+                                                         nr_set_cpus));
+            } else
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d",
                                                          b_info->max_vcpus));
         }
diff -r 3b0eed731020 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
@@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus, i))
                             ? "offline" : "online";
     }

@@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
-    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
+    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
     va_hvm->checksum -= sum;
diff -r 3b0eed731020 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl       Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_types.idl       Fri Jun 01 10:34:13 2012 +0800
@@ -235,7 +235,7 @@ libxl_sched_params = Struct("sched_param

 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
-    ("cur_vcpus",       integer),
+    ("avail_vcpus",     libxl_cpumap),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
diff -r 3b0eed731020 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
@@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
     cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
 }

+int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
+{
+    int i, nr_set_cpus = 0;
+    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))
+        nr_set_cpus++;
+
+    return nr_set_cpus;
+}
+
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
+{
+    int i = cpumap->size;
+    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
+    char *q = p;
+    while(--i >= 0) {
+        sprintf((char *)p, "%02x", cpumap->map[i]);
+        p += 2;
+    }
+    *p = '\0';
+    return q;
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff -r 3b0eed731020 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
@@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
     memset(cpumap->map, -1, cpumap->size);
diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
@@ -650,7 +650,14 @@ static void parse_config_data(const char

     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
-        b_info->cur_vcpus = (1 << l) - 1;
+
+        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+        libxl_cpumap_set_none(&b_info->avail_vcpus);
+        while (l-- > 0)
+            libxl_cpumap_set((&b_info->avail_vcpus), l);
     }

     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 02:49:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 02:49: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 1SaHuz-0003cG-LM; Fri, 01 Jun 2012 02:48:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SaHuy-0003cB-MY
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 02:48:49 +0000
Received: from [85.158.139.83:20683] by server-8.bemta-5.messagelabs.com id
	BB/6E-25689-F8D28CF4; Fri, 01 Jun 2012 02:48:47 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1338518921!24255471!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ0NDQy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32682 invoked from network); 1 Jun 2012 02:48:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	1 Jun 2012 02:48:42 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 31 May 2012 19:48:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106553609"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 31 May 2012 19:48:39 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 31 May 2012 19:48:38 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 10:48:36 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v3 ]libxl: allow to set more than 31 vcpus
Thread-Index: Ac0/oQmLbu06FE6qS2aPDp2Yn0HQxw==
Date: Fri, 1 Jun 2012 02:48:34 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E162576@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 from v2:
Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
According to Ian's comments, modified some codes to make the logic more reasonable.

In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r 3b0eed731020 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
@@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(

     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
-    if (!b_info->cur_vcpus)
-        b_info->cur_vcpus = 1;
+    if (!b_info->avail_vcpus.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
+            return ERROR_FAIL;
+        libxl_cpumap_set(&b_info->avail_vcpus, 0);
+    }

     if (!b_info->cpumap.size) {
         if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
diff -r 3b0eed731020 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
@@ -160,6 +160,8 @@ static char ** libxl__build_device_model
     }
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
+        int nr_set_cpus = 0;
+        char *s;

         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
@@ -200,11 +202,14 @@ static char ** libxl__build_device_model
                               libxl__sprintf(gc, "%d", b_info->max_vcpus),
                               NULL);
         }
-        if (b_info->cur_vcpus) {
-            flexarray_vappend(dm_args, "-vcpu_avail",
-                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
-                              NULL);
-        }
+
+        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
+        flexarray_vappend(dm_args, "-vcpu_avail",
+                libxl__sprintf(gc, "0x%s", s),
+                NULL);
+        free(s);
+
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
@@ -441,11 +446,14 @@ static char ** libxl__build_device_model
         }
         if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (b_info->cur_vcpus)
+            if (b_info->avail_vcpus.size) {
+                int nr_set_cpus = 0;
+                nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
                                                          b_info->max_vcpus,
-                                                         b_info->cur_vcpus));
-            else
+                                                         nr_set_cpus));
+            } else
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d",
                                                          b_info->max_vcpus));
         }
diff -r 3b0eed731020 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
@@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus, i))
                             ? "offline" : "online";
     }

@@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
-    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
+    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
     va_hvm->checksum -= sum;
diff -r 3b0eed731020 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl       Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_types.idl       Fri Jun 01 10:34:13 2012 +0800
@@ -235,7 +235,7 @@ libxl_sched_params = Struct("sched_param

 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
-    ("cur_vcpus",       integer),
+    ("avail_vcpus",     libxl_cpumap),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
diff -r 3b0eed731020 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
@@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
     cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
 }

+int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
+{
+    int i, nr_set_cpus = 0;
+    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))
+        nr_set_cpus++;
+
+    return nr_set_cpus;
+}
+
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
+{
+    int i = cpumap->size;
+    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
+    char *q = p;
+    while(--i >= 0) {
+        sprintf((char *)p, "%02x", cpumap->map[i]);
+        p += 2;
+    }
+    *p = '\0';
+    return q;
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff -r 3b0eed731020 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
@@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
     memset(cpumap->map, -1, cpumap->size);
diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
+++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
@@ -650,7 +650,14 @@ static void parse_config_data(const char

     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
-        b_info->cur_vcpus = (1 << l) - 1;
+
+        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+        libxl_cpumap_set_none(&b_info->avail_vcpus);
+        while (l-- > 0)
+            libxl_cpumap_set((&b_info->avail_vcpus), l);
     }

     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 05:41:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 05:41: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 1SaKb8-0006qj-5g; Fri, 01 Jun 2012 05:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaKb7-0006qe-0l
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 05:40:29 +0000
Received: from [85.158.143.35:7341] by server-3.bemta-4.messagelabs.com id
	97/6C-04252-CC558CF4; Fri, 01 Jun 2012 05:40:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1338529227!6980080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17776 invoked from network); 1 Jun 2012 05:40:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 05:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12777792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 05:40:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	06:40:26 +0100
Message-ID: <1338529225.14877.28.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "W. Michael Petullo" <mike@flyn.org>
Date: Fri, 1 Jun 2012 06:40:25 +0100
In-Reply-To: <20120601001208.GA2123@imp.flyn.org>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<1338508475.9414.18.camel@Abyss> <20120601001208.GA2123@imp.flyn.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 01:12 +0100, W. Michael Petullo wrote:
> >> tools, blockers:
> >> 
> >> ...
> >> 
> >> * xl compatibility with xm:
> >> 
> >>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
> >>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
> >> 
> >>         * does not automatically try to select a (set of) node(s) on
> >>           which to create a VM and pin its vcpus there. (Dario
> >>           Faggioli, patches posted)
> 
> I also noted another discrepancy (and provided a patch) between xm and
> xl in:
> 
> 	http://lists.xen.org/archives/html/xen-devel/2012-05/msg02285.html

Thanks for the ping. I would have sworn this was fixed already in 4.2
but it seems I was thinking of 25236:7872b0918901 which relates to
cpupool-create and not create.

Ian.




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

From xen-devel-bounces@lists.xen.org Fri Jun 01 05:41:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 05:41: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 1SaKb8-0006qj-5g; Fri, 01 Jun 2012 05:40:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaKb7-0006qe-0l
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 05:40:29 +0000
Received: from [85.158.143.35:7341] by server-3.bemta-4.messagelabs.com id
	97/6C-04252-CC558CF4; Fri, 01 Jun 2012 05:40:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1338529227!6980080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17776 invoked from network); 1 Jun 2012 05:40:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 05:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12777792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 05:40:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	06:40:26 +0100
Message-ID: <1338529225.14877.28.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "W. Michael Petullo" <mike@flyn.org>
Date: Fri, 1 Jun 2012 06:40:25 +0100
In-Reply-To: <20120601001208.GA2123@imp.flyn.org>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<1338508475.9414.18.camel@Abyss> <20120601001208.GA2123@imp.flyn.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 01:12 +0100, W. Michael Petullo wrote:
> >> tools, blockers:
> >> 
> >> ...
> >> 
> >> * xl compatibility with xm:
> >> 
> >>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
> >>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
> >> 
> >>         * does not automatically try to select a (set of) node(s) on
> >>           which to create a VM and pin its vcpus there. (Dario
> >>           Faggioli, patches posted)
> 
> I also noted another discrepancy (and provided a patch) between xm and
> xl in:
> 
> 	http://lists.xen.org/archives/html/xen-devel/2012-05/msg02285.html

Thanks for the ping. I would have sworn this was fixed already in 4.2
but it seems I was thinking of 25236:7872b0918901 which relates to
cpupool-create and not create.

Ian.




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

From xen-devel-bounces@lists.xen.org Fri Jun 01 05:46:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 05: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 1SaKgr-0006z3-W1; Fri, 01 Jun 2012 05:46: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 1SaKgq-0006yy-LD
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 05:46:24 +0000
Received: from [85.158.143.99:64269] by server-2.bemta-4.messagelabs.com id
	E5/55-11595-03758CF4; Fri, 01 Jun 2012 05:46:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338529582!30817034!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29437 invoked from network); 1 Jun 2012 05:46:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 05:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12777821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 05:45:58 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	06:45:58 +0100
Message-ID: <1338529558.14877.31.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "W. Michael Petullo" <mike@flyn.org>
Date: Fri, 1 Jun 2012 06:45:58 +0100
In-Reply-To: <20120531045040.GA16124@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using "xl create" without domain config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 05:50 +0100, W. Michael Petullo wrote:
> I found it useful to use xm without a domain configuration file:
> 
> 	xm create /dev/null kernel=...
> 
> The xl command does not support this. See a previous thread I started:
> 
> 	http://lists.xen.org/archives/html/xen-devel/2011-08/msg00330.html
> 
> I just found the time to modify xl so that it works without a domain
> configuration file. For example:
> 
> 	xl create kernel=\"...\" ...
> 
> Would it be possible to add this feature? The xl command already supports
> augmenting a domain configuration file with additional information
> from the command line. My changes just modify xl so that the entire
> configuration may be specified on the command line.
> 
> To test this patch, run:
> 
> 	1. xl create -c /path/to/config
> 
> 	2. xl create -c /path/to/config someAdditionalDomainParam=\"value\"
> 
> 	3. xl create -c kernel=\"/path/to/kernel\"
> 
> The third test covers the new case.

Does #3 actually work? I ask because name=".." is mandatory...

Please can you supply a proposed commit message including a
signed-off-by as per http://wiki.xen.org/wiki/Submitting_Xen_Patches

Please can you also check that docs/man/xl*.pod do not need updating
after this change.

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 05:46:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 05: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 1SaKgr-0006z3-W1; Fri, 01 Jun 2012 05:46: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 1SaKgq-0006yy-LD
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 05:46:24 +0000
Received: from [85.158.143.99:64269] by server-2.bemta-4.messagelabs.com id
	E5/55-11595-03758CF4; Fri, 01 Jun 2012 05:46:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338529582!30817034!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29437 invoked from network); 1 Jun 2012 05:46:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 05:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12777821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 05:45:58 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	06:45:58 +0100
Message-ID: <1338529558.14877.31.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "W. Michael Petullo" <mike@flyn.org>
Date: Fri, 1 Jun 2012 06:45:58 +0100
In-Reply-To: <20120531045040.GA16124@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using "xl create" without domain config file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 05:50 +0100, W. Michael Petullo wrote:
> I found it useful to use xm without a domain configuration file:
> 
> 	xm create /dev/null kernel=...
> 
> The xl command does not support this. See a previous thread I started:
> 
> 	http://lists.xen.org/archives/html/xen-devel/2011-08/msg00330.html
> 
> I just found the time to modify xl so that it works without a domain
> configuration file. For example:
> 
> 	xl create kernel=\"...\" ...
> 
> Would it be possible to add this feature? The xl command already supports
> augmenting a domain configuration file with additional information
> from the command line. My changes just modify xl so that the entire
> configuration may be specified on the command line.
> 
> To test this patch, run:
> 
> 	1. xl create -c /path/to/config
> 
> 	2. xl create -c /path/to/config someAdditionalDomainParam=\"value\"
> 
> 	3. xl create -c kernel=\"/path/to/kernel\"
> 
> The third test covers the new case.

Does #3 actually work? I ask because name=".." is mandatory...

Please can you supply a proposed commit message including a
signed-off-by as per http://wiki.xen.org/wiki/Submitting_Xen_Patches

Please can you also check that docs/man/xl*.pod do not need updating
after this change.

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:05:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaKym-0007Q9-Nb; Fri, 01 Jun 2012 06:04:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1SaKyl-0007Q4-F3
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:04:55 +0000
Received: from [85.158.143.99:22899] by server-1.bemta-4.messagelabs.com id
	63/61-27869-68B58CF4; Fri, 01 Jun 2012 06:04:54 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338530694!21195617!1
X-Originating-IP: [74.125.82.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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3138 invoked from network); 1 Jun 2012 06:04:54 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:04:54 -0000
Received: by wgbds1 with SMTP id ds1so262440wgb.2
	for <xen-devel@lists.xen.org>; Thu, 31 May 2012 23:04:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=zU/d/odZhl3G49CycHQYxUh3uK5pnjQkdfaWz4lMRak=;
	b=oeRnyg/d269e+A/esjmiMGEm2KiiRsPoAimcRyqw09AU3flUBU3YlBTCGQDU9S5F10
	MUXLDST0s4XexjpQgG+CJQmhoyXYRGzdheGUaM/0vBw4P7XSHtVEo2mnkGfbDiOI523B
	CZQx1Wr0Jb14QU9MBq0gujXWP35JXnsPc7tKIIWOPtEfklxDL97BmSOdDgSUhdYIwAUG
	u3V3flZcGS1q2j2+l9UiROkRlWrCnpZ7wNY7suCkakBo5DvrzrLoby50ba48HSVa1u3R
	+l5YxkoxFPIQYgWL0shib4kXngcJf4cQljBwLq0kgEY4xiAgvMYlnJN+iAT4wytuxOEc
	02YQ==
MIME-Version: 1.0
Received: by 10.216.207.67 with SMTP id m45mr1233900weo.175.1338530693953;
	Thu, 31 May 2012 23:04:53 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Thu, 31 May 2012 23:04:53 -0700 (PDT)
Date: Thu, 31 May 2012 23:04:53 -0700
Message-ID: <CAE+SDMzKMVUdUGFSbuemuP-Nr52FKuocySwuCxN3qJ6wwJcxwA@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Disable paging in xen kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3337128289664934552=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3337128289664934552==
Content-Type: multipart/alternative; boundary=0016e6d9a2d488b79204c162f671

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

Hi

I want to write a program in xen that runs in ring 0 and in unpaged
protected mode.
For this,  I add a hypercall and in my hypercall function write my code. I
test my hypercall, it works properly.
I see the value of CR0 register and I found that the PE and PG bits are 1.
It means that I am in protected mode with paging enabled.
In order to disable paging I want to set bit 31 of cr0 to 0, I write the
bellowing code in my hypercall function:

asm volatile(
"movl %cr0,%eax\n\t"
"and 0x7fffffff,%eax\n\t"
"movl %eax,%cr0"
);
But when I invoke my hypercall the system restart!!!
Can anyone tell me where is my fault and how should I disable paging in xen
kernel?

With kindest regards

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

Hi<br><br>I want to write a program in xen that runs in ring 0 and in unpag=
ed protected mode.<br>For this,=A0 I add a hypercall and in my hypercall fu=
nction write my code. I test my hypercall, it works properly.<br>I see the =
value of CR0 register and I found that the PE and PG bits are 1. It means t=
hat I am in protected mode with paging enabled.<br>
In order to disable paging I want to set bit 31 of cr0 to 0, I write the be=
llowing code in my hypercall function:<br><br>asm volatile(<br>&quot;movl %=
cr0,%eax\n\t&quot;<br>&quot;and 0x7fffffff,%eax\n\t&quot;<br>&quot;movl %ea=
x,%cr0&quot;<br>
);<br>But when I invoke my hypercall the system restart!!!<br>Can anyone te=
ll me where is my fault and how should I disable paging in xen kernel?<br><=
br>With kindest regards<br>

--0016e6d9a2d488b79204c162f671--


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

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

--===============3337128289664934552==--


From xen-devel-bounces@lists.xen.org Fri Jun 01 06:05:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaKym-0007Q9-Nb; Fri, 01 Jun 2012 06:04:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1SaKyl-0007Q4-F3
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:04:55 +0000
Received: from [85.158.143.99:22899] by server-1.bemta-4.messagelabs.com id
	63/61-27869-68B58CF4; Fri, 01 Jun 2012 06:04:54 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338530694!21195617!1
X-Originating-IP: [74.125.82.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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3138 invoked from network); 1 Jun 2012 06:04:54 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:04:54 -0000
Received: by wgbds1 with SMTP id ds1so262440wgb.2
	for <xen-devel@lists.xen.org>; Thu, 31 May 2012 23:04:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=zU/d/odZhl3G49CycHQYxUh3uK5pnjQkdfaWz4lMRak=;
	b=oeRnyg/d269e+A/esjmiMGEm2KiiRsPoAimcRyqw09AU3flUBU3YlBTCGQDU9S5F10
	MUXLDST0s4XexjpQgG+CJQmhoyXYRGzdheGUaM/0vBw4P7XSHtVEo2mnkGfbDiOI523B
	CZQx1Wr0Jb14QU9MBq0gujXWP35JXnsPc7tKIIWOPtEfklxDL97BmSOdDgSUhdYIwAUG
	u3V3flZcGS1q2j2+l9UiROkRlWrCnpZ7wNY7suCkakBo5DvrzrLoby50ba48HSVa1u3R
	+l5YxkoxFPIQYgWL0shib4kXngcJf4cQljBwLq0kgEY4xiAgvMYlnJN+iAT4wytuxOEc
	02YQ==
MIME-Version: 1.0
Received: by 10.216.207.67 with SMTP id m45mr1233900weo.175.1338530693953;
	Thu, 31 May 2012 23:04:53 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Thu, 31 May 2012 23:04:53 -0700 (PDT)
Date: Thu, 31 May 2012 23:04:53 -0700
Message-ID: <CAE+SDMzKMVUdUGFSbuemuP-Nr52FKuocySwuCxN3qJ6wwJcxwA@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Disable paging in xen kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3337128289664934552=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3337128289664934552==
Content-Type: multipart/alternative; boundary=0016e6d9a2d488b79204c162f671

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

Hi

I want to write a program in xen that runs in ring 0 and in unpaged
protected mode.
For this,  I add a hypercall and in my hypercall function write my code. I
test my hypercall, it works properly.
I see the value of CR0 register and I found that the PE and PG bits are 1.
It means that I am in protected mode with paging enabled.
In order to disable paging I want to set bit 31 of cr0 to 0, I write the
bellowing code in my hypercall function:

asm volatile(
"movl %cr0,%eax\n\t"
"and 0x7fffffff,%eax\n\t"
"movl %eax,%cr0"
);
But when I invoke my hypercall the system restart!!!
Can anyone tell me where is my fault and how should I disable paging in xen
kernel?

With kindest regards

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

Hi<br><br>I want to write a program in xen that runs in ring 0 and in unpag=
ed protected mode.<br>For this,=A0 I add a hypercall and in my hypercall fu=
nction write my code. I test my hypercall, it works properly.<br>I see the =
value of CR0 register and I found that the PE and PG bits are 1. It means t=
hat I am in protected mode with paging enabled.<br>
In order to disable paging I want to set bit 31 of cr0 to 0, I write the be=
llowing code in my hypercall function:<br><br>asm volatile(<br>&quot;movl %=
cr0,%eax\n\t&quot;<br>&quot;and 0x7fffffff,%eax\n\t&quot;<br>&quot;movl %ea=
x,%cr0&quot;<br>
);<br>But when I invoke my hypercall the system restart!!!<br>Can anyone te=
ll me where is my fault and how should I disable paging in xen kernel?<br><=
br>With kindest regards<br>

--0016e6d9a2d488b79204c162f671--


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

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

--===============3337128289664934552==--


From xen-devel-bounces@lists.xen.org Fri Jun 01 06:25:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:25: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 1SaLIa-0007cL-NS; Fri, 01 Jun 2012 06:25: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 1SaLIZ-0007cG-0Z
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:25:23 +0000
Received: from [85.158.143.35:24678] by server-1.bemta-4.messagelabs.com id
	87/C4-27869-25068CF4; Fri, 01 Jun 2012 06:25:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1338531920!10369286!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7137 invoked from network); 1 Jun 2012 06:25:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:25:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:25:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	07:25:18 +0100
Message-ID: <1338531918.14877.35.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "cyberhawk001@gmail.com" <cyberhawk001@gmail.com>
Date: Fri, 1 Jun 2012 07:25:18 +0100
In-Reply-To: <4FC7F89F.9010203@gmail.com>
References: <4FC7F89F.9010203@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Error in compiling latest Xen 4.2-Unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 00:02 +0100, cyberhawk001@gmail.com wrote:
> SO, possibly the GCC compiler is at fault and was wondering what
> version the Xen-devel team uses?

This issue is indeed a compiler related one.

The developers use a wide variety of compilers, including ones which
exhibit this behaviour. A few patches have been posted to xen-devel
(e.g.
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01856.html) but
we are still working on the final fix.

As a workaround in the meantime you could either apply the patch linked
above locally or remove the entirety of the "case -1" that is causing
the warnings.

Thanks for continuing to be patient.

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:25:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:25: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 1SaLIa-0007cL-NS; Fri, 01 Jun 2012 06:25: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 1SaLIZ-0007cG-0Z
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:25:23 +0000
Received: from [85.158.143.35:24678] by server-1.bemta-4.messagelabs.com id
	87/C4-27869-25068CF4; Fri, 01 Jun 2012 06:25:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1338531920!10369286!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7137 invoked from network); 1 Jun 2012 06:25:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:25:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:25:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	07:25:18 +0100
Message-ID: <1338531918.14877.35.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "cyberhawk001@gmail.com" <cyberhawk001@gmail.com>
Date: Fri, 1 Jun 2012 07:25:18 +0100
In-Reply-To: <4FC7F89F.9010203@gmail.com>
References: <4FC7F89F.9010203@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Error in compiling latest Xen 4.2-Unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 00:02 +0100, cyberhawk001@gmail.com wrote:
> SO, possibly the GCC compiler is at fault and was wondering what
> version the Xen-devel team uses?

This issue is indeed a compiler related one.

The developers use a wide variety of compilers, including ones which
exhibit this behaviour. A few patches have been posted to xen-devel
(e.g.
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01856.html) but
we are still working on the final fix.

As a workaround in the meantime you could either apply the patch linked
above locally or remove the entirety of the "case -1" that is causing
the warnings.

Thanks for continuing to be patient.

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:26:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaLJf-0007fD-5N; Fri, 01 Jun 2012 06:26:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaLJe-0007f5-4N
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:26:30 +0000
Received: from [85.158.139.83:36764] by server-10.bemta-5.messagelabs.com id
	44/2B-22179-59068CF4; Fri, 01 Jun 2012 06:26:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338531984!31403830!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4226 invoked from network); 1 Jun 2012 06:26:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-182.messagelabs.com with SMTP;
	1 Jun 2012 06:26:27 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78331560; Fri, 01 Jun 2012 08:26:20 +0200
Message-ID: <1338531971.31901.2.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 01 Jun 2012 08:26:11 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============8524888598274702035=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8524888598274702035==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+aD3wdiyOZXDLbz/sutd"


--=-+aD3wdiyOZXDLbz/sutd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

Sorry, my fault I missed the v1 of this but...

On Fri, 2012-06-01 at 02:41 +0000, Zhang, Yang Z wrote:=20
> Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_cpus.=
 In some place, we may want to allocate specific size of cpumap.
>
... Do we? I fail to see this in the code below (you're only replacing
libxl_cpumap_alloc calls with new versions _always_ passing 0 as
max_cpus, am I right?)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-+aD3wdiyOZXDLbz/sutd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IYIMACgkQk4XaBE3IOsQkYgCfeL7pqY80mPFQEuRAN6B99gsv
fIgAnjQpNsj8tJi9RaVFXhJDhSbAYJpg
=GsQm
-----END PGP SIGNATURE-----

--=-+aD3wdiyOZXDLbz/sutd--



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

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

--===============8524888598274702035==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 06:26:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaLJf-0007fD-5N; Fri, 01 Jun 2012 06:26:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaLJe-0007f5-4N
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:26:30 +0000
Received: from [85.158.139.83:36764] by server-10.bemta-5.messagelabs.com id
	44/2B-22179-59068CF4; Fri, 01 Jun 2012 06:26:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338531984!31403830!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4226 invoked from network); 1 Jun 2012 06:26:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-182.messagelabs.com with SMTP;
	1 Jun 2012 06:26:27 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78331560; Fri, 01 Jun 2012 08:26:20 +0200
Message-ID: <1338531971.31901.2.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 01 Jun 2012 08:26:11 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============8524888598274702035=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8524888598274702035==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+aD3wdiyOZXDLbz/sutd"


--=-+aD3wdiyOZXDLbz/sutd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

Sorry, my fault I missed the v1 of this but...

On Fri, 2012-06-01 at 02:41 +0000, Zhang, Yang Z wrote:=20
> Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_cpus.=
 In some place, we may want to allocate specific size of cpumap.
>
... Do we? I fail to see this in the code below (you're only replacing
libxl_cpumap_alloc calls with new versions _always_ passing 0 as
max_cpus, am I right?)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-+aD3wdiyOZXDLbz/sutd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IYIMACgkQk4XaBE3IOsQkYgCfeL7pqY80mPFQEuRAN6B99gsv
fIgAnjQpNsj8tJi9RaVFXhJDhSbAYJpg
=GsQm
-----END PGP SIGNATURE-----

--=-+aD3wdiyOZXDLbz/sutd--



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

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

--===============8524888598274702035==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 06:30:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLMl-0007pm-P5; Fri, 01 Jun 2012 06:29: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 1SaLMk-0007pd-A6
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:29:42 +0000
Received: from [85.158.143.35:45886] by server-2.bemta-4.messagelabs.com id
	E5/7C-11595-55168CF4; Fri, 01 Jun 2012 06:29:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1338532180!15135028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7264 invoked from network); 1 Jun 2012 06:29:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:29:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:29:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	07:29:40 +0100
Message-ID: <1338532179.14877.39.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Jun 2012 07:29:39 +0100
In-Reply-To: <4FC7A24B.3010506@citrix.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<05447f395c91029fb732.1338482400@whitby.uk.xensource.com>
	<4FC7A24B.3010506@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 6] arm: Move hyp-mode entry code out of
 line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 17:54 +0100, David Vrabel wrote:
> On 31/05/12 17:40, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1338482127 -3600
> > # Node ID 05447f395c91029fb732142e36788cfa92374045
> > # Parent  25d389d891c5a2a3009258ef7261379a9ad97746
> > arm: Move hyp-mode entry code out of line.
> > 
> > This code is grottier than the rest of the start-of-day code and
> > very specific to the software model we're developing on.
> > Segregate it accordingly, by putting it in its own file.
> 
> I've been vaguely thinking about writing a stub-bootloader to do this
> and provide the DTB (instead of having to link it with Xen).  Is this
> something that would be useful?

Rather than a new stub-bootloader we should switch over to using the
same boot-wrapper.git as Linaro and KVM are using[0], and perhaps
enhancing it to meet our needs.

One benefit of that is that when they come to do stuff on real hardware
we will already be somewhat aligned with something which looks a bit
like a bootloader so it should be easier for us to transition too.

It also has other benefits like enabling us to use semi-hosting to pull
the files off the host filesystem.

Ian.

[0] http://git.linaro.org/gitweb?p=arm/models/boot-wrapper.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 Fri Jun 01 06:30:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLMl-0007pm-P5; Fri, 01 Jun 2012 06:29: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 1SaLMk-0007pd-A6
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:29:42 +0000
Received: from [85.158.143.35:45886] by server-2.bemta-4.messagelabs.com id
	E5/7C-11595-55168CF4; Fri, 01 Jun 2012 06:29:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1338532180!15135028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7264 invoked from network); 1 Jun 2012 06:29:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:29:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:29:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	07:29:40 +0100
Message-ID: <1338532179.14877.39.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Jun 2012 07:29:39 +0100
In-Reply-To: <4FC7A24B.3010506@citrix.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<05447f395c91029fb732.1338482400@whitby.uk.xensource.com>
	<4FC7A24B.3010506@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 6] arm: Move hyp-mode entry code out of
 line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 17:54 +0100, David Vrabel wrote:
> On 31/05/12 17:40, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1338482127 -3600
> > # Node ID 05447f395c91029fb732142e36788cfa92374045
> > # Parent  25d389d891c5a2a3009258ef7261379a9ad97746
> > arm: Move hyp-mode entry code out of line.
> > 
> > This code is grottier than the rest of the start-of-day code and
> > very specific to the software model we're developing on.
> > Segregate it accordingly, by putting it in its own file.
> 
> I've been vaguely thinking about writing a stub-bootloader to do this
> and provide the DTB (instead of having to link it with Xen).  Is this
> something that would be useful?

Rather than a new stub-bootloader we should switch over to using the
same boot-wrapper.git as Linaro and KVM are using[0], and perhaps
enhancing it to meet our needs.

One benefit of that is that when they come to do stuff on real hardware
we will already be somewhat aligned with something which looks a bit
like a bootloader so it should be easier for us to transition too.

It also has other benefits like enabling us to use semi-hosting to pull
the files off the host filesystem.

Ian.

[0] http://git.linaro.org/gitweb?p=arm/models/boot-wrapper.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 Fri Jun 01 06:31:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:31: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 1SaLOO-0007wv-Ls; Fri, 01 Jun 2012 06:31:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaLOM-0007wZ-VH
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:31:23 +0000
Received: from [85.158.143.99:23008] by server-1.bemta-4.messagelabs.com id
	FE/7A-27869-AB168CF4; Fri, 01 Jun 2012 06:31:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338532281!24291273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13016 invoked from network); 1 Jun 2012 06:31:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:26:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 07:26:13 +0100
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 1SaLJN-0000Js-Fa;
	Fri, 01 Jun 2012 06:26:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaLJN-000142-6Q;
	Fri, 01 Jun 2012 07:26:13 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13002-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 07:26:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13002: 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 13002 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13002/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  d7318231cfe3
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:31:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:31: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 1SaLOO-0007wv-Ls; Fri, 01 Jun 2012 06:31:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaLOM-0007wZ-VH
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:31:23 +0000
Received: from [85.158.143.99:23008] by server-1.bemta-4.messagelabs.com id
	FE/7A-27869-AB168CF4; Fri, 01 Jun 2012 06:31:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338532281!24291273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13016 invoked from network); 1 Jun 2012 06:31:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:26:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 07:26:13 +0100
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 1SaLJN-0000Js-Fa;
	Fri, 01 Jun 2012 06:26:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaLJN-000142-6Q;
	Fri, 01 Jun 2012 07:26:13 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13002-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 07:26:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13002: 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 13002 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13002/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  d7318231cfe3
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:31:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLOO-0007wo-9l; Fri, 01 Jun 2012 06:31: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 1SaLOM-0007wY-Re
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:31:22 +0000
Received: from [85.158.143.99:26261] by server-3.bemta-4.messagelabs.com id
	4B/79-04252-AB168CF4; Fri, 01 Jun 2012 06:31:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338532281!24291273!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13019 invoked from network); 1 Jun 2012 06:31:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:30: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.213.0; Fri, 1 Jun 2012
	07:30:41 +0100
Message-ID: <1338532240.14877.40.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 07:30:40 +0100
In-Reply-To: <1338531971.31901.2.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
	<1338531971.31901.2.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
 specific 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 Fri, 2012-06-01 at 07:26 +0100, Dario Faggioli wrote:
> Hi all,
> 
> Sorry, my fault I missed the v1 of this but...
> 
> On Fri, 2012-06-01 at 02:41 +0000, Zhang, Yang Z wrote: 
> > Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_cpus. In some place, we may want to allocate specific size of cpumap.
> >
> ... Do we? I fail to see this in the code below (you're only replacing
> libxl_cpumap_alloc calls with new versions _always_ passing 0 as
> max_cpus, am I right?)

The change to actually use this is is a followup patch "libxl: allow to
set more than 31 vcpus".

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:31:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLOO-0007wo-9l; Fri, 01 Jun 2012 06:31: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 1SaLOM-0007wY-Re
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:31:22 +0000
Received: from [85.158.143.99:26261] by server-3.bemta-4.messagelabs.com id
	4B/79-04252-AB168CF4; Fri, 01 Jun 2012 06:31:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338532281!24291273!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13019 invoked from network); 1 Jun 2012 06:31:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 06:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12778254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:30: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.213.0; Fri, 1 Jun 2012
	07:30:41 +0100
Message-ID: <1338532240.14877.40.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 07:30:40 +0100
In-Reply-To: <1338531971.31901.2.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
	<1338531971.31901.2.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
 specific 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 Fri, 2012-06-01 at 07:26 +0100, Dario Faggioli wrote:
> Hi all,
> 
> Sorry, my fault I missed the v1 of this but...
> 
> On Fri, 2012-06-01 at 02:41 +0000, Zhang, Yang Z wrote: 
> > Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_cpus. In some place, we may want to allocate specific size of cpumap.
> >
> ... Do we? I fail to see this in the code below (you're only replacing
> libxl_cpumap_alloc calls with new versions _always_ passing 0 as
> max_cpus, am I right?)

The change to actually use this is is a followup patch "libxl: allow to
set more than 31 vcpus".

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:35:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLSb-0008Tw-CB; Fri, 01 Jun 2012 06:35:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaLSa-0008To-DI
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:35:44 +0000
Received: from [85.158.138.51:6963] by server-5.bemta-3.messagelabs.com id
	16/51-27664-FB268CF4; Fri, 01 Jun 2012 06:35:43 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338532542!11578090!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19100 invoked from network); 1 Jun 2012 06:35:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 06:35:42 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78331796; Fri, 01 Jun 2012 08:35:42 +0200
Message-ID: <1338532541.31901.10.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 01 Jun 2012 08:35:41 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6394858579261262338=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6394858579261262338==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-/eGdupRGnTZxx0qcmlNc"


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

On Fri, 2012-06-01 at 02:48 +0000, Zhang, Yang Z wrote:=20
> Change from v2:
> Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> According to Ian's comments, modified some codes to make the logic more r=
easonable.
>=20
> In current implementation, it uses integer to record current avail cpus a=
nd this only allows user to specify 31 vcpus.=20
> In following patch, it uses cpumap instead integer which make more sense =
than before. Also there is no limit to the max vcpus.
>=20
This part I understand, and looks reasonable.

I also see this is the whole point of your other patch, however ...

> diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> @@ -650,7 +650,14 @@ static void parse_config_data(const char
>=20
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus =3D l;
> -        b_info->cur_vcpus =3D (1 << l) - 1;
> +
> +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> +            fprintf(stderr, "Unable to allocate cpumap\n");
> +            exit(1);
> +        }
>
... Do you mind explaining me what would have happened here without your
previous patch, i.e., by just using the existing libxl_cpumap_alloc ?

I might be wrong, but I was wondering whether it is worth changing the
interface like that for just this single case which saves, what, 1 to 3
bytes per domain?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-/eGdupRGnTZxx0qcmlNc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IYr0ACgkQk4XaBE3IOsRh4QCfccT8mDMUryVPbAey/+wtEdZS
sEYAoIeoFumjV5Ar3KR0xl46sGgqkrdn
=BNBE
-----END PGP SIGNATURE-----

--=-/eGdupRGnTZxx0qcmlNc--



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

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

--===============6394858579261262338==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 06:35:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLSb-0008Tw-CB; Fri, 01 Jun 2012 06:35:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaLSa-0008To-DI
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:35:44 +0000
Received: from [85.158.138.51:6963] by server-5.bemta-3.messagelabs.com id
	16/51-27664-FB268CF4; Fri, 01 Jun 2012 06:35:43 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338532542!11578090!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19100 invoked from network); 1 Jun 2012 06:35:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 06:35:42 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78331796; Fri, 01 Jun 2012 08:35:42 +0200
Message-ID: <1338532541.31901.10.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 01 Jun 2012 08:35:41 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6394858579261262338=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6394858579261262338==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-/eGdupRGnTZxx0qcmlNc"


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

On Fri, 2012-06-01 at 02:48 +0000, Zhang, Yang Z wrote:=20
> Change from v2:
> Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> According to Ian's comments, modified some codes to make the logic more r=
easonable.
>=20
> In current implementation, it uses integer to record current avail cpus a=
nd this only allows user to specify 31 vcpus.=20
> In following patch, it uses cpumap instead integer which make more sense =
than before. Also there is no limit to the max vcpus.
>=20
This part I understand, and looks reasonable.

I also see this is the whole point of your other patch, however ...

> diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> @@ -650,7 +650,14 @@ static void parse_config_data(const char
>=20
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus =3D l;
> -        b_info->cur_vcpus =3D (1 << l) - 1;
> +
> +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> +            fprintf(stderr, "Unable to allocate cpumap\n");
> +            exit(1);
> +        }
>
... Do you mind explaining me what would have happened here without your
previous patch, i.e., by just using the existing libxl_cpumap_alloc ?

I might be wrong, but I was wondering whether it is worth changing the
interface like that for just this single case which saves, what, 1 to 3
bytes per domain?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-/eGdupRGnTZxx0qcmlNc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IYr0ACgkQk4XaBE3IOsRh4QCfccT8mDMUryVPbAey/+wtEdZS
sEYAoIeoFumjV5Ar3KR0xl46sGgqkrdn
=BNBE
-----END PGP SIGNATURE-----

--=-/eGdupRGnTZxx0qcmlNc--



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

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

--===============6394858579261262338==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 06:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLVa-0000AT-Vf; Fri, 01 Jun 2012 06:38:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaLVZ-0000AL-Ij
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:38:49 +0000
Received: from [193.109.254.147:45931] by server-5.bemta-14.messagelabs.com id
	67/9D-06171-87368CF4; Fri, 01 Jun 2012 06:38:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338532728!5461576!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11191 invoked from network); 1 Jun 2012 06:38:48 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 06:38:48 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78331856; Fri, 01 Jun 2012 08:38:47 +0200
Message-ID: <1338532727.31901.12.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 08:38:47 +0200
In-Reply-To: <1338532240.14877.40.camel@dagon.hellion.org.uk>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
	<1338531971.31901.2.camel@Abyss>
	<1338532240.14877.40.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============0809171089258822139=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0809171089258822139==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-38FnUCPfRk1XdTufMK3o"


--=-38FnUCPfRk1XdTufMK3o
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 07:30 +0100, Ian Campbell wrote:=20
> > > Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_c=
pus. In some place, we may want to allocate specific size of cpumap.
> > >
> > ... Do we? I fail to see this in the code below (you're only replacing
> > libxl_cpumap_alloc calls with new versions _always_ passing 0 as
> > max_cpus, am I right?)
>=20
> The change to actually use this is is a followup patch "libxl: allow to
> set more than 31 vcpus".
>=20
Yep, I saw that and commented on it too... If we go for this, I'd
suggest at least changing the changelog a bit and mention where/why
we're going to use it.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-38FnUCPfRk1XdTufMK3o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IY3cACgkQk4XaBE3IOsQBkQCfQO4yphSQbFpWzfGamhnGSk+q
QjgAn12utlMg7sCRXWTkBomjGBCUQJDB
=67r7
-----END PGP SIGNATURE-----

--=-38FnUCPfRk1XdTufMK3o--



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

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

--===============0809171089258822139==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 06:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06: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 1SaLVa-0000AT-Vf; Fri, 01 Jun 2012 06:38:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaLVZ-0000AL-Ij
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 06:38:49 +0000
Received: from [193.109.254.147:45931] by server-5.bemta-14.messagelabs.com id
	67/9D-06171-87368CF4; Fri, 01 Jun 2012 06:38:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338532728!5461576!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11191 invoked from network); 1 Jun 2012 06:38:48 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 06:38:48 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78331856; Fri, 01 Jun 2012 08:38:47 +0200
Message-ID: <1338532727.31901.12.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 08:38:47 +0200
In-Reply-To: <1338532240.14877.40.camel@dagon.hellion.org.uk>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162559@SHSMSX101.ccr.corp.intel.com>
	<1338531971.31901.2.camel@Abyss>
	<1338532240.14877.40.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============0809171089258822139=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0809171089258822139==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-38FnUCPfRk1XdTufMK3o"


--=-38FnUCPfRk1XdTufMK3o
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 07:30 +0100, Ian Campbell wrote:=20
> > > Currently, libxl_cpumap_alloc()allocate the cpumap with size of max_c=
pus. In some place, we may want to allocate specific size of cpumap.
> > >
> > ... Do we? I fail to see this in the code below (you're only replacing
> > libxl_cpumap_alloc calls with new versions _always_ passing 0 as
> > max_cpus, am I right?)
>=20
> The change to actually use this is is a followup patch "libxl: allow to
> set more than 31 vcpus".
>=20
Yep, I saw that and commented on it too... If we go for this, I'd
suggest at least changing the changelog a bit and mention where/why
we're going to use it.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-38FnUCPfRk1XdTufMK3o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IY3cACgkQk4XaBE3IOsQBkQCfQO4yphSQbFpWzfGamhnGSk+q
QjgAn12utlMg7sCRXWTkBomjGBCUQJDB
=67r7
-----END PGP SIGNATURE-----

--=-38FnUCPfRk1XdTufMK3o--



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

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

--===============0809171089258822139==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 06:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaLkq-0000ht-7x; Fri, 01 Jun 2012 06:54:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SaLko-0000ho-Nk
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:54:35 +0000
Received: from [85.158.143.99:22771] by server-2.bemta-4.messagelabs.com id
	17/7A-11595-A2768CF4; Fri, 01 Jun 2012 06:54:34 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338533672!28522686!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIyNzIwMA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14498 invoked from network); 1 Jun 2012 06:54:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 06:54:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=oiQ6krrrOtUDz3T69ifyi5WAb1djTL/IoEe2QOsc9eVHxVrXAOSd+J8F
	ICHZMPK9+lzdcnsd+qSKi8a6+w1En6IscMi9wABWEUMC2KKiLxOe+2A0/
	EjBKWIIoIdaQLOSGorGAwvIhsTQ80DawAcXAHK7LpSty9pSugofXxhitR
	FtnJwRpwpBoCMn/QCvOi+xdE9V8ecJgf39Eu8wwZ1voELJR36htoH8Wni
	WGmxYqmaELFUY1wu7TfiDuEjLVqCd;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1338533673; x=1370069673;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=tF2mwMa2pMLuMXRBXa09dgFTk5NBBFOlAgJFYGEaa5s=;
	b=SoMMSJ6Yoo3wvya9pejShnsd9p89cTAlpWDaWfaB2Atx2GUtWKeMIyEM
	xXzfA1zNEn62evwZp4VyFv0GyLzRQJuY1bypS3SYsixTGlMm1AB317c4H
	TB72CHZM0kBp0Ab5PR1/7tXkiw2uoI6sJCDwfa16SufieTiRaSI5BbY86
	uaerck+E261WQ0UX2hGll0ZNgpOPrSXAdPSBZi7EIt7j57x8Ab2gG1xH0
	AXhqJ8YWg2w/QnekrOXYMelDeE83a;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,696,1330902000"; d="scan'208";a="112054869"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 01 Jun 2012 08:54:32 +0200
X-IronPort-AV: E=Sophos;i="4.75,695,1330902000"; d="scan'208";a="135073590"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 01 Jun 2012 08:54:31 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id AD4AF967273;
	Fri,  1 Jun 2012 08:54:31 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Fri, 01 Jun 2012 08:54:31 +0200
Message-ID: <1450428.mTiMjbI6q8@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.10-1.9-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4FC7B32F0200007800087786@nat28.tlf.novell.com>
References: <CAOvdn6V1xSRjWEMPG8Mo1qZUco2NQC-eLWOJ7paM4329tjkFfg@mail.gmail.com>
	<CAOvdn6WbnAC-RwTS_8SGeMOpJFPDY1eBqCdtsAgzRekrjTGnBA@mail.gmail.com>
	<4FC7B32F0200007800087786@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, keir@xen.org,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dump with xen-unstable & linux 3.2.17
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Donnerstag 31 Mai 2012, 17:06:39 schrieb Jan Beulich:
> >>> On 31.05.12 at 17:52, Ben Guthro <ben@guthro.net> wrote:
> > 1. The changeset mentioned below needed to be reverted, as it was
> > removing the CPUS at suspend time.
> 
> I assume you refer to the one line change, not the full c/s?
> Juergen would have to tell us whether reverting that would
> break something else.

Maybe this will take some time as Juergen is away for a week.

Dietmar.

> 
> > 2. The linux xen watchdog driver (drivers/watchdog/xen_wdt.c) seems to
> > be enabling itsself on resume, even if you tell it not to.
> > I worked around this by just turning off watchdogs in my kernel
> > config...because I wasn't using them anyhow.
> 
> That was a problem up to 3.3, but was fixed in 3.4 afaict. What
> kernel version did you see this with?
> 
> Jan
> 
> > On Fri, May 25, 2012 at 9:20 AM, Ben Guthro <ben@guthro.net> wrote:
> >> Changed parts:
> >>
> >> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> >> index 0854f55..95cb2b4 100644
> >> --- a/xen/common/schedule.c
> >> +++ b/xen/common/schedule.c
> >> @@ -543,7 +543,7 @@ int cpu_disable_scheduler(unsigned int cpu)
> >>     int    ret = 0;
> >>
> >>     c = per_cpu(cpupool, cpu);
> >> -    if ( (c == NULL) || (system_state == SYS_STATE_suspend) )
> >> +    if ( (c == NULL) )
> >>         return ret;
> >>
> >>     for_each_domain_in_cpupool ( d, c )

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 06:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 06:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaLkq-0000ht-7x; Fri, 01 Jun 2012 06:54:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1SaLko-0000ho-Nk
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 06:54:35 +0000
Received: from [85.158.143.99:22771] by server-2.bemta-4.messagelabs.com id
	17/7A-11595-A2768CF4; Fri, 01 Jun 2012 06:54:34 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338533672!28522686!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIyNzIwMA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14498 invoked from network); 1 Jun 2012 06:54:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 06:54:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=oiQ6krrrOtUDz3T69ifyi5WAb1djTL/IoEe2QOsc9eVHxVrXAOSd+J8F
	ICHZMPK9+lzdcnsd+qSKi8a6+w1En6IscMi9wABWEUMC2KKiLxOe+2A0/
	EjBKWIIoIdaQLOSGorGAwvIhsTQ80DawAcXAHK7LpSty9pSugofXxhitR
	FtnJwRpwpBoCMn/QCvOi+xdE9V8ecJgf39Eu8wwZ1voELJR36htoH8Wni
	WGmxYqmaELFUY1wu7TfiDuEjLVqCd;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1338533673; x=1370069673;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=tF2mwMa2pMLuMXRBXa09dgFTk5NBBFOlAgJFYGEaa5s=;
	b=SoMMSJ6Yoo3wvya9pejShnsd9p89cTAlpWDaWfaB2Atx2GUtWKeMIyEM
	xXzfA1zNEn62evwZp4VyFv0GyLzRQJuY1bypS3SYsixTGlMm1AB317c4H
	TB72CHZM0kBp0Ab5PR1/7tXkiw2uoI6sJCDwfa16SufieTiRaSI5BbY86
	uaerck+E261WQ0UX2hGll0ZNgpOPrSXAdPSBZi7EIt7j57x8Ab2gG1xH0
	AXhqJ8YWg2w/QnekrOXYMelDeE83a;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.75,696,1330902000"; d="scan'208";a="112054869"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 01 Jun 2012 08:54:32 +0200
X-IronPort-AV: E=Sophos;i="4.75,695,1330902000"; d="scan'208";a="135073590"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 01 Jun 2012 08:54:31 +0200
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id AD4AF967273;
	Fri,  1 Jun 2012 08:54:31 +0200 (CEST)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xen.org
Date: Fri, 01 Jun 2012 08:54:31 +0200
Message-ID: <1450428.mTiMjbI6q8@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.10-1.9-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4FC7B32F0200007800087786@nat28.tlf.novell.com>
References: <CAOvdn6V1xSRjWEMPG8Mo1qZUco2NQC-eLWOJ7paM4329tjkFfg@mail.gmail.com>
	<CAOvdn6WbnAC-RwTS_8SGeMOpJFPDY1eBqCdtsAgzRekrjTGnBA@mail.gmail.com>
	<4FC7B32F0200007800087786@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, keir@xen.org,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dump with xen-unstable & linux 3.2.17
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Donnerstag 31 Mai 2012, 17:06:39 schrieb Jan Beulich:
> >>> On 31.05.12 at 17:52, Ben Guthro <ben@guthro.net> wrote:
> > 1. The changeset mentioned below needed to be reverted, as it was
> > removing the CPUS at suspend time.
> 
> I assume you refer to the one line change, not the full c/s?
> Juergen would have to tell us whether reverting that would
> break something else.

Maybe this will take some time as Juergen is away for a week.

Dietmar.

> 
> > 2. The linux xen watchdog driver (drivers/watchdog/xen_wdt.c) seems to
> > be enabling itsself on resume, even if you tell it not to.
> > I worked around this by just turning off watchdogs in my kernel
> > config...because I wasn't using them anyhow.
> 
> That was a problem up to 3.3, but was fixed in 3.4 afaict. What
> kernel version did you see this with?
> 
> Jan
> 
> > On Fri, May 25, 2012 at 9:20 AM, Ben Guthro <ben@guthro.net> wrote:
> >> Changed parts:
> >>
> >> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> >> index 0854f55..95cb2b4 100644
> >> --- a/xen/common/schedule.c
> >> +++ b/xen/common/schedule.c
> >> @@ -543,7 +543,7 @@ int cpu_disable_scheduler(unsigned int cpu)
> >>     int    ret = 0;
> >>
> >>     c = per_cpu(cpupool, cpu);
> >> -    if ( (c == NULL) || (system_state == SYS_STATE_suspend) )
> >> +    if ( (c == NULL) )
> >>         return ret;
> >>
> >>     for_each_domain_in_cpupool ( d, c )

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 07:19:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaM8G-0001KI-DA; Fri, 01 Jun 2012 07:18:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SaM8E-0001KA-AR
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 07:18:46 +0000
Received: from [85.158.143.35:11634] by server-1.bemta-4.messagelabs.com id
	22/08-27869-5DC68CF4; Fri, 01 Jun 2012 07:18:45 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338535123!7887820!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ0NDQy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30079 invoked from network); 1 Jun 2012 07:18:44 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 07:18:44 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 01 Jun 2012 00:18:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="150287282"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 01 Jun 2012 00:18:43 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 1 Jun 2012 00:18:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 15:18:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Dario Faggioli <raistlin@linux.it>
Thread-Topic: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
Thread-Index: Ac0/oQmLbu06FE6qS2aPDp2Yn0HQx///uVeA//95NxA=
Date: Fri, 1 Jun 2012 07:18:40 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
In-Reply-To: <1338532541.31901.10.camel@Abyss>
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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Dario Faggioli [mailto:raistlin@linux.it]
> Sent: Friday, June 01, 2012 2:36 PM
> To: Zhang, Yang Z
> Cc: xen-devel@lists.xensource.com; Ian Campbell
> Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
> 
> On Fri, 2012-06-01 at 02:48 +0000, Zhang, Yang Z wrote:
> > Change from v2:
> > Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> > According to Ian's comments, modified some codes to make the logic more
> reasonable.
> >
> > In current implementation, it uses integer to record current avail cpus and
> this only allows user to specify 31 vcpus.
> > In following patch, it uses cpumap instead integer which make more sense
> than before. Also there is no limit to the max vcpus.
> >
> This part I understand, and looks reasonable.
> 
> I also see this is the whole point of your other patch, however ...
> 
> > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> >
> >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> >          b_info->max_vcpus = l;
> > -        b_info->cur_vcpus = (1 << l) - 1;
> > +
> > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > +            exit(1);
> > +        }
> >
> ... Do you mind explaining me what would have happened here without your
> previous patch, i.e., by just using the existing libxl_cpumap_alloc ?
>
> I might be wrong, but I was wondering whether it is worth changing the
> interface like that for just this single case which saves, what, 1 to 3
> bytes per domain?
> 

It's ok to use existing libxl_cpumap_alloc(). But in my case, there is no need to use the existing interface.
And, in future, there are some cases may not need to allocate max size cpumap too. So it's better to extend the current interface.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 07:19:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaM8G-0001KI-DA; Fri, 01 Jun 2012 07:18:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SaM8E-0001KA-AR
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 07:18:46 +0000
Received: from [85.158.143.35:11634] by server-1.bemta-4.messagelabs.com id
	22/08-27869-5DC68CF4; Fri, 01 Jun 2012 07:18:45 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338535123!7887820!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ0NDQy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30079 invoked from network); 1 Jun 2012 07:18:44 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 07:18:44 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 01 Jun 2012 00:18:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="150287282"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 01 Jun 2012 00:18:43 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 1 Jun 2012 00:18:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 15:18:40 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Dario Faggioli <raistlin@linux.it>
Thread-Topic: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
Thread-Index: Ac0/oQmLbu06FE6qS2aPDp2Yn0HQx///uVeA//95NxA=
Date: Fri, 1 Jun 2012 07:18:40 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
In-Reply-To: <1338532541.31901.10.camel@Abyss>
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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Dario Faggioli [mailto:raistlin@linux.it]
> Sent: Friday, June 01, 2012 2:36 PM
> To: Zhang, Yang Z
> Cc: xen-devel@lists.xensource.com; Ian Campbell
> Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
> 
> On Fri, 2012-06-01 at 02:48 +0000, Zhang, Yang Z wrote:
> > Change from v2:
> > Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> > According to Ian's comments, modified some codes to make the logic more
> reasonable.
> >
> > In current implementation, it uses integer to record current avail cpus and
> this only allows user to specify 31 vcpus.
> > In following patch, it uses cpumap instead integer which make more sense
> than before. Also there is no limit to the max vcpus.
> >
> This part I understand, and looks reasonable.
> 
> I also see this is the whole point of your other patch, however ...
> 
> > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> >
> >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> >          b_info->max_vcpus = l;
> > -        b_info->cur_vcpus = (1 << l) - 1;
> > +
> > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > +            exit(1);
> > +        }
> >
> ... Do you mind explaining me what would have happened here without your
> previous patch, i.e., by just using the existing libxl_cpumap_alloc ?
>
> I might be wrong, but I was wondering whether it is worth changing the
> interface like that for just this single case which saves, what, 1 to 3
> bytes per domain?
> 

It's ok to use existing libxl_cpumap_alloc(). But in my case, there is no need to use the existing interface.
And, in future, there are some cases may not need to allocate max size cpumap too. So it's better to extend the current interface.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 07:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaMCr-0001SF-5N; Fri, 01 Jun 2012 07:23:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1SaMCp-0001S9-Dc
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 07:23:31 +0000
Received: from [85.158.143.35:41280] by server-2.bemta-4.messagelabs.com id
	FA/D3-11595-2FD68CF4; Fri, 01 Jun 2012 07:23:30 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1338535406!10377973!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7458 invoked from network); 1 Jun 2012 07:23:27 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-10.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 07:23:27 -0000
Received: from [127.0.0.1] ([::ffff:147.2.207.143])
	by mail.novell.com with ESMTP; Fri, 01 Jun 2012 01:23:12 -0600
MIME-Version: 1.0
X-Mercurial-Node: 3496f86000b80595b34a56390a5e269ef5d2bc44
Message-Id: <3496f86000b80595b34a.1338535311@linux-x12>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 01 Jun 2012 15:21:51 +0800
From: Bamvor Jian Zhang <bjzhang@suse.com>
To: xen-devel@lists.xen.org
Cc: jfehlig@suse.com, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	bjzhang@suse.com
Subject: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain console
	tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 api retrieve domain console from xenstore. With this new api, it is easy to implement "virsh console" command in libvirt libxl driver.

Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>

Changes since v2:
 * using ERROR_INVAL instead of ERROR_FAIL in libxl_console_get_tty and
 libxl__primary_console_find if need.
 * remove _out from some value name in libxl_primary_console_exec
 * add error handler and log message in libxl_console_get_tty.
 BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0, tty) will lead to null pointer access in CTX maco.
 * add empty line between my comment and other function.

diff -r d7318231cfe3 -r 3496f86000b8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl.c	Fri Jun 01 15:10:45 2012 +0800
@@ -1188,7 +1188,8 @@ out:
     return rc;
 }
 
-int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
+int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
+                       libxl_console_type type)
 {
     GC_INIT(ctx);
     char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
@@ -1214,25 +1215,82 @@ out:
     return ERROR_FAIL;
 }
 
-int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path)
+{
+    GC_INIT(ctx);
+    char *dom_path = 0;
+    char *tty_path = 0;
+    char *tty = 0;
+    int rc;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    switch (type) {
+    case LIBXL_CONSOLE_TYPE_SERIAL:
+        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
+        break;
+    case LIBXL_CONSOLE_TYPE_PV:
+        if (cons_num == 0)
+            tty_path = GCSPRINTF("%s/console/tty", dom_path);
+        else
+            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
+                                cons_num);
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+
+    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+    if (!tty) {
+       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
+       rc = ERROR_FAIL;
+       goto out;
+    }
+
+    *path = strdup(tty);
+    if (!*path)
+        libxl__alloc_failed(CTX, __func__, strlen(*path), 1);
+
+    rc = 0;
+
+out:
+    GC_FREE;
+    return rc;
+}
+
+static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
+                                       uint32_t *domid, int *cons_num, 
+                                       libxl_console_type *type)
 {
     GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
-    int rc;
-    if (stubdomid)
-        rc = libxl_console_exec(ctx, stubdomid,
-                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
-    else {
+    int rc = 0;
+
+    if (stubdomid) {
+        *domid = stubdomid;
+        *cons_num = STUBDOM_CONSOLE_SERIAL;
+        *type = LIBXL_CONSOLE_TYPE_PV;
+    } else {
         switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_SERIAL;
             break;
         case LIBXL_DOMAIN_TYPE_PV:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_PV;
             break;
         case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
-            rc = ERROR_FAIL;
+            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
+            rc = ERROR_INVAL;
             break;
         default:
             abort();
@@ -1242,6 +1300,31 @@ int libxl_primary_console_exec(libxl_ctx
     return rc;
 }
 
+int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_exec(ctx, domid, cons_num, type);
+}
+
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
+                                  char **path)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_get_tty(ctx, domid, cons_num, type, path);
+}
+
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
     GC_INIT(ctx);
diff -r d7318231cfe3 -r 3496f86000b8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl.h	Fri Jun 01 15:10:45 2012 +0800
@@ -570,6 +570,18 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
 
+/* libxl_console_get_tty retrieves the specified domain's console tty path
+ * and stores it in path. Caller is responsible for freeing the memory.
+ */
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path);
+
+/* libxl_primary_console_get_tty retrieves the specified domain's primary 
+ * console tty path and stores it in path. Caller is responsible for freeing
+ * the memory.
+ */
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path);
+
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 07:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaMCr-0001SF-5N; Fri, 01 Jun 2012 07:23:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1SaMCp-0001S9-Dc
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 07:23:31 +0000
Received: from [85.158.143.35:41280] by server-2.bemta-4.messagelabs.com id
	FA/D3-11595-2FD68CF4; Fri, 01 Jun 2012 07:23:30 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1338535406!10377973!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7458 invoked from network); 1 Jun 2012 07:23:27 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-10.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 07:23:27 -0000
Received: from [127.0.0.1] ([::ffff:147.2.207.143])
	by mail.novell.com with ESMTP; Fri, 01 Jun 2012 01:23:12 -0600
MIME-Version: 1.0
X-Mercurial-Node: 3496f86000b80595b34a56390a5e269ef5d2bc44
Message-Id: <3496f86000b80595b34a.1338535311@linux-x12>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 01 Jun 2012 15:21:51 +0800
From: Bamvor Jian Zhang <bjzhang@suse.com>
To: xen-devel@lists.xen.org
Cc: jfehlig@suse.com, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	bjzhang@suse.com
Subject: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain console
	tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 api retrieve domain console from xenstore. With this new api, it is easy to implement "virsh console" command in libvirt libxl driver.

Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>

Changes since v2:
 * using ERROR_INVAL instead of ERROR_FAIL in libxl_console_get_tty and
 libxl__primary_console_find if need.
 * remove _out from some value name in libxl_primary_console_exec
 * add error handler and log message in libxl_console_get_tty.
 BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0, tty) will lead to null pointer access in CTX maco.
 * add empty line between my comment and other function.

diff -r d7318231cfe3 -r 3496f86000b8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl.c	Fri Jun 01 15:10:45 2012 +0800
@@ -1188,7 +1188,8 @@ out:
     return rc;
 }
 
-int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
+int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
+                       libxl_console_type type)
 {
     GC_INIT(ctx);
     char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
@@ -1214,25 +1215,82 @@ out:
     return ERROR_FAIL;
 }
 
-int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path)
+{
+    GC_INIT(ctx);
+    char *dom_path = 0;
+    char *tty_path = 0;
+    char *tty = 0;
+    int rc;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    switch (type) {
+    case LIBXL_CONSOLE_TYPE_SERIAL:
+        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
+        break;
+    case LIBXL_CONSOLE_TYPE_PV:
+        if (cons_num == 0)
+            tty_path = GCSPRINTF("%s/console/tty", dom_path);
+        else
+            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
+                                cons_num);
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+
+    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+    if (!tty) {
+       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
+       rc = ERROR_FAIL;
+       goto out;
+    }
+
+    *path = strdup(tty);
+    if (!*path)
+        libxl__alloc_failed(CTX, __func__, strlen(*path), 1);
+
+    rc = 0;
+
+out:
+    GC_FREE;
+    return rc;
+}
+
+static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
+                                       uint32_t *domid, int *cons_num, 
+                                       libxl_console_type *type)
 {
     GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
-    int rc;
-    if (stubdomid)
-        rc = libxl_console_exec(ctx, stubdomid,
-                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
-    else {
+    int rc = 0;
+
+    if (stubdomid) {
+        *domid = stubdomid;
+        *cons_num = STUBDOM_CONSOLE_SERIAL;
+        *type = LIBXL_CONSOLE_TYPE_PV;
+    } else {
         switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_SERIAL;
             break;
         case LIBXL_DOMAIN_TYPE_PV:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_PV;
             break;
         case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
-            rc = ERROR_FAIL;
+            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
+            rc = ERROR_INVAL;
             break;
         default:
             abort();
@@ -1242,6 +1300,31 @@ int libxl_primary_console_exec(libxl_ctx
     return rc;
 }
 
+int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_exec(ctx, domid, cons_num, type);
+}
+
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
+                                  char **path)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_get_tty(ctx, domid, cons_num, type, path);
+}
+
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
     GC_INIT(ctx);
diff -r d7318231cfe3 -r 3496f86000b8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu May 31 10:18:52 2012 +0200
+++ b/tools/libxl/libxl.h	Fri Jun 01 15:10:45 2012 +0800
@@ -570,6 +570,18 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
 
+/* libxl_console_get_tty retrieves the specified domain's console tty path
+ * and stores it in path. Caller is responsible for freeing the memory.
+ */
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path);
+
+/* libxl_primary_console_get_tty retrieves the specified domain's primary 
+ * console tty path and stores it in path. Caller is responsible for freeing
+ * the memory.
+ */
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path);
+
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 07:45:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaMXJ-00025I-LT; Fri, 01 Jun 2012 07:44:41 +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 1SaMXH-00025C-WA
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 07:44:40 +0000
Received: from [193.109.254.147:51597] by server-4.bemta-14.messagelabs.com id
	81/E0-03148-7E278CF4; Fri, 01 Jun 2012 07:44:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338536677!4383571!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8590 invoked from network); 1 Jun 2012 07:44:38 -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; 1 Jun 2012 07:44:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 08:44:36 +0100
Message-Id: <4FC88F030200007800087B34@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 08:44:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
In-Reply-To: <20120531181712.GA19700@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.05.12 at 20:17, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The blkfront_remove part is .. that is going to take some surgery to do
> and I don't think I am going to be able to attempt that within the next 
> couple
> of weeks. So lets put that on the TODO list and just do this one?

That sounds okay to me.

> From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]

That's only partly true, since ...

> [v2: Add extra check in add_id_to_freelist]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
>  1 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 60eed4b..c7ef8a4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info 
> *info)
>  static void add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	BUG_ON(info->shadow[id].req.u.rw.id != id);
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> +	BUG_ON(info->shadow[id].request == NULL);

... there's now even two BUG_ON()s here. I would think these
checks should either happen at the call site, or the function
should return an error indication; in any case should these just
result in warnings just like the out-of-range check you added.

>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	const char *names[BLKIF_OP_DISCARD+1] = {

	static const char *const names[] = {

> +		"read" , "write", "barrier", "flush", "reserved", "discard"};

Perhaps using dedicated initializers would be preferable here?

> +
> +	if (op > BLKIF_OP_DISCARD)

	if (op >= ARRAY_SIZE(names))

(all three adjustments making future additions less intrusive -
they could be single-line then).

Jan

> +		return "unknown";
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -746,6 +757,18 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE) {
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			WARN(1, "%s: response to %s has incorrect id (%d)!\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			continue;
> +		}
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> @@ -758,8 +781,8 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -771,18 +794,14 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> -- 
> 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 Fri Jun 01 07:45:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaMXJ-00025I-LT; Fri, 01 Jun 2012 07:44:41 +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 1SaMXH-00025C-WA
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 07:44:40 +0000
Received: from [193.109.254.147:51597] by server-4.bemta-14.messagelabs.com id
	81/E0-03148-7E278CF4; Fri, 01 Jun 2012 07:44:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338536677!4383571!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8590 invoked from network); 1 Jun 2012 07:44:38 -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; 1 Jun 2012 07:44:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 08:44:36 +0100
Message-Id: <4FC88F030200007800087B34@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 08:44:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
In-Reply-To: <20120531181712.GA19700@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.05.12 at 20:17, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The blkfront_remove part is .. that is going to take some surgery to do
> and I don't think I am going to be able to attempt that within the next 
> couple
> of weeks. So lets put that on the TODO list and just do this one?

That sounds okay to me.

> From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]

That's only partly true, since ...

> [v2: Add extra check in add_id_to_freelist]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
>  1 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 60eed4b..c7ef8a4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info 
> *info)
>  static void add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	BUG_ON(info->shadow[id].req.u.rw.id != id);
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> +	BUG_ON(info->shadow[id].request == NULL);

... there's now even two BUG_ON()s here. I would think these
checks should either happen at the call site, or the function
should return an error indication; in any case should these just
result in warnings just like the out-of-range check you added.

>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	const char *names[BLKIF_OP_DISCARD+1] = {

	static const char *const names[] = {

> +		"read" , "write", "barrier", "flush", "reserved", "discard"};

Perhaps using dedicated initializers would be preferable here?

> +
> +	if (op > BLKIF_OP_DISCARD)

	if (op >= ARRAY_SIZE(names))

(all three adjustments making future additions less intrusive -
they could be single-line then).

Jan

> +		return "unknown";
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -746,6 +757,18 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE) {
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			WARN(1, "%s: response to %s has incorrect id (%d)!\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			continue;
> +		}
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> @@ -758,8 +781,8 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -771,18 +794,14 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> -- 
> 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 Fri Jun 01 07:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaMk8-0002K5-W5; Fri, 01 Jun 2012 07:57:56 +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 1SaMk7-0002K0-Lj
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 07:57:55 +0000
Received: from [85.158.143.35:5695] by server-2.bemta-4.messagelabs.com id
	73/DA-11595-20678CF4; Fri, 01 Jun 2012 07:57:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338537473!18384265!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjkwMTU4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27818 invoked from network); 1 Jun 2012 07:57:54 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 07:57:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 01 Jun 2012 00:57:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="150301491"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 01 Jun 2012 00:57:53 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 1 Jun 2012 00:57:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 15:57:52 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
Thread-Index: AQHNP17XM9HNPWGJrkGbs3SSikmUqJblFFsw
Date: Fri, 1 Jun 2012 07:57:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352010D2@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120531161139.GA13939@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923351FFB11@SHSMSX101.ccr.corp.intel.com>
	<20120531173137.GA31735@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923352000E2@SHSMSX101.ccr.corp.intel.com>
	<20120531185444.GA7557@phenom.dumpdata.com>
In-Reply-To: <20120531185444.GA7557@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>>> That's vMCE injection logic.
>>> 
>>> Are you sure about it? The comments in it speak of piggybacking on
>>> the native MCE handling routines. But since that is not used anymore
>>> do you need to use a different mechanism?
>> 
>> What is not used anymore? what's your concern about
>> cvt_gate_to_trap? I really confused here. Could you elaborate more?
> 
> Well, the mce.c is not involved anymore. So if it we are piggybacking
> on the native MCE handling routines - those routines
> (do_machine_check) won't deliever the data to your driver anymore?
> B/c the do_machine_check is doing mce_log which spools data. But your
> driver is using a different system to de-spool the data - and it does
> not use the mcelog structure array.

native mce is still there, we didn't mask it.
what is not used is native mce_log, w/ guest info (like guest address) when running at xen platform,
instead we use xen_mce_log, a self-contained logic getting real physical error info from xen hypervisor.
that's just what we expected.

> 
> .. snip.
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>> c/s a01ee165a132fadb57659d26246e340d6ac53265
>>> 
>>> Which I think the tree is based on too.
>> 
>> So it would not be stuck?
> 
> I've no idea what you mean here. Could you elaborate please?

What I meant here is, it should not meet confliction when you patched our patches to latest linus tree.
(Per my understanding, you meet confliction when patched, right? any misunderstanding please tell 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 Fri Jun 01 07:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 07: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 1SaMk8-0002K5-W5; Fri, 01 Jun 2012 07:57:56 +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 1SaMk7-0002K0-Lj
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 07:57:55 +0000
Received: from [85.158.143.35:5695] by server-2.bemta-4.messagelabs.com id
	73/DA-11595-20678CF4; Fri, 01 Jun 2012 07:57:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338537473!18384265!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjkwMTU4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27818 invoked from network); 1 Jun 2012 07:57:54 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 07:57:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 01 Jun 2012 00:57:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="150301491"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 01 Jun 2012 00:57:53 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 1 Jun 2012 00:57:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.94]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id
	14.01.0355.002; Fri, 1 Jun 2012 15:57:52 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
Thread-Index: AQHNP17XM9HNPWGJrkGbs3SSikmUqJblFFsw
Date: Fri, 1 Jun 2012 07:57:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352010D2@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120531161139.GA13939@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923351FFB11@SHSMSX101.ccr.corp.intel.com>
	<20120531173137.GA31735@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923352000E2@SHSMSX101.ccr.corp.intel.com>
	<20120531185444.GA7557@phenom.dumpdata.com>
In-Reply-To: <20120531185444.GA7557@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>>> That's vMCE injection logic.
>>> 
>>> Are you sure about it? The comments in it speak of piggybacking on
>>> the native MCE handling routines. But since that is not used anymore
>>> do you need to use a different mechanism?
>> 
>> What is not used anymore? what's your concern about
>> cvt_gate_to_trap? I really confused here. Could you elaborate more?
> 
> Well, the mce.c is not involved anymore. So if it we are piggybacking
> on the native MCE handling routines - those routines
> (do_machine_check) won't deliever the data to your driver anymore?
> B/c the do_machine_check is doing mce_log which spools data. But your
> driver is using a different system to de-spool the data - and it does
> not use the mcelog structure array.

native mce is still there, we didn't mask it.
what is not used is native mce_log, w/ guest info (like guest address) when running at xen platform,
instead we use xen_mce_log, a self-contained logic getting real physical error info from xen hypervisor.
that's just what we expected.

> 
> .. snip.
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>> c/s a01ee165a132fadb57659d26246e340d6ac53265
>>> 
>>> Which I think the tree is based on too.
>> 
>> So it would not be stuck?
> 
> I've no idea what you mean here. Could you elaborate please?

What I meant here is, it should not meet confliction when you patched our patches to latest linus tree.
(Per my understanding, you meet confliction when patched, right? any misunderstanding please tell 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 Fri Jun 01 08:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08:09: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 1SaMvR-000389-5F; Fri, 01 Jun 2012 08:09: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 1SaMvP-000384-Fn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 08:09:35 +0000
Received: from [85.158.138.51:36517] by server-12.bemta-3.messagelabs.com id
	72/3F-29860-EB878CF4; Fri, 01 Jun 2012 08:09:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1338538173!26238803!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1107 invoked from network); 1 Jun 2012 08:09:34 -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; 1 Jun 2012 08:09:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 09:09:33 +0100
Message-Id: <4FC894DB0200007800087B4D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 09:09:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zeinab Alebouyeh" <z.alebouyeh@gmail.com>
References: <CAE+SDMzKMVUdUGFSbuemuP-Nr52FKuocySwuCxN3qJ6wwJcxwA@mail.gmail.com>
In-Reply-To: <CAE+SDMzKMVUdUGFSbuemuP-Nr52FKuocySwuCxN3qJ6wwJcxwA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Disable paging in xen kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.06.12 at 08:04, Zeinab Alebouyeh <z.alebouyeh@gmail.com> wrote:
> I want to write a program in xen that runs in ring 0 and in unpaged
> protected mode.
> For this,  I add a hypercall and in my hypercall function write my code. I
> test my hypercall, it works properly.
> I see the value of CR0 register and I found that the PE and PG bits are 1.
> It means that I am in protected mode with paging enabled.
> In order to disable paging I want to set bit 31 of cr0 to 0, I write the
> bellowing code in my hypercall function:
> 
> asm volatile(
> "movl %cr0,%eax\n\t"
> "and 0x7fffffff,%eax\n\t"
> "movl %eax,%cr0"
> );
> But when I invoke my hypercall the system restart!!!

Of course, as this causes a triple fault without a lot of other
things taken care of.

> Can anyone tell me where is my fault and how should I disable paging in xen
> kernel?

Your fault is of conceptual nature - you just can't do what you're
intending to do in a pre-existing OS or OS-like environment. You
should instead consider to write your own OS-like environment
(started via some boot loader), where either you never enable
paging, or have a way to cleanly turn it off when you need to.

Jan


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08:09: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 1SaMvR-000389-5F; Fri, 01 Jun 2012 08:09: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 1SaMvP-000384-Fn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 08:09:35 +0000
Received: from [85.158.138.51:36517] by server-12.bemta-3.messagelabs.com id
	72/3F-29860-EB878CF4; Fri, 01 Jun 2012 08:09:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1338538173!26238803!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1107 invoked from network); 1 Jun 2012 08:09:34 -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; 1 Jun 2012 08:09:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 09:09:33 +0100
Message-Id: <4FC894DB0200007800087B4D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 09:09:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zeinab Alebouyeh" <z.alebouyeh@gmail.com>
References: <CAE+SDMzKMVUdUGFSbuemuP-Nr52FKuocySwuCxN3qJ6wwJcxwA@mail.gmail.com>
In-Reply-To: <CAE+SDMzKMVUdUGFSbuemuP-Nr52FKuocySwuCxN3qJ6wwJcxwA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Disable paging in xen kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.06.12 at 08:04, Zeinab Alebouyeh <z.alebouyeh@gmail.com> wrote:
> I want to write a program in xen that runs in ring 0 and in unpaged
> protected mode.
> For this,  I add a hypercall and in my hypercall function write my code. I
> test my hypercall, it works properly.
> I see the value of CR0 register and I found that the PE and PG bits are 1.
> It means that I am in protected mode with paging enabled.
> In order to disable paging I want to set bit 31 of cr0 to 0, I write the
> bellowing code in my hypercall function:
> 
> asm volatile(
> "movl %cr0,%eax\n\t"
> "and 0x7fffffff,%eax\n\t"
> "movl %eax,%cr0"
> );
> But when I invoke my hypercall the system restart!!!

Of course, as this causes a triple fault without a lot of other
things taken care of.

> Can anyone tell me where is my fault and how should I disable paging in xen
> kernel?

Your fault is of conceptual nature - you just can't do what you're
intending to do in a pre-existing OS or OS-like environment. You
should instead consider to write your own OS-like environment
(started via some boot loader), where either you never enable
paging, or have a way to cleanly turn it off when you need to.

Jan


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08:30: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 1SaNF6-0003JH-7J; Fri, 01 Jun 2012 08:29:56 +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 1SaNF4-0003JC-Hn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 08:29:54 +0000
Received: from [193.109.254.147:59209] by server-7.bemta-14.messagelabs.com id
	D1/AF-07635-18D78CF4; Fri, 01 Jun 2012 08:29:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1338539393!12292551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25987 invoked from network); 1 Jun 2012 08:29:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 08:29:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12780239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:29:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	09:29:52 +0100
Message-ID: <1338539390.17466.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 1 Jun 2012 09:29:50 +0100
In-Reply-To: <CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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 Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
> > The strange thing is that there *is* a pygrub in the right place, so
> > it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
> 
> It's seems that the right on the script are already set to 755 by the
> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.

What is the conclusion here? Is the original patch correct and/or is
there a subsequent additional fix?

My scripts does things like:
        make -C tools XEN_TARGET_ARCH=x86_32 DESTDIR=/tmp/tmp0_hnbt LIBXL_TESTIDL_SEED=42 debug=y -j12 install
then tars up /tmp/tmp0_hnbt, copies it to my test box and untars. I've
just noticed on my test box:
        # ls -dl /tmp/tmp* 
        drwxr-xr-x 3 root root 4096 Jun  1 09:26 /tmp/tmp0_hnbt
        drwxr-xr-x 3 root root 4096 May 18 11:11 /tmp/tmp8D2Mvc
        drwxr-xr-x 3 root root 4096 May 25 10:21 /tmp/tmpAd2OFq
        drwxr-xr-x 3 root root 4096 May 18 15:05 /tmp/tmpEqYZpf
        [...]
        # find /tmp/tmp* -name pygrub | wc -l 
        19
        
Oops!

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08:30: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 1SaNF6-0003JH-7J; Fri, 01 Jun 2012 08:29:56 +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 1SaNF4-0003JC-Hn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 08:29:54 +0000
Received: from [193.109.254.147:59209] by server-7.bemta-14.messagelabs.com id
	D1/AF-07635-18D78CF4; Fri, 01 Jun 2012 08:29:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1338539393!12292551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25987 invoked from network); 1 Jun 2012 08:29:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 08:29:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,696,1330905600"; d="scan'208";a="12780239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:29:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	09:29:52 +0100
Message-ID: <1338539390.17466.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 1 Jun 2012 09:29:50 +0100
In-Reply-To: <CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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 Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
> > The strange thing is that there *is* a pygrub in the right place, so
> > it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
> 
> It's seems that the right on the script are already set to 755 by the
> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.

What is the conclusion here? Is the original patch correct and/or is
there a subsequent additional fix?

My scripts does things like:
        make -C tools XEN_TARGET_ARCH=x86_32 DESTDIR=/tmp/tmp0_hnbt LIBXL_TESTIDL_SEED=42 debug=y -j12 install
then tars up /tmp/tmp0_hnbt, copies it to my test box and untars. I've
just noticed on my test box:
        # ls -dl /tmp/tmp* 
        drwxr-xr-x 3 root root 4096 Jun  1 09:26 /tmp/tmp0_hnbt
        drwxr-xr-x 3 root root 4096 May 18 11:11 /tmp/tmp8D2Mvc
        drwxr-xr-x 3 root root 4096 May 25 10:21 /tmp/tmpAd2OFq
        drwxr-xr-x 3 root root 4096 May 18 15:05 /tmp/tmpEqYZpf
        [...]
        # find /tmp/tmp* -name pygrub | wc -l 
        19
        
Oops!

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNHZ-0003QL-Us; Fri, 01 Jun 2012 08:32:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SaNHY-0003QD-SG
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 08:32:28 +0000
Received: from [193.109.254.147:43884] by server-8.bemta-14.messagelabs.com id
	A3/D8-04215-C1E78CF4; Fri, 01 Jun 2012 08:32:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338539537!12255106!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28578 invoked from network); 1 Jun 2012 08:32:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 08:32:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaNHM-000KOr-VR; Fri, 01 Jun 2012 08:32:16 +0000
Date: Fri, 1 Jun 2012 09:32:16 +0100
From: Tim Deegan <tim@xen.org>
To: ???? <zhangzhi2022@hotmail.com>
Message-ID: <20120601083216.GA77921@ocelot.phlegethon.org>
References: <20120531092326.GB62804@ocelot.phlegethon.org>
	<BLU147-W3164E67F10FCA98668A999CC0B0@phx.gbl>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BLU147-W3164E67F10FCA98668A999CC0B0@phx.gbl>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Copy-on write sharing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, 

Please don't drop the list from Cc.  I have put it back.

At 09:50 +0000 on 31 May (1338457855), ???? wrote:
> Hi, I just read about the source code (mainly the mem_sharing.c) that
> you mentioned before, but it seemed not like what I was looking for,
> and it doesn't make use of the rbtree for page sharing.

mem_sharing.c is just the mechanism for having two VMs share a page.
The choices of which pages to share are left to the tools.  As I said
the in-tree Xen tools don't currently have a good way to select pages to
share (though there are some out-of-tree users).

> I felt that the functionality of this mem_sharing.c file is not like
> the KSM(kernel samepage mechanism), which operates in the KVM(kernel
> virtual machine).

That's right.  KVM reuses linux's existing in-kernel mechanism for
finding and sharing suitable pages.

Tim.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNHZ-0003QL-Us; Fri, 01 Jun 2012 08:32:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SaNHY-0003QD-SG
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 08:32:28 +0000
Received: from [193.109.254.147:43884] by server-8.bemta-14.messagelabs.com id
	A3/D8-04215-C1E78CF4; Fri, 01 Jun 2012 08:32:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338539537!12255106!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28578 invoked from network); 1 Jun 2012 08:32:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 08:32:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaNHM-000KOr-VR; Fri, 01 Jun 2012 08:32:16 +0000
Date: Fri, 1 Jun 2012 09:32:16 +0100
From: Tim Deegan <tim@xen.org>
To: ???? <zhangzhi2022@hotmail.com>
Message-ID: <20120601083216.GA77921@ocelot.phlegethon.org>
References: <20120531092326.GB62804@ocelot.phlegethon.org>
	<BLU147-W3164E67F10FCA98668A999CC0B0@phx.gbl>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BLU147-W3164E67F10FCA98668A999CC0B0@phx.gbl>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Copy-on write sharing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, 

Please don't drop the list from Cc.  I have put it back.

At 09:50 +0000 on 31 May (1338457855), ???? wrote:
> Hi, I just read about the source code (mainly the mem_sharing.c) that
> you mentioned before, but it seemed not like what I was looking for,
> and it doesn't make use of the rbtree for page sharing.

mem_sharing.c is just the mechanism for having two VMs share a page.
The choices of which pages to share are left to the tools.  As I said
the in-tree Xen tools don't currently have a good way to select pages to
share (though there are some out-of-tree users).

> I felt that the functionality of this mem_sharing.c file is not like
> the KSM(kernel samepage mechanism), which operates in the KVM(kernel
> virtual machine).

That's right.  KVM reuses linux's existing in-kernel mechanism for
finding and sharing suitable pages.

Tim.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNTQ-0003uL-EN; Fri, 01 Jun 2012 08:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaNTO-0003uG-GG
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 08:44:42 +0000
Received: from [85.158.138.51:59625] by server-4.bemta-3.messagelabs.com id
	1A/33-32504-9F088CF4; Fri, 01 Jun 2012 08:44:41 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338540280!30322260!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3017 invoked from network); 1 Jun 2012 08:44:40 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 08:44:40 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78335615; Fri, 01 Jun 2012 10:44:40 +0200
Message-ID: <1338540279.31901.17.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 01 Jun 2012 10:44:39 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0698720075193277151=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0698720075193277151==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-1/PL893DS8ZKfdo9M+oe"


--=-1/PL893DS8ZKfdo9M+oe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 07:18 +0000, Zhang, Yang Z wrote:=20
> > > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > >
> > >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> > >          b_info->max_vcpus =3D l;
> > > -        b_info->cur_vcpus =3D (1 << l) - 1;
> > > +
> > > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > > +            exit(1);
> > > +        }
> > >
> > ... Do you mind explaining me what would have happened here without you=
r
> > previous patch, i.e., by just using the existing libxl_cpumap_alloc ?
> >
> > I might be wrong, but I was wondering whether it is worth changing the
> > interface like that for just this single case which saves, what, 1 to 3
> > bytes per domain?
> >=20
>=20
> It's ok to use existing libxl_cpumap_alloc(). But in my case, there is no=
 need to use the existing interface.
>
Ok.

> And, in future, there are some cases may not need to allocate max size cp=
umap too
> So it's better to extend the current interface.
>=20
Well, maybe... Who knows what future reserves ?!? :-D

Anyway, although I see your point, I really really dislike the new
parameter in libxl_cpumap_alloc(), but of course it is not something up
to me to decide, neither it is something I'd loose some sleep for. :-P

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-1/PL893DS8ZKfdo9M+oe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IgPcACgkQk4XaBE3IOsQvjgCgkac9C6GvYeL7BfovxiyIrlO/
o1QAnifY1Fi+s6fdlngClXyzB9qDxIsP
=rKrF
-----END PGP SIGNATURE-----

--=-1/PL893DS8ZKfdo9M+oe--



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

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

--===============0698720075193277151==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 08:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNTQ-0003uL-EN; Fri, 01 Jun 2012 08:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaNTO-0003uG-GG
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 08:44:42 +0000
Received: from [85.158.138.51:59625] by server-4.bemta-3.messagelabs.com id
	1A/33-32504-9F088CF4; Fri, 01 Jun 2012 08:44:41 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338540280!30322260!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3017 invoked from network); 1 Jun 2012 08:44:40 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 08:44:40 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78335615; Fri, 01 Jun 2012 10:44:40 +0200
Message-ID: <1338540279.31901.17.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 01 Jun 2012 10:44:39 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0698720075193277151=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0698720075193277151==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-1/PL893DS8ZKfdo9M+oe"


--=-1/PL893DS8ZKfdo9M+oe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 07:18 +0000, Zhang, Yang Z wrote:=20
> > > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > >
> > >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> > >          b_info->max_vcpus =3D l;
> > > -        b_info->cur_vcpus =3D (1 << l) - 1;
> > > +
> > > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > > +            exit(1);
> > > +        }
> > >
> > ... Do you mind explaining me what would have happened here without you=
r
> > previous patch, i.e., by just using the existing libxl_cpumap_alloc ?
> >
> > I might be wrong, but I was wondering whether it is worth changing the
> > interface like that for just this single case which saves, what, 1 to 3
> > bytes per domain?
> >=20
>=20
> It's ok to use existing libxl_cpumap_alloc(). But in my case, there is no=
 need to use the existing interface.
>
Ok.

> And, in future, there are some cases may not need to allocate max size cp=
umap too
> So it's better to extend the current interface.
>=20
Well, maybe... Who knows what future reserves ?!? :-D

Anyway, although I see your point, I really really dislike the new
parameter in libxl_cpumap_alloc(), but of course it is not something up
to me to decide, neither it is something I'd loose some sleep for. :-P

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-1/PL893DS8ZKfdo9M+oe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IgPcACgkQk4XaBE3IOsQvjgCgkac9C6GvYeL7BfovxiyIrlO/
o1QAnifY1Fi+s6fdlngClXyzB9qDxIsP
=rKrF
-----END PGP SIGNATURE-----

--=-1/PL893DS8ZKfdo9M+oe--



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

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

--===============0698720075193277151==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 08:45:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNUD-0003wi-S9; Fri, 01 Jun 2012 08:45: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 1SaNUC-0003wU-82
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 08:45:32 +0000
Received: from [85.158.139.83:60891] by server-9.bemta-5.messagelabs.com id
	58/F0-27779-B2188CF4; Fri, 01 Jun 2012 08:45:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338540330!28810952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4041 invoked from network); 1 Jun 2012 08:45:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 08:45:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12780723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:45:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	09:45:29 +0100
Message-ID: <1338540327.17466.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 1 Jun 2012 09:45:27 +0100
In-Reply-To: <1337962994-23573-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1205251712480.26786@kaball-desktop>
	<1337962994-23573-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/6] arm: implement event 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 Fri, 2012-05-25 at 17:23 +0100, Stefano Stabellini wrote:
> Implement vcpu_mark_events_pending using the vgic to inject PPI 31, that
> we reserve for Xen usage.
> In the future the interrupt used for event injection might be dynamic
> and could be written into the device tree.
> Otherwise it could be an SGI choosen by the guest and passed to Xen
> through an hypercall.

We need to resolve this one way or another before we commit to any ABI
(i.e. before we upstream any Linux patches depending on it), but lets
have this for now.

> 
> 
> Considering that:
> 
> - it is easy to determine if an event notification
> interrupt has already been EOI'd by the guest just looking at the
> evtchn_upcall_pending bit in the shared_info page;
> 
> - we can safely assume that there is at most one event notification
> interrupt pending at any time in any set of LR registers because we
> never inject more than a single event notification interrupt in one vcpu
> (see vcpu_mark_events_pending);
> 
> we can avoid requesting maintenance interrupts for
> VGIC_IRQ_EVTCHN_CALLBACK, provided that we check for event notification
> interrupts that need to be cleared in the following places:
> 
> - maintenance interrupt entry;
> 
> - gic_set_guest_irq;
> 
> that is every time we are about to write to an LR.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c |   11 +++++++++++
>  xen/arch/arm/dummy.S  |    1 -
>  xen/arch/arm/gic.c    |   40 +++++++++++++++++++++++++++++++++++++++-
>  xen/arch/arm/gic.h    |    3 +++
>  4 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 3a726c8..5702399 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -232,6 +232,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
>  {
>  }
>  
> +void vcpu_mark_events_pending(struct vcpu *v)
> +{
> +    int already_pending = test_and_set_bit(
> +        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> +
> +    if ( already_pending )
> +        return;
> +
> +    vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 8c6151c..016340c 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -27,7 +27,6 @@ DUMMY(arch_vcpu_reset);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_mark_events_pending);
>  DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index cdb4e4a..cc9d37b 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -37,6 +37,7 @@
>                                       + (GIC_CR_OFFSET & 0xfff)))
>  #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
>                                       + (GIC_HR_OFFSET & 0xfff)))
> +static void events_maintenance(struct vcpu *v);
>  
>  /* Global state */
>  static struct {
> @@ -46,6 +47,7 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t event_mask;
>      uint64_t lr_mask;
>      /* lr_pending is used to queue IRQs (struct pending_irq) that the
>       * vgic tried to inject in the guest (calling gic_set_guest_irq) but
> @@ -293,6 +295,7 @@ int __init gic_init(void)
>      gic_hyp_init();
>  
>      gic.lr_mask = 0ULL;
> +    gic.event_mask = 0ULL;
>      INIT_LIST_HEAD(&gic.lr_pending);
>  
>      spin_unlock(&gic.lock);
> @@ -392,9 +395,15 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>  static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> +    int maintenance_int = GICH_LR_MAINTENANCE_IRQ;
> +
>      BUG_ON(lr > nr_lrs);
> +
> +    if (virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK && nr_lrs > 1)
> +        maintenance_int = 0;
> +
>      GICH[GICH_LR + lr] = state |
> -        GICH_LR_MAINTENANCE_IRQ |
> +        maintenance_int |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
> @@ -405,6 +414,8 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>      int i;
>      struct pending_irq *iter, *n;
>  
> +    events_maintenance(current);
> +
>      spin_lock(&gic.lock);
>  
>      if ( list_empty(&gic.lr_pending) )
> @@ -412,6 +423,8 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>          i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
>          if (i < nr_lrs) {
>              set_bit(i, &gic.lr_mask);
> +            if ( virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK )
> +                set_bit(i, &gic.event_mask);
>              gic_set_lr(i, virtual_irq, state, priority);
>              goto out;
>          }
> @@ -515,12 +528,35 @@ void gicv_setup(struct domain *d)
>                          GIC_BASE_ADDRESS + GIC_VR_OFFSET);
>  }
>  
> +static void events_maintenance(struct vcpu *v)
> +{
> +    int i = 0;
> +    int already_pending = test_bit(0,
> +            (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> +
> +    if (!already_pending && gic.event_mask != 0) {
> +        spin_lock(&gic.lock);
> +        while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> +                        sizeof(uint64_t), i)) < sizeof(uint64_t)) {
> +
> +            GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +            clear_bit(i, &gic.event_mask);
> +
> +            i++;
> +        }
> +        spin_unlock(&gic.lock);
> +    }
> +}
> +
>  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
>      int i = 0, virq;
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> +    events_maintenance(current);
> +
>      while ((i = find_next_bit((const long unsigned int *) &eisr,
>                                sizeof(eisr), i)) < sizeof(eisr)) {
>          struct pending_irq *p;
> @@ -536,6 +572,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>              gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
>              list_del_init(&p->lr_queue);
>              set_bit(i, &gic.lr_mask);
> +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> +                set_bit(i, &gic.event_mask);
>          } else {
>              gic_inject_irq_stop();
>          }
> diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
> index 2c5922e..ff8d0a2 100644
> --- a/xen/arch/arm/gic.h
> +++ b/xen/arch/arm/gic.h
> @@ -121,6 +121,9 @@
>  #define GICH_LR_CPUID_SHIFT     9
>  #define GICH_VTR_NRLRGS         0x3f
>  
> +/* XXX: write this into the DT */
> +#define VGIC_IRQ_EVTCHN_CALLBACK 31
> +
>  extern int domain_vgic_init(struct domain *d);
>  extern int vcpu_vgic_init(struct vcpu *v);
>  extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:45:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNUD-0003wi-S9; Fri, 01 Jun 2012 08:45: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 1SaNUC-0003wU-82
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 08:45:32 +0000
Received: from [85.158.139.83:60891] by server-9.bemta-5.messagelabs.com id
	58/F0-27779-B2188CF4; Fri, 01 Jun 2012 08:45:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338540330!28810952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4041 invoked from network); 1 Jun 2012 08:45:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 08:45:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12780723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:45:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	09:45:29 +0100
Message-ID: <1338540327.17466.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 1 Jun 2012 09:45:27 +0100
In-Reply-To: <1337962994-23573-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1205251712480.26786@kaball-desktop>
	<1337962994-23573-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/6] arm: implement event 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 Fri, 2012-05-25 at 17:23 +0100, Stefano Stabellini wrote:
> Implement vcpu_mark_events_pending using the vgic to inject PPI 31, that
> we reserve for Xen usage.
> In the future the interrupt used for event injection might be dynamic
> and could be written into the device tree.
> Otherwise it could be an SGI choosen by the guest and passed to Xen
> through an hypercall.

We need to resolve this one way or another before we commit to any ABI
(i.e. before we upstream any Linux patches depending on it), but lets
have this for now.

> 
> 
> Considering that:
> 
> - it is easy to determine if an event notification
> interrupt has already been EOI'd by the guest just looking at the
> evtchn_upcall_pending bit in the shared_info page;
> 
> - we can safely assume that there is at most one event notification
> interrupt pending at any time in any set of LR registers because we
> never inject more than a single event notification interrupt in one vcpu
> (see vcpu_mark_events_pending);
> 
> we can avoid requesting maintenance interrupts for
> VGIC_IRQ_EVTCHN_CALLBACK, provided that we check for event notification
> interrupts that need to be cleared in the following places:
> 
> - maintenance interrupt entry;
> 
> - gic_set_guest_irq;
> 
> that is every time we are about to write to an LR.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c |   11 +++++++++++
>  xen/arch/arm/dummy.S  |    1 -
>  xen/arch/arm/gic.c    |   40 +++++++++++++++++++++++++++++++++++++++-
>  xen/arch/arm/gic.h    |    3 +++
>  4 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 3a726c8..5702399 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -232,6 +232,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
>  {
>  }
>  
> +void vcpu_mark_events_pending(struct vcpu *v)
> +{
> +    int already_pending = test_and_set_bit(
> +        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> +
> +    if ( already_pending )
> +        return;
> +
> +    vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 8c6151c..016340c 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -27,7 +27,6 @@ DUMMY(arch_vcpu_reset);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_mark_events_pending);
>  DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index cdb4e4a..cc9d37b 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -37,6 +37,7 @@
>                                       + (GIC_CR_OFFSET & 0xfff)))
>  #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
>                                       + (GIC_HR_OFFSET & 0xfff)))
> +static void events_maintenance(struct vcpu *v);
>  
>  /* Global state */
>  static struct {
> @@ -46,6 +47,7 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t event_mask;
>      uint64_t lr_mask;
>      /* lr_pending is used to queue IRQs (struct pending_irq) that the
>       * vgic tried to inject in the guest (calling gic_set_guest_irq) but
> @@ -293,6 +295,7 @@ int __init gic_init(void)
>      gic_hyp_init();
>  
>      gic.lr_mask = 0ULL;
> +    gic.event_mask = 0ULL;
>      INIT_LIST_HEAD(&gic.lr_pending);
>  
>      spin_unlock(&gic.lock);
> @@ -392,9 +395,15 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>  static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> +    int maintenance_int = GICH_LR_MAINTENANCE_IRQ;
> +
>      BUG_ON(lr > nr_lrs);
> +
> +    if (virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK && nr_lrs > 1)
> +        maintenance_int = 0;
> +
>      GICH[GICH_LR + lr] = state |
> -        GICH_LR_MAINTENANCE_IRQ |
> +        maintenance_int |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
> @@ -405,6 +414,8 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>      int i;
>      struct pending_irq *iter, *n;
>  
> +    events_maintenance(current);
> +
>      spin_lock(&gic.lock);
>  
>      if ( list_empty(&gic.lr_pending) )
> @@ -412,6 +423,8 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>          i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
>          if (i < nr_lrs) {
>              set_bit(i, &gic.lr_mask);
> +            if ( virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK )
> +                set_bit(i, &gic.event_mask);
>              gic_set_lr(i, virtual_irq, state, priority);
>              goto out;
>          }
> @@ -515,12 +528,35 @@ void gicv_setup(struct domain *d)
>                          GIC_BASE_ADDRESS + GIC_VR_OFFSET);
>  }
>  
> +static void events_maintenance(struct vcpu *v)
> +{
> +    int i = 0;
> +    int already_pending = test_bit(0,
> +            (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> +
> +    if (!already_pending && gic.event_mask != 0) {
> +        spin_lock(&gic.lock);
> +        while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> +                        sizeof(uint64_t), i)) < sizeof(uint64_t)) {
> +
> +            GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +            clear_bit(i, &gic.event_mask);
> +
> +            i++;
> +        }
> +        spin_unlock(&gic.lock);
> +    }
> +}
> +
>  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
>      int i = 0, virq;
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> +    events_maintenance(current);
> +
>      while ((i = find_next_bit((const long unsigned int *) &eisr,
>                                sizeof(eisr), i)) < sizeof(eisr)) {
>          struct pending_irq *p;
> @@ -536,6 +572,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>              gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
>              list_del_init(&p->lr_queue);
>              set_bit(i, &gic.lr_mask);
> +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> +                set_bit(i, &gic.event_mask);
>          } else {
>              gic_inject_irq_stop();
>          }
> diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
> index 2c5922e..ff8d0a2 100644
> --- a/xen/arch/arm/gic.h
> +++ b/xen/arch/arm/gic.h
> @@ -121,6 +121,9 @@
>  #define GICH_LR_CPUID_SHIFT     9
>  #define GICH_VTR_NRLRGS         0x3f
>  
> +/* XXX: write this into the DT */
> +#define VGIC_IRQ_EVTCHN_CALLBACK 31
> +
>  extern int domain_vgic_init(struct domain *d);
>  extern int vcpu_vgic_init(struct vcpu *v);
>  extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:59:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNgy-0004CJ-7B; Fri, 01 Jun 2012 08:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaNgw-0004CE-SZ
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 08:58:43 +0000
Received: from [85.158.143.35:59612] by server-1.bemta-4.messagelabs.com id
	0A/92-27869-24488CF4; Fri, 01 Jun 2012 08:58:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338541120!18396946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6218 invoked from network); 1 Jun 2012 08:58:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 08:58:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:58:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	09:58:40 +0100
Message-ID: <1338541118.17466.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 09:58:38 +0100
In-Reply-To: <1338540279.31901.17.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 09:44 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 07:18 +0000, Zhang, Yang Z wrote: 
> > > > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > > > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > > > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > > > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > > >
> > > >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> > > >          b_info->max_vcpus = l;
> > > > -        b_info->cur_vcpus = (1 << l) - 1;
> > > > +
> > > > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > > > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > > > +            exit(1);
> > > > +        }
> > > >
> > > ... Do you mind explaining me what would have happened here without your
> > > previous patch, i.e., by just using the existing libxl_cpumap_alloc ?
> > >
> > > I might be wrong, but I was wondering whether it is worth changing the
> > > interface like that for just this single case which saves, what, 1 to 3
> > > bytes per domain?
> > > 
> > 
> > It's ok to use existing libxl_cpumap_alloc(). But in my case, there is no need to use the existing interface.
> >
> Ok.
> 
> > And, in future, there are some cases may not need to allocate max size cpumap too
> > So it's better to extend the current interface.
> > 
> Well, maybe... Who knows what future reserves ?!? :-D
> 
> Anyway, although I see your point, I really really dislike the new
> parameter in libxl_cpumap_alloc(),

What about it do you dislike? The special meaning of 0 or its existence
at all?

> but of course it is not something up
> to me to decide, neither it is something I'd loose some sleep for. :-P

You could give vcpus > pcpus (dumb, but e.g. for debugging) and in that
case the existing libxl_cpumap_alloc behaviour (which sizes based on the
# of phys cpus) is incorrect. I suggested that rather than having
libxl_cpumap_alloc_size() we just combine this with the existing fn with
a new parameter.

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 08:59:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 08: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 1SaNgy-0004CJ-7B; Fri, 01 Jun 2012 08:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaNgw-0004CE-SZ
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 08:58:43 +0000
Received: from [85.158.143.35:59612] by server-1.bemta-4.messagelabs.com id
	0A/92-27869-24488CF4; Fri, 01 Jun 2012 08:58:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338541120!18396946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA2ODY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6218 invoked from network); 1 Jun 2012 08:58:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 08:58:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:58:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	09:58:40 +0100
Message-ID: <1338541118.17466.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 09:58:38 +0100
In-Reply-To: <1338540279.31901.17.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 09:44 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 07:18 +0000, Zhang, Yang Z wrote: 
> > > > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > > > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > > > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > > > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > > >
> > > >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> > > >          b_info->max_vcpus = l;
> > > > -        b_info->cur_vcpus = (1 << l) - 1;
> > > > +
> > > > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > > > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > > > +            exit(1);
> > > > +        }
> > > >
> > > ... Do you mind explaining me what would have happened here without your
> > > previous patch, i.e., by just using the existing libxl_cpumap_alloc ?
> > >
> > > I might be wrong, but I was wondering whether it is worth changing the
> > > interface like that for just this single case which saves, what, 1 to 3
> > > bytes per domain?
> > > 
> > 
> > It's ok to use existing libxl_cpumap_alloc(). But in my case, there is no need to use the existing interface.
> >
> Ok.
> 
> > And, in future, there are some cases may not need to allocate max size cpumap too
> > So it's better to extend the current interface.
> > 
> Well, maybe... Who knows what future reserves ?!? :-D
> 
> Anyway, although I see your point, I really really dislike the new
> parameter in libxl_cpumap_alloc(),

What about it do you dislike? The special meaning of 0 or its existence
at all?

> but of course it is not something up
> to me to decide, neither it is something I'd loose some sleep for. :-P

You could give vcpus > pcpus (dumb, but e.g. for debugging) and in that
case the existing libxl_cpumap_alloc behaviour (which sizes based on the
# of phys cpus) is incorrect. I suggested that rather than having
libxl_cpumap_alloc_size() we just combine this with the existing fn with
a new parameter.

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:08:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaNpo-0004cH-Dk; Fri, 01 Jun 2012 09:07:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaNpm-0004cC-Iv
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:07:50 +0000
Received: from [193.109.254.147:8410] by server-6.bemta-14.messagelabs.com id
	69/D7-10397-56688CF4; Fri, 01 Jun 2012 09:07:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338541652!7167215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25336 invoked from network); 1 Jun 2012 09:07:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:07:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781270"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:07:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:07:32 +0100
Message-ID: <1338541650.17466.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:07:30 +0100
In-Reply-To: <8656509f24ea8b17d1c2.1338482401@whitby.uk.xensource.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<8656509f24ea8b17d1c2.1338482401@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 6] arm: avoid memory write in switch to
	Hyp 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 Thu, 2012-05-31 at 17:40 +0100, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1338482127 -3600
> # Node ID 8656509f24ea8b17d1c2dabd67c710662f66d17f
> # Parent  05447f395c91029fb732142e36788cfa92374045
> arm: avoid memory write in switch to Hyp mode.
> 
> Assemble the new CPSR in registers instead.  It's slightly cleaner,
> And makes it possible to have a read-only text section.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 05447f395c91 -r 8656509f24ea xen/arch/arm/mode_switch.S
> --- a/xen/arch/arm/mode_switch.S	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/mode_switch.S	Thu May 31 17:35:27 2012 +0100
> @@ -66,11 +66,7 @@ enter_hyp_mode:
>  	mcr   CP32(r0, FCSEIDR)
>  	mcr   CP32(r0, CONTEXTIDR)
>  	/* FIXME: ought to reset some other NS control regs here */
> -	adr   r1, 1f                 /* Store return address */
> -	str   r3, [r1]               /* where we can use it for RFE */
> -	isb                          /* Ensure we see the stored address */
> -	rfeia r1                     /* Enter Hyp mode */
> -
> -1:	.word 0                      /* PC to enter Hyp mode at */
> -	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
> -
> +	mrs   r0, cpsr               /* Copy the CPSR */
> +	add   r0, r0, #0x4           /* 0x16 (Monitor) -> 0x1a (Hyp) */
> +	msr   spsr_cxsf, r0          /* into the SPSR */

Not that it matters much but I think this could have been sprs_c to just
update spsr[0:7] (which is all you wanted to touch). In fact I reckon
you could have just done:
	mov r0, #0x1a|SPSR_I|SPSR_F
	msr spsr_c, r0

Anyway, I'm going to apply regardless because I'm just nitpicking...

> +	movs  pc, r3                 /* Exception-return into Hyp mode */



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:08:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaNpo-0004cH-Dk; Fri, 01 Jun 2012 09:07:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaNpm-0004cC-Iv
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:07:50 +0000
Received: from [193.109.254.147:8410] by server-6.bemta-14.messagelabs.com id
	69/D7-10397-56688CF4; Fri, 01 Jun 2012 09:07:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338541652!7167215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25336 invoked from network); 1 Jun 2012 09:07:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:07:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781270"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:07:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:07:32 +0100
Message-ID: <1338541650.17466.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:07:30 +0100
In-Reply-To: <8656509f24ea8b17d1c2.1338482401@whitby.uk.xensource.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<8656509f24ea8b17d1c2.1338482401@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 6] arm: avoid memory write in switch to
	Hyp 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 Thu, 2012-05-31 at 17:40 +0100, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1338482127 -3600
> # Node ID 8656509f24ea8b17d1c2dabd67c710662f66d17f
> # Parent  05447f395c91029fb732142e36788cfa92374045
> arm: avoid memory write in switch to Hyp mode.
> 
> Assemble the new CPSR in registers instead.  It's slightly cleaner,
> And makes it possible to have a read-only text section.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 05447f395c91 -r 8656509f24ea xen/arch/arm/mode_switch.S
> --- a/xen/arch/arm/mode_switch.S	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/mode_switch.S	Thu May 31 17:35:27 2012 +0100
> @@ -66,11 +66,7 @@ enter_hyp_mode:
>  	mcr   CP32(r0, FCSEIDR)
>  	mcr   CP32(r0, CONTEXTIDR)
>  	/* FIXME: ought to reset some other NS control regs here */
> -	adr   r1, 1f                 /* Store return address */
> -	str   r3, [r1]               /* where we can use it for RFE */
> -	isb                          /* Ensure we see the stored address */
> -	rfeia r1                     /* Enter Hyp mode */
> -
> -1:	.word 0                      /* PC to enter Hyp mode at */
> -	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
> -
> +	mrs   r0, cpsr               /* Copy the CPSR */
> +	add   r0, r0, #0x4           /* 0x16 (Monitor) -> 0x1a (Hyp) */
> +	msr   spsr_cxsf, r0          /* into the SPSR */

Not that it matters much but I think this could have been sprs_c to just
update spsr[0:7] (which is all you wanted to touch). In fact I reckon
you could have just done:
	mov r0, #0x1a|SPSR_I|SPSR_F
	msr spsr_c, r0

Anyway, I'm going to apply regardless because I'm just nitpicking...

> +	movs  pc, r3                 /* Exception-return into Hyp mode */



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:18:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaNzo-0004sx-D3; Fri, 01 Jun 2012 09:18: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 1SaNzn-0004sn-7Q
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:18:11 +0000
Received: from [85.158.138.51:16579] by server-12.bemta-3.messagelabs.com id
	A2/57-29860-2D888CF4; Fri, 01 Jun 2012 09:18:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338542289!30380534!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23374 invoked from network); 1 Jun 2012 09:18:09 -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; 1 Jun 2012 09:18:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaNzk-000KWV-Vj; Fri, 01 Jun 2012 09:18:08 +0000
Date: Fri, 1 Jun 2012 10:18:08 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120601091808.GB77921@ocelot.phlegethon.org>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<8656509f24ea8b17d1c2.1338482401@whitby.uk.xensource.com>
	<1338541650.17466.39.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338541650.17466.39.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 3 of 6] arm: avoid memory write in switch to
	Hyp mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:07 +0100 on 01 Jun (1338545250), Ian Campbell wrote:
> > +	mrs   r0, cpsr               /* Copy the CPSR */
> > +	add   r0, r0, #0x4           /* 0x16 (Monitor) -> 0x1a (Hyp) */
> > +	msr   spsr_cxsf, r0          /* into the SPSR */
> 
> Not that it matters much but I think this could have been sprs_c to just
> update spsr[0:7] (which is all you wanted to touch). In fact I reckon
> you could have just done:
> 	mov r0, #0x1a|SPSR_I|SPSR_F
> 	msr spsr_c, r0

I considered that, but I don't think that anything in the path so far
will have initialised this mode's SPSR to a sensible value, and I didn't
want to accidentally turn on big-endian mode or some such.

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 Jun 01 09:18:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaNzo-0004sx-D3; Fri, 01 Jun 2012 09:18: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 1SaNzn-0004sn-7Q
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:18:11 +0000
Received: from [85.158.138.51:16579] by server-12.bemta-3.messagelabs.com id
	A2/57-29860-2D888CF4; Fri, 01 Jun 2012 09:18:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338542289!30380534!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23374 invoked from network); 1 Jun 2012 09:18:09 -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; 1 Jun 2012 09:18:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaNzk-000KWV-Vj; Fri, 01 Jun 2012 09:18:08 +0000
Date: Fri, 1 Jun 2012 10:18:08 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120601091808.GB77921@ocelot.phlegethon.org>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<8656509f24ea8b17d1c2.1338482401@whitby.uk.xensource.com>
	<1338541650.17466.39.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338541650.17466.39.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 3 of 6] arm: avoid memory write in switch to
	Hyp mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:07 +0100 on 01 Jun (1338545250), Ian Campbell wrote:
> > +	mrs   r0, cpsr               /* Copy the CPSR */
> > +	add   r0, r0, #0x4           /* 0x16 (Monitor) -> 0x1a (Hyp) */
> > +	msr   spsr_cxsf, r0          /* into the SPSR */
> 
> Not that it matters much but I think this could have been sprs_c to just
> update spsr[0:7] (which is all you wanted to touch). In fact I reckon
> you could have just done:
> 	mov r0, #0x1a|SPSR_I|SPSR_F
> 	msr spsr_c, r0

I considered that, but I don't think that anything in the path so far
will have initialised this mode's SPSR to a sensible value, and I didn't
want to accidentally turn on big-endian mode or some such.

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 Jun 01 09:18:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaNzx-0004ts-DH; Fri, 01 Jun 2012 09:18:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1SaNzw-0004ta-49
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:18:20 +0000
Received: from [85.158.143.99:20176] by server-1.bemta-4.messagelabs.com id
	9B/9D-27869-BD888CF4; Fri, 01 Jun 2012 09:18:19 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1338542297!25552236!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29816 invoked from network); 1 Jun 2012 09:18:18 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Jun 2012 09:18:18 -0000
Received: from mail102-db3-R.bigfish.com (10.3.81.236) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 09:17:47 +0000
Received: from mail102-db3 (localhost [127.0.0.1])	by
	mail102-db3-R.bigfish.com (Postfix) with ESMTP id 5BEE4180495;
	Fri,  1 Jun 2012 09:17:47 +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: 3
X-BigFish: VPS3(z37d5kzzz1202hzz8275bhz2dh668h839hd24he5bhf0ah)
Received: from mail102-db3 (localhost.localdomain [127.0.0.1]) by mail102-db3
	(MessageSwitch) id 1338542265218647_21183;
	Fri,  1 Jun 2012 09:17:45 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.235])	by
	mail102-db3.bigfish.com (Postfix) with ESMTP id 29D90340044;
	Fri,  1 Jun 2012 09:17:45 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 09:17:44 +0000
X-WSS-ID: 0M4XLU8-02-1TW-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 2045CC8153;	Fri,  1 Jun 2012 04:18:07 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 1 Jun 2012 04:18:30 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 1 Jun 2012 04:18:10 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	05:18:07 -0400
Received: from dosorca.osrc.amd.com (dosorca.osrc.amd.com [165.204.15.106])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B227749C20C;
	Fri,  1 Jun 2012 10:18:06 +0100 (BST)
From: Andre Przywara <andre.przywara@amd.com>
To: <hpa@zytor.com>, <konrad.wilk@oracle.com>
Date: Fri, 1 Jun 2012 11:26:36 +0200
Message-ID: <1338542796-40586-1-git-send-email-andre.przywara@amd.com>
X-Mailer: git-send-email 1.7.4.4
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] pvops/x86: remove hooks for {rd,
	wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 were paravirt_ops hooks for the full register set variant of
{rd,wr}msr_safe which are actually not used by anyone anymore.
Remove them to make the code cleaner and avoid silent breakages
when the pvops members were uninitialized.
This has been boot-tested natively and under Xen with PVOPS enabled
and disabled on one machine.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
 arch/x86/include/asm/paravirt.h       |   39 -------------------
 arch/x86/include/asm/paravirt_types.h |    2 -
 arch/x86/kernel/paravirt.c            |    2 -
 arch/x86/lib/msr-reg-export.c         |    4 +-
 arch/x86/lib/msr-reg.S                |   10 ++--
 arch/x86/xen/enlighten.c              |    2 -
 7 files changed, 35 insertions(+), 91 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 084ef95..81860cc 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned int msr,
 
 extern unsigned long long native_read_tsc(void);
 
-extern int native_rdmsr_safe_regs(u32 regs[8]);
-extern int native_wrmsr_safe_regs(u32 regs[8]);
+extern int rdmsr_safe_regs(u32 regs[8]);
+extern int wrmsr_safe_regs(u32 regs[8]);
 
 static __always_inline unsigned long long __native_read_tsc(void)
 {
@@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	return err;
 }
 
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = native_rdmsr_safe_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return native_wrmsr_safe_regs(gprs);
-}
-
-static inline int rdmsr_safe_regs(u32 regs[8])
-{
-	return native_rdmsr_safe_regs(regs);
-}
-
-static inline int wrmsr_safe_regs(u32 regs[8])
-{
-	return native_wrmsr_safe_regs(regs);
-}
-
 #define rdtscl(low)						\
 	((low) = (u32)__native_read_tsc())
 
@@ -248,6 +211,32 @@ do {                                                            \
 
 #endif	/* !CONFIG_PARAVIRT */
 
+static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
+{
+	u32 gprs[8] = { 0 };
+	int err;
+
+	gprs[1] = msr;
+	gprs[7] = 0x9c5a203a;
+
+	err = rdmsr_safe_regs(gprs);
+
+	*p = gprs[0] | ((u64)gprs[2] << 32);
+
+	return err;
+}
+
+static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
+{
+	u32 gprs[8] = { 0 };
+
+	gprs[0] = (u32)val;
+	gprs[1] = msr;
+	gprs[2] = val >> 32;
+	gprs[7] = 0x9c5a203a;
+
+	return wrmsr_safe_regs(gprs);
+}
 
 #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 6cbbabf..ebb0cdb 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int *err)
 	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
 }
 
-static inline int paravirt_rdmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
-}
-
 static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
 {
 	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
 }
 
-static inline int paravirt_wrmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
-}
-
 /* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2)			\
 do {						\
@@ -176,9 +166,6 @@ do {						\
 	_err;					\
 })
 
-#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
-#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
-
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
 	int err;
@@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	*p = paravirt_read_msr(msr, &err);
 	return err;
 }
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = paravirt_rdmsr_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return paravirt_wrmsr_regs(gprs);
-}
 
 static inline u64 paravirt_read_tsc(void)
 {
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..8613cbb 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -153,9 +153,7 @@ struct pv_cpu_ops {
 	/* MSR, PMC and TSR operations.
 	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
 	u64 (*read_msr)(unsigned int msr, int *err);
-	int (*rdmsr_regs)(u32 *regs);
 	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
-	int (*wrmsr_regs)(u32 *regs);
 
 	u64 (*read_tsc)(void);
 	u64 (*read_pmc)(int counter);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 9ce8859..17fff18 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
 #endif
 	.wbinvd = native_wbinvd,
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = native_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 	.read_tscp = native_read_tscp,
diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
index a311cc5..8d6ef78 100644
--- a/arch/x86/lib/msr-reg-export.c
+++ b/arch/x86/lib/msr-reg-export.c
@@ -1,5 +1,5 @@
 #include <linux/module.h>
 #include <asm/msr.h>
 
-EXPORT_SYMBOL(native_rdmsr_safe_regs);
-EXPORT_SYMBOL(native_wrmsr_safe_regs);
+EXPORT_SYMBOL(rdmsr_safe_regs);
+EXPORT_SYMBOL(wrmsr_safe_regs);
diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
index 69fa106..f6d13ee 100644
--- a/arch/x86/lib/msr-reg.S
+++ b/arch/x86/lib/msr-reg.S
@@ -6,13 +6,13 @@
 
 #ifdef CONFIG_X86_64
 /*
- * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
+ * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
  *
  * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
  *
  */
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushq_cfi %rbx
 	pushq_cfi %rbp
@@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #else /* X86_32 */
 
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushl_cfi %ebx
 	pushl_cfi %ebp
@@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #endif
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e74df95..60f1131 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.wbinvd = native_wbinvd,
 
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = xen_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
-- 
1.7.4.4



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:18:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaNzx-0004ts-DH; Fri, 01 Jun 2012 09:18:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1SaNzw-0004ta-49
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:18:20 +0000
Received: from [85.158.143.99:20176] by server-1.bemta-4.messagelabs.com id
	9B/9D-27869-BD888CF4; Fri, 01 Jun 2012 09:18:19 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1338542297!25552236!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29816 invoked from network); 1 Jun 2012 09:18:18 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Jun 2012 09:18:18 -0000
Received: from mail102-db3-R.bigfish.com (10.3.81.236) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 09:17:47 +0000
Received: from mail102-db3 (localhost [127.0.0.1])	by
	mail102-db3-R.bigfish.com (Postfix) with ESMTP id 5BEE4180495;
	Fri,  1 Jun 2012 09:17:47 +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: 3
X-BigFish: VPS3(z37d5kzzz1202hzz8275bhz2dh668h839hd24he5bhf0ah)
Received: from mail102-db3 (localhost.localdomain [127.0.0.1]) by mail102-db3
	(MessageSwitch) id 1338542265218647_21183;
	Fri,  1 Jun 2012 09:17:45 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.235])	by
	mail102-db3.bigfish.com (Postfix) with ESMTP id 29D90340044;
	Fri,  1 Jun 2012 09:17:45 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 09:17:44 +0000
X-WSS-ID: 0M4XLU8-02-1TW-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 2045CC8153;	Fri,  1 Jun 2012 04:18:07 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 1 Jun 2012 04:18:30 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 1 Jun 2012 04:18:10 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	05:18:07 -0400
Received: from dosorca.osrc.amd.com (dosorca.osrc.amd.com [165.204.15.106])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B227749C20C;
	Fri,  1 Jun 2012 10:18:06 +0100 (BST)
From: Andre Przywara <andre.przywara@amd.com>
To: <hpa@zytor.com>, <konrad.wilk@oracle.com>
Date: Fri, 1 Jun 2012 11:26:36 +0200
Message-ID: <1338542796-40586-1-git-send-email-andre.przywara@amd.com>
X-Mailer: git-send-email 1.7.4.4
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] pvops/x86: remove hooks for {rd,
	wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 were paravirt_ops hooks for the full register set variant of
{rd,wr}msr_safe which are actually not used by anyone anymore.
Remove them to make the code cleaner and avoid silent breakages
when the pvops members were uninitialized.
This has been boot-tested natively and under Xen with PVOPS enabled
and disabled on one machine.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
 arch/x86/include/asm/paravirt.h       |   39 -------------------
 arch/x86/include/asm/paravirt_types.h |    2 -
 arch/x86/kernel/paravirt.c            |    2 -
 arch/x86/lib/msr-reg-export.c         |    4 +-
 arch/x86/lib/msr-reg.S                |   10 ++--
 arch/x86/xen/enlighten.c              |    2 -
 7 files changed, 35 insertions(+), 91 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 084ef95..81860cc 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned int msr,
 
 extern unsigned long long native_read_tsc(void);
 
-extern int native_rdmsr_safe_regs(u32 regs[8]);
-extern int native_wrmsr_safe_regs(u32 regs[8]);
+extern int rdmsr_safe_regs(u32 regs[8]);
+extern int wrmsr_safe_regs(u32 regs[8]);
 
 static __always_inline unsigned long long __native_read_tsc(void)
 {
@@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	return err;
 }
 
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = native_rdmsr_safe_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return native_wrmsr_safe_regs(gprs);
-}
-
-static inline int rdmsr_safe_regs(u32 regs[8])
-{
-	return native_rdmsr_safe_regs(regs);
-}
-
-static inline int wrmsr_safe_regs(u32 regs[8])
-{
-	return native_wrmsr_safe_regs(regs);
-}
-
 #define rdtscl(low)						\
 	((low) = (u32)__native_read_tsc())
 
@@ -248,6 +211,32 @@ do {                                                            \
 
 #endif	/* !CONFIG_PARAVIRT */
 
+static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
+{
+	u32 gprs[8] = { 0 };
+	int err;
+
+	gprs[1] = msr;
+	gprs[7] = 0x9c5a203a;
+
+	err = rdmsr_safe_regs(gprs);
+
+	*p = gprs[0] | ((u64)gprs[2] << 32);
+
+	return err;
+}
+
+static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
+{
+	u32 gprs[8] = { 0 };
+
+	gprs[0] = (u32)val;
+	gprs[1] = msr;
+	gprs[2] = val >> 32;
+	gprs[7] = 0x9c5a203a;
+
+	return wrmsr_safe_regs(gprs);
+}
 
 #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 6cbbabf..ebb0cdb 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int *err)
 	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
 }
 
-static inline int paravirt_rdmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
-}
-
 static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
 {
 	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
 }
 
-static inline int paravirt_wrmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
-}
-
 /* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2)			\
 do {						\
@@ -176,9 +166,6 @@ do {						\
 	_err;					\
 })
 
-#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
-#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
-
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
 	int err;
@@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	*p = paravirt_read_msr(msr, &err);
 	return err;
 }
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = paravirt_rdmsr_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return paravirt_wrmsr_regs(gprs);
-}
 
 static inline u64 paravirt_read_tsc(void)
 {
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..8613cbb 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -153,9 +153,7 @@ struct pv_cpu_ops {
 	/* MSR, PMC and TSR operations.
 	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
 	u64 (*read_msr)(unsigned int msr, int *err);
-	int (*rdmsr_regs)(u32 *regs);
 	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
-	int (*wrmsr_regs)(u32 *regs);
 
 	u64 (*read_tsc)(void);
 	u64 (*read_pmc)(int counter);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 9ce8859..17fff18 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
 #endif
 	.wbinvd = native_wbinvd,
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = native_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 	.read_tscp = native_read_tscp,
diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
index a311cc5..8d6ef78 100644
--- a/arch/x86/lib/msr-reg-export.c
+++ b/arch/x86/lib/msr-reg-export.c
@@ -1,5 +1,5 @@
 #include <linux/module.h>
 #include <asm/msr.h>
 
-EXPORT_SYMBOL(native_rdmsr_safe_regs);
-EXPORT_SYMBOL(native_wrmsr_safe_regs);
+EXPORT_SYMBOL(rdmsr_safe_regs);
+EXPORT_SYMBOL(wrmsr_safe_regs);
diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
index 69fa106..f6d13ee 100644
--- a/arch/x86/lib/msr-reg.S
+++ b/arch/x86/lib/msr-reg.S
@@ -6,13 +6,13 @@
 
 #ifdef CONFIG_X86_64
 /*
- * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
+ * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
  *
  * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
  *
  */
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushq_cfi %rbx
 	pushq_cfi %rbp
@@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #else /* X86_32 */
 
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushl_cfi %ebx
 	pushl_cfi %ebp
@@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #endif
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e74df95..60f1131 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.wbinvd = native_wbinvd,
 
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = xen_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
-- 
1.7.4.4



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:20:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaO1u-0005FN-5k; Fri, 01 Jun 2012 09: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 1SaO1s-0005F3-72
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:20:20 +0000
Received: from [85.158.143.35:21173] by server-3.bemta-4.messagelabs.com id
	71/AE-04252-35988CF4; Fri, 01 Jun 2012 09:20:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338542411!15794659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28103 invoked from network); 1 Jun 2012 09:20:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:20:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:20:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:20:11 +0100
Message-ID: <1338542410.17466.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:20:10 +0100
In-Reply-To: <d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6 of 6] arm: Enable VFP at 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 Thu, 2012-05-31 at 17:40 +0100, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1338482127 -3600
> # Node ID d12d5fcf152bffda41de51f9919b3211d69f955b
> # Parent  9570c43c07f397d8d4a8e725698c17c10c034d80
> arm: Enable VFP at boot.

Thanks, this should mean I can remove
"cluster.cpu0.vfp-enable_at_reset=1" from my fast model cfg file!

... tries it... yes it works, sweeet!

> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/Rules.mk
> --- a/xen/arch/arm/Rules.mk	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/Rules.mk	Thu May 31 17:35:27 2012 +0100
> @@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili
>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>  endif
>  
> -CFLAGS += -march=armv7-a -mcpu=cortex-a15
> +CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp

This might have been worthy of a comment...

http://wiki.debian.org/ArmHardFloatPort has some discussion, including:
        * soft: Full software floating point. 
        * softfp: Use the FPU, but remain compatible with soft-float
        code. 
        * hard: Full hardware floating point. 

and "The combination of -mfpu=vfp and -mfloat-abi=hard is not available
in FSF GCC 4.4". (there's a reference to a TODO section which seems to
not exist anymore...). I think Debian's armhf does actually use hard
(the page seems to imply it)

Anyway softfp does seem like the right option, at least until
-mfloat-abi=hard. Since this is all internal to the hypervisor (guests
can do whatever they want, I'm happily running armhf binaries) I don't
think this is a big deal to change as and when the compiler will let us.

>  
>  # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
>  check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/setup.c
> --- a/xen/arch/arm/setup.c	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/setup.c	Thu May 31 17:35:27 2012 +0100
> @@ -36,6 +36,7 @@
>  #include <asm/page.h>
>  #include <asm/current.h>
>  #include <asm/setup.h>
> +#include <asm/vfp.h>
>  #include "gic.h"
>  
>  static __attribute_used__ void init_done(void)
> @@ -192,6 +193,8 @@ void __init start_xen(unsigned long boot
>  
>      processor_id();
>  
> +    enable_vfp();
> +
>      softirq_init();
>  
>      tasklet_subsys_init();
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/smpboot.c
> --- a/xen/arch/arm/smpboot.c	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/smpboot.c	Thu May 31 17:35:27 2012 +0100
> @@ -26,6 +26,7 @@
>  #include <xen/sched.h>
>  #include <xen/smp.h>
>  #include <xen/softirq.h>
> +#include <asm/vfp.h>
>  #include "gic.h"
>  
>  cpumask_t cpu_online_map;
> @@ -106,6 +107,8 @@ void __cpuinit start_secondary(unsigned 
>      WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
>  
>      mmu_init_secondary_cpu();
> +    enable_vfp();
> +
>      gic_init_secondary_cpu();
>      init_timer_interrupt();
>      gic_route_irqs();
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/include/asm-arm/vfp.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/xen/include/asm-arm/vfp.h	Thu May 31 17:35:27 2012 +0100
> @@ -0,0 +1,35 @@
> +#ifndef __ARM_VFP_H_
> +#define __ARM_VFP_H_
> +
> +#include <xen/types.h>
> +
> +#define FPEXC_EN (1u << 30)
> +
> +/* Save and restore FP state.
> + * Ought to be using the new vmrs/vmsr names, but older binutils has a
> + * bug where it only allows them to target fpscr (and not, say, fpexc). */
> +#define READ_FP(reg) ({                                 \
> +    uint32_t val;                                       \
> +    asm volatile ("fmrx %0, fp" #reg : "=r" (val));     \
> +    val; })
> +
> +#define WRITE_FP(reg, val) do {                         \
> +    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);
> +}
> +
> +#endif
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:20:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaO1u-0005FN-5k; Fri, 01 Jun 2012 09: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 1SaO1s-0005F3-72
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:20:20 +0000
Received: from [85.158.143.35:21173] by server-3.bemta-4.messagelabs.com id
	71/AE-04252-35988CF4; Fri, 01 Jun 2012 09:20:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338542411!15794659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28103 invoked from network); 1 Jun 2012 09:20:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:20:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:20:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:20:11 +0100
Message-ID: <1338542410.17466.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:20:10 +0100
In-Reply-To: <d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6 of 6] arm: Enable VFP at 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 Thu, 2012-05-31 at 17:40 +0100, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1338482127 -3600
> # Node ID d12d5fcf152bffda41de51f9919b3211d69f955b
> # Parent  9570c43c07f397d8d4a8e725698c17c10c034d80
> arm: Enable VFP at boot.

Thanks, this should mean I can remove
"cluster.cpu0.vfp-enable_at_reset=1" from my fast model cfg file!

... tries it... yes it works, sweeet!

> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/Rules.mk
> --- a/xen/arch/arm/Rules.mk	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/Rules.mk	Thu May 31 17:35:27 2012 +0100
> @@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili
>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>  endif
>  
> -CFLAGS += -march=armv7-a -mcpu=cortex-a15
> +CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp

This might have been worthy of a comment...

http://wiki.debian.org/ArmHardFloatPort has some discussion, including:
        * soft: Full software floating point. 
        * softfp: Use the FPU, but remain compatible with soft-float
        code. 
        * hard: Full hardware floating point. 

and "The combination of -mfpu=vfp and -mfloat-abi=hard is not available
in FSF GCC 4.4". (there's a reference to a TODO section which seems to
not exist anymore...). I think Debian's armhf does actually use hard
(the page seems to imply it)

Anyway softfp does seem like the right option, at least until
-mfloat-abi=hard. Since this is all internal to the hypervisor (guests
can do whatever they want, I'm happily running armhf binaries) I don't
think this is a big deal to change as and when the compiler will let us.

>  
>  # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
>  check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/setup.c
> --- a/xen/arch/arm/setup.c	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/setup.c	Thu May 31 17:35:27 2012 +0100
> @@ -36,6 +36,7 @@
>  #include <asm/page.h>
>  #include <asm/current.h>
>  #include <asm/setup.h>
> +#include <asm/vfp.h>
>  #include "gic.h"
>  
>  static __attribute_used__ void init_done(void)
> @@ -192,6 +193,8 @@ void __init start_xen(unsigned long boot
>  
>      processor_id();
>  
> +    enable_vfp();
> +
>      softirq_init();
>  
>      tasklet_subsys_init();
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/smpboot.c
> --- a/xen/arch/arm/smpboot.c	Thu May 31 17:35:27 2012 +0100
> +++ b/xen/arch/arm/smpboot.c	Thu May 31 17:35:27 2012 +0100
> @@ -26,6 +26,7 @@
>  #include <xen/sched.h>
>  #include <xen/smp.h>
>  #include <xen/softirq.h>
> +#include <asm/vfp.h>
>  #include "gic.h"
>  
>  cpumask_t cpu_online_map;
> @@ -106,6 +107,8 @@ void __cpuinit start_secondary(unsigned 
>      WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
>  
>      mmu_init_secondary_cpu();
> +    enable_vfp();
> +
>      gic_init_secondary_cpu();
>      init_timer_interrupt();
>      gic_route_irqs();
> diff -r 9570c43c07f3 -r d12d5fcf152b xen/include/asm-arm/vfp.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/xen/include/asm-arm/vfp.h	Thu May 31 17:35:27 2012 +0100
> @@ -0,0 +1,35 @@
> +#ifndef __ARM_VFP_H_
> +#define __ARM_VFP_H_
> +
> +#include <xen/types.h>
> +
> +#define FPEXC_EN (1u << 30)
> +
> +/* Save and restore FP state.
> + * Ought to be using the new vmrs/vmsr names, but older binutils has a
> + * bug where it only allows them to target fpscr (and not, say, fpexc). */
> +#define READ_FP(reg) ({                                 \
> +    uint32_t val;                                       \
> +    asm volatile ("fmrx %0, fp" #reg : "=r" (val));     \
> +    val; })
> +
> +#define WRITE_FP(reg, val) do {                         \
> +    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);
> +}
> +
> +#endif
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:29:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOAj-0005nq-DK; Fri, 01 Jun 2012 09:29: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 1SaOAi-0005nk-LP
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:29:28 +0000
Received: from [193.109.254.147:5944] by server-10.bemta-14.messagelabs.com id
	F4/E3-27843-77B88CF4; Fri, 01 Jun 2012 09:29:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338542966!4637298!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23159 invoked from network); 1 Jun 2012 09:29:27 -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; 1 Jun 2012 09:29:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaOAg-000KZO-E8; Fri, 01 Jun 2012 09:29:26 +0000
Date: Fri, 1 Jun 2012 10:29:26 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120601092926.GC77921@ocelot.phlegethon.org>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
	<1338542410.17466.46.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338542410.17466.46.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 6 of 6] arm: Enable VFP at 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

At 10:20 +0100 on 01 Jun (1338546010), Ian Campbell wrote:
> > -CFLAGS += -march=armv7-a -mcpu=cortex-a15
> > +CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
> 
> This might have been worthy of a comment...

Ah, yes it might.  Would you like me to add one and resubmit?

If I get time next week I'm going to look at VFP context switching; at
that point I might move all the VFP code into its own .c or .S file and
enable the fpu instructions just there, to be sure that gcc doesn't
start using the VFP registers in normal Xen code -- it will do that for
integer arithmetic with -mfpu=neon, for example.  OTOH it might be
OK to do that as long as there are no caller-save VFP registers; I'll
have a look at the calling conventions and see what can be done.

Tim.

> http://wiki.debian.org/ArmHardFloatPort has some discussion, including:
>         * soft: Full software floating point. 
>         * softfp: Use the FPU, but remain compatible with soft-float
>         code. 
>         * hard: Full hardware floating point. 
> 
> and "The combination of -mfpu=vfp and -mfloat-abi=hard is not available
> in FSF GCC 4.4". (there's a reference to a TODO section which seems to
> not exist anymore...). I think Debian's armhf does actually use hard
> (the page seems to imply it)
> 
> Anyway softfp does seem like the right option, at least until
> -mfloat-abi=hard. Since this is all internal to the hypervisor (guests
> can do whatever they want, I'm happily running armhf binaries) I don't
> think this is a big deal to change as and when the compiler will let us.
> 

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:29:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOAj-0005nq-DK; Fri, 01 Jun 2012 09:29: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 1SaOAi-0005nk-LP
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:29:28 +0000
Received: from [193.109.254.147:5944] by server-10.bemta-14.messagelabs.com id
	F4/E3-27843-77B88CF4; Fri, 01 Jun 2012 09:29:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338542966!4637298!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23159 invoked from network); 1 Jun 2012 09:29:27 -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; 1 Jun 2012 09:29:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaOAg-000KZO-E8; Fri, 01 Jun 2012 09:29:26 +0000
Date: Fri, 1 Jun 2012 10:29:26 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120601092926.GC77921@ocelot.phlegethon.org>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
	<1338542410.17466.46.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338542410.17466.46.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 6 of 6] arm: Enable VFP at 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

At 10:20 +0100 on 01 Jun (1338546010), Ian Campbell wrote:
> > -CFLAGS += -march=armv7-a -mcpu=cortex-a15
> > +CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
> 
> This might have been worthy of a comment...

Ah, yes it might.  Would you like me to add one and resubmit?

If I get time next week I'm going to look at VFP context switching; at
that point I might move all the VFP code into its own .c or .S file and
enable the fpu instructions just there, to be sure that gcc doesn't
start using the VFP registers in normal Xen code -- it will do that for
integer arithmetic with -mfpu=neon, for example.  OTOH it might be
OK to do that as long as there are no caller-save VFP registers; I'll
have a look at the calling conventions and see what can be done.

Tim.

> http://wiki.debian.org/ArmHardFloatPort has some discussion, including:
>         * soft: Full software floating point. 
>         * softfp: Use the FPU, but remain compatible with soft-float
>         code. 
>         * hard: Full hardware floating point. 
> 
> and "The combination of -mfpu=vfp and -mfloat-abi=hard is not available
> in FSF GCC 4.4". (there's a reference to a TODO section which seems to
> not exist anymore...). I think Debian's armhf does actually use hard
> (the page seems to imply it)
> 
> Anyway softfp does seem like the right option, at least until
> -mfloat-abi=hard. Since this is all internal to the hypervisor (guests
> can do whatever they want, I'm happily running armhf binaries) I don't
> think this is a big deal to change as and when the compiler will let us.
> 

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:31:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOBt-0005sI-Rw; Fri, 01 Jun 2012 09:30: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 1SaOBs-0005s2-61
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:30:40 +0000
Received: from [85.158.139.83:37704] by server-2.bemta-5.messagelabs.com id
	65/D6-09957-FBB88CF4; Fri, 01 Jun 2012 09:30:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338543037!30013724!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20876 invoked from network); 1 Jun 2012 09:30:38 -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; 1 Jun 2012 09:30:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 10:30:37 +0100
Message-Id: <4FC8A7DC0200007800087BBC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 10:30:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andre Przywara" <andre.przywara@amd.com>,
	<konrad.wilk@oracle.com>,<hpa@zytor.com>
References: <1338542796-40586-1-git-send-email-andre.przywara@amd.com>
In-Reply-To: <1338542796-40586-1-git-send-email-andre.przywara@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] pvops/x86: remove hooks for {rd,
 wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:26, Andre Przywara <andre.przywara@amd.com> wrote:
> There were paravirt_ops hooks for the full register set variant of
> {rd,wr}msr_safe which are actually not used by anyone anymore.
> Remove them to make the code cleaner and avoid silent breakages
> when the pvops members were uninitialized.
> This has been boot-tested natively and under Xen with PVOPS enabled
> and disabled on one machine.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
>  arch/x86/include/asm/paravirt.h       |   39 -------------------
>  arch/x86/include/asm/paravirt_types.h |    2 -
>  arch/x86/kernel/paravirt.c            |    2 -
>  arch/x86/lib/msr-reg-export.c         |    4 +-
>  arch/x86/lib/msr-reg.S                |   10 ++--
>  arch/x86/xen/enlighten.c              |    2 -
>  7 files changed, 35 insertions(+), 91 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 084ef95..81860cc 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned 
> int msr,
>  
>  extern unsigned long long native_read_tsc(void);
>  
> -extern int native_rdmsr_safe_regs(u32 regs[8]);
> -extern int native_wrmsr_safe_regs(u32 regs[8]);
> +extern int rdmsr_safe_regs(u32 regs[8]);
> +extern int wrmsr_safe_regs(u32 regs[8]);
>  
>  static __always_inline unsigned long long __native_read_tsc(void)
>  {
> @@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned 
> long long *p)
>  	return err;
>  }
>  
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = native_rdmsr_safe_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return native_wrmsr_safe_regs(gprs);
> -}
> -
> -static inline int rdmsr_safe_regs(u32 regs[8])
> -{
> -	return native_rdmsr_safe_regs(regs);
> -}
> -
> -static inline int wrmsr_safe_regs(u32 regs[8])
> -{
> -	return native_wrmsr_safe_regs(regs);
> -}
> -
>  #define rdtscl(low)						\
>  	((low) = (u32)__native_read_tsc())
>  
> @@ -248,6 +211,32 @@ do {                                                     
>        \
>  
>  #endif	/* !CONFIG_PARAVIRT */
>  
> +static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> +{
> +	u32 gprs[8] = { 0 };
> +	int err;
> +
> +	gprs[1] = msr;
> +	gprs[7] = 0x9c5a203a;
> +
> +	err = rdmsr_safe_regs(gprs);
> +
> +	*p = gprs[0] | ((u64)gprs[2] << 32);
> +
> +	return err;
> +}
> +
> +static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> +{
> +	u32 gprs[8] = { 0 };
> +
> +	gprs[0] = (u32)val;
> +	gprs[1] = msr;
> +	gprs[2] = val >> 32;
> +	gprs[7] = 0x9c5a203a;
> +
> +	return wrmsr_safe_regs(gprs);
> +}
>  
>  #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
>  					     (u32)((val) >> 32))
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 6cbbabf..ebb0cdb 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int 
> *err)
>  	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
>  }
>  
> -static inline int paravirt_rdmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
> -}
> -
>  static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned 
> high)
>  {
>  	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
>  }
>  
> -static inline int paravirt_wrmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
> -}
> -
>  /* These should all do BUG_ON(_err), but our headers are too tangled. */
>  #define rdmsr(msr, val1, val2)			\
>  do {						\
> @@ -176,9 +166,6 @@ do {						\
>  	_err;					\
>  })
>  
> -#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
> -#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
> -
>  static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  {
>  	int err;
> @@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned 
> long long *p)
>  	*p = paravirt_read_msr(msr, &err);
>  	return err;
>  }
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = paravirt_rdmsr_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return paravirt_wrmsr_regs(gprs);
> -}
>  
>  static inline u64 paravirt_read_tsc(void)
>  {
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..8613cbb 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -153,9 +153,7 @@ struct pv_cpu_ops {
>  	/* MSR, PMC and TSR operations.
>  	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
>  	u64 (*read_msr)(unsigned int msr, int *err);
> -	int (*rdmsr_regs)(u32 *regs);
>  	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
> -	int (*wrmsr_regs)(u32 *regs);
>  
>  	u64 (*read_tsc)(void);
>  	u64 (*read_pmc)(int counter);
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index 9ce8859..17fff18 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
>  #endif
>  	.wbinvd = native_wbinvd,
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = native_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
>  	.read_tscp = native_read_tscp,
> diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
> index a311cc5..8d6ef78 100644
> --- a/arch/x86/lib/msr-reg-export.c
> +++ b/arch/x86/lib/msr-reg-export.c
> @@ -1,5 +1,5 @@
>  #include <linux/module.h>
>  #include <asm/msr.h>
>  
> -EXPORT_SYMBOL(native_rdmsr_safe_regs);
> -EXPORT_SYMBOL(native_wrmsr_safe_regs);
> +EXPORT_SYMBOL(rdmsr_safe_regs);
> +EXPORT_SYMBOL(wrmsr_safe_regs);
> diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
> index 69fa106..f6d13ee 100644
> --- a/arch/x86/lib/msr-reg.S
> +++ b/arch/x86/lib/msr-reg.S
> @@ -6,13 +6,13 @@
>  
>  #ifdef CONFIG_X86_64
>  /*
> - * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
> + * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
>   *
>   * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
>   *
>   */
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushq_cfi %rbx
>  	pushq_cfi %rbp
> @@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #else /* X86_32 */
>  
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushl_cfi %ebx
>  	pushl_cfi %ebp
> @@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #endif
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e74df95..60f1131 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst 
> = {
>  	.wbinvd = native_wbinvd,
>  
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = xen_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
> -- 
> 1.7.4.4
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 01 09:31:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOBt-0005sI-Rw; Fri, 01 Jun 2012 09:30: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 1SaOBs-0005s2-61
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:30:40 +0000
Received: from [85.158.139.83:37704] by server-2.bemta-5.messagelabs.com id
	65/D6-09957-FBB88CF4; Fri, 01 Jun 2012 09:30:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338543037!30013724!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20876 invoked from network); 1 Jun 2012 09:30:38 -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; 1 Jun 2012 09:30:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 10:30:37 +0100
Message-Id: <4FC8A7DC0200007800087BBC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 10:30:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andre Przywara" <andre.przywara@amd.com>,
	<konrad.wilk@oracle.com>,<hpa@zytor.com>
References: <1338542796-40586-1-git-send-email-andre.przywara@amd.com>
In-Reply-To: <1338542796-40586-1-git-send-email-andre.przywara@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] pvops/x86: remove hooks for {rd,
 wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:26, Andre Przywara <andre.przywara@amd.com> wrote:
> There were paravirt_ops hooks for the full register set variant of
> {rd,wr}msr_safe which are actually not used by anyone anymore.
> Remove them to make the code cleaner and avoid silent breakages
> when the pvops members were uninitialized.
> This has been boot-tested natively and under Xen with PVOPS enabled
> and disabled on one machine.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
>  arch/x86/include/asm/paravirt.h       |   39 -------------------
>  arch/x86/include/asm/paravirt_types.h |    2 -
>  arch/x86/kernel/paravirt.c            |    2 -
>  arch/x86/lib/msr-reg-export.c         |    4 +-
>  arch/x86/lib/msr-reg.S                |   10 ++--
>  arch/x86/xen/enlighten.c              |    2 -
>  7 files changed, 35 insertions(+), 91 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 084ef95..81860cc 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned 
> int msr,
>  
>  extern unsigned long long native_read_tsc(void);
>  
> -extern int native_rdmsr_safe_regs(u32 regs[8]);
> -extern int native_wrmsr_safe_regs(u32 regs[8]);
> +extern int rdmsr_safe_regs(u32 regs[8]);
> +extern int wrmsr_safe_regs(u32 regs[8]);
>  
>  static __always_inline unsigned long long __native_read_tsc(void)
>  {
> @@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned 
> long long *p)
>  	return err;
>  }
>  
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = native_rdmsr_safe_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return native_wrmsr_safe_regs(gprs);
> -}
> -
> -static inline int rdmsr_safe_regs(u32 regs[8])
> -{
> -	return native_rdmsr_safe_regs(regs);
> -}
> -
> -static inline int wrmsr_safe_regs(u32 regs[8])
> -{
> -	return native_wrmsr_safe_regs(regs);
> -}
> -
>  #define rdtscl(low)						\
>  	((low) = (u32)__native_read_tsc())
>  
> @@ -248,6 +211,32 @@ do {                                                     
>        \
>  
>  #endif	/* !CONFIG_PARAVIRT */
>  
> +static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> +{
> +	u32 gprs[8] = { 0 };
> +	int err;
> +
> +	gprs[1] = msr;
> +	gprs[7] = 0x9c5a203a;
> +
> +	err = rdmsr_safe_regs(gprs);
> +
> +	*p = gprs[0] | ((u64)gprs[2] << 32);
> +
> +	return err;
> +}
> +
> +static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> +{
> +	u32 gprs[8] = { 0 };
> +
> +	gprs[0] = (u32)val;
> +	gprs[1] = msr;
> +	gprs[2] = val >> 32;
> +	gprs[7] = 0x9c5a203a;
> +
> +	return wrmsr_safe_regs(gprs);
> +}
>  
>  #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
>  					     (u32)((val) >> 32))
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 6cbbabf..ebb0cdb 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int 
> *err)
>  	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
>  }
>  
> -static inline int paravirt_rdmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
> -}
> -
>  static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned 
> high)
>  {
>  	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
>  }
>  
> -static inline int paravirt_wrmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
> -}
> -
>  /* These should all do BUG_ON(_err), but our headers are too tangled. */
>  #define rdmsr(msr, val1, val2)			\
>  do {						\
> @@ -176,9 +166,6 @@ do {						\
>  	_err;					\
>  })
>  
> -#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
> -#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
> -
>  static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  {
>  	int err;
> @@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned 
> long long *p)
>  	*p = paravirt_read_msr(msr, &err);
>  	return err;
>  }
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = paravirt_rdmsr_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return paravirt_wrmsr_regs(gprs);
> -}
>  
>  static inline u64 paravirt_read_tsc(void)
>  {
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..8613cbb 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -153,9 +153,7 @@ struct pv_cpu_ops {
>  	/* MSR, PMC and TSR operations.
>  	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
>  	u64 (*read_msr)(unsigned int msr, int *err);
> -	int (*rdmsr_regs)(u32 *regs);
>  	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
> -	int (*wrmsr_regs)(u32 *regs);
>  
>  	u64 (*read_tsc)(void);
>  	u64 (*read_pmc)(int counter);
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index 9ce8859..17fff18 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
>  #endif
>  	.wbinvd = native_wbinvd,
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = native_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
>  	.read_tscp = native_read_tscp,
> diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
> index a311cc5..8d6ef78 100644
> --- a/arch/x86/lib/msr-reg-export.c
> +++ b/arch/x86/lib/msr-reg-export.c
> @@ -1,5 +1,5 @@
>  #include <linux/module.h>
>  #include <asm/msr.h>
>  
> -EXPORT_SYMBOL(native_rdmsr_safe_regs);
> -EXPORT_SYMBOL(native_wrmsr_safe_regs);
> +EXPORT_SYMBOL(rdmsr_safe_regs);
> +EXPORT_SYMBOL(wrmsr_safe_regs);
> diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
> index 69fa106..f6d13ee 100644
> --- a/arch/x86/lib/msr-reg.S
> +++ b/arch/x86/lib/msr-reg.S
> @@ -6,13 +6,13 @@
>  
>  #ifdef CONFIG_X86_64
>  /*
> - * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
> + * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
>   *
>   * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
>   *
>   */
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushq_cfi %rbx
>  	pushq_cfi %rbp
> @@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #else /* X86_32 */
>  
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushl_cfi %ebx
>  	pushl_cfi %ebp
> @@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #endif
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e74df95..60f1131 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst 
> = {
>  	.wbinvd = native_wbinvd,
>  
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = xen_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
> -- 
> 1.7.4.4
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 01 09:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaODX-000654-Bp; Fri, 01 Jun 2012 09:32: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 1SaODW-00064v-9k
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:32:22 +0000
Received: from [193.109.254.147:11401] by server-11.bemta-14.messagelabs.com
	id 20/E3-01965-52C88CF4; Fri, 01 Jun 2012 09:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338543139!4637994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6121 invoked from network); 1 Jun 2012 09:32:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:31:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:31:31 +0100
Message-ID: <1338543090.17466.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 1 Jun 2012 10:31:30 +0100
In-Reply-To: <alpine.DEB.2.00.1205251712480.26786@kaball-desktop>
References: <alpine.DEB.2.00.1205251712480.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] xen/arm: event channels and
	shared_info page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-05-25 at 17:21 +0100, Stefano Stabellini wrote:
> this patch series implements support for injecting event channels into
> the guest and enables a wider range of hypercalls for ARM guests.

I've actually been running with the previous iteration of these patches
in my tree for ages now, so they are actually pretty well tested by me.

So I've acked+applied them...

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaODX-000654-Bp; Fri, 01 Jun 2012 09:32: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 1SaODW-00064v-9k
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:32:22 +0000
Received: from [193.109.254.147:11401] by server-11.bemta-14.messagelabs.com
	id 20/E3-01965-52C88CF4; Fri, 01 Jun 2012 09:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338543139!4637994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6121 invoked from network); 1 Jun 2012 09:32:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:31:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:31:31 +0100
Message-ID: <1338543090.17466.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 1 Jun 2012 10:31:30 +0100
In-Reply-To: <alpine.DEB.2.00.1205251712480.26786@kaball-desktop>
References: <alpine.DEB.2.00.1205251712480.26786@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] xen/arm: event channels and
	shared_info page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-05-25 at 17:21 +0100, Stefano Stabellini wrote:
> this patch series implements support for injecting event channels into
> the guest and enables a wider range of hypercalls for ARM guests.

I've actually been running with the previous iteration of these patches
in my tree for ages now, so they are actually pretty well tested by me.

So I've acked+applied them...

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:32:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaODc-000663-Nf; Fri, 01 Jun 2012 09:32:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaODb-00065b-An
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:32:27 +0000
Received: from [193.109.254.147:56035] by server-12.bemta-14.messagelabs.com
	id 5E/75-12643-A2C88CF4; Fri, 01 Jun 2012 09:32:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338543138!7173231!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3103 invoked from network); 1 Jun 2012 09:32:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:31:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:31:28 +0100
Message-ID: <1338543086.17466.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:31:26 +0100
In-Reply-To: <patchbomb.1338482398@whitby.uk.xensource.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 6] ARM: various boot-time tidying
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 17:39 +0100, Tim Deegan wrote:
> These patches tinker with the ARM boot a little bit.  They shouldn't
> clash with any of the other ARM work going on, since they only touch
> very early code.

All 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 Jun 01 09:32:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaODc-000663-Nf; Fri, 01 Jun 2012 09:32:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaODb-00065b-An
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:32:27 +0000
Received: from [193.109.254.147:56035] by server-12.bemta-14.messagelabs.com
	id 5E/75-12643-A2C88CF4; Fri, 01 Jun 2012 09:32:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338543138!7173231!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3103 invoked from network); 1 Jun 2012 09:32:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12781917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:31:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:31:28 +0100
Message-ID: <1338543086.17466.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:31:26 +0100
In-Reply-To: <patchbomb.1338482398@whitby.uk.xensource.com>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 6] ARM: various boot-time tidying
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 17:39 +0100, Tim Deegan wrote:
> These patches tinker with the ARM boot a little bit.  They shouldn't
> clash with any of the other ARM work going on, since they only touch
> very early code.

All 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 Jun 01 09:33:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOE2-0006GL-55; Fri, 01 Jun 2012 09:32:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaOE0-0006FR-BS
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:32:52 +0000
Received: from [85.158.138.51:36515] by server-1.bemta-3.messagelabs.com id
	9B/8A-06526-34C88CF4; Fri, 01 Jun 2012 09:32:51 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338543170!11615769!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14647 invoked from network); 1 Jun 2012 09:32:50 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 09:32:50 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78337478; Fri, 01 Jun 2012 11:32:44 +0200
Message-ID: <1338543157.31901.27.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 11:32:37 +0200
In-Reply-To: <1338541118.17466.36.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6595025311598952481=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6595025311598952481==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-lkEpB5vqBetmbaX8Ka3s"


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

On Fri, 2012-06-01 at 09:58 +0100, Ian Campbell wrote:=20
> > > And, in future, there are some cases may not need to allocate max siz=
e cpumap too
> > > So it's better to extend the current interface.
> > >=20
> > Well, maybe... Who knows what future reserves ?!? :-D
> >=20
> > Anyway, although I see your point, I really really dislike the new
> > parameter in libxl_cpumap_alloc(),
>=20
> What about it do you dislike? The special meaning of 0 or its existence
> at all?
>=20
It's pretty much all about its existence, given the fact it is _always_
0 apart from one single case, where it could well be zero as well. :-)
It's just I find it uncomfortable to have it, but of course I could live
with it if it buys something. It's the latter I'm not sure I see...

> > but of course it is not something up
> > to me to decide, neither it is something I'd loose some sleep for. :-P
>=20
> You could give vcpus > pcpus (dumb, but e.g. for debugging) and in that
> case the existing libxl_cpumap_alloc behaviour (which sizes based on the
> # of phys cpus) is incorrect.=20
>
Mmm... Maybe this is still related to the fact that on all the test
boxes I've used, libxl_get_max_cpus() returns something higher than the
actual physical CPU count of those boxes themselves, but I just created
an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
can't, can you?

Maybe it is that *_max_cpus() logic that needs some attention? :-O

> I suggested that rather than having
> libxl_cpumap_alloc_size() we just combine this with the existing fn with
> a new parameter.
>=20
Yeah, I checked that in the archives, and that's not the issue for me.
If the we decide we want the thing, I'm fine with both the 'add new' and
'modify the existing' approaches.=20

Thanks and Regards,
Dario
|
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-lkEpB5vqBetmbaX8Ka3s
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IjDUACgkQk4XaBE3IOsQWEwCfSLTUyO4Ms2sUuUjmCdvxdthH
LVIAnj3XamUPcT/PSReLA3QMyjfQ3Kic
=MYcQ
-----END PGP SIGNATURE-----

--=-lkEpB5vqBetmbaX8Ka3s--



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

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

--===============6595025311598952481==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 09:33:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOE2-0006GL-55; Fri, 01 Jun 2012 09:32:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaOE0-0006FR-BS
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:32:52 +0000
Received: from [85.158.138.51:36515] by server-1.bemta-3.messagelabs.com id
	9B/8A-06526-34C88CF4; Fri, 01 Jun 2012 09:32:51 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338543170!11615769!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14647 invoked from network); 1 Jun 2012 09:32:50 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 09:32:50 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78337478; Fri, 01 Jun 2012 11:32:44 +0200
Message-ID: <1338543157.31901.27.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 11:32:37 +0200
In-Reply-To: <1338541118.17466.36.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6595025311598952481=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6595025311598952481==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-lkEpB5vqBetmbaX8Ka3s"


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

On Fri, 2012-06-01 at 09:58 +0100, Ian Campbell wrote:=20
> > > And, in future, there are some cases may not need to allocate max siz=
e cpumap too
> > > So it's better to extend the current interface.
> > >=20
> > Well, maybe... Who knows what future reserves ?!? :-D
> >=20
> > Anyway, although I see your point, I really really dislike the new
> > parameter in libxl_cpumap_alloc(),
>=20
> What about it do you dislike? The special meaning of 0 or its existence
> at all?
>=20
It's pretty much all about its existence, given the fact it is _always_
0 apart from one single case, where it could well be zero as well. :-)
It's just I find it uncomfortable to have it, but of course I could live
with it if it buys something. It's the latter I'm not sure I see...

> > but of course it is not something up
> > to me to decide, neither it is something I'd loose some sleep for. :-P
>=20
> You could give vcpus > pcpus (dumb, but e.g. for debugging) and in that
> case the existing libxl_cpumap_alloc behaviour (which sizes based on the
> # of phys cpus) is incorrect.=20
>
Mmm... Maybe this is still related to the fact that on all the test
boxes I've used, libxl_get_max_cpus() returns something higher than the
actual physical CPU count of those boxes themselves, but I just created
an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
can't, can you?

Maybe it is that *_max_cpus() logic that needs some attention? :-O

> I suggested that rather than having
> libxl_cpumap_alloc_size() we just combine this with the existing fn with
> a new parameter.
>=20
Yeah, I checked that in the archives, and that's not the issue for me.
If the we decide we want the thing, I'm fine with both the 'add new' and
'modify the existing' approaches.=20

Thanks and Regards,
Dario
|
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-lkEpB5vqBetmbaX8Ka3s
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IjDUACgkQk4XaBE3IOsQWEwCfSLTUyO4Ms2sUuUjmCdvxdthH
LVIAnj3XamUPcT/PSReLA3QMyjfQ3Kic
=MYcQ
-----END PGP SIGNATURE-----

--=-lkEpB5vqBetmbaX8Ka3s--



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

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

--===============6595025311598952481==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 09:37:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOIV-00073W-F0; Fri, 01 Jun 2012 09:37:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaOIU-00073N-7Z
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:37:30 +0000
Received: from [85.158.143.99:14422] by server-2.bemta-4.messagelabs.com id
	D7/5A-11595-95D88CF4; Fri, 01 Jun 2012 09:37:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1338543446!27506124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8504 invoked from network); 1 Jun 2012 09:37:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:37:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:37:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:37:14 +0100
Message-ID: <1338543433.17466.51.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:37:13 +0100
In-Reply-To: <20120601092926.GC77921@ocelot.phlegethon.org>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
	<1338542410.17466.46.camel@zakaz.uk.xensource.com>
	<20120601092926.GC77921@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6 of 6] arm: Enable VFP at 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 Fri, 2012-06-01 at 10:29 +0100, Tim Deegan wrote:
> At 10:20 +0100 on 01 Jun (1338546010), Ian Campbell wrote:
> > > -CFLAGS += -march=armv7-a -mcpu=cortex-a15
> > > +CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
> > 
> > This might have been worthy of a comment...
> 
> Ah, yes it might.  Would you like me to add one and resubmit?

I've already committed. If you feel like it then an incremental patch
might be nice...

> If I get time next week I'm going to look at VFP context switching; at
> that point I might move all the VFP code into its own .c or .S file and
> enable the fpu instructions just there, to be sure that gcc doesn't
> start using the VFP registers in normal Xen code -- it will do that for
> integer arithmetic with -mfpu=neon, for example.  OTOH it might be
> OK to do that as long as there are no caller-save VFP registers; I'll
> have a look at the calling conventions and see what can be done.

OK!



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:37:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOIV-00073W-F0; Fri, 01 Jun 2012 09:37:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaOIU-00073N-7Z
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:37:30 +0000
Received: from [85.158.143.99:14422] by server-2.bemta-4.messagelabs.com id
	D7/5A-11595-95D88CF4; Fri, 01 Jun 2012 09:37:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1338543446!27506124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8504 invoked from network); 1 Jun 2012 09:37:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:37:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:37:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:37:14 +0100
Message-ID: <1338543433.17466.51.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 10:37:13 +0100
In-Reply-To: <20120601092926.GC77921@ocelot.phlegethon.org>
References: <patchbomb.1338482398@whitby.uk.xensource.com>
	<d12d5fcf152bffda41de.1338482404@whitby.uk.xensource.com>
	<1338542410.17466.46.camel@zakaz.uk.xensource.com>
	<20120601092926.GC77921@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6 of 6] arm: Enable VFP at 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 Fri, 2012-06-01 at 10:29 +0100, Tim Deegan wrote:
> At 10:20 +0100 on 01 Jun (1338546010), Ian Campbell wrote:
> > > -CFLAGS += -march=armv7-a -mcpu=cortex-a15
> > > +CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
> > 
> > This might have been worthy of a comment...
> 
> Ah, yes it might.  Would you like me to add one and resubmit?

I've already committed. If you feel like it then an incremental patch
might be nice...

> If I get time next week I'm going to look at VFP context switching; at
> that point I might move all the VFP code into its own .c or .S file and
> enable the fpu instructions just there, to be sure that gcc doesn't
> start using the VFP registers in normal Xen code -- it will do that for
> integer arithmetic with -mfpu=neon, for example.  OTOH it might be
> OK to do that as long as there are no caller-save VFP registers; I'll
> have a look at the calling conventions and see what can be done.

OK!



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:40:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:40: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 1SaOLI-0007CE-1h; Fri, 01 Jun 2012 09:40:24 +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 1SaOLG-0007C6-Vg
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:40:23 +0000
Received: from [85.158.143.35:18094] by server-1.bemta-4.messagelabs.com id
	AB/DB-27869-60E88CF4; Fri, 01 Jun 2012 09:40:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338543617!18319506!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21379 invoked from network); 1 Jun 2012 09:40:19 -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;
	1 Jun 2012 09:40:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197167114"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 05:40:17 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 05:40:16 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaOLA-0004TN-B6;
	Fri, 01 Jun 2012 10:40:16 +0100
Message-ID: <4FC88DFF.70807@citrix.com>
Date: Fri, 1 Jun 2012 10:40:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IFBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6Cj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1s
Cj4KPiBUaGUgdGltZSBsaW5lIGlzIGFzIGZvbGxvd3M6Cj4KPiAxOSBNYXJjaCAgICAgICAgLS0g
VE9ETyBsaXN0IGxvY2tlZCBkb3duCj4gMiBBcHJpbCAgICAgICAgIC0tIEZlYXR1cmUgRnJlZXpl
Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDw8ICBX
RSBBUkUgSEVSRQo+IE1pZC9MYXRlIE1heSAgICAtLSBGaXJzdCByZWxlYXNlIGNhbmRpZGF0ZQo+
IFdlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCBpdCBpcyByZWFkeQo+Cj4gSXQgc2VlbXMg
cHJldHR5IG9idmlvdXMgYXQgdGhpcyBzdGFnZSB0aGF0IHdlIGFyZSBub3QgZ29pbmcgdG8gYmUK
PiBkb2luZyBhbiBSQyBpbiBNaWQvTGF0ZSBNYXkuIFRoZSBiaWcgcmVtYWluaW5nIGl0ZW1zIGFy
ZSBiZWluZwo+IGFjdGl2ZWx5IHdvcmtlZCBvbiBhbmQgYXJlIHF1aXRlIHdlbGwgdW5kZXJzdG9v
ZC4gSSd2ZSBhbHNvIGRvbmUgYQo+IHBhc3MgdGhyb3VnaCB0aGUgdG9vbHMgYmxvY2tlcnMgbGlz
dCBhbmQgaGF2ZSBwcm9wb3NlZCBtb3Zpbmcgc29tZQo+IGl0ZW1zIHRvIHRoZSBOaWNlIFRvIEhh
dmUgbGlzdC4KPgo+IFRoZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLiBQZXIgdGhlIHJlbGVh
c2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwKPiBub3cgaGF2ZSB0byBiZSBtYWRlIGFzIHRvIHdo
eSBuZXcgaXRlbXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0LAo+IGVzcGVjaWFsbHkgYXMg
YSBibG9ja2VyLCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCj4KPiBJZiB5b3UgYXJlIGF3
YXJlIG9mIGFueSBidWdzIHdoaWNoIG11c3Qvc2hvdWxkIGJlIGZpeGVkIGZvciA0LjIgdGhlbgo+
IHBsZWFzZSByZXBseSB0byB0aGlzIHRocmVhZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJl
ciB0byBwaWNrIHRoZW0KPiB1cCBuZXh0IHdlZWspCj4KPiBPdGhlciB0aGFuIHRoYXQgSSB0aGlu
ayB3ZSBzaG91bGQgY29uc2lkZXIgdGhlIGZyZWV6ZSB0byBiZSBpbiBmdWxsCj4gZWZmZWN0IGFu
ZCB0aGUgYmFyIHRvIGVudHJ5IHRvIDQuMiB0byBiZSB2ZXJ5IGhpZ2guCj4KPiBoeXBlcnZpc29y
LCBibG9ja2VyczoKPgo+ICAgICAgKiBOb25lCj4KPiB0b29scywgYmxvY2tlcnM6Cj4KPiAgICAg
ICogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFi
bGUgQVBJCj4gICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBu
b3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YKPiAgICAgICAgdGhpcyBhcmU6Cj4KPiAgICAgICAgICAq
IGxpYnhsX3dhaXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQu
Cj4gICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8KPiAg
ICAgICAgICAgIGxvY2tpbmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUgKGRlZmVy
cmVkIHRvCj4gICAgICAgICAgICA0LjMpLiBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMgaW50
ZXJmYWNlIGJlaW5nCj4gICAgICAgICAgICBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVy
IHRvIDQuMy4gV2lsbCBtb3ZlIHRvIE5pY2UgVG8KPiAgICAgICAgICAgIEhhdmUncyBuZXh0IHdl
ZWsuCj4KPiAgICAgICAgICAqIGxpYnhsXypfcGF0aC4gTWFqb3JpdHkgbWFkZSBpbnRlcm5hbCwg
b25seSBjb25maWdkaXIgYW5kCj4gICAgICAgICAgICBsb2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVz
ZWQgYnkgeGwpLiAoSWFuQywgdG8gY29uc2lkZXIKPiAgICAgICAgICAgIG1vdmluZyB0aGUgdHdv
IHJlYW1pbmluZyBpbnRvIHhsIGluc3RlYWQgb2YgbGlieGwsIHdpbGwgbW92ZQo+ICAgICAgICAg
ICAgdG8gTmljZSBUbyBIYXZlJ3MgbmV4dCB3ZWVrKQo+Cj4gICAgICAgICAgKiBJbnRlcmZhY2Vz
IHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgo+Cj4gICAgICAgICAgICAgICogbGlieGxfZG9t
YWluX3N1c3BlbmQuIE1vdmUgeGNfZG9tYWluX3NhdmUvcmVzdG9yZSBpbnRvIGEKPiAgICAgICAg
ICAgICAgICBzZXBhcmF0ZSBwcm9jZXNzIChJYW5KLCBSRkMgcG9zdGVkLCB3b3JrIG9uZ29pbmcp
Lgo+Cj4gICAgICAgICAgICAgICogbGlieGxfZGV2aWNlX3tkaXNrLG5pYyx2a2IsYWRkLHBjaX1f
YWRkIChhbmQKPiAgICAgICAgICAgICAgICByZW1vdmU/KS4gUm9nZXIgUGF1IE1vbm7DqSBmaXhl
cyBkaXNrIGFzIHBhcnQgb2YgaG90cGx1Zwo+ICAgICAgICAgICAgICAgIHNjcmlwdCBzZXJpZXMg
YW5kIGFkZHMgaW5mcmFzdHJ1Y3R1cmUgd2hpY2ggc2hvdWxkIG1ha2UKPiAgICAgICAgICAgICAg
ICB0aGUgb3RoZXJzIHRyaXZpYWwuIChSb2dlciwgV0lQKQoKUGF0Y2hlcyBwb3N0ZWQgKGluIHRo
ZSBob3RwbHVnIHNlcmllcykgdG8gbWFrZSBkaXNrIGFuZCBuaWMgYXN5bmMgKGJvdGggCmFkZGl0
aW9uIGFuZCBkZWxldGlvbikuIE9uY2UgdGhhdCBpcyBpbiwgdmZiIGFuZCB2a2IgYXJlIHF1aXRl
IHRyaXZpYWwuIApJJ20gbm90IHN1cmUgYWJvdXQgUENJIHNpbmNlIEkgaGF2ZW4ndCBsb29rZWQg
YXQgaXQuCgpZb3UgY2FuIGFsc28gYWRkOgoKKiBsaWJ4bF9kb21haW5fZGVzdHJveTogY29udmVy
dCB0byBhc3luYy4gTW9zdGx5IGRvbmUgc2luY2UgaXQgd2lsbCBnbyAKaW4gd2l0aCBteSBob3Rw
bHVnIHNjcmlwdCBzZXJpZXMgYW5kIHRoZSBkaXNrL25pYyBhZGQvcmVtb3ZlLgoKPgo+ICAgICAg
ICAgICAgICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQo+ICAgICAg
ICAgICAgICAgIGRpc2tfe2FkZCxyZW1vdmV9IGRvbmUuIE5vYm9keSBpcyBsb29raW5nIGF0IHRo
aXM/IFRoaXMKPiAgICAgICAgICAgICAgICBpcyBiYXNpY2FsbHkgYSBoZWxwZXIgZnVuY3Rpb24g
YW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbgo+ICAgICAgICAgICAgICAgIGJlIGltcGxlbWVudGVk
IGluIHRlcm1zIG9mIHRoZSBsaWJ4bF9kaXNrXyoKPiAgICAgICAgICAgICAgICBpbnRlcmZhY2Vz
LiBXZSBjb3VsZCB0aGVyZWZvcmUgY29uc2lkZXIgbWFya2luZyB0aGlzCj4gICAgICAgICAgICAg
ICAgZnVuY3Rpb24gYXMgc3Vic3RhbmRhcmQgYW5kIHN1YmplY3QgdG8gY2hhbmdlIGluIHRoZQo+
ICAgICAgICAgICAgICAgIGZ1dHVyZS4gV2UgY291bGQgYWxzbyBjb25zaWRlciBzaW1wbHkgbW92
aW5nIGl0IGludG8geGwKPiAgICAgICAgICAgICAgICBhcyBhIGhlbHBlciBmdW5jdGlvbiBhbmQg
cmV2aXN0aW5nIGZvciA0LjMuCj4KPiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgo+
Cj4gICAgICAgICAgKiBbQlVHXSBjYW5ub3QgY3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZSBv
biBIVk0gZ3Vlc3QsCj4gICAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGluPDRG
OTY3MkRELjIwODA5MDJAdGlzY2FsaS5pdD4KPgo+ICAgICAgICAgICogZG9lcyBub3QgYXV0b21h
dGljYWxseSB0cnkgdG8gc2VsZWN0IGEgKHNldCBvZikgbm9kZShzKSBvbgo+ICAgICAgICAgICAg
d2hpY2ggdG8gY3JlYXRlIGEgVk0gYW5kIHBpbiBpdHMgdmNwdXMgdGhlcmUuIChEYXJpbwo+ICAg
ICAgICAgICAgRmFnZ2lvbGksIHBhdGNoZXMgcG9zdGVkKQo+Cj4gICAgICAgICAgKiBgY3B1cz1b
MiwzXWAgdG8gc2VsZWN0IHNwZWNpZmljIG1hcHBpbmcgdmNwdTAtLT5wY3B1MiwKPiAgICAgICAg
ICAgIHZjcHUxLS0+cGNwdTMgYXMgeG0gZG9lcy4gKERhcmlvIEZhZ2dpb2xpLCBET05FKQo+Cj4g
ICAgICAqIFtCVUddIFNwdXJpb3VzIENQVSBwYXJhbXMgZXJyb3IgbWVzc2FnZSB3aGVuIHN0YXJ0
aW5nIGEgZG9tYWluLAo+ICAgICAgICBlLmcuICJDcHUgd2VpZ2h0IG91dCBvZiByYW5nZSwgdmFs
aWQgdmFsdWVzIGFyZSB3aXRoaW4gcmFuZ2UKPiAgICAgICAgZnJvbSAxIHRvIDY1NTM1Ii4gKElh
biBDLCBwYXRjaGVzIHBvc3RlZCwgbmVlZCBmaW5hbCBkZWNpc2lvbiBvbgo+ICAgICAgICAib25l
IHN0cnVjdCIgb3IgIm11bHRpcGxlIHN0cnVjdCIgbGlieGwgQVBJIGZvciBzY2hlZCBwYXJhbXMp
Cj4KPiAgICAgICogTW9yZSBmb3JtYWxseSBkZXByZWNhdGUgeG0veGVuZC4gTWFucGFnZSBwYXRj
aGVzIGFscmVhZHkgaW4KPiAgICAgICAgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNv
bW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0
IHhsLgo+Cj4gICAgICAqIERvbWFpbiAwIGJsb2NrIGF0dGFjaCYgIGdlbmVyYWwgaG90cGx1ZyB3
aGVuIHVzaW5nIHFkaXNrIGJhY2tlbmQKPiAgICAgICAgKG5lZWQgdG8gc3RhcnQgcWVtdSBhcyBu
ZWNlc3NhcnkgZXRjKSAoU3RlZmFubyBTLCBwYXRjaGVzCj4gICAgICAgIHBvc3RlZCwgcGVvcGxl
IHNlZW0gaGFwcHkgYmFyIHRoZSBjb2RlIG1vdGlvbikKPgo+ICAgICAgKiBJbXByb3ZlZCBIb3Rw
bHVnIHNjcmlwdCBzdXBwb3J0IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzCj4gICAgICAgIHBv
c3RlZCwgbmVhcmluZyBjb21wbGV0aW9uPykKCkkgd291bGQgY2FsbCB0aGlzICJjYWxsaW5nIGhv
dHBsdWcgc2NyaXB0cyBmcm9tIHhsIiwgImltcHJvdmVkIGhvdHBsdWcgCnNjcmlwdCBzdXBwb3J0
IiBzZWVtcyBxdWl0ZSB2YWd1ZS4gWWVzLCBJIHRoaW5rIHRoZXkgYXJlIHF1aXRlIGRvbmUsIGFu
ZCAKcGVvcGxlIHNlZW1zIHRvIGJlIGhhcHB5IHdpdGggdGhhdC4KCkkgYWxzbyBoYXZlIHRoZSBO
ZXRCU0Qgc3VwcG9ydCBpbiBteSBwYXRjaCBxdWV1ZSwgd2FpdGluZyBmb3IgdGhlIExpbnV4IApz
dXBwb3J0IHRvIGdvIGluIChzaW5jZSBpdCB3aWxsIGJlIHBvaW50bGVzcyB0byBoYXZlIHRvIHJl
cG9zdCB0aGUgCk5ldEJTRCBzZXJpZXMgZXZlcnkgdGltZSB0aGUgcHJldmlvdXMgb25lIGNoYW5n
ZXMpLgoKPgo+ICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9uIGZyb20g
aG90cGx1ZyBzY3JpcHQgKFJvZ2VyCj4gICAgICAgIFBhdSBNb25uw6kpCgpUaGlzIHdpbGwganVz
dCBiZSBhIG1hdHRlciBvZiByZW1vdmluZyBhbiAiaWYiIHRoYXQncyBwcmV2ZW50aW5nIGxpYnhs
IApmcm9tIHVzaW5nIGN1c3RvbSBob3RwbHVnIHNjcmlwdHMgZm9yIGRpc2tzLgoKPiAgICAgICog
QWRqdXN0bWVudHMgbmVlZGVkIGZvciBxZGlzayBiYWNrZW5kIHRvIHdvcmsgb24gbm9uLXB2b3Bz
IExpbnV4Lgo+ICAgICAgICAoSmFuIEJldWxpY2gpCgoqIHFlbXUtdXBzdHJlYW0gZm9yIE5ldEJT
RDogSSdtIGN1cnJlbnRseSB3b3JraW5nIG9uIHRoaXMuIEl0IGNvbXBpbGVzIApidXQgVkdBIG1l
bW9yeSBtYXBwaW5nIHNlZW1zIHRvIGJlIHdyb25nLCBhbmQgcWVtdSBnZXRzIGEgc2VnZmF1bHQg
d2hlbiAKdHJ5aW5nIHRvIHdyaXRlIHRvIGl0LgoKPiBoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6
Cj4KPiAgICAgICogUG9EIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyAoR2VvcmdlIER1bmxhcCkK
Pgo+ICAgICAgKiBJUlEgcHJvYmxlbSBmb3Igd2hpY2ggZGVidWdnaW5nIGNvZGUgZ290IGFkZGVk
IGJ5IGMvcwo+ICAgICAgICAyNDcwNzo5Njk4N2MzMjRhNGYuIEkgaGF2ZSBhIHRlbnRhdGl2ZSBh
ZGp1c3RtZW50IHRvIHRoaXMgd2hpY2gKPiAgICAgICAgSSB3b3VsZCBob3BlIHRvIGF0IGxlYXN0
IGVsaW1pbmF0ZSB0aGUgYmFkIGNvbnNlcXVlbmNlcyBvZgo+ICAgICAgICBjcmFzaGluZyB0aGUg
aHlwZXJ2aXNvciAoY29udmVydGluZyB0aGUgdW5zb2xpY2l0ZWQKPiAgICAgICAgUElDLW9yaWdp
bmF0ZWQgSVJRIGludG8gYSBzcHVyaW91cyBvbmUpLiBJJ2xsIHN1Ym1pdCBhcyBzb29uIGFzCj4g
ICAgICAgIEkgZ290IHRvIHRlc3QgdGhpcyBhIGxpdHRsZSwgcGFydGljdWxhcmx5IGFsc28gb24g
YW4gb2xkIGJveAo+ICAgICAgICB3aXRob3V0IEFQSUMuIChKYW4gQmV1bGljaCwgRE9ORSkKPgo+
IHRvb2xzLCBuaWNlIHRvIGhhdmU6Cj4KPiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHht
Ogo+Cj4gICAgICAgICAgKiBOb25lIHJlbWFpbgo+Cj4gICAgICAqIGxpYnhsOiBBZGQgQVBJIHRv
IHJldHJpZXZlIGRvbWFpbiBjb25zb2xlIHR0eSAoQmFtdm9yIEppYW4KPiAgICAgICAgWmhhbmcs
IHBhdGNoZXMgcG9zdGVkKQo+Cj4gICAgICAqIHhsLmNmZyg1KSBkb2N1bWVudGF0aW9uIHBhdGNo
IGZvciBxZW11LXVwc3RyZWFtCj4gICAgICAgIHZpZGVvcmFtL3ZpZGVvbWVtIHN1cHBvcnQ6Cj4g
ICAgICAgIGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTIt
MDUvbXNnMDAyNTAuaHRtbAo+ICAgICAgICBxZW11LXVwc3RyZWFtIGRvZXNuJ3Qgc3VwcG9ydCBz
cGVjaWZ5aW5nIHZpZGVvbWVtIHNpemUgZm9yIHRoZQo+ICAgICAgICBIVk0gZ3Vlc3QgY2lycnVz
L3N0ZHZnYS4gIChidXQgdGhpcyB3b3JrcyB3aXRoCj4gICAgICAgIHFlbXUteGVuLXRyYWRpdGlv
bmFsKS4gKFBhc2kgS8Okcmtrw6RpbmVuKQo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:40:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:40: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 1SaOLI-0007CE-1h; Fri, 01 Jun 2012 09:40:24 +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 1SaOLG-0007C6-Vg
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:40:23 +0000
Received: from [85.158.143.35:18094] by server-1.bemta-4.messagelabs.com id
	AB/DB-27869-60E88CF4; Fri, 01 Jun 2012 09:40:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338543617!18319506!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21379 invoked from network); 1 Jun 2012 09:40:19 -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;
	1 Jun 2012 09:40:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197167114"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 05:40:17 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 05:40:16 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaOLA-0004TN-B6;
	Fri, 01 Jun 2012 10:40:16 +0100
Message-ID: <4FC88DFF.70807@citrix.com>
Date: Fri, 1 Jun 2012 10:40:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IFBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6Cj4gaHR0cDovL2xp
c3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1s
Cj4KPiBUaGUgdGltZSBsaW5lIGlzIGFzIGZvbGxvd3M6Cj4KPiAxOSBNYXJjaCAgICAgICAgLS0g
VE9ETyBsaXN0IGxvY2tlZCBkb3duCj4gMiBBcHJpbCAgICAgICAgIC0tIEZlYXR1cmUgRnJlZXpl
Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDw8ICBX
RSBBUkUgSEVSRQo+IE1pZC9MYXRlIE1heSAgICAtLSBGaXJzdCByZWxlYXNlIGNhbmRpZGF0ZQo+
IFdlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCBpdCBpcyByZWFkeQo+Cj4gSXQgc2VlbXMg
cHJldHR5IG9idmlvdXMgYXQgdGhpcyBzdGFnZSB0aGF0IHdlIGFyZSBub3QgZ29pbmcgdG8gYmUK
PiBkb2luZyBhbiBSQyBpbiBNaWQvTGF0ZSBNYXkuIFRoZSBiaWcgcmVtYWluaW5nIGl0ZW1zIGFy
ZSBiZWluZwo+IGFjdGl2ZWx5IHdvcmtlZCBvbiBhbmQgYXJlIHF1aXRlIHdlbGwgdW5kZXJzdG9v
ZC4gSSd2ZSBhbHNvIGRvbmUgYQo+IHBhc3MgdGhyb3VnaCB0aGUgdG9vbHMgYmxvY2tlcnMgbGlz
dCBhbmQgaGF2ZSBwcm9wb3NlZCBtb3Zpbmcgc29tZQo+IGl0ZW1zIHRvIHRoZSBOaWNlIFRvIEhh
dmUgbGlzdC4KPgo+IFRoZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLiBQZXIgdGhlIHJlbGVh
c2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwKPiBub3cgaGF2ZSB0byBiZSBtYWRlIGFzIHRvIHdo
eSBuZXcgaXRlbXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0LAo+IGVzcGVjaWFsbHkgYXMg
YSBibG9ja2VyLCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCj4KPiBJZiB5b3UgYXJlIGF3
YXJlIG9mIGFueSBidWdzIHdoaWNoIG11c3Qvc2hvdWxkIGJlIGZpeGVkIGZvciA0LjIgdGhlbgo+
IHBsZWFzZSByZXBseSB0byB0aGlzIHRocmVhZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJl
ciB0byBwaWNrIHRoZW0KPiB1cCBuZXh0IHdlZWspCj4KPiBPdGhlciB0aGFuIHRoYXQgSSB0aGlu
ayB3ZSBzaG91bGQgY29uc2lkZXIgdGhlIGZyZWV6ZSB0byBiZSBpbiBmdWxsCj4gZWZmZWN0IGFu
ZCB0aGUgYmFyIHRvIGVudHJ5IHRvIDQuMiB0byBiZSB2ZXJ5IGhpZ2guCj4KPiBoeXBlcnZpc29y
LCBibG9ja2VyczoKPgo+ICAgICAgKiBOb25lCj4KPiB0b29scywgYmxvY2tlcnM6Cj4KPiAgICAg
ICogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFi
bGUgQVBJCj4gICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBu
b3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YKPiAgICAgICAgdGhpcyBhcmU6Cj4KPiAgICAgICAgICAq
IGxpYnhsX3dhaXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQu
Cj4gICAgICAgICAgICBJbnRlcmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8KPiAg
ICAgICAgICAgIGxvY2tpbmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUgKGRlZmVy
cmVkIHRvCj4gICAgICAgICAgICA0LjMpLiBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMgaW50
ZXJmYWNlIGJlaW5nCj4gICAgICAgICAgICBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVy
IHRvIDQuMy4gV2lsbCBtb3ZlIHRvIE5pY2UgVG8KPiAgICAgICAgICAgIEhhdmUncyBuZXh0IHdl
ZWsuCj4KPiAgICAgICAgICAqIGxpYnhsXypfcGF0aC4gTWFqb3JpdHkgbWFkZSBpbnRlcm5hbCwg
b25seSBjb25maWdkaXIgYW5kCj4gICAgICAgICAgICBsb2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVz
ZWQgYnkgeGwpLiAoSWFuQywgdG8gY29uc2lkZXIKPiAgICAgICAgICAgIG1vdmluZyB0aGUgdHdv
IHJlYW1pbmluZyBpbnRvIHhsIGluc3RlYWQgb2YgbGlieGwsIHdpbGwgbW92ZQo+ICAgICAgICAg
ICAgdG8gTmljZSBUbyBIYXZlJ3MgbmV4dCB3ZWVrKQo+Cj4gICAgICAgICAgKiBJbnRlcmZhY2Vz
IHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgo+Cj4gICAgICAgICAgICAgICogbGlieGxfZG9t
YWluX3N1c3BlbmQuIE1vdmUgeGNfZG9tYWluX3NhdmUvcmVzdG9yZSBpbnRvIGEKPiAgICAgICAg
ICAgICAgICBzZXBhcmF0ZSBwcm9jZXNzIChJYW5KLCBSRkMgcG9zdGVkLCB3b3JrIG9uZ29pbmcp
Lgo+Cj4gICAgICAgICAgICAgICogbGlieGxfZGV2aWNlX3tkaXNrLG5pYyx2a2IsYWRkLHBjaX1f
YWRkIChhbmQKPiAgICAgICAgICAgICAgICByZW1vdmU/KS4gUm9nZXIgUGF1IE1vbm7DqSBmaXhl
cyBkaXNrIGFzIHBhcnQgb2YgaG90cGx1Zwo+ICAgICAgICAgICAgICAgIHNjcmlwdCBzZXJpZXMg
YW5kIGFkZHMgaW5mcmFzdHJ1Y3R1cmUgd2hpY2ggc2hvdWxkIG1ha2UKPiAgICAgICAgICAgICAg
ICB0aGUgb3RoZXJzIHRyaXZpYWwuIChSb2dlciwgV0lQKQoKUGF0Y2hlcyBwb3N0ZWQgKGluIHRo
ZSBob3RwbHVnIHNlcmllcykgdG8gbWFrZSBkaXNrIGFuZCBuaWMgYXN5bmMgKGJvdGggCmFkZGl0
aW9uIGFuZCBkZWxldGlvbikuIE9uY2UgdGhhdCBpcyBpbiwgdmZiIGFuZCB2a2IgYXJlIHF1aXRl
IHRyaXZpYWwuIApJJ20gbm90IHN1cmUgYWJvdXQgUENJIHNpbmNlIEkgaGF2ZW4ndCBsb29rZWQg
YXQgaXQuCgpZb3UgY2FuIGFsc28gYWRkOgoKKiBsaWJ4bF9kb21haW5fZGVzdHJveTogY29udmVy
dCB0byBhc3luYy4gTW9zdGx5IGRvbmUgc2luY2UgaXQgd2lsbCBnbyAKaW4gd2l0aCBteSBob3Rw
bHVnIHNjcmlwdCBzZXJpZXMgYW5kIHRoZSBkaXNrL25pYyBhZGQvcmVtb3ZlLgoKPgo+ICAgICAg
ICAgICAgICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQo+ICAgICAg
ICAgICAgICAgIGRpc2tfe2FkZCxyZW1vdmV9IGRvbmUuIE5vYm9keSBpcyBsb29raW5nIGF0IHRo
aXM/IFRoaXMKPiAgICAgICAgICAgICAgICBpcyBiYXNpY2FsbHkgYSBoZWxwZXIgZnVuY3Rpb24g
YW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbgo+ICAgICAgICAgICAgICAgIGJlIGltcGxlbWVudGVk
IGluIHRlcm1zIG9mIHRoZSBsaWJ4bF9kaXNrXyoKPiAgICAgICAgICAgICAgICBpbnRlcmZhY2Vz
LiBXZSBjb3VsZCB0aGVyZWZvcmUgY29uc2lkZXIgbWFya2luZyB0aGlzCj4gICAgICAgICAgICAg
ICAgZnVuY3Rpb24gYXMgc3Vic3RhbmRhcmQgYW5kIHN1YmplY3QgdG8gY2hhbmdlIGluIHRoZQo+
ICAgICAgICAgICAgICAgIGZ1dHVyZS4gV2UgY291bGQgYWxzbyBjb25zaWRlciBzaW1wbHkgbW92
aW5nIGl0IGludG8geGwKPiAgICAgICAgICAgICAgICBhcyBhIGhlbHBlciBmdW5jdGlvbiBhbmQg
cmV2aXN0aW5nIGZvciA0LjMuCj4KPiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgo+
Cj4gICAgICAgICAgKiBbQlVHXSBjYW5ub3QgY3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZSBv
biBIVk0gZ3Vlc3QsCj4gICAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGluPDRG
OTY3MkRELjIwODA5MDJAdGlzY2FsaS5pdD4KPgo+ICAgICAgICAgICogZG9lcyBub3QgYXV0b21h
dGljYWxseSB0cnkgdG8gc2VsZWN0IGEgKHNldCBvZikgbm9kZShzKSBvbgo+ICAgICAgICAgICAg
d2hpY2ggdG8gY3JlYXRlIGEgVk0gYW5kIHBpbiBpdHMgdmNwdXMgdGhlcmUuIChEYXJpbwo+ICAg
ICAgICAgICAgRmFnZ2lvbGksIHBhdGNoZXMgcG9zdGVkKQo+Cj4gICAgICAgICAgKiBgY3B1cz1b
MiwzXWAgdG8gc2VsZWN0IHNwZWNpZmljIG1hcHBpbmcgdmNwdTAtLT5wY3B1MiwKPiAgICAgICAg
ICAgIHZjcHUxLS0+cGNwdTMgYXMgeG0gZG9lcy4gKERhcmlvIEZhZ2dpb2xpLCBET05FKQo+Cj4g
ICAgICAqIFtCVUddIFNwdXJpb3VzIENQVSBwYXJhbXMgZXJyb3IgbWVzc2FnZSB3aGVuIHN0YXJ0
aW5nIGEgZG9tYWluLAo+ICAgICAgICBlLmcuICJDcHUgd2VpZ2h0IG91dCBvZiByYW5nZSwgdmFs
aWQgdmFsdWVzIGFyZSB3aXRoaW4gcmFuZ2UKPiAgICAgICAgZnJvbSAxIHRvIDY1NTM1Ii4gKElh
biBDLCBwYXRjaGVzIHBvc3RlZCwgbmVlZCBmaW5hbCBkZWNpc2lvbiBvbgo+ICAgICAgICAib25l
IHN0cnVjdCIgb3IgIm11bHRpcGxlIHN0cnVjdCIgbGlieGwgQVBJIGZvciBzY2hlZCBwYXJhbXMp
Cj4KPiAgICAgICogTW9yZSBmb3JtYWxseSBkZXByZWNhdGUgeG0veGVuZC4gTWFucGFnZSBwYXRj
aGVzIGFscmVhZHkgaW4KPiAgICAgICAgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNv
bW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0
IHhsLgo+Cj4gICAgICAqIERvbWFpbiAwIGJsb2NrIGF0dGFjaCYgIGdlbmVyYWwgaG90cGx1ZyB3
aGVuIHVzaW5nIHFkaXNrIGJhY2tlbmQKPiAgICAgICAgKG5lZWQgdG8gc3RhcnQgcWVtdSBhcyBu
ZWNlc3NhcnkgZXRjKSAoU3RlZmFubyBTLCBwYXRjaGVzCj4gICAgICAgIHBvc3RlZCwgcGVvcGxl
IHNlZW0gaGFwcHkgYmFyIHRoZSBjb2RlIG1vdGlvbikKPgo+ICAgICAgKiBJbXByb3ZlZCBIb3Rw
bHVnIHNjcmlwdCBzdXBwb3J0IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzCj4gICAgICAgIHBv
c3RlZCwgbmVhcmluZyBjb21wbGV0aW9uPykKCkkgd291bGQgY2FsbCB0aGlzICJjYWxsaW5nIGhv
dHBsdWcgc2NyaXB0cyBmcm9tIHhsIiwgImltcHJvdmVkIGhvdHBsdWcgCnNjcmlwdCBzdXBwb3J0
IiBzZWVtcyBxdWl0ZSB2YWd1ZS4gWWVzLCBJIHRoaW5rIHRoZXkgYXJlIHF1aXRlIGRvbmUsIGFu
ZCAKcGVvcGxlIHNlZW1zIHRvIGJlIGhhcHB5IHdpdGggdGhhdC4KCkkgYWxzbyBoYXZlIHRoZSBO
ZXRCU0Qgc3VwcG9ydCBpbiBteSBwYXRjaCBxdWV1ZSwgd2FpdGluZyBmb3IgdGhlIExpbnV4IApz
dXBwb3J0IHRvIGdvIGluIChzaW5jZSBpdCB3aWxsIGJlIHBvaW50bGVzcyB0byBoYXZlIHRvIHJl
cG9zdCB0aGUgCk5ldEJTRCBzZXJpZXMgZXZlcnkgdGltZSB0aGUgcHJldmlvdXMgb25lIGNoYW5n
ZXMpLgoKPgo+ICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9uIGZyb20g
aG90cGx1ZyBzY3JpcHQgKFJvZ2VyCj4gICAgICAgIFBhdSBNb25uw6kpCgpUaGlzIHdpbGwganVz
dCBiZSBhIG1hdHRlciBvZiByZW1vdmluZyBhbiAiaWYiIHRoYXQncyBwcmV2ZW50aW5nIGxpYnhs
IApmcm9tIHVzaW5nIGN1c3RvbSBob3RwbHVnIHNjcmlwdHMgZm9yIGRpc2tzLgoKPiAgICAgICog
QWRqdXN0bWVudHMgbmVlZGVkIGZvciBxZGlzayBiYWNrZW5kIHRvIHdvcmsgb24gbm9uLXB2b3Bz
IExpbnV4Lgo+ICAgICAgICAoSmFuIEJldWxpY2gpCgoqIHFlbXUtdXBzdHJlYW0gZm9yIE5ldEJT
RDogSSdtIGN1cnJlbnRseSB3b3JraW5nIG9uIHRoaXMuIEl0IGNvbXBpbGVzIApidXQgVkdBIG1l
bW9yeSBtYXBwaW5nIHNlZW1zIHRvIGJlIHdyb25nLCBhbmQgcWVtdSBnZXRzIGEgc2VnZmF1bHQg
d2hlbiAKdHJ5aW5nIHRvIHdyaXRlIHRvIGl0LgoKPiBoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6
Cj4KPiAgICAgICogUG9EIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyAoR2VvcmdlIER1bmxhcCkK
Pgo+ICAgICAgKiBJUlEgcHJvYmxlbSBmb3Igd2hpY2ggZGVidWdnaW5nIGNvZGUgZ290IGFkZGVk
IGJ5IGMvcwo+ICAgICAgICAyNDcwNzo5Njk4N2MzMjRhNGYuIEkgaGF2ZSBhIHRlbnRhdGl2ZSBh
ZGp1c3RtZW50IHRvIHRoaXMgd2hpY2gKPiAgICAgICAgSSB3b3VsZCBob3BlIHRvIGF0IGxlYXN0
IGVsaW1pbmF0ZSB0aGUgYmFkIGNvbnNlcXVlbmNlcyBvZgo+ICAgICAgICBjcmFzaGluZyB0aGUg
aHlwZXJ2aXNvciAoY29udmVydGluZyB0aGUgdW5zb2xpY2l0ZWQKPiAgICAgICAgUElDLW9yaWdp
bmF0ZWQgSVJRIGludG8gYSBzcHVyaW91cyBvbmUpLiBJJ2xsIHN1Ym1pdCBhcyBzb29uIGFzCj4g
ICAgICAgIEkgZ290IHRvIHRlc3QgdGhpcyBhIGxpdHRsZSwgcGFydGljdWxhcmx5IGFsc28gb24g
YW4gb2xkIGJveAo+ICAgICAgICB3aXRob3V0IEFQSUMuIChKYW4gQmV1bGljaCwgRE9ORSkKPgo+
IHRvb2xzLCBuaWNlIHRvIGhhdmU6Cj4KPiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHht
Ogo+Cj4gICAgICAgICAgKiBOb25lIHJlbWFpbgo+Cj4gICAgICAqIGxpYnhsOiBBZGQgQVBJIHRv
IHJldHJpZXZlIGRvbWFpbiBjb25zb2xlIHR0eSAoQmFtdm9yIEppYW4KPiAgICAgICAgWmhhbmcs
IHBhdGNoZXMgcG9zdGVkKQo+Cj4gICAgICAqIHhsLmNmZyg1KSBkb2N1bWVudGF0aW9uIHBhdGNo
IGZvciBxZW11LXVwc3RyZWFtCj4gICAgICAgIHZpZGVvcmFtL3ZpZGVvbWVtIHN1cHBvcnQ6Cj4g
ICAgICAgIGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTIt
MDUvbXNnMDAyNTAuaHRtbAo+ICAgICAgICBxZW11LXVwc3RyZWFtIGRvZXNuJ3Qgc3VwcG9ydCBz
cGVjaWZ5aW5nIHZpZGVvbWVtIHNpemUgZm9yIHRoZQo+ICAgICAgICBIVk0gZ3Vlc3QgY2lycnVz
L3N0ZHZnYS4gIChidXQgdGhpcyB3b3JrcyB3aXRoCj4gICAgICAgIHFlbXUteGVuLXRyYWRpdGlv
bmFsKS4gKFBhc2kgS8Okcmtrw6RpbmVuKQo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOM3-0007Gw-Fx; Fri, 01 Jun 2012 09:41:11 +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 1SaOM1-0007Gg-SU
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:41:10 +0000
Received: from [193.109.254.147:3093] by server-5.bemta-14.messagelabs.com id
	A1/0A-06171-53E88CF4; Fri, 01 Jun 2012 09:41:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1338543667!9523105!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10399 invoked from network); 1 Jun 2012 09:41:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:41:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:41:07 +0100
Message-ID: <1338543666.17466.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 10:41:06 +0100
In-Reply-To: <1338543157.31901.27.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 10:32 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 09:58 +0100, Ian Campbell wrote: 
> > > > And, in future, there are some cases may not need to allocate max size cpumap too
> > > > So it's better to extend the current interface.
> > > > 
> > > Well, maybe... Who knows what future reserves ?!? :-D
> > > 
> > > Anyway, although I see your point, I really really dislike the new
> > > parameter in libxl_cpumap_alloc(),
> > 
> > What about it do you dislike? The special meaning of 0 or its existence
> > at all?
> > 
> It's pretty much all about its existence, given the fact it is _always_
> 0 apart from one single case, where it could well be zero as well. :-)

Except as discussed below it can't be zero..

> It's just I find it uncomfortable to have it, but of course I could live
> with it if it buys something. It's the latter I'm not sure I see...
> 
> > > but of course it is not something up
> > > to me to decide, neither it is something I'd loose some sleep for. :-P
> > 
> > You could give vcpus > pcpus (dumb, but e.g. for debugging) and in that
> > case the existing libxl_cpumap_alloc behaviour (which sizes based on the
> > # of phys cpus) is incorrect. 
> >
> Mmm... Maybe this is still related to the fact that on all the test
> boxes I've used, libxl_get_max_cpus() returns something higher than the
> actual physical CPU count of those boxes themselves, but I just created
> an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
> can't, can you?

I think libxl_get_max_cpus and/or libxl_cpumap_alloc involved some
amount of rounding up, if you tried to create a 33 vcpu guest on that
machine (or a machine with <= 32 cpus) it may not work...

> Maybe it is that *_max_cpus() logic that needs some attention? :-O

max_cpus returns the max number of physical cpus, and I think it does so
correctly (perhaps with some slop at the top end). In some cases we want
to talk about virtual cpus and this change lets us size cpumap's of
virtual cpus more appropriately (be that larger or smaller than the
number of physical cpus).


> 
> > I suggested that rather than having
> > libxl_cpumap_alloc_size() we just combine this with the existing fn with
> > a new parameter.
> > 
> Yeah, I checked that in the archives, and that's not the issue for me.
> If the we decide we want the thing, I'm fine with both the 'add new' and
> 'modify the existing' approaches. 
> 
> Thanks and Regards,
> Dario
> |



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOM3-0007Gw-Fx; Fri, 01 Jun 2012 09:41:11 +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 1SaOM1-0007Gg-SU
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:41:10 +0000
Received: from [193.109.254.147:3093] by server-5.bemta-14.messagelabs.com id
	A1/0A-06171-53E88CF4; Fri, 01 Jun 2012 09:41:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1338543667!9523105!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10399 invoked from network); 1 Jun 2012 09:41:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:41:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:41:07 +0100
Message-ID: <1338543666.17466.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 10:41:06 +0100
In-Reply-To: <1338543157.31901.27.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 10:32 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 09:58 +0100, Ian Campbell wrote: 
> > > > And, in future, there are some cases may not need to allocate max size cpumap too
> > > > So it's better to extend the current interface.
> > > > 
> > > Well, maybe... Who knows what future reserves ?!? :-D
> > > 
> > > Anyway, although I see your point, I really really dislike the new
> > > parameter in libxl_cpumap_alloc(),
> > 
> > What about it do you dislike? The special meaning of 0 or its existence
> > at all?
> > 
> It's pretty much all about its existence, given the fact it is _always_
> 0 apart from one single case, where it could well be zero as well. :-)

Except as discussed below it can't be zero..

> It's just I find it uncomfortable to have it, but of course I could live
> with it if it buys something. It's the latter I'm not sure I see...
> 
> > > but of course it is not something up
> > > to me to decide, neither it is something I'd loose some sleep for. :-P
> > 
> > You could give vcpus > pcpus (dumb, but e.g. for debugging) and in that
> > case the existing libxl_cpumap_alloc behaviour (which sizes based on the
> > # of phys cpus) is incorrect. 
> >
> Mmm... Maybe this is still related to the fact that on all the test
> boxes I've used, libxl_get_max_cpus() returns something higher than the
> actual physical CPU count of those boxes themselves, but I just created
> an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
> can't, can you?

I think libxl_get_max_cpus and/or libxl_cpumap_alloc involved some
amount of rounding up, if you tried to create a 33 vcpu guest on that
machine (or a machine with <= 32 cpus) it may not work...

> Maybe it is that *_max_cpus() logic that needs some attention? :-O

max_cpus returns the max number of physical cpus, and I think it does so
correctly (perhaps with some slop at the top end). In some cases we want
to talk about virtual cpus and this change lets us size cpumap's of
virtual cpus more appropriately (be that larger or smaller than the
number of physical cpus).


> 
> > I suggested that rather than having
> > libxl_cpumap_alloc_size() we just combine this with the existing fn with
> > a new parameter.
> > 
> Yeah, I checked that in the archives, and that's not the issue for me.
> If the we decide we want the thing, I'm fine with both the 'add new' and
> 'modify the existing' approaches. 
> 
> Thanks and Regards,
> Dario
> |



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:52:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOW8-0007a4-OS; Fri, 01 Jun 2012 09:51: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 1SaOW6-0007Zz-Sn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:51:35 +0000
Received: from [85.158.143.99:2677] by server-2.bemta-4.messagelabs.com id
	74/57-11595-6A098CF4; Fri, 01 Jun 2012 09:51:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338544291!30556672!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3753 invoked from network); 1 Jun 2012 09:51:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:51:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:51:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:51:30 +0100
Message-ID: <1338544289.17466.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 1 Jun 2012 10:51:29 +0100
In-Reply-To: <4FC76FE7.5070003@eu.citrix.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<980a25d6ad12ba0f10fa.1338299819@cosworth.uk.xensource.com>
	<4FC76FE7.5070003@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 5 V2] libxl: add internal function to
 get a domain's scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 14:19 +0100, George Dunlap wrote:
> On 29/05/12 14:56, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell<ian.campbell@citrix.com>
> > # Date 1338299619 -3600
> > # Node ID 980a25d6ad12ba0f10fa616255b9382cc14ce69e
> > # Parent  12537c670e9ea9e7f73747e203ca318107b82cd9
> > libxl: add internal function to get a domain's scheduler.
> >
> > This takes into account cpupools.
> >
> > Add a helper to get the info for a single cpu pool, refactor libxl_list_cpupool
> > t use this. While there fix the leaks due to not disposing the partial list on
> > realloc failure in that function.
> >
> > Fix the failure of sched_domain_output to free the poolinfo list.
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> As an aside, I would prefer that the clean-up happen in separate 
> patches; having a single patch do several orthogonal things makes it 
> hard for me to tell what goes with what, both for review, and in case 
> someone in the future needs to do archaeology and figure out what's 
> going on.  Not really worth a respin just for that, though.

Agreed in general, and I should know better.

> >
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> > ---
> > v2: add libxl_cpupoolinfo_list_free, use it in libxl_cpupool_list error path.
> >      Also use it in libxl_cpupool_cpuremove_node (which fixes a leak) and in
> >      libxl_name_to_cpupoolid, sched_domain_output and main_cpupoollist (which
> >      also fixes a leak).
> >
> >      Also in libxl_cpupool_cpuremove_node use libxl_cputopology_list_free
> >      instead of open coding
> >
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl.c	Tue May 29 14:53:39 2012 +0100
> > @@ -552,41 +552,70 @@ int libxl_domain_info(libxl_ctx *ctx, li
> >       return 0;
> >   }
> >
> > +static int cpupool_info(libxl__gc *gc,
> > +                        libxl_cpupoolinfo *info,
> > +                        uint32_t poolid,
> > +                        bool exact /* exactly poolid or>= poolid */)
> > +{
> > +    xc_cpupoolinfo_t *xcinfo;
> > +    int rc = ERROR_FAIL;
> > +
> > +    xcinfo = xc_cpupool_getinfo(CTX->xch, poolid);
> > +    if (xcinfo == NULL)
> > +        return ERROR_FAIL;
> > +
> > +    if (exact&&  xcinfo->cpupool_id != poolid)
> > +        goto out;
> > +
> > +    info->poolid = xcinfo->cpupool_id;
> > +    info->sched = xcinfo->sched_id;
> > +    info->n_dom = xcinfo->n_dom;
> > +    if (libxl_cpumap_alloc(CTX,&info->cpumap))
> > +        goto out;
> > +    memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
> > +
> > +    rc = 0;
> > +out:
> > +    xc_cpupool_infofree(CTX->xch, xcinfo);
> > +    return rc;
> > +}
> > +
> > +int libxl_cpupool_info(libxl_ctx *ctx,
> > +                       libxl_cpupoolinfo *info, uint32_t poolid)
> > +{
> > +    GC_INIT(ctx);
> > +    int rc = cpupool_info(gc, info, poolid, true);
> > +    GC_FREE;
> > +    return rc;
> > +}
> > +
> >   libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool)
> >   {
> > -    libxl_cpupoolinfo *ptr, *tmp;
> > +    GC_INIT(ctx);
> > +    libxl_cpupoolinfo info, *ptr, *tmp;
> >       int i;
> > -    xc_cpupoolinfo_t *info;
> >       uint32_t poolid;
> >
> >       ptr = NULL;
> >
> >       poolid = 0;
> >       for (i = 0;; i++) {
> > -        info = xc_cpupool_getinfo(ctx->xch, poolid);
> > -        if (info == NULL)
> > +        if (cpupool_info(gc,&info, poolid, false))
> >               break;
> >           tmp = realloc(ptr, (i + 1) * sizeof(libxl_cpupoolinfo));
> >           if (!tmp) {
> >               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpupool info");
> > -            free(ptr);
> > -            xc_cpupool_infofree(ctx->xch, info);
> > -            return NULL;
> > +            libxl_cpupoolinfo_list_free(ptr, i);
> > +            goto out;
> >           }
> >           ptr = tmp;
> > -        ptr[i].poolid = info->cpupool_id;
> > -        ptr[i].sched = info->sched_id;
> > -        ptr[i].n_dom = info->n_dom;
> > -        if (libxl_cpumap_alloc(ctx,&ptr[i].cpumap)) {
> > -            xc_cpupool_infofree(ctx->xch, info);
> > -            break;
> > -        }
> > -        memcpy(ptr[i].cpumap.map, info->cpumap, ptr[i].cpumap.size);
> > -        poolid = info->cpupool_id + 1;
> > -        xc_cpupool_infofree(ctx->xch, info);
> > +        ptr[i] = info;
> > +        poolid = info.poolid + 1;
> >       }
> >
> >       *nb_pool = i;
> > +out:
> > +    GC_FREE;
> >       return ptr;
> >   }
> >
> > @@ -3932,14 +3961,10 @@ int libxl_cpupool_cpuremove_node(libxl_c
> >           }
> >       }
> >
> > -    for (cpu = 0; cpu<  nr_cpus; cpu++)
> > -        libxl_cputopology_dispose(&topology[cpu]);
> > -    free(topology);
> > +    libxl_cputopology_list_free(topology, nr_cpus);
> >
> >   out:
> > -    for (p = 0; p<  n_pools; p++) {
> > -        libxl_cpupoolinfo_dispose(poolinfo + p);
> > -    }
> > +    libxl_cpupoolinfo_list_free(poolinfo, n_pools);
> >
> >       return ret;
> >   }
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl.h	Tue May 29 14:53:39 2012 +0100
> > @@ -576,6 +576,7 @@ int libxl_domain_info(libxl_ctx*, libxl_
> >   libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
> >   void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
> >   libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
> > +void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr);
> >   libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
> >   void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
> >
> > @@ -829,6 +830,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx
> >   int libxl_cpupool_cpuremove(libxl_ctx *ctx, uint32_t poolid, int cpu);
> >   int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus);
> >   int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid);
> > +int libxl_cpupool_info(libxl_ctx *ctx, libxl_cpupoolinfo *info, uint32_t poolid);
> >
> >   int libxl_domid_valid_guest(uint32_t domid);
> >
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_dom.c	Tue May 29 14:53:39 2012 +0100
> > @@ -93,6 +93,41 @@ int libxl__domain_shutdown_reason(libxl_
> >       return (info.flags>>  XEN_DOMINF_shutdownshift)&  XEN_DOMINF_shutdownmask;
> >   }
> >
> > +int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid)
> > +{
> > +    xc_domaininfo_t info;
> > +    int ret;
> > +
> > +    ret = xc_domain_getinfolist(CTX->xch, domid, 1,&info);
> > +    if (ret != 1)
> > +        return ERROR_FAIL;
> > +    if (info.domain != domid)
> > +        return ERROR_FAIL;
> > +
> > +    return info.cpupool;
> > +}
> > +
> > +libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid)
> > +{
> > +    uint32_t cpupool = libxl__domain_cpupool(gc, domid);
> > +    libxl_cpupoolinfo poolinfo;
> > +    libxl_scheduler sched = LIBXL_SCHEDULER_UNKNOWN;
> > +    int rc;
> > +
> > +    if (cpupool<  0)
> > +        return sched;
> > +
> > +    rc = libxl_cpupool_info(CTX,&poolinfo, cpupool);
> > +    if (rc<  0)
> > +        goto out;
> > +
> > +    sched = poolinfo.sched;
> > +
> > +out:
> > +    libxl_cpupoolinfo_dispose(&poolinfo);
> > +    return sched;
> > +}
> > +
> >   int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> >                 libxl_domain_build_info *info, libxl__domain_build_state *state)
> >   {
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_internal.h	Tue May 29 14:53:39 2012 +0100
> > @@ -738,6 +738,8 @@ _hidden int libxl__file_reference_unmap(
> >   /* from xl_dom */
> >   _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
> >   _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
> > +_hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
> > +_hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
> >   _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams);
> >   #define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
> >       libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_types.idl	Tue May 29 14:53:39 2012 +0100
> > @@ -107,7 +107,9 @@ libxl_bios_type = Enumeration("bios_type
> >       ])
> >
> >   # Consistent with values defined in domctl.h
> > +# Except unknown which we have made up
> >   libxl_scheduler = Enumeration("scheduler", [
> > +    (0, "unknown"),
> >       (4, "sedf"),
> >       (5, "credit"),
> >       (6, "credit2"),
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_utils.c	Tue May 29 14:53:39 2012 +0100
> > @@ -133,9 +133,8 @@ int libxl_name_to_cpupoolid(libxl_ctx *c
> >               }
> >               free(poolname);
> >           }
> > -        libxl_cpupoolinfo_dispose(poolinfo + i);
> >       }
> > -    free(poolinfo);
> > +    libxl_cpupoolinfo_list_free(poolinfo, nb_pools);
> >       return ret;
> >   }
> >
> > @@ -686,6 +685,14 @@ void libxl_vminfo_list_free(libxl_vminfo
> >       free(list);
> >   }
> >
> > +void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr)
> > +{
> > +    int i;
> > +    for (i = 0; i<  nr; i++)
> > +        libxl_cpupoolinfo_dispose(&list[i]);
> > +    free(list);
> > +}
> > +
> >   int libxl_domid_valid_guest(uint32_t domid)
> >   {
> >       /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c	Tue May 29 14:53:39 2012 +0100
> > @@ -4608,11 +4608,8 @@ static int sched_domain_output(libxl_sch
> >                   break;
> >           }
> >       }
> > -    if (poolinfo) {
> > -        for (p = 0; p<  n_pools; p++) {
> > -            libxl_cpupoolinfo_dispose(poolinfo + p);
> > -        }
> > -    }
> > +    if (poolinfo)
> > +        libxl_cpupoolinfo_list_free(poolinfo, n_pools);
> >       return 0;
> >   }
> >
> > @@ -6119,8 +6116,9 @@ int main_cpupoollist(int argc, char **ar
> >                   printf("\n");
> >               }
> >           }
> > -        libxl_cpupoolinfo_dispose(poolinfo + p);
> > -    }
> > +    }
> > +
> > +    libxl_cpupoolinfo_list_free(poolinfo, n_pools);
> >
> >       return ret;
> >   }
> 



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 09:52:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 09: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 1SaOW8-0007a4-OS; Fri, 01 Jun 2012 09:51: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 1SaOW6-0007Zz-Sn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 09:51:35 +0000
Received: from [85.158.143.99:2677] by server-2.bemta-4.messagelabs.com id
	74/57-11595-6A098CF4; Fri, 01 Jun 2012 09:51:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338544291!30556672!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3753 invoked from network); 1 Jun 2012 09:51:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 09:51:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 09:51:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	10:51:30 +0100
Message-ID: <1338544289.17466.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 1 Jun 2012 10:51:29 +0100
In-Reply-To: <4FC76FE7.5070003@eu.citrix.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<980a25d6ad12ba0f10fa.1338299819@cosworth.uk.xensource.com>
	<4FC76FE7.5070003@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 5 V2] libxl: add internal function to
 get a domain's scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 14:19 +0100, George Dunlap wrote:
> On 29/05/12 14:56, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell<ian.campbell@citrix.com>
> > # Date 1338299619 -3600
> > # Node ID 980a25d6ad12ba0f10fa616255b9382cc14ce69e
> > # Parent  12537c670e9ea9e7f73747e203ca318107b82cd9
> > libxl: add internal function to get a domain's scheduler.
> >
> > This takes into account cpupools.
> >
> > Add a helper to get the info for a single cpu pool, refactor libxl_list_cpupool
> > t use this. While there fix the leaks due to not disposing the partial list on
> > realloc failure in that function.
> >
> > Fix the failure of sched_domain_output to free the poolinfo list.
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> As an aside, I would prefer that the clean-up happen in separate 
> patches; having a single patch do several orthogonal things makes it 
> hard for me to tell what goes with what, both for review, and in case 
> someone in the future needs to do archaeology and figure out what's 
> going on.  Not really worth a respin just for that, though.

Agreed in general, and I should know better.

> >
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> > ---
> > v2: add libxl_cpupoolinfo_list_free, use it in libxl_cpupool_list error path.
> >      Also use it in libxl_cpupool_cpuremove_node (which fixes a leak) and in
> >      libxl_name_to_cpupoolid, sched_domain_output and main_cpupoollist (which
> >      also fixes a leak).
> >
> >      Also in libxl_cpupool_cpuremove_node use libxl_cputopology_list_free
> >      instead of open coding
> >
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl.c	Tue May 29 14:53:39 2012 +0100
> > @@ -552,41 +552,70 @@ int libxl_domain_info(libxl_ctx *ctx, li
> >       return 0;
> >   }
> >
> > +static int cpupool_info(libxl__gc *gc,
> > +                        libxl_cpupoolinfo *info,
> > +                        uint32_t poolid,
> > +                        bool exact /* exactly poolid or>= poolid */)
> > +{
> > +    xc_cpupoolinfo_t *xcinfo;
> > +    int rc = ERROR_FAIL;
> > +
> > +    xcinfo = xc_cpupool_getinfo(CTX->xch, poolid);
> > +    if (xcinfo == NULL)
> > +        return ERROR_FAIL;
> > +
> > +    if (exact&&  xcinfo->cpupool_id != poolid)
> > +        goto out;
> > +
> > +    info->poolid = xcinfo->cpupool_id;
> > +    info->sched = xcinfo->sched_id;
> > +    info->n_dom = xcinfo->n_dom;
> > +    if (libxl_cpumap_alloc(CTX,&info->cpumap))
> > +        goto out;
> > +    memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
> > +
> > +    rc = 0;
> > +out:
> > +    xc_cpupool_infofree(CTX->xch, xcinfo);
> > +    return rc;
> > +}
> > +
> > +int libxl_cpupool_info(libxl_ctx *ctx,
> > +                       libxl_cpupoolinfo *info, uint32_t poolid)
> > +{
> > +    GC_INIT(ctx);
> > +    int rc = cpupool_info(gc, info, poolid, true);
> > +    GC_FREE;
> > +    return rc;
> > +}
> > +
> >   libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool)
> >   {
> > -    libxl_cpupoolinfo *ptr, *tmp;
> > +    GC_INIT(ctx);
> > +    libxl_cpupoolinfo info, *ptr, *tmp;
> >       int i;
> > -    xc_cpupoolinfo_t *info;
> >       uint32_t poolid;
> >
> >       ptr = NULL;
> >
> >       poolid = 0;
> >       for (i = 0;; i++) {
> > -        info = xc_cpupool_getinfo(ctx->xch, poolid);
> > -        if (info == NULL)
> > +        if (cpupool_info(gc,&info, poolid, false))
> >               break;
> >           tmp = realloc(ptr, (i + 1) * sizeof(libxl_cpupoolinfo));
> >           if (!tmp) {
> >               LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpupool info");
> > -            free(ptr);
> > -            xc_cpupool_infofree(ctx->xch, info);
> > -            return NULL;
> > +            libxl_cpupoolinfo_list_free(ptr, i);
> > +            goto out;
> >           }
> >           ptr = tmp;
> > -        ptr[i].poolid = info->cpupool_id;
> > -        ptr[i].sched = info->sched_id;
> > -        ptr[i].n_dom = info->n_dom;
> > -        if (libxl_cpumap_alloc(ctx,&ptr[i].cpumap)) {
> > -            xc_cpupool_infofree(ctx->xch, info);
> > -            break;
> > -        }
> > -        memcpy(ptr[i].cpumap.map, info->cpumap, ptr[i].cpumap.size);
> > -        poolid = info->cpupool_id + 1;
> > -        xc_cpupool_infofree(ctx->xch, info);
> > +        ptr[i] = info;
> > +        poolid = info.poolid + 1;
> >       }
> >
> >       *nb_pool = i;
> > +out:
> > +    GC_FREE;
> >       return ptr;
> >   }
> >
> > @@ -3932,14 +3961,10 @@ int libxl_cpupool_cpuremove_node(libxl_c
> >           }
> >       }
> >
> > -    for (cpu = 0; cpu<  nr_cpus; cpu++)
> > -        libxl_cputopology_dispose(&topology[cpu]);
> > -    free(topology);
> > +    libxl_cputopology_list_free(topology, nr_cpus);
> >
> >   out:
> > -    for (p = 0; p<  n_pools; p++) {
> > -        libxl_cpupoolinfo_dispose(poolinfo + p);
> > -    }
> > +    libxl_cpupoolinfo_list_free(poolinfo, n_pools);
> >
> >       return ret;
> >   }
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl.h	Tue May 29 14:53:39 2012 +0100
> > @@ -576,6 +576,7 @@ int libxl_domain_info(libxl_ctx*, libxl_
> >   libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
> >   void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
> >   libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
> > +void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr);
> >   libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
> >   void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
> >
> > @@ -829,6 +830,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx
> >   int libxl_cpupool_cpuremove(libxl_ctx *ctx, uint32_t poolid, int cpu);
> >   int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus);
> >   int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid);
> > +int libxl_cpupool_info(libxl_ctx *ctx, libxl_cpupoolinfo *info, uint32_t poolid);
> >
> >   int libxl_domid_valid_guest(uint32_t domid);
> >
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_dom.c	Tue May 29 14:53:39 2012 +0100
> > @@ -93,6 +93,41 @@ int libxl__domain_shutdown_reason(libxl_
> >       return (info.flags>>  XEN_DOMINF_shutdownshift)&  XEN_DOMINF_shutdownmask;
> >   }
> >
> > +int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid)
> > +{
> > +    xc_domaininfo_t info;
> > +    int ret;
> > +
> > +    ret = xc_domain_getinfolist(CTX->xch, domid, 1,&info);
> > +    if (ret != 1)
> > +        return ERROR_FAIL;
> > +    if (info.domain != domid)
> > +        return ERROR_FAIL;
> > +
> > +    return info.cpupool;
> > +}
> > +
> > +libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid)
> > +{
> > +    uint32_t cpupool = libxl__domain_cpupool(gc, domid);
> > +    libxl_cpupoolinfo poolinfo;
> > +    libxl_scheduler sched = LIBXL_SCHEDULER_UNKNOWN;
> > +    int rc;
> > +
> > +    if (cpupool<  0)
> > +        return sched;
> > +
> > +    rc = libxl_cpupool_info(CTX,&poolinfo, cpupool);
> > +    if (rc<  0)
> > +        goto out;
> > +
> > +    sched = poolinfo.sched;
> > +
> > +out:
> > +    libxl_cpupoolinfo_dispose(&poolinfo);
> > +    return sched;
> > +}
> > +
> >   int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> >                 libxl_domain_build_info *info, libxl__domain_build_state *state)
> >   {
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_internal.h	Tue May 29 14:53:39 2012 +0100
> > @@ -738,6 +738,8 @@ _hidden int libxl__file_reference_unmap(
> >   /* from xl_dom */
> >   _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
> >   _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
> > +_hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
> > +_hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
> >   _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams);
> >   #define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
> >       libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_types.idl	Tue May 29 14:53:39 2012 +0100
> > @@ -107,7 +107,9 @@ libxl_bios_type = Enumeration("bios_type
> >       ])
> >
> >   # Consistent with values defined in domctl.h
> > +# Except unknown which we have made up
> >   libxl_scheduler = Enumeration("scheduler", [
> > +    (0, "unknown"),
> >       (4, "sedf"),
> >       (5, "credit"),
> >       (6, "credit2"),
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/libxl_utils.c	Tue May 29 14:53:39 2012 +0100
> > @@ -133,9 +133,8 @@ int libxl_name_to_cpupoolid(libxl_ctx *c
> >               }
> >               free(poolname);
> >           }
> > -        libxl_cpupoolinfo_dispose(poolinfo + i);
> >       }
> > -    free(poolinfo);
> > +    libxl_cpupoolinfo_list_free(poolinfo, nb_pools);
> >       return ret;
> >   }
> >
> > @@ -686,6 +685,14 @@ void libxl_vminfo_list_free(libxl_vminfo
> >       free(list);
> >   }
> >
> > +void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr)
> > +{
> > +    int i;
> > +    for (i = 0; i<  nr; i++)
> > +        libxl_cpupoolinfo_dispose(&list[i]);
> > +    free(list);
> > +}
> > +
> >   int libxl_domid_valid_guest(uint32_t domid)
> >   {
> >       /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
> > diff -r 12537c670e9e -r 980a25d6ad12 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Tue May 29 12:56:57 2012 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c	Tue May 29 14:53:39 2012 +0100
> > @@ -4608,11 +4608,8 @@ static int sched_domain_output(libxl_sch
> >                   break;
> >           }
> >       }
> > -    if (poolinfo) {
> > -        for (p = 0; p<  n_pools; p++) {
> > -            libxl_cpupoolinfo_dispose(poolinfo + p);
> > -        }
> > -    }
> > +    if (poolinfo)
> > +        libxl_cpupoolinfo_list_free(poolinfo, n_pools);
> >       return 0;
> >   }
> >
> > @@ -6119,8 +6116,9 @@ int main_cpupoollist(int argc, char **ar
> >                   printf("\n");
> >               }
> >           }
> > -        libxl_cpupoolinfo_dispose(poolinfo + p);
> > -    }
> > +    }
> > +
> > +    libxl_cpupoolinfo_list_free(poolinfo, n_pools);
> >
> >       return ret;
> >   }
> 



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:09:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOnY-0008N1-6A; Fri, 01 Jun 2012 10:09: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 1SaOnW-0008Mw-Jt
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:09:34 +0000
Received: from [85.158.143.99:11451] by server-3.bemta-4.messagelabs.com id
	C3/A8-04252-DD498CF4; Fri, 01 Jun 2012 10:09:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338545372!25609129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24577 invoked from network); 1 Jun 2012 10:09:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:09:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:09:31 +0100
Message-ID: <1338545370.17466.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bamvor Jian Zhang <bjzhang@suse.com>
Date: Fri, 1 Jun 2012 11:09:30 +0100
In-Reply-To: <3496f86000b80595b34a.1338535311@linux-x12>
References: <3496f86000b80595b34a.1338535311@linux-x12>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"jfehlig@suse.com" <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
>  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
> tty) will lead to null pointer access in CTX maco. 

I haven't looked at the rest of the patch you but thought I'd pick up on
this now since we have at least one existing libxl__strdup(0, ..) in
        b_info->blkdev_start = libxl__strdup(0, "xvda");
        
so we need to decide what to do in general. libxl__strdup wants the CTX
so it can complain via the logs on malloc failure.

This looks like a problem even with the functions which take a
"gc_opt" (i.e. where gc==NULL is explicitly supposed to be allowed).

libxl__alloc_failed() could take a gc_opt instead of a ctx and only log
if it is non-null. It already also logs via stderr, since this is a
catastrophic failure from which we won't return.

We could also have a process-global libxl_alloc_failure_hook(const char
*argh) to allow the calling application to have some chance to log via
its own routines...

IanJ -- you added all this, what do you think?

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:09:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOnY-0008N1-6A; Fri, 01 Jun 2012 10:09: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 1SaOnW-0008Mw-Jt
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:09:34 +0000
Received: from [85.158.143.99:11451] by server-3.bemta-4.messagelabs.com id
	C3/A8-04252-DD498CF4; Fri, 01 Jun 2012 10:09:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338545372!25609129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24577 invoked from network); 1 Jun 2012 10:09:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12782944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:09:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:09:31 +0100
Message-ID: <1338545370.17466.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bamvor Jian Zhang <bjzhang@suse.com>
Date: Fri, 1 Jun 2012 11:09:30 +0100
In-Reply-To: <3496f86000b80595b34a.1338535311@linux-x12>
References: <3496f86000b80595b34a.1338535311@linux-x12>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"jfehlig@suse.com" <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
>  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
> tty) will lead to null pointer access in CTX maco. 

I haven't looked at the rest of the patch you but thought I'd pick up on
this now since we have at least one existing libxl__strdup(0, ..) in
        b_info->blkdev_start = libxl__strdup(0, "xvda");
        
so we need to decide what to do in general. libxl__strdup wants the CTX
so it can complain via the logs on malloc failure.

This looks like a problem even with the functions which take a
"gc_opt" (i.e. where gc==NULL is explicitly supposed to be allowed).

libxl__alloc_failed() could take a gc_opt instead of a ctx and only log
if it is non-null. It already also logs via stderr, since this is a
catastrophic failure from which we won't return.

We could also have a process-global libxl_alloc_failure_hook(const char
*argh) to allow the calling application to have some chance to log via
its own routines...

IanJ -- you added all this, what do you think?

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOr9-00005S-R0; Fri, 01 Jun 2012 10:13:19 +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 1SaOr9-00005L-Ap
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:13:19 +0000
Received: from [193.109.254.147:64822] by server-4.bemta-14.messagelabs.com id
	05/11-03148-EB598CF4; Fri, 01 Jun 2012 10:13:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338545596!4647704!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5361 invoked from network); 1 Jun 2012 10:13:17 -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;
	1 Jun 2012 10:13:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26510326"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:13:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:13:15 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaOr5-0005HJ-Hr;
	Fri, 01 Jun 2012 11:13:15 +0100
Message-ID: <4FC89556.7090502@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:11:34 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338539390.17466.26.camel@zakaz.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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/06/12 09:29, Ian Campbell wrote:
> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>> <George.Dunlap@eu.citrix.com>  wrote:
>>> The strange thing is that there *is* a pygrub in the right place, so
>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>> It's seems that the right on the script are already set to 755 by the
>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
> What is the conclusion here? Is the original patch correct and/or is
> there a subsequent additional fix?
There is a bug (pygrub is installed both in $(DESTDIR)/foo and 
$(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly 
fixes the bug (only installed in $(DESTDIR).

I think there is a redundant command in the Makefile as well, where 
pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause 
incorrect behavior, but I would probably still consider it a bug.

So the original patch is correct, but there is a subsequent fix.
> My scripts does things like:
>          make -C tools XEN_TARGET_ARCH=x86_32 DESTDIR=/tmp/tmp0_hnbt LIBXL_TESTIDL_SEED=42 debug=y -j12 install
> then tars up /tmp/tmp0_hnbt, copies it to my test box and untars. I've
> just noticed on my test box:
>          # ls -dl /tmp/tmp*
>          drwxr-xr-x 3 root root 4096 Jun  1 09:26 /tmp/tmp0_hnbt
>          drwxr-xr-x 3 root root 4096 May 18 11:11 /tmp/tmp8D2Mvc
>          drwxr-xr-x 3 root root 4096 May 25 10:21 /tmp/tmpAd2OFq
>          drwxr-xr-x 3 root root 4096 May 18 15:05 /tmp/tmpEqYZpf
>          [...]
>          # find /tmp/tmp* -name pygrub | wc -l
>          19
The "right thing" is to find find 2 files named "pygrub" per directory 
(a binary at /usr/lib/xen/bin/pygrub and a link to that binary at 
/usr/bin/pygrub, for compatibility).  Without Anthony's patch you would 
get 3.  Not sure how that corresponds to the directories you have there...

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOr9-00005S-R0; Fri, 01 Jun 2012 10:13:19 +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 1SaOr9-00005L-Ap
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:13:19 +0000
Received: from [193.109.254.147:64822] by server-4.bemta-14.messagelabs.com id
	05/11-03148-EB598CF4; Fri, 01 Jun 2012 10:13:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338545596!4647704!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5361 invoked from network); 1 Jun 2012 10:13:17 -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;
	1 Jun 2012 10:13:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26510326"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:13:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:13:15 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaOr5-0005HJ-Hr;
	Fri, 01 Jun 2012 11:13:15 +0100
Message-ID: <4FC89556.7090502@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:11:34 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338539390.17466.26.camel@zakaz.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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/06/12 09:29, Ian Campbell wrote:
> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>> <George.Dunlap@eu.citrix.com>  wrote:
>>> The strange thing is that there *is* a pygrub in the right place, so
>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>> It's seems that the right on the script are already set to 755 by the
>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
> What is the conclusion here? Is the original patch correct and/or is
> there a subsequent additional fix?
There is a bug (pygrub is installed both in $(DESTDIR)/foo and 
$(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly 
fixes the bug (only installed in $(DESTDIR).

I think there is a redundant command in the Makefile as well, where 
pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause 
incorrect behavior, but I would probably still consider it a bug.

So the original patch is correct, but there is a subsequent fix.
> My scripts does things like:
>          make -C tools XEN_TARGET_ARCH=x86_32 DESTDIR=/tmp/tmp0_hnbt LIBXL_TESTIDL_SEED=42 debug=y -j12 install
> then tars up /tmp/tmp0_hnbt, copies it to my test box and untars. I've
> just noticed on my test box:
>          # ls -dl /tmp/tmp*
>          drwxr-xr-x 3 root root 4096 Jun  1 09:26 /tmp/tmp0_hnbt
>          drwxr-xr-x 3 root root 4096 May 18 11:11 /tmp/tmp8D2Mvc
>          drwxr-xr-x 3 root root 4096 May 25 10:21 /tmp/tmpAd2OFq
>          drwxr-xr-x 3 root root 4096 May 18 15:05 /tmp/tmpEqYZpf
>          [...]
>          # find /tmp/tmp* -name pygrub | wc -l
>          19
The "right thing" is to find find 2 files named "pygrub" per directory 
(a binary at /usr/lib/xen/bin/pygrub and a link to that binary at 
/usr/bin/pygrub, for compatibility).  Without Anthony's patch you would 
get 3.  Not sure how that corresponds to the directories you have there...

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaOs3-000090-8t; Fri, 01 Jun 2012 10:14: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 1SaOs2-00008q-Bl
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:14:14 +0000
Received: from [85.158.143.35:23742] by server-2.bemta-4.messagelabs.com id
	60/28-11595-5F598CF4; Fri, 01 Jun 2012 10:14:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338545652!15805742!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6285 invoked from network); 1 Jun 2012 10:14:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:14:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:14:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:14:11 +0100
Message-ID: <1338545650.17466.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 11:14:10 +0100
In-Reply-To: <1338364837.2609.24.camel@Abyss>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<274de8e1e0d116070d34.1338299821@cosworth.uk.xensource.com>
	<1338362793.2609.20.camel@Abyss>
	<1338363341.31698.17.camel@zakaz.uk.xensource.com>
	<1338364837.2609.24.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-05-30 at 09:00 +0100, Dario Faggioli wrote:
> On Wed, 2012-05-30 at 08:35 +0100, Ian Campbell wrote: 
> > > That being said, I'm not sure at what level we want to enforce something
> > > like the above. The lowest level toolstack seems fine to me, which would
> > > mean putting something like the code above in the config file parsing...
> > > If you agree, I'll try that and let you know whether or not it works.
> > 
> > If you could provide an incremental patch that would be much
> > appreciated.
> > 
> I sure can. :-)
> 
> > IMHO it would be fine (and a good idea) for libxl to return ERROR_INVAL
> > if the conditions aren't met too. 
> >
> Ok, sounds reasonable.
> 
> > If you want to also check it in xl's
> > config file parsing and either fix it up like the above or error out
> > then please do.
> >
> Let's see what fits better...

Thanks. I'm going to commit this as is and await the fixup, if that's
ok. I think this isn't a regression from the PoV of the configuration
file since this would also have happened before.

> 
> Dario
> 



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaOs3-000090-8t; Fri, 01 Jun 2012 10:14: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 1SaOs2-00008q-Bl
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:14:14 +0000
Received: from [85.158.143.35:23742] by server-2.bemta-4.messagelabs.com id
	60/28-11595-5F598CF4; Fri, 01 Jun 2012 10:14:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338545652!15805742!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6285 invoked from network); 1 Jun 2012 10:14:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:14:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:14:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:14:11 +0100
Message-ID: <1338545650.17466.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 11:14:10 +0100
In-Reply-To: <1338364837.2609.24.camel@Abyss>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<274de8e1e0d116070d34.1338299821@cosworth.uk.xensource.com>
	<1338362793.2609.20.camel@Abyss>
	<1338363341.31698.17.camel@zakaz.uk.xensource.com>
	<1338364837.2609.24.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-05-30 at 09:00 +0100, Dario Faggioli wrote:
> On Wed, 2012-05-30 at 08:35 +0100, Ian Campbell wrote: 
> > > That being said, I'm not sure at what level we want to enforce something
> > > like the above. The lowest level toolstack seems fine to me, which would
> > > mean putting something like the code above in the config file parsing...
> > > If you agree, I'll try that and let you know whether or not it works.
> > 
> > If you could provide an incremental patch that would be much
> > appreciated.
> > 
> I sure can. :-)
> 
> > IMHO it would be fine (and a good idea) for libxl to return ERROR_INVAL
> > if the conditions aren't met too. 
> >
> Ok, sounds reasonable.
> 
> > If you want to also check it in xl's
> > config file parsing and either fix it up like the above or error out
> > then please do.
> >
> Let's see what fits better...

Thanks. I'm going to commit this as is and await the fixup, if that's
ok. I think this isn't a regression from the PoV of the configuration
file since this would also have happened before.

> 
> Dario
> 



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:17:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:17: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 1SaOvA-0000LO-S3; Fri, 01 Jun 2012 10:17:28 +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 1SaOv9-0000LA-FX
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:17:27 +0000
Received: from [193.109.254.147:9730] by server-12.bemta-14.messagelabs.com id
	7B/FA-12643-5B698CF4; Fri, 01 Jun 2012 10:17:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338545845!7183760!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12451 invoked from network); 1 Jun 2012 10:17:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:17:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:16:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 11:16:44 +0100
Date: Fri, 1 Jun 2012 11:16:29 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120531181712.GA19700@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 31 May 2012, Konrad Rzeszutek Wilk wrote:
> The blkfront_remove part is .. that is going to take some surgery to do
> and I don't think I am going to be able to attempt that within the next couple
> of weeks. So lets put that on the TODO list and just do this one?

OK

> >From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]
> [v2: Add extra check in add_id_to_freelist]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
>  1 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 60eed4b..c7ef8a4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info *info)
>  static void add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	BUG_ON(info->shadow[id].req.u.rw.id != id);
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> +	BUG_ON(info->shadow[id].request == NULL);
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
>  }

Like Jan said, it would be best to change the two BUG_ON into WARN_ON
and return an error.


> +static const char *op_name(int op)
> +{
> +	const char *names[BLKIF_OP_DISCARD+1] = {
> +		"read" , "write", "barrier", "flush", "reserved", "discard"};
> +
> +	if (op > BLKIF_OP_DISCARD)
> +		return "unknown";
> +	return names[op];
> +}

Considering that op is an int, shoudn't we check for negative values
too?


>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -746,6 +757,18 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE) {
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			WARN(1, "%s: response to %s has incorrect id (%d)!\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			continue;
> +		}
>  		req  = info->shadow[id].request;

Do you think it would be better to goto error_out, instead of continue?
I guess that depends on whether we expect the other requests to be in a
good shape or not...

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:17:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:17: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 1SaOvA-0000LO-S3; Fri, 01 Jun 2012 10:17:28 +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 1SaOv9-0000LA-FX
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:17:27 +0000
Received: from [193.109.254.147:9730] by server-12.bemta-14.messagelabs.com id
	7B/FA-12643-5B698CF4; Fri, 01 Jun 2012 10:17:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338545845!7183760!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12451 invoked from network); 1 Jun 2012 10:17:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:17:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:16:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 11:16:44 +0100
Date: Fri, 1 Jun 2012 11:16:29 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120531181712.GA19700@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 31 May 2012, Konrad Rzeszutek Wilk wrote:
> The blkfront_remove part is .. that is going to take some surgery to do
> and I don't think I am going to be able to attempt that within the next couple
> of weeks. So lets put that on the TODO list and just do this one?

OK

> >From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]
> [v2: Add extra check in add_id_to_freelist]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
>  1 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 60eed4b..c7ef8a4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info *info)
>  static void add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	BUG_ON(info->shadow[id].req.u.rw.id != id);
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> +	BUG_ON(info->shadow[id].request == NULL);
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
>  }

Like Jan said, it would be best to change the two BUG_ON into WARN_ON
and return an error.


> +static const char *op_name(int op)
> +{
> +	const char *names[BLKIF_OP_DISCARD+1] = {
> +		"read" , "write", "barrier", "flush", "reserved", "discard"};
> +
> +	if (op > BLKIF_OP_DISCARD)
> +		return "unknown";
> +	return names[op];
> +}

Considering that op is an int, shoudn't we check for negative values
too?


>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -746,6 +757,18 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE) {
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			WARN(1, "%s: response to %s has incorrect id (%d)!\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			continue;
> +		}
>  		req  = info->shadow[id].request;

Do you think it would be better to goto error_out, instead of continue?
I guess that depends on whether we expect the other requests to be in a
good shape or not...

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOxA-0000TS-HA; Fri, 01 Jun 2012 10:19:32 +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 1SaOx8-0000T7-Jp
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:19:30 +0000
Received: from [193.109.254.147:15104] by server-4.bemta-14.messagelabs.com id
	ED/E7-03148-13798CF4; Fri, 01 Jun 2012 10:19:29 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338545967!12144200!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10696 invoked from network); 1 Jun 2012 10:19:28 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:19:28 -0000
Received: by eekd41 with SMTP id d41so906638eek.32
	for <multiple recipients>; Fri, 01 Jun 2012 03:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=8uOP5xsUONlrGN/vzHDkvmqAGPNy/l+BTPiVktyxf8w=;
	b=XdglF9Aq3Synog8YsAu65g47kxgRsmf+PtVj5ESLVHDrYMN94b9xV1ONW84ghxLJWx
	tGvrFxY3MxvRhZolWuOI3N9lqKC5FXtxi1hogmvlbLCrU7qFUouRWXGJjC79tG8xe+oZ
	MG9RrwzqsG7g/phsPym0sSYk0qaEvoGKUKwO4UNZ2QaQc4hFKtIOVCKgqmIpSAoeC/nD
	yUkn5TJAwzL10Hf165imkLvUWaz5RU6Ws3Lf/nPJimYpx3m8ivJEk1YdlyjGFDZXskcZ
	sZXj6S4oKG5kKG68olmX9m3cvOlH853IKSy2GVMcsxCw8DK2X/SyGjVRioRJX+OZdoLn
	TUEA==
Received: by 10.14.97.77 with SMTP id s53mr1032470eef.104.1338545967713;
	Fri, 01 Jun 2012 03:19:27 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id u7sm5281597eeb.7.2012.06.01.03.19.25
	(version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 03:19:26 -0700 (PDT)
Message-ID: <4FC8972B.6060202@xen.org>
Date: Fri, 01 Jun 2012 11:19:23 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
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="===============4678443566369879006=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4678443566369879006==
Content-Type: multipart/alternative;
 boundary="------------010702070000020506000500"

This is a multi-part message in MIME format.
--------------010702070000020506000500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

at the last Xen Docs Day I got feedback that it is too hard to find 
useful information from the wiki front page. Also, much of the 
information on the front page (the list of categories) is actually 
duplicated on the wiki navigation bar.

There were a few items of feedback I received:
1) The front page should be more use-case driven and be aimed at 
beginners and users
2) Wiki Search is broken.
- Actually it is not, the UI design of search in MediaWiki is bad.
- Typing "Foo"+return into the search box will actually perform Go(Foo) 
which searches for "Foo" in titles only
- To search you need to type "Foo" and press search
3) Google search is broken.
- Some redirects are still needed but mostly we have fixed this now.
- The ones we know of are: (e.g. wiki.*xen*source.com is still hanging 
around)
- If you find SEO issues: let us know at http://wiki.xen.org/wiki/SEO_Issues

To facilitate the discussion on the new front-page, I created a proposal 
space for everybody to play with and make proposals
- http://wiki.xen.org/wiki/Proposals/ : list of proposals
- http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case 
focussed front-page
- http://wiki.xen.org/wiki/Talk:Proposals/Main_Page1 : discussion page, 
feel free to add
- http://wiki.xen.org/wiki/Proposals/Main_Page2 : a copy of the previous 
page, feel free to change
- http://wiki.xen.org/wiki/Talk:Proposals/Main_Page2 : discussion page, 
feel free to add

Feel free to add new proposals

Best Regards
Lars

--------------010702070000020506000500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    at the last Xen Docs Day I got feedback that it is too hard to find
    useful information from the wiki front page. Also, much of the
    information on the front page (the list of categories) is actually
    duplicated on the wiki navigation bar.<br>
    <br>
    There were a few items of feedback I received:<br>
    1) The front page should be more use-case driven and be aimed at
    beginners and users<br>
    2) Wiki Search is broken. <br>
    - Actually it is not, the UI design of search in MediaWiki is bad.&nbsp;
    <br>
    - Typing "Foo"+return into the search box will actually perform
    Go(Foo) which searches for "Foo" in titles only<br>
    - To search you need to type "Foo" and press search<br>
    3) Google search is broken. <br>
    - Some redirects are still needed but mostly&nbsp;<cite></cite>we have
    fixed this now.<br>
    - The ones we know of are: (e.g. <cite>wiki.<b>xen</b>source.com is
      still hanging around) </cite><br>
    - If you find SEO issues: let us know at
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/SEO_Issues">http://wiki.xen.org/wiki/SEO_Issues</a><br>
    <br>
    To facilitate the discussion on the new front-page, I created a
    proposal space for everybody to play with and make proposals<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Proposals/">http://wiki.xen.org/wiki/Proposals/</a> : list of proposals<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Proposals/Main_Page1">http://wiki.xen.org/wiki/Proposals/Main_Page1</a> : a more use-case
    focussed front-page<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Talk:Proposals/Main_Page1">http://wiki.xen.org/wiki/Talk:Proposals/Main_Page1</a> : discussion
    page, feel free to add<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Proposals/Main_Page2">http://wiki.xen.org/wiki/Proposals/Main_Page2</a> : a copy of the
    previous page, feel free to change<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Talk:Proposals/Main_Page2">http://wiki.xen.org/wiki/Talk:Proposals/Main_Page2</a> : discussion
    page, feel free to add<br>
    <br>
    Feel free to add new proposals<br>
    <br>
    Best Regards<br>
    Lars<br>
  </body>
</html>

--------------010702070000020506000500--


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

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

--===============4678443566369879006==--


From xen-devel-bounces@lists.xen.org Fri Jun 01 10:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaOxA-0000TS-HA; Fri, 01 Jun 2012 10:19:32 +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 1SaOx8-0000T7-Jp
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:19:30 +0000
Received: from [193.109.254.147:15104] by server-4.bemta-14.messagelabs.com id
	ED/E7-03148-13798CF4; Fri, 01 Jun 2012 10:19:29 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338545967!12144200!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10696 invoked from network); 1 Jun 2012 10:19:28 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:19:28 -0000
Received: by eekd41 with SMTP id d41so906638eek.32
	for <multiple recipients>; Fri, 01 Jun 2012 03:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=8uOP5xsUONlrGN/vzHDkvmqAGPNy/l+BTPiVktyxf8w=;
	b=XdglF9Aq3Synog8YsAu65g47kxgRsmf+PtVj5ESLVHDrYMN94b9xV1ONW84ghxLJWx
	tGvrFxY3MxvRhZolWuOI3N9lqKC5FXtxi1hogmvlbLCrU7qFUouRWXGJjC79tG8xe+oZ
	MG9RrwzqsG7g/phsPym0sSYk0qaEvoGKUKwO4UNZ2QaQc4hFKtIOVCKgqmIpSAoeC/nD
	yUkn5TJAwzL10Hf165imkLvUWaz5RU6Ws3Lf/nPJimYpx3m8ivJEk1YdlyjGFDZXskcZ
	sZXj6S4oKG5kKG68olmX9m3cvOlH853IKSy2GVMcsxCw8DK2X/SyGjVRioRJX+OZdoLn
	TUEA==
Received: by 10.14.97.77 with SMTP id s53mr1032470eef.104.1338545967713;
	Fri, 01 Jun 2012 03:19:27 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id u7sm5281597eeb.7.2012.06.01.03.19.25
	(version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 03:19:26 -0700 (PDT)
Message-ID: <4FC8972B.6060202@xen.org>
Date: Fri, 01 Jun 2012 11:19:23 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
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="===============4678443566369879006=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4678443566369879006==
Content-Type: multipart/alternative;
 boundary="------------010702070000020506000500"

This is a multi-part message in MIME format.
--------------010702070000020506000500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

at the last Xen Docs Day I got feedback that it is too hard to find 
useful information from the wiki front page. Also, much of the 
information on the front page (the list of categories) is actually 
duplicated on the wiki navigation bar.

There were a few items of feedback I received:
1) The front page should be more use-case driven and be aimed at 
beginners and users
2) Wiki Search is broken.
- Actually it is not, the UI design of search in MediaWiki is bad.
- Typing "Foo"+return into the search box will actually perform Go(Foo) 
which searches for "Foo" in titles only
- To search you need to type "Foo" and press search
3) Google search is broken.
- Some redirects are still needed but mostly we have fixed this now.
- The ones we know of are: (e.g. wiki.*xen*source.com is still hanging 
around)
- If you find SEO issues: let us know at http://wiki.xen.org/wiki/SEO_Issues

To facilitate the discussion on the new front-page, I created a proposal 
space for everybody to play with and make proposals
- http://wiki.xen.org/wiki/Proposals/ : list of proposals
- http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case 
focussed front-page
- http://wiki.xen.org/wiki/Talk:Proposals/Main_Page1 : discussion page, 
feel free to add
- http://wiki.xen.org/wiki/Proposals/Main_Page2 : a copy of the previous 
page, feel free to change
- http://wiki.xen.org/wiki/Talk:Proposals/Main_Page2 : discussion page, 
feel free to add

Feel free to add new proposals

Best Regards
Lars

--------------010702070000020506000500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    at the last Xen Docs Day I got feedback that it is too hard to find
    useful information from the wiki front page. Also, much of the
    information on the front page (the list of categories) is actually
    duplicated on the wiki navigation bar.<br>
    <br>
    There were a few items of feedback I received:<br>
    1) The front page should be more use-case driven and be aimed at
    beginners and users<br>
    2) Wiki Search is broken. <br>
    - Actually it is not, the UI design of search in MediaWiki is bad.&nbsp;
    <br>
    - Typing "Foo"+return into the search box will actually perform
    Go(Foo) which searches for "Foo" in titles only<br>
    - To search you need to type "Foo" and press search<br>
    3) Google search is broken. <br>
    - Some redirects are still needed but mostly&nbsp;<cite></cite>we have
    fixed this now.<br>
    - The ones we know of are: (e.g. <cite>wiki.<b>xen</b>source.com is
      still hanging around) </cite><br>
    - If you find SEO issues: let us know at
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/SEO_Issues">http://wiki.xen.org/wiki/SEO_Issues</a><br>
    <br>
    To facilitate the discussion on the new front-page, I created a
    proposal space for everybody to play with and make proposals<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Proposals/">http://wiki.xen.org/wiki/Proposals/</a> : list of proposals<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Proposals/Main_Page1">http://wiki.xen.org/wiki/Proposals/Main_Page1</a> : a more use-case
    focussed front-page<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Talk:Proposals/Main_Page1">http://wiki.xen.org/wiki/Talk:Proposals/Main_Page1</a> : discussion
    page, feel free to add<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Proposals/Main_Page2">http://wiki.xen.org/wiki/Proposals/Main_Page2</a> : a copy of the
    previous page, feel free to change<br>
    - <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Talk:Proposals/Main_Page2">http://wiki.xen.org/wiki/Talk:Proposals/Main_Page2</a> : discussion
    page, feel free to add<br>
    <br>
    Feel free to add new proposals<br>
    <br>
    Best Regards<br>
    Lars<br>
  </body>
</html>

--------------010702070000020506000500--


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

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

--===============4678443566369879006==--


From xen-devel-bounces@lists.xen.org Fri Jun 01 10:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:19: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 1SaOxK-0000V4-KL; Fri, 01 Jun 2012 10:19:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaOxI-0000Ue-Cw
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:19:40 +0000
Received: from [85.158.143.99:25596] by server-1.bemta-4.messagelabs.com id
	C8/7F-27869-B3798CF4; Fri, 01 Jun 2012 10:19:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338545977!30329241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20406 invoked from network); 1 Jun 2012 10:19:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:19:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:19:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:19:36 +0100
Message-ID: <1338545975.17466.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:19:35 +0100
In-Reply-To: <4FC89556.7090502@eu.citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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 Fri, 2012-06-01 at 11:11 +0100, George Dunlap wrote:
> On 01/06/12 09:29, Ian Campbell wrote:
> > On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
> >> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
> >> <George.Dunlap@eu.citrix.com>  wrote:
> >>> The strange thing is that there *is* a pygrub in the right place, so
> >>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
> >> It's seems that the right on the script are already set to 755 by the
> >> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
> > What is the conclusion here? Is the original patch correct and/or is
> > there a subsequent additional fix?
> There is a bug (pygrub is installed both in $(DESTDIR)/foo and 
> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly 
> fixes the bug (only installed in $(DESTDIR).
> 
> I think there is a redundant command in the Makefile as well, where 
> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause 
> incorrect behavior, but I would probably still consider it a bug.
> 
> So the original patch is correct, but there is a subsequent fix.
> > My scripts does things like:
> >          make -C tools XEN_TARGET_ARCH=x86_32 DESTDIR=/tmp/tmp0_hnbt LIBXL_TESTIDL_SEED=42 debug=y -j12 install
> > then tars up /tmp/tmp0_hnbt, copies it to my test box and untars. I've
> > just noticed on my test box:
> >          # ls -dl /tmp/tmp*
> >          drwxr-xr-x 3 root root 4096 Jun  1 09:26 /tmp/tmp0_hnbt
> >          drwxr-xr-x 3 root root 4096 May 18 11:11 /tmp/tmp8D2Mvc
> >          drwxr-xr-x 3 root root 4096 May 25 10:21 /tmp/tmpAd2OFq
> >          drwxr-xr-x 3 root root 4096 May 18 15:05 /tmp/tmpEqYZpf
> >          [...]
> >          # find /tmp/tmp* -name pygrub | wc -l
> >          19
> The "right thing" is to find find 2 files named "pygrub" per directory 
> (a binary at /usr/lib/xen/bin/pygrub and a link to that binary at 
> /usr/bin/pygrub, for compatibility).  Without Anthony's patch you would 
> get 3.  Not sure how that corresponds to the directories you have there...

This is the actual installed files on my test machine, not my build
machine. 

On my build system I would have had:
 /tmp/tmpEqYZpf/usr/lib/xen/bin/pygrub
 /tmp/tmpEqYZpf/usr/bin/pygrub -> /usr/lib/xen/bin/pygrub
 /tmp/tmpEqYZpf/tmp/tmpEqYZpf/usr/lib/xen/bin/pygrub

I then "tar -C /tmp/tmpEqYZpf  cf blah.tar ." and copy+untar blah.tar on
the so that on the target I get:
 /usr/lib/xen/bin/pygrub
 /usr/bin/pygrub -> /usr/lib/xen/bin/pygrub
 /tmp/tmpEqYZpf/usr/lib/xen/bin/pygrub

Where the last is what I find above via find etc.

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:19: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 1SaOxK-0000V4-KL; Fri, 01 Jun 2012 10:19:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaOxI-0000Ue-Cw
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:19:40 +0000
Received: from [85.158.143.99:25596] by server-1.bemta-4.messagelabs.com id
	C8/7F-27869-B3798CF4; Fri, 01 Jun 2012 10:19:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338545977!30329241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20406 invoked from network); 1 Jun 2012 10:19:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:19:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:19:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:19:36 +0100
Message-ID: <1338545975.17466.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:19:35 +0100
In-Reply-To: <4FC89556.7090502@eu.citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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 Fri, 2012-06-01 at 11:11 +0100, George Dunlap wrote:
> On 01/06/12 09:29, Ian Campbell wrote:
> > On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
> >> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
> >> <George.Dunlap@eu.citrix.com>  wrote:
> >>> The strange thing is that there *is* a pygrub in the right place, so
> >>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
> >> It's seems that the right on the script are already set to 755 by the
> >> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
> > What is the conclusion here? Is the original patch correct and/or is
> > there a subsequent additional fix?
> There is a bug (pygrub is installed both in $(DESTDIR)/foo and 
> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly 
> fixes the bug (only installed in $(DESTDIR).
> 
> I think there is a redundant command in the Makefile as well, where 
> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause 
> incorrect behavior, but I would probably still consider it a bug.
> 
> So the original patch is correct, but there is a subsequent fix.
> > My scripts does things like:
> >          make -C tools XEN_TARGET_ARCH=x86_32 DESTDIR=/tmp/tmp0_hnbt LIBXL_TESTIDL_SEED=42 debug=y -j12 install
> > then tars up /tmp/tmp0_hnbt, copies it to my test box and untars. I've
> > just noticed on my test box:
> >          # ls -dl /tmp/tmp*
> >          drwxr-xr-x 3 root root 4096 Jun  1 09:26 /tmp/tmp0_hnbt
> >          drwxr-xr-x 3 root root 4096 May 18 11:11 /tmp/tmp8D2Mvc
> >          drwxr-xr-x 3 root root 4096 May 25 10:21 /tmp/tmpAd2OFq
> >          drwxr-xr-x 3 root root 4096 May 18 15:05 /tmp/tmpEqYZpf
> >          [...]
> >          # find /tmp/tmp* -name pygrub | wc -l
> >          19
> The "right thing" is to find find 2 files named "pygrub" per directory 
> (a binary at /usr/lib/xen/bin/pygrub and a link to that binary at 
> /usr/bin/pygrub, for compatibility).  Without Anthony's patch you would 
> get 3.  Not sure how that corresponds to the directories you have there...

This is the actual installed files on my test machine, not my build
machine. 

On my build system I would have had:
 /tmp/tmpEqYZpf/usr/lib/xen/bin/pygrub
 /tmp/tmpEqYZpf/usr/bin/pygrub -> /usr/lib/xen/bin/pygrub
 /tmp/tmpEqYZpf/tmp/tmpEqYZpf/usr/lib/xen/bin/pygrub

I then "tar -C /tmp/tmpEqYZpf  cf blah.tar ." and copy+untar blah.tar on
the so that on the target I get:
 /usr/lib/xen/bin/pygrub
 /usr/bin/pygrub -> /usr/lib/xen/bin/pygrub
 /tmp/tmpEqYZpf/usr/lib/xen/bin/pygrub

Where the last is what I find above via find etc.

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:21:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:21: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 1SaOyu-0000nO-9V; Fri, 01 Jun 2012 10:21:20 +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 1SaOyt-0000n7-7A
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:21:19 +0000
Received: from [193.109.254.147:36056] by server-5.bemta-14.messagelabs.com id
	A3/A7-06171-E9798CF4; Fri, 01 Jun 2012 10:21:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1338546076!12318455!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27782 invoked from network); 1 Jun 2012 10:21:17 -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;
	1 Jun 2012 10:21:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26510994"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:21:15 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:21:15 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaOyp-0005Tj-5N;
	Fri, 01 Jun 2012 11:21:15 +0100
Message-ID: <4FC8979A.6000700@citrix.com>
Date: Fri, 1 Jun 2012 11:21:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com>
In-Reply-To: <4FC89556.7090502@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> On 01/06/12 09:29, Ian Campbell wrote:
>> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>> <George.Dunlap@eu.citrix.com>   wrote:
>>>> The strange thing is that there *is* a pygrub in the right place, so
>>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>> It's seems that the right on the script are already set to 755 by the
>>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>> What is the conclusion here? Is the original patch correct and/or is
>> there a subsequent additional fix?
> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
> fixes the bug (only installed in $(DESTDIR).
>
> I think there is a redundant command in the Makefile as well, where
> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
> incorrect behavior, but I would probably still consider it a bug.

I get an error when performing an install-tools on NetBSD:

byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py 
to LiloConf.pyc
running install_scripts
copying build/scripts-2.7/pygrub -> //usr/xen42/bin
error: //usr/xen42/bin/pygrub: Too many levels of symbolic links
gmake[3]: *** [install] Error 1
gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
gmake[2]: *** [subdir-install-pygrub] Error 2
gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
gmake[1]: *** [subdirs-install] Error 2
gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
gmake: *** [install-tools] Error 2

Which I'm quite sure is caused by this.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:21:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:21: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 1SaOyu-0000nO-9V; Fri, 01 Jun 2012 10:21:20 +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 1SaOyt-0000n7-7A
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:21:19 +0000
Received: from [193.109.254.147:36056] by server-5.bemta-14.messagelabs.com id
	A3/A7-06171-E9798CF4; Fri, 01 Jun 2012 10:21:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1338546076!12318455!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27782 invoked from network); 1 Jun 2012 10:21:17 -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;
	1 Jun 2012 10:21:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26510994"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:21:15 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:21:15 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaOyp-0005Tj-5N;
	Fri, 01 Jun 2012 11:21:15 +0100
Message-ID: <4FC8979A.6000700@citrix.com>
Date: Fri, 1 Jun 2012 11:21:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com>
In-Reply-To: <4FC89556.7090502@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> On 01/06/12 09:29, Ian Campbell wrote:
>> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>> <George.Dunlap@eu.citrix.com>   wrote:
>>>> The strange thing is that there *is* a pygrub in the right place, so
>>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>> It's seems that the right on the script are already set to 755 by the
>>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>> What is the conclusion here? Is the original patch correct and/or is
>> there a subsequent additional fix?
> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
> fixes the bug (only installed in $(DESTDIR).
>
> I think there is a redundant command in the Makefile as well, where
> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
> incorrect behavior, but I would probably still consider it a bug.

I get an error when performing an install-tools on NetBSD:

byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py 
to LiloConf.pyc
running install_scripts
copying build/scripts-2.7/pygrub -> //usr/xen42/bin
error: //usr/xen42/bin/pygrub: Too many levels of symbolic links
gmake[3]: *** [install] Error 1
gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
gmake[2]: *** [subdir-install-pygrub] Error 2
gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
gmake[1]: *** [subdirs-install] Error 2
gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
gmake: *** [install-tools] Error 2

Which I'm quite sure is caused by this.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaP0i-00015M-QX; Fri, 01 Jun 2012 10:23:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaP0h-000155-DR
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:23:11 +0000
Received: from [85.158.143.35:23995] by server-1.bemta-4.messagelabs.com id
	F5/96-27869-E0898CF4; Fri, 01 Jun 2012 10:23:10 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338546189!18415154!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22663 invoked from network); 1 Jun 2012 10:23:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 10:23:09 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78339326; Fri, 01 Jun 2012 12:23:08 +0200
Message-ID: <1338546187.31901.45.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 12:23:07 +0200
In-Reply-To: <1338543666.17466.55.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7029981955978653636=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7029981955978653636==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-AnoDFo7Xx6KxrDr+gDg/"


--=-AnoDFo7Xx6KxrDr+gDg/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 10:41 +0100, Ian Campbell wrote:=20
> > Mmm... Maybe this is still related to the fact that on all the test
> > boxes I've used, libxl_get_max_cpus() returns something higher than the
> > actual physical CPU count of those boxes themselves, but I just created
> > an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
> > can't, can you?
>=20
> I think libxl_get_max_cpus and/or libxl_cpumap_alloc involved some
> amount of rounding up, if you tried to create a 33 vcpu guest on that
> machine (or a machine with <=3D 32 cpus) it may not work...
>=20
It does:

    max_cpus =3D libxl_get_max_cpus(ctx);
    if (max_cpus =3D=3D 0)
        return ERROR_FAIL;

    sz =3D (max_cpus + 7) / 8;

So in my case it should be 16 + 7 =3D 23 / 8 =3D 2 ... Right? Then we have:

    cpumap->map =3D calloc(sz, sizeof(*cpumap->map));

Which make me thinking I'm getting a 2 elements uint8_t array for
storing the cpumap (please correct me if I'm wrong, I frequently am when
it comes to math! :-P). That's way I wasn't expecting to be able to
exceed 16 VCPUs.

Anyway, I just tried 25 and 33 and 65, and creation of the domain worked
without raising any errors! Then I double-checked, and saw that, in the
'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I log
into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
65 VCPUs case).

To conclude, I'm not sure what's going on, but I don't think is
something we would want... :-/=20

> > Maybe it is that *_max_cpus() logic that needs some attention? :-O
>=20
> max_cpus returns the max number of physical cpus, and I think it does so
> correctly (perhaps with some slop at the top end).=20
>
As we also saw in another thread, it seems to return the max_cpu_id+1,
which is different from the number of physical CPUs (at least in my
case). And in fact, I'm sure it returns 64 on my box. However, that does
not appear to be the main issue here, as creation seem to succeed no
matter how much VCPUs I ask for, but then a number of them are off. :-O

If that is a known/documented behaviour, fine, I just haven't found it.
Otherwise, perhaps I can investigate a bit what's going on, if that is
considered interesting...

> In some cases we want
> to talk about virtual cpus and this change lets us size cpumap's of
> virtual cpus more appropriately (be that larger or smaller than the
> number of physical cpus).
>=20
I have no argument against this. As I tried to explain, I thought

/* get max. number of cpus supported by hypervisor */
int libxl_get_max_cpus(libxl_ctx *ctx);

"max. number of cpus supported by hypervisor" to be different from the
actual number of physical processors, and I was sort-of mislead by the
machine I use to test Xen every day (where that is actually happening!).
If it is not like that, I guess I can agree with you on this change.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-AnoDFo7Xx6KxrDr+gDg/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/ImAsACgkQk4XaBE3IOsSbLACgobSeOi+6tIWSVs5bJdrqBe5U
VQMAoI3JJw+Z6OSEyYAJylPoC4Aa0wJ4
=8DSr
-----END PGP SIGNATURE-----

--=-AnoDFo7Xx6KxrDr+gDg/--



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

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

--===============7029981955978653636==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 10:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaP0i-00015M-QX; Fri, 01 Jun 2012 10:23:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaP0h-000155-DR
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:23:11 +0000
Received: from [85.158.143.35:23995] by server-1.bemta-4.messagelabs.com id
	F5/96-27869-E0898CF4; Fri, 01 Jun 2012 10:23:10 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338546189!18415154!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22663 invoked from network); 1 Jun 2012 10:23:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 10:23:09 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78339326; Fri, 01 Jun 2012 12:23:08 +0200
Message-ID: <1338546187.31901.45.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 12:23:07 +0200
In-Reply-To: <1338543666.17466.55.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7029981955978653636=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7029981955978653636==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-AnoDFo7Xx6KxrDr+gDg/"


--=-AnoDFo7Xx6KxrDr+gDg/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 10:41 +0100, Ian Campbell wrote:=20
> > Mmm... Maybe this is still related to the fact that on all the test
> > boxes I've used, libxl_get_max_cpus() returns something higher than the
> > actual physical CPU count of those boxes themselves, but I just created
> > an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
> > can't, can you?
>=20
> I think libxl_get_max_cpus and/or libxl_cpumap_alloc involved some
> amount of rounding up, if you tried to create a 33 vcpu guest on that
> machine (or a machine with <=3D 32 cpus) it may not work...
>=20
It does:

    max_cpus =3D libxl_get_max_cpus(ctx);
    if (max_cpus =3D=3D 0)
        return ERROR_FAIL;

    sz =3D (max_cpus + 7) / 8;

So in my case it should be 16 + 7 =3D 23 / 8 =3D 2 ... Right? Then we have:

    cpumap->map =3D calloc(sz, sizeof(*cpumap->map));

Which make me thinking I'm getting a 2 elements uint8_t array for
storing the cpumap (please correct me if I'm wrong, I frequently am when
it comes to math! :-P). That's way I wasn't expecting to be able to
exceed 16 VCPUs.

Anyway, I just tried 25 and 33 and 65, and creation of the domain worked
without raising any errors! Then I double-checked, and saw that, in the
'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I log
into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
65 VCPUs case).

To conclude, I'm not sure what's going on, but I don't think is
something we would want... :-/=20

> > Maybe it is that *_max_cpus() logic that needs some attention? :-O
>=20
> max_cpus returns the max number of physical cpus, and I think it does so
> correctly (perhaps with some slop at the top end).=20
>
As we also saw in another thread, it seems to return the max_cpu_id+1,
which is different from the number of physical CPUs (at least in my
case). And in fact, I'm sure it returns 64 on my box. However, that does
not appear to be the main issue here, as creation seem to succeed no
matter how much VCPUs I ask for, but then a number of them are off. :-O

If that is a known/documented behaviour, fine, I just haven't found it.
Otherwise, perhaps I can investigate a bit what's going on, if that is
considered interesting...

> In some cases we want
> to talk about virtual cpus and this change lets us size cpumap's of
> virtual cpus more appropriately (be that larger or smaller than the
> number of physical cpus).
>=20
I have no argument against this. As I tried to explain, I thought

/* get max. number of cpus supported by hypervisor */
int libxl_get_max_cpus(libxl_ctx *ctx);

"max. number of cpus supported by hypervisor" to be different from the
actual number of physical processors, and I was sort-of mislead by the
machine I use to test Xen every day (where that is actually happening!).
If it is not like that, I guess I can agree with you on this change.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-AnoDFo7Xx6KxrDr+gDg/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/ImAsACgkQk4XaBE3IOsSbLACgobSeOi+6tIWSVs5bJdrqBe5U
VQMAoI3JJw+Z6OSEyYAJylPoC4Aa0wJ4
=8DSr
-----END PGP SIGNATURE-----

--=-AnoDFo7Xx6KxrDr+gDg/--



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

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

--===============7029981955978653636==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 10:26:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:26: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 1SaP42-0001Mg-Ew; Fri, 01 Jun 2012 10:26:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaP40-0001MO-SP
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:26:37 +0000
Received: from [85.158.139.83:9025] by server-8.bemta-5.messagelabs.com id
	DE/4E-25689-BD898CF4; Fri, 01 Jun 2012 10:26:35 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338546394!27589926!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11631 invoked from network); 1 Jun 2012 10:26:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	1 Jun 2012 10:26:35 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78339443; Fri, 01 Jun 2012 12:26:33 +0200
Message-ID: <1338546392.31901.47.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 12:26:32 +0200
In-Reply-To: <1338545650.17466.68.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<274de8e1e0d116070d34.1338299821@cosworth.uk.xensource.com>
	<1338362793.2609.20.camel@Abyss>
	<1338363341.31698.17.camel@zakaz.uk.xensource.com>
	<1338364837.2609.24.camel@Abyss>
	<1338545650.17466.68.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6249729318167785494=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6249729318167785494==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8cK5sPtGfy6/La+Jm/gf"


--=-8cK5sPtGfy6/La+Jm/gf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 11:14 +0100, Ian Campbell wrote:=20
> Thanks. I'm going to commit this as is and await the fixup, if that's
> ok.=20
>
That's fine, I'm working on it today, as I have been busier that
expected with other things. I'll submit it separately on top of your
commits.

> I think this isn't a regression from the PoV of the configuration
> file since this would also have happened before.
>=20
It is, indeed.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-8cK5sPtGfy6/La+Jm/gf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/ImNkACgkQk4XaBE3IOsRfqACfYB9Qh5pEUm0KJkcX91frW9Fl
0n0AmwZeObYmOt7zAMSWpxY8cNowmuaT
=6QIY
-----END PGP SIGNATURE-----

--=-8cK5sPtGfy6/La+Jm/gf--



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

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

--===============6249729318167785494==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 10:26:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:26: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 1SaP42-0001Mg-Ew; Fri, 01 Jun 2012 10:26:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaP40-0001MO-SP
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:26:37 +0000
Received: from [85.158.139.83:9025] by server-8.bemta-5.messagelabs.com id
	DE/4E-25689-BD898CF4; Fri, 01 Jun 2012 10:26:35 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338546394!27589926!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11631 invoked from network); 1 Jun 2012 10:26:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	1 Jun 2012 10:26:35 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78339443; Fri, 01 Jun 2012 12:26:33 +0200
Message-ID: <1338546392.31901.47.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 12:26:32 +0200
In-Reply-To: <1338545650.17466.68.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<274de8e1e0d116070d34.1338299821@cosworth.uk.xensource.com>
	<1338362793.2609.20.camel@Abyss>
	<1338363341.31698.17.camel@zakaz.uk.xensource.com>
	<1338364837.2609.24.camel@Abyss>
	<1338545650.17466.68.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6249729318167785494=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6249729318167785494==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8cK5sPtGfy6/La+Jm/gf"


--=-8cK5sPtGfy6/La+Jm/gf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 11:14 +0100, Ian Campbell wrote:=20
> Thanks. I'm going to commit this as is and await the fixup, if that's
> ok.=20
>
That's fine, I'm working on it today, as I have been busier that
expected with other things. I'll submit it separately on top of your
commits.

> I think this isn't a regression from the PoV of the configuration
> file since this would also have happened before.
>=20
It is, indeed.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-8cK5sPtGfy6/La+Jm/gf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/ImNkACgkQk4XaBE3IOsRfqACfYB9Qh5pEUm0KJkcX91frW9Fl
0n0AmwZeObYmOt7zAMSWpxY8cNowmuaT
=6QIY
-----END PGP SIGNATURE-----

--=-8cK5sPtGfy6/La+Jm/gf--



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

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

--===============6249729318167785494==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 10:31:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:31: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 1SaP8A-0001Zs-55; Fri, 01 Jun 2012 10:30:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaP89-0001Zn-2y
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:30:53 +0000
Received: from [193.109.254.147:39766] by server-9.bemta-14.messagelabs.com id
	10/E9-28098-CD998CF4; Fri, 01 Jun 2012 10:30:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338546650!12282089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27331 invoked from network); 1 Jun 2012 10:30:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:30:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:30:50 +0100
Message-ID: <1338546648.17466.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 1 Jun 2012 11:30:48 +0100
In-Reply-To: <4FC8979A.6000700@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8979A.6000700@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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 Fri, 2012-06-01 at 11:21 +0100, Roger Pau Monne wrote:
> George Dunlap wrote:
> > On 01/06/12 09:29, Ian Campbell wrote:
> >> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
> >>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
> >>> <George.Dunlap@eu.citrix.com>   wrote:
> >>>> The strange thing is that there *is* a pygrub in the right place, so
> >>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
> >>> It's seems that the right on the script are already set to 755 by the
> >>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
> >> What is the conclusion here? Is the original patch correct and/or is
> >> there a subsequent additional fix?
> > There is a bug (pygrub is installed both in $(DESTDIR)/foo and
> > $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
> > fixes the bug (only installed in $(DESTDIR).
> >
> > I think there is a redundant command in the Makefile as well, where
> > pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
> > incorrect behavior, but I would probably still consider it a bug.
> 
> I get an error when performing an install-tools on NetBSD:
> 
> byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py 
> to LiloConf.pyc
> running install_scripts
> copying build/scripts-2.7/pygrub -> //usr/xen42/bin
> error: //usr/xen42/bin/pygrub: Too many levels of symbolic links

OOI what does //usr/xen42/bin/pygrub point to?

> gmake[3]: *** [install] Error 1
> gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
> gmake[2]: *** [subdir-install-pygrub] Error 2
> gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
> gmake[1]: *** [subdirs-install] Error 2
> gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
> gmake: *** [install-tools] Error 2
> 
> Which I'm quite sure is caused by this.

"this" == this problem or "this" == this patch?



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:31:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:31: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 1SaP8A-0001Zs-55; Fri, 01 Jun 2012 10:30:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaP89-0001Zn-2y
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:30:53 +0000
Received: from [193.109.254.147:39766] by server-9.bemta-14.messagelabs.com id
	10/E9-28098-CD998CF4; Fri, 01 Jun 2012 10:30:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338546650!12282089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27331 invoked from network); 1 Jun 2012 10:30:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:30:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:30:50 +0100
Message-ID: <1338546648.17466.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 1 Jun 2012 11:30:48 +0100
In-Reply-To: <4FC8979A.6000700@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8979A.6000700@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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 Fri, 2012-06-01 at 11:21 +0100, Roger Pau Monne wrote:
> George Dunlap wrote:
> > On 01/06/12 09:29, Ian Campbell wrote:
> >> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
> >>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
> >>> <George.Dunlap@eu.citrix.com>   wrote:
> >>>> The strange thing is that there *is* a pygrub in the right place, so
> >>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
> >>> It's seems that the right on the script are already set to 755 by the
> >>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
> >> What is the conclusion here? Is the original patch correct and/or is
> >> there a subsequent additional fix?
> > There is a bug (pygrub is installed both in $(DESTDIR)/foo and
> > $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
> > fixes the bug (only installed in $(DESTDIR).
> >
> > I think there is a redundant command in the Makefile as well, where
> > pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
> > incorrect behavior, but I would probably still consider it a bug.
> 
> I get an error when performing an install-tools on NetBSD:
> 
> byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py 
> to LiloConf.pyc
> running install_scripts
> copying build/scripts-2.7/pygrub -> //usr/xen42/bin
> error: //usr/xen42/bin/pygrub: Too many levels of symbolic links

OOI what does //usr/xen42/bin/pygrub point to?

> gmake[3]: *** [install] Error 1
> gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
> gmake[2]: *** [subdir-install-pygrub] Error 2
> gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
> gmake[1]: *** [subdirs-install] Error 2
> gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
> gmake: *** [install-tools] Error 2
> 
> Which I'm quite sure is caused by this.

"this" == this problem or "this" == this patch?



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPCa-0001vG-Ra; Fri, 01 Jun 2012 10:35:28 +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 1SaPCZ-0001vB-PG
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:35:27 +0000
Received: from [193.109.254.147:49793] by server-3.bemta-14.messagelabs.com id
	D8/2D-15022-FEA98CF4; Fri, 01 Jun 2012 10:35:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1338546912!11991567!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4987 invoked from network); 1 Jun 2012 10:35:14 -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 Jun 2012 10:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197170956"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:35:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:35:11 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaPCJ-0005qA-LX;
	Fri, 01 Jun 2012 11:35:11 +0100
Message-ID: <4FC89ADF.6080503@citrix.com>
Date: Fri, 1 Jun 2012 11:35:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8979A.6000700@citrix.com>
	<1338546648.17466.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338546648.17466.72.camel@zakaz.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Fri, 2012-06-01 at 11:21 +0100, Roger Pau Monne wrote:
>> George Dunlap wrote:
>>> On 01/06/12 09:29, Ian Campbell wrote:
>>>> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>>>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>>>> <George.Dunlap@eu.citrix.com>    wrote:
>>>>>> The strange thing is that there *is* a pygrub in the right place, so
>>>>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>>>> It's seems that the right on the script are already set to 755 by the
>>>>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>>>> What is the conclusion here? Is the original patch correct and/or is
>>>> there a subsequent additional fix?
>>> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
>>> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
>>> fixes the bug (only installed in $(DESTDIR).
>>>
>>> I think there is a redundant command in the Makefile as well, where
>>> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
>>> incorrect behavior, but I would probably still consider it a bug.
>> I get an error when performing an install-tools on NetBSD:
>>
>> byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py
>> to LiloConf.pyc
>> running install_scripts
>> copying build/scripts-2.7/pygrub ->  //usr/xen42/bin
>> error: //usr/xen42/bin/pygrub: Too many levels of symbolic links
>
> OOI what does //usr/xen42/bin/pygrub point to?

lrwxr-xr-x  1 root  wheel  21 May 25 14:32 //usr/xen42/bin/pygrub -> 
/usr/xen42/bin/pygrub

>> gmake[3]: *** [install] Error 1
>> gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
>> gmake[2]: *** [subdir-install-pygrub] Error 2
>> gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
>> gmake[1]: *** [subdirs-install] Error 2
>> gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
>> gmake: *** [install-tools] Error 2
>>
>> Which I'm quite sure is caused by this.
>
> "this" == this problem or "this" == this patch?

I haven't tried the patch, I was referring to the current code in the 
repository, so this == this problem.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPCa-0001vG-Ra; Fri, 01 Jun 2012 10:35:28 +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 1SaPCZ-0001vB-PG
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:35:27 +0000
Received: from [193.109.254.147:49793] by server-3.bemta-14.messagelabs.com id
	D8/2D-15022-FEA98CF4; Fri, 01 Jun 2012 10:35:27 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1338546912!11991567!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4987 invoked from network); 1 Jun 2012 10:35:14 -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 Jun 2012 10:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197170956"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:35:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:35:11 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaPCJ-0005qA-LX;
	Fri, 01 Jun 2012 11:35:11 +0100
Message-ID: <4FC89ADF.6080503@citrix.com>
Date: Fri, 1 Jun 2012 11:35:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8979A.6000700@citrix.com>
	<1338546648.17466.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338546648.17466.72.camel@zakaz.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Fri, 2012-06-01 at 11:21 +0100, Roger Pau Monne wrote:
>> George Dunlap wrote:
>>> On 01/06/12 09:29, Ian Campbell wrote:
>>>> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>>>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>>>> <George.Dunlap@eu.citrix.com>    wrote:
>>>>>> The strange thing is that there *is* a pygrub in the right place, so
>>>>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>>>> It's seems that the right on the script are already set to 755 by the
>>>>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>>>> What is the conclusion here? Is the original patch correct and/or is
>>>> there a subsequent additional fix?
>>> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
>>> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
>>> fixes the bug (only installed in $(DESTDIR).
>>>
>>> I think there is a redundant command in the Makefile as well, where
>>> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
>>> incorrect behavior, but I would probably still consider it a bug.
>> I get an error when performing an install-tools on NetBSD:
>>
>> byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py
>> to LiloConf.pyc
>> running install_scripts
>> copying build/scripts-2.7/pygrub ->  //usr/xen42/bin
>> error: //usr/xen42/bin/pygrub: Too many levels of symbolic links
>
> OOI what does //usr/xen42/bin/pygrub point to?

lrwxr-xr-x  1 root  wheel  21 May 25 14:32 //usr/xen42/bin/pygrub -> 
/usr/xen42/bin/pygrub

>> gmake[3]: *** [install] Error 1
>> gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
>> gmake[2]: *** [subdir-install-pygrub] Error 2
>> gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
>> gmake[1]: *** [subdirs-install] Error 2
>> gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
>> gmake: *** [install-tools] Error 2
>>
>> Which I'm quite sure is caused by this.
>
> "this" == this problem or "this" == this patch?

I haven't tried the patch, I was referring to the current code in the 
repository, so this == this problem.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:38:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPEp-000276-D6; Fri, 01 Jun 2012 10:37:47 +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 1SaPEn-00026r-Qf
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:37:46 +0000
Received: from [85.158.143.99:42413] by server-3.bemta-4.messagelabs.com id
	4D/A4-04252-97B98CF4; Fri, 01 Jun 2012 10:37:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338547062!24338422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9187 invoked from network); 1 Jun 2012 10:37:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:37:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26512101"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:37:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:37:41 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaPEi-0005u5-Vx;
	Fri, 01 Jun 2012 11:37:40 +0100
Message-ID: <4FC89B0F.5090407@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:35:59 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8979A.6000700@citrix.com>
	<1338546648.17466.72.camel@zakaz.uk.xensource.com>
	<4FC89ADF.6080503@citrix.com>
In-Reply-To: <4FC89ADF.6080503@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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/06/12 11:35, Roger Pau Monne wrote:
> Ian Campbell wrote:
>> On Fri, 2012-06-01 at 11:21 +0100, Roger Pau Monne wrote:
>>> George Dunlap wrote:
>>>> On 01/06/12 09:29, Ian Campbell wrote:
>>>>> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>>>>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>>>>> <George.Dunlap@eu.citrix.com>     wrote:
>>>>>>> The strange thing is that there *is* a pygrub in the right place, so
>>>>>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>>>>> It's seems that the right on the script are already set to 755 by the
>>>>>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>>>>> What is the conclusion here? Is the original patch correct and/or is
>>>>> there a subsequent additional fix?
>>>> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
>>>> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
>>>> fixes the bug (only installed in $(DESTDIR).
>>>>
>>>> I think there is a redundant command in the Makefile as well, where
>>>> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
>>>> incorrect behavior, but I would probably still consider it a bug.
>>> I get an error when performing an install-tools on NetBSD:
>>>
>>> byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py
>>> to LiloConf.pyc
>>> running install_scripts
>>> copying build/scripts-2.7/pygrub ->   //usr/xen42/bin
>>> error: //usr/xen42/bin/pygrub: Too many levels of symbolic links
>> OOI what does //usr/xen42/bin/pygrub point to?
> lrwxr-xr-x  1 root  wheel  21 May 25 14:32 //usr/xen42/bin/pygrub ->
> /usr/xen42/bin/pygrub
>
>>> gmake[3]: *** [install] Error 1
>>> gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
>>> gmake[2]: *** [subdir-install-pygrub] Error 2
>>> gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
>>> gmake[1]: *** [subdirs-install] Error 2
>>> gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
>>> gmake: *** [install-tools] Error 2
>>>
>>> Which I'm quite sure is caused by this.
>> "this" == this problem or "this" == this patch?
> I haven't tried the patch, I was referring to the current code in the
> repository, so this == this problem.
Ah, but that must be a different problem -- is it perhaps the case that 
in NetBSD $(PRIVATE_BINDIR) and $(BINDIR) are the same?

  -George


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:38:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPEp-000276-D6; Fri, 01 Jun 2012 10:37:47 +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 1SaPEn-00026r-Qf
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:37:46 +0000
Received: from [85.158.143.99:42413] by server-3.bemta-4.messagelabs.com id
	4D/A4-04252-97B98CF4; Fri, 01 Jun 2012 10:37:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338547062!24338422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9187 invoked from network); 1 Jun 2012 10:37:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:37:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26512101"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:37:41 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:37:41 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaPEi-0005u5-Vx;
	Fri, 01 Jun 2012 11:37:40 +0100
Message-ID: <4FC89B0F.5090407@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:35:59 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8979A.6000700@citrix.com>
	<1338546648.17466.72.camel@zakaz.uk.xensource.com>
	<4FC89ADF.6080503@citrix.com>
In-Reply-To: <4FC89ADF.6080503@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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/06/12 11:35, Roger Pau Monne wrote:
> Ian Campbell wrote:
>> On Fri, 2012-06-01 at 11:21 +0100, Roger Pau Monne wrote:
>>> George Dunlap wrote:
>>>> On 01/06/12 09:29, Ian Campbell wrote:
>>>>> On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>>>>> On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>>>>> <George.Dunlap@eu.citrix.com>     wrote:
>>>>>>> The strange thing is that there *is* a pygrub in the right place, so
>>>>>>> it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>>>>> It's seems that the right on the script are already set to 755 by the
>>>>>> setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>>>>> What is the conclusion here? Is the original patch correct and/or is
>>>>> there a subsequent additional fix?
>>>> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
>>>> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
>>>> fixes the bug (only installed in $(DESTDIR).
>>>>
>>>> I think there is a redundant command in the Makefile as well, where
>>>> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
>>>> incorrect behavior, but I would probably still consider it a bug.
>>> I get an error when performing an install-tools on NetBSD:
>>>
>>> byte-compiling /usr/xen42/lib/python2.7/site-packages/grub/LiloConf.py
>>> to LiloConf.pyc
>>> running install_scripts
>>> copying build/scripts-2.7/pygrub ->   //usr/xen42/bin
>>> error: //usr/xen42/bin/pygrub: Too many levels of symbolic links
>> OOI what does //usr/xen42/bin/pygrub point to?
> lrwxr-xr-x  1 root  wheel  21 May 25 14:32 //usr/xen42/bin/pygrub ->
> /usr/xen42/bin/pygrub
>
>>> gmake[3]: *** [install] Error 1
>>> gmake[3]: Leaving directory `/root/xen/xen-clean/tools/pygrub'
>>> gmake[2]: *** [subdir-install-pygrub] Error 2
>>> gmake[2]: Leaving directory `/root/xen/xen-clean/tools'
>>> gmake[1]: *** [subdirs-install] Error 2
>>> gmake[1]: Leaving directory `/root/xen/xen-clean/tools'
>>> gmake: *** [install-tools] Error 2
>>>
>>> Which I'm quite sure is caused by this.
>> "this" == this problem or "this" == this patch?
> I haven't tried the patch, I was referring to the current code in the
> repository, so this == this problem.
Ah, but that must be a different problem -- is it perhaps the case that 
in NetBSD $(PRIVATE_BINDIR) and $(BINDIR) are the same?

  -George


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaPF3-00028A-Pi; Fri, 01 Jun 2012 10:38:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaPF3-000281-4V
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:38:01 +0000
Received: from [85.158.143.35:57503] by server-3.bemta-4.messagelabs.com id
	87/25-04252-88B98CF4; Fri, 01 Jun 2012 10:38:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1338547079!14359714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16200 invoked from network); 1 Jun 2012 10:38:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:37:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 11:37:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaPF1-0001lM-Eq; Fri, 01 Jun 2012 10:37:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaPF1-0001wR-9H;
	Fri, 01 Jun 2012 11:37:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.39815.180423.370810@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 11:37:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338545370.17466.66.camel@zakaz.uk.xensource.com>
References: <3496f86000b80595b34a.1338535311@linux-x12>
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] [v3] libxl: Add API to retrieve domain console tty"):
> On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
> >  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
> > tty) will lead to null pointer access in CTX maco. 
> 
> I haven't looked at the rest of the patch you but thought I'd pick up on
> this now since we have at least one existing libxl__strdup(0, ..) in
>         b_info->blkdev_start = libxl__strdup(0, "xvda");
>         
> so we need to decide what to do in general. libxl__strdup wants the CTX
> so it can complain via the logs on malloc failure.

Damn.  I shouldn't have let you talk me into adding the extra
ctx-based logging, evidently.  I had forgotten the reason for the lack
of that.  (Because it was in the next patch.)

> This looks like a problem even with the functions which take a
> "gc_opt" (i.e. where gc==NULL is explicitly supposed to be allowed).

Yes.

> libxl__alloc_failed() could take a gc_opt instead of a ctx and only log
> if it is non-null. It already also logs via stderr, since this is a
> catastrophic failure from which we won't return.

Yes.

> We could also have a process-global libxl_alloc_failure_hook(const char
> *argh) to allow the calling application to have some chance to log via
> its own routines...

Yes.

> IanJ -- you added all this, what do you think?

I think the above is a good proposal.

Ian.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaPF3-00028A-Pi; Fri, 01 Jun 2012 10:38:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaPF3-000281-4V
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:38:01 +0000
Received: from [85.158.143.35:57503] by server-3.bemta-4.messagelabs.com id
	87/25-04252-88B98CF4; Fri, 01 Jun 2012 10:38:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1338547079!14359714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16200 invoked from network); 1 Jun 2012 10:38:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:37:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 11:37:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaPF1-0001lM-Eq; Fri, 01 Jun 2012 10:37:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaPF1-0001wR-9H;
	Fri, 01 Jun 2012 11:37:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.39815.180423.370810@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 11:37:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338545370.17466.66.camel@zakaz.uk.xensource.com>
References: <3496f86000b80595b34a.1338535311@linux-x12>
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] [v3] libxl: Add API to retrieve domain console tty"):
> On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
> >  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
> > tty) will lead to null pointer access in CTX maco. 
> 
> I haven't looked at the rest of the patch you but thought I'd pick up on
> this now since we have at least one existing libxl__strdup(0, ..) in
>         b_info->blkdev_start = libxl__strdup(0, "xvda");
>         
> so we need to decide what to do in general. libxl__strdup wants the CTX
> so it can complain via the logs on malloc failure.

Damn.  I shouldn't have let you talk me into adding the extra
ctx-based logging, evidently.  I had forgotten the reason for the lack
of that.  (Because it was in the next patch.)

> This looks like a problem even with the functions which take a
> "gc_opt" (i.e. where gc==NULL is explicitly supposed to be allowed).

Yes.

> libxl__alloc_failed() could take a gc_opt instead of a ctx and only log
> if it is non-null. It already also logs via stderr, since this is a
> catastrophic failure from which we won't return.

Yes.

> We could also have a process-global libxl_alloc_failure_hook(const char
> *argh) to allow the calling application to have some chance to log via
> its own routines...

Yes.

> IanJ -- you added all this, what do you think?

I think the above is a good proposal.

Ian.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:39:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:39: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 1SaPG0-0002Gr-ER; Fri, 01 Jun 2012 10:39: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 1SaPFz-0002GU-8n
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:38:59 +0000
Received: from [85.158.138.51:29947] by server-9.bemta-3.messagelabs.com id
	E3/93-21565-2CB98CF4; Fri, 01 Jun 2012 10:38:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338547137!30399839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28697 invoked from network); 1 Jun 2012 10:38:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10: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.213.0; Fri, 1 Jun 2012
	11:38:57 +0100
Message-ID: <1338547136.17466.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 11:38:56 +0100
In-Reply-To: <1338546187.31901.45.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 11:23 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 10:41 +0100, Ian Campbell wrote: 
> > > Mmm... Maybe this is still related to the fact that on all the test
> > > boxes I've used, libxl_get_max_cpus() returns something higher than the
> > > actual physical CPU count of those boxes themselves, but I just created
> > > an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
> > > can't, can you?
> > 
> > I think libxl_get_max_cpus and/or libxl_cpumap_alloc involved some
> > amount of rounding up, if you tried to create a 33 vcpu guest on that
> > machine (or a machine with <= 32 cpus) it may not work...
> > 
> It does:
> 
>     max_cpus = libxl_get_max_cpus(ctx);
>     if (max_cpus == 0)
>         return ERROR_FAIL;
> 
>     sz = (max_cpus + 7) / 8;
> 
> So in my case it should be 16 + 7 = 23 / 8 = 2 ... Right?

Yeah, it seems we do this at byte rather than word granularity like I
first thought.

>  Then we have:
> 
>     cpumap->map = calloc(sz, sizeof(*cpumap->map));
> 
> Which make me thinking I'm getting a 2 elements uint8_t array for
> storing the cpumap (please correct me if I'm wrong, I frequently am when
> it comes to math! :-P). That's way I wasn't expecting to be able to
> exceed 16 VCPUs.
> 
> Anyway, I just tried 25 and 33 and 65, and creation of the domain worked
> without raising any errors! Then I double-checked, and saw that, in the
> 'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I log
> into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
> 65 VCPUs case).

All 64 online?

It might be that the issue being fixed here only manifests on HVM. I'm
not really sure how 64 would work otherwise since cur_vcpus in the IDL
is definitely an int, which is what needs fixing!

libxl__build_post is also probably buggy with max_vcpus >
nr-bits-in(curr_vcpus) and from the looks of it it just overflows off
the end(!), which is also fixed here...

> To conclude, I'm not sure what's going on, but I don't think is
> something we would want... :-/ 
> 
> > > Maybe it is that *_max_cpus() logic that needs some attention? :-O
> > 
> > max_cpus returns the max number of physical cpus, and I think it does so
> > correctly (perhaps with some slop at the top end). 
> >
> As we also saw in another thread, it seems to return the max_cpu_id+1,
> which is different from the number of physical CPUs (at least in my
> case). And in fact, I'm sure it returns 64 on my box. However, that does
> not appear to be the main issue here, as creation seem to succeed no
> matter how much VCPUs I ask for, but then a number of them are off. :-O
> 
> If that is a known/documented behaviour, fine, I just haven't found it.
> Otherwise, perhaps I can investigate a bit what's going on, if that is
> considered interesting...
> 
> > In some cases we want
> > to talk about virtual cpus and this change lets us size cpumap's of
> > virtual cpus more appropriately (be that larger or smaller than the
> > number of physical cpus).
> > 
> I have no argument against this. As I tried to explain, I thought
> 
> /* get max. number of cpus supported by hypervisor */
> int libxl_get_max_cpus(libxl_ctx *ctx);
> 
> "max. number of cpus supported by hypervisor" to be different from the
> actual number of physical processors, and I was sort-of mislead by the
> machine I use to test Xen every day (where that is actually happening!).
> If it is not like that, I guess I can agree with you on this change.

It's certainly supposed to be "get max. number of physical cpus", quite
how that relates to the actual number of physical cpus I'm not sure.

It's definitely not something to do with virtual cpus (for which there
is a limit, but not this 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 Jun 01 10:39:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:39: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 1SaPG0-0002Gr-ER; Fri, 01 Jun 2012 10:39: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 1SaPFz-0002GU-8n
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:38:59 +0000
Received: from [85.158.138.51:29947] by server-9.bemta-3.messagelabs.com id
	E3/93-21565-2CB98CF4; Fri, 01 Jun 2012 10:38:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338547137!30399839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28697 invoked from network); 1 Jun 2012 10:38:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10: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.213.0; Fri, 1 Jun 2012
	11:38:57 +0100
Message-ID: <1338547136.17466.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 11:38:56 +0100
In-Reply-To: <1338546187.31901.45.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 11:23 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 10:41 +0100, Ian Campbell wrote: 
> > > Mmm... Maybe this is still related to the fact that on all the test
> > > boxes I've used, libxl_get_max_cpus() returns something higher than the
> > > actual physical CPU count of those boxes themselves, but I just created
> > > an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
> > > can't, can you?
> > 
> > I think libxl_get_max_cpus and/or libxl_cpumap_alloc involved some
> > amount of rounding up, if you tried to create a 33 vcpu guest on that
> > machine (or a machine with <= 32 cpus) it may not work...
> > 
> It does:
> 
>     max_cpus = libxl_get_max_cpus(ctx);
>     if (max_cpus == 0)
>         return ERROR_FAIL;
> 
>     sz = (max_cpus + 7) / 8;
> 
> So in my case it should be 16 + 7 = 23 / 8 = 2 ... Right?

Yeah, it seems we do this at byte rather than word granularity like I
first thought.

>  Then we have:
> 
>     cpumap->map = calloc(sz, sizeof(*cpumap->map));
> 
> Which make me thinking I'm getting a 2 elements uint8_t array for
> storing the cpumap (please correct me if I'm wrong, I frequently am when
> it comes to math! :-P). That's way I wasn't expecting to be able to
> exceed 16 VCPUs.
> 
> Anyway, I just tried 25 and 33 and 65, and creation of the domain worked
> without raising any errors! Then I double-checked, and saw that, in the
> 'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I log
> into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
> 65 VCPUs case).

All 64 online?

It might be that the issue being fixed here only manifests on HVM. I'm
not really sure how 64 would work otherwise since cur_vcpus in the IDL
is definitely an int, which is what needs fixing!

libxl__build_post is also probably buggy with max_vcpus >
nr-bits-in(curr_vcpus) and from the looks of it it just overflows off
the end(!), which is also fixed here...

> To conclude, I'm not sure what's going on, but I don't think is
> something we would want... :-/ 
> 
> > > Maybe it is that *_max_cpus() logic that needs some attention? :-O
> > 
> > max_cpus returns the max number of physical cpus, and I think it does so
> > correctly (perhaps with some slop at the top end). 
> >
> As we also saw in another thread, it seems to return the max_cpu_id+1,
> which is different from the number of physical CPUs (at least in my
> case). And in fact, I'm sure it returns 64 on my box. However, that does
> not appear to be the main issue here, as creation seem to succeed no
> matter how much VCPUs I ask for, but then a number of them are off. :-O
> 
> If that is a known/documented behaviour, fine, I just haven't found it.
> Otherwise, perhaps I can investigate a bit what's going on, if that is
> considered interesting...
> 
> > In some cases we want
> > to talk about virtual cpus and this change lets us size cpumap's of
> > virtual cpus more appropriately (be that larger or smaller than the
> > number of physical cpus).
> > 
> I have no argument against this. As I tried to explain, I thought
> 
> /* get max. number of cpus supported by hypervisor */
> int libxl_get_max_cpus(libxl_ctx *ctx);
> 
> "max. number of cpus supported by hypervisor" to be different from the
> actual number of physical processors, and I was sort-of mislead by the
> machine I use to test Xen every day (where that is actually happening!).
> If it is not like that, I guess I can agree with you on this change.

It's certainly supposed to be "get max. number of physical cpus", quite
how that relates to the actual number of physical cpus I'm not sure.

It's definitely not something to do with virtual cpus (for which there
is a limit, but not this 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 Jun 01 10:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPHH-0002R0-TG; Fri, 01 Jun 2012 10:40:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaPHG-0002Qj-D7
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:40:18 +0000
Received: from [85.158.143.99:60626] by server-3.bemta-4.messagelabs.com id
	06/3A-04252-11C98CF4; Fri, 01 Jun 2012 10:40:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338547216!30333480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17592 invoked from network); 1 Jun 2012 10:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:40:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:40:16 +0100
Message-ID: <1338547215.17466.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:40:15 +0100
In-Reply-To: <20424.39815.180423.370810@mariner.uk.xensource.com>
References: <3496f86000b80595b34a.1338535311@linux-x12>
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>
	<20424.39815.180423.370810@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 11:37 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] [v3] libxl: Add API to retrieve domain console tty"):
> > On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
> > >  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
> > > tty) will lead to null pointer access in CTX maco. 
> > 
> > I haven't looked at the rest of the patch you but thought I'd pick up on
> > this now since we have at least one existing libxl__strdup(0, ..) in
> >         b_info->blkdev_start = libxl__strdup(0, "xvda");
> >         
> > so we need to decide what to do in general. libxl__strdup wants the CTX
> > so it can complain via the logs on malloc failure.
> 
> Damn.  I shouldn't have let you talk me into adding the extra
> ctx-based logging, evidently.  I had forgotten the reason for the lack
> of that.  (Because it was in the next patch.)
> 
> > This looks like a problem even with the functions which take a
> > "gc_opt" (i.e. where gc==NULL is explicitly supposed to be allowed).
> 
> Yes.
> 
> > libxl__alloc_failed() could take a gc_opt instead of a ctx and only log
> > if it is non-null. It already also logs via stderr, since this is a
> > catastrophic failure from which we won't return.
> 
> Yes.
> 
> > We could also have a process-global libxl_alloc_failure_hook(const char
> > *argh) to allow the calling application to have some chance to log via
> > its own routines...
> 
> Yes.
> 
> > IanJ -- you added all this, what do you think?
> 
> I think the above is a good proposal.

Who's going to do it then ;-)

(FWIW I think libxl_alloc_failure_hook is an optional nice to have)

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPHH-0002R0-TG; Fri, 01 Jun 2012 10:40:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaPHG-0002Qj-D7
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:40:18 +0000
Received: from [85.158.143.99:60626] by server-3.bemta-4.messagelabs.com id
	06/3A-04252-11C98CF4; Fri, 01 Jun 2012 10:40:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338547216!30333480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17592 invoked from network); 1 Jun 2012 10:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12783847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:40:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:40:16 +0100
Message-ID: <1338547215.17466.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 11:40:15 +0100
In-Reply-To: <20424.39815.180423.370810@mariner.uk.xensource.com>
References: <3496f86000b80595b34a.1338535311@linux-x12>
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>
	<20424.39815.180423.370810@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 11:37 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] [v3] libxl: Add API to retrieve domain console tty"):
> > On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
> > >  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
> > > tty) will lead to null pointer access in CTX maco. 
> > 
> > I haven't looked at the rest of the patch you but thought I'd pick up on
> > this now since we have at least one existing libxl__strdup(0, ..) in
> >         b_info->blkdev_start = libxl__strdup(0, "xvda");
> >         
> > so we need to decide what to do in general. libxl__strdup wants the CTX
> > so it can complain via the logs on malloc failure.
> 
> Damn.  I shouldn't have let you talk me into adding the extra
> ctx-based logging, evidently.  I had forgotten the reason for the lack
> of that.  (Because it was in the next patch.)
> 
> > This looks like a problem even with the functions which take a
> > "gc_opt" (i.e. where gc==NULL is explicitly supposed to be allowed).
> 
> Yes.
> 
> > libxl__alloc_failed() could take a gc_opt instead of a ctx and only log
> > if it is non-null. It already also logs via stderr, since this is a
> > catastrophic failure from which we won't return.
> 
> Yes.
> 
> > We could also have a process-global libxl_alloc_failure_hook(const char
> > *argh) to allow the calling application to have some chance to log via
> > its own routines...
> 
> Yes.
> 
> > IanJ -- you added all this, what do you think?
> 
> I think the above is a good proposal.

Who's going to do it then ;-)

(FWIW I think libxl_alloc_failure_hook is an optional nice to have)

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:43: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 1SaPJv-0002hD-Fs; Fri, 01 Jun 2012 10:43:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaPJu-0002h0-G2
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:43:02 +0000
Received: from [85.158.143.35:51029] by server-3.bemta-4.messagelabs.com id
	D3/6F-04252-5BC98CF4; Fri, 01 Jun 2012 10:43:01 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338547380!18418937!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10884 invoked from network); 1 Jun 2012 10:43:00 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 10:43:00 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 9E287CE682F;
	Fri,  1 Jun 2012 12:42:59 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id oEFL9xfFD6Dt; Fri,  1 Jun 2012 12:42:59 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 12:42:59 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 5F4C049C20C;
	Fri,  1 Jun 2012 11:42:59 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 12:43:18 +0200
Message-Id: <1338547398-21681-1-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Andre Przywara <andre.przywara@amd.com>

f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it") wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.

This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.

This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).

Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: stable@vger.kernel.org # 3.4+
Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/kernel/cpu/amd.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 146bb6218eec..80ccd99542e6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -586,9 +586,9 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 	    !cpu_has(c, X86_FEATURE_TOPOEXT)) {
 		u64 val;
 
-		if (!rdmsrl_amd_safe(0xc0011005, &val)) {
+		if (!rdmsrl_safe(0xc0011005, &val)) {
 			val |= 1ULL << 54;
-			wrmsrl_amd_safe(0xc0011005, val);
+			checking_wrmsrl(0xc0011005, val);
 			rdmsrl(0xc0011005, val);
 			if (val & (1ULL << 54)) {
 				set_cpu_cap(c, X86_FEATURE_TOPOEXT);
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:43: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 1SaPJv-0002hD-Fs; Fri, 01 Jun 2012 10:43:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaPJu-0002h0-G2
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:43:02 +0000
Received: from [85.158.143.35:51029] by server-3.bemta-4.messagelabs.com id
	D3/6F-04252-5BC98CF4; Fri, 01 Jun 2012 10:43:01 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338547380!18418937!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10884 invoked from network); 1 Jun 2012 10:43:00 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-14.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 10:43:00 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 9E287CE682F;
	Fri,  1 Jun 2012 12:42:59 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id oEFL9xfFD6Dt; Fri,  1 Jun 2012 12:42:59 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 12:42:59 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 5F4C049C20C;
	Fri,  1 Jun 2012 11:42:59 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 12:43:18 +0200
Message-Id: <1338547398-21681-1-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Andre Przywara <andre.przywara@amd.com>

f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it") wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.

This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.

This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).

Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: stable@vger.kernel.org # 3.4+
Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/kernel/cpu/amd.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 146bb6218eec..80ccd99542e6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -586,9 +586,9 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 	    !cpu_has(c, X86_FEATURE_TOPOEXT)) {
 		u64 val;
 
-		if (!rdmsrl_amd_safe(0xc0011005, &val)) {
+		if (!rdmsrl_safe(0xc0011005, &val)) {
 			val |= 1ULL << 54;
-			wrmsrl_amd_safe(0xc0011005, val);
+			checking_wrmsrl(0xc0011005, val);
 			rdmsrl(0xc0011005, val);
 			if (val & (1ULL << 54)) {
 				set_cpu_cap(c, X86_FEATURE_TOPOEXT);
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:48:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPOb-0002tH-6u; Fri, 01 Jun 2012 10:47:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaPOZ-0002tA-GF
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:47:51 +0000
Received: from [85.158.143.35:12306] by server-2.bemta-4.messagelabs.com id
	08/4A-11595-6DD98CF4; Fri, 01 Jun 2012 10:47:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338547669!13099228!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5310 invoked from network); 1 Jun 2012 10:47:49 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 10:47:49 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78340168; Fri, 01 Jun 2012 12:47:45 +0200
Message-ID: <1338547664.31901.54.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 12:47:44 +0200
In-Reply-To: <1338547136.17466.77.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5283609742334525823=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5283609742334525823==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Upd1/X7cFHC2FPw0qNG/"


--=-Upd1/X7cFHC2FPw0qNG/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 11:38 +0100, Ian Campbell wrote:=20
> > Anyway, I just tried 25 and 33 and 65, and creation of the domain worke=
d
> > without raising any errors! Then I double-checked, and saw that, in the
> > 'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I lo=
g
> > into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
> > 65 VCPUs case).
>=20
> All 64 online?
>=20
I see all of them from the host (xl vcpu-list) but a kind of random
number of them from the guest...

> It might be that the issue being fixed here only manifests on HVM. I'm
> not really sure how 64 would work otherwise since cur_vcpus in the IDL
> is definitely an int, which is what needs fixing!
>=20
and in fact, I agreed with that part of the patch. Also, yes, I'm trying
PV but can try HVM as well and see what happens.

> libxl__build_post is also probably buggy with max_vcpus >
> nr-bits-in(curr_vcpus) and from the looks of it it just overflows off
> the end(!), which is also fixed here...
>=20
What I can do is trying again with the patch applied, and if it still
behaves weird I'll go seeing what might be still missing.

> > "max. number of cpus supported by hypervisor" to be different from the
> > actual number of physical processors, and I was sort-of mislead by the
> > machine I use to test Xen every day (where that is actually happening!)=
.
> > If it is not like that, I guess I can agree with you on this change.
>=20
> It's certainly supposed to be "get max. number of physical cpus", quite
> how that relates to the actual number of physical cpus I'm not sure.
>=20
> It's definitely not something to do with virtual cpus (for which there
> is a limit, but not this one...)
>=20
Ok, with that "physical" you're putting there, I see and agree it could
be useful untie it from the "virtual world". :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Upd1/X7cFHC2FPw0qNG/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IndAACgkQk4XaBE3IOsRerQCfZLYguulHdITcWLDlQtHO4d4M
PJcAoJItTYH0bW+1qJ7/Lv69E6ljimLG
=OBeB
-----END PGP SIGNATURE-----

--=-Upd1/X7cFHC2FPw0qNG/--



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

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

--===============5283609742334525823==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 10:48:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPOb-0002tH-6u; Fri, 01 Jun 2012 10:47:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaPOZ-0002tA-GF
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:47:51 +0000
Received: from [85.158.143.35:12306] by server-2.bemta-4.messagelabs.com id
	08/4A-11595-6DD98CF4; Fri, 01 Jun 2012 10:47:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338547669!13099228!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5310 invoked from network); 1 Jun 2012 10:47:49 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 10:47:49 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78340168; Fri, 01 Jun 2012 12:47:45 +0200
Message-ID: <1338547664.31901.54.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 12:47:44 +0200
In-Reply-To: <1338547136.17466.77.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5283609742334525823=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5283609742334525823==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Upd1/X7cFHC2FPw0qNG/"


--=-Upd1/X7cFHC2FPw0qNG/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 11:38 +0100, Ian Campbell wrote:=20
> > Anyway, I just tried 25 and 33 and 65, and creation of the domain worke=
d
> > without raising any errors! Then I double-checked, and saw that, in the
> > 'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I lo=
g
> > into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
> > 65 VCPUs case).
>=20
> All 64 online?
>=20
I see all of them from the host (xl vcpu-list) but a kind of random
number of them from the guest...

> It might be that the issue being fixed here only manifests on HVM. I'm
> not really sure how 64 would work otherwise since cur_vcpus in the IDL
> is definitely an int, which is what needs fixing!
>=20
and in fact, I agreed with that part of the patch. Also, yes, I'm trying
PV but can try HVM as well and see what happens.

> libxl__build_post is also probably buggy with max_vcpus >
> nr-bits-in(curr_vcpus) and from the looks of it it just overflows off
> the end(!), which is also fixed here...
>=20
What I can do is trying again with the patch applied, and if it still
behaves weird I'll go seeing what might be still missing.

> > "max. number of cpus supported by hypervisor" to be different from the
> > actual number of physical processors, and I was sort-of mislead by the
> > machine I use to test Xen every day (where that is actually happening!)=
.
> > If it is not like that, I guess I can agree with you on this change.
>=20
> It's certainly supposed to be "get max. number of physical cpus", quite
> how that relates to the actual number of physical cpus I'm not sure.
>=20
> It's definitely not something to do with virtual cpus (for which there
> is a limit, but not this one...)
>=20
Ok, with that "physical" you're putting there, I see and agree it could
be useful untie it from the "virtual world". :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Upd1/X7cFHC2FPw0qNG/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IndAACgkQk4XaBE3IOsRerQCfZLYguulHdITcWLDlQtHO4d4M
PJcAoJItTYH0bW+1qJ7/Lv69E6ljimLG
=OBeB
-----END PGP SIGNATURE-----

--=-Upd1/X7cFHC2FPw0qNG/--



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

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

--===============5283609742334525823==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 10:50:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaPRK-0002zW-Qy; Fri, 01 Jun 2012 10:50:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaPRJ-0002zN-43
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:50:41 +0000
Received: from [85.158.143.99:17129] by server-2.bemta-4.messagelabs.com id
	4D/AF-11595-08E98CF4; Fri, 01 Jun 2012 10:50:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338547837!21249150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26318 invoked from network); 1 Jun 2012 10:50:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:50:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:50:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:50:37 +0100
Message-ID: <1338547835.17466.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 11:50:35 +0100
In-Reply-To: <1338547664.31901.54.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
	<1338547664.31901.54.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 11:47 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 11:38 +0100, Ian Campbell wrote: 
> > > Anyway, I just tried 25 and 33 and 65, and creation of the domain worked
> > > without raising any errors! Then I double-checked, and saw that, in the
> > > 'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I log
> > > into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
> > > 65 VCPUs case).
> > 
> > All 64 online?
> > 
> I see all of them from the host (xl vcpu-list) but a kind of random
> number of them from the guest...

Which is probably the overflow I mentioned giving you a random set of
online cpus after #32...

> > libxl__build_post is also probably buggy with max_vcpus >
> > nr-bits-in(curr_vcpus) and from the looks of it it just overflows off
> > the end(!), which is also fixed here...
> > 
> What I can do is trying again with the patch applied, and if it still
> behaves weird I'll go seeing what might be still missing.
> 
> > > "max. number of cpus supported by hypervisor" to be different from the
> > > actual number of physical processors, and I was sort-of mislead by the
> > > machine I use to test Xen every day (where that is actually happening!).
> > > If it is not like that, I guess I can agree with you on this change.
> > 
> > It's certainly supposed to be "get max. number of physical cpus", quite
> > how that relates to the actual number of physical cpus I'm not sure.
> > 
> > It's definitely not something to do with virtual cpus (for which there
> > is a limit, but not this one...)
> > 
> Ok, with that "physical" you're putting there, I see and agree it could
> be useful untie it from the "virtual world". :-)

Is that an ACK for this and/or the previous patch?

> 
> Thanks and Regards,
> Dario
> 



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:50:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaPRK-0002zW-Qy; Fri, 01 Jun 2012 10:50:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaPRJ-0002zN-43
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 10:50:41 +0000
Received: from [85.158.143.99:17129] by server-2.bemta-4.messagelabs.com id
	4D/AF-11595-08E98CF4; Fri, 01 Jun 2012 10:50:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338547837!21249150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26318 invoked from network); 1 Jun 2012 10:50:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:50:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:50:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	11:50:37 +0100
Message-ID: <1338547835.17466.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 11:50:35 +0100
In-Reply-To: <1338547664.31901.54.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
	<1338547664.31901.54.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 11:47 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 11:38 +0100, Ian Campbell wrote: 
> > > Anyway, I just tried 25 and 33 and 65, and creation of the domain worked
> > > without raising any errors! Then I double-checked, and saw that, in the
> > > 'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I log
> > > into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the
> > > 65 VCPUs case).
> > 
> > All 64 online?
> > 
> I see all of them from the host (xl vcpu-list) but a kind of random
> number of them from the guest...

Which is probably the overflow I mentioned giving you a random set of
online cpus after #32...

> > libxl__build_post is also probably buggy with max_vcpus >
> > nr-bits-in(curr_vcpus) and from the looks of it it just overflows off
> > the end(!), which is also fixed here...
> > 
> What I can do is trying again with the patch applied, and if it still
> behaves weird I'll go seeing what might be still missing.
> 
> > > "max. number of cpus supported by hypervisor" to be different from the
> > > actual number of physical processors, and I was sort-of mislead by the
> > > machine I use to test Xen every day (where that is actually happening!).
> > > If it is not like that, I guess I can agree with you on this change.
> > 
> > It's certainly supposed to be "get max. number of physical cpus", quite
> > how that relates to the actual number of physical cpus I'm not sure.
> > 
> > It's definitely not something to do with virtual cpus (for which there
> > is a limit, but not this one...)
> > 
> Ok, with that "physical" you're putting there, I see and agree it could
> be useful untie it from the "virtual world". :-)

Is that an ACK for this and/or the previous patch?

> 
> Thanks and Regards,
> Dario
> 



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPYP-0003bc-2l; Fri, 01 Jun 2012 10:58: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 1SaPYO-0003bU-4B
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:58:00 +0000
Received: from [85.158.138.51:12860] by server-12.bemta-3.messagelabs.com id
	97/E9-29860-730A8CF4; Fri, 01 Jun 2012 10:57:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338548276!30284598!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5553 invoked from network); 1 Jun 2012 10:57: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;
	1 Jun 2012 10:57:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197172905"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:57:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:57:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaPY6-0006PA-R5;
	Fri, 01 Jun 2012 11:57:42 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 11:57:39 +0100
Message-ID: <1338548259-3767-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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on BSD
	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BSD systems already have a sys/queue.h file, which has more macros
than the one Qemu uses, and some header files depend on having that
macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
systems and include the native one.

This is not a backport because the original patch is too dificult to
backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.

Doing a diff -bB shows that the Qemu version is just a stripped
version of the original NetBSD header, with many macros removed, but
no new ones added.

Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 sys-queue.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/sys-queue.h b/sys-queue.h
index cb6a4c8..55c26fe 100644
--- a/sys-queue.h
+++ b/sys-queue.h
@@ -36,6 +36,12 @@
  *      @(#)queue.h     8.5 (Berkeley) 8/20/94
  */
 
+#include "config-host.h"
+#ifdef _BSD
+/* include native header before sys-queue.h */
+#include <sys/queue.h>
+#endif
+
 #ifndef _SYS_QUEUE_H_
 #define _SYS_QUEUE_H_
 
-- 
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 Jun 01 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10: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 1SaPYP-0003bc-2l; Fri, 01 Jun 2012 10:58: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 1SaPYO-0003bU-4B
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:58:00 +0000
Received: from [85.158.138.51:12860] by server-12.bemta-3.messagelabs.com id
	97/E9-29860-730A8CF4; Fri, 01 Jun 2012 10:57:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338548276!30284598!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5553 invoked from network); 1 Jun 2012 10:57: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;
	1 Jun 2012 10:57:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197172905"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 06:57:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 06:57:43 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaPY6-0006PA-R5;
	Fri, 01 Jun 2012 11:57:42 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 11:57:39 +0100
Message-ID: <1338548259-3767-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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on BSD
	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BSD systems already have a sys/queue.h file, which has more macros
than the one Qemu uses, and some header files depend on having that
macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
systems and include the native one.

This is not a backport because the original patch is too dificult to
backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.

Doing a diff -bB shows that the Qemu version is just a stripped
version of the original NetBSD header, with many macros removed, but
no new ones added.

Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 sys-queue.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/sys-queue.h b/sys-queue.h
index cb6a4c8..55c26fe 100644
--- a/sys-queue.h
+++ b/sys-queue.h
@@ -36,6 +36,12 @@
  *      @(#)queue.h     8.5 (Berkeley) 8/20/94
  */
 
+#include "config-host.h"
+#ifdef _BSD
+/* include native header before sys-queue.h */
+#include <sys/queue.h>
+#endif
+
 #ifndef _SYS_QUEUE_H_
 #define _SYS_QUEUE_H_
 
-- 
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 Jun 01 10:59:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:59: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 1SaPZp-0003iA-Hy; Fri, 01 Jun 2012 10:59:29 +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 1SaPZo-0003i1-0C
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:59:28 +0000
Received: from [85.158.139.83:59427] by server-12.bemta-5.messagelabs.com id
	38/31-18374-F80A8CF4; Fri, 01 Jun 2012 10:59:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338548366!30034151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1705 invoked from network); 1 Jun 2012 10:59:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:59:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:59:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 11:59:25 +0100
Date: Fri, 1 Jun 2012 11:59:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338548259-3767-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.00.1206011158570.26786@kaball-desktop>
References: <1338548259-3767-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on BSD
	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Roger Pau Monne wrote:
> BSD systems already have a sys/queue.h file, which has more macros
> than the one Qemu uses, and some header files depend on having that
> macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
> systems and include the native one.
> 
> This is not a backport because the original patch is too dificult to
> backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
> 
> Doing a diff -bB shows that the Qemu version is just a stripped
> version of the original NetBSD header, with many macros removed, but
> no new ones added.
> 
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  sys-queue.h |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/sys-queue.h b/sys-queue.h
> index cb6a4c8..55c26fe 100644
> --- a/sys-queue.h
> +++ b/sys-queue.h
> @@ -36,6 +36,12 @@
>   *      @(#)queue.h     8.5 (Berkeley) 8/20/94
>   */
>  
> +#include "config-host.h"
> +#ifdef _BSD
> +/* include native header before sys-queue.h */
> +#include <sys/queue.h>
> +#endif
> +
>  #ifndef _SYS_QUEUE_H_
>  #define _SYS_QUEUE_H_
>  
> -- 
> 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 Jun 01 10:59:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 10:59: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 1SaPZp-0003iA-Hy; Fri, 01 Jun 2012 10:59:29 +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 1SaPZo-0003i1-0C
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 10:59:28 +0000
Received: from [85.158.139.83:59427] by server-12.bemta-5.messagelabs.com id
	38/31-18374-F80A8CF4; Fri, 01 Jun 2012 10:59:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338548366!30034151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1705 invoked from network); 1 Jun 2012 10:59:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 10:59:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 10:59:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 11:59:25 +0100
Date: Fri, 1 Jun 2012 11:59:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338548259-3767-1-git-send-email-roger.pau@citrix.com>
Message-ID: <alpine.DEB.2.00.1206011158570.26786@kaball-desktop>
References: <1338548259-3767-1-git-send-email-roger.pau@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on BSD
	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Roger Pau Monne wrote:
> BSD systems already have a sys/queue.h file, which has more macros
> than the one Qemu uses, and some header files depend on having that
> macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
> systems and include the native one.
> 
> This is not a backport because the original patch is too dificult to
> backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
> 
> Doing a diff -bB shows that the Qemu version is just a stripped
> version of the original NetBSD header, with many macros removed, but
> no new ones added.
> 
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  sys-queue.h |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/sys-queue.h b/sys-queue.h
> index cb6a4c8..55c26fe 100644
> --- a/sys-queue.h
> +++ b/sys-queue.h
> @@ -36,6 +36,12 @@
>   *      @(#)queue.h     8.5 (Berkeley) 8/20/94
>   */
>  
> +#include "config-host.h"
> +#ifdef _BSD
> +/* include native header before sys-queue.h */
> +#include <sys/queue.h>
> +#endif
> +
>  #ifndef _SYS_QUEUE_H_
>  #define _SYS_QUEUE_H_
>  
> -- 
> 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 Jun 01 11:04:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:04: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 1SaPeu-0004LJ-EN; Fri, 01 Jun 2012 11:04:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaPes-0004LB-Hy
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:04:42 +0000
Received: from [85.158.143.99:60276] by server-2.bemta-4.messagelabs.com id
	78/CC-11595-9C1A8CF4; Fri, 01 Jun 2012 11:04:41 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338548681!23863454!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4132 invoked from network); 1 Jun 2012 11:04:41 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-216.messagelabs.com with SMTP;
	1 Jun 2012 11:04:41 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78340745; Fri, 01 Jun 2012 13:04:40 +0200
Message-ID: <1338548680.31901.57.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 13:04:40 +0200
In-Reply-To: <1338547835.17466.82.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
	<1338547664.31901.54.camel@Abyss>
	<1338547835.17466.82.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4895797601268354372=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4895797601268354372==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-GheMw5fD0or2I7yAWzON"


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

On Fri, 2012-06-01 at 11:50 +0100, Ian Campbell wrote:=20
> > Ok, with that "physical" you're putting there, I see and agree it could
> > be useful untie it from the "virtual world". :-)
>=20
> Is that an ACK for this and/or the previous patch?
>=20
Oh, yes, sorry for being a bit cryptic. For what my opinion counts, it
is. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-GheMw5fD0or2I7yAWzON
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IocgACgkQk4XaBE3IOsSbnQCdHsRenzUsw9OTlWDUUmGfdQZU
mdYAniOAr6znv5PxUKDlqSwq+hfVWW7L
=FS2j
-----END PGP SIGNATURE-----

--=-GheMw5fD0or2I7yAWzON--



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

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

--===============4895797601268354372==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 11:04:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:04: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 1SaPeu-0004LJ-EN; Fri, 01 Jun 2012 11:04:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SaPes-0004LB-Hy
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:04:42 +0000
Received: from [85.158.143.99:60276] by server-2.bemta-4.messagelabs.com id
	78/CC-11595-9C1A8CF4; Fri, 01 Jun 2012 11:04:41 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338548681!23863454!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4132 invoked from network); 1 Jun 2012 11:04:41 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-216.messagelabs.com with SMTP;
	1 Jun 2012 11:04:41 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78340745; Fri, 01 Jun 2012 13:04:40 +0200
Message-ID: <1338548680.31901.57.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 01 Jun 2012 13:04:40 +0200
In-Reply-To: <1338547835.17466.82.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
	<1338547664.31901.54.camel@Abyss>
	<1338547835.17466.82.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4895797601268354372=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4895797601268354372==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-GheMw5fD0or2I7yAWzON"


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

On Fri, 2012-06-01 at 11:50 +0100, Ian Campbell wrote:=20
> > Ok, with that "physical" you're putting there, I see and agree it could
> > be useful untie it from the "virtual world". :-)
>=20
> Is that an ACK for this and/or the previous patch?
>=20
Oh, yes, sorry for being a bit cryptic. For what my opinion counts, it
is. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-GheMw5fD0or2I7yAWzON
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/IocgACgkQk4XaBE3IOsSbnQCdHsRenzUsw9OTlWDUUmGfdQZU
mdYAniOAr6znv5PxUKDlqSwq+hfVWW7L
=FS2j
-----END PGP SIGNATURE-----

--=-GheMw5fD0or2I7yAWzON--



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

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

--===============4895797601268354372==--



From xen-devel-bounces@lists.xen.org Fri Jun 01 11:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPfy-0004TK-Sx; Fri, 01 Jun 2012 11:05: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 1SaPfx-0004T9-Hh
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:05:49 +0000
Received: from [85.158.143.99:10499] by server-2.bemta-4.messagelabs.com id
	3C/0F-11595-C02A8CF4; Fri, 01 Jun 2012 11:05:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338548747!21252502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16425 invoked from network); 1 Jun 2012 11:05:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:05:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:05:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:05:47 +0100
Message-ID: <1338548745.17466.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 1 Jun 2012 12:05:45 +0100
In-Reply-To: <4dad9647a0963a2665cc.1338476667@probook.site>
References: <4dad9647a0963a2665cc.1338476667@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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 Thu, 2012-05-31 at 16:04 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338476618 -7200
> # Node ID 4dad9647a0963a2665ccf055492e740c2b399517
> # Parent  d7318231cfe3498947bf75f09d6675407d7b4e76
> xl.cfg: document the maxmem= option
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r d7318231cfe3 -r 4dad9647a096 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -174,6 +174,14 @@ Honoured by the sedf scheduler.
>  
>  Start the guest with MBYTES megabytes of RAM.
>  
> +=item B<maxmem=MBYTES>
> +
> +Specifies the maximum amount of memory a guest can ever see.
> +The value of maxmem= must be equal or greater than memory=.
> +In combination with the memory= option it will start the guest "pre-ballooned".
> +In a HVM guest it will enable the PoD (populate on demand) mode, iff the values of memory= and maxmem= differ.
> +The guest needs a balloon driver in this case, without a balloon driver it will crash.

"iff" has proven to be confusing in the past (we keep getting "fix typo"
patches for existing ones) maybe just spell it out? Otherwise Ack on the
text. Although may add a note that booting a PV guest "pre-ballooned"
Just Works?

Formatting wise some of these lines are very long. Can you wrap to 80
columns please.

Also why have you wrapped this as one sentence per line rather than
wrapping it as paragraphs (which should have blank lines between them)?

I think maxmem= should be B<maxmem=> and the same for memory=.

Ian.

> +
>  =item B<on_poweroff="ACTION">
>  
>  Specifies what should be done with the domain if it shuts itself down.
> @@ -971,10 +979,6 @@ XXX
>  
>  XXX
>  
> -=item B<maxmem=NUMBER>
> -
> -XXX
> -
>  =item B<nodes=XXX>
>  
>  XXX
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 01 11:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPfy-0004TK-Sx; Fri, 01 Jun 2012 11:05: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 1SaPfx-0004T9-Hh
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:05:49 +0000
Received: from [85.158.143.99:10499] by server-2.bemta-4.messagelabs.com id
	3C/0F-11595-C02A8CF4; Fri, 01 Jun 2012 11:05:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338548747!21252502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16425 invoked from network); 1 Jun 2012 11:05:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:05:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:05:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:05:47 +0100
Message-ID: <1338548745.17466.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 1 Jun 2012 12:05:45 +0100
In-Reply-To: <4dad9647a0963a2665cc.1338476667@probook.site>
References: <4dad9647a0963a2665cc.1338476667@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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 Thu, 2012-05-31 at 16:04 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338476618 -7200
> # Node ID 4dad9647a0963a2665ccf055492e740c2b399517
> # Parent  d7318231cfe3498947bf75f09d6675407d7b4e76
> xl.cfg: document the maxmem= option
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r d7318231cfe3 -r 4dad9647a096 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -174,6 +174,14 @@ Honoured by the sedf scheduler.
>  
>  Start the guest with MBYTES megabytes of RAM.
>  
> +=item B<maxmem=MBYTES>
> +
> +Specifies the maximum amount of memory a guest can ever see.
> +The value of maxmem= must be equal or greater than memory=.
> +In combination with the memory= option it will start the guest "pre-ballooned".
> +In a HVM guest it will enable the PoD (populate on demand) mode, iff the values of memory= and maxmem= differ.
> +The guest needs a balloon driver in this case, without a balloon driver it will crash.

"iff" has proven to be confusing in the past (we keep getting "fix typo"
patches for existing ones) maybe just spell it out? Otherwise Ack on the
text. Although may add a note that booting a PV guest "pre-ballooned"
Just Works?

Formatting wise some of these lines are very long. Can you wrap to 80
columns please.

Also why have you wrapped this as one sentence per line rather than
wrapping it as paragraphs (which should have blank lines between them)?

I think maxmem= should be B<maxmem=> and the same for memory=.

Ian.

> +
>  =item B<on_poweroff="ACTION">
>  
>  Specifies what should be done with the domain if it shuts itself down.
> @@ -971,10 +979,6 @@ XXX
>  
>  XXX
>  
> -=item B<maxmem=NUMBER>
> -
> -XXX
> -
>  =item B<nodes=XXX>
>  
>  XXX
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 01 11:08:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPhu-0004dk-EY; Fri, 01 Jun 2012 11:07: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 1SaPhs-0004dP-Up
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:07:49 +0000
Received: from [85.158.143.99:61813] by server-2.bemta-4.messagelabs.com id
	42/83-11595-482A8CF4; Fri, 01 Jun 2012 11:07:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338548867!23864204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22195 invoked from network); 1 Jun 2012 11:07:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:07:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:07:08 +0100
Message-ID: <1338548826.17466.88.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, 1 Jun 2012 12:07:06 +0100
In-Reply-To: <patchbomb.1338299818@cosworth.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-05-29 at 14:56 +0100, Ian Campbell wrote:
> This series defines a descriminating value for each scheduler paramter
> and uses it to fix a warning when starting a guest:
>   "Cpu weight out of range, valid values are within range from 1 to 65535"

I applied this with George and Ian J's acks.

Thanks.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:08:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPhu-0004dk-EY; Fri, 01 Jun 2012 11:07: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 1SaPhs-0004dP-Up
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:07:49 +0000
Received: from [85.158.143.99:61813] by server-2.bemta-4.messagelabs.com id
	42/83-11595-482A8CF4; Fri, 01 Jun 2012 11:07:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338548867!23864204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22195 invoked from network); 1 Jun 2012 11:07:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:07:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:07:08 +0100
Message-ID: <1338548826.17466.88.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, 1 Jun 2012 12:07:06 +0100
In-Reply-To: <patchbomb.1338299818@cosworth.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-05-29 at 14:56 +0100, Ian Campbell wrote:
> This series defines a descriminating value for each scheduler paramter
> and uses it to fix a warning when starting a guest:
>   "Cpu weight out of range, valid values are within range from 1 to 65535"

I applied this with George and Ian J's acks.

Thanks.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:08:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPhu-0004ds-PY; Fri, 01 Jun 2012 11:07: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 1SaPht-0004dX-Ic
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:07:49 +0000
Received: from [85.158.143.35:37299] by server-3.bemta-4.messagelabs.com id
	CE/94-04252-482A8CF4; Fri, 01 Jun 2012 11:07:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338548867!18337831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29262 invoked from network); 1 Jun 2012 11:07:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:07:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:07:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:07:05 +0100
Message-ID: <1338548824.17466.87.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 1 Jun 2012 12:07:04 +0100
In-Reply-To: <a836c330fd736b751f5e.1338501349@probook.site>
References: <a836c330fd736b751f5e.1338501349@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix typos in libxl_cpuid_parse_config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 22:55 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338501314 -7200
> # Node ID a836c330fd736b751f5e26b5d9d816d8fa59d28b
> # Parent  4dad9647a0963a2665ccf055492e740c2b399517
> libxl: fix typos in libxl_cpuid_parse_config
> 
> Fix typo in comment.
> Fix cpuid_flags array init, use correct number of arguments for empty
> array entry.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Committed, thanks.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:08:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPhu-0004ds-PY; Fri, 01 Jun 2012 11:07: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 1SaPht-0004dX-Ic
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:07:49 +0000
Received: from [85.158.143.35:37299] by server-3.bemta-4.messagelabs.com id
	CE/94-04252-482A8CF4; Fri, 01 Jun 2012 11:07:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338548867!18337831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29262 invoked from network); 1 Jun 2012 11:07:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:07:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:07:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:07:05 +0100
Message-ID: <1338548824.17466.87.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 1 Jun 2012 12:07:04 +0100
In-Reply-To: <a836c330fd736b751f5e.1338501349@probook.site>
References: <a836c330fd736b751f5e.1338501349@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix typos in libxl_cpuid_parse_config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 22:55 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338501314 -7200
> # Node ID a836c330fd736b751f5e26b5d9d816d8fa59d28b
> # Parent  4dad9647a0963a2665ccf055492e740c2b399517
> libxl: fix typos in libxl_cpuid_parse_config
> 
> Fix typo in comment.
> Fix cpuid_flags array init, use correct number of arguments for empty
> array entry.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Committed, thanks.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj8-0004qi-9C; Fri, 01 Jun 2012 11:09:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hughd@google.com>) id 1SYLka-0005iS-PH
	for xen-devel@lists.xensource.com; Sat, 26 May 2012 18:30:04 +0000
Received: from [85.158.143.35:26008] by server-2.bemta-4.messagelabs.com id
	52/D1-12211-C2121CF4; Sat, 26 May 2012 18:30:04 +0000
X-Env-Sender: hughd@google.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338057000!6998668!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18670 invoked from network); 26 May 2012 18:30:02 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 May 2012 18:30:02 -0000
Received: by pbcwz7 with SMTP id wz7so3319074pbc.30
	for <xen-devel@lists.xensource.com>;
	Sat, 26 May 2012 11:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type;
	bh=d4f2GdIywtmwaBCf8lnl2UqZT2dS2W8TrYCqAWbYosw=;
	b=GDhZkBXaWkllV53FhTplV9yZmpvHUHtMdngJKO9qZuarWViQIdmk0iolH0Ic/7jmtw
	g4rp7XNJtjUMhsMtKY2lJg/lTm4IF6hphQeRzGR0osZ5atJn3EnvLoIaFUiB8fv11QIf
	NsKXpnGc+Uu1GjjGJT1hPmi7OuSulTok3vle077a30aOZnzazXBOUA5g26HFzakP+WmV
	IXJz9oi5bNbJQonEyAsgTdQ8DIuquDOG6NfVmPtw1ZeLPLvjnFiIQqH3dQfRM0kvAgH1
	t7trzx+RIyXrB4guma0lgheb5VWYkI71tqucfdSXtIaeksDv/QKtRZM0NFEX7wrSLloM
	oywQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type:x-gm-message-state;
	bh=d4f2GdIywtmwaBCf8lnl2UqZT2dS2W8TrYCqAWbYosw=;
	b=LBRc27Ycc9MN47qOjXqxeSWOOMM2je36t+rsw3bOc/7XhhhDsgufqWiMkaQNzxrS7t
	dtX1HgKASxM/+AKRPykTpEhmEZ5G6WdTxlWcglvrpYmiJRoFlzOqWpeucqdfl8pxA9SU
	zW9YKhRGj/8TsmkN0LHidbm+EcDnMljI6/7vRkyZtpPm6p7WWof0vxmL1sultcIkG1Ho
	3aFpnnQufl3fYhvJwv8jxU6Zf7Tsh4WwwOVKwXWJbLN8DsQvwiL+NefH3M7PC1x3oLsb
	BpPurlX07bwiLeAXCEZpOxxQP/D8geUTRWmkyVCTM8gD9ASsLJrV6yDCKC7wW777SRM4
	da5A==
Received: by 10.68.226.228 with SMTP id rv4mr10251267pbc.167.1338057000334;
	Sat, 26 May 2012 11:30:00 -0700 (PDT)
Received: by 10.68.226.228 with SMTP id rv4mr10251245pbc.167.1338057000237;
	Sat, 26 May 2012 11:30:00 -0700 (PDT)
Received: from [192.168.1.8] (c-67-188-178-35.hsd1.ca.comcast.net.
	[67.188.178.35])
	by mx.google.com with ESMTPS id vi10sm13270583pbc.4.2012.05.26.11.29.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 26 May 2012 11:29:59 -0700 (PDT)
Date: Sat, 26 May 2012 11:29:37 -0700 (PDT)
From: Hugh Dickins <hughd@google.com>
X-X-Sender: hugh@eggly.anvils
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120521181558.GA7829@phenom.dumpdata.com>
Message-ID: <alpine.LSU.2.00.1205261113470.2033@eggly.anvils>
References: <CAJ75kXbC3gqQAaghKo2i1L650dw9-vrFuEwoy4defagoyR8p4Q@mail.gmail.com>
	<20120521181558.GA7829@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
X-Gm-Message-State: ALoCoQmxgOIp3Cu/natxrDN4De3hIQOtCClsDsMxb3v8UFtzVJbmAh5tcBFzDgsEnxN229k/QWeE1+Y10aStxivDnH2LdRqxUihKyAySEoo+x8PfUJF1e+NtNnXwkU6SneE1jAP/lY2vdTFiscGgJnfu7Yecsk+B8w==
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: xen-devel@lists.xensource.com, Ben Hutchings <ben@decadent.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	shli@fusionio.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, William Dauchy <wdauchy@gmail.com>,
	Shaohua Li <shli@kernel.org>
Subject: Re: [Xen-devel] swap: don't do discard if no discard option added
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 21 May 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, May 21, 2012 at 12:30:45AM +0200, William Dauchy wrote:
> > Hello,
> > 
> > On Xen, when booting a guest with a system disk and an additional swap
> > disk I'm getting a calltrace.
> > xen hypervisor: 4.1.2; linux dom0: v3.3.6; linux guest: v3.2.17
> > When booting without a swap disk, I don't have the issue.
> > I also tested a guest with v3.3.6: same problem. But from v3.4-rc2,
> > the issue is fixed.
> > I cherry-picked:
> 
> > 052b198 swap: don't do discard if no discard option added
> 
> So you are asking for 052b198 to be back-ported.
> 
> I am OK with that but I think Shaohua needs to Ack that and
> ask Greg to put it on stable@kernel.org

Since that commit did indeed go into v3.4, I won't quarrel with it
now going to stable.

But the commit went in to work around the slow discard implementation
on OCZ Vertex II SSDs.

Please, could someone explain to me the meaning of the stacktrace
below (which is missing a WARNING or BUG line?), and how disabling
swap discard fixes it?

At present I see no connection (beyond the fact that the patch fixes
the symptom): in the absence of understanding, I have to beware that
the underlying issue may remain unfixed.

Hugh

> 
> 
> 
> > Applied and tested on top of v3.2.17 and v3.3.6, it fixes the issue.
> > 
> > Pid: 0, comm: swapper/0 Not tainted 3.2.17-x86_64 #12
> > Call Trace:
> >  <IRQ>
> >  [<ffffffff810919da>] ? handle_irq_event_percpu+0x3a/0x140
> >  [<ffffffff81091b29>] ? handle_irq_event+0x49/0x80
> >  [<ffffffff81094e7d>] ? handle_edge_irq+0x6d/0x120
> >  [<ffffffff81229088>] ? __xen_evtchn_do_upcall+0x1b8/0x280
> >  [<ffffffff8122a442>] ? xen_evtchn_do_upcall+0x22/0x40
> >  [<ffffffff8133f4fe>] ? xen_do_hypervisor_callback+0x1e/0x30
> >  <EOI>
> >  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >  [<ffffffff8100768c>] ? xen_safe_halt+0xc/0x20
> >  [<ffffffff81013563>] ? default_idle+0x23/0x40
> >  [<ffffffff8100b073>] ? cpu_idle+0x63/0xb0
> >  [<ffffffff81654c43>] ? start_kernel+0x362/0x36d
> >  [<ffffffff81657491>] ? xen_start_kernel+0x558/0x55e
> > Code: 39 ed 0f 84 1c 02 00 00 44 8b 7b 48 4c 8b 73 50 41 83 ef 01 41
> > 21 ef 49 6b c7 70 4d 8b 64 06 40 49 69 c4 d0 00 00 00 48 8d 14 03 <48>
> > 8b 8a 78 02 00 00 48 89 4c 24 10 80 ba 09 02 00 00 00 74 6d
> > RIP  [<ffffffff8125ed66>] blkif_interrupt+0x66/0x320
> >  RSP <ffff88001fc03e18>
> > ---[ end trace dfd4e5623eb06620 ]---

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjC-0004te-HP; Fri, 01 Jun 2012 11:09:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaNuA-0004jj-TN
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:12:23 +0000
Received: from [85.158.138.51:62087] by server-1.bemta-3.messagelabs.com id
	2E/E1-06526-67788CF4; Fri, 01 Jun 2012 09:12:22 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338541939!22204826!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDYwMzg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16984 invoked from network); 1 Jun 2012 09:12:20 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 09:12:20 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 14:42:18 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 14:42:16 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q519CENe54722780
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 14:42:15 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q51Eg0IH003936
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 00:42:02 +1000
Received: from srivatsabhat.in.ibm.com (srivatsabhat.in.ibm.com [9.124.35.113])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q51Eg0cq003838; Sat, 2 Jun 2012 00:42:00 +1000
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: tglx@linutronix.de, peterz@infradead.org, paulmck@linux.vnet.ibm.com
Date: Fri, 01 Jun 2012 14:41:31 +0530
Message-ID: <20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
User-Agent: StGIT/0.14.3
MIME-Version: 1.0
x-cbid: 12060109-4790-0000-0000-000003096A2A
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	x86@kernel.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, vatsa@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, yong.zhang0@gmail.com,
	Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
	srivatsa.bhat@linux.vnet.ibm.com,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xensource.com,
	akpm@linux-foundation.org,
	virtualization@lists.linux-foundation.org, mingo@kernel.org
Subject: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests)
is useful in the cpu bringup path.

Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking
on to the generic SMP booting framework.

Also remove the extra call to preempt_enable() added by commit 41bd956
(xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while
atomic) because it becomes unnecessary after this change.

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
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---

 arch/x86/xen/smp.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 09a7199..602d6b7 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -417,14 +417,6 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
 {
 	play_dead_common();
 	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
-	cpu_bringup();
-	/*
-	 * Balance out the preempt calls - as we are running in cpu_idle
-	 * loop which has been called at bootup from cpu_bringup_and_idle.
-	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
-	 * preempt_disable() So this preempt_enable will balance it out.
-	 */
-	preempt_enable();
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj9-0004r9-1P; Fri, 01 Jun 2012 11:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SZhUt-00042c-RT
	for xen-devel@lists.xensource.com; Wed, 30 May 2012 11:55:28 +0000
Received: from [85.158.143.35:28989] by server-2.bemta-4.messagelabs.com id
	7C/AF-11595-EAA06CF4; Wed, 30 May 2012 11:55:26 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338378924!15675145!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gNDE4MTI1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18484 invoked from network); 30 May 2012 11:55:25 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 May 2012 11:55:25 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q4UBsTsa015326;
	Wed, 30 May 2012 13:54:29 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q4UBsPmw003737;
	Wed, 30 May 2012 13:54:25 +0200
Message-ID: <4FC60A71.5050804@siemens.com>
Date: Wed, 30 May 2012 13:54:25 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com>
	<20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com>
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Andi Kleen <andi@firstfloor.org>, KVM <kvm@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V8 17/17] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-05-02 12:09, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 
> 
> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in paravirtual spinlock
> enabled guest.
> 
> KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled
> in guest.
> 
> Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU

This contains valuable documentation for features that are already
supported. Can you break them out and post as separate patch already?
One comment on them below.

> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
>  Documentation/virtual/kvm/cpuid.txt      |    4 ++
>  Documentation/virtual/kvm/hypercalls.txt |   60 ++++++++++++++++++++++++++++++
>  2 files changed, 64 insertions(+), 0 deletions(-)
> diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
> index 8820685..062dff9 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
>  KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
>                                     ||       || writing to msr 0x4b564d02
>  ------------------------------------------------------------------------------
> +KVM_FEATURE_PV_UNHALT              ||     6 || guest checks this feature bit
> +                                   ||       || before enabling paravirtualized
> +                                   ||       || spinlock support.
> +------------------------------------------------------------------------------
>  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
>                                     ||       || per-cpu warps are expected in
>                                     ||       || kvmclock.
> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
> new file mode 100644
> index 0000000..bc3f14a
> --- /dev/null
> +++ b/Documentation/virtual/kvm/hypercalls.txt
> @@ -0,0 +1,60 @@
> +KVM Hypercalls Documentation
> +===========================
> +The template for each hypercall is:
> +1. Hypercall name, value.
> +2. Architecture(s)
> +3. Status (deprecated, obsolete, active)
> +4. Purpose
> +
> +1. KVM_HC_VAPIC_POLL_IRQ
> +------------------------
> +Value: 1
> +Architecture: x86
> +Purpose: None

Purpose: Trigger guest exit so that the host can check for pending
interrupts on reentry.

> +
> +2. KVM_HC_MMU_OP
> +------------------------
> +Value: 2
> +Architecture: x86
> +Status: deprecated.
> +Purpose: Support MMU operations such as writing to PTE,
> +flushing TLB, release PT.
> +
> +3. KVM_HC_FEATURES
> +------------------------
> +Value: 3
> +Architecture: PPC
> +Status: active
> +Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid
> +used to enumerate which hypercalls are available. On PPC, either device tree
> +based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration
> +mechanism (which is this hypercall) can be used.
> +
> +4. KVM_HC_PPC_MAP_MAGIC_PAGE
> +------------------------
> +Value: 4
> +Architecture: PPC
> +Status: active
> +Purpose: To enable communication between the hypervisor and guest there is a
> +shared page that contains parts of supervisor visible register state.
> +The guest can map this shared page to access its supervisor register through
> +memory using this hypercall.
> +
> +5. KVM_HC_KICK_CPU
> +------------------------
> +Value: 5
> +Architecture: x86
> +Status: active
> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> +
> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> +kernel mode for an event to occur (ex: a spinlock to become available) can
> +execute HLT instruction once it has busy-waited for more than a threshold
> +time-interval. Execution of HLT instruction would cause the hypervisor to put
> +the vcpu to sleep until occurence of an appropriate event. Another vcpu of the
> +same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
> +specifying APIC ID of the vcpu to be wokenup.
> +
> +TODO:
> +1. more information on input and output needed?
> +2. Add more detail to purpose of hypercalls.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjC-0004te-HP; Fri, 01 Jun 2012 11:09:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaNuA-0004jj-TN
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:12:23 +0000
Received: from [85.158.138.51:62087] by server-1.bemta-3.messagelabs.com id
	2E/E1-06526-67788CF4; Fri, 01 Jun 2012 09:12:22 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338541939!22204826!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDYwMzg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16984 invoked from network); 1 Jun 2012 09:12:20 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 09:12:20 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 14:42:18 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 14:42:16 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q519CENe54722780
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 14:42:15 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q51Eg0IH003936
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 00:42:02 +1000
Received: from srivatsabhat.in.ibm.com (srivatsabhat.in.ibm.com [9.124.35.113])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q51Eg0cq003838; Sat, 2 Jun 2012 00:42:00 +1000
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: tglx@linutronix.de, peterz@infradead.org, paulmck@linux.vnet.ibm.com
Date: Fri, 01 Jun 2012 14:41:31 +0530
Message-ID: <20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
User-Agent: StGIT/0.14.3
MIME-Version: 1.0
x-cbid: 12060109-4790-0000-0000-000003096A2A
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	x86@kernel.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, vatsa@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, yong.zhang0@gmail.com,
	Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
	srivatsa.bhat@linux.vnet.ibm.com,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xensource.com,
	akpm@linux-foundation.org,
	virtualization@lists.linux-foundation.org, mingo@kernel.org
Subject: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests)
is useful in the cpu bringup path.

Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking
on to the generic SMP booting framework.

Also remove the extra call to preempt_enable() added by commit 41bd956
(xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while
atomic) because it becomes unnecessary after this change.

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
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---

 arch/x86/xen/smp.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 09a7199..602d6b7 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -417,14 +417,6 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
 {
 	play_dead_common();
 	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
-	cpu_bringup();
-	/*
-	 * Balance out the preempt calls - as we are running in cpu_idle
-	 * loop which has been called at bootup from cpu_bringup_and_idle.
-	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
-	 * preempt_disable() So this preempt_enable will balance it out.
-	 */
-	preempt_enable();
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj9-0004r9-1P; Fri, 01 Jun 2012 11:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SZhUt-00042c-RT
	for xen-devel@lists.xensource.com; Wed, 30 May 2012 11:55:28 +0000
Received: from [85.158.143.35:28989] by server-2.bemta-4.messagelabs.com id
	7C/AF-11595-EAA06CF4; Wed, 30 May 2012 11:55:26 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338378924!15675145!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gNDE4MTI1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18484 invoked from network); 30 May 2012 11:55:25 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 May 2012 11:55:25 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q4UBsTsa015326;
	Wed, 30 May 2012 13:54:29 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q4UBsPmw003737;
	Wed, 30 May 2012 13:54:25 +0200
Message-ID: <4FC60A71.5050804@siemens.com>
Date: Wed, 30 May 2012 13:54:25 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com>
	<20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com>
In-Reply-To: <20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com>
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Andi Kleen <andi@firstfloor.org>, KVM <kvm@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V8 17/17] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-05-02 12:09, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> 
> 
> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in paravirtual spinlock
> enabled guest.
> 
> KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled
> in guest.
> 
> Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU

This contains valuable documentation for features that are already
supported. Can you break them out and post as separate patch already?
One comment on them below.

> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
>  Documentation/virtual/kvm/cpuid.txt      |    4 ++
>  Documentation/virtual/kvm/hypercalls.txt |   60 ++++++++++++++++++++++++++++++
>  2 files changed, 64 insertions(+), 0 deletions(-)
> diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
> index 8820685..062dff9 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
>  KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
>                                     ||       || writing to msr 0x4b564d02
>  ------------------------------------------------------------------------------
> +KVM_FEATURE_PV_UNHALT              ||     6 || guest checks this feature bit
> +                                   ||       || before enabling paravirtualized
> +                                   ||       || spinlock support.
> +------------------------------------------------------------------------------
>  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
>                                     ||       || per-cpu warps are expected in
>                                     ||       || kvmclock.
> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
> new file mode 100644
> index 0000000..bc3f14a
> --- /dev/null
> +++ b/Documentation/virtual/kvm/hypercalls.txt
> @@ -0,0 +1,60 @@
> +KVM Hypercalls Documentation
> +===========================
> +The template for each hypercall is:
> +1. Hypercall name, value.
> +2. Architecture(s)
> +3. Status (deprecated, obsolete, active)
> +4. Purpose
> +
> +1. KVM_HC_VAPIC_POLL_IRQ
> +------------------------
> +Value: 1
> +Architecture: x86
> +Purpose: None

Purpose: Trigger guest exit so that the host can check for pending
interrupts on reentry.

> +
> +2. KVM_HC_MMU_OP
> +------------------------
> +Value: 2
> +Architecture: x86
> +Status: deprecated.
> +Purpose: Support MMU operations such as writing to PTE,
> +flushing TLB, release PT.
> +
> +3. KVM_HC_FEATURES
> +------------------------
> +Value: 3
> +Architecture: PPC
> +Status: active
> +Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid
> +used to enumerate which hypercalls are available. On PPC, either device tree
> +based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration
> +mechanism (which is this hypercall) can be used.
> +
> +4. KVM_HC_PPC_MAP_MAGIC_PAGE
> +------------------------
> +Value: 4
> +Architecture: PPC
> +Status: active
> +Purpose: To enable communication between the hypervisor and guest there is a
> +shared page that contains parts of supervisor visible register state.
> +The guest can map this shared page to access its supervisor register through
> +memory using this hypercall.
> +
> +5. KVM_HC_KICK_CPU
> +------------------------
> +Value: 5
> +Architecture: x86
> +Status: active
> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> +
> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> +kernel mode for an event to occur (ex: a spinlock to become available) can
> +execute HLT instruction once it has busy-waited for more than a threshold
> +time-interval. Execution of HLT instruction would cause the hypervisor to put
> +the vcpu to sleep until occurence of an appropriate event. Another vcpu of the
> +same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
> +specifying APIC ID of the vcpu to be wokenup.
> +
> +TODO:
> +1. more information on input and output needed?
> +2. Add more detail to purpose of hypercalls.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj9-0004ra-Si; Fri, 01 Jun 2012 11:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wS-0f
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:7881] by server-1.bemta-4.messagelabs.com id
	2E/AF-27869-EA487CF4; Thu, 31 May 2012 14:48:14 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3241 invoked from network); 31 May 2012 14:48:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:12 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WA-3o;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006ta-4Y;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 31 May 2012 15:52:30 +0100
Message-ID: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


V4V is a copy based inter vm communication system.

Please have a look at this thread for more detail
about V4V.
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html

This patch series is work in progress but I wanted to
post it early enough so I can get feedback from people.

Jean Guyader (5):
  xen: add ssize_t to types.h
  xen: Add headers to include/Makefile
  v4v: Introduce VIRQ_V4V
  xen: Enforce casting for guest_handle_cast
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/event_channel.c         |    1 +
 xen/common/v4v.c                   | 1779 ++++++++++++++++++++++++++++++++++++
 xen/include/Makefile               |    3 +-
 xen/include/asm-x86/guest_access.h |    2 +-
 xen/include/public/v4v.h           |  544 +++++++++++
 xen/include/public/xen.h           |    4 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/types.h            |    1 +
 xen/include/xen/v4v.h              |  109 +++
 15 files changed, 2467 insertions(+), 8 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

-- 
1.7.2.5


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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj8-0004qi-9C; Fri, 01 Jun 2012 11:09:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hughd@google.com>) id 1SYLka-0005iS-PH
	for xen-devel@lists.xensource.com; Sat, 26 May 2012 18:30:04 +0000
Received: from [85.158.143.35:26008] by server-2.bemta-4.messagelabs.com id
	52/D1-12211-C2121CF4; Sat, 26 May 2012 18:30:04 +0000
X-Env-Sender: hughd@google.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338057000!6998668!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18670 invoked from network); 26 May 2012 18:30:02 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 May 2012 18:30:02 -0000
Received: by pbcwz7 with SMTP id wz7so3319074pbc.30
	for <xen-devel@lists.xensource.com>;
	Sat, 26 May 2012 11:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type;
	bh=d4f2GdIywtmwaBCf8lnl2UqZT2dS2W8TrYCqAWbYosw=;
	b=GDhZkBXaWkllV53FhTplV9yZmpvHUHtMdngJKO9qZuarWViQIdmk0iolH0Ic/7jmtw
	g4rp7XNJtjUMhsMtKY2lJg/lTm4IF6hphQeRzGR0osZ5atJn3EnvLoIaFUiB8fv11QIf
	NsKXpnGc+Uu1GjjGJT1hPmi7OuSulTok3vle077a30aOZnzazXBOUA5g26HFzakP+WmV
	IXJz9oi5bNbJQonEyAsgTdQ8DIuquDOG6NfVmPtw1ZeLPLvjnFiIQqH3dQfRM0kvAgH1
	t7trzx+RIyXrB4guma0lgheb5VWYkI71tqucfdSXtIaeksDv/QKtRZM0NFEX7wrSLloM
	oywQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type:x-gm-message-state;
	bh=d4f2GdIywtmwaBCf8lnl2UqZT2dS2W8TrYCqAWbYosw=;
	b=LBRc27Ycc9MN47qOjXqxeSWOOMM2je36t+rsw3bOc/7XhhhDsgufqWiMkaQNzxrS7t
	dtX1HgKASxM/+AKRPykTpEhmEZ5G6WdTxlWcglvrpYmiJRoFlzOqWpeucqdfl8pxA9SU
	zW9YKhRGj/8TsmkN0LHidbm+EcDnMljI6/7vRkyZtpPm6p7WWof0vxmL1sultcIkG1Ho
	3aFpnnQufl3fYhvJwv8jxU6Zf7Tsh4WwwOVKwXWJbLN8DsQvwiL+NefH3M7PC1x3oLsb
	BpPurlX07bwiLeAXCEZpOxxQP/D8geUTRWmkyVCTM8gD9ASsLJrV6yDCKC7wW777SRM4
	da5A==
Received: by 10.68.226.228 with SMTP id rv4mr10251267pbc.167.1338057000334;
	Sat, 26 May 2012 11:30:00 -0700 (PDT)
Received: by 10.68.226.228 with SMTP id rv4mr10251245pbc.167.1338057000237;
	Sat, 26 May 2012 11:30:00 -0700 (PDT)
Received: from [192.168.1.8] (c-67-188-178-35.hsd1.ca.comcast.net.
	[67.188.178.35])
	by mx.google.com with ESMTPS id vi10sm13270583pbc.4.2012.05.26.11.29.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 26 May 2012 11:29:59 -0700 (PDT)
Date: Sat, 26 May 2012 11:29:37 -0700 (PDT)
From: Hugh Dickins <hughd@google.com>
X-X-Sender: hugh@eggly.anvils
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120521181558.GA7829@phenom.dumpdata.com>
Message-ID: <alpine.LSU.2.00.1205261113470.2033@eggly.anvils>
References: <CAJ75kXbC3gqQAaghKo2i1L650dw9-vrFuEwoy4defagoyR8p4Q@mail.gmail.com>
	<20120521181558.GA7829@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
X-Gm-Message-State: ALoCoQmxgOIp3Cu/natxrDN4De3hIQOtCClsDsMxb3v8UFtzVJbmAh5tcBFzDgsEnxN229k/QWeE1+Y10aStxivDnH2LdRqxUihKyAySEoo+x8PfUJF1e+NtNnXwkU6SneE1jAP/lY2vdTFiscGgJnfu7Yecsk+B8w==
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: xen-devel@lists.xensource.com, Ben Hutchings <ben@decadent.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	shli@fusionio.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, William Dauchy <wdauchy@gmail.com>,
	Shaohua Li <shli@kernel.org>
Subject: Re: [Xen-devel] swap: don't do discard if no discard option added
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 21 May 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, May 21, 2012 at 12:30:45AM +0200, William Dauchy wrote:
> > Hello,
> > 
> > On Xen, when booting a guest with a system disk and an additional swap
> > disk I'm getting a calltrace.
> > xen hypervisor: 4.1.2; linux dom0: v3.3.6; linux guest: v3.2.17
> > When booting without a swap disk, I don't have the issue.
> > I also tested a guest with v3.3.6: same problem. But from v3.4-rc2,
> > the issue is fixed.
> > I cherry-picked:
> 
> > 052b198 swap: don't do discard if no discard option added
> 
> So you are asking for 052b198 to be back-ported.
> 
> I am OK with that but I think Shaohua needs to Ack that and
> ask Greg to put it on stable@kernel.org

Since that commit did indeed go into v3.4, I won't quarrel with it
now going to stable.

But the commit went in to work around the slow discard implementation
on OCZ Vertex II SSDs.

Please, could someone explain to me the meaning of the stacktrace
below (which is missing a WARNING or BUG line?), and how disabling
swap discard fixes it?

At present I see no connection (beyond the fact that the patch fixes
the symptom): in the absence of understanding, I have to beware that
the underlying issue may remain unfixed.

Hugh

> 
> 
> 
> > Applied and tested on top of v3.2.17 and v3.3.6, it fixes the issue.
> > 
> > Pid: 0, comm: swapper/0 Not tainted 3.2.17-x86_64 #12
> > Call Trace:
> >  <IRQ>
> >  [<ffffffff810919da>] ? handle_irq_event_percpu+0x3a/0x140
> >  [<ffffffff81091b29>] ? handle_irq_event+0x49/0x80
> >  [<ffffffff81094e7d>] ? handle_edge_irq+0x6d/0x120
> >  [<ffffffff81229088>] ? __xen_evtchn_do_upcall+0x1b8/0x280
> >  [<ffffffff8122a442>] ? xen_evtchn_do_upcall+0x22/0x40
> >  [<ffffffff8133f4fe>] ? xen_do_hypervisor_callback+0x1e/0x30
> >  <EOI>
> >  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >  [<ffffffff8100768c>] ? xen_safe_halt+0xc/0x20
> >  [<ffffffff81013563>] ? default_idle+0x23/0x40
> >  [<ffffffff8100b073>] ? cpu_idle+0x63/0xb0
> >  [<ffffffff81654c43>] ? start_kernel+0x362/0x36d
> >  [<ffffffff81657491>] ? xen_start_kernel+0x558/0x55e
> > Code: 39 ed 0f 84 1c 02 00 00 44 8b 7b 48 4c 8b 73 50 41 83 ef 01 41
> > 21 ef 49 6b c7 70 4d 8b 64 06 40 49 69 c4 d0 00 00 00 48 8d 14 03 <48>
> > 8b 8a 78 02 00 00 48 89 4c 24 10 80 ba 09 02 00 00 00 74 6d
> > RIP  [<ffffffff8125ed66>] blkif_interrupt+0x66/0x320
> >  RSP <ffff88001fc03e18>
> > ---[ end trace dfd4e5623eb06620 ]---

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj9-0004ra-Si; Fri, 01 Jun 2012 11:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wS-0f
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:7881] by server-1.bemta-4.messagelabs.com id
	2E/AF-27869-EA487CF4; Thu, 31 May 2012 14:48:14 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3241 invoked from network); 31 May 2012 14:48:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:12 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WA-3o;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006ta-4Y;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 31 May 2012 15:52:30 +0100
Message-ID: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


V4V is a copy based inter vm communication system.

Please have a look at this thread for more detail
about V4V.
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html

This patch series is work in progress but I wanted to
post it early enough so I can get feedback from people.

Jean Guyader (5):
  xen: add ssize_t to types.h
  xen: Add headers to include/Makefile
  v4v: Introduce VIRQ_V4V
  xen: Enforce casting for guest_handle_cast
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/event_channel.c         |    1 +
 xen/common/v4v.c                   | 1779 ++++++++++++++++++++++++++++++++++++
 xen/include/Makefile               |    3 +-
 xen/include/asm-x86/guest_access.h |    2 +-
 xen/include/public/v4v.h           |  544 +++++++++++
 xen/include/public/xen.h           |    4 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/types.h            |    1 +
 xen/include/xen/v4v.h              |  109 +++
 15 files changed, 2467 insertions(+), 8 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

-- 
1.7.2.5


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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjB-0004sc-CG; Fri, 01 Jun 2012 11:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6fg-0004wU-3x
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:16 +0000
Received: from [85.158.143.35:10045] by server-3.bemta-4.messagelabs.com id
	45/97-04252-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338475693!15666854!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7059 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WM-TO;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006tl-ST;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:34 +0100
Message-ID: <1338475955-26472-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen: Enforce casting for guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


This is useful if you want to cast a guest handle to char * to do
pointer aritmetics afterwards with functions like guest_handle_add_offset.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/asm-x86/guest_access.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0004-xen-Enforce-casting-for-guest_handle_cast.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0004-xen-Enforce-casting-for-guest_handle_cast.patch"

diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index 2b429c2..7e95da3 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -47,7 +47,7 @@
 
 /* Cast a guest handle to the specified type of handle. */
 #define guest_handle_cast(hnd, type) ({         \
-    type *_x = (hnd).p;                         \
+    type *_x = (type *)(hnd).p;                 \
     (XEN_GUEST_HANDLE(type)) { _x };            \
 })
 

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjB-0004sK-10; Fri, 01 Jun 2012 11:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wT-Py
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:9969] by server-2.bemta-4.messagelabs.com id
	78/DE-11595-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3384 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WJ-N7;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006ti-Lb;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:33 +0100
Message-ID: <1338475955-26472-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Introduce the global virq VIRQ_V4V

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/public/xen.h   |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch; name="0003-v4v-Introduce-VIRQ_V4V.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0003-v4v-Introduce-VIRQ_V4V.patch"

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..e138600 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -107,6 +107,7 @@ static int virq_is_global(uint32_t virq)
     case VIRQ_TIMER:
     case VIRQ_DEBUG:
     case VIRQ_XENOPROF:
+    case VIRQ_V4V:
         rc = 0;
         break;
     case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..033cbba 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,7 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_CON_RING   8  /* G. (DOM0) Bytes received on console            */
 #define VIRQ_PCPU_STATE 9  /* G. (DOM0) PCPU state changed                   */
 #define VIRQ_MEM_EVENT  10 /* G. (DOM0) A memory event has occured           */
-#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient                     */
+#define VIRQ_V4V        11 /* G. V4V event has occurred                      */
 #define VIRQ_ENOMEM     12 /* G. (DOM0) Low on heap memory       */
 
 /* Architecture-specific VIRQ definitions. */

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjC-0004tD-5a; Fri, 01 Jun 2012 11:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hughd@google.com>) id 1SaEQN-0006SJ-NG
	for xen-devel@lists.xensource.com; Thu, 31 May 2012 23:04:59 +0000
Received: from [85.158.143.35:9631] by server-3.bemta-4.messagelabs.com id
	35/8C-04252-B19F7CF4; Thu, 31 May 2012 23:04:59 +0000
X-Env-Sender: hughd@google.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338505496!13014116!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18936 invoked from network); 31 May 2012 23:04:58 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 23:04:58 -0000
Received: by dajz8 with SMTP id z8so2207287daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 31 May 2012 16:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type;
	bh=6kvYc1Rbiwh9Cz7s/4z9IiTZlhwIDmHvTXAoY4IrWDE=;
	b=HujGO8lbIp1n84+TCvWMtklk6deYdNKBFvyhz6EGcTwpBQ9kDrpNwiluoc8EinYeLW
	9irsueTwJTAs1WMT3FYTmk5NhWl0OugeS7P8T/6d8RrNNeUkhYGUMmIBaKyX0LnXwU9V
	EVkHEhLycSJ1wDUmW1cD1BVRW7/sk5DBiVT7YhE0CtfCjbJPkV0aS6L/DTk+tU0BQYtm
	FxWPXZKvEC6/Zuz7zUPtr8bghraMDMKtm+DVZczWwUCsWLMPn0JIirtb4hw9SOxTRjCK
	hUW1/1b7L6oK/mTT1QJHtSGP6s56rjByuLf3PLcxbDxlZYfPIfAIpe8dhPHtU+waboNI
	cCdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type:x-gm-message-state;
	bh=6kvYc1Rbiwh9Cz7s/4z9IiTZlhwIDmHvTXAoY4IrWDE=;
	b=i/FLLepP8qjH0FPdHMwORHO00kAR2rfKTgIX/qDsCY7XBqMcUxIBp0OrUBoAbHYNgY
	QZMLfkGvc+Jt2sEj3SQXdIZcmvBLcZt6h+953XDOoJNDopS8lvYAX0K8WRALtY8sIFro
	WsnrhdLSvWOjMUDADcpCqMrFW5B4ZfiGSkpdTS7waqVh9TtmKwCiFp7dwYoJ4u7DJzfU
	7tW0lO7Rs0cscItBjOPGxg7mNwL3dWWqTLB2H85dWzCSP+yjn3aP7wC9O7FtQanWRgb2
	pik1UJpnZKbtOZxYMZCeNMh02Yt29qsyxE9mT1VHkEpzpjvIcHWIYiUDYe6DBweJvKUU
	9Lhw==
Received: by 10.68.191.201 with SMTP id ha9mr1182413pbc.75.1338505496055;
	Thu, 31 May 2012 16:04:56 -0700 (PDT)
Received: by 10.68.191.201 with SMTP id ha9mr1182380pbc.75.1338505495773;
	Thu, 31 May 2012 16:04:55 -0700 (PDT)
Received: from [2620:0:1000:fd2e:224:d7ff:fee2:b75c]
	([2620:0:1000:fd2e:224:d7ff:fee2:b75c])
	by mx.google.com with ESMTPS id ir6sm534358pbc.35.2012.05.31.16.04.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 31 May 2012 16:04:54 -0700 (PDT)
Date: Thu, 31 May 2012 16:04:35 -0700 (PDT)
From: Hugh Dickins <hughd@google.com>
X-X-Sender: hugh@eggly.anvils
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120529144743.GG3558@phenom.dumpdata.com>
Message-ID: <alpine.LSU.2.00.1205311601480.4561@eggly.anvils>
References: <CAJ75kXbC3gqQAaghKo2i1L650dw9-vrFuEwoy4defagoyR8p4Q@mail.gmail.com>
	<20120521181558.GA7829@phenom.dumpdata.com>
	<alpine.LSU.2.00.1205261113470.2033@eggly.anvils>
	<20120529144743.GG3558@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
X-Gm-Message-State: ALoCoQnuluPPJpkDdhIQ6aK2wqw+5u9wucVIFs8INOTfHmWF9L46pFyNmVrwW6zA98IEwjBlYRPOecrHSy3RiRUxKp1222HdqIW6vJcvB1hn7KzJO5S9I46kBl8FBN9CaseUI4tTc2R2gWK9lWYm7JHXnvLcrNX6Dg==
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: xen-devel@lists.xensource.com, Ben Hutchings <ben@decadent.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	shli@fusionio.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, William Dauchy <wdauchy@gmail.com>,
	Shaohua Li <shli@kernel.org>
Subject: Re: [Xen-devel] swap: don't do discard if no discard option added
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 May 2012, Konrad Rzeszutek Wilk wrote:
> 
> I think I know and just narrowed down the issue this Friday.
> 
> William, could you please apply the patch outlined in
> https://bugzilla.redhat.com/show_bug.cgi?id=824641
> to your dom0 and see if that (so do not have 052b198 in your branch)
> 
> > 
> > At present I see no connection (beyond the fact that the patch fixes
> > the symptom): in the absence of understanding, I have to beware that
> > the underlying issue may remain unfixed.
> 
> <nods>

Thanks a lot for pursuing that to a much more satisfying conclusion.

Hugh

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjB-0004sc-CG; Fri, 01 Jun 2012 11:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6fg-0004wU-3x
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:16 +0000
Received: from [85.158.143.35:10045] by server-3.bemta-4.messagelabs.com id
	45/97-04252-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338475693!15666854!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7059 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WM-TO;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006tl-ST;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:34 +0100
Message-ID: <1338475955-26472-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen: Enforce casting for guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


This is useful if you want to cast a guest handle to char * to do
pointer aritmetics afterwards with functions like guest_handle_add_offset.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/asm-x86/guest_access.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0004-xen-Enforce-casting-for-guest_handle_cast.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0004-xen-Enforce-casting-for-guest_handle_cast.patch"

diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index 2b429c2..7e95da3 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -47,7 +47,7 @@
 
 /* Cast a guest handle to the specified type of handle. */
 #define guest_handle_cast(hnd, type) ({         \
-    type *_x = (hnd).p;                         \
+    type *_x = (type *)(hnd).p;                 \
     (XEN_GUEST_HANDLE(type)) { _x };            \
 })
 

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjC-0004tD-5a; Fri, 01 Jun 2012 11:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hughd@google.com>) id 1SaEQN-0006SJ-NG
	for xen-devel@lists.xensource.com; Thu, 31 May 2012 23:04:59 +0000
Received: from [85.158.143.35:9631] by server-3.bemta-4.messagelabs.com id
	35/8C-04252-B19F7CF4; Thu, 31 May 2012 23:04:59 +0000
X-Env-Sender: hughd@google.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338505496!13014116!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18936 invoked from network); 31 May 2012 23:04:58 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 23:04:58 -0000
Received: by dajz8 with SMTP id z8so2207287daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 31 May 2012 16:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type;
	bh=6kvYc1Rbiwh9Cz7s/4z9IiTZlhwIDmHvTXAoY4IrWDE=;
	b=HujGO8lbIp1n84+TCvWMtklk6deYdNKBFvyhz6EGcTwpBQ9kDrpNwiluoc8EinYeLW
	9irsueTwJTAs1WMT3FYTmk5NhWl0OugeS7P8T/6d8RrNNeUkhYGUMmIBaKyX0LnXwU9V
	EVkHEhLycSJ1wDUmW1cD1BVRW7/sk5DBiVT7YhE0CtfCjbJPkV0aS6L/DTk+tU0BQYtm
	FxWPXZKvEC6/Zuz7zUPtr8bghraMDMKtm+DVZczWwUCsWLMPn0JIirtb4hw9SOxTRjCK
	hUW1/1b7L6oK/mTT1QJHtSGP6s56rjByuLf3PLcxbDxlZYfPIfAIpe8dhPHtU+waboNI
	cCdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id
	:references:user-agent:mime-version:content-type:x-gm-message-state;
	bh=6kvYc1Rbiwh9Cz7s/4z9IiTZlhwIDmHvTXAoY4IrWDE=;
	b=i/FLLepP8qjH0FPdHMwORHO00kAR2rfKTgIX/qDsCY7XBqMcUxIBp0OrUBoAbHYNgY
	QZMLfkGvc+Jt2sEj3SQXdIZcmvBLcZt6h+953XDOoJNDopS8lvYAX0K8WRALtY8sIFro
	WsnrhdLSvWOjMUDADcpCqMrFW5B4ZfiGSkpdTS7waqVh9TtmKwCiFp7dwYoJ4u7DJzfU
	7tW0lO7Rs0cscItBjOPGxg7mNwL3dWWqTLB2H85dWzCSP+yjn3aP7wC9O7FtQanWRgb2
	pik1UJpnZKbtOZxYMZCeNMh02Yt29qsyxE9mT1VHkEpzpjvIcHWIYiUDYe6DBweJvKUU
	9Lhw==
Received: by 10.68.191.201 with SMTP id ha9mr1182413pbc.75.1338505496055;
	Thu, 31 May 2012 16:04:56 -0700 (PDT)
Received: by 10.68.191.201 with SMTP id ha9mr1182380pbc.75.1338505495773;
	Thu, 31 May 2012 16:04:55 -0700 (PDT)
Received: from [2620:0:1000:fd2e:224:d7ff:fee2:b75c]
	([2620:0:1000:fd2e:224:d7ff:fee2:b75c])
	by mx.google.com with ESMTPS id ir6sm534358pbc.35.2012.05.31.16.04.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 31 May 2012 16:04:54 -0700 (PDT)
Date: Thu, 31 May 2012 16:04:35 -0700 (PDT)
From: Hugh Dickins <hughd@google.com>
X-X-Sender: hugh@eggly.anvils
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120529144743.GG3558@phenom.dumpdata.com>
Message-ID: <alpine.LSU.2.00.1205311601480.4561@eggly.anvils>
References: <CAJ75kXbC3gqQAaghKo2i1L650dw9-vrFuEwoy4defagoyR8p4Q@mail.gmail.com>
	<20120521181558.GA7829@phenom.dumpdata.com>
	<alpine.LSU.2.00.1205261113470.2033@eggly.anvils>
	<20120529144743.GG3558@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
X-Gm-Message-State: ALoCoQnuluPPJpkDdhIQ6aK2wqw+5u9wucVIFs8INOTfHmWF9L46pFyNmVrwW6zA98IEwjBlYRPOecrHSy3RiRUxKp1222HdqIW6vJcvB1hn7KzJO5S9I46kBl8FBN9CaseUI4tTc2R2gWK9lWYm7JHXnvLcrNX6Dg==
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: xen-devel@lists.xensource.com, Ben Hutchings <ben@decadent.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	shli@fusionio.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, William Dauchy <wdauchy@gmail.com>,
	Shaohua Li <shli@kernel.org>
Subject: Re: [Xen-devel] swap: don't do discard if no discard option added
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 May 2012, Konrad Rzeszutek Wilk wrote:
> 
> I think I know and just narrowed down the issue this Friday.
> 
> William, could you please apply the patch outlined in
> https://bugzilla.redhat.com/show_bug.cgi?id=824641
> to your dom0 and see if that (so do not have 052b198 in your branch)
> 
> > 
> > At present I see no connection (beyond the fact that the patch fixes
> > the symptom): in the absence of understanding, I have to beware that
> > the underlying issue may remain unfixed.
> 
> <nods>

Thanks a lot for pursuing that to a much more satisfying conclusion.

Hugh

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjB-0004sK-10; Fri, 01 Jun 2012 11:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wT-Py
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:9969] by server-2.bemta-4.messagelabs.com id
	78/DE-11595-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3384 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WJ-N7;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006ti-Lb;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:33 +0100
Message-ID: <1338475955-26472-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Introduce the global virq VIRQ_V4V

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/public/xen.h   |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch; name="0003-v4v-Introduce-VIRQ_V4V.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0003-v4v-Introduce-VIRQ_V4V.patch"

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..e138600 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -107,6 +107,7 @@ static int virq_is_global(uint32_t virq)
     case VIRQ_TIMER:
     case VIRQ_DEBUG:
     case VIRQ_XENOPROF:
+    case VIRQ_V4V:
         rc = 0;
         break;
     case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..033cbba 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,7 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_CON_RING   8  /* G. (DOM0) Bytes received on console            */
 #define VIRQ_PCPU_STATE 9  /* G. (DOM0) PCPU state changed                   */
 #define VIRQ_MEM_EVENT  10 /* G. (DOM0) A memory event has occured           */
-#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient                     */
+#define VIRQ_V4V        11 /* G. V4V event has occurred                      */
 #define VIRQ_ENOMEM     12 /* G. (DOM0) Low on heap memory       */
 
 /* Architecture-specific VIRQ definitions. */

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjA-0004rm-9Z; Fri, 01 Jun 2012 11:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wT-DC
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:7931] by server-2.bemta-4.messagelabs.com id
	24/DE-11595-EA487CF4; Thu, 31 May 2012 14:48:14 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3335 invoked from network); 31 May 2012 14:48:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:12 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WD-AK;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006tc-95;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:31 +0100
Message-ID: <1338475955-26472-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] xen: add ssize_t to types.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

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/xen/types.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch; name="0001-xen-add-ssize_t-to-types.h.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-xen-add-ssize_t-to-types.h.patch"

diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index 8596ded..ec992f8 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -58,5 +58,6 @@ typedef __u64 __le64;
 typedef __u64 __be64;
 
 typedef unsigned long uintptr_t;
+typedef int ssize_t;
 
 #endif /* __TYPES_H__ */

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjA-0004rm-9Z; Fri, 01 Jun 2012 11:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wT-DC
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:7931] by server-2.bemta-4.messagelabs.com id
	24/DE-11595-EA487CF4; Thu, 31 May 2012 14:48:14 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3335 invoked from network); 31 May 2012 14:48:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:12 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WD-AK;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006tc-95;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:31 +0100
Message-ID: <1338475955-26472-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] xen: add ssize_t to types.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

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/xen/types.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch; name="0001-xen-add-ssize_t-to-types.h.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-xen-add-ssize_t-to-types.h.patch"

diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index 8596ded..ec992f8 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -58,5 +58,6 @@ typedef __u64 __le64;
 typedef __u64 __be64;
 
 typedef unsigned long uintptr_t;
+typedef int ssize_t;
 
 #endif /* __TYPES_H__ */

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj9-0004rK-GF; Fri, 01 Jun 2012 11:09:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SZjDr-0000Ef-Gx
	for xen-devel@lists.xensource.com; Wed, 30 May 2012 13:45:59 +0000
Received: from [193.109.254.147:36384] by server-9.bemta-14.messagelabs.com id
	AE/8E-28098-69426CF4; Wed, 30 May 2012 13:45:58 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338385555!6857247!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA4MTA0MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15388 invoked from network); 30 May 2012 13:45:57 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 May 2012 13:45:57 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 May 2012 19:15:55 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 May 2012 19:15:51 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q4UDjoI22359736
	for <xen-devel@lists.xensource.com>; Wed, 30 May 2012 19:15:50 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q4UJFPeH032730
	for <xen-devel@lists.xensource.com>; Thu, 31 May 2012 00:45:27 +0530
Received: from [9.124.158.205] (codeblue.in.ibm.com [9.124.158.205])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q4UJFPn6032714; Thu, 31 May 2012 00:45:25 +0530
Message-ID: <4FC62458.7030802@linux.vnet.ibm.com>
Date: Wed, 30 May 2012 19:14:56 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com>
	<20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com>
	<4FC60A71.5050804@siemens.com>
In-Reply-To: <4FC60A71.5050804@siemens.com>
x-cbid: 12053013-8878-0000-0000-000002B81D9D
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Andi Kleen <andi@firstfloor.org>, KVM <kvm@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V8 17/17] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/30/2012 05:24 PM, Jan Kiszka wrote:
> On 2012-05-02 12:09, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>
>> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in paravirtual spinlock
>> enabled guest.
>>
>> KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled
>> in guest.
>>
>> Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU
>
> This contains valuable documentation for features that are already
> supported. Can you break them out and post as separate patch already?
> One comment on them below.
>

That sounds like a good idea. Sure, will do that.

>>
>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> ---
>>   Documentation/virtual/kvm/cpuid.txt      |    4 ++
>>   Documentation/virtual/kvm/hypercalls.txt |   60 ++++++++++++++++++++++++++++++
>>   2 files changed, 64 insertions(+), 0 deletions(-)
>> diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
>> index 8820685..062dff9 100644
>> --- a/Documentation/virtual/kvm/cpuid.txt
>> +++ b/Documentation/virtual/kvm/cpuid.txt
>> @@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
>>   KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
>>                                      ||       || writing to msr 0x4b564d02
>>   ------------------------------------------------------------------------------
>> +KVM_FEATURE_PV_UNHALT              ||     6 || guest checks this feature bit
>> +                                   ||       || before enabling paravirtualized
>> +                                   ||       || spinlock support.
>> +------------------------------------------------------------------------------
>>   KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
>>                                      ||       || per-cpu warps are expected in
>>                                      ||       || kvmclock.
>> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
>> new file mode 100644
>> index 0000000..bc3f14a
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>> @@ -0,0 +1,60 @@
>> +KVM Hypercalls Documentation
>> +===========================
>> +The template for each hypercall is:
>> +1. Hypercall name, value.
>> +2. Architecture(s)
>> +3. Status (deprecated, obsolete, active)
>> +4. Purpose
>> +
>> +1. KVM_HC_VAPIC_POLL_IRQ
>> +------------------------
>> +Value: 1
>> +Architecture: x86
>> +Purpose: None
>
> Purpose: Trigger guest exit so that the host can check for pending
> interrupts on reentry.

will add fold this and resend.

[...]


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjD-0004uL-8H; Fri, 01 Jun 2012 11:09:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaOQA-0007X9-Cj
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:45:26 +0000
Received: from [85.158.138.51:55970] by server-11.bemta-3.messagelabs.com id
	0E/C9-32748-53F88CF4; Fri, 01 Jun 2012 09:45:25 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338543861!21412931!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxNjQ0MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26323 invoked from network); 1 Jun 2012 09:45:11 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 09:45:11 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 08:51:48 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 08:51:38 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q519BYGa9241070
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 19:11:36 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q519BWu4003283
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 19:11:34 +1000
Received: from srivatsabhat.in.ibm.com (srivatsabhat.in.ibm.com [9.124.35.113])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q519BPe7003154; Fri, 1 Jun 2012 19:11:25 +1000
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: tglx@linutronix.de, peterz@infradead.org, paulmck@linux.vnet.ibm.com
Date: Fri, 01 Jun 2012 14:40:44 +0530
Message-ID: <20120601091038.31979.67878.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
User-Agent: StGIT/0.14.3
MIME-Version: 1.0
x-cbid: 12053122-9264-0000-0000-000001A0298E
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Venkatesh Pallipadi <venki@google.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	mingo@kernel.org, linux-arch@vger.kernel.org,
	xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	linux-sh@vger.kernel.org, x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Mike Frysinger <vapier@gentoo.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, Chris Metcalf <cmetcalf@tilera.com>,
	rjw@sisk.pl, Yong Zhang <yong.zhang0@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	virtualization@lists.linux-foundation.org,
	Tony Luck <tony.luck@intel.com>, vatsa@linux.vnet.ibm.com,
	Ralf Baechle <ralf@linux-mips.org>, Paul Mundt <lethal@linux-sh.org>,
	srivatsa.bhat@linux.vnet.ibm.com,
	Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org
Subject: [Xen-devel] [PATCH 03/27] smpboot: Define and use cpu_state per-cpu
 variable in generic 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

The per-cpu variable cpu_state is used in x86 and also used in other
architectures, to track the state of the cpu during bringup and hotplug.
Pull it out into generic code.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Yong Zhang <yong.zhang0@gmail.com>
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---

 arch/ia64/include/asm/cpu.h   |    2 --
 arch/ia64/kernel/process.c    |    1 +
 arch/ia64/kernel/smpboot.c    |    6 +-----
 arch/mips/cavium-octeon/smp.c |    4 +---
 arch/powerpc/kernel/smp.c     |    6 +-----
 arch/sh/include/asm/smp.h     |    2 --
 arch/sh/kernel/smp.c          |    4 +---
 arch/tile/kernel/smpboot.c    |    4 +---
 arch/x86/include/asm/cpu.h    |    2 --
 arch/x86/kernel/smpboot.c     |    4 +---
 arch/x86/xen/smp.c            |    1 +
 include/linux/smpboot.h       |    1 +
 kernel/smpboot.c              |    4 ++++
 13 files changed, 13 insertions(+), 28 deletions(-)

diff --git a/arch/ia64/include/asm/cpu.h b/arch/ia64/include/asm/cpu.h
index fcca30b..1c3acac 100644
--- a/arch/ia64/include/asm/cpu.h
+++ b/arch/ia64/include/asm/cpu.h
@@ -12,8 +12,6 @@ struct ia64_cpu {
 
 DECLARE_PER_CPU(struct ia64_cpu, cpu_devices);
 
-DECLARE_PER_CPU(int, cpu_state);
-
 #ifdef CONFIG_HOTPLUG_CPU
 extern int arch_register_cpu(int num);
 extern void arch_unregister_cpu(int);
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 5e0e86d..32566c7 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -29,6 +29,7 @@
 #include <linux/kdebug.h>
 #include <linux/utsname.h>
 #include <linux/tracehook.h>
+#include <linux/smpboot.h>
 
 #include <asm/cpu.h>
 #include <asm/delay.h>
diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
index 963d2db..df00a3c 100644
--- a/arch/ia64/kernel/smpboot.c
+++ b/arch/ia64/kernel/smpboot.c
@@ -39,6 +39,7 @@
 #include <linux/efi.h>
 #include <linux/percpu.h>
 #include <linux/bitops.h>
+#include <linux/smpboot.h>
 
 #include <linux/atomic.h>
 #include <asm/cache.h>
@@ -111,11 +112,6 @@ extern unsigned long ia64_iobase;
 
 struct task_struct *task_for_booting_cpu;
 
-/*
- * State for each CPU
- */
-DEFINE_PER_CPU(int, cpu_state);
-
 cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
 EXPORT_SYMBOL(cpu_core_map);
 DEFINE_PER_CPU_SHARED_ALIGNED(cpumask_t, cpu_sibling_map);
diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index 97e7ce9..93cd4b0 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -13,6 +13,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/sched.h>
 #include <linux/module.h>
+#include <linux/smpboot.h>
 
 #include <asm/mmu_context.h>
 #include <asm/time.h>
@@ -252,9 +253,6 @@ static void octeon_cpus_done(void)
 
 #ifdef CONFIG_HOTPLUG_CPU
 
-/* State of each CPU. */
-DEFINE_PER_CPU(int, cpu_state);
-
 extern void fixup_irqs(void);
 
 static DEFINE_SPINLOCK(smp_reserve_lock);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index e1417c4..1928058a 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -31,6 +31,7 @@
 #include <linux/cpu.h>
 #include <linux/notifier.h>
 #include <linux/topology.h>
+#include <linux/smpboot.h>
 
 #include <asm/ptrace.h>
 #include <linux/atomic.h>
@@ -57,11 +58,6 @@
 #define DBG(fmt...)
 #endif
 
-#ifdef CONFIG_HOTPLUG_CPU
-/* State of each CPU during hotplug phases */
-static DEFINE_PER_CPU(int, cpu_state) = { 0 };
-#endif
-
 struct thread_info *secondary_ti;
 
 DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
diff --git a/arch/sh/include/asm/smp.h b/arch/sh/include/asm/smp.h
index 78b0d0f4..bda041e 100644
--- a/arch/sh/include/asm/smp.h
+++ b/arch/sh/include/asm/smp.h
@@ -31,8 +31,6 @@ enum {
 	SMP_MSG_NR,	/* must be last */
 };
 
-DECLARE_PER_CPU(int, cpu_state);
-
 void smp_message_recv(unsigned int msg);
 void smp_timer_broadcast(const struct cpumask *mask);
 
diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c
index b86e9ca..8e0fde0 100644
--- a/arch/sh/kernel/smp.c
+++ b/arch/sh/kernel/smp.c
@@ -22,6 +22,7 @@
 #include <linux/interrupt.h>
 #include <linux/sched.h>
 #include <linux/atomic.h>
+#include <linux/smpboot.h>
 #include <asm/processor.h>
 #include <asm/mmu_context.h>
 #include <asm/smp.h>
@@ -34,9 +35,6 @@ int __cpu_logical_map[NR_CPUS];		/* Map logical to physical */
 
 struct plat_smp_ops *mp_ops = NULL;
 
-/* State of each CPU */
-DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
 void __cpuinit register_smp_ops(struct plat_smp_ops *ops)
 {
 	if (mp_ops)
diff --git a/arch/tile/kernel/smpboot.c b/arch/tile/kernel/smpboot.c
index e686c5a..24a9c06 100644
--- a/arch/tile/kernel/smpboot.c
+++ b/arch/tile/kernel/smpboot.c
@@ -25,13 +25,11 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/irq.h>
+#include <linux/smpboot.h>
 #include <asm/mmu_context.h>
 #include <asm/tlbflush.h>
 #include <asm/sections.h>
 
-/* State of each CPU. */
-static DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
 /* The messaging code jumps to this pointer during boot-up */
 unsigned long start_cpu_function_addr;
 
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 4564c8e..2d0b239 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -30,8 +30,6 @@ extern int arch_register_cpu(int num);
 extern void arch_unregister_cpu(int);
 #endif
 
-DECLARE_PER_CPU(int, cpu_state);
-
 int mwait_usable(const struct cpuinfo_x86 *);
 
 #endif /* _ASM_X86_CPU_H */
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index bfbe30e..269bc1f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -51,6 +51,7 @@
 #include <linux/stackprotector.h>
 #include <linux/gfp.h>
 #include <linux/cpuidle.h>
+#include <linux/smpboot.h>
 
 #include <asm/acpi.h>
 #include <asm/desc.h>
@@ -73,9 +74,6 @@
 #include <asm/smpboot_hooks.h>
 #include <asm/i8259.h>
 
-/* State of each CPU */
-DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
 #ifdef CONFIG_HOTPLUG_CPU
 /*
  * We need this for trampoline_base protection from concurrent accesses when
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2ef5948..09a7199 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
+#include <linux/smpboot.h>
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index 63bbedd..834d90c 100644
--- a/include/linux/smpboot.h
+++ b/include/linux/smpboot.h
@@ -5,6 +5,7 @@
 #ifndef SMPBOOT_H
 #define SMPBOOT_H
 
+DECLARE_PER_CPU(int, cpu_state);
 extern void smpboot_start_secondary(void *arg);
 
 #endif
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 5ae1805..0df43b0 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -67,6 +67,8 @@ void __init idle_threads_init(void)
 }
 #endif
 
+/* State of each CPU during bringup/teardown */
+DEFINE_PER_CPU(int, cpu_state) = { 0 };
 
 /* Implement the following functions in your architecture, as appropriate. */
 
@@ -141,6 +143,8 @@ void __cpuinit smpboot_start_secondary(void *arg)
 	set_cpu_online(cpu, true);
 	arch_vector_unlock();
 
+	per_cpu(cpu_state, cpu) = CPU_ONLINE;
+
 	__cpu_post_online(arg);
 
 	/* Enable local interrupts now */


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjC-0004tu-St; Fri, 01 Jun 2012 11:09:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaNuM-0004kA-TC
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:12:35 +0000
Received: from [85.158.139.83:14710] by server-8.bemta-5.messagelabs.com id
	A4/33-25689-28788CF4; Fri, 01 Jun 2012 09:12:34 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338541950!30982923!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxNTM4ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10936 invoked from network); 1 Jun 2012 09:12:32 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 09:12:32 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 14:42:29 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 14:42:27 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q519CQOj2752962
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 14:42:26 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q51EgCeA005034
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 00:42:13 +1000
Received: from srivatsabhat.in.ibm.com (srivatsabhat.in.ibm.com [9.124.35.113])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q51EgClR005031; Sat, 2 Jun 2012 00:42:12 +1000
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: tglx@linutronix.de, peterz@infradead.org, paulmck@linux.vnet.ibm.com
Date: Fri, 01 Jun 2012 14:41:43 +0530
Message-ID: <20120601091136.31979.36213.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
User-Agent: StGIT/0.14.3
MIME-Version: 1.0
x-cbid: 12060109-5564-0000-0000-00000307D246
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	x86@kernel.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, vatsa@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, yong.zhang0@gmail.com,
	Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
	srivatsa.bhat@linux.vnet.ibm.com,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xensource.com,
	akpm@linux-foundation.org,
	virtualization@lists.linux-foundation.org, mingo@kernel.org
Subject: [Xen-devel] [PATCH 06/27] xen,
	smpboot: Use generic SMP booting infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert xen to use the generic framework to boot secondary CPUs.

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: linux-kernel@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---

 arch/x86/xen/smp.c |   21 ++++-----------------
 1 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 602d6b7..46c96f9 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -58,13 +58,12 @@ static irqreturn_t xen_reschedule_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static void __cpuinit cpu_bringup(void)
+void __cpuinit xen_cpu_pre_starting(void *unused)
 {
 	int cpu;
 
 	cpu_init();
 	touch_softlockup_watchdog();
-	preempt_disable();
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
@@ -75,25 +74,11 @@ static void __cpuinit cpu_bringup(void)
 	set_cpu_sibling_map(cpu);
 
 	xen_setup_cpu_clockevents();
-
-	notify_cpu_starting(cpu);
-
-	set_cpu_online(cpu, true);
-
-	this_cpu_write(cpu_state, CPU_ONLINE);
-
-	wmb();
-
-	/* We can take interrupts now: we're officially "up". */
-	local_irq_enable();
-
-	wmb();			/* make sure everything is out */
 }
 
 static void __cpuinit cpu_bringup_and_idle(void)
 {
-	cpu_bringup();
-	cpu_idle();
+	smpboot_start_secondary(NULL);
 }
 
 static int xen_smp_intr_init(unsigned int cpu)
@@ -515,6 +500,8 @@ static const struct smp_ops xen_smp_ops __initconst = {
 	.smp_prepare_cpus = xen_smp_prepare_cpus,
 	.smp_cpus_done = xen_smp_cpus_done,
 
+	.cpu_pre_starting = xen_cpu_pre_starting,
+
 	.cpu_up = xen_cpu_up,
 	.cpu_die = xen_cpu_die,
 	.cpu_disable = xen_cpu_disable,


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjD-0004uL-8H; Fri, 01 Jun 2012 11:09:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaOQA-0007X9-Cj
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:45:26 +0000
Received: from [85.158.138.51:55970] by server-11.bemta-3.messagelabs.com id
	0E/C9-32748-53F88CF4; Fri, 01 Jun 2012 09:45:25 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338543861!21412931!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxNjQ0MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26323 invoked from network); 1 Jun 2012 09:45:11 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 09:45:11 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 08:51:48 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 08:51:38 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q519BYGa9241070
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 19:11:36 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q519BWu4003283
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 19:11:34 +1000
Received: from srivatsabhat.in.ibm.com (srivatsabhat.in.ibm.com [9.124.35.113])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q519BPe7003154; Fri, 1 Jun 2012 19:11:25 +1000
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: tglx@linutronix.de, peterz@infradead.org, paulmck@linux.vnet.ibm.com
Date: Fri, 01 Jun 2012 14:40:44 +0530
Message-ID: <20120601091038.31979.67878.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
User-Agent: StGIT/0.14.3
MIME-Version: 1.0
x-cbid: 12053122-9264-0000-0000-000001A0298E
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Venkatesh Pallipadi <venki@google.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	mingo@kernel.org, linux-arch@vger.kernel.org,
	xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	linux-sh@vger.kernel.org, x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Mike Frysinger <vapier@gentoo.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, Chris Metcalf <cmetcalf@tilera.com>,
	rjw@sisk.pl, Yong Zhang <yong.zhang0@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	virtualization@lists.linux-foundation.org,
	Tony Luck <tony.luck@intel.com>, vatsa@linux.vnet.ibm.com,
	Ralf Baechle <ralf@linux-mips.org>, Paul Mundt <lethal@linux-sh.org>,
	srivatsa.bhat@linux.vnet.ibm.com,
	Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org
Subject: [Xen-devel] [PATCH 03/27] smpboot: Define and use cpu_state per-cpu
 variable in generic 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

The per-cpu variable cpu_state is used in x86 and also used in other
architectures, to track the state of the cpu during bringup and hotplug.
Pull it out into generic code.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Yong Zhang <yong.zhang0@gmail.com>
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---

 arch/ia64/include/asm/cpu.h   |    2 --
 arch/ia64/kernel/process.c    |    1 +
 arch/ia64/kernel/smpboot.c    |    6 +-----
 arch/mips/cavium-octeon/smp.c |    4 +---
 arch/powerpc/kernel/smp.c     |    6 +-----
 arch/sh/include/asm/smp.h     |    2 --
 arch/sh/kernel/smp.c          |    4 +---
 arch/tile/kernel/smpboot.c    |    4 +---
 arch/x86/include/asm/cpu.h    |    2 --
 arch/x86/kernel/smpboot.c     |    4 +---
 arch/x86/xen/smp.c            |    1 +
 include/linux/smpboot.h       |    1 +
 kernel/smpboot.c              |    4 ++++
 13 files changed, 13 insertions(+), 28 deletions(-)

diff --git a/arch/ia64/include/asm/cpu.h b/arch/ia64/include/asm/cpu.h
index fcca30b..1c3acac 100644
--- a/arch/ia64/include/asm/cpu.h
+++ b/arch/ia64/include/asm/cpu.h
@@ -12,8 +12,6 @@ struct ia64_cpu {
 
 DECLARE_PER_CPU(struct ia64_cpu, cpu_devices);
 
-DECLARE_PER_CPU(int, cpu_state);
-
 #ifdef CONFIG_HOTPLUG_CPU
 extern int arch_register_cpu(int num);
 extern void arch_unregister_cpu(int);
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 5e0e86d..32566c7 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -29,6 +29,7 @@
 #include <linux/kdebug.h>
 #include <linux/utsname.h>
 #include <linux/tracehook.h>
+#include <linux/smpboot.h>
 
 #include <asm/cpu.h>
 #include <asm/delay.h>
diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
index 963d2db..df00a3c 100644
--- a/arch/ia64/kernel/smpboot.c
+++ b/arch/ia64/kernel/smpboot.c
@@ -39,6 +39,7 @@
 #include <linux/efi.h>
 #include <linux/percpu.h>
 #include <linux/bitops.h>
+#include <linux/smpboot.h>
 
 #include <linux/atomic.h>
 #include <asm/cache.h>
@@ -111,11 +112,6 @@ extern unsigned long ia64_iobase;
 
 struct task_struct *task_for_booting_cpu;
 
-/*
- * State for each CPU
- */
-DEFINE_PER_CPU(int, cpu_state);
-
 cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
 EXPORT_SYMBOL(cpu_core_map);
 DEFINE_PER_CPU_SHARED_ALIGNED(cpumask_t, cpu_sibling_map);
diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index 97e7ce9..93cd4b0 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -13,6 +13,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/sched.h>
 #include <linux/module.h>
+#include <linux/smpboot.h>
 
 #include <asm/mmu_context.h>
 #include <asm/time.h>
@@ -252,9 +253,6 @@ static void octeon_cpus_done(void)
 
 #ifdef CONFIG_HOTPLUG_CPU
 
-/* State of each CPU. */
-DEFINE_PER_CPU(int, cpu_state);
-
 extern void fixup_irqs(void);
 
 static DEFINE_SPINLOCK(smp_reserve_lock);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index e1417c4..1928058a 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -31,6 +31,7 @@
 #include <linux/cpu.h>
 #include <linux/notifier.h>
 #include <linux/topology.h>
+#include <linux/smpboot.h>
 
 #include <asm/ptrace.h>
 #include <linux/atomic.h>
@@ -57,11 +58,6 @@
 #define DBG(fmt...)
 #endif
 
-#ifdef CONFIG_HOTPLUG_CPU
-/* State of each CPU during hotplug phases */
-static DEFINE_PER_CPU(int, cpu_state) = { 0 };
-#endif
-
 struct thread_info *secondary_ti;
 
 DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
diff --git a/arch/sh/include/asm/smp.h b/arch/sh/include/asm/smp.h
index 78b0d0f4..bda041e 100644
--- a/arch/sh/include/asm/smp.h
+++ b/arch/sh/include/asm/smp.h
@@ -31,8 +31,6 @@ enum {
 	SMP_MSG_NR,	/* must be last */
 };
 
-DECLARE_PER_CPU(int, cpu_state);
-
 void smp_message_recv(unsigned int msg);
 void smp_timer_broadcast(const struct cpumask *mask);
 
diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c
index b86e9ca..8e0fde0 100644
--- a/arch/sh/kernel/smp.c
+++ b/arch/sh/kernel/smp.c
@@ -22,6 +22,7 @@
 #include <linux/interrupt.h>
 #include <linux/sched.h>
 #include <linux/atomic.h>
+#include <linux/smpboot.h>
 #include <asm/processor.h>
 #include <asm/mmu_context.h>
 #include <asm/smp.h>
@@ -34,9 +35,6 @@ int __cpu_logical_map[NR_CPUS];		/* Map logical to physical */
 
 struct plat_smp_ops *mp_ops = NULL;
 
-/* State of each CPU */
-DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
 void __cpuinit register_smp_ops(struct plat_smp_ops *ops)
 {
 	if (mp_ops)
diff --git a/arch/tile/kernel/smpboot.c b/arch/tile/kernel/smpboot.c
index e686c5a..24a9c06 100644
--- a/arch/tile/kernel/smpboot.c
+++ b/arch/tile/kernel/smpboot.c
@@ -25,13 +25,11 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/irq.h>
+#include <linux/smpboot.h>
 #include <asm/mmu_context.h>
 #include <asm/tlbflush.h>
 #include <asm/sections.h>
 
-/* State of each CPU. */
-static DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
 /* The messaging code jumps to this pointer during boot-up */
 unsigned long start_cpu_function_addr;
 
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 4564c8e..2d0b239 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -30,8 +30,6 @@ extern int arch_register_cpu(int num);
 extern void arch_unregister_cpu(int);
 #endif
 
-DECLARE_PER_CPU(int, cpu_state);
-
 int mwait_usable(const struct cpuinfo_x86 *);
 
 #endif /* _ASM_X86_CPU_H */
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index bfbe30e..269bc1f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -51,6 +51,7 @@
 #include <linux/stackprotector.h>
 #include <linux/gfp.h>
 #include <linux/cpuidle.h>
+#include <linux/smpboot.h>
 
 #include <asm/acpi.h>
 #include <asm/desc.h>
@@ -73,9 +74,6 @@
 #include <asm/smpboot_hooks.h>
 #include <asm/i8259.h>
 
-/* State of each CPU */
-DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
 #ifdef CONFIG_HOTPLUG_CPU
 /*
  * We need this for trampoline_base protection from concurrent accesses when
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2ef5948..09a7199 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -16,6 +16,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/smp.h>
+#include <linux/smpboot.h>
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index 63bbedd..834d90c 100644
--- a/include/linux/smpboot.h
+++ b/include/linux/smpboot.h
@@ -5,6 +5,7 @@
 #ifndef SMPBOOT_H
 #define SMPBOOT_H
 
+DECLARE_PER_CPU(int, cpu_state);
 extern void smpboot_start_secondary(void *arg);
 
 #endif
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 5ae1805..0df43b0 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -67,6 +67,8 @@ void __init idle_threads_init(void)
 }
 #endif
 
+/* State of each CPU during bringup/teardown */
+DEFINE_PER_CPU(int, cpu_state) = { 0 };
 
 /* Implement the following functions in your architecture, as appropriate. */
 
@@ -141,6 +143,8 @@ void __cpuinit smpboot_start_secondary(void *arg)
 	set_cpu_online(cpu, true);
 	arch_vector_unlock();
 
+	per_cpu(cpu_state, cpu) = CPU_ONLINE;
+
 	__cpu_post_online(arg);
 
 	/* Enable local interrupts now */


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjB-0004su-Oa; Fri, 01 Jun 2012 11:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6fg-0004wT-6X
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:16 +0000
Received: from [85.158.143.35:10043] by server-2.bemta-4.messagelabs.com id
	DF/DE-11595-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3471 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765940"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fd-0003WP-2b;
	Thu, 31 May 2012 14:48:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6jt-0006to-2S;
	Thu, 31 May 2012 15:52:37 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:35 +0100
Message-ID: <1338475955-26472-6-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/v4v.c                   | 1779 ++++++++++++++++++++++++++++++++++++
 xen/include/public/v4v.h           |  544 +++++++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/v4v.h              |  109 +++
 11 files changed, 2461 insertions(+), 5 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0005-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0005-xen-Add-V4V-implementation.patch"

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..6f2d70e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3124,7 +3124,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] = {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
 
 #else /* defined(__x86_64__) */
@@ -3209,7 +3210,8 @@ static hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] = {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
 
 #define COMPAT_CALL(x)                                        \
@@ -3226,7 +3228,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] = {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
 
 #endif /* defined(__x86_64__) */
diff --git a/xen/arch/x86/x86_32/entry.S b/xen/arch/x86/x86_32/entry.S
index 2982679..b3e0da4 100644
--- a/xen/arch/x86/x86_32/entry.S
+++ b/xen/arch/x86/x86_32/entry.S
@@ -700,6 +700,7 @@ ENTRY(hypercall_table)
         .long do_domctl
         .long do_kexec_op
         .long do_tmem_op
+        .long do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/4)
         .long do_ni_hypercall
         .endr
@@ -748,6 +749,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec_op          */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index f49ff2d..28615f9 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 6 /* do_v4v_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 3836260..918fa59 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -699,6 +699,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -747,6 +748,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9eba8bc..fe3c72c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
+obj-y += v4v.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo,$(n).init.o)
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8840202..9539d88 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm = 1u<<0, INIT_watchdog = 1u<<1, INIT_rangeset = 1u<<2,
-           INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
+           INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5,
+           INIT_v4v = 1u<<6 };
     int init_status = 0;
     int poolid = CPUPOOLID_NONE;
 
@@ -219,6 +220,7 @@ struct domain *domain_create(
     spin_lock_init(&d->hypercall_deadlock_mutex);
     INIT_PAGE_LIST_HEAD(&d->page_list);
     INIT_PAGE_LIST_HEAD(&d->xenpage_list);
+    rwlock_init(&d->v4v_lock);
 
     spin_lock_init(&d->node_affinity_lock);
     d->node_affinity = NODE_MASK_ALL;
@@ -274,6 +276,10 @@ struct domain *domain_create(
             goto fail;
         init_status |= INIT_gnttab;
 
+        if ( v4v_init(d) != 0 )
+            goto fail;
+        init_status |= INIT_v4v;
+
         poolid = 0;
 
         d->mem_event = xzalloc(struct mem_event_per_domain);
@@ -313,6 +319,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -466,6 +474,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..ed846ba
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1779 @@
+/******************************************************************************
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#include <xen/config.h>
+#include <xen/mm.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/v4v.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <asm/paging.h>
+#include <asm/p2m.h>
+#include <xen/keyhandler.h>
+
+#ifdef V4V_DEBUG
+#define MY_FILE "v4v.c"
+#define v4v_dprintk(format, args...)                    \
+    do {                                                \
+        printk("%s:%d " format,                         \
+               MY_FILE, __LINE__, ## args );            \
+    } while ( 1 == 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+
+
+DEFINE_XEN_GUEST_HANDLE (uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info (struct domain *d,
+                                                 struct v4v_ring_id *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr (struct domain *d,
+                                                         struct v4v_addr *a,
+                                                         domid_t p);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK (v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void
+v4v_hexdump (void *_p, int len)
+{
+    uint8_t *buf = (uint8_t *) _p;
+    int i, j;
+
+    for (i = 0; i < len; i += 16)
+    {
+        printk (KERN_ERR "%p:", &buf[i]);
+        for (j = 0; j < 16; ++j)
+        {
+            int k = i + j;
+            if (k < len)
+                printk (" %02x", buf[k]);
+            else
+                printk ("   ");
+        }
+        printk (" ");
+
+        for (j = 0; j < 16; ++j)
+        {
+            int k = i + j;
+            if (k < len)
+                printk ("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k] : '.');
+            else
+                printk (" ");
+        }
+        printk ("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain (struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+    send_guest_vcpu_virq (d->vcpu[0], VIRQ_V4V);
+}
+
+static void
+v4v_signal_domid (domid_t id)
+{
+    struct domain *d = get_domain_by_id (id);
+    if (!d)
+        return;
+    v4v_signal_domain (d);
+    put_domain (d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+/* called must have L3 */
+static void
+v4v_ring_unmap (struct v4v_ring_info *ring_info)
+{
+    int i;
+    for (i = 0; i < ring_info->npage; ++i)
+    {
+        if (!ring_info->mfn_mapping[i])
+            continue;
+        v4v_dprintk("");
+        v4v_dprintk("unmapping page %p from %p\n",
+                (void*) mfn_x (ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+
+        unmap_domain_page (ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] = NULL;
+    }
+}
+
+/* called must have L3 */
+static uint8_t *
+v4v_ring_map_page (struct v4v_ring_info *ring_info, int i)
+{
+    if (i >= ring_info->npage)
+        return NULL;
+    if (ring_info->mfn_mapping[i])
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] = map_domain_page (mfn_x (ring_info->mfns[i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+            (void *) mfn_x (ring_info->mfns[i]),
+            ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_from_guest_ring (void *_dst, struct v4v_ring_info *ring_info,
+                            uint32_t offset, uint32_t len)
+{
+    int page = offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst = _dst;
+
+    offset &= PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        src = v4v_ring_map_page (ring_info, page);
+
+        if (!src)
+        {
+            return -EFAULT;
+        }
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                dst, src, offset,
+                (int) (PAGE_SIZE - offset));
+        memcpy (dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -= PAGE_SIZE - offset;
+        dst += PAGE_SIZE - offset;
+        offset = 0;
+    }
+
+    src = v4v_ring_map_page (ring_info, page);
+    if (!src)
+    {
+        return -EFAULT;
+    }
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy (dst, src + offset, len);
+
+    return 0;
+}
+
+
+/* called must have L3 */
+static int
+v4v_update_tx_ptr (struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst = v4v_ring_map_page (ring_info, 0);
+    volatile uint32_t *p = (uint32_t *)(dst + offsetof (v4v_ring_t, tx_ptr));
+
+    if (!dst)
+        return -EFAULT;
+    *p = tx_ptr;
+    return 0;
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_to_guest_ring (struct v4v_ring_info *ring_info, uint32_t offset,
+        void *_src, uint32_t len)
+{
+    int page = offset >> PAGE_SHIFT;
+    uint8_t *dst;
+    uint8_t *src = _src;
+
+    offset &= PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        dst = v4v_ring_map_page (ring_info, page);
+
+        if (!dst)
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+#ifdef V4V_DEBUG
+        v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+                dst, offset, src,
+                (int) (PAGE_SIZE - offset));
+        v4v_hexdump (src, PAGE_SIZE - offset);
+        v4v_hexdump (dst + offset, PAGE_SIZE - offset);
+#endif
+        memcpy (dst + offset, src, PAGE_SIZE - offset);
+
+        page++;
+        len -= (PAGE_SIZE - offset);
+        src += (PAGE_SIZE - offset);
+        offset = 0;
+    }
+
+    dst = v4v_ring_map_page (ring_info, page);
+
+    if (!dst)
+    {
+        v4v_dprintk("attempted to map page %d of %d\n", page, ring_info->npage);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+            dst, offset, src, len);
+    v4v_hexdump (src, len);
+    v4v_hexdump (dst + offset, len);
+#endif
+    memcpy (dst + offset, src, len);
+
+    return 0;
+}
+
+/*called must have L3*/
+static int
+v4v_memcpy_to_guest_ring_from_guest(struct v4v_ring_info *ring_info,
+                                    uint32_t offset,
+                                    XEN_GUEST_HANDLE (uint8_t) src_hnd,
+                                    uint32_t len)
+{
+    int page = offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    offset &= PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst = v4v_ring_map_page (ring_info, page);
+
+        if ( !dst )
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+        v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                    dst, offset, (void *) src_hnd.p,
+                    (int) (PAGE_SIZE - offset));
+        if ( copy_from_guest ((dst + offset), src_hnd, PAGE_SIZE - offset) )
+        {
+            v4v_dprintk("copy_from_guest failed\n");
+            return -EFAULT;
+        }
+
+        page++;
+        len -= PAGE_SIZE - offset;
+        guest_handle_add_offset (src_hnd, PAGE_SIZE - offset);
+        offset = 0;
+    }
+
+    dst = v4v_ring_map_page (ring_info, page);
+    if (!dst)
+    {
+        v4v_dprintk("v4v_ring_map failed\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                dst, offset, (void *) src_hnd.p, len);
+    if ( copy_from_guest ((dst + offset), src_hnd, len) )
+    {
+        v4v_dprintk("copy_from_guest failed\n");
+        return -EFAULT;
+    }
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr (struct domain *d, struct v4v_ring_info *ring_info,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage == 0 )
+        return -1;
+
+    ringp = map_domain_page (mfn_x (ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *) mfn_x (ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    *rx_ptr = *(volatile uint32_t *) &ringp->rx_ptr;
+
+    unmap_domain_page (mfn_x (ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space (struct domain * d, struct v4v_ring_info * ring_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr = ring_info->tx_ptr;
+    ring.len = ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=%d rx_ptr=%d\n",
+                (int) ring.tx_ptr, (int) ring.rx_ptr);
+    if ( ring.rx_ptr == ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret = ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret += ring.len;
+
+    ret -= sizeof (struct v4v_ring_message_header);
+    ret -= V4V_ROUNDUP (1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+/*caller must have L3*/
+static size_t
+v4v_ringbuf_insert (struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    struct v4v_ring_id *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE (void) buf_hnd_void, uint32_t len)
+{
+    XEN_GUEST_HANDLE (uint8_t) buf_hnd =
+        guest_handle_cast (buf_hnd_void, uint8_t);
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh = { 0 };
+    int32_t sp;
+    int32_t happy_ret = len;
+    int32_t ret = 0;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header)) >=
+            ring_info->len )
+    {
+        v4v_dprintk("EMSGSIZE\n");
+        return -EMSGSIZE;
+    }
+
+    do
+    {
+        if ( (ret = v4v_memcpy_from_guest_ring (&ring, ring_info,
+                                                0, sizeof (ring))) )
+            break;
+
+        ring.tx_ptr = ring_info->tx_ptr;
+        ring.len = ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=%d ring.rx_ptr=%d ring.len=%d ring_info->tx_ptr=%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_ptr);
+
+        if ( ring.rx_ptr == ring.tx_ptr )
+            sp = ring_info->len;
+        else
+        {
+            sp = ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp += ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header)) >= sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret = -EAGAIN;
+            break;
+        }
+
+        mh.len = len + sizeof (struct v4v_ring_message_header);
+        mh.source = src_id->addr;
+        mh.pad = 0;
+        mh.protocol = proto;
+
+        if ( (ret = v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr += sizeof (mh);
+        if ( ring.tx_ptr == ring_info->len )
+            ring.tx_ptr = 0;
+
+        sp = ring.len - ring.tx_ptr;
+
+        if ( len > sp )
+        {
+            if ((ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                            ring.tx_ptr + sizeof (v4v_ring_t),
+                            buf_hnd, sp)))
+                break;
+
+            ring.tx_ptr = 0;
+            len -= sp;
+            guest_handle_add_offset (buf_hnd, sp);
+        }
+
+        if ( (ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        buf_hnd, len)) )
+            break;
+
+        ring.tx_ptr += V4V_ROUNDUP (len);
+
+        if ( ring.tx_ptr == ring_info->len )
+            ring.tx_ptr = 0;
+
+        mb ();
+        ring_info->tx_ptr = ring.tx_ptr;
+
+        if ( (ret = v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+
+}
+
+static ssize_t
+v4v_iov_count (XEN_GUEST_HANDLE (v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret = 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest (&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret += iov.iov_len;
+        guest_handle_add_offset (iovs, 1);
+    }
+
+    return ret;
+}
+
+/*caller must have L3*/
+static ssize_t
+v4v_ringbuf_insertv (struct domain *d,
+                     struct v4v_ring_info *ring_info,
+                     struct v4v_ring_id *src_id, uint32_t proto,
+                     XEN_GUEST_HANDLE (v4v_iov_t) iovs, uint32_t niov,
+                     uint32_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh = { 0 };
+    int32_t sp;
+    int32_t happy_ret;
+    int32_t ret = 0;
+
+    happy_ret = len;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header) ) >=
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret = v4v_memcpy_from_guest_ring (&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr = ring_info->tx_ptr;
+        ring.len = ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=%d ring.rx_ptr=%d ring.len=%d ring_info->tx_ptr=%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_ptr);
+
+        if ( ring.rx_ptr == ring.tx_ptr )
+            sp = ring_info->len;
+        else
+        {
+            sp = ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp += ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header) ) >= sp)
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret = -EAGAIN;
+            break;
+        }
+
+        mh.len = len + sizeof (struct v4v_ring_message_header);
+        mh.source = src_id->addr;
+        mh.pad = 0;
+        mh.protocol = proto;
+
+        if ( (ret = v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr += sizeof (mh);
+        if ( ring.tx_ptr == ring_info->len )
+            ring.tx_ptr = 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE (uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest (&iov, iovs, 1) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            buf_hnd.p = (uint8_t *) iov.iov_base; //FIXME
+            len = iov.iov_len;
+
+            if ( unlikely (!guest_handle_okay (buf_hnd, len)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            sp = ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                if ( (ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                                ring.tx_ptr +
+                                sizeof (v4v_ring_t),
+                                buf_hnd, sp)) )
+                    break;
+
+                ring.tx_ptr = 0;
+                len -= sp;
+                guest_handle_add_offset (buf_hnd, sp);
+            }
+
+            if ( (ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                            ring.tx_ptr +
+                            sizeof (v4v_ring_t),
+                            buf_hnd, len)) )
+                break;
+
+            ring.tx_ptr += len;
+
+            if (ring.tx_ptr == ring_info->len)
+                ring.tx_ptr = 0;
+
+            guest_handle_add_offset (iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr = V4V_ROUNDUP (ring.tx_ptr);
+
+        if ( ring.tx_ptr >= ring_info->len )
+            ring.tx_ptr -= ring_info->len;
+
+        mb ();
+        ring_info->tx_ptr = ring.tx_ptr;
+        if ( (ret = v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent (struct v4v_pending_ent *ent)
+{
+    hlist_del (&ent->node);
+    xfree (ent);
+}
+
+/*caller must have L3 */
+static void
+v4v_pending_remove_all (struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent (pending_ent);
+}
+
+/*Caller must hold L1 */
+static void
+v4v_pending_notify (struct domain *caller_d, struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, to_notify, node)
+    {
+        hlist_del (&pending_ent->node);
+        v4v_signal_domid (pending_ent->id);
+        xfree (pending_ent);
+    }
+
+}
+
+/*caller must have R(L2) */
+static void
+v4v_pending_find (struct v4v_ring_info *ring_info, uint32_t payload_space,
+        struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    spin_lock (&ring_info->lock);
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, node)
+    {
+        if (payload_space >= ent->len)
+        {
+            hlist_del (&ent->node);
+            hlist_add_head (&ent->node, to_notify);
+        }
+    }
+    spin_unlock (&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue (struct v4v_ring_info *ring_info, domid_t src_id, int len)
+{
+    struct v4v_pending_ent *ent = xmalloc (struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len = len;
+    ent->id = src_id;
+
+    hlist_add_head (&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue (struct v4v_ring_info *ring_info, domid_t src_id, int len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry (ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id == src_id )
+        {
+            if ( ent->len < len )
+                ent->len = len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue (ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel (struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, node)
+    {
+        if ( ent->id == src_id)
+        {
+            hlist_del (&ent->node);
+            xfree (ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data (struct domain *src_d,
+                    XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest (&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=%d,ent.ring.port=%u\n",
+                (int) ent.ring.domain, (int) ent.ring.port);
+
+    ent.flags = 0;
+
+    dst_d = get_domain_by_id (ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock (&dst_d->v4v->lock);
+        ring_info = v4v_ring_find_info_by_addr (dst_d, &ent.ring,
+                                                src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |= V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =
+                ring_info->len - sizeof (struct v4v_ring_message_header) -
+                V4V_ROUNDUP (1);
+            spin_lock (&ring_info->lock);
+
+            space_avail = v4v_ringbuf_payload_space (dst_d, ring_info);
+
+            if ( space_avail >= ent.space_required )
+            {
+                v4v_pending_cancel (ring_info, src_d->domain_id);
+                ent.flags |= V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue (ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |= V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock (&ring_info->lock);
+
+            if ( space_avail == ent.max_message_size )
+                ent.flags |= V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain (dst_d);
+
+    if ( copy_field_to_guest (data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas (struct domain *d, int nent,
+                     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd)
+{
+    int ret = 0;
+
+    read_lock (&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret = v4v_fill_ring_data (d, data_ent_hnd);
+        guest_handle_add_offset (data_ent_hnd, 1);
+    }
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns (struct domain *d, struct v4v_ring_info *ring_info,
+                    XEN_GUEST_HANDLE (v4v_pfn_list_t) pfn_list_hnd)
+{
+    XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd;
+    v4v_pfn_list_t pfn_list;
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret = 0;
+
+    if ( copy_from_guest (&pfn_list, pfn_list_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    if (pfn_list.magic != V4V_PFN_LIST_MAGIC)
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    if ((pfn_list.npage << PAGE_SHIFT) < ring_info->len)
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    {
+        XEN_GUEST_HANDLE (uint8_t) slop_hnd =
+            guest_handle_cast (pfn_list_hnd, uint8_t);
+        guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
+        pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
+    }
+
+    mfns = xmalloc_array (mfn_t, pfn_list.npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping = xmalloc_array (uint8_t *, pfn_list.npage);
+    if ( !mfn_mapping )
+    {
+        xfree (mfns);
+        return -ENOMEM;
+    }
+
+    for (i = 0; i < pfn_list.npage; ++i)
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset (&pfn, pfn_hnd, i, 1) )
+        {
+            ret = -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn = mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret = -EINVAL;
+            break;
+        }
+        page = mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_mfn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret = -EINVAL;
+            break;
+        }
+        mfns[i] = _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long) pfn, (unsigned long) mfn_x (mfns[i]));
+        mfn_mapping[i] = NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage = pfn_list.npage;
+        ring_info->mfns = mfns;
+        ring_info->mfn_mapping = mfn_mapping;
+    }
+    else
+    {
+        j = i;
+        for ( i = 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) != 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree (mfn_mapping);
+        xfree (mfns);
+        v4v_dprintk("");
+    }
+    return ret;
+}
+
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info (struct domain *d, struct v4v_ring_id *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    hash = v4v_hash_fn (id);
+
+    v4v_dprintk("ring_find_info: d->v4v=%p, d->v4v->ring_hash[%d]=%p id=%p\n",
+                d->v4v, (int) hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=%d id.addr.domain=%d id.addr.partner=%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[hash], node)
+    {
+        if ( !memcmp (id, &ring_info->id, sizeof (*id)) )
+        {
+            v4v_dprintk("ring_find_info: ring_info=%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr (struct domain *d, struct v4v_addr *a, domid_t p)
+{
+    struct v4v_ring_id id;
+    struct v4v_ring_info *ret;
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port = a->port;
+    id.addr.domain = d->domain_id;
+    id.partner = p;
+
+    ret = v4v_ring_find_info (d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner = V4V_DOMID_NONE;
+
+    return v4v_ring_find_info (d, &id);
+}
+
+/*caller must hold W(L2) */
+static void v4v_ring_remove_mfns (struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    if ( ring_info->mfns )
+    {
+        for ( i=0; i < ring_info->npage; ++i )
+            if (mfn_x(ring_info->mfns[i]) != 0)
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i])));
+        xfree (ring_info->mfns);
+    }
+    ring_info->mfns = NULL;
+}
+
+/*caller must hold W(L2) */
+static void
+v4v_ring_remove_info (struct v4v_ring_info *ring_info)
+{
+    v4v_pending_remove_all (ring_info);
+
+    hlist_del (&ring_info->node);
+    v4v_ring_remove_mfns(ring_info);
+    xfree (ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret = 0;
+
+    read_lock (&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret = -EFAULT;
+            break;
+        }
+
+        if ( ring.magic != V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) != V4V_RING_MAGIC(%lx), EINVAL\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret = -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain = d->domain_id;
+
+        write_lock (&d->v4v->lock);
+        ring_info = v4v_ring_find_info (d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info (ring_info);
+
+        write_unlock (&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk( "ENOENT\n" );
+            ret = -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd,
+              XEN_GUEST_HANDLE (v4v_pfn_list_t) pfn_list_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert = 0;
+    int ret = 0;
+
+    if ( (long) ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret = -EFAULT;
+            break;
+        }
+
+        if ( ring.magic != V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) != V4V_RING_MAGIC(%lx), EINVAL\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret = -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUNDUP (1) +
+                     V4V_ROUNDUP (1))) || (V4V_ROUNDUP (ring.len) != ring.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain = d->domain_id;
+        if ( copy_field_to_guest (ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret = -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >= ring.len)
+                || (V4V_ROUNDUP (ring.tx_ptr) != ring.tx_ptr) )
+        {
+            ring.tx_ptr = ring.rx_ptr;
+        }
+        copy_field_to_guest (ring_hnd, &ring, tx_ptr);
+
+        read_lock (&d->v4v->lock);
+        ring_info = v4v_ring_find_info (d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock (&d->v4v->lock);
+            ring_info = xmalloc (struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret = -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init (&ring_info->lock);
+            INIT_HLIST_HEAD (&ring_info->pending);
+            ring_info->mfns = NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed. If mfn list was already
+             * populated remove the MFN's from list and then add
+             * the new list.
+             */
+            printk(KERN_INFO "v4v: dom%d re-registering existing ring, clearing MFN list\n",
+                    current->domain->domain_id);
+            v4v_ring_remove_mfns(ring_info);
+        }
+
+        spin_lock (&ring_info->lock);
+        ring_info->id = ring.id;
+        ring_info->len = ring.len;
+        ring_info->tx_ptr = ring.tx_ptr;
+        ring_info->ring = ring_hnd;
+        if ( ring_info->mfns )
+            xfree (ring_info->mfns);
+        ret = v4v_find_ring_mfns (d, ring_info, pfn_list_hnd);
+        spin_unlock (&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock (&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash = v4v_hash_fn (&ring.id);
+            write_lock (&d->v4v->lock);
+            hlist_add_head (&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock (&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+/*Caller must hold v4v_lock and hash_lock*/
+static void
+v4v_notify_ring (struct domain *d, struct v4v_ring_info *ring_info,
+        struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    spin_lock (&ring_info->lock);
+    space = v4v_ringbuf_payload_space (d, ring_info);
+    spin_unlock (&ring_info->lock);
+
+    v4v_pending_find (ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify (struct domain *d,
+            XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD (to_notify);
+    int i;
+    int ret = 0;
+
+    read_lock (&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock (&d->v4v->lock);
+    for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe (ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring (d, ring_info, &to_notify);
+        }
+    }
+    read_unlock (&d->v4v->lock);
+
+    if ( !hlist_empty (&to_notify) )
+    {
+        v4v_pending_notify (d, &to_notify);
+    }
+
+    do
+    {
+        if ( !guest_handle_is_null (ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest (&ring_data, ring_data_hnd, magic) )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret = -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic != V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) != V4V_RING_MAGIC(%lx), EINVAL\n",
+                            ring_data.magic, V4V_RING_MAGIC);
+                ret = -EINVAL;
+                break;
+            }
+
+            if (copy_from_guest (&ring_data, ring_data_hnd, 1))
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret = -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
+                XEN_GUEST_HANDLE (uint8_t) slop_hnd =
+                    guest_handle_cast (ring_data_hnd, uint8_t);
+                guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
+                ring_data_ent_hnd =
+                    guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
+                ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+
+    return ret;
+}
+
+
+
+/*Hypercall to do the send*/
+static size_t
+v4v_send (struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE (void) buf, size_t len)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret = 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port = src_addr->port;
+    src_id.addr.domain = src_d->domain_id;
+    src_id.partner = dst_addr->domain;
+
+    dst_d = get_domain_by_id (dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            ret = -ECONNREFUSED;
+            v4v_dprintk("!dst_d->v4v, ECONNREFUSED\n");
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domain);
+
+        if ( !ring_info )
+        {
+            ret = -ECONNREFUSED;
+            v4v_dprintk("!ring_info\n");
+        }
+        else
+        {
+            spin_lock (&ring_info->lock);
+            ret =
+                v4v_ringbuf_insert (dst_d, ring_info, &src_id, proto, buf, len);
+            if ( ret == -EAGAIN )
+            {
+                v4v_dprintk("ret == EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, len))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret = -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if (ret >= 0)
+            {
+                v4v_signal_domain (dst_d);
+            }
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*Hypercall to do the send*/
+static size_t
+v4v_sendv (struct domain *src_d, v4v_addr_t * src_addr,
+           v4v_addr_t * dst_addr, uint32_t proto,
+           XEN_GUEST_HANDLE (v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret = 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if (!src_d->v4v)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port = src_addr->port;
+    src_id.addr.domain = src_d->domain_id;
+    src_id.partner = dst_addr->domain;
+
+    dst_d = get_domain_by_id (dst_addr->domain);
+    if (!dst_d)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret = -ECONNREFUSED;
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domain);
+
+        if ( !ring_info )
+        {
+            ret = -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            uint32_t len = v4v_iov_count (iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret = len;
+                break;
+            }
+
+            spin_lock (&ring_info->lock);
+            ret =
+                v4v_ringbuf_insertv (dst_d, ring_info, &src_id, proto, iovs,
+                        niov, len);
+            if ( ret == -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, len))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret = -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if ( ret >= 0 )
+            {
+                v4v_signal_domain (dst_d);
+            }
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op (int cmd, XEN_GUEST_HANDLE (void) arg1,
+           XEN_GUEST_HANDLE (void) arg2,
+           XEN_GUEST_HANDLE (void) arg3, uint32_t arg4, uint32_t arg5)
+{
+    struct domain *d = current->domain;
+    long rc = -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%p,%d,%d)\n", cmd,
+                (void *) arg1.p, (void *) arg2.p, (void *) arg3.p,
+                (int) arg4, (int) arg5);
+
+    domain_lock (d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =
+                    guest_handle_cast (arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE (v4v_pfn_list_t) pfn_list_hnd =
+                    guest_handle_cast (arg2, v4v_pfn_list_t);
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                if ( unlikely (!guest_handle_okay (pfn_list_hnd, 1)) ) //FIXME
+                    goto out;
+                rc = v4v_ring_add (d, ring_hnd, pfn_list_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =
+                    guest_handle_cast (arg1, v4v_ring_t);
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                rc = v4v_ring_remove (d, ring_hnd);
+                break;
+            }
+        case V4VOP_send:
+            {
+                v4v_addr_t src, dst;
+                uint32_t len = arg4;
+                uint32_t protocol = arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =
+                    guest_handle_cast (arg2, v4v_addr_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                rc = v4v_send (d, &src, &dst, protocol, arg3, len);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                v4v_addr_t src, dst;
+                uint32_t niov = arg4;
+                uint32_t protocol = arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =
+                    guest_handle_cast (arg2, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_iov_t) iovs =
+                    guest_handle_cast (arg3, v4v_iov_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (iovs, niov)) )
+                    goto out;
+
+                rc = v4v_sendv (d, &src, &dst, protocol, iovs, niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd =
+                    guest_handle_cast (arg1, v4v_ring_data_t);
+                rc = v4v_notify (d, ring_data_hnd);
+                break;
+            }
+        default:
+            rc = -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock (d);
+    v4v_dprintk("<-do_v4v_op()=%d\n", (int) rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy (struct domain *d)
+{
+    int i;
+
+    BUG_ON (!d->is_dying);
+    write_lock (&v4v_lock);
+
+    v4v_dprintk("d->v=%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe (ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info (ring_info);
+            }
+        }
+    }
+
+    d->v4v = NULL;
+    write_unlock (&v4v_lock);
+}
+
+int
+v4v_init (struct domain *d)
+{
+    struct v4v_domain *v4v;
+    int i;
+
+    v4v = xmalloc (struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rwlock_init (&v4v->lock);
+
+    for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        INIT_HLIST_HEAD (&v4v->ring_hash[i]);
+    }
+
+    write_lock (&v4v_lock);
+    d->v4v = v4v;
+    write_unlock (&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring (struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk (KERN_ERR "  ring: domid=%d port=0x%08x partner=%d npage=%d\n",
+            (int) d->domain_id, (int) ring_info->id.addr.port,
+            (int) ring_info->id.partner, (int) ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &rx_ptr) )
+    {
+        printk (KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk (KERN_ERR "   tx_ptr=%d rx_ptr=%d len=%d\n",
+            (int) ring_info->tx_ptr, (int) rx_ptr, (int) ring_info->len);
+}
+
+static void
+dump_domain_rings (struct domain *d)
+{
+    int i;
+
+    printk (KERN_ERR " domain %d:\n", (int) d->domain_id);
+
+    read_lock (&d->v4v->lock);
+
+    for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[i], node)
+            dump_domain_ring (d, ring_info);
+    }
+    read_unlock (&d->v4v->lock);
+
+    printk (KERN_ERR "\n");
+    v4v_signal_domain (d);
+}
+
+static void
+dump_rings (unsigned char key)
+{
+    struct domain *d;
+
+    printk (KERN_ERR "\n\nV4V ring dump:\n");
+    read_lock (&v4v_lock);
+
+    rcu_read_lock (&domlist_read_lock);
+
+    for_each_domain (d) dump_domain_rings (d);
+
+    rcu_read_unlock (&domlist_read_lock);
+
+    read_unlock (&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_rings,
+    .desc = "dump v4v ring states and intterupt"
+};
+
+static int __init
+setup_dump_rings (void)
+{
+    register_keyhandler ('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall (setup_dump_rings);
+
+
+/*
+ * 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/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..8cb02a8
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,544 @@
+/******************************************************************************
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+
+/*
+ * Compiler specific hacks
+ */
+#if !defined(__GNUC__)
+# define V4V_PACKED
+# define V4V_UNSUED
+# define V4V_INLINE __inline
+#else /* __GNUC__ */
+# define V4V_PACKED __attribute__ ((packed))
+# define V4V_UNUSED __attribute__ ((unused))
+# ifdef __XEN__
+#  define V4V_INLINE
+#  define V4V_VOLATILE
+# else
+#  define V4V_VOLATILE volatile
+#  ifndef __STRICT_ANSI__
+#   define V4V_INLINE inline
+#  else
+#   define V4V_INLINE
+#  endif
+# endif
+#endif /* __GNUC__ */
+
+#if !defined(__GNUC__)
+# pragma pack(push, 1)
+# pragma warning(push)
+# pragma warning(disable: 4200)
+#endif
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_PROTO_DGRAM		0x3c2c1db8
+#define V4V_PROTO_STREAM 	0x70f6a8e5
+
+#ifdef __i386__
+# define V4V_RING_MAGIC         0xdf6977f231abd910ULL
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302dULL
+#else
+# define V4V_RING_MAGIC         0xdf6977f231abd910
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302d
+#endif
+#define V4V_DOMID_INVALID       (0x7FFFU)
+#define V4V_DOMID_NONE          V4V_DOMID_INVALID
+#define V4V_DOMID_ANY           V4V_DOMID_INVALID
+#define V4V_PORT_NONE           0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint64_t iov_len;
+} V4V_PACKED v4v_iov_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+} V4V_PACKED v4v_addr_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+
+typedef struct v4v_ring_id
+{
+    struct v4v_addr addr;
+    domid_t partner;
+} V4V_PACKED v4v_ring_id_t;
+
+
+typedef uint64_t v4v_pfn_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
+
+typedef struct v4v_pfn_list_t
+{
+    uint64_t magic;
+    uint32_t npage;
+    uint32_t pad;
+    uint64_t reserved[3];
+    v4v_pfn_t pages[0];
+} V4V_PACKED v4v_pfn_list_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_list_t);
+
+
+typedef struct v4v_ring
+{
+    /* v4v magic number */
+    uint64_t magic;
+    /*
+     * id
+     *
+     * xen only looks at this during register/unregister
+     * and will fill in id.addr.domain
+     */
+    struct v4v_ring_id id;
+    /* length of ring[], must be a multiple of 8 */
+    uint32_t len;
+    /* rx pointer, modified by domain */
+    V4V_VOLATILE uint32_t rx_ptr;
+    /* tx pointer, modified by xen */
+    V4V_VOLATILE uint32_t tx_ptr;
+    /* padding */
+    uint64_t reserved[4];
+    /* ring */
+    V4V_VOLATILE uint8_t ring[0];
+} V4V_PACKED v4v_ring_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+
+#ifdef __i386__
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92aULL
+#else
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92a
+#endif
+
+#define V4V_RING_DATA_F_EMPTY       1U << 0 /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      1U << 1 /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     1U << 2 /* Pending interrupt exists - do not
+                                               rely on this field - for
+                                               profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  1U << 3 /* Sufficient space to queue
+                                               space_required bytes exists */
+
+typedef struct v4v_ring_data_ent
+{
+    struct v4v_addr ring;
+    uint16_t flags;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} V4V_PACKED v4v_ring_data_ent_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+    struct v4v_ring_data_ent data[0];
+} V4V_PACKED v4v_ring_data_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+
+
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+/* Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+} V4V_PACKED;
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    struct v4v_addr source;
+    uint16_t pad;
+    uint32_t protocol;
+    uint8_t data[0];
+} V4V_PACKED;
+
+
+/*
+ * HYPERCALLS
+ */
+
+#define V4VOP_register_ring 	1
+/*
+ * Registers a ring with Xen, if a ring with the same v4v_ring_id exists,
+ * this ring takes its place, registration will not change tx_ptr
+ * unless it is invalid
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t),
+ *           XEN_GUEST_HANDLE(v4v_pfn_list_t),
+ *           NULL, 0, 0)
+ */
+
+
+#define V4VOP_unregister_ring 	2
+/*
+ * Unregister a ring.
+ *
+ * v4v_hypercall(V4VOP_send, XEN_GUEST_HANDLE(v4v_ring_t), NULL, NULL, 0, 0)
+ */
+
+#define V4VOP_send 		3
+/*
+ * Sends len bytes of buf to dst, giving src as the source address (xen will
+ * ignore src->domain and put your domain in the actually message), xen
+ * first looks for a ring with id.addr==dst and id.partner==sending_domain
+ * if that fails it looks for id.addr==dst and id.partner==DOMID_ANY.
+ * protocol is the 32 bit protocol number used from the message
+ * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * v4v_hypercall(V4VOP_send,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) src,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) dst,
+ *               XEN_GUEST_HANDLE(void) buf,
+ *               uint32_t len,
+ *               uint32_t protocol)
+ */
+
+
+#define V4VOP_notify 		4
+/* Asks xen for information about other rings in the system
+ *
+ * v4v_ring_data_t contains an array of v4v_ring_data_ent_t
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is there
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * v4v_hypercall(V4VOP_notify,
+ *               XEN_GUEST_HANDLE(v4v_ring_data_t) buf,
+ *               NULL, NULL, 0, 0)
+ */
+
+
+#define V4VOP_sendv		5
+/*
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov_t and a length of the array.
+ *
+ * v4v_hypercall(V4VOP_sendv,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) src,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) dst,
+ *               XEN_GUEST_HANDLE(v4v_iov_t),
+ *               UINT32_t niov,
+ *               uint32_t protocol)
+ */
+
+#if !defined(__GNUC__)
+# pragma warning(pop)
+# pragma pack(pop)
+#endif
+
+#if !defined(__GNUC__)
+static __inline void
+mb (void)
+{
+    _mm_mfence ();
+    _ReadWriteBarrier ();
+}
+#else
+#ifndef mb
+# define mb() __asm__ __volatile__ ("" ::: "memory");
+#endif
+#endif
+
+#if !defined(V4V_EXCLUDE_UTILS)
+
+/*************** Utility functions **************/
+
+static V4V_INLINE uint32_t
+v4v_ring_bytes_to_read (volatile struct v4v_ring *r)
+{
+    int32_t ret;
+    ret = r->tx_ptr - r->rx_ptr;
+    if (ret >= 0)
+        return ret;
+    return (uint32_t) (r->len + ret);
+}
+
+
+/*
+ * Copy at most t bytes of the next message in the ring, into the buffer
+ * at _buf, setting from and protocol if they are not NULL, returns
+ * the actual length of the message, or -1 if there is nothing to read
+ */
+V4V_UNUSED static V4V_INLINE ssize_t
+v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
+              void *_buf, size_t t, int consume)
+{
+    volatile struct v4v_ring_message_header *mh;
+    /* unnecessary cast from void * required by MSVC compiler */
+    uint8_t *buf = (uint8_t *) _buf;
+    uint32_t btr = v4v_ring_bytes_to_read (r);
+    uint32_t rxp = r->rx_ptr;
+    uint32_t bte;
+    uint32_t len;
+    ssize_t ret;
+
+
+    if (btr < sizeof (*mh))
+        return -1;
+
+    /*
+     * Becuase the message_header is 128 bits long and the ring is 128 bit
+     * aligned, we're gaurunteed never to wrap
+     */
+    mh = (volatile struct v4v_ring_message_header *) &r->ring[r->rx_ptr];
+
+    len = mh->len;
+    if (btr < len)
+        return -1;
+
+#if defined(__GNUC__)
+    if (from)
+        *from = mh->source;
+#else
+    /* MSVC can't do the above */
+    if (from)
+	memcpy((void *) from, (void *) &(mh->source), sizeof(struct v4v_addr));
+#endif
+
+    if (protocol)
+        *protocol = mh->protocol;
+
+    rxp += sizeof (*mh);
+    if (rxp == r->len)
+        rxp = 0;
+    len -= sizeof (*mh);
+    ret = len;
+
+    bte = r->len - rxp;
+
+    if (bte < len)
+    {
+        if (t < bte)
+        {
+            if (buf)
+            {
+                memcpy (buf, (void *) &r->ring[rxp], t);
+                buf += t;
+            }
+
+            rxp = 0;
+            len -= bte;
+            t = 0;
+        }
+        else
+        {
+            if (buf)
+            {
+                memcpy (buf, (void *) &r->ring[rxp], bte);
+                buf += bte;
+            }
+            rxp = 0;
+            len -= bte;
+            t -= bte;
+        }
+    }
+
+    if (buf && t)
+        memcpy (buf, (void *) &r->ring[rxp], (t < len) ? t : len);
+
+
+    rxp += V4V_ROUNDUP (len);
+    if (rxp == r->len)
+        rxp = 0;
+
+    mb ();
+
+    if (consume)
+        r->rx_ptr = rxp;
+
+    return ret;
+}
+
+static V4V_INLINE void
+v4v_memcpy_skip (void *_dst, const void *_src, size_t len, size_t *skip)
+{
+    const uint8_t *src =  (const uint8_t *) _src;
+    uint8_t *dst = (uint8_t *) _dst;
+
+    if (!*skip)
+    {
+        memcpy (dst, src, len);
+        return;
+    }
+
+    if (*skip >= len)
+    {
+        *skip -= len;
+        return;
+    }
+
+    src += *skip;
+    dst += *skip;
+    len -= *skip;
+    *skip = 0;
+
+    memcpy (dst, src, len);
+}
+
+/*
+ * Copy at most t bytes of the next message in the ring, into the buffer
+ * at _buf, skipping skip bytes, setting from and protocol if they are not
+ * NULL, returns the actual length of the message, or -1 if there is
+ * nothing to read
+ */
+static ssize_t
+v4v_copy_out_offset (struct v4v_ring *r, struct v4v_addr *from,
+                     uint32_t * protocol, void *_buf, size_t t, int consume,
+                     size_t skip) V4V_UNUSED;
+
+V4V_INLINE static ssize_t
+v4v_copy_out_offset (struct v4v_ring *r, struct v4v_addr *from,
+                     uint32_t * protocol, void *_buf, size_t t, int consume,
+                     size_t skip)
+{
+    volatile struct v4v_ring_message_header *mh;
+    /* unnecessary cast from void * required by MSVC compiler */
+    uint8_t *buf = (uint8_t *) _buf;
+    uint32_t btr = v4v_ring_bytes_to_read (r);
+    uint32_t rxp = r->rx_ptr;
+    uint32_t bte;
+    uint32_t len;
+    ssize_t ret;
+
+    buf -= skip;
+
+    if (btr < sizeof (*mh))
+        return -1;
+
+    /*
+     * Becuase the message_header is 128 bits long and the ring is 128 bit
+     * aligned, we're gaurunteed never to wrap
+     */
+    mh = (volatile struct v4v_ring_message_header *) &r->ring[r->rx_ptr];
+
+    len = mh->len;
+    if (btr < len)
+        return -1;
+
+#if defined(__GNUC__)
+    if (from)
+        *from = mh->source;
+#else
+    /* MSVC can't do the above */
+    if (from)
+	memcpy((void *) from, (void *) &(mh->source), sizeof(struct v4v_addr));
+#endif
+
+    if (protocol)
+        *protocol = mh->protocol;
+
+    rxp += sizeof (*mh);
+    if (rxp == r->len)
+        rxp = 0;
+    len -= sizeof (*mh);
+    ret = len;
+
+    bte = r->len - rxp;
+
+    if (bte < len)
+    {
+        if (t < bte)
+        {
+            if (buf)
+            {
+                v4v_memcpy_skip (buf, (void *) &r->ring[rxp], t, &skip);
+                buf += t;
+            }
+
+            rxp = 0;
+            len -= bte;
+            t = 0;
+        }
+        else
+        {
+            if (buf)
+            {
+                v4v_memcpy_skip (buf, (void *) &r->ring[rxp], bte,
+                        &skip);
+                buf += bte;
+            }
+            rxp = 0;
+            len -= bte;
+            t -= bte;
+        }
+    }
+
+    if (buf && t)
+        v4v_memcpy_skip (buf, (void *) &r->ring[rxp], (t < len) ? t : len,
+                         &skip);
+
+
+    rxp += V4V_ROUNDUP (len);
+    if (rxp == r->len)
+        rxp = 0;
+
+    mb ();
+
+    if (consume)
+        r->rx_ptr = rxp;
+
+    return ret;
+}
+
+#endif /* V4V_EXCLUDE_UTILS */
+
+#endif /* __XEN_PUBLIC_V4V_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/public/xen.h b/xen/include/public/xen.h
index 033cbba..dce0338 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -99,7 +99,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
+#define __HYPERVISOR_v4v_op               39
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..457e3f2 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,6 +23,7 @@
 #include <public/sysctl.h>
 #include <public/vcpu.h>
 #include <public/mem_event.h>
+#include <xen/v4v.h>
 
 #ifdef CONFIG_COMPAT
 #include <compat/vcpu.h>
@@ -350,6 +351,10 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    rwlock_t v4v_lock;
+    struct v4v_domain *v4v;
 };
 
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..4325a03
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,109 @@
+/******************************************************************************
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/spinlock.h>
+#include <xen/smp.h>
+#include <xen/shared.h>
+#include <xen/list.h>
+#include <public/v4v.h>
+
+
+#define V4V_HTABLE_SIZE 32
+
+
+static inline uint16_t
+v4v_hash_fn (struct v4v_ring_id *id)
+{
+  uint16_t ret;
+  ret = (uint16_t) (id->addr.port >> 16);
+  ret ^= (uint16_t) id->addr.port;
+  ret ^= id->addr.domain;
+  ret ^= id->partner;
+
+  ret &= (V4V_HTABLE_SIZE-1);
+
+  return ret;
+}
+
+struct v4v_pending_ent
+{
+  struct hlist_node node;
+  domid_t id;
+  uint32_t len;
+};
+
+
+struct v4v_ring_info
+{
+  /* next node in the hash, protected by L2  */
+  struct hlist_node node;
+  /* this ring's id, protected by L2 */
+  struct v4v_ring_id id;
+  /* L3 */
+  spinlock_t lock;
+  /* cached length of the ring (from ring->len), protected by L3 */
+  uint32_t len;
+  uint32_t npage;
+  /* cached tx pointer location, protected by L3 */
+  uint32_t tx_ptr;
+  /* guest ring, protected by L3 */
+  XEN_GUEST_HANDLE(v4v_ring_t) ring;
+  /* mapped ring pages protected by L3*/
+  uint8_t **mfn_mapping;
+  /* list of mfns of guest ring */
+  mfn_t *mfns;
+  /* list of struct v4v_pending_ent for this ring, L3 */
+  struct hlist_head pending;
+};
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+struct v4v_domain
+{
+  /* L2 */
+  rwlock_t lock;
+  /* protected by L2 */
+  struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                XEN_GUEST_HANDLE (void) arg3,
+                uint32_t arg4,
+                uint32_t arg5);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjC-0004tu-St; Fri, 01 Jun 2012 11:09:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaNuM-0004kA-TC
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 09:12:35 +0000
Received: from [85.158.139.83:14710] by server-8.bemta-5.messagelabs.com id
	A4/33-25689-28788CF4; Fri, 01 Jun 2012 09:12:34 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338541950!30982923!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxNTM4ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10936 invoked from network); 1 Jun 2012 09:12:32 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 09:12:32 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 14:42:29 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 14:42:27 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q519CQOj2752962
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 14:42:26 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q51EgCeA005034
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 00:42:13 +1000
Received: from srivatsabhat.in.ibm.com (srivatsabhat.in.ibm.com [9.124.35.113])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q51EgClR005031; Sat, 2 Jun 2012 00:42:12 +1000
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: tglx@linutronix.de, peterz@infradead.org, paulmck@linux.vnet.ibm.com
Date: Fri, 01 Jun 2012 14:41:43 +0530
Message-ID: <20120601091136.31979.36213.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
User-Agent: StGIT/0.14.3
MIME-Version: 1.0
x-cbid: 12060109-5564-0000-0000-00000307D246
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	x86@kernel.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, vatsa@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, yong.zhang0@gmail.com,
	Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
	srivatsa.bhat@linux.vnet.ibm.com,
	"H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xensource.com,
	akpm@linux-foundation.org,
	virtualization@lists.linux-foundation.org, mingo@kernel.org
Subject: [Xen-devel] [PATCH 06/27] xen,
	smpboot: Use generic SMP booting infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Convert xen to use the generic framework to boot secondary CPUs.

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: linux-kernel@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---

 arch/x86/xen/smp.c |   21 ++++-----------------
 1 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 602d6b7..46c96f9 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -58,13 +58,12 @@ static irqreturn_t xen_reschedule_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static void __cpuinit cpu_bringup(void)
+void __cpuinit xen_cpu_pre_starting(void *unused)
 {
 	int cpu;
 
 	cpu_init();
 	touch_softlockup_watchdog();
-	preempt_disable();
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
@@ -75,25 +74,11 @@ static void __cpuinit cpu_bringup(void)
 	set_cpu_sibling_map(cpu);
 
 	xen_setup_cpu_clockevents();
-
-	notify_cpu_starting(cpu);
-
-	set_cpu_online(cpu, true);
-
-	this_cpu_write(cpu_state, CPU_ONLINE);
-
-	wmb();
-
-	/* We can take interrupts now: we're officially "up". */
-	local_irq_enable();
-
-	wmb();			/* make sure everything is out */
 }
 
 static void __cpuinit cpu_bringup_and_idle(void)
 {
-	cpu_bringup();
-	cpu_idle();
+	smpboot_start_secondary(NULL);
 }
 
 static int xen_smp_intr_init(unsigned int cpu)
@@ -515,6 +500,8 @@ static const struct smp_ops xen_smp_ops __initconst = {
 	.smp_prepare_cpus = xen_smp_prepare_cpus,
 	.smp_cpus_done = xen_smp_cpus_done,
 
+	.cpu_pre_starting = xen_cpu_pre_starting,
+
 	.cpu_up = xen_cpu_up,
 	.cpu_die = xen_cpu_die,
 	.cpu_disable = xen_cpu_disable,


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj9-0004rK-GF; Fri, 01 Jun 2012 11:09:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SZjDr-0000Ef-Gx
	for xen-devel@lists.xensource.com; Wed, 30 May 2012 13:45:59 +0000
Received: from [193.109.254.147:36384] by server-9.bemta-14.messagelabs.com id
	AE/8E-28098-69426CF4; Wed, 30 May 2012 13:45:58 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338385555!6857247!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA4MTA0MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15388 invoked from network); 30 May 2012 13:45:57 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 May 2012 13:45:57 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 May 2012 19:15:55 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 May 2012 19:15:51 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q4UDjoI22359736
	for <xen-devel@lists.xensource.com>; Wed, 30 May 2012 19:15:50 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q4UJFPeH032730
	for <xen-devel@lists.xensource.com>; Thu, 31 May 2012 00:45:27 +0530
Received: from [9.124.158.205] (codeblue.in.ibm.com [9.124.158.205])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q4UJFPn6032714; Thu, 31 May 2012 00:45:25 +0530
Message-ID: <4FC62458.7030802@linux.vnet.ibm.com>
Date: Wed, 30 May 2012 19:14:56 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com>
	<20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com>
	<4FC60A71.5050804@siemens.com>
In-Reply-To: <4FC60A71.5050804@siemens.com>
x-cbid: 12053013-8878-0000-0000-000002B81D9D
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Andi Kleen <andi@firstfloor.org>, KVM <kvm@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	X86 <x86@kernel.org>, linux-doc@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Avi Kivity <avi@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Attilio Rao <attilio.rao@citrix.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V8 17/17] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/30/2012 05:24 PM, Jan Kiszka wrote:
> On 2012-05-02 12:09, Raghavendra K T wrote:
>> From: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>
>> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in paravirtual spinlock
>> enabled guest.
>>
>> KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled
>> in guest.
>>
>> Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU
>
> This contains valuable documentation for features that are already
> supported. Can you break them out and post as separate patch already?
> One comment on them below.
>

That sounds like a good idea. Sure, will do that.

>>
>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> ---
>>   Documentation/virtual/kvm/cpuid.txt      |    4 ++
>>   Documentation/virtual/kvm/hypercalls.txt |   60 ++++++++++++++++++++++++++++++
>>   2 files changed, 64 insertions(+), 0 deletions(-)
>> diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
>> index 8820685..062dff9 100644
>> --- a/Documentation/virtual/kvm/cpuid.txt
>> +++ b/Documentation/virtual/kvm/cpuid.txt
>> @@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
>>   KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
>>                                      ||       || writing to msr 0x4b564d02
>>   ------------------------------------------------------------------------------
>> +KVM_FEATURE_PV_UNHALT              ||     6 || guest checks this feature bit
>> +                                   ||       || before enabling paravirtualized
>> +                                   ||       || spinlock support.
>> +------------------------------------------------------------------------------
>>   KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
>>                                      ||       || per-cpu warps are expected in
>>                                      ||       || kvmclock.
>> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
>> new file mode 100644
>> index 0000000..bc3f14a
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>> @@ -0,0 +1,60 @@
>> +KVM Hypercalls Documentation
>> +===========================
>> +The template for each hypercall is:
>> +1. Hypercall name, value.
>> +2. Architecture(s)
>> +3. Status (deprecated, obsolete, active)
>> +4. Purpose
>> +
>> +1. KVM_HC_VAPIC_POLL_IRQ
>> +------------------------
>> +Value: 1
>> +Architecture: x86
>> +Purpose: None
>
> Purpose: Trigger guest exit so that the host can check for pending
> interrupts on reentry.

will add fold this and resend.

[...]


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjB-0004su-Oa; Fri, 01 Jun 2012 11:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6fg-0004wT-6X
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:16 +0000
Received: from [85.158.143.35:10043] by server-2.bemta-4.messagelabs.com id
	DF/DE-11595-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338475692!18273743!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3471 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765940"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fd-0003WP-2b;
	Thu, 31 May 2012 14:48:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6jt-0006to-2S;
	Thu, 31 May 2012 15:52:37 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 31 May 2012 15:52:35 +0100
Message-ID: <1338475955-26472-6-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/v4v.c                   | 1779 ++++++++++++++++++++++++++++++++++++
 xen/include/public/v4v.h           |  544 +++++++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/v4v.h              |  109 +++
 11 files changed, 2461 insertions(+), 5 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0005-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0005-xen-Add-V4V-implementation.patch"

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..6f2d70e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3124,7 +3124,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] = {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
 
 #else /* defined(__x86_64__) */
@@ -3209,7 +3210,8 @@ static hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] = {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
 
 #define COMPAT_CALL(x)                                        \
@@ -3226,7 +3228,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] = {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
 
 #endif /* defined(__x86_64__) */
diff --git a/xen/arch/x86/x86_32/entry.S b/xen/arch/x86/x86_32/entry.S
index 2982679..b3e0da4 100644
--- a/xen/arch/x86/x86_32/entry.S
+++ b/xen/arch/x86/x86_32/entry.S
@@ -700,6 +700,7 @@ ENTRY(hypercall_table)
         .long do_domctl
         .long do_kexec_op
         .long do_tmem_op
+        .long do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/4)
         .long do_ni_hypercall
         .endr
@@ -748,6 +749,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec_op          */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index f49ff2d..28615f9 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 6 /* do_v4v_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 3836260..918fa59 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -699,6 +699,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -747,6 +748,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9eba8bc..fe3c72c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
+obj-y += v4v.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo,$(n).init.o)
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8840202..9539d88 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm = 1u<<0, INIT_watchdog = 1u<<1, INIT_rangeset = 1u<<2,
-           INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
+           INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5,
+           INIT_v4v = 1u<<6 };
     int init_status = 0;
     int poolid = CPUPOOLID_NONE;
 
@@ -219,6 +220,7 @@ struct domain *domain_create(
     spin_lock_init(&d->hypercall_deadlock_mutex);
     INIT_PAGE_LIST_HEAD(&d->page_list);
     INIT_PAGE_LIST_HEAD(&d->xenpage_list);
+    rwlock_init(&d->v4v_lock);
 
     spin_lock_init(&d->node_affinity_lock);
     d->node_affinity = NODE_MASK_ALL;
@@ -274,6 +276,10 @@ struct domain *domain_create(
             goto fail;
         init_status |= INIT_gnttab;
 
+        if ( v4v_init(d) != 0 )
+            goto fail;
+        init_status |= INIT_v4v;
+
         poolid = 0;
 
         d->mem_event = xzalloc(struct mem_event_per_domain);
@@ -313,6 +319,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -466,6 +474,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..ed846ba
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1779 @@
+/******************************************************************************
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#include <xen/config.h>
+#include <xen/mm.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/v4v.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <asm/paging.h>
+#include <asm/p2m.h>
+#include <xen/keyhandler.h>
+
+#ifdef V4V_DEBUG
+#define MY_FILE "v4v.c"
+#define v4v_dprintk(format, args...)                    \
+    do {                                                \
+        printk("%s:%d " format,                         \
+               MY_FILE, __LINE__, ## args );            \
+    } while ( 1 == 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+
+
+DEFINE_XEN_GUEST_HANDLE (uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info (struct domain *d,
+                                                 struct v4v_ring_id *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr (struct domain *d,
+                                                         struct v4v_addr *a,
+                                                         domid_t p);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK (v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void
+v4v_hexdump (void *_p, int len)
+{
+    uint8_t *buf = (uint8_t *) _p;
+    int i, j;
+
+    for (i = 0; i < len; i += 16)
+    {
+        printk (KERN_ERR "%p:", &buf[i]);
+        for (j = 0; j < 16; ++j)
+        {
+            int k = i + j;
+            if (k < len)
+                printk (" %02x", buf[k]);
+            else
+                printk ("   ");
+        }
+        printk (" ");
+
+        for (j = 0; j < 16; ++j)
+        {
+            int k = i + j;
+            if (k < len)
+                printk ("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k] : '.');
+            else
+                printk (" ");
+        }
+        printk ("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain (struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+    send_guest_vcpu_virq (d->vcpu[0], VIRQ_V4V);
+}
+
+static void
+v4v_signal_domid (domid_t id)
+{
+    struct domain *d = get_domain_by_id (id);
+    if (!d)
+        return;
+    v4v_signal_domain (d);
+    put_domain (d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+/* called must have L3 */
+static void
+v4v_ring_unmap (struct v4v_ring_info *ring_info)
+{
+    int i;
+    for (i = 0; i < ring_info->npage; ++i)
+    {
+        if (!ring_info->mfn_mapping[i])
+            continue;
+        v4v_dprintk("");
+        v4v_dprintk("unmapping page %p from %p\n",
+                (void*) mfn_x (ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+
+        unmap_domain_page (ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] = NULL;
+    }
+}
+
+/* called must have L3 */
+static uint8_t *
+v4v_ring_map_page (struct v4v_ring_info *ring_info, int i)
+{
+    if (i >= ring_info->npage)
+        return NULL;
+    if (ring_info->mfn_mapping[i])
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] = map_domain_page (mfn_x (ring_info->mfns[i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+            (void *) mfn_x (ring_info->mfns[i]),
+            ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_from_guest_ring (void *_dst, struct v4v_ring_info *ring_info,
+                            uint32_t offset, uint32_t len)
+{
+    int page = offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst = _dst;
+
+    offset &= PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        src = v4v_ring_map_page (ring_info, page);
+
+        if (!src)
+        {
+            return -EFAULT;
+        }
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                dst, src, offset,
+                (int) (PAGE_SIZE - offset));
+        memcpy (dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -= PAGE_SIZE - offset;
+        dst += PAGE_SIZE - offset;
+        offset = 0;
+    }
+
+    src = v4v_ring_map_page (ring_info, page);
+    if (!src)
+    {
+        return -EFAULT;
+    }
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy (dst, src + offset, len);
+
+    return 0;
+}
+
+
+/* called must have L3 */
+static int
+v4v_update_tx_ptr (struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst = v4v_ring_map_page (ring_info, 0);
+    volatile uint32_t *p = (uint32_t *)(dst + offsetof (v4v_ring_t, tx_ptr));
+
+    if (!dst)
+        return -EFAULT;
+    *p = tx_ptr;
+    return 0;
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_to_guest_ring (struct v4v_ring_info *ring_info, uint32_t offset,
+        void *_src, uint32_t len)
+{
+    int page = offset >> PAGE_SHIFT;
+    uint8_t *dst;
+    uint8_t *src = _src;
+
+    offset &= PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        dst = v4v_ring_map_page (ring_info, page);
+
+        if (!dst)
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+#ifdef V4V_DEBUG
+        v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+                dst, offset, src,
+                (int) (PAGE_SIZE - offset));
+        v4v_hexdump (src, PAGE_SIZE - offset);
+        v4v_hexdump (dst + offset, PAGE_SIZE - offset);
+#endif
+        memcpy (dst + offset, src, PAGE_SIZE - offset);
+
+        page++;
+        len -= (PAGE_SIZE - offset);
+        src += (PAGE_SIZE - offset);
+        offset = 0;
+    }
+
+    dst = v4v_ring_map_page (ring_info, page);
+
+    if (!dst)
+    {
+        v4v_dprintk("attempted to map page %d of %d\n", page, ring_info->npage);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+            dst, offset, src, len);
+    v4v_hexdump (src, len);
+    v4v_hexdump (dst + offset, len);
+#endif
+    memcpy (dst + offset, src, len);
+
+    return 0;
+}
+
+/*called must have L3*/
+static int
+v4v_memcpy_to_guest_ring_from_guest(struct v4v_ring_info *ring_info,
+                                    uint32_t offset,
+                                    XEN_GUEST_HANDLE (uint8_t) src_hnd,
+                                    uint32_t len)
+{
+    int page = offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    offset &= PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst = v4v_ring_map_page (ring_info, page);
+
+        if ( !dst )
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+        v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                    dst, offset, (void *) src_hnd.p,
+                    (int) (PAGE_SIZE - offset));
+        if ( copy_from_guest ((dst + offset), src_hnd, PAGE_SIZE - offset) )
+        {
+            v4v_dprintk("copy_from_guest failed\n");
+            return -EFAULT;
+        }
+
+        page++;
+        len -= PAGE_SIZE - offset;
+        guest_handle_add_offset (src_hnd, PAGE_SIZE - offset);
+        offset = 0;
+    }
+
+    dst = v4v_ring_map_page (ring_info, page);
+    if (!dst)
+    {
+        v4v_dprintk("v4v_ring_map failed\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                dst, offset, (void *) src_hnd.p, len);
+    if ( copy_from_guest ((dst + offset), src_hnd, len) )
+    {
+        v4v_dprintk("copy_from_guest failed\n");
+        return -EFAULT;
+    }
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr (struct domain *d, struct v4v_ring_info *ring_info,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage == 0 )
+        return -1;
+
+    ringp = map_domain_page (mfn_x (ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *) mfn_x (ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    *rx_ptr = *(volatile uint32_t *) &ringp->rx_ptr;
+
+    unmap_domain_page (mfn_x (ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space (struct domain * d, struct v4v_ring_info * ring_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr = ring_info->tx_ptr;
+    ring.len = ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=%d rx_ptr=%d\n",
+                (int) ring.tx_ptr, (int) ring.rx_ptr);
+    if ( ring.rx_ptr == ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret = ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret += ring.len;
+
+    ret -= sizeof (struct v4v_ring_message_header);
+    ret -= V4V_ROUNDUP (1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+/*caller must have L3*/
+static size_t
+v4v_ringbuf_insert (struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    struct v4v_ring_id *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE (void) buf_hnd_void, uint32_t len)
+{
+    XEN_GUEST_HANDLE (uint8_t) buf_hnd =
+        guest_handle_cast (buf_hnd_void, uint8_t);
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh = { 0 };
+    int32_t sp;
+    int32_t happy_ret = len;
+    int32_t ret = 0;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header)) >=
+            ring_info->len )
+    {
+        v4v_dprintk("EMSGSIZE\n");
+        return -EMSGSIZE;
+    }
+
+    do
+    {
+        if ( (ret = v4v_memcpy_from_guest_ring (&ring, ring_info,
+                                                0, sizeof (ring))) )
+            break;
+
+        ring.tx_ptr = ring_info->tx_ptr;
+        ring.len = ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=%d ring.rx_ptr=%d ring.len=%d ring_info->tx_ptr=%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_ptr);
+
+        if ( ring.rx_ptr == ring.tx_ptr )
+            sp = ring_info->len;
+        else
+        {
+            sp = ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp += ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header)) >= sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret = -EAGAIN;
+            break;
+        }
+
+        mh.len = len + sizeof (struct v4v_ring_message_header);
+        mh.source = src_id->addr;
+        mh.pad = 0;
+        mh.protocol = proto;
+
+        if ( (ret = v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr += sizeof (mh);
+        if ( ring.tx_ptr == ring_info->len )
+            ring.tx_ptr = 0;
+
+        sp = ring.len - ring.tx_ptr;
+
+        if ( len > sp )
+        {
+            if ((ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                            ring.tx_ptr + sizeof (v4v_ring_t),
+                            buf_hnd, sp)))
+                break;
+
+            ring.tx_ptr = 0;
+            len -= sp;
+            guest_handle_add_offset (buf_hnd, sp);
+        }
+
+        if ( (ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        buf_hnd, len)) )
+            break;
+
+        ring.tx_ptr += V4V_ROUNDUP (len);
+
+        if ( ring.tx_ptr == ring_info->len )
+            ring.tx_ptr = 0;
+
+        mb ();
+        ring_info->tx_ptr = ring.tx_ptr;
+
+        if ( (ret = v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+
+}
+
+static ssize_t
+v4v_iov_count (XEN_GUEST_HANDLE (v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret = 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest (&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret += iov.iov_len;
+        guest_handle_add_offset (iovs, 1);
+    }
+
+    return ret;
+}
+
+/*caller must have L3*/
+static ssize_t
+v4v_ringbuf_insertv (struct domain *d,
+                     struct v4v_ring_info *ring_info,
+                     struct v4v_ring_id *src_id, uint32_t proto,
+                     XEN_GUEST_HANDLE (v4v_iov_t) iovs, uint32_t niov,
+                     uint32_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh = { 0 };
+    int32_t sp;
+    int32_t happy_ret;
+    int32_t ret = 0;
+
+    happy_ret = len;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header) ) >=
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret = v4v_memcpy_from_guest_ring (&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr = ring_info->tx_ptr;
+        ring.len = ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=%d ring.rx_ptr=%d ring.len=%d ring_info->tx_ptr=%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_ptr);
+
+        if ( ring.rx_ptr == ring.tx_ptr )
+            sp = ring_info->len;
+        else
+        {
+            sp = ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp += ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header) ) >= sp)
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret = -EAGAIN;
+            break;
+        }
+
+        mh.len = len + sizeof (struct v4v_ring_message_header);
+        mh.source = src_id->addr;
+        mh.pad = 0;
+        mh.protocol = proto;
+
+        if ( (ret = v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr += sizeof (mh);
+        if ( ring.tx_ptr == ring_info->len )
+            ring.tx_ptr = 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE (uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest (&iov, iovs, 1) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            buf_hnd.p = (uint8_t *) iov.iov_base; //FIXME
+            len = iov.iov_len;
+
+            if ( unlikely (!guest_handle_okay (buf_hnd, len)) )
+            {
+                ret = -EFAULT;
+                break;
+            }
+
+            sp = ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                if ( (ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                                ring.tx_ptr +
+                                sizeof (v4v_ring_t),
+                                buf_hnd, sp)) )
+                    break;
+
+                ring.tx_ptr = 0;
+                len -= sp;
+                guest_handle_add_offset (buf_hnd, sp);
+            }
+
+            if ( (ret = v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                            ring.tx_ptr +
+                            sizeof (v4v_ring_t),
+                            buf_hnd, len)) )
+                break;
+
+            ring.tx_ptr += len;
+
+            if (ring.tx_ptr == ring_info->len)
+                ring.tx_ptr = 0;
+
+            guest_handle_add_offset (iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr = V4V_ROUNDUP (ring.tx_ptr);
+
+        if ( ring.tx_ptr >= ring_info->len )
+            ring.tx_ptr -= ring_info->len;
+
+        mb ();
+        ring_info->tx_ptr = ring.tx_ptr;
+        if ( (ret = v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent (struct v4v_pending_ent *ent)
+{
+    hlist_del (&ent->node);
+    xfree (ent);
+}
+
+/*caller must have L3 */
+static void
+v4v_pending_remove_all (struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent (pending_ent);
+}
+
+/*Caller must hold L1 */
+static void
+v4v_pending_notify (struct domain *caller_d, struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, to_notify, node)
+    {
+        hlist_del (&pending_ent->node);
+        v4v_signal_domid (pending_ent->id);
+        xfree (pending_ent);
+    }
+
+}
+
+/*caller must have R(L2) */
+static void
+v4v_pending_find (struct v4v_ring_info *ring_info, uint32_t payload_space,
+        struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    spin_lock (&ring_info->lock);
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, node)
+    {
+        if (payload_space >= ent->len)
+        {
+            hlist_del (&ent->node);
+            hlist_add_head (&ent->node, to_notify);
+        }
+    }
+    spin_unlock (&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue (struct v4v_ring_info *ring_info, domid_t src_id, int len)
+{
+    struct v4v_pending_ent *ent = xmalloc (struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len = len;
+    ent->id = src_id;
+
+    hlist_add_head (&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue (struct v4v_ring_info *ring_info, domid_t src_id, int len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry (ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id == src_id )
+        {
+            if ( ent->len < len )
+                ent->len = len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue (ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel (struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, node)
+    {
+        if ( ent->id == src_id)
+        {
+            hlist_del (&ent->node);
+            xfree (ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data (struct domain *src_d,
+                    XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest (&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=%d,ent.ring.port=%u\n",
+                (int) ent.ring.domain, (int) ent.ring.port);
+
+    ent.flags = 0;
+
+    dst_d = get_domain_by_id (ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock (&dst_d->v4v->lock);
+        ring_info = v4v_ring_find_info_by_addr (dst_d, &ent.ring,
+                                                src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |= V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =
+                ring_info->len - sizeof (struct v4v_ring_message_header) -
+                V4V_ROUNDUP (1);
+            spin_lock (&ring_info->lock);
+
+            space_avail = v4v_ringbuf_payload_space (dst_d, ring_info);
+
+            if ( space_avail >= ent.space_required )
+            {
+                v4v_pending_cancel (ring_info, src_d->domain_id);
+                ent.flags |= V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue (ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |= V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock (&ring_info->lock);
+
+            if ( space_avail == ent.max_message_size )
+                ent.flags |= V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain (dst_d);
+
+    if ( copy_field_to_guest (data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas (struct domain *d, int nent,
+                     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd)
+{
+    int ret = 0;
+
+    read_lock (&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret = v4v_fill_ring_data (d, data_ent_hnd);
+        guest_handle_add_offset (data_ent_hnd, 1);
+    }
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns (struct domain *d, struct v4v_ring_info *ring_info,
+                    XEN_GUEST_HANDLE (v4v_pfn_list_t) pfn_list_hnd)
+{
+    XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd;
+    v4v_pfn_list_t pfn_list;
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret = 0;
+
+    if ( copy_from_guest (&pfn_list, pfn_list_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    if (pfn_list.magic != V4V_PFN_LIST_MAGIC)
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    if ((pfn_list.npage << PAGE_SHIFT) < ring_info->len)
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    {
+        XEN_GUEST_HANDLE (uint8_t) slop_hnd =
+            guest_handle_cast (pfn_list_hnd, uint8_t);
+        guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
+        pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
+    }
+
+    mfns = xmalloc_array (mfn_t, pfn_list.npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping = xmalloc_array (uint8_t *, pfn_list.npage);
+    if ( !mfn_mapping )
+    {
+        xfree (mfns);
+        return -ENOMEM;
+    }
+
+    for (i = 0; i < pfn_list.npage; ++i)
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset (&pfn, pfn_hnd, i, 1) )
+        {
+            ret = -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn = mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret = -EINVAL;
+            break;
+        }
+        page = mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_mfn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret = -EINVAL;
+            break;
+        }
+        mfns[i] = _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long) pfn, (unsigned long) mfn_x (mfns[i]));
+        mfn_mapping[i] = NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage = pfn_list.npage;
+        ring_info->mfns = mfns;
+        ring_info->mfn_mapping = mfn_mapping;
+    }
+    else
+    {
+        j = i;
+        for ( i = 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) != 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree (mfn_mapping);
+        xfree (mfns);
+        v4v_dprintk("");
+    }
+    return ret;
+}
+
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info (struct domain *d, struct v4v_ring_id *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    hash = v4v_hash_fn (id);
+
+    v4v_dprintk("ring_find_info: d->v4v=%p, d->v4v->ring_hash[%d]=%p id=%p\n",
+                d->v4v, (int) hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=%d id.addr.domain=%d id.addr.partner=%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[hash], node)
+    {
+        if ( !memcmp (id, &ring_info->id, sizeof (*id)) )
+        {
+            v4v_dprintk("ring_find_info: ring_info=%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr (struct domain *d, struct v4v_addr *a, domid_t p)
+{
+    struct v4v_ring_id id;
+    struct v4v_ring_info *ret;
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port = a->port;
+    id.addr.domain = d->domain_id;
+    id.partner = p;
+
+    ret = v4v_ring_find_info (d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner = V4V_DOMID_NONE;
+
+    return v4v_ring_find_info (d, &id);
+}
+
+/*caller must hold W(L2) */
+static void v4v_ring_remove_mfns (struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    if ( ring_info->mfns )
+    {
+        for ( i=0; i < ring_info->npage; ++i )
+            if (mfn_x(ring_info->mfns[i]) != 0)
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i])));
+        xfree (ring_info->mfns);
+    }
+    ring_info->mfns = NULL;
+}
+
+/*caller must hold W(L2) */
+static void
+v4v_ring_remove_info (struct v4v_ring_info *ring_info)
+{
+    v4v_pending_remove_all (ring_info);
+
+    hlist_del (&ring_info->node);
+    v4v_ring_remove_mfns(ring_info);
+    xfree (ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret = 0;
+
+    read_lock (&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret = -EFAULT;
+            break;
+        }
+
+        if ( ring.magic != V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) != V4V_RING_MAGIC(%lx), EINVAL\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret = -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain = d->domain_id;
+
+        write_lock (&d->v4v->lock);
+        ring_info = v4v_ring_find_info (d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info (ring_info);
+
+        write_unlock (&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk( "ENOENT\n" );
+            ret = -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd,
+              XEN_GUEST_HANDLE (v4v_pfn_list_t) pfn_list_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert = 0;
+    int ret = 0;
+
+    if ( (long) ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret = -EFAULT;
+            break;
+        }
+
+        if ( ring.magic != V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) != V4V_RING_MAGIC(%lx), EINVAL\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret = -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUNDUP (1) +
+                     V4V_ROUNDUP (1))) || (V4V_ROUNDUP (ring.len) != ring.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain = d->domain_id;
+        if ( copy_field_to_guest (ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret = -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >= ring.len)
+                || (V4V_ROUNDUP (ring.tx_ptr) != ring.tx_ptr) )
+        {
+            ring.tx_ptr = ring.rx_ptr;
+        }
+        copy_field_to_guest (ring_hnd, &ring, tx_ptr);
+
+        read_lock (&d->v4v->lock);
+        ring_info = v4v_ring_find_info (d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock (&d->v4v->lock);
+            ring_info = xmalloc (struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret = -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init (&ring_info->lock);
+            INIT_HLIST_HEAD (&ring_info->pending);
+            ring_info->mfns = NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed. If mfn list was already
+             * populated remove the MFN's from list and then add
+             * the new list.
+             */
+            printk(KERN_INFO "v4v: dom%d re-registering existing ring, clearing MFN list\n",
+                    current->domain->domain_id);
+            v4v_ring_remove_mfns(ring_info);
+        }
+
+        spin_lock (&ring_info->lock);
+        ring_info->id = ring.id;
+        ring_info->len = ring.len;
+        ring_info->tx_ptr = ring.tx_ptr;
+        ring_info->ring = ring_hnd;
+        if ( ring_info->mfns )
+            xfree (ring_info->mfns);
+        ret = v4v_find_ring_mfns (d, ring_info, pfn_list_hnd);
+        spin_unlock (&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock (&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash = v4v_hash_fn (&ring.id);
+            write_lock (&d->v4v->lock);
+            hlist_add_head (&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock (&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+/*Caller must hold v4v_lock and hash_lock*/
+static void
+v4v_notify_ring (struct domain *d, struct v4v_ring_info *ring_info,
+        struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    spin_lock (&ring_info->lock);
+    space = v4v_ringbuf_payload_space (d, ring_info);
+    spin_unlock (&ring_info->lock);
+
+    v4v_pending_find (ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify (struct domain *d,
+            XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD (to_notify);
+    int i;
+    int ret = 0;
+
+    read_lock (&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock (&d->v4v->lock);
+    for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe (ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring (d, ring_info, &to_notify);
+        }
+    }
+    read_unlock (&d->v4v->lock);
+
+    if ( !hlist_empty (&to_notify) )
+    {
+        v4v_pending_notify (d, &to_notify);
+    }
+
+    do
+    {
+        if ( !guest_handle_is_null (ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest (&ring_data, ring_data_hnd, magic) )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret = -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic != V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) != V4V_RING_MAGIC(%lx), EINVAL\n",
+                            ring_data.magic, V4V_RING_MAGIC);
+                ret = -EINVAL;
+                break;
+            }
+
+            if (copy_from_guest (&ring_data, ring_data_hnd, 1))
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret = -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
+                XEN_GUEST_HANDLE (uint8_t) slop_hnd =
+                    guest_handle_cast (ring_data_hnd, uint8_t);
+                guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
+                ring_data_ent_hnd =
+                    guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
+                ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+
+    return ret;
+}
+
+
+
+/*Hypercall to do the send*/
+static size_t
+v4v_send (struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE (void) buf, size_t len)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret = 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port = src_addr->port;
+    src_id.addr.domain = src_d->domain_id;
+    src_id.partner = dst_addr->domain;
+
+    dst_d = get_domain_by_id (dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            ret = -ECONNREFUSED;
+            v4v_dprintk("!dst_d->v4v, ECONNREFUSED\n");
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domain);
+
+        if ( !ring_info )
+        {
+            ret = -ECONNREFUSED;
+            v4v_dprintk("!ring_info\n");
+        }
+        else
+        {
+            spin_lock (&ring_info->lock);
+            ret =
+                v4v_ringbuf_insert (dst_d, ring_info, &src_id, proto, buf, len);
+            if ( ret == -EAGAIN )
+            {
+                v4v_dprintk("ret == EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, len))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret = -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if (ret >= 0)
+            {
+                v4v_signal_domain (dst_d);
+            }
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*Hypercall to do the send*/
+static size_t
+v4v_sendv (struct domain *src_d, v4v_addr_t * src_addr,
+           v4v_addr_t * dst_addr, uint32_t proto,
+           XEN_GUEST_HANDLE (v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret = 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if (!src_d->v4v)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port = src_addr->port;
+    src_id.addr.domain = src_d->domain_id;
+    src_id.partner = dst_addr->domain;
+
+    dst_d = get_domain_by_id (dst_addr->domain);
+    if (!dst_d)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret = -ECONNREFUSED;
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domain);
+
+        if ( !ring_info )
+        {
+            ret = -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            uint32_t len = v4v_iov_count (iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret = len;
+                break;
+            }
+
+            spin_lock (&ring_info->lock);
+            ret =
+                v4v_ringbuf_insertv (dst_d, ring_info, &src_id, proto, iovs,
+                        niov, len);
+            if ( ret == -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, len))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret = -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if ( ret >= 0 )
+            {
+                v4v_signal_domain (dst_d);
+            }
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op (int cmd, XEN_GUEST_HANDLE (void) arg1,
+           XEN_GUEST_HANDLE (void) arg2,
+           XEN_GUEST_HANDLE (void) arg3, uint32_t arg4, uint32_t arg5)
+{
+    struct domain *d = current->domain;
+    long rc = -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%p,%d,%d)\n", cmd,
+                (void *) arg1.p, (void *) arg2.p, (void *) arg3.p,
+                (int) arg4, (int) arg5);
+
+    domain_lock (d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =
+                    guest_handle_cast (arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE (v4v_pfn_list_t) pfn_list_hnd =
+                    guest_handle_cast (arg2, v4v_pfn_list_t);
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                if ( unlikely (!guest_handle_okay (pfn_list_hnd, 1)) ) //FIXME
+                    goto out;
+                rc = v4v_ring_add (d, ring_hnd, pfn_list_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =
+                    guest_handle_cast (arg1, v4v_ring_t);
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                rc = v4v_ring_remove (d, ring_hnd);
+                break;
+            }
+        case V4VOP_send:
+            {
+                v4v_addr_t src, dst;
+                uint32_t len = arg4;
+                uint32_t protocol = arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =
+                    guest_handle_cast (arg2, v4v_addr_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                rc = v4v_send (d, &src, &dst, protocol, arg3, len);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                v4v_addr_t src, dst;
+                uint32_t niov = arg4;
+                uint32_t protocol = arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =
+                    guest_handle_cast (arg2, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_iov_t) iovs =
+                    guest_handle_cast (arg3, v4v_iov_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (iovs, niov)) )
+                    goto out;
+
+                rc = v4v_sendv (d, &src, &dst, protocol, iovs, niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd =
+                    guest_handle_cast (arg1, v4v_ring_data_t);
+                rc = v4v_notify (d, ring_data_hnd);
+                break;
+            }
+        default:
+            rc = -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock (d);
+    v4v_dprintk("<-do_v4v_op()=%d\n", (int) rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy (struct domain *d)
+{
+    int i;
+
+    BUG_ON (!d->is_dying);
+    write_lock (&v4v_lock);
+
+    v4v_dprintk("d->v=%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe (ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info (ring_info);
+            }
+        }
+    }
+
+    d->v4v = NULL;
+    write_unlock (&v4v_lock);
+}
+
+int
+v4v_init (struct domain *d)
+{
+    struct v4v_domain *v4v;
+    int i;
+
+    v4v = xmalloc (struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rwlock_init (&v4v->lock);
+
+    for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        INIT_HLIST_HEAD (&v4v->ring_hash[i]);
+    }
+
+    write_lock (&v4v_lock);
+    d->v4v = v4v;
+    write_unlock (&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring (struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk (KERN_ERR "  ring: domid=%d port=0x%08x partner=%d npage=%d\n",
+            (int) d->domain_id, (int) ring_info->id.addr.port,
+            (int) ring_info->id.partner, (int) ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &rx_ptr) )
+    {
+        printk (KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk (KERN_ERR "   tx_ptr=%d rx_ptr=%d len=%d\n",
+            (int) ring_info->tx_ptr, (int) rx_ptr, (int) ring_info->len);
+}
+
+static void
+dump_domain_rings (struct domain *d)
+{
+    int i;
+
+    printk (KERN_ERR " domain %d:\n", (int) d->domain_id);
+
+    read_lock (&d->v4v->lock);
+
+    for ( i = 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[i], node)
+            dump_domain_ring (d, ring_info);
+    }
+    read_unlock (&d->v4v->lock);
+
+    printk (KERN_ERR "\n");
+    v4v_signal_domain (d);
+}
+
+static void
+dump_rings (unsigned char key)
+{
+    struct domain *d;
+
+    printk (KERN_ERR "\n\nV4V ring dump:\n");
+    read_lock (&v4v_lock);
+
+    rcu_read_lock (&domlist_read_lock);
+
+    for_each_domain (d) dump_domain_rings (d);
+
+    rcu_read_unlock (&domlist_read_lock);
+
+    read_unlock (&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_rings,
+    .desc = "dump v4v ring states and intterupt"
+};
+
+static int __init
+setup_dump_rings (void)
+{
+    register_keyhandler ('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall (setup_dump_rings);
+
+
+/*
+ * 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/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..8cb02a8
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,544 @@
+/******************************************************************************
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+
+/*
+ * Compiler specific hacks
+ */
+#if !defined(__GNUC__)
+# define V4V_PACKED
+# define V4V_UNSUED
+# define V4V_INLINE __inline
+#else /* __GNUC__ */
+# define V4V_PACKED __attribute__ ((packed))
+# define V4V_UNUSED __attribute__ ((unused))
+# ifdef __XEN__
+#  define V4V_INLINE
+#  define V4V_VOLATILE
+# else
+#  define V4V_VOLATILE volatile
+#  ifndef __STRICT_ANSI__
+#   define V4V_INLINE inline
+#  else
+#   define V4V_INLINE
+#  endif
+# endif
+#endif /* __GNUC__ */
+
+#if !defined(__GNUC__)
+# pragma pack(push, 1)
+# pragma warning(push)
+# pragma warning(disable: 4200)
+#endif
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_PROTO_DGRAM		0x3c2c1db8
+#define V4V_PROTO_STREAM 	0x70f6a8e5
+
+#ifdef __i386__
+# define V4V_RING_MAGIC         0xdf6977f231abd910ULL
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302dULL
+#else
+# define V4V_RING_MAGIC         0xdf6977f231abd910
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302d
+#endif
+#define V4V_DOMID_INVALID       (0x7FFFU)
+#define V4V_DOMID_NONE          V4V_DOMID_INVALID
+#define V4V_DOMID_ANY           V4V_DOMID_INVALID
+#define V4V_PORT_NONE           0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint64_t iov_len;
+} V4V_PACKED v4v_iov_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+} V4V_PACKED v4v_addr_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+
+typedef struct v4v_ring_id
+{
+    struct v4v_addr addr;
+    domid_t partner;
+} V4V_PACKED v4v_ring_id_t;
+
+
+typedef uint64_t v4v_pfn_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
+
+typedef struct v4v_pfn_list_t
+{
+    uint64_t magic;
+    uint32_t npage;
+    uint32_t pad;
+    uint64_t reserved[3];
+    v4v_pfn_t pages[0];
+} V4V_PACKED v4v_pfn_list_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_list_t);
+
+
+typedef struct v4v_ring
+{
+    /* v4v magic number */
+    uint64_t magic;
+    /*
+     * id
+     *
+     * xen only looks at this during register/unregister
+     * and will fill in id.addr.domain
+     */
+    struct v4v_ring_id id;
+    /* length of ring[], must be a multiple of 8 */
+    uint32_t len;
+    /* rx pointer, modified by domain */
+    V4V_VOLATILE uint32_t rx_ptr;
+    /* tx pointer, modified by xen */
+    V4V_VOLATILE uint32_t tx_ptr;
+    /* padding */
+    uint64_t reserved[4];
+    /* ring */
+    V4V_VOLATILE uint8_t ring[0];
+} V4V_PACKED v4v_ring_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+
+#ifdef __i386__
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92aULL
+#else
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92a
+#endif
+
+#define V4V_RING_DATA_F_EMPTY       1U << 0 /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      1U << 1 /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     1U << 2 /* Pending interrupt exists - do not
+                                               rely on this field - for
+                                               profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  1U << 3 /* Sufficient space to queue
+                                               space_required bytes exists */
+
+typedef struct v4v_ring_data_ent
+{
+    struct v4v_addr ring;
+    uint16_t flags;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} V4V_PACKED v4v_ring_data_ent_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+    struct v4v_ring_data_ent data[0];
+} V4V_PACKED v4v_ring_data_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+
+
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+/* Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+} V4V_PACKED;
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    struct v4v_addr source;
+    uint16_t pad;
+    uint32_t protocol;
+    uint8_t data[0];
+} V4V_PACKED;
+
+
+/*
+ * HYPERCALLS
+ */
+
+#define V4VOP_register_ring 	1
+/*
+ * Registers a ring with Xen, if a ring with the same v4v_ring_id exists,
+ * this ring takes its place, registration will not change tx_ptr
+ * unless it is invalid
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t),
+ *           XEN_GUEST_HANDLE(v4v_pfn_list_t),
+ *           NULL, 0, 0)
+ */
+
+
+#define V4VOP_unregister_ring 	2
+/*
+ * Unregister a ring.
+ *
+ * v4v_hypercall(V4VOP_send, XEN_GUEST_HANDLE(v4v_ring_t), NULL, NULL, 0, 0)
+ */
+
+#define V4VOP_send 		3
+/*
+ * Sends len bytes of buf to dst, giving src as the source address (xen will
+ * ignore src->domain and put your domain in the actually message), xen
+ * first looks for a ring with id.addr==dst and id.partner==sending_domain
+ * if that fails it looks for id.addr==dst and id.partner==DOMID_ANY.
+ * protocol is the 32 bit protocol number used from the message
+ * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * v4v_hypercall(V4VOP_send,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) src,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) dst,
+ *               XEN_GUEST_HANDLE(void) buf,
+ *               uint32_t len,
+ *               uint32_t protocol)
+ */
+
+
+#define V4VOP_notify 		4
+/* Asks xen for information about other rings in the system
+ *
+ * v4v_ring_data_t contains an array of v4v_ring_data_ent_t
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is there
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * v4v_hypercall(V4VOP_notify,
+ *               XEN_GUEST_HANDLE(v4v_ring_data_t) buf,
+ *               NULL, NULL, 0, 0)
+ */
+
+
+#define V4VOP_sendv		5
+/*
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov_t and a length of the array.
+ *
+ * v4v_hypercall(V4VOP_sendv,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) src,
+ *               XEN_GUEST_HANDLE(v4v_addr_t) dst,
+ *               XEN_GUEST_HANDLE(v4v_iov_t),
+ *               UINT32_t niov,
+ *               uint32_t protocol)
+ */
+
+#if !defined(__GNUC__)
+# pragma warning(pop)
+# pragma pack(pop)
+#endif
+
+#if !defined(__GNUC__)
+static __inline void
+mb (void)
+{
+    _mm_mfence ();
+    _ReadWriteBarrier ();
+}
+#else
+#ifndef mb
+# define mb() __asm__ __volatile__ ("" ::: "memory");
+#endif
+#endif
+
+#if !defined(V4V_EXCLUDE_UTILS)
+
+/*************** Utility functions **************/
+
+static V4V_INLINE uint32_t
+v4v_ring_bytes_to_read (volatile struct v4v_ring *r)
+{
+    int32_t ret;
+    ret = r->tx_ptr - r->rx_ptr;
+    if (ret >= 0)
+        return ret;
+    return (uint32_t) (r->len + ret);
+}
+
+
+/*
+ * Copy at most t bytes of the next message in the ring, into the buffer
+ * at _buf, setting from and protocol if they are not NULL, returns
+ * the actual length of the message, or -1 if there is nothing to read
+ */
+V4V_UNUSED static V4V_INLINE ssize_t
+v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
+              void *_buf, size_t t, int consume)
+{
+    volatile struct v4v_ring_message_header *mh;
+    /* unnecessary cast from void * required by MSVC compiler */
+    uint8_t *buf = (uint8_t *) _buf;
+    uint32_t btr = v4v_ring_bytes_to_read (r);
+    uint32_t rxp = r->rx_ptr;
+    uint32_t bte;
+    uint32_t len;
+    ssize_t ret;
+
+
+    if (btr < sizeof (*mh))
+        return -1;
+
+    /*
+     * Becuase the message_header is 128 bits long and the ring is 128 bit
+     * aligned, we're gaurunteed never to wrap
+     */
+    mh = (volatile struct v4v_ring_message_header *) &r->ring[r->rx_ptr];
+
+    len = mh->len;
+    if (btr < len)
+        return -1;
+
+#if defined(__GNUC__)
+    if (from)
+        *from = mh->source;
+#else
+    /* MSVC can't do the above */
+    if (from)
+	memcpy((void *) from, (void *) &(mh->source), sizeof(struct v4v_addr));
+#endif
+
+    if (protocol)
+        *protocol = mh->protocol;
+
+    rxp += sizeof (*mh);
+    if (rxp == r->len)
+        rxp = 0;
+    len -= sizeof (*mh);
+    ret = len;
+
+    bte = r->len - rxp;
+
+    if (bte < len)
+    {
+        if (t < bte)
+        {
+            if (buf)
+            {
+                memcpy (buf, (void *) &r->ring[rxp], t);
+                buf += t;
+            }
+
+            rxp = 0;
+            len -= bte;
+            t = 0;
+        }
+        else
+        {
+            if (buf)
+            {
+                memcpy (buf, (void *) &r->ring[rxp], bte);
+                buf += bte;
+            }
+            rxp = 0;
+            len -= bte;
+            t -= bte;
+        }
+    }
+
+    if (buf && t)
+        memcpy (buf, (void *) &r->ring[rxp], (t < len) ? t : len);
+
+
+    rxp += V4V_ROUNDUP (len);
+    if (rxp == r->len)
+        rxp = 0;
+
+    mb ();
+
+    if (consume)
+        r->rx_ptr = rxp;
+
+    return ret;
+}
+
+static V4V_INLINE void
+v4v_memcpy_skip (void *_dst, const void *_src, size_t len, size_t *skip)
+{
+    const uint8_t *src =  (const uint8_t *) _src;
+    uint8_t *dst = (uint8_t *) _dst;
+
+    if (!*skip)
+    {
+        memcpy (dst, src, len);
+        return;
+    }
+
+    if (*skip >= len)
+    {
+        *skip -= len;
+        return;
+    }
+
+    src += *skip;
+    dst += *skip;
+    len -= *skip;
+    *skip = 0;
+
+    memcpy (dst, src, len);
+}
+
+/*
+ * Copy at most t bytes of the next message in the ring, into the buffer
+ * at _buf, skipping skip bytes, setting from and protocol if they are not
+ * NULL, returns the actual length of the message, or -1 if there is
+ * nothing to read
+ */
+static ssize_t
+v4v_copy_out_offset (struct v4v_ring *r, struct v4v_addr *from,
+                     uint32_t * protocol, void *_buf, size_t t, int consume,
+                     size_t skip) V4V_UNUSED;
+
+V4V_INLINE static ssize_t
+v4v_copy_out_offset (struct v4v_ring *r, struct v4v_addr *from,
+                     uint32_t * protocol, void *_buf, size_t t, int consume,
+                     size_t skip)
+{
+    volatile struct v4v_ring_message_header *mh;
+    /* unnecessary cast from void * required by MSVC compiler */
+    uint8_t *buf = (uint8_t *) _buf;
+    uint32_t btr = v4v_ring_bytes_to_read (r);
+    uint32_t rxp = r->rx_ptr;
+    uint32_t bte;
+    uint32_t len;
+    ssize_t ret;
+
+    buf -= skip;
+
+    if (btr < sizeof (*mh))
+        return -1;
+
+    /*
+     * Becuase the message_header is 128 bits long and the ring is 128 bit
+     * aligned, we're gaurunteed never to wrap
+     */
+    mh = (volatile struct v4v_ring_message_header *) &r->ring[r->rx_ptr];
+
+    len = mh->len;
+    if (btr < len)
+        return -1;
+
+#if defined(__GNUC__)
+    if (from)
+        *from = mh->source;
+#else
+    /* MSVC can't do the above */
+    if (from)
+	memcpy((void *) from, (void *) &(mh->source), sizeof(struct v4v_addr));
+#endif
+
+    if (protocol)
+        *protocol = mh->protocol;
+
+    rxp += sizeof (*mh);
+    if (rxp == r->len)
+        rxp = 0;
+    len -= sizeof (*mh);
+    ret = len;
+
+    bte = r->len - rxp;
+
+    if (bte < len)
+    {
+        if (t < bte)
+        {
+            if (buf)
+            {
+                v4v_memcpy_skip (buf, (void *) &r->ring[rxp], t, &skip);
+                buf += t;
+            }
+
+            rxp = 0;
+            len -= bte;
+            t = 0;
+        }
+        else
+        {
+            if (buf)
+            {
+                v4v_memcpy_skip (buf, (void *) &r->ring[rxp], bte,
+                        &skip);
+                buf += bte;
+            }
+            rxp = 0;
+            len -= bte;
+            t -= bte;
+        }
+    }
+
+    if (buf && t)
+        v4v_memcpy_skip (buf, (void *) &r->ring[rxp], (t < len) ? t : len,
+                         &skip);
+
+
+    rxp += V4V_ROUNDUP (len);
+    if (rxp == r->len)
+        rxp = 0;
+
+    mb ();
+
+    if (consume)
+        r->rx_ptr = rxp;
+
+    return ret;
+}
+
+#endif /* V4V_EXCLUDE_UTILS */
+
+#endif /* __XEN_PUBLIC_V4V_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/public/xen.h b/xen/include/public/xen.h
index 033cbba..dce0338 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -99,7 +99,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
+#define __HYPERVISOR_v4v_op               39
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..457e3f2 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,6 +23,7 @@
 #include <public/sysctl.h>
 #include <public/vcpu.h>
 #include <public/mem_event.h>
+#include <xen/v4v.h>
 
 #ifdef CONFIG_COMPAT
 #include <compat/vcpu.h>
@@ -350,6 +351,10 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    rwlock_t v4v_lock;
+    struct v4v_domain *v4v;
 };
 
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..4325a03
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,109 @@
+/******************************************************************************
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/spinlock.h>
+#include <xen/smp.h>
+#include <xen/shared.h>
+#include <xen/list.h>
+#include <public/v4v.h>
+
+
+#define V4V_HTABLE_SIZE 32
+
+
+static inline uint16_t
+v4v_hash_fn (struct v4v_ring_id *id)
+{
+  uint16_t ret;
+  ret = (uint16_t) (id->addr.port >> 16);
+  ret ^= (uint16_t) id->addr.port;
+  ret ^= id->addr.domain;
+  ret ^= id->partner;
+
+  ret &= (V4V_HTABLE_SIZE-1);
+
+  return ret;
+}
+
+struct v4v_pending_ent
+{
+  struct hlist_node node;
+  domid_t id;
+  uint32_t len;
+};
+
+
+struct v4v_ring_info
+{
+  /* next node in the hash, protected by L2  */
+  struct hlist_node node;
+  /* this ring's id, protected by L2 */
+  struct v4v_ring_id id;
+  /* L3 */
+  spinlock_t lock;
+  /* cached length of the ring (from ring->len), protected by L3 */
+  uint32_t len;
+  uint32_t npage;
+  /* cached tx pointer location, protected by L3 */
+  uint32_t tx_ptr;
+  /* guest ring, protected by L3 */
+  XEN_GUEST_HANDLE(v4v_ring_t) ring;
+  /* mapped ring pages protected by L3*/
+  uint8_t **mfn_mapping;
+  /* list of mfns of guest ring */
+  mfn_t *mfns;
+  /* list of struct v4v_pending_ent for this ring, L3 */
+  struct hlist_head pending;
+};
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+struct v4v_domain
+{
+  /* L2 */
+  rwlock_t lock;
+  /* protected by L2 */
+  struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                XEN_GUEST_HANDLE (void) arg3,
+                uint32_t arg4,
+                uint32_t arg5);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj8-0004qt-L4; Fri, 01 Jun 2012 11:09:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SZh3p-0003Oi-1m
	for xen-devel@lists.xensource.com; Wed, 30 May 2012 11:27:29 +0000
Received: from [193.109.254.147:39354] by server-6.bemta-14.messagelabs.com id
	A6/E6-10397-02406CF4; Wed, 30 May 2012 11:27:28 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338377244!4292711!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyOTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25260 invoked from network); 30 May 2012 11:27:27 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 May 2012 11:27:27 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 May 2012 11:21:25 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 May 2012 11:21:22 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q4UBK93a32243884
	for <xen-devel@lists.xensource.com>; Wed, 30 May 2012 21:20:09 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q4UBR9JR007111
	for <xen-devel@lists.xensource.com>; Wed, 30 May 2012 21:27:11 +1000
Received: from [9.124.158.205] (codeblue.in.ibm.com [9.124.158.205])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q4UBR4Hc007026; Wed, 30 May 2012 21:27:04 +1000
Message-ID: <4FC603D4.20107@linux.vnet.ibm.com>
Date: Wed, 30 May 2012 16:56:12 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com>
	<20120507082928.GI16608@gmail.com> <4FA7888F.80505@redhat.com>
	<4FA7AAD8.6050003@linux.vnet.ibm.com> <4FA7BABA.4040700@redhat.com>
	<4FA7CC05.50808@linux.vnet.ibm.com> <4FA7CCA2.4030408@redhat.com>
	<4FA7D06B.60005@linux.vnet.ibm.com>
	<20120507134611.GB5533@linux.vnet.ibm.com>
	<4FA7D2E5.1020607@redhat.com> <4FA7D3F7.9080005@linux.vnet.ibm.com>
	<4FA7D50D.1020209@redhat.com> <4FA7E06E.20304@linux.vnet.ibm.com>
	<4FA7E1C8.7010509@redhat.com> <4FB0014A.90604@linux.vnet.ibm.com>
	<4FB31CA4.5070908@linux.vnet.ibm.com>
In-Reply-To: <4FB31CA4.5070908@linux.vnet.ibm.com>
x-cbid: 12053001-7014-0000-0000-0000014457BC
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Andi Kleen <andi@firstfloor.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Gleb Natapov <gleb@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Attilio Rao <attilio.rao@citrix.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V8 0/17] Paravirtualized ticket 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-Transfer-Encoding: 7bit
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/16/2012 08:49 AM, Raghavendra K T wrote:
> On 05/14/2012 12:15 AM, Raghavendra K T wrote:
>> On 05/07/2012 08:22 PM, Avi Kivity wrote:
>>
>> I could not come with pv-flush results (also Nikunj had clarified that
>> the result was on NOn PLE
>>
>>> I'd like to see those numbers, then.
>>>
>>> Ingo, please hold on the kvm-specific patches, meanwhile.
[...]
> To summarise,
> with 32 vcpu guest with nr thread=32 we get around 27% improvement. In
> very low/undercommitted systems we may see very small improvement or
> small acceptable degradation ( which it deserves).
>

For large guests, current value SPIN_THRESHOLD, along with ple_window 
needed some of research/experiment.

[Thanks to Jeremy/Nikunj for inputs and help in result analysis ]

I started with debugfs spinlock/histograms, and ran experiments with 32, 
64 vcpu guests for spin threshold of 2k, 4k, 8k, 16k, and 32k with
1vm/2vm/4vm  for kernbench, sysbench, ebizzy, hackbench.
[ spinlock/histogram  gives logarithmic view of lockwait times ]

machine: PLE machine  with 32 cores.

Here is the result summary.
The summary includes 2 part,
(1) %improvement w.r.t 2K spin threshold,
(2) improvement w.r.t sum of histogram numbers in debugfs (that gives 
rough indication of contention/cpu time wasted)

  For e.g 98% for 4k threshold kbench 1 vm would imply, there is a 98% 
reduction in sigma(histogram values) compared to 2k case

Result for 32 vcpu guest
==========================
+----------------+-----------+-----------+-----------+-----------+
|    Base-2k     |     4k    |    8k     |   16k     |    32k    |
+----------------+-----------+-----------+-----------+-----------+
|     kbench-1vm |       44  |       50  |       46  |       41  |
|  SPINHisto-1vm |       98  |       99  |       99  |       99  |
|     kbench-2vm |       25  |       45  |       49  |       45  |
|  SPINHisto-2vm |       31  |       91  |       99  |       99  |
|     kbench-4vm |      -13  |      -27  |       -2  |       -4  |
|  SPINHisto-4vm |       29  |       66  |       95  |       99  |
+----------------+-----------+-----------+-----------+-----------+
|     ebizzy-1vm |      954  |      942  |      913  |      915  |
|  SPINHisto-1vm |       96  |       99  |       99  |       99  |
|     ebizzy-2vm |      158  |      135  |      123  |      106  |
|  SPINHisto-2vm |       90  |       98  |       99  |       99  |
|     ebizzy-4vm |      -13  |      -28  |      -33  |      -37  |
|  SPINHisto-4vm |       83  |       98  |       99  |       99  |
+----------------+-----------+-----------+-----------+-----------+
|     hbench-1vm |       48  |       56  |       52  |       64  |
|  SPINHisto-1vm |       92  |       95  |       99  |       99  |
|     hbench-2vm |       32  |       40  |       39  |       21  |
|  SPINHisto-2vm |       74  |       96  |       99  |       99  |
|     hbench-4vm |       27  |       15  |        3  |      -57  |
|  SPINHisto-4vm |       68  |       88  |       94  |       97  |
+----------------+-----------+-----------+-----------+-----------+
|    sysbnch-1vm |        0  |        0  |        1  |        0  |
|  SPINHisto-1vm |       76  |       98  |       99  |       99  |
|    sysbnch-2vm |       -1  |        3  |       -1  |       -4  |
|  SPINHisto-2vm |       82  |       94  |       96  |       99  |
|    sysbnch-4vm |        0  |       -2  |       -8  |      -14  |
|  SPINHisto-4vm |       57  |       79  |       88  |       95  |
+----------------+-----------+-----------+-----------+-----------+

result for 64  vcpu guest
=========================
+----------------+-----------+-----------+-----------+-----------+
|    Base-2k     |     4k    |    8k     |   16k     |    32k    |
+----------------+-----------+-----------+-----------+-----------+
|     kbench-1vm |        1  |      -11  |      -25  |       31  |
|  SPINHisto-1vm |        3  |       10  |       47  |       99  |
|     kbench-2vm |       15  |       -9  |      -66  |      -15  |
|  SPINHisto-2vm |        2  |       11  |       19  |       90  |
+----------------+-----------+-----------+-----------+-----------+
|     ebizzy-1vm |      784  |     1097  |      978  |      930  |
|  SPINHisto-1vm |       74  |       97  |       98  |       99  |
|     ebizzy-2vm |       43  |       48  |       56  |       32  |
|  SPINHisto-2vm |       58  |       93  |       97  |       98  |
+----------------+-----------+-----------+-----------+-----------+
|     hbench-1vm |        8  |       55  |       56  |       62  |
|  SPINHisto-1vm |       18  |       69  |       96  |       99  |
|     hbench-2vm |       13  |      -14  |      -75  |      -29  |
|  SPINHisto-2vm |       57  |       74  |       80  |       97  |
+----------------+-----------+-----------+-----------+-----------+
|    sysbnch-1vm |        9  |       11  |       15  |       10  |
|  SPINHisto-1vm |       80  |       93  |       98  |       99  |
|    sysbnch-2vm |        3  |        3  |        4  |        2  |
|  SPINHisto-2vm |       72  |       89  |       94  |       97  |
+----------------+-----------+-----------+-----------+-----------+

 From this, value around 4k-8k threshold seem to be optimal one. [ This 
is amost inline with ple_window default ]
(lower the spin threshold, we would cover lesser % of spinlocks, that 
would result in more halt_exit/wakeups.

[ www.xen.org/files/xensummitboston08/LHP.pdf also has good graphical 
detail on covering spinlock waits ]

After 8k threshold, we see no more contention but that would mean we 
have wasted lot of cpu time in busy waits.

Will get a PLE machine again, and 'll continue experimenting with 
further tuning of SPIN_THRESHOLD.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjA-0004s4-L8; Fri, 01 Jun 2012 11:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wU-Ls
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:20698] by server-3.bemta-4.messagelabs.com id
	BB/87-04252-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338475693!15666854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6968 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765937"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:12 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WG-GJ;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006tf-Fb;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 31 May 2012 15:52:32 +0100
Message-ID: <1338475955-26472-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] xen: Add headers to include/Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


  Add stdlib.h for size_t
  Add string.h for memcpy
  Add sys/types.h for ssize_t

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-Add-headers-to-include-Makefile.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-xen-Add-headers-to-include-Makefile.patch"

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 62846a1..67aaef4 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -77,8 +77,9 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
 all: headers.chk
 
+INCLUDE_LIBS=stdint.h stdlib.h string.h sys/types.h
 headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
-	for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W -Werror -S -o /dev/null -xc $$i || exit 1; echo $$i; done >$@.new
+	for i in $(filter %.h,$^); do $(CC) -ansi ${INCLUDE_LIBS:%.h=-include %.h} -Wall -W -Werror -S -o /dev/null -xc $$i || exit 1; echo $$i; done >$@.new
 	mv $@.new $@
 
 endif

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPj8-0004qt-L4; Fri, 01 Jun 2012 11:09:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SZh3p-0003Oi-1m
	for xen-devel@lists.xensource.com; Wed, 30 May 2012 11:27:29 +0000
Received: from [193.109.254.147:39354] by server-6.bemta-14.messagelabs.com id
	A6/E6-10397-02406CF4; Wed, 30 May 2012 11:27:28 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338377244!4292711!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyOTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25260 invoked from network); 30 May 2012 11:27:27 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 May 2012 11:27:27 -0000
Received: from /spool/local
	by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 30 May 2012 11:21:25 +1000
Received: from d23relay04.au.ibm.com (202.81.31.246)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 30 May 2012 11:21:22 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q4UBK93a32243884
	for <xen-devel@lists.xensource.com>; Wed, 30 May 2012 21:20:09 +1000
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q4UBR9JR007111
	for <xen-devel@lists.xensource.com>; Wed, 30 May 2012 21:27:11 +1000
Received: from [9.124.158.205] (codeblue.in.ibm.com [9.124.158.205])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q4UBR4Hc007026; Wed, 30 May 2012 21:27:04 +1000
Message-ID: <4FC603D4.20107@linux.vnet.ibm.com>
Date: Wed, 30 May 2012 16:56:12 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com>
	<20120507082928.GI16608@gmail.com> <4FA7888F.80505@redhat.com>
	<4FA7AAD8.6050003@linux.vnet.ibm.com> <4FA7BABA.4040700@redhat.com>
	<4FA7CC05.50808@linux.vnet.ibm.com> <4FA7CCA2.4030408@redhat.com>
	<4FA7D06B.60005@linux.vnet.ibm.com>
	<20120507134611.GB5533@linux.vnet.ibm.com>
	<4FA7D2E5.1020607@redhat.com> <4FA7D3F7.9080005@linux.vnet.ibm.com>
	<4FA7D50D.1020209@redhat.com> <4FA7E06E.20304@linux.vnet.ibm.com>
	<4FA7E1C8.7010509@redhat.com> <4FB0014A.90604@linux.vnet.ibm.com>
	<4FB31CA4.5070908@linux.vnet.ibm.com>
In-Reply-To: <4FB31CA4.5070908@linux.vnet.ibm.com>
x-cbid: 12053001-7014-0000-0000-0000014457BC
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Andi Kleen <andi@firstfloor.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Gleb Natapov <gleb@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Attilio Rao <attilio.rao@citrix.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Subject: Re: [Xen-devel] [PATCH RFC V8 0/17] Paravirtualized ticket 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-Transfer-Encoding: 7bit
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/16/2012 08:49 AM, Raghavendra K T wrote:
> On 05/14/2012 12:15 AM, Raghavendra K T wrote:
>> On 05/07/2012 08:22 PM, Avi Kivity wrote:
>>
>> I could not come with pv-flush results (also Nikunj had clarified that
>> the result was on NOn PLE
>>
>>> I'd like to see those numbers, then.
>>>
>>> Ingo, please hold on the kvm-specific patches, meanwhile.
[...]
> To summarise,
> with 32 vcpu guest with nr thread=32 we get around 27% improvement. In
> very low/undercommitted systems we may see very small improvement or
> small acceptable degradation ( which it deserves).
>

For large guests, current value SPIN_THRESHOLD, along with ple_window 
needed some of research/experiment.

[Thanks to Jeremy/Nikunj for inputs and help in result analysis ]

I started with debugfs spinlock/histograms, and ran experiments with 32, 
64 vcpu guests for spin threshold of 2k, 4k, 8k, 16k, and 32k with
1vm/2vm/4vm  for kernbench, sysbench, ebizzy, hackbench.
[ spinlock/histogram  gives logarithmic view of lockwait times ]

machine: PLE machine  with 32 cores.

Here is the result summary.
The summary includes 2 part,
(1) %improvement w.r.t 2K spin threshold,
(2) improvement w.r.t sum of histogram numbers in debugfs (that gives 
rough indication of contention/cpu time wasted)

  For e.g 98% for 4k threshold kbench 1 vm would imply, there is a 98% 
reduction in sigma(histogram values) compared to 2k case

Result for 32 vcpu guest
==========================
+----------------+-----------+-----------+-----------+-----------+
|    Base-2k     |     4k    |    8k     |   16k     |    32k    |
+----------------+-----------+-----------+-----------+-----------+
|     kbench-1vm |       44  |       50  |       46  |       41  |
|  SPINHisto-1vm |       98  |       99  |       99  |       99  |
|     kbench-2vm |       25  |       45  |       49  |       45  |
|  SPINHisto-2vm |       31  |       91  |       99  |       99  |
|     kbench-4vm |      -13  |      -27  |       -2  |       -4  |
|  SPINHisto-4vm |       29  |       66  |       95  |       99  |
+----------------+-----------+-----------+-----------+-----------+
|     ebizzy-1vm |      954  |      942  |      913  |      915  |
|  SPINHisto-1vm |       96  |       99  |       99  |       99  |
|     ebizzy-2vm |      158  |      135  |      123  |      106  |
|  SPINHisto-2vm |       90  |       98  |       99  |       99  |
|     ebizzy-4vm |      -13  |      -28  |      -33  |      -37  |
|  SPINHisto-4vm |       83  |       98  |       99  |       99  |
+----------------+-----------+-----------+-----------+-----------+
|     hbench-1vm |       48  |       56  |       52  |       64  |
|  SPINHisto-1vm |       92  |       95  |       99  |       99  |
|     hbench-2vm |       32  |       40  |       39  |       21  |
|  SPINHisto-2vm |       74  |       96  |       99  |       99  |
|     hbench-4vm |       27  |       15  |        3  |      -57  |
|  SPINHisto-4vm |       68  |       88  |       94  |       97  |
+----------------+-----------+-----------+-----------+-----------+
|    sysbnch-1vm |        0  |        0  |        1  |        0  |
|  SPINHisto-1vm |       76  |       98  |       99  |       99  |
|    sysbnch-2vm |       -1  |        3  |       -1  |       -4  |
|  SPINHisto-2vm |       82  |       94  |       96  |       99  |
|    sysbnch-4vm |        0  |       -2  |       -8  |      -14  |
|  SPINHisto-4vm |       57  |       79  |       88  |       95  |
+----------------+-----------+-----------+-----------+-----------+

result for 64  vcpu guest
=========================
+----------------+-----------+-----------+-----------+-----------+
|    Base-2k     |     4k    |    8k     |   16k     |    32k    |
+----------------+-----------+-----------+-----------+-----------+
|     kbench-1vm |        1  |      -11  |      -25  |       31  |
|  SPINHisto-1vm |        3  |       10  |       47  |       99  |
|     kbench-2vm |       15  |       -9  |      -66  |      -15  |
|  SPINHisto-2vm |        2  |       11  |       19  |       90  |
+----------------+-----------+-----------+-----------+-----------+
|     ebizzy-1vm |      784  |     1097  |      978  |      930  |
|  SPINHisto-1vm |       74  |       97  |       98  |       99  |
|     ebizzy-2vm |       43  |       48  |       56  |       32  |
|  SPINHisto-2vm |       58  |       93  |       97  |       98  |
+----------------+-----------+-----------+-----------+-----------+
|     hbench-1vm |        8  |       55  |       56  |       62  |
|  SPINHisto-1vm |       18  |       69  |       96  |       99  |
|     hbench-2vm |       13  |      -14  |      -75  |      -29  |
|  SPINHisto-2vm |       57  |       74  |       80  |       97  |
+----------------+-----------+-----------+-----------+-----------+
|    sysbnch-1vm |        9  |       11  |       15  |       10  |
|  SPINHisto-1vm |       80  |       93  |       98  |       99  |
|    sysbnch-2vm |        3  |        3  |        4  |        2  |
|  SPINHisto-2vm |       72  |       89  |       94  |       97  |
+----------------+-----------+-----------+-----------+-----------+

 From this, value around 4k-8k threshold seem to be optimal one. [ This 
is amost inline with ple_window default ]
(lower the spin threshold, we would cover lesser % of spinlocks, that 
would result in more halt_exit/wakeups.

[ www.xen.org/files/xensummitboston08/LHP.pdf also has good graphical 
detail on covering spinlock waits ]

After 8k threshold, we see no more contention but that would mean we 
have wasted lot of cpu time in busy waits.

Will get a PLE machine again, and 'll continue experimenting with 
further tuning of SPIN_THRESHOLD.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPjA-0004s4-L8; Fri, 01 Jun 2012 11:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sa6ff-0004wU-Ls
	for xen-devel@lists.xen.org; Thu, 31 May 2012 14:48:15 +0000
Received: from [85.158.143.35:20698] by server-3.bemta-4.messagelabs.com id
	BB/87-04252-FA487CF4; Thu, 31 May 2012 14:48:15 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338475693!15666854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA0OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6968 invoked from network); 31 May 2012 14:48:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 May 2012 14:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="12765937"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 May 2012 14:48:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 31 May 2012 15:48:12 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1Sa6fc-0003WG-GJ;
	Thu, 31 May 2012 14:48:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sa6js-0006tf-Fb;
	Thu, 31 May 2012 15:52:36 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 31 May 2012 15:52:32 +0100
Message-ID: <1338475955-26472-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
References: <1338475955-26472-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
X-Mailman-Approved-At: Fri, 01 Jun 2012 11:09:05 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] xen: Add headers to include/Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


  Add stdlib.h for size_t
  Add string.h for memcpy
  Add sys/types.h for ssize_t

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-Add-headers-to-include-Makefile.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-xen-Add-headers-to-include-Makefile.patch"

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 62846a1..67aaef4 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -77,8 +77,9 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
 all: headers.chk
 
+INCLUDE_LIBS=stdint.h stdlib.h string.h sys/types.h
 headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
-	for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W -Werror -S -o /dev/null -xc $$i || exit 1; echo $$i; done >$@.new
+	for i in $(filter %.h,$^); do $(CC) -ansi ${INCLUDE_LIBS:%.h=-include %.h} -Wall -W -Werror -S -o /dev/null -xc $$i || exit 1; echo $$i; done >$@.new
 	mv $@.new $@
 
 endif

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

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

--------------true--


From xen-devel-bounces@lists.xen.org Fri Jun 01 11:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaPjd-0005Od-74; Fri, 01 Jun 2012 11: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 1SaPjc-0005NF-44
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:09:36 +0000
Received: from [193.109.254.147:30592] by server-12.bemta-14.messagelabs.com
	id FE/CB-12643-FE2A8CF4; Fri, 01 Jun 2012 11:09:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1338548975!12421887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 1 Jun 2012 11:09:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:09:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 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.213.0; Fri, 1 Jun 2012
	12:09:34 +0100
Message-ID: <1338548973.17466.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 12:09:33 +0100
In-Reply-To: <1338548680.31901.57.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
	<1338547664.31901.54.camel@Abyss>
	<1338547835.17466.82.camel@zakaz.uk.xensource.com>
	<1338548680.31901.57.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 12:04 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 11:50 +0100, Ian Campbell wrote: 
> > > Ok, with that "physical" you're putting there, I see and agree it could
> > > be useful untie it from the "virtual world". :-)
> > 
> > Is that an ACK for this and/or the previous patch?
> > 
> Oh, yes, sorry for being a bit cryptic. For what my opinion counts, it
> is. :-)

Everyone's Ack is worthwhile.

I'll add:
        Acked-by: Dario Faggioli <Dario.Faggioli@citrix.com>
Please do supply the actual string (for formalities sake) next 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 Jun 01 11:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaPjd-0005Od-74; Fri, 01 Jun 2012 11: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 1SaPjc-0005NF-44
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:09:36 +0000
Received: from [193.109.254.147:30592] by server-12.bemta-14.messagelabs.com
	id FE/CB-12643-FE2A8CF4; Fri, 01 Jun 2012 11:09:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1338548975!12421887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 1 Jun 2012 11:09:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:09:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 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.213.0; Fri, 1 Jun 2012
	12:09:34 +0100
Message-ID: <1338548973.17466.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 1 Jun 2012 12:09:33 +0100
In-Reply-To: <1338548680.31901.57.camel@Abyss>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338532541.31901.10.camel@Abyss>
	<A9667DDFB95DB7438FA9D7D576C3D87E162970@SHSMSX101.ccr.corp.intel.com>
	<1338540279.31901.17.camel@Abyss>
	<1338541118.17466.36.camel@zakaz.uk.xensource.com>
	<1338543157.31901.27.camel@Abyss>
	<1338543666.17466.55.camel@zakaz.uk.xensource.com>
	<1338546187.31901.45.camel@Abyss>
	<1338547136.17466.77.camel@zakaz.uk.xensource.com>
	<1338547664.31901.54.camel@Abyss>
	<1338547835.17466.82.camel@zakaz.uk.xensource.com>
	<1338548680.31901.57.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 12:04 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 11:50 +0100, Ian Campbell wrote: 
> > > Ok, with that "physical" you're putting there, I see and agree it could
> > > be useful untie it from the "virtual world". :-)
> > 
> > Is that an ACK for this and/or the previous patch?
> > 
> Oh, yes, sorry for being a bit cryptic. For what my opinion counts, it
> is. :-)

Everyone's Ack is worthwhile.

I'll add:
        Acked-by: Dario Faggioli <Dario.Faggioli@citrix.com>
Please do supply the actual string (for formalities sake) next 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 Jun 01 11:14:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPoZ-0007YB-KG; Fri, 01 Jun 2012 11:14:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SaPoY-0007Y2-Up
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:14:43 +0000
Received: from [193.109.254.147:38074] by server-6.bemta-14.messagelabs.com id
	9A/66-10397-224A8CF4; Fri, 01 Jun 2012 11:14:42 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1338549280!5505333!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6334 invoked from network); 1 Jun 2012 11:14:41 -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;
	1 Jun 2012 11:14:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197175420"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 07:14:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 07:14:39 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SaPoV-0006sr-NJ;
	Fri, 01 Jun 2012 12:14:39 +0100
Message-ID: <4FC8A41F.6040201@citrix.com>
Date: Fri, 1 Jun 2012 12:14:39 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com>
In-Reply-To: <4FC89556.7090502@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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/06/12 11:11, George Dunlap wrote:
> On 01/06/12 09:29, Ian Campbell wrote:
>> >  On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>> >>  On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>> >>  <George.Dunlap@eu.citrix.com>   wrote:
>>>> >>>  The strange thing is that there*is*  a pygrub in the right place, so
>>>> >>>  it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>> >>  It's seems that the right on the script are already set to 755 by the
>>> >>  setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>> >  What is the conclusion here? Is the original patch correct and/or is
>> >  there a subsequent additional fix?
> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
> fixes the bug (only installed in $(DESTDIR).
>
> I think there is a redundant command in the Makefile as well, where
> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
> incorrect behavior, but I would probably still consider it a bug.
>
> So the original patch is correct, but there is a subsequent fix.

I'll send a patch that remove this extra line as the pygrub script is 
copied by setup.py.

-- 
Anthony PERARD

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:14:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPoZ-0007YB-KG; Fri, 01 Jun 2012 11:14:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SaPoY-0007Y2-Up
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:14:43 +0000
Received: from [193.109.254.147:38074] by server-6.bemta-14.messagelabs.com id
	9A/66-10397-224A8CF4; Fri, 01 Jun 2012 11:14:42 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1338549280!5505333!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6334 invoked from network); 1 Jun 2012 11:14:41 -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;
	1 Jun 2012 11:14:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197175420"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 07:14:40 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 07:14:39 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SaPoV-0006sr-NJ;
	Fri, 01 Jun 2012 12:14:39 +0100
Message-ID: <4FC8A41F.6040201@citrix.com>
Date: Fri, 1 Jun 2012 12:14:39 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com>
In-Reply-To: <4FC89556.7090502@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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-Transfer-Encoding: 7bit
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/06/12 11:11, George Dunlap wrote:
> On 01/06/12 09:29, Ian Campbell wrote:
>> >  On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>> >>  On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>> >>  <George.Dunlap@eu.citrix.com>   wrote:
>>>> >>>  The strange thing is that there*is*  a pygrub in the right place, so
>>>> >>>  it appears that thefollowing line ($INSTALL_PYTHON_PROG) is redundant?
>>> >>  It's seems that the right on the script are already set to 755 by the
>>> >>  setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>> >  What is the conclusion here? Is the original patch correct and/or is
>> >  there a subsequent additional fix?
> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
> fixes the bug (only installed in $(DESTDIR).
>
> I think there is a redundant command in the Makefile as well, where
> pygrub will be copied to $(DESTDIR)/foo twice.  That doesn't cause
> incorrect behavior, but I would probably still consider it a bug.
>
> So the original patch is correct, but there is a subsequent fix.

I'll send a patch that remove this extra line as the pygrub script is 
copied by setup.py.

-- 
Anthony PERARD

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPtt-0007hP-DQ; Fri, 01 Jun 2012 11: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 1SaPtr-0007hK-OI
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:20:11 +0000
Received: from [85.158.139.83:57879] by server-9.bemta-5.messagelabs.com id
	0B/53-27779-B65A8CF4; Fri, 01 Jun 2012 11:20:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338549609!28847590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5343 invoked from network); 1 Jun 2012 11:20:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:20:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:20:09 +0100
Message-ID: <1338549608.17466.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bamvor Jian Zhang <bjzhang@suse.com>
Date: Fri, 1 Jun 2012 12:20:08 +0100
In-Reply-To: <3496f86000b80595b34a.1338535311@linux-x12>
References: <3496f86000b80595b34a.1338535311@linux-x12>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
> This api retrieve domain console from xenstore. With this new api, it is easy to implement "virsh console" command in libvirt libxl driver.
> 
> Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
> 
> Changes since v2:
>  * using ERROR_INVAL instead of ERROR_FAIL in libxl_console_get_tty and
>  libxl__primary_console_find if need.
>  * remove _out from some value name in libxl_primary_console_exec
>  * add error handler and log message in libxl_console_get_tty.
>  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0, tty) will lead to null pointer access in CTX maco.
>  * add empty line between my comment and other function.
> 
> diff -r d7318231cfe3 -r 3496f86000b8 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu May 31 10:18:52 2012 +0200
> +++ b/tools/libxl/libxl.c	Fri Jun 01 15:10:45 2012 +0800
> @@ -1188,7 +1188,8 @@ out:
>      return rc;
>  }
>  
> -int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
> +int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
> +                       libxl_console_type type)
>  {
>      GC_INIT(ctx);
>      char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
> @@ -1214,25 +1215,82 @@ out:
>      return ERROR_FAIL;
>  }
>  
> -int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
> +int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> +                          libxl_console_type type, char **path)
> +{
> +    GC_INIT(ctx);
> +    char *dom_path = 0;
> +    char *tty_path = 0;
> +    char *tty = 0;

Is the compiler giving false positives about using these without
initialising them?

Otherwise these initialisations are simply hiding what would a useful
warning from the compiler.

Or is there some deliberate path by which these can be used without
first being set to something explicit?

> +    int rc;
> +
> +    dom_path = libxl__xs_get_dompath(gc, domid);
> +    if (!dom_path) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    switch (type) {
> +    case LIBXL_CONSOLE_TYPE_SERIAL:
> +        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
> +        break;
> +    case LIBXL_CONSOLE_TYPE_PV:
> +        if (cons_num == 0)
> +            tty_path = GCSPRINTF("%s/console/tty", dom_path);
> +        else
> +            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
> +                                cons_num);
> +        break;
> +    default:
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +
> +    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
> +    if (!tty) {
> +       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
> +       rc = ERROR_FAIL;
> +       goto out;
> +    }
> +
> +    *path = strdup(tty);
> +    if (!*path)
> +        libxl__alloc_failed(CTX, __func__, strlen(*path), 1);
> +
> +    rc = 0;
> +
> +out:
> +    GC_FREE;
> +    return rc;
> +}
> +
> +static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
> +                                       uint32_t *domid, int *cons_num, 
> +                                       libxl_console_type *type)
>  {
>      GC_INIT(ctx);
>      uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
> -    int rc;
> -    if (stubdomid)
> -        rc = libxl_console_exec(ctx, stubdomid,
> -                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
> -    else {
> +    int rc = 0;

This initialisation also potentially hides errors, I think. Better to
explicitly set in the cases where we succeed.

> +
> +    if (stubdomid) {
> +        *domid = stubdomid;
> +        *cons_num = STUBDOM_CONSOLE_SERIAL;
> +        *type = LIBXL_CONSOLE_TYPE_PV;
> +    } else {
>          switch (libxl__domain_type(gc, domid_vm)) {
>          case LIBXL_DOMAIN_TYPE_HVM:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_SERIAL;
>              break;
>          case LIBXL_DOMAIN_TYPE_PV:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_PV;
>              break;
>          case -1:
> -            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
> -            rc = ERROR_FAIL;
> +            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
> +            rc = ERROR_INVAL;
>              break;
>          default:
>              abort();
> @@ -1242,6 +1300,31 @@ int libxl_primary_console_exec(libxl_ctx
>      return rc;
>  }
>  


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11: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 1SaPtt-0007hP-DQ; Fri, 01 Jun 2012 11: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 1SaPtr-0007hK-OI
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:20:11 +0000
Received: from [85.158.139.83:57879] by server-9.bemta-5.messagelabs.com id
	0B/53-27779-B65A8CF4; Fri, 01 Jun 2012 11:20:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338549609!28847590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5343 invoked from network); 1 Jun 2012 11:20:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:20:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:20:09 +0100
Message-ID: <1338549608.17466.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bamvor Jian Zhang <bjzhang@suse.com>
Date: Fri, 1 Jun 2012 12:20:08 +0100
In-Reply-To: <3496f86000b80595b34a.1338535311@linux-x12>
References: <3496f86000b80595b34a.1338535311@linux-x12>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 08:21 +0100, Bamvor Jian Zhang wrote:
> This api retrieve domain console from xenstore. With this new api, it is easy to implement "virsh console" command in libvirt libxl driver.
> 
> Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
> 
> Changes since v2:
>  * using ERROR_INVAL instead of ERROR_FAIL in libxl_console_get_tty and
>  libxl__primary_console_find if need.
>  * remove _out from some value name in libxl_primary_console_exec
>  * add error handler and log message in libxl_console_get_tty.
>  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0, tty) will lead to null pointer access in CTX maco.
>  * add empty line between my comment and other function.
> 
> diff -r d7318231cfe3 -r 3496f86000b8 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu May 31 10:18:52 2012 +0200
> +++ b/tools/libxl/libxl.c	Fri Jun 01 15:10:45 2012 +0800
> @@ -1188,7 +1188,8 @@ out:
>      return rc;
>  }
>  
> -int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
> +int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
> +                       libxl_console_type type)
>  {
>      GC_INIT(ctx);
>      char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
> @@ -1214,25 +1215,82 @@ out:
>      return ERROR_FAIL;
>  }
>  
> -int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
> +int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> +                          libxl_console_type type, char **path)
> +{
> +    GC_INIT(ctx);
> +    char *dom_path = 0;
> +    char *tty_path = 0;
> +    char *tty = 0;

Is the compiler giving false positives about using these without
initialising them?

Otherwise these initialisations are simply hiding what would a useful
warning from the compiler.

Or is there some deliberate path by which these can be used without
first being set to something explicit?

> +    int rc;
> +
> +    dom_path = libxl__xs_get_dompath(gc, domid);
> +    if (!dom_path) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    switch (type) {
> +    case LIBXL_CONSOLE_TYPE_SERIAL:
> +        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
> +        break;
> +    case LIBXL_CONSOLE_TYPE_PV:
> +        if (cons_num == 0)
> +            tty_path = GCSPRINTF("%s/console/tty", dom_path);
> +        else
> +            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
> +                                cons_num);
> +        break;
> +    default:
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +
> +    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
> +    if (!tty) {
> +       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
> +       rc = ERROR_FAIL;
> +       goto out;
> +    }
> +
> +    *path = strdup(tty);
> +    if (!*path)
> +        libxl__alloc_failed(CTX, __func__, strlen(*path), 1);
> +
> +    rc = 0;
> +
> +out:
> +    GC_FREE;
> +    return rc;
> +}
> +
> +static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
> +                                       uint32_t *domid, int *cons_num, 
> +                                       libxl_console_type *type)
>  {
>      GC_INIT(ctx);
>      uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
> -    int rc;
> -    if (stubdomid)
> -        rc = libxl_console_exec(ctx, stubdomid,
> -                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
> -    else {
> +    int rc = 0;

This initialisation also potentially hides errors, I think. Better to
explicitly set in the cases where we succeed.

> +
> +    if (stubdomid) {
> +        *domid = stubdomid;
> +        *cons_num = STUBDOM_CONSOLE_SERIAL;
> +        *type = LIBXL_CONSOLE_TYPE_PV;
> +    } else {
>          switch (libxl__domain_type(gc, domid_vm)) {
>          case LIBXL_DOMAIN_TYPE_HVM:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_SERIAL;
>              break;
>          case LIBXL_DOMAIN_TYPE_PV:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_PV;
>              break;
>          case -1:
> -            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
> -            rc = ERROR_FAIL;
> +            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
> +            rc = ERROR_INVAL;
>              break;
>          default:
>              abort();
> @@ -1242,6 +1300,31 @@ int libxl_primary_console_exec(libxl_ctx
>      return rc;
>  }
>  


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaPuf-0007kS-Rg; Fri, 01 Jun 2012 11:21: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 1SaPue-0007kG-BO
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:21:00 +0000
Received: from [85.158.143.35:6888] by server-1.bemta-4.messagelabs.com id
	9C/8A-27869-B95A8CF4; Fri, 01 Jun 2012 11:20:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338549656!15819511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4509 invoked from network); 1 Jun 2012 11:20:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:20:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:20:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 12:20:55 +0100
Date: Fri, 1 Jun 2012 12:20:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FC88DFF.70807@citrix.com>
Message-ID: <alpine.DEB.2.00.1206011218310.26786@kaball-desktop>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<4FC88DFF.70807@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Roger Pau Monne wrote:
> * qemu-upstream for NetBSD: I'm currently working on this. It compiles 
> but VGA memory mapping seems to be wrong, and qemu gets a segfault when 
> trying to write to it.

You might have to check the implementation of xc_domain_add_to_physmap
on NetBSD. On the QEMU side xen_add_to_physmap is the relevant function.
However I cannot see how it would be different from
qemu-xen-traditional.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaPuf-0007kS-Rg; Fri, 01 Jun 2012 11:21: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 1SaPue-0007kG-BO
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:21:00 +0000
Received: from [85.158.143.35:6888] by server-1.bemta-4.messagelabs.com id
	9C/8A-27869-B95A8CF4; Fri, 01 Jun 2012 11:20:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338549656!15819511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4509 invoked from network); 1 Jun 2012 11:20:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:20:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12784859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:20:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 12:20:55 +0100
Date: Fri, 1 Jun 2012 12:20:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FC88DFF.70807@citrix.com>
Message-ID: <alpine.DEB.2.00.1206011218310.26786@kaball-desktop>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<4FC88DFF.70807@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Roger Pau Monne wrote:
> * qemu-upstream for NetBSD: I'm currently working on this. It compiles 
> but VGA memory mapping seems to be wrong, and qemu gets a segfault when 
> trying to write to it.

You might have to check the implementation of xc_domain_add_to_physmap
on NetBSD. On the QEMU side xen_add_to_physmap is the relevant function.
However I cannot see how it would be different from
qemu-xen-traditional.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:26:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:26: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 1SaPzd-0007yn-Hs; Fri, 01 Jun 2012 11:26:09 +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 1SaPzc-0007yi-Rz
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:26:08 +0000
Received: from [85.158.143.99:36689] by server-1.bemta-4.messagelabs.com id
	50/74-27869-0D6A8CF4; Fri, 01 Jun 2012 11:26:08 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338549965!30881506!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20202 invoked from network); 1 Jun 2012 11:26:07 -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 Jun 2012 11:26:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26517178"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 07:26:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 07:26:04 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SaPzY-0007AJ-IO;
	Fri, 01 Jun 2012 12:26:04 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Fri, 1 Jun 2012 12:26:03 +0100
Message-ID: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] pygrub Makefile cleanup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch removes the extra command `install pygrub` because this is already
done by the setup.py script.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
This patch need to be applied after the patch named "Fix pygrub install."

 tools/pygrub/Makefile |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
index af2b8a5..bd22dd4 100644
--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -13,7 +13,6 @@ install: all
 	CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \
 		$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
 		--install-scripts=$(PRIVATE_BINDIR) --force
-	$(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub
 	$(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot
 	ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR)
 
-- 
Anthony PERARD

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:26:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:26: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 1SaPzd-0007yn-Hs; Fri, 01 Jun 2012 11:26:09 +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 1SaPzc-0007yi-Rz
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 11:26:08 +0000
Received: from [85.158.143.99:36689] by server-1.bemta-4.messagelabs.com id
	50/74-27869-0D6A8CF4; Fri, 01 Jun 2012 11:26:08 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338549965!30881506!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20202 invoked from network); 1 Jun 2012 11:26:07 -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 Jun 2012 11:26:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26517178"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 07:26:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 07:26:04 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SaPzY-0007AJ-IO;
	Fri, 01 Jun 2012 12:26:04 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Fri, 1 Jun 2012 12:26:03 +0100
Message-ID: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] pygrub Makefile cleanup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch removes the extra command `install pygrub` because this is already
done by the setup.py script.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
This patch need to be applied after the patch named "Fix pygrub install."

 tools/pygrub/Makefile |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
index af2b8a5..bd22dd4 100644
--- a/tools/pygrub/Makefile
+++ b/tools/pygrub/Makefile
@@ -13,7 +13,6 @@ install: all
 	CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \
 		$(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
 		--install-scripts=$(PRIVATE_BINDIR) --force
-	$(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub
 	$(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot
 	ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR)
 
-- 
Anthony PERARD

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:45:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:45: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 1SaQHs-0008Ha-8X; Fri, 01 Jun 2012 11:45: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 1SaQHr-0008HV-DU
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:44:59 +0000
Received: from [85.158.139.83:24296] by server-11.bemta-5.messagelabs.com id
	CE/55-12711-A3BA8CF4; Fri, 01 Jun 2012 11:44:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1338551096!31594954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1491 invoked from network); 1 Jun 2012 11:44:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12785364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:44:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:44:55 +0100
Message-ID: <1338551094.17466.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 1 Jun 2012 12:44:54 +0100
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 03:48 +0100, Zhang, Yang Z wrote:
> Change from v2:
> Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> According to Ian's comments, modified some codes to make the logic more reasonable.
> 
> In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
> In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> 
> diff -r 3b0eed731020 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
> @@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(
> 
>      if (!b_info->max_vcpus)
>          b_info->max_vcpus = 1;
> -    if (!b_info->cur_vcpus)
> -        b_info->cur_vcpus = 1;
> +    if (!b_info->avail_vcpus.size) {
> +        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
> +            return ERROR_FAIL;
> +        libxl_cpumap_set(&b_info->avail_vcpus, 0);
> +    }
> 
>      if (!b_info->cpumap.size) {
>          if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
> diff -r 3b0eed731020 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
> @@ -160,6 +160,8 @@ static char ** libxl__build_device_model
>      }
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_vifs = 0;
> +        int nr_set_cpus = 0;
> +        char *s;
> 
>          if (b_info->u.hvm.serial) {
>              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
> @@ -200,11 +202,14 @@ static char ** libxl__build_device_model
>                                libxl__sprintf(gc, "%d", b_info->max_vcpus),
>                                NULL);
>          }
> -        if (b_info->cur_vcpus) {
> -            flexarray_vappend(dm_args, "-vcpu_avail",
> -                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
> -                              NULL);
> -        }
> +
> +        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
> +        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
> +        flexarray_vappend(dm_args, "-vcpu_avail",
> +                libxl__sprintf(gc, "0x%s", s),

You might as well make to_hex_string include the 0x?

> +                NULL);
> +        free(s);
> +
>          for (i = 0; i < num_vifs; i++) {
>              if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
>                  char *smac = libxl__sprintf(gc,
> diff -r 3b0eed731020 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
> @@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
>      ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
> +        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus, i))
>                              ? "offline" : "online";

Weren't you going to drop the "i &&" and invert the ternary?

>      }
> 
> @@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
>      va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
>      va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
>      va_hvm->nr_vcpus = info->max_vcpus;
> -    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
> +    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);

This needs some sort of limit check, probably in terms of HVM_MAX_VCPUS.
otherwise a particularly large vcpus= in the config will cause mayhem...

I guess this should probably be done in
libxl__domain_build_info_setdefaults.

> diff -r 3b0eed731020 tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
> @@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
>      cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
>  }
> 
> +int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
> +{
> +    int i, nr_set_cpus = 0;
> +    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))

Please stop this habit of yours of casting away the const to make the
warning go away, it is almost always wrong and on the odd occasion that
it is right it should have a comment explaining why...

In this case please make libxl_cpumap_test const correct instead.

> +        nr_set_cpus++;
> +
> +    return nr_set_cpus;
> +}
> +
> +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
> +{
> +    int i = cpumap->size;
> +    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
> +    char *q = p;
> +    while(--i >= 0) {
> +        sprintf((char *)p, "%02x", cpumap->map[i]);

Why this cast?

> +        p += 2;
> +    }
> +    *p = '\0';
> +    return q;
> +}
> +
>  int libxl_get_max_cpus(libxl_ctx *ctx)
>  {
>      return xc_get_max_cpus(ctx->xch);
> diff -r 3b0eed731020 tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
> @@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
>  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> +int libxl_cpumap_count_set(const libxl_cpumap *cpumap);

Please add a comment describing this function, it should remind the
caller that they are responsible for freeing the result.

> +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
>  static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
>  {
>      memset(cpumap->map, -1, cpumap->size);
> diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> @@ -650,7 +650,14 @@ static void parse_config_data(const char
> 
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
> -        b_info->cur_vcpus = (1 << l) - 1;
> +
> +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> +            fprintf(stderr, "Unable to allocate cpumap\n");
> +            exit(1);
> +        }
> +        libxl_cpumap_set_none(&b_info->avail_vcpus);
> +        while (l-- > 0)
> +            libxl_cpumap_set((&b_info->avail_vcpus), l);

This while loop is == libxl_cpumap_set_any.

>      }
> 
>      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 11:45:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 11:45: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 1SaQHs-0008Ha-8X; Fri, 01 Jun 2012 11:45: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 1SaQHr-0008HV-DU
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 11:44:59 +0000
Received: from [85.158.139.83:24296] by server-11.bemta-5.messagelabs.com id
	CE/55-12711-A3BA8CF4; Fri, 01 Jun 2012 11:44:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1338551096!31594954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1491 invoked from network); 1 Jun 2012 11:44:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 11:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12785364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:44:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	12:44:55 +0100
Message-ID: <1338551094.17466.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 1 Jun 2012 12:44:54 +0100
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 03:48 +0100, Zhang, Yang Z wrote:
> Change from v2:
> Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> According to Ian's comments, modified some codes to make the logic more reasonable.
> 
> In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
> In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> 
> diff -r 3b0eed731020 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
> @@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(
> 
>      if (!b_info->max_vcpus)
>          b_info->max_vcpus = 1;
> -    if (!b_info->cur_vcpus)
> -        b_info->cur_vcpus = 1;
> +    if (!b_info->avail_vcpus.size) {
> +        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
> +            return ERROR_FAIL;
> +        libxl_cpumap_set(&b_info->avail_vcpus, 0);
> +    }
> 
>      if (!b_info->cpumap.size) {
>          if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
> diff -r 3b0eed731020 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
> @@ -160,6 +160,8 @@ static char ** libxl__build_device_model
>      }
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          int ioemu_vifs = 0;
> +        int nr_set_cpus = 0;
> +        char *s;
> 
>          if (b_info->u.hvm.serial) {
>              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
> @@ -200,11 +202,14 @@ static char ** libxl__build_device_model
>                                libxl__sprintf(gc, "%d", b_info->max_vcpus),
>                                NULL);
>          }
> -        if (b_info->cur_vcpus) {
> -            flexarray_vappend(dm_args, "-vcpu_avail",
> -                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
> -                              NULL);
> -        }
> +
> +        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
> +        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
> +        flexarray_vappend(dm_args, "-vcpu_avail",
> +                libxl__sprintf(gc, "0x%s", s),

You might as well make to_hex_string include the 0x?

> +                NULL);
> +        free(s);
> +
>          for (i = 0; i < num_vifs; i++) {
>              if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
>                  char *smac = libxl__sprintf(gc,
> diff -r 3b0eed731020 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
> @@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
>      ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
> +        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus, i))
>                              ? "offline" : "online";

Weren't you going to drop the "i &&" and invert the ternary?

>      }
> 
> @@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
>      va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
>      va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
>      va_hvm->nr_vcpus = info->max_vcpus;
> -    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
> +    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);

This needs some sort of limit check, probably in terms of HVM_MAX_VCPUS.
otherwise a particularly large vcpus= in the config will cause mayhem...

I guess this should probably be done in
libxl__domain_build_info_setdefaults.

> diff -r 3b0eed731020 tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
> @@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
>      cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
>  }
> 
> +int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
> +{
> +    int i, nr_set_cpus = 0;
> +    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))

Please stop this habit of yours of casting away the const to make the
warning go away, it is almost always wrong and on the odd occasion that
it is right it should have a comment explaining why...

In this case please make libxl_cpumap_test const correct instead.

> +        nr_set_cpus++;
> +
> +    return nr_set_cpus;
> +}
> +
> +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
> +{
> +    int i = cpumap->size;
> +    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
> +    char *q = p;
> +    while(--i >= 0) {
> +        sprintf((char *)p, "%02x", cpumap->map[i]);

Why this cast?

> +        p += 2;
> +    }
> +    *p = '\0';
> +    return q;
> +}
> +
>  int libxl_get_max_cpus(libxl_ctx *ctx)
>  {
>      return xc_get_max_cpus(ctx->xch);
> diff -r 3b0eed731020 tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
> @@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
>  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> +int libxl_cpumap_count_set(const libxl_cpumap *cpumap);

Please add a comment describing this function, it should remind the
caller that they are responsible for freeing the result.

> +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
>  static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
>  {
>      memset(cpumap->map, -1, cpumap->size);
> diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> @@ -650,7 +650,14 @@ static void parse_config_data(const char
> 
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
> -        b_info->cur_vcpus = (1 << l) - 1;
> +
> +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> +            fprintf(stderr, "Unable to allocate cpumap\n");
> +            exit(1);
> +        }
> +        libxl_cpumap_set_none(&b_info->avail_vcpus);
> +        while (l-- > 0)
> +            libxl_cpumap_set((&b_info->avail_vcpus), l);

This while loop is == libxl_cpumap_set_any.

>      }
> 
>      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 12:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 12:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaQjF-0000yZ-HH; Fri, 01 Jun 2012 12:13:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SaQjE-0000yR-Ck
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 12:13:16 +0000
Received: from [85.158.139.83:31309] by server-12.bemta-5.messagelabs.com id
	09/75-18374-BD1B8CF4; Fri, 01 Jun 2012 12:13:15 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1338552793!27588999!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11225 invoked from network); 1 Jun 2012 12:13:14 -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;
	1 Jun 2012 12:13:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197179784"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:13:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 08:13:06 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaQj3-0008M2-W6;
	Fri, 01 Jun 2012 13:13:06 +0100
Message-ID: <4FC8B1D1.1080801@citrix.com>
Date: Fri, 1 Jun 2012 13:13:05 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<4FC88DFF.70807@citrix.com>
	<alpine.DEB.2.00.1206011218310.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1206011218310.26786@kaball-desktop>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stabellini wrote:
> On Fri, 1 Jun 2012, Roger Pau Monne wrote:
>> * qemu-upstream for NetBSD: I'm currently working on this. It compiles
>> but VGA memory mapping seems to be wrong, and qemu gets a segfault when
>> trying to write to it.
>
> You might have to check the implementation of xc_domain_add_to_physmap
> on NetBSD. On the QEMU side xen_add_to_physmap is the relevant function.
> However I cannot see how it would be different from
> qemu-xen-traditional.

Well my description was not completely accurate, when the memory address 
is retrieved for the first time (vga.c:2225), qemu can write to it, but 
after some point (don't know exactly yet), the userspace process looses 
access to that memory region, and gets a segfault.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 12:13:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 12:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaQjF-0000yZ-HH; Fri, 01 Jun 2012 12:13:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SaQjE-0000yR-Ck
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 12:13:16 +0000
Received: from [85.158.139.83:31309] by server-12.bemta-5.messagelabs.com id
	09/75-18374-BD1B8CF4; Fri, 01 Jun 2012 12:13:15 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1338552793!27588999!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11225 invoked from network); 1 Jun 2012 12:13:14 -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;
	1 Jun 2012 12:13:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197179784"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 08:13:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 08:13:06 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SaQj3-0008M2-W6;
	Fri, 01 Jun 2012 13:13:06 +0100
Message-ID: <4FC8B1D1.1080801@citrix.com>
Date: Fri, 1 Jun 2012 13:13:05 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<4FC88DFF.70807@citrix.com>
	<alpine.DEB.2.00.1206011218310.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1206011218310.26786@kaball-desktop>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stabellini wrote:
> On Fri, 1 Jun 2012, Roger Pau Monne wrote:
>> * qemu-upstream for NetBSD: I'm currently working on this. It compiles
>> but VGA memory mapping seems to be wrong, and qemu gets a segfault when
>> trying to write to it.
>
> You might have to check the implementation of xc_domain_add_to_physmap
> on NetBSD. On the QEMU side xen_add_to_physmap is the relevant function.
> However I cannot see how it would be different from
> qemu-xen-traditional.

Well my description was not completely accurate, when the memory address 
is retrieved for the first time (vga.c:2225), qemu can write to it, but 
after some point (don't know exactly yet), the userspace process looses 
access to that memory region, and gets a segfault.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 12:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 12:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaRB4-0001T0-5m; Fri, 01 Jun 2012 12:42:02 +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 1SaRB2-0001Sv-Nn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 12:42:00 +0000
Received: from [193.109.254.147:14156] by server-3.bemta-14.messagelabs.com id
	B5/83-15022-898B8CF4; Fri, 01 Jun 2012 12:42:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338554517!12309986!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 1 Jun 2012 12:41:58 -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; 1 Jun 2012 12:41:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 13:41:57 +0100
Message-Id: <4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 13:41:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:

Is there a particular reason this series got resent with no apparent
change (and also none mentioned in the description here or in the
individual patches)? All of the comments sent yesterday still apply,
and I continue to consider patches 1-4 as unnecessary/broken.

Jan


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 12:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 12:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaRB4-0001T0-5m; Fri, 01 Jun 2012 12:42:02 +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 1SaRB2-0001Sv-Nn
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 12:42:00 +0000
Received: from [193.109.254.147:14156] by server-3.bemta-14.messagelabs.com id
	B5/83-15022-898B8CF4; Fri, 01 Jun 2012 12:42:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338554517!12309986!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 1 Jun 2012 12:41:58 -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; 1 Jun 2012 12:41:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 13:41:57 +0100
Message-Id: <4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 13:41:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:

Is there a particular reason this series got resent with no apparent
change (and also none mentioned in the description here or in the
individual patches)? All of the comments sent yesterday still apply,
and I continue to consider patches 1-4 as unnecessary/broken.

Jan


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 13:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 13: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 1SaRqK-00026j-Qz; Fri, 01 Jun 2012 13:24:40 +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 1SaRqI-00026e-RA
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 13:24:39 +0000
Received: from [85.158.138.51:24977] by server-7.bemta-3.messagelabs.com id
	EC/36-22601-592C8CF4; Fri, 01 Jun 2012 13:24:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338557076!22262417!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17791 invoked from network); 1 Jun 2012 13:24:37 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 13:24:37 -0000
Received: by qaeb19 with SMTP id b19so380887qae.11
	for <xen-devel@lists.xen.org>; Fri, 01 Jun 2012 06:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=6L8Ha/Jv08tZq51ZvT2XBss8f7k+a0qQm21f/B6QSyc=;
	b=liGNBrq5alDJUHvoPVCZnhbVs4C5loP3qKpr2PriTM6J5wzjrN2sRS5hpUvl+jd67k
	7KZm6ToHUUj5tnyFqYaR2qq8GHymd8JvKPgLJ2f9Tux8VFVPkAQv3ZtR//KmuUbjPhaz
	DSIu2wYSzhO+kxsHusI98pcpega6y4sO58Ky9PMDdBoGb+SENfsyWojoj00FV3hLFV0N
	jRpSeZu5CZDcFa5+Px86xNXWHNlDodO7qqoqLU3ege1C0cAAJPmlymX2S2RYk2OzGc20
	0q6javtMINoi99Wg/t93LMbGqFBBrWHd30YoBjvfaovTsyc8K6gltbkI4yzpwxWh+l/s
	Jpyg==
MIME-Version: 1.0
Received: by 10.224.181.83 with SMTP id bx19mr4113336qab.79.1338557075951;
	Fri, 01 Jun 2012 06:24:35 -0700 (PDT)
Received: by 10.229.188.195 with HTTP; Fri, 1 Jun 2012 06:24:35 -0700 (PDT)
In-Reply-To: <4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
Date: Fri, 1 Jun 2012 14:24:35 +0100
X-Google-Sender-Auth: 6G3aKKl5rTlrscDmbMIZl7Seia0
Message-ID: <CAFLBxZZ2G5zLe9ty1BXiGP5YGmUBSmqNP8OW4bpkY2euazLRhg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 1, 2012 at 1:41 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
>
> Is there a particular reason this series got resent with no apparent
> change (and also none mentioned in the description here or in the
> individual patches)? All of the comments sent yesterday still apply,
> and I continue to consider patches 1-4 as unnecessary/broken.

The date on the second set of e-mails is 15 minutes before the
original series.  I presume this means that Jean sent the series but
it got held up for some reason, so sent it again 15 minutes later; and
the second series made it through but the first was held up until
today.

Never attribute to malice that which can be attributed to computer error. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 13:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 13: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 1SaRqK-00026j-Qz; Fri, 01 Jun 2012 13:24:40 +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 1SaRqI-00026e-RA
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 13:24:39 +0000
Received: from [85.158.138.51:24977] by server-7.bemta-3.messagelabs.com id
	EC/36-22601-592C8CF4; Fri, 01 Jun 2012 13:24:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338557076!22262417!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17791 invoked from network); 1 Jun 2012 13:24:37 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 13:24:37 -0000
Received: by qaeb19 with SMTP id b19so380887qae.11
	for <xen-devel@lists.xen.org>; Fri, 01 Jun 2012 06:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=6L8Ha/Jv08tZq51ZvT2XBss8f7k+a0qQm21f/B6QSyc=;
	b=liGNBrq5alDJUHvoPVCZnhbVs4C5loP3qKpr2PriTM6J5wzjrN2sRS5hpUvl+jd67k
	7KZm6ToHUUj5tnyFqYaR2qq8GHymd8JvKPgLJ2f9Tux8VFVPkAQv3ZtR//KmuUbjPhaz
	DSIu2wYSzhO+kxsHusI98pcpega6y4sO58Ky9PMDdBoGb+SENfsyWojoj00FV3hLFV0N
	jRpSeZu5CZDcFa5+Px86xNXWHNlDodO7qqoqLU3ege1C0cAAJPmlymX2S2RYk2OzGc20
	0q6javtMINoi99Wg/t93LMbGqFBBrWHd30YoBjvfaovTsyc8K6gltbkI4yzpwxWh+l/s
	Jpyg==
MIME-Version: 1.0
Received: by 10.224.181.83 with SMTP id bx19mr4113336qab.79.1338557075951;
	Fri, 01 Jun 2012 06:24:35 -0700 (PDT)
Received: by 10.229.188.195 with HTTP; Fri, 1 Jun 2012 06:24:35 -0700 (PDT)
In-Reply-To: <4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
Date: Fri, 1 Jun 2012 14:24:35 +0100
X-Google-Sender-Auth: 6G3aKKl5rTlrscDmbMIZl7Seia0
Message-ID: <CAFLBxZZ2G5zLe9ty1BXiGP5YGmUBSmqNP8OW4bpkY2euazLRhg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 1, 2012 at 1:41 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
>
> Is there a particular reason this series got resent with no apparent
> change (and also none mentioned in the description here or in the
> individual patches)? All of the comments sent yesterday still apply,
> and I continue to consider patches 1-4 as unnecessary/broken.

The date on the second set of e-mails is 15 minutes before the
original series.  I presume this means that Jean sent the series but
it got held up for some reason, so sent it again 15 minutes later; and
the second series made it through but the first was held up until
today.

Never attribute to malice that which can be attributed to computer error. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 13:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 13:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaSDC-0002ac-1R; Fri, 01 Jun 2012 13:48: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 1SaSDA-0002aX-Ab
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 13:48:16 +0000
Received: from [85.158.138.51:52864] by server-3.bemta-3.messagelabs.com id
	59/D5-15793-F18C8CF4; Fri, 01 Jun 2012 13:48:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338558494!27498096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13512 invoked from network); 1 Jun 2012 13:48:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 13:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12788400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 13:47:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	14:47:59 +0100
Message-ID: <1338558477.17466.121.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Fri, 1 Jun 2012 14:47:57 +0100
In-Reply-To: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-05-31 at 16:07 +0100, Jean Guyader wrote:
> V4V is a copy based inter vm communication system.
> 
> Please have a look at this thread for more detail
> about V4V.
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html
> 
> This patch series is work in progress but I wanted to
> post it early enough so I can get feedback from people.

The main thing which is missing here, which makes it rather hard to
review, is any kind of design documentation. It would also be great to
see the rationale for why things have to be done this way.

For example it seems that there is a bunch of stuff being added to the
hypervisor which could live in the context of some guest or service
domain -- putting stuff like that in the hypervisor needs strong
arguments and rationale why it has to be there rather than somewhere
else.

Likewise perhaps the v4v hypercall could effectively be implemented with
a multicall containing some grant copy ops and evtchn manipulations?

But in the absence of any descriptions of the whats, hows and whys of
v4v its rather hard to have these sorts of conversations. The above are
some concrete examples but I'm more interested in seeing the more
general descriptions before we get into those.

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 13:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 13:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaSDC-0002ac-1R; Fri, 01 Jun 2012 13:48: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 1SaSDA-0002aX-Ab
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 13:48:16 +0000
Received: from [85.158.138.51:52864] by server-3.bemta-3.messagelabs.com id
	59/D5-15793-F18C8CF4; Fri, 01 Jun 2012 13:48:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338558494!27498096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13512 invoked from network); 1 Jun 2012 13:48:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 13:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12788400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 13:47:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	14:47:59 +0100
Message-ID: <1338558477.17466.121.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Fri, 1 Jun 2012 14:47:57 +0100
In-Reply-To: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-05-31 at 16:07 +0100, Jean Guyader wrote:
> V4V is a copy based inter vm communication system.
> 
> Please have a look at this thread for more detail
> about V4V.
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html
> 
> This patch series is work in progress but I wanted to
> post it early enough so I can get feedback from people.

The main thing which is missing here, which makes it rather hard to
review, is any kind of design documentation. It would also be great to
see the rationale for why things have to be done this way.

For example it seems that there is a bunch of stuff being added to the
hypervisor which could live in the context of some guest or service
domain -- putting stuff like that in the hypervisor needs strong
arguments and rationale why it has to be there rather than somewhere
else.

Likewise perhaps the v4v hypercall could effectively be implemented with
a multicall containing some grant copy ops and evtchn manipulations?

But in the absence of any descriptions of the whats, hows and whys of
v4v its rather hard to have these sorts of conversations. The above are
some concrete examples but I'm more interested in seeing the more
general descriptions before we get into those.

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:28:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaSpX-0003La-0i; Fri, 01 Jun 2012 14:27:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <killian.de.volder@scarlet.be>) id 1SaSpV-0003LU-DL
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:27:53 +0000
Received: from [85.158.143.99:31291] by server-3.bemta-4.messagelabs.com id
	EF/75-04252-861D8CF4; Fri, 01 Jun 2012 14:27:52 +0000
X-Env-Sender: killian.de.volder@scarlet.be
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338560871!23904140!1
X-Originating-IP: [195.130.132.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNDggPT4gMzIxMjQz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8132 invoked from network); 1 Jun 2012 14:27:52 -0000
Received: from gerard.telenet-ops.be (HELO gerard.telenet-ops.be)
	(195.130.132.48) by server-6.tower-216.messagelabs.com with SMTP;
	1 Jun 2012 14:27:52 -0000
Received: from [172.17.0.70] ([78.22.225.157])
	by gerard.telenet-ops.be with bizsmtp
	id H2Tq1j00k3QNqd20H2Tra2; Fri, 01 Jun 2012 16:27:51 +0200
Message-ID: <4FC8D166.20404@scarlet.be>
Date: Fri, 01 Jun 2012 16:27:50 +0200
From: Killian De Volder <killian.de.volder@scarlet.be>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120522 Thunderbird/10.0.4
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Only 1 CPU core detected
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 have a weird problem:
When I boot Linux get 8 cores (hyper-threading so 4 real cores).
However if I boot using Xen, i only get 1 cpu core:xl info report: "nr_cpus:1 nr_cores: 1 cores_per_socket:1 threads_per_core: 1"
Laptop is a ThinkPad w520 with a i7-2860QM with EFI-bios enabled.

Anyone has any suggestions ?

Kind regards,
Killian De Volder

xl dmesg:
(XEN) Xen version 4.1.2 (root@me.lan) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) Mon Feb 27 02:14:06 CET 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GRUB 1.99
(XEN) Command line: XEN
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009dc00 (usable)
(XEN)  000000000009dc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040000000 (usable)
(XEN)  0000000040000000 - 0000000040200000 (reserved)
(XEN)  0000000040200000 - 00000000da99f000 (usable)
(XEN)  00000000da99f000 - 00000000dae9f000 (reserved)
(XEN)  00000000dae9f000 - 00000000daf9f000 (ACPI NVS)
(XEN)  00000000daf9f000 - 00000000dafff000 (ACPI data)
(XEN)  00000000dafff000 - 00000000db000000 (usable)
(XEN)  00000000db000000 - 00000000dfa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed08000 - 00000000fed09000 (reserved)
(XEN)  00000000fed10000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffd20000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000011e600000 (usable)
(XEN) ACPI Error (tbxfroot-0220): A valid RSDP was not found [20070126]
(XEN) System RAM: 3979MB (4074740kB)
(XEN) Domain heap initialised
(XEN) Table is not found!
(XEN) Found and enabled local APIC!
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2491.961 MHz processor.
(XEN) Initing memory sharing.
(XEN) I/O virtualisation disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) Platform timer is 1.193MHz PIT
(XEN) Allocated console ring of 16 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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 1 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1d6c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000114000000->0000000118000000 (955561 pages to be allocated)
(XEN)  Init. ramdisk: 000000011e1f4000->000000011e5ff600
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81d6c000
(XEN)  Init. ramdisk: ffffffff81d6c000->ffffffff82177600
(XEN)  Phys-Mach map: ffffffff82178000->ffffffff828e45a8
(XEN)  Start info:    ffffffff828e5000->ffffffff828e54b4
(XEN)  Page tables:   ffffffff828e6000->ffffffff828ff000
(XEN)  Boot stack:    ffffffff828ff000->ffffffff82900000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a21200
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 212kB init memory.
(XEN) physdev.c:155: dom0: wrong map_pirq type 3





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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:28:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaSpX-0003La-0i; Fri, 01 Jun 2012 14:27:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <killian.de.volder@scarlet.be>) id 1SaSpV-0003LU-DL
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:27:53 +0000
Received: from [85.158.143.99:31291] by server-3.bemta-4.messagelabs.com id
	EF/75-04252-861D8CF4; Fri, 01 Jun 2012 14:27:52 +0000
X-Env-Sender: killian.de.volder@scarlet.be
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338560871!23904140!1
X-Originating-IP: [195.130.132.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNDggPT4gMzIxMjQz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8132 invoked from network); 1 Jun 2012 14:27:52 -0000
Received: from gerard.telenet-ops.be (HELO gerard.telenet-ops.be)
	(195.130.132.48) by server-6.tower-216.messagelabs.com with SMTP;
	1 Jun 2012 14:27:52 -0000
Received: from [172.17.0.70] ([78.22.225.157])
	by gerard.telenet-ops.be with bizsmtp
	id H2Tq1j00k3QNqd20H2Tra2; Fri, 01 Jun 2012 16:27:51 +0200
Message-ID: <4FC8D166.20404@scarlet.be>
Date: Fri, 01 Jun 2012 16:27:50 +0200
From: Killian De Volder <killian.de.volder@scarlet.be>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120522 Thunderbird/10.0.4
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Only 1 CPU core detected
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 have a weird problem:
When I boot Linux get 8 cores (hyper-threading so 4 real cores).
However if I boot using Xen, i only get 1 cpu core:xl info report: "nr_cpus:1 nr_cores: 1 cores_per_socket:1 threads_per_core: 1"
Laptop is a ThinkPad w520 with a i7-2860QM with EFI-bios enabled.

Anyone has any suggestions ?

Kind regards,
Killian De Volder

xl dmesg:
(XEN) Xen version 4.1.2 (root@me.lan) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) Mon Feb 27 02:14:06 CET 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GRUB 1.99
(XEN) Command line: XEN
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009dc00 (usable)
(XEN)  000000000009dc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040000000 (usable)
(XEN)  0000000040000000 - 0000000040200000 (reserved)
(XEN)  0000000040200000 - 00000000da99f000 (usable)
(XEN)  00000000da99f000 - 00000000dae9f000 (reserved)
(XEN)  00000000dae9f000 - 00000000daf9f000 (ACPI NVS)
(XEN)  00000000daf9f000 - 00000000dafff000 (ACPI data)
(XEN)  00000000dafff000 - 00000000db000000 (usable)
(XEN)  00000000db000000 - 00000000dfa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed08000 - 00000000fed09000 (reserved)
(XEN)  00000000fed10000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffd20000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000011e600000 (usable)
(XEN) ACPI Error (tbxfroot-0220): A valid RSDP was not found [20070126]
(XEN) System RAM: 3979MB (4074740kB)
(XEN) Domain heap initialised
(XEN) Table is not found!
(XEN) Found and enabled local APIC!
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2491.961 MHz processor.
(XEN) Initing memory sharing.
(XEN) I/O virtualisation disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) Platform timer is 1.193MHz PIT
(XEN) Allocated console ring of 16 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) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 1 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1d6c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000114000000->0000000118000000 (955561 pages to be allocated)
(XEN)  Init. ramdisk: 000000011e1f4000->000000011e5ff600
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81d6c000
(XEN)  Init. ramdisk: ffffffff81d6c000->ffffffff82177600
(XEN)  Phys-Mach map: ffffffff82178000->ffffffff828e45a8
(XEN)  Start info:    ffffffff828e5000->ffffffff828e54b4
(XEN)  Page tables:   ffffffff828e6000->ffffffff828ff000
(XEN)  Boot stack:    ffffffff828ff000->ffffffff82900000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a21200
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 212kB init memory.
(XEN) physdev.c:155: dom0: wrong map_pirq type 3





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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14: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 1SaT5S-0003w4-Hs; Fri, 01 Jun 2012 14:44: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 1SaT5Q-0003vz-NN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 14:44:21 +0000
Received: from [85.158.139.83:2968] by server-1.bemta-5.messagelabs.com id
	FA/9C-21549-345D8CF4; Fri, 01 Jun 2012 14:44:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338561858!31058540!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30293 invoked from network); 1 Jun 2012 14:44:18 -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; 1 Jun 2012 14:44:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 15:44:18 +0100
Message-Id: <4FC8F1610200007800087D7E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 15:44:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Killian De Volder" <killian.de.volder@scarlet.be>
References: <4FC8D166.20404@scarlet.be>
In-Reply-To: <4FC8D166.20404@scarlet.be>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Only 1 CPU core detected
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:27, Killian De Volder <killian.de.volder@scarlet.be> wrote:
> I have a weird problem:
> When I boot Linux get 8 cores (hyper-threading so 4 real cores).
> However if I boot using Xen, i only get 1 cpu core:xl info report: 
> "nr_cpus:1 nr_cores: 1 cores_per_socket:1 threads_per_core: 1"
> Laptop is a ThinkPad w520 with a i7-2860QM with EFI-bios enabled.
> 
> Anyone has any suggestions ?

Please post/attach the complete set of native Linux boot messages,
since ...

> (XEN) Xen version 4.1.2 (root@me.lan) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) Mon Feb 27 02:14:06 CET 2012
> (XEN) Latest ChangeSet: unavailable
> (XEN) Bootloader: GRUB 1.99
> (XEN) Command line: XEN
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 0 MBR signatures
> (XEN)  Found 0 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009dc00 (usable)
> (XEN)  000000000009dc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040000000 (usable)
> (XEN)  0000000040000000 - 0000000040200000 (reserved)
> (XEN)  0000000040200000 - 00000000da99f000 (usable)
> (XEN)  00000000da99f000 - 00000000dae9f000 (reserved)
> (XEN)  00000000dae9f000 - 00000000daf9f000 (ACPI NVS)
> (XEN)  00000000daf9f000 - 00000000dafff000 (ACPI data)
> (XEN)  00000000dafff000 - 00000000db000000 (usable)
> (XEN)  00000000db000000 - 00000000dfa00000 (reserved)
> (XEN)  00000000f8000000 - 00000000fc000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec01000 (reserved)
> (XEN)  00000000fed08000 - 00000000fed09000 (reserved)
> (XEN)  00000000fed10000 - 00000000fed1a000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ffd20000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 000000011e600000 (usable)
> (XEN) ACPI Error (tbxfroot-0220): A valid RSDP was not found [20070126]

... indicates a problem that I would generally assume Linux has
as well (hence it'll be interesting to see how it manages to find
all 8 threads). Subsequently it may become necessary that you
dump and provide the ACPI tables of the system (assuming it
has ACPI, however broken it might be) and/or try out recent
-unstable code.

Btw., unless the log was from a PXE boot on a diskless system,
the two lines following "Disc information:" above indicate further
problems with your BIOS, so I wouldn't be surprised if the issue
you found is firmware related too.

Jan

> (XEN) System RAM: 3979MB (4074740kB)
> (XEN) Domain heap initialised
> (XEN) Table is not found!
> (XEN) Found and enabled local APIC!
> (XEN) Not enabling x2APIC: depends on iommu_supports_eim.
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2491.961 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) I/O virtualisation disabled
> (XEN) Enabled directed EOI with ioapic_ack_old on!
> (XEN) Platform timer is 1.193MHz PIT
> (XEN) Allocated console ring of 16 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) EPT supports 2MB super page.
> (XEN) HVM: ASIDs enabled.
> (XEN) HVM: VMX enabled
> (XEN) HVM: Hardware Assisted Paging detected.
> (XEN) Brought up 1 CPUs



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14: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 1SaT5S-0003w4-Hs; Fri, 01 Jun 2012 14:44: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 1SaT5Q-0003vz-NN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 14:44:21 +0000
Received: from [85.158.139.83:2968] by server-1.bemta-5.messagelabs.com id
	FA/9C-21549-345D8CF4; Fri, 01 Jun 2012 14:44:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338561858!31058540!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30293 invoked from network); 1 Jun 2012 14:44:18 -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; 1 Jun 2012 14:44:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 15:44:18 +0100
Message-Id: <4FC8F1610200007800087D7E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 15:44:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Killian De Volder" <killian.de.volder@scarlet.be>
References: <4FC8D166.20404@scarlet.be>
In-Reply-To: <4FC8D166.20404@scarlet.be>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Only 1 CPU core detected
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:27, Killian De Volder <killian.de.volder@scarlet.be> wrote:
> I have a weird problem:
> When I boot Linux get 8 cores (hyper-threading so 4 real cores).
> However if I boot using Xen, i only get 1 cpu core:xl info report: 
> "nr_cpus:1 nr_cores: 1 cores_per_socket:1 threads_per_core: 1"
> Laptop is a ThinkPad w520 with a i7-2860QM with EFI-bios enabled.
> 
> Anyone has any suggestions ?

Please post/attach the complete set of native Linux boot messages,
since ...

> (XEN) Xen version 4.1.2 (root@me.lan) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) Mon Feb 27 02:14:06 CET 2012
> (XEN) Latest ChangeSet: unavailable
> (XEN) Bootloader: GRUB 1.99
> (XEN) Command line: XEN
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 0 MBR signatures
> (XEN)  Found 0 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009dc00 (usable)
> (XEN)  000000000009dc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040000000 (usable)
> (XEN)  0000000040000000 - 0000000040200000 (reserved)
> (XEN)  0000000040200000 - 00000000da99f000 (usable)
> (XEN)  00000000da99f000 - 00000000dae9f000 (reserved)
> (XEN)  00000000dae9f000 - 00000000daf9f000 (ACPI NVS)
> (XEN)  00000000daf9f000 - 00000000dafff000 (ACPI data)
> (XEN)  00000000dafff000 - 00000000db000000 (usable)
> (XEN)  00000000db000000 - 00000000dfa00000 (reserved)
> (XEN)  00000000f8000000 - 00000000fc000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec01000 (reserved)
> (XEN)  00000000fed08000 - 00000000fed09000 (reserved)
> (XEN)  00000000fed10000 - 00000000fed1a000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ffd20000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 000000011e600000 (usable)
> (XEN) ACPI Error (tbxfroot-0220): A valid RSDP was not found [20070126]

... indicates a problem that I would generally assume Linux has
as well (hence it'll be interesting to see how it manages to find
all 8 threads). Subsequently it may become necessary that you
dump and provide the ACPI tables of the system (assuming it
has ACPI, however broken it might be) and/or try out recent
-unstable code.

Btw., unless the log was from a PXE boot on a diskless system,
the two lines following "Disc information:" above indicate further
problems with your BIOS, so I wouldn't be surprised if the issue
you found is firmware related too.

Jan

> (XEN) System RAM: 3979MB (4074740kB)
> (XEN) Domain heap initialised
> (XEN) Table is not found!
> (XEN) Found and enabled local APIC!
> (XEN) Not enabling x2APIC: depends on iommu_supports_eim.
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2491.961 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) I/O virtualisation disabled
> (XEN) Enabled directed EOI with ioapic_ack_old on!
> (XEN) Platform timer is 1.193MHz PIT
> (XEN) Allocated console ring of 16 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) EPT supports 2MB super page.
> (XEN) HVM: ASIDs enabled.
> (XEN) HVM: VMX enabled
> (XEN) HVM: Hardware Assisted Paging detected.
> (XEN) Brought up 1 CPUs



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTD9-00046H-P5; Fri, 01 Jun 2012 14:52:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD7-00045i-Vr
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:18 +0000
Received: from [85.158.143.35:28116] by server-3.bemta-4.messagelabs.com id
	F8/A4-04252-127D8CF4; Fri, 01 Jun 2012 14:52:17 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338562333!15860369!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17209 invoked from network); 1 Jun 2012 14:52:13 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-16.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 14:52:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id CAD73C002A3;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id t9J+KI7i-2+q; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 32E2C49C69F;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:36 +0200
Message-Id: <1338562358-28182-3-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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

From: Borislav Petkov <borislav.petkov@amd.com>

There's no real reason why, when showing the MSRs on a CPU at boottime,
we should be using the AMD-specific variant. Simply use the generic safe
one which handles #GPs just fine.

Cc: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/kernel/cpu/common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 82f29e70d058..232fba2d54c9 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -947,7 +947,7 @@ static void __cpuinit __print_cpu_msr(void)
 		index_max = msr_range_array[i].max;
 
 		for (index = index_min; index < index_max; index++) {
-			if (rdmsrl_amd_safe(index, &val))
+			if (rdmsrl_safe(index, &val))
 				continue;
 			printk(KERN_INFO " MSR%08x: %016llx\n", index, val);
 		}
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTD9-00046H-P5; Fri, 01 Jun 2012 14:52:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD7-00045i-Vr
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:18 +0000
Received: from [85.158.143.35:28116] by server-3.bemta-4.messagelabs.com id
	F8/A4-04252-127D8CF4; Fri, 01 Jun 2012 14:52:17 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338562333!15860369!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17209 invoked from network); 1 Jun 2012 14:52:13 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-16.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 14:52:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id CAD73C002A3;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id t9J+KI7i-2+q; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 32E2C49C69F;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:36 +0200
Message-Id: <1338562358-28182-3-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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

From: Borislav Petkov <borislav.petkov@amd.com>

There's no real reason why, when showing the MSRs on a CPU at boottime,
we should be using the AMD-specific variant. Simply use the generic safe
one which handles #GPs just fine.

Cc: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/kernel/cpu/common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 82f29e70d058..232fba2d54c9 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -947,7 +947,7 @@ static void __cpuinit __print_cpu_msr(void)
 		index_max = msr_range_array[i].max;
 
 		for (index = index_min; index < index_max; index++) {
-			if (rdmsrl_amd_safe(index, &val))
+			if (rdmsrl_safe(index, &val))
 				continue;
 			printk(KERN_INFO " MSR%08x: %016llx\n", index, val);
 		}
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14: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 1SaTD5-00045J-G3; Fri, 01 Jun 2012 14:52:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD4-000458-3L
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:14 +0000
Received: from [85.158.143.35:27860] by server-1.bemta-4.messagelabs.com id
	5A/7F-27869-D17D8CF4; Fri, 01 Jun 2012 14:52:13 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338562332!13146939!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8699 invoked from network); 1 Jun 2012 14:52:12 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-8.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 14:52:12 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 6AF33C0047F;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id Y9YWPmjb5nEz; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 2460E49C20C;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:34 +0200
Message-Id: <1338562358-28182-1-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Borislav Petkov <borislav.petkov@amd.com>

Ok,

the following patchset should take care of all the {rd,wr}msrl_amd_safe
headaches we had this week. After it is applied, the AMD-specific
variants become private to amd.c and issue a warning when used on
anything else beside K8.

This also contains the two patches from Andre which cleanup the PV-side
of things.

Thanks.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14: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 1SaTD5-00045J-G3; Fri, 01 Jun 2012 14:52:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD4-000458-3L
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:14 +0000
Received: from [85.158.143.35:27860] by server-1.bemta-4.messagelabs.com id
	5A/7F-27869-D17D8CF4; Fri, 01 Jun 2012 14:52:13 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338562332!13146939!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8699 invoked from network); 1 Jun 2012 14:52:12 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-8.tower-21.messagelabs.com with SMTP;
	1 Jun 2012 14:52:12 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 6AF33C0047F;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id Y9YWPmjb5nEz; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 2460E49C20C;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:34 +0200
Message-Id: <1338562358-28182-1-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Borislav Petkov <borislav.petkov@amd.com>

Ok,

the following patchset should take care of all the {rd,wr}msrl_amd_safe
headaches we had this week. After it is applied, the AMD-specific
variants become private to amd.c and issue a warning when used on
anything else beside K8.

This also contains the two patches from Andre which cleanup the PV-side
of things.

Thanks.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTD6-00045V-Rv; Fri, 01 Jun 2012 14:52:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD5-000458-5l
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:15 +0000
Received: from [85.158.143.99:22793] by server-1.bemta-4.messagelabs.com id
	43/8F-27869-E17D8CF4; Fri, 01 Jun 2012 14:52:14 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338562333!30382199!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21335 invoked from network); 1 Jun 2012 14:52:13 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-3.tower-216.messagelabs.com with SMTP;
	1 Jun 2012 14:52:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 2F28CC002B0;
	Fri,  1 Jun 2012 16:52:13 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id liMkJ9hx0yQt; Fri,  1 Jun 2012 16:52:13 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 37B7549C6A1;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:38 +0200
Message-Id: <1338562358-28182-5-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 4/4] x86, CPU,
	AMD: Deprecate AMD-specific MSR variants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Borislav Petkov <borislav.petkov@amd.com>

Now that all users of {rd,wr}msr_amd_safe have been fixed, deprecate its
use by making them private to amd.c and adding warnings when used on
anything else beside K8.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/include/asm/msr.h |   27 ---------------------------
 arch/x86/kernel/cpu/amd.c  |   33 +++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 81860cc012d1..cb33b5f00267 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -211,33 +211,6 @@ do {                                                            \
 
 #endif	/* !CONFIG_PARAVIRT */
 
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = rdmsr_safe_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return wrmsr_safe_regs(gprs);
-}
-
 #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
 
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 80ccd99542e6..c928eb26ada6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -19,6 +19,39 @@
 
 #include "cpu.h"
 
+static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
+{
+	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
+	u32 gprs[8] = { 0 };
+	int err;
+
+	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
+
+	gprs[1] = msr;
+	gprs[7] = 0x9c5a203a;
+
+	err = rdmsr_safe_regs(gprs);
+
+	*p = gprs[0] | ((u64)gprs[2] << 32);
+
+	return err;
+}
+
+static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
+{
+	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
+	u32 gprs[8] = { 0 };
+
+	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
+
+	gprs[0] = (u32)val;
+	gprs[1] = msr;
+	gprs[2] = val >> 32;
+	gprs[7] = 0x9c5a203a;
+
+	return wrmsr_safe_regs(gprs);
+}
+
 #ifdef CONFIG_X86_32
 /*
  *	B step AMD K6 before B 9730xxxx have hardware bugs that can cause
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTD6-00045V-Rv; Fri, 01 Jun 2012 14:52:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD5-000458-5l
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:15 +0000
Received: from [85.158.143.99:22793] by server-1.bemta-4.messagelabs.com id
	43/8F-27869-E17D8CF4; Fri, 01 Jun 2012 14:52:14 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338562333!30382199!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21335 invoked from network); 1 Jun 2012 14:52:13 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-3.tower-216.messagelabs.com with SMTP;
	1 Jun 2012 14:52:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 2F28CC002B0;
	Fri,  1 Jun 2012 16:52:13 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id liMkJ9hx0yQt; Fri,  1 Jun 2012 16:52:13 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 37B7549C6A1;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:38 +0200
Message-Id: <1338562358-28182-5-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 4/4] x86, CPU,
	AMD: Deprecate AMD-specific MSR variants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Borislav Petkov <borislav.petkov@amd.com>

Now that all users of {rd,wr}msr_amd_safe have been fixed, deprecate its
use by making them private to amd.c and adding warnings when used on
anything else beside K8.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/include/asm/msr.h |   27 ---------------------------
 arch/x86/kernel/cpu/amd.c  |   33 +++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 81860cc012d1..cb33b5f00267 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -211,33 +211,6 @@ do {                                                            \
 
 #endif	/* !CONFIG_PARAVIRT */
 
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = rdmsr_safe_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return wrmsr_safe_regs(gprs);
-}
-
 #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
 
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 80ccd99542e6..c928eb26ada6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -19,6 +19,39 @@
 
 #include "cpu.h"
 
+static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
+{
+	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
+	u32 gprs[8] = { 0 };
+	int err;
+
+	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
+
+	gprs[1] = msr;
+	gprs[7] = 0x9c5a203a;
+
+	err = rdmsr_safe_regs(gprs);
+
+	*p = gprs[0] | ((u64)gprs[2] << 32);
+
+	return err;
+}
+
+static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
+{
+	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
+	u32 gprs[8] = { 0 };
+
+	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
+
+	gprs[0] = (u32)val;
+	gprs[1] = msr;
+	gprs[2] = val >> 32;
+	gprs[7] = 0x9c5a203a;
+
+	return wrmsr_safe_regs(gprs);
+}
+
 #ifdef CONFIG_X86_32
 /*
  *	B step AMD K6 before B 9730xxxx have hardware bugs that can cause
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTDC-00046x-67; Fri, 01 Jun 2012 14:52:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTDA-00046S-Gd
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:20 +0000
Received: from [193.109.254.147:16786] by server-7.bemta-14.messagelabs.com id
	CB/0D-07635-327D8CF4; Fri, 01 Jun 2012 14:52:19 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338562333!7242694!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13327 invoked from network); 1 Jun 2012 14:52:15 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-10.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 14:52:14 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 8A12FC00428;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id L4sEosMgSxoT; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 30AF149C69E;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:35 +0200
Message-Id: <1338562358-28182-2-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 1/4] x86, pvops: Remove hooks for {rd,
	wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Andre Przywara <andre.przywara@amd.com>

There were paravirt_ops hooks for the full register set variant of
{rd,wr}msr_safe which are actually not used by anyone anymore. Remove
them to make the code cleaner and avoid silent breakages when the pvops
members were uninitialized. This has been boot-tested natively and under
Xen with PVOPS enabled and disabled on one machine.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
 arch/x86/include/asm/paravirt.h       |   39 -------------------
 arch/x86/include/asm/paravirt_types.h |    2 -
 arch/x86/kernel/paravirt.c            |    2 -
 arch/x86/lib/msr-reg-export.c         |    4 +-
 arch/x86/lib/msr-reg.S                |   10 ++---
 arch/x86/xen/enlighten.c              |    2 -
 7 files changed, 35 insertions(+), 91 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 084ef95274cd..81860cc012d1 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned int msr,
 
 extern unsigned long long native_read_tsc(void);
 
-extern int native_rdmsr_safe_regs(u32 regs[8]);
-extern int native_wrmsr_safe_regs(u32 regs[8]);
+extern int rdmsr_safe_regs(u32 regs[8]);
+extern int wrmsr_safe_regs(u32 regs[8]);
 
 static __always_inline unsigned long long __native_read_tsc(void)
 {
@@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	return err;
 }
 
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = native_rdmsr_safe_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return native_wrmsr_safe_regs(gprs);
-}
-
-static inline int rdmsr_safe_regs(u32 regs[8])
-{
-	return native_rdmsr_safe_regs(regs);
-}
-
-static inline int wrmsr_safe_regs(u32 regs[8])
-{
-	return native_wrmsr_safe_regs(regs);
-}
-
 #define rdtscl(low)						\
 	((low) = (u32)__native_read_tsc())
 
@@ -248,6 +211,32 @@ do {                                                            \
 
 #endif	/* !CONFIG_PARAVIRT */
 
+static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
+{
+	u32 gprs[8] = { 0 };
+	int err;
+
+	gprs[1] = msr;
+	gprs[7] = 0x9c5a203a;
+
+	err = rdmsr_safe_regs(gprs);
+
+	*p = gprs[0] | ((u64)gprs[2] << 32);
+
+	return err;
+}
+
+static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
+{
+	u32 gprs[8] = { 0 };
+
+	gprs[0] = (u32)val;
+	gprs[1] = msr;
+	gprs[2] = val >> 32;
+	gprs[7] = 0x9c5a203a;
+
+	return wrmsr_safe_regs(gprs);
+}
 
 #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 6cbbabf52707..ebb0cdb60a89 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int *err)
 	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
 }
 
-static inline int paravirt_rdmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
-}
-
 static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
 {
 	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
 }
 
-static inline int paravirt_wrmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
-}
-
 /* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2)			\
 do {						\
@@ -176,9 +166,6 @@ do {						\
 	_err;					\
 })
 
-#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
-#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
-
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
 	int err;
@@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	*p = paravirt_read_msr(msr, &err);
 	return err;
 }
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = paravirt_rdmsr_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return paravirt_wrmsr_regs(gprs);
-}
 
 static inline u64 paravirt_read_tsc(void)
 {
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4987ee..8613cbb7ba41 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -153,9 +153,7 @@ struct pv_cpu_ops {
 	/* MSR, PMC and TSR operations.
 	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
 	u64 (*read_msr)(unsigned int msr, int *err);
-	int (*rdmsr_regs)(u32 *regs);
 	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
-	int (*wrmsr_regs)(u32 *regs);
 
 	u64 (*read_tsc)(void);
 	u64 (*read_pmc)(int counter);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 9ce885996fd7..17fff18a1031 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
 #endif
 	.wbinvd = native_wbinvd,
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = native_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 	.read_tscp = native_read_tscp,
diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
index a311cc59b65d..8d6ef78b5d01 100644
--- a/arch/x86/lib/msr-reg-export.c
+++ b/arch/x86/lib/msr-reg-export.c
@@ -1,5 +1,5 @@
 #include <linux/module.h>
 #include <asm/msr.h>
 
-EXPORT_SYMBOL(native_rdmsr_safe_regs);
-EXPORT_SYMBOL(native_wrmsr_safe_regs);
+EXPORT_SYMBOL(rdmsr_safe_regs);
+EXPORT_SYMBOL(wrmsr_safe_regs);
diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
index 69fa10623f21..f6d13eefad10 100644
--- a/arch/x86/lib/msr-reg.S
+++ b/arch/x86/lib/msr-reg.S
@@ -6,13 +6,13 @@
 
 #ifdef CONFIG_X86_64
 /*
- * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
+ * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
  *
  * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
  *
  */
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushq_cfi %rbx
 	pushq_cfi %rbp
@@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #else /* X86_32 */
 
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushl_cfi %ebx
 	pushl_cfi %ebp
@@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #endif
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e74df9548a02..60f1131eb94f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.wbinvd = native_wbinvd,
 
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = xen_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTDC-00046x-67; Fri, 01 Jun 2012 14:52:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTDA-00046S-Gd
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:20 +0000
Received: from [193.109.254.147:16786] by server-7.bemta-14.messagelabs.com id
	CB/0D-07635-327D8CF4; Fri, 01 Jun 2012 14:52:19 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338562333!7242694!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13327 invoked from network); 1 Jun 2012 14:52:15 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-10.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 14:52:14 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 8A12FC00428;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id L4sEosMgSxoT; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 30AF149C69E;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:35 +0200
Message-Id: <1338562358-28182-2-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 1/4] x86, pvops: Remove hooks for {rd,
	wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Andre Przywara <andre.przywara@amd.com>

There were paravirt_ops hooks for the full register set variant of
{rd,wr}msr_safe which are actually not used by anyone anymore. Remove
them to make the code cleaner and avoid silent breakages when the pvops
members were uninitialized. This has been boot-tested natively and under
Xen with PVOPS enabled and disabled on one machine.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
 arch/x86/include/asm/paravirt.h       |   39 -------------------
 arch/x86/include/asm/paravirt_types.h |    2 -
 arch/x86/kernel/paravirt.c            |    2 -
 arch/x86/lib/msr-reg-export.c         |    4 +-
 arch/x86/lib/msr-reg.S                |   10 ++---
 arch/x86/xen/enlighten.c              |    2 -
 7 files changed, 35 insertions(+), 91 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 084ef95274cd..81860cc012d1 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned int msr,
 
 extern unsigned long long native_read_tsc(void);
 
-extern int native_rdmsr_safe_regs(u32 regs[8]);
-extern int native_wrmsr_safe_regs(u32 regs[8]);
+extern int rdmsr_safe_regs(u32 regs[8]);
+extern int wrmsr_safe_regs(u32 regs[8]);
 
 static __always_inline unsigned long long __native_read_tsc(void)
 {
@@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	return err;
 }
 
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = native_rdmsr_safe_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return native_wrmsr_safe_regs(gprs);
-}
-
-static inline int rdmsr_safe_regs(u32 regs[8])
-{
-	return native_rdmsr_safe_regs(regs);
-}
-
-static inline int wrmsr_safe_regs(u32 regs[8])
-{
-	return native_wrmsr_safe_regs(regs);
-}
-
 #define rdtscl(low)						\
 	((low) = (u32)__native_read_tsc())
 
@@ -248,6 +211,32 @@ do {                                                            \
 
 #endif	/* !CONFIG_PARAVIRT */
 
+static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
+{
+	u32 gprs[8] = { 0 };
+	int err;
+
+	gprs[1] = msr;
+	gprs[7] = 0x9c5a203a;
+
+	err = rdmsr_safe_regs(gprs);
+
+	*p = gprs[0] | ((u64)gprs[2] << 32);
+
+	return err;
+}
+
+static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
+{
+	u32 gprs[8] = { 0 };
+
+	gprs[0] = (u32)val;
+	gprs[1] = msr;
+	gprs[2] = val >> 32;
+	gprs[7] = 0x9c5a203a;
+
+	return wrmsr_safe_regs(gprs);
+}
 
 #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 6cbbabf52707..ebb0cdb60a89 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int *err)
 	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
 }
 
-static inline int paravirt_rdmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
-}
-
 static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
 {
 	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
 }
 
-static inline int paravirt_wrmsr_regs(u32 *regs)
-{
-	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
-}
-
 /* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2)			\
 do {						\
@@ -176,9 +166,6 @@ do {						\
 	_err;					\
 })
 
-#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
-#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
-
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
 	int err;
@@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 	*p = paravirt_read_msr(msr, &err);
 	return err;
 }
-static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
-{
-	u32 gprs[8] = { 0 };
-	int err;
-
-	gprs[1] = msr;
-	gprs[7] = 0x9c5a203a;
-
-	err = paravirt_rdmsr_regs(gprs);
-
-	*p = gprs[0] | ((u64)gprs[2] << 32);
-
-	return err;
-}
-
-static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
-{
-	u32 gprs[8] = { 0 };
-
-	gprs[0] = (u32)val;
-	gprs[1] = msr;
-	gprs[2] = val >> 32;
-	gprs[7] = 0x9c5a203a;
-
-	return paravirt_wrmsr_regs(gprs);
-}
 
 static inline u64 paravirt_read_tsc(void)
 {
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4987ee..8613cbb7ba41 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -153,9 +153,7 @@ struct pv_cpu_ops {
 	/* MSR, PMC and TSR operations.
 	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
 	u64 (*read_msr)(unsigned int msr, int *err);
-	int (*rdmsr_regs)(u32 *regs);
 	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
-	int (*wrmsr_regs)(u32 *regs);
 
 	u64 (*read_tsc)(void);
 	u64 (*read_pmc)(int counter);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 9ce885996fd7..17fff18a1031 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
 #endif
 	.wbinvd = native_wbinvd,
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = native_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 	.read_tscp = native_read_tscp,
diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
index a311cc59b65d..8d6ef78b5d01 100644
--- a/arch/x86/lib/msr-reg-export.c
+++ b/arch/x86/lib/msr-reg-export.c
@@ -1,5 +1,5 @@
 #include <linux/module.h>
 #include <asm/msr.h>
 
-EXPORT_SYMBOL(native_rdmsr_safe_regs);
-EXPORT_SYMBOL(native_wrmsr_safe_regs);
+EXPORT_SYMBOL(rdmsr_safe_regs);
+EXPORT_SYMBOL(wrmsr_safe_regs);
diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
index 69fa10623f21..f6d13eefad10 100644
--- a/arch/x86/lib/msr-reg.S
+++ b/arch/x86/lib/msr-reg.S
@@ -6,13 +6,13 @@
 
 #ifdef CONFIG_X86_64
 /*
- * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
+ * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
  *
  * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
  *
  */
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushq_cfi %rbx
 	pushq_cfi %rbp
@@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #else /* X86_32 */
 
 .macro op_safe_regs op
-ENTRY(native_\op\()_safe_regs)
+ENTRY(\op\()_safe_regs)
 	CFI_STARTPROC
 	pushl_cfi %ebx
 	pushl_cfi %ebp
@@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
 
 	_ASM_EXTABLE(1b, 3b)
 	CFI_ENDPROC
-ENDPROC(native_\op\()_safe_regs)
+ENDPROC(\op\()_safe_regs)
 .endm
 
 #endif
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e74df9548a02..60f1131eb94f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.wbinvd = native_wbinvd,
 
 	.read_msr = native_read_msr_safe,
-	.rdmsr_regs = native_rdmsr_safe_regs,
 	.write_msr = xen_write_msr_safe,
-	.wrmsr_regs = native_wrmsr_safe_regs,
 
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTD7-00045c-7P; Fri, 01 Jun 2012 14:52:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD5-00045D-7E
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:15 +0000
Received: from [85.158.138.51:42275] by server-6.bemta-3.messagelabs.com id
	BF/7D-23455-E17D8CF4; Fri, 01 Jun 2012 14:52:14 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338562333!11686535!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21305 invoked from network); 1 Jun 2012 14:52:13 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-13.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 14:52:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 23E97C002AE;
	Fri,  1 Jun 2012 16:52:13 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id UemWqWRnhrJU; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 3535649C6A0;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:37 +0200
Message-Id: <1338562358-28182-4-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, stable@vger.kernel.org#3.4+,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Andre Przywara <andre.przywara@amd.com>

f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it") wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.

This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.

This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).

Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: stable@vger.kernel.org # 3.4+
Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/kernel/cpu/amd.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 146bb6218eec..80ccd99542e6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -586,9 +586,9 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 	    !cpu_has(c, X86_FEATURE_TOPOEXT)) {
 		u64 val;
 
-		if (!rdmsrl_amd_safe(0xc0011005, &val)) {
+		if (!rdmsrl_safe(0xc0011005, &val)) {
 			val |= 1ULL << 54;
-			wrmsrl_amd_safe(0xc0011005, val);
+			checking_wrmsrl(0xc0011005, val);
 			rdmsrl(0xc0011005, val);
 			if (val & (1ULL << 54)) {
 				set_cpu_cap(c, X86_FEATURE_TOPOEXT);
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:52:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:52: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 1SaTD7-00045c-7P; Fri, 01 Jun 2012 14:52:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTD5-00045D-7E
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:52:15 +0000
Received: from [85.158.138.51:42275] by server-6.bemta-3.messagelabs.com id
	BF/7D-23455-E17D8CF4; Fri, 01 Jun 2012 14:52:14 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338562333!11686535!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21305 invoked from network); 1 Jun 2012 14:52:13 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-13.tower-174.messagelabs.com with SMTP;
	1 Jun 2012 14:52:13 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 23E97C002AE;
	Fri,  1 Jun 2012 16:52:13 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id UemWqWRnhrJU; Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:52:12 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 3535649C6A0;
	Fri,  1 Jun 2012 15:52:12 +0100 (BST)
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri,  1 Jun 2012 16:52:37 +0200
Message-Id: <1338562358-28182-4-git-send-email-bp@amd64.org>
X-Mailer: git-send-email 1.7.9.3.362.g71319
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, stable@vger.kernel.org#3.4+,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Andre Przywara <andre.przywara@amd.com>

f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it") wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.

This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.

This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).

Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: stable@vger.kernel.org # 3.4+
Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/kernel/cpu/amd.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 146bb6218eec..80ccd99542e6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -586,9 +586,9 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 	    !cpu_has(c, X86_FEATURE_TOPOEXT)) {
 		u64 val;
 
-		if (!rdmsrl_amd_safe(0xc0011005, &val)) {
+		if (!rdmsrl_safe(0xc0011005, &val)) {
 			val |= 1ULL << 54;
-			wrmsrl_amd_safe(0xc0011005, val);
+			checking_wrmsrl(0xc0011005, val);
 			rdmsrl(0xc0011005, val);
 			if (val & (1ULL << 54)) {
 				set_cpu_cap(c, X86_FEATURE_TOPOEXT);
-- 
1.7.9.3.362.g71319


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTEo-0004UI-Rc; Fri, 01 Jun 2012 14:54:02 +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 1SaTEo-0004Ty-2k
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:54:02 +0000
Received: from [85.158.143.99:33938] by server-2.bemta-4.messagelabs.com id
	EA/81-11595-787D8CF4; Fri, 01 Jun 2012 14:53:59 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338562437!28619101!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32628 invoked from network); 1 Jun 2012 14:53:58 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 14:53:58 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q51ErVAh001678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Fri, 1 Jun 2012 07:53:32 -0700
Message-ID: <4FC8D766.1070700@zytor.com>
Date: Fri, 01 Jun 2012 07:53:26 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
X-Enigmail-Version: 1.4.1
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 07:52 AM, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
> 
> Ok,
> 
> the following patchset should take care of all the {rd,wr}msrl_amd_safe
> headaches we had this week. After it is applied, the AMD-specific
> variants become private to amd.c and issue a warning when used on
> anything else beside K8.
> 
> This also contains the two patches from Andre which cleanup the PV-side
> of things.
> 

Looks good.  This can be for 3.6, right (no immediate urgency)?

	-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 Jun 01 14:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTEo-0004UI-Rc; Fri, 01 Jun 2012 14:54:02 +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 1SaTEo-0004Ty-2k
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:54:02 +0000
Received: from [85.158.143.99:33938] by server-2.bemta-4.messagelabs.com id
	EA/81-11595-787D8CF4; Fri, 01 Jun 2012 14:53:59 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338562437!28619101!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32628 invoked from network); 1 Jun 2012 14:53:58 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 14:53:58 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q51ErVAh001678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Fri, 1 Jun 2012 07:53:32 -0700
Message-ID: <4FC8D766.1070700@zytor.com>
Date: Fri, 01 Jun 2012 07:53:26 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
In-Reply-To: <1338562358-28182-1-git-send-email-bp@amd64.org>
X-Enigmail-Version: 1.4.1
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 07:52 AM, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
> 
> Ok,
> 
> the following patchset should take care of all the {rd,wr}msrl_amd_safe
> headaches we had this week. After it is applied, the AMD-specific
> variants become private to amd.c and issue a warning when used on
> anything else beside K8.
> 
> This also contains the two patches from Andre which cleanup the PV-side
> of things.
> 

Looks good.  This can be for 3.6, right (no immediate urgency)?

	-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 Jun 01 14:56:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:56: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 1SaTGb-0004jw-BF; Fri, 01 Jun 2012 14:55: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 1SaTGZ-0004jN-TP
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:55:52 +0000
Received: from [85.158.139.83:42772] by server-10.bemta-5.messagelabs.com id
	E5/80-22179-7F7D8CF4; Fri, 01 Jun 2012 14:55:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338562549!31060776!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22602 invoked from network); 1 Jun 2012 14:55:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 14:55:50 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo4) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h07563o51EOsXf
	for <xen-devel@lists.xensource.com>;
	Fri, 1 Jun 2012 16:55:49 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id BE80C18637
	for <xen-devel@lists.xensource.com>;
	Fri,  1 Jun 2012 16:55:46 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
Message-Id: <fde8ad0252ee6ddb8d71.1338562529@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 01 Jun 2012 16:55:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1338562334 -7200
# Node ID fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
# Parent  3b4346d6002e9ffcd4a9f50b031bd2a77b16b1dd
xl.cfg: document the maxmem= option

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

diff -r 3b4346d6002e -r fde8ad0252ee docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -174,6 +174,16 @@ Honoured by the sedf scheduler.
 
 Start the guest with MBYTES megabytes of RAM.
 
+=item B<maxmem=MBYTES>
+
+Specifies the maximum amount of memory a guest can ever see.
+The value of B<maxmem=> must be equal or greater than B<memory=>.
+
+In combination with B<memory=> it will start the guest "pre-ballooned",
+if the values of B<memory=> and B<maxmem=> differ.
+A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
+it will crash.
+
 =item B<on_poweroff="ACTION">
 
 Specifies what should be done with the domain if it shuts itself down.
@@ -971,10 +981,6 @@ XXX
 
 XXX
 
-=item B<maxmem=NUMBER>
-
-XXX
-
 =item B<nodes=XXX>
 
 XXX

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:56:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:56: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 1SaTGb-0004jw-BF; Fri, 01 Jun 2012 14:55: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 1SaTGZ-0004jN-TP
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:55:52 +0000
Received: from [85.158.139.83:42772] by server-10.bemta-5.messagelabs.com id
	E5/80-22179-7F7D8CF4; Fri, 01 Jun 2012 14:55:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338562549!31060776!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22602 invoked from network); 1 Jun 2012 14:55:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 14:55:50 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo4) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h07563o51EOsXf
	for <xen-devel@lists.xensource.com>;
	Fri, 1 Jun 2012 16:55:49 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id BE80C18637
	for <xen-devel@lists.xensource.com>;
	Fri,  1 Jun 2012 16:55:46 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
Message-Id: <fde8ad0252ee6ddb8d71.1338562529@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 01 Jun 2012 16:55:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1338562334 -7200
# Node ID fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
# Parent  3b4346d6002e9ffcd4a9f50b031bd2a77b16b1dd
xl.cfg: document the maxmem= option

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

diff -r 3b4346d6002e -r fde8ad0252ee docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -174,6 +174,16 @@ Honoured by the sedf scheduler.
 
 Start the guest with MBYTES megabytes of RAM.
 
+=item B<maxmem=MBYTES>
+
+Specifies the maximum amount of memory a guest can ever see.
+The value of B<maxmem=> must be equal or greater than B<memory=>.
+
+In combination with B<memory=> it will start the guest "pre-ballooned",
+if the values of B<memory=> and B<maxmem=> differ.
+A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
+it will crash.
+
 =item B<on_poweroff="ACTION">
 
 Specifies what should be done with the domain if it shuts itself down.
@@ -971,10 +981,6 @@ XXX
 
 XXX
 
-=item B<maxmem=NUMBER>
-
-XXX
-
 =item B<nodes=XXX>
 
 XXX

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTHn-0004v9-Qi; Fri, 01 Jun 2012 14:57:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTHm-0004ur-74
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:57:06 +0000
Received: from [193.109.254.147:24910] by server-10.bemta-14.messagelabs.com
	id C9/94-27843-148D8CF4; Fri, 01 Jun 2012 14:57:05 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1338562624!4453008!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11375 invoked from network); 1 Jun 2012 14:57:05 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-6.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 14:57:05 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id C48C6C0047F;
	Fri,  1 Jun 2012 16:57:04 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id G6akymkGBvtM; Fri,  1 Jun 2012 16:57:04 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:57:04 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 8344949C20C;
	Fri,  1 Jun 2012 15:57:04 +0100 (BST)
Date: Fri, 1 Jun 2012 16:57:32 +0200
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120601145732.GA28216@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<4FC8D766.1070700@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FC8D766.1070700@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 07:53:26AM -0700, H. Peter Anvin wrote:
> Looks good.  This can be for 3.6, right (no immediate urgency)?

None on arch/x86/ - simply correctness fixes.

And I'm assuming since you took Konrad's patch, there are no pending
issues for xen either.

So yeah, this can wait for 3.6, IMHO.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTHn-0004v9-Qi; Fri, 01 Jun 2012 14:57:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1SaTHm-0004ur-74
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:57:06 +0000
Received: from [193.109.254.147:24910] by server-10.bemta-14.messagelabs.com
	id C9/94-27843-148D8CF4; Fri, 01 Jun 2012 14:57:05 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1338562624!4453008!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11375 invoked from network); 1 Jun 2012 14:57:05 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-6.tower-27.messagelabs.com with SMTP;
	1 Jun 2012 14:57:05 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id C48C6C0047F;
	Fri,  1 Jun 2012 16:57:04 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id G6akymkGBvtM; Fri,  1 Jun 2012 16:57:04 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Fri,  1 Jun 2012 16:57:04 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 8344949C20C;
	Fri,  1 Jun 2012 15:57:04 +0100 (BST)
Date: Fri, 1 Jun 2012 16:57:32 +0200
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120601145732.GA28216@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<4FC8D766.1070700@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FC8D766.1070700@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 07:53:26AM -0700, H. Peter Anvin wrote:
> Looks good.  This can be for 3.6, right (no immediate urgency)?

None on arch/x86/ - simply correctness fixes.

And I'm assuming since you took Konrad's patch, there are no pending
issues for xen either.

So yeah, this can wait for 3.6, IMHO.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:59:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:59: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 1SaTKH-0005CF-Cz; Fri, 01 Jun 2012 14:59:41 +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 1SaTKG-0005C3-5S
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:59:40 +0000
Received: from [85.158.138.51:42078] by server-1.bemta-3.messagelabs.com id
	E5/11-06526-BD8D8CF4; Fri, 01 Jun 2012 14:59:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338562778!22282633!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13611 invoked from network); 1 Jun 2012 14:59:38 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 14:59:38 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo69) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e00cb5o51ERjAq ;
	Fri, 1 Jun 2012 16:59:38 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E752018638; Fri,  1 Jun 2012 16:59:35 +0200 (CEST)
Date: Fri, 1 Jun 2012 16:59:35 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120601145935.GA4464@aepfle.de>
References: <4dad9647a0963a2665cc.1338476667@probook.site>
	<1338548745.17466.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338548745.17466.86.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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 Fri, Jun 01, Ian Campbell wrote:

> On Thu, 2012-05-31 at 16:04 +0100, Olaf Hering wrote:
> > +=item B<maxmem=MBYTES>
> > +
> > +Specifies the maximum amount of memory a guest can ever see.
> > +The value of maxmem= must be equal or greater than memory=.
> > +In combination with the memory= option it will start the guest "pre-ballooned".
> > +In a HVM guest it will enable the PoD (populate on demand) mode, iff the values of memory= and maxmem= differ.
> > +The guest needs a balloon driver in this case, without a balloon driver it will crash.
> 
> "iff" has proven to be confusing in the past (we keep getting "fix typo"
> patches for existing ones) maybe just spell it out? Otherwise Ack on the
> text. Although may add a note that booting a PV guest "pre-ballooned"
> Just Works?

I just send a simplified version of this patch. Mentioning PoD is not
really needed because its an hypervisor internal feature.

> Formatting wise some of these lines are very long. Can you wrap to 80
> columns please.

Done.

> Also why have you wrapped this as one sentence per line rather than
> wrapping it as paragraphs (which should have blank lines between them)?

Just a habit.

> I think maxmem= should be B<maxmem=> and the same for memory=.

Done.

Olaf

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 14:59:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 14:59: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 1SaTKH-0005CF-Cz; Fri, 01 Jun 2012 14:59:41 +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 1SaTKG-0005C3-5S
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 14:59:40 +0000
Received: from [85.158.138.51:42078] by server-1.bemta-3.messagelabs.com id
	E5/11-06526-BD8D8CF4; Fri, 01 Jun 2012 14:59:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338562778!22282633!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjEyMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13611 invoked from network); 1 Jun 2012 14:59:38 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 14:59:38 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo69) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e00cb5o51ERjAq ;
	Fri, 1 Jun 2012 16:59:38 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E752018638; Fri,  1 Jun 2012 16:59:35 +0200 (CEST)
Date: Fri, 1 Jun 2012 16:59:35 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120601145935.GA4464@aepfle.de>
References: <4dad9647a0963a2665cc.1338476667@probook.site>
	<1338548745.17466.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338548745.17466.86.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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 Fri, Jun 01, Ian Campbell wrote:

> On Thu, 2012-05-31 at 16:04 +0100, Olaf Hering wrote:
> > +=item B<maxmem=MBYTES>
> > +
> > +Specifies the maximum amount of memory a guest can ever see.
> > +The value of maxmem= must be equal or greater than memory=.
> > +In combination with the memory= option it will start the guest "pre-ballooned".
> > +In a HVM guest it will enable the PoD (populate on demand) mode, iff the values of memory= and maxmem= differ.
> > +The guest needs a balloon driver in this case, without a balloon driver it will crash.
> 
> "iff" has proven to be confusing in the past (we keep getting "fix typo"
> patches for existing ones) maybe just spell it out? Otherwise Ack on the
> text. Although may add a note that booting a PV guest "pre-ballooned"
> Just Works?

I just send a simplified version of this patch. Mentioning PoD is not
really needed because its an hypervisor internal feature.

> Formatting wise some of these lines are very long. Can you wrap to 80
> columns please.

Done.

> Also why have you wrapped this as one sentence per line rather than
> wrapping it as paragraphs (which should have blank lines between them)?

Just a habit.

> I think maxmem= should be B<maxmem=> and the same for memory=.

Done.

Olaf

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 15:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaTRg-0005oS-RO; Fri, 01 Jun 2012 15:07:20 +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 1SaTRf-0005oN-7V
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:07:19 +0000
Received: from [85.158.138.51:52059] by server-9.bemta-3.messagelabs.com id
	0D/3F-21565-6AAD8CF4; Fri, 01 Jun 2012 15:07:18 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338563235!27514597!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20407 invoked from network); 1 Jun 2012 15:07:17 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 15:07:17 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q51F70tH006010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Fri, 1 Jun 2012 08:07:01 -0700
Message-ID: <4FC8DA8F.4070602@zytor.com>
Date: Fri, 01 Jun 2012 08:06:55 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<4FC8D766.1070700@zytor.com>
	<20120601145732.GA28216@aftab.osrc.amd.com>
In-Reply-To: <20120601145732.GA28216@aftab.osrc.amd.com>
X-Enigmail-Version: 1.4.1
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 07:57 AM, Borislav Petkov wrote:
> On Fri, Jun 01, 2012 at 07:53:26AM -0700, H. Peter Anvin wrote:
>> Looks good.  This can be for 3.6, right (no immediate urgency)?
> 
> None on arch/x86/ - simply correctness fixes.
> 
> And I'm assuming since you took Konrad's patch, there are no pending
> issues for xen either.
> 
> So yeah, this can wait for 3.6, IMHO.
> 

Great!  Will queue up shortly.

	-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 Jun 01 15:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaTRg-0005oS-RO; Fri, 01 Jun 2012 15:07:20 +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 1SaTRf-0005oN-7V
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:07:19 +0000
Received: from [85.158.138.51:52059] by server-9.bemta-3.messagelabs.com id
	0D/3F-21565-6AAD8CF4; Fri, 01 Jun 2012 15:07:18 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338563235!27514597!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20407 invoked from network); 1 Jun 2012 15:07:17 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 15:07:17 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q51F70tH006010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Fri, 1 Jun 2012 08:07:01 -0700
Message-ID: <4FC8DA8F.4070602@zytor.com>
Date: Fri, 01 Jun 2012 08:06:55 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<4FC8D766.1070700@zytor.com>
	<20120601145732.GA28216@aftab.osrc.amd.com>
In-Reply-To: <20120601145732.GA28216@aftab.osrc.amd.com>
X-Enigmail-Version: 1.4.1
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/4] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 07:57 AM, Borislav Petkov wrote:
> On Fri, Jun 01, 2012 at 07:53:26AM -0700, H. Peter Anvin wrote:
>> Looks good.  This can be for 3.6, right (no immediate urgency)?
> 
> None on arch/x86/ - simply correctness fixes.
> 
> And I'm assuming since you took Konrad's patch, there are no pending
> issues for xen either.
> 
> So yeah, this can wait for 3.6, IMHO.
> 

Great!  Will queue up shortly.

	-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 Jun 01 15:17:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:17: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 1SaTbG-00061F-4J; Fri, 01 Jun 2012 15:17:14 +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 1SaTbE-000617-8S
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:17:12 +0000
Received: from [85.158.143.99:25931] by server-3.bemta-4.messagelabs.com id
	99/33-04252-7FCD8CF4; Fri, 01 Jun 2012 15:17:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338563827!25670607!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21954 invoked from network); 1 Jun 2012 15:17:09 -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;
	1 Jun 2012 15:17:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197203174"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:17:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:17:05 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SaTZL-0005KI-Sq;
	Fri, 01 Jun 2012 16:15:15 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 1 Jun 2012 16:14:54 +0100
Message-ID: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/mm: do direct hypercall in xen_set_pte() if
	batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

In xen_set_pte() if batching is unavailable (because the caller is in
an interrupt context such as handling a page fault) it would fall back
to using native_set_pte() and trapping and emulating the PTE write.

On 32-bit guests this requires two traps for each PTE write (one for
each dword of the PTE).  Instead, do one mmu_update hypercall
directly.

This significantly improves page fault performance in 32-bit PV
guests.

lmbench3 test  Before    After     Improvement
----------------------------------------------
lat_pagefault  3.18 us   2.32 us   27%
lat_proc fork  356 us    313.3 us  11%

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/mmu.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b8e2794..3bf5dfa 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -308,8 +308,20 @@ static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
 
 static inline void __xen_set_pte(pte_t *ptep, pte_t pteval)
 {
-	if (!xen_batched_set_pte(ptep, pteval))
-		native_set_pte(ptep, pteval);
+	if (!xen_batched_set_pte(ptep, pteval)) {
+		/*
+		 * Could call native_set_pte() here and trap and
+		 * emulate the PTE write but with 32-bit guests this
+		 * needs two traps (one for each of the two 32-bit
+		 * words in the PTE) so do one hypercall directly
+		 * instead.
+		 */
+		struct mmu_update u;
+
+		u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
+		u.val = pte_val_ma(pteval);
+		HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF);
+	}
 }
 
 static void xen_set_pte(pte_t *ptep, pte_t pteval)
-- 
1.7.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 Jun 01 15:17:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:17: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 1SaTbG-00061F-4J; Fri, 01 Jun 2012 15:17:14 +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 1SaTbE-000617-8S
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:17:12 +0000
Received: from [85.158.143.99:25931] by server-3.bemta-4.messagelabs.com id
	99/33-04252-7FCD8CF4; Fri, 01 Jun 2012 15:17:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338563827!25670607!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21954 invoked from network); 1 Jun 2012 15:17:09 -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;
	1 Jun 2012 15:17:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197203174"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:17:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:17:05 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SaTZL-0005KI-Sq;
	Fri, 01 Jun 2012 16:15:15 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 1 Jun 2012 16:14:54 +0100
Message-ID: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/mm: do direct hypercall in xen_set_pte() if
	batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

In xen_set_pte() if batching is unavailable (because the caller is in
an interrupt context such as handling a page fault) it would fall back
to using native_set_pte() and trapping and emulating the PTE write.

On 32-bit guests this requires two traps for each PTE write (one for
each dword of the PTE).  Instead, do one mmu_update hypercall
directly.

This significantly improves page fault performance in 32-bit PV
guests.

lmbench3 test  Before    After     Improvement
----------------------------------------------
lat_pagefault  3.18 us   2.32 us   27%
lat_proc fork  356 us    313.3 us  11%

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/mmu.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b8e2794..3bf5dfa 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -308,8 +308,20 @@ static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
 
 static inline void __xen_set_pte(pte_t *ptep, pte_t pteval)
 {
-	if (!xen_batched_set_pte(ptep, pteval))
-		native_set_pte(ptep, pteval);
+	if (!xen_batched_set_pte(ptep, pteval)) {
+		/*
+		 * Could call native_set_pte() here and trap and
+		 * emulate the PTE write but with 32-bit guests this
+		 * needs two traps (one for each of the two 32-bit
+		 * words in the PTE) so do one hypercall directly
+		 * instead.
+		 */
+		struct mmu_update u;
+
+		u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
+		u.val = pte_val_ma(pteval);
+		HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF);
+	}
 }
 
 static void xen_set_pte(pte_t *ptep, pte_t pteval)
-- 
1.7.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 Jun 01 15:39:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:39: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 1SaTwH-0006af-GK; Fri, 01 Jun 2012 15:38: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 1SaTwF-0006aa-UN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:38:56 +0000
Received: from [85.158.139.83:40366] by server-11.bemta-5.messagelabs.com id
	27/4E-12711-F02E8CF4; Fri, 01 Jun 2012 15:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1338565134!27633678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26833 invoked from network); 1 Jun 2012 15:38:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12791291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 15:38:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	16:38:34 +0100
Message-ID: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 1 Jun 2012 16:38:33 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/38] arm: boot a dom1 to "Calibrating delay
	loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 enormous dump, I seem to have accumulated a boat load of
stuff in my tree...

There's actually a bunch of random guff in here, but the main bit is
xc_dom code in libxc to build a dom1 from a ARM zImage and enough
hypervisor support to run it to:
        [    0.000000] Linux version 3.2.0-rc5-arm-native+ (ianc@drall) (gcc version 4.6.0 (GCC) ) #174 Thu May 24 15:44:30 BST 2012
        [    0.000000] CPU: ARMv7 Processor [410fc0f0] revision 0 (ARMv7), cr=10c53c7d
        [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
        [    0.000000] Machine: ARM Versatile Express, model: V2P-AEMv7A
        [    0.000000] bootconsole [xenboot0] enabled
        [    0.000000] Memory policy: ECC disabled, Data cache writeback
        [    0.000000] Architected local timer running at 100.00MHz.
        [    0.000000] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949ms
        [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
        [    0.000000] Kernel command line: earlyprintk=xen console=hvc0
        [    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
        [    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
        [    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
        [    0.000000] Memory: 128MB = 128MB total
        [    0.000000] Memory: 126256k/126256k available, 4816k reserved, 0K highmem
        [    0.000000] Virtual kernel memory layout:
        [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
        [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
        [    0.000000]     vmalloc : 0xc8800000 - 0xf8000000   ( 760 MB)
        [    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
        [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
        [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
        [    0.000000]       .text : 0xc0008000 - 0xc032cce0   (3220 kB)
        [    0.000000]       .init : 0xc032d000 - 0xc034e000   ( 132 kB)
        [    0.000000]       .data : 0xc034e000 - 0xc036f400   ( 133 kB)
        [    0.000000]        .bss : 0xc036f424 - 0xc038e0ec   ( 124 kB)
        [    0.000000] NR_IRQS:256
        [    0.000000] Console: colour dummy device 80x30
        [    0.191514] Calibrating delay loop... 

(Stefano is looking at virtual timers and interrupt injection as we
speak...)

There is some non-ARM impact, specifically teaching xc_dom_* about the
idea that RAM might not start at 0x000 (on the ARM platform we are
similar too RAM starts at 0x80000000), I think that makes at least the
libxc parts non-4.2 material at this stage.

There are also three (more than usually) hacky patches needed to get to
this point:
        HACK: arm: initial XENMAPSPACE_gmfn_foreign
        HACK: add simple xcbuild
        HACK: arm: disable hypercall continuations.
which I'm not proposing but I'm including because it doesn't work
without them ;-).

The rest I think is fair game for acking and cherry-picking the
acceptable bits for commit.

I still need to cleanup the Linux side of this, that probably won't
happen today and these patches probably don't work without those
changes... FWIW the XENMAPSPACE_gmfn_foreign thing is an even bigger
hack there. Ultimately we should do the same thing as hybrid x86

Ian.

The following changes since commit 5fcec8e92ea02240c2737c4fa982027cef053401:

  libxl: fix typos in libxl_cpuid_parse_config (2012-06-01 12:06:22 +0100)

are available in the git repository at:

  git://xenbits.xen.org/people/ianc/xen-unstable.git devel/arm

for you to fetch changes up to 5177d39f17feb3d5ccdedb976074cb0eee62ee69:

  HACK: arm: disable hypercall continuations. (2012-06-01 15:14:28 +0000)

----------------------------------------------------------------
Ian Campbell (38):
      arm: allocate top level p2m page for all non-idle domains
      arm: handy function to print a walk of the hypervisor page tables
      arm: handy function to print a walk of a domain's p2m.
      arm: correct and expand TLB flush CP15 registers
      arm: restore stack on return from trap.
      arm: enable interrupts while handling traps
      arm: hook up domctl and memory_op
      arm: allocate and setup a guest vcpu.
      arm: print domid as part of debug trap
      arm: remove unnecessarily verbose print from p2m_load_VTTBR
      arm: implement p2m lookup
      arm: remove hard tabs from init_idle_domain
      arm: stub out sync_vcpu_execstate
      arm: do not set max_vcpus = 8 in arch_domain_create.
      arm: implement stub version of flush_tlb_mask.
      arm: Add simple cpu_{sibling,core}_mask
      arm: allow p2m to be created with specific MATTR.
      arm: implement vpl011 (UART) emulator.
      arm: context switch a bunch of guest state.
      arm: dump a page table walk when va_to_par fails.
      arm: dump guest s1 walk on data abort which is not a stage 2 issue.
      arm: implement vcpu_show_execution_state
      arm: use correct attributes for mappings in copy_from_paddr()
      arm: map fixmaps non-executable.
      arm: remove old identity map of boot paddr when we are done with it.
      arm: fix locking in create_p2m_entries
      arm: split pending SPIs (global) out from pending PPIs and SGIs (per CPU)
      arm: map GICV in all domains, not just dom0.
      arm: delay enabling data-cache until paging enabled.
      arm: Upgrade guest barriers to Outer-Shareable. Enable Protected Table Walk.
      arm: gic.lock can be taken in interrupt context, so lock appropriately.
      arm: context switch virtual timer registers
      arm: the hyp timer seems to work now,  default to using it.
      HACK: arm: initial XENMAPSPACE_gmfn_foreign
      arm: move PSR flag definitions into interface, for tools use.
      libxc: add ARM support to xc_dom (PV domain building)
      HACK: add simple xcbuild
      HACK: arm: disable hypercall continuations.

 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 tools/xcutils/Makefile               |    6 +-
 tools/xcutils/xcbuild.c              |  100 +++++++++++++++
 xen/arch/arm/Makefile                |    1 +
 xen/arch/arm/domain.c                |  232 +++++++++++++++++++++++++++++++---
 xen/arch/arm/domain_build.c          |    7 +-
 xen/arch/arm/dummy.S                 |    8 --
 xen/arch/arm/entry.S                 |   23 +++-
 xen/arch/arm/gic.c                   |   56 ++++++---
 xen/arch/arm/gic.h                   |   11 ++-
 xen/arch/arm/head.S                  |    9 +-
 xen/arch/arm/io.c                    |    1 +
 xen/arch/arm/io.h                    |    1 +
 xen/arch/arm/kernel.c                |    8 +-
 xen/arch/arm/mm.c                    |   94 +++++++++++++--
 xen/arch/arm/p2m.c                   |  123 ++++++++++++++++--
 xen/arch/arm/setup.c                 |   15 ++-
 xen/arch/arm/smp.c                   |    9 ++
 xen/arch/arm/smpboot.c               |    5 +
 xen/arch/arm/time.c                  |    8 +-
 xen/arch/arm/traps.c                 |  145 +++++++++++++++++++---
 xen/arch/arm/vgic.c                  |   17 ++-
 xen/arch/arm/vpl011.c                |  155 +++++++++++++++++++++++
 xen/arch/arm/vpl011.h                |   34 +++++
 xen/arch/x86/mm.c                    |    2 +
 xen/include/asm-arm/cpregs.h         |   43 ++++++-
 xen/include/asm-arm/domain.h         |   56 ++++++++-
 xen/include/asm-arm/p2m.h            |    3 +
 xen/include/asm-arm/page.h           |   17 ++-
 xen/include/asm-arm/processor.h      |   26 +---
 xen/include/asm-arm/setup.h          |    2 +-
 xen/include/asm-arm/system.h         |    2 +-
 xen/include/public/arch-arm.h        |   36 ++++--
 xen/include/public/memory.h          |   12 +-
 xen/include/xen/sched.h              |    4 +
 40 files changed, 1426 insertions(+), 169 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c
 create mode 100644 tools/xcutils/xcbuild.c
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 15:39:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:39: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 1SaTwH-0006af-GK; Fri, 01 Jun 2012 15:38: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 1SaTwF-0006aa-UN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:38:56 +0000
Received: from [85.158.139.83:40366] by server-11.bemta-5.messagelabs.com id
	27/4E-12711-F02E8CF4; Fri, 01 Jun 2012 15:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1338565134!27633678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26833 invoked from network); 1 Jun 2012 15:38:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12791291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 15:38:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	16:38:34 +0100
Message-ID: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 1 Jun 2012 16:38:33 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/38] arm: boot a dom1 to "Calibrating delay
	loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 enormous dump, I seem to have accumulated a boat load of
stuff in my tree...

There's actually a bunch of random guff in here, but the main bit is
xc_dom code in libxc to build a dom1 from a ARM zImage and enough
hypervisor support to run it to:
        [    0.000000] Linux version 3.2.0-rc5-arm-native+ (ianc@drall) (gcc version 4.6.0 (GCC) ) #174 Thu May 24 15:44:30 BST 2012
        [    0.000000] CPU: ARMv7 Processor [410fc0f0] revision 0 (ARMv7), cr=10c53c7d
        [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
        [    0.000000] Machine: ARM Versatile Express, model: V2P-AEMv7A
        [    0.000000] bootconsole [xenboot0] enabled
        [    0.000000] Memory policy: ECC disabled, Data cache writeback
        [    0.000000] Architected local timer running at 100.00MHz.
        [    0.000000] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949ms
        [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
        [    0.000000] Kernel command line: earlyprintk=xen console=hvc0
        [    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
        [    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
        [    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
        [    0.000000] Memory: 128MB = 128MB total
        [    0.000000] Memory: 126256k/126256k available, 4816k reserved, 0K highmem
        [    0.000000] Virtual kernel memory layout:
        [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
        [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
        [    0.000000]     vmalloc : 0xc8800000 - 0xf8000000   ( 760 MB)
        [    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
        [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
        [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
        [    0.000000]       .text : 0xc0008000 - 0xc032cce0   (3220 kB)
        [    0.000000]       .init : 0xc032d000 - 0xc034e000   ( 132 kB)
        [    0.000000]       .data : 0xc034e000 - 0xc036f400   ( 133 kB)
        [    0.000000]        .bss : 0xc036f424 - 0xc038e0ec   ( 124 kB)
        [    0.000000] NR_IRQS:256
        [    0.000000] Console: colour dummy device 80x30
        [    0.191514] Calibrating delay loop... 

(Stefano is looking at virtual timers and interrupt injection as we
speak...)

There is some non-ARM impact, specifically teaching xc_dom_* about the
idea that RAM might not start at 0x000 (on the ARM platform we are
similar too RAM starts at 0x80000000), I think that makes at least the
libxc parts non-4.2 material at this stage.

There are also three (more than usually) hacky patches needed to get to
this point:
        HACK: arm: initial XENMAPSPACE_gmfn_foreign
        HACK: add simple xcbuild
        HACK: arm: disable hypercall continuations.
which I'm not proposing but I'm including because it doesn't work
without them ;-).

The rest I think is fair game for acking and cherry-picking the
acceptable bits for commit.

I still need to cleanup the Linux side of this, that probably won't
happen today and these patches probably don't work without those
changes... FWIW the XENMAPSPACE_gmfn_foreign thing is an even bigger
hack there. Ultimately we should do the same thing as hybrid x86

Ian.

The following changes since commit 5fcec8e92ea02240c2737c4fa982027cef053401:

  libxl: fix typos in libxl_cpuid_parse_config (2012-06-01 12:06:22 +0100)

are available in the git repository at:

  git://xenbits.xen.org/people/ianc/xen-unstable.git devel/arm

for you to fetch changes up to 5177d39f17feb3d5ccdedb976074cb0eee62ee69:

  HACK: arm: disable hypercall continuations. (2012-06-01 15:14:28 +0000)

----------------------------------------------------------------
Ian Campbell (38):
      arm: allocate top level p2m page for all non-idle domains
      arm: handy function to print a walk of the hypervisor page tables
      arm: handy function to print a walk of a domain's p2m.
      arm: correct and expand TLB flush CP15 registers
      arm: restore stack on return from trap.
      arm: enable interrupts while handling traps
      arm: hook up domctl and memory_op
      arm: allocate and setup a guest vcpu.
      arm: print domid as part of debug trap
      arm: remove unnecessarily verbose print from p2m_load_VTTBR
      arm: implement p2m lookup
      arm: remove hard tabs from init_idle_domain
      arm: stub out sync_vcpu_execstate
      arm: do not set max_vcpus = 8 in arch_domain_create.
      arm: implement stub version of flush_tlb_mask.
      arm: Add simple cpu_{sibling,core}_mask
      arm: allow p2m to be created with specific MATTR.
      arm: implement vpl011 (UART) emulator.
      arm: context switch a bunch of guest state.
      arm: dump a page table walk when va_to_par fails.
      arm: dump guest s1 walk on data abort which is not a stage 2 issue.
      arm: implement vcpu_show_execution_state
      arm: use correct attributes for mappings in copy_from_paddr()
      arm: map fixmaps non-executable.
      arm: remove old identity map of boot paddr when we are done with it.
      arm: fix locking in create_p2m_entries
      arm: split pending SPIs (global) out from pending PPIs and SGIs (per CPU)
      arm: map GICV in all domains, not just dom0.
      arm: delay enabling data-cache until paging enabled.
      arm: Upgrade guest barriers to Outer-Shareable. Enable Protected Table Walk.
      arm: gic.lock can be taken in interrupt context, so lock appropriately.
      arm: context switch virtual timer registers
      arm: the hyp timer seems to work now,  default to using it.
      HACK: arm: initial XENMAPSPACE_gmfn_foreign
      arm: move PSR flag definitions into interface, for tools use.
      libxc: add ARM support to xc_dom (PV domain building)
      HACK: add simple xcbuild
      HACK: arm: disable hypercall continuations.

 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 tools/xcutils/Makefile               |    6 +-
 tools/xcutils/xcbuild.c              |  100 +++++++++++++++
 xen/arch/arm/Makefile                |    1 +
 xen/arch/arm/domain.c                |  232 +++++++++++++++++++++++++++++++---
 xen/arch/arm/domain_build.c          |    7 +-
 xen/arch/arm/dummy.S                 |    8 --
 xen/arch/arm/entry.S                 |   23 +++-
 xen/arch/arm/gic.c                   |   56 ++++++---
 xen/arch/arm/gic.h                   |   11 ++-
 xen/arch/arm/head.S                  |    9 +-
 xen/arch/arm/io.c                    |    1 +
 xen/arch/arm/io.h                    |    1 +
 xen/arch/arm/kernel.c                |    8 +-
 xen/arch/arm/mm.c                    |   94 +++++++++++++--
 xen/arch/arm/p2m.c                   |  123 ++++++++++++++++--
 xen/arch/arm/setup.c                 |   15 ++-
 xen/arch/arm/smp.c                   |    9 ++
 xen/arch/arm/smpboot.c               |    5 +
 xen/arch/arm/time.c                  |    8 +-
 xen/arch/arm/traps.c                 |  145 +++++++++++++++++++---
 xen/arch/arm/vgic.c                  |   17 ++-
 xen/arch/arm/vpl011.c                |  155 +++++++++++++++++++++++
 xen/arch/arm/vpl011.h                |   34 +++++
 xen/arch/x86/mm.c                    |    2 +
 xen/include/asm-arm/cpregs.h         |   43 ++++++-
 xen/include/asm-arm/domain.h         |   56 ++++++++-
 xen/include/asm-arm/p2m.h            |    3 +
 xen/include/asm-arm/page.h           |   17 ++-
 xen/include/asm-arm/processor.h      |   26 +---
 xen/include/asm-arm/setup.h          |    2 +-
 xen/include/asm-arm/system.h         |    2 +-
 xen/include/public/arch-arm.h        |   36 ++++--
 xen/include/public/memory.h          |   12 +-
 xen/include/xen/sched.h              |    4 +
 40 files changed, 1426 insertions(+), 169 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c
 create mode 100644 tools/xcutils/xcbuild.c
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxZ-0006fx-SH; Fri, 01 Jun 2012 15:40: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 1SaTxX-0006eW-3e
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:15 +0000
Received: from [85.158.138.51:38264] by server-7.bemta-3.messagelabs.com id
	36/B4-22601-E52E8CF4; Fri, 01 Jun 2012 15:40:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338565210!27520903!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7172 invoked from network); 1 Jun 2012 15:40:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:40:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547684"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-6S;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:39 +0000
Message-ID: <1338565207-2888-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/38] arm: remove unnecessarily verbose print
	from p2m_load_VTTBR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/p2m.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fdbecbc..095e608 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -47,8 +47,6 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
-
     WRITE_CP64(vttbr, VTTBR);
     isb(); /* Ensure update is visible */
 }
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxZ-0006fx-SH; Fri, 01 Jun 2012 15:40: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 1SaTxX-0006eW-3e
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:15 +0000
Received: from [85.158.138.51:38264] by server-7.bemta-3.messagelabs.com id
	36/B4-22601-E52E8CF4; Fri, 01 Jun 2012 15:40:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338565210!27520903!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7172 invoked from network); 1 Jun 2012 15:40:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:40:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547684"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-6S;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:39 +0000
Message-ID: <1338565207-2888-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/38] arm: remove unnecessarily verbose print
	from p2m_load_VTTBR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/p2m.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fdbecbc..095e608 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -47,8 +47,6 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
-
     WRITE_CP64(vttbr, VTTBR);
     isb(); /* Ensure update is visible */
 }
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxY-0006f9-9i; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eL-CF
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [85.158.138.51:57883] by server-12.bemta-3.messagelabs.com id
	AF/90-29860-D52E8CF4; Fri, 01 Jun 2012 15:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338565210!27520903!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7146 invoked from network); 1 Jun 2012 15:40:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547683"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-55;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:38 +0000
Message-ID: <1338565207-2888-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/38] arm: print domid as part of debug trap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5d8b7f9..40bb375 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -388,25 +388,26 @@ static arm_hypercall_t *arm_hypercall_table[] = {
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
     uint32_t reg, *r;
-
+    uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = &regs->r0 + reg;
-        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+               domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("Reached %08"PRIx32"\n", regs->pc);
+        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
         break;
     case 0xfe:
         printk("%c", (char)(regs->r0 & 0xff));
         break;
     case 0xff:
-        printk("DEBUG\n");
+        printk("DOM%d: DEBUG\n", domid);
         show_execution_state(regs);
         break;
     default:
-        panic("Unhandled debug trap %#x\n", code);
+        panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
         break;
     }
 }
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxY-0006f9-9i; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eL-CF
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [85.158.138.51:57883] by server-12.bemta-3.messagelabs.com id
	AF/90-29860-D52E8CF4; Fri, 01 Jun 2012 15:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338565210!27520903!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7146 invoked from network); 1 Jun 2012 15:40:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547683"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-55;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:38 +0000
Message-ID: <1338565207-2888-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/38] arm: print domid as part of debug trap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5d8b7f9..40bb375 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -388,25 +388,26 @@ static arm_hypercall_t *arm_hypercall_table[] = {
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
     uint32_t reg, *r;
-
+    uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = &regs->r0 + reg;
-        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+               domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("Reached %08"PRIx32"\n", regs->pc);
+        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
         break;
     case 0xfe:
         printk("%c", (char)(regs->r0 & 0xff));
         break;
     case 0xff:
-        printk("DEBUG\n");
+        printk("DOM%d: DEBUG\n", domid);
         show_execution_state(regs);
         break;
     default:
-        panic("Unhandled debug trap %#x\n", code);
+        panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
         break;
     }
 }
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxZ-0006fX-1u; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eU-Lf
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [193.109.254.147:18261] by server-12.bemta-14.messagelabs.com
	id A9/82-12643-D52E8CF4; Fri, 01 Jun 2012 15:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338565210!7252174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16146 invoked from network); 1 Jun 2012 15:40:12 -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 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206653"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-0n;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:36 +0000
Message-ID: <1338565207-2888-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/38] arm: hook up domctl and memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5ed754f..5d8b7f9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -373,6 +373,8 @@ typedef unsigned long arm_hypercall_t(
     [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
 
 static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(memory_op),
+    HYPERCALL(domctl),
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxZ-0006fX-1u; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eU-Lf
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [193.109.254.147:18261] by server-12.bemta-14.messagelabs.com
	id A9/82-12643-D52E8CF4; Fri, 01 Jun 2012 15:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338565210!7252174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16146 invoked from network); 1 Jun 2012 15:40:12 -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 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206653"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-0n;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:36 +0000
Message-ID: <1338565207-2888-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/38] arm: hook up domctl and memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5ed754f..5d8b7f9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -373,6 +373,8 @@ typedef unsigned long arm_hypercall_t(
     [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
 
 static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(memory_op),
+    HYPERCALL(domctl),
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxZ-0006fh-FS; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eV-Ma
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [193.109.254.147:18269] by server-4.bemta-14.messagelabs.com id
	DA/00-03148-E52E8CF4; Fri, 01 Jun 2012 15:40:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338565208!12347274!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19021 invoked from network); 1 Jun 2012 15:40:10 -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;
	1 Jun 2012 15:40:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547679"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-Nb;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:32 +0000
Message-ID: <1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk of a
	domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/page.h |    1 +
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 4f624d8..fdbecbc 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -5,6 +5,40 @@
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
 
+void dump_p2m_lookup(struct domain *d, paddr_t addr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+
+    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
+
+    first = __map_domain_page(p2m->first_level);
+    printk("1ST[%#03llx] = %#016llx\n",
+           first_table_offset(addr),
+           first[first_table_offset(addr)].bits);
+    if ( !first[first_table_offset(addr)].p2m.valid ||
+         !first[first_table_offset(addr)].p2m.table )
+        goto done;
+
+    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+    printk("2ND[%#03llx] = %#016llx\n",
+           second_table_offset(addr),
+           second[second_table_offset(addr)].bits);
+    if ( !second[second_table_offset(addr)].p2m.valid ||
+         !second[second_table_offset(addr)].p2m.table )
+        goto done;
+
+    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+    printk("3RD[%#03llx] = %#016llx\n",
+           third_table_offset(addr),
+           third[third_table_offset(addr)].bits);
+
+done:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 void p2m_load_VTTBR(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 22c56b5..c7b6530 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -313,6 +313,7 @@ static inline uint64_t gva_to_ipa(uint32_t va)
 #define PAR_FAULT 0x1
 
 extern void dump_pt_walk(uint32_t addr);
+extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
 #endif /* __ASSEMBLY__ */
 
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxZ-0006fh-FS; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eV-Ma
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [193.109.254.147:18269] by server-4.bemta-14.messagelabs.com id
	DA/00-03148-E52E8CF4; Fri, 01 Jun 2012 15:40:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338565208!12347274!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19021 invoked from network); 1 Jun 2012 15:40:10 -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;
	1 Jun 2012 15:40:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547679"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-Nb;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:32 +0000
Message-ID: <1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk of a
	domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/page.h |    1 +
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 4f624d8..fdbecbc 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -5,6 +5,40 @@
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
 
+void dump_p2m_lookup(struct domain *d, paddr_t addr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+
+    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
+
+    first = __map_domain_page(p2m->first_level);
+    printk("1ST[%#03llx] = %#016llx\n",
+           first_table_offset(addr),
+           first[first_table_offset(addr)].bits);
+    if ( !first[first_table_offset(addr)].p2m.valid ||
+         !first[first_table_offset(addr)].p2m.table )
+        goto done;
+
+    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
+    printk("2ND[%#03llx] = %#016llx\n",
+           second_table_offset(addr),
+           second[second_table_offset(addr)].bits);
+    if ( !second[second_table_offset(addr)].p2m.valid ||
+         !second[second_table_offset(addr)].p2m.table )
+        goto done;
+
+    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
+    printk("3RD[%#03llx] = %#016llx\n",
+           third_table_offset(addr),
+           third[third_table_offset(addr)].bits);
+
+done:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 void p2m_load_VTTBR(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 22c56b5..c7b6530 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -313,6 +313,7 @@ static inline uint64_t gva_to_ipa(uint32_t va)
 #define PAR_FAULT 0x1
 
 extern void dump_pt_walk(uint32_t addr);
+extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
 #endif /* __ASSEMBLY__ */
 
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxV-0006e4-47; Fri, 01 Jun 2012 15:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaTxT-0006dq-Jg
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:11 +0000
Received: from [85.158.139.83:48892] by server-9.bemta-5.messagelabs.com id
	C5/D2-27779-A52E8CF4; Fri, 01 Jun 2012 15:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1441 invoked from network); 1 Jun 2012 15:40:09 -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;
	1 Jun 2012 15:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206650"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-Kc;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:30 +0000
Message-ID: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/38] arm: allocate top level p2m page for all
	non-idle 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

Not just dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c |    3 +++
 xen/arch/arm/p2m.c    |    2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5702399..4b38790 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -201,6 +201,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         clear_page(d->shared_info);
         share_xen_page_with_guest(
                 virt_to_page(d->shared_info), d, XENSHARE_writable);
+
+        if ( (rc = p2m_alloc_table(d)) != 0 )
+            goto fail;
     }
 
     d->max_vcpus = 8;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 051a0e8..4f624d8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -203,7 +203,7 @@ int p2m_alloc_table(struct domain *d)
     void *p;
 
     /* First level P2M is 2 consecutive pages */
-    page = alloc_domheap_pages(d, 1, 0);
+    page = alloc_domheap_pages(NULL, 1, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxV-0006e4-47; Fri, 01 Jun 2012 15:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaTxT-0006dq-Jg
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:11 +0000
Received: from [85.158.139.83:48892] by server-9.bemta-5.messagelabs.com id
	C5/D2-27779-A52E8CF4; Fri, 01 Jun 2012 15:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1441 invoked from network); 1 Jun 2012 15:40:09 -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;
	1 Jun 2012 15:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206650"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-Kc;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:30 +0000
Message-ID: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/38] arm: allocate top level p2m page for all
	non-idle 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

Not just dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c |    3 +++
 xen/arch/arm/p2m.c    |    2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5702399..4b38790 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -201,6 +201,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         clear_page(d->shared_info);
         share_xen_page_with_guest(
                 virt_to_page(d->shared_info), d, XENSHARE_writable);
+
+        if ( (rc = p2m_alloc_table(d)) != 0 )
+            goto fail;
     }
 
     d->max_vcpus = 8;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 051a0e8..4f624d8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -203,7 +203,7 @@ int p2m_alloc_table(struct domain *d)
     void *p;
 
     /* First level P2M is 2 consecutive pages */
-    page = alloc_domheap_pages(d, 1, 0);
+    page = alloc_domheap_pages(NULL, 1, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxV-0006eC-Gw; Fri, 01 Jun 2012 15:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaTxU-0006dq-5x
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:12 +0000
Received: from [85.158.139.83:45040] by server-9.bemta-5.messagelabs.com id
	EC/D2-27779-B52E8CF4; Fri, 01 Jun 2012 15:40:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1508 invoked from network); 1 Jun 2012 15:40:10 -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;
	1 Jun 2012 15:40:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206651"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-MA;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:31 +0000
Message-ID: <1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk of
	the hypervisor page 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

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c          |   53 ++++++++++++++++++++++++++++++++++++++++++-
 xen/include/asm-arm/page.h |    2 +
 2 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 10ff883..c332e4c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -42,6 +42,8 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t boot_httbr;
 
+static paddr_t xen_phys_offset;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -53,6 +55,53 @@ unsigned long max_page;
 
 extern char __init_begin[], __init_end[];
 
+void dump_pt_walk(uint32_t addr)
+{
+    paddr_t second_ma, third_ma;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    uint64_t httbr = READ_CP64(HTTBR);
+
+    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
+           addr, httbr);
+
+    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
+    first = xen_pgtable;
+    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
+           first_table_offset(addr),
+           first, first_table_offset(addr),
+           virt_to_maddr(&first[first_table_offset(addr)]),
+           first[first_table_offset(addr)].bits);
+
+    if ( !first[first_table_offset(addr)].pt.valid ||
+         !first[first_table_offset(addr)].pt.table )
+        goto done;
+
+    second_ma = (paddr_t)first[first_table_offset(addr)].pt.base << PAGE_SHIFT;
+    second = (lpae_t *)(unsigned long)(second_ma - xen_phys_offset);
+    printk("2ND[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
+           second_table_offset(addr),
+           second, second_table_offset(addr),
+           virt_to_maddr(&second[second_table_offset(addr)]),
+           second[second_table_offset(addr)].bits);
+    if ( !second[second_table_offset(addr)].pt.valid ||
+         !second[second_table_offset(addr)].pt.table )
+        goto done;
+
+    third_ma = (paddr_t)second[second_table_offset(addr)].pt.base << PAGE_SHIFT;
+    third = (lpae_t *)(unsigned long)(third_ma - xen_phys_offset);
+    printk("3RD[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
+           third_table_offset(addr),
+           third, third_table_offset(addr),
+           virt_to_maddr(&third[third_table_offset(addr)]),
+           third[third_table_offset(addr)].bits);
+    if ( !third[third_table_offset(addr)].pt.valid ||
+         !third[third_table_offset(addr)].pt.table )
+        goto done;
+
+done:
+    return;
+}
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
@@ -173,8 +222,8 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
     flush_xen_data_tlb_va(dest_va);
 
     /* Calculate virt-to-phys offset for the new location */
-    phys_offset = xen_paddr - (unsigned long) _start;
-
+    xen_phys_offset = phys_offset = xen_paddr - (unsigned long) _start;
+    
     /* Copy */
     memcpy((void *) dest_va, _start, _end - _start);
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b6df64e..22c56b5 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -312,6 +312,8 @@ static inline uint64_t gva_to_ipa(uint32_t va)
 /* Bits in the PAR returned by va_to_par */
 #define PAR_FAULT 0x1
 
+extern void dump_pt_walk(uint32_t addr);
+
 #endif /* __ASSEMBLY__ */
 
 /* These numbers add up to a 39-bit input address space.  The  ARMv7-A
-- 
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 Jun 01 15:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40: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 1SaTxV-0006eC-Gw; Fri, 01 Jun 2012 15:40:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaTxU-0006dq-5x
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:12 +0000
Received: from [85.158.139.83:45040] by server-9.bemta-5.messagelabs.com id
	EC/D2-27779-B52E8CF4; Fri, 01 Jun 2012 15:40:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1508 invoked from network); 1 Jun 2012 15:40:10 -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;
	1 Jun 2012 15:40:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206651"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-MA;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:31 +0000
Message-ID: <1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk of
	the hypervisor page 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

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c          |   53 ++++++++++++++++++++++++++++++++++++++++++-
 xen/include/asm-arm/page.h |    2 +
 2 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 10ff883..c332e4c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -42,6 +42,8 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t boot_httbr;
 
+static paddr_t xen_phys_offset;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -53,6 +55,53 @@ unsigned long max_page;
 
 extern char __init_begin[], __init_end[];
 
+void dump_pt_walk(uint32_t addr)
+{
+    paddr_t second_ma, third_ma;
+    lpae_t *first = NULL, *second = NULL, *third = NULL;
+    uint64_t httbr = READ_CP64(HTTBR);
+
+    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
+           addr, httbr);
+
+    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
+    first = xen_pgtable;
+    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
+           first_table_offset(addr),
+           first, first_table_offset(addr),
+           virt_to_maddr(&first[first_table_offset(addr)]),
+           first[first_table_offset(addr)].bits);
+
+    if ( !first[first_table_offset(addr)].pt.valid ||
+         !first[first_table_offset(addr)].pt.table )
+        goto done;
+
+    second_ma = (paddr_t)first[first_table_offset(addr)].pt.base << PAGE_SHIFT;
+    second = (lpae_t *)(unsigned long)(second_ma - xen_phys_offset);
+    printk("2ND[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
+           second_table_offset(addr),
+           second, second_table_offset(addr),
+           virt_to_maddr(&second[second_table_offset(addr)]),
+           second[second_table_offset(addr)].bits);
+    if ( !second[second_table_offset(addr)].pt.valid ||
+         !second[second_table_offset(addr)].pt.table )
+        goto done;
+
+    third_ma = (paddr_t)second[second_table_offset(addr)].pt.base << PAGE_SHIFT;
+    third = (lpae_t *)(unsigned long)(third_ma - xen_phys_offset);
+    printk("3RD[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
+           third_table_offset(addr),
+           third, third_table_offset(addr),
+           virt_to_maddr(&third[third_table_offset(addr)]),
+           third[third_table_offset(addr)].bits);
+    if ( !third[third_table_offset(addr)].pt.valid ||
+         !third[third_table_offset(addr)].pt.table )
+        goto done;
+
+done:
+    return;
+}
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
@@ -173,8 +222,8 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
     flush_xen_data_tlb_va(dest_va);
 
     /* Calculate virt-to-phys offset for the new location */
-    phys_offset = xen_paddr - (unsigned long) _start;
-
+    xen_phys_offset = phys_offset = xen_paddr - (unsigned long) _start;
+    
     /* Copy */
     memcpy((void *) dest_va, _start, _end - _start);
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b6df64e..22c56b5 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -312,6 +312,8 @@ static inline uint64_t gva_to_ipa(uint32_t va)
 /* Bits in the PAR returned by va_to_par */
 #define PAR_FAULT 0x1
 
+extern void dump_pt_walk(uint32_t addr);
+
 #endif /* __ASSEMBLY__ */
 
 /* These numbers add up to a 39-bit input address space.  The  ARMv7-A
-- 
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 Jun 01 15:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaTxY-0006fJ-M9; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eR-F4
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [85.158.139.83:45173] by server-5.bemta-5.messagelabs.com id
	CD/54-16141-D52E8CF4; Fri, 01 Jun 2012 15:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1862 invoked from network); 1 Jun 2012 15:40:12 -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;
	1 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206654"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-UR;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:35 +0000
Message-ID: <1338565207-2888-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/38] arm: enable interrupts while handling
	traps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 most traps we can do this as soon as we have saved the necessary state.
For IRQs and FIQs we must wait until we have acked the interrupt with the GIC.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/entry.S |   17 ++++++++++++++---
 xen/arch/arm/gic.c   |    2 ++
 xen/arch/arm/traps.c |    1 -
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 7a22e2d..5bc3906 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -46,6 +46,17 @@ save_guest_regs:
 	ALIGN;												\
 trap_##trap:												\
 	SAVE_ALL;											\
+	cpsie i; 	/* local_irq_enable */								\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+#define DEFINE_TRAP_ENTRY_NOIRQ(trap)									\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
 	adr lr, return_from_trap;									\
 	mov r0, sp;											\
 	mov r11, sp;											\
@@ -69,8 +80,8 @@ DEFINE_TRAP_ENTRY(supervisor_call)
 DEFINE_TRAP_ENTRY(prefetch_abort)
 DEFINE_TRAP_ENTRY(data_abort)
 DEFINE_TRAP_ENTRY(hypervisor)
-DEFINE_TRAP_ENTRY(irq)
-DEFINE_TRAP_ENTRY(fiq)
+DEFINE_TRAP_ENTRY_NOIRQ(irq)
+DEFINE_TRAP_ENTRY_NOIRQ(fiq)
 
 return_from_trap:
 	mov sp, r11
@@ -83,7 +94,7 @@ ENTRY(return_to_new_vcpu)
 ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
-	bl leave_hypervisor_tail
+	bl leave_hypervisor_tail /* Disables interrupts on return */
 	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index cc9d37b..1a2b95f 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -509,6 +509,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     uint32_t intack = GICC[GICC_IAR];
     unsigned int irq = intack & GICC_IA_IRQ;
 
+    local_irq_enable();
+
     if ( irq == 1023 )
         /* Spurious interrupt */
         return;
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index abc26a3..5ed754f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -412,7 +412,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     arm_hypercall_t *call = NULL;
-    local_irq_enable();
 
     if ( iss != XEN_HYPERCALL_TAG )
     {
-- 
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 Jun 01 15:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaTxY-0006fJ-M9; Fri, 01 Jun 2012 15:40: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 1SaTxW-0006eR-F4
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:14 +0000
Received: from [85.158.139.83:45173] by server-5.bemta-5.messagelabs.com id
	CD/54-16141-D52E8CF4; Fri, 01 Jun 2012 15:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1862 invoked from network); 1 Jun 2012 15:40:12 -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;
	1 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206654"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-UR;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:35 +0000
Message-ID: <1338565207-2888-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/38] arm: enable interrupts while handling
	traps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 most traps we can do this as soon as we have saved the necessary state.
For IRQs and FIQs we must wait until we have acked the interrupt with the GIC.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/entry.S |   17 ++++++++++++++---
 xen/arch/arm/gic.c   |    2 ++
 xen/arch/arm/traps.c |    1 -
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 7a22e2d..5bc3906 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -46,6 +46,17 @@ save_guest_regs:
 	ALIGN;												\
 trap_##trap:												\
 	SAVE_ALL;											\
+	cpsie i; 	/* local_irq_enable */								\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+#define DEFINE_TRAP_ENTRY_NOIRQ(trap)									\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
 	adr lr, return_from_trap;									\
 	mov r0, sp;											\
 	mov r11, sp;											\
@@ -69,8 +80,8 @@ DEFINE_TRAP_ENTRY(supervisor_call)
 DEFINE_TRAP_ENTRY(prefetch_abort)
 DEFINE_TRAP_ENTRY(data_abort)
 DEFINE_TRAP_ENTRY(hypervisor)
-DEFINE_TRAP_ENTRY(irq)
-DEFINE_TRAP_ENTRY(fiq)
+DEFINE_TRAP_ENTRY_NOIRQ(irq)
+DEFINE_TRAP_ENTRY_NOIRQ(fiq)
 
 return_from_trap:
 	mov sp, r11
@@ -83,7 +94,7 @@ ENTRY(return_to_new_vcpu)
 ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
-	bl leave_hypervisor_tail
+	bl leave_hypervisor_tail /* Disables interrupts on return */
 	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index cc9d37b..1a2b95f 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -509,6 +509,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     uint32_t intack = GICC[GICC_IAR];
     unsigned int irq = intack & GICC_IA_IRQ;
 
+    local_irq_enable();
+
     if ( irq == 1023 )
         /* Spurious interrupt */
         return;
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index abc26a3..5ed754f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -412,7 +412,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     arm_hypercall_t *call = NULL;
-    local_irq_enable();
 
     if ( iss != XEN_HYPERCALL_TAG )
     {
-- 
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 Jun 01 15:40:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaTxW-0006em-TI; Fri, 01 Jun 2012 15:40: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 1SaTxV-0006e2-9e
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:13 +0000
Received: from [85.158.139.83:45100] by server-10.bemta-5.messagelabs.com id
	4A/FA-22179-C52E8CF4; Fri, 01 Jun 2012 15:40:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1820 invoked from network); 1 Jun 2012 15:40:11 -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;
	1 Jun 2012 15:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206652"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-T0;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:34 +0000
Message-ID: <1338565207-2888-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/38] arm: restore stack on return from trap.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 align the stack before calling into C code but we weren't undoing this on
return.

Collapse continue_(non)idle_domain into continue_new_vcpu.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |   16 +++-------------
 xen/arch/arm/entry.S  |    5 ++++-
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4b38790..9339a11 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -16,17 +16,6 @@
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
-static void continue_idle_domain(struct vcpu *v)
-{
-    reset_stack_and_jump(idle_loop);
-}
-
-static void continue_nonidle_domain(struct vcpu *v)
-{
-    /* check_wakeup_from_wait(); */
-    reset_stack_and_jump(return_from_trap);
-}
-
 void idle_loop(void)
 {
     for ( ; ; )
@@ -72,9 +61,10 @@ static void continue_new_vcpu(struct vcpu *prev)
     schedule_tail(prev);
 
     if ( is_idle_vcpu(current) )
-        continue_idle_domain(current);
+        reset_stack_and_jump(idle_loop);
     else
-        continue_nonidle_domain(current);
+        /* check_wakeup_from_wait(); */
+        reset_stack_and_jump(return_to_new_vcpu);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index f261a9f..7a22e2d 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -72,7 +72,9 @@ DEFINE_TRAP_ENTRY(hypervisor)
 DEFINE_TRAP_ENTRY(irq)
 DEFINE_TRAP_ENTRY(fiq)
 
-ENTRY(return_from_trap)
+return_from_trap:
+	mov sp, r11
+ENTRY(return_to_new_vcpu)
 	ldr r11, [sp, #UREGS_cpsr]
 	and r11, #PSR_MODE_MASK
 	cmp r11, #PSR_MODE_HYP
@@ -82,6 +84,7 @@ ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
 	bl leave_hypervisor_tail
+	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
 	RESTORE_BANKED(svc)
-- 
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 Jun 01 15:40:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaTxW-0006em-TI; Fri, 01 Jun 2012 15:40: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 1SaTxV-0006e2-9e
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:13 +0000
Received: from [85.158.139.83:45100] by server-10.bemta-5.messagelabs.com id
	4A/FA-22179-C52E8CF4; Fri, 01 Jun 2012 15:40:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338565208!17780788!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1820 invoked from network); 1 Jun 2012 15:40:11 -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;
	1 Jun 2012 15:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197206652"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-T0;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:34 +0000
Message-ID: <1338565207-2888-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/38] arm: restore stack on return from trap.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 align the stack before calling into C code but we weren't undoing this on
return.

Collapse continue_(non)idle_domain into continue_new_vcpu.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |   16 +++-------------
 xen/arch/arm/entry.S  |    5 ++++-
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4b38790..9339a11 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -16,17 +16,6 @@
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
-static void continue_idle_domain(struct vcpu *v)
-{
-    reset_stack_and_jump(idle_loop);
-}
-
-static void continue_nonidle_domain(struct vcpu *v)
-{
-    /* check_wakeup_from_wait(); */
-    reset_stack_and_jump(return_from_trap);
-}
-
 void idle_loop(void)
 {
     for ( ; ; )
@@ -72,9 +61,10 @@ static void continue_new_vcpu(struct vcpu *prev)
     schedule_tail(prev);
 
     if ( is_idle_vcpu(current) )
-        continue_idle_domain(current);
+        reset_stack_and_jump(idle_loop);
     else
-        continue_nonidle_domain(current);
+        /* check_wakeup_from_wait(); */
+        reset_stack_and_jump(return_to_new_vcpu);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index f261a9f..7a22e2d 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -72,7 +72,9 @@ DEFINE_TRAP_ENTRY(hypervisor)
 DEFINE_TRAP_ENTRY(irq)
 DEFINE_TRAP_ENTRY(fiq)
 
-ENTRY(return_from_trap)
+return_from_trap:
+	mov sp, r11
+ENTRY(return_to_new_vcpu)
 	ldr r11, [sp, #UREGS_cpsr]
 	and r11, #PSR_MODE_MASK
 	cmp r11, #PSR_MODE_HYP
@@ -82,6 +84,7 @@ ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
 	bl leave_hypervisor_tail
+	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
 	RESTORE_BANKED(svc)
-- 
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 Jun 01 15:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTxq-0006pw-H8; Fri, 01 Jun 2012 15:40:34 +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 1SaTxo-0006ok-QJ
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:33 +0000
Received: from [193.109.254.147:5396] by server-3.bemta-14.messagelabs.com id
	24/02-15022-072E8CF4; Fri, 01 Jun 2012 15:40:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338565208!12347274!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19095 invoked from network); 1 Jun 2012 15:40:10 -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;
	1 Jun 2012 15:40:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547680"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-QL;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:33 +0000
Message-ID: <1338565207-2888-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/38] arm: correct and expand TLB flush CP15
	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

Correct spelling of TLBIALLHIS and correct definition of TLBIALLNSNHIS.

Add a few more.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/cpregs.h |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ee8a287..7a0b49a 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -172,12 +172,19 @@
 #define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
 #define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
 #define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define ITLBIALL        p15,0,c8,c5,0   /* Invalidate instruction TLB */
+#define ITLBIMVA        p15,0,c8,c5,1   /* Invalidate instruction TLB entry by MVA */
+#define ITLBIASID       p15,0,c8,c5,2   /* Invalidate instruction TLB by ASID match */
 #define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
 #define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
 #define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
-#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIALL         p15,0,c8,c7,0   /* invalidate unified TLB */
+#define TLBIMVA         p15,0,c8,c7,1   /* invalidate unified TLB entry by MVA */
+#define TLBIASID        p15,0,c8,c7,2   /* invalid unified TLB by ASID match */
+#define TLBIMVAA        p15,0,c8,c7,3   /* invalidate unified TLB entries by MVA all ASID */
+#define TLBIALLHIS      p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
 #define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
-#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c3,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
 #define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
 #define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
 #define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
-- 
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 Jun 01 15:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTxq-0006pw-H8; Fri, 01 Jun 2012 15:40:34 +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 1SaTxo-0006ok-QJ
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:33 +0000
Received: from [193.109.254.147:5396] by server-3.bemta-14.messagelabs.com id
	24/02-15022-072E8CF4; Fri, 01 Jun 2012 15:40:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338565208!12347274!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19095 invoked from network); 1 Jun 2012 15:40:10 -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;
	1 Jun 2012 15:40:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547680"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxP-0006I5-QL;
	Fri, 01 Jun 2012 16:40:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:33 +0000
Message-ID: <1338565207-2888-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/38] arm: correct and expand TLB flush CP15
	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

Correct spelling of TLBIALLHIS and correct definition of TLBIALLNSNHIS.

Add a few more.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/cpregs.h |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ee8a287..7a0b49a 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -172,12 +172,19 @@
 #define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
 #define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
 #define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define ITLBIALL        p15,0,c8,c5,0   /* Invalidate instruction TLB */
+#define ITLBIMVA        p15,0,c8,c5,1   /* Invalidate instruction TLB entry by MVA */
+#define ITLBIASID       p15,0,c8,c5,2   /* Invalidate instruction TLB by ASID match */
 #define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
 #define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
 #define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
-#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIALL         p15,0,c8,c7,0   /* invalidate unified TLB */
+#define TLBIMVA         p15,0,c8,c7,1   /* invalidate unified TLB entry by MVA */
+#define TLBIASID        p15,0,c8,c7,2   /* invalid unified TLB by ASID match */
+#define TLBIMVAA        p15,0,c8,c7,3   /* invalidate unified TLB entries by MVA all ASID */
+#define TLBIALLHIS      p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
 #define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
-#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c3,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
 #define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
 #define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
 #define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
-- 
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 Jun 01 15:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTxq-0006qJ-Tn; Fri, 01 Jun 2012 15:40:34 +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 1SaTxp-0006ok-9Z
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:33 +0000
Received: from [193.109.254.147:5428] by server-3.bemta-14.messagelabs.com id
	A4/02-15022-072E8CF4; Fri, 01 Jun 2012 15:40:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338565208!12347274!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19171 invoked from network); 1 Jun 2012 15:40:12 -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;
	1 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547681"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-3V;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:37 +0000
Message-ID: <1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/dummy.S          |    3 --
 xen/include/public/arch-arm.h |    9 -----
 3 files changed, 68 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9339a11..62a2f3a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
     free_xenheap_page(v);
 }
 
+struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+{
+    return xmalloc(struct vcpu_guest_context);
+
+}
+
+void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
+{
+    xfree(vgc);
+}
+
 int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
@@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     if ( !is_idle_domain(d) )
     {
         rc = -ENOMEM;
@@ -212,6 +226,60 @@ void arch_domain_destroy(struct domain *d)
     /* domain_vgic_destroy */
 }
 
+static int is_guest_psr(uint32_t psr)
+{
+    switch (psr & PSR_MODE_MASK)
+    {
+    case PSR_MODE_USR:
+    case PSR_MODE_FIQ:
+    case PSR_MODE_IRQ:
+    case PSR_MODE_SVC:
+    case PSR_MODE_ABT:
+    case PSR_MODE_UND:
+    case PSR_MODE_SYS:
+        return 1;
+    case PSR_MODE_MON:
+    case PSR_MODE_HYP:
+    default:
+        return 0;
+    }
+}
+
+int arch_set_info_guest(
+    struct vcpu *v, vcpu_guest_context_u c)
+{
+    struct cpu_user_regs *regs = &c.nat->user_regs;
+
+    if ( !is_guest_psr(regs->cpsr) )
+        return -EINVAL;
+
+    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
+        return -EINVAL;
+    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
+        return -EINVAL;
+    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
+        return -EINVAL;
+    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
+        return -EINVAL;
+    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
+        return -EINVAL;
+
+    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+
+    /* XXX other state:
+     * - SCTLR
+     * - TTBR0/1
+     * - TTBCR
+     */
+
+    //if ( flags & VGCF_online )
+        clear_bit(_VPF_down, &v->pause_flags);
+    //else
+    //    set_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
+
 void arch_dump_domain_info(struct domain *d)
 {
 }
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 016340c..3b48917 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
 DUMMY(pirq_set_affinity);
 
 /* VCPU */
-DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1b1bcf3..e439727 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
-    union {
-        uint32_t reg[16];
-        struct {
-            uint32_t __pad[12];
-            uint32_t sp; /* r13 */
-            uint32_t lr; /* r14 */
-            uint32_t pc; /* r15 */
-        };
-    };
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 01 15:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaTxq-0006qJ-Tn; Fri, 01 Jun 2012 15:40:34 +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 1SaTxp-0006ok-9Z
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:40:33 +0000
Received: from [193.109.254.147:5428] by server-3.bemta-14.messagelabs.com id
	A4/02-15022-072E8CF4; Fri, 01 Jun 2012 15:40:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338565208!12347274!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19171 invoked from network); 1 Jun 2012 15:40:12 -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;
	1 Jun 2012 15:40:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26547681"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:40:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:40:08 -0400
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 1SaTxQ-0006I5-3V;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:37 +0000
Message-ID: <1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/dummy.S          |    3 --
 xen/include/public/arch-arm.h |    9 -----
 3 files changed, 68 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9339a11..62a2f3a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
     free_xenheap_page(v);
 }
 
+struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+{
+    return xmalloc(struct vcpu_guest_context);
+
+}
+
+void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
+{
+    xfree(vgc);
+}
+
 int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
@@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
+
     if ( !is_idle_domain(d) )
     {
         rc = -ENOMEM;
@@ -212,6 +226,60 @@ void arch_domain_destroy(struct domain *d)
     /* domain_vgic_destroy */
 }
 
+static int is_guest_psr(uint32_t psr)
+{
+    switch (psr & PSR_MODE_MASK)
+    {
+    case PSR_MODE_USR:
+    case PSR_MODE_FIQ:
+    case PSR_MODE_IRQ:
+    case PSR_MODE_SVC:
+    case PSR_MODE_ABT:
+    case PSR_MODE_UND:
+    case PSR_MODE_SYS:
+        return 1;
+    case PSR_MODE_MON:
+    case PSR_MODE_HYP:
+    default:
+        return 0;
+    }
+}
+
+int arch_set_info_guest(
+    struct vcpu *v, vcpu_guest_context_u c)
+{
+    struct cpu_user_regs *regs = &c.nat->user_regs;
+
+    if ( !is_guest_psr(regs->cpsr) )
+        return -EINVAL;
+
+    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
+        return -EINVAL;
+    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
+        return -EINVAL;
+    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
+        return -EINVAL;
+    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
+        return -EINVAL;
+    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
+        return -EINVAL;
+
+    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+
+    /* XXX other state:
+     * - SCTLR
+     * - TTBR0/1
+     * - TTBCR
+     */
+
+    //if ( flags & VGCF_online )
+        clear_bit(_VPF_down, &v->pause_flags);
+    //else
+    //    set_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
+
 void arch_dump_domain_info(struct domain *d)
 {
 }
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 016340c..3b48917 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
 DUMMY(pirq_set_affinity);
 
 /* VCPU */
-DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1b1bcf3..e439727 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
-    union {
-        uint32_t reg[16];
-        struct {
-            uint32_t __pad[12];
-            uint32_t sp; /* r13 */
-            uint32_t lr; /* r14 */
-            uint32_t pc; /* r15 */
-        };
-    };
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 01 15:46:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU31-00086y-KV; Fri, 01 Jun 2012 15:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU2z-000869-D0
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:53 +0000
Received: from [85.158.143.35:58647] by server-1.bemta-4.messagelabs.com id
	80/C9-27869-0B3E8CF4; Fri, 01 Jun 2012 15:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338565548!13156336!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23382 invoked from network); 1 Jun 2012 15:45:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:48 -0400
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 1SaTxR-0006I5-OE;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:05 +0000
Message-ID: <1338565207-2888-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 36/38] libxc: add ARM support to xc_dom (PV
	domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Includes ARM zImage support.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 6 files changed, 315 insertions(+), 9 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ca38cbd..a01d457 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
 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_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 2aef64a..4db8fad 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -93,6 +93,7 @@ struct xc_dom_image {
     void *p2m_guest;
 
     /* physical memory */
+    xen_pfn_t rambase_pfn;
     xen_pfn_t total_pages;
     struct xc_dom_phys *phys_pages;
     int realmodearea_log;
@@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
@@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
 {
     if (xc_dom_feature_translated(dom))
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 /* --- arch bits --------------------------------------------------- */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 122d0e8..9099cad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -18,14 +18,138 @@
  * Copyright (c) 2011, Citrix Systems
  */
 #include <inttypes.h>
+
 #include <xen/xen.h>
+#include <xen/io/protocols.h>
+
 #include "xg_private.h"
 #include "xc_dom.h"
 
+/* ------------------------------------------------------------------------ */
+/*
+ * arm guests are hybrid and start off with paging disabled, therefore no
+ * pagetables and nothing to do here.
+ */
+static int count_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+static int setup_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX
+     *   dom->p2m_guest
+     *   dom->start_info_pfn
+     *   dom->xenstore_pfn
+     *   dom->console_pfn
+     */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int start_info_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
+{
+    vcpu_guest_context_t *ctxt = ptr;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    /* clear everything */
+    memset(ctxt, 0, sizeof(*ctxt));
+
+    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
+
+    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
+    ctxt->user_regs.r3 = 0xdeadbeef;
+    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
+    ctxt->ttbr0 = 0;
+    ctxt->ttbr1 = 0;
+    ctxt->ttbcr = 0; /* Defined Reset Value */
+
+    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static struct xc_dom_arch xc_dom_32 = {
+    .guest_type = "xen-3.0-armv7l",
+    .native_protocol = XEN_IO_PROTO_ABI_ARM,
+    .page_shift = PAGE_SHIFT_ARM,
+    .sizeof_pfn = 8,
+    .alloc_magic_pages = alloc_magic_pages,
+    .count_pgtables = count_pgtables_arm,
+    .setup_pgtables = setup_pgtables_arm,
+    .start_info = start_info_arm,
+    .shared_info = shared_info_arm,
+    .vcpu = vcpu_arm,
+};
+
+static void __init register_arch_hooks(void)
+{
+    xc_dom_register_arch_hooks(&xc_dom_32);
+}
+
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
-    errno = ENOSYS;
-    return -1;
+    int rc;
+    xen_pfn_t pfn, allocsz, i;
+
+    dom->shadow_enabled = 1;
+
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+
+    /* setup initial p2m */
+    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
+
+    /* allocate guest memory */
+    for ( i = rc = allocsz = 0;
+          (i < dom->total_pages) && !rc;
+          i += allocsz )
+    {
+        allocsz = dom->total_pages - i;
+        if ( allocsz > 1024*1024 )
+            allocsz = 1024*1024;
+
+        rc = xc_domain_populate_physmap_exact(
+            dom->xch, dom->guest_domid, allocsz,
+            0, 0, &dom->p2m_host[i]);
+    }
+
+    return 0;
 }
 
 int arch_setup_bootearly(struct xc_dom_image *dom)
@@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
 
 int arch_setup_bootlate(struct xc_dom_image *dom)
 {
-    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    /* XXX
+     *   map shared info
+     *   map grant tables
+     *   setup shared info
+     */
     return 0;
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
new file mode 100644
index 0000000..220176d
--- /dev/null
+++ b/tools/libxc/xc_dom_armzimageloader.c
@@ -0,0 +1,167 @@
+/*
+ * Xen domain builder -- ARM zImage bits
+ *
+ * Parse and load ARM zImage kernel images.
+ *
+ * Copyright (C) 2012, Citrix Systems.
+ *
+ * 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
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#include <arpa/inet.h> /* XXX ntohl is not the right function... */
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t end;
+
+    if ( dom->kernel_blob == NULL )
+    {
+        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                     "%s: no kernel image loaded", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    zimage = (uint32_t *)dom->kernel_blob;
+    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    /*
+     * Check for an appended DTB.
+     */
+    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
+        struct minimal_dtb_header *dtb_hdr;
+        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
+        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
+            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
+            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
+        }
+    }
+
+    dom->kernel_size = end;
+
+    return 0;
+}
+
+static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t start, entry_addr;
+    uint64_t v_start, v_end;
+    uint64_t rambase = 0x80000000; /* XXX */
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    zimage = (uint32_t *)dom->kernel_blob;
+
+    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
+
+    v_start = rambase + 0x8000; /* XXX */
+    v_end = v_start + dom->kernel_size;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+
+    if (start == 0)
+        entry_addr = v_start;
+    else
+        entry_addr = start;
+
+    /* find kernel segment */
+    dom->kernel_seg.vstart = v_start;
+    dom->kernel_seg.vend   = v_end;
+
+    dom->parms.virt_entry = entry_addr;
+
+    dom->guest_type = "xen-3.0-armv7l";
+    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
+              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
+    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
+              __FUNCTION__, dom->guest_type,
+              dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    return 0;
+}
+
+static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
+{
+    void *dst;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
+
+    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
+              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
+              __func__, dom->kernel_size, dom->kernel_blob, dst);
+
+    memcpy(dst, dom->kernel_blob, dom->kernel_size);
+
+    return 0;
+}
+
+static struct xc_dom_loader zimage_loader = {
+    .name = "Linux zImage (ARM)",
+    .probe = xc_dom_probe_zimage_kernel,
+    .parser = xc_dom_parse_zimage_kernel,
+    .loader = xc_dom_load_zimage_kernel,
+};
+
+static void __init register_loader(void)
+{
+    xc_dom_register_loader(&zimage_loader);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fea9de5..b0d48d5 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
                         xen_pfn_t count)
 {
     struct xc_dom_phys *phys;
+    xen_pfn_t offset;
     unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
     char *mode = "unset";
 
-    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
+    offset = pfn-dom->rambase_pfn;
+    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
          count > dom->total_pages ||
-         pfn > dom->total_pages - count )
+         offset > dom->total_pages - count )
     {
-        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
-                  __FUNCTION__, pfn, dom->total_pages);
+        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
+                  __FUNCTION__, pfn, offset, dom->total_pages);
         return NULL;
     }
 
@@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
     dom->parms.virt_hv_start_low = UNSET_ADDR;
     dom->parms.elf_paddr_offset = UNSET_ADDR;
 
+    dom->rambase_pfn = 0;
+
     dom->alloc_malloc += sizeof(*dom);
     return dom;
 
diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
index a29fa26..a271942 100644
--- a/tools/libxc/xg_private.h
+++ b/tools/libxc/xg_private.h
@@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
+#define PAGE_SHIFT_ARM          12
+#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
+#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
+
 #define PAGE_SHIFT_X86          12
 #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
 #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-- 
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 Jun 01 15:46:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU31-00086y-KV; Fri, 01 Jun 2012 15:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU2z-000869-D0
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:53 +0000
Received: from [85.158.143.35:58647] by server-1.bemta-4.messagelabs.com id
	80/C9-27869-0B3E8CF4; Fri, 01 Jun 2012 15:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338565548!13156336!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23382 invoked from network); 1 Jun 2012 15:45:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:48 -0400
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 1SaTxR-0006I5-OE;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:05 +0000
Message-ID: <1338565207-2888-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 36/38] libxc: add ARM support to xc_dom (PV
	domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Includes ARM zImage support.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 6 files changed, 315 insertions(+), 9 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ca38cbd..a01d457 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
 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_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 2aef64a..4db8fad 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -93,6 +93,7 @@ struct xc_dom_image {
     void *p2m_guest;
 
     /* physical memory */
+    xen_pfn_t rambase_pfn;
     xen_pfn_t total_pages;
     struct xc_dom_phys *phys_pages;
     int realmodearea_log;
@@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
@@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
 {
     if (xc_dom_feature_translated(dom))
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 /* --- arch bits --------------------------------------------------- */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 122d0e8..9099cad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -18,14 +18,138 @@
  * Copyright (c) 2011, Citrix Systems
  */
 #include <inttypes.h>
+
 #include <xen/xen.h>
+#include <xen/io/protocols.h>
+
 #include "xg_private.h"
 #include "xc_dom.h"
 
+/* ------------------------------------------------------------------------ */
+/*
+ * arm guests are hybrid and start off with paging disabled, therefore no
+ * pagetables and nothing to do here.
+ */
+static int count_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+static int setup_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX
+     *   dom->p2m_guest
+     *   dom->start_info_pfn
+     *   dom->xenstore_pfn
+     *   dom->console_pfn
+     */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int start_info_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
+{
+    vcpu_guest_context_t *ctxt = ptr;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    /* clear everything */
+    memset(ctxt, 0, sizeof(*ctxt));
+
+    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
+
+    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
+    ctxt->user_regs.r3 = 0xdeadbeef;
+    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
+    ctxt->ttbr0 = 0;
+    ctxt->ttbr1 = 0;
+    ctxt->ttbcr = 0; /* Defined Reset Value */
+
+    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static struct xc_dom_arch xc_dom_32 = {
+    .guest_type = "xen-3.0-armv7l",
+    .native_protocol = XEN_IO_PROTO_ABI_ARM,
+    .page_shift = PAGE_SHIFT_ARM,
+    .sizeof_pfn = 8,
+    .alloc_magic_pages = alloc_magic_pages,
+    .count_pgtables = count_pgtables_arm,
+    .setup_pgtables = setup_pgtables_arm,
+    .start_info = start_info_arm,
+    .shared_info = shared_info_arm,
+    .vcpu = vcpu_arm,
+};
+
+static void __init register_arch_hooks(void)
+{
+    xc_dom_register_arch_hooks(&xc_dom_32);
+}
+
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
-    errno = ENOSYS;
-    return -1;
+    int rc;
+    xen_pfn_t pfn, allocsz, i;
+
+    dom->shadow_enabled = 1;
+
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+
+    /* setup initial p2m */
+    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
+
+    /* allocate guest memory */
+    for ( i = rc = allocsz = 0;
+          (i < dom->total_pages) && !rc;
+          i += allocsz )
+    {
+        allocsz = dom->total_pages - i;
+        if ( allocsz > 1024*1024 )
+            allocsz = 1024*1024;
+
+        rc = xc_domain_populate_physmap_exact(
+            dom->xch, dom->guest_domid, allocsz,
+            0, 0, &dom->p2m_host[i]);
+    }
+
+    return 0;
 }
 
 int arch_setup_bootearly(struct xc_dom_image *dom)
@@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
 
 int arch_setup_bootlate(struct xc_dom_image *dom)
 {
-    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    /* XXX
+     *   map shared info
+     *   map grant tables
+     *   setup shared info
+     */
     return 0;
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
new file mode 100644
index 0000000..220176d
--- /dev/null
+++ b/tools/libxc/xc_dom_armzimageloader.c
@@ -0,0 +1,167 @@
+/*
+ * Xen domain builder -- ARM zImage bits
+ *
+ * Parse and load ARM zImage kernel images.
+ *
+ * Copyright (C) 2012, Citrix Systems.
+ *
+ * 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
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#include <arpa/inet.h> /* XXX ntohl is not the right function... */
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t end;
+
+    if ( dom->kernel_blob == NULL )
+    {
+        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                     "%s: no kernel image loaded", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    zimage = (uint32_t *)dom->kernel_blob;
+    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    /*
+     * Check for an appended DTB.
+     */
+    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
+        struct minimal_dtb_header *dtb_hdr;
+        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
+        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
+            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
+            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
+        }
+    }
+
+    dom->kernel_size = end;
+
+    return 0;
+}
+
+static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t start, entry_addr;
+    uint64_t v_start, v_end;
+    uint64_t rambase = 0x80000000; /* XXX */
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    zimage = (uint32_t *)dom->kernel_blob;
+
+    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
+
+    v_start = rambase + 0x8000; /* XXX */
+    v_end = v_start + dom->kernel_size;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+
+    if (start == 0)
+        entry_addr = v_start;
+    else
+        entry_addr = start;
+
+    /* find kernel segment */
+    dom->kernel_seg.vstart = v_start;
+    dom->kernel_seg.vend   = v_end;
+
+    dom->parms.virt_entry = entry_addr;
+
+    dom->guest_type = "xen-3.0-armv7l";
+    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
+              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
+    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
+              __FUNCTION__, dom->guest_type,
+              dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    return 0;
+}
+
+static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
+{
+    void *dst;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
+
+    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
+              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
+              __func__, dom->kernel_size, dom->kernel_blob, dst);
+
+    memcpy(dst, dom->kernel_blob, dom->kernel_size);
+
+    return 0;
+}
+
+static struct xc_dom_loader zimage_loader = {
+    .name = "Linux zImage (ARM)",
+    .probe = xc_dom_probe_zimage_kernel,
+    .parser = xc_dom_parse_zimage_kernel,
+    .loader = xc_dom_load_zimage_kernel,
+};
+
+static void __init register_loader(void)
+{
+    xc_dom_register_loader(&zimage_loader);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fea9de5..b0d48d5 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
                         xen_pfn_t count)
 {
     struct xc_dom_phys *phys;
+    xen_pfn_t offset;
     unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
     char *mode = "unset";
 
-    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
+    offset = pfn-dom->rambase_pfn;
+    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
          count > dom->total_pages ||
-         pfn > dom->total_pages - count )
+         offset > dom->total_pages - count )
     {
-        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
-                  __FUNCTION__, pfn, dom->total_pages);
+        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
+                  __FUNCTION__, pfn, offset, dom->total_pages);
         return NULL;
     }
 
@@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
     dom->parms.virt_hv_start_low = UNSET_ADDR;
     dom->parms.elf_paddr_offset = UNSET_ADDR;
 
+    dom->rambase_pfn = 0;
+
     dom->alloc_malloc += sizeof(*dom);
     return dom;
 
diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
index a29fa26..a271942 100644
--- a/tools/libxc/xg_private.h
+++ b/tools/libxc/xg_private.h
@@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
+#define PAGE_SHIFT_ARM          12
+#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
+#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
+
 #define PAGE_SHIFT_X86          12
 #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
 #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU35-0008AB-Ox; Fri, 01 Jun 2012 15:45:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU34-00088P-8V
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:58 +0000
Received: from [85.158.138.51:33366] by server-10.bemta-3.messagelabs.com id
	AC/4B-12071-5B3E8CF4; Fri, 01 Jun 2012 15:45:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25575 invoked from network); 1 Jun 2012 15:45:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548500"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:56 -0400
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 1SaTxR-0006I5-Gx;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:02 +0000
Message-ID: <1338565207-2888-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 33/38] arm: the hyp timer seems to work now,
	default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/time.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 437dc71..1587fa2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -27,8 +27,12 @@
 #include <xen/time.h>
 #include <asm/system.h>
 
-/* Unfortunately the hypervisor timer interrupt appears to be buggy */
-#define USE_HYP_TIMER 0
+/*
+ * Unfortunately the hypervisor timer interrupt appears to be buggy in
+ * some versions of the model. Disable this to use the physical timer
+ * instead.
+ */
+#define USE_HYP_TIMER 1
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU32-00087f-Ps; Fri, 01 Jun 2012 15:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU30-000869-Go
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:54 +0000
Received: from [85.158.143.99:51051] by server-1.bemta-4.messagelabs.com id
	05/C9-27869-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338565550!30932364!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 673 invoked from network); 1 Jun 2012 15:45:52 -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;
	1 Jun 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207422"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:49 -0400
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 1SaTxR-0006I5-Bm;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:00 +0000
Message-ID: <1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in interrupt
	context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 particular it is taken by gic_set_guest_irq which is called by
vgic_vcpu_inject_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/gic.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a398f92..ededa99 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -329,19 +329,19 @@ int __init gic_init(void)
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
 void __cpuinit gic_init_secondary_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_init();
     gic_hyp_init();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 /* Shut down the per-CPU GIC interface */
 void gic_disable_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_disable();
     gic_hyp_disable();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 void gic_route_irqs(void)
@@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
 
     events_maintenance(current);
 
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
 
     if ( list_empty(&gic.lr_pending) )
     {
@@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &gic.lr_pending);
 
 out:
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
     return;
 }
 
@@ -559,7 +559,7 @@ static void events_maintenance(struct vcpu *v)
             (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
 
     if (!already_pending && gic.event_mask != 0) {
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
                         sizeof(uint64_t), i)) < sizeof(uint64_t)) {
 
@@ -569,7 +569,7 @@ static void events_maintenance(struct vcpu *v)
 
             i++;
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
     }
 }
 
@@ -585,7 +585,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                               sizeof(eisr), i)) < sizeof(eisr)) {
         struct pending_irq *p;
 
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
@@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         } else {
             gic_inject_irq_stop();
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
 
         spin_lock(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU35-0008AB-Ox; Fri, 01 Jun 2012 15:45:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU34-00088P-8V
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:58 +0000
Received: from [85.158.138.51:33366] by server-10.bemta-3.messagelabs.com id
	AC/4B-12071-5B3E8CF4; Fri, 01 Jun 2012 15:45:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25575 invoked from network); 1 Jun 2012 15:45:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548500"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:56 -0400
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 1SaTxR-0006I5-Gx;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:02 +0000
Message-ID: <1338565207-2888-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 33/38] arm: the hyp timer seems to work now,
	default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/time.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 437dc71..1587fa2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -27,8 +27,12 @@
 #include <xen/time.h>
 #include <asm/system.h>
 
-/* Unfortunately the hypervisor timer interrupt appears to be buggy */
-#define USE_HYP_TIMER 0
+/*
+ * Unfortunately the hypervisor timer interrupt appears to be buggy in
+ * some versions of the model. Disable this to use the physical timer
+ * instead.
+ */
+#define USE_HYP_TIMER 1
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU32-00087f-Ps; Fri, 01 Jun 2012 15:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU30-000869-Go
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:54 +0000
Received: from [85.158.143.99:51051] by server-1.bemta-4.messagelabs.com id
	05/C9-27869-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338565550!30932364!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 673 invoked from network); 1 Jun 2012 15:45:52 -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;
	1 Jun 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207422"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:49 -0400
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 1SaTxR-0006I5-Bm;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:00 +0000
Message-ID: <1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in interrupt
	context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 particular it is taken by gic_set_guest_irq which is called by
vgic_vcpu_inject_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/gic.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a398f92..ededa99 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -329,19 +329,19 @@ int __init gic_init(void)
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
 void __cpuinit gic_init_secondary_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_init();
     gic_hyp_init();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 /* Shut down the per-CPU GIC interface */
 void gic_disable_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_disable();
     gic_hyp_disable();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 void gic_route_irqs(void)
@@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
 
     events_maintenance(current);
 
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
 
     if ( list_empty(&gic.lr_pending) )
     {
@@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &gic.lr_pending);
 
 out:
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
     return;
 }
 
@@ -559,7 +559,7 @@ static void events_maintenance(struct vcpu *v)
             (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
 
     if (!already_pending && gic.event_mask != 0) {
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
                         sizeof(uint64_t), i)) < sizeof(uint64_t)) {
 
@@ -569,7 +569,7 @@ static void events_maintenance(struct vcpu *v)
 
             i++;
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
     }
 }
 
@@ -585,7 +585,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                               sizeof(eisr), i)) < sizeof(eisr)) {
         struct pending_irq *p;
 
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
@@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         } else {
             gic_inject_irq_stop();
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
 
         spin_lock(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU33-00088N-OD; Fri, 01 Jun 2012 15:45: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 1SaU30-000869-W2
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:55 +0000
Received: from [85.158.143.99:64894] by server-1.bemta-4.messagelabs.com id
	F6/C9-27869-2B3E8CF4; Fri, 01 Jun 2012 15:45:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338565550!23414785!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18514 invoked from network); 1 Jun 2012 15:45:52 -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;
	1 Jun 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548428"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:51 -0400
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 1SaTxQ-0006I5-Eh;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:43 +0000
Message-ID: <1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/38] arm: do not set max_vcpus = 8 in
	arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
smaller guest.

The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
MAX_VIRT_CPUS -- but making that change caused:
    (XEN) Unexpected Trap: Data Abort
    (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
    (XEN) CPU:    0
    (XEN) PC:     00222e48 _spin_lock+0x28/0x6c
    (XEN) CPSR:   600001da MODE:HYP
    (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
    (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
    (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
    (XEN)      SP: 40017d5c LR: 00222e34
    (XEN)
    [...]
    (XEN) Xen call trace:
    (XEN)    [<00222e48>] _spin_lock+0x28/0x6c
    (XEN)    [<0022623c>] init_timer+0xbc/0x160
    (XEN)    [<0021fbdc>] sched_init_vcpu+0x94/0x200
    (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
    (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
    (XEN)    [<00241ab8>] do_trap_hypervisor+0x588/0x8cc
    (XEN)    [<0023bbb0>] return_from_trap+0x0/0x4

so punt on that for now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index bd900f9..e867cb2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -215,8 +215,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
     }
 
-    d->max_vcpus = 8;
-
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU34-00088y-Fp; Fri, 01 Jun 2012 15:45:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU31-00086o-Od
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:55 +0000
Received: from [193.109.254.147:34525] by server-11.bemta-14.messagelabs.com
	id BF/9D-01965-3B3E8CF4; Fri, 01 Jun 2012 15:45:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338565553!5577259!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3435 invoked from network); 1 Jun 2012 15:45:54 -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;
	1 Jun 2012 15:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207437"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:52 -0400
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 1SaTxR-0006I5-EO;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:01 +0000
Message-ID: <1338565207-2888-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 32/38] arm: context switch virtual timer
	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>
---
 xen/arch/arm/domain.c        |   10 ++++++++++
 xen/include/asm-arm/cpregs.h |    3 +++
 xen/include/asm-arm/domain.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e15c1e8..893a169 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -49,6 +49,11 @@ static void ctxt_switch_from(struct vcpu *p)
     p->arch.tpidruro = READ_CP32(TPIDRURO);
     p->arch.tpidrprw = READ_CP32(TPIDRPRW);
 
+    /* Arch timer */
+    p->arch.cntvoff = READ_CP64(CNTVOFF);
+    p->arch.cntv_cval = READ_CP64(CNTV_CVAL);
+    p->arch.cntv_ctl = READ_CP32(CNTV_CTL);
+
     /* 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);
@@ -128,6 +133,11 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_CP32(n->arch.mair1, MAIR1);
     isb();
 
+    /* Arch timer */
+    WRITE_CP64(n->arch.cntvoff, CNTVOFF);
+    WRITE_CP64(n->arch.cntv_cval, CNTV_CVAL);
+    WRITE_CP32(n->arch.cntv_ctl, CNTV_CTL);
+
     /* Control Registers */
     WRITE_CP32(n->arch.actlr, ACTLR);
     WRITE_CP32(n->arch.sctlr, SCTLR);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index bd46942..34a9e93 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -238,10 +238,13 @@
 #define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
 #define CNTVCT          p15,1,c14       /* Time counter value + offset */
 #define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTV_CVAL       p15,3,c14       /* Virt. Timer comparator */
 #define CNTVOFF         p15,4,c14       /* Time counter offset */
 #define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
 #define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
 #define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTV_TVAL       p15,0,c14,c3,0  /* Virt. Timer value */
+#define CNTV_CTL        p15,0,c14,c3,1  /* Virt. TImer control register */
 #define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
 
 /* CP15 CR15: Implementation Defined Registers */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 32deb52..230ea8c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,11 @@ struct arch_vcpu
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
 
+    /* Arch timers */
+    uint64_t cntvoff;
+    uint64_t cntv_cval;
+    uint32_t cntv_ctl;
+
     /* CP 15 */
     uint32_t csselr;
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU33-00088N-OD; Fri, 01 Jun 2012 15:45: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 1SaU30-000869-W2
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:55 +0000
Received: from [85.158.143.99:64894] by server-1.bemta-4.messagelabs.com id
	F6/C9-27869-2B3E8CF4; Fri, 01 Jun 2012 15:45:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338565550!23414785!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18514 invoked from network); 1 Jun 2012 15:45:52 -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;
	1 Jun 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548428"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:51 -0400
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 1SaTxQ-0006I5-Eh;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:43 +0000
Message-ID: <1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/38] arm: do not set max_vcpus = 8 in
	arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
smaller guest.

The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
MAX_VIRT_CPUS -- but making that change caused:
    (XEN) Unexpected Trap: Data Abort
    (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
    (XEN) CPU:    0
    (XEN) PC:     00222e48 _spin_lock+0x28/0x6c
    (XEN) CPSR:   600001da MODE:HYP
    (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
    (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
    (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
    (XEN)      SP: 40017d5c LR: 00222e34
    (XEN)
    [...]
    (XEN) Xen call trace:
    (XEN)    [<00222e48>] _spin_lock+0x28/0x6c
    (XEN)    [<0022623c>] init_timer+0xbc/0x160
    (XEN)    [<0021fbdc>] sched_init_vcpu+0x94/0x200
    (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
    (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
    (XEN)    [<00241ab8>] do_trap_hypervisor+0x588/0x8cc
    (XEN)    [<0023bbb0>] return_from_trap+0x0/0x4

so punt on that for now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index bd900f9..e867cb2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -215,8 +215,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
     }
 
-    d->max_vcpus = 8;
-
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU34-00088y-Fp; Fri, 01 Jun 2012 15:45:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU31-00086o-Od
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:55 +0000
Received: from [193.109.254.147:34525] by server-11.bemta-14.messagelabs.com
	id BF/9D-01965-3B3E8CF4; Fri, 01 Jun 2012 15:45:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338565553!5577259!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3435 invoked from network); 1 Jun 2012 15:45:54 -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;
	1 Jun 2012 15:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207437"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:52 -0400
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 1SaTxR-0006I5-EO;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:01 +0000
Message-ID: <1338565207-2888-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 32/38] arm: context switch virtual timer
	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>
---
 xen/arch/arm/domain.c        |   10 ++++++++++
 xen/include/asm-arm/cpregs.h |    3 +++
 xen/include/asm-arm/domain.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e15c1e8..893a169 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -49,6 +49,11 @@ static void ctxt_switch_from(struct vcpu *p)
     p->arch.tpidruro = READ_CP32(TPIDRURO);
     p->arch.tpidrprw = READ_CP32(TPIDRPRW);
 
+    /* Arch timer */
+    p->arch.cntvoff = READ_CP64(CNTVOFF);
+    p->arch.cntv_cval = READ_CP64(CNTV_CVAL);
+    p->arch.cntv_ctl = READ_CP32(CNTV_CTL);
+
     /* 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);
@@ -128,6 +133,11 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_CP32(n->arch.mair1, MAIR1);
     isb();
 
+    /* Arch timer */
+    WRITE_CP64(n->arch.cntvoff, CNTVOFF);
+    WRITE_CP64(n->arch.cntv_cval, CNTV_CVAL);
+    WRITE_CP32(n->arch.cntv_ctl, CNTV_CTL);
+
     /* Control Registers */
     WRITE_CP32(n->arch.actlr, ACTLR);
     WRITE_CP32(n->arch.sctlr, SCTLR);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index bd46942..34a9e93 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -238,10 +238,13 @@
 #define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
 #define CNTVCT          p15,1,c14       /* Time counter value + offset */
 #define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTV_CVAL       p15,3,c14       /* Virt. Timer comparator */
 #define CNTVOFF         p15,4,c14       /* Time counter offset */
 #define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
 #define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
 #define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTV_TVAL       p15,0,c14,c3,0  /* Virt. Timer value */
+#define CNTV_CTL        p15,0,c14,c3,1  /* Virt. TImer control register */
 #define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
 
 /* CP15 CR15: Implementation Defined Registers */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 32deb52..230ea8c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,11 @@ struct arch_vcpu
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
 
+    /* Arch timers */
+    uint64_t cntvoff;
+    uint64_t cntv_cval;
+    uint32_t cntv_ctl;
+
     /* CP 15 */
     uint32_t csselr;
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU35-00089Z-8Q; Fri, 01 Jun 2012 15:45:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU32-00087S-S6
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:57 +0000
Received: from [85.158.138.51:33247] by server-12.bemta-3.messagelabs.com id
	0E/1D-29860-4B3E8CF4; Fri, 01 Jun 2012 15:45:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25470 invoked from network); 1 Jun 2012 15:45:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548473"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:54 -0400
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 1SaTxQ-0006I5-Qj;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:50 +0000
Message-ID: <1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 21/38] arm: dump guest s1 walk on data abort
	which is not a stage 2 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/traps.c            |   75 +++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/processor.h |    1 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 40bb375..35907ee 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -28,6 +28,7 @@
 #include <xen/errno.h>
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
+#include <xen/domain_page.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -528,6 +529,62 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
+void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+{
+    uint32_t ttbcr = READ_CP32(TTBCR);
+    uint32_t ttbr0 = READ_CP32(TTBR0);
+    paddr_t paddr;
+    uint32_t offset;
+    uint32_t *first = NULL, *second = NULL;
+
+    printk("dom%d VA %#010"PRIx32"\n", d->domain_id, addr);
+    printk("    TTBCR: %#010"PRIx32"\n", ttbcr);
+    printk("    TTBR0: %#010"PRIx32" = %#"PRIpaddr"\n",
+           ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
+
+    if ( ttbcr & TTBCR_EAE )
+    {
+        printk("Cannot handle LPAE guest PT walk\n");
+        return;
+    }
+    if ( (ttbcr & TTBCR_N_MASK) != 0 )
+    {
+        printk("Cannot handle TTBR1 guest walks\n");
+        return;
+    }
+
+    paddr = p2m_lookup(d, ttbr0 & PAGE_MASK);
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed TTBR0 maddr lookup\n");
+        goto done;
+    }
+    first = map_domain_page(paddr>>PAGE_SHIFT);
+
+    offset = addr >> (12+10);
+    printk("1ST[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",
+           offset, paddr, first[offset]);
+    if ( !(first[offset] & 0x1) ||
+         !(first[offset] & 0x2) )
+        goto done;
+
+    paddr = p2m_lookup(d, first[offset] & PAGE_MASK);
+
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed L1 entry maddr lookup\n");
+        goto done;
+    }
+    second = map_domain_page(paddr>>PAGE_SHIFT);
+    offset = (addr >> 12) & 0x3FF;
+    printk("2ND[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",
+           offset, paddr, second[offset]);
+
+done:
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
                                      struct hsr_dabt dabt)
 {
@@ -535,11 +592,12 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     int level = -1;
     mmio_info_t info;
 
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+
     if (dabt.s1ptw)
         goto bad_data_abort;
 
-    info.dabt = dabt;
-    info.gva = READ_CP32(HDFAR);
     info.gpa = gva_to_ipa(info.gva);
 
     if (handle_mmio(&info))
@@ -553,18 +611,23 @@ bad_data_abort:
     msg = decode_fsc( dabt.dfsc, &level);
 
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           "    gva=%"PRIx32"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
-           info.gva, info.gpa);
-    if (dabt.valid)
+           info.gva);
+    if ( !dabt.s1ptw )
+        printk("    gpa=%"PRIpaddr"\n", info.gpa);
+    if ( dabt.valid )
         printk("    size=%d sign=%d write=%d reg=%d\n",
                dabt.size, dabt.sign, dabt.write, dabt.reg);
     else
         printk("    instruction syndrome invalid\n");
     printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
            dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
-
+    if ( !dabt.s1ptw )
+        dump_p2m_lookup(current->domain, info.gpa);
+    else
+        dump_guest_s1_walk(current->domain, info.gva);
     show_execution_state(regs);
     panic("Unhandled guest data abort\n");
 }
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ec6fb48..81924a4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -25,6 +25,7 @@
 #define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
+#define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
 #define TTBCR_N_16KB 0x00
 #define TTBCR_N_8KB  0x01
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU31-00086n-9N; Fri, 01 Jun 2012 15:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU2z-000864-JV
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:53 +0000
Received: from [85.158.143.99:64862] by server-2.bemta-4.messagelabs.com id
	10/19-11595-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338565550!23414785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18486 invoked from network); 1 Jun 2012 15:45:51 -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;
	1 Jun 2012 15:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:49 -0400
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 1SaTxR-0006I5-2K;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:54 +0000
Message-ID: <1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
	paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 160a4e9..ab52171 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
     lpae_t pte, *p;
     int i;
 
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
     xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU35-00089Z-8Q; Fri, 01 Jun 2012 15:45:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU32-00087S-S6
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:57 +0000
Received: from [85.158.138.51:33247] by server-12.bemta-3.messagelabs.com id
	0E/1D-29860-4B3E8CF4; Fri, 01 Jun 2012 15:45:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25470 invoked from network); 1 Jun 2012 15:45:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548473"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:54 -0400
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 1SaTxQ-0006I5-Qj;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:50 +0000
Message-ID: <1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 21/38] arm: dump guest s1 walk on data abort
	which is not a stage 2 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/traps.c            |   75 +++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/processor.h |    1 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 40bb375..35907ee 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -28,6 +28,7 @@
 #include <xen/errno.h>
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
+#include <xen/domain_page.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -528,6 +529,62 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
+void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+{
+    uint32_t ttbcr = READ_CP32(TTBCR);
+    uint32_t ttbr0 = READ_CP32(TTBR0);
+    paddr_t paddr;
+    uint32_t offset;
+    uint32_t *first = NULL, *second = NULL;
+
+    printk("dom%d VA %#010"PRIx32"\n", d->domain_id, addr);
+    printk("    TTBCR: %#010"PRIx32"\n", ttbcr);
+    printk("    TTBR0: %#010"PRIx32" = %#"PRIpaddr"\n",
+           ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
+
+    if ( ttbcr & TTBCR_EAE )
+    {
+        printk("Cannot handle LPAE guest PT walk\n");
+        return;
+    }
+    if ( (ttbcr & TTBCR_N_MASK) != 0 )
+    {
+        printk("Cannot handle TTBR1 guest walks\n");
+        return;
+    }
+
+    paddr = p2m_lookup(d, ttbr0 & PAGE_MASK);
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed TTBR0 maddr lookup\n");
+        goto done;
+    }
+    first = map_domain_page(paddr>>PAGE_SHIFT);
+
+    offset = addr >> (12+10);
+    printk("1ST[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",
+           offset, paddr, first[offset]);
+    if ( !(first[offset] & 0x1) ||
+         !(first[offset] & 0x2) )
+        goto done;
+
+    paddr = p2m_lookup(d, first[offset] & PAGE_MASK);
+
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed L1 entry maddr lookup\n");
+        goto done;
+    }
+    second = map_domain_page(paddr>>PAGE_SHIFT);
+    offset = (addr >> 12) & 0x3FF;
+    printk("2ND[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",
+           offset, paddr, second[offset]);
+
+done:
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
                                      struct hsr_dabt dabt)
 {
@@ -535,11 +592,12 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     int level = -1;
     mmio_info_t info;
 
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+
     if (dabt.s1ptw)
         goto bad_data_abort;
 
-    info.dabt = dabt;
-    info.gva = READ_CP32(HDFAR);
     info.gpa = gva_to_ipa(info.gva);
 
     if (handle_mmio(&info))
@@ -553,18 +611,23 @@ bad_data_abort:
     msg = decode_fsc( dabt.dfsc, &level);
 
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           "    gva=%"PRIx32"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
-           info.gva, info.gpa);
-    if (dabt.valid)
+           info.gva);
+    if ( !dabt.s1ptw )
+        printk("    gpa=%"PRIpaddr"\n", info.gpa);
+    if ( dabt.valid )
         printk("    size=%d sign=%d write=%d reg=%d\n",
                dabt.size, dabt.sign, dabt.write, dabt.reg);
     else
         printk("    instruction syndrome invalid\n");
     printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
            dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
-
+    if ( !dabt.s1ptw )
+        dump_p2m_lookup(current->domain, info.gpa);
+    else
+        dump_guest_s1_walk(current->domain, info.gva);
     show_execution_state(regs);
     panic("Unhandled guest data abort\n");
 }
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ec6fb48..81924a4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -25,6 +25,7 @@
 #define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
+#define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
 #define TTBCR_N_16KB 0x00
 #define TTBCR_N_8KB  0x01
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU34-00088d-3E; Fri, 01 Jun 2012 15:45: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 1SaU31-00086h-Mb
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:55 +0000
Received: from [85.158.138.51:33173] by server-4.bemta-3.messagelabs.com id
	2F/24-32504-2B3E8CF4; Fri, 01 Jun 2012 15:45:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25444 invoked from network); 1 Jun 2012 15:45:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548450"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:53 -0400
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 1SaTxR-0006I5-9A;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:58 +0000
Message-ID: <1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
	paging 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

With enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..71197af 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache diabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -217,6 +218,10 @@ pt_ready:
 	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
+	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
+	orr   r0, r0, #(SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
 #ifdef EARLY_UART_ADDRESS
 	/* Recover the UART address in the new address space. */
 	lsl   r11, #11
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU31-00086n-9N; Fri, 01 Jun 2012 15:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU2z-000864-JV
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:53 +0000
Received: from [85.158.143.99:64862] by server-2.bemta-4.messagelabs.com id
	10/19-11595-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338565550!23414785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18486 invoked from network); 1 Jun 2012 15:45:51 -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;
	1 Jun 2012 15:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:49 -0400
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 1SaTxR-0006I5-2K;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:54 +0000
Message-ID: <1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
	paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 160a4e9..ab52171 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
     lpae_t pte, *p;
     int i;
 
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        write_pte(xen_second + second_linear_offset(dest_va), pte);
+    }
+
     xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU2z-00086L-TE; Fri, 01 Jun 2012 15:45: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 1SaU2y-000864-F8
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:52 +0000
Received: from [85.158.143.35:58587] by server-2.bemta-4.messagelabs.com id
	F5/09-11595-FA3E8CF4; Fri, 01 Jun 2012 15:45:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338565548!13156336!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23310 invoked from network); 1 Jun 2012 15:45:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207417"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:47 -0400
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 1SaTxR-0006I5-7o;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:57 +0000
Message-ID: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
	not just 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

This requires that we allocate all p2m pages from domheap without a particular
dom because max pages is not setup yet so there is no allocation available to
us.

At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.

Also we seem to have been calling p2m_alloc_table twice for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c       |   10 +++++++---
 xen/arch/arm/domain_build.c |    5 -----
 xen/arch/arm/gic.c          |    9 ++++-----
 xen/arch/arm/gic.h          |    2 +-
 xen/arch/arm/p2m.c          |    3 ++-
 5 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a7fb227..e15c1e8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         if ( (rc = p2m_alloc_table(d)) != 0 )
             goto fail;
-    }
 
-    if ( (rc = domain_vgic_init(d)) != 0 )
-        goto fail;
+        if ( (rc = gicv_setup(d)) != 0 )
+            goto fail;
+
+        if ( (rc = domain_vgic_init(d)) != 0 )
+            goto fail;
+    }
 
     rc = 0;
 fail:
+    /*XXX unwind allocations etc */
     return rc;
 }
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72e775c..1b19e54 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
 
     d->max_pages = ~0U;
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
-        return rc;
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
@@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
     printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
     map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
 
-    gicv_setup(d);
-
     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
     gic_route_irq_to_guest(d, 34, "timer0");
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..a398f92 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -541,14 +541,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     do_IRQ(regs, irq, is_fiq);
 }
 
-void gicv_setup(struct domain *d)
+int gicv_setup(struct domain *d)
 {
+    printk("GICV setup for DOM%d\n", d->domain_id);
+
     /* map the gic virtual cpu interface in the gic cpu interface region of
      * the guest */
-    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
-           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
-           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
-    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
                         GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..018d820 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
-extern void gicv_setup(struct domain *d);
+extern int gicv_setup(struct domain *d);
 
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c4daf83..0665445 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
+#include "gic.h"
 
 void dump_p2m_lookup(struct domain *d, paddr_t addr)
 {
@@ -138,7 +139,7 @@ static int p2m_create_entry(struct domain *d,
 
     BUG_ON(entry->p2m.valid);
 
-    page = alloc_domheap_page(d, 0);
+    page = alloc_domheap_page(NULL, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU32-00087T-ES; Fri, 01 Jun 2012 15:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU2z-000869-WD
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:54 +0000
Received: from [85.158.143.35:58684] by server-1.bemta-4.messagelabs.com id
	83/C9-27869-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338565548!13156336!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23433 invoked from network); 1 Jun 2012 15:45:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:51 -0400
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 1SaTxQ-0006I5-O2;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:48 +0000
Message-ID: <1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 19/38] arm: context switch a bunch of 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

I haven't investigated what if any of this could be done lazily.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c         |  122 ++++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/gic.c            |   25 ++++++++-
 xen/arch/arm/gic.h            |    9 ++-
 xen/include/asm-arm/cpregs.h  |   29 +++++++++-
 xen/include/asm-arm/domain.h  |   33 ++++++++++-
 xen/include/public/arch-arm.h |    3 +
 6 files changed, 210 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d830980..a7fb227 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -36,12 +36,124 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
+    /* CP 15 */
+    p->arch.csselr = READ_CP32(CSSELR);
+
+    /* Control Registers */
+    p->arch.actlr = READ_CP32(ACTLR);
+    p->arch.sctlr = READ_CP32(SCTLR);
+    p->arch.cpacr = READ_CP32(CPACR);
+
+    p->arch.contextidr = READ_CP32(CONTEXTIDR);
+    p->arch.tpidrurw = READ_CP32(TPIDRURW);
+    p->arch.tpidruro = READ_CP32(TPIDRURO);
+    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+
+    /* 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);
+
+    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.mair0 = READ_CP32(MAIR0);
+    p->arch.mair1 = READ_CP32(MAIR1);
+
+    /* Fault Status */
+    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);
+
+    /* XXX MPU */
+
+    /* XXX VFP */
+
+    /* XXX VGIC */
+    gic_save_state(p);
+
+    isb();
     context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
 {
+    uint32_t hcr;
+
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    isb();
+
     p2m_load_VTTBR(n->domain);
+    isb();
+
+    /* XXX VGIC */
+    gic_restore_state(n);
+
+    /* XXX VFP */
+
+    /* XXX MPU */
+
+    /* Fault Status */
+    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);
+
+    /* 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_CP32(n->arch.mair0, MAIR0);
+    WRITE_CP32(n->arch.mair1, MAIR1);
+    isb();
+
+    /* Control Registers */
+    WRITE_CP32(n->arch.actlr, ACTLR);
+    WRITE_CP32(n->arch.sctlr, SCTLR);
+    WRITE_CP32(n->arch.cpacr, CPACR);
+
+    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
+    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
+    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
+    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+
+    /* 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);
+
+    isb();
+
+    /* CP 15 */
+    WRITE_CP32(n->arch.csselr, CSSELR);
+
+    isb();
+
+    WRITE_CP32(hcr, HCR);
+    isb();
 }
 
 static void schedule_tail(struct vcpu *prev)
@@ -255,6 +367,7 @@ static int is_guest_psr(uint32_t psr)
 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;
 
     if ( !is_guest_psr(regs->cpsr) )
@@ -273,10 +386,13 @@ int arch_set_info_guest(
 
     v->arch.cpu_info->guest_cpu_user_regs = *regs;
 
+    v->arch.sctlr = ctxt->sctlr;
+    v->arch.ttbr0 = ctxt->ttbr0;
+    v->arch.ttbr1 = ctxt->ttbr1;
+    v->arch.ttbcr = ctxt->ttbcr;
+
     /* XXX other state:
-     * - SCTLR
-     * - TTBR0/1
-     * - TTBCR
+     * -
      */
 
     //if ( flags & VGCF_online )
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1a2b95f..339c327 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -61,6 +61,30 @@ static struct {
 irq_desc_t irq_desc[NR_IRQS];
 unsigned nr_lrs;
 
+void gic_save_state(struct vcpu *v)
+{
+    int i;
+
+    for ( i=0; i<nr_lrs; i++)
+        v->arch.gic_lr[i] = GICH[GICH_LR + i];
+    /* Disable until next VCPU scheduled */
+    GICH[GICH_HCR] = 0;
+    isb();
+}
+
+void gic_restore_state(struct vcpu *v)
+{
+    int i;
+
+    if ( is_idle_vcpu(v) )
+        return;
+
+    for ( i=0; i<nr_lrs; i++)
+        GICH[GICH_LR + i] = v->arch.gic_lr[i];
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    isb();
+}
+
 static unsigned int gic_irq_startup(struct irq_desc *desc)
 {
     uint32_t enabler;
@@ -263,7 +287,6 @@ static void __cpuinit gic_hyp_init(void)
     vtr = GICH[GICH_VTR];
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
 
-    GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ff8d0a2..ac9cf3a 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -70,8 +70,8 @@
 #define GICH_MISR       (0x10/4)
 #define GICH_EISR0      (0x20/4)
 #define GICH_EISR1      (0x24/4)
-#define GICH_ELRSR0     (0x30/4)
-#define GICH_ELRSR1     (0x34/4)
+#define GICH_ELSR0      (0x30/4)
+#define GICH_ELSR1      (0x34/4)
 #define GICH_APR        (0xF0/4)
 #define GICH_LR         (0x100/4)
 
@@ -149,6 +149,11 @@ extern void gic_init_secondary_cpu(void);
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
+
+/* Context switch */
+extern void gic_save_state(struct vcpu *v);
+extern void gic_restore_state(struct vcpu *v);
+
 #endif
 
 /*
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7a0b49a..bd46942 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -88,6 +88,19 @@
  * arguments, which are cp,opc1,crn,crm,opc2.
  */
 
+/* Coprocessor 14 */
+
+/* CP14 CR0: */
+#define TEECR           p14,6,c0,c0,0   /* ThumbEE Configuration Register */
+
+/* CP14 CR1: */
+#define TEEHBR          p14,6,c1,c0,0   /* ThumbEE Handler Base Register */
+#define JOSCR           p14,7,c1,c0,0   /* Jazelle OS Control Register */
+
+/* CP14 CR2: */
+#define JMCR            p14,7,c2,c0,0   /* Jazelle Main Configuration Register */
+
+
 /* Coprocessor 15 */
 
 /* CP15 CR0: CPUID and Cache Type Registers */
@@ -112,6 +125,8 @@
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define ACTLR           p15,0,c1,c0,1   /* Auxiliary Control Register */
+#define CPACR           p15,0,c1,c0,2   /* Coprocessor Access Control Register */
 #define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
 #define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
 #define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
@@ -127,12 +142,15 @@
 #define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
 
 /* CP15 CR3: Domain Access Control Register */
+#define DACR            p15,0,c3,c0,0   /* Domain Access Control Register */
 
 /* CP15 CR4: */
 
 /* CP15 CR5: Fault Status Registers */
 #define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
 #define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define ADFSR           p15,0,c5,c1,0   /* Auxiliary Data Fault Status Register */
+#define AIFSR           p15,0,c5,c1,1   /* Auxiliary Instruction Fault Status Register */
 #define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
 
 /* CP15 CR6: Fault Address Registers */
@@ -144,6 +162,7 @@
 
 /* CP15 CR7: Cache and address translation operations */
 #define PAR             p15,0,c7        /* Physical Address Register */
+
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
@@ -192,20 +211,24 @@
 /* CP15 CR9: */
 
 /* CP15 CR10: */
-#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
-#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 AKA NMRR */
 #define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
 #define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
 
 /* CP15 CR11: DMA Operations for TCM Access */
 
 /* CP15 CR12:  */
+#define VBAR            p15,0,c12,c0,0  /* Vector Base Address Register */
 #define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
 
 /* CP15 CR13:  */
 #define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
 #define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
-#define HTPIDR          p15,4,c13,c0,2  /* Hyp. Software Thread ID Register */
+#define TPIDRURW        p15,0,c13,c0,2  /* Software Thread ID, User, R/W */
+#define TPIDRURO        p15,0,c13,c0,3  /* Software Thread ID, User, R/O */
+#define TPIDRPRW        p15,0,c13,c0,4  /* Software Thread ID, Priveleged */
+#define HTPIDR          p15,4,c13,c0,2  /* HYp Software Thread Id Register */
 
 /* CP15 CR14:  */
 #define CNTPCT          p15,0,c14       /* Time counter value */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index f295a82..620b26e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -81,8 +81,37 @@ struct arch_vcpu
      */
     struct cpu_info *cpu_info;
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    /* Fault Status */
+    uint32_t dfar, ifar;
+    uint32_t dfsr, ifsr;
+    uint32_t adfsr, aifsr;
+
+    /* MMU */
+    uint32_t vbar;
+    uint32_t ttbcr;
+    uint32_t ttbr0, ttbr1;
+
+    uint32_t dacr;
+    uint64_t par;
+    uint32_t mair0, mair1;
+
+    /* Control Registers */
+    uint32_t actlr, sctlr;
+    uint32_t cpacr;
+
+    uint32_t contextidr;
+    uint32_t tpidrurw;
+    uint32_t tpidruro;
+    uint32_t tpidrprw;
+
+    uint32_t teecr, teehbr;
+    uint32_t joscr, jmcr;
+
+    /* CP 15 */
+    uint32_t csselr;
+
+    uint32_t gic_hcr, gic_vmcr, gic_apr;
+    uint32_t gic_lr[64];
 
     struct {
         struct vgic_irq_rank private_irqs;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e439727..e915cbf 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,9 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU2z-00086L-TE; Fri, 01 Jun 2012 15:45: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 1SaU2y-000864-F8
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:52 +0000
Received: from [85.158.143.35:58587] by server-2.bemta-4.messagelabs.com id
	F5/09-11595-FA3E8CF4; Fri, 01 Jun 2012 15:45:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338565548!13156336!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23310 invoked from network); 1 Jun 2012 15:45:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207417"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:47 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:47 -0400
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 1SaTxR-0006I5-7o;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:57 +0000
Message-ID: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
	not just 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

This requires that we allocate all p2m pages from domheap without a particular
dom because max pages is not setup yet so there is no allocation available to
us.

At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.

Also we seem to have been calling p2m_alloc_table twice for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c       |   10 +++++++---
 xen/arch/arm/domain_build.c |    5 -----
 xen/arch/arm/gic.c          |    9 ++++-----
 xen/arch/arm/gic.h          |    2 +-
 xen/arch/arm/p2m.c          |    3 ++-
 5 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a7fb227..e15c1e8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         if ( (rc = p2m_alloc_table(d)) != 0 )
             goto fail;
-    }
 
-    if ( (rc = domain_vgic_init(d)) != 0 )
-        goto fail;
+        if ( (rc = gicv_setup(d)) != 0 )
+            goto fail;
+
+        if ( (rc = domain_vgic_init(d)) != 0 )
+            goto fail;
+    }
 
     rc = 0;
 fail:
+    /*XXX unwind allocations etc */
     return rc;
 }
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72e775c..1b19e54 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
 
     d->max_pages = ~0U;
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
-        return rc;
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
@@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
     printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
     map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
 
-    gicv_setup(d);
-
     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
     gic_route_irq_to_guest(d, 34, "timer0");
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..a398f92 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -541,14 +541,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     do_IRQ(regs, irq, is_fiq);
 }
 
-void gicv_setup(struct domain *d)
+int gicv_setup(struct domain *d)
 {
+    printk("GICV setup for DOM%d\n", d->domain_id);
+
     /* map the gic virtual cpu interface in the gic cpu interface region of
      * the guest */
-    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
-           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
-           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
-    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
                         GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..018d820 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
-extern void gicv_setup(struct domain *d);
+extern int gicv_setup(struct domain *d);
 
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c4daf83..0665445 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
+#include "gic.h"
 
 void dump_p2m_lookup(struct domain *d, paddr_t addr)
 {
@@ -138,7 +139,7 @@ static int p2m_create_entry(struct domain *d,
 
     BUG_ON(entry->p2m.valid);
 
-    page = alloc_domheap_page(d, 0);
+    page = alloc_domheap_page(NULL, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU34-00089H-SA; Fri, 01 Jun 2012 15:45: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 1SaU32-000872-7f
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:56 +0000
Received: from [85.158.138.51:33209] by server-2.bemta-3.messagelabs.com id
	1E/93-17140-3B3E8CF4; Fri, 01 Jun 2012 15:45:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565553!11696954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18903 invoked from network); 1 Jun 2012 15:45:54 -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 Jun 2012 15:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207441"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:53 -0400
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 1SaTxR-0006I5-JW;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:03 +0000
Message-ID: <1338565207-2888-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 34/38] HACK: arm: initial
	XENMAPSPACE_gmfn_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

Should use same interface as hybrid x86.
---
 xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
 xen/arch/x86/mm.c             |    2 ++
 xen/include/public/arch-arm.h |    1 +
 xen/include/public/memory.h   |   12 +++++++-----
 4 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index ab52171..1832e7f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -480,12 +480,32 @@ static int xenmem_add_to_physmap_once(
 
     switch ( xatp->space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( xatp->idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+
+        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            printk("bad p2m lookup\n");
+            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+        mfn = maddr >> PAGE_SHIFT;
+        rcu_unlock_domain(od);
+        break;
+    }
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 876e1ef..d6c90f9 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4572,6 +4572,8 @@ static int xenmem_add_to_physmap_once(
             mfn = idx;
             page = mfn_to_page(mfn);
             break;
+        case XENMAPSPACE_gmfn_foreign:
+            return -ENOSYS;
         }
         default:
             break;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e915cbf..b52bfc7 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
 #define XEN_LEGACY_MAX_VCPUS 1
 
 typedef uint32_t xen_ulong_t;
+#define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU34-00088d-3E; Fri, 01 Jun 2012 15:45: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 1SaU31-00086h-Mb
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:55 +0000
Received: from [85.158.138.51:33173] by server-4.bemta-3.messagelabs.com id
	2F/24-32504-2B3E8CF4; Fri, 01 Jun 2012 15:45:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25444 invoked from network); 1 Jun 2012 15:45:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548450"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:53 -0400
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 1SaTxR-0006I5-9A;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:58 +0000
Message-ID: <1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
	paging 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

With enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..71197af 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache diabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -217,6 +218,10 @@ pt_ready:
 	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
+	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
+	orr   r0, r0, #(SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
+
 #ifdef EARLY_UART_ADDRESS
 	/* Recover the UART address in the new address space. */
 	lsl   r11, #11
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU32-00087T-ES; Fri, 01 Jun 2012 15:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU2z-000869-WD
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:54 +0000
Received: from [85.158.143.35:58684] by server-1.bemta-4.messagelabs.com id
	83/C9-27869-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338565548!13156336!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23433 invoked from network); 1 Jun 2012 15:45:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:51 -0400
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 1SaTxQ-0006I5-O2;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:48 +0000
Message-ID: <1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 19/38] arm: context switch a bunch of 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

I haven't investigated what if any of this could be done lazily.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c         |  122 ++++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/gic.c            |   25 ++++++++-
 xen/arch/arm/gic.h            |    9 ++-
 xen/include/asm-arm/cpregs.h  |   29 +++++++++-
 xen/include/asm-arm/domain.h  |   33 ++++++++++-
 xen/include/public/arch-arm.h |    3 +
 6 files changed, 210 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d830980..a7fb227 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -36,12 +36,124 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
+    /* CP 15 */
+    p->arch.csselr = READ_CP32(CSSELR);
+
+    /* Control Registers */
+    p->arch.actlr = READ_CP32(ACTLR);
+    p->arch.sctlr = READ_CP32(SCTLR);
+    p->arch.cpacr = READ_CP32(CPACR);
+
+    p->arch.contextidr = READ_CP32(CONTEXTIDR);
+    p->arch.tpidrurw = READ_CP32(TPIDRURW);
+    p->arch.tpidruro = READ_CP32(TPIDRURO);
+    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+
+    /* 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);
+
+    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.mair0 = READ_CP32(MAIR0);
+    p->arch.mair1 = READ_CP32(MAIR1);
+
+    /* Fault Status */
+    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);
+
+    /* XXX MPU */
+
+    /* XXX VFP */
+
+    /* XXX VGIC */
+    gic_save_state(p);
+
+    isb();
     context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
 {
+    uint32_t hcr;
+
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    isb();
+
     p2m_load_VTTBR(n->domain);
+    isb();
+
+    /* XXX VGIC */
+    gic_restore_state(n);
+
+    /* XXX VFP */
+
+    /* XXX MPU */
+
+    /* Fault Status */
+    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);
+
+    /* 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_CP32(n->arch.mair0, MAIR0);
+    WRITE_CP32(n->arch.mair1, MAIR1);
+    isb();
+
+    /* Control Registers */
+    WRITE_CP32(n->arch.actlr, ACTLR);
+    WRITE_CP32(n->arch.sctlr, SCTLR);
+    WRITE_CP32(n->arch.cpacr, CPACR);
+
+    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
+    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
+    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
+    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+
+    /* 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);
+
+    isb();
+
+    /* CP 15 */
+    WRITE_CP32(n->arch.csselr, CSSELR);
+
+    isb();
+
+    WRITE_CP32(hcr, HCR);
+    isb();
 }
 
 static void schedule_tail(struct vcpu *prev)
@@ -255,6 +367,7 @@ static int is_guest_psr(uint32_t psr)
 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;
 
     if ( !is_guest_psr(regs->cpsr) )
@@ -273,10 +386,13 @@ int arch_set_info_guest(
 
     v->arch.cpu_info->guest_cpu_user_regs = *regs;
 
+    v->arch.sctlr = ctxt->sctlr;
+    v->arch.ttbr0 = ctxt->ttbr0;
+    v->arch.ttbr1 = ctxt->ttbr1;
+    v->arch.ttbcr = ctxt->ttbcr;
+
     /* XXX other state:
-     * - SCTLR
-     * - TTBR0/1
-     * - TTBCR
+     * -
      */
 
     //if ( flags & VGCF_online )
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1a2b95f..339c327 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -61,6 +61,30 @@ static struct {
 irq_desc_t irq_desc[NR_IRQS];
 unsigned nr_lrs;
 
+void gic_save_state(struct vcpu *v)
+{
+    int i;
+
+    for ( i=0; i<nr_lrs; i++)
+        v->arch.gic_lr[i] = GICH[GICH_LR + i];
+    /* Disable until next VCPU scheduled */
+    GICH[GICH_HCR] = 0;
+    isb();
+}
+
+void gic_restore_state(struct vcpu *v)
+{
+    int i;
+
+    if ( is_idle_vcpu(v) )
+        return;
+
+    for ( i=0; i<nr_lrs; i++)
+        GICH[GICH_LR + i] = v->arch.gic_lr[i];
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    isb();
+}
+
 static unsigned int gic_irq_startup(struct irq_desc *desc)
 {
     uint32_t enabler;
@@ -263,7 +287,6 @@ static void __cpuinit gic_hyp_init(void)
     vtr = GICH[GICH_VTR];
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
 
-    GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ff8d0a2..ac9cf3a 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -70,8 +70,8 @@
 #define GICH_MISR       (0x10/4)
 #define GICH_EISR0      (0x20/4)
 #define GICH_EISR1      (0x24/4)
-#define GICH_ELRSR0     (0x30/4)
-#define GICH_ELRSR1     (0x34/4)
+#define GICH_ELSR0      (0x30/4)
+#define GICH_ELSR1      (0x34/4)
 #define GICH_APR        (0xF0/4)
 #define GICH_LR         (0x100/4)
 
@@ -149,6 +149,11 @@ extern void gic_init_secondary_cpu(void);
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
+
+/* Context switch */
+extern void gic_save_state(struct vcpu *v);
+extern void gic_restore_state(struct vcpu *v);
+
 #endif
 
 /*
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7a0b49a..bd46942 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -88,6 +88,19 @@
  * arguments, which are cp,opc1,crn,crm,opc2.
  */
 
+/* Coprocessor 14 */
+
+/* CP14 CR0: */
+#define TEECR           p14,6,c0,c0,0   /* ThumbEE Configuration Register */
+
+/* CP14 CR1: */
+#define TEEHBR          p14,6,c1,c0,0   /* ThumbEE Handler Base Register */
+#define JOSCR           p14,7,c1,c0,0   /* Jazelle OS Control Register */
+
+/* CP14 CR2: */
+#define JMCR            p14,7,c2,c0,0   /* Jazelle Main Configuration Register */
+
+
 /* Coprocessor 15 */
 
 /* CP15 CR0: CPUID and Cache Type Registers */
@@ -112,6 +125,8 @@
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define ACTLR           p15,0,c1,c0,1   /* Auxiliary Control Register */
+#define CPACR           p15,0,c1,c0,2   /* Coprocessor Access Control Register */
 #define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
 #define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
 #define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
@@ -127,12 +142,15 @@
 #define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
 
 /* CP15 CR3: Domain Access Control Register */
+#define DACR            p15,0,c3,c0,0   /* Domain Access Control Register */
 
 /* CP15 CR4: */
 
 /* CP15 CR5: Fault Status Registers */
 #define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
 #define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define ADFSR           p15,0,c5,c1,0   /* Auxiliary Data Fault Status Register */
+#define AIFSR           p15,0,c5,c1,1   /* Auxiliary Instruction Fault Status Register */
 #define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
 
 /* CP15 CR6: Fault Address Registers */
@@ -144,6 +162,7 @@
 
 /* CP15 CR7: Cache and address translation operations */
 #define PAR             p15,0,c7        /* Physical Address Register */
+
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
@@ -192,20 +211,24 @@
 /* CP15 CR9: */
 
 /* CP15 CR10: */
-#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
-#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 AKA NMRR */
 #define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
 #define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
 
 /* CP15 CR11: DMA Operations for TCM Access */
 
 /* CP15 CR12:  */
+#define VBAR            p15,0,c12,c0,0  /* Vector Base Address Register */
 #define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
 
 /* CP15 CR13:  */
 #define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
 #define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
-#define HTPIDR          p15,4,c13,c0,2  /* Hyp. Software Thread ID Register */
+#define TPIDRURW        p15,0,c13,c0,2  /* Software Thread ID, User, R/W */
+#define TPIDRURO        p15,0,c13,c0,3  /* Software Thread ID, User, R/O */
+#define TPIDRPRW        p15,0,c13,c0,4  /* Software Thread ID, Priveleged */
+#define HTPIDR          p15,4,c13,c0,2  /* HYp Software Thread Id Register */
 
 /* CP15 CR14:  */
 #define CNTPCT          p15,0,c14       /* Time counter value */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index f295a82..620b26e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -81,8 +81,37 @@ struct arch_vcpu
      */
     struct cpu_info *cpu_info;
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    /* Fault Status */
+    uint32_t dfar, ifar;
+    uint32_t dfsr, ifsr;
+    uint32_t adfsr, aifsr;
+
+    /* MMU */
+    uint32_t vbar;
+    uint32_t ttbcr;
+    uint32_t ttbr0, ttbr1;
+
+    uint32_t dacr;
+    uint64_t par;
+    uint32_t mair0, mair1;
+
+    /* Control Registers */
+    uint32_t actlr, sctlr;
+    uint32_t cpacr;
+
+    uint32_t contextidr;
+    uint32_t tpidrurw;
+    uint32_t tpidruro;
+    uint32_t tpidrprw;
+
+    uint32_t teecr, teehbr;
+    uint32_t joscr, jmcr;
+
+    /* CP 15 */
+    uint32_t csselr;
+
+    uint32_t gic_hcr, gic_vmcr, gic_apr;
+    uint32_t gic_lr[64];
 
     struct {
         struct vgic_irq_rank private_irqs;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e439727..e915cbf 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,9 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU36-0008Ad-5X; Fri, 01 Jun 2012 15:46: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 1SaU34-00088P-MW
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:58 +0000
Received: from [85.158.138.51:34758] by server-10.bemta-3.messagelabs.com id
	F3/5B-12071-6B3E8CF4; Fri, 01 Jun 2012 15:45:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25618 invoked from network); 1 Jun 2012 15:45:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548509"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:56 -0400
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 1SaTxQ-0006I5-AY;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:41 +0000
Message-ID: <1338565207-2888-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/38] arm: remove hard tabs from
	init_idle_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

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 0df3c1a..81ababb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,9 +47,9 @@ static __attribute_used__ void init_done(void)
 
 static void __init init_idle_domain(void)
 {
-        scheduler_init();
-        set_current(idle_vcpu[0]);
-        /* TODO: setup_idle_pagetable(); */
+    scheduler_init();
+    set_current(idle_vcpu[0]);
+    /* TODO: setup_idle_pagetable(); */
 }
 
 static void __init processor_id(void)
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU34-00089H-SA; Fri, 01 Jun 2012 15:45: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 1SaU32-000872-7f
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:56 +0000
Received: from [85.158.138.51:33209] by server-2.bemta-3.messagelabs.com id
	1E/93-17140-3B3E8CF4; Fri, 01 Jun 2012 15:45:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565553!11696954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18903 invoked from network); 1 Jun 2012 15:45:54 -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 Jun 2012 15:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207441"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:53 -0400
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 1SaTxR-0006I5-JW;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:03 +0000
Message-ID: <1338565207-2888-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 34/38] HACK: arm: initial
	XENMAPSPACE_gmfn_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

Should use same interface as hybrid x86.
---
 xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
 xen/arch/x86/mm.c             |    2 ++
 xen/include/public/arch-arm.h |    1 +
 xen/include/public/memory.h   |   12 +++++++-----
 4 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index ab52171..1832e7f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -480,12 +480,32 @@ static int xenmem_add_to_physmap_once(
 
     switch ( xatp->space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( xatp->idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+
+        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            printk("bad p2m lookup\n");
+            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+        mfn = maddr >> PAGE_SHIFT;
+        rcu_unlock_domain(od);
+        break;
+    }
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 876e1ef..d6c90f9 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4572,6 +4572,8 @@ static int xenmem_add_to_physmap_once(
             mfn = idx;
             page = mfn_to_page(mfn);
             break;
+        case XENMAPSPACE_gmfn_foreign:
+            return -ENOSYS;
         }
         default:
             break;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e915cbf..b52bfc7 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
 #define XEN_LEGACY_MAX_VCPUS 1
 
 typedef uint32_t xen_ulong_t;
+#define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU36-0008Ad-5X; Fri, 01 Jun 2012 15:46: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 1SaU34-00088P-MW
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:58 +0000
Received: from [85.158.138.51:34758] by server-10.bemta-3.messagelabs.com id
	F3/5B-12071-6B3E8CF4; Fri, 01 Jun 2012 15:45:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25618 invoked from network); 1 Jun 2012 15:45:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548509"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:56 -0400
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 1SaTxQ-0006I5-AY;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:41 +0000
Message-ID: <1338565207-2888-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/38] arm: remove hard tabs from
	init_idle_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

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 0df3c1a..81ababb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,9 +47,9 @@ static __attribute_used__ void init_done(void)
 
 static void __init init_idle_domain(void)
 {
-        scheduler_init();
-        set_current(idle_vcpu[0]);
-        /* TODO: setup_idle_pagetable(); */
+    scheduler_init();
+    set_current(idle_vcpu[0]);
+    /* TODO: setup_idle_pagetable(); */
 }
 
 static void __init processor_id(void)
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU31-00087C-WA; Fri, 01 Jun 2012 15:45: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 1SaU2z-00086C-V5
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:54 +0000
Received: from [85.158.139.83:42171] by server-10.bemta-5.messagelabs.com id
	E7/2A-22179-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338565550!31523018!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30124 invoked from network); 1 Jun 2012 15:45:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:50 -0400
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 1SaTxQ-0006I5-Vx;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:53 +0000
Message-ID: <1338565207-2888-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 24/38] arm: map fixmaps non-executable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/mm.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c332e4c..160a4e9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -108,6 +108,7 @@ void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
     lpae_t pte = mfn_to_xen_entry(mfn);
     pte.pt.table = 1; /* 4k mappings always have this bit set */
     pte.pt.ai = attributes;
+    pte.pt.xn = 1;
     write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
     flush_xen_data_tlb_va(FIXMAP_ADDR(map));
 }
-- 
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 Jun 01 15:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU31-00087C-WA; Fri, 01 Jun 2012 15:45: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 1SaU2z-00086C-V5
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:54 +0000
Received: from [85.158.139.83:42171] by server-10.bemta-5.messagelabs.com id
	E7/2A-22179-1B3E8CF4; Fri, 01 Jun 2012 15:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338565550!31523018!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30124 invoked from network); 1 Jun 2012 15:45:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:50 -0400
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 1SaTxQ-0006I5-Vx;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:53 +0000
Message-ID: <1338565207-2888-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 24/38] arm: map fixmaps non-executable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/mm.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c332e4c..160a4e9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -108,6 +108,7 @@ void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
     lpae_t pte = mfn_to_xen_entry(mfn);
     pte.pt.table = 1; /* 4k mappings always have this bit set */
     pte.pt.ai = attributes;
+    pte.pt.xn = 1;
     write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
     flush_xen_data_tlb_va(FIXMAP_ADDR(map));
 }
-- 
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 Jun 01 15:46:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU36-0008B1-HS; Fri, 01 Jun 2012 15:46: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 1SaU35-00086h-JW
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:59 +0000
Received: from [85.158.138.51:34833] by server-4.bemta-3.messagelabs.com id
	38/54-32504-7B3E8CF4; Fri, 01 Jun 2012 15:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25671 invoked from network); 1 Jun 2012 15:45:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548513"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:58 -0400
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 1SaTxR-0006I5-55;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:55 +0000
Message-ID: <1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 26/38] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For some reason we were holding the lock over only the unmaps at the end of
the function, rather than for the whole walk.

We might want to be more clever in the future, but for now lets just lock for
the whole walk+create process.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 46c6f17..c4daf83 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -168,6 +168,8 @@ static int create_p2m_entries(struct domain *d,
     paddr_t addr;
     unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
 
+    spin_lock(&p2m->lock);
+
     /* XXX Don't actually handle 40 bit guest physical addresses */
     BUG_ON(start_gpaddr & 0x8000000000ULL);
     BUG_ON(end_gpaddr   & 0x8000000000ULL);
@@ -249,8 +251,6 @@ static int create_p2m_entries(struct domain *d,
     rc = 0;
 
 out:
-    spin_lock(&p2m->lock);
-
     if (third) unmap_domain_page(third);
     if (second) unmap_domain_page(second);
     if (first) unmap_domain_page(first);
-- 
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 Jun 01 15:46:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU36-0008B1-HS; Fri, 01 Jun 2012 15:46: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 1SaU35-00086h-JW
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:45:59 +0000
Received: from [85.158.138.51:34833] by server-4.bemta-3.messagelabs.com id
	38/54-32504-7B3E8CF4; Fri, 01 Jun 2012 15:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338565552!30346150!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25671 invoked from network); 1 Jun 2012 15:45:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:45:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548513"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:58 -0400
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 1SaTxR-0006I5-55;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:55 +0000
Message-ID: <1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 26/38] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For some reason we were holding the lock over only the unmaps at the end of
the function, rather than for the whole walk.

We might want to be more clever in the future, but for now lets just lock for
the whole walk+create process.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 46c6f17..c4daf83 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -168,6 +168,8 @@ static int create_p2m_entries(struct domain *d,
     paddr_t addr;
     unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
 
+    spin_lock(&p2m->lock);
+
     /* XXX Don't actually handle 40 bit guest physical addresses */
     BUG_ON(start_gpaddr & 0x8000000000ULL);
     BUG_ON(end_gpaddr   & 0x8000000000ULL);
@@ -249,8 +251,6 @@ static int create_p2m_entries(struct domain *d,
     rc = 0;
 
 out:
-    spin_lock(&p2m->lock);
-
     if (third) unmap_domain_page(third);
     if (second) unmap_domain_page(second);
     if (first) unmap_domain_page(first);
-- 
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 Jun 01 15:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3A-0008H3-Ha; Fri, 01 Jun 2012 15:46: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 1SaU38-0008Cl-Gm
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:02 +0000
Received: from [85.158.143.99:65367] by server-3.bemta-4.messagelabs.com id
	A1/31-04252-9B3E8CF4; Fri, 01 Jun 2012 15:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9127 invoked from network); 1 Jun 2012 15:46:00 -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;
	1 Jun 2012 15:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207444"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:55 -0400
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 1SaTxR-0006I5-Mb;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:04 +0000
Message-ID: <1338565207-2888-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 35/38] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/entry.S            |    1 +
 xen/include/asm-arm/page.h      |    2 ++
 xen/include/asm-arm/processor.h |   21 ---------------------
 xen/include/asm-arm/system.h    |    2 +-
 xen/include/public/arch-arm.h   |   23 ++++++++++++++++++++++-
 5 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 5bc3906..2ff32a1 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
+#include <public/xen.h>
 
 #define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
 #define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index f36bf6f..12ab2e8 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -2,6 +2,8 @@
 #define __ARM_PAGE_H__
 
 #include <xen/config.h>
+#include <public/xen.h>
+#include <asm/processor.h>
 
 #define PADDR_BITS              40
 #define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9b3c9dd..3849b23 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -3,27 +3,6 @@
 
 #include <asm/cpregs.h>
 
-/* PSR bits (CPSR, SPSR)*/
-
-/* 0-4: Mode */
-#define PSR_MODE_MASK 0x1f
-#define PSR_MODE_USR 0x10
-#define PSR_MODE_FIQ 0x11
-#define PSR_MODE_IRQ 0x12
-#define PSR_MODE_SVC 0x13
-#define PSR_MODE_MON 0x16
-#define PSR_MODE_ABT 0x17
-#define PSR_MODE_HYP 0x1a
-#define PSR_MODE_UND 0x1b
-#define PSR_MODE_SYS 0x1f
-
-#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 */
-#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
-
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 7963ea5..216ef1f 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -3,7 +3,7 @@
 #define __ASM_SYSTEM_H
 
 #include <xen/lib.h>
-#include <asm/processor.h>
+#include <public/arch-arm.h>
 
 #define nop() \
     asm volatile ( "nop" )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index b52bfc7..7ebe966 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -139,7 +139,28 @@ struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif
+#endif /* ifndef __ASSEMBLY __ */
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#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 */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
-- 
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 Jun 01 15:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3A-0008H3-Ha; Fri, 01 Jun 2012 15:46: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 1SaU38-0008Cl-Gm
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:02 +0000
Received: from [85.158.143.99:65367] by server-3.bemta-4.messagelabs.com id
	A1/31-04252-9B3E8CF4; Fri, 01 Jun 2012 15:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9127 invoked from network); 1 Jun 2012 15:46:00 -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;
	1 Jun 2012 15:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207444"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:55 -0400
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 1SaTxR-0006I5-Mb;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:04 +0000
Message-ID: <1338565207-2888-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 35/38] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/entry.S            |    1 +
 xen/include/asm-arm/page.h      |    2 ++
 xen/include/asm-arm/processor.h |   21 ---------------------
 xen/include/asm-arm/system.h    |    2 +-
 xen/include/public/arch-arm.h   |   23 ++++++++++++++++++++++-
 5 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 5bc3906..2ff32a1 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
+#include <public/xen.h>
 
 #define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
 #define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index f36bf6f..12ab2e8 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -2,6 +2,8 @@
 #define __ARM_PAGE_H__
 
 #include <xen/config.h>
+#include <public/xen.h>
+#include <asm/processor.h>
 
 #define PADDR_BITS              40
 #define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9b3c9dd..3849b23 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -3,27 +3,6 @@
 
 #include <asm/cpregs.h>
 
-/* PSR bits (CPSR, SPSR)*/
-
-/* 0-4: Mode */
-#define PSR_MODE_MASK 0x1f
-#define PSR_MODE_USR 0x10
-#define PSR_MODE_FIQ 0x11
-#define PSR_MODE_IRQ 0x12
-#define PSR_MODE_SVC 0x13
-#define PSR_MODE_MON 0x16
-#define PSR_MODE_ABT 0x17
-#define PSR_MODE_HYP 0x1a
-#define PSR_MODE_UND 0x1b
-#define PSR_MODE_SYS 0x1f
-
-#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 */
-#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
-
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 7963ea5..216ef1f 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -3,7 +3,7 @@
 #define __ASM_SYSTEM_H
 
 #include <xen/lib.h>
-#include <asm/processor.h>
+#include <public/arch-arm.h>
 
 #define nop() \
     asm volatile ( "nop" )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index b52bfc7..7ebe966 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -139,7 +139,28 @@ struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif
+#endif /* ifndef __ASSEMBLY __ */
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#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 */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
-- 
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 Jun 01 15:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3C-0008Ki-8H; Fri, 01 Jun 2012 15:46: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 1SaU39-0008DC-3l
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:03 +0000
Received: from [85.158.138.51:33644] by server-9.bemta-3.messagelabs.com id
	11/72-21565-AB3E8CF4; Fri, 01 Jun 2012 15:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19553 invoked from network); 1 Jun 2012 15:46:01 -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;
	1 Jun 2012 15:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:59 -0400
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 1SaTxQ-0006I5-95;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:40 +0000
Message-ID: <1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/p2m.c        |   71 ++++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-arm/p2m.h |    3 ++
 2 files changed, 70 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 095e608..9b40e93 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -10,10 +10,20 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
     struct p2m_domain *p2m = &d->arch.p2m;
     lpae_t *first = NULL, *second = NULL, *third = NULL;
 
-    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
+    printk("dom%d IPA %#"PRIpaddr"\n", d->domain_id, addr);
+
+    printk("P2M @ %p mfn:%#lx (%#03llx,%#03llx,%#03llx)\n",
+           p2m->first_level,
+           page_to_mfn(p2m->first_level),
+           first_table_offset(addr),
+           second_table_offset(addr),
+           third_table_offset(addr));
+
+    if ( first_table_offset(addr) >= LPAE_ENTRIES )
+        goto done;
 
     first = __map_domain_page(p2m->first_level);
-    printk("1ST[%#03llx] = %#016llx\n",
+    printk("1ST[%#03llx] = %#"PRIpaddr"\n",
            first_table_offset(addr),
            first[first_table_offset(addr)].bits);
     if ( !first[first_table_offset(addr)].p2m.valid ||
@@ -21,7 +31,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
         goto done;
 
     second = map_domain_page(first[first_table_offset(addr)].p2m.base);
-    printk("2ND[%#03llx] = %#016llx\n",
+    printk("2ND[%#03llx] = %#"PRIpaddr"\n",
            second_table_offset(addr),
            second[second_table_offset(addr)].bits);
     if ( !second[second_table_offset(addr)].p2m.valid ||
@@ -29,7 +39,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
         goto done;
 
     third = map_domain_page(second[second_table_offset(addr)].p2m.base);
-    printk("3RD[%#03llx] = %#016llx\n",
+    printk("3RD[%#03llx] = %#"PRIpaddr"\n",
            third_table_offset(addr),
            third[third_table_offset(addr)].bits);
 
@@ -51,6 +61,59 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+/*
+ * Lookup the MFN corresponding to a domain's PFN.
+ *
+ * There are no processor functions to do a stage 2 only lookup therefore we
+ * do a a software walk.
+ */
+paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
+    paddr_t maddr = INVALID_PADDR;
+
+    spin_lock(&p2m->lock);
+
+    first = __map_domain_page(p2m->first_level);
+    if ( !first[first_table_offset(paddr)].p2m.valid )
+        goto done_err;
+    if ( !first[first_table_offset(paddr)].p2m.table )
+    {
+        pte = first[first_table_offset(paddr)];
+        goto done;
+    }
+
+    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
+    if ( !second[second_table_offset(paddr)].p2m.valid )
+        goto done_err;
+    if ( !second[second_table_offset(paddr)].p2m.table )
+    {
+        pte = second[second_table_offset(paddr)];
+        goto done;
+    }
+
+    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
+    if ( !third[third_table_offset(paddr)].p2m.valid )
+        goto done_err;
+    if ( !third[third_table_offset(paddr)].p2m.table )
+        goto done_err;
+
+    pte = third[third_table_offset(paddr)];
+
+done:
+
+    maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
+done_err:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return maddr;
+}
+
 int guest_physmap_mark_populate_on_demand(struct domain *d,
                                           unsigned long gfn,
                                           unsigned int order)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 349923a..1afd5cb 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
 /* */
 void p2m_load_VTTBR(struct domain *d);
 
+/* */
+paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
+
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
-- 
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 Jun 01 15:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3C-0008Ki-8H; Fri, 01 Jun 2012 15:46: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 1SaU39-0008DC-3l
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:03 +0000
Received: from [85.158.138.51:33644] by server-9.bemta-3.messagelabs.com id
	11/72-21565-AB3E8CF4; Fri, 01 Jun 2012 15:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19553 invoked from network); 1 Jun 2012 15:46:01 -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;
	1 Jun 2012 15:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:59 -0400
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 1SaTxQ-0006I5-95;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:40 +0000
Message-ID: <1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/p2m.c        |   71 ++++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-arm/p2m.h |    3 ++
 2 files changed, 70 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 095e608..9b40e93 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -10,10 +10,20 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
     struct p2m_domain *p2m = &d->arch.p2m;
     lpae_t *first = NULL, *second = NULL, *third = NULL;
 
-    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
+    printk("dom%d IPA %#"PRIpaddr"\n", d->domain_id, addr);
+
+    printk("P2M @ %p mfn:%#lx (%#03llx,%#03llx,%#03llx)\n",
+           p2m->first_level,
+           page_to_mfn(p2m->first_level),
+           first_table_offset(addr),
+           second_table_offset(addr),
+           third_table_offset(addr));
+
+    if ( first_table_offset(addr) >= LPAE_ENTRIES )
+        goto done;
 
     first = __map_domain_page(p2m->first_level);
-    printk("1ST[%#03llx] = %#016llx\n",
+    printk("1ST[%#03llx] = %#"PRIpaddr"\n",
            first_table_offset(addr),
            first[first_table_offset(addr)].bits);
     if ( !first[first_table_offset(addr)].p2m.valid ||
@@ -21,7 +31,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
         goto done;
 
     second = map_domain_page(first[first_table_offset(addr)].p2m.base);
-    printk("2ND[%#03llx] = %#016llx\n",
+    printk("2ND[%#03llx] = %#"PRIpaddr"\n",
            second_table_offset(addr),
            second[second_table_offset(addr)].bits);
     if ( !second[second_table_offset(addr)].p2m.valid ||
@@ -29,7 +39,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
         goto done;
 
     third = map_domain_page(second[second_table_offset(addr)].p2m.base);
-    printk("3RD[%#03llx] = %#016llx\n",
+    printk("3RD[%#03llx] = %#"PRIpaddr"\n",
            third_table_offset(addr),
            third[third_table_offset(addr)].bits);
 
@@ -51,6 +61,59 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+/*
+ * Lookup the MFN corresponding to a domain's PFN.
+ *
+ * There are no processor functions to do a stage 2 only lookup therefore we
+ * do a a software walk.
+ */
+paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
+    paddr_t maddr = INVALID_PADDR;
+
+    spin_lock(&p2m->lock);
+
+    first = __map_domain_page(p2m->first_level);
+    if ( !first[first_table_offset(paddr)].p2m.valid )
+        goto done_err;
+    if ( !first[first_table_offset(paddr)].p2m.table )
+    {
+        pte = first[first_table_offset(paddr)];
+        goto done;
+    }
+
+    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
+    if ( !second[second_table_offset(paddr)].p2m.valid )
+        goto done_err;
+    if ( !second[second_table_offset(paddr)].p2m.table )
+    {
+        pte = second[second_table_offset(paddr)];
+        goto done;
+    }
+
+    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
+    if ( !third[third_table_offset(paddr)].p2m.valid )
+        goto done_err;
+    if ( !third[third_table_offset(paddr)].p2m.table )
+        goto done_err;
+
+    pte = third[third_table_offset(paddr)];
+
+done:
+
+    maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
+done_err:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return maddr;
+}
+
 int guest_physmap_mark_populate_on_demand(struct domain *d,
                                           unsigned long gfn,
                                           unsigned int order)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 349923a..1afd5cb 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
 /* */
 void p2m_load_VTTBR(struct domain *d);
 
+/* */
+paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
+
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3C-0008LF-LY; Fri, 01 Jun 2012 15:46: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 1SaU39-0008F2-T9
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:04 +0000
Received: from [85.158.143.99:51500] by server-2.bemta-4.messagelabs.com id
	51/59-11595-BB3E8CF4; Fri, 01 Jun 2012 15:46:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9201 invoked from network); 1 Jun 2012 15:46:01 -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;
	1 Jun 2012 15:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207456"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:58 -0400
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 1SaTxQ-0006I5-Ig;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:46 +0000
Message-ID: <1338565207-2888-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 17/38] arm: allow p2m to be created with
	specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/p2m.c         |   15 ++++++++-------
 xen/include/asm-arm/page.h |    6 ++++--
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9b40e93..46c6f17 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -148,7 +148,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -159,7 +159,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -235,11 +236,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -263,7 +264,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -271,7 +272,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -281,7 +282,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index c7b6530..bb1729a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -46,6 +46,8 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -169,7 +171,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -178,7 +180,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3C-0008LF-LY; Fri, 01 Jun 2012 15:46: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 1SaU39-0008F2-T9
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:04 +0000
Received: from [85.158.143.99:51500] by server-2.bemta-4.messagelabs.com id
	51/59-11595-BB3E8CF4; Fri, 01 Jun 2012 15:46:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9201 invoked from network); 1 Jun 2012 15:46:01 -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;
	1 Jun 2012 15:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207456"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:58 -0400
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 1SaTxQ-0006I5-Ig;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:46 +0000
Message-ID: <1338565207-2888-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 17/38] arm: allow p2m to be created with
	specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/p2m.c         |   15 ++++++++-------
 xen/include/asm-arm/page.h |    6 ++++--
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9b40e93..46c6f17 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -148,7 +148,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -159,7 +159,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -235,11 +236,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -263,7 +264,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -271,7 +272,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -281,7 +282,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index c7b6530..bb1729a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -46,6 +46,8 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -169,7 +171,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -178,7 +180,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3D-0008M4-2I; Fri, 01 Jun 2012 15:46: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 1SaU39-0008D3-Jb
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:03 +0000
Received: from [85.158.143.99:51510] by server-1.bemta-4.messagelabs.com id
	7F/F9-27869-BB3E8CF4; Fri, 01 Jun 2012 15:46:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9266 invoked from network); 1 Jun 2012 15:46:01 -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;
	1 Jun 2012 15:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207466"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:00 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:00 -0400
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 1SaTxQ-0006I5-PT;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:49 +0000
Message-ID: <1338565207-2888-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 20/38] arm: dump a page table walk when
	va_to_par 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: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/page.h |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index bb1729a..f36bf6f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -254,6 +254,9 @@ static inline void flush_guest_tlb(void)
     WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
 }
 
+extern void dump_pt_walk(uint32_t addr);
+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)
 {
@@ -270,7 +273,11 @@ static inline uint64_t va_to_par(uint32_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
-    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    if ( par & PAR_F )
+    {
+        dump_pt_walk(va);
+        panic_PAR(par, "Hypervisor");
+    }
     return par;
 }
 
@@ -314,9 +321,6 @@ static inline uint64_t gva_to_ipa(uint32_t va)
 /* Bits in the PAR returned by va_to_par */
 #define PAR_FAULT 0x1
 
-extern void dump_pt_walk(uint32_t addr);
-extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
-
 #endif /* __ASSEMBLY__ */
 
 /* These numbers add up to a 39-bit input address space.  The  ARMv7-A
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3B-0008Jf-Np; Fri, 01 Jun 2012 15:46:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU38-0008D3-Pw
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:02 +0000
Received: from [85.158.143.99:65385] by server-1.bemta-4.messagelabs.com id
	C9/F9-27869-AB3E8CF4; Fri, 01 Jun 2012 15:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9152 invoked from network); 1 Jun 2012 15:46:00 -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;
	1 Jun 2012 15:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207453"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:57 -0400
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 1SaTxQ-0006I5-DN;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:42 +0000
Message-ID: <1338565207-2888-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/38] arm: stub out sync_vcpu_execstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 do lazy exec state switching so there isn't actually anything to do.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/dummy.S  |    1 -
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 62a2f3a..bd900f9 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -96,6 +96,11 @@ void sync_local_execstate(void)
     /* Nothing to do -- no lazy switching */
 }
 
+void sync_vcpu_execstate(struct vcpu *v)
+{
+    /* Nothing to do -- no lazy switching */
+}
+
 void startup_cpu_idle_loop(void)
 {
     struct vcpu *v = current;
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3b48917..8eddd15 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -22,7 +22,6 @@ DUMMY(pirq_set_affinity);
 /* VCPU */
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
 
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3D-0008M4-2I; Fri, 01 Jun 2012 15:46: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 1SaU39-0008D3-Jb
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:03 +0000
Received: from [85.158.143.99:51510] by server-1.bemta-4.messagelabs.com id
	7F/F9-27869-BB3E8CF4; Fri, 01 Jun 2012 15:46:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9266 invoked from network); 1 Jun 2012 15:46:01 -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;
	1 Jun 2012 15:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207466"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:00 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:00 -0400
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 1SaTxQ-0006I5-PT;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:49 +0000
Message-ID: <1338565207-2888-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 20/38] arm: dump a page table walk when
	va_to_par 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: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/page.h |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index bb1729a..f36bf6f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -254,6 +254,9 @@ static inline void flush_guest_tlb(void)
     WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
 }
 
+extern void dump_pt_walk(uint32_t addr);
+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)
 {
@@ -270,7 +273,11 @@ static inline uint64_t va_to_par(uint32_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
-    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    if ( par & PAR_F )
+    {
+        dump_pt_walk(va);
+        panic_PAR(par, "Hypervisor");
+    }
     return par;
 }
 
@@ -314,9 +321,6 @@ static inline uint64_t gva_to_ipa(uint32_t va)
 /* Bits in the PAR returned by va_to_par */
 #define PAR_FAULT 0x1
 
-extern void dump_pt_walk(uint32_t addr);
-extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
-
 #endif /* __ASSEMBLY__ */
 
 /* These numbers add up to a 39-bit input address space.  The  ARMv7-A
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3B-0008Jf-Np; Fri, 01 Jun 2012 15:46:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU38-0008D3-Pw
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:02 +0000
Received: from [85.158.143.99:65385] by server-1.bemta-4.messagelabs.com id
	C9/F9-27869-AB3E8CF4; Fri, 01 Jun 2012 15:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9152 invoked from network); 1 Jun 2012 15:46:00 -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;
	1 Jun 2012 15:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207453"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:45:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:45:57 -0400
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 1SaTxQ-0006I5-DN;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:42 +0000
Message-ID: <1338565207-2888-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/38] arm: stub out sync_vcpu_execstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 do lazy exec state switching so there isn't actually anything to do.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/dummy.S  |    1 -
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 62a2f3a..bd900f9 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -96,6 +96,11 @@ void sync_local_execstate(void)
     /* Nothing to do -- no lazy switching */
 }
 
+void sync_vcpu_execstate(struct vcpu *v)
+{
+    /* Nothing to do -- no lazy switching */
+}
+
 void startup_cpu_idle_loop(void)
 {
     struct vcpu *v = current;
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3b48917..8eddd15 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -22,7 +22,6 @@ DUMMY(pirq_set_affinity);
 /* VCPU */
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
 
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3D-0008Mi-F7; Fri, 01 Jun 2012 15:46: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 1SaU3A-0008D3-BT
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:04 +0000
Received: from [85.158.143.99:65476] by server-1.bemta-4.messagelabs.com id
	F3/0A-27869-CB3E8CF4; Fri, 01 Jun 2012 15:46:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9288 invoked from network); 1 Jun 2012 15:46:02 -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;
	1 Jun 2012 15:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207473"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:01 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:01 -0400
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 1SaTxR-0006I5-RY;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:07 +0000
Message-ID: <1338565207-2888-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 38/38] HACK: arm: disable hypercall
	continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/sched.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..15fa6b4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
 
+#ifdef CONFIG_ARM
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
-- 
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 Jun 01 15:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3D-0008Mi-F7; Fri, 01 Jun 2012 15:46: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 1SaU3A-0008D3-BT
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:04 +0000
Received: from [85.158.143.99:65476] by server-1.bemta-4.messagelabs.com id
	F3/0A-27869-CB3E8CF4; Fri, 01 Jun 2012 15:46:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9288 invoked from network); 1 Jun 2012 15:46:02 -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;
	1 Jun 2012 15:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207473"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:01 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:01 -0400
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 1SaTxR-0006I5-RY;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:07 +0000
Message-ID: <1338565207-2888-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 38/38] HACK: arm: disable hypercall
	continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/sched.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..15fa6b4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
 
+#ifdef CONFIG_ARM
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
-- 
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 Jun 01 15:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46: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 1SaU3E-0008Ny-4Q; Fri, 01 Jun 2012 15: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 1SaU39-0008E8-MN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:03 +0000
Received: from [85.158.138.51:35122] by server-8.bemta-3.messagelabs.com id
	0F/80-01456-AB3E8CF4; Fri, 01 Jun 2012 15:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19594 invoked from network); 1 Jun 2012 15:46:02 -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;
	1 Jun 2012 15:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548526"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:01 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:01 -0400
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 1SaTxR-0006I5-6S;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:56 +0000
Message-ID: <1338565207-2888-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 27/38] arm: split pending SPIs (global) out from
	pending PPIs and SGIs (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

This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
seems more logical.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c          |   17 ++++++++++-------
 xen/include/asm-arm/domain.h |   10 ++++++++++
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 629a0da..91d6166 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.shared_irqs =
         xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     d->arch.vgic.pending_irqs =
-        xmalloc_array(struct pending_irq,
-                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
-    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+    for (i=0; i<d->arch.vgic.nr_lines; i++)
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
@@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     spin_lock_init(&v->arch.vgic.private_irqs.lock);
 
+    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
+    for (i = 0; i < 32; i++)
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+
     /* For SGI and PPI the target is always this CPU */
     for ( i = 0 ; i < 8 ; i++ )
         v->arch.vgic.private_irqs.itargets[i] =
@@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
     /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
-        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
-            + v->domain->arch.vgic.nr_lines];
+        n = &v->arch.vgic.pending_irqs[irq];
     else
         n = &v->domain->arch.vgic.pending_irqs[irq - 32];
     return n;
@@ -548,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -564,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
@@ -575,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 620b26e..32deb52 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -46,6 +46,10 @@ struct arch_domain
         int ctlr;
         int nr_lines;
         struct vgic_irq_rank *shared_irqs;
+        /*
+         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
+         * struct arch_vcpu.
+         */
         struct pending_irq *pending_irqs;
     } vgic;
 
@@ -114,7 +118,13 @@ struct arch_vcpu
     uint32_t gic_lr[64];
 
     struct {
+        /*
+         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
+         * struct arch_domain.
+         */
+        struct pending_irq pending_irqs[32];
         struct vgic_irq_rank private_irqs;
+
         /* This list is ordered by IRQ priority and it is used to keep
          * track of the IRQs that the VGIC injected into the guest.
          * Depending on the availability of LR registers, the IRQs might
-- 
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 Jun 01 15:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46: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 1SaU3E-0008Ny-4Q; Fri, 01 Jun 2012 15: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 1SaU39-0008E8-MN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:03 +0000
Received: from [85.158.138.51:35122] by server-8.bemta-3.messagelabs.com id
	0F/80-01456-AB3E8CF4; Fri, 01 Jun 2012 15:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19594 invoked from network); 1 Jun 2012 15:46:02 -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;
	1 Jun 2012 15:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548526"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:01 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:01 -0400
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 1SaTxR-0006I5-6S;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:56 +0000
Message-ID: <1338565207-2888-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 27/38] arm: split pending SPIs (global) out from
	pending PPIs and SGIs (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

This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
seems more logical.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c          |   17 ++++++++++-------
 xen/include/asm-arm/domain.h |   10 ++++++++++
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 629a0da..91d6166 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.shared_irqs =
         xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     d->arch.vgic.pending_irqs =
-        xmalloc_array(struct pending_irq,
-                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
-    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+    for (i=0; i<d->arch.vgic.nr_lines; i++)
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
@@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     spin_lock_init(&v->arch.vgic.private_irqs.lock);
 
+    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
+    for (i = 0; i < 32; i++)
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+
     /* For SGI and PPI the target is always this CPU */
     for ( i = 0 ; i < 8 ; i++ )
         v->arch.vgic.private_irqs.itargets[i] =
@@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
     /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
-        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
-            + v->domain->arch.vgic.nr_lines];
+        n = &v->arch.vgic.pending_irqs[irq];
     else
         n = &v->domain->arch.vgic.pending_irqs[irq - 32];
     return n;
@@ -548,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -564,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
@@ -575,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 620b26e..32deb52 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -46,6 +46,10 @@ struct arch_domain
         int ctlr;
         int nr_lines;
         struct vgic_irq_rank *shared_irqs;
+        /*
+         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
+         * struct arch_vcpu.
+         */
         struct pending_irq *pending_irqs;
     } vgic;
 
@@ -114,7 +118,13 @@ struct arch_vcpu
     uint32_t gic_lr[64];
 
     struct {
+        /*
+         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
+         * struct arch_domain.
+         */
+        struct pending_irq pending_irqs[32];
         struct vgic_irq_rank private_irqs;
+
         /* This list is ordered by IRQ priority and it is used to keep
          * track of the IRQs that the VGIC injected into the guest.
          * Depending on the availability of LR registers, the IRQs might
-- 
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 Jun 01 15:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3E-0008Pn-Uy; Fri, 01 Jun 2012 15:46: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 1SaU3B-0008D3-7W
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:05 +0000
Received: from [85.158.143.99:5997] by server-1.bemta-4.messagelabs.com id
	C7/0A-27869-CB3E8CF4; Fri, 01 Jun 2012 15:46:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9354 invoked from network); 1 Jun 2012 15:46:03 -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;
	1 Jun 2012 15:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207475"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:02 -0400
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 1SaTxQ-0006I5-HM;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:45 +0000
Message-ID: <1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,core}_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: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S   |    2 --
 xen/arch/arm/setup.c   |    7 +++++++
 xen/arch/arm/smpboot.c |    5 +++++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index c001e8d..03f7489 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 81ababb..b0cfacc 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
         }
     }
 
+    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
+         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
+        BUG();
+
+    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
+    cpumask_clear(per_cpu(cpu_core_mask, 0));
+
     printk("Brought up %ld CPUs\n", (long)num_online_cpus());
     /* TODO: smp_cpus_done(); */
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ea05afc..8517d86 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,6 +52,11 @@ unsigned long __initdata ready_cpus = 0;
 
 /* ID of the PCPU we're running on */
 DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awefully x86ish... */
+/* representing HT siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
+/* representing HT and core siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
-- 
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 Jun 01 15:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3E-0008Pn-Uy; Fri, 01 Jun 2012 15:46: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 1SaU3B-0008D3-7W
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:05 +0000
Received: from [85.158.143.99:5997] by server-1.bemta-4.messagelabs.com id
	C7/0A-27869-CB3E8CF4; Fri, 01 Jun 2012 15:46:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9354 invoked from network); 1 Jun 2012 15:46:03 -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;
	1 Jun 2012 15:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207475"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:02 -0400
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 1SaTxQ-0006I5-HM;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:45 +0000
Message-ID: <1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,core}_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: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S   |    2 --
 xen/arch/arm/setup.c   |    7 +++++++
 xen/arch/arm/smpboot.c |    5 +++++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index c001e8d..03f7489 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 81ababb..b0cfacc 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
         }
     }
 
+    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
+         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
+        BUG();
+
+    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
+    cpumask_clear(per_cpu(cpu_core_mask, 0));
+
     printk("Brought up %ld CPUs\n", (long)num_online_cpus());
     /* TODO: smp_cpus_done(); */
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ea05afc..8517d86 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,6 +52,11 @@ unsigned long __initdata ready_cpus = 0;
 
 /* ID of the PCPU we're running on */
 DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awefully x86ish... */
+/* representing HT siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
+/* representing HT and core siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
-- 
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 Jun 01 15:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3F-0008Rb-RE; Fri, 01 Jun 2012 15:46:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU3C-0008D3-44
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:06 +0000
Received: from [85.158.143.99:6058] by server-1.bemta-4.messagelabs.com id
	9C/0A-27869-DB3E8CF4; Fri, 01 Jun 2012 15:46:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9430 invoked from network); 1 Jun 2012 15:46:04 -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;
	1 Jun 2012 15:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207485"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:03 -0400
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 1SaTxQ-0006I5-S2;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:51 +0000
Message-ID: <1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 22/38] arm: implement vcpu_show_execution_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 03f7489..cab9522 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
 DUMMY(get_page);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 35907ee..ec74298 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
     panic("Error during %s-to-physical address translation\n", when);
 }
 
-void show_registers(struct cpu_user_regs *regs)
+struct reg_ctxt {
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+};
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
     print_xen_info();
     printk("CPU:    %d\n", smp_processor_id());
     printk("PC:     %08"PRIx32, regs->pc);
-    if ( !guest_mode(regs) )
+    if ( !guest_mode )
             print_symbol(" %s", regs->pc);
     printk("\n");
     printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
@@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
     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);
 
-    if ( guest_mode(regs) )
+    if ( guest_mode )
     {
         printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
                regs->sp_usr, regs->lr_usr, regs->cpsr);
@@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
                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",
-               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
-        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
         printk("\n");
     }
@@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
     printk("\n");
 }
 
+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);
+    _show_registers(regs, &ctxt, guest_mode(regs));
+}
+
+void vcpu_show_registers(const struct vcpu *v)
+{
+    struct reg_ctxt ctxt;
+    ctxt.sctlr = v->arch.sctlr;
+    ctxt.ttbcr = 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);
+}
+
 static void show_guest_stack(struct cpu_user_regs *regs)
 {
     printk("GUEST STACK GOES HERE\n");
@@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
     show_stack(regs);
 }
 
+void vcpu_show_execution_state(struct vcpu *v)
+{
+    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
+           v->domain->domain_id, v->vcpu_id);
+
+    if ( v == current )
+    {
+        show_execution_state(guest_cpu_user_regs());
+        return;
+    }
+
+    vcpu_pause(v); /* acceptably dangerous */
+
+    vcpu_show_registers(v);
+    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
+        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
+
+    vcpu_unpause(v);
+}
+
 static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
-- 
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 Jun 01 15:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3F-0008Rb-RE; Fri, 01 Jun 2012 15:46:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU3C-0008D3-44
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:06 +0000
Received: from [85.158.143.99:6058] by server-1.bemta-4.messagelabs.com id
	9C/0A-27869-DB3E8CF4; Fri, 01 Jun 2012 15:46:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9430 invoked from network); 1 Jun 2012 15:46:04 -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;
	1 Jun 2012 15:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207485"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:03 -0400
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 1SaTxQ-0006I5-S2;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:51 +0000
Message-ID: <1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 22/38] arm: implement vcpu_show_execution_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 03f7489..cab9522 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
 DUMMY(get_page);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 35907ee..ec74298 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
     panic("Error during %s-to-physical address translation\n", when);
 }
 
-void show_registers(struct cpu_user_regs *regs)
+struct reg_ctxt {
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+};
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
     print_xen_info();
     printk("CPU:    %d\n", smp_processor_id());
     printk("PC:     %08"PRIx32, regs->pc);
-    if ( !guest_mode(regs) )
+    if ( !guest_mode )
             print_symbol(" %s", regs->pc);
     printk("\n");
     printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
@@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
     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);
 
-    if ( guest_mode(regs) )
+    if ( guest_mode )
     {
         printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
                regs->sp_usr, regs->lr_usr, regs->cpsr);
@@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
                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",
-               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
-        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
         printk("\n");
     }
@@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
     printk("\n");
 }
 
+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);
+    _show_registers(regs, &ctxt, guest_mode(regs));
+}
+
+void vcpu_show_registers(const struct vcpu *v)
+{
+    struct reg_ctxt ctxt;
+    ctxt.sctlr = v->arch.sctlr;
+    ctxt.ttbcr = 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);
+}
+
 static void show_guest_stack(struct cpu_user_regs *regs)
 {
     printk("GUEST STACK GOES HERE\n");
@@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
     show_stack(regs);
 }
 
+void vcpu_show_execution_state(struct vcpu *v)
+{
+    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
+           v->domain->domain_id, v->vcpu_id);
+
+    if ( v == current )
+    {
+        show_execution_state(guest_cpu_user_regs());
+        return;
+    }
+
+    vcpu_pause(v); /* acceptably dangerous */
+
+    vcpu_show_registers(v);
+    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
+        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
+
+    vcpu_unpause(v);
+}
+
 static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
-- 
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 Jun 01 15:46:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46: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 1SaU3G-0008TG-Lu; Fri, 01 Jun 2012 15:46:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU3C-0008D3-JX
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:06 +0000
Received: from [85.158.143.99:55669] by server-1.bemta-4.messagelabs.com id
	2E/0A-27869-EB3E8CF4; Fri, 01 Jun 2012 15:46:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 1 Jun 2012 15:46:03 -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;
	1 Jun 2012 15:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207477"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:02 -0400
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 1SaTxQ-0006I5-TN;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:52 +0000
Message-ID: <1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 23/38] arm: use correct attributes for mappings
	in copy_from_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

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/setup.h |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..1a705c9 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, mattr);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b0cfacc..f5473cd 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..faadccc 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Jun 01 15:46:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46: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 1SaU3G-0008TG-Lu; Fri, 01 Jun 2012 15:46:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaU3C-0008D3-JX
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:06 +0000
Received: from [85.158.143.99:55669] by server-1.bemta-4.messagelabs.com id
	2E/0A-27869-EB3E8CF4; Fri, 01 Jun 2012 15:46:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 1 Jun 2012 15:46:03 -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;
	1 Jun 2012 15:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207477"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:02 -0400
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 1SaTxQ-0006I5-TN;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:52 +0000
Message-ID: <1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 23/38] arm: use correct attributes for mappings
	in copy_from_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

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/setup.h |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..1a705c9 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, mattr);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b0cfacc..f5473cd 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..faadccc 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Jun 01 15:46:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3H-0008VM-JR; Fri, 01 Jun 2012 15:46: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 1SaU3C-0008Kf-SB
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:07 +0000
Received: from [85.158.138.51:35296] by server-2.bemta-3.messagelabs.com id
	88/E3-17140-DB3E8CF4; Fri, 01 Jun 2012 15:46:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19803 invoked from network); 1 Jun 2012 15:46:05 -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;
	1 Jun 2012 15:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548559"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:04 -0400
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 1SaTxQ-0006I5-LL;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:47 +0000
Message-ID: <1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  155 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 +++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 204 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e867cb2..d830980 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -201,6 +202,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    if ( (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     if ( !is_idle_domain(d) )
     {
         rc = -ENOMEM;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..1491dcc
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,155 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_BASE_ADDRESS 0x1c090000
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    int rc;
+    if ( d->domain_id == 0 )
+        return 0;
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    rc = -ENOMEM;
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        goto out;
+
+    rc = 0;
+out:
+    return rc;
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
+    int val = (int)((*r) & 0xFF);
+
+    if ( dabt.size != 0 )
+    {
+        printk("VPL011: Invalid %d-byte write to offset %#x\n",
+               1<<dabt.size, offset);
+        domain_crash_synchronous();
+    }
+
+    switch ( offset )
+    {
+    case UARTDR:
+        uart0_print_char(val);
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 10ed540..f295a82 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Jun 01 15:46:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3H-0008VM-JR; Fri, 01 Jun 2012 15:46: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 1SaU3C-0008Kf-SB
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:07 +0000
Received: from [85.158.138.51:35296] by server-2.bemta-3.messagelabs.com id
	88/E3-17140-DB3E8CF4; Fri, 01 Jun 2012 15:46:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19803 invoked from network); 1 Jun 2012 15:46:05 -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;
	1 Jun 2012 15:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548559"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:04 -0400
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 1SaTxQ-0006I5-LL;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:47 +0000
Message-ID: <1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    4 +
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  155 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 +++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 204 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e867cb2..d830980 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -201,6 +202,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    if ( (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     if ( !is_idle_domain(d) )
     {
         rc = -ENOMEM;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..1491dcc
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,155 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_BASE_ADDRESS 0x1c090000
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    int rc;
+    if ( d->domain_id == 0 )
+        return 0;
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    rc = -ENOMEM;
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        goto out;
+
+    rc = 0;
+out:
+    return rc;
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
+    int val = (int)((*r) & 0xFF);
+
+    if ( dabt.size != 0 )
+    {
+        printk("VPL011: Invalid %d-byte write to offset %#x\n",
+               1<<dabt.size, offset);
+        domain_crash_synchronous();
+    }
+
+    switch ( offset )
+    {
+    case UARTDR:
+        uart0_print_char(val);
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 10ed540..f295a82 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Jun 01 15:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3I-00006V-Jm; Fri, 01 Jun 2012 15:46: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 1SaU3D-0008E8-60
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:07 +0000
Received: from [85.158.138.51:37887] by server-8.bemta-3.messagelabs.com id
	07/A0-01456-EB3E8CF4; Fri, 01 Jun 2012 15:46:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19870 invoked from network); 1 Jun 2012 15:46:06 -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;
	1 Jun 2012 15:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548563"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:05 -0400
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 1SaTxQ-0006I5-G0;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:44 +0000
Message-ID: <1338565207-2888-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/38] arm: implement stub version of
	flush_tlb_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: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/smp.c   |    9 +++++++++
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 8eddd15..c001e8d 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -48,7 +48,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(flush_tlb_mask);
 DUMMY(gmfn_to_mfn);
 DUMMY(hypercall_create_continuation);
 DUMMY(send_timer_event);
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
index cad84f5..824c8c8 100644
--- a/xen/arch/arm/smp.c
+++ b/xen/arch/arm/smp.c
@@ -1,5 +1,14 @@
 #include <xen/config.h>
+#include <asm/system.h>
 #include <asm/smp.h>
+#include <asm/cpregs.h>
+#include <asm/page.h>
+
+void flush_tlb_mask(const cpumask_t *mask)
+{
+    /* XXX IPI other processors */
+    flush_xen_data_tlb();
+}
 
 void smp_call_function(
     void (*func) (void *info),
-- 
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 Jun 01 15:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaU3I-00006V-Jm; Fri, 01 Jun 2012 15:46: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 1SaU3D-0008E8-60
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:07 +0000
Received: from [85.158.138.51:37887] by server-8.bemta-3.messagelabs.com id
	07/A0-01456-EB3E8CF4; Fri, 01 Jun 2012 15:46:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19870 invoked from network); 1 Jun 2012 15:46:06 -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;
	1 Jun 2012 15:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548563"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:05 -0400
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 1SaTxQ-0006I5-G0;
	Fri, 01 Jun 2012 16:40:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:44 +0000
Message-ID: <1338565207-2888-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/38] arm: implement stub version of
	flush_tlb_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: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/smp.c   |    9 +++++++++
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 8eddd15..c001e8d 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -48,7 +48,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(flush_tlb_mask);
 DUMMY(gmfn_to_mfn);
 DUMMY(hypercall_create_continuation);
 DUMMY(send_timer_event);
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
index cad84f5..824c8c8 100644
--- a/xen/arch/arm/smp.c
+++ b/xen/arch/arm/smp.c
@@ -1,5 +1,14 @@
 #include <xen/config.h>
+#include <asm/system.h>
 #include <asm/smp.h>
+#include <asm/cpregs.h>
+#include <asm/page.h>
+
+void flush_tlb_mask(const cpumask_t *mask)
+{
+    /* XXX IPI other processors */
+    flush_xen_data_tlb();
+}
 
 void smp_call_function(
     void (*func) (void *info),
-- 
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 Jun 01 15:46:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46: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 1SaU3J-00009K-IR; Fri, 01 Jun 2012 15:46: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 1SaU3D-0008Cl-8I
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:07 +0000
Received: from [85.158.143.99:6147] by server-3.bemta-4.messagelabs.com id
	C5/51-04252-FB3E8CF4; Fri, 01 Jun 2012 15:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9508 invoked from network); 1 Jun 2012 15:46:05 -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;
	1 Jun 2012 15:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207494"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:05 -0400
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 1SaTxR-0006I5-Q4;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:06 +0000
Message-ID: <1338565207-2888-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 37/38] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on init-xenstore-domain.c.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xcutils/Makefile  |    6 ++-
 tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 tools/xcutils/xcbuild.c

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 6c502f1..dcd2c84 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -11,7 +11,7 @@
 XEN_ROOT	= $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-PROGRAMS = xc_restore xc_save readnotes lsevtchn
+PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
 
 CFLAGS += -Werror
 
@@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 
 .PHONY: all
 all: build
@@ -32,6 +33,9 @@ xc_restore: xc_restore.o
 xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xcbuild: xcbuild.o
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
 
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
new file mode 100644
index 0000000..8f8660e
--- /dev/null
+++ b/tools/xcutils/xcbuild.c
@@ -0,0 +1,100 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#include <errno.h>
+
+#include <xenctrl.h>
+#include <xentoollog.h>
+#include <xc_dom.h>
+
+int main(int argc, char **argv)
+{
+	xentoollog_logger *logger;
+	xc_interface *xch;
+	int rv;
+	const char *image;
+	uint32_t domid;
+	xen_domain_handle_t handle;
+	int maxmem = 128; /* MB */ //atoi(argv[2]);
+	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
+	struct xc_dom_image *dom;
+
+	image = (argc < 2) ? "guest.img" : argv[1];
+	printf("Image: %s\n", image);
+	printf("Memory: %dKB\n", memory_kb);
+
+	logger = (xentoollog_logger*)
+		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
+	if ( logger == NULL )
+	{
+		perror("xtl_createlogger_stdiostream");
+		exit(1);
+	}
+
+	xch = xc_interface_open(logger, logger, 0);
+	if ( xch == NULL )
+	{
+		perror("xc_interface_open");
+		exit(1);
+	}
+
+	rv = xc_dom_loginit(xch);
+	if (rv) return rv;
+
+	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	//if (rv) return rv;
+
+	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
+	printf("xc_domain_create: %d (%d)\n", rv, errno);
+	if ( rv < 0 )
+	{
+		perror("xc_domain_create");
+		exit(1);
+	}
+
+	printf("building dom%d\n", domid);
+
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if ( rv < 0)
+	{
+		perror("xc_domain_max_vcpus");
+		exit(1);
+	}
+
+	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
+	if ( rv < 0)
+	{
+		perror("xc_domain_setmaxmem");
+		exit(1);
+	}
+
+	dom = xc_dom_allocate(xch, "", NULL);
+	rv = xc_dom_kernel_file(dom, image);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_unpause(xch, domid);
+	if ( rv )
+	{
+		perror("xc_domain_unpause");
+		exit(1);
+	}
+
+	xc_interface_close(xch);
+
+	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 Jun 01 15:46:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15:46: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 1SaU3J-00009K-IR; Fri, 01 Jun 2012 15:46: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 1SaU3D-0008Cl-8I
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:07 +0000
Received: from [85.158.143.99:6147] by server-3.bemta-4.messagelabs.com id
	C5/51-04252-FB3E8CF4; Fri, 01 Jun 2012 15:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338565558!30625361!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9508 invoked from network); 1 Jun 2012 15:46:05 -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;
	1 Jun 2012 15:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197207494"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:05 -0400
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 1SaTxR-0006I5-Q4;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:40:06 +0000
Message-ID: <1338565207-2888-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 37/38] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on init-xenstore-domain.c.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xcutils/Makefile  |    6 ++-
 tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 tools/xcutils/xcbuild.c

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 6c502f1..dcd2c84 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -11,7 +11,7 @@
 XEN_ROOT	= $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-PROGRAMS = xc_restore xc_save readnotes lsevtchn
+PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
 
 CFLAGS += -Werror
 
@@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 
 .PHONY: all
 all: build
@@ -32,6 +33,9 @@ xc_restore: xc_restore.o
 xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xcbuild: xcbuild.o
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
 
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
new file mode 100644
index 0000000..8f8660e
--- /dev/null
+++ b/tools/xcutils/xcbuild.c
@@ -0,0 +1,100 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#include <errno.h>
+
+#include <xenctrl.h>
+#include <xentoollog.h>
+#include <xc_dom.h>
+
+int main(int argc, char **argv)
+{
+	xentoollog_logger *logger;
+	xc_interface *xch;
+	int rv;
+	const char *image;
+	uint32_t domid;
+	xen_domain_handle_t handle;
+	int maxmem = 128; /* MB */ //atoi(argv[2]);
+	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
+	struct xc_dom_image *dom;
+
+	image = (argc < 2) ? "guest.img" : argv[1];
+	printf("Image: %s\n", image);
+	printf("Memory: %dKB\n", memory_kb);
+
+	logger = (xentoollog_logger*)
+		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
+	if ( logger == NULL )
+	{
+		perror("xtl_createlogger_stdiostream");
+		exit(1);
+	}
+
+	xch = xc_interface_open(logger, logger, 0);
+	if ( xch == NULL )
+	{
+		perror("xc_interface_open");
+		exit(1);
+	}
+
+	rv = xc_dom_loginit(xch);
+	if (rv) return rv;
+
+	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	//if (rv) return rv;
+
+	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
+	printf("xc_domain_create: %d (%d)\n", rv, errno);
+	if ( rv < 0 )
+	{
+		perror("xc_domain_create");
+		exit(1);
+	}
+
+	printf("building dom%d\n", domid);
+
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if ( rv < 0)
+	{
+		perror("xc_domain_max_vcpus");
+		exit(1);
+	}
+
+	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
+	if ( rv < 0)
+	{
+		perror("xc_domain_setmaxmem");
+		exit(1);
+	}
+
+	dom = xc_dom_allocate(xch, "", NULL);
+	rv = xc_dom_kernel_file(dom, image);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_unpause(xch, domid);
+	if ( rv )
+	{
+		perror("xc_domain_unpause");
+		exit(1);
+	}
+
+	xc_interface_close(xch);
+
+	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 Jun 01 15:46:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3K-0000CS-M3; Fri, 01 Jun 2012 15:46: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 1SaU3E-0008NS-Bg
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:08 +0000
Received: from [85.158.138.51:35420] by server-4.bemta-3.messagelabs.com id
	21/94-32504-FB3E8CF4; Fri, 01 Jun 2012 15:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 1 Jun 2012 15:46:06 -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;
	1 Jun 2012 15:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548565"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:06 -0400
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 1SaTxR-0006I5-AU;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:59 +0000
Message-ID: <1338565207-2888-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 30/38] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Upgrading barriers is conservative and may not be necessary.

Protected Table Walk traps stage 1 page tables which refer to device memory
(per stage 2) using a non-device mapping. This generally indicates a guest
error but trapping it as a fault for now helps us know if something odd is
going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c     |    2 +-
 xen/include/asm-arm/processor.h |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1b19e54..a9e7f43 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -333,7 +333,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 81924a4..9b3c9dd 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -76,6 +76,10 @@
 #define HCR_TWI         (1<<13)
 #define HCR_DC          (1<<12)
 #define HCR_BSU_MASK    (3<<10)
+#define HCR_BSU_NONE     (0<<10)
+#define HCR_BSU_INNER    (1<<10)
+#define HCR_BSU_OUTER    (2<<10)
+#define HCR_BSU_FULL     (3<<10)
 #define HCR_FB          (1<<9)
 #define HCR_VA          (1<<8)
 #define HCR_VI          (1<<7)
-- 
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 Jun 01 15:46:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3K-0000CS-M3; Fri, 01 Jun 2012 15:46: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 1SaU3E-0008NS-Bg
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:08 +0000
Received: from [85.158.138.51:35420] by server-4.bemta-3.messagelabs.com id
	21/94-32504-FB3E8CF4; Fri, 01 Jun 2012 15:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1338565560!11696972!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDc3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 1 Jun 2012 15:46:06 -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;
	1 Jun 2012 15:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="26548565"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 11:46:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 11:46:06 -0400
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 1SaTxR-0006I5-AU;
	Fri, 01 Jun 2012 16:40:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 1 Jun 2012 15:39:59 +0000
Message-ID: <1338565207-2888-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 30/38] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Upgrading barriers is conservative and may not be necessary.

Protected Table Walk traps stage 1 page tables which refer to device memory
(per stage 2) using a non-device mapping. This generally indicates a guest
error but trapping it as a fault for now helps us know if something odd is
going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c     |    2 +-
 xen/include/asm-arm/processor.h |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1b19e54..a9e7f43 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -333,7 +333,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 81924a4..9b3c9dd 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -76,6 +76,10 @@
 #define HCR_TWI         (1<<13)
 #define HCR_DC          (1<<12)
 #define HCR_BSU_MASK    (3<<10)
+#define HCR_BSU_NONE     (0<<10)
+#define HCR_BSU_INNER    (1<<10)
+#define HCR_BSU_OUTER    (2<<10)
+#define HCR_BSU_FULL     (3<<10)
 #define HCR_FB          (1<<9)
 #define HCR_VA          (1<<8)
 #define HCR_VI          (1<<7)
-- 
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 Jun 01 15:46:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3M-0000GD-7k; Fri, 01 Jun 2012 15:46: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 1SaU3F-0008PM-8o
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:09 +0000
Received: from [85.158.138.51:35469] by server-12.bemta-3.messagelabs.com id
	07/9D-29860-0C3E8CF4; Fri, 01 Jun 2012 15:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338565567!30465793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15616 invoked from network); 1 Jun 2012 15:46:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12791365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 15:40:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	16:40:57 +0100
Message-ID: <1338565256.1077.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Fri, 1 Jun 2012 16:40:56 +0100
In-Reply-To: <4FC3A7B4.3020805@xen.org>
References: <CANSMP-7mijyMvO=ssvR0rNn0TFPAPyrvgaT2xj_OMdryU_FkOg@mail.gmail.com>
	<CAFivhPn4GzWQf3ssEkPrD3k4oYYg=fAiF=M9gr04cxn-1mP3Jw@mail.gmail.com>
	<4FC3A7B4.3020805@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Using XL toolstack (Xen) with DRBD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-05-28 at 17:28 +0100, Lars Kurth wrote:
> Is this on the roadmap for 4.2 or 4.3?

This == block hotplug scripts in (lib)xl?

It's on the TODO list for 4.2 as a blocker, marked as following on from
the general hotplug script improvements. I think Roger has most of the
implementation ready, pending a few other dependent changes going in.

Ian.


> Lars
> 
> On 28/05/2012 13:54, Florian Heigl wrote:
> > I wish...
> >
> > The message comes from XL as far as I remember.
> > It told me "Sorry, external blocks aren't implemented yet" or
> > something like that.
> >
> > This also affects stuff like OpenNebula + Moosefs as far as I can tell.
> >
> > Maybe you know some C and can try adding the support?
> >
> > Florian
> >
> > 2012/5/18 Chris Dickson<chrisd1100@gmail.com>:
> >> Hello,
> >>
> >> Currently it seems that the drbd disk type with Xen's XL toolstack (vs XM)
> >> to get the automatic promotion/demotion behavior of drbd devices is not
> >> supported. Is there something I can tweak with the block-drbd script to get
> >> this to work?
> >>
> >> Thanks,
> >>
> >> Chris
> >>
> >> _______________________________________________
> >> 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







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

From xen-devel-bounces@lists.xen.org Fri Jun 01 15:46:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 15: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 1SaU3M-0000GD-7k; Fri, 01 Jun 2012 15:46: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 1SaU3F-0008PM-8o
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 15:46:09 +0000
Received: from [85.158.138.51:35469] by server-12.bemta-3.messagelabs.com id
	07/9D-29860-0C3E8CF4; Fri, 01 Jun 2012 15:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338565567!30465793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15616 invoked from network); 1 Jun 2012 15:46:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 15:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12791365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 15:40:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	16:40:57 +0100
Message-ID: <1338565256.1077.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Fri, 1 Jun 2012 16:40:56 +0100
In-Reply-To: <4FC3A7B4.3020805@xen.org>
References: <CANSMP-7mijyMvO=ssvR0rNn0TFPAPyrvgaT2xj_OMdryU_FkOg@mail.gmail.com>
	<CAFivhPn4GzWQf3ssEkPrD3k4oYYg=fAiF=M9gr04cxn-1mP3Jw@mail.gmail.com>
	<4FC3A7B4.3020805@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Using XL toolstack (Xen) with DRBD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-05-28 at 17:28 +0100, Lars Kurth wrote:
> Is this on the roadmap for 4.2 or 4.3?

This == block hotplug scripts in (lib)xl?

It's on the TODO list for 4.2 as a blocker, marked as following on from
the general hotplug script improvements. I think Roger has most of the
implementation ready, pending a few other dependent changes going in.

Ian.


> Lars
> 
> On 28/05/2012 13:54, Florian Heigl wrote:
> > I wish...
> >
> > The message comes from XL as far as I remember.
> > It told me "Sorry, external blocks aren't implemented yet" or
> > something like that.
> >
> > This also affects stuff like OpenNebula + Moosefs as far as I can tell.
> >
> > Maybe you know some C and can try adding the support?
> >
> > Florian
> >
> > 2012/5/18 Chris Dickson<chrisd1100@gmail.com>:
> >> Hello,
> >>
> >> Currently it seems that the drbd disk type with Xen's XL toolstack (vs XM)
> >> to get the automatic promotion/demotion behavior of drbd devices is not
> >> supported. Is there something I can tweak with the block-drbd script to get
> >> this to work?
> >>
> >> Thanks,
> >>
> >> Chris
> >>
> >> _______________________________________________
> >> 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







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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:21:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:21:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaUaw-0004ob-9b; Fri, 01 Jun 2012 16:20:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1SaUat-0004oV-TR
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:20:56 +0000
Received: from [193.109.254.147:55983] by server-10.bemta-14.messagelabs.com
	id 90/9B-27843-7EBE8CF4; Fri, 01 Jun 2012 16:20:55 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338567646!7258575!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18822 invoked from network); 1 Jun 2012 16:20:47 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:20:47 -0000
Received: by yenm4 with SMTP id m4so2259361yen.32
	for <xen-devel@lists.xen.org>; Fri, 01 Jun 2012 09:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=KAqwNjndHoDp2nC2ZwThKKlITMfe2fxbueBtAfpTyUI=;
	b=EXrnjYRcJJ9xPJHQg19X0bUvVx7q1cNDO2q2FLpcdjjjPA2LPkEfVhWoynhwLBZ6Sb
	gscVJ7X2Nf4NWl8khfVg/PJZ7XxrX0PrxP4mM/B+8wCBByxNZq+IAXOl+W75TbGecpb6
	zDT/tPOJ/WcWCgIaHhYeYXn0f3CAtobysSBse2FtNSoSHAkxe8iVKlNqbvHDHi8xq7U9
	+KTE8/a8vqwy7r6P4K8REO+slqcwfO+9DLEE/OsCvgGhRS7D9CzXl+dTQ3LlFOKswXao
	9VO+diAIgGcgho3iOnDkx/4iWQ1/NpgxydKh/DvOudHX7lE3Ng4FD8Y419Ez4NeqcowM
	PVVA==
Received: by 10.236.115.196 with SMTP id e44mr3256522yhh.90.1338567646380;
	Fri, 01 Jun 2012 09:20:46 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id p14sm3197464ani.8.2012.06.01.09.20.43
	(version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 09:20:45 -0700 (PDT)
Message-ID: <4FC8EBD9.4@cantab.net>
Date: Fri, 01 Jun 2012 17:20:41 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 23/38] arm: use correct attributes for
 mappings in copy_from_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 01/06/12 16:39, Ian Campbell wrote:
> The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
> a device type mapping (hence dev shared).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Potentially the bootloader could provide the DTB in flash but this seems
unlikely.

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

David

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:21:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:21:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaUaw-0004ob-9b; Fri, 01 Jun 2012 16:20:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1SaUat-0004oV-TR
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:20:56 +0000
Received: from [193.109.254.147:55983] by server-10.bemta-14.messagelabs.com
	id 90/9B-27843-7EBE8CF4; Fri, 01 Jun 2012 16:20:55 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338567646!7258575!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18822 invoked from network); 1 Jun 2012 16:20:47 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:20:47 -0000
Received: by yenm4 with SMTP id m4so2259361yen.32
	for <xen-devel@lists.xen.org>; Fri, 01 Jun 2012 09:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=KAqwNjndHoDp2nC2ZwThKKlITMfe2fxbueBtAfpTyUI=;
	b=EXrnjYRcJJ9xPJHQg19X0bUvVx7q1cNDO2q2FLpcdjjjPA2LPkEfVhWoynhwLBZ6Sb
	gscVJ7X2Nf4NWl8khfVg/PJZ7XxrX0PrxP4mM/B+8wCBByxNZq+IAXOl+W75TbGecpb6
	zDT/tPOJ/WcWCgIaHhYeYXn0f3CAtobysSBse2FtNSoSHAkxe8iVKlNqbvHDHi8xq7U9
	+KTE8/a8vqwy7r6P4K8REO+slqcwfO+9DLEE/OsCvgGhRS7D9CzXl+dTQ3LlFOKswXao
	9VO+diAIgGcgho3iOnDkx/4iWQ1/NpgxydKh/DvOudHX7lE3Ng4FD8Y419Ez4NeqcowM
	PVVA==
Received: by 10.236.115.196 with SMTP id e44mr3256522yhh.90.1338567646380;
	Fri, 01 Jun 2012 09:20:46 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id p14sm3197464ani.8.2012.06.01.09.20.43
	(version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 09:20:45 -0700 (PDT)
Message-ID: <4FC8EBD9.4@cantab.net>
Date: Fri, 01 Jun 2012 17:20:41 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 23/38] arm: use correct attributes for
 mappings in copy_from_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 01/06/12 16:39, Ian Campbell wrote:
> The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
> a device type mapping (hence dev shared).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Potentially the bootloader could provide the DTB in flash but this seems
unlikely.

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

David

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:28:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaUhV-00055M-9s; Fri, 01 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SaUhR-00055H-JR
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:27:44 +0000
Received: from [85.158.139.83:25539] by server-3.bemta-5.messagelabs.com id
	6C/E5-29112-C7DE8CF4; Fri, 01 Jun 2012 16:27:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338568058!27666312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13844 invoked from network); 1 Jun 2012 16:27:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:27:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:27:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 17:27:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaUhN-00047B-E8; Fri, 01 Jun 2012 16:27:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaUhN-0006bX-Cf;
	Fri, 01 Jun 2012 17:27:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.60793.374823.597252@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 17:27:37 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
In-Reply-To: <3496f86000b80595b34a.1338535311@linux-x12>,
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>,
	<20424.39815.180423.370810@mariner.uk.xensource.com>
References: <3496f86000b80595b34a.1338535311@linux-x12>
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>
	<20424.39815.180423.370810@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty [and 2 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

Bamvor Jian Zhang writes ("[PATCH] [v3] libxl: Add API to retrieve
domain consol
>  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
>  tty) will lead to null pointer access in CTX maco.

So once again, well done for spotting this.

During some private discussion with Ian Campbell I came up with the
a proposal to fix it, which I have now implemented in the form of the
patch below.

Please comment.

NB this patch cannot be applied to xen-unstable.hg staging tip.  It
needs to go in the middle of my save/restore series.  I think this is
a sufficiently off-the-mainline bug (it will only show up with
allocation errors) that it's better to avoid introducing any more
merge conflicts than absolutely necessary.  And doing it this way
avoids my series ending up with a tip containing callers which wrongly
pass 0 for gc_opt.

Thanks,
Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Do not pass NULL as gc_opt; introduce NOGC

In 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc.

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>

---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   36 +++++++++++++++++++++++-------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 53626ae..6a0fa85 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index eaf378b..431791a 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -107,7 +107,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 13d2fc1..875aaea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2111,6 +2120,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 2382c9d..3a5f292 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
tg: (e2dea8e..) t/xen/xl.nogc (depends on: t/xen/xl.savefile.async)

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:28:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaUhV-00055M-9s; Fri, 01 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SaUhR-00055H-JR
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:27:44 +0000
Received: from [85.158.139.83:25539] by server-3.bemta-5.messagelabs.com id
	6C/E5-29112-C7DE8CF4; Fri, 01 Jun 2012 16:27:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338568058!27666312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13844 invoked from network); 1 Jun 2012 16:27:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:27:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:27:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 17:27:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaUhN-00047B-E8; Fri, 01 Jun 2012 16:27:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaUhN-0006bX-Cf;
	Fri, 01 Jun 2012 17:27:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.60793.374823.597252@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 17:27:37 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
In-Reply-To: <3496f86000b80595b34a.1338535311@linux-x12>,
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>,
	<20424.39815.180423.370810@mariner.uk.xensource.com>
References: <3496f86000b80595b34a.1338535311@linux-x12>
	<1338545370.17466.66.camel@zakaz.uk.xensource.com>
	<20424.39815.180423.370810@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v3] libxl: Add API to retrieve domain
	console tty [and 2 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

Bamvor Jian Zhang writes ("[PATCH] [v3] libxl: Add API to retrieve
domain consol
>  BUT, NOT update strdup to libxl__strdup. bacause libxl__strdup(0,
>  tty) will lead to null pointer access in CTX maco.

So once again, well done for spotting this.

During some private discussion with Ian Campbell I came up with the
a proposal to fix it, which I have now implemented in the form of the
patch below.

Please comment.

NB this patch cannot be applied to xen-unstable.hg staging tip.  It
needs to go in the middle of my save/restore series.  I think this is
a sufficiently off-the-mainline bug (it will only show up with
allocation errors) that it's better to avoid introducing any more
merge conflicts than absolutely necessary.  And doing it this way
avoids my series ending up with a tip containing callers which wrongly
pass 0 for gc_opt.

Thanks,
Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Do not pass NULL as gc_opt; introduce NOGC

In 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc.

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>

---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   36 +++++++++++++++++++++++-------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 30 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 53626ae..6a0fa85 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index eaf378b..431791a 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -107,7 +107,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 13d2fc1..875aaea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2111,6 +2120,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 2382c9d..3a5f292 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
tg: (e2dea8e..) t/xen/xl.nogc (depends on: t/xen/xl.savefile.async)

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:28:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:28: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 1SaUhe-00055r-MV; Fri, 01 Jun 2012 16:27:54 +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 1SaUhd-00055j-Di
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:27:53 +0000
Received: from [85.158.139.83:28552] by server-6.bemta-5.messagelabs.com id
	7F/75-31790-88DE8CF4; Fri, 01 Jun 2012 16:27:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1338568069!31653304!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5355 invoked from network); 1 Jun 2012 16:27:50 -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;
	1 Jun 2012 16:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197212556"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 12:27:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 12:27:48 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaUZE-0007NW-AY;
	Fri, 01 Jun 2012 17:19:12 +0100
Message-ID: <4FC8EB1A.70608@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:17:30 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1338462397-32111-1-git-send-email-david.vrabel@citrix.com>
	<CAFLBxZZ6uRj3vwSv4k1=ejCyftcDP-G6WAM4CTYynyhhHDn0YA@mail.gmail.com>
	<4FC780F1.201@citrix.com>
In-Reply-To: <4FC780F1.201@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3 0/3] trace: improve hypercall tracing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 15:32, David Vrabel wrote:
> On 31/05/12 15:21, George Dunlap wrote:
>> On Thu, May 31, 2012 at 12:06 PM, David Vrabel<david.vrabel@citrix.com>  wrote:
>>> These are probably for 4.3.
>> Thanks for doing these, David.
> Thanks for the review.
>
>> I wouldn't oppose these going into 4.2;  but it is getting awfully
>> late.  (I acked them "4.2-only" just to flag that up to the
>> committers.)
> I think they should be for 4.3 -- there's more important things needing
> to be merged into 4.2.
>
>> BTW, what did you use to send these patches?  Any chance you could use
>> "hg email" (or the git equivalent if you're using git) instead?  It
>> makes it a lot easier for me to integrate them into my review
>> workflow. :-)
> I did use git send-email.  What's the problem with the series? I can see
> if there options I could turn on that would help.
Curious.  I'm not exactly sure; just that the tool I use to trawl a 
gmail folder looking for patch series (hg mimport) for some reason 
identified it as 3 independent patches (and I think put them in the 
wrong order), rather than a single 3-patch series.

Maybe someday I'll take a look and figure out what went wrong.

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:28:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:28: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 1SaUhe-00055r-MV; Fri, 01 Jun 2012 16:27:54 +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 1SaUhd-00055j-Di
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:27:53 +0000
Received: from [85.158.139.83:28552] by server-6.bemta-5.messagelabs.com id
	7F/75-31790-88DE8CF4; Fri, 01 Jun 2012 16:27:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1338568069!31653304!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5355 invoked from network); 1 Jun 2012 16:27:50 -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;
	1 Jun 2012 16:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197212556"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 12:27:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 12:27:48 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaUZE-0007NW-AY;
	Fri, 01 Jun 2012 17:19:12 +0100
Message-ID: <4FC8EB1A.70608@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:17:30 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1338462397-32111-1-git-send-email-david.vrabel@citrix.com>
	<CAFLBxZZ6uRj3vwSv4k1=ejCyftcDP-G6WAM4CTYynyhhHDn0YA@mail.gmail.com>
	<4FC780F1.201@citrix.com>
In-Reply-To: <4FC780F1.201@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3 0/3] trace: improve hypercall tracing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 15:32, David Vrabel wrote:
> On 31/05/12 15:21, George Dunlap wrote:
>> On Thu, May 31, 2012 at 12:06 PM, David Vrabel<david.vrabel@citrix.com>  wrote:
>>> These are probably for 4.3.
>> Thanks for doing these, David.
> Thanks for the review.
>
>> I wouldn't oppose these going into 4.2;  but it is getting awfully
>> late.  (I acked them "4.2-only" just to flag that up to the
>> committers.)
> I think they should be for 4.3 -- there's more important things needing
> to be merged into 4.2.
>
>> BTW, what did you use to send these patches?  Any chance you could use
>> "hg email" (or the git equivalent if you're using git) instead?  It
>> makes it a lot easier for me to integrate them into my review
>> workflow. :-)
> I did use git send-email.  What's the problem with the series? I can see
> if there options I could turn on that would help.
Curious.  I'm not exactly sure; just that the tool I use to trawl a 
gmail folder looking for patch series (hg mimport) for some reason 
identified it as 3 independent patches (and I think put them in the 
wrong order), rather than a single 3-patch series.

Maybe someday I'll take a look and figure out what went wrong.

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaUvQ-0006BP-6a; Fri, 01 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SaUvN-0006BK-Sa
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:42:06 +0000
Received: from [85.158.138.51:6749] by server-10.bemta-3.messagelabs.com id
	F0/54-12071-DD0F8CF4; Fri, 01 Jun 2012 16:42:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338568924!22299895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20734 invoked from network); 1 Jun 2012 16:42:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:42:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792476"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:42:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 17:42:03 +0100
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 1SaUvL-0004CG-3j;
	Fri, 01 Jun 2012 16:42:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaUvK-0005gC-N8;
	Fri, 01 Jun 2012 17:42:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13003-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:42:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13003: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 13002

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2       fail REGR. vs. 13002
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 12999

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

version targeted for testing:
 xen                  137b02968b40
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Not pushing.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaUvQ-0006BP-6a; Fri, 01 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SaUvN-0006BK-Sa
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:42:06 +0000
Received: from [85.158.138.51:6749] by server-10.bemta-3.messagelabs.com id
	F0/54-12071-DD0F8CF4; Fri, 01 Jun 2012 16:42:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1338568924!22299895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20734 invoked from network); 1 Jun 2012 16:42:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:42:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792476"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:42:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 17:42:03 +0100
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 1SaUvL-0004CG-3j;
	Fri, 01 Jun 2012 16:42:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaUvK-0005gC-N8;
	Fri, 01 Jun 2012 17:42:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13003-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:42:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13003: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 13002

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2       fail REGR. vs. 13002
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 12999

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

version targeted for testing:
 xen                  137b02968b40
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Not pushing.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaUzU-0006Ib-TZ; Fri, 01 Jun 2012 16:46: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 1SaUzT-0006IV-DV
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:46:19 +0000
Received: from [85.158.143.99:13192] by server-3.bemta-4.messagelabs.com id
	68/A2-04252-AD1F8CF4; Fri, 01 Jun 2012 16:46:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1338569175!27586796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12704 invoked from network); 1 Jun 2012 16:46:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:46:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	17:46:12 +0100
Message-ID: <1338569170.1077.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 1 Jun 2012 17:46:10 +0100
In-Reply-To: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/38] arm: boot a dom1 to "Calibrating delay
 loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 16:38 +0100, Ian Campbell wrote:
> I still need to cleanup the Linux side of this, that probably won't
> happen today and these patches probably don't work without those
> changes... 

I've pushed my dev tree, which contains several hacks and lots of stuff
to cleanup, to:
        git://xenbits.xen.org/people/ianc/linux-2.6.git devel/arm-hacks

It's based of David's[0] vexpress-dt branch + Stefanos's[1]
vexpress-dt-privcmd branch.

It contains a backport of some old version of Mark Zynger's arch_timers
stuff, a very hacky XENMAPSPACE_gmfn_foreign, loads of mess around UARTs
and device tree stuff which make no sense etc etc.

At the moment you need CONFIG_ARM_ARCH_TIMER=y for domU and =n for
dom0... 

Nobody look too closely ;-)

Ian.

[0] git://xenbits.xen.org/people/dvrabel/linux.git
[1] git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaUzU-0006Ib-TZ; Fri, 01 Jun 2012 16:46: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 1SaUzT-0006IV-DV
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:46:19 +0000
Received: from [85.158.143.99:13192] by server-3.bemta-4.messagelabs.com id
	68/A2-04252-AD1F8CF4; Fri, 01 Jun 2012 16:46:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1338569175!27586796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12704 invoked from network); 1 Jun 2012 16:46:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:46:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	17:46:12 +0100
Message-ID: <1338569170.1077.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 1 Jun 2012 17:46:10 +0100
In-Reply-To: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/38] arm: boot a dom1 to "Calibrating delay
 loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 16:38 +0100, Ian Campbell wrote:
> I still need to cleanup the Linux side of this, that probably won't
> happen today and these patches probably don't work without those
> changes... 

I've pushed my dev tree, which contains several hacks and lots of stuff
to cleanup, to:
        git://xenbits.xen.org/people/ianc/linux-2.6.git devel/arm-hacks

It's based of David's[0] vexpress-dt branch + Stefanos's[1]
vexpress-dt-privcmd branch.

It contains a backport of some old version of Mark Zynger's arch_timers
stuff, a very hacky XENMAPSPACE_gmfn_foreign, loads of mess around UARTs
and device tree stuff which make no sense etc etc.

At the moment you need CONFIG_ARM_ARCH_TIMER=y for domU and =n for
dom0... 

Nobody look too closely ;-)

Ian.

[0] git://xenbits.xen.org/people/dvrabel/linux.git
[1] git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaV1J-0006Q2-IV; Fri, 01 Jun 2012 16:48: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 1SaV1I-0006Ps-45
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:48:12 +0000
Received: from [85.158.143.35:16183] by server-3.bemta-4.messagelabs.com id
	DB/F4-04252-B42F8CF4; Fri, 01 Jun 2012 16:48:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1338569285!17165665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10966 invoked from network); 1 Jun 2012 16:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792550"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:48:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	17:48:04 +0100
Message-ID: <1338569283.1077.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:48:03 +0100
In-Reply-To: <20423.35295.846826.21182@mariner.uk.xensource.com>
References: <osstest-12988-mainreport@xen.org>
	<1338371077.31698.29.camel@zakaz.uk.xensource.com>
	<1338371198.31698.30.camel@zakaz.uk.xensource.com>
	<20421.61199.525262.572856@mariner.uk.xensource.com>
	<CAOvdn6WziXKV0JT_ofUpFaY6aTsXVWBhdXb81SL+CgQvKL7rAg@mail.gmail.com>
	<CAOvdn6XB_aNEJBwpq2K-fPdJZ4Jz2o=831GE_qNN6HVXKbrURA@mail.gmail.com>
	<20423.35295.846826.21182@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [xen-unstable test] 12988: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 16:10 +0100, Ian Jackson wrote:
> Ben Guthro writes ("Re: [Xen-devel] [xen-unstable test] 12988: regressions - FAIL"):
> > Fix build error, after distclean
> 
> I think in fact the right fix is probably more like this.  What do you
> think ?

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

Subject to a suitable commit message being inserted..

> 
> Ian.
> 
> diff -r e53a1d3c212c tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Wed May 30 10:57:10 2012 +0100
> +++ b/tools/libxl/Makefile	Thu May 31 16:10:11 2012 +0100
> @@ -72,7 +72,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
>  
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
>  
> -AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
> +AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
>  AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
>  LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
>  	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaV1J-0006Q2-IV; Fri, 01 Jun 2012 16:48: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 1SaV1I-0006Ps-45
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:48:12 +0000
Received: from [85.158.143.35:16183] by server-3.bemta-4.messagelabs.com id
	DB/F4-04252-B42F8CF4; Fri, 01 Jun 2012 16:48:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1338569285!17165665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10966 invoked from network); 1 Jun 2012 16:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792550"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:48:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	17:48:04 +0100
Message-ID: <1338569283.1077.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:48:03 +0100
In-Reply-To: <20423.35295.846826.21182@mariner.uk.xensource.com>
References: <osstest-12988-mainreport@xen.org>
	<1338371077.31698.29.camel@zakaz.uk.xensource.com>
	<1338371198.31698.30.camel@zakaz.uk.xensource.com>
	<20421.61199.525262.572856@mariner.uk.xensource.com>
	<CAOvdn6WziXKV0JT_ofUpFaY6aTsXVWBhdXb81SL+CgQvKL7rAg@mail.gmail.com>
	<CAOvdn6XB_aNEJBwpq2K-fPdJZ4Jz2o=831GE_qNN6HVXKbrURA@mail.gmail.com>
	<20423.35295.846826.21182@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [xen-unstable test] 12988: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-05-31 at 16:10 +0100, Ian Jackson wrote:
> Ben Guthro writes ("Re: [Xen-devel] [xen-unstable test] 12988: regressions - FAIL"):
> > Fix build error, after distclean
> 
> I think in fact the right fix is probably more like this.  What do you
> think ?

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

Subject to a suitable commit message being inserted..

> 
> Ian.
> 
> diff -r e53a1d3c212c tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Wed May 30 10:57:10 2012 +0100
> +++ b/tools/libxl/Makefile	Thu May 31 16:10:11 2012 +0100
> @@ -72,7 +72,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
>  
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
>  
> -AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
> +AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
>  AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
>  LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
>  	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:52:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaV4w-0006cH-6d; Fri, 01 Jun 2012 16:51:58 +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 1SaV4u-0006cA-Kb
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:51:56 +0000
Received: from [85.158.143.99:25836] by server-1.bemta-4.messagelabs.com id
	98/AE-27869-B23F8CF4; Fri, 01 Jun 2012 16:51:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338569514!23422983!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13459 invoked from network); 1 Jun 2012 16:51:55 -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;
	1 Jun 2012 16:51:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197214893"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 12:51:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 12:51:53 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaUzM-0008Tt-Nb;
	Fri, 01 Jun 2012 17:46:12 +0100
Message-ID: <4FC8F16F.30405@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:44:31 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<5c4b4f0c184fa3534bcb.1338466271@Solace>
	<20423.32435.342657.764548@mariner.uk.xensource.com>
In-Reply-To: <20423.32435.342657.764548@mariner.uk.xensource.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 06 of 11] libxl: introduce
	libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 15:22, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 06 of 11] libxl: introduce libxl_get_numainfo()"):
>> Make some NUMA node information available to the toolstack. Achieve
>> this by means of xc_numainfo(), which exposes memory size and amount
>> of free memory of each node, as well as the relative distances of
>> each node to all the others.
> ...
>> +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
> Is there some reason we can't just make sure we use the same value for
> this in both places ?  That would avoid the need for this:
>
>> +#define V(mem, i) (mem[i] == INVALID_NUMAINFO_ID) ? \
>> +    LIBXL_NUMAINFO_INVALID_ENTRY : mem[i]
> I appreciate that the types aren't the same.  In libxc it's an
> unsigned long.  But shouldn't they be the same ?
It looks like Dario was just following suit from the topology interface:

xen/include/syctl.h: #define INVALID_TOPOLOGY_ID  (~0U)
tools/libxl/libxl.h: #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)

It might be worth seeing who wrote those and asking that person why they 
thought it was important.  It might be something to do with making the 
libxl type a fixed size...?
> In libxl you can use libxl__zalloc(NULL,...) (and don't have to check 
> for errors because it can't fail). But perhaps this is going into 
> libxc ? I'd like to hear what other people say about putting this in 
> libxl vs. libxc.
I dunno, whom do we expect to be calling libxc?  If the answer is "One 
day, only libxl", then it's just a matter of taste.  Otherwise, we need 
to ask whether someone might want to call such a function w/o having to 
link to libxl.

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:52:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SaV4w-0006cH-6d; Fri, 01 Jun 2012 16:51:58 +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 1SaV4u-0006cA-Kb
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:51:56 +0000
Received: from [85.158.143.99:25836] by server-1.bemta-4.messagelabs.com id
	98/AE-27869-B23F8CF4; Fri, 01 Jun 2012 16:51:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338569514!23422983!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13459 invoked from network); 1 Jun 2012 16:51:55 -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;
	1 Jun 2012 16:51:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197214893"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 12:51:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 12:51:53 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaUzM-0008Tt-Nb;
	Fri, 01 Jun 2012 17:46:12 +0100
Message-ID: <4FC8F16F.30405@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:44:31 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<5c4b4f0c184fa3534bcb.1338466271@Solace>
	<20423.32435.342657.764548@mariner.uk.xensource.com>
In-Reply-To: <20423.32435.342657.764548@mariner.uk.xensource.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 06 of 11] libxl: introduce
	libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 15:22, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 06 of 11] libxl: introduce libxl_get_numainfo()"):
>> Make some NUMA node information available to the toolstack. Achieve
>> this by means of xc_numainfo(), which exposes memory size and amount
>> of free memory of each node, as well as the relative distances of
>> each node to all the others.
> ...
>> +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
> Is there some reason we can't just make sure we use the same value for
> this in both places ?  That would avoid the need for this:
>
>> +#define V(mem, i) (mem[i] == INVALID_NUMAINFO_ID) ? \
>> +    LIBXL_NUMAINFO_INVALID_ENTRY : mem[i]
> I appreciate that the types aren't the same.  In libxc it's an
> unsigned long.  But shouldn't they be the same ?
It looks like Dario was just following suit from the topology interface:

xen/include/syctl.h: #define INVALID_TOPOLOGY_ID  (~0U)
tools/libxl/libxl.h: #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)

It might be worth seeing who wrote those and asking that person why they 
thought it was important.  It might be something to do with making the 
libxl type a fixed size...?
> In libxl you can use libxl__zalloc(NULL,...) (and don't have to check 
> for errors because it can't fail). But perhaps this is going into 
> libxc ? I'd like to hear what other people say about putting this in 
> libxl vs. libxc.
I dunno, whom do we expect to be calling libxc?  If the answer is "One 
day, only libxl", then it's just a matter of taste.  Otherwise, we need 
to ask whether someone might want to call such a function w/o having to 
link to libxl.

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:58: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 1SaVAX-0006oN-Vs; Fri, 01 Jun 2012 16:57:45 +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 1SaVAX-0006oG-46
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:57:45 +0000
Received: from [193.109.254.147:48558] by server-8.bemta-14.messagelabs.com id
	5D/74-04215-884F8CF4; Fri, 01 Jun 2012 16:57:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338569862!12223511!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21099 invoked from network); 1 Jun 2012 16:57:43 -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;
	1 Jun 2012 16:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197215478"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 12:57:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 12:57:42 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaVAT-0000V3-OF;
	Fri, 01 Jun 2012 17:57:41 +0100
Message-ID: <4FC8F420.3060407@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:56:00 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<b791abe0f7b78622041e.1338466273@Solace>
	<20423.32533.912523.206821@mariner.uk.xensource.com>
In-Reply-To: <20423.32533.912523.206821@mariner.uk.xensource.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 11] xl: add more NUMA information to
	`xl info -n'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 15:24, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 08 of 11] xl: add more NUMA information to `xl info -n'"):
>> So that the user knows how much memory there is on each node and
>> how far they are from each others.
> Perhaps the json output machinery can do this for us ?  If that's
> sufficiently legible then it would be an improvement on this
> open-coded printer.
That sounds like a different patch series -- after all, the topology 
info is also "open-coded" at the moment.  I think there's enough work to 
do with the NUMA placement stuff for now. :-)

My only nit (somewhat pedantic) is that "x / (1 << n)" will come up with 
exactly the same answer as "x >> n", but with a very fast bit-shift 
rather than a very slow integer divison.  Not that it matters for this 
purpose; but it does make the expression more complicated-looking than 
it needs to me.

But other than that, I think this patch is probably good as it is.

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 16:58: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 1SaVAX-0006oN-Vs; Fri, 01 Jun 2012 16:57:45 +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 1SaVAX-0006oG-46
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:57:45 +0000
Received: from [193.109.254.147:48558] by server-8.bemta-14.messagelabs.com id
	5D/74-04215-884F8CF4; Fri, 01 Jun 2012 16:57:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338569862!12223511!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTY3NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21099 invoked from network); 1 Jun 2012 16:57:43 -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;
	1 Jun 2012 16:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330923600"; d="scan'208";a="197215478"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 12:57:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 1 Jun 2012 12:57:42 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SaVAT-0000V3-OF;
	Fri, 01 Jun 2012 17:57:41 +0100
Message-ID: <4FC8F420.3060407@eu.citrix.com>
Date: Fri, 1 Jun 2012 17:56:00 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<b791abe0f7b78622041e.1338466273@Solace>
	<20423.32533.912523.206821@mariner.uk.xensource.com>
In-Reply-To: <20423.32533.912523.206821@mariner.uk.xensource.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 11] xl: add more NUMA information to
	`xl info -n'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 15:24, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 08 of 11] xl: add more NUMA information to `xl info -n'"):
>> So that the user knows how much memory there is on each node and
>> how far they are from each others.
> Perhaps the json output machinery can do this for us ?  If that's
> sufficiently legible then it would be an improvement on this
> open-coded printer.
That sounds like a different patch series -- after all, the topology 
info is also "open-coded" at the moment.  I think there's enough work to 
do with the NUMA placement stuff for now. :-)

My only nit (somewhat pedantic) is that "x / (1 << n)" will come up with 
exactly the same answer as "x >> n", but with a very fast bit-shift 
rather than a very slow integer divison.  Not that it matters for this 
purpose; but it does make the expression more complicated-looking than 
it needs to me.

But other than that, I think this patch is probably good as it is.

  -George

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 16:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaVBv-0006sE-G8; Fri, 01 Jun 2012 16:59: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 1SaVBt-0006s6-FJ
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:59:09 +0000
Received: from [85.158.138.51:9580] by server-1.bemta-3.messagelabs.com id
	49/79-06526-CD4F8CF4; Fri, 01 Jun 2012 16:59:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338569948!30356469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5240 invoked from network); 1 Jun 2012 16:59:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:58:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 17:58:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaVBE-0004HU-05; Fri, 01 Jun 2012 16:58:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaVBD-0000Gn-VF;
	Fri, 01 Jun 2012 17:58:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.62643.954672.219909@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 17:58:27 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4FC8F16F.30405@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<5c4b4f0c184fa3534bcb.1338466271@Solace>
	<20423.32435.342657.764548@mariner.uk.xensource.com>
	<4FC8F16F.30405@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 06 of 11] libxl: introduce
	libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [PATCH 06 of 11] libxl: introduce libxl_get_numainfo()"):
> I dunno, whom do we expect to be calling libxc?  If the answer is "One 
> day, only libxl", then it's just a matter of taste.  Otherwise, we need 
> to ask whether someone might want to call such a function w/o having to 
> link to libxl.

Perhaps the right thing is to cross that bridge when we come to 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 Jun 01 16:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaVBv-0006sE-G8; Fri, 01 Jun 2012 16:59: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 1SaVBt-0006s6-FJ
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 16:59:09 +0000
Received: from [85.158.138.51:9580] by server-1.bemta-3.messagelabs.com id
	49/79-06526-CD4F8CF4; Fri, 01 Jun 2012 16:59:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338569948!30356469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5240 invoked from network); 1 Jun 2012 16:59:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 16:58:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 17:58:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaVBE-0004HU-05; Fri, 01 Jun 2012 16:58:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaVBD-0000Gn-VF;
	Fri, 01 Jun 2012 17:58:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.62643.954672.219909@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 17:58:27 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4FC8F16F.30405@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<5c4b4f0c184fa3534bcb.1338466271@Solace>
	<20423.32435.342657.764548@mariner.uk.xensource.com>
	<4FC8F16F.30405@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 06 of 11] libxl: introduce
	libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [PATCH 06 of 11] libxl: introduce libxl_get_numainfo()"):
> I dunno, whom do we expect to be calling libxc?  If the answer is "One 
> day, only libxl", then it's just a matter of taste.  Otherwise, we need 
> to ask whether someone might want to call such a function w/o having to 
> link to libxl.

Perhaps the right thing is to cross that bridge when we come to 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 Jun 01 17:02:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaVF9-00074T-GG; Fri, 01 Jun 2012 17:02:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaVF7-00074K-5y
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 17:02:29 +0000
Received: from [85.158.143.99:23747] by server-2.bemta-4.messagelabs.com id
	5A/09-11595-4A5F8CF4; Fri, 01 Jun 2012 17:02:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338570147!28638071!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32474 invoked from network); 1 Jun 2012 17:02:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 17:02:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 17:02:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 18:02:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaVF4-0004Lx-Ox; Fri, 01 Jun 2012 17:02:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaVF4-0000HV-Nq;
	Fri, 01 Jun 2012 18:02:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.62882.719478.562210@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 18:02:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338569283.1077.37.camel@zakaz.uk.xensource.com>
References: <osstest-12988-mainreport@xen.org>
	<1338371077.31698.29.camel@zakaz.uk.xensource.com>
	<1338371198.31698.30.camel@zakaz.uk.xensource.com>
	<20421.61199.525262.572856@mariner.uk.xensource.com>
	<CAOvdn6WziXKV0JT_ofUpFaY6aTsXVWBhdXb81SL+CgQvKL7rAg@mail.gmail.com>
	<CAOvdn6XB_aNEJBwpq2K-fPdJZ4Jz2o=831GE_qNN6HVXKbrURA@mail.gmail.com>
	<20423.35295.846826.21182@mariner.uk.xensource.com>
	<1338569283.1077.37.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>,
	Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [xen-unstable test] 12988: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 12988: regressions - FAIL"):
> On Thu, 2012-05-31 at 16:10 +0100, Ian Jackson wrote:
> > I think in fact the right fix is probably more like this.  What do you
> > think ?
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Subject to a suitable commit message being inserted..

Thanks.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1338570123 -3600
# Node ID 1e2ce970f0f29af4184d975c4f161f11938070cf
# Parent  3b4346d6002e9ffcd4a9f50b031bd2a77b16b1dd
libxl: fix Makefile race bug relating to _paths.h

_paths.h needs to be in AUTOINCS.  That arranges for it to be an
explicit dependency of all object files.  This is necessary so that it
is made before any compilation is attempted.

Making it a dependency of xl.h (as in 25426:e53a1d3c212c) is harmless,
but not sufficient because that only takes effect if there is already
an autogenerated .d file naming xl.h as a dependency of relevant
object files.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3b4346d6002e -r 1e2ce970f0f2 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Jun 01 12:06:22 2012 +0100
+++ b/tools/libxl/Makefile	Fri Jun 01 18:02:03 2012 +0100
@@ -72,7 +72,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 17:02:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaVF9-00074T-GG; Fri, 01 Jun 2012 17:02:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaVF7-00074K-5y
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 17:02:29 +0000
Received: from [85.158.143.99:23747] by server-2.bemta-4.messagelabs.com id
	5A/09-11595-4A5F8CF4; Fri, 01 Jun 2012 17:02:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338570147!28638071!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32474 invoked from network); 1 Jun 2012 17:02:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 17:02:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12792745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 17:02:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 18:02:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaVF4-0004Lx-Ox; Fri, 01 Jun 2012 17:02:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaVF4-0000HV-Nq;
	Fri, 01 Jun 2012 18:02:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20424.62882.719478.562210@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 18:02:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338569283.1077.37.camel@zakaz.uk.xensource.com>
References: <osstest-12988-mainreport@xen.org>
	<1338371077.31698.29.camel@zakaz.uk.xensource.com>
	<1338371198.31698.30.camel@zakaz.uk.xensource.com>
	<20421.61199.525262.572856@mariner.uk.xensource.com>
	<CAOvdn6WziXKV0JT_ofUpFaY6aTsXVWBhdXb81SL+CgQvKL7rAg@mail.gmail.com>
	<CAOvdn6XB_aNEJBwpq2K-fPdJZ4Jz2o=831GE_qNN6HVXKbrURA@mail.gmail.com>
	<20423.35295.846826.21182@mariner.uk.xensource.com>
	<1338569283.1077.37.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>,
	Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [xen-unstable test] 12988: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 12988: regressions - FAIL"):
> On Thu, 2012-05-31 at 16:10 +0100, Ian Jackson wrote:
> > I think in fact the right fix is probably more like this.  What do you
> > think ?
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Subject to a suitable commit message being inserted..

Thanks.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1338570123 -3600
# Node ID 1e2ce970f0f29af4184d975c4f161f11938070cf
# Parent  3b4346d6002e9ffcd4a9f50b031bd2a77b16b1dd
libxl: fix Makefile race bug relating to _paths.h

_paths.h needs to be in AUTOINCS.  That arranges for it to be an
explicit dependency of all object files.  This is necessary so that it
is made before any compilation is attempted.

Making it a dependency of xl.h (as in 25426:e53a1d3c212c) is harmless,
but not sufficient because that only takes effect if there is already
an autogenerated .d file naming xl.h as a dependency of relevant
object files.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3b4346d6002e -r 1e2ce970f0f2 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Jun 01 12:06:22 2012 +0100
+++ b/tools/libxl/Makefile	Fri Jun 01 18:02:03 2012 +0100
@@ -72,7 +72,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 17:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 17: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 1SaVHr-0007Gm-Av; Fri, 01 Jun 2012 17:05: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 1SaVHq-0007Gd-2E
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 17:05:18 +0000
Received: from [85.158.143.99:35799] by server-1.bemta-4.messagelabs.com id
	52/8B-27869-D46F8CF4; Fri, 01 Jun 2012 17:05:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338570315!30943445!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5391 invoked from network); 1 Jun 2012 17:05:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 17:05:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaVHm-000Ltg-3l; Fri, 01 Jun 2012 17:05:14 +0000
Date: Fri, 1 Jun 2012 18:05:14 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120601170514.GD77921@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
	paging 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

At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> With enough warnings enabled the model seemed to be complaining that pages
> cached before paging was enabled had been mapped with to inconsistent sets of
> attributes. I'm not convinced that isn't a model issue, nor am I convinced
> this has really fixed anything, but it seems sensible enough.

This might be what breaks secondary CPU bringup: pagetables built by CPU
0 may not have been flushed all the way to RAM when CPU 1 comes up, and
CPU 1 isn't participating in cache coherence protocols when it
starts to need them.

OTOH, if that's the case, it's surprising that CPU 1 passes the boot
gate.  I'll look into it next week, x86/mm workload permitting. 

Cheers,

Tim.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/head.S |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 9a7714a..71197af 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -148,10 +148,11 @@ hyp:
>  	 * Exceptions in LE ARM,
>  	 * Low-latency IRQs disabled,
>  	 * Write-implies-XN disabled (for now),
> -	 * I-cache and d-cache enabled,
> +	 * D-cache diabled (for now),
> +	 * I-cache enabled,
>  	 * Alignment checking enabled,
>  	 * MMU translation disabled (for now). */
> -	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
> +	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
>  	mcr   CP32(r0, HSCTLR)
>  
>  	/* Write Xen's PT's paddr into the HTTBR */
> @@ -217,6 +218,10 @@ pt_ready:
>  	mov   pc, r1                 /* Get a proper vaddr into PC */
>  paging:
>  
> +	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
> +	orr   r0, r0, #(SCTLR_C)
> +	mcr   CP32(r0, HSCTLR)
> +
>  #ifdef EARLY_UART_ADDRESS
>  	/* Recover the UART address in the new address space. */
>  	lsl   r11, #11
> -- 
> 1.7.9.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 Fri Jun 01 17:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 17: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 1SaVHr-0007Gm-Av; Fri, 01 Jun 2012 17:05: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 1SaVHq-0007Gd-2E
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 17:05:18 +0000
Received: from [85.158.143.99:35799] by server-1.bemta-4.messagelabs.com id
	52/8B-27869-D46F8CF4; Fri, 01 Jun 2012 17:05:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338570315!30943445!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5391 invoked from network); 1 Jun 2012 17:05:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Jun 2012 17:05:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SaVHm-000Ltg-3l; Fri, 01 Jun 2012 17:05:14 +0000
Date: Fri, 1 Jun 2012 18:05:14 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120601170514.GD77921@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
	paging 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

At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> With enough warnings enabled the model seemed to be complaining that pages
> cached before paging was enabled had been mapped with to inconsistent sets of
> attributes. I'm not convinced that isn't a model issue, nor am I convinced
> this has really fixed anything, but it seems sensible enough.

This might be what breaks secondary CPU bringup: pagetables built by CPU
0 may not have been flushed all the way to RAM when CPU 1 comes up, and
CPU 1 isn't participating in cache coherence protocols when it
starts to need them.

OTOH, if that's the case, it's surprising that CPU 1 passes the boot
gate.  I'll look into it next week, x86/mm workload permitting. 

Cheers,

Tim.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/head.S |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 9a7714a..71197af 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -148,10 +148,11 @@ hyp:
>  	 * Exceptions in LE ARM,
>  	 * Low-latency IRQs disabled,
>  	 * Write-implies-XN disabled (for now),
> -	 * I-cache and d-cache enabled,
> +	 * D-cache diabled (for now),
> +	 * I-cache enabled,
>  	 * Alignment checking enabled,
>  	 * MMU translation disabled (for now). */
> -	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
> +	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
>  	mcr   CP32(r0, HSCTLR)
>  
>  	/* Write Xen's PT's paddr into the HTTBR */
> @@ -217,6 +218,10 @@ pt_ready:
>  	mov   pc, r1                 /* Get a proper vaddr into PC */
>  paging:
>  
> +	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
> +	orr   r0, r0, #(SCTLR_C)
> +	mcr   CP32(r0, HSCTLR)
> +
>  #ifdef EARLY_UART_ADDRESS
>  	/* Recover the UART address in the new address space. */
>  	lsl   r11, #11
> -- 
> 1.7.9.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 Fri Jun 01 17:49:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 17:49: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 1SaVxr-0008A8-UV; Fri, 01 Jun 2012 17:48: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 1SaVxq-0008A3-92
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 17:48:42 +0000
Received: from [85.158.143.35:45302] by server-2.bemta-4.messagelabs.com id
	53/04-11595-97009CF4; Fri, 01 Jun 2012 17:48:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338572918!8003191!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzUwMzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzUwMzE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25273 invoked from network); 1 Jun 2012 17:48:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 17:48:39 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo50) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z053c1o51H7JHX
	for <xen-devel@lists.xensource.com>;
	Fri, 1 Jun 2012 19:48:38 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0B15118637
	for <xen-devel@lists.xensource.com>;
	Fri,  1 Jun 2012 19:48:36 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 3da83ff08d6b6431c104a431d6617ccb5977643b
Message-Id: <3da83ff08d6b6431c104.1338572903@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 01 Jun 2012 19:48:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1338572607 -7200
# Node ID 3da83ff08d6b6431c104a431d6617ccb5977643b
# Parent  fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
xl.cfg: document the cpuid= option

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

diff -r fde8ad0252ee -r 3da83ff08d6b docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -969,9 +969,47 @@ XXX
 
 XXX
 
-=item B<cpuid=XXX>
+=item B<cpuid="STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
 
-XXX
+Configure guest CPUID responses. Two config versions of config syntax are
+recognized: xend and libxl.
+
+The xend syntax is a list of values in the form of
+'leafnum:register=bitstring,register=bitstring':
+ "leafnum" is the requested function,
+ "register" is the response register to modify
+ "bitstring" represents a bit in the register, its length must be exactly 32 chars.
+  Each successive character represent a lesser-significant bit:
+   '1' -> force the corresponding bit to 1
+   '0' -> force to 0
+   'x' -> Get a safe value (pass through and mask with the default policy)
+   'k' -> pass through the host bit value
+   's' -> as 'k' but preserve across save/restore and migration (not implemented)
+
+The libxl syntax is a comma separated list of key=value pairs, preceded by the
+word "host". Some keys take a numerical value, all others take a single
+character just as in the "bitstring" list above.
+
+List of keys taking a value:
+apicidsize brandid clflush family localapicid maxleaf model nc proccount procpkg
+stepping
+
+List of keys taking a character:
+3dnow 3dnowext 3dnowprefetch abm acpi aes altmovcr8 apic avx clfsh cmov
+cmplegacy cmpxchg16 cmpxchg8 cntxid dca de ds dscpl dtes64 est extapic f16c
+ffxsr fma4 fpu fxsr htt hypervisor ia64 ibs lahfsahf lm lwp mca mce misalignsse
+mmx mmxext monitor movbe msr mtrr nodeid nx osvw osxsave pae page1gb pat pbe
+pclmulqdq pdcm pge popcnt pse pse36 psn rdtscp skinit smx ss sse sse2 sse3
+sse4.1 sse4.2 sse4a ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips
+svm_pausefilt svm_tscrate svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc
+vme vmx wdt x2apic xop xsave xtpr
+
+Example to hide two features from the guest: 'tm', which is bit #29 in EDX, and
+'pni' (SSE3), which is bit #0 in ECX:
+
+xend: [ '1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0,edx=xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' ]
+
+libxl: 'host,tm=0,sse3=0'
 
 =item B<acpi_s3=BOOLEAN>
 

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 17:49:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 17:49: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 1SaVxr-0008A8-UV; Fri, 01 Jun 2012 17:48: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 1SaVxq-0008A3-92
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 17:48:42 +0000
Received: from [85.158.143.35:45302] by server-2.bemta-4.messagelabs.com id
	53/04-11595-97009CF4; Fri, 01 Jun 2012 17:48:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338572918!8003191!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzUwMzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzUwMzE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25273 invoked from network); 1 Jun 2012 17:48:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 17:48:39 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo50) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z053c1o51H7JHX
	for <xen-devel@lists.xensource.com>;
	Fri, 1 Jun 2012 19:48:38 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0B15118637
	for <xen-devel@lists.xensource.com>;
	Fri,  1 Jun 2012 19:48:36 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 3da83ff08d6b6431c104a431d6617ccb5977643b
Message-Id: <3da83ff08d6b6431c104.1338572903@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 01 Jun 2012 19:48:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1338572607 -7200
# Node ID 3da83ff08d6b6431c104a431d6617ccb5977643b
# Parent  fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
xl.cfg: document the cpuid= option

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

diff -r fde8ad0252ee -r 3da83ff08d6b docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -969,9 +969,47 @@ XXX
 
 XXX
 
-=item B<cpuid=XXX>
+=item B<cpuid="STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
 
-XXX
+Configure guest CPUID responses. Two config versions of config syntax are
+recognized: xend and libxl.
+
+The xend syntax is a list of values in the form of
+'leafnum:register=bitstring,register=bitstring':
+ "leafnum" is the requested function,
+ "register" is the response register to modify
+ "bitstring" represents a bit in the register, its length must be exactly 32 chars.
+  Each successive character represent a lesser-significant bit:
+   '1' -> force the corresponding bit to 1
+   '0' -> force to 0
+   'x' -> Get a safe value (pass through and mask with the default policy)
+   'k' -> pass through the host bit value
+   's' -> as 'k' but preserve across save/restore and migration (not implemented)
+
+The libxl syntax is a comma separated list of key=value pairs, preceded by the
+word "host". Some keys take a numerical value, all others take a single
+character just as in the "bitstring" list above.
+
+List of keys taking a value:
+apicidsize brandid clflush family localapicid maxleaf model nc proccount procpkg
+stepping
+
+List of keys taking a character:
+3dnow 3dnowext 3dnowprefetch abm acpi aes altmovcr8 apic avx clfsh cmov
+cmplegacy cmpxchg16 cmpxchg8 cntxid dca de ds dscpl dtes64 est extapic f16c
+ffxsr fma4 fpu fxsr htt hypervisor ia64 ibs lahfsahf lm lwp mca mce misalignsse
+mmx mmxext monitor movbe msr mtrr nodeid nx osvw osxsave pae page1gb pat pbe
+pclmulqdq pdcm pge popcnt pse pse36 psn rdtscp skinit smx ss sse sse2 sse3
+sse4.1 sse4.2 sse4a ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips
+svm_pausefilt svm_tscrate svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc
+vme vmx wdt x2apic xop xsave xtpr
+
+Example to hide two features from the guest: 'tm', which is bit #29 in EDX, and
+'pni' (SSE3), which is bit #0 in ECX:
+
+xend: [ '1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0,edx=xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' ]
+
+libxl: 'host,tm=0,sse3=0'
 
 =item B<acpi_s3=BOOLEAN>
 

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 17:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 17: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 1SaW3X-0008KI-V4; Fri, 01 Jun 2012 17:54:35 +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 1SaW3W-0008Jx-LW
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 17:54:34 +0000
Received: from [193.109.254.147:18153] by server-9.bemta-14.messagelabs.com id
	71/86-28098-9D109CF4; Fri, 01 Jun 2012 17:54:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338573273!4734467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28101 invoked from network); 1 Jun 2012 17:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 17:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 17:54:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 18:54:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaW3U-00054o-NT; Fri, 01 Jun 2012 17:54:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaW3U-0000L7-Le;
	Fri, 01 Jun 2012 18:54:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.472.655564.805506@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 18:54:32 +0100
To: lars.kurth@xen.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
References: <m2n.s.1SaP2B-131944@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-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("[Xen-devel] Proposals/changes for a new Wiki Front-Page - need input/mods/creative proposals"):
> - http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case focussed
> front-page

This one is already much better than the existing front page.  I have
made some more changes.

The links under "Xen Docs" are rather poor.  I don't know what pages
we have that would do better, but the top link being the Wiki category
listing is quite unhelpful.

Ian.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 17:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 17: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 1SaW3X-0008KI-V4; Fri, 01 Jun 2012 17:54:35 +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 1SaW3W-0008Jx-LW
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 17:54:34 +0000
Received: from [193.109.254.147:18153] by server-9.bemta-14.messagelabs.com id
	71/86-28098-9D109CF4; Fri, 01 Jun 2012 17:54:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338573273!4734467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28101 invoked from network); 1 Jun 2012 17:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 17:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 17:54:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 18:54:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaW3U-00054o-NT; Fri, 01 Jun 2012 17:54:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaW3U-0000L7-Le;
	Fri, 01 Jun 2012 18:54:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.472.655564.805506@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 18:54:32 +0100
To: lars.kurth@xen.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
References: <m2n.s.1SaP2B-131944@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-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lars Kurth writes ("[Xen-devel] Proposals/changes for a new Wiki Front-Page - need input/mods/creative proposals"):
> - http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case focussed
> front-page

This one is already much better than the existing front page.  I have
made some more changes.

The links under "Xen Docs" are rather poor.  I don't know what pages
we have that would do better, but the top link being the Wiki category
listing is quite unhelpful.

Ian.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 18:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaW9t-0000NE-Rg; Fri, 01 Jun 2012 18:01:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaW9s-0000N7-US
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:01:09 +0000
Received: from [85.158.143.35:61504] by server-1.bemta-4.messagelabs.com id
	0A/4D-27869-46309CF4; Fri, 01 Jun 2012 18:01:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1338573666!14042108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21970 invoked from network); 1 Jun 2012 18:01:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:01:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 19:01:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaW9p-000570-KV; Fri, 01 Jun 2012 18:01:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaW9o-0007Pg-CB;
	Fri, 01 Jun 2012 19:01:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.863.785362.721748@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 19:01:03 +0100
To: "W. Michael Petullo" <mike@flyn.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120531045040.GA16124@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.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] Using "xl create" without domain 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

W. Michael Petullo writes ("[Xen-devel] Using "xl create" without domain config file"):
> I found it useful to use xm without a domain configuration file:
> 
> 	xm create /dev/null kernel=...
> 
> The xl command does not support this. See a previous thread I started:
> 
> 	http://lists.xen.org/archives/html/xen-devel/2011-08/msg00330.html

I would be happy to support the /dev/null form.

> I just found the time to modify xl so that it works without a domain
> configuration file. For example:
> 
> 	xl create kernel=\"...\" ...

This, however, is ambiguous.  It's not clear from your patch below how
this ambiguity is resolved but I don't think what you've done can be
sufficient in itself.

What if the domain config filename contains a `=' ?

Ian.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 18:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaW9t-0000NE-Rg; Fri, 01 Jun 2012 18:01:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaW9s-0000N7-US
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:01:09 +0000
Received: from [85.158.143.35:61504] by server-1.bemta-4.messagelabs.com id
	0A/4D-27869-46309CF4; Fri, 01 Jun 2012 18:01:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1338573666!14042108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21970 invoked from network); 1 Jun 2012 18:01:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:01:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 19:01:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaW9p-000570-KV; Fri, 01 Jun 2012 18:01:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaW9o-0007Pg-CB;
	Fri, 01 Jun 2012 19:01:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.863.785362.721748@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 19:01:03 +0100
To: "W. Michael Petullo" <mike@flyn.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120531045040.GA16124@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.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] Using "xl create" without domain 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

W. Michael Petullo writes ("[Xen-devel] Using "xl create" without domain config file"):
> I found it useful to use xm without a domain configuration file:
> 
> 	xm create /dev/null kernel=...
> 
> The xl command does not support this. See a previous thread I started:
> 
> 	http://lists.xen.org/archives/html/xen-devel/2011-08/msg00330.html

I would be happy to support the /dev/null form.

> I just found the time to modify xl so that it works without a domain
> configuration file. For example:
> 
> 	xl create kernel=\"...\" ...

This, however, is ambiguous.  It's not clear from your patch below how
this ambiguity is resolved but I don't think what you've done can be
sufficient in itself.

What if the domain config filename contains a `=' ?

Ian.

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 18:05:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 18: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 1SaWE0-0000gy-Hx; Fri, 01 Jun 2012 18:05: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 1SaWDy-0000gr-T1
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:05:23 +0000
Received: from [85.158.138.51:57173] by server-6.bemta-3.messagelabs.com id
	8A/AE-23455-16409CF4; Fri, 01 Jun 2012 18:05:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1338573920!30452363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31045 invoked from network); 1 Jun 2012 18:05:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:05:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:05:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 19:05:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaWDw-00058Y-5z; Fri, 01 Jun 2012 18:05:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaWDw-0000tz-4K;
	Fri, 01 Jun 2012 19:05:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.1120.90566.706268@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 19:05:20 +0100
To: Simon Rowe <simon.rowe@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
References: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Simon Rowe writes ("[Xen-devel] [PATCH V2] xs: set read_thread stacksize"):
> xs_watch() creates a thread to wake watchers using default attributes. The
> stacksize can be quite large (8 MB on Linux), applications that link against
> xenstore end up having a larger memory footprint than necessary.

Thanks.  This seems like a genuine bug but I have one comments about
your fix.  The effect of your patch is to make the stacksize of the
libxenstore private thread be small.

However, we do not take any care to avoid signals being delivered to
this thread.  This is bad enough at the moment, but with your patch
these signals may now be delivered to a thread with a small stack.

Can I request that you provide another patch too, which would probably
come before this one, which uses pthread_sigprocmask to block all
signals on the private thread ?  This is done by changing the signal
mask to all signals blocked and then restoring it afterwards.

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 Jun 01 18:05:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 18: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 1SaWE0-0000gy-Hx; Fri, 01 Jun 2012 18:05: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 1SaWDy-0000gr-T1
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:05:23 +0000
Received: from [85.158.138.51:57173] by server-6.bemta-3.messagelabs.com id
	8A/AE-23455-16409CF4; Fri, 01 Jun 2012 18:05:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1338573920!30452363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31045 invoked from network); 1 Jun 2012 18:05:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:05:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:05:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 19:05:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaWDw-00058Y-5z; Fri, 01 Jun 2012 18:05:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaWDw-0000tz-4K;
	Fri, 01 Jun 2012 19:05:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.1120.90566.706268@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 19:05:20 +0100
To: Simon Rowe <simon.rowe@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
References: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Simon Rowe writes ("[Xen-devel] [PATCH V2] xs: set read_thread stacksize"):
> xs_watch() creates a thread to wake watchers using default attributes. The
> stacksize can be quite large (8 MB on Linux), applications that link against
> xenstore end up having a larger memory footprint than necessary.

Thanks.  This seems like a genuine bug but I have one comments about
your fix.  The effect of your patch is to make the stacksize of the
libxenstore private thread be small.

However, we do not take any care to avoid signals being delivered to
this thread.  This is bad enough at the moment, but with your patch
these signals may now be delivered to a thread with a small stack.

Can I request that you provide another patch too, which would probably
come before this one, which uses pthread_sigprocmask to block all
signals on the private thread ?  This is done by changing the signal
mask to all signals blocked and then restoring it afterwards.

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 Jun 01 18:08:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 18: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 1SaWH0-0000vD-5L; Fri, 01 Jun 2012 18:08:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaWGy-0000v3-7w
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:08:28 +0000
Received: from [193.109.254.147:33058] by server-5.bemta-14.messagelabs.com id
	F5/A9-06171-B1509CF4; Fri, 01 Jun 2012 18:08:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338574100!7271654!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8604 invoked from network); 1 Jun 2012 18:08:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:08:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 19:08:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaWGp-00059U-B2; Fri, 01 Jun 2012 18:08:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaWGp-0000uW-6v;
	Fri, 01 Jun 2012 19:08:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.1295.7385.342986@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 19:08:15 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338548826.17466.88.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0 of 5 V2] libxl: make it possible to explicitly specify default sched params"):
> On Tue, 2012-05-29 at 14:56 +0100, Ian Campbell wrote:
> > This series defines a descriminating value for each scheduler paramter
> > and uses it to fix a warning when starting a guest:
> >   "Cpu weight out of range, valid values are within range from 1 to 65535"
> 
> I applied this with George and Ian J's acks.

It seems to have produced a build failure in the ocaml bindings.  See
below.

Ian.

make[7]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
 MLC      xenlight.cmo
 MLA      xenlight.cma
 CC       xenlight_stubs.o
xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_get':
xenlight_stubs.c:503: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
xenlight_stubs.c:503: error: (Each undeclared identifier is reported only once
xenlight_stubs.c:503: error: for each function it appears in.)
xenlight_stubs.c:503: error: expected ';' before 'c_scinfo'
cc1: warnings being treated as errors
xenlight_stubs.c:504: error: ISO C90 forbids mixed declarations and code
xenlight_stubs.c:508: error: implicit declaration of function 'libxl_sched_credit_domain_get'
xenlight_stubs.c:508: error: 'c_scinfo' undeclared (first use in this function)
xenlight_stubs.c:513: error: implicit declaration of function 'Val_sched_credit_domain'
xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_set':
xenlight_stubs.c:520: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
xenlight_stubs.c:520: error: expected ';' before 'c_scinfo'
xenlight_stubs.c:521: error: ISO C90 forbids mixed declarations and code
xenlight_stubs.c:524: error: implicit declaration of function 'sched_credit_domain_val'
xenlight_stubs.c:524: error: 'c_scinfo' undeclared (first use in this function)
xenlight_stubs.c:527: error: implicit declaration of function 'libxl_sched_credit_domain_set'
make[7]: *** [xenlight_stubs.o] Error 1
make[7]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
make[6]: *** [subdir-install-xl] Error 2
make[6]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
make[5]: *** [subdirs-install] Error 2
make[5]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
make[4]: *** [subdir-install-libs] Error 2
make[4]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
make[3]: *** [subdirs-install] Error 2
make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
make[2]: *** [subdir-install-ocaml] Error 2
make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make: *** [install-tools] Error 2

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 18:08:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 18: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 1SaWH0-0000vD-5L; Fri, 01 Jun 2012 18:08:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaWGy-0000v3-7w
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:08:28 +0000
Received: from [193.109.254.147:33058] by server-5.bemta-14.messagelabs.com id
	F5/A9-06171-B1509CF4; Fri, 01 Jun 2012 18:08:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338574100!7271654!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8604 invoked from network); 1 Jun 2012 18:08:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:08:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 19:08:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SaWGp-00059U-B2; Fri, 01 Jun 2012 18:08:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SaWGp-0000uW-6v;
	Fri, 01 Jun 2012 19:08:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20425.1295.7385.342986@mariner.uk.xensource.com>
Date: Fri, 1 Jun 2012 19:08:15 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338548826.17466.88.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0 of 5 V2] libxl: make it possible to explicitly specify default sched params"):
> On Tue, 2012-05-29 at 14:56 +0100, Ian Campbell wrote:
> > This series defines a descriminating value for each scheduler paramter
> > and uses it to fix a warning when starting a guest:
> >   "Cpu weight out of range, valid values are within range from 1 to 65535"
> 
> I applied this with George and Ian J's acks.

It seems to have produced a build failure in the ocaml bindings.  See
below.

Ian.

make[7]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
 MLC      xenlight.cmo
 MLA      xenlight.cma
 CC       xenlight_stubs.o
xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_get':
xenlight_stubs.c:503: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
xenlight_stubs.c:503: error: (Each undeclared identifier is reported only once
xenlight_stubs.c:503: error: for each function it appears in.)
xenlight_stubs.c:503: error: expected ';' before 'c_scinfo'
cc1: warnings being treated as errors
xenlight_stubs.c:504: error: ISO C90 forbids mixed declarations and code
xenlight_stubs.c:508: error: implicit declaration of function 'libxl_sched_credit_domain_get'
xenlight_stubs.c:508: error: 'c_scinfo' undeclared (first use in this function)
xenlight_stubs.c:513: error: implicit declaration of function 'Val_sched_credit_domain'
xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_set':
xenlight_stubs.c:520: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
xenlight_stubs.c:520: error: expected ';' before 'c_scinfo'
xenlight_stubs.c:521: error: ISO C90 forbids mixed declarations and code
xenlight_stubs.c:524: error: implicit declaration of function 'sched_credit_domain_val'
xenlight_stubs.c:524: error: 'c_scinfo' undeclared (first use in this function)
xenlight_stubs.c:527: error: implicit declaration of function 'libxl_sched_credit_domain_set'
make[7]: *** [xenlight_stubs.o] Error 1
make[7]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
make[6]: *** [subdir-install-xl] Error 2
make[6]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
make[5]: *** [subdirs-install] Error 2
make[5]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
make[4]: *** [subdir-install-libs] Error 2
make[4]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
make[3]: *** [subdirs-install] Error 2
make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
make[2]: *** [subdir-install-ocaml] Error 2
make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make: *** [install-tools] Error 2

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

From xen-devel-bounces@lists.xen.org Fri Jun 01 18:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaWUC-0001Ed-Nn; Fri, 01 Jun 2012 18:22:08 +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 1SaWUB-0001EY-5Y
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 18:22:07 +0000
Received: from [85.158.139.83:17632] by server-10.bemta-5.messagelabs.com id
	3C/E0-23803-E4809CF4; Fri, 01 Jun 2012 18:22:06 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1338574923!27364485!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20944 invoked from network); 1 Jun 2012 18:22:05 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:22:05 -0000
Received: by dajz8 with SMTP id z8so3571833daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Jun 2012 11:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6Pb0bl2dqM5DeKI6vn+WVcJInOTa0pc6w38AIOQ4OSQ=;
	b=K49gmrYbbmK3j6CGY8DyHUHkZyJUVUBAWoHYS2TF5e28M92o8wd+pvRwBp6FWW6M6O
	cKedyEfvdAqjlKMNA20MdOK6f6PvyicVcyDvCTMkvySuWbCxXHkaG2y0Kd27Hn5c2uZO
	yf4mgKne2j+s0lLAFiAWSQt1wcE3wed79TpXf9UL6PUsUxyoJDFwD0Z256vxzDc8GBeq
	Z35x/wxd1S8lXnbmXQel2c3Im8KHtxjyCMzgw2RAhW4Xa/TW+C78Qbw0coQmgB5CjUy9
	w8d1m8+rzscW4MFasdio5+5FOKYHqScoahSjqSpuLd9tc+JDh+zN5IT2UD+lqZfdmZ5w
	nztg==
MIME-Version: 1.0
Received: by 10.68.216.2 with SMTP id om2mr9819884pbc.26.1338574923414; Fri,
	01 Jun 2012 11:22:03 -0700 (PDT)
Received: by 10.143.164.12 with HTTP; Fri, 1 Jun 2012 11:22:03 -0700 (PDT)
In-Reply-To: <1338562358-28182-3-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-3-git-send-email-bp@amd64.org>
Date: Fri, 1 Jun 2012 11:22:03 -0700
X-Google-Sender-Auth: ZBURQ1DsHC01THpXl3G8nu2xPgI
Message-ID: <CAE9FiQVad9qWvZeBej31Mw4aEJO3L0L6ZC7mx7VJQwRB_q8fzQ@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Borislav Petkov <bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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="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, Jun 1, 2012 at 7:52 AM, Borislav Petkov <bp@amd64.org> wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
>
> There's no real reason why, when showing the MSRs on a CPU at boottime,
> we should be using the AMD-specific variant. Simply use the generic safe
> one which handles #GPs just fine.
>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
> =A0arch/x86/kernel/cpu/common.c | =A0 =A02 +-
> =A01 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 82f29e70d058..232fba2d54c9 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -947,7 +947,7 @@ static void __cpuinit __print_cpu_msr(void)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0index_max =3D msr_range_array[i].max;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (index =3D index_min; index < index_ma=
x; index++) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (rdmsrl_amd_safe(index, =
&val))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (rdmsrl_safe(index, &val=
))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_INFO " MSR%08x=
: %016llx\n", index, val);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> --

can you double check if the range will need special passcode ?



        { 0x00000000, 0x00000418},
        { 0xc0000000, 0xc000040b},
        { 0xc0010000, 0xc0010142},
        { 0xc0011000, 0xc001103b},

passcode should be
       gprs[7] =3D 0x9c5a203a;

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 Jun 01 18:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 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 1SaWUC-0001Ed-Nn; Fri, 01 Jun 2012 18:22:08 +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 1SaWUB-0001EY-5Y
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 18:22:07 +0000
Received: from [85.158.139.83:17632] by server-10.bemta-5.messagelabs.com id
	3C/E0-23803-E4809CF4; Fri, 01 Jun 2012 18:22:06 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1338574923!27364485!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20944 invoked from network); 1 Jun 2012 18:22:05 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:22:05 -0000
Received: by dajz8 with SMTP id z8so3571833daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Jun 2012 11:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6Pb0bl2dqM5DeKI6vn+WVcJInOTa0pc6w38AIOQ4OSQ=;
	b=K49gmrYbbmK3j6CGY8DyHUHkZyJUVUBAWoHYS2TF5e28M92o8wd+pvRwBp6FWW6M6O
	cKedyEfvdAqjlKMNA20MdOK6f6PvyicVcyDvCTMkvySuWbCxXHkaG2y0Kd27Hn5c2uZO
	yf4mgKne2j+s0lLAFiAWSQt1wcE3wed79TpXf9UL6PUsUxyoJDFwD0Z256vxzDc8GBeq
	Z35x/wxd1S8lXnbmXQel2c3Im8KHtxjyCMzgw2RAhW4Xa/TW+C78Qbw0coQmgB5CjUy9
	w8d1m8+rzscW4MFasdio5+5FOKYHqScoahSjqSpuLd9tc+JDh+zN5IT2UD+lqZfdmZ5w
	nztg==
MIME-Version: 1.0
Received: by 10.68.216.2 with SMTP id om2mr9819884pbc.26.1338574923414; Fri,
	01 Jun 2012 11:22:03 -0700 (PDT)
Received: by 10.143.164.12 with HTTP; Fri, 1 Jun 2012 11:22:03 -0700 (PDT)
In-Reply-To: <1338562358-28182-3-git-send-email-bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-3-git-send-email-bp@amd64.org>
Date: Fri, 1 Jun 2012 11:22:03 -0700
X-Google-Sender-Auth: ZBURQ1DsHC01THpXl3G8nu2xPgI
Message-ID: <CAE9FiQVad9qWvZeBej31Mw4aEJO3L0L6ZC7mx7VJQwRB_q8fzQ@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Borislav Petkov <bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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="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, Jun 1, 2012 at 7:52 AM, Borislav Petkov <bp@amd64.org> wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
>
> There's no real reason why, when showing the MSRs on a CPU at boottime,
> we should be using the AMD-specific variant. Simply use the generic safe
> one which handles #GPs just fine.
>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
> =A0arch/x86/kernel/cpu/common.c | =A0 =A02 +-
> =A01 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 82f29e70d058..232fba2d54c9 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -947,7 +947,7 @@ static void __cpuinit __print_cpu_msr(void)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0index_max =3D msr_range_array[i].max;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (index =3D index_min; index < index_ma=
x; index++) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (rdmsrl_amd_safe(index, =
&val))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (rdmsrl_safe(index, &val=
))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_INFO " MSR%08x=
: %016llx\n", index, val);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> --

can you double check if the range will need special passcode ?



        { 0x00000000, 0x00000418},
        { 0xc0000000, 0xc000040b},
        { 0xc0010000, 0xc0010142},
        { 0xc0011000, 0xc001103b},

passcode should be
       gprs[7] =3D 0x9c5a203a;

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 Jun 01 18:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 18: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 1SaWt8-0001iA-1p; Fri, 01 Jun 2012 18:47: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 1SaWt6-0001i5-R6
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:47:53 +0000
Received: from [85.158.143.35:58470] by server-3.bemta-4.messagelabs.com id
	85/8C-04252-85E09CF4; Fri, 01 Jun 2012 18:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338576471!16149252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12089 invoked from network); 1 Jun 2012 18:47:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:47:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:47:51 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	19:47:51 +0100
Message-ID: <1338576470.14877.58.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 19:47:50 +0100
In-Reply-To: <20425.1295.7385.342986@mariner.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 19:08 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to explicitly specify default sched params"):
> > On Tue, 2012-05-29 at 14:56 +0100, Ian Campbell wrote:
> > > This series defines a descriminating value for each scheduler paramter
> > > and uses it to fix a warning when starting a guest:
> > >   "Cpu weight out of range, valid values are within range from 1 to 65535"
> > 
> > I applied this with George and Ian J's acks.
> 
> It seems to have produced a build failure in the ocaml bindings.

Damn, sorry about that. I swear I compiled this both before sending it
and as part of the commit procedure, and I just tried built it again and
didn't see it.

However I've now done a make clean and can now repro. Patch to follow
shortly.

>   See
> below.
> 
> Ian.
> 
> make[7]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
>  MLC      xenlight.cmo
>  MLA      xenlight.cma
>  CC       xenlight_stubs.o
> xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_get':
> xenlight_stubs.c:503: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
> xenlight_stubs.c:503: error: (Each undeclared identifier is reported only once
> xenlight_stubs.c:503: error: for each function it appears in.)
> xenlight_stubs.c:503: error: expected ';' before 'c_scinfo'
> cc1: warnings being treated as errors
> xenlight_stubs.c:504: error: ISO C90 forbids mixed declarations and code
> xenlight_stubs.c:508: error: implicit declaration of function 'libxl_sched_credit_domain_get'
> xenlight_stubs.c:508: error: 'c_scinfo' undeclared (first use in this function)
> xenlight_stubs.c:513: error: implicit declaration of function 'Val_sched_credit_domain'
> xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_set':
> xenlight_stubs.c:520: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
> xenlight_stubs.c:520: error: expected ';' before 'c_scinfo'
> xenlight_stubs.c:521: error: ISO C90 forbids mixed declarations and code
> xenlight_stubs.c:524: error: implicit declaration of function 'sched_credit_domain_val'
> xenlight_stubs.c:524: error: 'c_scinfo' undeclared (first use in this function)
> xenlight_stubs.c:527: error: implicit declaration of function 'libxl_sched_credit_domain_set'
> make[7]: *** [xenlight_stubs.o] Error 1
> make[7]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
> make[6]: *** [subdir-install-xl] Error 2
> make[6]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
> make[5]: *** [subdirs-install] Error 2
> make[5]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
> make[4]: *** [subdir-install-libs] Error 2
> make[4]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
> make[2]: *** [subdir-install-ocaml] Error 2
> make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make: *** [install-tools] Error 2



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 18:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 18: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 1SaWt8-0001iA-1p; Fri, 01 Jun 2012 18:47: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 1SaWt6-0001i5-R6
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 18:47:53 +0000
Received: from [85.158.143.35:58470] by server-3.bemta-4.messagelabs.com id
	85/8C-04252-85E09CF4; Fri, 01 Jun 2012 18:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338576471!16149252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12089 invoked from network); 1 Jun 2012 18:47:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 18:47:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 18:47:51 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	19:47:51 +0100
Message-ID: <1338576470.14877.58.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 19:47:50 +0100
In-Reply-To: <20425.1295.7385.342986@mariner.uk.xensource.com>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 19:08 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to explicitly specify default sched params"):
> > On Tue, 2012-05-29 at 14:56 +0100, Ian Campbell wrote:
> > > This series defines a descriminating value for each scheduler paramter
> > > and uses it to fix a warning when starting a guest:
> > >   "Cpu weight out of range, valid values are within range from 1 to 65535"
> > 
> > I applied this with George and Ian J's acks.
> 
> It seems to have produced a build failure in the ocaml bindings.

Damn, sorry about that. I swear I compiled this both before sending it
and as part of the commit procedure, and I just tried built it again and
didn't see it.

However I've now done a make clean and can now repro. Patch to follow
shortly.

>   See
> below.
> 
> Ian.
> 
> make[7]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
>  MLC      xenlight.cmo
>  MLA      xenlight.cma
>  CC       xenlight_stubs.o
> xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_get':
> xenlight_stubs.c:503: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
> xenlight_stubs.c:503: error: (Each undeclared identifier is reported only once
> xenlight_stubs.c:503: error: for each function it appears in.)
> xenlight_stubs.c:503: error: expected ';' before 'c_scinfo'
> cc1: warnings being treated as errors
> xenlight_stubs.c:504: error: ISO C90 forbids mixed declarations and code
> xenlight_stubs.c:508: error: implicit declaration of function 'libxl_sched_credit_domain_get'
> xenlight_stubs.c:508: error: 'c_scinfo' undeclared (first use in this function)
> xenlight_stubs.c:513: error: implicit declaration of function 'Val_sched_credit_domain'
> xenlight_stubs.c: In function 'stub_xl_sched_credit_domain_set':
> xenlight_stubs.c:520: error: 'libxl_sched_credit_domain' undeclared (first use in this function)
> xenlight_stubs.c:520: error: expected ';' before 'c_scinfo'
> xenlight_stubs.c:521: error: ISO C90 forbids mixed declarations and code
> xenlight_stubs.c:524: error: implicit declaration of function 'sched_credit_domain_val'
> xenlight_stubs.c:524: error: 'c_scinfo' undeclared (first use in this function)
> xenlight_stubs.c:527: error: implicit declaration of function 'libxl_sched_credit_domain_set'
> make[7]: *** [xenlight_stubs.o] Error 1
> make[7]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs/xl'
> make[6]: *** [subdir-install-xl] Error 2
> make[6]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
> make[5]: *** [subdirs-install] Error 2
> make[5]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml/libs'
> make[4]: *** [subdir-install-libs] Error 2
> make[4]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/ocaml'
> make[2]: *** [subdir-install-ocaml] Error 2
> make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make: *** [install-tools] Error 2



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 19:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 19: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 1SaX9N-0002CN-O6; Fri, 01 Jun 2012 19:04:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaX9M-0002CI-3u
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 19:04:40 +0000
Received: from [85.158.139.83:63656] by server-12.bemta-5.messagelabs.com id
	4C/D2-18374-74219CF4; Fri, 01 Jun 2012 19:04:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338577478!31094563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24540 invoked from network); 1 Jun 2012 19:04:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 19:04:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 19:04:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	20:04:22 +0100
Message-ID: <1338577461.14877.61.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 20:04:21 +0100
In-Reply-To: <20120601170514.GD77921@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
	<20120601170514.GD77921@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
 paging 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 Fri, 2012-06-01 at 18:05 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> > With enough warnings enabled the model seemed to be complaining that pages
> > cached before paging was enabled had been mapped with to inconsistent sets of
> > attributes. I'm not convinced that isn't a model issue, nor am I convinced
> > this has really fixed anything, but it seems sensible enough.
> 
> This might be what breaks secondary CPU bringup: pagetables built by CPU
> 0 may not have been flushed all the way to RAM when CPU 1 comes up, and
> CPU 1 isn't participating in cache coherence protocols when it
> starts to need them.

The issue here is the lack of the necessary flush, rather than this
change particularly, right?

> OTOH, if that's the case, it's surprising that CPU 1 passes the boot
> gate.  I'll look into it next week, x86/mm workload permitting. 

Sounds good!

I tried to test SMP yesterday but ut turned out all the models I thought
were SMP enabled were actual UP Only, not sure how/when that happened!

Cheers,
Ian.

> 
> Cheers,
> 
> Tim.
> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/head.S |    9 +++++++--
> >  1 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index 9a7714a..71197af 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -148,10 +148,11 @@ hyp:
> >  	 * Exceptions in LE ARM,
> >  	 * Low-latency IRQs disabled,
> >  	 * Write-implies-XN disabled (for now),
> > -	 * I-cache and d-cache enabled,
> > +	 * D-cache diabled (for now),
> > +	 * I-cache enabled,
> >  	 * Alignment checking enabled,
> >  	 * MMU translation disabled (for now). */
> > -	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
> > +	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
> >  	mcr   CP32(r0, HSCTLR)
> >  
> >  	/* Write Xen's PT's paddr into the HTTBR */
> > @@ -217,6 +218,10 @@ pt_ready:
> >  	mov   pc, r1                 /* Get a proper vaddr into PC */
> >  paging:
> >  
> > +	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
> > +	orr   r0, r0, #(SCTLR_C)
> > +	mcr   CP32(r0, HSCTLR)
> > +
> >  #ifdef EARLY_UART_ADDRESS
> >  	/* Recover the UART address in the new address space. */
> >  	lsl   r11, #11
> > -- 
> > 1.7.9.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 Fri Jun 01 19:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 19: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 1SaX9N-0002CN-O6; Fri, 01 Jun 2012 19:04:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SaX9M-0002CI-3u
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 19:04:40 +0000
Received: from [85.158.139.83:63656] by server-12.bemta-5.messagelabs.com id
	4C/D2-18374-74219CF4; Fri, 01 Jun 2012 19:04:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338577478!31094563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24540 invoked from network); 1 Jun 2012 19:04:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 19:04:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12793966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 19:04:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	20:04:22 +0100
Message-ID: <1338577461.14877.61.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 1 Jun 2012 20:04:21 +0100
In-Reply-To: <20120601170514.GD77921@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
	<20120601170514.GD77921@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
 paging 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 Fri, 2012-06-01 at 18:05 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> > With enough warnings enabled the model seemed to be complaining that pages
> > cached before paging was enabled had been mapped with to inconsistent sets of
> > attributes. I'm not convinced that isn't a model issue, nor am I convinced
> > this has really fixed anything, but it seems sensible enough.
> 
> This might be what breaks secondary CPU bringup: pagetables built by CPU
> 0 may not have been flushed all the way to RAM when CPU 1 comes up, and
> CPU 1 isn't participating in cache coherence protocols when it
> starts to need them.

The issue here is the lack of the necessary flush, rather than this
change particularly, right?

> OTOH, if that's the case, it's surprising that CPU 1 passes the boot
> gate.  I'll look into it next week, x86/mm workload permitting. 

Sounds good!

I tried to test SMP yesterday but ut turned out all the models I thought
were SMP enabled were actual UP Only, not sure how/when that happened!

Cheers,
Ian.

> 
> Cheers,
> 
> Tim.
> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/head.S |    9 +++++++--
> >  1 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index 9a7714a..71197af 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -148,10 +148,11 @@ hyp:
> >  	 * Exceptions in LE ARM,
> >  	 * Low-latency IRQs disabled,
> >  	 * Write-implies-XN disabled (for now),
> > -	 * I-cache and d-cache enabled,
> > +	 * D-cache diabled (for now),
> > +	 * I-cache enabled,
> >  	 * Alignment checking enabled,
> >  	 * MMU translation disabled (for now). */
> > -	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
> > +	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
> >  	mcr   CP32(r0, HSCTLR)
> >  
> >  	/* Write Xen's PT's paddr into the HTTBR */
> > @@ -217,6 +218,10 @@ pt_ready:
> >  	mov   pc, r1                 /* Get a proper vaddr into PC */
> >  paging:
> >  
> > +	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
> > +	orr   r0, r0, #(SCTLR_C)
> > +	mcr   CP32(r0, HSCTLR)
> > +
> >  #ifdef EARLY_UART_ADDRESS
> >  	/* Recover the UART address in the new address space. */
> >  	lsl   r11, #11
> > -- 
> > 1.7.9.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 Fri Jun 01 19:15:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 19:15: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 1SaXJ9-0002RX-Qf; Fri, 01 Jun 2012 19:14: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 1SaXJ7-0002RQ-UN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 19:14:46 +0000
Received: from [193.109.254.147:31260] by server-1.bemta-14.messagelabs.com id
	3C/05-07411-5A419CF4; Fri, 01 Jun 2012 19:14:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338578084!7277948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25721 invoked from network); 1 Jun 2012 19:14:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 19:14:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12794024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 19:14: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.213.0; Fri, 1 Jun 2012
	20:14:23 +0100
Message-ID: <1338578062.14877.65.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 20:14:22 +0100
In-Reply-To: <1338576470.14877.58.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote:
> Patch to follow shortly.

Here we go. Since this fixes the build I'll apply it in the morning
unless someone has objected by then (rather than leave the build broken
over the 4 day UK bank holiday weekend...), or sooner if someone acks
it.

I'll also add "make distclean" to my commit process, possibly even a git
clean based rune too.

8<--------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338578033 -3600
# Node ID bfe1d242bab30451b55e0bc12624a8e823d9a32a
# Parent  0197a9b4fd81dfd03f9df81a1c1eac64b5babdad
ocaml: fix build after 25446:648508ee27a2, 25449:68d46c5ea0a3 et al.

These renamed a type and the associated functions and the ocaml bindings were
not updated to suit.

This also highlighted that libxl_domain_sched_params should not be just DIR_IN
since it is also use as an output struct.

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

diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jun 01 19:59:24 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Fri Jun 01 20:13:53 2012 +0100
@@ -232,7 +232,7 @@ libxl_domain_sched_params = Struct("doma
     ("slice",        integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
     ("latency",      integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
     ("extratime",    integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
-    ], dir=DIR_IN)
+    ])
 
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 19:59:24 2012 +0100
+++ b/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 20:13:53 2012 +0100
@@ -32,8 +32,9 @@ functions = { # ( name , [type1,type2,..
                       ],
     "cputopology":    [ ("get",            ["unit", "t array"]),
                       ],
-    "sched_credit":   [ ("domain_get",     ["domid", "t"]),
-                        ("domain_set",     ["domid", "t", "unit"]),
+    "domain_sched_params":
+                      [ ("get",            ["domid", "t"]),
+                        ("set",            ["domid", "t", "unit"]),
                       ],
 }
 def stub_fn_name(ty, name):
diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 19:59:24 2012 +0100
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 20:13:53 2012 +0100
@@ -496,37 +496,37 @@ value stub_xl_cputopology_get(value unit
 	CAMLreturn(topology);
 }
 
-value stub_xl_sched_credit_domain_get(value domid)
+value stub_xl_domain_sched_params_get(value domid)
 {
 	CAMLparam1(domid);
 	CAMLlocal1(scinfo);
-	libxl_sched_credit_domain c_scinfo;
+	libxl_domain_sched_params c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
 	INIT_CTX();
-	ret = libxl_sched_credit_domain_get(ctx, Int_val(domid), &c_scinfo);
+	ret = libxl_domain_sched_params_get(ctx, Int_val(domid), &c_scinfo);
 	if (ret != 0)
-		failwith_xl("sched_credit_domain_get", &lg);
+		failwith_xl("domain_sched_params_get", &lg);
 	FREE_CTX();
 
-	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
+	scinfo = Val_domain_sched_params(&gc, &lg, &c_scinfo);
 	CAMLreturn(scinfo);
 }
 
-value stub_xl_sched_credit_domain_set(value domid, value scinfo)
+value stub_xl_domain_sched_params_set(value domid, value scinfo)
 {
 	CAMLparam2(domid, scinfo);
-	libxl_sched_credit_domain c_scinfo;
+	libxl_domain_sched_params c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
-	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
+	domain_sched_params_val(&gc, &lg, &c_scinfo, scinfo);
 
 	INIT_CTX();
-	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);
+	ret = libxl_domain_sched_params_set(ctx, Int_val(domid), &c_scinfo);
 	if (ret != 0)
-		failwith_xl("sched_credit_domain_set", &lg);
+		failwith_xl("domain_sched_params_set", &lg);
 	FREE_CTX();
 
 	CAMLreturn(Val_unit);



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 19:15:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 19:15: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 1SaXJ9-0002RX-Qf; Fri, 01 Jun 2012 19:14: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 1SaXJ7-0002RQ-UN
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 19:14:46 +0000
Received: from [193.109.254.147:31260] by server-1.bemta-14.messagelabs.com id
	3C/05-07411-5A419CF4; Fri, 01 Jun 2012 19:14:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338578084!7277948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25721 invoked from network); 1 Jun 2012 19:14:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 19:14:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12794024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 19:14: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.213.0; Fri, 1 Jun 2012
	20:14:23 +0100
Message-ID: <1338578062.14877.65.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 20:14:22 +0100
In-Reply-To: <1338576470.14877.58.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote:
> Patch to follow shortly.

Here we go. Since this fixes the build I'll apply it in the morning
unless someone has objected by then (rather than leave the build broken
over the 4 day UK bank holiday weekend...), or sooner if someone acks
it.

I'll also add "make distclean" to my commit process, possibly even a git
clean based rune too.

8<--------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338578033 -3600
# Node ID bfe1d242bab30451b55e0bc12624a8e823d9a32a
# Parent  0197a9b4fd81dfd03f9df81a1c1eac64b5babdad
ocaml: fix build after 25446:648508ee27a2, 25449:68d46c5ea0a3 et al.

These renamed a type and the associated functions and the ocaml bindings were
not updated to suit.

This also highlighted that libxl_domain_sched_params should not be just DIR_IN
since it is also use as an output struct.

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

diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jun 01 19:59:24 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Fri Jun 01 20:13:53 2012 +0100
@@ -232,7 +232,7 @@ libxl_domain_sched_params = Struct("doma
     ("slice",        integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
     ("latency",      integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
     ("extratime",    integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
-    ], dir=DIR_IN)
+    ])
 
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 19:59:24 2012 +0100
+++ b/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 20:13:53 2012 +0100
@@ -32,8 +32,9 @@ functions = { # ( name , [type1,type2,..
                       ],
     "cputopology":    [ ("get",            ["unit", "t array"]),
                       ],
-    "sched_credit":   [ ("domain_get",     ["domid", "t"]),
-                        ("domain_set",     ["domid", "t", "unit"]),
+    "domain_sched_params":
+                      [ ("get",            ["domid", "t"]),
+                        ("set",            ["domid", "t", "unit"]),
                       ],
 }
 def stub_fn_name(ty, name):
diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 19:59:24 2012 +0100
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 20:13:53 2012 +0100
@@ -496,37 +496,37 @@ value stub_xl_cputopology_get(value unit
 	CAMLreturn(topology);
 }
 
-value stub_xl_sched_credit_domain_get(value domid)
+value stub_xl_domain_sched_params_get(value domid)
 {
 	CAMLparam1(domid);
 	CAMLlocal1(scinfo);
-	libxl_sched_credit_domain c_scinfo;
+	libxl_domain_sched_params c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
 	INIT_CTX();
-	ret = libxl_sched_credit_domain_get(ctx, Int_val(domid), &c_scinfo);
+	ret = libxl_domain_sched_params_get(ctx, Int_val(domid), &c_scinfo);
 	if (ret != 0)
-		failwith_xl("sched_credit_domain_get", &lg);
+		failwith_xl("domain_sched_params_get", &lg);
 	FREE_CTX();
 
-	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
+	scinfo = Val_domain_sched_params(&gc, &lg, &c_scinfo);
 	CAMLreturn(scinfo);
 }
 
-value stub_xl_sched_credit_domain_set(value domid, value scinfo)
+value stub_xl_domain_sched_params_set(value domid, value scinfo)
 {
 	CAMLparam2(domid, scinfo);
-	libxl_sched_credit_domain c_scinfo;
+	libxl_domain_sched_params c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
-	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
+	domain_sched_params_val(&gc, &lg, &c_scinfo, scinfo);
 
 	INIT_CTX();
-	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);
+	ret = libxl_domain_sched_params_set(ctx, Int_val(domid), &c_scinfo);
 	if (ret != 0)
-		failwith_xl("sched_credit_domain_set", &lg);
+		failwith_xl("domain_sched_params_set", &lg);
 	FREE_CTX();
 
 	CAMLreturn(Val_unit);



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 19:17:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 19: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 1SaXLd-0002e4-HX; Fri, 01 Jun 2012 19:17: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 1SaXLc-0002du-5u
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 19:17:20 +0000
Received: from [85.158.143.99:47981] by server-2.bemta-4.messagelabs.com id
	77/04-11595-F3519CF4; Fri, 01 Jun 2012 19:17:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338578239!25698193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15927 invoked from network); 1 Jun 2012 19:17:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 19:17:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12794054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 19:17:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	20:17:18 +0100
Message-ID: <1338578238.14877.67.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 20:17:18 +0100
In-Reply-To: <20425.1120.90566.706268@mariner.uk.xensource.com>
References: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
	<20425.1120.90566.706268@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Simon Rowe <Simon.Rowe@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 19:05 +0100, Ian Jackson wrote:
> Simon Rowe writes ("[Xen-devel] [PATCH V2] xs: set read_thread stacksize"):
> > xs_watch() creates a thread to wake watchers using default attributes. The
> > stacksize can be quite large (8 MB on Linux), applications that link against
> > xenstore end up having a larger memory footprint than necessary.
> 
> Thanks.  This seems like a genuine bug but I have one comments about
> your fix.  The effect of your patch is to make the stacksize of the
> libxenstore private thread be small.
> 
> However, we do not take any care to avoid signals being delivered to
> this thread.  This is bad enough at the moment, but with your patch
> these signals may now be delivered to a thread with a small stack.
> 
> Can I request that you provide another patch too, which would probably
> come before this one, which uses pthread_sigprocmask to block all
> signals on the private thread ?  This is done by changing the signal
> mask to all signals blocked and then restoring it afterwards.

Do you mean pthread_sigmask or sigprocmask rather than the hybrid
pthread_sigprocmask (which appears not to exist).

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 19:17:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 19: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 1SaXLd-0002e4-HX; Fri, 01 Jun 2012 19:17: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 1SaXLc-0002du-5u
	for xen-devel@lists.xen.org; Fri, 01 Jun 2012 19:17:20 +0000
Received: from [85.158.143.99:47981] by server-2.bemta-4.messagelabs.com id
	77/04-11595-F3519CF4; Fri, 01 Jun 2012 19:17:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338578239!25698193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15927 invoked from network); 1 Jun 2012 19:17:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 19:17:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="12794054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 19:17:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	20:17:18 +0100
Message-ID: <1338578238.14877.67.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 20:17:18 +0100
In-Reply-To: <20425.1120.90566.706268@mariner.uk.xensource.com>
References: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
	<20425.1120.90566.706268@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Simon Rowe <Simon.Rowe@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 19:05 +0100, Ian Jackson wrote:
> Simon Rowe writes ("[Xen-devel] [PATCH V2] xs: set read_thread stacksize"):
> > xs_watch() creates a thread to wake watchers using default attributes. The
> > stacksize can be quite large (8 MB on Linux), applications that link against
> > xenstore end up having a larger memory footprint than necessary.
> 
> Thanks.  This seems like a genuine bug but I have one comments about
> your fix.  The effect of your patch is to make the stacksize of the
> libxenstore private thread be small.
> 
> However, we do not take any care to avoid signals being delivered to
> this thread.  This is bad enough at the moment, but with your patch
> these signals may now be delivered to a thread with a small stack.
> 
> Can I request that you provide another patch too, which would probably
> come before this one, which uses pthread_sigprocmask to block all
> signals on the private thread ?  This is done by changing the signal
> mask to all signals blocked and then restoring it afterwards.

Do you mean pthread_sigmask or sigprocmask rather than the hybrid
pthread_sigprocmask (which appears not to exist).

Ian.



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

From xen-devel-bounces@lists.xen.org Fri Jun 01 21:56:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 21: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 1SaZp1-0005Bv-5M; Fri, 01 Jun 2012 21:55:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaZoz-0005Bp-NU
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 21:55:50 +0000
Received: from [193.109.254.147:41547] by server-10.bemta-14.messagelabs.com
	id 52/AA-27843-46A39CF4; Fri, 01 Jun 2012 21:55:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338587748!11565888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21850 invoked from network); 1 Jun 2012 21:55:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 21:55:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,700,1330905600"; d="scan'208";a="12795023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 21:55:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 22:55:48 +0100
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 1SaZox-0006Lg-Pi;
	Fri, 01 Jun 2012 21:55:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaZox-0003UQ-Jg;
	Fri, 01 Jun 2012 22:55:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13004-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 22:55:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13004: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 13002
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13002

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 12999

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

version targeted for testing:
 xen                  3b4346d6002e
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Not pushing.


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

From xen-devel-bounces@lists.xen.org Fri Jun 01 21:56:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Jun 2012 21: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 1SaZp1-0005Bv-5M; Fri, 01 Jun 2012 21:55:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaZoz-0005Bp-NU
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 21:55:50 +0000
Received: from [193.109.254.147:41547] by server-10.bemta-14.messagelabs.com
	id 52/AA-27843-46A39CF4; Fri, 01 Jun 2012 21:55:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338587748!11565888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA3ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21850 invoked from network); 1 Jun 2012 21:55:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 21:55:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,700,1330905600"; d="scan'208";a="12795023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jun 2012 21:55:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 1 Jun 2012 22:55:48 +0100
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 1SaZox-0006Lg-Pi;
	Fri, 01 Jun 2012 21:55:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaZox-0003UQ-Jg;
	Fri, 01 Jun 2012 22:55:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13004-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Jun 2012 22:55:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13004: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 13002
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13002

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 12999

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

version targeted for testing:
 xen                  3b4346d6002e
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Not pushing.


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 03:09:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 03: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 1SaehW-0007PX-Is; Sat, 02 Jun 2012 03:08:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaehU-0007PS-96
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 03:08:24 +0000
Received: from [85.158.138.51:25932] by server-6.bemta-3.messagelabs.com id
	19/71-23455-7A389CF4; Sat, 02 Jun 2012 03:08:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338606502!30522413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5855 invoked from network); 2 Jun 2012 03:08:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 03:08:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,700,1330905600"; d="scan'208";a="12796068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 03:08:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 2 Jun 2012 04:08:21 +0100
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 1SaehQ-00081a-K1;
	Sat, 02 Jun 2012 03:08:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaehQ-0002IO-JT;
	Sat, 02 Jun 2012 04:08:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13006-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 04:08:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13006: 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 13006 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13006/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 12999

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-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-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1e2ce970f0f2
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=1e2ce970f0f2
+ . 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 1e2ce970f0f2
+ branch=xen-unstable
+ revision=1e2ce970f0f2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1e2ce970f0f2 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 19 changesets with 56 changes to 31 files

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

From xen-devel-bounces@lists.xen.org Sat Jun 02 03:09:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 03: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 1SaehW-0007PX-Is; Sat, 02 Jun 2012 03:08:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SaehU-0007PS-96
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 03:08:24 +0000
Received: from [85.158.138.51:25932] by server-6.bemta-3.messagelabs.com id
	19/71-23455-7A389CF4; Sat, 02 Jun 2012 03:08:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338606502!30522413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5855 invoked from network); 2 Jun 2012 03:08:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 03:08:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,700,1330905600"; d="scan'208";a="12796068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 03:08:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 2 Jun 2012 04:08:21 +0100
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 1SaehQ-00081a-K1;
	Sat, 02 Jun 2012 03:08:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SaehQ-0002IO-JT;
	Sat, 02 Jun 2012 04:08:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13006-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 04:08:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13006: 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 13006 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13006/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 12999

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-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-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1e2ce970f0f2
baseline version:
 xen                  d7318231cfe3

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=1e2ce970f0f2
+ . 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 1e2ce970f0f2
+ branch=xen-unstable
+ revision=1e2ce970f0f2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1e2ce970f0f2 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 19 changesets with 56 changes to 31 files

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

From xen-devel-bounces@lists.xen.org Sat Jun 02 06:38:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 06: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 1Sahyb-0002Pz-Bl; Sat, 02 Jun 2012 06:38:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SahyZ-0002Pu-6W
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 06:38:15 +0000
Received: from [85.158.138.51:61973] by server-1.bemta-3.messagelabs.com id
	9C/E1-06526-6D4B9CF4; Sat, 02 Jun 2012 06:38:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-174.messagelabs.com!1338619093!26411565!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2215 invoked from network); 2 Jun 2012 06:38:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-174.messagelabs.com with SMTP;
	2 Jun 2012 06:38:13 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78373757; Sat, 02 Jun 2012 08:37:59 +0200
Message-ID: <1338619069.4052.0.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Sat, 02 Jun 2012 08:37:49 +0200
In-Reply-To: <1338576470.14877.58.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8200793659439453277=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8200793659439453277==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-NlG91tF5MLX8/e6k4rSd"


--=-NlG91tF5MLX8/e6k4rSd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote:=20
> Damn, sorry about that. I swear I compiled this both before sending it
> and as part of the commit procedure, and I just tried built it again and
> didn't see it.
>=20
Uh? I can build it too...

> However I've now done a make clean and can now repro. Patch to follow
> shortly.
>=20
Ah, perhaps it is this (I'm not sure I 'make clean'-ed)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-NlG91tF5MLX8/e6k4rSd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/JtL0ACgkQk4XaBE3IOsSN7QCghPOswywJcx9u3WsPDk0LvyRV
CZcAoKUqTQ7X+zhX0/VQ3BES58exsVDr
=BB0v
-----END PGP SIGNATURE-----

--=-NlG91tF5MLX8/e6k4rSd--



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

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

--===============8200793659439453277==--



From xen-devel-bounces@lists.xen.org Sat Jun 02 06:38:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 06: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 1Sahyb-0002Pz-Bl; Sat, 02 Jun 2012 06:38:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SahyZ-0002Pu-6W
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 06:38:15 +0000
Received: from [85.158.138.51:61973] by server-1.bemta-3.messagelabs.com id
	9C/E1-06526-6D4B9CF4; Sat, 02 Jun 2012 06:38:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-174.messagelabs.com!1338619093!26411565!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2215 invoked from network); 2 Jun 2012 06:38:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-174.messagelabs.com with SMTP;
	2 Jun 2012 06:38:13 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78373757; Sat, 02 Jun 2012 08:37:59 +0200
Message-ID: <1338619069.4052.0.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Sat, 02 Jun 2012 08:37:49 +0200
In-Reply-To: <1338576470.14877.58.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8200793659439453277=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8200793659439453277==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-NlG91tF5MLX8/e6k4rSd"


--=-NlG91tF5MLX8/e6k4rSd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote:=20
> Damn, sorry about that. I swear I compiled this both before sending it
> and as part of the commit procedure, and I just tried built it again and
> didn't see it.
>=20
Uh? I can build it too...

> However I've now done a make clean and can now repro. Patch to follow
> shortly.
>=20
Ah, perhaps it is this (I'm not sure I 'make clean'-ed)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-NlG91tF5MLX8/e6k4rSd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/JtL0ACgkQk4XaBE3IOsSN7QCghPOswywJcx9u3WsPDk0LvyRV
CZcAoKUqTQ7X+zhX0/VQ3BES58exsVDr
=BB0v
-----END PGP SIGNATURE-----

--=-NlG91tF5MLX8/e6k4rSd--



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

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

--===============8200793659439453277==--



From xen-devel-bounces@lists.xen.org Sat Jun 02 07:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 07: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 1Saiwz-0003S1-50; Sat, 02 Jun 2012 07:40:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Saiwx-0003Rw-1C
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 07:40:39 +0000
Received: from [85.158.143.99:43163] by server-3.bemta-4.messagelabs.com id
	3D/E3-04252-673C9CF4; Sat, 02 Jun 2012 07:40:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338622837!31005086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11726 invoked from network); 2 Jun 2012 07:40:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 07:40:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12797436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 07:40:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 2 Jun 2012
	08:40:37 +0100
Message-ID: <1338622836.14877.69.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 08:40:36 +0100
In-Reply-To: <1338578062.14877.65.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
	<1338578062.14877.65.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 20:14 +0100, Ian Campbell wrote:
> On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote:
> > Patch to follow shortly.
> 
> Here we go. Since this fixes the build I'll apply it in the morning

Done.

[...]

> 8<--------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1338578033 -3600
> # Node ID bfe1d242bab30451b55e0bc12624a8e823d9a32a
> # Parent  0197a9b4fd81dfd03f9df81a1c1eac64b5babdad
> ocaml: fix build after 25446:648508ee27a2, 25449:68d46c5ea0a3 et al.
> 
> These renamed a type and the associated functions and the ocaml bindings were
> not updated to suit.
> 
> This also highlighted that libxl_domain_sched_params should not be just DIR_IN
> since it is also use as an output struct.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri Jun 01 19:59:24 2012 +0100
> +++ b/tools/libxl/libxl_types.idl	Fri Jun 01 20:13:53 2012 +0100
> @@ -232,7 +232,7 @@ libxl_domain_sched_params = Struct("doma
>      ("slice",        integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
>      ("latency",      integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
>      ("extratime",    integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
> -    ], dir=DIR_IN)
> +    ])
>  
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
> diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/genwrap.py
> --- a/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 19:59:24 2012 +0100
> +++ b/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 20:13:53 2012 +0100
> @@ -32,8 +32,9 @@ functions = { # ( name , [type1,type2,..
>                        ],
>      "cputopology":    [ ("get",            ["unit", "t array"]),
>                        ],
> -    "sched_credit":   [ ("domain_get",     ["domid", "t"]),
> -                        ("domain_set",     ["domid", "t", "unit"]),
> +    "domain_sched_params":
> +                      [ ("get",            ["domid", "t"]),
> +                        ("set",            ["domid", "t", "unit"]),
>                        ],
>  }
>  def stub_fn_name(ty, name):
> diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/xenlight_stubs.c
> --- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 19:59:24 2012 +0100
> +++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 20:13:53 2012 +0100
> @@ -496,37 +496,37 @@ value stub_xl_cputopology_get(value unit
>  	CAMLreturn(topology);
>  }
>  
> -value stub_xl_sched_credit_domain_get(value domid)
> +value stub_xl_domain_sched_params_get(value domid)
>  {
>  	CAMLparam1(domid);
>  	CAMLlocal1(scinfo);
> -	libxl_sched_credit_domain c_scinfo;
> +	libxl_domain_sched_params c_scinfo;
>  	int ret;
>  	INIT_STRUCT();
>  
>  	INIT_CTX();
> -	ret = libxl_sched_credit_domain_get(ctx, Int_val(domid), &c_scinfo);
> +	ret = libxl_domain_sched_params_get(ctx, Int_val(domid), &c_scinfo);
>  	if (ret != 0)
> -		failwith_xl("sched_credit_domain_get", &lg);
> +		failwith_xl("domain_sched_params_get", &lg);
>  	FREE_CTX();
>  
> -	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
> +	scinfo = Val_domain_sched_params(&gc, &lg, &c_scinfo);
>  	CAMLreturn(scinfo);
>  }
>  
> -value stub_xl_sched_credit_domain_set(value domid, value scinfo)
> +value stub_xl_domain_sched_params_set(value domid, value scinfo)
>  {
>  	CAMLparam2(domid, scinfo);
> -	libxl_sched_credit_domain c_scinfo;
> +	libxl_domain_sched_params c_scinfo;
>  	int ret;
>  	INIT_STRUCT();
>  
> -	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
> +	domain_sched_params_val(&gc, &lg, &c_scinfo, scinfo);
>  
>  	INIT_CTX();
> -	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);
> +	ret = libxl_domain_sched_params_set(ctx, Int_val(domid), &c_scinfo);
>  	if (ret != 0)
> -		failwith_xl("sched_credit_domain_set", &lg);
> +		failwith_xl("domain_sched_params_set", &lg);
>  	FREE_CTX();
>  
>  	CAMLreturn(Val_unit);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 02 07:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 07: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 1Saiwz-0003S1-50; Sat, 02 Jun 2012 07:40:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Saiwx-0003Rw-1C
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 07:40:39 +0000
Received: from [85.158.143.99:43163] by server-3.bemta-4.messagelabs.com id
	3D/E3-04252-673C9CF4; Sat, 02 Jun 2012 07:40:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338622837!31005086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11726 invoked from network); 2 Jun 2012 07:40:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 07:40:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12797436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 07:40:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 2 Jun 2012
	08:40:37 +0100
Message-ID: <1338622836.14877.69.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 08:40:36 +0100
In-Reply-To: <1338578062.14877.65.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
	<1338578062.14877.65.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 20:14 +0100, Ian Campbell wrote:
> On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote:
> > Patch to follow shortly.
> 
> Here we go. Since this fixes the build I'll apply it in the morning

Done.

[...]

> 8<--------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1338578033 -3600
> # Node ID bfe1d242bab30451b55e0bc12624a8e823d9a32a
> # Parent  0197a9b4fd81dfd03f9df81a1c1eac64b5babdad
> ocaml: fix build after 25446:648508ee27a2, 25449:68d46c5ea0a3 et al.
> 
> These renamed a type and the associated functions and the ocaml bindings were
> not updated to suit.
> 
> This also highlighted that libxl_domain_sched_params should not be just DIR_IN
> since it is also use as an output struct.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri Jun 01 19:59:24 2012 +0100
> +++ b/tools/libxl/libxl_types.idl	Fri Jun 01 20:13:53 2012 +0100
> @@ -232,7 +232,7 @@ libxl_domain_sched_params = Struct("doma
>      ("slice",        integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
>      ("latency",      integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
>      ("extratime",    integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
> -    ], dir=DIR_IN)
> +    ])
>  
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
> diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/genwrap.py
> --- a/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 19:59:24 2012 +0100
> +++ b/tools/ocaml/libs/xl/genwrap.py	Fri Jun 01 20:13:53 2012 +0100
> @@ -32,8 +32,9 @@ functions = { # ( name , [type1,type2,..
>                        ],
>      "cputopology":    [ ("get",            ["unit", "t array"]),
>                        ],
> -    "sched_credit":   [ ("domain_get",     ["domid", "t"]),
> -                        ("domain_set",     ["domid", "t", "unit"]),
> +    "domain_sched_params":
> +                      [ ("get",            ["domid", "t"]),
> +                        ("set",            ["domid", "t", "unit"]),
>                        ],
>  }
>  def stub_fn_name(ty, name):
> diff -r 0197a9b4fd81 -r bfe1d242bab3 tools/ocaml/libs/xl/xenlight_stubs.c
> --- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 19:59:24 2012 +0100
> +++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jun 01 20:13:53 2012 +0100
> @@ -496,37 +496,37 @@ value stub_xl_cputopology_get(value unit
>  	CAMLreturn(topology);
>  }
>  
> -value stub_xl_sched_credit_domain_get(value domid)
> +value stub_xl_domain_sched_params_get(value domid)
>  {
>  	CAMLparam1(domid);
>  	CAMLlocal1(scinfo);
> -	libxl_sched_credit_domain c_scinfo;
> +	libxl_domain_sched_params c_scinfo;
>  	int ret;
>  	INIT_STRUCT();
>  
>  	INIT_CTX();
> -	ret = libxl_sched_credit_domain_get(ctx, Int_val(domid), &c_scinfo);
> +	ret = libxl_domain_sched_params_get(ctx, Int_val(domid), &c_scinfo);
>  	if (ret != 0)
> -		failwith_xl("sched_credit_domain_get", &lg);
> +		failwith_xl("domain_sched_params_get", &lg);
>  	FREE_CTX();
>  
> -	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
> +	scinfo = Val_domain_sched_params(&gc, &lg, &c_scinfo);
>  	CAMLreturn(scinfo);
>  }
>  
> -value stub_xl_sched_credit_domain_set(value domid, value scinfo)
> +value stub_xl_domain_sched_params_set(value domid, value scinfo)
>  {
>  	CAMLparam2(domid, scinfo);
> -	libxl_sched_credit_domain c_scinfo;
> +	libxl_domain_sched_params c_scinfo;
>  	int ret;
>  	INIT_STRUCT();
>  
> -	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
> +	domain_sched_params_val(&gc, &lg, &c_scinfo, scinfo);
>  
>  	INIT_CTX();
> -	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);
> +	ret = libxl_domain_sched_params_set(ctx, Int_val(domid), &c_scinfo);
>  	if (ret != 0)
> -		failwith_xl("sched_credit_domain_set", &lg);
> +		failwith_xl("domain_sched_params_set", &lg);
>  	FREE_CTX();
>  
>  	CAMLreturn(Val_unit);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 02 07:41:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 07: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 1SaixP-0003TO-NM; Sat, 02 Jun 2012 07:41: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 1SaixP-0003TG-0U
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 07:41:07 +0000
Received: from [85.158.139.83:44120] by server-3.bemta-5.messagelabs.com id
	FD/63-17554-293C9CF4; Sat, 02 Jun 2012 07:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1338622865!24352159!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22822 invoked from network); 2 Jun 2012 07:41:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 07:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12797438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 07:41:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 2 Jun 2012
	08:41:04 +0100
Message-ID: <1338622864.14877.70.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Sat, 2 Jun 2012 08:41:04 +0100
In-Reply-To: <1338619069.4052.0.camel@Abyss>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
	<1338619069.4052.0.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-06-02 at 07:37 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote: 
> > Damn, sorry about that. I swear I compiled this both before sending it
> > and as part of the commit procedure, and I just tried built it again and
> > didn't see it.
> > 
> Uh? I can build it too...

So, apparently, could test flight 13006, which is odd because I thought
the test system was doing everything totally from scratch.

I've pushed the fix anyway.

Ian.



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

From xen-devel-bounces@lists.xen.org Sat Jun 02 07:41:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 07: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 1SaixP-0003TO-NM; Sat, 02 Jun 2012 07:41: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 1SaixP-0003TG-0U
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 07:41:07 +0000
Received: from [85.158.139.83:44120] by server-3.bemta-5.messagelabs.com id
	FD/63-17554-293C9CF4; Sat, 02 Jun 2012 07:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1338622865!24352159!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22822 invoked from network); 2 Jun 2012 07:41:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 07:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12797438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 07:41:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 2 Jun 2012
	08:41:04 +0100
Message-ID: <1338622864.14877.70.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Sat, 2 Jun 2012 08:41:04 +0100
In-Reply-To: <1338619069.4052.0.camel@Abyss>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
	<1338619069.4052.0.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-06-02 at 07:37 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 19:47 +0100, Ian Campbell wrote: 
> > Damn, sorry about that. I swear I compiled this both before sending it
> > and as part of the commit procedure, and I just tried built it again and
> > didn't see it.
> > 
> Uh? I can build it too...

So, apparently, could test flight 13006, which is odd because I thought
the test system was doing everything totally from scratch.

I've pushed the fix anyway.

Ian.



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

From xen-devel-bounces@lists.xen.org Sat Jun 02 08:49:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 08: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 1Sak0e-0004uK-Pg; Sat, 02 Jun 2012 08:48: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 1Sak0d-0004uF-Ai
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 08:48:31 +0000
Received: from [85.158.139.83:65459] by server-9.bemta-5.messagelabs.com id
	2B/F3-29678-E53D9CF4; Sat, 02 Jun 2012 08:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338626908!30177413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2570 invoked from network); 2 Jun 2012 08:48:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 08:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12797873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 08:48:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 2 Jun 2012 09:48:28 +0100
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 1Sak0Z-0001PP-Oq;
	Sat, 02 Jun 2012 08:48:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sak0Z-0006YR-Hv;
	Sat, 02 Jun 2012 09:48:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13012-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 09:48:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13012: 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 13012 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13012/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13006

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1e2ce970f0f2
baseline version:
 xen                  1e2ce970f0f2

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 08:49:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 08: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 1Sak0e-0004uK-Pg; Sat, 02 Jun 2012 08:48: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 1Sak0d-0004uF-Ai
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 08:48:31 +0000
Received: from [85.158.139.83:65459] by server-9.bemta-5.messagelabs.com id
	2B/F3-29678-E53D9CF4; Sat, 02 Jun 2012 08:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338626908!30177413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDA4OTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2570 invoked from network); 2 Jun 2012 08:48:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 08:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12797873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 08:48:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 2 Jun 2012 09:48:28 +0100
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 1Sak0Z-0001PP-Oq;
	Sat, 02 Jun 2012 08:48:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sak0Z-0006YR-Hv;
	Sat, 02 Jun 2012 09:48:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13012-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 09:48:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13012: 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 13012 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13012/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13006

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1e2ce970f0f2
baseline version:
 xen                  1e2ce970f0f2

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO3-0008Or-HF; Sat, 02 Jun 2012 13:28: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 1SaRSQ-0001gr-Gy
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 12:59:58 +0000
Received: from [85.158.143.99:49245] by server-3.bemta-4.messagelabs.com id
	0F/70-04252-ACCB8CF4; Fri, 01 Jun 2012 12:59:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338555592!30594377!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 618 invoked from network); 1 Jun 2012 12:59:53 -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; 1 Jun 2012 12:59:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 13:59:51 +0100
Message-Id: <4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 13:59:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <srivatsa.bhat@linux.vnet.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
wrote:
> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
> suggests) is useful in the cpu bringup path.

This might not be correct - the code as it is without this change is
safe even when the vCPU gets onlined back later by an external
entity (e.g. the Xen tool stack), and it would in that case resume
at the return point of the VCPUOP_down hypercall. That might
be a heritage from the original XenoLinux tree though, and be
meaningless in pv-ops context - Jeremy, Konrad?

Possibly it was bogus/unused even in that original tree - Keir?

Jan

> Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in 
> hooking on to the generic SMP booting framework.
> 
> Also remove the extra call to preempt_enable() added by commit 41bd956
> (xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while
> atomic) because it becomes unnecessary after this change.
> 
> 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 
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
> 
>  arch/x86/xen/smp.c |    8 --------
>  1 files changed, 0 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 09a7199..602d6b7 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -417,14 +417,6 @@ static void __cpuinit xen_play_dead(void) /* used only 
> with HOTPLUG_CPU */
>  {
>  	play_dead_common();
>  	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
> -	cpu_bringup();
> -	/*
> -	 * Balance out the preempt calls - as we are running in cpu_idle
> -	 * loop which has been called at bootup from cpu_bringup_and_idle.
> -	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
> -	 * preempt_disable() So this preempt_enable will balance it out.
> -	 */
> -	preempt_enable();
>  }
>  
>  #else /* !CONFIG_HOTPLUG_CPU */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 02 13:29:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO3-0008Or-HF; Sat, 02 Jun 2012 13:28: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 1SaRSQ-0001gr-Gy
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 12:59:58 +0000
Received: from [85.158.143.99:49245] by server-3.bemta-4.messagelabs.com id
	0F/70-04252-ACCB8CF4; Fri, 01 Jun 2012 12:59:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338555592!30594377!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 618 invoked from network); 1 Jun 2012 12:59:53 -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; 1 Jun 2012 12:59:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 13:59:51 +0100
Message-Id: <4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 13:59:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <srivatsa.bhat@linux.vnet.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
wrote:
> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
> suggests) is useful in the cpu bringup path.

This might not be correct - the code as it is without this change is
safe even when the vCPU gets onlined back later by an external
entity (e.g. the Xen tool stack), and it would in that case resume
at the return point of the VCPUOP_down hypercall. That might
be a heritage from the original XenoLinux tree though, and be
meaningless in pv-ops context - Jeremy, Konrad?

Possibly it was bogus/unused even in that original tree - Keir?

Jan

> Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in 
> hooking on to the generic SMP booting framework.
> 
> Also remove the extra call to preempt_enable() added by commit 41bd956
> (xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while
> atomic) because it becomes unnecessary after this change.
> 
> 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 
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
> 
>  arch/x86/xen/smp.c |    8 --------
>  1 files changed, 0 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 09a7199..602d6b7 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -417,14 +417,6 @@ static void __cpuinit xen_play_dead(void) /* used only 
> with HOTPLUG_CPU */
>  {
>  	play_dead_common();
>  	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
> -	cpu_bringup();
> -	/*
> -	 * Balance out the preempt calls - as we are running in cpu_idle
> -	 * loop which has been called at bootup from cpu_bringup_and_idle.
> -	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
> -	 * preempt_disable() So this preempt_enable will balance it out.
> -	 */
> -	preempt_enable();
>  }
>  
>  #else /* !CONFIG_HOTPLUG_CPU */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 02 13:29:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO3-0008Oy-SH; Sat, 02 Jun 2012 13:28:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaTYb-00060d-Gk
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:14:29 +0000
Received: from [85.158.143.35:52564] by server-2.bemta-4.messagelabs.com id
	83/A7-11595-45CD8CF4; Fri, 01 Jun 2012 15:14:28 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338563665!13151096!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAyMDg4MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23620 invoked from network); 1 Jun 2012 15:14:27 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 15:14:27 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 20:44:24 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 20:44:21 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q51FEKkU3211640
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 20:44:21 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q51KhseS003738
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 02:13:57 +0530
Received: from [9.77.82.204] ([9.77.82.204])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q51KhlAY003093; Sat, 2 Jun 2012 02:13:48 +0530
Message-ID: <4FC8DC19.4000007@linux.vnet.ibm.com>
Date: Fri, 01 Jun 2012 20:43:29 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
In-Reply-To: <4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
x-cbid: 12060115-9574-0000-0000-00000302CF04
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Russell King <linux@arm.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 06:29 PM, Jan Beulich wrote:

>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> wrote:
>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>> suggests) is useful in the cpu bringup path.
> 
> This might not be correct - the code as it is without this change is
> safe even when the vCPU gets onlined back later by an external
> entity (e.g. the Xen tool stack), and it would in that case resume
> at the return point of the VCPUOP_down hypercall. That might
> be a heritage from the original XenoLinux tree though, and be
> meaningless in pv-ops context - Jeremy, Konrad?
> 
> Possibly it was bogus/unused even in that original tree - Keir?
>


Thanks for your comments Jan!

In case this change is wrong, the other method I had in mind was to call
cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
in the sense that it runs the cpu bringup code including cpu_idle(), in the
cpu offline path, namely the cpu_die() function). Would that approach work
for xen as well? If yes, then we wouldn't have any issues to convert xen to
generic code.

Regards,
Srivatsa S. Bhat

> 
>> Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in 
>> hooking on to the generic SMP booting framework.
>>
>> Also remove the extra call to preempt_enable() added by commit 41bd956
>> (xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while
>> atomic) because it becomes unnecessary after this change.
>>
>> 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 
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> ---
>>
>>  arch/x86/xen/smp.c |    8 --------
>>  1 files changed, 0 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>> index 09a7199..602d6b7 100644
>> --- a/arch/x86/xen/smp.c
>> +++ b/arch/x86/xen/smp.c
>> @@ -417,14 +417,6 @@ static void __cpuinit xen_play_dead(void) /* used only 
>> with HOTPLUG_CPU */
>>  {
>>  	play_dead_common();
>>  	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
>> -	cpu_bringup();
>> -	/*
>> -	 * Balance out the preempt calls - as we are running in cpu_idle
>> -	 * loop which has been called at bootup from cpu_bringup_and_idle.
>> -	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
>> -	 * preempt_disable() So this preempt_enable will balance it out.
>> -	 */
>> -	preempt_enable();
>>  }
>>  
>>  #else /* !CONFIG_HOTPLUG_CPU */
>>
>>


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO3-0008Oy-SH; Sat, 02 Jun 2012 13:28:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SaTYb-00060d-Gk
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:14:29 +0000
Received: from [85.158.143.35:52564] by server-2.bemta-4.messagelabs.com id
	83/A7-11595-45CD8CF4; Fri, 01 Jun 2012 15:14:28 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338563665!13151096!1
X-Originating-IP: [122.248.162.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAyMDg4MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23620 invoked from network); 1 Jun 2012 15:14:27 -0000
Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Jun 2012 15:14:27 -0000
Received: from /spool/local
	by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Fri, 1 Jun 2012 20:44:24 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 1 Jun 2012 20:44:21 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q51FEKkU3211640
	for <xen-devel@lists.xensource.com>; Fri, 1 Jun 2012 20:44:21 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q51KhseS003738
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 02:13:57 +0530
Received: from [9.77.82.204] ([9.77.82.204])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q51KhlAY003093; Sat, 2 Jun 2012 02:13:48 +0530
Message-ID: <4FC8DC19.4000007@linux.vnet.ibm.com>
Date: Fri, 01 Jun 2012 20:43:29 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
In-Reply-To: <4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
x-cbid: 12060115-9574-0000-0000-00000302CF04
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Russell King <linux@arm.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 06:29 PM, Jan Beulich wrote:

>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> wrote:
>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>> suggests) is useful in the cpu bringup path.
> 
> This might not be correct - the code as it is without this change is
> safe even when the vCPU gets onlined back later by an external
> entity (e.g. the Xen tool stack), and it would in that case resume
> at the return point of the VCPUOP_down hypercall. That might
> be a heritage from the original XenoLinux tree though, and be
> meaningless in pv-ops context - Jeremy, Konrad?
> 
> Possibly it was bogus/unused even in that original tree - Keir?
>


Thanks for your comments Jan!

In case this change is wrong, the other method I had in mind was to call
cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
in the sense that it runs the cpu bringup code including cpu_idle(), in the
cpu offline path, namely the cpu_die() function). Would that approach work
for xen as well? If yes, then we wouldn't have any issues to convert xen to
generic code.

Regards,
Srivatsa S. Bhat

> 
>> Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in 
>> hooking on to the generic SMP booting framework.
>>
>> Also remove the extra call to preempt_enable() added by commit 41bd956
>> (xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while
>> atomic) because it becomes unnecessary after this change.
>>
>> 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 
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> ---
>>
>>  arch/x86/xen/smp.c |    8 --------
>>  1 files changed, 0 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>> index 09a7199..602d6b7 100644
>> --- a/arch/x86/xen/smp.c
>> +++ b/arch/x86/xen/smp.c
>> @@ -417,14 +417,6 @@ static void __cpuinit xen_play_dead(void) /* used only 
>> with HOTPLUG_CPU */
>>  {
>>  	play_dead_common();
>>  	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
>> -	cpu_bringup();
>> -	/*
>> -	 * Balance out the preempt calls - as we are running in cpu_idle
>> -	 * loop which has been called at bootup from cpu_bringup_and_idle.
>> -	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
>> -	 * preempt_disable() So this preempt_enable will balance it out.
>> -	 */
>> -	preempt_enable();
>>  }
>>  
>>  #else /* !CONFIG_HOTPLUG_CPU */
>>
>>


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO4-0008PC-JN; Sat, 02 Jun 2012 13:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddaney.cavm@gmail.com>) id 1SaVBz-0006sd-SJ
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:59:16 +0000
Received: from [85.158.143.99:7651] by server-1.bemta-4.messagelabs.com id
	E4/E4-27869-3E4F8CF4; Fri, 01 Jun 2012 16:59:15 +0000
X-Env-Sender: ddaney.cavm@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338569952!30401377!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6792 invoked from network); 1 Jun 2012 16:59:14 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:59:14 -0000
Received: by dajz8 with SMTP id z8so3468097daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Jun 2012 09:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=wbLRlIRQ0gm2LiNUXyElqCgrygSzoMO1bWGOWHNTWAU=;
	b=k11OuMGjCTvzNh7rawnPmS2K5WIql00y9kaZD4WQWJLRXsPGND0H3p3rNDMwzRSM0G
	ph9Ir6uoyrpm6xkUHhCT8tSlwiqsQO9F9c/MhIsn9sTGqIFXIjjJ53CTARKetscIr19I
	tbuv0wxHjsSHXrjqd/x6QzNFMMQwZPGNFjQdNNpshZAN+BaWOzG0jDlNXn1Laf9gQuCH
	7IyKsU3xnUZB7WQE4QPFCSikauRaFAUU0g5B2CG+JfqZLffQgc+OVi3JozuYa5ljCUcC
	MglRUGNeeptRwGaVtNHLIJzApwoyVPCKbIJvthFKESUsrh5lLEmRf/E1quc1Fet+D1UQ
	Nbkg==
Received: by 10.68.240.105 with SMTP id vz9mr4905000pbc.119.1338569951304;
	Fri, 01 Jun 2012 09:59:11 -0700 (PDT)
Received: from dd1.caveonetworks.com (64.2.3.195.ptr.us.xo.net. [64.2.3.195])
	by mx.google.com with ESMTPS id
	ua6sm3303728pbc.20.2012.06.01.09.59.08 (version=SSLv3 cipher=OTHER);
	Fri, 01 Jun 2012 09:59:09 -0700 (PDT)
Message-ID: <4FC8F4DB.2070906@gmail.com>
Date: Fri, 01 Jun 2012 09:59:07 -0700
From: David Daney <ddaney.cavm@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10
MIME-Version: 1.0
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091038.31979.67878.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601091038.31979.67878.stgit@srivatsabhat.in.ibm.com>
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: Venkatesh Pallipadi <venki@google.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
	peterz@infradead.org, Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	mingo@kernel.org, linux-arch@vger.kernel.org,
	xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	linux-sh@vger.kernel.org, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, paulmck@linux.vnet.ibm.com,
	Fenghua Yu <fenghua.yu@intel.com>, Mike Frysinger <vapier@gentoo.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, Chris Metcalf <cmetcalf@tilera.com>,
	rjw@sisk.pl, yong.zhang0@gmail.com, tglx@linutronix.de,
	virtualization@lists.linux-foundation.org,
	Tony Luck <tony.luck@intel.com>, vatsa@linux.vnet.ibm.com,
	Ralf Baechle <ralf@linux-mips.org>,
	Paul Mundt <lethal@linux-sh.org>, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [Xen-devel] [PATCH 03/27] smpboot: Define and use cpu_state
 per-cpu variable in generic 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-Transfer-Encoding: 7bit
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/01/2012 02:10 AM, Srivatsa S. Bhat wrote:
> The per-cpu variable cpu_state is used in x86 and also used in other
> architectures, to track the state of the cpu during bringup and hotplug.
> Pull it out into generic code.
>
> Cc: Tony Luck<tony.luck@intel.com>
> Cc: Fenghua Yu<fenghua.yu@intel.com>
> Cc: Ralf Baechle<ralf@linux-mips.org>
> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> Cc: Paul Mundt<lethal@linux-sh.org>
> Cc: Chris Metcalf<cmetcalf@tilera.com>
> Cc: Thomas Gleixner<tglx@linutronix.de>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: "H. Peter Anvin"<hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
> Cc: Peter Zijlstra<a.p.zijlstra@chello.nl>
> Cc: Andrew Morton<akpm@linux-foundation.org>
> Cc: Mike Frysinger<vapier@gentoo.org>
> Cc: Yong Zhang<yong.zhang0@gmail.com>
> Cc: Venkatesh Pallipadi<venki@google.com>
> Cc: Suresh Siddha<suresh.b.siddha@intel.com>
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-sh@vger.kernel.org
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Srivatsa S. Bhat<srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
>   arch/ia64/include/asm/cpu.h   |    2 --
>   arch/ia64/kernel/process.c    |    1 +
>   arch/ia64/kernel/smpboot.c    |    6 +-----
>   arch/mips/cavium-octeon/smp.c |    4 +---
>   arch/powerpc/kernel/smp.c     |    6 +-----
>   arch/sh/include/asm/smp.h     |    2 --
>   arch/sh/kernel/smp.c          |    4 +---
>   arch/tile/kernel/smpboot.c    |    4 +---
>   arch/x86/include/asm/cpu.h    |    2 --
>   arch/x86/kernel/smpboot.c     |    4 +---
>   arch/x86/xen/smp.c            |    1 +
>   include/linux/smpboot.h       |    1 +
>   kernel/smpboot.c              |    4 ++++
>   13 files changed, 13 insertions(+), 28 deletions(-)
>
[...]
> diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
> index 97e7ce9..93cd4b0 100644
> --- a/arch/mips/cavium-octeon/smp.c
> +++ b/arch/mips/cavium-octeon/smp.c
> @@ -13,6 +13,7 @@
>   #include<linux/kernel_stat.h>
>   #include<linux/sched.h>
>   #include<linux/module.h>
> +#include<linux/smpboot.h>
>
>   #include<asm/mmu_context.h>
>   #include<asm/time.h>
> @@ -252,9 +253,6 @@ static void octeon_cpus_done(void)
>
>   #ifdef CONFIG_HOTPLUG_CPU
>
> -/* State of each CPU. */
> -DEFINE_PER_CPU(int, cpu_state);
> -
>   extern void fixup_irqs(void);
>
>   static DEFINE_SPINLOCK(smp_reserve_lock);

The Octeon bit:

Acked-by: David Daney <david.daney@cavium.com>


FWIW, the rest looks good too.

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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO4-0008P5-7W; Sat, 02 Jun 2012 13:29:00 +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 1SaTuJ-0006UR-Cq
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:36:55 +0000
Received: from [193.109.254.147:23500] by server-1.bemta-14.messagelabs.com id
	95/0D-07411-691E8CF4; Fri, 01 Jun 2012 15:36:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338565013!11525966!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12446 invoked from network); 1 Jun 2012 15:36:54 -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; 1 Jun 2012 15:36:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 16:36:30 +0100
Message-Id: <4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 16:36:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
In-Reply-To: <4FC8DC19.4000007@linux.vnet.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
wrote:
> On 06/01/2012 06:29 PM, Jan Beulich wrote:
> 
>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>> wrote:
>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>>> suggests) is useful in the cpu bringup path.
>> 
>> This might not be correct - the code as it is without this change is
>> safe even when the vCPU gets onlined back later by an external
>> entity (e.g. the Xen tool stack), and it would in that case resume
>> at the return point of the VCPUOP_down hypercall. That might
>> be a heritage from the original XenoLinux tree though, and be
>> meaningless in pv-ops context - Jeremy, Konrad?
>> 
>> Possibly it was bogus/unused even in that original tree - Keir?
>>
> 
> 
> Thanks for your comments Jan!
> 
> In case this change is wrong, the other method I had in mind was to call
> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
> in the sense that it runs the cpu bringup code including cpu_idle(), in the
> cpu offline path, namely the cpu_die() function). Would that approach work
> for xen as well? If yes, then we wouldn't have any issues to convert xen to
> generic code.

No, that wouldn't work either afaict - the function is expected
to return.

Jan


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO4-0008P5-7W; Sat, 02 Jun 2012 13:29:00 +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 1SaTuJ-0006UR-Cq
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 15:36:55 +0000
Received: from [193.109.254.147:23500] by server-1.bemta-14.messagelabs.com id
	95/0D-07411-691E8CF4; Fri, 01 Jun 2012 15:36:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338565013!11525966!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12446 invoked from network); 1 Jun 2012 15:36:54 -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; 1 Jun 2012 15:36:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Jun 2012 16:36:30 +0100
Message-Id: <4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 01 Jun 2012 16:36:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
In-Reply-To: <4FC8DC19.4000007@linux.vnet.ibm.com>
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
wrote:
> On 06/01/2012 06:29 PM, Jan Beulich wrote:
> 
>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>> wrote:
>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>>> suggests) is useful in the cpu bringup path.
>> 
>> This might not be correct - the code as it is without this change is
>> safe even when the vCPU gets onlined back later by an external
>> entity (e.g. the Xen tool stack), and it would in that case resume
>> at the return point of the VCPUOP_down hypercall. That might
>> be a heritage from the original XenoLinux tree though, and be
>> meaningless in pv-ops context - Jeremy, Konrad?
>> 
>> Possibly it was bogus/unused even in that original tree - Keir?
>>
> 
> 
> Thanks for your comments Jan!
> 
> In case this change is wrong, the other method I had in mind was to call
> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
> in the sense that it runs the cpu bringup code including cpu_idle(), in the
> cpu offline path, namely the cpu_die() function). Would that approach work
> for xen as well? If yes, then we wouldn't have any issues to convert xen to
> generic code.

No, that wouldn't work either afaict - the function is expected
to return.

Jan


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO4-0008PC-JN; Sat, 02 Jun 2012 13:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddaney.cavm@gmail.com>) id 1SaVBz-0006sd-SJ
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 16:59:16 +0000
Received: from [85.158.143.99:7651] by server-1.bemta-4.messagelabs.com id
	E4/E4-27869-3E4F8CF4; Fri, 01 Jun 2012 16:59:15 +0000
X-Env-Sender: ddaney.cavm@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338569952!30401377!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6792 invoked from network); 1 Jun 2012 16:59:14 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jun 2012 16:59:14 -0000
Received: by dajz8 with SMTP id z8so3468097daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Jun 2012 09:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=wbLRlIRQ0gm2LiNUXyElqCgrygSzoMO1bWGOWHNTWAU=;
	b=k11OuMGjCTvzNh7rawnPmS2K5WIql00y9kaZD4WQWJLRXsPGND0H3p3rNDMwzRSM0G
	ph9Ir6uoyrpm6xkUHhCT8tSlwiqsQO9F9c/MhIsn9sTGqIFXIjjJ53CTARKetscIr19I
	tbuv0wxHjsSHXrjqd/x6QzNFMMQwZPGNFjQdNNpshZAN+BaWOzG0jDlNXn1Laf9gQuCH
	7IyKsU3xnUZB7WQE4QPFCSikauRaFAUU0g5B2CG+JfqZLffQgc+OVi3JozuYa5ljCUcC
	MglRUGNeeptRwGaVtNHLIJzApwoyVPCKbIJvthFKESUsrh5lLEmRf/E1quc1Fet+D1UQ
	Nbkg==
Received: by 10.68.240.105 with SMTP id vz9mr4905000pbc.119.1338569951304;
	Fri, 01 Jun 2012 09:59:11 -0700 (PDT)
Received: from dd1.caveonetworks.com (64.2.3.195.ptr.us.xo.net. [64.2.3.195])
	by mx.google.com with ESMTPS id
	ua6sm3303728pbc.20.2012.06.01.09.59.08 (version=SSLv3 cipher=OTHER);
	Fri, 01 Jun 2012 09:59:09 -0700 (PDT)
Message-ID: <4FC8F4DB.2070906@gmail.com>
Date: Fri, 01 Jun 2012 09:59:07 -0700
From: David Daney <ddaney.cavm@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10
MIME-Version: 1.0
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091038.31979.67878.stgit@srivatsabhat.in.ibm.com>
In-Reply-To: <20120601091038.31979.67878.stgit@srivatsabhat.in.ibm.com>
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: Venkatesh Pallipadi <venki@google.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
	peterz@infradead.org, Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	mingo@kernel.org, linux-arch@vger.kernel.org,
	xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	linux-sh@vger.kernel.org, x86@kernel.org,
	Ingo Molnar <mingo@redhat.com>, paulmck@linux.vnet.ibm.com,
	Fenghua Yu <fenghua.yu@intel.com>, Mike Frysinger <vapier@gentoo.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	rusty@rustcorp.com.au, Chris Metcalf <cmetcalf@tilera.com>,
	rjw@sisk.pl, yong.zhang0@gmail.com, tglx@linutronix.de,
	virtualization@lists.linux-foundation.org,
	Tony Luck <tony.luck@intel.com>, vatsa@linux.vnet.ibm.com,
	Ralf Baechle <ralf@linux-mips.org>,
	Paul Mundt <lethal@linux-sh.org>, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [Xen-devel] [PATCH 03/27] smpboot: Define and use cpu_state
 per-cpu variable in generic 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-Transfer-Encoding: 7bit
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/01/2012 02:10 AM, Srivatsa S. Bhat wrote:
> The per-cpu variable cpu_state is used in x86 and also used in other
> architectures, to track the state of the cpu during bringup and hotplug.
> Pull it out into generic code.
>
> Cc: Tony Luck<tony.luck@intel.com>
> Cc: Fenghua Yu<fenghua.yu@intel.com>
> Cc: Ralf Baechle<ralf@linux-mips.org>
> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> Cc: Paul Mundt<lethal@linux-sh.org>
> Cc: Chris Metcalf<cmetcalf@tilera.com>
> Cc: Thomas Gleixner<tglx@linutronix.de>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: "H. Peter Anvin"<hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
> Cc: Peter Zijlstra<a.p.zijlstra@chello.nl>
> Cc: Andrew Morton<akpm@linux-foundation.org>
> Cc: Mike Frysinger<vapier@gentoo.org>
> Cc: Yong Zhang<yong.zhang0@gmail.com>
> Cc: Venkatesh Pallipadi<venki@google.com>
> Cc: Suresh Siddha<suresh.b.siddha@intel.com>
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-sh@vger.kernel.org
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Srivatsa S. Bhat<srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
>   arch/ia64/include/asm/cpu.h   |    2 --
>   arch/ia64/kernel/process.c    |    1 +
>   arch/ia64/kernel/smpboot.c    |    6 +-----
>   arch/mips/cavium-octeon/smp.c |    4 +---
>   arch/powerpc/kernel/smp.c     |    6 +-----
>   arch/sh/include/asm/smp.h     |    2 --
>   arch/sh/kernel/smp.c          |    4 +---
>   arch/tile/kernel/smpboot.c    |    4 +---
>   arch/x86/include/asm/cpu.h    |    2 --
>   arch/x86/kernel/smpboot.c     |    4 +---
>   arch/x86/xen/smp.c            |    1 +
>   include/linux/smpboot.h       |    1 +
>   kernel/smpboot.c              |    4 ++++
>   13 files changed, 13 insertions(+), 28 deletions(-)
>
[...]
> diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
> index 97e7ce9..93cd4b0 100644
> --- a/arch/mips/cavium-octeon/smp.c
> +++ b/arch/mips/cavium-octeon/smp.c
> @@ -13,6 +13,7 @@
>   #include<linux/kernel_stat.h>
>   #include<linux/sched.h>
>   #include<linux/module.h>
> +#include<linux/smpboot.h>
>
>   #include<asm/mmu_context.h>
>   #include<asm/time.h>
> @@ -252,9 +253,6 @@ static void octeon_cpus_done(void)
>
>   #ifdef CONFIG_HOTPLUG_CPU
>
> -/* State of each CPU. */
> -DEFINE_PER_CPU(int, cpu_state);
> -
>   extern void fixup_irqs(void);
>
>   static DEFINE_SPINLOCK(smp_reserve_lock);

The Octeon bit:

Acked-by: David Daney <david.daney@cavium.com>


FWIW, the rest looks good too.

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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO4-0008PJ-VW; Sat, 02 Jun 2012 13:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Borislav.Petkov@amd.com>) id 1Saafk-00066I-24
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 22:50:20 +0000
Received: from [85.158.143.35:40579] by server-3.bemta-4.messagelabs.com id
	99/68-04252-B2749CF4; Fri, 01 Jun 2012 22:50:19 +0000
X-Env-Sender: Borislav.Petkov@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1338591017!14065242!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3300 invoked from network); 1 Jun 2012 22:50:17 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Jun 2012 22:50:17 -0000
Received: from mail39-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 22:49:45 +0000
Received: from mail39-am1 (localhost [127.0.0.1])	by mail39-am1-R.bigfish.com
	(Postfix) with ESMTP id CF8B080440;
	Fri,  1 Jun 2012 22:49:44 +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: -9
X-BigFish: VPS-9(zz1432N98dKzz1202hzzz2dh668h839h944hd25hf0ah)
Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1
	(MessageSwitch) id 1338590982372672_13788;
	Fri,  1 Jun 2012 22:49:42 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.237])	by
	mail39-am1.bigfish.com (Postfix) with ESMTP id 57F04220046;
	Fri,  1 Jun 2012 22:49:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 22:49:36 +0000
X-WSS-ID: 0M4YNFF-02-19T-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 22E2BC814E;	Fri,  1 Jun 2012 17:50:03 -0500 (CDT)
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, 1 Jun 2012 17:50:26 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 1 Jun 2012 17:50:04 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	18:50:03 -0400
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4847E49C69E; Fri,  1 Jun 2012
	23:50:02 +0100 (BST)
Date: Sat, 2 Jun 2012 00:50:30 +0200
From: Borislav Petkov <borislav.petkov@amd.com>
To: Yinghai Lu <yinghai@kernel.org>
Message-ID: <20120601225030.GC30418@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-3-git-send-email-bp@amd64.org>
	<CAE9FiQVad9qWvZeBej31Mw4aEJO3L0L6ZC7mx7VJQwRB_q8fzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE9FiQVad9qWvZeBej31Mw4aEJO3L0L6ZC7mx7VJQwRB_q8fzQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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 Fri, Jun 01, 2012 at 11:22:03AM -0700, Yinghai Lu wrote:
> can you double check if the range will need special passcode ?
> 
>         { 0x00000000, 0x00000418},
>         { 0xc0000000, 0xc000040b},
>         { 0xc0010000, 0xc0010142},
>         { 0xc0011000, 0xc001103b},
> 
> passcode should be
>        gprs[7] = 0x9c5a203a;

This currently reads the MSRs it can read without the passcode. There's
no reason I'm aware of to access the other MSRs.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 13:29:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 13: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 1SaoO4-0008PJ-VW; Sat, 02 Jun 2012 13:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Borislav.Petkov@amd.com>) id 1Saafk-00066I-24
	for xen-devel@lists.xensource.com; Fri, 01 Jun 2012 22:50:20 +0000
Received: from [85.158.143.35:40579] by server-3.bemta-4.messagelabs.com id
	99/68-04252-B2749CF4; Fri, 01 Jun 2012 22:50:19 +0000
X-Env-Sender: Borislav.Petkov@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1338591017!14065242!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3300 invoked from network); 1 Jun 2012 22:50:17 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Jun 2012 22:50:17 -0000
Received: from mail39-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 22:49:45 +0000
Received: from mail39-am1 (localhost [127.0.0.1])	by mail39-am1-R.bigfish.com
	(Postfix) with ESMTP id CF8B080440;
	Fri,  1 Jun 2012 22:49:44 +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: -9
X-BigFish: VPS-9(zz1432N98dKzz1202hzzz2dh668h839h944hd25hf0ah)
Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1
	(MessageSwitch) id 1338590982372672_13788;
	Fri,  1 Jun 2012 22:49:42 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.237])	by
	mail39-am1.bigfish.com (Postfix) with ESMTP id 57F04220046;
	Fri,  1 Jun 2012 22:49:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 1 Jun 2012 22:49:36 +0000
X-WSS-ID: 0M4YNFF-02-19T-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 22E2BC814E;	Fri,  1 Jun 2012 17:50:03 -0500 (CDT)
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, 1 Jun 2012 17:50:26 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 1 Jun 2012 17:50:04 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 1 Jun 2012
	18:50:03 -0400
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4847E49C69E; Fri,  1 Jun 2012
	23:50:02 +0100 (BST)
Date: Sat, 2 Jun 2012 00:50:30 +0200
From: Borislav Petkov <borislav.petkov@amd.com>
To: Yinghai Lu <yinghai@kernel.org>
Message-ID: <20120601225030.GC30418@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-3-git-send-email-bp@amd64.org>
	<CAE9FiQVad9qWvZeBej31Mw4aEJO3L0L6ZC7mx7VJQwRB_q8fzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE9FiQVad9qWvZeBej31Mw4aEJO3L0L6ZC7mx7VJQwRB_q8fzQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
X-Mailman-Approved-At: Sat, 02 Jun 2012 13:28:57 +0000
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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 Fri, Jun 01, 2012 at 11:22:03AM -0700, Yinghai Lu wrote:
> can you double check if the range will need special passcode ?
> 
>         { 0x00000000, 0x00000418},
>         { 0xc0000000, 0xc000040b},
>         { 0xc0010000, 0xc0010142},
>         { 0xc0011000, 0xc001103b},
> 
> passcode should be
>        gprs[7] = 0x9c5a203a;

This currently reads the MSRs it can read without the passcode. There's
no reason I'm aware of to access the other MSRs.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


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

From xen-devel-bounces@lists.xen.org Sat Jun 02 14:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 14: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 1Sap1I-0001Jt-CT; Sat, 02 Jun 2012 14:09:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sap1H-0001Jo-04
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 14:09:31 +0000
Received: from [85.158.138.51:39103] by server-2.bemta-3.messagelabs.com id
	9D/C7-17140-A9E1ACF4; Sat, 02 Jun 2012 14:09:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338646168!30569156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20443 invoked from network); 2 Jun 2012 14:09:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 14:09:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12799242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 14:09:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 2 Jun 2012 15:09:27 +0100
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 1Sap1D-0003Bt-7h;
	Sat, 02 Jun 2012 14:09:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sap1D-0006zz-2H;
	Sat, 02 Jun 2012 15:09:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13013-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 15:09:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13013: 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 13013 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13013/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13012

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  1e2ce970f0f2

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=6bea63e6c780
+ . 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 6bea63e6c780
+ branch=xen-unstable
+ revision=6bea63e6c780
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6bea63e6c780 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 Sat Jun 02 14:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 14: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 1Sap1I-0001Jt-CT; Sat, 02 Jun 2012 14:09:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sap1H-0001Jo-04
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 14:09:31 +0000
Received: from [85.158.138.51:39103] by server-2.bemta-3.messagelabs.com id
	9D/C7-17140-A9E1ACF4; Sat, 02 Jun 2012 14:09:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338646168!30569156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20443 invoked from network); 2 Jun 2012 14:09:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jun 2012 14:09:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="12799242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jun 2012 14:09:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 2 Jun 2012 15:09:27 +0100
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 1Sap1D-0003Bt-7h;
	Sat, 02 Jun 2012 14:09:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sap1D-0006zz-2H;
	Sat, 02 Jun 2012 15:09:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13013-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Jun 2012 15:09:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13013: 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 13013 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13013/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13012

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  1e2ce970f0f2

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=6bea63e6c780
+ . 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 6bea63e6c780
+ branch=xen-unstable
+ revision=6bea63e6c780
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6bea63e6c780 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 Sat Jun 02 14:19:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 14: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 1SapAa-0001WZ-Lq; Sat, 02 Jun 2012 14:19:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1SapAY-0001WU-MN
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 14:19:06 +0000
Received: from [193.109.254.147:58577] by server-11.bemta-14.messagelabs.com
	id 69/4F-01965-AD02ACF4; Sat, 02 Jun 2012 14:19:06 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338646745!4826039!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23167 invoked from network); 2 Jun 2012 14:19:05 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-7.tower-27.messagelabs.com with SMTP;
	2 Jun 2012 14:19:05 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 3992B1F880AD
	for <xen-devel@lists.xen.org>; Sat,  2 Jun 2012 10:21:45 -0400 (EDT)
Received: (qmail 11292 invoked by uid 108); 2 Jun 2012 10:19:04 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.189.210.134)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 2 Jun 2012 10:19:04 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 8B5868121A9; Sat,  2 Jun 2012 09:19:03 -0500 (CDT)
Date: Sat, 2 Jun 2012 09:19:03 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120602141903.GA2903@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20425.863.785362.721748@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Using "xl create" without domain 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

>> I found it useful to use xm without a domain configuration file:
>> 
>> 	xm create /dev/null kernel=...
>> 
>> The xl command does not support this. See a previous thread I started:
>> 
>> 	http://lists.xen.org/archives/html/xen-devel/2011-08/msg00330.html
 
> I would be happy to support the /dev/null form.

This patch supports the /dev/null form.

# HG changeset patch
# Parent 435493696053a079ec17d6e1a63e5f2be3a2c9d0
xl: Allow use of /dev/null with xl create to enable command-line definition

xm allows specifying /dev/null as the domain configuration argument
to its create option; add same functionality to xl. Whereas xl used to
check to ensure the domain configuration argument was a regular file,
it now checks to ensure it is not a directory. This allows specifying
an entire domain configuration on the command line.

Signed-off-by: W. Michael Petullo <mike@flyn.org>

diff -r 435493696053 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Fri May 25 08:18:47 2012 +0100
+++ b/tools/libxl/libxl_utils.c	Sat Jun 02 09:11:27 2012 -0500
@@ -324,8 +324,8 @@ int libxl_read_file_contents(libxl_ctx *
         goto xe;
     }
 
-    if (!S_ISREG(stab.st_mode)) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
+    if (S_ISDIR(stab.st_mode)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);
         errno = ENOTTY;
         goto xe;
     }

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

From xen-devel-bounces@lists.xen.org Sat Jun 02 14:19:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Jun 2012 14: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 1SapAa-0001WZ-Lq; Sat, 02 Jun 2012 14:19:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1SapAY-0001WU-MN
	for xen-devel@lists.xen.org; Sat, 02 Jun 2012 14:19:06 +0000
Received: from [193.109.254.147:58577] by server-11.bemta-14.messagelabs.com
	id 69/4F-01965-AD02ACF4; Sat, 02 Jun 2012 14:19:06 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338646745!4826039!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23167 invoked from network); 2 Jun 2012 14:19:05 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-7.tower-27.messagelabs.com with SMTP;
	2 Jun 2012 14:19:05 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 3992B1F880AD
	for <xen-devel@lists.xen.org>; Sat,  2 Jun 2012 10:21:45 -0400 (EDT)
Received: (qmail 11292 invoked by uid 108); 2 Jun 2012 10:19:04 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.189.210.134)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 2 Jun 2012 10:19:04 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 8B5868121A9; Sat,  2 Jun 2012 09:19:03 -0500 (CDT)
Date: Sat, 2 Jun 2012 09:19:03 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120602141903.GA2903@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20425.863.785362.721748@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Using "xl create" without domain 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

>> I found it useful to use xm without a domain configuration file:
>> 
>> 	xm create /dev/null kernel=...
>> 
>> The xl command does not support this. See a previous thread I started:
>> 
>> 	http://lists.xen.org/archives/html/xen-devel/2011-08/msg00330.html
 
> I would be happy to support the /dev/null form.

This patch supports the /dev/null form.

# HG changeset patch
# Parent 435493696053a079ec17d6e1a63e5f2be3a2c9d0
xl: Allow use of /dev/null with xl create to enable command-line definition

xm allows specifying /dev/null as the domain configuration argument
to its create option; add same functionality to xl. Whereas xl used to
check to ensure the domain configuration argument was a regular file,
it now checks to ensure it is not a directory. This allows specifying
an entire domain configuration on the command line.

Signed-off-by: W. Michael Petullo <mike@flyn.org>

diff -r 435493696053 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Fri May 25 08:18:47 2012 +0100
+++ b/tools/libxl/libxl_utils.c	Sat Jun 02 09:11:27 2012 -0500
@@ -324,8 +324,8 @@ int libxl_read_file_contents(libxl_ctx *
         goto xe;
     }
 
-    if (!S_ISREG(stab.st_mode)) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
+    if (S_ISDIR(stab.st_mode)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);
         errno = ENOTTY;
         goto xe;
     }

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

From xen-devel-bounces@lists.xen.org Sun Jun 03 06:13:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Jun 2012 06:13: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 1Sb43w-00020f-6y; Sun, 03 Jun 2012 06:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sb43u-00020a-Fi
	for xen-devel@lists.xensource.com; Sun, 03 Jun 2012 06:13:14 +0000
Received: from [85.158.143.99:60595] by server-2.bemta-4.messagelabs.com id
	9C/36-11595-9700BCF4; Sun, 03 Jun 2012 06:13:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338703992!24549478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14729 invoked from network); 3 Jun 2012 06:13:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jun 2012 06:13:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,706,1330905600"; d="scan'208";a="12804618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jun 2012 06: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.213.0; Sun, 3 Jun 2012 07:12:45 +0100
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 1Sb43Q-0008F4-I3;
	Sun, 03 Jun 2012 06:12:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sb43N-0005ef-E8;
	Sun, 03 Jun 2012 07:12:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13014-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Jun 2012 07:12:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13014: 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 13014 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13014/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 13013

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13013

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Sun Jun 03 06:13:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Jun 2012 06:13: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 1Sb43w-00020f-6y; Sun, 03 Jun 2012 06:13:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sb43u-00020a-Fi
	for xen-devel@lists.xensource.com; Sun, 03 Jun 2012 06:13:14 +0000
Received: from [85.158.143.99:60595] by server-2.bemta-4.messagelabs.com id
	9C/36-11595-9700BCF4; Sun, 03 Jun 2012 06:13:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338703992!24549478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14729 invoked from network); 3 Jun 2012 06:13:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jun 2012 06:13:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,706,1330905600"; d="scan'208";a="12804618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jun 2012 06: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.213.0; Sun, 3 Jun 2012 07:12:45 +0100
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 1Sb43Q-0008F4-I3;
	Sun, 03 Jun 2012 06:12:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sb43N-0005ef-E8;
	Sun, 03 Jun 2012 07:12:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13014-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Jun 2012 07:12:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13014: 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 13014 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13014/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 13013

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13013

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Sun Jun 03 12:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Jun 2012 12:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sb9c6-00072l-G8; Sun, 03 Jun 2012 12:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1Sasj5-0004rt-7d
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 18:06:59 +0000
Received: from [85.158.143.35:40051] by server-1.bemta-4.messagelabs.com id
	8F/89-27869-2465ACF4; Sat, 02 Jun 2012 18:06:58 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1338660415!17271214!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAyMTA4MDY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3350 invoked from network); 2 Jun 2012 18:06:57 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Jun 2012 18:06:57 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Sat, 2 Jun 2012 23:36:53 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 2 Jun 2012 23:36:50 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q52I6n9t4653434
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 23:36:50 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q52NaPhE027848
	for <xen-devel@lists.xensource.com>; Sun, 3 Jun 2012 05:06:26 +0530
Received: from [9.79.246.89] ([9.79.246.89])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q52NaKPh027800; Sun, 3 Jun 2012 05:06:21 +0530
Message-ID: <4FCA5608.2010404@linux.vnet.ibm.com>
Date: Sat, 02 Jun 2012 23:36:00 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
In-Reply-To: <4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
x-cbid: 12060218-3864-0000-0000-00000328EB06
X-Mailman-Approved-At: Sun, 03 Jun 2012 12:08:53 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 09:06 PM, Jan Beulich wrote:

>>>> On 01.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> wrote:
>> On 06/01/2012 06:29 PM, Jan Beulich wrote:
>>
>>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>> wrote:
>>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>>>> suggests) is useful in the cpu bringup path.
>>>
>>> This might not be correct - the code as it is without this change is
>>> safe even when the vCPU gets onlined back later by an external
>>> entity (e.g. the Xen tool stack), and it would in that case resume
>>> at the return point of the VCPUOP_down hypercall. That might
>>> be a heritage from the original XenoLinux tree though, and be
>>> meaningless in pv-ops context - Jeremy, Konrad?
>>>
>>> Possibly it was bogus/unused even in that original tree - Keir?
>>>
>>
>>
>> Thanks for your comments Jan!
>>
>> In case this change is wrong, the other method I had in mind was to call
>> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
>> in the sense that it runs the cpu bringup code including cpu_idle(), in the
>> cpu offline path, namely the cpu_die() function). Would that approach work
>> for xen as well? If yes, then we wouldn't have any issues to convert xen to
>> generic code.
> 
> No, that wouldn't work either afaict - the function is expected
> to return.
> 


Ok.. So, I would love to hear a confirmation about whether this patch (which
removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.

If its not correct, then we can probably make __cpu_post_online() return an int,
with the meaning:

0 => success, go ahead and call cpu_idle()
non-zero => stop here, thanks for your services so far.. now leave the rest to me.

So all other archs will return 0, Xen will return non-zero, and it will handle
when to call cpu_idle() and when not to do so.

Might sound a bit ugly, but I don't see much other option. Suggestions are
appreciated!

Regards,
Srivatsa S. Bhat


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

From xen-devel-bounces@lists.xen.org Sun Jun 03 12:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Jun 2012 12:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sb9c6-00072l-G8; Sun, 03 Jun 2012 12:08:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1Sasj5-0004rt-7d
	for xen-devel@lists.xensource.com; Sat, 02 Jun 2012 18:06:59 +0000
Received: from [85.158.143.35:40051] by server-1.bemta-4.messagelabs.com id
	8F/89-27869-2465ACF4; Sat, 02 Jun 2012 18:06:58 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1338660415!17271214!1
X-Originating-IP: [122.248.162.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAyMTA4MDY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3350 invoked from network); 2 Jun 2012 18:06:57 -0000
Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Jun 2012 18:06:57 -0000
Received: from /spool/local
	by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Sat, 2 Jun 2012 23:36:53 +0530
Received: from d28relay03.in.ibm.com (9.184.220.60)
	by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 2 Jun 2012 23:36:50 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q52I6n9t4653434
	for <xen-devel@lists.xensource.com>; Sat, 2 Jun 2012 23:36:50 +0530
Received: from d28av01.in.ibm.com (loopback [127.0.0.1])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q52NaPhE027848
	for <xen-devel@lists.xensource.com>; Sun, 3 Jun 2012 05:06:26 +0530
Received: from [9.79.246.89] ([9.79.246.89])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q52NaKPh027800; Sun, 3 Jun 2012 05:06:21 +0530
Message-ID: <4FCA5608.2010404@linux.vnet.ibm.com>
Date: Sat, 02 Jun 2012 23:36:00 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
In-Reply-To: <4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
x-cbid: 12060218-3864-0000-0000-00000328EB06
X-Mailman-Approved-At: Sun, 03 Jun 2012 12:08:53 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/2012 09:06 PM, Jan Beulich wrote:

>>>> On 01.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> wrote:
>> On 06/01/2012 06:29 PM, Jan Beulich wrote:
>>
>>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>> wrote:
>>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>>>> suggests) is useful in the cpu bringup path.
>>>
>>> This might not be correct - the code as it is without this change is
>>> safe even when the vCPU gets onlined back later by an external
>>> entity (e.g. the Xen tool stack), and it would in that case resume
>>> at the return point of the VCPUOP_down hypercall. That might
>>> be a heritage from the original XenoLinux tree though, and be
>>> meaningless in pv-ops context - Jeremy, Konrad?
>>>
>>> Possibly it was bogus/unused even in that original tree - Keir?
>>>
>>
>>
>> Thanks for your comments Jan!
>>
>> In case this change is wrong, the other method I had in mind was to call
>> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
>> in the sense that it runs the cpu bringup code including cpu_idle(), in the
>> cpu offline path, namely the cpu_die() function). Would that approach work
>> for xen as well? If yes, then we wouldn't have any issues to convert xen to
>> generic code.
> 
> No, that wouldn't work either afaict - the function is expected
> to return.
> 


Ok.. So, I would love to hear a confirmation about whether this patch (which
removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.

If its not correct, then we can probably make __cpu_post_online() return an int,
with the meaning:

0 => success, go ahead and call cpu_idle()
non-zero => stop here, thanks for your services so far.. now leave the rest to me.

So all other archs will return 0, Xen will return non-zero, and it will handle
when to call cpu_idle() and when not to do so.

Might sound a bit ugly, but I don't see much other option. Suggestions are
appreciated!

Regards,
Srivatsa S. Bhat


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

From xen-devel-bounces@lists.xen.org Mon Jun 04 06:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 06:25: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 1SbQiE-00087l-On; Mon, 04 Jun 2012 06:24:22 +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 1SbQiD-00087g-Ak
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 06:24:21 +0000
Received: from [193.109.254.147:17250] by server-6.bemta-14.messagelabs.com id
	C6/BF-10397-4945CCF4; Mon, 04 Jun 2012 06:24:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338791060!4750120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7669 invoked from network); 4 Jun 2012 06:24:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 06:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,711,1330905600"; d="scan'208";a="12810814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jun 2012 06:24:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 4 Jun 2012 07:24:19 +0100
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 1SbQiB-0007ot-3G;
	Mon, 04 Jun 2012 06:24:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SbQiA-0001Wn-I6;
	Mon, 04 Jun 2012 07:24:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13015-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Jun 2012 07:24:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13015: 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 13015 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13015/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13014

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Mon Jun 04 06:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 06:25: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 1SbQiE-00087l-On; Mon, 04 Jun 2012 06:24:22 +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 1SbQiD-00087g-Ak
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 06:24:21 +0000
Received: from [193.109.254.147:17250] by server-6.bemta-14.messagelabs.com id
	C6/BF-10397-4945CCF4; Mon, 04 Jun 2012 06:24:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338791060!4750120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7669 invoked from network); 4 Jun 2012 06:24:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 06:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,711,1330905600"; d="scan'208";a="12810814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jun 2012 06:24:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 4 Jun 2012 07:24:19 +0100
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 1SbQiB-0007ot-3G;
	Mon, 04 Jun 2012 06:24:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SbQiA-0001Wn-I6;
	Mon, 04 Jun 2012 07:24:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13015-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Jun 2012 07:24:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13015: 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 13015 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13015/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13014

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Mon Jun 04 06:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 06: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 1SbQmv-0008EA-HA; Mon, 04 Jun 2012 06:29:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1SbQmt-0008E4-Iq
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 06:29:11 +0000
Received: from [85.158.139.83:53371] by server-6.bemta-5.messagelabs.com id
	9F/E9-18700-6B55CCF4; Mon, 04 Jun 2012 06:29:10 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338791349!29158167!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ1OTY1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4628 invoked from network); 4 Jun 2012 06:29:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-182.messagelabs.com with SMTP;
	4 Jun 2012 06:29:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 03 Jun 2012 23:29:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="107404659"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 03 Jun 2012 23:29:07 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 3 Jun 2012 23:29:07 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.56]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.93]) with mapi id
	14.01.0355.002; Mon, 4 Jun 2012 14:29:07 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:25429 & Dom0:76f901e...
Thread-Index: AQHNQhtYNShM+aq5VUKy3haWrIp2Dw==
Date: Mon, 4 Jun 2012 06:29:07 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FD52515@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:25429 & Dom0:76f901e...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree. 
There is one new issue and no issue got fixed.

Version Info:
=================================================================
xen-changeset:   25429:a120d24f90fb
Dom0:          linux.git  3.4.0 (commit: 76f901e...) 
=================================================================

New issue(1)
==============
1. Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824

Fixed issue(0)
==============

Old issues(11)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. [VT-D] device reset fail when create/destroy guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752
6. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
7. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
8. cpu weight out of range error when create hvm domU
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818
9. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
10. long stop during the guest boot process with qcow image
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
11. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822

Thanks,
Zhou, Chao

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

From xen-devel-bounces@lists.xen.org Mon Jun 04 06:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 06: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 1SbQmv-0008EA-HA; Mon, 04 Jun 2012 06:29:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1SbQmt-0008E4-Iq
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 06:29:11 +0000
Received: from [85.158.139.83:53371] by server-6.bemta-5.messagelabs.com id
	9F/E9-18700-6B55CCF4; Mon, 04 Jun 2012 06:29:10 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338791349!29158167!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ1OTY1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4628 invoked from network); 4 Jun 2012 06:29:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-4.tower-182.messagelabs.com with SMTP;
	4 Jun 2012 06:29:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 03 Jun 2012 23:29:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="107404659"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 03 Jun 2012 23:29:07 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 3 Jun 2012 23:29:07 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.56]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.93]) with mapi id
	14.01.0355.002; Mon, 4 Jun 2012 14:29:07 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:25429 & Dom0:76f901e...
Thread-Index: AQHNQhtYNShM+aq5VUKy3haWrIp2Dw==
Date: Mon, 4 Jun 2012 06:29:07 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FD52515@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:25429 & Dom0:76f901e...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree. 
There is one new issue and no issue got fixed.

Version Info:
=================================================================
xen-changeset:   25429:a120d24f90fb
Dom0:          linux.git  3.4.0 (commit: 76f901e...) 
=================================================================

New issue(1)
==============
1. Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824

Fixed issue(0)
==============

Old issues(11)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. [VT-D] device reset fail when create/destroy guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752
6. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
7. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
8. cpu weight out of range error when create hvm domU
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818
9. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
10. long stop during the guest boot process with qcow image
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
11. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822

Thanks,
Zhou, Chao

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

From xen-devel-bounces@lists.xen.org Mon Jun 04 08:35:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 08: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 1SbSkL-0000s7-8q; Mon, 04 Jun 2012 08:34:41 +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 1SbSkJ-0000s2-EQ
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 08:34:39 +0000
Received: from [193.109.254.147:24026] by server-7.bemta-14.messagelabs.com id
	CD/C5-07635-E137CCF4; Mon, 04 Jun 2012 08:34:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338798877!11809613!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8823 invoked from network); 4 Jun 2012 08:34:38 -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; 4 Jun 2012 08:34:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Jun 2012 09:34:37 +0100
Message-Id: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 04 Jun 2012 09:34:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part92BC1C0A.0__="
Subject: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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>
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.

--=__Part92BC1C0A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
os-posix.c:os_find_datadir() works. While one would generally expect
that function to honour the --datadir configure option, fixing this is
quite a bit more involved than simply adjusting the configure options
to match the function's behavior (in that, for an installed binary, it
looks in $bindir/../share/qemu). Afaict, so far this can have worked
only by virtue of what CONFIG_QEMU_DATADIR points to being populated
due to (presumably) some other qemu instance being installed on
people's systems (but being absent when running qemu-system-i386 from
the dist/ portion of the build tree).

Signed-off-by: Jan Beulich <JBeulich@suse.com>

--- a/tools/Makefile
+++ b/tools/Makefile
@@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
 		--extra-ldflags=3D"-L$(XEN_ROOT)/tools/libxc \
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=3D$(LIBEXEC) \
-		--datadir=3D$(SHAREDIR)/qemu-xen \
+		--datadir=3D$(dir $(LIBEXEC))share/qemu \
 		--disable-kvm \
 		--python=3D$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \




--=__Part92BC1C0A.0__=
Content-Type: text/plain; name="tools-qemu-upstream-config.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tools-qemu-upstream-config.patch"

tools: adjust --datadir option passed to qemu-upstream's configure =
script=0A=0APassing $(SHAREDIR)/qemu-xen isn't compatible with the =
way=0Aos-posix.c:os_find_datadir() works. While one would generally =
expect=0Athat function to honour the --datadir configure option, fixing =
this is=0Aquite a bit more involved than simply adjusting the configure =
options=0Ato match the function's behavior (in that, for an installed =
binary, it=0Alooks in $bindir/../share/qemu). Afaict, so far this can have =
worked=0Aonly by virtue of what CONFIG_QEMU_DATADIR points to being =
populated=0Adue to (presumably) some other qemu instance being installed =
on=0Apeople's systems (but being absent when running qemu-system-i386 =
from=0Athe dist/ portion of the build tree).=0A=0ASigned-off-by: Jan =
Beulich <JBeulich@suse.com>=0A=0A--- a/tools/Makefile=0A+++ b/tools/Makefil=
e=0A@@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q=0A 		=
--extra-ldflags=3D"-L$(XEN_ROOT)/tools/libxc \=0A 		-L$(XEN_ROO=
T)/tools/xenstore" \=0A 		--bindir=3D$(LIBEXEC) \=0A-		=
--datadir=3D$(SHAREDIR)/qemu-xen \=0A+		--datadir=3D$(dir =
$(LIBEXEC))share/qemu \=0A 		--disable-kvm \=0A 		=
--python=3D$(PYTHON) \=0A 		$(IOEMU_CONFIGURE_CROSS); \=0A
--=__Part92BC1C0A.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

--=__Part92BC1C0A.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 04 08:35:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 08: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 1SbSkL-0000s7-8q; Mon, 04 Jun 2012 08:34:41 +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 1SbSkJ-0000s2-EQ
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 08:34:39 +0000
Received: from [193.109.254.147:24026] by server-7.bemta-14.messagelabs.com id
	CD/C5-07635-E137CCF4; Mon, 04 Jun 2012 08:34:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338798877!11809613!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8823 invoked from network); 4 Jun 2012 08:34:38 -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; 4 Jun 2012 08:34:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Jun 2012 09:34:37 +0100
Message-Id: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 04 Jun 2012 09:34:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part92BC1C0A.0__="
Subject: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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>
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.

--=__Part92BC1C0A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
os-posix.c:os_find_datadir() works. While one would generally expect
that function to honour the --datadir configure option, fixing this is
quite a bit more involved than simply adjusting the configure options
to match the function's behavior (in that, for an installed binary, it
looks in $bindir/../share/qemu). Afaict, so far this can have worked
only by virtue of what CONFIG_QEMU_DATADIR points to being populated
due to (presumably) some other qemu instance being installed on
people's systems (but being absent when running qemu-system-i386 from
the dist/ portion of the build tree).

Signed-off-by: Jan Beulich <JBeulich@suse.com>

--- a/tools/Makefile
+++ b/tools/Makefile
@@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
 		--extra-ldflags=3D"-L$(XEN_ROOT)/tools/libxc \
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=3D$(LIBEXEC) \
-		--datadir=3D$(SHAREDIR)/qemu-xen \
+		--datadir=3D$(dir $(LIBEXEC))share/qemu \
 		--disable-kvm \
 		--python=3D$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \




--=__Part92BC1C0A.0__=
Content-Type: text/plain; name="tools-qemu-upstream-config.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tools-qemu-upstream-config.patch"

tools: adjust --datadir option passed to qemu-upstream's configure =
script=0A=0APassing $(SHAREDIR)/qemu-xen isn't compatible with the =
way=0Aos-posix.c:os_find_datadir() works. While one would generally =
expect=0Athat function to honour the --datadir configure option, fixing =
this is=0Aquite a bit more involved than simply adjusting the configure =
options=0Ato match the function's behavior (in that, for an installed =
binary, it=0Alooks in $bindir/../share/qemu). Afaict, so far this can have =
worked=0Aonly by virtue of what CONFIG_QEMU_DATADIR points to being =
populated=0Adue to (presumably) some other qemu instance being installed =
on=0Apeople's systems (but being absent when running qemu-system-i386 =
from=0Athe dist/ portion of the build tree).=0A=0ASigned-off-by: Jan =
Beulich <JBeulich@suse.com>=0A=0A--- a/tools/Makefile=0A+++ b/tools/Makefil=
e=0A@@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q=0A 		=
--extra-ldflags=3D"-L$(XEN_ROOT)/tools/libxc \=0A 		-L$(XEN_ROO=
T)/tools/xenstore" \=0A 		--bindir=3D$(LIBEXEC) \=0A-		=
--datadir=3D$(SHAREDIR)/qemu-xen \=0A+		--datadir=3D$(dir =
$(LIBEXEC))share/qemu \=0A 		--disable-kvm \=0A 		=
--python=3D$(PYTHON) \=0A 		$(IOEMU_CONFIGURE_CROSS); \=0A
--=__Part92BC1C0A.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

--=__Part92BC1C0A.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 04 13:10:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 13: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 1SbX2j-0002LE-09; Mon, 04 Jun 2012 13:09:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SbX2g-0002L9-QN
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 13:09:55 +0000
Received: from [193.109.254.147:26641] by server-9.bemta-14.messagelabs.com id
	77/98-28098-2A3BCCF4; Mon, 04 Jun 2012 13:09:54 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338815393!5906121!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15416 invoked from network); 4 Jun 2012 13:09:53 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jun 2012 13:09:53 -0000
Received: from mail54-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 13:09:13 +0000
Received: from mail54-db3 (localhost [127.0.0.1])	by mail54-db3-R.bigfish.com
	(Postfix) with ESMTP id 832FC801FF;
	Mon,  4 Jun 2012 13:09:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzzz2dh668h839h93fhd25he5bhf0ah)
Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3
	(MessageSwitch) id 1338815351140626_15989;
	Mon,  4 Jun 2012 13:09:11 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.229])	by
	mail54-db3.bigfish.com (Postfix) with ESMTP id 1665020120;
	Mon,  4 Jun 2012 13:09:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 13:09:10 +0000
X-WSS-ID: 0M53GK9-01-077-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F0D7102815D;	Mon,  4 Jun 2012 08:09:44 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 4 Jun 2012 08:09:50 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Mon, 4 Jun 2012 08:09:45 -0500
Received: from donner.osrc.amd.com (165.204.15.15) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 4 Jun 2012
	09:09:44 -0400
Message-ID: <4FCCB3FB.5080504@amd.com>
Date: Mon, 4 Jun 2012 15:11:23 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0a338fd74bab9eaeea74.1337873876@Solace>
	<1337939090.22311.22.camel@zakaz.uk.xensource.com>
	<1337941600.5761.19.camel@Solace>
	<1337942163.22311.27.camel@zakaz.uk.xensource.com>
	<20415.26393.141418.446541@mariner.uk.xensource.com>
	<1337951405.26090.2.camel@Solace>
	<1337954436.22311.37.camel@zakaz.uk.xensource.com>
In-Reply-To: <1337954436.22311.37.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/25/12 16:00, Ian Campbell wrote:

> On Fri, 2012-05-25 at 14:10 +0100, Dario Faggioli wrote:
>> On Fri, 2012-05-25 at 12:03 +0100, Ian Jackson wrote:
>>> Ian Campbell writes ("Re: [PATCH v4] libxl: introduce LIBXL_DOMAIN_TYPE_INVALID"):
>>>> so having arranged to call that function at the right time we can assume
>>>> that type is a sensible value, and indeed setdefault makes this the
>>>> case.
>>>
>>> Right.
>>>
>> Ok.
>>
>>> The other situation where we can get _INVALID is if libxl__domain_type
>>> fails, which it can do.
>>>
>>> I think this should be handled by having places which call
>>> libxl__domain_type abandon operation and return an error if the
>>> libxl__domain_type fails.
>>>
>>> If this is done, then general variables, parameters, etc. within libxl
>>> which are supposed to contain a libxl_domain_type will never contain
>>> _INVALID.
>>>
>> I like this. I'll chase each call to that function and have the calle
>> failing if a DOMAIN_TYPE_INVALID is returned. Then, if I go this way,
>> can I also nuke both the 'case DOMAIN_TYPE_INVALID' _and_ the default
>> clauses from everywhere? I seem to think I could...
> 
> iff the compiler is smart enough to realise that in the type == INVALID
> case you have returned already before reaching the switch statement,
> otherwise you will need to have "case INVALID: abort()".


What is latest status of this patch? When will it go upstream?

> 
>>
>> Thanks and Regards,
>> Daio


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

From xen-devel-bounces@lists.xen.org Mon Jun 04 13:10:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 13: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 1SbX2j-0002LE-09; Mon, 04 Jun 2012 13:09:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SbX2g-0002L9-QN
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 13:09:55 +0000
Received: from [193.109.254.147:26641] by server-9.bemta-14.messagelabs.com id
	77/98-28098-2A3BCCF4; Mon, 04 Jun 2012 13:09:54 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338815393!5906121!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15416 invoked from network); 4 Jun 2012 13:09:53 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jun 2012 13:09:53 -0000
Received: from mail54-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 13:09:13 +0000
Received: from mail54-db3 (localhost [127.0.0.1])	by mail54-db3-R.bigfish.com
	(Postfix) with ESMTP id 832FC801FF;
	Mon,  4 Jun 2012 13:09:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzzz2dh668h839h93fhd25he5bhf0ah)
Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3
	(MessageSwitch) id 1338815351140626_15989;
	Mon,  4 Jun 2012 13:09:11 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.229])	by
	mail54-db3.bigfish.com (Postfix) with ESMTP id 1665020120;
	Mon,  4 Jun 2012 13:09:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 13:09:10 +0000
X-WSS-ID: 0M53GK9-01-077-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F0D7102815D;	Mon,  4 Jun 2012 08:09:44 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 4 Jun 2012 08:09:50 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Mon, 4 Jun 2012 08:09:45 -0500
Received: from donner.osrc.amd.com (165.204.15.15) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 4 Jun 2012
	09:09:44 -0400
Message-ID: <4FCCB3FB.5080504@amd.com>
Date: Mon, 4 Jun 2012 15:11:23 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0a338fd74bab9eaeea74.1337873876@Solace>
	<1337939090.22311.22.camel@zakaz.uk.xensource.com>
	<1337941600.5761.19.camel@Solace>
	<1337942163.22311.27.camel@zakaz.uk.xensource.com>
	<20415.26393.141418.446541@mariner.uk.xensource.com>
	<1337951405.26090.2.camel@Solace>
	<1337954436.22311.37.camel@zakaz.uk.xensource.com>
In-Reply-To: <1337954436.22311.37.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/25/12 16:00, Ian Campbell wrote:

> On Fri, 2012-05-25 at 14:10 +0100, Dario Faggioli wrote:
>> On Fri, 2012-05-25 at 12:03 +0100, Ian Jackson wrote:
>>> Ian Campbell writes ("Re: [PATCH v4] libxl: introduce LIBXL_DOMAIN_TYPE_INVALID"):
>>>> so having arranged to call that function at the right time we can assume
>>>> that type is a sensible value, and indeed setdefault makes this the
>>>> case.
>>>
>>> Right.
>>>
>> Ok.
>>
>>> The other situation where we can get _INVALID is if libxl__domain_type
>>> fails, which it can do.
>>>
>>> I think this should be handled by having places which call
>>> libxl__domain_type abandon operation and return an error if the
>>> libxl__domain_type fails.
>>>
>>> If this is done, then general variables, parameters, etc. within libxl
>>> which are supposed to contain a libxl_domain_type will never contain
>>> _INVALID.
>>>
>> I like this. I'll chase each call to that function and have the calle
>> failing if a DOMAIN_TYPE_INVALID is returned. Then, if I go this way,
>> can I also nuke both the 'case DOMAIN_TYPE_INVALID' _and_ the default
>> clauses from everywhere? I seem to think I could...
> 
> iff the compiler is smart enough to realise that in the type == INVALID
> case you have returned already before reaching the switch statement,
> otherwise you will need to have "case INVALID: abort()".


What is latest status of this patch? When will it go upstream?

> 
>>
>> Thanks and Regards,
>> Daio


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

From xen-devel-bounces@lists.xen.org Mon Jun 04 14:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 14:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SbXqf-0002hy-Cq; Mon, 04 Jun 2012 14:01:33 +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 1SbXqd-0002ht-Fq
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 14:01:31 +0000
Received: from [85.158.143.99:44588] by server-1.bemta-4.messagelabs.com id
	4C/09-27869-ABFBCCF4; Mon, 04 Jun 2012 14:01:30 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338818489!28942130!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10077 invoked from network); 4 Jun 2012 14:01:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 14:01:29 -0000
Received: by wgbed3 with SMTP id ed3so2981476wgb.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 07:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=ttXiu5IJTlrHU3JNizCU548GMHMZTJzE63MEqwD9RLw=;
	b=pBsc391ydCwYxc3rBcRiF3gUxH3t4cedWYBXFza8rEt5kljXniUSnGfKffm6L8kIeE
	K6Uw8R7N0Edpn5aHbzusNQrKbdIK4qsUnTbvefgt5/gfZXOPIO583ATfTiU6yBekPkTA
	d7z8+d78sgOhQBa+vvvpExZh87BzdwCxBN3x/0h/WSq/+grSaK26fJbWfeNcEFvC9owz
	ZpycWalFTnHWBdh7fo7m4TzuT9mnFZVDxqHjJjxbO2G+egvuhZs4/BY5r1AjBCe4syRw
	bP69A8hkiMY9kzN/nRUQIEHnxtRmQbTSpEhLicJcf/g4XmCOX9ydWxgDT/fOftukC6Iu
	dOVA==
Received: by 10.216.203.80 with SMTP id e58mr10412234weo.41.1338818488233;
	Mon, 04 Jun 2012 07:01:28 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id f19sm32600654wiw.11.2012.06.04.07.01.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 04 Jun 2012 07:01:26 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 3eadab19abd49fbc6f562e6c9d86c4b1d0cf6bd8
Message-Id: <3eadab19abd49fbc6f56.1338818483@Solace>
User-Agent: Mercurial-patchbomb/2.2.1
Date: Mon, 04 Jun 2012 16:01:23 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org, xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] xl: check for meaningful combination of sedf
 config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 do it in the implementation of `xl sched-sedf -d ...', some
consistency checking is needed while parsing the sedf scheduling
parameters provided via config file. Not doing this results in the call
libxl_domain_sched_params_set() to fail, and no parameters being
enforced for the domain.

Note we do this at config file parsing time as that gives us the chance
of bailing out early. It would have been pointless to add it within
sched_sedf_domain_set() (in libxl), as the very same thing is
done in the hypervisor, and the result is being checked and returned
to the caller already.

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

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
@@ -561,6 +561,7 @@ static void parse_config_data(const char
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    int opt_w = 0, opt_p = 0, opt_s = 0;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
     int pci_permissive = 0;
@@ -632,18 +633,36 @@ static void parse_config_data(const char
 
     /* the following is the actual config parsing with overriding
      * values in the structures */
-    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) {
         b_info->sched_params.weight = l;
+        opt_w = 1;
+    }
     if (!xlu_cfg_get_long (config, "cap", &l, 0))
         b_info->sched_params.cap = l;
-    if (!xlu_cfg_get_long (config, "period", &l, 0))
+    if (!xlu_cfg_get_long (config, "period", &l, 0)) {
         b_info->sched_params.period = l;
-    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        opt_p = 1;
+    }
+    if (!xlu_cfg_get_long (config, "slice", &l, 0)) {
         b_info->sched_params.slice = l;
+        opt_s = 1;
+    }
     if (!xlu_cfg_get_long (config, "latency", &l, 0))
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
+    /* The sedf scheduler needs some more consistency checking */
+    if (opt_w && (opt_p || opt_s)) {
+        fprintf(stderr, "Either specify a weight OR a period and slice\n");
+        exit(1);
+    }
+    if (opt_w) {
+        b_info->sched_params.slice = 0;
+        b_info->sched_params.period = 0;
+    }
+    if (opt_p || opt_s)
+        b_info->sched_params.weight = 0;
+
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

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

From xen-devel-bounces@lists.xen.org Mon Jun 04 14:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 14:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SbXqf-0002hy-Cq; Mon, 04 Jun 2012 14:01:33 +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 1SbXqd-0002ht-Fq
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 14:01:31 +0000
Received: from [85.158.143.99:44588] by server-1.bemta-4.messagelabs.com id
	4C/09-27869-ABFBCCF4; Mon, 04 Jun 2012 14:01:30 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338818489!28942130!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10077 invoked from network); 4 Jun 2012 14:01:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 14:01:29 -0000
Received: by wgbed3 with SMTP id ed3so2981476wgb.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 07:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=ttXiu5IJTlrHU3JNizCU548GMHMZTJzE63MEqwD9RLw=;
	b=pBsc391ydCwYxc3rBcRiF3gUxH3t4cedWYBXFza8rEt5kljXniUSnGfKffm6L8kIeE
	K6Uw8R7N0Edpn5aHbzusNQrKbdIK4qsUnTbvefgt5/gfZXOPIO583ATfTiU6yBekPkTA
	d7z8+d78sgOhQBa+vvvpExZh87BzdwCxBN3x/0h/WSq/+grSaK26fJbWfeNcEFvC9owz
	ZpycWalFTnHWBdh7fo7m4TzuT9mnFZVDxqHjJjxbO2G+egvuhZs4/BY5r1AjBCe4syRw
	bP69A8hkiMY9kzN/nRUQIEHnxtRmQbTSpEhLicJcf/g4XmCOX9ydWxgDT/fOftukC6Iu
	dOVA==
Received: by 10.216.203.80 with SMTP id e58mr10412234weo.41.1338818488233;
	Mon, 04 Jun 2012 07:01:28 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id f19sm32600654wiw.11.2012.06.04.07.01.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 04 Jun 2012 07:01:26 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 3eadab19abd49fbc6f562e6c9d86c4b1d0cf6bd8
Message-Id: <3eadab19abd49fbc6f56.1338818483@Solace>
User-Agent: Mercurial-patchbomb/2.2.1
Date: Mon, 04 Jun 2012 16:01:23 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org, xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] xl: check for meaningful combination of sedf
 config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 do it in the implementation of `xl sched-sedf -d ...', some
consistency checking is needed while parsing the sedf scheduling
parameters provided via config file. Not doing this results in the call
libxl_domain_sched_params_set() to fail, and no parameters being
enforced for the domain.

Note we do this at config file parsing time as that gives us the chance
of bailing out early. It would have been pointless to add it within
sched_sedf_domain_set() (in libxl), as the very same thing is
done in the hypervisor, and the result is being checked and returned
to the caller already.

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

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
@@ -561,6 +561,7 @@ static void parse_config_data(const char
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    int opt_w = 0, opt_p = 0, opt_s = 0;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
     int pci_permissive = 0;
@@ -632,18 +633,36 @@ static void parse_config_data(const char
 
     /* the following is the actual config parsing with overriding
      * values in the structures */
-    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
+    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) {
         b_info->sched_params.weight = l;
+        opt_w = 1;
+    }
     if (!xlu_cfg_get_long (config, "cap", &l, 0))
         b_info->sched_params.cap = l;
-    if (!xlu_cfg_get_long (config, "period", &l, 0))
+    if (!xlu_cfg_get_long (config, "period", &l, 0)) {
         b_info->sched_params.period = l;
-    if (!xlu_cfg_get_long (config, "slice", &l, 0))
+        opt_p = 1;
+    }
+    if (!xlu_cfg_get_long (config, "slice", &l, 0)) {
         b_info->sched_params.slice = l;
+        opt_s = 1;
+    }
     if (!xlu_cfg_get_long (config, "latency", &l, 0))
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
+    /* The sedf scheduler needs some more consistency checking */
+    if (opt_w && (opt_p || opt_s)) {
+        fprintf(stderr, "Either specify a weight OR a period and slice\n");
+        exit(1);
+    }
+    if (opt_w) {
+        b_info->sched_params.slice = 0;
+        b_info->sched_params.period = 0;
+    }
+    if (opt_p || opt_s)
+        b_info->sched_params.weight = 0;
+
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

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

From xen-devel-bounces@lists.xen.org Mon Jun 04 14:04:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 14:04: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 1SbXt0-0002mm-U6; Mon, 04 Jun 2012 14: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@linux.it>) id 1SbXsz-0002me-2o
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 14:03:57 +0000
Received: from [85.158.143.35:30853] by server-3.bemta-4.messagelabs.com id
	9D/82-04252-C40CCCF4; Mon, 04 Jun 2012 14:03:56 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1338818617!7415719!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25562 invoked from network); 4 Jun 2012 14:03:37 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-21.messagelabs.com with SMTP;
	4 Jun 2012 14:03:37 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78628284; Mon, 04 Jun 2012 16:03:36 +0200
Message-ID: <1338818602.4344.3.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Mon, 04 Jun 2012 16:03:22 +0200
In-Reply-To: <4FCCB3FB.5080504@amd.com>
References: <0a338fd74bab9eaeea74.1337873876@Solace>
	<1337939090.22311.22.camel@zakaz.uk.xensource.com>
	<1337941600.5761.19.camel@Solace>
	<1337942163.22311.27.camel@zakaz.uk.xensource.com>
	<20415.26393.141418.446541@mariner.uk.xensource.com>
	<1337951405.26090.2.camel@Solace>
	<1337954436.22311.37.camel@zakaz.uk.xensource.com>
	<4FCCB3FB.5080504@amd.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Roger Pau Monne <roger.pau@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 v4] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7810173326436782013=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7810173326436782013==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-mwkXWKutFUepStU4UpoG"


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

On Mon, 2012-06-04 at 15:11 +0200, Christoph Egger wrote:
> What is latest status of this patch? When will it go upstream?
>=20
I'm resending a new version of it in a very short while... Let's see if
I manage in intercepting everyone's taste! :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-mwkXWKutFUepStU4UpoG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/MwCoACgkQk4XaBE3IOsSocgCfRLfb+dzMTQQtZCDO7BmQMMOQ
qJcAnizS0/zzP50PVizsE1q0JnxWHk7l
=109z
-----END PGP SIGNATURE-----

--=-mwkXWKutFUepStU4UpoG--



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

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

--===============7810173326436782013==--



From xen-devel-bounces@lists.xen.org Mon Jun 04 14:04:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 14:04: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 1SbXt0-0002mm-U6; Mon, 04 Jun 2012 14: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@linux.it>) id 1SbXsz-0002me-2o
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 14:03:57 +0000
Received: from [85.158.143.35:30853] by server-3.bemta-4.messagelabs.com id
	9D/82-04252-C40CCCF4; Mon, 04 Jun 2012 14:03:56 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1338818617!7415719!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25562 invoked from network); 4 Jun 2012 14:03:37 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-21.messagelabs.com with SMTP;
	4 Jun 2012 14:03:37 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78628284; Mon, 04 Jun 2012 16:03:36 +0200
Message-ID: <1338818602.4344.3.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Mon, 04 Jun 2012 16:03:22 +0200
In-Reply-To: <4FCCB3FB.5080504@amd.com>
References: <0a338fd74bab9eaeea74.1337873876@Solace>
	<1337939090.22311.22.camel@zakaz.uk.xensource.com>
	<1337941600.5761.19.camel@Solace>
	<1337942163.22311.27.camel@zakaz.uk.xensource.com>
	<20415.26393.141418.446541@mariner.uk.xensource.com>
	<1337951405.26090.2.camel@Solace>
	<1337954436.22311.37.camel@zakaz.uk.xensource.com>
	<4FCCB3FB.5080504@amd.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Roger Pau Monne <roger.pau@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 v4] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7810173326436782013=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7810173326436782013==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-mwkXWKutFUepStU4UpoG"


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

On Mon, 2012-06-04 at 15:11 +0200, Christoph Egger wrote:
> What is latest status of this patch? When will it go upstream?
>=20
I'm resending a new version of it in a very short while... Let's see if
I manage in intercepting everyone's taste! :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-mwkXWKutFUepStU4UpoG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/MwCoACgkQk4XaBE3IOsSocgCfRLfb+dzMTQQtZCDO7BmQMMOQ
qJcAnizS0/zzP50PVizsE1q0JnxWHk7l
=109z
-----END PGP SIGNATURE-----

--=-mwkXWKutFUepStU4UpoG--



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

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

--===============7810173326436782013==--



From xen-devel-bounces@lists.xen.org Mon Jun 04 16:37:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 16: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 1SbaGz-0003vD-8v; Mon, 04 Jun 2012 16:36:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SbaGx-0003v8-Pg
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 16:36:52 +0000
Received: from [85.158.138.51:33259] by server-7.bemta-3.messagelabs.com id
	AE/03-22601-224ECCF4; Mon, 04 Jun 2012 16:36:50 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338827808!30703580!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10913 invoked from network); 4 Jun 2012 16:36:50 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jun 2012 16:36:50 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SbaGu-0002xP-AL
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 09:36:48 -0700
Date: Mon, 4 Jun 2012 09:36:48 -0700 (PDT)
From: elahe <e.shekuhi@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1338827808312-5709267.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xen live vm migration 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

Hi everybody,

I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
migration does not work. While the source host works on the "xm migrate -l
..." command, I can see the VM on the target host in paused state in "xm
list", but after a while it vanishes while the xm command on the source
machine returns whitout any errors.

(One machine has core i7 processor while another is core 2 quad system).


 I have searched the net and this list and found a few posts mentioning this
error, but no solution, not even a hint
    on the source of the problem. 

Any help would be really appreciated. Thanks.

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-live-vm-migration-error-tp5709267.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xen.org Mon Jun 04 16:37:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 16: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 1SbaGz-0003vD-8v; Mon, 04 Jun 2012 16:36:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SbaGx-0003v8-Pg
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 16:36:52 +0000
Received: from [85.158.138.51:33259] by server-7.bemta-3.messagelabs.com id
	AE/03-22601-224ECCF4; Mon, 04 Jun 2012 16:36:50 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338827808!30703580!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10913 invoked from network); 4 Jun 2012 16:36:50 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jun 2012 16:36:50 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SbaGu-0002xP-AL
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 09:36:48 -0700
Date: Mon, 4 Jun 2012 09:36:48 -0700 (PDT)
From: elahe <e.shekuhi@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1338827808312-5709267.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xen live vm migration 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

Hi everybody,

I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
migration does not work. While the source host works on the "xm migrate -l
..." command, I can see the VM on the target host in paused state in "xm
list", but after a while it vanishes while the xm command on the source
machine returns whitout any errors.

(One machine has core i7 processor while another is core 2 quad system).


 I have searched the net and this list and found a few posts mentioning this
error, but no solution, not even a hint
    on the source of the problem. 

Any help would be really appreciated. Thanks.

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-live-vm-migration-error-tp5709267.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xen.org Mon Jun 04 17:24:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 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 1Sbb0n-0004KA-DN; Mon, 04 Jun 2012 17:24:13 +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 1Sbb0m-0004Jw-4t
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 17:24:12 +0000
Received: from [85.158.143.35:45186] by server-3.bemta-4.messagelabs.com id
	96/29-29237-B3FECCF4; Mon, 04 Jun 2012 17:24:11 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338830650!13997065!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17396 invoked from network); 4 Jun 2012 17:24:10 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 17:24:10 -0000
Received: by wibhn14 with SMTP id hn14so2739301wib.2
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 10:24:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=MLBAeN5Bz3/xbJj3Ev4H8xURONpRB2BgBs/xTOlFWAw=;
	b=wvogLyVPAN28csnYzj20opXTbIiumxrpOTPw5Sdj0QDST4+3U6RbYcNLbzNbLP1Q/M
	dVtz/Z5vJA2d2HV1pa1AHYPuoTUsqTLMVCztgB0+1heYkvxJtouGJ5/XHoqo1wQdTreD
	LdpQ8qQAQxMDWogsBL8URqklfd2QTIMgojCe/Etg5LtjfhwS6HMAMIWLmxb75ULyp3gV
	jQjUBcXxZCHSzC2JzDQ694yrQogHr80PIFB2DdT+lt7EXeRTTw5Cm4q7nurq8wcNYtGt
	LLo/IoZWA8wzmamOtS0raDau+MkHJvZEAsmC7DeO8eOb6xw9G7v5sdgite3PxzYV/U2a
	sLUQ==
Received: by 10.216.213.28 with SMTP id z28mr11651730weo.50.1338830650249;
	Mon, 04 Jun 2012 10:24:10 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id bn9sm21245760wib.5.2012.06.04.10.24.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 04 Jun 2012 10:24:08 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a5f7f05d76f9d8940121e3a78cb47ef770ad7d0e
Message-Id: <a5f7f05d76f9d8940121.1338830602@Solace>
In-Reply-To: <patchbomb.1338830601@Solace>
References: <patchbomb.1338830601@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 04 Jun 2012 19:23:22 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VG8gYXZvaWQgcmVjZW50IGdjYyBjb21wbGFpbmluZyBhYm91dDoKbGlieGwuYzogSW4gZnVuY3Rp
b24g4oCYbGlieGxfcHJpbWFyeV9jb25zb2xlX2V4ZWPigJk6CmxpYnhsLmM6MTIzMzo5OiBlcnJv
cjogY2FzZSB2YWx1ZSDigJg0Mjk0OTY3Mjk14oCZIG5vdCBpbiBlbnVtZXJhdGVkIHR5cGUg4oCY
bGlieGxfZG9tYWluX3R5cGXigJkgWy1XZXJyb3I9c3dpdGNoXQoKQWxzbzoKIC0gaGF2ZSBhbGwg
dGhlIGNhbGwgc2l0ZXMgb2YgbGlieGxfX2RvbWFpbl90eXBlKCkgcmV0dXJuIHdpdGggZXJyb3Ig
aW4KICAgY2FzZSB0aGUgZnVuY3Rpb24gcmV0dXJucyBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElE
OwogLSBhZGp1c3QgYWxsIG90aGVyIGNvZGUgc2VnbWVudHMgd2hlcmUgLVdzd2l0Y2ggbWFrZXMg
d291bGQgY2xhaW0gdGhhdAogICBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEIGlzIG5vdCBoYW5k
bGVkIGJ5IGFkZGluZyBhICJkZWZhdWx0OiBhYm9ydCgpOyIKICAgY2xhdXNlLgoKU2lnbmVkLW9m
Zi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5jb20+ClNpZ25lZC1v
ZmYtYnk6IENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CgpkaWZmIC0t
Z2l0IGEvdG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKLS0tIGEvdG9v
bHMvbGlieGwvbGlieGwuYworKysgYi90b29scy9saWJ4bC9saWJ4bC5jCkBAIC02NTYsNiArNjU2
LDEzIEBAIGludCBsaWJ4bF9kb21haW5fcmVtdXNfc3RhcnQobGlieGxfY3R4ICoKICAgICBsaWJ4
bF9kb21haW5fdHlwZSB0eXBlID0gbGlieGxfX2RvbWFpbl90eXBlKGdjLCBkb21pZCk7CiAgICAg
aW50IHJjID0gMDsKIAorICAgIGlmICh0eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQp
IHsKKyAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsCisgICAgICAgICAg
ICAgICAgICAgImludmFsaWQgZG9tYWluIHR5cGUgZm9yIGRvbWFpbiAlZCIsIGRvbWlkKTsKKyAg
ICAgICAgcmMgPSBFUlJPUl9JTlZBTDsKKyAgICAgICAgZ290byByZW11c19mYWlsOworICAgIH0K
KwogICAgIGlmIChpbmZvID09IE5VTEwpIHsKICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhM
X19MT0dfRVJST1IsCiAgICAgICAgICAgICAgICAgICAgIk5vIHJlbXVzX2luZm8gc3RydWN0dXJl
IHN1cHBsaWVkIGZvciBkb21haW4gJWQiLCBkb21pZCk7CkBAIC02OTIsMTEgKzY5OSwyMCBAQCBp
bnQgbGlieGxfZG9tYWluX3N1c3BlbmQobGlieGxfY3R4ICpjdHgsCiAgICAgaW50IGRlYnVnID0g
aW5mbyAhPSBOVUxMICYmIGluZm8tPmZsYWdzICYgWExfU1VTUEVORF9ERUJVRzsKICAgICBpbnQg
cmMgPSAwOwogCisgICAgaWYgKHR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfSU5WQUxJRCkgewor
ICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKKyAgICAgICAgICAgICAg
ICAgICAiaW52YWxpZCBkb21haW4gdHlwZSBmb3IgZG9tYWluICVkIiwgZG9taWQpOworICAgICAg
ICByYyA9IEVSUk9SX0lOVkFMOworICAgICAgICBnb3RvIHN1c3BlbmRfZmFpbDsKKyAgICB9CisK
ICAgICByYyA9IGxpYnhsX19kb21haW5fc3VzcGVuZF9jb21tb24oZ2MsIGRvbWlkLCBmZCwgdHlw
ZSwgbGl2ZSwgZGVidWcsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8q
IE5vIFJlbXVzICovIE5VTEwpOwogCiAgICAgaWYgKCFyYyAmJiB0eXBlID09IExJQlhMX0RPTUFJ
Tl9UWVBFX0hWTSkKICAgICAgICAgcmMgPSBsaWJ4bF9fZG9tYWluX3NhdmVfZGV2aWNlX21vZGVs
KGdjLCBkb21pZCwgZmQpOworCisgc3VzcGVuZF9mYWlsOgogICAgIEdDX0ZSRUU7CiAgICAgcmV0
dXJuIHJjOwogfQpAQCAtMTI1OSw3ICsxMjc1LDcgQEAgaW50IGxpYnhsX3ByaW1hcnlfY29uc29s
ZV9leGVjKGxpYnhsX2N0eAogICAgICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX1BWOgogICAg
ICAgICAgICAgcmMgPSBsaWJ4bF9jb25zb2xlX2V4ZWMoY3R4LCBkb21pZF92bSwgMCwgTElCWExf
Q09OU09MRV9UWVBFX1BWKTsKICAgICAgICAgICAgIGJyZWFrOwotICAgICAgICBjYXNlIC0xOgor
ICAgICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQ6CiAgICAgICAgICAgICBMT0co
RVJST1IsInVuYWJsZSB0byBnZXQgZG9tYWluIHR5cGUgZm9yIGRvbWlkPSUiUFJJdTMyLGRvbWlk
X3ZtKTsKICAgICAgICAgICAgIHJjID0gRVJST1JfRkFJTDsKICAgICAgICAgICAgIGJyZWFrOwpk
aWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2Rt
LmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYworKysgYi90b29scy9saWJ4bC9saWJ4bF9k
bS5jCkBAIC0yNTcsNiArMjU3LDggQEAgc3RhdGljIGNoYXIgKiogbGlieGxfX2J1aWxkX2Rldmlj
ZV9tb2RlbAogICAgICAgICBmb3IgKGkgPSAwOyBiX2luZm8tPmV4dHJhX2h2bSAmJiBiX2luZm8t
PmV4dHJhX2h2bVtpXSAhPSBOVUxMOyBpKyspCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5k
KGRtX2FyZ3MsIGJfaW5mby0+ZXh0cmFfaHZtW2ldKTsKICAgICAgICAgYnJlYWs7CisgICAgZGVm
YXVsdDoKKyAgICAgICAgYWJvcnQoKTsKICAgICB9CiAgICAgZmxleGFycmF5X2FwcGVuZChkbV9h
cmdzLCBOVUxMKTsKICAgICByZXR1cm4gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhkbV9h
cmdzKTsKQEAgLTUwNSw2ICs1MDcsOCBAQCBzdGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVpbGRfZGV2
aWNlX21vZGVsCiAgICAgICAgIGZvciAoaSA9IDA7IGJfaW5mby0+ZXh0cmFfaHZtICYmIGJfaW5m
by0+ZXh0cmFfaHZtW2ldICE9IE5VTEw7IGkrKykKICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBl
bmQoZG1fYXJncywgYl9pbmZvLT5leHRyYV9odm1baV0pOwogICAgICAgICBicmVhazsKKyAgICBk
ZWZhdWx0OgorICAgICAgICBhYm9ydCgpOwogICAgIH0KIAogICAgIHJhbV9zaXplID0gbGlieGxf
X3NpemVrYl90b19tYihiX2luZm8tPm1heF9tZW1rYiAtIGJfaW5mby0+dmlkZW9fbWVta2IpOwpk
aWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG9tLmMgYi90b29scy9saWJ4bC9saWJ4bF9k
b20uYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9kb20uYworKysgYi90b29scy9saWJ4bC9saWJ4
bF9kb20uYwpAQCAtMzMsOSArMzMsOSBAQCBsaWJ4bF9kb21haW5fdHlwZSBsaWJ4bF9fZG9tYWlu
X3R5cGUobGliCiAKICAgICByZXQgPSB4Y19kb21haW5fZ2V0aW5mb2xpc3QoY3R4LT54Y2gsIGRv
bWlkLCAxLCAmaW5mbyk7CiAgICAgaWYgKHJldCAhPSAxKQotICAgICAgICByZXR1cm4gLTE7Cisg
ICAgICAgIHJldHVybiBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEOwogICAgIGlmIChpbmZvLmRv
bWFpbiAhPSBkb21pZCkKLSAgICAgICAgcmV0dXJuIC0xOworICAgICAgICByZXR1cm4gTElCWExf
RE9NQUlOX1RZUEVfSU5WQUxJRDsKICAgICBpZiAoaW5mby5mbGFncyAmIFhFTl9ET01JTkZfaHZt
X2d1ZXN0KQogICAgICAgICByZXR1cm4gTElCWExfRE9NQUlOX1RZUEVfSFZNOwogICAgIGVsc2UK
ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnhsL2xp
YnhsX3R5cGVzLmlkbAotLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCkBAIC0yOCw2ICsyOCw3IEBAIE1lbUtCID0gVUludCg2
NCwgaW5pdF92YWwgPSAiTElCWExfTUVNS0IKICMKIAogbGlieGxfZG9tYWluX3R5cGUgPSBFbnVt
ZXJhdGlvbigiZG9tYWluX3R5cGUiLCBbCisgICAgKC0xLCAiSU5WQUxJRCIpLAogICAgICgxLCAi
SFZNIiksCiAgICAgKDIsICJQViIpLAogICAgIF0pCkBAIC0zMTAsNiArMzExLDcgQEAgbGlieGxf
ZG9tYWluX2J1aWxkX2luZm8gPSBTdHJ1Y3QoImRvbWFpbgogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAjIFVzZSBob3N0J3MgRTgyMCBmb3IgUENJIHBhc3N0aHJvdWdoLgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoImU4MjBfaG9zdCIsIGxpYnhs
X2RlZmJvb2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBdKSksCisg
ICAgICAgICAgICAgICAgICgiaW52YWxpZCIsIFN0cnVjdChOb25lLCBbXSkpLAogICAgICAgICAg
ICAgICAgICBdLCBrZXl2YXJfaW5pdF92YWwgPSAiLTEiKSksCiAgICAgXSwgZGlyPURJUl9JTgog
KQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Jun 04 17:24:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 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 1Sbb0m-0004Jx-0l; Mon, 04 Jun 2012 17:24:12 +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 1Sbb0j-0004Jo-Sh
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 17:24:10 +0000
Received: from [85.158.143.99:8661] by server-2.bemta-4.messagelabs.com id
	FC/36-25135-93FECCF4; Mon, 04 Jun 2012 17:24:09 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1338830647!20097261!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29064 invoked from network); 4 Jun 2012 17:24:08 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 17:24:08 -0000
Received: by wgbed3 with SMTP id ed3so3124544wgb.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 10:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=xZ+Pp/96okztSqBXy4Bis6nLv0OeXs18ArKyQYsw+zQ=;
	b=iExv7wEWpY83SDo4KSU+n+aRs8cZ7CXPJ9nv4FdCgYZg0Zn0X8+xF/YdooDHqj2/G+
	fn+WrVxeBtptPlTH1Kuos1I9qgtDR6CN8sctHJHbVz3sryggOb2Gz5gRHzKRKSFnPoQ5
	I0P3wGtR/oBtYmqpwnZy/3a0rpz2/71JI+luN8u9qeiQ1vDp/RvZBjF9+WUiv5ZS0sj+
	YeJWok0tEI3n5z9R4nNQ/cCZFO3oxCxLBDJ5x6V0WG7u3rKena964TZ77kv+wHx+uzO4
	wqeR6+xTbr2kzAW6Tt3Oo+qLY9KkH88x9oo1PyhanKIfx34B/teq9jw8Sqz6vwnDtNPs
	H4Hw==
Received: by 10.216.228.202 with SMTP id f52mr11529112weq.223.1338830646940;
	Mon, 04 Jun 2012 10:24:06 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id bn9sm21245760wib.5.2012.06.04.10.24.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 04 Jun 2012 10:24:04 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1338830601@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 04 Jun 2012 19:23:21 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 1 v5] Fix build failure with gcc's
	-Werror=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

Hi guys,

This is another attempt of fixing that build failure with recent gcc-s properly
(the one due to -Werror=switch enabled by default).

>From previous versions (namely, v4), I rewrote it as per IanJ's suggestion of
going for all the call sites of libxl__domain_type() and deal with the fact it
can fail.  This way, and thanks to the libxl__domain_build_info_setdefault()
machinery, all the places where something different from LIBXL_DOMAIN_TYPE_PV
or LIBXL_DOMAIN_TYPE_HVM is returned can just fail or abort.

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 Mon Jun 04 17:24:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 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 1Sbb0n-0004KA-DN; Mon, 04 Jun 2012 17:24:13 +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 1Sbb0m-0004Jw-4t
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 17:24:12 +0000
Received: from [85.158.143.35:45186] by server-3.bemta-4.messagelabs.com id
	96/29-29237-B3FECCF4; Mon, 04 Jun 2012 17:24:11 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338830650!13997065!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17396 invoked from network); 4 Jun 2012 17:24:10 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 17:24:10 -0000
Received: by wibhn14 with SMTP id hn14so2739301wib.2
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 10:24:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=MLBAeN5Bz3/xbJj3Ev4H8xURONpRB2BgBs/xTOlFWAw=;
	b=wvogLyVPAN28csnYzj20opXTbIiumxrpOTPw5Sdj0QDST4+3U6RbYcNLbzNbLP1Q/M
	dVtz/Z5vJA2d2HV1pa1AHYPuoTUsqTLMVCztgB0+1heYkvxJtouGJ5/XHoqo1wQdTreD
	LdpQ8qQAQxMDWogsBL8URqklfd2QTIMgojCe/Etg5LtjfhwS6HMAMIWLmxb75ULyp3gV
	jQjUBcXxZCHSzC2JzDQ694yrQogHr80PIFB2DdT+lt7EXeRTTw5Cm4q7nurq8wcNYtGt
	LLo/IoZWA8wzmamOtS0raDau+MkHJvZEAsmC7DeO8eOb6xw9G7v5sdgite3PxzYV/U2a
	sLUQ==
Received: by 10.216.213.28 with SMTP id z28mr11651730weo.50.1338830650249;
	Mon, 04 Jun 2012 10:24:10 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id bn9sm21245760wib.5.2012.06.04.10.24.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 04 Jun 2012 10:24:08 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a5f7f05d76f9d8940121e3a78cb47ef770ad7d0e
Message-Id: <a5f7f05d76f9d8940121.1338830602@Solace>
In-Reply-To: <patchbomb.1338830601@Solace>
References: <patchbomb.1338830601@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 04 Jun 2012 19:23:22 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VG8gYXZvaWQgcmVjZW50IGdjYyBjb21wbGFpbmluZyBhYm91dDoKbGlieGwuYzogSW4gZnVuY3Rp
b24g4oCYbGlieGxfcHJpbWFyeV9jb25zb2xlX2V4ZWPigJk6CmxpYnhsLmM6MTIzMzo5OiBlcnJv
cjogY2FzZSB2YWx1ZSDigJg0Mjk0OTY3Mjk14oCZIG5vdCBpbiBlbnVtZXJhdGVkIHR5cGUg4oCY
bGlieGxfZG9tYWluX3R5cGXigJkgWy1XZXJyb3I9c3dpdGNoXQoKQWxzbzoKIC0gaGF2ZSBhbGwg
dGhlIGNhbGwgc2l0ZXMgb2YgbGlieGxfX2RvbWFpbl90eXBlKCkgcmV0dXJuIHdpdGggZXJyb3Ig
aW4KICAgY2FzZSB0aGUgZnVuY3Rpb24gcmV0dXJucyBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElE
OwogLSBhZGp1c3QgYWxsIG90aGVyIGNvZGUgc2VnbWVudHMgd2hlcmUgLVdzd2l0Y2ggbWFrZXMg
d291bGQgY2xhaW0gdGhhdAogICBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEIGlzIG5vdCBoYW5k
bGVkIGJ5IGFkZGluZyBhICJkZWZhdWx0OiBhYm9ydCgpOyIKICAgY2xhdXNlLgoKU2lnbmVkLW9m
Zi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5jb20+ClNpZ25lZC1v
ZmYtYnk6IENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CgpkaWZmIC0t
Z2l0IGEvdG9vbHMvbGlieGwvbGlieGwuYyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKLS0tIGEvdG9v
bHMvbGlieGwvbGlieGwuYworKysgYi90b29scy9saWJ4bC9saWJ4bC5jCkBAIC02NTYsNiArNjU2
LDEzIEBAIGludCBsaWJ4bF9kb21haW5fcmVtdXNfc3RhcnQobGlieGxfY3R4ICoKICAgICBsaWJ4
bF9kb21haW5fdHlwZSB0eXBlID0gbGlieGxfX2RvbWFpbl90eXBlKGdjLCBkb21pZCk7CiAgICAg
aW50IHJjID0gMDsKIAorICAgIGlmICh0eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQp
IHsKKyAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsCisgICAgICAgICAg
ICAgICAgICAgImludmFsaWQgZG9tYWluIHR5cGUgZm9yIGRvbWFpbiAlZCIsIGRvbWlkKTsKKyAg
ICAgICAgcmMgPSBFUlJPUl9JTlZBTDsKKyAgICAgICAgZ290byByZW11c19mYWlsOworICAgIH0K
KwogICAgIGlmIChpbmZvID09IE5VTEwpIHsKICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhM
X19MT0dfRVJST1IsCiAgICAgICAgICAgICAgICAgICAgIk5vIHJlbXVzX2luZm8gc3RydWN0dXJl
IHN1cHBsaWVkIGZvciBkb21haW4gJWQiLCBkb21pZCk7CkBAIC02OTIsMTEgKzY5OSwyMCBAQCBp
bnQgbGlieGxfZG9tYWluX3N1c3BlbmQobGlieGxfY3R4ICpjdHgsCiAgICAgaW50IGRlYnVnID0g
aW5mbyAhPSBOVUxMICYmIGluZm8tPmZsYWdzICYgWExfU1VTUEVORF9ERUJVRzsKICAgICBpbnQg
cmMgPSAwOwogCisgICAgaWYgKHR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfSU5WQUxJRCkgewor
ICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKKyAgICAgICAgICAgICAg
ICAgICAiaW52YWxpZCBkb21haW4gdHlwZSBmb3IgZG9tYWluICVkIiwgZG9taWQpOworICAgICAg
ICByYyA9IEVSUk9SX0lOVkFMOworICAgICAgICBnb3RvIHN1c3BlbmRfZmFpbDsKKyAgICB9CisK
ICAgICByYyA9IGxpYnhsX19kb21haW5fc3VzcGVuZF9jb21tb24oZ2MsIGRvbWlkLCBmZCwgdHlw
ZSwgbGl2ZSwgZGVidWcsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8q
IE5vIFJlbXVzICovIE5VTEwpOwogCiAgICAgaWYgKCFyYyAmJiB0eXBlID09IExJQlhMX0RPTUFJ
Tl9UWVBFX0hWTSkKICAgICAgICAgcmMgPSBsaWJ4bF9fZG9tYWluX3NhdmVfZGV2aWNlX21vZGVs
KGdjLCBkb21pZCwgZmQpOworCisgc3VzcGVuZF9mYWlsOgogICAgIEdDX0ZSRUU7CiAgICAgcmV0
dXJuIHJjOwogfQpAQCAtMTI1OSw3ICsxMjc1LDcgQEAgaW50IGxpYnhsX3ByaW1hcnlfY29uc29s
ZV9leGVjKGxpYnhsX2N0eAogICAgICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX1BWOgogICAg
ICAgICAgICAgcmMgPSBsaWJ4bF9jb25zb2xlX2V4ZWMoY3R4LCBkb21pZF92bSwgMCwgTElCWExf
Q09OU09MRV9UWVBFX1BWKTsKICAgICAgICAgICAgIGJyZWFrOwotICAgICAgICBjYXNlIC0xOgor
ICAgICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQ6CiAgICAgICAgICAgICBMT0co
RVJST1IsInVuYWJsZSB0byBnZXQgZG9tYWluIHR5cGUgZm9yIGRvbWlkPSUiUFJJdTMyLGRvbWlk
X3ZtKTsKICAgICAgICAgICAgIHJjID0gRVJST1JfRkFJTDsKICAgICAgICAgICAgIGJyZWFrOwpk
aWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2Rt
LmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYworKysgYi90b29scy9saWJ4bC9saWJ4bF9k
bS5jCkBAIC0yNTcsNiArMjU3LDggQEAgc3RhdGljIGNoYXIgKiogbGlieGxfX2J1aWxkX2Rldmlj
ZV9tb2RlbAogICAgICAgICBmb3IgKGkgPSAwOyBiX2luZm8tPmV4dHJhX2h2bSAmJiBiX2luZm8t
PmV4dHJhX2h2bVtpXSAhPSBOVUxMOyBpKyspCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5k
KGRtX2FyZ3MsIGJfaW5mby0+ZXh0cmFfaHZtW2ldKTsKICAgICAgICAgYnJlYWs7CisgICAgZGVm
YXVsdDoKKyAgICAgICAgYWJvcnQoKTsKICAgICB9CiAgICAgZmxleGFycmF5X2FwcGVuZChkbV9h
cmdzLCBOVUxMKTsKICAgICByZXR1cm4gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhkbV9h
cmdzKTsKQEAgLTUwNSw2ICs1MDcsOCBAQCBzdGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVpbGRfZGV2
aWNlX21vZGVsCiAgICAgICAgIGZvciAoaSA9IDA7IGJfaW5mby0+ZXh0cmFfaHZtICYmIGJfaW5m
by0+ZXh0cmFfaHZtW2ldICE9IE5VTEw7IGkrKykKICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBl
bmQoZG1fYXJncywgYl9pbmZvLT5leHRyYV9odm1baV0pOwogICAgICAgICBicmVhazsKKyAgICBk
ZWZhdWx0OgorICAgICAgICBhYm9ydCgpOwogICAgIH0KIAogICAgIHJhbV9zaXplID0gbGlieGxf
X3NpemVrYl90b19tYihiX2luZm8tPm1heF9tZW1rYiAtIGJfaW5mby0+dmlkZW9fbWVta2IpOwpk
aWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG9tLmMgYi90b29scy9saWJ4bC9saWJ4bF9k
b20uYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9kb20uYworKysgYi90b29scy9saWJ4bC9saWJ4
bF9kb20uYwpAQCAtMzMsOSArMzMsOSBAQCBsaWJ4bF9kb21haW5fdHlwZSBsaWJ4bF9fZG9tYWlu
X3R5cGUobGliCiAKICAgICByZXQgPSB4Y19kb21haW5fZ2V0aW5mb2xpc3QoY3R4LT54Y2gsIGRv
bWlkLCAxLCAmaW5mbyk7CiAgICAgaWYgKHJldCAhPSAxKQotICAgICAgICByZXR1cm4gLTE7Cisg
ICAgICAgIHJldHVybiBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEOwogICAgIGlmIChpbmZvLmRv
bWFpbiAhPSBkb21pZCkKLSAgICAgICAgcmV0dXJuIC0xOworICAgICAgICByZXR1cm4gTElCWExf
RE9NQUlOX1RZUEVfSU5WQUxJRDsKICAgICBpZiAoaW5mby5mbGFncyAmIFhFTl9ET01JTkZfaHZt
X2d1ZXN0KQogICAgICAgICByZXR1cm4gTElCWExfRE9NQUlOX1RZUEVfSFZNOwogICAgIGVsc2UK
ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnhsL2xp
YnhsX3R5cGVzLmlkbAotLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCkBAIC0yOCw2ICsyOCw3IEBAIE1lbUtCID0gVUludCg2
NCwgaW5pdF92YWwgPSAiTElCWExfTUVNS0IKICMKIAogbGlieGxfZG9tYWluX3R5cGUgPSBFbnVt
ZXJhdGlvbigiZG9tYWluX3R5cGUiLCBbCisgICAgKC0xLCAiSU5WQUxJRCIpLAogICAgICgxLCAi
SFZNIiksCiAgICAgKDIsICJQViIpLAogICAgIF0pCkBAIC0zMTAsNiArMzExLDcgQEAgbGlieGxf
ZG9tYWluX2J1aWxkX2luZm8gPSBTdHJ1Y3QoImRvbWFpbgogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAjIFVzZSBob3N0J3MgRTgyMCBmb3IgUENJIHBhc3N0aHJvdWdoLgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoImU4MjBfaG9zdCIsIGxpYnhs
X2RlZmJvb2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBdKSksCisg
ICAgICAgICAgICAgICAgICgiaW52YWxpZCIsIFN0cnVjdChOb25lLCBbXSkpLAogICAgICAgICAg
ICAgICAgICBdLCBrZXl2YXJfaW5pdF92YWwgPSAiLTEiKSksCiAgICAgXSwgZGlyPURJUl9JTgog
KQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Jun 04 17:24:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 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 1Sbb0m-0004Jx-0l; Mon, 04 Jun 2012 17:24:12 +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 1Sbb0j-0004Jo-Sh
	for xen-devel@lists.xen.org; Mon, 04 Jun 2012 17:24:10 +0000
Received: from [85.158.143.99:8661] by server-2.bemta-4.messagelabs.com id
	FC/36-25135-93FECCF4; Mon, 04 Jun 2012 17:24:09 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1338830647!20097261!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29064 invoked from network); 4 Jun 2012 17:24:08 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jun 2012 17:24:08 -0000
Received: by wgbed3 with SMTP id ed3so3124544wgb.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 10:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=xZ+Pp/96okztSqBXy4Bis6nLv0OeXs18ArKyQYsw+zQ=;
	b=iExv7wEWpY83SDo4KSU+n+aRs8cZ7CXPJ9nv4FdCgYZg0Zn0X8+xF/YdooDHqj2/G+
	fn+WrVxeBtptPlTH1Kuos1I9qgtDR6CN8sctHJHbVz3sryggOb2Gz5gRHzKRKSFnPoQ5
	I0P3wGtR/oBtYmqpwnZy/3a0rpz2/71JI+luN8u9qeiQ1vDp/RvZBjF9+WUiv5ZS0sj+
	YeJWok0tEI3n5z9R4nNQ/cCZFO3oxCxLBDJ5x6V0WG7u3rKena964TZ77kv+wHx+uzO4
	wqeR6+xTbr2kzAW6Tt3Oo+qLY9KkH88x9oo1PyhanKIfx34B/teq9jw8Sqz6vwnDtNPs
	H4Hw==
Received: by 10.216.228.202 with SMTP id f52mr11529112weq.223.1338830646940;
	Mon, 04 Jun 2012 10:24:06 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id bn9sm21245760wib.5.2012.06.04.10.24.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 04 Jun 2012 10:24:04 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1338830601@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 04 Jun 2012 19:23:21 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 1 v5] Fix build failure with gcc's
	-Werror=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

Hi guys,

This is another attempt of fixing that build failure with recent gcc-s properly
(the one due to -Werror=switch enabled by default).

>From previous versions (namely, v4), I rewrote it as per IanJ's suggestion of
going for all the call sites of libxl__domain_type() and deal with the fact it
can fail.  This way, and thanks to the libxl__domain_build_info_setdefault()
machinery, all the places where something different from LIBXL_DOMAIN_TYPE_PV
or LIBXL_DOMAIN_TYPE_HVM is returned can just fail or abort.

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 Mon Jun 04 18:48:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 18: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 1SbcJd-0004rk-Iw; Mon, 04 Jun 2012 18:47:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SbcJb-0004rf-Ft
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 18:47:43 +0000
Received: from [85.158.143.35:43028] by server-1.bemta-4.messagelabs.com id
	26/44-10042-EC20DCF4; Mon, 04 Jun 2012 18:47:42 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338835660!18744747!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 703 invoked from network); 4 Jun 2012 18:47:41 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jun 2012 18:47:41 -0000
Received: from mail202-va3-R.bigfish.com (10.7.14.240) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 18:47:00 +0000
Received: from mail202-va3 (localhost [127.0.0.1])	by
	mail202-va3-R.bigfish.com (Postfix) with ESMTP id 3FDB5D80248;
	Mon,  4 Jun 2012 18:47:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail202-va3 (localhost.localdomain [127.0.0.1]) by mail202-va3
	(MessageSwitch) id 1338835618210435_10092;
	Mon,  4 Jun 2012 18:46:58 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.239])	by
	mail202-va3.bigfish.com (Postfix) with ESMTP id 3122A64004B;
	Mon,  4 Jun 2012 18:46:58 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 18:46:57 +0000
X-WSS-ID: 0M53W78-01-66Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2639E102814F;	Mon,  4 Jun 2012 13:47:31 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 4 Jun 2012 13:47:37 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 4 Jun 2012 13:47:31 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 4 Jun 2012
	14:47:30 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C26D949C2B0; Mon,  4 Jun 2012
	19:47:29 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id B1AB12D202B; Mon,
	4 Jun 2012 20:47:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 390346181927d0350f83c4046470a0b9b28c1686
Message-ID: <390346181927d0350f83.1338835629@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 4 Jun 2012 20:47:09 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keir@xen.org>, <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpm,
 x86: Fix reporting of idle state average residency times
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1338831484 -7200
# Node ID 390346181927d0350f83c4046470a0b9b28c1686
# Parent  6bea63e6c780de6303361e5f190d6925996cd2a2
xenpm, x86: Fix reporting of idle state average residency times

If CPU stays in the same idle state for the full duration of
xenpm sample then average residency may not be reported correctly
since usage counter will not be incremented.

In addition, in order to calculate averages correctly residence
time and usage counter should be read and written atomically.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 6bea63e6c780 -r 390346181927 tools/misc/xenpm.c
--- a/tools/misc/xenpm.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/misc/xenpm.c	Mon Jun 04 19:38:04 2012 +0200
@@ -389,7 +389,14 @@ static void signal_int_handler(int signo
                 res = ( diff >= 0 ) ? diff : 0;
                 triggers = cxstat_end[i].triggers[j] -
                     cxstat_start[i].triggers[j];
-                avg_res = (triggers==0) ? 0: (double)res/triggers/1000000.0;
+                /* 
+                 * triggers may be zero if the CPU has been in this state for
+                 * the whole sample or if it never entered the state
+                 */
+                if ( triggers == 0 && cxstat_end[i].last == j )
+                    avg_res =  (double)sum_cx[i]/1000000.0;
+                else
+                    avg_res = (triggers==0) ? 0: (double)res/triggers/1000000.0;
                 printf("  C%d\t%"PRIu64"\t(%5.2f%%)\t%.2f\n", j, res/1000000UL,
                         100 * res / (double)sum_cx[i], avg_res );
             }
diff -r 6bea63e6c780 -r 390346181927 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/xen/arch/x86/acpi/cpu_idle.c	Mon Jun 04 19:38:04 2012 +0200
@@ -165,29 +165,35 @@ static void print_acpi_power(uint32_t cp
 {
     uint32_t i, idle_usage = 0;
     uint64_t res, idle_res = 0;
+    u32 usage;
+    u8 last_state_idx;
 
     printk("==cpu%d==\n", cpu);
-    printk("active state:\t\tC%d\n",
-           power->last_state ? power->last_state->idx : -1);
+    last_state_idx = power->last_state ? power->last_state->idx : -1;
+    printk("active state:\t\tC%d\n", last_state_idx);
     printk("max_cstate:\t\tC%d\n", max_cstate);
     printk("states:\n");
     
     for ( i = 1; i < power->count; i++ )
     {
+        spin_lock_irq(&power->stat_lock);	
         res = tick_to_ns(power->states[i].time);
-        idle_usage += power->states[i].usage;
+        usage = power->states[i].usage;
+        spin_unlock_irq(&power->stat_lock);
+
+        idle_usage += usage;
         idle_res += res;
 
-        printk((power->last_state && power->last_state->idx == i) ?
-               "   *" : "    ");
+        printk((last_state_idx == i) ? "   *" : "    ");
         printk("C%d:\t", i);
         printk("type[C%d] ", power->states[i].type);
         printk("latency[%03d] ", power->states[i].latency);
-        printk("usage[%08d] ", power->states[i].usage);
+        printk("usage[%08d] ", usage);
         printk("method[%5s] ", acpi_cstate_method_name[power->states[i].entry_method]);
         printk("duration[%"PRId64"]\n", res);
     }
-    printk("    C0:\tusage[%08d] duration[%"PRId64"]\n",
+    printk((last_state_idx == 0) ? "   *" : "    ");
+    printk("C0:\tusage[%08d] duration[%"PRId64"]\n",
            idle_usage, NOW() - idle_res);
 
     print_hw_residencies(cpu);
@@ -384,12 +390,29 @@ bool_t errata_c6_eoi_workaround(void)
     return (fix_needed && cpu_has_pending_apic_eoi());
 }
 
+static inline void acpi_update_idle_stats(struct acpi_processor_power *power,
+                                          struct acpi_processor_cx *cx,
+                                          int64_t sleep_ticks)
+{
+    /* Interrupts are disabled */
+
+    spin_lock(&power->stat_lock);
+
+    cx->usage++;
+    if ( sleep_ticks > 0 )
+    {
+        power->last_residency = tick_to_ns(sleep_ticks) / 1000UL;
+        cx->time += sleep_ticks;
+    }
+
+    spin_unlock(&power->stat_lock);
+}
+
 static void acpi_processor_idle(void)
 {
     struct acpi_processor_power *power = processor_powers[smp_processor_id()];
     struct acpi_processor_cx *cx = NULL;
     int next_state;
-    int64_t sleep_ticks = 0;
     uint64_t t1, t2 = 0;
     u32 exp = 0, pred = 0;
     u32 irq_traced[4] = { 0 };
@@ -462,10 +485,10 @@ static void acpi_processor_idle(void)
             /* Trace cpu idle exit */
             TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
                      irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
+            /* Update statistics */
+            acpi_update_idle_stats(power, cx, ticks_elapsed(t1, t2));
             /* Re-enable interrupts */
             local_irq_enable();
-            /* Compute time (ticks) that we were actually asleep */
-            sleep_ticks = ticks_elapsed(t1, t2);
             break;
         }
 
@@ -537,28 +560,26 @@ static void acpi_processor_idle(void)
         TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
                  irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
 
+        /* Update statistics */
+        acpi_update_idle_stats(power, cx, ticks_elapsed(t1, t2));
         /* Re-enable interrupts */
         local_irq_enable();
         /* recovering APIC */
         lapic_timer_on();
-        /* Compute time (ticks) that we were actually asleep */
-        sleep_ticks = ticks_elapsed(t1, t2);
 
         break;
 
     default:
+        /* Now in C0 */
+        power->last_state = &power->states[0];
         local_irq_enable();
         sched_tick_resume();
         cpufreq_dbs_timer_resume();
         return;
     }
 
-    cx->usage++;
-    if ( sleep_ticks > 0 )
-    {
-        power->last_residency = tick_to_ns(sleep_ticks) / 1000UL;
-        cx->time += sleep_ticks;
-    }
+    /* Now in C0 */
+    power->last_state = &power->states[0];
 
     sched_tick_resume();
     cpufreq_dbs_timer_resume();
@@ -662,6 +683,7 @@ static int cpuidle_init_cpu(int cpu)
     acpi_power->states[1].type = ACPI_STATE_C1;
     acpi_power->states[1].entry_method = ACPI_CSTATE_EM_HALT;
     acpi_power->safe_state = &acpi_power->states[1];
+    spin_lock_init(&acpi_power->stat_lock);
 
     return 0;
 }
@@ -1064,7 +1086,8 @@ uint32_t pmstat_get_cx_nr(uint32_t cpuid
 int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat)
 {
     struct acpi_processor_power *power = processor_powers[cpuid];
-    uint64_t usage, res, idle_usage = 0, idle_res = 0;
+    uint64_t idle_usage = 0, idle_res = 0;
+    uint64_t usage[ACPI_PROCESSOR_MAX_POWER], res[ACPI_PROCESSOR_MAX_POWER];
     int i;
     struct hw_residencies hw_res;
 
@@ -1084,16 +1107,14 @@ int pmstat_get_cx_stat(uint32_t cpuid, s
     if ( pm_idle_save == NULL )
     {
         /* C1 */
-        usage = 1;
-        res = stat->idle_time;
-        if ( copy_to_guest_offset(stat->triggers, 1, &usage, 1) ||
-             copy_to_guest_offset(stat->residencies, 1, &res, 1) )
-            return -EFAULT;
+        usage[1] = 1;
+        res[1] = stat->idle_time;
 
         /* C0 */
-        res = NOW() - res;
-        if ( copy_to_guest_offset(stat->triggers, 0, &usage, 1) ||
-             copy_to_guest_offset(stat->residencies, 0, &res, 1) )
+        res[0] = NOW() - res[1];
+
+        if ( copy_to_guest_offset(stat->triggers, 0, &usage[0], 2) ||
+            copy_to_guest_offset(stat->residencies, 0, &res[0], 2) )
             return -EFAULT;
 
         stat->pc2 = 0;
@@ -1110,21 +1131,25 @@ int pmstat_get_cx_stat(uint32_t cpuid, s
     {
         if ( i != 0 )
         {
-            usage = power->states[i].usage;
-            res = tick_to_ns(power->states[i].time);
-            idle_usage += usage;
-            idle_res += res;
+            spin_lock_irq(&power->stat_lock);
+            usage[i] = power->states[i].usage;
+            res[i] = tick_to_ns(power->states[i].time);
+            spin_unlock_irq(&power->stat_lock);
+
+            idle_usage += usage[i];
+            idle_res += res[i];
         }
         else
         {
-            usage = idle_usage;
-            res = NOW() - idle_res;
+            usage[i] = idle_usage;
+            res[i] = NOW() - idle_res;
         }
-        if ( copy_to_guest_offset(stat->triggers, i, &usage, 1) ||
-             copy_to_guest_offset(stat->residencies, i, &res, 1) )
-            return -EFAULT;
     }
 
+    if ( copy_to_guest_offset(stat->triggers, 0, &usage[0], power->count) ||
+        copy_to_guest_offset(stat->residencies, 0, &res[0], power->count) )
+        return -EFAULT;
+
     get_hw_residencies(cpuid, &hw_res);
 
     stat->pc2 = hw_res.pc2;
diff -r 6bea63e6c780 -r 390346181927 xen/include/xen/cpuidle.h
--- a/xen/include/xen/cpuidle.h	Sat Jun 02 08:39:45 2012 +0100
+++ b/xen/include/xen/cpuidle.h	Mon Jun 04 19:38:04 2012 +0200
@@ -28,6 +28,7 @@
 #define _XEN_CPUIDLE_H
 
 #include <xen/cpumask.h>
+#include <xen/spinlock.h>
 
 #define ACPI_PROCESSOR_MAX_POWER        8
 #define CPUIDLE_NAME_LEN                16
@@ -69,6 +70,7 @@ struct acpi_processor_power
     void *gdata; /* governor specific data */
     u32 last_residency;
     u32 count;
+    spinlock_t stat_lock;
     struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER];
 };
 


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

From xen-devel-bounces@lists.xen.org Mon Jun 04 18:48:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 18: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 1SbcJd-0004rk-Iw; Mon, 04 Jun 2012 18:47:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SbcJb-0004rf-Ft
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 18:47:43 +0000
Received: from [85.158.143.35:43028] by server-1.bemta-4.messagelabs.com id
	26/44-10042-EC20DCF4; Mon, 04 Jun 2012 18:47:42 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338835660!18744747!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 703 invoked from network); 4 Jun 2012 18:47:41 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jun 2012 18:47:41 -0000
Received: from mail202-va3-R.bigfish.com (10.7.14.240) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 18:47:00 +0000
Received: from mail202-va3 (localhost [127.0.0.1])	by
	mail202-va3-R.bigfish.com (Postfix) with ESMTP id 3FDB5D80248;
	Mon,  4 Jun 2012 18:47:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail202-va3 (localhost.localdomain [127.0.0.1]) by mail202-va3
	(MessageSwitch) id 1338835618210435_10092;
	Mon,  4 Jun 2012 18:46:58 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.239])	by
	mail202-va3.bigfish.com (Postfix) with ESMTP id 3122A64004B;
	Mon,  4 Jun 2012 18:46:58 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server id
	14.1.225.23; Mon, 4 Jun 2012 18:46:57 +0000
X-WSS-ID: 0M53W78-01-66Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2639E102814F;	Mon,  4 Jun 2012 13:47:31 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 4 Jun 2012 13:47:37 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 4 Jun 2012 13:47:31 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 4 Jun 2012
	14:47:30 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C26D949C2B0; Mon,  4 Jun 2012
	19:47:29 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id B1AB12D202B; Mon,
	4 Jun 2012 20:47:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 390346181927d0350f83c4046470a0b9b28c1686
Message-ID: <390346181927d0350f83.1338835629@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 4 Jun 2012 20:47:09 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keir@xen.org>, <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpm,
 x86: Fix reporting of idle state average residency times
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1338831484 -7200
# Node ID 390346181927d0350f83c4046470a0b9b28c1686
# Parent  6bea63e6c780de6303361e5f190d6925996cd2a2
xenpm, x86: Fix reporting of idle state average residency times

If CPU stays in the same idle state for the full duration of
xenpm sample then average residency may not be reported correctly
since usage counter will not be incremented.

In addition, in order to calculate averages correctly residence
time and usage counter should be read and written atomically.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 6bea63e6c780 -r 390346181927 tools/misc/xenpm.c
--- a/tools/misc/xenpm.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/misc/xenpm.c	Mon Jun 04 19:38:04 2012 +0200
@@ -389,7 +389,14 @@ static void signal_int_handler(int signo
                 res = ( diff >= 0 ) ? diff : 0;
                 triggers = cxstat_end[i].triggers[j] -
                     cxstat_start[i].triggers[j];
-                avg_res = (triggers==0) ? 0: (double)res/triggers/1000000.0;
+                /* 
+                 * triggers may be zero if the CPU has been in this state for
+                 * the whole sample or if it never entered the state
+                 */
+                if ( triggers == 0 && cxstat_end[i].last == j )
+                    avg_res =  (double)sum_cx[i]/1000000.0;
+                else
+                    avg_res = (triggers==0) ? 0: (double)res/triggers/1000000.0;
                 printf("  C%d\t%"PRIu64"\t(%5.2f%%)\t%.2f\n", j, res/1000000UL,
                         100 * res / (double)sum_cx[i], avg_res );
             }
diff -r 6bea63e6c780 -r 390346181927 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/xen/arch/x86/acpi/cpu_idle.c	Mon Jun 04 19:38:04 2012 +0200
@@ -165,29 +165,35 @@ static void print_acpi_power(uint32_t cp
 {
     uint32_t i, idle_usage = 0;
     uint64_t res, idle_res = 0;
+    u32 usage;
+    u8 last_state_idx;
 
     printk("==cpu%d==\n", cpu);
-    printk("active state:\t\tC%d\n",
-           power->last_state ? power->last_state->idx : -1);
+    last_state_idx = power->last_state ? power->last_state->idx : -1;
+    printk("active state:\t\tC%d\n", last_state_idx);
     printk("max_cstate:\t\tC%d\n", max_cstate);
     printk("states:\n");
     
     for ( i = 1; i < power->count; i++ )
     {
+        spin_lock_irq(&power->stat_lock);	
         res = tick_to_ns(power->states[i].time);
-        idle_usage += power->states[i].usage;
+        usage = power->states[i].usage;
+        spin_unlock_irq(&power->stat_lock);
+
+        idle_usage += usage;
         idle_res += res;
 
-        printk((power->last_state && power->last_state->idx == i) ?
-               "   *" : "    ");
+        printk((last_state_idx == i) ? "   *" : "    ");
         printk("C%d:\t", i);
         printk("type[C%d] ", power->states[i].type);
         printk("latency[%03d] ", power->states[i].latency);
-        printk("usage[%08d] ", power->states[i].usage);
+        printk("usage[%08d] ", usage);
         printk("method[%5s] ", acpi_cstate_method_name[power->states[i].entry_method]);
         printk("duration[%"PRId64"]\n", res);
     }
-    printk("    C0:\tusage[%08d] duration[%"PRId64"]\n",
+    printk((last_state_idx == 0) ? "   *" : "    ");
+    printk("C0:\tusage[%08d] duration[%"PRId64"]\n",
            idle_usage, NOW() - idle_res);
 
     print_hw_residencies(cpu);
@@ -384,12 +390,29 @@ bool_t errata_c6_eoi_workaround(void)
     return (fix_needed && cpu_has_pending_apic_eoi());
 }
 
+static inline void acpi_update_idle_stats(struct acpi_processor_power *power,
+                                          struct acpi_processor_cx *cx,
+                                          int64_t sleep_ticks)
+{
+    /* Interrupts are disabled */
+
+    spin_lock(&power->stat_lock);
+
+    cx->usage++;
+    if ( sleep_ticks > 0 )
+    {
+        power->last_residency = tick_to_ns(sleep_ticks) / 1000UL;
+        cx->time += sleep_ticks;
+    }
+
+    spin_unlock(&power->stat_lock);
+}
+
 static void acpi_processor_idle(void)
 {
     struct acpi_processor_power *power = processor_powers[smp_processor_id()];
     struct acpi_processor_cx *cx = NULL;
     int next_state;
-    int64_t sleep_ticks = 0;
     uint64_t t1, t2 = 0;
     u32 exp = 0, pred = 0;
     u32 irq_traced[4] = { 0 };
@@ -462,10 +485,10 @@ static void acpi_processor_idle(void)
             /* Trace cpu idle exit */
             TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
                      irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
+            /* Update statistics */
+            acpi_update_idle_stats(power, cx, ticks_elapsed(t1, t2));
             /* Re-enable interrupts */
             local_irq_enable();
-            /* Compute time (ticks) that we were actually asleep */
-            sleep_ticks = ticks_elapsed(t1, t2);
             break;
         }
 
@@ -537,28 +560,26 @@ static void acpi_processor_idle(void)
         TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
                  irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);
 
+        /* Update statistics */
+        acpi_update_idle_stats(power, cx, ticks_elapsed(t1, t2));
         /* Re-enable interrupts */
         local_irq_enable();
         /* recovering APIC */
         lapic_timer_on();
-        /* Compute time (ticks) that we were actually asleep */
-        sleep_ticks = ticks_elapsed(t1, t2);
 
         break;
 
     default:
+        /* Now in C0 */
+        power->last_state = &power->states[0];
         local_irq_enable();
         sched_tick_resume();
         cpufreq_dbs_timer_resume();
         return;
     }
 
-    cx->usage++;
-    if ( sleep_ticks > 0 )
-    {
-        power->last_residency = tick_to_ns(sleep_ticks) / 1000UL;
-        cx->time += sleep_ticks;
-    }
+    /* Now in C0 */
+    power->last_state = &power->states[0];
 
     sched_tick_resume();
     cpufreq_dbs_timer_resume();
@@ -662,6 +683,7 @@ static int cpuidle_init_cpu(int cpu)
     acpi_power->states[1].type = ACPI_STATE_C1;
     acpi_power->states[1].entry_method = ACPI_CSTATE_EM_HALT;
     acpi_power->safe_state = &acpi_power->states[1];
+    spin_lock_init(&acpi_power->stat_lock);
 
     return 0;
 }
@@ -1064,7 +1086,8 @@ uint32_t pmstat_get_cx_nr(uint32_t cpuid
 int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat)
 {
     struct acpi_processor_power *power = processor_powers[cpuid];
-    uint64_t usage, res, idle_usage = 0, idle_res = 0;
+    uint64_t idle_usage = 0, idle_res = 0;
+    uint64_t usage[ACPI_PROCESSOR_MAX_POWER], res[ACPI_PROCESSOR_MAX_POWER];
     int i;
     struct hw_residencies hw_res;
 
@@ -1084,16 +1107,14 @@ int pmstat_get_cx_stat(uint32_t cpuid, s
     if ( pm_idle_save == NULL )
     {
         /* C1 */
-        usage = 1;
-        res = stat->idle_time;
-        if ( copy_to_guest_offset(stat->triggers, 1, &usage, 1) ||
-             copy_to_guest_offset(stat->residencies, 1, &res, 1) )
-            return -EFAULT;
+        usage[1] = 1;
+        res[1] = stat->idle_time;
 
         /* C0 */
-        res = NOW() - res;
-        if ( copy_to_guest_offset(stat->triggers, 0, &usage, 1) ||
-             copy_to_guest_offset(stat->residencies, 0, &res, 1) )
+        res[0] = NOW() - res[1];
+
+        if ( copy_to_guest_offset(stat->triggers, 0, &usage[0], 2) ||
+            copy_to_guest_offset(stat->residencies, 0, &res[0], 2) )
             return -EFAULT;
 
         stat->pc2 = 0;
@@ -1110,21 +1131,25 @@ int pmstat_get_cx_stat(uint32_t cpuid, s
     {
         if ( i != 0 )
         {
-            usage = power->states[i].usage;
-            res = tick_to_ns(power->states[i].time);
-            idle_usage += usage;
-            idle_res += res;
+            spin_lock_irq(&power->stat_lock);
+            usage[i] = power->states[i].usage;
+            res[i] = tick_to_ns(power->states[i].time);
+            spin_unlock_irq(&power->stat_lock);
+
+            idle_usage += usage[i];
+            idle_res += res[i];
         }
         else
         {
-            usage = idle_usage;
-            res = NOW() - idle_res;
+            usage[i] = idle_usage;
+            res[i] = NOW() - idle_res;
         }
-        if ( copy_to_guest_offset(stat->triggers, i, &usage, 1) ||
-             copy_to_guest_offset(stat->residencies, i, &res, 1) )
-            return -EFAULT;
     }
 
+    if ( copy_to_guest_offset(stat->triggers, 0, &usage[0], power->count) ||
+        copy_to_guest_offset(stat->residencies, 0, &res[0], power->count) )
+        return -EFAULT;
+
     get_hw_residencies(cpuid, &hw_res);
 
     stat->pc2 = hw_res.pc2;
diff -r 6bea63e6c780 -r 390346181927 xen/include/xen/cpuidle.h
--- a/xen/include/xen/cpuidle.h	Sat Jun 02 08:39:45 2012 +0100
+++ b/xen/include/xen/cpuidle.h	Mon Jun 04 19:38:04 2012 +0200
@@ -28,6 +28,7 @@
 #define _XEN_CPUIDLE_H
 
 #include <xen/cpumask.h>
+#include <xen/spinlock.h>
 
 #define ACPI_PROCESSOR_MAX_POWER        8
 #define CPUIDLE_NAME_LEN                16
@@ -69,6 +70,7 @@ struct acpi_processor_power
     void *gdata; /* governor specific data */
     u32 last_residency;
     u32 count;
+    spinlock_t stat_lock;
     struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER];
 };
 


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

From xen-devel-bounces@lists.xen.org Mon Jun 04 19:01:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 19:01: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 1SbcWC-00056x-2k; Mon, 04 Jun 2012 19:00:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil.rao@ericsson.com>) id 1SbcWA-00056s-4X
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 19:00:42 +0000
Received: from [85.158.143.99:42922] by server-3.bemta-4.messagelabs.com id
	9B/22-29237-9D50DCF4; Mon, 04 Jun 2012 19:00:41 +0000
X-Env-Sender: anil.rao@ericsson.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338836438!31282667!1
X-Originating-IP: [198.24.6.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjI0LjYuOSA9PiAyNDc4MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14590 invoked from network); 4 Jun 2012 19:00:40 -0000
Received: from imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.9)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jun 2012 19:00:40 -0000
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181])
	by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q54J0YOo001033
	for <xen-devel@lists.xensource.com>; Mon, 4 Jun 2012 14:00:36 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by
	eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi;
	Mon, 4 Jun 2012 15:00:31 -0400
From: Anil Rao <anil.rao@ericsson.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 4 Jun 2012 15:00:31 -0400
Thread-Topic: PCI hotplug related issues
Thread-Index: Ac1ChFAWKRNzJ2HnRoGNcNhtTq9Xmg==
Message-ID: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
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] PCI hotplug related 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: multipart/mixed; boundary="===============3857852369897448374=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3857852369897448374==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_DD729E174A25344F8D7D351BA4CF57272DAD45DB0EEUSAACMS0715e_"

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

Hello,

I am encountering an interesting problem when using PCI-hotplug to assign d=
evices to a VM (HVM) in a Xen environment (SLES 11 SP2).

1. If the VM is powered on before the PCI device is brought on-line, the gu=
est OS is unable to see the device (I have tried using
    the acpiphp/pciehp drivers in the guest OS, as well as manually rescann=
ing the PCI bus from within the VM).

    However, Xen reports that the hot-plug operation was successful. When I=
 try to verify the PCI device state from Xen's perspective
    by looking  at a) the list of (remaining) assignable devices and b) lis=
t of devices attached to the VM, the xm and xl tool-sets report
    that the PCI device is indeed assigned to the VM.

2. If the VM is powered on after the PCI device (an FPGA in this case) is b=
rought on-line, the guest OS inside the VM can see and
    configure the device as expected (using the appropriate driver for the =
device).

Upon examining the output of /var/log/xen/qemu-dm-VMName.log, I see that in=
 the former case QEMU returned a failure, while in the latter case it repor=
ted success (see below).


Case 1: VM was powered on 'before' PCI device (FPGA) was brought on-line
---------------------------------------------------------------------------=
----------------------------------
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01:00.0 ...
register_real_device: Error: couldn't locate device in libpci structures


Case 2: VM was powered on 'after' PCI device (FPGA) was brought on-line
---------------------------------------------------------------------------=
-------------------------------
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01: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: 0x1:0x0.0x0
pt_register_regions: IO region registered (size=3D0x00100000 base_addr=3D0x=
c6000000)
pt_register_regions: IO region registered (size=3D0x00100000 base_addr=3D0x=
c6100000)
pt_msi_setup: msi mapped with pirq 84 pci_intx: intx=3D1
register_real_device: Real physical device 01:00.0 registered successfuly!

I have seen this behavior when running both WindRiver and Ubuntu based oper=
ating environments inside the VM. It doesn't seem related to the type of gu=
est OS.

I have two questions, that I hoped someone on this list can answer for me.

A) Does Xen support case 1 (hotplugging a PCI device to a running VM that w=
as powered-on before the device was added to
    the host)?

B) Why is Xen reporting that the hotplug operation was successful and that =
the device is assigned to the VM, when QEMU reported
    an error? Shouldn't the Xen hotplug operation have failed as well?

Any help on this matter will be most appreciated.

Thanks.
-Anil


--_000_DD729E174A25344F8D7D351BA4CF57272DAD45DB0EEUSAACMS0715e_
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"Arial, sans-serif" size=3D"2">
<div>Hello,</div>
<div>&nbsp;</div>
<div>I am encountering an interesting problem when using PCI-hotplug to ass=
ign devices to a VM (HVM) in a Xen environment (SLES 11 SP2). </div>
<div>&nbsp;</div>
<div>1. If the VM is powered on before the PCI device is brought on-line, t=
he guest OS is unable to see the device (I have tried using </div>
<div>&nbsp;&nbsp;&nbsp; the acpiphp/pciehp drivers in the guest OS, as well=
 as manually rescanning the PCI bus from within the VM). </div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp; However, Xen reports that the hot-plug operation wa=
s successful. When I try to verify the PCI device state from Xen's perspect=
ive </div>
<div>&nbsp;&nbsp;&nbsp; by looking&nbsp; at a) the list of (remaining) assi=
gnable devices and b) list of devices attached to the VM, the xm and xl too=
l-sets report </div>
<div>&nbsp;&nbsp;&nbsp; that the PCI device is indeed assigned to the VM.</=
div>
<div>&nbsp;</div>
<div>2. If the VM is powered on after the PCI device (an FPGA in this case)=
 is brought on-line, the guest OS inside the VM can see and</div>
<div>&nbsp;&nbsp;&nbsp; configure the device as expected (using the appropr=
iate driver for the device).</div>
<div>&nbsp;</div>
<div>Upon examining the output of /var/log/xen/qemu-dm-VMName.log, I see th=
at in the former case QEMU returned a failure, while in the latter case it =
reported success (see below).</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Case 1: VM was powered on 'before' PCI device (FPGA) was brought on-li=
ne</div>
<div>----------------------------------------------------------------------=
---------------------------------------</div>
<div>dm-command: hot insert pass-through pci dev</div>
<div>register_real_device: Assigning real physical device 01:00.0 ...</div>
<div>register_real_device: Error: couldn't locate device in libpci structur=
es</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Case 2: VM was powered on 'after' PCI device (FPGA) was brought on-lin=
e</div>
<div>----------------------------------------------------------------------=
------------------------------------</div>
<div>dm-command: hot insert pass-through pci dev</div>
<div>register_real_device: Assigning real physical device 01:00.0 ...</div>
<div>register_real_device: Enable MSI translation via per device option</di=
v>
<div>register_real_device: Disable power management</div>
<div>pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul=
: No such file or directory: 0x1:0x0.0x0</div>
<div>pt_register_regions: IO region registered (size=3D0x00100000 base_addr=
=3D0xc6000000)</div>
<div>pt_register_regions: IO region registered (size=3D0x00100000 base_addr=
=3D0xc6100000)</div>
<div>pt_msi_setup: msi mapped with pirq 84 pci_intx: intx=3D1</div>
<div>register_real_device: Real physical device 01:00.0 registered successf=
uly!</div>
<div>&nbsp;</div>
<div>I have seen this behavior when running both WindRiver and Ubuntu based=
 operating environments inside the VM. It doesn't seem related to the type =
of guest OS.</div>
<div>&nbsp;</div>
<div>I have two questions, that I hoped someone on this list can answer for=
 me.</div>
<div>&nbsp;</div>
<div>A) Does Xen support case 1 (hotplugging a PCI device to a running VM t=
hat was powered-on before the device was added to</div>
<div>&nbsp;&nbsp;&nbsp; the host)?</div>
<div>&nbsp;</div>
<div>B) Why is Xen reporting that the hotplug operation was successful and =
that the device is assigned to the VM, when QEMU reported</div>
<div>&nbsp;&nbsp;&nbsp; an error? Shouldn't the Xen hotplug operation have =
failed as well?</div>
<div>&nbsp;</div>
<div>Any help on this matter will be most appreciated.</div>
<div>&nbsp;</div>
<div>Thanks.</div>
<div>-Anil</div>
<div>&nbsp;</div>
</font>
</body>
</html>

--_000_DD729E174A25344F8D7D351BA4CF57272DAD45DB0EEUSAACMS0715e_--


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

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

--===============3857852369897448374==--


From xen-devel-bounces@lists.xen.org Mon Jun 04 19:01:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 19:01: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 1SbcWC-00056x-2k; Mon, 04 Jun 2012 19:00:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil.rao@ericsson.com>) id 1SbcWA-00056s-4X
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 19:00:42 +0000
Received: from [85.158.143.99:42922] by server-3.bemta-4.messagelabs.com id
	9B/22-29237-9D50DCF4; Mon, 04 Jun 2012 19:00:41 +0000
X-Env-Sender: anil.rao@ericsson.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338836438!31282667!1
X-Originating-IP: [198.24.6.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjI0LjYuOSA9PiAyNDc4MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14590 invoked from network); 4 Jun 2012 19:00:40 -0000
Received: from imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.9)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jun 2012 19:00:40 -0000
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181])
	by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q54J0YOo001033
	for <xen-devel@lists.xensource.com>; Mon, 4 Jun 2012 14:00:36 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by
	eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi;
	Mon, 4 Jun 2012 15:00:31 -0400
From: Anil Rao <anil.rao@ericsson.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 4 Jun 2012 15:00:31 -0400
Thread-Topic: PCI hotplug related issues
Thread-Index: Ac1ChFAWKRNzJ2HnRoGNcNhtTq9Xmg==
Message-ID: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
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] PCI hotplug related 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: multipart/mixed; boundary="===============3857852369897448374=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3857852369897448374==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_DD729E174A25344F8D7D351BA4CF57272DAD45DB0EEUSAACMS0715e_"

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

Hello,

I am encountering an interesting problem when using PCI-hotplug to assign d=
evices to a VM (HVM) in a Xen environment (SLES 11 SP2).

1. If the VM is powered on before the PCI device is brought on-line, the gu=
est OS is unable to see the device (I have tried using
    the acpiphp/pciehp drivers in the guest OS, as well as manually rescann=
ing the PCI bus from within the VM).

    However, Xen reports that the hot-plug operation was successful. When I=
 try to verify the PCI device state from Xen's perspective
    by looking  at a) the list of (remaining) assignable devices and b) lis=
t of devices attached to the VM, the xm and xl tool-sets report
    that the PCI device is indeed assigned to the VM.

2. If the VM is powered on after the PCI device (an FPGA in this case) is b=
rought on-line, the guest OS inside the VM can see and
    configure the device as expected (using the appropriate driver for the =
device).

Upon examining the output of /var/log/xen/qemu-dm-VMName.log, I see that in=
 the former case QEMU returned a failure, while in the latter case it repor=
ted success (see below).


Case 1: VM was powered on 'before' PCI device (FPGA) was brought on-line
---------------------------------------------------------------------------=
----------------------------------
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01:00.0 ...
register_real_device: Error: couldn't locate device in libpci structures


Case 2: VM was powered on 'after' PCI device (FPGA) was brought on-line
---------------------------------------------------------------------------=
-------------------------------
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01: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: 0x1:0x0.0x0
pt_register_regions: IO region registered (size=3D0x00100000 base_addr=3D0x=
c6000000)
pt_register_regions: IO region registered (size=3D0x00100000 base_addr=3D0x=
c6100000)
pt_msi_setup: msi mapped with pirq 84 pci_intx: intx=3D1
register_real_device: Real physical device 01:00.0 registered successfuly!

I have seen this behavior when running both WindRiver and Ubuntu based oper=
ating environments inside the VM. It doesn't seem related to the type of gu=
est OS.

I have two questions, that I hoped someone on this list can answer for me.

A) Does Xen support case 1 (hotplugging a PCI device to a running VM that w=
as powered-on before the device was added to
    the host)?

B) Why is Xen reporting that the hotplug operation was successful and that =
the device is assigned to the VM, when QEMU reported
    an error? Shouldn't the Xen hotplug operation have failed as well?

Any help on this matter will be most appreciated.

Thanks.
-Anil


--_000_DD729E174A25344F8D7D351BA4CF57272DAD45DB0EEUSAACMS0715e_
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"Arial, sans-serif" size=3D"2">
<div>Hello,</div>
<div>&nbsp;</div>
<div>I am encountering an interesting problem when using PCI-hotplug to ass=
ign devices to a VM (HVM) in a Xen environment (SLES 11 SP2). </div>
<div>&nbsp;</div>
<div>1. If the VM is powered on before the PCI device is brought on-line, t=
he guest OS is unable to see the device (I have tried using </div>
<div>&nbsp;&nbsp;&nbsp; the acpiphp/pciehp drivers in the guest OS, as well=
 as manually rescanning the PCI bus from within the VM). </div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp; However, Xen reports that the hot-plug operation wa=
s successful. When I try to verify the PCI device state from Xen's perspect=
ive </div>
<div>&nbsp;&nbsp;&nbsp; by looking&nbsp; at a) the list of (remaining) assi=
gnable devices and b) list of devices attached to the VM, the xm and xl too=
l-sets report </div>
<div>&nbsp;&nbsp;&nbsp; that the PCI device is indeed assigned to the VM.</=
div>
<div>&nbsp;</div>
<div>2. If the VM is powered on after the PCI device (an FPGA in this case)=
 is brought on-line, the guest OS inside the VM can see and</div>
<div>&nbsp;&nbsp;&nbsp; configure the device as expected (using the appropr=
iate driver for the device).</div>
<div>&nbsp;</div>
<div>Upon examining the output of /var/log/xen/qemu-dm-VMName.log, I see th=
at in the former case QEMU returned a failure, while in the latter case it =
reported success (see below).</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Case 1: VM was powered on 'before' PCI device (FPGA) was brought on-li=
ne</div>
<div>----------------------------------------------------------------------=
---------------------------------------</div>
<div>dm-command: hot insert pass-through pci dev</div>
<div>register_real_device: Assigning real physical device 01:00.0 ...</div>
<div>register_real_device: Error: couldn't locate device in libpci structur=
es</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Case 2: VM was powered on 'after' PCI device (FPGA) was brought on-lin=
e</div>
<div>----------------------------------------------------------------------=
------------------------------------</div>
<div>dm-command: hot insert pass-through pci dev</div>
<div>register_real_device: Assigning real physical device 01:00.0 ...</div>
<div>register_real_device: Enable MSI translation via per device option</di=
v>
<div>register_real_device: Disable power management</div>
<div>pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul=
: No such file or directory: 0x1:0x0.0x0</div>
<div>pt_register_regions: IO region registered (size=3D0x00100000 base_addr=
=3D0xc6000000)</div>
<div>pt_register_regions: IO region registered (size=3D0x00100000 base_addr=
=3D0xc6100000)</div>
<div>pt_msi_setup: msi mapped with pirq 84 pci_intx: intx=3D1</div>
<div>register_real_device: Real physical device 01:00.0 registered successf=
uly!</div>
<div>&nbsp;</div>
<div>I have seen this behavior when running both WindRiver and Ubuntu based=
 operating environments inside the VM. It doesn't seem related to the type =
of guest OS.</div>
<div>&nbsp;</div>
<div>I have two questions, that I hoped someone on this list can answer for=
 me.</div>
<div>&nbsp;</div>
<div>A) Does Xen support case 1 (hotplugging a PCI device to a running VM t=
hat was powered-on before the device was added to</div>
<div>&nbsp;&nbsp;&nbsp; the host)?</div>
<div>&nbsp;</div>
<div>B) Why is Xen reporting that the hotplug operation was successful and =
that the device is assigned to the VM, when QEMU reported</div>
<div>&nbsp;&nbsp;&nbsp; an error? Shouldn't the Xen hotplug operation have =
failed as well?</div>
<div>&nbsp;</div>
<div>Any help on this matter will be most appreciated.</div>
<div>&nbsp;</div>
<div>Thanks.</div>
<div>-Anil</div>
<div>&nbsp;</div>
</font>
</body>
</html>

--_000_DD729E174A25344F8D7D351BA4CF57272DAD45DB0EEUSAACMS0715e_--


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

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

--===============3857852369897448374==--


From xen-devel-bounces@lists.xen.org Mon Jun 04 21:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 21: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 1SbfGS-0007ba-B9; Mon, 04 Jun 2012 21:56:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SbfGQ-0007bV-Kx
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 21:56:38 +0000
Received: from [85.158.139.83:3007] by server-1.bemta-5.messagelabs.com id
	F1/E3-25424-51F2DCF4; Mon, 04 Jun 2012 21:56:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338846996!31445885!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDUxMTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDUxMTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2987 invoked from network); 4 Jun 2012 21:56:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jun 2012 21:56:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV71Y=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-5.vodafone-net.de [80.226.24.5])
	by smtp.strato.de (josoe mo32) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V021d4o54LNr2f
	for <xen-devel@lists.xensource.com>;
	Mon, 4 Jun 2012 23:56:34 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 26A7A18637
	for <xen-devel@lists.xensource.com>;
	Mon,  4 Jun 2012 23:56:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 92a75908163cb0c5a46f94360d0e5faecf2e5a3a
Message-Id: <92a75908163cb0c5a46f.1338846971@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 04 Jun 2012 23:56:11 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools: pass EXTRA_CFLAGS via environment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1338846793 -7200
# Node ID 92a75908163cb0c5a46f94360d0e5faecf2e5a3a
# Parent  1e2ce970f0f29af4184d975c4f161f11938070cf
tools: pass EXTRA_CFLAGS via environment

Currently qemu-xen will be compiled with CFLAGS only if CFLAGS was
already in the environment during make invocation. If CFLAGS is in
environment then make will append all of the various flags specified in
xen Makefiles to this environment variable, which is then used in qemu
configure. Since qemu-xen is not ready for compiler flags like
"-std=gnu99" compilation will fail. If CFLAGS is not in environment,
then configure will use just its own "-O2 -g" because make does not
export its own CFLAGS variable.

>From a distro perspective, it is required to build libraries and
binaries with certain global cflags (arbitrary gcc options). Up to the
point when qemu-xen was imported it worked as expected by exporting
CFLAGS before 'make tools'.  Now qemu-upstream reuses these CFLAGS, but
it cant deal with the result.

This patch extends the tools Makefiles so that three new environment
variables are recognized:
  EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
  EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
  EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.

Special care needs to be taken in tools/firmware because the resulting
binaries are not linked with the hosts runtime libraries. These binaries
run in guest context. To avoid build errors from gcc options like
-fstack-protector, reuse existing practice to unset the new
EXTRA_CFLAGS_XEN_TOOLS for the firmware dirs.


The new feature can be used like this in a rpm xen.spec file:

   export EXTRA_CFLAGS_XEN_TOOLS="${RPM_OPT_FLAGS}"
   export EXTRA_CFLAGS_QEMU_TRADITIONAL="${RPM_OPT_FLAGS}"
   export EXTRA_CFLAGS_QEMU_XEN="${RPM_OPT_FLAGS}"
   ./configure \
   	--libdir=%{_libdir} \
   	--prefix=/usr
   make


v5:
 - move EXTRA_CFLAGS_XEN_TOOLS back to tools/Rules.mk
 - unset EXTRA_CFLAGS_XEN_TOOLS in tools/firmware/Rules.mk to avoid patching
   every Makefile in the tree

v4:
 - move EXTRA_CFLAGS_QEMU_XEN to existing --extra-cflags option
 - remove all configure related changes, EXTRA_CFLAGS_* will be
   taken from either environment or as make command line.

v3:
 - move EXTRA_CFLAGS_XEN_TOOLS from rules in tools/Rules.mk to every
   Makefile except firmware because it runs in guest context and can not
   deal with gcc options like -fstack-protector. This turns
   EXTRA_CFLAGS_XEN_TOOLS into a HOST_CFLAGS kind of thing.

v2:
 - add new EXTRA_CFLAGS_XEN_TOOLS variable to config/Tools.mk.in instead
   of modifying CFLAGS in this file. Also remove include order change in
   tools/Rules.mk since its now not needed anymore
 - add EXTRA_CFLAGS_XEN_TOOLS to all rules in tools/Rules.mk
 - update help output in tools/configure.ac

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

diff -r 1e2ce970f0f2 -r 92a75908163c tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -122,7 +122,9 @@ subdir-all-qemu-xen-traditional-dir subd
 	set -e; \
 		$(buildmakevars2shellvars); \
 		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(QEMU_ROOT)/xen-setup \
+		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
+		$(IOEMU_CONFIGURE_CROSS); \
 		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
@@ -151,7 +153,8 @@ subdir-all-qemu-xen-dir subdir-install-q
 		--extra-cflags="-I$(XEN_ROOT)/tools/include \
 		-I$(XEN_ROOT)/tools/libxc \
 		-I$(XEN_ROOT)/tools/xenstore \
-		-I$(XEN_ROOT)/tools/xenstore/compat" \
+		-I$(XEN_ROOT)/tools/xenstore/compat \
+		$(EXTRA_CFLAGS_QEMU_XEN)" \
 		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=$(LIBEXEC) \
diff -r 1e2ce970f0f2 -r 92a75908163c tools/Rules.mk
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -76,6 +76,8 @@ endif
 CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
 CFLAGS += $(CFLAGS-y)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
 check-$(CONFIG_X86) = $(call cc-ver-check,CC,0x030400,\
                         "Xen requires at least gcc-3.4")
diff -r 1e2ce970f0f2 -r 92a75908163c tools/firmware/Rules.mk
--- a/tools/firmware/Rules.mk
+++ b/tools/firmware/Rules.mk
@@ -3,6 +3,7 @@ override XEN_TARGET_ARCH = x86_32
 
 # User-supplied CFLAGS are not useful here.
 CFLAGS =
+EXTRA_CFLAGS_XEN_TOOLS =
 
 include $(XEN_ROOT)/tools/Rules.mk
 

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

From xen-devel-bounces@lists.xen.org Mon Jun 04 21:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Jun 2012 21: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 1SbfGS-0007ba-B9; Mon, 04 Jun 2012 21:56:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SbfGQ-0007bV-Kx
	for xen-devel@lists.xensource.com; Mon, 04 Jun 2012 21:56:38 +0000
Received: from [85.158.139.83:3007] by server-1.bemta-5.messagelabs.com id
	F1/E3-25424-51F2DCF4; Mon, 04 Jun 2012 21:56:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1338846996!31445885!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDUxMTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDUxMTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2987 invoked from network); 4 Jun 2012 21:56:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jun 2012 21:56:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV71Y=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-5.vodafone-net.de [80.226.24.5])
	by smtp.strato.de (josoe mo32) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V021d4o54LNr2f
	for <xen-devel@lists.xensource.com>;
	Mon, 4 Jun 2012 23:56:34 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 26A7A18637
	for <xen-devel@lists.xensource.com>;
	Mon,  4 Jun 2012 23:56:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 92a75908163cb0c5a46f94360d0e5faecf2e5a3a
Message-Id: <92a75908163cb0c5a46f.1338846971@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 04 Jun 2012 23:56:11 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools: pass EXTRA_CFLAGS via environment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1338846793 -7200
# Node ID 92a75908163cb0c5a46f94360d0e5faecf2e5a3a
# Parent  1e2ce970f0f29af4184d975c4f161f11938070cf
tools: pass EXTRA_CFLAGS via environment

Currently qemu-xen will be compiled with CFLAGS only if CFLAGS was
already in the environment during make invocation. If CFLAGS is in
environment then make will append all of the various flags specified in
xen Makefiles to this environment variable, which is then used in qemu
configure. Since qemu-xen is not ready for compiler flags like
"-std=gnu99" compilation will fail. If CFLAGS is not in environment,
then configure will use just its own "-O2 -g" because make does not
export its own CFLAGS variable.

>From a distro perspective, it is required to build libraries and
binaries with certain global cflags (arbitrary gcc options). Up to the
point when qemu-xen was imported it worked as expected by exporting
CFLAGS before 'make tools'.  Now qemu-upstream reuses these CFLAGS, but
it cant deal with the result.

This patch extends the tools Makefiles so that three new environment
variables are recognized:
  EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
  EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
  EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.

Special care needs to be taken in tools/firmware because the resulting
binaries are not linked with the hosts runtime libraries. These binaries
run in guest context. To avoid build errors from gcc options like
-fstack-protector, reuse existing practice to unset the new
EXTRA_CFLAGS_XEN_TOOLS for the firmware dirs.


The new feature can be used like this in a rpm xen.spec file:

   export EXTRA_CFLAGS_XEN_TOOLS="${RPM_OPT_FLAGS}"
   export EXTRA_CFLAGS_QEMU_TRADITIONAL="${RPM_OPT_FLAGS}"
   export EXTRA_CFLAGS_QEMU_XEN="${RPM_OPT_FLAGS}"
   ./configure \
   	--libdir=%{_libdir} \
   	--prefix=/usr
   make


v5:
 - move EXTRA_CFLAGS_XEN_TOOLS back to tools/Rules.mk
 - unset EXTRA_CFLAGS_XEN_TOOLS in tools/firmware/Rules.mk to avoid patching
   every Makefile in the tree

v4:
 - move EXTRA_CFLAGS_QEMU_XEN to existing --extra-cflags option
 - remove all configure related changes, EXTRA_CFLAGS_* will be
   taken from either environment or as make command line.

v3:
 - move EXTRA_CFLAGS_XEN_TOOLS from rules in tools/Rules.mk to every
   Makefile except firmware because it runs in guest context and can not
   deal with gcc options like -fstack-protector. This turns
   EXTRA_CFLAGS_XEN_TOOLS into a HOST_CFLAGS kind of thing.

v2:
 - add new EXTRA_CFLAGS_XEN_TOOLS variable to config/Tools.mk.in instead
   of modifying CFLAGS in this file. Also remove include order change in
   tools/Rules.mk since its now not needed anymore
 - add EXTRA_CFLAGS_XEN_TOOLS to all rules in tools/Rules.mk
 - update help output in tools/configure.ac

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

diff -r 1e2ce970f0f2 -r 92a75908163c tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -122,7 +122,9 @@ subdir-all-qemu-xen-traditional-dir subd
 	set -e; \
 		$(buildmakevars2shellvars); \
 		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(QEMU_ROOT)/xen-setup \
+		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
+		$(IOEMU_CONFIGURE_CROSS); \
 		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
@@ -151,7 +153,8 @@ subdir-all-qemu-xen-dir subdir-install-q
 		--extra-cflags="-I$(XEN_ROOT)/tools/include \
 		-I$(XEN_ROOT)/tools/libxc \
 		-I$(XEN_ROOT)/tools/xenstore \
-		-I$(XEN_ROOT)/tools/xenstore/compat" \
+		-I$(XEN_ROOT)/tools/xenstore/compat \
+		$(EXTRA_CFLAGS_QEMU_XEN)" \
 		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=$(LIBEXEC) \
diff -r 1e2ce970f0f2 -r 92a75908163c tools/Rules.mk
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -76,6 +76,8 @@ endif
 CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs)
 CFLAGS += $(CFLAGS-y)
 
+CFLAGS += $(EXTRA_CFLAGS_XEN_TOOLS)
+
 # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
 check-$(CONFIG_X86) = $(call cc-ver-check,CC,0x030400,\
                         "Xen requires at least gcc-3.4")
diff -r 1e2ce970f0f2 -r 92a75908163c tools/firmware/Rules.mk
--- a/tools/firmware/Rules.mk
+++ b/tools/firmware/Rules.mk
@@ -3,6 +3,7 @@ override XEN_TARGET_ARCH = x86_32
 
 # User-supplied CFLAGS are not useful here.
 CFLAGS =
+EXTRA_CFLAGS_XEN_TOOLS =
 
 include $(XEN_ROOT)/tools/Rules.mk
 

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

From xen-devel-bounces@lists.xen.org Tue Jun 05 06:08:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 06:08: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 1SbmvP-0006nl-1m; Tue, 05 Jun 2012 06:07:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1SbmvO-0006ng-4R
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 06:07:26 +0000
Received: from [85.158.143.99:36899] by server-1.bemta-4.messagelabs.com id
	19/54-10042-D12ADCF4; Tue, 05 Jun 2012 06:07:25 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338876444!24312331!1
X-Originating-IP: [74.125.82.51]
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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24398 invoked from network); 5 Jun 2012 06:07:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 06:07:24 -0000
Received: by wgbed3 with SMTP id ed3so3473029wgb.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 23:07:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=LVSuJiobmR0bA8ZkK8ePDDYUUK3DhK9vAhPNNzv0YgU=;
	b=QUH24U6ePMuRi9mFcrh8owgmsfFfU7H2IRxDhR04RKc+Lu54FDKdv2sfu2rvRIwSce
	Q4U1OEULICtMv9W8Erqsq96YN0JPL+Z/RUtDfQDBx1DhWK2uH4yz9t+wbsu5EYh8UYw8
	SpTju56oV1EcmKGMC6r9LaiOVz+E7nKcnLkJEG1vVbUFw6VTIC5h9JIptZsPuCATo+9j
	jUobRaTy26Ppto2zxHpjYQHTJSR/whKW6XiKpkyMh8RfFi6zFlh0DpoBW0gWB9pOSmCr
	rAT0ZsIbcmoSgTtclt+DnAdbBH1uVyuAyaKdQ0mtbR64UsoUKF8SrCzbeOPWhk6LAcll
	i1wg==
MIME-Version: 1.0
Received: by 10.216.143.200 with SMTP id l50mr12481898wej.58.1338876424923;
	Mon, 04 Jun 2012 23:07:04 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Mon, 4 Jun 2012 23:07:04 -0700 (PDT)
Date: Mon, 4 Jun 2012 23:07:04 -0700
Message-ID: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6209774183111844382=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6209774183111844382==
Content-Type: multipart/alternative; boundary=0016e6dedd8cb4aa3904c1b375f2

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

Hi everyone,
I'm working on a research project. I add a hypercall to xen. It works
properly.
In my Hypercall function I have a label and I want the physical address of
my label to pass to another function. How can I grab the physical address
of the label?

Thanks

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

Hi everyone,<br>I&#39;m working on a research project. I add a hypercall to=
 xen. It works properly. <br>In my Hypercall function I have a label and I =
want the physical address of my label to pass to another function. How can =
I grab the physical address of the label?<br>
<br>Thanks<br>

--0016e6dedd8cb4aa3904c1b375f2--


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

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

--===============6209774183111844382==--


From xen-devel-bounces@lists.xen.org Tue Jun 05 06:08:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 06:08: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 1SbmvP-0006nl-1m; Tue, 05 Jun 2012 06:07:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1SbmvO-0006ng-4R
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 06:07:26 +0000
Received: from [85.158.143.99:36899] by server-1.bemta-4.messagelabs.com id
	19/54-10042-D12ADCF4; Tue, 05 Jun 2012 06:07:25 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338876444!24312331!1
X-Originating-IP: [74.125.82.51]
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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24398 invoked from network); 5 Jun 2012 06:07:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 06:07:24 -0000
Received: by wgbed3 with SMTP id ed3so3473029wgb.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 23:07:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=LVSuJiobmR0bA8ZkK8ePDDYUUK3DhK9vAhPNNzv0YgU=;
	b=QUH24U6ePMuRi9mFcrh8owgmsfFfU7H2IRxDhR04RKc+Lu54FDKdv2sfu2rvRIwSce
	Q4U1OEULICtMv9W8Erqsq96YN0JPL+Z/RUtDfQDBx1DhWK2uH4yz9t+wbsu5EYh8UYw8
	SpTju56oV1EcmKGMC6r9LaiOVz+E7nKcnLkJEG1vVbUFw6VTIC5h9JIptZsPuCATo+9j
	jUobRaTy26Ppto2zxHpjYQHTJSR/whKW6XiKpkyMh8RfFi6zFlh0DpoBW0gWB9pOSmCr
	rAT0ZsIbcmoSgTtclt+DnAdbBH1uVyuAyaKdQ0mtbR64UsoUKF8SrCzbeOPWhk6LAcll
	i1wg==
MIME-Version: 1.0
Received: by 10.216.143.200 with SMTP id l50mr12481898wej.58.1338876424923;
	Mon, 04 Jun 2012 23:07:04 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Mon, 4 Jun 2012 23:07:04 -0700 (PDT)
Date: Mon, 4 Jun 2012 23:07:04 -0700
Message-ID: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6209774183111844382=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6209774183111844382==
Content-Type: multipart/alternative; boundary=0016e6dedd8cb4aa3904c1b375f2

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

Hi everyone,
I'm working on a research project. I add a hypercall to xen. It works
properly.
In my Hypercall function I have a label and I want the physical address of
my label to pass to another function. How can I grab the physical address
of the label?

Thanks

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

Hi everyone,<br>I&#39;m working on a research project. I add a hypercall to=
 xen. It works properly. <br>In my Hypercall function I have a label and I =
want the physical address of my label to pass to another function. How can =
I grab the physical address of the label?<br>
<br>Thanks<br>

--0016e6dedd8cb4aa3904c1b375f2--


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

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

--===============6209774183111844382==--


From xen-devel-bounces@lists.xen.org Tue Jun 05 06:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 06: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 1SbnEp-0007Hw-8x; Tue, 05 Jun 2012 06:27:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SbnEo-0007Hq-2R
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 06:27:30 +0000
Received: from [193.109.254.147:20840] by server-5.bemta-14.messagelabs.com id
	18/2E-31398-1D6ADCF4; Tue, 05 Jun 2012 06:27:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1338877648!10020001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExNjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30274 invoked from network); 5 Jun 2012 06:27:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 06:27:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,716,1330905600"; d="scan'208";a="12829529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jun 2012 06:27:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 5 Jun 2012 07:27:28 +0100
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 1SbnEm-0007AW-4t;
	Tue, 05 Jun 2012 06:27:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SbnEl-0006XS-GW;
	Tue, 05 Jun 2012 07:27:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13016-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Jun 2012 07:27:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13016: 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 13016 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13016/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13015

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 06:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 06: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 1SbnEp-0007Hw-8x; Tue, 05 Jun 2012 06:27:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SbnEo-0007Hq-2R
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 06:27:30 +0000
Received: from [193.109.254.147:20840] by server-5.bemta-14.messagelabs.com id
	18/2E-31398-1D6ADCF4; Tue, 05 Jun 2012 06:27:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1338877648!10020001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExNjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30274 invoked from network); 5 Jun 2012 06:27:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 06:27:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,716,1330905600"; d="scan'208";a="12829529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jun 2012 06:27:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 5 Jun 2012 07:27:28 +0100
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 1SbnEm-0007AW-4t;
	Tue, 05 Jun 2012 06:27:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SbnEl-0006XS-GW;
	Tue, 05 Jun 2012 07:27:27 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13016-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Jun 2012 07:27:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13016: 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 13016 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13016/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13015

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 08:43:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 08:43: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 1SbpLq-00005o-Ik; Tue, 05 Jun 2012 08:42: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 1SbpLp-00005j-0e
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 08:42:53 +0000
Received: from [85.158.143.35:26687] by server-3.bemta-4.messagelabs.com id
	49/47-29237-C86CDCF4; Tue, 05 Jun 2012 08:42:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1338885771!14848947!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13178 invoked from network); 5 Jun 2012 08:42:51 -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; 5 Jun 2012 08:42:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Jun 2012 09:42:51 +0100
Message-Id: <4FCDE2A902000078000883C3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 05 Jun 2012 09:42:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anil Rao" <anil.rao@ericsson.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
In-Reply-To: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 04.06.12 at 21:00, Anil Rao <anil.rao@ericsson.com> wrote:
> A) Does Xen support case 1 (hotplugging a PCI device to a running VM that 
> was powered-on before the device was added to
>     the host)?

As far as I'm aware, only hotplug from the perspective of the guest
is really supported/tested.

But the issue here really seems less Xen related, but more towards
libpci behavior (as according to qemu this is where the device isn't
known). As that's a component Xen/qemu-dm simply builds upon,
failure there (e.g. lack of hotplug awareness) would surface as a
Xen misbehavior. Quickly going through the list of provided symbols
of libpci.so doesn't show anything that looks hotplug related (e.g.
some sort of notification registration). But of course it's possible
that I'm overlooking something here, and that in fact qemu-dm's
interaction with libpci is simply incomplete.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 08:43:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 08:43: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 1SbpLq-00005o-Ik; Tue, 05 Jun 2012 08:42: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 1SbpLp-00005j-0e
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 08:42:53 +0000
Received: from [85.158.143.35:26687] by server-3.bemta-4.messagelabs.com id
	49/47-29237-C86CDCF4; Tue, 05 Jun 2012 08:42:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1338885771!14848947!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13178 invoked from network); 5 Jun 2012 08:42:51 -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; 5 Jun 2012 08:42:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Jun 2012 09:42:51 +0100
Message-Id: <4FCDE2A902000078000883C3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 05 Jun 2012 09:42:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anil Rao" <anil.rao@ericsson.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
In-Reply-To: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 04.06.12 at 21:00, Anil Rao <anil.rao@ericsson.com> wrote:
> A) Does Xen support case 1 (hotplugging a PCI device to a running VM that 
> was powered-on before the device was added to
>     the host)?

As far as I'm aware, only hotplug from the perspective of the guest
is really supported/tested.

But the issue here really seems less Xen related, but more towards
libpci behavior (as according to qemu this is where the device isn't
known). As that's a component Xen/qemu-dm simply builds upon,
failure there (e.g. lack of hotplug awareness) would surface as a
Xen misbehavior. Quickly going through the list of provided symbols
of libpci.so doesn't show anything that looks hotplug related (e.g.
some sort of notification registration). But of course it's possible
that I'm overlooking something here, and that in fact qemu-dm's
interaction with libpci is simply incomplete.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 11:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 11: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 1SbrnX-0000mD-MN; Tue, 05 Jun 2012 11:19:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SbrnV-0000m7-Qx
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 11:19:38 +0000
Received: from [85.158.143.35:4569] by server-1.bemta-4.messagelabs.com id
	F4/9A-10042-84BEDCF4; Tue, 05 Jun 2012 11:19:36 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338895174!8440742!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4961 invoked from network); 5 Jun 2012 11:19:35 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 11:19:35 -0000
Received: by yenq11 with SMTP id q11so4795443yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Jun 2012 04:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=RblCqe9Z5Lit+5woPQ0u4T+wuvaaY46Gi5VZMHc+lGI=;
	b=ohcM+CzMd02MPe+omrMMBfyBzBmkD4/Q0nRBuL0AKLrjSrXMjmm/QhelrEVzqzvweh
	YF11kSy4QlEatBaxqGBoLz9GWOTly+ockwcvFhMyuI+Qo4B0opoKPadzGqndVoeNnnyX
	gVlkfJG0IEDOB8dcapXbfbibqnVPZFlI3WgZYoveJ1XtkpzdW2Nskx3g7jKsdN75xIp3
	cv8oWiUV4mmPhWTWXcFSmAHrAtwO6BcUWKtESA/Kbc5EO3wddX8xzT/0IL+d2qHsUivy
	OwDr+9vcQsJFmWDsTh1GyBcST88hug3jPTCx0wNZge8H+Ae9uyR9Ar92+CVDdnziHT5N
	WuWQ==
MIME-Version: 1.0
Received: by 10.60.13.134 with SMTP id h6mr15365028oec.11.1338895174446; Tue,
	05 Jun 2012 04:19:34 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Tue, 5 Jun 2012 04:19:33 -0700 (PDT)
Date: Tue, 5 Jun 2012 19:19:33 +0800
Message-ID: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=e89a8fb1ebb643af7b04c1b7d38c
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	"ian.jackson" <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel]  [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

changeset:   25453:7bd08f83a2ce
user:        Zhou Peng <ailvpeng25@gmail.com>
date:        Tue Jun 05 17:39:37 2012 +0800
files:       tools/libxl/libxl.h tools/libxl/libxl_create.c
tools/libxl/libxl_dm.c tools/libxl/libxl_types.idl
tools/libxl/xl_cmdimpl.c tools/libxl/xl_sxp.c
description:
tools:libxl: refactor stdvga opinon support.

Be ready to add and describe new vga interface

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>


diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl.h	Tue Jun 05 17:39:37 2012 +0800
@@ -342,6 +342,7 @@ typedef struct libxl__ctx libxl_ctx;

 #define LIBXL_TIMER_MODE_DEFAULT -1
 #define LIBXL_MEMKB_DEFAULT ~0ULL
+#define LIBXL_VGA_INTERFACE_TYPE_DEFAULT -1

 #include "_libxl_types.h"

diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl_create.c	Tue Jun 05 17:39:37 2012 +0800
@@ -193,7 +193,8 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }

-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
+            b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Tue Jun 05 17:39:37 2012 +0800
@@ -175,8 +175,13 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
+
+        switch (b_info->u.hvm.vga.type) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
             flexarray_append(dm_args, "-std-vga");
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
         }

         if (b_info->u.hvm.boot) {
@@ -418,8 +423,13 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }

-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
-                flexarray_vappend(dm_args, "-vga", "std", NULL);
+        switch (b_info->u.hvm.vga.type) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
+            flexarray_vappend(dm_args, "-vga", "std", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
         }

         if (b_info->u.hvm.boot) {
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Jun 05 17:39:37 2012 +0800
@@ -125,9 +125,19 @@ libxl_shutdown_reason = Enumeration("shu
     (4, "watchdog"),
     ])

+libxl_vga_interface_type = Enumeration("vga_interface_type", [
+    (0, "CIRRUS"),
+    (1, "STD"),
+    ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
+
 #
 # Complex libxl types
 #
+
+libxl_vga_interface_info = Struct("vga_interface_info", [
+    ("type",    libxl_vga_interface_type),
+    ])
+
 libxl_vnc_info = Struct("vnc_info", [
     ("enable",        libxl_defbool),
     # "address:port" that should be listened on
@@ -281,7 +291,7 @@ libxl_domain_build_info = Struct("domain
                                        ("nested_hvm",       libxl_defbool),
                                        ("incr_generationid",libxl_defbool),
                                        ("nographic",        libxl_defbool),
-                                       ("stdvga",           libxl_defbool),
+                                       ("vga",
libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is
en-us keyboard
                                        ("keymap",           string),
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
@@ -1256,7 +1256,10 @@ skip_vfb:
 #undef parse_extra_args

     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+            if (l)
+                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Tue Jun 05 17:39:37 2012 +0800
@@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-        printf("\t\t\t(stdvga %s)\n",
-               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type ==
+                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
+                                      "True" : "False");
         printf("\t\t\t(vnc %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);


-- 
Zhou Peng

--e89a8fb1ebb643af7b04c1b7d38c
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.stdvga.refactor.v2.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.stdvga.refactor.v2.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h32vk5rr0

Y2hhbmdlc2V0OiAgIDI1NDUzOjdiZDA4ZjgzYTJjZQp1c2VyOiAgICAgICAgWmhvdSBQZW5nIDxh
aWx2cGVuZzI1QGdtYWlsLmNvbT4KZGF0ZTogICAgICAgIFR1ZSBKdW4gMDUgMTc6Mzk6MzcgMjAx
MiArMDgwMApmaWxlczogICAgICAgdG9vbHMvbGlieGwvbGlieGwuaCB0b29scy9saWJ4bC9saWJ4
bF9jcmVhdGUuYyB0b29scy9saWJ4bC9saWJ4bF9kbS5jIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVz
LmlkbCB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMgdG9vbHMvbGlieGwveGxfc3hwLmMKZGVzY3Jp
cHRpb246CnRvb2xzOmxpYnhsOiByZWZhY3RvciBzdGR2Z2Egb3Bpbm9uIHN1cHBvcnQuCgpCZSBy
ZWFkeSB0byBhZGQgYW5kIGRlc2NyaWJlIG5ldyB2Z2EgaW50ZXJmYWNlCgpTaWduZWQtb2ZmLWJ5
OiBaaG91IFBlbmcgPGFpbHZwZW5nMjVAZ21haWwuY29tPgoKCmRpZmYgLXIgNmJlYTYzZTZjNzgw
IC1yIDdiZDA4ZjgzYTJjZSB0b29scy9saWJ4bC9saWJ4bC5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xp
YnhsLmgJU2F0IEp1biAwMiAwODozOTo0NSAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xpYnhsL2xp
YnhsLmgJVHVlIEp1biAwNSAxNzozOTozNyAyMDEyICswODAwCkBAIC0zNDIsNiArMzQyLDcgQEAg
dHlwZWRlZiBzdHJ1Y3QgbGlieGxfX2N0eCBsaWJ4bF9jdHg7CiAKICNkZWZpbmUgTElCWExfVElN
RVJfTU9ERV9ERUZBVUxUIC0xCiAjZGVmaW5lIExJQlhMX01FTUtCX0RFRkFVTFQgfjBVTEwKKyNk
ZWZpbmUgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0RFRkFVTFQgLTEKIAogI2luY2x1ZGUgIl9s
aWJ4bF90eXBlcy5oIgogCmRpZmYgLXIgNmJlYTYzZTZjNzgwIC1yIDdiZDA4ZjgzYTJjZSB0b29s
cy9saWJ4bC9saWJ4bF9jcmVhdGUuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlT
YXQgSnVuIDAyIDA4OjM5OjQ1IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3Jl
YXRlLmMJVHVlIEp1biAwNSAxNzozOTozNyAyMDEyICswODAwCkBAIC0xOTMsNyArMTkzLDggQEAg
aW50IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgICAgICAgICAgaWYg
KCFiX2luZm8tPnUuaHZtLmJvb3QpIHJldHVybiBFUlJPUl9OT01FTTsKICAgICAgICAgfQogCi0g
ICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIGZh
bHNlKTsKKyAgICAgICAgaWYgKGJfaW5mby0+dS5odm0udmdhLnR5cGUgPT0gTElCWExfVkdBX0lO
VEVSRkFDRV9UWVBFX0RFRkFVTFQpCisgICAgICAgICAgICBiX2luZm8tPnUuaHZtLnZnYS50eXBl
ID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJUlJVUzsKICAgICAgICAgbGlieGxfZGVmYm9v
bF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIHRydWUpOwogICAgICAgICBp
ZiAobGlieGxfZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxlKSkgewogICAgICAg
ICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnZuYy5maW5kdW51
c2VkLCB0cnVlKTsKZGlmZiAtciA2YmVhNjNlNmM3ODAgLXIgN2JkMDhmODNhMmNlIHRvb2xzL2xp
YnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlTYXQgSnVuIDAyIDA4
OjM5OjQ1IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlUdWUgSnVuIDA1
IDE3OjM5OjM3IDIwMTIgKzA4MDAKQEAgLTE3NSw4ICsxNzUsMTMgQEAgc3RhdGljIGNoYXIgKiog
bGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBsaWJ4bF9fc2l6ZWtiX3RvX21iKGJfaW5mby0+dmlkZW9fbWVta2IpKSwKICAgICAgICAg
ICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgIH0KLSAgICAgICAgaWYgKGxpYnhsX2RlZmJvb2xf
dmFsKGJfaW5mby0+dS5odm0uc3RkdmdhKSkgeworCisgICAgICAgIHN3aXRjaCAoYl9pbmZvLT51
Lmh2bS52Z2EudHlwZSkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9T
VEQ6CiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItc3RkLXZnYSIpOwor
ICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBF
X0NJUlJVUzoKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJf
aW5mby0+dS5odm0uYm9vdCkgewpAQCAtNDE4LDggKzQyMywxMyBAQCBzdGF0aWMgY2hhciAqKiBs
aWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRt
X2FyZ3MsIHNwaWNlb3B0aW9ucyk7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAobGlieGxfZGVm
Ym9vbF92YWwoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKSB7Ci0gICAgICAgICAgICAgICAgZmxleGFy
cmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAic3RkIiwgTlVMTCk7CisgICAgICAgIHN3aXRj
aCAoYl9pbmZvLT51Lmh2bS52Z2EudHlwZSkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRF
UkZBQ0VfVFlQRV9TVEQ6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdzLCAi
LXZnYSIsICJzdGQiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICBjYXNlIExJ
QlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFw
cGVuZChkbV9hcmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFr
OwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0uYm9vdCkgewpkaWZmIC1y
IDZiZWE2M2U2Yzc4MCAtciA3YmQwOGY4M2EyY2UgdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRs
Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlTYXQgSnVuIDAyIDA4OjM5OjQ1IDIw
MTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVR1ZSBKdW4gMDUgMTc6
Mzk6MzcgMjAxMiArMDgwMApAQCAtMTI1LDkgKzEyNSwxOSBAQCBsaWJ4bF9zaHV0ZG93bl9yZWFz
b24gPSBFbnVtZXJhdGlvbigic2h1CiAgICAgKDQsICJ3YXRjaGRvZyIpLAogICAgIF0pCiAKK2xp
YnhsX3ZnYV9pbnRlcmZhY2VfdHlwZSA9IEVudW1lcmF0aW9uKCJ2Z2FfaW50ZXJmYWNlX3R5cGUi
LCBbCisgICAgKDAsICJDSVJSVVMiKSwKKyAgICAoMSwgIlNURCIpLAorICAgIF0sIGluaXRfdmFs
ID0gIkxJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9ERUZBVUxUIikKKwogIwogIyBDb21wbGV4IGxp
YnhsIHR5cGVzCiAjCisKK2xpYnhsX3ZnYV9pbnRlcmZhY2VfaW5mbyA9IFN0cnVjdCgidmdhX2lu
dGVyZmFjZV9pbmZvIiwgWworICAgICgidHlwZSIsICAgIGxpYnhsX3ZnYV9pbnRlcmZhY2VfdHlw
ZSksCisgICAgXSkKKwogbGlieGxfdm5jX2luZm8gPSBTdHJ1Y3QoInZuY19pbmZvIiwgWwogICAg
ICgiZW5hYmxlIiwgICAgICAgIGxpYnhsX2RlZmJvb2wpLAogICAgICMgImFkZHJlc3M6cG9ydCIg
dGhhdCBzaG91bGQgYmUgbGlzdGVuZWQgb24KQEAgLTI4MSw3ICsyOTEsNyBAQCBsaWJ4bF9kb21h
aW5fYnVpbGRfaW5mbyA9IFN0cnVjdCgiZG9tYWluCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoIm5lc3RlZF9odm0iLCAgICAgICBsaWJ4bF9kZWZib29sKSwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgiaW5jcl9nZW5lcmF0aW9uaWQiLGxp
YnhsX2RlZmJvb2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJu
b2dyYXBoaWMiLCAgICAgICAgbGlieGxfZGVmYm9vbCksCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoInN0ZHZnYSIsICAgICAgICAgICBsaWJ4bF9kZWZib29sKSwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgidmdhIiwgICAgICAgICAgICAg
IGxpYnhsX3ZnYV9pbnRlcmZhY2VfaW5mbyksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAoInZuYyIsICAgICAgICAgICAgICBsaWJ4bF92bmNfaW5mbyksCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGtleWJvYXJkIGxheW91dCwgZGVmYXVs
dCBpcyBlbi11cyBrZXlib2FyZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKCJrZXltYXAiLCAgICAgICAgICAgc3RyaW5nKSwKZGlmZiAtciA2YmVhNjNlNmM3ODAgLXIg
N2JkMDhmODNhMmNlIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29scy9saWJ4bC94
bF9jbWRpbXBsLmMJU2F0IEp1biAwMiAwODozOTo0NSAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwlUdWUgSnVuIDA1IDE3OjM5OjM3IDIwMTIgKzA4MDAKQEAgLTEyNTYs
NyArMTI1NiwxMCBAQCBza2lwX3ZmYjoKICN1bmRlZiBwYXJzZV9leHRyYV9hcmdzCiAKICAgICBp
ZiAoY19pbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0hWTSkgewotICAgICAgICB4bHVf
Y2ZnX2dldF9kZWZib29sKGNvbmZpZywgInN0ZHZnYSIsICZiX2luZm8tPnUuaHZtLnN0ZHZnYSwg
MCk7CisgICAgICAgIGlmICgheGx1X2NmZ19nZXRfbG9uZyhjb25maWcsICJzdGR2Z2EiLCAmbCwg
MCkpCisgICAgICAgICAgICBpZiAobCkKKyAgICAgICAgICAgICAgICBiX2luZm8tPnUuaHZtLnZn
YS50eXBlID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1NURDsKKwogICAgICAgICB4bHVfY2Zn
X2dldF9kZWZib29sKGNvbmZpZywgInZuYyIsICZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIDAp
OwogICAgICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nIChjb25maWcsICJ2bmNsaXN0ZW4iLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS52bmMubGlzdGVu
LCAwKTsKZGlmZiAtciA2YmVhNjNlNmM3ODAgLXIgN2JkMDhmODNhMmNlIHRvb2xzL2xpYnhsL3hs
X3N4cC5jCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX3N4cC5jCVNhdCBKdW4gMDIgMDg6Mzk6NDUgMjAx
MiArMDEwMAorKysgYi90b29scy9saWJ4bC94bF9zeHAuYwlUdWUgSnVuIDA1IDE3OjM5OjM3IDIw
MTIgKzA4MDAKQEAgLTExMCw4ICsxMTAsOSBAQCB2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRv
bWlkLCBsaWJ4bF9kCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2lu
Zm8tPnUuaHZtLm5lc3RlZF9odm0pKTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQobm9faW5jcl9n
ZW5lcmF0aW9uaWQgJXMpXG4iLAogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJp
bmcoYl9pbmZvLT51Lmh2bS5pbmNyX2dlbmVyYXRpb25pZCkpOwotICAgICAgICBwcmludGYoIlx0
XHRcdChzdGR2Z2EgJXMpXG4iLAotICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJp
bmcoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKTsKKyAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3Rkdmdh
ICVzKVxuIiwgYl9pbmZvLT51Lmh2bS52Z2EudHlwZSA9PQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfU1REID8KKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIlRydWUiIDogIkZhbHNlIik7CiAgICAgICAg
IHByaW50ZigiXHRcdFx0KHZuYyAlcylcbiIsCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29s
X3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUpKTsKICAgICAgICAgcHJpbnRmKCJc
dFx0XHQodm5jbGlzdGVuICVzKVxuIiwgYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuKTsKCg==
--e89a8fb1ebb643af7b04c1b7d38c
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--e89a8fb1ebb643af7b04c1b7d38c--


From xen-devel-bounces@lists.xen.org Tue Jun 05 11:20:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 11: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 1SbrnX-0000mD-MN; Tue, 05 Jun 2012 11:19:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SbrnV-0000m7-Qx
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 11:19:38 +0000
Received: from [85.158.143.35:4569] by server-1.bemta-4.messagelabs.com id
	F4/9A-10042-84BEDCF4; Tue, 05 Jun 2012 11:19:36 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338895174!8440742!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4961 invoked from network); 5 Jun 2012 11:19:35 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 11:19:35 -0000
Received: by yenq11 with SMTP id q11so4795443yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Jun 2012 04:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=RblCqe9Z5Lit+5woPQ0u4T+wuvaaY46Gi5VZMHc+lGI=;
	b=ohcM+CzMd02MPe+omrMMBfyBzBmkD4/Q0nRBuL0AKLrjSrXMjmm/QhelrEVzqzvweh
	YF11kSy4QlEatBaxqGBoLz9GWOTly+ockwcvFhMyuI+Qo4B0opoKPadzGqndVoeNnnyX
	gVlkfJG0IEDOB8dcapXbfbibqnVPZFlI3WgZYoveJ1XtkpzdW2Nskx3g7jKsdN75xIp3
	cv8oWiUV4mmPhWTWXcFSmAHrAtwO6BcUWKtESA/Kbc5EO3wddX8xzT/0IL+d2qHsUivy
	OwDr+9vcQsJFmWDsTh1GyBcST88hug3jPTCx0wNZge8H+Ae9uyR9Ar92+CVDdnziHT5N
	WuWQ==
MIME-Version: 1.0
Received: by 10.60.13.134 with SMTP id h6mr15365028oec.11.1338895174446; Tue,
	05 Jun 2012 04:19:34 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Tue, 5 Jun 2012 04:19:33 -0700 (PDT)
Date: Tue, 5 Jun 2012 19:19:33 +0800
Message-ID: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=e89a8fb1ebb643af7b04c1b7d38c
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	"ian.jackson" <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel]  [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

changeset:   25453:7bd08f83a2ce
user:        Zhou Peng <ailvpeng25@gmail.com>
date:        Tue Jun 05 17:39:37 2012 +0800
files:       tools/libxl/libxl.h tools/libxl/libxl_create.c
tools/libxl/libxl_dm.c tools/libxl/libxl_types.idl
tools/libxl/xl_cmdimpl.c tools/libxl/xl_sxp.c
description:
tools:libxl: refactor stdvga opinon support.

Be ready to add and describe new vga interface

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>


diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl.h	Tue Jun 05 17:39:37 2012 +0800
@@ -342,6 +342,7 @@ typedef struct libxl__ctx libxl_ctx;

 #define LIBXL_TIMER_MODE_DEFAULT -1
 #define LIBXL_MEMKB_DEFAULT ~0ULL
+#define LIBXL_VGA_INTERFACE_TYPE_DEFAULT -1

 #include "_libxl_types.h"

diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl_create.c	Tue Jun 05 17:39:37 2012 +0800
@@ -193,7 +193,8 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }

-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
+            b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Tue Jun 05 17:39:37 2012 +0800
@@ -175,8 +175,13 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
+
+        switch (b_info->u.hvm.vga.type) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
             flexarray_append(dm_args, "-std-vga");
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
         }

         if (b_info->u.hvm.boot) {
@@ -418,8 +423,13 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }

-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
-                flexarray_vappend(dm_args, "-vga", "std", NULL);
+        switch (b_info->u.hvm.vga.type) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
+            flexarray_vappend(dm_args, "-vga", "std", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
         }

         if (b_info->u.hvm.boot) {
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Jun 05 17:39:37 2012 +0800
@@ -125,9 +125,19 @@ libxl_shutdown_reason = Enumeration("shu
     (4, "watchdog"),
     ])

+libxl_vga_interface_type = Enumeration("vga_interface_type", [
+    (0, "CIRRUS"),
+    (1, "STD"),
+    ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
+
 #
 # Complex libxl types
 #
+
+libxl_vga_interface_info = Struct("vga_interface_info", [
+    ("type",    libxl_vga_interface_type),
+    ])
+
 libxl_vnc_info = Struct("vnc_info", [
     ("enable",        libxl_defbool),
     # "address:port" that should be listened on
@@ -281,7 +291,7 @@ libxl_domain_build_info = Struct("domain
                                        ("nested_hvm",       libxl_defbool),
                                        ("incr_generationid",libxl_defbool),
                                        ("nographic",        libxl_defbool),
-                                       ("stdvga",           libxl_defbool),
+                                       ("vga",
libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is
en-us keyboard
                                        ("keymap",           string),
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
@@ -1256,7 +1256,10 @@ skip_vfb:
 #undef parse_extra_args

     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+            if (l)
+                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);
diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Tue Jun 05 17:39:37 2012 +0800
@@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-        printf("\t\t\t(stdvga %s)\n",
-               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type ==
+                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
+                                      "True" : "False");
         printf("\t\t\t(vnc %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);


-- 
Zhou Peng

--e89a8fb1ebb643af7b04c1b7d38c
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.stdvga.refactor.v2.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.stdvga.refactor.v2.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h32vk5rr0

Y2hhbmdlc2V0OiAgIDI1NDUzOjdiZDA4ZjgzYTJjZQp1c2VyOiAgICAgICAgWmhvdSBQZW5nIDxh
aWx2cGVuZzI1QGdtYWlsLmNvbT4KZGF0ZTogICAgICAgIFR1ZSBKdW4gMDUgMTc6Mzk6MzcgMjAx
MiArMDgwMApmaWxlczogICAgICAgdG9vbHMvbGlieGwvbGlieGwuaCB0b29scy9saWJ4bC9saWJ4
bF9jcmVhdGUuYyB0b29scy9saWJ4bC9saWJ4bF9kbS5jIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVz
LmlkbCB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMgdG9vbHMvbGlieGwveGxfc3hwLmMKZGVzY3Jp
cHRpb246CnRvb2xzOmxpYnhsOiByZWZhY3RvciBzdGR2Z2Egb3Bpbm9uIHN1cHBvcnQuCgpCZSBy
ZWFkeSB0byBhZGQgYW5kIGRlc2NyaWJlIG5ldyB2Z2EgaW50ZXJmYWNlCgpTaWduZWQtb2ZmLWJ5
OiBaaG91IFBlbmcgPGFpbHZwZW5nMjVAZ21haWwuY29tPgoKCmRpZmYgLXIgNmJlYTYzZTZjNzgw
IC1yIDdiZDA4ZjgzYTJjZSB0b29scy9saWJ4bC9saWJ4bC5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xp
YnhsLmgJU2F0IEp1biAwMiAwODozOTo0NSAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xpYnhsL2xp
YnhsLmgJVHVlIEp1biAwNSAxNzozOTozNyAyMDEyICswODAwCkBAIC0zNDIsNiArMzQyLDcgQEAg
dHlwZWRlZiBzdHJ1Y3QgbGlieGxfX2N0eCBsaWJ4bF9jdHg7CiAKICNkZWZpbmUgTElCWExfVElN
RVJfTU9ERV9ERUZBVUxUIC0xCiAjZGVmaW5lIExJQlhMX01FTUtCX0RFRkFVTFQgfjBVTEwKKyNk
ZWZpbmUgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0RFRkFVTFQgLTEKIAogI2luY2x1ZGUgIl9s
aWJ4bF90eXBlcy5oIgogCmRpZmYgLXIgNmJlYTYzZTZjNzgwIC1yIDdiZDA4ZjgzYTJjZSB0b29s
cy9saWJ4bC9saWJ4bF9jcmVhdGUuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlT
YXQgSnVuIDAyIDA4OjM5OjQ1IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3Jl
YXRlLmMJVHVlIEp1biAwNSAxNzozOTozNyAyMDEyICswODAwCkBAIC0xOTMsNyArMTkzLDggQEAg
aW50IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgICAgICAgICAgaWYg
KCFiX2luZm8tPnUuaHZtLmJvb3QpIHJldHVybiBFUlJPUl9OT01FTTsKICAgICAgICAgfQogCi0g
ICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIGZh
bHNlKTsKKyAgICAgICAgaWYgKGJfaW5mby0+dS5odm0udmdhLnR5cGUgPT0gTElCWExfVkdBX0lO
VEVSRkFDRV9UWVBFX0RFRkFVTFQpCisgICAgICAgICAgICBiX2luZm8tPnUuaHZtLnZnYS50eXBl
ID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJUlJVUzsKICAgICAgICAgbGlieGxfZGVmYm9v
bF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIHRydWUpOwogICAgICAgICBp
ZiAobGlieGxfZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxlKSkgewogICAgICAg
ICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnZuYy5maW5kdW51
c2VkLCB0cnVlKTsKZGlmZiAtciA2YmVhNjNlNmM3ODAgLXIgN2JkMDhmODNhMmNlIHRvb2xzL2xp
YnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlTYXQgSnVuIDAyIDA4
OjM5OjQ1IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlUdWUgSnVuIDA1
IDE3OjM5OjM3IDIwMTIgKzA4MDAKQEAgLTE3NSw4ICsxNzUsMTMgQEAgc3RhdGljIGNoYXIgKiog
bGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBsaWJ4bF9fc2l6ZWtiX3RvX21iKGJfaW5mby0+dmlkZW9fbWVta2IpKSwKICAgICAgICAg
ICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgIH0KLSAgICAgICAgaWYgKGxpYnhsX2RlZmJvb2xf
dmFsKGJfaW5mby0+dS5odm0uc3RkdmdhKSkgeworCisgICAgICAgIHN3aXRjaCAoYl9pbmZvLT51
Lmh2bS52Z2EudHlwZSkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9T
VEQ6CiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItc3RkLXZnYSIpOwor
ICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBF
X0NJUlJVUzoKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJf
aW5mby0+dS5odm0uYm9vdCkgewpAQCAtNDE4LDggKzQyMywxMyBAQCBzdGF0aWMgY2hhciAqKiBs
aWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRt
X2FyZ3MsIHNwaWNlb3B0aW9ucyk7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAobGlieGxfZGVm
Ym9vbF92YWwoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKSB7Ci0gICAgICAgICAgICAgICAgZmxleGFy
cmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAic3RkIiwgTlVMTCk7CisgICAgICAgIHN3aXRj
aCAoYl9pbmZvLT51Lmh2bS52Z2EudHlwZSkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRF
UkZBQ0VfVFlQRV9TVEQ6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdzLCAi
LXZnYSIsICJzdGQiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICBjYXNlIExJ
QlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFw
cGVuZChkbV9hcmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFr
OwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0uYm9vdCkgewpkaWZmIC1y
IDZiZWE2M2U2Yzc4MCAtciA3YmQwOGY4M2EyY2UgdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRs
Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlTYXQgSnVuIDAyIDA4OjM5OjQ1IDIw
MTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVR1ZSBKdW4gMDUgMTc6
Mzk6MzcgMjAxMiArMDgwMApAQCAtMTI1LDkgKzEyNSwxOSBAQCBsaWJ4bF9zaHV0ZG93bl9yZWFz
b24gPSBFbnVtZXJhdGlvbigic2h1CiAgICAgKDQsICJ3YXRjaGRvZyIpLAogICAgIF0pCiAKK2xp
YnhsX3ZnYV9pbnRlcmZhY2VfdHlwZSA9IEVudW1lcmF0aW9uKCJ2Z2FfaW50ZXJmYWNlX3R5cGUi
LCBbCisgICAgKDAsICJDSVJSVVMiKSwKKyAgICAoMSwgIlNURCIpLAorICAgIF0sIGluaXRfdmFs
ID0gIkxJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9ERUZBVUxUIikKKwogIwogIyBDb21wbGV4IGxp
YnhsIHR5cGVzCiAjCisKK2xpYnhsX3ZnYV9pbnRlcmZhY2VfaW5mbyA9IFN0cnVjdCgidmdhX2lu
dGVyZmFjZV9pbmZvIiwgWworICAgICgidHlwZSIsICAgIGxpYnhsX3ZnYV9pbnRlcmZhY2VfdHlw
ZSksCisgICAgXSkKKwogbGlieGxfdm5jX2luZm8gPSBTdHJ1Y3QoInZuY19pbmZvIiwgWwogICAg
ICgiZW5hYmxlIiwgICAgICAgIGxpYnhsX2RlZmJvb2wpLAogICAgICMgImFkZHJlc3M6cG9ydCIg
dGhhdCBzaG91bGQgYmUgbGlzdGVuZWQgb24KQEAgLTI4MSw3ICsyOTEsNyBAQCBsaWJ4bF9kb21h
aW5fYnVpbGRfaW5mbyA9IFN0cnVjdCgiZG9tYWluCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoIm5lc3RlZF9odm0iLCAgICAgICBsaWJ4bF9kZWZib29sKSwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgiaW5jcl9nZW5lcmF0aW9uaWQiLGxp
YnhsX2RlZmJvb2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJu
b2dyYXBoaWMiLCAgICAgICAgbGlieGxfZGVmYm9vbCksCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoInN0ZHZnYSIsICAgICAgICAgICBsaWJ4bF9kZWZib29sKSwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgidmdhIiwgICAgICAgICAgICAg
IGxpYnhsX3ZnYV9pbnRlcmZhY2VfaW5mbyksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAoInZuYyIsICAgICAgICAgICAgICBsaWJ4bF92bmNfaW5mbyksCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGtleWJvYXJkIGxheW91dCwgZGVmYXVs
dCBpcyBlbi11cyBrZXlib2FyZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKCJrZXltYXAiLCAgICAgICAgICAgc3RyaW5nKSwKZGlmZiAtciA2YmVhNjNlNmM3ODAgLXIg
N2JkMDhmODNhMmNlIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29scy9saWJ4bC94
bF9jbWRpbXBsLmMJU2F0IEp1biAwMiAwODozOTo0NSAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwlUdWUgSnVuIDA1IDE3OjM5OjM3IDIwMTIgKzA4MDAKQEAgLTEyNTYs
NyArMTI1NiwxMCBAQCBza2lwX3ZmYjoKICN1bmRlZiBwYXJzZV9leHRyYV9hcmdzCiAKICAgICBp
ZiAoY19pbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX0hWTSkgewotICAgICAgICB4bHVf
Y2ZnX2dldF9kZWZib29sKGNvbmZpZywgInN0ZHZnYSIsICZiX2luZm8tPnUuaHZtLnN0ZHZnYSwg
MCk7CisgICAgICAgIGlmICgheGx1X2NmZ19nZXRfbG9uZyhjb25maWcsICJzdGR2Z2EiLCAmbCwg
MCkpCisgICAgICAgICAgICBpZiAobCkKKyAgICAgICAgICAgICAgICBiX2luZm8tPnUuaHZtLnZn
YS50eXBlID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1NURDsKKwogICAgICAgICB4bHVfY2Zn
X2dldF9kZWZib29sKGNvbmZpZywgInZuYyIsICZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIDAp
OwogICAgICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nIChjb25maWcsICJ2bmNsaXN0ZW4iLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS52bmMubGlzdGVu
LCAwKTsKZGlmZiAtciA2YmVhNjNlNmM3ODAgLXIgN2JkMDhmODNhMmNlIHRvb2xzL2xpYnhsL3hs
X3N4cC5jCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX3N4cC5jCVNhdCBKdW4gMDIgMDg6Mzk6NDUgMjAx
MiArMDEwMAorKysgYi90b29scy9saWJ4bC94bF9zeHAuYwlUdWUgSnVuIDA1IDE3OjM5OjM3IDIw
MTIgKzA4MDAKQEAgLTExMCw4ICsxMTAsOSBAQCB2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRv
bWlkLCBsaWJ4bF9kCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2lu
Zm8tPnUuaHZtLm5lc3RlZF9odm0pKTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQobm9faW5jcl9n
ZW5lcmF0aW9uaWQgJXMpXG4iLAogICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJp
bmcoYl9pbmZvLT51Lmh2bS5pbmNyX2dlbmVyYXRpb25pZCkpOwotICAgICAgICBwcmludGYoIlx0
XHRcdChzdGR2Z2EgJXMpXG4iLAotICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJp
bmcoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKTsKKyAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3Rkdmdh
ICVzKVxuIiwgYl9pbmZvLT51Lmh2bS52Z2EudHlwZSA9PQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfU1REID8KKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIlRydWUiIDogIkZhbHNlIik7CiAgICAgICAg
IHByaW50ZigiXHRcdFx0KHZuYyAlcylcbiIsCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29s
X3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUpKTsKICAgICAgICAgcHJpbnRmKCJc
dFx0XHQodm5jbGlzdGVuICVzKVxuIiwgYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuKTsKCg==
--e89a8fb1ebb643af7b04c1b7d38c
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--e89a8fb1ebb643af7b04c1b7d38c--


From xen-devel-bounces@lists.xen.org Tue Jun 05 11:23:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 11:23: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 1SbrqS-0000rV-Bz; Tue, 05 Jun 2012 11:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SbrqR-0000rP-Dc
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 11:22:39 +0000
Received: from [85.158.139.83:45159] by server-10.bemta-5.messagelabs.com id
	12/50-23803-EFBEDCF4; Tue, 05 Jun 2012 11:22:38 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338895355!30556612!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2794 invoked from network); 5 Jun 2012 11:22:37 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 11:22:37 -0000
Received: by obfk16 with SMTP id k16so6533951obf.30
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Jun 2012 04:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=/8Fx6pMOiIt81pV6LueHbDR9wo6KtxzI11HDM/9NG9M=;
	b=Y6zvit7SPPtaLXyT5euAPh31/s+KJ2xiLNcacFozS8NcY/GyhAx8jdAiFCBN345HU/
	ei7NBEbzjZTU0PkdykPqVbRFdE541OUJsTKgHMmcm+sj1dPXxXFzMrPwpjy7EPQc1DRT
	rZTnwAisPrp8CtRwO2ETfI6wL55iI9cDYZ5eoUCAGXynOlqtx4UXLOWqHYsFR455K2X9
	LFIic0RtqF4ubzpD1e6gPgmphgt+bzHZw8sQtj5Yrn4RV4SqQ30mfbrpNJpgg7KFuokk
	4IkRRIaCI98iQcesCeweGgXpgAxxzOcq27gsuMNGmVEy9jTMebTRkTnQIwAyKVyP0fVt
	K3EA==
MIME-Version: 1.0
Received: by 10.182.52.38 with SMTP id q6mr15454903obo.8.1338895355049; Tue,
	05 Jun 2012 04:22:35 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Tue, 5 Jun 2012 04:22:34 -0700 (PDT)
Date: Tue, 5 Jun 2012 19:22:34 +0800
Message-ID: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=14dae9398e9307773604c1b7de6e
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	"ian.jackson" <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface support
	v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

changeset:   25454:1804a873a64d
tag:         tip
user:        Zhou Peng <ailvpeng25@gmail.com>
date:        Tue Jun 05 17:56:46 2012 +0800
files:       tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
description:
tools:libxl: Add qxl vga interface support.

Usage:
 qxl=1
 qxlvram=64
 qxlram=64

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>


diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/libxl_create.c	Tue Jun 05 17:56:46 2012 +0800
@@ -23,6 +23,32 @@
 #include <xc_dom.h>
 #include <xenguest.h>

+/*
+ * For qxl vga interface, the total video mem is determined by
+ * RAM bar and VRAM bar. But it is not simply linearly determined,
+ * get_qxl_ram_size below gives the details.
+ */
+static inline uint32_t msb_mask(uint32_t val)
+{
+    uint32_t mask;
+
+    do {
+        mask = ~(val - 1) & val;
+        val &= ~mask;
+    } while (mask < val);
+
+    return mask;
+}
+
+static inline uint32_t get_qxl_ram_size(uint32_t vram_sizekb,
+                                    uint32_t ram_sizekb)
+{
+    uint32_t vram = msb_mask(2 * vram_sizekb * 1024 - 1);
+    uint32_t ram = msb_mask(2 * ram_sizekb * 1024 - 1);
+
+    return (vram + ram + 1023) / 1024;
+}
+
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
     memset(d_config, 0, sizeof(*d_config));
@@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(

         if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
             b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
+            && b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->u.hvm.vga.vramkb == LIBXL_MEMKB_DEFAULT)
+                b_info->u.hvm.vga.vramkb = 64 * 1024;
+            if (b_info->u.hvm.vga.ramkb == LIBXL_MEMKB_DEFAULT)
+                b_info->u.hvm.vga.ramkb = 64 * 1024;
+            uint32_t qxl_ram = get_qxl_ram_size(b_info->u.hvm.vga.vramkb,
+                                                b_info->u.hvm.vga.ramkb);
+            /*
+             * video_memkb is the real size of video memory to assign.
+             * If video_memkb can't meet the need of qxl, adjust it
+             * accordingly.
+             */
+            if ((b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+                || (b_info->video_memkb < qxl_ram)) {
+                b_info->video_memkb = qxl_ram;
+            }
+        }
+
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/libxl_dm.c	Tue Jun 05 17:56:46 2012 +0800
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-std-vga");
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
             break;
         }

@@ -429,6 +431,17 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            flexarray_vappend(dm_args, "-global",
+                              GCSPRINTF("qxl-vga.vram_size=%lu",
+                                        b_info->u.hvm.vga.vramkb * 1024),
+                              NULL);
+            flexarray_vappend(dm_args, "-global",
+                              GCSPRINTF("qxl-vga.ram_size=%lu",
+                                        b_info->u.hvm.vga.ramkb * 1024),
+                              NULL);
             break;
         }

diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/libxl_types.idl	Tue Jun 05 17:56:46 2012 +0800
@@ -128,6 +128,7 @@ libxl_vga_interface_type = Enumeration("
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (0, "CIRRUS"),
     (1, "STD"),
+    (2, "QXL"),
     ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")

 #
@@ -136,6 +137,10 @@ libxl_vga_interface_type = Enumeration("

 libxl_vga_interface_info = Struct("vga_interface_info", [
     ("type",    libxl_vga_interface_type),
+    # VRAM bar for qxl
+    ("vramkb",  MemKB),
+    # RAM bar for qxl
+    ("ramkb",  MemKB),
     ])

 libxl_vnc_info = Struct("vnc_info", [
diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:56:46 2012 +0800
@@ -1260,6 +1260,16 @@ skip_vfb:
             if (l)
                 b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;

+        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
+            if (l) {
+                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_QXL;
+                if (!xlu_cfg_get_long (config, "qxlvram", &l, 0))
+                    b_info->u.hvm.vga.vramkb = l * 1024;
+                if (!xlu_cfg_get_long (config, "qxlram", &l, 0))
+                    b_info->u.hvm.vga.ramkb = l * 1024;
+            }
+        }
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);


-- 
Zhou Peng

--14dae9398e9307773604c1b7de6e
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support.v2.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support.v2.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h32vnacp0

Y2hhbmdlc2V0OiAgIDI1NDU0OjE4MDRhODczYTY0ZAp0YWc6ICAgICAgICAgdGlwCnVzZXI6ICAg
ICAgICBaaG91IFBlbmcgPGFpbHZwZW5nMjVAZ21haWwuY29tPgpkYXRlOiAgICAgICAgVHVlIEp1
biAwNSAxNzo1Njo0NiAyMDEyICswODAwCmZpbGVzOiAgICAgICB0b29scy9saWJ4bC9saWJ4bF9j
cmVhdGUuYyB0b29scy9saWJ4bC9saWJ4bF9kbS5jIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlk
bCB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKZGVzY3JpcHRpb246CnRvb2xzOmxpYnhsOiBBZGQg
cXhsIHZnYSBpbnRlcmZhY2Ugc3VwcG9ydC4KClVzYWdlOgogcXhsPTEKIHF4bHZyYW09NjQKIHF4
bHJhbT02NAoKU2lnbmVkLW9mZi1ieTogWmhvdSBQZW5nIDxhaWx2cGVuZzI1QGdtYWlsLmNvbT4K
CgpkaWZmIC1yIDdiZDA4ZjgzYTJjZSAtciAxODA0YTg3M2E2NGQgdG9vbHMvbGlieGwvbGlieGxf
Y3JlYXRlLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMJVHVlIEp1biAwNSAxNzoz
OTozNyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCVR1ZSBKdW4g
MDUgMTc6NTY6NDYgMjAxMiArMDgwMApAQCAtMjMsNiArMjMsMzIgQEAKICNpbmNsdWRlIDx4Y19k
b20uaD4KICNpbmNsdWRlIDx4ZW5ndWVzdC5oPgogCisvKgorICogRm9yIHF4bCB2Z2EgaW50ZXJm
YWNlLCB0aGUgdG90YWwgdmlkZW8gbWVtIGlzIGRldGVybWluZWQgYnkKKyAqIFJBTSBiYXIgYW5k
IFZSQU0gYmFyLiBCdXQgaXQgaXMgbm90IHNpbXBseSBsaW5lYXJseSBkZXRlcm1pbmVkLAorICog
Z2V0X3F4bF9yYW1fc2l6ZSBiZWxvdyBnaXZlcyB0aGUgZGV0YWlscy4KKyAqLworc3RhdGljIGlu
bGluZSB1aW50MzJfdCBtc2JfbWFzayh1aW50MzJfdCB2YWwpCit7CisgICAgdWludDMyX3QgbWFz
azsKKworICAgIGRvIHsKKyAgICAgICAgbWFzayA9IH4odmFsIC0gMSkgJiB2YWw7CisgICAgICAg
IHZhbCAmPSB+bWFzazsKKyAgICB9IHdoaWxlIChtYXNrIDwgdmFsKTsKKworICAgIHJldHVybiBt
YXNrOworfQorCitzdGF0aWMgaW5saW5lIHVpbnQzMl90IGdldF9xeGxfcmFtX3NpemUodWludDMy
X3QgdnJhbV9zaXpla2IsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50
MzJfdCByYW1fc2l6ZWtiKQoreworICAgIHVpbnQzMl90IHZyYW0gPSBtc2JfbWFzaygyICogdnJh
bV9zaXpla2IgKiAxMDI0IC0gMSk7CisgICAgdWludDMyX3QgcmFtID0gbXNiX21hc2soMiAqIHJh
bV9zaXpla2IgKiAxMDI0IC0gMSk7CisKKyAgICByZXR1cm4gKHZyYW0gKyByYW0gKyAxMDIzKSAv
IDEwMjQ7Cit9CisKIHZvaWQgbGlieGxfZG9tYWluX2NvbmZpZ19pbml0KGxpYnhsX2RvbWFpbl9j
b25maWcgKmRfY29uZmlnKQogewogICAgIG1lbXNldChkX2NvbmZpZywgMCwgc2l6ZW9mKCpkX2Nv
bmZpZykpOwpAQCAtMTk1LDYgKzIyMSwyNSBAQCBpbnQgbGlieGxfX2RvbWFpbl9idWlsZF9pbmZv
X3NldGRlZmF1bHQoCiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0udmdhLnR5cGUgPT0gTElC
WExfVkdBX0lOVEVSRkFDRV9UWVBFX0RFRkFVTFQpCiAgICAgICAgICAgICBiX2luZm8tPnUuaHZt
LnZnYS50eXBlID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJUlJVUzsKKyAgICAgICAgaWYg
KGJfaW5mby0+ZGV2aWNlX21vZGVsX3ZlcnNpb24gPT0gTElCWExfREVWSUNFX01PREVMX1ZFUlNJ
T05fUUVNVV9YRU4KKyAgICAgICAgICAgICYmIGJfaW5mby0+dS5odm0udmdhLnR5cGUgPT0gTElC
WExfVkdBX0lOVEVSRkFDRV9UWVBFX1FYTCkgeworICAgICAgICAgICAgaWYgKGJfaW5mby0+dS5o
dm0udmdhLnZyYW1rYiA9PSBMSUJYTF9NRU1LQl9ERUZBVUxUKQorICAgICAgICAgICAgICAgIGJf
aW5mby0+dS5odm0udmdhLnZyYW1rYiA9IDY0ICogMTAyNDsKKyAgICAgICAgICAgIGlmIChiX2lu
Zm8tPnUuaHZtLnZnYS5yYW1rYiA9PSBMSUJYTF9NRU1LQl9ERUZBVUxUKQorICAgICAgICAgICAg
ICAgIGJfaW5mby0+dS5odm0udmdhLnJhbWtiID0gNjQgKiAxMDI0OworICAgICAgICAgICAgdWlu
dDMyX3QgcXhsX3JhbSA9IGdldF9xeGxfcmFtX3NpemUoYl9pbmZvLT51Lmh2bS52Z2EudnJhbWti
LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYl9pbmZv
LT51Lmh2bS52Z2EucmFta2IpOworICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAqIHZpZGVv
X21lbWtiIGlzIHRoZSByZWFsIHNpemUgb2YgdmlkZW8gbWVtb3J5IHRvIGFzc2lnbi4KKyAgICAg
ICAgICAgICAqIElmIHZpZGVvX21lbWtiIGNhbid0IG1lZXQgdGhlIG5lZWQgb2YgcXhsLCBhZGp1
c3QgaXQKKyAgICAgICAgICAgICAqIGFjY29yZGluZ2x5LgorICAgICAgICAgICAgICovCisgICAg
ICAgICAgICBpZiAoKGJfaW5mby0+dmlkZW9fbWVta2IgPT0gTElCWExfTUVNS0JfREVGQVVMVCkK
KyAgICAgICAgICAgICAgICB8fCAoYl9pbmZvLT52aWRlb19tZW1rYiA8IHF4bF9yYW0pKSB7Cisg
ICAgICAgICAgICAgICAgYl9pbmZvLT52aWRlb19tZW1rYiA9IHF4bF9yYW07CisgICAgICAgICAg
ICB9CisgICAgICAgIH0KKwogICAgICAgICBsaWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJfaW5m
by0+dS5odm0udm5jLmVuYWJsZSwgdHJ1ZSk7CiAgICAgICAgIGlmIChsaWJ4bF9kZWZib29sX3Zh
bChiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUpKSB7CiAgICAgICAgICAgICBsaWJ4bF9kZWZib29s
X3NldGRlZmF1bHQoJmJfaW5mby0+dS5odm0udm5jLmZpbmR1bnVzZWQsIHRydWUpOwpkaWZmIC1y
IDdiZDA4ZjgzYTJjZSAtciAxODA0YTg3M2E2NGQgdG9vbHMvbGlieGwvbGlieGxfZG0uYwotLS0g
YS90b29scy9saWJ4bC9saWJ4bF9kbS5jCVR1ZSBKdW4gMDUgMTc6Mzk6MzcgMjAxMiArMDgwMAor
KysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jCVR1ZSBKdW4gMDUgMTc6NTY6NDYgMjAxMiArMDgw
MApAQCAtMTgxLDYgKzE4MSw4IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX19idWlsZF9kZXZpY2Vf
bW9kZWwKICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1zdGQtdmdhIik7
CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZ
UEVfQ0lSUlVTOgorICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lO
VEVSRkFDRV9UWVBFX1FYTDoKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKQEAgLTQy
OSw2ICs0MzEsMTcgQEAgc3RhdGljIGNoYXIgKiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAog
ICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBF
X0NJUlJVUzoKICAgICAgICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRtX2FyZ3MsICItdmdhIiwg
ImNpcnJ1cyIsIE5VTEwpOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExf
VkdBX0lOVEVSRkFDRV9UWVBFX1FYTDoKKyAgICAgICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRt
X2FyZ3MsICItdmdhIiwgInF4bCIsIE5VTEwpOworICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBl
bmQoZG1fYXJncywgIi1nbG9iYWwiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR0NT
UFJJTlRGKCJxeGwtdmdhLnZyYW1fc2l6ZT0lbHUiLAorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGJfaW5mby0+dS5odm0udmdhLnZyYW1rYiAqIDEwMjQpLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCk7CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFw
cGVuZChkbV9hcmdzLCAiLWdsb2JhbCIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBH
Q1NQUklOVEYoInF4bC12Z2EucmFtX3NpemU9JWx1IiwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBiX2luZm8tPnUuaHZtLnZnYS5yYW1rYiAqIDEwMjQpLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgICAgICBicmVhazsKICAgICAg
ICAgfQogCmRpZmYgLXIgN2JkMDhmODNhMmNlIC1yIDE4MDRhODczYTY0ZCB0b29scy9saWJ4bC9s
aWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVR1ZSBKdW4g
MDUgMTc6Mzk6MzcgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJ
VHVlIEp1biAwNSAxNzo1Njo0NiAyMDEyICswODAwCkBAIC0xMjgsNiArMTI4LDcgQEAgbGlieGxf
dmdhX2ludGVyZmFjZV90eXBlID0gRW51bWVyYXRpb24oIgogbGlieGxfdmdhX2ludGVyZmFjZV90
eXBlID0gRW51bWVyYXRpb24oInZnYV9pbnRlcmZhY2VfdHlwZSIsIFsKICAgICAoMCwgIkNJUlJV
UyIpLAogICAgICgxLCAiU1REIiksCisgICAgKDIsICJRWEwiKSwKICAgICBdLCBpbml0X3ZhbCA9
ICJMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfREVGQVVMVCIpCiAKICMKQEAgLTEzNiw2ICsxMzcs
MTAgQEAgbGlieGxfdmdhX2ludGVyZmFjZV90eXBlID0gRW51bWVyYXRpb24oIgogCiBsaWJ4bF92
Z2FfaW50ZXJmYWNlX2luZm8gPSBTdHJ1Y3QoInZnYV9pbnRlcmZhY2VfaW5mbyIsIFsKICAgICAo
InR5cGUiLCAgICBsaWJ4bF92Z2FfaW50ZXJmYWNlX3R5cGUpLAorICAgICMgVlJBTSBiYXIgZm9y
IHF4bAorICAgICgidnJhbWtiIiwgIE1lbUtCKSwKKyAgICAjIFJBTSBiYXIgZm9yIHF4bAorICAg
ICgicmFta2IiLCAgTWVtS0IpLAogICAgIF0pCiAKIGxpYnhsX3ZuY19pbmZvID0gU3RydWN0KCJ2
bmNfaW5mbyIsIFsKZGlmZiAtciA3YmQwOGY4M2EyY2UgLXIgMTgwNGE4NzNhNjRkIHRvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMJVHVlIEp1biAw
NSAxNzozOTozNyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlUdWUg
SnVuIDA1IDE3OjU2OjQ2IDIwMTIgKzA4MDAKQEAgLTEyNjAsNiArMTI2MCwxNiBAQCBza2lwX3Zm
YjoKICAgICAgICAgICAgIGlmIChsKQogICAgICAgICAgICAgICAgIGJfaW5mby0+dS5odm0udmdh
LnR5cGUgPSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfU1REOwogCisgICAgICAgIGlmICgheGx1
X2NmZ19nZXRfbG9uZyhjb25maWcsICJxeGwiLCAmbCwgMCkpIHsKKyAgICAgICAgICAgIGlmIChs
KSB7CisgICAgICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2EudHlwZSA9IExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9RWEw7CisgICAgICAgICAgICAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25n
IChjb25maWcsICJxeGx2cmFtIiwgJmwsIDApKQorICAgICAgICAgICAgICAgICAgICBiX2luZm8t
PnUuaHZtLnZnYS52cmFta2IgPSBsICogMTAyNDsKKyAgICAgICAgICAgICAgICBpZiAoIXhsdV9j
ZmdfZ2V0X2xvbmcgKGNvbmZpZywgInF4bHJhbSIsICZsLCAwKSkKKyAgICAgICAgICAgICAgICAg
ICAgYl9pbmZvLT51Lmh2bS52Z2EucmFta2IgPSBsICogMTAyNDsKKyAgICAgICAgICAgIH0KKyAg
ICAgICAgfQorCiAgICAgICAgIHhsdV9jZmdfZ2V0X2RlZmJvb2woY29uZmlnLCAidm5jIiwgJmJf
aW5mby0+dS5odm0udm5jLmVuYWJsZSwgMCk7CiAgICAgICAgIHhsdV9jZmdfcmVwbGFjZV9zdHJp
bmcgKGNvbmZpZywgInZuY2xpc3RlbiIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZiX2luZm8tPnUuaHZtLnZuYy5saXN0ZW4sIDApOwoK
--14dae9398e9307773604c1b7de6e
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--14dae9398e9307773604c1b7de6e--


From xen-devel-bounces@lists.xen.org Tue Jun 05 11:23:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 11:23: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 1SbrqS-0000rV-Bz; Tue, 05 Jun 2012 11:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SbrqR-0000rP-Dc
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 11:22:39 +0000
Received: from [85.158.139.83:45159] by server-10.bemta-5.messagelabs.com id
	12/50-23803-EFBEDCF4; Tue, 05 Jun 2012 11:22:38 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338895355!30556612!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2794 invoked from network); 5 Jun 2012 11:22:37 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 11:22:37 -0000
Received: by obfk16 with SMTP id k16so6533951obf.30
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Jun 2012 04:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=/8Fx6pMOiIt81pV6LueHbDR9wo6KtxzI11HDM/9NG9M=;
	b=Y6zvit7SPPtaLXyT5euAPh31/s+KJ2xiLNcacFozS8NcY/GyhAx8jdAiFCBN345HU/
	ei7NBEbzjZTU0PkdykPqVbRFdE541OUJsTKgHMmcm+sj1dPXxXFzMrPwpjy7EPQc1DRT
	rZTnwAisPrp8CtRwO2ETfI6wL55iI9cDYZ5eoUCAGXynOlqtx4UXLOWqHYsFR455K2X9
	LFIic0RtqF4ubzpD1e6gPgmphgt+bzHZw8sQtj5Yrn4RV4SqQ30mfbrpNJpgg7KFuokk
	4IkRRIaCI98iQcesCeweGgXpgAxxzOcq27gsuMNGmVEy9jTMebTRkTnQIwAyKVyP0fVt
	K3EA==
MIME-Version: 1.0
Received: by 10.182.52.38 with SMTP id q6mr15454903obo.8.1338895355049; Tue,
	05 Jun 2012 04:22:35 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Tue, 5 Jun 2012 04:22:34 -0700 (PDT)
Date: Tue, 5 Jun 2012 19:22:34 +0800
Message-ID: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=14dae9398e9307773604c1b7de6e
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	"ian.jackson" <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface support
	v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

changeset:   25454:1804a873a64d
tag:         tip
user:        Zhou Peng <ailvpeng25@gmail.com>
date:        Tue Jun 05 17:56:46 2012 +0800
files:       tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
description:
tools:libxl: Add qxl vga interface support.

Usage:
 qxl=1
 qxlvram=64
 qxlram=64

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>


diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/libxl_create.c	Tue Jun 05 17:56:46 2012 +0800
@@ -23,6 +23,32 @@
 #include <xc_dom.h>
 #include <xenguest.h>

+/*
+ * For qxl vga interface, the total video mem is determined by
+ * RAM bar and VRAM bar. But it is not simply linearly determined,
+ * get_qxl_ram_size below gives the details.
+ */
+static inline uint32_t msb_mask(uint32_t val)
+{
+    uint32_t mask;
+
+    do {
+        mask = ~(val - 1) & val;
+        val &= ~mask;
+    } while (mask < val);
+
+    return mask;
+}
+
+static inline uint32_t get_qxl_ram_size(uint32_t vram_sizekb,
+                                    uint32_t ram_sizekb)
+{
+    uint32_t vram = msb_mask(2 * vram_sizekb * 1024 - 1);
+    uint32_t ram = msb_mask(2 * ram_sizekb * 1024 - 1);
+
+    return (vram + ram + 1023) / 1024;
+}
+
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
     memset(d_config, 0, sizeof(*d_config));
@@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(

         if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
             b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
+            && b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->u.hvm.vga.vramkb == LIBXL_MEMKB_DEFAULT)
+                b_info->u.hvm.vga.vramkb = 64 * 1024;
+            if (b_info->u.hvm.vga.ramkb == LIBXL_MEMKB_DEFAULT)
+                b_info->u.hvm.vga.ramkb = 64 * 1024;
+            uint32_t qxl_ram = get_qxl_ram_size(b_info->u.hvm.vga.vramkb,
+                                                b_info->u.hvm.vga.ramkb);
+            /*
+             * video_memkb is the real size of video memory to assign.
+             * If video_memkb can't meet the need of qxl, adjust it
+             * accordingly.
+             */
+            if ((b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+                || (b_info->video_memkb < qxl_ram)) {
+                b_info->video_memkb = qxl_ram;
+            }
+        }
+
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/libxl_dm.c	Tue Jun 05 17:56:46 2012 +0800
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-std-vga");
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
             break;
         }

@@ -429,6 +431,17 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            flexarray_vappend(dm_args, "-global",
+                              GCSPRINTF("qxl-vga.vram_size=%lu",
+                                        b_info->u.hvm.vga.vramkb * 1024),
+                              NULL);
+            flexarray_vappend(dm_args, "-global",
+                              GCSPRINTF("qxl-vga.ram_size=%lu",
+                                        b_info->u.hvm.vga.ramkb * 1024),
+                              NULL);
             break;
         }

diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/libxl_types.idl	Tue Jun 05 17:56:46 2012 +0800
@@ -128,6 +128,7 @@ libxl_vga_interface_type = Enumeration("
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (0, "CIRRUS"),
     (1, "STD"),
+    (2, "QXL"),
     ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")

 #
@@ -136,6 +137,10 @@ libxl_vga_interface_type = Enumeration("

 libxl_vga_interface_info = Struct("vga_interface_info", [
     ("type",    libxl_vga_interface_type),
+    # VRAM bar for qxl
+    ("vramkb",  MemKB),
+    # RAM bar for qxl
+    ("ramkb",  MemKB),
     ])

 libxl_vnc_info = Struct("vnc_info", [
diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:56:46 2012 +0800
@@ -1260,6 +1260,16 @@ skip_vfb:
             if (l)
                 b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;

+        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
+            if (l) {
+                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_QXL;
+                if (!xlu_cfg_get_long (config, "qxlvram", &l, 0))
+                    b_info->u.hvm.vga.vramkb = l * 1024;
+                if (!xlu_cfg_get_long (config, "qxlram", &l, 0))
+                    b_info->u.hvm.vga.ramkb = l * 1024;
+            }
+        }
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);


-- 
Zhou Peng

--14dae9398e9307773604c1b7de6e
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support.v2.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support.v2.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h32vnacp0

Y2hhbmdlc2V0OiAgIDI1NDU0OjE4MDRhODczYTY0ZAp0YWc6ICAgICAgICAgdGlwCnVzZXI6ICAg
ICAgICBaaG91IFBlbmcgPGFpbHZwZW5nMjVAZ21haWwuY29tPgpkYXRlOiAgICAgICAgVHVlIEp1
biAwNSAxNzo1Njo0NiAyMDEyICswODAwCmZpbGVzOiAgICAgICB0b29scy9saWJ4bC9saWJ4bF9j
cmVhdGUuYyB0b29scy9saWJ4bC9saWJ4bF9kbS5jIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlk
bCB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKZGVzY3JpcHRpb246CnRvb2xzOmxpYnhsOiBBZGQg
cXhsIHZnYSBpbnRlcmZhY2Ugc3VwcG9ydC4KClVzYWdlOgogcXhsPTEKIHF4bHZyYW09NjQKIHF4
bHJhbT02NAoKU2lnbmVkLW9mZi1ieTogWmhvdSBQZW5nIDxhaWx2cGVuZzI1QGdtYWlsLmNvbT4K
CgpkaWZmIC1yIDdiZDA4ZjgzYTJjZSAtciAxODA0YTg3M2E2NGQgdG9vbHMvbGlieGwvbGlieGxf
Y3JlYXRlLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMJVHVlIEp1biAwNSAxNzoz
OTozNyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCVR1ZSBKdW4g
MDUgMTc6NTY6NDYgMjAxMiArMDgwMApAQCAtMjMsNiArMjMsMzIgQEAKICNpbmNsdWRlIDx4Y19k
b20uaD4KICNpbmNsdWRlIDx4ZW5ndWVzdC5oPgogCisvKgorICogRm9yIHF4bCB2Z2EgaW50ZXJm
YWNlLCB0aGUgdG90YWwgdmlkZW8gbWVtIGlzIGRldGVybWluZWQgYnkKKyAqIFJBTSBiYXIgYW5k
IFZSQU0gYmFyLiBCdXQgaXQgaXMgbm90IHNpbXBseSBsaW5lYXJseSBkZXRlcm1pbmVkLAorICog
Z2V0X3F4bF9yYW1fc2l6ZSBiZWxvdyBnaXZlcyB0aGUgZGV0YWlscy4KKyAqLworc3RhdGljIGlu
bGluZSB1aW50MzJfdCBtc2JfbWFzayh1aW50MzJfdCB2YWwpCit7CisgICAgdWludDMyX3QgbWFz
azsKKworICAgIGRvIHsKKyAgICAgICAgbWFzayA9IH4odmFsIC0gMSkgJiB2YWw7CisgICAgICAg
IHZhbCAmPSB+bWFzazsKKyAgICB9IHdoaWxlIChtYXNrIDwgdmFsKTsKKworICAgIHJldHVybiBt
YXNrOworfQorCitzdGF0aWMgaW5saW5lIHVpbnQzMl90IGdldF9xeGxfcmFtX3NpemUodWludDMy
X3QgdnJhbV9zaXpla2IsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50
MzJfdCByYW1fc2l6ZWtiKQoreworICAgIHVpbnQzMl90IHZyYW0gPSBtc2JfbWFzaygyICogdnJh
bV9zaXpla2IgKiAxMDI0IC0gMSk7CisgICAgdWludDMyX3QgcmFtID0gbXNiX21hc2soMiAqIHJh
bV9zaXpla2IgKiAxMDI0IC0gMSk7CisKKyAgICByZXR1cm4gKHZyYW0gKyByYW0gKyAxMDIzKSAv
IDEwMjQ7Cit9CisKIHZvaWQgbGlieGxfZG9tYWluX2NvbmZpZ19pbml0KGxpYnhsX2RvbWFpbl9j
b25maWcgKmRfY29uZmlnKQogewogICAgIG1lbXNldChkX2NvbmZpZywgMCwgc2l6ZW9mKCpkX2Nv
bmZpZykpOwpAQCAtMTk1LDYgKzIyMSwyNSBAQCBpbnQgbGlieGxfX2RvbWFpbl9idWlsZF9pbmZv
X3NldGRlZmF1bHQoCiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0udmdhLnR5cGUgPT0gTElC
WExfVkdBX0lOVEVSRkFDRV9UWVBFX0RFRkFVTFQpCiAgICAgICAgICAgICBiX2luZm8tPnUuaHZt
LnZnYS50eXBlID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJUlJVUzsKKyAgICAgICAgaWYg
KGJfaW5mby0+ZGV2aWNlX21vZGVsX3ZlcnNpb24gPT0gTElCWExfREVWSUNFX01PREVMX1ZFUlNJ
T05fUUVNVV9YRU4KKyAgICAgICAgICAgICYmIGJfaW5mby0+dS5odm0udmdhLnR5cGUgPT0gTElC
WExfVkdBX0lOVEVSRkFDRV9UWVBFX1FYTCkgeworICAgICAgICAgICAgaWYgKGJfaW5mby0+dS5o
dm0udmdhLnZyYW1rYiA9PSBMSUJYTF9NRU1LQl9ERUZBVUxUKQorICAgICAgICAgICAgICAgIGJf
aW5mby0+dS5odm0udmdhLnZyYW1rYiA9IDY0ICogMTAyNDsKKyAgICAgICAgICAgIGlmIChiX2lu
Zm8tPnUuaHZtLnZnYS5yYW1rYiA9PSBMSUJYTF9NRU1LQl9ERUZBVUxUKQorICAgICAgICAgICAg
ICAgIGJfaW5mby0+dS5odm0udmdhLnJhbWtiID0gNjQgKiAxMDI0OworICAgICAgICAgICAgdWlu
dDMyX3QgcXhsX3JhbSA9IGdldF9xeGxfcmFtX3NpemUoYl9pbmZvLT51Lmh2bS52Z2EudnJhbWti
LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYl9pbmZv
LT51Lmh2bS52Z2EucmFta2IpOworICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAqIHZpZGVv
X21lbWtiIGlzIHRoZSByZWFsIHNpemUgb2YgdmlkZW8gbWVtb3J5IHRvIGFzc2lnbi4KKyAgICAg
ICAgICAgICAqIElmIHZpZGVvX21lbWtiIGNhbid0IG1lZXQgdGhlIG5lZWQgb2YgcXhsLCBhZGp1
c3QgaXQKKyAgICAgICAgICAgICAqIGFjY29yZGluZ2x5LgorICAgICAgICAgICAgICovCisgICAg
ICAgICAgICBpZiAoKGJfaW5mby0+dmlkZW9fbWVta2IgPT0gTElCWExfTUVNS0JfREVGQVVMVCkK
KyAgICAgICAgICAgICAgICB8fCAoYl9pbmZvLT52aWRlb19tZW1rYiA8IHF4bF9yYW0pKSB7Cisg
ICAgICAgICAgICAgICAgYl9pbmZvLT52aWRlb19tZW1rYiA9IHF4bF9yYW07CisgICAgICAgICAg
ICB9CisgICAgICAgIH0KKwogICAgICAgICBsaWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJfaW5m
by0+dS5odm0udm5jLmVuYWJsZSwgdHJ1ZSk7CiAgICAgICAgIGlmIChsaWJ4bF9kZWZib29sX3Zh
bChiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUpKSB7CiAgICAgICAgICAgICBsaWJ4bF9kZWZib29s
X3NldGRlZmF1bHQoJmJfaW5mby0+dS5odm0udm5jLmZpbmR1bnVzZWQsIHRydWUpOwpkaWZmIC1y
IDdiZDA4ZjgzYTJjZSAtciAxODA0YTg3M2E2NGQgdG9vbHMvbGlieGwvbGlieGxfZG0uYwotLS0g
YS90b29scy9saWJ4bC9saWJ4bF9kbS5jCVR1ZSBKdW4gMDUgMTc6Mzk6MzcgMjAxMiArMDgwMAor
KysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jCVR1ZSBKdW4gMDUgMTc6NTY6NDYgMjAxMiArMDgw
MApAQCAtMTgxLDYgKzE4MSw4IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX19idWlsZF9kZXZpY2Vf
bW9kZWwKICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1zdGQtdmdhIik7
CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZ
UEVfQ0lSUlVTOgorICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lO
VEVSRkFDRV9UWVBFX1FYTDoKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKQEAgLTQy
OSw2ICs0MzEsMTcgQEAgc3RhdGljIGNoYXIgKiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAog
ICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBF
X0NJUlJVUzoKICAgICAgICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRtX2FyZ3MsICItdmdhIiwg
ImNpcnJ1cyIsIE5VTEwpOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExf
VkdBX0lOVEVSRkFDRV9UWVBFX1FYTDoKKyAgICAgICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRt
X2FyZ3MsICItdmdhIiwgInF4bCIsIE5VTEwpOworICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBl
bmQoZG1fYXJncywgIi1nbG9iYWwiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR0NT
UFJJTlRGKCJxeGwtdmdhLnZyYW1fc2l6ZT0lbHUiLAorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGJfaW5mby0+dS5odm0udmdhLnZyYW1rYiAqIDEwMjQpLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCk7CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFw
cGVuZChkbV9hcmdzLCAiLWdsb2JhbCIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBH
Q1NQUklOVEYoInF4bC12Z2EucmFtX3NpemU9JWx1IiwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBiX2luZm8tPnUuaHZtLnZnYS5yYW1rYiAqIDEwMjQpLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgICAgICBicmVhazsKICAgICAg
ICAgfQogCmRpZmYgLXIgN2JkMDhmODNhMmNlIC1yIDE4MDRhODczYTY0ZCB0b29scy9saWJ4bC9s
aWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVR1ZSBKdW4g
MDUgMTc6Mzk6MzcgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJ
VHVlIEp1biAwNSAxNzo1Njo0NiAyMDEyICswODAwCkBAIC0xMjgsNiArMTI4LDcgQEAgbGlieGxf
dmdhX2ludGVyZmFjZV90eXBlID0gRW51bWVyYXRpb24oIgogbGlieGxfdmdhX2ludGVyZmFjZV90
eXBlID0gRW51bWVyYXRpb24oInZnYV9pbnRlcmZhY2VfdHlwZSIsIFsKICAgICAoMCwgIkNJUlJV
UyIpLAogICAgICgxLCAiU1REIiksCisgICAgKDIsICJRWEwiKSwKICAgICBdLCBpbml0X3ZhbCA9
ICJMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfREVGQVVMVCIpCiAKICMKQEAgLTEzNiw2ICsxMzcs
MTAgQEAgbGlieGxfdmdhX2ludGVyZmFjZV90eXBlID0gRW51bWVyYXRpb24oIgogCiBsaWJ4bF92
Z2FfaW50ZXJmYWNlX2luZm8gPSBTdHJ1Y3QoInZnYV9pbnRlcmZhY2VfaW5mbyIsIFsKICAgICAo
InR5cGUiLCAgICBsaWJ4bF92Z2FfaW50ZXJmYWNlX3R5cGUpLAorICAgICMgVlJBTSBiYXIgZm9y
IHF4bAorICAgICgidnJhbWtiIiwgIE1lbUtCKSwKKyAgICAjIFJBTSBiYXIgZm9yIHF4bAorICAg
ICgicmFta2IiLCAgTWVtS0IpLAogICAgIF0pCiAKIGxpYnhsX3ZuY19pbmZvID0gU3RydWN0KCJ2
bmNfaW5mbyIsIFsKZGlmZiAtciA3YmQwOGY4M2EyY2UgLXIgMTgwNGE4NzNhNjRkIHRvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwotLS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMJVHVlIEp1biAw
NSAxNzozOTozNyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlUdWUg
SnVuIDA1IDE3OjU2OjQ2IDIwMTIgKzA4MDAKQEAgLTEyNjAsNiArMTI2MCwxNiBAQCBza2lwX3Zm
YjoKICAgICAgICAgICAgIGlmIChsKQogICAgICAgICAgICAgICAgIGJfaW5mby0+dS5odm0udmdh
LnR5cGUgPSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfU1REOwogCisgICAgICAgIGlmICgheGx1
X2NmZ19nZXRfbG9uZyhjb25maWcsICJxeGwiLCAmbCwgMCkpIHsKKyAgICAgICAgICAgIGlmIChs
KSB7CisgICAgICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2EudHlwZSA9IExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9RWEw7CisgICAgICAgICAgICAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25n
IChjb25maWcsICJxeGx2cmFtIiwgJmwsIDApKQorICAgICAgICAgICAgICAgICAgICBiX2luZm8t
PnUuaHZtLnZnYS52cmFta2IgPSBsICogMTAyNDsKKyAgICAgICAgICAgICAgICBpZiAoIXhsdV9j
ZmdfZ2V0X2xvbmcgKGNvbmZpZywgInF4bHJhbSIsICZsLCAwKSkKKyAgICAgICAgICAgICAgICAg
ICAgYl9pbmZvLT51Lmh2bS52Z2EucmFta2IgPSBsICogMTAyNDsKKyAgICAgICAgICAgIH0KKyAg
ICAgICAgfQorCiAgICAgICAgIHhsdV9jZmdfZ2V0X2RlZmJvb2woY29uZmlnLCAidm5jIiwgJmJf
aW5mby0+dS5odm0udm5jLmVuYWJsZSwgMCk7CiAgICAgICAgIHhsdV9jZmdfcmVwbGFjZV9zdHJp
bmcgKGNvbmZpZywgInZuY2xpc3RlbiIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZiX2luZm8tPnUuaHZtLnZuYy5saXN0ZW4sIDApOwoK
--14dae9398e9307773604c1b7de6e
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--14dae9398e9307773604c1b7de6e--


From xen-devel-bounces@lists.xen.org Tue Jun 05 11:27:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 11:27: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 1SbruC-000124-1a; Tue, 05 Jun 2012 11:26:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SbruA-00011z-GP
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 11:26:30 +0000
Received: from [85.158.139.83:60187] by server-2.bemta-5.messagelabs.com id
	EE/89-20827-5ECEDCF4; Tue, 05 Jun 2012 11:26:29 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338895587!28119829!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24802 invoked from network); 5 Jun 2012 11:26:28 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 11:26:28 -0000
Received: by obfk16 with SMTP id k16so6539617obf.30
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Jun 2012 04:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=w5iYURmxF0pKSZ/44L1mSzJZrMD5/ryRZBNk72p+bas=;
	b=nRevwGRhhqnz2K3TE//+ROeG1BaO/XyRzHFTtHKOU+NJDtI1BKsPGc6jaxidX2tm0U
	yfQV3SeBnJ0om0xYRZZwS1627UlhRXO7+oNgeNinqPYHxWfpnDiBgbjh0Py66Af1bBo4
	xQiqM1xmJAfp5dFb8HTLXCf7Uc+6JNxfkXbuDUVyARysWJ8bLqvHSOqBKIMzyiKijNMp
	jnpGUYlSG2VE7NF/2zs0Mv67OygutfdtVXU9OpFNGqgPcH/vqILBSi+iZPCtEOhIO9t2
	EidY9ZhfoGuxLtOXHpt324H9EPb5qRbFp1uehEIhYZyrX7rhedxwS/7a88p3jzcvPfY8
	XtTw==
MIME-Version: 1.0
Received: by 10.182.86.130 with SMTP id p2mr8347571obz.52.1338895586915; Tue,
	05 Jun 2012 04:26:26 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Tue, 5 Jun 2012 04:26:26 -0700 (PDT)
Date: Tue, 5 Jun 2012 19:26:26 +0800
Message-ID: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=f46d0444819fd9777804c1b7eb84
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel]  [PATCH 3/3] docs: qxl vga interface 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

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

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

diff -r 1804a873a64d docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Jun 05 17:56:46 2012 +0800
+++ b/docs/man/xl.cfg.pod.5	Tue Jun 05 18:58:12 2012 +0800
@@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin

 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). The default is 8MB which is sufficient for
-e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
-amount of video ram is fixed at 4MB which is sufficient for 1024x768
+available. This option is available when using the B<stdvga> and
+B<qxl> options (see below).
+For B<stdvga> option, the default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> options,
+the amount of video ram is fixed at 4MB which is sufficient for 1024x768
 at 32 bpp.
+For B<qxl> option, it may be adjusted automatically (see B<qxlram>
+option below).

 =item B<stdvga=BOOLEAN>

@@ -711,6 +714,27 @@ emulated graphics device. The default is
 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.
+
+=item B<qxl=BOOLEAN>
+
+Select a QXL VGA card as the emulated graphics device. This enables
+the other QXL-related settings.
+In general, QXL should work with the Spice remote display protocol for
+acceleration, but QXL driver is necessary in guest. QXL can also work
+with the VNC protocol like a standard VGA without acceleration.
+
+=item B<qxlram=MBYTES>
+
+Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
+The total size of QXL video memory is determined by B<qxlram> (RAM bar)
+and B<qxlvram> (VRAM bar), the size of each is settable.
+B<videoram> can set the amount of RAM which emulated video card
+will contain, but if it can't meet the need of QXL, it will be
+adjusted accordingly.
+
+=item B<qxlvram=MBYTES>
+
+Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.

 =item B<vnc=BOOLEAN>


-- 
Zhou Peng

--f46d0444819fd9777804c1b7eb84
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support.docs.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support.docs.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h32vs3f20

U2lnbmVkLW9mZi1ieTogWmhvdSBQZW5nIDxhaWx2cGVuZzI1QGdtYWlsLmNvbT4KCmRpZmYgLXIg
MTgwNGE4NzNhNjRkIGRvY3MvbWFuL3hsLmNmZy5wb2QuNQotLS0gYS9kb2NzL21hbi94bC5jZmcu
cG9kLjUJVHVlIEp1biAwNSAxNzo1Njo0NiAyMDEyICswODAwCisrKyBiL2RvY3MvbWFuL3hsLmNm
Zy5wb2QuNQlUdWUgSnVuIDA1IDE4OjU4OjEyIDIwMTIgKzA4MDAKQEAgLTY5OSwxMSArNjk5LDE0
IEBAIGluIHRoZSBCPFZGQl9TUEVDX1NUUklORz4gZm9yIGNvbmZpZ3VyaW4KIAogU2V0cyB0aGUg
YW1vdW50IG9mIFJBTSB3aGljaCB0aGUgZW11bGF0ZWQgdmlkZW8gY2FyZCB3aWxsIGNvbnRhaW4s
CiB3aGljaCBpbiB0dXJuIGxpbWl0cyB0aGUgcmVzb2x1dGlvbnMgYW5kIGJpdCBkZXB0aHMgd2hp
Y2ggd2lsbCBiZQotYXZhaWxhYmxlLiBUaGlzIG9wdGlvbiBpcyBvbmx5IGF2YWlsYWJsZSB3aGVu
IHVzaW5nIHRoZSBCPHN0ZHZnYT4KLW9wdGlvbiAoc2VlIGJlbG93KS4gVGhlIGRlZmF1bHQgaXMg
OE1CIHdoaWNoIGlzIHN1ZmZpY2llbnQgZm9yCi1lLmcuIDE2MDB4MTIwMCBhdCAzMmJwcC4gV2hl
biBub3QgdXNpbmcgdGhlIEI8c3RkdmdhPiBvcHRpb24gdGhlCi1hbW91bnQgb2YgdmlkZW8gcmFt
IGlzIGZpeGVkIGF0IDRNQiB3aGljaCBpcyBzdWZmaWNpZW50IGZvciAxMDI0eDc2OAorYXZhaWxh
YmxlLiBUaGlzIG9wdGlvbiBpcyBhdmFpbGFibGUgd2hlbiB1c2luZyB0aGUgQjxzdGR2Z2E+IGFu
ZAorQjxxeGw+IG9wdGlvbnMgKHNlZSBiZWxvdykuIAorRm9yIEI8c3RkdmdhPiBvcHRpb24sIHRo
ZSBkZWZhdWx0IGlzIDhNQiB3aGljaCBpcyBzdWZmaWNpZW50IGZvcgorZS5nLiAxNjAweDEyMDAg
YXQgMzJicHAuIFdoZW4gbm90IHVzaW5nIHRoZSBCPHN0ZHZnYT4gYW5kIEI8cXhsPiBvcHRpb25z
LAordGhlIGFtb3VudCBvZiB2aWRlbyByYW0gaXMgZml4ZWQgYXQgNE1CIHdoaWNoIGlzIHN1ZmZp
Y2llbnQgZm9yIDEwMjR4NzY4CiBhdCAzMiBicHAuCitGb3IgQjxxeGw+IG9wdGlvbiwgaXQgbWF5
IGJlIGFkanVzdGVkIGF1dG9tYXRpY2FsbHkgKHNlZSBCPHF4bHJhbT4KK29wdGlvbiBiZWxvdyku
CiAKID1pdGVtIEI8c3RkdmdhPUJPT0xFQU4+CiAKQEAgLTcxMSw2ICs3MTQsMjcgQEAgZW11bGF0
ZWQgZ3JhcGhpY3MgZGV2aWNlLiBUaGUgZGVmYXVsdCBpcwogZW11bGF0ZWQgZ3JhcGhpY3MgZGV2
aWNlLiBUaGUgZGVmYXVsdCBpcyBmYWxzZSB3aGljaCBtZWFucyB0byBlbXVsYXRlCiBhIENpcnJ1
cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgZ3Vlc3Qgc3VwcG9ydHMgVkJFIDIuMCBv
cgogbGF0ZXIgKGUuZy4gV2luZG93cyBYUCBvbndhcmRzKSB0aGVuIHlvdSBzaG91bGQgZW5hYmxl
IHRoaXMuCisKKz1pdGVtIEI8cXhsPUJPT0xFQU4+CisKK1NlbGVjdCBhIFFYTCBWR0EgY2FyZCBh
cyB0aGUgZW11bGF0ZWQgZ3JhcGhpY3MgZGV2aWNlLiBUaGlzIGVuYWJsZXMKK3RoZSBvdGhlciBR
WEwtcmVsYXRlZCBzZXR0aW5ncy4KK0luIGdlbmVyYWwsIFFYTCBzaG91bGQgd29yayB3aXRoIHRo
ZSBTcGljZSByZW1vdGUgZGlzcGxheSBwcm90b2NvbCBmb3IKK2FjY2VsZXJhdGlvbiwgYnV0IFFY
TCBkcml2ZXIgaXMgbmVjZXNzYXJ5IGluIGd1ZXN0LiBRWEwgY2FuIGFsc28gd29yaword2l0aCB0
aGUgVk5DIHByb3RvY29sIGxpa2UgYSBzdGFuZGFyZCBWR0Egd2l0aG91dCBhY2NlbGVyYXRpb24u
CisKKz1pdGVtIEI8cXhscmFtPU1CWVRFUz4KKworU2V0cyB0aGUgYW1vdW50IG9mIFJBTSBiYXIg
Zm9yIFFYTCBWR0EgY2FyZC4gVGhlIGRlZmF1bHQgaXMgNjQgTWlCLgorVGhlIHRvdGFsIHNpemUg
b2YgUVhMIHZpZGVvIG1lbW9yeSBpcyBkZXRlcm1pbmVkIGJ5IEI8cXhscmFtPiAoUkFNIGJhcikK
K2FuZCBCPHF4bHZyYW0+IChWUkFNIGJhciksIHRoZSBzaXplIG9mIGVhY2ggaXMgc2V0dGFibGUu
CitCPHZpZGVvcmFtPiBjYW4gc2V0IHRoZSBhbW91bnQgb2YgUkFNIHdoaWNoIGVtdWxhdGVkIHZp
ZGVvIGNhcmQKK3dpbGwgY29udGFpbiwgYnV0IGlmIGl0IGNhbid0IG1lZXQgdGhlIG5lZWQgb2Yg
UVhMLCBpdCB3aWxsIGJlCithZGp1c3RlZCBhY2NvcmRpbmdseS4KKworPWl0ZW0gQjxxeGx2cmFt
PU1CWVRFUz4KKworU2V0cyB0aGUgYW1vdW50IG9mIFZSQU0gYmFyIGZvciBRWEwgVkdBIGNhcmQu
IFRoZSBkZWZhdWx0IGlzIDY0IE1pQi4KIAogPWl0ZW0gQjx2bmM9Qk9PTEVBTj4KIAo=
--f46d0444819fd9777804c1b7eb84
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--f46d0444819fd9777804c1b7eb84--


From xen-devel-bounces@lists.xen.org Tue Jun 05 11:27:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 11:27: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 1SbruC-000124-1a; Tue, 05 Jun 2012 11:26:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SbruA-00011z-GP
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 11:26:30 +0000
Received: from [85.158.139.83:60187] by server-2.bemta-5.messagelabs.com id
	EE/89-20827-5ECEDCF4; Tue, 05 Jun 2012 11:26:29 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338895587!28119829!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24802 invoked from network); 5 Jun 2012 11:26:28 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 11:26:28 -0000
Received: by obfk16 with SMTP id k16so6539617obf.30
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Jun 2012 04:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=w5iYURmxF0pKSZ/44L1mSzJZrMD5/ryRZBNk72p+bas=;
	b=nRevwGRhhqnz2K3TE//+ROeG1BaO/XyRzHFTtHKOU+NJDtI1BKsPGc6jaxidX2tm0U
	yfQV3SeBnJ0om0xYRZZwS1627UlhRXO7+oNgeNinqPYHxWfpnDiBgbjh0Py66Af1bBo4
	xQiqM1xmJAfp5dFb8HTLXCf7Uc+6JNxfkXbuDUVyARysWJ8bLqvHSOqBKIMzyiKijNMp
	jnpGUYlSG2VE7NF/2zs0Mv67OygutfdtVXU9OpFNGqgPcH/vqILBSi+iZPCtEOhIO9t2
	EidY9ZhfoGuxLtOXHpt324H9EPb5qRbFp1uehEIhYZyrX7rhedxwS/7a88p3jzcvPfY8
	XtTw==
MIME-Version: 1.0
Received: by 10.182.86.130 with SMTP id p2mr8347571obz.52.1338895586915; Tue,
	05 Jun 2012 04:26:26 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Tue, 5 Jun 2012 04:26:26 -0700 (PDT)
Date: Tue, 5 Jun 2012 19:26:26 +0800
Message-ID: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=f46d0444819fd9777804c1b7eb84
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel]  [PATCH 3/3] docs: qxl vga interface 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

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

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

diff -r 1804a873a64d docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Jun 05 17:56:46 2012 +0800
+++ b/docs/man/xl.cfg.pod.5	Tue Jun 05 18:58:12 2012 +0800
@@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin

 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). The default is 8MB which is sufficient for
-e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
-amount of video ram is fixed at 4MB which is sufficient for 1024x768
+available. This option is available when using the B<stdvga> and
+B<qxl> options (see below).
+For B<stdvga> option, the default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> options,
+the amount of video ram is fixed at 4MB which is sufficient for 1024x768
 at 32 bpp.
+For B<qxl> option, it may be adjusted automatically (see B<qxlram>
+option below).

 =item B<stdvga=BOOLEAN>

@@ -711,6 +714,27 @@ emulated graphics device. The default is
 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.
+
+=item B<qxl=BOOLEAN>
+
+Select a QXL VGA card as the emulated graphics device. This enables
+the other QXL-related settings.
+In general, QXL should work with the Spice remote display protocol for
+acceleration, but QXL driver is necessary in guest. QXL can also work
+with the VNC protocol like a standard VGA without acceleration.
+
+=item B<qxlram=MBYTES>
+
+Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
+The total size of QXL video memory is determined by B<qxlram> (RAM bar)
+and B<qxlvram> (VRAM bar), the size of each is settable.
+B<videoram> can set the amount of RAM which emulated video card
+will contain, but if it can't meet the need of QXL, it will be
+adjusted accordingly.
+
+=item B<qxlvram=MBYTES>
+
+Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.

 =item B<vnc=BOOLEAN>


-- 
Zhou Peng

--f46d0444819fd9777804c1b7eb84
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support.docs.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support.docs.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h32vs3f20

U2lnbmVkLW9mZi1ieTogWmhvdSBQZW5nIDxhaWx2cGVuZzI1QGdtYWlsLmNvbT4KCmRpZmYgLXIg
MTgwNGE4NzNhNjRkIGRvY3MvbWFuL3hsLmNmZy5wb2QuNQotLS0gYS9kb2NzL21hbi94bC5jZmcu
cG9kLjUJVHVlIEp1biAwNSAxNzo1Njo0NiAyMDEyICswODAwCisrKyBiL2RvY3MvbWFuL3hsLmNm
Zy5wb2QuNQlUdWUgSnVuIDA1IDE4OjU4OjEyIDIwMTIgKzA4MDAKQEAgLTY5OSwxMSArNjk5LDE0
IEBAIGluIHRoZSBCPFZGQl9TUEVDX1NUUklORz4gZm9yIGNvbmZpZ3VyaW4KIAogU2V0cyB0aGUg
YW1vdW50IG9mIFJBTSB3aGljaCB0aGUgZW11bGF0ZWQgdmlkZW8gY2FyZCB3aWxsIGNvbnRhaW4s
CiB3aGljaCBpbiB0dXJuIGxpbWl0cyB0aGUgcmVzb2x1dGlvbnMgYW5kIGJpdCBkZXB0aHMgd2hp
Y2ggd2lsbCBiZQotYXZhaWxhYmxlLiBUaGlzIG9wdGlvbiBpcyBvbmx5IGF2YWlsYWJsZSB3aGVu
IHVzaW5nIHRoZSBCPHN0ZHZnYT4KLW9wdGlvbiAoc2VlIGJlbG93KS4gVGhlIGRlZmF1bHQgaXMg
OE1CIHdoaWNoIGlzIHN1ZmZpY2llbnQgZm9yCi1lLmcuIDE2MDB4MTIwMCBhdCAzMmJwcC4gV2hl
biBub3QgdXNpbmcgdGhlIEI8c3RkdmdhPiBvcHRpb24gdGhlCi1hbW91bnQgb2YgdmlkZW8gcmFt
IGlzIGZpeGVkIGF0IDRNQiB3aGljaCBpcyBzdWZmaWNpZW50IGZvciAxMDI0eDc2OAorYXZhaWxh
YmxlLiBUaGlzIG9wdGlvbiBpcyBhdmFpbGFibGUgd2hlbiB1c2luZyB0aGUgQjxzdGR2Z2E+IGFu
ZAorQjxxeGw+IG9wdGlvbnMgKHNlZSBiZWxvdykuIAorRm9yIEI8c3RkdmdhPiBvcHRpb24sIHRo
ZSBkZWZhdWx0IGlzIDhNQiB3aGljaCBpcyBzdWZmaWNpZW50IGZvcgorZS5nLiAxNjAweDEyMDAg
YXQgMzJicHAuIFdoZW4gbm90IHVzaW5nIHRoZSBCPHN0ZHZnYT4gYW5kIEI8cXhsPiBvcHRpb25z
LAordGhlIGFtb3VudCBvZiB2aWRlbyByYW0gaXMgZml4ZWQgYXQgNE1CIHdoaWNoIGlzIHN1ZmZp
Y2llbnQgZm9yIDEwMjR4NzY4CiBhdCAzMiBicHAuCitGb3IgQjxxeGw+IG9wdGlvbiwgaXQgbWF5
IGJlIGFkanVzdGVkIGF1dG9tYXRpY2FsbHkgKHNlZSBCPHF4bHJhbT4KK29wdGlvbiBiZWxvdyku
CiAKID1pdGVtIEI8c3RkdmdhPUJPT0xFQU4+CiAKQEAgLTcxMSw2ICs3MTQsMjcgQEAgZW11bGF0
ZWQgZ3JhcGhpY3MgZGV2aWNlLiBUaGUgZGVmYXVsdCBpcwogZW11bGF0ZWQgZ3JhcGhpY3MgZGV2
aWNlLiBUaGUgZGVmYXVsdCBpcyBmYWxzZSB3aGljaCBtZWFucyB0byBlbXVsYXRlCiBhIENpcnJ1
cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgZ3Vlc3Qgc3VwcG9ydHMgVkJFIDIuMCBv
cgogbGF0ZXIgKGUuZy4gV2luZG93cyBYUCBvbndhcmRzKSB0aGVuIHlvdSBzaG91bGQgZW5hYmxl
IHRoaXMuCisKKz1pdGVtIEI8cXhsPUJPT0xFQU4+CisKK1NlbGVjdCBhIFFYTCBWR0EgY2FyZCBh
cyB0aGUgZW11bGF0ZWQgZ3JhcGhpY3MgZGV2aWNlLiBUaGlzIGVuYWJsZXMKK3RoZSBvdGhlciBR
WEwtcmVsYXRlZCBzZXR0aW5ncy4KK0luIGdlbmVyYWwsIFFYTCBzaG91bGQgd29yayB3aXRoIHRo
ZSBTcGljZSByZW1vdGUgZGlzcGxheSBwcm90b2NvbCBmb3IKK2FjY2VsZXJhdGlvbiwgYnV0IFFY
TCBkcml2ZXIgaXMgbmVjZXNzYXJ5IGluIGd1ZXN0LiBRWEwgY2FuIGFsc28gd29yaword2l0aCB0
aGUgVk5DIHByb3RvY29sIGxpa2UgYSBzdGFuZGFyZCBWR0Egd2l0aG91dCBhY2NlbGVyYXRpb24u
CisKKz1pdGVtIEI8cXhscmFtPU1CWVRFUz4KKworU2V0cyB0aGUgYW1vdW50IG9mIFJBTSBiYXIg
Zm9yIFFYTCBWR0EgY2FyZC4gVGhlIGRlZmF1bHQgaXMgNjQgTWlCLgorVGhlIHRvdGFsIHNpemUg
b2YgUVhMIHZpZGVvIG1lbW9yeSBpcyBkZXRlcm1pbmVkIGJ5IEI8cXhscmFtPiAoUkFNIGJhcikK
K2FuZCBCPHF4bHZyYW0+IChWUkFNIGJhciksIHRoZSBzaXplIG9mIGVhY2ggaXMgc2V0dGFibGUu
CitCPHZpZGVvcmFtPiBjYW4gc2V0IHRoZSBhbW91bnQgb2YgUkFNIHdoaWNoIGVtdWxhdGVkIHZp
ZGVvIGNhcmQKK3dpbGwgY29udGFpbiwgYnV0IGlmIGl0IGNhbid0IG1lZXQgdGhlIG5lZWQgb2Yg
UVhMLCBpdCB3aWxsIGJlCithZGp1c3RlZCBhY2NvcmRpbmdseS4KKworPWl0ZW0gQjxxeGx2cmFt
PU1CWVRFUz4KKworU2V0cyB0aGUgYW1vdW50IG9mIFZSQU0gYmFyIGZvciBRWEwgVkdBIGNhcmQu
IFRoZSBkZWZhdWx0IGlzIDY0IE1pQi4KIAogPWl0ZW0gQjx2bmM9Qk9PTEVBTj4KIAo=
--f46d0444819fd9777804c1b7eb84
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--f46d0444819fd9777804c1b7eb84--


From xen-devel-bounces@lists.xen.org Tue Jun 05 16:15:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 16:15: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 1SbwPG-0003zb-Nn; Tue, 05 Jun 2012 16:14: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 1SbwPE-0003zW-K5
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:14:52 +0000
Received: from [85.158.143.99:49030] by server-3.bemta-4.messagelabs.com id
	81/DF-29237-B703ECF4; Tue, 05 Jun 2012 16:14:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338912889!23896320!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTcwODUx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24998 invoked from network); 5 Jun 2012 16:14:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jun 2012 16:14:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q55GElLc018885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Jun 2012 16:14: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
	q55GEkFP018868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Jun 2012 16:14:47 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
	q55GEj0F012065; Tue, 5 Jun 2012 11:14:46 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Jun 2012 09:14:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6D3224030D; Tue,  5 Jun 2012 12:07:46 -0400 (EDT)
Date: Tue, 5 Jun 2012 12:07:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120605160746.GB24031@phenom.dumpdata.com>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
 xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In xen_set_pte() if batching is unavailable (because the caller is in
> an interrupt context such as handling a page fault) it would fall back
> to using native_set_pte() and trapping and emulating the PTE write.
> 
> On 32-bit guests this requires two traps for each PTE write (one for
> each dword of the PTE).  Instead, do one mmu_update hypercall
> directly.

OK.
> 
> This significantly improves page fault performance in 32-bit PV
> guests.

Nice!
> 
> lmbench3 test  Before    After     Improvement
> ----------------------------------------------
> lat_pagefault  3.18 us   2.32 us   27%
> lat_proc fork  356 us    313.3 us  11%
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/mmu.c |   16 ++++++++++++++--
>  1 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b8e2794..3bf5dfa 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -308,8 +308,20 @@ static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
>  
>  static inline void __xen_set_pte(pte_t *ptep, pte_t pteval)
>  {
> -	if (!xen_batched_set_pte(ptep, pteval))
> -		native_set_pte(ptep, pteval);
> +	if (!xen_batched_set_pte(ptep, pteval)) {
> +		/*
> +		 * Could call native_set_pte() here and trap and
> +		 * emulate the PTE write but with 32-bit guests this
> +		 * needs two traps (one for each of the two 32-bit
> +		 * words in the PTE) so do one hypercall directly
> +		 * instead.

Ouch.
> +		 */
> +		struct mmu_update u;
> +
> +		u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
> +		u.val = pte_val_ma(pteval);
> +		HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF);
> +	}
>  }
>  
>  static void xen_set_pte(pte_t *ptep, pte_t pteval)
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Tue Jun 05 16:15:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 16:15: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 1SbwPG-0003zb-Nn; Tue, 05 Jun 2012 16:14: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 1SbwPE-0003zW-K5
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:14:52 +0000
Received: from [85.158.143.99:49030] by server-3.bemta-4.messagelabs.com id
	81/DF-29237-B703ECF4; Tue, 05 Jun 2012 16:14:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338912889!23896320!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTcwODUx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24998 invoked from network); 5 Jun 2012 16:14:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jun 2012 16:14:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q55GElLc018885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Jun 2012 16:14: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
	q55GEkFP018868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Jun 2012 16:14:47 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
	q55GEj0F012065; Tue, 5 Jun 2012 11:14:46 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Jun 2012 09:14:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6D3224030D; Tue,  5 Jun 2012 12:07:46 -0400 (EDT)
Date: Tue, 5 Jun 2012 12:07:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120605160746.GB24031@phenom.dumpdata.com>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
 xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> In xen_set_pte() if batching is unavailable (because the caller is in
> an interrupt context such as handling a page fault) it would fall back
> to using native_set_pte() and trapping and emulating the PTE write.
> 
> On 32-bit guests this requires two traps for each PTE write (one for
> each dword of the PTE).  Instead, do one mmu_update hypercall
> directly.

OK.
> 
> This significantly improves page fault performance in 32-bit PV
> guests.

Nice!
> 
> lmbench3 test  Before    After     Improvement
> ----------------------------------------------
> lat_pagefault  3.18 us   2.32 us   27%
> lat_proc fork  356 us    313.3 us  11%
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/mmu.c |   16 ++++++++++++++--
>  1 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b8e2794..3bf5dfa 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -308,8 +308,20 @@ static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
>  
>  static inline void __xen_set_pte(pte_t *ptep, pte_t pteval)
>  {
> -	if (!xen_batched_set_pte(ptep, pteval))
> -		native_set_pte(ptep, pteval);
> +	if (!xen_batched_set_pte(ptep, pteval)) {
> +		/*
> +		 * Could call native_set_pte() here and trap and
> +		 * emulate the PTE write but with 32-bit guests this
> +		 * needs two traps (one for each of the two 32-bit
> +		 * words in the PTE) so do one hypercall directly
> +		 * instead.

Ouch.
> +		 */
> +		struct mmu_update u;
> +
> +		u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
> +		u.val = pte_val_ma(pteval);
> +		HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF);
> +	}
>  }
>  
>  static void xen_set_pte(pte_t *ptep, pte_t pteval)
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Tue Jun 05 16:25:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 16:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SbwYl-00048k-Q0; Tue, 05 Jun 2012 16:24:43 +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 1SbwYl-00048f-9Y
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:24:43 +0000
Received: from [193.109.254.147:59213] by server-2.bemta-14.messagelabs.com id
	AB/1E-27740-AC23ECF4; Tue, 05 Jun 2012 16:24:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338913480!12041934!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTcwODUx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30876 invoked from network); 5 Jun 2012 16:24:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 16:24:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q55GObbL028791
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Jun 2012 16:24: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
	q55GObw9024061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Jun 2012 16:24: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
	q55GObsx008291; Tue, 5 Jun 2012 11:24:37 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Jun 2012 09:24:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 240E54030D; Tue,  5 Jun 2012 12:17:37 -0400 (EDT)
Date: Tue, 5 Jun 2012 12:17:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "aorchis@gmail.com" <aorchis@gmail.com>
Message-ID: <20120605161737.GC24031@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.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
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
> Hi Jeremy and Konrad,

CC-ing xen-devel.

> =

> Basically the driver NVIDIA provided is a binary blob and recent
> versions does not work with the PAT layout of XEN so it falls back to
> MTRR to provide write combining (please correct me if I'm wrong).

OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
NVidia driver? I've had reports that it works OK.

> However there is no MTRR support on XEN so the driver hard crashed my
> machine (I can't ssh into the box anymore).
> =

> Moreover, there is problem with the open source driver 'nouveau' for
> NVIDIA card  (also has something to do with PAT layout of XEN) which
> causes memory corruption.

Huh? Can you point me to a bugzilla please? There was a corruption
issue where you can pass in 'nopat' on the command line.

> =

> I found several patches for XEN which supposedly provide basic MTRR
> support for XEN however there is still no /proc/mtrr. Jeremy, can you
> tell me if you had been able to get /proc/mtrr on XEN dom0?

> =

> Thanks for your time.
> =

> Damien.
> =

> =

> On Sun, Jun 3, 2012 at 5:37 AM, Jeremy Fitzhardinge <jeremy@goop.org> wro=
te:
> > On 06/02/2012 03:13 AM, aorchis@gmail.com wrote:
> >> Hi Jeremy,
> >>
> >> Is there any way I can get back MTRR support in XEN in 3.0 kernel? To
> >> make a long story short, NVIDIA binary driver rejects PAT in XEN and
> >> it falls back to using MTRR but MTRR in XEN was taken out a long time
> >> ago so now there's no way to get the NVIDIA binary blob running under
> >> a linux XEN dom0. I was about to tear my hair out looking for
> >> solutions high and low.
> >
> > Hi!
> >
> > Firstly, Konrad is probably the person you should send this to these
> > days, since I'm not managing to get much Xen stuff done.
> >
> > Secondly, hm. =A0Unfortunately, the changes we did have to integrate Xe=
n's
> > MTRR machinery with Linux have been solidly rejected by the upstream
> > maintainers several times, so I think its unlikely that they will ever
> > make it into the mainline kernel. =A0And it doesn't seem to have really
> > made a difference because PAT does subsume MTRR for at least all the in
> > kernel users, as far as I know.
> >
> > What do you mean by "[the] NVIDIA binary driver rejects PAT in XEN and
> > it falls back to using MTRR"? =A0Why does the Nvidia driver reject PAT?
> > Perhaps addressing that would be a more profitable way of getting this
> > working. =A0In the past we've talked about changing Xen's PAT mapping to
> > match the kernel's (or make it configurable), but for now we're
> > remapping between the PAT schemes in the pte pvops. =A0If the NVIDIA
> > driver is using that mechanism to set ptes (as it must to get anywhere
> > in a pvops kernel), then it should be fine with the remapping. =A0Or its
> > possible they're having problems with reading a pte back and mapping
> > from Xen->Linux PAT formats, which is a problem some of the in-kernel
> > drivers also had. =A0Konrad, how did that turn out in the end?

Attic. I've turned it off since we had corruption issues (the WC didn't
turn back into WB b/c of page_attr using the pte_flag instead of pte_var).
Peter was talking about some software PAT lookup code but I hadn't
focused on that. There is also some performance numbers to run and collect.


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 16:25:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 16:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SbwYl-00048k-Q0; Tue, 05 Jun 2012 16:24:43 +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 1SbwYl-00048f-9Y
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:24:43 +0000
Received: from [193.109.254.147:59213] by server-2.bemta-14.messagelabs.com id
	AB/1E-27740-AC23ECF4; Tue, 05 Jun 2012 16:24:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1338913480!12041934!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTcwODUx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30876 invoked from network); 5 Jun 2012 16:24:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 16:24:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q55GObbL028791
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Jun 2012 16:24: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
	q55GObw9024061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Jun 2012 16:24: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
	q55GObsx008291; Tue, 5 Jun 2012 11:24:37 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Jun 2012 09:24:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 240E54030D; Tue,  5 Jun 2012 12:17:37 -0400 (EDT)
Date: Tue, 5 Jun 2012 12:17:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "aorchis@gmail.com" <aorchis@gmail.com>
Message-ID: <20120605161737.GC24031@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.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
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
> Hi Jeremy and Konrad,

CC-ing xen-devel.

> =

> Basically the driver NVIDIA provided is a binary blob and recent
> versions does not work with the PAT layout of XEN so it falls back to
> MTRR to provide write combining (please correct me if I'm wrong).

OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
NVidia driver? I've had reports that it works OK.

> However there is no MTRR support on XEN so the driver hard crashed my
> machine (I can't ssh into the box anymore).
> =

> Moreover, there is problem with the open source driver 'nouveau' for
> NVIDIA card  (also has something to do with PAT layout of XEN) which
> causes memory corruption.

Huh? Can you point me to a bugzilla please? There was a corruption
issue where you can pass in 'nopat' on the command line.

> =

> I found several patches for XEN which supposedly provide basic MTRR
> support for XEN however there is still no /proc/mtrr. Jeremy, can you
> tell me if you had been able to get /proc/mtrr on XEN dom0?

> =

> Thanks for your time.
> =

> Damien.
> =

> =

> On Sun, Jun 3, 2012 at 5:37 AM, Jeremy Fitzhardinge <jeremy@goop.org> wro=
te:
> > On 06/02/2012 03:13 AM, aorchis@gmail.com wrote:
> >> Hi Jeremy,
> >>
> >> Is there any way I can get back MTRR support in XEN in 3.0 kernel? To
> >> make a long story short, NVIDIA binary driver rejects PAT in XEN and
> >> it falls back to using MTRR but MTRR in XEN was taken out a long time
> >> ago so now there's no way to get the NVIDIA binary blob running under
> >> a linux XEN dom0. I was about to tear my hair out looking for
> >> solutions high and low.
> >
> > Hi!
> >
> > Firstly, Konrad is probably the person you should send this to these
> > days, since I'm not managing to get much Xen stuff done.
> >
> > Secondly, hm. =A0Unfortunately, the changes we did have to integrate Xe=
n's
> > MTRR machinery with Linux have been solidly rejected by the upstream
> > maintainers several times, so I think its unlikely that they will ever
> > make it into the mainline kernel. =A0And it doesn't seem to have really
> > made a difference because PAT does subsume MTRR for at least all the in
> > kernel users, as far as I know.
> >
> > What do you mean by "[the] NVIDIA binary driver rejects PAT in XEN and
> > it falls back to using MTRR"? =A0Why does the Nvidia driver reject PAT?
> > Perhaps addressing that would be a more profitable way of getting this
> > working. =A0In the past we've talked about changing Xen's PAT mapping to
> > match the kernel's (or make it configurable), but for now we're
> > remapping between the PAT schemes in the pte pvops. =A0If the NVIDIA
> > driver is using that mechanism to set ptes (as it must to get anywhere
> > in a pvops kernel), then it should be fine with the remapping. =A0Or its
> > possible they're having problems with reading a pte back and mapping
> > from Xen->Linux PAT formats, which is a problem some of the in-kernel
> > drivers also had. =A0Konrad, how did that turn out in the end?

Attic. I've turned it off since we had corruption issues (the WC didn't
turn back into WB b/c of page_attr using the pte_flag instead of pte_var).
Peter was talking about some software PAT lookup code but I hadn't
focused on that. There is also some performance numbers to run and collect.


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 16:45:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 16:45: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 1SbwsL-0004LR-Mm; Tue, 05 Jun 2012 16:44:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SbwsK-0004LM-8i
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:44:56 +0000
Received: from [85.158.143.99:14166] by server-1.bemta-4.messagelabs.com id
	99/5F-10042-7873ECF4; Tue, 05 Jun 2012 16:44:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1338914693!20243677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExNDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16149 invoked from network); 5 Jun 2012 16:44:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 16:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,718,1330905600"; d="scan'208";a="12844007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jun 2012 16:44:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 5 Jun 2012 17:44:52 +0100
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 1SbwsF-00026g-Ui;
	Tue, 05 Jun 2012 16:44:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SbwsF-000666-Ii;
	Tue, 05 Jun 2012 17:44:51 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13017-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Jun 2012 17:44:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13017: 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 13017 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13017/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 12965
 test-amd64-amd64-win         12 guest-localmigrate/x10       fail   like 12954

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-winxpsp3-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-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-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                6102ace32239ad2174ffbb7d60be8dafee7341a1
baseline version:
 linux                091ce3d38e5e57cf7dd44d66335725910e928f59

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

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

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


Pushing revision :

+ branch=linux-3.0
+ revision=6102ace32239ad2174ffbb7d60be8dafee7341a1
+ . 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 6102ace32239ad2174ffbb7d60be8dafee7341a1
+ branch=linux-3.0
+ revision=6102ace32239ad2174ffbb7d60be8dafee7341a1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 6102ace32239ad2174ffbb7d60be8dafee7341a1:tested/linux-3.0
Counting objects: 1   
Counting objects: 203   
Counting objects: 487, done.
Compressing objects:   1% (1/64)   
Compressing objects:   3% (2/64)   
Compressing objects:   4% (3/64)   
Compressing objects:   6% (4/64)   
Compressing objects:   7% (5/64)   
Compressing objects:   9% (6/64)   
Compressing objects:  10% (7/64)   
Compressing objects:  12% (8/64)   
Compressing objects:  14% (9/64)   
Compressing objects:  15% (10/64)   
Compressing objects:  17% (11/64)   
Compressing objects:  18% (12/64)   
Compressing objects:  20% (13/64)   
Compressing objects:  21% (14/64)   
Compressing objects:  23% (15/64)   
Compressing objects:  25% (16/64)   
Compressing objects:  26% (17/64)   
Compressing objects:  28% (18/64)   
Compressing objects:  29% (19/64)   
Compressing objects:  31% (20/64)   
Compressing objects:  32% (21/64)   
Compressing objects:  34% (22/64)   
Compressing objects:  35% (23/64)   
Compressing objects:  37% (24/64)   
Compressing objects:  39% (25/64)   
Compressing objects:  40% (26/64)   
Compressing objects:  42% (27/64)   
Compressing objects:  43% (28/64)   
Compressing objects:  45% (29/64)   
Compressing objects:  46% (30/64)   
Compressing objects:  48% (31/64)   
Compressing objects:  50% (32/64)   
Compressing objects:  51% (33/64)   
Compressing objects:  53% (34/64)   
Compressing objects:  54% (35/64)   
Compressing objects:  56% (36/64)   
Compressing objects:  57% (37/64)   
Compressing objects:  59% (38/64)   
Compressing objects:  60% (39/64)   
Compressing objects:  62% (40/64)   
Compressing objects:  64% (41/64)   
Compressing objects:  65% (42/64)   
Compressing objects:  67% (43/64)   
Compressing objects:  68% (44/64)   
Compressing objects:  70% (45/64)   
Compressing objects:  71% (46/64)   
Compressing objects:  73% (47/64)   
Compressing objects:  75% (48/64)   
Compressing objects:  76% (49/64)   
Compressing objects:  78% (50/64)   
Compressing objects:  79% (51/64)   
Compressing objects:  81% (52/64)   
Compressing objects:  82% (53/64)   
Compressing objects:  84% (54/64)   
Compressing objects:  85% (55/64)   
Compressing objects:  87% (56/64)   
Compressing objects:  89% (57/64)   
Compressing objects:  90% (58/64)   
Compressing objects:  92% (59/64)   
Compressing objects:  93% (60/64)   
Compressing objects:  95% (61/64)   
Compressing objects:  96% (62/64)   
Compressing objects:  98% (63/64)   
Compressing objects: 100% (64/64)   
Compressing objects: 100% (64/64), done.
Writing objects:   0% (1/346)   
Writing objects:   1% (4/346)   
Writing objects:   2% (7/346)   
Writing objects:   3% (11/346)   
Writing objects:   4% (14/346)   
Writing objects:   5% (18/346)   
Writing objects:   6% (21/346)   
Writing objects:   7% (25/346)   
Writing objects:   8% (28/346)   
Writing objects:   9% (32/346)   
Writing objects:  10% (35/346)   
Writing objects:  11% (39/346)   
Writing objects:  12% (42/346)   
Writing objects:  13% (45/346)   
Writing objects:  14% (49/346)   
Writing objects:  15% (52/346)   
Writing objects:  16% (56/346)   
Writing objects:  17% (59/346)   
Writing objects:  18% (63/346)   
Writing objects:  19% (66/346)   
Writing objects:  20% (70/346)   
Writing objects:  21% (73/346)   
Writing objects:  22% (77/346)   
Writing objects:  23% (80/346)   
Writing objects:  24% (84/346)   
Writing objects:  25% (87/346)   
Writing objects:  26% (90/346)   
Writing objects:  27% (94/346)   
Writing objects:  28% (97/346)   
Writing objects:  29% (101/346)   
Writing objects:  30% (104/346)   
Writing objects:  31% (108/346)   
Writing objects:  32% (111/346)   
Writing objects:  33% (115/346)   
Writing objects:  34% (118/346)   
Writing objects:  35% (122/346)   
Writing objects:  36% (125/346)   
Writing objects:  37% (129/346)   
Writing objects:  38% (132/346)   
Writing objects:  39% (135/346)   
Writing objects:  40% (139/346)   
Writing objects:  41% (142/346)   
Writing objects:  42% (146/346)   
Writing objects:  43% (149/346)   
Writing objects:  44% (153/346)   
Writing objects:  45% (156/346)   
Writing objects:  46% (160/346)   
Writing objects:  47% (163/346)   
Writing objects:  48% (167/346)   
Writing objects:  49% (170/346)   
Writing objects:  50% (173/346)   
Writing objects:  51% (177/346)   
Writing objects:  52% (180/346)   
Writing objects:  53% (184/346)   
Writing objects:  54% (187/346)   
Writing objects:  55% (191/346)   
Writing objects:  56% (194/346)   
Writing objects:  57% (198/346)   
Writing objects:  58% (201/346)   
Writing objects:  59% (205/346)   
Writing objects:  60% (208/346)   
Writing objects:  61% (212/346)   
Writing objects:  62% (215/346)   
Writing objects:  63% (218/346)   
Writing objects:  64% (222/346)   
Writing objects:  65% (225/346)   
Writing objects:  66% (229/346)   
Writing objects:  67% (232/346)   
Writing objects:  68% (236/346)   
Writing objects:  69% (239/346)   
Writing objects:  70% (243/346)   
Writing objects:  71% (246/346)   
Writing objects:  72% (250/346)   
Writing objects:  73% (253/346)   
Writing objects:  74% (257/346)   
Writing objects:  75% (260/346)   
Writing objects:  76% (263/346)   
Writing objects:  77% (267/346)   
Writing objects:  78% (270/346)   
Writing objects:  79% (274/346)   
Writing objects:  80% (277/346)   
Writing objects:  81% (281/346)   
Writing objects:  82% (284/346)   
Writing objects:  83% (288/346)   
Writing objects:  84% (291/346)   
Writing objects:  85% (295/346)   
Writing objects:  86% (298/346)   
Writing objects:  87% (302/346)   
Writing objects:  88% (305/346)   
Writing objects:  89% (308/346)   
Writing objects:  90% (312/346)   
Writing objects:  91% (315/346)   
Writing objects:  92% (319/346)   
Writing objects:  93% (322/346)   
Writing objects:  94% (326/346)   
Writing objects:  95% (329/346)   
Writing objects:  96% (333/346)   
Writing objects:  97% (336/346)   
Writing objects:  98% (340/346)   
Writing objects:  99% (343/346)   
Writing objects: 100% (346/346)   
Writing objects: 100% (346/346), 59.53 KiB, done.
Total 346 (delta 280), reused 346 (delta 280)
To xen@xenbits.xensource.com:git/linux-pvops.git
   091ce3d..6102ace  6102ace32239ad2174ffbb7d60be8dafee7341a1 -> 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 Tue Jun 05 16:45:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 16:45: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 1SbwsL-0004LR-Mm; Tue, 05 Jun 2012 16:44:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SbwsK-0004LM-8i
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:44:56 +0000
Received: from [85.158.143.99:14166] by server-1.bemta-4.messagelabs.com id
	99/5F-10042-7873ECF4; Tue, 05 Jun 2012 16:44:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1338914693!20243677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExNDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16149 invoked from network); 5 Jun 2012 16:44:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 16:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,718,1330905600"; d="scan'208";a="12844007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jun 2012 16:44:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 5 Jun 2012 17:44:52 +0100
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 1SbwsF-00026g-Ui;
	Tue, 05 Jun 2012 16:44:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SbwsF-000666-Ii;
	Tue, 05 Jun 2012 17:44:51 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13017-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Jun 2012 17:44:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13017: 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 13017 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13017/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 12965
 test-amd64-amd64-win         12 guest-localmigrate/x10       fail   like 12954

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-winxpsp3-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-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-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                6102ace32239ad2174ffbb7d60be8dafee7341a1
baseline version:
 linux                091ce3d38e5e57cf7dd44d66335725910e928f59

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

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

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


Pushing revision :

+ branch=linux-3.0
+ revision=6102ace32239ad2174ffbb7d60be8dafee7341a1
+ . 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 6102ace32239ad2174ffbb7d60be8dafee7341a1
+ branch=linux-3.0
+ revision=6102ace32239ad2174ffbb7d60be8dafee7341a1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 6102ace32239ad2174ffbb7d60be8dafee7341a1:tested/linux-3.0
Counting objects: 1   
Counting objects: 203   
Counting objects: 487, done.
Compressing objects:   1% (1/64)   
Compressing objects:   3% (2/64)   
Compressing objects:   4% (3/64)   
Compressing objects:   6% (4/64)   
Compressing objects:   7% (5/64)   
Compressing objects:   9% (6/64)   
Compressing objects:  10% (7/64)   
Compressing objects:  12% (8/64)   
Compressing objects:  14% (9/64)   
Compressing objects:  15% (10/64)   
Compressing objects:  17% (11/64)   
Compressing objects:  18% (12/64)   
Compressing objects:  20% (13/64)   
Compressing objects:  21% (14/64)   
Compressing objects:  23% (15/64)   
Compressing objects:  25% (16/64)   
Compressing objects:  26% (17/64)   
Compressing objects:  28% (18/64)   
Compressing objects:  29% (19/64)   
Compressing objects:  31% (20/64)   
Compressing objects:  32% (21/64)   
Compressing objects:  34% (22/64)   
Compressing objects:  35% (23/64)   
Compressing objects:  37% (24/64)   
Compressing objects:  39% (25/64)   
Compressing objects:  40% (26/64)   
Compressing objects:  42% (27/64)   
Compressing objects:  43% (28/64)   
Compressing objects:  45% (29/64)   
Compressing objects:  46% (30/64)   
Compressing objects:  48% (31/64)   
Compressing objects:  50% (32/64)   
Compressing objects:  51% (33/64)   
Compressing objects:  53% (34/64)   
Compressing objects:  54% (35/64)   
Compressing objects:  56% (36/64)   
Compressing objects:  57% (37/64)   
Compressing objects:  59% (38/64)   
Compressing objects:  60% (39/64)   
Compressing objects:  62% (40/64)   
Compressing objects:  64% (41/64)   
Compressing objects:  65% (42/64)   
Compressing objects:  67% (43/64)   
Compressing objects:  68% (44/64)   
Compressing objects:  70% (45/64)   
Compressing objects:  71% (46/64)   
Compressing objects:  73% (47/64)   
Compressing objects:  75% (48/64)   
Compressing objects:  76% (49/64)   
Compressing objects:  78% (50/64)   
Compressing objects:  79% (51/64)   
Compressing objects:  81% (52/64)   
Compressing objects:  82% (53/64)   
Compressing objects:  84% (54/64)   
Compressing objects:  85% (55/64)   
Compressing objects:  87% (56/64)   
Compressing objects:  89% (57/64)   
Compressing objects:  90% (58/64)   
Compressing objects:  92% (59/64)   
Compressing objects:  93% (60/64)   
Compressing objects:  95% (61/64)   
Compressing objects:  96% (62/64)   
Compressing objects:  98% (63/64)   
Compressing objects: 100% (64/64)   
Compressing objects: 100% (64/64), done.
Writing objects:   0% (1/346)   
Writing objects:   1% (4/346)   
Writing objects:   2% (7/346)   
Writing objects:   3% (11/346)   
Writing objects:   4% (14/346)   
Writing objects:   5% (18/346)   
Writing objects:   6% (21/346)   
Writing objects:   7% (25/346)   
Writing objects:   8% (28/346)   
Writing objects:   9% (32/346)   
Writing objects:  10% (35/346)   
Writing objects:  11% (39/346)   
Writing objects:  12% (42/346)   
Writing objects:  13% (45/346)   
Writing objects:  14% (49/346)   
Writing objects:  15% (52/346)   
Writing objects:  16% (56/346)   
Writing objects:  17% (59/346)   
Writing objects:  18% (63/346)   
Writing objects:  19% (66/346)   
Writing objects:  20% (70/346)   
Writing objects:  21% (73/346)   
Writing objects:  22% (77/346)   
Writing objects:  23% (80/346)   
Writing objects:  24% (84/346)   
Writing objects:  25% (87/346)   
Writing objects:  26% (90/346)   
Writing objects:  27% (94/346)   
Writing objects:  28% (97/346)   
Writing objects:  29% (101/346)   
Writing objects:  30% (104/346)   
Writing objects:  31% (108/346)   
Writing objects:  32% (111/346)   
Writing objects:  33% (115/346)   
Writing objects:  34% (118/346)   
Writing objects:  35% (122/346)   
Writing objects:  36% (125/346)   
Writing objects:  37% (129/346)   
Writing objects:  38% (132/346)   
Writing objects:  39% (135/346)   
Writing objects:  40% (139/346)   
Writing objects:  41% (142/346)   
Writing objects:  42% (146/346)   
Writing objects:  43% (149/346)   
Writing objects:  44% (153/346)   
Writing objects:  45% (156/346)   
Writing objects:  46% (160/346)   
Writing objects:  47% (163/346)   
Writing objects:  48% (167/346)   
Writing objects:  49% (170/346)   
Writing objects:  50% (173/346)   
Writing objects:  51% (177/346)   
Writing objects:  52% (180/346)   
Writing objects:  53% (184/346)   
Writing objects:  54% (187/346)   
Writing objects:  55% (191/346)   
Writing objects:  56% (194/346)   
Writing objects:  57% (198/346)   
Writing objects:  58% (201/346)   
Writing objects:  59% (205/346)   
Writing objects:  60% (208/346)   
Writing objects:  61% (212/346)   
Writing objects:  62% (215/346)   
Writing objects:  63% (218/346)   
Writing objects:  64% (222/346)   
Writing objects:  65% (225/346)   
Writing objects:  66% (229/346)   
Writing objects:  67% (232/346)   
Writing objects:  68% (236/346)   
Writing objects:  69% (239/346)   
Writing objects:  70% (243/346)   
Writing objects:  71% (246/346)   
Writing objects:  72% (250/346)   
Writing objects:  73% (253/346)   
Writing objects:  74% (257/346)   
Writing objects:  75% (260/346)   
Writing objects:  76% (263/346)   
Writing objects:  77% (267/346)   
Writing objects:  78% (270/346)   
Writing objects:  79% (274/346)   
Writing objects:  80% (277/346)   
Writing objects:  81% (281/346)   
Writing objects:  82% (284/346)   
Writing objects:  83% (288/346)   
Writing objects:  84% (291/346)   
Writing objects:  85% (295/346)   
Writing objects:  86% (298/346)   
Writing objects:  87% (302/346)   
Writing objects:  88% (305/346)   
Writing objects:  89% (308/346)   
Writing objects:  90% (312/346)   
Writing objects:  91% (315/346)   
Writing objects:  92% (319/346)   
Writing objects:  93% (322/346)   
Writing objects:  94% (326/346)   
Writing objects:  95% (329/346)   
Writing objects:  96% (333/346)   
Writing objects:  97% (336/346)   
Writing objects:  98% (340/346)   
Writing objects:  99% (343/346)   
Writing objects: 100% (346/346)   
Writing objects: 100% (346/346), 59.53 KiB, done.
Total 346 (delta 280), reused 346 (delta 280)
To xen@xenbits.xensource.com:git/linux-pvops.git
   091ce3d..6102ace  6102ace32239ad2174ffbb7d60be8dafee7341a1 -> 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 Tue Jun 05 17:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 17: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 1SbxIf-0004bZ-4k; Tue, 05 Jun 2012 17:12:09 +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 1SbxId-0004bO-4d
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 17:12:07 +0000
Received: from [85.158.139.83:56543] by server-8.bemta-5.messagelabs.com id
	C3/4C-02058-6ED3ECF4; Tue, 05 Jun 2012 17:12:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338916325!29410047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExNDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15730 invoked from network); 5 Jun 2012 17:12:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 17:12:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,718,1330905600"; d="scan'208";a="12844376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jun 2012 17:12:04 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 5 Jun 2012 18:12:04 +0100
Date: Tue, 5 Jun 2012 18:11:58 +0100
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: <1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-19-git-send-email-ian.campbell@citrix.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] [PATCH 19/38] arm: context switch a bunch of 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 Fri, 1 Jun 2012, Ian Campbell wrote:
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 1a2b95f..339c327 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -61,6 +61,30 @@ static struct {
>  irq_desc_t irq_desc[NR_IRQS];
>  unsigned nr_lrs;
> 
> +void gic_save_state(struct vcpu *v)
> +{
> +    int i;
> +
> +    for ( i=0; i<nr_lrs; i++)
> +        v->arch.gic_lr[i] = GICH[GICH_LR + i];
> +    /* Disable until next VCPU scheduled */
> +    GICH[GICH_HCR] = 0;
> +    isb();
> +}
> +
> +void gic_restore_state(struct vcpu *v)
> +{
> +    int i;
> +
> +    if ( is_idle_vcpu(v) )
> +        return;
> +
> +    for ( i=0; i<nr_lrs; i++)
> +        GICH[GICH_LR + i] = v->arch.gic_lr[i];
> +    GICH[GICH_HCR] = GICH_HCR_EN;
> +    isb();
> +}
> +

it is still missing a bunch of stuff from the gic state but it is a step
in the right direction, so I'll send out patches to complete the gic
context switch separately, based on this one.

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

From xen-devel-bounces@lists.xen.org Tue Jun 05 17:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 17: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 1SbxIf-0004bZ-4k; Tue, 05 Jun 2012 17:12:09 +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 1SbxId-0004bO-4d
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 17:12:07 +0000
Received: from [85.158.139.83:56543] by server-8.bemta-5.messagelabs.com id
	C3/4C-02058-6ED3ECF4; Tue, 05 Jun 2012 17:12:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338916325!29410047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExNDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15730 invoked from network); 5 Jun 2012 17:12:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 17:12:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,718,1330905600"; d="scan'208";a="12844376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jun 2012 17:12:04 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 5 Jun 2012 18:12:04 +0100
Date: Tue, 5 Jun 2012 18:11:58 +0100
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: <1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-19-git-send-email-ian.campbell@citrix.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] [PATCH 19/38] arm: context switch a bunch of 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 Fri, 1 Jun 2012, Ian Campbell wrote:
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 1a2b95f..339c327 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -61,6 +61,30 @@ static struct {
>  irq_desc_t irq_desc[NR_IRQS];
>  unsigned nr_lrs;
> 
> +void gic_save_state(struct vcpu *v)
> +{
> +    int i;
> +
> +    for ( i=0; i<nr_lrs; i++)
> +        v->arch.gic_lr[i] = GICH[GICH_LR + i];
> +    /* Disable until next VCPU scheduled */
> +    GICH[GICH_HCR] = 0;
> +    isb();
> +}
> +
> +void gic_restore_state(struct vcpu *v)
> +{
> +    int i;
> +
> +    if ( is_idle_vcpu(v) )
> +        return;
> +
> +    for ( i=0; i<nr_lrs; i++)
> +        GICH[GICH_LR + i] = v->arch.gic_lr[i];
> +    GICH[GICH_HCR] = GICH_HCR_EN;
> +    isb();
> +}
> +

it is still missing a bunch of stuff from the gic state but it is a step
in the right direction, so I'll send out patches to complete the gic
context switch separately, based on this one.

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

From xen-devel-bounces@lists.xen.org Tue Jun 05 18:02:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 18:02: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 1Sby4z-0005Gz-IF; Tue, 05 Jun 2012 18:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil.rao@ericsson.com>) id 1Sby4x-0005Gu-ED
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 18:02:03 +0000
Received: from [85.158.143.35:24198] by server-1.bemta-4.messagelabs.com id
	D7/98-10042-A994ECF4; Tue, 05 Jun 2012 18:02:02 +0000
X-Env-Sender: anil.rao@ericsson.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338919319!18897863!1
X-Originating-IP: [198.24.6.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjI0LjYuOSA9PiAyNDgyNDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1808 invoked from network); 5 Jun 2012 18:02:01 -0000
Received: from imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.9)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 18:02:01 -0000
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32])
	by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q55I1vKY024319; Tue, 5 Jun 2012 13:01:58 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by
	eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi;
	Tue, 5 Jun 2012 14:01:52 -0400
From: Anil Rao <anil.rao@ericsson.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 5 Jun 2012 14:01:51 -0400
Thread-Topic: [Xen-devel] PCI hotplug related issues
Thread-Index: Ac1C9zKPZLzqOiDpT6GWFP98HlMc5wATIi8A
Message-ID: <DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
In-Reply-To: <4FCDE2A902000078000883C3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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

Thanks for the reply. 

After encountering this problem, I was afraid that only VM-level hotplug is supported by Xen (and not true hotplug at the host-level). Can someone kindly confirm that this is the case? Our current effort depends on host-level hotplug of a PCI device that can (later) be assigned (hotplugged) to a running VM, so a definitive answer will help us to avoid going down the wrong path.

At the same time, I still think its odd that the Xen xm pci-attach command returned success when the attempted hotplug operation actually failed (as reported by the error message printed in the qemu-dm log file). Also, as I have indicated in my earlier post, Xen actually believes that the PCI device is assigned to the target VM (verified this by using xm pci-list to find out the list of devices attached to a VM), which again is very misleading. 

-Anil



-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Tuesday, June 05, 2012 1:43 AM
To: Anil Rao
Cc: xen-devel
Subject: Re: [Xen-devel] PCI hotplug related issues

>>> On 04.06.12 at 21:00, Anil Rao <anil.rao@ericsson.com> wrote:
> A) Does Xen support case 1 (hotplugging a PCI device to a running VM 
> that was powered-on before the device was added to
>     the host)?

As far as I'm aware, only hotplug from the perspective of the guest is really supported/tested.

But the issue here really seems less Xen related, but more towards libpci behavior (as according to qemu this is where the device isn't known). As that's a component Xen/qemu-dm simply builds upon, failure there (e.g. lack of hotplug awareness) would surface as a Xen misbehavior. Quickly going through the list of provided symbols of libpci.so doesn't show anything that looks hotplug related (e.g.
some sort of notification registration). But of course it's possible that I'm overlooking something here, and that in fact qemu-dm's interaction with libpci is simply incomplete.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 18:02:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 18:02: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 1Sby4z-0005Gz-IF; Tue, 05 Jun 2012 18:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil.rao@ericsson.com>) id 1Sby4x-0005Gu-ED
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 18:02:03 +0000
Received: from [85.158.143.35:24198] by server-1.bemta-4.messagelabs.com id
	D7/98-10042-A994ECF4; Tue, 05 Jun 2012 18:02:02 +0000
X-Env-Sender: anil.rao@ericsson.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338919319!18897863!1
X-Originating-IP: [198.24.6.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjI0LjYuOSA9PiAyNDgyNDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1808 invoked from network); 5 Jun 2012 18:02:01 -0000
Received: from imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.9)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 18:02:01 -0000
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32])
	by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q55I1vKY024319; Tue, 5 Jun 2012 13:01:58 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by
	eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi;
	Tue, 5 Jun 2012 14:01:52 -0400
From: Anil Rao <anil.rao@ericsson.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 5 Jun 2012 14:01:51 -0400
Thread-Topic: [Xen-devel] PCI hotplug related issues
Thread-Index: Ac1C9zKPZLzqOiDpT6GWFP98HlMc5wATIi8A
Message-ID: <DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
In-Reply-To: <4FCDE2A902000078000883C3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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

Thanks for the reply. 

After encountering this problem, I was afraid that only VM-level hotplug is supported by Xen (and not true hotplug at the host-level). Can someone kindly confirm that this is the case? Our current effort depends on host-level hotplug of a PCI device that can (later) be assigned (hotplugged) to a running VM, so a definitive answer will help us to avoid going down the wrong path.

At the same time, I still think its odd that the Xen xm pci-attach command returned success when the attempted hotplug operation actually failed (as reported by the error message printed in the qemu-dm log file). Also, as I have indicated in my earlier post, Xen actually believes that the PCI device is assigned to the target VM (verified this by using xm pci-list to find out the list of devices attached to a VM), which again is very misleading. 

-Anil



-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Tuesday, June 05, 2012 1:43 AM
To: Anil Rao
Cc: xen-devel
Subject: Re: [Xen-devel] PCI hotplug related issues

>>> On 04.06.12 at 21:00, Anil Rao <anil.rao@ericsson.com> wrote:
> A) Does Xen support case 1 (hotplugging a PCI device to a running VM 
> that was powered-on before the device was added to
>     the host)?

As far as I'm aware, only hotplug from the perspective of the guest is really supported/tested.

But the issue here really seems less Xen related, but more towards libpci behavior (as according to qemu this is where the device isn't known). As that's a component Xen/qemu-dm simply builds upon, failure there (e.g. lack of hotplug awareness) would surface as a Xen misbehavior. Quickly going through the list of provided symbols of libpci.so doesn't show anything that looks hotplug related (e.g.
some sort of notification registration). But of course it's possible that I'm overlooking something here, and that in fact qemu-dm's interaction with libpci is simply incomplete.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Jun 05 23:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 23: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 1Sc379-0006pZ-1A; Tue, 05 Jun 2012 23:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paton@cs.wisc.edu>) id 1Sc377-0006pU-2T
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 23:24:37 +0000
Received: from [85.158.143.99:63529] by server-2.bemta-4.messagelabs.com id
	A1/5D-25135-4359ECF4; Tue, 05 Jun 2012 23:24:36 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338938665!24915483!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDcyMTEgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23937 invoked from network); 5 Jun 2012 23:24:26 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jun 2012 23:24:26 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q55NOOR3008832
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for <xen-devel@lists.xen.org>; Tue, 5 Jun 2012 18:24:24 -0500
From: James Paton <paton@cs.wisc.edu>
Date: Tue, 5 Jun 2012 18:24:19 -0500
Message-Id: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Subject: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Apologies if this is not the appropriate list, but I thought I would 
have better luck here than on xen-users.

I'm a CS graduate student hacking on the xen-blkback driver and would 
like to be able to debug it using gdb over serial. I have spent a great 
deal of time on this with no success (more details can be found at 
http://bit.ly/KMEF6o (Stack Overflow)). 

It eventually occurred to me that it might not even be possible to do 
what I'm trying to do if Xen intercepts interrupts from the serial port 
and tries to direct them to dom0 through some unexpected channel. Then, 
after I've done `echo g > /proc/sysrq_trigger`, the kernel debugger 
might not see the interrupt. Can anyone confirm or disconfirm this? 
What is the usual procedure for debugging the Dom0 kernel?

Thank you,

James Paton

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

From xen-devel-bounces@lists.xen.org Tue Jun 05 23:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Jun 2012 23: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 1Sc379-0006pZ-1A; Tue, 05 Jun 2012 23:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paton@cs.wisc.edu>) id 1Sc377-0006pU-2T
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 23:24:37 +0000
Received: from [85.158.143.99:63529] by server-2.bemta-4.messagelabs.com id
	A1/5D-25135-4359ECF4; Tue, 05 Jun 2012 23:24:36 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338938665!24915483!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDcyMTEgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23937 invoked from network); 5 Jun 2012 23:24:26 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jun 2012 23:24:26 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q55NOOR3008832
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for <xen-devel@lists.xen.org>; Tue, 5 Jun 2012 18:24:24 -0500
From: James Paton <paton@cs.wisc.edu>
Date: Tue, 5 Jun 2012 18:24:19 -0500
Message-Id: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Subject: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Apologies if this is not the appropriate list, but I thought I would 
have better luck here than on xen-users.

I'm a CS graduate student hacking on the xen-blkback driver and would 
like to be able to debug it using gdb over serial. I have spent a great 
deal of time on this with no success (more details can be found at 
http://bit.ly/KMEF6o (Stack Overflow)). 

It eventually occurred to me that it might not even be possible to do 
what I'm trying to do if Xen intercepts interrupts from the serial port 
and tries to direct them to dom0 through some unexpected channel. Then, 
after I've done `echo g > /proc/sysrq_trigger`, the kernel debugger 
might not see the interrupt. Can anyone confirm or disconfirm this? 
What is the usual procedure for debugging the Dom0 kernel?

Thank you,

James Paton

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 01:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 01:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sc5BI-0003DJ-2E; Wed, 06 Jun 2012 01:37:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jisooy@gmail.com>) id 1Sc5BG-0003DE-PV
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 01:37:02 +0000
Received: from [193.109.254.147:62586] by server-4.bemta-14.messagelabs.com id
	6D/67-27598-E34BECF4; Wed, 06 Jun 2012 01:37:02 +0000
X-Env-Sender: jisooy@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338946608!7813517!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22372 invoked from network); 6 Jun 2012 01:36:49 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 01:36:49 -0000
Received: by ggnp1 with SMTP id p1so5360462ggn.32
	for <xen-devel@lists.xen.org>; Tue, 05 Jun 2012 18:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=g6NzjSfMIr5y+58Jq/J6fZGRag3l6PVxemn45sNWFQc=;
	b=n74A1bN5WEmYwq/DyImfaNd9ARb/hnuQRlCgPpv09BzFfz3HjYgPaJCa1O37K85i3q
	iLAVzfrXvhCtjrd1T6TDenYMcj6NdP2ozbfTSDpQWVa3IEPH5gFXiTxxXvyNraxtxX8C
	2VNg9f5EIsYdrDEfPZIiCUX0rXhxp0XK0NzhihU+X1IoygsQJjCqv9uCSpbUET3jBMxo
	sbKK3wEI3qtjh0AS5JZk/oTAJh/luOLdDI2T6m+TmDmeUEzjI4vPHXTVA39pZpwD+uZg
	IBl0feG3NdXUIGIixoyVduGF77g4Yrbmde7ZYRx7IpnKMsz7w8TkbTtyb8O8Sa6pWnR5
	c7dg==
MIME-Version: 1.0
Received: by 10.50.188.131 with SMTP id ga3mr1829639igc.54.1338946608188; Tue,
	05 Jun 2012 18:36:48 -0700 (PDT)
Received: by 10.42.178.195 with HTTP; Tue, 5 Jun 2012 18:36:47 -0700 (PDT)
Date: Tue, 5 Jun 2012 18:36:47 -0700
Message-ID: <CAALfnVVRvQoKTVho0ixEBi4C2srx8WZy=ZqSerL1xnoCTb-T8w@mail.gmail.com>
From: Jisoo Yang <jisooy@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] page_list_splice() seems buggy (4.1.2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7425428488489141392=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7425428488489141392==
Content-Type: multipart/alternative; boundary=14dae9341157f44bc904c1c3ccda

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

Hello,

It looks like page_list_splice(list, head) in include/xen/mm.h is buggy.
(4.1.2)

After calling it, head->next.prev incorrectly points to the old first page,
when it really should point to null (i.e., PAGE_LIST_NULL).
The 'head' list becomes inconsistent and the system will crash later when
you pop items out from the list. (usually fatal page fault) .

To patch this bug I suggest to remove 'first->list.prev =
page_to_pdx(head->next);' line.

This bug was discovered while I was doing a private project, and the
suggested patch above seems to fix it.

Thanks,
-J

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

Hello,<br><br>It looks like page_list_splice(list, head) in include/xen/mm.=
h is buggy. (4.1.2)<br><br>After calling it, head-&gt;next.prev incorrectly=
 points to the old first page, when it really should point to null (i.e., P=
AGE_LIST_NULL). <br>
The &#39;head&#39; list becomes inconsistent and the system will crash late=
r when you pop items out from the list. (usually fatal page fault) .<br><br=
>To patch this bug I suggest to remove &#39;first-&gt;list.prev =3D page_to=
_pdx(head-&gt;next);&#39; line.<br>
<br>This bug was discovered while I was doing a private project, and the su=
ggested patch above seems to fix it.<br><br>Thanks,<br>-J<br><br><br><br>

--14dae9341157f44bc904c1c3ccda--


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

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

--===============7425428488489141392==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 01:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 01:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sc5BI-0003DJ-2E; Wed, 06 Jun 2012 01:37:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jisooy@gmail.com>) id 1Sc5BG-0003DE-PV
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 01:37:02 +0000
Received: from [193.109.254.147:62586] by server-4.bemta-14.messagelabs.com id
	6D/67-27598-E34BECF4; Wed, 06 Jun 2012 01:37:02 +0000
X-Env-Sender: jisooy@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338946608!7813517!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22372 invoked from network); 6 Jun 2012 01:36:49 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 01:36:49 -0000
Received: by ggnp1 with SMTP id p1so5360462ggn.32
	for <xen-devel@lists.xen.org>; Tue, 05 Jun 2012 18:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=g6NzjSfMIr5y+58Jq/J6fZGRag3l6PVxemn45sNWFQc=;
	b=n74A1bN5WEmYwq/DyImfaNd9ARb/hnuQRlCgPpv09BzFfz3HjYgPaJCa1O37K85i3q
	iLAVzfrXvhCtjrd1T6TDenYMcj6NdP2ozbfTSDpQWVa3IEPH5gFXiTxxXvyNraxtxX8C
	2VNg9f5EIsYdrDEfPZIiCUX0rXhxp0XK0NzhihU+X1IoygsQJjCqv9uCSpbUET3jBMxo
	sbKK3wEI3qtjh0AS5JZk/oTAJh/luOLdDI2T6m+TmDmeUEzjI4vPHXTVA39pZpwD+uZg
	IBl0feG3NdXUIGIixoyVduGF77g4Yrbmde7ZYRx7IpnKMsz7w8TkbTtyb8O8Sa6pWnR5
	c7dg==
MIME-Version: 1.0
Received: by 10.50.188.131 with SMTP id ga3mr1829639igc.54.1338946608188; Tue,
	05 Jun 2012 18:36:48 -0700 (PDT)
Received: by 10.42.178.195 with HTTP; Tue, 5 Jun 2012 18:36:47 -0700 (PDT)
Date: Tue, 5 Jun 2012 18:36:47 -0700
Message-ID: <CAALfnVVRvQoKTVho0ixEBi4C2srx8WZy=ZqSerL1xnoCTb-T8w@mail.gmail.com>
From: Jisoo Yang <jisooy@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] page_list_splice() seems buggy (4.1.2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7425428488489141392=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7425428488489141392==
Content-Type: multipart/alternative; boundary=14dae9341157f44bc904c1c3ccda

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

Hello,

It looks like page_list_splice(list, head) in include/xen/mm.h is buggy.
(4.1.2)

After calling it, head->next.prev incorrectly points to the old first page,
when it really should point to null (i.e., PAGE_LIST_NULL).
The 'head' list becomes inconsistent and the system will crash later when
you pop items out from the list. (usually fatal page fault) .

To patch this bug I suggest to remove 'first->list.prev =
page_to_pdx(head->next);' line.

This bug was discovered while I was doing a private project, and the
suggested patch above seems to fix it.

Thanks,
-J

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

Hello,<br><br>It looks like page_list_splice(list, head) in include/xen/mm.=
h is buggy. (4.1.2)<br><br>After calling it, head-&gt;next.prev incorrectly=
 points to the old first page, when it really should point to null (i.e., P=
AGE_LIST_NULL). <br>
The &#39;head&#39; list becomes inconsistent and the system will crash late=
r when you pop items out from the list. (usually fatal page fault) .<br><br=
>To patch this bug I suggest to remove &#39;first-&gt;list.prev =3D page_to=
_pdx(head-&gt;next);&#39; line.<br>
<br>This bug was discovered while I was doing a private project, and the su=
ggested patch above seems to fix it.<br><br>Thanks,<br>-J<br><br><br><br>

--14dae9341157f44bc904c1c3ccda--


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

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

--===============7425428488489141392==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 06:37:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 06: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 1Sc9rJ-0004wI-Gr; Wed, 06 Jun 2012 06:36:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sc9rH-0004wD-J1
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 06:36:43 +0000
Received: from [85.158.143.35:31999] by server-2.bemta-4.messagelabs.com id
	FC/F7-25135-A7AFECF4; Wed, 06 Jun 2012 06:36:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338964600!18956602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13011 invoked from network); 6 Jun 2012 06:36:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 06:36:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,722,1330905600"; d="scan'208";a="12849738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 06:36:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 07:36:40 +0100
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 1Sc9rD-0006dx-P4;
	Wed, 06 Jun 2012 06:36:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sc9rD-0004wL-I8;
	Wed, 06 Jun 2012 07:36:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13018-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 07:36:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13018: 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 13018 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13018/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13016

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 06:37:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 06: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 1Sc9rJ-0004wI-Gr; Wed, 06 Jun 2012 06:36:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sc9rH-0004wD-J1
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 06:36:43 +0000
Received: from [85.158.143.35:31999] by server-2.bemta-4.messagelabs.com id
	FC/F7-25135-A7AFECF4; Wed, 06 Jun 2012 06:36:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338964600!18956602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13011 invoked from network); 6 Jun 2012 06:36:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 06:36:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,722,1330905600"; d="scan'208";a="12849738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 06:36:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 07:36:40 +0100
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 1Sc9rD-0006dx-P4;
	Wed, 06 Jun 2012 06:36:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sc9rD-0004wL-I8;
	Wed, 06 Jun 2012 07:36:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13018-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 07:36:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13018: 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 13018 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13018/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13016

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bea63e6c780
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 07:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07:00: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 1ScAE6-000599-N6; Wed, 06 Jun 2012 07:00:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1ScAE5-000594-Bu
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:00:17 +0000
Received: from [85.158.143.99:50704] by server-3.bemta-4.messagelabs.com id
	72/2E-29237-0000FCF4; Wed, 06 Jun 2012 07:00:16 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338966014!24949606!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24412 invoked from network); 6 Jun 2012 07:00:15 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 07:00:15 -0000
Received: by wgbed3 with SMTP id ed3so4262386wgb.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 00:00:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=pSQwJE2jGF1cNobucNsttSqJQbn6gL42MOwR3dUIy9c=;
	b=TbFzlLLr159WKUTlx4MtSOIc3sw1OXWwQpoxRz7qH8ngyN7nOjfouLxHidX0ibxLAj
	EC/wU0e47i3p3pV63OmZpNNA1VHMyoZw1H7/jQ6x4YJmjTepgwkxbDuhSlzKtsrvfU2h
	QmLna1Jp4dZtgNwmaFPsk15a+rj5rNc0GOfihkF2zUt8xapmLbkYYRvSsRnMFzBCGsCz
	et2nfMnjX4w3l/StI8OnYEeAZRvDSWmwYPPcNELUYLsg/n2+kgDilAKpUi+kjrSrpMH5
	s4JRI2N+tUruU7xAqnobIFq8i7cZBYcCyD0AL1yKnjKNM//cmMPRHOEQoLFGzOTD7PRA
	xOGQ==
MIME-Version: 1.0
Received: by 10.216.138.130 with SMTP id a2mr1217548wej.35.1338966013697; Wed,
	06 Jun 2012 00:00:13 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Wed, 6 Jun 2012 00:00:13 -0700 (PDT)
Date: Wed, 6 Jun 2012 08:00:13 +0100
Message-ID: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4720039289228189208=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4720039289228189208==
Content-Type: multipart/alternative; boundary=0016e6d7e3539cddd604c1c851b8

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

Hi everybody,

I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
migration does not work. While the source host works on the "xm migrate -l
..." command, I can see the VM on the target host in paused state in "xm
list", but after a while it vanishes while the xm command on the source
machine returns whitout any errors.

(One machine has core i7 processor while another is core 2 quad system).


 I have searched the net and this list and found a few posts mentioning this
error, but no solution, not even a hint
   on the source of the problem.

Any help would be really appreciated. Thanks.

best wishes

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

<div dir=3D"ltr">Hi everybody,<br>
<br>
I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but liv=
e<br>
migration does not work. While the source host works on the &quot;xm migrat=
e -l<br>
...&quot; command, I can see the VM on the target host in paused state in &=
quot;xm<br>
list&quot;, but after a while it vanishes while the xm command on the sourc=
e<br>
machine returns whitout any errors.<br>
<br>
(One machine has core i7 processor while another is core 2 quad system).<br=
>
<br>
<br>
=A0I have searched the net and this list and found a few posts mentioning t=
his<br>
error, but no solution, not even a hint<br>
 =A0 =A0on the source of the problem.<br>
<br>
Any help would be really appreciated. Thanks.<br><br>best wishes<br></div>

--0016e6d7e3539cddd604c1c851b8--


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

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

--===============4720039289228189208==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 07:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07:00: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 1ScAE6-000599-N6; Wed, 06 Jun 2012 07:00:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1ScAE5-000594-Bu
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:00:17 +0000
Received: from [85.158.143.99:50704] by server-3.bemta-4.messagelabs.com id
	72/2E-29237-0000FCF4; Wed, 06 Jun 2012 07:00:16 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338966014!24949606!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24412 invoked from network); 6 Jun 2012 07:00:15 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 07:00:15 -0000
Received: by wgbed3 with SMTP id ed3so4262386wgb.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 00:00:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=pSQwJE2jGF1cNobucNsttSqJQbn6gL42MOwR3dUIy9c=;
	b=TbFzlLLr159WKUTlx4MtSOIc3sw1OXWwQpoxRz7qH8ngyN7nOjfouLxHidX0ibxLAj
	EC/wU0e47i3p3pV63OmZpNNA1VHMyoZw1H7/jQ6x4YJmjTepgwkxbDuhSlzKtsrvfU2h
	QmLna1Jp4dZtgNwmaFPsk15a+rj5rNc0GOfihkF2zUt8xapmLbkYYRvSsRnMFzBCGsCz
	et2nfMnjX4w3l/StI8OnYEeAZRvDSWmwYPPcNELUYLsg/n2+kgDilAKpUi+kjrSrpMH5
	s4JRI2N+tUruU7xAqnobIFq8i7cZBYcCyD0AL1yKnjKNM//cmMPRHOEQoLFGzOTD7PRA
	xOGQ==
MIME-Version: 1.0
Received: by 10.216.138.130 with SMTP id a2mr1217548wej.35.1338966013697; Wed,
	06 Jun 2012 00:00:13 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Wed, 6 Jun 2012 00:00:13 -0700 (PDT)
Date: Wed, 6 Jun 2012 08:00:13 +0100
Message-ID: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4720039289228189208=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4720039289228189208==
Content-Type: multipart/alternative; boundary=0016e6d7e3539cddd604c1c851b8

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

Hi everybody,

I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
migration does not work. While the source host works on the "xm migrate -l
..." command, I can see the VM on the target host in paused state in "xm
list", but after a while it vanishes while the xm command on the source
machine returns whitout any errors.

(One machine has core i7 processor while another is core 2 quad system).


 I have searched the net and this list and found a few posts mentioning this
error, but no solution, not even a hint
   on the source of the problem.

Any help would be really appreciated. Thanks.

best wishes

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

<div dir=3D"ltr">Hi everybody,<br>
<br>
I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but liv=
e<br>
migration does not work. While the source host works on the &quot;xm migrat=
e -l<br>
...&quot; command, I can see the VM on the target host in paused state in &=
quot;xm<br>
list&quot;, but after a while it vanishes while the xm command on the sourc=
e<br>
machine returns whitout any errors.<br>
<br>
(One machine has core i7 processor while another is core 2 quad system).<br=
>
<br>
<br>
=A0I have searched the net and this list and found a few posts mentioning t=
his<br>
error, but no solution, not even a hint<br>
 =A0 =A0on the source of the problem.<br>
<br>
Any help would be really appreciated. Thanks.<br><br>best wishes<br></div>

--0016e6d7e3539cddd604c1c851b8--


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

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

--===============4720039289228189208==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 07:12:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07: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 1ScAPK-0005U9-Eh; Wed, 06 Jun 2012 07:11:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1ScAPI-0005U4-OY
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:11:53 +0000
Received: from [85.158.143.99:39384] by server-2.bemta-4.messagelabs.com id
	74/DC-25135-8B20FCF4; Wed, 06 Jun 2012 07:11:52 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338966709!24469805!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6587 invoked from network); 6 Jun 2012 07:11:50 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-6.tower-216.messagelabs.com with SMTP;
	6 Jun 2012 07:11:50 -0000
Received: from [127.0.0.1] ([::ffff:147.2.207.143])
	by mail.novell.com with ESMTP; Wed, 06 Jun 2012 01:11:34 -0600
MIME-Version: 1.0
X-Mercurial-Node: 2586692a6d74bc11475a0c579c31cdf675d2d529
Message-Id: <2586692a6d74bc11475a.1338966596@linux-bjrd>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 06 Jun 2012 15:09:56 +0800
From: Bamvor Jian Zhang <bjzhang@suse.com>
To: xen-devel@lists.xen.org
Cc: jfehlig@suse.com, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	bjzhang@suse.com
Subject: [Xen-devel] [PATCH] [v4] libxl: Add API to retrieve domain console
	tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 api retrieve domain console from xenstore. With this new api, it is easy
to implement "virsh console" command in libvirt libxl driver.

Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>

Changes since v3:
 * leave variable uninitialised at the top of the function in order to avoid
    hiding the useful compiler warnings.
 * using libxl__strdup instead of strdup in libxl_console_get_tty. benefit from
   the error handling behavior.
   libxl__strdup(0, tty) should be replaced by libxl__strdup(NOGC, tty) after
   Ian Jackson commit his patch: "Do not pass NULL as gc_opt; introduce NOGC."

diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Jun 06 14:35:01 2012 +0800
@@ -1217,7 +1217,8 @@ out:
     return rc;
 }
 
-int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
+int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
+                       libxl_console_type type)
 {
     GC_INIT(ctx);
     char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
@@ -1243,34 +1244,116 @@ out:
     return ERROR_FAIL;
 }
 
-int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path)
+{
+    GC_INIT(ctx);
+    char *dom_path;
+    char *tty_path;
+    char *tty;
+    int rc;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    switch (type) {
+    case LIBXL_CONSOLE_TYPE_SERIAL:
+        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
+        break;
+    case LIBXL_CONSOLE_TYPE_PV:
+        if (cons_num == 0)
+            tty_path = GCSPRINTF("%s/console/tty", dom_path);
+        else
+            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
+                                cons_num);
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+
+    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+    if (!tty) {
+       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
+       rc = ERROR_FAIL;
+       goto out;
+    }
+
+    *path = libxl__strdup(0, tty);
+    rc = 0;
+out:
+    GC_FREE;
+    return rc;
+}
+
+static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
+                                       uint32_t *domid, int *cons_num, 
+                                       libxl_console_type *type)
 {
     GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
     int rc;
-    if (stubdomid)
-        rc = libxl_console_exec(ctx, stubdomid,
-                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
-    else {
+
+    if (stubdomid) {
+        *domid = stubdomid;
+        *cons_num = STUBDOM_CONSOLE_SERIAL;
+        *type = LIBXL_CONSOLE_TYPE_PV;
+    } else {
         switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_SERIAL;
             break;
         case LIBXL_DOMAIN_TYPE_PV:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_PV;
             break;
         case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
-            rc = ERROR_FAIL;
+            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
+            rc = ERROR_INVAL;
+            goto out;
             break;
         default:
             abort();
         }
     }
+    
+    rc = 0;
+out:
     GC_FREE;
     return rc;
 }
 
+int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_exec(ctx, domid, cons_num, type);
+}
+
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
+                                  char **path)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_get_tty(ctx, domid, cons_num, type, path);
+}
+
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
     GC_INIT(ctx);
diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl.h	Wed Jun 06 14:35:01 2012 +0800
@@ -570,6 +570,18 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
 
+/* libxl_console_get_tty retrieves the specified domain's console tty path
+ * and stores it in path. Caller is responsible for freeing the memory.
+ */
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path);
+
+/* libxl_primary_console_get_tty retrieves the specified domain's primary 
+ * console tty path and stores it in path. Caller is responsible for freeing
+ * the memory.
+ */
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path);
+
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 07:12:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07: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 1ScAPK-0005U9-Eh; Wed, 06 Jun 2012 07:11:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1ScAPI-0005U4-OY
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:11:53 +0000
Received: from [85.158.143.99:39384] by server-2.bemta-4.messagelabs.com id
	74/DC-25135-8B20FCF4; Wed, 06 Jun 2012 07:11:52 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1338966709!24469805!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6587 invoked from network); 6 Jun 2012 07:11:50 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-6.tower-216.messagelabs.com with SMTP;
	6 Jun 2012 07:11:50 -0000
Received: from [127.0.0.1] ([::ffff:147.2.207.143])
	by mail.novell.com with ESMTP; Wed, 06 Jun 2012 01:11:34 -0600
MIME-Version: 1.0
X-Mercurial-Node: 2586692a6d74bc11475a0c579c31cdf675d2d529
Message-Id: <2586692a6d74bc11475a.1338966596@linux-bjrd>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 06 Jun 2012 15:09:56 +0800
From: Bamvor Jian Zhang <bjzhang@suse.com>
To: xen-devel@lists.xen.org
Cc: jfehlig@suse.com, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	bjzhang@suse.com
Subject: [Xen-devel] [PATCH] [v4] libxl: Add API to retrieve domain console
	tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 api retrieve domain console from xenstore. With this new api, it is easy
to implement "virsh console" command in libvirt libxl driver.

Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>

Changes since v3:
 * leave variable uninitialised at the top of the function in order to avoid
    hiding the useful compiler warnings.
 * using libxl__strdup instead of strdup in libxl_console_get_tty. benefit from
   the error handling behavior.
   libxl__strdup(0, tty) should be replaced by libxl__strdup(NOGC, tty) after
   Ian Jackson commit his patch: "Do not pass NULL as gc_opt; introduce NOGC."

diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Jun 06 14:35:01 2012 +0800
@@ -1217,7 +1217,8 @@ out:
     return rc;
 }
 
-int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
+int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
+                       libxl_console_type type)
 {
     GC_INIT(ctx);
     char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
@@ -1243,34 +1244,116 @@ out:
     return ERROR_FAIL;
 }
 
-int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path)
+{
+    GC_INIT(ctx);
+    char *dom_path;
+    char *tty_path;
+    char *tty;
+    int rc;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    switch (type) {
+    case LIBXL_CONSOLE_TYPE_SERIAL:
+        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
+        break;
+    case LIBXL_CONSOLE_TYPE_PV:
+        if (cons_num == 0)
+            tty_path = GCSPRINTF("%s/console/tty", dom_path);
+        else
+            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
+                                cons_num);
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+
+    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+    if (!tty) {
+       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
+       rc = ERROR_FAIL;
+       goto out;
+    }
+
+    *path = libxl__strdup(0, tty);
+    rc = 0;
+out:
+    GC_FREE;
+    return rc;
+}
+
+static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
+                                       uint32_t *domid, int *cons_num, 
+                                       libxl_console_type *type)
 {
     GC_INIT(ctx);
     uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
     int rc;
-    if (stubdomid)
-        rc = libxl_console_exec(ctx, stubdomid,
-                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
-    else {
+
+    if (stubdomid) {
+        *domid = stubdomid;
+        *cons_num = STUBDOM_CONSOLE_SERIAL;
+        *type = LIBXL_CONSOLE_TYPE_PV;
+    } else {
         switch (libxl__domain_type(gc, domid_vm)) {
         case LIBXL_DOMAIN_TYPE_HVM:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_SERIAL;
             break;
         case LIBXL_DOMAIN_TYPE_PV:
-            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
+            *domid = domid_vm;
+            *cons_num = 0;
+            *type = LIBXL_CONSOLE_TYPE_PV;
             break;
         case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
-            rc = ERROR_FAIL;
+            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
+            rc = ERROR_INVAL;
+            goto out;
             break;
         default:
             abort();
         }
     }
+    
+    rc = 0;
+out:
     GC_FREE;
     return rc;
 }
 
+int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_exec(ctx, domid, cons_num, type);
+}
+
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
+                                  char **path)
+{
+    uint32_t domid;
+    int cons_num;
+    libxl_console_type type;
+    int rc;
+
+    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
+    if ( rc ) return rc;
+    return libxl_console_get_tty(ctx, domid, cons_num, type, path);
+}
+
 int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 {
     GC_INIT(ctx);
diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/libxl/libxl.h	Wed Jun 06 14:35:01 2012 +0800
@@ -570,6 +570,18 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
 
+/* libxl_console_get_tty retrieves the specified domain's console tty path
+ * and stores it in path. Caller is responsible for freeing the memory.
+ */
+int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
+                          libxl_console_type type, char **path);
+
+/* libxl_primary_console_get_tty retrieves the specified domain's primary 
+ * console tty path and stores it in path. Caller is responsible for freeing
+ * the memory.
+ */
+int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path);
+
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 07:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07: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 1ScAnA-0005wN-Gg; Wed, 06 Jun 2012 07:36:32 +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 1ScAn8-0005wI-E0
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:36:30 +0000
Received: from [85.158.139.83:22620] by server-7.bemta-5.messagelabs.com id
	65/5C-19648-D780FCF4; Wed, 06 Jun 2012 07:36:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1338968188!24975298!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28755 invoked from network); 6 Jun 2012 07:36:28 -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; 6 Jun 2012 07:36:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 08:36:27 +0100
Message-Id: <4FCF2499020000780008865E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 08:36:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anil Rao" <anil.rao@ericsson.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
	<DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
In-Reply-To: <DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 05.06.12 at 20:01, Anil Rao <anil.rao@ericsson.com> wrote:
> After encountering this problem, I was afraid that only VM-level hotplug is 
> supported by Xen (and not true hotplug at the host-level). Can someone kindly 
> confirm that this is the case? Our current effort depends on host-level 
> hotplug of a PCI device that can (later) be assigned (hotplugged) to a 
> running VM, so a definitive answer will help us to avoid going down the wrong 
> path.

That is not a proper statement - host side holtplug is still supported,
just that currently it may need to happen before the target VM gets
created. Overcoming limitations like this is certainly desirable, but will
obviously require someone to actually invest work - the question
would hence be whether, given that you're interested in this feature
and posted on xen-devel, you wouldn't also want to look into
addressing this (provided my brief analysis of the situation is correct
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 Wed Jun 06 07:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07: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 1ScAnA-0005wN-Gg; Wed, 06 Jun 2012 07:36:32 +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 1ScAn8-0005wI-E0
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:36:30 +0000
Received: from [85.158.139.83:22620] by server-7.bemta-5.messagelabs.com id
	65/5C-19648-D780FCF4; Wed, 06 Jun 2012 07:36:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1338968188!24975298!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28755 invoked from network); 6 Jun 2012 07:36:28 -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; 6 Jun 2012 07:36:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 08:36:27 +0100
Message-Id: <4FCF2499020000780008865E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 08:36:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anil Rao" <anil.rao@ericsson.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
	<DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
In-Reply-To: <DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 05.06.12 at 20:01, Anil Rao <anil.rao@ericsson.com> wrote:
> After encountering this problem, I was afraid that only VM-level hotplug is 
> supported by Xen (and not true hotplug at the host-level). Can someone kindly 
> confirm that this is the case? Our current effort depends on host-level 
> hotplug of a PCI device that can (later) be assigned (hotplugged) to a 
> running VM, so a definitive answer will help us to avoid going down the wrong 
> path.

That is not a proper statement - host side holtplug is still supported,
just that currently it may need to happen before the target VM gets
created. Overcoming limitations like this is certainly desirable, but will
obviously require someone to actually invest work - the question
would hence be whether, given that you're interested in this feature
and posted on xen-devel, you wouldn't also want to look into
addressing this (provided my brief analysis of the situation is correct
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 Wed Jun 06 07:42:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07: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 1ScAsX-00067J-9T; Wed, 06 Jun 2012 07:42: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 1ScAsV-00067B-Nu
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:42:03 +0000
Received: from [85.158.139.83:10730] by server-9.bemta-5.messagelabs.com id
	15/DD-29678-AC90FCF4; Wed, 06 Jun 2012 07:42:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338968521!30676379!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6892 invoked from network); 6 Jun 2012 07:42:02 -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; 6 Jun 2012 07:42:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 08:42:01 +0100
Message-Id: <4FCF25E7020000780008866D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 08:41:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "elahe shekuhi" <e.shekuhi@gmail.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
In-Reply-To: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 09:00, elahe shekuhi <e.shekuhi@gmail.com> wrote:
> I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
> migration does not work. While the source host works on the "xm migrate -l
> ..." command, I can see the VM on the target host in paused state in "xm
> list", but after a while it vanishes while the xm command on the source
> machine returns whitout any errors.

Does the guest crash perhaps? In which case a kernel log from it
might turn out pretty useful. As would technical data (rather than
a simple "does not work") in the first place (hypervisor, xend, and
Dom0 kernel logs are all possible candidates for holding relevant
information).

> (One machine has core i7 processor while another is core 2
> quad system).

Does migration fail in both directions? Or perhaps just from the
newer to the older system (in which case I would guess you're
not masking features properly on the newer one)?

Jan



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 07:42:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 07: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 1ScAsX-00067J-9T; Wed, 06 Jun 2012 07:42: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 1ScAsV-00067B-Nu
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 07:42:03 +0000
Received: from [85.158.139.83:10730] by server-9.bemta-5.messagelabs.com id
	15/DD-29678-AC90FCF4; Wed, 06 Jun 2012 07:42:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338968521!30676379!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6892 invoked from network); 6 Jun 2012 07:42:02 -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; 6 Jun 2012 07:42:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 08:42:01 +0100
Message-Id: <4FCF25E7020000780008866D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 08:41:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "elahe shekuhi" <e.shekuhi@gmail.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
In-Reply-To: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 09:00, elahe shekuhi <e.shekuhi@gmail.com> wrote:
> I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
> migration does not work. While the source host works on the "xm migrate -l
> ..." command, I can see the VM on the target host in paused state in "xm
> list", but after a while it vanishes while the xm command on the source
> machine returns whitout any errors.

Does the guest crash perhaps? In which case a kernel log from it
might turn out pretty useful. As would technical data (rather than
a simple "does not work") in the first place (hypervisor, xend, and
Dom0 kernel logs are all possible candidates for holding relevant
information).

> (One machine has core i7 processor while another is core 2
> quad system).

Does migration fail in both directions? Or perhaps just from the
newer to the older system (in which case I would guess you're
not masking features properly on the newer one)?

Jan



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 08:15:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScBOs-0006rD-Qg; Wed, 06 Jun 2012 08:15: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 1ScBOr-0006r8-ET
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:15:29 +0000
Received: from [85.158.138.51:48317] by server-11.bemta-3.messagelabs.com id
	80/B2-28329-0A11FCF4; Wed, 06 Jun 2012 08:15:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338970527!22103612!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17358 invoked from network); 6 Jun 2012 08:15:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jun 2012 08:15:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 09:15:26 +0100
Message-Id: <4FCF2DBC0200007800088677@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 09:15:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jisoo Yang" <jisooy@gmail.com>
References: <CAALfnVVRvQoKTVho0ixEBi4C2srx8WZy=ZqSerL1xnoCTb-T8w@mail.gmail.com>
In-Reply-To: <CAALfnVVRvQoKTVho0ixEBi4C2srx8WZy=ZqSerL1xnoCTb-T8w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] page_list_splice() seems buggy (4.1.2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.06.12 at 03:36, Jisoo Yang <jisooy@gmail.com> wrote:
> It looks like page_list_splice(list, head) in include/xen/mm.h is buggy.
> (4.1.2)
> 
> After calling it, head->next.prev incorrectly points to the old first page,
> when it really should point to null (i.e., PAGE_LIST_NULL).
> The 'head' list becomes inconsistent and the system will crash later when
> you pop items out from the list. (usually fatal page fault) .
> 
> To patch this bug I suggest to remove 'first->list.prev =
> page_to_pdx(head->next);' line.

While removing this line indeed appears to be correct, it would
make it less obvious to compare the functionality here with
__list_splice(). Therefore I'd replace it either with

    ASSERT(first->list.prev == PAGE_LIST_NULL);

or with (possibly commented out, i.e. just for documentation)

    first->list.prev = at->list.prev;

Apparently the sole current in-tree user simply doesn't
reference head->next.prev, and hence the bug never
manifested itself.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 08:15:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScBOs-0006rD-Qg; Wed, 06 Jun 2012 08:15: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 1ScBOr-0006r8-ET
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:15:29 +0000
Received: from [85.158.138.51:48317] by server-11.bemta-3.messagelabs.com id
	80/B2-28329-0A11FCF4; Wed, 06 Jun 2012 08:15:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338970527!22103612!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17358 invoked from network); 6 Jun 2012 08:15:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jun 2012 08:15:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 09:15:26 +0100
Message-Id: <4FCF2DBC0200007800088677@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 09:15:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jisoo Yang" <jisooy@gmail.com>
References: <CAALfnVVRvQoKTVho0ixEBi4C2srx8WZy=ZqSerL1xnoCTb-T8w@mail.gmail.com>
In-Reply-To: <CAALfnVVRvQoKTVho0ixEBi4C2srx8WZy=ZqSerL1xnoCTb-T8w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] page_list_splice() seems buggy (4.1.2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.06.12 at 03:36, Jisoo Yang <jisooy@gmail.com> wrote:
> It looks like page_list_splice(list, head) in include/xen/mm.h is buggy.
> (4.1.2)
> 
> After calling it, head->next.prev incorrectly points to the old first page,
> when it really should point to null (i.e., PAGE_LIST_NULL).
> The 'head' list becomes inconsistent and the system will crash later when
> you pop items out from the list. (usually fatal page fault) .
> 
> To patch this bug I suggest to remove 'first->list.prev =
> page_to_pdx(head->next);' line.

While removing this line indeed appears to be correct, it would
make it less obvious to compare the functionality here with
__list_splice(). Therefore I'd replace it either with

    ASSERT(first->list.prev == PAGE_LIST_NULL);

or with (possibly commented out, i.e. just for documentation)

    first->list.prev = at->list.prev;

Apparently the sole current in-tree user simply doesn't
reference head->next.prev, and hence the bug never
manifested itself.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 08:23:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:23: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 1ScBWP-000712-NQ; Wed, 06 Jun 2012 08:23:17 +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 1ScBWO-00070x-IE
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:23:16 +0000
Received: from [85.158.138.51:20129] by server-2.bemta-3.messagelabs.com id
	EA/89-16299-3731FCF4; Wed, 06 Jun 2012 08:23:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338970994!31029169!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21616 invoked from network); 6 Jun 2012 08:23:15 -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; 6 Jun 2012 08:23:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 09:23:14 +0100
Message-Id: <4FCF2F90020000780008868A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 09:23:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9BB51660.1__="
Cc: Jisoo Yang <jisooy@gmail.com>
Subject: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part9BB51660.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Other than in __list_splice(), the first element's prev pointer doesn't
need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
the assignment (to formally match __list_splice()), simply assert that
this assignment is really unnecessary.

Reported-by: Jisoo Yang <jisooy@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
     last =3D list->tail;
     at =3D head->next;
=20
-    first->list.prev =3D page_to_pdx(head->next);
+    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
+    ASSERT(first->list.prev =3D=3D at->list.prev);
     head->next =3D first;
=20
     last->list.next =3D page_to_pdx(at);




--=__Part9BB51660.1__=
Content-Type: text/plain; name="page-list-splice.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="page-list-splice.patch"

fix page_list_splice()=0A=0AOther than in __list_splice(), the first =
element's prev pointer doesn't=0Aneed adjustment here - it already is =
PAGE_LIST_NULL. Rather than fixing=0Athe assignment (to formally match =
__list_splice()), simply assert that=0Athis assignment is really unnecessar=
y.=0A=0AReported-by: Jisoo Yang <jisooy@gmail.com>=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/include/xen/mm.h=0A+++ =
b/xen/include/xen/mm.h=0A@@ -270,7 +270,8 @@ page_list_splice(struct =
page_list_head *=0A     last =3D list->tail;=0A     at =3D head->next;=0A =
=0A-    first->list.prev =3D page_to_pdx(head->next);=0A+    /* Both =
first->list.prev and at->list.prev are PAGE_LIST_NULL. */=0A+    ASSERT(fir=
st->list.prev =3D=3D at->list.prev);=0A     head->next =3D first;=0A =0A   =
  last->list.next =3D page_to_pdx(at);=0A
--=__Part9BB51660.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

--=__Part9BB51660.1__=--


From xen-devel-bounces@lists.xen.org Wed Jun 06 08:23:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:23: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 1ScBWP-000712-NQ; Wed, 06 Jun 2012 08:23:17 +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 1ScBWO-00070x-IE
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:23:16 +0000
Received: from [85.158.138.51:20129] by server-2.bemta-3.messagelabs.com id
	EA/89-16299-3731FCF4; Wed, 06 Jun 2012 08:23:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338970994!31029169!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21616 invoked from network); 6 Jun 2012 08:23:15 -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; 6 Jun 2012 08:23:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 09:23:14 +0100
Message-Id: <4FCF2F90020000780008868A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 09:23:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9BB51660.1__="
Cc: Jisoo Yang <jisooy@gmail.com>
Subject: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part9BB51660.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Other than in __list_splice(), the first element's prev pointer doesn't
need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
the assignment (to formally match __list_splice()), simply assert that
this assignment is really unnecessary.

Reported-by: Jisoo Yang <jisooy@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
     last =3D list->tail;
     at =3D head->next;
=20
-    first->list.prev =3D page_to_pdx(head->next);
+    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
+    ASSERT(first->list.prev =3D=3D at->list.prev);
     head->next =3D first;
=20
     last->list.next =3D page_to_pdx(at);




--=__Part9BB51660.1__=
Content-Type: text/plain; name="page-list-splice.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="page-list-splice.patch"

fix page_list_splice()=0A=0AOther than in __list_splice(), the first =
element's prev pointer doesn't=0Aneed adjustment here - it already is =
PAGE_LIST_NULL. Rather than fixing=0Athe assignment (to formally match =
__list_splice()), simply assert that=0Athis assignment is really unnecessar=
y.=0A=0AReported-by: Jisoo Yang <jisooy@gmail.com>=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/include/xen/mm.h=0A+++ =
b/xen/include/xen/mm.h=0A@@ -270,7 +270,8 @@ page_list_splice(struct =
page_list_head *=0A     last =3D list->tail;=0A     at =3D head->next;=0A =
=0A-    first->list.prev =3D page_to_pdx(head->next);=0A+    /* Both =
first->list.prev and at->list.prev are PAGE_LIST_NULL. */=0A+    ASSERT(fir=
st->list.prev =3D=3D at->list.prev);=0A     head->next =3D first;=0A =0A   =
  last->list.next =3D page_to_pdx(at);=0A
--=__Part9BB51660.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

--=__Part9BB51660.1__=--


From xen-devel-bounces@lists.xen.org Wed Jun 06 08:51:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:51: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 1ScBww-0007V2-MG; Wed, 06 Jun 2012 08:50:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScBwv-0007Ut-N8
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:50:41 +0000
Received: from [85.158.143.99:16960] by server-3.bemta-4.messagelabs.com id
	CE/C9-29237-1E91FCF4; Wed, 06 Jun 2012 08:50:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1338972639!30627028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29425 invoked from network); 6 Jun 2012 08:50:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 08:50:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12852383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 08: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.213.0; Wed, 6 Jun 2012
	09:50:37 +0100
Message-ID: <1338972636.32319.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Will McDermott <wmcdermott@seq.org>
Date: Wed, 6 Jun 2012 09:50:36 +0100
In-Reply-To: <assp.0501a9d0b5.4FCB71EC020000C900015D24@smtp.seq.org>
References: <assp.0501a9d0b5.4FCB71EC020000C900015D24@smtp.seq.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] Xen unstable fails to build on ubutnu
	12.04
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gU3VuLCAyMDEyLTA2LTAzIGF0IDIyOjE2ICswMTAwLCBXaWxsIE1jRGVybW90dCB3cm90ZToK
PiBIZWxsbywKPiAKPiBJIGFtIHRyeWluZyB0byBjb21waWxlIHhlbiA0LjIgdW5zdGFibGUgZnJv
bSBtZXJjdXJpYWwuIEkgY2FuJ3QgZ2V0IHBhc3QKPiB0aGUgbWFrZSB0b29scyBzdGVwLiBXaGVu
IEkgcnVuIG1ha2UgdG9vbHMsIHRoZSBidWlsZCBmYWlscyB3aXRoOgoKVGhhbmtzIFdpbGwsIHRo
aXMgbG9va3MgbGlrZSBhIG5ldyBvbmUsIEkndmUgbm90IG5vdGljZWQgYW55IHJlcG9ydHMgb2YK
dGhpcyBiZWZvcmUuIENDaW5nIHhlbi1kZXZlbEAgYW5kIG91ciBRZW11IGZvbGtzLgoKR3V5cywg
dGhpcyBsb29rcyBsaWtlCmh0dHA6Ly9saXN0cy5nbnUub3JnL2FyY2hpdmUvaHRtbC9xZW11LWRl
dmVsLzIwMTItMDIvbXNnMDM0NjAuaHRtbCBvcgpodHRwczovL2J1Z3MubGF1bmNocGFkLm5ldC91
YnVudHUvK3NvdXJjZS9xZW11LWt2bS8rYnVnLzkzMDE4MSAod2hpY2gKV2lsbCByZWZlcmVuY2Vz
IGJlbG93KS4gSSBkaWRuJ3QgbG9vayBpZiBhbnkgcGF0Y2ggaGFzIGdvbmUgaW4gdXBzdHJlYW0K
b3Igbm90LgoKSSBjYW4ndCBleHBsYWluIHdoeSBvdGhlciBVYnVudHUgdXNlcnMgYXJlbid0IHNl
ZWluZyB0aGlzIHRob3VnaC4KCklhbi4KCj4gCj4gQ0MgICAgbGliaHc2NC85cGZzL2NveGF0dHIu
bwo+ICAgQ0MgICAgbGliaHc2NC85cGZzL3ZpcnRpby05cC1zeW50aC5vCj4gICBDQyAgICBsaWJo
dzY0LzlwZnMvdmlydGlvLTlwLWhhbmRsZS5vCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRpby05cC1oYW5kbGUuYzogSW4KPiBmdW5jdGlvbiDD
omhhbmRsZV91cGRhdGVfZmlsZV9jcmVkw6I6Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRpby05cC1oYW5kbGUuYzo3MDo1ODoKPiBlcnJvcjog
w6JBVF9FTVBUWV9QQVRIw6IgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24p
Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRp
by05cC1oYW5kbGUuYzo3MDo1ODoKPiBub3RlOiBlYWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciBp
cyByZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24KPiBpdCBhcHBlYXJzIGluCj4g
L3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRpby05
cC1oYW5kbGUuYzogSW4KPiBmdW5jdGlvbiDDomhhbmRsZV9sc3RhdMOiOgo+IC9yb290L3hlbi11
bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvOXBmcy92aXJ0aW8tOXAtaGFuZGxlLmM6
ODc6MzQ6Cj4gZXJyb3I6IMOiQVRfRU1QVFlfUEFUSMOiIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSBp
biB0aGlzIGZ1bmN0aW9uKQo+IC9yb290L3hlbi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1k
aXIvaHcvOXBmcy92aXJ0aW8tOXAtaGFuZGxlLmM6IEluCj4gZnVuY3Rpb24gw6JoYW5kbGVfc3lt
bGlua8OiOgo+IC9yb290L3hlbi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvOXBm
cy92aXJ0aW8tOXAtaGFuZGxlLmM6MzE0OjYyOgo+IGVycm9yOiDDokFUX0VNUFRZX1BBVEjDoiB1
bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikKPiAvcm9vdC94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvcWVtdS14ZW4tZGlyL2h3LzlwZnMvdmlydGlvLTlwLWhhbmRsZS5jOiBJbgo+
IGZ1bmN0aW9uIMOiaGFuZGxlX2xpbmvDojoKPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
cWVtdS14ZW4tZGlyL2h3LzlwZnMvdmlydGlvLTlwLWhhbmRsZS5jOjMzNzo0NToKPiBlcnJvcjog
w6JBVF9FTVBUWV9QQVRIw6IgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24p
Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRp
by05cC1oYW5kbGUuYzogSW4KPiBmdW5jdGlvbiDDomhhbmRsZV9jaG93bsOiOgo+IC9yb290L3hl
bi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvOXBmcy92aXJ0aW8tOXAtaGFuZGxl
LmM6MzczOjU4Ogo+IGVycm9yOiDDokFUX0VNUFRZX1BBVEjDoiB1bmRlY2xhcmVkIChmaXJzdCB1
c2UgaW4gdGhpcyBmdW5jdGlvbikKPiBtYWtlWzRdOiAqKiogWzlwZnMvdmlydGlvLTlwLWhhbmRs
ZS5vXSBFcnJvciAxCj4gbWFrZVszXTogKioqIFtzdWJkaXItbGliaHc2NF0gRXJyb3IgMgo+IG1h
a2VbM106IExlYXZpbmcgZGlyZWN0b3J5Cj4gYC9yb290L3hlbi11bnN0YWJsZS5oZy90b29scy9x
ZW11LXhlbi1kaXItcmVtb3RlJwo+IG1ha2VbMl06ICoqKiBbc3ViZGlyLWluc3RhbGwtcWVtdS14
ZW4tZGlyXSBFcnJvciAyCj4gbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9yb290L3hlbi11
bnN0YWJsZS5oZy90b29scycKPiBtYWtlWzFdOiAqKiogW3N1YmRpcnMtaW5zdGFsbF0gRXJyb3Ig
Mgo+IG1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4tdW5zdGFibGUuaGcvdG9v
bHMnCj4gbWFrZTogKioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyCj4gCj4gSSBhbSBydW5uaW5n
IHVidW50dSAxMi4wNCwga2VybmVsIHZlcjogMy4yLjAtMjQtZ2VuZXJpYyAKPiAKPiBBbnkgaWRl
YXM/IEkgaGF2ZSBnb29nbGVkIGZ1cmlvdXNseSBhbmQgZm91bmQgc29tZSBwZW9wbGUgdGFsa2lu
ZyBhYm91dAo+IHFlbXUta3ZtIGhhdmluZyB0aGUgc2FtZSBpc3N1ZToKPiBodHRwczovL2J1Z3Mu
bGF1bmNocGFkLm5ldC91YnVudHUvK3NvdXJjZS9xZW11LWt2bS8rYnVnLzkzMDE4MQo+IEJ1dCBJ
IHdhcyBub3QgYWJsZSB0byBmaW5kIHRoZSBwYXRjaAo+IAo+IFRoYW5rcyBpbiBhZHZhbmNlIQo+
IAo+IAo+IAo+IE1lcmN1cmlhbG0KPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+IFhlbi11c2VycyBtYWlsaW5nIGxpc3QKPiBYZW4tdXNlcnNAbGlz
dHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2VycwoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 08:51:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:51: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 1ScBww-0007V2-MG; Wed, 06 Jun 2012 08:50:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScBwv-0007Ut-N8
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:50:41 +0000
Received: from [85.158.143.99:16960] by server-3.bemta-4.messagelabs.com id
	CE/C9-29237-1E91FCF4; Wed, 06 Jun 2012 08:50:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1338972639!30627028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29425 invoked from network); 6 Jun 2012 08:50:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 08:50:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12852383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 08: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.213.0; Wed, 6 Jun 2012
	09:50:37 +0100
Message-ID: <1338972636.32319.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Will McDermott <wmcdermott@seq.org>
Date: Wed, 6 Jun 2012 09:50:36 +0100
In-Reply-To: <assp.0501a9d0b5.4FCB71EC020000C900015D24@smtp.seq.org>
References: <assp.0501a9d0b5.4FCB71EC020000C900015D24@smtp.seq.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] Xen unstable fails to build on ubutnu
	12.04
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gU3VuLCAyMDEyLTA2LTAzIGF0IDIyOjE2ICswMTAwLCBXaWxsIE1jRGVybW90dCB3cm90ZToK
PiBIZWxsbywKPiAKPiBJIGFtIHRyeWluZyB0byBjb21waWxlIHhlbiA0LjIgdW5zdGFibGUgZnJv
bSBtZXJjdXJpYWwuIEkgY2FuJ3QgZ2V0IHBhc3QKPiB0aGUgbWFrZSB0b29scyBzdGVwLiBXaGVu
IEkgcnVuIG1ha2UgdG9vbHMsIHRoZSBidWlsZCBmYWlscyB3aXRoOgoKVGhhbmtzIFdpbGwsIHRo
aXMgbG9va3MgbGlrZSBhIG5ldyBvbmUsIEkndmUgbm90IG5vdGljZWQgYW55IHJlcG9ydHMgb2YK
dGhpcyBiZWZvcmUuIENDaW5nIHhlbi1kZXZlbEAgYW5kIG91ciBRZW11IGZvbGtzLgoKR3V5cywg
dGhpcyBsb29rcyBsaWtlCmh0dHA6Ly9saXN0cy5nbnUub3JnL2FyY2hpdmUvaHRtbC9xZW11LWRl
dmVsLzIwMTItMDIvbXNnMDM0NjAuaHRtbCBvcgpodHRwczovL2J1Z3MubGF1bmNocGFkLm5ldC91
YnVudHUvK3NvdXJjZS9xZW11LWt2bS8rYnVnLzkzMDE4MSAod2hpY2gKV2lsbCByZWZlcmVuY2Vz
IGJlbG93KS4gSSBkaWRuJ3QgbG9vayBpZiBhbnkgcGF0Y2ggaGFzIGdvbmUgaW4gdXBzdHJlYW0K
b3Igbm90LgoKSSBjYW4ndCBleHBsYWluIHdoeSBvdGhlciBVYnVudHUgdXNlcnMgYXJlbid0IHNl
ZWluZyB0aGlzIHRob3VnaC4KCklhbi4KCj4gCj4gQ0MgICAgbGliaHc2NC85cGZzL2NveGF0dHIu
bwo+ICAgQ0MgICAgbGliaHc2NC85cGZzL3ZpcnRpby05cC1zeW50aC5vCj4gICBDQyAgICBsaWJo
dzY0LzlwZnMvdmlydGlvLTlwLWhhbmRsZS5vCj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRpby05cC1oYW5kbGUuYzogSW4KPiBmdW5jdGlvbiDD
omhhbmRsZV91cGRhdGVfZmlsZV9jcmVkw6I6Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRpby05cC1oYW5kbGUuYzo3MDo1ODoKPiBlcnJvcjog
w6JBVF9FTVBUWV9QQVRIw6IgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24p
Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRp
by05cC1oYW5kbGUuYzo3MDo1ODoKPiBub3RlOiBlYWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciBp
cyByZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24KPiBpdCBhcHBlYXJzIGluCj4g
L3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRpby05
cC1oYW5kbGUuYzogSW4KPiBmdW5jdGlvbiDDomhhbmRsZV9sc3RhdMOiOgo+IC9yb290L3hlbi11
bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvOXBmcy92aXJ0aW8tOXAtaGFuZGxlLmM6
ODc6MzQ6Cj4gZXJyb3I6IMOiQVRfRU1QVFlfUEFUSMOiIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSBp
biB0aGlzIGZ1bmN0aW9uKQo+IC9yb290L3hlbi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1k
aXIvaHcvOXBmcy92aXJ0aW8tOXAtaGFuZGxlLmM6IEluCj4gZnVuY3Rpb24gw6JoYW5kbGVfc3lt
bGlua8OiOgo+IC9yb290L3hlbi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvOXBm
cy92aXJ0aW8tOXAtaGFuZGxlLmM6MzE0OjYyOgo+IGVycm9yOiDDokFUX0VNUFRZX1BBVEjDoiB1
bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikKPiAvcm9vdC94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvcWVtdS14ZW4tZGlyL2h3LzlwZnMvdmlydGlvLTlwLWhhbmRsZS5jOiBJbgo+
IGZ1bmN0aW9uIMOiaGFuZGxlX2xpbmvDojoKPiAvcm9vdC94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
cWVtdS14ZW4tZGlyL2h3LzlwZnMvdmlydGlvLTlwLWhhbmRsZS5jOjMzNzo0NToKPiBlcnJvcjog
w6JBVF9FTVBUWV9QQVRIw6IgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24p
Cj4gL3Jvb3QveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody85cGZzL3ZpcnRp
by05cC1oYW5kbGUuYzogSW4KPiBmdW5jdGlvbiDDomhhbmRsZV9jaG93bsOiOgo+IC9yb290L3hl
bi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvOXBmcy92aXJ0aW8tOXAtaGFuZGxl
LmM6MzczOjU4Ogo+IGVycm9yOiDDokFUX0VNUFRZX1BBVEjDoiB1bmRlY2xhcmVkIChmaXJzdCB1
c2UgaW4gdGhpcyBmdW5jdGlvbikKPiBtYWtlWzRdOiAqKiogWzlwZnMvdmlydGlvLTlwLWhhbmRs
ZS5vXSBFcnJvciAxCj4gbWFrZVszXTogKioqIFtzdWJkaXItbGliaHc2NF0gRXJyb3IgMgo+IG1h
a2VbM106IExlYXZpbmcgZGlyZWN0b3J5Cj4gYC9yb290L3hlbi11bnN0YWJsZS5oZy90b29scy9x
ZW11LXhlbi1kaXItcmVtb3RlJwo+IG1ha2VbMl06ICoqKiBbc3ViZGlyLWluc3RhbGwtcWVtdS14
ZW4tZGlyXSBFcnJvciAyCj4gbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9yb290L3hlbi11
bnN0YWJsZS5oZy90b29scycKPiBtYWtlWzFdOiAqKiogW3N1YmRpcnMtaW5zdGFsbF0gRXJyb3Ig
Mgo+IG1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4tdW5zdGFibGUuaGcvdG9v
bHMnCj4gbWFrZTogKioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyCj4gCj4gSSBhbSBydW5uaW5n
IHVidW50dSAxMi4wNCwga2VybmVsIHZlcjogMy4yLjAtMjQtZ2VuZXJpYyAKPiAKPiBBbnkgaWRl
YXM/IEkgaGF2ZSBnb29nbGVkIGZ1cmlvdXNseSBhbmQgZm91bmQgc29tZSBwZW9wbGUgdGFsa2lu
ZyBhYm91dAo+IHFlbXUta3ZtIGhhdmluZyB0aGUgc2FtZSBpc3N1ZToKPiBodHRwczovL2J1Z3Mu
bGF1bmNocGFkLm5ldC91YnVudHUvK3NvdXJjZS9xZW11LWt2bS8rYnVnLzkzMDE4MQo+IEJ1dCBJ
IHdhcyBub3QgYWJsZSB0byBmaW5kIHRoZSBwYXRjaAo+IAo+IFRoYW5rcyBpbiBhZHZhbmNlIQo+
IAo+IAo+IAo+IE1lcmN1cmlhbG0KPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+IFhlbi11c2VycyBtYWlsaW5nIGxpc3QKPiBYZW4tdXNlcnNAbGlz
dHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2VycwoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 08:53:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08: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 1ScBzD-0007iQ-SG; Wed, 06 Jun 2012 08:53: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 1ScBzB-0007i3-H6
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:53:01 +0000
Received: from [85.158.143.99:31305] by server-2.bemta-4.messagelabs.com id
	BF/48-25135-C6A1FCF4; Wed, 06 Jun 2012 08:53:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1338972776!21742296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28782 invoked from network); 6 Jun 2012 08:52:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 08:52:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12852437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 08:52:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	09:52:56 +0100
Message-ID: <1338972775.32319.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 09:52:55 +0100
In-Reply-To: <4FCF25E7020000780008866D@nat28.tlf.novell.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: elahe shekuhi <e.shekuhi@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 08:41 +0100, Jan Beulich wrote:
> >>> On 06.06.12 at 09:00, elahe shekuhi <e.shekuhi@gmail.com> wrote:
> > I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
> > migration does not work. While the source host works on the "xm migrate -l
> > ..." command, I can see the VM on the target host in paused state in "xm
> > list", but after a while it vanishes while the xm command on the source
> > machine returns whitout any errors.
> 
> Does the guest crash perhaps? In which case a kernel log from it
> might turn out pretty useful. As would technical data (rather than
> a simple "does not work") in the first place (hypervisor, xend, and
> Dom0 kernel logs are all possible candidates for holding relevant
> information).

Elahe, please see http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen
for advice about the kind of information which you can usefully include
in a bug report.

Thanks,
Ian.

> 
> > (One machine has core i7 processor while another is core 2
> > quad system).
> 
> Does migration fail in both directions? Or perhaps just from the
> newer to the older system (in which case I would guess you're
> not masking features properly on the newer one)?
> 
> 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 Jun 06 08:53:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08: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 1ScBzD-0007iQ-SG; Wed, 06 Jun 2012 08:53: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 1ScBzB-0007i3-H6
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:53:01 +0000
Received: from [85.158.143.99:31305] by server-2.bemta-4.messagelabs.com id
	BF/48-25135-C6A1FCF4; Wed, 06 Jun 2012 08:53:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1338972776!21742296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28782 invoked from network); 6 Jun 2012 08:52:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 08:52:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12852437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 08:52:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	09:52:56 +0100
Message-ID: <1338972775.32319.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 09:52:55 +0100
In-Reply-To: <4FCF25E7020000780008866D@nat28.tlf.novell.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: elahe shekuhi <e.shekuhi@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 08:41 +0100, Jan Beulich wrote:
> >>> On 06.06.12 at 09:00, elahe shekuhi <e.shekuhi@gmail.com> wrote:
> > I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but live
> > migration does not work. While the source host works on the "xm migrate -l
> > ..." command, I can see the VM on the target host in paused state in "xm
> > list", but after a while it vanishes while the xm command on the source
> > machine returns whitout any errors.
> 
> Does the guest crash perhaps? In which case a kernel log from it
> might turn out pretty useful. As would technical data (rather than
> a simple "does not work") in the first place (hypervisor, xend, and
> Dom0 kernel logs are all possible candidates for holding relevant
> information).

Elahe, please see http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen
for advice about the kind of information which you can usefully include
in a bug report.

Thanks,
Ian.

> 
> > (One machine has core i7 processor while another is core 2
> > quad system).
> 
> Does migration fail in both directions? Or perhaps just from the
> newer to the older system (in which case I would guess you're
> not masking features properly on the newer one)?
> 
> 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 Jun 06 08:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:54: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 1ScC0G-0007op-AV; Wed, 06 Jun 2012 08:54:08 +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 1ScC0E-0007oc-VL
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:54:07 +0000
Received: from [85.158.143.99:37655] by server-3.bemta-4.messagelabs.com id
	5E/BF-29237-EAA1FCF4; Wed, 06 Jun 2012 08:54:06 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338972844!24970257!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gODMzNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32289 invoked from network); 6 Jun 2012 08:54:05 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	6 Jun 2012 08:54:05 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q568s3wo014755;
	Wed, 6 Jun 2012 04:54:03 -0400
Date: Wed, 06 Jun 2012 04:54:03 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <1726d244-d951-4651-bfee-16ac14b56096@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <c30e80f1-120e-4b42-ab33-c53bbe714a94@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


https://bugzilla.redhat.com/show_bug.cgi?id=829016

was opened yesterday. Maybe the following commit
is the culprit?

commit cb8095bba6d24118135a5683a956f4f4fb5f17bb
Author: Jan Beulich <JBeulich@suse.com>
Date:   Fri Jan 20 16:22:04 2012 +0000

    x86: atomic64 assembly improvements

Drew

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 08:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 08:54: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 1ScC0G-0007op-AV; Wed, 06 Jun 2012 08:54:08 +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 1ScC0E-0007oc-VL
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 08:54:07 +0000
Received: from [85.158.143.99:37655] by server-3.bemta-4.messagelabs.com id
	5E/BF-29237-EAA1FCF4; Wed, 06 Jun 2012 08:54:06 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338972844!24970257!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gODMzNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32289 invoked from network); 6 Jun 2012 08:54:05 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	6 Jun 2012 08:54:05 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q568s3wo014755;
	Wed, 6 Jun 2012 04:54:03 -0400
Date: Wed, 06 Jun 2012 04:54:03 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <1726d244-d951-4651-bfee-16ac14b56096@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <c30e80f1-120e-4b42-ab33-c53bbe714a94@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


https://bugzilla.redhat.com/show_bug.cgi?id=829016

was opened yesterday. Maybe the following commit
is the culprit?

commit cb8095bba6d24118135a5683a956f4f4fb5f17bb
Author: Jan Beulich <JBeulich@suse.com>
Date:   Fri Jan 20 16:22:04 2012 +0000

    x86: atomic64 assembly improvements

Drew

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:02:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:02: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 1ScC8J-0000Gk-T8; Wed, 06 Jun 2012 09:02:27 +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 1ScC8I-0000Ga-6j
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:02:26 +0000
Received: from [85.158.138.51:5648] by server-9.bemta-3.messagelabs.com id
	3A/0A-15054-1AC1FCF4; Wed, 06 Jun 2012 09:02:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338973344!31038263!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18565 invoked from network); 6 Jun 2012 09:02:24 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:02:24 -0000
Received: by eekd41 with SMTP id d41so2390388eek.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 02:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lOYaboM6jhLdJ7J1H++n2rHWcTXj1b4kcLlvNc6XJo8=;
	b=OphScut5RzbQSnzTWJtbRn/loUXZXMWp0SdV3RZJPrXBNx8Z/42rIJwoOQi9Or1ejV
	5sAjZeEMpFk8EkmEhHx4TX8C8H4vilNEYiSdJbs+GUDG6X4j0SBHvY+jGAtM/rgwVSKk
	4+7r+mzJRYb57VG6vXihr6TX0367zmiYzuRAmSNqwNOlxjgE5jd5/iNAm7HoRghHEiq5
	OGcdUbwXTAp5yRqq8IWR2iz+dp9cnIL2WFAdCWMMfWTyRJfq/ZaHdSDzIzSCvHhVt0p8
	hdfxKRELSMlXT1iVeXCzeQcXrUR++Xqb+ldptYnzLIkEdMABYvKZMclia0FYCjrG738t
	tp8g==
Received: by 10.14.188.130 with SMTP id a2mr8980791een.86.1338973344392;
	Wed, 06 Jun 2012 02:02:24 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-18-132.range81-152.btcentralplus.com.
	[81.152.18.132])
	by mx.google.com with ESMTPS id y3sm3940375eem.16.2012.06.06.02.02.18
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 02:02:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 06 Jun 2012 10:02:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBF4DB24.41FB1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] fix page_list_splice()
Thread-Index: Ac1Dww9rlU/aMLekvkacNJmqutiRlA==
In-Reply-To: <4FCF2F90020000780008868A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jisoo Yang <jisooy@gmail.com>
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:

> Other than in __list_splice(), the first element's prev pointer doesn't
> need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
> the assignment (to formally match __list_splice()), simply assert that
> this assignment is really unnecessary.
>
> Reported-by: Jisoo Yang <jisooy@gmail.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
>      last = list->tail;
>      at = head->next;
>  
> -    first->list.prev = page_to_pdx(head->next);
> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */

ASSERT(first->list.prev == PAGE_LIST_NULL); ?

It seems odd to have one assumption encoded as an ASSERTion, and one as a
code comment... A second assertion makes the assumption explicit, and
run-time checked in debug builds.

 -- Keir

> +    ASSERT(first->list.prev == at->list.prev);
>      head->next = first;
>  
>      last->list.next = page_to_pdx(at);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 09:02:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:02: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 1ScC8J-0000Gk-T8; Wed, 06 Jun 2012 09:02:27 +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 1ScC8I-0000Ga-6j
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:02:26 +0000
Received: from [85.158.138.51:5648] by server-9.bemta-3.messagelabs.com id
	3A/0A-15054-1AC1FCF4; Wed, 06 Jun 2012 09:02:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338973344!31038263!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18565 invoked from network); 6 Jun 2012 09:02:24 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:02:24 -0000
Received: by eekd41 with SMTP id d41so2390388eek.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 02:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lOYaboM6jhLdJ7J1H++n2rHWcTXj1b4kcLlvNc6XJo8=;
	b=OphScut5RzbQSnzTWJtbRn/loUXZXMWp0SdV3RZJPrXBNx8Z/42rIJwoOQi9Or1ejV
	5sAjZeEMpFk8EkmEhHx4TX8C8H4vilNEYiSdJbs+GUDG6X4j0SBHvY+jGAtM/rgwVSKk
	4+7r+mzJRYb57VG6vXihr6TX0367zmiYzuRAmSNqwNOlxjgE5jd5/iNAm7HoRghHEiq5
	OGcdUbwXTAp5yRqq8IWR2iz+dp9cnIL2WFAdCWMMfWTyRJfq/ZaHdSDzIzSCvHhVt0p8
	hdfxKRELSMlXT1iVeXCzeQcXrUR++Xqb+ldptYnzLIkEdMABYvKZMclia0FYCjrG738t
	tp8g==
Received: by 10.14.188.130 with SMTP id a2mr8980791een.86.1338973344392;
	Wed, 06 Jun 2012 02:02:24 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-18-132.range81-152.btcentralplus.com.
	[81.152.18.132])
	by mx.google.com with ESMTPS id y3sm3940375eem.16.2012.06.06.02.02.18
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 02:02:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 06 Jun 2012 10:02:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CBF4DB24.41FB1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] fix page_list_splice()
Thread-Index: Ac1Dww9rlU/aMLekvkacNJmqutiRlA==
In-Reply-To: <4FCF2F90020000780008868A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jisoo Yang <jisooy@gmail.com>
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:

> Other than in __list_splice(), the first element's prev pointer doesn't
> need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
> the assignment (to formally match __list_splice()), simply assert that
> this assignment is really unnecessary.
>
> Reported-by: Jisoo Yang <jisooy@gmail.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
>      last = list->tail;
>      at = head->next;
>  
> -    first->list.prev = page_to_pdx(head->next);
> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */

ASSERT(first->list.prev == PAGE_LIST_NULL); ?

It seems odd to have one assumption encoded as an ASSERTion, and one as a
code comment... A second assertion makes the assumption explicit, and
run-time checked in debug builds.

 -- Keir

> +    ASSERT(first->list.prev == at->list.prev);
>      head->next = first;
>  
>      last->list.next = page_to_pdx(at);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 09:10:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCFx-0000tW-8C; Wed, 06 Jun 2012 09:10:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Simon.Rowe@eu.citrix.com>) id 1ScCFv-0000sy-Nr
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:10:19 +0000
Received: from [85.158.138.51:55229] by server-3.bemta-3.messagelabs.com id
	27/0B-25608-A7E1FCF4; Wed, 06 Jun 2012 09:10:18 +0000
X-Env-Sender: Simon.Rowe@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1338973816!30998739!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkwNDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10797 invoked from network); 6 Jun 2012 09:10:18 -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;
	6 Jun 2012 09:10:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="27022088"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 05:10:16 -0400
Received: from drall.uk.xensource.com (10.80.227.107) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 05:10:15 -0400
MIME-Version: 1.0
X-Mercurial-Node: 711a707dc776045dfdc786b9b2b3ad8b97e3e6c3
Message-ID: <711a707dc776045dfdc7.1338973649@drall.uk.xensource.com>
In-Reply-To: <patchbomb.1338973648@drall.uk.xensource.com>
References: <patchbomb.1338973648@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 10:07:29 +0100
From: Simon Rowe <simon.rowe@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: simon.rowe@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V3] xs: block signals in watch wakeup
	thread
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 thread created to wakeup watchers is not intended to handle signals
(and a later patch will reduce it's stack size which makes it unsuitable
for doing so).

Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>

diff -r 6bea63e6c780 -r 711a707dc776 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/xenstore/xs.c	Wed Jun 06 10:04:15 2012 +0100
@@ -705,11 +705,18 @@ bool xs_watch(struct xs_handle *h, const
 	/* We dynamically create a reader thread on demand. */
 	mutex_lock(&h->request_mutex);
 	if (!h->read_thr_exists) {
+		sigset_t set, old_set;
+
+		sigfillset(&set);
+		pthread_sigmask(SIG_SETMASK, &set, &old_set);
+
 		if (pthread_create(&h->read_thr, NULL, read_thread, h) != 0) {
+			pthread_sigmask(SIG_SETMASK, &old_set, NULL);
 			mutex_unlock(&h->request_mutex);
 			return false;
 		}
 		h->read_thr_exists = 1;
+		pthread_sigmask(SIG_SETMASK, &old_set, NULL);
 	}
 	mutex_unlock(&h->request_mutex);
 #endif

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:10:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCFx-0000tW-8C; Wed, 06 Jun 2012 09:10:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Simon.Rowe@eu.citrix.com>) id 1ScCFv-0000sy-Nr
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:10:19 +0000
Received: from [85.158.138.51:55229] by server-3.bemta-3.messagelabs.com id
	27/0B-25608-A7E1FCF4; Wed, 06 Jun 2012 09:10:18 +0000
X-Env-Sender: Simon.Rowe@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1338973816!30998739!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkwNDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10797 invoked from network); 6 Jun 2012 09:10:18 -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;
	6 Jun 2012 09:10:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="27022088"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 05:10:16 -0400
Received: from drall.uk.xensource.com (10.80.227.107) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 05:10:15 -0400
MIME-Version: 1.0
X-Mercurial-Node: 711a707dc776045dfdc786b9b2b3ad8b97e3e6c3
Message-ID: <711a707dc776045dfdc7.1338973649@drall.uk.xensource.com>
In-Reply-To: <patchbomb.1338973648@drall.uk.xensource.com>
References: <patchbomb.1338973648@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 10:07:29 +0100
From: Simon Rowe <simon.rowe@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: simon.rowe@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V3] xs: block signals in watch wakeup
	thread
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 thread created to wakeup watchers is not intended to handle signals
(and a later patch will reduce it's stack size which makes it unsuitable
for doing so).

Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>

diff -r 6bea63e6c780 -r 711a707dc776 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c	Sat Jun 02 08:39:45 2012 +0100
+++ b/tools/xenstore/xs.c	Wed Jun 06 10:04:15 2012 +0100
@@ -705,11 +705,18 @@ bool xs_watch(struct xs_handle *h, const
 	/* We dynamically create a reader thread on demand. */
 	mutex_lock(&h->request_mutex);
 	if (!h->read_thr_exists) {
+		sigset_t set, old_set;
+
+		sigfillset(&set);
+		pthread_sigmask(SIG_SETMASK, &set, &old_set);
+
 		if (pthread_create(&h->read_thr, NULL, read_thread, h) != 0) {
+			pthread_sigmask(SIG_SETMASK, &old_set, NULL);
 			mutex_unlock(&h->request_mutex);
 			return false;
 		}
 		h->read_thr_exists = 1;
+		pthread_sigmask(SIG_SETMASK, &old_set, NULL);
 	}
 	mutex_unlock(&h->request_mutex);
 #endif

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:10:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:10: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 1ScCFw-0000tK-RL; Wed, 06 Jun 2012 09:10:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Simon.Rowe@eu.citrix.com>) id 1ScCFv-0000t0-KJ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:10:19 +0000
Received: from [85.158.143.99:35323] by server-2.bemta-4.messagelabs.com id
	95/09-25135-A7E1FCF4; Wed, 06 Jun 2012 09:10:18 +0000
X-Env-Sender: Simon.Rowe@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338973815!24973683!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgwMDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12646 invoked from network); 6 Jun 2012 09:10:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:10:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197696156"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 05:10:15 -0400
Received: from drall.uk.xensource.com (10.80.227.107) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 05:10:15 -0400
MIME-Version: 1.0
Message-ID: <patchbomb.1338973648@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 10:07:28 +0100
From: Simon Rowe <simon.rowe@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: simon.rowe@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V3] xs: fixes to watch thread creation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 pair of patches to the xenstore library that:

  1) blocks signal delivery before creating the watch wakeup thread

  2) reduces the stack size of the watch wakeup thread.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:10:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:10: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 1ScCFw-0000tK-RL; Wed, 06 Jun 2012 09:10:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Simon.Rowe@eu.citrix.com>) id 1ScCFv-0000t0-KJ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:10:19 +0000
Received: from [85.158.143.99:35323] by server-2.bemta-4.messagelabs.com id
	95/09-25135-A7E1FCF4; Wed, 06 Jun 2012 09:10:18 +0000
X-Env-Sender: Simon.Rowe@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338973815!24973683!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgwMDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12646 invoked from network); 6 Jun 2012 09:10:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:10:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197696156"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 05:10:15 -0400
Received: from drall.uk.xensource.com (10.80.227.107) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 05:10:15 -0400
MIME-Version: 1.0
Message-ID: <patchbomb.1338973648@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 10:07:28 +0100
From: Simon Rowe <simon.rowe@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: simon.rowe@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V3] xs: fixes to watch thread creation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 pair of patches to the xenstore library that:

  1) blocks signal delivery before creating the watch wakeup thread

  2) reduces the stack size of the watch wakeup thread.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:10:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:10: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 1ScCG0-0000ur-SF; Wed, 06 Jun 2012 09:10:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Simon.Rowe@eu.citrix.com>) id 1ScCFy-0000t0-V4
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:10:23 +0000
Received: from [85.158.143.35:21465] by server-2.bemta-4.messagelabs.com id
	F7/29-25135-E7E1FCF4; Wed, 06 Jun 2012 09:10:22 +0000
X-Env-Sender: Simon.Rowe@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338973817!13747288!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30408 invoked from network); 6 Jun 2012 09:10:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:10:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197696161"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 05:10:16 -0400
Received: from drall.uk.xensource.com (10.80.227.107) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 05:10:16 -0400
MIME-Version: 1.0
X-Mercurial-Node: ae3a05009962e4ad2195d7096f247d88ca362c34
Message-ID: <ae3a05009962e4ad2195.1338973650@drall.uk.xensource.com>
In-Reply-To: <patchbomb.1338973648@drall.uk.xensource.com>
References: <patchbomb.1338973648@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 10:07:30 +0100
From: Simon Rowe <simon.rowe@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: simon.rowe@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V3] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xs_watch() creates a thread to wake watchers using default attributes. The
stacksize can be quite large (8 MB on Linux), applications that link against
xenstore end up having a larger memory footprint than necessary.

Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>

---
Changed since v1:
  * remove test for _POSIX_THREAD_ATTR_STACKSIZE
  * use define for constant

diff -r 711a707dc776 -r ae3a05009962 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c	Wed Jun 06 10:04:15 2012 +0100
+++ b/tools/xenstore/xs.c	Wed Jun 06 10:06:44 2012 +0100
@@ -702,21 +702,36 @@ bool xs_watch(struct xs_handle *h, const
 	struct iovec iov[2];
 
 #ifdef USE_PTHREAD
+#define READ_THREAD_STACKSIZE (16 * 1024)
+
 	/* We dynamically create a reader thread on demand. */
 	mutex_lock(&h->request_mutex);
 	if (!h->read_thr_exists) {
 		sigset_t set, old_set;
+		pthread_attr_t attr;
+
+		if (pthread_attr_init(&attr) != 0) {
+			mutex_unlock(&h->request_mutex);
+			return false;
+		}
+		if (pthread_attr_setstacksize(&attr, READ_THREAD_STACKSIZE) != 0) {
+			pthread_attr_destroy(&attr);
+			mutex_unlock(&h->request_mutex);
+			return false;
+		}
 
 		sigfillset(&set);
 		pthread_sigmask(SIG_SETMASK, &set, &old_set);
 
-		if (pthread_create(&h->read_thr, NULL, read_thread, h) != 0) {
+		if (pthread_create(&h->read_thr, &attr, read_thread, h) != 0) {
 			pthread_sigmask(SIG_SETMASK, &old_set, NULL);
+			pthread_attr_destroy(&attr);
 			mutex_unlock(&h->request_mutex);
 			return false;
 		}
 		h->read_thr_exists = 1;
 		pthread_sigmask(SIG_SETMASK, &old_set, NULL);
+		pthread_attr_destroy(&attr);
 	}
 	mutex_unlock(&h->request_mutex);
 #endif

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:10:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:10: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 1ScCG0-0000ur-SF; Wed, 06 Jun 2012 09:10:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Simon.Rowe@eu.citrix.com>) id 1ScCFy-0000t0-V4
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:10:23 +0000
Received: from [85.158.143.35:21465] by server-2.bemta-4.messagelabs.com id
	F7/29-25135-E7E1FCF4; Wed, 06 Jun 2012 09:10:22 +0000
X-Env-Sender: Simon.Rowe@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338973817!13747288!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30408 invoked from network); 6 Jun 2012 09:10:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:10:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197696161"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 05:10:16 -0400
Received: from drall.uk.xensource.com (10.80.227.107) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 05:10:16 -0400
MIME-Version: 1.0
X-Mercurial-Node: ae3a05009962e4ad2195d7096f247d88ca362c34
Message-ID: <ae3a05009962e4ad2195.1338973650@drall.uk.xensource.com>
In-Reply-To: <patchbomb.1338973648@drall.uk.xensource.com>
References: <patchbomb.1338973648@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 10:07:30 +0100
From: Simon Rowe <simon.rowe@eu.citrix.com>
To: xen-devel@lists.xen.org
Cc: simon.rowe@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V3] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xs_watch() creates a thread to wake watchers using default attributes. The
stacksize can be quite large (8 MB on Linux), applications that link against
xenstore end up having a larger memory footprint than necessary.

Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>

---
Changed since v1:
  * remove test for _POSIX_THREAD_ATTR_STACKSIZE
  * use define for constant

diff -r 711a707dc776 -r ae3a05009962 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c	Wed Jun 06 10:04:15 2012 +0100
+++ b/tools/xenstore/xs.c	Wed Jun 06 10:06:44 2012 +0100
@@ -702,21 +702,36 @@ bool xs_watch(struct xs_handle *h, const
 	struct iovec iov[2];
 
 #ifdef USE_PTHREAD
+#define READ_THREAD_STACKSIZE (16 * 1024)
+
 	/* We dynamically create a reader thread on demand. */
 	mutex_lock(&h->request_mutex);
 	if (!h->read_thr_exists) {
 		sigset_t set, old_set;
+		pthread_attr_t attr;
+
+		if (pthread_attr_init(&attr) != 0) {
+			mutex_unlock(&h->request_mutex);
+			return false;
+		}
+		if (pthread_attr_setstacksize(&attr, READ_THREAD_STACKSIZE) != 0) {
+			pthread_attr_destroy(&attr);
+			mutex_unlock(&h->request_mutex);
+			return false;
+		}
 
 		sigfillset(&set);
 		pthread_sigmask(SIG_SETMASK, &set, &old_set);
 
-		if (pthread_create(&h->read_thr, NULL, read_thread, h) != 0) {
+		if (pthread_create(&h->read_thr, &attr, read_thread, h) != 0) {
 			pthread_sigmask(SIG_SETMASK, &old_set, NULL);
+			pthread_attr_destroy(&attr);
 			mutex_unlock(&h->request_mutex);
 			return false;
 		}
 		h->read_thr_exists = 1;
 		pthread_sigmask(SIG_SETMASK, &old_set, NULL);
+		pthread_attr_destroy(&attr);
 	}
 	mutex_unlock(&h->request_mutex);
 #endif

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:14:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCJQ-0001dc-J7; Wed, 06 Jun 2012 09:13:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScCJP-0001dI-A1
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:13:55 +0000
Received: from [85.158.138.51:29965] by server-3.bemta-3.messagelabs.com id
	E7/11-25608-25F1FCF4; Wed, 06 Jun 2012 09:13:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338974026!22117338!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDQ2NjAgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5862 invoked from network); 6 Jun 2012 09:13:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12852999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:13:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:13:46 +0100
Message-ID: <1338974024.32319.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Paton <paton@cs.wisc.edu>
Date: Wed, 6 Jun 2012 10:13:44 +0100
In-Reply-To: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote:
> Hi,
> 
> Apologies if this is not the appropriate list, but I thought I would 
> have better luck here than on xen-users.
> 
> I'm a CS graduate student hacking on the xen-blkback driver and would 
> like to be able to debug it using gdb over serial. I have spent a great 
> deal of time on this with no success (more details can be found at 
> http://bit.ly/KMEF6o (Stack Overflow)). 
> 
> It eventually occurred to me that it might not even be possible to do 
> what I'm trying to do if Xen intercepts interrupts from the serial port 
> and tries to direct them to dom0 through some unexpected channel. Then, 
> after I've done `echo g > /proc/sysrq_trigger`, the kernel debugger 
> might not see the interrupt. Can anyone confirm or disconfirm this? 

It's not something I've ever tried but I expect that if you avoid
console=com1 (or com*) on your hypervisor command line then the com port
should be available for dom0 just like on native.

Alternatively you could perhaps separate the two by using com1 for Xen
and com2/ttyS1 for dom0/kdb etc.

I've no idea if kdb would be expected to work over hvc*. I suspect you'd
be treading fresh ground with that one...

I'd also start by taking virtual box out of the equation on the host
side. Start by using a MacOS terminal emulator and checking that you can
see the dom0 console messages and login via a getty running on ttyS0
before trying to hook up gdb.

> What is the usual procedure for debugging the Dom0 kernel?

Printk ;-)

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:14:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCJQ-0001dc-J7; Wed, 06 Jun 2012 09:13:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScCJP-0001dI-A1
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:13:55 +0000
Received: from [85.158.138.51:29965] by server-3.bemta-3.messagelabs.com id
	E7/11-25608-25F1FCF4; Wed, 06 Jun 2012 09:13:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338974026!22117338!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwODk=\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDQ2NjAgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5862 invoked from network); 6 Jun 2012 09:13:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12852999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:13:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:13:46 +0100
Message-ID: <1338974024.32319.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Paton <paton@cs.wisc.edu>
Date: Wed, 6 Jun 2012 10:13:44 +0100
In-Reply-To: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote:
> Hi,
> 
> Apologies if this is not the appropriate list, but I thought I would 
> have better luck here than on xen-users.
> 
> I'm a CS graduate student hacking on the xen-blkback driver and would 
> like to be able to debug it using gdb over serial. I have spent a great 
> deal of time on this with no success (more details can be found at 
> http://bit.ly/KMEF6o (Stack Overflow)). 
> 
> It eventually occurred to me that it might not even be possible to do 
> what I'm trying to do if Xen intercepts interrupts from the serial port 
> and tries to direct them to dom0 through some unexpected channel. Then, 
> after I've done `echo g > /proc/sysrq_trigger`, the kernel debugger 
> might not see the interrupt. Can anyone confirm or disconfirm this? 

It's not something I've ever tried but I expect that if you avoid
console=com1 (or com*) on your hypervisor command line then the com port
should be available for dom0 just like on native.

Alternatively you could perhaps separate the two by using com1 for Xen
and com2/ttyS1 for dom0/kdb etc.

I've no idea if kdb would be expected to work over hvc*. I suspect you'd
be treading fresh ground with that one...

I'd also start by taking virtual box out of the equation on the host
side. Start by using a MacOS terminal emulator and checking that you can
see the dom0 console messages and login via a getty running on ttyS0
before trying to hook up gdb.

> What is the usual procedure for debugging the Dom0 kernel?

Printk ;-)

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:21:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCQL-0001yY-EO; Wed, 06 Jun 2012 09:21:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1ScCQJ-0001yS-Ox
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:21:04 +0000
Received: from [193.109.254.147:57709] by server-2.bemta-14.messagelabs.com id
	56/34-27740-FF02FCF4; Wed, 06 Jun 2012 09:21:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1338974460!13098606!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.5 required=7.0 tests=HOT_NASTY,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7282 invoked from network); 6 Jun 2012 09:21:01 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:21:01 -0000
Received: by qcsp15 with SMTP id p15so4124528qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 02:20:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=59O5P7Dlt8TiAzzoUm3Jx5twodEyUmjoBzFgQ3TVSrc=;
	b=VIKaQDIkmKWbIXS92NerupNz0OHjvHhxGDzI8hyrVeQoQXYz4gIynrZD/3pQ0n+Pbv
	0jyMHqswygeQzOEWO2nTFIC67cAZP9ps9AfcO8Uo+p+h43nMTe/BwW3zpER2yfenVXm0
	4SPwTIdMX7bQ5tPnBOAVezcZokUse7JXYX9Yhnkhfa7HKRrvwsbbaq9wdMgpl+zGwR3+
	LQEhAOFcoyV+QPVQASIzxGoYrZQWnWxFgoCyCwH8IRrbz0uQ+cfJIK4MzUvCoV1VmVZG
	QwutIsyr8IxqA3VBgUje+QnCgLYXTLEtp0hS27UbSOoJK3fNiPx8ehjfcYwfgSBrOtR1
	ir3g==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr20870925qae.26.1338974459586;
	Wed, 06 Jun 2012 02:20:59 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 02:20:59 -0700 (PDT)
In-Reply-To: <3da83ff08d6b6431c104.1338572903@probook.site>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
Date: Wed, 6 Jun 2012 10:20:59 +0100
X-Google-Sender-Auth: MFxfMv9lzla34vDMfUDAyN5kGnM
Message-ID: <CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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="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, Jun 1, 2012 at 6:48 PM, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338572607 -7200
> # Node ID 3da83ff08d6b6431c104a431d6617ccb5977643b
> # Parent =A0fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
> xl.cfg: document the cpuid=3D option
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r fde8ad0252ee -r 3da83ff08d6b docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -969,9 +969,47 @@ XXX
>
> =A0XXX
>
> -=3Ditem B<cpuid=3DXXX>
> +=3Ditem B<cpuid=3D"STRING"> or B<cpuid=3D[ "XEND_STRING", "XEND_STRING" =
]>
>
> -XXX
> +Configure guest CPUID responses.

I think I would say, "Configure the value returned when a guest
executes CPUID instruction".  ("Response" is a technical term that
doesn't really seem to fit here, I think.)

> Two config versions of config syntax are
> +recognized: xend and libxl.

It's not clear from this text -- will libxl understand the xend format?

Other than that, the explanation and the example look really good.
(NB, I haven't reviewed for accuracy.)

 -George

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:21:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCQL-0001yY-EO; Wed, 06 Jun 2012 09:21:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1ScCQJ-0001yS-Ox
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:21:04 +0000
Received: from [193.109.254.147:57709] by server-2.bemta-14.messagelabs.com id
	56/34-27740-FF02FCF4; Wed, 06 Jun 2012 09:21:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1338974460!13098606!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.5 required=7.0 tests=HOT_NASTY,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7282 invoked from network); 6 Jun 2012 09:21:01 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:21:01 -0000
Received: by qcsp15 with SMTP id p15so4124528qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 02:20:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=59O5P7Dlt8TiAzzoUm3Jx5twodEyUmjoBzFgQ3TVSrc=;
	b=VIKaQDIkmKWbIXS92NerupNz0OHjvHhxGDzI8hyrVeQoQXYz4gIynrZD/3pQ0n+Pbv
	0jyMHqswygeQzOEWO2nTFIC67cAZP9ps9AfcO8Uo+p+h43nMTe/BwW3zpER2yfenVXm0
	4SPwTIdMX7bQ5tPnBOAVezcZokUse7JXYX9Yhnkhfa7HKRrvwsbbaq9wdMgpl+zGwR3+
	LQEhAOFcoyV+QPVQASIzxGoYrZQWnWxFgoCyCwH8IRrbz0uQ+cfJIK4MzUvCoV1VmVZG
	QwutIsyr8IxqA3VBgUje+QnCgLYXTLEtp0hS27UbSOoJK3fNiPx8ehjfcYwfgSBrOtR1
	ir3g==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr20870925qae.26.1338974459586;
	Wed, 06 Jun 2012 02:20:59 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 02:20:59 -0700 (PDT)
In-Reply-To: <3da83ff08d6b6431c104.1338572903@probook.site>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
Date: Wed, 6 Jun 2012 10:20:59 +0100
X-Google-Sender-Auth: MFxfMv9lzla34vDMfUDAyN5kGnM
Message-ID: <CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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="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, Jun 1, 2012 at 6:48 PM, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338572607 -7200
> # Node ID 3da83ff08d6b6431c104a431d6617ccb5977643b
> # Parent =A0fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
> xl.cfg: document the cpuid=3D option
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r fde8ad0252ee -r 3da83ff08d6b docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -969,9 +969,47 @@ XXX
>
> =A0XXX
>
> -=3Ditem B<cpuid=3DXXX>
> +=3Ditem B<cpuid=3D"STRING"> or B<cpuid=3D[ "XEND_STRING", "XEND_STRING" =
]>
>
> -XXX
> +Configure guest CPUID responses.

I think I would say, "Configure the value returned when a guest
executes CPUID instruction".  ("Response" is a technical term that
doesn't really seem to fit here, I think.)

> Two config versions of config syntax are
> +recognized: xend and libxl.

It's not clear from this text -- will libxl understand the xend format?

Other than that, the explanation and the example look really good.
(NB, I haven't reviewed for accuracy.)

 -George

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:22:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScCRL-00022i-Sc; Wed, 06 Jun 2012 09:22:07 +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 1ScCRK-00022X-JN
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:22:06 +0000
Received: from [85.158.138.51:55760] by server-5.bemta-3.messagelabs.com id
	1C/1B-03598-D312FCF4; Wed, 06 Jun 2012 09:22:05 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338974525!28148483!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26539 invoked from network); 6 Jun 2012 09:22:05 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:22:05 -0000
Received: by wibhj6 with SMTP id hj6so4043520wib.14
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 02:22:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=GGzLWxJ3vC5KvUgF6e80k83aYX1RO5rOHmWg0PkSV4k=;
	b=fgse6+8qFmFRVKddagq2o0G+A0Ui0R1AADeq7YHjkeQ1eCmJOWt7dyG5al5UNTQz4J
	CQIiW+r0EcrI8AbysLk4J062rmCfK8y40cTO9YZWmxd4kRA7Uh1reK/ymtBclTHzHJja
	Lh0N3mmuK4WFzlzm3GM3kGr7C0SBNhe7bbmBCl9OcQgKPvFdbCopwYIgpSRyGD8JEYTg
	xtdV0tX2HQ2UwH17mar1UvcgFpS5WZ8jyHGIYlV2t9vVpihd8dUY6HBUZJ6jIfFJhhky
	4+UKeQLs09EpiLupMi2aUR2fT3DI/9d0JVQQ3S1aVyFzcdJsWN+vWF/4htezXO9M2vPr
	vFNA==
Received: by 10.216.207.85 with SMTP id m63mr5027530weo.183.1338974525107;
	Wed, 06 Jun 2012 02:22:05 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id dg2sm2505957wib.4.2012.06.06.02.22.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 02:22:03 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f893681e07ae2bb0e52e3aa38fb70cc9f163468a
Message-Id: <f893681e07ae2bb0e52e.1338974521@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 06 Jun 2012 11:22:01 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: convert malloc() to libxl__zalloc(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

And ditch the error handling in libxl_get_cpu_topology()

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

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3116,12 +3116,7 @@ libxl_cputopology *libxl_get_cpu_topolog
     if (tinfo.max_cpu_index < max_cpus - 1)
         max_cpus = tinfo.max_cpu_index + 1;
 
-    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
-    if (ret == NULL) {
-        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
-                            "Unable to allocate return value");
-        goto fail;
-    }
+    ret = libxl__zalloc(NULL, sizeof(libxl_cputopology) * max_cpus);
 
     for (i = 0; i < max_cpus; i++) {
 #define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:22:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScCRL-00022i-Sc; Wed, 06 Jun 2012 09:22:07 +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 1ScCRK-00022X-JN
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:22:06 +0000
Received: from [85.158.138.51:55760] by server-5.bemta-3.messagelabs.com id
	1C/1B-03598-D312FCF4; Wed, 06 Jun 2012 09:22:05 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1338974525!28148483!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26539 invoked from network); 6 Jun 2012 09:22:05 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:22:05 -0000
Received: by wibhj6 with SMTP id hj6so4043520wib.14
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 02:22:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=GGzLWxJ3vC5KvUgF6e80k83aYX1RO5rOHmWg0PkSV4k=;
	b=fgse6+8qFmFRVKddagq2o0G+A0Ui0R1AADeq7YHjkeQ1eCmJOWt7dyG5al5UNTQz4J
	CQIiW+r0EcrI8AbysLk4J062rmCfK8y40cTO9YZWmxd4kRA7Uh1reK/ymtBclTHzHJja
	Lh0N3mmuK4WFzlzm3GM3kGr7C0SBNhe7bbmBCl9OcQgKPvFdbCopwYIgpSRyGD8JEYTg
	xtdV0tX2HQ2UwH17mar1UvcgFpS5WZ8jyHGIYlV2t9vVpihd8dUY6HBUZJ6jIfFJhhky
	4+UKeQLs09EpiLupMi2aUR2fT3DI/9d0JVQQ3S1aVyFzcdJsWN+vWF/4htezXO9M2vPr
	vFNA==
Received: by 10.216.207.85 with SMTP id m63mr5027530weo.183.1338974525107;
	Wed, 06 Jun 2012 02:22:05 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id dg2sm2505957wib.4.2012.06.06.02.22.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 02:22:03 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f893681e07ae2bb0e52e3aa38fb70cc9f163468a
Message-Id: <f893681e07ae2bb0e52e.1338974521@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 06 Jun 2012 11:22:01 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: convert malloc() to libxl__zalloc(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

And ditch the error handling in libxl_get_cpu_topology()

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

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3116,12 +3116,7 @@ libxl_cputopology *libxl_get_cpu_topolog
     if (tinfo.max_cpu_index < max_cpus - 1)
         max_cpus = tinfo.max_cpu_index + 1;
 
-    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
-    if (ret == NULL) {
-        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
-                            "Unable to allocate return value");
-        goto fail;
-    }
+    ret = libxl__zalloc(NULL, sizeof(libxl_cputopology) * max_cpus);
 
     for (i = 0; i < max_cpus; i++) {
 #define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCWR-0002K4-Lk; Wed, 06 Jun 2012 09:27: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 1ScCWP-0002Ju-Hr
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:27:21 +0000
Received: from [193.109.254.147:51601] by server-8.bemta-14.messagelabs.com id
	44/56-27132-8722FCF4; Wed, 06 Jun 2012 09:27:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338974840!6198570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5707 invoked from network); 6 Jun 2012 09:27:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:27:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12853385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:27:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:27:20 +0100
Message-ID: <1338974838.32319.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 10:27:18 +0100
In-Reply-To: <4FCDE2A902000078000883C3@nat28.tlf.novell.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anil Rao <anil.rao@ericsson.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 Tue, 2012-06-05 at 09:42 +0100, Jan Beulich wrote:
> >>> On 04.06.12 at 21:00, Anil Rao <anil.rao@ericsson.com> wrote:
> > A) Does Xen support case 1 (hotplugging a PCI device to a running VM that 
> > was powered-on before the device was added to
> >     the host)?
> 
> As far as I'm aware, only hotplug from the perspective of the guest
> is really supported/tested.
> 
> But the issue here really seems less Xen related, but more towards
> libpci behavior (as according to qemu this is where the device isn't
> known). As that's a component Xen/qemu-dm simply builds upon,
> failure there (e.g. lack of hotplug awareness) would surface as a
> Xen misbehavior. Quickly going through the list of provided symbols
> of libpci.so doesn't show anything that looks hotplug related (e.g.
> some sort of notification registration). But of course it's possible
> that I'm overlooking something here, and that in fact qemu-dm's
> interaction with libpci is simply incomplete.

Your theory tallies with what I remember from looking at PCI hotplug
using a stub qemu -- IIRC libpci scans the bus at start of day and has
no capability to refresh the list of known devices after that. This
means that on host hotplug (actually mini-os hotplug in the case I was
looking at) the device doesn't become known to qemu.

Anyway the upshot is that AFAIK even for non-stub qemu either (or both)
qemu and libpci need to be taught about host PCI hotplug somehow.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCWR-0002K4-Lk; Wed, 06 Jun 2012 09:27: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 1ScCWP-0002Ju-Hr
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:27:21 +0000
Received: from [193.109.254.147:51601] by server-8.bemta-14.messagelabs.com id
	44/56-27132-8722FCF4; Wed, 06 Jun 2012 09:27:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338974840!6198570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5707 invoked from network); 6 Jun 2012 09:27:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:27:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12853385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:27:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:27:20 +0100
Message-ID: <1338974838.32319.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 10:27:18 +0100
In-Reply-To: <4FCDE2A902000078000883C3@nat28.tlf.novell.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anil Rao <anil.rao@ericsson.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 Tue, 2012-06-05 at 09:42 +0100, Jan Beulich wrote:
> >>> On 04.06.12 at 21:00, Anil Rao <anil.rao@ericsson.com> wrote:
> > A) Does Xen support case 1 (hotplugging a PCI device to a running VM that 
> > was powered-on before the device was added to
> >     the host)?
> 
> As far as I'm aware, only hotplug from the perspective of the guest
> is really supported/tested.
> 
> But the issue here really seems less Xen related, but more towards
> libpci behavior (as according to qemu this is where the device isn't
> known). As that's a component Xen/qemu-dm simply builds upon,
> failure there (e.g. lack of hotplug awareness) would surface as a
> Xen misbehavior. Quickly going through the list of provided symbols
> of libpci.so doesn't show anything that looks hotplug related (e.g.
> some sort of notification registration). But of course it's possible
> that I'm overlooking something here, and that in fact qemu-dm's
> interaction with libpci is simply incomplete.

Your theory tallies with what I remember from looking at PCI hotplug
using a stub qemu -- IIRC libpci scans the bus at start of day and has
no capability to refresh the list of known devices after that. This
means that on host hotplug (actually mini-os hotplug in the case I was
looking at) the device doesn't become known to qemu.

Anyway the upshot is that AFAIK even for non-stub qemu either (or both)
qemu and libpci need to be taught about host PCI hotplug somehow.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:33:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCcW-0002cv-7r; Wed, 06 Jun 2012 09:33: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 1ScCcU-0002co-Ta
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:33:39 +0000
Received: from [85.158.143.99:17563] by server-1.bemta-4.messagelabs.com id
	97/E4-10042-2F32FCF4; Wed, 06 Jun 2012 09:33:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338975217!26254359!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7371 invoked from network); 6 Jun 2012 09:33:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:33:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12853415"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:28:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:28:36 +0100
Message-ID: <1338974915.32319.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 10:28:35 +0100
In-Reply-To: <4FCF2499020000780008865E@nat28.tlf.novell.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
	<DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
	<4FCF2499020000780008865E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anil Rao <anil.rao@ericsson.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 Wed, 2012-06-06 at 08:36 +0100, Jan Beulich wrote:
> >>> On 05.06.12 at 20:01, Anil Rao <anil.rao@ericsson.com> wrote:
> > After encountering this problem, I was afraid that only VM-level hotplug is 
> > supported by Xen (and not true hotplug at the host-level). Can someone kindly 
> > confirm that this is the case? Our current effort depends on host-level 
> > hotplug of a PCI device that can (later) be assigned (hotplugged) to a 
> > running VM, so a definitive answer will help us to avoid going down the wrong 
> > path.
> 
> That is not a proper statement - host side holtplug is still supported,
> just that currently it may need to happen before the target VM gets
> created. Overcoming limitations like this is certainly desirable, but will
> obviously require someone to actually invest work - the question
> would hence be whether, given that you're interested in this feature
> and posted on xen-devel, you wouldn't also want to look into
> addressing this (provided my brief analysis of the situation is correct
> at all).

Yes, patches to make this work would be gratefully received.

As an aside, I wonder if upstream qemu does anything better here -- that
would probably be the right place to look at adding this new feature in
any case.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:33:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCcW-0002cv-7r; Wed, 06 Jun 2012 09:33: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 1ScCcU-0002co-Ta
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:33:39 +0000
Received: from [85.158.143.99:17563] by server-1.bemta-4.messagelabs.com id
	97/E4-10042-2F32FCF4; Wed, 06 Jun 2012 09:33:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1338975217!26254359!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7371 invoked from network); 6 Jun 2012 09:33:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:33:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12853415"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:28:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:28:36 +0100
Message-ID: <1338974915.32319.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 10:28:35 +0100
In-Reply-To: <4FCF2499020000780008865E@nat28.tlf.novell.com>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
	<DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
	<4FCF2499020000780008865E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anil Rao <anil.rao@ericsson.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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 Wed, 2012-06-06 at 08:36 +0100, Jan Beulich wrote:
> >>> On 05.06.12 at 20:01, Anil Rao <anil.rao@ericsson.com> wrote:
> > After encountering this problem, I was afraid that only VM-level hotplug is 
> > supported by Xen (and not true hotplug at the host-level). Can someone kindly 
> > confirm that this is the case? Our current effort depends on host-level 
> > hotplug of a PCI device that can (later) be assigned (hotplugged) to a 
> > running VM, so a definitive answer will help us to avoid going down the wrong 
> > path.
> 
> That is not a proper statement - host side holtplug is still supported,
> just that currently it may need to happen before the target VM gets
> created. Overcoming limitations like this is certainly desirable, but will
> obviously require someone to actually invest work - the question
> would hence be whether, given that you're interested in this feature
> and posted on xen-devel, you wouldn't also want to look into
> addressing this (provided my brief analysis of the situation is correct
> at all).

Yes, patches to make this work would be gratefully received.

As an aside, I wonder if upstream qemu does anything better here -- that
would probably be the right place to look at adding this new feature in
any case.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:43: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 1ScClY-00034U-8s; Wed, 06 Jun 2012 09:43:00 +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 1ScClV-00034M-Uv
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:42:58 +0000
Received: from [193.109.254.147:22108] by server-8.bemta-14.messagelabs.com id
	10/F6-27132-1262FCF4; Wed, 06 Jun 2012 09:42:57 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1338975776!13103510!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21561 invoked from network); 6 Jun 2012 09:42:56 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-3.tower-27.messagelabs.com with SMTP;
	6 Jun 2012 09:42:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTP id
	D97761D99AD; Wed,  6 Jun 2012 11:42:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1338975776; bh=cRTwXA8/2M5cw30LPFD7QzOpjOS9oa7uTLVHUcrmsuU=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=gV7Ml2qIOhVc3qxPIg1ARh1ZfwKFiHo5N3ypzP
	TDmF6E0FtClcmPHdrZmWON1vCfEkbybIPAPpsgSZpsyL+weYzYAZ9+59CsvAjEZHvLY
	1mDzrU+FBT0yCCl4E4iizRmlEB7GZ0KFD+CVhpMN3PCpm4i9hghX+gJ4xem/TboitY=
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
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 1jcpGssko7BB; Wed,  6 Jun 2012 11:42:55 +0200 (CEST)
Received: from liondog.tnic (p4FF1DE13.dip.t-dialin.net [79.241.222.19])
	(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
	346D61D996C; Wed,  6 Jun 2012 11:42:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1338975775; bh=cRTwXA8/2M5cw30LPFD7QzOpjOS9oa7uTLVHUcrmsuU=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=KC3ZPH2MzOIa0tk4nTB5+5mP6dDMErAEGHAnSp
	GOy2ftqS2f1jJo29ITt6jYMIU1PFEGclD5Au/TWBGlh89aTh+at+KvJ8pZVu1/qh49o
	ASX/ycibwVslWiiRxZUQvuMY1/Dk3PcMaaxf0qlXlr7iZAU/igbvgTYy/R7fVrY/GA=
Received: by liondog.tnic (Postfix, from userid 1000)
	id 581214B8E84; Wed,  6 Jun 2012 11:42:54 +0200 (CEST)
Date: Wed, 6 Jun 2012 11:42:54 +0200
From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@kernel.org>
Message-ID: <20120606094254.GA4990@liondog.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, mingo@elte.hu, tglx@linutronix.de
References: <20120530171754.GA5115@phenom.dumpdata.com>
	<20120530173247.GC15635@x1.osrc.amd.com>
	<4FC65D34.1060803@zytor.com>
	<20120530175150.GE15438@x1.osrc.amd.com>
	<4FC66037.6020506@zytor.com>
	<20120530181722.GF15438@x1.osrc.amd.com>
	<4FC664E1.9050504@zytor.com>
	<20120530223334.GB28417@andromeda.dapyr.net>
	<4FC6A897.6020005@zytor.com> <20120606092713.GB9495@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120606092713.GB9495@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, mingo@elte.hu,
	tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD
 Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 11:27:13AM +0200, Ingo Molnar wrote:
> 
> * H. Peter Anvin <hpa@zytor.com> wrote:
> 
> > On 05/30/2012 03:33 PM, Konrad Rzeszutek Wilk wrote:
> > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > index 75f33b2..e74df95 100644
> > > --- a/arch/x86/xen/enlighten.c
> > > +++ b/arch/x86/xen/enlighten.c
> > > @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
> > >  	.wbinvd = native_wbinvd,
> > >  
> > >  	.read_msr = native_read_msr_safe,
> > > +	.rdmsr_regs = native_rdmsr_safe_regs,
> > >  	.write_msr = xen_write_msr_safe,
> > > +	.wrmsr_regs = native_wrmsr_safe_regs,
> > > +
> > >  	.read_tsc = native_read_tsc,
> > >  	.read_pmc = native_read_pmc,
> > >  
> > 
> > Okay, tell me again:
> > 
> > why do we have these hooks again?  Can we please weed out 
> > paravirt methods that have no users?
> 
> ping?

I think we solved all that and hpa wanted to queue them up shortly:

http://marc.info/?l=linux-kernel&m=133856342618027&w=2

If it's easier, I can send you a pull request later.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:43: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 1ScClY-00034U-8s; Wed, 06 Jun 2012 09:43:00 +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 1ScClV-00034M-Uv
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:42:58 +0000
Received: from [193.109.254.147:22108] by server-8.bemta-14.messagelabs.com id
	10/F6-27132-1262FCF4; Wed, 06 Jun 2012 09:42:57 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1338975776!13103510!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=1.9 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21561 invoked from network); 6 Jun 2012 09:42:56 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-3.tower-27.messagelabs.com with SMTP;
	6 Jun 2012 09:42:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTP id
	D97761D99AD; Wed,  6 Jun 2012 11:42:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1338975776; bh=cRTwXA8/2M5cw30LPFD7QzOpjOS9oa7uTLVHUcrmsuU=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=gV7Ml2qIOhVc3qxPIg1ARh1ZfwKFiHo5N3ypzP
	TDmF6E0FtClcmPHdrZmWON1vCfEkbybIPAPpsgSZpsyL+weYzYAZ9+59CsvAjEZHvLY
	1mDzrU+FBT0yCCl4E4iizRmlEB7GZ0KFD+CVhpMN3PCpm4i9hghX+gJ4xem/TboitY=
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
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 1jcpGssko7BB; Wed,  6 Jun 2012 11:42:55 +0200 (CEST)
Received: from liondog.tnic (p4FF1DE13.dip.t-dialin.net [79.241.222.19])
	(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
	346D61D996C; Wed,  6 Jun 2012 11:42:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1338975775; bh=cRTwXA8/2M5cw30LPFD7QzOpjOS9oa7uTLVHUcrmsuU=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=KC3ZPH2MzOIa0tk4nTB5+5mP6dDMErAEGHAnSp
	GOy2ftqS2f1jJo29ITt6jYMIU1PFEGclD5Au/TWBGlh89aTh+at+KvJ8pZVu1/qh49o
	ASX/ycibwVslWiiRxZUQvuMY1/Dk3PcMaaxf0qlXlr7iZAU/igbvgTYy/R7fVrY/GA=
Received: by liondog.tnic (Postfix, from userid 1000)
	id 581214B8E84; Wed,  6 Jun 2012 11:42:54 +0200 (CEST)
Date: Wed, 6 Jun 2012 11:42:54 +0200
From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@kernel.org>
Message-ID: <20120606094254.GA4990@liondog.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, mingo@elte.hu, tglx@linutronix.de
References: <20120530171754.GA5115@phenom.dumpdata.com>
	<20120530173247.GC15635@x1.osrc.amd.com>
	<4FC65D34.1060803@zytor.com>
	<20120530175150.GE15438@x1.osrc.amd.com>
	<4FC66037.6020506@zytor.com>
	<20120530181722.GF15438@x1.osrc.amd.com>
	<4FC664E1.9050504@zytor.com>
	<20120530223334.GB28417@andromeda.dapyr.net>
	<4FC6A897.6020005@zytor.com> <20120606092713.GB9495@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120606092713.GB9495@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, mingo@elte.hu,
	tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD
 Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 11:27:13AM +0200, Ingo Molnar wrote:
> 
> * H. Peter Anvin <hpa@zytor.com> wrote:
> 
> > On 05/30/2012 03:33 PM, Konrad Rzeszutek Wilk wrote:
> > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > index 75f33b2..e74df95 100644
> > > --- a/arch/x86/xen/enlighten.c
> > > +++ b/arch/x86/xen/enlighten.c
> > > @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
> > >  	.wbinvd = native_wbinvd,
> > >  
> > >  	.read_msr = native_read_msr_safe,
> > > +	.rdmsr_regs = native_rdmsr_safe_regs,
> > >  	.write_msr = xen_write_msr_safe,
> > > +	.wrmsr_regs = native_wrmsr_safe_regs,
> > > +
> > >  	.read_tsc = native_read_tsc,
> > >  	.read_pmc = native_read_pmc,
> > >  
> > 
> > Okay, tell me again:
> > 
> > why do we have these hooks again?  Can we please weed out 
> > paravirt methods that have no users?
> 
> ping?

I think we solved all that and hpa wanted to queue them up shortly:

http://marc.info/?l=linux-kernel&m=133856342618027&w=2

If it's easier, I can send you a pull request later.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:43:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:43: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 1ScCmB-00037q-R2; Wed, 06 Jun 2012 09:43: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 1ScCmA-00037a-Ds
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:43:38 +0000
Received: from [85.158.143.99:32735] by server-1.bemta-4.messagelabs.com id
	9D/30-10042-9462FCF4; Wed, 06 Jun 2012 09:43:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1338975817!20337808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24687 invoked from network); 6 Jun 2012 09:43:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:43:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12853836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:43:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:43:36 +0100
Message-ID: <1338975815.32319.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Wed, 6 Jun 2012 10:43:35 +0100
In-Reply-To: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-05 at 07:07 +0100, Zeinab Alebouyeh wrote:
> Hi everyone,
> I'm working on a research project. I add a hypercall to xen. It works
> properly. 
> In my Hypercall function I have a label and I want the physical
> address of my label to pass to another function. How can I grab the
> physical address of the label?

AFAIK there is no way to do this in standard C.

xen-devel isn't really the best place to be asking C programming
questions. I suggest you either speak to your advisor/mentor or seek out
one of the C forums on the Internet.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:43:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:43: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 1ScCmB-00037q-R2; Wed, 06 Jun 2012 09:43: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 1ScCmA-00037a-Ds
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:43:38 +0000
Received: from [85.158.143.99:32735] by server-1.bemta-4.messagelabs.com id
	9D/30-10042-9462FCF4; Wed, 06 Jun 2012 09:43:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1338975817!20337808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24687 invoked from network); 6 Jun 2012 09:43:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:43:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12853836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:43:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:43:36 +0100
Message-ID: <1338975815.32319.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Wed, 6 Jun 2012 10:43:35 +0100
In-Reply-To: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-05 at 07:07 +0100, Zeinab Alebouyeh wrote:
> Hi everyone,
> I'm working on a research project. I add a hypercall to xen. It works
> properly. 
> In my Hypercall function I have a label and I want the physical
> address of my label to pass to another function. How can I grab the
> physical address of the label?

AFAIK there is no way to do this in standard C.

xen-devel isn't really the best place to be asking C programming
questions. I suggest you either speak to your advisor/mentor or seek out
one of the C forums on the Internet.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScCp7-0003Km-0s; Wed, 06 Jun 2012 09: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 1ScCp6-0003Ke-1a
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:46:40 +0000
Received: from [85.158.139.83:45375] by server-10.bemta-5.messagelabs.com id
	64/8E-23803-FF62FCF4; Wed, 06 Jun 2012 09:46:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1338975998!32542830!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9439 invoked from network); 6 Jun 2012 09:46: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; 6 Jun 2012 09:46:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 10:26:13 +0100
Message-Id: <4FCF3E5002000078000886D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 10:26:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FCF2F90020000780008868A@nat28.tlf.novell.com>
	<CBF4DB24.41FB1%keir@xen.org>
In-Reply-To: <CBF4DB24.41FB1%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jisoo Yang <jisooy@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:02, Keir Fraser <keir@xen.org> wrote:
> On 06/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Other than in __list_splice(), the first element's prev pointer doesn't
>> need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
>> the assignment (to formally match __list_splice()), simply assert that
>> this assignment is really unnecessary.
>>
>> Reported-by: Jisoo Yang <jisooy@gmail.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
>>      last = list->tail;
>>      at = head->next;
>>  
>> -    first->list.prev = page_to_pdx(head->next);
>> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
> 
> ASSERT(first->list.prev == PAGE_LIST_NULL); ?
> 
> It seems odd to have one assumption encoded as an ASSERTion, and one as a
> code comment... A second assertion makes the assumption explicit, and
> run-time checked in debug builds.

But the __list_splice() equivalent assignment would be

    first->list.prev = at->list.prev;

which is why I chose the assert expression that way, yet made
the comment clarify what the actual state is. If the comment
just repeated what the ASSERT() already says, I'd rather drop
the comment altogether.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScCp7-0003Km-0s; Wed, 06 Jun 2012 09: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 1ScCp6-0003Ke-1a
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:46:40 +0000
Received: from [85.158.139.83:45375] by server-10.bemta-5.messagelabs.com id
	64/8E-23803-FF62FCF4; Wed, 06 Jun 2012 09:46:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1338975998!32542830!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9439 invoked from network); 6 Jun 2012 09:46: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; 6 Jun 2012 09:46:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 10:26:13 +0100
Message-Id: <4FCF3E5002000078000886D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 10:26:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FCF2F90020000780008868A@nat28.tlf.novell.com>
	<CBF4DB24.41FB1%keir@xen.org>
In-Reply-To: <CBF4DB24.41FB1%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jisoo Yang <jisooy@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:02, Keir Fraser <keir@xen.org> wrote:
> On 06/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Other than in __list_splice(), the first element's prev pointer doesn't
>> need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
>> the assignment (to formally match __list_splice()), simply assert that
>> this assignment is really unnecessary.
>>
>> Reported-by: Jisoo Yang <jisooy@gmail.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
>>      last = list->tail;
>>      at = head->next;
>>  
>> -    first->list.prev = page_to_pdx(head->next);
>> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
> 
> ASSERT(first->list.prev == PAGE_LIST_NULL); ?
> 
> It seems odd to have one assumption encoded as an ASSERTion, and one as a
> code comment... A second assertion makes the assumption explicit, and
> run-time checked in debug builds.

But the __list_splice() equivalent assignment would be

    first->list.prev = at->list.prev;

which is why I chose the assert expression that way, yet made
the comment clarify what the actual state is. If the comment
just repeated what the ASSERT() already says, I'd rather drop
the comment altogether.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:49:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScCrp-0003V4-Lm; Wed, 06 Jun 2012 09:49:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sanosh@alpha.co.jp>) id 1ScCrl-0003Ut-KU
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:49:28 +0000
Received: from [85.158.139.83:28974] by server-9.bemta-5.messagelabs.com id
	58/8D-29678-4A72FCF4; Wed, 06 Jun 2012 09:49:24 +0000
X-Env-Sender: sanosh@alpha.co.jp
X-Msg-Ref: server-16.tower-182.messagelabs.com!1338976160!24879016!1
X-Originating-IP: [219.127.235.68]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6489 invoked from network); 6 Jun 2012 09:49:22 -0000
Received: from mgw1.alpha.co.jp (HELO mgw1.alpha.co.jp) (219.127.235.68)
	by server-16.tower-182.messagelabs.com with SMTP;
	6 Jun 2012 09:49:22 -0000
Received: from (unknown [10.133.235.68]) by SPS-0013.alpha.co.jp with smtp
	id 2194_37f5_159b31aa_afbd_11e1_8bc1_001517fbe004;
	Wed, 06 Jun 2012 18:50:46 +0900
Received: from ms4.alpha.co.jp (ms4.alpha.co.jp [10.108.1.42])
	by mgw1.alpha.co.jp (Postfix) with ESMTP id 7D66FA7C599
	for <xen-devel@lists.xen.org>; Wed,  6 Jun 2012 18:49:18 +0900 (JST)
Received: from (unknown [10.108.1.42]) by SPS-0013.alpha.co.jp with smtp
	id 2194_37ee_1525206e_afbd_11e1_8bc1_001517fbe004;
	Wed, 06 Jun 2012 18:50:43 +0900
Received: from [10.146.176.35] (unknown [10.146.176.35])
	by ms4.alpha.co.jp (Postfix) with ESMTP id 5A54A19F02F0
	for <xen-devel@lists.xen.org>; Wed,  6 Jun 2012 18:49:18 +0900 (JST)
Message-ID: <4FCF279E.3050306@alpha.co.jp>
Date: Wed, 06 Jun 2012 18:49:18 +0900
From: =?ISO-2022-JP?B?GyRCOjRMbhsoQiAbJEI9KEVNGyhC?= <sanosh@alpha.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:13.0) Gecko/20120604 Thunderbird/13.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Intel VGA-passthrough to Ubuntu12.04 64bit Dom-U
	doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
When Ubuntu12.04 64bit domU boot up, Intel VGA-passthrough doesn't work.
I used the command "xm create" to boot up Dom-U.
Windows7-64bit-SP1 works quite well with same configuration.
Boot log is as follows.

Dom-U dmesg:
[    1.421858] initcall rfcomm_init+0x0/0xf1 [rfcomm] returned 0 after
2192 usecs
[    1.423021] calling  i915_init+0x0/0x8d [i915] @ 387
[    1.423023] [drm:drm_pci_init],
[    1.423038] [drm:drm_get_pci_dev],
[    1.423157] xen: --> pirq=55 -> irq=24 (gsi=24)
[    1.423159] i915 0000:00:02.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
[    1.423224] i915 0000:00:02.0: setting latency timer to 64
[    1.423315] [drm:drm_get_minor],
[    1.423411] initcall alsa_timer_init+0x0/0x1000 [snd_timer] returned
0 after 1559 usecs
[    1.423528] [drm:drm_get_minor], new minor assigned 64
[    1.423529] [drm:drm_get_minor],
[    1.423620] [drm:drm_get_minor], new minor assigned 0
[    1.474532] [drm:intel_opregion_setup], graphic opregion physical
addr: 0xfeff5018
[    1.474545] resource map sanity check conflict: 0xfeff5018 0xfeff7017
0xfeff7000 0xffffffff reserved
[    1.474547] ------------[ cut here ]------------
[    1.474551] WARNING: at
/build/buildd/linux-3.2.0/arch/x86/mm/ioremap.c:171
__ioremap_caller+0x382/0x390()
[    1.474553] Hardware name: HVM domU
[    1.474554] Info: mapping multiple BARs. Your kernel is fine.
[    1.474555] Modules linked in: i915(+) snd_timer snd_seq_device
rfcomm drm_kms_helper psmouse snd serio_raw drm mac_hid bnep
i2c_algo_bit shpchp soundcore bluetooth video parport_pc ppdev
snd_page_alloc i2c_piix4 lp parport floppy
[    1.474568] Pid: 387, comm: modprobe Not tainted 3.2.0-23-generic
#36-Ubuntu
[    1.474570] Call Trace:
[    1.474574]  [<ffffffff8106712f>] warn_slowpath_common+0x7f/0xc0
[    1.474576]  [<ffffffff81067226>] warn_slowpath_fmt+0x46/0x50
[    1.474578]  [<ffffffff81041002>] __ioremap_caller+0x382/0x390
[    1.474592]  [<ffffffffa01876da>] ? intel_opregion_setup+0x7a/0x220
[i915]
[    1.474594]  [<ffffffff81041044>] ioremap_cache+0x14/0x20
[    1.474603]  [<ffffffffa01876da>] intel_opregion_setup+0x7a/0x220 [i915]
[    1.474611]  [<ffffffffa0149744>] i915_driver_load+0x1a4/0x720 [i915]
[    1.474618]  [<ffffffffa00bffb9>] drm_get_pci_dev+0x199/0x300 [drm]
[    1.474620]  [<ffffffff8103dbb9>] ? default_spin_lock_flags+0x9/0x10
[    1.474630]  [<ffffffffa018a2a7>] i915_pci_probe+0x1b/0x1d [i915]
[    1.474633]  [<ffffffff8133447c>] local_pci_probe+0x5c/0xd0
[    1.474635]  [<ffffffff81335d29>] __pci_device_probe+0xf9/0x100
[    1.474638]  [<ffffffff8130cd2a>] ? kobject_get+0x1a/0x30
[    1.474640]  [<ffffffff81335d6a>] pci_device_probe+0x3a/0x60
[    1.474643]  [<ffffffff813f4eb8>] really_probe+0x68/0x190
[    1.474645]  [<ffffffff813f5145>] driver_probe_device+0x45/0x70
[    1.474646]  [<ffffffff813f521b>] __driver_attach+0xab/0xb0
[    1.474648]  [<ffffffff813f5170>] ? driver_probe_device+0x70/0x70
[    1.474650]  [<ffffffff813f5170>] ? driver_probe_device+0x70/0x70
[    1.474651]  [<ffffffff813f3fac>] bus_for_each_dev+0x5c/0x90
[    1.474653]  [<ffffffff813f4c7e>] driver_attach+0x1e/0x20
[    1.474655]  [<ffffffff813f48d0>] bus_add_driver+0x1a0/0x270
[    1.474657]  [<ffffffff813f5786>] driver_register+0x76/0x140
[    1.474659]  [<ffffffff81335a06>] __pci_register_driver+0x56/0xd0
[    1.474664]  [<ffffffffa00c023a>] drm_pci_init+0x11a/0x130 [drm]
[    1.474667]  [<ffffffff8100a669>] ? xen_clocksource_get_cycles+0x9/0x10
[    1.474669]  [<ffffffffa01b9000>] ? 0xffffffffa01b8fff
[    1.474675]  [<ffffffffa01b908b>] i915_init+0x8b/0x8d [i915]
[    1.474678]  [<ffffffff8100212c>] do_one_initcall+0x12c/0x180
[    1.474681]  [<ffffffff810a886e>] sys_init_module+0xbe/0x230
[    1.474683]  [<ffffffff81664a82>] system_call_fastpath+0x16/0x1b
[    1.474685] ---[ end trace 7589c8eed3077f77 ]---

Hardware:
Dell Optiplex 990
Core i5 2500
Display connected via VGA

Software:
dom0 kernel : Linux 3.4.0 64bit
domU kernel : Linux 3.2.0-23-generic 64bit(Ubuntu12.04 LTS)
xen 4.2-unstable(Latest ChangeSet: Thu May 31 10:18:52 2012 +0200
25432:d7318231cfe3)

Dom-U configuration file:
#  -*- mode: python; -*-
kernel = "hvmloader"
builder='hvm'
name = "domU"
vcpus=1
device_model = 'qemu-dm'
serial='pty'
usb=1
usbdevice='tablet'
memory = 2048
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
disk = [ 'file:/etc/xen/ubuntu.img,hda,w' ]
vscsi = [ '2:0:0:0, host' ]
pci=[ '00:02.0', '00:1b.0', '00:1a.0', '00:1d.0' ]
gfx_passthru=1
vif = [ 'type=ioemu, bridge=xenbr0, model=e1000' ]
keymap='ja'


Thanks,
SANO


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:49:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScCrp-0003V4-Lm; Wed, 06 Jun 2012 09:49:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sanosh@alpha.co.jp>) id 1ScCrl-0003Ut-KU
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:49:28 +0000
Received: from [85.158.139.83:28974] by server-9.bemta-5.messagelabs.com id
	58/8D-29678-4A72FCF4; Wed, 06 Jun 2012 09:49:24 +0000
X-Env-Sender: sanosh@alpha.co.jp
X-Msg-Ref: server-16.tower-182.messagelabs.com!1338976160!24879016!1
X-Originating-IP: [219.127.235.68]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6489 invoked from network); 6 Jun 2012 09:49:22 -0000
Received: from mgw1.alpha.co.jp (HELO mgw1.alpha.co.jp) (219.127.235.68)
	by server-16.tower-182.messagelabs.com with SMTP;
	6 Jun 2012 09:49:22 -0000
Received: from (unknown [10.133.235.68]) by SPS-0013.alpha.co.jp with smtp
	id 2194_37f5_159b31aa_afbd_11e1_8bc1_001517fbe004;
	Wed, 06 Jun 2012 18:50:46 +0900
Received: from ms4.alpha.co.jp (ms4.alpha.co.jp [10.108.1.42])
	by mgw1.alpha.co.jp (Postfix) with ESMTP id 7D66FA7C599
	for <xen-devel@lists.xen.org>; Wed,  6 Jun 2012 18:49:18 +0900 (JST)
Received: from (unknown [10.108.1.42]) by SPS-0013.alpha.co.jp with smtp
	id 2194_37ee_1525206e_afbd_11e1_8bc1_001517fbe004;
	Wed, 06 Jun 2012 18:50:43 +0900
Received: from [10.146.176.35] (unknown [10.146.176.35])
	by ms4.alpha.co.jp (Postfix) with ESMTP id 5A54A19F02F0
	for <xen-devel@lists.xen.org>; Wed,  6 Jun 2012 18:49:18 +0900 (JST)
Message-ID: <4FCF279E.3050306@alpha.co.jp>
Date: Wed, 06 Jun 2012 18:49:18 +0900
From: =?ISO-2022-JP?B?GyRCOjRMbhsoQiAbJEI9KEVNGyhC?= <sanosh@alpha.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:13.0) Gecko/20120604 Thunderbird/13.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Intel VGA-passthrough to Ubuntu12.04 64bit Dom-U
	doesn't work
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
When Ubuntu12.04 64bit domU boot up, Intel VGA-passthrough doesn't work.
I used the command "xm create" to boot up Dom-U.
Windows7-64bit-SP1 works quite well with same configuration.
Boot log is as follows.

Dom-U dmesg:
[    1.421858] initcall rfcomm_init+0x0/0xf1 [rfcomm] returned 0 after
2192 usecs
[    1.423021] calling  i915_init+0x0/0x8d [i915] @ 387
[    1.423023] [drm:drm_pci_init],
[    1.423038] [drm:drm_get_pci_dev],
[    1.423157] xen: --> pirq=55 -> irq=24 (gsi=24)
[    1.423159] i915 0000:00:02.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
[    1.423224] i915 0000:00:02.0: setting latency timer to 64
[    1.423315] [drm:drm_get_minor],
[    1.423411] initcall alsa_timer_init+0x0/0x1000 [snd_timer] returned
0 after 1559 usecs
[    1.423528] [drm:drm_get_minor], new minor assigned 64
[    1.423529] [drm:drm_get_minor],
[    1.423620] [drm:drm_get_minor], new minor assigned 0
[    1.474532] [drm:intel_opregion_setup], graphic opregion physical
addr: 0xfeff5018
[    1.474545] resource map sanity check conflict: 0xfeff5018 0xfeff7017
0xfeff7000 0xffffffff reserved
[    1.474547] ------------[ cut here ]------------
[    1.474551] WARNING: at
/build/buildd/linux-3.2.0/arch/x86/mm/ioremap.c:171
__ioremap_caller+0x382/0x390()
[    1.474553] Hardware name: HVM domU
[    1.474554] Info: mapping multiple BARs. Your kernel is fine.
[    1.474555] Modules linked in: i915(+) snd_timer snd_seq_device
rfcomm drm_kms_helper psmouse snd serio_raw drm mac_hid bnep
i2c_algo_bit shpchp soundcore bluetooth video parport_pc ppdev
snd_page_alloc i2c_piix4 lp parport floppy
[    1.474568] Pid: 387, comm: modprobe Not tainted 3.2.0-23-generic
#36-Ubuntu
[    1.474570] Call Trace:
[    1.474574]  [<ffffffff8106712f>] warn_slowpath_common+0x7f/0xc0
[    1.474576]  [<ffffffff81067226>] warn_slowpath_fmt+0x46/0x50
[    1.474578]  [<ffffffff81041002>] __ioremap_caller+0x382/0x390
[    1.474592]  [<ffffffffa01876da>] ? intel_opregion_setup+0x7a/0x220
[i915]
[    1.474594]  [<ffffffff81041044>] ioremap_cache+0x14/0x20
[    1.474603]  [<ffffffffa01876da>] intel_opregion_setup+0x7a/0x220 [i915]
[    1.474611]  [<ffffffffa0149744>] i915_driver_load+0x1a4/0x720 [i915]
[    1.474618]  [<ffffffffa00bffb9>] drm_get_pci_dev+0x199/0x300 [drm]
[    1.474620]  [<ffffffff8103dbb9>] ? default_spin_lock_flags+0x9/0x10
[    1.474630]  [<ffffffffa018a2a7>] i915_pci_probe+0x1b/0x1d [i915]
[    1.474633]  [<ffffffff8133447c>] local_pci_probe+0x5c/0xd0
[    1.474635]  [<ffffffff81335d29>] __pci_device_probe+0xf9/0x100
[    1.474638]  [<ffffffff8130cd2a>] ? kobject_get+0x1a/0x30
[    1.474640]  [<ffffffff81335d6a>] pci_device_probe+0x3a/0x60
[    1.474643]  [<ffffffff813f4eb8>] really_probe+0x68/0x190
[    1.474645]  [<ffffffff813f5145>] driver_probe_device+0x45/0x70
[    1.474646]  [<ffffffff813f521b>] __driver_attach+0xab/0xb0
[    1.474648]  [<ffffffff813f5170>] ? driver_probe_device+0x70/0x70
[    1.474650]  [<ffffffff813f5170>] ? driver_probe_device+0x70/0x70
[    1.474651]  [<ffffffff813f3fac>] bus_for_each_dev+0x5c/0x90
[    1.474653]  [<ffffffff813f4c7e>] driver_attach+0x1e/0x20
[    1.474655]  [<ffffffff813f48d0>] bus_add_driver+0x1a0/0x270
[    1.474657]  [<ffffffff813f5786>] driver_register+0x76/0x140
[    1.474659]  [<ffffffff81335a06>] __pci_register_driver+0x56/0xd0
[    1.474664]  [<ffffffffa00c023a>] drm_pci_init+0x11a/0x130 [drm]
[    1.474667]  [<ffffffff8100a669>] ? xen_clocksource_get_cycles+0x9/0x10
[    1.474669]  [<ffffffffa01b9000>] ? 0xffffffffa01b8fff
[    1.474675]  [<ffffffffa01b908b>] i915_init+0x8b/0x8d [i915]
[    1.474678]  [<ffffffff8100212c>] do_one_initcall+0x12c/0x180
[    1.474681]  [<ffffffff810a886e>] sys_init_module+0xbe/0x230
[    1.474683]  [<ffffffff81664a82>] system_call_fastpath+0x16/0x1b
[    1.474685] ---[ end trace 7589c8eed3077f77 ]---

Hardware:
Dell Optiplex 990
Core i5 2500
Display connected via VGA

Software:
dom0 kernel : Linux 3.4.0 64bit
domU kernel : Linux 3.2.0-23-generic 64bit(Ubuntu12.04 LTS)
xen 4.2-unstable(Latest ChangeSet: Thu May 31 10:18:52 2012 +0200
25432:d7318231cfe3)

Dom-U configuration file:
#  -*- mode: python; -*-
kernel = "hvmloader"
builder='hvm'
name = "domU"
vcpus=1
device_model = 'qemu-dm'
serial='pty'
usb=1
usbdevice='tablet'
memory = 2048
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
disk = [ 'file:/etc/xen/ubuntu.img,hda,w' ]
vscsi = [ '2:0:0:0, host' ]
pci=[ '00:02.0', '00:1b.0', '00:1a.0', '00:1d.0' ]
gfx_passthru=1
vif = [ 'type=ioemu, bridge=xenbr0, model=e1000' ]
keymap='ja'


Thanks,
SANO


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:54:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCwP-0003fr-CS; Wed, 06 Jun 2012 09:54: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 1ScCwN-0003fg-J5
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:54:11 +0000
Received: from [85.158.143.99:21296] by server-3.bemta-4.messagelabs.com id
	6C/D6-29237-2C82FCF4; Wed, 06 Jun 2012 09:54:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1338976449!26258598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23036 invoked from network); 6 Jun 2012 09:54:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:54:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12854140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:54:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:54:09 +0100
Message-ID: <1338976448.32319.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 10:54:08 +0100
In-Reply-To: <4FC4A1A80200007800086845@nat28.tlf.novell.com>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<4FC4A1A80200007800086845@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-05-29 at 09:15 +0100, Jan Beulich wrote:
> >>> On 28.05.12 at 11:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, nice to have:
> 
> * Grant table patches posted at the end of last week (no feedback
> so far).

I think these went in in the interim so I'm going to go straight to DONE
and garbage collect it from the list before posting. I like those kinds
of TODO items ;-)

Ian.




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

From xen-devel-bounces@lists.xen.org Wed Jun 06 09:54:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 09: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 1ScCwP-0003fr-CS; Wed, 06 Jun 2012 09:54: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 1ScCwN-0003fg-J5
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 09:54:11 +0000
Received: from [85.158.143.99:21296] by server-3.bemta-4.messagelabs.com id
	6C/D6-29237-2C82FCF4; Wed, 06 Jun 2012 09:54:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1338976449!26258598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23036 invoked from network); 6 Jun 2012 09:54:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:54:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12854140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:54:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	10:54:09 +0100
Message-ID: <1338976448.32319.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 10:54:08 +0100
In-Reply-To: <4FC4A1A80200007800086845@nat28.tlf.novell.com>
References: <1338197010.14158.37.camel@zakaz.uk.xensource.com>
	<4FC4A1A80200007800086845@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-05-29 at 09:15 +0100, Jan Beulich wrote:
> >>> On 28.05.12 at 11:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, nice to have:
> 
> * Grant table patches posted at the end of last week (no feedback
> so far).

I think these went in in the interim so I'm going to go straight to DONE
and garbage collect it from the list before posting. I like those kinds
of TODO items ;-)

Ian.




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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:12:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDDz-00041E-2h; Wed, 06 Jun 2012 10:12:23 +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 1ScDDx-00040H-Ip
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:12:22 +0000
Received: from [193.109.254.147:31760] by server-8.bemta-14.messagelabs.com id
	AB/A8-27132-30D2FCF4; Wed, 06 Jun 2012 10:12:19 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1338977537!11173630!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_90_100,HTML_MESSAGE,
	RCVD_BY_IP,SUSPICIOUS_RECIPS
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21885 invoked from network); 6 Jun 2012 10:12:18 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:12:18 -0000
Received: by eaak12 with SMTP id k12so2010881eaa.32
	for <multiple recipients>; Wed, 06 Jun 2012 03:12:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=j1L6KX7djOOcneGy8ooWyiyXvSUfMTq3wiuC01nevjA=;
	b=GKbeiVIhjFIvtIOIEVEVvayLp42qoACskLE/WymZdrRalMrk7bG1IsytvdqMDtd8zA
	+sZIaTrz5tsje0MB+F7amWvHVsecG4RDaMVH3DKYk+/ReC4QOJ5UXSdTZMG8m1+S2m+0
	mki7mPySi3N+/W/K4Ji4GhzhGB5qKJABkzjsNaPVPfo9mAjkJLSCJSp1p8jcyp/Bfr/U
	CIflsOQF6cxxRqY1KwGP5HA38FsdxsHjXi3uuuNOimuSKC39SHPMTCnD8T1VCCrGccGe
	+Ibcu5RAEKMiKEi2DfIp88iAE9TcTDIZDwnVK4cmSKEqMY4fhNDTxCGkJMOvKnikdjX1
	Hz/w==
Received: by 10.14.100.205 with SMTP id z53mr8992919eef.39.1338977537286;
	Wed, 06 Jun 2012 03:12:17 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id t3sm4605616eeb.15.2012.06.06.03.12.14
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 03:12:16 -0700 (PDT)
Message-ID: <4FCF2CFD.7070606@xen.org>
Date: Wed, 06 Jun 2012 11:12:13 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-announce@lists.xen.org, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-users@lists.xen.org, xen-arm@lists.xen.org, xen-devel@lists.xen.org
Subject: [Xen-devel] Submit a Proposal to Speak at XenSummit North America
 2012 before the CFP Deadline, June 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-Type: multipart/mixed; boundary="===============3021442547764201407=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3021442547764201407==
Content-Type: multipart/alternative;
 boundary="------------010405050404010608000400"

This is a multi-part message in MIME format.
--------------010405050404010608000400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

XenSummit · August 27-28, 2012 · Sheraton San Diego · San Diego, CA, USA


    Submit a Proposal to Speak at XenSummit North America 2012 before
    the CFP Deadline, June 15th!


        XenSummit North America
        August 27-28, 2012 -- San Diego, CA

Xen.org invites developers, users, researchers, open source projects and 
businesses who are developing and/or using Xen to submit a proposal for 
XenSummit North America 2012.

*Submit a speaking proposal for XenSummit North America 2012 
<http://xen.org/polls/xensummit_na_2012.html>*


      Suggested topics for XenSummit America include:

  * Latest developments and features in Xen and related projects
  * Developments in upstream projects that impact the Xen community
  * Proposals on how to evolve Xen and related projects in future
  * Research using Xen and related projects
  * Proof of concepts and other interesting technologies related to Xen
  * Other topics related to developing and using Xen
  * Technologies and technology trends that will impact Xen development
    in future

  * User experiences and case studies with Xen or XCP
  * Benchmarks, case studies, improvement suggestions and other lessons
    learned
  * Innovative ways of using Xen and related projects
  * Open source projects and products that interface or build on top of
    Xen or related projects
  * Usage of Xen in server virtualization, cloud computing,
    clientvirtualization, mobile spaces, etc.

  *   Any other topics that you feel are relevant to developers, users,
    researchers and other members of the Xen community


We will have 30, 45 and 60 minute talking slots (including questions). 
Please choose the type of session when you submit a proposal.


      About XenSummit

XenSummit is the annual technical conference for Xen developers and 
users in North America. The conference provides a collaboration and 
education space for the Xen community and brings together a 
cross-section of the leading players in the Xen community, innovative 
and timely content and a wide variety of opportunities for attendee 
collaboration. This year, XenSummit is co-located with other industry 
events such as LinuxCon NA 
<https://events.linuxfoundation.org/events/linuxcon>, Linux Plumbers 
Conference <http://www.linuxplumbersconf.org/2012/>, Linux Kernel Summit 
<https://events.linuxfoundation.org/events/linux-kernel-summit>, 
CloudOpen <https://events.linuxfoundation.org/events/cloudopen> and 
others 
<https://events.linuxfoundation.org/events/cloudopen/co-located-events>, 
which will maximise opportunities for cross-community collaboration.

*Learn more about XenSummit* <http://xen.org/community/xensummit.html>
*Register for XenSummit* 
<http://www.regonline.com/Register/Checkin.aspx?EventId=1105690>

--------------010405050404010608000400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <meta http-equiv="Content-Type" content="text/html;
      charset=ISO-8859-1">
    <!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-GB</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:EnableOpenTypeKerning/>
   <w:DontFlipMirrorIndents/>
   <w:OverrideTableStyleHps/>
  </w:Compatibility>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="267">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style>
<![endif]-->
    <p class="MsoNormal" style="margin-bottom:12.0pt"><span
        style="mso-fareast-font-family:
        &quot;Times New Roman&quot;"><!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600"
 o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f"
 stroked="f">
 <v:stroke joinstyle="miter"/>
 <v:formulas>
  <v:f eqn="if lineDrawn pixelLineWidth 0"/>
  <v:f eqn="sum @0 1 0"/>
  <v:f eqn="sum 0 0 @1"/>
  <v:f eqn="prod @2 1 2"/>
  <v:f eqn="prod @3 21600 pixelWidth"/>
  <v:f eqn="prod @3 21600 pixelHeight"/>
  <v:f eqn="sum @0 0 1"/>
  <v:f eqn="prod @6 1 2"/>
  <v:f eqn="prod @7 21600 pixelWidth"/>
  <v:f eqn="sum @8 21600 0"/>
  <v:f eqn="prod @7 21600 pixelHeight"/>
  <v:f eqn="sum @10 21600 0"/>
 </v:formulas>
 <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
 <o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" alt="XenSummit &middot; August 27-28, 2012 &middot; Sheraton San Diego &middot; San&#13;&#10;      Diego, CA, USA"
 style='width:525pt;height:157.5pt'>
 <v:imagedata src="file:///C:\Users\LARSK~1.CIT\AppData\Local\Temp\msohtmlclip1\01\clip_image001.png"
  o:href="cid:part1.02000406.05050001@xen.org"/>
</v:shape><![endif]--><!--[if !vml]--><img
src="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_image002.png"
          alt="XenSummit &middot; August 27-28, 2012 &middot; Sheraton San Diego &middot;
          San
 Diego, CA, USA" v:shapes="_x0000_i1025" height="210"
          width="700"><!--[endif]--><o:p></o:p></span></p>
    <h2><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">Submit a Proposal
        to Speak at XenSummit North America 2012 before the CFP
        Deadline, June 15th!<o:p></o:p></span></h2>
    <h4><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">XenSummit North
        America<br>
        August 27-28, 2012 &#8211; San Diego, CA<o:p></o:p></span></h4>
    <p>Xen.org invites developers, users, researchers, open source
      projects and
      businesses who are developing and/or using Xen to submit a
      proposal for
      XenSummit North America 2012.<o:p></o:p></p>
    <p><b><span style="color:#3366FF"><a
            href="http://xen.org/polls/xensummit_na_2012.html">Submit a
            speaking proposal
            for XenSummit North America 2012</a></span></b><o:p></o:p></p>
    <h3><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">Suggested topics
        for XenSummit America include:<o:p></o:p></span></h3>
    <ul type="disc">
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Latest
          developments and features in Xen and related projects<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Developments
          in upstream projects that impact the Xen community<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Proposals
          on how to evolve Xen and related projects in future<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Research
          using Xen and related projects<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Proof
          of concepts and other interesting technologies related to Xen<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Other
          topics related to developing and using Xen<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Technologies
          and technology trends that will impact Xen development in
          future<o:p></o:p></span></li>
    </ul>
    <ul type="disc">
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">User
          experiences and case studies with Xen or XCP<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span style="">Benchmarks,
          case studies, improvement suggestions and other </span><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">lessons
          learned</span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Innovative
          ways of using Xen and related projects<br>
        </span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Open
          source projects and products that interface or build on top of
          Xen or related projects<o:p></o:p></span></li>
      <li class="MsoNormal" style=""><span style="">Usage of Xen in
          server virtualization, cloud computing, client</span><span
          style="font-size:12.0pt;line-height:115%;
          font-family:&quot;Times New
          Roman&quot;,&quot;serif&quot;;mso-fareast-font-family:&quot;Times
          New Roman&quot;;
mso-ansi-language:EN-GB;mso-fareast-language:EN-GB;mso-bidi-language:AR-SA">
          virtualization</span><span style="">, mobile spaces, etc. <br>
        </span></li>
    </ul>
    <span style=""></span>
    <ul type="disc">
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span style="">&nbsp;Any
          other topics that you feel are relevant to </span>developers,
        users, researchers and other members of the Xen community<br>
      </li>
    </ul>
    <p class="MsoNormal"><span
        style="mso-fareast-font-family:&quot;Times New Roman&quot;"><br>
        We
        will have 30, 45 and 60 minute talking slots (including
        questions). Please
        choose the type of session when you submit a proposal. <o:p></o:p></span></p>
    <h3><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">About XenSummit<o:p></o:p></span></h3>
    <p>XenSummit is the annual technical conference for Xen developers
      and users in
      North America. The conference provides a collaboration and
      education space for
      the Xen community and brings together a cross-section of the
      leading players in
      the Xen community, innovative and timely content and a wide
      variety of
      opportunities for attendee collaboration. This year, XenSummit is
      co-located
      with other industry events such as <a
        href="https://events.linuxfoundation.org/events/linuxcon">LinuxCon
        NA</a>, <a href="http://www.linuxplumbersconf.org/2012/">Linux
        Plumbers Conference</a>, <a
        href="https://events.linuxfoundation.org/events/linux-kernel-summit">Linux
Kernel
        Summit</a>, <a
        href="https://events.linuxfoundation.org/events/cloudopen">CloudOpen</a>
      and <a
href="https://events.linuxfoundation.org/events/cloudopen/co-located-events">others</a>,
      which will maximise opportunities for cross-community
      collaboration.<o:p></o:p></p>
    <span style="font-size:12.0pt;font-family:&quot;Times New
      Roman&quot;,&quot;serif&quot;;mso-fareast-font-family:
      &quot;Times New
      Roman&quot;;color:black;mso-ansi-language:EN-GB;mso-fareast-language:
      EN-GB;mso-bidi-language:AR-SA"><a
        href="http://xen.org/community/xensummit.html"><b>Learn
          more about XenSummit</b></a><br>
      <a
        href="http://www.regonline.com/Register/Checkin.aspx?EventId=1105690"><b>Register
for
          XenSummit</b></a></span>
    <meta name="ProgId" content="Word.Document">
    <meta name="Generator" content="Microsoft Word 14">
    <meta name="Originator" content="Microsoft Word 14">
    <link rel="File-List"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">
    <link rel="Edit-Time-Data"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_editdata.mso">
    <link rel="themeData"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx">
    <link rel="colorSchemeMapping"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">
    <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;}
h2
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 2 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	mso-outline-level:2;
	font-size:18.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
h3
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 3 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	mso-outline-level:3;
	font-size:13.5pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
h4
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 4 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	mso-outline-level:4;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	mso-themecolor:followedhyperlink;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-style-noshow:yes;
	mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 2";
	mso-ansi-font-size:18.0pt;
	mso-bidi-font-size:18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 3";
	mso-ansi-font-size:13.5pt;
	mso-bidi-font-size:13.5pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 4";
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
 /* List Definitions */
 @list l0
	{mso-list-id:506135686;
	mso-list-template-ids:2121573526;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:&#61623;;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1
	{mso-list-id:1640650674;
	mso-list-template-ids:398722712;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:&#61623;;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l1:level3
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level4
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level5
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level6
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level7
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level8
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level9
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
  </body>
</html>

--------------010405050404010608000400--


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

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

--===============3021442547764201407==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 10:12:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDDz-00041E-2h; Wed, 06 Jun 2012 10:12:23 +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 1ScDDx-00040H-Ip
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:12:22 +0000
Received: from [193.109.254.147:31760] by server-8.bemta-14.messagelabs.com id
	AB/A8-27132-30D2FCF4; Wed, 06 Jun 2012 10:12:19 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1338977537!11173630!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_90_100,HTML_MESSAGE,
	RCVD_BY_IP,SUSPICIOUS_RECIPS
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21885 invoked from network); 6 Jun 2012 10:12:18 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:12:18 -0000
Received: by eaak12 with SMTP id k12so2010881eaa.32
	for <multiple recipients>; Wed, 06 Jun 2012 03:12:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=j1L6KX7djOOcneGy8ooWyiyXvSUfMTq3wiuC01nevjA=;
	b=GKbeiVIhjFIvtIOIEVEVvayLp42qoACskLE/WymZdrRalMrk7bG1IsytvdqMDtd8zA
	+sZIaTrz5tsje0MB+F7amWvHVsecG4RDaMVH3DKYk+/ReC4QOJ5UXSdTZMG8m1+S2m+0
	mki7mPySi3N+/W/K4Ji4GhzhGB5qKJABkzjsNaPVPfo9mAjkJLSCJSp1p8jcyp/Bfr/U
	CIflsOQF6cxxRqY1KwGP5HA38FsdxsHjXi3uuuNOimuSKC39SHPMTCnD8T1VCCrGccGe
	+Ibcu5RAEKMiKEi2DfIp88iAE9TcTDIZDwnVK4cmSKEqMY4fhNDTxCGkJMOvKnikdjX1
	Hz/w==
Received: by 10.14.100.205 with SMTP id z53mr8992919eef.39.1338977537286;
	Wed, 06 Jun 2012 03:12:17 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id t3sm4605616eeb.15.2012.06.06.03.12.14
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 03:12:16 -0700 (PDT)
Message-ID: <4FCF2CFD.7070606@xen.org>
Date: Wed, 06 Jun 2012 11:12:13 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-announce@lists.xen.org, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-users@lists.xen.org, xen-arm@lists.xen.org, xen-devel@lists.xen.org
Subject: [Xen-devel] Submit a Proposal to Speak at XenSummit North America
 2012 before the CFP Deadline, June 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-Type: multipart/mixed; boundary="===============3021442547764201407=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============3021442547764201407==
Content-Type: multipart/alternative;
 boundary="------------010405050404010608000400"

This is a multi-part message in MIME format.
--------------010405050404010608000400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

XenSummit · August 27-28, 2012 · Sheraton San Diego · San Diego, CA, USA


    Submit a Proposal to Speak at XenSummit North America 2012 before
    the CFP Deadline, June 15th!


        XenSummit North America
        August 27-28, 2012 -- San Diego, CA

Xen.org invites developers, users, researchers, open source projects and 
businesses who are developing and/or using Xen to submit a proposal for 
XenSummit North America 2012.

*Submit a speaking proposal for XenSummit North America 2012 
<http://xen.org/polls/xensummit_na_2012.html>*


      Suggested topics for XenSummit America include:

  * Latest developments and features in Xen and related projects
  * Developments in upstream projects that impact the Xen community
  * Proposals on how to evolve Xen and related projects in future
  * Research using Xen and related projects
  * Proof of concepts and other interesting technologies related to Xen
  * Other topics related to developing and using Xen
  * Technologies and technology trends that will impact Xen development
    in future

  * User experiences and case studies with Xen or XCP
  * Benchmarks, case studies, improvement suggestions and other lessons
    learned
  * Innovative ways of using Xen and related projects
  * Open source projects and products that interface or build on top of
    Xen or related projects
  * Usage of Xen in server virtualization, cloud computing,
    clientvirtualization, mobile spaces, etc.

  *   Any other topics that you feel are relevant to developers, users,
    researchers and other members of the Xen community


We will have 30, 45 and 60 minute talking slots (including questions). 
Please choose the type of session when you submit a proposal.


      About XenSummit

XenSummit is the annual technical conference for Xen developers and 
users in North America. The conference provides a collaboration and 
education space for the Xen community and brings together a 
cross-section of the leading players in the Xen community, innovative 
and timely content and a wide variety of opportunities for attendee 
collaboration. This year, XenSummit is co-located with other industry 
events such as LinuxCon NA 
<https://events.linuxfoundation.org/events/linuxcon>, Linux Plumbers 
Conference <http://www.linuxplumbersconf.org/2012/>, Linux Kernel Summit 
<https://events.linuxfoundation.org/events/linux-kernel-summit>, 
CloudOpen <https://events.linuxfoundation.org/events/cloudopen> and 
others 
<https://events.linuxfoundation.org/events/cloudopen/co-located-events>, 
which will maximise opportunities for cross-community collaboration.

*Learn more about XenSummit* <http://xen.org/community/xensummit.html>
*Register for XenSummit* 
<http://www.regonline.com/Register/Checkin.aspx?EventId=1105690>

--------------010405050404010608000400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <meta http-equiv="Content-Type" content="text/html;
      charset=ISO-8859-1">
    <!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-GB</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:EnableOpenTypeKerning/>
   <w:DontFlipMirrorIndents/>
   <w:OverrideTableStyleHps/>
  </w:Compatibility>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="267">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style>
<![endif]-->
    <p class="MsoNormal" style="margin-bottom:12.0pt"><span
        style="mso-fareast-font-family:
        &quot;Times New Roman&quot;"><!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600"
 o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f"
 stroked="f">
 <v:stroke joinstyle="miter"/>
 <v:formulas>
  <v:f eqn="if lineDrawn pixelLineWidth 0"/>
  <v:f eqn="sum @0 1 0"/>
  <v:f eqn="sum 0 0 @1"/>
  <v:f eqn="prod @2 1 2"/>
  <v:f eqn="prod @3 21600 pixelWidth"/>
  <v:f eqn="prod @3 21600 pixelHeight"/>
  <v:f eqn="sum @0 0 1"/>
  <v:f eqn="prod @6 1 2"/>
  <v:f eqn="prod @7 21600 pixelWidth"/>
  <v:f eqn="sum @8 21600 0"/>
  <v:f eqn="prod @7 21600 pixelHeight"/>
  <v:f eqn="sum @10 21600 0"/>
 </v:formulas>
 <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
 <o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" alt="XenSummit &middot; August 27-28, 2012 &middot; Sheraton San Diego &middot; San&#13;&#10;      Diego, CA, USA"
 style='width:525pt;height:157.5pt'>
 <v:imagedata src="file:///C:\Users\LARSK~1.CIT\AppData\Local\Temp\msohtmlclip1\01\clip_image001.png"
  o:href="cid:part1.02000406.05050001@xen.org"/>
</v:shape><![endif]--><!--[if !vml]--><img
src="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_image002.png"
          alt="XenSummit &middot; August 27-28, 2012 &middot; Sheraton San Diego &middot;
          San
 Diego, CA, USA" v:shapes="_x0000_i1025" height="210"
          width="700"><!--[endif]--><o:p></o:p></span></p>
    <h2><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">Submit a Proposal
        to Speak at XenSummit North America 2012 before the CFP
        Deadline, June 15th!<o:p></o:p></span></h2>
    <h4><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">XenSummit North
        America<br>
        August 27-28, 2012 &#8211; San Diego, CA<o:p></o:p></span></h4>
    <p>Xen.org invites developers, users, researchers, open source
      projects and
      businesses who are developing and/or using Xen to submit a
      proposal for
      XenSummit North America 2012.<o:p></o:p></p>
    <p><b><span style="color:#3366FF"><a
            href="http://xen.org/polls/xensummit_na_2012.html">Submit a
            speaking proposal
            for XenSummit North America 2012</a></span></b><o:p></o:p></p>
    <h3><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">Suggested topics
        for XenSummit America include:<o:p></o:p></span></h3>
    <ul type="disc">
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Latest
          developments and features in Xen and related projects<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Developments
          in upstream projects that impact the Xen community<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Proposals
          on how to evolve Xen and related projects in future<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Research
          using Xen and related projects<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Proof
          of concepts and other interesting technologies related to Xen<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Other
          topics related to developing and using Xen<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l1 level1 lfo1;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Technologies
          and technology trends that will impact Xen development in
          future<o:p></o:p></span></li>
    </ul>
    <ul type="disc">
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">User
          experiences and case studies with Xen or XCP<o:p></o:p></span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span style="">Benchmarks,
          case studies, improvement suggestions and other </span><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">lessons
          learned</span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Innovative
          ways of using Xen and related projects<br>
        </span></li>
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span
          style="mso-fareast-font-family: &quot;Times New Roman&quot;">Open
          source projects and products that interface or build on top of
          Xen or related projects<o:p></o:p></span></li>
      <li class="MsoNormal" style=""><span style="">Usage of Xen in
          server virtualization, cloud computing, client</span><span
          style="font-size:12.0pt;line-height:115%;
          font-family:&quot;Times New
          Roman&quot;,&quot;serif&quot;;mso-fareast-font-family:&quot;Times
          New Roman&quot;;
mso-ansi-language:EN-GB;mso-fareast-language:EN-GB;mso-bidi-language:AR-SA">
          virtualization</span><span style="">, mobile spaces, etc. <br>
        </span></li>
    </ul>
    <span style=""></span>
    <ul type="disc">
      <li class="MsoNormal"
        style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
        mso-list:l0 level1 lfo2;tab-stops:list 36.0pt"><span style="">&nbsp;Any
          other topics that you feel are relevant to </span>developers,
        users, researchers and other members of the Xen community<br>
      </li>
    </ul>
    <p class="MsoNormal"><span
        style="mso-fareast-font-family:&quot;Times New Roman&quot;"><br>
        We
        will have 30, 45 and 60 minute talking slots (including
        questions). Please
        choose the type of session when you submit a proposal. <o:p></o:p></span></p>
    <h3><span style="mso-fareast-font-family:&quot;Times New
        Roman&quot;">About XenSummit<o:p></o:p></span></h3>
    <p>XenSummit is the annual technical conference for Xen developers
      and users in
      North America. The conference provides a collaboration and
      education space for
      the Xen community and brings together a cross-section of the
      leading players in
      the Xen community, innovative and timely content and a wide
      variety of
      opportunities for attendee collaboration. This year, XenSummit is
      co-located
      with other industry events such as <a
        href="https://events.linuxfoundation.org/events/linuxcon">LinuxCon
        NA</a>, <a href="http://www.linuxplumbersconf.org/2012/">Linux
        Plumbers Conference</a>, <a
        href="https://events.linuxfoundation.org/events/linux-kernel-summit">Linux
Kernel
        Summit</a>, <a
        href="https://events.linuxfoundation.org/events/cloudopen">CloudOpen</a>
      and <a
href="https://events.linuxfoundation.org/events/cloudopen/co-located-events">others</a>,
      which will maximise opportunities for cross-community
      collaboration.<o:p></o:p></p>
    <span style="font-size:12.0pt;font-family:&quot;Times New
      Roman&quot;,&quot;serif&quot;;mso-fareast-font-family:
      &quot;Times New
      Roman&quot;;color:black;mso-ansi-language:EN-GB;mso-fareast-language:
      EN-GB;mso-bidi-language:AR-SA"><a
        href="http://xen.org/community/xensummit.html"><b>Learn
          more about XenSummit</b></a><br>
      <a
        href="http://www.regonline.com/Register/Checkin.aspx?EventId=1105690"><b>Register
for
          XenSummit</b></a></span>
    <meta name="ProgId" content="Word.Document">
    <meta name="Generator" content="Microsoft Word 14">
    <meta name="Originator" content="Microsoft Word 14">
    <link rel="File-List"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">
    <link rel="Edit-Time-Data"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_editdata.mso">
    <link rel="themeData"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx">
    <link rel="colorSchemeMapping"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">
    <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;}
h2
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 2 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	mso-outline-level:2;
	font-size:18.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
h3
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 3 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	mso-outline-level:3;
	font-size:13.5pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
h4
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 4 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	mso-outline-level:4;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	mso-themecolor:followedhyperlink;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-style-noshow:yes;
	mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 2";
	mso-ansi-font-size:18.0pt;
	mso-bidi-font-size:18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 3";
	mso-ansi-font-size:13.5pt;
	mso-bidi-font-size:13.5pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 4";
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	color:black;
	font-weight:bold;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
 /* List Definitions */
 @list l0
	{mso-list-id:506135686;
	mso-list-template-ids:2121573526;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:&#61623;;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1
	{mso-list-id:1640650674;
	mso-list-template-ids:398722712;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:&#61623;;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l1:level3
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level4
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level5
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level6
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level7
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level8
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l1:level9
	{mso-level-number-format:bullet;
	mso-level-text:&#61607;;
	mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
  </body>
</html>

--------------010405050404010608000400--


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

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

--===============3021442547764201407==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 10:17:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:17: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 1ScDIB-0004f3-UE; Wed, 06 Jun 2012 10:16:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScDI9-0004eq-W4
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 10:16:42 +0000
Received: from [85.158.143.99:25221] by server-3.bemta-4.messagelabs.com id
	B1/54-29237-90E2FCF4; Wed, 06 Jun 2012 10:16:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338977798!31213292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22135 invoked from network); 6 Jun 2012 10:16:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12854879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:16:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:16:00 +0100
Message-ID: <1338977759.32319.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <dunlapg@umich.edu>
Date: Wed, 6 Jun 2012 11:15:59 +0100
In-Reply-To: <CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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 Wed, 2012-06-06 at 10:20 +0100, George Dunlap wrote:
> On Fri, Jun 1, 2012 at 6:48 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1338572607 -7200
> > # Node ID 3da83ff08d6b6431c104a431d6617ccb5977643b
> > # Parent  fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
> > xl.cfg: document the cpuid= option
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >
> > diff -r fde8ad0252ee -r 3da83ff08d6b docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -969,9 +969,47 @@ XXX
> >
> >  XXX
> >
> > -=item B<cpuid=XXX>
> > +=item B<cpuid="STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
> >
> > -XXX
> > +Configure guest CPUID responses.
> 
> I think I would say, "Configure the value returned when a guest
> executes CPUID instruction".  ("Response" is a technical term that
> doesn't really seem to fit here, I think.)
> 
> > Two config versions of config syntax are
> > +recognized: xend and libxl.
> 
> It's not clear from this text -- will libxl understand the xend format?

Yes, although for clarity the xl one ought to be preferred IMHO and
therefore made more prominent than the xend one i.e. be described first
and completely rather than referencing to the xend syntax (which can
refer to the xl stuff if necessary).

> 
> Other than that, the explanation and the example look really good.
> (NB, I haven't reviewed for accuracy.)
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 10:17:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:17: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 1ScDIB-0004f3-UE; Wed, 06 Jun 2012 10:16:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScDI9-0004eq-W4
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 10:16:42 +0000
Received: from [85.158.143.99:25221] by server-3.bemta-4.messagelabs.com id
	B1/54-29237-90E2FCF4; Wed, 06 Jun 2012 10:16:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338977798!31213292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22135 invoked from network); 6 Jun 2012 10:16:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12854879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:16:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:16:00 +0100
Message-ID: <1338977759.32319.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <dunlapg@umich.edu>
Date: Wed, 6 Jun 2012 11:15:59 +0100
In-Reply-To: <CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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 Wed, 2012-06-06 at 10:20 +0100, George Dunlap wrote:
> On Fri, Jun 1, 2012 at 6:48 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1338572607 -7200
> > # Node ID 3da83ff08d6b6431c104a431d6617ccb5977643b
> > # Parent  fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
> > xl.cfg: document the cpuid= option
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >
> > diff -r fde8ad0252ee -r 3da83ff08d6b docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -969,9 +969,47 @@ XXX
> >
> >  XXX
> >
> > -=item B<cpuid=XXX>
> > +=item B<cpuid="STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
> >
> > -XXX
> > +Configure guest CPUID responses.
> 
> I think I would say, "Configure the value returned when a guest
> executes CPUID instruction".  ("Response" is a technical term that
> doesn't really seem to fit here, I think.)
> 
> > Two config versions of config syntax are
> > +recognized: xend and libxl.
> 
> It's not clear from this text -- will libxl understand the xend format?

Yes, although for clarity the xl one ought to be preferred IMHO and
therefore made more prominent than the xend one i.e. be described first
and completely rather than referencing to the xend syntax (which can
refer to the xl stuff if necessary).

> 
> Other than that, the explanation and the example look really good.
> (NB, I haven't reviewed for accuracy.)
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLw-0005Gd-Em; Wed, 06 Jun 2012 10:20:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1ScCnz-0003Ha-6v
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:45:31 +0000
Received: from [193.109.254.147:4584] by server-5.bemta-14.messagelabs.com id
	66/CD-31398-AB62FCF4; Wed, 06 Jun 2012 09:45:30 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338975924!12967924!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=2.2 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20006 invoked from network); 6 Jun 2012 09:45:24 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:45:24 -0000
Received: by bkty5 with SMTP id y5so6811445bkt.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 02:45:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dC+mycH+HmEGfFzVwOZs7vDHaS2I3qZQDA2dplcAWxs=;
	b=ODhZFASLr4d4UqjNk6pelQl2BQpWJ0ze5aVLU/0/ZPf5oMSuCnhbKnp+OuTOGa7GnI
	vuZX3N9GE/+h1uORZUuYhL0vfS+TtcQT5oeIrxHeAJWBh2v07cZ3+hEzKSogUPChOzV5
	CXmmyCI2oXczs0qqMkddbEZ40j35GZG+H6X4UZGN46FPkUR2zKTN1CkJkx3vbD7i9EfW
	wZwU/t8Dvxa8kHOsMJmEx7PSVfLf43rWCMpE1qd7JQozae1s1KXkbklc8kvuxI8BfHfK
	4zQB1/h8Y9MOXLyCPVpFrlZL5b6HjFQrHQXrwldofuy1Lk/tesofgIODXWq7821NH5cg
	Xd9Q==
Received: by 10.205.127.140 with SMTP id ha12mr11514332bkc.105.1338975923779; 
	Wed, 06 Jun 2012 02:45:23 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id e20sm1379625bkw.3.2012.06.06.02.45.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 02:45:22 -0700 (PDT)
Date: Wed, 6 Jun 2012 11:45:18 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, mingo@elte.hu, tglx@linutronix.de
Message-ID: <20120606094518.GE9495@gmail.com>
References: <20120530173247.GC15635@x1.osrc.amd.com>
	<4FC65D34.1060803@zytor.com>
	<20120530175150.GE15438@x1.osrc.amd.com>
	<4FC66037.6020506@zytor.com>
	<20120530181722.GF15438@x1.osrc.amd.com>
	<4FC664E1.9050504@zytor.com>
	<20120530223334.GB28417@andromeda.dapyr.net>
	<4FC6A897.6020005@zytor.com> <20120606092713.GB9495@gmail.com>
	<20120606094254.GA4990@liondog.tnic>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120606094254.GA4990@liondog.tnic>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:33 +0000
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD
 Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* Borislav Petkov <bp@alien8.de> wrote:

> On Wed, Jun 06, 2012 at 11:27:13AM +0200, Ingo Molnar wrote:
> > 
> > * H. Peter Anvin <hpa@zytor.com> wrote:
> > 
> > > On 05/30/2012 03:33 PM, Konrad Rzeszutek Wilk wrote:
> > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > > index 75f33b2..e74df95 100644
> > > > --- a/arch/x86/xen/enlighten.c
> > > > +++ b/arch/x86/xen/enlighten.c
> > > > @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
> > > >  	.wbinvd = native_wbinvd,
> > > >  
> > > >  	.read_msr = native_read_msr_safe,
> > > > +	.rdmsr_regs = native_rdmsr_safe_regs,
> > > >  	.write_msr = xen_write_msr_safe,
> > > > +	.wrmsr_regs = native_wrmsr_safe_regs,
> > > > +
> > > >  	.read_tsc = native_read_tsc,
> > > >  	.read_pmc = native_read_pmc,
> > > >  
> > > 
> > > Okay, tell me again:
> > > 
> > > why do we have these hooks again?  Can we please weed out 
> > > paravirt methods that have no users?
> > 
> > ping?
> 
> I think we solved all that and hpa wanted to queue them up shortly:
> 
> http://marc.info/?l=linux-kernel&m=133856342618027&w=2

Great, will wait for hpa then.

Thanks,

	Ingo

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLw-0005Gd-Em; Wed, 06 Jun 2012 10:20:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1ScCnz-0003Ha-6v
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:45:31 +0000
Received: from [193.109.254.147:4584] by server-5.bemta-14.messagelabs.com id
	66/CD-31398-AB62FCF4; Wed, 06 Jun 2012 09:45:30 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338975924!12967924!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=2.2 required=7.0 tests=BODY_RANDOM_LONG,INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20006 invoked from network); 6 Jun 2012 09:45:24 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:45:24 -0000
Received: by bkty5 with SMTP id y5so6811445bkt.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 02:45:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=dC+mycH+HmEGfFzVwOZs7vDHaS2I3qZQDA2dplcAWxs=;
	b=ODhZFASLr4d4UqjNk6pelQl2BQpWJ0ze5aVLU/0/ZPf5oMSuCnhbKnp+OuTOGa7GnI
	vuZX3N9GE/+h1uORZUuYhL0vfS+TtcQT5oeIrxHeAJWBh2v07cZ3+hEzKSogUPChOzV5
	CXmmyCI2oXczs0qqMkddbEZ40j35GZG+H6X4UZGN46FPkUR2zKTN1CkJkx3vbD7i9EfW
	wZwU/t8Dvxa8kHOsMJmEx7PSVfLf43rWCMpE1qd7JQozae1s1KXkbklc8kvuxI8BfHfK
	4zQB1/h8Y9MOXLyCPVpFrlZL5b6HjFQrHQXrwldofuy1Lk/tesofgIODXWq7821NH5cg
	Xd9Q==
Received: by 10.205.127.140 with SMTP id ha12mr11514332bkc.105.1338975923779; 
	Wed, 06 Jun 2012 02:45:23 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id e20sm1379625bkw.3.2012.06.06.02.45.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 02:45:22 -0700 (PDT)
Date: Wed, 6 Jun 2012 11:45:18 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, mingo@elte.hu, tglx@linutronix.de
Message-ID: <20120606094518.GE9495@gmail.com>
References: <20120530173247.GC15635@x1.osrc.amd.com>
	<4FC65D34.1060803@zytor.com>
	<20120530175150.GE15438@x1.osrc.amd.com>
	<4FC66037.6020506@zytor.com>
	<20120530181722.GF15438@x1.osrc.amd.com>
	<4FC664E1.9050504@zytor.com>
	<20120530223334.GB28417@andromeda.dapyr.net>
	<4FC6A897.6020005@zytor.com> <20120606092713.GB9495@gmail.com>
	<20120606094254.GA4990@liondog.tnic>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120606094254.GA4990@liondog.tnic>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:33 +0000
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD
 Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* Borislav Petkov <bp@alien8.de> wrote:

> On Wed, Jun 06, 2012 at 11:27:13AM +0200, Ingo Molnar wrote:
> > 
> > * H. Peter Anvin <hpa@zytor.com> wrote:
> > 
> > > On 05/30/2012 03:33 PM, Konrad Rzeszutek Wilk wrote:
> > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > > index 75f33b2..e74df95 100644
> > > > --- a/arch/x86/xen/enlighten.c
> > > > +++ b/arch/x86/xen/enlighten.c
> > > > @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
> > > >  	.wbinvd = native_wbinvd,
> > > >  
> > > >  	.read_msr = native_read_msr_safe,
> > > > +	.rdmsr_regs = native_rdmsr_safe_regs,
> > > >  	.write_msr = xen_write_msr_safe,
> > > > +	.wrmsr_regs = native_wrmsr_safe_regs,
> > > > +
> > > >  	.read_tsc = native_read_tsc,
> > > >  	.read_pmc = native_read_pmc,
> > > >  
> > > 
> > > Okay, tell me again:
> > > 
> > > why do we have these hooks again?  Can we please weed out 
> > > paravirt methods that have no users?
> > 
> > ping?
> 
> I think we solved all that and hpa wanted to queue them up shortly:
> 
> http://marc.info/?l=linux-kernel&m=133856342618027&w=2

Great, will wait for hpa then.

Thanks,

	Ingo

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLu-0005F8-6Y; Wed, 06 Jun 2012 10:20:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jackyzt98@gmail.com>) id 1SbkjJ-0005PM-1t
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 03:46:49 +0000
Received: from [193.109.254.147:17550] by server-3.bemta-14.messagelabs.com id
	57/2E-05653-8218DCF4; Tue, 05 Jun 2012 03:46:48 +0000
X-Env-Sender: jackyzt98@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1338868006!12461931!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12343 invoked from network); 5 Jun 2012 03:46:47 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 03:46:47 -0000
Received: by qcsc20 with SMTP id c20so3268517qcs.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 20:46:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KoVRy8/HutKNxYU/0Ok5pd3SeC+o92Z+/j0ru3rEVbU=;
	b=v0WeFnQIyoVeuctIlMj0wChkvhYOmX+lH5AbZrsuPqHbWGozwbkyzj46/lee3ZelJI
	EdE+KxHq7lJOQo7uKPTJbJSKpKlyrjqFoUyQMrzEawUlGyYSwHZlI5kEN6EF4RDi29rv
	K+5Y7b/pmyBKXT/NkCJ8pWBZ/ROStKe20fE6M90zEGhj+O8VKHQF6vaBFp84DgzVl5c7
	5FdPz3ICSsSJcSlhnsjoHtpeAaruF9hTbaoJVzZTnoeomGPBaMqwPDo+z0aOwjGcDK8a
	lUggiA+GDuTw48CKxivxt9u2fyFBcPnG3EiQjTfvF0/0nm9ouquSfQGEk2FNTxa1PxvR
	6gTQ==
MIME-Version: 1.0
Received: by 10.229.102.73 with SMTP id f9mr4604500qco.103.1338868005949; Mon,
	04 Jun 2012 20:46:45 -0700 (PDT)
Received: by 10.229.225.71 with HTTP; Mon, 4 Jun 2012 20:46:45 -0700 (PDT)
Date: Tue, 5 Jun 2012 11:46:45 +0800
Message-ID: <CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com>
From: Zhou Jacky <jackyzt98@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Subject: [Xen-devel] [bug report] Windows HVM Hang when reboot/power off
	using special config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6390823447204514567=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6390823447204514567==
Content-Type: multipart/alternative; boundary=002354471dd8e5504404c1b17fdf

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

Hi,

Seems there's a bug when booting HVM guest Windows 2003 using
special config (pin 2 VCPUs to same phy CPU). The guest OS will hange when
reboot or power off system
in guest. The CPU will be 100 percent when watching xentop. The config file
as following:

****************************************************
kernel="/usr/lib/xen-4.1/boot/hvmloader"
builder='hvm'
name="windows_2003"
uuid="bb29f502-315a-488d-a234-c5651bcd6fbe"
memory=4096
vcpus=2
on_reboot='restart'
on_crash='restart'
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=29
stdvga=0
serial='pty'
usbdevice='tablet'
localtime=1
cpus=['5','5']
***************************************

Then I debug qemu-dm, find the OS never execute the ACPI register write, so
the QEMU can not catch the system reboot/power off event.
The normal case for guest OS poweroff will be : at first all system
process/driver quit, then OS write ACPI register to poweroff system power.

1. Qemu fetch the register memory map in shared page, judge if it's ACPI
register write.
2. If it's a reset, reboot, poweroff ACPI register operation, then
call qemu_system_shutdown_request() or qemu_system_reset_request()
 to set a flag
3. If the flag be set, call destroy_hvm_domain()
4. Qemu process quit, xend clear other resource

In my case, the qemu_system_shutdown_request ( ACPI register write ) never
be triggered. And the VCPU usage be 100 percent.
So I think it must exist some spinlock-like code in guest OS which cause
the ACPI write never be executed.
If I pin one VCPU to another CPU like '6', then ACPI register write be
called immediately, guest OS poweroff smoothly.

So anyone know why it's not work when PIN 2 VCPUs to same physical CPU when
booting HVM Windows 2003? Thanks.

Normal call stack:
qemu_system_reset_request () at /root/qemu/xen-4.1.2/qemu/vl.c:3673
#1  0x000000000047950a in cpu_ioreq_pio (req=0x7ff6d7dbd000, env=0x22a1c40)
at /root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:351
#2  __handle_ioreq (env=0x22a1c40, req=0x7ff6d7dbd000) at
/root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:446
#3  0x0000000000479d7b in cpu_handle_ioreq (opaque=0x22a1c40) at
/root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:515
#4  0x000000000040d81f in main_loop_wait (timeout=<optimized out>) at
/root/qemu/xen-4.1.2/qemu/vl.c:3794

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

<p>Hi,</p>
<p>Seems there&#39;s a bug when=A0booting HVM=A0guest=A0Windows 2003=A0usin=
g special=A0config=A0(pin 2 VCPUs to same phy=A0CPU). The guest OS will han=
ge when reboot or power off system<br>in guest. The CPU will be 100 percent=
 when watching xentop. The config file as following:</p>

<p>****************************************************<br>kernel=3D&quot;/=
usr/lib/xen-4.1/boot/hvmloader&quot;<br>builder=3D&#39;hvm&#39;<br>name=3D&=
quot;windows_2003&quot;<br>uuid=3D&quot;bb29f502-315a-488d-a234-c5651bcd6fb=
e&quot;<br>
memory=3D4096<br>vcpus=3D2<br>on_reboot=3D&#39;restart&#39;<br>on_crash=3D&=
#39;restart&#39;<br>sdl=3D0<br>vnc=3D1<br>vnclisten=3D&quot;0.0.0.0&quot;<b=
r>vncdisplay=3D29<br>stdvga=3D0<br>serial=3D&#39;pty&#39;<br>usbdevice=3D&#=
39;tablet&#39;<br>
localtime=3D1<br>cpus=3D[&#39;5&#39;,&#39;5&#39;]<br>**********************=
*****************</p>
<p>Then I debug qemu-dm, find the OS never execute the ACPI register write,=
 so the QEMU can not catch the system reboot/power off event.<br>The normal=
 case for guest OS poweroff will be : at first all system process/driver qu=
it, then OS write ACPI register to poweroff system power. </p>

<p>1. Qemu fetch the register memory map in shared page, judge if it&#39;s =
ACPI register write.<br>2. If it&#39;s a reset, reboot, poweroff ACPI regis=
ter operation, then call=A0qemu_system_shutdown_request() or qemu_system_re=
set_request()<br>
=A0to set a flag<br>3. If the flag be set, call destroy_hvm_domain()<br>4. =
Qemu process quit, xend clear other resource=A0</p>
<p>In my case, the qemu_system_shutdown_request ( ACPI register write ) nev=
er be triggered. And the VCPU usage be 100 percent. <br>So I think it must =
exist some spinlock-like code in guest OS which cause the ACPI write never =
be executed.<br>
If I pin one VCPU to another CPU like &#39;6&#39;, then ACPI register write=
 be called immediately, guest OS poweroff smoothly.</p>
<p>So anyone know=A0why it&#39;s not work when PIN 2 VCPUs to same physical=
 CPU when booting HVM Windows 2003? Thanks.</p>
<p>Normal call stack:<br>qemu_system_reset_request () at /root/qemu/xen-4.1=
.2/qemu/vl.c:3673<br>#1=A0 0x000000000047950a in cpu_ioreq_pio (req=3D0x7ff=
6d7dbd000, env=3D0x22a1c40) at /root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:=
351<br>
#2=A0 __handle_ioreq (env=3D0x22a1c40, req=3D0x7ff6d7dbd000) at /root/qemu/=
xen-4.1.2/qemu/i386-dm/helper2.c:446<br>#3=A0 0x0000000000479d7b in cpu_han=
dle_ioreq (opaque=3D0x22a1c40) at /root/qemu/xen-4.1.2/qemu/i386-dm/helper2=
.c:515<br>
#4=A0 0x000000000040d81f in main_loop_wait (timeout=3D&lt;optimized out&gt;=
) at /root/qemu/xen-4.1.2/qemu/vl.c:3794</p>

--002354471dd8e5504404c1b17fdf--


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

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

--===============6390823447204514567==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLv-0005Fr-Bf; Wed, 06 Jun 2012 10:20:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1Sbxl2-0005AP-1N
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 17:41:28 +0000
Received: from [85.158.143.35:5336] by server-2.bemta-4.messagelabs.com id
	30/FE-25135-7C44ECF4; Tue, 05 Jun 2012 17:41:27 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1338918086!7193440!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9157 invoked from network); 5 Jun 2012 17:41:26 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Jun 2012 17:41:26 -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 1SbxkK-0005TP-1Z; Tue, 05 Jun 2012 19:40:44 +0200
Date: Tue, 5 Jun 2012 19:40:42 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
In-Reply-To: <4FCA5608.2010404@linux.vnet.ibm.com>
Message-ID: <alpine.LFD.2.02.1206051921320.3086@ionos>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.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
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:33 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, paulmck@linux.vnet.ibm.com, mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2 Jun 2012, Srivatsa S. Bhat wrote:
> Ok.. So, I would love to hear a confirmation about whether this patch (which
> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.
> 
> If its not correct, then we can probably make __cpu_post_online() return an int,
> with the meaning:
> 
> 0 => success, go ahead and call cpu_idle()
> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
> 
> So all other archs will return 0, Xen will return non-zero, and it will handle
> when to call cpu_idle() and when not to do so.
> 
> Might sound a bit ugly, but I don't see much other option. Suggestions are
> appreciated!

Yes, it's butt ugly. 

You are tripping over the main misconception of the current hotplug
code: It's asymetric.

So people added warts and workarounds like the xen one. What you are
proposing is another wart and workaround.

The real way to avoid it, is to have the symetric state machine in
place first and then convert everything to that instead of introducing
an intermediate state which resembles the existing state.

One of the main things we need to do to make it symetric is to kill
the play_dead() thing in the idle loop and make idle a function which
returns on cpu_should_die().

Give me a day or two and I get you a working version of that. (Up is
functional, just down refuses to play along)

Thanks,

	tglx


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLv-0005Fr-Bf; Wed, 06 Jun 2012 10:20:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1Sbxl2-0005AP-1N
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 17:41:28 +0000
Received: from [85.158.143.35:5336] by server-2.bemta-4.messagelabs.com id
	30/FE-25135-7C44ECF4; Tue, 05 Jun 2012 17:41:27 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1338918086!7193440!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9157 invoked from network); 5 Jun 2012 17:41:26 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Jun 2012 17:41:26 -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 1SbxkK-0005TP-1Z; Tue, 05 Jun 2012 19:40:44 +0200
Date: Tue, 5 Jun 2012 19:40:42 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
In-Reply-To: <4FCA5608.2010404@linux.vnet.ibm.com>
Message-ID: <alpine.LFD.2.02.1206051921320.3086@ionos>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.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
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:33 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, paulmck@linux.vnet.ibm.com, mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2 Jun 2012, Srivatsa S. Bhat wrote:
> Ok.. So, I would love to hear a confirmation about whether this patch (which
> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.
> 
> If its not correct, then we can probably make __cpu_post_online() return an int,
> with the meaning:
> 
> 0 => success, go ahead and call cpu_idle()
> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
> 
> So all other archs will return 0, Xen will return non-zero, and it will handle
> when to call cpu_idle() and when not to do so.
> 
> Might sound a bit ugly, but I don't see much other option. Suggestions are
> appreciated!

Yes, it's butt ugly. 

You are tripping over the main misconception of the current hotplug
code: It's asymetric.

So people added warts and workarounds like the xen one. What you are
proposing is another wart and workaround.

The real way to avoid it, is to have the symetric state machine in
place first and then convert everything to that instead of introducing
an intermediate state which resembles the existing state.

One of the main things we need to do to make it symetric is to kill
the play_dead() thing in the idle loop and make idle a function which
returns on cpu_should_die().

Give me a day or two and I get you a working version of that. (Up is
functional, just down refuses to play along)

Thanks,

	tglx


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLu-0005FZ-Vv; Wed, 06 Jun 2012 10:20:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SbxhK-00059i-Qv
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 17:37:39 +0000
Received: from [85.158.138.51:18436] by server-12.bemta-3.messagelabs.com id
	0C/2B-24185-2E34ECF4; Tue, 05 Jun 2012 17:37:38 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1338917855!30904191!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDgwMjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30200 invoked from network); 5 Jun 2012 17:37:37 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jun 2012 17:37:37 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Tue, 5 Jun 2012 23:07:20 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 5 Jun 2012 23:07:06 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q55Hb49V65274022
	for <xen-devel@lists.xensource.com>; Tue, 5 Jun 2012 23:07:06 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q55N7f5f019288
	for <xen-devel@lists.xensource.com>; Wed, 6 Jun 2012 09:07:43 +1000
Received: from [9.77.83.67] ([9.77.83.67])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q55N7aos019054; Wed, 6 Jun 2012 09:07:36 +1000
Message-ID: <4FCE438C.5080005@linux.vnet.ibm.com>
Date: Tue, 05 Jun 2012 23:06:12 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.com>
	<20120605164957.GA1997@phenom.dumpdata.com>
In-Reply-To: <20120605164957.GA1997@phenom.dumpdata.com>
x-cbid: 12060517-4790-0000-0000-000003186CEB
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05/2012 10:19 PM, Konrad Rzeszutek Wilk wrote:

> On Sat, Jun 02, 2012 at 11:36:00PM +0530, Srivatsa S. Bhat wrote:
>> On 06/01/2012 09:06 PM, Jan Beulich wrote:
>>
>>>>>> On 01.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>> wrote:
>>>> On 06/01/2012 06:29 PM, Jan Beulich wrote:
>>>>
>>>>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>>>> wrote:
>>>>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>>>>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>>>>>> suggests) is useful in the cpu bringup path.
>>>>>
>>>>> This might not be correct - the code as it is without this change is
>>>>> safe even when the vCPU gets onlined back later by an external
>>>>> entity (e.g. the Xen tool stack), and it would in that case resume
>>>>> at the return point of the VCPUOP_down hypercall. That might
>>>>> be a heritage from the original XenoLinux tree though, and be
>>>>> meaningless in pv-ops context - Jeremy, Konrad?
>>>>>
>>>>> Possibly it was bogus/unused even in that original tree - Keir?
>>>>>
>>>>
>>>>
>>>> Thanks for your comments Jan!
>>>>
>>>> In case this change is wrong, the other method I had in mind was to call
>>>> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
>>>> in the sense that it runs the cpu bringup code including cpu_idle(), in the
>>>> cpu offline path, namely the cpu_die() function). Would that approach work
>>>> for xen as well? If yes, then we wouldn't have any issues to convert xen to
>>>> generic code.
>>>
>>> No, that wouldn't work either afaict - the function is expected
>>> to return.
>>>
>>
>>
>> Ok.. So, I would love to hear a confirmation about whether this patch (which
>> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.
> 
> I think it will break - are these patches available on some git tree to test them out?
> 


Oh, sorry I haven't hosted them on any git tree.. 

>>
>> If its not correct, then we can probably make __cpu_post_online() return an int,
>> with the meaning:
>>
>> 0 => success, go ahead and call cpu_idle()
>> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
>>
>> So all other archs will return 0, Xen will return non-zero, and it will handle
>> when to call cpu_idle() and when not to do so.
> 
> The call-chain (this is taken from 41bd956de3dfdc3a43708fe2e0c8096c69064a1e):
> 
>     cpu_bringup_and_idle:
>      \- cpu_bringup
>       |   \-[preempt_disable]
>       |
>       |- cpu_idle
>            \- play_dead [assuming the user offlined the VCPU]
>            |     \
>            |     +- (xen_play_dead)
>            |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
>            |          |                       onlines it starts from here]
>            |          \- cpu_bringup [preempt_disable]
>            |
>            +- preempt_enable_no_reschedule()
>            +- schedule()
>            \- preempt_enable()
> 
> Which I think is a bit different from your use-case?
> 


Yes, when this patch is applied, the call to cpu_bringup() after HYPERVISOR_VCPU_off
gets removed. So it will look like this:

    cpu_bringup_and_idle:
     \- cpu_bringup
      |   \-[preempt_disable]
      |
      |- cpu_idle
           \- play_dead [assuming the user offlined the VCPU]
           |     \
           |     +- (xen_play_dead)
           |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
           |                                  onlines it starts from here]
           |
           |
           +- preempt_enable_no_reschedule()
           +- schedule()
           \- preempt_enable()


And hence we wouldn't have the preempt imbalance, hence no need for the
extra preempt_enable() in xen_play_dead().

So, basically our problem is this:
The generic smp booting code calls cpu_idle() after setting the cpu in
cpu_online_mask etc, because this call to cpu_idle() is used in every
architecture. But just for xen, that too only in the cpu down path, this
call is omitted - which makes it difficult to convert xen to the generic
smp booting framework.

So I proposed 3 solutions, of which we can choose whichever that doesn't
break stuff and whichever looks the least ugly:

1. Omit the call to cpu_bringup() after HYPERVISOR_VCPU_off (which this
patch does).

2. Or, invoke cpu_bringup_and_idle() after HYPERVISOR_VCPU_off (Jan said
this might not work since we are expected to return). ARM actually does
something like this (it does the complete bringup including idle in the
cpu down path).

3. Or, Just for the sake of Xen, convert the __cpu_post_online() function to
return an int - Xen will return non-zero and do the next steps itself,
also deciding between whether or not to call cpu_idle(). All other archs
will just return 0, and allow the generic smp booting code to continue
on to cpu_idle().

Please let me know your thoughts.

Regards,
Srivatsa S. Bhat


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLv-0005G7-NO; Wed, 06 Jun 2012 10:20:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1Sbxsk-0005Ba-C5
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 17:49:26 +0000
Received: from [193.109.254.147:54078] by server-8.bemta-14.messagelabs.com id
	70/38-27132-4A64ECF4; Tue, 05 Jun 2012 17:49:24 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338918562!6105398!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxMzA3Njk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6878 invoked from network); 5 Jun 2012 17:49:24 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 17:49:24 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Tue, 5 Jun 2012 23:19:21 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 5 Jun 2012 23:19:19 +0530
Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q55HnIuh1507822
	for <xen-devel@lists.xensource.com>; Tue, 5 Jun 2012 23:19:19 +0530
Received: from d28av03.in.ibm.com (loopback [127.0.0.1])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q55NIWcO022191
	for <xen-devel@lists.xensource.com>; Wed, 6 Jun 2012 09:18:34 +1000
Received: from [9.77.83.67] ([9.77.83.67])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q55NISmI021979; Wed, 6 Jun 2012 09:18:29 +1000
Message-ID: <4FCE466A.3050202@linux.vnet.ibm.com>
Date: Tue, 05 Jun 2012 23:18:26 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.com>
	<alpine.LFD.2.02.1206051921320.3086@ionos>
In-Reply-To: <alpine.LFD.2.02.1206051921320.3086@ionos>
x-cbid: 12060517-2674-0000-0000-000004CBA251
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, paulmck@linux.vnet.ibm.com, mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05/2012 11:10 PM, Thomas Gleixner wrote:

> On Sat, 2 Jun 2012, Srivatsa S. Bhat wrote:
>> Ok.. So, I would love to hear a confirmation about whether this patch (which
>> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.
>>
>> If its not correct, then we can probably make __cpu_post_online() return an int,
>> with the meaning:
>>
>> 0 => success, go ahead and call cpu_idle()
>> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
>>
>> So all other archs will return 0, Xen will return non-zero, and it will handle
>> when to call cpu_idle() and when not to do so.
>>
>> Might sound a bit ugly, but I don't see much other option. Suggestions are
>> appreciated!
> 
> Yes, it's butt ugly. 
> 
> You are tripping over the main misconception of the current hotplug
> code: It's asymetric.
> 
> So people added warts and workarounds like the xen one. What you are
> proposing is another wart and workaround.
> 
> The real way to avoid it, is to have the symetric state machine in
> place first and then convert everything to that instead of introducing
> an intermediate state which resembles the existing state.
> 
> One of the main things we need to do to make it symetric is to kill
> the play_dead() thing in the idle loop and make idle a function which
> returns on cpu_should_die().
> 
> Give me a day or two and I get you a working version of that. (Up is
> functional, just down refuses to play along)
> 


Oh great! So, then I'll wait for your patches and then adapt this patchset
to your model then. Let me know if I can help out with something..

Regards,
Srivatsa S. Bhat


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLv-0005G7-NO; Wed, 06 Jun 2012 10:20:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1Sbxsk-0005Ba-C5
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 17:49:26 +0000
Received: from [193.109.254.147:54078] by server-8.bemta-14.messagelabs.com id
	70/38-27132-4A64ECF4; Tue, 05 Jun 2012 17:49:24 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338918562!6105398!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxMzA3Njk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6878 invoked from network); 5 Jun 2012 17:49:24 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 17:49:24 -0000
Received: from /spool/local
	by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Tue, 5 Jun 2012 23:19:21 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 5 Jun 2012 23:19:19 +0530
Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q55HnIuh1507822
	for <xen-devel@lists.xensource.com>; Tue, 5 Jun 2012 23:19:19 +0530
Received: from d28av03.in.ibm.com (loopback [127.0.0.1])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q55NIWcO022191
	for <xen-devel@lists.xensource.com>; Wed, 6 Jun 2012 09:18:34 +1000
Received: from [9.77.83.67] ([9.77.83.67])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q55NISmI021979; Wed, 6 Jun 2012 09:18:29 +1000
Message-ID: <4FCE466A.3050202@linux.vnet.ibm.com>
Date: Tue, 05 Jun 2012 23:18:26 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Thomas Gleixner <tglx@linutronix.de>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.com>
	<alpine.LFD.2.02.1206051921320.3086@ionos>
In-Reply-To: <alpine.LFD.2.02.1206051921320.3086@ionos>
x-cbid: 12060517-2674-0000-0000-000004CBA251
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, nikunj@linux.vnet.ibm.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	akpm@linux-foundation.org, paulmck@linux.vnet.ibm.com, mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05/2012 11:10 PM, Thomas Gleixner wrote:

> On Sat, 2 Jun 2012, Srivatsa S. Bhat wrote:
>> Ok.. So, I would love to hear a confirmation about whether this patch (which
>> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.
>>
>> If its not correct, then we can probably make __cpu_post_online() return an int,
>> with the meaning:
>>
>> 0 => success, go ahead and call cpu_idle()
>> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
>>
>> So all other archs will return 0, Xen will return non-zero, and it will handle
>> when to call cpu_idle() and when not to do so.
>>
>> Might sound a bit ugly, but I don't see much other option. Suggestions are
>> appreciated!
> 
> Yes, it's butt ugly. 
> 
> You are tripping over the main misconception of the current hotplug
> code: It's asymetric.
> 
> So people added warts and workarounds like the xen one. What you are
> proposing is another wart and workaround.
> 
> The real way to avoid it, is to have the symetric state machine in
> place first and then convert everything to that instead of introducing
> an intermediate state which resembles the existing state.
> 
> One of the main things we need to do to make it symetric is to kill
> the play_dead() thing in the idle loop and make idle a function which
> returns on cpu_should_die().
> 
> Give me a day or two and I get you a working version of that. (Up is
> functional, just down refuses to play along)
> 


Oh great! So, then I'll wait for your patches and then adapt this patchset
to your model then. Let me know if I can help out with something..

Regards,
Srivatsa S. Bhat


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLu-0005F8-6Y; Wed, 06 Jun 2012 10:20:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jackyzt98@gmail.com>) id 1SbkjJ-0005PM-1t
	for xen-devel@lists.xen.org; Tue, 05 Jun 2012 03:46:49 +0000
Received: from [193.109.254.147:17550] by server-3.bemta-14.messagelabs.com id
	57/2E-05653-8218DCF4; Tue, 05 Jun 2012 03:46:48 +0000
X-Env-Sender: jackyzt98@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1338868006!12461931!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12343 invoked from network); 5 Jun 2012 03:46:47 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jun 2012 03:46:47 -0000
Received: by qcsc20 with SMTP id c20so3268517qcs.32
	for <xen-devel@lists.xen.org>; Mon, 04 Jun 2012 20:46:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KoVRy8/HutKNxYU/0Ok5pd3SeC+o92Z+/j0ru3rEVbU=;
	b=v0WeFnQIyoVeuctIlMj0wChkvhYOmX+lH5AbZrsuPqHbWGozwbkyzj46/lee3ZelJI
	EdE+KxHq7lJOQo7uKPTJbJSKpKlyrjqFoUyQMrzEawUlGyYSwHZlI5kEN6EF4RDi29rv
	K+5Y7b/pmyBKXT/NkCJ8pWBZ/ROStKe20fE6M90zEGhj+O8VKHQF6vaBFp84DgzVl5c7
	5FdPz3ICSsSJcSlhnsjoHtpeAaruF9hTbaoJVzZTnoeomGPBaMqwPDo+z0aOwjGcDK8a
	lUggiA+GDuTw48CKxivxt9u2fyFBcPnG3EiQjTfvF0/0nm9ouquSfQGEk2FNTxa1PxvR
	6gTQ==
MIME-Version: 1.0
Received: by 10.229.102.73 with SMTP id f9mr4604500qco.103.1338868005949; Mon,
	04 Jun 2012 20:46:45 -0700 (PDT)
Received: by 10.229.225.71 with HTTP; Mon, 4 Jun 2012 20:46:45 -0700 (PDT)
Date: Tue, 5 Jun 2012 11:46:45 +0800
Message-ID: <CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com>
From: Zhou Jacky <jackyzt98@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Subject: [Xen-devel] [bug report] Windows HVM Hang when reboot/power off
	using special config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6390823447204514567=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6390823447204514567==
Content-Type: multipart/alternative; boundary=002354471dd8e5504404c1b17fdf

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

Hi,

Seems there's a bug when booting HVM guest Windows 2003 using
special config (pin 2 VCPUs to same phy CPU). The guest OS will hange when
reboot or power off system
in guest. The CPU will be 100 percent when watching xentop. The config file
as following:

****************************************************
kernel="/usr/lib/xen-4.1/boot/hvmloader"
builder='hvm'
name="windows_2003"
uuid="bb29f502-315a-488d-a234-c5651bcd6fbe"
memory=4096
vcpus=2
on_reboot='restart'
on_crash='restart'
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=29
stdvga=0
serial='pty'
usbdevice='tablet'
localtime=1
cpus=['5','5']
***************************************

Then I debug qemu-dm, find the OS never execute the ACPI register write, so
the QEMU can not catch the system reboot/power off event.
The normal case for guest OS poweroff will be : at first all system
process/driver quit, then OS write ACPI register to poweroff system power.

1. Qemu fetch the register memory map in shared page, judge if it's ACPI
register write.
2. If it's a reset, reboot, poweroff ACPI register operation, then
call qemu_system_shutdown_request() or qemu_system_reset_request()
 to set a flag
3. If the flag be set, call destroy_hvm_domain()
4. Qemu process quit, xend clear other resource

In my case, the qemu_system_shutdown_request ( ACPI register write ) never
be triggered. And the VCPU usage be 100 percent.
So I think it must exist some spinlock-like code in guest OS which cause
the ACPI write never be executed.
If I pin one VCPU to another CPU like '6', then ACPI register write be
called immediately, guest OS poweroff smoothly.

So anyone know why it's not work when PIN 2 VCPUs to same physical CPU when
booting HVM Windows 2003? Thanks.

Normal call stack:
qemu_system_reset_request () at /root/qemu/xen-4.1.2/qemu/vl.c:3673
#1  0x000000000047950a in cpu_ioreq_pio (req=0x7ff6d7dbd000, env=0x22a1c40)
at /root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:351
#2  __handle_ioreq (env=0x22a1c40, req=0x7ff6d7dbd000) at
/root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:446
#3  0x0000000000479d7b in cpu_handle_ioreq (opaque=0x22a1c40) at
/root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:515
#4  0x000000000040d81f in main_loop_wait (timeout=<optimized out>) at
/root/qemu/xen-4.1.2/qemu/vl.c:3794

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

<p>Hi,</p>
<p>Seems there&#39;s a bug when=A0booting HVM=A0guest=A0Windows 2003=A0usin=
g special=A0config=A0(pin 2 VCPUs to same phy=A0CPU). The guest OS will han=
ge when reboot or power off system<br>in guest. The CPU will be 100 percent=
 when watching xentop. The config file as following:</p>

<p>****************************************************<br>kernel=3D&quot;/=
usr/lib/xen-4.1/boot/hvmloader&quot;<br>builder=3D&#39;hvm&#39;<br>name=3D&=
quot;windows_2003&quot;<br>uuid=3D&quot;bb29f502-315a-488d-a234-c5651bcd6fb=
e&quot;<br>
memory=3D4096<br>vcpus=3D2<br>on_reboot=3D&#39;restart&#39;<br>on_crash=3D&=
#39;restart&#39;<br>sdl=3D0<br>vnc=3D1<br>vnclisten=3D&quot;0.0.0.0&quot;<b=
r>vncdisplay=3D29<br>stdvga=3D0<br>serial=3D&#39;pty&#39;<br>usbdevice=3D&#=
39;tablet&#39;<br>
localtime=3D1<br>cpus=3D[&#39;5&#39;,&#39;5&#39;]<br>**********************=
*****************</p>
<p>Then I debug qemu-dm, find the OS never execute the ACPI register write,=
 so the QEMU can not catch the system reboot/power off event.<br>The normal=
 case for guest OS poweroff will be : at first all system process/driver qu=
it, then OS write ACPI register to poweroff system power. </p>

<p>1. Qemu fetch the register memory map in shared page, judge if it&#39;s =
ACPI register write.<br>2. If it&#39;s a reset, reboot, poweroff ACPI regis=
ter operation, then call=A0qemu_system_shutdown_request() or qemu_system_re=
set_request()<br>
=A0to set a flag<br>3. If the flag be set, call destroy_hvm_domain()<br>4. =
Qemu process quit, xend clear other resource=A0</p>
<p>In my case, the qemu_system_shutdown_request ( ACPI register write ) nev=
er be triggered. And the VCPU usage be 100 percent. <br>So I think it must =
exist some spinlock-like code in guest OS which cause the ACPI write never =
be executed.<br>
If I pin one VCPU to another CPU like &#39;6&#39;, then ACPI register write=
 be called immediately, guest OS poweroff smoothly.</p>
<p>So anyone know=A0why it&#39;s not work when PIN 2 VCPUs to same physical=
 CPU when booting HVM Windows 2003? Thanks.</p>
<p>Normal call stack:<br>qemu_system_reset_request () at /root/qemu/xen-4.1=
.2/qemu/vl.c:3673<br>#1=A0 0x000000000047950a in cpu_ioreq_pio (req=3D0x7ff=
6d7dbd000, env=3D0x22a1c40) at /root/qemu/xen-4.1.2/qemu/i386-dm/helper2.c:=
351<br>
#2=A0 __handle_ioreq (env=3D0x22a1c40, req=3D0x7ff6d7dbd000) at /root/qemu/=
xen-4.1.2/qemu/i386-dm/helper2.c:446<br>#3=A0 0x0000000000479d7b in cpu_han=
dle_ioreq (opaque=3D0x22a1c40) at /root/qemu/xen-4.1.2/qemu/i386-dm/helper2=
.c:515<br>
#4=A0 0x000000000040d81f in main_loop_wait (timeout=3D&lt;optimized out&gt;=
) at /root/qemu/xen-4.1.2/qemu/vl.c:3794</p>

--002354471dd8e5504404c1b17fdf--


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

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

--===============6390823447204514567==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLu-0005FZ-Vv; Wed, 06 Jun 2012 10:20:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <srivatsa.bhat@linux.vnet.ibm.com>)
	id 1SbxhK-00059i-Qv
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 17:37:39 +0000
Received: from [85.158.138.51:18436] by server-12.bemta-3.messagelabs.com id
	0C/2B-24185-2E34ECF4; Tue, 05 Jun 2012 17:37:38 +0000
X-Env-Sender: srivatsa.bhat@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1338917855!30904191!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDgwMjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30200 invoked from network); 5 Jun 2012 17:37:37 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jun 2012 17:37:37 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<srivatsa.bhat@linux.vnet.ibm.com>; Tue, 5 Jun 2012 23:07:20 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 5 Jun 2012 23:07:06 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q55Hb49V65274022
	for <xen-devel@lists.xensource.com>; Tue, 5 Jun 2012 23:07:06 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q55N7f5f019288
	for <xen-devel@lists.xensource.com>; Wed, 6 Jun 2012 09:07:43 +1000
Received: from [9.77.83.67] ([9.77.83.67])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q55N7aos019054; Wed, 6 Jun 2012 09:07:36 +1000
Message-ID: <4FCE438C.5080005@linux.vnet.ibm.com>
Date: Tue, 05 Jun 2012 23:06:12 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.com>
	<20120605164957.GA1997@phenom.dumpdata.com>
In-Reply-To: <20120605164957.GA1997@phenom.dumpdata.com>
x-cbid: 12060517-4790-0000-0000-000003186CEB
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05/2012 10:19 PM, Konrad Rzeszutek Wilk wrote:

> On Sat, Jun 02, 2012 at 11:36:00PM +0530, Srivatsa S. Bhat wrote:
>> On 06/01/2012 09:06 PM, Jan Beulich wrote:
>>
>>>>>> On 01.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>> wrote:
>>>> On 06/01/2012 06:29 PM, Jan Beulich wrote:
>>>>
>>>>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>>>> wrote:
>>>>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>>>>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
>>>>>> suggests) is useful in the cpu bringup path.
>>>>>
>>>>> This might not be correct - the code as it is without this change is
>>>>> safe even when the vCPU gets onlined back later by an external
>>>>> entity (e.g. the Xen tool stack), and it would in that case resume
>>>>> at the return point of the VCPUOP_down hypercall. That might
>>>>> be a heritage from the original XenoLinux tree though, and be
>>>>> meaningless in pv-ops context - Jeremy, Konrad?
>>>>>
>>>>> Possibly it was bogus/unused even in that original tree - Keir?
>>>>>
>>>>
>>>>
>>>> Thanks for your comments Jan!
>>>>
>>>> In case this change is wrong, the other method I had in mind was to call
>>>> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
>>>> in the sense that it runs the cpu bringup code including cpu_idle(), in the
>>>> cpu offline path, namely the cpu_die() function). Would that approach work
>>>> for xen as well? If yes, then we wouldn't have any issues to convert xen to
>>>> generic code.
>>>
>>> No, that wouldn't work either afaict - the function is expected
>>> to return.
>>>
>>
>>
>> Ok.. So, I would love to hear a confirmation about whether this patch (which
>> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.
> 
> I think it will break - are these patches available on some git tree to test them out?
> 


Oh, sorry I haven't hosted them on any git tree.. 

>>
>> If its not correct, then we can probably make __cpu_post_online() return an int,
>> with the meaning:
>>
>> 0 => success, go ahead and call cpu_idle()
>> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
>>
>> So all other archs will return 0, Xen will return non-zero, and it will handle
>> when to call cpu_idle() and when not to do so.
> 
> The call-chain (this is taken from 41bd956de3dfdc3a43708fe2e0c8096c69064a1e):
> 
>     cpu_bringup_and_idle:
>      \- cpu_bringup
>       |   \-[preempt_disable]
>       |
>       |- cpu_idle
>            \- play_dead [assuming the user offlined the VCPU]
>            |     \
>            |     +- (xen_play_dead)
>            |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
>            |          |                       onlines it starts from here]
>            |          \- cpu_bringup [preempt_disable]
>            |
>            +- preempt_enable_no_reschedule()
>            +- schedule()
>            \- preempt_enable()
> 
> Which I think is a bit different from your use-case?
> 


Yes, when this patch is applied, the call to cpu_bringup() after HYPERVISOR_VCPU_off
gets removed. So it will look like this:

    cpu_bringup_and_idle:
     \- cpu_bringup
      |   \-[preempt_disable]
      |
      |- cpu_idle
           \- play_dead [assuming the user offlined the VCPU]
           |     \
           |     +- (xen_play_dead)
           |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
           |                                  onlines it starts from here]
           |
           |
           +- preempt_enable_no_reschedule()
           +- schedule()
           \- preempt_enable()


And hence we wouldn't have the preempt imbalance, hence no need for the
extra preempt_enable() in xen_play_dead().

So, basically our problem is this:
The generic smp booting code calls cpu_idle() after setting the cpu in
cpu_online_mask etc, because this call to cpu_idle() is used in every
architecture. But just for xen, that too only in the cpu down path, this
call is omitted - which makes it difficult to convert xen to the generic
smp booting framework.

So I proposed 3 solutions, of which we can choose whichever that doesn't
break stuff and whichever looks the least ugly:

1. Omit the call to cpu_bringup() after HYPERVISOR_VCPU_off (which this
patch does).

2. Or, invoke cpu_bringup_and_idle() after HYPERVISOR_VCPU_off (Jan said
this might not work since we are expected to return). ARM actually does
something like this (it does the complete bringup including idle in the
cpu down path).

3. Or, Just for the sake of Xen, convert the __cpu_post_online() function to
return an int - Xen will return non-zero and do the next steps itself,
also deciding between whether or not to call cpu_idle(). All other archs
will just return 0, and allow the generic smp booting code to continue
on to cpu_idle().

Please let me know your thoughts.

Regards,
Srivatsa S. Bhat


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLu-0005FK-Je; Wed, 06 Jun 2012 10:20: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 1Sbx5r-0004Ut-II
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:58:55 +0000
Received: from [193.109.254.147:39911] by server-11.bemta-14.messagelabs.com
	id 5F/E5-02727-ECA3ECF4; Tue, 05 Jun 2012 16:58:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338915526!5238819!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTcwODUx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12152 invoked from network); 5 Jun 2012 16:58:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 16:58:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q55Gv7oR030794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Jun 2012 16:57:08 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
	q55Gv3Xu010126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Jun 2012 16:57:03 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
	q55Guwkl032488; Tue, 5 Jun 2012 11:56:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Jun 2012 09:56:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DD7DF4030D; Tue,  5 Jun 2012 12:49:57 -0400 (EDT)
Date: Tue, 5 Jun 2012 12:49:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Message-ID: <20120605164957.GA1997@phenom.dumpdata.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FCA5608.2010404@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jun 02, 2012 at 11:36:00PM +0530, Srivatsa S. Bhat wrote:
> On 06/01/2012 09:06 PM, Jan Beulich wrote:
> 
> >>>> On 01.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> > wrote:
> >> On 06/01/2012 06:29 PM, Jan Beulich wrote:
> >>
> >>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> >>> wrote:
> >>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
> >>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
> >>>> suggests) is useful in the cpu bringup path.
> >>>
> >>> This might not be correct - the code as it is without this change is
> >>> safe even when the vCPU gets onlined back later by an external
> >>> entity (e.g. the Xen tool stack), and it would in that case resume
> >>> at the return point of the VCPUOP_down hypercall. That might
> >>> be a heritage from the original XenoLinux tree though, and be
> >>> meaningless in pv-ops context - Jeremy, Konrad?
> >>>
> >>> Possibly it was bogus/unused even in that original tree - Keir?
> >>>
> >>
> >>
> >> Thanks for your comments Jan!
> >>
> >> In case this change is wrong, the other method I had in mind was to call
> >> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
> >> in the sense that it runs the cpu bringup code including cpu_idle(), in the
> >> cpu offline path, namely the cpu_die() function). Would that approach work
> >> for xen as well? If yes, then we wouldn't have any issues to convert xen to
> >> generic code.
> > 
> > No, that wouldn't work either afaict - the function is expected
> > to return.
> > 
> 
> 
> Ok.. So, I would love to hear a confirmation about whether this patch (which
> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.

I think it will break - are these patches available on some git tree to test them out?

> 
> If its not correct, then we can probably make __cpu_post_online() return an int,
> with the meaning:
> 
> 0 => success, go ahead and call cpu_idle()
> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
> 
> So all other archs will return 0, Xen will return non-zero, and it will handle
> when to call cpu_idle() and when not to do so.

The call-chain (this is taken from 41bd956de3dfdc3a43708fe2e0c8096c69064a1e):

    cpu_bringup_and_idle:
     \- cpu_bringup
      |   \-[preempt_disable]
      |
      |- cpu_idle
           \- play_dead [assuming the user offlined the VCPU]
           |     \
           |     +- (xen_play_dead)
           |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
           |          |                       onlines it starts from here]
           |          \- cpu_bringup [preempt_disable]
           |
           +- preempt_enable_no_reschedule()
           +- schedule()
           \- preempt_enable()

Which I think is a bit different from your use-case?

> 
> Might sound a bit ugly, but I don't see much other option. Suggestions are
> appreciated!
> 
> Regards,
> Srivatsa S. Bhat

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLw-0005GM-2V; Wed, 06 Jun 2012 10:20:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1ScCWO-0002Jp-HV
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:27:20 +0000
Received: from [193.109.254.147:31287] by server-4.bemta-14.messagelabs.com id
	A9/D8-27598-7722FCF4; Wed, 06 Jun 2012 09:27:19 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1338974837!11163922!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24192 invoked from network); 6 Jun 2012 09:27:18 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:27:18 -0000
Received: by bkty5 with SMTP id y5so6793435bkt.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 02:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=MvoFDmpNAc3QdKmB4dpz9yck+JlJeG/EVOab2h/8FgQ=;
	b=Hn4UNPq2WBmoqdRPGhIuTAzF0SBJO7kz7vW6qIH+bNAfIfQtbf8tkvX7vNJjT8BiCD
	yJBH1AuT/Cq1D9llbA1SCVzjXvvgTNY1/kYKuz4X60LdBtO48nQbtwoFbcy0EeBU/1Gc
	o0XwvT3VKonfVpM7yC2Cr5n9DNhAkj81fSi0tVLNjbB8xkHhrZgtD7rwQgEC+f6HQIJa
	VOcZ+enW+QXbwvk99sHAXFMVga9hOxfKEKJ5UFZ2aVyDw9TnChJONySimfk6B+2ArWGi
	cFbpTO1s6swP6473neZsUoa/zQlYpDY0N6WyW+TlIxA31ngCKN1PQqsq+RqKHJNE1y1N
	K6dg==
Received: by 10.204.154.142 with SMTP id o14mr11006263bkw.116.1338974837461;
	Wed, 06 Jun 2012 02:27:17 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id n19sm1281328bkv.14.2012.06.06.02.27.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 02:27:16 -0700 (PDT)
Date: Wed, 6 Jun 2012 11:27:13 +0200
From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120606092713.GB9495@gmail.com>
References: <20120530150334.GA13349@jshin-Toonie>
	<20120530171754.GA5115@phenom.dumpdata.com>
	<20120530173247.GC15635@x1.osrc.amd.com>
	<4FC65D34.1060803@zytor.com>
	<20120530175150.GE15438@x1.osrc.amd.com>
	<4FC66037.6020506@zytor.com>
	<20120530181722.GF15438@x1.osrc.amd.com>
	<4FC664E1.9050504@zytor.com>
	<20120530223334.GB28417@andromeda.dapyr.net>
	<4FC6A897.6020005@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FC6A897.6020005@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:33 +0000
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, linux-kernel@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, mingo@elte.hu,
	tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD
 Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* H. Peter Anvin <hpa@zytor.com> wrote:

> On 05/30/2012 03:33 PM, Konrad Rzeszutek Wilk wrote:
> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index 75f33b2..e74df95 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
> >  	.wbinvd = native_wbinvd,
> >  
> >  	.read_msr = native_read_msr_safe,
> > +	.rdmsr_regs = native_rdmsr_safe_regs,
> >  	.write_msr = xen_write_msr_safe,
> > +	.wrmsr_regs = native_wrmsr_safe_regs,
> > +
> >  	.read_tsc = native_read_tsc,
> >  	.read_pmc = native_read_pmc,
> >  
> 
> Okay, tell me again:
> 
> why do we have these hooks again?  Can we please weed out 
> paravirt methods that have no users?

ping?

	Ingo

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLu-0005FK-Je; Wed, 06 Jun 2012 10:20: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 1Sbx5r-0004Ut-II
	for xen-devel@lists.xensource.com; Tue, 05 Jun 2012 16:58:55 +0000
Received: from [193.109.254.147:39911] by server-11.bemta-14.messagelabs.com
	id 5F/E5-02727-ECA3ECF4; Tue, 05 Jun 2012 16:58:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338915526!5238819!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTcwODUx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12152 invoked from network); 5 Jun 2012 16:58:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jun 2012 16:58:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q55Gv7oR030794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Jun 2012 16:57:08 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
	q55Gv3Xu010126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Jun 2012 16:57:03 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
	q55Guwkl032488; Tue, 5 Jun 2012 11:56:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Jun 2012 09:56:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DD7DF4030D; Tue,  5 Jun 2012 12:49:57 -0400 (EDT)
Date: Tue, 5 Jun 2012 12:49:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Message-ID: <20120605164957.GA1997@phenom.dumpdata.com>
References: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
	<20120601091124.31979.91984.stgit@srivatsabhat.in.ibm.com>
	<4FC8D8E30200007800087D2B@nat28.tlf.novell.com>
	<4FC8DC19.4000007@linux.vnet.ibm.com>
	<4FC8FD9C0200007800087DF5@nat28.tlf.novell.com>
	<4FCA5608.2010404@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FCA5608.2010404@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:32 +0000
Cc: linux-arch@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>, akpm@linux-foundation.org,
	nikunj@linux.vnet.ibm.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	vatsa@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org, rjw@sisk.pl,
	yong.zhang0@gmail.com, Ingo Molnar <mingo@redhat.com>,
	Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Keir Fraser <keir@xen.org>,
	Thomas Gleixner <tglx@linutronix.de>, paulmck@linux.vnet.ibm.com,
	mingo@kernel.org
Subject: Re: [Xen-devel] [PATCH 05/27] xen,
 cpu hotplug: Don't call cpu_bringup() in xen_play_dead()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jun 02, 2012 at 11:36:00PM +0530, Srivatsa S. Bhat wrote:
> On 06/01/2012 09:06 PM, Jan Beulich wrote:
> 
> >>>> On 01.06.12 at 17:13, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> > wrote:
> >> On 06/01/2012 06:29 PM, Jan Beulich wrote:
> >>
> >>>>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> >>> wrote:
> >>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
> >>>> is invoked in the cpu down path, whereas cpu_bringup() (as the name 
> >>>> suggests) is useful in the cpu bringup path.
> >>>
> >>> This might not be correct - the code as it is without this change is
> >>> safe even when the vCPU gets onlined back later by an external
> >>> entity (e.g. the Xen tool stack), and it would in that case resume
> >>> at the return point of the VCPUOP_down hypercall. That might
> >>> be a heritage from the original XenoLinux tree though, and be
> >>> meaningless in pv-ops context - Jeremy, Konrad?
> >>>
> >>> Possibly it was bogus/unused even in that original tree - Keir?
> >>>
> >>
> >>
> >> Thanks for your comments Jan!
> >>
> >> In case this change is wrong, the other method I had in mind was to call
> >> cpu_bringup_and_idle() in xen_play_dead(). (Even ARM does something similar,
> >> in the sense that it runs the cpu bringup code including cpu_idle(), in the
> >> cpu offline path, namely the cpu_die() function). Would that approach work
> >> for xen as well? If yes, then we wouldn't have any issues to convert xen to
> >> generic code.
> > 
> > No, that wouldn't work either afaict - the function is expected
> > to return.
> > 
> 
> 
> Ok.. So, I would love to hear a confirmation about whether this patch (which
> removes cpu_bringup() in xen_play_dead()) will break things or it is good as is.

I think it will break - are these patches available on some git tree to test them out?

> 
> If its not correct, then we can probably make __cpu_post_online() return an int,
> with the meaning:
> 
> 0 => success, go ahead and call cpu_idle()
> non-zero => stop here, thanks for your services so far.. now leave the rest to me.
> 
> So all other archs will return 0, Xen will return non-zero, and it will handle
> when to call cpu_idle() and when not to do so.

The call-chain (this is taken from 41bd956de3dfdc3a43708fe2e0c8096c69064a1e):

    cpu_bringup_and_idle:
     \- cpu_bringup
      |   \-[preempt_disable]
      |
      |- cpu_idle
           \- play_dead [assuming the user offlined the VCPU]
           |     \
           |     +- (xen_play_dead)
           |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
           |          |                       onlines it starts from here]
           |          \- cpu_bringup [preempt_disable]
           |
           +- preempt_enable_no_reschedule()
           +- schedule()
           \- preempt_enable()

Which I think is a bit different from your use-case?

> 
> Might sound a bit ugly, but I don't see much other option. Suggestions are
> appreciated!
> 
> Regards,
> Srivatsa S. Bhat

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:20:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:20: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 1ScDLw-0005GM-2V; Wed, 06 Jun 2012 10:20:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo.kernel.org@gmail.com>) id 1ScCWO-0002Jp-HV
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 09:27:20 +0000
Received: from [193.109.254.147:31287] by server-4.bemta-14.messagelabs.com id
	A9/D8-27598-7722FCF4; Wed, 06 Jun 2012 09:27:19 +0000
X-Env-Sender: mingo.kernel.org@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1338974837!11163922!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24192 invoked from network); 6 Jun 2012 09:27:18 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 09:27:18 -0000
Received: by bkty5 with SMTP id y5so6793435bkt.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 02:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=MvoFDmpNAc3QdKmB4dpz9yck+JlJeG/EVOab2h/8FgQ=;
	b=Hn4UNPq2WBmoqdRPGhIuTAzF0SBJO7kz7vW6qIH+bNAfIfQtbf8tkvX7vNJjT8BiCD
	yJBH1AuT/Cq1D9llbA1SCVzjXvvgTNY1/kYKuz4X60LdBtO48nQbtwoFbcy0EeBU/1Gc
	o0XwvT3VKonfVpM7yC2Cr5n9DNhAkj81fSi0tVLNjbB8xkHhrZgtD7rwQgEC+f6HQIJa
	VOcZ+enW+QXbwvk99sHAXFMVga9hOxfKEKJ5UFZ2aVyDw9TnChJONySimfk6B+2ArWGi
	cFbpTO1s6swP6473neZsUoa/zQlYpDY0N6WyW+TlIxA31ngCKN1PQqsq+RqKHJNE1y1N
	K6dg==
Received: by 10.204.154.142 with SMTP id o14mr11006263bkw.116.1338974837461;
	Wed, 06 Jun 2012 02:27:17 -0700 (PDT)
Received: from gmail.com (54033750.catv.pool.telekom.hu. [84.3.55.80])
	by mx.google.com with ESMTPS id n19sm1281328bkv.14.2012.06.06.02.27.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 02:27:16 -0700 (PDT)
Date: Wed, 6 Jun 2012 11:27:13 +0200
From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120606092713.GB9495@gmail.com>
References: <20120530150334.GA13349@jshin-Toonie>
	<20120530171754.GA5115@phenom.dumpdata.com>
	<20120530173247.GC15635@x1.osrc.amd.com>
	<4FC65D34.1060803@zytor.com>
	<20120530175150.GE15438@x1.osrc.amd.com>
	<4FC66037.6020506@zytor.com>
	<20120530181722.GF15438@x1.osrc.amd.com>
	<4FC664E1.9050504@zytor.com>
	<20120530223334.GB28417@andromeda.dapyr.net>
	<4FC6A897.6020005@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FC6A897.6020005@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 06 Jun 2012 10:20:33 +0000
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jacob Shin <jacob.shin@amd.com>, linux-kernel@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, mingo@elte.hu,
	tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD
 Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


* H. Peter Anvin <hpa@zytor.com> wrote:

> On 05/30/2012 03:33 PM, Konrad Rzeszutek Wilk wrote:
> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index 75f33b2..e74df95 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
> >  	.wbinvd = native_wbinvd,
> >  
> >  	.read_msr = native_read_msr_safe,
> > +	.rdmsr_regs = native_rdmsr_safe_regs,
> >  	.write_msr = xen_write_msr_safe,
> > +	.wrmsr_regs = native_wrmsr_safe_regs,
> > +
> >  	.read_tsc = native_read_tsc,
> >  	.read_pmc = native_read_pmc,
> >  
> 
> Okay, tell me again:
> 
> why do we have these hooks again?  Can we please weed out 
> paravirt methods that have no users?

ping?

	Ingo

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDSk-0007Dm-4S; Wed, 06 Jun 2012 10:27: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 1ScDSi-0007DH-Fb
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:27:36 +0000
Received: from [85.158.138.51:54107] by server-5.bemta-3.messagelabs.com id
	00/67-03598-5903FCF4; Wed, 06 Jun 2012 10:27:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1338978452!31076257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 6 Jun 2012 10:27:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:27:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:27:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:27:32 +0100
Message-ID: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Jun 2012 11:27:31 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release / TODO 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UG9zdGluZyBhIGJpdCBsYXRlIHRoaXMgd2VlaywgZHVlIHRvIHB1YmxpYyBob2xpZGF5cyBpbiB0
aGUgVUsuIAoKSSdtIG9uIHZhY2F0aW9uIHRoZSBuZXh0IHR3byBNb25kYXlzIHNvIGl0IHdpbGwg
YmUgbGF0ZSB0aGVuIHRvby4KClBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54
ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhl
IHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgoKMTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBs
b2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAgLS0gRmVhdHVyZSBGcmVlemUKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJ
dCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBS
Q04rMSB1bnRpbCByZWxlYXNlCgpJJ20gbm90IGdvaW5nIGdldCBjYXVnaHQgb3V0IG1ha2luZyBh
bm90aGVyIGd1ZXNzIGF0IHdoZW4gd2Ugc3RhcnQKUkNzLCBsZXRzIGp1c3QgZ28gd2l0aCAid2hl
biBpdCdzIHJlYWR5IiA7LSkuIEkgdGhpbmsgd2UgYXJlIGVkZ2luZyBjbG9zZXIuLi4KClRoZSB1
cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLiBQZXIgdGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBj
YXNlIHdpbGwKbm93IGhhdmUgdG8gYmUgbWFkZSBhcyB0byB3aHkgbmV3IGl0ZW1zIHNob3VsZCBi
ZSBhZGRlZCB0byB0aGUgbGlzdCwKZXNwZWNpYWxseSBhcyBhIGJsb2NrZXIsIHJhdGhlciB0aGFu
IGRlZmVycmVkIHRvIDQuMy4KCklmIHlvdSBhcmUgYXdhcmUgb2YgYW55IGJ1Z3Mgd2hpY2ggbXVz
dC9zaG91bGQgYmUgZml4ZWQgZm9yIDQuMiB0aGVuCnBsZWFzZSByZXBseSB0byB0aGlzIHRocmVh
ZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJlciB0byBwaWNrIHRoZW0KdXAgbmV4dCB3ZWVr
KQoKT3RoZXIgdGhhbiB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnNpZGVyIHRoZSBmcmVlemUg
dG8gYmUgaW4gZnVsbAplZmZlY3QgYW5kIHRoZSBiYXIgdG8gZW50cnkgdG8gNC4yIHRvIGJlIHZl
cnkgaGlnaC4KCmh5cGVydmlzb3IsIGJsb2NrZXJzOgoKICAgICogTm9uZQogCnRvb2xzLCBibG9j
a2VyczoKCiAgICAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVm
aW5lIGEgc3RhYmxlIEFQSQogICAgICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJl
bHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCiAgICAgIHRoaXMgYXJlOgoKICAgICAgICAq
IExJQlhMX05JQ19UWVBFIGVudW0gbmFtZXMgYXJlIGNvbmZ1c2luZy4KCiAgICAgICAgKiBJbnRl
cmZhY2VzIHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgoKICAgICAgICAgICAgKiBsaWJ4bF9k
b21haW5fc3VzcGVuZC4gTW92ZSB4Y19kb21haW5fc2F2ZS9yZXN0b3JlIGludG8gYQogICAgICAg
ICAgICAgIHNlcGFyYXRlIHByb2Nlc3MgKElhbkosIHBhdGNoZXMgcG9zdGVkKS4KCiAgICAgICAg
ICAgICogbGlieGxfZGV2aWNlX3tkaXNrLG5pYyx2a2IsYWRkLHBjaX1fYWRkIChhbmQKICAgICAg
ICAgICAgICByZW1vdmUpLiAoUm9nZXIsIHBhdGNoZXMgcG9zdGVkIGZvciBkaXNrICYgbmljLCB2
a2IKICAgICAgICAgICAgICB0cml2aWFsLCBub3QgbG9va2VkIGF0IHBjaSB5ZXQpCgogICAgICAg
ICogdXNlIGxpYnhsX2NwdW1hcCBmb3IgYl9pbmZvLmF2YWlsX2NwdXMgaW5zdGVhZCBvZiBhbiBp
bnQsCiAgICAgICAgICB0aGlzImFsbG93cyBzZXR0aW5nIG1vcmUgdGhhbiAzMSBDUFVTIChZYW5n
IFogWmhhbmcsIHBhdGNoZXMKICAgICAgICAgIHBvc3RlZCkKCiAgICAgICAgKiB1c2UgYW4gZW51
bSBmb3IgVkdBIGludGVyZmFjZSB0eXBlIChlLmcuIENpcnJ1cywKICAgICAgICAgIFN0ZFZHQSku
IEFsbG93cyBmb3IgUVhMIHN1cHBvcnQgKGluIDQuMykuIChaaG91IFBlbmcsCiAgICAgICAgICBw
YXRjaGVzIHBvc3RlZCkKCiAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAg
KiBbQlVHXSBjYW5ub3QgY3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZSBvbiBIVk0gZ3Vlc3Qs
CiAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGluIDw0Rjk2NzJERC4yMDgwOTAy
QHRpc2NhbGkuaXQ+CgogICAgICAgICogZG9lcyBub3QgYXV0b21hdGljYWxseSB0cnkgdG8gc2Vs
ZWN0IGEgKHNldCBvZikgbm9kZShzKSBvbgogICAgICAgICAgd2hpY2ggdG8gY3JlYXRlIGEgVk0g
YW5kIHBpbiBpdHMgdmNwdXMgdGhlcmUuIChEYXJpbwogICAgICAgICAgRmFnZ2lvbGksIHBhdGNo
ZXMgcmVwb3N0ZWQsIHVuZGVyIHJldmlldykKCiAgICAqIFtCVUddIFNwdXJpb3VzIENQVSBwYXJh
bXMgZXJyb3IgbWVzc2FnZSB3aGVuIHN0YXJ0aW5nIGEgZG9tYWluLAogICAgICBlLmcuICJDcHUg
d2VpZ2h0IG91dCBvZiByYW5nZSwgdmFsaWQgdmFsdWVzIGFyZSB3aXRoaW4gcmFuZ2UKICAgICAg
ZnJvbSAxIHRvIDY1NTM1Ii4gKElhbiBDLCBET05FKQoKICAgICogTW9yZSBmb3JtYWxseSBkZXBy
ZWNhdGUgeG0veGVuZC4gTWFucGFnZSBwYXRjaGVzIGFscmVhZHkgaW4KICAgICAgdHJlZS4gTmVl
ZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KICAgICAg
cmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgoKICAgICogRG9tYWluIDAgYmxvY2sgYXR0YWNoICYg
Z2VuZXJhbCBob3RwbHVnIHdoZW4gdXNpbmcgcWRpc2sgYmFja2VuZAogICAgICAobmVlZCB0byBz
dGFydCBxZW11IGFzIG5lY2Vzc2FyeSBldGMpIChTdGVmYW5vIFMsIERPTkUpCgogICAgKiBjYWxs
aW5nIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsIChMaW51eCBhbmQgTmV0QlNEKSAoUm9nZXIgUGF1
CiAgICAgIE1vbm7DqSwgcGF0Y2hlcyBwb3N0ZWQsIG5lYXJpbmcgY29tcGxldGlvbj8pCgogICAg
KiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9uIGZyb20gaG90cGx1ZyBzY3JpcHQg
KFJvZ2VyCiAgICAgIFBhdSBNb25uw6ksICJqdXN0IGJlIGEgbWF0dGVyIG9mIHJlbW92aW5nIGFu
ICJpZiIiKQoKICAgICogQWRqdXN0bWVudHMgbmVlZGVkIGZvciBxZGlzayBiYWNrZW5kIHRvIHdv
cmsgb24gbm9uLXB2b3BzIExpbnV4LgogICAgICAicWVtdS94ZW5kaXNrOiBzZXQgbWF4aW11bSBu
dW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4gQmV1bGljaCkKCiAgICAqIENvbmZpcm0g
dGhhdCBtaWdyYXRpb24gZnJvbSBYZW4gNC4xIC0+IDQuMiB3b3Jrcy4uLgoKICAgICogW0JVR10g
QnVpbGQgZmFpbHVyZSBkdWUgdG8gZ2NjIC1Xc3dpdGNoIG9uIHNvbWUgZGlzdHJvcwogICAgICB2
cy4gTElCWExfRE9NQUlOX1RZUEUuIChEYXJpbyBGYWdnaW9saSwgcGF0Y2hlcyBwb3N0ZWQpCgpo
eXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6CgogICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1l
bnRzIChHZW9yZ2UgRHVubGFwKQoKdG9vbHMsIG5pY2UgdG8gaGF2ZToKCiAgICAqIHhsIGNvbXBh
dGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAgKiBBY2NlcHQgInhsIGNyIC9kZXYvbnVsbCBwYXJh
bT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29uZmlnCiAgICAgICAgICBvbiB0aGUgY29tbWFuZCBs
aW5lICgJVy4gTWljaGFlbCBQZXR1bGxvLCBwYXRjaCBwb3N0ZWQpCgogICAgKiBsaWJ4bDogQWRk
IEFQSSB0byByZXRyaWV2ZSBkb21haW4gY29uc29sZSB0dHkgKEJhbXZvciBKaWFuCiAgICAgIFpo
YW5nLCBwYXRjaGVzIHBvc3RlZCkKCiAgICAqIGxpYnhsIHN0YWJsZSBBUEkKCiAgICAgICAgKiBs
aWJ4bF8qX3BhdGguIE1ham9yaXR5IG1hZGUgaW50ZXJuYWwsIG9ubHkgY29uZmlnZGlyIGFuZAog
ICAgICAgICAgbG9ja2RpciByZW1haW4gcHVibGljLiBVc2VkIGJ5IHhsIHRoZXJlZm9yZSBtb3Zl
IHRvIHhsPwogICAgICAgICAgKElhbkMsIERPTkUpCgogICAgICAgICogbGlieGxfd2FpdF9mb3Jf
ZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5X3RhcmdldC4KICAgICAgICAgIEludGVy
ZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRlZCB0bwogICAgICAgICAgbG9ja2luZy9zZXJp
YWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0ZSAoZGVmZXJyZWQgdG8KICAgICAgICAgIDQuMyku
IElhbkogdG8gYWRkIG5vdGUgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVpbmcKICAgICAgICAgIHN1
YnN0YW5kYXJkIGJ1dCBvdGhlcndpc2UgZGVmZXIgdG8gNC4zLgoKICAgICAgICAqIEludGVyZmFj
ZXMgd2hpY2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAgICAqIGxpYnhsX2Nkcm9t
X2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQogICAgICAgICAgICAgIGRpc2tfe2FkZCxyZW1v
dmV9IGRvbmUuIFRoaXMgaXMgYmFzaWNhbGx5IGEgaGVscGVyCiAgICAgICAgICAgICAgZnVuY3Rp
b24gYW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRlZCBpbgogICAgICAgICAg
ICAgIHRlcm1zIG9mIHRoZSBsaWJ4bF9kaXNrXyogaW50ZXJmYWNlcy4gSWYgdGhpcyBpcyBub3QK
ICAgICAgICAgICAgICBkb25lIGluIHRpbWUgd2Ugc2hvdWxkIGRvY3VtZW50IGFzIGEgc3Vic3Rh
bmRhcmQKICAgICAgICAgICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3ViamVjdCB0byBjaGFuZ2Ug
cG9zdCA0LjIuCgogICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBwYXRjaCBmb3IgcWVtdS11
cHN0cmVhbQogICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0OgogICAgICBodHRwOi8vbGlz
dHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1L21zZzAwMjUwLmh0bWwK
ICAgICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lmeWluZyB2aWRlb21lbSBz
aXplIGZvciB0aGUKICAgICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29y
a3Mgd2l0aAogICAgICBxZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNpIEvDpHJra8OkaW5lbikK
CiAgICAqIHFlbXUtdXBzdHJlYW0gZm9yIE5ldEJTRCAoUm9nZXIpCgogICAgKiBbQlVHXSBsb25n
IHN0b3AgZHVyaW5nIHRoZSBndWVzdCBib290IHByb2Nlc3Mgd2l0aCBxY293IGltYWdlLAogICAg
ICByZXBvcnRlZCBieSBJbnRlbDogaHR0cDovL2J1Z3ppbGxhLnhlbi5vcmcvYnVnemlsbGEvc2hv
d19idWcuY2dpP2lkPTE4MjEKCiAgICAqIFtCVUddIHZjcHUtc2V0IGRvZXNuJ3QgdGFrZSBlZmZl
Y3Qgb24gZ3Vlc3QsIHJlcG9ydGVkIGJ5IEludGVsOgogICAgICBodHRwOi8vYnVnemlsbGEueGVu
Lm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MTgyMgoKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDSk-0007Dm-4S; Wed, 06 Jun 2012 10:27: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 1ScDSi-0007DH-Fb
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:27:36 +0000
Received: from [85.158.138.51:54107] by server-5.bemta-3.messagelabs.com id
	00/67-03598-5903FCF4; Wed, 06 Jun 2012 10:27:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1338978452!31076257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 6 Jun 2012 10:27:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:27:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:27:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:27:32 +0100
Message-ID: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Jun 2012 11:27:31 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release / TODO 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UG9zdGluZyBhIGJpdCBsYXRlIHRoaXMgd2VlaywgZHVlIHRvIHB1YmxpYyBob2xpZGF5cyBpbiB0
aGUgVUsuIAoKSSdtIG9uIHZhY2F0aW9uIHRoZSBuZXh0IHR3byBNb25kYXlzIHNvIGl0IHdpbGwg
YmUgbGF0ZSB0aGVuIHRvby4KClBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54
ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhl
IHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgoKMTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBs
b2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAgLS0gRmVhdHVyZSBGcmVlemUKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJ
dCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBS
Q04rMSB1bnRpbCByZWxlYXNlCgpJJ20gbm90IGdvaW5nIGdldCBjYXVnaHQgb3V0IG1ha2luZyBh
bm90aGVyIGd1ZXNzIGF0IHdoZW4gd2Ugc3RhcnQKUkNzLCBsZXRzIGp1c3QgZ28gd2l0aCAid2hl
biBpdCdzIHJlYWR5IiA7LSkuIEkgdGhpbmsgd2UgYXJlIGVkZ2luZyBjbG9zZXIuLi4KClRoZSB1
cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLiBQZXIgdGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBj
YXNlIHdpbGwKbm93IGhhdmUgdG8gYmUgbWFkZSBhcyB0byB3aHkgbmV3IGl0ZW1zIHNob3VsZCBi
ZSBhZGRlZCB0byB0aGUgbGlzdCwKZXNwZWNpYWxseSBhcyBhIGJsb2NrZXIsIHJhdGhlciB0aGFu
IGRlZmVycmVkIHRvIDQuMy4KCklmIHlvdSBhcmUgYXdhcmUgb2YgYW55IGJ1Z3Mgd2hpY2ggbXVz
dC9zaG91bGQgYmUgZml4ZWQgZm9yIDQuMiB0aGVuCnBsZWFzZSByZXBseSB0byB0aGlzIHRocmVh
ZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJlciB0byBwaWNrIHRoZW0KdXAgbmV4dCB3ZWVr
KQoKT3RoZXIgdGhhbiB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnNpZGVyIHRoZSBmcmVlemUg
dG8gYmUgaW4gZnVsbAplZmZlY3QgYW5kIHRoZSBiYXIgdG8gZW50cnkgdG8gNC4yIHRvIGJlIHZl
cnkgaGlnaC4KCmh5cGVydmlzb3IsIGJsb2NrZXJzOgoKICAgICogTm9uZQogCnRvb2xzLCBibG9j
a2VyczoKCiAgICAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVm
aW5lIGEgc3RhYmxlIEFQSQogICAgICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJl
bHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCiAgICAgIHRoaXMgYXJlOgoKICAgICAgICAq
IExJQlhMX05JQ19UWVBFIGVudW0gbmFtZXMgYXJlIGNvbmZ1c2luZy4KCiAgICAgICAgKiBJbnRl
cmZhY2VzIHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgoKICAgICAgICAgICAgKiBsaWJ4bF9k
b21haW5fc3VzcGVuZC4gTW92ZSB4Y19kb21haW5fc2F2ZS9yZXN0b3JlIGludG8gYQogICAgICAg
ICAgICAgIHNlcGFyYXRlIHByb2Nlc3MgKElhbkosIHBhdGNoZXMgcG9zdGVkKS4KCiAgICAgICAg
ICAgICogbGlieGxfZGV2aWNlX3tkaXNrLG5pYyx2a2IsYWRkLHBjaX1fYWRkIChhbmQKICAgICAg
ICAgICAgICByZW1vdmUpLiAoUm9nZXIsIHBhdGNoZXMgcG9zdGVkIGZvciBkaXNrICYgbmljLCB2
a2IKICAgICAgICAgICAgICB0cml2aWFsLCBub3QgbG9va2VkIGF0IHBjaSB5ZXQpCgogICAgICAg
ICogdXNlIGxpYnhsX2NwdW1hcCBmb3IgYl9pbmZvLmF2YWlsX2NwdXMgaW5zdGVhZCBvZiBhbiBp
bnQsCiAgICAgICAgICB0aGlzImFsbG93cyBzZXR0aW5nIG1vcmUgdGhhbiAzMSBDUFVTIChZYW5n
IFogWmhhbmcsIHBhdGNoZXMKICAgICAgICAgIHBvc3RlZCkKCiAgICAgICAgKiB1c2UgYW4gZW51
bSBmb3IgVkdBIGludGVyZmFjZSB0eXBlIChlLmcuIENpcnJ1cywKICAgICAgICAgIFN0ZFZHQSku
IEFsbG93cyBmb3IgUVhMIHN1cHBvcnQgKGluIDQuMykuIChaaG91IFBlbmcsCiAgICAgICAgICBw
YXRjaGVzIHBvc3RlZCkKCiAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAg
KiBbQlVHXSBjYW5ub3QgY3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZSBvbiBIVk0gZ3Vlc3Qs
CiAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGluIDw0Rjk2NzJERC4yMDgwOTAy
QHRpc2NhbGkuaXQ+CgogICAgICAgICogZG9lcyBub3QgYXV0b21hdGljYWxseSB0cnkgdG8gc2Vs
ZWN0IGEgKHNldCBvZikgbm9kZShzKSBvbgogICAgICAgICAgd2hpY2ggdG8gY3JlYXRlIGEgVk0g
YW5kIHBpbiBpdHMgdmNwdXMgdGhlcmUuIChEYXJpbwogICAgICAgICAgRmFnZ2lvbGksIHBhdGNo
ZXMgcmVwb3N0ZWQsIHVuZGVyIHJldmlldykKCiAgICAqIFtCVUddIFNwdXJpb3VzIENQVSBwYXJh
bXMgZXJyb3IgbWVzc2FnZSB3aGVuIHN0YXJ0aW5nIGEgZG9tYWluLAogICAgICBlLmcuICJDcHUg
d2VpZ2h0IG91dCBvZiByYW5nZSwgdmFsaWQgdmFsdWVzIGFyZSB3aXRoaW4gcmFuZ2UKICAgICAg
ZnJvbSAxIHRvIDY1NTM1Ii4gKElhbiBDLCBET05FKQoKICAgICogTW9yZSBmb3JtYWxseSBkZXBy
ZWNhdGUgeG0veGVuZC4gTWFucGFnZSBwYXRjaGVzIGFscmVhZHkgaW4KICAgICAgdHJlZS4gTmVl
ZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KICAgICAg
cmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgoKICAgICogRG9tYWluIDAgYmxvY2sgYXR0YWNoICYg
Z2VuZXJhbCBob3RwbHVnIHdoZW4gdXNpbmcgcWRpc2sgYmFja2VuZAogICAgICAobmVlZCB0byBz
dGFydCBxZW11IGFzIG5lY2Vzc2FyeSBldGMpIChTdGVmYW5vIFMsIERPTkUpCgogICAgKiBjYWxs
aW5nIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsIChMaW51eCBhbmQgTmV0QlNEKSAoUm9nZXIgUGF1
CiAgICAgIE1vbm7DqSwgcGF0Y2hlcyBwb3N0ZWQsIG5lYXJpbmcgY29tcGxldGlvbj8pCgogICAg
KiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9uIGZyb20gaG90cGx1ZyBzY3JpcHQg
KFJvZ2VyCiAgICAgIFBhdSBNb25uw6ksICJqdXN0IGJlIGEgbWF0dGVyIG9mIHJlbW92aW5nIGFu
ICJpZiIiKQoKICAgICogQWRqdXN0bWVudHMgbmVlZGVkIGZvciBxZGlzayBiYWNrZW5kIHRvIHdv
cmsgb24gbm9uLXB2b3BzIExpbnV4LgogICAgICAicWVtdS94ZW5kaXNrOiBzZXQgbWF4aW11bSBu
dW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4gQmV1bGljaCkKCiAgICAqIENvbmZpcm0g
dGhhdCBtaWdyYXRpb24gZnJvbSBYZW4gNC4xIC0+IDQuMiB3b3Jrcy4uLgoKICAgICogW0JVR10g
QnVpbGQgZmFpbHVyZSBkdWUgdG8gZ2NjIC1Xc3dpdGNoIG9uIHNvbWUgZGlzdHJvcwogICAgICB2
cy4gTElCWExfRE9NQUlOX1RZUEUuIChEYXJpbyBGYWdnaW9saSwgcGF0Y2hlcyBwb3N0ZWQpCgpo
eXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6CgogICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1l
bnRzIChHZW9yZ2UgRHVubGFwKQoKdG9vbHMsIG5pY2UgdG8gaGF2ZToKCiAgICAqIHhsIGNvbXBh
dGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAgKiBBY2NlcHQgInhsIGNyIC9kZXYvbnVsbCBwYXJh
bT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29uZmlnCiAgICAgICAgICBvbiB0aGUgY29tbWFuZCBs
aW5lICgJVy4gTWljaGFlbCBQZXR1bGxvLCBwYXRjaCBwb3N0ZWQpCgogICAgKiBsaWJ4bDogQWRk
IEFQSSB0byByZXRyaWV2ZSBkb21haW4gY29uc29sZSB0dHkgKEJhbXZvciBKaWFuCiAgICAgIFpo
YW5nLCBwYXRjaGVzIHBvc3RlZCkKCiAgICAqIGxpYnhsIHN0YWJsZSBBUEkKCiAgICAgICAgKiBs
aWJ4bF8qX3BhdGguIE1ham9yaXR5IG1hZGUgaW50ZXJuYWwsIG9ubHkgY29uZmlnZGlyIGFuZAog
ICAgICAgICAgbG9ja2RpciByZW1haW4gcHVibGljLiBVc2VkIGJ5IHhsIHRoZXJlZm9yZSBtb3Zl
IHRvIHhsPwogICAgICAgICAgKElhbkMsIERPTkUpCgogICAgICAgICogbGlieGxfd2FpdF9mb3Jf
ZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5X3RhcmdldC4KICAgICAgICAgIEludGVy
ZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRlZCB0bwogICAgICAgICAgbG9ja2luZy9zZXJp
YWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0ZSAoZGVmZXJyZWQgdG8KICAgICAgICAgIDQuMyku
IElhbkogdG8gYWRkIG5vdGUgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVpbmcKICAgICAgICAgIHN1
YnN0YW5kYXJkIGJ1dCBvdGhlcndpc2UgZGVmZXIgdG8gNC4zLgoKICAgICAgICAqIEludGVyZmFj
ZXMgd2hpY2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAgICAqIGxpYnhsX2Nkcm9t
X2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQogICAgICAgICAgICAgIGRpc2tfe2FkZCxyZW1v
dmV9IGRvbmUuIFRoaXMgaXMgYmFzaWNhbGx5IGEgaGVscGVyCiAgICAgICAgICAgICAgZnVuY3Rp
b24gYW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRlZCBpbgogICAgICAgICAg
ICAgIHRlcm1zIG9mIHRoZSBsaWJ4bF9kaXNrXyogaW50ZXJmYWNlcy4gSWYgdGhpcyBpcyBub3QK
ICAgICAgICAgICAgICBkb25lIGluIHRpbWUgd2Ugc2hvdWxkIGRvY3VtZW50IGFzIGEgc3Vic3Rh
bmRhcmQKICAgICAgICAgICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3ViamVjdCB0byBjaGFuZ2Ug
cG9zdCA0LjIuCgogICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBwYXRjaCBmb3IgcWVtdS11
cHN0cmVhbQogICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0OgogICAgICBodHRwOi8vbGlz
dHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1L21zZzAwMjUwLmh0bWwK
ICAgICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lmeWluZyB2aWRlb21lbSBz
aXplIGZvciB0aGUKICAgICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29y
a3Mgd2l0aAogICAgICBxZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNpIEvDpHJra8OkaW5lbikK
CiAgICAqIHFlbXUtdXBzdHJlYW0gZm9yIE5ldEJTRCAoUm9nZXIpCgogICAgKiBbQlVHXSBsb25n
IHN0b3AgZHVyaW5nIHRoZSBndWVzdCBib290IHByb2Nlc3Mgd2l0aCBxY293IGltYWdlLAogICAg
ICByZXBvcnRlZCBieSBJbnRlbDogaHR0cDovL2J1Z3ppbGxhLnhlbi5vcmcvYnVnemlsbGEvc2hv
d19idWcuY2dpP2lkPTE4MjEKCiAgICAqIFtCVUddIHZjcHUtc2V0IGRvZXNuJ3QgdGFrZSBlZmZl
Y3Qgb24gZ3Vlc3QsIHJlcG9ydGVkIGJ5IEludGVsOgogICAgICBodHRwOi8vYnVnemlsbGEueGVu
Lm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MTgyMgoKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:34:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDZL-00083T-TT; Wed, 06 Jun 2012 10:34:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScDZK-00083C-GO
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:34:26 +0000
Received: from [85.158.143.35:48230] by server-2.bemta-4.messagelabs.com id
	E8/98-17938-1323FCF4; Wed, 06 Jun 2012 10:34:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338978865!19001622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17946 invoked from network); 6 Jun 2012 10:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:34:25 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:34:24 +0100
Date: Wed, 6 Jun 2012 11:34:18 +0100
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: <1338972636.32319.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206061131090.6030@kaball.uk.xensource.com>
References: <assp.0501a9d0b5.4FCB71EC020000C900015D24@smtp.seq.org>
	<1338972636.32319.12.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-users@lists.xen.org" <xen-users@lists.xen.org>,
	Will McDermott <wmcdermott@seq.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen unstable fails to build on ubutnu
	12.04
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> On Sun, 2012-06-03 at 22:16 +0100, Will McDermott wrote:
> > Hello,
> > 
> > I am trying to compile xen 4.2 unstable from mercurial. I can't get past
> > the make tools step. When I run make tools, the build fails with:
> 
> Thanks Will, this looks like a new one, I've not noticed any reports of
> this before. CCing xen-devel@ and our Qemu folks.
> 
> Guys, this looks like
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html or
> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/930181 (which
> Will references below). I didn't look if any patch has gone in upstream
> or not.
> 
> I can't explain why other Ubuntu users aren't seeing this though.

You must have libcap and libattr installed, because that's what it takes
to enable virtfs in QEMU by default.
And virtfs at the moment doesn't compile without that patch.

I'll ping the QEMU maintainers about it, and also submit a patch to our
build system to disable virtfs.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:34:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDZL-00083T-TT; Wed, 06 Jun 2012 10:34:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScDZK-00083C-GO
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:34:26 +0000
Received: from [85.158.143.35:48230] by server-2.bemta-4.messagelabs.com id
	E8/98-17938-1323FCF4; Wed, 06 Jun 2012 10:34:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338978865!19001622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17946 invoked from network); 6 Jun 2012 10:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:34:25 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:34:24 +0100
Date: Wed, 6 Jun 2012 11:34:18 +0100
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: <1338972636.32319.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206061131090.6030@kaball.uk.xensource.com>
References: <assp.0501a9d0b5.4FCB71EC020000C900015D24@smtp.seq.org>
	<1338972636.32319.12.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-users@lists.xen.org" <xen-users@lists.xen.org>,
	Will McDermott <wmcdermott@seq.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen unstable fails to build on ubutnu
	12.04
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> On Sun, 2012-06-03 at 22:16 +0100, Will McDermott wrote:
> > Hello,
> > 
> > I am trying to compile xen 4.2 unstable from mercurial. I can't get past
> > the make tools step. When I run make tools, the build fails with:
> 
> Thanks Will, this looks like a new one, I've not noticed any reports of
> this before. CCing xen-devel@ and our Qemu folks.
> 
> Guys, this looks like
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html or
> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/930181 (which
> Will references below). I didn't look if any patch has gone in upstream
> or not.
> 
> I can't explain why other Ubuntu users aren't seeing this though.

You must have libcap and libattr installed, because that's what it takes
to enable virtfs in QEMU by default.
And virtfs at the moment doesn't compile without that patch.

I'll ping the QEMU maintainers about it, and also submit a patch to our
build system to disable virtfs.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:36:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDao-0008LT-W7; Wed, 06 Jun 2012 10:35: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 1ScDao-0008L5-1I
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:35:58 +0000
Received: from [85.158.139.83:29901] by server-4.bemta-5.messagelabs.com id
	17/8C-05858-D823FCF4; Wed, 06 Jun 2012 10:35:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1338978956!31363958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20130 invoked from network); 6 Jun 2012 10:35:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855469"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10: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.213.0; Wed, 6 Jun 2012
	11:35:37 +0100
Message-ID: <1338978936.32319.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 11:35:36 +0100
In-Reply-To: <3eadab19abd49fbc6f56.1338818483@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-04 at 15:01 +0100, Dario Faggioli wrote:
> As we do it in the implementation of `xl sched-sedf -d ...', some
> consistency checking is needed while parsing the sedf scheduling
> parameters provided via config file. Not doing this results in the call
> libxl_domain_sched_params_set() to fail, and no parameters being
> enforced for the domain.
> 
> Note we do this at config file parsing time as that gives us the chance
> of bailing out early. It would have been pointless to add it within
> sched_sedf_domain_set() (in libxl), as the very same thing is
> done in the hypervisor, and the result is being checked and returned
> to the caller already.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> 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
> @@ -561,6 +561,7 @@ static void parse_config_data(const char
>      long l;
>      XLU_Config *config;
>      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> +    int opt_w = 0, opt_p = 0, opt_s = 0;

These names don't make much sense in this context.

Perhaps you can just check each interesting option against the
corresponding LIBXL_DOAIN_SCHED_PARAM_DEFAULT? That might make some long
lines. Perhaps pulling this out into a separate valid_sched_params()
would help with that?

>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 1;
>      int pci_permissive = 0;
> @@ -632,18 +633,36 @@ static void parse_config_data(const char
>  
>      /* the following is the actual config parsing with overriding
>       * values in the structures */
> -    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
> +    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) {
>          b_info->sched_params.weight = l;
> +        opt_w = 1;
> +    }
>      if (!xlu_cfg_get_long (config, "cap", &l, 0))
>          b_info->sched_params.cap = l;
> -    if (!xlu_cfg_get_long (config, "period", &l, 0))
> +    if (!xlu_cfg_get_long (config, "period", &l, 0)) {
>          b_info->sched_params.period = l;
> -    if (!xlu_cfg_get_long (config, "slice", &l, 0))
> +        opt_p = 1;
> +    }
> +    if (!xlu_cfg_get_long (config, "slice", &l, 0)) {
>          b_info->sched_params.slice = l;
> +        opt_s = 1;
> +    }
>      if (!xlu_cfg_get_long (config, "latency", &l, 0))
>          b_info->sched_params.latency = l;
>      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
>          b_info->sched_params.extratime = l;
> +    /* The sedf scheduler needs some more consistency checking */
> +    if (opt_w && (opt_p || opt_s)) {
> +        fprintf(stderr, "Either specify a weight OR a period and slice\n");

Does this constrain you from setting valid combinations of credit*
parameters? I think not since period and slice are SEDF specific.


> +        exit(1);
> +    }
> +    if (opt_w) {
> +        b_info->sched_params.slice = 0;
> +        b_info->sched_params.period = 0;
> +    }
> +    if (opt_p || opt_s)
> +        b_info->sched_params.weight = 0;
> +
>  
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:36:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDao-0008LT-W7; Wed, 06 Jun 2012 10:35: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 1ScDao-0008L5-1I
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:35:58 +0000
Received: from [85.158.139.83:29901] by server-4.bemta-5.messagelabs.com id
	17/8C-05858-D823FCF4; Wed, 06 Jun 2012 10:35:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1338978956!31363958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20130 invoked from network); 6 Jun 2012 10:35:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855469"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10: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.213.0; Wed, 6 Jun 2012
	11:35:37 +0100
Message-ID: <1338978936.32319.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 11:35:36 +0100
In-Reply-To: <3eadab19abd49fbc6f56.1338818483@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-04 at 15:01 +0100, Dario Faggioli wrote:
> As we do it in the implementation of `xl sched-sedf -d ...', some
> consistency checking is needed while parsing the sedf scheduling
> parameters provided via config file. Not doing this results in the call
> libxl_domain_sched_params_set() to fail, and no parameters being
> enforced for the domain.
> 
> Note we do this at config file parsing time as that gives us the chance
> of bailing out early. It would have been pointless to add it within
> sched_sedf_domain_set() (in libxl), as the very same thing is
> done in the hypervisor, and the result is being checked and returned
> to the caller already.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> 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
> @@ -561,6 +561,7 @@ static void parse_config_data(const char
>      long l;
>      XLU_Config *config;
>      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> +    int opt_w = 0, opt_p = 0, opt_s = 0;

These names don't make much sense in this context.

Perhaps you can just check each interesting option against the
corresponding LIBXL_DOAIN_SCHED_PARAM_DEFAULT? That might make some long
lines. Perhaps pulling this out into a separate valid_sched_params()
would help with that?

>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 1;
>      int pci_permissive = 0;
> @@ -632,18 +633,36 @@ static void parse_config_data(const char
>  
>      /* the following is the actual config parsing with overriding
>       * values in the structures */
> -    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0))
> +    if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) {
>          b_info->sched_params.weight = l;
> +        opt_w = 1;
> +    }
>      if (!xlu_cfg_get_long (config, "cap", &l, 0))
>          b_info->sched_params.cap = l;
> -    if (!xlu_cfg_get_long (config, "period", &l, 0))
> +    if (!xlu_cfg_get_long (config, "period", &l, 0)) {
>          b_info->sched_params.period = l;
> -    if (!xlu_cfg_get_long (config, "slice", &l, 0))
> +        opt_p = 1;
> +    }
> +    if (!xlu_cfg_get_long (config, "slice", &l, 0)) {
>          b_info->sched_params.slice = l;
> +        opt_s = 1;
> +    }
>      if (!xlu_cfg_get_long (config, "latency", &l, 0))
>          b_info->sched_params.latency = l;
>      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
>          b_info->sched_params.extratime = l;
> +    /* The sedf scheduler needs some more consistency checking */
> +    if (opt_w && (opt_p || opt_s)) {
> +        fprintf(stderr, "Either specify a weight OR a period and slice\n");

Does this constrain you from setting valid combinations of credit*
parameters? I think not since period and slice are SEDF specific.


> +        exit(1);
> +    }
> +    if (opt_w) {
> +        b_info->sched_params.slice = 0;
> +        b_info->sched_params.period = 0;
> +    }
> +    if (opt_p || opt_s)
> +        b_info->sched_params.weight = 0;
> +
>  
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:37:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDcc-0000Dk-Mw; Wed, 06 Jun 2012 10:37:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScDcb-0000DY-4k
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:37:49 +0000
Received: from [193.109.254.147:29663] by server-10.bemta-14.messagelabs.com
	id 93/39-25709-CF23FCF4; Wed, 06 Jun 2012 10:37:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1338979052!10223351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7425 invoked from network); 6 Jun 2012 10:37:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:37:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:37:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:37:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDcK-00082g-4Q; Wed, 06 Jun 2012 10:37:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDcK-00062j-1Y;
	Wed, 06 Jun 2012 11:37:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13035.861265.563682@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:37:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338578238.14877.67.camel@dagon.hellion.org.uk>
References: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
	<20425.1120.90566.706268@mariner.uk.xensource.com>
	<1338578238.14877.67.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Simon Rowe <Simon.Rowe@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] xs: set read_thread stacksize"):
> On Fri, 2012-06-01 at 19:05 +0100, Ian Jackson wrote:
> > Can I request that you provide another patch too, which would probably
> > come before this one, which uses pthread_sigprocmask to block all
> > signals on the private thread ?  This is done by changing the signal
> > mask to all signals blocked and then restoring it afterwards.
> 
> Do you mean pthread_sigmask or sigprocmask rather than the hybrid
> pthread_sigprocmask (which appears not to exist).

I mean pthread_sigmask, of course.

I remembered that they had pointlessly invented a new function name
but not that they'd pointlessly varied the spelling...

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:37:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDcc-0000Dk-Mw; Wed, 06 Jun 2012 10:37:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScDcb-0000DY-4k
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:37:49 +0000
Received: from [193.109.254.147:29663] by server-10.bemta-14.messagelabs.com
	id 93/39-25709-CF23FCF4; Wed, 06 Jun 2012 10:37:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1338979052!10223351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7425 invoked from network); 6 Jun 2012 10:37:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:37:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:37:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:37:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDcK-00082g-4Q; Wed, 06 Jun 2012 10:37:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDcK-00062j-1Y;
	Wed, 06 Jun 2012 11:37:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13035.861265.563682@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:37:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338578238.14877.67.camel@dagon.hellion.org.uk>
References: <2d0a29ab3f917df16804.1338449959@drall.uk.xensource.com>
	<20425.1120.90566.706268@mariner.uk.xensource.com>
	<1338578238.14877.67.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Simon Rowe <Simon.Rowe@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] xs: set read_thread stacksize"):
> On Fri, 2012-06-01 at 19:05 +0100, Ian Jackson wrote:
> > Can I request that you provide another patch too, which would probably
> > come before this one, which uses pthread_sigprocmask to block all
> > signals on the private thread ?  This is done by changing the signal
> > mask to all signals blocked and then restoring it afterwards.
> 
> Do you mean pthread_sigmask or sigprocmask rather than the hybrid
> pthread_sigprocmask (which appears not to exist).

I mean pthread_sigmask, of course.

I remembered that they had pointlessly invented a new function name
but not that they'd pointlessly varied the spelling...

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:38:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDdc-0000Py-53; Wed, 06 Jun 2012 10:38: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 1ScDda-0000PT-77
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:38:50 +0000
Received: from [85.158.138.51:29517] by server-4.bemta-3.messagelabs.com id
	3E/1C-13598-9333FCF4; Wed, 06 Jun 2012 10:38:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338979128!30991300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31116 invoked from network); 6 Jun 2012 10:38:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:38:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:38:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:38:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDdY-00084M-8Z; Wed, 06 Jun 2012 10:38:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDdY-00062s-6Q;
	Wed, 06 Jun 2012 11:38:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13112.19965.299156@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:38:48 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338622864.14877.70.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
	<1338619069.4052.0.camel@Abyss>
	<1338622864.14877.70.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0 of 5 V2] libxl: make it possible to explicitly specify default sched params"):
> On Sat, 2012-06-02 at 07:37 +0100, Dario Faggioli wrote:
> > Uh? I can build it too...
> 
> So, apparently, could test flight 13006, which is odd because I thought
> the test system was doing everything totally from scratch.

The test system doesn't have ocaml installed because when it did it
exposed what seemed to be a bug in the ocaml xenstored, which I
haven't yet had time to investigate.

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:38:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10: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 1ScDdc-0000Py-53; Wed, 06 Jun 2012 10:38: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 1ScDda-0000PT-77
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:38:50 +0000
Received: from [85.158.138.51:29517] by server-4.bemta-3.messagelabs.com id
	3E/1C-13598-9333FCF4; Wed, 06 Jun 2012 10:38:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1338979128!30991300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31116 invoked from network); 6 Jun 2012 10:38:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:38:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:38:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:38:48 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDdY-00084M-8Z; Wed, 06 Jun 2012 10:38:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDdY-00062s-6Q;
	Wed, 06 Jun 2012 11:38:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13112.19965.299156@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:38:48 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1338622864.14877.70.camel@dagon.hellion.org.uk>
References: <patchbomb.1338299818@cosworth.uk.xensource.com>
	<1338548826.17466.88.camel@zakaz.uk.xensource.com>
	<20425.1295.7385.342986@mariner.uk.xensource.com>
	<1338576470.14877.58.camel@dagon.hellion.org.uk>
	<1338619069.4052.0.camel@Abyss>
	<1338622864.14877.70.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5 V2] libxl: make it possible to
 explicitly specify default sched params
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0 of 5 V2] libxl: make it possible to explicitly specify default sched params"):
> On Sat, 2012-06-02 at 07:37 +0100, Dario Faggioli wrote:
> > Uh? I can build it too...
> 
> So, apparently, could test flight 13006, which is odd because I thought
> the test system was doing everything totally from scratch.

The test system doesn't have ocaml installed because when it did it
exposed what seemed to be a bug in the ocaml xenstored, which I
haven't yet had time to investigate.

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:40: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 1ScDf1-0000cw-MP; Wed, 06 Jun 2012 10:40: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 1ScDf0-0000cg-LC
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:40:18 +0000
Received: from [85.158.143.99:63878] by server-2.bemta-4.messagelabs.com id
	A6/A3-17938-2933FCF4; Wed, 06 Jun 2012 10:40:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338979216!31528731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15002 invoked from network); 6 Jun 2012 10:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:40:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:40:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDey-00084w-9p; Wed, 06 Jun 2012 10:40:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDey-00062y-8M;
	Wed, 06 Jun 2012 11:40:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13200.114406.125096@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:40:16 +0100
To: "W. Michael Petullo" <mike@flyn.org>
In-Reply-To: <20120602141903.GA2903@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
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] Using "xl create" without domain 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

W. Michael Petullo writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
...
> -    if (!S_ISREG(stab.st_mode)) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
> +    if (S_ISDIR(stab.st_mode)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);

This is not correct.  If, for example, /dev/tty is specified, it will
go wrong.

The reason for the restriction to plain files is that those are the
only thing on which stat works to provide the size.  If we are to
support other objects, we need to change the reading algorithm.

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:40: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 1ScDf1-0000cw-MP; Wed, 06 Jun 2012 10:40: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 1ScDf0-0000cg-LC
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:40:18 +0000
Received: from [85.158.143.99:63878] by server-2.bemta-4.messagelabs.com id
	A6/A3-17938-2933FCF4; Wed, 06 Jun 2012 10:40:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338979216!31528731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15002 invoked from network); 6 Jun 2012 10:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:40:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:40:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDey-00084w-9p; Wed, 06 Jun 2012 10:40:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDey-00062y-8M;
	Wed, 06 Jun 2012 11:40:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13200.114406.125096@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:40:16 +0100
To: "W. Michael Petullo" <mike@flyn.org>
In-Reply-To: <20120602141903.GA2903@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
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] Using "xl create" without domain 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

W. Michael Petullo writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
...
> -    if (!S_ISREG(stab.st_mode)) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
> +    if (S_ISDIR(stab.st_mode)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);

This is not correct.  If, for example, /dev/tty is specified, it will
go wrong.

The reason for the restriction to plain files is that those are the
only thing on which stat works to provide the size.  If we are to
support other objects, we need to change the reading algorithm.

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDgQ-0000oV-8x; Wed, 06 Jun 2012 10:41: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 1ScDgP-0000oH-3Q
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:41:45 +0000
Received: from [85.158.139.83:25751] by server-5.bemta-5.messagelabs.com id
	46/6B-04481-8E33FCF4; Wed, 06 Jun 2012 10:41:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338979303!30715620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5029 invoked from network); 6 Jun 2012 10:41:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:41:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:41:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDgN-00085U-84; Wed, 06 Jun 2012 10:41:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDgN-000634-7F;
	Wed, 06 Jun 2012 11:41:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13287.208744.519066@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:41:43 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <3eadab19abd49fbc6f56.1338818483@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[PATCH] xl: check for meaningful combination of sedf config file parameters"):
> As we do it in the implementation of `xl sched-sedf -d ...', some
> consistency checking is needed while parsing the sedf scheduling
> parameters provided via config file. Not doing this results in the call
> libxl_domain_sched_params_set() to fail, and no parameters being
> enforced for the domain.

Why does xl continue after libxl_domain_sched_params_set fails ?

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDgQ-0000oV-8x; Wed, 06 Jun 2012 10:41: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 1ScDgP-0000oH-3Q
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:41:45 +0000
Received: from [85.158.139.83:25751] by server-5.bemta-5.messagelabs.com id
	46/6B-04481-8E33FCF4; Wed, 06 Jun 2012 10:41:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338979303!30715620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5029 invoked from network); 6 Jun 2012 10:41:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:41:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:41:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDgN-00085U-84; Wed, 06 Jun 2012 10:41:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDgN-000634-7F;
	Wed, 06 Jun 2012 11:41:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13287.208744.519066@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:41:43 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <3eadab19abd49fbc6f56.1338818483@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[PATCH] xl: check for meaningful combination of sedf config file parameters"):
> As we do it in the implementation of `xl sched-sedf -d ...', some
> consistency checking is needed while parsing the sedf scheduling
> parameters provided via config file. Not doing this results in the call
> libxl_domain_sched_params_set() to fail, and no parameters being
> enforced for the domain.

Why does xl continue after libxl_domain_sched_params_set fails ?

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:42:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:42: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 1ScDgf-0000rd-MI; Wed, 06 Jun 2012 10:42: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 1ScDge-0000rF-84
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:42:00 +0000
Received: from [85.158.139.83:29321] by server-8.bemta-5.messagelabs.com id
	A4/EE-02058-7F33FCF4; Wed, 06 Jun 2012 10:41:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1338979318!28247530!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21757 invoked from network); 6 Jun 2012 10:41:58 -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; 6 Jun 2012 10:41:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 11:41:58 +0100
Message-Id: <4FCF5015020000780008878C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 11:41:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Jones" <drjones@redhat.com>
References: <c30e80f1-120e-4b42-ab33-c53bbe714a94@zmail17.collab.prod.int.phx2.redhat.com>
	<1726d244-d951-4651-bfee-16ac14b56096@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1726d244-d951-4651-bfee-16ac14b56096@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 10:54, Andrew Jones <drjones@redhat.com> wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=829016 
> 
> was opened yesterday. Maybe the following commit
> is the culprit?
> 
> commit cb8095bba6d24118135a5683a956f4f4fb5f17bb
> Author: Jan Beulich <JBeulich@suse.com>
> Date:   Fri Jan 20 16:22:04 2012 +0000
> 
>     x86: atomic64 assembly improvements

Hardly - that change didn't even touch atomic64_read_cx8()
or any of its constraints.

Further more, this

*pdpt = 0000000023be6027 *pde = 00000000037c2067 *pte = 8000000023bdb061 
Oops: 0003 [#1] SMP 

tells us that this was a write-protection fault, yet the hypervisor
failed to emulate this (hence the hypervisor log would likely help).
After quite some time spent looking through the upstream 3.0.4
sources (and my local object files) I can't, however, spot where
the call to atomic64_read() is actually located in the functions in
question.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:42:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:42: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 1ScDgf-0000rd-MI; Wed, 06 Jun 2012 10:42: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 1ScDge-0000rF-84
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:42:00 +0000
Received: from [85.158.139.83:29321] by server-8.bemta-5.messagelabs.com id
	A4/EE-02058-7F33FCF4; Wed, 06 Jun 2012 10:41:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1338979318!28247530!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21757 invoked from network); 6 Jun 2012 10:41:58 -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; 6 Jun 2012 10:41:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Jun 2012 11:41:58 +0100
Message-Id: <4FCF5015020000780008878C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 06 Jun 2012 11:41:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Jones" <drjones@redhat.com>
References: <c30e80f1-120e-4b42-ab33-c53bbe714a94@zmail17.collab.prod.int.phx2.redhat.com>
	<1726d244-d951-4651-bfee-16ac14b56096@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1726d244-d951-4651-bfee-16ac14b56096@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 10:54, Andrew Jones <drjones@redhat.com> wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=829016 
> 
> was opened yesterday. Maybe the following commit
> is the culprit?
> 
> commit cb8095bba6d24118135a5683a956f4f4fb5f17bb
> Author: Jan Beulich <JBeulich@suse.com>
> Date:   Fri Jan 20 16:22:04 2012 +0000
> 
>     x86: atomic64 assembly improvements

Hardly - that change didn't even touch atomic64_read_cx8()
or any of its constraints.

Further more, this

*pdpt = 0000000023be6027 *pde = 00000000037c2067 *pte = 8000000023bdb061 
Oops: 0003 [#1] SMP 

tells us that this was a write-protection fault, yet the hypervisor
failed to emulate this (hence the hypervisor log would likely help).
After quite some time spent looking through the upstream 3.0.4
sources (and my local object files) I can't, however, spot where
the call to atomic64_read() is actually located in the functions in
question.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:43: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 1ScDi5-00016T-5x; Wed, 06 Jun 2012 10:43: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 1ScDi4-000165-6K
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:43:28 +0000
Received: from [85.158.143.99:14422] by server-1.bemta-4.messagelabs.com id
	35/B5-10042-F443FCF4; Wed, 06 Jun 2012 10:43:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1338979406!21764898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14927 invoked from network); 6 Jun 2012 10:43:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:43:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:43:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDi1-00085z-It; Wed, 06 Jun 2012 10:43:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDi1-00063F-I5;
	Wed, 06 Jun 2012 11:43:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13389.87069.507313@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:43:25 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <a5f7f05d76f9d8940121.1338830602@Solace>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

RGFyaW8gRmFnZ2lvbGkgd3JpdGVzICgiW1BBVENIIDEgb2YgMSB2NV0gbGlieGw6IGludHJvZHVj
ZSBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEIik6Cj4gVG8gYXZvaWQgcmVjZW50IGdjYyBjb21w
bGFpbmluZyBhYm91dDoKPiBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9wcmltYXJ5X2Nv
bnNvbGVfZXhlY+KAmToKCkNhbiB5b3UgcGxlYXNlIGF2b2lkIHRoZXNlIG5vbi1hc2NpaSBxdW90
ZXMgaW4gY29tbWl0IG1lc3NhZ2VzID8gIEl0Cm1ha2VzIG15IGxpZmUgdW5uZWNlc3NhcmlseSBk
aWZmaWN1bHQgd2hlbiBhcHBseWluZyBwYXRjaGVzLiAgQW55IG9mCmAuLi4nLCAnLi4uJyBhbmQg
Ii4uLiIgYXJlIGZpbmUuCgpJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:43: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 1ScDi5-00016T-5x; Wed, 06 Jun 2012 10:43: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 1ScDi4-000165-6K
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:43:28 +0000
Received: from [85.158.143.99:14422] by server-1.bemta-4.messagelabs.com id
	35/B5-10042-F443FCF4; Wed, 06 Jun 2012 10:43:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1338979406!21764898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14927 invoked from network); 6 Jun 2012 10:43:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:43:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:43:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDi1-00085z-It; Wed, 06 Jun 2012 10:43:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDi1-00063F-I5;
	Wed, 06 Jun 2012 11:43:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13389.87069.507313@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:43:25 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <a5f7f05d76f9d8940121.1338830602@Solace>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

RGFyaW8gRmFnZ2lvbGkgd3JpdGVzICgiW1BBVENIIDEgb2YgMSB2NV0gbGlieGw6IGludHJvZHVj
ZSBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEIik6Cj4gVG8gYXZvaWQgcmVjZW50IGdjYyBjb21w
bGFpbmluZyBhYm91dDoKPiBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9wcmltYXJ5X2Nv
bnNvbGVfZXhlY+KAmToKCkNhbiB5b3UgcGxlYXNlIGF2b2lkIHRoZXNlIG5vbi1hc2NpaSBxdW90
ZXMgaW4gY29tbWl0IG1lc3NhZ2VzID8gIEl0Cm1ha2VzIG15IGxpZmUgdW5uZWNlc3NhcmlseSBk
aWZmaWN1bHQgd2hlbiBhcHBseWluZyBwYXRjaGVzLiAgQW55IG9mCmAuLi4nLCAnLi4uJyBhbmQg
Ii4uLiIgYXJlIGZpbmUuCgpJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:47:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:47:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDlm-0001U9-RX; Wed, 06 Jun 2012 10:47: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 1ScDll-0001U1-2U
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:47:17 +0000
Received: from [85.158.143.35:63431] by server-2.bemta-4.messagelabs.com id
	95/DF-17938-4353FCF4; Wed, 06 Jun 2012 10:47:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338979635!8599969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24499 invoked from network); 6 Jun 2012 10:47:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:47:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:47:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:47:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDli-00087J-9E; Wed, 06 Jun 2012 10:47:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDli-00063O-7j;
	Wed, 06 Jun 2012 11:47:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13618.66803.683850@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:47:14 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <a5f7f05d76f9d8940121.1338830602@Solace>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

RGFyaW8gRmFnZ2lvbGkgd3JpdGVzICgiW1BBVENIIDEgb2YgMSB2NV0gbGlieGw6IGludHJvZHVj
ZSBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEIik6Cj4gVG8gYXZvaWQgcmVjZW50IGdjYyBjb21w
bGFpbmluZyBhYm91dDoKPiBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9wcmltYXJ5X2Nv
bnNvbGVfZXhlY+KAmToKPiBsaWJ4bC5jOjEyMzM6OTogZXJyb3I6IGNhc2UgdmFsdWUg4oCYNDI5
NDk2NzI5NeKAmSBub3QgaW4gZW51bWVyYXRlZCB0eXBlIOKAmGxpYnhsX2RvbWFpbl90eXBl4oCZ
IFstV2Vycm9yPXN3aXRjaF0KLi4uCj4gKyAgICBpZiAodHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQ
RV9JTlZBTElEKSB7Cj4gKyAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1Is
Cj4gKyAgICAgICAgICAgICAgICAgICAiaW52YWxpZCBkb21haW4gdHlwZSBmb3IgZG9tYWluICVk
IiwgZG9taWQpOwo+ICsgICAgICAgIHJjID0gRVJST1JfSU5WQUw7Cj4gKyAgICAgICAgZ290byBy
ZW11c19mYWlsOwoKVGhpcyBpcyBub3QgYW4gZXhwZWN0ZWQgZXJyb3IgY29uZGl0aW9uLCBpcyBp
dCA/ICBFUlJPUl9JTlZBTCBpcyBmb3IKbGlieGwgYmVpbmcgcGFzc2VkIGltcHJvbXBlciBwYXJh
bWV0ZXJzLiAgU28gSSB0aGluayB0aGlzIHNob3VsZCBiZQpFUlJPUl9GQUlMLgoKPiBAQCAtNjky
LDExICs2OTksMjAgQEAgaW50IGxpYnhsX2RvbWFpbl9zdXNwZW5kKGxpYnhsX2N0eCAqY3R4LAo+
ICAgICAgaW50IGRlYnVnID0gaW5mbyAhPSBOVUxMICYmIGluZm8tPmZsYWdzICYgWExfU1VTUEVO
RF9ERUJVRzsKPiAgICAgIGludCByYyA9IDA7Cj4gIAo+ICsgICAgaWYgKHR5cGUgPT0gTElCWExf
RE9NQUlOX1RZUEVfSU5WQUxJRCkgewo+ICsgICAgICAgIExJQlhMX19MT0coY3R4LCBMSUJYTF9f
TE9HX0VSUk9SLAo+ICsgICAgICAgICAgICAgICAgICAgImludmFsaWQgZG9tYWluIHR5cGUgZm9y
IGRvbWFpbiAlZCIsIGRvbWlkKTsKPiArICAgICAgICByYyA9IEVSUk9SX0lOVkFMOwo+ICsgICAg
ICAgIGdvdG8gc3VzcGVuZF9mYWlsOwo+ICsgICAgfQoKSXMgaXQgcG9zc2libGUgZm9yIHlvdSB0
byBsZWF2ZSB0aGlzIHBhcnQgYWxvbmUgPyAgSXQncyBtb3ZlZCBhYm91dCBhCmxvdCBpbiBteSBz
dXNwZW5kL3Jlc3VtZSBzZXJpZXMuCgpJIHdpbGwgZml4IGl0IHVwIGF0IHRoZSBlbmQgb2YgbXkg
c2VyaWVzLgoKVGhhbmtzLApJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:47:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:47:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDlm-0001U9-RX; Wed, 06 Jun 2012 10:47: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 1ScDll-0001U1-2U
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:47:17 +0000
Received: from [85.158.143.35:63431] by server-2.bemta-4.messagelabs.com id
	95/DF-17938-4353FCF4; Wed, 06 Jun 2012 10:47:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338979635!8599969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24499 invoked from network); 6 Jun 2012 10:47:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:47:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:47:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:47:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDli-00087J-9E; Wed, 06 Jun 2012 10:47:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDli-00063O-7j;
	Wed, 06 Jun 2012 11:47:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13618.66803.683850@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:47:14 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <a5f7f05d76f9d8940121.1338830602@Solace>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

RGFyaW8gRmFnZ2lvbGkgd3JpdGVzICgiW1BBVENIIDEgb2YgMSB2NV0gbGlieGw6IGludHJvZHVj
ZSBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEIik6Cj4gVG8gYXZvaWQgcmVjZW50IGdjYyBjb21w
bGFpbmluZyBhYm91dDoKPiBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9wcmltYXJ5X2Nv
bnNvbGVfZXhlY+KAmToKPiBsaWJ4bC5jOjEyMzM6OTogZXJyb3I6IGNhc2UgdmFsdWUg4oCYNDI5
NDk2NzI5NeKAmSBub3QgaW4gZW51bWVyYXRlZCB0eXBlIOKAmGxpYnhsX2RvbWFpbl90eXBl4oCZ
IFstV2Vycm9yPXN3aXRjaF0KLi4uCj4gKyAgICBpZiAodHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQ
RV9JTlZBTElEKSB7Cj4gKyAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1Is
Cj4gKyAgICAgICAgICAgICAgICAgICAiaW52YWxpZCBkb21haW4gdHlwZSBmb3IgZG9tYWluICVk
IiwgZG9taWQpOwo+ICsgICAgICAgIHJjID0gRVJST1JfSU5WQUw7Cj4gKyAgICAgICAgZ290byBy
ZW11c19mYWlsOwoKVGhpcyBpcyBub3QgYW4gZXhwZWN0ZWQgZXJyb3IgY29uZGl0aW9uLCBpcyBp
dCA/ICBFUlJPUl9JTlZBTCBpcyBmb3IKbGlieGwgYmVpbmcgcGFzc2VkIGltcHJvbXBlciBwYXJh
bWV0ZXJzLiAgU28gSSB0aGluayB0aGlzIHNob3VsZCBiZQpFUlJPUl9GQUlMLgoKPiBAQCAtNjky
LDExICs2OTksMjAgQEAgaW50IGxpYnhsX2RvbWFpbl9zdXNwZW5kKGxpYnhsX2N0eCAqY3R4LAo+
ICAgICAgaW50IGRlYnVnID0gaW5mbyAhPSBOVUxMICYmIGluZm8tPmZsYWdzICYgWExfU1VTUEVO
RF9ERUJVRzsKPiAgICAgIGludCByYyA9IDA7Cj4gIAo+ICsgICAgaWYgKHR5cGUgPT0gTElCWExf
RE9NQUlOX1RZUEVfSU5WQUxJRCkgewo+ICsgICAgICAgIExJQlhMX19MT0coY3R4LCBMSUJYTF9f
TE9HX0VSUk9SLAo+ICsgICAgICAgICAgICAgICAgICAgImludmFsaWQgZG9tYWluIHR5cGUgZm9y
IGRvbWFpbiAlZCIsIGRvbWlkKTsKPiArICAgICAgICByYyA9IEVSUk9SX0lOVkFMOwo+ICsgICAg
ICAgIGdvdG8gc3VzcGVuZF9mYWlsOwo+ICsgICAgfQoKSXMgaXQgcG9zc2libGUgZm9yIHlvdSB0
byBsZWF2ZSB0aGlzIHBhcnQgYWxvbmUgPyAgSXQncyBtb3ZlZCBhYm91dCBhCmxvdCBpbiBteSBz
dXNwZW5kL3Jlc3VtZSBzZXJpZXMuCgpJIHdpbGwgZml4IGl0IHVwIGF0IHRoZSBlbmQgb2YgbXkg
c2VyaWVzLgoKVGhhbmtzLApJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScDn3-0001ae-9r; Wed, 06 Jun 2012 10:48:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScDn1-0001aZ-Vj
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:48:36 +0000
Received: from [193.109.254.147:5271] by server-3.bemta-14.messagelabs.com id
	FA/D5-05653-3853FCF4; Wed, 06 Jun 2012 10:48:35 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338979714!12980560!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15585 invoked from network); 6 Jun 2012 10:48:34 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-27.messagelabs.com with SMTP;
	6 Jun 2012 10:48:34 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689290; Wed, 06 Jun 2012 12:48:33 +0200
Message-ID: <1338979707.6152.18.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 06 Jun 2012 12:48:27 +0200
In-Reply-To: <20431.13287.208744.519066@mariner.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3188883009246489539=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3188883009246489539==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HE5UClY673wDFtpZ17vS"


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

On Wed, 2012-06-06 at 11:41 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH] xl: check for meaningful combination of s=
edf config file parameters"):
> > As we do it in the implementation of `xl sched-sedf -d ...', some
> > consistency checking is needed while parsing the sedf scheduling
> > parameters provided via config file. Not doing this results in the call
> > libxl_domain_sched_params_set() to fail, and no parameters being
> > enforced for the domain.
>=20
> Why does xl continue after libxl_domain_sched_params_set fails ?
>=20
Well, that I really don't know. It has always been like this I guess, it
just print the related error about inconsistent/wrong scheduling
parameters and then the domain is created with default ones.

Should we/I stop it?

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-HE5UClY673wDFtpZ17vS
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)

iEUEABECAAYFAk/PNXsACgkQk4XaBE3IOsTqDQCfYWyw8BjnrDMGPcrrwJtxERiP
81MAmKuI5jFpr6ekQhZOsqbY8LAf1PQ=
=9fBm
-----END PGP SIGNATURE-----

--=-HE5UClY673wDFtpZ17vS--



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

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

--===============3188883009246489539==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 10:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScDn3-0001ae-9r; Wed, 06 Jun 2012 10:48:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScDn1-0001aZ-Vj
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:48:36 +0000
Received: from [193.109.254.147:5271] by server-3.bemta-14.messagelabs.com id
	FA/D5-05653-3853FCF4; Wed, 06 Jun 2012 10:48:35 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1338979714!12980560!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15585 invoked from network); 6 Jun 2012 10:48:34 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-27.messagelabs.com with SMTP;
	6 Jun 2012 10:48:34 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689290; Wed, 06 Jun 2012 12:48:33 +0200
Message-ID: <1338979707.6152.18.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 06 Jun 2012 12:48:27 +0200
In-Reply-To: <20431.13287.208744.519066@mariner.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3188883009246489539=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3188883009246489539==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HE5UClY673wDFtpZ17vS"


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

On Wed, 2012-06-06 at 11:41 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH] xl: check for meaningful combination of s=
edf config file parameters"):
> > As we do it in the implementation of `xl sched-sedf -d ...', some
> > consistency checking is needed while parsing the sedf scheduling
> > parameters provided via config file. Not doing this results in the call
> > libxl_domain_sched_params_set() to fail, and no parameters being
> > enforced for the domain.
>=20
> Why does xl continue after libxl_domain_sched_params_set fails ?
>=20
Well, that I really don't know. It has always been like this I guess, it
just print the related error about inconsistent/wrong scheduling
parameters and then the domain is created with default ones.

Should we/I stop it?

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-HE5UClY673wDFtpZ17vS
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)

iEUEABECAAYFAk/PNXsACgkQk4XaBE3IOsTqDQCfYWyw8BjnrDMGPcrrwJtxERiP
81MAmKuI5jFpr6ekQhZOsqbY8LAf1PQ=
=9fBm
-----END PGP SIGNATURE-----

--=-HE5UClY673wDFtpZ17vS--



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

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

--===============3188883009246489539==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 10:49:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDnY-0001e4-Mh; Wed, 06 Jun 2012 10:49: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 1ScDnY-0001dr-3p
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:49:08 +0000
Received: from [85.158.143.35:25316] by server-3.bemta-4.messagelabs.com id
	17/4D-29237-3A53FCF4; Wed, 06 Jun 2012 10:49:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338979741!19004723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13588 invoked from network); 6 Jun 2012 10:49:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:49:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:49:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:49:01 +0100
Message-ID: <1338979740.32319.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 11:49:00 +0100
In-Reply-To: <20431.13287.208744.519066@mariner.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 11:41 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH] xl: check for meaningful combination of sedf config file parameters"):
> > As we do it in the implementation of `xl sched-sedf -d ...', some
> > consistency checking is needed while parsing the sedf scheduling
> > parameters provided via config file. Not doing this results in the call
> > libxl_domain_sched_params_set() to fail, and no parameters being
> > enforced for the domain.
> 
> Why does xl continue after libxl_domain_sched_params_set fails ?

Because libxl just carries on (in libxl__build_post) and doesn't
propagate the error... It most likely shouldn't. I think we can change
that separately though?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:49:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDnY-0001e4-Mh; Wed, 06 Jun 2012 10:49: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 1ScDnY-0001dr-3p
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:49:08 +0000
Received: from [85.158.143.35:25316] by server-3.bemta-4.messagelabs.com id
	17/4D-29237-3A53FCF4; Wed, 06 Jun 2012 10:49:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338979741!19004723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13588 invoked from network); 6 Jun 2012 10:49:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:49:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:49:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:49:01 +0100
Message-ID: <1338979740.32319.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 11:49:00 +0100
In-Reply-To: <20431.13287.208744.519066@mariner.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 11:41 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH] xl: check for meaningful combination of sedf config file parameters"):
> > As we do it in the implementation of `xl sched-sedf -d ...', some
> > consistency checking is needed while parsing the sedf scheduling
> > parameters provided via config file. Not doing this results in the call
> > libxl_domain_sched_params_set() to fail, and no parameters being
> > enforced for the domain.
> 
> Why does xl continue after libxl_domain_sched_params_set fails ?

Because libxl just carries on (in libxl__build_post) and doesn't
propagate the error... It most likely shouldn't. I think we can change
that separately though?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:51:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDpS-0001sH-F9; Wed, 06 Jun 2012 10:51:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScDpR-0001s5-Fl
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 10:51:05 +0000
Received: from [85.158.139.83:54701] by server-1.bemta-5.messagelabs.com id
	BC/A3-25424-8163FCF4; Wed, 06 Jun 2012 10:51:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1338979863!32266045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25095 invoked from network); 6 Jun 2012 10:51:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:51:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:50:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:50:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDp7-00088Y-0f; Wed, 06 Jun 2012 10:50:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDp7-00063q-00;
	Wed, 06 Jun 2012 11:50:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13828.982906.240702@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:50:44 +0100
To: ZhouPeng <zpengxen@gmail.com>
In-Reply-To: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ZhouPeng writes ("[Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2"):
> description:
> tools:libxl: refactor stdvga opinon support.
> 
> Be ready to add and describe new vga interface

Thanks.  

If Ian C is happy with the idl changes then I am happy with this
interface change for 4.2.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

However I think patches 2 and 3 of your series come too late for the
4.2 freeze.  Thanks for showing them to us, though.  We should
reconsider them after 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 Wed Jun 06 10:51:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDpS-0001sH-F9; Wed, 06 Jun 2012 10:51:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScDpR-0001s5-Fl
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 10:51:05 +0000
Received: from [85.158.139.83:54701] by server-1.bemta-5.messagelabs.com id
	BC/A3-25424-8163FCF4; Wed, 06 Jun 2012 10:51:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1338979863!32266045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25095 invoked from network); 6 Jun 2012 10:51:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:51:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:50:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:50:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDp7-00088Y-0f; Wed, 06 Jun 2012 10:50:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDp7-00063q-00;
	Wed, 06 Jun 2012 11:50:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.13828.982906.240702@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:50:44 +0100
To: ZhouPeng <zpengxen@gmail.com>
In-Reply-To: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ZhouPeng writes ("[Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2"):
> description:
> tools:libxl: refactor stdvga opinon support.
> 
> Be ready to add and describe new vga interface

Thanks.  

If Ian C is happy with the idl changes then I am happy with this
interface change for 4.2.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

However I think patches 2 and 3 of your series come too late for the
4.2 freeze.  Thanks for showing them to us, though.  We should
reconsider them after 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 Wed Jun 06 10:54:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:54: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 1ScDsr-00027I-8G; Wed, 06 Jun 2012 10:54:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScDsq-00027B-1i
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 10:54:36 +0000
Received: from [85.158.143.35:8534] by server-3.bemta-4.messagelabs.com id
	6E/67-29237-BE63FCF4; Wed, 06 Jun 2012 10:54:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1338980074!11089263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8702 invoked from network); 6 Jun 2012 10:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:54:34 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:54:34 +0100
Date: Wed, 6 Jun 2012 11:54:28 +0100
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.1206061152550.6030@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] disable virtfs compilation by default in
	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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---

diff --git a/tools/Makefile b/tools/Makefile
index 7b14678..dae7995 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find
 		--bindir=$(LIBEXEC) \
 		--datadir=$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
+		--disable-virtfs \
 		--python=$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:54:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:54: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 1ScDsr-00027I-8G; Wed, 06 Jun 2012 10:54:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScDsq-00027B-1i
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 10:54:36 +0000
Received: from [85.158.143.35:8534] by server-3.bemta-4.messagelabs.com id
	6E/67-29237-BE63FCF4; Wed, 06 Jun 2012 10:54:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1338980074!11089263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8702 invoked from network); 6 Jun 2012 10:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12855952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:54:34 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:54:34 +0100
Date: Wed, 6 Jun 2012 11:54:28 +0100
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.1206061152550.6030@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] disable virtfs compilation by default in
	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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---

diff --git a/tools/Makefile b/tools/Makefile
index 7b14678..dae7995 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find
 		--bindir=$(LIBEXEC) \
 		--datadir=$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
+		--disable-virtfs \
 		--python=$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:57:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDvB-0002Dy-Pb; Wed, 06 Jun 2012 10:57: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 1ScDvA-0002Dt-De
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:57:00 +0000
Received: from [85.158.143.99:48699] by server-2.bemta-4.messagelabs.com id
	C0/D0-17938-B773FCF4; Wed, 06 Jun 2012 10:56:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338980217!31220901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8407 invoked from network); 6 Jun 2012 10:56:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:56:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:56:56 +0100
Message-ID: <1338980214.32319.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 11:56:54 +0100
In-Reply-To: <20431.13618.66803.683850@mariner.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13618.66803.683850@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTA2IGF0IDExOjQ3ICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBE
YXJpbyBGYWdnaW9saSB3cml0ZXMgKCJbUEFUQ0ggMSBvZiAxIHY1XSBsaWJ4bDogaW50cm9kdWNl
IExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQiKToKPiA+IFRvIGF2b2lkIHJlY2VudCBnY2MgY29t
cGxhaW5pbmcgYWJvdXQ6Cj4gPiBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9wcmltYXJ5
X2NvbnNvbGVfZXhlY+KAmToKPiA+IGxpYnhsLmM6MTIzMzo5OiBlcnJvcjogY2FzZSB2YWx1ZSDi
gJg0Mjk0OTY3Mjk14oCZIG5vdCBpbiBlbnVtZXJhdGVkIHR5cGUg4oCYbGlieGxfZG9tYWluX3R5
cGXigJkgWy1XZXJyb3I9c3dpdGNoXQo+IC4uLgo+ID4gKyAgICBpZiAodHlwZSA9PSBMSUJYTF9E
T01BSU5fVFlQRV9JTlZBTElEKSB7Cj4gPiArICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExf
X0xPR19FUlJPUiwKPiA+ICsgICAgICAgICAgICAgICAgICAgImludmFsaWQgZG9tYWluIHR5cGUg
Zm9yIGRvbWFpbiAlZCIsIGRvbWlkKTsKPiA+ICsgICAgICAgIHJjID0gRVJST1JfSU5WQUw7Cj4g
PiArICAgICAgICBnb3RvIHJlbXVzX2ZhaWw7Cj4gCj4gVGhpcyBpcyBub3QgYW4gZXhwZWN0ZWQg
ZXJyb3IgY29uZGl0aW9uLCBpcyBpdCA/ICBFUlJPUl9JTlZBTCBpcyBmb3IKPiBsaWJ4bCBiZWlu
ZyBwYXNzZWQgaW1wcm9tcGVyIHBhcmFtZXRlcnMuICBTbyBJIHRoaW5rIHRoaXMgc2hvdWxkIGJl
Cj4gRVJST1JfRkFJTC4KCkFsc28gcGVyaGFwcyB0aGUgbG9nZ2luZyBzaG91bGQgYmUgZG9uZSBp
biBsaWJ4bF9fZG9tYWluX3R5cGU/IFVubGVzcwp0aGVyZSBhcmUgdG9vIG1hbnkgbGVnaXRpbWF0
ZSBvY2Nhc2lvbnMgd2hlcmUgSU5WQUxJRCBtaWdodCBjb21lIHVwPwoKPiAKPiA+IEBAIC02OTIs
MTEgKzY5OSwyMCBAQCBpbnQgbGlieGxfZG9tYWluX3N1c3BlbmQobGlieGxfY3R4ICpjdHgsCj4g
PiAgICAgIGludCBkZWJ1ZyA9IGluZm8gIT0gTlVMTCAmJiBpbmZvLT5mbGFncyAmIFhMX1NVU1BF
TkRfREVCVUc7Cj4gPiAgICAgIGludCByYyA9IDA7Cj4gPiAgCj4gPiArICAgIGlmICh0eXBlID09
IExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQpIHsKPiA+ICsgICAgICAgIExJQlhMX19MT0coY3R4
LCBMSUJYTF9fTE9HX0VSUk9SLAo+ID4gKyAgICAgICAgICAgICAgICAgICAiaW52YWxpZCBkb21h
aW4gdHlwZSBmb3IgZG9tYWluICVkIiwgZG9taWQpOwo+ID4gKyAgICAgICAgcmMgPSBFUlJPUl9J
TlZBTDsKPiA+ICsgICAgICAgIGdvdG8gc3VzcGVuZF9mYWlsOwo+ID4gKyAgICB9Cj4gCj4gSXMg
aXQgcG9zc2libGUgZm9yIHlvdSB0byBsZWF2ZSB0aGlzIHBhcnQgYWxvbmUgPyAgSXQncyBtb3Zl
ZCBhYm91dCBhCj4gbG90IGluIG15IHN1c3BlbmQvcmVzdW1lIHNlcmllcy4KPiAKPiBJIHdpbGwg
Zml4IGl0IHVwIGF0IHRoZSBlbmQgb2YgbXkgc2VyaWVzLgo+IAo+IFRoYW5rcywKPiBJYW4uCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:57:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScDvB-0002Dy-Pb; Wed, 06 Jun 2012 10:57: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 1ScDvA-0002Dt-De
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:57:00 +0000
Received: from [85.158.143.99:48699] by server-2.bemta-4.messagelabs.com id
	C0/D0-17938-B773FCF4; Wed, 06 Jun 2012 10:56:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1338980217!31220901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8407 invoked from network); 6 Jun 2012 10:56:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:56:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	11:56:56 +0100
Message-ID: <1338980214.32319.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 11:56:54 +0100
In-Reply-To: <20431.13618.66803.683850@mariner.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13618.66803.683850@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTA2IGF0IDExOjQ3ICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBE
YXJpbyBGYWdnaW9saSB3cml0ZXMgKCJbUEFUQ0ggMSBvZiAxIHY1XSBsaWJ4bDogaW50cm9kdWNl
IExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQiKToKPiA+IFRvIGF2b2lkIHJlY2VudCBnY2MgY29t
cGxhaW5pbmcgYWJvdXQ6Cj4gPiBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9wcmltYXJ5
X2NvbnNvbGVfZXhlY+KAmToKPiA+IGxpYnhsLmM6MTIzMzo5OiBlcnJvcjogY2FzZSB2YWx1ZSDi
gJg0Mjk0OTY3Mjk14oCZIG5vdCBpbiBlbnVtZXJhdGVkIHR5cGUg4oCYbGlieGxfZG9tYWluX3R5
cGXigJkgWy1XZXJyb3I9c3dpdGNoXQo+IC4uLgo+ID4gKyAgICBpZiAodHlwZSA9PSBMSUJYTF9E
T01BSU5fVFlQRV9JTlZBTElEKSB7Cj4gPiArICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExf
X0xPR19FUlJPUiwKPiA+ICsgICAgICAgICAgICAgICAgICAgImludmFsaWQgZG9tYWluIHR5cGUg
Zm9yIGRvbWFpbiAlZCIsIGRvbWlkKTsKPiA+ICsgICAgICAgIHJjID0gRVJST1JfSU5WQUw7Cj4g
PiArICAgICAgICBnb3RvIHJlbXVzX2ZhaWw7Cj4gCj4gVGhpcyBpcyBub3QgYW4gZXhwZWN0ZWQg
ZXJyb3IgY29uZGl0aW9uLCBpcyBpdCA/ICBFUlJPUl9JTlZBTCBpcyBmb3IKPiBsaWJ4bCBiZWlu
ZyBwYXNzZWQgaW1wcm9tcGVyIHBhcmFtZXRlcnMuICBTbyBJIHRoaW5rIHRoaXMgc2hvdWxkIGJl
Cj4gRVJST1JfRkFJTC4KCkFsc28gcGVyaGFwcyB0aGUgbG9nZ2luZyBzaG91bGQgYmUgZG9uZSBp
biBsaWJ4bF9fZG9tYWluX3R5cGU/IFVubGVzcwp0aGVyZSBhcmUgdG9vIG1hbnkgbGVnaXRpbWF0
ZSBvY2Nhc2lvbnMgd2hlcmUgSU5WQUxJRCBtaWdodCBjb21lIHVwPwoKPiAKPiA+IEBAIC02OTIs
MTEgKzY5OSwyMCBAQCBpbnQgbGlieGxfZG9tYWluX3N1c3BlbmQobGlieGxfY3R4ICpjdHgsCj4g
PiAgICAgIGludCBkZWJ1ZyA9IGluZm8gIT0gTlVMTCAmJiBpbmZvLT5mbGFncyAmIFhMX1NVU1BF
TkRfREVCVUc7Cj4gPiAgICAgIGludCByYyA9IDA7Cj4gPiAgCj4gPiArICAgIGlmICh0eXBlID09
IExJQlhMX0RPTUFJTl9UWVBFX0lOVkFMSUQpIHsKPiA+ICsgICAgICAgIExJQlhMX19MT0coY3R4
LCBMSUJYTF9fTE9HX0VSUk9SLAo+ID4gKyAgICAgICAgICAgICAgICAgICAiaW52YWxpZCBkb21h
aW4gdHlwZSBmb3IgZG9tYWluICVkIiwgZG9taWQpOwo+ID4gKyAgICAgICAgcmMgPSBFUlJPUl9J
TlZBTDsKPiA+ICsgICAgICAgIGdvdG8gc3VzcGVuZF9mYWlsOwo+ID4gKyAgICB9Cj4gCj4gSXMg
aXQgcG9zc2libGUgZm9yIHlvdSB0byBsZWF2ZSB0aGlzIHBhcnQgYWxvbmUgPyAgSXQncyBtb3Zl
ZCBhYm91dCBhCj4gbG90IGluIG15IHN1c3BlbmQvcmVzdW1lIHNlcmllcy4KPiAKPiBJIHdpbGwg
Zml4IGl0IHVwIGF0IHRoZSBlbmQgb2YgbXkgc2VyaWVzLgo+IAo+IFRoYW5rcywKPiBJYW4uCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 06 10:57:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:57: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 1ScDvH-0002EV-5T; Wed, 06 Jun 2012 10:57:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScDvF-0002EH-H7
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:57:05 +0000
Received: from [193.109.254.147:63819] by server-6.bemta-14.messagelabs.com id
	7F/77-02426-0873FCF4; Wed, 06 Jun 2012 10:57:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338980224!5355137!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22045 invoked from network); 6 Jun 2012 10:57:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:57:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:57:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:57:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDvD-0008CC-1f; Wed, 06 Jun 2012 10:57:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDvD-00064V-1C;
	Wed, 06 Jun 2012 11:57:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.14207.24074.538390@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:57:03 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1338979707.6152.18.camel@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
	<1338979707.6152.18.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [PATCH] xl: check for meaningful combination of sedf config file parameters"):
> On Wed, 2012-06-06 at 11:41 +0100, Ian Jackson wrote:
> > Why does xl continue after libxl_domain_sched_params_set fails ?
> 
> Well, that I really don't know. It has always been like this I guess, it
> just print the related error about inconsistent/wrong scheduling
> parameters and then the domain is created with default ones.
> 
> Should we/I stop it?

Please, yes.  In general libxl's error handling is rather poor in
places (although a lot of it has been improved).

Where you notice that (a) the thing you wanted to do doesn't work and
(b) xl blunders on anyway, it's best to fix (b) first, while you still
have the test case, and then (a) :-).

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 Jun 06 10:57:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 10:57: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 1ScDvH-0002EV-5T; Wed, 06 Jun 2012 10:57:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScDvF-0002EH-H7
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 10:57:05 +0000
Received: from [193.109.254.147:63819] by server-6.bemta-14.messagelabs.com id
	7F/77-02426-0873FCF4; Wed, 06 Jun 2012 10:57:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338980224!5355137!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22045 invoked from network); 6 Jun 2012 10:57:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 10:57:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 10:57:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 11:57:03 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScDvD-0008CC-1f; Wed, 06 Jun 2012 10:57:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScDvD-00064V-1C;
	Wed, 06 Jun 2012 11:57:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.14207.24074.538390@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 11:57:03 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1338979707.6152.18.camel@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
	<1338979707.6152.18.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [PATCH] xl: check for meaningful combination of sedf config file parameters"):
> On Wed, 2012-06-06 at 11:41 +0100, Ian Jackson wrote:
> > Why does xl continue after libxl_domain_sched_params_set fails ?
> 
> Well, that I really don't know. It has always been like this I guess, it
> just print the related error about inconsistent/wrong scheduling
> parameters and then the domain is created with default ones.
> 
> Should we/I stop it?

Please, yes.  In general libxl's error handling is rather poor in
places (although a lot of it has been improved).

Where you notice that (a) the thing you wanted to do doesn't work and
(b) xl blunders on anyway, it's best to fix (b) first, while you still
have the test case, and then (a) :-).

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 Jun 06 11:05:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:05: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 1ScE3T-0002g1-5T; Wed, 06 Jun 2012 11:05:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScE3R-0002fw-7l
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:05:33 +0000
Received: from [85.158.138.51:10509] by server-5.bemta-3.messagelabs.com id
	0D/8D-03598-C793FCF4; Wed, 06 Jun 2012 11:05:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1338980731!24687441!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1453 invoked from network); 6 Jun 2012 11:05:31 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-174.messagelabs.com with SMTP;
	6 Jun 2012 11:05:31 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689761; Wed, 06 Jun 2012 13:05:28 +0200
Message-ID: <1338980722.6152.30.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 13:05:22 +0200
In-Reply-To: <1338978936.32319.49.camel@zakaz.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<1338978936.32319.49.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7662033446885818681=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7662033446885818681==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-2Q8hCKkrWPimJ6U+OgrQ"


--=-2Q8hCKkrWPimJ6U+OgrQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 11:35 +0100, Ian Campbell wrote:
> > 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
> > @@ -561,6 +561,7 @@ static void parse_config_data(const char
> >      long l;
> >      XLU_Config *config;
> >      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> > +    int opt_w =3D 0, opt_p =3D 0, opt_s =3D 0;
>=20
> These names don't make much sense in this context.
>=20
Yeah, I agree... It's just I needed something :-/

> Perhaps you can just check each interesting option against the
> corresponding LIBXL_DOAIN_SCHED_PARAM_DEFAULT?=20
>
Mmm... I was mistakenly thinking these default values not to be there
yet, but I now see it. Yes, I guess I can do that.

> That might make some long
> lines. Perhaps pulling this out into a separate valid_sched_params()
> would help with that?
>
Maybe, but what to put here depends on your thought on the below...

> >      if (!xlu_cfg_get_long (config, "latency", &l, 0))
> >          b_info->sched_params.latency =3D l;
> >      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
> >          b_info->sched_params.extratime =3D l;
> > +    /* The sedf scheduler needs some more consistency checking */
> > +    if (opt_w && (opt_p || opt_s)) {
> > +        fprintf(stderr, "Either specify a weight OR a period and slice=
\n");
>=20
> Does this constrain you from setting valid combinations of credit*
> parameters? I think not since period and slice are SEDF specific.
>=20
I'd say not at all, for the exact reason you're suggesting. Then, if you
ask what happens if you boot with sched=3Dcredit and then try to specify
both a cpu_weight and a period, then yes, it will kick you out.

The whole point is, period and slice are only meaningful for sedf so, if
you are using them, I take it like you meant to be using sedf, and thus
asking for a cpu_weight at the same time is wrong.

Of course, one can think at it the other way around (scheduler is
credit, so cpu_weight is fine and period and slice should be ignored).
If that is better, I can add a libxl_is_the_scheduler_credit? kind of
check to that if...

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-2Q8hCKkrWPimJ6U+OgrQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/POXIACgkQk4XaBE3IOsRwfwCgkR0woiL/MLJ5wLoSSskFa3wS
nZ4AnAiRZfZpjuw30XtdTNp1we+PB+RN
=MT0A
-----END PGP SIGNATURE-----

--=-2Q8hCKkrWPimJ6U+OgrQ--



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

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

--===============7662033446885818681==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:05:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:05: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 1ScE3T-0002g1-5T; Wed, 06 Jun 2012 11:05:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScE3R-0002fw-7l
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:05:33 +0000
Received: from [85.158.138.51:10509] by server-5.bemta-3.messagelabs.com id
	0D/8D-03598-C793FCF4; Wed, 06 Jun 2012 11:05:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1338980731!24687441!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1453 invoked from network); 6 Jun 2012 11:05:31 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-174.messagelabs.com with SMTP;
	6 Jun 2012 11:05:31 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689761; Wed, 06 Jun 2012 13:05:28 +0200
Message-ID: <1338980722.6152.30.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 13:05:22 +0200
In-Reply-To: <1338978936.32319.49.camel@zakaz.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<1338978936.32319.49.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7662033446885818681=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7662033446885818681==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-2Q8hCKkrWPimJ6U+OgrQ"


--=-2Q8hCKkrWPimJ6U+OgrQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 11:35 +0100, Ian Campbell wrote:
> > 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
> > @@ -561,6 +561,7 @@ static void parse_config_data(const char
> >      long l;
> >      XLU_Config *config;
> >      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> > +    int opt_w =3D 0, opt_p =3D 0, opt_s =3D 0;
>=20
> These names don't make much sense in this context.
>=20
Yeah, I agree... It's just I needed something :-/

> Perhaps you can just check each interesting option against the
> corresponding LIBXL_DOAIN_SCHED_PARAM_DEFAULT?=20
>
Mmm... I was mistakenly thinking these default values not to be there
yet, but I now see it. Yes, I guess I can do that.

> That might make some long
> lines. Perhaps pulling this out into a separate valid_sched_params()
> would help with that?
>
Maybe, but what to put here depends on your thought on the below...

> >      if (!xlu_cfg_get_long (config, "latency", &l, 0))
> >          b_info->sched_params.latency =3D l;
> >      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
> >          b_info->sched_params.extratime =3D l;
> > +    /* The sedf scheduler needs some more consistency checking */
> > +    if (opt_w && (opt_p || opt_s)) {
> > +        fprintf(stderr, "Either specify a weight OR a period and slice=
\n");
>=20
> Does this constrain you from setting valid combinations of credit*
> parameters? I think not since period and slice are SEDF specific.
>=20
I'd say not at all, for the exact reason you're suggesting. Then, if you
ask what happens if you boot with sched=3Dcredit and then try to specify
both a cpu_weight and a period, then yes, it will kick you out.

The whole point is, period and slice are only meaningful for sedf so, if
you are using them, I take it like you meant to be using sedf, and thus
asking for a cpu_weight at the same time is wrong.

Of course, one can think at it the other way around (scheduler is
credit, so cpu_weight is fine and period and slice should be ignored).
If that is better, I can add a libxl_is_the_scheduler_credit? kind of
check to that if...

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-2Q8hCKkrWPimJ6U+OgrQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/POXIACgkQk4XaBE3IOsRwfwCgkR0woiL/MLJ5wLoSSskFa3wS
nZ4AnAiRZfZpjuw30XtdTNp1we+PB+RN
=MT0A
-----END PGP SIGNATURE-----

--=-2Q8hCKkrWPimJ6U+OgrQ--



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

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

--===============7662033446885818681==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:07:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScE5E-0002nm-Ln; Wed, 06 Jun 2012 11:07: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 1ScE5D-0002nU-W7
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:07:24 +0000
Received: from [85.158.138.51:24483] by server-7.bemta-3.messagelabs.com id
	99/E8-01983-BE93FCF4; Wed, 06 Jun 2012 11:07:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1338980842!26992807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9410 invoked from network); 6 Jun 2012 11:07:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:07:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 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.213.0; Wed, 6 Jun 2012
	12:07:21 +0100
Message-ID: <1338980840.32319.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 12:07:20 +0100
In-Reply-To: <1338980722.6152.30.camel@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<1338978936.32319.49.camel@zakaz.uk.xensource.com>
	<1338980722.6152.30.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 12:05 +0100, Dario Faggioli wrote:
> On Wed, 2012-06-06 at 11:35 +0100, Ian Campbell wrote:
> > > 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
> > > @@ -561,6 +561,7 @@ static void parse_config_data(const char
> > >      long l;
> > >      XLU_Config *config;
> > >      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> > > +    int opt_w = 0, opt_p = 0, opt_s = 0;
> > 
> > These names don't make much sense in this context.
> > 
> Yeah, I agree... It's just I needed something :-/
> 
> > Perhaps you can just check each interesting option against the
> > corresponding LIBXL_DOAIN_SCHED_PARAM_DEFAULT? 
> >
> Mmm... I was mistakenly thinking these default values not to be there
> yet, but I now see it. Yes, I guess I can do that.
> 
> > That might make some long
> > lines. Perhaps pulling this out into a separate valid_sched_params()
> > would help with that?
> >
> Maybe, but what to put here depends on your thought on the below...
> 
> > >      if (!xlu_cfg_get_long (config, "latency", &l, 0))
> > >          b_info->sched_params.latency = l;
> > >      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
> > >          b_info->sched_params.extratime = l;
> > > +    /* The sedf scheduler needs some more consistency checking */
> > > +    if (opt_w && (opt_p || opt_s)) {
> > > +        fprintf(stderr, "Either specify a weight OR a period and slice\n");
> > 
> > Does this constrain you from setting valid combinations of credit*
> > parameters? I think not since period and slice are SEDF specific.
> > 
> I'd say not at all, for the exact reason you're suggesting. Then, if you
> ask what happens if you boot with sched=credit and then try to specify
> both a cpu_weight and a period, then yes, it will kick you out.
> 
> The whole point is, period and slice are only meaningful for sedf so, if
> you are using them, I take it like you meant to be using sedf, and thus
> asking for a cpu_weight at the same time is wrong.
> 
> Of course, one can think at it the other way around (scheduler is
> credit, so cpu_weight is fine and period and slice should be ignored).
> If that is better, I can add a libxl_is_the_scheduler_credit? kind of
> check to that if...

Lets keep it simple for now and go with the "don't do that" answer --
i.e. reject as invalid setting weight and period regardless of the
actual scheduler in use.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:07:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScE5E-0002nm-Ln; Wed, 06 Jun 2012 11:07: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 1ScE5D-0002nU-W7
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:07:24 +0000
Received: from [85.158.138.51:24483] by server-7.bemta-3.messagelabs.com id
	99/E8-01983-BE93FCF4; Wed, 06 Jun 2012 11:07:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1338980842!26992807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9410 invoked from network); 6 Jun 2012 11:07:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:07:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 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.213.0; Wed, 6 Jun 2012
	12:07:21 +0100
Message-ID: <1338980840.32319.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 12:07:20 +0100
In-Reply-To: <1338980722.6152.30.camel@Solace>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<1338978936.32319.49.camel@zakaz.uk.xensource.com>
	<1338980722.6152.30.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 12:05 +0100, Dario Faggioli wrote:
> On Wed, 2012-06-06 at 11:35 +0100, Ian Campbell wrote:
> > > 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
> > > @@ -561,6 +561,7 @@ static void parse_config_data(const char
> > >      long l;
> > >      XLU_Config *config;
> > >      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> > > +    int opt_w = 0, opt_p = 0, opt_s = 0;
> > 
> > These names don't make much sense in this context.
> > 
> Yeah, I agree... It's just I needed something :-/
> 
> > Perhaps you can just check each interesting option against the
> > corresponding LIBXL_DOAIN_SCHED_PARAM_DEFAULT? 
> >
> Mmm... I was mistakenly thinking these default values not to be there
> yet, but I now see it. Yes, I guess I can do that.
> 
> > That might make some long
> > lines. Perhaps pulling this out into a separate valid_sched_params()
> > would help with that?
> >
> Maybe, but what to put here depends on your thought on the below...
> 
> > >      if (!xlu_cfg_get_long (config, "latency", &l, 0))
> > >          b_info->sched_params.latency = l;
> > >      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
> > >          b_info->sched_params.extratime = l;
> > > +    /* The sedf scheduler needs some more consistency checking */
> > > +    if (opt_w && (opt_p || opt_s)) {
> > > +        fprintf(stderr, "Either specify a weight OR a period and slice\n");
> > 
> > Does this constrain you from setting valid combinations of credit*
> > parameters? I think not since period and slice are SEDF specific.
> > 
> I'd say not at all, for the exact reason you're suggesting. Then, if you
> ask what happens if you boot with sched=credit and then try to specify
> both a cpu_weight and a period, then yes, it will kick you out.
> 
> The whole point is, period and slice are only meaningful for sedf so, if
> you are using them, I take it like you meant to be using sedf, and thus
> asking for a cpu_weight at the same time is wrong.
> 
> Of course, one can think at it the other way around (scheduler is
> credit, so cpu_weight is fine and period and slice should be ignored).
> If that is better, I can add a libxl_is_the_scheduler_credit? kind of
> check to that if...

Lets keep it simple for now and go with the "don't do that" answer --
i.e. reject as invalid setting weight and period regardless of the
actual scheduler in use.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScE7w-00032q-7e; Wed, 06 Jun 2012 11:10:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScE7u-00032g-Dz
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:10:10 +0000
Received: from [193.109.254.147:55815] by server-8.bemta-14.messagelabs.com id
	B6/08-27132-19A3FCF4; Wed, 06 Jun 2012 11:10:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338981008!7891531!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6238 invoked from network); 6 Jun 2012 11:10:08 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-27.messagelabs.com with SMTP;
	6 Jun 2012 11:10:08 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689875; Wed, 06 Jun 2012 13:10:08 +0200
Message-ID: <1338981002.6152.32.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 06 Jun 2012 13:10:02 +0200
In-Reply-To: <20431.13618.66803.683850@mariner.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13618.66803.683850@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3819417051944688331=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3819417051944688331==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-w+8kv2PeV+OP+2KBhIIj"


--=-w+8kv2PeV+OP+2KBhIIj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 11:47 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 1 of 1 v5] libxl: introduce LIBXL_DOMAIN_T=
YPE_INVALID"):
> > To avoid recent gcc complaining about:
> > libxl.c: In function =E2=80=98libxl_primary_console_exec=E2=80=99:
> > libxl.c:1233:9: error: case value =E2=80=984294967295=E2=80=99 not in e=
numerated type =E2=80=98libxl_domain_type=E2=80=99 [-Werror=3Dswitch]
> ...
> > +    if (type =3D=3D LIBXL_DOMAIN_TYPE_INVALID) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                   "invalid domain type for domain %d", domid);
> > +        rc =3D ERROR_INVAL;
> > +        goto remus_fail;
>=20
> This is not an expected error condition, is it ?  ERROR_INVAL is for
> libxl being passed impromper parameters.  So I think this should be
> ERROR_FAIL.
>=20
Sounds reasonable, will fix.

> > @@ -692,11 +699,20 @@ int libxl_domain_suspend(libxl_ctx *ctx,
> >      int debug =3D info !=3D NULL && info->flags & XL_SUSPEND_DEBUG;
> >      int rc =3D 0;
> > =20
> > +    if (type =3D=3D LIBXL_DOMAIN_TYPE_INVALID) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                   "invalid domain type for domain %d", domid);
> > +        rc =3D ERROR_INVAL;
> > +        goto suspend_fail;
> > +    }
>=20
> Is it possible for you to leave this part alone ?  It's moved about a
> lot in my suspend/resume series.
>=20
> I will fix it up at the end of my series.
>=20
Ok.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-w+8kv2PeV+OP+2KBhIIj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/POooACgkQk4XaBE3IOsTgZgCdFS7ErVfIT3fpEY/n+ZBGM+6L
QSgAmweZ/kwUNWCcQuXLjB3MSfMuSWKj
=ghXD
-----END PGP SIGNATURE-----

--=-w+8kv2PeV+OP+2KBhIIj--



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

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

--===============3819417051944688331==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScE7w-00032q-7e; Wed, 06 Jun 2012 11:10:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScE7u-00032g-Dz
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:10:10 +0000
Received: from [193.109.254.147:55815] by server-8.bemta-14.messagelabs.com id
	B6/08-27132-19A3FCF4; Wed, 06 Jun 2012 11:10:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1338981008!7891531!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6238 invoked from network); 6 Jun 2012 11:10:08 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-27.messagelabs.com with SMTP;
	6 Jun 2012 11:10:08 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689875; Wed, 06 Jun 2012 13:10:08 +0200
Message-ID: <1338981002.6152.32.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 06 Jun 2012 13:10:02 +0200
In-Reply-To: <20431.13618.66803.683850@mariner.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13618.66803.683850@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3819417051944688331=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3819417051944688331==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-w+8kv2PeV+OP+2KBhIIj"


--=-w+8kv2PeV+OP+2KBhIIj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 11:47 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 1 of 1 v5] libxl: introduce LIBXL_DOMAIN_T=
YPE_INVALID"):
> > To avoid recent gcc complaining about:
> > libxl.c: In function =E2=80=98libxl_primary_console_exec=E2=80=99:
> > libxl.c:1233:9: error: case value =E2=80=984294967295=E2=80=99 not in e=
numerated type =E2=80=98libxl_domain_type=E2=80=99 [-Werror=3Dswitch]
> ...
> > +    if (type =3D=3D LIBXL_DOMAIN_TYPE_INVALID) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                   "invalid domain type for domain %d", domid);
> > +        rc =3D ERROR_INVAL;
> > +        goto remus_fail;
>=20
> This is not an expected error condition, is it ?  ERROR_INVAL is for
> libxl being passed impromper parameters.  So I think this should be
> ERROR_FAIL.
>=20
Sounds reasonable, will fix.

> > @@ -692,11 +699,20 @@ int libxl_domain_suspend(libxl_ctx *ctx,
> >      int debug =3D info !=3D NULL && info->flags & XL_SUSPEND_DEBUG;
> >      int rc =3D 0;
> > =20
> > +    if (type =3D=3D LIBXL_DOMAIN_TYPE_INVALID) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                   "invalid domain type for domain %d", domid);
> > +        rc =3D ERROR_INVAL;
> > +        goto suspend_fail;
> > +    }
>=20
> Is it possible for you to leave this part alone ?  It's moved about a
> lot in my suspend/resume series.
>=20
> I will fix it up at the end of my series.
>=20
Ok.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-w+8kv2PeV+OP+2KBhIIj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/POooACgkQk4XaBE3IOsTgZgCdFS7ErVfIT3fpEY/n+ZBGM+6L
QSgAmweZ/kwUNWCcQuXLjB3MSfMuSWKj
=ghXD
-----END PGP SIGNATURE-----

--=-w+8kv2PeV+OP+2KBhIIj--



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

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

--===============3819417051944688331==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScE8F-00035N-Kn; Wed, 06 Jun 2012 11:10:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScE8E-000353-48
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:10:30 +0000
Received: from [85.158.143.35:62550] by server-2.bemta-4.messagelabs.com id
	5D/7A-17938-5AA3FCF4; Wed, 06 Jun 2012 11:10:29 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338981025!14267076!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4722 invoked from network); 6 Jun 2012 11:10:27 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:10:27 -0000
Received: by obfk16 with SMTP id k16so8660383obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 04:10:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=MLUGKF4lYOdutFraXBJZ0pAWG6DCQFsoQvYcQ/yegvY=;
	b=UhT4lmUtypJWsYikOHo8Oup6PbMbaFFPe4L78+lmznCfCjaUWkVQvU12BM4JiUVFJu
	FzBSihFEiCbknbma53fPvbGiPT5zopDfTRuOIgn4QYSEvVGCEUOqXJ5V2MXAS89AoTI3
	1PNAx1ZvI4Wq/edk4C7qf1vrh2uyIn1Uzm7vHO9sg74DcDwaRUR1fhpkAvGLBegdjYXE
	k+rwdr+PMh7nOR4EAZjdovzcfSnTa0iPWygn/62fim6CYbfywY0V/oZ6dRMAN5sH06EG
	tgVYsaPWHcTRmBwsRQssC1xaa7UFzmyaQns68QBzUBR2qjaAUmg4HaGqVLgmqcIwBe4G
	obPA==
MIME-Version: 1.0
Received: by 10.182.13.74 with SMTP id f10mr19776592obc.36.1338981024961; Wed,
	06 Jun 2012 04:10:24 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 04:10:24 -0700 (PDT)
In-Reply-To: <20431.13828.982906.240702@mariner.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<20431.13828.982906.240702@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 19:10:24 +0800
Message-ID: <CAAh7U5P_WX=E6A77Z51M4wLPnEx52wVXc3rKB-6CmavMFO=_7Q@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 6, 2012 at 6:50 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wro=
te:
> ZhouPeng writes ("[Xen-devel] [PATCH 1/3] libxl:refactor stdvga option su=
pport v2"):
>> description:
>> tools:libxl: refactor stdvga opinon support.
>>
>> Be ready to add and describe new vga interface
>
> Thanks.
>
> If Ian C is happy with the idl changes then I am happy with this
> interface change for 4.2.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> However I think patches 2 and 3 of your series come too late for the
> 4.2 freeze. =A0Thanks for showing them to us, though. =A0We should
> reconsider them after 4.2.

It's ok to wait until the 4.3 dev cycle.

Thanks.
> Ian.



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScE8F-00035N-Kn; Wed, 06 Jun 2012 11:10:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScE8E-000353-48
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:10:30 +0000
Received: from [85.158.143.35:62550] by server-2.bemta-4.messagelabs.com id
	5D/7A-17938-5AA3FCF4; Wed, 06 Jun 2012 11:10:29 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338981025!14267076!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4722 invoked from network); 6 Jun 2012 11:10:27 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:10:27 -0000
Received: by obfk16 with SMTP id k16so8660383obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 04:10:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=MLUGKF4lYOdutFraXBJZ0pAWG6DCQFsoQvYcQ/yegvY=;
	b=UhT4lmUtypJWsYikOHo8Oup6PbMbaFFPe4L78+lmznCfCjaUWkVQvU12BM4JiUVFJu
	FzBSihFEiCbknbma53fPvbGiPT5zopDfTRuOIgn4QYSEvVGCEUOqXJ5V2MXAS89AoTI3
	1PNAx1ZvI4Wq/edk4C7qf1vrh2uyIn1Uzm7vHO9sg74DcDwaRUR1fhpkAvGLBegdjYXE
	k+rwdr+PMh7nOR4EAZjdovzcfSnTa0iPWygn/62fim6CYbfywY0V/oZ6dRMAN5sH06EG
	tgVYsaPWHcTRmBwsRQssC1xaa7UFzmyaQns68QBzUBR2qjaAUmg4HaGqVLgmqcIwBe4G
	obPA==
MIME-Version: 1.0
Received: by 10.182.13.74 with SMTP id f10mr19776592obc.36.1338981024961; Wed,
	06 Jun 2012 04:10:24 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 04:10:24 -0700 (PDT)
In-Reply-To: <20431.13828.982906.240702@mariner.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<20431.13828.982906.240702@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 19:10:24 +0800
Message-ID: <CAAh7U5P_WX=E6A77Z51M4wLPnEx52wVXc3rKB-6CmavMFO=_7Q@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 6, 2012 at 6:50 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wro=
te:
> ZhouPeng writes ("[Xen-devel] [PATCH 1/3] libxl:refactor stdvga option su=
pport v2"):
>> description:
>> tools:libxl: refactor stdvga opinon support.
>>
>> Be ready to add and describe new vga interface
>
> Thanks.
>
> If Ian C is happy with the idl changes then I am happy with this
> interface change for 4.2.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> However I think patches 2 and 3 of your series come too late for the
> 4.2 freeze. =A0Thanks for showing them to us, though. =A0We should
> reconsider them after 4.2.

It's ok to wait until the 4.3 dev cycle.

Thanks.
> Ian.



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScE94-0003F7-A0; Wed, 06 Jun 2012 11:11:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScE93-0003Ev-Ax
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:11:21 +0000
Received: from [85.158.143.99:36712] by server-2.bemta-4.messagelabs.com id
	BB/FB-17938-8DA3FCF4; Wed, 06 Jun 2012 11:11:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-216.messagelabs.com!1338981080!21770871!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18052 invoked from network); 6 Jun 2012 11:11:20 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-216.messagelabs.com with SMTP;
	6 Jun 2012 11:11:20 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689941; Wed, 06 Jun 2012 13:11:18 +0200
Message-ID: <1338981073.6152.34.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 06 Jun 2012 13:11:13 +0200
In-Reply-To: <20431.13389.87069.507313@mariner.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13389.87069.507313@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5166380916305741939=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5166380916305741939==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HmUMJc8Q1jMVvc2MR8Gz"


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

On Wed, 2012-06-06 at 11:43 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 1 of 1 v5] libxl: introduce LIBXL_DOMAIN_T=
YPE_INVALID"):
> > To avoid recent gcc complaining about:
> > libxl.c: In function =E2=80=98libxl_primary_console_exec=E2=80=99:
>=20
> Can you please avoid these non-ascii quotes in commit messages ?  It
> makes my life unnecessarily difficult when applying patches.  Any of
> `...', '...' and "..." are fine.
>=20
Sure, sorry... Cut'n'pasting from gnome-terminal into vim has apparently
produced monsters... :-/

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-HmUMJc8Q1jMVvc2MR8Gz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/POtEACgkQk4XaBE3IOsRtrACfUNLjSyC65oe+MfHTgdpl8Y+H
q78AoIJGUQnzGUBo7vQfa25BGs9Mmko9
=8Uc8
-----END PGP SIGNATURE-----

--=-HmUMJc8Q1jMVvc2MR8Gz--



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

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

--===============5166380916305741939==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScE94-0003F7-A0; Wed, 06 Jun 2012 11:11:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScE93-0003Ev-Ax
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:11:21 +0000
Received: from [85.158.143.99:36712] by server-2.bemta-4.messagelabs.com id
	BB/FB-17938-8DA3FCF4; Wed, 06 Jun 2012 11:11:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-216.messagelabs.com!1338981080!21770871!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18052 invoked from network); 6 Jun 2012 11:11:20 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-216.messagelabs.com with SMTP;
	6 Jun 2012 11:11:20 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78689941; Wed, 06 Jun 2012 13:11:18 +0200
Message-ID: <1338981073.6152.34.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 06 Jun 2012 13:11:13 +0200
In-Reply-To: <20431.13389.87069.507313@mariner.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13389.87069.507313@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5166380916305741939=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5166380916305741939==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HmUMJc8Q1jMVvc2MR8Gz"


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

On Wed, 2012-06-06 at 11:43 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 1 of 1 v5] libxl: introduce LIBXL_DOMAIN_T=
YPE_INVALID"):
> > To avoid recent gcc complaining about:
> > libxl.c: In function =E2=80=98libxl_primary_console_exec=E2=80=99:
>=20
> Can you please avoid these non-ascii quotes in commit messages ?  It
> makes my life unnecessarily difficult when applying patches.  Any of
> `...', '...' and "..." are fine.
>=20
Sure, sorry... Cut'n'pasting from gnome-terminal into vim has apparently
produced monsters... :-/

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-HmUMJc8Q1jMVvc2MR8Gz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/POtEACgkQk4XaBE3IOsRtrACfUNLjSyC65oe+MfHTgdpl8Y+H
q78AoIJGUQnzGUBo7vQfa25BGs9Mmko9
=8Uc8
-----END PGP SIGNATURE-----

--=-HmUMJc8Q1jMVvc2MR8Gz--



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

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

--===============5166380916305741939==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:12:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:12: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 1ScEAK-0003RI-Pw; Wed, 06 Jun 2012 11:12:40 +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 1ScEAJ-0003R6-N0
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:12:39 +0000
Received: from [193.109.254.147:26657] by server-11.bemta-14.messagelabs.com
	id B9/B0-02727-72B3FCF4; Wed, 06 Jun 2012 11:12:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338981157!12854165!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 6 Jun 2012 11:12:38 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:12:38 -0000
Received: by qaeb19 with SMTP id b19so3007674qae.11
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 04:12:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=AD617qRISwmP4wwZL6rbl2fU7owqEYzRskighKXQ59w=;
	b=U49co4YVHXv84zNCHpL1e6onRt/25anAoedkb9yMtvT/s0dWzRUXSsLd7bgvNorkFA
	zvBJ5N7rD0KaYz4KvebcJEv//dyN6LbNKV4tqJWI5v3GZa4rUXj7ReyCzZOdlvsqNS9U
	LFxtMcEjrPEQPbzNe4GMCpPmxaF1MAVhvDS1cLRCd8j25Xad52HQ5XgClaJ2cdP1MAJh
	bpczSuGpVblAzF8foQt/4AI85SNF1c72X/eFJoX20GH1G5MbkkyhtxwHfNhOpzvpWcxf
	BJQOF6CWv0w3wAIaUaP9P4ZgQjJlYUjg1aUJy9Az8OupMrb+y4XidwaQHF+UDFQEtOe/
	xmzw==
MIME-Version: 1.0
Received: by 10.229.134.193 with SMTP id k1mr490689qct.64.1338981157066; Wed,
	06 Jun 2012 04:12:37 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 04:12:37 -0700 (PDT)
In-Reply-To: <CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com>
References: <CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com>
Date: Wed, 6 Jun 2012 12:12:37 +0100
X-Google-Sender-Auth: 4kX64oSiPbjANF3A4pQHalFYU4w
Message-ID: <CAFLBxZaOWtiTDwBn-=H3Z51Pybv=2+z2Fy2w7ED6VEtuaPH5Fg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Zhou Jacky <jackyzt98@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [bug report] Windows HVM Hang when reboot/power off
 using special config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 5, 2012 at 4:46 AM, Zhou Jacky <jackyzt98@gmail.com> wrote:
> In my case, the qemu_system_shutdown_request ( ACPI register write ) never
> be triggered. And the VCPU usage be 100 percent.
> So I think it must exist some spinlock-like code in guest OS which cause =
the
> ACPI write never be executed.
> If I pin one VCPU to another CPU like '6', then ACPI register write be
> called immediately, guest OS poweroff smoothly.
>
> So anyone know=A0why it's not work when PIN 2 VCPUs to same physical CPU =
when
> booting HVM Windows 2003? Thanks.

I think you've already given the most probable answer your own
question -- there must be some kind of synchronization that the guest
OS is doing, probably relating to gracefully bringing down secondary
cpus, that breaks when you pin them to a single core.

 -George

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:12:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:12: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 1ScEAK-0003RI-Pw; Wed, 06 Jun 2012 11:12:40 +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 1ScEAJ-0003R6-N0
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:12:39 +0000
Received: from [193.109.254.147:26657] by server-11.bemta-14.messagelabs.com
	id B9/B0-02727-72B3FCF4; Wed, 06 Jun 2012 11:12:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338981157!12854165!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 6 Jun 2012 11:12:38 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:12:38 -0000
Received: by qaeb19 with SMTP id b19so3007674qae.11
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 04:12:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=AD617qRISwmP4wwZL6rbl2fU7owqEYzRskighKXQ59w=;
	b=U49co4YVHXv84zNCHpL1e6onRt/25anAoedkb9yMtvT/s0dWzRUXSsLd7bgvNorkFA
	zvBJ5N7rD0KaYz4KvebcJEv//dyN6LbNKV4tqJWI5v3GZa4rUXj7ReyCzZOdlvsqNS9U
	LFxtMcEjrPEQPbzNe4GMCpPmxaF1MAVhvDS1cLRCd8j25Xad52HQ5XgClaJ2cdP1MAJh
	bpczSuGpVblAzF8foQt/4AI85SNF1c72X/eFJoX20GH1G5MbkkyhtxwHfNhOpzvpWcxf
	BJQOF6CWv0w3wAIaUaP9P4ZgQjJlYUjg1aUJy9Az8OupMrb+y4XidwaQHF+UDFQEtOe/
	xmzw==
MIME-Version: 1.0
Received: by 10.229.134.193 with SMTP id k1mr490689qct.64.1338981157066; Wed,
	06 Jun 2012 04:12:37 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 04:12:37 -0700 (PDT)
In-Reply-To: <CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com>
References: <CAMT9dFFO05SLzc8GoF288AT08a5SJvzS77MMbCFdxtJ8_pHeVg@mail.gmail.com>
Date: Wed, 6 Jun 2012 12:12:37 +0100
X-Google-Sender-Auth: 4kX64oSiPbjANF3A4pQHalFYU4w
Message-ID: <CAFLBxZaOWtiTDwBn-=H3Z51Pybv=2+z2Fy2w7ED6VEtuaPH5Fg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Zhou Jacky <jackyzt98@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [bug report] Windows HVM Hang when reboot/power off
 using special config
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 5, 2012 at 4:46 AM, Zhou Jacky <jackyzt98@gmail.com> wrote:
> In my case, the qemu_system_shutdown_request ( ACPI register write ) never
> be triggered. And the VCPU usage be 100 percent.
> So I think it must exist some spinlock-like code in guest OS which cause =
the
> ACPI write never be executed.
> If I pin one VCPU to another CPU like '6', then ACPI register write be
> called immediately, guest OS poweroff smoothly.
>
> So anyone know=A0why it's not work when PIN 2 VCPUs to same physical CPU =
when
> booting HVM Windows 2003? Thanks.

I think you've already given the most probable answer your own
question -- there must be some kind of synchronization that the guest
OS is doing, probably relating to gracefully bringing down secondary
cpus, that breaks when you pin them to a single core.

 -George

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:15:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:15: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 1ScED7-0003jQ-Dh; Wed, 06 Jun 2012 11:15:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScED5-0003jD-6O
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:15:31 +0000
Received: from [85.158.143.35:19270] by server-2.bemta-4.messagelabs.com id
	76/A2-17938-2DB3FCF4; Wed, 06 Jun 2012 11:15:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1338981322!8100988!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4969 invoked from network); 6 Jun 2012 11:15:23 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-21.messagelabs.com with SMTP;
	6 Jun 2012 11:15:23 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78690031; Wed, 06 Jun 2012 13:15:22 +0200
Message-ID: <1338981316.6152.37.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 13:15:16 +0200
In-Reply-To: <1338980214.32319.52.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13618.66803.683850@mariner.uk.xensource.com>
	<1338980214.32319.52.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7165024313800194691=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7165024313800194691==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-VkduEtrRndLv9Sg7psFr"


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

On Wed, 2012-06-06 at 11:56 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 11:47 +0100, Ian Jackson wrote:
> > Dario Faggioli writes ("[PATCH 1 of 1 v5] libxl: introduce LIBXL_DOMAIN=
_TYPE_INVALID"):
> > > To avoid recent gcc complaining about:
> > > libxl.c: In function =E2=80=98libxl_primary_console_exec=E2=80=99:
> > > libxl.c:1233:9: error: case value =E2=80=984294967295=E2=80=99 not in=
 enumerated type =E2=80=98libxl_domain_type=E2=80=99 [-Werror=3Dswitch]
> > ...
> > > +    if (type =3D=3D LIBXL_DOMAIN_TYPE_INVALID) {
> > > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > > +                   "invalid domain type for domain %d", domid);
> > > +        rc =3D ERROR_INVAL;
> > > +        goto remus_fail;
> >=20
> > This is not an expected error condition, is it ?  ERROR_INVAL is for
> > libxl being passed impromper parameters.  So I think this should be
> > ERROR_FAIL.
>=20
> Also perhaps the logging should be done in libxl__domain_type?=20
>
That makes sense to me...

> Unless
> there are too many legitimate occasions where INVALID might come up?
>=20
I might be wrong but I don't think so. There might be some more printing
than with this patch, but mostly before some 'default: abort();'
situation so...

Anyway, I'll do it and try to see how it behaves.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-VkduEtrRndLv9Sg7psFr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/PO8QACgkQk4XaBE3IOsRQZgCeOQx6TpWBMWDKUi1YBDZ9VMCF
HTQAnApx3MhVfVE04AKtWadtiJLGSplc
=DE9m
-----END PGP SIGNATURE-----

--=-VkduEtrRndLv9Sg7psFr--



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

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

--===============7165024313800194691==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:15:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:15: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 1ScED7-0003jQ-Dh; Wed, 06 Jun 2012 11:15:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScED5-0003jD-6O
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:15:31 +0000
Received: from [85.158.143.35:19270] by server-2.bemta-4.messagelabs.com id
	76/A2-17938-2DB3FCF4; Wed, 06 Jun 2012 11:15:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1338981322!8100988!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4969 invoked from network); 6 Jun 2012 11:15:23 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-21.messagelabs.com with SMTP;
	6 Jun 2012 11:15:23 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78690031; Wed, 06 Jun 2012 13:15:22 +0200
Message-ID: <1338981316.6152.37.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 13:15:16 +0200
In-Reply-To: <1338980214.32319.52.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338830601@Solace>
	<a5f7f05d76f9d8940121.1338830602@Solace>
	<20431.13618.66803.683850@mariner.uk.xensource.com>
	<1338980214.32319.52.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v5] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7165024313800194691=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7165024313800194691==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-VkduEtrRndLv9Sg7psFr"


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

On Wed, 2012-06-06 at 11:56 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 11:47 +0100, Ian Jackson wrote:
> > Dario Faggioli writes ("[PATCH 1 of 1 v5] libxl: introduce LIBXL_DOMAIN=
_TYPE_INVALID"):
> > > To avoid recent gcc complaining about:
> > > libxl.c: In function =E2=80=98libxl_primary_console_exec=E2=80=99:
> > > libxl.c:1233:9: error: case value =E2=80=984294967295=E2=80=99 not in=
 enumerated type =E2=80=98libxl_domain_type=E2=80=99 [-Werror=3Dswitch]
> > ...
> > > +    if (type =3D=3D LIBXL_DOMAIN_TYPE_INVALID) {
> > > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > > +                   "invalid domain type for domain %d", domid);
> > > +        rc =3D ERROR_INVAL;
> > > +        goto remus_fail;
> >=20
> > This is not an expected error condition, is it ?  ERROR_INVAL is for
> > libxl being passed impromper parameters.  So I think this should be
> > ERROR_FAIL.
>=20
> Also perhaps the logging should be done in libxl__domain_type?=20
>
That makes sense to me...

> Unless
> there are too many legitimate occasions where INVALID might come up?
>=20
I might be wrong but I don't think so. There might be some more printing
than with this patch, but mostly before some 'default: abort();'
situation so...

Anyway, I'll do it and try to see how it behaves.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-VkduEtrRndLv9Sg7psFr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/PO8QACgkQk4XaBE3IOsRQZgCeOQx6TpWBMWDKUi1YBDZ9VMCF
HTQAnApx3MhVfVE04AKtWadtiJLGSplc
=DE9m
-----END PGP SIGNATURE-----

--=-VkduEtrRndLv9Sg7psFr--



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

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

--===============7165024313800194691==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 11:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:21: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 1ScEIk-0003wH-82; Wed, 06 Jun 2012 11:21: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 1ScEIj-0003wC-H4
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:21:21 +0000
Received: from [85.158.138.51:13317] by server-9.bemta-3.messagelabs.com id
	13/1F-15054-03D3FCF4; Wed, 06 Jun 2012 11:21:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338981680!22146300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23889 invoked from network); 6 Jun 2012 11:21:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:20:48 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 12:20:48 +0100
Date: Wed, 6 Jun 2012 12:20:40 +0100
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.1206051814030.6030@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Tim Deegan <Tim.Deegan@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/5] xen/arm: multiple guests support in the GIC
	and VGIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series fixes the GIC, VGIC and vtimer issues that caused dom1
to hang, as described by Ian in
http://marc.info/?l=xen-devel&m=133856539418794.

With this patch series applied on top of Ian's, dom1 boots up to:

VFS: Cannot open root device "(null)" or unknown-block(2,0)


Stefano Stabellini (5):
      arm/vtimer: do not let the guest interact with the physical timer
      arm/gic: fix gic context switch
      xen/gic: support injecting IRQs even to VCPUs not currently running
      xen/vgic: vgic: support irq enable/disable
      xen/vgic: initialize pending_irqs.lr_queue

 xen/arch/arm/gic.c           |   76 +++++++++++++++++++++++++++++++-----------
 xen/arch/arm/gic.h           |    2 +-
 xen/arch/arm/time.c          |    4 +-
 xen/arch/arm/vgic.c          |   30 ++++++++++++++++-
 xen/include/asm-arm/domain.h |    9 +++++
 5 files changed, 97 insertions(+), 24 deletions(-)

Cheers,

Stefano

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:21: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 1ScEIk-0003wH-82; Wed, 06 Jun 2012 11:21: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 1ScEIj-0003wC-H4
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:21:21 +0000
Received: from [85.158.138.51:13317] by server-9.bemta-3.messagelabs.com id
	13/1F-15054-03D3FCF4; Wed, 06 Jun 2012 11:21:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1338981680!22146300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23889 invoked from network); 6 Jun 2012 11:21:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12856599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:20:48 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 12:20:48 +0100
Date: Wed, 6 Jun 2012 12:20:40 +0100
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.1206051814030.6030@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Tim Deegan <Tim.Deegan@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/5] xen/arm: multiple guests support in the GIC
	and VGIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series fixes the GIC, VGIC and vtimer issues that caused dom1
to hang, as described by Ian in
http://marc.info/?l=xen-devel&m=133856539418794.

With this patch series applied on top of Ian's, dom1 boots up to:

VFS: Cannot open root device "(null)" or unknown-block(2,0)


Stefano Stabellini (5):
      arm/vtimer: do not let the guest interact with the physical timer
      arm/gic: fix gic context switch
      xen/gic: support injecting IRQs even to VCPUs not currently running
      xen/vgic: vgic: support irq enable/disable
      xen/vgic: initialize pending_irqs.lr_queue

 xen/arch/arm/gic.c           |   76 +++++++++++++++++++++++++++++++-----------
 xen/arch/arm/gic.h           |    2 +-
 xen/arch/arm/time.c          |    4 +-
 xen/arch/arm/vgic.c          |   30 ++++++++++++++++-
 xen/include/asm-arm/domain.h |    9 +++++
 5 files changed, 97 insertions(+), 24 deletions(-)

Cheers,

Stefano

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJj-000406-2k; Wed, 06 Jun 2012 11:22: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 1ScEJh-0003zX-2f
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:21 +0000
Received: from [85.158.143.99:47946] by server-2.bemta-4.messagelabs.com id
	E4/DD-17938-C6D3FCF4; Wed, 06 Jun 2012 11:22:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338981738!24014470!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27841 invoked from network); 6 Jun 2012 11:22:19 -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;
	6 Jun 2012 11:22:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197706841"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-Gh;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:07 +0100
Message-ID: <1338981730-14816-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/5] arm/gic: fix gic 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

gic_save/restore_state should also save and restore lr_mask and
event_mask too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |    4 ++++
 xen/include/asm-arm/domain.h |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 3f9a061..c73f274 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -67,6 +67,8 @@ 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 = gic.lr_mask;
+    v->arch.event_mask = gic.event_mask;
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
     isb();
@@ -79,6 +81,8 @@ void gic_restore_state(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic.lr_mask = v->arch.lr_mask;
+    gic.event_mask = v->arch.event_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     GICH[GICH_HCR] = GICH_HCR_EN;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 230ea8c..3576d50 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -121,6 +121,8 @@ struct arch_vcpu
 
     uint32_t gic_hcr, gic_vmcr, gic_apr;
     uint32_t gic_lr[64];
+    uint64_t event_mask;
+    uint64_t lr_mask;
 
     struct {
         /*
-- 
1.7.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 Jun 06 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJj-000406-2k; Wed, 06 Jun 2012 11:22: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 1ScEJh-0003zX-2f
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:21 +0000
Received: from [85.158.143.99:47946] by server-2.bemta-4.messagelabs.com id
	E4/DD-17938-C6D3FCF4; Wed, 06 Jun 2012 11:22:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338981738!24014470!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27841 invoked from network); 6 Jun 2012 11:22:19 -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;
	6 Jun 2012 11:22:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197706841"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-Gh;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:07 +0100
Message-ID: <1338981730-14816-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/5] arm/gic: fix gic 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

gic_save/restore_state should also save and restore lr_mask and
event_mask too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |    4 ++++
 xen/include/asm-arm/domain.h |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 3f9a061..c73f274 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -67,6 +67,8 @@ 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 = gic.lr_mask;
+    v->arch.event_mask = gic.event_mask;
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
     isb();
@@ -79,6 +81,8 @@ void gic_restore_state(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return;
 
+    gic.lr_mask = v->arch.lr_mask;
+    gic.event_mask = v->arch.event_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     GICH[GICH_HCR] = GICH_HCR_EN;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 230ea8c..3576d50 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -121,6 +121,8 @@ struct arch_vcpu
 
     uint32_t gic_hcr, gic_vmcr, gic_apr;
     uint32_t gic_lr[64];
+    uint64_t event_mask;
+    uint64_t lr_mask;
 
     struct {
         /*
-- 
1.7.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 Jun 06 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJk-000410-OD; Wed, 06 Jun 2012 11:22:24 +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 1ScEJi-0003zp-HD
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:22 +0000
Received: from [85.158.143.99:9237] by server-1.bemta-4.messagelabs.com id
	0C/69-10042-D6D3FCF4; Wed, 06 Jun 2012 11:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338981738!24014470!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28081 invoked from network); 6 Jun 2012 11:22:21 -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;
	6 Jun 2012 11:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197706843"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-HO;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:08 +0100
Message-ID: <1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
	VCPUs not currently 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

The lr_pending list belongs to the vgic rather than the gic, so move it
there.

gic_set_guest_irq should take into account whether the vcpu is currently
running and if it is not it should add the irq to the right lr_pending
list.

When restoring the gic state we need to go through the lr_pending list
because it is possible that some irqs have been "injected" while the
vcpu wasn't running.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   66 +++++++++++++++++++++++++++++------------
 xen/arch/arm/gic.h           |    2 +-
 xen/arch/arm/vgic.c          |    3 +-
 xen/include/asm-arm/domain.h |    7 ++++
 4 files changed, 56 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index c73f274..2e41d75 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -38,6 +38,7 @@
 #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
                                      + (GIC_HR_OFFSET & 0xfff)))
 static void events_maintenance(struct vcpu *v);
+static void gic_restore_pending_irqs(struct vcpu *v);
 
 /* Global state */
 static struct {
@@ -49,13 +50,6 @@ static struct {
     spinlock_t lock;
     uint64_t event_mask;
     uint64_t lr_mask;
-    /* lr_pending is used to queue IRQs (struct pending_irq) that the
-     * vgic tried to inject in the guest (calling gic_set_guest_irq) but
-     * no LRs were available at the time.
-     * As soon as an LR is freed we remove the first IRQ from this
-     * list and write it to the LR register.
-     * lr_pending is a subset of vgic.inflight_irqs. */
-    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -87,6 +81,8 @@ void gic_restore_state(struct vcpu *v)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     GICH[GICH_HCR] = GICH_HCR_EN;
     isb();
+
+    gic_restore_pending_irqs(v);
 }
 
 static unsigned int gic_irq_startup(struct irq_desc *desc)
@@ -323,7 +319,6 @@ int __init gic_init(void)
 
     gic.lr_mask = 0ULL;
     gic.event_mask = 0ULL;
-    INIT_LIST_HEAD(&gic.lr_pending);
 
     spin_unlock(&gic.lock);
 
@@ -435,17 +430,20 @@ static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
     int i;
     struct pending_irq *iter, *n;
 
-    events_maintenance(current);
+    if ( v->is_running )
+    {
+        events_maintenance(v);
+    }
 
     spin_lock_irq(&gic.lock);
 
-    if ( list_empty(&gic.lr_pending) )
+    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
     {
         i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
         if (i < nr_lrs) {
@@ -457,8 +455,8 @@ void gic_set_guest_irq(unsigned int virtual_irq,
         }
     }
 
-    n = irq_to_pending(current, virtual_irq);
-    list_for_each_entry ( iter, &gic.lr_pending, lr_queue )
+    n = irq_to_pending(v, virtual_irq);
+    list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
     {
         if ( iter->priority > priority )
         {
@@ -466,13 +464,40 @@ void gic_set_guest_irq(unsigned int virtual_irq,
             goto out;
         }
     }
-    list_add_tail(&n->lr_queue, &gic.lr_pending);
+    list_add_tail(&n->lr_queue, &v->arch.vgic.lr_pending);
 
 out:
     spin_unlock_irq(&gic.lock);
     return;
 }
 
+static void gic_restore_pending_irqs(struct vcpu *v)
+{
+    int i;
+    struct pending_irq *p;
+
+    /* check for new pending irqs */
+    if ( list_empty(&v->arch.vgic.lr_pending) )
+        return;
+
+    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
+    {
+        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
+        if ( i < nr_lrs )
+        {
+            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+            list_del_init(&p->lr_queue);
+            set_bit(i, &gic.lr_mask);
+            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
+                set_bit(i, &gic.event_mask);
+        } else
+        {
+            return;
+        }
+    }
+
+}
+
 static void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -582,9 +607,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
 {
     int i = 0, virq;
     uint32_t lr;
+    struct vcpu *v = current;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    events_maintenance(current);
+    events_maintenance(v);
 
     while ((i = find_next_bit((const long unsigned int *) &eisr,
                               sizeof(eisr), i)) < sizeof(eisr)) {
@@ -596,8 +622,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         GICH[GICH_LR + i] = 0;
         clear_bit(i, &gic.lr_mask);
 
-        if ( !list_empty(&gic.lr_pending) ) {
-            p = list_entry(gic.lr_pending.next, typeof(*p), lr_queue);
+        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);
@@ -608,14 +634,14 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         }
         spin_unlock_irq(&gic.lock);
 
-        spin_lock(&current->arch.vgic.lock);
-        p = irq_to_pending(current, virq);
+        spin_lock(&v->arch.vgic.lock);
+        p = irq_to_pending(v, virq);
         if ( p->desc != NULL ) {
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
         list_del_init(&p->inflight);
-        spin_unlock(&current->arch.vgic.lock);
+        spin_unlock(&v->arch.vgic.lock);
 
         i++;
     }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..a55e146 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -134,7 +134,7 @@ extern void gic_route_irqs(void);
 extern void gic_inject(void);
 
 extern void __cpuinit init_maintenance_interrupt(void);
-extern void gic_set_guest_irq(unsigned int irq,
+extern void gic_set_guest_irq(struct vcpu *v, unsigned int irq,
         unsigned int state, unsigned int priority);
 extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
                                   const char * devname);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 6eb6ec7..5a624bd 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -112,6 +112,7 @@ int vcpu_vgic_init(struct vcpu *v)
             | (1<<(v->vcpu_id+16))
             | (1<<(v->vcpu_id+24));
     INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    INIT_LIST_HEAD(&v->arch.vgic.lr_pending);
     spin_lock_init(&v->arch.vgic.lock);
 
     return 0;
@@ -568,7 +569,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     else
         n->desc = NULL;
 
-    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+    gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
 
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3576d50..2b14545 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -140,6 +140,13 @@ struct arch_vcpu
          * As soon as an IRQ is EOI'd by the guest and removed from the
          * corresponding LR it is also removed from this list. */
         struct list_head inflight_irqs;
+        /* lr_pending is used to queue IRQs (struct pending_irq) that the
+         * vgic tried to inject in the guest (calling gic_set_guest_irq) but
+         * no LRs were available at the time.
+         * As soon as an LR is freed we remove the first IRQ from this
+         * list and write it to the LR register.
+         * lr_pending is a subset of vgic.inflight_irqs. */
+        struct list_head lr_pending;
         spinlock_t lock;
     } vgic;
 
-- 
1.7.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 Jun 06 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJk-000410-OD; Wed, 06 Jun 2012 11:22:24 +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 1ScEJi-0003zp-HD
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:22 +0000
Received: from [85.158.143.99:9237] by server-1.bemta-4.messagelabs.com id
	0C/69-10042-D6D3FCF4; Wed, 06 Jun 2012 11:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338981738!24014470!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28081 invoked from network); 6 Jun 2012 11:22:21 -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;
	6 Jun 2012 11:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197706843"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-HO;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:08 +0100
Message-ID: <1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
	VCPUs not currently 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

The lr_pending list belongs to the vgic rather than the gic, so move it
there.

gic_set_guest_irq should take into account whether the vcpu is currently
running and if it is not it should add the irq to the right lr_pending
list.

When restoring the gic state we need to go through the lr_pending list
because it is possible that some irqs have been "injected" while the
vcpu wasn't running.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   66 +++++++++++++++++++++++++++++------------
 xen/arch/arm/gic.h           |    2 +-
 xen/arch/arm/vgic.c          |    3 +-
 xen/include/asm-arm/domain.h |    7 ++++
 4 files changed, 56 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index c73f274..2e41d75 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -38,6 +38,7 @@
 #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
                                      + (GIC_HR_OFFSET & 0xfff)))
 static void events_maintenance(struct vcpu *v);
+static void gic_restore_pending_irqs(struct vcpu *v);
 
 /* Global state */
 static struct {
@@ -49,13 +50,6 @@ static struct {
     spinlock_t lock;
     uint64_t event_mask;
     uint64_t lr_mask;
-    /* lr_pending is used to queue IRQs (struct pending_irq) that the
-     * vgic tried to inject in the guest (calling gic_set_guest_irq) but
-     * no LRs were available at the time.
-     * As soon as an LR is freed we remove the first IRQ from this
-     * list and write it to the LR register.
-     * lr_pending is a subset of vgic.inflight_irqs. */
-    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -87,6 +81,8 @@ void gic_restore_state(struct vcpu *v)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     GICH[GICH_HCR] = GICH_HCR_EN;
     isb();
+
+    gic_restore_pending_irqs(v);
 }
 
 static unsigned int gic_irq_startup(struct irq_desc *desc)
@@ -323,7 +319,6 @@ int __init gic_init(void)
 
     gic.lr_mask = 0ULL;
     gic.event_mask = 0ULL;
-    INIT_LIST_HEAD(&gic.lr_pending);
 
     spin_unlock(&gic.lock);
 
@@ -435,17 +430,20 @@ static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
     int i;
     struct pending_irq *iter, *n;
 
-    events_maintenance(current);
+    if ( v->is_running )
+    {
+        events_maintenance(v);
+    }
 
     spin_lock_irq(&gic.lock);
 
-    if ( list_empty(&gic.lr_pending) )
+    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
     {
         i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
         if (i < nr_lrs) {
@@ -457,8 +455,8 @@ void gic_set_guest_irq(unsigned int virtual_irq,
         }
     }
 
-    n = irq_to_pending(current, virtual_irq);
-    list_for_each_entry ( iter, &gic.lr_pending, lr_queue )
+    n = irq_to_pending(v, virtual_irq);
+    list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
     {
         if ( iter->priority > priority )
         {
@@ -466,13 +464,40 @@ void gic_set_guest_irq(unsigned int virtual_irq,
             goto out;
         }
     }
-    list_add_tail(&n->lr_queue, &gic.lr_pending);
+    list_add_tail(&n->lr_queue, &v->arch.vgic.lr_pending);
 
 out:
     spin_unlock_irq(&gic.lock);
     return;
 }
 
+static void gic_restore_pending_irqs(struct vcpu *v)
+{
+    int i;
+    struct pending_irq *p;
+
+    /* check for new pending irqs */
+    if ( list_empty(&v->arch.vgic.lr_pending) )
+        return;
+
+    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
+    {
+        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
+        if ( i < nr_lrs )
+        {
+            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+            list_del_init(&p->lr_queue);
+            set_bit(i, &gic.lr_mask);
+            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
+                set_bit(i, &gic.event_mask);
+        } else
+        {
+            return;
+        }
+    }
+
+}
+
 static void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -582,9 +607,10 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
 {
     int i = 0, virq;
     uint32_t lr;
+    struct vcpu *v = current;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    events_maintenance(current);
+    events_maintenance(v);
 
     while ((i = find_next_bit((const long unsigned int *) &eisr,
                               sizeof(eisr), i)) < sizeof(eisr)) {
@@ -596,8 +622,8 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         GICH[GICH_LR + i] = 0;
         clear_bit(i, &gic.lr_mask);
 
-        if ( !list_empty(&gic.lr_pending) ) {
-            p = list_entry(gic.lr_pending.next, typeof(*p), lr_queue);
+        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);
@@ -608,14 +634,14 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         }
         spin_unlock_irq(&gic.lock);
 
-        spin_lock(&current->arch.vgic.lock);
-        p = irq_to_pending(current, virq);
+        spin_lock(&v->arch.vgic.lock);
+        p = irq_to_pending(v, virq);
         if ( p->desc != NULL ) {
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
         list_del_init(&p->inflight);
-        spin_unlock(&current->arch.vgic.lock);
+        spin_unlock(&v->arch.vgic.lock);
 
         i++;
     }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..a55e146 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -134,7 +134,7 @@ extern void gic_route_irqs(void);
 extern void gic_inject(void);
 
 extern void __cpuinit init_maintenance_interrupt(void);
-extern void gic_set_guest_irq(unsigned int irq,
+extern void gic_set_guest_irq(struct vcpu *v, unsigned int irq,
         unsigned int state, unsigned int priority);
 extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
                                   const char * devname);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 6eb6ec7..5a624bd 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -112,6 +112,7 @@ int vcpu_vgic_init(struct vcpu *v)
             | (1<<(v->vcpu_id+16))
             | (1<<(v->vcpu_id+24));
     INIT_LIST_HEAD(&v->arch.vgic.inflight_irqs);
+    INIT_LIST_HEAD(&v->arch.vgic.lr_pending);
     spin_lock_init(&v->arch.vgic.lock);
 
     return 0;
@@ -568,7 +569,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     else
         n->desc = NULL;
 
-    gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
+    gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
 
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3576d50..2b14545 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -140,6 +140,13 @@ struct arch_vcpu
          * As soon as an IRQ is EOI'd by the guest and removed from the
          * corresponding LR it is also removed from this list. */
         struct list_head inflight_irqs;
+        /* lr_pending is used to queue IRQs (struct pending_irq) that the
+         * vgic tried to inject in the guest (calling gic_set_guest_irq) but
+         * no LRs were available at the time.
+         * As soon as an LR is freed we remove the first IRQ from this
+         * list and write it to the LR register.
+         * lr_pending is a subset of vgic.inflight_irqs. */
+        struct list_head lr_pending;
         spinlock_t lock;
     } vgic;
 
-- 
1.7.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 Jun 06 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJj-00040F-Fl; Wed, 06 Jun 2012 11:22:23 +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 1ScEJh-0003zY-BP
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:21 +0000
Received: from [85.158.139.83:24251] by server-4.bemta-5.messagelabs.com id
	B3/5D-05858-C6D3FCF4; Wed, 06 Jun 2012 11:22:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338981738!28284220!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1867 invoked from network); 6 Jun 2012 11:22:19 -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;
	6 Jun 2012 11:22:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="27031843"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-Fx;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:06 +0100
Message-ID: <1338981730-14816-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.1206051814030.6030@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/5] arm/vtimer: do not let the guest interact
	with the physical 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

The guest can read the physical counter but it shouldn't be able to
cause interrupts of the physical timer to go to the hypervisor.
Trap physical timer reads/writes in vtimer.c instead.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/time.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 1587fa2..d5b71d7 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -160,8 +160,8 @@ void __cpuinit init_timer_interrupt(void)
     WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
     WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
 #if USE_HYP_TIMER
-    /* Let the VMs read the physical counter and timer so they can tell time */
-    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+    /* Do not the VMs program the physical timer, only read the physical counter */
+    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
 #else
     /* Cannot let VMs access physical counter if we are using it */
     WRITE_CP32(0, CNTHCTL);
-- 
1.7.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 Jun 06 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJj-00040F-Fl; Wed, 06 Jun 2012 11:22:23 +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 1ScEJh-0003zY-BP
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:21 +0000
Received: from [85.158.139.83:24251] by server-4.bemta-5.messagelabs.com id
	B3/5D-05858-C6D3FCF4; Wed, 06 Jun 2012 11:22:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338981738!28284220!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1867 invoked from network); 6 Jun 2012 11:22:19 -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;
	6 Jun 2012 11:22:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="27031843"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-Fx;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:06 +0100
Message-ID: <1338981730-14816-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.1206051814030.6030@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/5] arm/vtimer: do not let the guest interact
	with the physical 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

The guest can read the physical counter but it shouldn't be able to
cause interrupts of the physical timer to go to the hypervisor.
Trap physical timer reads/writes in vtimer.c instead.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/time.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 1587fa2..d5b71d7 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -160,8 +160,8 @@ void __cpuinit init_timer_interrupt(void)
     WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
     WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
 #if USE_HYP_TIMER
-    /* Let the VMs read the physical counter and timer so they can tell time */
-    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
+    /* Do not the VMs program the physical timer, only read the physical counter */
+    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
 #else
     /* Cannot let VMs access physical counter if we are using it */
     WRITE_CP32(0, CNTHCTL);
-- 
1.7.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 Jun 06 11:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJk-00040o-Ca; Wed, 06 Jun 2012 11:22:24 +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 1ScEJi-0003zm-7U
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:22 +0000
Received: from [85.158.139.83:24337] by server-3.bemta-5.messagelabs.com id
	C8/36-17554-D6D3FCF4; Wed, 06 Jun 2012 11:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338981738!28284220!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1926 invoked from network); 6 Jun 2012 11:22:20 -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;
	6 Jun 2012 11:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="27031844"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-JL;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:09 +0100
Message-ID: <1338981730-14816-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen/vgic: vgic: support irq enable/disable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 vgic_vcpu_inject_irq is called (for example by a device emulator like
vtimer.c) but the corresponding irq is not enabled in the virtual gicd
just queue it in the inflight_irqs list.

When the irq is enabled make sure to call gic_set_guest_irq.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vgic.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 5a624bd..4cdfec5 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -343,6 +343,22 @@ read_as_zero:
     return 1;
 }
 
+static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
+{
+    struct pending_irq *p;
+    unsigned int irq;
+    int i = 0;
+
+    while ( (i = find_next_bit((const long unsigned int *) &r,
+                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
+        irq = i + (32 * n);
+        p = irq_to_pending(v, irq);
+        if ( !list_empty(&p->inflight) )
+            gic_set_guest_irq(v, irq, GICH_LR_PENDING, p->priority);
+        i++;
+    }
+}
+
 static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
@@ -351,6 +367,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
+    uint32_t tr;
 
     switch ( gicd_reg )
     {
@@ -378,8 +395,10 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
         rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
+        tr = rank->ienable;
         rank->ienable |= *r;
         vgic_unlock_rank(v, rank);
+        vgic_enable_irqs(v, (*r) & (~tr), gicd_reg - GICD_ISENABLER);
         return 1;
 
     case GICD_ICENABLER ... GICD_ICENABLERN:
@@ -569,7 +588,9 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     else
         n->desc = NULL;
 
-    gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
+    /* the irq is enabled */
+    if ( rank->ienable & (1 << (irq % 32)) )
+        gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
 
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
-- 
1.7.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 Jun 06 11:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJk-00040o-Ca; Wed, 06 Jun 2012 11:22:24 +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 1ScEJi-0003zm-7U
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:22 +0000
Received: from [85.158.139.83:24337] by server-3.bemta-5.messagelabs.com id
	C8/36-17554-D6D3FCF4; Wed, 06 Jun 2012 11:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338981738!28284220!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1926 invoked from network); 6 Jun 2012 11:22:20 -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;
	6 Jun 2012 11:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="27031844"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-JL;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:09 +0100
Message-ID: <1338981730-14816-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen/vgic: vgic: support irq enable/disable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 vgic_vcpu_inject_irq is called (for example by a device emulator like
vtimer.c) but the corresponding irq is not enabled in the virtual gicd
just queue it in the inflight_irqs list.

When the irq is enabled make sure to call gic_set_guest_irq.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vgic.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 5a624bd..4cdfec5 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -343,6 +343,22 @@ read_as_zero:
     return 1;
 }
 
+static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
+{
+    struct pending_irq *p;
+    unsigned int irq;
+    int i = 0;
+
+    while ( (i = find_next_bit((const long unsigned int *) &r,
+                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
+        irq = i + (32 * n);
+        p = irq_to_pending(v, irq);
+        if ( !list_empty(&p->inflight) )
+            gic_set_guest_irq(v, irq, GICH_LR_PENDING, p->priority);
+        i++;
+    }
+}
+
 static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
@@ -351,6 +367,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
+    uint32_t tr;
 
     switch ( gicd_reg )
     {
@@ -378,8 +395,10 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
         rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
+        tr = rank->ienable;
         rank->ienable |= *r;
         vgic_unlock_rank(v, rank);
+        vgic_enable_irqs(v, (*r) & (~tr), gicd_reg - GICD_ISENABLER);
         return 1;
 
     case GICD_ICENABLER ... GICD_ICENABLERN:
@@ -569,7 +588,9 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     else
         n->desc = NULL;
 
-    gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
+    /* the irq is enabled */
+    if ( rank->ienable & (1 << (irq % 32)) )
+        gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
 
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
-- 
1.7.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 Jun 06 11:22:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJj-00040Q-RW; Wed, 06 Jun 2012 11:22: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 1ScEJh-0003zX-Ht
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:21 +0000
Received: from [85.158.143.99:47995] by server-2.bemta-4.messagelabs.com id
	A9/DD-17938-D6D3FCF4; Wed, 06 Jun 2012 11:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338981738!24014470!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27951 invoked from network); 6 Jun 2012 11:22:20 -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;
	6 Jun 2012 11:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197706842"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-LC;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:10 +0100
Message-ID: <1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/5] xen/vgic: initialize pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Properly initialize all the pending_irqs.lr_queue like we do for
inflight.
Check whether we already have the irq in lr_queue before adding it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c  |    6 ++++++
 xen/arch/arm/vgic.c |    6 ++++++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2e41d75..998033a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
     }
 
     n = irq_to_pending(v, virtual_irq);
+    if ( !list_empty(&n->lr_queue) )
+    {
+        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
+                virtual_irq);
+        goto out;
+    }
     list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
     {
         if ( iter->priority > priority )
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 4cdfec5..653e8e5 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.pending_irqs =
         xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
     for (i=0; i<d->arch.vgic.nr_lines; i++)
+    {
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
+    }
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
     return 0;
@@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
     for (i = 0; i < 32; i++)
+    {
         INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
+    }
     printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
            &v->arch.vgic.pending_irqs[0],
            v->arch.vgic.pending_irqs[0].desc);
-- 
1.7.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 Jun 06 11:22:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:22:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEJj-00040Q-RW; Wed, 06 Jun 2012 11:22: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 1ScEJh-0003zX-Ht
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:22:21 +0000
Received: from [85.158.143.99:47995] by server-2.bemta-4.messagelabs.com id
	A9/DD-17938-D6D3FCF4; Wed, 06 Jun 2012 11:22:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1338981738!24014470!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27951 invoked from network); 6 Jun 2012 11:22:20 -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;
	6 Jun 2012 11:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330923600"; d="scan'208";a="197706842"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 07:22:18 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 07:22:17 -0400
Received: from [10.80.238.169] (helo=kaball.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1ScEJY-00052C-LC;
	Wed, 06 Jun 2012 12:22:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 6 Jun 2012 12:22:10 +0100
Message-ID: <1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/5] xen/vgic: initialize pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Properly initialize all the pending_irqs.lr_queue like we do for
inflight.
Check whether we already have the irq in lr_queue before adding it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c  |    6 ++++++
 xen/arch/arm/vgic.c |    6 ++++++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2e41d75..998033a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
     }
 
     n = irq_to_pending(v, virtual_irq);
+    if ( !list_empty(&n->lr_queue) )
+    {
+        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
+                virtual_irq);
+        goto out;
+    }
     list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
     {
         if ( iter->priority > priority )
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 4cdfec5..653e8e5 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.pending_irqs =
         xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
     for (i=0; i<d->arch.vgic.nr_lines; i++)
+    {
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
+        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
+    }
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
     return 0;
@@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
     for (i = 0; i < 32; i++)
+    {
         INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
+    }
     printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
            &v->arch.vgic.pending_irqs[0],
            v->arch.vgic.pending_irqs[0].desc);
-- 
1.7.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 Jun 06 11:22:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScEJe-0003zH-M7; Wed, 06 Jun 2012 11:22:18 +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 1ScEJd-0003z9-Bk
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:22:17 +0000
Received: from [193.109.254.147:15607] by server-11.bemta-14.messagelabs.com
	id 9E/2E-02727-86D3FCF4; Wed, 06 Jun 2012 11:22:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338981732!6223342!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9575 invoked from network); 6 Jun 2012 11:22:12 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:22:12 -0000
Received: by eaak12 with SMTP id k12so2041821eaa.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 04:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zSI9yiRqxR47ebHZMxgl27M5KFX44IzLZrWyGQ21RKs=;
	b=dq7VYoN0qwmoEYRmeRsOvjxX4/Qjxt4ZMYwT8mWBGBzS8zEaZs7+7Nx1DOZAMFcIXS
	9mOLs6gXYJCa4ZcqHrtY/B/Ch+WnKVNcqFJS/PkzqRecmvTGaevdSRzsfEjJnr46kV2C
	3S226K5KgU2qCaSudB/k/RbgZ8OTA5WHYNuY4HLflAPiW/JbPM1c0/cHv+zKvNdl+/Ho
	VRjAWYN6BCmaptG23wH7u8Xtj5nAF6qcZmfiTKUe6yeHNWB7mQktw0HIf30qm/ev/uLe
	ahf6Jp8Sw/8GrPr5pcRFvEWayMh1kSMiql46Kh02Y+sv2IHwSZIdoIP/2J+u7wrIifBC
	Hc1w==
Received: by 10.14.40.20 with SMTP id e20mr10023240eeb.119.1338981731779;
	Wed, 06 Jun 2012 04:22:11 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-18-132.range81-152.btcentralplus.com.
	[81.152.18.132])
	by mx.google.com with ESMTPS id e45sm5292314eeb.6.2012.06.06.04.22.10
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 04:22:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 06 Jun 2012 12:22:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CBF4FBEF.3558E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] fix page_list_splice()
Thread-Index: Ac1D1ps6EQDQiLdZnk62SHbOoYA17A==
In-Reply-To: <4FCF3E5002000078000886D7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jisoo Yang <jisooy@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 10:26, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.06.12 at 11:02, Keir Fraser <keir@xen.org> wrote:
>> On 06/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Other than in __list_splice(), the first element's prev pointer doesn't
>>> need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
>>> the assignment (to formally match __list_splice()), simply assert that
>>> this assignment is really unnecessary.
>>> 
>>> Reported-by: Jisoo Yang <jisooy@gmail.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> 
>>> --- a/xen/include/xen/mm.h
>>> +++ b/xen/include/xen/mm.h
>>> @@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
>>>      last = list->tail;
>>>      at = head->next;
>>>  
>>> -    first->list.prev = page_to_pdx(head->next);
>>> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
>> 
>> ASSERT(first->list.prev == PAGE_LIST_NULL); ?
>> 
>> It seems odd to have one assumption encoded as an ASSERTion, and one as a
>> code comment... A second assertion makes the assumption explicit, and
>> run-time checked in debug builds.
> 
> But the __list_splice() equivalent assignment would be
> 
>     first->list.prev = at->list.prev;
> 
> which is why I chose the assert expression that way, yet made
> the comment clarify what the actual state is. If the comment
> just repeated what the ASSERT() already says, I'd rather drop
> the comment altogether.

I mean to replace the comment with a second assertion, not to replace the
assertion your patch already adds. Does that make sense?

 -- 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 Jun 06 11:22:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScEJe-0003zH-M7; Wed, 06 Jun 2012 11:22:18 +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 1ScEJd-0003z9-Bk
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:22:17 +0000
Received: from [193.109.254.147:15607] by server-11.bemta-14.messagelabs.com
	id 9E/2E-02727-86D3FCF4; Wed, 06 Jun 2012 11:22:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1338981732!6223342!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9575 invoked from network); 6 Jun 2012 11:22:12 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:22:12 -0000
Received: by eaak12 with SMTP id k12so2041821eaa.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 04:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=zSI9yiRqxR47ebHZMxgl27M5KFX44IzLZrWyGQ21RKs=;
	b=dq7VYoN0qwmoEYRmeRsOvjxX4/Qjxt4ZMYwT8mWBGBzS8zEaZs7+7Nx1DOZAMFcIXS
	9mOLs6gXYJCa4ZcqHrtY/B/Ch+WnKVNcqFJS/PkzqRecmvTGaevdSRzsfEjJnr46kV2C
	3S226K5KgU2qCaSudB/k/RbgZ8OTA5WHYNuY4HLflAPiW/JbPM1c0/cHv+zKvNdl+/Ho
	VRjAWYN6BCmaptG23wH7u8Xtj5nAF6qcZmfiTKUe6yeHNWB7mQktw0HIf30qm/ev/uLe
	ahf6Jp8Sw/8GrPr5pcRFvEWayMh1kSMiql46Kh02Y+sv2IHwSZIdoIP/2J+u7wrIifBC
	Hc1w==
Received: by 10.14.40.20 with SMTP id e20mr10023240eeb.119.1338981731779;
	Wed, 06 Jun 2012 04:22:11 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-18-132.range81-152.btcentralplus.com.
	[81.152.18.132])
	by mx.google.com with ESMTPS id e45sm5292314eeb.6.2012.06.06.04.22.10
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 04:22:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 06 Jun 2012 12:22:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CBF4FBEF.3558E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] fix page_list_splice()
Thread-Index: Ac1D1ps6EQDQiLdZnk62SHbOoYA17A==
In-Reply-To: <4FCF3E5002000078000886D7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jisoo Yang <jisooy@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 10:26, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.06.12 at 11:02, Keir Fraser <keir@xen.org> wrote:
>> On 06/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Other than in __list_splice(), the first element's prev pointer doesn't
>>> need adjustment here - it already is PAGE_LIST_NULL. Rather than fixing
>>> the assignment (to formally match __list_splice()), simply assert that
>>> this assignment is really unnecessary.
>>> 
>>> Reported-by: Jisoo Yang <jisooy@gmail.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> 
>>> --- a/xen/include/xen/mm.h
>>> +++ b/xen/include/xen/mm.h
>>> @@ -270,7 +270,8 @@ page_list_splice(struct page_list_head *
>>>      last = list->tail;
>>>      at = head->next;
>>>  
>>> -    first->list.prev = page_to_pdx(head->next);
>>> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
>> 
>> ASSERT(first->list.prev == PAGE_LIST_NULL); ?
>> 
>> It seems odd to have one assumption encoded as an ASSERTion, and one as a
>> code comment... A second assertion makes the assumption explicit, and
>> run-time checked in debug builds.
> 
> But the __list_splice() equivalent assignment would be
> 
>     first->list.prev = at->list.prev;
> 
> which is why I chose the assert expression that way, yet made
> the comment clarify what the actual state is. If the comment
> just repeated what the ASSERT() already says, I'd rather drop
> the comment altogether.

I mean to replace the comment with a second assertion, not to replace the
assertion your patch already adds. Does that make sense?

 -- 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 Jun 06 11:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScEhq-00057Y-12; Wed, 06 Jun 2012 11:47: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 1ScEho-00057T-3b
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:47:16 +0000
Received: from [85.158.139.83:24893] by server-2.bemta-5.messagelabs.com id
	74/75-20827-3434FCF4; Wed, 06 Jun 2012 11:47:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338983233!32152560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16342 invoked from network); 6 Jun 2012 11:47:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:47:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12857243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:47:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	12:47:12 +0100
Message-ID: <1338983231.32319.65.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 6 Jun 2012 12:47:11 +0100
In-Reply-To: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
>  # Complex libxl types
>  #
> +
> +libxl_vga_interface_info = Struct("vga_interface_info", [
> +    ("type",    libxl_vga_interface_type),
> +    ])

Unfortunately "type" is a reserved word in ocaml (and possibly other
languages, which causes the bindings to fail to build:
        make[4]: Entering directory `/local/scratch/ianc/devel/committer.git/tools/ocaml/libs/xl'
         MLDEP    
        File "xenlight.ml", line 116, characters 2-6:
        Error: Syntax error
         MLI      xenlight.cmi
        File "xenlight.mli", line 116, characters 2-6:
        Error: Syntax error: 'end' expected
        File "xenlight.mli", line 113, characters 28-31:
        Error: This 'sig' might be unmatched

Ideally we'd make the bindings generator do appropriate substitutions on
keywords but the usual workaround is to s/type/kind for the field name.

BTW, I wasn't going to bounce the patch over this but could 
LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
the type? I'm not sure why we don't do the same for
LIBXL_TIMER_MODE_DEFAULT already.

Ian.


> +
>  libxl_vnc_info = Struct("vnc_info", [
>      ("enable",        libxl_defbool),
>      # "address:port" that should be listened on
> @@ -281,7 +291,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("nested_hvm",       libxl_defbool),
>                                         ("incr_generationid",libxl_defbool),
>                                         ("nographic",        libxl_defbool),
> -                                       ("stdvga",           libxl_defbool),
> +                                       ("vga",
> libxl_vga_interface_info),
>                                         ("vnc",              libxl_vnc_info),
>                                         # keyboard layout, default is
> en-us keyboard
>                                         ("keymap",           string),
> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
> @@ -1256,7 +1256,10 @@ skip_vfb:
>  #undef parse_extra_args
> 
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +            if (l)
> +                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
> +
>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
>          xlu_cfg_replace_string (config, "vnclisten",
>                                  &b_info->u.hvm.vnc.listen, 0);
> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/xl_sxp.c	Tue Jun 05 17:39:37 2012 +0800
> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
>          printf("\t\t\t(no_incr_generationid %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
> -        printf("\t\t\t(stdvga %s)\n",
> -               libxl_defbool_to_string(b_info->u.hvm.stdvga));
> +        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type ==
> +                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
> +                                      "True" : "False");
>          printf("\t\t\t(vnc %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
>          printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> 
> 



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScEhq-00057Y-12; Wed, 06 Jun 2012 11:47: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 1ScEho-00057T-3b
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 11:47:16 +0000
Received: from [85.158.139.83:24893] by server-2.bemta-5.messagelabs.com id
	74/75-20827-3434FCF4; Wed, 06 Jun 2012 11:47:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338983233!32152560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16342 invoked from network); 6 Jun 2012 11:47:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:47:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12857243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:47:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	12:47:12 +0100
Message-ID: <1338983231.32319.65.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 6 Jun 2012 12:47:11 +0100
In-Reply-To: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
>  # Complex libxl types
>  #
> +
> +libxl_vga_interface_info = Struct("vga_interface_info", [
> +    ("type",    libxl_vga_interface_type),
> +    ])

Unfortunately "type" is a reserved word in ocaml (and possibly other
languages, which causes the bindings to fail to build:
        make[4]: Entering directory `/local/scratch/ianc/devel/committer.git/tools/ocaml/libs/xl'
         MLDEP    
        File "xenlight.ml", line 116, characters 2-6:
        Error: Syntax error
         MLI      xenlight.cmi
        File "xenlight.mli", line 116, characters 2-6:
        Error: Syntax error: 'end' expected
        File "xenlight.mli", line 113, characters 28-31:
        Error: This 'sig' might be unmatched

Ideally we'd make the bindings generator do appropriate substitutions on
keywords but the usual workaround is to s/type/kind for the field name.

BTW, I wasn't going to bounce the patch over this but could 
LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
the type? I'm not sure why we don't do the same for
LIBXL_TIMER_MODE_DEFAULT already.

Ian.


> +
>  libxl_vnc_info = Struct("vnc_info", [
>      ("enable",        libxl_defbool),
>      # "address:port" that should be listened on
> @@ -281,7 +291,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("nested_hvm",       libxl_defbool),
>                                         ("incr_generationid",libxl_defbool),
>                                         ("nographic",        libxl_defbool),
> -                                       ("stdvga",           libxl_defbool),
> +                                       ("vga",
> libxl_vga_interface_info),
>                                         ("vnc",              libxl_vnc_info),
>                                         # keyboard layout, default is
> en-us keyboard
>                                         ("keymap",           string),
> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
> @@ -1256,7 +1256,10 @@ skip_vfb:
>  #undef parse_extra_args
> 
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +            if (l)
> +                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
> +
>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
>          xlu_cfg_replace_string (config, "vnclisten",
>                                  &b_info->u.hvm.vnc.listen, 0);
> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/xl_sxp.c	Tue Jun 05 17:39:37 2012 +0800
> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
>          printf("\t\t\t(no_incr_generationid %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
> -        printf("\t\t\t(stdvga %s)\n",
> -               libxl_defbool_to_string(b_info->u.hvm.stdvga));
> +        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type ==
> +                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
> +                                      "True" : "False");
>          printf("\t\t\t(vnc %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
>          printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> 
> 



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:47:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:47: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 1ScEi0-00058G-DM; Wed, 06 Jun 2012 11:47: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 1ScEhy-00057y-PW
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:47:27 +0000
Received: from [85.158.143.35:35405] by server-3.bemta-4.messagelabs.com id
	6C/A3-29237-E434FCF4; Wed, 06 Jun 2012 11:47:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338983245!13178534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4409 invoked from network); 6 Jun 2012 11:47:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:47:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12857253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:47:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	12:47:22 +0100
Message-ID: <1338983241.32319.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bamvor Jian Zhang <bjzhang@suse.com>
Date: Wed, 6 Jun 2012 12:47:21 +0100
In-Reply-To: <2586692a6d74bc11475a.1338966596@linux-bjrd>
References: <2586692a6d74bc11475a.1338966596@linux-bjrd>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v4] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 08:09 +0100, Bamvor Jian Zhang wrote:
> This api retrieve domain console from xenstore. With this new api, it is easy
> to implement "virsh console" command in libvirt libxl driver.
> 
> Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>

Applied, thanks.

I trimmed a bunch of trailing whitespace, please watch out next time.

> Changes since v3:
>  * leave variable uninitialised at the top of the function in order to avoid
>     hiding the useful compiler warnings.
>  * using libxl__strdup instead of strdup in libxl_console_get_tty. benefit from
>    the error handling behavior.
>    libxl__strdup(0, tty) should be replaced by libxl__strdup(NOGC, tty) after
>    Ian Jackson commit his patch: "Do not pass NULL as gc_opt; introduce NOGC."

I introduced a "#define NOGC NULL" in an earlier patch so we don't miss
converting any new instances to the proper scheme when Ian J's patch
goes in. I did s/0/NOGC on this patch as I applied it. Hope that's ok.

> 
> diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/libxl.c	Wed Jun 06 14:35:01 2012 +0800
> @@ -1217,7 +1217,8 @@ out:
>      return rc;
>  }
>  
> -int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
> +int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
> +                       libxl_console_type type)
>  {
>      GC_INIT(ctx);
>      char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
> @@ -1243,34 +1244,116 @@ out:
>      return ERROR_FAIL;
>  }
>  
> -int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
> +int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> +                          libxl_console_type type, char **path)
> +{
> +    GC_INIT(ctx);
> +    char *dom_path;
> +    char *tty_path;
> +    char *tty;
> +    int rc;
> +
> +    dom_path = libxl__xs_get_dompath(gc, domid);
> +    if (!dom_path) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    switch (type) {
> +    case LIBXL_CONSOLE_TYPE_SERIAL:
> +        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
> +        break;
> +    case LIBXL_CONSOLE_TYPE_PV:
> +        if (cons_num == 0)
> +            tty_path = GCSPRINTF("%s/console/tty", dom_path);
> +        else
> +            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
> +                                cons_num);
> +        break;
> +    default:
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +
> +    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
> +    if (!tty) {
> +       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
> +       rc = ERROR_FAIL;
> +       goto out;
> +    }
> +
> +    *path = libxl__strdup(0, tty);
> +    rc = 0;
> +out:
> +    GC_FREE;
> +    return rc;
> +}
> +
> +static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
> +                                       uint32_t *domid, int *cons_num, 
> +                                       libxl_console_type *type)
>  {
>      GC_INIT(ctx);
>      uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
>      int rc;
> -    if (stubdomid)
> -        rc = libxl_console_exec(ctx, stubdomid,
> -                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
> -    else {
> +
> +    if (stubdomid) {
> +        *domid = stubdomid;
> +        *cons_num = STUBDOM_CONSOLE_SERIAL;
> +        *type = LIBXL_CONSOLE_TYPE_PV;
> +    } else {
>          switch (libxl__domain_type(gc, domid_vm)) {
>          case LIBXL_DOMAIN_TYPE_HVM:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_SERIAL;
>              break;
>          case LIBXL_DOMAIN_TYPE_PV:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_PV;
>              break;
>          case -1:
> -            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
> -            rc = ERROR_FAIL;
> +            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
> +            rc = ERROR_INVAL;
> +            goto out;
>              break;
>          default:
>              abort();
>          }
>      }
> +    
> +    rc = 0;
> +out:
>      GC_FREE;
>      return rc;
>  }
>  
> +int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
> +{
> +    uint32_t domid;
> +    int cons_num;
> +    libxl_console_type type;
> +    int rc;
> +
> +    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
> +    if ( rc ) return rc;
> +    return libxl_console_exec(ctx, domid, cons_num, type);
> +}
> +
> +int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
> +                                  char **path)
> +{
> +    uint32_t domid;
> +    int cons_num;
> +    libxl_console_type type;
> +    int rc;
> +
> +    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
> +    if ( rc ) return rc;
> +    return libxl_console_get_tty(ctx, domid, cons_num, type, path);
> +}
> +
>  int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>  {
>      GC_INIT(ctx);
> diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/libxl.h	Wed Jun 06 14:35:01 2012 +0800
> @@ -570,6 +570,18 @@ int libxl_console_exec(libxl_ctx *ctx, u
>   * guests using pygrub. */
>  int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
>  
> +/* libxl_console_get_tty retrieves the specified domain's console tty path
> + * and stores it in path. Caller is responsible for freeing the memory.
> + */
> +int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> +                          libxl_console_type type, char **path);
> +
> +/* libxl_primary_console_get_tty retrieves the specified domain's primary 
> + * console tty path and stores it in path. Caller is responsible for freeing
> + * the memory.
> + */
> +int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path);
> +
>  /* May be called with info_r == NULL to check for domain's existance */
>  int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
>                        uint32_t domid);



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:47:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:47: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 1ScEi0-00058G-DM; Wed, 06 Jun 2012 11:47: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 1ScEhy-00057y-PW
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:47:27 +0000
Received: from [85.158.143.35:35405] by server-3.bemta-4.messagelabs.com id
	6C/A3-29237-E434FCF4; Wed, 06 Jun 2012 11:47:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1338983245!13178534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4409 invoked from network); 6 Jun 2012 11:47:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:47:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12857253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:47:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	12:47:22 +0100
Message-ID: <1338983241.32319.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bamvor Jian Zhang <bjzhang@suse.com>
Date: Wed, 6 Jun 2012 12:47:21 +0100
In-Reply-To: <2586692a6d74bc11475a.1338966596@linux-bjrd>
References: <2586692a6d74bc11475a.1338966596@linux-bjrd>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] [v4] libxl: Add API to retrieve domain
	console tty
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 08:09 +0100, Bamvor Jian Zhang wrote:
> This api retrieve domain console from xenstore. With this new api, it is easy
> to implement "virsh console" command in libvirt libxl driver.
> 
> Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>

Applied, thanks.

I trimmed a bunch of trailing whitespace, please watch out next time.

> Changes since v3:
>  * leave variable uninitialised at the top of the function in order to avoid
>     hiding the useful compiler warnings.
>  * using libxl__strdup instead of strdup in libxl_console_get_tty. benefit from
>    the error handling behavior.
>    libxl__strdup(0, tty) should be replaced by libxl__strdup(NOGC, tty) after
>    Ian Jackson commit his patch: "Do not pass NULL as gc_opt; introduce NOGC."

I introduced a "#define NOGC NULL" in an earlier patch so we don't miss
converting any new instances to the proper scheme when Ian J's patch
goes in. I did s/0/NOGC on this patch as I applied it. Hope that's ok.

> 
> diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/libxl.c	Wed Jun 06 14:35:01 2012 +0800
> @@ -1217,7 +1217,8 @@ out:
>      return rc;
>  }
>  
> -int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type)
> +int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
> +                       libxl_console_type type)
>  {
>      GC_INIT(ctx);
>      char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
> @@ -1243,34 +1244,116 @@ out:
>      return ERROR_FAIL;
>  }
>  
> -int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
> +int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> +                          libxl_console_type type, char **path)
> +{
> +    GC_INIT(ctx);
> +    char *dom_path;
> +    char *tty_path;
> +    char *tty;
> +    int rc;
> +
> +    dom_path = libxl__xs_get_dompath(gc, domid);
> +    if (!dom_path) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    switch (type) {
> +    case LIBXL_CONSOLE_TYPE_SERIAL:
> +        tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
> +        break;
> +    case LIBXL_CONSOLE_TYPE_PV:
> +        if (cons_num == 0)
> +            tty_path = GCSPRINTF("%s/console/tty", dom_path);
> +        else
> +            tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path, 
> +                                cons_num);
> +        break;
> +    default:
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +
> +    tty = libxl__xs_read(gc, XBT_NULL, tty_path);
> +    if (!tty) {
> +       LOGE(ERROR,"unable to read console tty path `%s'",tty_path);
> +       rc = ERROR_FAIL;
> +       goto out;
> +    }
> +
> +    *path = libxl__strdup(0, tty);
> +    rc = 0;
> +out:
> +    GC_FREE;
> +    return rc;
> +}
> +
> +static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm, 
> +                                       uint32_t *domid, int *cons_num, 
> +                                       libxl_console_type *type)
>  {
>      GC_INIT(ctx);
>      uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
>      int rc;
> -    if (stubdomid)
> -        rc = libxl_console_exec(ctx, stubdomid,
> -                                STUBDOM_CONSOLE_SERIAL, LIBXL_CONSOLE_TYPE_PV);
> -    else {
> +
> +    if (stubdomid) {
> +        *domid = stubdomid;
> +        *cons_num = STUBDOM_CONSOLE_SERIAL;
> +        *type = LIBXL_CONSOLE_TYPE_PV;
> +    } else {
>          switch (libxl__domain_type(gc, domid_vm)) {
>          case LIBXL_DOMAIN_TYPE_HVM:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_SERIAL);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_SERIAL;
>              break;
>          case LIBXL_DOMAIN_TYPE_PV:
> -            rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
> +            *domid = domid_vm;
> +            *cons_num = 0;
> +            *type = LIBXL_CONSOLE_TYPE_PV;
>              break;
>          case -1:
> -            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
> -            rc = ERROR_FAIL;
> +            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
> +            rc = ERROR_INVAL;
> +            goto out;
>              break;
>          default:
>              abort();
>          }
>      }
> +    
> +    rc = 0;
> +out:
>      GC_FREE;
>      return rc;
>  }
>  
> +int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm)
> +{
> +    uint32_t domid;
> +    int cons_num;
> +    libxl_console_type type;
> +    int rc;
> +
> +    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
> +    if ( rc ) return rc;
> +    return libxl_console_exec(ctx, domid, cons_num, type);
> +}
> +
> +int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
> +                                  char **path)
> +{
> +    uint32_t domid;
> +    int cons_num;
> +    libxl_console_type type;
> +    int rc;
> +
> +    rc = libxl__primary_console_find(ctx, domid_vm, &domid, &cons_num, &type);
> +    if ( rc ) return rc;
> +    return libxl_console_get_tty(ctx, domid, cons_num, type, path);
> +}
> +
>  int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
>  {
>      GC_INIT(ctx);
> diff -r 6bea63e6c780 -r 2586692a6d74 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Sat Jun 02 08:39:45 2012 +0100
> +++ b/tools/libxl/libxl.h	Wed Jun 06 14:35:01 2012 +0800
> @@ -570,6 +570,18 @@ int libxl_console_exec(libxl_ctx *ctx, u
>   * guests using pygrub. */
>  int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
>  
> +/* libxl_console_get_tty retrieves the specified domain's console tty path
> + * and stores it in path. Caller is responsible for freeing the memory.
> + */
> +int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> +                          libxl_console_type type, char **path);
> +
> +/* libxl_primary_console_get_tty retrieves the specified domain's primary 
> + * console tty path and stores it in path. Caller is responsible for freeing
> + * the memory.
> + */
> +int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path);
> +
>  /* May be called with info_r == NULL to check for domain's existance */
>  int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
>                        uint32_t domid);



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:48:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEiQ-0005CC-25; Wed, 06 Jun 2012 11:47: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 1ScEiO-0005Bs-St
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:47:53 +0000
Received: from [85.158.143.99:39551] by server-2.bemta-4.messagelabs.com id
	73/67-17938-8634FCF4; Wed, 06 Jun 2012 11:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338983271!31542329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22908 invoked from network); 6 Jun 2012 11:47:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:47:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12857265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:47:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	12:47:50 +0100
Message-ID: <1338983269.32319.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 12:47:49 +0100
In-Reply-To: <f893681e07ae2bb0e52e.1338974521@Solace>
References: <f893681e07ae2bb0e52e.1338974521@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: convert malloc() to
	libxl__zalloc(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 Wed, 2012-06-06 at 10:22 +0100, Dario Faggioli wrote:
> And ditch the error handling in libxl_get_cpu_topology()
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Could have used libxl__calloc but I've applied this version.

I added "#define NOGC NULL" and used it instead of NULL, this will mean
that when we come to apply
<20424.60793.374823.597252@mariner.uk.xensource.com> we stand less
chance of missing an existing NULL introduced in the interim. Hope
that's ok.

Ian.
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3116,12 +3116,7 @@ libxl_cputopology *libxl_get_cpu_topolog
>      if (tinfo.max_cpu_index < max_cpus - 1)
>          max_cpus = tinfo.max_cpu_index + 1;
>  
> -    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
> -    if (ret == NULL) {
> -        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
> -                            "Unable to allocate return value");
> -        goto fail;
> -    }
> +    ret = libxl__zalloc(NULL, sizeof(libxl_cputopology) * max_cpus);
>  
>      for (i = 0; i < max_cpus; i++) {
>  #define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 11:48:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 11:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScEiQ-0005CC-25; Wed, 06 Jun 2012 11:47: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 1ScEiO-0005Bs-St
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 11:47:53 +0000
Received: from [85.158.143.99:39551] by server-2.bemta-4.messagelabs.com id
	73/67-17938-8634FCF4; Wed, 06 Jun 2012 11:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1338983271!31542329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22908 invoked from network); 6 Jun 2012 11:47:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 11:47:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="12857265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 11:47:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	12:47:50 +0100
Message-ID: <1338983269.32319.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 12:47:49 +0100
In-Reply-To: <f893681e07ae2bb0e52e.1338974521@Solace>
References: <f893681e07ae2bb0e52e.1338974521@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: convert malloc() to
	libxl__zalloc(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 Wed, 2012-06-06 at 10:22 +0100, Dario Faggioli wrote:
> And ditch the error handling in libxl_get_cpu_topology()
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Could have used libxl__calloc but I've applied this version.

I added "#define NOGC NULL" and used it instead of NULL, this will mean
that when we come to apply
<20424.60793.374823.597252@mariner.uk.xensource.com> we stand less
chance of missing an existing NULL introduced in the interim. Hope
that's ok.

Ian.
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3116,12 +3116,7 @@ libxl_cputopology *libxl_get_cpu_topolog
>      if (tinfo.max_cpu_index < max_cpus - 1)
>          max_cpus = tinfo.max_cpu_index + 1;
>  
> -    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
> -    if (ret == NULL) {
> -        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
> -                            "Unable to allocate return value");
> -        goto fail;
> -    }
> +    ret = libxl__zalloc(NULL, sizeof(libxl_cputopology) * max_cpus);
>  
>      for (i = 0; i < max_cpus; i++) {
>  #define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 12:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12: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 1ScFTS-0006AX-Qz; Wed, 06 Jun 2012 12:36:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1ScFTR-0006AS-Us
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:36:30 +0000
Received: from [85.158.143.99:59656] by server-2.bemta-4.messagelabs.com id
	8A/4B-17938-DCE4FCF4; Wed, 06 Jun 2012 12:36:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338986188!31007061!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDkxMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDkxMjY=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7174 invoked from network); 6 Jun 2012 12:36:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 12:36:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69j6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-10.vodafone-net.de [80.226.24.10])
	by smtp.strato.de (jorabe mo23) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I07a1eo56BgNZX ;
	Wed, 6 Jun 2012 14:36:27 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 889CC18638; Wed,  6 Jun 2012 14:36:25 +0200 (CEST)
Date: Wed, 6 Jun 2012 14:36:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606123625.GA13453@aepfle.de>
References: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 Release / TODO 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 Wed, Jun 06, Ian Campbell wrote:

> If you are aware of any bugs which must/should be fixed for 4.2 then
> please reply to this thread (otherwise I may not remember to pick them
> up next week)

A regression compared to 4.1 and earlier, during tools build additional
CFLAGS cant be easily passed to make. This patch addresses it:

http://lists.xen.org/archives/html/xen-devel/2012-06/msg00186.html


Olaf

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 12:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12: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 1ScFTS-0006AX-Qz; Wed, 06 Jun 2012 12:36:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1ScFTR-0006AS-Us
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:36:30 +0000
Received: from [85.158.143.99:59656] by server-2.bemta-4.messagelabs.com id
	8A/4B-17938-DCE4FCF4; Wed, 06 Jun 2012 12:36:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1338986188!31007061!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDkxMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDkxMjY=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7174 invoked from network); 6 Jun 2012 12:36:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 12:36:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69j6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-10.vodafone-net.de [80.226.24.10])
	by smtp.strato.de (jorabe mo23) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I07a1eo56BgNZX ;
	Wed, 6 Jun 2012 14:36:27 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 889CC18638; Wed,  6 Jun 2012 14:36:25 +0200 (CEST)
Date: Wed, 6 Jun 2012 14:36:25 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606123625.GA13453@aepfle.de>
References: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 Release / TODO 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 Wed, Jun 06, Ian Campbell wrote:

> If you are aware of any bugs which must/should be fixed for 4.2 then
> please reply to this thread (otherwise I may not remember to pick them
> up next week)

A regression compared to 4.1 and earlier, during tools build additional
CFLAGS cant be easily passed to make. This patch addresses it:

http://lists.xen.org/archives/html/xen-devel/2012-06/msg00186.html


Olaf

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 12:46:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12: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 1ScFcP-0006U9-W4; Wed, 06 Jun 2012 12:45:45 +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 1ScFcN-0006U4-TK
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:45:44 +0000
Received: from [193.109.254.147:10281] by server-2.bemta-14.messagelabs.com id
	FE/4E-27740-7F05FCF4; Wed, 06 Jun 2012 12:45:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338986742!5146448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13058 invoked from network); 6 Jun 2012 12:45:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 12:45:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12858596"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 12:45:42 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 13:45:42 +0100
Date: Wed, 6 Jun 2012 13:45:35 +0100
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: <1338565207-2888-4-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061345230.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-4-git-send-email-ian.campbell@citrix.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] [PATCH 04/38] arm: correct and expand TLB flush
 CP15 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, 1 Jun 2012, Ian Campbell wrote:
> Correct spelling of TLBIALLHIS and correct definition of TLBIALLNSNHIS.
> 
> Add a few more.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/include/asm-arm/cpregs.h |   11 +++++++++--
>  1 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> index ee8a287..7a0b49a 100644
> --- a/xen/include/asm-arm/cpregs.h
> +++ b/xen/include/asm-arm/cpregs.h
> @@ -172,12 +172,19 @@
>  #define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
>  #define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
>  #define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
> +#define ITLBIALL        p15,0,c8,c5,0   /* Invalidate instruction TLB */
> +#define ITLBIMVA        p15,0,c8,c5,1   /* Invalidate instruction TLB entry by MVA */
> +#define ITLBIASID       p15,0,c8,c5,2   /* Invalidate instruction TLB by ASID match */
>  #define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
>  #define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
>  #define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
> -#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
> +#define TLBIALL         p15,0,c8,c7,0   /* invalidate unified TLB */
> +#define TLBIMVA         p15,0,c8,c7,1   /* invalidate unified TLB entry by MVA */
> +#define TLBIASID        p15,0,c8,c7,2   /* invalid unified TLB by ASID match */
> +#define TLBIMVAA        p15,0,c8,c7,3   /* invalidate unified TLB entries by MVA all ASID */
> +#define TLBIALLHIS      p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
>  #define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
> -#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
> +#define TLBIALLNSNHIS   p15,4,c8,c3,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
>  #define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
>  #define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
>  #define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
> -- 
> 1.7.9.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 Wed Jun 06 12:46:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12: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 1ScFcP-0006U9-W4; Wed, 06 Jun 2012 12:45:45 +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 1ScFcN-0006U4-TK
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:45:44 +0000
Received: from [193.109.254.147:10281] by server-2.bemta-14.messagelabs.com id
	FE/4E-27740-7F05FCF4; Wed, 06 Jun 2012 12:45:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338986742!5146448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13058 invoked from network); 6 Jun 2012 12:45:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 12:45:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12858596"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 12:45:42 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 13:45:42 +0100
Date: Wed, 6 Jun 2012 13:45:35 +0100
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: <1338565207-2888-4-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061345230.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-4-git-send-email-ian.campbell@citrix.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] [PATCH 04/38] arm: correct and expand TLB flush
 CP15 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, 1 Jun 2012, Ian Campbell wrote:
> Correct spelling of TLBIALLHIS and correct definition of TLBIALLNSNHIS.
> 
> Add a few more.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/include/asm-arm/cpregs.h |   11 +++++++++--
>  1 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> index ee8a287..7a0b49a 100644
> --- a/xen/include/asm-arm/cpregs.h
> +++ b/xen/include/asm-arm/cpregs.h
> @@ -172,12 +172,19 @@
>  #define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
>  #define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
>  #define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
> +#define ITLBIALL        p15,0,c8,c5,0   /* Invalidate instruction TLB */
> +#define ITLBIMVA        p15,0,c8,c5,1   /* Invalidate instruction TLB entry by MVA */
> +#define ITLBIASID       p15,0,c8,c5,2   /* Invalidate instruction TLB by ASID match */
>  #define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
>  #define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
>  #define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
> -#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
> +#define TLBIALL         p15,0,c8,c7,0   /* invalidate unified TLB */
> +#define TLBIMVA         p15,0,c8,c7,1   /* invalidate unified TLB entry by MVA */
> +#define TLBIASID        p15,0,c8,c7,2   /* invalid unified TLB by ASID match */
> +#define TLBIMVAA        p15,0,c8,c7,3   /* invalidate unified TLB entries by MVA all ASID */
> +#define TLBIALLHIS      p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
>  #define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
> -#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
> +#define TLBIALLNSNHIS   p15,4,c8,c3,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
>  #define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
>  #define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
>  #define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
> -- 
> 1.7.9.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 Wed Jun 06 12:51:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScFhc-0006iL-Fo; Wed, 06 Jun 2012 12:51:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1ScFhb-0006i5-4y
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:51:07 +0000
Received: from [85.158.139.83:64251] by server-7.bemta-5.messagelabs.com id
	CD/3E-19648-A325FCF4; Wed, 06 Jun 2012 12:51:06 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-10.tower-182.messagelabs.com!1338987062!32580457!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	UNPARSEABLE_RELAY,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22792 invoked from network); 6 Jun 2012 12:51:03 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-10.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 6 Jun 2012 12:51:03 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1612641Ab2FFMur (ORCPT <rfc822;xen-devel@lists.xen.org>);
	Wed, 6 Jun 2012 14:50:47 +0200
Date: Wed, 6 Jun 2012 14:50:47 +0200
From: Daniel Kiper <dkiper@net-space.pl>
To: James Paton <paton@cs.wisc.edu>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606125047.GA12043@router-fw-old.local.net-space.pl>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338974024.32319.29.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.3.28i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 10:13:44AM +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote:
> > Hi,
> >
> > Apologies if this is not the appropriate list, but I thought I would
> > have better luck here than on xen-users.
> >
> > I'm a CS graduate student hacking on the xen-blkback driver and would
> > like to be able to debug it using gdb over serial. I have spent a great
> > deal of time on this with no success (more details can be found at
> > http://bit.ly/KMEF6o (Stack Overflow)).
> >
> > It eventually occurred to me that it might not even be possible to do
> > what I'm trying to do if Xen intercepts interrupts from the serial port
> > and tries to direct them to dom0 through some unexpected channel. Then,
> > after I've done `echo g > /proc/sysrq_trigger`, the kernel debugger
> > might not see the interrupt. Can anyone confirm or disconfirm this?
>
> It's not something I've ever tried but I expect that if you avoid
> console=com1 (or com*) on your hypervisor command line then the com port
> should be available for dom0 just like on native.
>
> Alternatively you could perhaps separate the two by using com1 for Xen
> and com2/ttyS1 for dom0/kdb etc.
>
> I've no idea if kdb would be expected to work over hvc*. I suspect you'd
> be treading fresh ground with that one...
>
> I'd also start by taking virtual box out of the equation on the host
> side. Start by using a MacOS terminal emulator and checking that you can
> see the dom0 console messages and login via a getty running on ttyS0
> before trying to hook up gdb.
>
> > What is the usual procedure for debugging the Dom0 kernel?
>
> Printk ;-)

:-)))))) any variation of this is the best debugging tool for every piece of software...

... but another option is plain QEMU. Just download it (http://wiki.qemu.org/Main_Page),
install minimal set of software relevant for your needs and look for following options:
  - -serial - is a must; I use following combination:
     ... -serial telnet:127.0.0.1:10232,server ...
     you could access it by: telnet 127.0.0.1 10232
  - -gdb - remote access for GDB; I use following combination:
    ... -gdb tcp:127.0.0.1:1234 ...
    you could connect from GDB using following command:
    target remote :1234
    do not forget to compile your software with symbols
  - -monitor - useful if you need check something in memory
    (especially if you know only physical address - xp command;
    but also look for others; I am sure that some could be useful
    for you); I use following combination:
    ... -monitor telnet:127.0.0.1:1233,server,nowait ...
    you could access it by: telnet 127.0.0.1 1233
    quit from monitor: Ctrl-] and then quit command
  - -debugcon - I have not tested it yet but it looks very promising;
    usage is very similar to serial option; however, you do not need
    to do any hardware initialization (serial ports require it);
    just send anything to port 0xe9 (simple outb)

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 12:51:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 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 1ScFhc-0006iL-Fo; Wed, 06 Jun 2012 12:51:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1ScFhb-0006i5-4y
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:51:07 +0000
Received: from [85.158.139.83:64251] by server-7.bemta-5.messagelabs.com id
	CD/3E-19648-A325FCF4; Wed, 06 Jun 2012 12:51:06 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-10.tower-182.messagelabs.com!1338987062!32580457!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	UNPARSEABLE_RELAY,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22792 invoked from network); 6 Jun 2012 12:51:03 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-10.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 6 Jun 2012 12:51:03 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1612641Ab2FFMur (ORCPT <rfc822;xen-devel@lists.xen.org>);
	Wed, 6 Jun 2012 14:50:47 +0200
Date: Wed, 6 Jun 2012 14:50:47 +0200
From: Daniel Kiper <dkiper@net-space.pl>
To: James Paton <paton@cs.wisc.edu>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606125047.GA12043@router-fw-old.local.net-space.pl>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338974024.32319.29.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.3.28i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 10:13:44AM +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote:
> > Hi,
> >
> > Apologies if this is not the appropriate list, but I thought I would
> > have better luck here than on xen-users.
> >
> > I'm a CS graduate student hacking on the xen-blkback driver and would
> > like to be able to debug it using gdb over serial. I have spent a great
> > deal of time on this with no success (more details can be found at
> > http://bit.ly/KMEF6o (Stack Overflow)).
> >
> > It eventually occurred to me that it might not even be possible to do
> > what I'm trying to do if Xen intercepts interrupts from the serial port
> > and tries to direct them to dom0 through some unexpected channel. Then,
> > after I've done `echo g > /proc/sysrq_trigger`, the kernel debugger
> > might not see the interrupt. Can anyone confirm or disconfirm this?
>
> It's not something I've ever tried but I expect that if you avoid
> console=com1 (or com*) on your hypervisor command line then the com port
> should be available for dom0 just like on native.
>
> Alternatively you could perhaps separate the two by using com1 for Xen
> and com2/ttyS1 for dom0/kdb etc.
>
> I've no idea if kdb would be expected to work over hvc*. I suspect you'd
> be treading fresh ground with that one...
>
> I'd also start by taking virtual box out of the equation on the host
> side. Start by using a MacOS terminal emulator and checking that you can
> see the dom0 console messages and login via a getty running on ttyS0
> before trying to hook up gdb.
>
> > What is the usual procedure for debugging the Dom0 kernel?
>
> Printk ;-)

:-)))))) any variation of this is the best debugging tool for every piece of software...

... but another option is plain QEMU. Just download it (http://wiki.qemu.org/Main_Page),
install minimal set of software relevant for your needs and look for following options:
  - -serial - is a must; I use following combination:
     ... -serial telnet:127.0.0.1:10232,server ...
     you could access it by: telnet 127.0.0.1 10232
  - -gdb - remote access for GDB; I use following combination:
    ... -gdb tcp:127.0.0.1:1234 ...
    you could connect from GDB using following command:
    target remote :1234
    do not forget to compile your software with symbols
  - -monitor - useful if you need check something in memory
    (especially if you know only physical address - xp command;
    but also look for others; I am sure that some could be useful
    for you); I use following combination:
    ... -monitor telnet:127.0.0.1:1233,server,nowait ...
    you could access it by: telnet 127.0.0.1 1233
    quit from monitor: Ctrl-] and then quit command
  - -debugcon - I have not tested it yet but it looks very promising;
    usage is very similar to serial option; however, you do not need
    to do any hardware initialization (serial ports require it);
    just send anything to port 0xe9 (simple outb)

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 12:54:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScFkj-0006xU-3o; Wed, 06 Jun 2012 12:54: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 1ScFkg-0006xJ-Kk
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 12:54:18 +0000
Received: from [85.158.139.83:35812] by server-4.bemta-5.messagelabs.com id
	5B/96-05858-9F25FCF4; Wed, 06 Jun 2012 12:54:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338987257!28302984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31239 invoked from network); 6 Jun 2012 12:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 12:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12858815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 12:54:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	13:54:16 +0100
Message-ID: <1338987255.32319.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 6 Jun 2012 13:54:15 +0100
In-Reply-To: <fde8ad0252ee6ddb8d71.1338562529@probook.site>
References: <fde8ad0252ee6ddb8d71.1338562529@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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 Fri, 2012-06-01 at 15:55 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338562334 -7200
> # Node ID fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
> # Parent  3b4346d6002e9ffcd4a9f50b031bd2a77b16b1dd
> xl.cfg: document the maxmem= option
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Applied, thanks.

> 
> diff -r 3b4346d6002e -r fde8ad0252ee docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -174,6 +174,16 @@ Honoured by the sedf scheduler.
>  
>  Start the guest with MBYTES megabytes of RAM.
>  
> +=item B<maxmem=MBYTES>
> +
> +Specifies the maximum amount of memory a guest can ever see.
> +The value of B<maxmem=> must be equal or greater than B<memory=>.
> +
> +In combination with B<memory=> it will start the guest "pre-ballooned",
> +if the values of B<memory=> and B<maxmem=> differ.
> +A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
> +it will crash.
> +
>  =item B<on_poweroff="ACTION">
>  
>  Specifies what should be done with the domain if it shuts itself down.
> @@ -971,10 +981,6 @@ XXX
>  
>  XXX
>  
> -=item B<maxmem=NUMBER>
> -
> -XXX
> -
>  =item B<nodes=XXX>
>  
>  XXX
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 12:54:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScFkj-0006xU-3o; Wed, 06 Jun 2012 12:54: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 1ScFkg-0006xJ-Kk
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 12:54:18 +0000
Received: from [85.158.139.83:35812] by server-4.bemta-5.messagelabs.com id
	5B/96-05858-9F25FCF4; Wed, 06 Jun 2012 12:54:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1338987257!28302984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31239 invoked from network); 6 Jun 2012 12:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 12:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12858815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 12:54:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	13:54:16 +0100
Message-ID: <1338987255.32319.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 6 Jun 2012 13:54:15 +0100
In-Reply-To: <fde8ad0252ee6ddb8d71.1338562529@probook.site>
References: <fde8ad0252ee6ddb8d71.1338562529@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= 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 Fri, 2012-06-01 at 15:55 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1338562334 -7200
> # Node ID fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62
> # Parent  3b4346d6002e9ffcd4a9f50b031bd2a77b16b1dd
> xl.cfg: document the maxmem= option
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Applied, thanks.

> 
> diff -r 3b4346d6002e -r fde8ad0252ee docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -174,6 +174,16 @@ Honoured by the sedf scheduler.
>  
>  Start the guest with MBYTES megabytes of RAM.
>  
> +=item B<maxmem=MBYTES>
> +
> +Specifies the maximum amount of memory a guest can ever see.
> +The value of B<maxmem=> must be equal or greater than B<memory=>.
> +
> +In combination with B<memory=> it will start the guest "pre-ballooned",
> +if the values of B<memory=> and B<maxmem=> differ.
> +A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
> +it will crash.
> +
>  =item B<on_poweroff="ACTION">
>  
>  Specifies what should be done with the domain if it shuts itself down.
> @@ -971,10 +981,6 @@ XXX
>  
>  XXX
>  
> -=item B<maxmem=NUMBER>
> -
> -XXX
> -
>  =item B<nodes=XXX>
>  
>  XXX
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 12:59:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12: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 1ScFpC-0007BE-R3; Wed, 06 Jun 2012 12:58: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 1ScFpB-0007B6-US
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:58:58 +0000
Received: from [85.158.143.99:36096] by server-2.bemta-4.messagelabs.com id
	3B/F2-17938-1145FCF4; Wed, 06 Jun 2012 12:58:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338987535!21923806!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14472 invoked from network); 6 Jun 2012 12:58:56 -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;
	6 Jun 2012 12:58:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="197717340"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 08:58:54 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	08:58:54 -0400
Message-ID: <4FCF540D.3050004@citrix.com>
Date: Wed, 6 Jun 2012 13:58:53 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 Release / TODO 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 06/06/12 11:27, Ian Campbell wrote:
> 
> If you are aware of any bugs which must/should be fixed for 4.2 then
> please reply to this thread (otherwise I may not remember to pick them
> up next week)

This qemu build patch hasn't been picked up yet.

http://lists.xen.org/archives/html/xen-devel/2012-05/msg02199.html

David

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 12:59:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 12: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 1ScFpC-0007BE-R3; Wed, 06 Jun 2012 12:58: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 1ScFpB-0007B6-US
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 12:58:58 +0000
Received: from [85.158.143.99:36096] by server-2.bemta-4.messagelabs.com id
	3B/F2-17938-1145FCF4; Wed, 06 Jun 2012 12:58:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1338987535!21923806!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTgxOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14472 invoked from network); 6 Jun 2012 12:58:56 -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;
	6 Jun 2012 12:58:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="197717340"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 08:58:54 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	08:58:54 -0400
Message-ID: <4FCF540D.3050004@citrix.com>
Date: Wed, 6 Jun 2012 13:58:53 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338978451.32319.46.camel@zakaz.uk.xensource.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 Release / TODO 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 06/06/12 11:27, Ian Campbell wrote:
> 
> If you are aware of any bugs which must/should be fixed for 4.2 then
> please reply to this thread (otherwise I may not remember to pick them
> up next week)

This qemu build patch hasn't been picked up yet.

http://lists.xen.org/archives/html/xen-devel/2012-05/msg02199.html

David

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScFu5-0007Qe-Ib; Wed, 06 Jun 2012 13:04: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 1ScFu3-0007QS-VG
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:04:00 +0000
Received: from [85.158.139.83:17534] by server-11.bemta-5.messagelabs.com id
	E7/65-25194-F355FCF4; Wed, 06 Jun 2012 13:03:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338987838!32167764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16160 invoked from network); 6 Jun 2012 13:03:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:03:58 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:03:58 +0100
Date: Wed, 6 Jun 2012 14:03:51 +0100
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: <1338565207-2888-5-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061403450.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-5-git-send-email-ian.campbell@citrix.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] [PATCH 05/38] arm: restore stack on return from
 trap.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> We align the stack before calling into C code but we weren't undoing this on
> return.
> 
> Collapse continue_(non)idle_domain into continue_new_vcpu.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c |   16 +++-------------
>  xen/arch/arm/entry.S  |    5 ++++-
>  2 files changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 4b38790..9339a11 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -16,17 +16,6 @@
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
> -static void continue_idle_domain(struct vcpu *v)
> -{
> -    reset_stack_and_jump(idle_loop);
> -}
> -
> -static void continue_nonidle_domain(struct vcpu *v)
> -{
> -    /* check_wakeup_from_wait(); */
> -    reset_stack_and_jump(return_from_trap);
> -}
> -
>  void idle_loop(void)
>  {
>      for ( ; ; )
> @@ -72,9 +61,10 @@ static void continue_new_vcpu(struct vcpu *prev)
>      schedule_tail(prev);
>  
>      if ( is_idle_vcpu(current) )
> -        continue_idle_domain(current);
> +        reset_stack_and_jump(idle_loop);
>      else
> -        continue_nonidle_domain(current);
> +        /* check_wakeup_from_wait(); */
> +        reset_stack_and_jump(return_to_new_vcpu);
>  }
>  
>  void context_switch(struct vcpu *prev, struct vcpu *next)
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index f261a9f..7a22e2d 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -72,7 +72,9 @@ DEFINE_TRAP_ENTRY(hypervisor)
>  DEFINE_TRAP_ENTRY(irq)
>  DEFINE_TRAP_ENTRY(fiq)
>  
> -ENTRY(return_from_trap)
> +return_from_trap:
> +	mov sp, r11
> +ENTRY(return_to_new_vcpu)
>  	ldr r11, [sp, #UREGS_cpsr]
>  	and r11, #PSR_MODE_MASK
>  	cmp r11, #PSR_MODE_HYP
> @@ -82,6 +84,7 @@ ENTRY(return_to_guest)
>  	mov r11, sp
>  	bic sp, #7 /* Align the stack pointer */
>  	bl leave_hypervisor_tail
> +	mov sp, r11
>  	RESTORE_ONE_BANKED(SP_usr)
>  	/* LR_usr is the same physical register as lr and is restored below */
>  	RESTORE_BANKED(svc)
> -- 
> 1.7.9.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 Wed Jun 06 13:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScFu5-0007Qe-Ib; Wed, 06 Jun 2012 13:04: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 1ScFu3-0007QS-VG
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:04:00 +0000
Received: from [85.158.139.83:17534] by server-11.bemta-5.messagelabs.com id
	E7/65-25194-F355FCF4; Wed, 06 Jun 2012 13:03:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1338987838!32167764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16160 invoked from network); 6 Jun 2012 13:03:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:03:58 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:03:58 +0100
Date: Wed, 6 Jun 2012 14:03:51 +0100
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: <1338565207-2888-5-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061403450.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-5-git-send-email-ian.campbell@citrix.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] [PATCH 05/38] arm: restore stack on return from
 trap.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> We align the stack before calling into C code but we weren't undoing this on
> return.
> 
> Collapse continue_(non)idle_domain into continue_new_vcpu.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c |   16 +++-------------
>  xen/arch/arm/entry.S  |    5 ++++-
>  2 files changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 4b38790..9339a11 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -16,17 +16,6 @@
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
> -static void continue_idle_domain(struct vcpu *v)
> -{
> -    reset_stack_and_jump(idle_loop);
> -}
> -
> -static void continue_nonidle_domain(struct vcpu *v)
> -{
> -    /* check_wakeup_from_wait(); */
> -    reset_stack_and_jump(return_from_trap);
> -}
> -
>  void idle_loop(void)
>  {
>      for ( ; ; )
> @@ -72,9 +61,10 @@ static void continue_new_vcpu(struct vcpu *prev)
>      schedule_tail(prev);
>  
>      if ( is_idle_vcpu(current) )
> -        continue_idle_domain(current);
> +        reset_stack_and_jump(idle_loop);
>      else
> -        continue_nonidle_domain(current);
> +        /* check_wakeup_from_wait(); */
> +        reset_stack_and_jump(return_to_new_vcpu);
>  }
>  
>  void context_switch(struct vcpu *prev, struct vcpu *next)
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index f261a9f..7a22e2d 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -72,7 +72,9 @@ DEFINE_TRAP_ENTRY(hypervisor)
>  DEFINE_TRAP_ENTRY(irq)
>  DEFINE_TRAP_ENTRY(fiq)
>  
> -ENTRY(return_from_trap)
> +return_from_trap:
> +	mov sp, r11
> +ENTRY(return_to_new_vcpu)
>  	ldr r11, [sp, #UREGS_cpsr]
>  	and r11, #PSR_MODE_MASK
>  	cmp r11, #PSR_MODE_HYP
> @@ -82,6 +84,7 @@ ENTRY(return_to_guest)
>  	mov r11, sp
>  	bic sp, #7 /* Align the stack pointer */
>  	bl leave_hypervisor_tail
> +	mov sp, r11
>  	RESTORE_ONE_BANKED(SP_usr)
>  	/* LR_usr is the same physical register as lr and is restored below */
>  	RESTORE_BANKED(svc)
> -- 
> 1.7.9.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 Wed Jun 06 13:05:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScFvU-0007XC-1X; Wed, 06 Jun 2012 13:05:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScFvS-0007Wz-4O
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 13:05:26 +0000
Received: from [193.109.254.147:43545] by server-5.bemta-14.messagelabs.com id
	4A/78-31398-5955FCF4; Wed, 06 Jun 2012 13:05:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338987920!5150308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7952 invoked from network); 6 Jun 2012 13:05:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:05:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:05:20 +0100
Message-ID: <1338987918.32319.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 6 Jun 2012 14:05:18 +0100
In-Reply-To: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
> changeset:   25454:1804a873a64d
> tag:         tip
> user:        Zhou Peng <ailvpeng25@gmail.com>
> date:        Tue Jun 05 17:56:46 2012 +0800
> files:       tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
> description:
> tools:libxl: Add qxl vga interface support.
> 
> Usage:
>  qxl=1
>  qxlvram=64
>  qxlram=64
> 
> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

Thanks.

As previously mentioned this is  4.3 material. Please can you resubmit
once the 4.3 dev cycle opens.

> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/libxl_create.c	Tue Jun 05 17:56:46 2012 +0800
> @@ -23,6 +23,32 @@
>  #include <xc_dom.h>
>  #include <xenguest.h>
> 
> +/*
> + * For qxl vga interface, the total video mem is determined by
> + * RAM bar and VRAM bar. But it is not simply linearly determined,
> + * get_qxl_ram_size below gives the details.

>From this statement I expected get_qxl_ram_size to have a nice comment
explaining what is going on, but it doesn't have this.

Can you please explain somewhere how this value is determined (I can see
it is not simple ;-)). Perhaps a link to some QXL/qemu document
discussing these parameters would be helpful too?

> + */
> +static inline uint32_t msb_mask(uint32_t val)
> +{
> +    uint32_t mask;
> +
> +    do {
> +        mask = ~(val - 1) & val;
> +        val &= ~mask;
> +    } while (mask < val);
> +
> +    return mask;
> +}
> +
> +static inline uint32_t get_qxl_ram_size(uint32_t vram_sizekb,
> +                                    uint32_t ram_sizekb)
> +{
> +    uint32_t vram = msb_mask(2 * vram_sizekb * 1024 - 1);
> +    uint32_t ram = msb_mask(2 * ram_sizekb * 1024 - 1);

Why 2*?

> +
> +    return (vram + ram + 1023) / 1024;
> +}
> +
>  void libxl_domain_config_init(libxl_domain_config *d_config)
>  {
>      memset(d_config, 0, sizeof(*d_config));
> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
> 
>          if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
>              b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> +            && b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->u.hvm.vga.vramkb == LIBXL_MEMKB_DEFAULT)
> +                b_info->u.hvm.vga.vramkb = 64 * 1024;
> +            if (b_info->u.hvm.vga.ramkb == LIBXL_MEMKB_DEFAULT)
> +                b_info->u.hvm.vga.ramkb = 64 * 1024;
> +            uint32_t qxl_ram = get_qxl_ram_size(b_info->u.hvm.vga.vramkb,
> +                                                b_info->u.hvm.vga.ramkb);
> +            /*
> +             * video_memkb is the real size of video memory to assign.
> +             * If video_memkb can't meet the need of qxl, adjust it
> +             * accordingly.
> +             */
> +            if ((b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +                || (b_info->video_memkb < qxl_ram)) {
> +                b_info->video_memkb = qxl_ram;

If video_memkb is != LIBXL_MEMKB_DEFAULT and it is not sufficiently
large then I think the correct thing to do is to error out and return
ERROR_INVAL. 

If it is == LIBXL_MEMKB_DEFAULT then of course you can feel free to
override as necessary.

e.g.
               if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
                   b_info->video_memkb = qxl_ram;
               if (b_info->video_memkb < qxl_ram) {
                   LOG(...)
                   return ERROR_INVAL;
               }

> +            }
> +        }
> +
>          libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
>          if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>              libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/libxl_dm.c	Tue Jun 05 17:56:46 2012 +0800
> @@ -181,6 +181,8 @@ static char ** libxl__build_device_model
>              flexarray_append(dm_args, "-std-vga");
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
>              break;
>          }
> 
> @@ -429,6 +431,17 @@ static char ** libxl__build_device_model
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>              flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> +            flexarray_vappend(dm_args, "-global",
> +                              GCSPRINTF("qxl-vga.vram_size=%lu",
> +                                        b_info->u.hvm.vga.vramkb * 1024),
> +                              NULL);
> +            flexarray_vappend(dm_args, "-global",
> +                              GCSPRINTF("qxl-vga.ram_size=%lu",
> +                                        b_info->u.hvm.vga.ramkb * 1024),
> +                              NULL);
>              break;
>          }
> 
> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/libxl_types.idl	Tue Jun 05 17:56:46 2012 +0800
> @@ -128,6 +128,7 @@ libxl_vga_interface_type = Enumeration("
>  libxl_vga_interface_type = Enumeration("vga_interface_type", [
>      (0, "CIRRUS"),
>      (1, "STD"),
> +    (2, "QXL"),
>      ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
> 
>  #
> @@ -136,6 +137,10 @@ libxl_vga_interface_type = Enumeration("
> 
>  libxl_vga_interface_info = Struct("vga_interface_info", [
>      ("type",    libxl_vga_interface_type),
> +    # VRAM bar for qxl
> +    ("vramkb",  MemKB),
> +    # RAM bar for qxl
> +    ("ramkb",  MemKB),
>      ])
> 
>  libxl_vnc_info = Struct("vnc_info", [
> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:56:46 2012 +0800
> @@ -1260,6 +1260,16 @@ skip_vfb:
>              if (l)
>                  b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
> 
> +        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
> +            if (l) {
> +                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_QXL;
> +                if (!xlu_cfg_get_long (config, "qxlvram", &l, 0))
> +                    b_info->u.hvm.vga.vramkb = l * 1024;
> +                if (!xlu_cfg_get_long (config, "qxlram", &l, 0))
> +                    b_info->u.hvm.vga.ramkb = l * 1024;
> +            }
> +        }
> +
>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
>          xlu_cfg_replace_string (config, "vnclisten",
>                                  &b_info->u.hvm.vnc.listen, 0);
> 
> 



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:05:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScFvU-0007XC-1X; Wed, 06 Jun 2012 13:05:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScFvS-0007Wz-4O
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 13:05:26 +0000
Received: from [193.109.254.147:43545] by server-5.bemta-14.messagelabs.com id
	4A/78-31398-5955FCF4; Wed, 06 Jun 2012 13:05:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1338987920!5150308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7952 invoked from network); 6 Jun 2012 13:05:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:05:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:05:20 +0100
Message-ID: <1338987918.32319.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 6 Jun 2012 14:05:18 +0100
In-Reply-To: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
> changeset:   25454:1804a873a64d
> tag:         tip
> user:        Zhou Peng <ailvpeng25@gmail.com>
> date:        Tue Jun 05 17:56:46 2012 +0800
> files:       tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
> description:
> tools:libxl: Add qxl vga interface support.
> 
> Usage:
>  qxl=1
>  qxlvram=64
>  qxlram=64
> 
> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

Thanks.

As previously mentioned this is  4.3 material. Please can you resubmit
once the 4.3 dev cycle opens.

> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/libxl_create.c	Tue Jun 05 17:56:46 2012 +0800
> @@ -23,6 +23,32 @@
>  #include <xc_dom.h>
>  #include <xenguest.h>
> 
> +/*
> + * For qxl vga interface, the total video mem is determined by
> + * RAM bar and VRAM bar. But it is not simply linearly determined,
> + * get_qxl_ram_size below gives the details.

>From this statement I expected get_qxl_ram_size to have a nice comment
explaining what is going on, but it doesn't have this.

Can you please explain somewhere how this value is determined (I can see
it is not simple ;-)). Perhaps a link to some QXL/qemu document
discussing these parameters would be helpful too?

> + */
> +static inline uint32_t msb_mask(uint32_t val)
> +{
> +    uint32_t mask;
> +
> +    do {
> +        mask = ~(val - 1) & val;
> +        val &= ~mask;
> +    } while (mask < val);
> +
> +    return mask;
> +}
> +
> +static inline uint32_t get_qxl_ram_size(uint32_t vram_sizekb,
> +                                    uint32_t ram_sizekb)
> +{
> +    uint32_t vram = msb_mask(2 * vram_sizekb * 1024 - 1);
> +    uint32_t ram = msb_mask(2 * ram_sizekb * 1024 - 1);

Why 2*?

> +
> +    return (vram + ram + 1023) / 1024;
> +}
> +
>  void libxl_domain_config_init(libxl_domain_config *d_config)
>  {
>      memset(d_config, 0, sizeof(*d_config));
> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
> 
>          if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
>              b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> +            && b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->u.hvm.vga.vramkb == LIBXL_MEMKB_DEFAULT)
> +                b_info->u.hvm.vga.vramkb = 64 * 1024;
> +            if (b_info->u.hvm.vga.ramkb == LIBXL_MEMKB_DEFAULT)
> +                b_info->u.hvm.vga.ramkb = 64 * 1024;
> +            uint32_t qxl_ram = get_qxl_ram_size(b_info->u.hvm.vga.vramkb,
> +                                                b_info->u.hvm.vga.ramkb);
> +            /*
> +             * video_memkb is the real size of video memory to assign.
> +             * If video_memkb can't meet the need of qxl, adjust it
> +             * accordingly.
> +             */
> +            if ((b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +                || (b_info->video_memkb < qxl_ram)) {
> +                b_info->video_memkb = qxl_ram;

If video_memkb is != LIBXL_MEMKB_DEFAULT and it is not sufficiently
large then I think the correct thing to do is to error out and return
ERROR_INVAL. 

If it is == LIBXL_MEMKB_DEFAULT then of course you can feel free to
override as necessary.

e.g.
               if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
                   b_info->video_memkb = qxl_ram;
               if (b_info->video_memkb < qxl_ram) {
                   LOG(...)
                   return ERROR_INVAL;
               }

> +            }
> +        }
> +
>          libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
>          if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>              libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/libxl_dm.c	Tue Jun 05 17:56:46 2012 +0800
> @@ -181,6 +181,8 @@ static char ** libxl__build_device_model
>              flexarray_append(dm_args, "-std-vga");
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
>              break;
>          }
> 
> @@ -429,6 +431,17 @@ static char ** libxl__build_device_model
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>              flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> +            flexarray_vappend(dm_args, "-global",
> +                              GCSPRINTF("qxl-vga.vram_size=%lu",
> +                                        b_info->u.hvm.vga.vramkb * 1024),
> +                              NULL);
> +            flexarray_vappend(dm_args, "-global",
> +                              GCSPRINTF("qxl-vga.ram_size=%lu",
> +                                        b_info->u.hvm.vga.ramkb * 1024),
> +                              NULL);
>              break;
>          }
> 
> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/libxl_types.idl	Tue Jun 05 17:56:46 2012 +0800
> @@ -128,6 +128,7 @@ libxl_vga_interface_type = Enumeration("
>  libxl_vga_interface_type = Enumeration("vga_interface_type", [
>      (0, "CIRRUS"),
>      (1, "STD"),
> +    (2, "QXL"),
>      ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
> 
>  #
> @@ -136,6 +137,10 @@ libxl_vga_interface_type = Enumeration("
> 
>  libxl_vga_interface_info = Struct("vga_interface_info", [
>      ("type",    libxl_vga_interface_type),
> +    # VRAM bar for qxl
> +    ("vramkb",  MemKB),
> +    # RAM bar for qxl
> +    ("ramkb",  MemKB),
>      ])
> 
>  libxl_vnc_info = Struct("vnc_info", [
> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:39:37 2012 +0800
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Jun 05 17:56:46 2012 +0800
> @@ -1260,6 +1260,16 @@ skip_vfb:
>              if (l)
>                  b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
> 
> +        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
> +            if (l) {
> +                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_QXL;
> +                if (!xlu_cfg_get_long (config, "qxlvram", &l, 0))
> +                    b_info->u.hvm.vga.vramkb = l * 1024;
> +                if (!xlu_cfg_get_long (config, "qxlram", &l, 0))
> +                    b_info->u.hvm.vga.ramkb = l * 1024;
> +            }
> +        }
> +
>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
>          xlu_cfg_replace_string (config, "vnclisten",
>                                  &b_info->u.hvm.vnc.listen, 0);
> 
> 



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:08:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScFxv-0007mr-P0; Wed, 06 Jun 2012 13:07: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 1ScFxu-0007mj-4m
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 13:07:58 +0000
Received: from [85.158.139.83:8504] by server-9.bemta-5.messagelabs.com id
	2E/0D-29678-D265FCF4; Wed, 06 Jun 2012 13:07:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1338988075!31397356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2253 invoked from network); 6 Jun 2012 13:07:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:07:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:07:54 +0100
Message-ID: <1338988073.32319.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 6 Jun 2012 14:07:53 +0100
In-Reply-To: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface 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, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

You can/should include this with the patch which adds the functionality,
no need to separate it out.
 
> 
> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Tue Jun 05 17:56:46 2012 +0800
> +++ b/docs/man/xl.cfg.pod.5	Tue Jun 05 18:58:12 2012 +0800
> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
> 
>  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). The default is 8MB which is sufficient for
> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
> +available. This option is available when using the B<stdvga> and
> +B<qxl> options (see below).
> +For B<stdvga> option, the default is 8MB which is sufficient for
> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> options,
> +the amount of video ram is fixed at 4MB which is sufficient for 1024x768
>  at 32 bpp.
> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
> +option below).
> 
>  =item B<stdvga=BOOLEAN>
> 
> @@ -711,6 +714,27 @@ emulated graphics device. The default is
>  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.
> +
> +=item B<qxl=BOOLEAN>
> +
> +Select a QXL VGA card as the emulated graphics device. This enables
> +the other QXL-related settings.
> +In general, QXL should work with the Spice remote display protocol for
> +acceleration, but QXL driver is necessary in guest. QXL can also work
> +with the VNC protocol like a standard VGA without acceleration.
> +
> +=item B<qxlram=MBYTES>
> +
> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
> +The total size of QXL video memory is determined by B<qxlram> (RAM bar)
> +and B<qxlvram> (VRAM bar), the size of each is settable.
> +B<videoram> can set the amount of RAM which emulated video card
> +will contain, but if it can't meet the need of QXL, it will be
> +adjusted accordingly.
> +
> +=item B<qxlvram=MBYTES>
> +
> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.

It's not clear to me having read this what the distinction between RAM
and VRAM is in the context of QXL. When and why would I want to set
either?

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:08:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScFxv-0007mr-P0; Wed, 06 Jun 2012 13:07: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 1ScFxu-0007mj-4m
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 13:07:58 +0000
Received: from [85.158.139.83:8504] by server-9.bemta-5.messagelabs.com id
	2E/0D-29678-D265FCF4; Wed, 06 Jun 2012 13:07:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1338988075!31397356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2253 invoked from network); 6 Jun 2012 13:07:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:07:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:07:54 +0100
Message-ID: <1338988073.32319.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 6 Jun 2012 14:07:53 +0100
In-Reply-To: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface 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, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

You can/should include this with the patch which adds the functionality,
no need to separate it out.
 
> 
> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Tue Jun 05 17:56:46 2012 +0800
> +++ b/docs/man/xl.cfg.pod.5	Tue Jun 05 18:58:12 2012 +0800
> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
> 
>  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). The default is 8MB which is sufficient for
> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
> +available. This option is available when using the B<stdvga> and
> +B<qxl> options (see below).
> +For B<stdvga> option, the default is 8MB which is sufficient for
> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> options,
> +the amount of video ram is fixed at 4MB which is sufficient for 1024x768
>  at 32 bpp.
> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
> +option below).
> 
>  =item B<stdvga=BOOLEAN>
> 
> @@ -711,6 +714,27 @@ emulated graphics device. The default is
>  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.
> +
> +=item B<qxl=BOOLEAN>
> +
> +Select a QXL VGA card as the emulated graphics device. This enables
> +the other QXL-related settings.
> +In general, QXL should work with the Spice remote display protocol for
> +acceleration, but QXL driver is necessary in guest. QXL can also work
> +with the VNC protocol like a standard VGA without acceleration.
> +
> +=item B<qxlram=MBYTES>
> +
> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
> +The total size of QXL video memory is determined by B<qxlram> (RAM bar)
> +and B<qxlvram> (VRAM bar), the size of each is settable.
> +B<videoram> can set the amount of RAM which emulated video card
> +will contain, but if it can't meet the need of QXL, it will be
> +adjusted accordingly.
> +
> +=item B<qxlvram=MBYTES>
> +
> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.

It's not clear to me having read this what the distinction between RAM
and VRAM is in the context of QXL. When and why would I want to set
either?

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:15: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 1ScG4q-00085n-L9; Wed, 06 Jun 2012 13:15:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScG4p-00085i-8r
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:15:07 +0000
Received: from [85.158.139.83:13216] by server-3.bemta-5.messagelabs.com id
	A9/CF-17554-AD75FCF4; Wed, 06 Jun 2012 13:15:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338988504!30746646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 6 Jun 2012 13:15:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="27043906"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:15:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 09:15:04 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1ScG4l-00084C-HR;
	Wed, 06 Jun 2012 14:15:03 +0100
MIME-Version: 1.0
X-Mercurial-Node: bda11a77fad7c42a58cd2b5eefce50a39e97964b
Message-ID: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 14:15:03 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: remove libxl__error_set prototype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338988494 -3600
# Node ID bda11a77fad7c42a58cd2b5eefce50a39e97964b
# Parent  76d9122d2740b9d9fe9c50497110bd6ccaad9fa3
libxl: remove libxl__error_set prototype

The implementation went away in 25181:26f72d923cb9 "libxl: Crash (more
sensibly) on malloc failure".

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

diff -r 76d9122d2740 -r bda11a77fad7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Jun 06 14:13:16 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Jun 06 14:14:54 2012 +0100
@@ -1313,8 +1313,6 @@ struct libxl__xen_console_reader {
     unsigned int index;
 };
 
-_hidden int libxl__error_set(libxl__gc *gc, int code);
-
 /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
 _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:15: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 1ScG4q-00085n-L9; Wed, 06 Jun 2012 13:15:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScG4p-00085i-8r
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:15:07 +0000
Received: from [85.158.139.83:13216] by server-3.bemta-5.messagelabs.com id
	A9/CF-17554-AD75FCF4; Wed, 06 Jun 2012 13:15:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1338988504!30746646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 6 Jun 2012 13:15:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="27043906"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:15:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 09:15:04 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1ScG4l-00084C-HR;
	Wed, 06 Jun 2012 14:15:03 +0100
MIME-Version: 1.0
X-Mercurial-Node: bda11a77fad7c42a58cd2b5eefce50a39e97964b
Message-ID: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 14:15:03 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: remove libxl__error_set prototype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338988494 -3600
# Node ID bda11a77fad7c42a58cd2b5eefce50a39e97964b
# Parent  76d9122d2740b9d9fe9c50497110bd6ccaad9fa3
libxl: remove libxl__error_set prototype

The implementation went away in 25181:26f72d923cb9 "libxl: Crash (more
sensibly) on malloc failure".

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

diff -r 76d9122d2740 -r bda11a77fad7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Jun 06 14:13:16 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Jun 06 14:14:54 2012 +0100
@@ -1313,8 +1313,6 @@ struct libxl__xen_console_reader {
     unsigned int index;
 };
 
-_hidden int libxl__error_set(libxl__gc *gc, int code);
-
 /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
 _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:22:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGBE-0008GH-GL; Wed, 06 Jun 2012 13:21: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 1ScGBC-0008GC-UM
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:21:43 +0000
Received: from [193.109.254.147:37444] by server-8.bemta-14.messagelabs.com id
	D9/60-27132-6695FCF4; Wed, 06 Jun 2012 13:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1338988899!13046723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12829 invoked from network); 6 Jun 2012 13:21:40 -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;
	6 Jun 2012 13:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="27044569"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:21:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 09:21:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1ScGB8-0008FI-KD;
	Wed, 06 Jun 2012 14:21:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 76d9122d2740b9d9fe9c50497110bd6ccaad9fa3
Message-ID: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 14:21:38 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] xend: do not run a hotplug script from qemu on
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338988396 -3600
# Node ID 76d9122d2740b9d9fe9c50497110bd6ccaad9fa3
# Parent  beca28fe812ffd3c8e50aa5fc6ba89c6b706d5e2
xend: do not run a hotplug script from qemu on Linux

The current vif-hotplug-common.sh for renaming the tap device is failing
because it is racing with this script and therefore the device is unexpectedly
up when we come to rename it.

Fix this in the same way as libxl does, by disabling the script (only on
Linux).

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

diff -r beca28fe812f -r 76d9122d2740 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Wed Jun 06 14:12:25 2012 +0100
+++ b/tools/python/xen/xend/image.py	Wed Jun 06 14:13:16 2012 +0100
@@ -919,8 +919,13 @@ class HVMImageHandler(ImageHandler):
                        (nics, mac, model))
             vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
-            ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
-                       (nics, vifname, bridge))
+            if osdep.tapif_script is not None:
+                script=",script=%s,downscript=%s" % \
+                        (osdep.tapif_script, osdep.tapif_script)
+            else:
+                script=""
+            ret.append("tap,vlan=%d,ifname=%s,bridge=%s%s" %
+                       (nics, vifname, bridge, script))
 
         if nics == 0:
             ret.append("-net")
diff -r beca28fe812f -r 76d9122d2740 tools/python/xen/xend/osdep.py
--- a/tools/python/xen/xend/osdep.py	Wed Jun 06 14:12:25 2012 +0100
+++ b/tools/python/xen/xend/osdep.py	Wed Jun 06 14:13:16 2012 +0100
@@ -30,6 +30,10 @@ _vif_script = {
     "SunOS": "vif-vnic"
 }
 
+_tapif_script = {
+    "Linux": "no",
+}
+
 PROC_XEN_BALLOON = '/proc/xen/balloon'
 SYSFS_XEN_MEMORY = '/sys/devices/system/xen_memory/xen_memory0'
 
@@ -257,6 +261,7 @@ def _get(var, default=None):
 
 xend_autorestart = _get(_xend_autorestart)
 vif_script = _get(_vif_script, "vif-bridge")
+tapif_script = _get(_tapif_script)
 lookup_balloon_stat = _get(_balloon_stat, _linux_balloon_stat)
 get_cpuinfo = _get(_get_cpuinfo, _linux_get_cpuinfo)
 prefork = _get(_get_prefork, _default_prefork)

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:22:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGBE-0008GH-GL; Wed, 06 Jun 2012 13:21: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 1ScGBC-0008GC-UM
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:21:43 +0000
Received: from [193.109.254.147:37444] by server-8.bemta-14.messagelabs.com id
	D9/60-27132-6695FCF4; Wed, 06 Jun 2012 13:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1338988899!13046723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12829 invoked from network); 6 Jun 2012 13:21:40 -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;
	6 Jun 2012 13:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="27044569"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:21:39 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 09:21:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1ScGB8-0008FI-KD;
	Wed, 06 Jun 2012 14:21:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 76d9122d2740b9d9fe9c50497110bd6ccaad9fa3
Message-ID: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 14:21:38 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] xend: do not run a hotplug script from qemu on
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338988396 -3600
# Node ID 76d9122d2740b9d9fe9c50497110bd6ccaad9fa3
# Parent  beca28fe812ffd3c8e50aa5fc6ba89c6b706d5e2
xend: do not run a hotplug script from qemu on Linux

The current vif-hotplug-common.sh for renaming the tap device is failing
because it is racing with this script and therefore the device is unexpectedly
up when we come to rename it.

Fix this in the same way as libxl does, by disabling the script (only on
Linux).

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

diff -r beca28fe812f -r 76d9122d2740 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Wed Jun 06 14:12:25 2012 +0100
+++ b/tools/python/xen/xend/image.py	Wed Jun 06 14:13:16 2012 +0100
@@ -919,8 +919,13 @@ class HVMImageHandler(ImageHandler):
                        (nics, mac, model))
             vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
-            ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
-                       (nics, vifname, bridge))
+            if osdep.tapif_script is not None:
+                script=",script=%s,downscript=%s" % \
+                        (osdep.tapif_script, osdep.tapif_script)
+            else:
+                script=""
+            ret.append("tap,vlan=%d,ifname=%s,bridge=%s%s" %
+                       (nics, vifname, bridge, script))
 
         if nics == 0:
             ret.append("-net")
diff -r beca28fe812f -r 76d9122d2740 tools/python/xen/xend/osdep.py
--- a/tools/python/xen/xend/osdep.py	Wed Jun 06 14:12:25 2012 +0100
+++ b/tools/python/xen/xend/osdep.py	Wed Jun 06 14:13:16 2012 +0100
@@ -30,6 +30,10 @@ _vif_script = {
     "SunOS": "vif-vnic"
 }
 
+_tapif_script = {
+    "Linux": "no",
+}
+
 PROC_XEN_BALLOON = '/proc/xen/balloon'
 SYSFS_XEN_MEMORY = '/sys/devices/system/xen_memory/xen_memory0'
 
@@ -257,6 +261,7 @@ def _get(var, default=None):
 
 xend_autorestart = _get(_xend_autorestart)
 vif_script = _get(_vif_script, "vif-bridge")
+tapif_script = _get(_tapif_script)
 lookup_balloon_stat = _get(_balloon_stat, _linux_balloon_stat)
 get_cpuinfo = _get(_get_cpuinfo, _linux_get_cpuinfo)
 prefork = _get(_get_prefork, _default_prefork)

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:22:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGBX-0008HL-Ss; Wed, 06 Jun 2012 13:22: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 1ScGBW-0008H9-9b
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:22:02 +0000
Received: from [85.158.139.83:57552] by server-5.bemta-5.messagelabs.com id
	DC/37-04481-9795FCF4; Wed, 06 Jun 2012 13:22:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1338988919!27994978!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30890 invoked from network); 6 Jun 2012 13:22:00 -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;
	6 Jun 2012 13:22:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="27044601"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:21:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 09:21:59 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1ScGBS-0008FO-Jo;
	Wed, 06 Jun 2012 14:21:58 +0100
MIME-Version: 1.0
X-Mercurial-Node: beca28fe812ffd3c8e50aa5fc6ba89c6b706d5e2
Message-ID: <beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 14:21:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a
	bzImage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338988345 -3600
# Node ID beca28fe812ffd3c8e50aa5fc6ba89c6b706d5e2
# Parent  04b4bfaaed2f8fc5fb80068dfe2c00305200491d
libxc: do not "panic" if a kernel is not a bzImage.

Up until the point where we think this is a bzImage there is no point in
printing panicy messages -- some other loader will have a go (probably the
compressed ELF one)

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

diff -r 04b4bfaaed2f -r beca28fe812f tools/libxc/xc_dom_bzimageloader.c
--- a/tools/libxc/xc_dom_bzimageloader.c	Wed Jun 06 14:12:12 2012 +0100
+++ b/tools/libxc/xc_dom_bzimageloader.c	Wed Jun 06 14:12:25 2012 +0100
@@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s
 
     if ( dom->kernel_size < sizeof(struct setup_header) )
     {
-        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
-                     "%s: kernel image too small", __FUNCTION__);
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
         return -EINVAL;
     }
 
@@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s
 
     if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
     {
-        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
-                     "%s: kernel is not a bzImage", __FUNCTION__);
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
         return -EINVAL;
     }
 

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:22:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGBX-0008HL-Ss; Wed, 06 Jun 2012 13:22: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 1ScGBW-0008H9-9b
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:22:02 +0000
Received: from [85.158.139.83:57552] by server-5.bemta-5.messagelabs.com id
	DC/37-04481-9795FCF4; Wed, 06 Jun 2012 13:22:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1338988919!27994978!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDkyNTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30890 invoked from network); 6 Jun 2012 13:22:00 -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;
	6 Jun 2012 13:22:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330923600"; d="scan'208";a="27044601"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 09:21:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 6 Jun 2012 09:21:59 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1ScGBS-0008FO-Jo;
	Wed, 06 Jun 2012 14:21:58 +0100
MIME-Version: 1.0
X-Mercurial-Node: beca28fe812ffd3c8e50aa5fc6ba89c6b706d5e2
Message-ID: <beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 6 Jun 2012 14:21:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a
	bzImage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1338988345 -3600
# Node ID beca28fe812ffd3c8e50aa5fc6ba89c6b706d5e2
# Parent  04b4bfaaed2f8fc5fb80068dfe2c00305200491d
libxc: do not "panic" if a kernel is not a bzImage.

Up until the point where we think this is a bzImage there is no point in
printing panicy messages -- some other loader will have a go (probably the
compressed ELF one)

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

diff -r 04b4bfaaed2f -r beca28fe812f tools/libxc/xc_dom_bzimageloader.c
--- a/tools/libxc/xc_dom_bzimageloader.c	Wed Jun 06 14:12:12 2012 +0100
+++ b/tools/libxc/xc_dom_bzimageloader.c	Wed Jun 06 14:12:25 2012 +0100
@@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s
 
     if ( dom->kernel_size < sizeof(struct setup_header) )
     {
-        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
-                     "%s: kernel image too small", __FUNCTION__);
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
         return -EINVAL;
     }
 
@@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s
 
     if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
     {
-        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
-                     "%s: kernel is not a bzImage", __FUNCTION__);
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
         return -EINVAL;
     }
 

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:38:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:38: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 1ScGRK-0000Wv-2B; Wed, 06 Jun 2012 13:38:22 +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 1ScGRI-0000Wm-5f
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:38:20 +0000
Received: from [193.109.254.147:16926] by server-11.bemta-14.messagelabs.com
	id 63/FC-02727-B4D5FCF4; Wed, 06 Jun 2012 13:38:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1338989898!5132841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14090 invoked from network); 6 Jun 2012 13:38:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:38:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:38:18 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:38:18 +0100
Date: Wed, 6 Jun 2012 14:38:11 +0100
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: <1338565207-2888-6-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061438000.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-6-git-send-email-ian.campbell@citrix.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] [PATCH 06/38] arm: enable interrupts while handling
 traps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> For most traps we can do this as soon as we have saved the necessary state.
> For IRQs and FIQs we must wait until we have acked the interrupt with the GIC.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/entry.S |   17 ++++++++++++++---
>  xen/arch/arm/gic.c   |    2 ++
>  xen/arch/arm/traps.c |    1 -
>  3 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index 7a22e2d..5bc3906 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -46,6 +46,17 @@ save_guest_regs:
>  	ALIGN;												\
>  trap_##trap:												\
>  	SAVE_ALL;											\
> +	cpsie i; 	/* local_irq_enable */								\
> +	adr lr, return_from_trap;									\
> +	mov r0, sp;											\
> +	mov r11, sp;											\
> +	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
> +	b do_trap_##trap
> +
> +#define DEFINE_TRAP_ENTRY_NOIRQ(trap)									\
> +	ALIGN;												\
> +trap_##trap:												\
> +	SAVE_ALL;											\
>  	adr lr, return_from_trap;									\
>  	mov r0, sp;											\
>  	mov r11, sp;											\
> @@ -69,8 +80,8 @@ DEFINE_TRAP_ENTRY(supervisor_call)
>  DEFINE_TRAP_ENTRY(prefetch_abort)
>  DEFINE_TRAP_ENTRY(data_abort)
>  DEFINE_TRAP_ENTRY(hypervisor)
> -DEFINE_TRAP_ENTRY(irq)
> -DEFINE_TRAP_ENTRY(fiq)
> +DEFINE_TRAP_ENTRY_NOIRQ(irq)
> +DEFINE_TRAP_ENTRY_NOIRQ(fiq)
>  
>  return_from_trap:
>  	mov sp, r11
> @@ -83,7 +94,7 @@ ENTRY(return_to_new_vcpu)
>  ENTRY(return_to_guest)
>  	mov r11, sp
>  	bic sp, #7 /* Align the stack pointer */
> -	bl leave_hypervisor_tail
> +	bl leave_hypervisor_tail /* Disables interrupts on return */
>  	mov sp, r11
>  	RESTORE_ONE_BANKED(SP_usr)
>  	/* LR_usr is the same physical register as lr and is restored below */
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index cc9d37b..1a2b95f 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -509,6 +509,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>      uint32_t intack = GICC[GICC_IAR];
>      unsigned int irq = intack & GICC_IA_IRQ;
>  
> +    local_irq_enable();
> +
>      if ( irq == 1023 )
>          /* Spurious interrupt */
>          return;
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index abc26a3..5ed754f 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -412,7 +412,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
>  {
>      arm_hypercall_t *call = NULL;
> -    local_irq_enable();
>  
>      if ( iss != XEN_HYPERCALL_TAG )
>      {
> -- 
> 1.7.9.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 Wed Jun 06 13:38:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:38: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 1ScGRK-0000Wv-2B; Wed, 06 Jun 2012 13:38:22 +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 1ScGRI-0000Wm-5f
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:38:20 +0000
Received: from [193.109.254.147:16926] by server-11.bemta-14.messagelabs.com
	id 63/FC-02727-B4D5FCF4; Wed, 06 Jun 2012 13:38:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1338989898!5132841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14090 invoked from network); 6 Jun 2012 13:38:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:38:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12859977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:38:18 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:38:18 +0100
Date: Wed, 6 Jun 2012 14:38:11 +0100
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: <1338565207-2888-6-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061438000.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-6-git-send-email-ian.campbell@citrix.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] [PATCH 06/38] arm: enable interrupts while handling
 traps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> For most traps we can do this as soon as we have saved the necessary state.
> For IRQs and FIQs we must wait until we have acked the interrupt with the GIC.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/entry.S |   17 ++++++++++++++---
>  xen/arch/arm/gic.c   |    2 ++
>  xen/arch/arm/traps.c |    1 -
>  3 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index 7a22e2d..5bc3906 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -46,6 +46,17 @@ save_guest_regs:
>  	ALIGN;												\
>  trap_##trap:												\
>  	SAVE_ALL;											\
> +	cpsie i; 	/* local_irq_enable */								\
> +	adr lr, return_from_trap;									\
> +	mov r0, sp;											\
> +	mov r11, sp;											\
> +	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
> +	b do_trap_##trap
> +
> +#define DEFINE_TRAP_ENTRY_NOIRQ(trap)									\
> +	ALIGN;												\
> +trap_##trap:												\
> +	SAVE_ALL;											\
>  	adr lr, return_from_trap;									\
>  	mov r0, sp;											\
>  	mov r11, sp;											\
> @@ -69,8 +80,8 @@ DEFINE_TRAP_ENTRY(supervisor_call)
>  DEFINE_TRAP_ENTRY(prefetch_abort)
>  DEFINE_TRAP_ENTRY(data_abort)
>  DEFINE_TRAP_ENTRY(hypervisor)
> -DEFINE_TRAP_ENTRY(irq)
> -DEFINE_TRAP_ENTRY(fiq)
> +DEFINE_TRAP_ENTRY_NOIRQ(irq)
> +DEFINE_TRAP_ENTRY_NOIRQ(fiq)
>  
>  return_from_trap:
>  	mov sp, r11
> @@ -83,7 +94,7 @@ ENTRY(return_to_new_vcpu)
>  ENTRY(return_to_guest)
>  	mov r11, sp
>  	bic sp, #7 /* Align the stack pointer */
> -	bl leave_hypervisor_tail
> +	bl leave_hypervisor_tail /* Disables interrupts on return */
>  	mov sp, r11
>  	RESTORE_ONE_BANKED(SP_usr)
>  	/* LR_usr is the same physical register as lr and is restored below */
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index cc9d37b..1a2b95f 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -509,6 +509,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>      uint32_t intack = GICC[GICC_IAR];
>      unsigned int irq = intack & GICC_IA_IRQ;
>  
> +    local_irq_enable();
> +
>      if ( irq == 1023 )
>          /* Spurious interrupt */
>          return;
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index abc26a3..5ed754f 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -412,7 +412,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
>  {
>      arm_hypercall_t *call = NULL;
> -    local_irq_enable();
>  
>      if ( iss != XEN_HYPERCALL_TAG )
>      {
> -- 
> 1.7.9.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 Wed Jun 06 13:39:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGS7-0000ar-Fj; Wed, 06 Jun 2012 13:39:11 +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 1ScGS6-0000aZ-5a
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:39:10 +0000
Received: from [85.158.143.35:31336] by server-1.bemta-4.messagelabs.com id
	EF/53-10042-D7D5FCF4; Wed, 06 Jun 2012 13:39:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338989948!19039253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26091 invoked from network); 6 Jun 2012 13:39:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:39:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:39:08 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:39:08 +0100
Date: Wed, 6 Jun 2012 14:39:02 +0100
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: <1338565207-2888-7-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061438560.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-7-git-send-email-ian.campbell@citrix.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] [PATCH 07/38] arm: hook up domctl and memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/traps.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5ed754f..5d8b7f9 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -373,6 +373,8 @@ typedef unsigned long arm_hypercall_t(
>      [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
>  
>  static arm_hypercall_t *arm_hypercall_table[] = {
> +    HYPERCALL(memory_op),
> +    HYPERCALL(domctl),
>      HYPERCALL(arch_0),
>      HYPERCALL(sched_op),
>      HYPERCALL(console_io),
> -- 
> 1.7.9.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 Wed Jun 06 13:39:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGS7-0000ar-Fj; Wed, 06 Jun 2012 13:39:11 +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 1ScGS6-0000aZ-5a
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:39:10 +0000
Received: from [85.158.143.35:31336] by server-1.bemta-4.messagelabs.com id
	EF/53-10042-D7D5FCF4; Wed, 06 Jun 2012 13:39:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338989948!19039253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26091 invoked from network); 6 Jun 2012 13:39:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:39:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:39:08 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:39:08 +0100
Date: Wed, 6 Jun 2012 14:39:02 +0100
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: <1338565207-2888-7-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061438560.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-7-git-send-email-ian.campbell@citrix.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] [PATCH 07/38] arm: hook up domctl and memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/traps.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5ed754f..5d8b7f9 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -373,6 +373,8 @@ typedef unsigned long arm_hypercall_t(
>      [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
>  
>  static arm_hypercall_t *arm_hypercall_table[] = {
> +    HYPERCALL(memory_op),
> +    HYPERCALL(domctl),
>      HYPERCALL(arch_0),
>      HYPERCALL(sched_op),
>      HYPERCALL(console_io),
> -- 
> 1.7.9.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 Wed Jun 06 13:42:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGV4-0000pU-27; Wed, 06 Jun 2012 13:42:14 +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 1ScGV2-0000pJ-OS
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:42:12 +0000
Received: from [85.158.143.35:49463] by server-1.bemta-4.messagelabs.com id
	F7/68-10042-43E5FCF4; Wed, 06 Jun 2012 13:42:12 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1338990128!15064626!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7396 invoked from network); 6 Jun 2012 13:42:08 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:42:08 -0000
Received: by werf3 with SMTP id f3so5334666wer.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 06:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=41qOGtFVw5NP8gSSH9wcLKqJdx+6EW0zVOn1u8nt1hU=;
	b=HTA+7c3Qt1Y5X+yXGavMQMCL6xqSHIDkHz5cV3D6Nxl7CNwQTiFQjjTj228RKLtCQb
	KTF2sa/DT9x57QEsyRKYSA5yutKjbYTnluny9uOx0JxtS//RVh64huYyFa55j43d0gZ7
	Te/lsPXghxL+UtIbAmRXkynbpTLBU5W99Xw8Vj1aNP3cUd0070uKMjxm0Iwlqe2WZiZU
	XoMqW1xHNazZwee3tH3XzvHiFJm4k1jTSqSW3yfMkyex7W5SQP/mK+wGX0t556SJSACm
	hJNxjx1ZbGB6tyaYAyjoxXXMiakybKSSJWijyPVv9Kqmw46cWDX5CCGZJV4XMzxg+JRb
	iBAw==
Received: by 10.216.228.202 with SMTP id f52mr17062302weq.223.1338990128560;
	Wed, 06 Jun 2012 06:42:08 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id fm1sm2590945wib.10.2012.06.06.06.42.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 06:42:06 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 78af912f1823442009eaff08b7fbf20b7cb1e180
Message-Id: <78af912f1823442009ea.1338990124@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 06 Jun 2012 15:42:04 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6] libxl: introduce LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 avoid recent gcc complaining about:
libxl.c: In function 'libxl_primary_console_exec':
libxl.c:1233:9: error: case value '4294967295' not in enumerated type 'libxl_domain_type' [-Werror=switch]

Also:
 - have all the call sites of libxl__domain_type() return with error in
   case the function returns LIBXL_DOMAIN_TYPE_INVALID;
 - adjust all other code segments where -Wswitch makes would claim that
   LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort();"
   clause.

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

Changes from v5:
 * ERROR_INVAL converted in ERROR_FAIL in libxl_domain_remus_start()
 * Error logging moved in libxl__domain_type()
 * Forgot about libxl_domain_suspend() as requested

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -656,6 +656,11 @@ int libxl_domain_remus_start(libxl_ctx *
     libxl_domain_type type = libxl__domain_type(gc, domid);
     int rc = 0;
 
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto remus_fail;
+    }
+
     if (info == NULL) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "No remus_info structure supplied for domain %d", domid);
@@ -1259,8 +1264,7 @@ int libxl_primary_console_exec(libxl_ctx
         case LIBXL_DOMAIN_TYPE_PV:
             rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
             break;
-        case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
+        case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_FAIL;
             break;
         default:
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
@@ -257,6 +257,8 @@ static char ** libxl__build_device_model
         for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
             flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
+    default:
+        abort();
     }
     flexarray_append(dm_args, NULL);
     return (char **) flexarray_contents(dm_args);
@@ -505,6 +507,8 @@ static char ** libxl__build_device_model
         for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
             flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
+    default:
+        abort();
     }
 
     ram_size = libxl__sizekb_to_mb(b_info->max_memkb - b_info->video_memkb);
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
@@ -32,10 +32,11 @@ libxl_domain_type libxl__domain_type(lib
     int ret;
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
-    if (ret != 1)
-        return -1;
-    if (info.domain != domid)
-        return -1;
+    if (ret != 1 || info.domain != domid) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "unable to get domain type for domid=%"PRIu32, domid);
+        return LIBXL_DOMAIN_TYPE_INVALID;
+    }
     if (info.flags & XEN_DOMINF_hvm_guest)
         return LIBXL_DOMAIN_TYPE_HVM;
     else
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
@@ -28,6 +28,7 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB
 #
 
 libxl_domain_type = Enumeration("domain_type", [
+    (-1, "INVALID"),
     (1, "HVM"),
     (2, "PV"),
     ])
@@ -310,6 +311,7 @@ libxl_domain_build_info = Struct("domain
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", libxl_defbool),
                                       ])),
+                 ("invalid", Struct(None, [])),
                  ], keyvar_init_val = "-1")),
     ], dir=DIR_IN
 )

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:42:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGV4-0000pU-27; Wed, 06 Jun 2012 13:42:14 +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 1ScGV2-0000pJ-OS
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:42:12 +0000
Received: from [85.158.143.35:49463] by server-1.bemta-4.messagelabs.com id
	F7/68-10042-43E5FCF4; Wed, 06 Jun 2012 13:42:12 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1338990128!15064626!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7396 invoked from network); 6 Jun 2012 13:42:08 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:42:08 -0000
Received: by werf3 with SMTP id f3so5334666wer.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 06:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=41qOGtFVw5NP8gSSH9wcLKqJdx+6EW0zVOn1u8nt1hU=;
	b=HTA+7c3Qt1Y5X+yXGavMQMCL6xqSHIDkHz5cV3D6Nxl7CNwQTiFQjjTj228RKLtCQb
	KTF2sa/DT9x57QEsyRKYSA5yutKjbYTnluny9uOx0JxtS//RVh64huYyFa55j43d0gZ7
	Te/lsPXghxL+UtIbAmRXkynbpTLBU5W99Xw8Vj1aNP3cUd0070uKMjxm0Iwlqe2WZiZU
	XoMqW1xHNazZwee3tH3XzvHiFJm4k1jTSqSW3yfMkyex7W5SQP/mK+wGX0t556SJSACm
	hJNxjx1ZbGB6tyaYAyjoxXXMiakybKSSJWijyPVv9Kqmw46cWDX5CCGZJV4XMzxg+JRb
	iBAw==
Received: by 10.216.228.202 with SMTP id f52mr17062302weq.223.1338990128560;
	Wed, 06 Jun 2012 06:42:08 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-230.sn3.eutelia.it. [213.136.143.230])
	by mx.google.com with ESMTPS id fm1sm2590945wib.10.2012.06.06.06.42.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 06 Jun 2012 06:42:06 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 78af912f1823442009eaff08b7fbf20b7cb1e180
Message-Id: <78af912f1823442009ea.1338990124@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 06 Jun 2012 15:42:04 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6] libxl: introduce LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 avoid recent gcc complaining about:
libxl.c: In function 'libxl_primary_console_exec':
libxl.c:1233:9: error: case value '4294967295' not in enumerated type 'libxl_domain_type' [-Werror=switch]

Also:
 - have all the call sites of libxl__domain_type() return with error in
   case the function returns LIBXL_DOMAIN_TYPE_INVALID;
 - adjust all other code segments where -Wswitch makes would claim that
   LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort();"
   clause.

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

Changes from v5:
 * ERROR_INVAL converted in ERROR_FAIL in libxl_domain_remus_start()
 * Error logging moved in libxl__domain_type()
 * Forgot about libxl_domain_suspend() as requested

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -656,6 +656,11 @@ int libxl_domain_remus_start(libxl_ctx *
     libxl_domain_type type = libxl__domain_type(gc, domid);
     int rc = 0;
 
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto remus_fail;
+    }
+
     if (info == NULL) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                    "No remus_info structure supplied for domain %d", domid);
@@ -1259,8 +1264,7 @@ int libxl_primary_console_exec(libxl_ctx
         case LIBXL_DOMAIN_TYPE_PV:
             rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
             break;
-        case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
+        case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_FAIL;
             break;
         default:
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
@@ -257,6 +257,8 @@ static char ** libxl__build_device_model
         for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
             flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
+    default:
+        abort();
     }
     flexarray_append(dm_args, NULL);
     return (char **) flexarray_contents(dm_args);
@@ -505,6 +507,8 @@ static char ** libxl__build_device_model
         for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
             flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
+    default:
+        abort();
     }
 
     ram_size = libxl__sizekb_to_mb(b_info->max_memkb - b_info->video_memkb);
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
@@ -32,10 +32,11 @@ libxl_domain_type libxl__domain_type(lib
     int ret;
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
-    if (ret != 1)
-        return -1;
-    if (info.domain != domid)
-        return -1;
+    if (ret != 1 || info.domain != domid) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "unable to get domain type for domid=%"PRIu32, domid);
+        return LIBXL_DOMAIN_TYPE_INVALID;
+    }
     if (info.flags & XEN_DOMINF_hvm_guest)
         return LIBXL_DOMAIN_TYPE_HVM;
     else
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
@@ -28,6 +28,7 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB
 #
 
 libxl_domain_type = Enumeration("domain_type", [
+    (-1, "INVALID"),
     (1, "HVM"),
     (2, "PV"),
     ])
@@ -310,6 +311,7 @@ libxl_domain_build_info = Struct("domain
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", libxl_defbool),
                                       ])),
+                 ("invalid", Struct(None, [])),
                  ], keyvar_init_val = "-1")),
     ], dir=DIR_IN
 )

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGaP-00014f-C5; Wed, 06 Jun 2012 13:47:45 +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 1ScGaO-00014N-6d
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:47:44 +0000
Received: from [85.158.143.35:25532] by server-2.bemta-4.messagelabs.com id
	82/3A-17938-F7F5FCF4; Wed, 06 Jun 2012 13:47:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1338990458!7336433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16920 invoked from network); 6 Jun 2012 13:47:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:47:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:46:40 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:46:40 +0100
Date: Wed, 6 Jun 2012 14:46:33 +0100
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: <1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.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] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/dummy.S          |    3 --
>  xen/include/public/arch-arm.h |    9 -----
>  3 files changed, 68 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 9339a11..62a2f3a 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
>      free_xenheap_page(v);
>  }
>  
> +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> +{
> +    return xmalloc(struct vcpu_guest_context);
> +
> +}
> +
> +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> +{
> +    xfree(vgc);
> +}
> +
>  int vcpu_initialise(struct vcpu *v)
>  {
>      int rc = 0;
> @@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    if ( (rc = domain_vgic_init(d)) != 0 )
> +        goto fail;
> +

there is a call to domain_vgic_init already in arch_domain_create


>      if ( !is_idle_domain(d) )
>      {
>          rc = -ENOMEM;
> @@ -212,6 +226,60 @@ void arch_domain_destroy(struct domain *d)
>      /* domain_vgic_destroy */
>  }
>  
> +static int is_guest_psr(uint32_t psr)
> +{
> +    switch (psr & PSR_MODE_MASK)
> +    {
> +    case PSR_MODE_USR:
> +    case PSR_MODE_FIQ:
> +    case PSR_MODE_IRQ:
> +    case PSR_MODE_SVC:
> +    case PSR_MODE_ABT:
> +    case PSR_MODE_UND:
> +    case PSR_MODE_SYS:
> +        return 1;
> +    case PSR_MODE_MON:
> +    case PSR_MODE_HYP:
> +    default:
> +        return 0;
> +    }
> +}
> +
> +int arch_set_info_guest(
> +    struct vcpu *v, vcpu_guest_context_u c)
> +{
> +    struct cpu_user_regs *regs = &c.nat->user_regs;
> +
> +    if ( !is_guest_psr(regs->cpsr) )
> +        return -EINVAL;
> +
> +    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
> +        return -EINVAL;
> +    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
> +        return -EINVAL;
> +    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
> +        return -EINVAL;
> +    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
> +        return -EINVAL;
> +    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
> +        return -EINVAL;
> +
> +    v->arch.cpu_info->guest_cpu_user_regs = *regs;
> +
> +    /* XXX other state:
> +     * - SCTLR
> +     * - TTBR0/1
> +     * - TTBCR
> +     */
> +
> +    //if ( flags & VGCF_online )
> +        clear_bit(_VPF_down, &v->pause_flags);
> +    //else
> +    //    set_bit(_VPF_down, &v->pause_flags);
> +
> +    return 0;
> +}

Do we really need to add commented out code like this?
Also arch_set_info_guest could benefit by a couple of lines of comments
to explain what it is supposed to do.


>  void arch_dump_domain_info(struct domain *d)
>  {
>  }
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 016340c..3b48917 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
>  DUMMY(pirq_set_affinity);
>  
>  /* VCPU */
> -DUMMY(alloc_vcpu_guest_context);
>  DUMMY(arch_get_info_guest);
> -DUMMY(arch_set_info_guest);
>  DUMMY(arch_vcpu_reset);
> -DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
>  DUMMY(vcpu_show_execution_state);
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 1b1bcf3..e439727 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
>  
>  struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> -    union {
> -        uint32_t reg[16];
> -        struct {
> -            uint32_t __pad[12];
> -            uint32_t sp; /* r13 */
> -            uint32_t lr; /* r14 */
> -            uint32_t pc; /* r15 */
> -        };
> -    };
>  };
>  typedef struct vcpu_guest_context vcpu_guest_context_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
> -- 
> 1.7.9.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 Wed Jun 06 13:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGaP-00014f-C5; Wed, 06 Jun 2012 13:47:45 +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 1ScGaO-00014N-6d
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:47:44 +0000
Received: from [85.158.143.35:25532] by server-2.bemta-4.messagelabs.com id
	82/3A-17938-F7F5FCF4; Wed, 06 Jun 2012 13:47:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1338990458!7336433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16920 invoked from network); 6 Jun 2012 13:47:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:47:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:46:40 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:46:40 +0100
Date: Wed, 6 Jun 2012 14:46:33 +0100
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: <1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.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] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/dummy.S          |    3 --
>  xen/include/public/arch-arm.h |    9 -----
>  3 files changed, 68 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 9339a11..62a2f3a 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
>      free_xenheap_page(v);
>  }
>  
> +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> +{
> +    return xmalloc(struct vcpu_guest_context);
> +
> +}
> +
> +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> +{
> +    xfree(vgc);
> +}
> +
>  int vcpu_initialise(struct vcpu *v)
>  {
>      int rc = 0;
> @@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    if ( (rc = domain_vgic_init(d)) != 0 )
> +        goto fail;
> +

there is a call to domain_vgic_init already in arch_domain_create


>      if ( !is_idle_domain(d) )
>      {
>          rc = -ENOMEM;
> @@ -212,6 +226,60 @@ void arch_domain_destroy(struct domain *d)
>      /* domain_vgic_destroy */
>  }
>  
> +static int is_guest_psr(uint32_t psr)
> +{
> +    switch (psr & PSR_MODE_MASK)
> +    {
> +    case PSR_MODE_USR:
> +    case PSR_MODE_FIQ:
> +    case PSR_MODE_IRQ:
> +    case PSR_MODE_SVC:
> +    case PSR_MODE_ABT:
> +    case PSR_MODE_UND:
> +    case PSR_MODE_SYS:
> +        return 1;
> +    case PSR_MODE_MON:
> +    case PSR_MODE_HYP:
> +    default:
> +        return 0;
> +    }
> +}
> +
> +int arch_set_info_guest(
> +    struct vcpu *v, vcpu_guest_context_u c)
> +{
> +    struct cpu_user_regs *regs = &c.nat->user_regs;
> +
> +    if ( !is_guest_psr(regs->cpsr) )
> +        return -EINVAL;
> +
> +    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
> +        return -EINVAL;
> +    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
> +        return -EINVAL;
> +    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
> +        return -EINVAL;
> +    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
> +        return -EINVAL;
> +    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
> +        return -EINVAL;
> +
> +    v->arch.cpu_info->guest_cpu_user_regs = *regs;
> +
> +    /* XXX other state:
> +     * - SCTLR
> +     * - TTBR0/1
> +     * - TTBCR
> +     */
> +
> +    //if ( flags & VGCF_online )
> +        clear_bit(_VPF_down, &v->pause_flags);
> +    //else
> +    //    set_bit(_VPF_down, &v->pause_flags);
> +
> +    return 0;
> +}

Do we really need to add commented out code like this?
Also arch_set_info_guest could benefit by a couple of lines of comments
to explain what it is supposed to do.


>  void arch_dump_domain_info(struct domain *d)
>  {
>  }
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 016340c..3b48917 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
>  DUMMY(pirq_set_affinity);
>  
>  /* VCPU */
> -DUMMY(alloc_vcpu_guest_context);
>  DUMMY(arch_get_info_guest);
> -DUMMY(arch_set_info_guest);
>  DUMMY(arch_vcpu_reset);
> -DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
>  DUMMY(vcpu_show_execution_state);
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 1b1bcf3..e439727 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
>  
>  struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> -    union {
> -        uint32_t reg[16];
> -        struct {
> -            uint32_t __pad[12];
> -            uint32_t sp; /* r13 */
> -            uint32_t lr; /* r14 */
> -            uint32_t pc; /* r15 */
> -        };
> -    };
>  };
>  typedef struct vcpu_guest_context vcpu_guest_context_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
> -- 
> 1.7.9.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 Wed Jun 06 13:48:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:48: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 1ScGaS-00015I-O7; Wed, 06 Jun 2012 13:47: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 1ScGaR-00014H-0X
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:47:47 +0000
Received: from [85.158.143.35:63381] by server-3.bemta-4.messagelabs.com id
	68/AD-29237-28F5FCF4; Wed, 06 Jun 2012 13:47:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338990466!14298542!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6651 invoked from network); 6 Jun 2012 13:47:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:47:32 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:47:32 +0100
Date: Wed, 6 Jun 2012 14:47:26 +0100
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: <1338565207-2888-10-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061447180.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-10-git-send-email-ian.campbell@citrix.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] [PATCH 10/38] arm: remove unnecessarily verbose
 print from p2m_load_VTTBR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/p2m.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index fdbecbc..095e608 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -47,8 +47,6 @@ void p2m_load_VTTBR(struct domain *d)
>  
>      vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
>  
> -    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
> -
>      WRITE_CP64(vttbr, VTTBR);
>      isb(); /* Ensure update is visible */
>  }
> -- 
> 1.7.9.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 Wed Jun 06 13:48:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:48: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 1ScGaS-00015I-O7; Wed, 06 Jun 2012 13:47: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 1ScGaR-00014H-0X
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:47:47 +0000
Received: from [85.158.143.35:63381] by server-3.bemta-4.messagelabs.com id
	68/AD-29237-28F5FCF4; Wed, 06 Jun 2012 13:47:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338990466!14298542!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6651 invoked from network); 6 Jun 2012 13:47:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:47:32 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:47:32 +0100
Date: Wed, 6 Jun 2012 14:47:26 +0100
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: <1338565207-2888-10-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061447180.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-10-git-send-email-ian.campbell@citrix.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] [PATCH 10/38] arm: remove unnecessarily verbose
 print from p2m_load_VTTBR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/p2m.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index fdbecbc..095e608 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -47,8 +47,6 @@ void p2m_load_VTTBR(struct domain *d)
>  
>      vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
>  
> -    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
> -
>      WRITE_CP64(vttbr, VTTBR);
>      isb(); /* Ensure update is visible */
>  }
> -- 
> 1.7.9.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 Wed Jun 06 13:48:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGaN-00014P-Vm; Wed, 06 Jun 2012 13:47: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 1ScGaM-00014H-AJ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:47:42 +0000
Received: from [85.158.143.35:25396] by server-3.bemta-4.messagelabs.com id
	FF/7D-29237-D7F5FCF4; Wed, 06 Jun 2012 13:47:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1338990460!4613255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28954 invoked from network); 6 Jun 2012 13:47:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:47:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:47:11 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:47:11 +0100
Date: Wed, 6 Jun 2012 14:47:05 +0100
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: <1338565207-2888-9-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061446590.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-9-git-send-email-ian.campbell@citrix.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] [PATCH 09/38] arm: print domid as part of debug trap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  xen/arch/arm/traps.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5d8b7f9..40bb375 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -388,25 +388,26 @@ static arm_hypercall_t *arm_hypercall_table[] = {
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  {
>      uint32_t reg, *r;
> -
> +    uint32_t domid = current->domain->domain_id;
>      switch ( code ) {
>      case 0xe0 ... 0xef:
>          reg = code - 0xe0;
>          r = &regs->r0 + reg;
> -        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
> +        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> +               domid, reg, *r, regs->pc);
>          break;
>      case 0xfd:
> -        printk("Reached %08"PRIx32"\n", regs->pc);
> +        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
>          break;
>      case 0xfe:
>          printk("%c", (char)(regs->r0 & 0xff));
>          break;
>      case 0xff:
> -        printk("DEBUG\n");
> +        printk("DOM%d: DEBUG\n", domid);
>          show_execution_state(regs);
>          break;
>      default:
> -        panic("Unhandled debug trap %#x\n", code);
> +        panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
>          break;
>      }
>  }
> -- 
> 1.7.9.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 Wed Jun 06 13:48:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGaN-00014P-Vm; Wed, 06 Jun 2012 13:47: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 1ScGaM-00014H-AJ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:47:42 +0000
Received: from [85.158.143.35:25396] by server-3.bemta-4.messagelabs.com id
	FF/7D-29237-D7F5FCF4; Wed, 06 Jun 2012 13:47:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1338990460!4613255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28954 invoked from network); 6 Jun 2012 13:47:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:47:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:47:11 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:47:11 +0100
Date: Wed, 6 Jun 2012 14:47:05 +0100
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: <1338565207-2888-9-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061446590.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-9-git-send-email-ian.campbell@citrix.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] [PATCH 09/38] arm: print domid as part of debug trap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  xen/arch/arm/traps.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5d8b7f9..40bb375 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -388,25 +388,26 @@ static arm_hypercall_t *arm_hypercall_table[] = {
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  {
>      uint32_t reg, *r;
> -
> +    uint32_t domid = current->domain->domain_id;
>      switch ( code ) {
>      case 0xe0 ... 0xef:
>          reg = code - 0xe0;
>          r = &regs->r0 + reg;
> -        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
> +        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> +               domid, reg, *r, regs->pc);
>          break;
>      case 0xfd:
> -        printk("Reached %08"PRIx32"\n", regs->pc);
> +        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
>          break;
>      case 0xfe:
>          printk("%c", (char)(regs->r0 & 0xff));
>          break;
>      case 0xff:
> -        printk("DEBUG\n");
> +        printk("DOM%d: DEBUG\n", domid);
>          show_execution_state(regs);
>          break;
>      default:
> -        panic("Unhandled debug trap %#x\n", code);
> +        panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
>          break;
>      }
>  }
> -- 
> 1.7.9.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 Wed Jun 06 13:56:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGhu-0001UN-O2; Wed, 06 Jun 2012 13:55: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 1ScGht-0001UI-AD
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:55:29 +0000
Received: from [85.158.143.99:10417] by server-1.bemta-4.messagelabs.com id
	0F/7E-10042-0516FCF4; Wed, 06 Jun 2012 13:55:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1338990927!26305160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5681 invoked from network); 6 Jun 2012 13:55:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:55:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:55:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:55:26 +0100
Message-ID: <1338990925.32319.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 14:55:25 +0100
In-Reply-To: <alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:46 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
> >  xen/arch/arm/dummy.S          |    3 --
> >  xen/include/public/arch-arm.h |    9 -----
> >  3 files changed, 68 insertions(+), 12 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 9339a11..62a2f3a 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
> >      free_xenheap_page(v);
> >  }
> >  
> > +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> > +{
> > +    return xmalloc(struct vcpu_guest_context);
> > +
> > +}
> > +
> > +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> > +{
> > +    xfree(vgc);
> > +}
> > +
> >  int vcpu_initialise(struct vcpu *v)
> >  {
> >      int rc = 0;
> > @@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >      if ( (rc = p2m_init(d)) != 0 )
> >          goto fail;
> >  
> > +    if ( (rc = domain_vgic_init(d)) != 0 )
> > +        goto fail;
> > +
> 
> there is a call to domain_vgic_init already in arch_domain_create

So there is!

I notice while checking that a bunch of stuff can/should be pushed under
the !idle_domain conditional, or better the idle domain case should bail
early.

> > +int arch_set_info_guest(
> > +    struct vcpu *v, vcpu_guest_context_u c)
> > +{
> > +    struct cpu_user_regs *regs = &c.nat->user_regs;
> > +
> > +    if ( !is_guest_psr(regs->cpsr) )
> > +        return -EINVAL;
> > +
> > +    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
> > +        return -EINVAL;
> > +
> > +    v->arch.cpu_info->guest_cpu_user_regs = *regs;
> > +
> > +    /* XXX other state:
> > +     * - SCTLR
> > +     * - TTBR0/1
> > +     * - TTBCR
> > +     */
> > +
> > +    //if ( flags & VGCF_online )
> > +        clear_bit(_VPF_down, &v->pause_flags);
> > +    //else
> > +    //    set_bit(_VPF_down, &v->pause_flags);
> > +
> > +    return 0;
> > +}
> 
> Do we really need to add commented out code like this?

Yeah, you're right, I copied from x86 which has this but we haven't
implemented it for ARM yet. I suppose an XXX would be better. Or maybe I
should just implement the flags...

> Also arch_set_info_guest could benefit by a couple of lines of comments
> to explain what it is supposed to do.

I'll add something.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:56:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGhu-0001UN-O2; Wed, 06 Jun 2012 13:55: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 1ScGht-0001UI-AD
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:55:29 +0000
Received: from [85.158.143.99:10417] by server-1.bemta-4.messagelabs.com id
	0F/7E-10042-0516FCF4; Wed, 06 Jun 2012 13:55:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1338990927!26305160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5681 invoked from network); 6 Jun 2012 13:55:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:55:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:55:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:55:26 +0100
Message-ID: <1338990925.32319.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 14:55:25 +0100
In-Reply-To: <alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:46 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
> >  xen/arch/arm/dummy.S          |    3 --
> >  xen/include/public/arch-arm.h |    9 -----
> >  3 files changed, 68 insertions(+), 12 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 9339a11..62a2f3a 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
> >      free_xenheap_page(v);
> >  }
> >  
> > +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> > +{
> > +    return xmalloc(struct vcpu_guest_context);
> > +
> > +}
> > +
> > +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> > +{
> > +    xfree(vgc);
> > +}
> > +
> >  int vcpu_initialise(struct vcpu *v)
> >  {
> >      int rc = 0;
> > @@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >      if ( (rc = p2m_init(d)) != 0 )
> >          goto fail;
> >  
> > +    if ( (rc = domain_vgic_init(d)) != 0 )
> > +        goto fail;
> > +
> 
> there is a call to domain_vgic_init already in arch_domain_create

So there is!

I notice while checking that a bunch of stuff can/should be pushed under
the !idle_domain conditional, or better the idle domain case should bail
early.

> > +int arch_set_info_guest(
> > +    struct vcpu *v, vcpu_guest_context_u c)
> > +{
> > +    struct cpu_user_regs *regs = &c.nat->user_regs;
> > +
> > +    if ( !is_guest_psr(regs->cpsr) )
> > +        return -EINVAL;
> > +
> > +    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
> > +        return -EINVAL;
> > +    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
> > +        return -EINVAL;
> > +
> > +    v->arch.cpu_info->guest_cpu_user_regs = *regs;
> > +
> > +    /* XXX other state:
> > +     * - SCTLR
> > +     * - TTBR0/1
> > +     * - TTBCR
> > +     */
> > +
> > +    //if ( flags & VGCF_online )
> > +        clear_bit(_VPF_down, &v->pause_flags);
> > +    //else
> > +    //    set_bit(_VPF_down, &v->pause_flags);
> > +
> > +    return 0;
> > +}
> 
> Do we really need to add commented out code like this?

Yeah, you're right, I copied from x86 which has this but we haven't
implemented it for ARM yet. I suppose an XXX would be better. Or maybe I
should just implement the flags...

> Also arch_set_info_guest could benefit by a couple of lines of comments
> to explain what it is supposed to do.

I'll add something.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGl0-0001aN-At; Wed, 06 Jun 2012 13:58:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScGkz-0001aG-NX
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:58:41 +0000
Received: from [193.109.254.147:41154] by server-11.bemta-14.messagelabs.com
	id 94/7A-02727-0126FCF4; Wed, 06 Jun 2012 13:58:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338991112!5393464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5000 invoked from network); 6 Jun 2012 13:58:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:58:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:58:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScGkq-0000sz-0R; Wed, 06 Jun 2012 13:58:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScGkq-0006Hs-07;
	Wed, 06 Jun 2012 14:58:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.25095.988128.781065@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 14:58:31 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
References: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: remove libxl__error_set prototype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: remove libxl__error_set prototype"):
> libxl: remove libxl__error_set prototype
> 
> The implementation went away in 25181:26f72d923cb9 "libxl: Crash (more
> sensibly) on malloc failure".

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGl0-0001aN-At; Wed, 06 Jun 2012 13:58:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScGkz-0001aG-NX
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:58:41 +0000
Received: from [193.109.254.147:41154] by server-11.bemta-14.messagelabs.com
	id 94/7A-02727-0126FCF4; Wed, 06 Jun 2012 13:58:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1338991112!5393464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5000 invoked from network); 6 Jun 2012 13:58:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:58:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:58:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScGkq-0000sz-0R; Wed, 06 Jun 2012 13:58:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScGkq-0006Hs-07;
	Wed, 06 Jun 2012 14:58:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.25095.988128.781065@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 14:58:31 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
References: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: remove libxl__error_set prototype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: remove libxl__error_set prototype"):
> libxl: remove libxl__error_set prototype
> 
> The implementation went away in 25181:26f72d923cb9 "libxl: Crash (more
> sensibly) on malloc failure".

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGl3-0001ai-Mn; Wed, 06 Jun 2012 13:58: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 1ScGl2-0001aY-A5
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:58:44 +0000
Received: from [85.158.138.51:46345] by server-7.bemta-3.messagelabs.com id
	D8/BB-01983-3126FCF4; Wed, 06 Jun 2012 13:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338991122!31104798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24118 invoked from network); 6 Jun 2012 13:58:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:58:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:58:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:58:42 +0100
Message-ID: <1338991121.32319.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 14:58:41 +0100
In-Reply-To: <78af912f1823442009ea.1338990124@Solace>
References: <78af912f1823442009ea.1338990124@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> To avoid recent gcc complaining about:
> libxl.c: In function 'libxl_primary_console_exec':
> libxl.c:1233:9: error: case value '4294967295' not in enumerated type 'libxl_domain_type' [-Werror=switch]
> 
> Also:
>  - have all the call sites of libxl__domain_type() return with error in
>    case the function returns LIBXL_DOMAIN_TYPE_INVALID;
>  - adjust all other code segments where -Wswitch makes would claim that
>    LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort();"
>    clause.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

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

> @@ -310,6 +311,7 @@ libxl_domain_build_info = Struct("domain
>                                        # Use host's E820 for PCI passthrough.
>                                        ("e820_host", libxl_defbool),
>                                        ])),
> +                 ("invalid", Struct(None, [])),
>                   ], keyvar_init_val = "-1")),

This -1 should => LIBXL_DOMAIN_TYPE_INVALID, but I'll just make that
change as I commit it, if that's ok with you...

>      ], dir=DIR_IN
>  )



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13: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 1ScGl3-0001ai-Mn; Wed, 06 Jun 2012 13:58: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 1ScGl2-0001aY-A5
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:58:44 +0000
Received: from [85.158.138.51:46345] by server-7.bemta-3.messagelabs.com id
	D8/BB-01983-3126FCF4; Wed, 06 Jun 2012 13:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1338991122!31104798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24118 invoked from network); 6 Jun 2012 13:58:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:58:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:58:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	14:58:42 +0100
Message-ID: <1338991121.32319.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 14:58:41 +0100
In-Reply-To: <78af912f1823442009ea.1338990124@Solace>
References: <78af912f1823442009ea.1338990124@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> To avoid recent gcc complaining about:
> libxl.c: In function 'libxl_primary_console_exec':
> libxl.c:1233:9: error: case value '4294967295' not in enumerated type 'libxl_domain_type' [-Werror=switch]
> 
> Also:
>  - have all the call sites of libxl__domain_type() return with error in
>    case the function returns LIBXL_DOMAIN_TYPE_INVALID;
>  - adjust all other code segments where -Wswitch makes would claim that
>    LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort();"
>    clause.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

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

> @@ -310,6 +311,7 @@ libxl_domain_build_info = Struct("domain
>                                        # Use host's E820 for PCI passthrough.
>                                        ("e820_host", libxl_defbool),
>                                        ])),
> +                 ("invalid", Struct(None, [])),
>                   ], keyvar_init_val = "-1")),

This -1 should => LIBXL_DOMAIN_TYPE_INVALID, but I'll just make that
change as I commit it, if that's ok with you...

>      ], dir=DIR_IN
>  )



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGlr-0001hW-LS; Wed, 06 Jun 2012 13:59:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScGlq-0001g2-Ek
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:59:34 +0000
Received: from [85.158.143.35:51495] by server-2.bemta-4.messagelabs.com id
	C5/2D-17938-6426FCF4; Wed, 06 Jun 2012 13:59:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338991138!13804352!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31635 invoked from network); 6 Jun 2012 13:59:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:59:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860547"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:59:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:59:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScGlV-0000tH-S3; Wed, 06 Jun 2012 13:59:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScGlV-0006I8-Rv;
	Wed, 06 Jun 2012 14:59:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.25137.851561.2815@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 14:59:13 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
References: <beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a
	bzImage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] libxc: do not "panic" if a kernel is not a bzImage"):
> libxc: do not "panic" if a kernel is not a bzImage.
> 
> Up until the point where we think this is a bzImage there is no point in
> printing panicy messages -- some other loader will have a go (probably the
> compressed ELF one)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScGlr-0001hW-LS; Wed, 06 Jun 2012 13:59:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScGlq-0001g2-Ek
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:59:34 +0000
Received: from [85.158.143.35:51495] by server-2.bemta-4.messagelabs.com id
	C5/2D-17938-6426FCF4; Wed, 06 Jun 2012 13:59:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338991138!13804352!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31635 invoked from network); 6 Jun 2012 13:59:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:59:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860547"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:59:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:59:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScGlV-0000tH-S3; Wed, 06 Jun 2012 13:59:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScGlV-0006I8-Rv;
	Wed, 06 Jun 2012 14:59:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.25137.851561.2815@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 14:59:13 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
References: <beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a
	bzImage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] libxc: do not "panic" if a kernel is not a bzImage"):
> libxc: do not "panic" if a kernel is not a bzImage.
> 
> Up until the point where we think this is a bzImage there is no point in
> printing panicy messages -- some other loader will have a go (probably the
> compressed ELF one)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:59: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 1ScGlo-0001gO-4e; Wed, 06 Jun 2012 13:59:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScGlm-0001g2-72
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:59:30 +0000
Received: from [85.158.143.35:36850] by server-2.bemta-4.messagelabs.com id
	45/0D-17938-1426FCF4; Wed, 06 Jun 2012 13:59:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338991138!13804352!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31333 invoked from network); 6 Jun 2012 13:59:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:59:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:58:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:58:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScGlG-0000t9-3t; Wed, 06 Jun 2012 13:58:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScGlG-0006I1-3i;
	Wed, 06 Jun 2012 14:58:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.25122.99704.458764@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 14:58:58 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
References: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: do not run a hotplug script from qemu
	on 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

Ian Campbell writes ("[PATCH] xend: do not run a hotplug script from qemu on Linux"):
> xend: do not run a hotplug script from qemu on Linux
> 
> The current vif-hotplug-common.sh for renaming the tap device is failing
> because it is racing with this script and therefore the device is unexpectedly
> up when we come to rename it.
> 
> Fix this in the same way as libxl does, by disabling the script (only on
> Linux).

Sounds plausible.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 13:59:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 13:59: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 1ScGlo-0001gO-4e; Wed, 06 Jun 2012 13:59:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScGlm-0001g2-72
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 13:59:30 +0000
Received: from [85.158.143.35:36850] by server-2.bemta-4.messagelabs.com id
	45/0D-17938-1426FCF4; Wed, 06 Jun 2012 13:59:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338991138!13804352!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31333 invoked from network); 6 Jun 2012 13:59:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 13:59:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 13:58:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 14:58:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScGlG-0000t9-3t; Wed, 06 Jun 2012 13:58:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScGlG-0006I1-3i;
	Wed, 06 Jun 2012 14:58:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20431.25122.99704.458764@mariner.uk.xensource.com>
Date: Wed, 6 Jun 2012 14:58:58 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
References: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: do not run a hotplug script from qemu
	on 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

Ian Campbell writes ("[PATCH] xend: do not run a hotplug script from qemu on Linux"):
> xend: do not run a hotplug script from qemu on Linux
> 
> The current vif-hotplug-common.sh for renaming the tap device is failing
> because it is racing with this script and therefore the device is unexpectedly
> up when we come to rename it.
> 
> Fix this in the same way as libxl does, by disabling the script (only on
> Linux).

Sounds plausible.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 14:02:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScGod-0002AD-CW; Wed, 06 Jun 2012 14:02:27 +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 1ScGoc-00029v-10
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:02:26 +0000
Received: from [85.158.138.51:19110] by server-1.bemta-3.messagelabs.com id
	E3/D2-01327-1F26FCF4; Wed, 06 Jun 2012 14:02:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338991344!31156714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28044 invoked from network); 6 Jun 2012 14:02:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:01:37 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 15:01:37 +0100
Date: Wed, 6 Jun 2012 15:01:31 +0100
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: <1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.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] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/p2m.c        |   71 ++++++++++++++++++++++++++++++++++++++++++--
>  xen/include/asm-arm/p2m.h |    3 ++
>  2 files changed, 70 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 095e608..9b40e93 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -10,10 +10,20 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>      struct p2m_domain *p2m = &d->arch.p2m;
>      lpae_t *first = NULL, *second = NULL, *third = NULL;
>  
> -    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> +    printk("dom%d IPA %#"PRIpaddr"\n", d->domain_id, addr);
> +
> +    printk("P2M @ %p mfn:%#lx (%#03llx,%#03llx,%#03llx)\n",
> +           p2m->first_level,
> +           page_to_mfn(p2m->first_level),
> +           first_table_offset(addr),
> +           second_table_offset(addr),
> +           third_table_offset(addr));
> +
> +    if ( first_table_offset(addr) >= LPAE_ENTRIES )
> +        goto done;
>  
>      first = __map_domain_page(p2m->first_level);
> -    printk("1ST[%#03llx] = %#016llx\n",
> +    printk("1ST[%#03llx] = %#"PRIpaddr"\n",
>             first_table_offset(addr),
>             first[first_table_offset(addr)].bits);
>      if ( !first[first_table_offset(addr)].p2m.valid ||
> @@ -21,7 +31,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>          goto done;
>  
>      second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> -    printk("2ND[%#03llx] = %#016llx\n",
> +    printk("2ND[%#03llx] = %#"PRIpaddr"\n",
>             second_table_offset(addr),
>             second[second_table_offset(addr)].bits);
>      if ( !second[second_table_offset(addr)].p2m.valid ||
> @@ -29,7 +39,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>          goto done;
>  
>      third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> -    printk("3RD[%#03llx] = %#016llx\n",
> +    printk("3RD[%#03llx] = %#"PRIpaddr"\n",
>             third_table_offset(addr),
>             third[third_table_offset(addr)].bits);
>  
> @@ -51,6 +61,59 @@ void p2m_load_VTTBR(struct domain *d)
>      isb(); /* Ensure update is visible */
>  }

there is no need to introduce p2m_lookup in the same patch you do these
unrelated printk adjustments, correct?


> +/*
> + * Lookup the MFN corresponding to a domain's PFN.
> + *
> + * There are no processor functions to do a stage 2 only lookup therefore we
> + * do a a software walk.
> + */
> +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> +    paddr_t maddr = INVALID_PADDR;
> +
> +    spin_lock(&p2m->lock);
> +
> +    first = __map_domain_page(p2m->first_level);
> +    if ( !first[first_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !first[first_table_offset(paddr)].p2m.table )
> +    {
> +        pte = first[first_table_offset(paddr)];
> +        goto done;
> +    }
> +
> +    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
> +    if ( !second[second_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !second[second_table_offset(paddr)].p2m.table )
> +    {
> +        pte = second[second_table_offset(paddr)];
> +        goto done;
> +    }
> +
> +    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
> +    if ( !third[third_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !third[third_table_offset(paddr)].p2m.table )
> +        goto done_err;
> +
> +    pte = third[third_table_offset(paddr)];
> +
> +done:
> +
> +    maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
> +done_err:
> +    if (third) unmap_domain_page(third);
> +    if (second) unmap_domain_page(second);
> +    if (first) unmap_domain_page(first);
> +
> +    spin_unlock(&p2m->lock);
> +
> +    return maddr;
> +}
> +

this function looks correct though

>  int guest_physmap_mark_populate_on_demand(struct domain *d,
>                                            unsigned long gfn,
>                                            unsigned int order)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 349923a..1afd5cb 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
>  /* */
>  void p2m_load_VTTBR(struct domain *d);
>  
> +/* */
> +paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
> +
>  /* Setup p2m RAM mapping for domain d from start-end. */
>  int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>  /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
> -- 
> 1.7.9.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 Wed Jun 06 14:02:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScGod-0002AD-CW; Wed, 06 Jun 2012 14:02:27 +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 1ScGoc-00029v-10
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:02:26 +0000
Received: from [85.158.138.51:19110] by server-1.bemta-3.messagelabs.com id
	E3/D2-01327-1F26FCF4; Wed, 06 Jun 2012 14:02:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338991344!31156714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28044 invoked from network); 6 Jun 2012 14:02:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12860619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:01:37 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 15:01:37 +0100
Date: Wed, 6 Jun 2012 15:01:31 +0100
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: <1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.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] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/p2m.c        |   71 ++++++++++++++++++++++++++++++++++++++++++--
>  xen/include/asm-arm/p2m.h |    3 ++
>  2 files changed, 70 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 095e608..9b40e93 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -10,10 +10,20 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>      struct p2m_domain *p2m = &d->arch.p2m;
>      lpae_t *first = NULL, *second = NULL, *third = NULL;
>  
> -    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> +    printk("dom%d IPA %#"PRIpaddr"\n", d->domain_id, addr);
> +
> +    printk("P2M @ %p mfn:%#lx (%#03llx,%#03llx,%#03llx)\n",
> +           p2m->first_level,
> +           page_to_mfn(p2m->first_level),
> +           first_table_offset(addr),
> +           second_table_offset(addr),
> +           third_table_offset(addr));
> +
> +    if ( first_table_offset(addr) >= LPAE_ENTRIES )
> +        goto done;
>  
>      first = __map_domain_page(p2m->first_level);
> -    printk("1ST[%#03llx] = %#016llx\n",
> +    printk("1ST[%#03llx] = %#"PRIpaddr"\n",
>             first_table_offset(addr),
>             first[first_table_offset(addr)].bits);
>      if ( !first[first_table_offset(addr)].p2m.valid ||
> @@ -21,7 +31,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>          goto done;
>  
>      second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> -    printk("2ND[%#03llx] = %#016llx\n",
> +    printk("2ND[%#03llx] = %#"PRIpaddr"\n",
>             second_table_offset(addr),
>             second[second_table_offset(addr)].bits);
>      if ( !second[second_table_offset(addr)].p2m.valid ||
> @@ -29,7 +39,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>          goto done;
>  
>      third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> -    printk("3RD[%#03llx] = %#016llx\n",
> +    printk("3RD[%#03llx] = %#"PRIpaddr"\n",
>             third_table_offset(addr),
>             third[third_table_offset(addr)].bits);
>  
> @@ -51,6 +61,59 @@ void p2m_load_VTTBR(struct domain *d)
>      isb(); /* Ensure update is visible */
>  }

there is no need to introduce p2m_lookup in the same patch you do these
unrelated printk adjustments, correct?


> +/*
> + * Lookup the MFN corresponding to a domain's PFN.
> + *
> + * There are no processor functions to do a stage 2 only lookup therefore we
> + * do a a software walk.
> + */
> +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> +    paddr_t maddr = INVALID_PADDR;
> +
> +    spin_lock(&p2m->lock);
> +
> +    first = __map_domain_page(p2m->first_level);
> +    if ( !first[first_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !first[first_table_offset(paddr)].p2m.table )
> +    {
> +        pte = first[first_table_offset(paddr)];
> +        goto done;
> +    }
> +
> +    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
> +    if ( !second[second_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !second[second_table_offset(paddr)].p2m.table )
> +    {
> +        pte = second[second_table_offset(paddr)];
> +        goto done;
> +    }
> +
> +    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
> +    if ( !third[third_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !third[third_table_offset(paddr)].p2m.table )
> +        goto done_err;
> +
> +    pte = third[third_table_offset(paddr)];
> +
> +done:
> +
> +    maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
> +done_err:
> +    if (third) unmap_domain_page(third);
> +    if (second) unmap_domain_page(second);
> +    if (first) unmap_domain_page(first);
> +
> +    spin_unlock(&p2m->lock);
> +
> +    return maddr;
> +}
> +

this function looks correct though

>  int guest_physmap_mark_populate_on_demand(struct domain *d,
>                                            unsigned long gfn,
>                                            unsigned int order)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 349923a..1afd5cb 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
>  /* */
>  void p2m_load_VTTBR(struct domain *d);
>  
> +/* */
> +paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
> +
>  /* Setup p2m RAM mapping for domain d from start-end. */
>  int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>  /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
> -- 
> 1.7.9.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 Wed Jun 06 14:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScH9z-0002st-VP; Wed, 06 Jun 2012 14:24:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScH9y-0002sn-KD
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:24:30 +0000
Received: from [85.158.143.35:17747] by server-2.bemta-4.messagelabs.com id
	F0/59-17938-D186FCF4; Wed, 06 Jun 2012 14:24:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338992669!13809460!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9026 invoked from network); 6 Jun 2012 14:24:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	6 Jun 2012 14:24:29 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78695966; Wed, 06 Jun 2012 16:23:43 +0200
Message-ID: <1338992609.8123.3.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 16:23:29 +0200
In-Reply-To: <1338979740.32319.50.camel@zakaz.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
	<1338979740.32319.50.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7808210876836164416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7808210876836164416==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4/MfupYjUx3xY+gst3SZ"


--=-4/MfupYjUx3xY+gst3SZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 11:49 +0100, Ian Campbell wrote:
> Because libxl just carries on (in libxl__build_post) and doesn't
> propagate the error... It most likely shouldn't. I think we can change
> that separately though?
>=20
Taking care of this right now... it seems, next version of this patch
will be a series of two patches. :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-4/MfupYjUx3xY+gst3SZ
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)

iEUEABECAAYFAk/PZ+EACgkQk4XaBE3IOsQeWwCgkHOGABRCIPVL7qExvevA1rpm
vPsAlA0zOeruremkoj4ZK+ry3nRWnz4=
=0w3K
-----END PGP SIGNATURE-----

--=-4/MfupYjUx3xY+gst3SZ--



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

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

--===============7808210876836164416==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 14:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScH9z-0002st-VP; Wed, 06 Jun 2012 14:24:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScH9y-0002sn-KD
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:24:30 +0000
Received: from [85.158.143.35:17747] by server-2.bemta-4.messagelabs.com id
	F0/59-17938-D186FCF4; Wed, 06 Jun 2012 14:24:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1338992669!13809460!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9026 invoked from network); 6 Jun 2012 14:24:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	6 Jun 2012 14:24:29 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78695966; Wed, 06 Jun 2012 16:23:43 +0200
Message-ID: <1338992609.8123.3.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 16:23:29 +0200
In-Reply-To: <1338979740.32319.50.camel@zakaz.uk.xensource.com>
References: <3eadab19abd49fbc6f56.1338818483@Solace>
	<20431.13287.208744.519066@mariner.uk.xensource.com>
	<1338979740.32319.50.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: check for meaningful combination of
 sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7808210876836164416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7808210876836164416==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4/MfupYjUx3xY+gst3SZ"


--=-4/MfupYjUx3xY+gst3SZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 11:49 +0100, Ian Campbell wrote:
> Because libxl just carries on (in libxl__build_post) and doesn't
> propagate the error... It most likely shouldn't. I think we can change
> that separately though?
>=20
Taking care of this right now... it seems, next version of this patch
will be a series of two patches. :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-4/MfupYjUx3xY+gst3SZ
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)

iEUEABECAAYFAk/PZ+EACgkQk4XaBE3IOsQeWwCgkHOGABRCIPVL7qExvevA1rpm
vPsAlA0zOeruremkoj4ZK+ry3nRWnz4=
=0w3K
-----END PGP SIGNATURE-----

--=-4/MfupYjUx3xY+gst3SZ--



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

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

--===============7808210876836164416==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 14:30:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScHFx-00036A-S5; Wed, 06 Jun 2012 14:30:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScHFw-000365-SQ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:30:41 +0000
Received: from [85.158.139.83:63547] by server-10.bemta-5.messagelabs.com id
	83/65-23803-0996FCF4; Wed, 06 Jun 2012 14:30:40 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1338993039!32600169!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31932 invoked from network); 6 Jun 2012 14:30:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-182.messagelabs.com with SMTP;
	6 Jun 2012 14:30:39 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78696184; Wed, 06 Jun 2012 16:30:38 +0200
Message-ID: <1338993032.8123.4.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 16:30:32 +0200
In-Reply-To: <1338991121.32319.105.camel@zakaz.uk.xensource.com>
References: <78af912f1823442009ea.1338990124@Solace>
	<1338991121.32319.105.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5340787520306966530=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5340787520306966530==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Hj/63BIxDs5j/HUaAuA/"


--=-Hj/63BIxDs5j/HUaAuA/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 14:58 +0100, Ian Campbell wrote:
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>=20
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
Cool! :-)

> > @@ -310,6 +311,7 @@ libxl_domain_build_info =3D Struct("domain
> >                                        # Use host's E820 for PCI passth=
rough.
> >                                        ("e820_host", libxl_defbool),
> >                                        ])),
> > +                 ("invalid", Struct(None, [])),
> >                   ], keyvar_init_val =3D "-1")),
>=20
> This -1 should =3D> LIBXL_DOMAIN_TYPE_INVALID,=20
>
Oh, you're right, I just wasn't sure I could put i here... And then I
forgot to try! :-P

> but I'll just make that
> change as I commit it, if that's ok with you...
>=20
It is, thanks.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Hj/63BIxDs5j/HUaAuA/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/PaYgACgkQk4XaBE3IOsSVHQCgojjBUBr3wjE7sR/B6xl6Ti9h
bT4AnA5eybuxlslL7Thz1qtjBH0xS/Fy
=JRSR
-----END PGP SIGNATURE-----

--=-Hj/63BIxDs5j/HUaAuA/--



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

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

--===============5340787520306966530==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 14:30:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScHFx-00036A-S5; Wed, 06 Jun 2012 14:30:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScHFw-000365-SQ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:30:41 +0000
Received: from [85.158.139.83:63547] by server-10.bemta-5.messagelabs.com id
	83/65-23803-0996FCF4; Wed, 06 Jun 2012 14:30:40 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1338993039!32600169!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31932 invoked from network); 6 Jun 2012 14:30:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-182.messagelabs.com with SMTP;
	6 Jun 2012 14:30:39 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78696184; Wed, 06 Jun 2012 16:30:38 +0200
Message-ID: <1338993032.8123.4.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 06 Jun 2012 16:30:32 +0200
In-Reply-To: <1338991121.32319.105.camel@zakaz.uk.xensource.com>
References: <78af912f1823442009ea.1338990124@Solace>
	<1338991121.32319.105.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5340787520306966530=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5340787520306966530==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Hj/63BIxDs5j/HUaAuA/"


--=-Hj/63BIxDs5j/HUaAuA/
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 14:58 +0100, Ian Campbell wrote:
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>=20
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
Cool! :-)

> > @@ -310,6 +311,7 @@ libxl_domain_build_info =3D Struct("domain
> >                                        # Use host's E820 for PCI passth=
rough.
> >                                        ("e820_host", libxl_defbool),
> >                                        ])),
> > +                 ("invalid", Struct(None, [])),
> >                   ], keyvar_init_val =3D "-1")),
>=20
> This -1 should =3D> LIBXL_DOMAIN_TYPE_INVALID,=20
>
Oh, you're right, I just wasn't sure I could put i here... And then I
forgot to try! :-P

> but I'll just make that
> change as I commit it, if that's ok with you...
>=20
It is, thanks.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Hj/63BIxDs5j/HUaAuA/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/PaYgACgkQk4XaBE3IOsSVHQCgojjBUBr3wjE7sR/B6xl6Ti9h
bT4AnA5eybuxlslL7Thz1qtjBH0xS/Fy
=JRSR
-----END PGP SIGNATURE-----

--=-Hj/63BIxDs5j/HUaAuA/--



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

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

--===============5340787520306966530==--



From xen-devel-bounces@lists.xen.org Wed Jun 06 14:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHG2-00036Y-8j; Wed, 06 Jun 2012 14:30:46 +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 1ScHG0-00036N-EX
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:30:44 +0000
Received: from [193.109.254.147:33953] by server-1.bemta-14.messagelabs.com id
	01/52-08067-3996FCF4; Wed, 06 Jun 2012 14:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1338993033!5144151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18844 invoked from network); 6 Jun 2012 14:30:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:30:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12861353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:30:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:30:33 +0100
Message-ID: <1338993031.32319.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 15:30:31 +0100
In-Reply-To: <alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 15:01 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/p2m.c        |   71 ++++++++++++++++++++++++++++++++++++++++++--
> >  xen/include/asm-arm/p2m.h |    3 ++
> >  2 files changed, 70 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 095e608..9b40e93 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -10,10 +10,20 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
> >      struct p2m_domain *p2m = &d->arch.p2m;
> >      lpae_t *first = NULL, *second = NULL, *third = NULL;
> >  
> > -    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > +    printk("dom%d IPA %#"PRIpaddr"\n", d->domain_id, addr);
> > +
> > +    printk("P2M @ %p mfn:%#lx (%#03llx,%#03llx,%#03llx)\n",
> > +           p2m->first_level,
> > +           page_to_mfn(p2m->first_level),
> > +           first_table_offset(addr),
> > +           second_table_offset(addr),
> > +           third_table_offset(addr));
> > +
> > +    if ( first_table_offset(addr) >= LPAE_ENTRIES )
> > +        goto done;
> >  
> >      first = __map_domain_page(p2m->first_level);
> > -    printk("1ST[%#03llx] = %#016llx\n",
> > +    printk("1ST[%#03llx] = %#"PRIpaddr"\n",
> >             first_table_offset(addr),
> >             first[first_table_offset(addr)].bits);
> >      if ( !first[first_table_offset(addr)].p2m.valid ||
> > @@ -21,7 +31,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
> >          goto done;
> >  
> >      second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > -    printk("2ND[%#03llx] = %#016llx\n",
> > +    printk("2ND[%#03llx] = %#"PRIpaddr"\n",
> >             second_table_offset(addr),
> >             second[second_table_offset(addr)].bits);
> >      if ( !second[second_table_offset(addr)].p2m.valid ||
> > @@ -29,7 +39,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
> >          goto done;
> >  
> >      third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > -    printk("3RD[%#03llx] = %#016llx\n",
> > +    printk("3RD[%#03llx] = %#"PRIpaddr"\n",
> >             third_table_offset(addr),
> >             third[third_table_offset(addr)].bits);
> >  
> > @@ -51,6 +61,59 @@ void p2m_load_VTTBR(struct domain *d)
> >      isb(); /* Ensure update is visible */
> >  }
> 
> there is no need to introduce p2m_lookup in the same patch you do these
> unrelated printk adjustments, correct?
> 

Right, I think I've just put them in the wrong patch by mistake, I'll
figure out what I meant to do ...
> 
> > +/*
> > + * Lookup the MFN corresponding to a domain's PFN.
> > + *
> > + * There are no processor functions to do a stage 2 only lookup therefore we
> > + * do a a software walk.
> > + */
> > +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> > +{
> > +    struct p2m_domain *p2m = &d->arch.p2m;
> > +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> > +    paddr_t maddr = INVALID_PADDR;
> > +
> > +    spin_lock(&p2m->lock);
> > +
> > +    first = __map_domain_page(p2m->first_level);
> > +    if ( !first[first_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !first[first_table_offset(paddr)].p2m.table )
> > +    {
> > +        pte = first[first_table_offset(paddr)];
> > +        goto done;
> > +    }
> > +
> > +    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
> > +    if ( !second[second_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !second[second_table_offset(paddr)].p2m.table )
> > +    {
> > +        pte = second[second_table_offset(paddr)];
> > +        goto done;
> > +    }
> > +
> > +    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
> > +    if ( !third[third_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !third[third_table_offset(paddr)].p2m.table )
> > +        goto done_err;
> > +
> > +    pte = third[third_table_offset(paddr)];
> > +
> > +done:
> > +
> > +    maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
> > +done_err:
> > +    if (third) unmap_domain_page(third);
> > +    if (second) unmap_domain_page(second);
> > +    if (first) unmap_domain_page(first);
> > +
> > +    spin_unlock(&p2m->lock);
> > +
> > +    return maddr;
> > +}
> > +
> 
> this function looks correct though
> 
> >  int guest_physmap_mark_populate_on_demand(struct domain *d,
> >                                            unsigned long gfn,
> >                                            unsigned int order)
> > diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> > index 349923a..1afd5cb 100644
> > --- a/xen/include/asm-arm/p2m.h
> > +++ b/xen/include/asm-arm/p2m.h
> > @@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
> >  /* */
> >  void p2m_load_VTTBR(struct domain *d);
> >  
> > +/* */
> > +paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
> > +
> >  /* Setup p2m RAM mapping for domain d from start-end. */
> >  int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
> >  /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
> > -- 
> > 1.7.9.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 Wed Jun 06 14:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHG2-00036Y-8j; Wed, 06 Jun 2012 14:30:46 +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 1ScHG0-00036N-EX
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:30:44 +0000
Received: from [193.109.254.147:33953] by server-1.bemta-14.messagelabs.com id
	01/52-08067-3996FCF4; Wed, 06 Jun 2012 14:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1338993033!5144151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18844 invoked from network); 6 Jun 2012 14:30:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:30:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12861353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:30:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:30:33 +0100
Message-ID: <1338993031.32319.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 15:30:31 +0100
In-Reply-To: <alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 15:01 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/p2m.c        |   71 ++++++++++++++++++++++++++++++++++++++++++--
> >  xen/include/asm-arm/p2m.h |    3 ++
> >  2 files changed, 70 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 095e608..9b40e93 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -10,10 +10,20 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
> >      struct p2m_domain *p2m = &d->arch.p2m;
> >      lpae_t *first = NULL, *second = NULL, *third = NULL;
> >  
> > -    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > +    printk("dom%d IPA %#"PRIpaddr"\n", d->domain_id, addr);
> > +
> > +    printk("P2M @ %p mfn:%#lx (%#03llx,%#03llx,%#03llx)\n",
> > +           p2m->first_level,
> > +           page_to_mfn(p2m->first_level),
> > +           first_table_offset(addr),
> > +           second_table_offset(addr),
> > +           third_table_offset(addr));
> > +
> > +    if ( first_table_offset(addr) >= LPAE_ENTRIES )
> > +        goto done;
> >  
> >      first = __map_domain_page(p2m->first_level);
> > -    printk("1ST[%#03llx] = %#016llx\n",
> > +    printk("1ST[%#03llx] = %#"PRIpaddr"\n",
> >             first_table_offset(addr),
> >             first[first_table_offset(addr)].bits);
> >      if ( !first[first_table_offset(addr)].p2m.valid ||
> > @@ -21,7 +31,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
> >          goto done;
> >  
> >      second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > -    printk("2ND[%#03llx] = %#016llx\n",
> > +    printk("2ND[%#03llx] = %#"PRIpaddr"\n",
> >             second_table_offset(addr),
> >             second[second_table_offset(addr)].bits);
> >      if ( !second[second_table_offset(addr)].p2m.valid ||
> > @@ -29,7 +39,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
> >          goto done;
> >  
> >      third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > -    printk("3RD[%#03llx] = %#016llx\n",
> > +    printk("3RD[%#03llx] = %#"PRIpaddr"\n",
> >             third_table_offset(addr),
> >             third[third_table_offset(addr)].bits);
> >  
> > @@ -51,6 +61,59 @@ void p2m_load_VTTBR(struct domain *d)
> >      isb(); /* Ensure update is visible */
> >  }
> 
> there is no need to introduce p2m_lookup in the same patch you do these
> unrelated printk adjustments, correct?
> 

Right, I think I've just put them in the wrong patch by mistake, I'll
figure out what I meant to do ...
> 
> > +/*
> > + * Lookup the MFN corresponding to a domain's PFN.
> > + *
> > + * There are no processor functions to do a stage 2 only lookup therefore we
> > + * do a a software walk.
> > + */
> > +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> > +{
> > +    struct p2m_domain *p2m = &d->arch.p2m;
> > +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> > +    paddr_t maddr = INVALID_PADDR;
> > +
> > +    spin_lock(&p2m->lock);
> > +
> > +    first = __map_domain_page(p2m->first_level);
> > +    if ( !first[first_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !first[first_table_offset(paddr)].p2m.table )
> > +    {
> > +        pte = first[first_table_offset(paddr)];
> > +        goto done;
> > +    }
> > +
> > +    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
> > +    if ( !second[second_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !second[second_table_offset(paddr)].p2m.table )
> > +    {
> > +        pte = second[second_table_offset(paddr)];
> > +        goto done;
> > +    }
> > +
> > +    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
> > +    if ( !third[third_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !third[third_table_offset(paddr)].p2m.table )
> > +        goto done_err;
> > +
> > +    pte = third[third_table_offset(paddr)];
> > +
> > +done:
> > +
> > +    maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
> > +done_err:
> > +    if (third) unmap_domain_page(third);
> > +    if (second) unmap_domain_page(second);
> > +    if (first) unmap_domain_page(first);
> > +
> > +    spin_unlock(&p2m->lock);
> > +
> > +    return maddr;
> > +}
> > +
> 
> this function looks correct though
> 
> >  int guest_physmap_mark_populate_on_demand(struct domain *d,
> >                                            unsigned long gfn,
> >                                            unsigned int order)
> > diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> > index 349923a..1afd5cb 100644
> > --- a/xen/include/asm-arm/p2m.h
> > +++ b/xen/include/asm-arm/p2m.h
> > @@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
> >  /* */
> >  void p2m_load_VTTBR(struct domain *d);
> >  
> > +/* */
> > +paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
> > +
> >  /* Setup p2m RAM mapping for domain d from start-end. */
> >  int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
> >  /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
> > -- 
> > 1.7.9.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 Wed Jun 06 14:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHNt-0003wy-JZ; Wed, 06 Jun 2012 14:38: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 1ScHNs-0003wp-Ts
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:38:53 +0000
Received: from [85.158.143.35:46363] by server-2.bemta-4.messagelabs.com id
	CE/91-17938-B7B6FCF4; Wed, 06 Jun 2012 14:38:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338993529!8646869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23585 invoked from network); 6 Jun 2012 14:38:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:38:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12861630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:38:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:38:49 +0100
Message-ID: <1338993527.32319.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 15:38:47 +0100
In-Reply-To: <78af912f1823442009ea.1338990124@Solace>
References: <78af912f1823442009ea.1338990124@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> @@ -1259,8 +1264,7 @@ int libxl_primary_console_exec(libxl_ctx
>          case LIBXL_DOMAIN_TYPE_PV:
>              rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
>              break;
> -        case -1:
> -            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
> +        case LIBXL_DOMAIN_TYPE_INVALID:
>              rc = ERROR_FAIL;
>              break;
>          default:

This hunk no longer applies due to 25454:123628d31cf2 from Bamvor.
However the same code effectively exists in libxl__primary_console_find
so I resolved it by applying the same there instead, which resulted in:

--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1313,11 +1313,9 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
             *cons_num = 0;
             *type = LIBXL_CONSOLE_TYPE_PV;
             break;
-        case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
+        case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-            break;
         default:
             abort();
         }

I'll commit this, assuming I can compile it etc.

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 14:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHNt-0003wy-JZ; Wed, 06 Jun 2012 14:38: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 1ScHNs-0003wp-Ts
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:38:53 +0000
Received: from [85.158.143.35:46363] by server-2.bemta-4.messagelabs.com id
	CE/91-17938-B7B6FCF4; Wed, 06 Jun 2012 14:38:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338993529!8646869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23585 invoked from network); 6 Jun 2012 14:38:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:38:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12861630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:38:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:38:49 +0100
Message-ID: <1338993527.32319.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 15:38:47 +0100
In-Reply-To: <78af912f1823442009ea.1338990124@Solace>
References: <78af912f1823442009ea.1338990124@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> @@ -1259,8 +1264,7 @@ int libxl_primary_console_exec(libxl_ctx
>          case LIBXL_DOMAIN_TYPE_PV:
>              rc = libxl_console_exec(ctx, domid_vm, 0, LIBXL_CONSOLE_TYPE_PV);
>              break;
> -        case -1:
> -            LOG(ERROR,"unable to get domain type for domid=%"PRIu32,domid_vm);
> +        case LIBXL_DOMAIN_TYPE_INVALID:
>              rc = ERROR_FAIL;
>              break;
>          default:

This hunk no longer applies due to 25454:123628d31cf2 from Bamvor.
However the same code effectively exists in libxl__primary_console_find
so I resolved it by applying the same there instead, which resulted in:

--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1313,11 +1313,9 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
             *cons_num = 0;
             *type = LIBXL_CONSOLE_TYPE_PV;
             break;
-        case -1:
-            LOG(ERROR,"unable to get domain type for domid=%"PRIu32, domid_vm);
+        case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-            break;
         default:
             abort();
         }

I'll commit this, assuming I can compile it etc.

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 14:57:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHg8-0004cs-5c; Wed, 06 Jun 2012 14:57:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScHg6-0004cS-HH
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:57:42 +0000
Received: from [85.158.143.99:12508] by server-1.bemta-4.messagelabs.com id
	A1/19-10042-5EF6FCF4; Wed, 06 Jun 2012 14:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338994659!29266485!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5522 invoked from network); 6 Jun 2012 14:57:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:57:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:57:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:57:23 +0100
Message-ID: <1338994641.32319.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 6 Jun 2012 15:57:21 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@xen.org>
Subject: [Xen-devel] Volunteers wanted to help with list moderation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen.org mailing lists are moderated for non-subscribers, primarily
as a SPAM prevention measure. We are a little short of moderators at the
moment which means that sometimes mails for genuine posters who happen
to not be subscribed get delayed for a few days.

We are looking for volunteers to help out with this, it should be a
couple of a minutes each day to clear out any SPAM which has made it
through the automated filters and accept the posts from non-subscribers.

The basic policy for moderation is:

     "reject and blacklist spam, accept and whitelist everything else".

Most of the SPAM which gets through the filters is still pretty obvious
to the human eye and there are generally only a small number each day so
it is usually a pretty quick job.

Please let myself and Lars know if you would like to help out with one
or more lists. The only requirement is to be an existing regular poster
to the list.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 14:57:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHg8-0004cs-5c; Wed, 06 Jun 2012 14:57:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScHg6-0004cS-HH
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:57:42 +0000
Received: from [85.158.143.99:12508] by server-1.bemta-4.messagelabs.com id
	A1/19-10042-5EF6FCF4; Wed, 06 Jun 2012 14:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338994659!29266485!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5522 invoked from network); 6 Jun 2012 14:57:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:57:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:57:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:57:23 +0100
Message-ID: <1338994641.32319.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 6 Jun 2012 15:57:21 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@xen.org>
Subject: [Xen-devel] Volunteers wanted to help with list moderation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen.org mailing lists are moderated for non-subscribers, primarily
as a SPAM prevention measure. We are a little short of moderators at the
moment which means that sometimes mails for genuine posters who happen
to not be subscribed get delayed for a few days.

We are looking for volunteers to help out with this, it should be a
couple of a minutes each day to clear out any SPAM which has made it
through the automated filters and accept the posts from non-subscribers.

The basic policy for moderation is:

     "reject and blacklist spam, accept and whitelist everything else".

Most of the SPAM which gets through the filters is still pretty obvious
to the human eye and there are generally only a small number each day so
it is usually a pretty quick job.

Please let myself and Lars know if you would like to help out with one
or more lists. The only requirement is to be an existing regular poster
to the list.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 14:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHhj-0004uU-Is; Wed, 06 Jun 2012 14:59: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 1ScHhh-0004u7-Is
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:59:21 +0000
Received: from [85.158.143.99:23264] by server-2.bemta-4.messagelabs.com id
	83/33-17938-8407FCF4; Wed, 06 Jun 2012 14:59:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338994760!25041911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25233 invoked from network); 6 Jun 2012 14:59:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:59:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:59:20 +0100
Message-ID: <1338994758.32319.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 15:59:18 +0100
In-Reply-To: <78af912f1823442009ea.1338990124@Solace>
References: <78af912f1823442009ea.1338990124@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> To avoid recent gcc complaining about:
> libxl.c: In function 'libxl_primary_console_exec':
> libxl.c:1233:9: error: case value '4294967295' not in enumerated type 'libxl_domain_type' [-Werror=switch]
> 
> Also:
>  - have all the call sites of libxl__domain_type() return with error in
>    case the function returns LIBXL_DOMAIN_TYPE_INVALID;
>  - adjust all other code segments where -Wswitch makes would claim that
>    LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort();"
>    clause.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Committed with the two changes I mentioned. Please check I haven't made
a mess of things...

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 14:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 14: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 1ScHhj-0004uU-Is; Wed, 06 Jun 2012 14:59: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 1ScHhh-0004u7-Is
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 14:59:21 +0000
Received: from [85.158.143.99:23264] by server-2.bemta-4.messagelabs.com id
	83/33-17938-8407FCF4; Wed, 06 Jun 2012 14:59:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1338994760!25041911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25233 invoked from network); 6 Jun 2012 14:59:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 14:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 14:59:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	15:59:20 +0100
Message-ID: <1338994758.32319.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 6 Jun 2012 15:59:18 +0100
In-Reply-To: <78af912f1823442009ea.1338990124@Solace>
References: <78af912f1823442009ea.1338990124@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> To avoid recent gcc complaining about:
> libxl.c: In function 'libxl_primary_console_exec':
> libxl.c:1233:9: error: case value '4294967295' not in enumerated type 'libxl_domain_type' [-Werror=switch]
> 
> Also:
>  - have all the call sites of libxl__domain_type() return with error in
>    case the function returns LIBXL_DOMAIN_TYPE_INVALID;
>  - adjust all other code segments where -Wswitch makes would claim that
>    LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort();"
>    clause.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Committed with the two changes I mentioned. Please check I haven't made
a mess of things...

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:14: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 1ScHvh-0005eJ-4P; Wed, 06 Jun 2012 15:13: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 1ScHvf-0005eB-1F
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:13:47 +0000
Received: from [85.158.143.35:50818] by server-2.bemta-4.messagelabs.com id
	39/F9-17938-AA37FCF4; Wed, 06 Jun 2012 15:13:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1338995625!8147596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30803 invoked from network); 6 Jun 2012 15:13:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:13:45 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:13:45 +0100
Date: Wed, 6 Jun 2012 16:13:38 +0100
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: <1338565207-2888-12-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061613210.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-12-git-send-email-ian.campbell@citrix.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] [PATCH 12/38] arm: remove hard tabs from
 init_idle_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 Fri, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.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 0df3c1a..81ababb 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -47,9 +47,9 @@ static __attribute_used__ void init_done(void)
>  
>  static void __init init_idle_domain(void)
>  {
> -        scheduler_init();
> -        set_current(idle_vcpu[0]);
> -        /* TODO: setup_idle_pagetable(); */
> +    scheduler_init();
> +    set_current(idle_vcpu[0]);
> +    /* TODO: setup_idle_pagetable(); */
>  }
>  
>  static void __init processor_id(void)
> -- 
> 1.7.9.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 Wed Jun 06 15:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:14: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 1ScHvh-0005eJ-4P; Wed, 06 Jun 2012 15:13: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 1ScHvf-0005eB-1F
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:13:47 +0000
Received: from [85.158.143.35:50818] by server-2.bemta-4.messagelabs.com id
	39/F9-17938-AA37FCF4; Wed, 06 Jun 2012 15:13:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1338995625!8147596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30803 invoked from network); 6 Jun 2012 15:13:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:13:45 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:13:45 +0100
Date: Wed, 6 Jun 2012 16:13:38 +0100
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: <1338565207-2888-12-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061613210.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-12-git-send-email-ian.campbell@citrix.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] [PATCH 12/38] arm: remove hard tabs from
 init_idle_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 Fri, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.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 0df3c1a..81ababb 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -47,9 +47,9 @@ static __attribute_used__ void init_done(void)
>  
>  static void __init init_idle_domain(void)
>  {
> -        scheduler_init();
> -        set_current(idle_vcpu[0]);
> -        /* TODO: setup_idle_pagetable(); */
> +    scheduler_init();
> +    set_current(idle_vcpu[0]);
> +    /* TODO: setup_idle_pagetable(); */
>  }
>  
>  static void __init processor_id(void)
> -- 
> 1.7.9.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 Wed Jun 06 15:15:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:15: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 1ScHxK-0005iM-Jm; Wed, 06 Jun 2012 15:15:30 +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 1ScHxJ-0005iG-5D
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:15:29 +0000
Received: from [85.158.139.83:56085] by server-3.bemta-5.messagelabs.com id
	85/81-17554-0147FCF4; Wed, 06 Jun 2012 15:15:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338995727!18452879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8452 invoked from network); 6 Jun 2012 15:15:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:15:27 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:15:27 +0100
Date: Wed, 6 Jun 2012 16:15:21 +0100
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: <1338565207-2888-13-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061615110.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-13-git-send-email-ian.campbell@citrix.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] [PATCH 13/38] arm: stub out sync_vcpu_execstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> We don't do lazy exec state switching so there isn't actually anything to do.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c |    5 +++++
>  xen/arch/arm/dummy.S  |    1 -
>  2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 62a2f3a..bd900f9 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -96,6 +96,11 @@ void sync_local_execstate(void)
>      /* Nothing to do -- no lazy switching */
>  }
>  
> +void sync_vcpu_execstate(struct vcpu *v)
> +{
> +    /* Nothing to do -- no lazy switching */
> +}
> +
>  void startup_cpu_idle_loop(void)
>  {
>      struct vcpu *v = current;
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 3b48917..8eddd15 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -22,7 +22,6 @@ DUMMY(pirq_set_affinity);
>  /* VCPU */
>  DUMMY(arch_get_info_guest);
>  DUMMY(arch_vcpu_reset);
> -DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
>  DUMMY(vcpu_show_execution_state);
>  
> -- 
> 1.7.9.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 Wed Jun 06 15:15:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:15: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 1ScHxK-0005iM-Jm; Wed, 06 Jun 2012 15:15:30 +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 1ScHxJ-0005iG-5D
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:15:29 +0000
Received: from [85.158.139.83:56085] by server-3.bemta-5.messagelabs.com id
	85/81-17554-0147FCF4; Wed, 06 Jun 2012 15:15:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1338995727!18452879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8452 invoked from network); 6 Jun 2012 15:15:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:15:27 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:15:27 +0100
Date: Wed, 6 Jun 2012 16:15:21 +0100
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: <1338565207-2888-13-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061615110.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-13-git-send-email-ian.campbell@citrix.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] [PATCH 13/38] arm: stub out sync_vcpu_execstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> We don't do lazy exec state switching so there isn't actually anything to do.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c |    5 +++++
>  xen/arch/arm/dummy.S  |    1 -
>  2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 62a2f3a..bd900f9 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -96,6 +96,11 @@ void sync_local_execstate(void)
>      /* Nothing to do -- no lazy switching */
>  }
>  
> +void sync_vcpu_execstate(struct vcpu *v)
> +{
> +    /* Nothing to do -- no lazy switching */
> +}
> +
>  void startup_cpu_idle_loop(void)
>  {
>      struct vcpu *v = current;
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 3b48917..8eddd15 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -22,7 +22,6 @@ DUMMY(pirq_set_affinity);
>  /* VCPU */
>  DUMMY(arch_get_info_guest);
>  DUMMY(arch_vcpu_reset);
> -DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
>  DUMMY(vcpu_show_execution_state);
>  
> -- 
> 1.7.9.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 Wed Jun 06 15:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScI1G-0005tt-8n; Wed, 06 Jun 2012 15:19: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 1ScI1E-0005tk-CM
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:19:32 +0000
Received: from [85.158.143.35:49353] by server-2.bemta-4.messagelabs.com id
	06/82-17938-3057FCF4; Wed, 06 Jun 2012 15:19:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338995971!14315070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2511 invoked from network); 6 Jun 2012 15:19:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:19:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	16:19:31 +0100
Message-ID: <1338995969.32319.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 16:19:29 +0100
In-Reply-To: <alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/38] arm: context switch a bunch of 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 Tue, 2012-06-05 at 18:11 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 1a2b95f..339c327 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -61,6 +61,30 @@ static struct {
> >  irq_desc_t irq_desc[NR_IRQS];
> >  unsigned nr_lrs;
> > 
> > +void gic_save_state(struct vcpu *v)
> > +{
> > +    int i;
> > +
> > +    for ( i=0; i<nr_lrs; i++)
> > +        v->arch.gic_lr[i] = GICH[GICH_LR + i];
> > +    /* Disable until next VCPU scheduled */
> > +    GICH[GICH_HCR] = 0;
> > +    isb();
> > +}
> > +
> > +void gic_restore_state(struct vcpu *v)
> > +{
> > +    int i;
> > +
> > +    if ( is_idle_vcpu(v) )
> > +        return;
> > +
> > +    for ( i=0; i<nr_lrs; i++)
> > +        GICH[GICH_LR + i] = v->arch.gic_lr[i];
> > +    GICH[GICH_HCR] = GICH_HCR_EN;
> > +    isb();
> > +}
> > +
> 
> it is still missing a bunch of stuff from the gic state but it is a step
> in the right direction, so I'll send out patches to complete the gic
> context switch separately, based on this one.

Can I take this as an Ack for this patch for what it does?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScI1G-0005tt-8n; Wed, 06 Jun 2012 15:19: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 1ScI1E-0005tk-CM
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:19:32 +0000
Received: from [85.158.143.35:49353] by server-2.bemta-4.messagelabs.com id
	06/82-17938-3057FCF4; Wed, 06 Jun 2012 15:19:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1338995971!14315070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2511 invoked from network); 6 Jun 2012 15:19:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:19:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	16:19:31 +0100
Message-ID: <1338995969.32319.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 16:19:29 +0100
In-Reply-To: <alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 19/38] arm: context switch a bunch of 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 Tue, 2012-06-05 at 18:11 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 1a2b95f..339c327 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -61,6 +61,30 @@ static struct {
> >  irq_desc_t irq_desc[NR_IRQS];
> >  unsigned nr_lrs;
> > 
> > +void gic_save_state(struct vcpu *v)
> > +{
> > +    int i;
> > +
> > +    for ( i=0; i<nr_lrs; i++)
> > +        v->arch.gic_lr[i] = GICH[GICH_LR + i];
> > +    /* Disable until next VCPU scheduled */
> > +    GICH[GICH_HCR] = 0;
> > +    isb();
> > +}
> > +
> > +void gic_restore_state(struct vcpu *v)
> > +{
> > +    int i;
> > +
> > +    if ( is_idle_vcpu(v) )
> > +        return;
> > +
> > +    for ( i=0; i<nr_lrs; i++)
> > +        GICH[GICH_LR + i] = v->arch.gic_lr[i];
> > +    GICH[GICH_HCR] = GICH_HCR_EN;
> > +    isb();
> > +}
> > +
> 
> it is still missing a bunch of stuff from the gic state but it is a step
> in the right direction, so I'll send out patches to complete the gic
> context switch separately, based on this one.

Can I take this as an Ack for this patch for what it does?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:20:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScI2C-0005yA-Nj; Wed, 06 Jun 2012 15:20:32 +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 1ScI2B-0005xx-E9
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:20:31 +0000
Received: from [193.109.254.147:11493] by server-7.bemta-14.messagelabs.com id
	28/F9-29165-E357FCF4; Wed, 06 Jun 2012 15:20:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338996022!12905102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 792 invoked from network); 6 Jun 2012 15:20:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:20:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:20:22 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:20:22 +0100
Date: Wed, 6 Jun 2012 16:20:16 +0100
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: <1338995969.32319.139.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206061620040.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
	<1338995969.32319.139.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] [PATCH 19/38] arm: context switch a bunch of 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 Wed, 6 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-05 at 18:11 +0100, Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > index 1a2b95f..339c327 100644
> > > --- a/xen/arch/arm/gic.c
> > > +++ b/xen/arch/arm/gic.c
> > > @@ -61,6 +61,30 @@ static struct {
> > >  irq_desc_t irq_desc[NR_IRQS];
> > >  unsigned nr_lrs;
> > > 
> > > +void gic_save_state(struct vcpu *v)
> > > +{
> > > +    int i;
> > > +
> > > +    for ( i=0; i<nr_lrs; i++)
> > > +        v->arch.gic_lr[i] = GICH[GICH_LR + i];
> > > +    /* Disable until next VCPU scheduled */
> > > +    GICH[GICH_HCR] = 0;
> > > +    isb();
> > > +}
> > > +
> > > +void gic_restore_state(struct vcpu *v)
> > > +{
> > > +    int i;
> > > +
> > > +    if ( is_idle_vcpu(v) )
> > > +        return;
> > > +
> > > +    for ( i=0; i<nr_lrs; i++)
> > > +        GICH[GICH_LR + i] = v->arch.gic_lr[i];
> > > +    GICH[GICH_HCR] = GICH_HCR_EN;
> > > +    isb();
> > > +}
> > > +
> > 
> > it is still missing a bunch of stuff from the gic state but it is a step
> > in the right direction, so I'll send out patches to complete the gic
> > context switch separately, based on this one.
> 
> Can I take this as an Ack for this patch for what it does?

yes

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:20:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScI2C-0005yA-Nj; Wed, 06 Jun 2012 15:20:32 +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 1ScI2B-0005xx-E9
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:20:31 +0000
Received: from [193.109.254.147:11493] by server-7.bemta-14.messagelabs.com id
	28/F9-29165-E357FCF4; Wed, 06 Jun 2012 15:20:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1338996022!12905102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 792 invoked from network); 6 Jun 2012 15:20:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:20:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:20:22 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:20:22 +0100
Date: Wed, 6 Jun 2012 16:20:16 +0100
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: <1338995969.32319.139.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206061620040.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-19-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206051810270.6030@kaball.uk.xensource.com>
	<1338995969.32319.139.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] [PATCH 19/38] arm: context switch a bunch of 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 Wed, 6 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-05 at 18:11 +0100, Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > index 1a2b95f..339c327 100644
> > > --- a/xen/arch/arm/gic.c
> > > +++ b/xen/arch/arm/gic.c
> > > @@ -61,6 +61,30 @@ static struct {
> > >  irq_desc_t irq_desc[NR_IRQS];
> > >  unsigned nr_lrs;
> > > 
> > > +void gic_save_state(struct vcpu *v)
> > > +{
> > > +    int i;
> > > +
> > > +    for ( i=0; i<nr_lrs; i++)
> > > +        v->arch.gic_lr[i] = GICH[GICH_LR + i];
> > > +    /* Disable until next VCPU scheduled */
> > > +    GICH[GICH_HCR] = 0;
> > > +    isb();
> > > +}
> > > +
> > > +void gic_restore_state(struct vcpu *v)
> > > +{
> > > +    int i;
> > > +
> > > +    if ( is_idle_vcpu(v) )
> > > +        return;
> > > +
> > > +    for ( i=0; i<nr_lrs; i++)
> > > +        GICH[GICH_LR + i] = v->arch.gic_lr[i];
> > > +    GICH[GICH_HCR] = GICH_HCR_EN;
> > > +    isb();
> > > +}
> > > +
> > 
> > it is still missing a bunch of stuff from the gic state but it is a step
> > in the right direction, so I'll send out patches to complete the gic
> > context switch separately, based on this one.
> 
> Can I take this as an Ack for this patch for what it does?

yes

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:26: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 1ScI86-0006C2-HC; Wed, 06 Jun 2012 15:26: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 1ScI85-0006Bx-Gm
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:26:37 +0000
Received: from [85.158.143.35:30057] by server-2.bemta-4.messagelabs.com id
	07/EC-17938-CA67FCF4; Wed, 06 Jun 2012 15:26:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338996392!19140032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12678 invoked from network); 6 Jun 2012 15:26:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:26:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:26:31 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:26:31 +0100
Date: Wed, 6 Jun 2012 16:26:25 +0100
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: <1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.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] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> smaller guest.
> 
> The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> MAX_VIRT_CPUS -- but making that change caused:

Are you sure? I made that change and I didn't see the error.
I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
max_vcpus = 8.


>     (XEN) Unexpected Trap: Data Abort
>     (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
>     (XEN) CPU:    0
>     (XEN) PC:     00222e48 _spin_lock+0x28/0x6c
>     (XEN) CPSR:   600001da MODE:HYP
>     (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
>     (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
>     (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
>     (XEN)      SP: 40017d5c LR: 00222e34
>     (XEN)
>     [...]
>     (XEN) Xen call trace:
>     (XEN)    [<00222e48>] _spin_lock+0x28/0x6c
>     (XEN)    [<0022623c>] init_timer+0xbc/0x160
>     (XEN)    [<0021fbdc>] sched_init_vcpu+0x94/0x200
>     (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
>     (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
>     (XEN)    [<00241ab8>] do_trap_hypervisor+0x588/0x8cc
>     (XEN)    [<0023bbb0>] return_from_trap+0x0/0x4
> 
> so punt on that for now.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index bd900f9..e867cb2 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -215,8 +215,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>              goto fail;
>      }
>  
> -    d->max_vcpus = 8;
> -
>      if ( (rc = domain_vgic_init(d)) != 0 )
>          goto fail;
>  
> -- 
> 1.7.9.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 Wed Jun 06 15:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:26: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 1ScI86-0006C2-HC; Wed, 06 Jun 2012 15:26: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 1ScI85-0006Bx-Gm
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:26:37 +0000
Received: from [85.158.143.35:30057] by server-2.bemta-4.messagelabs.com id
	07/EC-17938-CA67FCF4; Wed, 06 Jun 2012 15:26:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1338996392!19140032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12678 invoked from network); 6 Jun 2012 15:26:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:26:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:26:31 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:26:31 +0100
Date: Wed, 6 Jun 2012 16:26:25 +0100
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: <1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.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] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> smaller guest.
> 
> The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> MAX_VIRT_CPUS -- but making that change caused:

Are you sure? I made that change and I didn't see the error.
I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
max_vcpus = 8.


>     (XEN) Unexpected Trap: Data Abort
>     (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
>     (XEN) CPU:    0
>     (XEN) PC:     00222e48 _spin_lock+0x28/0x6c
>     (XEN) CPSR:   600001da MODE:HYP
>     (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
>     (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
>     (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
>     (XEN)      SP: 40017d5c LR: 00222e34
>     (XEN)
>     [...]
>     (XEN) Xen call trace:
>     (XEN)    [<00222e48>] _spin_lock+0x28/0x6c
>     (XEN)    [<0022623c>] init_timer+0xbc/0x160
>     (XEN)    [<0021fbdc>] sched_init_vcpu+0x94/0x200
>     (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
>     (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
>     (XEN)    [<00241ab8>] do_trap_hypervisor+0x588/0x8cc
>     (XEN)    [<0023bbb0>] return_from_trap+0x0/0x4
> 
> so punt on that for now.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index bd900f9..e867cb2 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -215,8 +215,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>              goto fail;
>      }
>  
> -    d->max_vcpus = 8;
> -
>      if ( (rc = domain_vgic_init(d)) != 0 )
>          goto fail;
>  
> -- 
> 1.7.9.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 Wed Jun 06 15:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:28: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 1ScI9P-0006Fv-Vz; Wed, 06 Jun 2012 15:27:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScI9O-0006Fm-Oh
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:27:58 +0000
Received: from [193.109.254.147:57454] by server-7.bemta-14.messagelabs.com id
	17/41-29165-EF67FCF4; Wed, 06 Jun 2012 15:27:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1338996477!6251332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17829 invoked from network); 6 Jun 2012 15:27:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:27:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:27:57 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:27:57 +0100
Date: Wed, 6 Jun 2012 16:27:50 +0100
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: <1338565207-2888-15-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061627380.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-15-git-send-email-ian.campbell@citrix.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] [PATCH 15/38] arm: implement stub version of
 flush_tlb_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, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/dummy.S |    1 -
>  xen/arch/arm/smp.c   |    9 +++++++++
>  2 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 8eddd15..c001e8d 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -48,7 +48,6 @@ DUMMY(domain_get_maximum_gpfn);
>  DUMMY(domain_relinquish_resources);
>  DUMMY(domain_set_time_offset);
>  DUMMY(dom_cow);
> -DUMMY(flush_tlb_mask);
>  DUMMY(gmfn_to_mfn);
>  DUMMY(hypercall_create_continuation);
>  DUMMY(send_timer_event);
> diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
> index cad84f5..824c8c8 100644
> --- a/xen/arch/arm/smp.c
> +++ b/xen/arch/arm/smp.c
> @@ -1,5 +1,14 @@
>  #include <xen/config.h>
> +#include <asm/system.h>
>  #include <asm/smp.h>
> +#include <asm/cpregs.h>
> +#include <asm/page.h>
> +
> +void flush_tlb_mask(const cpumask_t *mask)
> +{
> +    /* XXX IPI other processors */
> +    flush_xen_data_tlb();
> +}
>  
>  void smp_call_function(
>      void (*func) (void *info),
> -- 
> 1.7.9.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 Wed Jun 06 15:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:28: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 1ScI9P-0006Fv-Vz; Wed, 06 Jun 2012 15:27:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScI9O-0006Fm-Oh
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:27:58 +0000
Received: from [193.109.254.147:57454] by server-7.bemta-14.messagelabs.com id
	17/41-29165-EF67FCF4; Wed, 06 Jun 2012 15:27:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1338996477!6251332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17829 invoked from network); 6 Jun 2012 15:27:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:27:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:27:57 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 16:27:57 +0100
Date: Wed, 6 Jun 2012 16:27:50 +0100
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: <1338565207-2888-15-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061627380.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-15-git-send-email-ian.campbell@citrix.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] [PATCH 15/38] arm: implement stub version of
 flush_tlb_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, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/dummy.S |    1 -
>  xen/arch/arm/smp.c   |    9 +++++++++
>  2 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 8eddd15..c001e8d 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -48,7 +48,6 @@ DUMMY(domain_get_maximum_gpfn);
>  DUMMY(domain_relinquish_resources);
>  DUMMY(domain_set_time_offset);
>  DUMMY(dom_cow);
> -DUMMY(flush_tlb_mask);
>  DUMMY(gmfn_to_mfn);
>  DUMMY(hypercall_create_continuation);
>  DUMMY(send_timer_event);
> diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
> index cad84f5..824c8c8 100644
> --- a/xen/arch/arm/smp.c
> +++ b/xen/arch/arm/smp.c
> @@ -1,5 +1,14 @@
>  #include <xen/config.h>
> +#include <asm/system.h>
>  #include <asm/smp.h>
> +#include <asm/cpregs.h>
> +#include <asm/page.h>
> +
> +void flush_tlb_mask(const cpumask_t *mask)
> +{
> +    /* XXX IPI other processors */
> +    flush_xen_data_tlb();
> +}
>  
>  void smp_call_function(
>      void (*func) (void *info),
> -- 
> 1.7.9.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 Wed Jun 06 15:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScIBI-0006Mr-G3; Wed, 06 Jun 2012 15:29:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScIBH-0006Me-6E
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:29:55 +0000
Received: from [85.158.143.35:48372] by server-1.bemta-4.messagelabs.com id
	0F/9B-10042-2777FCF4; Wed, 06 Jun 2012 15:29:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1338996593!8150357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 507 invoked from network); 6 Jun 2012 15:29:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:29:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:29:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	16:29:53 +0100
Message-ID: <1338996592.32319.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 16:29:52 +0100
In-Reply-To: <alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 16:26 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> > smaller guest.
> > 
> > The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> > MAX_VIRT_CPUS -- but making that change caused:
> 
> Are you sure?

Reasonably.

>  I made that change and I didn't see the error.

Let me try it again.

> I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
> max_vcpus = 8.

Yes, that would be ideal, but in the interim just removing the max_vcpus
= 8 is an improvement in its own right if changing MAX_VIRT_CPUS causes
grief.

Ian.
> 
> 
> >     (XEN) Unexpected Trap: Data Abort
> >     (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
> >     (XEN) CPU:    0
> >     (XEN) PC:     00222e48 _spin_lock+0x28/0x6c
> >     (XEN) CPSR:   600001da MODE:HYP
> >     (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
> >     (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
> >     (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
> >     (XEN)      SP: 40017d5c LR: 00222e34
> >     (XEN)
> >     [...]
> >     (XEN) Xen call trace:
> >     (XEN)    [<00222e48>] _spin_lock+0x28/0x6c
> >     (XEN)    [<0022623c>] init_timer+0xbc/0x160
> >     (XEN)    [<0021fbdc>] sched_init_vcpu+0x94/0x200
> >     (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
> >     (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
> >     (XEN)    [<00241ab8>] do_trap_hypervisor+0x588/0x8cc
> >     (XEN)    [<0023bbb0>] return_from_trap+0x0/0x4
> > 
> > so punt on that for now.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain.c |    2 --
> >  1 files changed, 0 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index bd900f9..e867cb2 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -215,8 +215,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >              goto fail;
> >      }
> >  
> > -    d->max_vcpus = 8;
> > -
> >      if ( (rc = domain_vgic_init(d)) != 0 )
> >          goto fail;
> >  
> > -- 
> > 1.7.9.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 Wed Jun 06 15:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScIBI-0006Mr-G3; Wed, 06 Jun 2012 15:29:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScIBH-0006Me-6E
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:29:55 +0000
Received: from [85.158.143.35:48372] by server-1.bemta-4.messagelabs.com id
	0F/9B-10042-2777FCF4; Wed, 06 Jun 2012 15:29:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1338996593!8150357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 507 invoked from network); 6 Jun 2012 15:29:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:29:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208";a="12862905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 15:29:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
	16:29:53 +0100
Message-ID: <1338996592.32319.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 6 Jun 2012 16:29:52 +0100
In-Reply-To: <alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 16:26 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> > smaller guest.
> > 
> > The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> > MAX_VIRT_CPUS -- but making that change caused:
> 
> Are you sure?

Reasonably.

>  I made that change and I didn't see the error.

Let me try it again.

> I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
> max_vcpus = 8.

Yes, that would be ideal, but in the interim just removing the max_vcpus
= 8 is an improvement in its own right if changing MAX_VIRT_CPUS causes
grief.

Ian.
> 
> 
> >     (XEN) Unexpected Trap: Data Abort
> >     (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
> >     (XEN) CPU:    0
> >     (XEN) PC:     00222e48 _spin_lock+0x28/0x6c
> >     (XEN) CPSR:   600001da MODE:HYP
> >     (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
> >     (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
> >     (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
> >     (XEN)      SP: 40017d5c LR: 00222e34
> >     (XEN)
> >     [...]
> >     (XEN) Xen call trace:
> >     (XEN)    [<00222e48>] _spin_lock+0x28/0x6c
> >     (XEN)    [<0022623c>] init_timer+0xbc/0x160
> >     (XEN)    [<0021fbdc>] sched_init_vcpu+0x94/0x200
> >     (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
> >     (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
> >     (XEN)    [<00241ab8>] do_trap_hypervisor+0x588/0x8cc
> >     (XEN)    [<0023bbb0>] return_from_trap+0x0/0x4
> > 
> > so punt on that for now.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain.c |    2 --
> >  1 files changed, 0 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index bd900f9..e867cb2 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -215,8 +215,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >              goto fail;
> >      }
> >  
> > -    d->max_vcpus = 8;
> > -
> >      if ( (rc = domain_vgic_init(d)) != 0 )
> >          goto fail;
> >  
> > -- 
> > 1.7.9.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 Wed Jun 06 15:35:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:35: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 1ScIGk-0006ic-LM; Wed, 06 Jun 2012 15:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1ScIGk-0006iK-2E
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:35:34 +0000
Received: from [85.158.143.99:7050] by server-2.bemta-4.messagelabs.com id
	1A/AA-17938-5C87FCF4; Wed, 06 Jun 2012 15:35:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338996930!29273162!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8418 invoked from network); 6 Jun 2012 15:35:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:35:31 -0000
Received: by eekd41 with SMTP id d41so2579876eek.32
	for <multiple recipients>; Wed, 06 Jun 2012 08:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+yE5V7Js7AZgmLLkeb55yBzWJ7itscCyHf5DWAmwO0Y=;
	b=jdrJdA1fm/Y5NjJAPTBlka05ZcfgMnJ0IrsUdfgX1VGNYFI+6FBeG+Ai8f2HD/x14n
	PBiBrAcyOkZs+MgP1++q8+mTcM31sBV+iaUxLKL7wTCgllJlR8HAUWvtgKsVTdZTbObG
	WFnnMgwBd50/aXNOC+pAOY2bpNTwN8ch/8SzTcFOJIq04Ob4nr1w9AFfvHcLeAV5irji
	UQUQVsFWKFV3no0zQRFOwDYPdy5bMOOEISOhdtT6tBUKp2VBcj8Dj5Q70re7EXG4pqCn
	3TBnTdpHVhw4H5eK/xhKTST7zw8aNysTvA72+/ZvYK9X0s9SHwxWl/nnnbX1ViziFP75
	qXfw==
Received: by 10.14.97.131 with SMTP id t3mr856082eef.196.1338996929490;
	Wed, 06 Jun 2012 08:35:29 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id p41sm604637eef.5.2012.06.06.08.35.26
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 08:35:27 -0700 (PDT)
Message-ID: <4FCF78BD.3040909@xen.org>
Date: Wed, 06 Jun 2012 16:35:25 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
In-Reply-To: <20425.472.655564.805506@mariner.uk.xensource.com>
Cc: xen-users@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
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

On 01/06/2012 18:54, Ian Jackson wrote:
> Lars Kurth writes ("[Xen-devel] Proposals/changes for a new Wiki Front-Page - need input/mods/creative proposals"):
>> - http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case focussed
>> front-page
> This one is already much better than the existing front page.  I have
> made some more changes.
Great!

> The links under "Xen Docs" are rather poor.  I don't know what pages
> we have that would do better, but the top link being the Wiki category
> listing is quite unhelpful.
Would a ...
1) link to http://wiki.xen.org/wiki/Xen_4.x_Manuals instead of 
http://wiki.xen.org/wiki/Category:Manual be better?
2) We could move http://wiki.xen.org/wiki/Xen_Beginners_Guide one up - 
it is a step-by-step tutorial to set up Xen 4 with Squeeze

Part of the problem is that there is a lot of stuff and it is hard to 
choose what is relevant

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:35:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:35: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 1ScIGk-0006ic-LM; Wed, 06 Jun 2012 15:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1ScIGk-0006iK-2E
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 15:35:34 +0000
Received: from [85.158.143.99:7050] by server-2.bemta-4.messagelabs.com id
	1A/AA-17938-5C87FCF4; Wed, 06 Jun 2012 15:35:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1338996930!29273162!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8418 invoked from network); 6 Jun 2012 15:35:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 15:35:31 -0000
Received: by eekd41 with SMTP id d41so2579876eek.32
	for <multiple recipients>; Wed, 06 Jun 2012 08:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=+yE5V7Js7AZgmLLkeb55yBzWJ7itscCyHf5DWAmwO0Y=;
	b=jdrJdA1fm/Y5NjJAPTBlka05ZcfgMnJ0IrsUdfgX1VGNYFI+6FBeG+Ai8f2HD/x14n
	PBiBrAcyOkZs+MgP1++q8+mTcM31sBV+iaUxLKL7wTCgllJlR8HAUWvtgKsVTdZTbObG
	WFnnMgwBd50/aXNOC+pAOY2bpNTwN8ch/8SzTcFOJIq04Ob4nr1w9AFfvHcLeAV5irji
	UQUQVsFWKFV3no0zQRFOwDYPdy5bMOOEISOhdtT6tBUKp2VBcj8Dj5Q70re7EXG4pqCn
	3TBnTdpHVhw4H5eK/xhKTST7zw8aNysTvA72+/ZvYK9X0s9SHwxWl/nnnbX1ViziFP75
	qXfw==
Received: by 10.14.97.131 with SMTP id t3mr856082eef.196.1338996929490;
	Wed, 06 Jun 2012 08:35:29 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id p41sm604637eef.5.2012.06.06.08.35.26
	(version=SSLv3 cipher=OTHER); Wed, 06 Jun 2012 08:35:27 -0700 (PDT)
Message-ID: <4FCF78BD.3040909@xen.org>
Date: Wed, 06 Jun 2012 16:35:25 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
In-Reply-To: <20425.472.655564.805506@mariner.uk.xensource.com>
Cc: xen-users@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
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

On 01/06/2012 18:54, Ian Jackson wrote:
> Lars Kurth writes ("[Xen-devel] Proposals/changes for a new Wiki Front-Page - need input/mods/creative proposals"):
>> - http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case focussed
>> front-page
> This one is already much better than the existing front page.  I have
> made some more changes.
Great!

> The links under "Xen Docs" are rather poor.  I don't know what pages
> we have that would do better, but the top link being the Wiki category
> listing is quite unhelpful.
Would a ...
1) link to http://wiki.xen.org/wiki/Xen_4.x_Manuals instead of 
http://wiki.xen.org/wiki/Category:Manual be better?
2) We could move http://wiki.xen.org/wiki/Xen_Beginners_Guide one up - 
it is a step-by-step tutorial to set up Xen 4 with Squeeze

Part of the problem is that there is a lot of stuff and it is hard to 
choose what is relevant

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:55:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:55: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 1ScIZW-0007gX-4k; Wed, 06 Jun 2012 15:54:58 +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 1ScIZU-0007gO-3y
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 15:54:56 +0000
Received: from [85.158.143.99:60900] by server-2.bemta-4.messagelabs.com id
	CD/85-17938-F4D7FCF4; Wed, 06 Jun 2012 15:54:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1338998091!26278944!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11816 invoked from network); 6 Jun 2012 15:54:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 15:54:52 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69j6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-10.vodafone-net.de [80.226.24.10])
	by smtp.strato.de (jorabe mo66) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L009cco56EH1cT
	for <xen-devel@lists.xensource.com>;
	Wed, 6 Jun 2012 17:54:49 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 636BF18637
	for <xen-devel@lists.xensource.com>;
	Wed,  6 Jun 2012 17:54:47 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 0e4a303989d132ca49c77ff6b7cbebb8f501efaa
Message-Id: <0e4a303989d132ca49c7.1338998070@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 06 Jun 2012 17:54:30 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1338998032 -7200
# Node ID 0e4a303989d132ca49c77ff6b7cbebb8f501efaa
# Parent  b5411db463770c9e11ac687fd80b0947b11fa5ca
xl.cfg: document the cpuid= option

v2:
 - describe libxl syntax before xend syntax
 - add wikipedia link

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

diff -r b5411db46377 -r 0e4a303989d1 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -969,9 +969,53 @@ XXX
 
 XXX
 
-=item B<cpuid=XXX>
+=item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
 
-XXX
+Configure the value returned when a guest executes CPUID instruction.
+Two versions of config syntax are recognized: libxl and xend.
+
+The libxl syntax is a comma separated list of key=value pairs, preceded by the
+word "host". A few keys take a numerical value, all others take a single
+character which describes what to do with the feature bit.
+
+Possible values for a single feature bit:
+  '1' -> force the corresponding bit to 1
+  '0' -> force to 0
+  'x' -> Get a safe value (pass through and mask with the default policy)
+  'k' -> pass through the host bit value
+  's' -> as 'k' but preserve across save/restore and migration (not implemented)
+
+List of keys taking a value:
+apicidsize brandid clflush family localapicid maxleaf model nc proccount procpkg
+stepping
+
+List of keys taking a character:
+3dnow 3dnowext 3dnowprefetch abm acpi aes altmovcr8 apic avx clfsh cmov
+cmplegacy cmpxchg16 cmpxchg8 cntxid dca de ds dscpl dtes64 est extapic f16c
+ffxsr fma4 fpu fxsr htt hypervisor ia64 ibs lahfsahf lm lwp mca mce misalignsse
+mmx mmxext monitor movbe msr mtrr nodeid nx osvw osxsave pae page1gb pat pbe
+pclmulqdq pdcm pge popcnt pse pse36 psn rdtscp skinit smx ss sse sse2 sse3
+sse4.1 sse4.2 sse4a ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips
+svm_pausefilt svm_tscrate svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc
+vme vmx wdt x2apic xop xsave xtpr
+
+The xend syntax is a list of values in the form of
+'leafnum:register=bitstring,register=bitstring'
+  "leafnum" is the requested function,
+  "register" is the response register to modify
+  "bitstring" represents all bits in the register, its length must be 32 chars.
+  Each successive character represent a lesser-significant bit, possible values
+  are listed above in the libxl section.
+
+Example to hide two features from the guest: 'tm', which is bit #29 in EDX, and
+'pni' (SSE3), which is bit #0 in ECX:
+
+xend: [ '1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0,edx=xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' ]
+
+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_s3=BOOLEAN>
 

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:55:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15:55: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 1ScIZW-0007gX-4k; Wed, 06 Jun 2012 15:54:58 +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 1ScIZU-0007gO-3y
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 15:54:56 +0000
Received: from [85.158.143.99:60900] by server-2.bemta-4.messagelabs.com id
	CD/85-17938-F4D7FCF4; Wed, 06 Jun 2012 15:54:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1338998091!26278944!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11816 invoked from network); 6 Jun 2012 15:54:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 15:54:52 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69j6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-10.vodafone-net.de [80.226.24.10])
	by smtp.strato.de (jorabe mo66) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L009cco56EH1cT
	for <xen-devel@lists.xensource.com>;
	Wed, 6 Jun 2012 17:54:49 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 636BF18637
	for <xen-devel@lists.xensource.com>;
	Wed,  6 Jun 2012 17:54:47 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 0e4a303989d132ca49c77ff6b7cbebb8f501efaa
Message-Id: <0e4a303989d132ca49c7.1338998070@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 06 Jun 2012 17:54:30 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1338998032 -7200
# Node ID 0e4a303989d132ca49c77ff6b7cbebb8f501efaa
# Parent  b5411db463770c9e11ac687fd80b0947b11fa5ca
xl.cfg: document the cpuid= option

v2:
 - describe libxl syntax before xend syntax
 - add wikipedia link

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

diff -r b5411db46377 -r 0e4a303989d1 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -969,9 +969,53 @@ XXX
 
 XXX
 
-=item B<cpuid=XXX>
+=item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
 
-XXX
+Configure the value returned when a guest executes CPUID instruction.
+Two versions of config syntax are recognized: libxl and xend.
+
+The libxl syntax is a comma separated list of key=value pairs, preceded by the
+word "host". A few keys take a numerical value, all others take a single
+character which describes what to do with the feature bit.
+
+Possible values for a single feature bit:
+  '1' -> force the corresponding bit to 1
+  '0' -> force to 0
+  'x' -> Get a safe value (pass through and mask with the default policy)
+  'k' -> pass through the host bit value
+  's' -> as 'k' but preserve across save/restore and migration (not implemented)
+
+List of keys taking a value:
+apicidsize brandid clflush family localapicid maxleaf model nc proccount procpkg
+stepping
+
+List of keys taking a character:
+3dnow 3dnowext 3dnowprefetch abm acpi aes altmovcr8 apic avx clfsh cmov
+cmplegacy cmpxchg16 cmpxchg8 cntxid dca de ds dscpl dtes64 est extapic f16c
+ffxsr fma4 fpu fxsr htt hypervisor ia64 ibs lahfsahf lm lwp mca mce misalignsse
+mmx mmxext monitor movbe msr mtrr nodeid nx osvw osxsave pae page1gb pat pbe
+pclmulqdq pdcm pge popcnt pse pse36 psn rdtscp skinit smx ss sse sse2 sse3
+sse4.1 sse4.2 sse4a ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips
+svm_pausefilt svm_tscrate svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc
+vme vmx wdt x2apic xop xsave xtpr
+
+The xend syntax is a list of values in the form of
+'leafnum:register=bitstring,register=bitstring'
+  "leafnum" is the requested function,
+  "register" is the response register to modify
+  "bitstring" represents all bits in the register, its length must be 32 chars.
+  Each successive character represent a lesser-significant bit, possible values
+  are listed above in the libxl section.
+
+Example to hide two features from the guest: 'tm', which is bit #29 in EDX, and
+'pni' (SSE3), which is bit #0 in ECX:
+
+xend: [ '1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0,edx=xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' ]
+
+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_s3=BOOLEAN>
 

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 15:55:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScIaG-0007k5-Ic; Wed, 06 Jun 2012 15:55: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 1ScIaG-0007js-2l
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 15:55:44 +0000
Received: from [85.158.139.83:42153] by server-10.bemta-5.messagelabs.com id
	A8/FB-23803-F7D7FCF4; Wed, 06 Jun 2012 15:55:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338998142!29582979!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27288 invoked from network); 6 Jun 2012 15:55:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 15:55:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69j6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-10.vodafone-net.de [80.226.24.10])
	by smtp.strato.de (joses mo47) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K07490o56DdQ08 ;
	Wed, 6 Jun 2012 17:55:38 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 3B15C18638; Wed,  6 Jun 2012 17:55:36 +0200 (CEST)
Date: Wed, 6 Jun 2012 17:55:36 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606155536.GA8015@aepfle.de>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
	<1338977759.32319.43.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338977759.32319.43.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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 Wed, Jun 06, Ian Campbell wrote:

> On Wed, 2012-06-06 at 10:20 +0100, George Dunlap wrote:
> > On Fri, Jun 1, 2012 at 6:48 PM, Olaf Hering <olaf@aepfle.de> wrote:

> > > Two config versions of config syntax are
> > > +recognized: xend and libxl.
> > It's not clear from this text -- will libxl understand the xend format?
> 
> Yes, although for clarity the xl one ought to be preferred IMHO and
> therefore made more prominent than the xend one i.e. be described first
> and completely rather than referencing to the xend syntax (which can
> refer to the xl stuff if necessary).

Thanks for the input. I sent out a second version 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 Wed Jun 06 15:55:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 15: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 1ScIaG-0007k5-Ic; Wed, 06 Jun 2012 15:55: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 1ScIaG-0007js-2l
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 15:55:44 +0000
Received: from [85.158.139.83:42153] by server-10.bemta-5.messagelabs.com id
	A8/FB-23803-F7D7FCF4; Wed, 06 Jun 2012 15:55:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1338998142!29582979!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjc2MzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27288 invoked from network); 6 Jun 2012 15:55:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 15:55:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69j6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-10.vodafone-net.de [80.226.24.10])
	by smtp.strato.de (joses mo47) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K07490o56DdQ08 ;
	Wed, 6 Jun 2012 17:55:38 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 3B15C18638; Wed,  6 Jun 2012 17:55:36 +0200 (CEST)
Date: Wed, 6 Jun 2012 17:55:36 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606155536.GA8015@aepfle.de>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
	<1338977759.32319.43.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338977759.32319.43.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <dunlapg@umich.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= 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 Wed, Jun 06, Ian Campbell wrote:

> On Wed, 2012-06-06 at 10:20 +0100, George Dunlap wrote:
> > On Fri, Jun 1, 2012 at 6:48 PM, Olaf Hering <olaf@aepfle.de> wrote:

> > > Two config versions of config syntax are
> > > +recognized: xend and libxl.
> > It's not clear from this text -- will libxl understand the xend format?
> 
> Yes, although for clarity the xl one ought to be preferred IMHO and
> therefore made more prominent than the xend one i.e. be described first
> and completely rather than referencing to the xend syntax (which can
> refer to the xl stuff if necessary).

Thanks for the input. I sent out a second version 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 Wed Jun 06 16:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScIqe-0000VB-RK; Wed, 06 Jun 2012 16:12:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sr@swisscenter.com>) id 1ScIqd-0000V6-4C
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 16:12:39 +0000
Received: from [85.158.138.51:19611] by server-12.bemta-3.messagelabs.com id
	FB/22-24185-6718FCF4; Wed, 06 Jun 2012 16:12:38 +0000
X-Env-Sender: sr@swisscenter.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338999157!31182471!1
X-Originating-IP: [94.103.96.90]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17486 invoked from network); 6 Jun 2012 16:12:37 -0000
Received: from mail.swisslink.ch (HELO mail.swisslink.ch) (94.103.96.90)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 16:12:37 -0000
Received: from [10.8.0.18] (gate.swisslink.ch [62.2.195.10])
	(authenticated bits=0)
	by mail.swisslink.ch (8.14.3/8.14.3/Debian-9.4) with ESMTP id
	q56GCaZ2016241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Wed, 6 Jun 2012 18:12:37 +0200
Message-ID: <4FCF8169.20409@swisscenter.com>
Date: Wed, 06 Jun 2012 18:12:25 +0200
From: =?ISO-8859-1?Q?S=E9bastien_Riccio?= <sr@swisscenter.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Virus-Scanned: clamav-milter 0.97.3 at mail
X-Virus-Status: Clean
Subject: [Xen-devel] Any plans to support VHDX via blktap?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2416391300056905289=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2416391300056905289==
Content-Type: multipart/alternative;
 boundary="------------010306090706080503030002"

This is a multi-part message in MIME format.
--------------010306090706080503030002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I don't know where this question should be posted, but I'll try here.

Is there any plan for XenServer/XCP/Kronos to support the vhdx format 
that should get rid of the 2tb limit for a single volume ?

As seen somewhere on the interweb:

Now with VHDX Microsoft kills this limitations and brings some other 
improvements:

  * Supports up to 16TB size
  * Supports larger block file size
  * improved performance
  * improved corruption resistance

Cheers,
Sébastien


--------------010306090706080503030002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    I don't know where this question should be posted, but I'll try
    here. <br>
    <br>
    Is there any plan for XenServer/XCP/Kronos to support the vhdx
    format that should get rid of the 2tb limit for a single volume ?<br>
    <br>
    As seen somewhere on the interweb:<br>
    <br>
    Now with VHDX Microsoft kills this limitations and brings some other
    improvements:<br>
    <ul>
      <li>Supports up to 16TB size</li>
      <li>Supports larger block file size</li>
      <li>improved performance</li>
      <li>improved corruption resistance</li>
    </ul>
    Cheers,<br>
    S&eacute;bastien<br>
    <br>
  </body>
</html>

--------------010306090706080503030002--


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

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

--===============2416391300056905289==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 16:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScIqe-0000VB-RK; Wed, 06 Jun 2012 16:12:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sr@swisscenter.com>) id 1ScIqd-0000V6-4C
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 16:12:39 +0000
Received: from [85.158.138.51:19611] by server-12.bemta-3.messagelabs.com id
	FB/22-24185-6718FCF4; Wed, 06 Jun 2012 16:12:38 +0000
X-Env-Sender: sr@swisscenter.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1338999157!31182471!1
X-Originating-IP: [94.103.96.90]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17486 invoked from network); 6 Jun 2012 16:12:37 -0000
Received: from mail.swisslink.ch (HELO mail.swisslink.ch) (94.103.96.90)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 16:12:37 -0000
Received: from [10.8.0.18] (gate.swisslink.ch [62.2.195.10])
	(authenticated bits=0)
	by mail.swisslink.ch (8.14.3/8.14.3/Debian-9.4) with ESMTP id
	q56GCaZ2016241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Wed, 6 Jun 2012 18:12:37 +0200
Message-ID: <4FCF8169.20409@swisscenter.com>
Date: Wed, 06 Jun 2012 18:12:25 +0200
From: =?ISO-8859-1?Q?S=E9bastien_Riccio?= <sr@swisscenter.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Virus-Scanned: clamav-milter 0.97.3 at mail
X-Virus-Status: Clean
Subject: [Xen-devel] Any plans to support VHDX via blktap?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2416391300056905289=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2416391300056905289==
Content-Type: multipart/alternative;
 boundary="------------010306090706080503030002"

This is a multi-part message in MIME format.
--------------010306090706080503030002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I don't know where this question should be posted, but I'll try here.

Is there any plan for XenServer/XCP/Kronos to support the vhdx format 
that should get rid of the 2tb limit for a single volume ?

As seen somewhere on the interweb:

Now with VHDX Microsoft kills this limitations and brings some other 
improvements:

  * Supports up to 16TB size
  * Supports larger block file size
  * improved performance
  * improved corruption resistance

Cheers,
Sébastien


--------------010306090706080503030002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    I don't know where this question should be posted, but I'll try
    here. <br>
    <br>
    Is there any plan for XenServer/XCP/Kronos to support the vhdx
    format that should get rid of the 2tb limit for a single volume ?<br>
    <br>
    As seen somewhere on the interweb:<br>
    <br>
    Now with VHDX Microsoft kills this limitations and brings some other
    improvements:<br>
    <ul>
      <li>Supports up to 16TB size</li>
      <li>Supports larger block file size</li>
      <li>improved performance</li>
      <li>improved corruption resistance</li>
    </ul>
    Cheers,<br>
    S&eacute;bastien<br>
    <br>
  </body>
</html>

--------------010306090706080503030002--


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

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

--===============2416391300056905289==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 16:14:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16:14: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 1ScIrx-0000Yq-AE; Wed, 06 Jun 2012 16:14: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 1ScIrw-0000Yh-6D
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:14:00 +0000
Received: from [85.158.143.35:8295] by server-1.bemta-4.messagelabs.com id
	9E/09-10042-7C18FCF4; Wed, 06 Jun 2012 16:13:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338999238!19066721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 6 Jun 2012 16:13:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 16:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12863982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 16:13:58 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 17:13:59 +0100
Date: Wed, 6 Jun 2012 17:13:52 +0100
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: <1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061713410.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.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] [PATCH 16/38] arm: Add simple cpu_{sibling,
 core}_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, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/dummy.S   |    2 --
>  xen/arch/arm/setup.c   |    7 +++++++
>  xen/arch/arm/smpboot.c |    5 +++++
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index c001e8d..03f7489 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
>  x:	mov pc, lr
>  	
>  /* SMP support */
> -DUMMY(per_cpu__cpu_core_mask);
> -DUMMY(per_cpu__cpu_sibling_mask);
>  DUMMY(node_online_map);
>  DUMMY(smp_send_state_dump);
>  
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 81ababb..b0cfacc 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
>          }
>      }
>  
> +    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
> +         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
> +        BUG();
> +
> +    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
> +    cpumask_clear(per_cpu(cpu_core_mask, 0));
> +
>      printk("Brought up %ld CPUs\n", (long)num_online_cpus());
>      /* TODO: smp_cpus_done(); */
>  
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index ea05afc..8517d86 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -52,6 +52,11 @@ unsigned long __initdata ready_cpus = 0;
>  
>  /* ID of the PCPU we're running on */
>  DEFINE_PER_CPU(unsigned int, cpu_id);
> +/* XXX these seem awefully x86ish... */
> +/* representing HT siblings of each logical CPU */
> +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
> +/* representing HT and core siblings of each logical CPU */
> +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
>  
>  void __init
>  smp_prepare_cpus (unsigned int max_cpus)
> -- 
> 1.7.9.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 Wed Jun 06 16:14:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16:14: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 1ScIrx-0000Yq-AE; Wed, 06 Jun 2012 16:14: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 1ScIrw-0000Yh-6D
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:14:00 +0000
Received: from [85.158.143.35:8295] by server-1.bemta-4.messagelabs.com id
	9E/09-10042-7C18FCF4; Wed, 06 Jun 2012 16:13:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1338999238!19066721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 6 Jun 2012 16:13:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 16:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12863982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 16:13:58 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 17:13:59 +0100
Date: Wed, 6 Jun 2012 17:13:52 +0100
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: <1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061713410.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.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] [PATCH 16/38] arm: Add simple cpu_{sibling,
 core}_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, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/dummy.S   |    2 --
>  xen/arch/arm/setup.c   |    7 +++++++
>  xen/arch/arm/smpboot.c |    5 +++++
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index c001e8d..03f7489 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
>  x:	mov pc, lr
>  	
>  /* SMP support */
> -DUMMY(per_cpu__cpu_core_mask);
> -DUMMY(per_cpu__cpu_sibling_mask);
>  DUMMY(node_online_map);
>  DUMMY(smp_send_state_dump);
>  
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 81ababb..b0cfacc 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
>          }
>      }
>  
> +    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
> +         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
> +        BUG();
> +
> +    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
> +    cpumask_clear(per_cpu(cpu_core_mask, 0));
> +
>      printk("Brought up %ld CPUs\n", (long)num_online_cpus());
>      /* TODO: smp_cpus_done(); */
>  
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index ea05afc..8517d86 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -52,6 +52,11 @@ unsigned long __initdata ready_cpus = 0;
>  
>  /* ID of the PCPU we're running on */
>  DEFINE_PER_CPU(unsigned int, cpu_id);
> +/* XXX these seem awefully x86ish... */
> +/* representing HT siblings of each logical CPU */
> +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
> +/* representing HT and core siblings of each logical CPU */
> +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
>  
>  void __init
>  smp_prepare_cpus (unsigned int max_cpus)
> -- 
> 1.7.9.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 Wed Jun 06 16:22:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16: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 1ScIzn-0000ru-7x; Wed, 06 Jun 2012 16:22:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1ScIzl-0000rp-IS
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:22:05 +0000
Received: from [85.158.143.35:18548] by server-1.bemta-4.messagelabs.com id
	56/F1-10042-CA38FCF4; Wed, 06 Jun 2012 16:22:04 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338999721!8663897!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6362 invoked from network); 6 Jun 2012 16:22:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 16:22:02 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56GLx23029571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 6 Jun 2012 16:22:00 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
	q56GLxOL022360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 6 Jun 2012 16:21:59 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
	q56GLx99004376
	for <xen-devel@lists.xen.org>; Wed, 6 Jun 2012 11:21:59 -0500
MIME-Version: 1.0
Message-ID: <1733e817-76b1-45b3-bb1b-e2d11922496f@default>
Date: Wed, 6 Jun 2012 09:21:49 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Transcendent Memory 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

FYI, it's been a long road, but the last guest-side piece
(aka frontswap) necessary for Xen transcendent memory
("tmem") support was merged into Linux 3.5-rc1 by Linus
this week.

So it should soon be coming to a distro near you.  If
you should want to play with it today, Oracle Linux
with UEK2 supports tmem and is downloadable today (free).

Interestingly, an RFC was also just posted on lkml for
tmem support for KVM.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 16:22:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16: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 1ScIzn-0000ru-7x; Wed, 06 Jun 2012 16:22:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1ScIzl-0000rp-IS
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:22:05 +0000
Received: from [85.158.143.35:18548] by server-1.bemta-4.messagelabs.com id
	56/F1-10042-CA38FCF4; Wed, 06 Jun 2012 16:22:04 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1338999721!8663897!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6362 invoked from network); 6 Jun 2012 16:22:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 16:22:02 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56GLx23029571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 6 Jun 2012 16:22:00 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
	q56GLxOL022360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 6 Jun 2012 16:21:59 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
	q56GLx99004376
	for <xen-devel@lists.xen.org>; Wed, 6 Jun 2012 11:21:59 -0500
MIME-Version: 1.0
Message-ID: <1733e817-76b1-45b3-bb1b-e2d11922496f@default>
Date: Wed, 6 Jun 2012 09:21:49 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Transcendent Memory 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

FYI, it's been a long road, but the last guest-side piece
(aka frontswap) necessary for Xen transcendent memory
("tmem") support was merged into Linux 3.5-rc1 by Linus
this week.

So it should soon be coming to a distro near you.  If
you should want to play with it today, Oracle Linux
with UEK2 supports tmem and is downloadable today (free).

Interestingly, an RFC was also just posted on lkml for
tmem support for KVM.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 16:28:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16:28: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 1ScJ58-0000ze-0g; Wed, 06 Jun 2012 16:27: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 1ScJ56-0000zY-BM
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:27:36 +0000
Received: from [85.158.143.35:51423] by server-2.bemta-4.messagelabs.com id
	BB/8E-17938-7F48FCF4; Wed, 06 Jun 2012 16:27:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339000055!8664610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27494 invoked from network); 6 Jun 2012 16:27:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 16:27:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12864315"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 16:27:32 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 17:27:32 +0100
Date: Wed, 6 Jun 2012 17:27:25 +0100
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: <1338565207-2888-17-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061725020.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-17-git-send-email-ian.campbell@citrix.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] [PATCH 17/38] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/p2m.c         |   15 ++++++++-------
>  xen/include/asm-arm/page.h |    6 ++++--
>  2 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 9b40e93..46c6f17 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -148,7 +148,7 @@ static int p2m_create_entry(struct domain *d,
>      clear_page(p);
>      unmap_domain_page(p);
>  
> -    pte = mfn_to_p2m_entry(page_to_mfn(page));
> +    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
>  
>      write_pte(entry, pte);
>  

This works because p2m_create_entry is always called to create first or
second level entries only.
Maybe we should rename p2m_create_entry to p2m_create_table_entry for
clarity? Or add a comment?


> @@ -159,7 +159,8 @@ static int create_p2m_entries(struct domain *d,
>                       int alloc,
>                       paddr_t start_gpaddr,
>                       paddr_t end_gpaddr,
> -                     paddr_t maddr)
> +                     paddr_t maddr,
> +                     int mattr)
>  {
>      int rc;
>      struct p2m_domain *p2m = &d->arch.p2m;
> @@ -235,11 +236,11 @@ static int create_p2m_entries(struct domain *d,
>                  goto out;
>              }
>  
> -            pte = mfn_to_p2m_entry(page_to_mfn(page));
> +            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
>  
>              write_pte(&third[third_table_offset(addr)], pte);
>          } else {
> -            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
> +            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
>              write_pte(&third[third_table_offset(addr)], pte);
>              maddr += PAGE_SIZE;
>          }
> @@ -263,7 +264,7 @@ int p2m_populate_ram(struct domain *d,
>                       paddr_t start,
>                       paddr_t end)
>  {
> -    return create_p2m_entries(d, 1, start, end, 0);
> +    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
>  }
>  
>  int map_mmio_regions(struct domain *d,
> @@ -271,7 +272,7 @@ int map_mmio_regions(struct domain *d,
>                       paddr_t end_gaddr,
>                       paddr_t maddr)
>  {
> -    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> +    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
>  }
>  
>  int guest_physmap_add_page(struct domain *d,
> @@ -281,7 +282,7 @@ int guest_physmap_add_page(struct domain *d,
>  {
>      return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
>                                (gpfn + (1<<page_order)) << PAGE_SHIFT,
> -                              mfn << PAGE_SHIFT);
> +                              mfn << PAGE_SHIFT, MATTR_MEM);
>  }
>  
>  void guest_physmap_remove_page(struct domain *d,
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index c7b6530..bb1729a 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -46,6 +46,8 @@
>  #define DEV_WC        BUFFERABLE
>  #define DEV_CACHED    WRITEBACK
>  
> +#define MATTR_DEV     0x1
> +#define MATTR_MEM     0xf
>  
>  #ifndef __ASSEMBLY__
>  
> @@ -169,7 +171,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
>      return e;
>  }
>  
> -static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
> +static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
>  {
>      paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
>      lpae_t e = (lpae_t) {
> @@ -178,7 +180,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
>          .p2m.sh = LPAE_SH_OUTER,
>          .p2m.write = 1,
>          .p2m.read = 1,
> -        .p2m.mattr = 0xf,
> +        .p2m.mattr = mattr,
>          .p2m.table = 1,
>          .p2m.valid = 1,
>      };

the rest of the patch is fine

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 16:28:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16:28: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 1ScJ58-0000ze-0g; Wed, 06 Jun 2012 16:27: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 1ScJ56-0000zY-BM
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:27:36 +0000
Received: from [85.158.143.35:51423] by server-2.bemta-4.messagelabs.com id
	BB/8E-17938-7F48FCF4; Wed, 06 Jun 2012 16:27:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339000055!8664610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27494 invoked from network); 6 Jun 2012 16:27:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 16:27:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12864315"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 16:27:32 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 17:27:32 +0100
Date: Wed, 6 Jun 2012 17:27:25 +0100
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: <1338565207-2888-17-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061725020.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-17-git-send-email-ian.campbell@citrix.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] [PATCH 17/38] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/p2m.c         |   15 ++++++++-------
>  xen/include/asm-arm/page.h |    6 ++++--
>  2 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 9b40e93..46c6f17 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -148,7 +148,7 @@ static int p2m_create_entry(struct domain *d,
>      clear_page(p);
>      unmap_domain_page(p);
>  
> -    pte = mfn_to_p2m_entry(page_to_mfn(page));
> +    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
>  
>      write_pte(entry, pte);
>  

This works because p2m_create_entry is always called to create first or
second level entries only.
Maybe we should rename p2m_create_entry to p2m_create_table_entry for
clarity? Or add a comment?


> @@ -159,7 +159,8 @@ static int create_p2m_entries(struct domain *d,
>                       int alloc,
>                       paddr_t start_gpaddr,
>                       paddr_t end_gpaddr,
> -                     paddr_t maddr)
> +                     paddr_t maddr,
> +                     int mattr)
>  {
>      int rc;
>      struct p2m_domain *p2m = &d->arch.p2m;
> @@ -235,11 +236,11 @@ static int create_p2m_entries(struct domain *d,
>                  goto out;
>              }
>  
> -            pte = mfn_to_p2m_entry(page_to_mfn(page));
> +            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
>  
>              write_pte(&third[third_table_offset(addr)], pte);
>          } else {
> -            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
> +            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
>              write_pte(&third[third_table_offset(addr)], pte);
>              maddr += PAGE_SIZE;
>          }
> @@ -263,7 +264,7 @@ int p2m_populate_ram(struct domain *d,
>                       paddr_t start,
>                       paddr_t end)
>  {
> -    return create_p2m_entries(d, 1, start, end, 0);
> +    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
>  }
>  
>  int map_mmio_regions(struct domain *d,
> @@ -271,7 +272,7 @@ int map_mmio_regions(struct domain *d,
>                       paddr_t end_gaddr,
>                       paddr_t maddr)
>  {
> -    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> +    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
>  }
>  
>  int guest_physmap_add_page(struct domain *d,
> @@ -281,7 +282,7 @@ int guest_physmap_add_page(struct domain *d,
>  {
>      return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
>                                (gpfn + (1<<page_order)) << PAGE_SHIFT,
> -                              mfn << PAGE_SHIFT);
> +                              mfn << PAGE_SHIFT, MATTR_MEM);
>  }
>  
>  void guest_physmap_remove_page(struct domain *d,
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index c7b6530..bb1729a 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -46,6 +46,8 @@
>  #define DEV_WC        BUFFERABLE
>  #define DEV_CACHED    WRITEBACK
>  
> +#define MATTR_DEV     0x1
> +#define MATTR_MEM     0xf
>  
>  #ifndef __ASSEMBLY__
>  
> @@ -169,7 +171,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
>      return e;
>  }
>  
> -static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
> +static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
>  {
>      paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
>      lpae_t e = (lpae_t) {
> @@ -178,7 +180,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
>          .p2m.sh = LPAE_SH_OUTER,
>          .p2m.write = 1,
>          .p2m.read = 1,
> -        .p2m.mattr = 0xf,
> +        .p2m.mattr = mattr,
>          .p2m.table = 1,
>          .p2m.valid = 1,
>      };

the rest of the patch is fine

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 16:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16: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 1ScJYQ-0001io-BE; Wed, 06 Jun 2012 16:57:54 +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 1ScJYO-0001ij-KO
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:57:52 +0000
Received: from [193.109.254.147:23280] by server-4.bemta-14.messagelabs.com id
	3E/9A-27598-F0C8FCF4; Wed, 06 Jun 2012 16:57:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339001871!6265353!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31521 invoked from network); 6 Jun 2012 16:57:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 16:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12864769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 16:57:34 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 17:57:34 +0100
Date: Wed, 6 Jun 2012 17:57:27 +0100
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: <1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061739130.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.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] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> This is not interended to provide a full emulation, but rather just enough to
> satisfy the use made by Linux' boot time decompressor code (which is too early
> for DT etc)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/Makefile        |    1 +
>  xen/arch/arm/domain.c        |    4 +
>  xen/arch/arm/io.c            |    1 +
>  xen/arch/arm/io.h            |    1 +
>  xen/arch/arm/vpl011.c        |  155 ++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/vpl011.h        |   34 +++++++++
>  xen/include/asm-arm/domain.h |    8 ++
>  7 files changed, 204 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/vpl011.c
>  create mode 100644 xen/arch/arm/vpl011.h
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 9440a21..5a87ba6 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -25,6 +25,7 @@ obj-y += shutdown.o
>  obj-y += traps.o
>  obj-y += vgic.o
>  obj-y += vtimer.o
> +obj-y += vpl011.o
>  
>  #obj-bin-y += ....o
>  
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index e867cb2..d830980 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -13,6 +13,7 @@
>  
>  #include "gic.h"
>  #include "vtimer.h"
> +#include "vpl011.h"
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
> @@ -201,6 +202,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = domain_vgic_init(d)) != 0 )
>          goto fail;
>  
> +    if ( (rc = domain_uart0_init(d)) != 0 )
> +        goto fail;
> +
>      if ( !is_idle_domain(d) )
>      {
>          rc = -ENOMEM;
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index 4461225..18f6164 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -25,6 +25,7 @@
>  static const struct mmio_handler *const mmio_handlers[] =
>  {
>      &vgic_distr_mmio_handler,
> +    &uart0_mmio_handler,
>  };
>  #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
>  
> diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
> index 8cc5ca7..9a507f5 100644
> --- a/xen/arch/arm/io.h
> +++ b/xen/arch/arm/io.h
> @@ -40,6 +40,7 @@ struct mmio_handler {
>  };
>  
>  extern const struct mmio_handler vgic_distr_mmio_handler;
> +extern const struct mmio_handler uart0_mmio_handler;
>  
>  extern int handle_mmio(mmio_info_t *info);
>  
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> new file mode 100644
> index 0000000..1491dcc
> --- /dev/null
> +++ b/xen/arch/arm/vpl011.c
> @@ -0,0 +1,155 @@
> +/*
> + * xen/arch/arm/vpl011.c
> + *
> + * ARM PL011 UART Emulator (DEBUG)
> + *
> + * 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.
> + */
> +
> +/*
> + * This is not intended to be a full emulation of a PL011
> + * device. Rather it is intended to provide a sufficient veneer of one
> + * that early code (such as Linux's boot time decompressor) which
> + * hardcodes output directly to such a device are able to make progress.
> + *
> + * This device is not intended to be enumerable or exposed to the OS
> + * (e.g. via Device Tree).
> + */
> +
> +#include <xen/config.h>
> +#include <xen/lib.h>
> +#include <xen/sched.h>
> +#include <xen/errno.h>
> +#include <xen/ctype.h>
> +
> +#include "io.h"
> +
> +#define UART0_BASE_ADDRESS 0x1c090000
> +
> +#define UARTDR 0x000
> +#define UARTFR 0x018
> +
> +int domain_uart0_init(struct domain *d)
> +{
> +    int rc;
> +    if ( d->domain_id == 0 )
> +        return 0;
> +
> +    spin_lock_init(&d->arch.uart0.lock);
> +    d->arch.uart0.idx = 0;
> +
> +    rc = -ENOMEM;
> +    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
> +    if ( !d->arch.uart0.buf )
> +        goto out;
> +
> +    rc = 0;
> +out:
> +    return rc;
> +}
> +
> +static void uart0_print_char(char c)
> +{
> +    struct vpl011 *uart = &current->domain->arch.uart0;
> +
> +    /* Accept only printable characters, newline, and horizontal tab. */
> +    if ( !isprint(c) && (c != '\n') && (c != '\t') )
> +        return ;
> +
> +    spin_lock(&uart->lock);
> +    uart->buf[uart->idx++] = c;
> +    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
> +    {
> +        if ( c != '\n' )
> +            uart->buf[uart->idx++] = '\n';
> +        uart->buf[uart->idx] = '\0';
> +        printk(XENLOG_G_DEBUG "DOM%u: %s",
> +               current->domain->domain_id, uart->buf);
> +        uart->idx = 0;
> +    }
> +    spin_unlock(&uart->lock);
> +}
> +
> +static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
> +{
> +    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
> +}

maybe we need UART0_BASE_ADDRESS_START and UART0_BASE_ADDRESS_END
instead of having an arbitrary +65536


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 16:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 16: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 1ScJYQ-0001io-BE; Wed, 06 Jun 2012 16:57:54 +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 1ScJYO-0001ij-KO
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 16:57:52 +0000
Received: from [193.109.254.147:23280] by server-4.bemta-14.messagelabs.com id
	3E/9A-27598-F0C8FCF4; Wed, 06 Jun 2012 16:57:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339001871!6265353!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31521 invoked from network); 6 Jun 2012 16:57:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 16:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12864769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 16:57:34 +0000
Received: from sstabellini-Precision-WorkStation-T3500.local (10.80.238.169)
	by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 17:57:34 +0100
Date: Wed, 6 Jun 2012 17:57:27 +0100
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: <1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061739130.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.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] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> This is not interended to provide a full emulation, but rather just enough to
> satisfy the use made by Linux' boot time decompressor code (which is too early
> for DT etc)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/Makefile        |    1 +
>  xen/arch/arm/domain.c        |    4 +
>  xen/arch/arm/io.c            |    1 +
>  xen/arch/arm/io.h            |    1 +
>  xen/arch/arm/vpl011.c        |  155 ++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/vpl011.h        |   34 +++++++++
>  xen/include/asm-arm/domain.h |    8 ++
>  7 files changed, 204 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/vpl011.c
>  create mode 100644 xen/arch/arm/vpl011.h
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 9440a21..5a87ba6 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -25,6 +25,7 @@ obj-y += shutdown.o
>  obj-y += traps.o
>  obj-y += vgic.o
>  obj-y += vtimer.o
> +obj-y += vpl011.o
>  
>  #obj-bin-y += ....o
>  
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index e867cb2..d830980 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -13,6 +13,7 @@
>  
>  #include "gic.h"
>  #include "vtimer.h"
> +#include "vpl011.h"
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
> @@ -201,6 +202,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = domain_vgic_init(d)) != 0 )
>          goto fail;
>  
> +    if ( (rc = domain_uart0_init(d)) != 0 )
> +        goto fail;
> +
>      if ( !is_idle_domain(d) )
>      {
>          rc = -ENOMEM;
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index 4461225..18f6164 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -25,6 +25,7 @@
>  static const struct mmio_handler *const mmio_handlers[] =
>  {
>      &vgic_distr_mmio_handler,
> +    &uart0_mmio_handler,
>  };
>  #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
>  
> diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
> index 8cc5ca7..9a507f5 100644
> --- a/xen/arch/arm/io.h
> +++ b/xen/arch/arm/io.h
> @@ -40,6 +40,7 @@ struct mmio_handler {
>  };
>  
>  extern const struct mmio_handler vgic_distr_mmio_handler;
> +extern const struct mmio_handler uart0_mmio_handler;
>  
>  extern int handle_mmio(mmio_info_t *info);
>  
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> new file mode 100644
> index 0000000..1491dcc
> --- /dev/null
> +++ b/xen/arch/arm/vpl011.c
> @@ -0,0 +1,155 @@
> +/*
> + * xen/arch/arm/vpl011.c
> + *
> + * ARM PL011 UART Emulator (DEBUG)
> + *
> + * 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.
> + */
> +
> +/*
> + * This is not intended to be a full emulation of a PL011
> + * device. Rather it is intended to provide a sufficient veneer of one
> + * that early code (such as Linux's boot time decompressor) which
> + * hardcodes output directly to such a device are able to make progress.
> + *
> + * This device is not intended to be enumerable or exposed to the OS
> + * (e.g. via Device Tree).
> + */
> +
> +#include <xen/config.h>
> +#include <xen/lib.h>
> +#include <xen/sched.h>
> +#include <xen/errno.h>
> +#include <xen/ctype.h>
> +
> +#include "io.h"
> +
> +#define UART0_BASE_ADDRESS 0x1c090000
> +
> +#define UARTDR 0x000
> +#define UARTFR 0x018
> +
> +int domain_uart0_init(struct domain *d)
> +{
> +    int rc;
> +    if ( d->domain_id == 0 )
> +        return 0;
> +
> +    spin_lock_init(&d->arch.uart0.lock);
> +    d->arch.uart0.idx = 0;
> +
> +    rc = -ENOMEM;
> +    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
> +    if ( !d->arch.uart0.buf )
> +        goto out;
> +
> +    rc = 0;
> +out:
> +    return rc;
> +}
> +
> +static void uart0_print_char(char c)
> +{
> +    struct vpl011 *uart = &current->domain->arch.uart0;
> +
> +    /* Accept only printable characters, newline, and horizontal tab. */
> +    if ( !isprint(c) && (c != '\n') && (c != '\t') )
> +        return ;
> +
> +    spin_lock(&uart->lock);
> +    uart->buf[uart->idx++] = c;
> +    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
> +    {
> +        if ( c != '\n' )
> +            uart->buf[uart->idx++] = '\n';
> +        uart->buf[uart->idx] = '\0';
> +        printk(XENLOG_G_DEBUG "DOM%u: %s",
> +               current->domain->domain_id, uart->buf);
> +        uart->idx = 0;
> +    }
> +    spin_unlock(&uart->lock);
> +}
> +
> +static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
> +{
> +    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
> +}

maybe we need UART0_BASE_ADDRESS_START and UART0_BASE_ADDRESS_END
instead of having an arbitrary +65536


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 17:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:00: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 1ScJay-0001q5-Tl; Wed, 06 Jun 2012 17:00:32 +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 1ScJax-0001q0-Ey
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 17:00:31 +0000
Received: from [85.158.143.99:24037] by server-3.bemta-4.messagelabs.com id
	57/B3-29237-EAC8FCF4; Wed, 06 Jun 2012 17:00:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339002028!21833552!1
X-Originating-IP: [209.85.216.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24332 invoked from network); 6 Jun 2012 17:00:29 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:00:29 -0000
Received: by qady23 with SMTP id y23so4131350qad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 10:00:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=jdHNxUQ0atY3u2QcpBEiqTVlpL9G8EFPtBBzmGS6gfM=;
	b=bLt3pbXbOirRmurAEq6EjLsu//x17a5a7Qk/6sDsv0pJxsIz3swNLUf49gjKaPe4W+
	I/hCFcmiz10pd2bebxsuLogNSGkTC8oGcNsC4yA+LusvMx7MYbh5+60tH1MZr+Sh7OJr
	GqHCky4Fof/hXc+mIlh5YoUO/+0TmNEYsZLoPE8Kujm+lCJ6zgkYS036JqaMcZGrzHiO
	s9SuupiJcCCaUO/d7w3ci8PLYRpPvtx7T4jhUIA6Hi6wL0VAty31yISjNTZ8KrpLdafo
	mhwYMohd+NIFvem5bDFsriyY3DsRn7/Qj2U6lOPAdKtR2i+S9E8cC39pKz0UfEmPm8UV
	/Upw==
MIME-Version: 1.0
Received: by 10.229.134.193 with SMTP id k1mr862895qct.64.1339002027667; Wed,
	06 Jun 2012 10:00:27 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 10:00:27 -0700 (PDT)
In-Reply-To: <8884c4995307dc8664d5.1338462978@qabil.uk.xensource.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<8884c4995307dc8664d5.1338462978@qabil.uk.xensource.com>
Date: Wed, 6 Jun 2012 18:00:27 +0100
X-Google-Sender-Auth: 1sT143fdgnM2YXxnjI-eDr_aV8k
Message-ID: <CAFLBxZbBFJPd+j18skM3L4Bm2KR3Q39r1X7u016C-RzXZJJbag@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, George Dunlap <george.dunlap@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02 of 10] xenalyze: automatically generate
	dependencies
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, May 31, 2012 at 12:16 PM, David Vrabel <david.vrabel@citrix.com> wr=
ote:
> Use gcc's -MD and -MP options to automatically generate dependencies.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

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

>
> diff --git a/.hgignore b/.hgignore
> --- a/.hgignore
> +++ b/.hgignore
> @@ -1,3 +1,4 @@
> +.*\.d
> =A0.*\.o
> =A0xenalyze
> =A0dump-raw
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,5 +1,3 @@
> -CC =3D gcc
> -
> =A0CFLAGS +=3D -g -O2
> =A0CFLAGS +=3D -fno-strict-aliasing
> =A0CFLAGS +=3D -std=3Dgnu99
> @@ -7,22 +5,35 @@ CFLAGS +=3D -Wall -Wstrict-prototypes
> =A0CFLAGS +=3D -Wno-unused-value
> =A0CFLAGS +=3D -Wdeclaration-after-statement
>
> -CFLAGS =A0+=3D -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> +CFLAGS +=3D -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> =A0CFLAGS +=3D -mno-tls-direct-seg-refs
> -CFLAGS =A0+=3D -Werror
> +CFLAGS +=3D -Werror
>
> -BIN =A0 =A0 =A0=3D xenalyze dump-raw
> +BIN :=3D xenalyze dump-raw
>
> -HDRS =3D trace.h analyze.h mread.h
> +xenalyze_OBJS :=3D \
> + =A0 =A0 =A0 mread.o \
> + =A0 =A0 =A0 xenalyze.o
> +
> +dump-raw_OBJS :=3D \
> + =A0 =A0 =A0 dump-raw.o
>
> =A0all: $(BIN)
>
> +xenalyze: $(xenalyze_OBJS)
> + =A0 =A0 =A0 $(CC) $(LDFLAGS) -o $@ $^
> +
> +dump-raw: $(dump-raw_OBJS)
> + =A0 =A0 =A0 $(CC) $(LDFLAGS) -o $@ $^
> +
> +%.o: %.c
> + =A0 =A0 =A0 $(CC) $(CFLAGS) -MD -MP -c -o $@ $<
> +
> +all_objs :=3D $(foreach b,$(BIN),$($(b)_OBJS))
> +all_deps :=3D $(all_objs:.o=3D.d)
> +
> =A0.PHONY: clean
> =A0clean:
> - =A0 =A0 =A0 $(RM) *.a *.so *.o *.rpm $(BIN) $(LIBBIN)
> + =A0 =A0 =A0 $(RM) $(BIN) $(all_objs) $(all_deps)
>
> -%: %.c $(HDRS) Makefile
> - =A0 =A0 =A0 $(CC) $(CFLAGS) -o $@ $<
> -
> -xenalyze: xenalyze.o mread.o
> - =A0 =A0 =A0 $(CC) $(CFLAGS) -o $@ $^
> +-include $(all_deps)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 17:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:00: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 1ScJay-0001q5-Tl; Wed, 06 Jun 2012 17:00:32 +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 1ScJax-0001q0-Ey
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 17:00:31 +0000
Received: from [85.158.143.99:24037] by server-3.bemta-4.messagelabs.com id
	57/B3-29237-EAC8FCF4; Wed, 06 Jun 2012 17:00:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339002028!21833552!1
X-Originating-IP: [209.85.216.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24332 invoked from network); 6 Jun 2012 17:00:29 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:00:29 -0000
Received: by qady23 with SMTP id y23so4131350qad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 10:00:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=jdHNxUQ0atY3u2QcpBEiqTVlpL9G8EFPtBBzmGS6gfM=;
	b=bLt3pbXbOirRmurAEq6EjLsu//x17a5a7Qk/6sDsv0pJxsIz3swNLUf49gjKaPe4W+
	I/hCFcmiz10pd2bebxsuLogNSGkTC8oGcNsC4yA+LusvMx7MYbh5+60tH1MZr+Sh7OJr
	GqHCky4Fof/hXc+mIlh5YoUO/+0TmNEYsZLoPE8Kujm+lCJ6zgkYS036JqaMcZGrzHiO
	s9SuupiJcCCaUO/d7w3ci8PLYRpPvtx7T4jhUIA6Hi6wL0VAty31yISjNTZ8KrpLdafo
	mhwYMohd+NIFvem5bDFsriyY3DsRn7/Qj2U6lOPAdKtR2i+S9E8cC39pKz0UfEmPm8UV
	/Upw==
MIME-Version: 1.0
Received: by 10.229.134.193 with SMTP id k1mr862895qct.64.1339002027667; Wed,
	06 Jun 2012 10:00:27 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 10:00:27 -0700 (PDT)
In-Reply-To: <8884c4995307dc8664d5.1338462978@qabil.uk.xensource.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<8884c4995307dc8664d5.1338462978@qabil.uk.xensource.com>
Date: Wed, 6 Jun 2012 18:00:27 +0100
X-Google-Sender-Auth: 1sT143fdgnM2YXxnjI-eDr_aV8k
Message-ID: <CAFLBxZbBFJPd+j18skM3L4Bm2KR3Q39r1X7u016C-RzXZJJbag@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, George Dunlap <george.dunlap@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02 of 10] xenalyze: automatically generate
	dependencies
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, May 31, 2012 at 12:16 PM, David Vrabel <david.vrabel@citrix.com> wr=
ote:
> Use gcc's -MD and -MP options to automatically generate dependencies.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

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

>
> diff --git a/.hgignore b/.hgignore
> --- a/.hgignore
> +++ b/.hgignore
> @@ -1,3 +1,4 @@
> +.*\.d
> =A0.*\.o
> =A0xenalyze
> =A0dump-raw
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,5 +1,3 @@
> -CC =3D gcc
> -
> =A0CFLAGS +=3D -g -O2
> =A0CFLAGS +=3D -fno-strict-aliasing
> =A0CFLAGS +=3D -std=3Dgnu99
> @@ -7,22 +5,35 @@ CFLAGS +=3D -Wall -Wstrict-prototypes
> =A0CFLAGS +=3D -Wno-unused-value
> =A0CFLAGS +=3D -Wdeclaration-after-statement
>
> -CFLAGS =A0+=3D -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> +CFLAGS +=3D -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> =A0CFLAGS +=3D -mno-tls-direct-seg-refs
> -CFLAGS =A0+=3D -Werror
> +CFLAGS +=3D -Werror
>
> -BIN =A0 =A0 =A0=3D xenalyze dump-raw
> +BIN :=3D xenalyze dump-raw
>
> -HDRS =3D trace.h analyze.h mread.h
> +xenalyze_OBJS :=3D \
> + =A0 =A0 =A0 mread.o \
> + =A0 =A0 =A0 xenalyze.o
> +
> +dump-raw_OBJS :=3D \
> + =A0 =A0 =A0 dump-raw.o
>
> =A0all: $(BIN)
>
> +xenalyze: $(xenalyze_OBJS)
> + =A0 =A0 =A0 $(CC) $(LDFLAGS) -o $@ $^
> +
> +dump-raw: $(dump-raw_OBJS)
> + =A0 =A0 =A0 $(CC) $(LDFLAGS) -o $@ $^
> +
> +%.o: %.c
> + =A0 =A0 =A0 $(CC) $(CFLAGS) -MD -MP -c -o $@ $<
> +
> +all_objs :=3D $(foreach b,$(BIN),$($(b)_OBJS))
> +all_deps :=3D $(all_objs:.o=3D.d)
> +
> =A0.PHONY: clean
> =A0clean:
> - =A0 =A0 =A0 $(RM) *.a *.so *.o *.rpm $(BIN) $(LIBBIN)
> + =A0 =A0 =A0 $(RM) $(BIN) $(all_objs) $(all_deps)
>
> -%: %.c $(HDRS) Makefile
> - =A0 =A0 =A0 $(CC) $(CFLAGS) -o $@ $<
> -
> -xenalyze: xenalyze.o mread.o
> - =A0 =A0 =A0 $(CC) $(CFLAGS) -o $@ $^
> +-include $(all_deps)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 17:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScJe0-0001zU-Gk; Wed, 06 Jun 2012 17:03:40 +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 1ScJdy-0001zH-V5
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 17:03:39 +0000
Received: from [85.158.139.83:8647] by server-10.bemta-5.messagelabs.com id
	CF/3A-23803-A6D8FCF4; Wed, 06 Jun 2012 17:03:38 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339002215!24963944!1
X-Originating-IP: [209.85.216.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22846 invoked from network); 6 Jun 2012 17:03:36 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:03:36 -0000
Received: by qady23 with SMTP id y23so4134155qad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 10:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=9F6LtzKyq+13KvMOcjGy2WyytwP3bCPXijH8YMpaRPc=;
	b=nzGYA3PCUuhIp2V0t5ZIkMUoF7V0ZcLcZg5Zw6sdhb1KJ8jJwjKxd+qLbWRmDMJCLG
	gFjEeIIvE5bq4bCTQwdSPWnLA5Fv/wj+UNB8I3w83LImWjW3hr2GtUUecqfbFIByCueq
	evrnL9UspKyWOLaYUZSHxRkoQ716fHtDXXA9fmeHvL2H1zgk9oHas09FLPGvTTo/Cl2p
	cC4c5es0wriSWbFmJkRvgJ0NEmT92S2nYdit8ZT1htwfFEe2F9FhGT3z4Yv7rS23dfMK
	2lK8HpprgskMMwp6XYcIqvtBInbbO94OiIF6lcd3qhqwjADyFvD5VuMZTNw8m1gO+RPe
	Yd+w==
MIME-Version: 1.0
Received: by 10.229.135.9 with SMTP id l9mr881717qct.91.1339002215327; Wed, 06
	Jun 2012 10:03:35 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 10:03:35 -0700 (PDT)
In-Reply-To: <e54f58627f692e43a95c.1338462979@qabil.uk.xensource.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<e54f58627f692e43a95c.1338462979@qabil.uk.xensource.com>
Date: Wed, 6 Jun 2012 18:03:35 +0100
X-Google-Sender-Auth: ezDizfGWeOnUmVbpUZCxd_7LAc8
Message-ID: <CAFLBxZapMAfOfqYhiietvbsYvZfJ1By-4WqJUUUZ9qw9qQARAg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, George Dunlap <george.dunlap@citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] xenalyze: remove decode of unused
	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="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, May 31, 2012 at 12:16 PM, David Vrabel <david.vrabel@citrix.com> wr=
ote:
> The PV_UPDATE_VA_MAPPING event is not present in xen-unstable, nor is
> it present in any of the 3.2, 3.3, 3.4 or 4.1 XenServer trees I looked
> at so I can only assume this was an event that never made it upstream.
>
> Remove the code as the event ID is now used for PV_HYPERCALL_V2.
>
> Similarly, some of the the HW_IRQ_* events are also not used anywhere
> I could find.

Certainly makes sense to remove these, but I think the
PV_UPDATE_VA_MAPPING at least is probably useful, if I can find the
patch for it.  (The HW_IRQ events were for tracking down that IOMMU
bug reported by SolarFlare last summer.)

I'll make two changesets which remove these individually, so it's easy
to revert if we decide to bring them back.

 -George

>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -1531,7 +1531,6 @@ enum {
> =A0 =A0 PV_GDT_LDT_MAPPING_FAULT,
> =A0 =A0 PV_PTWR_EMULATION,
> =A0 =A0 PV_PTWR_EMULATION_PAE,
> - =A0 =A0PV_UPDATE_VA_MAPPING,
> =A0 =A0 PV_MAX
> =A0};
>
> @@ -6514,44 +6513,6 @@ void pv_ptwr_emulation_process(struct re
> =A0 =A0 }
> =A0}
>
> -void pv_update_va_mapping_process(struct record_info *ri, struct pv_data=
 *pv) {
> - =A0 =A0union pv_event pevt =3D { .event =3D ri->event };
> - =A0 =A0union {
> - =A0 =A0 =A0 =A0/* gpl2 is deprecated */
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned long long val;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned int va, flags;
> - =A0 =A0 =A0 =A0} x32;
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned long long val;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned long long va, flags;
> - =A0 =A0 =A0 =A0} x64;
> - =A0 =A0} *r =3D (typeof(r))ri->d;
> - =A0 =A0struct {
> - =A0 =A0 =A0 =A0unsigned long long val, va, flags;
> - =A0 =A0} e;
> -
> - =A0 =A0if ( pevt.x64 )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0e.val =3D r->x64.val;
> - =A0 =A0 =A0 =A0e.va =3D r->x64.va;
> - =A0 =A0 =A0 =A0e.flags =3D r->x64.flags;
> - =A0 =A0}
> - =A0 =A0else
> - =A0 =A0{
> - =A0 =A0 =A0 =A0e.val =3D r->x32.val;
> - =A0 =A0 =A0 =A0e.va =3D r->x32.va;
> - =A0 =A0 =A0 =A0e.flags =3D r->x32.flags;
> - =A0 =A0}
> -
> - =A0 =A0if ( opt.dump_all )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0printf(" %s update_va_mapping l1e %llx va %llx flags %ll=
x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 e.val, e.va, e.flags);
> - =A0 =A0}
> -}
> -
> =A0void pv_generic_process(struct record_info *ri, struct pv_data *pv) {
> =A0 =A0 union pv_event pevt =3D { .event =3D ri->event };
> =A0 =A0 if ( opt.dump_all ) {
> @@ -6638,9 +6599,6 @@ void pv_process(struct pcpu_info *p)
> =A0 =A0 case PV_PTWR_EMULATION_PAE:
> =A0 =A0 =A0 =A0 pv_ptwr_emulation_process(ri, pv);
> =A0 =A0 =A0 =A0 break;
> - =A0 =A0case PV_UPDATE_VA_MAPPING:
> - =A0 =A0 =A0 =A0pv_update_va_mapping_process(ri, pv);
> - =A0 =A0 =A0 =A0break;
> =A0 =A0 case PV_PAGE_FAULT:
> =A0 =A0 =A0 =A0 //pv_pf_process(ri, pv);
> =A0 =A0 =A0 =A0 //break;
> @@ -7893,149 +7851,6 @@ void irq_process(struct pcpu_info *p) {
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 break;
> =A0 =A0 }
> - =A0 =A0case TRC_HW_IRQ_MSI_WRITE:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned address_lo, address_hi;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned data;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned irq:16, pos:16;
> - =A0 =A0 =A0 =A0 =A0 =A0uint8_t func, slot, bus, type;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned mask_base;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_msi_write irq %x t %x base %x ad=
dr %x %x data %x pci %02x:%02x.%x %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->type,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->mask_base,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->address_hi, r->address_lo,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->data,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->bus, r->slot, r->func, r->pos);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_IOMMU_AMD_IRE:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0uint16_t bdf, id;
> - =A0 =A0 =A0 =A0 =A0 =A0int offset;
> - =A0 =A0 =A0 =A0 =A0 =A0uint8_t dest_mode, dev_mode, vector, dest;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_iommu_ire bdf %x id %x offset %x=
 dest_mode %x dev_mode %x vec %x dest %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->bdf, r->id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->offset,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->dest_mode, r->dev_mode,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->vector, r->dest);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_MAP_PIRQ_MSI:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned domain:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pirq:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0devfn:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0entry_nr:16;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( r->irq < MAX_IRQ )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0struct irq_desc *irq=3Dirq_table+r->irq;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0if ( irq->dev )
> - =A0 =A0 =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(warn, "Strange, irq %d already h=
as dev %02x:%x.%x!\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0r->irq, irq->dev->bus,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->dev->devfn>>4,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->dev->devfn&3);
> - =A0 =A0 =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0 =A0 =A0else
> - =A0 =A0 =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct pci_dev *pdev =3D pdev_find(r->bu=
s, r->devfn);
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->dev=3Dpdev;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->type=3DIRQ_MSI;
> - =A0 =A0 =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0}
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_map_pirq_msi d%d pirq %x(%d) irq=
 %x bus %x devfn %x entry %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->domain,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->bus,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->devfn,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->entry_nr);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_MAP_PIRQ_GSI:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned domain, pirq, irq;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_map_pirq_gsi d%d pirq %x(%d) irq=
 %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->domain,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_MSI_SET_AFFINITY:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned irq, apic_id, vector;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_msi_set_affinity irq %x apicid %=
x vec %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->apic_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->vector);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_SET_DESC_AFFINITY:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned line:16, irq:16;
> - =A0 =A0 =A0 =A0 =A0 =A0char fname[24]; /* Extra 7 words; 6 words * 4 =
=3D 24 */
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> - =A0 =A0 =A0 =A0char fname[25];
> - =A0 =A0 =A0 =A0int i;
> -
> - =A0 =A0 =A0 =A0for(i=3D0; i<24; i++)
> - =A0 =A0 =A0 =A0 =A0 =A0fname[i]=3Dr->fname[i];
> - =A0 =A0 =A0 =A0fname[i]=3D0;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_set_desc_affinity irq %x %s:%d\n=
",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fname,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->line);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> =A0 =A0 case TRC_HW_IRQ_CLEAR_VECTOR:
> =A0 =A0 case TRC_HW_IRQ_MOVE_FINISH :
> =A0 =A0 default:
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 17:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScJe0-0001zU-Gk; Wed, 06 Jun 2012 17:03:40 +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 1ScJdy-0001zH-V5
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 17:03:39 +0000
Received: from [85.158.139.83:8647] by server-10.bemta-5.messagelabs.com id
	CF/3A-23803-A6D8FCF4; Wed, 06 Jun 2012 17:03:38 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339002215!24963944!1
X-Originating-IP: [209.85.216.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22846 invoked from network); 6 Jun 2012 17:03:36 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:03:36 -0000
Received: by qady23 with SMTP id y23so4134155qad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 10:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=9F6LtzKyq+13KvMOcjGy2WyytwP3bCPXijH8YMpaRPc=;
	b=nzGYA3PCUuhIp2V0t5ZIkMUoF7V0ZcLcZg5Zw6sdhb1KJ8jJwjKxd+qLbWRmDMJCLG
	gFjEeIIvE5bq4bCTQwdSPWnLA5Fv/wj+UNB8I3w83LImWjW3hr2GtUUecqfbFIByCueq
	evrnL9UspKyWOLaYUZSHxRkoQ716fHtDXXA9fmeHvL2H1zgk9oHas09FLPGvTTo/Cl2p
	cC4c5es0wriSWbFmJkRvgJ0NEmT92S2nYdit8ZT1htwfFEe2F9FhGT3z4Yv7rS23dfMK
	2lK8HpprgskMMwp6XYcIqvtBInbbO94OiIF6lcd3qhqwjADyFvD5VuMZTNw8m1gO+RPe
	Yd+w==
MIME-Version: 1.0
Received: by 10.229.135.9 with SMTP id l9mr881717qct.91.1339002215327; Wed, 06
	Jun 2012 10:03:35 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Wed, 6 Jun 2012 10:03:35 -0700 (PDT)
In-Reply-To: <e54f58627f692e43a95c.1338462979@qabil.uk.xensource.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<e54f58627f692e43a95c.1338462979@qabil.uk.xensource.com>
Date: Wed, 6 Jun 2012 18:03:35 +0100
X-Google-Sender-Auth: ezDizfGWeOnUmVbpUZCxd_7LAc8
Message-ID: <CAFLBxZapMAfOfqYhiietvbsYvZfJ1By-4WqJUUUZ9qw9qQARAg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, George Dunlap <george.dunlap@citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] xenalyze: remove decode of unused
	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="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, May 31, 2012 at 12:16 PM, David Vrabel <david.vrabel@citrix.com> wr=
ote:
> The PV_UPDATE_VA_MAPPING event is not present in xen-unstable, nor is
> it present in any of the 3.2, 3.3, 3.4 or 4.1 XenServer trees I looked
> at so I can only assume this was an event that never made it upstream.
>
> Remove the code as the event ID is now used for PV_HYPERCALL_V2.
>
> Similarly, some of the the HW_IRQ_* events are also not used anywhere
> I could find.

Certainly makes sense to remove these, but I think the
PV_UPDATE_VA_MAPPING at least is probably useful, if I can find the
patch for it.  (The HW_IRQ events were for tracking down that IOMMU
bug reported by SolarFlare last summer.)

I'll make two changesets which remove these individually, so it's easy
to revert if we decide to bring them back.

 -George

>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -1531,7 +1531,6 @@ enum {
> =A0 =A0 PV_GDT_LDT_MAPPING_FAULT,
> =A0 =A0 PV_PTWR_EMULATION,
> =A0 =A0 PV_PTWR_EMULATION_PAE,
> - =A0 =A0PV_UPDATE_VA_MAPPING,
> =A0 =A0 PV_MAX
> =A0};
>
> @@ -6514,44 +6513,6 @@ void pv_ptwr_emulation_process(struct re
> =A0 =A0 }
> =A0}
>
> -void pv_update_va_mapping_process(struct record_info *ri, struct pv_data=
 *pv) {
> - =A0 =A0union pv_event pevt =3D { .event =3D ri->event };
> - =A0 =A0union {
> - =A0 =A0 =A0 =A0/* gpl2 is deprecated */
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned long long val;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned int va, flags;
> - =A0 =A0 =A0 =A0} x32;
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned long long val;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned long long va, flags;
> - =A0 =A0 =A0 =A0} x64;
> - =A0 =A0} *r =3D (typeof(r))ri->d;
> - =A0 =A0struct {
> - =A0 =A0 =A0 =A0unsigned long long val, va, flags;
> - =A0 =A0} e;
> -
> - =A0 =A0if ( pevt.x64 )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0e.val =3D r->x64.val;
> - =A0 =A0 =A0 =A0e.va =3D r->x64.va;
> - =A0 =A0 =A0 =A0e.flags =3D r->x64.flags;
> - =A0 =A0}
> - =A0 =A0else
> - =A0 =A0{
> - =A0 =A0 =A0 =A0e.val =3D r->x32.val;
> - =A0 =A0 =A0 =A0e.va =3D r->x32.va;
> - =A0 =A0 =A0 =A0e.flags =3D r->x32.flags;
> - =A0 =A0}
> -
> - =A0 =A0if ( opt.dump_all )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0printf(" %s update_va_mapping l1e %llx va %llx flags %ll=
x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 e.val, e.va, e.flags);
> - =A0 =A0}
> -}
> -
> =A0void pv_generic_process(struct record_info *ri, struct pv_data *pv) {
> =A0 =A0 union pv_event pevt =3D { .event =3D ri->event };
> =A0 =A0 if ( opt.dump_all ) {
> @@ -6638,9 +6599,6 @@ void pv_process(struct pcpu_info *p)
> =A0 =A0 case PV_PTWR_EMULATION_PAE:
> =A0 =A0 =A0 =A0 pv_ptwr_emulation_process(ri, pv);
> =A0 =A0 =A0 =A0 break;
> - =A0 =A0case PV_UPDATE_VA_MAPPING:
> - =A0 =A0 =A0 =A0pv_update_va_mapping_process(ri, pv);
> - =A0 =A0 =A0 =A0break;
> =A0 =A0 case PV_PAGE_FAULT:
> =A0 =A0 =A0 =A0 //pv_pf_process(ri, pv);
> =A0 =A0 =A0 =A0 //break;
> @@ -7893,149 +7851,6 @@ void irq_process(struct pcpu_info *p) {
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 break;
> =A0 =A0 }
> - =A0 =A0case TRC_HW_IRQ_MSI_WRITE:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned address_lo, address_hi;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned data;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned irq:16, pos:16;
> - =A0 =A0 =A0 =A0 =A0 =A0uint8_t func, slot, bus, type;
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned mask_base;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_msi_write irq %x t %x base %x ad=
dr %x %x data %x pci %02x:%02x.%x %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->type,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->mask_base,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->address_hi, r->address_lo,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->data,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->bus, r->slot, r->func, r->pos);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_IOMMU_AMD_IRE:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0uint16_t bdf, id;
> - =A0 =A0 =A0 =A0 =A0 =A0int offset;
> - =A0 =A0 =A0 =A0 =A0 =A0uint8_t dest_mode, dev_mode, vector, dest;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_iommu_ire bdf %x id %x offset %x=
 dest_mode %x dev_mode %x vec %x dest %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->bdf, r->id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->offset,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->dest_mode, r->dev_mode,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->vector, r->dest);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_MAP_PIRQ_MSI:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned domain:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pirq:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0devfn:16,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0entry_nr:16;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( r->irq < MAX_IRQ )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0struct irq_desc *irq=3Dirq_table+r->irq;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0if ( irq->dev )
> - =A0 =A0 =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(warn, "Strange, irq %d already h=
as dev %02x:%x.%x!\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0r->irq, irq->dev->bus,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->dev->devfn>>4,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->dev->devfn&3);
> - =A0 =A0 =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0 =A0 =A0else
> - =A0 =A0 =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct pci_dev *pdev =3D pdev_find(r->bu=
s, r->devfn);
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->dev=3Dpdev;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq->type=3DIRQ_MSI;
> - =A0 =A0 =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0}
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_map_pirq_msi d%d pirq %x(%d) irq=
 %x bus %x devfn %x entry %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->domain,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->bus,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->devfn,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->entry_nr);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_MAP_PIRQ_GSI:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned domain, pirq, irq;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_map_pirq_gsi d%d pirq %x(%d) irq=
 %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->domain,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->pirq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_MSI_SET_AFFINITY:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned irq, apic_id, vector;
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_msi_set_affinity irq %x apicid %=
x vec %x\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->apic_id,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->vector);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> - =A0 =A0case TRC_HW_IRQ_SET_DESC_AFFINITY:
> - =A0 =A0{
> - =A0 =A0 =A0 =A0struct {
> - =A0 =A0 =A0 =A0 =A0 =A0unsigned line:16, irq:16;
> - =A0 =A0 =A0 =A0 =A0 =A0char fname[24]; /* Extra 7 words; 6 words * 4 =
=3D 24 */
> - =A0 =A0 =A0 =A0} *r =3D (typeof(r))ri->d;
> - =A0 =A0 =A0 =A0char fname[25];
> - =A0 =A0 =A0 =A0int i;
> -
> - =A0 =A0 =A0 =A0for(i=3D0; i<24; i++)
> - =A0 =A0 =A0 =A0 =A0 =A0fname[i]=3Dr->fname[i];
> - =A0 =A0 =A0 =A0fname[i]=3D0;
> -
> - =A0 =A0 =A0 =A0if ( opt.dump_all )
> - =A0 =A0 =A0 =A0{
> - =A0 =A0 =A0 =A0 =A0 =A0printf(" %s irq_set_desc_affinity irq %x %s:%d\n=
",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ri->dump_header,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->irq,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fname,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r->line);
> - =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0break;
> - =A0 =A0}
> =A0 =A0 case TRC_HW_IRQ_CLEAR_VECTOR:
> =A0 =A0 case TRC_HW_IRQ_MOVE_FINISH :
> =A0 =A0 default:
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 17:28:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScK1Z-0002Nw-NM; Wed, 06 Jun 2012 17:28: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 1ScK1X-0002Nr-WA
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 17:28:00 +0000
Received: from [85.158.143.35:45760] by server-3.bemta-4.messagelabs.com id
	AB/F8-29237-F139FCF4; Wed, 06 Jun 2012 17:27:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339003678!8166234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25572 invoked from network); 6 Jun 2012 17:27:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:27:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 17:27:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 18:27:08 +0100
Date: Wed, 6 Jun 2012 18:26:53 +0100
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: <1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-22-git-send-email-ian.campbell@citrix.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] [PATCH 22/38] arm: implement
 vcpu_show_execution_state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/dummy.S |    1 -
>  xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
>  2 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 03f7489..cab9522 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
>  DUMMY(arch_get_info_guest);
>  DUMMY(arch_vcpu_reset);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
>  DUMMY(get_page);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 35907ee..ec74298 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
>      panic("Error during %s-to-physical address translation\n", when);
>  }
>  
> -void show_registers(struct cpu_user_regs *regs)
> +struct reg_ctxt {
> +    uint32_t sctlr;
> +    uint32_t ttbr0, ttbr1, ttbcr;
> +};
> +static void _show_registers(struct cpu_user_regs *regs,
> +                            struct reg_ctxt *ctxt,
> +                            int guest_mode)
>  {
>      static const char *mode_strings[] = {
>         [PSR_MODE_USR] = "USR",
> @@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
>      print_xen_info();
>      printk("CPU:    %d\n", smp_processor_id());
>      printk("PC:     %08"PRIx32, regs->pc);
> -    if ( !guest_mode(regs) )
> +    if ( !guest_mode )
>              print_symbol(" %s", regs->pc);
>      printk("\n");
>      printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
> @@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
>      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);
>  
> -    if ( guest_mode(regs) )
> +    if ( guest_mode )
>      {
>          printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
>                 regs->sp_usr, regs->lr_usr, regs->cpsr);
> @@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
>                 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",
> -               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
> -        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
> +               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
> +        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
>          printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
>          printk("\n");
>      }
> @@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
>      printk("\n");
>  }
>  
> +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);
> +    _show_registers(regs, &ctxt, guest_mode(regs));
> +}
> +
> +void vcpu_show_registers(const struct vcpu *v)
> +{
> +    struct reg_ctxt ctxt;
> +    ctxt.sctlr = v->arch.sctlr;
> +    ctxt.ttbcr = 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);
> +}
> +
>  static void show_guest_stack(struct cpu_user_regs *regs)
>  {
>      printk("GUEST STACK GOES HERE\n");
> @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
>      show_stack(regs);
>  }
>  
> +void vcpu_show_execution_state(struct vcpu *v)
> +{
> +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> +           v->domain->domain_id, v->vcpu_id);
> +
> +    if ( v == current )
> +    {
> +        show_execution_state(guest_cpu_user_regs());
> +        return;
> +    }
> +
> +    vcpu_pause(v); /* acceptably dangerous */
> +
> +    vcpu_show_registers(v);
> +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);

isn't the if condition inverted?

> +    vcpu_unpause(v);
> +}
> +
>  static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
>  {
>      printk("Unexpected Trap: %s\n", msg);


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 17:28:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScK1Z-0002Nw-NM; Wed, 06 Jun 2012 17:28: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 1ScK1X-0002Nr-WA
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 17:28:00 +0000
Received: from [85.158.143.35:45760] by server-3.bemta-4.messagelabs.com id
	AB/F8-29237-F139FCF4; Wed, 06 Jun 2012 17:27:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339003678!8166234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25572 invoked from network); 6 Jun 2012 17:27:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:27:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 17:27:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 18:27:08 +0100
Date: Wed, 6 Jun 2012 18:26:53 +0100
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: <1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-22-git-send-email-ian.campbell@citrix.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] [PATCH 22/38] arm: implement
 vcpu_show_execution_state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/dummy.S |    1 -
>  xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
>  2 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 03f7489..cab9522 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
>  DUMMY(arch_get_info_guest);
>  DUMMY(arch_vcpu_reset);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
>  DUMMY(get_page);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 35907ee..ec74298 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
>      panic("Error during %s-to-physical address translation\n", when);
>  }
>  
> -void show_registers(struct cpu_user_regs *regs)
> +struct reg_ctxt {
> +    uint32_t sctlr;
> +    uint32_t ttbr0, ttbr1, ttbcr;
> +};
> +static void _show_registers(struct cpu_user_regs *regs,
> +                            struct reg_ctxt *ctxt,
> +                            int guest_mode)
>  {
>      static const char *mode_strings[] = {
>         [PSR_MODE_USR] = "USR",
> @@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
>      print_xen_info();
>      printk("CPU:    %d\n", smp_processor_id());
>      printk("PC:     %08"PRIx32, regs->pc);
> -    if ( !guest_mode(regs) )
> +    if ( !guest_mode )
>              print_symbol(" %s", regs->pc);
>      printk("\n");
>      printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
> @@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
>      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);
>  
> -    if ( guest_mode(regs) )
> +    if ( guest_mode )
>      {
>          printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
>                 regs->sp_usr, regs->lr_usr, regs->cpsr);
> @@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
>                 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",
> -               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
> -        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
> +               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
> +        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
>          printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
>          printk("\n");
>      }
> @@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
>      printk("\n");
>  }
>  
> +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);
> +    _show_registers(regs, &ctxt, guest_mode(regs));
> +}
> +
> +void vcpu_show_registers(const struct vcpu *v)
> +{
> +    struct reg_ctxt ctxt;
> +    ctxt.sctlr = v->arch.sctlr;
> +    ctxt.ttbcr = 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);
> +}
> +
>  static void show_guest_stack(struct cpu_user_regs *regs)
>  {
>      printk("GUEST STACK GOES HERE\n");
> @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
>      show_stack(regs);
>  }
>  
> +void vcpu_show_execution_state(struct vcpu *v)
> +{
> +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> +           v->domain->domain_id, v->vcpu_id);
> +
> +    if ( v == current )
> +    {
> +        show_execution_state(guest_cpu_user_regs());
> +        return;
> +    }
> +
> +    vcpu_pause(v); /* acceptably dangerous */
> +
> +    vcpu_show_registers(v);
> +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);

isn't the if condition inverted?

> +    vcpu_unpause(v);
> +}
> +
>  static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
>  {
>      printk("Unexpected Trap: %s\n", msg);


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 17:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17: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 1ScKBz-0002kS-1n; Wed, 06 Jun 2012 17:38: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 1ScKBx-0002jg-Mf
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 17:38:45 +0000
Received: from [85.158.138.51:26508] by server-8.bemta-3.messagelabs.com id
	BD/FB-22118-4A59FCF4; Wed, 06 Jun 2012 17:38:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339004324!31072848!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3548 invoked from network); 6 Jun 2012 17:38:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:38:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 17:38:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 18:38:43 +0100
Date: Wed, 6 Jun 2012 18:38:28 +0100
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: <1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061833290.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-23-git-send-email-ian.campbell@citrix.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] [PATCH 23/38] arm: use correct attributes for
 mappings in copy_from_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 Fri, 1 Jun 2012, Ian Campbell wrote:
> The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
> a device type mapping (hence dev shared).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/kernel.c       |    8 ++++----
>  xen/arch/arm/setup.c        |    2 +-
>  xen/include/asm-arm/setup.h |    2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 130d488..1a705c9 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -39,7 +39,7 @@ struct minimal_dtb_header {
>   * @paddr: source physical address
>   * @len: length to copy
>   */
> -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
> +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr)
>  {
>      void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
>  
> @@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
>          s = paddr & (PAGE_SIZE-1);
>          l = min(PAGE_SIZE - s, len);
>  
> -        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
> +        set_fixmap(FIXMAP_MISC, p, mattr);
>          memcpy(dst, src + s, l);
>  
>          paddr += l;
> @@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
>      /*
>       * Check for an appended DTB.
>       */
> -    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
> +    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
>      if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
>          end += be32_to_cpu(dtb_hdr.total_size);
>      }
> @@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
>      if ( info->kernel_img == NULL )
>          panic("Cannot allocate temporary buffer for kernel.\n");
>  
> -    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> +    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
>  
>      if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
>          return rc;
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index b0cfacc..f5473cd 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
>       * TODO: handle other payloads too.
>       */
>      device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
> -    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
> +    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
>  
>      /* Add non-xenheap memory */
>      init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 05ff89e..faadccc 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -3,7 +3,7 @@
>  
>  #include <public/version.h>
>  
> -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr);
>  
>  void arch_get_xen_caps(xen_capabilities_info_t *info);
>  

The patch is correct, but it shouldn't call the new parameter mattr
because it can easily be confused with the memattr bits (see
http://marc.info/?l=xen-devel&m=133856578918985).
I would call it "int attrindx" instead.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 17:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17: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 1ScKBz-0002kS-1n; Wed, 06 Jun 2012 17:38: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 1ScKBx-0002jg-Mf
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 17:38:45 +0000
Received: from [85.158.138.51:26508] by server-8.bemta-3.messagelabs.com id
	BD/FB-22118-4A59FCF4; Wed, 06 Jun 2012 17:38:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339004324!31072848!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3548 invoked from network); 6 Jun 2012 17:38:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:38:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 17:38:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 18:38:43 +0100
Date: Wed, 6 Jun 2012 18:38:28 +0100
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: <1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061833290.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-23-git-send-email-ian.campbell@citrix.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] [PATCH 23/38] arm: use correct attributes for
 mappings in copy_from_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 Fri, 1 Jun 2012, Ian Campbell wrote:
> The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
> a device type mapping (hence dev shared).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/kernel.c       |    8 ++++----
>  xen/arch/arm/setup.c        |    2 +-
>  xen/include/asm-arm/setup.h |    2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 130d488..1a705c9 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -39,7 +39,7 @@ struct minimal_dtb_header {
>   * @paddr: source physical address
>   * @len: length to copy
>   */
> -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
> +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr)
>  {
>      void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
>  
> @@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
>          s = paddr & (PAGE_SIZE-1);
>          l = min(PAGE_SIZE - s, len);
>  
> -        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
> +        set_fixmap(FIXMAP_MISC, p, mattr);
>          memcpy(dst, src + s, l);
>  
>          paddr += l;
> @@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
>      /*
>       * Check for an appended DTB.
>       */
> -    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
> +    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
>      if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
>          end += be32_to_cpu(dtb_hdr.total_size);
>      }
> @@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
>      if ( info->kernel_img == NULL )
>          panic("Cannot allocate temporary buffer for kernel.\n");
>  
> -    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> +    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
>  
>      if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
>          return rc;
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index b0cfacc..f5473cd 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
>       * TODO: handle other payloads too.
>       */
>      device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
> -    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
> +    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
>  
>      /* Add non-xenheap memory */
>      init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 05ff89e..faadccc 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -3,7 +3,7 @@
>  
>  #include <public/version.h>
>  
> -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr);
>  
>  void arch_get_xen_caps(xen_capabilities_info_t *info);
>  

The patch is correct, but it shouldn't call the new parameter mattr
because it can easily be confused with the memattr bits (see
http://marc.info/?l=xen-devel&m=133856578918985).
I would call it "int attrindx" instead.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 17:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScKDj-0002pt-Hw; Wed, 06 Jun 2012 17:40:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScKDh-0002pm-Pa
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 17:40:33 +0000
Received: from [85.158.143.35:29578] by server-3.bemta-4.messagelabs.com id
	20/C1-29237-1169FCF4; Wed, 06 Jun 2012 17:40:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339004432!14333116!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19650 invoked from network); 6 Jun 2012 17:40:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 17:40:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 18:40:32 +0100
Date: Wed, 6 Jun 2012 18:40:16 +0100
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: <1338565207-2888-24-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061839560.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-24-git-send-email-ian.campbell@citrix.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] [PATCH 24/38] arm: map fixmaps non-executable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/mm.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index c332e4c..160a4e9 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -108,6 +108,7 @@ void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
>      lpae_t pte = mfn_to_xen_entry(mfn);
>      pte.pt.table = 1; /* 4k mappings always have this bit set */
>      pte.pt.ai = attributes;
> +    pte.pt.xn = 1;
>      write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
>      flush_xen_data_tlb_va(FIXMAP_ADDR(map));
>  }
> -- 
> 1.7.9.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 Wed Jun 06 17:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 17:40:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScKDj-0002pt-Hw; Wed, 06 Jun 2012 17:40:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScKDh-0002pm-Pa
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 17:40:33 +0000
Received: from [85.158.143.35:29578] by server-3.bemta-4.messagelabs.com id
	20/C1-29237-1169FCF4; Wed, 06 Jun 2012 17:40:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339004432!14333116!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19650 invoked from network); 6 Jun 2012 17:40:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 17:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 17:40:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 18:40:32 +0100
Date: Wed, 6 Jun 2012 18:40:16 +0100
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: <1338565207-2888-24-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061839560.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-24-git-send-email-ian.campbell@citrix.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] [PATCH 24/38] arm: map fixmaps non-executable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/mm.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index c332e4c..160a4e9 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -108,6 +108,7 @@ void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
>      lpae_t pte = mfn_to_xen_entry(mfn);
>      pte.pt.table = 1; /* 4k mappings always have this bit set */
>      pte.pt.ai = attributes;
> +    pte.pt.xn = 1;
>      write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
>      flush_xen_data_tlb_va(FIXMAP_ADDR(map));
>  }
> -- 
> 1.7.9.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 Wed Jun 06 18:03:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18: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 1ScKZq-00038i-Ha; Wed, 06 Jun 2012 18:03:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil.rao@ericsson.com>) id 1ScKZo-00038d-Ew
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:03:24 +0000
Received: from [85.158.143.99:22289] by server-2.bemta-4.messagelabs.com id
	08/6A-17938-B6B9FCF4; Wed, 06 Jun 2012 18:03:23 +0000
X-Env-Sender: anil.rao@ericsson.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339005801!29291201!1
X-Originating-IP: [198.24.6.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjI0LjYuMTMgPT4gMjU2MjYw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 6 Jun 2012 18:03:22 -0000
Received: from imr3.ericy.com (HELO imr3.ericy.com) (198.24.6.13)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 18:03:22 -0000
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181])
	by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q56I3IqR000512
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Wed, 6 Jun 2012 13:03:19 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by
	eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi;
	Wed, 6 Jun 2012 14:03:18 -0400
From: Anil Rao <anil.rao@ericsson.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 14:03:17 -0400
Thread-Topic: [Xen-devel] PCI hotplug related issues
Thread-Index: Ac1DxskdSkWre16GSn+XTq0iO+kjtQARpEJQ
Message-ID: <DD729E174A25344F8D7D351BA4CF57272DAD4CEF7B@EUSAACMS0715.eamcs.ericsson.se>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
	<DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
	<4FCF2499020000780008865E@nat28.tlf.novell.com>
	<1338974915.32319.37.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338974915.32319.37.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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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

 
Thanks, Jan and Ian for your confirmation and suggestions. For the moment, I have incorporated a workaround that is allowing us to proceed with our particular usage of Xen based VMs. 

When I free up a little bit at work, I don't mind taking a stab at getting this to work. I'll keep the list posted.

Anil


-----Original Message-----
From: Ian Campbell [mailto:Ian.Campbell@citrix.com] 
Sent: Wednesday, June 06, 2012 2:29 AM
To: Jan Beulich
Cc: Anil Rao; xen-devel
Subject: Re: [Xen-devel] PCI hotplug related issues

On Wed, 2012-06-06 at 08:36 +0100, Jan Beulich wrote:
> >>> On 05.06.12 at 20:01, Anil Rao <anil.rao@ericsson.com> wrote:
> > After encountering this problem, I was afraid that only VM-level 
> > hotplug is supported by Xen (and not true hotplug at the 
> > host-level). Can someone kindly confirm that this is the case? Our 
> > current effort depends on host-level hotplug of a PCI device that 
> > can (later) be assigned (hotplugged) to a running VM, so a 
> > definitive answer will help us to avoid going down the wrong path.
> 
> That is not a proper statement - host side holtplug is still 
> supported, just that currently it may need to happen before the target 
> VM gets created. Overcoming limitations like this is certainly 
> desirable, but will obviously require someone to actually invest work 
> - the question would hence be whether, given that you're interested in 
> this feature and posted on xen-devel, you wouldn't also want to look 
> into addressing this (provided my brief analysis of the situation is 
> correct at all).

Yes, patches to make this work would be gratefully received.

As an aside, I wonder if upstream qemu does anything better here -- that would probably be the right place to look at adding this new feature in any case.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 18:03:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18: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 1ScKZq-00038i-Ha; Wed, 06 Jun 2012 18:03:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil.rao@ericsson.com>) id 1ScKZo-00038d-Ew
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:03:24 +0000
Received: from [85.158.143.99:22289] by server-2.bemta-4.messagelabs.com id
	08/6A-17938-B6B9FCF4; Wed, 06 Jun 2012 18:03:23 +0000
X-Env-Sender: anil.rao@ericsson.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339005801!29291201!1
X-Originating-IP: [198.24.6.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk4LjI0LjYuMTMgPT4gMjU2MjYw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7875 invoked from network); 6 Jun 2012 18:03:22 -0000
Received: from imr3.ericy.com (HELO imr3.ericy.com) (198.24.6.13)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 18:03:22 -0000
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181])
	by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q56I3IqR000512
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Wed, 6 Jun 2012 13:03:19 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by
	eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi;
	Wed, 6 Jun 2012 14:03:18 -0400
From: Anil Rao <anil.rao@ericsson.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Date: Wed, 6 Jun 2012 14:03:17 -0400
Thread-Topic: [Xen-devel] PCI hotplug related issues
Thread-Index: Ac1DxskdSkWre16GSn+XTq0iO+kjtQARpEJQ
Message-ID: <DD729E174A25344F8D7D351BA4CF57272DAD4CEF7B@EUSAACMS0715.eamcs.ericsson.se>
References: <DD729E174A25344F8D7D351BA4CF57272DAD45DB0E@EUSAACMS0715.eamcs.ericsson.se>
	<4FCDE2A902000078000883C3@nat28.tlf.novell.com>
	<DD729E174A25344F8D7D351BA4CF57272DAD45E089@EUSAACMS0715.eamcs.ericsson.se>
	<4FCF2499020000780008865E@nat28.tlf.novell.com>
	<1338974915.32319.37.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338974915.32319.37.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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PCI hotplug related 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

 
Thanks, Jan and Ian for your confirmation and suggestions. For the moment, I have incorporated a workaround that is allowing us to proceed with our particular usage of Xen based VMs. 

When I free up a little bit at work, I don't mind taking a stab at getting this to work. I'll keep the list posted.

Anil


-----Original Message-----
From: Ian Campbell [mailto:Ian.Campbell@citrix.com] 
Sent: Wednesday, June 06, 2012 2:29 AM
To: Jan Beulich
Cc: Anil Rao; xen-devel
Subject: Re: [Xen-devel] PCI hotplug related issues

On Wed, 2012-06-06 at 08:36 +0100, Jan Beulich wrote:
> >>> On 05.06.12 at 20:01, Anil Rao <anil.rao@ericsson.com> wrote:
> > After encountering this problem, I was afraid that only VM-level 
> > hotplug is supported by Xen (and not true hotplug at the 
> > host-level). Can someone kindly confirm that this is the case? Our 
> > current effort depends on host-level hotplug of a PCI device that 
> > can (later) be assigned (hotplugged) to a running VM, so a 
> > definitive answer will help us to avoid going down the wrong path.
> 
> That is not a proper statement - host side holtplug is still 
> supported, just that currently it may need to happen before the target 
> VM gets created. Overcoming limitations like this is certainly 
> desirable, but will obviously require someone to actually invest work 
> - the question would hence be whether, given that you're interested in 
> this feature and posted on xen-devel, you wouldn't also want to look 
> into addressing this (provided my brief analysis of the situation is 
> correct at all).

Yes, patches to make this work would be gratefully received.

As an aside, I wonder if upstream qemu does anything better here -- that would probably be the right place to look at adding this new feature in any case.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 18:05:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScKbE-0003Cq-0F; Wed, 06 Jun 2012 18:04:52 +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 1ScKbC-0003Ch-Tk
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:04:51 +0000
Received: from [85.158.143.99:25609] by server-3.bemta-4.messagelabs.com id
	03/02-29237-2CB9FCF4; Wed, 06 Jun 2012 18:04:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339005889!25065969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23620 invoked from network); 6 Jun 2012 18:04:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 18:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 18:04:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 19:04:48 +0100
Date: Wed, 6 Jun 2012 19:04:33 +0100
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: <1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.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] [PATCH 25/38] arm: remove old identity map of boot
 paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/mm.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 160a4e9..ab52171 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
>      lpae_t pte, *p;
>      int i;
>  
> +    if ( boot_phys_offset != 0 )
> +    {
> +        /* Remove the old identity mapping of the boot paddr */
> +        pte.bits = 0;
> +        dest_va = (unsigned long)_start + boot_phys_offset;
> +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> +    }

It looks like we are already doing this few lines below.
Also now that I am thinking about it, considering that bits is a 64 bit
field, shouldn't this be:

pte.bits = 0ULL;

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 18:05:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScKbE-0003Cq-0F; Wed, 06 Jun 2012 18:04:52 +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 1ScKbC-0003Ch-Tk
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:04:51 +0000
Received: from [85.158.143.99:25609] by server-3.bemta-4.messagelabs.com id
	03/02-29237-2CB9FCF4; Wed, 06 Jun 2012 18:04:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339005889!25065969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23620 invoked from network); 6 Jun 2012 18:04:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 18:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12865694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 18:04:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 19:04:48 +0100
Date: Wed, 6 Jun 2012 19:04:33 +0100
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: <1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.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] [PATCH 25/38] arm: remove old identity map of boot
 paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/mm.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 160a4e9..ab52171 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
>      lpae_t pte, *p;
>      int i;
>  
> +    if ( boot_phys_offset != 0 )
> +    {
> +        /* Remove the old identity mapping of the boot paddr */
> +        pte.bits = 0;
> +        dest_va = (unsigned long)_start + boot_phys_offset;
> +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> +    }

It looks like we are already doing this few lines below.
Also now that I am thinking about it, considering that bits is a 64 bit
field, shouldn't this be:

pte.bits = 0ULL;

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 18:16:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18: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 1ScKlu-0003ac-4I; Wed, 06 Jun 2012 18:15:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1ScKls-0003aX-A5
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:15:52 +0000
Received: from [85.158.138.51:55246] by server-6.bemta-3.messagelabs.com id
	2A/03-05063-75E9FCF4; Wed, 06 Jun 2012 18:15:51 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339006550!24766834!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4423 invoked from network); 6 Jun 2012 18:15:50 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 18:15:50 -0000
Received: by wgbed3 with SMTP id ed3so4688012wgb.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 11:15:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=5KZDVaiqr65GHAWed61qtbldQCTe3q9d86iFcDjmOQg=;
	b=R8Sa2itu4nlfsEqfy6Jk43nPDoWUOwFzPwHQLAc8L0NOOox1GiZIqZmzU28+TLZhRN
	YSDE9oFm/LNTVcun5NyG/l7tY1kHWsinCaytOxFvamPaIzT8TUNhFfsTBurVdR6Qybd3
	Z0m1n6OMyimeDn5ALrVveQ2kfD1yqr2mu8pj2bM3ubwUniSb36gMV1+pUynGUM75O6Ae
	QS7o3Fq3WtMz1GaGk5ueevsDPm1+hFXzRTZZXc0Zc27l6yLah6qtgZUOfgcxFhwPgrPM
	xfk1Iz3xYdHeCdFc7Hw13IqxzJe3YIXoXNVMvJ/J+0ynCW3SLxOjKtQH5LxMd7DFXoEK
	5ThA==
MIME-Version: 1.0
Received: by 10.216.217.228 with SMTP id i78mr17527434wep.126.1339006548801;
	Wed, 06 Jun 2012 11:15:48 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Wed, 6 Jun 2012 11:15:48 -0700 (PDT)
In-Reply-To: <4FCF25E7020000780008866D@nat28.tlf.novell.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
Date: Wed, 6 Jun 2012 19:15:48 +0100
Message-ID: <CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2490621950705802286=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2490621950705802286==
Content-Type: multipart/alternative; boundary=00504502e0c7b179b604c1d1c113

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

Hi,

 Thanks for your attention.

On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 06.06.12 at 09:00, elahe shekuhi <e.shekuhi@gmail.com> wrote:
> > I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but
> live
> > migration does not work. While the source host works on the "xm migrate
> -l
> > ..." command, I can see the VM on the target host in paused state in "xm
> > list", but after a while it vanishes while the xm command on the source
> > machine returns whitout any errors.
>
> Does the guest crash perhaps? In which case a kernel log from it
> might turn out pretty useful. As would technical data (rather than
> a simple "does not work") in the first place (hypervisor, xend, and
> Dom0 kernel logs are all possible candidates for holding relevant
> information).
>
> > (One machine has core i7 processor while another is core 2
> > quad system).
>
> Does migration fail in both directions? Or perhaps just from the
> newer to the older system (in which case I would guess you're
> not masking features properly on the newer one)?
>

   Yes, Migration failed in both directions, but the error in Xend.log is
different. When I do migrate VM from core 2 quad to core i7 machine the
error in Xend.log is

[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:237)
XendDomainInfo.restore(['domain', ['domid', '5'], ['cpu_weight', '256'],
['cpu_cap', '0'], ['pool_name', 'Pool-0'], ['bootloader',
'/usr/bin/pygrub'], ['vcpus', '2'], ['cpus', [[], []]], ['on_poweroff',
'destroy'], ['description', 'None'], ['on_crash', 'destroy'], ['uuid',
'9d19e419-83ca-e877-52e4-0f93f634354a'], ['bootloader_args', '-q'],
['name', 'sles11-1'], ['on_reboot', 'restart'], ['maxmem', '1024'],
['memory', '512'], ['shadow_memory', '0'], ['vcpu_avail', '3'],
['features', ''], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'],
['start_time', '1335185584.3'], ['cpu_time', '0.353877786'],
['online_vcpus', '2'], ['image', ['linux', ['kernel', ''], ['args', ' '],
['superpages', '0'], ['videoram', '4'], ['pci', []], ['nomigrate', '0'],
['tsc_mode', '0'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['notes',
['FEATURES',
'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel'],
['VIRT_BASE', '18446744071562067968'], ['GUEST_VERSION', '2.6'],
['PADDR_OFFSET', '0'], ['GUEST_OS', 'linux'], ['HYPERCALL_PAGE',
'18446744071564193792'], ['LOADER', 'generic'], ['SUSPEND_CANCEL', '1'],
['ENTRY', '18446744071564165120'], ['XEN_VERSION', 'xen-3.0']]]],
['status', '2'], ['state', '-b----'], ['store_mfn', '470107'],
['console_mfn', '470106'], ['device', ['vif', ['bridge', 'br0'], ['mac',
'00:16:3e:44:ac:23'], ['script', '/etc/xen/scripts/vif-bridge'], ['uuid',
'f3a500be-df8d-a7fe-881e-b8d8347dce74'], ['backend', '0']]], ['device',
['vkbd', ['backend', '0']]], ['device', ['console', ['protocol', 'vt100'],
['location', '2'], ['uuid', '0debd581-e78c-c87c-8012-330fa7d0eafb']]],
['device', ['vbd', ['protocol', 'x86_64-abi'], ['uuid',
'8e7150c8-4af1-88c0-e71b-16049663cebc'], ['bootable', '1'], ['dev',
'xvda:disk'], ['uname', 'file:/home/elahe/xen/images/sles11-1/disk0.raw'],
['mode', 'w'], ['backend', '0'], ['VDI', '']]], ['device', ['vbd',
['protocol', 'x86_64-abi'], ['uuid',
'55ff031d-7810-1b41-ed7b-f7fce59c6dcd'], ['bootable', '0'], ['dev',
'xvdb:cdrom'], ['uname', 'phy:/dev/sr0'], ['mode', 'r'], ['backend', '0'],
['VDI', '']]], ['device', ['vfb', ['vncunused', '1'], ['vnc', '1'],
['xauthority', '/root/.Xauthority'], ['keymap', 'en-us'], ['location',
'127.0.0.1:5900'], ['uuid', '3d8f53d2-97b8-770b-59c7-69ac1cd302fa']]],
['change_home_server', 'False']])

[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:2562)
XendDomainInfo.constructDomain

[2012-04-23 17:25:55 1405] DEBUG (balloon:206) Balloon: 538624 KiB free;
need 16384; done.

[2012-04-23 17:25:55 1405] DEBUG (XendDomain:482) Adding Domain: 4

[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:3514) Storing VM details:
{'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0',
'uuid': '9d19e419-83ca-e877-52e4-0f93f634354a', 'on_reboot': 'restart',
'start_time': '1335185584.3', 'on_poweroff': 'destroy', 'bootloader_args':
'-q', 'on_xend_start': 'ignore', 'on_crash': 'destroy',
'xend/restart_count': '0', 'vcpus': '2', 'vcpu_avail': '3', 'bootloader':
'/usr/bin/pygrub', 'image': "(linux (kernel '') (args ' ') (superpages 0)
(videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (device_model
/usr/lib/xen/bin/qemu-dm) (notes (FEATURES
'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel')
(VIRT_BASE 18446744071562067968) (GUEST_VERSION 2.6) (PADDR_OFFSET 0)
(GUEST_OS linux) (HYPERCALL_PAGE 18446744071564193792) (LOADER generic)
(SUSPEND_CANCEL 1) (ENTRY 18446744071564165120) (XEN_VERSION xen-3.0)))",
'name': 'sles11-1'}

[2012-04-23 17:25:55 1405] DEBUG (image:343) No VNC passwd configured for
vfb access

[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:359) restore:shadow=0x0,
_static_max=0x40000000, _static_min=0x0,

[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:386) [xc_restore]:
/usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0

[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn't
set eXtended States for vcpu0 (22 = Invalid argument): Internal error

[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:3150)
XendDomainInfo.destroy: domid=4

[2012-04-23 17:26:41 1405] ERROR (XendDomainInfo:3164)
XendDomainInfo.destroy: domain destruction failed.
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py",
line 3157, in destroy
    xc.domain_pause(self.domid)
Error: (3, 'No such process')

[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2470) No device model

[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2472) Releasing devices

[2012-04-23 17:26:41 1405] ERROR (XendCheckpoint:421)
/usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 390, in restore
    forkHelper(cmd, fd, handler.handler, True)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 475, in forkHelper
    raise XendError("%s failed" % string.join(cmd))
XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed

[2012-04-23 17:26:41 1405] ERROR (XendDomain:1200) Restore failed
Traceback (most recent call last):

 File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line
1184,
 in domain_restore_fd
    dominfo = XendCheckpoint.restore(self, fd, paused=paused,
relocating=relocating)

File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py", line
422,
in restore
    raise exn
XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed


I would be really appreciated.

Best,
elahe

>
> Jan
>
>
>

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

<div dir=3D"ltr">Hi,<br><br>=A0Thanks for your attention.<br><br><div class=
=3D"gmail_quote">On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <span dir=3D"l=
tr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@sus=
e.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">&gt;&gt;&gt; On 06.06.12 a=
t 09:00, elahe shekuhi &lt;<a href=3D"mailto:e.shekuhi@gmail.com">e.shekuhi=
@gmail.com</a>&gt; wrote:<br>

&gt; I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, bu=
t live<br>
&gt; migration does not work. While the source host works on the &quot;xm m=
igrate -l<br>
&gt; ...&quot; command, I can see the VM on the target host in paused state=
 in &quot;xm<br>
&gt; list&quot;, but after a while it vanishes while the xm command on the =
source<br>
&gt; machine returns whitout any errors.<br>
<br>
</div>Does the guest crash perhaps? In which case a kernel log from it<br>
might turn out pretty useful. As would technical data (rather than<br>
a simple &quot;does not work&quot;) in the first place (hypervisor, xend, a=
nd<br>
Dom0 kernel logs are all possible candidates for holding relevant<br>
information).<br>
<div class=3D"im"><br>
&gt; (One machine has core i7 processor while another is core 2<br>
&gt; quad system).<br>
<br>
</div>Does migration fail in both directions? Or perhaps just from the<br>
newer to the older system (in which case I would guess you&#39;re<br>
not masking features properly on the newer one)?<br></blockquote><div><br>=
=A0=A0 Yes, Migration failed in both directions, but the error in Xend.log =
is different. When I do migrate VM from core 2 quad to core i7 machine the =
error in Xend.log is <br>
<br>[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:237) XendDomainInfo.re=
store([&#39;domain&#39;, [&#39;domid&#39;, &#39;5&#39;], [&#39;cpu_weight&#=
39;, &#39;256&#39;], [&#39;cpu_cap&#39;, &#39;0&#39;], [&#39;pool_name&#39;=
, &#39;Pool-0&#39;], [&#39;bootloader&#39;, &#39;/usr/bin/pygrub&#39;], [&#=
39;vcpus&#39;, &#39;2&#39;], [&#39;cpus&#39;, [[], []]], [&#39;on_poweroff&=
#39;, &#39;destroy&#39;], [&#39;description&#39;, &#39;None&#39;], [&#39;on=
_crash&#39;, &#39;destroy&#39;], [&#39;uuid&#39;, &#39;9d19e419-83ca-e877-5=
2e4-0f93f634354a&#39;], [&#39;bootloader_args&#39;, &#39;-q&#39;], [&#39;na=
me&#39;, &#39;sles11-1&#39;], [&#39;on_reboot&#39;, &#39;restart&#39;], [&#=
39;maxmem&#39;, &#39;1024&#39;], [&#39;memory&#39;, &#39;512&#39;], [&#39;s=
hadow_memory&#39;, &#39;0&#39;], [&#39;vcpu_avail&#39;, &#39;3&#39;], [&#39=
;features&#39;, &#39;&#39;], [&#39;on_xend_start&#39;, &#39;ignore&#39;], [=
&#39;on_xend_stop&#39;, &#39;ignore&#39;], [&#39;start_time&#39;, &#39;1335=
185584.3&#39;], [&#39;cpu_time&#39;, &#39;0.353877786&#39;], [&#39;online_v=
cpus&#39;, &#39;2&#39;], [&#39;image&#39;, [&#39;linux&#39;, [&#39;kernel&#=
39;, &#39;&#39;], [&#39;args&#39;, &#39; &#39;], [&#39;superpages&#39;, &#3=
9;0&#39;], [&#39;videoram&#39;, &#39;4&#39;], [&#39;pci&#39;, []], [&#39;no=
migrate&#39;, &#39;0&#39;], [&#39;tsc_mode&#39;, &#39;0&#39;], [&#39;device=
_model&#39;, &#39;/usr/lib/xen/bin/qemu-dm&#39;], [&#39;notes&#39;, [&#39;F=
EATURES&#39;, &#39;writable_page_tables|writable_descriptor_tables|auto_tra=
nslated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel&#39;], [&#39;VIR=
T_BASE&#39;, &#39;18446744071562067968&#39;], [&#39;GUEST_VERSION&#39;, &#3=
9;2.6&#39;], [&#39;PADDR_OFFSET&#39;, &#39;0&#39;], [&#39;GUEST_OS&#39;, &#=
39;linux&#39;], [&#39;HYPERCALL_PAGE&#39;, &#39;18446744071564193792&#39;],=
 [&#39;LOADER&#39;, &#39;generic&#39;], [&#39;SUSPEND_CANCEL&#39;, &#39;1&#=
39;], [&#39;ENTRY&#39;, &#39;18446744071564165120&#39;], [&#39;XEN_VERSION&=
#39;, &#39;xen-3.0&#39;]]]], [&#39;status&#39;, &#39;2&#39;], [&#39;state&#=
39;, &#39;-b----&#39;], [&#39;store_mfn&#39;, &#39;470107&#39;], [&#39;cons=
ole_mfn&#39;, &#39;470106&#39;], [&#39;device&#39;, [&#39;vif&#39;, [&#39;b=
ridge&#39;, &#39;br0&#39;], [&#39;mac&#39;, &#39;00:16:3e:44:ac:23&#39;], [=
&#39;script&#39;, &#39;/etc/xen/scripts/vif-bridge&#39;], [&#39;uuid&#39;, =
&#39;f3a500be-df8d-a7fe-881e-b8d8347dce74&#39;], [&#39;backend&#39;, &#39;0=
&#39;]]], [&#39;device&#39;, [&#39;vkbd&#39;, [&#39;backend&#39;, &#39;0&#3=
9;]]], [&#39;device&#39;, [&#39;console&#39;, [&#39;protocol&#39;, &#39;vt1=
00&#39;], [&#39;location&#39;, &#39;2&#39;], [&#39;uuid&#39;, &#39;0debd581=
-e78c-c87c-8012-330fa7d0eafb&#39;]]], [&#39;device&#39;, [&#39;vbd&#39;, [&=
#39;protocol&#39;, &#39;x86_64-abi&#39;], [&#39;uuid&#39;, &#39;8e7150c8-4a=
f1-88c0-e71b-16049663cebc&#39;], [&#39;bootable&#39;, &#39;1&#39;], [&#39;d=
ev&#39;, &#39;xvda:disk&#39;], [&#39;uname&#39;, &#39;file:/home/elahe/xen/=
images/sles11-1/disk0.raw&#39;], [&#39;mode&#39;, &#39;w&#39;], [&#39;backe=
nd&#39;, &#39;0&#39;], [&#39;VDI&#39;, &#39;&#39;]]], [&#39;device&#39;, [&=
#39;vbd&#39;, [&#39;protocol&#39;, &#39;x86_64-abi&#39;], [&#39;uuid&#39;, =
&#39;55ff031d-7810-1b41-ed7b-f7fce59c6dcd&#39;], [&#39;bootable&#39;, &#39;=
0&#39;], [&#39;dev&#39;, &#39;xvdb:cdrom&#39;], [&#39;uname&#39;, &#39;phy:=
/dev/sr0&#39;], [&#39;mode&#39;, &#39;r&#39;], [&#39;backend&#39;, &#39;0&#=
39;], [&#39;VDI&#39;, &#39;&#39;]]], [&#39;device&#39;, [&#39;vfb&#39;, [&#=
39;vncunused&#39;, &#39;1&#39;], [&#39;vnc&#39;, &#39;1&#39;], [&#39;xautho=
rity&#39;, &#39;/root/.Xauthority&#39;], [&#39;keymap&#39;, &#39;en-us&#39;=
], [&#39;location&#39;, &#39;127.0.0.1:5900&#39;], [&#39;uuid&#39;, &#39;3d=
8f53d2-97b8-770b-59c7-69ac1cd302fa&#39;]]], [&#39;change_home_server&#39;, =
&#39;False&#39;]])<br>
<br>[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:2562) XendDomainInfo.c=
onstructDomain<br><br>[2012-04-23 17:25:55 1405] DEBUG (balloon:206) Balloo=
n: 538624 KiB free; need 16384; done.<br><br>[2012-04-23 17:25:55 1405] DEB=
UG (XendDomain:482) Adding Domain: 4<br>
<br>[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:3514) Storing VM detai=
ls: {&#39;on_xend_stop&#39;: &#39;ignore&#39;, &#39;pool_name&#39;: &#39;Po=
ol-0&#39;, &#39;shadow_memory&#39;: &#39;0&#39;, &#39;uuid&#39;: &#39;9d19e=
419-83ca-e877-52e4-0f93f634354a&#39;, &#39;on_reboot&#39;: &#39;restart&#39=
;, &#39;start_time&#39;: &#39;1335185584.3&#39;, &#39;on_poweroff&#39;: &#3=
9;destroy&#39;, &#39;bootloader_args&#39;: &#39;-q&#39;, &#39;on_xend_start=
&#39;: &#39;ignore&#39;, &#39;on_crash&#39;: &#39;destroy&#39;, &#39;xend/r=
estart_count&#39;: &#39;0&#39;, &#39;vcpus&#39;: &#39;2&#39;, &#39;vcpu_ava=
il&#39;: &#39;3&#39;, &#39;bootloader&#39;: &#39;/usr/bin/pygrub&#39;, &#39=
;image&#39;: &quot;(linux (kernel &#39;&#39;) (args &#39; &#39;) (superpage=
s 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (device_model /usr/li=
b/xen/bin/qemu-dm) (notes (FEATURES &#39;writable_page_tables|writable_desc=
riptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_k=
ernel&#39;) (VIRT_BASE 18446744071562067968) (GUEST_VERSION 2.6) (PADDR_OFF=
SET 0) (GUEST_OS linux) (HYPERCALL_PAGE 18446744071564193792) (LOADER gener=
ic) (SUSPEND_CANCEL 1) (ENTRY 18446744071564165120) (XEN_VERSION xen-3.0)))=
&quot;, &#39;name&#39;: &#39;sles11-1&#39;}<br>
<br>[2012-04-23 17:25:55 1405] DEBUG (image:343) No VNC passwd configured f=
or vfb access<br><br>[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:359) =
restore:shadow=3D0x0, _static_max=3D0x40000000, _static_min=3D0x0, <br><br>=
[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:386) [xc_restore]: /usr/li=
b64/xen/bin/xc_restore 4 4 1 2 0 0 0 0<br>
<br>[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn&=
#39;t set eXtended States for vcpu0 (22 =3D Invalid argument): Internal err=
or<br><br>[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:3150) XendDomain=
Info.destroy: domid=3D4<br>
<br>[2012-04-23 17:26:41 1405] ERROR (XendDomainInfo:3164) XendDomainInfo.d=
estroy: domain destruction failed.<br>Traceback (most recent call last):<br=
>=A0 File &quot;/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.=
py&quot;, line 3157, in destroy<br>
=A0=A0=A0 xc.domain_pause(self.domid)<br>Error: (3, &#39;No such process&#3=
9;)<br><br>[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2470) No device=
 model<br><br>[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2472) Releas=
ing devices<br>
<br>[2012-04-23 17:26:41 1405] ERROR (XendCheckpoint:421) /usr/lib64/xen/bi=
n/xc_restore 4 4 1 2 0 0 0 0 failed<br>Traceback (most recent call last):<b=
r>=A0 File &quot;/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint=
.py&quot;, line 390, in restore<br>
=A0=A0=A0 forkHelper(cmd, fd, handler.handler, True)<br>=A0 File &quot;/usr=
/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py&quot;, line 475, =
in forkHelper<br>=A0=A0=A0 raise XendError(&quot;%s failed&quot; % string.j=
oin(cmd))<br>
XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed<br><br>[201=
2-04-23 17:26:41 1405] ERROR (XendDomain:1200) Restore failed<br>Traceback =
(most recent call last):<br>=A0<br>=A0File &quot;/usr/lib64/python2.7/site-=
packages/xen/xend/XendDomain.py&quot;, line 1184,<br>
=A0in domain_restore_fd<br>=A0=A0=A0 dominfo =3D XendCheckpoint.restore(sel=
f, fd, paused=3Dpaused, relocating=3Drelocating)<br>=A0 <br>File &quot;/usr=
/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py&quot;, line 422, =
<br>in restore<br>
=A0=A0=A0 raise exn<br>XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0=
 0 0 failed<br><br><br>I would be really appreciated.<br><br>Best,<br>elahe=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--00504502e0c7b179b604c1d1c113--


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

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

--===============2490621950705802286==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 18:16:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18: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 1ScKlu-0003ac-4I; Wed, 06 Jun 2012 18:15:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1ScKls-0003aX-A5
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:15:52 +0000
Received: from [85.158.138.51:55246] by server-6.bemta-3.messagelabs.com id
	2A/03-05063-75E9FCF4; Wed, 06 Jun 2012 18:15:51 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339006550!24766834!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4423 invoked from network); 6 Jun 2012 18:15:50 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 18:15:50 -0000
Received: by wgbed3 with SMTP id ed3so4688012wgb.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 11:15:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=5KZDVaiqr65GHAWed61qtbldQCTe3q9d86iFcDjmOQg=;
	b=R8Sa2itu4nlfsEqfy6Jk43nPDoWUOwFzPwHQLAc8L0NOOox1GiZIqZmzU28+TLZhRN
	YSDE9oFm/LNTVcun5NyG/l7tY1kHWsinCaytOxFvamPaIzT8TUNhFfsTBurVdR6Qybd3
	Z0m1n6OMyimeDn5ALrVveQ2kfD1yqr2mu8pj2bM3ubwUniSb36gMV1+pUynGUM75O6Ae
	QS7o3Fq3WtMz1GaGk5ueevsDPm1+hFXzRTZZXc0Zc27l6yLah6qtgZUOfgcxFhwPgrPM
	xfk1Iz3xYdHeCdFc7Hw13IqxzJe3YIXoXNVMvJ/J+0ynCW3SLxOjKtQH5LxMd7DFXoEK
	5ThA==
MIME-Version: 1.0
Received: by 10.216.217.228 with SMTP id i78mr17527434wep.126.1339006548801;
	Wed, 06 Jun 2012 11:15:48 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Wed, 6 Jun 2012 11:15:48 -0700 (PDT)
In-Reply-To: <4FCF25E7020000780008866D@nat28.tlf.novell.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
Date: Wed, 6 Jun 2012 19:15:48 +0100
Message-ID: <CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2490621950705802286=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2490621950705802286==
Content-Type: multipart/alternative; boundary=00504502e0c7b179b604c1d1c113

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

Hi,

 Thanks for your attention.

On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 06.06.12 at 09:00, elahe shekuhi <e.shekuhi@gmail.com> wrote:
> > I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, but
> live
> > migration does not work. While the source host works on the "xm migrate
> -l
> > ..." command, I can see the VM on the target host in paused state in "xm
> > list", but after a while it vanishes while the xm command on the source
> > machine returns whitout any errors.
>
> Does the guest crash perhaps? In which case a kernel log from it
> might turn out pretty useful. As would technical data (rather than
> a simple "does not work") in the first place (hypervisor, xend, and
> Dom0 kernel logs are all possible candidates for holding relevant
> information).
>
> > (One machine has core i7 processor while another is core 2
> > quad system).
>
> Does migration fail in both directions? Or perhaps just from the
> newer to the older system (in which case I would guess you're
> not masking features properly on the newer one)?
>

   Yes, Migration failed in both directions, but the error in Xend.log is
different. When I do migrate VM from core 2 quad to core i7 machine the
error in Xend.log is

[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:237)
XendDomainInfo.restore(['domain', ['domid', '5'], ['cpu_weight', '256'],
['cpu_cap', '0'], ['pool_name', 'Pool-0'], ['bootloader',
'/usr/bin/pygrub'], ['vcpus', '2'], ['cpus', [[], []]], ['on_poweroff',
'destroy'], ['description', 'None'], ['on_crash', 'destroy'], ['uuid',
'9d19e419-83ca-e877-52e4-0f93f634354a'], ['bootloader_args', '-q'],
['name', 'sles11-1'], ['on_reboot', 'restart'], ['maxmem', '1024'],
['memory', '512'], ['shadow_memory', '0'], ['vcpu_avail', '3'],
['features', ''], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'],
['start_time', '1335185584.3'], ['cpu_time', '0.353877786'],
['online_vcpus', '2'], ['image', ['linux', ['kernel', ''], ['args', ' '],
['superpages', '0'], ['videoram', '4'], ['pci', []], ['nomigrate', '0'],
['tsc_mode', '0'], ['device_model', '/usr/lib/xen/bin/qemu-dm'], ['notes',
['FEATURES',
'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel'],
['VIRT_BASE', '18446744071562067968'], ['GUEST_VERSION', '2.6'],
['PADDR_OFFSET', '0'], ['GUEST_OS', 'linux'], ['HYPERCALL_PAGE',
'18446744071564193792'], ['LOADER', 'generic'], ['SUSPEND_CANCEL', '1'],
['ENTRY', '18446744071564165120'], ['XEN_VERSION', 'xen-3.0']]]],
['status', '2'], ['state', '-b----'], ['store_mfn', '470107'],
['console_mfn', '470106'], ['device', ['vif', ['bridge', 'br0'], ['mac',
'00:16:3e:44:ac:23'], ['script', '/etc/xen/scripts/vif-bridge'], ['uuid',
'f3a500be-df8d-a7fe-881e-b8d8347dce74'], ['backend', '0']]], ['device',
['vkbd', ['backend', '0']]], ['device', ['console', ['protocol', 'vt100'],
['location', '2'], ['uuid', '0debd581-e78c-c87c-8012-330fa7d0eafb']]],
['device', ['vbd', ['protocol', 'x86_64-abi'], ['uuid',
'8e7150c8-4af1-88c0-e71b-16049663cebc'], ['bootable', '1'], ['dev',
'xvda:disk'], ['uname', 'file:/home/elahe/xen/images/sles11-1/disk0.raw'],
['mode', 'w'], ['backend', '0'], ['VDI', '']]], ['device', ['vbd',
['protocol', 'x86_64-abi'], ['uuid',
'55ff031d-7810-1b41-ed7b-f7fce59c6dcd'], ['bootable', '0'], ['dev',
'xvdb:cdrom'], ['uname', 'phy:/dev/sr0'], ['mode', 'r'], ['backend', '0'],
['VDI', '']]], ['device', ['vfb', ['vncunused', '1'], ['vnc', '1'],
['xauthority', '/root/.Xauthority'], ['keymap', 'en-us'], ['location',
'127.0.0.1:5900'], ['uuid', '3d8f53d2-97b8-770b-59c7-69ac1cd302fa']]],
['change_home_server', 'False']])

[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:2562)
XendDomainInfo.constructDomain

[2012-04-23 17:25:55 1405] DEBUG (balloon:206) Balloon: 538624 KiB free;
need 16384; done.

[2012-04-23 17:25:55 1405] DEBUG (XendDomain:482) Adding Domain: 4

[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:3514) Storing VM details:
{'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0',
'uuid': '9d19e419-83ca-e877-52e4-0f93f634354a', 'on_reboot': 'restart',
'start_time': '1335185584.3', 'on_poweroff': 'destroy', 'bootloader_args':
'-q', 'on_xend_start': 'ignore', 'on_crash': 'destroy',
'xend/restart_count': '0', 'vcpus': '2', 'vcpu_avail': '3', 'bootloader':
'/usr/bin/pygrub', 'image': "(linux (kernel '') (args ' ') (superpages 0)
(videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (device_model
/usr/lib/xen/bin/qemu-dm) (notes (FEATURES
'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel')
(VIRT_BASE 18446744071562067968) (GUEST_VERSION 2.6) (PADDR_OFFSET 0)
(GUEST_OS linux) (HYPERCALL_PAGE 18446744071564193792) (LOADER generic)
(SUSPEND_CANCEL 1) (ENTRY 18446744071564165120) (XEN_VERSION xen-3.0)))",
'name': 'sles11-1'}

[2012-04-23 17:25:55 1405] DEBUG (image:343) No VNC passwd configured for
vfb access

[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:359) restore:shadow=0x0,
_static_max=0x40000000, _static_min=0x0,

[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:386) [xc_restore]:
/usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0

[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn't
set eXtended States for vcpu0 (22 = Invalid argument): Internal error

[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:3150)
XendDomainInfo.destroy: domid=4

[2012-04-23 17:26:41 1405] ERROR (XendDomainInfo:3164)
XendDomainInfo.destroy: domain destruction failed.
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py",
line 3157, in destroy
    xc.domain_pause(self.domid)
Error: (3, 'No such process')

[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2470) No device model

[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2472) Releasing devices

[2012-04-23 17:26:41 1405] ERROR (XendCheckpoint:421)
/usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 390, in restore
    forkHelper(cmd, fd, handler.handler, True)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 475, in forkHelper
    raise XendError("%s failed" % string.join(cmd))
XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed

[2012-04-23 17:26:41 1405] ERROR (XendDomain:1200) Restore failed
Traceback (most recent call last):

 File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line
1184,
 in domain_restore_fd
    dominfo = XendCheckpoint.restore(self, fd, paused=paused,
relocating=relocating)

File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py", line
422,
in restore
    raise exn
XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed


I would be really appreciated.

Best,
elahe

>
> Jan
>
>
>

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

<div dir=3D"ltr">Hi,<br><br>=A0Thanks for your attention.<br><br><div class=
=3D"gmail_quote">On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <span dir=3D"l=
tr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@sus=
e.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">&gt;&gt;&gt; On 06.06.12 a=
t 09:00, elahe shekuhi &lt;<a href=3D"mailto:e.shekuhi@gmail.com">e.shekuhi=
@gmail.com</a>&gt; wrote:<br>

&gt; I have setup Xen 4.1.2 on OpenSuse 12.1. It is running fine so far, bu=
t live<br>
&gt; migration does not work. While the source host works on the &quot;xm m=
igrate -l<br>
&gt; ...&quot; command, I can see the VM on the target host in paused state=
 in &quot;xm<br>
&gt; list&quot;, but after a while it vanishes while the xm command on the =
source<br>
&gt; machine returns whitout any errors.<br>
<br>
</div>Does the guest crash perhaps? In which case a kernel log from it<br>
might turn out pretty useful. As would technical data (rather than<br>
a simple &quot;does not work&quot;) in the first place (hypervisor, xend, a=
nd<br>
Dom0 kernel logs are all possible candidates for holding relevant<br>
information).<br>
<div class=3D"im"><br>
&gt; (One machine has core i7 processor while another is core 2<br>
&gt; quad system).<br>
<br>
</div>Does migration fail in both directions? Or perhaps just from the<br>
newer to the older system (in which case I would guess you&#39;re<br>
not masking features properly on the newer one)?<br></blockquote><div><br>=
=A0=A0 Yes, Migration failed in both directions, but the error in Xend.log =
is different. When I do migrate VM from core 2 quad to core i7 machine the =
error in Xend.log is <br>
<br>[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:237) XendDomainInfo.re=
store([&#39;domain&#39;, [&#39;domid&#39;, &#39;5&#39;], [&#39;cpu_weight&#=
39;, &#39;256&#39;], [&#39;cpu_cap&#39;, &#39;0&#39;], [&#39;pool_name&#39;=
, &#39;Pool-0&#39;], [&#39;bootloader&#39;, &#39;/usr/bin/pygrub&#39;], [&#=
39;vcpus&#39;, &#39;2&#39;], [&#39;cpus&#39;, [[], []]], [&#39;on_poweroff&=
#39;, &#39;destroy&#39;], [&#39;description&#39;, &#39;None&#39;], [&#39;on=
_crash&#39;, &#39;destroy&#39;], [&#39;uuid&#39;, &#39;9d19e419-83ca-e877-5=
2e4-0f93f634354a&#39;], [&#39;bootloader_args&#39;, &#39;-q&#39;], [&#39;na=
me&#39;, &#39;sles11-1&#39;], [&#39;on_reboot&#39;, &#39;restart&#39;], [&#=
39;maxmem&#39;, &#39;1024&#39;], [&#39;memory&#39;, &#39;512&#39;], [&#39;s=
hadow_memory&#39;, &#39;0&#39;], [&#39;vcpu_avail&#39;, &#39;3&#39;], [&#39=
;features&#39;, &#39;&#39;], [&#39;on_xend_start&#39;, &#39;ignore&#39;], [=
&#39;on_xend_stop&#39;, &#39;ignore&#39;], [&#39;start_time&#39;, &#39;1335=
185584.3&#39;], [&#39;cpu_time&#39;, &#39;0.353877786&#39;], [&#39;online_v=
cpus&#39;, &#39;2&#39;], [&#39;image&#39;, [&#39;linux&#39;, [&#39;kernel&#=
39;, &#39;&#39;], [&#39;args&#39;, &#39; &#39;], [&#39;superpages&#39;, &#3=
9;0&#39;], [&#39;videoram&#39;, &#39;4&#39;], [&#39;pci&#39;, []], [&#39;no=
migrate&#39;, &#39;0&#39;], [&#39;tsc_mode&#39;, &#39;0&#39;], [&#39;device=
_model&#39;, &#39;/usr/lib/xen/bin/qemu-dm&#39;], [&#39;notes&#39;, [&#39;F=
EATURES&#39;, &#39;writable_page_tables|writable_descriptor_tables|auto_tra=
nslated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel&#39;], [&#39;VIR=
T_BASE&#39;, &#39;18446744071562067968&#39;], [&#39;GUEST_VERSION&#39;, &#3=
9;2.6&#39;], [&#39;PADDR_OFFSET&#39;, &#39;0&#39;], [&#39;GUEST_OS&#39;, &#=
39;linux&#39;], [&#39;HYPERCALL_PAGE&#39;, &#39;18446744071564193792&#39;],=
 [&#39;LOADER&#39;, &#39;generic&#39;], [&#39;SUSPEND_CANCEL&#39;, &#39;1&#=
39;], [&#39;ENTRY&#39;, &#39;18446744071564165120&#39;], [&#39;XEN_VERSION&=
#39;, &#39;xen-3.0&#39;]]]], [&#39;status&#39;, &#39;2&#39;], [&#39;state&#=
39;, &#39;-b----&#39;], [&#39;store_mfn&#39;, &#39;470107&#39;], [&#39;cons=
ole_mfn&#39;, &#39;470106&#39;], [&#39;device&#39;, [&#39;vif&#39;, [&#39;b=
ridge&#39;, &#39;br0&#39;], [&#39;mac&#39;, &#39;00:16:3e:44:ac:23&#39;], [=
&#39;script&#39;, &#39;/etc/xen/scripts/vif-bridge&#39;], [&#39;uuid&#39;, =
&#39;f3a500be-df8d-a7fe-881e-b8d8347dce74&#39;], [&#39;backend&#39;, &#39;0=
&#39;]]], [&#39;device&#39;, [&#39;vkbd&#39;, [&#39;backend&#39;, &#39;0&#3=
9;]]], [&#39;device&#39;, [&#39;console&#39;, [&#39;protocol&#39;, &#39;vt1=
00&#39;], [&#39;location&#39;, &#39;2&#39;], [&#39;uuid&#39;, &#39;0debd581=
-e78c-c87c-8012-330fa7d0eafb&#39;]]], [&#39;device&#39;, [&#39;vbd&#39;, [&=
#39;protocol&#39;, &#39;x86_64-abi&#39;], [&#39;uuid&#39;, &#39;8e7150c8-4a=
f1-88c0-e71b-16049663cebc&#39;], [&#39;bootable&#39;, &#39;1&#39;], [&#39;d=
ev&#39;, &#39;xvda:disk&#39;], [&#39;uname&#39;, &#39;file:/home/elahe/xen/=
images/sles11-1/disk0.raw&#39;], [&#39;mode&#39;, &#39;w&#39;], [&#39;backe=
nd&#39;, &#39;0&#39;], [&#39;VDI&#39;, &#39;&#39;]]], [&#39;device&#39;, [&=
#39;vbd&#39;, [&#39;protocol&#39;, &#39;x86_64-abi&#39;], [&#39;uuid&#39;, =
&#39;55ff031d-7810-1b41-ed7b-f7fce59c6dcd&#39;], [&#39;bootable&#39;, &#39;=
0&#39;], [&#39;dev&#39;, &#39;xvdb:cdrom&#39;], [&#39;uname&#39;, &#39;phy:=
/dev/sr0&#39;], [&#39;mode&#39;, &#39;r&#39;], [&#39;backend&#39;, &#39;0&#=
39;], [&#39;VDI&#39;, &#39;&#39;]]], [&#39;device&#39;, [&#39;vfb&#39;, [&#=
39;vncunused&#39;, &#39;1&#39;], [&#39;vnc&#39;, &#39;1&#39;], [&#39;xautho=
rity&#39;, &#39;/root/.Xauthority&#39;], [&#39;keymap&#39;, &#39;en-us&#39;=
], [&#39;location&#39;, &#39;127.0.0.1:5900&#39;], [&#39;uuid&#39;, &#39;3d=
8f53d2-97b8-770b-59c7-69ac1cd302fa&#39;]]], [&#39;change_home_server&#39;, =
&#39;False&#39;]])<br>
<br>[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:2562) XendDomainInfo.c=
onstructDomain<br><br>[2012-04-23 17:25:55 1405] DEBUG (balloon:206) Balloo=
n: 538624 KiB free; need 16384; done.<br><br>[2012-04-23 17:25:55 1405] DEB=
UG (XendDomain:482) Adding Domain: 4<br>
<br>[2012-04-23 17:25:55 1405] DEBUG (XendDomainInfo:3514) Storing VM detai=
ls: {&#39;on_xend_stop&#39;: &#39;ignore&#39;, &#39;pool_name&#39;: &#39;Po=
ol-0&#39;, &#39;shadow_memory&#39;: &#39;0&#39;, &#39;uuid&#39;: &#39;9d19e=
419-83ca-e877-52e4-0f93f634354a&#39;, &#39;on_reboot&#39;: &#39;restart&#39=
;, &#39;start_time&#39;: &#39;1335185584.3&#39;, &#39;on_poweroff&#39;: &#3=
9;destroy&#39;, &#39;bootloader_args&#39;: &#39;-q&#39;, &#39;on_xend_start=
&#39;: &#39;ignore&#39;, &#39;on_crash&#39;: &#39;destroy&#39;, &#39;xend/r=
estart_count&#39;: &#39;0&#39;, &#39;vcpus&#39;: &#39;2&#39;, &#39;vcpu_ava=
il&#39;: &#39;3&#39;, &#39;bootloader&#39;: &#39;/usr/bin/pygrub&#39;, &#39=
;image&#39;: &quot;(linux (kernel &#39;&#39;) (args &#39; &#39;) (superpage=
s 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (device_model /usr/li=
b/xen/bin/qemu-dm) (notes (FEATURES &#39;writable_page_tables|writable_desc=
riptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_k=
ernel&#39;) (VIRT_BASE 18446744071562067968) (GUEST_VERSION 2.6) (PADDR_OFF=
SET 0) (GUEST_OS linux) (HYPERCALL_PAGE 18446744071564193792) (LOADER gener=
ic) (SUSPEND_CANCEL 1) (ENTRY 18446744071564165120) (XEN_VERSION xen-3.0)))=
&quot;, &#39;name&#39;: &#39;sles11-1&#39;}<br>
<br>[2012-04-23 17:25:55 1405] DEBUG (image:343) No VNC passwd configured f=
or vfb access<br><br>[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:359) =
restore:shadow=3D0x0, _static_max=3D0x40000000, _static_min=3D0x0, <br><br>=
[2012-04-23 17:25:55 1405] DEBUG (XendCheckpoint:386) [xc_restore]: /usr/li=
b64/xen/bin/xc_restore 4 4 1 2 0 0 0 0<br>
<br>[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn&=
#39;t set eXtended States for vcpu0 (22 =3D Invalid argument): Internal err=
or<br><br>[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:3150) XendDomain=
Info.destroy: domid=3D4<br>
<br>[2012-04-23 17:26:41 1405] ERROR (XendDomainInfo:3164) XendDomainInfo.d=
estroy: domain destruction failed.<br>Traceback (most recent call last):<br=
>=A0 File &quot;/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.=
py&quot;, line 3157, in destroy<br>
=A0=A0=A0 xc.domain_pause(self.domid)<br>Error: (3, &#39;No such process&#3=
9;)<br><br>[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2470) No device=
 model<br><br>[2012-04-23 17:26:41 1405] DEBUG (XendDomainInfo:2472) Releas=
ing devices<br>
<br>[2012-04-23 17:26:41 1405] ERROR (XendCheckpoint:421) /usr/lib64/xen/bi=
n/xc_restore 4 4 1 2 0 0 0 0 failed<br>Traceback (most recent call last):<b=
r>=A0 File &quot;/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint=
.py&quot;, line 390, in restore<br>
=A0=A0=A0 forkHelper(cmd, fd, handler.handler, True)<br>=A0 File &quot;/usr=
/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py&quot;, line 475, =
in forkHelper<br>=A0=A0=A0 raise XendError(&quot;%s failed&quot; % string.j=
oin(cmd))<br>
XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0 0 0 failed<br><br>[201=
2-04-23 17:26:41 1405] ERROR (XendDomain:1200) Restore failed<br>Traceback =
(most recent call last):<br>=A0<br>=A0File &quot;/usr/lib64/python2.7/site-=
packages/xen/xend/XendDomain.py&quot;, line 1184,<br>
=A0in domain_restore_fd<br>=A0=A0=A0 dominfo =3D XendCheckpoint.restore(sel=
f, fd, paused=3Dpaused, relocating=3Drelocating)<br>=A0 <br>File &quot;/usr=
/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py&quot;, line 422, =
<br>in restore<br>
=A0=A0=A0 raise exn<br>XendError: /usr/lib64/xen/bin/xc_restore 4 4 1 2 0 0=
 0 0 failed<br><br><br>I would be really appreciated.<br><br>Best,<br>elahe=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--00504502e0c7b179b604c1d1c113--


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

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

--===============2490621950705802286==--


From xen-devel-bounces@lists.xen.org Wed Jun 06 18:19:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18: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 1ScKot-0003hm-TE; Wed, 06 Jun 2012 18:18:59 +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 1ScKor-0003he-MQ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:18:57 +0000
Received: from [85.158.139.83:48224] by server-12.bemta-5.messagelabs.com id
	83/D7-18374-01F9FCF4; Wed, 06 Jun 2012 18:18:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339006735!18476786!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5375 invoked from network); 6 Jun 2012 18:18:56 -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; 6 Jun 2012 18:18:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScKom-000Fcb-Jr; Wed, 06 Jun 2012 18:18:52 +0000
Date: Wed, 6 Jun 2012 19:18:52 +0100
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120606181852.GB38649@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
	paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:04 +0100 on 06 Jun (1339009473), Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/mm.c |    8 ++++++++
> >  1 files changed, 8 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > index 160a4e9..ab52171 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> >      lpae_t pte, *p;
> >      int i;
> >  
> > +    if ( boot_phys_offset != 0 )
> > +    {
> > +        /* Remove the old identity mapping of the boot paddr */
> > +        pte.bits = 0;
> > +        dest_va = (unsigned long)_start + boot_phys_offset;
> > +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> > +    }
> 
> It looks like we are already doing this few lines below.

We used to do this here and now we do it futher down, after the copy.
That way the secondary CPUs can come up on the pre-copy tables where
the identity map still exists.

> Also now that I am thinking about it, considering that bits is a 64 bit
> field, shouldn't this be:
> 
> pte.bits = 0ULL;

It's OK; the 0 will be sign-extended by the compiler to 64 bits. 

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 18:19:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 18: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 1ScKot-0003hm-TE; Wed, 06 Jun 2012 18:18:59 +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 1ScKor-0003he-MQ
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 18:18:57 +0000
Received: from [85.158.139.83:48224] by server-12.bemta-5.messagelabs.com id
	83/D7-18374-01F9FCF4; Wed, 06 Jun 2012 18:18:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339006735!18476786!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5375 invoked from network); 6 Jun 2012 18:18:56 -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; 6 Jun 2012 18:18:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScKom-000Fcb-Jr; Wed, 06 Jun 2012 18:18:52 +0000
Date: Wed, 6 Jun 2012 19:18:52 +0100
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120606181852.GB38649@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
	paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:04 +0100 on 06 Jun (1339009473), Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/mm.c |    8 ++++++++
> >  1 files changed, 8 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > index 160a4e9..ab52171 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> >      lpae_t pte, *p;
> >      int i;
> >  
> > +    if ( boot_phys_offset != 0 )
> > +    {
> > +        /* Remove the old identity mapping of the boot paddr */
> > +        pte.bits = 0;
> > +        dest_va = (unsigned long)_start + boot_phys_offset;
> > +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> > +    }
> 
> It looks like we are already doing this few lines below.

We used to do this here and now we do it futher down, after the copy.
That way the secondary CPUs can come up on the pre-copy tables where
the identity map still exists.

> Also now that I am thinking about it, considering that bits is a 64 bit
> field, shouldn't this be:
> 
> pte.bits = 0ULL;

It's OK; the 0 will be sign-extended by the compiler to 64 bits. 

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 19:09:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 19: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 1ScLbj-0004Mm-4h; Wed, 06 Jun 2012 19:09:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ScLbh-0004Md-0b
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 19:09:25 +0000
Received: from [193.109.254.147:30752] by server-8.bemta-14.messagelabs.com id
	D8/B0-27132-4EAAFCF4; Wed, 06 Jun 2012 19:09:24 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339009762!13099141!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4637 invoked from network); 6 Jun 2012 19:09:23 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 19:09:23 -0000
Received: by obbwd20 with SMTP id wd20so14311666obb.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 12:09:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=muZRzCr6xQDiJZKOI2XnH9c0x1tZsSGkdrQT5hne09w=;
	b=lQzUwnVM68z5qLfLllAzRGeyIwRYXXP01xWwS/yjsOSiu4kEVhqlxXmoAOiODdnTBM
	KbaAZXQYeK/z6ojcmewcf2CXWvoLTecv5CRAC6Br1dtrtTXVWxeuJ1AYRlhiLzYE6bQD
	Jimz5iARjMnpWG2i5rfIy2FCFcCAalGBEDT1tuqvr395+r3pQj2d5Cb3491vWOl2g0SW
	PAZmAkGFUzwdjq9c84rFynWMYwniH1G2I+TUFFRutg5AJew3zk3RA2lGjhelsRtx5BL7
	dfdrVWG1CIxTK9z4HJxbAEg34AqOqnAr4Tu8zWGDqOf34HjR09dBSK2iGRarsaXoQ2Ej
	cYqQ==
Received: by 10.182.112.102 with SMTP id ip6mr21683883obb.39.1339009761761;
	Wed, 06 Jun 2012 12:09:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.204.99 with HTTP; Wed, 6 Jun 2012 12:09:01 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FCF78BD.3040909@xen.org>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
From: Rolu <rolu@roce.org>
Date: Wed, 6 Jun 2012 21:09:01 +0200
Message-ID: <CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
To: lars.kurth@xen.org
X-Gm-Message-State: ALoCoQlhXfgBc5nUgseSAMJLjgkxOkBckkNVNNg4fJHxePm+dwk5jx/bDUO4WR0602wMyezn3m+h
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 6, 2012 at 5:35 PM, Lars Kurth <lars.kurth@xen.org> wrote:
> On 01/06/2012 18:54, Ian Jackson wrote:
>>
>> Lars Kurth writes ("[Xen-devel] Proposals/changes for a new Wiki
>> Front-Page - need input/mods/creative proposals"):
>>>
>>> - http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case
>>> focussed
>>> front-page
>>
>> This one is already much better than the existing front page. =A0I have
>> made some more changes.
>
> Great!
>

I agree it's much better. Since the main categories are "help with
xen" and "help with xcp" it would be nice if there were a few lines at
the top of the page explaining which is which, so (new) people can
have a better idea of where to look. The descriptions from
http://xen.org/products/ and a link to
http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
The latter is already linked in the "getting started with xen" column
but would be better off at the top since it gives a feature table of
both.

>> The links under "Xen Docs" are rather poor. =A0I don't know what pages
>> we have that would do better, but the top link being the Wiki category
>> listing is quite unhelpful.
>
> Would a ...
> 1) link to http://wiki.xen.org/wiki/Xen_4.x_Manuals instead of
> http://wiki.xen.org/wiki/Category:Manual be better?
> 2) We could move http://wiki.xen.org/wiki/Xen_Beginners_Guide one up - it=
 is
> a step-by-step tutorial to set up Xen 4 with Squeeze
>
> Part of the problem is that there is a lot of stuff and it is hard to cho=
ose
> what is relevant
>

As someone who started with Xen not long ago, I much prefer dedicated
link pages over Category: pages. The latter just give a big unsorted
(alphabetical doesn't count, needs to be sorted by subtopic to be a
useful sort) list of pages of widely varying scope and usefulness.
It's better than nothing, sure, but a page that sorts them by topic or
purpose or something (much like this proposed front page really) is a
lot better.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 19:09:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 19: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 1ScLbj-0004Mm-4h; Wed, 06 Jun 2012 19:09:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ScLbh-0004Md-0b
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 19:09:25 +0000
Received: from [193.109.254.147:30752] by server-8.bemta-14.messagelabs.com id
	D8/B0-27132-4EAAFCF4; Wed, 06 Jun 2012 19:09:24 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339009762!13099141!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4637 invoked from network); 6 Jun 2012 19:09:23 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 19:09:23 -0000
Received: by obbwd20 with SMTP id wd20so14311666obb.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 12:09:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=muZRzCr6xQDiJZKOI2XnH9c0x1tZsSGkdrQT5hne09w=;
	b=lQzUwnVM68z5qLfLllAzRGeyIwRYXXP01xWwS/yjsOSiu4kEVhqlxXmoAOiODdnTBM
	KbaAZXQYeK/z6ojcmewcf2CXWvoLTecv5CRAC6Br1dtrtTXVWxeuJ1AYRlhiLzYE6bQD
	Jimz5iARjMnpWG2i5rfIy2FCFcCAalGBEDT1tuqvr395+r3pQj2d5Cb3491vWOl2g0SW
	PAZmAkGFUzwdjq9c84rFynWMYwniH1G2I+TUFFRutg5AJew3zk3RA2lGjhelsRtx5BL7
	dfdrVWG1CIxTK9z4HJxbAEg34AqOqnAr4Tu8zWGDqOf34HjR09dBSK2iGRarsaXoQ2Ej
	cYqQ==
Received: by 10.182.112.102 with SMTP id ip6mr21683883obb.39.1339009761761;
	Wed, 06 Jun 2012 12:09:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.204.99 with HTTP; Wed, 6 Jun 2012 12:09:01 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FCF78BD.3040909@xen.org>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
From: Rolu <rolu@roce.org>
Date: Wed, 6 Jun 2012 21:09:01 +0200
Message-ID: <CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
To: lars.kurth@xen.org
X-Gm-Message-State: ALoCoQlhXfgBc5nUgseSAMJLjgkxOkBckkNVNNg4fJHxePm+dwk5jx/bDUO4WR0602wMyezn3m+h
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 6, 2012 at 5:35 PM, Lars Kurth <lars.kurth@xen.org> wrote:
> On 01/06/2012 18:54, Ian Jackson wrote:
>>
>> Lars Kurth writes ("[Xen-devel] Proposals/changes for a new Wiki
>> Front-Page - need input/mods/creative proposals"):
>>>
>>> - http://wiki.xen.org/wiki/Proposals/Main_Page1 : a more use-case
>>> focussed
>>> front-page
>>
>> This one is already much better than the existing front page. =A0I have
>> made some more changes.
>
> Great!
>

I agree it's much better. Since the main categories are "help with
xen" and "help with xcp" it would be nice if there were a few lines at
the top of the page explaining which is which, so (new) people can
have a better idea of where to look. The descriptions from
http://xen.org/products/ and a link to
http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
The latter is already linked in the "getting started with xen" column
but would be better off at the top since it gives a feature table of
both.

>> The links under "Xen Docs" are rather poor. =A0I don't know what pages
>> we have that would do better, but the top link being the Wiki category
>> listing is quite unhelpful.
>
> Would a ...
> 1) link to http://wiki.xen.org/wiki/Xen_4.x_Manuals instead of
> http://wiki.xen.org/wiki/Category:Manual be better?
> 2) We could move http://wiki.xen.org/wiki/Xen_Beginners_Guide one up - it=
 is
> a step-by-step tutorial to set up Xen 4 with Squeeze
>
> Part of the problem is that there is a lot of stuff and it is hard to cho=
ose
> what is relevant
>

As someone who started with Xen not long ago, I much prefer dedicated
link pages over Category: pages. The latter just give a big unsorted
(alphabetical doesn't count, needs to be sorted by subtopic to be a
useful sort) list of pages of widely varying scope and usefulness.
It's better than nothing, sure, but a page that sorts them by topic or
purpose or something (much like this proposed front page really) is a
lot better.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 19:56:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 19:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScMKi-0005F5-27; Wed, 06 Jun 2012 19:55:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paton@cs.wisc.edu>) id 1ScMKg-0005F0-Fg
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 19:55:54 +0000
Received: from [85.158.143.99:48477] by server-2.bemta-4.messagelabs.com id
	38/5B-17938-9C5BFCF4; Wed, 06 Jun 2012 19:55:53 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339012551!21982556!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21852 invoked from network); 6 Jun 2012 19:55:52 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jun 2012 19:55:52 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q56JtlwJ027791
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 6 Jun 2012 14:55:48 -0500
Mime-Version: 1.0 (Apple Message framework v1278)
From: James Paton <paton@cs.wisc.edu>
In-Reply-To: <20120606125047.GA12043@router-fw-old.local.net-space.pl>
Date: Wed, 6 Jun 2012 14:55:42 -0500
Message-Id: <BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
To: Daniel Kiper <dkiper@net-space.pl>
X-Mailer: Apple Mail (2.1278)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 everyone for your help.

I tried the suggestion of leaving ttyS1 out of the Xen boot options and using that. I confirmed that I can echo things back and forth through that connection from the host OS. I compiled a custom version of gdb to target x86_64-linux-gnu so I could do remote debugging from the host. No luck. I also tried setting console=ttyS1 for the dom0 kernel -- same outcome.

Next, using exactly the same settings, I booted the dom0 kernel bare (no Xen this time) and tried the same thing. This time, it worked. I can connect the debugger and it breaks as expected. So I'm thinking debugging while running Xen over serial is a dead end, unless I figure out a way to do it over hvc. I think for now I'll just use printk.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 19:56:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 19:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScMKi-0005F5-27; Wed, 06 Jun 2012 19:55:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paton@cs.wisc.edu>) id 1ScMKg-0005F0-Fg
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 19:55:54 +0000
Received: from [85.158.143.99:48477] by server-2.bemta-4.messagelabs.com id
	38/5B-17938-9C5BFCF4; Wed, 06 Jun 2012 19:55:53 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339012551!21982556!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21852 invoked from network); 6 Jun 2012 19:55:52 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jun 2012 19:55:52 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q56JtlwJ027791
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 6 Jun 2012 14:55:48 -0500
Mime-Version: 1.0 (Apple Message framework v1278)
From: James Paton <paton@cs.wisc.edu>
In-Reply-To: <20120606125047.GA12043@router-fw-old.local.net-space.pl>
Date: Wed, 6 Jun 2012 14:55:42 -0500
Message-Id: <BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
To: Daniel Kiper <dkiper@net-space.pl>
X-Mailer: Apple Mail (2.1278)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 everyone for your help.

I tried the suggestion of leaving ttyS1 out of the Xen boot options and using that. I confirmed that I can echo things back and forth through that connection from the host OS. I compiled a custom version of gdb to target x86_64-linux-gnu so I could do remote debugging from the host. No luck. I also tried setting console=ttyS1 for the dom0 kernel -- same outcome.

Next, using exactly the same settings, I booted the dom0 kernel bare (no Xen this time) and tried the same thing. This time, it worked. I can connect the debugger and it breaks as expected. So I'm thinking debugging while running Xen over serial is a dead end, unless I figure out a way to do it over hvc. I think for now I'll just use printk.

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20: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 1ScMce-0005e6-SG; Wed, 06 Jun 2012 20:14:28 +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 1ScMcd-0005e1-3M
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:27 +0000
Received: from [193.109.254.147:54818] by server-11.bemta-14.messagelabs.com
	id 22/57-02727-22ABFCF4; Wed, 06 Jun 2012 20:14:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339013664!7976994!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NTE3MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30587 invoked from network); 6 Jun 2012 20:14:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 20:14:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KDtiM005761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:13:56 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
	q56KDr0S005274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:13:54 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q56KDoYD004354; Wed, 6 Jun 2012 15:13:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:13:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 32AD14030D; Wed,  6 Jun 2012 16:06:51 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:06:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200651.GA9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-2-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-2-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/4] x86, pvops: Remove hooks for {rd,
	wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:52:35PM +0200, Borislav Petkov wrote:
> From: Andre Przywara <andre.przywara@amd.com>
> 
> There were paravirt_ops hooks for the full register set variant of
> {rd,wr}msr_safe which are actually not used by anyone anymore. Remove
> them to make the code cleaner and avoid silent breakages when the pvops
> members were uninitialized. This has been boot-tested natively and under
> Xen with PVOPS enabled and disabled on one machine.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
>  arch/x86/include/asm/paravirt.h       |   39 -------------------
>  arch/x86/include/asm/paravirt_types.h |    2 -
>  arch/x86/kernel/paravirt.c            |    2 -
>  arch/x86/lib/msr-reg-export.c         |    4 +-
>  arch/x86/lib/msr-reg.S                |   10 ++---
>  arch/x86/xen/enlighten.c              |    2 -
>  7 files changed, 35 insertions(+), 91 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 084ef95274cd..81860cc012d1 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned int msr,
>  
>  extern unsigned long long native_read_tsc(void);
>  
> -extern int native_rdmsr_safe_regs(u32 regs[8]);
> -extern int native_wrmsr_safe_regs(u32 regs[8]);
> +extern int rdmsr_safe_regs(u32 regs[8]);
> +extern int wrmsr_safe_regs(u32 regs[8]);
>  
>  static __always_inline unsigned long long __native_read_tsc(void)
>  {
> @@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  	return err;
>  }
>  
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = native_rdmsr_safe_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return native_wrmsr_safe_regs(gprs);
> -}
> -
> -static inline int rdmsr_safe_regs(u32 regs[8])
> -{
> -	return native_rdmsr_safe_regs(regs);
> -}
> -
> -static inline int wrmsr_safe_regs(u32 regs[8])
> -{
> -	return native_wrmsr_safe_regs(regs);
> -}
> -
>  #define rdtscl(low)						\
>  	((low) = (u32)__native_read_tsc())
>  
> @@ -248,6 +211,32 @@ do {                                                            \
>  
>  #endif	/* !CONFIG_PARAVIRT */
>  
> +static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> +{
> +	u32 gprs[8] = { 0 };
> +	int err;
> +
> +	gprs[1] = msr;
> +	gprs[7] = 0x9c5a203a;
> +
> +	err = rdmsr_safe_regs(gprs);
> +
> +	*p = gprs[0] | ((u64)gprs[2] << 32);
> +
> +	return err;
> +}
> +
> +static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> +{
> +	u32 gprs[8] = { 0 };
> +
> +	gprs[0] = (u32)val;
> +	gprs[1] = msr;
> +	gprs[2] = val >> 32;
> +	gprs[7] = 0x9c5a203a;
> +
> +	return wrmsr_safe_regs(gprs);
> +}
>  
>  #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
>  					     (u32)((val) >> 32))
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 6cbbabf52707..ebb0cdb60a89 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int *err)
>  	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
>  }
>  
> -static inline int paravirt_rdmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
> -}
> -
>  static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
>  {
>  	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
>  }
>  
> -static inline int paravirt_wrmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
> -}
> -
>  /* These should all do BUG_ON(_err), but our headers are too tangled. */
>  #define rdmsr(msr, val1, val2)			\
>  do {						\
> @@ -176,9 +166,6 @@ do {						\
>  	_err;					\
>  })
>  
> -#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
> -#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
> -
>  static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  {
>  	int err;
> @@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  	*p = paravirt_read_msr(msr, &err);
>  	return err;
>  }
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = paravirt_rdmsr_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return paravirt_wrmsr_regs(gprs);
> -}
>  
>  static inline u64 paravirt_read_tsc(void)
>  {
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4987ee..8613cbb7ba41 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -153,9 +153,7 @@ struct pv_cpu_ops {
>  	/* MSR, PMC and TSR operations.
>  	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
>  	u64 (*read_msr)(unsigned int msr, int *err);
> -	int (*rdmsr_regs)(u32 *regs);
>  	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
> -	int (*wrmsr_regs)(u32 *regs);
>  
>  	u64 (*read_tsc)(void);
>  	u64 (*read_pmc)(int counter);
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index 9ce885996fd7..17fff18a1031 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
>  #endif
>  	.wbinvd = native_wbinvd,
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = native_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
>  	.read_tscp = native_read_tscp,
> diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
> index a311cc59b65d..8d6ef78b5d01 100644
> --- a/arch/x86/lib/msr-reg-export.c
> +++ b/arch/x86/lib/msr-reg-export.c
> @@ -1,5 +1,5 @@
>  #include <linux/module.h>
>  #include <asm/msr.h>
>  
> -EXPORT_SYMBOL(native_rdmsr_safe_regs);
> -EXPORT_SYMBOL(native_wrmsr_safe_regs);
> +EXPORT_SYMBOL(rdmsr_safe_regs);
> +EXPORT_SYMBOL(wrmsr_safe_regs);
> diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
> index 69fa10623f21..f6d13eefad10 100644
> --- a/arch/x86/lib/msr-reg.S
> +++ b/arch/x86/lib/msr-reg.S
> @@ -6,13 +6,13 @@
>  
>  #ifdef CONFIG_X86_64
>  /*
> - * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
> + * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
>   *
>   * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
>   *
>   */
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushq_cfi %rbx
>  	pushq_cfi %rbp
> @@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #else /* X86_32 */
>  
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushl_cfi %ebx
>  	pushl_cfi %ebp
> @@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #endif
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e74df9548a02..60f1131eb94f 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
>  	.wbinvd = native_wbinvd,
>  
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = xen_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20: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 1ScMce-0005e6-SG; Wed, 06 Jun 2012 20:14:28 +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 1ScMcd-0005e1-3M
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:27 +0000
Received: from [193.109.254.147:54818] by server-11.bemta-14.messagelabs.com
	id 22/57-02727-22ABFCF4; Wed, 06 Jun 2012 20:14:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339013664!7976994!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NTE3MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30587 invoked from network); 6 Jun 2012 20:14:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 20:14:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KDtiM005761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:13:56 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
	q56KDr0S005274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:13:54 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q56KDoYD004354; Wed, 6 Jun 2012 15:13:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:13:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 32AD14030D; Wed,  6 Jun 2012 16:06:51 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:06:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200651.GA9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-2-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-2-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/4] x86, pvops: Remove hooks for {rd,
	wr}msr_safe_regs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:52:35PM +0200, Borislav Petkov wrote:
> From: Andre Przywara <andre.przywara@amd.com>
> 
> There were paravirt_ops hooks for the full register set variant of
> {rd,wr}msr_safe which are actually not used by anyone anymore. Remove
> them to make the code cleaner and avoid silent breakages when the pvops
> members were uninitialized. This has been boot-tested natively and under
> Xen with PVOPS enabled and disabled on one machine.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/msr.h            |   67 ++++++++++++++-------------------
>  arch/x86/include/asm/paravirt.h       |   39 -------------------
>  arch/x86/include/asm/paravirt_types.h |    2 -
>  arch/x86/kernel/paravirt.c            |    2 -
>  arch/x86/lib/msr-reg-export.c         |    4 +-
>  arch/x86/lib/msr-reg.S                |   10 ++---
>  arch/x86/xen/enlighten.c              |    2 -
>  7 files changed, 35 insertions(+), 91 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 084ef95274cd..81860cc012d1 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -115,8 +115,8 @@ notrace static inline int native_write_msr_safe(unsigned int msr,
>  
>  extern unsigned long long native_read_tsc(void);
>  
> -extern int native_rdmsr_safe_regs(u32 regs[8]);
> -extern int native_wrmsr_safe_regs(u32 regs[8]);
> +extern int rdmsr_safe_regs(u32 regs[8]);
> +extern int wrmsr_safe_regs(u32 regs[8]);
>  
>  static __always_inline unsigned long long __native_read_tsc(void)
>  {
> @@ -187,43 +187,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  	return err;
>  }
>  
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = native_rdmsr_safe_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return native_wrmsr_safe_regs(gprs);
> -}
> -
> -static inline int rdmsr_safe_regs(u32 regs[8])
> -{
> -	return native_rdmsr_safe_regs(regs);
> -}
> -
> -static inline int wrmsr_safe_regs(u32 regs[8])
> -{
> -	return native_wrmsr_safe_regs(regs);
> -}
> -
>  #define rdtscl(low)						\
>  	((low) = (u32)__native_read_tsc())
>  
> @@ -248,6 +211,32 @@ do {                                                            \
>  
>  #endif	/* !CONFIG_PARAVIRT */
>  
> +static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> +{
> +	u32 gprs[8] = { 0 };
> +	int err;
> +
> +	gprs[1] = msr;
> +	gprs[7] = 0x9c5a203a;
> +
> +	err = rdmsr_safe_regs(gprs);
> +
> +	*p = gprs[0] | ((u64)gprs[2] << 32);
> +
> +	return err;
> +}
> +
> +static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> +{
> +	u32 gprs[8] = { 0 };
> +
> +	gprs[0] = (u32)val;
> +	gprs[1] = msr;
> +	gprs[2] = val >> 32;
> +	gprs[7] = 0x9c5a203a;
> +
> +	return wrmsr_safe_regs(gprs);
> +}
>  
>  #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
>  					     (u32)((val) >> 32))
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 6cbbabf52707..ebb0cdb60a89 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -128,21 +128,11 @@ static inline u64 paravirt_read_msr(unsigned msr, int *err)
>  	return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
>  }
>  
> -static inline int paravirt_rdmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.rdmsr_regs, regs);
> -}
> -
>  static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
>  {
>  	return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
>  }
>  
> -static inline int paravirt_wrmsr_regs(u32 *regs)
> -{
> -	return PVOP_CALL1(int, pv_cpu_ops.wrmsr_regs, regs);
> -}
> -
>  /* These should all do BUG_ON(_err), but our headers are too tangled. */
>  #define rdmsr(msr, val1, val2)			\
>  do {						\
> @@ -176,9 +166,6 @@ do {						\
>  	_err;					\
>  })
>  
> -#define rdmsr_safe_regs(regs)	paravirt_rdmsr_regs(regs)
> -#define wrmsr_safe_regs(regs)	paravirt_wrmsr_regs(regs)
> -
>  static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  {
>  	int err;
> @@ -186,32 +173,6 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>  	*p = paravirt_read_msr(msr, &err);
>  	return err;
>  }
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = paravirt_rdmsr_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return paravirt_wrmsr_regs(gprs);
> -}
>  
>  static inline u64 paravirt_read_tsc(void)
>  {
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4987ee..8613cbb7ba41 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -153,9 +153,7 @@ struct pv_cpu_ops {
>  	/* MSR, PMC and TSR operations.
>  	   err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
>  	u64 (*read_msr)(unsigned int msr, int *err);
> -	int (*rdmsr_regs)(u32 *regs);
>  	int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
> -	int (*wrmsr_regs)(u32 *regs);
>  
>  	u64 (*read_tsc)(void);
>  	u64 (*read_pmc)(int counter);
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index 9ce885996fd7..17fff18a1031 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -352,9 +352,7 @@ struct pv_cpu_ops pv_cpu_ops = {
>  #endif
>  	.wbinvd = native_wbinvd,
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = native_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
>  	.read_tscp = native_read_tscp,
> diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
> index a311cc59b65d..8d6ef78b5d01 100644
> --- a/arch/x86/lib/msr-reg-export.c
> +++ b/arch/x86/lib/msr-reg-export.c
> @@ -1,5 +1,5 @@
>  #include <linux/module.h>
>  #include <asm/msr.h>
>  
> -EXPORT_SYMBOL(native_rdmsr_safe_regs);
> -EXPORT_SYMBOL(native_wrmsr_safe_regs);
> +EXPORT_SYMBOL(rdmsr_safe_regs);
> +EXPORT_SYMBOL(wrmsr_safe_regs);
> diff --git a/arch/x86/lib/msr-reg.S b/arch/x86/lib/msr-reg.S
> index 69fa10623f21..f6d13eefad10 100644
> --- a/arch/x86/lib/msr-reg.S
> +++ b/arch/x86/lib/msr-reg.S
> @@ -6,13 +6,13 @@
>  
>  #ifdef CONFIG_X86_64
>  /*
> - * int native_{rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
> + * int {rdmsr,wrmsr}_safe_regs(u32 gprs[8]);
>   *
>   * reg layout: u32 gprs[eax, ecx, edx, ebx, esp, ebp, esi, edi]
>   *
>   */
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushq_cfi %rbx
>  	pushq_cfi %rbp
> @@ -45,13 +45,13 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #else /* X86_32 */
>  
>  .macro op_safe_regs op
> -ENTRY(native_\op\()_safe_regs)
> +ENTRY(\op\()_safe_regs)
>  	CFI_STARTPROC
>  	pushl_cfi %ebx
>  	pushl_cfi %ebp
> @@ -92,7 +92,7 @@ ENTRY(native_\op\()_safe_regs)
>  
>  	_ASM_EXTABLE(1b, 3b)
>  	CFI_ENDPROC
> -ENDPROC(native_\op\()_safe_regs)
> +ENDPROC(\op\()_safe_regs)
>  .endm
>  
>  #endif
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e74df9548a02..60f1131eb94f 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1116,9 +1116,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
>  	.wbinvd = native_wbinvd,
>  
>  	.read_msr = native_read_msr_safe,
> -	.rdmsr_regs = native_rdmsr_safe_regs,
>  	.write_msr = xen_write_msr_safe,
> -	.wrmsr_regs = native_wrmsr_safe_regs,
>  
>  	.read_tsc = native_read_tsc,
>  	.read_pmc = native_read_pmc,
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20:15: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 1ScMcv-0005ee-8w; Wed, 06 Jun 2012 20:14:45 +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 1ScMct-0005eZ-SQ
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:44 +0000
Received: from [85.158.143.35:53774] by server-2.bemta-4.messagelabs.com id
	90/F5-17938-33ABFCF4; Wed, 06 Jun 2012 20:14:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1339013681!19170913!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31721 invoked from network); 6 Jun 2012 20:14:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 20:14:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KEFj7018774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:14:16 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
	q56KEFS1009934
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:14:15 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
	q56KEFXD004610; Wed, 6 Jun 2012 15:14:15 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:14:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9A5614030D; Wed,  6 Jun 2012 16:07:15 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:07:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200715.GC9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-3-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-3-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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 Fri, Jun 01, 2012 at 04:52:36PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
> 
> There's no real reason why, when showing the MSRs on a CPU at boottime,
> we should be using the AMD-specific variant. Simply use the generic safe
> one which handles #GPs just fine.

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Cc: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
>  arch/x86/kernel/cpu/common.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 82f29e70d058..232fba2d54c9 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -947,7 +947,7 @@ static void __cpuinit __print_cpu_msr(void)
>  		index_max = msr_range_array[i].max;
>  
>  		for (index = index_min; index < index_max; index++) {
> -			if (rdmsrl_amd_safe(index, &val))
> +			if (rdmsrl_safe(index, &val))
>  				continue;
>  			printk(KERN_INFO " MSR%08x: %016llx\n", index, val);
>  		}
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20:15: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 1ScMcv-0005ee-8w; Wed, 06 Jun 2012 20:14:45 +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 1ScMct-0005eZ-SQ
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:44 +0000
Received: from [85.158.143.35:53774] by server-2.bemta-4.messagelabs.com id
	90/F5-17938-33ABFCF4; Wed, 06 Jun 2012 20:14:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1339013681!19170913!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31721 invoked from network); 6 Jun 2012 20:14:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 20:14:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KEFj7018774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:14:16 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
	q56KEFS1009934
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:14:15 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
	q56KEFXD004610; Wed, 6 Jun 2012 15:14:15 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:14:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9A5614030D; Wed,  6 Jun 2012 16:07:15 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:07:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200715.GC9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-3-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-3-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] x86,
	CPU: Fix show_msr MSR accessing 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 Fri, Jun 01, 2012 at 04:52:36PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
> 
> There's no real reason why, when showing the MSRs on a CPU at boottime,
> we should be using the AMD-specific variant. Simply use the generic safe
> one which handles #GPs just fine.

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Cc: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
>  arch/x86/kernel/cpu/common.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 82f29e70d058..232fba2d54c9 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -947,7 +947,7 @@ static void __cpuinit __print_cpu_msr(void)
>  		index_max = msr_range_array[i].max;
>  
>  		for (index = index_min; index < index_max; index++) {
> -			if (rdmsrl_amd_safe(index, &val))
> +			if (rdmsrl_safe(index, &val))
>  				continue;
>  			printk(KERN_INFO " MSR%08x: %016llx\n", index, val);
>  		}
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20: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 1ScMd5-0005fX-LP; Wed, 06 Jun 2012 20:14:55 +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 1ScMd4-0005fQ-LU
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:54 +0000
Received: from [85.158.143.99:51568] by server-1.bemta-4.messagelabs.com id
	3C/E5-10042-D3ABFCF4; Wed, 06 Jun 2012 20:14:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339013680!31613405!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 6 Jun 2012 20:14:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jun 2012 20:14:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KE769018641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:14:08 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
	q56KE316015008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:14:05 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
	q56KE3fY026758; Wed, 6 Jun 2012 15:14:03 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:14:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 678FA4030D; Wed,  6 Jun 2012 16:07:04 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:07:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200704.GB9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-5-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-5-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 4/4] x86, CPU,
	AMD: Deprecate AMD-specific MSR variants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:52:38PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
> 
> Now that all users of {rd,wr}msr_amd_safe have been fixed, deprecate its
> use by making them private to amd.c and adding warnings when used on
> anything else beside K8.
> 

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
>  arch/x86/include/asm/msr.h |   27 ---------------------------
>  arch/x86/kernel/cpu/amd.c  |   33 +++++++++++++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 81860cc012d1..cb33b5f00267 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -211,33 +211,6 @@ do {                                                            \
>  
>  #endif	/* !CONFIG_PARAVIRT */
>  
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = rdmsr_safe_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return wrmsr_safe_regs(gprs);
> -}
> -
>  #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
>  					     (u32)((val) >> 32))
>  
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 80ccd99542e6..c928eb26ada6 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -19,6 +19,39 @@
>  
>  #include "cpu.h"
>  
> +static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> +{
> +	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
> +	u32 gprs[8] = { 0 };
> +	int err;
> +
> +	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
> +
> +	gprs[1] = msr;
> +	gprs[7] = 0x9c5a203a;
> +
> +	err = rdmsr_safe_regs(gprs);
> +
> +	*p = gprs[0] | ((u64)gprs[2] << 32);
> +
> +	return err;
> +}
> +
> +static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> +{
> +	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
> +	u32 gprs[8] = { 0 };
> +
> +	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
> +
> +	gprs[0] = (u32)val;
> +	gprs[1] = msr;
> +	gprs[2] = val >> 32;
> +	gprs[7] = 0x9c5a203a;
> +
> +	return wrmsr_safe_regs(gprs);
> +}
> +
>  #ifdef CONFIG_X86_32
>  /*
>   *	B step AMD K6 before B 9730xxxx have hardware bugs that can cause
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20: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 1ScMd5-0005fX-LP; Wed, 06 Jun 2012 20:14:55 +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 1ScMd4-0005fQ-LU
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:54 +0000
Received: from [85.158.143.99:51568] by server-1.bemta-4.messagelabs.com id
	3C/E5-10042-D3ABFCF4; Wed, 06 Jun 2012 20:14:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339013680!31613405!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 6 Jun 2012 20:14:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jun 2012 20:14:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KE769018641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:14:08 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
	q56KE316015008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:14:05 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
	q56KE3fY026758; Wed, 6 Jun 2012 15:14:03 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:14:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 678FA4030D; Wed,  6 Jun 2012 16:07:04 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:07:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200704.GB9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-5-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-5-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com, Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 4/4] x86, CPU,
	AMD: Deprecate AMD-specific MSR variants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:52:38PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@amd.com>
> 
> Now that all users of {rd,wr}msr_amd_safe have been fixed, deprecate its
> use by making them private to amd.c and adding warnings when used on
> anything else beside K8.
> 

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
>  arch/x86/include/asm/msr.h |   27 ---------------------------
>  arch/x86/kernel/cpu/amd.c  |   33 +++++++++++++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 81860cc012d1..cb33b5f00267 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -211,33 +211,6 @@ do {                                                            \
>  
>  #endif	/* !CONFIG_PARAVIRT */
>  
> -static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> -{
> -	u32 gprs[8] = { 0 };
> -	int err;
> -
> -	gprs[1] = msr;
> -	gprs[7] = 0x9c5a203a;
> -
> -	err = rdmsr_safe_regs(gprs);
> -
> -	*p = gprs[0] | ((u64)gprs[2] << 32);
> -
> -	return err;
> -}
> -
> -static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> -{
> -	u32 gprs[8] = { 0 };
> -
> -	gprs[0] = (u32)val;
> -	gprs[1] = msr;
> -	gprs[2] = val >> 32;
> -	gprs[7] = 0x9c5a203a;
> -
> -	return wrmsr_safe_regs(gprs);
> -}
> -
>  #define checking_wrmsrl(msr, val) wrmsr_safe((msr), (u32)(val),		\
>  					     (u32)((val) >> 32))
>  
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 80ccd99542e6..c928eb26ada6 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -19,6 +19,39 @@
>  
>  #include "cpu.h"
>  
> +static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
> +{
> +	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
> +	u32 gprs[8] = { 0 };
> +	int err;
> +
> +	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
> +
> +	gprs[1] = msr;
> +	gprs[7] = 0x9c5a203a;
> +
> +	err = rdmsr_safe_regs(gprs);
> +
> +	*p = gprs[0] | ((u64)gprs[2] << 32);
> +
> +	return err;
> +}
> +
> +static inline int wrmsrl_amd_safe(unsigned msr, unsigned long long val)
> +{
> +	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
> +	u32 gprs[8] = { 0 };
> +
> +	WARN_ONCE((c->x86 != 0xf), "%s should only be used on K8!\n", __func__);
> +
> +	gprs[0] = (u32)val;
> +	gprs[1] = msr;
> +	gprs[2] = val >> 32;
> +	gprs[7] = 0x9c5a203a;
> +
> +	return wrmsr_safe_regs(gprs);
> +}
> +
>  #ifdef CONFIG_X86_32
>  /*
>   *	B step AMD K6 before B 9730xxxx have hardware bugs that can cause
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20:15: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 1ScMdB-0005gj-6t; Wed, 06 Jun 2012 20:15:01 +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 1ScMd9-0005gC-Di
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:59 +0000
Received: from [85.158.138.51:51265] by server-3.bemta-3.messagelabs.com id
	28/C6-25608-24ABFCF4; Wed, 06 Jun 2012 20:14:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339013696!31157969!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5492 invoked from network); 6 Jun 2012 20:14:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 20:14:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KEZVp018978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:14: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
	q56KEYDx015663
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:14:34 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
	q56KEXtQ027052; Wed, 6 Jun 2012 15:14:33 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:14:33 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 788D24030D; Wed,  6 Jun 2012 16:07:34 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:07:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200734.GD9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-4-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: stable@vger.kernel.org.#.3.4+, Andre Przywara <andre.przywara@amd.com>,
	jeremy@goop.org, xen-devel@lists.xensource.com,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
 AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:52:37PM +0200, Borislav Petkov wrote:
> From: Andre Przywara <andre.przywara@amd.com>
> 
> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> has disabled it") wrongfully added code which used the AMD-specific
> {rd,wr}msr variants for no real reason.
> 
> This caused boot panics on xen which wasn't initializing the
> {rd,wr}msr_safe_regs pv_ops members properly.
> 
> This, in turn, caused a heated discussion leading to us reviewing all
> uses of the AMD-specific variants and removing them where unneeded
> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> 
> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> which should've been used in the first place anyway and avoided unneeded
> excitation with xen.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>
> Cc: Andreas Herrmann <andreas.herrmann3@amd.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> Cc: stable@vger.kernel.org # 3.4+
> Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> [Boris: correct and expand commit message]
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
>  arch/x86/kernel/cpu/amd.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 146bb6218eec..80ccd99542e6 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -586,9 +586,9 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>  	    !cpu_has(c, X86_FEATURE_TOPOEXT)) {
>  		u64 val;
>  
> -		if (!rdmsrl_amd_safe(0xc0011005, &val)) {
> +		if (!rdmsrl_safe(0xc0011005, &val)) {
>  			val |= 1ULL << 54;
> -			wrmsrl_amd_safe(0xc0011005, val);
> +			checking_wrmsrl(0xc0011005, val);
>  			rdmsrl(0xc0011005, val);
>  			if (val & (1ULL << 54)) {
>  				set_cpu_cap(c, X86_FEATURE_TOPOEXT);
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20:15: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 1ScMdB-0005gj-6t; Wed, 06 Jun 2012 20:15:01 +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 1ScMd9-0005gC-Di
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:14:59 +0000
Received: from [85.158.138.51:51265] by server-3.bemta-3.messagelabs.com id
	28/C6-25608-24ABFCF4; Wed, 06 Jun 2012 20:14:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339013696!31157969!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5492 invoked from network); 6 Jun 2012 20:14:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 20:14:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56KEZVp018978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 20:14: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
	q56KEYDx015663
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 20:14:34 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
	q56KEXtQ027052; Wed, 6 Jun 2012 15:14:33 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 13:14:33 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 788D24030D; Wed,  6 Jun 2012 16:07:34 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:07:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@amd64.org>
Message-ID: <20120606200734.GD9602@phenom.dumpdata.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338562358-28182-4-git-send-email-bp@amd64.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: stable@vger.kernel.org.#.3.4+, Andre Przywara <andre.przywara@amd.com>,
	jeremy@goop.org, xen-devel@lists.xensource.com,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
 AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 04:52:37PM +0200, Borislav Petkov wrote:
> From: Andre Przywara <andre.przywara@amd.com>
> 
> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> has disabled it") wrongfully added code which used the AMD-specific
> {rd,wr}msr variants for no real reason.
> 
> This caused boot panics on xen which wasn't initializing the
> {rd,wr}msr_safe_regs pv_ops members properly.
> 
> This, in turn, caused a heated discussion leading to us reviewing all
> uses of the AMD-specific variants and removing them where unneeded
> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> 
> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> which should've been used in the first place anyway and avoided unneeded
> excitation with xen.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>
> Cc: Andreas Herrmann <andreas.herrmann3@amd.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> Cc: stable@vger.kernel.org # 3.4+
> Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> [Boris: correct and expand commit message]
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> ---
>  arch/x86/kernel/cpu/amd.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 146bb6218eec..80ccd99542e6 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -586,9 +586,9 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>  	    !cpu_has(c, X86_FEATURE_TOPOEXT)) {
>  		u64 val;
>  
> -		if (!rdmsrl_amd_safe(0xc0011005, &val)) {
> +		if (!rdmsrl_safe(0xc0011005, &val)) {
>  			val |= 1ULL << 54;
> -			wrmsrl_amd_safe(0xc0011005, val);
> +			checking_wrmsrl(0xc0011005, val);
>  			rdmsrl(0xc0011005, val);
>  			if (val & (1ULL << 54)) {
>  				set_cpu_cap(c, X86_FEATURE_TOPOEXT);
> -- 
> 1.7.9.3.362.g71319

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20: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 1ScMhJ-00068h-SD; Wed, 06 Jun 2012 20:19: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 1ScMhH-00068W-Fx
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:19:15 +0000
Received: from [85.158.143.35:39606] by server-3.bemta-4.messagelabs.com id
	A7/61-29237-24BBFCF4; Wed, 06 Jun 2012 20:19:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339013953!13852101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11597 invoked from network); 6 Jun 2012 20:19:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 20:19:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12867360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 20:19:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 21:19:13 +0100
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 1ScMhF-0002vH-33;
	Wed, 06 Jun 2012 20:19:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScMhE-0003sl-Nk;
	Wed, 06 Jun 2012 21:19:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13019-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 21:19:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13019: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13018

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a24ffff4e18d
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Not pushing.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20: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 1ScMhJ-00068h-SD; Wed, 06 Jun 2012 20:19: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 1ScMhH-00068W-Fx
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 20:19:15 +0000
Received: from [85.158.143.35:39606] by server-3.bemta-4.messagelabs.com id
	A7/61-29237-24BBFCF4; Wed, 06 Jun 2012 20:19:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339013953!13852101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11597 invoked from network); 6 Jun 2012 20:19:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 20:19:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="12867360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jun 2012 20:19:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 6 Jun 2012 21:19:13 +0100
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 1ScMhF-0002vH-33;
	Wed, 06 Jun 2012 20:19:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScMhE-0003sl-Nk;
	Wed, 06 Jun 2012 21:19:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13019-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Jun 2012 21:19:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13019: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13018

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a24ffff4e18d
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Not pushing.


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

From xen-devel-bounces@lists.xen.org Wed Jun 06 20:55:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScNFr-0006b2-Sv; Wed, 06 Jun 2012 20:54:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1ScNFq-0006ax-Fk
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 20:54:58 +0000
Received: from [85.158.139.83:24421] by server-11.bemta-5.messagelabs.com id
	FC/D1-25194-1A3CFCF4; Wed, 06 Jun 2012 20:54:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339016096!28452878!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24334 invoked from network); 6 Jun 2012 20:54:56 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 20:54:56 -0000
Received: by lahc1 with SMTP id c1so6138965lah.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 13:54:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Nit+DKcPIdI+d9AePLk69+NxoB+Jc4z8KnSSjiahyjY=;
	b=aSOPja28qPACVjXbsbtxpAvRQ/2NaYHvI93NAhSRoy6lu8H5/8qv1Q74KNkYQeDgLm
	OQs7PUDL3jVVCnNpHYnYSIsdf9YY73PbC8KqYSb8lxZnsDq4z4/K0ETbtlscWqFV6Por
	fOmZ4pKy+se0CRChQg73csIa8GSuvXqlgofTlmaB+tQ/2xNTzjU+rpfzN1nhuRz0C3oq
	ifNBEjw2fxnHyW3PsnPJ5WO07Jn9udPnBLD1hEzwFZBOd+rqmb7oqPbzGSNOFLrGvpHP
	I1WCwyCqFEtdIQvF0QApLlm3LRwdjoNis0smsvTXlqIumnhXlj9JD1nkfbZtcTaLODSh
	n7vg==
MIME-Version: 1.0
Received: by 10.112.86.105 with SMTP id o9mr115326lbz.32.1339016096112; Wed,
	06 Jun 2012 13:54:56 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Wed, 6 Jun 2012 13:54:56 -0700 (PDT)
In-Reply-To: <BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
Date: Wed, 6 Jun 2012 16:54:56 -0400
X-Google-Sender-Auth: o6aUdJ4T71lqkuNy10Pl8hmf7-Y
Message-ID: <CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: James Paton <paton@cs.wisc.edu>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

What kernel version?

Below is a patch against 3.2.y that allows for debug using kdb over hvc

Some bits of this were recently upstreamed as part of some perf-tools
work in pvops...but the debug_core.c, and=A0hvc_console.c didn't make
it.

With this patch, you can add the kernel parameter
kgdboc=3Dhvc0

Alternately, at runtime by doing the following:
echo hvc0 > /sys/module/kgdboc/parameters/kgdboc

To break into the debugger, you need to press the magic SysRq key
sequence "Alt+SysRq+g"

While you are in the debugger, you are in "polling" console mode. As
such, there seems to be a limitation on how fast you can type
commands. I found that when I typed two letters too fast, it just
printed the help text again.



diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d5e0e0a..88815a1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -65,6 +65,7 @@

=A0#include "xen-ops.h"
=A0#include "mmu.h"
+#include "smp.h"
=A0#include "multicalls.h"

=A0EXPORT_SYMBOL_GPL(hypercall_page);
@@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void)
=A0 apic->icr_write =3D xen_apic_icr_write;
=A0 apic->wait_icr_idle =3D xen_apic_wait_icr_idle;
=A0 apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle;
+
+ apic->send_IPI_allbutself =3D xen_send_IPI_allbutself;
+ apic->send_IPI_mask_allbutself =3D xen_send_IPI_mask_allbutself;
+ apic->send_IPI_mask =3D xen_send_IPI_mask;
+ apic->send_IPI_all =3D xen_send_IPI_all;
+ apic->send_IPI_self =3D xen_send_IPI_self;
=A0}

=A0#endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3061244..d8928a1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
=A0 xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
=A0}

-static void xen_send_IPI_mask(const struct cpumask *mask,
- =A0 =A0 =A0enum ipi_vector vector)
+void xen_send_IPI_mask(const struct cpumask *mask,
+ =A0 =A0 =A0int vector)
=A0{
=A0 unsigned cpu;

@@ -466,6 +466,39 @@ static void xen_smp_send_call_function_single_ipi(int =
cpu)
=A0 =A0XEN_CALL_FUNCTION_SINGLE_VECTOR);
=A0}

+void xen_send_IPI_all(int vector)
+{
+ xen_send_IPI_mask(cpu_online_mask, vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+ xen_send_IPI_one(smp_processor_id(), vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+ int vector)
+{
+ unsigned cpu;
+ unsigned int this_cpu =3D smp_processor_id();
+
+ if (!(num_online_cpus() > 1))
+ return;
+
+ for_each_cpu_and(cpu, mask, cpu_online_mask) {
+ if (this_cpu =3D=3D cpu)
+ continue;
+
+ xen_smp_send_call_function_single_ipi(cpu);
+ }
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+ xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
+}
+
+
=A0static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
=A0{
=A0 irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8981a76
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+ =A0 =A0 =A0int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+ int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 58ca7ce..4addc80 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)

=A0static int hvc_poll_get_char(struct tty_driver *driver, int line)
=A0{
- struct tty_struct *tty =3D driver->ttys[0];
- struct hvc_struct *hp =3D tty->driver_data;
=A0 int n;
=A0 char ch;

- n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
-
+ n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
=A0 if (n =3D=3D 0)
=A0 return NO_POLL_CHAR;

@@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver
*driver, int line)

=A0static void hvc_poll_put_char(struct tty_driver *driver, int line, char =
ch)
=A0{
- struct tty_struct *tty =3D driver->ttys[0];
- struct hvc_struct *hp =3D tty->driver_data;
=A0 int n;

=A0 do {
- n =3D hp->ops->put_chars(hp->vtermno, &ch, 1);
+ n =3D cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
=A0 } while (n <=3D 0);
=A0}
=A0#endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index cefd4a1..df904a5 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -581,12 +581,14 @@ return_normal:
=A0 kgdb_roundup_cpus(flags);
=A0#endif

+#ifndef CONFIG_XEN
=A0 /*
=A0 * Wait for the other CPUs to be notified and be waiting for us:
=A0 */
=A0 while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
=A0 atomic_read(&slaves_in_kgdb)) !=3D online_cpus)
=A0 cpu_relax();
+#endif

=A0 /*
=A0 * At this point the primary processor is completely





On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote:
>
> Thanks everyone for your help.
>
> I tried the suggestion of leaving ttyS1 out of the Xen boot options and u=
sing that. I confirmed that I can echo things back and forth through that c=
onnection from the host OS. I compiled a custom version of gdb to target x8=
6_64-linux-gnu so I could do remote debugging from the host. No luck. I als=
o tried setting console=3DttyS1 for the dom0 kernel -- same outcome.
>
> Next, using exactly the same settings, I booted the dom0 kernel bare (no =
Xen this time) and tried the same thing. This time, it worked. I can connec=
t the debugger and it breaks as expected. So I'm thinking debugging while r=
unning Xen over serial is a dead end, unless I figure out a way to do it ov=
er hvc. I think for now I'll just use printk.
>
> -- Jim
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 20:55:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 20:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScNFr-0006b2-Sv; Wed, 06 Jun 2012 20:54:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1ScNFq-0006ax-Fk
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 20:54:58 +0000
Received: from [85.158.139.83:24421] by server-11.bemta-5.messagelabs.com id
	FC/D1-25194-1A3CFCF4; Wed, 06 Jun 2012 20:54:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339016096!28452878!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24334 invoked from network); 6 Jun 2012 20:54:56 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jun 2012 20:54:56 -0000
Received: by lahc1 with SMTP id c1so6138965lah.32
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 13:54:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Nit+DKcPIdI+d9AePLk69+NxoB+Jc4z8KnSSjiahyjY=;
	b=aSOPja28qPACVjXbsbtxpAvRQ/2NaYHvI93NAhSRoy6lu8H5/8qv1Q74KNkYQeDgLm
	OQs7PUDL3jVVCnNpHYnYSIsdf9YY73PbC8KqYSb8lxZnsDq4z4/K0ETbtlscWqFV6Por
	fOmZ4pKy+se0CRChQg73csIa8GSuvXqlgofTlmaB+tQ/2xNTzjU+rpfzN1nhuRz0C3oq
	ifNBEjw2fxnHyW3PsnPJ5WO07Jn9udPnBLD1hEzwFZBOd+rqmb7oqPbzGSNOFLrGvpHP
	I1WCwyCqFEtdIQvF0QApLlm3LRwdjoNis0smsvTXlqIumnhXlj9JD1nkfbZtcTaLODSh
	n7vg==
MIME-Version: 1.0
Received: by 10.112.86.105 with SMTP id o9mr115326lbz.32.1339016096112; Wed,
	06 Jun 2012 13:54:56 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Wed, 6 Jun 2012 13:54:56 -0700 (PDT)
In-Reply-To: <BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
Date: Wed, 6 Jun 2012 16:54:56 -0400
X-Google-Sender-Auth: o6aUdJ4T71lqkuNy10Pl8hmf7-Y
Message-ID: <CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: James Paton <paton@cs.wisc.edu>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

What kernel version?

Below is a patch against 3.2.y that allows for debug using kdb over hvc

Some bits of this were recently upstreamed as part of some perf-tools
work in pvops...but the debug_core.c, and=A0hvc_console.c didn't make
it.

With this patch, you can add the kernel parameter
kgdboc=3Dhvc0

Alternately, at runtime by doing the following:
echo hvc0 > /sys/module/kgdboc/parameters/kgdboc

To break into the debugger, you need to press the magic SysRq key
sequence "Alt+SysRq+g"

While you are in the debugger, you are in "polling" console mode. As
such, there seems to be a limitation on how fast you can type
commands. I found that when I typed two letters too fast, it just
printed the help text again.



diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d5e0e0a..88815a1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -65,6 +65,7 @@

=A0#include "xen-ops.h"
=A0#include "mmu.h"
+#include "smp.h"
=A0#include "multicalls.h"

=A0EXPORT_SYMBOL_GPL(hypercall_page);
@@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void)
=A0 apic->icr_write =3D xen_apic_icr_write;
=A0 apic->wait_icr_idle =3D xen_apic_wait_icr_idle;
=A0 apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle;
+
+ apic->send_IPI_allbutself =3D xen_send_IPI_allbutself;
+ apic->send_IPI_mask_allbutself =3D xen_send_IPI_mask_allbutself;
+ apic->send_IPI_mask =3D xen_send_IPI_mask;
+ apic->send_IPI_all =3D xen_send_IPI_all;
+ apic->send_IPI_self =3D xen_send_IPI_self;
=A0}

=A0#endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3061244..d8928a1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
=A0 xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
=A0}

-static void xen_send_IPI_mask(const struct cpumask *mask,
- =A0 =A0 =A0enum ipi_vector vector)
+void xen_send_IPI_mask(const struct cpumask *mask,
+ =A0 =A0 =A0int vector)
=A0{
=A0 unsigned cpu;

@@ -466,6 +466,39 @@ static void xen_smp_send_call_function_single_ipi(int =
cpu)
=A0 =A0XEN_CALL_FUNCTION_SINGLE_VECTOR);
=A0}

+void xen_send_IPI_all(int vector)
+{
+ xen_send_IPI_mask(cpu_online_mask, vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+ xen_send_IPI_one(smp_processor_id(), vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+ int vector)
+{
+ unsigned cpu;
+ unsigned int this_cpu =3D smp_processor_id();
+
+ if (!(num_online_cpus() > 1))
+ return;
+
+ for_each_cpu_and(cpu, mask, cpu_online_mask) {
+ if (this_cpu =3D=3D cpu)
+ continue;
+
+ xen_smp_send_call_function_single_ipi(cpu);
+ }
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+ xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
+}
+
+
=A0static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
=A0{
=A0 irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8981a76
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+ =A0 =A0 =A0int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+ int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 58ca7ce..4addc80 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)

=A0static int hvc_poll_get_char(struct tty_driver *driver, int line)
=A0{
- struct tty_struct *tty =3D driver->ttys[0];
- struct hvc_struct *hp =3D tty->driver_data;
=A0 int n;
=A0 char ch;

- n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
-
+ n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
=A0 if (n =3D=3D 0)
=A0 return NO_POLL_CHAR;

@@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver
*driver, int line)

=A0static void hvc_poll_put_char(struct tty_driver *driver, int line, char =
ch)
=A0{
- struct tty_struct *tty =3D driver->ttys[0];
- struct hvc_struct *hp =3D tty->driver_data;
=A0 int n;

=A0 do {
- n =3D hp->ops->put_chars(hp->vtermno, &ch, 1);
+ n =3D cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
=A0 } while (n <=3D 0);
=A0}
=A0#endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index cefd4a1..df904a5 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -581,12 +581,14 @@ return_normal:
=A0 kgdb_roundup_cpus(flags);
=A0#endif

+#ifndef CONFIG_XEN
=A0 /*
=A0 * Wait for the other CPUs to be notified and be waiting for us:
=A0 */
=A0 while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
=A0 atomic_read(&slaves_in_kgdb)) !=3D online_cpus)
=A0 cpu_relax();
+#endif

=A0 /*
=A0 * At this point the primary processor is completely





On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote:
>
> Thanks everyone for your help.
>
> I tried the suggestion of leaving ttyS1 out of the Xen boot options and u=
sing that. I confirmed that I can echo things back and forth through that c=
onnection from the host OS. I compiled a custom version of gdb to target x8=
6_64-linux-gnu so I could do remote debugging from the host. No luck. I als=
o tried setting console=3DttyS1 for the dom0 kernel -- same outcome.
>
> Next, using exactly the same settings, I booted the dom0 kernel bare (no =
Xen this time) and tried the same thing. This time, it worked. I can connec=
t the debugger and it breaks as expected. So I'm thinking debugging while r=
unning Xen over serial is a dead end, unless I figure out a way to do it ov=
er hvc. I think for now I'll just use printk.
>
> -- Jim
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 06 21:02:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 21: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 1ScNNG-0006mO-2S; Wed, 06 Jun 2012 21:02:38 +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 1ScNNE-0006mJ-GQ
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 21:02:36 +0000
Received: from [85.158.143.35:17358] by server-3.bemta-4.messagelabs.com id
	3F/19-29237-B65CFCF4; Wed, 06 Jun 2012 21:02:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339016553!19094487!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5902 invoked from network); 6 Jun 2012 21:02:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 21:02:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56L2Nor009127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 21:02:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q56L2MIl004241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 21:02:23 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
	q56L2MDP025428; Wed, 6 Jun 2012 16:02:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 14:02:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 237324030D; Wed,  6 Jun 2012 16:55:23 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:55:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120606205523.GA10891@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
> >From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00 2001
> From: root <root@ljsromley.bj.intel.com>
> Date: Fri, 1 Jun 2012 03:12:51 +0800
> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
> 
> When MCA error occurs, it would be handled by Xen hypervisor first,
> and then the error information would be sent to initial domain for logging.
> 
> This patch gets error information from Xen hypervisor and convert
> Xen format error into Linux format mcelog. This logic is basically
> self-contained, not touching other kernel components.
> 
> By using tools like mcelog tool users could read specific error information,
> like what they did under native Linux.
> 
> To test follow directions outlined in Documentation/acpi/apei/einj.txt

[   53.264610] switch: port 1(eth0) entered forwarding state
[ 1058.051938] BUG: sleeping function called from invalid context at /home/konrad/linux/include/linux/kernel.h:199
[ 1058.052066] in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog
[ 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O 3.5.0-rc1upstream-00041-ga16e594-dirty #2
[ 1058.052235] Call Trace:
[ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100
[ 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140
[ 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190
[ 1058.052461]  [<ffffffff81148f4c>] sys_read+0x4c/0x90
[ 1058.052515]  [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1

?

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 21:02:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 21: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 1ScNNG-0006mO-2S; Wed, 06 Jun 2012 21:02:38 +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 1ScNNE-0006mJ-GQ
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 21:02:36 +0000
Received: from [85.158.143.35:17358] by server-3.bemta-4.messagelabs.com id
	3F/19-29237-B65CFCF4; Wed, 06 Jun 2012 21:02:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339016553!19094487!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5902 invoked from network); 6 Jun 2012 21:02:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 21:02:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56L2Nor009127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 21:02:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q56L2MIl004241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 21:02:23 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
	q56L2MDP025428; Wed, 6 Jun 2012 16:02:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 14:02:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 237324030D; Wed,  6 Jun 2012 16:55:23 -0400 (EDT)
Date: Wed, 6 Jun 2012 16:55:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120606205523.GA10891@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
> >From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00 2001
> From: root <root@ljsromley.bj.intel.com>
> Date: Fri, 1 Jun 2012 03:12:51 +0800
> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
> 
> When MCA error occurs, it would be handled by Xen hypervisor first,
> and then the error information would be sent to initial domain for logging.
> 
> This patch gets error information from Xen hypervisor and convert
> Xen format error into Linux format mcelog. This logic is basically
> self-contained, not touching other kernel components.
> 
> By using tools like mcelog tool users could read specific error information,
> like what they did under native Linux.
> 
> To test follow directions outlined in Documentation/acpi/apei/einj.txt

[   53.264610] switch: port 1(eth0) entered forwarding state
[ 1058.051938] BUG: sleeping function called from invalid context at /home/konrad/linux/include/linux/kernel.h:199
[ 1058.052066] in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog
[ 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O 3.5.0-rc1upstream-00041-ga16e594-dirty #2
[ 1058.052235] Call Trace:
[ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100
[ 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140
[ 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190
[ 1058.052461]  [<ffffffff81148f4c>] sys_read+0x4c/0x90
[ 1058.052515]  [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1

?

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

From xen-devel-bounces@lists.xen.org Wed Jun 06 21:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 21: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 1ScNqa-00079I-0W; Wed, 06 Jun 2012 21:32:56 +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 1ScNqY-00079D-Rg
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 21:32:55 +0000
Received: from [85.158.143.99:45281] by server-1.bemta-4.messagelabs.com id
	D0/0E-10042-68CCFCF4; Wed, 06 Jun 2012 21:32:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339018371!31308565!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24427 invoked from network); 6 Jun 2012 21:32:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 21:32:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56LWdJi005137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 21:32: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
	q56LWcof013157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 21:32:39 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
	q56LWbq2013817; Wed, 6 Jun 2012 16:32:37 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 14:32:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B594A4030D; Wed,  6 Jun 2012 17:25:38 -0400 (EDT)
Date: Wed, 6 Jun 2012 17:25:38 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120606212538.GG9472@phenom.dumpdata.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: James Paton <paton@cs.wisc.edu>, Ian Campbell <Ian.Campbell@citrix.com>,
	Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 06, 2012 at 04:54:56PM -0400, Ben Guthro wrote:
> What kernel version?
> =

> Below is a patch against 3.2.y that allows for debug using kdb over hvc
> =

> Some bits of this were recently upstreamed as part of some perf-tools
> work in pvops...but the debug_core.c, and=A0hvc_console.c didn't make
> it.

I would be interested in seeing them against v3.5-rc1..

> =

> With this patch, you can add the kernel parameter
> kgdboc=3Dhvc0
> =

> Alternately, at runtime by doing the following:
> echo hvc0 > /sys/module/kgdboc/parameters/kgdboc
> =

> To break into the debugger, you need to press the magic SysRq key
> sequence "Alt+SysRq+g"
> =

> While you are in the debugger, you are in "polling" console mode. As
> such, there seems to be a limitation on how fast you can type
> commands. I found that when I typed two letters too fast, it just
> printed the help text again.
> =

> =

> =

> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index d5e0e0a..88815a1 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -65,6 +65,7 @@
> =

> =A0#include "xen-ops.h"
> =A0#include "mmu.h"
> +#include "smp.h"
> =A0#include "multicalls.h"
> =

> =A0EXPORT_SYMBOL_GPL(hypercall_page);
> @@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void)
> =A0 apic->icr_write =3D xen_apic_icr_write;
> =A0 apic->wait_icr_idle =3D xen_apic_wait_icr_idle;
> =A0 apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle;
> +
> + apic->send_IPI_allbutself =3D xen_send_IPI_allbutself;
> + apic->send_IPI_mask_allbutself =3D xen_send_IPI_mask_allbutself;
> + apic->send_IPI_mask =3D xen_send_IPI_mask;
> + apic->send_IPI_all =3D xen_send_IPI_all;
> + apic->send_IPI_self =3D xen_send_IPI_self;
> =A0}
> =

> =A0#endif
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 3061244..d8928a1 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
> =A0 xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
> =A0}
> =

> -static void xen_send_IPI_mask(const struct cpumask *mask,
> - =A0 =A0 =A0enum ipi_vector vector)
> +void xen_send_IPI_mask(const struct cpumask *mask,
> + =A0 =A0 =A0int vector)
> =A0{
> =A0 unsigned cpu;
> =

> @@ -466,6 +466,39 @@ static void xen_smp_send_call_function_single_ipi(in=
t cpu)
> =A0 =A0XEN_CALL_FUNCTION_SINGLE_VECTOR);
> =A0}
> =

> +void xen_send_IPI_all(int vector)
> +{
> + xen_send_IPI_mask(cpu_online_mask, vector);
> +}
> +
> +void xen_send_IPI_self(int vector)
> +{
> + xen_send_IPI_one(smp_processor_id(), vector);
> +}
> +
> +void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector)
> +{
> + unsigned cpu;
> + unsigned int this_cpu =3D smp_processor_id();
> +
> + if (!(num_online_cpus() > 1))
> + return;
> +
> + for_each_cpu_and(cpu, mask, cpu_online_mask) {
> + if (this_cpu =3D=3D cpu)
> + continue;
> +
> + xen_smp_send_call_function_single_ipi(cpu);
> + }
> +}
> +
> +void xen_send_IPI_allbutself(int vector)
> +{
> + xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
> +}
> +
> +
> =A0static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
> =A0{
> =A0 irq_enter();
> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
> new file mode 100644
> index 0000000..8981a76
> --- /dev/null
> +++ b/arch/x86/xen/smp.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_SMP_H
> +
> +extern void xen_send_IPI_mask(const struct cpumask *mask,
> + =A0 =A0 =A0int vector);
> +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector);
> +extern void xen_send_IPI_allbutself(int vector);
> +extern void physflat_send_IPI_allbutself(int vector);
> +extern void xen_send_IPI_all(int vector);
> +extern void xen_send_IPI_self(int vector);
> +
> +#endif
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 58ca7ce..4addc80 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int
> line, char *options)
> =

> =A0static int hvc_poll_get_char(struct tty_driver *driver, int line)
> =A0{
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
> =A0 int n;
> =A0 char ch;
> =

> - n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
> -
> + n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
> =A0 if (n =3D=3D 0)
> =A0 return NO_POLL_CHAR;
> =

> @@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver
> *driver, int line)
> =

> =A0static void hvc_poll_put_char(struct tty_driver *driver, int line, cha=
r ch)
> =A0{
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
> =A0 int n;
> =

> =A0 do {
> - n =3D hp->ops->put_chars(hp->vtermno, &ch, 1);
> + n =3D cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
> =A0 } while (n <=3D 0);
> =A0}
> =A0#endif
> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> index cefd4a1..df904a5 100644
> --- a/kernel/debug/debug_core.c
> +++ b/kernel/debug/debug_core.c
> @@ -581,12 +581,14 @@ return_normal:
> =A0 kgdb_roundup_cpus(flags);
> =A0#endif
> =

> +#ifndef CONFIG_XEN
> =A0 /*
> =A0 * Wait for the other CPUs to be notified and be waiting for us:
> =A0 */
> =A0 while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
> =A0 atomic_read(&slaves_in_kgdb)) !=3D online_cpus)
> =A0 cpu_relax();
> +#endif
> =

> =A0 /*
> =A0 * At this point the primary processor is completely
> =

> =

> =

> =

> =

> On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote:
> >
> > Thanks everyone for your help.
> >
> > I tried the suggestion of leaving ttyS1 out of the Xen boot options and=
 using that. I confirmed that I can echo things back and forth through that=
 connection from the host OS. I compiled a custom version of gdb to target =
x86_64-linux-gnu so I could do remote debugging from the host. No luck. I a=
lso tried setting console=3DttyS1 for the dom0 kernel -- same outcome.
> >
> > Next, using exactly the same settings, I booted the dom0 kernel bare (n=
o Xen this time) and tried the same thing. This time, it worked. I can conn=
ect the debugger and it breaks as expected. So I'm thinking debugging while=
 running Xen over serial is a dead end, unless I figure out a way to do it =
over hvc. I think for now I'll just use printk.
> >
> > -- Jim
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@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 Wed Jun 06 21:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 21: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 1ScNqa-00079I-0W; Wed, 06 Jun 2012 21:32:56 +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 1ScNqY-00079D-Rg
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 21:32:55 +0000
Received: from [85.158.143.99:45281] by server-1.bemta-4.messagelabs.com id
	D0/0E-10042-68CCFCF4; Wed, 06 Jun 2012 21:32:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339018371!31308565!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTczMDM0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24427 invoked from network); 6 Jun 2012 21:32:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 21:32:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56LWdJi005137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 21:32: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
	q56LWcof013157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 21:32:39 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
	q56LWbq2013817; Wed, 6 Jun 2012 16:32:37 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 14:32:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B594A4030D; Wed,  6 Jun 2012 17:25:38 -0400 (EDT)
Date: Wed, 6 Jun 2012 17:25:38 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120606212538.GG9472@phenom.dumpdata.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: James Paton <paton@cs.wisc.edu>, Ian Campbell <Ian.Campbell@citrix.com>,
	Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 06, 2012 at 04:54:56PM -0400, Ben Guthro wrote:
> What kernel version?
> =

> Below is a patch against 3.2.y that allows for debug using kdb over hvc
> =

> Some bits of this were recently upstreamed as part of some perf-tools
> work in pvops...but the debug_core.c, and=A0hvc_console.c didn't make
> it.

I would be interested in seeing them against v3.5-rc1..

> =

> With this patch, you can add the kernel parameter
> kgdboc=3Dhvc0
> =

> Alternately, at runtime by doing the following:
> echo hvc0 > /sys/module/kgdboc/parameters/kgdboc
> =

> To break into the debugger, you need to press the magic SysRq key
> sequence "Alt+SysRq+g"
> =

> While you are in the debugger, you are in "polling" console mode. As
> such, there seems to be a limitation on how fast you can type
> commands. I found that when I typed two letters too fast, it just
> printed the help text again.
> =

> =

> =

> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index d5e0e0a..88815a1 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -65,6 +65,7 @@
> =

> =A0#include "xen-ops.h"
> =A0#include "mmu.h"
> +#include "smp.h"
> =A0#include "multicalls.h"
> =

> =A0EXPORT_SYMBOL_GPL(hypercall_page);
> @@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void)
> =A0 apic->icr_write =3D xen_apic_icr_write;
> =A0 apic->wait_icr_idle =3D xen_apic_wait_icr_idle;
> =A0 apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle;
> +
> + apic->send_IPI_allbutself =3D xen_send_IPI_allbutself;
> + apic->send_IPI_mask_allbutself =3D xen_send_IPI_mask_allbutself;
> + apic->send_IPI_mask =3D xen_send_IPI_mask;
> + apic->send_IPI_all =3D xen_send_IPI_all;
> + apic->send_IPI_self =3D xen_send_IPI_self;
> =A0}
> =

> =A0#endif
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 3061244..d8928a1 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
> =A0 xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
> =A0}
> =

> -static void xen_send_IPI_mask(const struct cpumask *mask,
> - =A0 =A0 =A0enum ipi_vector vector)
> +void xen_send_IPI_mask(const struct cpumask *mask,
> + =A0 =A0 =A0int vector)
> =A0{
> =A0 unsigned cpu;
> =

> @@ -466,6 +466,39 @@ static void xen_smp_send_call_function_single_ipi(in=
t cpu)
> =A0 =A0XEN_CALL_FUNCTION_SINGLE_VECTOR);
> =A0}
> =

> +void xen_send_IPI_all(int vector)
> +{
> + xen_send_IPI_mask(cpu_online_mask, vector);
> +}
> +
> +void xen_send_IPI_self(int vector)
> +{
> + xen_send_IPI_one(smp_processor_id(), vector);
> +}
> +
> +void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector)
> +{
> + unsigned cpu;
> + unsigned int this_cpu =3D smp_processor_id();
> +
> + if (!(num_online_cpus() > 1))
> + return;
> +
> + for_each_cpu_and(cpu, mask, cpu_online_mask) {
> + if (this_cpu =3D=3D cpu)
> + continue;
> +
> + xen_smp_send_call_function_single_ipi(cpu);
> + }
> +}
> +
> +void xen_send_IPI_allbutself(int vector)
> +{
> + xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
> +}
> +
> +
> =A0static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
> =A0{
> =A0 irq_enter();
> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
> new file mode 100644
> index 0000000..8981a76
> --- /dev/null
> +++ b/arch/x86/xen/smp.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_SMP_H
> +
> +extern void xen_send_IPI_mask(const struct cpumask *mask,
> + =A0 =A0 =A0int vector);
> +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector);
> +extern void xen_send_IPI_allbutself(int vector);
> +extern void physflat_send_IPI_allbutself(int vector);
> +extern void xen_send_IPI_all(int vector);
> +extern void xen_send_IPI_self(int vector);
> +
> +#endif
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 58ca7ce..4addc80 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int
> line, char *options)
> =

> =A0static int hvc_poll_get_char(struct tty_driver *driver, int line)
> =A0{
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
> =A0 int n;
> =A0 char ch;
> =

> - n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
> -
> + n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
> =A0 if (n =3D=3D 0)
> =A0 return NO_POLL_CHAR;
> =

> @@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver
> *driver, int line)
> =

> =A0static void hvc_poll_put_char(struct tty_driver *driver, int line, cha=
r ch)
> =A0{
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
> =A0 int n;
> =

> =A0 do {
> - n =3D hp->ops->put_chars(hp->vtermno, &ch, 1);
> + n =3D cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
> =A0 } while (n <=3D 0);
> =A0}
> =A0#endif
> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> index cefd4a1..df904a5 100644
> --- a/kernel/debug/debug_core.c
> +++ b/kernel/debug/debug_core.c
> @@ -581,12 +581,14 @@ return_normal:
> =A0 kgdb_roundup_cpus(flags);
> =A0#endif
> =

> +#ifndef CONFIG_XEN
> =A0 /*
> =A0 * Wait for the other CPUs to be notified and be waiting for us:
> =A0 */
> =A0 while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
> =A0 atomic_read(&slaves_in_kgdb)) !=3D online_cpus)
> =A0 cpu_relax();
> +#endif
> =

> =A0 /*
> =A0 * At this point the primary processor is completely
> =

> =

> =

> =

> =

> On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote:
> >
> > Thanks everyone for your help.
> >
> > I tried the suggestion of leaving ttyS1 out of the Xen boot options and=
 using that. I confirmed that I can echo things back and forth through that=
 connection from the host OS. I compiled a custom version of gdb to target =
x86_64-linux-gnu so I could do remote debugging from the host. No luck. I a=
lso tried setting console=3DttyS1 for the dom0 kernel -- same outcome.
> >
> > Next, using exactly the same settings, I booted the dom0 kernel bare (n=
o Xen this time) and tried the same thing. This time, it worked. I can conn=
ect the debugger and it breaks as expected. So I'm thinking debugging while=
 running Xen over serial is a dead end, unless I figure out a way to do it =
over hvc. I think for now I'll just use printk.
> >
> > -- Jim
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@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 Wed Jun 06 22:01:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 22:01: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 1ScOHX-0007uO-Fm; Wed, 06 Jun 2012 22:00:47 +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 1ScOHW-0007uF-9n
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 22:00:46 +0000
Received: from [85.158.143.99:54533] by server-2.bemta-4.messagelabs.com id
	09/5E-17938-D03DFCF4; Wed, 06 Jun 2012 22:00:45 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339020041!29310966!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20281 invoked from network); 6 Jun 2012 22:00:42 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 22:00:42 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q56M0Jkl005311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 15:00:20 -0700
Message-ID: <4FCFD2EE.8060508@zytor.com>
Date: Wed, 06 Jun 2012 15:00:14 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
In-Reply-To: <1338562358-28182-4-git-send-email-bp@amd64.org>
X-Enigmail-Version: 1.4.1
Cc: stable@vger.kernel.org.#.3.4+, Andre Przywara <andre.przywara@amd.com>,
	jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/01/2012 07:52 AM, Borislav Petkov wrote:
> From: Andre Przywara <andre.przywara@amd.com>
> 
> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> has disabled it") wrongfully added code which used the AMD-specific
> {rd,wr}msr variants for no real reason.
> 
> This caused boot panics on xen which wasn't initializing the
> {rd,wr}msr_safe_regs pv_ops members properly.
> 
> This, in turn, caused a heated discussion leading to us reviewing all
> uses of the AMD-specific variants and removing them where unneeded
> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> 
> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> which should've been used in the first place anyway and avoided unneeded
> excitation with xen.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>
> Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
> Cc: stable@vger.kernel.org # 3.4+
> Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> [Boris: correct and expand commit message]
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>

Why -stable?  I though we had agreed that we didn't have an active
problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
currently sits?

	-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 Wed Jun 06 22:01:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 22:01: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 1ScOHX-0007uO-Fm; Wed, 06 Jun 2012 22:00:47 +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 1ScOHW-0007uF-9n
	for xen-devel@lists.xensource.com; Wed, 06 Jun 2012 22:00:46 +0000
Received: from [85.158.143.99:54533] by server-2.bemta-4.messagelabs.com id
	09/5E-17938-D03DFCF4; Wed, 06 Jun 2012 22:00:45 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339020041!29310966!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20281 invoked from network); 6 Jun 2012 22:00:42 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 22:00:42 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q56M0Jkl005311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 15:00:20 -0700
Message-ID: <4FCFD2EE.8060508@zytor.com>
Date: Wed, 06 Jun 2012 15:00:14 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
In-Reply-To: <1338562358-28182-4-git-send-email-bp@amd64.org>
X-Enigmail-Version: 1.4.1
Cc: stable@vger.kernel.org.#.3.4+, Andre Przywara <andre.przywara@amd.com>,
	jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>, Jan Beulich <JBeulich@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/01/2012 07:52 AM, Borislav Petkov wrote:
> From: Andre Przywara <andre.przywara@amd.com>
> 
> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> has disabled it") wrongfully added code which used the AMD-specific
> {rd,wr}msr variants for no real reason.
> 
> This caused boot panics on xen which wasn't initializing the
> {rd,wr}msr_safe_regs pv_ops members properly.
> 
> This, in turn, caused a heated discussion leading to us reviewing all
> uses of the AMD-specific variants and removing them where unneeded
> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> 
> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> which should've been used in the first place anyway and avoided unneeded
> excitation with xen.
> 
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>
> Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
> Cc: stable@vger.kernel.org # 3.4+
> Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> [Boris: correct and expand commit message]
> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>

Why -stable?  I though we had agreed that we didn't have an active
problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
currently sits?

	-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 Wed Jun 06 22:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 22: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 1ScOOd-0008Lk-14; Wed, 06 Jun 2012 22:08:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paton@cs.wisc.edu>) id 1ScOOb-0008Lf-A3
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 22:08:05 +0000
Received: from [85.158.143.35:22363] by server-3.bemta-4.messagelabs.com id
	B3/06-29237-4C4DFCF4; Wed, 06 Jun 2012 22:08:04 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339020481!15949711!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20622 invoked from network); 6 Jun 2012 22:08:02 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 22:08:02 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q56M7vgg029973
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 6 Jun 2012 17:07:57 -0500
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C"
From: James Paton <paton@cs.wisc.edu>
In-Reply-To: <CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
Date: Wed, 6 Jun 2012 17:07:52 -0500
Message-Id: <8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
X-Mailer: Apple Mail (2.1278)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Thank you! I am using 3.3.6, but by manually applying your patch, I got =
it to work. I've attached a patch for 3.3.6 in case anyone would find it =
useful.

-- Jim


--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Disposition: attachment;
	filename=hvc.patch
Content-Type: application/octet-stream;
	name="hvc.patch"
Content-Transfer-Encoding: 7bit

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c4c38a5..4e517d4 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -66,7 +66,6 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
-#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -760,12 +759,6 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
-	
-	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
-	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
-	apic->send_IPI_mask = xen_send_IPI_mask;
-	apic->send_IPI_all = xen_send_IPI_all;
-	apic->send_IPI_self = xen_send_IPI_self;
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 64b78f7..f2ce60a 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -474,8 +474,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-void xen_send_IPI_mask(const struct cpumask *mask, 
-		int vector)
+static void xen_send_IPI_mask(const struct cpumask *mask,
+			      enum ipi_vector vector)
 {
 	unsigned cpu;
 
@@ -504,38 +504,6 @@ static void xen_smp_send_call_function_single_ipi(int cpu)
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
-void xen_send_IPI_all(int vector)
-{
-	xen_send_IPI_mask(cpu_online_mask, vector);
-}
-
-void xen_send_IPI_self(int vector)
-{
-	xen_send_IPI_one(smp_processor_id(), vector);
-}
-
-void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
-	       int vector)
-{
-	unsigned cpu;
-	unsigned int this_cpu = smp_processor_id();
-	
-	if (!(num_online_cpus() > 1))
-		return;
-	
-	for_each_cpu_and(cpu, mask, cpu_online_mask) {
-		if (this_cpu == cpu)
-			continue;
-	
-		xen_smp_send_call_function_single_ipi(cpu);
-	}
-}
-
-void xen_send_IPI_allbutself(int vector)
-{
-	xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
-}
-
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
deleted file mode 100644
index 8e684e4..0000000
--- a/arch/x86/xen/smp.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef _XEN_SMP_H
-#define _XEN_SMP_H
-
-extern void xen_send_IPI_mask(const struct cpumask *mask,
-      int vector);
-extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
-	int vector);
-extern void xen_send_IPI_allbutself(int vector);
-extern void physflat_send_IPI_allbutself(int vector);
-extern void xen_send_IPI_all(int vector);
-extern void xen_send_IPI_self(int vector);
-
-#endif
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 401e9e3..b6b2d18 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -775,10 +775,13 @@ int hvc_poll_init(struct tty_driver *driver, int line, char *options)
 
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
+	struct tty_struct *tty = driver->ttys[0];
+	struct hvc_struct *hp = tty->driver_data;
 	int n;
 	char ch;
 
-	n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
+	n = hp->ops->get_chars(hp->vtermno, &ch, 1);
+
 	if (n == 0)
 		return NO_POLL_CHAR;
 
@@ -787,10 +790,12 @@ static int hvc_poll_get_char(struct tty_driver *driver, int line)
 
 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
+	struct tty_struct *tty = driver->ttys[0];
+	struct hvc_struct *hp = tty->driver_data;
 	int n;
 
 	do {
-		n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
+		n = hp->ops->put_chars(hp->vtermno, &ch, 1);
 	} while (n <= 0);
 }
 #endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 1be125f..7fda904 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -576,14 +576,12 @@ return_normal:
 		kgdb_roundup_cpus(flags);
 #endif
 
-#ifndef CONFIG_XEN
 	/*
 	 * Wait for the other CPUs to be notified and be waiting for us:
 	 */
 	while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
 				atomic_read(&slaves_in_kgdb)) != online_cpus)
 		cpu_relax();
-#endif
 
 	/*
 	 * At this point the primary processor is completely

--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1



-- Jim

On Jun 6, 2012, at 3:54 PM, Ben Guthro wrote:

> What kernel version?
>=20
> Below is a patch against 3.2.y that allows for debug using kdb over =
hvc
>=20
> Some bits of this were recently upstreamed as part of some perf-tools
> work in pvops...but the debug_core.c, and hvc_console.c didn't make
> it.
>=20
> With this patch, you can add the kernel parameter
> kgdboc=3Dhvc0
>=20
> Alternately, at runtime by doing the following:
> echo hvc0 > /sys/module/kgdboc/parameters/kgdboc
>=20
> To break into the debugger, you need to press the magic SysRq key
> sequence "Alt+SysRq+g"
>=20
> While you are in the debugger, you are in "polling" console mode. As
> such, there seems to be a limitation on how fast you can type
> commands. I found that when I typed two letters too fast, it just
> printed the help text again.
>=20
>=20
>=20
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index d5e0e0a..88815a1 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -65,6 +65,7 @@
>=20
>  #include "xen-ops.h"
>  #include "mmu.h"
> +#include "smp.h"
>  #include "multicalls.h"
>=20
>  EXPORT_SYMBOL_GPL(hypercall_page);
> @@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void)
>   apic->icr_write =3D xen_apic_icr_write;
>   apic->wait_icr_idle =3D xen_apic_wait_icr_idle;
>   apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle;
> +
> + apic->send_IPI_allbutself =3D xen_send_IPI_allbutself;
> + apic->send_IPI_mask_allbutself =3D xen_send_IPI_mask_allbutself;
> + apic->send_IPI_mask =3D xen_send_IPI_mask;
> + apic->send_IPI_all =3D xen_send_IPI_all;
> + apic->send_IPI_self =3D xen_send_IPI_self;
>  }
>=20
>  #endif
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 3061244..d8928a1 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
>   xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
>  }
>=20
> -static void xen_send_IPI_mask(const struct cpumask *mask,
> -      enum ipi_vector vector)
> +void xen_send_IPI_mask(const struct cpumask *mask,
> +      int vector)
>  {
>   unsigned cpu;
>=20
> @@ -466,6 +466,39 @@ static void =
xen_smp_send_call_function_single_ipi(int cpu)
>    XEN_CALL_FUNCTION_SINGLE_VECTOR);
>  }
>=20
> +void xen_send_IPI_all(int vector)
> +{
> + xen_send_IPI_mask(cpu_online_mask, vector);
> +}
> +
> +void xen_send_IPI_self(int vector)
> +{
> + xen_send_IPI_one(smp_processor_id(), vector);
> +}
> +
> +void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector)
> +{
> + unsigned cpu;
> + unsigned int this_cpu =3D smp_processor_id();
> +
> + if (!(num_online_cpus() > 1))
> + return;
> +
> + for_each_cpu_and(cpu, mask, cpu_online_mask) {
> + if (this_cpu =3D=3D cpu)
> + continue;
> +
> + xen_smp_send_call_function_single_ipi(cpu);
> + }
> +}
> +
> +void xen_send_IPI_allbutself(int vector)
> +{
> + xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
> +}
> +
> +
>  static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
>  {
>   irq_enter();
> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
> new file mode 100644
> index 0000000..8981a76
> --- /dev/null
> +++ b/arch/x86/xen/smp.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_SMP_H
> +
> +extern void xen_send_IPI_mask(const struct cpumask *mask,
> +      int vector);
> +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector);
> +extern void xen_send_IPI_allbutself(int vector);
> +extern void physflat_send_IPI_allbutself(int vector);
> +extern void xen_send_IPI_all(int vector);
> +extern void xen_send_IPI_self(int vector);
> +
> +#endif
> diff --git a/drivers/tty/hvc/hvc_console.c =
b/drivers/tty/hvc/hvc_console.c
> index 58ca7ce..4addc80 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int
> line, char *options)
>=20
>  static int hvc_poll_get_char(struct tty_driver *driver, int line)
>  {
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
>   int n;
>   char ch;
>=20
> - n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
> -
> + n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
>   if (n =3D=3D 0)
>   return NO_POLL_CHAR;
>=20
> @@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver
> *driver, int line)
>=20
>  static void hvc_poll_put_char(struct tty_driver *driver, int line, =
char ch)
>  {
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
>   int n;
>=20
>   do {
> - n =3D hp->ops->put_chars(hp->vtermno, &ch, 1);
> + n =3D cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
>   } while (n <=3D 0);
>  }
>  #endif
> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> index cefd4a1..df904a5 100644
> --- a/kernel/debug/debug_core.c
> +++ b/kernel/debug/debug_core.c
> @@ -581,12 +581,14 @@ return_normal:
>   kgdb_roundup_cpus(flags);
>  #endif
>=20
> +#ifndef CONFIG_XEN
>   /*
>   * Wait for the other CPUs to be notified and be waiting for us:
>   */
>   while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
>   atomic_read(&slaves_in_kgdb)) !=3D online_cpus)
>   cpu_relax();
> +#endif
>=20
>   /*
>   * At this point the primary processor is completely
>=20
>=20
>=20
>=20
>=20
> On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote:
>>=20
>> Thanks everyone for your help.
>>=20
>> I tried the suggestion of leaving ttyS1 out of the Xen boot options =
and using that. I confirmed that I can echo things back and forth =
through that connection from the host OS. I compiled a custom version of =
gdb to target x86_64-linux-gnu so I could do remote debugging from the =
host. No luck. I also tried setting console=3DttyS1 for the dom0 kernel =
-- same outcome.
>>=20
>> Next, using exactly the same settings, I booted the dom0 kernel bare =
(no Xen this time) and tried the same thing. This time, it worked. I can =
connect the debugger and it breaks as expected. So I'm thinking =
debugging while running Xen over serial is a dead end, unless I figure =
out a way to do it over hvc. I think for now I'll just use printk.
>>=20
>> -- Jim
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C--


From xen-devel-bounces@lists.xen.org Wed Jun 06 22:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Jun 2012 22: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 1ScOOd-0008Lk-14; Wed, 06 Jun 2012 22:08:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paton@cs.wisc.edu>) id 1ScOOb-0008Lf-A3
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 22:08:05 +0000
Received: from [85.158.143.35:22363] by server-3.bemta-4.messagelabs.com id
	B3/06-29237-4C4DFCF4; Wed, 06 Jun 2012 22:08:04 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339020481!15949711!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20622 invoked from network); 6 Jun 2012 22:08:02 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 22:08:02 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q56M7vgg029973
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 6 Jun 2012 17:07:57 -0500
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C"
From: James Paton <paton@cs.wisc.edu>
In-Reply-To: <CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
Date: Wed, 6 Jun 2012 17:07:52 -0500
Message-Id: <8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
X-Mailer: Apple Mail (2.1278)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Thank you! I am using 3.3.6, but by manually applying your patch, I got =
it to work. I've attached a patch for 3.3.6 in case anyone would find it =
useful.

-- Jim


--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Disposition: attachment;
	filename=hvc.patch
Content-Type: application/octet-stream;
	name="hvc.patch"
Content-Transfer-Encoding: 7bit

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c4c38a5..4e517d4 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -66,7 +66,6 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
-#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -760,12 +759,6 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
-	
-	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
-	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
-	apic->send_IPI_mask = xen_send_IPI_mask;
-	apic->send_IPI_all = xen_send_IPI_all;
-	apic->send_IPI_self = xen_send_IPI_self;
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 64b78f7..f2ce60a 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -474,8 +474,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-void xen_send_IPI_mask(const struct cpumask *mask, 
-		int vector)
+static void xen_send_IPI_mask(const struct cpumask *mask,
+			      enum ipi_vector vector)
 {
 	unsigned cpu;
 
@@ -504,38 +504,6 @@ static void xen_smp_send_call_function_single_ipi(int cpu)
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
-void xen_send_IPI_all(int vector)
-{
-	xen_send_IPI_mask(cpu_online_mask, vector);
-}
-
-void xen_send_IPI_self(int vector)
-{
-	xen_send_IPI_one(smp_processor_id(), vector);
-}
-
-void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
-	       int vector)
-{
-	unsigned cpu;
-	unsigned int this_cpu = smp_processor_id();
-	
-	if (!(num_online_cpus() > 1))
-		return;
-	
-	for_each_cpu_and(cpu, mask, cpu_online_mask) {
-		if (this_cpu == cpu)
-			continue;
-	
-		xen_smp_send_call_function_single_ipi(cpu);
-	}
-}
-
-void xen_send_IPI_allbutself(int vector)
-{
-	xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
-}
-
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
deleted file mode 100644
index 8e684e4..0000000
--- a/arch/x86/xen/smp.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef _XEN_SMP_H
-#define _XEN_SMP_H
-
-extern void xen_send_IPI_mask(const struct cpumask *mask,
-      int vector);
-extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
-	int vector);
-extern void xen_send_IPI_allbutself(int vector);
-extern void physflat_send_IPI_allbutself(int vector);
-extern void xen_send_IPI_all(int vector);
-extern void xen_send_IPI_self(int vector);
-
-#endif
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 401e9e3..b6b2d18 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -775,10 +775,13 @@ int hvc_poll_init(struct tty_driver *driver, int line, char *options)
 
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
+	struct tty_struct *tty = driver->ttys[0];
+	struct hvc_struct *hp = tty->driver_data;
 	int n;
 	char ch;
 
-	n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
+	n = hp->ops->get_chars(hp->vtermno, &ch, 1);
+
 	if (n == 0)
 		return NO_POLL_CHAR;
 
@@ -787,10 +790,12 @@ static int hvc_poll_get_char(struct tty_driver *driver, int line)
 
 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
+	struct tty_struct *tty = driver->ttys[0];
+	struct hvc_struct *hp = tty->driver_data;
 	int n;
 
 	do {
-		n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
+		n = hp->ops->put_chars(hp->vtermno, &ch, 1);
 	} while (n <= 0);
 }
 #endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 1be125f..7fda904 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -576,14 +576,12 @@ return_normal:
 		kgdb_roundup_cpus(flags);
 #endif
 
-#ifndef CONFIG_XEN
 	/*
 	 * Wait for the other CPUs to be notified and be waiting for us:
 	 */
 	while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
 				atomic_read(&slaves_in_kgdb)) != online_cpus)
 		cpu_relax();
-#endif
 
 	/*
 	 * At this point the primary processor is completely

--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1



-- Jim

On Jun 6, 2012, at 3:54 PM, Ben Guthro wrote:

> What kernel version?
>=20
> Below is a patch against 3.2.y that allows for debug using kdb over =
hvc
>=20
> Some bits of this were recently upstreamed as part of some perf-tools
> work in pvops...but the debug_core.c, and hvc_console.c didn't make
> it.
>=20
> With this patch, you can add the kernel parameter
> kgdboc=3Dhvc0
>=20
> Alternately, at runtime by doing the following:
> echo hvc0 > /sys/module/kgdboc/parameters/kgdboc
>=20
> To break into the debugger, you need to press the magic SysRq key
> sequence "Alt+SysRq+g"
>=20
> While you are in the debugger, you are in "polling" console mode. As
> such, there seems to be a limitation on how fast you can type
> commands. I found that when I typed two letters too fast, it just
> printed the help text again.
>=20
>=20
>=20
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index d5e0e0a..88815a1 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -65,6 +65,7 @@
>=20
>  #include "xen-ops.h"
>  #include "mmu.h"
> +#include "smp.h"
>  #include "multicalls.h"
>=20
>  EXPORT_SYMBOL_GPL(hypercall_page);
> @@ -768,6 +769,12 @@ static void set_xen_basic_apic_ops(void)
>   apic->icr_write =3D xen_apic_icr_write;
>   apic->wait_icr_idle =3D xen_apic_wait_icr_idle;
>   apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle;
> +
> + apic->send_IPI_allbutself =3D xen_send_IPI_allbutself;
> + apic->send_IPI_mask_allbutself =3D xen_send_IPI_mask_allbutself;
> + apic->send_IPI_mask =3D xen_send_IPI_mask;
> + apic->send_IPI_all =3D xen_send_IPI_all;
> + apic->send_IPI_self =3D xen_send_IPI_self;
>  }
>=20
>  #endif
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 3061244..d8928a1 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
>   xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
>  }
>=20
> -static void xen_send_IPI_mask(const struct cpumask *mask,
> -      enum ipi_vector vector)
> +void xen_send_IPI_mask(const struct cpumask *mask,
> +      int vector)
>  {
>   unsigned cpu;
>=20
> @@ -466,6 +466,39 @@ static void =
xen_smp_send_call_function_single_ipi(int cpu)
>    XEN_CALL_FUNCTION_SINGLE_VECTOR);
>  }
>=20
> +void xen_send_IPI_all(int vector)
> +{
> + xen_send_IPI_mask(cpu_online_mask, vector);
> +}
> +
> +void xen_send_IPI_self(int vector)
> +{
> + xen_send_IPI_one(smp_processor_id(), vector);
> +}
> +
> +void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector)
> +{
> + unsigned cpu;
> + unsigned int this_cpu =3D smp_processor_id();
> +
> + if (!(num_online_cpus() > 1))
> + return;
> +
> + for_each_cpu_and(cpu, mask, cpu_online_mask) {
> + if (this_cpu =3D=3D cpu)
> + continue;
> +
> + xen_smp_send_call_function_single_ipi(cpu);
> + }
> +}
> +
> +void xen_send_IPI_allbutself(int vector)
> +{
> + xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
> +}
> +
> +
>  static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
>  {
>   irq_enter();
> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
> new file mode 100644
> index 0000000..8981a76
> --- /dev/null
> +++ b/arch/x86/xen/smp.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_SMP_H
> +
> +extern void xen_send_IPI_mask(const struct cpumask *mask,
> +      int vector);
> +extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> + int vector);
> +extern void xen_send_IPI_allbutself(int vector);
> +extern void physflat_send_IPI_allbutself(int vector);
> +extern void xen_send_IPI_all(int vector);
> +extern void xen_send_IPI_self(int vector);
> +
> +#endif
> diff --git a/drivers/tty/hvc/hvc_console.c =
b/drivers/tty/hvc/hvc_console.c
> index 58ca7ce..4addc80 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -754,13 +754,10 @@ int hvc_poll_init(struct tty_driver *driver, int
> line, char *options)
>=20
>  static int hvc_poll_get_char(struct tty_driver *driver, int line)
>  {
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
>   int n;
>   char ch;
>=20
> - n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
> -
> + n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
>   if (n =3D=3D 0)
>   return NO_POLL_CHAR;
>=20
> @@ -769,12 +766,10 @@ static int hvc_poll_get_char(struct tty_driver
> *driver, int line)
>=20
>  static void hvc_poll_put_char(struct tty_driver *driver, int line, =
char ch)
>  {
> - struct tty_struct *tty =3D driver->ttys[0];
> - struct hvc_struct *hp =3D tty->driver_data;
>   int n;
>=20
>   do {
> - n =3D hp->ops->put_chars(hp->vtermno, &ch, 1);
> + n =3D cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
>   } while (n <=3D 0);
>  }
>  #endif
> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> index cefd4a1..df904a5 100644
> --- a/kernel/debug/debug_core.c
> +++ b/kernel/debug/debug_core.c
> @@ -581,12 +581,14 @@ return_normal:
>   kgdb_roundup_cpus(flags);
>  #endif
>=20
> +#ifndef CONFIG_XEN
>   /*
>   * Wait for the other CPUs to be notified and be waiting for us:
>   */
>   while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
>   atomic_read(&slaves_in_kgdb)) !=3D online_cpus)
>   cpu_relax();
> +#endif
>=20
>   /*
>   * At this point the primary processor is completely
>=20
>=20
>=20
>=20
>=20
> On Wed, Jun 6, 2012 at 3:55 PM, James Paton <paton@cs.wisc.edu> wrote:
>>=20
>> Thanks everyone for your help.
>>=20
>> I tried the suggestion of leaving ttyS1 out of the Xen boot options =
and using that. I confirmed that I can echo things back and forth =
through that connection from the host OS. I compiled a custom version of =
gdb to target x86_64-linux-gnu so I could do remote debugging from the =
host. No luck. I also tried setting console=3DttyS1 for the dom0 kernel =
-- same outcome.
>>=20
>> Next, using exactly the same settings, I booted the dom0 kernel bare =
(no Xen this time) and tried the same thing. This time, it worked. I can =
connect the debugger and it breaks as expected. So I'm thinking =
debugging while running Xen over serial is a dead end, unless I figure =
out a way to do it over hvc. I think for now I'll just use printk.
>>=20
>> -- Jim
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--Apple-Mail=_24CB5A2A-29E0-402F-AB2B-3531AF335C2C--


From xen-devel-bounces@lists.xen.org Thu Jun 07 02:35:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 02:35: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 1ScSYc-0006Z3-7b; Thu, 07 Jun 2012 02:34:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScSYZ-0006Yy-W6
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 02:34:40 +0000
Received: from [85.158.139.83:56592] by server-5.bemta-5.messagelabs.com id
	F2/45-04481-F3310DF4; Thu, 07 Jun 2012 02:34:39 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339036476!32258866!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28700 invoked from network); 7 Jun 2012 02:34:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 02:34:38 -0000
Received: by obfk16 with SMTP id k16so292772obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 19:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=6VFk4wBhfTP6M05jr3PIVTanOK/QaQzSbvHNAFBS9hE=;
	b=IVXJpz5QMH+EuLhj085pwunh64yBe3xUqW64D32wRmUXMV9rCAeaPlRmLsiHY+tpf5
	zbI2U0hhQ6QK6fpxEJ/S0LJGknoEiTWUYd5AniMdUGscRxBpXcpAiDNoRmNBEHL4NyP+
	1+SgOE59EQIBWBWg7uMFJoaR0WNw7zBs+jWxdaDbSAfzGZigxir3QweJpegbJTPWtHTU
	Bg4kNcKYz5TjcIxiYkW2HREdVhtVHa/n7pGEzKci+cHyFNtoPD97VhpHv00RwqWAMNu5
	x61V7zUrJKRMgk2cfxpEoPmPJLinvi70tGJgyOF1Pej1pGraxMUMd34n1GfrQpjJtUki
	7uwQ==
MIME-Version: 1.0
Received: by 10.60.22.201 with SMTP id g9mr420687oef.8.1339036476306; Wed, 06
	Jun 2012 19:34:36 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 19:34:36 -0700 (PDT)
In-Reply-To: <1338983231.32319.65.camel@zakaz.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
Date: Thu, 7 Jun 2012 10:34:36 +0800
Message-ID: <CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 6, 2012 at 7:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
>> =A0# Complex libxl types
>> =A0#
>> +
>> +libxl_vga_interface_info =3D Struct("vga_interface_info", [
>> + =A0 =A0("type", =A0 =A0libxl_vga_interface_type),
>> + =A0 =A0])
>
> Unfortunately "type" is a reserved word in ocaml (and possibly other
> languages, which causes the bindings to fail to build:
Thanks for your review.

I didn't build against ocaml.
I 'make install' in tools/libxl directly.
> =A0 =A0 =A0 =A0make[4]: Entering directory `/local/scratch/ianc/devel/com=
mitter.git/tools/ocaml/libs/xl'
> =A0 =A0 =A0 =A0 MLDEP
> =A0 =A0 =A0 =A0File "xenlight.ml", line 116, characters 2-6:
> =A0 =A0 =A0 =A0Error: Syntax error
> =A0 =A0 =A0 =A0 MLI =A0 =A0 =A0xenlight.cmi
> =A0 =A0 =A0 =A0File "xenlight.mli", line 116, characters 2-6:
> =A0 =A0 =A0 =A0Error: Syntax error: 'end' expected
> =A0 =A0 =A0 =A0File "xenlight.mli", line 113, characters 28-31:
> =A0 =A0 =A0 =A0Error: This 'sig' might be unmatched
>
> Ideally we'd make the bindings generator do appropriate substitutions on
> keywords but the usual workaround is to s/type/kind for the field name.
>
> BTW, I wasn't going to bounce the patch over this but could

Sorry, I'm not farmiliar with the vocabulary  'bounce',
do you mean s/type/kind is necessary or not?
I think you mean necessary, right?
> LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
> the type?
do you mean this way below?
libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
    (-1, "DEFAULT"),
    (0, "CIRRUS"),
    (1, "STD"),
    ], init_val =3D "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")

In my understanding, LIBXL_VGA_INTERFACE_TYPE_DEFAULT is not really
a meaningful vga type (even not present default vga to use, but just tag the
variable has never be initialized, so in meaningless state).
It's only used to check if libxl_vga_interface_type var is
initialized (whether stdvga setted by vm.cfg), to
avoid random value initialized.

It's equal with LIBXL_MEMKB_DEFAULT in this context.

It's the same with LIBXL_TIMER_MODE_DEFAULT
> I'm not sure why we don't do the same for
> LIBXL_TIMER_MODE_DEFAULT already.
>
> Ian.
>
>
>> +
>> =A0libxl_vnc_info =3D Struct("vnc_info", [
>> =A0 =A0 =A0("enable", =A0 =A0 =A0 =A0libxl_defbool),
>> =A0 =A0 =A0# "address:port" that should be listened on
>> @@ -281,7 +291,7 @@ libxl_domain_build_info =3D Struct("domain
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("nested_hvm", =A0 =A0 =A0 libxl_defbool),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("incr_generationid",libxl_defbool),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("nographic", =A0 =A0 =A0 =A0libxl_defbool),
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("stdvga", =A0 =A0 =A0 =A0 =A0 libxl_defbool),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("vga",
>> libxl_vga_interface_info),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("vnc", =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_vnc_info),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 # keyboard layout, default is
>> en-us keyboard
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("keymap", =A0 =A0 =A0 =A0 =A0 string),
>> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Sat Jun 02 08:39:45 2012 +=
0100
>> +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:39:37 2012 +=
0800
>> @@ -1256,7 +1256,10 @@ skip_vfb:
>> =A0#undef parse_extra_args
>>
>> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.st=
dvga, 0);
>> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_IN=
TERFACE_TYPE_STD;
>> +
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc=
.enable, 0);
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_replace_string (config, "vnclisten",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&b_in=
fo->u.hvm.vnc.listen, 0);
>> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
>> --- a/tools/libxl/xl_sxp.c =A0 =A0Sat Jun 02 08:39:45 2012 +0100
>> +++ b/tools/libxl/xl_sxp.c =A0 =A0Tue Jun 05 17:39:37 2012 +0800
>> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.ne=
sted_hvm));
>> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(no_incr_generationid %s)\n",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.in=
cr_generationid));
>> - =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n",
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.stdv=
ga));
>> + =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type =
=3D=3D
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0LIBXL_VGA_INTERFACE_TYPE_STD ?
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0"True" : "False");
>> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnc %s)\n",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.vn=
c.enable));
>> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.li=
sten);
>>
>>
>
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 02:35:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 02:35: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 1ScSYc-0006Z3-7b; Thu, 07 Jun 2012 02:34:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScSYZ-0006Yy-W6
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 02:34:40 +0000
Received: from [85.158.139.83:56592] by server-5.bemta-5.messagelabs.com id
	F2/45-04481-F3310DF4; Thu, 07 Jun 2012 02:34:39 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339036476!32258866!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28700 invoked from network); 7 Jun 2012 02:34:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 02:34:38 -0000
Received: by obfk16 with SMTP id k16so292772obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 19:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=6VFk4wBhfTP6M05jr3PIVTanOK/QaQzSbvHNAFBS9hE=;
	b=IVXJpz5QMH+EuLhj085pwunh64yBe3xUqW64D32wRmUXMV9rCAeaPlRmLsiHY+tpf5
	zbI2U0hhQ6QK6fpxEJ/S0LJGknoEiTWUYd5AniMdUGscRxBpXcpAiDNoRmNBEHL4NyP+
	1+SgOE59EQIBWBWg7uMFJoaR0WNw7zBs+jWxdaDbSAfzGZigxir3QweJpegbJTPWtHTU
	Bg4kNcKYz5TjcIxiYkW2HREdVhtVHa/n7pGEzKci+cHyFNtoPD97VhpHv00RwqWAMNu5
	x61V7zUrJKRMgk2cfxpEoPmPJLinvi70tGJgyOF1Pej1pGraxMUMd34n1GfrQpjJtUki
	7uwQ==
MIME-Version: 1.0
Received: by 10.60.22.201 with SMTP id g9mr420687oef.8.1339036476306; Wed, 06
	Jun 2012 19:34:36 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 19:34:36 -0700 (PDT)
In-Reply-To: <1338983231.32319.65.camel@zakaz.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
Date: Thu, 7 Jun 2012 10:34:36 +0800
Message-ID: <CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 6, 2012 at 7:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
>> =A0# Complex libxl types
>> =A0#
>> +
>> +libxl_vga_interface_info =3D Struct("vga_interface_info", [
>> + =A0 =A0("type", =A0 =A0libxl_vga_interface_type),
>> + =A0 =A0])
>
> Unfortunately "type" is a reserved word in ocaml (and possibly other
> languages, which causes the bindings to fail to build:
Thanks for your review.

I didn't build against ocaml.
I 'make install' in tools/libxl directly.
> =A0 =A0 =A0 =A0make[4]: Entering directory `/local/scratch/ianc/devel/com=
mitter.git/tools/ocaml/libs/xl'
> =A0 =A0 =A0 =A0 MLDEP
> =A0 =A0 =A0 =A0File "xenlight.ml", line 116, characters 2-6:
> =A0 =A0 =A0 =A0Error: Syntax error
> =A0 =A0 =A0 =A0 MLI =A0 =A0 =A0xenlight.cmi
> =A0 =A0 =A0 =A0File "xenlight.mli", line 116, characters 2-6:
> =A0 =A0 =A0 =A0Error: Syntax error: 'end' expected
> =A0 =A0 =A0 =A0File "xenlight.mli", line 113, characters 28-31:
> =A0 =A0 =A0 =A0Error: This 'sig' might be unmatched
>
> Ideally we'd make the bindings generator do appropriate substitutions on
> keywords but the usual workaround is to s/type/kind for the field name.
>
> BTW, I wasn't going to bounce the patch over this but could

Sorry, I'm not farmiliar with the vocabulary  'bounce',
do you mean s/type/kind is necessary or not?
I think you mean necessary, right?
> LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
> the type?
do you mean this way below?
libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
    (-1, "DEFAULT"),
    (0, "CIRRUS"),
    (1, "STD"),
    ], init_val =3D "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")

In my understanding, LIBXL_VGA_INTERFACE_TYPE_DEFAULT is not really
a meaningful vga type (even not present default vga to use, but just tag the
variable has never be initialized, so in meaningless state).
It's only used to check if libxl_vga_interface_type var is
initialized (whether stdvga setted by vm.cfg), to
avoid random value initialized.

It's equal with LIBXL_MEMKB_DEFAULT in this context.

It's the same with LIBXL_TIMER_MODE_DEFAULT
> I'm not sure why we don't do the same for
> LIBXL_TIMER_MODE_DEFAULT already.
>
> Ian.
>
>
>> +
>> =A0libxl_vnc_info =3D Struct("vnc_info", [
>> =A0 =A0 =A0("enable", =A0 =A0 =A0 =A0libxl_defbool),
>> =A0 =A0 =A0# "address:port" that should be listened on
>> @@ -281,7 +291,7 @@ libxl_domain_build_info =3D Struct("domain
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("nested_hvm", =A0 =A0 =A0 libxl_defbool),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("incr_generationid",libxl_defbool),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("nographic", =A0 =A0 =A0 =A0libxl_defbool),
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("stdvga", =A0 =A0 =A0 =A0 =A0 libxl_defbool),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("vga",
>> libxl_vga_interface_info),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("vnc", =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_vnc_info),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 # keyboard layout, default is
>> en-us keyboard
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 ("keymap", =A0 =A0 =A0 =A0 =A0 string),
>> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Sat Jun 02 08:39:45 2012 +=
0100
>> +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:39:37 2012 +=
0800
>> @@ -1256,7 +1256,10 @@ skip_vfb:
>> =A0#undef parse_extra_args
>>
>> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.st=
dvga, 0);
>> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_IN=
TERFACE_TYPE_STD;
>> +
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc=
.enable, 0);
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_replace_string (config, "vnclisten",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&b_in=
fo->u.hvm.vnc.listen, 0);
>> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
>> --- a/tools/libxl/xl_sxp.c =A0 =A0Sat Jun 02 08:39:45 2012 +0100
>> +++ b/tools/libxl/xl_sxp.c =A0 =A0Tue Jun 05 17:39:37 2012 +0800
>> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.ne=
sted_hvm));
>> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(no_incr_generationid %s)\n",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.in=
cr_generationid));
>> - =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n",
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.stdv=
ga));
>> + =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type =
=3D=3D
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0LIBXL_VGA_INTERFACE_TYPE_STD ?
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0"True" : "False");
>> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnc %s)\n",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.vn=
c.enable));
>> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.li=
sten);
>>
>>
>
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 02:45:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 02: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 1ScSiu-0006yJ-WA; Thu, 07 Jun 2012 02:45: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 1ScSit-0006y7-Kh
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 02:45:19 +0000
Received: from [85.158.139.83:59817] by server-5.bemta-5.messagelabs.com id
	65/7B-04481-EB510DF4; Thu, 07 Jun 2012 02:45:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339037117!25132949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20833 invoked from network); 7 Jun 2012 02:45:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 02:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,727,1330905600"; d="scan'208";a="12870401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 02:45:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 03:45:16 +0100
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 1ScSiq-0004zr-FP;
	Thu, 07 Jun 2012 02:45:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScSiq-0000BI-EL;
	Thu, 07 Jun 2012 03:45:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13020-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Jun 2012 03:45:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13020: 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 13020 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13020/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 13018
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13018

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  f6bfaf9daa50
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=f6bfaf9daa50
+ . 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 f6bfaf9daa50
+ branch=xen-unstable
+ revision=f6bfaf9daa50
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r f6bfaf9daa50 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 12 files

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 02:45:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 02: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 1ScSiu-0006yJ-WA; Thu, 07 Jun 2012 02:45: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 1ScSit-0006y7-Kh
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 02:45:19 +0000
Received: from [85.158.139.83:59817] by server-5.bemta-5.messagelabs.com id
	65/7B-04481-EB510DF4; Thu, 07 Jun 2012 02:45:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339037117!25132949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20833 invoked from network); 7 Jun 2012 02:45:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 02:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,727,1330905600"; d="scan'208";a="12870401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 02:45:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 03:45:16 +0100
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 1ScSiq-0004zr-FP;
	Thu, 07 Jun 2012 02:45:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScSiq-0000BI-EL;
	Thu, 07 Jun 2012 03:45:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13020-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Jun 2012 03:45:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13020: 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 13020 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13020/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 13018
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13018

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  f6bfaf9daa50
baseline version:
 xen                  6bea63e6c780

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


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

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

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


Pushing revision :

+ branch=xen-unstable
+ revision=f6bfaf9daa50
+ . 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 f6bfaf9daa50
+ branch=xen-unstable
+ revision=f6bfaf9daa50
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r f6bfaf9daa50 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 12 files

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 03:19:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 03:19: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 1ScTFr-0007LJ-W4; Thu, 07 Jun 2012 03:19:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScTFq-0007LE-CU
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 03:19:22 +0000
Received: from [85.158.143.35:29563] by server-3.bemta-4.messagelabs.com id
	02/F4-29237-9BD10DF4; Thu, 07 Jun 2012 03:19:21 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339039159!15971090!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23076 invoked from network); 7 Jun 2012 03:19:20 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 03:19:20 -0000
Received: by obfk16 with SMTP id k16so357167obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 20:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=rcA6etkeYwqmhMd1d+PFG5q5BPYaZ1tyqf4q5aR9s4Q=;
	b=00xKnAuCLO3Lmq790si+r726ms28rYc5gJ9wjjUghdSfQaTpG2v44SNTY1sVGBeTXq
	07zOmmqPL+/vNxxbl5jjp7gkSHhNFiLu3yQXWQw7T5qDJM7IAi6ttSwna9LPddMjiPBe
	1RNkSLcAbIv1+DvH3QTS+8WKHiSZx157KdOqr8RA6W4zCmCVo58NxPYIHgeKQcIi4Qbj
	MU4i/Gw6md462MZKJ1UyF5PiHJhZYUXEMV3WSTvbCmCq1EKhYMVwZFf2QVT5EfNBmjL+
	6RtE1yUNaPhhyan/EonhVDP/3sgrD6/T/DUsJzJaFaIkK9ub6f4Pyr++5/7XxUyf4eQ8
	cwcQ==
MIME-Version: 1.0
Received: by 10.182.40.71 with SMTP id v7mr539183obk.5.1339039158943; Wed, 06
	Jun 2012 20:19:18 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 20:19:18 -0700 (PDT)
In-Reply-To: <1338987918.32319.84.camel@zakaz.uk.xensource.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
Date: Thu, 7 Jun 2012 11:19:18 +0800
Message-ID: <CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 6, 2012 at 9:05 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
>> changeset: =A0 25454:1804a873a64d
>> tag: =A0 =A0 =A0 =A0 tip
>> user: =A0 =A0 =A0 =A0Zhou Peng <ailvpeng25@gmail.com>
>> date: =A0 =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +0800
>> files: =A0 =A0 =A0 tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
>> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
>> description:
>> tools:libxl: Add qxl vga interface support.
>>
>> Usage:
>> =A0qxl=3D1
>> =A0qxlvram=3D64
>> =A0qxlram=3D64
>>
>> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>
> Thanks.
>
> As previously mentioned this is =A04.3 material. Please can you resubmit
> once the 4.3 dev cycle opens.
ok, thanks.
>
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
>> --- a/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:39:37 2012 +08=
00
>> +++ b/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +08=
00
>> @@ -23,6 +23,32 @@
>> =A0#include <xc_dom.h>
>> =A0#include <xenguest.h>
>>
>> +/*
>> + * For qxl vga interface, the total video mem is determined by
>> + * RAM bar and VRAM bar. But it is not simply linearly determined,
>> + * get_qxl_ram_size below gives the details.
>
> From this statement I expected get_qxl_ram_size to have a nice comment
> explaining what is going on, but it doesn't have this.
>
> Can you please explain somewhere how this value is determined (I can see
> it is not simple ;-)). Perhaps a link to some QXL/qemu document
> discussing these parameters would be helpful too?

Sorry, there is not a piece of docs on ram bar and vram bar, and how
the total size
of qxl video memory is calculated from ram bar and vram bar parameters.

But from my digging into qxl's source code and debugging, it works this way.

I asked similar question in spice-list and get response from:
http://comments.gmane.org/gmane.comp.emulators.spice.devel/9501

Any way, I will rich the document if get more info.
>> + */
>> +static inline uint32_t msb_mask(uint32_t val)
>> +{
>> + =A0 =A0uint32_t mask;
>> +
>> + =A0 =A0do {
>> + =A0 =A0 =A0 =A0mask =3D ~(val - 1) & val;
>> + =A0 =A0 =A0 =A0val &=3D ~mask;
>> + =A0 =A0} while (mask < val);
>> +
>> + =A0 =A0return mask;
>> +}
>> +
>> +static inline uint32_t get_qxl_ram_size(uint32_t vram_sizekb,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0uint32_t ram_sizekb)
>> +{
>> + =A0 =A0uint32_t vram =3D msb_mask(2 * vram_sizekb * 1024 - 1);
>> + =A0 =A0uint32_t ram =3D msb_mask(2 * ram_sizekb * 1024 - 1);
>
> Why 2*?

I don't know why yet, but it works this way in qxl.
>
>> +
>> + =A0 =A0return (vram + ram + 1023) / 1024;
>> +}
>> +
>> =A0void libxl_domain_config_init(libxl_domain_config *d_config)
>> =A0{
>> =A0 =A0 =A0memset(d_config, 0, sizeof(*d_config));
>> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
>>
>> =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_INTERFACE=
_TYPE_DEFAULT)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_INTERFAC=
E_TYPE_CIRRUS;
>> + =A0 =A0 =A0 =A0if (b_info->device_model_version =3D=3D LIBXL_DEVICE_MO=
DEL_VERSION_QEMU_XEN
>> + =A0 =A0 =A0 =A0 =A0 =A0&& b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_INTE=
RFACE_TYPE_QXL) {
>> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.vramkb =3D=3D LIBXL_MEMKB=
_DEFAULT)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.vramkb =3D 64 * 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.ramkb =3D=3D LIBXL_MEMKB_=
DEFAULT)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb =3D 64 * 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0uint32_t qxl_ram =3D get_qxl_ram_size(b_info->u=
.hvm.vga.vramkb,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb);
>> + =A0 =A0 =A0 =A0 =A0 =A0/*
>> + =A0 =A0 =A0 =A0 =A0 =A0 * video_memkb is the real size of video memory=
 to assign.
>> + =A0 =A0 =A0 =A0 =A0 =A0 * If video_memkb can't meet the need of qxl, a=
djust it
>> + =A0 =A0 =A0 =A0 =A0 =A0 * accordingly.
>> + =A0 =A0 =A0 =A0 =A0 =A0 */
>> + =A0 =A0 =A0 =A0 =A0 =A0if ((b_info->video_memkb =3D=3D LIBXL_MEMKB_DEF=
AULT)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| (b_info->video_memkb < qxl_ram)) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->video_memkb =3D qxl_ram;
>
> If video_memkb is !=3D LIBXL_MEMKB_DEFAULT and it is not sufficiently
> large then I think the correct thing to do is to error out and return
> ERROR_INVAL.

Not agreed.
This will let user must to set a proper value to meet qxl, but from
discussing above,
it's difficult for user to give this decision.
qxlram and qxlvram parameters are enough  for user to set qxl's video
ram (libvirt also use
these two parameters).
>
> If it is =3D=3D LIBXL_MEMKB_DEFAULT then of course you can feel free to
> override as necessary.
>
> e.g.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DE=
FAULT)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b_info->video_memkb =3D qxl_ram;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (b_info->video_memkb < qxl_ram) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LOG(...)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERROR_INVAL;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
>> + =A0 =A0 =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0}
>> +
>> =A0 =A0 =A0 =A0 =A0libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, t=
rue);
>> =A0 =A0 =A0 =A0 =A0if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_defbool_setdefault(&b_info->u.hvm.vnc.f=
indunused, true);
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_dm.c
>> --- a/tools/libxl/libxl_dm.c =A0Tue Jun 05 17:39:37 2012 +0800
>> +++ b/tools/libxl/libxl_dm.c =A0Tue Jun 05 17:56:46 2012 +0800
>> @@ -181,6 +181,8 @@ static char ** libxl__build_device_model
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0flexarray_append(dm_args, "-std-vga");
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>> + =A0 =A0 =A0 =A0 =A0 =A0break;
>> + =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_QXL:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> @@ -429,6 +431,17 @@ static char ** libxl__build_device_model
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-vga", "cirrus", =
NULL);
>> + =A0 =A0 =A0 =A0 =A0 =A0break;
>> + =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_QXL:
>> + =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-vga", "qxl", NULL);
>> + =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-global",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GCSPRINTF("=
qxl-vga.vram_size=3D%lu",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0b_info->u.hvm.vga.vramkb * 1024),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NULL);
>> + =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-global",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GCSPRINTF("=
qxl-vga.ram_size=3D%lu",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0b_info->u.hvm.vga.ramkb * 1024),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NULL);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_types.idl
>> --- a/tools/libxl/libxl_types.idl =A0 =A0 Tue Jun 05 17:39:37 2012 +0800
>> +++ b/tools/libxl/libxl_types.idl =A0 =A0 Tue Jun 05 17:56:46 2012 +0800
>> @@ -128,6 +128,7 @@ libxl_vga_interface_type =3D Enumeration("
>> =A0libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
>> =A0 =A0 =A0(0, "CIRRUS"),
>> =A0 =A0 =A0(1, "STD"),
>> + =A0 =A0(2, "QXL"),
>> =A0 =A0 =A0], init_val =3D "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
>>
>> =A0#
>> @@ -136,6 +137,10 @@ libxl_vga_interface_type =3D Enumeration("
>>
>> =A0libxl_vga_interface_info =3D Struct("vga_interface_info", [
>> =A0 =A0 =A0("type", =A0 =A0libxl_vga_interface_type),
>> + =A0 =A0# VRAM bar for qxl
>> + =A0 =A0("vramkb", =A0MemKB),
>> + =A0 =A0# RAM bar for qxl
>> + =A0 =A0("ramkb", =A0MemKB),
>> =A0 =A0 =A0])
>>
>> =A0libxl_vnc_info =3D Struct("vnc_info", [
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:39:37 2012 +=
0800
>> +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +=
0800
>> @@ -1260,6 +1260,16 @@ skip_vfb:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_=
INTERFACE_TYPE_STD;
>>
>> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
>> + =A0 =A0 =A0 =A0 =A0 =A0if (l) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_IN=
TERFACE_TYPE_QXL;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long (config, "qxlvram=
", &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.vramkb =3D l =
* 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long (config, "qxlram"=
, &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb =3D l *=
 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0}
>> +
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc=
.enable, 0);
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_replace_string (config, "vnclisten",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&b_in=
fo->u.hvm.vnc.listen, 0);
>>
>>
>
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 03:19:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 03:19: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 1ScTFr-0007LJ-W4; Thu, 07 Jun 2012 03:19:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScTFq-0007LE-CU
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 03:19:22 +0000
Received: from [85.158.143.35:29563] by server-3.bemta-4.messagelabs.com id
	02/F4-29237-9BD10DF4; Thu, 07 Jun 2012 03:19:21 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339039159!15971090!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23076 invoked from network); 7 Jun 2012 03:19:20 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 03:19:20 -0000
Received: by obfk16 with SMTP id k16so357167obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 20:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=rcA6etkeYwqmhMd1d+PFG5q5BPYaZ1tyqf4q5aR9s4Q=;
	b=00xKnAuCLO3Lmq790si+r726ms28rYc5gJ9wjjUghdSfQaTpG2v44SNTY1sVGBeTXq
	07zOmmqPL+/vNxxbl5jjp7gkSHhNFiLu3yQXWQw7T5qDJM7IAi6ttSwna9LPddMjiPBe
	1RNkSLcAbIv1+DvH3QTS+8WKHiSZx157KdOqr8RA6W4zCmCVo58NxPYIHgeKQcIi4Qbj
	MU4i/Gw6md462MZKJ1UyF5PiHJhZYUXEMV3WSTvbCmCq1EKhYMVwZFf2QVT5EfNBmjL+
	6RtE1yUNaPhhyan/EonhVDP/3sgrD6/T/DUsJzJaFaIkK9ub6f4Pyr++5/7XxUyf4eQ8
	cwcQ==
MIME-Version: 1.0
Received: by 10.182.40.71 with SMTP id v7mr539183obk.5.1339039158943; Wed, 06
	Jun 2012 20:19:18 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 20:19:18 -0700 (PDT)
In-Reply-To: <1338987918.32319.84.camel@zakaz.uk.xensource.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
Date: Thu, 7 Jun 2012 11:19:18 +0800
Message-ID: <CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 6, 2012 at 9:05 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
>> changeset: =A0 25454:1804a873a64d
>> tag: =A0 =A0 =A0 =A0 tip
>> user: =A0 =A0 =A0 =A0Zhou Peng <ailvpeng25@gmail.com>
>> date: =A0 =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +0800
>> files: =A0 =A0 =A0 tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
>> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
>> description:
>> tools:libxl: Add qxl vga interface support.
>>
>> Usage:
>> =A0qxl=3D1
>> =A0qxlvram=3D64
>> =A0qxlram=3D64
>>
>> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>
> Thanks.
>
> As previously mentioned this is =A04.3 material. Please can you resubmit
> once the 4.3 dev cycle opens.
ok, thanks.
>
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
>> --- a/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:39:37 2012 +08=
00
>> +++ b/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +08=
00
>> @@ -23,6 +23,32 @@
>> =A0#include <xc_dom.h>
>> =A0#include <xenguest.h>
>>
>> +/*
>> + * For qxl vga interface, the total video mem is determined by
>> + * RAM bar and VRAM bar. But it is not simply linearly determined,
>> + * get_qxl_ram_size below gives the details.
>
> From this statement I expected get_qxl_ram_size to have a nice comment
> explaining what is going on, but it doesn't have this.
>
> Can you please explain somewhere how this value is determined (I can see
> it is not simple ;-)). Perhaps a link to some QXL/qemu document
> discussing these parameters would be helpful too?

Sorry, there is not a piece of docs on ram bar and vram bar, and how
the total size
of qxl video memory is calculated from ram bar and vram bar parameters.

But from my digging into qxl's source code and debugging, it works this way.

I asked similar question in spice-list and get response from:
http://comments.gmane.org/gmane.comp.emulators.spice.devel/9501

Any way, I will rich the document if get more info.
>> + */
>> +static inline uint32_t msb_mask(uint32_t val)
>> +{
>> + =A0 =A0uint32_t mask;
>> +
>> + =A0 =A0do {
>> + =A0 =A0 =A0 =A0mask =3D ~(val - 1) & val;
>> + =A0 =A0 =A0 =A0val &=3D ~mask;
>> + =A0 =A0} while (mask < val);
>> +
>> + =A0 =A0return mask;
>> +}
>> +
>> +static inline uint32_t get_qxl_ram_size(uint32_t vram_sizekb,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0uint32_t ram_sizekb)
>> +{
>> + =A0 =A0uint32_t vram =3D msb_mask(2 * vram_sizekb * 1024 - 1);
>> + =A0 =A0uint32_t ram =3D msb_mask(2 * ram_sizekb * 1024 - 1);
>
> Why 2*?

I don't know why yet, but it works this way in qxl.
>
>> +
>> + =A0 =A0return (vram + ram + 1023) / 1024;
>> +}
>> +
>> =A0void libxl_domain_config_init(libxl_domain_config *d_config)
>> =A0{
>> =A0 =A0 =A0memset(d_config, 0, sizeof(*d_config));
>> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
>>
>> =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_INTERFACE=
_TYPE_DEFAULT)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_INTERFAC=
E_TYPE_CIRRUS;
>> + =A0 =A0 =A0 =A0if (b_info->device_model_version =3D=3D LIBXL_DEVICE_MO=
DEL_VERSION_QEMU_XEN
>> + =A0 =A0 =A0 =A0 =A0 =A0&& b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_INTE=
RFACE_TYPE_QXL) {
>> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.vramkb =3D=3D LIBXL_MEMKB=
_DEFAULT)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.vramkb =3D 64 * 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.ramkb =3D=3D LIBXL_MEMKB_=
DEFAULT)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb =3D 64 * 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0uint32_t qxl_ram =3D get_qxl_ram_size(b_info->u=
.hvm.vga.vramkb,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb);
>> + =A0 =A0 =A0 =A0 =A0 =A0/*
>> + =A0 =A0 =A0 =A0 =A0 =A0 * video_memkb is the real size of video memory=
 to assign.
>> + =A0 =A0 =A0 =A0 =A0 =A0 * If video_memkb can't meet the need of qxl, a=
djust it
>> + =A0 =A0 =A0 =A0 =A0 =A0 * accordingly.
>> + =A0 =A0 =A0 =A0 =A0 =A0 */
>> + =A0 =A0 =A0 =A0 =A0 =A0if ((b_info->video_memkb =3D=3D LIBXL_MEMKB_DEF=
AULT)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| (b_info->video_memkb < qxl_ram)) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->video_memkb =3D qxl_ram;
>
> If video_memkb is !=3D LIBXL_MEMKB_DEFAULT and it is not sufficiently
> large then I think the correct thing to do is to error out and return
> ERROR_INVAL.

Not agreed.
This will let user must to set a proper value to meet qxl, but from
discussing above,
it's difficult for user to give this decision.
qxlram and qxlvram parameters are enough  for user to set qxl's video
ram (libvirt also use
these two parameters).
>
> If it is =3D=3D LIBXL_MEMKB_DEFAULT then of course you can feel free to
> override as necessary.
>
> e.g.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DE=
FAULT)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b_info->video_memkb =3D qxl_ram;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (b_info->video_memkb < qxl_ram) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LOG(...)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERROR_INVAL;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
>> + =A0 =A0 =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0}
>> +
>> =A0 =A0 =A0 =A0 =A0libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, t=
rue);
>> =A0 =A0 =A0 =A0 =A0if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_defbool_setdefault(&b_info->u.hvm.vnc.f=
indunused, true);
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_dm.c
>> --- a/tools/libxl/libxl_dm.c =A0Tue Jun 05 17:39:37 2012 +0800
>> +++ b/tools/libxl/libxl_dm.c =A0Tue Jun 05 17:56:46 2012 +0800
>> @@ -181,6 +181,8 @@ static char ** libxl__build_device_model
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0flexarray_append(dm_args, "-std-vga");
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>> + =A0 =A0 =A0 =A0 =A0 =A0break;
>> + =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_QXL:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> @@ -429,6 +431,17 @@ static char ** libxl__build_device_model
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-vga", "cirrus", =
NULL);
>> + =A0 =A0 =A0 =A0 =A0 =A0break;
>> + =A0 =A0 =A0 =A0case LIBXL_VGA_INTERFACE_TYPE_QXL:
>> + =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-vga", "qxl", NULL);
>> + =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-global",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GCSPRINTF("=
qxl-vga.vram_size=3D%lu",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0b_info->u.hvm.vga.vramkb * 1024),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NULL);
>> + =A0 =A0 =A0 =A0 =A0 =A0flexarray_vappend(dm_args, "-global",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GCSPRINTF("=
qxl-vga.ram_size=3D%lu",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0b_info->u.hvm.vga.ramkb * 1024),
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NULL);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_types.idl
>> --- a/tools/libxl/libxl_types.idl =A0 =A0 Tue Jun 05 17:39:37 2012 +0800
>> +++ b/tools/libxl/libxl_types.idl =A0 =A0 Tue Jun 05 17:56:46 2012 +0800
>> @@ -128,6 +128,7 @@ libxl_vga_interface_type =3D Enumeration("
>> =A0libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
>> =A0 =A0 =A0(0, "CIRRUS"),
>> =A0 =A0 =A0(1, "STD"),
>> + =A0 =A0(2, "QXL"),
>> =A0 =A0 =A0], init_val =3D "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
>>
>> =A0#
>> @@ -136,6 +137,10 @@ libxl_vga_interface_type =3D Enumeration("
>>
>> =A0libxl_vga_interface_info =3D Struct("vga_interface_info", [
>> =A0 =A0 =A0("type", =A0 =A0libxl_vga_interface_type),
>> + =A0 =A0# VRAM bar for qxl
>> + =A0 =A0("vramkb", =A0MemKB),
>> + =A0 =A0# RAM bar for qxl
>> + =A0 =A0("ramkb", =A0MemKB),
>> =A0 =A0 =A0])
>>
>> =A0libxl_vnc_info =3D Struct("vnc_info", [
>> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:39:37 2012 +=
0800
>> +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +=
0800
>> @@ -1260,6 +1260,16 @@ skip_vfb:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_=
INTERFACE_TYPE_STD;
>>
>> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
>> + =A0 =A0 =A0 =A0 =A0 =A0if (l) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_IN=
TERFACE_TYPE_QXL;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long (config, "qxlvram=
", &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.vramkb =3D l =
* 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long (config, "qxlram"=
, &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb =3D l *=
 1024;
>> + =A0 =A0 =A0 =A0 =A0 =A0}
>> + =A0 =A0 =A0 =A0}
>> +
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc=
.enable, 0);
>> =A0 =A0 =A0 =A0 =A0xlu_cfg_replace_string (config, "vnclisten",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&b_in=
fo->u.hvm.vnc.listen, 0);
>>
>>
>
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 03:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 03: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 1ScTIW-0007Qb-Hs; Thu, 07 Jun 2012 03:22:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScTIV-0007QU-4V
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 03:22:07 +0000
Received: from [85.158.138.51:20769] by server-11.bemta-3.messagelabs.com id
	91/21-28329-E5E10DF4; Thu, 07 Jun 2012 03:22:06 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339039324!23067422!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29724 invoked from network); 7 Jun 2012 03:22:05 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 03:22:05 -0000
Received: by obfk16 with SMTP id k16so360847obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 20:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=+az2ADfR22FF6AI0SZb2iB5G1kQYLZ9nqoF2YFijyjE=;
	b=zHWAoD7lOrz/yMeiEhG669CWN0qgU2LKH6SXk+YH0v8cIOlILcJhqpoUFY3XvD62v3
	+jYh+odEpdKbUUJuVbLQO5J/KmZDNw8aYaJUOPlFIAgpZ0fuPknpKUfPFX2EzVex3LH4
	DvZZjijzg0BC2DDNEYLeV8FGmZ75E+JsCcf4OPL5kiLwEhlc095rPClflhXpv+ETVzDn
	KBu9R4nN5Vu3fQ3vwQoXBYRSGTuMWwSPET3LZNlTHrjSy7QqDzczxOOoZW5+tUcY7b+/
	UvYIWxeqLa75dT+iLFt64EHebSI4PdNiFAI61vMBtOw91ASrTj6JMCL5TGqCGk3zGl0q
	3A/g==
MIME-Version: 1.0
Received: by 10.60.22.201 with SMTP id g9mr514435oef.8.1339039323904; Wed, 06
	Jun 2012 20:22:03 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 20:22:03 -0700 (PDT)
In-Reply-To: <1338988073.32319.86.camel@zakaz.uk.xensource.com>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
	<1338988073.32319.86.camel@zakaz.uk.xensource.com>
Date: Thu, 7 Jun 2012 11:22:03 +0800
Message-ID: <CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface 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="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, Jun 6, 2012 at 9:07 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Tue, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
>> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>
> You can/should include this with the patch which adds the functionality,
> no need to separate it out.
Ok.
>
>>
>> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 17:56:46 2012 +0800
>> +++ b/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 18:58:12 2012 +0800
>> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
>>
>> =A0Sets the amount of RAM which the emulated video card will contain,
>> =A0which 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). The default is 8MB which is sufficient for
>> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
>> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
>> +available. This option is available when using the B<stdvga> and
>> +B<qxl> options (see below).
>> +For B<stdvga> option, the default is 8MB which is sufficient for
>> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> option=
s,
>> +the amount of video ram is fixed at 4MB which is sufficient for 1024x768
>> =A0at 32 bpp.
>> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
>> +option below).
>>
>> =A0=3Ditem B<stdvga=3DBOOLEAN>
>>
>> @@ -711,6 +714,27 @@ emulated graphics device. The default is
>> =A0emulated graphics device. The default is false which means to emulate
>> =A0a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>> =A0later (e.g. Windows XP onwards) then you should enable this.
>> +
>> +=3Ditem B<qxl=3DBOOLEAN>
>> +
>> +Select a QXL VGA card as the emulated graphics device. This enables
>> +the other QXL-related settings.
>> +In general, QXL should work with the Spice remote display protocol for
>> +acceleration, but QXL driver is necessary in guest. QXL can also work
>> +with the VNC protocol like a standard VGA without acceleration.
>> +
>> +=3Ditem B<qxlram=3DMBYTES>
>> +
>> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
>> +The total size of QXL video memory is determined by B<qxlram> (RAM bar)
>> +and B<qxlvram> (VRAM bar), the size of each is settable.
>> +B<videoram> can set the amount of RAM which emulated video card
>> +will contain, but if it can't meet the need of QXL, it will be
>> +adjusted accordingly.
>> +
>> +=3Ditem B<qxlvram=3DMBYTES>
>> +
>> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.
>
> It's not clear to me having read this what the distinction between RAM
> and VRAM is in the context of QXL. When and why would I want to set
> either?
Both of them are necessary to set qxl video ram.
They are necessary paremeters of qxl.

Any way, I will rich the document if get more info.
Thanks.
> Ian.
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 03:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 03: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 1ScTIW-0007Qb-Hs; Thu, 07 Jun 2012 03:22:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScTIV-0007QU-4V
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 03:22:07 +0000
Received: from [85.158.138.51:20769] by server-11.bemta-3.messagelabs.com id
	91/21-28329-E5E10DF4; Thu, 07 Jun 2012 03:22:06 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339039324!23067422!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29724 invoked from network); 7 Jun 2012 03:22:05 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 03:22:05 -0000
Received: by obfk16 with SMTP id k16so360847obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Jun 2012 20:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=+az2ADfR22FF6AI0SZb2iB5G1kQYLZ9nqoF2YFijyjE=;
	b=zHWAoD7lOrz/yMeiEhG669CWN0qgU2LKH6SXk+YH0v8cIOlILcJhqpoUFY3XvD62v3
	+jYh+odEpdKbUUJuVbLQO5J/KmZDNw8aYaJUOPlFIAgpZ0fuPknpKUfPFX2EzVex3LH4
	DvZZjijzg0BC2DDNEYLeV8FGmZ75E+JsCcf4OPL5kiLwEhlc095rPClflhXpv+ETVzDn
	KBu9R4nN5Vu3fQ3vwQoXBYRSGTuMWwSPET3LZNlTHrjSy7QqDzczxOOoZW5+tUcY7b+/
	UvYIWxeqLa75dT+iLFt64EHebSI4PdNiFAI61vMBtOw91ASrTj6JMCL5TGqCGk3zGl0q
	3A/g==
MIME-Version: 1.0
Received: by 10.60.22.201 with SMTP id g9mr514435oef.8.1339039323904; Wed, 06
	Jun 2012 20:22:03 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 6 Jun 2012 20:22:03 -0700 (PDT)
In-Reply-To: <1338988073.32319.86.camel@zakaz.uk.xensource.com>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
	<1338988073.32319.86.camel@zakaz.uk.xensource.com>
Date: Thu, 7 Jun 2012 11:22:03 +0800
Message-ID: <CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface 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="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, Jun 6, 2012 at 9:07 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Tue, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
>> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>
> You can/should include this with the patch which adds the functionality,
> no need to separate it out.
Ok.
>
>>
>> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 17:56:46 2012 +0800
>> +++ b/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 18:58:12 2012 +0800
>> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
>>
>> =A0Sets the amount of RAM which the emulated video card will contain,
>> =A0which 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). The default is 8MB which is sufficient for
>> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
>> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
>> +available. This option is available when using the B<stdvga> and
>> +B<qxl> options (see below).
>> +For B<stdvga> option, the default is 8MB which is sufficient for
>> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> option=
s,
>> +the amount of video ram is fixed at 4MB which is sufficient for 1024x768
>> =A0at 32 bpp.
>> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
>> +option below).
>>
>> =A0=3Ditem B<stdvga=3DBOOLEAN>
>>
>> @@ -711,6 +714,27 @@ emulated graphics device. The default is
>> =A0emulated graphics device. The default is false which means to emulate
>> =A0a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>> =A0later (e.g. Windows XP onwards) then you should enable this.
>> +
>> +=3Ditem B<qxl=3DBOOLEAN>
>> +
>> +Select a QXL VGA card as the emulated graphics device. This enables
>> +the other QXL-related settings.
>> +In general, QXL should work with the Spice remote display protocol for
>> +acceleration, but QXL driver is necessary in guest. QXL can also work
>> +with the VNC protocol like a standard VGA without acceleration.
>> +
>> +=3Ditem B<qxlram=3DMBYTES>
>> +
>> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
>> +The total size of QXL video memory is determined by B<qxlram> (RAM bar)
>> +and B<qxlvram> (VRAM bar), the size of each is settable.
>> +B<videoram> can set the amount of RAM which emulated video card
>> +will contain, but if it can't meet the need of QXL, it will be
>> +adjusted accordingly.
>> +
>> +=3Ditem B<qxlvram=3DMBYTES>
>> +
>> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.
>
> It's not clear to me having read this what the distinction between RAM
> and VRAM is in the context of QXL. When and why would I want to set
> either?
Both of them are necessary to set qxl video ram.
They are necessary paremeters of qxl.

Any way, I will rich the document if get more info.
Thanks.
> Ian.
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 04:30:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 04: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 1ScUM4-0007y3-Sm; Thu, 07 Jun 2012 04:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1ScUM2-0007xy-Vh
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 04:29:51 +0000
Received: from [85.158.143.99:8720] by server-3.bemta-4.messagelabs.com id
	FC/ED-29237-E3E20DF4; Thu, 07 Jun 2012 04:29:50 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339043387!30768795!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23212 invoked from network); 7 Jun 2012 04:29:48 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 04:29:48 -0000
Received: by wibhr14 with SMTP id hr14so131011wib.14
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 21:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=dzajZXVCApLavNUJ4uKbO3w4OhzQRYJrdfWBv0YFEpc=;
	b=GqYeqCv9sROLdxG2L79KHxjfQpUGG0RGOYYWr/5IpSRFD4JGIVKU1yW7xMHPZK0hwt
	03T2pkaw1Sb2wPcWcyeJrXB+jDkmLcM8pyUfKl2eapHe2/SNW9O2LroTPiAL37IDA5dE
	gN+UYnl0DHL7EDF8q+tDNeNnipDgWvHD5v6KHjv8DM0BaZcD2drDsSDjEGA7tuS8nqED
	NmFwPDyPNvmBrCQSlywtQ0lB3Yp4Ea2L19B2ZLJAdKGXItYlKKOqWr9urnoa/mQDnJWR
	vZ2YWiBfRadQtL1l4YzS2RW1xSLtt0vjrxPsv0tZ3nOdh863Uh7TpRnI0NttpZXn+39K
	dbRA==
MIME-Version: 1.0
Received: by 10.216.207.67 with SMTP id m45mr572691weo.175.1339043367871; Wed,
	06 Jun 2012 21:29:27 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Wed, 6 Jun 2012 21:29:27 -0700 (PDT)
In-Reply-To: <1338975815.32319.40.camel@zakaz.uk.xensource.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
Date: Wed, 6 Jun 2012 21:29:27 -0700
Message-ID: <CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0409924017757288763=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0409924017757288763==
Content-Type: multipart/alternative; boundary=0016e6d9a2d447e57404c1da5444

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

Thanks but I think if I find the base physical address of xen image I can
convert virtual address to physical address
I'm working in xen4 and my platform is: Processor AMD 64 and Centos 6 i386
with 8G of RAM
Can anyone tell me The physical address that xen image load in it? This
physical address depends on platform?

Thanks a lot


On Wed, Jun 6, 2012 at 2:43 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-06-05 at 07:07 +0100, Zeinab Alebouyeh wrote:
> > Hi everyone,
> > I'm working on a research project. I add a hypercall to xen. It works
> > properly.
> > In my Hypercall function I have a label and I want the physical
> > address of my label to pass to another function. How can I grab the
> > physical address of the label?
>
> AFAIK there is no way to do this in standard C.
>
> xen-devel isn't really the best place to be asking C programming
> questions. I suggest you either speak to your advisor/mentor or seek out
> one of the C forums on the Internet.
>
> Ian.
>
>

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

Thanks but I think if I find the base physical address of xen image I can c=
onvert virtual address to physical address<br>I&#39;m working in xen4 and m=
y platform is: Processor AMD 64 and Centos 6 i386 with 8G of RAM<br>Can any=
one tell me The physical address that xen image load in it? This physical a=
ddress depends on platform?<br>
<br>Thanks a lot<br><br><br><div class=3D"gmail_quote">On Wed, Jun 6, 2012 =
at 2:43 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbe=
ll@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On T=
ue, 2012-06-05 at 07:07 +0100, Zeinab Alebouyeh wrote:<br>
&gt; Hi everyone,<br>
&gt; I&#39;m working on a research project. I add a hypercall to xen. It wo=
rks<br>
&gt; properly.<br>
&gt; In my Hypercall function I have a label and I want the physical<br>
&gt; address of my label to pass to another function. How can I grab the<br=
>
&gt; physical address of the label?<br>
<br>
</div></div>AFAIK there is no way to do this in standard C.<br>
<br>
xen-devel isn&#39;t really the best place to be asking C programming<br>
questions. I suggest you either speak to your advisor/mentor or seek out<br=
>
one of the C forums on the Internet.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br>

--0016e6d9a2d447e57404c1da5444--


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

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

--===============0409924017757288763==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 04:30:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 04: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 1ScUM4-0007y3-Sm; Thu, 07 Jun 2012 04:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1ScUM2-0007xy-Vh
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 04:29:51 +0000
Received: from [85.158.143.99:8720] by server-3.bemta-4.messagelabs.com id
	FC/ED-29237-E3E20DF4; Thu, 07 Jun 2012 04:29:50 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339043387!30768795!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23212 invoked from network); 7 Jun 2012 04:29:48 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 04:29:48 -0000
Received: by wibhr14 with SMTP id hr14so131011wib.14
	for <xen-devel@lists.xen.org>; Wed, 06 Jun 2012 21:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=dzajZXVCApLavNUJ4uKbO3w4OhzQRYJrdfWBv0YFEpc=;
	b=GqYeqCv9sROLdxG2L79KHxjfQpUGG0RGOYYWr/5IpSRFD4JGIVKU1yW7xMHPZK0hwt
	03T2pkaw1Sb2wPcWcyeJrXB+jDkmLcM8pyUfKl2eapHe2/SNW9O2LroTPiAL37IDA5dE
	gN+UYnl0DHL7EDF8q+tDNeNnipDgWvHD5v6KHjv8DM0BaZcD2drDsSDjEGA7tuS8nqED
	NmFwPDyPNvmBrCQSlywtQ0lB3Yp4Ea2L19B2ZLJAdKGXItYlKKOqWr9urnoa/mQDnJWR
	vZ2YWiBfRadQtL1l4YzS2RW1xSLtt0vjrxPsv0tZ3nOdh863Uh7TpRnI0NttpZXn+39K
	dbRA==
MIME-Version: 1.0
Received: by 10.216.207.67 with SMTP id m45mr572691weo.175.1339043367871; Wed,
	06 Jun 2012 21:29:27 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Wed, 6 Jun 2012 21:29:27 -0700 (PDT)
In-Reply-To: <1338975815.32319.40.camel@zakaz.uk.xensource.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
Date: Wed, 6 Jun 2012 21:29:27 -0700
Message-ID: <CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0409924017757288763=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0409924017757288763==
Content-Type: multipart/alternative; boundary=0016e6d9a2d447e57404c1da5444

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

Thanks but I think if I find the base physical address of xen image I can
convert virtual address to physical address
I'm working in xen4 and my platform is: Processor AMD 64 and Centos 6 i386
with 8G of RAM
Can anyone tell me The physical address that xen image load in it? This
physical address depends on platform?

Thanks a lot


On Wed, Jun 6, 2012 at 2:43 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-06-05 at 07:07 +0100, Zeinab Alebouyeh wrote:
> > Hi everyone,
> > I'm working on a research project. I add a hypercall to xen. It works
> > properly.
> > In my Hypercall function I have a label and I want the physical
> > address of my label to pass to another function. How can I grab the
> > physical address of the label?
>
> AFAIK there is no way to do this in standard C.
>
> xen-devel isn't really the best place to be asking C programming
> questions. I suggest you either speak to your advisor/mentor or seek out
> one of the C forums on the Internet.
>
> Ian.
>
>

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

Thanks but I think if I find the base physical address of xen image I can c=
onvert virtual address to physical address<br>I&#39;m working in xen4 and m=
y platform is: Processor AMD 64 and Centos 6 i386 with 8G of RAM<br>Can any=
one tell me The physical address that xen image load in it? This physical a=
ddress depends on platform?<br>
<br>Thanks a lot<br><br><br><div class=3D"gmail_quote">On Wed, Jun 6, 2012 =
at 2:43 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbe=
ll@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On T=
ue, 2012-06-05 at 07:07 +0100, Zeinab Alebouyeh wrote:<br>
&gt; Hi everyone,<br>
&gt; I&#39;m working on a research project. I add a hypercall to xen. It wo=
rks<br>
&gt; properly.<br>
&gt; In my Hypercall function I have a label and I want the physical<br>
&gt; address of my label to pass to another function. How can I grab the<br=
>
&gt; physical address of the label?<br>
<br>
</div></div>AFAIK there is no way to do this in standard C.<br>
<br>
xen-devel isn&#39;t really the best place to be asking C programming<br>
questions. I suggest you either speak to your advisor/mentor or seek out<br=
>
one of the C forums on the Internet.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br>

--0016e6d9a2d447e57404c1da5444--


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

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

--===============0409924017757288763==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 06:08:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06:08: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 1ScVtH-0000Q1-Ae; Thu, 07 Jun 2012 06:08:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScVtF-0000Pw-PN
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 06:08:14 +0000
Received: from [85.158.139.83:3431] by server-6.bemta-5.messagelabs.com id
	98/9E-18700-C4540DF4; Thu, 07 Jun 2012 06:08:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339049292!32276722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21292 invoked from network); 7 Jun 2012 06:08:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:08:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:08:11 +0100
Message-ID: <1339049291.6557.11.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 7 Jun 2012 07:08:11 +0100
In-Reply-To: <CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	<CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 04:19 +0100, ZhouPeng wrote:
> On Wed, Jun 6, 2012 at 9:05 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
> >> changeset:   25454:1804a873a64d
> >> tag:         tip
> >> user:        Zhou Peng <ailvpeng25@gmail.com>
> >> date:        Tue Jun 05 17:56:46 2012 +0800
> >> files:       tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
> >> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
> >> description:
> >> tools:libxl: Add qxl vga interface support.
> >>
> >> Usage:
> >>  qxl=1
> >>  qxlvram=64
> >>  qxlram=64
> >>
> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
> >
> > Thanks.
> >
> > As previously mentioned this is  4.3 material. Please can you resubmit
> > once the 4.3 dev cycle opens.
> ok, thanks.
> >
> >> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
> >> --- a/tools/libxl/libxl_create.c      Tue Jun 05 17:39:37 2012 +0800
> >> +++ b/tools/libxl/libxl_create.c      Tue Jun 05 17:56:46 2012 +0800
> >> @@ -23,6 +23,32 @@
> >>  #include <xc_dom.h>
> >>  #include <xenguest.h>
> >>
> >> +/*
> >> + * For qxl vga interface, the total video mem is determined by
> >> + * RAM bar and VRAM bar. But it is not simply linearly determined,
> >> + * get_qxl_ram_size below gives the details.
> >
> > From this statement I expected get_qxl_ram_size to have a nice comment
> > explaining what is going on, but it doesn't have this.
> >
> > Can you please explain somewhere how this value is determined (I can see
> > it is not simple ;-)). Perhaps a link to some QXL/qemu document
> > discussing these parameters would be helpful too?
> 
> Sorry, there is not a piece of docs on ram bar and vram bar, and how
> the total size
> of qxl video memory is calculated from ram bar and vram bar parameters.
> 
> But from my digging into qxl's source code and debugging, it works this way.
> 
> I asked similar question in spice-list and get response from:
> http://comments.gmane.org/gmane.comp.emulators.spice.devel/9501
> 
> Any way, I will rich the document if get more info.

OK, thanks.

> >> +
> >> +    return (vram + ram + 1023) / 1024;
> >> +}
> >> +
> >>  void libxl_domain_config_init(libxl_domain_config *d_config)
> >>  {
> >>      memset(d_config, 0, sizeof(*d_config));
> >> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
> >>
> >>          if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
> >>              b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> >> +        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> >> +            && b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> >> +            if (b_info->u.hvm.vga.vramkb == LIBXL_MEMKB_DEFAULT)
> >> +                b_info->u.hvm.vga.vramkb = 64 * 1024;
> >> +            if (b_info->u.hvm.vga.ramkb == LIBXL_MEMKB_DEFAULT)
> >> +                b_info->u.hvm.vga.ramkb = 64 * 1024;
> >> +            uint32_t qxl_ram = get_qxl_ram_size(b_info->u.hvm.vga.vramkb,
> >> +                                                b_info->u.hvm.vga.ramkb);
> >> +            /*
> >> +             * video_memkb is the real size of video memory to assign.
> >> +             * If video_memkb can't meet the need of qxl, adjust it
> >> +             * accordingly.
> >> +             */
> >> +            if ((b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> >> +                || (b_info->video_memkb < qxl_ram)) {
> >> +                b_info->video_memkb = qxl_ram;
> >
> > If video_memkb is != LIBXL_MEMKB_DEFAULT and it is not sufficiently
> > large then I think the correct thing to do is to error out and return
> > ERROR_INVAL.
> 
> Not agreed.
> This will let user must to set a proper value to meet qxl, but from
> discussing above, it's difficult for user to give this decision.
> qxlram and qxlvram parameters are enough  for user to set qxl's video
> ram (libvirt also use these two parameters).

If the user has asked for a specific amount of video RAM which is not
sufficient then the correct answer is to log an error (including the
required minimum) and exit.

You are correct that it is hard to figure out what "enough" RAM is. I
expect that for that reason almost all users won't pass any of these
arguments and will just accept the default, which will work just fine.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:08:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06:08: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 1ScVtH-0000Q1-Ae; Thu, 07 Jun 2012 06:08:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScVtF-0000Pw-PN
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 06:08:14 +0000
Received: from [85.158.139.83:3431] by server-6.bemta-5.messagelabs.com id
	98/9E-18700-C4540DF4; Thu, 07 Jun 2012 06:08:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339049292!32276722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21292 invoked from network); 7 Jun 2012 06:08:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:08:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:08:11 +0100
Message-ID: <1339049291.6557.11.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 7 Jun 2012 07:08:11 +0100
In-Reply-To: <CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	<CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 04:19 +0100, ZhouPeng wrote:
> On Wed, Jun 6, 2012 at 9:05 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
> >> changeset:   25454:1804a873a64d
> >> tag:         tip
> >> user:        Zhou Peng <ailvpeng25@gmail.com>
> >> date:        Tue Jun 05 17:56:46 2012 +0800
> >> files:       tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
> >> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
> >> description:
> >> tools:libxl: Add qxl vga interface support.
> >>
> >> Usage:
> >>  qxl=1
> >>  qxlvram=64
> >>  qxlram=64
> >>
> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
> >
> > Thanks.
> >
> > As previously mentioned this is  4.3 material. Please can you resubmit
> > once the 4.3 dev cycle opens.
> ok, thanks.
> >
> >> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
> >> --- a/tools/libxl/libxl_create.c      Tue Jun 05 17:39:37 2012 +0800
> >> +++ b/tools/libxl/libxl_create.c      Tue Jun 05 17:56:46 2012 +0800
> >> @@ -23,6 +23,32 @@
> >>  #include <xc_dom.h>
> >>  #include <xenguest.h>
> >>
> >> +/*
> >> + * For qxl vga interface, the total video mem is determined by
> >> + * RAM bar and VRAM bar. But it is not simply linearly determined,
> >> + * get_qxl_ram_size below gives the details.
> >
> > From this statement I expected get_qxl_ram_size to have a nice comment
> > explaining what is going on, but it doesn't have this.
> >
> > Can you please explain somewhere how this value is determined (I can see
> > it is not simple ;-)). Perhaps a link to some QXL/qemu document
> > discussing these parameters would be helpful too?
> 
> Sorry, there is not a piece of docs on ram bar and vram bar, and how
> the total size
> of qxl video memory is calculated from ram bar and vram bar parameters.
> 
> But from my digging into qxl's source code and debugging, it works this way.
> 
> I asked similar question in spice-list and get response from:
> http://comments.gmane.org/gmane.comp.emulators.spice.devel/9501
> 
> Any way, I will rich the document if get more info.

OK, thanks.

> >> +
> >> +    return (vram + ram + 1023) / 1024;
> >> +}
> >> +
> >>  void libxl_domain_config_init(libxl_domain_config *d_config)
> >>  {
> >>      memset(d_config, 0, sizeof(*d_config));
> >> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
> >>
> >>          if (b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_DEFAULT)
> >>              b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> >> +        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> >> +            && b_info->u.hvm.vga.type == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> >> +            if (b_info->u.hvm.vga.vramkb == LIBXL_MEMKB_DEFAULT)
> >> +                b_info->u.hvm.vga.vramkb = 64 * 1024;
> >> +            if (b_info->u.hvm.vga.ramkb == LIBXL_MEMKB_DEFAULT)
> >> +                b_info->u.hvm.vga.ramkb = 64 * 1024;
> >> +            uint32_t qxl_ram = get_qxl_ram_size(b_info->u.hvm.vga.vramkb,
> >> +                                                b_info->u.hvm.vga.ramkb);
> >> +            /*
> >> +             * video_memkb is the real size of video memory to assign.
> >> +             * If video_memkb can't meet the need of qxl, adjust it
> >> +             * accordingly.
> >> +             */
> >> +            if ((b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> >> +                || (b_info->video_memkb < qxl_ram)) {
> >> +                b_info->video_memkb = qxl_ram;
> >
> > If video_memkb is != LIBXL_MEMKB_DEFAULT and it is not sufficiently
> > large then I think the correct thing to do is to error out and return
> > ERROR_INVAL.
> 
> Not agreed.
> This will let user must to set a proper value to meet qxl, but from
> discussing above, it's difficult for user to give this decision.
> qxlram and qxlvram parameters are enough  for user to set qxl's video
> ram (libvirt also use these two parameters).

If the user has asked for a specific amount of video RAM which is not
sufficient then the correct answer is to log an error (including the
required minimum) and exit.

You are correct that it is hard to figure out what "enough" RAM is. I
expect that for that reason almost all users won't pass any of these
arguments and will just accept the default, which will work just fine.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScW8w-0000bp-2o; Thu, 07 Jun 2012 06:24: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 1ScW8u-0000bk-DI
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 06:24:24 +0000
Received: from [85.158.138.51:9624] by server-10.bemta-3.messagelabs.com id
	0E/96-06494-71940DF4; Thu, 07 Jun 2012 06:24:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339050262!31166905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25344 invoked from network); 7 Jun 2012 06:24:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:24:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:24:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:24:06 +0100
Message-ID: <1339050245.6557.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 7 Jun 2012 07:24:05 +0100
In-Reply-To: <CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
	<1338988073.32319.86.camel@zakaz.uk.xensource.com>
	<CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 04:22 +0100, ZhouPeng wrote:
> On Wed, Jun 6, 2012 at 9:07 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
> >
> > You can/should include this with the patch which adds the functionality,
> > no need to separate it out.
> Ok.
> >
> >>
> >> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
> >> --- a/docs/man/xl.cfg.pod.5   Tue Jun 05 17:56:46 2012 +0800
> >> +++ b/docs/man/xl.cfg.pod.5   Tue Jun 05 18:58:12 2012 +0800
> >> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
> >>
> >>  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). The default is 8MB which is sufficient for
> >> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
> >> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
> >> +available. This option is available when using the B<stdvga> and
> >> +B<qxl> options (see below).
> >> +For B<stdvga> option, the default is 8MB which is sufficient for
> >> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> options,
> >> +the amount of video ram is fixed at 4MB which is sufficient for 1024x768
> >>  at 32 bpp.
> >> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
> >> +option below).
> >>
> >>  =item B<stdvga=BOOLEAN>
> >>
> >> @@ -711,6 +714,27 @@ emulated graphics device. The default is
> >>  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.
> >> +
> >> +=item B<qxl=BOOLEAN>
> >> +
> >> +Select a QXL VGA card as the emulated graphics device. This enables
> >> +the other QXL-related settings.
> >> +In general, QXL should work with the Spice remote display protocol for
> >> +acceleration, but QXL driver is necessary in guest. QXL can also work
> >> +with the VNC protocol like a standard VGA without acceleration.
> >> +
> >> +=item B<qxlram=MBYTES>
> >> +
> >> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
> >> +The total size of QXL video memory is determined by B<qxlram> (RAM bar)
> >> +and B<qxlvram> (VRAM bar), the size of each is settable.
> >> +B<videoram> can set the amount of RAM which emulated video card
> >> +will contain, but if it can't meet the need of QXL, it will be
> >> +adjusted accordingly.
> >> +
> >> +=item B<qxlvram=MBYTES>
> >> +
> >> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.
> >
> > It's not clear to me having read this what the distinction between RAM
> > and VRAM is in the context of QXL. When and why would I want to set
> > either?
> Both of them are necessary to set qxl video ram.
> They are necessary paremeters of qxl.

But they aren't necessary at the xl layer, right? I can just omit them
and a correct value will be chosen for me?


> 
> Any way, I will rich the document if get more info.
> 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 Jun 07 06:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScW8w-0000bp-2o; Thu, 07 Jun 2012 06:24: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 1ScW8u-0000bk-DI
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 06:24:24 +0000
Received: from [85.158.138.51:9624] by server-10.bemta-3.messagelabs.com id
	0E/96-06494-71940DF4; Thu, 07 Jun 2012 06:24:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339050262!31166905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25344 invoked from network); 7 Jun 2012 06:24:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:24:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:24:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:24:06 +0100
Message-ID: <1339050245.6557.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 7 Jun 2012 07:24:05 +0100
In-Reply-To: <CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
	<1338988073.32319.86.camel@zakaz.uk.xensource.com>
	<CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 04:22 +0100, ZhouPeng wrote:
> On Wed, Jun 6, 2012 at 9:07 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
> >
> > You can/should include this with the patch which adds the functionality,
> > no need to separate it out.
> Ok.
> >
> >>
> >> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
> >> --- a/docs/man/xl.cfg.pod.5   Tue Jun 05 17:56:46 2012 +0800
> >> +++ b/docs/man/xl.cfg.pod.5   Tue Jun 05 18:58:12 2012 +0800
> >> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
> >>
> >>  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). The default is 8MB which is sufficient for
> >> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
> >> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
> >> +available. This option is available when using the B<stdvga> and
> >> +B<qxl> options (see below).
> >> +For B<stdvga> option, the default is 8MB which is sufficient for
> >> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> options,
> >> +the amount of video ram is fixed at 4MB which is sufficient for 1024x768
> >>  at 32 bpp.
> >> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
> >> +option below).
> >>
> >>  =item B<stdvga=BOOLEAN>
> >>
> >> @@ -711,6 +714,27 @@ emulated graphics device. The default is
> >>  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.
> >> +
> >> +=item B<qxl=BOOLEAN>
> >> +
> >> +Select a QXL VGA card as the emulated graphics device. This enables
> >> +the other QXL-related settings.
> >> +In general, QXL should work with the Spice remote display protocol for
> >> +acceleration, but QXL driver is necessary in guest. QXL can also work
> >> +with the VNC protocol like a standard VGA without acceleration.
> >> +
> >> +=item B<qxlram=MBYTES>
> >> +
> >> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
> >> +The total size of QXL video memory is determined by B<qxlram> (RAM bar)
> >> +and B<qxlvram> (VRAM bar), the size of each is settable.
> >> +B<videoram> can set the amount of RAM which emulated video card
> >> +will contain, but if it can't meet the need of QXL, it will be
> >> +adjusted accordingly.
> >> +
> >> +=item B<qxlvram=MBYTES>
> >> +
> >> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.
> >
> > It's not clear to me having read this what the distinction between RAM
> > and VRAM is in the context of QXL. When and why would I want to set
> > either?
> Both of them are necessary to set qxl video ram.
> They are necessary paremeters of qxl.

But they aren't necessary at the xl layer, right? I can just omit them
and a correct value will be chosen for me?


> 
> Any way, I will rich the document if get more info.
> 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 Jun 07 06:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScWBt-0000h3-M7; Thu, 07 Jun 2012 06:27:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScWBs-0000gu-9v
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 06:27:28 +0000
Received: from [85.158.143.35:2059] by server-2.bemta-4.messagelabs.com id
	A8/1B-17938-FC940DF4; Thu, 07 Jun 2012 06:27:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339050446!15161278!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11090 invoked from network); 7 Jun 2012 06:27:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:27:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:27:26 +0100
Message-ID: <1339050446.6557.19.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 7 Jun 2012 07:27:26 +0100
In-Reply-To: <20120606141751.37305f89@mantra.us.oracle.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606141751.37305f89@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: James Paton <paton@cs.wisc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 22:17 +0100, Mukesh Rathor wrote:
> I wrote up a debugger for xen, also (mis)named kdb. It halts the 
> system, lets you poke memory, data structs, set breakpoints, etc.
> To use it, you must have prior experience of a kernel debugger. I
> am attaching patch build for changeset 25287 in unstable tree, if you
> wanna try it. Start with kdb/README.

I think this is for the hypervisor itself, right?

James was asking about debugging the dom0 kernel. I also considered
mentioning gdbsx but I think that can only work with domU?

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScWBt-0000h3-M7; Thu, 07 Jun 2012 06:27:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScWBs-0000gu-9v
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 06:27:28 +0000
Received: from [85.158.143.35:2059] by server-2.bemta-4.messagelabs.com id
	A8/1B-17938-FC940DF4; Thu, 07 Jun 2012 06:27:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339050446!15161278!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11090 invoked from network); 7 Jun 2012 06:27:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:27:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:27:26 +0100
Message-ID: <1339050446.6557.19.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 7 Jun 2012 07:27:26 +0100
In-Reply-To: <20120606141751.37305f89@mantra.us.oracle.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606141751.37305f89@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: James Paton <paton@cs.wisc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 22:17 +0100, Mukesh Rathor wrote:
> I wrote up a debugger for xen, also (mis)named kdb. It halts the 
> system, lets you poke memory, data structs, set breakpoints, etc.
> To use it, you must have prior experience of a kernel debugger. I
> am attaching patch build for changeset 25287 in unstable tree, if you
> wanna try it. Start with kdb/README.

I think this is for the hypervisor itself, right?

James was asking about debugging the dom0 kernel. I also considered
mentioning gdbsx but I think that can only work with domU?

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:31:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScWFg-0000rD-AZ; Thu, 07 Jun 2012 06:31: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 1ScWFe-0000r3-Hq
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 06:31:22 +0000
Received: from [85.158.138.51:14645] by server-9.bemta-3.messagelabs.com id
	04/60-15054-9BA40DF4; Thu, 07 Jun 2012 06:31:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339050681!22284809!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14989 invoked from network); 7 Jun 2012 06:31:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:31:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:31:20 +0100
Message-ID: <1339050679.6557.21.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Thu, 7 Jun 2012 07:31:19 +0100
In-Reply-To: <CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, it makes it hard to follow the flow of the
conversation.

You might also find it useful to read
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions

On Thu, 2012-06-07 at 05:29 +0100, Zeinab Alebouyeh wrote:
> Thanks but I think if I find the base physical address of xen image I
> can convert virtual address to physical address

I'm not sure what this has to do with taking the address of a label,
like you originally asked, but...

There are macros to convert a xenheap virtual address into a physical
one and back, see __pa and __va. (Note that these only work for xenheap
addresses).

> I'm working in xen4 and my platform is: Processor AMD 64 and Centos 6
> i386 with 8G of RAM

Are you using a 32-bit or 64-bit hypervisor? 

I strongly recommend basing all future x86 work on 64-bit Xen, even if
you are using a 32 bit dom0.

> Can anyone tell me The physical address that xen image load in it?
> This physical address depends on platform?

Yes, Xen will relocate itself at start of day. You should be able to
figure out the details from the implementation of __pa and __va.

It might be helpful if you described what you are actually trying to
achieve here -- what is your end goal?

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:31:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScWFg-0000rD-AZ; Thu, 07 Jun 2012 06:31: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 1ScWFe-0000r3-Hq
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 06:31:22 +0000
Received: from [85.158.138.51:14645] by server-9.bemta-3.messagelabs.com id
	04/60-15054-9BA40DF4; Thu, 07 Jun 2012 06:31:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339050681!22284809!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14989 invoked from network); 7 Jun 2012 06:31:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 06:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12872390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:31:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:31:20 +0100
Message-ID: <1339050679.6557.21.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Thu, 7 Jun 2012 07:31:19 +0100
In-Reply-To: <CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, it makes it hard to follow the flow of the
conversation.

You might also find it useful to read
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions

On Thu, 2012-06-07 at 05:29 +0100, Zeinab Alebouyeh wrote:
> Thanks but I think if I find the base physical address of xen image I
> can convert virtual address to physical address

I'm not sure what this has to do with taking the address of a label,
like you originally asked, but...

There are macros to convert a xenheap virtual address into a physical
one and back, see __pa and __va. (Note that these only work for xenheap
addresses).

> I'm working in xen4 and my platform is: Processor AMD 64 and Centos 6
> i386 with 8G of RAM

Are you using a 32-bit or 64-bit hypervisor? 

I strongly recommend basing all future x86 work on 64-bit Xen, even if
you are using a 32 bit dom0.

> Can anyone tell me The physical address that xen image load in it?
> This physical address depends on platform?

Yes, Xen will relocate itself at start of day. You should be able to
figure out the details from the implementation of __pa and __va.

It might be helpful if you described what you are actually trying to
achieve here -- what is your end goal?

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:43:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScWR0-00017S-IJ; Thu, 07 Jun 2012 06:43:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dokter@icg.tugraz.at>) id 1ScWQz-00017N-8i
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 06:43:05 +0000
Received: from [193.109.254.147:62386] by server-5.bemta-14.messagelabs.com id
	68/D7-31398-87D40DF4; Thu, 07 Jun 2012 06:43:04 +0000
X-Env-Sender: dokter@icg.tugraz.at
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339051383!8473613!1
X-Originating-IP: [129.27.2.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20027 invoked from network); 7 Jun 2012 06:43:04 -0000
Received: from mailrelay.tu-graz.ac.at (HELO mailrelay.tugraz.at)
	(129.27.2.202)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 06:43:04 -0000
Received: from [10.0.24.110] ([84.115.181.40]) (authenticated bits=0)
	by mailrelay1.tugraz.at (8.14.4/8.14.4) with ESMTP id q576gvwG003143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Thu, 7 Jun 2012 08:43:01 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.3 mailrelay1.tugraz.at q576gvwG003143
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at;
	s=mailrelay; t=1339051382; i=@icg.tugraz.at;
	bh=CyI7Fl3PWqg/Y9V4f7G1p3GKzrlBspGZ35vR8GlnHXs=;
	h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=o/+Ss0Nf4UHR8EolckqIBmHvzDQuXYU1ckRmtelMTCTM/HpR/iBfIEKE31pfm9E+5
	94RBOfGFqH6I21s7BqACvgh2mhJcQtJT+2cyHxtazP66MbTz1tSBrIMqDeD/27fJab
	ZzZJhoWQ8KBKMo7+mujNQH9QpAyMpPVkVdoOIIq4=
Message-ID: <4FD04D70.1030805@icg.tugraz.at>
Date: Thu, 07 Jun 2012 08:42:56 +0200
From: Mark Dokter <dokter@icg.tugraz.at>
Organization: Institute for Computer Graphics and Vision
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
In-Reply-To: <CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
X-Enigmail-Version: 1.5pre
X-TUG-Backscatter-control: rFbaswCq5sZ4TcOS98kMZA
X-Spam-Scanner: SpamAssassin 3.003000 
X-Spam-Score-relay: 1.3
X-Scanned-By: MIMEDefang 2.70 on 129.27.10.18
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: dokter@icg.tugraz.at
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 08:15 PM, elahe shekuhi wrote:
> Hi,
> 

Hi!

Maybe you could try using xl instead of xm. They behave differently
concerning sources of errors imho.

hth, Mark

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:43:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06: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 1ScWR0-00017S-IJ; Thu, 07 Jun 2012 06:43:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dokter@icg.tugraz.at>) id 1ScWQz-00017N-8i
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 06:43:05 +0000
Received: from [193.109.254.147:62386] by server-5.bemta-14.messagelabs.com id
	68/D7-31398-87D40DF4; Thu, 07 Jun 2012 06:43:04 +0000
X-Env-Sender: dokter@icg.tugraz.at
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339051383!8473613!1
X-Originating-IP: [129.27.2.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20027 invoked from network); 7 Jun 2012 06:43:04 -0000
Received: from mailrelay.tu-graz.ac.at (HELO mailrelay.tugraz.at)
	(129.27.2.202)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 06:43:04 -0000
Received: from [10.0.24.110] ([84.115.181.40]) (authenticated bits=0)
	by mailrelay1.tugraz.at (8.14.4/8.14.4) with ESMTP id q576gvwG003143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Thu, 7 Jun 2012 08:43:01 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.3 mailrelay1.tugraz.at q576gvwG003143
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at;
	s=mailrelay; t=1339051382; i=@icg.tugraz.at;
	bh=CyI7Fl3PWqg/Y9V4f7G1p3GKzrlBspGZ35vR8GlnHXs=;
	h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=o/+Ss0Nf4UHR8EolckqIBmHvzDQuXYU1ckRmtelMTCTM/HpR/iBfIEKE31pfm9E+5
	94RBOfGFqH6I21s7BqACvgh2mhJcQtJT+2cyHxtazP66MbTz1tSBrIMqDeD/27fJab
	ZzZJhoWQ8KBKMo7+mujNQH9QpAyMpPVkVdoOIIq4=
Message-ID: <4FD04D70.1030805@icg.tugraz.at>
Date: Thu, 07 Jun 2012 08:42:56 +0200
From: Mark Dokter <dokter@icg.tugraz.at>
Organization: Institute for Computer Graphics and Vision
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
In-Reply-To: <CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
X-Enigmail-Version: 1.5pre
X-TUG-Backscatter-control: rFbaswCq5sZ4TcOS98kMZA
X-Spam-Scanner: SpamAssassin 3.003000 
X-Spam-Score-relay: 1.3
X-Scanned-By: MIMEDefang 2.70 on 129.27.10.18
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: dokter@icg.tugraz.at
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 08:15 PM, elahe shekuhi wrote:
> Hi,
> 

Hi!

Maybe you could try using xl instead of xm. They behave differently
concerning sources of errors imho.

hth, Mark

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScWTc-0001Ck-4R; Thu, 07 Jun 2012 06:45:48 +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 1ScWTa-0001Cc-IN
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 06:45:46 +0000
Received: from [85.158.139.83:60902] by server-10.bemta-5.messagelabs.com id
	48/52-23803-91E40DF4; Thu, 07 Jun 2012 06:45:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339051542!25154401!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ4NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23073 invoked from network); 7 Jun 2012 06:45:43 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	7 Jun 2012 06:45:43 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 06 Jun 2012 23:45:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108885185"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 06 Jun 2012 23:45:42 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 6 Jun 2012 23:45:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Thu, 7 Jun 2012 14:45:39 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
Thread-Index: AQHNRCe5DOce9SoxVEmsF2YnWPn8AJbuaPkA
Date: Thu, 7 Jun 2012 06:45:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120606205523.GA10891@phenom.dumpdata.com>
In-Reply-To: <20120606205523.GA10891@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
>>> From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00
>>> 2001 
>> From: root <root@ljsromley.bj.intel.com>
>> Date: Fri, 1 Jun 2012 03:12:51 +0800
>> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
>> 
>> When MCA error occurs, it would be handled by Xen hypervisor first,
>> and then the error information would be sent to initial domain for
>> logging. 
>> 
>> This patch gets error information from Xen hypervisor and convert
>> Xen format error into Linux format mcelog. This logic is basically
>> self-contained, not touching other kernel components.
>> 
>> By using tools like mcelog tool users could read specific error
>> information, like what they did under native Linux.
>> 
>> To test follow directions outlined in
>> Documentation/acpi/apei/einj.txt 
> 
> [   53.264610] switch: port 1(eth0) entered forwarding state
> [ 1058.051938] BUG: sleeping function called from invalid context at
> /home/konrad/linux/include/linux/kernel.h:199 [ 1058.052066]
> in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog [
> 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O
> 3.5.0-rc1upstream-00041-ga16e594-dirty #2 [ 1058.052235] Call Trace:
> [ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100 [
> 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140 [
> 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190 [ 1058.052461]
> [<ffffffff81148f4c>] sys_read+0x4c/0x90 [ 1058.052515] 
> [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1 
> 
> ?

I will debug it. Would you tell me the steps to reproduce the bug, and your .config file?
(Some issue w/ my email box this morning, just notice this)

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 06:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 06:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScWTc-0001Ck-4R; Thu, 07 Jun 2012 06:45:48 +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 1ScWTa-0001Cc-IN
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 06:45:46 +0000
Received: from [85.158.139.83:60902] by server-10.bemta-5.messagelabs.com id
	48/52-23803-91E40DF4; Thu, 07 Jun 2012 06:45:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339051542!25154401!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjQ4NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23073 invoked from network); 7 Jun 2012 06:45:43 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	7 Jun 2012 06:45:43 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 06 Jun 2012 23:45:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108885185"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 06 Jun 2012 23:45:42 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 6 Jun 2012 23:45:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Thu, 7 Jun 2012 14:45:39 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
Thread-Index: AQHNRCe5DOce9SoxVEmsF2YnWPn8AJbuaPkA
Date: Thu, 7 Jun 2012 06:45:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120606205523.GA10891@phenom.dumpdata.com>
In-Reply-To: <20120606205523.GA10891@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
>>> From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00
>>> 2001 
>> From: root <root@ljsromley.bj.intel.com>
>> Date: Fri, 1 Jun 2012 03:12:51 +0800
>> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
>> 
>> When MCA error occurs, it would be handled by Xen hypervisor first,
>> and then the error information would be sent to initial domain for
>> logging. 
>> 
>> This patch gets error information from Xen hypervisor and convert
>> Xen format error into Linux format mcelog. This logic is basically
>> self-contained, not touching other kernel components.
>> 
>> By using tools like mcelog tool users could read specific error
>> information, like what they did under native Linux.
>> 
>> To test follow directions outlined in
>> Documentation/acpi/apei/einj.txt 
> 
> [   53.264610] switch: port 1(eth0) entered forwarding state
> [ 1058.051938] BUG: sleeping function called from invalid context at
> /home/konrad/linux/include/linux/kernel.h:199 [ 1058.052066]
> in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog [
> 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O
> 3.5.0-rc1upstream-00041-ga16e594-dirty #2 [ 1058.052235] Call Trace:
> [ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100 [
> 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140 [
> 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190 [ 1058.052461]
> [<ffffffff81148f4c>] sys_read+0x4c/0x90 [ 1058.052515] 
> [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1 
> 
> ?

I will debug it. Would you tell me the steps to reproduce the bug, and your .config file?
(Some issue w/ my email box this morning, just notice this)

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:18:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07: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 1ScWzA-0001oJ-4p; Thu, 07 Jun 2012 07:18:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScWz7-0001oA-UT
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 07:18:22 +0000
Received: from [193.109.254.147:21532] by server-5.bemta-14.messagelabs.com id
	04/80-31398-DB550DF4; Thu, 07 Jun 2012 07:18:21 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339053500!6084816!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27531 invoked from network); 7 Jun 2012 07:18:20 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-27.messagelabs.com with SMTP;
	7 Jun 2012 07:18:20 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78710180; Thu, 07 Jun 2012 09:18:19 +0200
Message-ID: <1339053493.8123.6.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 07 Jun 2012 09:18:13 +0200
In-Reply-To: <1338994758.32319.130.camel@zakaz.uk.xensource.com>
References: <78af912f1823442009ea.1338990124@Solace>
	<1338994758.32319.130.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0968006088060031120=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0968006088060031120==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IuHoQ8kt1/Pq7Ghz2i6X"


--=-IuHoQ8kt1/Pq7Ghz2i6X
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 15:59 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> > To avoid recent gcc complaining about:
> > libxl.c: In function 'libxl_primary_console_exec':
> > libxl.c:1233:9: error: case value '4294967295' not in enumerated type '=
libxl_domain_type' [-Werror=3Dswitch]
> >=20
> > Also:
> >  - have all the call sites of libxl__domain_type() return with error in
> >    case the function returns LIBXL_DOMAIN_TYPE_INVALID;
> >  - adjust all other code segments where -Wswitch makes would claim that
> >    LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort=
();"
> >    clause.
> >=20
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>=20
> Committed with the two changes I mentioned. Please check I haven't made
> a mess of things...
>=20
I looked at it and it seems fine. Thanks for doing this,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-IuHoQ8kt1/Pq7Ghz2i6X
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/QVbUACgkQk4XaBE3IOsSFXACdEvG7OXAD2WjYzKn9XoxhZUqr
P9MAmwQHRzB6WVFuZF0uvrs06By45ClG
=PdAK
-----END PGP SIGNATURE-----

--=-IuHoQ8kt1/Pq7Ghz2i6X--



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

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

--===============0968006088060031120==--



From xen-devel-bounces@lists.xen.org Thu Jun 07 07:18:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07: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 1ScWzA-0001oJ-4p; Thu, 07 Jun 2012 07:18:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ScWz7-0001oA-UT
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 07:18:22 +0000
Received: from [193.109.254.147:21532] by server-5.bemta-14.messagelabs.com id
	04/80-31398-DB550DF4; Thu, 07 Jun 2012 07:18:21 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339053500!6084816!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27531 invoked from network); 7 Jun 2012 07:18:20 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-27.messagelabs.com with SMTP;
	7 Jun 2012 07:18:20 -0000
Received: from [213.136.143.230] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78710180; Thu, 07 Jun 2012 09:18:19 +0200
Message-ID: <1339053493.8123.6.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 07 Jun 2012 09:18:13 +0200
In-Reply-To: <1338994758.32319.130.camel@zakaz.uk.xensource.com>
References: <78af912f1823442009ea.1338990124@Solace>
	<1338994758.32319.130.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] libxl: introduce
	LIBXL_DOMAIN_TYPE_INVALID
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0968006088060031120=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0968006088060031120==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IuHoQ8kt1/Pq7Ghz2i6X"


--=-IuHoQ8kt1/Pq7Ghz2i6X
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-06 at 15:59 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 14:42 +0100, Dario Faggioli wrote:
> > To avoid recent gcc complaining about:
> > libxl.c: In function 'libxl_primary_console_exec':
> > libxl.c:1233:9: error: case value '4294967295' not in enumerated type '=
libxl_domain_type' [-Werror=3Dswitch]
> >=20
> > Also:
> >  - have all the call sites of libxl__domain_type() return with error in
> >    case the function returns LIBXL_DOMAIN_TYPE_INVALID;
> >  - adjust all other code segments where -Wswitch makes would claim that
> >    LIBXL_DOMAIN_TYPE_INVALID is not handled by adding a "default: abort=
();"
> >    clause.
> >=20
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>=20
> Committed with the two changes I mentioned. Please check I haven't made
> a mess of things...
>=20
I looked at it and it seems fine. Thanks for doing this,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-IuHoQ8kt1/Pq7Ghz2i6X
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/QVbUACgkQk4XaBE3IOsSFXACdEvG7OXAD2WjYzKn9XoxhZUqr
P9MAmwQHRzB6WVFuZF0uvrs06By45ClG
=PdAK
-----END PGP SIGNATURE-----

--=-IuHoQ8kt1/Pq7Ghz2i6X--



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

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

--===============0968006088060031120==--



From xen-devel-bounces@lists.xen.org Thu Jun 07 07:21:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:21: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 1ScX2H-00025S-WB; Thu, 07 Jun 2012 07:21:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1ScX2G-00025I-Se
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:21:37 +0000
Received: from [85.158.143.35:25610] by server-2.bemta-4.messagelabs.com id
	FB/E4-17938-08650DF4; Thu, 07 Jun 2012 07:21:36 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339053695!14401620!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25891 invoked from network); 7 Jun 2012 07:21:35 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-15.tower-21.messagelabs.com with SMTP;
	7 Jun 2012 07:21:35 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 8C905C00428;
	Thu,  7 Jun 2012 09:21:34 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id kDXWcZ-rvw7o; Thu,  7 Jun 2012 09:21:34 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Thu,  7 Jun 2012 09:21:34 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 3FDD249C58B;
	Thu,  7 Jun 2012 08:21:34 +0100 (BST)
Date: Thu, 7 Jun 2012 09:21:59 +0200
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120607072159.GB9856@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FCFD2EE.8060508@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
 AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
> On 06/01/2012 07:52 AM, Borislav Petkov wrote:
> > From: Andre Przywara <andre.przywara@amd.com>
> > 
> > f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> > has disabled it") wrongfully added code which used the AMD-specific
> > {rd,wr}msr variants for no real reason.
> > 
> > This caused boot panics on xen which wasn't initializing the
> > {rd,wr}msr_safe_regs pv_ops members properly.
> > 
> > This, in turn, caused a heated discussion leading to us reviewing all
> > uses of the AMD-specific variants and removing them where unneeded
> > (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> > 
> > Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> > which should've been used in the first place anyway and avoided unneeded
> > excitation with xen.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@amd.com>
> > Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
> > Cc: stable@vger.kernel.org # 3.4+
> > Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> > [Boris: correct and expand commit message]
> > Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> 
> Why -stable?  I though we had agreed that we didn't have an active
> problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
> currently sits?

Yes, AFAICT, we need at least one fix for 3.4 where the original patch
f7f286a910221 broke xen.

So either this one or 1ab46fd319bc should be backported to stable, if
I'm not mistaken. If the second, I'll drop the stable tag from this one
and resend.

Konrad, what do you want wrt xen paravirt nullptr breakage for
3.4-stable?

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:21:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:21: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 1ScX2H-00025S-WB; Thu, 07 Jun 2012 07:21:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@amd64.org>) id 1ScX2G-00025I-Se
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:21:37 +0000
Received: from [85.158.143.35:25610] by server-2.bemta-4.messagelabs.com id
	FB/E4-17938-08650DF4; Thu, 07 Jun 2012 07:21:36 +0000
X-Env-Sender: bp@amd64.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339053695!14401620!1
X-Originating-IP: [217.160.130.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25891 invoked from network); 7 Jun 2012 07:21:35 -0000
Received: from s15943758.onlinehome-server.info (HELO mail.x86-64.org)
	(217.160.130.188) by server-15.tower-21.messagelabs.com with SMTP;
	7 Jun 2012 07:21:35 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.x86-64.org (Postfix) with ESMTP id 8C905C00428;
	Thu,  7 Jun 2012 09:21:34 +0200 (CEST)
X-Virus-Scanned: Nedap ESD1 at s15943758.onlinehome-server.info
Received: from mail.x86-64.org ([127.0.0.1])
	by localhost (s15943758.onlinehome-server.info [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id kDXWcZ-rvw7o; Thu,  7 Jun 2012 09:21:34 +0200 (CEST)
Received: from gwo.osrc.amd.com (gwo.osrc.amd.com [10.97.0.252])
	by mail.x86-64.org (Postfix) with ESMTP;
	Thu,  7 Jun 2012 09:21:34 +0200 (CEST)
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])
	by gwo.osrc.amd.com (Postfix) with ESMTP id 3FDD249C58B;
	Thu,  7 Jun 2012 08:21:34 +0100 (BST)
Date: Thu, 7 Jun 2012 09:21:59 +0200
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120607072159.GB9856@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FCFD2EE.8060508@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
 AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
> On 06/01/2012 07:52 AM, Borislav Petkov wrote:
> > From: Andre Przywara <andre.przywara@amd.com>
> > 
> > f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> > has disabled it") wrongfully added code which used the AMD-specific
> > {rd,wr}msr variants for no real reason.
> > 
> > This caused boot panics on xen which wasn't initializing the
> > {rd,wr}msr_safe_regs pv_ops members properly.
> > 
> > This, in turn, caused a heated discussion leading to us reviewing all
> > uses of the AMD-specific variants and removing them where unneeded
> > (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> > 
> > Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> > which should've been used in the first place anyway and avoided unneeded
> > excitation with xen.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@amd.com>
> > Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
> > Cc: stable@vger.kernel.org # 3.4+
> > Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> > [Boris: correct and expand commit message]
> > Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> 
> Why -stable?  I though we had agreed that we didn't have an active
> problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
> currently sits?

Yes, AFAICT, we need at least one fix for 3.4 where the original patch
f7f286a910221 broke xen.

So either this one or 1ab46fd319bc should be backported to stable, if
I'm not mistaken. If the second, I'll drop the stable tag from this one
and resend.

Konrad, what do you want wrt xen paravirt nullptr breakage for
3.4-stable?

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:34: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 1ScXE2-0002V4-DU; Thu, 07 Jun 2012 07:33:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1ScXE0-0002Uo-MV
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:33:44 +0000
Received: from [193.109.254.147:63690] by server-7.bemta-14.messagelabs.com id
	5A/77-29165-75950DF4; Thu, 07 Jun 2012 07:33:43 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339054421!6087608!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32405 invoked from network); 7 Jun 2012 07:33:42 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:33:42 -0000
Received: by yhkk6 with SMTP id k6so230444yhk.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 00:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=gj3QfhdGvIqJAMIOtV48NidCxnhG6NMab8XDJujGb4k=;
	b=P53s69jA1qPXv0Jz8QpO+GOsqyN7048uoWRiqxHwn3TMIZU5+hX22Wof8P2ijPcs6j
	yAkVMoDWeBLsjdvf3xchZmKvrrr1X86vzRtLZSw2adXJVkAJ/1T9sqztfhH44E6gU3mm
	cP/PRI9cbHCktndjPcdm+ZpJgVXYKZnCItNERutMvFUWkzjmNC0oX20uvWfbh+9WK7VH
	VPZ1X0ZbzGc9/2nmMMmI7XSXpJ411BXqTH6rWH5kQ5JRqFPQrkU8Krl0l4XiYdYLBHit
	/+7nEFgs3RkbizemVpXGdDCmfKxSlWOYnjd+aO3kTpTgs5ghxvFuAjeTIDr1HmwHm65B
	J/OQ==
Received: by 10.50.237.73 with SMTP id va9mr637532igc.3.1339054421059;
	Thu, 07 Jun 2012 00:33:41 -0700 (PDT)
Received: from burratino (cl-1372.chi-02.us.sixxs.net. [2001:4978:f:55b::2])
	by mx.google.com with ESMTPS id iw6sm2987522igc.15.2012.06.07.00.33.35
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 00:33:36 -0700 (PDT)
Date: Thu, 7 Jun 2012 02:33:33 -0500
From: Jonathan Nieder <jrnieder@gmail.com>
To: Sergio Gelato <Sergio.Gelato@astro.su.se>
Message-ID: <20120607073333.GF3210@burratino>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607064017.GA2112@hanuman.astro.su.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sergio Gelato wrote[1]:

>                          That 3.4.1-1~experimental.1 build
> (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux)
> is even less well-behaved under Xen: I'm getting a kernel OOPS at
> EIP: [<c1168e54>] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c
> The top of the trace message unfortunately scrolled off the console before I
> could see it, and the message doesn't have time to make it to syslog (either
> local or remote).
[...]
> Non-Xen boots proceed normally.

Yeah, apparently[2] that's caused by

	commit 26c191788f18
	Author: Andrea Arcangeli <aarcange@redhat.com>
	Date:   Tue May 29 15:06:49 2012 -0700

	    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition

which was also included in Debian kernel 3.2.19-1.

[1] http://bugs.debian.org/676360
[2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:34: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 1ScXE2-0002V4-DU; Thu, 07 Jun 2012 07:33:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1ScXE0-0002Uo-MV
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:33:44 +0000
Received: from [193.109.254.147:63690] by server-7.bemta-14.messagelabs.com id
	5A/77-29165-75950DF4; Thu, 07 Jun 2012 07:33:43 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339054421!6087608!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32405 invoked from network); 7 Jun 2012 07:33:42 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:33:42 -0000
Received: by yhkk6 with SMTP id k6so230444yhk.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 00:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=gj3QfhdGvIqJAMIOtV48NidCxnhG6NMab8XDJujGb4k=;
	b=P53s69jA1qPXv0Jz8QpO+GOsqyN7048uoWRiqxHwn3TMIZU5+hX22Wof8P2ijPcs6j
	yAkVMoDWeBLsjdvf3xchZmKvrrr1X86vzRtLZSw2adXJVkAJ/1T9sqztfhH44E6gU3mm
	cP/PRI9cbHCktndjPcdm+ZpJgVXYKZnCItNERutMvFUWkzjmNC0oX20uvWfbh+9WK7VH
	VPZ1X0ZbzGc9/2nmMMmI7XSXpJ411BXqTH6rWH5kQ5JRqFPQrkU8Krl0l4XiYdYLBHit
	/+7nEFgs3RkbizemVpXGdDCmfKxSlWOYnjd+aO3kTpTgs5ghxvFuAjeTIDr1HmwHm65B
	J/OQ==
Received: by 10.50.237.73 with SMTP id va9mr637532igc.3.1339054421059;
	Thu, 07 Jun 2012 00:33:41 -0700 (PDT)
Received: from burratino (cl-1372.chi-02.us.sixxs.net. [2001:4978:f:55b::2])
	by mx.google.com with ESMTPS id iw6sm2987522igc.15.2012.06.07.00.33.35
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 00:33:36 -0700 (PDT)
Date: Thu, 7 Jun 2012 02:33:33 -0500
From: Jonathan Nieder <jrnieder@gmail.com>
To: Sergio Gelato <Sergio.Gelato@astro.su.se>
Message-ID: <20120607073333.GF3210@burratino>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607064017.GA2112@hanuman.astro.su.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sergio Gelato wrote[1]:

>                          That 3.4.1-1~experimental.1 build
> (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux)
> is even less well-behaved under Xen: I'm getting a kernel OOPS at
> EIP: [<c1168e54>] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c
> The top of the trace message unfortunately scrolled off the console before I
> could see it, and the message doesn't have time to make it to syslog (either
> local or remote).
[...]
> Non-Xen boots proceed normally.

Yeah, apparently[2] that's caused by

	commit 26c191788f18
	Author: Andrea Arcangeli <aarcange@redhat.com>
	Date:   Tue May 29 15:06:49 2012 -0700

	    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition

which was also included in Debian kernel 3.2.19-1.

[1] http://bugs.debian.org/676360
[2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:50:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:50: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 1ScXTX-0002mN-5b; Thu, 07 Jun 2012 07:49:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ScXTV-0002mI-On
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:49:45 +0000
Received: from [85.158.143.99:52137] by server-2.bemta-4.messagelabs.com id
	3A/DC-17938-91D50DF4; Thu, 07 Jun 2012 07:49:45 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339055382!26363572!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17856 invoked from network); 7 Jun 2012 07:49:43 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Jun 2012 07:49:43 -0000
Received: from mail150-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 07:48:55 +0000
Received: from mail150-tx2 (localhost [127.0.0.1])	by
	mail150-tx2-R.bigfish.com (Postfix) with ESMTP id CC7DF4C0227;
	Thu,  7 Jun 2012 07:48:54 +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: -16
X-BigFish: VPS-16(zzbb2dI9371I542M1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail150-tx2 (localhost.localdomain [127.0.0.1]) by mail150-tx2
	(MessageSwitch) id 133905533396885_26362;
	Thu,  7 Jun 2012 07:48:53 +0000 (UTC)
Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.247])	by
	mail150-tx2.bigfish.com (Postfix) with ESMTP id 08A142A0049;
	Thu,  7 Jun 2012 07:48:53 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 07:48:51 +0000
X-WSS-ID: 0M58LQQ-02-2G0-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 22869C8196;	Thu,  7 Jun 2012 02:49:37 -0500 (CDT)
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;
	Thu, 7 Jun 2012 02:49:53 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 7 Jun 2012 02:49:38 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	03:49:35 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id AE64449C58B; Thu,  7 Jun 2012
	08:49:34 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id 81C9C5940FF; Thu,  7 Jun 2012
	09:49:34 +0200 (CEST)
Message-ID: <4FD05CED.60905@amd.com>
Date: Thu, 7 Jun 2012 09:49:01 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com>
In-Reply-To: <20120607072159.GB9856@aftab.osrc.amd.com>
X-OriginatorOrg: amd.com
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/07/2012 09:21 AM, Borislav Petkov wrote:
> On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
>> On 06/01/2012 07:52 AM, Borislav Petkov wrote:
>>> From: Andre Przywara<andre.przywara@amd.com>
>>>
>>> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
>>> has disabled it") wrongfully added code which used the AMD-specific
>>> {rd,wr}msr variants for no real reason.
>>>
>>> This caused boot panics on xen which wasn't initializing the
>>> {rd,wr}msr_safe_regs pv_ops members properly.
>>>
>>> This, in turn, caused a heated discussion leading to us reviewing all
>>> uses of the AMD-specific variants and removing them where unneeded
>>> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
>>>
>>> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
>>> which should've been used in the first place anyway and avoided unneeded
>>> excitation with xen.
>>>
>>> Signed-off-by: Andre Przywara<andre.przywara@amd.com>
>>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>>> Cc: stable@vger.kernel.org # 3.4+
>>> Link:<http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
>>> [Boris: correct and expand commit message]
>>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>>
>> Why -stable?  I though we had agreed that we didn't have an active
>> problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
>> currently sits?

This is probably a leftover from the original patch, before Konrad's 
patch got committed.

> Yes, AFAICT, we need at least one fix for 3.4 where the original patch
> f7f286a910221 broke xen.
>
> So either this one or 1ab46fd319bc should be backported to stable, if
> I'm not mistaken. If the second, I'll drop the stable tag from this one
> and resend.
>
> Konrad, what do you want wrt xen paravirt nullptr breakage for
> 3.4-stable?

Greg just sent out the review mail for 1ab46fd319bc, so we can drop the 
stable tag from this one.

Regards,
Andre.

-------- Original Message --------
Subject: [ 21/82] x86, amd, xen: Avoid NULL pointer paravirt references
Date: Thu, 7 Jun 2012 13:03:57 +0900
From: Greg KH <gregkh@linuxfoundation.org>
To: <linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
CC: <torvalds@linux-foundation.org>, <akpm@linux-foundation.org>, 
<alan@lxorguk.ukuu.org.uk>, Andre Przywara <andre.przywara@amd.com>, "H. 
Peter Anvin" <hpa@zytor.com>

3.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Konrad Rzeszutek Wilk <konrad@darnok.org>

commit 1ab46fd319bcf1fcd9fb6311727d532b580e4eba upstream.

Stub out MSR methods that aren't actually needed.  This fixes a crash
as Xen Dom0 on AMD Trinity systems.  A bigger patch should be added to
remove the paravirt machinery completely for the methods which
apparently have no users!
.....



-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:50:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:50: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 1ScXTX-0002mN-5b; Thu, 07 Jun 2012 07:49:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ScXTV-0002mI-On
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:49:45 +0000
Received: from [85.158.143.99:52137] by server-2.bemta-4.messagelabs.com id
	3A/DC-17938-91D50DF4; Thu, 07 Jun 2012 07:49:45 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339055382!26363572!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17856 invoked from network); 7 Jun 2012 07:49:43 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Jun 2012 07:49:43 -0000
Received: from mail150-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 07:48:55 +0000
Received: from mail150-tx2 (localhost [127.0.0.1])	by
	mail150-tx2-R.bigfish.com (Postfix) with ESMTP id CC7DF4C0227;
	Thu,  7 Jun 2012 07:48:54 +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: -16
X-BigFish: VPS-16(zzbb2dI9371I542M1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail150-tx2 (localhost.localdomain [127.0.0.1]) by mail150-tx2
	(MessageSwitch) id 133905533396885_26362;
	Thu,  7 Jun 2012 07:48:53 +0000 (UTC)
Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.247])	by
	mail150-tx2.bigfish.com (Postfix) with ESMTP id 08A142A0049;
	Thu,  7 Jun 2012 07:48:53 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 07:48:51 +0000
X-WSS-ID: 0M58LQQ-02-2G0-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 22869C8196;	Thu,  7 Jun 2012 02:49:37 -0500 (CDT)
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;
	Thu, 7 Jun 2012 02:49:53 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 7 Jun 2012 02:49:38 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	03:49:35 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id AE64449C58B; Thu,  7 Jun 2012
	08:49:34 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id 81C9C5940FF; Thu,  7 Jun 2012
	09:49:34 +0200 (CEST)
Message-ID: <4FD05CED.60905@amd.com>
Date: Thu, 7 Jun 2012 09:49:01 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@amd64.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com>
In-Reply-To: <20120607072159.GB9856@aftab.osrc.amd.com>
X-OriginatorOrg: amd.com
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/07/2012 09:21 AM, Borislav Petkov wrote:
> On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
>> On 06/01/2012 07:52 AM, Borislav Petkov wrote:
>>> From: Andre Przywara<andre.przywara@amd.com>
>>>
>>> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
>>> has disabled it") wrongfully added code which used the AMD-specific
>>> {rd,wr}msr variants for no real reason.
>>>
>>> This caused boot panics on xen which wasn't initializing the
>>> {rd,wr}msr_safe_regs pv_ops members properly.
>>>
>>> This, in turn, caused a heated discussion leading to us reviewing all
>>> uses of the AMD-specific variants and removing them where unneeded
>>> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
>>>
>>> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
>>> which should've been used in the first place anyway and avoided unneeded
>>> excitation with xen.
>>>
>>> Signed-off-by: Andre Przywara<andre.przywara@amd.com>
>>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>>> Cc: stable@vger.kernel.org # 3.4+
>>> Link:<http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
>>> [Boris: correct and expand commit message]
>>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>>
>> Why -stable?  I though we had agreed that we didn't have an active
>> problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
>> currently sits?

This is probably a leftover from the original patch, before Konrad's 
patch got committed.

> Yes, AFAICT, we need at least one fix for 3.4 where the original patch
> f7f286a910221 broke xen.
>
> So either this one or 1ab46fd319bc should be backported to stable, if
> I'm not mistaken. If the second, I'll drop the stable tag from this one
> and resend.
>
> Konrad, what do you want wrt xen paravirt nullptr breakage for
> 3.4-stable?

Greg just sent out the review mail for 1ab46fd319bc, so we can drop the 
stable tag from this one.

Regards,
Andre.

-------- Original Message --------
Subject: [ 21/82] x86, amd, xen: Avoid NULL pointer paravirt references
Date: Thu, 7 Jun 2012 13:03:57 +0900
From: Greg KH <gregkh@linuxfoundation.org>
To: <linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
CC: <torvalds@linux-foundation.org>, <akpm@linux-foundation.org>, 
<alan@lxorguk.ukuu.org.uk>, Andre Przywara <andre.przywara@amd.com>, "H. 
Peter Anvin" <hpa@zytor.com>

3.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Konrad Rzeszutek Wilk <konrad@darnok.org>

commit 1ab46fd319bcf1fcd9fb6311727d532b580e4eba upstream.

Stub out MSR methods that aren't actually needed.  This fixes a crash
as Xen Dom0 on AMD Trinity systems.  A bigger patch should be added to
remove the paravirt machinery completely for the methods which
apparently have no users!
.....



-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:51:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07: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 1ScXUi-0002pn-Ln; Thu, 07 Jun 2012 07:51:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScXUh-0002pa-9X
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:50:59 +0000
Received: from [85.158.143.35:22889] by server-1.bemta-4.messagelabs.com id
	08/D0-10042-16D50DF4; Thu, 07 Jun 2012 07:50:57 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339055397!13312045!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21425 invoked from network); 7 Jun 2012 07:49:58 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:49:58 -0000
Received: by obfk16 with SMTP id k16so768680obf.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 00:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=vvcMiQ5SAvxeMMnZAJwrMbv/o6yHHm/JbE/OiRlLqWY=;
	b=0oAr8hEBJxBpD7boICm8YZrXruEAWkoPyDpRntLD+eV6sZxeRsqiM3gFZ8qY5XYtYU
	yuDi4LjaTLna91CcKB1LKTU9trNqejYFxzWWkVBtDlB2P5MZGDlvLnf0h+W5dxlz2M8Y
	O9/N4RCTSzT0A5UGGGQdxM7qhScHvHZzV1/wndlgCpvQee7QIf4R8ueN1G2lLrE25kVk
	AfNI+1atMug22l5c09/fd92q3K8D9nqHBf1W/3hNUZ+2ekmOEgV+vPs8avtu8U5oWq59
	c9ftNwVyoDn4JXdWl0yEshLxM+3yh8YySt0AsJtRI1bLeEIEMzT628xlAHkvOcshM+Gi
	yumg==
MIME-Version: 1.0
Received: by 10.182.164.69 with SMTP id yo5mr1112111obb.17.1339055377481; Thu,
	07 Jun 2012 00:49:37 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Thu, 7 Jun 2012 00:49:37 -0700 (PDT)
In-Reply-To: <1339049291.6557.11.camel@dagon.hellion.org.uk>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	<CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
Date: Thu, 7 Jun 2012 15:49:37 +0800
Message-ID: <CAAh7U5Pn+VxC2aQiLWhCgtO_-F4=stF-uX-TZ8FfX7CU2XgWmA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 7, 2012 at 2:08 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Thu, 2012-06-07 at 04:19 +0100, ZhouPeng wrote:
>> On Wed, Jun 6, 2012 at 9:05 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>> > On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
>> >> changeset: =A0 25454:1804a873a64d
>> >> tag: =A0 =A0 =A0 =A0 tip
>> >> user: =A0 =A0 =A0 =A0Zhou Peng <ailvpeng25@gmail.com>
>> >> date: =A0 =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +0800
>> >> files: =A0 =A0 =A0 tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
>> >> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
>> >> description:
>> >> tools:libxl: Add qxl vga interface support.
>> >>
>> >> Usage:
>> >> =A0qxl=3D1
>> >> =A0qxlvram=3D64
>> >> =A0qxlram=3D64
>> >>
>> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>> >
>> > Thanks.
>> >
>> > As previously mentioned this is =A04.3 material. Please can you resubm=
it
>> > once the 4.3 dev cycle opens.
>> ok, thanks.
>> >
>> >> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
>> >> --- a/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:39:37 2012 =
+0800
>> >> +++ b/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:56:46 2012 =
+0800
>> >> @@ -23,6 +23,32 @@
>> >> =A0#include <xc_dom.h>
>> >> =A0#include <xenguest.h>
>> >>
>> >> +/*
>> >> + * For qxl vga interface, the total video mem is determined by
>> >> + * RAM bar and VRAM bar. But it is not simply linearly determined,
>> >> + * get_qxl_ram_size below gives the details.
>> >
>> > From this statement I expected get_qxl_ram_size to have a nice comment
>> > explaining what is going on, but it doesn't have this.
>> >
>> > Can you please explain somewhere how this value is determined (I can s=
ee
>> > it is not simple ;-)). Perhaps a link to some QXL/qemu document
>> > discussing these parameters would be helpful too?
>>
>> Sorry, there is not a piece of docs on ram bar and vram bar, and how
>> the total size
>> of qxl video memory is calculated from ram bar and vram bar parameters.
>>
>> But from my digging into qxl's source code and debugging, it works this =
way.
>>
>> I asked similar question in spice-list and get response from:
>> http://comments.gmane.org/gmane.comp.emulators.spice.devel/9501
>>
>> Any way, I will rich the document if get more info.
>
> OK, thanks.
>
>> >> +
>> >> + =A0 =A0return (vram + ram + 1023) / 1024;
>> >> +}
>> >> +
>> >> =A0void libxl_domain_config_init(libxl_domain_config *d_config)
>> >> =A0{
>> >> =A0 =A0 =A0memset(d_config, 0, sizeof(*d_config));
>> >> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
>> >>
>> >> =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_INTERF=
ACE_TYPE_DEFAULT)
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_INTER=
FACE_TYPE_CIRRUS;
>> >> + =A0 =A0 =A0 =A0if (b_info->device_model_version =3D=3D LIBXL_DEVICE=
_MODEL_VERSION_QEMU_XEN
>> >> + =A0 =A0 =A0 =A0 =A0 =A0&& b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_I=
NTERFACE_TYPE_QXL) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.vramkb =3D=3D LIBXL_ME=
MKB_DEFAULT)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.vramkb =3D 64 * 10=
24;
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.ramkb =3D=3D LIBXL_MEM=
KB_DEFAULT)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb =3D 64 * 102=
4;
>> >> + =A0 =A0 =A0 =A0 =A0 =A0uint32_t qxl_ram =3D get_qxl_ram_size(b_info=
->u.hvm.vga.vramkb,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0/*
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 * video_memkb is the real size of video mem=
ory to assign.
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 * If video_memkb can't meet the need of qxl=
, adjust it
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 * accordingly.
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 */
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if ((b_info->video_memkb =3D=3D LIBXL_MEMKB_=
DEFAULT)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| (b_info->video_memkb < qxl_ram)) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->video_memkb =3D qxl_ram;
>> >
>> > If video_memkb is !=3D LIBXL_MEMKB_DEFAULT and it is not sufficiently
>> > large then I think the correct thing to do is to error out and return
>> > ERROR_INVAL.
>>
>> Not agreed.
>> This will let user must to set a proper value to meet qxl, but from
>> discussing above, it's difficult for user to give this decision.
>> qxlram and qxlvram parameters are enough =A0for user to set qxl's video
>> ram (libvirt also use these two parameters).
>
> If the user has asked for a specific amount of video RAM which is not
> sufficient then the correct answer is to log an error (including the
> required minimum) and exit.
>
> You are correct that it is hard to figure out what "enough" RAM is. I
> expect that for that reason almost all users won't pass any of these
> arguments and will just accept the default, which will work just fine.

I think it's reasonable.
Just use the default will make things much more simpler.
> Ian.
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:51:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07: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 1ScXUi-0002pn-Ln; Thu, 07 Jun 2012 07:51:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScXUh-0002pa-9X
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:50:59 +0000
Received: from [85.158.143.35:22889] by server-1.bemta-4.messagelabs.com id
	08/D0-10042-16D50DF4; Thu, 07 Jun 2012 07:50:57 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339055397!13312045!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21425 invoked from network); 7 Jun 2012 07:49:58 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:49:58 -0000
Received: by obfk16 with SMTP id k16so768680obf.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 00:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=vvcMiQ5SAvxeMMnZAJwrMbv/o6yHHm/JbE/OiRlLqWY=;
	b=0oAr8hEBJxBpD7boICm8YZrXruEAWkoPyDpRntLD+eV6sZxeRsqiM3gFZ8qY5XYtYU
	yuDi4LjaTLna91CcKB1LKTU9trNqejYFxzWWkVBtDlB2P5MZGDlvLnf0h+W5dxlz2M8Y
	O9/N4RCTSzT0A5UGGGQdxM7qhScHvHZzV1/wndlgCpvQee7QIf4R8ueN1G2lLrE25kVk
	AfNI+1atMug22l5c09/fd92q3K8D9nqHBf1W/3hNUZ+2ekmOEgV+vPs8avtu8U5oWq59
	c9ftNwVyoDn4JXdWl0yEshLxM+3yh8YySt0AsJtRI1bLeEIEMzT628xlAHkvOcshM+Gi
	yumg==
MIME-Version: 1.0
Received: by 10.182.164.69 with SMTP id yo5mr1112111obb.17.1339055377481; Thu,
	07 Jun 2012 00:49:37 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Thu, 7 Jun 2012 00:49:37 -0700 (PDT)
In-Reply-To: <1339049291.6557.11.camel@dagon.hellion.org.uk>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	<CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
Date: Thu, 7 Jun 2012 15:49:37 +0800
Message-ID: <CAAh7U5Pn+VxC2aQiLWhCgtO_-F4=stF-uX-TZ8FfX7CU2XgWmA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 7, 2012 at 2:08 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Thu, 2012-06-07 at 04:19 +0100, ZhouPeng wrote:
>> On Wed, Jun 6, 2012 at 9:05 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>> > On Tue, 2012-06-05 at 12:22 +0100, ZhouPeng wrote:
>> >> changeset: =A0 25454:1804a873a64d
>> >> tag: =A0 =A0 =A0 =A0 tip
>> >> user: =A0 =A0 =A0 =A0Zhou Peng <ailvpeng25@gmail.com>
>> >> date: =A0 =A0 =A0 =A0Tue Jun 05 17:56:46 2012 +0800
>> >> files: =A0 =A0 =A0 tools/libxl/libxl_create.c tools/libxl/libxl_dm.c
>> >> tools/libxl/libxl_types.idl tools/libxl/xl_cmdimpl.c
>> >> description:
>> >> tools:libxl: Add qxl vga interface support.
>> >>
>> >> Usage:
>> >> =A0qxl=3D1
>> >> =A0qxlvram=3D64
>> >> =A0qxlram=3D64
>> >>
>> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>> >
>> > Thanks.
>> >
>> > As previously mentioned this is =A04.3 material. Please can you resubm=
it
>> > once the 4.3 dev cycle opens.
>> ok, thanks.
>> >
>> >> diff -r 7bd08f83a2ce -r 1804a873a64d tools/libxl/libxl_create.c
>> >> --- a/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:39:37 2012 =
+0800
>> >> +++ b/tools/libxl/libxl_create.c =A0 =A0 =A0Tue Jun 05 17:56:46 2012 =
+0800
>> >> @@ -23,6 +23,32 @@
>> >> =A0#include <xc_dom.h>
>> >> =A0#include <xenguest.h>
>> >>
>> >> +/*
>> >> + * For qxl vga interface, the total video mem is determined by
>> >> + * RAM bar and VRAM bar. But it is not simply linearly determined,
>> >> + * get_qxl_ram_size below gives the details.
>> >
>> > From this statement I expected get_qxl_ram_size to have a nice comment
>> > explaining what is going on, but it doesn't have this.
>> >
>> > Can you please explain somewhere how this value is determined (I can s=
ee
>> > it is not simple ;-)). Perhaps a link to some QXL/qemu document
>> > discussing these parameters would be helpful too?
>>
>> Sorry, there is not a piece of docs on ram bar and vram bar, and how
>> the total size
>> of qxl video memory is calculated from ram bar and vram bar parameters.
>>
>> But from my digging into qxl's source code and debugging, it works this =
way.
>>
>> I asked similar question in spice-list and get response from:
>> http://comments.gmane.org/gmane.comp.emulators.spice.devel/9501
>>
>> Any way, I will rich the document if get more info.
>
> OK, thanks.
>
>> >> +
>> >> + =A0 =A0return (vram + ram + 1023) / 1024;
>> >> +}
>> >> +
>> >> =A0void libxl_domain_config_init(libxl_domain_config *d_config)
>> >> =A0{
>> >> =A0 =A0 =A0memset(d_config, 0, sizeof(*d_config));
>> >> @@ -195,6 +221,25 @@ int libxl__domain_build_info_setdefault(
>> >>
>> >> =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_INTERF=
ACE_TYPE_DEFAULT)
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA_INTER=
FACE_TYPE_CIRRUS;
>> >> + =A0 =A0 =A0 =A0if (b_info->device_model_version =3D=3D LIBXL_DEVICE=
_MODEL_VERSION_QEMU_XEN
>> >> + =A0 =A0 =A0 =A0 =A0 =A0&& b_info->u.hvm.vga.type =3D=3D LIBXL_VGA_I=
NTERFACE_TYPE_QXL) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.vramkb =3D=3D LIBXL_ME=
MKB_DEFAULT)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.vramkb =3D 64 * 10=
24;
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (b_info->u.hvm.vga.ramkb =3D=3D LIBXL_MEM=
KB_DEFAULT)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb =3D 64 * 102=
4;
>> >> + =A0 =A0 =A0 =A0 =A0 =A0uint32_t qxl_ram =3D get_qxl_ram_size(b_info=
->u.hvm.vga.vramkb,
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.ramkb);
>> >> + =A0 =A0 =A0 =A0 =A0 =A0/*
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 * video_memkb is the real size of video mem=
ory to assign.
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 * If video_memkb can't meet the need of qxl=
, adjust it
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 * accordingly.
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 */
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if ((b_info->video_memkb =3D=3D LIBXL_MEMKB_=
DEFAULT)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| (b_info->video_memkb < qxl_ram)) {
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->video_memkb =3D qxl_ram;
>> >
>> > If video_memkb is !=3D LIBXL_MEMKB_DEFAULT and it is not sufficiently
>> > large then I think the correct thing to do is to error out and return
>> > ERROR_INVAL.
>>
>> Not agreed.
>> This will let user must to set a proper value to meet qxl, but from
>> discussing above, it's difficult for user to give this decision.
>> qxlram and qxlvram parameters are enough =A0for user to set qxl's video
>> ram (libvirt also use these two parameters).
>
> If the user has asked for a specific amount of video RAM which is not
> sufficient then the correct answer is to log an error (including the
> required minimum) and exit.
>
> You are correct that it is hard to figure out what "enough" RAM is. I
> expect that for that reason almost all users won't pass any of these
> arguments and will just accept the default, which will work just fine.

I think it's reasonable.
Just use the default will make things much more simpler.
> Ian.
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScXb2-00037J-KD; Thu, 07 Jun 2012 07:57:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1ScXb0-00037E-Vc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 07:57:31 +0000
Received: from [85.158.143.99:32231] by server-2.bemta-4.messagelabs.com id
	46/C7-17938-AEE50DF4; Thu, 07 Jun 2012 07:57:30 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339055848!28314490!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27641 invoked from network); 7 Jun 2012 07:57:29 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:57:29 -0000
Received: by obbwd20 with SMTP id wd20so784923obb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 00:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lI9BiQIw+T7fGYqlSrtyGDM19+AWiEBeOaNGiD86LZs=;
	b=Xeg2HPfN7NFa+xiFpZYBg8iipEB/u9bzkwGahl6jBiHsoD7ejG6bEmfh2xF0t/jepU
	AnlKXI7xI6bBXf94Ri1n6L0lSl1/GWP5SzUDQEifaip9WPkeV7/MdZ0QErgpwhcMG+7O
	Jo8RIPcvG0JxJj3QtGoZxRuUkgKL0uWUPTfBxRq6IFS5HH7+rJdhMGssgtrmHNl5wG7B
	s/Zs4wL2JfZqwXTjtVL1nHqsqRHTbHPBaQwtNoMBCZJlCTFNZ5iQf69X3gwbyqx1KBfD
	waJIhmMy+pGYDz4mWaiJ+wtTfdN16Z/VMWLjUpJLkVTFzTidBG1Fihmd+E3BP387elPn
	lcBA==
MIME-Version: 1.0
Received: by 10.182.47.105 with SMTP id c9mr1096927obn.49.1339055847874; Thu,
	07 Jun 2012 00:57:27 -0700 (PDT)
Received: by 10.182.53.33 with HTTP; Thu, 7 Jun 2012 00:57:27 -0700 (PDT)
In-Reply-To: <4FD04D70.1030805@icg.tugraz.at>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD04D70.1030805@icg.tugraz.at>
Date: Thu, 7 Jun 2012 08:57:27 +0100
Message-ID: <CAFuBCajci2vcyuUDLHADiU1YTDpSwzZGHF4ngt=eWNrDfjZv5w@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: dokter@icg.tugraz.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6981111441775548405=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6981111441775548405==
Content-Type: multipart/alternative; boundary=14dae9399769259f3704c1dd3c2f

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

Hi,

How to use "xl"? Should xend be disable? How do I configure host and
destination machines for live migration? Is it as before like for xm
utility?

On Thu, Jun 7, 2012 at 7:42 AM, Mark Dokter <dokter@icg.tugraz.at> wrote:

> On 06/06/2012 08:15 PM, elahe shekuhi wrote:
> > Hi,
> >
>
> Hi!
>
> Maybe you could try using xl instead of xm. They behave differently
> concerning sources of errors imho.
>
> hth, Mark
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

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

<div dir=3D"ltr">Hi,<br><br>How to use &quot;xl&quot;? Should xend be disab=
le? How do I configure host and destination machines for live migration? Is=
 it as before like for xm utility?<br><br><div class=3D"gmail_quote">On Thu=
, Jun 7, 2012 at 7:42 AM, Mark Dokter <span dir=3D"ltr">&lt;<a href=3D"mail=
to:dokter@icg.tugraz.at" target=3D"_blank">dokter@icg.tugraz.at</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 06/06/2012 08:15 PM, elahe shekuhi wrote:=
<br>
&gt; Hi,<br>
&gt;<br>
<br>
Hi!<br>
<br>
Maybe you could try using xl instead of xm. They behave differently<br>
concerning sources of errors imho.<br>
<br>
hth, Mark<br>
<div class=3D"HOEnZb"><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>

--14dae9399769259f3704c1dd3c2f--


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

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

--===============6981111441775548405==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 07:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScXb2-00037J-KD; Thu, 07 Jun 2012 07:57:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1ScXb0-00037E-Vc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 07:57:31 +0000
Received: from [85.158.143.99:32231] by server-2.bemta-4.messagelabs.com id
	46/C7-17938-AEE50DF4; Thu, 07 Jun 2012 07:57:30 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339055848!28314490!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27641 invoked from network); 7 Jun 2012 07:57:29 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:57:29 -0000
Received: by obbwd20 with SMTP id wd20so784923obb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 00:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lI9BiQIw+T7fGYqlSrtyGDM19+AWiEBeOaNGiD86LZs=;
	b=Xeg2HPfN7NFa+xiFpZYBg8iipEB/u9bzkwGahl6jBiHsoD7ejG6bEmfh2xF0t/jepU
	AnlKXI7xI6bBXf94Ri1n6L0lSl1/GWP5SzUDQEifaip9WPkeV7/MdZ0QErgpwhcMG+7O
	Jo8RIPcvG0JxJj3QtGoZxRuUkgKL0uWUPTfBxRq6IFS5HH7+rJdhMGssgtrmHNl5wG7B
	s/Zs4wL2JfZqwXTjtVL1nHqsqRHTbHPBaQwtNoMBCZJlCTFNZ5iQf69X3gwbyqx1KBfD
	waJIhmMy+pGYDz4mWaiJ+wtTfdN16Z/VMWLjUpJLkVTFzTidBG1Fihmd+E3BP387elPn
	lcBA==
MIME-Version: 1.0
Received: by 10.182.47.105 with SMTP id c9mr1096927obn.49.1339055847874; Thu,
	07 Jun 2012 00:57:27 -0700 (PDT)
Received: by 10.182.53.33 with HTTP; Thu, 7 Jun 2012 00:57:27 -0700 (PDT)
In-Reply-To: <4FD04D70.1030805@icg.tugraz.at>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD04D70.1030805@icg.tugraz.at>
Date: Thu, 7 Jun 2012 08:57:27 +0100
Message-ID: <CAFuBCajci2vcyuUDLHADiU1YTDpSwzZGHF4ngt=eWNrDfjZv5w@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: dokter@icg.tugraz.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6981111441775548405=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6981111441775548405==
Content-Type: multipart/alternative; boundary=14dae9399769259f3704c1dd3c2f

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

Hi,

How to use "xl"? Should xend be disable? How do I configure host and
destination machines for live migration? Is it as before like for xm
utility?

On Thu, Jun 7, 2012 at 7:42 AM, Mark Dokter <dokter@icg.tugraz.at> wrote:

> On 06/06/2012 08:15 PM, elahe shekuhi wrote:
> > Hi,
> >
>
> Hi!
>
> Maybe you could try using xl instead of xm. They behave differently
> concerning sources of errors imho.
>
> hth, Mark
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

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

<div dir=3D"ltr">Hi,<br><br>How to use &quot;xl&quot;? Should xend be disab=
le? How do I configure host and destination machines for live migration? Is=
 it as before like for xm utility?<br><br><div class=3D"gmail_quote">On Thu=
, Jun 7, 2012 at 7:42 AM, Mark Dokter <span dir=3D"ltr">&lt;<a href=3D"mail=
to:dokter@icg.tugraz.at" target=3D"_blank">dokter@icg.tugraz.at</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 06/06/2012 08:15 PM, elahe shekuhi wrote:=
<br>
&gt; Hi,<br>
&gt;<br>
<br>
Hi!<br>
<br>
Maybe you could try using xl instead of xm. They behave differently<br>
concerning sources of errors imho.<br>
<br>
hth, Mark<br>
<div class=3D"HOEnZb"><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>

--14dae9399769259f3704c1dd3c2f--


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

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

--===============6981111441775548405==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 07:58:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07: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 1ScXc3-0003Ab-2P; Thu, 07 Jun 2012 07:58:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScXc1-0003AT-BJ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:58:33 +0000
Received: from [85.158.139.83:20353] by server-5.bemta-5.messagelabs.com id
	73/67-04481-82F50DF4; Thu, 07 Jun 2012 07:58:32 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339055910!28118635!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7785 invoked from network); 7 Jun 2012 07:58:31 -0000
Received: from mail-gh0-f171.google.com (HELO mail-gh0-f171.google.com)
	(209.85.160.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:58:31 -0000
Received: by ghy10 with SMTP id 10so222902ghy.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 00:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=K4AQ1hf0h1bIkI4yObDdp5XaQxujJX6KYeK092i8qiA=;
	b=NEKFpwA9dAwDbgXhDHaGyKtUv22pYq0Da6TmW0hIRJ6z1zi5cE4OZHntZrN7rx1aP8
	b1r/AXvJCstDq2M7B0rx7UZfiPMPWTTsEr1N2y7cZLu5K+A7ixS8cYSJX1wn4ySkHRFA
	GAzCawiuJPqXQy0L7k20ObRK4MDVCnKUL0coGJynlxy3Xh8aIu/Nk9yk6aFx59Kgakrb
	Py6gcnB2WXiLPg3ILlYoOFHFBDMthb81jE/vBU5HgtfZuJbygtwTE+6vWSSuHVFJZsUH
	k++WRb1xe4RoZkm/aO/KOkCTsIDUxvYYwvNCl4Od9Q8sMgrSU69dPCq0XuvZjsN+mKfY
	0QjA==
MIME-Version: 1.0
Received: by 10.60.169.174 with SMTP id af14mr1117726oec.13.1339055910261;
	Thu, 07 Jun 2012 00:58:30 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Thu, 7 Jun 2012 00:58:30 -0700 (PDT)
In-Reply-To: <1339050245.6557.17.camel@dagon.hellion.org.uk>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
	<1338988073.32319.86.camel@zakaz.uk.xensource.com>
	<CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
	<1339050245.6557.17.camel@dagon.hellion.org.uk>
Date: Thu, 7 Jun 2012 15:58:30 +0800
Message-ID: <CAAh7U5NXPYH-Z8o5it2ZN+bjact7TBXqG2OYbUwCxxCsYj0Mhg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface 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="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, Jun 7, 2012 at 2:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Thu, 2012-06-07 at 04:22 +0100, ZhouPeng wrote:
>> On Wed, Jun 6, 2012 at 9:07 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>> > On Tue, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
>> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>> >
>> > You can/should include this with the patch which adds the functionalit=
y,
>> > no need to separate it out.
>> Ok.
>> >
>> >>
>> >> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
>> >> --- a/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 17:56:46 2012 +0800
>> >> +++ b/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 18:58:12 2012 +0800
>> >> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
>> >>
>> >> =A0Sets the amount of RAM which the emulated video card will contain,
>> >> =A0which 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). The default is 8MB which is sufficient for
>> >> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
>> >> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
>> >> +available. This option is available when using the B<stdvga> and
>> >> +B<qxl> options (see below).
>> >> +For B<stdvga> option, the default is 8MB which is sufficient for
>> >> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> opt=
ions,
>> >> +the amount of video ram is fixed at 4MB which is sufficient for 1024=
x768
>> >> =A0at 32 bpp.
>> >> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
>> >> +option below).
>> >>
>> >> =A0=3Ditem B<stdvga=3DBOOLEAN>
>> >>
>> >> @@ -711,6 +714,27 @@ emulated graphics device. The default is
>> >> =A0emulated graphics device. The default is false which means to emul=
ate
>> >> =A0a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>> >> =A0later (e.g. Windows XP onwards) then you should enable this.
>> >> +
>> >> +=3Ditem B<qxl=3DBOOLEAN>
>> >> +
>> >> +Select a QXL VGA card as the emulated graphics device. This enables
>> >> +the other QXL-related settings.
>> >> +In general, QXL should work with the Spice remote display protocol f=
or
>> >> +acceleration, but QXL driver is necessary in guest. QXL can also work
>> >> +with the VNC protocol like a standard VGA without acceleration.
>> >> +
>> >> +=3Ditem B<qxlram=3DMBYTES>
>> >> +
>> >> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
>> >> +The total size of QXL video memory is determined by B<qxlram> (RAM b=
ar)
>> >> +and B<qxlvram> (VRAM bar), the size of each is settable.
>> >> +B<videoram> can set the amount of RAM which emulated video card
>> >> +will contain, but if it can't meet the need of QXL, it will be
>> >> +adjusted accordingly.
>> >> +
>> >> +=3Ditem B<qxlvram=3DMBYTES>
>> >> +
>> >> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.
>> >
>> > It's not clear to me having read this what the distinction between RAM
>> > and VRAM is in the context of QXL. When and why would I want to set
>> > either?
>> Both of them are necessary to set qxl video ram.
>> They are necessary paremeters of qxl.
>
> But they aren't necessary at the xl layer, right? I can just omit them
> and a correct value will be chosen for me?

I means if user want to adjust the qxl total ram, both parameters
are necessary to be considered.

But if just use the default, both can be omitted, and a
correct value will be chosen by qxl (which is like get_qxl_ram(64, 64) =3D =
128).
>
>>
>> Any way, I will rich the document if get more info.
>> Thanks.
>> > Ian.
>> >
>>
>>
>>
>
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 07:58:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 07: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 1ScXc3-0003Ab-2P; Thu, 07 Jun 2012 07:58:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1ScXc1-0003AT-BJ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 07:58:33 +0000
Received: from [85.158.139.83:20353] by server-5.bemta-5.messagelabs.com id
	73/67-04481-82F50DF4; Thu, 07 Jun 2012 07:58:32 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339055910!28118635!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7785 invoked from network); 7 Jun 2012 07:58:31 -0000
Received: from mail-gh0-f171.google.com (HELO mail-gh0-f171.google.com)
	(209.85.160.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 07:58:31 -0000
Received: by ghy10 with SMTP id 10so222902ghy.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 00:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=K4AQ1hf0h1bIkI4yObDdp5XaQxujJX6KYeK092i8qiA=;
	b=NEKFpwA9dAwDbgXhDHaGyKtUv22pYq0Da6TmW0hIRJ6z1zi5cE4OZHntZrN7rx1aP8
	b1r/AXvJCstDq2M7B0rx7UZfiPMPWTTsEr1N2y7cZLu5K+A7ixS8cYSJX1wn4ySkHRFA
	GAzCawiuJPqXQy0L7k20ObRK4MDVCnKUL0coGJynlxy3Xh8aIu/Nk9yk6aFx59Kgakrb
	Py6gcnB2WXiLPg3ILlYoOFHFBDMthb81jE/vBU5HgtfZuJbygtwTE+6vWSSuHVFJZsUH
	k++WRb1xe4RoZkm/aO/KOkCTsIDUxvYYwvNCl4Od9Q8sMgrSU69dPCq0XuvZjsN+mKfY
	0QjA==
MIME-Version: 1.0
Received: by 10.60.169.174 with SMTP id af14mr1117726oec.13.1339055910261;
	Thu, 07 Jun 2012 00:58:30 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Thu, 7 Jun 2012 00:58:30 -0700 (PDT)
In-Reply-To: <1339050245.6557.17.camel@dagon.hellion.org.uk>
References: <CAAh7U5Pu1Uf4U=1t3FXJrbfuGN_pd=kxwuG6rmKe41aam41Ohg@mail.gmail.com>
	<1338988073.32319.86.camel@zakaz.uk.xensource.com>
	<CAAh7U5NWickumpR14Vef_we_sOPTghuSqUbfgOjn6gA-upD05g@mail.gmail.com>
	<1339050245.6557.17.camel@dagon.hellion.org.uk>
Date: Thu, 7 Jun 2012 15:58:30 +0800
Message-ID: <CAAh7U5NXPYH-Z8o5it2ZN+bjact7TBXqG2OYbUwCxxCsYj0Mhg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] docs: qxl vga interface 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="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, Jun 7, 2012 at 2:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Thu, 2012-06-07 at 04:22 +0100, ZhouPeng wrote:
>> On Wed, Jun 6, 2012 at 9:07 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>> > On Tue, 2012-06-05 at 12:26 +0100, ZhouPeng wrote:
>> >> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>> >
>> > You can/should include this with the patch which adds the functionalit=
y,
>> > no need to separate it out.
>> Ok.
>> >
>> >>
>> >> diff -r 1804a873a64d docs/man/xl.cfg.pod.5
>> >> --- a/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 17:56:46 2012 +0800
>> >> +++ b/docs/man/xl.cfg.pod.5 =A0 Tue Jun 05 18:58:12 2012 +0800
>> >> @@ -699,11 +699,14 @@ in the B<VFB_SPEC_STRING> for configurin
>> >>
>> >> =A0Sets the amount of RAM which the emulated video card will contain,
>> >> =A0which 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). The default is 8MB which is sufficient for
>> >> -e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
>> >> -amount of video ram is fixed at 4MB which is sufficient for 1024x768
>> >> +available. This option is available when using the B<stdvga> and
>> >> +B<qxl> options (see below).
>> >> +For B<stdvga> option, the default is 8MB which is sufficient for
>> >> +e.g. 1600x1200 at 32bpp. When not using the B<stdvga> and B<qxl> opt=
ions,
>> >> +the amount of video ram is fixed at 4MB which is sufficient for 1024=
x768
>> >> =A0at 32 bpp.
>> >> +For B<qxl> option, it may be adjusted automatically (see B<qxlram>
>> >> +option below).
>> >>
>> >> =A0=3Ditem B<stdvga=3DBOOLEAN>
>> >>
>> >> @@ -711,6 +714,27 @@ emulated graphics device. The default is
>> >> =A0emulated graphics device. The default is false which means to emul=
ate
>> >> =A0a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>> >> =A0later (e.g. Windows XP onwards) then you should enable this.
>> >> +
>> >> +=3Ditem B<qxl=3DBOOLEAN>
>> >> +
>> >> +Select a QXL VGA card as the emulated graphics device. This enables
>> >> +the other QXL-related settings.
>> >> +In general, QXL should work with the Spice remote display protocol f=
or
>> >> +acceleration, but QXL driver is necessary in guest. QXL can also work
>> >> +with the VNC protocol like a standard VGA without acceleration.
>> >> +
>> >> +=3Ditem B<qxlram=3DMBYTES>
>> >> +
>> >> +Sets the amount of RAM bar for QXL VGA card. The default is 64 MiB.
>> >> +The total size of QXL video memory is determined by B<qxlram> (RAM b=
ar)
>> >> +and B<qxlvram> (VRAM bar), the size of each is settable.
>> >> +B<videoram> can set the amount of RAM which emulated video card
>> >> +will contain, but if it can't meet the need of QXL, it will be
>> >> +adjusted accordingly.
>> >> +
>> >> +=3Ditem B<qxlvram=3DMBYTES>
>> >> +
>> >> +Sets the amount of VRAM bar for QXL VGA card. The default is 64 MiB.
>> >
>> > It's not clear to me having read this what the distinction between RAM
>> > and VRAM is in the context of QXL. When and why would I want to set
>> > either?
>> Both of them are necessary to set qxl video ram.
>> They are necessary paremeters of qxl.
>
> But they aren't necessary at the xl layer, right? I can just omit them
> and a correct value will be chosen for me?

I means if user want to adjust the qxl total ram, both parameters
are necessary to be considered.

But if just use the default, both can be omitted, and a
correct value will be chosen by qxl (which is like get_qxl_ram(64, 64) =3D =
128).
>
>>
>> Any way, I will rich the document if get more info.
>> Thanks.
>> > Ian.
>> >
>>
>>
>>
>
>



-- =

Zhou Peng

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 08:02:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08: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 1ScXfU-0003no-Gv; Thu, 07 Jun 2012 08:02: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 1ScXfT-0003ni-7a
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 08:02:07 +0000
Received: from [85.158.139.83:7939] by server-3.bemta-5.messagelabs.com id
	CD/43-17554-EFF50DF4; Thu, 07 Jun 2012 08:02:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339056125!28402011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14560 invoked from network); 7 Jun 2012 08:02:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 08:02:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12873998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 08:02:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 09:02:03 +0100
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 1ScXfO-0006hF-WC;
	Thu, 07 Jun 2012 08:02:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScXfO-0007ab-S1;
	Thu, 07 Jun 2012 09:02:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13023-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Jun 2012 09:02:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13023: 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 13023 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13023/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13020

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  f6bfaf9daa50
baseline version:
 xen                  f6bfaf9daa50

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 08:02:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08: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 1ScXfU-0003no-Gv; Thu, 07 Jun 2012 08:02: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 1ScXfT-0003ni-7a
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 08:02:07 +0000
Received: from [85.158.139.83:7939] by server-3.bemta-5.messagelabs.com id
	CD/43-17554-EFF50DF4; Thu, 07 Jun 2012 08:02:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339056125!28402011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyNzM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14560 invoked from network); 7 Jun 2012 08:02:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 08:02:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="12873998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 08:02:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 09:02:03 +0100
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 1ScXfO-0006hF-WC;
	Thu, 07 Jun 2012 08:02:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScXfO-0007ab-S1;
	Thu, 07 Jun 2012 09:02:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13023-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Jun 2012 09:02:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13023: 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 13023 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13023/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13020

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  f6bfaf9daa50
baseline version:
 xen                  f6bfaf9daa50

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 08:09:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08:09: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 1ScXly-000471-LC; Thu, 07 Jun 2012 08:08:50 +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 1ScXlw-00046w-Ij
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 08:08:48 +0000
Received: from [193.109.254.147:41607] by server-10.bemta-14.messagelabs.com
	id 91/F1-25709-F8160DF4; Thu, 07 Jun 2012 08:08:47 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339056525!8376119!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13632 invoked from network); 7 Jun 2012 08:08:47 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 08:08:47 -0000
Received: by dajz8 with SMTP id z8so581512daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 01:08:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent
	:x-gm-message-state;
	bh=qAjmO6cHDDn8Qu7TyY9ZJ08bWESJnROA4hPRROM/rAA=;
	b=cP220IC4aQK4E4nIyJIuewNvvj+8y54fgDG49dzvcp1Sezkbmwh9ThXvcB/tyqYXe3
	2toGxgDrttr6OplWlGI3LtUI/qDNmA+w93Lh5a1VrdayIyw/1LjT9/l63qlZzxuAGKWW
	vOvF6jQmUZY6LxCReXrbuOXxle8ZC8bvd3JLbdRvtxqG23459mFkt+2+4KnVysRzKUWL
	KQf7IFWjWRiDNIS5XeiB/jgtpDmjhZ/UXBx9ie+WrAzYUqzfbmiFy1UNjS7/lDbopTzH
	l94yrv+mk1LKTNRO5jqhHNU+ooUUK4tsUZ5T4puWxKwfvYO2jkqQJzxAZP8jK9eP5jUh
	aKbw==
Received: by 10.68.197.198 with SMTP id iw6mr6259873pbc.36.1339056525003;
	Thu, 07 Jun 2012 01:08:45 -0700 (PDT)
Received: from localhost (p40081-ipngn402hodogaya.kanagawa.ocn.ne.jp.
	[180.23.161.81])
	by mx.google.com with ESMTPS id hb5sm3291671pbc.58.2012.06.07.01.08.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 01:08:43 -0700 (PDT)
Date: Thu, 7 Jun 2012 17:08:33 +0900
From: Greg KH <gregkh@linuxfoundation.org>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120607080833.GA23186@kroah.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com> <4FD05CED.60905@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD05CED.60905@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQnWlKeGC2o+9DQCIaQMGMIEHZm76edUbFMn1GqH0JgE+jzbSMPp5grLndRVg/cwZ0+wpA4z
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
 AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 09:49:01AM +0200, Andre Przywara wrote:
> On 06/07/2012 09:21 AM, Borislav Petkov wrote:
> >On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
> >>On 06/01/2012 07:52 AM, Borislav Petkov wrote:
> >>>From: Andre Przywara<andre.przywara@amd.com>
> >>>
> >>>f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> >>>has disabled it") wrongfully added code which used the AMD-specific
> >>>{rd,wr}msr variants for no real reason.
> >>>
> >>>This caused boot panics on xen which wasn't initializing the
> >>>{rd,wr}msr_safe_regs pv_ops members properly.
> >>>
> >>>This, in turn, caused a heated discussion leading to us reviewing all
> >>>uses of the AMD-specific variants and removing them where unneeded
> >>>(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> >>>
> >>>Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> >>>which should've been used in the first place anyway and avoided unneeded
> >>>excitation with xen.
> >>>
> >>>Signed-off-by: Andre Przywara<andre.przywara@amd.com>
> >>>Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
> >>>Cc: stable@vger.kernel.org # 3.4+
> >>>Link:<http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> >>>[Boris: correct and expand commit message]
> >>>Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
> >>
> >>Why -stable?  I though we had agreed that we didn't have an active
> >>problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
> >>currently sits?
> 
> This is probably a leftover from the original patch, before Konrad's
> patch got committed.
> 
> >Yes, AFAICT, we need at least one fix for 3.4 where the original patch
> >f7f286a910221 broke xen.
> >
> >So either this one or 1ab46fd319bc should be backported to stable, if
> >I'm not mistaken. If the second, I'll drop the stable tag from this one
> >and resend.
> >
> >Konrad, what do you want wrt xen paravirt nullptr breakage for
> >3.4-stable?
> 
> Greg just sent out the review mail for 1ab46fd319bc, so we can drop
> the stable tag from this one.
> 
> Regards,
> Andre.

What?  So I don't need to do anything?

Totally confused,

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 Thu Jun 07 08:09:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08:09: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 1ScXly-000471-LC; Thu, 07 Jun 2012 08:08:50 +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 1ScXlw-00046w-Ij
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 08:08:48 +0000
Received: from [193.109.254.147:41607] by server-10.bemta-14.messagelabs.com
	id 91/F1-25709-F8160DF4; Thu, 07 Jun 2012 08:08:47 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339056525!8376119!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13632 invoked from network); 7 Jun 2012 08:08:47 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 08:08:47 -0000
Received: by dajz8 with SMTP id z8so581512daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 01:08:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent
	:x-gm-message-state;
	bh=qAjmO6cHDDn8Qu7TyY9ZJ08bWESJnROA4hPRROM/rAA=;
	b=cP220IC4aQK4E4nIyJIuewNvvj+8y54fgDG49dzvcp1Sezkbmwh9ThXvcB/tyqYXe3
	2toGxgDrttr6OplWlGI3LtUI/qDNmA+w93Lh5a1VrdayIyw/1LjT9/l63qlZzxuAGKWW
	vOvF6jQmUZY6LxCReXrbuOXxle8ZC8bvd3JLbdRvtxqG23459mFkt+2+4KnVysRzKUWL
	KQf7IFWjWRiDNIS5XeiB/jgtpDmjhZ/UXBx9ie+WrAzYUqzfbmiFy1UNjS7/lDbopTzH
	l94yrv+mk1LKTNRO5jqhHNU+ooUUK4tsUZ5T4puWxKwfvYO2jkqQJzxAZP8jK9eP5jUh
	aKbw==
Received: by 10.68.197.198 with SMTP id iw6mr6259873pbc.36.1339056525003;
	Thu, 07 Jun 2012 01:08:45 -0700 (PDT)
Received: from localhost (p40081-ipngn402hodogaya.kanagawa.ocn.ne.jp.
	[180.23.161.81])
	by mx.google.com with ESMTPS id hb5sm3291671pbc.58.2012.06.07.01.08.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 01:08:43 -0700 (PDT)
Date: Thu, 7 Jun 2012 17:08:33 +0900
From: Greg KH <gregkh@linuxfoundation.org>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120607080833.GA23186@kroah.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com> <4FD05CED.60905@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD05CED.60905@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQnWlKeGC2o+9DQCIaQMGMIEHZm76edUbFMn1GqH0JgE+jzbSMPp5grLndRVg/cwZ0+wpA4z
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
 AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 09:49:01AM +0200, Andre Przywara wrote:
> On 06/07/2012 09:21 AM, Borislav Petkov wrote:
> >On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
> >>On 06/01/2012 07:52 AM, Borislav Petkov wrote:
> >>>From: Andre Przywara<andre.przywara@amd.com>
> >>>
> >>>f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
> >>>has disabled it") wrongfully added code which used the AMD-specific
> >>>{rd,wr}msr variants for no real reason.
> >>>
> >>>This caused boot panics on xen which wasn't initializing the
> >>>{rd,wr}msr_safe_regs pv_ops members properly.
> >>>
> >>>This, in turn, caused a heated discussion leading to us reviewing all
> >>>uses of the AMD-specific variants and removing them where unneeded
> >>>(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
> >>>
> >>>Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
> >>>which should've been used in the first place anyway and avoided unneeded
> >>>excitation with xen.
> >>>
> >>>Signed-off-by: Andre Przywara<andre.przywara@amd.com>
> >>>Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
> >>>Cc: stable@vger.kernel.org # 3.4+
> >>>Link:<http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> >>>[Boris: correct and expand commit message]
> >>>Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
> >>
> >>Why -stable?  I though we had agreed that we didn't have an active
> >>problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
> >>currently sits?
> 
> This is probably a leftover from the original patch, before Konrad's
> patch got committed.
> 
> >Yes, AFAICT, we need at least one fix for 3.4 where the original patch
> >f7f286a910221 broke xen.
> >
> >So either this one or 1ab46fd319bc should be backported to stable, if
> >I'm not mistaken. If the second, I'll drop the stable tag from this one
> >and resend.
> >
> >Konrad, what do you want wrt xen paravirt nullptr breakage for
> >3.4-stable?
> 
> Greg just sent out the review mail for 1ab46fd319bc, so we can drop
> the stable tag from this one.
> 
> Regards,
> Andre.

What?  So I don't need to do anything?

Totally confused,

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 Thu Jun 07 08:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08: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 1ScXwb-0004GZ-T7; Thu, 07 Jun 2012 08:19:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ScXwZ-0004GR-Ut
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 08:19:48 +0000
Received: from [85.158.139.83:21826] by server-5.bemta-5.messagelabs.com id
	5A/C3-04481-32460DF4; Thu, 07 Jun 2012 08:19:47 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339057184!32363893!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24151 invoked from network); 7 Jun 2012 08:19:45 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-12.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Jun 2012 08:19:45 -0000
Received: from mail209-ch1-R.bigfish.com (10.43.68.253) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 08:18:57 +0000
Received: from mail209-ch1 (localhost [127.0.0.1])	by
	mail209-ch1-R.bigfish.com (Postfix) with ESMTP id 9F7481402E7;
	Thu,  7 Jun 2012 08:18:56 +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: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail209-ch1 (localhost.localdomain [127.0.0.1]) by mail209-ch1
	(MessageSwitch) id 133905713449298_21711;
	Thu,  7 Jun 2012 08:18:54 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.246])	by mail209-ch1.bigfish.com (Postfix) with ESMTP id
	09067460048;	Thu,  7 Jun 2012 08:18:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 08:18:53 +0000
X-WSS-ID: 0M58N4Q-02-3Y3-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 23051C8195;	Thu,  7 Jun 2012 03:19:37 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 7 Jun 2012 03:19:52 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 7 Jun 2012 03:19:37 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	04:19:36 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F240F49C69E; Thu,  7 Jun 2012
	09:19:34 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id BB1075940FF; Thu,  7 Jun 2012
	10:19:34 +0200 (CEST)
Message-ID: <4FD063F0.3060301@amd.com>
Date: Thu, 7 Jun 2012 10:18:56 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com>
	<4FD05CED.60905@amd.com> <20120607080833.GA23186@kroah.com>
In-Reply-To: <20120607080833.GA23186@kroah.com>
X-OriginatorOrg: amd.com
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/07/2012 10:08 AM, Greg KH wrote:
> On Thu, Jun 07, 2012 at 09:49:01AM +0200, Andre Przywara wrote:
>> On 06/07/2012 09:21 AM, Borislav Petkov wrote:
>>> On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
>>>> On 06/01/2012 07:52 AM, Borislav Petkov wrote:
>>>>> From: Andre Przywara<andre.przywara@amd.com>
>>>>>
>>>>> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
>>>>> has disabled it") wrongfully added code which used the AMD-specific
>>>>> {rd,wr}msr variants for no real reason.
>>>>>
>>>>> This caused boot panics on xen which wasn't initializing the
>>>>> {rd,wr}msr_safe_regs pv_ops members properly.
>>>>>
>>>>> This, in turn, caused a heated discussion leading to us reviewing all
>>>>> uses of the AMD-specific variants and removing them where unneeded
>>>>> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
>>>>>
>>>>> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
>>>>> which should've been used in the first place anyway and avoided unneeded
>>>>> excitation with xen.
>>>>>
>>>>> Signed-off-by: Andre Przywara<andre.przywara@amd.com>
>>>>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>>>>> Cc: stable@vger.kernel.org # 3.4+
>>>>> Link:<http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
>>>>> [Boris: correct and expand commit message]
>>>>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>>>>
>>>> Why -stable?  I though we had agreed that we didn't have an active
>>>> problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
>>>> currently sits?
>>
>> This is probably a leftover from the original patch, before Konrad's
>> patch got committed.
>>
>>> Yes, AFAICT, we need at least one fix for 3.4 where the original patch
>>> f7f286a910221 broke xen.
>>>
>>> So either this one or 1ab46fd319bc should be backported to stable, if
>>> I'm not mistaken. If the second, I'll drop the stable tag from this one
>>> and resend.
>>>
>>> Konrad, what do you want wrt xen paravirt nullptr breakage for
>>> 3.4-stable?
>>
>> Greg just sent out the review mail for 1ab46fd319bc, so we can drop
>> the stable tag from this one.
>>
>> Regards,
>> Andre.
>
> What?  So I don't need to do anything?
>
> Totally confused,

Sorry for that.

To fix the issue, we need only one of those patches.
Mine ("Fix crash as Xen Dom0 on AMD Trinity systems", removing "_amd" 
from the rd/wrmsr calls) was sent out earlier, so I added the stable tag.
A bit later Konrad sent his patch (1ab46fd319bc, initializing the 
forgotten PVOPS members), which hpa took (dropping mine). So this fix is 
in 3.5-rc1 and should also be in -stable.
Now for making things smoother Boris sent out mine again - for 3.6 - and 
more or less accidentally kept the stable tag in it.

Long story short: everything is fine, just apply the one you sent the 
review message for.

HTH,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 08:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08: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 1ScXwb-0004GZ-T7; Thu, 07 Jun 2012 08:19:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ScXwZ-0004GR-Ut
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 08:19:48 +0000
Received: from [85.158.139.83:21826] by server-5.bemta-5.messagelabs.com id
	5A/C3-04481-32460DF4; Thu, 07 Jun 2012 08:19:47 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339057184!32363893!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24151 invoked from network); 7 Jun 2012 08:19:45 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-12.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Jun 2012 08:19:45 -0000
Received: from mail209-ch1-R.bigfish.com (10.43.68.253) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 08:18:57 +0000
Received: from mail209-ch1 (localhost [127.0.0.1])	by
	mail209-ch1-R.bigfish.com (Postfix) with ESMTP id 9F7481402E7;
	Thu,  7 Jun 2012 08:18:56 +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: -11
X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail209-ch1 (localhost.localdomain [127.0.0.1]) by mail209-ch1
	(MessageSwitch) id 133905713449298_21711;
	Thu,  7 Jun 2012 08:18:54 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.246])	by mail209-ch1.bigfish.com (Postfix) with ESMTP id
	09067460048;	Thu,  7 Jun 2012 08:18:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 08:18:53 +0000
X-WSS-ID: 0M58N4Q-02-3Y3-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 23051C8195;	Thu,  7 Jun 2012 03:19:37 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 7 Jun 2012 03:19:52 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 7 Jun 2012 03:19:37 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	04:19:36 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F240F49C69E; Thu,  7 Jun 2012
	09:19:34 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id BB1075940FF; Thu,  7 Jun 2012
	10:19:34 +0200 (CEST)
Message-ID: <4FD063F0.3060301@amd.com>
Date: Thu, 7 Jun 2012 10:18:56 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com>
	<4FD05CED.60905@amd.com> <20120607080833.GA23186@kroah.com>
In-Reply-To: <20120607080833.GA23186@kroah.com>
X-OriginatorOrg: amd.com
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/07/2012 10:08 AM, Greg KH wrote:
> On Thu, Jun 07, 2012 at 09:49:01AM +0200, Andre Przywara wrote:
>> On 06/07/2012 09:21 AM, Borislav Petkov wrote:
>>> On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
>>>> On 06/01/2012 07:52 AM, Borislav Petkov wrote:
>>>>> From: Andre Przywara<andre.przywara@amd.com>
>>>>>
>>>>> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS
>>>>> has disabled it") wrongfully added code which used the AMD-specific
>>>>> {rd,wr}msr variants for no real reason.
>>>>>
>>>>> This caused boot panics on xen which wasn't initializing the
>>>>> {rd,wr}msr_safe_regs pv_ops members properly.
>>>>>
>>>>> This, in turn, caused a heated discussion leading to us reviewing all
>>>>> uses of the AMD-specific variants and removing them where unneeded
>>>>> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
>>>>>
>>>>> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
>>>>> which should've been used in the first place anyway and avoided unneeded
>>>>> excitation with xen.
>>>>>
>>>>> Signed-off-by: Andre Przywara<andre.przywara@amd.com>
>>>>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>>>>> Cc: stable@vger.kernel.org # 3.4+
>>>>> Link:<http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
>>>>> [Boris: correct and expand commit message]
>>>>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>>>>
>>>> Why -stable?  I though we had agreed that we didn't have an active
>>>> problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
>>>> currently sits?
>>
>> This is probably a leftover from the original patch, before Konrad's
>> patch got committed.
>>
>>> Yes, AFAICT, we need at least one fix for 3.4 where the original patch
>>> f7f286a910221 broke xen.
>>>
>>> So either this one or 1ab46fd319bc should be backported to stable, if
>>> I'm not mistaken. If the second, I'll drop the stable tag from this one
>>> and resend.
>>>
>>> Konrad, what do you want wrt xen paravirt nullptr breakage for
>>> 3.4-stable?
>>
>> Greg just sent out the review mail for 1ab46fd319bc, so we can drop
>> the stable tag from this one.
>>
>> Regards,
>> Andre.
>
> What?  So I don't need to do anything?
>
> Totally confused,

Sorry for that.

To fix the issue, we need only one of those patches.
Mine ("Fix crash as Xen Dom0 on AMD Trinity systems", removing "_amd" 
from the rd/wrmsr calls) was sent out earlier, so I added the stable tag.
A bit later Konrad sent his patch (1ab46fd319bc, initializing the 
forgotten PVOPS members), which hpa took (dropping mine). So this fix is 
in 3.5-rc1 and should also be in -stable.
Now for making things smoother Boris sent out mine again - for 3.6 - and 
more or less accidentally kept the stable tag in it.

Long story short: everything is fine, just apply the one you sent the 
review message for.

HTH,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 08:45:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08: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 1ScYLL-0004Zr-C9; Thu, 07 Jun 2012 08:45: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 1ScYLK-0004Zm-71
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 08:45:22 +0000
Received: from [85.158.143.35:29933] by server-1.bemta-4.messagelabs.com id
	CC/81-10042-12A60DF4; Thu, 07 Jun 2012 08:45:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339058719!14418101!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8069 invoked from network); 7 Jun 2012 08:45:19 -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 Jun 2012 08:45:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYLF-000INm-Rt; Thu, 07 Jun 2012 08:45:17 +0000
Date: Thu, 7 Jun 2012 09:45:17 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607084517.GA70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk
	of the hypervisor page 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

Hi,

At 15:39 +0000 on 01 Jun (1338565171), Ian Campbell wrote:
> +void dump_pt_walk(uint32_t addr)
> +{
> +    paddr_t second_ma, third_ma;
> +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> +    uint64_t httbr = READ_CP64(HTTBR);
> +
> +    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
> +           addr, httbr);
> +
> +    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
> +    first = xen_pgtable;
> +    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> +           first_table_offset(addr),
> +           first, first_table_offset(addr),
> +           virt_to_maddr(&first[first_table_offset(addr)]),
> +           first[first_table_offset(addr)].bits);
> +
> +    if ( !first[first_table_offset(addr)].pt.valid ||
> +         !first[first_table_offset(addr)].pt.table )
> +        goto done;

This could probably be a for loop rather than open-coding three
almost-identical printks.

> +
> +    second_ma = (paddr_t)first[first_table_offset(addr)].pt.base << PAGE_SHIFT;
> +    second = (lpae_t *)(unsigned long)(second_ma - xen_phys_offset);
> +    printk("2ND[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> +           second_table_offset(addr),
> +           second, second_table_offset(addr),
> +           virt_to_maddr(&second[second_table_offset(addr)]),
> +           second[second_table_offset(addr)].bits);
> +    if ( !second[second_table_offset(addr)].pt.valid ||
> +         !second[second_table_offset(addr)].pt.table )
> +        goto done;
> +
> +    third_ma = (paddr_t)second[second_table_offset(addr)].pt.base << PAGE_SHIFT;
> +    third = (lpae_t *)(unsigned long)(third_ma - xen_phys_offset);
> +    printk("3RD[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> +           third_table_offset(addr),
> +           third, third_table_offset(addr),
> +           virt_to_maddr(&third[third_table_offset(addr)]),
> +           third[third_table_offset(addr)].bits);
> +    if ( !third[third_table_offset(addr)].pt.valid ||
> +         !third[third_table_offset(addr)].pt.table )
> +        goto done;
> +
> +done:
> +    return;

Maybe use return above instead of goto?

> +}
> +
>  /* Map a 4k page in a fixmap entry */
>  void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
>  {
> @@ -173,8 +222,8 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
>      flush_xen_data_tlb_va(dest_va);
>  
>      /* Calculate virt-to-phys offset for the new location */
> -    phys_offset = xen_paddr - (unsigned long) _start;
> -
> +    xen_phys_offset = phys_offset = xen_paddr - (unsigned long) _start;
> +    

Just make phys_offset file-scope static; no need to add a new variable
for this.

>      /* Copy */
>      memcpy((void *) dest_va, _start, _end - _start);
>  
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index b6df64e..22c56b5 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -312,6 +312,8 @@ static inline uint64_t gva_to_ipa(uint32_t va)
>  /* Bits in the PAR returned by va_to_par */
>  #define PAR_FAULT 0x1
>  
> +extern void dump_pt_walk(uint32_t addr);
> +

Maybe a comment?

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 Jun 07 08:45:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08: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 1ScYLL-0004Zr-C9; Thu, 07 Jun 2012 08:45: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 1ScYLK-0004Zm-71
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 08:45:22 +0000
Received: from [85.158.143.35:29933] by server-1.bemta-4.messagelabs.com id
	CC/81-10042-12A60DF4; Thu, 07 Jun 2012 08:45:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339058719!14418101!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8069 invoked from network); 7 Jun 2012 08:45:19 -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 Jun 2012 08:45:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYLF-000INm-Rt; Thu, 07 Jun 2012 08:45:17 +0000
Date: Thu, 7 Jun 2012 09:45:17 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607084517.GA70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk
	of the hypervisor page 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

Hi,

At 15:39 +0000 on 01 Jun (1338565171), Ian Campbell wrote:
> +void dump_pt_walk(uint32_t addr)
> +{
> +    paddr_t second_ma, third_ma;
> +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> +    uint64_t httbr = READ_CP64(HTTBR);
> +
> +    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
> +           addr, httbr);
> +
> +    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
> +    first = xen_pgtable;
> +    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> +           first_table_offset(addr),
> +           first, first_table_offset(addr),
> +           virt_to_maddr(&first[first_table_offset(addr)]),
> +           first[first_table_offset(addr)].bits);
> +
> +    if ( !first[first_table_offset(addr)].pt.valid ||
> +         !first[first_table_offset(addr)].pt.table )
> +        goto done;

This could probably be a for loop rather than open-coding three
almost-identical printks.

> +
> +    second_ma = (paddr_t)first[first_table_offset(addr)].pt.base << PAGE_SHIFT;
> +    second = (lpae_t *)(unsigned long)(second_ma - xen_phys_offset);
> +    printk("2ND[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> +           second_table_offset(addr),
> +           second, second_table_offset(addr),
> +           virt_to_maddr(&second[second_table_offset(addr)]),
> +           second[second_table_offset(addr)].bits);
> +    if ( !second[second_table_offset(addr)].pt.valid ||
> +         !second[second_table_offset(addr)].pt.table )
> +        goto done;
> +
> +    third_ma = (paddr_t)second[second_table_offset(addr)].pt.base << PAGE_SHIFT;
> +    third = (lpae_t *)(unsigned long)(third_ma - xen_phys_offset);
> +    printk("3RD[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> +           third_table_offset(addr),
> +           third, third_table_offset(addr),
> +           virt_to_maddr(&third[third_table_offset(addr)]),
> +           third[third_table_offset(addr)].bits);
> +    if ( !third[third_table_offset(addr)].pt.valid ||
> +         !third[third_table_offset(addr)].pt.table )
> +        goto done;
> +
> +done:
> +    return;

Maybe use return above instead of goto?

> +}
> +
>  /* Map a 4k page in a fixmap entry */
>  void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
>  {
> @@ -173,8 +222,8 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
>      flush_xen_data_tlb_va(dest_va);
>  
>      /* Calculate virt-to-phys offset for the new location */
> -    phys_offset = xen_paddr - (unsigned long) _start;
> -
> +    xen_phys_offset = phys_offset = xen_paddr - (unsigned long) _start;
> +    

Just make phys_offset file-scope static; no need to add a new variable
for this.

>      /* Copy */
>      memcpy((void *) dest_va, _start, _end - _start);
>  
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index b6df64e..22c56b5 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -312,6 +312,8 @@ static inline uint64_t gva_to_ipa(uint32_t va)
>  /* Bits in the PAR returned by va_to_par */
>  #define PAR_FAULT 0x1
>  
> +extern void dump_pt_walk(uint32_t addr);
> +

Maybe a comment?

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 Jun 07 08:49:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScYPC-0004jZ-0Q; Thu, 07 Jun 2012 08:49:22 +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 1ScYPA-0004jT-U7
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 08:49:21 +0000
Received: from [85.158.138.51:64465] by server-3.bemta-3.messagelabs.com id
	20/E2-25608-E0B60DF4; Thu, 07 Jun 2012 08:49:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339058957!24858852!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3765 invoked from network); 7 Jun 2012 08:49:18 -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 Jun 2012 08:49:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYP7-000IOJ-Gv; Thu, 07 Jun 2012 08:49:17 +0000
Date: Thu, 7 Jun 2012 09:49:17 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607084917.GB70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
	of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> Useful for debug but not actually used in this patch.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/page.h |    1 +
>  2 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 4f624d8..fdbecbc 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -5,6 +5,40 @@
>  #include <xen/domain_page.h>
>  #include <asm/flushtlb.h>
>  
> +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> +
> +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> +
> +    first = __map_domain_page(p2m->first_level);
> +    printk("1ST[%#03llx] = %#016llx\n",
> +           first_table_offset(addr),
> +           first[first_table_offset(addr)].bits);
> +    if ( !first[first_table_offset(addr)].p2m.valid ||
> +         !first[first_table_offset(addr)].p2m.table )
> +        goto done;
> +
> +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> +    printk("2ND[%#03llx] = %#016llx\n",
> +           second_table_offset(addr),
> +           second[second_table_offset(addr)].bits);
> +    if ( !second[second_table_offset(addr)].p2m.valid ||
> +         !second[second_table_offset(addr)].p2m.table )
> +        goto done;
> +
> +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> +    printk("3RD[%#03llx] = %#016llx\n",
> +           third_table_offset(addr),
> +           third[third_table_offset(addr)].bits);
> +
> +done:
> +    if (third) unmap_domain_page(third);
> +    if (second) unmap_domain_page(second);
> +    if (first) unmap_domain_page(first);
> +}

Can this be unified with dump_pt_walk?  As it happens, the valid, table,
and base fields are the same in pt and p2m entries.

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 08:49:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 08:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScYPC-0004jZ-0Q; Thu, 07 Jun 2012 08:49:22 +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 1ScYPA-0004jT-U7
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 08:49:21 +0000
Received: from [85.158.138.51:64465] by server-3.bemta-3.messagelabs.com id
	20/E2-25608-E0B60DF4; Thu, 07 Jun 2012 08:49:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339058957!24858852!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3765 invoked from network); 7 Jun 2012 08:49:18 -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 Jun 2012 08:49:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYP7-000IOJ-Gv; Thu, 07 Jun 2012 08:49:17 +0000
Date: Thu, 7 Jun 2012 09:49:17 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607084917.GB70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
	of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> Useful for debug but not actually used in this patch.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/page.h |    1 +
>  2 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 4f624d8..fdbecbc 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -5,6 +5,40 @@
>  #include <xen/domain_page.h>
>  #include <asm/flushtlb.h>
>  
> +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> +
> +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> +
> +    first = __map_domain_page(p2m->first_level);
> +    printk("1ST[%#03llx] = %#016llx\n",
> +           first_table_offset(addr),
> +           first[first_table_offset(addr)].bits);
> +    if ( !first[first_table_offset(addr)].p2m.valid ||
> +         !first[first_table_offset(addr)].p2m.table )
> +        goto done;
> +
> +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> +    printk("2ND[%#03llx] = %#016llx\n",
> +           second_table_offset(addr),
> +           second[second_table_offset(addr)].bits);
> +    if ( !second[second_table_offset(addr)].p2m.valid ||
> +         !second[second_table_offset(addr)].p2m.table )
> +        goto done;
> +
> +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> +    printk("3RD[%#03llx] = %#016llx\n",
> +           third_table_offset(addr),
> +           third[third_table_offset(addr)].bits);
> +
> +done:
> +    if (third) unmap_domain_page(third);
> +    if (second) unmap_domain_page(second);
> +    if (first) unmap_domain_page(first);
> +}

Can this be unified with dump_pt_walk?  As it happens, the valid, table,
and base fields are the same in pt and p2m entries.

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:04:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScYd1-00053E-RK; Thu, 07 Jun 2012 09:03:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScYd0-00052W-5h
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:03:38 +0000
Received: from [193.109.254.147:27077] by server-2.bemta-14.messagelabs.com id
	A2/EA-27740-96E60DF4; Thu, 07 Jun 2012 09:03:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339059816!1674246!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32160 invoked from network); 7 Jun 2012 09:03:36 -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; 7 Jun 2012 09:03:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYcw-000IQe-LA; Thu, 07 Jun 2012 09:03:34 +0000
Date: Thu, 7 Jun 2012 10:03:34 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607090334.GC70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0000 on 01 Jun (1338565180), Ian Campbell wrote:
> +/*
> + * Lookup the MFN corresponding to a domain's PFN.
> + *
> + * There are no processor functions to do a stage 2 only lookup therefore we
> + * do a a software walk.
> + */
> +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> +    paddr_t maddr = INVALID_PADDR;
> +
> +    spin_lock(&p2m->lock);
> +
> +    first = __map_domain_page(p2m->first_level);
> +    if ( !first[first_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !first[first_table_offset(paddr)].p2m.table )
> +    {
> +        pte = first[first_table_offset(paddr)];
> +        goto done;
> +    }

This would be neater as: 
       pte = first[first_table_offset(paddr)];
       if ( !pte.p2m.valid || !pte.p2m.table )
           goto done;

and test for pte.valid at 'done'.

It would be nice to do the three levels in a loop as well, but the weird
way the table bit behaves in third-level entries might make that more
confusing than the straight-line 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 Jun 07 09:04:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScYd1-00053E-RK; Thu, 07 Jun 2012 09:03:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScYd0-00052W-5h
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:03:38 +0000
Received: from [193.109.254.147:27077] by server-2.bemta-14.messagelabs.com id
	A2/EA-27740-96E60DF4; Thu, 07 Jun 2012 09:03:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339059816!1674246!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32160 invoked from network); 7 Jun 2012 09:03:36 -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; 7 Jun 2012 09:03:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYcw-000IQe-LA; Thu, 07 Jun 2012 09:03:34 +0000
Date: Thu, 7 Jun 2012 10:03:34 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607090334.GC70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0000 on 01 Jun (1338565180), Ian Campbell wrote:
> +/*
> + * Lookup the MFN corresponding to a domain's PFN.
> + *
> + * There are no processor functions to do a stage 2 only lookup therefore we
> + * do a a software walk.
> + */
> +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> +    paddr_t maddr = INVALID_PADDR;
> +
> +    spin_lock(&p2m->lock);
> +
> +    first = __map_domain_page(p2m->first_level);
> +    if ( !first[first_table_offset(paddr)].p2m.valid )
> +        goto done_err;
> +    if ( !first[first_table_offset(paddr)].p2m.table )
> +    {
> +        pte = first[first_table_offset(paddr)];
> +        goto done;
> +    }

This would be neater as: 
       pte = first[first_table_offset(paddr)];
       if ( !pte.p2m.valid || !pte.p2m.table )
           goto done;

and test for pte.valid at 'done'.

It would be nice to do the three levels in a loop as well, but the weird
way the table bit behaves in third-level entries might make that more
confusing than the straight-line 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 Jun 07 09:08:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScYhQ-0005E6-Hd; Thu, 07 Jun 2012 09:08:12 +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 1ScYhO-0005Dz-C4
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:08:10 +0000
Received: from [85.158.143.35:17586] by server-1.bemta-4.messagelabs.com id
	D2/DB-10042-97F60DF4; Thu, 07 Jun 2012 09:08:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339060088!11245975!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2335 invoked from network); 7 Jun 2012 09:08:08 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:08:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYhM-000IRg-Bk; Thu, 07 Jun 2012 09:08:08 +0000
Date: Thu, 7 Jun 2012 10:08:08 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607090808.GD70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,
	core}_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

At 15:39 +0000 on 01 Jun (1338565185), Ian Campbell wrote:
> @@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
>          }
>      }
>  
> +    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
> +         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
> +        BUG();
> +
> +    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
> +    cpumask_clear(per_cpu(cpu_core_mask, 0));

Aren't these clear()s noops?  

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:08:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScYhQ-0005E6-Hd; Thu, 07 Jun 2012 09:08:12 +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 1ScYhO-0005Dz-C4
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:08:10 +0000
Received: from [85.158.143.35:17586] by server-1.bemta-4.messagelabs.com id
	D2/DB-10042-97F60DF4; Thu, 07 Jun 2012 09:08:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339060088!11245975!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2335 invoked from network); 7 Jun 2012 09:08:08 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:08:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScYhM-000IRg-Bk; Thu, 07 Jun 2012 09:08:08 +0000
Date: Thu, 7 Jun 2012 10:08:08 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607090808.GD70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,
	core}_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

At 15:39 +0000 on 01 Jun (1338565185), Ian Campbell wrote:
> @@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
>          }
>      }
>  
> +    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
> +         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
> +        BUG();
> +
> +    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
> +    cpumask_clear(per_cpu(cpu_core_mask, 0));

Aren't these clear()s noops?  

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:24:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScYwv-0005pW-HX; Thu, 07 Jun 2012 09:24:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1ScYwt-0005or-OO
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:24:12 +0000
Received: from [85.158.143.35:50800] by server-2.bemta-4.messagelabs.com id
	36/E8-17938-93370DF4; Thu, 07 Jun 2012 09:24:09 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339061047!4741589!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9956 invoked from network); 7 Jun 2012 09:24:08 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:24:08 -0000
Received: by ghrr14 with SMTP id r14so252046ghr.32
	for <multiple recipients>; Thu, 07 Jun 2012 02:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BgF56tB79ocML0suJkg4jkjEqu8WCYGoLDR7cjpr3Ik=;
	b=bY+f3wW/wB4vWS6p5MNRlLmWMmfGF6EPboBb4F0JK/kCSRurqdxrBaIFdob7V4y+83
	B3+jQKajYDgRFtoF7REwzC7N37TxcLmP/YC3BrNFhvA4YlGpUdlD+jAz3QvJbcPjhh1g
	xgtFSRSq3hluyHHh6CPH3bJpskTO16r/5K+ifdS1zD2C90SqPlwamuKiXvDqu1EtAZPr
	ud+M1BnRdSrhvKQcTRHV3e0wme3OGiIcEMUrch7dGr76G06+yEHerhZQNM17RtiGcGwx
	NYQLJVEo/q1vpY4GiTELwsYkmoRewvfgL8AQFIuElrmLTuUqrGdl/97MXcGN9ZoDe/Nd
	cQXw==
MIME-Version: 1.0
Received: by 10.42.153.10 with SMTP id k10mr754364icw.24.1339061047023; Thu,
	07 Jun 2012 02:24:07 -0700 (PDT)
Received: by 10.231.205.208 with HTTP; Thu, 7 Jun 2012 02:24:06 -0700 (PDT)
In-Reply-To: <CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
Date: Thu, 7 Jun 2012 10:24:06 +0100
Message-ID: <CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: Rolu <rolu@roce.org>
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0507940380651415575=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0507940380651415575==
Content-Type: multipart/alternative; boundary=90e6ba2121f70a574404c1de726b

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

Rolu,

thanks for the feedback.


xen" and "help with xcp" it would be nice if there were a few lines at
> the top of the page explaining which is which, so (new) people can
> have a better idea of where to look.


So you mean a link to Xen and XCP from the headline, or a tagline
describing what Xen/XCP is? Two lines are probably OK; more would probably
break up the navigation too much.


> The descriptions from
> http://xen.org/products/ and a link to
> http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
> The latter is already linked in the "getting started with xen" column
> but would be better off at the top since it gives a feature table of
> both.
>
I am wondering whether Xen Features / XCP Features in one of the boxes
would not be better.


> As someone who started with Xen not long ago, I much prefer dedicated
> link pages over Category: pages. The latter just give a big unsorted
> (alphabetical doesn't count, needs to be sorted by subtopic to be a
> useful sort) list of pages of widely varying scope and usefulness.
> It's better than nothing, sure, but a page that sorts them by topic or
> purpose or something (much like this proposed front page really) is a
> lot better.
>
How about a compromise? Category pages have two parts:
1) A fixed part that can be used for any content, such as lists of
important articles by topic or other ciriteria
    An example of this is
http://wiki.xen.org/wiki/Category:Host_Install(and some of the pages
linked from it)
2) The auto-generated index

I know that some people are don't like category pages. However, until
somebody steps up and provides an alternative, which to do well requires
a) Classifying articles
b) Grouping them by topic or purpose
c) Encoding that grouping in some manual index
d) Keeping these up-to-date

... the category pages are all we have and are a lot better than what we
had in the old wiki. And they are self-maintaining.

The fact that we are having this discussion is actually good. I am open to
suggestions and maybe we just need a small number of manually maintained
indexes (or categories with maintained content at the top). Maybe to make
this really work and get better navigability we need some degree of
ownership in the wiki: i.e. community members owning content, categories,
etc. and being responsible for classifying, grouping and making it more
accessible.

I also started experimenting with shortcut boxes on pages such as
http://wiki.xen.org/wiki/Xen_Overview &
http://wiki.xen.org/wiki/Getting_Started and wanted to know what people
thought of these and whether these improve navigability.

Lars

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

Rolu,<br><br>thanks for the feedback.<br><br><div class=3D"gmail_quote"><br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
xen&quot; and &quot;help with xcp&quot; it would be nice if there were a fe=
w lines at<br>
the top of the page explaining which is which, so (new) people can<br>
have a better idea of where to look.</blockquote><div><br>So you mean a lin=
k to Xen and XCP from the headline, or a tagline describing what Xen/XCP is=
? Two lines are probably OK; more would probably break up the navigation to=
o much. <br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The description=
s from<br>
<a href=3D"http://xen.org/products/" target=3D"_blank">http://xen.org/produ=
cts/</a> and a link to<br>
<a href=3D"http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview" targ=
et=3D"_blank">http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview</a=
> would work.<br>
The latter is already linked in the &quot;getting started with xen&quot; co=
lumn<br>
but would be better off at the top since it gives a feature table of<br>
both.<br></blockquote><div>I am wondering whether Xen Features / XCP Featur=
es in one of the boxes would not be better.<br>=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

As someone who started with Xen not long ago, I much prefer dedicated<br>
link pages over Category: pages. The latter just give a big unsorted<br>
(alphabetical doesn&#39;t count, needs to be sorted by subtopic to be a<br>
useful sort) list of pages of widely varying scope and usefulness.<br>
It&#39;s better than nothing, sure, but a page that sorts them by topic or<=
br>
purpose or something (much like this proposed front page really) is a<br>
lot better.<br>
</blockquote>How about a compromise? Category pages have two parts: <br>1) =
A fixed part that can be used for any content, such as lists of important a=
rticles by topic or other ciriteria<br>=A0=A0=A0 An example of this is <a h=
ref=3D"http://wiki.xen.org/wiki/Category:Host_Install" target=3D"_blank">ht=
tp://wiki.xen.org/wiki/Category:Host_Install</a> (and some of the pages lin=
ked from it)<br>

2) The auto-generated index <br><br>I know that some people are don&#39;t l=
ike category pages. However, until somebody steps up and provides an altern=
ative, which to do well requires<br>a) Classifying articles<br>b) Grouping =
them by topic or purpose <br>

c) Encoding that grouping in some manual index<br>d) Keeping these up-to-da=
te<br><br>... the category pages are all we have and are a lot better than =
what we had in the old wiki. And they are self-maintaining. <br><br>The fac=
t that we are having this discussion is actually good. I am open to suggest=
ions and maybe we just need a small number of manually maintained indexes (=
or categories with maintained content at the top). Maybe to make this reall=
y work and get better navigability we need some degree of ownership in the =
wiki: i.e. community members owning content, categories, etc. and being res=
ponsible for classifying, grouping and making it more accessible.<br>

<br>I also started experimenting with shortcut boxes on pages such as <a hr=
ef=3D"http://wiki.xen.org/wiki/Xen_Overview" target=3D"_blank">http://wiki.=
xen.org/wiki/Xen_Overview</a> &amp; <a href=3D"http://wiki.xen.org/wiki/Get=
ting_Started" target=3D"_blank">http://wiki.xen.org/wiki/Getting_Started</a=
> and wanted to know what people thought of these and whether these improve=
 navigability.<br>
<br>Lars<br>
</div><br>

--90e6ba2121f70a574404c1de726b--


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

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

--===============0507940380651415575==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 09:24:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScYwv-0005pW-HX; Thu, 07 Jun 2012 09:24:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1ScYwt-0005or-OO
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:24:12 +0000
Received: from [85.158.143.35:50800] by server-2.bemta-4.messagelabs.com id
	36/E8-17938-93370DF4; Thu, 07 Jun 2012 09:24:09 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339061047!4741589!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9956 invoked from network); 7 Jun 2012 09:24:08 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:24:08 -0000
Received: by ghrr14 with SMTP id r14so252046ghr.32
	for <multiple recipients>; Thu, 07 Jun 2012 02:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BgF56tB79ocML0suJkg4jkjEqu8WCYGoLDR7cjpr3Ik=;
	b=bY+f3wW/wB4vWS6p5MNRlLmWMmfGF6EPboBb4F0JK/kCSRurqdxrBaIFdob7V4y+83
	B3+jQKajYDgRFtoF7REwzC7N37TxcLmP/YC3BrNFhvA4YlGpUdlD+jAz3QvJbcPjhh1g
	xgtFSRSq3hluyHHh6CPH3bJpskTO16r/5K+ifdS1zD2C90SqPlwamuKiXvDqu1EtAZPr
	ud+M1BnRdSrhvKQcTRHV3e0wme3OGiIcEMUrch7dGr76G06+yEHerhZQNM17RtiGcGwx
	NYQLJVEo/q1vpY4GiTELwsYkmoRewvfgL8AQFIuElrmLTuUqrGdl/97MXcGN9ZoDe/Nd
	cQXw==
MIME-Version: 1.0
Received: by 10.42.153.10 with SMTP id k10mr754364icw.24.1339061047023; Thu,
	07 Jun 2012 02:24:07 -0700 (PDT)
Received: by 10.231.205.208 with HTTP; Thu, 7 Jun 2012 02:24:06 -0700 (PDT)
In-Reply-To: <CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
Date: Thu, 7 Jun 2012 10:24:06 +0100
Message-ID: <CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: Rolu <rolu@roce.org>
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0507940380651415575=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0507940380651415575==
Content-Type: multipart/alternative; boundary=90e6ba2121f70a574404c1de726b

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

Rolu,

thanks for the feedback.


xen" and "help with xcp" it would be nice if there were a few lines at
> the top of the page explaining which is which, so (new) people can
> have a better idea of where to look.


So you mean a link to Xen and XCP from the headline, or a tagline
describing what Xen/XCP is? Two lines are probably OK; more would probably
break up the navigation too much.


> The descriptions from
> http://xen.org/products/ and a link to
> http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
> The latter is already linked in the "getting started with xen" column
> but would be better off at the top since it gives a feature table of
> both.
>
I am wondering whether Xen Features / XCP Features in one of the boxes
would not be better.


> As someone who started with Xen not long ago, I much prefer dedicated
> link pages over Category: pages. The latter just give a big unsorted
> (alphabetical doesn't count, needs to be sorted by subtopic to be a
> useful sort) list of pages of widely varying scope and usefulness.
> It's better than nothing, sure, but a page that sorts them by topic or
> purpose or something (much like this proposed front page really) is a
> lot better.
>
How about a compromise? Category pages have two parts:
1) A fixed part that can be used for any content, such as lists of
important articles by topic or other ciriteria
    An example of this is
http://wiki.xen.org/wiki/Category:Host_Install(and some of the pages
linked from it)
2) The auto-generated index

I know that some people are don't like category pages. However, until
somebody steps up and provides an alternative, which to do well requires
a) Classifying articles
b) Grouping them by topic or purpose
c) Encoding that grouping in some manual index
d) Keeping these up-to-date

... the category pages are all we have and are a lot better than what we
had in the old wiki. And they are self-maintaining.

The fact that we are having this discussion is actually good. I am open to
suggestions and maybe we just need a small number of manually maintained
indexes (or categories with maintained content at the top). Maybe to make
this really work and get better navigability we need some degree of
ownership in the wiki: i.e. community members owning content, categories,
etc. and being responsible for classifying, grouping and making it more
accessible.

I also started experimenting with shortcut boxes on pages such as
http://wiki.xen.org/wiki/Xen_Overview &
http://wiki.xen.org/wiki/Getting_Started and wanted to know what people
thought of these and whether these improve navigability.

Lars

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

Rolu,<br><br>thanks for the feedback.<br><br><div class=3D"gmail_quote"><br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
xen&quot; and &quot;help with xcp&quot; it would be nice if there were a fe=
w lines at<br>
the top of the page explaining which is which, so (new) people can<br>
have a better idea of where to look.</blockquote><div><br>So you mean a lin=
k to Xen and XCP from the headline, or a tagline describing what Xen/XCP is=
? Two lines are probably OK; more would probably break up the navigation to=
o much. <br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The description=
s from<br>
<a href=3D"http://xen.org/products/" target=3D"_blank">http://xen.org/produ=
cts/</a> and a link to<br>
<a href=3D"http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview" targ=
et=3D"_blank">http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview</a=
> would work.<br>
The latter is already linked in the &quot;getting started with xen&quot; co=
lumn<br>
but would be better off at the top since it gives a feature table of<br>
both.<br></blockquote><div>I am wondering whether Xen Features / XCP Featur=
es in one of the boxes would not be better.<br>=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

As someone who started with Xen not long ago, I much prefer dedicated<br>
link pages over Category: pages. The latter just give a big unsorted<br>
(alphabetical doesn&#39;t count, needs to be sorted by subtopic to be a<br>
useful sort) list of pages of widely varying scope and usefulness.<br>
It&#39;s better than nothing, sure, but a page that sorts them by topic or<=
br>
purpose or something (much like this proposed front page really) is a<br>
lot better.<br>
</blockquote>How about a compromise? Category pages have two parts: <br>1) =
A fixed part that can be used for any content, such as lists of important a=
rticles by topic or other ciriteria<br>=A0=A0=A0 An example of this is <a h=
ref=3D"http://wiki.xen.org/wiki/Category:Host_Install" target=3D"_blank">ht=
tp://wiki.xen.org/wiki/Category:Host_Install</a> (and some of the pages lin=
ked from it)<br>

2) The auto-generated index <br><br>I know that some people are don&#39;t l=
ike category pages. However, until somebody steps up and provides an altern=
ative, which to do well requires<br>a) Classifying articles<br>b) Grouping =
them by topic or purpose <br>

c) Encoding that grouping in some manual index<br>d) Keeping these up-to-da=
te<br><br>... the category pages are all we have and are a lot better than =
what we had in the old wiki. And they are self-maintaining. <br><br>The fac=
t that we are having this discussion is actually good. I am open to suggest=
ions and maybe we just need a small number of manually maintained indexes (=
or categories with maintained content at the top). Maybe to make this reall=
y work and get better navigability we need some degree of ownership in the =
wiki: i.e. community members owning content, categories, etc. and being res=
ponsible for classifying, grouping and making it more accessible.<br>

<br>I also started experimenting with shortcut boxes on pages such as <a hr=
ef=3D"http://wiki.xen.org/wiki/Xen_Overview" target=3D"_blank">http://wiki.=
xen.org/wiki/Xen_Overview</a> &amp; <a href=3D"http://wiki.xen.org/wiki/Get=
ting_Started" target=3D"_blank">http://wiki.xen.org/wiki/Getting_Started</a=
> and wanted to know what people thought of these and whether these improve=
 navigability.<br>
<br>Lars<br>
</div><br>

--90e6ba2121f70a574404c1de726b--


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

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

--===============0507940380651415575==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 09:29:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ2B-0006OT-Es; Thu, 07 Jun 2012 09:29:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1ScZ29-0006OI-09
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 09:29:37 +0000
Received: from [85.158.139.83:60763] by server-12.bemta-5.messagelabs.com id
	AA/B9-18374-08470DF4; Thu, 07 Jun 2012 09:29:36 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339061374!31859645!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8336 invoked from network); 7 Jun 2012 09:29:35 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:29:35 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id EC02ED0
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 13:29:33 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id gB-6XRnRs363 for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 13:29:33 +0400 (MSK)
Received: from sysadmin.office.main.elserv.ru (sysadmin.office.main.elserv.ru
	[192.168.3.135]) (Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id 85CC919
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 13:29:33 +0400 (MSK)
Message-ID: <4FD0747D.10103@elserv.ru>
Date: Thu, 07 Jun 2012 13:29:33 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary="------------000802070202030103090808"
Subject: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------000802070202030103090808
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi people,

I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on 
IBM eServer x3400. Without noacpi command line option dom0 kernel 
crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen 
patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor 
all kernels run without any problems.

There are several patches (available on 
http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/kernel-image-xen-dom0, 
commits f1f91babc9cc9402ccee8938b888240f5bae1574, 
72db7b5e069002765ced64f030c1117d72352331, 
adc4c567a08d4d2377060179639cbfdc3d9d8e0e and 
9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32 to 
boot on this hardware. This patches written by kernel package maintainer 
of ALT Linux distribution. Discussion of this issue is available on 
Sysadmins ALTLinux mailing list 
(http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html 
and follows) in Russian.

I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need this 
messages for more recent versions of Xen and kernel, or more information 
about hardware, please let me know.

Ideally, I would like to run current versions of Xen and Linux kernels 
on this hardware. Can you help me please?


--
  WBR, Alex Moskalenko

--------------000802070202030103090808
Content-Type: application/x-bzip;
 name="crash.acpi.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="crash.acpi.bz2"

QlpoOTFBWSZTWU4ENtgACa/fiP/1bP/////v//7////0IAAAAOAkvHDk++7x7M+BJ9V3sAMT
Xvvfe0fe8++NrTJpPtxa6rdnRzYQqlRKzQz3vKetHoJV5wceXu7nXe9571zrYO7DrZqdUdN6
1c9ui7aIlAC7G773hCAPPhKIEATE00CZMVT/BNGkNMJG1NNqejUQ8hGmm1DRpkAlBABJkTU9
J6NVP1T09E00TymGoYTaIDEANANBoAamaImgmmkNNR6nppGho0Gjaj1B6RoAAAGmgNACTSiJ
Dagmg1NoRgFGjQ2k9TyMk0epoD1ANGgaA9QEUhSn6iPyFGQ2oA8o8p6mg0NNAeoPU/VA0aDQ
AAMgkSAgECDTSaNCaMmjRlTyJ5TI0aNqGI0zUaZNA006YEOQhIQ/W0FgykggUgQaMpUksYtQ
rILIpCAdiMEZArAjMDZVgAFoEFRkQQUjH2he149/Pw/fIBB5psWuXdeUsNk212J3T7/xwa/w
eXr27LQNtB0UiMbgAwhJK0AenF8ZPqKNaMke/H7O7iZo6TW0MzuAGkr4H9JWSJKRucLh/e/L
kaYgLt7HSmrcBBa2IGQZVBZQAKSsKrFvXZ46+lEpAKmOpTp8OS88apcvG8rDW3Wll4k8sMd5
jjHN9OHJuXU+t+78giT4Kqqu7g9Nb1hnakNuS/WuSg2J630srDmlNYylrO2k5NGnbJuEdvHD
h0ttD+j7n3XaNNpEuYqvA0bxkgMzTKFSClBQkKq13Et196p3giBtRZIKK1V9BpJraAjYtRvE
TRLbTGi5EwMVXA0pGSAzljZZMxZsxZ5/Jn1c+lgDgCAF+2cd2VMf00SAByQKAPyEUTSns7fn
wFAyZ79069H8/TZrpfCPWUZGqqs/yMIbPPXX3uE0CqTVxDYPGhfbWOkVZgnBYbevhXBozSnQ
1DoM+UDFTByU6RMjiAdZgQnL0adQ5qb9b5XPbvgrvxhVVVZPBp3Tg/T8WnOdU9/vbHqO0ncE
RERERERETm3fwIXSrQRA3ZUpGjc2JLtKEbPUL5zKrMCQ2jilgkYqk7WZS0V8RqOqBg+Qc98u
QuuCIo44yiv6RSQqITmTc6Ax8XbEiWKfBTflufiY7+/t/hQSrfT7pHViaHj73+p7PJ9/QdDl
x5/I+N5j0nmvqwH2uGmatbcRomL5Znx+bHX3G7d8GDGKW0tottLZRtLarG02K1fUqIy5hqiE
OZrDY1ycJYvMZAIPtwRlbp53Knri8/ZUnSzKdkmSZVUWJh1NGaqPtDV4uQjiDcpf2/pj25YJ
6p5cA42rmxL9Stuz/TzX3nhf50bZXXmQNnea23+cslmQkU+hYVDx5yi4bHDSutvpz6qahXgE
dEsssUF/ZVZiXbkOWSSOSfGuWF6qOLOlAGwPawz75iaSTBFXzTXZ9V2n6Cr0Tk4ZO/8PuzTV
mWLjJW3znD9NqruRKjPNlKM3o1haX/T5HyY76uHj2CTw/F7x7e1uNVVRVRFFViqqqqqqqqqq
qqoqqp/fg/Z9Op8J5eINwFchBJpmZF6l7kxdfe3vxX5aiQwt3vZSKZ4dbVROluABwAb2KdDS
IUJpZN7plVWgS3/OBZGQIl6LWd43pwyJlrtts+Ip985ui3/jvT44Ckqr7euVH7DkxmHHI8F8
rgOzsHtjCkUFExY3FxSJAgYmgxKqJW23NeXLPiUSVXCiv2TX4OQEwBfpsBbAtKnhh0br0sE+
g3trrwmcs83CWapDN3sP27S6LMXZp48n7rbZXqoY+gzrppocnXiHcIbD7UWYDC1HPOQcCAHU
AkG2QiwNmhoO2QGEgGpJ1UmbKb5fEHIuxBXAw87BY/SqXmxLaNztl2f4fcU7sMyPknVqc7GO
gsznKaJ9TYHOvdoAcT0segjYU00rwXk5WPXQuxfWuZfYuy6V80skkV5CNUBBM2pPe0U9/wmc
O8hWK9hg7hQX64Qfk9nvn2XpgQmFAVVVFBUROkNrA4Gi/jzzajoddQG3rOWNJ7XfcUfHaXbr
/VRSWxvslZcV9hGWK8LQOa1MJqNc8e7fA7vWB6QMwF6TMiMNBWcp5qYXDV0HzwHxFvFpNKZI
MVEYzDE3E6ok9Nhpj5aLvmnh66aFqH1Bpbt8nCZEcRnDB19V1vZghMp+qIH8sLnqIG778dQY
gFo7Yqb+rc3JbcQVME+PC7hhINGKDsrYGu4DkTpLfnsdZZC2yglnbuKUmDFCMLo4Yk3togAb
ElSLdqkrKlqlJ/sod03uSo2sndreBxNOqOkIqqXA75NGrG+F5bS4dr2NutkQO/ZP77TTfcAq
kfX7O4pukRLS9RbOhXNur5u6SaQfpz5YlXvzr6esnu9f3Dv9uNxcdVIQwtuZLkn0UrpWlyiP
zMXc8Fo08vsY8ni9B5GOWS48TnJtd1ZPfw+0be5iS4UpOYw6hrpqGZumgld6Ly7nvvQ6MrPm
O3unybr2i/gpzs2Yt6J48HVmxTa0jOALMuB2Ks/O83ecAZVSYKiezSQXLLAgl83UrL4RfE0G
7SI3QkmlI1JPhsAaScRaNGy3mDeIqKoTZ/DwUVf1YxE9HraE16vR3tBYeq0UUUUUPACHmTcn
5ONIW1QTdgRa7KKA2aGj4ZpOHR58W008sLSdeJw7JHt3A+FaGmjiP9O5dz1iAqJDOT2e6e2t
CBturX3fR++v2CA0+HD5vnPWVSNWhC+tpAXawPsIm0Xch+9ASJRURRS/4vOY7jEHedxjDiGR
jxwpERjOeIcIHeRkLM+IiQDiCkz/pI9yhM0GmYFIDhw0KQWB84weSzYrMasTQd/qik5dF2yv
8TlPEBtEyrMRH8NsOF1EkN7p5Jfc+3vVZE2KO92wQRFYxjePpM/4DuTIMGRoH4tVUPPm79P1
mm9F6pzN/M0aIJUUQ+o4idvwJIX9aihAUPHLdd88WHkqWhMwZisIxIIDnk1aWOKIwwKqnAIV
ULhIyME4J1PUq5JreNsLS5ju+qM8TbepvDrNjv9ZuPuOAzqLGB7zrIxb9pE74OUok8vcDxM7
DZQKW0bsQOFQZMuZmZUsGbL2lbd5TjPN8Pkhz853uKEhCdvnAbc2vWHPkv1a5Z4ODJRaMsG1
XeHFt9PBbBGFYWiM1upmvSTwnB1iF2bqhi+LAGaseE8DB5lGiwgKKVlVme7bn8u9kpvaCmTx
tzItv8ta/Z/yyBHdoUrpIKKrEn9Gik3/S3uK+H5DD8PtjBXh5kjkSSwX1oQkdBoDexCAqkHy
HuCE3EIQnImrVRd6QgusGelRRiowEIXl8vkxjDzHKwBQndnabEyDLtMTIkYHocCGMkKyoSph
EJk8LEHTtXUkBDkQJ7z+4siaSFoxCwxS3kEEFsySkUrmdZRXeBiMx8RCSsWxG3CuYNsGY3A8
7P0txF7KgupTjKhsay7qEhxxAPYklEERM64MAiMDV59Lsl5t+m2uLdNNNgkmRJAoNdYLKt12
Kk4QWZRgpkMnKBqhIgymJSkb0IIiVy0ibMJFShFKIoxNgCVxOaQ1brJAoimxAIOxoXs/EqDi
o+JsODoKDCXZOIemlpmgnVguyMJDeQ4HiXgkywtNpQypQzypQxUyAuGDKIldAxLLKCbzEmCD
Ky4mS6Ir0LCaPkogsitsnWVEo4spifVXdEjZS2mr3E3CVIQm4yxEVJqPhmK/LxmaylMVrTgP
0DST2JWVYf9Y1aTEpWUJ8XMEEDGAqAJb1sMi8IoWZ42JnrNwRAwO9aG4kHn2v+0SpNn4nJsE
J5QLE0IMQS0omAClEiiCAgiJDDKMqamJZAVMJYCWUKCJUKJKwoMUiJ0JSIIjGDGIkUGMenVt
KXS/smlPubll7dzaOE/tAFa5FVVVVI2i/M0YUKc35+wocGkxHIbis5VTLZzyN+qdPR4cOxw+
mhH7yYyFk1e3AJD3x5TlSxY5SSVWIL2cB0Cs5SIS3+SAlCdJwo4x6j7D0hcmWpUgBFqxUSJM
SH8l5CUuY/PIIYp4XWIqfKGuIFy6i1rxM+iqLaN2fBJ81qye0SJMOI1dPM5ZCyNbwFqHrJCz
rMlMgmAIxiaiQklMmGMy2Nw/O2NE33pr27XoKDUTnaJMyTbjcEFKgDUKEQnN1SybJMiaoabY
g6GTeengpgNJqKKNnYR8xMpvO/Ld0xkuWzdb76xzwu3tz9gGxNYMxPhjBi1P1MsUAgDfwGgc
V3V8vLfa8Hi7mrWWSVoRciddLilONXPD3RqirAsMHMgHsxgaQMnJjeMStVYXc3o4ENiwjYoT
E15u65xM78Y/hQzwIJmw5DabsTkd3rJrSfEiLA+wWseNOuD/zz9naYFyDw3oDJ6i0toJa0Jh
TuLHQmVGY9eZy7yki5e6GiiNLKIyNrbkqyOkdY+QkI5YnSPJW7+G5tpSM1C1FpXcWvbmDNhv
FtuMnJRpLLV9jhxeSLEOVYiYpiQCBAZm2O8xAXqGTlUmvYV2gGxsmlznHxc7nfI1J6mANpeI
+BkYGlwoeiA0eLMrEIhtreMUEHyTJBIgWIyBjKdzQu4tFMPLu6tdG5V762vF5zCHWVSRMXQt
dvAUdmj/du8tIGJcIzH7htqRsCSohFGBDSiHcjWXEpD/w3VW2ZUKrZguR1xcgeGixQaOXAah
XoQHWHceIRyklEptqj1FlRy8hjl2yH7Rih8N9AJXffcmJENgUJdNxAgfcqlSZKpA8QWp0l0l
FVZaxospKeSlJ215EdDBBDIrOo1mc5G0dyxpVZkinMVpoUN83riUX13BRudygWsPuVCYyum5
yFBVGYzAejmLuFEiLKe/NnrLjtys7vlM0jS/0NjdB8WZvi3cEwVONYbPeQZPqC5AnbzrKQNv
2wUduVAJdVJBSOpQgW7FWdJ06Dm5yJ4Jv3FeolAoFB8jIwOSp5WTS+xOZSiDTQ7nlOYWUqcy
gaqMZwRAniXbSH06T4gdoRKmxkbGuyUnrKeBNrWYp6XrauojwZiicSJe9dxklcrExMwXtGB5
K8IgScMFtM4S0IBkVe2mhRg2dGOeOJ5B5Zp744W00ry5ZaBaMDsNjlo07DMAmHASQMeHowF3
mtKAijprjtaB4CuKMzO6pihBRiBH1FCEH1HGOBQvkZoywIiJbTqPjK4Doa6zZXZ0Tbgvb3CI
YqqpbZL+CIpUK8oHQmGxuqdRFWu3vzQY4KLE572oHlaf0weBoYOzgIGayfMg7By22Jm/F3su
p61gpRaFGw5SiwbUmKZOCFIyFEdqEymhLp8AVRlQTlSzkypk1/DqVWjafa5h4t6/DhH0XRsf
4fERpbP752YFArxsL+TM2GWDGfkSz2fCCeoqE5UfxL7jA5GDmgGsyAPxH5t+x2UaxqfdvvQ/
baF+thsxKABoAmUSRUaB7FAYGmmpoXuxGI6r91dnxC41ka2TrYuueUz2yLmdg27c+q98L351
GDAZW+4vmbThblvYWzd7Nzr8IPZtAY05Lhz+vL0oesARFBhzVG8Xdg/68pTAYTITIh1Ig40E
0LTtGEekuPpRNCkwg1VYdzDGnIZAaMLDkVEyUp5CBzIDECBxJjjkjtLkjYwXIFzB0FFMk8Fy
RiZK5kwKOE61qGhuROSCJxIy3jlauanLxEmjt6HcILSCCEUJFcstRq9aNicFnV23nKHTvsNa
bgDeFNkKDIIYAL7U4XXP2YeQoBrgeiH+7hT7mg6xmgM9we+DPH/WRJpTEj8nxDZFxiNzSOB3
6z9RnU/V4EhHg+xLftJwkiDIHMgB7HrM1GHumpf67jYIJMQh844x4/kYFWnrjQsBbe8mIJS4
9f6K4yi5YDmMV2oAmVkIwz7+T7W/zl+z5sB9CCzwMM+JsfjQCCDBa3txe16SrY6WWZ4eFOdM
6iMcC2WIFoGCayhGG4w4FyEsm1QZdkc/IfGYzNLP68EFD6YDZkvlg9wMCAZ5ZMBkBMmbmZCl
YSTAIRH3zgEie0CROYBsU0rHXpzsXi0hLJoXA5w5Qjzvky5rCQe5i4JeZJvDbhMCKbDW47Rh
IjYL0AXtpxoTACxB7MIhzqUBQCwYa00kOTY1NeKp4SMyoeMUTfxtdUgZOfa51oBkp8kCxxEQ
PCD0tZcD2yFpddaaSQH8Jc6cpIyPRSnkAHVjpcsDYpoMNJIaceEAttuB1aPuIVzkXNTq6PXe
J1mFWGORpFNzF0aLUeuAiQ/4sP1DwQhHJABCV88JICgITcmiAD9Q0JcEuYstakctfcXKb4Ey
E2zkr50Dc4zIU2XEkMTUtOWu1U1RHIJM6CoPkjS5xPUT476a4a1eAtE5Rlv51X58Nf6zghKb
M1zwkwFI9OqNRQThEgqdBdu0y7F8Q0szg1xjaSl8ufDwMt2e6+BBSfAiN8XVblwTlY5/O4Oa
jAixAWWv4/DO3cMJMPWGsUHbaEhHh0I56GF+NCCPxkKSGkvMMmKhCV16mC7XTaqOcKgcQki6
+m8W9QooolkhXkFZmBHOAZwiZR8tVTtQCjmqkp0MOP67BhhtS2j6ZcMxiQrBNbCNn02rFVRE
FVRVVVVVVVVVVVVVVVVVVVVVWCoiuGgJgJLgWB4mAfdYOtNX8TdZMslZ60JYq5giG6+fEqZk
VZwWaJn0XhTGueC5y+i4ZhJd0mgqkFS6ICfHgoPaLCKVtESAhCpG1b1xacJxnKc5pT1GSEK0
na1pznOc5zskmiYFwJUqVJEyRUsXuNYGLKgyCkwHqwDMvV7vU5EY4C2Yfeo32r9rWLd/baNG
rjznUdBuNQiDRPlFNIorMzmOJZ3NAgrHs8TSbD5H3VDzeMDxEk8g+uUYPJSBIH1/aJ37vyzM
lhT6hjB84xAibgiMljSxAYcvQJgiYZSGEz85ImbBFiRAXFcGMGMEQRBEEQRC/n0DjEwcI0/M
cZwzWKio9aHwcjw+82WA8gEBg0KiOL4lJEDywpHA9amAgA5wKcVMERIicIG1CQpMkSFLYCo4
oFUiJwobg0CBqMGpUpuLDasMSBfCbx+POAkffKPXw97hw7lNPqaPpMxnwMA7ia9vwhR71mIU
D2uyhlkNNDlQKigXFMn6xsQPSYIFoJsdQch3uymZPf7gePuyVVYqQFy+fsHWek8W85oQPdvb
0YMCrPEX8g7w3yLhACFGZjLAmcgMGk2x3IUcnIOk8FEKRuEhUVYub7HT3KIbxYpOSUvdUqm0
lgSP7NHVCwAl3D7HCGfcZo6LfUvtS0LsRYbOQbyCa7WfsYluZ/EwF2ADtxVA6X3EYpIcM0wG
RaBwQ4kookWC0cbVVS4SWTeYm/wAJrOLoNExoOF/Ql27+xSsrx06/fN2RNC5DPy9aWIS2zky
mPY8x5RmG84M8zQY8Gh3jDRvEaSGxXl644kVBwYRE4y8Bhk3olzOkVHBROSnJxTiD3qrwilD
CykPFAP6KEcMd35R8BaoBARBS8GsnL01JEuCUKi9wEJFBjGl2W6Lw9vkJ6YlYYDFnnNZQEQj
bhWEHmMaTpPMYVGKRxkCYzlTxyKmg5vKIiUAlb4yxcjsecF0IkD8A9tebEgQ6C6aPAIAXVFU
iXic0iOBRLY+c4njn4C7Aa3eEajPFnqBhESKMhcjRpiFzDclwwBjFUaSUjD8vmpMKKosih8q
CJvFB2kgHHWXVSUeLCkEQMDCrIRDLJIQxH2XJyTYejS+5pHDCI+OFrrBDDqGl1HNkKrFQ6q9
YTmRUl3fXxJmO5JVYAJThE7RjJHrXwA4iGymg9yPGFCJ24CIjG6DUbIVsJB4WJImlphDxNSZ
PUxLghdp1nWXOsgOrZvY3LoNneM26jMNiCRI4sFqg2XMIIYfsMt+8tWJ1ZI8QpwKU1Ez0maQ
XLToMXoIKFMURRHmuo/lhoClgDYxjC5liTIMR2zuunFvlPoQ6fFHAR5l8m2Y1T1+VnId8xwk
KFvQkHTAAzZi0cxliUgyzV1gqwY8ApIwDU0NSxVUJYvNp+Hp1PKebb0TDgZEGCprQ1qjGSah
shKUB00DhMpSTbBSRNNGwpORy08fYAjQh18kh/ogmS+stO3oUUqKdpciKdDIjkBWCVRiY8wk
LAkMc9GTpI4qdmnrD8HDurPr5lzvGT3LvKizGeQaS1mPRW4lP9iSZvNnb11NQqodZVuJCteK
mv8lVpyRjlHJ6sPLE3ZWJAO4EJMDKIUm+PEiXHu7UgxKTIOB1LrZef1RvlzP6zfqVKJT4H0E
vHa7Xgm1yUQQNS9gqylSowyBwHFkDzpNJ3f3TrdxKEYkiKAdEkHT2SqiVnKDYDJR9hz2qH6L
H3T1N4eXHh5YGO+sCK9u6CImSnDhlewd+mSaCGbX5vD1cHu/yYqIqDygQUEiuxl6ZmUaTh64
qRErOlVD1xKIFZoaYMYxCv2qQY3y75klMTOoxnoJlisejdU7hbkdqDzzFaiNDKECjYt28kkk
D4DUU9HOqrzEIaxTb5jcA452IDCs48ZZETz0T+TkQYwr78m/Ke87zUtc49h7DLhZIsMUXL5F
vt+gn1EwZvG4D84pZSgPGQAIpIxEjt3GnCySSCvHt8i/g+TEB+Wk226p9WTQBQAiIH6qr8zW
UGoOIaEgxEjWChJQoNDHRKDpRceHzG4oaMkEZA1GHyzo8QAsxEsOyfBnEXfvFe7FiQytLAZF
UmQViD5Ep5lSBTqKyQVYnGCE5C67w82MQy6SoSVmEw4JBgflYSFvJwSLnQ7yvwQMpgyPhIIA
ESAYqiQQGHmtGCjWAhBA7V6xKwtnINAExBMEK/yaYoGsRp41sQpEQpeJSNCMa2Y1HW/02GNF
ETjt5rMC9Q2UiFe6AmtddvSyUgfeA2gPADZoolKSOesEp+Sc4mX2JlarPQOwBjGrTAgkMDAB
qU6hmm4aPzzUcHKbpviMkYGwyuSwtxgG7eqCogYtGecfb3c1UOLV0fhfAh0kG4Uop1KGg7eJ
B3DDguAMhIJzc78XEMAiCDY5KYg41C/1nz80FpYfTM+liqypmW+aU8zH63Vgdxdbk11NdVYy
FKdqmMKttKy0OcblUGriI7RpEiTbzW8oAJ1Rh79Q14ySwoEmkfQWIuwmmNdIE4IBUJyRSYJS
ZbSRztcoJTXads32GNYFgGxmb+IaEPYMwk42ANok2UwSuF0w3gQcWy8/Vp11IzZmJbsie/v4
awuJhwJHYtwjIgnUqUkDNBliq4TRwqMGB+aCV7Ihf5NbzcYWmmDYsd5lVAUoDsVM0xNgEmsk
uaDfeTBihB7IJXBRamrgRA2aMRBDt6FHEJUO+DJOX6JZIc3AcumfZvEq4hgLWLCw4ZxRFQTc
kPVVgU0CCiCkAvvGkwCUUj45AVscAYyzIGNSKUOZNE6Ey0kKAL4qTAm5MyAdKFicUEXXBYIK
GhSfR2OlhevYVYthlVBON9ulRNOp6/ACA7t4SCwUhKiQrQgt2orvMIUOPokSJE7n9nUutZmR
+vAx81rIUEvlWyIMlIg1bYcEkXaTYdQ4akfyPnw5ETFXEtIWDbDre5V3eouCaY4H3LIPvivA
DEBgNMBihwdpApepaIOevOw2LcB+Y+LE62L4zmLFJbw7g3u0CX0tLIZ16s2z9gw8Jgc+sMzt
muwqwjp7729OvoIGP0QlvJjGY0JjSTegElyBiGHVIlICpBU9S7PpaKhgVXUkhEALwkUvpBkB
fbTyXU3VWZibMWKPbUz5bj/EyCgRfgTFhqQk5V3oXmGly3jzAW9phYBnY258gcbIGkRrVSCI
jAE5oGxgHVFVIKJUFHO5xwudCZ27DEPmpPXtwJurkHCSgE00Jh4VyO1YLlPWr8MhXWIDkPJc
SGzikmVOSQxTkGdzUg6g3DOKMsL2wJBwCk8gChlIGgnkhO58hmWDxQJmb2W8saiEz4ThAxMb
+vIRDkFdxQpAxTkMDLGYC2eBZEghAcokQqJ8nWccKtF5crWdDtNTzEJochZaiOWA2sTF4m5i
hYrJYLgSbLC9hCiyd0mGEIFTcqGFjdh3/UzWMBQsVwSGIFhROIOExxRpaoOvkRst6owwCROU
wkYHTeS0IBFFiKc9bhIeyJCJcEFswWbFMwvMfkmVTWKFsIUZplxXIAkJIumyKgMMMkVFYsDK
SYFXjEKY0tEoIYc9140zuMpGhpnQkyGmupCEQPPQn5KcK4WtWoROhVEK4LD5KsM1lgLZojSH
VMmIkSQB7isEKmRhxJlqEEYUSYKTLAeQ2E6xPoo92QHVHqjWSgpkJpOAbAqKRNB0Hcylcmkl
JMMQgol0MpHWFIiajnWq7pbEjQma4CgkIKwATyK6N3s6FygtGtWQwxiCCpmO7yQE3yIGpVtq
BLIsrA3N5kRg3cD49CoSIeLvLvT1ujtoSQmMNwbgx0S6ES7/ifk71hSFyJQefl8fK9sjNcgr
sZbiyTT3wp+M0u46uZLp1hrpN7CgMVTdBxSntALYODNwRInKkiQRoXOckWFsYIGS0LSDHjt4
BztJ2qSEFhL6KxKADAKCCCYpQSLT7RooyX8sDiuIVIRIis7zDyI+oSBfBiBKbEhNgpOpifgI
EEkJMGfavSrJYMR9tAV7I3G86nJb041bMZUF7LMiYQ5wxMHXxIsSHbobp9ucRN7JOQ5WKon7
6NLKyjWNLBWO9EgjX7X/F3JFOFCQTgQ22A==
--------------000802070202030103090808
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------000802070202030103090808--


From xen-devel-bounces@lists.xen.org Thu Jun 07 09:29:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ2B-0006OT-Es; Thu, 07 Jun 2012 09:29:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1ScZ29-0006OI-09
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 09:29:37 +0000
Received: from [85.158.139.83:60763] by server-12.bemta-5.messagelabs.com id
	AA/B9-18374-08470DF4; Thu, 07 Jun 2012 09:29:36 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339061374!31859645!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8336 invoked from network); 7 Jun 2012 09:29:35 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:29:35 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id EC02ED0
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 13:29:33 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id gB-6XRnRs363 for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 13:29:33 +0400 (MSK)
Received: from sysadmin.office.main.elserv.ru (sysadmin.office.main.elserv.ru
	[192.168.3.135]) (Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id 85CC919
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 13:29:33 +0400 (MSK)
Message-ID: <4FD0747D.10103@elserv.ru>
Date: Thu, 07 Jun 2012 13:29:33 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary="------------000802070202030103090808"
Subject: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------000802070202030103090808
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi people,

I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on 
IBM eServer x3400. Without noacpi command line option dom0 kernel 
crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen 
patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor 
all kernels run without any problems.

There are several patches (available on 
http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/kernel-image-xen-dom0, 
commits f1f91babc9cc9402ccee8938b888240f5bae1574, 
72db7b5e069002765ced64f030c1117d72352331, 
adc4c567a08d4d2377060179639cbfdc3d9d8e0e and 
9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32 to 
boot on this hardware. This patches written by kernel package maintainer 
of ALT Linux distribution. Discussion of this issue is available on 
Sysadmins ALTLinux mailing list 
(http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html 
and follows) in Russian.

I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need this 
messages for more recent versions of Xen and kernel, or more information 
about hardware, please let me know.

Ideally, I would like to run current versions of Xen and Linux kernels 
on this hardware. Can you help me please?


--
  WBR, Alex Moskalenko

--------------000802070202030103090808
Content-Type: application/x-bzip;
 name="crash.acpi.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="crash.acpi.bz2"

QlpoOTFBWSZTWU4ENtgACa/fiP/1bP/////v//7////0IAAAAOAkvHDk++7x7M+BJ9V3sAMT
Xvvfe0fe8++NrTJpPtxa6rdnRzYQqlRKzQz3vKetHoJV5wceXu7nXe9571zrYO7DrZqdUdN6
1c9ui7aIlAC7G773hCAPPhKIEATE00CZMVT/BNGkNMJG1NNqejUQ8hGmm1DRpkAlBABJkTU9
J6NVP1T09E00TymGoYTaIDEANANBoAamaImgmmkNNR6nppGho0Gjaj1B6RoAAAGmgNACTSiJ
Dagmg1NoRgFGjQ2k9TyMk0epoD1ANGgaA9QEUhSn6iPyFGQ2oA8o8p6mg0NNAeoPU/VA0aDQ
AAMgkSAgECDTSaNCaMmjRlTyJ5TI0aNqGI0zUaZNA006YEOQhIQ/W0FgykggUgQaMpUksYtQ
rILIpCAdiMEZArAjMDZVgAFoEFRkQQUjH2he149/Pw/fIBB5psWuXdeUsNk212J3T7/xwa/w
eXr27LQNtB0UiMbgAwhJK0AenF8ZPqKNaMke/H7O7iZo6TW0MzuAGkr4H9JWSJKRucLh/e/L
kaYgLt7HSmrcBBa2IGQZVBZQAKSsKrFvXZ46+lEpAKmOpTp8OS88apcvG8rDW3Wll4k8sMd5
jjHN9OHJuXU+t+78giT4Kqqu7g9Nb1hnakNuS/WuSg2J630srDmlNYylrO2k5NGnbJuEdvHD
h0ttD+j7n3XaNNpEuYqvA0bxkgMzTKFSClBQkKq13Et196p3giBtRZIKK1V9BpJraAjYtRvE
TRLbTGi5EwMVXA0pGSAzljZZMxZsxZ5/Jn1c+lgDgCAF+2cd2VMf00SAByQKAPyEUTSns7fn
wFAyZ79069H8/TZrpfCPWUZGqqs/yMIbPPXX3uE0CqTVxDYPGhfbWOkVZgnBYbevhXBozSnQ
1DoM+UDFTByU6RMjiAdZgQnL0adQ5qb9b5XPbvgrvxhVVVZPBp3Tg/T8WnOdU9/vbHqO0ncE
RERERERETm3fwIXSrQRA3ZUpGjc2JLtKEbPUL5zKrMCQ2jilgkYqk7WZS0V8RqOqBg+Qc98u
QuuCIo44yiv6RSQqITmTc6Ax8XbEiWKfBTflufiY7+/t/hQSrfT7pHViaHj73+p7PJ9/QdDl
x5/I+N5j0nmvqwH2uGmatbcRomL5Znx+bHX3G7d8GDGKW0tottLZRtLarG02K1fUqIy5hqiE
OZrDY1ycJYvMZAIPtwRlbp53Knri8/ZUnSzKdkmSZVUWJh1NGaqPtDV4uQjiDcpf2/pj25YJ
6p5cA42rmxL9Stuz/TzX3nhf50bZXXmQNnea23+cslmQkU+hYVDx5yi4bHDSutvpz6qahXgE
dEsssUF/ZVZiXbkOWSSOSfGuWF6qOLOlAGwPawz75iaSTBFXzTXZ9V2n6Cr0Tk4ZO/8PuzTV
mWLjJW3znD9NqruRKjPNlKM3o1haX/T5HyY76uHj2CTw/F7x7e1uNVVRVRFFViqqqqqqqqqq
qqoqqp/fg/Z9Op8J5eINwFchBJpmZF6l7kxdfe3vxX5aiQwt3vZSKZ4dbVROluABwAb2KdDS
IUJpZN7plVWgS3/OBZGQIl6LWd43pwyJlrtts+Ip985ui3/jvT44Ckqr7euVH7DkxmHHI8F8
rgOzsHtjCkUFExY3FxSJAgYmgxKqJW23NeXLPiUSVXCiv2TX4OQEwBfpsBbAtKnhh0br0sE+
g3trrwmcs83CWapDN3sP27S6LMXZp48n7rbZXqoY+gzrppocnXiHcIbD7UWYDC1HPOQcCAHU
AkG2QiwNmhoO2QGEgGpJ1UmbKb5fEHIuxBXAw87BY/SqXmxLaNztl2f4fcU7sMyPknVqc7GO
gsznKaJ9TYHOvdoAcT0segjYU00rwXk5WPXQuxfWuZfYuy6V80skkV5CNUBBM2pPe0U9/wmc
O8hWK9hg7hQX64Qfk9nvn2XpgQmFAVVVFBUROkNrA4Gi/jzzajoddQG3rOWNJ7XfcUfHaXbr
/VRSWxvslZcV9hGWK8LQOa1MJqNc8e7fA7vWB6QMwF6TMiMNBWcp5qYXDV0HzwHxFvFpNKZI
MVEYzDE3E6ok9Nhpj5aLvmnh66aFqH1Bpbt8nCZEcRnDB19V1vZghMp+qIH8sLnqIG778dQY
gFo7Yqb+rc3JbcQVME+PC7hhINGKDsrYGu4DkTpLfnsdZZC2yglnbuKUmDFCMLo4Yk3togAb
ElSLdqkrKlqlJ/sod03uSo2sndreBxNOqOkIqqXA75NGrG+F5bS4dr2NutkQO/ZP77TTfcAq
kfX7O4pukRLS9RbOhXNur5u6SaQfpz5YlXvzr6esnu9f3Dv9uNxcdVIQwtuZLkn0UrpWlyiP
zMXc8Fo08vsY8ni9B5GOWS48TnJtd1ZPfw+0be5iS4UpOYw6hrpqGZumgld6Ly7nvvQ6MrPm
O3unybr2i/gpzs2Yt6J48HVmxTa0jOALMuB2Ks/O83ecAZVSYKiezSQXLLAgl83UrL4RfE0G
7SI3QkmlI1JPhsAaScRaNGy3mDeIqKoTZ/DwUVf1YxE9HraE16vR3tBYeq0UUUUUPACHmTcn
5ONIW1QTdgRa7KKA2aGj4ZpOHR58W008sLSdeJw7JHt3A+FaGmjiP9O5dz1iAqJDOT2e6e2t
CBturX3fR++v2CA0+HD5vnPWVSNWhC+tpAXawPsIm0Xch+9ASJRURRS/4vOY7jEHedxjDiGR
jxwpERjOeIcIHeRkLM+IiQDiCkz/pI9yhM0GmYFIDhw0KQWB84weSzYrMasTQd/qik5dF2yv
8TlPEBtEyrMRH8NsOF1EkN7p5Jfc+3vVZE2KO92wQRFYxjePpM/4DuTIMGRoH4tVUPPm79P1
mm9F6pzN/M0aIJUUQ+o4idvwJIX9aihAUPHLdd88WHkqWhMwZisIxIIDnk1aWOKIwwKqnAIV
ULhIyME4J1PUq5JreNsLS5ju+qM8TbepvDrNjv9ZuPuOAzqLGB7zrIxb9pE74OUok8vcDxM7
DZQKW0bsQOFQZMuZmZUsGbL2lbd5TjPN8Pkhz853uKEhCdvnAbc2vWHPkv1a5Z4ODJRaMsG1
XeHFt9PBbBGFYWiM1upmvSTwnB1iF2bqhi+LAGaseE8DB5lGiwgKKVlVme7bn8u9kpvaCmTx
tzItv8ta/Z/yyBHdoUrpIKKrEn9Gik3/S3uK+H5DD8PtjBXh5kjkSSwX1oQkdBoDexCAqkHy
HuCE3EIQnImrVRd6QgusGelRRiowEIXl8vkxjDzHKwBQndnabEyDLtMTIkYHocCGMkKyoSph
EJk8LEHTtXUkBDkQJ7z+4siaSFoxCwxS3kEEFsySkUrmdZRXeBiMx8RCSsWxG3CuYNsGY3A8
7P0txF7KgupTjKhsay7qEhxxAPYklEERM64MAiMDV59Lsl5t+m2uLdNNNgkmRJAoNdYLKt12
Kk4QWZRgpkMnKBqhIgymJSkb0IIiVy0ibMJFShFKIoxNgCVxOaQ1brJAoimxAIOxoXs/EqDi
o+JsODoKDCXZOIemlpmgnVguyMJDeQ4HiXgkywtNpQypQzypQxUyAuGDKIldAxLLKCbzEmCD
Ky4mS6Ir0LCaPkogsitsnWVEo4spifVXdEjZS2mr3E3CVIQm4yxEVJqPhmK/LxmaylMVrTgP
0DST2JWVYf9Y1aTEpWUJ8XMEEDGAqAJb1sMi8IoWZ42JnrNwRAwO9aG4kHn2v+0SpNn4nJsE
J5QLE0IMQS0omAClEiiCAgiJDDKMqamJZAVMJYCWUKCJUKJKwoMUiJ0JSIIjGDGIkUGMenVt
KXS/smlPubll7dzaOE/tAFa5FVVVVI2i/M0YUKc35+wocGkxHIbis5VTLZzyN+qdPR4cOxw+
mhH7yYyFk1e3AJD3x5TlSxY5SSVWIL2cB0Cs5SIS3+SAlCdJwo4x6j7D0hcmWpUgBFqxUSJM
SH8l5CUuY/PIIYp4XWIqfKGuIFy6i1rxM+iqLaN2fBJ81qye0SJMOI1dPM5ZCyNbwFqHrJCz
rMlMgmAIxiaiQklMmGMy2Nw/O2NE33pr27XoKDUTnaJMyTbjcEFKgDUKEQnN1SybJMiaoabY
g6GTeengpgNJqKKNnYR8xMpvO/Ld0xkuWzdb76xzwu3tz9gGxNYMxPhjBi1P1MsUAgDfwGgc
V3V8vLfa8Hi7mrWWSVoRciddLilONXPD3RqirAsMHMgHsxgaQMnJjeMStVYXc3o4ENiwjYoT
E15u65xM78Y/hQzwIJmw5DabsTkd3rJrSfEiLA+wWseNOuD/zz9naYFyDw3oDJ6i0toJa0Jh
TuLHQmVGY9eZy7yki5e6GiiNLKIyNrbkqyOkdY+QkI5YnSPJW7+G5tpSM1C1FpXcWvbmDNhv
FtuMnJRpLLV9jhxeSLEOVYiYpiQCBAZm2O8xAXqGTlUmvYV2gGxsmlznHxc7nfI1J6mANpeI
+BkYGlwoeiA0eLMrEIhtreMUEHyTJBIgWIyBjKdzQu4tFMPLu6tdG5V762vF5zCHWVSRMXQt
dvAUdmj/du8tIGJcIzH7htqRsCSohFGBDSiHcjWXEpD/w3VW2ZUKrZguR1xcgeGixQaOXAah
XoQHWHceIRyklEptqj1FlRy8hjl2yH7Rih8N9AJXffcmJENgUJdNxAgfcqlSZKpA8QWp0l0l
FVZaxospKeSlJ215EdDBBDIrOo1mc5G0dyxpVZkinMVpoUN83riUX13BRudygWsPuVCYyum5
yFBVGYzAejmLuFEiLKe/NnrLjtys7vlM0jS/0NjdB8WZvi3cEwVONYbPeQZPqC5AnbzrKQNv
2wUduVAJdVJBSOpQgW7FWdJ06Dm5yJ4Jv3FeolAoFB8jIwOSp5WTS+xOZSiDTQ7nlOYWUqcy
gaqMZwRAniXbSH06T4gdoRKmxkbGuyUnrKeBNrWYp6XrauojwZiicSJe9dxklcrExMwXtGB5
K8IgScMFtM4S0IBkVe2mhRg2dGOeOJ5B5Zp744W00ry5ZaBaMDsNjlo07DMAmHASQMeHowF3
mtKAijprjtaB4CuKMzO6pihBRiBH1FCEH1HGOBQvkZoywIiJbTqPjK4Doa6zZXZ0Tbgvb3CI
YqqpbZL+CIpUK8oHQmGxuqdRFWu3vzQY4KLE572oHlaf0weBoYOzgIGayfMg7By22Jm/F3su
p61gpRaFGw5SiwbUmKZOCFIyFEdqEymhLp8AVRlQTlSzkypk1/DqVWjafa5h4t6/DhH0XRsf
4fERpbP752YFArxsL+TM2GWDGfkSz2fCCeoqE5UfxL7jA5GDmgGsyAPxH5t+x2UaxqfdvvQ/
baF+thsxKABoAmUSRUaB7FAYGmmpoXuxGI6r91dnxC41ka2TrYuueUz2yLmdg27c+q98L351
GDAZW+4vmbThblvYWzd7Nzr8IPZtAY05Lhz+vL0oesARFBhzVG8Xdg/68pTAYTITIh1Ig40E
0LTtGEekuPpRNCkwg1VYdzDGnIZAaMLDkVEyUp5CBzIDECBxJjjkjtLkjYwXIFzB0FFMk8Fy
RiZK5kwKOE61qGhuROSCJxIy3jlauanLxEmjt6HcILSCCEUJFcstRq9aNicFnV23nKHTvsNa
bgDeFNkKDIIYAL7U4XXP2YeQoBrgeiH+7hT7mg6xmgM9we+DPH/WRJpTEj8nxDZFxiNzSOB3
6z9RnU/V4EhHg+xLftJwkiDIHMgB7HrM1GHumpf67jYIJMQh844x4/kYFWnrjQsBbe8mIJS4
9f6K4yi5YDmMV2oAmVkIwz7+T7W/zl+z5sB9CCzwMM+JsfjQCCDBa3txe16SrY6WWZ4eFOdM
6iMcC2WIFoGCayhGG4w4FyEsm1QZdkc/IfGYzNLP68EFD6YDZkvlg9wMCAZ5ZMBkBMmbmZCl
YSTAIRH3zgEie0CROYBsU0rHXpzsXi0hLJoXA5w5Qjzvky5rCQe5i4JeZJvDbhMCKbDW47Rh
IjYL0AXtpxoTACxB7MIhzqUBQCwYa00kOTY1NeKp4SMyoeMUTfxtdUgZOfa51oBkp8kCxxEQ
PCD0tZcD2yFpddaaSQH8Jc6cpIyPRSnkAHVjpcsDYpoMNJIaceEAttuB1aPuIVzkXNTq6PXe
J1mFWGORpFNzF0aLUeuAiQ/4sP1DwQhHJABCV88JICgITcmiAD9Q0JcEuYstakctfcXKb4Ey
E2zkr50Dc4zIU2XEkMTUtOWu1U1RHIJM6CoPkjS5xPUT476a4a1eAtE5Rlv51X58Nf6zghKb
M1zwkwFI9OqNRQThEgqdBdu0y7F8Q0szg1xjaSl8ufDwMt2e6+BBSfAiN8XVblwTlY5/O4Oa
jAixAWWv4/DO3cMJMPWGsUHbaEhHh0I56GF+NCCPxkKSGkvMMmKhCV16mC7XTaqOcKgcQki6
+m8W9QooolkhXkFZmBHOAZwiZR8tVTtQCjmqkp0MOP67BhhtS2j6ZcMxiQrBNbCNn02rFVRE
FVRVVVVVVVVVVVVVVVVVVVVVWCoiuGgJgJLgWB4mAfdYOtNX8TdZMslZ60JYq5giG6+fEqZk
VZwWaJn0XhTGueC5y+i4ZhJd0mgqkFS6ICfHgoPaLCKVtESAhCpG1b1xacJxnKc5pT1GSEK0
na1pznOc5zskmiYFwJUqVJEyRUsXuNYGLKgyCkwHqwDMvV7vU5EY4C2Yfeo32r9rWLd/baNG
rjznUdBuNQiDRPlFNIorMzmOJZ3NAgrHs8TSbD5H3VDzeMDxEk8g+uUYPJSBIH1/aJ37vyzM
lhT6hjB84xAibgiMljSxAYcvQJgiYZSGEz85ImbBFiRAXFcGMGMEQRBEEQRC/n0DjEwcI0/M
cZwzWKio9aHwcjw+82WA8gEBg0KiOL4lJEDywpHA9amAgA5wKcVMERIicIG1CQpMkSFLYCo4
oFUiJwobg0CBqMGpUpuLDasMSBfCbx+POAkffKPXw97hw7lNPqaPpMxnwMA7ia9vwhR71mIU
D2uyhlkNNDlQKigXFMn6xsQPSYIFoJsdQch3uymZPf7gePuyVVYqQFy+fsHWek8W85oQPdvb
0YMCrPEX8g7w3yLhACFGZjLAmcgMGk2x3IUcnIOk8FEKRuEhUVYub7HT3KIbxYpOSUvdUqm0
lgSP7NHVCwAl3D7HCGfcZo6LfUvtS0LsRYbOQbyCa7WfsYluZ/EwF2ADtxVA6X3EYpIcM0wG
RaBwQ4kookWC0cbVVS4SWTeYm/wAJrOLoNExoOF/Ql27+xSsrx06/fN2RNC5DPy9aWIS2zky
mPY8x5RmG84M8zQY8Gh3jDRvEaSGxXl644kVBwYRE4y8Bhk3olzOkVHBROSnJxTiD3qrwilD
CykPFAP6KEcMd35R8BaoBARBS8GsnL01JEuCUKi9wEJFBjGl2W6Lw9vkJ6YlYYDFnnNZQEQj
bhWEHmMaTpPMYVGKRxkCYzlTxyKmg5vKIiUAlb4yxcjsecF0IkD8A9tebEgQ6C6aPAIAXVFU
iXic0iOBRLY+c4njn4C7Aa3eEajPFnqBhESKMhcjRpiFzDclwwBjFUaSUjD8vmpMKKosih8q
CJvFB2kgHHWXVSUeLCkEQMDCrIRDLJIQxH2XJyTYejS+5pHDCI+OFrrBDDqGl1HNkKrFQ6q9
YTmRUl3fXxJmO5JVYAJThE7RjJHrXwA4iGymg9yPGFCJ24CIjG6DUbIVsJB4WJImlphDxNSZ
PUxLghdp1nWXOsgOrZvY3LoNneM26jMNiCRI4sFqg2XMIIYfsMt+8tWJ1ZI8QpwKU1Ez0maQ
XLToMXoIKFMURRHmuo/lhoClgDYxjC5liTIMR2zuunFvlPoQ6fFHAR5l8m2Y1T1+VnId8xwk
KFvQkHTAAzZi0cxliUgyzV1gqwY8ApIwDU0NSxVUJYvNp+Hp1PKebb0TDgZEGCprQ1qjGSah
shKUB00DhMpSTbBSRNNGwpORy08fYAjQh18kh/ogmS+stO3oUUqKdpciKdDIjkBWCVRiY8wk
LAkMc9GTpI4qdmnrD8HDurPr5lzvGT3LvKizGeQaS1mPRW4lP9iSZvNnb11NQqodZVuJCteK
mv8lVpyRjlHJ6sPLE3ZWJAO4EJMDKIUm+PEiXHu7UgxKTIOB1LrZef1RvlzP6zfqVKJT4H0E
vHa7Xgm1yUQQNS9gqylSowyBwHFkDzpNJ3f3TrdxKEYkiKAdEkHT2SqiVnKDYDJR9hz2qH6L
H3T1N4eXHh5YGO+sCK9u6CImSnDhlewd+mSaCGbX5vD1cHu/yYqIqDygQUEiuxl6ZmUaTh64
qRErOlVD1xKIFZoaYMYxCv2qQY3y75klMTOoxnoJlisejdU7hbkdqDzzFaiNDKECjYt28kkk
D4DUU9HOqrzEIaxTb5jcA452IDCs48ZZETz0T+TkQYwr78m/Ke87zUtc49h7DLhZIsMUXL5F
vt+gn1EwZvG4D84pZSgPGQAIpIxEjt3GnCySSCvHt8i/g+TEB+Wk226p9WTQBQAiIH6qr8zW
UGoOIaEgxEjWChJQoNDHRKDpRceHzG4oaMkEZA1GHyzo8QAsxEsOyfBnEXfvFe7FiQytLAZF
UmQViD5Ep5lSBTqKyQVYnGCE5C67w82MQy6SoSVmEw4JBgflYSFvJwSLnQ7yvwQMpgyPhIIA
ESAYqiQQGHmtGCjWAhBA7V6xKwtnINAExBMEK/yaYoGsRp41sQpEQpeJSNCMa2Y1HW/02GNF
ETjt5rMC9Q2UiFe6AmtddvSyUgfeA2gPADZoolKSOesEp+Sc4mX2JlarPQOwBjGrTAgkMDAB
qU6hmm4aPzzUcHKbpviMkYGwyuSwtxgG7eqCogYtGecfb3c1UOLV0fhfAh0kG4Uop1KGg7eJ
B3DDguAMhIJzc78XEMAiCDY5KYg41C/1nz80FpYfTM+liqypmW+aU8zH63Vgdxdbk11NdVYy
FKdqmMKttKy0OcblUGriI7RpEiTbzW8oAJ1Rh79Q14ySwoEmkfQWIuwmmNdIE4IBUJyRSYJS
ZbSRztcoJTXads32GNYFgGxmb+IaEPYMwk42ANok2UwSuF0w3gQcWy8/Vp11IzZmJbsie/v4
awuJhwJHYtwjIgnUqUkDNBliq4TRwqMGB+aCV7Ihf5NbzcYWmmDYsd5lVAUoDsVM0xNgEmsk
uaDfeTBihB7IJXBRamrgRA2aMRBDt6FHEJUO+DJOX6JZIc3AcumfZvEq4hgLWLCw4ZxRFQTc
kPVVgU0CCiCkAvvGkwCUUj45AVscAYyzIGNSKUOZNE6Ey0kKAL4qTAm5MyAdKFicUEXXBYIK
GhSfR2OlhevYVYthlVBON9ulRNOp6/ACA7t4SCwUhKiQrQgt2orvMIUOPokSJE7n9nUutZmR
+vAx81rIUEvlWyIMlIg1bYcEkXaTYdQ4akfyPnw5ETFXEtIWDbDre5V3eouCaY4H3LIPvivA
DEBgNMBihwdpApepaIOevOw2LcB+Y+LE62L4zmLFJbw7g3u0CX0tLIZ16s2z9gw8Jgc+sMzt
muwqwjp7729OvoIGP0QlvJjGY0JjSTegElyBiGHVIlICpBU9S7PpaKhgVXUkhEALwkUvpBkB
fbTyXU3VWZibMWKPbUz5bj/EyCgRfgTFhqQk5V3oXmGly3jzAW9phYBnY258gcbIGkRrVSCI
jAE5oGxgHVFVIKJUFHO5xwudCZ27DEPmpPXtwJurkHCSgE00Jh4VyO1YLlPWr8MhXWIDkPJc
SGzikmVOSQxTkGdzUg6g3DOKMsL2wJBwCk8gChlIGgnkhO58hmWDxQJmb2W8saiEz4ThAxMb
+vIRDkFdxQpAxTkMDLGYC2eBZEghAcokQqJ8nWccKtF5crWdDtNTzEJochZaiOWA2sTF4m5i
hYrJYLgSbLC9hCiyd0mGEIFTcqGFjdh3/UzWMBQsVwSGIFhROIOExxRpaoOvkRst6owwCROU
wkYHTeS0IBFFiKc9bhIeyJCJcEFswWbFMwvMfkmVTWKFsIUZplxXIAkJIumyKgMMMkVFYsDK
SYFXjEKY0tEoIYc9140zuMpGhpnQkyGmupCEQPPQn5KcK4WtWoROhVEK4LD5KsM1lgLZojSH
VMmIkSQB7isEKmRhxJlqEEYUSYKTLAeQ2E6xPoo92QHVHqjWSgpkJpOAbAqKRNB0Hcylcmkl
JMMQgol0MpHWFIiajnWq7pbEjQma4CgkIKwATyK6N3s6FygtGtWQwxiCCpmO7yQE3yIGpVtq
BLIsrA3N5kRg3cD49CoSIeLvLvT1ujtoSQmMNwbgx0S6ES7/ifk71hSFyJQefl8fK9sjNcgr
sZbiyTT3wp+M0u46uZLp1hrpN7CgMVTdBxSntALYODNwRInKkiQRoXOckWFsYIGS0LSDHjt4
BztJ2qSEFhL6KxKADAKCCCYpQSLT7RooyX8sDiuIVIRIis7zDyI+oSBfBiBKbEhNgpOpifgI
EEkJMGfavSrJYMR9tAV7I3G86nJb041bMZUF7LMiYQ5wxMHXxIsSHbobp9ucRN7JOQ5WKon7
6NLKyjWNLBWO9EgjX7X/F3JFOFCQTgQ22A==
--------------000802070202030103090808
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------000802070202030103090808--


From xen-devel-bounces@lists.xen.org Thu Jun 07 09:30:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:30: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 1ScZ2R-0006Px-Qb; Thu, 07 Jun 2012 09:29: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 1ScZ2Q-0006Pl-QB
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:29:54 +0000
Received: from [85.158.138.51:36241] by server-5.bemta-3.messagelabs.com id
	F2/F6-03598-19470DF4; Thu, 07 Jun 2012 09:29:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339061392!31207764!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23097 invoked from network); 7 Jun 2012 09:29:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:29:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZ2N-000IWb-Kw; Thu, 07 Jun 2012 09:29:51 +0000
Date: Thu, 7 Jun 2012 10:29:51 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607092951.GE70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> +int domain_uart0_init(struct domain *d)
> +{
> +    int rc;
> +    if ( d->domain_id == 0 )
> +        return 0;

Why?  There's no equivalent gate on the MMIO handlers.

> +    spin_lock_init(&d->arch.uart0.lock);
> +    d->arch.uart0.idx = 0;
> +
> +    rc = -ENOMEM;
> +    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
> +    if ( !d->arch.uart0.buf )
> +        goto out;

Just return ENOMEM here - the 'rc=foo; goto out' is overkill.

> +
> +    rc = 0;
> +out:
> +    return rc;
> +}

> +static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
> +{
> +    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
> +}

linewrap?

> +
> +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 = &regs->r0 + dabt.reg;
> +    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
> +

Need to check dabt.size != 0 here too?

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:30:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:30: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 1ScZ2R-0006Px-Qb; Thu, 07 Jun 2012 09:29: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 1ScZ2Q-0006Pl-QB
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:29:54 +0000
Received: from [85.158.138.51:36241] by server-5.bemta-3.messagelabs.com id
	F2/F6-03598-19470DF4; Thu, 07 Jun 2012 09:29:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339061392!31207764!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23097 invoked from network); 7 Jun 2012 09:29:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:29:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZ2N-000IWb-Kw; Thu, 07 Jun 2012 09:29:51 +0000
Date: Thu, 7 Jun 2012 10:29:51 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607092951.GE70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> +int domain_uart0_init(struct domain *d)
> +{
> +    int rc;
> +    if ( d->domain_id == 0 )
> +        return 0;

Why?  There's no equivalent gate on the MMIO handlers.

> +    spin_lock_init(&d->arch.uart0.lock);
> +    d->arch.uart0.idx = 0;
> +
> +    rc = -ENOMEM;
> +    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
> +    if ( !d->arch.uart0.buf )
> +        goto out;

Just return ENOMEM here - the 'rc=foo; goto out' is overkill.

> +
> +    rc = 0;
> +out:
> +    return rc;
> +}

> +static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
> +{
> +    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
> +}

linewrap?

> +
> +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 = &regs->r0 + dabt.reg;
> +    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
> +

Need to check dabt.size != 0 here too?

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ5i-0006hU-E1; Thu, 07 Jun 2012 09:33:18 +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 1ScZ5h-0006hH-FF
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:33:17 +0000
Received: from [85.158.138.51:11187] by server-9.bemta-3.messagelabs.com id
	3E/84-15054-C5570DF4; Thu, 07 Jun 2012 09:33:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339061594!31249410!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9868 invoked from network); 7 Jun 2012 09:33:14 -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; 7 Jun 2012 09:33:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZ5O-000IXJ-G6; Thu, 07 Jun 2012 09:32:58 +0000
Date: Thu, 7 Jun 2012 10:32:58 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607093258.GF70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-20-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-20-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/38] arm: dump a page table walk when
	va_to_par 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

At 15:39 +0000 on 01 Jun (1338565189), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
>  xen/include/asm-arm/page.h |   12 ++++++++----
>  1 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index bb1729a..f36bf6f 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -254,6 +254,9 @@ static inline void flush_guest_tlb(void)
>      WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
>  }
>  
> +extern void dump_pt_walk(uint32_t addr);
> +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)
>  {
> @@ -270,7 +273,11 @@ static inline uint64_t va_to_par(uint32_t va)
>  {
>      uint64_t par = __va_to_par(va);
>      /* It is not OK to call this with an invalid VA */
> -    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
> +    if ( par & PAR_F )
> +    {
> +        dump_pt_walk(va);
> +        panic_PAR(par, "Hypervisor");
> +    }
>      return par;
>  }
>  
> @@ -314,9 +321,6 @@ static inline uint64_t gva_to_ipa(uint32_t va)
>  /* Bits in the PAR returned by va_to_par */
>  #define PAR_FAULT 0x1
>  
> -extern void dump_pt_walk(uint32_t addr);
> -extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
> -
>  #endif /* __ASSEMBLY__ */
>  
>  /* These numbers add up to a 39-bit input address space.  The  ARMv7-A
> -- 
> 1.7.9.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 Thu Jun 07 09:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ5i-0006hU-E1; Thu, 07 Jun 2012 09:33:18 +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 1ScZ5h-0006hH-FF
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:33:17 +0000
Received: from [85.158.138.51:11187] by server-9.bemta-3.messagelabs.com id
	3E/84-15054-C5570DF4; Thu, 07 Jun 2012 09:33:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339061594!31249410!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9868 invoked from network); 7 Jun 2012 09:33:14 -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; 7 Jun 2012 09:33:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZ5O-000IXJ-G6; Thu, 07 Jun 2012 09:32:58 +0000
Date: Thu, 7 Jun 2012 10:32:58 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607093258.GF70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-20-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-20-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/38] arm: dump a page table walk when
	va_to_par 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

At 15:39 +0000 on 01 Jun (1338565189), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
>  xen/include/asm-arm/page.h |   12 ++++++++----
>  1 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index bb1729a..f36bf6f 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -254,6 +254,9 @@ static inline void flush_guest_tlb(void)
>      WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
>  }
>  
> +extern void dump_pt_walk(uint32_t addr);
> +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)
>  {
> @@ -270,7 +273,11 @@ static inline uint64_t va_to_par(uint32_t va)
>  {
>      uint64_t par = __va_to_par(va);
>      /* It is not OK to call this with an invalid VA */
> -    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
> +    if ( par & PAR_F )
> +    {
> +        dump_pt_walk(va);
> +        panic_PAR(par, "Hypervisor");
> +    }
>      return par;
>  }
>  
> @@ -314,9 +321,6 @@ static inline uint64_t gva_to_ipa(uint32_t va)
>  /* Bits in the PAR returned by va_to_par */
>  #define PAR_FAULT 0x1
>  
> -extern void dump_pt_walk(uint32_t addr);
> -extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
> -
>  #endif /* __ASSEMBLY__ */
>  
>  /* These numbers add up to a 39-bit input address space.  The  ARMv7-A
> -- 
> 1.7.9.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 Thu Jun 07 09:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ7H-0006tf-IL; Thu, 07 Jun 2012 09:34: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 1ScZ7G-0006tQ-DU
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:34:54 +0000
Received: from [85.158.143.99:12529] by server-3.bemta-4.messagelabs.com id
	17/3B-29237-DB570DF4; Thu, 07 Jun 2012 09:34:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339061692!24175677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5212 invoked from network); 7 Jun 2012 09:34:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:34:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12876396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 09:34:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	10:34:52 +0100
Message-ID: <1339061691.15265.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 10:34:51 +0100
In-Reply-To: <20120607092951.GE70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
	<20120607092951.GE70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 10:29 +0100, Tim Deegan wrote:
> > +int domain_uart0_init(struct domain *d)
> > +{
> > +    int rc;
> > +    if ( d->domain_id == 0 )
> > +        return 0;
> 
> Why?  There's no equivalent gate on the MMIO handlers.

dom0 has the actual uart mapped at this address, not the emulated one.
Maybe that should be written at the caller instead?

> 
> > +    spin_lock_init(&d->arch.uart0.lock);
> > +    d->arch.uart0.idx = 0;
> > +
> > +    rc = -ENOMEM;
> > +    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
> > +    if ( !d->arch.uart0.buf )
> > +        goto out;
> 
> Just return ENOMEM here - the 'rc=foo; goto out' is overkill.

ok.

> > +
> > +    rc = 0;
> > +out:
> > +    return rc;
> > +}
> 
> > +static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
> > +{
> > +    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
> > +}
> 
> linewrap?

yes, Stefano also suggests a better #define than 65536...

> 
> > +
> > +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 = &regs->r0 + dabt.reg;
> > +    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
> > +
> 
> Need to check dabt.size != 0 here too?

IIRC I was seeing reads of different sizes. To be honest I mostly
tailored this for the specific behaviour of the Linux decompression
code, it didn't really want to write a full & correct UART emulation...

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ7H-0006tf-IL; Thu, 07 Jun 2012 09:34: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 1ScZ7G-0006tQ-DU
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:34:54 +0000
Received: from [85.158.143.99:12529] by server-3.bemta-4.messagelabs.com id
	17/3B-29237-DB570DF4; Thu, 07 Jun 2012 09:34:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339061692!24175677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5212 invoked from network); 7 Jun 2012 09:34:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:34:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12876396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 09:34:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	10:34:52 +0100
Message-ID: <1339061691.15265.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 10:34:51 +0100
In-Reply-To: <20120607092951.GE70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
	<20120607092951.GE70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 10:29 +0100, Tim Deegan wrote:
> > +int domain_uart0_init(struct domain *d)
> > +{
> > +    int rc;
> > +    if ( d->domain_id == 0 )
> > +        return 0;
> 
> Why?  There's no equivalent gate on the MMIO handlers.

dom0 has the actual uart mapped at this address, not the emulated one.
Maybe that should be written at the caller instead?

> 
> > +    spin_lock_init(&d->arch.uart0.lock);
> > +    d->arch.uart0.idx = 0;
> > +
> > +    rc = -ENOMEM;
> > +    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
> > +    if ( !d->arch.uart0.buf )
> > +        goto out;
> 
> Just return ENOMEM here - the 'rc=foo; goto out' is overkill.

ok.

> > +
> > +    rc = 0;
> > +out:
> > +    return rc;
> > +}
> 
> > +static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
> > +{
> > +    return v->domain->domain_id && addr >= UART0_BASE_ADDRESS && addr < (UART0_BASE_ADDRESS+65536);
> > +}
> 
> linewrap?

yes, Stefano also suggests a better #define than 65536...

> 
> > +
> > +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 = &regs->r0 + dabt.reg;
> > +    int offset = (int)(info->gpa - UART0_BASE_ADDRESS);
> > +
> 
> Need to check dabt.size != 0 here too?

IIRC I was seeing reads of different sizes. To be honest I mostly
tailored this for the specific behaviour of the Linux decompression
code, it didn't really want to write a full & correct UART emulation...

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:35:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ81-00071M-1L; Thu, 07 Jun 2012 09:35:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@eu.citrix.com>) id 1ScYIS-0004WX-Fs
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 08:42:24 +0000
Received: from [85.158.139.83:40228] by server-2.bemta-5.messagelabs.com id
	79/10-20827-F6960DF4; Thu, 07 Jun 2012 08:42:23 +0000
X-Env-Sender: jean.guyader@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339058542!28412315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5608 invoked from network); 7 Jun 2012 08:42:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 08:42:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12874914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 08:42:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 09:42:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1ScYIQ-0006uv-EC;
	Thu, 07 Jun 2012 08:42:22 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1ScYNi-0003rv-3N;
	Thu, 07 Jun 2012 09:47:50 +0100
Date: Thu, 7 Jun 2012 09:47:50 +0100
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607084750.GD14635@spongy.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338558477.17466.121.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 07 Jun 2012 09:35:39 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 01/06 02:47, Ian Campbell wrote:
> On Thu, 2012-05-31 at 16:07 +0100, Jean Guyader wrote:
> > V4V is a copy based inter vm communication system.
> > 
> > Please have a look at this thread for more detail
> > about V4V.
> > http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html
> > 
> > This patch series is work in progress but I wanted to
> > post it early enough so I can get feedback from people.
> 
> The main thing which is missing here, which makes it rather hard to
> review, is any kind of design documentation. It would also be great to
> see the rationale for why things have to be done this way.
> 
> For example it seems that there is a bunch of stuff being added to the
> hypervisor which could live in the context of some guest or service
> domain -- putting stuff like that in the hypervisor needs strong
> arguments and rationale why it has to be there rather than somewhere
> else.
> 
> Likewise perhaps the v4v hypercall could effectively be implemented with
> a multicall containing some grant copy ops and evtchn manipulations?
> 
> But in the absence of any descriptions of the whats, hows and whys of
> v4v its rather hard to have these sorts of conversations. The above are
> some concrete examples but I'm more interested in seeing the more
> general descriptions before we get into those.
> 

Here is some documentation of the Xen V4V API and the ring structure.
Let me know if you have other questions.

* Overview
** Architecture

v4v has a very simple architecture. The receiving domain registers a ring with xen. 
The sending domain requests that xen inserts data into the receiving domain's ring.
Notification that there is new data to read is delivered by a VIRQ, and a domain can
request an interrupt be generated when sufficient space is available in another domain's
ring. The code that inserts the data into the ring is in xen, and xen writes a header
describing the data and where it came from infront of the data. As both the ring manipulation
and the header are written by the hypervisor, the receiving domain can trust their content
and the format of the ring. 

** Addressing
v4v_addr_t identifies an endpoint address.
 typedef struct v4v_addr
 {
     uint32_t port;
     domid_t domain;
 } v4v_addr_t;
struct v4v_ring_id uniquely identifies a ring on the platform.

 struct v4v_ring_id
 {
    struct v4v_addr addr;
    domid_t partner;
 };

When a send operation is performed, xen will attempt to find a ring 
registered by destination domain, with the required port, and with
a partner of the sending domain. Failing that it will then search
for a ring with the correct port and destination domain, but with 
partner set to V4V_DOMID_ANY.

** Setup
A domain first generates a ring, and a structure describing the pages in the ring.
Rings must be page aligned, and contiguous in virtual memory, but need not be 
contiguous in physical(pfn) or machine(mfn) memory. A ring is uniquely identified
on the platform by its struct v4v_ring_id.

A ring is contained in a v4v_ring_t
 typedef struct v4v_ring
 {
    uint64_t magic;
    /*
     * Identifies ring_id - xen only looks at this during register/unregister
     * and will fill in id.addr.domain
     */
    struct v4v_ring_id id;
    /* length of ring[], must be a multiple of 16 */
    uint32_t len;
    /* rx_ptr - modified by domain */
    uint32_t rx_ptr;
    /* tx_ptr - modified by xen */
    volatile uint32_t tx_ptr;
    uint64_t reserved[4];
    volatile uint8_t ring[0];
 } v4v_ring_t;

To register the ring, xen also needs a list of pfn that the ring occupies.
This is provided in a v4v_pfn_list_t
 typedef struct v4v_pfn_list_t
 {
    uint64_t magic;
    uint32_t npage;
    uint32_t pad;
    uint64_t reserved[3];
    v4v_pfn_t pages[0];
 } v4v_pfn_list_t;

Registering the ring is done with a hypercall

int hypercall(NR_V4V,V4VOP_register_ring,v4v_ring_t *ring,v4v_pfn_list_t *pfn_list);

On registering, xen will check that the tx_ptr and rx_ptr values are valid (aligned
and within the size of the ring) and modify them if they are not, it will also update
id.addr.domain with the calling domain's domid and take an internal copy of all the
relevant information. After registration the only field that xen will read is
ring->rx_ptr, xen will write to ring->ring[] and ring->tx_ptr. 
Thus pfn_list can be freed after the registration call. Critically, registration is
idempotent, and all a domain need do after hibernation or migration is re-register all
its rings. (NB the id.addr.domain field may change).

** Sending

To send data a guest merely calls the send or sendv hypercall
int hypercall(NR_V4V,V4VOP_send,v4v_addr_t *src,v4v_addr_t *dst,void *buf, uint32_t len,
              uint32_t protocol);

the caller provides a source address, a destination address, a buffer, a number of bytes to copy
and a 32 bit protocol number. Xen ignores src->domain and instead uses the domain id of the caller.

Xen will attempt to insert into a ring with id.addr equal to dst, and with
id.partner equal to the caller's domid. Otherwise it will insert into a ring
with id.addr equal to dst and id.partner equal to V4V_DOMID_ANY. If the insert is successfull
then Xen will trigger the V4V VIRQ line in the receiving domain.

** Reception

Xen pads all messages on the ring to 16 bytes (the macro V4V_ROUNDUP is provided 
for convience), and inserts a message header infront of all messages it copies onto the ring.

 struct v4v_ring_message_header
 {
    uint32_t len;
    struct v4v_addr source;
    uint16_t pad;
    uint32_t protocol;
    uint8_t data[0];
 };

len is the number of bytes in the message including the struct v4v_ring_message_header
source specifies the source address from which the message came, source.domain is
set by xen, and source.port is taken from the arguments to the send or sendv call.
protocol is the protocol value given to the send call.

An  inline function is provided to make reading from the ring easier:

 ssize_t
 v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
              void *_buf, size_t t, int consume)

v4v_copy_out will copy at most t bytes from the ring r and place them in buf, if it
is non-null. If from and protocol are not NULL pointers then the source address and
 protocol number will by copied into them. If consume is non-zero then the ring's
receive pointer will be advanced. The function returns the number of bytes of payload
that the message has (ie. the number of bytes passed to the original send or sendv call).
Thus, v4v_copy_out(r,NULL,NULL,NULL,0,0); will return the number of bytes in the next message,
and  v4v_copy_out(r,NULL,NULL,NULL,0,1);  will return the number of bytes in the next message
and delete it from the ring.

** Notification
If the receiving ring is full in a send or sendv hypercall, the hypercall will return with
the error -EAGAIN. When sufficient space becomes available in the ring xen will raise the V4V VIRQ 
line.


Jean

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:35:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ81-00071M-1L; Thu, 07 Jun 2012 09:35:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@eu.citrix.com>) id 1ScYIS-0004WX-Fs
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 08:42:24 +0000
Received: from [85.158.139.83:40228] by server-2.bemta-5.messagelabs.com id
	79/10-20827-F6960DF4; Thu, 07 Jun 2012 08:42:23 +0000
X-Env-Sender: jean.guyader@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339058542!28412315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5608 invoked from network); 7 Jun 2012 08:42:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 08:42:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12874914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 08:42:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 09:42:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1ScYIQ-0006uv-EC;
	Thu, 07 Jun 2012 08:42:22 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1ScYNi-0003rv-3N;
	Thu, 07 Jun 2012 09:47:50 +0100
Date: Thu, 7 Jun 2012 09:47:50 +0100
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607084750.GD14635@spongy.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338558477.17466.121.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 07 Jun 2012 09:35:39 +0000
Cc: Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 01/06 02:47, Ian Campbell wrote:
> On Thu, 2012-05-31 at 16:07 +0100, Jean Guyader wrote:
> > V4V is a copy based inter vm communication system.
> > 
> > Please have a look at this thread for more detail
> > about V4V.
> > http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html
> > 
> > This patch series is work in progress but I wanted to
> > post it early enough so I can get feedback from people.
> 
> The main thing which is missing here, which makes it rather hard to
> review, is any kind of design documentation. It would also be great to
> see the rationale for why things have to be done this way.
> 
> For example it seems that there is a bunch of stuff being added to the
> hypervisor which could live in the context of some guest or service
> domain -- putting stuff like that in the hypervisor needs strong
> arguments and rationale why it has to be there rather than somewhere
> else.
> 
> Likewise perhaps the v4v hypercall could effectively be implemented with
> a multicall containing some grant copy ops and evtchn manipulations?
> 
> But in the absence of any descriptions of the whats, hows and whys of
> v4v its rather hard to have these sorts of conversations. The above are
> some concrete examples but I'm more interested in seeing the more
> general descriptions before we get into those.
> 

Here is some documentation of the Xen V4V API and the ring structure.
Let me know if you have other questions.

* Overview
** Architecture

v4v has a very simple architecture. The receiving domain registers a ring with xen. 
The sending domain requests that xen inserts data into the receiving domain's ring.
Notification that there is new data to read is delivered by a VIRQ, and a domain can
request an interrupt be generated when sufficient space is available in another domain's
ring. The code that inserts the data into the ring is in xen, and xen writes a header
describing the data and where it came from infront of the data. As both the ring manipulation
and the header are written by the hypervisor, the receiving domain can trust their content
and the format of the ring. 

** Addressing
v4v_addr_t identifies an endpoint address.
 typedef struct v4v_addr
 {
     uint32_t port;
     domid_t domain;
 } v4v_addr_t;
struct v4v_ring_id uniquely identifies a ring on the platform.

 struct v4v_ring_id
 {
    struct v4v_addr addr;
    domid_t partner;
 };

When a send operation is performed, xen will attempt to find a ring 
registered by destination domain, with the required port, and with
a partner of the sending domain. Failing that it will then search
for a ring with the correct port and destination domain, but with 
partner set to V4V_DOMID_ANY.

** Setup
A domain first generates a ring, and a structure describing the pages in the ring.
Rings must be page aligned, and contiguous in virtual memory, but need not be 
contiguous in physical(pfn) or machine(mfn) memory. A ring is uniquely identified
on the platform by its struct v4v_ring_id.

A ring is contained in a v4v_ring_t
 typedef struct v4v_ring
 {
    uint64_t magic;
    /*
     * Identifies ring_id - xen only looks at this during register/unregister
     * and will fill in id.addr.domain
     */
    struct v4v_ring_id id;
    /* length of ring[], must be a multiple of 16 */
    uint32_t len;
    /* rx_ptr - modified by domain */
    uint32_t rx_ptr;
    /* tx_ptr - modified by xen */
    volatile uint32_t tx_ptr;
    uint64_t reserved[4];
    volatile uint8_t ring[0];
 } v4v_ring_t;

To register the ring, xen also needs a list of pfn that the ring occupies.
This is provided in a v4v_pfn_list_t
 typedef struct v4v_pfn_list_t
 {
    uint64_t magic;
    uint32_t npage;
    uint32_t pad;
    uint64_t reserved[3];
    v4v_pfn_t pages[0];
 } v4v_pfn_list_t;

Registering the ring is done with a hypercall

int hypercall(NR_V4V,V4VOP_register_ring,v4v_ring_t *ring,v4v_pfn_list_t *pfn_list);

On registering, xen will check that the tx_ptr and rx_ptr values are valid (aligned
and within the size of the ring) and modify them if they are not, it will also update
id.addr.domain with the calling domain's domid and take an internal copy of all the
relevant information. After registration the only field that xen will read is
ring->rx_ptr, xen will write to ring->ring[] and ring->tx_ptr. 
Thus pfn_list can be freed after the registration call. Critically, registration is
idempotent, and all a domain need do after hibernation or migration is re-register all
its rings. (NB the id.addr.domain field may change).

** Sending

To send data a guest merely calls the send or sendv hypercall
int hypercall(NR_V4V,V4VOP_send,v4v_addr_t *src,v4v_addr_t *dst,void *buf, uint32_t len,
              uint32_t protocol);

the caller provides a source address, a destination address, a buffer, a number of bytes to copy
and a 32 bit protocol number. Xen ignores src->domain and instead uses the domain id of the caller.

Xen will attempt to insert into a ring with id.addr equal to dst, and with
id.partner equal to the caller's domid. Otherwise it will insert into a ring
with id.addr equal to dst and id.partner equal to V4V_DOMID_ANY. If the insert is successfull
then Xen will trigger the V4V VIRQ line in the receiving domain.

** Reception

Xen pads all messages on the ring to 16 bytes (the macro V4V_ROUNDUP is provided 
for convience), and inserts a message header infront of all messages it copies onto the ring.

 struct v4v_ring_message_header
 {
    uint32_t len;
    struct v4v_addr source;
    uint16_t pad;
    uint32_t protocol;
    uint8_t data[0];
 };

len is the number of bytes in the message including the struct v4v_ring_message_header
source specifies the source address from which the message came, source.domain is
set by xen, and source.port is taken from the arguments to the send or sendv call.
protocol is the protocol value given to the send call.

An  inline function is provided to make reading from the ring easier:

 ssize_t
 v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
              void *_buf, size_t t, int consume)

v4v_copy_out will copy at most t bytes from the ring r and place them in buf, if it
is non-null. If from and protocol are not NULL pointers then the source address and
 protocol number will by copied into them. If consume is non-zero then the ring's
receive pointer will be advanced. The function returns the number of bytes of payload
that the message has (ie. the number of bytes passed to the original send or sendv call).
Thus, v4v_copy_out(r,NULL,NULL,NULL,0,0); will return the number of bytes in the next message,
and  v4v_copy_out(r,NULL,NULL,NULL,0,1);  will return the number of bytes in the next message
and delete it from the ring.

** Notification
If the receiving ring is full in a send or sendv hypercall, the hypercall will return with
the error -EAGAIN. When sufficient space becomes available in the ring xen will raise the V4V VIRQ 
line.


Jean

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ8C-00075u-OO; Thu, 07 Jun 2012 09:35:52 +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 1ScNcW-00077K-J8
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 21:18:26 +0000
Received: from [85.158.139.83:5292] by server-12.bemta-5.messagelabs.com id
	93/56-18374-F19CFCF4; Wed, 06 Jun 2012 21:18:23 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339017489!31462131!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NTE3MA==\n,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDY4ODQgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6651 invoked from network); 6 Jun 2012 21:18:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 21:18:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56LHugt006974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 21:17:57 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
	q56LHsKJ023387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 21:17:55 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
	q56LHrn5005232; Wed, 6 Jun 2012 16:17:53 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 14:17:53 -0700
Date: Wed, 6 Jun 2012 14:17:51 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606141751.37305f89@mantra.us.oracle.com>
In-Reply-To: <1338974024.32319.29.camel@zakaz.uk.xensource.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.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
Content-Type: multipart/mixed; boundary="MP_/61SL/dFgoelVIa2N/5RWWnn"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Thu, 07 Jun 2012 09:35:51 +0000
Cc: James Paton <paton@cs.wisc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/61SL/dFgoelVIa2N/5RWWnn
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, 6 Jun 2012 10:13:44 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote:
> > Hi,
> > 
> > Apologies if this is not the appropriate list, but I thought I
> > would have better luck here than on xen-users.
> > 
> > I'm a CS graduate student hacking on the xen-blkback driver and
> > would like to be able to debug it using gdb over serial. I have
> > spent a great deal of time on this with no success (more details
> > can be found at http://bit.ly/KMEF6o (Stack Overflow)). 
> > 
> > It eventually occurred to me that it might not even be possible to
> > do what I'm trying to do if Xen intercepts interrupts from the
> > serial port and tries to direct them to dom0 through some
> > unexpected channel. Then, after I've done `echo g
> > > /proc/sysrq_trigger`, the kernel debugger might not see the
> > > interrupt. Can anyone confirm or disconfirm this? 
> 
> It's not something I've ever tried but I expect that if you avoid
> console=com1 (or com*) on your hypervisor command line then the com
> port should be available for dom0 just like on native.
> 
> Alternatively you could perhaps separate the two by using com1 for Xen
> and com2/ttyS1 for dom0/kdb etc.
> 
> I've no idea if kdb would be expected to work over hvc*. I suspect
> you'd be treading fresh ground with that one...
> 
> I'd also start by taking virtual box out of the equation on the host
> side. Start by using a MacOS terminal emulator and checking that you
> can see the dom0 console messages and login via a getty running on
> ttyS0 before trying to hook up gdb.
> 
> > What is the usual procedure for debugging the Dom0 kernel?
> 
> Printk ;-)
> 
> Ian.


I wrote up a debugger for xen, also (mis)named kdb. It halts the 
system, lets you poke memory, data structs, set breakpoints, etc.
To use it, you must have prior experience of a kernel debugger. I
am attaching patch build for changeset 25287 in unstable tree, if you
wanna try it. Start with kdb/README.

Mukesh


--MP_/61SL/dFgoelVIa2N/5RWWnn
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=kdb.patch

diff -r 54c8c9eaee92 xen/Makefile
--- a/xen/Makefile	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -61,6 +61,7 @@ _clean: delete-unfresh-files
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C kdb clean
 	rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET)-syms *~ core
 	rm -f include/asm-*/asm-offsets.h
 	[ -d tools/figlet ] && rm -f .banner*
@@ -129,7 +130,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h
 	  echo ""; \
 	  echo "#endif") <$< >$@
 
-SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers
+SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers kdb
 define all_sources
     ( find include/asm-$(TARGET_ARCH) -name '*.h' -print; \
       find include -name 'asm-*' -prune -o -name '*.h' -print; \
diff -r 54c8c9eaee92 xen/Rules.mk
--- a/xen/Rules.mk	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/Rules.mk	Wed Jun 06 14:17:11 2012 -0700
@@ -10,6 +10,7 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto           ?= n
+kdb           ?= n
 
 include $(XEN_ROOT)/Config.mk
 
@@ -40,6 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/d
 ALL_OBJS-y               += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(kdb)          += $(BASEDIR)/kdb/built_in.o
 
 CFLAGS-y                += -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
@@ -53,6 +55,7 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFIL
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(kdb)           += -DXEN_KDB_CONFIG
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y                += -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff -r 54c8c9eaee92 xen/arch/x86/hvm/svm/entry.S
--- a/xen/arch/x86/hvm/svm/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/svm/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -59,12 +59,23 @@ ENTRY(svm_asm_do_resume)
         get_current(bx)
         CLGI
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         testl $~0,(r(dx),r(ax),1)
         jnz  .Lsvm_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0, VCPU_nsvm_hap_enabled(r(bx))
 UNLIKELY_START(nz, nsvm_hap)
         mov  VCPU_nhvm_p2m(r(bx)),r(ax)
diff -r 54c8c9eaee92 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/svm/svm.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2170,6 +2170,10 @@ void svm_vmexit_handler(struct cpu_user_
         break;
 
     case VMEXIT_EXCEPTION_DB:
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+	    break;
+#endif
         if ( !v->domain->debugger_attached )
             goto exit_and_crash;
         domain_pause_for_debugger();
@@ -2182,6 +2186,10 @@ void svm_vmexit_handler(struct cpu_user_
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
         __update_guest_eip(regs, inst_len);
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_int3, regs))
+            break;
+#endif
         current->arch.gdbsx_vcpu_event = TRAP_int3;
         domain_pause_for_debugger();
         break;
diff -r 54c8c9eaee92 xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Wed Jun 06 14:17:11 2012 -0700
@@ -315,6 +315,36 @@ void setup_vmcb_dump(void)
     register_keyhandler('v', &vmcb_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+/* did == 0 : display for all HVM domains. domid 0 is never HVM.
+ *  * vid == -1 : display for all HVM VCPUs
+ *   */
+void kdb_dump_vmcb(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain (dp) {
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+            kdbp("  VMCB [domid: %d  vcpu:%d]:\n", dp->domain_id, vp->vcpu_id);
+            svm_vmcb_dump("kdb", vp->arch.hvm_svm.vmcb);
+            kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    rcu_read_unlock(&domlist_read_lock);
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 54c8c9eaee92 xen/arch/x86/hvm/vmx/entry.S
--- a/xen/arch/x86/hvm/vmx/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/vmx/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -124,12 +124,23 @@ vmx_asm_do_vmentry:
         get_current(bx)
         cli
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         cmpl $0,(r(dx),r(ax),1)
         jnz  .Lvmx_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0xff,VCPU_vmx_emulate(r(bx))
         jnz .Lvmx_goto_emulator
         testb $0xff,VCPU_vmx_realmode(r(bx))
diff -r 54c8c9eaee92 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Wed Jun 06 14:17:11 2012 -0700
@@ -1117,6 +1117,13 @@ void vmx_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
+#if defined(XEN_KDB_CONFIG)
+    if (kdb_dr7)
+        __vmwrite(GUEST_DR7, kdb_dr7);
+    else
+        __vmwrite(GUEST_DR7, 0);
+#endif
+
     debug_state = v->domain->debugger_attached
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_INT3]
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP];
@@ -1326,6 +1333,220 @@ void setup_vmcs_dump(void)
     register_keyhandler('v', &vmcs_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+#define GUEST_EFER      0x2806   /* see page 23-20 */
+#define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+
+/* it's a shame we can't use vmcs_dump_vcpu(), but it does vmx_vmcs_enter which
+ * will IPI other CPUs. also, print a subset relevant to software debugging */
+static void noinline kdb_print_vmcs(struct vcpu *vp)
+{
+    struct cpu_user_regs *regs = &vp->arch.user_regs;
+    unsigned long long x;
+
+    kdbp("*** Guest State ***\n");
+    kdbp("CR0: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR0),
+         (unsigned long long)vmr(CR0_READ_SHADOW), 
+         (unsigned long long)vmr(CR0_GUEST_HOST_MASK));
+    kdbp("CR4: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR4),
+         (unsigned long long)vmr(CR4_READ_SHADOW), 
+         (unsigned long long)vmr(CR4_GUEST_HOST_MASK));
+    kdbp("CR3: actual=0x%016llx, target_count=%d\n",
+         (unsigned long long)vmr(GUEST_CR3),
+         (int)vmr(CR3_TARGET_COUNT));
+    kdbp("     target0=%016llx, target1=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE0),
+         (unsigned long long)vmr(CR3_TARGET_VALUE1));
+    kdbp("     target2=%016llx, target3=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE2),
+         (unsigned long long)vmr(CR3_TARGET_VALUE3));
+    kdbp("RSP = 0x%016llx (0x%016llx)  RIP = 0x%016llx (0x%016llx)\n", 
+         (unsigned long long)vmr(GUEST_RSP),
+         (unsigned long long)regs->esp,
+         (unsigned long long)vmr(GUEST_RIP),
+         (unsigned long long)regs->eip);
+    kdbp("RFLAGS=0x%016llx (0x%016llx)  DR7 = 0x%016llx\n", 
+         (unsigned long long)vmr(GUEST_RFLAGS),
+         (unsigned long long)regs->eflags,
+         (unsigned long long)vmr(GUEST_DR7));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+         (unsigned long long)vmr(GUEST_SYSENTER_ESP),
+         (int)vmr(GUEST_SYSENTER_CS),
+         (unsigned long long)vmr(GUEST_SYSENTER_EIP));
+    vmx_dump_sel("CS", GUEST_CS_SELECTOR);
+    vmx_dump_sel("DS", GUEST_DS_SELECTOR);
+    vmx_dump_sel("SS", GUEST_SS_SELECTOR);
+    vmx_dump_sel("ES", GUEST_ES_SELECTOR);
+    vmx_dump_sel("FS", GUEST_FS_SELECTOR);
+    vmx_dump_sel("GS", GUEST_GS_SELECTOR);
+    vmx_dump_sel2("GDTR", GUEST_GDTR_LIMIT);
+    vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
+    vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
+    vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
+    kdbp("Guest PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
+    x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
+    x |= (uint32_t)vmr(TSC_OFFSET);
+    kdbp("TSC Offset = %016llx\n", x);
+    x  = (unsigned long long)vmr(GUEST_IA32_DEBUGCTL_HIGH) << 32;
+    x |= (uint32_t)vmr(GUEST_IA32_DEBUGCTL);
+    kdbp("DebugCtl=%016llx DebugExceptions=%016llx\n", x,
+           (unsigned long long)vmr(GUEST_PENDING_DBG_EXCEPTIONS));
+    kdbp("Interruptibility=%04x ActivityState=%04x\n",
+           (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
+           (int)vmr(GUEST_ACTIVITY_STATE));
+
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
+    kdbp("\n*** Host State ***\n");
+    kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
+           (unsigned long long)vmr(HOST_RSP),
+           (unsigned long long)vmr(HOST_RIP));
+    kdbp("CS=%04x DS=%04x ES=%04x FS=%04x GS=%04x SS=%04x TR=%04x\n",
+           (uint16_t)vmr(HOST_CS_SELECTOR),
+           (uint16_t)vmr(HOST_DS_SELECTOR),
+           (uint16_t)vmr(HOST_ES_SELECTOR),
+           (uint16_t)vmr(HOST_FS_SELECTOR),
+           (uint16_t)vmr(HOST_GS_SELECTOR),
+           (uint16_t)vmr(HOST_SS_SELECTOR),
+           (uint16_t)vmr(HOST_TR_SELECTOR));
+    kdbp("FSBase=%016llx GSBase=%016llx TRBase=%016llx\n",
+           (unsigned long long)vmr(HOST_FS_BASE),
+           (unsigned long long)vmr(HOST_GS_BASE),
+           (unsigned long long)vmr(HOST_TR_BASE));
+    kdbp("GDTBase=%016llx IDTBase=%016llx\n",
+           (unsigned long long)vmr(HOST_GDTR_BASE),
+           (unsigned long long)vmr(HOST_IDTR_BASE));
+    kdbp("CR0=%016llx CR3=%016llx CR4=%016llx\n",
+           (unsigned long long)vmr(HOST_CR0),
+           (unsigned long long)vmr(HOST_CR3),
+           (unsigned long long)vmr(HOST_CR4));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+           (unsigned long long)vmr(HOST_SYSENTER_ESP),
+           (int)vmr(HOST_SYSENTER_CS),
+           (unsigned long long)vmr(HOST_SYSENTER_EIP));
+    kdbp("Host PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(HOST_PAT_HIGH), (uint32_t)vmr(HOST_PAT));
+
+    kdbp("\n*** Control State ***\n");
+    kdbp("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n",
+           (uint32_t)vmr(PIN_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(CPU_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(SECONDARY_VM_EXEC_CONTROL));
+    kdbp("EntryControls=%08x ExitControls=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_CONTROLS),
+           (uint32_t)vmr(VM_EXIT_CONTROLS));
+    kdbp("ExceptionBitmap=%08x\n",
+           (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
+    kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_INTR_INFO),
+           (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("VMExit: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_EXIT_INTR_INFO),
+           (uint32_t)vmr(VM_EXIT_INTR_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("        reason=%08x qualification=%08x\n",
+           (uint32_t)vmr(VM_EXIT_REASON),
+           (uint32_t)vmr(EXIT_QUALIFICATION));
+    kdbp("IDTVectoring: info=%08x errcode=%08x\n",
+           (uint32_t)vmr(IDT_VECTORING_INFO),
+           (uint32_t)vmr(IDT_VECTORING_ERROR_CODE));
+    kdbp("TPR Threshold = 0x%02x\n",
+           (uint32_t)vmr(TPR_THRESHOLD));
+    kdbp("EPT pointer = 0x%08x%08x\n",
+           (uint32_t)vmr(EPT_POINTER_HIGH), (uint32_t)vmr(EPT_POINTER));
+    kdbp("Virtual processor ID = 0x%04x\n",
+           (uint32_t)vmr(VIRTUAL_PROCESSOR_ID));
+    kdbp("=================================================================\n");
+}
+
+/* Flush VMCS on this cpu if it needs to: 
+ *   - Upon leaving kdb, the HVM cpu will resume in vmx_vmexit_handler() and 
+ *     do __vmreads. So, the VMCS pointer can't be left cleared.
+ *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
+ *     vmlaunch must be done and not vmresume. This means, we must clear 
+ *     arch_vmx->launched.
+ */
+void kdb_curr_cpu_flush_vmcs(void)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    int ccpu = smp_processor_id();
+    struct vmcs_struct *cvp = this_cpu(current_vmcs);
+
+    if (this_cpu(current_vmcs) == NULL)
+        return;             /* no HVM active on this CPU */
+
+    kdbp("KDB:[%d] curvmcs:%lx/%lx\n", ccpu, cvp, virt_to_maddr(cvp));
+
+    /* looks like we got one. unfortunately, current_vmcs points to vmcs 
+     * and not VCPU, so we gotta search the entire list... */
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        for_each_vcpu (dp, vp) {
+            if ( vp->arch.hvm_vmx.vmcs == cvp ) {
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched = 0;
+                this_cpu(current_vmcs) = NULL;
+                kdbp("KDB:[%d] %d:%d current_vmcs:%lx flushed\n", 
+		     ccpu, dp->domain_id, vp->vcpu_id, cvp, virt_to_maddr(cvp));
+            }
+        }
+    }
+}
+
+/*
+ * domid == 0 : display for all HVM domains  (dom0 is never an HVM domain)
+ * vcpu id == -1 : display all vcpuids
+ * PreCondition: all HVM cpus (including current cpu) have flushed VMCS
+ */
+void kdb_dump_vmcs(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    struct vmcs_struct  *vmcsp;
+    u64 addr = -1;
+
+    ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
+    __vmptrst(&addr);
+
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+	    vmcsp = vp->arch.hvm_vmx.vmcs;
+            kdbp("VMCS %lx/%lx [domid:%d (%p)  vcpu:%d (%p)]:\n", vmcsp,
+	         virt_to_maddr(vmcsp), dp->domain_id, dp, vp->vcpu_id, vp);
+            __vmptrld(virt_to_maddr(vmcsp));
+            kdb_print_vmcs(vp);
+            __vmpclear(virt_to_maddr(vmcsp));
+            vp->arch.hvm_vmx.launched = 0;
+        }
+        kdbp("\n");
+    }
+    /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
+    if (addr && addr != (u64)-1)
+        __vmptrld(addr);
+}
+#endif
 
 /*
  * Local variables:
diff -r 54c8c9eaee92 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2197,11 +2197,14 @@ static void vmx_failed_vmentry(unsigned 
         printk("reason not known yet!");
         break;
     }
-
+#if defined(XEN_KDB_CONFIG)
+    kdbp("\n************* VMCS Area **************\n");
+    kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
-
+#endif
     domain_crash(curr->domain);
 }
 
@@ -2429,6 +2432,12 @@ void vmx_vmexit_handler(struct cpu_user_
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
+
+#if defined(XEN_KDB_CONFIG)
+            /* TRAP_debug: IP points correctly to next instr */
+            if (kdb_handle_trap_entry(vector, regs))
+                break;
+#endif
             domain_pause_for_debugger();
             break;
         case TRAP_int3: 
@@ -2437,6 +2446,13 @@ void vmx_vmexit_handler(struct cpu_user_
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
+#if defined(XEN_KDB_CONFIG)
+                /* vmcs.IP points to bp, kdb expects bp+1. Hence after the above
+                 * update_guest_eip which updates to bp+1. works for gdbsx too 
+                 */
+                if (kdb_handle_trap_entry(vector, regs))
+                    break;
+#endif
                 current->arch.gdbsx_vcpu_event = TRAP_int3;
                 domain_pause_for_debugger();
                 break;
@@ -2716,6 +2732,10 @@ void vmx_vmexit_handler(struct cpu_user_
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
+#if defined(XEN_KDB_CONFIG)
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+            break;
+#endif
         if ( v->arch.hvm_vcpu.single_step ) {
           hvm_memory_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
diff -r 54c8c9eaee92 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/irq.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2296,3 +2296,29 @@ bool_t hvm_domain_use_pirq(const struct 
     return is_hvm_domain(d) && pirq &&
            pirq->arch.hvm.emuirq != IRQ_UNBOUND; 
 }
+
+#ifdef XEN_KDB_CONFIG
+void kdb_prnt_guest_mapped_irqs(void)
+{
+    int irq, j;
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    kdbp("irq  vec  aff  type  domid:mapped-pirq pairs  (all in decimal)\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+        irq_guest_action_t *actp = (irq_guest_action_t *)dp->action;
+
+        if (!dp->handler ||dp->handler==&no_irq_type || !(dp->status&IRQ_GUEST))
+            continue;
+
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %3d %3s %-13s ", irq, archp->vector, affstr,
+             dp->handler->typename);
+        for (j=0; j < actp->nr_guests; j++)
+            kdbp("%03d:%04d ", actp->guest[j]->domain_id,
+                 domain_irq_to_pirq(actp->guest[j], irq));
+        kdbp("\n");
+    }
+}
+#endif
diff -r 54c8c9eaee92 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/setup.c	Wed Jun 06 14:17:11 2012 -0700
@@ -47,6 +47,13 @@
 #include <xen/cpu.h>
 #include <asm/nmi.h>
 
+#ifdef XEN_KDB_CONFIG
+#include <asm/debugger.h>
+
+int opt_earlykdb=0;
+boolean_param("earlykdb", opt_earlykdb);
+#endif
+
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
 boolean_param("nosmp", opt_nosmp);
@@ -1242,6 +1249,11 @@ void __init __start_xen(unsigned long mb
 
     trap_init();
 
+#ifdef XEN_KDB_CONFIG
+    kdb_init();
+    if (opt_earlykdb)
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+#endif
     rcu_init();
     
     early_time_init();
diff -r 54c8c9eaee92 xen/arch/x86/smp.c
--- a/xen/arch/x86/smp.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/smp.c	Wed Jun 06 14:17:11 2012 -0700
@@ -273,7 +273,7 @@ void smp_send_event_check_mask(const cpu
  * Structure and data for smp_call_function()/on_selected_cpus().
  */
 
-static void __smp_call_function_interrupt(void);
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs);
 static DEFINE_SPINLOCK(call_lock);
 static struct call_data_struct {
     void (*func) (void *info);
@@ -321,7 +321,7 @@ void on_selected_cpus(
     if ( cpumask_test_cpu(smp_processor_id(), &call_data.selected) )
     {
         local_irq_disable();
-        __smp_call_function_interrupt();
+        __smp_call_function_interrupt(NULL);
         local_irq_enable();
     }
 
@@ -390,7 +390,7 @@ void event_check_interrupt(struct cpu_us
     this_cpu(irq_count)++;
 }
 
-static void __smp_call_function_interrupt(void)
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs)
 {
     void (*func)(void *info) = call_data.func;
     void *info = call_data.info;
@@ -411,6 +411,11 @@ static void __smp_call_function_interrup
     {
         mb();
         cpumask_clear_cpu(cpu, &call_data.selected);
+#ifdef XEN_KDB_CONFIG
+        if (info && !strcmp(info, "XENKDB")) {           /* called from kdb */
+                (*(void (*)(struct cpu_user_regs *, void *))func)(regs, info);
+        } else
+#endif
         (*func)(info);
     }
 
@@ -421,5 +426,5 @@ void call_function_interrupt(struct cpu_
 {
     ack_APIC_irq();
     perfc_incr(ipis);
-    __smp_call_function_interrupt();
+    __smp_call_function_interrupt(regs);
 }
diff -r 54c8c9eaee92 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/time.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2007,6 +2007,46 @@ static int __init setup_dump_softtsc(voi
 }
 __initcall(setup_dump_softtsc);
 
+#ifdef XEN_KDB_CONFIG
+void kdb_time_resume(int update_domains)
+{
+        s_time_t now;
+        int ccpu = smp_processor_id();
+        struct cpu_time *t = &this_cpu(cpu_time);
+
+        if (!plt_src.read_counter)            /* not initialized for earlykdb */
+                return;
+
+        if (update_domains) {
+                plt_stamp = plt_src.read_counter();
+                platform_timer_stamp = plt_stamp64;
+                platform_time_calibration();
+                do_settime(get_cmos_time(), 0, read_platform_stime());
+        }
+        if (local_irq_is_enabled())
+                kdbp("kdb BUG: enabled in time_resume(). ccpu:%d\n", ccpu);
+
+        rdtscll(t->local_tsc_stamp);
+        now = read_platform_stime();
+        t->stime_master_stamp = now;
+        t->stime_local_stamp  = now;
+
+        update_vcpu_system_time(current);
+
+        if (update_domains)
+                set_timer(&calibration_timer, NOW() + EPOCH);
+}
+
+void kdb_dump_time_pcpu(void)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        kdbp("[%d]: cpu_time: %016lx\n", cpu, &per_cpu(cpu_time, cpu));
+        kdbp("[%d]: cpu_calibration: %016lx\n", cpu, 
+             &per_cpu(cpu_calibration, cpu));
+    }
+}
+#endif
 /*
  * Local variables:
  * mode: C
diff -r 54c8c9eaee92 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/traps.c	Wed Jun 06 14:17:11 2012 -0700
@@ -225,7 +225,7 @@ static void show_trace(struct cpu_user_r
 
 #else
 
-static void show_trace(struct cpu_user_regs *regs)
+void show_trace(struct cpu_user_regs *regs)
 {
     unsigned long *frame, next, addr, low, high;
 
@@ -3325,6 +3325,10 @@ void do_nmi(struct cpu_user_regs *regs)
     if ( nmi_callback(regs, cpu) )
         return;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_enabled && kdb_handle_trap_entry(TRAP_nmi, regs))
+        return;
+#endif
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
 
diff -r 54c8c9eaee92 xen/arch/x86/x86_64/compat/entry.S
--- a/xen/arch/x86/x86_64/compat/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/x86_64/compat/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -95,6 +95,10 @@ compat_skip_clobber:
 /* %rbx: struct vcpu */
 ENTRY(compat_test_all_events)
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG
+        testl $1, kdb_session_begun(%rip)
+        jnz   compat_restore_all_guest
+#endif
 /*compat_test_softirqs:*/
         movl  VCPU_processor(%rbx),%eax
         shlq  $IRQSTAT_shift,%rax
diff -r 54c8c9eaee92 xen/arch/x86/x86_64/entry.S
--- a/xen/arch/x86/x86_64/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/x86_64/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -184,6 +184,10 @@ skip_clobber:
 /* %rbx: struct vcpu */
 test_all_events:
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG                   /* 64bit dom0 will resume here */
+        testl $1, kdb_session_begun(%rip)
+        jnz   restore_all_guest
+#endif
 /*test_softirqs:*/  
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
@@ -545,6 +549,13 @@ ENTRY(debug)
 
 ENTRY(int3)
         pushq $0
+#ifdef XEN_KDB_CONFIG
+        pushq %rax
+        GET_CPUINFO_FIELD(CPUINFO_processor_id, %rax)
+        movq  (%rax), %rax
+        lock  bts %rax, kdb_cpu_traps(%rip)
+        popq  %rax
+#endif
         movl  $TRAP_int3,4(%rsp)
         jmp   handle_exception
 
diff -r 54c8c9eaee92 xen/common/domain.c
--- a/xen/common/domain.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/domain.c	Wed Jun 06 14:17:11 2012 -0700
@@ -530,6 +530,14 @@ void domain_shutdown(struct domain *d, u
 {
     struct vcpu *v;
 
+#ifdef XEN_KDB_CONFIG
+    if (reason == SHUTDOWN_crash) {
+        if ( IS_PRIV(d) )
+            kdb_trap_immed(KDB_TRAP_FATAL);
+        else
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+    }
+#endif
     spin_lock(&d->shutdown_lock);
 
     if ( d->shutdown_code == -1 )
@@ -624,7 +632,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* send VIRQ_DEBUGGER to guest only if gdbsx_vcpu_event is not active */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r 54c8c9eaee92 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/sched_credit.c	Wed Jun 06 14:17:11 2012 -0700
@@ -1475,6 +1475,33 @@ csched_dump_vcpu(struct csched_vcpu *svc
     printk("\n");
 }
 
+#ifdef XEN_KDB_CONFIG
+static void kdb_csched_dump(int cpu)
+{
+    struct csched_pcpu *pcpup = CSCHED_PCPU(cpu);
+    struct vcpu *scurrvp = (CSCHED_VCPU(current))->vcpu;
+    struct list_head *tmp, *runq = RUNQ(cpu);
+
+    kdbp("    csched_pcpu: %p\n", pcpup);
+    kdbp("    curr csched:%p {vcpu:%p id:%d domid:%d}\n", (current)->sched_priv,
+         scurrvp, scurrvp->vcpu_id, scurrvp->domain->domain_id);
+    kdbp("    runq:\n");
+
+    /* next is top of struct, so screw stupid, ugly hard to follow macros */
+    if (offsetof(struct csched_vcpu, runq_elem.next) != 0) {
+        kdbp("next is not first in struct csched_vcpu. please fixme\n");
+        return;        /* otherwise for loop will crash */
+    }
+    for (tmp = runq->next; tmp != runq; tmp = tmp->next) {
+
+        struct csched_vcpu *csp = (struct csched_vcpu *)tmp;
+        struct vcpu *vp = csp->vcpu;
+        kdbp("      csp:%p pri:%02d vcpu: {p:%p id:%d domid:%d}\n", csp,
+             csp->pri, vp, vp->vcpu_id, vp->domain->domain_id);
+    };
+}
+#endif
+
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
@@ -1484,6 +1511,10 @@ csched_dump_pcpu(const struct scheduler 
     int loop;
 #define cpustr keyhandler_scratch
 
+#ifdef XEN_KDB_CONFIG
+    kdb_csched_dump(cpu);
+    return;
+#endif
     spc = CSCHED_PCPU(cpu);
     runq = &spc->runq;
 
diff -r 54c8c9eaee92 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/schedule.c	Wed Jun 06 14:17:11 2012 -0700
@@ -1454,6 +1454,25 @@ void wait(void)
     schedule();
 }
 
+#ifdef XEN_KDB_CONFIG
+void kdb_print_sched_info(void)
+{
+    int cpu;
+
+    kdbp("Scheduler: name:%s opt_name:%s id:%d\n", ops.name, ops.opt_name,
+         ops.sched_id);
+    kdbp("per cpu schedule_data:\n");
+    for_each_online_cpu(cpu) {
+        struct schedule_data *p =  &per_cpu(schedule_data, cpu);
+        kdbp("  cpu:%d  &(per cpu)schedule_data:%p\n", cpu, p);
+        kdbp("         curr:%p sched_priv:%p\n", p->curr, p->sched_priv);
+        kdbp("\n");
+        ops.dump_cpu_state(&ops, cpu);
+        kdbp("\n");
+    }
+}
+#endif
+
 #ifdef CONFIG_COMPAT
 #include "compat/schedule.c"
 #endif
diff -r 54c8c9eaee92 xen/common/symbols.c
--- a/xen/common/symbols.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/symbols.c	Wed Jun 06 14:17:11 2012 -0700
@@ -168,3 +168,21 @@ void __print_symbol(const char *fmt, uns
 
     spin_unlock_irqrestore(&lock, flags);
 }
+
+#ifdef XEN_KDB_CONFIG
+/*
+ *  * Given a symbol, return its address 
+ *   */
+unsigned long address_lookup(char *symp)
+{
+    int i, off = 0;
+    char namebuf[KSYM_NAME_LEN+1];
+
+    for (i=0; i < symbols_num_syms; i++) {
+        off = symbols_expand_symbol(off, namebuf);
+        if (strcmp(namebuf, symp) == 0)                  /* found it */
+            return symbols_address(i);
+    }
+    return 0;
+}
+#endif
diff -r 54c8c9eaee92 xen/common/timer.c
--- a/xen/common/timer.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/timer.c	Wed Jun 06 14:17:11 2012 -0700
@@ -643,6 +643,48 @@ void __init timer_init(void)
     register_keyhandler('a', &dump_timerq_keyhandler);
 }
 
+#ifdef XEN_KDB_CONFIG
+#include <xen/symbols.h>
+void kdb_dump_timer_queues(void)
+{
+    struct timer  *t;
+    struct timers *ts;
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1];
+    int cpu, j;
+    u64 tsc;
+
+    for_each_online_cpu( cpu )
+    {
+        ts = &per_cpu(timers, cpu);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
+
+        /* timers in the heap */
+        for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
+            t = ts->heap[j];
+            kdbp("  %d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+        /* timers on the link list */
+        for ( t = ts->list, j = 0; t != NULL; t = t->list_next, j++ ) {
+            kdbp(" L%d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+    }
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 54c8c9eaee92 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/drivers/char/console.c	Wed Jun 06 14:17:11 2012 -0700
@@ -295,6 +295,21 @@ static void serial_rx(char c, struct cpu
 {
     static int switch_code_count = 0;
 
+#ifdef XEN_KDB_CONFIG
+    /* if ctrl-\ pressed and kdb handles it, return */
+    if (kdb_enabled && c == 0x1c) {
+        if (!kdb_session_begun) {
+            if (kdb_keyboard(regs))
+                return;
+        } else {
+            kdbp("Sorry... kdb session already active.. please try again..\n");
+            return;
+        }
+    }
+    if (kdb_session_begun)      /* kdb should already be polling */
+        return;                 /* swallow chars so they don't buffer in dom0 */
+#endif
+
     if ( switch_code && (c == switch_code) )
     {
         /* We eat CTRL-<switch_char> in groups of 3 to switch console input. */
@@ -710,6 +725,18 @@ void console_end_sync(void)
     atomic_dec(&print_everything);
 }
 
+#ifdef XEN_KDB_CONFIG
+void console_putc(char c)
+{
+    serial_putc(sercon_handle, c);
+}
+
+int console_getc(void)
+{
+    return serial_getc(sercon_handle);
+}
+#endif
+
 /*
  * printk rate limiting, lifted from Linux.
  *
diff -r 54c8c9eaee92 xen/include/asm-x86/debugger.h
--- a/xen/include/asm-x86/debugger.h	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/include/asm-x86/debugger.h	Wed Jun 06 14:17:11 2012 -0700
@@ -39,7 +39,11 @@
 #define DEBUGGER_trap_fatal(_v, _r) \
     if ( debugger_trap_fatal(_v, _r) ) return;
 
-#if defined(CRASH_DEBUG)
+#if defined(XEN_KDB_CONFIG)
+#define debugger_trap_immediate() kdb_trap_immed(KDB_TRAP_NONFATAL)
+#define debugger_trap_fatal(_v, _r) kdb_trap_fatal(_v, _r)
+
+#elif defined(CRASH_DEBUG)
 
 #include <xen/gdbstub.h>
 
@@ -70,6 +74,10 @@ static inline int debugger_trap_entry(
 {
     struct vcpu *v = current;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_handle_trap_entry(vector, regs))
+        return 1;
+#endif
     if ( guest_kernel_mode(v, regs) && v->domain->debugger_attached &&
          ((vector == TRAP_int3) || (vector == TRAP_debug)) )
     {
diff -r 54c8c9eaee92 xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/include/xen/lib.h	Wed Jun 06 14:17:11 2012 -0700
@@ -116,4 +116,7 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+#ifdef XEN_KDB_CONFIG
+#include "../../kdb/include/kdb_extern.h"
+#endif
 #endif /* __LIB_H__ */
diff -r 54c8c9eaee92 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/include/xen/sched.h	Wed Jun 06 14:17:11 2012 -0700
@@ -576,11 +576,14 @@ extern void (*dead_idle) (void);
 unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
-
+#ifdef XEN_KDB_CONFIG
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
diff -r 54c8c9eaee92 xen/kdb/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,5 @@
+
+obj-y		+= kdbmain.o kdb_cmds.o kdb_io.o 
+
+subdir-y += x86 guest
+
diff -r 54c8c9eaee92 xen/kdb/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/README	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,243 @@
+
+Welcome to kdb for xen, a hypervisor built in debugger.
+
+FEATURES:
+   - set breakpoints in hypervisor
+   - examine virt/machine memory, registers, domains, vcpus, etc...
+   - single step, single step till jump/call, step over call to next
+     instruction after the call.
+   - examine memory of a PV/HVM guest. 
+   - set breakpoints, single step, etc... for a PV guest.
+   - breaking into the debugger will freeze the system, all CPUs will pause,
+     no interrupts are acknowledged in the debugger. (Hence, the wall clock
+     will drift)
+   - single step will step only that cpu.
+   - earlykdb: break into kdb very early during boot. Put "earlykdb" on the
+               xen command line in grub.conf.
+   - generic tracing functions (see below) for quick tracing to debug timing
+     related problems. To use:
+        o set KDBTRCMAX to max num of recs in circular trc buffer in kdbmain.c
+	o call kdb_trc() from anywhere in xen
+	o turn tracing on by setting kdb_trcon in kdbmain.c or trcon command.
+	o trcp in kdb will give hints to dump trace recs. Use dd to see buffer
+	o trcz will zero out the entire buffer if needed.
+
+NOTE:
+   - since almost all numbers are in hex, 0x is not prefixed. Instead, decimal
+     numbers are preceded by $, as in $17 (sorry, one gets used to it). Note,
+     vcpu num, cpu num, domid are always displayed in decimal, without $.
+   - watchdog must be disabled to use kdb
+
+ISSUES:
+   - Currently, debug hypervisor is not supported. Make sure NDEBUG is defined
+     or compile with debug=n
+   - "timer went backwards" messages on dom0, but kdb/hyp should be fine.
+     I usually do "echo 2 > /proc/sys/kernel/printk" when using kdb.
+   - 32bit hypervisor may hang. Tested on 64bit hypervisor only.
+    
+
+TO BUILD:
+ - do >make kdb=y
+
+HOW TO USE:
+  1. A serial line is needed to use the debugger. Set up a serial line
+     from the source machine to target victim. Make sure the serial line
+     is working properly by displaying login prompt and loging in etc....
+
+  2. Add following to grub.conf:
+        kernel /xen.kdb console=com1,vga com1=57600,8n1 dom0_mem=542M
+
+        (57600 or whatever used in step 1 above)
+
+  3. Boot the hypervisor built with the debugger. 
+
+  4. ctrl-\ (ctrl and backslash) will break into the debugger. If the system is
+     badly hung, pressing NMI would also break into it. However, once kdb is
+     entered via NMI, normal execution can't continue.
+
+  5. type 'h' for list of commands.
+
+  6. Command line editing is limited to backspace. ctrl-c to start a new cmd.
+
+
+
+GUEST debug:
+  - type sym in the debugger
+  - for REL4, grep kallsyms_names, kallsyms_addresses, and kallsyms_num_syms
+    in the guest System.map* file. Run sym again with domid and the three
+    values on the command line.
+  - Now basic symbols can be used for guest debug. Note, if the binary is not
+    built with symbols, only function names are available, but not global vars.
+
+    Eg: sym 0 c0696084 c068a590 c0696080 c06b43e8 c06b4740
+        will set symbols for dom 0. Then :
+
+        [4]xkdb> bp some_function 0
+
+	wills set bp at some_function in dom 0
+
+	[3]xkdb> dw c068a590 32 0 : display 32 bytes of dom0 memory
+
+
+Tips:
+  - In "[0]xkdb>"  : 0 is the cpu number in decimal
+  - In
+      00000000c042645c: 0:do_timer+17                  push %ebp
+    0:do_timer : 0 is the domid in hex
+    offset +17 is in hex.
+
+    absense of 0: would indicate it's a hypervisor function
+
+  - commands starting with kdb (kdb*) are for kdb debug only.
+
+
+Finally,
+ - think hex.
+ - bug/problem: enter kdbdbg, reproduce, and send me the output.
+   If the output is not enough, I may ask to run kdbdbg twice, then collect
+   output.
+
+
+Thanks,
+Mukesh Rathor
+Oracle Corporatin, 
+Redwood Shores, CA 94065
+
+--------------------------------------------------------------------------------
+COMMAND DESCRIPTION:
+
+info:  Print basic info like version, compile flags, etc..
+
+cur:  print current domain id and vcpu id
+
+f: display current stack. If a vcpu ptr is given, then print stack for that
+   VCPU by using its IP and SP.
+
+fg: display stack for a guest given domid, SP and IP.
+
+dw: display words of memory. 'num' of bytes is optional, but if displaying guest
+    memory, then is required.
+
+dd: same as above, but display doublewords.
+
+dwm: same as above but the address is machine address instead of virtual.
+
+ddm: same as above, but display doublewords.
+
+dr: display registers. if 'sp' is specified then print few extra registers.
+
+drg: display guest context saved on stack bottom.
+
+dis: disassemble instructions. If disassembling for guest, then 'num' must
+     be specified. 'num' is number of instrs to display.
+
+dism: toggle disassembly mode between Intel and ATT/GAS.
+
+mw: modify word in memory given virtual address. 'domid' may be specified if
+    modifying guest memory. value is assumed in hex even without 0x.
+
+md: same as above but modify doubleword.
+
+mr: modify register. value is assumd hex.
+
+bc: clear given or all breakpoints
+
+bp: display breakpoints or set a breakpoint. Domid may be specified to set a bp
+    in guest. kdb functions may not be specified if debugging kdb.
+    Example:
+      xkdb> bp acpi_processor_idle  : will set bp in xen
+      xkdb> bp default_idle 0 :   will set bp in domid 0
+      xkdb> bp idle_cpu 9 :   will set bp in domid 9
+
+     Conditions may be specified for a bp: lhs == rhs or lhs != rhs
+     where : lhs is register like 'r6', 'rax', etc...  or memory location
+             rhs is hex value with or without leading 0x.
+     Thus,
+      xkdb> bp acpi_processor_idle rdi == c000 
+      xkdb> bp 0xffffffff80062ebc 0 rsi == ffff880021edbc98 : will break into
+            kdb at 0xffffffff80062ebc in dom0 when rsi is ffff880021edbc98 
+
+btp: break point trace. Upon bp, print some info and continue without stopping.
+   Ex: btp idle_cpu 7 rax rbx 0x20ef5a5 r9
+
+   will print: rax, rbx, *(long *)0x20ef5a5, r9 upon hitting idle_cpu() and 
+               continue.
+
+wp: set a watchpoint at a virtual address which can belong to hypervisor or
+    any guest. Do not specify wp in kdb path if debugging kdb.
+
+wc: clear given or all watchpoints.
+
+ni: single step, stepping over function calls.
+
+ss: single step. Be carefull when in interrupt handlers or context switches.
+    
+ssb: single step to branch. Use with care.
+
+go: leave kdb and continue.
+
+cpu: go back to orig cpu when entering kdb. If 'cpu number' given, then switch 
+     to that cpu. If 'all' then show status of all cpus.
+
+nmi: Only available in hung/crash state. Send NMI to a cpu that may be hung.
+
+sym: Initialize a symbol table for debugging a guest. Look into the System.map
+     file of guest for certain symbol values and provide them here.
+
+vcpuh: Given vcpu ptr, display hvm_vcpu struct.
+
+vcpu: Display current vcpu struct. If 'vcpu-ptr' given, display that vcpu.
+
+dom: display current domain. If 'domid' then display that domid. If 'all', then
+     display all domains.
+
+sched: show schedular info and run queues.
+
+mmu: print basic mmu info
+
+p2m: convert a gpfn to mfn given a domid. value in hex even without 0x.
+
+m2p: convert mfn to pfn. value in hex even without 0x.
+
+dpage: display struct page given a mfn or struct page ptr. Since, no info is 
+       kept on page type, we display all possible page types.
+
+dtrq: display timer queues.
+
+didt: dump IDT table.
+
+dgt: dump GDT table.
+
+dirq: display IRQ bindings.
+
+dvmc: display all or given dom/vcpu VMCS or VMCB.
+
+trcon: turn tracing on. Trace hooks must be added in xen and kdb function
+       called directly from there.
+
+trcoff: turn tracing off.
+
+trcz: zero trace buffer.
+
+trcp: give hints to print the circular trace buffer, like current active ptr.
+
+usr1: allows to add any arbitraty command quickly.
+
+--------------------------------------------------------------------------------
+/*
+ * Copyright (C) 2008 Oracle.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
diff -r 54c8c9eaee92 xen/kdb/guest/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y           := kdb_guest.o
+
diff -r 54c8c9eaee92 xen/kdb/guest/kdb_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/kdb_guest.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,342 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+/* information for symbols for a guest (includeing dom 0 ) is saved here */
+struct gst_syminfo {           /* guest symbols info */
+    int   domid;               /* which domain */
+    int   bitness;             /* 32 or 64 */
+    void *addrtblp;            /* ptr to (32/64)addresses tbl */
+    u8   *toktbl;              /* ptr to kallsyms_token_table */
+    u16  *tokidxtbl;           /* ptr to kallsyms_token_index */
+    u8   *kallsyms_names;      /* ptr to kallsyms_names */
+    long  kallsyms_num_syms;   /* ptr to kallsyms_num_syms */
+    kdbva_t  stext;            /* value of _stext in guest */
+    kdbva_t  etext;            /* value of _etext in guest */
+    kdbva_t  sinittext;        /* value of _sinittext in guest */
+    kdbva_t  einittext;        /* value of _einittext in guest */
+};
+
+#define MAX_CACHE 16                              /* cache upto 16 guests */
+struct gst_syminfo gst_syminfoa[MAX_CACHE];       /* guest symbol info array */
+
+static struct gst_syminfo *
+kdb_get_syminfo_slot(void)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].addrtblp == NULL)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+static struct gst_syminfo *
+kdb_domid2syminfop(domid_t domid)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].domid == domid)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+/* check if an address looks like text address in guest */
+int
+kdb_is_addr_guest_text(kdbva_t addr, int domid)
+{
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    if (!gp || !gp->stext || !gp->etext)
+        return 0;
+    KDBGP1("guestaddr: addr:%lx domid:%d\n", addr, domid);
+
+    return ( (addr >= gp->stext && addr <= gp->etext) ||
+             (addr >= gp->sinittext && addr <= gp->einittext) );
+}
+
+/*
+ * returns: value of kallsyms_addresses[idx];
+ */
+static kdbva_t
+kdb_rd_guest_addrtbl(struct gst_syminfo *gp, int idx)
+{
+    kdbva_t addr, retaddr=0;
+    int num = gp->bitness/8;       /* whether 4 byte or 8 byte ptrs */
+    domid_t id = gp->domid;
+
+    addr = (kdbva_t)(((char *)gp->addrtblp) + idx * num);
+    KDBGP1("rdguestaddrtbl:addr:%lx idx:%d\n", addr, idx);
+
+    if (kdb_read_mem(addr, (kdbbyt_t *)&retaddr,num,id) != num) {
+        kdbp("Can't read addrtbl domid:%d at:%lx\n", id, addr);
+        return 0;
+    }
+    KDBGP1("rdguestaddrtbl:exit:retaddr:%lx\n", retaddr);
+    return retaddr;
+}
+
+/* Based on el5 kallsyms.c file. */
+static unsigned int 
+kdb_expand_el5_sym(struct gst_syminfo *gp, unsigned int off, char *result)
+{   
+    int len, skipped_first = 0;
+    u8 u8idx, *tptr, *datap;
+    domid_t domid = gp->domid;
+
+    *result = '\0';
+
+    /* get the compressed symbol length from the first symbol byte */
+    datap = gp->kallsyms_names + off;
+    len = 0;
+    if ((kdb_read_mem((kdbva_t)datap, (kdbbyt_t *)&len, 1, domid)) != 1) {
+        KDBGP("failed to read guest memory\n");
+        return 0;
+    }
+    datap++;
+
+    /* update the offset to return the offset for the next symbol on
+     * the compressed stream */
+    off += len + 1;
+
+    /* for every byte on the compressed symbol data, copy the table
+     * entry for that byte */
+    while(len) {
+        u16 u16idx, *u16p;
+        if (kdb_read_mem((kdbva_t)datap,(kdbbyt_t *)&u8idx,1,domid)!=1){
+            kdbp("memory (u8idx) read error:%p\n",gp->tokidxtbl);
+            return 0;
+        }
+        u16p = u8idx + gp->tokidxtbl;
+        if (kdb_read_mem((kdbva_t)u16p,(kdbbyt_t *)&u16idx,2,domid)!=2){
+            kdbp("tokidxtbl read error:%p\n", u16p);
+            return 0;
+        }
+        tptr = gp->toktbl + u16idx;
+        datap++;
+        len--;
+
+        while ((kdb_read_mem((kdbva_t)tptr, (kdbbyt_t *)&u8idx, 1, domid)==1) &&
+               u8idx) {
+
+            if(skipped_first) {
+                *result = u8idx;
+                result++;
+            } else
+                skipped_first = 1;
+            tptr++;
+        }
+    }
+    *result = '\0';
+    return off;          /* return to offset to the next symbol */
+}
+
+#define EL4_NMLEN 127
+/* so much pain, so not sure of it's worth .. :).. */
+static kdbva_t
+kdb_expand_el4_sym(struct gst_syminfo *gp, int low, char *result, char *symp)
+{   
+    int i, j;
+    u8 *nmp = gp->kallsyms_names;       /* guest address space */
+    kdbbyt_t byte, prefix;
+    domid_t id = gp->domid;
+    kdbva_t addr;
+
+    KDBGP1("Eel4sym:nmp:%p maxidx:$%d sym:%s\n", nmp, low, symp);
+    for (i=0; i <= low; i++) {
+        /* unsigned prefix = *name++; */
+        if (kdb_read_mem((kdbva_t)nmp, &prefix, 1, id) != 1) {
+            kdbp("failed to read:%p domid:%x\n", nmp, id);
+            return 0;
+        }
+        KDBGP2("el4:i:%d prefix:%x\n", i, prefix);
+        nmp++;
+        /* strncpy(namebuf + prefix, name, KSYM_NAME_LEN - prefix); */
+        addr = (long)result + prefix;
+        for (j=0; j < EL4_NMLEN-prefix; j++) {
+            if (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) != 1) {
+                kdbp("failed read:%p domid:%x\n", nmp, id);
+                return 0;
+            }
+            KDBGP2("el4:j:%d byte:%x\n", j, byte);
+            *(kdbbyt_t *)addr = byte;
+            addr++; nmp++;
+            if (byte == '\0')
+                break;
+        }
+        KDBGP2("el4sym:i:%d res:%s\n", i, result);
+        if (symp && strcmp(result, symp) == 0)
+            return(kdb_rd_guest_addrtbl(gp, i));
+
+        /* kallsyms.c: name += strlen(name) + 1; */
+        if (j == EL4_NMLEN-prefix && byte != '\0')
+            while (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) && byte != '\0')
+                nmp++;
+    }
+    KDBGP1("Xel4sym: na-ga-da\n");
+    return 0;
+}
+
+static unsigned int
+kdb_get_el5_symoffset(struct gst_syminfo *gp, long pos)
+{
+    int i;
+    u8 data, *namep;
+    domid_t domid = gp->domid;
+
+    namep = gp->kallsyms_names;
+    for (i=0; i < pos; i++) {
+        if (kdb_read_mem((kdbva_t)namep, &data, 1, domid) != 1) {
+            kdbp("Can't read id:$%d mem:%p\n", domid, namep);
+            return 0;
+        }
+        namep = namep + data + 1;
+    }
+    return namep - gp->kallsyms_names;
+}
+
+/*
+ * for a given guest domid (domid >= 0 && < KDB_HYPDOMID), convert addr to
+ * symbol. offset is set to  addr - symbolstart
+ */
+char *
+kdb_guest_addr2sym(unsigned long addr, domid_t domid, ulong *offsp)
+{
+    static char namebuf[KSYM_NAME_LEN+1];
+    unsigned long low, high, mid;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    *offsp = 0;
+    if(!gp || gp->kallsyms_num_syms == 0)
+        return " ??? ";
+
+    namebuf[0] = namebuf[KSYM_NAME_LEN] = '\0';
+    if (1) {
+        /* do a binary search on the sorted kallsyms_addresses array */
+        low = 0;
+        high = gp->kallsyms_num_syms;
+
+        while (high-low > 1) {
+            mid = (low + high) / 2;
+            if (kdb_rd_guest_addrtbl(gp, mid) <= addr) 
+                low = mid;
+            else 
+                high = mid;
+        }
+        /* Grab name */
+        if (gp->toktbl) {
+            int symoff = kdb_get_el5_symoffset(gp,low);
+            kdb_expand_el5_sym(gp, symoff, namebuf);
+        } else
+            kdb_expand_el4_sym(gp, low, namebuf, NULL);
+        *offsp = addr - kdb_rd_guest_addrtbl(gp, low);
+        return namebuf;
+    }
+    return " ???? ";
+}
+
+
+/* 
+ * save guest (dom0 and others) symbols info : domid and following addresses:
+ *     &kallsyms_names &kallsyms_addresses &kallsyms_num_syms \
+ *     &kallsyms_token_table &kallsyms_token_index
+ */
+void
+kdb_sav_dom_syminfo(domid_t domid, long namesp, long addrap, long nump,
+                    long toktblp, long tokidxp)
+{
+    int bytes;
+    long val = 0;    /* must be set to zero for 32 on 64 cases */
+    struct gst_syminfo *gp = kdb_get_syminfo_slot();
+
+    if (gp == NULL) {
+        kdbp("kdb:kdb_sav_dom_syminfo():Table full.. symbols not saved\n");
+        return;
+    }
+    memset(gp, 0, sizeof(*gp));
+
+    gp->domid = domid;
+    gp->bitness = kdb_guest_bitness(domid);
+    gp->addrtblp = (void *)addrap;
+    gp->kallsyms_names = (u8 *)namesp;
+    gp->toktbl = (u8 *)toktblp;
+    gp->tokidxtbl = (u16 *)tokidxp;
+
+    KDBGP("domid:%x bitness:$%d numsyms:$%ld arrayp:%p\n", domid,
+          gp->bitness, gp->kallsyms_num_syms, gp->addrtblp);
+
+    bytes = gp->bitness/8;
+    if (kdb_read_mem(nump, (kdbbyt_t *)&val, bytes, domid) != bytes) {
+
+        kdbp("Unable to read number of symbols from:%lx\n", nump);
+        memset(gp, 0, sizeof(*gp));
+        return;
+    } else
+        kdbp("Number of symbols:$%ld\n", val);
+
+    gp->kallsyms_num_syms = val;
+
+    bytes = (gp->bitness/8) * gp->kallsyms_num_syms;
+    gp->stext = kdb_guest_sym2addr("_stext", domid);
+    gp->etext = kdb_guest_sym2addr("_etext", domid);
+    if (!gp->stext || !gp->etext)
+        kdbp("Warn: Can't find stext/etext\n");
+
+    if (gp->toktbl && gp->tokidxtbl) {
+        gp->sinittext = kdb_guest_sym2addr("_sinittext", domid);
+        gp->einittext = kdb_guest_sym2addr("_einittext", domid);
+        if (!gp->sinittext || !gp->einittext) {
+            kdbp("Warn: Can't find sinittext/einittext\n");
+    } 
+    }
+    KDBGP1("stxt:%lx etxt:%lx sitxt:%lx eitxt:%lx\n", gp->stext, gp->etext,
+           gp->sinittext, gp->einittext);
+    kdbp("Succesfully saved symbol info\n");
+}
+
+/*
+ * given a symbol string for a guest/domid, return its address
+ */
+kdbva_t
+kdb_guest_sym2addr(char *symp, domid_t domid)
+{
+    char namebuf[KSYM_NAME_LEN+1];
+    int i, off=0;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    KDBGP("sym2a: sym:%s domid:%x numsyms:%ld\n", symp, domid,
+          gp ? gp->kallsyms_num_syms: -1);
+
+    if (!gp)
+        return 0;
+
+    if (gp->toktbl == 0 || gp->tokidxtbl == 0)
+        return(kdb_expand_el4_sym(gp, gp->kallsyms_num_syms, namebuf, symp));
+
+    for (i=0; i < gp->kallsyms_num_syms; i++) {
+        off = kdb_expand_el5_sym(gp, off, namebuf);
+        KDBGP1("i:%d namebuf:%s\n", i, namebuf);
+        if (strcmp(namebuf, symp) == 0) {
+            return(kdb_rd_guest_addrtbl(gp, i));
+        }
+    }
+    KDBGP("sym2a:exit:na-ga-da\n");
+    return 0;
+}
diff -r 54c8c9eaee92 xen/kdb/include/kdb_extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdb_extern.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDB_EXTERN_H
+#define _KDB_EXTERN_H
+
+#define KDB_TRAP_FATAL     1    /* trap is fatal. can't resume from kdb */
+#define KDB_TRAP_NONFATAL  2    /* can resume from kdb */
+#define KDB_TRAP_KDBSTACK  3    /* to debug kdb itself. dump kdb stack */
+
+/* following can be called from anywhere in xen to debug */
+extern void kdb_trap_immed(int);
+extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
+extern void kdbp(const char *fmt, ...);
+
+typedef unsigned long kdbva_t;
+typedef unsigned char kdbbyt_t;
+typedef unsigned long kdbma_t;
+
+extern unsigned long kdb_dr7;
+
+
+extern volatile int kdb_session_begun;
+extern volatile int kdb_enabled;
+extern void kdb_init(void);
+extern int kdb_keyboard(struct cpu_user_regs *);
+extern void kdb_ssni_reenter(struct cpu_user_regs *);
+extern int kdb_handle_trap_entry(int, struct cpu_user_regs *);
+extern int kdb_trap_fatal(int, struct cpu_user_regs *);  /* fatal with regs */
+extern void kdb_dump_vmcs(uint16_t did, int vid);
+void kdb_dump_vmcb(uint16_t did, int vid);
+extern void kdb_dump_time_pcpu(void);
+
+
+#define VMPTRST_OPCODE  ".byte 0x0f,0xc7\n"     /* reg/opcode: /7 */
+#define MODRM_EAX_07    ".byte 0x38\n"          /* [EAX], with reg/opcode: /7 */
+static inline void __vmptrst(u64 *addr)
+{
+    asm volatile ( VMPTRST_OPCODE
+                   MODRM_EAX_07
+                   :
+                   : "a" (addr)
+                   : "memory");
+}
+
+extern void mukchk(unsigned long);
+#define is_hvm_or_hyb_domain is_hvm_domain
+#define is_hvm_or_hyb_vcpu is_hvm_vcpu
+
+
+#endif  /* _KDB_EXTERN_H */
diff -r 54c8c9eaee92 xen/kdb/include/kdbdefs.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbdefs.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBDEFS_H
+#define _KDBDEFS_H
+
+/* reason we are entering kdbmain (bp == breakpoint) */
+typedef enum {
+    KDB_REASON_KEYBOARD=1,  /* Keyboard entry - always 1 */
+    KDB_REASON_BPEXCP,      /* #BP excp: sw bp (INT3) */
+    KDB_REASON_DBEXCP,      /* #DB excp: TF flag or HW bp */
+    KDB_REASON_PAUSE_IPI,   /* received pause IPI from another CPU */
+} kdb_reason_t;
+
+
+/* cpu state: past, present, and future */
+typedef enum {
+    KDB_CPU_INVAL=0,     /* invalid value. not in or leaving kdb */
+    KDB_CPU_QUIT,        /* main cpu does GO. all others do QUIT */
+    KDB_CPU_PAUSE,       /* cpu is paused */
+    KDB_CPU_DISABLE,     /* disable interrupts */
+    KDB_CPU_SHOWPC,      /* all cpus must display their pc */
+    KDB_CPU_DO_VMEXIT,   /* all cpus must do vmcs vmexit. intel only */
+    KDB_CPU_MAIN_KDB,    /* cpu in kdb main command loop */
+    KDB_CPU_GO,          /* user entered go for this cpu */
+    KDB_CPU_SS,          /* single step for this cpu */
+    KDB_CPU_NI,          /* go to next instr after the call instr */
+    KDB_CPU_INSTALL_BP,  /* delayed install of sw bp(s) by this cpu */
+} kdb_cpu_cmd_t;
+
+/* ============= kdb commands ============================================= */
+
+typedef kdb_cpu_cmd_t (*kdb_func_t)(int, const char **, struct cpu_user_regs *);
+typedef kdb_cpu_cmd_t (*kdb_usgf_t)(void);
+
+typedef enum {
+    KDB_REPEAT_NONE = 0,    /* Do not repeat this command */
+    KDB_REPEAT_NO_ARGS,     /* Repeat the command without arguments */
+    KDB_REPEAT_WITH_ARGS,   /* Repeat the command including its arguments */
+} kdb_repeat_t;
+
+typedef struct _kdbtab {
+    char        *kdb_cmd_name;        /* Command name */
+    kdb_func_t   kdb_cmd_func;        /* ptr to function to execute command */
+    kdb_usgf_t   kdb_cmd_usgf;        /* usage function ptr */
+    int          kdb_cmd_crash_avail; /* available in sys fatal/crash state */
+    kdb_repeat_t kdb_cmd_repeat;      /* Does command auto repeat on enter? */
+} kdbtab_t;
+
+
+/* ============= types and stuff ========================================= */
+#define BFD_INVAL (~0UL)            /* invalid bfd_vma */
+
+#if defined(__x86_64__)
+  #define KDBIP rip
+  #define KDBSP rsp
+#else
+  #define KDBIP eip
+  #define KDBSP esp
+#endif
+
+/* ============= macros ================================================== */
+extern volatile int kdbdbg;
+#define KDBGP(...) {(kdbdbg) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP3(...) {0;};
+
+#define KDBMIN(x,y) (((x)<(y))?(x):(y))
+
+#endif  /* !_KDBDEFS_H */
diff -r 54c8c9eaee92 xen/kdb/include/kdbinc.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbinc.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBINC_H
+#define _KDBINC_H
+
+#include <xen/compile.h>
+#include <xen/config.h>
+#include <xen/version.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/mm.h>
+#include <xen/event.h>
+#include <xen/time.h>
+#include <xen/console.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/rangeset.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/delay.h>
+#include <xen/shutdown.h>
+#include <xen/percpu.h>
+#include <xen/multicall.h>
+#include <xen/rcupdate.h>
+#include <xen/ctype.h>
+#include <xen/symbols.h>
+#include <xen/shutdown.h>
+#include <xen/serial.h>
+#include <xen/grant_table.h>
+#include <asm/debugger.h>
+#include <asm/shared.h>
+#include <asm/apicdef.h>
+
+#include <asm/nmi.h>
+#include <asm/p2m.h>
+#include <asm/debugreg.h>
+#include <public/sched.h>
+#include <public/vcpu.h>
+#ifdef _XEN_LATEST
+#include <xsm/xsm.h>
+#endif
+
+#include <asm/hvm/vmx/vmx.h>
+
+#include "kdb_extern.h"
+#include "kdbdefs.h"
+#include "kdbproto.h"
+
+#endif /* !_KDBINC_H */
diff -r 54c8c9eaee92 xen/kdb/include/kdbproto.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbproto.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBPROTO_H
+#define _KDBPROTO_H
+
+/* hypervisor interfaces use by kdb or kdb interfaces in xen files */
+extern void console_putc(char);
+extern int console_getc(void);
+extern void show_trace(struct cpu_user_regs *);
+extern void kdb_dump_timer_queues(void);
+extern void kdb_time_resume(int);
+extern void kdb_print_sched_info(void);
+extern void kdb_curr_cpu_flush_vmcs(void);
+extern unsigned long address_lookup(char *);
+extern void kdb_prnt_guest_mapped_irqs(void);
+
+/* kdb globals */
+extern kdbtab_t *kdb_cmd_tbl;
+extern char kdb_prompt[32];
+extern volatile int kdb_sys_crash;
+extern volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+extern volatile int kdb_trcon;
+
+/* kdb interfaces */
+extern void __init kdb_io_init(void);
+extern void kdb_init_cmdtab(void);
+extern void kdb_do_cmds(struct cpu_user_regs *);
+extern int kdb_check_sw_bkpts(struct cpu_user_regs *);
+extern int kdb_check_watchpoints(struct cpu_user_regs *);
+extern void kdb_do_watchpoints(kdbva_t, int, int);
+extern void kdb_install_watchpoints(void);
+extern void kdb_clear_wps(int);
+extern kdbma_t kdb_rd_dbgreg(int);
+
+
+
+extern char *kdb_get_cmdline(char *);
+extern void kdb_clear_prev_cmd(void);
+extern void kdb_toggle_dis_syntax(void);
+extern int kdb_check_call_instr(domid_t, kdbva_t);
+extern void kdb_display_pc(struct cpu_user_regs *);
+extern kdbva_t kdb_print_instr(kdbva_t, long, domid_t);
+extern int kdb_read_mmem(kdbva_t, kdbbyt_t *, int);
+extern int kdb_read_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+extern int kdb_write_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+
+extern void kdb_install_all_swbp(void);
+extern void kdb_uninstall_all_swbp(void);
+extern int kdb_swbp_exists(void);
+extern void kdb_flush_swbp_table(void);
+extern int kdb_is_addr_guest_text(kdbva_t, int);
+extern kdbva_t kdb_guest_sym2addr(char *, domid_t);
+extern char *kdb_guest_addr2sym(unsigned long, domid_t, ulong *);
+extern void kdb_prnt_addr2sym(domid_t, kdbva_t, char *);
+extern void kdb_sav_dom_syminfo(domid_t, long, long, long, long, long);
+extern int kdb_guest_bitness(domid_t);
+extern void kdb_nmi_pause_cpus(cpumask_t);
+
+extern void kdb_trczero(void);
+void kdb_trcp(void);
+
+
+
+#endif /* !_KDBPROTO_H */
diff -r 54c8c9eaee92 xen/kdb/kdb_cmds.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_cmds.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3774 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+#if defined(__x86_64__)
+    #define KDBF64 "%lx"
+    #define KDBFL "%016lx"         /* print long all digits */
+#else
+    #define KDBF64 "%llx"
+    #define KDBFL "%08lx"
+#endif
+
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    #define KDB_LKDEF(l) ((l).raw.lock)
+    #define KDB_PGLLE(t) ((t).tail)    /* page list last element ^%$#@ */
+#else
+    #define KDB_LKDEF(l) ((l).lock)
+    #define KDB_PGLLE(t) ((t).prev)    /* page list last element ^%$#@ */
+#endif
+
+#define KDB_CMD_HISTORY_COUNT   32
+#define CMD_BUFLEN              200     /* kdb_printf: max printline == 256 */
+
+#define KDBMAXSBP 16                    /* max number of software breakpoints */
+#define KDB_MAXARGC 16                  /* max args in a kdb command */
+#define KDB_MAXBTP  8                   /* max display args in btp */
+
+/* condition is: 'r6 == 0x123f' or '0xffffffff82800000 != deadbeef'  */
+struct kdb_bpcond {
+    kdbbyt_t bp_cond_status;       /* 0 == off, 1 == register, 2 == memory */
+    kdbbyt_t bp_cond_type;         /* 0 == bad, 1 == equal, 2 == not equal */
+    ulong    bp_cond_lhs;          /* lhs of condition: reg offset or mem loc */
+    ulong    bp_cond_rhs;          /* right hand side of condition */
+};
+
+/* software breakpoint structure */
+struct kdb_sbrkpt {
+    kdbva_t  bp_addr;              /* address the bp is set at */
+    domid_t  bp_domid;             /* which domain the bp belongs to */
+    kdbbyt_t bp_originst;          /* save orig instr/s here */
+    kdbbyt_t bp_deleted;           /* delete pending on this bp */
+    kdbbyt_t bp_ni;                /* set for KDB_CPU_NI */
+    kdbbyt_t bp_just_added;        /* added in the current kdb session */
+    kdbbyt_t bp_type;              /* 0 = normal, 1 == cond,  2 == btp */
+    union {
+        struct kdb_bpcond bp_cond;
+        ulong *bp_btp;
+    } u;
+};
+
+/* don't use kmalloc in kdb which hijacks all cpus */
+static ulong kdb_btp_argsa[KDBMAXSBP][KDB_MAXBTP];
+static ulong *kdb_btp_ap[KDBMAXSBP];
+
+static struct kdb_reg_nmofs {
+    char *reg_nm;
+    int reg_offs;
+} kdb_reg_nm_offs[] =  {
+       { "rax", offsetof(struct cpu_user_regs, rax) },
+       { "rbx", offsetof(struct cpu_user_regs, rbx) },
+       { "rcx", offsetof(struct cpu_user_regs, rcx) },
+       { "rdx", offsetof(struct cpu_user_regs, rdx) },
+       { "rsi", offsetof(struct cpu_user_regs, rsi) },
+       { "rdi", offsetof(struct cpu_user_regs, rdi) },
+       { "rbp", offsetof(struct cpu_user_regs, rbp) },
+       { "rsp", offsetof(struct cpu_user_regs, rsp) },
+       { "r8",  offsetof(struct cpu_user_regs, r8) },
+       { "r9",  offsetof(struct cpu_user_regs, r9) },
+       { "r10", offsetof(struct cpu_user_regs, r10) },
+       { "r11", offsetof(struct cpu_user_regs, r11) },
+       { "r12", offsetof(struct cpu_user_regs, r12) },
+       { "r13", offsetof(struct cpu_user_regs, r13) },
+       { "r14", offsetof(struct cpu_user_regs, r14) },
+       { "r15", offsetof(struct cpu_user_regs, r15) },
+       { "rflags", offsetof(struct cpu_user_regs, rflags) } };
+
+static const int KDBBPSZ=1;                   /* size of KDB_BPINST is 1 byte*/
+static kdbbyt_t kdb_bpinst = 0xcc;            /* breakpoint instr: INT3 */
+static struct kdb_sbrkpt kdb_sbpa[KDBMAXSBP]; /* soft brkpt array/table */
+static kdbtab_t *tbp;
+
+static int kdb_set_bp(domid_t, kdbva_t, int, ulong *, char*, char*, char*);
+static void kdb_print_uregs(struct cpu_user_regs *);
+
+
+/* ===================== cmdline functions  ================================ */
+
+/* lp points to a string of only alpha numeric chars terminated by '\n'.
+ * Parse the string into argv pointers, and RETURN argc
+ * Eg:  if lp --> "dr  sp\n" :  argv[0]=="dr\0"  argv[1]=="sp\0"  argc==2
+ */
+static int
+kdb_parse_cmdline(char *lp, const char **argv)
+{
+    int i=0;
+
+    for (; *lp == ' '; lp++);      /* note: isspace() skips '\n' also */
+    while ( *lp != '\n' ) {
+        if (i == KDB_MAXARGC) {
+            printk("kdb: max args exceeded\n");
+            break;
+        }
+        argv[i++] = lp;
+        for (; *lp != ' ' && *lp != '\n'; lp++);
+        if (*lp != '\n')
+            *lp++ = '\0';
+        for (; *lp == ' '; lp++);
+    }
+    *lp = '\0';
+    return i;
+}
+
+void
+kdb_clear_prev_cmd()             /* so previous command is not repeated */
+{
+    tbp = NULL;
+}
+
+void
+kdb_do_cmds(struct cpu_user_regs *regs)
+{
+    char *cmdlinep;
+    const char *argv[KDB_MAXARGC];
+    int argc = 0, curcpu = smp_processor_id();
+    kdb_cpu_cmd_t result = KDB_CPU_MAIN_KDB;
+
+    snprintf(kdb_prompt, sizeof(kdb_prompt), "[%d]xkdb> ", curcpu);
+
+    while (result == KDB_CPU_MAIN_KDB) {
+        cmdlinep = kdb_get_cmdline(kdb_prompt);
+        if (*cmdlinep == '\n') {
+            if (tbp==NULL || tbp->kdb_cmd_func==NULL)
+                continue;
+            else
+                argc = -1;    /* repeat prev command */
+        } else {
+            argc = kdb_parse_cmdline(cmdlinep, argv);
+            for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_func; tbp++)  {
+                if (strcmp(argv[0], tbp->kdb_cmd_name)==0) 
+                    break;
+            }
+        }
+        if (kdb_sys_crash && tbp->kdb_cmd_func && !tbp->kdb_cmd_crash_avail) {
+            kdbp("cmd not available in fatal/crashed state....\n");
+            continue;
+        }
+        if (tbp->kdb_cmd_func) {
+            result = (*tbp->kdb_cmd_func)(argc, argv, regs);
+            if (tbp->kdb_cmd_repeat == KDB_REPEAT_NONE)
+                tbp = NULL;
+        } else
+            kdbp("kdb: Unknown cmd: %s\n", cmdlinep);
+    }
+    kdb_cpu_cmd[curcpu] = result;
+    return;
+}
+
+/* ===================== Util functions  ==================================== */
+
+int
+kdb_vcpu_valid(struct vcpu *in_vp)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    for(dp=domain_list; in_vp && dp; dp=dp->next_in_list)
+        for_each_vcpu(dp, vp)
+            if (in_vp == vp)
+                return 1;
+    return 0;     /* not found */
+}
+
+/*
+ * Given a symbol, find it's address
+ */
+static kdbva_t
+kdb_sym2addr(const char *p, domid_t domid)
+{
+    kdbva_t addr;
+
+    KDBGP1("sym2addr: p:%s domid:%d\n", p, domid);
+    if (domid == DOMID_IDLE)
+        addr = address_lookup((char *)p);
+    else
+        addr = (kdbva_t)kdb_guest_sym2addr((char *)p, domid);
+    KDBGP1("sym2addr: exit: addr returned:0x%lx\n", addr);
+    return addr;
+}
+
+/*
+ * convert ascii to int decimal (base 10). 
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2deci(const char *strp, int *intp)
+{
+    const char *endp;
+
+    KDBGP2("str2deci: str:%s\n", strp);
+    if (!isdigit(*strp))
+        return 0;
+    *intp = (int)simple_strtoul(strp, &endp, 10);
+    if (endp != strp+strlen(strp))
+        return 0;
+    KDBGP2("str2deci: intval:$%d\n", *intp);
+    return 1;
+}
+/*
+ * convert ascii to long. NOTE: base is 16
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2ulong(const char *strp, ulong *longp)
+{
+    ulong val;
+    const char *endp;
+
+    KDBGP2("str2long: str:%s\n", strp);
+    if (!isxdigit(*strp))
+        return 0;
+    val = (long)simple_strtoul(strp, &endp, 16);   /* handles leading 0x */
+    if (endp != strp+strlen(strp))
+        return 0;
+    if (longp)
+        *longp = val;
+    KDBGP2("str2long: val:0x%lx\n", val);
+    return 1;
+}
+/*
+ * convert a symbol or ascii address to hex address
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2addr(const char *strp, kdbva_t *addrp, domid_t id)
+{
+    kdbva_t addr;
+    const char *endp;
+
+    /* assume it's an address */
+    KDBGP2("str2addr: str:%s id:%d\n", strp, id);
+    addr = (kdbva_t)simple_strtoul(strp, &endp, 16); /*handles leading 0x */
+    if (endp != strp+strlen(strp))
+        if ( !(addr=kdb_sym2addr(strp, id)) )
+            return 0;
+    *addrp = addr;
+    KDBGP2("str2addr: addr:0x%lx\n", addr);
+    return 1;
+}
+
+/* Given domid, return ptr to struct domain 
+ * IF domid == DOMID_IDLE return ptr to idle_domain 
+ * IF domid == valid domain, return ptr to domain struct
+ * else domid is bad and return NULL
+ */
+static struct domain *
+kdb_domid2ptr(domid_t domid)
+{
+    struct domain *dp;
+
+    /* get_domain_by_id() ret NULL for both DOMID_IDLE and bad domids */
+    if (domid == DOMID_IDLE)
+        dp = idle_vcpu[smp_processor_id()]->domain;
+    else 
+        dp = get_domain_by_id(domid);   /* NULL now means bad domid */
+    return dp;
+}
+
+/*
+ * Returns:  0: failed. invalid domid or string, *idp not changed.
+ */
+static int
+kdb_str2domid(const char *domstr, domid_t *idp, int perr)
+{
+    int id;
+    if (!kdb_str2deci(domstr, &id) || !kdb_domid2ptr((domid_t)id)) {
+        if (perr)
+            kdbp("Invalid domid:%s\n", domstr);
+        return 0;
+    }
+    *idp = (domid_t)id;
+    return 1;
+}
+
+static struct domain *
+kdb_strdomid2ptr(const char *domstr, int perror)
+{
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
+}
+
+/* return a guest bitness: 32 or 64 */
+int
+kdb_guest_bitness(domid_t domid)
+{
+    const int HYPSZ = sizeof(long) * 8;
+    struct domain *dp = kdb_domid2ptr(domid);
+    int retval; 
+
+    if (is_idle_domain(dp))
+        retval = HYPSZ;
+    else if (is_hvm_or_hyb_domain(dp))
+        retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
+    else 
+        retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
+    KDBGP1("gbitness: domid:%d dp:%p bitness:%d\n", domid, dp, retval);
+    return retval;
+}
+
+/* kdb_print_spin_lock(&xyz_lock, "xyz_lock:", "\n"); */
+static void
+kdb_print_spin_lock(char *strp, spinlock_t *lkp, char *nlp)
+{
+    kdbp("%s %04hx %d %d%s", strp, KDB_LKDEF(*lkp), lkp->recurse_cpu,
+         lkp->recurse_cnt, nlp);
+}
+
+/* check if register string is valid. if yes, return offset to the register
+ * in cpu_user_regs, else return -1 */
+static int
+kdb_valid_reg(const char *nmp) 
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (strcmp(kdb_reg_nm_offs[i].reg_nm, nmp) == 0)
+            return kdb_reg_nm_offs[i].reg_offs;
+    return -1;
+}
+
+/* given offset of register, return register name string. if offset is invalid
+ * return NULL */
+static char *kdb_regoffs_to_name(int offs)
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (kdb_reg_nm_offs[i].reg_offs == offs)
+            return kdb_reg_nm_offs[i].reg_nm;
+    return NULL;
+}
+
+/* ===================== util struct funcs ================================= */
+static void
+kdb_prnt_timer(struct timer *tp)
+{
+#if XEN_SUBVERSION == 0 
+    kdbp(" expires:%016lx expires_end:%016lx cpu:%d status:%x\n", tp->expires, 
+         tp->expires_end, tp->cpu, tp->status);
+#else
+    kdbp(" expires:%016lx cpu:%d status:%x\n", tp->expires, tp->cpu,tp->status);
+#endif
+    kdbp(" function data:%p ptr:%p ", tp->data, tp->function);
+    kdb_prnt_addr2sym(DOMID_IDLE, (kdbva_t)tp->function, "\n");
+}
+
+static void 
+kdb_prnt_periodic_time(struct periodic_time *ptp)
+{
+    kdbp(" next:%p prev:%p\n", ptp->list.next, ptp->list.prev);
+    kdbp(" on_list:%d one_shot:%d dont_freeze:%d irq_issued:%d src:%x irq:%x\n",
+         ptp->on_list, ptp->one_shot, ptp->do_not_freeze, ptp->irq_issued,
+         ptp->source, ptp->irq);
+    kdbp(" vcpu:%p pending_intr_nr:%08x period:%016lx\n", ptp->vcpu,
+         ptp->pending_intr_nr, ptp->period);
+    kdbp(" scheduled:%016lx last_plt_gtime:%016lx\n", ptp->scheduled,
+         ptp->last_plt_gtime);
+    kdbp(" \n          timer info:\n");
+    kdb_prnt_timer(&ptp->timer);
+    kdbp("\n");
+}
+
+/* ===================== cmd functions  ==================================== */
+
+/*
+ * FUNCTION: Disassemble instructions
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dis(void)
+{
+    kdbp("dis [addr|sym][num][domid] : Disassemble instrs\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dis(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int num = 8;                           /* display 8 instr by default */
+    static kdbva_t addr = BFD_INVAL;
+    static domid_t domid;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dis();
+
+    if (argc != -1)      /* not a command repeat */
+        domid = guest_mode(regs) ?  current->domain->domain_id : DOMID_IDLE;
+
+    if (argc >= 4 && !kdb_str2domid(argv[3], &domid, 1)) { 
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc >= 3 && !kdb_str2deci(argv[2], &num)) {
+        kdbp("kdb:Invalid num\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc > 1 && !kdb_str2addr(argv[1], &addr, domid)) {
+        kdbp("kdb:Invalid addr/sym\n");
+        kdbp("(num has to be specified if providing domid)\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc == 1)                    /* not command repeat */
+        addr = regs->KDBIP;           /* PC is the default */
+    else if (addr == BFD_INVAL) {
+        kdbp("kdb:Invalid addr/sym\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    addr = kdb_print_instr(addr, num, domid);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* FUNCTION: kdb_cmdf_dism() Toggle disassembly syntax from Intel to ATT/GAS */
+static kdb_cpu_cmd_t
+kdb_usgf_dism(void)
+{
+    kdbp("dism: toggle disassembly mode between ATT/GAS and INTEL\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dism(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dism();
+
+    kdb_toggle_dis_syntax();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+_kdb_show_guest_stack(domid_t domid, kdbva_t ipaddr, kdbva_t spaddr)
+{
+    kdbva_t val;
+    int num=0, max=0, rd = kdb_guest_bitness(domid)/8;
+
+    kdb_print_instr(ipaddr, 1, domid);
+    KDBGP("_guest_stack:sp:%lx domid:%d rd:$%d\n", spaddr, domid, rd);
+    val = 0;                          /* must zero, in case guest is 32bit */
+    while((kdb_read_mem(spaddr,(kdbbyt_t *)&val,rd,domid)==rd) && num < 16){
+        KDBGP1("gstk:addr:%lx val:%lx\n", spaddr, val);
+        if (kdb_is_addr_guest_text(val, domid)) {
+            kdb_print_instr(val, 1, domid);
+            num++;
+        }
+        if (max++ > 10000)            /* don't walk down the stack forever */
+            break;                    /* 10k is chosen randomly */
+        spaddr += rd;
+    }
+}
+
+/* Read guest memory and display address that looks like text. */
+static void
+kdb_show_guest_stack(struct cpu_user_regs *regs, struct vcpu *vcpup)
+{
+    kdbva_t ipaddr=regs->KDBIP, spaddr = regs->KDBSP;
+    domid_t domid = vcpup->domain->domain_id;
+
+    ASSERT(domid != DOMID_IDLE);
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+}
+
+/* display stack. if vcpu ptr given, then display stack for that. Otherwise,
+ * use current regs */
+static kdb_cpu_cmd_t
+kdb_usgf_f(void)
+{
+    kdbp("f [vcpu-ptr]: dump current/vcpu stack\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_f(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_f();
+
+    if (argc > 1 ) {
+        struct vcpu *vp;
+        if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp)) {
+            kdbp("kdb: Bad VCPU ptr:%s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdb_show_guest_stack(&vp->arch.user_regs, vp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs))
+        kdb_show_guest_stack(regs, current);
+    else
+        show_trace(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an spaddr and domid for guest, dump stack */
+static kdb_cpu_cmd_t
+kdb_usgf_fg(void)
+{
+    kdbp("fg domid RIP ESP: dump guest stack given domid, RIP, and ESP\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_fg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid;
+    kdbva_t ipaddr, spaddr;
+
+    if (argc != 4) 
+        return kdb_usgf_fg();
+
+    if (kdb_str2domid(argv[1], &domid, 1)==0) {
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[2], &ipaddr)==0) {
+        kdbp("Bad ipaddr:%s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[3], &spaddr)==0) {
+        kdbp("Bad spaddr:%s\n", argv[3]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display kdb stack. for debugging kdb itself */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbf(void)
+{
+    kdbp("kdbf: display kdb stack. for debugging kdb only\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_kdbf(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbf();
+
+    kdb_trap_immed(KDB_TRAP_KDBSTACK);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* worker function to display memory. Request could be for any guest, domid.
+ * Also address could be machine or virtual */
+static void
+_kdb_display_mem(kdbva_t *addrp, int *lenp, int wordsz, int domid, int is_maddr)
+{
+    #define DDBUFSZ 4096
+
+    kdbbyt_t buf[DDBUFSZ], *bp;
+    int numrd, bytes;
+    int len = *lenp;
+    kdbva_t addr = *addrp;
+
+    /* round len down to wordsz boundry because on intel endian, printing
+     * characters is not prudent, (long and ints can't be interpreted 
+     * easily) */
+    len &= ~(wordsz-1);
+    len = KDBMIN(DDBUFSZ, len);
+    len = len ? len : wordsz;
+
+    KDBGP("dmem:addr:%lx buf:%p len:$%d domid:%d sz:$%d maddr:%d\n", addr,
+          buf, len, domid, wordsz, is_maddr);
+    if (is_maddr)
+        numrd=kdb_read_mmem((kdbma_t)addr, buf, len);
+    else
+        numrd=kdb_read_mem(addr, buf, len, domid);
+    if (numrd != len)
+        kdbp("Memory read error. Bytes read:$%d\n", numrd);
+
+    for (bp = buf; numrd > 0;) {
+        kdbp("%016lx: ", addr); 
+
+        /* display 16 bytes per line */
+        for (bytes=0; bytes < 16 && numrd > 0; bytes += wordsz) {
+            if (numrd >= wordsz) {
+                if (wordsz == 8)
+                    kdbp(" %016lx", *(long *)bp);
+                else
+                    kdbp(" %08x", *(int *)bp);
+                bp += wordsz;
+                numrd -= wordsz;
+                addr += wordsz;
+            }
+        }
+        kdbp("\n");
+        continue;
+    }
+    *lenp = len;
+    *addrp = addr;
+}
+
+/* display machine mem, ie, the given address is machine address */
+static kdb_cpu_cmd_t 
+kdb_display_mmem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbma_t maddr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&maddr, &len, wordsz, id, 1);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                                     /* default read len */
+
+    if (!kdb_str2ulong(argv[1], &maddr)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_display_mem(&maddr, &len, wordsz, 0, 1);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dwm(void)
+{
+    kdbp("dwm:  maddr|sym [num] : dump memory word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dwm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 4, kdb_usgf_dwm);
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ddm(void)
+{
+    kdbp("ddm:  maddr|sym [num] : dump double word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ddm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 8, kdb_usgf_ddm);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory : word or doubleword
+ *           wordsz : bytes in word. 4 or 8
+ *
+ *           We display upto BUFSZ bytes. User can just press enter for more.
+ *           addr is always in hex with or without leading 0x
+ */
+static kdb_cpu_cmd_t 
+kdb_display_mem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbva_t addr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&addr, &len, wordsz, id, 0);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    id = DOMID_IDLE;                /* not a command repeat, reset dom id */
+    if (argc >= 4) { 
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                       /* default read len */
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    _kdb_display_mem(&addr, &len, wordsz, id, 0);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dw(void)
+{
+    kdbp("dw vaddr|sym [num][domid] : dump mem word. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 4, kdb_usgf_dw);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dd(void)
+{
+    kdbp("dd vaddr|sym [num][domid] : dump dword. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dd(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 8, kdb_usgf_dd);
+}
+
+/* 
+ * FUNCTION: Modify Memory Word 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mw(void)
+{
+    kdbp("mw vaddr|sym val [domid] : modify memory word in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_mw();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val, 4, id) != 4)
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_md(void)
+{
+    kdbp("md vaddr|sym val [domid] : modify memory dword in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_md(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_md();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) {
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val,sizeof(val),id) != sizeof(val))
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct  Xgt_desc_struct {
+    unsigned short size;
+    unsigned long address __attribute__((packed));
+};
+
+void
+kdb_show_special_regs(struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    unsigned short tr;                 /* Task Register segment selector */
+    __u64 efer;
+
+    kdbp("\nSpecial Registers:\n");
+    __asm__ __volatile__ ("sidt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("IDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+    __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("GDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+
+    kdbp("cr0: %016lx  cr2: %016lx\n", read_cr0(), read_cr2());
+    kdbp("cr3: %016lx  cr4: %016lx\n", read_cr3(), read_cr4());
+    __asm__ __volatile__ ("str (%0) \n":: "a"(&tr) : "memory");
+    kdbp("TR: %x\n", tr);
+
+    rdmsrl(MSR_EFER, efer);    /* IA32_EFER */
+    kdbp("efer:"KDBF64" LMA(IA-32e mode):%d SCE(syscall/sysret):%d\n",
+         efer, ((efer&EFER_LMA) != 0), ((efer&EFER_SCE) != 0));
+
+    kdbp("DR0: %016lx  DR1:%016lx  DR2:%016lx\n", kdb_rd_dbgreg(0),
+         kdb_rd_dbgreg(1), kdb_rd_dbgreg(2)); 
+    kdbp("DR3: %016lx  DR6:%016lx  DR7:%016lx\n", kdb_rd_dbgreg(3),
+         kdb_rd_dbgreg(6), kdb_rd_dbgreg(7)); 
+}
+
+/* 
+ * FUNCTION: Dispaly Registers. If "sp" argument, then display additional regs
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dr(void)
+{
+    kdbp("dr [sp]: display registers. sp to display special regs also\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dr();
+
+    KDBGP1("regs:%p .rsp:%lx .rip:%lx\n", regs, regs->rsp, regs->rip);
+    show_registers(regs);
+    if (argc > 1 && !strcmp(argv[1], "sp")) 
+        kdb_show_special_regs(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* show registers on stack bottom where guest context is. same as dr if
+ * not running in guest mode */
+static kdb_cpu_cmd_t
+kdb_usgf_drg(void)
+{
+    kdbp("drg: display active guest registers at stack bottom\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_drg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_drg();
+
+    kdbp("\tNote: ds/es/fs/gs etc.. are not saved from the cpu\n");
+    kdb_print_uregs(guest_cpu_user_regs());
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Register
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mr(void)
+{
+    kdbp("mr reg val : Modify Register. val assumed in hex\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int regoffs;
+    ulong val;
+
+    if (argc != 3 || !kdb_str2ulong(argv[2], &val)) {
+        return kdb_usgf_mr();
+    }
+    argp = argv[1];
+
+#if defined(__x86_64__)
+    if ((regoffs=kdb_valid_reg(argp)) != -1)
+        *((uint64_t *)((char *)regs+regoffs)) = val;
+#else
+    if (!strcmp(argp, "eax"))
+        regs->eax = val;
+    else if (!strcmp(argp, "ebx"))
+        regs->ebx = val;
+    else if (!strcmp(argp, "ecx"))
+        regs->ecx = val;
+    else if (!strcmp(argp, "edx"))
+        regs->edx = val;
+    else if (!strcmp(argp, "esi"))
+        regs->esi = val;
+    else if (!strcmp(argp, "edi"))
+        regs->edi = val;
+    else if (!strcmp(argp, "ebp"))
+        regs->ebp = val;
+    else if (!strcmp(argp, "esp"))
+        regs->esp = val;
+    else if (!strcmp(argp, "eflags") || !strcmp(argp, "rflags"))
+        regs->eflags = val;
+#endif
+    else
+        kdbp("Error. Bad register : %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Single Step
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ss(void)
+{
+    kdbp("ss: single step\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ss(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    #define KDB_HALT_INSTR 0xf4
+
+    kdbbyt_t byte;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ss();
+
+    KDBGP("enter kdb_cmdf_ss \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_read_mem(regs->KDBIP, &byte, 1, id) == 1) {
+        if (byte == KDB_HALT_INSTR) {
+            kdbp("kdb: jumping over halt instruction\n");
+            regs->KDBIP++;
+        }
+    } else {
+        kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
+        current->arch.hvm_vcpu.single_step = 1;
+    } else
+        regs->eflags |= X86_EFLAGS_TF;
+
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Next Instruction, step over the call instr to the next instr
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ni(void)
+{
+    kdbp("ni: single step, stepping over function calls\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ni(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int sz, i;
+    domid_t id=guest_mode(regs) ? current->domain->domain_id:DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ni();
+
+    KDBGP("enter kdb_cmdf_ni \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if ((sz=kdb_check_call_instr(id, regs->KDBIP)) == 0)  /* !call instr */
+        return kdb_cmdf_ss(argc, argv, regs);         /* just do ss */
+
+    if ((i=kdb_set_bp(id, regs->KDBIP+sz, 1,0,0,0,0)) >= KDBMAXSBP) /* failed */
+        return KDB_CPU_MAIN_KDB;
+
+    kdb_sbpa[i].bp_ni = 1;
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+        current->arch.hvm_vcpu.single_step = 0;
+    else
+        regs->eflags &= ~X86_EFLAGS_TF;
+
+    return KDB_CPU_NI;
+}
+
+static void
+kdb_btf_enable(void)
+{
+    u64 debugctl;
+    rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 0x2);
+}
+
+/* 
+ * FUNCTION: Single Step to branch. Doesn't seem to work very well.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ssb(void)
+{
+    kdbp("ssb: singe step to branch\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ssb(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ssb();
+
+    KDBGP("MUK: enter kdb_cmdf_ssb\n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (is_hvm_or_hyb_vcpu(current)) 
+        current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
+
+    regs->eflags |= X86_EFLAGS_TF;
+    kdb_btf_enable();
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Continue Execution. TF must be cleared here as this could run on 
+ *           any cpu. Hence not OK to do it from kdb_end_session.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_go(void)
+{
+    kdbp("go: leave kdb and continue execution\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_go(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_go();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    return KDB_CPU_GO;
+}
+
+/* All cpus must display their current context */
+static kdb_cpu_cmd_t 
+kdb_cpu_status_all(int ccpu, struct cpu_user_regs *regs)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)   /* hung cpu */
+                continue;
+            kdb_cpu_cmd[cpu] = KDB_CPU_SHOWPC;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_SHOWPC);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * display/switch CPU. 
+ *  Argument:
+ *     none:   just go back to initial cpu
+ *     cpunum: switch to given vpu
+ *     "all":  show one line status of all cpus
+ */
+extern volatile int kdb_init_cpu;
+static kdb_cpu_cmd_t
+kdb_usgf_cpu(void)
+{
+    kdbp("cpu [all|num]: none will switch back to initial cpu\n");
+    kdbp("               cpunum to switch to the vcpu. all to show status\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_cpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+    int ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cpu();
+
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all"))
+            return kdb_cpu_status_all(ccpu, regs);
+
+            cpu = (int)simple_strtoul(argv[1], NULL, 0); /* handles 0x */
+            if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && 
+                cpu_online(cpu) && kdb_cpu_cmd[cpu] == KDB_CPU_PAUSE)
+            {
+                kdbp("Switching to cpu:%d\n", cpu);
+                kdb_cpu_cmd[cpu] = KDB_CPU_MAIN_KDB;
+
+                /* clear any single step on the current cpu */
+                regs->eflags &= ~X86_EFLAGS_TF;
+                return KDB_CPU_PAUSE;
+            } else {
+                if (cpu != ccpu)
+                    kdbp("Unable to switch to cpu:%d\n", cpu);
+                else {
+                    kdb_display_pc(regs);
+                }
+                return KDB_CPU_MAIN_KDB;
+            }
+    }
+    /* no arg means back to initial cpu */
+    if (!kdb_sys_crash && ccpu != kdb_init_cpu) {
+        if (kdb_cpu_cmd[kdb_init_cpu] == KDB_CPU_PAUSE) {
+            regs->eflags &= ~X86_EFLAGS_TF;
+            kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_MAIN_KDB;
+            return KDB_CPU_PAUSE;
+        } else
+            kdbp("Unable to switch to: %d\n", kdb_init_cpu);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* send NMI to all or given CPU. Must be crashed/fatal state */
+static kdb_cpu_cmd_t
+kdb_usgf_nmi(void)
+{
+    kdbp("nmi cpu#|all: send nmi cpu/s. must reboot when done with kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_nmi(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    cpumask_t cpumask;
+    int ccpu = smp_processor_id();
+
+    if (argc <= 1 || (argc > 1 && *argv[1] == '?'))
+        return kdb_usgf_nmi();
+
+    if (!kdb_sys_crash) {
+        kdbp("kdb: nmi cmd available in crashed state only\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!strcmp(argv[1], "all"))
+        cpumask = cpu_online_map;
+    else {
+        int cpu = (int)simple_strtoul(argv[1], NULL, 0);
+        if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && cpu_online(cpu))
+            cpumask = *cpumask_of(cpu);
+        else {
+            kdbp("KDB nmi: invalid cpu %s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    kdb_nmi_pause_cpus(cpumask);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_percpu(void)
+{
+    kdbp("percpu: display per cpu pointers\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_percpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_percpu();
+    kdb_dump_time_pcpu();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ========================= Breakpoints ==================================== */
+
+static void
+kdb_prnt_bp_cond(int bpnum)
+{
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {
+        kdbp("     ( %s %c%c %lx )\n", 
+             kdb_regoffs_to_name(bpcp->bp_cond_lhs),
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    } else {
+        kdbp("     ( %lx %c%c %lx )\n", bpcp->bp_cond_lhs,
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    }
+}
+
+static void
+kdb_prnt_bp_extra(int bpnum)
+{
+    if (kdb_sbpa[bpnum].bp_type == 2) {
+        ulong i, arg, *btp = kdb_sbpa[bpnum].u.bp_btp;
+        
+        kdbp("   will trace ");
+        for (i=0; i < KDB_MAXBTP && btp[i]; i++)
+            if ((arg=btp[i]) < sizeof (struct cpu_user_regs)) {
+                kdbp(" %s ", kdb_regoffs_to_name(arg));
+            } else {
+                kdbp(" %lx ", arg);
+            }
+        kdbp("\n");
+
+    } else if (kdb_sbpa[bpnum].bp_type == 1)
+        kdb_prnt_bp_cond(bpnum);
+}
+
+/*
+ * List software breakpoints
+ */
+static kdb_cpu_cmd_t
+kdb_display_sbkpts(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted) {
+            struct domain *dp = kdb_domid2ptr(kdb_sbpa[i].bp_domid);
+
+            if (dp == NULL || dp->is_dying) {
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                continue;
+            }
+            kdbp("[%d]: domid:%d 0x%lx   ", i, 
+                 kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr);
+            kdb_prnt_addr2sym(kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr,"\n");
+            kdb_prnt_bp_extra(i);
+        }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Check if any breakpoints that we need to install (delayed install)
+ * Returns: 1 if yes, 0 if none.
+ */
+int
+kdb_swbp_exists(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+/*
+ * Check if any breakpoints were deleted this kdb session
+ * Returns: 0 if none, 1 if yes
+ */
+static int
+kdb_swbp_deleted(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+
+/*
+ * Flush deleted sw breakpoints
+ */
+void
+kdb_flush_swbp_table(void)
+{
+    int i;
+    KDBGP("ccpu:%d flush_swbp_table: deleted:%x\n", smp_processor_id(), 
+          kdb_swbp_deleted());
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted) {
+            KDBGP("flush:[%x] addr:0x%lx\n",i,kdb_sbpa[i].bp_addr);
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        }
+}
+
+/*
+ * Delete/Clear a sw breakpoint
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bc(void)
+{
+    kdbp("bc $num|all : clear given or all breakpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, bpnum = -1, delall = 0;
+    const char *argp;
+
+    if (argc != 2 || *argv[1] == '?')
+        return kdb_usgf_bc();
+
+    if (!kdb_swbp_exists()) {
+        kdbp("No breakpoints are set\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        delall = 1;
+    else if (!kdb_str2deci(argp, &bpnum) || bpnum < 0 || bpnum > KDBMAXSBP) {
+        kdbp("Invalid bpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (delall && kdb_sbpa[i].bp_addr) {
+            kdbp("Deleted breakpoint [%x] addr:0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            continue;
+        }
+        if (bpnum != -1 && bpnum == i) {
+            kdbp("Deleted breakpoint [%x] at 0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            break;
+        }
+    }
+    if (i >= KDBMAXSBP && !delall)
+        kdbp("Unable to delete breakpoint: %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Install a breakpoint in the given array entry
+ * Returns: 0 : failed to install
+ *          1 : installed successfully
+ */
+static int
+kdb_install_swbp(int idx)                   /* which entry in the bp array */
+{
+    kdbva_t addr = kdb_sbpa[idx].bp_addr;
+    domid_t domid = kdb_sbpa[idx].bp_domid;
+    kdbbyt_t *p = &kdb_sbpa[idx].bp_originst;
+    struct domain *dp = kdb_domid2ptr(domid);
+
+    if (dp == NULL || dp->is_dying) {
+        memset(&kdb_sbpa[idx], 0, sizeof(kdb_sbpa[idx]));
+        kdbp("Removed bp %d addr:%p domid:%d\n", idx, addr, domid);
+        return 0;
+    }
+
+    if (kdb_read_mem(addr, p, KDBBPSZ, domid) != KDBBPSZ){
+        kdbp("Failed(R) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    if (kdb_write_mem(addr, &kdb_bpinst, KDBBPSZ, domid) != KDBBPSZ) {
+        kdbp("Failed(W) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    KDBGP("install_swbp: installed bp:%x at:0x%lx ccpu:%x domid:%d\n",
+          idx, kdb_sbpa[idx].bp_addr, smp_processor_id(), domid);
+    return 1;
+}
+
+/*
+ * Install all the software breakpoints
+ */
+void
+kdb_install_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_deleted && kdb_sbpa[i].bp_addr)
+            kdb_install_swbp(i);
+}
+
+static void
+kdb_uninstall_a_swbp(int i)
+{
+    kdbva_t addr = kdb_sbpa[i].bp_addr;
+    kdbbyt_t originst = kdb_sbpa[i].bp_originst;
+    domid_t id = kdb_sbpa[i].bp_domid;
+
+    kdb_sbpa[i].bp_just_added = 0;
+    if (!addr)
+        return;
+    if (kdb_write_mem(addr, &originst, KDBBPSZ, id) != KDBBPSZ) {
+        kdbp("Failed to uninstall breakpoint %x at:0x%lx domid:%d\n",
+             i, kdb_sbpa[i].bp_addr, id);
+    }
+}
+
+/*
+ * Uninstall all the software breakpoints at beginning of kdb session
+ */
+void
+kdb_uninstall_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++) 
+        kdb_uninstall_a_swbp(i);
+    KDBGP("ccpu:%d uninstalled all bps\n", smp_processor_id());
+}
+
+/* RETURNS: rc == 2: condition was not met,  rc == 3: condition was met */
+static int
+kdb_check_bp_condition(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong res = 0, lhsval=0;
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {             /* register condition */
+        uint64_t *rp = (uint64_t *)((char *)regs + bpcp->bp_cond_lhs);
+        lhsval = *rp;
+    } else if (bpcp->bp_cond_status == 2) {      /* memaddr condition */
+        ulong addr = bpcp->bp_cond_lhs;
+        int num = sizeof(lhsval);
+
+        if (kdb_read_mem(addr, (kdbbyt_t *)&lhsval, num, domid) != num) {
+            kdbp("kdb: unable to read %d bytes at %lx\n", num, addr);
+            return 3;
+        }
+    }
+    if (bpcp->bp_cond_type == 1)                 /* lhs == rhs */
+        res = (lhsval == bpcp->bp_cond_rhs);
+    else                                         /* lhs != rhs */
+        res = (lhsval != bpcp->bp_cond_rhs);
+
+    if (!res)
+        kdbp("KDB: [%d]Ignoring bp:%d condition not met. val:%lx\n", 
+              smp_processor_id(), bpnum, lhsval); 
+
+    KDBGP1("bpnum:%d domid:%d cond: %d %d %lx %lx res:%d\n", bpnum, domid, 
+           bpcp->bp_cond_status, bpcp->bp_cond_type, bpcp->bp_cond_lhs, 
+           bpcp->bp_cond_rhs, res);
+
+    return (res ? 3 : 2);
+}
+
+static void
+kdb_prnt_btp_info(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong i, arg, val, num, *btp = kdb_sbpa[bpnum].u.bp_btp;
+
+    kdb_prnt_addr2sym(domid, regs->KDBIP, "\n");
+    num = kdb_guest_bitness(domid)/8;
+    for (i=0; i < KDB_MAXBTP && (arg=btp[i]); i++) {
+        if (arg < sizeof (struct cpu_user_regs)) {
+            uint64_t *rp = (uint64_t *)((char *)regs + arg);
+            kdbp(" %s: %016lx ", kdb_regoffs_to_name(arg), *rp);
+        } else {
+            if (kdb_read_mem(arg, (kdbbyt_t *)&val, num, domid) != num)
+                kdbp("kdb: unable to read %d bytes at %lx\n", num, arg);
+            if (num == 8)
+                kdbp(" %016lx:%016lx ", arg, val);
+            else
+                kdbp(" %08lx:%08lx ", arg, val);
+        }
+    }
+    kdbp("\n");
+    KDBGP1("bpnum:%d domid:%d btp:%p num:%d\n", bpnum, domid, btp, num);
+}
+
+/*
+ * Check if the BP trap belongs to us. 
+ * Return: 0 : not one of ours. IP not changed. (leave kdb)
+ *         1 : one of ours but deleted. IP decremented. (leave kdb)
+ *         2 : one of ours but condition not met, or btp. IP decremented.(leave)
+ *         3 : one of ours and active. IP decremented. (stay in kdb)
+ */
+int 
+kdb_check_sw_bkpts(struct cpu_user_regs *regs)
+{
+    int i, rc=0;
+    domid_t curid;
+
+    curid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    for(i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_domid == curid  && 
+            kdb_sbpa[i].bp_addr == (regs->KDBIP- KDBBPSZ)) {
+
+            regs->KDBIP -= KDBBPSZ;
+            rc = 3;
+
+            if (kdb_sbpa[i].bp_ni) {
+                kdb_uninstall_a_swbp(i);
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            } else if (kdb_sbpa[i].bp_deleted) {
+                rc = 1;
+            } else if (kdb_sbpa[i].bp_type == 1) {
+                rc = kdb_check_bp_condition(i, regs, curid);
+            } else if (kdb_sbpa[i].bp_type == 2) {
+                kdb_prnt_btp_info(i, regs, curid);
+                rc = 2;
+            }
+            KDBGP1("ccpu:%d rc:%d curid:%d domid:%d addr:%lx\n", 
+                   smp_processor_id(), rc, curid, kdb_sbpa[i].bp_domid, 
+                   kdb_sbpa[i].bp_addr);
+            break;
+        }
+    }
+    return (rc);
+}
+
+/* Eg: r6 == 0x123EDF  or 0xFFFF2034 != 0xDEADBEEF
+ * regoffs: -1 means lhs is not reg. else offset of reg in cpu_user_regs
+ * addr: memory location if lhs is not register, eg, 0xFFFF2034
+ * condp : points to != or ==
+ * rhsval : right hand side value
+ */
+static void
+kdb_set_bp_cond(int bpnum, int regoffs, ulong addr, char *condp, ulong rhsval)
+{
+    if (bpnum >= KDBMAXSBP) {
+        kdbp("BUG: %s got invalid bpnum\n", __FUNCTION__);
+        return;
+    }
+    if (regoffs != -1) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 1;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = regoffs;
+    } else if (addr != 0) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 2;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = addr;
+    } else {
+        kdbp("error: invalid call to kdb_set_bp_cond\n");
+        return;
+    }
+    kdb_sbpa[bpnum].u.bp_cond.bp_cond_rhs = rhsval;
+
+    if (*condp == '!')
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 2;
+    else
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 1;
+}
+
+/* install breakpt at given addr. 
+ * ni: bp for next instr 
+ * btpa: ptr to args for btp for printing when bp is hit
+ * lhsp/condp/rhsp: point to strings of condition
+ *
+ * RETURNS: the index in array where installed. KDBMAXSBP if error 
+ */
+static int
+kdb_set_bp(domid_t domid, kdbva_t addr, int ni, ulong *btpa, char *lhsp, 
+           char *condp, char *rhsp)
+{
+    int i, pre_existing = 0, regoffs = -1;
+    ulong memloc=0, rhsval=0, tmpul;
+
+    if (btpa && (lhsp || rhsp || condp)) {
+        kdbp("internal error. btpa and (lhsp || rhsp || condp) set\n");
+        return KDBMAXSBP;
+    }
+    if (lhsp && ((regoffs=kdb_valid_reg(lhsp)) == -1)  &&
+        kdb_str2ulong(lhsp, &memloc) &&
+        kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0) {
+
+        kdbp("error: invalid argument: %s\n", lhsp);
+        return KDBMAXSBP;
+    }
+    if (rhsp && ! kdb_str2ulong(rhsp, &rhsval)) {
+        kdbp("error: invalid argument: %s\n", rhsp);
+        return KDBMAXSBP;
+    }
+
+    /* see if bp already set */
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_addr==addr && kdb_sbpa[i].bp_domid==domid) {
+
+            if (kdb_sbpa[i].bp_deleted) {
+                /* just re-set this bp again */
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                pre_existing = 1;
+            } else {
+                kdbp("Breakpoint already set \n");
+                return KDBMAXSBP;
+            }
+        }
+    }
+    /* see if any room left for another breakpoint */
+    for (i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_addr)
+            break;
+    if (i >= KDBMAXSBP) {
+        kdbp("ERROR: Breakpoint table full....\n");
+        return i;
+    }
+    kdb_sbpa[i].bp_addr = addr;
+    kdb_sbpa[i].bp_domid = domid;
+    if (btpa) {
+        kdb_sbpa[i].bp_type = 2;
+        kdb_sbpa[i].u.bp_btp = btpa;
+    } else if (regoffs != -1 || memloc) {
+        kdb_sbpa[i].bp_type = 1;
+        kdb_set_bp_cond(i, regoffs, memloc, condp, rhsval);
+    } else
+        kdb_sbpa[i].bp_type = 0;
+
+    if (kdb_install_swbp(i)) {                  /* make sure it can be done */
+        if (ni)
+            return i;
+
+        kdb_uninstall_a_swbp(i);                /* dont' show user INT3 */
+        if (!pre_existing)               /* make sure no is cpu sitting on it */
+            kdb_sbpa[i].bp_just_added = 1;
+
+        kdbp("bp %d set for domid:%d at: 0x%lx ", i, kdb_sbpa[i].bp_domid, 
+             kdb_sbpa[i].bp_addr);
+        kdb_prnt_addr2sym(domid, addr, "\n");
+        kdb_prnt_bp_extra(i);
+    } else {
+        kdbp("ERROR:Can't install bp: 0x%lx domid:%d\n", addr, domid);
+        if (pre_existing)     /* in case a cpu is sitting on this bp in traps */
+            kdb_sbpa[i].bp_deleted = 1;
+        else
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        return KDBMAXSBP;
+    }
+    /* make sure swbp reporting is enabled in the vmcb/vmcs */
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        struct domain *dp = kdb_domid2ptr(domid);
+        dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
+        KDBGP("debugger_attached set. domid:%d\n", domid);
+    }
+    return i;
+}
+
+/* 
+ * Set/List Software Breakpoint/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bp(void)
+{
+    kdbp("bp [addr|sym][domid][condition]: display or set a breakpoint\n");
+    kdbp("  where cond is like: r6 == 0x123F or rax != DEADBEEF or \n");
+    kdbp("       ffff82c48038fe58 == 321E or 0xffff82c48038fe58 != 0\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9");
+    kdbp(" r10 r11 r12 r13 r14 r15 rflags\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    int idx = -1;
+    domid_t domid = DOMID_IDLE;
+    char *domidstrp, *lhsp=NULL, *condp=NULL, *rhsp=NULL;
+
+    if ((argc > 1 && *argv[1] == '?') || argc == 4 || argc > 6)
+        return kdb_usgf_bp();
+
+    if (argc < 2 || kdb_sys_crash)         /* list all set breakpoints */
+        return kdb_display_sbkpts();
+
+    /* valid argc either: 2 3 5 or 6 
+     * 'bp idle_loop r6 == 0xc000' OR 'bp idle_loop 3 r9 != 0xdeadbeef' */
+    idx = (argc == 5) ? 2 : ((argc == 6) ? 3 : idx);
+    if (argc >= 5 ) {
+        lhsp = (char *)argv[idx];
+        condp = (char *)argv[idx+1];
+        rhsp = (char *)argv[idx+2];
+
+        if (!kdb_str2ulong(rhsp, NULL) || *(condp+1) != '=' || 
+            (*condp != '=' && *condp != '!')) {
+
+            return kdb_usgf_bp();
+        }
+    }
+    domidstrp = (argc == 3 || argc == 6 ) ? (char *)argv[2] : NULL;
+    if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
+        return kdb_usgf_bp();
+    }
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        kdbp("HVM domain not supported yet for conditional bp\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    /* make sure xen addr is in xen text, otherwise bp set in 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_set_bp(domid, addr, 0, NULL, lhsp, condp, rhsp);     /* 0 is ni flag */
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* trace breakpoint, meaning, upon bp trace/print some info and continue */
+
+static kdb_cpu_cmd_t
+kdb_usgf_btp(void)
+{
+    kdbp("btp addr|sym [domid] reg|domid-mem-addr... : breakpoint trace\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9 ");
+    kdbp("r10 r11 r12 r13 r14 r15 rflags\n");
+    kdbp("  Eg. btp idle_cpu 7 rax rbx 0x20ef5a5 r9\n");
+    kdbp("      will print rax, rbx, *(long *)0x20ef5a5, r9 and continue\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_btp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, btpidx, numrd, argsidx, regoffs = -1;
+    kdbva_t addr, memloc=0;
+    domid_t domid = DOMID_IDLE;
+    ulong *btpa, tmpul;
+
+    if ((argc > 1 && *argv[1] == '?') || argc < 3)
+        return kdb_usgf_btp();
+
+    argsidx = 2;                   /* assume 3rd arg is not domid */
+    if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
+
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+            kdbp("HVM domains are not currently supprted\n");
+            return KDB_CPU_MAIN_KDB;
+        } else
+            argsidx = 3;               /* 3rd arg is a domid */
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    /* make sure xen addr is in xen text, otherwise will trace 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    numrd = kdb_guest_bitness(domid)/8;
+    if (kdb_read_mem(addr, (kdbbyt_t *)&tmpul, numrd, domid) != numrd) {
+        kdbp("Unable to read mem from %s (%lx)\n", argv[1], addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    for (btpidx=0; btpidx < KDBMAXSBP && kdb_btp_ap[btpidx]; btpidx++);
+    if (btpidx >= KDBMAXSBP) {
+        kdbp("error: table full. delete few breakpoints\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    btpa = kdb_btp_argsa[btpidx];
+    memset(btpa, 0, sizeof(kdb_btp_argsa[0]));
+
+    for (i=0; argv[argsidx]; i++, argsidx++) {
+
+        if (((regoffs=kdb_valid_reg(argv[argsidx])) == -1)  &&
+            kdb_str2ulong(argv[argsidx], &memloc) &&
+            (memloc < sizeof (struct cpu_user_regs) ||
+            kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0)){
+
+            kdbp("error: invalid argument: %s\n", argv[argsidx]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        if (i >= KDB_MAXBTP) {
+            kdbp("error: cannot specify more than %d args\n", KDB_MAXBTP);
+            return KDB_CPU_MAIN_KDB;
+        }
+        btpa[i] = (regoffs == -1) ? memloc : regoffs;
+    }
+
+    i = kdb_set_bp(domid, addr, 0, btpa, 0, 0, 0);     /* 0 is ni flag */
+    if (i < KDBMAXSBP)
+        kdb_btp_ap[btpidx] = kdb_btp_argsa[btpidx];
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * Set/List watchpoints, ie, hardware breakpoint/s, in hypervisor
+ *   Usage: wp [sym|addr] [w|i]   w == write only data watchpoint
+ *                                i == IO watchpoint (read/write)
+ *
+ *   Eg:  wp        : list all watchpoints set
+ *        wp addr   : set a read/write wp at given addr
+ *        wp addr w : set a write only wp at given addr
+ *        wp addr i : set an IO wp at given addr (16bits port #)
+ *
+ *  TBD: allow to be set on particular cpu
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_wp(void)
+{
+    kdbp("wp [addr|sym][w|i]: display or set watchpoint. writeonly or IO\n");
+    kdbp("\tnote: watchpoint is triggered after the instruction executes\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    domid_t domid = DOMID_IDLE;
+    int rw = 3, len = 4;       /* for now just default to 4 bytes len */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_wp();
+
+    if (argc <= 1 || kdb_sys_crash) {       /* list all set watchpoints */
+        kdb_do_watchpoints(0, 0, 0);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2) {
+        if (!strcmp(argv[2], "w"))
+            rw = 1;
+        else if (!strcmp(argv[2], "i"))
+            rw = 2;
+        else {
+            return kdb_usgf_wp();
+        }
+    }
+    kdb_do_watchpoints(addr, rw, len);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_wc(void)
+{
+    kdbp("wc $num|all : clear given or all watchpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int wpnum;              /* wp num to delete. -1 for all */
+
+    if (argc != 2 || *argv[1] == '?') 
+        return kdb_usgf_wc();
+
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        wpnum = -1;
+    else if (!kdb_str2deci(argp, &wpnum)) {
+        kdbp("Invalid wpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_clear_wps(wpnum);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display struct hvm_vcpu{} in struct vcpu.arch{} */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpuh(void)
+{
+    kdbp("vcpuh vcpu-ptr : display hvm_vcpu struct\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpuh(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *vp;
+    struct hvm_vcpu *hvp;
+    struct hvm_io_op *ioop;
+    struct vlapic *vlp;
+
+    if (argc < 2 || *argv[1] == '?') 
+        return kdb_usgf_vcpuh();
+
+    if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
+        !is_hvm_or_hyb_vcpu(vp)) {
+
+        kdbp("kdb: Bad VCPU: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    hvp = &vp->arch.hvm_vcpu;
+    vlp = &hvp->vlapic;
+    kdbp("vcpu:%lx id:%d domid:%d\n", vp, vp->vcpu_id, vp->domain->domain_id);
+
+    ioop = NULL;   /* compiler warning */
+    kdbp("&hvm_vcpu:%lx  guest_efer:"KDBFL"\n", hvp, hvp->guest_efer);
+    kdbp("  guest_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->guest_cr[0],
+         hvp->guest_cr[1],hvp->guest_cr[2]);
+    kdbp("            [3]:"KDBFL" [4]:"KDBFL"\n", hvp->guest_cr[3],
+         hvp->guest_cr[4]);
+    kdbp("  hw_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->hw_cr[0],
+         hvp->hw_cr[1], hvp->hw_cr[2]);
+    kdbp("          [3]:"KDBFL" [4]:"KDBFL"\n", hvp->hw_cr[3], hvp->hw_cr[4]);
+
+    kdbp("  VLAPIC: base msr:"KDBF64" dis:%x tmrdiv:%x\n", 
+         vlp->hw.apic_base_msr, vlp->hw.disabled, vlp->hw.timer_divisor);
+    kdbp("          regs:%p regs_page:%p\n", vlp->regs, vlp->regs_page);
+    kdbp("          periodic time:\n"); 
+    kdb_prnt_periodic_time(&vlp->pt);
+
+    kdbp("  xen_port:%x flag_dr_dirty:%x dbg_st_latch:%x\n", hvp->xen_port,
+         hvp->flag_dr_dirty, hvp->debug_state_latch);
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+
+        struct arch_vmx_struct *vxp = &hvp->u.vmx;
+        kdbp("  &vmx: %p vmcs:%lx active_cpu:%x launched:%x\n", vxp, vxp->vmcs, 
+             vxp->active_cpu, vxp->launched);
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("    exec_ctrl:%x vpid:$%d\n", vxp->exec_control, vxp->vpid);
+#endif
+        kdbp("    host_cr0: "KDBFL" vmx: {realm:%x emulate:%x}\n",
+             vxp->host_cr0, vxp->vmx_realmode, vxp->vmx_emulate);
+
+#ifdef __x86_64__
+        kdbp("    &msr_state:%p\n", &vxp->msr_state);
+#endif
+    } else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+        struct arch_svm_struct *svp = &hvp->u.svm;
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("  &svm: vmcb:%lx pa:"KDBF64" asid:"KDBF64"\n", svp, svp->vmcb,
+             svp->vmcb_pa, svp->asid_generation);
+#endif
+        kdbp("    msrpm:%p lnch_core:%x vmcb_sync:%x\n", svp->msrpm, 
+             svp->launch_core, svp->vmcb_in_sync);
+    }
+    kdbp("  cachemode:%x io: {state: %x data: "KDBFL"}\n", hvp->cache_mode,
+         hvp->hvm_io.io_state, hvp->hvm_io.io_data);
+    kdbp("  mmio: {gva: "KDBFL" gpfn: "KDBFL"}\n", hvp->hvm_io.mmio_gva,
+         hvp->hvm_io.mmio_gpfn);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* also look into arch_get_info_guest() to get context */
+static void
+kdb_print_uregs(struct cpu_user_regs *regs)
+{
+#ifdef __x86_64__
+    kdbp("      rflags: %016lx   rip: %016lx\n", regs->rflags, regs->rip);
+    kdbp("         rax: %016lx   rbx: %016lx   rcx: %016lx\n",
+         regs->rax, regs->rbx, regs->rcx);
+    kdbp("         rdx: %016lx   rsi: %016lx   rdi: %016lx\n",
+         regs->rdx, regs->rsi, regs->rdi);
+    kdbp("         rbp: %016lx   rsp: %016lx    r8: %016lx\n",
+         regs->rbp, regs->rsp, regs->r8);
+    kdbp("          r9:  %016lx  r10: %016lx   r11: %016lx\n",
+         regs->r9,  regs->r10, regs->r11);
+    kdbp("         r12: %016lx   r13: %016lx   r14: %016lx\n",
+         regs->r12, regs->r13, regs->r14);
+    kdbp("         r15: %016lx\n", regs->r15);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+         "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%08lx entryvec:%08lx upcall_mask:%lx\n",
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#else
+    kdbp("      eflags: %016lx eip: 016lx\n", regs->eflags, regs->eip);
+    kdbp("      eax: %08x   ebx: %08x   ecx: %08x   edx: %08x\n",
+         regs->eax, regs->ebx, regs->ecx, regs->edx);
+    kdbp("      esi: %08x   edi: %08x   ebp: %08x   esp: %08x\n",
+         regs->esi, regs->edi, regs->ebp, regs->esp);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+     "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%04lx entryvec:%04lx upcall_mask:%lx\n", 
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#endif
+}
+
+#if XEN_SUBVERSION < 3             /* xen 3.1.x or xen 3.2.x */
+#ifdef CONFIG_COMPAT
+    #undef vcpu_info
+    #define vcpu_info(v, field)             \
+    (*(!has_32bit_shinfo((v)->domain) ?                                       \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->native.field : \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->compat.field))
+
+    #undef __shared_info
+    #define __shared_info(d, s, field)                      \
+    (*(!has_32bit_shinfo(d) ?                           \
+       (typeof(&(s)->compat.field))&(s)->native.field : \
+       (typeof(&(s)->compat.field))&(s)->compat.field))
+#endif
+#endif
+
+static void kdb_display_pv_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct pv_vcpu *gp = &vp->arch.pv_vcpu;
+
+    kdbp("      GDT_VIRT_START(vcpu): %lx\n", GDT_VIRT_START(vp));
+    kdbp("      GDT: entries:0x%lx  frames:\n", gp->gdt_ents);
+    for (i=0; i < 16; i=i+4) 
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->gdt_frames[i], 
+             gp->gdt_frames[i+1], gp->gdt_frames[i+2],gp->gdt_frames[i+3]);
+    
+    kdbp("      trap_ctxt:%lx kernel_ss:%lx kernel_sp:%lx\n", gp->trap_ctxt,
+         gp->kernel_ss, gp->kernel_sp);
+    kdbp("      ctrlregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->ctrlreg[i], 
+             gp->ctrlreg[i+1], gp->ctrlreg[i+2], gp->ctrlreg[i+3]);
+#ifdef __x86_64__
+    kdbp("      callback:   event: %016lx   failsafe: %016lx\n", 
+         gp->event_callback_eip, gp->failsafe_callback_eip);
+    kdbp("      base: fs:0x%lx gskern:0x%lx gsuser:0x%lx\n", 
+         gp->fs_base, gp->gs_base_kernel, gp->gs_base_user);
+#else
+    kdbp("      callback:   event: %08lx:%08lx   failsafe: %08lx:%08lx\n", 
+         gp->event_callback_cs, gp->event_callback_eip, 
+         gp->failsafe_callback_cs, gp->failsafe_callback_eip);
+#endif
+    kdbp("    vcpu_info_mfn: %lx  iopl: %x\n", gp->vcpu_info_mfn, gp->iopl);
+    kdbp("\n");
+}
+
+/* Display one VCPU info */
+static void
+kdb_display_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct arch_vcpu *avp = &vp->arch;
+    struct paging_vcpu *pvp = &vp->arch.paging;
+    int domid = vp->domain->domain_id;
+
+    kdbp("\nVCPU:  vcpu-id:%d  vcpu-ptr:%p ", vp->vcpu_id, vp);
+    kdbp("  processor:%d domid:%d  domp:%p\n", vp->processor, domid,vp->domain);
+
+    if (domid == DOMID_IDLE) {
+        kdbp("    IDLE vcpu.\n");
+        return;
+    }
+    kdbp("  pause: flags:0x%016lx count:%x\n", vp->pause_flags, 
+         vp->pause_count.counter);
+    kdbp("  vcpu: initdone:%d running:%d\n", 
+         vp->is_initialised, vp->is_running);
+    kdbp("  mcepend:%d nmipend:%d shut: def:%d paused:%d\n", 
+         vp->mce_pending,  vp->nmi_pending, vp->defer_shutdown, 
+         vp->paused_for_shutdown);
+    kdbp("  &vcpu_info:%p : evtchn_upc_pend:%x _mask:%x\n",
+         vp->vcpu_info, vcpu_info(vp, evtchn_upcall_pending),
+         vcpu_info(vp, evtchn_upcall_mask));
+    kdbp("  evt_pend_sel:%lx poll_evtchn:%x ", 
+         *(unsigned long *)&vcpu_info(vp, evtchn_pending_sel), vp->poll_evtchn);
+    kdb_print_spin_lock("virq_lock:", &vp->virq_lock, "\n");
+    for (i=0; i < NR_VIRQS; i++)
+        if (vp->virq_to_evtchn[i] != 0)
+            kdbp("      virq:$%d port:$%d\n", i, vp->virq_to_evtchn[i]);
+
+    kdbp("  next:%p periodic: period:0x%lx last_event:0x%lx\n", 
+         vp->next_in_list, vp->periodic_period, vp->periodic_last_event);
+    kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:%p sched_priv:0x%p\n",
+         vp->cpu_affinity, vp->vcpu_dirty_cpumask, vp->sched_priv);
+    kdbp("  &runstate: %p state: %x (eg. RUNSTATE_running) guestptr:%p\n", 
+         &vp->runstate, vp->runstate.state, runstate_guest(vp));
+    kdbp("\n");
+    kdbp("  arch info: (%p)\n", &vp->arch);
+    kdbp("    guest_context: VGCF_ flags:%lx", 
+         vp->arch.vgc_flags); /* VGCF_in_kernel */
+    if (is_hvm_or_hyb_vcpu(vp))
+        kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
+    kdbp("\n");
+    kdb_print_uregs(&vp->arch.user_regs);
+    kdbp("      debugregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", avp->debugreg[i], 
+             avp->debugreg[i+1], avp->debugreg[i+2], avp->debugreg[i+3]);
+    kdb_display_pv_vcpu(vp);
+
+    kdbp("    TF_flags: %016lx  guest_table: %016lx cr3:%016lx\n", 
+         vp->arch.flags, vp->arch.guest_table.pfn, avp->cr3); 
+    kdbp("    paging: \n");
+    kdbp("      vtlb:%p\n", &pvp->vtlb);
+    kdbp("      &pg_mode:%p gstlevels:%d &shadow:%p shlevels:%d\n",
+         pvp->mode, pvp->mode->guest_levels, &pvp->mode->shadow,
+         pvp->mode->shadow.shadow_levels);
+    kdbp("      shadow_vcpu:\n");
+    kdbp("        guest_vtable:%p last em_mfn:"KDBFL"\n",
+         pvp->shadow.guest_vtable, pvp->shadow.last_emulated_mfn);
+#if CONFIG_PAGING_LEVELS >= 3
+    kdbp("         l3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.l3table[3].l3, pvp->shadow.l3table[2].l3, 
+     pvp->shadow.l3table[1].l3, pvp->shadow.l3table[0].l3);
+    kdbp("        gl3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.gl3e[3].l3, pvp->shadow.gl3e[2].l3, 
+     pvp->shadow.gl3e[1].l3, pvp->shadow.gl3e[0].l3);
+#endif
+    kdbp("  gdbsx_vcpu_event:%x\n", vp->arch.gdbsx_vcpu_event);
+}
+
+/* 
+ * FUNCTION: Dispaly (current) VCPU/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpu(void)
+{
+    kdbp("vcpu [vcpu-ptr] : display current/vcpu-ptr vcpu info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *v = current;
+
+    if (argc > 2 || (argc > 1 && *argv[1] == '?'))
+        kdb_usgf_vcpu();
+    else if (argc <= 1)
+        kdb_display_vcpu(v);
+    else if (kdb_str2ulong(argv[1], (ulong *)&v) && kdb_vcpu_valid(v))
+        kdb_display_vcpu(v);
+    else 
+        kdbp("Invalid usage/argument:%s v:%lx\n", argv[1], (long)v);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* from paging_dump_domain_info() */
+static void kdb_pr_dom_pg_modes(struct domain *d)
+{
+    if (paging_mode_enabled(d)) {
+        kdbp(" paging mode enabled");
+        if ( paging_mode_shadow(d) )
+            kdbp(" shadow(PG_SH_enable)");
+        if ( paging_mode_hap(d) )
+            kdbp(" hap(PG_HAP_enable) ");
+        if ( paging_mode_refcounts(d) )
+            kdbp(" refcounts(PG_refcounts) ");
+        if ( paging_mode_log_dirty(d) )
+            kdbp(" log_dirty(PG_log_dirty) ");
+        if ( paging_mode_translate(d) )
+            kdbp(" translate(PG_translate) ");
+        if ( paging_mode_external(d) )
+            kdbp(" external(PG_external) ");
+    } else
+        kdbp(" disabled");
+    kdbp("\n");
+}
+
+/* print event channels info for a given domain 
+ * NOTE: very confusing, port and event channel refer to the same thing. evtchn
+ * is arry of pointers to a bucket of pointers to 128 struct evtchn{}. while
+ * 64bit xen can handle 4096 max channels, a 32bit guest is limited to 1024 */
+static void noinline kdb_print_dom_eventinfo(struct domain *dp)
+{
+    uint chn;
+
+    kdbp("\n");
+    kdbp("  Evt: MAX_EVTCHNS:$%d ptr:%p pollmsk:%08lx ",
+         MAX_EVTCHNS(dp), dp->evtchn, dp->poll_mask[0]);
+    kdb_print_spin_lock("lk:", &dp->event_lock, "\n");
+    kdbp("    &evtchn_pending:%p &evtchn_mask:%p\n", 
+         shared_info(dp, evtchn_pending), shared_info(dp, evtchn_mask));
+
+    kdbp("   Channels info: (everything is in decimal):\n");
+    for (chn=0; chn < MAX_EVTCHNS(dp); chn++ ) {
+        struct evtchn *bktp = dp->evtchn[chn/EVTCHNS_PER_BUCKET];
+        struct evtchn *chnp = &bktp[chn & (EVTCHNS_PER_BUCKET-1)];
+        char pbit = test_bit(chn, &shared_info(dp, evtchn_pending)) ? 'Y' : 'N';
+        char mbit = test_bit(chn, &shared_info(dp, evtchn_mask)) ? 'Y' : 'N';
+
+        if (bktp==NULL || chnp->state==ECS_FREE)
+            continue;
+
+        kdbp("    chn:%4u st:%d _xen=%d _vcpu_id:%2d ", chn, chnp->state,
+             chnp->xen_consumer, chnp->notify_vcpu_id);
+        if (chnp->state == ECS_UNBOUND)
+            kdbp(" rem-domid:%d", chnp->u.unbound.remote_domid);
+        else if (chnp->state == ECS_INTERDOMAIN)
+            kdbp(" rem-port:%d rem-dom:%d", chnp->u.interdomain.remote_port,
+                 chnp->u.interdomain.remote_dom->domain_id);
+        else if (chnp->state == ECS_PIRQ)
+            kdbp(" pirq:%d", chnp->u.pirq);
+        else if (chnp->state == ECS_VIRQ)
+            kdbp(" virq:%d", chnp->u.virq);
+
+        kdbp("  pend:%c mask:%c\n", pbit, mbit);
+    }
+#if 0
+    kdbp("pirq to evtchn mapping (pirq:evtchn) (all decimal):\n");
+    for (i=0; i < dp->nr_pirqs; i ++)
+        if (dp->pirq_to_evtchn[i])
+            kdbp("(%d:%d) ", i, dp->pirq_to_evtchn[i]);
+    kdbp("\n");
+#endif
+}
+
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    struct hvm_domain *hvp = &dp->arch.hvm_domain;
+
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+    if (hvp == NULL)
+        return;
+
+    if (hvp->irq.callback_via_type == HVMIRQ_callback_vector)
+        kdbp("    HVMIRQ_callback_vector: %x\n", hvp->irq.callback_via.vector);
+
+    if (!is_hvm_domain(dp))
+        return;
+
+    kdbp("    HVM PARAMS (all in hex):\n");
+    kdbp("\tioreq.page:%lx ioreq.va:%lx\n", hvp->ioreq.page, hvp->ioreq.va);
+    kdbp("\tbuf_ioreq.page:%lx ioreq.va:%lx\n", hvp->buf_ioreq.page, 
+         hvp->buf_ioreq.va);
+    kdbp("\tHVM_PARAM_CALLBACK_IRQ: %x\n", hvp->params[HVM_PARAM_CALLBACK_IRQ]);
+    kdbp("\tHVM_PARAM_STORE_PFN: %x\n", hvp->params[HVM_PARAM_STORE_PFN]);
+    kdbp("\tHVM_PARAM_STORE_EVTCHN: %x\n", hvp->params[HVM_PARAM_STORE_EVTCHN]);
+    kdbp("\tHVM_PARAM_PAE_ENABLED: %x\n", hvp->params[HVM_PARAM_PAE_ENABLED]);
+    kdbp("\tHVM_PARAM_IOREQ_PFN: %x\n", hvp->params[HVM_PARAM_IOREQ_PFN]);
+    kdbp("\tHVM_PARAM_BUFIOREQ_PFN: %x\n", hvp->params[HVM_PARAM_BUFIOREQ_PFN]);
+    kdbp("\tHVM_PARAM_VIRIDIAN: %x\n", hvp->params[HVM_PARAM_VIRIDIAN]);
+    kdbp("\tHVM_PARAM_TIMER_MODE: %x\n", hvp->params[HVM_PARAM_TIMER_MODE]);
+    kdbp("\tHVM_PARAM_HPET_ENABLED: %x\n", hvp->params[HVM_PARAM_HPET_ENABLED]);
+    kdbp("\tHVM_PARAM_IDENT_PT: %x\n", hvp->params[HVM_PARAM_IDENT_PT]);
+    kdbp("\tHVM_PARAM_DM_DOMAIN: %x\n", hvp->params[HVM_PARAM_DM_DOMAIN]);
+    kdbp("\tHVM_PARAM_ACPI_S_STATE: %x\n", hvp->params[HVM_PARAM_ACPI_S_STATE]);
+    kdbp("\tHVM_PARAM_VM86_TSS: %x\n", hvp->params[HVM_PARAM_VM86_TSS]);
+    kdbp("\tHVM_PARAM_VPT_ALIGN: %x\n", hvp->params[HVM_PARAM_VPT_ALIGN]);
+    kdbp("\tHVM_PARAM_CONSOLE_PFN: %x\n", hvp->params[HVM_PARAM_CONSOLE_PFN]);
+    kdbp("\tHVM_PARAM_CONSOLE_EVTCHN: %x\n", 
+         hvp->params[HVM_PARAM_CONSOLE_EVTCHN]);
+    kdbp("\tHVM_PARAM_ACPI_IOPORTS_LOCATION: %x\n", 
+         hvp->params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+    kdbp("\tHVM_PARAM_MEMORY_EVENT_SINGLE_STEP: %x\n", 
+         hvp->params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP]);
+}
+static void kdb_print_rangesets(struct domain *dp)
+{
+    int locked = spin_is_locked(&dp->rangesets_lock);
+
+    if (locked)
+        spin_unlock(&dp->rangesets_lock);
+    rangeset_domain_printk(dp);
+    if (locked)
+        spin_lock(&dp->rangesets_lock);
+}
+
+static void kdb_pr_vtsc_info(struct arch_domain *ap)
+{
+    kdbp("    VTSC info: tsc_mode:%x  vtsc:%x  vtsc_last:%016lx\n", 
+         ap->tsc_mode, ap->vtsc, ap->vtsc_last);
+    kdbp("        vtsc_offset:%016lx tsc_khz:%08lx incarnation:%x\n", 
+         ap->vtsc_offset, ap->vtsc_offset, ap->incarnation);
+    kdbp("        vtsc_kerncount:%016lx _usercount:%016lx\n",
+         ap->vtsc_kerncount, ap->vtsc_usercount);
+}
+
+/* display one domain info */
+static void
+kdb_display_dom(struct domain *dp)
+{
+    struct vcpu *vp;
+    int printed = 0;
+    struct grant_table *gp = dp->grant_table;
+    struct arch_domain *ap = &dp->arch;
+
+    kdbp("\nDOMAIN :    domid:0x%04x ptr:0x%p\n", dp->domain_id, dp);
+    if (dp->domain_id == DOMID_IDLE) {
+        kdbp("    IDLE domain.\n");
+        return;
+    }
+    if (dp->is_dying) {
+        kdbp("    domain is DYING.\n");
+        return;
+    }
+#if 0
+    kdb_print_spin_lock("  pgalk:", &dp->page_alloc_lock, "\n");
+    kdbp("  pglist:  0x%p 0x%p\n", dp->page_list.next,KDB_PGLLE(dp->page_list));
+    kdbp("  xpglist: 0x%p 0x%p\n", dp->xenpage_list.next, 
+         KDB_PGLLE(dp->xenpage_list));
+    kdbp("  next:0x%p hashnext:0x%p\n", 
+         dp->next_in_list, dp->next_in_hashbucket);
+#endif
+    kdbp("  PAGES: tot:0x%08x max:0x%08x xenheap:0x%08x\n", 
+         dp->tot_pages, dp->max_pages, dp->xenheap_pages);
+
+    kdb_print_rangesets(dp);
+    kdb_print_dom_eventinfo(dp);
+    kdbp("\n");
+    kdbp("  Grant table: gp:0x%p\n", gp);
+    if (gp) {
+        kdbp("    nr_frames:0x%08x shpp:0x%p active:0x%p\n",
+             gp->nr_grant_frames, gp->shared_raw, gp->active);
+        kdbp("    maptrk:0x%p maphd:0x%08x maplmt:0x%08x\n", 
+             gp->maptrack, gp->maptrack_head, gp->maptrack_limit);
+        kdbp("    mapcnt:");
+        kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
+    }
+    kdbp("  hvm:%d priv:%d need_iommu:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_privileged, dp->need_iommu,
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
+    kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
+    kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
+         dp->is_shut_down, dp->shutdown_code);
+    kdbp("  pausecnt:0x%08x vm_assist:0x"KDBFL" refcnt:0x%08x\n",
+         dp->pause_count.counter, dp->vm_assist, dp->refcnt.counter);
+    kdbp("  &domain_dirty_cpumask:%p\n", &dp->domain_dirty_cpumask); 
+
+    kdbp("  shared == vcpu_info[]: %p\n",  dp->shared_info); 
+    kdbp("    arch_shared: maxpfn: %lx pfn-mfn-frame-ll mfn: %lx\n", 
+         arch_get_max_pfn(dp), arch_get_pfn_to_mfn_frame_list_list(dp));
+    kdbp("\n");
+    kdbp("  arch_domain at : %p\n", ap);
+
+#ifdef CONFIG_X86_64
+    kdbp("    pt_pages:0x%p ", ap->mm_perdomain_pt_pages);
+    kdbp("    l2:0x%p l3:0x%p\n", ap->mm_perdomain_l2, ap->mm_perdomain_l3);
+#else
+    kdbp("    pt:0x%p ", ap->mm_perdomain_pt);
+#endif
+#ifdef CONFIG_X86_32
+    kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
+#endif
+    kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
+    kdb_pr_dom_pg_modes(dp);
+    kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
+         KDB_PGLLE(ap->p2m->pages));
+    kdbp("       max_mapped_pfn:"KDBFL, ap->p2m->max_mapped_pfn);
+#if XEN_SUBVERSION > 0 && XEN_VERSION == 4              /* xen 4.1 and above */
+    kdbp("  phys_table:%p\n", ap->p2m->phys_table.pfn);
+#else
+    kdbp("  phys_table.pfn:"KDBFL"\n", ap->phys_table.pfn);
+#endif
+    kdbp("    physaddr_bitsz:%d 32bit_pv:%d has_32bit_shinfo:%d\n", 
+         ap->physaddr_bitsize, ap->is_32bit_pv, ap->has_32bit_shinfo);
+    kdb_pr_vtsc_info(ap);
+    kdbp("  sched:0x%p  &handle:0x%p\n", dp->sched_priv, &dp->handle);
+    kdbp("  vcpu ptrs:\n   ");
+    for_each_vcpu(dp, vp) {
+        kdbp(" %d:%p", vp->vcpu_id, vp);
+        if (++printed % 4 == 0) kdbp("\n   ");
+    }
+    kdbp("\n");
+}
+
+/* 
+ * FUNCTION: Dispaly (current) domain/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dom(void)
+{
+    kdbp("dom [all|domid]: Display current/all/given domain/s\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dom(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int id;
+    struct domain *dp = current->domain;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dom();
+
+    if (argc > 1) {
+        for(dp=domain_list; dp; dp=dp->next_in_list)
+            if (kdb_str2deci(argv[1], &id) && dp->domain_id==id)
+                kdb_display_dom(dp);
+            else if (!strcmp(argv[1], "all")) 
+                kdb_display_dom(dp);
+    } else {
+        kdbp("Displaying current domain :\n");
+        kdb_display_dom(dp);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dirq(void)
+{
+    kdbp("dirq : dump irq bindings\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dirq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long irq, sz, offs, addr;
+    char buf[KSYM_NAME_LEN+1];
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dirq();
+
+#if XEN_VERSION < 4 && XEN_SUBVERSION < 5           /* xen 3.4.x or below */
+    kdbp("idx/irq#/status: all are in decimal\n");
+    kdbp("idx  irq#  status   action(handler name devid)\n");
+    for (irq=0; irq < NR_VECTORS; irq++) {
+        irq_desc_t  *dp = &irq_desc[irq];
+        if (!dp->action)
+            continue;
+        addr = (unsigned long)dp->action->handler;
+        kdbp("[%3ld]:irq:%3d st:%3d f:%s devnm:%s devid:0x%p\n",
+             i, vector_to_irq(irq), dp->status, (dp->status & IRQ_GUEST) ? 
+                            "GUEST IRQ" : symbols_lookup(addr, &sz, &offs, buf),
+             dp->action->name, dp->action->dev_id);
+    }
+#else
+    kdbp("irq_desc[]:%p nr_irqs: $%d nr_irqs_gsi: $%d\n", irq_desc, nr_irqs, 
+          nr_irqs_gsi);
+    kdbp("irq/vec#/status: in decimal. affinity in hex, not bitmap\n");
+    kdbp("irq-- vec sta function----------- name---- type--------- ");
+    kdbp("aff devid------------\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        void *devidp;
+        const char *symp, *nmp;
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+
+        if (!dp->handler || dp->handler==&no_irq_type || dp->status & IRQ_GUEST)
+            continue;
+
+        addr = dp->action ? (unsigned long)dp->action->handler : 0;
+        symp = addr ? symbols_lookup(addr, &sz, &offs, buf) : "n/a ";
+        nmp = addr ? dp->action->name : "n/a ";
+        devidp = addr ? dp->action->dev_id : NULL;
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %03d %03d %-19s %-8s %-13s %3s 0x%p\n", irq, archp->vector,
+             dp->status, symp, nmp, dp->handler->typename, affstr, devidp);
+    }
+    kdb_prnt_guest_mapped_irqs();
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+kdb_prnt_vec_irq_table(int cpu)
+{
+    int i,j, *tbl = per_cpu(vector_irq, cpu);
+
+    kdbp("CPU %d : ", cpu);
+    for (i=0, j=0; i < NR_VECTORS; i++)
+        if (tbl[i] != -1) {
+            kdbp("(%3d:%3d) ", i, tbl[i]);
+            if (!(++j % 5))
+                kdbp("\n        ");
+        }
+    kdbp("\n");
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dvit(void)
+{
+    kdbp("dvit [cpu|all]: dump (per cpu)vector irq table\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvit(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu, ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvit();
+    
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all")) 
+            cpu = -1;
+        else if (!kdb_str2deci(argv[1], &cpu)) {
+            kdbp("Invalid cpu:%d\n", cpu);
+            return kdb_usgf_dvit();
+        }
+    } else
+        cpu = ccpu;
+
+    kdbp("Per CPU vector irq table pairs (vector:irq) (all decimals):\n");
+    if (cpu != -1) 
+        kdb_prnt_vec_irq_table(cpu);
+    else
+        for_each_online_cpu(cpu) 
+            kdb_prnt_vec_irq_table(cpu);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* do vmexit on all cpu's so intel VMCS can be dumped */
+static kdb_cpu_cmd_t 
+kdb_all_cpu_flush_vmcs(void)
+{
+    int cpu, ccpu = smp_processor_id();
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdb_curr_cpu_flush_vmcs();
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE){  /* hung cpu */
+                kdbp("Skipping (hung?) cpu %d\n", cpu);
+                continue;
+            }
+            kdb_cpu_cmd[cpu] = KDB_CPU_DO_VMEXIT;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_DO_VMEXIT);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display VMCS or VMCB */
+static kdb_cpu_cmd_t
+kdb_usgf_dvmc(void)
+{
+    kdbp("dvmc [domid][vcpuid] : Dump vmcs/vmcb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvmc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid = 0;  /* unsigned type don't like -1 */
+    int vcpuid = -1;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvmc();
+
+    if (argc > 1) { 
+        if (!kdb_str2domid(argv[1], &domid, 1))
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2 && !kdb_str2deci(argv[2], &vcpuid)) {
+        kdbp("Bad vcpuid: 0x%x\n", vcpuid);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        kdb_all_cpu_flush_vmcs();
+        kdb_dump_vmcs(domid, (int)vcpuid);
+    } else {
+        kdb_dump_vmcb(domid, (int)vcpuid);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_mmio(void)
+{
+    kdbp("mmio: dump mmio related info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmio(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmio();
+
+    kdbp("r/o mmio ranges:\n");
+    rangeset_printk(mmio_ro_ranges);
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump timer/timers queues */
+static kdb_cpu_cmd_t
+kdb_usgf_dtrq(void)
+{
+    kdbp("dtrq: dump timer queues on all cpus\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dtrq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dtrq();
+
+    kdb_dump_timer_queues();
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct idte {
+    uint16_t offs0_15;
+    uint16_t selector;
+    uint16_t meta;
+    uint16_t offs16_31;
+    uint32_t offs32_63;
+    uint32_t resvd;
+};
+
+#ifdef __x86_64__
+static void
+kdb_print_idte(int num, struct idte *idtp) 
+{
+    uint16_t mta = idtp->meta;
+    char dpl = ((mta & 0x6000) >> 13);
+    char present = ((mta &0x8000) >> 15);
+    int tval = ((mta &0x300) >> 8);
+    char *type = (tval == 1) ? "Task" : ((tval== 2) ? "Intr" : "Trap");
+    domid_t domid = idtp->selector==__HYPERVISOR_CS64 ? DOMID_IDLE :
+                    current->domain->domain_id;
+    uint64_t addr = idtp->offs0_15 | ((uint64_t)idtp->offs16_31 << 16) | 
+                    ((uint64_t)idtp->offs32_63 << 32);
+
+    kdbp("[%03d]: %s %x  %x %04x:%016lx ", num, type, dpl, present,
+         idtp->selector, addr); 
+    kdb_prnt_addr2sym(domid, addr, "\n");
+}
+
+/* Dump 64bit idt table currently on this cpu. Intel Vol 3 section 5.14.1 */
+static kdb_cpu_cmd_t
+kdb_usgf_didt(void)
+{
+    kdbp("didt : dump IDT table on the current cpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i;
+    struct idte *idtp = (struct idte *)idt_tables[smp_processor_id()];
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_didt();
+
+    kdbp("IDT at:%p\n", idtp);
+    kdbp("idt#  Type DPL P addr (all hex except idt#)\n", idtp);
+    for (i=0; i < 256; i++, idtp++) 
+        kdb_print_idte(i, idtp);
+    return KDB_CPU_MAIN_KDB;
+}
+#else
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbp("kdb: Please implement me in 32bit hypervisor\n");
+    return KDB_CPU_MAIN_KDB;
+}
+#endif
+
+struct gdte {             /* same for TSS and LDT */
+    ulong limit0:16;
+    ulong base0:24;       /* linear address base, not pa */
+    ulong acctype:4;      /* Type: access rights */
+    ulong S:1;            /* S: 0 = system, 1 = code/data */
+    ulong DPL:2;          /* DPL */
+    ulong P:1;            /* P: Segment Present */
+    ulong limit1:4;
+    ulong AVL:1;          /* AVL: avail for use by system software */
+    ulong L:1;            /* L: 64bit code segment */
+    ulong DB:1;           /* D/B */
+    ulong G:1;            /* G: granularity */
+    ulong base1:8;        /* linear address base, not pa */
+};
+
+union gdte_u {
+    struct gdte gdte;
+    u64 gval;
+};
+
+struct call_gdte {
+    unsigned short offs0:16;
+    unsigned short sel:16;
+    unsigned short misc0:16;
+    unsigned short offs1:16;
+};
+
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
+union sgdte_u {
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
+    u64 sgval;
+};
+
+/* return binary form of a hex in string : max 4 chars 0000 to 1111 */
+static char *kdb_ret_acctype(uint acctype)
+{
+    static char buf[16];
+    char *p = buf;
+    int i;
+
+    if (acctype > 0xf) {
+        buf[0] = buf[1] = buf[2] = buf[3] = '?';
+        buf[5] = '\n';
+        return buf;
+    }
+    for (i=0; i < 4; i++, p++, acctype=acctype>>1)
+        *p = (acctype & 0x1) ? '1' : '0';
+
+    return buf;
+}
+
+/* Display GDT table. IA-32e mode is assumded. */
+/* first display non system descriptors then display system descriptors */
+static kdb_cpu_cmd_t
+kdb_usgf_dgdt(void)
+{
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
+         "given vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dgdt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    union gdte_u u1;
+    ulong start_addr, end_addr, taddr=0;
+    domid_t domid = DOMID_IDLE;
+    int idx;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dgdt();
+
+    if (argc > 1) {
+        if (argc != 3)
+            return kdb_usgf_dgdt();
+
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
+        } else {
+            kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
+            return kdb_usgf_dgdt();
+        }
+    } else {
+        __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
+    }
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
+    kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
+         "--Base Addr ----  Limit\n");
+    kdbp("                              Type\n");
+
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+            continue;
+
+        if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
+            continue;               /* what an effin x86 mess */
+
+        idx = (taddr - start_addr) / 8;
+        if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
+            taddr += sizeof(ulong);
+            continue;
+        }
+        kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
+             u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
+             (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
+             u1.gdte.limit0 | (u1.gdte.limit1<<16));
+    }
+
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
+        uint acctype;
+        u64 upper, addr64=0;
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
+            u1.gval == 0 || u1.gdte.S == 1) {
+            continue;
+        }
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+            kdbp("Could not read upper 8 bytes of system desc\n");
+            upper = 0;
+        }
+        acctype = u1.gdte.acctype;
+        if (acctype != 2 && acctype != 9 && acctype != 11 && acctype !=12 &&
+            acctype != 14 && acctype != 15)
+            continue;
+
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
+
+        /* Vol 3A: table: 3-2  page: 3-19 */
+        if (acctype == 2) {
+            kdbp("LDT gate (0010)\n");
+        }
+        else if (acctype == 9) {
+            kdbp("TSS avail gate(1001)\n");
+        }
+        else if (acctype == 11) {
+            kdbp("TSS busy gate(1011)\n");
+        }
+        else if (acctype == 12) {
+            kdbp("CALL gate (1100)\n");
+        }
+        else if (acctype == 14) {
+            kdbp("IDT gate (1110)\n");
+        }
+        else if (acctype == 15) {
+            kdbp("Trap gate (1111)\n"); 
+        }
+
+        if (acctype == 2 || acctype == 9 || acctype == 11) {
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display scheduler basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_sched(void)
+{
+    kdbp("sched: show schedular info and run queues\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sched(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_sched();
+
+    kdb_print_sched_info();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display MMU basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_mmu(void)
+{
+    kdbp("mmu: print basic MMU info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmu();
+
+    kdbp("MMU Info:\n");
+    kdbp("total  pages: %lx\n", total_pages);
+    kdbp("max page/mfn: %lx\n", max_page);
+    kdbp("frame_table:  %p\n", frame_table);
+    kdbp("DIRECTMAP_VIRT_START:  %lx\n", DIRECTMAP_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_START: %lx\n", HYPERVISOR_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_END:   %lx\n", HYPERVISOR_VIRT_END);
+    kdbp("RO_MPT_VIRT_START:     %lx\n", RO_MPT_VIRT_START);
+    kdbp("PERDOMAIN_VIRT_START:  %lx\n", PERDOMAIN_VIRT_START);
+    kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
+    kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
+         (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
+
+    kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
+    kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
+    kdbp("LAST_RESERVED_GDT_ENTRY: %lx\n", (ulong)LAST_RESERVED_GDT_ENTRY);
+    kdbp("  Per cpu non-compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(gdt_table, cpu));
+    }
+    kdbp("  Per cpu compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
+    }
+    kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
+#ifdef USER_MAPPINGS_ARE_GLOBAL
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
+#else
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
+#endif
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* for HVM/HYB guests, go thru EPT. For PV guest we need to go to the btree. 
+ * btree: pfn_to_mfn_frame_list_list is root that points (has mfns of) upto 16
+ * pages (call 'em l2 nodes) that contain mfns of guest p2m table pages 
+ * NOTE: num of entries in a p2m page is same as num of entries in l2 node */
+static noinline ulong
+kdb_gpfn2mfn(struct domain *dp, ulong gpfn, p2m_type_t *typep) 
+{
+    int idx;
+
+    if ( !paging_mode_translate(dp) ) {
+        mfn_t *mfn_va, mfn = arch_get_pfn_to_mfn_frame_list_list(dp);
+        int g_longsz = kdb_guest_bitness(dp->domain_id)/8;
+        int entries_per_pg = PAGE_SIZE/g_longsz;
+        const int shift = get_count_order(entries_per_pg);
+
+	if ( !mfn_valid(mfn) ) {
+	    kdbp("Invalid frame_list_list mfn:%lx for non-xlate guest\n", mfn);
+	    return INVALID_MFN;
+	}
+
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn >> 2*shift;     /* index in root page/node */
+        if (idx > 15) {
+            kdbp("gpfn:%lx idx:%x not in frame list limit of z16\n", gpfn, idx);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        if (mfn==0) {
+            kdbp("No mfn for idx:%d for gpfn:%lx in root pg\n", idx, gpfn);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn_va = map_domain_page(mfn);
+        KDBGP1("p2m: idx:%x fll:%lx mfn of 2nd lvl page:%lx\n", idx,
+               arch_get_pfn_to_mfn_frame_list_list(dp), mfn);
+
+        idx = (gpfn>>shift) & ((1<<shift)-1);     /* idx in l2 node */
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+        if (mfn == 0) {
+            kdbp("No mfn entry at:%x in 2nd lvl pg for gpfn:%lx\n", idx, gpfn);
+            return INVALID_MFN;
+        }
+        KDBGP1("p2m: idx:%x  mfn of p2m page:%lx\n", idx, mfn); 
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn & ((1<<shift)-1);
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+
+	*typep = -1;
+        return mfn;
+    } else
+#if XEN_SUBVERSION > 0 
+        return get_gfn(dp, gpfn, typep);
+#else
+        return get_gfn(dp, gpfn, typep);
+#endif
+
+    return INVALID_MFN;
+}
+
+/* given a pfn, find it's mfn */
+static kdb_cpu_cmd_t
+kdb_usgf_p2m(void)
+{
+    kdbp("p2m domid 0xgpfn : gpfn to mfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_p2m(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gpfn;
+    p2m_type_t p2mtype;
+
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
+        !kdb_str2ulong(argv[2], &gpfn)) {
+
+        return kdb_usgf_p2m();
+    }
+    if ( paging_mode_translate(dp) )
+        kdbp("p2m[%lx] == %lx type:%d\n", gpfn, 
+             kdb_gpfn2mfn(dp, gpfn, &p2mtype), p2mtype);
+    else 
+        kdbp("p2m[%lx] == %lx type:N/A(PV)\n", gpfn, 
+             kdb_gpfn2mfn(dp, gpfn, &p2mtype));
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an mfn, lookup pfn in the MPT */
+static kdb_cpu_cmd_t
+kdb_usgf_m2p(void)
+{
+    kdbp("m2p 0xmfn: mfn to pfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_m2p(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    mfn_t mfn;
+    if (argc > 1 && kdb_str2ulong(argv[1], &mfn))
+        if (mfn_valid(mfn))
+            kdbp("mpt[%x] == %lx\n", mfn, machine_to_phys_mapping[mfn]);
+        else
+            kdbp("Invalid mfn:%lx\n", mfn);
+    else
+        kdb_usgf_m2p();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void 
+kdb_pr_pg_pgt_flds(unsigned long type_info)
+{
+    switch (type_info & PGT_type_mask) {
+        case (PGT_l1_page_table):
+            kdbp("    page is PGT_l1_page_table\n");
+            break;
+        case PGT_l2_page_table:
+            kdbp("    page is PGT_l2_page_table\n");
+            break;
+        case PGT_l3_page_table:
+            kdbp("    page is PGT_l3_page_table\n");
+            break;
+        case PGT_l4_page_table:
+            kdbp("    page is PGT_l4_page_table\n");
+            break;
+        case PGT_seg_desc_page:
+            kdbp("    page is seg desc page\n");
+            break;
+        case PGT_writable_page:
+            kdbp("    page is writable page\n");
+            break;
+        case PGT_shared_page:
+            kdbp("    page is shared page\n");
+            break;
+    }
+    if (type_info & PGT_pinned)
+        kdbp("    page is pinned\n");
+    if (type_info & PGT_validated)
+        kdbp("    page is validated\n");
+    if (type_info & PGT_pae_xen_l2)
+        kdbp("    page is PGT_pae_xen_l2\n");
+    if (type_info & PGT_partial)
+        kdbp("    page is PGT_partial\n");
+    if (type_info & PGT_locked)
+        kdbp("    page is PGT_locked\n");
+}
+
+static void
+kdb_pr_pg_pgc_flds(unsigned long count_info)
+{
+    if (count_info & PGC_allocated)
+        kdbp("  PGC_allocated");
+    if (count_info & PGC_xen_heap)
+        kdbp("  PGC_xen_heap");
+    if (count_info & PGC_page_table)
+        kdbp("  PGC_page_table");
+    if (count_info & PGC_broken)
+        kdbp("  PGC_broken");
+#if XEN_VERSION < 4                                 /* xen 3.x.x */
+    if (count_info & PGC_offlining)
+        kdbp("  PGC_offlining");
+    if (count_info & PGC_offlined)
+        kdbp("  PGC_offlined");
+#else
+    if (count_info & PGC_state_inuse)
+        kdbp("  PGC_inuse");
+    if (count_info & PGC_state_offlining)
+        kdbp("  PGC_state_offlining");
+    if (count_info & PGC_state_offlined)
+        kdbp("  PGC_state_offlined");
+    if (count_info & PGC_state_free)
+        kdbp("  PGC_state_free");
+#endif
+    kdbp("\n");
+}
+
+/* print struct page_info{} given ptr to it or an mfn
+ * NOTE: that given an mfn there seems no way of knowing how it's used, so
+ *       here we just print all info and let user decide what's applicable */
+static kdb_cpu_cmd_t
+kdb_usgf_dpage(void)
+{
+    kdbp("dpage mfn|page-ptr : Display struct page\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dpage(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long val;
+    struct page_info *pgp;
+    struct domain *dp;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dpage();
+
+    if ((kdb_str2ulong(argv[1], &val) == 0)      ||
+        (val <  (ulong)frame_table && !mfn_valid(val))) {
+
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdbp("Page Info:\n");
+    if (val <= (ulong)frame_table) {       /* arg is mfn */
+        pgp = mfn_to_page(val);
+        kdbp("  mfn: %lx page_info:%p\n", val, pgp);
+    } else {
+        pgp = (struct page_info *)val; /* arg is struct page{} */
+        if (pgp < frame_table || pgp >= frame_table+max_page) {
+            kdbp("Invalid page ptr. below/beyond max_page\n");
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdbp("  mfn: %lx page_info:%p\n", page_to_mfn(pgp), pgp);
+    } 
+    kdbp("  count_info: %016lx  (refcnt: %x)\n", pgp->count_info,
+         pgp->count_info & PGC_count_mask);
+#if XEN_VERSION > 3 || XEN_SUBVERSION > 3             /* xen 3.4.x or later */
+    kdb_pr_pg_pgc_flds(pgp->count_info);
+
+    kdbp("In use info:\n");
+    kdbp("  type_info:%016lx\n", pgp->u.inuse.type_info);
+    kdb_pr_pg_pgt_flds(pgp->u.inuse.type_info);
+    dp = page_get_owner(pgp);
+    kdbp("  domid:%d (pickled:%lx)\n", dp ? dp->domain_id : -1, 
+         pgp->v.inuse._domain);
+
+    kdbp("Shadow Info:\n");
+    kdbp("  type:%x pinned:%x count:%x\n", pgp->u.sh.type, pgp->u.sh.pinned,
+         pgp->u.sh.count);
+    kdbp("  back:%lx  shadow_flags:%x  next_shadow:%lx\n", pgp->v.sh.back,
+         pgp->shadow_flags, pgp->next_shadow);
+
+    kdbp("Free Info\n");
+    kdbp("  need_tlbflush:%d order:%d tlbflush_timestamp:%x\n",
+         pgp->u.free.need_tlbflush, pgp->v.free.order, 
+         pgp->tlbflush_timestamp);
+#else
+    if (pgp->count_info & PGC_allocated)            /* page allocated */
+        kdbp("  PGC_allocated");
+    if (pgp->count_info & PGC_page_table)           /* page table page */
+        kdbp("  PGC_page_table");
+    kdbp("\n");
+    kdbp("  page is %s xen heap page\n", is_xen_heap_page(pgp) ? "a":"NOT");
+    kdbp("  cacheattr:%x\n", (pgp->count_info>>PGC_cacheattr_base) & 7);
+    if (pgp->count_info & PGC_count_mask) {         /* page in use */
+        dp = pgp->u.inuse._domain;         /* pickled domain */
+        kdbp("  page is in use\n");
+        kdbp("    domid: %d  (pickled dom:%x)\n", 
+             dp ? (unpickle_domptr(dp))->domain_id : -1, dp);
+        kdbp("    type_info: %lx\n", pgp->u.inuse.type_info);
+        kdb_prt_pg_type(pgp->u.inuse.type_info);
+    } else {                                         /* page is free */
+        kdbp("  page is free\n");
+        kdbp("    order: %x\n", pgp->u.free.order);
+        kdbp("    cpumask: %lx\n", pgp->u.free.cpumask.bits);
+    }
+    kdbp("  tlbflush/shadow_flags: %lx\n", pgp->shadow_flags);
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display asked msr value */
+static kdb_cpu_cmd_t
+kdb_usgf_dmsr(void)
+{
+    kdbp("dmsr address : Display msr value\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dmsr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long addr, val;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dmsr();
+
+    if ((kdb_str2ulong(argv[1], &addr) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    rdmsrl(addr, val);
+    kdbp("msr: %lx  val:%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_cpuid(void)
+{
+    kdbp("cpuid eax : Display cpuid value returned in rax\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_cpuid(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long rax=0, rbx=0, rcx=0, rdx=0;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_cpuid();
+
+    if ((kdb_str2ulong(argv[1], &rax) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+#if 0
+    __asm__ __volatile__ (
+            /* "pushl %%rax  \n" */
+
+            "movl %0, %%rax  \n"
+            "cpuid           \n" 
+            : "=&a" (rax), "=b" (rbx), "=c" (rcx), "=d" (rdx)
+            : "0" (rax)
+            : "rax", "rbx", "rcx", "rdx", "memory");
+#endif
+    cpuid(rax, &rax, &rbx, &rcx, &rdx);
+    kdbp("rax: %016lx  rbx:%016lx rcx:%016lx rdx:%016lx\n", rax, rbx,
+         rcx, rdx);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_wept(void)
+{
+    kdbp("wept domid gfn: walk ept table for given domid and gfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_wept(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gfn;
+
+    if ((argc > 1 && *argv[1] == '?') || argc != 3)
+        return kdb_usgf_wept();
+    if ((dp=kdb_strdomid2ptr(argv[1], 1)) && kdb_str2ulong(argv[2], &gfn))
+        ept_walk_table(dp, gfn);
+    else
+        kdb_usgf_wept();
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Save symbols info for a guest, dom0 or other...
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_sym(void)
+{
+   kdbp("sym domid &kallsyms_names &kallsyms_addresses &kallsyms_num_syms\n");
+   kdbp("\t [&kallsyms_token_table] [&kallsyms_token_index]\n");
+   kdbp("\ttoken _table and _index MUST be specified for el5\n");
+   return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sym(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong namesp, addrap, nump, toktblp, tokidxp;
+    domid_t domid;
+
+    if (argc < 5) {
+        return kdb_usgf_sym();
+    }
+    toktblp = tokidxp = 0;     /* optional parameters */
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &namesp)   &&
+        kdb_str2ulong(argv[3], &addrap)   &&
+        kdb_str2ulong(argv[4], &nump)     && 
+        (argc==5 || (argc==7 && kdb_str2ulong(argv[5], &toktblp) &&
+                                kdb_str2ulong(argv[6], &tokidxp)))) {
+
+        kdb_sav_dom_syminfo(domid, namesp, addrap,nump,toktblp,tokidxp);
+    } else
+        kdb_usgf_sym();
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* mods is the dumb ass &modules. modules is struct {nxt, prev}, and not ptr */
+static void
+kdb_dump_linux_modules(domid_t domid, ulong mods, uint nxtoffs, uint nmoffs, 
+                       uint coreoffs)
+{
+    const int bufsz = 56;
+    char buf[bufsz];
+    uint64_t addr, addrval, *nxtptr, *modptr;
+    uint i, num = 8;
+
+    if (kdb_guest_bitness(domid) == 32)
+        num = 4;
+
+    /* first read modules{}.next ptr */
+    if (kdb_read_mem(mods, (kdbbyt_t *)&nxtptr, num, domid) != num) {
+        kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+        return;
+    }
+
+    KDBGP("mods:%p nxtptr:%p nmoffs:%x coreoffs:%x\n", (void *)mods, nxtptr,
+          nmoffs, coreoffs);
+
+    while ((uint64_t)nxtptr != mods) {
+
+        modptr = (uint64_t *) ((ulong)nxtptr - nxtoffs);
+
+        addr = (ulong)modptr + coreoffs;
+        if (kdb_read_mem(addr, (kdbbyt_t *)&addrval, num, domid) != num) {
+            kdbp("ERROR: Could not read mod addr at :%p\n", (void *)addr);
+            return;
+        }
+
+        KDBGP("modptr:%p addr:%p\n", modptr, (void *)addr);
+        addr = (ulong)modptr + nmoffs;
+        i=0;
+        do {
+            if (kdb_read_mem(addr, (kdbbyt_t *)&buf[i], 1, domid) != 1) {
+                kdbp("ERROR:Could not read name ch at addr:%p\n", (void *)addr);
+                return;
+            }
+            addr++;
+        } while (buf[i] && i++ < bufsz);
+        buf[bufsz-1] = '\0';
+
+        kdbp("%016lx %016lx %s\n", modptr, addrval, buf);
+
+        if (kdb_read_mem((ulong)nxtptr, (kdbbyt_t *)&nxtptr, num, domid)!=num) {
+            kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+            return;
+        }
+        KDBGP("nxtptr:%p addr:%p\n", nxtptr, (void *)addr);
+    } 
+}
+
+/* Display modules loaded in linux guest */
+static kdb_cpu_cmd_t
+kdb_usgf_mod(void)
+{
+   kdbp("mod domid &modules next-offs name-offs module_core-offs\n");
+   kdbp("\twhere next-offs: &((struct module *)0)->list.next\n");
+   kdbp("\tname-offs: &((struct module *)0)->name etc..\n");
+   kdbp("\tDisplays all loaded modules in the linux guest\n");
+   kdbp("\tEg: mod 0 ffffffff80302780 8 0x18 0x178\n");
+
+   return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_cmdf_mod(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong mods, nxtoffs, nmoffs, coreoffs;
+    domid_t domid;
+
+    if (argc < 6) {
+        return kdb_usgf_mod();
+    }
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &mods)     &&
+        kdb_str2ulong(argv[3], &nxtoffs)  &&
+        kdb_str2ulong(argv[4], &nmoffs)   &&
+        kdb_str2ulong(argv[5], &coreoffs)) {
+
+        kdbp("modptr address name\n");
+        kdb_dump_linux_modules(domid, mods, nxtoffs, nmoffs, coreoffs);
+    } else
+        kdb_usgf_mod();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* toggle kdb debug trace level */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbdbg(void)
+{
+    kdbp("kdbdbg : trace info to debug kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_kdbdbg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbdbg();
+
+    kdbdbg = (kdbdbg==3) ? 0 : (kdbdbg+1);
+    kdbp("kdbdbg set to:%d\n", kdbdbg);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_reboot(void)
+{
+    kdbp("reboot: reboot system\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_reboot(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_reboot();
+
+    machine_restart(500);
+    return KDB_CPU_MAIN_KDB;              /* not reached */
+}
+
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcon(void)
+{
+    kdbp("trcon: turn user added kdb tracing on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcon(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcon();
+
+    kdb_trcon = 1;
+    kdbp("kdb tracing is now on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcoff(void)
+{
+    kdbp("trcoff: turn user added kdb tracing off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcoff(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcoff();
+
+    kdb_trcon = 0;
+    kdbp("kdb tracing is now off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcz(void)
+{
+    kdbp("trcz : zero entire trace buffer\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcz(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcz();
+
+    kdb_trczero();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcp(void)
+{
+    kdbp("trcp : give hints to dump trace buffer via dw/dd command\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcp();
+
+    kdb_trcp();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* print some basic info, constants, etc.. */
+static kdb_cpu_cmd_t
+kdb_usgf_info(void)
+{
+    kdbp("info : display basic info, constants, etc..\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_info(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    struct cpuinfo_x86 *bcdp;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_info();
+
+    kdbp("Version: %d.%d.%s (%s@%s) %s\n", xen_major_version(), 
+         xen_minor_version(), xen_extra_version(), xen_compile_by(), 
+         xen_compile_domain(), xen_compile_date());
+    kdbp("__XEN_LATEST_INTERFACE_VERSION__ : 0x%x\n", 
+         __XEN_LATEST_INTERFACE_VERSION__);
+    kdbp("__XEN_INTERFACE_VERSION__: 0x%x\n", __XEN_INTERFACE_VERSION__);
+
+    bcdp = &boot_cpu_data;
+    kdbp("CPU: (all decimal)");
+        if (bcdp->x86_vendor == X86_VENDOR_AMD)
+            kdbp(" AMD");
+        else
+            kdbp(" INTEL");
+        kdbp(" family:%d model:%d\n", bcdp->x86, bcdp->x86_model);
+        kdbp("     vendor_id:%16s model_id:%64s\n", bcdp->x86_vendor_id,
+             bcdp->x86_model_id);
+        kdbp("     cpuidlvl:%d cache:sz:%d align:%d\n", bcdp->cpuid_level,
+             bcdp->x86_cache_size, bcdp->x86_cache_alignment);
+        kdbp("     power:%d cores: max:%d booted:%d siblings:%d apicid:%d\n",
+             bcdp->x86_power, bcdp->x86_max_cores, bcdp->booted_cores,
+             bcdp->x86_num_siblings, bcdp->apicid);
+        kdbp("     ");
+        if (cpu_has_apic)
+            kdbp("_apic");
+        if (cpu_has_sep)
+            kdbp("|_sep");
+        if (cpu_has_xmm3)
+            kdbp("|_xmm3");
+        if (cpu_has_ht)
+            kdbp("|_ht");
+        if (cpu_has_nx)
+            kdbp("|_nx");
+        if (cpu_has_clflush)
+            kdbp("|_clflush");
+        if (cpu_has_page1gb)
+            kdbp("|_page1gb");
+        if (cpu_has_ffxsr)
+            kdbp("|_ffxsr");
+        if (cpu_has_x2apic)
+            kdbp("|_x2apic");
+    kdbp("\n\n");
+    kdbp("CC:");
+#if defined(CONFIG_X86_64)
+        kdbp(" CONFIG_X86_64");
+#endif
+#if defined(CONFIG_COMPAT)
+        kdbp(" CONFIG_COMPAT");
+#endif
+#if defined(CONFIG_PAGING_ASSISTANCE)
+        kdbp(" CONFIG_PAGING_ASSISTANCE");
+#endif
+    kdbp("\n");
+    kdbp("cpu has following features:\n");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ? 
+         "X86_FEATURE_TSC_RELIABLE" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_CONSTANT_TSC)? "X86_FEATURE_CONSTANT_TSC":"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ? "X86_FEATURE_NONSTOP_TSC" :"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_RDTSCP) ?  "X86_FEATURE_RDTSCP" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_FXSR) ?  "X86_FEATURE_FXSR" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_CPUID_FAULTING) ?  
+         "X86_FEATURE_CPUID_FAULTING" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_PAGE1GB) ?  "X86_FEATURE_PAGE1GB" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_MWAIT) ?  "X86_FEATURE_MWAIT" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_X2APIC) ?  "X86_FEATURE_X2APIC":"");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_XSAVE) ?  "X86_FEATURE_XSAVE":"");
+    kdbp("\n");
+
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
+    kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
+    kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
+
+    kdbp("\nDomains and their vcpus:\n");
+    for_each_domain(dp) {
+        struct vcpu *vp;
+        int printed=0;
+        kdbp("  Domain: {id:%d 0x%x   ptr:%p%s}  VCPUs:\n", 
+             dp->domain_id, dp->domain_id, dp, dp->is_dying ? " DYING":"");
+        for(vp=dp->vcpu[0]; vp; vp = vp->next_in_list) {
+            kdbp("  {id:%d p:%p runstate:%d}", vp->vcpu_id, vp, 
+                 vp->runstate.state);
+            if (++printed % 2 == 0) kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_cur(void)
+{
+    kdbp("cur : display current domid and vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Checking for guest_mode() not feasible here. if dom0->hcall->bp in xen, 
+ * then g_m() will show xen, but vcpu is still dom0. hence just look at 
+ * current only */
+static kdb_cpu_cmd_t
+kdb_cmdf_cur(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t id = current->domain->domain_id;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cur();
+
+    kdbp("domid: %d{%p} %s vcpu:%d {%p} ", id, current->domain,
+         (id==DOMID_IDLE) ? "(IDLE)" : "", current->vcpu_id, current);
+
+    /* if (id != DOMID_IDLE) { */
+        if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+            u64 addr = -1;
+            __vmptrst(&addr);
+            kdbp(" VMCS:"KDBFL, addr);
+        }
+    /* } */
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* stub to quickly and easily add a new command */
+static kdb_cpu_cmd_t
+kdb_usgf_usr1(void)
+{
+    kdbp("usr1: add any arbitrary cmd using this in kdb_cmds.c\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_usr1(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_h(void)
+{
+    kdbp("h: display all commands. See kdb/README for more info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_h(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbtab_t *tbp;
+
+    kdbp(" - ccpu is current cpu \n");
+    kdbp(" - following are always in decimal:\n");
+    kdbp("     vcpu num, cpu num, domid\n");
+    kdbp(" - otherwise, almost all numbers are in hex (0x not needed)\n");
+    kdbp(" - output: $17 means decimal 17\n");
+    kdbp(" - domid 7fff($32767) refers to hypervisor\n");
+    kdbp(" - if no domid before function name, then it's hypervisor\n");
+    kdbp(" - earlykdb in xen grub line to break into kdb during boot\n");
+    kdbp(" - command ? will show the command usage\n");
+    kdbp("\n");
+
+    for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_usgf; tbp++)
+        (*tbp->kdb_cmd_usgf)();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ===================== cmd table initialization ========================== */
+void __init
+kdb_init_cmdtab(void)
+{
+  static kdbtab_t _kdb_cmd_table[] = {
+
+    {"info", kdb_cmdf_info, kdb_usgf_info, 1, KDB_REPEAT_NONE},
+    {"cur",  kdb_cmdf_cur, kdb_usgf_cur, 1, KDB_REPEAT_NONE},
+
+    {"f",  kdb_cmdf_f,  kdb_usgf_f,  1, KDB_REPEAT_NONE},
+    {"fg", kdb_cmdf_fg, kdb_usgf_fg, 1, KDB_REPEAT_NONE},
+
+    {"dw",  kdb_cmdf_dw,  kdb_usgf_dw,  1, KDB_REPEAT_NO_ARGS},
+    {"dd",  kdb_cmdf_dd,  kdb_usgf_dd,  1, KDB_REPEAT_NO_ARGS},
+    {"dwm", kdb_cmdf_dwm, kdb_usgf_dwm, 1, KDB_REPEAT_NO_ARGS},
+    {"ddm", kdb_cmdf_ddm, kdb_usgf_ddm, 1, KDB_REPEAT_NO_ARGS},
+    {"dr",  kdb_cmdf_dr,  kdb_usgf_dr,  1, KDB_REPEAT_NONE},
+    {"drg", kdb_cmdf_drg, kdb_usgf_drg, 1, KDB_REPEAT_NONE},
+
+    {"dis", kdb_cmdf_dis,  kdb_usgf_dis,  1, KDB_REPEAT_NO_ARGS},
+    {"dism",kdb_cmdf_dism, kdb_usgf_dism, 1, KDB_REPEAT_NO_ARGS},
+
+    {"mw", kdb_cmdf_mw, kdb_usgf_mw, 1, KDB_REPEAT_NONE},
+    {"md", kdb_cmdf_md, kdb_usgf_md, 1, KDB_REPEAT_NONE},
+    {"mr", kdb_cmdf_mr, kdb_usgf_mr, 1, KDB_REPEAT_NONE},
+
+    {"bc", kdb_cmdf_bc, kdb_usgf_bc, 0, KDB_REPEAT_NONE},
+    {"bp", kdb_cmdf_bp, kdb_usgf_bp, 1, KDB_REPEAT_NONE},
+    {"btp", kdb_cmdf_btp, kdb_usgf_btp, 1, KDB_REPEAT_NONE},
+
+    {"wp", kdb_cmdf_wp, kdb_usgf_wp, 1, KDB_REPEAT_NONE},
+    {"wc", kdb_cmdf_wc, kdb_usgf_wc, 0, KDB_REPEAT_NONE},
+
+    {"ni", kdb_cmdf_ni, kdb_usgf_ni, 0, KDB_REPEAT_NO_ARGS},
+    {"ss", kdb_cmdf_ss, kdb_usgf_ss, 1, KDB_REPEAT_NO_ARGS},
+    {"ssb",kdb_cmdf_ssb,kdb_usgf_ssb,0, KDB_REPEAT_NO_ARGS},
+    {"go", kdb_cmdf_go, kdb_usgf_go, 0, KDB_REPEAT_NONE},
+
+    {"cpu",kdb_cmdf_cpu, kdb_usgf_cpu, 1, KDB_REPEAT_NONE},
+    {"nmi",kdb_cmdf_nmi, kdb_usgf_nmi, 1, KDB_REPEAT_NONE},
+    {"percpu",kdb_cmdf_percpu, kdb_usgf_percpu, 1, KDB_REPEAT_NONE},
+
+    {"sym",  kdb_cmdf_sym,   kdb_usgf_sym,   1, KDB_REPEAT_NONE},
+    {"mod",  kdb_cmdf_mod,   kdb_usgf_mod,   1, KDB_REPEAT_NONE},
+
+    {"vcpuh",kdb_cmdf_vcpuh, kdb_usgf_vcpuh, 1, KDB_REPEAT_NONE},
+    {"vcpu", kdb_cmdf_vcpu,  kdb_usgf_vcpu,  1, KDB_REPEAT_NONE},
+    {"dom",  kdb_cmdf_dom,   kdb_usgf_dom,   1, KDB_REPEAT_NONE},
+
+    {"sched", kdb_cmdf_sched, kdb_usgf_sched, 1, KDB_REPEAT_NONE},
+    {"mmu",   kdb_cmdf_mmu,   kdb_usgf_mmu,   1, KDB_REPEAT_NONE},
+    {"p2m",   kdb_cmdf_p2m,   kdb_usgf_p2m,   1, KDB_REPEAT_NONE},
+    {"m2p",   kdb_cmdf_m2p,   kdb_usgf_m2p,   1, KDB_REPEAT_NONE},
+    {"dpage", kdb_cmdf_dpage, kdb_usgf_dpage, 1, KDB_REPEAT_NONE},
+    {"dmsr",  kdb_cmdf_dmsr,  kdb_usgf_dmsr, 1, KDB_REPEAT_NONE},
+    {"cpuid",  kdb_cmdf_cpuid,  kdb_usgf_cpuid, 1, KDB_REPEAT_NONE},
+    {"wept",  kdb_cmdf_wept,  kdb_usgf_wept, 1, KDB_REPEAT_NONE},
+
+    {"dtrq", kdb_cmdf_dtrq,  kdb_usgf_dtrq, 1, KDB_REPEAT_NONE},
+    {"didt", kdb_cmdf_didt,  kdb_usgf_didt, 1, KDB_REPEAT_NONE},
+    {"dgdt", kdb_cmdf_dgdt,  kdb_usgf_dgdt, 1, KDB_REPEAT_NONE},
+    {"dirq", kdb_cmdf_dirq,  kdb_usgf_dirq, 1, KDB_REPEAT_NONE},
+    {"dvit", kdb_cmdf_dvit,  kdb_usgf_dvit, 1, KDB_REPEAT_NONE},
+    {"dvmc", kdb_cmdf_dvmc,  kdb_usgf_dvmc, 1, KDB_REPEAT_NONE},
+    {"mmio", kdb_cmdf_mmio,  kdb_usgf_mmio, 1, KDB_REPEAT_NONE},
+
+    /* tracing related commands */
+    {"trcon", kdb_cmdf_trcon,  kdb_usgf_trcon,  0, KDB_REPEAT_NONE},
+    {"trcoff",kdb_cmdf_trcoff, kdb_usgf_trcoff, 0, KDB_REPEAT_NONE},
+    {"trcz",  kdb_cmdf_trcz,   kdb_usgf_trcz,   0, KDB_REPEAT_NONE},
+    {"trcp",  kdb_cmdf_trcp,   kdb_usgf_trcp,   1, KDB_REPEAT_NONE},
+
+    {"usr1",  kdb_cmdf_usr1,   kdb_usgf_usr1,   1, KDB_REPEAT_NONE},
+    {"kdbf",  kdb_cmdf_kdbf,   kdb_usgf_kdbf,   1, KDB_REPEAT_NONE},
+    {"kdbdbg",kdb_cmdf_kdbdbg, kdb_usgf_kdbdbg, 1, KDB_REPEAT_NONE},
+    {"reboot",kdb_cmdf_reboot, kdb_usgf_reboot, 1, KDB_REPEAT_NONE},
+    {"h",     kdb_cmdf_h,      kdb_usgf_h,      1, KDB_REPEAT_NONE},
+
+    {"", NULL, NULL, 0, 0},
+  };
+    kdb_cmd_tbl = _kdb_cmd_table;
+    return;
+}
diff -r 54c8c9eaee92 xen/kdb/kdb_io.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_io.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+#include "include/kdbinc.h"
+
+#define K_BACKSPACE  0x8                   /* ctrl-H */
+#define K_BACKSPACE1 0x7f                  /* ctrl-? */
+#define K_UNDERSCORE 0x5f
+#define K_CMD_BUFSZ  160
+#define K_CMD_MAXI   (K_CMD_BUFSZ - 1)     /* max index in buffer */
+
+#if 0        /* make a history array some day */
+#define K_UP_ARROW                         /* sequence : 1b 5b 41 ie, '\e[A' */
+#define K_DN_ARROW                         /* sequence : 1b 5b 42 ie, '\e[B' */
+#define K_NUM_HIST   32
+static int cursor;
+static char cmds_a[NUM_HIST][K_CMD_BUFSZ];
+#endif
+
+static char cmds_a[K_CMD_BUFSZ];
+
+
+static int
+kdb_key_valid(int key)
+{
+    /* note: isspace() is more than ' ', hence we don't use it here */
+    if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
+            return 1;
+    return 0;
+}
+
+/* display kdb prompt and read command from the console 
+ * RETURNS: a '\n' terminated command buffer */
+char *
+kdb_get_cmdline(char *prompt)
+{
+    #define K_BELL     0x7
+    #define K_CTRL_C   0x3
+
+    int key, i=0;
+
+    kdbp(prompt);
+    memset(cmds_a, 0, K_CMD_BUFSZ);
+    cmds_a[K_CMD_BUFSZ-1] = '\n';
+
+    do {
+        key = console_getc();
+        if (key == '\r') 
+            key = '\n';
+        if (key == K_BACKSPACE1) 
+            key = K_BACKSPACE;
+
+        if (key == K_CTRL_C || (i==K_CMD_MAXI && key != '\n')) {
+            console_putc('\n');
+            if (i >= K_CMD_MAXI) {
+                kdbp("KDB: cmd buffer overflow\n");
+                console_putc(K_BELL);
+            }
+            memset(cmds_a, 0, K_CMD_BUFSZ);
+            i = 0;
+            kdbp(prompt);
+            continue;
+        }
+        if (!kdb_key_valid(key)) {
+            console_putc(K_BELL);
+            continue;
+        }
+        if (key == K_BACKSPACE) {
+            if (i==0) {
+                console_putc(K_BELL);
+                continue;
+            } else 
+                cmds_a[--i] = '\0';
+                console_putc(K_BACKSPACE);
+                console_putc(' ');        /* erase character */
+        } else
+            cmds_a[i++] = key;
+
+        console_putc(key);
+
+    } while (key != '\n');
+
+    return cmds_a;
+}
+
+/*
+ * printk takes a lock, an NMI could come in after that, and another cpu may 
+ * spin. also, the console lock is forced unlock, so panic is been seen on 
+ * 8 way. hence, no printk() calls.
+ */
+static volatile int kdbp_gate = 0;
+void
+kdbp(const char *fmt, ...)
+{
+    static char buf[1024];
+    va_list args;
+    char *p;
+    int i=0;
+
+    while ((__cmpxchg(&kdbp_gate, 0,1, sizeof(kdbp_gate)) != 0) && i++<1000)
+        mdelay(10);
+
+    va_start(args, fmt);
+    (void)vsnprintf(buf, sizeof(buf), fmt, args);
+    va_end(args);
+
+    for (p=buf; *p != '\0'; p++)
+        console_putc(*p);
+    kdbp_gate = 0;
+}
+
+
+/*
+ * copy/read machine memory. 
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mmem(kdbma_t maddr, kdbbyt_t *dbuf, int len)
+{
+    ulong remain, orig=len;
+
+    while (len > 0) {
+        ulong pagecnt = min_t(long, PAGE_SIZE-(maddr&~PAGE_MASK), len);
+        char *va = map_domain_page(maddr >> PAGE_SHIFT);
+
+        va = va + (maddr & (PAGE_SIZE-1));        /* add page offset */
+        remain = __copy_from_user(dbuf, (void *)va, pagecnt);
+        KDBGP1("maddr:%x va:%p len:%x pagecnt:%x rem:%x\n", 
+               maddr, va, len, pagecnt, remain);
+        unmap_domain_page(va);
+        len = len  - (pagecnt - remain);
+        if (remain != 0)
+            break;
+        maddr += pagecnt;
+        dbuf += pagecnt;
+    }
+    return orig - len;
+}
+
+
+/*
+ * copy/read guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mem(kdbva_t saddr, kdbbyt_t *dbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(saddr, dbuf, len, domid, 0, 0));
+}
+
+/*
+ * write guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes written
+ */
+int
+kdb_write_mem(kdbva_t daddr, kdbbyt_t *sbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(daddr, sbuf, len, domid, 1, 0));
+}
diff -r 54c8c9eaee92 xen/kdb/kdbmain.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdbmain.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+static int kdbmain(kdb_reason_t, struct cpu_user_regs *);
+static int kdbmain_fatal(struct cpu_user_regs *, int);
+static const char *kdb_gettrapname(int);
+
+/* ======================== GLOBAL VARIABLES =============================== */
+/* All global variables used by KDB must be defined here only. Module specific
+ * static variables must be declared in respective modules.
+ */
+kdbtab_t *kdb_cmd_tbl;
+char kdb_prompt[32];
+
+volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+cpumask_t kdb_cpu_traps;           /* bit per cpu to tell which cpus hit int3 */
+
+#ifndef NDEBUG
+    #error KDB is not supported on debug xen. Turn debug off
+#endif
+
+volatile int kdb_init_cpu = -1;           /* initial kdb cpu */
+volatile int kdb_session_begun = 0;       /* active kdb session? */
+volatile int kdb_enabled = 1;             /* kdb enabled currently? */
+volatile int kdb_sys_crash = 0;           /* are we in crashed state? */
+volatile int kdbdbg = 0;                  /* to debug kdb itself */
+
+static volatile int kdb_trap_immed_reason = 0;   /* reason for immed trap */
+
+static cpumask_t kdb_fatal_cpumask;       /* which cpus in fatal path */
+
+/* return index of first bit set in val. if val is 0, retval is undefined */
+static inline unsigned int kdb_firstbit(unsigned long val)
+{
+    __asm__ ( "bsf %1,%0" : "=r" (val) : "r" (val), "0" (BITS_PER_LONG) );
+    return (unsigned int)val;
+}
+
+void noinline mukchk(unsigned long ul)
+{
+}
+
+static void 
+kdb_dbg_prnt_ctrps(char *label, int ccpu)
+{
+    int i;
+    if (!kdbdbg)
+        return;
+
+    if (label || *label)
+        kdbp("%s ", label);
+    if (ccpu != -1)
+        kdbp("ccpu:%d ", ccpu);
+    kdbp("cputrps:");
+    for (i=sizeof(kdb_cpu_traps)/sizeof(kdb_cpu_traps.bits[0]) - 1; i >=0; i--)
+        kdbp(" %lx", kdb_cpu_traps.bits[i]);
+    kdbp("\n");
+}
+
+/* 
+ * Hold this cpu. Don't disable until all CPUs in kdb to avoid IPI deadlock 
+ */
+static void
+kdb_hold_this_cpu(int ccpu, struct cpu_user_regs *regs)
+{
+    KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+    do {
+        for(; kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE; cpu_relax());
+        KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DISABLE) {
+            local_irq_disable();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DO_VMEXIT) {
+            kdb_curr_cpu_flush_vmcs();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_SHOWPC) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+    } while (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE);     /* No goto, eh! */
+    KDBGP1("un hold: ccpu:%d cmd:%d\n", ccpu, kdb_cpu_cmd[ccpu]);
+}
+
+/*
+ * Pause this cpu while one CPU does main kdb processing. If that CPU does
+ * a "cpu switch" to this cpu, this cpu will become the main kdb cpu. If the
+ * user next does single step of some sort, this function will be exited,
+ * and this cpu will come back into kdb via kdb_handle_trap_entry function.
+ */
+static void 
+kdb_pause_this_cpu(struct cpu_user_regs *regs, void *unused)
+{
+    kdbmain(KDB_REASON_PAUSE_IPI, regs);
+}
+
+/* pause other cpus via an IPI. Note, disabled CPUs can't receive IPIs until
+ * enabled */
+static void
+kdb_smp_pause_cpus(void)
+{
+    int cpu, wait_count = 0;
+    int ccpu = smp_processor_id();      /* current cpu */
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL) {
+            kdbp("KDB: won't pause cpu:%d, cmd[cpu]=%d\n",cpu,kdb_cpu_cmd[cpu]);
+            cpumask_clear_cpu(cpu, &cpumask);
+        }
+    KDBGP("ccpu:%d will pause cpus. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    on_selected_cpus(&cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0);
+#else
+    on_selected_cpus(cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0, 0);
+#endif
+    mdelay(300);                     /* wait a bit for other CPUs to stop */
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+                bummer = 1;
+        if (!bummer)
+            break;
+        kdbp("ccpu:%d trying to stop other cpus...\n", ccpu);
+        mdelay(100);  /* wait 100 ms */
+    };
+    for_each_cpu(cpu, &cpumask)          /* now check who is with us */
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+            kdbp("Bummer cpu %d not paused. ccpu:%d\n", cpu,ccpu);
+        else {
+            kdb_cpu_cmd[cpu] = KDB_CPU_DISABLE;  /* tell it to disable ints */
+            while (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE);
+        }
+}
+
+/* 
+ * Do once per kdb session:  A kdb session lasts from 
+ *    keybord/HWBP/SWBP till KDB_CPU_INSTALL_BP is done. Within a session,
+ *    user may do several cpu switches, single step, next instr,  etc..
+ *
+ * DO: 1. pause other cpus if they are not already. they would already be 
+ *        if we are in single step mode
+ *     2. watchdog_disable() 
+ *     3. uninstall all sw breakpoints so that user doesn't see them
+ */
+static void
+kdb_begin_session(void)
+{
+    if (!kdb_session_begun) {
+        kdb_session_begun = 1;
+        kdb_smp_pause_cpus();
+        local_irq_disable();
+        watchdog_disable();
+        kdb_uninstall_all_swbp();
+    }
+}
+
+int noinline mukid(void)
+{
+    return smp_processor_id();
+}
+
+static void
+kdb_smp_unpause_cpus(int ccpu)
+{
+    int cpu;
+
+    int wait_count = 0;
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+
+    KDBGP("kdb_smp_unpause_other_cpus(). ccpu:%d\n", ccpu);
+    for_each_cpu(cpu, &cpumask)
+        kdb_cpu_cmd[cpu] = KDB_CPU_QUIT;
+
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+                bummer = 1;
+            if (!bummer)
+                break;
+            mdelay(90);  /* wait 90 ms, 50 too short on large systems */
+    };
+    /* now make sure they are all in there */
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+            kdbp("KDB: cpu %d still paused (cmd==%d). ccpu:%d\n",
+                 cpu, kdb_cpu_cmd[cpu], ccpu);
+}
+
+/*
+ * End of KDB session. 
+ *   This is called at the very end. In case of multiple cpus hitting BPs
+ *   and sitting on a trap handlers, the last cpu to exit will call this.
+ *   - isnstall all sw breakpoints, and purge deleted ones from table.
+ *   - clear TF here also in case go is entered on a different cpu after switch
+ */
+static void
+kdb_end_session(int ccpu, struct cpu_user_regs *regs)
+{
+    ASSERT(!cpumask_empty(&kdb_cpu_traps));
+    ASSERT(kdb_session_begun);
+    kdb_install_all_swbp();
+    kdb_flush_swbp_table();
+    kdb_install_watchpoints();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    kdb_time_resume(1);
+    kdb_session_begun = 0;      /* before unpause for kdb_install_watchpoints */
+    kdb_smp_unpause_cpus(ccpu);
+    watchdog_enable();
+    KDBGP("end_session:ccpu:%d\n", ccpu);
+}
+volatile int mukwpprnt;
+unsigned long mukaddr1 = 0xffffffff81243ae7, mukaddr2 = 0xffffffff8100986e;
+/* 
+ * check if we entered kdb because of DB trap. If yes, then check if
+ * we caused it or someone else.
+ * RETURNS: 0 : not one of ours. hypervisor must handle it. 
+ *          1 : #DB for delayed sw bp install. 
+ *          2 : this cpu must stay in kdb.
+ */
+static noinline int
+kdb_check_dbtrap(kdb_reason_t *reasp, int ss_mode, struct cpu_user_regs *regs) 
+{
+    int rc = 2;
+    int ccpu = smp_processor_id();
+
+    /* DB excp caused by hw breakpoint or the TF flag. The TF flag is set
+     * by us for ss mode or to install breakpoints. In ss mode, none of the
+     * breakpoints are installed. Check to make sure we intended BP INSTALL
+     * so we don't do it on a spurious DB trap.
+     * check for kdb_cpu_traps here also, because each cpu sitting on a trap
+     * must execute the instruction without the BP before passing control
+     * to next cpu in kdb_cpu_traps.
+     */
+    if (*reasp == KDB_REASON_DBEXCP && !ss_mode) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP) {
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                *reasp = KDB_REASON_PAUSE_IPI;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
+                kdb_init_cpu = -1;
+            } else {
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            }
+        } else if (! kdb_check_watchpoints(regs)) {
+            rc = 0;                        /* hyp must handle it */
+        } else {
+            if (regs->rip==mukaddr1 || regs->rip==mukaddr2)
+            {
+                if (mukwpprnt)
+                    kdbp("MUK: ignoring wp:%lx\n", regs->rip);
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            } 
+        }
+    }
+    return rc;
+}
+
+/* 
+ * Misc processing on kdb entry like displaying PC, adjust IP for sw bp.... 
+ */
+static void
+kdb_main_entry_misc(kdb_reason_t reason, struct cpu_user_regs *regs, 
+                    int ccpu, int ss_mode, int enabled)
+{
+    if (reason == KDB_REASON_KEYBOARD)
+        kdbp("\nEnter kdb (cpu:%d reason:%d vcpu=%d domid:%d"
+             " eflg:0x%lx irqs:%d)\n", ccpu, reason, current->vcpu_id, 
+             current->domain->domain_id, regs->eflags, enabled);
+    else if (ss_mode)
+        KDBGP1("KDBG: KDB single step mode. ccpu:%d\n", ccpu);
+
+    if (reason == KDB_REASON_BPEXCP && !ss_mode) 
+        kdbp("Breakpoint on cpu %d at 0x%lx\n", ccpu, regs->KDBIP);
+
+    /* display the current PC and instruction at it */
+    if (reason != KDB_REASON_PAUSE_IPI)
+        kdb_display_pc(regs);
+    console_start_sync();
+}
+
+/* 
+ * The MAIN kdb function. All cpus go thru this. IRQ is enabled on entry because
+ * a cpu could hit a bp set in disabled code.
+ * IPI: Even the main cpu must enable in case another CPU is trying to IPI us.
+ *      That way, it would IPI us, then get out and be ready for our pause IPI.
+ * IRQs: The reason irqs enable/disable is scattered is because on a typical
+ *       system IPIs are constantly going on amongs CPUs in a set of any size. 
+ *       As a result,  to avoid deadlock, cpus have to loop enabled, until a 
+ *       quorum is established and the session has begun.
+ * Step: Intel Vol3B 18.3.1.4 : An external interrupt may be serviced upon
+ *       single step. Since, the likely ext timer_interrupt and 
+ *       apic_timer_interrupt dont' mess with time data structs, we are prob OK
+ *       leaving enabled.
+ * Time: Very messy. Most platform timers are readonly, so we can't stop time
+ *       in the debugger. We take the only resort, let the TSC and plt run as
+ *       normal, upon leaving, "attempt" to bring everybody to current time.
+ * kdbcputraps: bit per cpu. each cpu sets it bit in entry.S. The bit is 
+ *              reliable because upon traps, Ints are disabled. the bit is set
+ *              before Ints are enabled.
+ *
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+static int
+kdbmain(kdb_reason_t reason, struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();                /* current cpu */
+    int rc = 1, cmd = kdb_cpu_cmd[ccpu];
+    int ss_mode = (cmd == KDB_CPU_SS || cmd == KDB_CPU_NI);
+    int delayed_install = (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP);
+    int enabled = local_irq_is_enabled();
+
+    KDBGP("kdbmain:ccpu:%d rsn:%d eflgs:0x%lx cmd:%d initc:%d irqs:%d "
+          "regs:%lx IP:%lx ", ccpu, reason, regs->eflags, cmd, 
+          kdb_init_cpu, enabled, regs, regs->KDBIP);
+    kdb_dbg_prnt_ctrps("", -1);
+
+    if (!ss_mode && !delayed_install)    /* initial kdb enter */
+        local_irq_enable();              /* so we can receive IPI */
+
+    if (!ss_mode && ccpu != kdb_init_cpu && reason != KDB_REASON_PAUSE_IPI){
+        int sz = sizeof(kdb_init_cpu);
+        while (__cmpxchg(&kdb_init_cpu, -1, ccpu, sz) != -1)
+            for(; kdb_init_cpu != -1; cpu_relax());
+    }
+    if (kdb_session_begun)
+        local_irq_disable();             /* kdb always runs disabled */
+
+    if (reason == KDB_REASON_BPEXCP) {             /* INT 3 */
+        cpumask_clear_cpu(ccpu, &kdb_cpu_traps);   /* remove ourself */
+        rc = kdb_check_sw_bkpts(regs);
+        if (rc == 0) {               /* not one of ours. leave kdb */
+            kdb_init_cpu = -1;
+            goto out;
+        } else if (rc == 1) {        /* one of ours but deleted */
+            if (cpumask_empty(&kdb_cpu_traps)) {
+                kdb_end_session(ccpu,regs);     
+                kdb_init_cpu = -1;
+                goto out;
+            } else {                 
+                /* release another trap cpu, and put ourself in a pause mode */
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d cmd:%d rsn:%d atrpcpu:%d initcpu:%d\n", ccpu, 
+                      kdb_cpu_cmd[ccpu], reason, a_trap_cpu, kdb_init_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                reason = KDB_REASON_PAUSE_IPI;
+                kdb_init_cpu = -1;
+            }
+        } else if (rc == 2) {        /* one of ours but condition not met */
+                kdb_begin_session();
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+        }
+    }
+
+    /* following will take care of KDB_CPU_INSTALL_BP, and also release
+     * kdb_init_cpu. it should not be done twice */
+    if ((rc=kdb_check_dbtrap(&reason, ss_mode, regs)) == 0 || rc == 1) {
+        kdb_init_cpu = -1;       /* leaving kdb */
+        goto out;                /* rc properly set to 0 or 1 */
+    }
+    if (reason != KDB_REASON_PAUSE_IPI) {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+    } else
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB && !ss_mode)
+        kdb_begin_session(); 
+
+    kdb_main_entry_misc(reason, regs, ccpu, ss_mode, enabled);
+    /* note, one or more cpu switches may occur in between */
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+            if (ccpu != kdb_init_cpu) {
+                kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_GO;
+                kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+                continue;               /* for the pause guy */
+            }
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                /* execute current instruction without 0xcc */
+                kdb_dbg_prnt_ctrps("nempty:", ccpu);
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            }
+        }
+        if (kdb_cpu_cmd[ccpu] != KDB_CPU_PAUSE  && 
+            kdb_cpu_cmd[ccpu] != KDB_CPU_MAIN_KDB)
+                break;
+    }
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+        ASSERT(cpumask_empty(&kdb_cpu_traps));
+        if (kdb_swbp_exists()) {
+            if (reason == KDB_REASON_BPEXCP) {
+                /* do delayed install */
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            } 
+        }
+        kdb_end_session(ccpu, regs);
+        kdb_init_cpu = -1;
+    }
+out:
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_QUIT) {
+        KDBGP("ccpu:%d _quit IP: %lx\n", ccpu, regs->KDBIP);
+        if (! kdb_session_begun)
+            kdb_install_watchpoints();
+        kdb_time_resume(0);
+        kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    }
+
+    /* for ss and delayed install, TF is set. not much in EXT INT handlers*/
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_NI)
+        kdb_time_resume(1);
+    if (enabled)
+        local_irq_enable();
+
+    KDBGP("kdbmain:X:ccpu:%d rc:%d cmd:%d eflg:0x%lx initc:%d sesn:%d " 
+          "cs:%x irqs:%d ", ccpu, rc, kdb_cpu_cmd[ccpu], regs->eflags, 
+          kdb_init_cpu, kdb_session_begun, regs->cs, local_irq_is_enabled());
+    kdb_dbg_prnt_ctrps("", -1);
+    return (rc ? 1 : 0);
+}
+
+/* 
+ * kdb entry function when coming in via a keyboard
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+int
+kdb_keyboard(struct cpu_user_regs *regs)
+{
+    return kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+
+#if 0
+/*
+ * this function called when kdb session active and user presses ctrl\ again.
+ * the assumption is that the user typed ni/ss cmd, and it never got back into
+ * kdb, or the user is impatient. Either case, we just fake it that the SS did
+ * finish. Since, all other kdb cpus must be holding disabled, the interrupt
+ * would be on the CPU that did the ss/ni cmd
+ */
+void
+kdb_ssni_reenter(struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();
+    int ccmd = kdb_cpu_cmd[ccpu];
+
+    if(ccmd == KDB_CPU_SS || ccmd == KDB_CPU_INSTALL_BP)
+        kdbmain(KDB_REASON_DBEXCP, regs); 
+    else 
+        kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+#endif
+
+/* 
+ * All traps are routed thru here. We care about BP (#3) trap (INT 3) and
+ * the DB trap(#1) only. 
+ * returns: 0 kdb has nothing do with this trap
+ *          1 kdb handled this trap 
+ */
+int
+kdb_handle_trap_entry(int vector, struct cpu_user_regs *regs)
+{
+    int rc = 0;
+    int ccpu = smp_processor_id();
+
+    if (vector == TRAP_int3) {
+        rc = kdbmain(KDB_REASON_BPEXCP, regs);
+
+    } else if (vector == TRAP_debug) {
+        KDBGP("ccpu:%d trapdbg reas:%d\n", ccpu, kdb_trap_immed_reason);
+
+        if (kdb_trap_immed_reason == KDB_TRAP_FATAL) { 
+            KDBGP("kdbtrp:fatal ccpu:%d vec:%d\n", ccpu, vector);
+            rc = kdbmain_fatal(regs, vector);
+            BUG();                             /* no return */
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_KDBSTACK) {
+            kdb_trap_immed_reason = 0;         /* show kdb stack */
+            show_registers(regs);
+            show_stack(regs);
+            regs->eflags &= ~X86_EFLAGS_TF;
+            rc = 1;
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_NONFATAL) {
+            kdb_trap_immed_reason = 0;
+            rc = kdb_keyboard(regs);
+        } else {                         /* ss/ni/delayed install... */
+            if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                current->arch.hvm_vcpu.single_step = 0;
+            rc = kdbmain(KDB_REASON_DBEXCP, regs); 
+        }
+
+    } else if (vector == TRAP_nmi) {                   /* external nmi */
+        /* when nmi is pressed, it could go to one or more or all cpus
+         * depending on the hardware. Also, for now assume it's fatal */
+        KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
+        rc = kdbmain_fatal(regs, TRAP_nmi);
+    } 
+    return rc;
+}
+
+int
+kdb_trap_fatal(int vector, struct cpu_user_regs *regs)
+{
+    kdbmain_fatal(regs, vector);
+    return 0;
+}
+
+/* From smp_send_nmi_allbutself() in crash.c which is static */
+void
+kdb_nmi_pause_cpus(cpumask_t cpumask)
+{
+    int ccpu = smp_processor_id();
+    mdelay(200);
+    cpumask_complement(&cpumask, &cpumask);              /* flip bit map */
+    cpumask_and(&cpumask, &cpumask, &cpu_online_map);    /* remove extra bits */
+    cpumask_clear_cpu(ccpu, &cpumask);/* absolutely make sure we're not on it */
+
+    KDBGP("ccpu:%d nmi pause. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+    if ( !cpumask_empty(&cpumask) )
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+        send_IPI_mask(&cpumask, APIC_DM_NMI);
+#else
+        send_IPI_mask(cpumask, APIC_DM_NMI);
+#endif
+    mdelay(200);
+    KDBGP("ccpu:%d nmi pause done...\n", ccpu);
+}
+
+/* 
+ * Separate function from kdbmain to keep both within sanity levels.
+ */
+DEFINE_SPINLOCK(kdb_fatal_lk);
+static int
+kdbmain_fatal(struct cpu_user_regs *regs, int vector)
+{
+    int ccpu = smp_processor_id();
+
+    console_start_sync();
+
+    KDBGP("mainf:ccpu:%d vec:%d irq:%d\n", ccpu, vector,local_irq_is_enabled());
+    cpumask_set_cpu(ccpu, &kdb_fatal_cpumask);        /* uses LOCK_PREFIX */
+
+    if (spin_trylock(&kdb_fatal_lk)) {
+
+        kdbp("*** kdb (Fatal Error on cpu:%d vec:%d %s):\n", ccpu,
+             vector, kdb_gettrapname(vector));
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+        kdb_display_pc(regs);
+
+        watchdog_disable();     /* important */
+        kdb_sys_crash = 1;
+        kdb_session_begun = 0;  /* incase session already active */
+        local_irq_enable();
+        kdb_nmi_pause_cpus(kdb_fatal_cpumask);
+
+        kdb_clear_prev_cmd();   /* buffered CRs will repeat prev cmd */
+        kdb_session_begun = 1;  /* for kdb_hold_this_cpu() */
+        local_irq_disable();
+    } else {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+    }
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+#if 0
+        /* dump is the only way to exit in crashed state */
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DUMP)
+            kdb_do_dump(regs);
+#endif
+    }
+    return 0;
+}
+
+/* Mostly called in fatal cases. earlykdb calls non-fatal.
+ * kdb_trap_immed_reason is global, so allow only one cpu at a time. Also,
+ * multiple cpu may be crashing at the same time. We enable because if there
+ * is a bad hang, at least ctrl-\ will break into kdb. Also, we don't call
+ * call kdb_keyboard directly becaue we don't have the register context.
+ */
+DEFINE_SPINLOCK(kdb_immed_lk);
+void
+kdb_trap_immed(int reason)            /* fatal, non-fatal, kdb stack etc... */
+{
+    int ccpu = smp_processor_id();
+    int disabled = !local_irq_is_enabled();
+
+    KDBGP("trapimm:ccpu:%d reas:%d\n", ccpu, reason);
+    local_irq_enable();
+    spin_lock(&kdb_immed_lk);
+    kdb_trap_immed_reason = reason;
+    barrier();
+    __asm__ __volatile__ ( "int $1" );
+    kdb_trap_immed_reason = 0;
+
+    spin_unlock(&kdb_immed_lk);
+    if (disabled)
+        local_irq_disable();
+}
+
+/* called very early during init, even before all CPUs are brought online */
+void 
+kdb_init(void)
+{
+        kdb_init_cmdtab();      /* Initialize Command Table */
+}
+
+static const char *
+kdb_gettrapname(int trapno)
+{
+    char *ret;
+    switch (trapno) {
+        case  0:  ret = "Divide Error"; break;
+        case  2:  ret = "NMI Interrupt"; break;
+        case  3:  ret = "Int 3 Trap"; break;
+        case  4:  ret = "Overflow Error"; break;
+        case  6:  ret = "Invalid Opcode"; break;
+        case  8:  ret = "Double Fault"; break;
+        case 10:  ret = "Invalid TSS"; break;
+        case 11:  ret = "Segment Not Present"; break;
+        case 12:  ret = "Stack-Segment Fault"; break;
+        case 13:  ret = "General Protection"; break;
+        case 14:  ret = "Page Fault"; break;
+        case 17:  ret = "Alignment Check"; break;
+        default: ret = " ????? ";
+    }
+    return ret;
+}
+
+
+/* ====================== Generic tracing subsystem ======================== */
+
+#define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
+                           * is 32 bytes */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
+
+typedef struct {
+    union {
+        struct { uint d0; uint cpu_trcid; } s0;
+        uint64_t l0;
+    }u;
+    uint64_t l1, l2, l3; 
+} trc_rec_t;
+
+static volatile unsigned int trcidx;    /* points to where new entry will go */
+static trc_rec_t trca[KDBTRCMAX];       /* trace array */
+
+/* atomically: add i to *p, return prev value of *p (ie, val before add) */
+static int
+kdb_fetch_and_add(int i, uint *p)
+{
+    asm volatile("lock xaddl %0, %1;" : "=r"(i) : "m"(*p), "0"(i));
+    return i;
+}
+
+/* zero out the entire buffer */
+void 
+kdb_trczero(void)
+{
+    for (trcidx = KDBTRCMAX-1; trcidx; trcidx--) {
+        memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    }
+    memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    kdbp("kdb trace buffer has been zeroed\n");
+}
+
+/* add trace entry: eg.: kdbtrc(0xe0f099, intdata, vcpu, domain, 0)
+ *    where:  0xe0f099 : 24bits max trcid, lower 8 bits are set to cpuid */
+void
+kdbtrc(uint trcid, uint int_d0, uint64_t d1_64, uint64_t d2_64, uint64_t d3_64)
+{
+    uint idx;
+
+    if (!kdb_trcon)
+        return;
+
+    idx = kdb_fetch_and_add(1, (uint*)&trcidx);
+    idx = idx % KDBTRCMAX;
+
+#if 0
+    trca[idx].u.s0.cpu_trcid = (smp_processor_id()<<24) | trcid;
+#endif
+    trca[idx].u.s0.cpu_trcid = (trcid<<8) | smp_processor_id();
+    trca[idx].u.s0.d0 = int_d0;
+    trca[idx].l1 = d1_64;
+    trca[idx].l2 = d2_64;
+    trca[idx].l3 = d3_64;
+}
+
+/* give hints so user can print trc buffer via the dd command. last has the
+ * most recent entry */
+void
+kdb_trcp(void)
+{
+    int i = trcidx % KDBTRCMAX;
+
+    i = (i==0) ? KDBTRCMAX-1 : i-1;
+    kdbp("trcbuf:    [0]: %016lx [MAX-1]: %016lx\n", &trca[0],
+         &trca[KDBTRCMAX-1]);
+    kdbp(" [most recent]: %016lx   trcidx: 0x%x\n", &trca[i], trcidx);
+}
+
diff -r 54c8c9eaee92 xen/kdb/x86/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y    := kdb_wp.o
+subdir-y += udis86-1.7
diff -r 54c8c9eaee92 xen/kdb/x86/kdb_wp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/kdb_wp.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,310 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+#if 0
+#define DR6_BT  0x00008000
+#define DR6_BS  0x00004000
+#define DR6_BD  0x00002000
+#endif
+#define DR6_B3  0x00000008
+#define DR6_B2  0x00000004
+#define DR6_B1  0x00000002
+#define DR6_B0  0x00000001
+
+#define KDB_MAXWP 4                          /* DR0 thru DR3 */
+
+struct kdb_wp {
+    kdbma_t  wp_addr;
+    int      wp_rwflag;
+    int      wp_len;
+    int      wp_deleted;                     /* pending delete */
+};
+static struct kdb_wp kdb_wpa[KDB_MAXWP];
+
+/* following because vmcs has it's own dr7. when vmcs runs, it messes up the
+ * native dr7 so we need to save/restore it */
+unsigned long kdb_dr7;
+
+
+/* Set G0-G3 bits in DR7. this does global enable of the corresponding wp */
+static void
+kdb_set_gx_in_dr7(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p | 0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p | 0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p | 0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p | 0x80;
+}
+
+/* Set LEN0 - LEN3 pair bits in DR7 (len should be 1 2 4 or 8) */
+static void
+kdb_set_len_in_dr7(int regno, kdbma_t *dr7p, int len)
+{
+    int lenbits = (len == 8) ? 2 : len-1;
+
+    *dr7p &= ~(0x3 << (18 + 4*regno));
+    *dr7p |= ((ulong)(lenbits & 0x3) << (18 + 4*regno));
+}
+
+static void
+kdb_set_dr7_rw(int regno, kdbma_t *dr7p, int rw)
+{
+    *dr7p &= ~(0x3 << (16 + 4*regno));
+    *dr7p |= ((ulong)(rw & 0x3)) << (16 + 4*regno);
+}
+
+/* get value of a debug register: DR0-DR3 DR6 DR7. other values return 0 */
+kdbma_t
+kdb_rd_dbgreg(int regnum)
+{
+    kdbma_t contents = 0;
+
+    if (regnum == 0)
+        __asm__ ("movq %%db0,%0\n\t":"=r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %%db1,%0\n\t":"=r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %%db2,%0\n\t":"=r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %%db3,%0\n\t":"=r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %%db6,%0\n\t":"=r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %%db7,%0\n\t":"=r"(contents));
+
+    return contents;
+}
+
+static void
+kdb_wr_dbgreg(int regnum, kdbma_t contents)
+{
+    if (regnum == 0)
+        __asm__ ("movq %0,%%db0\n\t"::"r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %0,%%db1\n\t"::"r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %0,%%db2\n\t"::"r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %0,%%db3\n\t"::"r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %0,%%db6\n\t"::"r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %0,%%db7\n\t"::"r"(contents));
+}
+
+static void
+kdb_print_wp_info(char *strp, int idx)
+{
+    kdbp("%s[%d]:%016lx len:%d ", strp, idx, kdb_wpa[idx].wp_addr,
+         kdb_wpa[idx].wp_len);
+    if (kdb_wpa[idx].wp_rwflag == 1)
+        kdbp("on data write only\n");
+    else if (kdb_wpa[idx].wp_rwflag == 2)
+        kdbp("on IO read/write\n");
+    else 
+        kdbp("on data read/write\n");
+}
+
+/*
+ * Returns : 0 if not one of ours
+ *           1 if one of ours
+ */
+int
+kdb_check_watchpoints(struct cpu_user_regs *regs)
+{
+    int wpnum;
+    kdbma_t dr6 = kdb_rd_dbgreg(6);
+
+    KDBGP1("check_wp: IP:%lx EFLAGS:%lx\n", regs->rip, regs->rflags);
+    if (dr6 & DR6_B0)
+        wpnum = 0;
+    else if (dr6 & DR6_B1)
+        wpnum = 1;
+    else if (dr6 & DR6_B2)
+        wpnum = 2;
+    else if (dr6 & DR6_B3)
+        wpnum = 3;
+    else
+        return 0;
+
+    kdb_print_wp_info("Watchpoint ", wpnum);
+    return 1;
+}
+
+/* set a watchpoint at a given address 
+ * PreCondition: addr != 0 */
+static void
+kdb_set_wp(kdbva_t addr, int rwflag, int len)
+{
+    int regno;
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        if (kdb_wpa[regno].wp_addr == addr && !kdb_wpa[regno].wp_deleted) {
+            kdbp("Watchpoint already set\n");
+            return;
+        }
+        if (kdb_wpa[regno].wp_deleted)
+            memset(&kdb_wpa[regno], 0, sizeof(kdb_wpa[regno]));
+    }
+    for (regno=0; regno < KDB_MAXWP && kdb_wpa[regno].wp_addr; regno++);
+    if (regno >= KDB_MAXWP) {
+        kdbp("watchpoint table full. limit:%d\n", KDB_MAXWP);
+        return;
+    }
+    kdb_wpa[regno].wp_addr = addr;
+    kdb_wpa[regno].wp_rwflag = rwflag;
+    kdb_wpa[regno].wp_len = len;
+    kdb_print_wp_info("Watchpoint set ", regno);
+}
+
+/* write reg DR0-3 with address. Update corresponding bits in DR7 */
+static void
+kdb_install_watchpoint(int regno, kdbma_t *dr7p)
+{
+    kdb_set_gx_in_dr7(regno, dr7p);
+    kdb_set_len_in_dr7(regno, dr7p, kdb_wpa[regno].wp_len); 
+    kdb_set_dr7_rw(regno, dr7p, kdb_wpa[regno].wp_rwflag);
+    kdb_wr_dbgreg(regno, kdb_wpa[regno].wp_addr);
+
+    KDBGP1("ccpu:%d installed wp. addr:%lx rw:%x len:%x dr7:%016lx\n",
+           smp_processor_id(), kdb_wpa[regno].wp_addr, 
+           kdb_wpa[regno].wp_rwflag, kdb_wpa[regno].wp_len, *dr7p);
+}
+
+/* clear G0-G3 bits in DR7 for given DR0-3 */
+static void
+kdb_clear_dr7_gx(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p & ~0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p & ~0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p & ~0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p & ~0x80;
+}
+
+/* update dr7 once, as it's slow to update debug regs and cpu's will still be 
+ * paused when leaving kdb.
+ *
+ * Just leave DR0-3 clobbered but remove bits from DR7 to disable wp 
+ */
+void
+kdb_install_watchpoints(void)
+{
+    int regno;
+    kdbma_t dr7 = kdb_rd_dbgreg(7);
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        /* do not clear wp_deleted here as all cpus must clear wps */
+        if (kdb_wpa[regno].wp_deleted) {
+            kdb_clear_dr7_gx(regno, &dr7);
+            continue;
+        }
+        if (kdb_wpa[regno].wp_addr)
+            kdb_install_watchpoint(regno, &dr7);
+    }
+    /* always clear DR6 when leaving */
+    kdb_wr_dbgreg(6, 0);
+    kdb_wr_dbgreg(7, dr7);
+
+    if (dr7 & DR7_ACTIVE_MASK)
+        kdb_dr7 = dr7;
+    else
+        kdb_dr7 = 0;
+#if 0
+    for(dp=domain_list; dp; dp=dp->next_in_list) {
+        struct vcpu *vp;
+        for_each_vcpu(dp, vp) {
+            for (regno=0; regno < KDB_MAXWP; regno++)
+                vp->arch.guest_context.debugreg[regno] = kdb_wpa[regno].wp_addr;
+
+            vp->arch.guest_context.debugreg[6] = 0;
+            vp->arch.guest_context.debugreg[7] = dr7;
+            KDBGP("kdb_install_watchpoints(): v:%p dr7:%lx\n", vp, dr7);
+            /* hvm_set_info_guest(vp);: Can't because can't vmcs_enter in kdb */
+        }
+    }
+#endif
+}
+
+/* clear watchpoint/s. wpnum == -1 to clear all watchpoints */
+void
+kdb_clear_wps(int wpnum)
+{
+    int i;
+
+    if (wpnum >= KDB_MAXWP) {
+        kdbp("Invalid wpnum %d\n", wpnum);
+        return;
+    }
+    if (wpnum >=0) {
+        if (kdb_wpa[wpnum].wp_addr) {
+            kdb_wpa[wpnum].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", wpnum);
+        } else
+            kdbp("watchpoint %d not set\n", wpnum);
+        return;
+    }
+    for (i=0; i < KDB_MAXWP; i++) {
+        if (kdb_wpa[i].wp_addr) {
+            kdb_wpa[i].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", i);
+        }
+    }
+}
+
+/* display any watchpoints that are set */
+static void
+kdb_display_wps(void)
+{
+    int i;
+    for (i=0; i < KDB_MAXWP; i++)
+        if (kdb_wpa[i].wp_addr && !kdb_wpa[i].wp_deleted) 
+            kdb_print_wp_info("", i);
+}
+
+/* 
+ * Display or Set hardware breakpoints, ie, watchpoints:
+ *   - Upto 4 are allowed
+ *   
+ *  rw_flag should be one of: 
+ *     01 == break on data write only
+ *     10 == break on IO read/write
+ *     11 == Break on data reads or writes
+ *
+ *  len should be one of : 1 2 4 8 
+ */
+void
+kdb_do_watchpoints(kdbva_t addr, int rw_flag, int len)
+{
+    if (addr == 0) {
+        kdb_display_wps();        /* display set watchpoints */
+        return;
+    }
+    kdb_set_wp(addr, rw_flag, len);
+    return;
+}
+
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/LICENSE
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/LICENSE	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,22 @@
+Copyright (c) 2002, 2003, 2004, 2005, 2006 <vivek@sig9.com>
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, 
+are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice, 
+      this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright notice, 
+      this list of conditions and the following disclaimer in the documentation 
+      and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,5 @@
+
+CFLAGS		+= -D__UD_STANDALONE__
+obj-y		:= decode.o input.o itab.o kdb_dis.o syn-att.o syn.o \
+                   syn-intel.o udis86.o
+
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/README	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,10 @@
+
+http://udis86.sourceforge.net/
+udis86-1.6 : 
+  - cd libudis86
+  - cp *c to here
+  - cp *h to here
+   
+Mukesh Rathor
+04/30/2008
+
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/decode.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,1197 @@
+/* -----------------------------------------------------------------------------
+ * decode.c
+ *
+ * Copyright (c) 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <assert.h>
+#include <string.h>
+#endif
+
+#include "types.h"
+#include "itab.h"
+#include "input.h"
+#include "decode.h"
+
+/* The max number of prefixes to an instruction */
+#define MAX_PREFIXES    15
+
+static struct ud_itab_entry ie_invalid = { UD_Iinvalid, O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_pause   = { UD_Ipause,   O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_nop     = { UD_Inop,     O_NONE, O_NONE, O_NONE, P_none };
+
+
+/* Looks up mnemonic code in the mnemonic string table
+ * Returns NULL if the mnemonic code is invalid
+ */
+const char * ud_lookup_mnemonic( enum ud_mnemonic_code c )
+{
+    if ( c < UD_Id3vil )
+        return ud_mnemonics_str[ c ];
+    return NULL;
+}
+
+
+/* Extracts instruction prefixes.
+ */
+static int get_prefixes( struct ud* u )
+{
+    unsigned int have_pfx = 1;
+    unsigned int i;
+    uint8_t curr;
+
+    /* if in error state, bail out */
+    if ( u->error ) 
+        return -1; 
+
+    /* keep going as long as there are prefixes available */
+    for ( i = 0; have_pfx ; ++i ) {
+
+        /* Get next byte. */
+        inp_next(u); 
+        if ( u->error ) 
+            return -1;
+        curr = inp_curr( u );
+
+        /* rex prefixes in 64bit mode */
+        if ( u->dis_mode == 64 && ( curr & 0xF0 ) == 0x40 ) {
+            u->pfx_rex = curr;  
+        } else {
+            switch ( curr )  
+            {
+            case 0x2E : 
+                u->pfx_seg = UD_R_CS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x36 :     
+                u->pfx_seg = UD_R_SS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x3E : 
+                u->pfx_seg = UD_R_DS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x26 : 
+                u->pfx_seg = UD_R_ES; 
+                u->pfx_rex = 0;
+                break;
+            case 0x64 : 
+                u->pfx_seg = UD_R_FS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x65 : 
+                u->pfx_seg = UD_R_GS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x67 : /* adress-size override prefix */ 
+                u->pfx_adr = 0x67;
+                u->pfx_rex = 0;
+                break;
+            case 0xF0 : 
+                u->pfx_lock = 0xF0;
+                u->pfx_rex  = 0;
+                break;
+            case 0x66: 
+                /* the 0x66 sse prefix is only effective if no other sse prefix
+                 * has already been specified.
+                 */
+                if ( !u->pfx_insn ) u->pfx_insn = 0x66;
+                u->pfx_opr = 0x66;           
+                u->pfx_rex = 0;
+                break;
+            case 0xF2:
+                u->pfx_insn  = 0xF2;
+                u->pfx_repne = 0xF2; 
+                u->pfx_rex   = 0;
+                break;
+            case 0xF3:
+                u->pfx_insn = 0xF3;
+                u->pfx_rep  = 0xF3; 
+                u->pfx_repe = 0xF3; 
+                u->pfx_rex  = 0;
+                break;
+            default : 
+                /* No more prefixes */
+                have_pfx = 0;
+                break;
+            }
+        }
+
+        /* check if we reached max instruction length */
+        if ( i + 1 == MAX_INSN_LENGTH ) {
+            u->error = 1;
+            break;
+        }
+    }
+
+    /* return status */
+    if ( u->error ) 
+        return -1; 
+
+    /* rewind back one byte in stream, since the above loop 
+     * stops with a non-prefix byte. 
+     */
+    inp_back(u);
+
+    /* speculatively determine the effective operand mode,
+     * based on the prefixes and the current disassembly
+     * mode. This may be inaccurate, but useful for mode
+     * dependent decoding.
+     */
+    if ( u->dis_mode == 64 ) {
+        u->opr_mode = REX_W( u->pfx_rex ) ? 64 : ( ( u->pfx_opr ) ? 16 : 32 ) ;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 64;
+    } else if ( u->dis_mode == 32 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+        u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+    } else if ( u->dis_mode == 16 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+    }
+
+    return 0;
+}
+
+
+/* Searches the instruction tables for the right entry.
+ */
+static int search_itab( struct ud * u )
+{
+    struct ud_itab_entry * e = NULL;
+    enum ud_itab_index table;
+    uint8_t peek;
+    uint8_t did_peek = 0;
+    uint8_t curr; 
+    uint8_t index;
+
+    /* if in state of error, return */
+    if ( u->error ) 
+        return -1;
+
+    /* get first byte of opcode. */
+    inp_next(u); 
+    if ( u->error ) 
+        return -1;
+    curr = inp_curr(u); 
+
+    /* resolve xchg, nop, pause crazyness */
+    if ( 0x90 == curr ) {
+        if ( !( u->dis_mode == 64 && REX_B( u->pfx_rex ) ) ) {
+            if ( u->pfx_rep ) {
+                u->pfx_rep = 0;
+                e = & ie_pause;
+            } else {
+                e = & ie_nop;
+            }
+            goto found_entry;
+        }
+    }
+
+    /* get top-level table */
+    if ( 0x0F == curr ) {
+        table = ITAB__0F;
+        curr  = inp_next(u);
+        if ( u->error )
+            return -1;
+
+        /* 2byte opcodes can be modified by 0x66, F3, and F2 prefixes */
+        if ( 0x66 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSE66__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSE66__0F;
+                u->pfx_opr = 0;
+            }
+        } else if ( 0xF2 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF2__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF2__0F; 
+                u->pfx_repne = 0;
+            }
+        } else if ( 0xF3 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF3__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF3__0F;
+                u->pfx_repe = 0;
+                u->pfx_rep  = 0;
+            }
+        }
+    /* pick an instruction from the 1byte table */
+    } else {
+        table = ITAB__1BYTE; 
+    }
+
+    index = curr;
+
+search:
+
+    e = & ud_itab_list[ table ][ index ];
+
+    /* if mnemonic constant is a standard instruction constant
+     * our search is over.
+     */
+    
+    if ( e->mnemonic < UD_Id3vil ) {
+        if ( e->mnemonic == UD_Iinvalid ) {
+            if ( did_peek ) {
+                inp_next( u ); if ( u->error ) return -1;
+            }
+            goto found_entry;
+        }
+        goto found_entry;
+    }
+
+    table = e->prefix;
+
+    switch ( e->mnemonic )
+    {
+    case UD_Igrp_reg:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_REG( peek );
+        break;
+
+    case UD_Igrp_mod:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_MOD( peek );
+        if ( index == 3 )
+           index = ITAB__MOD_INDX__11;
+        else 
+           index = ITAB__MOD_INDX__NOT_11; 
+        break;
+
+    case UD_Igrp_rm:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = MODRM_RM( curr );
+        break;
+
+    case UD_Igrp_x87:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = curr - 0xC0;
+        break;
+
+    case UD_Igrp_osize:
+        if ( u->opr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->opr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+ 
+    case UD_Igrp_asize:
+        if ( u->adr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->adr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;               
+
+    case UD_Igrp_mode:
+        if ( u->dis_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->dis_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+
+    case UD_Igrp_vendor:
+        if ( u->vendor == UD_VENDOR_INTEL ) 
+            index = ITAB__VENDOR_INDX__INTEL; 
+        else if ( u->vendor == UD_VENDOR_AMD )
+            index = ITAB__VENDOR_INDX__AMD;
+        else {
+            kdbp("KDB:search_itab(): unrecognized vendor id\n");
+            return -1;
+        }
+        break;
+
+    case UD_Id3vil:
+        kdbp("KDB:search_itab(): invalid instr mnemonic constant Id3vil\n");
+        return -1;
+
+    default:
+        kdbp("KDB:search_itab(): invalid instruction mnemonic constant\n");
+        return -1;
+    }
+
+    goto search;
+
+found_entry:
+
+    u->itab_entry = e;
+    u->mnemonic = u->itab_entry->mnemonic;
+
+    return 0;
+}
+
+
+static unsigned int resolve_operand_size( const struct ud * u, unsigned int s )
+{
+    switch ( s ) 
+    {
+    case SZ_V:
+        return ( u->opr_mode );
+    case SZ_Z:  
+        return ( u->opr_mode == 16 ) ? 16 : 32;
+    case SZ_P:  
+        return ( u->opr_mode == 16 ) ? SZ_WP : SZ_DP;
+    case SZ_MDQ:
+        return ( u->opr_mode == 16 ) ? 32 : u->opr_mode;
+    case SZ_RDQ:
+        return ( u->dis_mode == 64 ) ? 64 : 32;
+    default:
+        return s;
+    }
+}
+
+
+static int resolve_mnemonic( struct ud* u )
+{
+  /* far/near flags */
+  u->br_far = 0;
+  u->br_near = 0;
+  /* readjust operand sizes for call/jmp instrcutions */
+  if ( u->mnemonic == UD_Icall || u->mnemonic == UD_Ijmp ) {
+    /* WP: 16bit pointer */
+    if ( u->operand[ 0 ].size == SZ_WP ) {
+        u->operand[ 0 ].size = 16;
+        u->br_far = 1;
+        u->br_near= 0;
+    /* DP: 32bit pointer */
+    } else if ( u->operand[ 0 ].size == SZ_DP ) {
+        u->operand[ 0 ].size = 32;
+        u->br_far = 1;
+        u->br_near= 0;
+    } else {
+        u->br_far = 0;
+        u->br_near= 1;
+    }
+  /* resolve 3dnow weirdness. */
+  } else if ( u->mnemonic == UD_I3dnow ) {
+    u->mnemonic = ud_itab_list[ ITAB__3DNOW ][ inp_curr( u )  ].mnemonic;
+  }
+  /* SWAPGS is only valid in 64bits mode */
+  if ( u->mnemonic == UD_Iswapgs && u->dis_mode != 64 ) {
+    u->error = 1;
+    return -1;
+  }
+
+  return 0;
+}
+
+
+/* -----------------------------------------------------------------------------
+ * decode_a()- Decodes operands of the type seg:offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_a(struct ud* u, struct ud_operand *op)
+{
+  if (u->opr_mode == 16) {  
+    /* seg16:off16 */
+    op->type = UD_OP_PTR;
+    op->size = 32;
+    op->lval.ptr.off = inp_uint16(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  } else {
+    /* seg16:off32 */
+    op->type = UD_OP_PTR;
+    op->size = 48;
+    op->lval.ptr.off = inp_uint32(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_gpr() - Returns decoded General Purpose Register 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+decode_gpr(register struct ud* u, unsigned int s, unsigned char rm)
+{
+  s = resolve_operand_size(u, s);
+        
+  switch (s) {
+    case 64:
+        return UD_R_RAX + rm;
+    case SZ_DP:
+    case 32:
+        return UD_R_EAX + rm;
+    case SZ_WP:
+    case 16:
+        return UD_R_AX  + rm;
+    case  8:
+        if (u->dis_mode == 64 && u->pfx_rex) {
+            if (rm >= 4)
+                return UD_R_SPL + (rm-4);
+            return UD_R_AL + rm;
+        } else return UD_R_AL + rm;
+    default:
+        return 0;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr64() - 64bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr64(struct ud* u, enum ud_operand_code gpr_op)
+{
+  if (gpr_op >= OP_rAXr8 && gpr_op <= OP_rDIr15)
+    gpr_op = (gpr_op - OP_rAXr8) | (REX_B(u->pfx_rex) << 3);          
+  else  gpr_op = (gpr_op - OP_rAX);
+
+  if (u->opr_mode == 16)
+    return gpr_op + UD_R_AX;
+  if (u->dis_mode == 32 || 
+    (u->opr_mode == 32 && ! (REX_W(u->pfx_rex) || u->default64))) {
+    return gpr_op + UD_R_EAX;
+  }
+
+  return gpr_op + UD_R_RAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr32 () - 32bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr32(struct ud* u, enum ud_operand_code gpr_op)
+{
+  gpr_op = gpr_op - OP_eAX;
+
+  if (u->opr_mode == 16) 
+    return gpr_op + UD_R_AX;
+
+  return gpr_op +  UD_R_EAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_reg() - Resolves the register type 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_reg(struct ud* u, unsigned int type, unsigned char i)
+{
+  switch (type) {
+    case T_MMX :    return UD_R_MM0  + (i & 7);
+    case T_XMM :    return UD_R_XMM0 + i;
+    case T_CRG :    return UD_R_CR0  + i;
+    case T_DBG :    return UD_R_DR0  + i;
+    case T_SEG :    return UD_R_ES   + (i & 7);
+    case T_NONE:
+    default:    return UD_NONE;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_imm() - Decodes Immediate values.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_imm(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  op->size = resolve_operand_size(u, s);
+  op->type = UD_OP_IMM;
+
+  switch (op->size) {
+    case  8: op->lval.sbyte = inp_uint8(u);   break;
+    case 16: op->lval.uword = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: return;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_modrm() - Decodes ModRM Byte
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_modrm(struct ud* u, struct ud_operand *op, unsigned int s, 
+         unsigned char rm_type, struct ud_operand *opreg, 
+         unsigned char reg_size, unsigned char reg_type)
+{
+  unsigned char mod, rm, reg;
+
+  inp_next(u);
+
+  /* get mod, r/m and reg fields */
+  mod = MODRM_MOD(inp_curr(u));
+  rm  = (REX_B(u->pfx_rex) << 3) | MODRM_RM(inp_curr(u));
+  reg = (REX_R(u->pfx_rex) << 3) | MODRM_REG(inp_curr(u));
+
+  op->size = resolve_operand_size(u, s);
+
+  /* if mod is 11b, then the UD_R_m specifies a gpr/mmx/sse/control/debug */
+  if (mod == 3) {
+    op->type = UD_OP_REG;
+    if (rm_type ==  T_GPR)
+        op->base = decode_gpr(u, op->size, rm);
+    else    op->base = resolve_reg(u, rm_type, (REX_B(u->pfx_rex) << 3) | (rm&7));
+  } 
+  /* else its memory addressing */  
+  else {
+    op->type = UD_OP_MEM;
+
+    /* 64bit addressing */
+    if (u->adr_mode == 64) {
+
+        op->base = UD_R_RAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && (rm & 7) == 5) {           
+            op->base = UD_R_RIP;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+            
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_RAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_RAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            /* special conditions for base reference */
+            if (op->index == UD_R_RSP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            if (op->base == UD_R_RBP || op->base == UD_R_R13) {
+                if (mod == 0) 
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 32-Bit addressing mode */
+    else if (u->adr_mode == 32) {
+
+        /* get base */
+        op->base = UD_R_EAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && rm == 5) {
+            op->base = UD_NONE;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_EAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_EAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            if (op->index == UD_R_ESP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            /* special condition for base reference */
+            if (op->base == UD_R_EBP) {
+                if (mod == 0)
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 16bit addressing mode */
+    else  {
+        switch (rm) {
+            case 0: op->base = UD_R_BX; op->index = UD_R_SI; break;
+            case 1: op->base = UD_R_BX; op->index = UD_R_DI; break;
+            case 2: op->base = UD_R_BP; op->index = UD_R_SI; break;
+            case 3: op->base = UD_R_BP; op->index = UD_R_DI; break;
+            case 4: op->base = UD_R_SI; break;
+            case 5: op->base = UD_R_DI; break;
+            case 6: op->base = UD_R_BP; break;
+            case 7: op->base = UD_R_BX; break;
+        }
+
+        if (mod == 0 && rm == 6) {
+            op->offset= 16;
+            op->base = UD_NONE;
+        }
+        else if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2) 
+            op->offset = 16;
+    }
+  }  
+
+  /* extract offset, if any */
+  switch(op->offset) {
+    case 8 : op->lval.ubyte  = inp_uint8(u);  break;
+    case 16: op->lval.uword  = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: break;
+  }
+
+  /* resolve register encoded in reg field */
+  if (opreg) {
+    opreg->type = UD_OP_REG;
+    opreg->size = resolve_operand_size(u, reg_size);
+    if (reg_type == T_GPR) 
+        opreg->base = decode_gpr(u, opreg->size, reg);
+    else opreg->base = resolve_reg(u, reg_type, reg);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_o() - Decodes offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_o(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  switch (u->adr_mode) {
+    case 64:
+        op->offset = 64; 
+        op->lval.uqword = inp_uint64(u); 
+        break;
+    case 32:
+        op->offset = 32; 
+        op->lval.udword = inp_uint32(u); 
+        break;
+    case 16:
+        op->offset = 16; 
+        op->lval.uword  = inp_uint16(u); 
+        break;
+    default:
+        return;
+  }
+  op->type = UD_OP_MEM;
+  op->size = resolve_operand_size(u, s);
+}
+
+/* -----------------------------------------------------------------------------
+ * disasm_operands() - Disassembles Operands.
+ * -----------------------------------------------------------------------------
+ */
+static int disasm_operands(register struct ud* u)
+{
+
+
+  /* mopXt = map entry, operand X, type; */
+  enum ud_operand_code mop1t = u->itab_entry->operand1.type;
+  enum ud_operand_code mop2t = u->itab_entry->operand2.type;
+  enum ud_operand_code mop3t = u->itab_entry->operand3.type;
+
+  /* mopXs = map entry, operand X, size */
+  unsigned int mop1s = u->itab_entry->operand1.size;
+  unsigned int mop2s = u->itab_entry->operand2.size;
+  unsigned int mop3s = u->itab_entry->operand3.size;
+
+  /* iop = instruction operand */
+  register struct ud_operand* iop = u->operand;
+    
+  switch(mop1t) {
+    
+    case OP_A :
+        decode_a(u, &(iop[0]));
+        break;
+    
+    /* M[b] ... */
+    case OP_M :
+        if (MODRM_MOD(inp_peek(u)) == 3)
+            u->error= 1;
+    /* E, G/P/V/I/CL/1/S */
+    case OP_E :
+        if (mop2t == OP_G) {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+            else if (mop3t == OP_CL) {
+                iop[2].type = UD_OP_REG;
+                iop[2].base = UD_R_CL;
+                iop[2].size = 8;
+            }
+        }
+        else if (mop2t == OP_P)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_MMX);
+        else if (mop2t == OP_V)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_XMM);
+        else if (mop2t == OP_S)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_SEG);
+        else {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, NULL, 0, T_NONE);
+            if (mop2t == OP_CL) {
+                iop[1].type = UD_OP_REG;
+                iop[1].base = UD_R_CL;
+                iop[1].size = 8;
+            } else if (mop2t == OP_I1) {
+                iop[1].type = UD_OP_CONST;
+                u->operand[1].lval.udword = 1;
+            } else if (mop2t == OP_I) {
+                decode_imm(u, mop2s, &(iop[1]));
+            }
+        }
+        break;
+
+    /* G, E/PR[,I]/VR */
+    case OP_G :
+        if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_W)
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        break;
+
+    /* AL..BH, I/O/DX */
+    case OP_AL : case OP_CL : case OP_DL : case OP_BL :
+    case OP_AH : case OP_CH : case OP_DH : case OP_BH :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AL + (mop1t - OP_AL);
+        iop[0].size = 8;
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        }
+        else if (mop2t == OP_O)
+            decode_o(u, mop2s, &(iop[1]));
+        break;
+
+    /* rAX[r8]..rDI[r15], I/rAX..rDI/O */
+    case OP_rAXr8 : case OP_rCXr9 : case OP_rDXr10 : case OP_rBXr11 :
+    case OP_rSPr12: case OP_rBPr13: case OP_rSIr14 : case OP_rDIr15 :
+    case OP_rAX : case OP_rCX : case OP_rDX : case OP_rBX :
+    case OP_rSP : case OP_rBP : case OP_rSI : case OP_rDI :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr64(u, mop1t);
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t >= OP_rAX && mop2t <= OP_rDI) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = resolve_gpr64(u, mop2t);
+        }
+        else if (mop2t == OP_O) {
+            decode_o(u, mop2s, &(iop[1]));  
+            iop[0].size = resolve_operand_size(u, mop2s);
+        }
+        break;
+
+    /* AL[r8b]..BH[r15b], I */
+    case OP_ALr8b : case OP_CLr9b : case OP_DLr10b : case OP_BLr11b :
+    case OP_AHr12b: case OP_CHr13b: case OP_DHr14b : case OP_BHr15b :
+    {
+        ud_type_t gpr = (mop1t - OP_ALr8b) + UD_R_AL + 
+                        (REX_B(u->pfx_rex) << 3);
+        if (UD_R_AH <= gpr && u->pfx_rex)
+            gpr = gpr + 4;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = gpr;
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+    }
+
+    /* eAX..eDX, DX/I */
+    case OP_eAX : case OP_eCX : case OP_eDX : case OP_eBX :
+    case OP_eSP : case OP_eBP : case OP_eSI : case OP_eDI :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr32(u, mop1t);
+        if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        } else if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+
+    /* ES..GS */
+    case OP_ES : case OP_CS : case OP_DS :
+    case OP_SS : case OP_FS : case OP_GS :
+
+        /* in 64bits mode, only fs and gs are allowed */
+        if (u->dis_mode == 64)
+            if (mop1t != OP_FS && mop1t != OP_GS)
+                u->error= 1;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t - OP_ES) + UD_R_ES;
+        iop[0].size = 16;
+
+        break;
+
+    /* J */
+    case OP_J :
+        decode_imm(u, mop1s, &(iop[0]));        
+        iop[0].type = UD_OP_JIMM;
+        break ;
+
+    /* PR, I */
+    case OP_PR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* VR, I */
+    case OP_VR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* P, Q[,I]/W/E[,I],VR */
+    case OP_P :
+        if (mop2t == OP_Q) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_W) {
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        }
+        break;
+
+    /* R, C/D */
+    case OP_R :
+        if (mop2t == OP_C)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_CRG);
+        else if (mop2t == OP_D)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_DBG);
+        break;
+
+    /* C, R */
+    case OP_C :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_CRG);
+        break;
+
+    /* D, R */
+    case OP_D :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_DBG);
+        break;
+
+    /* Q, P */
+    case OP_Q :
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, &(iop[1]), mop2s, T_MMX);
+        break;
+
+    /* S, E */
+    case OP_S :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_SEG);
+        break;
+
+    /* W, V */
+    case OP_W :
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, &(iop[1]), mop2s, T_XMM);
+        break;
+
+    /* V, W[,I]/Q/M/E */
+    case OP_V :
+        if (mop2t == OP_W) {
+            /* special cases for movlps and movhps */
+            if (MODRM_MOD(inp_peek(u)) == 3) {
+                if (u->mnemonic == UD_Imovlps)
+                    u->mnemonic = UD_Imovhlps;
+                else
+                if (u->mnemonic == UD_Imovhps)
+                    u->mnemonic = UD_Imovlhps;
+            }
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_XMM);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_Q)
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        else if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        }
+        break;
+
+    /* DX, eAX/AL */
+    case OP_DX :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_DX;
+        iop[0].size = 16;
+
+        if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        } else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 8;
+        }
+
+        break;
+
+    /* I, I/AL/eAX */
+    case OP_I :
+        decode_imm(u, mop1s, &(iop[0]));
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 16;
+        } else if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        }
+        break;
+
+    /* O, AL/eAX */
+    case OP_O :
+        decode_o(u, mop1s, &(iop[0]));
+        iop[1].type = UD_OP_REG;
+        iop[1].size = resolve_operand_size(u, mop1s);
+        if (mop2t == OP_AL)
+            iop[1].base = UD_R_AL;
+        else if (mop2t == OP_eAX)
+            iop[1].base = resolve_gpr32(u, mop2t);
+        else if (mop2t == OP_rAX)
+            iop[1].base = resolve_gpr64(u, mop2t);      
+        break;
+
+    /* 3 */
+    case OP_I3 :
+        iop[0].type = UD_OP_CONST;
+        iop[0].lval.sbyte = 3;
+        break;
+
+    /* ST(n), ST(n) */
+    case OP_ST0 : case OP_ST1 : case OP_ST2 : case OP_ST3 :
+    case OP_ST4 : case OP_ST5 : case OP_ST6 : case OP_ST7 :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t-OP_ST0) + UD_R_ST0;
+        iop[0].size = 0;
+
+        if (mop2t >= OP_ST0 && mop2t <= OP_ST7) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = (mop2t-OP_ST0) + UD_R_ST0;
+            iop[1].size = 0;
+        }
+        break;
+
+    /* AX */
+    case OP_AX:
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AX;
+        iop[0].size = 16;
+        break;
+
+    /* none */
+    default :
+        iop[0].type = iop[1].type = iop[2].type = UD_NONE;
+  }
+
+  return 0;
+}
+
+/* -----------------------------------------------------------------------------
+ * clear_insn() - clear instruction pointer 
+ * -----------------------------------------------------------------------------
+ */
+static int clear_insn(register struct ud* u)
+{
+  u->error     = 0;
+  u->pfx_seg   = 0;
+  u->pfx_opr   = 0;
+  u->pfx_adr   = 0;
+  u->pfx_lock  = 0;
+  u->pfx_repne = 0;
+  u->pfx_rep   = 0;
+  u->pfx_repe  = 0;
+  u->pfx_seg   = 0;
+  u->pfx_rex   = 0;
+  u->pfx_insn  = 0;
+  u->mnemonic  = UD_Inone;
+  u->itab_entry = NULL;
+
+  memset( &u->operand[ 0 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 1 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 2 ], 0, sizeof( struct ud_operand ) );
+ 
+  return 0;
+}
+
+static int do_mode( struct ud* u )
+{
+  /* if in error state, bail out */
+  if ( u->error ) return -1; 
+
+  /* propagate perfix effects */
+  if ( u->dis_mode == 64 ) {  /* set 64bit-mode flags */
+
+    /* Check validity of  instruction m64 */
+    if ( P_INV64( u->itab_entry->prefix ) ) {
+        u->error = 1;
+        return -1;
+    }
+
+    /* effective rex prefix is the  effective mask for the 
+     * instruction hard-coded in the opcode map.
+     */
+    u->pfx_rex = ( u->pfx_rex & 0x40 ) | 
+                 ( u->pfx_rex & REX_PFX_MASK( u->itab_entry->prefix ) ); 
+
+    /* whether this instruction has a default operand size of 
+     * 64bit, also hardcoded into the opcode map.
+     */
+    u->default64 = P_DEF64( u->itab_entry->prefix ); 
+    /* calculate effective operand size */
+    if ( REX_W( u->pfx_rex ) ) {
+        u->opr_mode = 64;
+    } else if ( u->pfx_opr ) {
+        u->opr_mode = 16;
+    } else {
+        /* unless the default opr size of instruction is 64,
+         * the effective operand size in the absence of rex.w
+         * prefix is 32.
+         */
+        u->opr_mode = ( u->default64 ) ? 64 : 32;
+    }
+
+    /* calculate effective address size */
+    u->adr_mode = (u->pfx_adr) ? 32 : 64;
+  } else if ( u->dis_mode == 32 ) { /* set 32bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+    u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+  } else if ( u->dis_mode == 16 ) { /* set 16bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+    u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+  }
+
+  /* These flags determine which operand to apply the operand size
+   * cast to.
+   */
+  u->c1 = ( P_C1( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c2 = ( P_C2( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c3 = ( P_C3( u->itab_entry->prefix ) ) ? 1 : 0;
+
+  /* set flags for implicit addressing */
+  u->implicit_addr = P_IMPADDR( u->itab_entry->prefix );
+
+  return 0;
+}
+
+static int gen_hex( struct ud *u )
+{
+  unsigned int i;
+  unsigned char *src_ptr = inp_sess( u );
+  char* src_hex;
+
+  /* bail out if in error stat. */
+  if ( u->error ) return -1; 
+  /* output buffer pointe */
+  src_hex = ( char* ) u->insn_hexcode;
+  /* for each byte used to decode instruction */
+  for ( i = 0; i < u->inp_ctr; ++i, ++src_ptr) {
+    snprintf( src_hex, 2, "%02x", *src_ptr & 0xFF );
+    src_hex += 2;
+  }
+  return 0;
+}
+
+/* =============================================================================
+ * ud_decode() - Instruction decoder. Returns the number of bytes decoded.
+ * =============================================================================
+ */
+unsigned int ud_decode( struct ud* u )
+{
+  inp_start(u);
+
+  if ( clear_insn( u ) ) {
+    ; /* error */
+  } else if ( get_prefixes( u ) != 0 ) {
+    ; /* error */
+  } else if ( search_itab( u ) != 0 ) {
+    ; /* error */
+  } else if ( do_mode( u ) != 0 ) {
+    ; /* error */
+  } else if ( disasm_operands( u ) != 0 ) {
+    ; /* error */
+  } else if ( resolve_mnemonic( u ) != 0 ) {
+    ; /* error */
+  }
+
+  /* Handle decode error. */
+  if ( u->error ) {
+    /* clear out the decode data. */
+    clear_insn( u );
+    /* mark the sequence of bytes as invalid. */
+    u->itab_entry = & ie_invalid;
+    u->mnemonic = u->itab_entry->mnemonic;
+  } 
+
+  u->insn_offset = u->pc; /* set offset of instruction */
+  u->insn_fill = 0;   /* set translation buffer index to 0 */
+  u->pc += u->inp_ctr;    /* move program counter by bytes decoded */
+  gen_hex( u );       /* generate hex code */
+
+  /* return number of bytes disassembled. */
+  return u->inp_ctr;
+}
+
+/* vim:cindent
+ * vim:ts=4
+ * vim:sw=4
+ * vim:expandtab
+ */
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/decode.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,273 @@
+#ifndef UD_DECODE_H
+#define UD_DECODE_H
+
+#define MAX_INSN_LENGTH 15
+
+/* register classes */
+#define T_NONE  0
+#define T_GPR   1
+#define T_MMX   2
+#define T_CRG   3
+#define T_DBG   4
+#define T_SEG   5
+#define T_XMM   6
+
+/* itab prefix bits */
+#define P_none          ( 0 )
+#define P_c1            ( 1 << 0 )
+#define P_C1(n)         ( ( n >> 0 ) & 1 )
+#define P_rexb          ( 1 << 1 )
+#define P_REXB(n)       ( ( n >> 1 ) & 1 )
+#define P_depM          ( 1 << 2 )
+#define P_DEPM(n)       ( ( n >> 2 ) & 1 )
+#define P_c3            ( 1 << 3 )
+#define P_C3(n)         ( ( n >> 3 ) & 1 )
+#define P_inv64         ( 1 << 4 )
+#define P_INV64(n)      ( ( n >> 4 ) & 1 )
+#define P_rexw          ( 1 << 5 )
+#define P_REXW(n)       ( ( n >> 5 ) & 1 )
+#define P_c2            ( 1 << 6 )
+#define P_C2(n)         ( ( n >> 6 ) & 1 )
+#define P_def64         ( 1 << 7 )
+#define P_DEF64(n)      ( ( n >> 7 ) & 1 )
+#define P_rexr          ( 1 << 8 )
+#define P_REXR(n)       ( ( n >> 8 ) & 1 )
+#define P_oso           ( 1 << 9 )
+#define P_OSO(n)        ( ( n >> 9 ) & 1 )
+#define P_aso           ( 1 << 10 )
+#define P_ASO(n)        ( ( n >> 10 ) & 1 )
+#define P_rexx          ( 1 << 11 )
+#define P_REXX(n)       ( ( n >> 11 ) & 1 )
+#define P_ImpAddr       ( 1 << 12 )
+#define P_IMPADDR(n)    ( ( n >> 12 ) & 1 )
+
+/* rex prefix bits */
+#define REX_W(r)        ( ( 0xF & ( r ) )  >> 3 )
+#define REX_R(r)        ( ( 0x7 & ( r ) )  >> 2 )
+#define REX_X(r)        ( ( 0x3 & ( r ) )  >> 1 )
+#define REX_B(r)        ( ( 0x1 & ( r ) )  >> 0 )
+#define REX_PFX_MASK(n) ( ( P_REXW(n) << 3 ) | \
+                          ( P_REXR(n) << 2 ) | \
+                          ( P_REXX(n) << 1 ) | \
+                          ( P_REXB(n) << 0 ) )
+
+/* scable-index-base bits */
+#define SIB_S(b)        ( ( b ) >> 6 )
+#define SIB_I(b)        ( ( ( b ) >> 3 ) & 7 )
+#define SIB_B(b)        ( ( b ) & 7 )
+
+/* modrm bits */
+#define MODRM_REG(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_NNN(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_MOD(b)    ( ( ( b ) >> 6 ) & 3 )
+#define MODRM_RM(b)     ( ( b ) & 7 )
+
+/* operand type constants -- order is important! */
+
+enum ud_operand_code {
+    OP_NONE,
+
+    OP_A,      OP_E,      OP_M,       OP_G,       
+    OP_I,
+
+    OP_AL,     OP_CL,     OP_DL,      OP_BL,
+    OP_AH,     OP_CH,     OP_DH,      OP_BH,
+
+    OP_ALr8b,  OP_CLr9b,  OP_DLr10b,  OP_BLr11b,
+    OP_AHr12b, OP_CHr13b, OP_DHr14b,  OP_BHr15b,
+
+    OP_AX,     OP_CX,     OP_DX,      OP_BX,
+    OP_SI,     OP_DI,     OP_SP,      OP_BP,
+
+    OP_rAX,    OP_rCX,    OP_rDX,     OP_rBX,  
+    OP_rSP,    OP_rBP,    OP_rSI,     OP_rDI,
+
+    OP_rAXr8,  OP_rCXr9,  OP_rDXr10,  OP_rBXr11,  
+    OP_rSPr12, OP_rBPr13, OP_rSIr14,  OP_rDIr15,
+
+    OP_eAX,    OP_eCX,    OP_eDX,     OP_eBX,
+    OP_eSP,    OP_eBP,    OP_eSI,     OP_eDI,
+
+    OP_ES,     OP_CS,     OP_SS,      OP_DS,  
+    OP_FS,     OP_GS,
+
+    OP_ST0,    OP_ST1,    OP_ST2,     OP_ST3,
+    OP_ST4,    OP_ST5,    OP_ST6,     OP_ST7,
+
+    OP_J,      OP_S,      OP_O,          
+    OP_I1,     OP_I3, 
+
+    OP_V,      OP_W,      OP_Q,       OP_P, 
+
+    OP_R,      OP_C,  OP_D,       OP_VR,  OP_PR
+};
+
+
+/* operand size constants */
+
+enum ud_operand_size {
+    SZ_NA  = 0,
+    SZ_Z   = 1,
+    SZ_V   = 2,
+    SZ_P   = 3,
+    SZ_WP  = 4,
+    SZ_DP  = 5,
+    SZ_MDQ = 6,
+    SZ_RDQ = 7,
+
+    /* the following values are used as is,
+     * and thus hard-coded. changing them 
+     * will break internals 
+     */
+    SZ_B   = 8,
+    SZ_W   = 16,
+    SZ_D   = 32,
+    SZ_Q   = 64,
+    SZ_T   = 80,
+};
+
+/* itab entry operand definitions */
+
+#define O_rSPr12  { OP_rSPr12,   SZ_NA    }
+#define O_BL      { OP_BL,       SZ_NA    }
+#define O_BH      { OP_BH,       SZ_NA    }
+#define O_BP      { OP_BP,       SZ_NA    }
+#define O_AHr12b  { OP_AHr12b,   SZ_NA    }
+#define O_BX      { OP_BX,       SZ_NA    }
+#define O_Jz      { OP_J,        SZ_Z     }
+#define O_Jv      { OP_J,        SZ_V     }
+#define O_Jb      { OP_J,        SZ_B     }
+#define O_rSIr14  { OP_rSIr14,   SZ_NA    }
+#define O_GS      { OP_GS,       SZ_NA    }
+#define O_D       { OP_D,        SZ_NA    }
+#define O_rBPr13  { OP_rBPr13,   SZ_NA    }
+#define O_Ob      { OP_O,        SZ_B     }
+#define O_P       { OP_P,        SZ_NA    }
+#define O_Ow      { OP_O,        SZ_W     }
+#define O_Ov      { OP_O,        SZ_V     }
+#define O_Gw      { OP_G,        SZ_W     }
+#define O_Gv      { OP_G,        SZ_V     }
+#define O_rDX     { OP_rDX,      SZ_NA    }
+#define O_Gx      { OP_G,        SZ_MDQ   }
+#define O_Gd      { OP_G,        SZ_D     }
+#define O_Gb      { OP_G,        SZ_B     }
+#define O_rBXr11  { OP_rBXr11,   SZ_NA    }
+#define O_rDI     { OP_rDI,      SZ_NA    }
+#define O_rSI     { OP_rSI,      SZ_NA    }
+#define O_ALr8b   { OP_ALr8b,    SZ_NA    }
+#define O_eDI     { OP_eDI,      SZ_NA    }
+#define O_Gz      { OP_G,        SZ_Z     }
+#define O_eDX     { OP_eDX,      SZ_NA    }
+#define O_DHr14b  { OP_DHr14b,   SZ_NA    }
+#define O_rSP     { OP_rSP,      SZ_NA    }
+#define O_PR      { OP_PR,       SZ_NA    }
+#define O_NONE    { OP_NONE,     SZ_NA    }
+#define O_rCX     { OP_rCX,      SZ_NA    }
+#define O_jWP     { OP_J,        SZ_WP    }
+#define O_rDXr10  { OP_rDXr10,   SZ_NA    }
+#define O_Md      { OP_M,        SZ_D     }
+#define O_C       { OP_C,        SZ_NA    }
+#define O_G       { OP_G,        SZ_NA    }
+#define O_Mb      { OP_M,        SZ_B     }
+#define O_Mt      { OP_M,        SZ_T     }
+#define O_S       { OP_S,        SZ_NA    }
+#define O_Mq      { OP_M,        SZ_Q     }
+#define O_W       { OP_W,        SZ_NA    }
+#define O_ES      { OP_ES,       SZ_NA    }
+#define O_rBX     { OP_rBX,      SZ_NA    }
+#define O_Ed      { OP_E,        SZ_D     }
+#define O_DLr10b  { OP_DLr10b,   SZ_NA    }
+#define O_Mw      { OP_M,        SZ_W     }
+#define O_Eb      { OP_E,        SZ_B     }
+#define O_Ex      { OP_E,        SZ_MDQ   }
+#define O_Ez      { OP_E,        SZ_Z     }
+#define O_Ew      { OP_E,        SZ_W     }
+#define O_Ev      { OP_E,        SZ_V     }
+#define O_Ep      { OP_E,        SZ_P     }
+#define O_FS      { OP_FS,       SZ_NA    }
+#define O_Ms      { OP_M,        SZ_W     }
+#define O_rAXr8   { OP_rAXr8,    SZ_NA    }
+#define O_eBP     { OP_eBP,      SZ_NA    }
+#define O_Isb     { OP_I,        SZ_SB    }
+#define O_eBX     { OP_eBX,      SZ_NA    }
+#define O_rCXr9   { OP_rCXr9,    SZ_NA    }
+#define O_jDP     { OP_J,        SZ_DP    }
+#define O_CH      { OP_CH,       SZ_NA    }
+#define O_CL      { OP_CL,       SZ_NA    }
+#define O_R       { OP_R,        SZ_RDQ   }
+#define O_V       { OP_V,        SZ_NA    }
+#define O_CS      { OP_CS,       SZ_NA    }
+#define O_CHr13b  { OP_CHr13b,   SZ_NA    }
+#define O_eCX     { OP_eCX,      SZ_NA    }
+#define O_eSP     { OP_eSP,      SZ_NA    }
+#define O_SS      { OP_SS,       SZ_NA    }
+#define O_SP      { OP_SP,       SZ_NA    }
+#define O_BLr11b  { OP_BLr11b,   SZ_NA    }
+#define O_SI      { OP_SI,       SZ_NA    }
+#define O_eSI     { OP_eSI,      SZ_NA    }
+#define O_DL      { OP_DL,       SZ_NA    }
+#define O_DH      { OP_DH,       SZ_NA    }
+#define O_DI      { OP_DI,       SZ_NA    }
+#define O_DX      { OP_DX,       SZ_NA    }
+#define O_rBP     { OP_rBP,      SZ_NA    }
+#define O_Gvw     { OP_G,        SZ_MDQ   }
+#define O_I1      { OP_I1,       SZ_NA    }
+#define O_I3      { OP_I3,       SZ_NA    }
+#define O_DS      { OP_DS,       SZ_NA    }
+#define O_ST4     { OP_ST4,      SZ_NA    }
+#define O_ST5     { OP_ST5,      SZ_NA    }
+#define O_ST6     { OP_ST6,      SZ_NA    }
+#define O_ST7     { OP_ST7,      SZ_NA    }
+#define O_ST0     { OP_ST0,      SZ_NA    }
+#define O_ST1     { OP_ST1,      SZ_NA    }
+#define O_ST2     { OP_ST2,      SZ_NA    }
+#define O_ST3     { OP_ST3,      SZ_NA    }
+#define O_E       { OP_E,        SZ_NA    }
+#define O_AH      { OP_AH,       SZ_NA    }
+#define O_M       { OP_M,        SZ_NA    }
+#define O_AL      { OP_AL,       SZ_NA    }
+#define O_CLr9b   { OP_CLr9b,    SZ_NA    }
+#define O_Q       { OP_Q,        SZ_NA    }
+#define O_eAX     { OP_eAX,      SZ_NA    }
+#define O_VR      { OP_VR,       SZ_NA    }
+#define O_AX      { OP_AX,       SZ_NA    }
+#define O_rAX     { OP_rAX,      SZ_NA    }
+#define O_Iz      { OP_I,        SZ_Z     }
+#define O_rDIr15  { OP_rDIr15,   SZ_NA    }
+#define O_Iw      { OP_I,        SZ_W     }
+#define O_Iv      { OP_I,        SZ_V     }
+#define O_Ap      { OP_A,        SZ_P     }
+#define O_CX      { OP_CX,       SZ_NA    }
+#define O_Ib      { OP_I,        SZ_B     }
+#define O_BHr15b  { OP_BHr15b,   SZ_NA    }
+
+
+/* A single operand of an entry in the instruction table. 
+ * (internal use only)
+ */
+struct ud_itab_entry_operand 
+{
+  enum ud_operand_code type;
+  enum ud_operand_size size;
+};
+
+
+/* A single entry in an instruction table. 
+ *(internal use only)
+ */
+struct ud_itab_entry 
+{
+  enum ud_mnemonic_code         mnemonic;
+  struct ud_itab_entry_operand  operand1;
+  struct ud_itab_entry_operand  operand2;
+  struct ud_itab_entry_operand  operand3;
+  uint32_t                      prefix;
+};
+
+#endif /* UD_DECODE_H */
+
+/* vim:cindent
+ * vim:expandtab
+ * vim:ts=4
+ * vim:sw=4
+ */
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/extern.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,67 @@
+/* -----------------------------------------------------------------------------
+ * extern.h
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_EXTERN_H
+#define UD_EXTERN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #include <stdio.h> */
+#include "types.h"
+
+/* ============================= PUBLIC API ================================= */
+
+extern void ud_init(struct ud*);
+
+extern void ud_set_mode(struct ud*, uint8_t);
+
+extern void ud_set_pc(struct ud*, uint64_t);
+
+extern void ud_set_input_hook(struct ud*, int (*)(struct ud*));
+
+extern void ud_set_input_buffer(struct ud*, uint8_t*, size_t);
+
+#ifndef __UD_STANDALONE__
+extern void ud_set_input_file(struct ud*, FILE*);
+#endif /* __UD_STANDALONE__ */
+
+extern void ud_set_vendor(struct ud*, unsigned);
+
+extern void ud_set_syntax(struct ud*, void (*)(struct ud*));
+
+extern void ud_input_skip(struct ud*, size_t);
+
+extern int ud_input_end(struct ud*);
+
+extern unsigned int ud_decode(struct ud*);
+
+extern unsigned int ud_disassemble(struct ud*);
+
+extern void ud_translate_intel(struct ud*);
+
+extern void ud_translate_att(struct ud*);
+
+extern char* ud_insn_asm(struct ud* u);
+
+extern uint8_t* ud_insn_ptr(struct ud* u);
+
+extern uint64_t ud_insn_off(struct ud*);
+
+extern char* ud_insn_hex(struct ud*);
+
+extern unsigned int ud_insn_len(struct ud* u);
+
+extern const char* ud_lookup_mnemonic(enum ud_mnemonic_code c);
+
+/* ========================================================================== */
+
+#ifdef __cplusplus
+}
+#endif
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/input.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,226 @@
+/* -----------------------------------------------------------------------------
+ * input.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#include "extern.h"
+#include "types.h"
+#include "input.h"
+
+/* -----------------------------------------------------------------------------
+ * inp_buff_hook() - Hook for buffered inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_buff_hook(struct ud* u)
+{
+  if (u->inp_buff < u->inp_buff_end)
+	return *u->inp_buff++;
+  else	return -1;
+}
+
+#ifndef __UD_STANDALONE__
+/* -----------------------------------------------------------------------------
+ * inp_file_hook() - Hook for FILE inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_file_hook(struct ud* u)
+{
+  return fgetc(u->inp_file);
+}
+#endif /* __UD_STANDALONE__*/
+
+/* =============================================================================
+ * ud_inp_set_hook() - Sets input hook.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_hook(register struct ud* u, int (*hook)(struct ud*))
+{
+  u->inp_hook = hook;
+  inp_init(u);
+}
+
+/* =============================================================================
+ * ud_inp_set_buffer() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_buffer(register struct ud* u, uint8_t* buf, size_t len)
+{
+  u->inp_hook = inp_buff_hook;
+  u->inp_buff = buf;
+  u->inp_buff_end = buf + len;
+  inp_init(u);
+}
+
+#ifndef __UD_STANDALONE__
+/* =============================================================================
+ * ud_input_set_file() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_file(register struct ud* u, FILE* f)
+{
+  u->inp_hook = inp_file_hook;
+  u->inp_file = f;
+  inp_init(u);
+}
+#endif /* __UD_STANDALONE__ */
+
+/* =============================================================================
+ * ud_input_skip() - Skip n input bytes.
+ * =============================================================================
+ */
+extern void 
+ud_input_skip(struct ud* u, size_t n)
+{
+  while (n--) {
+	u->inp_hook(u);
+  }
+}
+
+/* =============================================================================
+ * ud_input_end() - Test for end of input.
+ * =============================================================================
+ */
+extern int 
+ud_input_end(struct ud* u)
+{
+  return (u->inp_curr == u->inp_fill) && u->inp_end;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_next() - Loads and returns the next byte from input.
+ *
+ * inp_curr and inp_fill are pointers to the cache. The program is written based
+ * on the property that they are 8-bits in size, and will eventually wrap around
+ * forming a circular buffer. So, the size of the cache is 256 in size, kind of
+ * unnecessary yet optimized.
+ *
+ * A buffer inp_sess stores the bytes disassembled for a single session.
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t inp_next(struct ud* u) 
+{
+  int c = -1;
+  /* if current pointer is not upto the fill point in the 
+   * input cache.
+   */
+  if ( u->inp_curr != u->inp_fill ) {
+	c = u->inp_cache[ ++u->inp_curr ];
+  /* if !end-of-input, call the input hook and get a byte */
+  } else if ( u->inp_end || ( c = u->inp_hook( u ) ) == -1 ) {
+	/* end-of-input, mark it as an error, since the decoder,
+	 * expected a byte more.
+	 */
+	u->error = 1;
+	/* flag end of input */
+	u->inp_end = 1;
+	return 0;
+  } else {
+	/* increment pointers, we have a new byte.  */
+	u->inp_curr = ++u->inp_fill;
+	/* add the byte to the cache */
+	u->inp_cache[ u->inp_fill ] = c;
+  }
+  /* record bytes input per decode-session. */
+  u->inp_sess[ u->inp_ctr++ ] = c;
+  /* return byte */
+  return ( uint8_t ) c;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_back() - Move back a single byte in the stream.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_back(struct ud* u) 
+{
+  if ( u->inp_ctr > 0 ) {
+	--u->inp_curr;
+	--u->inp_ctr;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_peek() - Peek into the next byte in source. 
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t
+inp_peek(struct ud* u) 
+{
+  uint8_t r = inp_next(u);
+  if ( !u->error ) inp_back(u); /* Don't backup if there was an error */
+  return r;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_move() - Move ahead n input bytes.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_move(struct ud* u, size_t n) 
+{
+  while (n--)
+	inp_next(u);
+}
+
+/*------------------------------------------------------------------------------
+ *  inp_uintN() - return uintN from source.
+ *------------------------------------------------------------------------------
+ */
+extern uint8_t 
+inp_uint8(struct ud* u)
+{
+  return inp_next(u);
+}
+
+extern uint16_t 
+inp_uint16(struct ud* u)
+{
+  uint16_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  return ret | (r << 8);
+}
+
+extern uint32_t 
+inp_uint32(struct ud* u)
+{
+  uint32_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  return ret | (r << 24);
+}
+
+extern uint64_t 
+inp_uint64(struct ud* u)
+{
+  uint64_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  ret = ret | (r << 24);
+  r = inp_next(u);
+  ret = ret | (r << 32);
+  r = inp_next(u);
+  ret = ret | (r << 40);
+  r = inp_next(u);
+  ret = ret | (r << 48);
+  r = inp_next(u);
+  return ret | (r << 56);
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/input.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,49 @@
+/* -----------------------------------------------------------------------------
+ * input.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_INPUT_H
+#define UD_INPUT_H
+
+#include "types.h"
+
+uint8_t inp_next(struct ud*);
+uint8_t inp_peek(struct ud*);
+uint8_t inp_uint8(struct ud*);
+uint16_t inp_uint16(struct ud*);
+uint32_t inp_uint32(struct ud*);
+uint64_t inp_uint64(struct ud*);
+void inp_move(struct ud*, size_t);
+void inp_back(struct ud*);
+
+/* inp_init() - Initializes the input system. */
+#define inp_init(u) \
+do { \
+  u->inp_curr = 0; \
+  u->inp_fill = 0; \
+  u->inp_ctr  = 0; \
+  u->inp_end  = 0; \
+} while (0)
+
+/* inp_start() - Should be called before each de-code operation. */
+#define inp_start(u) u->inp_ctr = 0
+
+/* inp_back() - Resets the current pointer to its position before the current
+ * instruction disassembly was started.
+ */
+#define inp_reset(u) \
+do { \
+  u->inp_curr -= u->inp_ctr; \
+  u->inp_ctr = 0; \
+} while (0)
+
+/* inp_sess() - Returns the pointer to current session. */
+#define inp_sess(u) (u->inp_sess)
+
+/* inp_cur() - Returns the current input byte. */
+#define inp_curr(u) ((u)->inp_cache[(u)->inp_curr])
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/itab.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3668 @@
+
+/* itab.c -- auto generated by opgen.py, do not edit. */
+
+#include "types.h"
+#include "decode.h"
+#include "itab.h"
+
+const char * ud_mnemonics_str[] = {
+  "3dnow",
+  "aaa",
+  "aad",
+  "aam",
+  "aas",
+  "adc",
+  "add",
+  "addpd",
+  "addps",
+  "addsd",
+  "addss",
+  "addsubpd",
+  "addsubps",
+  "and",
+  "andpd",
+  "andps",
+  "andnpd",
+  "andnps",
+  "arpl",
+  "movsxd",
+  "bound",
+  "bsf",
+  "bsr",
+  "bswap",
+  "bt",
+  "btc",
+  "btr",
+  "bts",
+  "call",
+  "cbw",
+  "cwde",
+  "cdqe",
+  "clc",
+  "cld",
+  "clflush",
+  "clgi",
+  "cli",
+  "clts",
+  "cmc",
+  "cmovo",
+  "cmovno",
+  "cmovb",
+  "cmovae",
+  "cmovz",
+  "cmovnz",
+  "cmovbe",
+  "cmova",
+  "cmovs",
+  "cmovns",
+  "cmovp",
+  "cmovnp",
+  "cmovl",
+  "cmovge",
+  "cmovle",
+  "cmovg",
+  "cmp",
+  "cmppd",
+  "cmpps",
+  "cmpsb",
+  "cmpsw",
+  "cmpsd",
+  "cmpsq",
+  "cmpss",
+  "cmpxchg",
+  "cmpxchg8b",
+  "comisd",
+  "comiss",
+  "cpuid",
+  "cvtdq2pd",
+  "cvtdq2ps",
+  "cvtpd2dq",
+  "cvtpd2pi",
+  "cvtpd2ps",
+  "cvtpi2ps",
+  "cvtpi2pd",
+  "cvtps2dq",
+  "cvtps2pi",
+  "cvtps2pd",
+  "cvtsd2si",
+  "cvtsd2ss",
+  "cvtsi2ss",
+  "cvtss2si",
+  "cvtss2sd",
+  "cvttpd2pi",
+  "cvttpd2dq",
+  "cvttps2dq",
+  "cvttps2pi",
+  "cvttsd2si",
+  "cvtsi2sd",
+  "cvttss2si",
+  "cwd",
+  "cdq",
+  "cqo",
+  "daa",
+  "das",
+  "dec",
+  "div",
+  "divpd",
+  "divps",
+  "divsd",
+  "divss",
+  "emms",
+  "enter",
+  "f2xm1",
+  "fabs",
+  "fadd",
+  "faddp",
+  "fbld",
+  "fbstp",
+  "fchs",
+  "fclex",
+  "fcmovb",
+  "fcmove",
+  "fcmovbe",
+  "fcmovu",
+  "fcmovnb",
+  "fcmovne",
+  "fcmovnbe",
+  "fcmovnu",
+  "fucomi",
+  "fcom",
+  "fcom2",
+  "fcomp3",
+  "fcomi",
+  "fucomip",
+  "fcomip",
+  "fcomp",
+  "fcomp5",
+  "fcompp",
+  "fcos",
+  "fdecstp",
+  "fdiv",
+  "fdivp",
+  "fdivr",
+  "fdivrp",
+  "femms",
+  "ffree",
+  "ffreep",
+  "ficom",
+  "ficomp",
+  "fild",
+  "fncstp",
+  "fninit",
+  "fiadd",
+  "fidivr",
+  "fidiv",
+  "fisub",
+  "fisubr",
+  "fist",
+  "fistp",
+  "fisttp",
+  "fld",
+  "fld1",
+  "fldl2t",
+  "fldl2e",
+  "fldlpi",
+  "fldlg2",
+  "fldln2",
+  "fldz",
+  "fldcw",
+  "fldenv",
+  "fmul",
+  "fmulp",
+  "fimul",
+  "fnop",
+  "fpatan",
+  "fprem",
+  "fprem1",
+  "fptan",
+  "frndint",
+  "frstor",
+  "fnsave",
+  "fscale",
+  "fsin",
+  "fsincos",
+  "fsqrt",
+  "fstp",
+  "fstp1",
+  "fstp8",
+  "fstp9",
+  "fst",
+  "fnstcw",
+  "fnstenv",
+  "fnstsw",
+  "fsub",
+  "fsubp",
+  "fsubr",
+  "fsubrp",
+  "ftst",
+  "fucom",
+  "fucomp",
+  "fucompp",
+  "fxam",
+  "fxch",
+  "fxch4",
+  "fxch7",
+  "fxrstor",
+  "fxsave",
+  "fpxtract",
+  "fyl2x",
+  "fyl2xp1",
+  "haddpd",
+  "haddps",
+  "hlt",
+  "hsubpd",
+  "hsubps",
+  "idiv",
+  "in",
+  "imul",
+  "inc",
+  "insb",
+  "insw",
+  "insd",
+  "int1",
+  "int3",
+  "int",
+  "into",
+  "invd",
+  "invlpg",
+  "invlpga",
+  "iretw",
+  "iretd",
+  "iretq",
+  "jo",
+  "jno",
+  "jb",
+  "jae",
+  "jz",
+  "jnz",
+  "jbe",
+  "ja",
+  "js",
+  "jns",
+  "jp",
+  "jnp",
+  "jl",
+  "jge",
+  "jle",
+  "jg",
+  "jcxz",
+  "jecxz",
+  "jrcxz",
+  "jmp",
+  "lahf",
+  "lar",
+  "lddqu",
+  "ldmxcsr",
+  "lds",
+  "lea",
+  "les",
+  "lfs",
+  "lgs",
+  "lidt",
+  "lss",
+  "leave",
+  "lfence",
+  "lgdt",
+  "lldt",
+  "lmsw",
+  "lock",
+  "lodsb",
+  "lodsw",
+  "lodsd",
+  "lodsq",
+  "loopnz",
+  "loope",
+  "loop",
+  "lsl",
+  "ltr",
+  "maskmovq",
+  "maxpd",
+  "maxps",
+  "maxsd",
+  "maxss",
+  "mfence",
+  "minpd",
+  "minps",
+  "minsd",
+  "minss",
+  "monitor",
+  "mov",
+  "movapd",
+  "movaps",
+  "movd",
+  "movddup",
+  "movdqa",
+  "movdqu",
+  "movdq2q",
+  "movhpd",
+  "movhps",
+  "movlhps",
+  "movlpd",
+  "movlps",
+  "movhlps",
+  "movmskpd",
+  "movmskps",
+  "movntdq",
+  "movnti",
+  "movntpd",
+  "movntps",
+  "movntq",
+  "movq",
+  "movqa",
+  "movq2dq",
+  "movsb",
+  "movsw",
+  "movsd",
+  "movsq",
+  "movsldup",
+  "movshdup",
+  "movss",
+  "movsx",
+  "movupd",
+  "movups",
+  "movzx",
+  "mul",
+  "mulpd",
+  "mulps",
+  "mulsd",
+  "mulss",
+  "mwait",
+  "neg",
+  "nop",
+  "not",
+  "or",
+  "orpd",
+  "orps",
+  "out",
+  "outsb",
+  "outsw",
+  "outsd",
+  "outsq",
+  "packsswb",
+  "packssdw",
+  "packuswb",
+  "paddb",
+  "paddw",
+  "paddq",
+  "paddsb",
+  "paddsw",
+  "paddusb",
+  "paddusw",
+  "pand",
+  "pandn",
+  "pause",
+  "pavgb",
+  "pavgw",
+  "pcmpeqb",
+  "pcmpeqw",
+  "pcmpeqd",
+  "pcmpgtb",
+  "pcmpgtw",
+  "pcmpgtd",
+  "pextrw",
+  "pinsrw",
+  "pmaddwd",
+  "pmaxsw",
+  "pmaxub",
+  "pminsw",
+  "pminub",
+  "pmovmskb",
+  "pmulhuw",
+  "pmulhw",
+  "pmullw",
+  "pmuludq",
+  "pop",
+  "popa",
+  "popad",
+  "popfw",
+  "popfd",
+  "popfq",
+  "por",
+  "prefetch",
+  "prefetchnta",
+  "prefetcht0",
+  "prefetcht1",
+  "prefetcht2",
+  "psadbw",
+  "pshufd",
+  "pshufhw",
+  "pshuflw",
+  "pshufw",
+  "pslldq",
+  "psllw",
+  "pslld",
+  "psllq",
+  "psraw",
+  "psrad",
+  "psrlw",
+  "psrld",
+  "psrlq",
+  "psrldq",
+  "psubb",
+  "psubw",
+  "psubd",
+  "psubq",
+  "psubsb",
+  "psubsw",
+  "psubusb",
+  "psubusw",
+  "punpckhbw",
+  "punpckhwd",
+  "punpckhdq",
+  "punpckhqdq",
+  "punpcklbw",
+  "punpcklwd",
+  "punpckldq",
+  "punpcklqdq",
+  "pi2fw",
+  "pi2fd",
+  "pf2iw",
+  "pf2id",
+  "pfnacc",
+  "pfpnacc",
+  "pfcmpge",
+  "pfmin",
+  "pfrcp",
+  "pfrsqrt",
+  "pfsub",
+  "pfadd",
+  "pfcmpgt",
+  "pfmax",
+  "pfrcpit1",
+  "pfrspit1",
+  "pfsubr",
+  "pfacc",
+  "pfcmpeq",
+  "pfmul",
+  "pfrcpit2",
+  "pmulhrw",
+  "pswapd",
+  "pavgusb",
+  "push",
+  "pusha",
+  "pushad",
+  "pushfw",
+  "pushfd",
+  "pushfq",
+  "pxor",
+  "rcl",
+  "rcr",
+  "rol",
+  "ror",
+  "rcpps",
+  "rcpss",
+  "rdmsr",
+  "rdpmc",
+  "rdtsc",
+  "rdtscp",
+  "repne",
+  "rep",
+  "ret",
+  "retf",
+  "rsm",
+  "rsqrtps",
+  "rsqrtss",
+  "sahf",
+  "sal",
+  "salc",
+  "sar",
+  "shl",
+  "shr",
+  "sbb",
+  "scasb",
+  "scasw",
+  "scasd",
+  "scasq",
+  "seto",
+  "setno",
+  "setb",
+  "setnb",
+  "setz",
+  "setnz",
+  "setbe",
+  "seta",
+  "sets",
+  "setns",
+  "setp",
+  "setnp",
+  "setl",
+  "setge",
+  "setle",
+  "setg",
+  "sfence",
+  "sgdt",
+  "shld",
+  "shrd",
+  "shufpd",
+  "shufps",
+  "sidt",
+  "sldt",
+  "smsw",
+  "sqrtps",
+  "sqrtpd",
+  "sqrtsd",
+  "sqrtss",
+  "stc",
+  "std",
+  "stgi",
+  "sti",
+  "skinit",
+  "stmxcsr",
+  "stosb",
+  "stosw",
+  "stosd",
+  "stosq",
+  "str",
+  "sub",
+  "subpd",
+  "subps",
+  "subsd",
+  "subss",
+  "swapgs",
+  "syscall",
+  "sysenter",
+  "sysexit",
+  "sysret",
+  "test",
+  "ucomisd",
+  "ucomiss",
+  "ud2",
+  "unpckhpd",
+  "unpckhps",
+  "unpcklps",
+  "unpcklpd",
+  "verr",
+  "verw",
+  "vmcall",
+  "vmclear",
+  "vmxon",
+  "vmptrld",
+  "vmptrst",
+  "vmresume",
+  "vmxoff",
+  "vmrun",
+  "vmmcall",
+  "vmload",
+  "vmsave",
+  "wait",
+  "wbinvd",
+  "wrmsr",
+  "xadd",
+  "xchg",
+  "xlatb",
+  "xor",
+  "xorpd",
+  "xorps",
+  "db",
+  "invalid",
+};
+
+
+
+static struct ud_itab_entry itab__0f[256] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_00__REG },
+  /* 01 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG },
+  /* 02 */  { UD_Ilar,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ilsl,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Isyscall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iclts,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isysret,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Iinvd,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Iwbinvd,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iud2,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_0D__REG },
+  /* 0E */  { UD_Ifemms,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovups,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovups,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_18__REG },
+  /* 19 */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1D */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1E */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1F */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 20 */  { UD_Imov,         O_R,     O_C,     O_NONE,  P_rexr },
+  /* 21 */  { UD_Imov,         O_R,     O_D,     O_NONE,  P_rexr },
+  /* 22 */  { UD_Imov,         O_C,     O_R,     O_NONE,  P_rexr },
+  /* 23 */  { UD_Imov,         O_D,     O_R,     O_NONE,  P_rexr },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovaps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovaps,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2ps,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntps,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttps2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtps2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomiss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomiss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iwrmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Irdtsc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Irdmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Irdpmc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Isysenter,    O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 35 */  { UD_Isysexit,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Icmovo,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 41 */  { UD_Icmovno,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 42 */  { UD_Icmovb,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 43 */  { UD_Icmovae,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 44 */  { UD_Icmovz,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 45 */  { UD_Icmovnz,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 46 */  { UD_Icmovbe,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 47 */  { UD_Icmova,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 48 */  { UD_Icmovs,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 49 */  { UD_Icmovns,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4A */  { UD_Icmovp,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4B */  { UD_Icmovnp,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4C */  { UD_Icmovl,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4D */  { UD_Icmovge,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4E */  { UD_Icmovle,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4F */  { UD_Icmovg,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 50 */  { UD_Imovmskps,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtps,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iandps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorps,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtps2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtdq2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Imovd,        O_P,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovq,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufw,      O_P,     O_Q,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iemms,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_P,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovq,        O_Q,     O_P,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Ijo,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 81 */  { UD_Ijno,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 82 */  { UD_Ijb,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 83 */  { UD_Ijae,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 84 */  { UD_Ijz,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 85 */  { UD_Ijnz,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 86 */  { UD_Ijbe,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 87 */  { UD_Ija,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 88 */  { UD_Ijs,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 89 */  { UD_Ijns,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8A */  { UD_Ijp,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8B */  { UD_Ijnp,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8C */  { UD_Ijl,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8D */  { UD_Ijge,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8E */  { UD_Ijle,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8F */  { UD_Ijg,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 90 */  { UD_Iseto,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 91 */  { UD_Isetno,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 92 */  { UD_Isetb,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 93 */  { UD_Isetnb,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 94 */  { UD_Isetz,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 95 */  { UD_Isetnz,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 96 */  { UD_Isetbe,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 97 */  { UD_Iseta,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 98 */  { UD_Isets,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 99 */  { UD_Isetns,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9A */  { UD_Isetp,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9B */  { UD_Isetnp,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9C */  { UD_Isetl,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9D */  { UD_Isetge,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9E */  { UD_Isetle,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9F */  { UD_Isetg,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* A0 */  { UD_Ipush,        O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A1 */  { UD_Ipop,         O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A2 */  { UD_Icpuid,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A3 */  { UD_Ibt,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A4 */  { UD_Ishld,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A5 */  { UD_Ishld,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Ipush,        O_GS,    O_NONE,  O_NONE,  P_none },
+  /* A9 */  { UD_Ipop,         O_GS,    O_NONE,  O_NONE,  P_none },
+  /* AA */  { UD_Irsm,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AB */  { UD_Ibts,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AC */  { UD_Ishrd,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AD */  { UD_Ishrd,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG },
+  /* AF */  { UD_Iimul,        O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B0 */  { UD_Icmpxchg,     O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* B1 */  { UD_Icmpxchg,     O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B2 */  { UD_Ilss,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B3 */  { UD_Ibtr,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B4 */  { UD_Ilfs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B5 */  { UD_Ilgs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B6 */  { UD_Imovzx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B7 */  { UD_Imovzx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_BA__REG },
+  /* BB */  { UD_Ibtc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BC */  { UD_Ibsf,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BD */  { UD_Ibsr,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BE */  { UD_Imovsx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BF */  { UD_Imovsx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpps,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Imovnti,      O_M,     O_Gvw,   O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C4 */  { UD_Ipinsrw,      O_P,     O_Ew,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_PR,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C6 */  { UD_Ishufps,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG },
+  /* C8 */  { UD_Ibswap,       O_rAXr8, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* C9 */  { UD_Ibswap,       O_rCXr9, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* CA */  { UD_Ibswap,       O_rDXr10, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CB */  { UD_Ibswap,       O_rBXr11, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CC */  { UD_Ibswap,       O_rSPr12, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CD */  { UD_Ibswap,       O_rBPr13, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CE */  { UD_Ibswap,       O_rSIr14, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CF */  { UD_Ibswap,       O_rDIr15, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Ipsrlw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_PR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipaddusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipaddusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Imovntq,      O_M,     O_P,     O_NONE,  P_none },
+  /* E8 */  { UD_Ipsubsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_00__reg[8] = {
+  /* 00 */  { UD_Isldt,        O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Istr,         O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Illdt,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iltr,         O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iverr,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iverw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg[8] = {
+  /* 00 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD },
+  /* 01 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD },
+  /* 02 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_02__MOD },
+  /* 03 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD },
+  /* 04 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_04__MOD },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod[2] = {
+  /* 00 */  { UD_Isgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmcall,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmresume,    O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxoff,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod[2] = {
+  /* 00 */  { UD_Isidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imonitor,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imwait,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_02__mod[2] = {
+  /* 00 */  { UD_Ilgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod[2] = {
+  /* 00 */  { UD_Ilidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR },
+  /* 06 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor[2] = {
+  /* 00 */  { UD_Ivmrun,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Ivmmcall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor[2] = {
+  /* 00 */  { UD_Ivmload,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Ivmsave,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Istgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor[2] = {
+  /* 00 */  { UD_Iclgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor[2] = {
+  /* 00 */  { UD_Iskinit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvlpga,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_04__mod[2] = {
+  /* 00 */  { UD_Ismsw,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Ilmsw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iinvlpg,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iswapgs,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Irdtscp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_0d__reg[8] = {
+  /* 00 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_18__reg[8] = {
+  /* 00 */  { UD_Iprefetchnta, O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetcht0,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetcht1,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetcht2,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ildmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Istmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iclflush,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ba__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ibt,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ibts,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ibtr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ibtc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Icmpxchg8b,   O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrld,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrst,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Ifabs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_If2xm1,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte[256] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iadd,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadd,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iadd,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iadd,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iadd,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 06 */  { UD_Ipush,        O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 07 */  { UD_Ipop,         O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 08 */  { UD_Ior,          O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 09 */  { UD_Ior,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0A */  { UD_Ior,          O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 0B */  { UD_Ior,          O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0C */  { UD_Ior,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 0D */  { UD_Ior,          O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 0E */  { UD_Ipush,        O_CS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iadc,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Iadc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Iadc,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iadc,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iadc,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 15 */  { UD_Iadc,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 16 */  { UD_Ipush,        O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 17 */  { UD_Ipop,         O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 18 */  { UD_Isbb,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 19 */  { UD_Isbb,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Isbb,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Isbb,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Isbb,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 1D */  { UD_Isbb,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 1E */  { UD_Ipush,        O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 1F */  { UD_Ipop,         O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 20 */  { UD_Iand,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 21 */  { UD_Iand,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 22 */  { UD_Iand,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 23 */  { UD_Iand,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 24 */  { UD_Iand,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 25 */  { UD_Iand,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Idaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 28 */  { UD_Isub,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Isub,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Isub,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Isub,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Isub,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 2D */  { UD_Isub,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Idas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 30 */  { UD_Ixor,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 31 */  { UD_Ixor,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 32 */  { UD_Ixor,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 33 */  { UD_Ixor,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 34 */  { UD_Ixor,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 35 */  { UD_Ixor,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iaaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 38 */  { UD_Icmp,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 39 */  { UD_Icmp,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3A */  { UD_Icmp,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 3B */  { UD_Icmp,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3C */  { UD_Icmp,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 3D */  { UD_Icmp,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iaas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 40 */  { UD_Iinc,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 41 */  { UD_Iinc,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 42 */  { UD_Iinc,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 43 */  { UD_Iinc,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 44 */  { UD_Iinc,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 45 */  { UD_Iinc,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 46 */  { UD_Iinc,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 47 */  { UD_Iinc,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 48 */  { UD_Idec,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 49 */  { UD_Idec,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 4A */  { UD_Idec,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 4B */  { UD_Idec,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 4C */  { UD_Idec,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 4D */  { UD_Idec,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 4E */  { UD_Idec,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 4F */  { UD_Idec,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 50 */  { UD_Ipush,        O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 51 */  { UD_Ipush,        O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 52 */  { UD_Ipush,        O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 53 */  { UD_Ipush,        O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 54 */  { UD_Ipush,        O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 55 */  { UD_Ipush,        O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 56 */  { UD_Ipush,        O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 57 */  { UD_Ipush,        O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 58 */  { UD_Ipop,         O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 59 */  { UD_Ipop,         O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 5A */  { UD_Ipop,         O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5B */  { UD_Ipop,         O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5C */  { UD_Ipop,         O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5D */  { UD_Ipop,         O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5E */  { UD_Ipop,         O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5F */  { UD_Ipop,         O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 60 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_60__OSIZE },
+  /* 61 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_61__OSIZE },
+  /* 62 */  { UD_Ibound,       O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* 63 */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_63__MODE },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Ipush,        O_Iz,    O_NONE,  O_NONE,  P_c1|P_oso },
+  /* 69 */  { UD_Iimul,        O_Gv,    O_Ev,    O_Iz,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipush,        O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* 6B */  { UD_Iimul,        O_Gv,    O_Ev,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinsb,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6D */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6D__OSIZE },
+  /* 6E */  { UD_Ioutsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6F */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6F__OSIZE },
+  /* 70 */  { UD_Ijo,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 71 */  { UD_Ijno,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 72 */  { UD_Ijb,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 73 */  { UD_Ijae,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 74 */  { UD_Ijz,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 75 */  { UD_Ijnz,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 76 */  { UD_Ijbe,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 77 */  { UD_Ija,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Ijs,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 79 */  { UD_Ijns,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7A */  { UD_Ijp,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7B */  { UD_Ijnp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7C */  { UD_Ijl,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7D */  { UD_Ijge,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7E */  { UD_Ijle,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7F */  { UD_Ijg,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 80 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_80__REG },
+  /* 81 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_81__REG },
+  /* 82 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_82__REG },
+  /* 83 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_83__REG },
+  /* 84 */  { UD_Itest,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 85 */  { UD_Itest,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 86 */  { UD_Ixchg,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 87 */  { UD_Ixchg,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 88 */  { UD_Imov,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 89 */  { UD_Imov,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8A */  { UD_Imov,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 8B */  { UD_Imov,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8C */  { UD_Imov,         O_Ev,    O_S,     O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8D */  { UD_Ilea,         O_Gv,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8E */  { UD_Imov,         O_S,     O_Ev,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8F */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_8F__REG },
+  /* 90 */  { UD_Ixchg,        O_rAXr8, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 91 */  { UD_Ixchg,        O_rCXr9, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 92 */  { UD_Ixchg,        O_rDXr10, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 93 */  { UD_Ixchg,        O_rBXr11, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 94 */  { UD_Ixchg,        O_rSPr12, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 95 */  { UD_Ixchg,        O_rBPr13, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 96 */  { UD_Ixchg,        O_rSIr14, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 97 */  { UD_Ixchg,        O_rDIr15, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 98 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_98__OSIZE },
+  /* 99 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_99__OSIZE },
+  /* 9A */  { UD_Icall,        O_Ap,    O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 9B */  { UD_Iwait,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9C */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE },
+  /* 9D */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE },
+  /* 9E */  { UD_Isahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9F */  { UD_Ilahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A0 */  { UD_Imov,         O_AL,    O_Ob,    O_NONE,  P_none },
+  /* A1 */  { UD_Imov,         O_rAX,   O_Ov,    O_NONE,  P_aso|P_oso|P_rexw },
+  /* A2 */  { UD_Imov,         O_Ob,    O_AL,    O_NONE,  P_none },
+  /* A3 */  { UD_Imov,         O_Ov,    O_rAX,   O_NONE,  P_aso|P_oso|P_rexw },
+  /* A4 */  { UD_Imovsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* A5 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A5__OSIZE },
+  /* A6 */  { UD_Icmpsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A7 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A7__OSIZE },
+  /* A8 */  { UD_Itest,        O_AL,    O_Ib,    O_NONE,  P_none },
+  /* A9 */  { UD_Itest,        O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* AA */  { UD_Istosb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AB */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AB__OSIZE },
+  /* AC */  { UD_Ilodsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AD */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AD__OSIZE },
+  /* AE */  { UD_Iscasb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AF__OSIZE },
+  /* B0 */  { UD_Imov,         O_ALr8b, O_Ib,    O_NONE,  P_rexb },
+  /* B1 */  { UD_Imov,         O_CLr9b, O_Ib,    O_NONE,  P_rexb },
+  /* B2 */  { UD_Imov,         O_DLr10b, O_Ib,    O_NONE, P_rexb },
+  /* B3 */  { UD_Imov,         O_BLr11b, O_Ib,    O_NONE, P_rexb },
+  /* B4 */  { UD_Imov,         O_AHr12b, O_Ib,    O_NONE, P_rexb },
+  /* B5 */  { UD_Imov,         O_CHr13b, O_Ib,    O_NONE, P_rexb },
+  /* B6 */  { UD_Imov,         O_DHr14b, O_Ib,    O_NONE, P_rexb },
+  /* B7 */  { UD_Imov,         O_BHr15b, O_Ib,    O_NONE, P_rexb },
+  /* B8 */  { UD_Imov,         O_rAXr8, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* B9 */  { UD_Imov,         O_rCXr9, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* BA */  { UD_Imov,         O_rDXr10, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BB */  { UD_Imov,         O_rBXr11, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BC */  { UD_Imov,         O_rSPr12, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BD */  { UD_Imov,         O_rBPr13, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BE */  { UD_Imov,         O_rSIr14, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BF */  { UD_Imov,         O_rDIr15, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* C0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C0__REG },
+  /* C1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C1__REG },
+  /* C2 */  { UD_Iret,         O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* C3 */  { UD_Iret,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* C4 */  { UD_Iles,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C5 */  { UD_Ilds,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C6__REG },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C7__REG },
+  /* C8 */  { UD_Ienter,       O_Iw,    O_Ib,    O_NONE,  P_def64|P_depM|P_none },
+  /* C9 */  { UD_Ileave,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CA */  { UD_Iretf,        O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* CB */  { UD_Iretf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CC */  { UD_Iint3,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CD */  { UD_Iint,         O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* CE */  { UD_Iinto,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* CF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_CF__OSIZE },
+  /* D0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D0__REG },
+  /* D1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D1__REG },
+  /* D2 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D2__REG },
+  /* D3 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D3__REG },
+  /* D4 */  { UD_Iaam,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D5 */  { UD_Iaad,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D6 */  { UD_Isalc,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D7 */  { UD_Ixlatb,       O_NONE,  O_NONE,  O_NONE,  P_rexw },
+  /* D8 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD },
+  /* D9 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD },
+  /* DA */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD },
+  /* DB */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD },
+  /* DC */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD },
+  /* DD */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD },
+  /* DE */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD },
+  /* DF */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD },
+  /* E0 */  { UD_Iloopnz,      O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E1 */  { UD_Iloope,       O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E2 */  { UD_Iloop,        O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E3 */  { UD_Igrp_asize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_E3__ASIZE },
+  /* E4 */  { UD_Iin,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* E5 */  { UD_Iin,          O_eAX,   O_Ib,    O_NONE,  P_oso },
+  /* E6 */  { UD_Iout,         O_Ib,    O_AL,    O_NONE,  P_none },
+  /* E7 */  { UD_Iout,         O_Ib,    O_eAX,   O_NONE,  P_oso },
+  /* E8 */  { UD_Icall,        O_Jz,    O_NONE,  O_NONE,  P_def64|P_oso },
+  /* E9 */  { UD_Ijmp,         O_Jz,    O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* EA */  { UD_Ijmp,         O_Ap,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* EB */  { UD_Ijmp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* EC */  { UD_Iin,          O_AL,    O_DX,    O_NONE,  P_none },
+  /* ED */  { UD_Iin,          O_eAX,   O_DX,    O_NONE,  P_oso },
+  /* EE */  { UD_Iout,         O_DX,    O_AL,    O_NONE,  P_none },
+  /* EF */  { UD_Iout,         O_DX,    O_eAX,   O_NONE,  P_oso },
+  /* F0 */  { UD_Ilock,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F1 */  { UD_Iint1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F2 */  { UD_Irepne,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F3 */  { UD_Irep,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F4 */  { UD_Ihlt,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F5 */  { UD_Icmc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F6__REG },
+  /* F7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F7__REG },
+  /* F8 */  { UD_Iclc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F9 */  { UD_Istc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FA */  { UD_Icli,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FB */  { UD_Isti,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FC */  { UD_Icld,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FD */  { UD_Istd,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FE__REG },
+  /* FF */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FF__REG },
+};
+
+static struct ud_itab_entry itab__1byte__op_60__osize[3] = {
+  /* 00 */  { UD_Ipusha,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipushad,      O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_61__osize[3] = {
+  /* 00 */  { UD_Ipopa,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipopad,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_63__mode[3] = {
+  /* 00 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 01 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 02 */  { UD_Imovsxd,      O_Gv,    O_Ed,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexx|P_rexr|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_6d__osize[3] = {
+  /* 00 */  { UD_Iinsw,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Iinsd,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_6f__osize[3] = {
+  /* 00 */  { UD_Ioutsw,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Ioutsd,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Ioutsq,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_80__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_81__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_82__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_83__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_8f__reg[8] = {
+  /* 00 */  { UD_Ipop,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_98__osize[3] = {
+  /* 00 */  { UD_Icbw,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icwde,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icdqe,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_99__osize[3] = {
+  /* 00 */  { UD_Icwd,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icdq,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icqo,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipushfq,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipopfq,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_a5__osize[3] = {
+  /* 00 */  { UD_Imovsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Imovsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Imovsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_a7__osize[3] = {
+  /* 00 */  { UD_Icmpsw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icmpsd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icmpsq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ab__osize[3] = {
+  /* 00 */  { UD_Istosw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Istosd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Istosq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ad__osize[3] = {
+  /* 00 */  { UD_Ilodsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Ilodsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Ilodsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AE__MOD__OP_00__REG },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifxsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifxrstor,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_af__osize[3] = {
+  /* 00 */  { UD_Iscasw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iscasd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iscasq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_c0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c6__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_c7__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_cf__osize[3] = {
+  /* 00 */  { UD_Iiretw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iiretd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iiretq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_d0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d2__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d3__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsub,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsub,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsub,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsub,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsub,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsub,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsub,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdiv,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdiv,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdiv,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdiv,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdiv,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdiv,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdiv,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ifst,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifldenv,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifldcw,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifnstenv,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstcw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifld,         O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifld,         O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifld,         O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifld,         O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifld,         O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifld,         O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifld,         O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifld,         O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifnop,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Ifstp1,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp1,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp1,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp1,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp1,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp1,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp1,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp1,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifchs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iftst,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifxam,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifld1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifldl2t,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifldl2e,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifldlpi,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifldlg2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifldln2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifldz,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Ifyl2x,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Ifptan,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Ifpatan,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Ifpxtract,    O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 35 */  { UD_Ifprem1,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Ifdecstp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 37 */  { UD_Ifncstp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 38 */  { UD_Ifprem,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 39 */  { UD_Ifyl2xp1,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3A */  { UD_Ifsqrt,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3B */  { UD_Ifsincos,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3C */  { UD_Ifrndint,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3D */  { UD_Ifscale,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3E */  { UD_Ifsin,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3F */  { UD_Ifcos,        O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovb,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovb,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovb,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovb,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovb,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovb,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovb,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovb,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmove,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmove,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmove,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmove,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmove,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmove,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmove,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmove,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovbe,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovbe,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovbe,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovbe,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovbe,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovbe,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovbe,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovbe,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovu,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovu,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovu,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovu,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovu,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovu,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovu,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovu,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Ifucompp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Ifld,         O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Ifstp,        O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovnb,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovnb,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovnb,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovnb,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovnb,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovnb,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovnb,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovnb,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmovne,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmovne,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmovne,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmovne,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmovne,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmovne,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmovne,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmovne,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovnbe,    O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovnbe,    O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovnbe,    O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovnbe,    O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovnbe,    O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovnbe,    O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovnbe,    O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovnbe,    O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovnu,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovnu,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovnu,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovnu,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovnu,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovnu,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovnu,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovnu,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Ifclex,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifninit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomi,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomi,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomi,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomi,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomi,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomi,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomi,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomi,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomi,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomi,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomi,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomi,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomi,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomi,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomi,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomi,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom2,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom2,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom2,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom2,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom2,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom2,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom2,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom2,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp3,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp3,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp3,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp3,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp3,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp3,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp3,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp3,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsub,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsub,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsub,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsub,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsub,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsub,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsub,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdiv,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdiv,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdiv,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdiv,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdiv,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdiv,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdiv,        O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifst,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifrstor,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ifnsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstsw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffree,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffree,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffree,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffree,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffree,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffree,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffree,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffree,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch4,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch4,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch4,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch4,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch4,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch4,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch4,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch4,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifst,         O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifst,         O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifst,         O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifst,         O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifst,         O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifst,         O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifst,         O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifst,         O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp,        O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp,        O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp,        O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp,        O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp,        O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp,        O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp,        O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp,        O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifucom,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Ifucom,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Ifucom,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifucom,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Ifucom,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifucom,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Ifucom,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 27 */  { UD_Ifucom,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 28 */  { UD_Ifucomp,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomp,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomp,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomp,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomp,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomp,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomp,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomp,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifaddp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifaddp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifaddp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifaddp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifaddp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifaddp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifaddp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifaddp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmulp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmulp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmulp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmulp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmulp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmulp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmulp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmulp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcomp5,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcomp5,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcomp5,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcomp5,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcomp5,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcomp5,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcomp5,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcomp5,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Ifcompp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Ifsubrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifbld,        O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifild,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifbstp,       O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifistp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffreep,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffreep,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffreep,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffreep,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffreep,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffreep,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffreep,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffreep,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch7,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch7,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch7,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch7,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch7,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch7,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch7,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch7,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifstp8,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifstp8,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifstp8,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifstp8,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifstp8,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifstp8,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifstp8,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifstp8,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp9,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp9,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp9,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp9,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp9,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp9,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp9,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp9,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifnstsw,      O_AX,    O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomip,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomip,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomip,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomip,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomip,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomip,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomip,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomip,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomip,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomip,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomip,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomip,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomip,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomip,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomip,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomip,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_e3__asize[3] = {
+  /* 00 */  { UD_Ijcxz,        O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 01 */  { UD_Ijecxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 02 */  { UD_Ijrcxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+};
+
+static struct ud_itab_entry itab__1byte__op_f6__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_f7__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_fe__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ff__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Icall,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Icall,        O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ijmp,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ijmp,         O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ipush,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__3dnow[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 59 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovupd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovupd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovapd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovapd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2pd,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntpd,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttpd2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtpd2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomisd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomisd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Imovmskpd,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iandpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorpd,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtpd2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtps2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Ipunpcklqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6D */  { UD_Ipunpckhqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6E */  { UD_Imovd,        O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovqa,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_V,     O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqa,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmppd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Ipinsrw,      O_V,     O_Ew,    O_Ib,    P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_VR,    O_Ib,    P_aso|P_rexr|P_rexb },
+  /* C6 */  { UD_Ishufpd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Ipsrlw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Imovq,        O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_VR,    O_NONE,  P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Icvttpd2dq,   O_V,     O_W,     O_NONE,  P_none },
+  /* E7 */  { UD_Imovntdq,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E8 */  { UD_Ipsubsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Ipsrldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Ipslldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmclear,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_ssef2__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovsd,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovddup,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2sd,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttsd2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtsd2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtsd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtsd2ss,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Isubsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Ipshuflw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpsd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovdq2q,     O_P,     O_VR,    O_NONE,  P_aso|P_rexb },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtpd2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Ilddqu,       O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovss,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovsldup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Imovshdup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2ss,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttss2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtss2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtss2sd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvttps2dq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Imovdqu,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufhw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovq,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqu,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpss,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovq2dq,     O_V,     O_PR,    O_NONE,  P_aso },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtdq2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxon,       O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+/* the order of this table matches enum ud_itab_index */
+struct ud_itab_entry * ud_itab_list[] = {
+  itab__0f,
+  itab__0f__op_00__reg,
+  itab__0f__op_01__reg,
+  itab__0f__op_01__reg__op_00__mod,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_01__mod,
+  itab__0f__op_01__reg__op_01__mod__op_01__rm,
+  itab__0f__op_01__reg__op_02__mod,
+  itab__0f__op_01__reg__op_03__mod,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor,
+  itab__0f__op_01__reg__op_04__mod,
+  itab__0f__op_01__reg__op_06__mod,
+  itab__0f__op_01__reg__op_07__mod,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_0d__reg,
+  itab__0f__op_18__reg,
+  itab__0f__op_71__reg,
+  itab__0f__op_72__reg,
+  itab__0f__op_73__reg,
+  itab__0f__op_ae__reg,
+  itab__0f__op_ae__reg__op_05__mod,
+  itab__0f__op_ae__reg__op_05__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_06__mod,
+  itab__0f__op_ae__reg__op_06__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_07__mod,
+  itab__0f__op_ae__reg__op_07__mod__op_01__rm,
+  itab__0f__op_ba__reg,
+  itab__0f__op_c7__reg,
+  itab__0f__op_c7__reg__op_00__vendor,
+  itab__0f__op_c7__reg__op_07__vendor,
+  itab__0f__op_d9__mod,
+  itab__0f__op_d9__mod__op_01__x87,
+  itab__1byte,
+  itab__1byte__op_60__osize,
+  itab__1byte__op_61__osize,
+  itab__1byte__op_63__mode,
+  itab__1byte__op_6d__osize,
+  itab__1byte__op_6f__osize,
+  itab__1byte__op_80__reg,
+  itab__1byte__op_81__reg,
+  itab__1byte__op_82__reg,
+  itab__1byte__op_83__reg,
+  itab__1byte__op_8f__reg,
+  itab__1byte__op_98__osize,
+  itab__1byte__op_99__osize,
+  itab__1byte__op_9c__mode,
+  itab__1byte__op_9c__mode__op_00__osize,
+  itab__1byte__op_9c__mode__op_01__osize,
+  itab__1byte__op_9d__mode,
+  itab__1byte__op_9d__mode__op_00__osize,
+  itab__1byte__op_9d__mode__op_01__osize,
+  itab__1byte__op_a5__osize,
+  itab__1byte__op_a7__osize,
+  itab__1byte__op_ab__osize,
+  itab__1byte__op_ad__osize,
+  itab__1byte__op_ae__mod,
+  itab__1byte__op_ae__mod__op_00__reg,
+  itab__1byte__op_af__osize,
+  itab__1byte__op_c0__reg,
+  itab__1byte__op_c1__reg,
+  itab__1byte__op_c6__reg,
+  itab__1byte__op_c7__reg,
+  itab__1byte__op_cf__osize,
+  itab__1byte__op_d0__reg,
+  itab__1byte__op_d1__reg,
+  itab__1byte__op_d2__reg,
+  itab__1byte__op_d3__reg,
+  itab__1byte__op_d8__mod,
+  itab__1byte__op_d8__mod__op_00__reg,
+  itab__1byte__op_d8__mod__op_01__x87,
+  itab__1byte__op_d9__mod,
+  itab__1byte__op_d9__mod__op_00__reg,
+  itab__1byte__op_d9__mod__op_01__x87,
+  itab__1byte__op_da__mod,
+  itab__1byte__op_da__mod__op_00__reg,
+  itab__1byte__op_da__mod__op_01__x87,
+  itab__1byte__op_db__mod,
+  itab__1byte__op_db__mod__op_00__reg,
+  itab__1byte__op_db__mod__op_01__x87,
+  itab__1byte__op_dc__mod,
+  itab__1byte__op_dc__mod__op_00__reg,
+  itab__1byte__op_dc__mod__op_01__x87,
+  itab__1byte__op_dd__mod,
+  itab__1byte__op_dd__mod__op_00__reg,
+  itab__1byte__op_dd__mod__op_01__x87,
+  itab__1byte__op_de__mod,
+  itab__1byte__op_de__mod__op_00__reg,
+  itab__1byte__op_de__mod__op_01__x87,
+  itab__1byte__op_df__mod,
+  itab__1byte__op_df__mod__op_00__reg,
+  itab__1byte__op_df__mod__op_01__x87,
+  itab__1byte__op_e3__asize,
+  itab__1byte__op_f6__reg,
+  itab__1byte__op_f7__reg,
+  itab__1byte__op_fe__reg,
+  itab__1byte__op_ff__reg,
+  itab__3dnow,
+  itab__pfx_sse66__0f,
+  itab__pfx_sse66__0f__op_71__reg,
+  itab__pfx_sse66__0f__op_72__reg,
+  itab__pfx_sse66__0f__op_73__reg,
+  itab__pfx_sse66__0f__op_c7__reg,
+  itab__pfx_sse66__0f__op_c7__reg__op_00__vendor,
+  itab__pfx_ssef2__0f,
+  itab__pfx_ssef3__0f,
+  itab__pfx_ssef3__0f__op_c7__reg,
+  itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor,
+};
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/itab.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,719 @@
+
+/* itab.h -- auto generated by opgen.py, do not edit. */
+
+#ifndef UD_ITAB_H
+#define UD_ITAB_H
+
+
+
+enum ud_itab_vendor_index {
+  ITAB__VENDOR_INDX__AMD,
+  ITAB__VENDOR_INDX__INTEL,
+};
+
+
+enum ud_itab_mode_index {
+  ITAB__MODE_INDX__16,
+  ITAB__MODE_INDX__32,
+  ITAB__MODE_INDX__64
+};
+
+
+enum ud_itab_mod_index {
+  ITAB__MOD_INDX__NOT_11,
+  ITAB__MOD_INDX__11
+};
+
+
+enum ud_itab_index {
+  ITAB__0F,
+  ITAB__0F__OP_00__REG,
+  ITAB__0F__OP_01__REG,
+  ITAB__0F__OP_01__REG__OP_00__MOD,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_01__MOD,
+  ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_02__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR,
+  ITAB__0F__OP_01__REG__OP_04__MOD,
+  ITAB__0F__OP_01__REG__OP_06__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_0D__REG,
+  ITAB__0F__OP_18__REG,
+  ITAB__0F__OP_71__REG,
+  ITAB__0F__OP_72__REG,
+  ITAB__0F__OP_73__REG,
+  ITAB__0F__OP_AE__REG,
+  ITAB__0F__OP_AE__REG__OP_05__MOD,
+  ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_06__MOD,
+  ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_07__MOD,
+  ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_BA__REG,
+  ITAB__0F__OP_C7__REG,
+  ITAB__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__0F__OP_C7__REG__OP_07__VENDOR,
+  ITAB__0F__OP_D9__MOD,
+  ITAB__0F__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE,
+  ITAB__1BYTE__OP_60__OSIZE,
+  ITAB__1BYTE__OP_61__OSIZE,
+  ITAB__1BYTE__OP_63__MODE,
+  ITAB__1BYTE__OP_6D__OSIZE,
+  ITAB__1BYTE__OP_6F__OSIZE,
+  ITAB__1BYTE__OP_80__REG,
+  ITAB__1BYTE__OP_81__REG,
+  ITAB__1BYTE__OP_82__REG,
+  ITAB__1BYTE__OP_83__REG,
+  ITAB__1BYTE__OP_8F__REG,
+  ITAB__1BYTE__OP_98__OSIZE,
+  ITAB__1BYTE__OP_99__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE,
+  ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE,
+  ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_A5__OSIZE,
+  ITAB__1BYTE__OP_A7__OSIZE,
+  ITAB__1BYTE__OP_AB__OSIZE,
+  ITAB__1BYTE__OP_AD__OSIZE,
+  ITAB__1BYTE__OP_AE__MOD,
+  ITAB__1BYTE__OP_AE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_AF__OSIZE,
+  ITAB__1BYTE__OP_C0__REG,
+  ITAB__1BYTE__OP_C1__REG,
+  ITAB__1BYTE__OP_C6__REG,
+  ITAB__1BYTE__OP_C7__REG,
+  ITAB__1BYTE__OP_CF__OSIZE,
+  ITAB__1BYTE__OP_D0__REG,
+  ITAB__1BYTE__OP_D1__REG,
+  ITAB__1BYTE__OP_D2__REG,
+  ITAB__1BYTE__OP_D3__REG,
+  ITAB__1BYTE__OP_D8__MOD,
+  ITAB__1BYTE__OP_D8__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D8__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_D9__MOD,
+  ITAB__1BYTE__OP_D9__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DA__MOD,
+  ITAB__1BYTE__OP_DA__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DA__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DB__MOD,
+  ITAB__1BYTE__OP_DB__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DB__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DC__MOD,
+  ITAB__1BYTE__OP_DC__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DC__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DD__MOD,
+  ITAB__1BYTE__OP_DD__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DD__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DE__MOD,
+  ITAB__1BYTE__OP_DE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DE__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DF__MOD,
+  ITAB__1BYTE__OP_DF__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DF__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_E3__ASIZE,
+  ITAB__1BYTE__OP_F6__REG,
+  ITAB__1BYTE__OP_F7__REG,
+  ITAB__1BYTE__OP_FE__REG,
+  ITAB__1BYTE__OP_FF__REG,
+  ITAB__3DNOW,
+  ITAB__PFX_SSE66__0F,
+  ITAB__PFX_SSE66__0F__OP_71__REG,
+  ITAB__PFX_SSE66__0F__OP_72__REG,
+  ITAB__PFX_SSE66__0F__OP_73__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__PFX_SSEF2__0F,
+  ITAB__PFX_SSEF3__0F,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR,
+};
+
+
+enum ud_mnemonic_code {
+  UD_I3dnow,
+  UD_Iaaa,
+  UD_Iaad,
+  UD_Iaam,
+  UD_Iaas,
+  UD_Iadc,
+  UD_Iadd,
+  UD_Iaddpd,
+  UD_Iaddps,
+  UD_Iaddsd,
+  UD_Iaddss,
+  UD_Iaddsubpd,
+  UD_Iaddsubps,
+  UD_Iand,
+  UD_Iandpd,
+  UD_Iandps,
+  UD_Iandnpd,
+  UD_Iandnps,
+  UD_Iarpl,
+  UD_Imovsxd,
+  UD_Ibound,
+  UD_Ibsf,
+  UD_Ibsr,
+  UD_Ibswap,
+  UD_Ibt,
+  UD_Ibtc,
+  UD_Ibtr,
+  UD_Ibts,
+  UD_Icall,
+  UD_Icbw,
+  UD_Icwde,
+  UD_Icdqe,
+  UD_Iclc,
+  UD_Icld,
+  UD_Iclflush,
+  UD_Iclgi,
+  UD_Icli,
+  UD_Iclts,
+  UD_Icmc,
+  UD_Icmovo,
+  UD_Icmovno,
+  UD_Icmovb,
+  UD_Icmovae,
+  UD_Icmovz,
+  UD_Icmovnz,
+  UD_Icmovbe,
+  UD_Icmova,
+  UD_Icmovs,
+  UD_Icmovns,
+  UD_Icmovp,
+  UD_Icmovnp,
+  UD_Icmovl,
+  UD_Icmovge,
+  UD_Icmovle,
+  UD_Icmovg,
+  UD_Icmp,
+  UD_Icmppd,
+  UD_Icmpps,
+  UD_Icmpsb,
+  UD_Icmpsw,
+  UD_Icmpsd,
+  UD_Icmpsq,
+  UD_Icmpss,
+  UD_Icmpxchg,
+  UD_Icmpxchg8b,
+  UD_Icomisd,
+  UD_Icomiss,
+  UD_Icpuid,
+  UD_Icvtdq2pd,
+  UD_Icvtdq2ps,
+  UD_Icvtpd2dq,
+  UD_Icvtpd2pi,
+  UD_Icvtpd2ps,
+  UD_Icvtpi2ps,
+  UD_Icvtpi2pd,
+  UD_Icvtps2dq,
+  UD_Icvtps2pi,
+  UD_Icvtps2pd,
+  UD_Icvtsd2si,
+  UD_Icvtsd2ss,
+  UD_Icvtsi2ss,
+  UD_Icvtss2si,
+  UD_Icvtss2sd,
+  UD_Icvttpd2pi,
+  UD_Icvttpd2dq,
+  UD_Icvttps2dq,
+  UD_Icvttps2pi,
+  UD_Icvttsd2si,
+  UD_Icvtsi2sd,
+  UD_Icvttss2si,
+  UD_Icwd,
+  UD_Icdq,
+  UD_Icqo,
+  UD_Idaa,
+  UD_Idas,
+  UD_Idec,
+  UD_Idiv,
+  UD_Idivpd,
+  UD_Idivps,
+  UD_Idivsd,
+  UD_Idivss,
+  UD_Iemms,
+  UD_Ienter,
+  UD_If2xm1,
+  UD_Ifabs,
+  UD_Ifadd,
+  UD_Ifaddp,
+  UD_Ifbld,
+  UD_Ifbstp,
+  UD_Ifchs,
+  UD_Ifclex,
+  UD_Ifcmovb,
+  UD_Ifcmove,
+  UD_Ifcmovbe,
+  UD_Ifcmovu,
+  UD_Ifcmovnb,
+  UD_Ifcmovne,
+  UD_Ifcmovnbe,
+  UD_Ifcmovnu,
+  UD_Ifucomi,
+  UD_Ifcom,
+  UD_Ifcom2,
+  UD_Ifcomp3,
+  UD_Ifcomi,
+  UD_Ifucomip,
+  UD_Ifcomip,
+  UD_Ifcomp,
+  UD_Ifcomp5,
+  UD_Ifcompp,
+  UD_Ifcos,
+  UD_Ifdecstp,
+  UD_Ifdiv,
+  UD_Ifdivp,
+  UD_Ifdivr,
+  UD_Ifdivrp,
+  UD_Ifemms,
+  UD_Iffree,
+  UD_Iffreep,
+  UD_Ificom,
+  UD_Ificomp,
+  UD_Ifild,
+  UD_Ifncstp,
+  UD_Ifninit,
+  UD_Ifiadd,
+  UD_Ifidivr,
+  UD_Ifidiv,
+  UD_Ifisub,
+  UD_Ifisubr,
+  UD_Ifist,
+  UD_Ifistp,
+  UD_Ifisttp,
+  UD_Ifld,
+  UD_Ifld1,
+  UD_Ifldl2t,
+  UD_Ifldl2e,
+  UD_Ifldlpi,
+  UD_Ifldlg2,
+  UD_Ifldln2,
+  UD_Ifldz,
+  UD_Ifldcw,
+  UD_Ifldenv,
+  UD_Ifmul,
+  UD_Ifmulp,
+  UD_Ifimul,
+  UD_Ifnop,
+  UD_Ifpatan,
+  UD_Ifprem,
+  UD_Ifprem1,
+  UD_Ifptan,
+  UD_Ifrndint,
+  UD_Ifrstor,
+  UD_Ifnsave,
+  UD_Ifscale,
+  UD_Ifsin,
+  UD_Ifsincos,
+  UD_Ifsqrt,
+  UD_Ifstp,
+  UD_Ifstp1,
+  UD_Ifstp8,
+  UD_Ifstp9,
+  UD_Ifst,
+  UD_Ifnstcw,
+  UD_Ifnstenv,
+  UD_Ifnstsw,
+  UD_Ifsub,
+  UD_Ifsubp,
+  UD_Ifsubr,
+  UD_Ifsubrp,
+  UD_Iftst,
+  UD_Ifucom,
+  UD_Ifucomp,
+  UD_Ifucompp,
+  UD_Ifxam,
+  UD_Ifxch,
+  UD_Ifxch4,
+  UD_Ifxch7,
+  UD_Ifxrstor,
+  UD_Ifxsave,
+  UD_Ifpxtract,
+  UD_Ifyl2x,
+  UD_Ifyl2xp1,
+  UD_Ihaddpd,
+  UD_Ihaddps,
+  UD_Ihlt,
+  UD_Ihsubpd,
+  UD_Ihsubps,
+  UD_Iidiv,
+  UD_Iin,
+  UD_Iimul,
+  UD_Iinc,
+  UD_Iinsb,
+  UD_Iinsw,
+  UD_Iinsd,
+  UD_Iint1,
+  UD_Iint3,
+  UD_Iint,
+  UD_Iinto,
+  UD_Iinvd,
+  UD_Iinvlpg,
+  UD_Iinvlpga,
+  UD_Iiretw,
+  UD_Iiretd,
+  UD_Iiretq,
+  UD_Ijo,
+  UD_Ijno,
+  UD_Ijb,
+  UD_Ijae,
+  UD_Ijz,
+  UD_Ijnz,
+  UD_Ijbe,
+  UD_Ija,
+  UD_Ijs,
+  UD_Ijns,
+  UD_Ijp,
+  UD_Ijnp,
+  UD_Ijl,
+  UD_Ijge,
+  UD_Ijle,
+  UD_Ijg,
+  UD_Ijcxz,
+  UD_Ijecxz,
+  UD_Ijrcxz,
+  UD_Ijmp,
+  UD_Ilahf,
+  UD_Ilar,
+  UD_Ilddqu,
+  UD_Ildmxcsr,
+  UD_Ilds,
+  UD_Ilea,
+  UD_Iles,
+  UD_Ilfs,
+  UD_Ilgs,
+  UD_Ilidt,
+  UD_Ilss,
+  UD_Ileave,
+  UD_Ilfence,
+  UD_Ilgdt,
+  UD_Illdt,
+  UD_Ilmsw,
+  UD_Ilock,
+  UD_Ilodsb,
+  UD_Ilodsw,
+  UD_Ilodsd,
+  UD_Ilodsq,
+  UD_Iloopnz,
+  UD_Iloope,
+  UD_Iloop,
+  UD_Ilsl,
+  UD_Iltr,
+  UD_Imaskmovq,
+  UD_Imaxpd,
+  UD_Imaxps,
+  UD_Imaxsd,
+  UD_Imaxss,
+  UD_Imfence,
+  UD_Iminpd,
+  UD_Iminps,
+  UD_Iminsd,
+  UD_Iminss,
+  UD_Imonitor,
+  UD_Imov,
+  UD_Imovapd,
+  UD_Imovaps,
+  UD_Imovd,
+  UD_Imovddup,
+  UD_Imovdqa,
+  UD_Imovdqu,
+  UD_Imovdq2q,
+  UD_Imovhpd,
+  UD_Imovhps,
+  UD_Imovlhps,
+  UD_Imovlpd,
+  UD_Imovlps,
+  UD_Imovhlps,
+  UD_Imovmskpd,
+  UD_Imovmskps,
+  UD_Imovntdq,
+  UD_Imovnti,
+  UD_Imovntpd,
+  UD_Imovntps,
+  UD_Imovntq,
+  UD_Imovq,
+  UD_Imovqa,
+  UD_Imovq2dq,
+  UD_Imovsb,
+  UD_Imovsw,
+  UD_Imovsd,
+  UD_Imovsq,
+  UD_Imovsldup,
+  UD_Imovshdup,
+  UD_Imovss,
+  UD_Imovsx,
+  UD_Imovupd,
+  UD_Imovups,
+  UD_Imovzx,
+  UD_Imul,
+  UD_Imulpd,
+  UD_Imulps,
+  UD_Imulsd,
+  UD_Imulss,
+  UD_Imwait,
+  UD_Ineg,
+  UD_Inop,
+  UD_Inot,
+  UD_Ior,
+  UD_Iorpd,
+  UD_Iorps,
+  UD_Iout,
+  UD_Ioutsb,
+  UD_Ioutsw,
+  UD_Ioutsd,
+  UD_Ioutsq,
+  UD_Ipacksswb,
+  UD_Ipackssdw,
+  UD_Ipackuswb,
+  UD_Ipaddb,
+  UD_Ipaddw,
+  UD_Ipaddq,
+  UD_Ipaddsb,
+  UD_Ipaddsw,
+  UD_Ipaddusb,
+  UD_Ipaddusw,
+  UD_Ipand,
+  UD_Ipandn,
+  UD_Ipause,
+  UD_Ipavgb,
+  UD_Ipavgw,
+  UD_Ipcmpeqb,
+  UD_Ipcmpeqw,
+  UD_Ipcmpeqd,
+  UD_Ipcmpgtb,
+  UD_Ipcmpgtw,
+  UD_Ipcmpgtd,
+  UD_Ipextrw,
+  UD_Ipinsrw,
+  UD_Ipmaddwd,
+  UD_Ipmaxsw,
+  UD_Ipmaxub,
+  UD_Ipminsw,
+  UD_Ipminub,
+  UD_Ipmovmskb,
+  UD_Ipmulhuw,
+  UD_Ipmulhw,
+  UD_Ipmullw,
+  UD_Ipmuludq,
+  UD_Ipop,
+  UD_Ipopa,
+  UD_Ipopad,
+  UD_Ipopfw,
+  UD_Ipopfd,
+  UD_Ipopfq,
+  UD_Ipor,
+  UD_Iprefetch,
+  UD_Iprefetchnta,
+  UD_Iprefetcht0,
+  UD_Iprefetcht1,
+  UD_Iprefetcht2,
+  UD_Ipsadbw,
+  UD_Ipshufd,
+  UD_Ipshufhw,
+  UD_Ipshuflw,
+  UD_Ipshufw,
+  UD_Ipslldq,
+  UD_Ipsllw,
+  UD_Ipslld,
+  UD_Ipsllq,
+  UD_Ipsraw,
+  UD_Ipsrad,
+  UD_Ipsrlw,
+  UD_Ipsrld,
+  UD_Ipsrlq,
+  UD_Ipsrldq,
+  UD_Ipsubb,
+  UD_Ipsubw,
+  UD_Ipsubd,
+  UD_Ipsubq,
+  UD_Ipsubsb,
+  UD_Ipsubsw,
+  UD_Ipsubusb,
+  UD_Ipsubusw,
+  UD_Ipunpckhbw,
+  UD_Ipunpckhwd,
+  UD_Ipunpckhdq,
+  UD_Ipunpckhqdq,
+  UD_Ipunpcklbw,
+  UD_Ipunpcklwd,
+  UD_Ipunpckldq,
+  UD_Ipunpcklqdq,
+  UD_Ipi2fw,
+  UD_Ipi2fd,
+  UD_Ipf2iw,
+  UD_Ipf2id,
+  UD_Ipfnacc,
+  UD_Ipfpnacc,
+  UD_Ipfcmpge,
+  UD_Ipfmin,
+  UD_Ipfrcp,
+  UD_Ipfrsqrt,
+  UD_Ipfsub,
+  UD_Ipfadd,
+  UD_Ipfcmpgt,
+  UD_Ipfmax,
+  UD_Ipfrcpit1,
+  UD_Ipfrspit1,
+  UD_Ipfsubr,
+  UD_Ipfacc,
+  UD_Ipfcmpeq,
+  UD_Ipfmul,
+  UD_Ipfrcpit2,
+  UD_Ipmulhrw,
+  UD_Ipswapd,
+  UD_Ipavgusb,
+  UD_Ipush,
+  UD_Ipusha,
+  UD_Ipushad,
+  UD_Ipushfw,
+  UD_Ipushfd,
+  UD_Ipushfq,
+  UD_Ipxor,
+  UD_Ircl,
+  UD_Ircr,
+  UD_Irol,
+  UD_Iror,
+  UD_Ircpps,
+  UD_Ircpss,
+  UD_Irdmsr,
+  UD_Irdpmc,
+  UD_Irdtsc,
+  UD_Irdtscp,
+  UD_Irepne,
+  UD_Irep,
+  UD_Iret,
+  UD_Iretf,
+  UD_Irsm,
+  UD_Irsqrtps,
+  UD_Irsqrtss,
+  UD_Isahf,
+  UD_Isal,
+  UD_Isalc,
+  UD_Isar,
+  UD_Ishl,
+  UD_Ishr,
+  UD_Isbb,
+  UD_Iscasb,
+  UD_Iscasw,
+  UD_Iscasd,
+  UD_Iscasq,
+  UD_Iseto,
+  UD_Isetno,
+  UD_Isetb,
+  UD_Isetnb,
+  UD_Isetz,
+  UD_Isetnz,
+  UD_Isetbe,
+  UD_Iseta,
+  UD_Isets,
+  UD_Isetns,
+  UD_Isetp,
+  UD_Isetnp,
+  UD_Isetl,
+  UD_Isetge,
+  UD_Isetle,
+  UD_Isetg,
+  UD_Isfence,
+  UD_Isgdt,
+  UD_Ishld,
+  UD_Ishrd,
+  UD_Ishufpd,
+  UD_Ishufps,
+  UD_Isidt,
+  UD_Isldt,
+  UD_Ismsw,
+  UD_Isqrtps,
+  UD_Isqrtpd,
+  UD_Isqrtsd,
+  UD_Isqrtss,
+  UD_Istc,
+  UD_Istd,
+  UD_Istgi,
+  UD_Isti,
+  UD_Iskinit,
+  UD_Istmxcsr,
+  UD_Istosb,
+  UD_Istosw,
+  UD_Istosd,
+  UD_Istosq,
+  UD_Istr,
+  UD_Isub,
+  UD_Isubpd,
+  UD_Isubps,
+  UD_Isubsd,
+  UD_Isubss,
+  UD_Iswapgs,
+  UD_Isyscall,
+  UD_Isysenter,
+  UD_Isysexit,
+  UD_Isysret,
+  UD_Itest,
+  UD_Iucomisd,
+  UD_Iucomiss,
+  UD_Iud2,
+  UD_Iunpckhpd,
+  UD_Iunpckhps,
+  UD_Iunpcklps,
+  UD_Iunpcklpd,
+  UD_Iverr,
+  UD_Iverw,
+  UD_Ivmcall,
+  UD_Ivmclear,
+  UD_Ivmxon,
+  UD_Ivmptrld,
+  UD_Ivmptrst,
+  UD_Ivmresume,
+  UD_Ivmxoff,
+  UD_Ivmrun,
+  UD_Ivmmcall,
+  UD_Ivmload,
+  UD_Ivmsave,
+  UD_Iwait,
+  UD_Iwbinvd,
+  UD_Iwrmsr,
+  UD_Ixadd,
+  UD_Ixchg,
+  UD_Ixlatb,
+  UD_Ixor,
+  UD_Ixorpd,
+  UD_Ixorps,
+  UD_Idb,
+  UD_Iinvalid,
+  UD_Id3vil,
+  UD_Ina,
+  UD_Igrp_reg,
+  UD_Igrp_rm,
+  UD_Igrp_vendor,
+  UD_Igrp_x87,
+  UD_Igrp_mode,
+  UD_Igrp_osize,
+  UD_Igrp_asize,
+  UD_Igrp_mod,
+  UD_Inone,
+};
+
+
+
+extern const char* ud_mnemonics_str[];;
+extern struct ud_itab_entry* ud_itab_list[];
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/kdb_dis.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include <xen/compile.h>                /* for XEN_SUBVERSION */
+#include "../../include/kdbinc.h"
+#include "extern.h"
+
+static void (*dis_syntax)(ud_t*) = UD_SYN_ATT; /* default dis-assembly syntax */
+
+static struct {                         /* info for kdb_read_byte_for_ud() */
+    kdbva_t kud_instr_addr;
+    domid_t kud_domid;
+} kdb_ud_rd_info;
+
+/* called via function ptr by ud when disassembling. 
+ * kdb info passed via kdb_ud_rd_info{} 
+ */
+static int
+kdb_read_byte_for_ud(struct ud *udp)
+{
+    kdbbyt_t bytebuf;
+    domid_t domid = kdb_ud_rd_info.kud_domid;
+    kdbva_t addr = kdb_ud_rd_info.kud_instr_addr;
+
+    if (kdb_read_mem(addr, &bytebuf, 1, domid) == 1) {
+        kdb_ud_rd_info.kud_instr_addr++;
+        KDBGP1("udrd:addr:%lx domid:%d byt:%x\n", addr, domid, bytebuf);
+        return bytebuf;
+    }
+    KDBGP1("udrd:addr:%lx domid:%d err\n", addr, domid);
+    return UD_EOI;
+}
+
+/* 
+ * given a domid, convert addr to symbol and print it 
+ * Eg: ffff828c801235e2: idle_loop+52                  jmp  idle_loop+55
+ *    Called twice here for idle_loop. In first case, nl is null, 
+ *    in the second case nl == '\n'
+ */
+void
+kdb_prnt_addr2sym(domid_t domid, kdbva_t addr, char *nl)
+{
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1], pbuf[150], prefix[8];
+    char *p = buf;
+
+    prefix[0]='\0';
+    if (domid != DOMID_IDLE) {
+        snprintf(prefix, 8, "%x:", domid);
+        p = kdb_guest_addr2sym(addr, domid, &offs);
+    } else
+        symbols_lookup(addr, &sz, &offs, buf);
+
+    snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
+    if (*nl != '\n')
+        kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
+    else
+        kdbp("%s%s", pbuf, nl);
+
+}
+
+static int
+kdb_jump_instr(enum ud_mnemonic_code mnemonic)
+{
+    return (mnemonic >= UD_Ijo && mnemonic <= UD_Ijmp);
+}
+
+/*
+ * print one instr: function so that we can print offsets of jmp etc.. as
+ *  symbol+offset instead of just address
+ */
+static void
+kdb_print_one_instr(struct ud *udp, domid_t domid)
+{
+    signed long val = 0;
+    ud_type_t type = udp->operand[0].type;
+
+    if ((udp->mnemonic == UD_Icall || kdb_jump_instr(udp->mnemonic)) &&
+        type == UD_OP_JIMM) {
+        
+        int sz = udp->operand[0].size;
+        char *p, ibuf[40], *q = ibuf;
+        kdbva_t addr;
+
+        if (sz == 8) val = udp->operand[0].lval.sbyte;
+        else if (sz == 16) val = udp->operand[0].lval.sword;
+        else if (sz == 32) val = udp->operand[0].lval.sdword;
+        else if (sz == 64) val = udp->operand[0].lval.sqword;
+        else kdbp("kdb_print_one_instr: Inval sz:z%d\n", sz);
+
+        addr = udp->pc + val;
+        for(p=ud_insn_asm(udp); (*q=*p) && *p!=' '; p++,q++);
+        *q='\0';
+        kdbp(" %-4s ", ibuf);    /* space before for long func names */
+        kdb_prnt_addr2sym(domid, addr, "\n");
+    } else
+        kdbp(" %-24s\n", ud_insn_asm(udp));
+#if 0
+    kdbp("mnemonic:z%d ", udp->mnemonic);
+    if (type == UD_OP_CONST) kdbp("type is const\n");
+    else if (type == UD_OP_JIMM) kdbp("type is JIMM\n");
+    else if (type == UD_OP_IMM) kdbp("type is IMM\n");
+    else if (type == UD_OP_PTR) kdbp("type is PTR\n");
+#endif
+}
+
+static void
+kdb_setup_ud(struct ud *udp, kdbva_t addr, domid_t domid)
+{
+    int bitness = kdb_guest_bitness(domid);
+    uint vendor = (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ?
+                                           UD_VENDOR_AMD : UD_VENDOR_INTEL;
+
+    KDBGP1("setup_ud:domid:%d bitness:%d addr:%lx\n", domid, bitness, addr);
+    ud_init(udp);
+    ud_set_mode(udp, kdb_guest_bitness(domid));
+    ud_set_syntax(udp, dis_syntax); 
+    ud_set_vendor(udp, vendor);           /* HVM: vmx/svm different instrs*/
+    ud_set_pc(udp, addr);                 /* for numbers printed on left */
+    ud_set_input_hook(udp, kdb_read_byte_for_ud);
+    kdb_ud_rd_info.kud_instr_addr = addr;
+    kdb_ud_rd_info.kud_domid = domid;
+}
+
+/*
+ * given an addr, print given number of instructions.
+ * Returns: address of next instruction in the stream
+ */
+kdbva_t
+kdb_print_instr(kdbva_t addr, long num, domid_t domid)
+{
+    struct ud ud_s;
+
+    KDBGP1("print_instr:addr:0x%lx num:%ld domid:%x\n", addr, num, domid);
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    while(num--) {
+        if (ud_disassemble(&ud_s)) {
+            uint64_t pc = ud_insn_off(&ud_s);
+            /* kdbp("%08x: ",(int)pc); */
+            kdbp("%016lx: ", pc);
+            kdb_prnt_addr2sym(domid, pc, "");
+            kdb_print_one_instr(&ud_s, domid);
+        } else
+            kdbp("KDB:Couldn't disassemble PC:0x%lx\n", addr);
+            /* for stack reads, don't always display error */
+    }
+    KDBGP1("print_instr:kudaddr:0x%lx\n", kdb_ud_rd_info.kud_instr_addr);
+    return kdb_ud_rd_info.kud_instr_addr;
+}
+
+void
+kdb_display_pc(struct cpu_user_regs *regs)
+{   
+    domid_t domid;
+    struct cpu_user_regs regs1 = *regs;
+    domid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+
+    regs1.KDBIP = regs->KDBIP;
+    kdb_print_instr(regs1.KDBIP, 1, domid);
+}
+
+/* check if the instr at the addr is call instruction
+ * RETURNS: size of the instr if it's a call instr, else 0
+ */
+int
+kdb_check_call_instr(domid_t domid, kdbva_t addr)
+{
+    struct ud ud_s;
+    int sz;
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    if ((sz=ud_disassemble(&ud_s)) && ud_s.mnemonic == UD_Icall)
+        return (sz);
+    return 0;
+}
+
+/* toggle ATT and Intel syntaxes */
+void
+kdb_toggle_dis_syntax(void)
+{
+    if (dis_syntax == UD_SYN_INTEL) {
+        dis_syntax = UD_SYN_ATT;
+        kdbp("dis syntax now set to ATT (Gas)\n");
+    } else {
+        dis_syntax = UD_SYN_INTEL;
+        kdbp("dis syntax now set to Intel (NASM)\n");
+    }
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn-att.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-att.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,211 @@
+/* -----------------------------------------------------------------------------
+ * syn-att.c
+ *
+ * Copyright (c) 2004, 2005, 2006 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case 16 : case 32 :
+		mkasm(u, "*");   break;
+	default: break;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+gen_operand(struct ud* u, struct ud_operand* op)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, "%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM:
+		if (u->br_far) opr_cast(u, op);
+		if (u->pfx_seg)
+			mkasm(u, "%%%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", (-op->lval.sbyte) & 0xff);
+			else	mkasm(u, "0x%x", op->lval.sbyte);
+		} 
+		else if (op->offset == 16) 
+			mkasm(u, "0x%x", op->lval.uword);
+		else if (op->offset == 32) 
+			mkasm(u, "0x%lx", op->lval.udword);
+		else if (op->offset == 64) 
+			mkasm(u, "0x" FMT64 "x", op->lval.uqword);
+
+		if (op->base)
+			mkasm(u, "(%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		if (op->index) {
+			if (op->base)
+				mkasm(u, ",");
+			else mkasm(u, "(");
+			mkasm(u, "%%%s", ud_reg_tab[op->index - UD_R_AL]);
+		}
+		if (op->scale)
+			mkasm(u, ",%d", op->scale);
+		if (op->base || op->index)
+			mkasm(u, ")");
+		break;
+
+	case UD_OP_IMM:
+		switch (op->size) {
+			case  8: mkasm(u, "$0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "$0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "$0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "$0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "$0x%x, $0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "$0x%x, $0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+			
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to AT&T syntax 
+ * =============================================================================
+ */
+extern void 
+ud_translate_att(struct ud *u)
+{
+  int size = 0;
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+  	mkasm(u,  "lock ");
+  if (u->pfx_rep)
+	mkasm(u,  "rep ");
+  if (u->pfx_repne)
+		mkasm(u,  "repne ");
+
+  /* special instructions */
+  switch (u->mnemonic) {
+	case UD_Iretf: 
+		mkasm(u, "lret "); 
+		break;
+	case UD_Idb:
+		mkasm(u, ".byte 0x%x", u->operand[0].lval.ubyte);
+		return;
+	case UD_Ijmp:
+	case UD_Icall:
+		if (u->br_far) mkasm(u,  "l");
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+		break;
+	case UD_Ibound:
+	case UD_Ienter:
+		if (u->operand[0].type != UD_NONE)
+			gen_operand(u, &u->operand[0]);
+		if (u->operand[1].type != UD_NONE) {
+			mkasm(u, ",");
+			gen_operand(u, &u->operand[1]);
+		}
+		return;
+	default:
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+  }
+
+  if (u->c1)
+	size = u->operand[0].size;
+  else if (u->c2)
+	size = u->operand[1].size;
+  else if (u->c3)
+	size = u->operand[2].size;
+
+  if (size == 8)
+	mkasm(u, "b");
+  else if (size == 16)
+	mkasm(u, "w");
+  else if (size == 64)
+ 	mkasm(u, "q");
+
+  mkasm(u, " ");
+
+  if (u->operand[2].type != UD_NONE) {
+	gen_operand(u, &u->operand[2]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[1].type != UD_NONE) {
+	gen_operand(u, &u->operand[1]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[0].type != UD_NONE)
+	gen_operand(u, &u->operand[0]);
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn-intel.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-intel.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,208 @@
+/* -----------------------------------------------------------------------------
+ * syn-intel.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case  8: mkasm(u, "byte " ); break;
+	case 16: mkasm(u, "word " ); break;
+	case 32: mkasm(u, "dword "); break;
+	case 64: mkasm(u, "qword "); break;
+	case 80: mkasm(u, "tword "); break;
+	default: break;
+  }
+  if (u->br_far)
+	mkasm(u, "far "); 
+  else if (u->br_near)
+	mkasm(u, "near ");
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void gen_operand(struct ud* u, struct ud_operand* op, int syn_cast)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM: {
+
+		int op_f = 0;
+
+		if (syn_cast) 
+			opr_cast(u, op);
+
+		mkasm(u, "[");
+
+		if (u->pfx_seg)
+			mkasm(u, "%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+		if (op->base) {
+			mkasm(u, "%s", ud_reg_tab[op->base - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->index) {
+			if (op_f)
+				mkasm(u, "+");
+			mkasm(u, "%s", ud_reg_tab[op->index - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->scale)
+			mkasm(u, "*%d", op->scale);
+
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", -op->lval.sbyte);
+			else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sbyte);
+		}
+		else if (op->offset == 16)
+			mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.uword);
+		else if (op->offset == 32) {
+			if (u->adr_mode == 64) {
+				if (op->lval.sdword < 0)
+					mkasm(u, "-0x%x", -op->lval.sdword);
+				else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sdword);
+			} 
+			else	mkasm(u, "%s0x%lx", (op_f) ? "+" : "", op->lval.udword);
+		}
+		else if (op->offset == 64) 
+			mkasm(u, "%s0x" FMT64 "x", (op_f) ? "+" : "", op->lval.uqword);
+
+		mkasm(u, "]");
+		break;
+	}
+			
+	case UD_OP_IMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8: mkasm(u, "0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "word 0x%x:0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "dword 0x%x:0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+
+	case UD_OP_CONST:
+		if (syn_cast) opr_cast(u, op);
+		mkasm(u, "%d", op->lval.udword);
+		break;
+
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to intel syntax 
+ * =============================================================================
+ */
+extern void ud_translate_intel(struct ud* u)
+{
+  /* -- prefixes -- */
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+	mkasm(u, "lock ");
+  if (u->pfx_rep)
+	mkasm(u, "rep ");
+  if (u->pfx_repne)
+	mkasm(u, "repne ");
+  if (u->implicit_addr && u->pfx_seg)
+	mkasm(u, "%s ", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+  /* print the instruction mnemonic */
+  mkasm(u, "%s ", ud_lookup_mnemonic(u->mnemonic));
+
+  /* operand 1 */
+  if (u->operand[0].type != UD_NONE) {
+	gen_operand(u, &u->operand[0], u->c1);
+  }
+  /* operand 2 */
+  if (u->operand[1].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[1], u->c2);
+  }
+
+  /* operand 3 */
+  if (u->operand[2].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[2], u->c3);
+  }
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,61 @@
+/* -----------------------------------------------------------------------------
+ * syn.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+/* -----------------------------------------------------------------------------
+ * Intel Register Table - Order Matters (types.h)!
+ * -----------------------------------------------------------------------------
+ */
+const char* ud_reg_tab[] = 
+{
+  "al",		"cl",		"dl",		"bl",
+  "ah",		"ch",		"dh",		"bh",
+  "spl",	"bpl",		"sil",		"dil",
+  "r8b",	"r9b",		"r10b",		"r11b",
+  "r12b",	"r13b",		"r14b",		"r15b",
+
+  "ax",		"cx",		"dx",		"bx",
+  "sp",		"bp",		"si",		"di",
+  "r8w",	"r9w",		"r10w",		"r11w",
+  "r12w",	"r13W"	,	"r14w",		"r15w",
+	
+  "eax",	"ecx",		"edx",		"ebx",
+  "esp",	"ebp",		"esi",		"edi",
+  "r8d",	"r9d",		"r10d",		"r11d",
+  "r12d",	"r13d",		"r14d",		"r15d",
+	
+  "rax",	"rcx",		"rdx",		"rbx",
+  "rsp",	"rbp",		"rsi",		"rdi",
+  "r8",		"r9",		"r10",		"r11",
+  "r12",	"r13",		"r14",		"r15",
+
+  "es",		"cs",		"ss",		"ds",
+  "fs",		"gs",	
+
+  "cr0",	"cr1",		"cr2",		"cr3",
+  "cr4",	"cr5",		"cr6",		"cr7",
+  "cr8",	"cr9",		"cr10",		"cr11",
+  "cr12",	"cr13",		"cr14",		"cr15",
+	
+  "dr0",	"dr1",		"dr2",		"dr3",
+  "dr4",	"dr5",		"dr6",		"dr7",
+  "dr8",	"dr9",		"dr10",		"dr11",
+  "dr12",	"dr13",		"dr14",		"dr15",
+
+  "mm0",	"mm1",		"mm2",		"mm3",
+  "mm4",	"mm5",		"mm6",		"mm7",
+
+  "st0",	"st1",		"st2",		"st3",
+  "st4",	"st5",		"st6",		"st7", 
+
+  "xmm0",	"xmm1",		"xmm2",		"xmm3",
+  "xmm4",	"xmm5",		"xmm6",		"xmm7",
+  "xmm8",	"xmm9",		"xmm10",	"xmm11",
+  "xmm12",	"xmm13",	"xmm14",	"xmm15",
+
+  "rip"
+};
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,27 @@
+/* -----------------------------------------------------------------------------
+ * syn.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_SYN_H
+#define UD_SYN_H
+
+#if 0
+#include <stdio.h>
+#include <stdarg.h>
+#endif
+#include "types.h"
+
+extern const char* ud_reg_tab[];
+
+static void mkasm(struct ud* u, const char* fmt, ...)
+{
+  va_list ap;
+  va_start(ap, fmt);
+  u->insn_fill += vsnprintf((char*) u->insn_buffer + u->insn_fill, 64, fmt, ap);
+  va_end(ap);
+}
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/types.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/types.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,186 @@
+/* -----------------------------------------------------------------------------
+ * types.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_TYPES_H
+#define UD_TYPES_H
+
+
+#include "../../include/kdbinc.h"
+
+#define FMT64 "%ll"
+#include "itab.h"
+
+/* -----------------------------------------------------------------------------
+ * All possible "types" of objects in udis86. Order is Important!
+ * -----------------------------------------------------------------------------
+ */
+enum ud_type
+{
+  UD_NONE,
+
+  /* 8 bit GPRs */
+  UD_R_AL,	UD_R_CL,	UD_R_DL,	UD_R_BL,
+  UD_R_AH,	UD_R_CH,	UD_R_DH,	UD_R_BH,
+  UD_R_SPL,	UD_R_BPL,	UD_R_SIL,	UD_R_DIL,
+  UD_R_R8B,	UD_R_R9B,	UD_R_R10B,	UD_R_R11B,
+  UD_R_R12B,	UD_R_R13B,	UD_R_R14B,	UD_R_R15B,
+
+  /* 16 bit GPRs */
+  UD_R_AX,	UD_R_CX,	UD_R_DX,	UD_R_BX,
+  UD_R_SP,	UD_R_BP,	UD_R_SI,	UD_R_DI,
+  UD_R_R8W,	UD_R_R9W,	UD_R_R10W,	UD_R_R11W,
+  UD_R_R12W,	UD_R_R13W,	UD_R_R14W,	UD_R_R15W,
+	
+  /* 32 bit GPRs */
+  UD_R_EAX,	UD_R_ECX,	UD_R_EDX,	UD_R_EBX,
+  UD_R_ESP,	UD_R_EBP,	UD_R_ESI,	UD_R_EDI,
+  UD_R_R8D,	UD_R_R9D,	UD_R_R10D,	UD_R_R11D,
+  UD_R_R12D,	UD_R_R13D,	UD_R_R14D,	UD_R_R15D,
+	
+  /* 64 bit GPRs */
+  UD_R_RAX,	UD_R_RCX,	UD_R_RDX,	UD_R_RBX,
+  UD_R_RSP,	UD_R_RBP,	UD_R_RSI,	UD_R_RDI,
+  UD_R_R8,	UD_R_R9,	UD_R_R10,	UD_R_R11,
+  UD_R_R12,	UD_R_R13,	UD_R_R14,	UD_R_R15,
+
+  /* segment registers */
+  UD_R_ES,	UD_R_CS,	UD_R_SS,	UD_R_DS,
+  UD_R_FS,	UD_R_GS,	
+
+  /* control registers*/
+  UD_R_CR0,	UD_R_CR1,	UD_R_CR2,	UD_R_CR3,
+  UD_R_CR4,	UD_R_CR5,	UD_R_CR6,	UD_R_CR7,
+  UD_R_CR8,	UD_R_CR9,	UD_R_CR10,	UD_R_CR11,
+  UD_R_CR12,	UD_R_CR13,	UD_R_CR14,	UD_R_CR15,
+	
+  /* debug registers */
+  UD_R_DR0,	UD_R_DR1,	UD_R_DR2,	UD_R_DR3,
+  UD_R_DR4,	UD_R_DR5,	UD_R_DR6,	UD_R_DR7,
+  UD_R_DR8,	UD_R_DR9,	UD_R_DR10,	UD_R_DR11,
+  UD_R_DR12,	UD_R_DR13,	UD_R_DR14,	UD_R_DR15,
+
+  /* mmx registers */
+  UD_R_MM0,	UD_R_MM1,	UD_R_MM2,	UD_R_MM3,
+  UD_R_MM4,	UD_R_MM5,	UD_R_MM6,	UD_R_MM7,
+
+  /* x87 registers */
+  UD_R_ST0,	UD_R_ST1,	UD_R_ST2,	UD_R_ST3,
+  UD_R_ST4,	UD_R_ST5,	UD_R_ST6,	UD_R_ST7, 
+
+  /* extended multimedia registers */
+  UD_R_XMM0,	UD_R_XMM1,	UD_R_XMM2,	UD_R_XMM3,
+  UD_R_XMM4,	UD_R_XMM5,	UD_R_XMM6,	UD_R_XMM7,
+  UD_R_XMM8,	UD_R_XMM9,	UD_R_XMM10,	UD_R_XMM11,
+  UD_R_XMM12,	UD_R_XMM13,	UD_R_XMM14,	UD_R_XMM15,
+
+  UD_R_RIP,
+
+  /* Operand Types */
+  UD_OP_REG,	UD_OP_MEM,	UD_OP_PTR,	UD_OP_IMM,	
+  UD_OP_JIMM,	UD_OP_CONST
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud_operand - Disassembled instruction Operand.
+ * -----------------------------------------------------------------------------
+ */
+struct ud_operand 
+{
+  enum ud_type		type;
+  uint8_t		size;
+  union {
+	int8_t		sbyte;
+	uint8_t		ubyte;
+	int16_t		sword;
+	uint16_t	uword;
+	int32_t		sdword;
+	uint32_t	udword;
+	int64_t		sqword;
+	uint64_t	uqword;
+
+	struct {
+		uint16_t seg;
+		uint32_t off;
+	} ptr;
+  } lval;
+
+  enum ud_type		base;
+  enum ud_type		index;
+  uint8_t		offset;
+  uint8_t		scale;	
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud - The udis86 object.
+ * -----------------------------------------------------------------------------
+ */
+struct ud
+{
+  int 			(*inp_hook) (struct ud*);
+  uint8_t		inp_curr;
+  uint8_t		inp_fill;
+  uint8_t		inp_ctr;
+  uint8_t*		inp_buff;
+  uint8_t*		inp_buff_end;
+  uint8_t		inp_end;
+  void			(*translator)(struct ud*);
+  uint64_t		insn_offset;
+  char			insn_hexcode[32];
+  char			insn_buffer[64];
+  unsigned int		insn_fill;
+  uint8_t		dis_mode;
+  uint64_t		pc;
+  uint8_t		vendor;
+  struct map_entry*	mapen;
+  enum ud_mnemonic_code	mnemonic;
+  struct ud_operand	operand[3];
+  uint8_t		error;
+  uint8_t	 	pfx_rex;
+  uint8_t 		pfx_seg;
+  uint8_t 		pfx_opr;
+  uint8_t 		pfx_adr;
+  uint8_t 		pfx_lock;
+  uint8_t 		pfx_rep;
+  uint8_t 		pfx_repe;
+  uint8_t 		pfx_repne;
+  uint8_t 		pfx_insn;
+  uint8_t		default64;
+  uint8_t		opr_mode;
+  uint8_t		adr_mode;
+  uint8_t		br_far;
+  uint8_t		br_near;
+  uint8_t		implicit_addr;
+  uint8_t		c1;
+  uint8_t		c2;
+  uint8_t		c3;
+  uint8_t 		inp_cache[256];
+  uint8_t		inp_sess[64];
+  struct ud_itab_entry * itab_entry;
+};
+
+/* -----------------------------------------------------------------------------
+ * Type-definitions
+ * -----------------------------------------------------------------------------
+ */
+typedef enum ud_type 		ud_type_t;
+typedef enum ud_mnemonic_code	ud_mnemonic_code_t;
+
+typedef struct ud 		ud_t;
+typedef struct ud_operand 	ud_operand_t;
+
+#define UD_SYN_INTEL		ud_translate_intel
+#define UD_SYN_ATT		ud_translate_att
+#define UD_EOI			-1
+#define UD_INP_CACHE_SZ		32
+#define UD_VENDOR_AMD		0
+#define UD_VENDOR_INTEL		1
+
+#define bail_out(ud,error_code) longjmp( (ud)->bailout, error_code )
+#define try_decode(ud) if ( setjmp( (ud)->bailout ) == 0 )
+#define catch_error() else
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/udis86.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/udis86.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,156 @@
+/* -----------------------------------------------------------------------------
+ * udis86.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#endif
+
+#include "input.h"
+#include "extern.h"
+
+/* =============================================================================
+ * ud_init() - Initializes ud_t object.
+ * =============================================================================
+ */
+extern void 
+ud_init(struct ud* u)
+{
+  memset((void*)u, 0, sizeof(struct ud));
+  ud_set_mode(u, 16);
+  u->mnemonic = UD_Iinvalid;
+  ud_set_pc(u, 0);
+#ifndef __UD_STANDALONE__
+  ud_set_input_file(u, stdin);
+#endif /* __UD_STANDALONE__ */
+}
+
+/* =============================================================================
+ * ud_disassemble() - disassembles one instruction and returns the number of 
+ * bytes disassembled. A zero means end of disassembly.
+ * =============================================================================
+ */
+extern unsigned int
+ud_disassemble(struct ud* u)
+{
+  if (ud_input_end(u))
+	return 0;
+
+ 
+  u->insn_buffer[0] = u->insn_hexcode[0] = 0;
+
+ 
+  if (ud_decode(u) == 0)
+	return 0;
+  if (u->translator)
+	u->translator(u);
+  return ud_insn_len(u);
+}
+
+/* =============================================================================
+ * ud_set_mode() - Set Disassemly Mode.
+ * =============================================================================
+ */
+extern void 
+ud_set_mode(struct ud* u, uint8_t m)
+{
+  switch(m) {
+	case 16:
+	case 32:
+	case 64: u->dis_mode = m ; return;
+	default: u->dis_mode = 16; return;
+  }
+}
+
+/* =============================================================================
+ * ud_set_vendor() - Set vendor.
+ * =============================================================================
+ */
+extern void 
+ud_set_vendor(struct ud* u, unsigned v)
+{
+  switch(v) {
+	case UD_VENDOR_INTEL:
+		u->vendor = v;
+		break;
+	default:
+		u->vendor = UD_VENDOR_AMD;
+  }
+}
+
+/* =============================================================================
+ * ud_set_pc() - Sets code origin. 
+ * =============================================================================
+ */
+extern void 
+ud_set_pc(struct ud* u, uint64_t o)
+{
+  u->pc = o;
+}
+
+/* =============================================================================
+ * ud_set_syntax() - Sets the output syntax.
+ * =============================================================================
+ */
+extern void 
+ud_set_syntax(struct ud* u, void (*t)(struct ud*))
+{
+  u->translator = t;
+}
+
+/* =============================================================================
+ * ud_insn() - returns the disassembled instruction
+ * =============================================================================
+ */
+extern char* 
+ud_insn_asm(struct ud* u) 
+{
+  return u->insn_buffer;
+}
+
+/* =============================================================================
+ * ud_insn_offset() - Returns the offset.
+ * =============================================================================
+ */
+extern uint64_t
+ud_insn_off(struct ud* u) 
+{
+  return u->insn_offset;
+}
+
+
+/* =============================================================================
+ * ud_insn_hex() - Returns hex form of disassembled instruction.
+ * =============================================================================
+ */
+extern char* 
+ud_insn_hex(struct ud* u) 
+{
+  return u->insn_hexcode;
+}
+
+/* =============================================================================
+ * ud_insn_ptr() - Returns code disassembled.
+ * =============================================================================
+ */
+extern uint8_t* 
+ud_insn_ptr(struct ud* u) 
+{
+  return u->inp_sess;
+}
+
+/* =============================================================================
+ * ud_insn_len() - Returns the count of bytes disassembled.
+ * =============================================================================
+ */
+extern unsigned int 
+ud_insn_len(struct ud* u) 
+{
+  return u->inp_ctr;
+}

--MP_/61SL/dFgoelVIa2N/5RWWnn
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--MP_/61SL/dFgoelVIa2N/5RWWnn--


From xen-devel-bounces@lists.xen.org Thu Jun 07 09:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ8C-00075u-OO; Thu, 07 Jun 2012 09:35:52 +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 1ScNcW-00077K-J8
	for xen-devel@lists.xen.org; Wed, 06 Jun 2012 21:18:26 +0000
Received: from [85.158.139.83:5292] by server-12.bemta-5.messagelabs.com id
	93/56-18374-F19CFCF4; Wed, 06 Jun 2012 21:18:23 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339017489!31462131!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NTE3MA==\n,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDY4ODQgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6651 invoked from network); 6 Jun 2012 21:18:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jun 2012 21:18:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q56LHugt006974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Jun 2012 21:17:57 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
	q56LHsKJ023387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Jun 2012 21:17:55 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
	q56LHrn5005232; Wed, 6 Jun 2012 16:17:53 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Jun 2012 14:17:53 -0700
Date: Wed, 6 Jun 2012 14:17:51 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120606141751.37305f89@mantra.us.oracle.com>
In-Reply-To: <1338974024.32319.29.camel@zakaz.uk.xensource.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.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
Content-Type: multipart/mixed; boundary="MP_/61SL/dFgoelVIa2N/5RWWnn"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Thu, 07 Jun 2012 09:35:51 +0000
Cc: James Paton <paton@cs.wisc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/61SL/dFgoelVIa2N/5RWWnn
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, 6 Jun 2012 10:13:44 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-06-06 at 00:24 +0100, James Paton wrote:
> > Hi,
> > 
> > Apologies if this is not the appropriate list, but I thought I
> > would have better luck here than on xen-users.
> > 
> > I'm a CS graduate student hacking on the xen-blkback driver and
> > would like to be able to debug it using gdb over serial. I have
> > spent a great deal of time on this with no success (more details
> > can be found at http://bit.ly/KMEF6o (Stack Overflow)). 
> > 
> > It eventually occurred to me that it might not even be possible to
> > do what I'm trying to do if Xen intercepts interrupts from the
> > serial port and tries to direct them to dom0 through some
> > unexpected channel. Then, after I've done `echo g
> > > /proc/sysrq_trigger`, the kernel debugger might not see the
> > > interrupt. Can anyone confirm or disconfirm this? 
> 
> It's not something I've ever tried but I expect that if you avoid
> console=com1 (or com*) on your hypervisor command line then the com
> port should be available for dom0 just like on native.
> 
> Alternatively you could perhaps separate the two by using com1 for Xen
> and com2/ttyS1 for dom0/kdb etc.
> 
> I've no idea if kdb would be expected to work over hvc*. I suspect
> you'd be treading fresh ground with that one...
> 
> I'd also start by taking virtual box out of the equation on the host
> side. Start by using a MacOS terminal emulator and checking that you
> can see the dom0 console messages and login via a getty running on
> ttyS0 before trying to hook up gdb.
> 
> > What is the usual procedure for debugging the Dom0 kernel?
> 
> Printk ;-)
> 
> Ian.


I wrote up a debugger for xen, also (mis)named kdb. It halts the 
system, lets you poke memory, data structs, set breakpoints, etc.
To use it, you must have prior experience of a kernel debugger. I
am attaching patch build for changeset 25287 in unstable tree, if you
wanna try it. Start with kdb/README.

Mukesh


--MP_/61SL/dFgoelVIa2N/5RWWnn
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=kdb.patch

diff -r 54c8c9eaee92 xen/Makefile
--- a/xen/Makefile	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -61,6 +61,7 @@ _clean: delete-unfresh-files
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C kdb clean
 	rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET)-syms *~ core
 	rm -f include/asm-*/asm-offsets.h
 	[ -d tools/figlet ] && rm -f .banner*
@@ -129,7 +130,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h
 	  echo ""; \
 	  echo "#endif") <$< >$@
 
-SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers
+SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers kdb
 define all_sources
     ( find include/asm-$(TARGET_ARCH) -name '*.h' -print; \
       find include -name 'asm-*' -prune -o -name '*.h' -print; \
diff -r 54c8c9eaee92 xen/Rules.mk
--- a/xen/Rules.mk	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/Rules.mk	Wed Jun 06 14:17:11 2012 -0700
@@ -10,6 +10,7 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto           ?= n
+kdb           ?= n
 
 include $(XEN_ROOT)/Config.mk
 
@@ -40,6 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/d
 ALL_OBJS-y               += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(kdb)          += $(BASEDIR)/kdb/built_in.o
 
 CFLAGS-y                += -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
@@ -53,6 +55,7 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFIL
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(kdb)           += -DXEN_KDB_CONFIG
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y                += -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff -r 54c8c9eaee92 xen/arch/x86/hvm/svm/entry.S
--- a/xen/arch/x86/hvm/svm/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/svm/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -59,12 +59,23 @@ ENTRY(svm_asm_do_resume)
         get_current(bx)
         CLGI
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         testl $~0,(r(dx),r(ax),1)
         jnz  .Lsvm_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0, VCPU_nsvm_hap_enabled(r(bx))
 UNLIKELY_START(nz, nsvm_hap)
         mov  VCPU_nhvm_p2m(r(bx)),r(ax)
diff -r 54c8c9eaee92 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/svm/svm.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2170,6 +2170,10 @@ void svm_vmexit_handler(struct cpu_user_
         break;
 
     case VMEXIT_EXCEPTION_DB:
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+	    break;
+#endif
         if ( !v->domain->debugger_attached )
             goto exit_and_crash;
         domain_pause_for_debugger();
@@ -2182,6 +2186,10 @@ void svm_vmexit_handler(struct cpu_user_
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
         __update_guest_eip(regs, inst_len);
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_int3, regs))
+            break;
+#endif
         current->arch.gdbsx_vcpu_event = TRAP_int3;
         domain_pause_for_debugger();
         break;
diff -r 54c8c9eaee92 xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Wed Jun 06 14:17:11 2012 -0700
@@ -315,6 +315,36 @@ void setup_vmcb_dump(void)
     register_keyhandler('v', &vmcb_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+/* did == 0 : display for all HVM domains. domid 0 is never HVM.
+ *  * vid == -1 : display for all HVM VCPUs
+ *   */
+void kdb_dump_vmcb(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain (dp) {
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+            kdbp("  VMCB [domid: %d  vcpu:%d]:\n", dp->domain_id, vp->vcpu_id);
+            svm_vmcb_dump("kdb", vp->arch.hvm_svm.vmcb);
+            kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    rcu_read_unlock(&domlist_read_lock);
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 54c8c9eaee92 xen/arch/x86/hvm/vmx/entry.S
--- a/xen/arch/x86/hvm/vmx/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/vmx/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -124,12 +124,23 @@ vmx_asm_do_vmentry:
         get_current(bx)
         cli
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         cmpl $0,(r(dx),r(ax),1)
         jnz  .Lvmx_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0xff,VCPU_vmx_emulate(r(bx))
         jnz .Lvmx_goto_emulator
         testb $0xff,VCPU_vmx_realmode(r(bx))
diff -r 54c8c9eaee92 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Wed Jun 06 14:17:11 2012 -0700
@@ -1117,6 +1117,13 @@ void vmx_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
+#if defined(XEN_KDB_CONFIG)
+    if (kdb_dr7)
+        __vmwrite(GUEST_DR7, kdb_dr7);
+    else
+        __vmwrite(GUEST_DR7, 0);
+#endif
+
     debug_state = v->domain->debugger_attached
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_INT3]
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP];
@@ -1326,6 +1333,220 @@ void setup_vmcs_dump(void)
     register_keyhandler('v', &vmcs_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+#define GUEST_EFER      0x2806   /* see page 23-20 */
+#define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+
+/* it's a shame we can't use vmcs_dump_vcpu(), but it does vmx_vmcs_enter which
+ * will IPI other CPUs. also, print a subset relevant to software debugging */
+static void noinline kdb_print_vmcs(struct vcpu *vp)
+{
+    struct cpu_user_regs *regs = &vp->arch.user_regs;
+    unsigned long long x;
+
+    kdbp("*** Guest State ***\n");
+    kdbp("CR0: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR0),
+         (unsigned long long)vmr(CR0_READ_SHADOW), 
+         (unsigned long long)vmr(CR0_GUEST_HOST_MASK));
+    kdbp("CR4: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR4),
+         (unsigned long long)vmr(CR4_READ_SHADOW), 
+         (unsigned long long)vmr(CR4_GUEST_HOST_MASK));
+    kdbp("CR3: actual=0x%016llx, target_count=%d\n",
+         (unsigned long long)vmr(GUEST_CR3),
+         (int)vmr(CR3_TARGET_COUNT));
+    kdbp("     target0=%016llx, target1=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE0),
+         (unsigned long long)vmr(CR3_TARGET_VALUE1));
+    kdbp("     target2=%016llx, target3=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE2),
+         (unsigned long long)vmr(CR3_TARGET_VALUE3));
+    kdbp("RSP = 0x%016llx (0x%016llx)  RIP = 0x%016llx (0x%016llx)\n", 
+         (unsigned long long)vmr(GUEST_RSP),
+         (unsigned long long)regs->esp,
+         (unsigned long long)vmr(GUEST_RIP),
+         (unsigned long long)regs->eip);
+    kdbp("RFLAGS=0x%016llx (0x%016llx)  DR7 = 0x%016llx\n", 
+         (unsigned long long)vmr(GUEST_RFLAGS),
+         (unsigned long long)regs->eflags,
+         (unsigned long long)vmr(GUEST_DR7));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+         (unsigned long long)vmr(GUEST_SYSENTER_ESP),
+         (int)vmr(GUEST_SYSENTER_CS),
+         (unsigned long long)vmr(GUEST_SYSENTER_EIP));
+    vmx_dump_sel("CS", GUEST_CS_SELECTOR);
+    vmx_dump_sel("DS", GUEST_DS_SELECTOR);
+    vmx_dump_sel("SS", GUEST_SS_SELECTOR);
+    vmx_dump_sel("ES", GUEST_ES_SELECTOR);
+    vmx_dump_sel("FS", GUEST_FS_SELECTOR);
+    vmx_dump_sel("GS", GUEST_GS_SELECTOR);
+    vmx_dump_sel2("GDTR", GUEST_GDTR_LIMIT);
+    vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
+    vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
+    vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
+    kdbp("Guest PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
+    x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
+    x |= (uint32_t)vmr(TSC_OFFSET);
+    kdbp("TSC Offset = %016llx\n", x);
+    x  = (unsigned long long)vmr(GUEST_IA32_DEBUGCTL_HIGH) << 32;
+    x |= (uint32_t)vmr(GUEST_IA32_DEBUGCTL);
+    kdbp("DebugCtl=%016llx DebugExceptions=%016llx\n", x,
+           (unsigned long long)vmr(GUEST_PENDING_DBG_EXCEPTIONS));
+    kdbp("Interruptibility=%04x ActivityState=%04x\n",
+           (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
+           (int)vmr(GUEST_ACTIVITY_STATE));
+
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
+    kdbp("\n*** Host State ***\n");
+    kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
+           (unsigned long long)vmr(HOST_RSP),
+           (unsigned long long)vmr(HOST_RIP));
+    kdbp("CS=%04x DS=%04x ES=%04x FS=%04x GS=%04x SS=%04x TR=%04x\n",
+           (uint16_t)vmr(HOST_CS_SELECTOR),
+           (uint16_t)vmr(HOST_DS_SELECTOR),
+           (uint16_t)vmr(HOST_ES_SELECTOR),
+           (uint16_t)vmr(HOST_FS_SELECTOR),
+           (uint16_t)vmr(HOST_GS_SELECTOR),
+           (uint16_t)vmr(HOST_SS_SELECTOR),
+           (uint16_t)vmr(HOST_TR_SELECTOR));
+    kdbp("FSBase=%016llx GSBase=%016llx TRBase=%016llx\n",
+           (unsigned long long)vmr(HOST_FS_BASE),
+           (unsigned long long)vmr(HOST_GS_BASE),
+           (unsigned long long)vmr(HOST_TR_BASE));
+    kdbp("GDTBase=%016llx IDTBase=%016llx\n",
+           (unsigned long long)vmr(HOST_GDTR_BASE),
+           (unsigned long long)vmr(HOST_IDTR_BASE));
+    kdbp("CR0=%016llx CR3=%016llx CR4=%016llx\n",
+           (unsigned long long)vmr(HOST_CR0),
+           (unsigned long long)vmr(HOST_CR3),
+           (unsigned long long)vmr(HOST_CR4));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+           (unsigned long long)vmr(HOST_SYSENTER_ESP),
+           (int)vmr(HOST_SYSENTER_CS),
+           (unsigned long long)vmr(HOST_SYSENTER_EIP));
+    kdbp("Host PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(HOST_PAT_HIGH), (uint32_t)vmr(HOST_PAT));
+
+    kdbp("\n*** Control State ***\n");
+    kdbp("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n",
+           (uint32_t)vmr(PIN_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(CPU_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(SECONDARY_VM_EXEC_CONTROL));
+    kdbp("EntryControls=%08x ExitControls=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_CONTROLS),
+           (uint32_t)vmr(VM_EXIT_CONTROLS));
+    kdbp("ExceptionBitmap=%08x\n",
+           (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
+    kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_INTR_INFO),
+           (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("VMExit: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_EXIT_INTR_INFO),
+           (uint32_t)vmr(VM_EXIT_INTR_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("        reason=%08x qualification=%08x\n",
+           (uint32_t)vmr(VM_EXIT_REASON),
+           (uint32_t)vmr(EXIT_QUALIFICATION));
+    kdbp("IDTVectoring: info=%08x errcode=%08x\n",
+           (uint32_t)vmr(IDT_VECTORING_INFO),
+           (uint32_t)vmr(IDT_VECTORING_ERROR_CODE));
+    kdbp("TPR Threshold = 0x%02x\n",
+           (uint32_t)vmr(TPR_THRESHOLD));
+    kdbp("EPT pointer = 0x%08x%08x\n",
+           (uint32_t)vmr(EPT_POINTER_HIGH), (uint32_t)vmr(EPT_POINTER));
+    kdbp("Virtual processor ID = 0x%04x\n",
+           (uint32_t)vmr(VIRTUAL_PROCESSOR_ID));
+    kdbp("=================================================================\n");
+}
+
+/* Flush VMCS on this cpu if it needs to: 
+ *   - Upon leaving kdb, the HVM cpu will resume in vmx_vmexit_handler() and 
+ *     do __vmreads. So, the VMCS pointer can't be left cleared.
+ *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
+ *     vmlaunch must be done and not vmresume. This means, we must clear 
+ *     arch_vmx->launched.
+ */
+void kdb_curr_cpu_flush_vmcs(void)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    int ccpu = smp_processor_id();
+    struct vmcs_struct *cvp = this_cpu(current_vmcs);
+
+    if (this_cpu(current_vmcs) == NULL)
+        return;             /* no HVM active on this CPU */
+
+    kdbp("KDB:[%d] curvmcs:%lx/%lx\n", ccpu, cvp, virt_to_maddr(cvp));
+
+    /* looks like we got one. unfortunately, current_vmcs points to vmcs 
+     * and not VCPU, so we gotta search the entire list... */
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        for_each_vcpu (dp, vp) {
+            if ( vp->arch.hvm_vmx.vmcs == cvp ) {
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched = 0;
+                this_cpu(current_vmcs) = NULL;
+                kdbp("KDB:[%d] %d:%d current_vmcs:%lx flushed\n", 
+		     ccpu, dp->domain_id, vp->vcpu_id, cvp, virt_to_maddr(cvp));
+            }
+        }
+    }
+}
+
+/*
+ * domid == 0 : display for all HVM domains  (dom0 is never an HVM domain)
+ * vcpu id == -1 : display all vcpuids
+ * PreCondition: all HVM cpus (including current cpu) have flushed VMCS
+ */
+void kdb_dump_vmcs(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    struct vmcs_struct  *vmcsp;
+    u64 addr = -1;
+
+    ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
+    __vmptrst(&addr);
+
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+	    vmcsp = vp->arch.hvm_vmx.vmcs;
+            kdbp("VMCS %lx/%lx [domid:%d (%p)  vcpu:%d (%p)]:\n", vmcsp,
+	         virt_to_maddr(vmcsp), dp->domain_id, dp, vp->vcpu_id, vp);
+            __vmptrld(virt_to_maddr(vmcsp));
+            kdb_print_vmcs(vp);
+            __vmpclear(virt_to_maddr(vmcsp));
+            vp->arch.hvm_vmx.launched = 0;
+        }
+        kdbp("\n");
+    }
+    /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
+    if (addr && addr != (u64)-1)
+        __vmptrld(addr);
+}
+#endif
 
 /*
  * Local variables:
diff -r 54c8c9eaee92 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2197,11 +2197,14 @@ static void vmx_failed_vmentry(unsigned 
         printk("reason not known yet!");
         break;
     }
-
+#if defined(XEN_KDB_CONFIG)
+    kdbp("\n************* VMCS Area **************\n");
+    kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
-
+#endif
     domain_crash(curr->domain);
 }
 
@@ -2429,6 +2432,12 @@ void vmx_vmexit_handler(struct cpu_user_
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
+
+#if defined(XEN_KDB_CONFIG)
+            /* TRAP_debug: IP points correctly to next instr */
+            if (kdb_handle_trap_entry(vector, regs))
+                break;
+#endif
             domain_pause_for_debugger();
             break;
         case TRAP_int3: 
@@ -2437,6 +2446,13 @@ void vmx_vmexit_handler(struct cpu_user_
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
+#if defined(XEN_KDB_CONFIG)
+                /* vmcs.IP points to bp, kdb expects bp+1. Hence after the above
+                 * update_guest_eip which updates to bp+1. works for gdbsx too 
+                 */
+                if (kdb_handle_trap_entry(vector, regs))
+                    break;
+#endif
                 current->arch.gdbsx_vcpu_event = TRAP_int3;
                 domain_pause_for_debugger();
                 break;
@@ -2716,6 +2732,10 @@ void vmx_vmexit_handler(struct cpu_user_
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
+#if defined(XEN_KDB_CONFIG)
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+            break;
+#endif
         if ( v->arch.hvm_vcpu.single_step ) {
           hvm_memory_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
diff -r 54c8c9eaee92 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/irq.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2296,3 +2296,29 @@ bool_t hvm_domain_use_pirq(const struct 
     return is_hvm_domain(d) && pirq &&
            pirq->arch.hvm.emuirq != IRQ_UNBOUND; 
 }
+
+#ifdef XEN_KDB_CONFIG
+void kdb_prnt_guest_mapped_irqs(void)
+{
+    int irq, j;
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    kdbp("irq  vec  aff  type  domid:mapped-pirq pairs  (all in decimal)\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+        irq_guest_action_t *actp = (irq_guest_action_t *)dp->action;
+
+        if (!dp->handler ||dp->handler==&no_irq_type || !(dp->status&IRQ_GUEST))
+            continue;
+
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %3d %3s %-13s ", irq, archp->vector, affstr,
+             dp->handler->typename);
+        for (j=0; j < actp->nr_guests; j++)
+            kdbp("%03d:%04d ", actp->guest[j]->domain_id,
+                 domain_irq_to_pirq(actp->guest[j], irq));
+        kdbp("\n");
+    }
+}
+#endif
diff -r 54c8c9eaee92 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/setup.c	Wed Jun 06 14:17:11 2012 -0700
@@ -47,6 +47,13 @@
 #include <xen/cpu.h>
 #include <asm/nmi.h>
 
+#ifdef XEN_KDB_CONFIG
+#include <asm/debugger.h>
+
+int opt_earlykdb=0;
+boolean_param("earlykdb", opt_earlykdb);
+#endif
+
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
 boolean_param("nosmp", opt_nosmp);
@@ -1242,6 +1249,11 @@ void __init __start_xen(unsigned long mb
 
     trap_init();
 
+#ifdef XEN_KDB_CONFIG
+    kdb_init();
+    if (opt_earlykdb)
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+#endif
     rcu_init();
     
     early_time_init();
diff -r 54c8c9eaee92 xen/arch/x86/smp.c
--- a/xen/arch/x86/smp.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/smp.c	Wed Jun 06 14:17:11 2012 -0700
@@ -273,7 +273,7 @@ void smp_send_event_check_mask(const cpu
  * Structure and data for smp_call_function()/on_selected_cpus().
  */
 
-static void __smp_call_function_interrupt(void);
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs);
 static DEFINE_SPINLOCK(call_lock);
 static struct call_data_struct {
     void (*func) (void *info);
@@ -321,7 +321,7 @@ void on_selected_cpus(
     if ( cpumask_test_cpu(smp_processor_id(), &call_data.selected) )
     {
         local_irq_disable();
-        __smp_call_function_interrupt();
+        __smp_call_function_interrupt(NULL);
         local_irq_enable();
     }
 
@@ -390,7 +390,7 @@ void event_check_interrupt(struct cpu_us
     this_cpu(irq_count)++;
 }
 
-static void __smp_call_function_interrupt(void)
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs)
 {
     void (*func)(void *info) = call_data.func;
     void *info = call_data.info;
@@ -411,6 +411,11 @@ static void __smp_call_function_interrup
     {
         mb();
         cpumask_clear_cpu(cpu, &call_data.selected);
+#ifdef XEN_KDB_CONFIG
+        if (info && !strcmp(info, "XENKDB")) {           /* called from kdb */
+                (*(void (*)(struct cpu_user_regs *, void *))func)(regs, info);
+        } else
+#endif
         (*func)(info);
     }
 
@@ -421,5 +426,5 @@ void call_function_interrupt(struct cpu_
 {
     ack_APIC_irq();
     perfc_incr(ipis);
-    __smp_call_function_interrupt();
+    __smp_call_function_interrupt(regs);
 }
diff -r 54c8c9eaee92 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/time.c	Wed Jun 06 14:17:11 2012 -0700
@@ -2007,6 +2007,46 @@ static int __init setup_dump_softtsc(voi
 }
 __initcall(setup_dump_softtsc);
 
+#ifdef XEN_KDB_CONFIG
+void kdb_time_resume(int update_domains)
+{
+        s_time_t now;
+        int ccpu = smp_processor_id();
+        struct cpu_time *t = &this_cpu(cpu_time);
+
+        if (!plt_src.read_counter)            /* not initialized for earlykdb */
+                return;
+
+        if (update_domains) {
+                plt_stamp = plt_src.read_counter();
+                platform_timer_stamp = plt_stamp64;
+                platform_time_calibration();
+                do_settime(get_cmos_time(), 0, read_platform_stime());
+        }
+        if (local_irq_is_enabled())
+                kdbp("kdb BUG: enabled in time_resume(). ccpu:%d\n", ccpu);
+
+        rdtscll(t->local_tsc_stamp);
+        now = read_platform_stime();
+        t->stime_master_stamp = now;
+        t->stime_local_stamp  = now;
+
+        update_vcpu_system_time(current);
+
+        if (update_domains)
+                set_timer(&calibration_timer, NOW() + EPOCH);
+}
+
+void kdb_dump_time_pcpu(void)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        kdbp("[%d]: cpu_time: %016lx\n", cpu, &per_cpu(cpu_time, cpu));
+        kdbp("[%d]: cpu_calibration: %016lx\n", cpu, 
+             &per_cpu(cpu_calibration, cpu));
+    }
+}
+#endif
 /*
  * Local variables:
  * mode: C
diff -r 54c8c9eaee92 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/traps.c	Wed Jun 06 14:17:11 2012 -0700
@@ -225,7 +225,7 @@ static void show_trace(struct cpu_user_r
 
 #else
 
-static void show_trace(struct cpu_user_regs *regs)
+void show_trace(struct cpu_user_regs *regs)
 {
     unsigned long *frame, next, addr, low, high;
 
@@ -3325,6 +3325,10 @@ void do_nmi(struct cpu_user_regs *regs)
     if ( nmi_callback(regs, cpu) )
         return;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_enabled && kdb_handle_trap_entry(TRAP_nmi, regs))
+        return;
+#endif
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
 
diff -r 54c8c9eaee92 xen/arch/x86/x86_64/compat/entry.S
--- a/xen/arch/x86/x86_64/compat/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/x86_64/compat/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -95,6 +95,10 @@ compat_skip_clobber:
 /* %rbx: struct vcpu */
 ENTRY(compat_test_all_events)
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG
+        testl $1, kdb_session_begun(%rip)
+        jnz   compat_restore_all_guest
+#endif
 /*compat_test_softirqs:*/
         movl  VCPU_processor(%rbx),%eax
         shlq  $IRQSTAT_shift,%rax
diff -r 54c8c9eaee92 xen/arch/x86/x86_64/entry.S
--- a/xen/arch/x86/x86_64/entry.S	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/arch/x86/x86_64/entry.S	Wed Jun 06 14:17:11 2012 -0700
@@ -184,6 +184,10 @@ skip_clobber:
 /* %rbx: struct vcpu */
 test_all_events:
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG                   /* 64bit dom0 will resume here */
+        testl $1, kdb_session_begun(%rip)
+        jnz   restore_all_guest
+#endif
 /*test_softirqs:*/  
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
@@ -545,6 +549,13 @@ ENTRY(debug)
 
 ENTRY(int3)
         pushq $0
+#ifdef XEN_KDB_CONFIG
+        pushq %rax
+        GET_CPUINFO_FIELD(CPUINFO_processor_id, %rax)
+        movq  (%rax), %rax
+        lock  bts %rax, kdb_cpu_traps(%rip)
+        popq  %rax
+#endif
         movl  $TRAP_int3,4(%rsp)
         jmp   handle_exception
 
diff -r 54c8c9eaee92 xen/common/domain.c
--- a/xen/common/domain.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/domain.c	Wed Jun 06 14:17:11 2012 -0700
@@ -530,6 +530,14 @@ void domain_shutdown(struct domain *d, u
 {
     struct vcpu *v;
 
+#ifdef XEN_KDB_CONFIG
+    if (reason == SHUTDOWN_crash) {
+        if ( IS_PRIV(d) )
+            kdb_trap_immed(KDB_TRAP_FATAL);
+        else
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+    }
+#endif
     spin_lock(&d->shutdown_lock);
 
     if ( d->shutdown_code == -1 )
@@ -624,7 +632,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* send VIRQ_DEBUGGER to guest only if gdbsx_vcpu_event is not active */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r 54c8c9eaee92 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/sched_credit.c	Wed Jun 06 14:17:11 2012 -0700
@@ -1475,6 +1475,33 @@ csched_dump_vcpu(struct csched_vcpu *svc
     printk("\n");
 }
 
+#ifdef XEN_KDB_CONFIG
+static void kdb_csched_dump(int cpu)
+{
+    struct csched_pcpu *pcpup = CSCHED_PCPU(cpu);
+    struct vcpu *scurrvp = (CSCHED_VCPU(current))->vcpu;
+    struct list_head *tmp, *runq = RUNQ(cpu);
+
+    kdbp("    csched_pcpu: %p\n", pcpup);
+    kdbp("    curr csched:%p {vcpu:%p id:%d domid:%d}\n", (current)->sched_priv,
+         scurrvp, scurrvp->vcpu_id, scurrvp->domain->domain_id);
+    kdbp("    runq:\n");
+
+    /* next is top of struct, so screw stupid, ugly hard to follow macros */
+    if (offsetof(struct csched_vcpu, runq_elem.next) != 0) {
+        kdbp("next is not first in struct csched_vcpu. please fixme\n");
+        return;        /* otherwise for loop will crash */
+    }
+    for (tmp = runq->next; tmp != runq; tmp = tmp->next) {
+
+        struct csched_vcpu *csp = (struct csched_vcpu *)tmp;
+        struct vcpu *vp = csp->vcpu;
+        kdbp("      csp:%p pri:%02d vcpu: {p:%p id:%d domid:%d}\n", csp,
+             csp->pri, vp, vp->vcpu_id, vp->domain->domain_id);
+    };
+}
+#endif
+
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
@@ -1484,6 +1511,10 @@ csched_dump_pcpu(const struct scheduler 
     int loop;
 #define cpustr keyhandler_scratch
 
+#ifdef XEN_KDB_CONFIG
+    kdb_csched_dump(cpu);
+    return;
+#endif
     spc = CSCHED_PCPU(cpu);
     runq = &spc->runq;
 
diff -r 54c8c9eaee92 xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/schedule.c	Wed Jun 06 14:17:11 2012 -0700
@@ -1454,6 +1454,25 @@ void wait(void)
     schedule();
 }
 
+#ifdef XEN_KDB_CONFIG
+void kdb_print_sched_info(void)
+{
+    int cpu;
+
+    kdbp("Scheduler: name:%s opt_name:%s id:%d\n", ops.name, ops.opt_name,
+         ops.sched_id);
+    kdbp("per cpu schedule_data:\n");
+    for_each_online_cpu(cpu) {
+        struct schedule_data *p =  &per_cpu(schedule_data, cpu);
+        kdbp("  cpu:%d  &(per cpu)schedule_data:%p\n", cpu, p);
+        kdbp("         curr:%p sched_priv:%p\n", p->curr, p->sched_priv);
+        kdbp("\n");
+        ops.dump_cpu_state(&ops, cpu);
+        kdbp("\n");
+    }
+}
+#endif
+
 #ifdef CONFIG_COMPAT
 #include "compat/schedule.c"
 #endif
diff -r 54c8c9eaee92 xen/common/symbols.c
--- a/xen/common/symbols.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/symbols.c	Wed Jun 06 14:17:11 2012 -0700
@@ -168,3 +168,21 @@ void __print_symbol(const char *fmt, uns
 
     spin_unlock_irqrestore(&lock, flags);
 }
+
+#ifdef XEN_KDB_CONFIG
+/*
+ *  * Given a symbol, return its address 
+ *   */
+unsigned long address_lookup(char *symp)
+{
+    int i, off = 0;
+    char namebuf[KSYM_NAME_LEN+1];
+
+    for (i=0; i < symbols_num_syms; i++) {
+        off = symbols_expand_symbol(off, namebuf);
+        if (strcmp(namebuf, symp) == 0)                  /* found it */
+            return symbols_address(i);
+    }
+    return 0;
+}
+#endif
diff -r 54c8c9eaee92 xen/common/timer.c
--- a/xen/common/timer.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/common/timer.c	Wed Jun 06 14:17:11 2012 -0700
@@ -643,6 +643,48 @@ void __init timer_init(void)
     register_keyhandler('a', &dump_timerq_keyhandler);
 }
 
+#ifdef XEN_KDB_CONFIG
+#include <xen/symbols.h>
+void kdb_dump_timer_queues(void)
+{
+    struct timer  *t;
+    struct timers *ts;
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1];
+    int cpu, j;
+    u64 tsc;
+
+    for_each_online_cpu( cpu )
+    {
+        ts = &per_cpu(timers, cpu);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
+
+        /* timers in the heap */
+        for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
+            t = ts->heap[j];
+            kdbp("  %d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+        /* timers on the link list */
+        for ( t = ts->list, j = 0; t != NULL; t = t->list_next, j++ ) {
+            kdbp(" L%d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+    }
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 54c8c9eaee92 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/drivers/char/console.c	Wed Jun 06 14:17:11 2012 -0700
@@ -295,6 +295,21 @@ static void serial_rx(char c, struct cpu
 {
     static int switch_code_count = 0;
 
+#ifdef XEN_KDB_CONFIG
+    /* if ctrl-\ pressed and kdb handles it, return */
+    if (kdb_enabled && c == 0x1c) {
+        if (!kdb_session_begun) {
+            if (kdb_keyboard(regs))
+                return;
+        } else {
+            kdbp("Sorry... kdb session already active.. please try again..\n");
+            return;
+        }
+    }
+    if (kdb_session_begun)      /* kdb should already be polling */
+        return;                 /* swallow chars so they don't buffer in dom0 */
+#endif
+
     if ( switch_code && (c == switch_code) )
     {
         /* We eat CTRL-<switch_char> in groups of 3 to switch console input. */
@@ -710,6 +725,18 @@ void console_end_sync(void)
     atomic_dec(&print_everything);
 }
 
+#ifdef XEN_KDB_CONFIG
+void console_putc(char c)
+{
+    serial_putc(sercon_handle, c);
+}
+
+int console_getc(void)
+{
+    return serial_getc(sercon_handle);
+}
+#endif
+
 /*
  * printk rate limiting, lifted from Linux.
  *
diff -r 54c8c9eaee92 xen/include/asm-x86/debugger.h
--- a/xen/include/asm-x86/debugger.h	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/include/asm-x86/debugger.h	Wed Jun 06 14:17:11 2012 -0700
@@ -39,7 +39,11 @@
 #define DEBUGGER_trap_fatal(_v, _r) \
     if ( debugger_trap_fatal(_v, _r) ) return;
 
-#if defined(CRASH_DEBUG)
+#if defined(XEN_KDB_CONFIG)
+#define debugger_trap_immediate() kdb_trap_immed(KDB_TRAP_NONFATAL)
+#define debugger_trap_fatal(_v, _r) kdb_trap_fatal(_v, _r)
+
+#elif defined(CRASH_DEBUG)
 
 #include <xen/gdbstub.h>
 
@@ -70,6 +74,10 @@ static inline int debugger_trap_entry(
 {
     struct vcpu *v = current;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_handle_trap_entry(vector, regs))
+        return 1;
+#endif
     if ( guest_kernel_mode(v, regs) && v->domain->debugger_attached &&
          ((vector == TRAP_int3) || (vector == TRAP_debug)) )
     {
diff -r 54c8c9eaee92 xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/include/xen/lib.h	Wed Jun 06 14:17:11 2012 -0700
@@ -116,4 +116,7 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+#ifdef XEN_KDB_CONFIG
+#include "../../kdb/include/kdb_extern.h"
+#endif
 #endif /* __LIB_H__ */
diff -r 54c8c9eaee92 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Fri Apr 27 11:09:26 2012 +0200
+++ b/xen/include/xen/sched.h	Wed Jun 06 14:17:11 2012 -0700
@@ -576,11 +576,14 @@ extern void (*dead_idle) (void);
 unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
-
+#ifdef XEN_KDB_CONFIG
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
diff -r 54c8c9eaee92 xen/kdb/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,5 @@
+
+obj-y		+= kdbmain.o kdb_cmds.o kdb_io.o 
+
+subdir-y += x86 guest
+
diff -r 54c8c9eaee92 xen/kdb/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/README	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,243 @@
+
+Welcome to kdb for xen, a hypervisor built in debugger.
+
+FEATURES:
+   - set breakpoints in hypervisor
+   - examine virt/machine memory, registers, domains, vcpus, etc...
+   - single step, single step till jump/call, step over call to next
+     instruction after the call.
+   - examine memory of a PV/HVM guest. 
+   - set breakpoints, single step, etc... for a PV guest.
+   - breaking into the debugger will freeze the system, all CPUs will pause,
+     no interrupts are acknowledged in the debugger. (Hence, the wall clock
+     will drift)
+   - single step will step only that cpu.
+   - earlykdb: break into kdb very early during boot. Put "earlykdb" on the
+               xen command line in grub.conf.
+   - generic tracing functions (see below) for quick tracing to debug timing
+     related problems. To use:
+        o set KDBTRCMAX to max num of recs in circular trc buffer in kdbmain.c
+	o call kdb_trc() from anywhere in xen
+	o turn tracing on by setting kdb_trcon in kdbmain.c or trcon command.
+	o trcp in kdb will give hints to dump trace recs. Use dd to see buffer
+	o trcz will zero out the entire buffer if needed.
+
+NOTE:
+   - since almost all numbers are in hex, 0x is not prefixed. Instead, decimal
+     numbers are preceded by $, as in $17 (sorry, one gets used to it). Note,
+     vcpu num, cpu num, domid are always displayed in decimal, without $.
+   - watchdog must be disabled to use kdb
+
+ISSUES:
+   - Currently, debug hypervisor is not supported. Make sure NDEBUG is defined
+     or compile with debug=n
+   - "timer went backwards" messages on dom0, but kdb/hyp should be fine.
+     I usually do "echo 2 > /proc/sys/kernel/printk" when using kdb.
+   - 32bit hypervisor may hang. Tested on 64bit hypervisor only.
+    
+
+TO BUILD:
+ - do >make kdb=y
+
+HOW TO USE:
+  1. A serial line is needed to use the debugger. Set up a serial line
+     from the source machine to target victim. Make sure the serial line
+     is working properly by displaying login prompt and loging in etc....
+
+  2. Add following to grub.conf:
+        kernel /xen.kdb console=com1,vga com1=57600,8n1 dom0_mem=542M
+
+        (57600 or whatever used in step 1 above)
+
+  3. Boot the hypervisor built with the debugger. 
+
+  4. ctrl-\ (ctrl and backslash) will break into the debugger. If the system is
+     badly hung, pressing NMI would also break into it. However, once kdb is
+     entered via NMI, normal execution can't continue.
+
+  5. type 'h' for list of commands.
+
+  6. Command line editing is limited to backspace. ctrl-c to start a new cmd.
+
+
+
+GUEST debug:
+  - type sym in the debugger
+  - for REL4, grep kallsyms_names, kallsyms_addresses, and kallsyms_num_syms
+    in the guest System.map* file. Run sym again with domid and the three
+    values on the command line.
+  - Now basic symbols can be used for guest debug. Note, if the binary is not
+    built with symbols, only function names are available, but not global vars.
+
+    Eg: sym 0 c0696084 c068a590 c0696080 c06b43e8 c06b4740
+        will set symbols for dom 0. Then :
+
+        [4]xkdb> bp some_function 0
+
+	wills set bp at some_function in dom 0
+
+	[3]xkdb> dw c068a590 32 0 : display 32 bytes of dom0 memory
+
+
+Tips:
+  - In "[0]xkdb>"  : 0 is the cpu number in decimal
+  - In
+      00000000c042645c: 0:do_timer+17                  push %ebp
+    0:do_timer : 0 is the domid in hex
+    offset +17 is in hex.
+
+    absense of 0: would indicate it's a hypervisor function
+
+  - commands starting with kdb (kdb*) are for kdb debug only.
+
+
+Finally,
+ - think hex.
+ - bug/problem: enter kdbdbg, reproduce, and send me the output.
+   If the output is not enough, I may ask to run kdbdbg twice, then collect
+   output.
+
+
+Thanks,
+Mukesh Rathor
+Oracle Corporatin, 
+Redwood Shores, CA 94065
+
+--------------------------------------------------------------------------------
+COMMAND DESCRIPTION:
+
+info:  Print basic info like version, compile flags, etc..
+
+cur:  print current domain id and vcpu id
+
+f: display current stack. If a vcpu ptr is given, then print stack for that
+   VCPU by using its IP and SP.
+
+fg: display stack for a guest given domid, SP and IP.
+
+dw: display words of memory. 'num' of bytes is optional, but if displaying guest
+    memory, then is required.
+
+dd: same as above, but display doublewords.
+
+dwm: same as above but the address is machine address instead of virtual.
+
+ddm: same as above, but display doublewords.
+
+dr: display registers. if 'sp' is specified then print few extra registers.
+
+drg: display guest context saved on stack bottom.
+
+dis: disassemble instructions. If disassembling for guest, then 'num' must
+     be specified. 'num' is number of instrs to display.
+
+dism: toggle disassembly mode between Intel and ATT/GAS.
+
+mw: modify word in memory given virtual address. 'domid' may be specified if
+    modifying guest memory. value is assumed in hex even without 0x.
+
+md: same as above but modify doubleword.
+
+mr: modify register. value is assumd hex.
+
+bc: clear given or all breakpoints
+
+bp: display breakpoints or set a breakpoint. Domid may be specified to set a bp
+    in guest. kdb functions may not be specified if debugging kdb.
+    Example:
+      xkdb> bp acpi_processor_idle  : will set bp in xen
+      xkdb> bp default_idle 0 :   will set bp in domid 0
+      xkdb> bp idle_cpu 9 :   will set bp in domid 9
+
+     Conditions may be specified for a bp: lhs == rhs or lhs != rhs
+     where : lhs is register like 'r6', 'rax', etc...  or memory location
+             rhs is hex value with or without leading 0x.
+     Thus,
+      xkdb> bp acpi_processor_idle rdi == c000 
+      xkdb> bp 0xffffffff80062ebc 0 rsi == ffff880021edbc98 : will break into
+            kdb at 0xffffffff80062ebc in dom0 when rsi is ffff880021edbc98 
+
+btp: break point trace. Upon bp, print some info and continue without stopping.
+   Ex: btp idle_cpu 7 rax rbx 0x20ef5a5 r9
+
+   will print: rax, rbx, *(long *)0x20ef5a5, r9 upon hitting idle_cpu() and 
+               continue.
+
+wp: set a watchpoint at a virtual address which can belong to hypervisor or
+    any guest. Do not specify wp in kdb path if debugging kdb.
+
+wc: clear given or all watchpoints.
+
+ni: single step, stepping over function calls.
+
+ss: single step. Be carefull when in interrupt handlers or context switches.
+    
+ssb: single step to branch. Use with care.
+
+go: leave kdb and continue.
+
+cpu: go back to orig cpu when entering kdb. If 'cpu number' given, then switch 
+     to that cpu. If 'all' then show status of all cpus.
+
+nmi: Only available in hung/crash state. Send NMI to a cpu that may be hung.
+
+sym: Initialize a symbol table for debugging a guest. Look into the System.map
+     file of guest for certain symbol values and provide them here.
+
+vcpuh: Given vcpu ptr, display hvm_vcpu struct.
+
+vcpu: Display current vcpu struct. If 'vcpu-ptr' given, display that vcpu.
+
+dom: display current domain. If 'domid' then display that domid. If 'all', then
+     display all domains.
+
+sched: show schedular info and run queues.
+
+mmu: print basic mmu info
+
+p2m: convert a gpfn to mfn given a domid. value in hex even without 0x.
+
+m2p: convert mfn to pfn. value in hex even without 0x.
+
+dpage: display struct page given a mfn or struct page ptr. Since, no info is 
+       kept on page type, we display all possible page types.
+
+dtrq: display timer queues.
+
+didt: dump IDT table.
+
+dgt: dump GDT table.
+
+dirq: display IRQ bindings.
+
+dvmc: display all or given dom/vcpu VMCS or VMCB.
+
+trcon: turn tracing on. Trace hooks must be added in xen and kdb function
+       called directly from there.
+
+trcoff: turn tracing off.
+
+trcz: zero trace buffer.
+
+trcp: give hints to print the circular trace buffer, like current active ptr.
+
+usr1: allows to add any arbitraty command quickly.
+
+--------------------------------------------------------------------------------
+/*
+ * Copyright (C) 2008 Oracle.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
diff -r 54c8c9eaee92 xen/kdb/guest/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y           := kdb_guest.o
+
diff -r 54c8c9eaee92 xen/kdb/guest/kdb_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/kdb_guest.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,342 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+/* information for symbols for a guest (includeing dom 0 ) is saved here */
+struct gst_syminfo {           /* guest symbols info */
+    int   domid;               /* which domain */
+    int   bitness;             /* 32 or 64 */
+    void *addrtblp;            /* ptr to (32/64)addresses tbl */
+    u8   *toktbl;              /* ptr to kallsyms_token_table */
+    u16  *tokidxtbl;           /* ptr to kallsyms_token_index */
+    u8   *kallsyms_names;      /* ptr to kallsyms_names */
+    long  kallsyms_num_syms;   /* ptr to kallsyms_num_syms */
+    kdbva_t  stext;            /* value of _stext in guest */
+    kdbva_t  etext;            /* value of _etext in guest */
+    kdbva_t  sinittext;        /* value of _sinittext in guest */
+    kdbva_t  einittext;        /* value of _einittext in guest */
+};
+
+#define MAX_CACHE 16                              /* cache upto 16 guests */
+struct gst_syminfo gst_syminfoa[MAX_CACHE];       /* guest symbol info array */
+
+static struct gst_syminfo *
+kdb_get_syminfo_slot(void)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].addrtblp == NULL)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+static struct gst_syminfo *
+kdb_domid2syminfop(domid_t domid)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].domid == domid)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+/* check if an address looks like text address in guest */
+int
+kdb_is_addr_guest_text(kdbva_t addr, int domid)
+{
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    if (!gp || !gp->stext || !gp->etext)
+        return 0;
+    KDBGP1("guestaddr: addr:%lx domid:%d\n", addr, domid);
+
+    return ( (addr >= gp->stext && addr <= gp->etext) ||
+             (addr >= gp->sinittext && addr <= gp->einittext) );
+}
+
+/*
+ * returns: value of kallsyms_addresses[idx];
+ */
+static kdbva_t
+kdb_rd_guest_addrtbl(struct gst_syminfo *gp, int idx)
+{
+    kdbva_t addr, retaddr=0;
+    int num = gp->bitness/8;       /* whether 4 byte or 8 byte ptrs */
+    domid_t id = gp->domid;
+
+    addr = (kdbva_t)(((char *)gp->addrtblp) + idx * num);
+    KDBGP1("rdguestaddrtbl:addr:%lx idx:%d\n", addr, idx);
+
+    if (kdb_read_mem(addr, (kdbbyt_t *)&retaddr,num,id) != num) {
+        kdbp("Can't read addrtbl domid:%d at:%lx\n", id, addr);
+        return 0;
+    }
+    KDBGP1("rdguestaddrtbl:exit:retaddr:%lx\n", retaddr);
+    return retaddr;
+}
+
+/* Based on el5 kallsyms.c file. */
+static unsigned int 
+kdb_expand_el5_sym(struct gst_syminfo *gp, unsigned int off, char *result)
+{   
+    int len, skipped_first = 0;
+    u8 u8idx, *tptr, *datap;
+    domid_t domid = gp->domid;
+
+    *result = '\0';
+
+    /* get the compressed symbol length from the first symbol byte */
+    datap = gp->kallsyms_names + off;
+    len = 0;
+    if ((kdb_read_mem((kdbva_t)datap, (kdbbyt_t *)&len, 1, domid)) != 1) {
+        KDBGP("failed to read guest memory\n");
+        return 0;
+    }
+    datap++;
+
+    /* update the offset to return the offset for the next symbol on
+     * the compressed stream */
+    off += len + 1;
+
+    /* for every byte on the compressed symbol data, copy the table
+     * entry for that byte */
+    while(len) {
+        u16 u16idx, *u16p;
+        if (kdb_read_mem((kdbva_t)datap,(kdbbyt_t *)&u8idx,1,domid)!=1){
+            kdbp("memory (u8idx) read error:%p\n",gp->tokidxtbl);
+            return 0;
+        }
+        u16p = u8idx + gp->tokidxtbl;
+        if (kdb_read_mem((kdbva_t)u16p,(kdbbyt_t *)&u16idx,2,domid)!=2){
+            kdbp("tokidxtbl read error:%p\n", u16p);
+            return 0;
+        }
+        tptr = gp->toktbl + u16idx;
+        datap++;
+        len--;
+
+        while ((kdb_read_mem((kdbva_t)tptr, (kdbbyt_t *)&u8idx, 1, domid)==1) &&
+               u8idx) {
+
+            if(skipped_first) {
+                *result = u8idx;
+                result++;
+            } else
+                skipped_first = 1;
+            tptr++;
+        }
+    }
+    *result = '\0';
+    return off;          /* return to offset to the next symbol */
+}
+
+#define EL4_NMLEN 127
+/* so much pain, so not sure of it's worth .. :).. */
+static kdbva_t
+kdb_expand_el4_sym(struct gst_syminfo *gp, int low, char *result, char *symp)
+{   
+    int i, j;
+    u8 *nmp = gp->kallsyms_names;       /* guest address space */
+    kdbbyt_t byte, prefix;
+    domid_t id = gp->domid;
+    kdbva_t addr;
+
+    KDBGP1("Eel4sym:nmp:%p maxidx:$%d sym:%s\n", nmp, low, symp);
+    for (i=0; i <= low; i++) {
+        /* unsigned prefix = *name++; */
+        if (kdb_read_mem((kdbva_t)nmp, &prefix, 1, id) != 1) {
+            kdbp("failed to read:%p domid:%x\n", nmp, id);
+            return 0;
+        }
+        KDBGP2("el4:i:%d prefix:%x\n", i, prefix);
+        nmp++;
+        /* strncpy(namebuf + prefix, name, KSYM_NAME_LEN - prefix); */
+        addr = (long)result + prefix;
+        for (j=0; j < EL4_NMLEN-prefix; j++) {
+            if (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) != 1) {
+                kdbp("failed read:%p domid:%x\n", nmp, id);
+                return 0;
+            }
+            KDBGP2("el4:j:%d byte:%x\n", j, byte);
+            *(kdbbyt_t *)addr = byte;
+            addr++; nmp++;
+            if (byte == '\0')
+                break;
+        }
+        KDBGP2("el4sym:i:%d res:%s\n", i, result);
+        if (symp && strcmp(result, symp) == 0)
+            return(kdb_rd_guest_addrtbl(gp, i));
+
+        /* kallsyms.c: name += strlen(name) + 1; */
+        if (j == EL4_NMLEN-prefix && byte != '\0')
+            while (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) && byte != '\0')
+                nmp++;
+    }
+    KDBGP1("Xel4sym: na-ga-da\n");
+    return 0;
+}
+
+static unsigned int
+kdb_get_el5_symoffset(struct gst_syminfo *gp, long pos)
+{
+    int i;
+    u8 data, *namep;
+    domid_t domid = gp->domid;
+
+    namep = gp->kallsyms_names;
+    for (i=0; i < pos; i++) {
+        if (kdb_read_mem((kdbva_t)namep, &data, 1, domid) != 1) {
+            kdbp("Can't read id:$%d mem:%p\n", domid, namep);
+            return 0;
+        }
+        namep = namep + data + 1;
+    }
+    return namep - gp->kallsyms_names;
+}
+
+/*
+ * for a given guest domid (domid >= 0 && < KDB_HYPDOMID), convert addr to
+ * symbol. offset is set to  addr - symbolstart
+ */
+char *
+kdb_guest_addr2sym(unsigned long addr, domid_t domid, ulong *offsp)
+{
+    static char namebuf[KSYM_NAME_LEN+1];
+    unsigned long low, high, mid;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    *offsp = 0;
+    if(!gp || gp->kallsyms_num_syms == 0)
+        return " ??? ";
+
+    namebuf[0] = namebuf[KSYM_NAME_LEN] = '\0';
+    if (1) {
+        /* do a binary search on the sorted kallsyms_addresses array */
+        low = 0;
+        high = gp->kallsyms_num_syms;
+
+        while (high-low > 1) {
+            mid = (low + high) / 2;
+            if (kdb_rd_guest_addrtbl(gp, mid) <= addr) 
+                low = mid;
+            else 
+                high = mid;
+        }
+        /* Grab name */
+        if (gp->toktbl) {
+            int symoff = kdb_get_el5_symoffset(gp,low);
+            kdb_expand_el5_sym(gp, symoff, namebuf);
+        } else
+            kdb_expand_el4_sym(gp, low, namebuf, NULL);
+        *offsp = addr - kdb_rd_guest_addrtbl(gp, low);
+        return namebuf;
+    }
+    return " ???? ";
+}
+
+
+/* 
+ * save guest (dom0 and others) symbols info : domid and following addresses:
+ *     &kallsyms_names &kallsyms_addresses &kallsyms_num_syms \
+ *     &kallsyms_token_table &kallsyms_token_index
+ */
+void
+kdb_sav_dom_syminfo(domid_t domid, long namesp, long addrap, long nump,
+                    long toktblp, long tokidxp)
+{
+    int bytes;
+    long val = 0;    /* must be set to zero for 32 on 64 cases */
+    struct gst_syminfo *gp = kdb_get_syminfo_slot();
+
+    if (gp == NULL) {
+        kdbp("kdb:kdb_sav_dom_syminfo():Table full.. symbols not saved\n");
+        return;
+    }
+    memset(gp, 0, sizeof(*gp));
+
+    gp->domid = domid;
+    gp->bitness = kdb_guest_bitness(domid);
+    gp->addrtblp = (void *)addrap;
+    gp->kallsyms_names = (u8 *)namesp;
+    gp->toktbl = (u8 *)toktblp;
+    gp->tokidxtbl = (u16 *)tokidxp;
+
+    KDBGP("domid:%x bitness:$%d numsyms:$%ld arrayp:%p\n", domid,
+          gp->bitness, gp->kallsyms_num_syms, gp->addrtblp);
+
+    bytes = gp->bitness/8;
+    if (kdb_read_mem(nump, (kdbbyt_t *)&val, bytes, domid) != bytes) {
+
+        kdbp("Unable to read number of symbols from:%lx\n", nump);
+        memset(gp, 0, sizeof(*gp));
+        return;
+    } else
+        kdbp("Number of symbols:$%ld\n", val);
+
+    gp->kallsyms_num_syms = val;
+
+    bytes = (gp->bitness/8) * gp->kallsyms_num_syms;
+    gp->stext = kdb_guest_sym2addr("_stext", domid);
+    gp->etext = kdb_guest_sym2addr("_etext", domid);
+    if (!gp->stext || !gp->etext)
+        kdbp("Warn: Can't find stext/etext\n");
+
+    if (gp->toktbl && gp->tokidxtbl) {
+        gp->sinittext = kdb_guest_sym2addr("_sinittext", domid);
+        gp->einittext = kdb_guest_sym2addr("_einittext", domid);
+        if (!gp->sinittext || !gp->einittext) {
+            kdbp("Warn: Can't find sinittext/einittext\n");
+    } 
+    }
+    KDBGP1("stxt:%lx etxt:%lx sitxt:%lx eitxt:%lx\n", gp->stext, gp->etext,
+           gp->sinittext, gp->einittext);
+    kdbp("Succesfully saved symbol info\n");
+}
+
+/*
+ * given a symbol string for a guest/domid, return its address
+ */
+kdbva_t
+kdb_guest_sym2addr(char *symp, domid_t domid)
+{
+    char namebuf[KSYM_NAME_LEN+1];
+    int i, off=0;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    KDBGP("sym2a: sym:%s domid:%x numsyms:%ld\n", symp, domid,
+          gp ? gp->kallsyms_num_syms: -1);
+
+    if (!gp)
+        return 0;
+
+    if (gp->toktbl == 0 || gp->tokidxtbl == 0)
+        return(kdb_expand_el4_sym(gp, gp->kallsyms_num_syms, namebuf, symp));
+
+    for (i=0; i < gp->kallsyms_num_syms; i++) {
+        off = kdb_expand_el5_sym(gp, off, namebuf);
+        KDBGP1("i:%d namebuf:%s\n", i, namebuf);
+        if (strcmp(namebuf, symp) == 0) {
+            return(kdb_rd_guest_addrtbl(gp, i));
+        }
+    }
+    KDBGP("sym2a:exit:na-ga-da\n");
+    return 0;
+}
diff -r 54c8c9eaee92 xen/kdb/include/kdb_extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdb_extern.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDB_EXTERN_H
+#define _KDB_EXTERN_H
+
+#define KDB_TRAP_FATAL     1    /* trap is fatal. can't resume from kdb */
+#define KDB_TRAP_NONFATAL  2    /* can resume from kdb */
+#define KDB_TRAP_KDBSTACK  3    /* to debug kdb itself. dump kdb stack */
+
+/* following can be called from anywhere in xen to debug */
+extern void kdb_trap_immed(int);
+extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
+extern void kdbp(const char *fmt, ...);
+
+typedef unsigned long kdbva_t;
+typedef unsigned char kdbbyt_t;
+typedef unsigned long kdbma_t;
+
+extern unsigned long kdb_dr7;
+
+
+extern volatile int kdb_session_begun;
+extern volatile int kdb_enabled;
+extern void kdb_init(void);
+extern int kdb_keyboard(struct cpu_user_regs *);
+extern void kdb_ssni_reenter(struct cpu_user_regs *);
+extern int kdb_handle_trap_entry(int, struct cpu_user_regs *);
+extern int kdb_trap_fatal(int, struct cpu_user_regs *);  /* fatal with regs */
+extern void kdb_dump_vmcs(uint16_t did, int vid);
+void kdb_dump_vmcb(uint16_t did, int vid);
+extern void kdb_dump_time_pcpu(void);
+
+
+#define VMPTRST_OPCODE  ".byte 0x0f,0xc7\n"     /* reg/opcode: /7 */
+#define MODRM_EAX_07    ".byte 0x38\n"          /* [EAX], with reg/opcode: /7 */
+static inline void __vmptrst(u64 *addr)
+{
+    asm volatile ( VMPTRST_OPCODE
+                   MODRM_EAX_07
+                   :
+                   : "a" (addr)
+                   : "memory");
+}
+
+extern void mukchk(unsigned long);
+#define is_hvm_or_hyb_domain is_hvm_domain
+#define is_hvm_or_hyb_vcpu is_hvm_vcpu
+
+
+#endif  /* _KDB_EXTERN_H */
diff -r 54c8c9eaee92 xen/kdb/include/kdbdefs.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbdefs.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBDEFS_H
+#define _KDBDEFS_H
+
+/* reason we are entering kdbmain (bp == breakpoint) */
+typedef enum {
+    KDB_REASON_KEYBOARD=1,  /* Keyboard entry - always 1 */
+    KDB_REASON_BPEXCP,      /* #BP excp: sw bp (INT3) */
+    KDB_REASON_DBEXCP,      /* #DB excp: TF flag or HW bp */
+    KDB_REASON_PAUSE_IPI,   /* received pause IPI from another CPU */
+} kdb_reason_t;
+
+
+/* cpu state: past, present, and future */
+typedef enum {
+    KDB_CPU_INVAL=0,     /* invalid value. not in or leaving kdb */
+    KDB_CPU_QUIT,        /* main cpu does GO. all others do QUIT */
+    KDB_CPU_PAUSE,       /* cpu is paused */
+    KDB_CPU_DISABLE,     /* disable interrupts */
+    KDB_CPU_SHOWPC,      /* all cpus must display their pc */
+    KDB_CPU_DO_VMEXIT,   /* all cpus must do vmcs vmexit. intel only */
+    KDB_CPU_MAIN_KDB,    /* cpu in kdb main command loop */
+    KDB_CPU_GO,          /* user entered go for this cpu */
+    KDB_CPU_SS,          /* single step for this cpu */
+    KDB_CPU_NI,          /* go to next instr after the call instr */
+    KDB_CPU_INSTALL_BP,  /* delayed install of sw bp(s) by this cpu */
+} kdb_cpu_cmd_t;
+
+/* ============= kdb commands ============================================= */
+
+typedef kdb_cpu_cmd_t (*kdb_func_t)(int, const char **, struct cpu_user_regs *);
+typedef kdb_cpu_cmd_t (*kdb_usgf_t)(void);
+
+typedef enum {
+    KDB_REPEAT_NONE = 0,    /* Do not repeat this command */
+    KDB_REPEAT_NO_ARGS,     /* Repeat the command without arguments */
+    KDB_REPEAT_WITH_ARGS,   /* Repeat the command including its arguments */
+} kdb_repeat_t;
+
+typedef struct _kdbtab {
+    char        *kdb_cmd_name;        /* Command name */
+    kdb_func_t   kdb_cmd_func;        /* ptr to function to execute command */
+    kdb_usgf_t   kdb_cmd_usgf;        /* usage function ptr */
+    int          kdb_cmd_crash_avail; /* available in sys fatal/crash state */
+    kdb_repeat_t kdb_cmd_repeat;      /* Does command auto repeat on enter? */
+} kdbtab_t;
+
+
+/* ============= types and stuff ========================================= */
+#define BFD_INVAL (~0UL)            /* invalid bfd_vma */
+
+#if defined(__x86_64__)
+  #define KDBIP rip
+  #define KDBSP rsp
+#else
+  #define KDBIP eip
+  #define KDBSP esp
+#endif
+
+/* ============= macros ================================================== */
+extern volatile int kdbdbg;
+#define KDBGP(...) {(kdbdbg) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP3(...) {0;};
+
+#define KDBMIN(x,y) (((x)<(y))?(x):(y))
+
+#endif  /* !_KDBDEFS_H */
diff -r 54c8c9eaee92 xen/kdb/include/kdbinc.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbinc.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBINC_H
+#define _KDBINC_H
+
+#include <xen/compile.h>
+#include <xen/config.h>
+#include <xen/version.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/mm.h>
+#include <xen/event.h>
+#include <xen/time.h>
+#include <xen/console.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/rangeset.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/delay.h>
+#include <xen/shutdown.h>
+#include <xen/percpu.h>
+#include <xen/multicall.h>
+#include <xen/rcupdate.h>
+#include <xen/ctype.h>
+#include <xen/symbols.h>
+#include <xen/shutdown.h>
+#include <xen/serial.h>
+#include <xen/grant_table.h>
+#include <asm/debugger.h>
+#include <asm/shared.h>
+#include <asm/apicdef.h>
+
+#include <asm/nmi.h>
+#include <asm/p2m.h>
+#include <asm/debugreg.h>
+#include <public/sched.h>
+#include <public/vcpu.h>
+#ifdef _XEN_LATEST
+#include <xsm/xsm.h>
+#endif
+
+#include <asm/hvm/vmx/vmx.h>
+
+#include "kdb_extern.h"
+#include "kdbdefs.h"
+#include "kdbproto.h"
+
+#endif /* !_KDBINC_H */
diff -r 54c8c9eaee92 xen/kdb/include/kdbproto.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbproto.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBPROTO_H
+#define _KDBPROTO_H
+
+/* hypervisor interfaces use by kdb or kdb interfaces in xen files */
+extern void console_putc(char);
+extern int console_getc(void);
+extern void show_trace(struct cpu_user_regs *);
+extern void kdb_dump_timer_queues(void);
+extern void kdb_time_resume(int);
+extern void kdb_print_sched_info(void);
+extern void kdb_curr_cpu_flush_vmcs(void);
+extern unsigned long address_lookup(char *);
+extern void kdb_prnt_guest_mapped_irqs(void);
+
+/* kdb globals */
+extern kdbtab_t *kdb_cmd_tbl;
+extern char kdb_prompt[32];
+extern volatile int kdb_sys_crash;
+extern volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+extern volatile int kdb_trcon;
+
+/* kdb interfaces */
+extern void __init kdb_io_init(void);
+extern void kdb_init_cmdtab(void);
+extern void kdb_do_cmds(struct cpu_user_regs *);
+extern int kdb_check_sw_bkpts(struct cpu_user_regs *);
+extern int kdb_check_watchpoints(struct cpu_user_regs *);
+extern void kdb_do_watchpoints(kdbva_t, int, int);
+extern void kdb_install_watchpoints(void);
+extern void kdb_clear_wps(int);
+extern kdbma_t kdb_rd_dbgreg(int);
+
+
+
+extern char *kdb_get_cmdline(char *);
+extern void kdb_clear_prev_cmd(void);
+extern void kdb_toggle_dis_syntax(void);
+extern int kdb_check_call_instr(domid_t, kdbva_t);
+extern void kdb_display_pc(struct cpu_user_regs *);
+extern kdbva_t kdb_print_instr(kdbva_t, long, domid_t);
+extern int kdb_read_mmem(kdbva_t, kdbbyt_t *, int);
+extern int kdb_read_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+extern int kdb_write_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+
+extern void kdb_install_all_swbp(void);
+extern void kdb_uninstall_all_swbp(void);
+extern int kdb_swbp_exists(void);
+extern void kdb_flush_swbp_table(void);
+extern int kdb_is_addr_guest_text(kdbva_t, int);
+extern kdbva_t kdb_guest_sym2addr(char *, domid_t);
+extern char *kdb_guest_addr2sym(unsigned long, domid_t, ulong *);
+extern void kdb_prnt_addr2sym(domid_t, kdbva_t, char *);
+extern void kdb_sav_dom_syminfo(domid_t, long, long, long, long, long);
+extern int kdb_guest_bitness(domid_t);
+extern void kdb_nmi_pause_cpus(cpumask_t);
+
+extern void kdb_trczero(void);
+void kdb_trcp(void);
+
+
+
+#endif /* !_KDBPROTO_H */
diff -r 54c8c9eaee92 xen/kdb/kdb_cmds.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_cmds.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3774 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+#if defined(__x86_64__)
+    #define KDBF64 "%lx"
+    #define KDBFL "%016lx"         /* print long all digits */
+#else
+    #define KDBF64 "%llx"
+    #define KDBFL "%08lx"
+#endif
+
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    #define KDB_LKDEF(l) ((l).raw.lock)
+    #define KDB_PGLLE(t) ((t).tail)    /* page list last element ^%$#@ */
+#else
+    #define KDB_LKDEF(l) ((l).lock)
+    #define KDB_PGLLE(t) ((t).prev)    /* page list last element ^%$#@ */
+#endif
+
+#define KDB_CMD_HISTORY_COUNT   32
+#define CMD_BUFLEN              200     /* kdb_printf: max printline == 256 */
+
+#define KDBMAXSBP 16                    /* max number of software breakpoints */
+#define KDB_MAXARGC 16                  /* max args in a kdb command */
+#define KDB_MAXBTP  8                   /* max display args in btp */
+
+/* condition is: 'r6 == 0x123f' or '0xffffffff82800000 != deadbeef'  */
+struct kdb_bpcond {
+    kdbbyt_t bp_cond_status;       /* 0 == off, 1 == register, 2 == memory */
+    kdbbyt_t bp_cond_type;         /* 0 == bad, 1 == equal, 2 == not equal */
+    ulong    bp_cond_lhs;          /* lhs of condition: reg offset or mem loc */
+    ulong    bp_cond_rhs;          /* right hand side of condition */
+};
+
+/* software breakpoint structure */
+struct kdb_sbrkpt {
+    kdbva_t  bp_addr;              /* address the bp is set at */
+    domid_t  bp_domid;             /* which domain the bp belongs to */
+    kdbbyt_t bp_originst;          /* save orig instr/s here */
+    kdbbyt_t bp_deleted;           /* delete pending on this bp */
+    kdbbyt_t bp_ni;                /* set for KDB_CPU_NI */
+    kdbbyt_t bp_just_added;        /* added in the current kdb session */
+    kdbbyt_t bp_type;              /* 0 = normal, 1 == cond,  2 == btp */
+    union {
+        struct kdb_bpcond bp_cond;
+        ulong *bp_btp;
+    } u;
+};
+
+/* don't use kmalloc in kdb which hijacks all cpus */
+static ulong kdb_btp_argsa[KDBMAXSBP][KDB_MAXBTP];
+static ulong *kdb_btp_ap[KDBMAXSBP];
+
+static struct kdb_reg_nmofs {
+    char *reg_nm;
+    int reg_offs;
+} kdb_reg_nm_offs[] =  {
+       { "rax", offsetof(struct cpu_user_regs, rax) },
+       { "rbx", offsetof(struct cpu_user_regs, rbx) },
+       { "rcx", offsetof(struct cpu_user_regs, rcx) },
+       { "rdx", offsetof(struct cpu_user_regs, rdx) },
+       { "rsi", offsetof(struct cpu_user_regs, rsi) },
+       { "rdi", offsetof(struct cpu_user_regs, rdi) },
+       { "rbp", offsetof(struct cpu_user_regs, rbp) },
+       { "rsp", offsetof(struct cpu_user_regs, rsp) },
+       { "r8",  offsetof(struct cpu_user_regs, r8) },
+       { "r9",  offsetof(struct cpu_user_regs, r9) },
+       { "r10", offsetof(struct cpu_user_regs, r10) },
+       { "r11", offsetof(struct cpu_user_regs, r11) },
+       { "r12", offsetof(struct cpu_user_regs, r12) },
+       { "r13", offsetof(struct cpu_user_regs, r13) },
+       { "r14", offsetof(struct cpu_user_regs, r14) },
+       { "r15", offsetof(struct cpu_user_regs, r15) },
+       { "rflags", offsetof(struct cpu_user_regs, rflags) } };
+
+static const int KDBBPSZ=1;                   /* size of KDB_BPINST is 1 byte*/
+static kdbbyt_t kdb_bpinst = 0xcc;            /* breakpoint instr: INT3 */
+static struct kdb_sbrkpt kdb_sbpa[KDBMAXSBP]; /* soft brkpt array/table */
+static kdbtab_t *tbp;
+
+static int kdb_set_bp(domid_t, kdbva_t, int, ulong *, char*, char*, char*);
+static void kdb_print_uregs(struct cpu_user_regs *);
+
+
+/* ===================== cmdline functions  ================================ */
+
+/* lp points to a string of only alpha numeric chars terminated by '\n'.
+ * Parse the string into argv pointers, and RETURN argc
+ * Eg:  if lp --> "dr  sp\n" :  argv[0]=="dr\0"  argv[1]=="sp\0"  argc==2
+ */
+static int
+kdb_parse_cmdline(char *lp, const char **argv)
+{
+    int i=0;
+
+    for (; *lp == ' '; lp++);      /* note: isspace() skips '\n' also */
+    while ( *lp != '\n' ) {
+        if (i == KDB_MAXARGC) {
+            printk("kdb: max args exceeded\n");
+            break;
+        }
+        argv[i++] = lp;
+        for (; *lp != ' ' && *lp != '\n'; lp++);
+        if (*lp != '\n')
+            *lp++ = '\0';
+        for (; *lp == ' '; lp++);
+    }
+    *lp = '\0';
+    return i;
+}
+
+void
+kdb_clear_prev_cmd()             /* so previous command is not repeated */
+{
+    tbp = NULL;
+}
+
+void
+kdb_do_cmds(struct cpu_user_regs *regs)
+{
+    char *cmdlinep;
+    const char *argv[KDB_MAXARGC];
+    int argc = 0, curcpu = smp_processor_id();
+    kdb_cpu_cmd_t result = KDB_CPU_MAIN_KDB;
+
+    snprintf(kdb_prompt, sizeof(kdb_prompt), "[%d]xkdb> ", curcpu);
+
+    while (result == KDB_CPU_MAIN_KDB) {
+        cmdlinep = kdb_get_cmdline(kdb_prompt);
+        if (*cmdlinep == '\n') {
+            if (tbp==NULL || tbp->kdb_cmd_func==NULL)
+                continue;
+            else
+                argc = -1;    /* repeat prev command */
+        } else {
+            argc = kdb_parse_cmdline(cmdlinep, argv);
+            for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_func; tbp++)  {
+                if (strcmp(argv[0], tbp->kdb_cmd_name)==0) 
+                    break;
+            }
+        }
+        if (kdb_sys_crash && tbp->kdb_cmd_func && !tbp->kdb_cmd_crash_avail) {
+            kdbp("cmd not available in fatal/crashed state....\n");
+            continue;
+        }
+        if (tbp->kdb_cmd_func) {
+            result = (*tbp->kdb_cmd_func)(argc, argv, regs);
+            if (tbp->kdb_cmd_repeat == KDB_REPEAT_NONE)
+                tbp = NULL;
+        } else
+            kdbp("kdb: Unknown cmd: %s\n", cmdlinep);
+    }
+    kdb_cpu_cmd[curcpu] = result;
+    return;
+}
+
+/* ===================== Util functions  ==================================== */
+
+int
+kdb_vcpu_valid(struct vcpu *in_vp)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    for(dp=domain_list; in_vp && dp; dp=dp->next_in_list)
+        for_each_vcpu(dp, vp)
+            if (in_vp == vp)
+                return 1;
+    return 0;     /* not found */
+}
+
+/*
+ * Given a symbol, find it's address
+ */
+static kdbva_t
+kdb_sym2addr(const char *p, domid_t domid)
+{
+    kdbva_t addr;
+
+    KDBGP1("sym2addr: p:%s domid:%d\n", p, domid);
+    if (domid == DOMID_IDLE)
+        addr = address_lookup((char *)p);
+    else
+        addr = (kdbva_t)kdb_guest_sym2addr((char *)p, domid);
+    KDBGP1("sym2addr: exit: addr returned:0x%lx\n", addr);
+    return addr;
+}
+
+/*
+ * convert ascii to int decimal (base 10). 
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2deci(const char *strp, int *intp)
+{
+    const char *endp;
+
+    KDBGP2("str2deci: str:%s\n", strp);
+    if (!isdigit(*strp))
+        return 0;
+    *intp = (int)simple_strtoul(strp, &endp, 10);
+    if (endp != strp+strlen(strp))
+        return 0;
+    KDBGP2("str2deci: intval:$%d\n", *intp);
+    return 1;
+}
+/*
+ * convert ascii to long. NOTE: base is 16
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2ulong(const char *strp, ulong *longp)
+{
+    ulong val;
+    const char *endp;
+
+    KDBGP2("str2long: str:%s\n", strp);
+    if (!isxdigit(*strp))
+        return 0;
+    val = (long)simple_strtoul(strp, &endp, 16);   /* handles leading 0x */
+    if (endp != strp+strlen(strp))
+        return 0;
+    if (longp)
+        *longp = val;
+    KDBGP2("str2long: val:0x%lx\n", val);
+    return 1;
+}
+/*
+ * convert a symbol or ascii address to hex address
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2addr(const char *strp, kdbva_t *addrp, domid_t id)
+{
+    kdbva_t addr;
+    const char *endp;
+
+    /* assume it's an address */
+    KDBGP2("str2addr: str:%s id:%d\n", strp, id);
+    addr = (kdbva_t)simple_strtoul(strp, &endp, 16); /*handles leading 0x */
+    if (endp != strp+strlen(strp))
+        if ( !(addr=kdb_sym2addr(strp, id)) )
+            return 0;
+    *addrp = addr;
+    KDBGP2("str2addr: addr:0x%lx\n", addr);
+    return 1;
+}
+
+/* Given domid, return ptr to struct domain 
+ * IF domid == DOMID_IDLE return ptr to idle_domain 
+ * IF domid == valid domain, return ptr to domain struct
+ * else domid is bad and return NULL
+ */
+static struct domain *
+kdb_domid2ptr(domid_t domid)
+{
+    struct domain *dp;
+
+    /* get_domain_by_id() ret NULL for both DOMID_IDLE and bad domids */
+    if (domid == DOMID_IDLE)
+        dp = idle_vcpu[smp_processor_id()]->domain;
+    else 
+        dp = get_domain_by_id(domid);   /* NULL now means bad domid */
+    return dp;
+}
+
+/*
+ * Returns:  0: failed. invalid domid or string, *idp not changed.
+ */
+static int
+kdb_str2domid(const char *domstr, domid_t *idp, int perr)
+{
+    int id;
+    if (!kdb_str2deci(domstr, &id) || !kdb_domid2ptr((domid_t)id)) {
+        if (perr)
+            kdbp("Invalid domid:%s\n", domstr);
+        return 0;
+    }
+    *idp = (domid_t)id;
+    return 1;
+}
+
+static struct domain *
+kdb_strdomid2ptr(const char *domstr, int perror)
+{
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
+}
+
+/* return a guest bitness: 32 or 64 */
+int
+kdb_guest_bitness(domid_t domid)
+{
+    const int HYPSZ = sizeof(long) * 8;
+    struct domain *dp = kdb_domid2ptr(domid);
+    int retval; 
+
+    if (is_idle_domain(dp))
+        retval = HYPSZ;
+    else if (is_hvm_or_hyb_domain(dp))
+        retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
+    else 
+        retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
+    KDBGP1("gbitness: domid:%d dp:%p bitness:%d\n", domid, dp, retval);
+    return retval;
+}
+
+/* kdb_print_spin_lock(&xyz_lock, "xyz_lock:", "\n"); */
+static void
+kdb_print_spin_lock(char *strp, spinlock_t *lkp, char *nlp)
+{
+    kdbp("%s %04hx %d %d%s", strp, KDB_LKDEF(*lkp), lkp->recurse_cpu,
+         lkp->recurse_cnt, nlp);
+}
+
+/* check if register string is valid. if yes, return offset to the register
+ * in cpu_user_regs, else return -1 */
+static int
+kdb_valid_reg(const char *nmp) 
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (strcmp(kdb_reg_nm_offs[i].reg_nm, nmp) == 0)
+            return kdb_reg_nm_offs[i].reg_offs;
+    return -1;
+}
+
+/* given offset of register, return register name string. if offset is invalid
+ * return NULL */
+static char *kdb_regoffs_to_name(int offs)
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (kdb_reg_nm_offs[i].reg_offs == offs)
+            return kdb_reg_nm_offs[i].reg_nm;
+    return NULL;
+}
+
+/* ===================== util struct funcs ================================= */
+static void
+kdb_prnt_timer(struct timer *tp)
+{
+#if XEN_SUBVERSION == 0 
+    kdbp(" expires:%016lx expires_end:%016lx cpu:%d status:%x\n", tp->expires, 
+         tp->expires_end, tp->cpu, tp->status);
+#else
+    kdbp(" expires:%016lx cpu:%d status:%x\n", tp->expires, tp->cpu,tp->status);
+#endif
+    kdbp(" function data:%p ptr:%p ", tp->data, tp->function);
+    kdb_prnt_addr2sym(DOMID_IDLE, (kdbva_t)tp->function, "\n");
+}
+
+static void 
+kdb_prnt_periodic_time(struct periodic_time *ptp)
+{
+    kdbp(" next:%p prev:%p\n", ptp->list.next, ptp->list.prev);
+    kdbp(" on_list:%d one_shot:%d dont_freeze:%d irq_issued:%d src:%x irq:%x\n",
+         ptp->on_list, ptp->one_shot, ptp->do_not_freeze, ptp->irq_issued,
+         ptp->source, ptp->irq);
+    kdbp(" vcpu:%p pending_intr_nr:%08x period:%016lx\n", ptp->vcpu,
+         ptp->pending_intr_nr, ptp->period);
+    kdbp(" scheduled:%016lx last_plt_gtime:%016lx\n", ptp->scheduled,
+         ptp->last_plt_gtime);
+    kdbp(" \n          timer info:\n");
+    kdb_prnt_timer(&ptp->timer);
+    kdbp("\n");
+}
+
+/* ===================== cmd functions  ==================================== */
+
+/*
+ * FUNCTION: Disassemble instructions
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dis(void)
+{
+    kdbp("dis [addr|sym][num][domid] : Disassemble instrs\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dis(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int num = 8;                           /* display 8 instr by default */
+    static kdbva_t addr = BFD_INVAL;
+    static domid_t domid;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dis();
+
+    if (argc != -1)      /* not a command repeat */
+        domid = guest_mode(regs) ?  current->domain->domain_id : DOMID_IDLE;
+
+    if (argc >= 4 && !kdb_str2domid(argv[3], &domid, 1)) { 
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc >= 3 && !kdb_str2deci(argv[2], &num)) {
+        kdbp("kdb:Invalid num\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc > 1 && !kdb_str2addr(argv[1], &addr, domid)) {
+        kdbp("kdb:Invalid addr/sym\n");
+        kdbp("(num has to be specified if providing domid)\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc == 1)                    /* not command repeat */
+        addr = regs->KDBIP;           /* PC is the default */
+    else if (addr == BFD_INVAL) {
+        kdbp("kdb:Invalid addr/sym\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    addr = kdb_print_instr(addr, num, domid);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* FUNCTION: kdb_cmdf_dism() Toggle disassembly syntax from Intel to ATT/GAS */
+static kdb_cpu_cmd_t
+kdb_usgf_dism(void)
+{
+    kdbp("dism: toggle disassembly mode between ATT/GAS and INTEL\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dism(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dism();
+
+    kdb_toggle_dis_syntax();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+_kdb_show_guest_stack(domid_t domid, kdbva_t ipaddr, kdbva_t spaddr)
+{
+    kdbva_t val;
+    int num=0, max=0, rd = kdb_guest_bitness(domid)/8;
+
+    kdb_print_instr(ipaddr, 1, domid);
+    KDBGP("_guest_stack:sp:%lx domid:%d rd:$%d\n", spaddr, domid, rd);
+    val = 0;                          /* must zero, in case guest is 32bit */
+    while((kdb_read_mem(spaddr,(kdbbyt_t *)&val,rd,domid)==rd) && num < 16){
+        KDBGP1("gstk:addr:%lx val:%lx\n", spaddr, val);
+        if (kdb_is_addr_guest_text(val, domid)) {
+            kdb_print_instr(val, 1, domid);
+            num++;
+        }
+        if (max++ > 10000)            /* don't walk down the stack forever */
+            break;                    /* 10k is chosen randomly */
+        spaddr += rd;
+    }
+}
+
+/* Read guest memory and display address that looks like text. */
+static void
+kdb_show_guest_stack(struct cpu_user_regs *regs, struct vcpu *vcpup)
+{
+    kdbva_t ipaddr=regs->KDBIP, spaddr = regs->KDBSP;
+    domid_t domid = vcpup->domain->domain_id;
+
+    ASSERT(domid != DOMID_IDLE);
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+}
+
+/* display stack. if vcpu ptr given, then display stack for that. Otherwise,
+ * use current regs */
+static kdb_cpu_cmd_t
+kdb_usgf_f(void)
+{
+    kdbp("f [vcpu-ptr]: dump current/vcpu stack\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_f(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_f();
+
+    if (argc > 1 ) {
+        struct vcpu *vp;
+        if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp)) {
+            kdbp("kdb: Bad VCPU ptr:%s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdb_show_guest_stack(&vp->arch.user_regs, vp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs))
+        kdb_show_guest_stack(regs, current);
+    else
+        show_trace(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an spaddr and domid for guest, dump stack */
+static kdb_cpu_cmd_t
+kdb_usgf_fg(void)
+{
+    kdbp("fg domid RIP ESP: dump guest stack given domid, RIP, and ESP\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_fg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid;
+    kdbva_t ipaddr, spaddr;
+
+    if (argc != 4) 
+        return kdb_usgf_fg();
+
+    if (kdb_str2domid(argv[1], &domid, 1)==0) {
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[2], &ipaddr)==0) {
+        kdbp("Bad ipaddr:%s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[3], &spaddr)==0) {
+        kdbp("Bad spaddr:%s\n", argv[3]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display kdb stack. for debugging kdb itself */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbf(void)
+{
+    kdbp("kdbf: display kdb stack. for debugging kdb only\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_kdbf(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbf();
+
+    kdb_trap_immed(KDB_TRAP_KDBSTACK);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* worker function to display memory. Request could be for any guest, domid.
+ * Also address could be machine or virtual */
+static void
+_kdb_display_mem(kdbva_t *addrp, int *lenp, int wordsz, int domid, int is_maddr)
+{
+    #define DDBUFSZ 4096
+
+    kdbbyt_t buf[DDBUFSZ], *bp;
+    int numrd, bytes;
+    int len = *lenp;
+    kdbva_t addr = *addrp;
+
+    /* round len down to wordsz boundry because on intel endian, printing
+     * characters is not prudent, (long and ints can't be interpreted 
+     * easily) */
+    len &= ~(wordsz-1);
+    len = KDBMIN(DDBUFSZ, len);
+    len = len ? len : wordsz;
+
+    KDBGP("dmem:addr:%lx buf:%p len:$%d domid:%d sz:$%d maddr:%d\n", addr,
+          buf, len, domid, wordsz, is_maddr);
+    if (is_maddr)
+        numrd=kdb_read_mmem((kdbma_t)addr, buf, len);
+    else
+        numrd=kdb_read_mem(addr, buf, len, domid);
+    if (numrd != len)
+        kdbp("Memory read error. Bytes read:$%d\n", numrd);
+
+    for (bp = buf; numrd > 0;) {
+        kdbp("%016lx: ", addr); 
+
+        /* display 16 bytes per line */
+        for (bytes=0; bytes < 16 && numrd > 0; bytes += wordsz) {
+            if (numrd >= wordsz) {
+                if (wordsz == 8)
+                    kdbp(" %016lx", *(long *)bp);
+                else
+                    kdbp(" %08x", *(int *)bp);
+                bp += wordsz;
+                numrd -= wordsz;
+                addr += wordsz;
+            }
+        }
+        kdbp("\n");
+        continue;
+    }
+    *lenp = len;
+    *addrp = addr;
+}
+
+/* display machine mem, ie, the given address is machine address */
+static kdb_cpu_cmd_t 
+kdb_display_mmem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbma_t maddr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&maddr, &len, wordsz, id, 1);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                                     /* default read len */
+
+    if (!kdb_str2ulong(argv[1], &maddr)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_display_mem(&maddr, &len, wordsz, 0, 1);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dwm(void)
+{
+    kdbp("dwm:  maddr|sym [num] : dump memory word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dwm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 4, kdb_usgf_dwm);
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ddm(void)
+{
+    kdbp("ddm:  maddr|sym [num] : dump double word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ddm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 8, kdb_usgf_ddm);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory : word or doubleword
+ *           wordsz : bytes in word. 4 or 8
+ *
+ *           We display upto BUFSZ bytes. User can just press enter for more.
+ *           addr is always in hex with or without leading 0x
+ */
+static kdb_cpu_cmd_t 
+kdb_display_mem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbva_t addr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&addr, &len, wordsz, id, 0);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    id = DOMID_IDLE;                /* not a command repeat, reset dom id */
+    if (argc >= 4) { 
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                       /* default read len */
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    _kdb_display_mem(&addr, &len, wordsz, id, 0);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dw(void)
+{
+    kdbp("dw vaddr|sym [num][domid] : dump mem word. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 4, kdb_usgf_dw);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dd(void)
+{
+    kdbp("dd vaddr|sym [num][domid] : dump dword. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dd(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 8, kdb_usgf_dd);
+}
+
+/* 
+ * FUNCTION: Modify Memory Word 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mw(void)
+{
+    kdbp("mw vaddr|sym val [domid] : modify memory word in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_mw();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val, 4, id) != 4)
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_md(void)
+{
+    kdbp("md vaddr|sym val [domid] : modify memory dword in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_md(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_md();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) {
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val,sizeof(val),id) != sizeof(val))
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct  Xgt_desc_struct {
+    unsigned short size;
+    unsigned long address __attribute__((packed));
+};
+
+void
+kdb_show_special_regs(struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    unsigned short tr;                 /* Task Register segment selector */
+    __u64 efer;
+
+    kdbp("\nSpecial Registers:\n");
+    __asm__ __volatile__ ("sidt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("IDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+    __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("GDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+
+    kdbp("cr0: %016lx  cr2: %016lx\n", read_cr0(), read_cr2());
+    kdbp("cr3: %016lx  cr4: %016lx\n", read_cr3(), read_cr4());
+    __asm__ __volatile__ ("str (%0) \n":: "a"(&tr) : "memory");
+    kdbp("TR: %x\n", tr);
+
+    rdmsrl(MSR_EFER, efer);    /* IA32_EFER */
+    kdbp("efer:"KDBF64" LMA(IA-32e mode):%d SCE(syscall/sysret):%d\n",
+         efer, ((efer&EFER_LMA) != 0), ((efer&EFER_SCE) != 0));
+
+    kdbp("DR0: %016lx  DR1:%016lx  DR2:%016lx\n", kdb_rd_dbgreg(0),
+         kdb_rd_dbgreg(1), kdb_rd_dbgreg(2)); 
+    kdbp("DR3: %016lx  DR6:%016lx  DR7:%016lx\n", kdb_rd_dbgreg(3),
+         kdb_rd_dbgreg(6), kdb_rd_dbgreg(7)); 
+}
+
+/* 
+ * FUNCTION: Dispaly Registers. If "sp" argument, then display additional regs
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dr(void)
+{
+    kdbp("dr [sp]: display registers. sp to display special regs also\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dr();
+
+    KDBGP1("regs:%p .rsp:%lx .rip:%lx\n", regs, regs->rsp, regs->rip);
+    show_registers(regs);
+    if (argc > 1 && !strcmp(argv[1], "sp")) 
+        kdb_show_special_regs(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* show registers on stack bottom where guest context is. same as dr if
+ * not running in guest mode */
+static kdb_cpu_cmd_t
+kdb_usgf_drg(void)
+{
+    kdbp("drg: display active guest registers at stack bottom\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_drg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_drg();
+
+    kdbp("\tNote: ds/es/fs/gs etc.. are not saved from the cpu\n");
+    kdb_print_uregs(guest_cpu_user_regs());
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Register
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mr(void)
+{
+    kdbp("mr reg val : Modify Register. val assumed in hex\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int regoffs;
+    ulong val;
+
+    if (argc != 3 || !kdb_str2ulong(argv[2], &val)) {
+        return kdb_usgf_mr();
+    }
+    argp = argv[1];
+
+#if defined(__x86_64__)
+    if ((regoffs=kdb_valid_reg(argp)) != -1)
+        *((uint64_t *)((char *)regs+regoffs)) = val;
+#else
+    if (!strcmp(argp, "eax"))
+        regs->eax = val;
+    else if (!strcmp(argp, "ebx"))
+        regs->ebx = val;
+    else if (!strcmp(argp, "ecx"))
+        regs->ecx = val;
+    else if (!strcmp(argp, "edx"))
+        regs->edx = val;
+    else if (!strcmp(argp, "esi"))
+        regs->esi = val;
+    else if (!strcmp(argp, "edi"))
+        regs->edi = val;
+    else if (!strcmp(argp, "ebp"))
+        regs->ebp = val;
+    else if (!strcmp(argp, "esp"))
+        regs->esp = val;
+    else if (!strcmp(argp, "eflags") || !strcmp(argp, "rflags"))
+        regs->eflags = val;
+#endif
+    else
+        kdbp("Error. Bad register : %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Single Step
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ss(void)
+{
+    kdbp("ss: single step\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ss(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    #define KDB_HALT_INSTR 0xf4
+
+    kdbbyt_t byte;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ss();
+
+    KDBGP("enter kdb_cmdf_ss \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_read_mem(regs->KDBIP, &byte, 1, id) == 1) {
+        if (byte == KDB_HALT_INSTR) {
+            kdbp("kdb: jumping over halt instruction\n");
+            regs->KDBIP++;
+        }
+    } else {
+        kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
+        current->arch.hvm_vcpu.single_step = 1;
+    } else
+        regs->eflags |= X86_EFLAGS_TF;
+
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Next Instruction, step over the call instr to the next instr
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ni(void)
+{
+    kdbp("ni: single step, stepping over function calls\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ni(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int sz, i;
+    domid_t id=guest_mode(regs) ? current->domain->domain_id:DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ni();
+
+    KDBGP("enter kdb_cmdf_ni \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if ((sz=kdb_check_call_instr(id, regs->KDBIP)) == 0)  /* !call instr */
+        return kdb_cmdf_ss(argc, argv, regs);         /* just do ss */
+
+    if ((i=kdb_set_bp(id, regs->KDBIP+sz, 1,0,0,0,0)) >= KDBMAXSBP) /* failed */
+        return KDB_CPU_MAIN_KDB;
+
+    kdb_sbpa[i].bp_ni = 1;
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+        current->arch.hvm_vcpu.single_step = 0;
+    else
+        regs->eflags &= ~X86_EFLAGS_TF;
+
+    return KDB_CPU_NI;
+}
+
+static void
+kdb_btf_enable(void)
+{
+    u64 debugctl;
+    rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 0x2);
+}
+
+/* 
+ * FUNCTION: Single Step to branch. Doesn't seem to work very well.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ssb(void)
+{
+    kdbp("ssb: singe step to branch\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ssb(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ssb();
+
+    KDBGP("MUK: enter kdb_cmdf_ssb\n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (is_hvm_or_hyb_vcpu(current)) 
+        current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
+
+    regs->eflags |= X86_EFLAGS_TF;
+    kdb_btf_enable();
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Continue Execution. TF must be cleared here as this could run on 
+ *           any cpu. Hence not OK to do it from kdb_end_session.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_go(void)
+{
+    kdbp("go: leave kdb and continue execution\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_go(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_go();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    return KDB_CPU_GO;
+}
+
+/* All cpus must display their current context */
+static kdb_cpu_cmd_t 
+kdb_cpu_status_all(int ccpu, struct cpu_user_regs *regs)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)   /* hung cpu */
+                continue;
+            kdb_cpu_cmd[cpu] = KDB_CPU_SHOWPC;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_SHOWPC);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * display/switch CPU. 
+ *  Argument:
+ *     none:   just go back to initial cpu
+ *     cpunum: switch to given vpu
+ *     "all":  show one line status of all cpus
+ */
+extern volatile int kdb_init_cpu;
+static kdb_cpu_cmd_t
+kdb_usgf_cpu(void)
+{
+    kdbp("cpu [all|num]: none will switch back to initial cpu\n");
+    kdbp("               cpunum to switch to the vcpu. all to show status\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_cpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+    int ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cpu();
+
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all"))
+            return kdb_cpu_status_all(ccpu, regs);
+
+            cpu = (int)simple_strtoul(argv[1], NULL, 0); /* handles 0x */
+            if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && 
+                cpu_online(cpu) && kdb_cpu_cmd[cpu] == KDB_CPU_PAUSE)
+            {
+                kdbp("Switching to cpu:%d\n", cpu);
+                kdb_cpu_cmd[cpu] = KDB_CPU_MAIN_KDB;
+
+                /* clear any single step on the current cpu */
+                regs->eflags &= ~X86_EFLAGS_TF;
+                return KDB_CPU_PAUSE;
+            } else {
+                if (cpu != ccpu)
+                    kdbp("Unable to switch to cpu:%d\n", cpu);
+                else {
+                    kdb_display_pc(regs);
+                }
+                return KDB_CPU_MAIN_KDB;
+            }
+    }
+    /* no arg means back to initial cpu */
+    if (!kdb_sys_crash && ccpu != kdb_init_cpu) {
+        if (kdb_cpu_cmd[kdb_init_cpu] == KDB_CPU_PAUSE) {
+            regs->eflags &= ~X86_EFLAGS_TF;
+            kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_MAIN_KDB;
+            return KDB_CPU_PAUSE;
+        } else
+            kdbp("Unable to switch to: %d\n", kdb_init_cpu);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* send NMI to all or given CPU. Must be crashed/fatal state */
+static kdb_cpu_cmd_t
+kdb_usgf_nmi(void)
+{
+    kdbp("nmi cpu#|all: send nmi cpu/s. must reboot when done with kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_nmi(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    cpumask_t cpumask;
+    int ccpu = smp_processor_id();
+
+    if (argc <= 1 || (argc > 1 && *argv[1] == '?'))
+        return kdb_usgf_nmi();
+
+    if (!kdb_sys_crash) {
+        kdbp("kdb: nmi cmd available in crashed state only\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!strcmp(argv[1], "all"))
+        cpumask = cpu_online_map;
+    else {
+        int cpu = (int)simple_strtoul(argv[1], NULL, 0);
+        if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && cpu_online(cpu))
+            cpumask = *cpumask_of(cpu);
+        else {
+            kdbp("KDB nmi: invalid cpu %s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    kdb_nmi_pause_cpus(cpumask);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_percpu(void)
+{
+    kdbp("percpu: display per cpu pointers\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_percpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_percpu();
+    kdb_dump_time_pcpu();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ========================= Breakpoints ==================================== */
+
+static void
+kdb_prnt_bp_cond(int bpnum)
+{
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {
+        kdbp("     ( %s %c%c %lx )\n", 
+             kdb_regoffs_to_name(bpcp->bp_cond_lhs),
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    } else {
+        kdbp("     ( %lx %c%c %lx )\n", bpcp->bp_cond_lhs,
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    }
+}
+
+static void
+kdb_prnt_bp_extra(int bpnum)
+{
+    if (kdb_sbpa[bpnum].bp_type == 2) {
+        ulong i, arg, *btp = kdb_sbpa[bpnum].u.bp_btp;
+        
+        kdbp("   will trace ");
+        for (i=0; i < KDB_MAXBTP && btp[i]; i++)
+            if ((arg=btp[i]) < sizeof (struct cpu_user_regs)) {
+                kdbp(" %s ", kdb_regoffs_to_name(arg));
+            } else {
+                kdbp(" %lx ", arg);
+            }
+        kdbp("\n");
+
+    } else if (kdb_sbpa[bpnum].bp_type == 1)
+        kdb_prnt_bp_cond(bpnum);
+}
+
+/*
+ * List software breakpoints
+ */
+static kdb_cpu_cmd_t
+kdb_display_sbkpts(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted) {
+            struct domain *dp = kdb_domid2ptr(kdb_sbpa[i].bp_domid);
+
+            if (dp == NULL || dp->is_dying) {
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                continue;
+            }
+            kdbp("[%d]: domid:%d 0x%lx   ", i, 
+                 kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr);
+            kdb_prnt_addr2sym(kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr,"\n");
+            kdb_prnt_bp_extra(i);
+        }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Check if any breakpoints that we need to install (delayed install)
+ * Returns: 1 if yes, 0 if none.
+ */
+int
+kdb_swbp_exists(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+/*
+ * Check if any breakpoints were deleted this kdb session
+ * Returns: 0 if none, 1 if yes
+ */
+static int
+kdb_swbp_deleted(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+
+/*
+ * Flush deleted sw breakpoints
+ */
+void
+kdb_flush_swbp_table(void)
+{
+    int i;
+    KDBGP("ccpu:%d flush_swbp_table: deleted:%x\n", smp_processor_id(), 
+          kdb_swbp_deleted());
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted) {
+            KDBGP("flush:[%x] addr:0x%lx\n",i,kdb_sbpa[i].bp_addr);
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        }
+}
+
+/*
+ * Delete/Clear a sw breakpoint
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bc(void)
+{
+    kdbp("bc $num|all : clear given or all breakpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, bpnum = -1, delall = 0;
+    const char *argp;
+
+    if (argc != 2 || *argv[1] == '?')
+        return kdb_usgf_bc();
+
+    if (!kdb_swbp_exists()) {
+        kdbp("No breakpoints are set\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        delall = 1;
+    else if (!kdb_str2deci(argp, &bpnum) || bpnum < 0 || bpnum > KDBMAXSBP) {
+        kdbp("Invalid bpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (delall && kdb_sbpa[i].bp_addr) {
+            kdbp("Deleted breakpoint [%x] addr:0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            continue;
+        }
+        if (bpnum != -1 && bpnum == i) {
+            kdbp("Deleted breakpoint [%x] at 0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            break;
+        }
+    }
+    if (i >= KDBMAXSBP && !delall)
+        kdbp("Unable to delete breakpoint: %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Install a breakpoint in the given array entry
+ * Returns: 0 : failed to install
+ *          1 : installed successfully
+ */
+static int
+kdb_install_swbp(int idx)                   /* which entry in the bp array */
+{
+    kdbva_t addr = kdb_sbpa[idx].bp_addr;
+    domid_t domid = kdb_sbpa[idx].bp_domid;
+    kdbbyt_t *p = &kdb_sbpa[idx].bp_originst;
+    struct domain *dp = kdb_domid2ptr(domid);
+
+    if (dp == NULL || dp->is_dying) {
+        memset(&kdb_sbpa[idx], 0, sizeof(kdb_sbpa[idx]));
+        kdbp("Removed bp %d addr:%p domid:%d\n", idx, addr, domid);
+        return 0;
+    }
+
+    if (kdb_read_mem(addr, p, KDBBPSZ, domid) != KDBBPSZ){
+        kdbp("Failed(R) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    if (kdb_write_mem(addr, &kdb_bpinst, KDBBPSZ, domid) != KDBBPSZ) {
+        kdbp("Failed(W) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    KDBGP("install_swbp: installed bp:%x at:0x%lx ccpu:%x domid:%d\n",
+          idx, kdb_sbpa[idx].bp_addr, smp_processor_id(), domid);
+    return 1;
+}
+
+/*
+ * Install all the software breakpoints
+ */
+void
+kdb_install_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_deleted && kdb_sbpa[i].bp_addr)
+            kdb_install_swbp(i);
+}
+
+static void
+kdb_uninstall_a_swbp(int i)
+{
+    kdbva_t addr = kdb_sbpa[i].bp_addr;
+    kdbbyt_t originst = kdb_sbpa[i].bp_originst;
+    domid_t id = kdb_sbpa[i].bp_domid;
+
+    kdb_sbpa[i].bp_just_added = 0;
+    if (!addr)
+        return;
+    if (kdb_write_mem(addr, &originst, KDBBPSZ, id) != KDBBPSZ) {
+        kdbp("Failed to uninstall breakpoint %x at:0x%lx domid:%d\n",
+             i, kdb_sbpa[i].bp_addr, id);
+    }
+}
+
+/*
+ * Uninstall all the software breakpoints at beginning of kdb session
+ */
+void
+kdb_uninstall_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++) 
+        kdb_uninstall_a_swbp(i);
+    KDBGP("ccpu:%d uninstalled all bps\n", smp_processor_id());
+}
+
+/* RETURNS: rc == 2: condition was not met,  rc == 3: condition was met */
+static int
+kdb_check_bp_condition(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong res = 0, lhsval=0;
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {             /* register condition */
+        uint64_t *rp = (uint64_t *)((char *)regs + bpcp->bp_cond_lhs);
+        lhsval = *rp;
+    } else if (bpcp->bp_cond_status == 2) {      /* memaddr condition */
+        ulong addr = bpcp->bp_cond_lhs;
+        int num = sizeof(lhsval);
+
+        if (kdb_read_mem(addr, (kdbbyt_t *)&lhsval, num, domid) != num) {
+            kdbp("kdb: unable to read %d bytes at %lx\n", num, addr);
+            return 3;
+        }
+    }
+    if (bpcp->bp_cond_type == 1)                 /* lhs == rhs */
+        res = (lhsval == bpcp->bp_cond_rhs);
+    else                                         /* lhs != rhs */
+        res = (lhsval != bpcp->bp_cond_rhs);
+
+    if (!res)
+        kdbp("KDB: [%d]Ignoring bp:%d condition not met. val:%lx\n", 
+              smp_processor_id(), bpnum, lhsval); 
+
+    KDBGP1("bpnum:%d domid:%d cond: %d %d %lx %lx res:%d\n", bpnum, domid, 
+           bpcp->bp_cond_status, bpcp->bp_cond_type, bpcp->bp_cond_lhs, 
+           bpcp->bp_cond_rhs, res);
+
+    return (res ? 3 : 2);
+}
+
+static void
+kdb_prnt_btp_info(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong i, arg, val, num, *btp = kdb_sbpa[bpnum].u.bp_btp;
+
+    kdb_prnt_addr2sym(domid, regs->KDBIP, "\n");
+    num = kdb_guest_bitness(domid)/8;
+    for (i=0; i < KDB_MAXBTP && (arg=btp[i]); i++) {
+        if (arg < sizeof (struct cpu_user_regs)) {
+            uint64_t *rp = (uint64_t *)((char *)regs + arg);
+            kdbp(" %s: %016lx ", kdb_regoffs_to_name(arg), *rp);
+        } else {
+            if (kdb_read_mem(arg, (kdbbyt_t *)&val, num, domid) != num)
+                kdbp("kdb: unable to read %d bytes at %lx\n", num, arg);
+            if (num == 8)
+                kdbp(" %016lx:%016lx ", arg, val);
+            else
+                kdbp(" %08lx:%08lx ", arg, val);
+        }
+    }
+    kdbp("\n");
+    KDBGP1("bpnum:%d domid:%d btp:%p num:%d\n", bpnum, domid, btp, num);
+}
+
+/*
+ * Check if the BP trap belongs to us. 
+ * Return: 0 : not one of ours. IP not changed. (leave kdb)
+ *         1 : one of ours but deleted. IP decremented. (leave kdb)
+ *         2 : one of ours but condition not met, or btp. IP decremented.(leave)
+ *         3 : one of ours and active. IP decremented. (stay in kdb)
+ */
+int 
+kdb_check_sw_bkpts(struct cpu_user_regs *regs)
+{
+    int i, rc=0;
+    domid_t curid;
+
+    curid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    for(i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_domid == curid  && 
+            kdb_sbpa[i].bp_addr == (regs->KDBIP- KDBBPSZ)) {
+
+            regs->KDBIP -= KDBBPSZ;
+            rc = 3;
+
+            if (kdb_sbpa[i].bp_ni) {
+                kdb_uninstall_a_swbp(i);
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            } else if (kdb_sbpa[i].bp_deleted) {
+                rc = 1;
+            } else if (kdb_sbpa[i].bp_type == 1) {
+                rc = kdb_check_bp_condition(i, regs, curid);
+            } else if (kdb_sbpa[i].bp_type == 2) {
+                kdb_prnt_btp_info(i, regs, curid);
+                rc = 2;
+            }
+            KDBGP1("ccpu:%d rc:%d curid:%d domid:%d addr:%lx\n", 
+                   smp_processor_id(), rc, curid, kdb_sbpa[i].bp_domid, 
+                   kdb_sbpa[i].bp_addr);
+            break;
+        }
+    }
+    return (rc);
+}
+
+/* Eg: r6 == 0x123EDF  or 0xFFFF2034 != 0xDEADBEEF
+ * regoffs: -1 means lhs is not reg. else offset of reg in cpu_user_regs
+ * addr: memory location if lhs is not register, eg, 0xFFFF2034
+ * condp : points to != or ==
+ * rhsval : right hand side value
+ */
+static void
+kdb_set_bp_cond(int bpnum, int regoffs, ulong addr, char *condp, ulong rhsval)
+{
+    if (bpnum >= KDBMAXSBP) {
+        kdbp("BUG: %s got invalid bpnum\n", __FUNCTION__);
+        return;
+    }
+    if (regoffs != -1) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 1;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = regoffs;
+    } else if (addr != 0) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 2;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = addr;
+    } else {
+        kdbp("error: invalid call to kdb_set_bp_cond\n");
+        return;
+    }
+    kdb_sbpa[bpnum].u.bp_cond.bp_cond_rhs = rhsval;
+
+    if (*condp == '!')
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 2;
+    else
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 1;
+}
+
+/* install breakpt at given addr. 
+ * ni: bp for next instr 
+ * btpa: ptr to args for btp for printing when bp is hit
+ * lhsp/condp/rhsp: point to strings of condition
+ *
+ * RETURNS: the index in array where installed. KDBMAXSBP if error 
+ */
+static int
+kdb_set_bp(domid_t domid, kdbva_t addr, int ni, ulong *btpa, char *lhsp, 
+           char *condp, char *rhsp)
+{
+    int i, pre_existing = 0, regoffs = -1;
+    ulong memloc=0, rhsval=0, tmpul;
+
+    if (btpa && (lhsp || rhsp || condp)) {
+        kdbp("internal error. btpa and (lhsp || rhsp || condp) set\n");
+        return KDBMAXSBP;
+    }
+    if (lhsp && ((regoffs=kdb_valid_reg(lhsp)) == -1)  &&
+        kdb_str2ulong(lhsp, &memloc) &&
+        kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0) {
+
+        kdbp("error: invalid argument: %s\n", lhsp);
+        return KDBMAXSBP;
+    }
+    if (rhsp && ! kdb_str2ulong(rhsp, &rhsval)) {
+        kdbp("error: invalid argument: %s\n", rhsp);
+        return KDBMAXSBP;
+    }
+
+    /* see if bp already set */
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_addr==addr && kdb_sbpa[i].bp_domid==domid) {
+
+            if (kdb_sbpa[i].bp_deleted) {
+                /* just re-set this bp again */
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                pre_existing = 1;
+            } else {
+                kdbp("Breakpoint already set \n");
+                return KDBMAXSBP;
+            }
+        }
+    }
+    /* see if any room left for another breakpoint */
+    for (i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_addr)
+            break;
+    if (i >= KDBMAXSBP) {
+        kdbp("ERROR: Breakpoint table full....\n");
+        return i;
+    }
+    kdb_sbpa[i].bp_addr = addr;
+    kdb_sbpa[i].bp_domid = domid;
+    if (btpa) {
+        kdb_sbpa[i].bp_type = 2;
+        kdb_sbpa[i].u.bp_btp = btpa;
+    } else if (regoffs != -1 || memloc) {
+        kdb_sbpa[i].bp_type = 1;
+        kdb_set_bp_cond(i, regoffs, memloc, condp, rhsval);
+    } else
+        kdb_sbpa[i].bp_type = 0;
+
+    if (kdb_install_swbp(i)) {                  /* make sure it can be done */
+        if (ni)
+            return i;
+
+        kdb_uninstall_a_swbp(i);                /* dont' show user INT3 */
+        if (!pre_existing)               /* make sure no is cpu sitting on it */
+            kdb_sbpa[i].bp_just_added = 1;
+
+        kdbp("bp %d set for domid:%d at: 0x%lx ", i, kdb_sbpa[i].bp_domid, 
+             kdb_sbpa[i].bp_addr);
+        kdb_prnt_addr2sym(domid, addr, "\n");
+        kdb_prnt_bp_extra(i);
+    } else {
+        kdbp("ERROR:Can't install bp: 0x%lx domid:%d\n", addr, domid);
+        if (pre_existing)     /* in case a cpu is sitting on this bp in traps */
+            kdb_sbpa[i].bp_deleted = 1;
+        else
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        return KDBMAXSBP;
+    }
+    /* make sure swbp reporting is enabled in the vmcb/vmcs */
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        struct domain *dp = kdb_domid2ptr(domid);
+        dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
+        KDBGP("debugger_attached set. domid:%d\n", domid);
+    }
+    return i;
+}
+
+/* 
+ * Set/List Software Breakpoint/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bp(void)
+{
+    kdbp("bp [addr|sym][domid][condition]: display or set a breakpoint\n");
+    kdbp("  where cond is like: r6 == 0x123F or rax != DEADBEEF or \n");
+    kdbp("       ffff82c48038fe58 == 321E or 0xffff82c48038fe58 != 0\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9");
+    kdbp(" r10 r11 r12 r13 r14 r15 rflags\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    int idx = -1;
+    domid_t domid = DOMID_IDLE;
+    char *domidstrp, *lhsp=NULL, *condp=NULL, *rhsp=NULL;
+
+    if ((argc > 1 && *argv[1] == '?') || argc == 4 || argc > 6)
+        return kdb_usgf_bp();
+
+    if (argc < 2 || kdb_sys_crash)         /* list all set breakpoints */
+        return kdb_display_sbkpts();
+
+    /* valid argc either: 2 3 5 or 6 
+     * 'bp idle_loop r6 == 0xc000' OR 'bp idle_loop 3 r9 != 0xdeadbeef' */
+    idx = (argc == 5) ? 2 : ((argc == 6) ? 3 : idx);
+    if (argc >= 5 ) {
+        lhsp = (char *)argv[idx];
+        condp = (char *)argv[idx+1];
+        rhsp = (char *)argv[idx+2];
+
+        if (!kdb_str2ulong(rhsp, NULL) || *(condp+1) != '=' || 
+            (*condp != '=' && *condp != '!')) {
+
+            return kdb_usgf_bp();
+        }
+    }
+    domidstrp = (argc == 3 || argc == 6 ) ? (char *)argv[2] : NULL;
+    if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
+        return kdb_usgf_bp();
+    }
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        kdbp("HVM domain not supported yet for conditional bp\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    /* make sure xen addr is in xen text, otherwise bp set in 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_set_bp(domid, addr, 0, NULL, lhsp, condp, rhsp);     /* 0 is ni flag */
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* trace breakpoint, meaning, upon bp trace/print some info and continue */
+
+static kdb_cpu_cmd_t
+kdb_usgf_btp(void)
+{
+    kdbp("btp addr|sym [domid] reg|domid-mem-addr... : breakpoint trace\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9 ");
+    kdbp("r10 r11 r12 r13 r14 r15 rflags\n");
+    kdbp("  Eg. btp idle_cpu 7 rax rbx 0x20ef5a5 r9\n");
+    kdbp("      will print rax, rbx, *(long *)0x20ef5a5, r9 and continue\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_btp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, btpidx, numrd, argsidx, regoffs = -1;
+    kdbva_t addr, memloc=0;
+    domid_t domid = DOMID_IDLE;
+    ulong *btpa, tmpul;
+
+    if ((argc > 1 && *argv[1] == '?') || argc < 3)
+        return kdb_usgf_btp();
+
+    argsidx = 2;                   /* assume 3rd arg is not domid */
+    if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
+
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+            kdbp("HVM domains are not currently supprted\n");
+            return KDB_CPU_MAIN_KDB;
+        } else
+            argsidx = 3;               /* 3rd arg is a domid */
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    /* make sure xen addr is in xen text, otherwise will trace 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    numrd = kdb_guest_bitness(domid)/8;
+    if (kdb_read_mem(addr, (kdbbyt_t *)&tmpul, numrd, domid) != numrd) {
+        kdbp("Unable to read mem from %s (%lx)\n", argv[1], addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    for (btpidx=0; btpidx < KDBMAXSBP && kdb_btp_ap[btpidx]; btpidx++);
+    if (btpidx >= KDBMAXSBP) {
+        kdbp("error: table full. delete few breakpoints\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    btpa = kdb_btp_argsa[btpidx];
+    memset(btpa, 0, sizeof(kdb_btp_argsa[0]));
+
+    for (i=0; argv[argsidx]; i++, argsidx++) {
+
+        if (((regoffs=kdb_valid_reg(argv[argsidx])) == -1)  &&
+            kdb_str2ulong(argv[argsidx], &memloc) &&
+            (memloc < sizeof (struct cpu_user_regs) ||
+            kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0)){
+
+            kdbp("error: invalid argument: %s\n", argv[argsidx]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        if (i >= KDB_MAXBTP) {
+            kdbp("error: cannot specify more than %d args\n", KDB_MAXBTP);
+            return KDB_CPU_MAIN_KDB;
+        }
+        btpa[i] = (regoffs == -1) ? memloc : regoffs;
+    }
+
+    i = kdb_set_bp(domid, addr, 0, btpa, 0, 0, 0);     /* 0 is ni flag */
+    if (i < KDBMAXSBP)
+        kdb_btp_ap[btpidx] = kdb_btp_argsa[btpidx];
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * Set/List watchpoints, ie, hardware breakpoint/s, in hypervisor
+ *   Usage: wp [sym|addr] [w|i]   w == write only data watchpoint
+ *                                i == IO watchpoint (read/write)
+ *
+ *   Eg:  wp        : list all watchpoints set
+ *        wp addr   : set a read/write wp at given addr
+ *        wp addr w : set a write only wp at given addr
+ *        wp addr i : set an IO wp at given addr (16bits port #)
+ *
+ *  TBD: allow to be set on particular cpu
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_wp(void)
+{
+    kdbp("wp [addr|sym][w|i]: display or set watchpoint. writeonly or IO\n");
+    kdbp("\tnote: watchpoint is triggered after the instruction executes\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    domid_t domid = DOMID_IDLE;
+    int rw = 3, len = 4;       /* for now just default to 4 bytes len */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_wp();
+
+    if (argc <= 1 || kdb_sys_crash) {       /* list all set watchpoints */
+        kdb_do_watchpoints(0, 0, 0);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2) {
+        if (!strcmp(argv[2], "w"))
+            rw = 1;
+        else if (!strcmp(argv[2], "i"))
+            rw = 2;
+        else {
+            return kdb_usgf_wp();
+        }
+    }
+    kdb_do_watchpoints(addr, rw, len);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_wc(void)
+{
+    kdbp("wc $num|all : clear given or all watchpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int wpnum;              /* wp num to delete. -1 for all */
+
+    if (argc != 2 || *argv[1] == '?') 
+        return kdb_usgf_wc();
+
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        wpnum = -1;
+    else if (!kdb_str2deci(argp, &wpnum)) {
+        kdbp("Invalid wpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_clear_wps(wpnum);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display struct hvm_vcpu{} in struct vcpu.arch{} */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpuh(void)
+{
+    kdbp("vcpuh vcpu-ptr : display hvm_vcpu struct\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpuh(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *vp;
+    struct hvm_vcpu *hvp;
+    struct hvm_io_op *ioop;
+    struct vlapic *vlp;
+
+    if (argc < 2 || *argv[1] == '?') 
+        return kdb_usgf_vcpuh();
+
+    if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
+        !is_hvm_or_hyb_vcpu(vp)) {
+
+        kdbp("kdb: Bad VCPU: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    hvp = &vp->arch.hvm_vcpu;
+    vlp = &hvp->vlapic;
+    kdbp("vcpu:%lx id:%d domid:%d\n", vp, vp->vcpu_id, vp->domain->domain_id);
+
+    ioop = NULL;   /* compiler warning */
+    kdbp("&hvm_vcpu:%lx  guest_efer:"KDBFL"\n", hvp, hvp->guest_efer);
+    kdbp("  guest_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->guest_cr[0],
+         hvp->guest_cr[1],hvp->guest_cr[2]);
+    kdbp("            [3]:"KDBFL" [4]:"KDBFL"\n", hvp->guest_cr[3],
+         hvp->guest_cr[4]);
+    kdbp("  hw_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->hw_cr[0],
+         hvp->hw_cr[1], hvp->hw_cr[2]);
+    kdbp("          [3]:"KDBFL" [4]:"KDBFL"\n", hvp->hw_cr[3], hvp->hw_cr[4]);
+
+    kdbp("  VLAPIC: base msr:"KDBF64" dis:%x tmrdiv:%x\n", 
+         vlp->hw.apic_base_msr, vlp->hw.disabled, vlp->hw.timer_divisor);
+    kdbp("          regs:%p regs_page:%p\n", vlp->regs, vlp->regs_page);
+    kdbp("          periodic time:\n"); 
+    kdb_prnt_periodic_time(&vlp->pt);
+
+    kdbp("  xen_port:%x flag_dr_dirty:%x dbg_st_latch:%x\n", hvp->xen_port,
+         hvp->flag_dr_dirty, hvp->debug_state_latch);
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+
+        struct arch_vmx_struct *vxp = &hvp->u.vmx;
+        kdbp("  &vmx: %p vmcs:%lx active_cpu:%x launched:%x\n", vxp, vxp->vmcs, 
+             vxp->active_cpu, vxp->launched);
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("    exec_ctrl:%x vpid:$%d\n", vxp->exec_control, vxp->vpid);
+#endif
+        kdbp("    host_cr0: "KDBFL" vmx: {realm:%x emulate:%x}\n",
+             vxp->host_cr0, vxp->vmx_realmode, vxp->vmx_emulate);
+
+#ifdef __x86_64__
+        kdbp("    &msr_state:%p\n", &vxp->msr_state);
+#endif
+    } else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+        struct arch_svm_struct *svp = &hvp->u.svm;
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("  &svm: vmcb:%lx pa:"KDBF64" asid:"KDBF64"\n", svp, svp->vmcb,
+             svp->vmcb_pa, svp->asid_generation);
+#endif
+        kdbp("    msrpm:%p lnch_core:%x vmcb_sync:%x\n", svp->msrpm, 
+             svp->launch_core, svp->vmcb_in_sync);
+    }
+    kdbp("  cachemode:%x io: {state: %x data: "KDBFL"}\n", hvp->cache_mode,
+         hvp->hvm_io.io_state, hvp->hvm_io.io_data);
+    kdbp("  mmio: {gva: "KDBFL" gpfn: "KDBFL"}\n", hvp->hvm_io.mmio_gva,
+         hvp->hvm_io.mmio_gpfn);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* also look into arch_get_info_guest() to get context */
+static void
+kdb_print_uregs(struct cpu_user_regs *regs)
+{
+#ifdef __x86_64__
+    kdbp("      rflags: %016lx   rip: %016lx\n", regs->rflags, regs->rip);
+    kdbp("         rax: %016lx   rbx: %016lx   rcx: %016lx\n",
+         regs->rax, regs->rbx, regs->rcx);
+    kdbp("         rdx: %016lx   rsi: %016lx   rdi: %016lx\n",
+         regs->rdx, regs->rsi, regs->rdi);
+    kdbp("         rbp: %016lx   rsp: %016lx    r8: %016lx\n",
+         regs->rbp, regs->rsp, regs->r8);
+    kdbp("          r9:  %016lx  r10: %016lx   r11: %016lx\n",
+         regs->r9,  regs->r10, regs->r11);
+    kdbp("         r12: %016lx   r13: %016lx   r14: %016lx\n",
+         regs->r12, regs->r13, regs->r14);
+    kdbp("         r15: %016lx\n", regs->r15);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+         "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%08lx entryvec:%08lx upcall_mask:%lx\n",
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#else
+    kdbp("      eflags: %016lx eip: 016lx\n", regs->eflags, regs->eip);
+    kdbp("      eax: %08x   ebx: %08x   ecx: %08x   edx: %08x\n",
+         regs->eax, regs->ebx, regs->ecx, regs->edx);
+    kdbp("      esi: %08x   edi: %08x   ebp: %08x   esp: %08x\n",
+         regs->esi, regs->edi, regs->ebp, regs->esp);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+     "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%04lx entryvec:%04lx upcall_mask:%lx\n", 
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#endif
+}
+
+#if XEN_SUBVERSION < 3             /* xen 3.1.x or xen 3.2.x */
+#ifdef CONFIG_COMPAT
+    #undef vcpu_info
+    #define vcpu_info(v, field)             \
+    (*(!has_32bit_shinfo((v)->domain) ?                                       \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->native.field : \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->compat.field))
+
+    #undef __shared_info
+    #define __shared_info(d, s, field)                      \
+    (*(!has_32bit_shinfo(d) ?                           \
+       (typeof(&(s)->compat.field))&(s)->native.field : \
+       (typeof(&(s)->compat.field))&(s)->compat.field))
+#endif
+#endif
+
+static void kdb_display_pv_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct pv_vcpu *gp = &vp->arch.pv_vcpu;
+
+    kdbp("      GDT_VIRT_START(vcpu): %lx\n", GDT_VIRT_START(vp));
+    kdbp("      GDT: entries:0x%lx  frames:\n", gp->gdt_ents);
+    for (i=0; i < 16; i=i+4) 
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->gdt_frames[i], 
+             gp->gdt_frames[i+1], gp->gdt_frames[i+2],gp->gdt_frames[i+3]);
+    
+    kdbp("      trap_ctxt:%lx kernel_ss:%lx kernel_sp:%lx\n", gp->trap_ctxt,
+         gp->kernel_ss, gp->kernel_sp);
+    kdbp("      ctrlregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->ctrlreg[i], 
+             gp->ctrlreg[i+1], gp->ctrlreg[i+2], gp->ctrlreg[i+3]);
+#ifdef __x86_64__
+    kdbp("      callback:   event: %016lx   failsafe: %016lx\n", 
+         gp->event_callback_eip, gp->failsafe_callback_eip);
+    kdbp("      base: fs:0x%lx gskern:0x%lx gsuser:0x%lx\n", 
+         gp->fs_base, gp->gs_base_kernel, gp->gs_base_user);
+#else
+    kdbp("      callback:   event: %08lx:%08lx   failsafe: %08lx:%08lx\n", 
+         gp->event_callback_cs, gp->event_callback_eip, 
+         gp->failsafe_callback_cs, gp->failsafe_callback_eip);
+#endif
+    kdbp("    vcpu_info_mfn: %lx  iopl: %x\n", gp->vcpu_info_mfn, gp->iopl);
+    kdbp("\n");
+}
+
+/* Display one VCPU info */
+static void
+kdb_display_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct arch_vcpu *avp = &vp->arch;
+    struct paging_vcpu *pvp = &vp->arch.paging;
+    int domid = vp->domain->domain_id;
+
+    kdbp("\nVCPU:  vcpu-id:%d  vcpu-ptr:%p ", vp->vcpu_id, vp);
+    kdbp("  processor:%d domid:%d  domp:%p\n", vp->processor, domid,vp->domain);
+
+    if (domid == DOMID_IDLE) {
+        kdbp("    IDLE vcpu.\n");
+        return;
+    }
+    kdbp("  pause: flags:0x%016lx count:%x\n", vp->pause_flags, 
+         vp->pause_count.counter);
+    kdbp("  vcpu: initdone:%d running:%d\n", 
+         vp->is_initialised, vp->is_running);
+    kdbp("  mcepend:%d nmipend:%d shut: def:%d paused:%d\n", 
+         vp->mce_pending,  vp->nmi_pending, vp->defer_shutdown, 
+         vp->paused_for_shutdown);
+    kdbp("  &vcpu_info:%p : evtchn_upc_pend:%x _mask:%x\n",
+         vp->vcpu_info, vcpu_info(vp, evtchn_upcall_pending),
+         vcpu_info(vp, evtchn_upcall_mask));
+    kdbp("  evt_pend_sel:%lx poll_evtchn:%x ", 
+         *(unsigned long *)&vcpu_info(vp, evtchn_pending_sel), vp->poll_evtchn);
+    kdb_print_spin_lock("virq_lock:", &vp->virq_lock, "\n");
+    for (i=0; i < NR_VIRQS; i++)
+        if (vp->virq_to_evtchn[i] != 0)
+            kdbp("      virq:$%d port:$%d\n", i, vp->virq_to_evtchn[i]);
+
+    kdbp("  next:%p periodic: period:0x%lx last_event:0x%lx\n", 
+         vp->next_in_list, vp->periodic_period, vp->periodic_last_event);
+    kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:%p sched_priv:0x%p\n",
+         vp->cpu_affinity, vp->vcpu_dirty_cpumask, vp->sched_priv);
+    kdbp("  &runstate: %p state: %x (eg. RUNSTATE_running) guestptr:%p\n", 
+         &vp->runstate, vp->runstate.state, runstate_guest(vp));
+    kdbp("\n");
+    kdbp("  arch info: (%p)\n", &vp->arch);
+    kdbp("    guest_context: VGCF_ flags:%lx", 
+         vp->arch.vgc_flags); /* VGCF_in_kernel */
+    if (is_hvm_or_hyb_vcpu(vp))
+        kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
+    kdbp("\n");
+    kdb_print_uregs(&vp->arch.user_regs);
+    kdbp("      debugregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", avp->debugreg[i], 
+             avp->debugreg[i+1], avp->debugreg[i+2], avp->debugreg[i+3]);
+    kdb_display_pv_vcpu(vp);
+
+    kdbp("    TF_flags: %016lx  guest_table: %016lx cr3:%016lx\n", 
+         vp->arch.flags, vp->arch.guest_table.pfn, avp->cr3); 
+    kdbp("    paging: \n");
+    kdbp("      vtlb:%p\n", &pvp->vtlb);
+    kdbp("      &pg_mode:%p gstlevels:%d &shadow:%p shlevels:%d\n",
+         pvp->mode, pvp->mode->guest_levels, &pvp->mode->shadow,
+         pvp->mode->shadow.shadow_levels);
+    kdbp("      shadow_vcpu:\n");
+    kdbp("        guest_vtable:%p last em_mfn:"KDBFL"\n",
+         pvp->shadow.guest_vtable, pvp->shadow.last_emulated_mfn);
+#if CONFIG_PAGING_LEVELS >= 3
+    kdbp("         l3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.l3table[3].l3, pvp->shadow.l3table[2].l3, 
+     pvp->shadow.l3table[1].l3, pvp->shadow.l3table[0].l3);
+    kdbp("        gl3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.gl3e[3].l3, pvp->shadow.gl3e[2].l3, 
+     pvp->shadow.gl3e[1].l3, pvp->shadow.gl3e[0].l3);
+#endif
+    kdbp("  gdbsx_vcpu_event:%x\n", vp->arch.gdbsx_vcpu_event);
+}
+
+/* 
+ * FUNCTION: Dispaly (current) VCPU/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpu(void)
+{
+    kdbp("vcpu [vcpu-ptr] : display current/vcpu-ptr vcpu info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *v = current;
+
+    if (argc > 2 || (argc > 1 && *argv[1] == '?'))
+        kdb_usgf_vcpu();
+    else if (argc <= 1)
+        kdb_display_vcpu(v);
+    else if (kdb_str2ulong(argv[1], (ulong *)&v) && kdb_vcpu_valid(v))
+        kdb_display_vcpu(v);
+    else 
+        kdbp("Invalid usage/argument:%s v:%lx\n", argv[1], (long)v);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* from paging_dump_domain_info() */
+static void kdb_pr_dom_pg_modes(struct domain *d)
+{
+    if (paging_mode_enabled(d)) {
+        kdbp(" paging mode enabled");
+        if ( paging_mode_shadow(d) )
+            kdbp(" shadow(PG_SH_enable)");
+        if ( paging_mode_hap(d) )
+            kdbp(" hap(PG_HAP_enable) ");
+        if ( paging_mode_refcounts(d) )
+            kdbp(" refcounts(PG_refcounts) ");
+        if ( paging_mode_log_dirty(d) )
+            kdbp(" log_dirty(PG_log_dirty) ");
+        if ( paging_mode_translate(d) )
+            kdbp(" translate(PG_translate) ");
+        if ( paging_mode_external(d) )
+            kdbp(" external(PG_external) ");
+    } else
+        kdbp(" disabled");
+    kdbp("\n");
+}
+
+/* print event channels info for a given domain 
+ * NOTE: very confusing, port and event channel refer to the same thing. evtchn
+ * is arry of pointers to a bucket of pointers to 128 struct evtchn{}. while
+ * 64bit xen can handle 4096 max channels, a 32bit guest is limited to 1024 */
+static void noinline kdb_print_dom_eventinfo(struct domain *dp)
+{
+    uint chn;
+
+    kdbp("\n");
+    kdbp("  Evt: MAX_EVTCHNS:$%d ptr:%p pollmsk:%08lx ",
+         MAX_EVTCHNS(dp), dp->evtchn, dp->poll_mask[0]);
+    kdb_print_spin_lock("lk:", &dp->event_lock, "\n");
+    kdbp("    &evtchn_pending:%p &evtchn_mask:%p\n", 
+         shared_info(dp, evtchn_pending), shared_info(dp, evtchn_mask));
+
+    kdbp("   Channels info: (everything is in decimal):\n");
+    for (chn=0; chn < MAX_EVTCHNS(dp); chn++ ) {
+        struct evtchn *bktp = dp->evtchn[chn/EVTCHNS_PER_BUCKET];
+        struct evtchn *chnp = &bktp[chn & (EVTCHNS_PER_BUCKET-1)];
+        char pbit = test_bit(chn, &shared_info(dp, evtchn_pending)) ? 'Y' : 'N';
+        char mbit = test_bit(chn, &shared_info(dp, evtchn_mask)) ? 'Y' : 'N';
+
+        if (bktp==NULL || chnp->state==ECS_FREE)
+            continue;
+
+        kdbp("    chn:%4u st:%d _xen=%d _vcpu_id:%2d ", chn, chnp->state,
+             chnp->xen_consumer, chnp->notify_vcpu_id);
+        if (chnp->state == ECS_UNBOUND)
+            kdbp(" rem-domid:%d", chnp->u.unbound.remote_domid);
+        else if (chnp->state == ECS_INTERDOMAIN)
+            kdbp(" rem-port:%d rem-dom:%d", chnp->u.interdomain.remote_port,
+                 chnp->u.interdomain.remote_dom->domain_id);
+        else if (chnp->state == ECS_PIRQ)
+            kdbp(" pirq:%d", chnp->u.pirq);
+        else if (chnp->state == ECS_VIRQ)
+            kdbp(" virq:%d", chnp->u.virq);
+
+        kdbp("  pend:%c mask:%c\n", pbit, mbit);
+    }
+#if 0
+    kdbp("pirq to evtchn mapping (pirq:evtchn) (all decimal):\n");
+    for (i=0; i < dp->nr_pirqs; i ++)
+        if (dp->pirq_to_evtchn[i])
+            kdbp("(%d:%d) ", i, dp->pirq_to_evtchn[i]);
+    kdbp("\n");
+#endif
+}
+
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    struct hvm_domain *hvp = &dp->arch.hvm_domain;
+
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+    if (hvp == NULL)
+        return;
+
+    if (hvp->irq.callback_via_type == HVMIRQ_callback_vector)
+        kdbp("    HVMIRQ_callback_vector: %x\n", hvp->irq.callback_via.vector);
+
+    if (!is_hvm_domain(dp))
+        return;
+
+    kdbp("    HVM PARAMS (all in hex):\n");
+    kdbp("\tioreq.page:%lx ioreq.va:%lx\n", hvp->ioreq.page, hvp->ioreq.va);
+    kdbp("\tbuf_ioreq.page:%lx ioreq.va:%lx\n", hvp->buf_ioreq.page, 
+         hvp->buf_ioreq.va);
+    kdbp("\tHVM_PARAM_CALLBACK_IRQ: %x\n", hvp->params[HVM_PARAM_CALLBACK_IRQ]);
+    kdbp("\tHVM_PARAM_STORE_PFN: %x\n", hvp->params[HVM_PARAM_STORE_PFN]);
+    kdbp("\tHVM_PARAM_STORE_EVTCHN: %x\n", hvp->params[HVM_PARAM_STORE_EVTCHN]);
+    kdbp("\tHVM_PARAM_PAE_ENABLED: %x\n", hvp->params[HVM_PARAM_PAE_ENABLED]);
+    kdbp("\tHVM_PARAM_IOREQ_PFN: %x\n", hvp->params[HVM_PARAM_IOREQ_PFN]);
+    kdbp("\tHVM_PARAM_BUFIOREQ_PFN: %x\n", hvp->params[HVM_PARAM_BUFIOREQ_PFN]);
+    kdbp("\tHVM_PARAM_VIRIDIAN: %x\n", hvp->params[HVM_PARAM_VIRIDIAN]);
+    kdbp("\tHVM_PARAM_TIMER_MODE: %x\n", hvp->params[HVM_PARAM_TIMER_MODE]);
+    kdbp("\tHVM_PARAM_HPET_ENABLED: %x\n", hvp->params[HVM_PARAM_HPET_ENABLED]);
+    kdbp("\tHVM_PARAM_IDENT_PT: %x\n", hvp->params[HVM_PARAM_IDENT_PT]);
+    kdbp("\tHVM_PARAM_DM_DOMAIN: %x\n", hvp->params[HVM_PARAM_DM_DOMAIN]);
+    kdbp("\tHVM_PARAM_ACPI_S_STATE: %x\n", hvp->params[HVM_PARAM_ACPI_S_STATE]);
+    kdbp("\tHVM_PARAM_VM86_TSS: %x\n", hvp->params[HVM_PARAM_VM86_TSS]);
+    kdbp("\tHVM_PARAM_VPT_ALIGN: %x\n", hvp->params[HVM_PARAM_VPT_ALIGN]);
+    kdbp("\tHVM_PARAM_CONSOLE_PFN: %x\n", hvp->params[HVM_PARAM_CONSOLE_PFN]);
+    kdbp("\tHVM_PARAM_CONSOLE_EVTCHN: %x\n", 
+         hvp->params[HVM_PARAM_CONSOLE_EVTCHN]);
+    kdbp("\tHVM_PARAM_ACPI_IOPORTS_LOCATION: %x\n", 
+         hvp->params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+    kdbp("\tHVM_PARAM_MEMORY_EVENT_SINGLE_STEP: %x\n", 
+         hvp->params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP]);
+}
+static void kdb_print_rangesets(struct domain *dp)
+{
+    int locked = spin_is_locked(&dp->rangesets_lock);
+
+    if (locked)
+        spin_unlock(&dp->rangesets_lock);
+    rangeset_domain_printk(dp);
+    if (locked)
+        spin_lock(&dp->rangesets_lock);
+}
+
+static void kdb_pr_vtsc_info(struct arch_domain *ap)
+{
+    kdbp("    VTSC info: tsc_mode:%x  vtsc:%x  vtsc_last:%016lx\n", 
+         ap->tsc_mode, ap->vtsc, ap->vtsc_last);
+    kdbp("        vtsc_offset:%016lx tsc_khz:%08lx incarnation:%x\n", 
+         ap->vtsc_offset, ap->vtsc_offset, ap->incarnation);
+    kdbp("        vtsc_kerncount:%016lx _usercount:%016lx\n",
+         ap->vtsc_kerncount, ap->vtsc_usercount);
+}
+
+/* display one domain info */
+static void
+kdb_display_dom(struct domain *dp)
+{
+    struct vcpu *vp;
+    int printed = 0;
+    struct grant_table *gp = dp->grant_table;
+    struct arch_domain *ap = &dp->arch;
+
+    kdbp("\nDOMAIN :    domid:0x%04x ptr:0x%p\n", dp->domain_id, dp);
+    if (dp->domain_id == DOMID_IDLE) {
+        kdbp("    IDLE domain.\n");
+        return;
+    }
+    if (dp->is_dying) {
+        kdbp("    domain is DYING.\n");
+        return;
+    }
+#if 0
+    kdb_print_spin_lock("  pgalk:", &dp->page_alloc_lock, "\n");
+    kdbp("  pglist:  0x%p 0x%p\n", dp->page_list.next,KDB_PGLLE(dp->page_list));
+    kdbp("  xpglist: 0x%p 0x%p\n", dp->xenpage_list.next, 
+         KDB_PGLLE(dp->xenpage_list));
+    kdbp("  next:0x%p hashnext:0x%p\n", 
+         dp->next_in_list, dp->next_in_hashbucket);
+#endif
+    kdbp("  PAGES: tot:0x%08x max:0x%08x xenheap:0x%08x\n", 
+         dp->tot_pages, dp->max_pages, dp->xenheap_pages);
+
+    kdb_print_rangesets(dp);
+    kdb_print_dom_eventinfo(dp);
+    kdbp("\n");
+    kdbp("  Grant table: gp:0x%p\n", gp);
+    if (gp) {
+        kdbp("    nr_frames:0x%08x shpp:0x%p active:0x%p\n",
+             gp->nr_grant_frames, gp->shared_raw, gp->active);
+        kdbp("    maptrk:0x%p maphd:0x%08x maplmt:0x%08x\n", 
+             gp->maptrack, gp->maptrack_head, gp->maptrack_limit);
+        kdbp("    mapcnt:");
+        kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
+    }
+    kdbp("  hvm:%d priv:%d need_iommu:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_privileged, dp->need_iommu,
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
+    kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
+    kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
+         dp->is_shut_down, dp->shutdown_code);
+    kdbp("  pausecnt:0x%08x vm_assist:0x"KDBFL" refcnt:0x%08x\n",
+         dp->pause_count.counter, dp->vm_assist, dp->refcnt.counter);
+    kdbp("  &domain_dirty_cpumask:%p\n", &dp->domain_dirty_cpumask); 
+
+    kdbp("  shared == vcpu_info[]: %p\n",  dp->shared_info); 
+    kdbp("    arch_shared: maxpfn: %lx pfn-mfn-frame-ll mfn: %lx\n", 
+         arch_get_max_pfn(dp), arch_get_pfn_to_mfn_frame_list_list(dp));
+    kdbp("\n");
+    kdbp("  arch_domain at : %p\n", ap);
+
+#ifdef CONFIG_X86_64
+    kdbp("    pt_pages:0x%p ", ap->mm_perdomain_pt_pages);
+    kdbp("    l2:0x%p l3:0x%p\n", ap->mm_perdomain_l2, ap->mm_perdomain_l3);
+#else
+    kdbp("    pt:0x%p ", ap->mm_perdomain_pt);
+#endif
+#ifdef CONFIG_X86_32
+    kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
+#endif
+    kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
+    kdb_pr_dom_pg_modes(dp);
+    kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
+         KDB_PGLLE(ap->p2m->pages));
+    kdbp("       max_mapped_pfn:"KDBFL, ap->p2m->max_mapped_pfn);
+#if XEN_SUBVERSION > 0 && XEN_VERSION == 4              /* xen 4.1 and above */
+    kdbp("  phys_table:%p\n", ap->p2m->phys_table.pfn);
+#else
+    kdbp("  phys_table.pfn:"KDBFL"\n", ap->phys_table.pfn);
+#endif
+    kdbp("    physaddr_bitsz:%d 32bit_pv:%d has_32bit_shinfo:%d\n", 
+         ap->physaddr_bitsize, ap->is_32bit_pv, ap->has_32bit_shinfo);
+    kdb_pr_vtsc_info(ap);
+    kdbp("  sched:0x%p  &handle:0x%p\n", dp->sched_priv, &dp->handle);
+    kdbp("  vcpu ptrs:\n   ");
+    for_each_vcpu(dp, vp) {
+        kdbp(" %d:%p", vp->vcpu_id, vp);
+        if (++printed % 4 == 0) kdbp("\n   ");
+    }
+    kdbp("\n");
+}
+
+/* 
+ * FUNCTION: Dispaly (current) domain/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dom(void)
+{
+    kdbp("dom [all|domid]: Display current/all/given domain/s\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dom(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int id;
+    struct domain *dp = current->domain;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dom();
+
+    if (argc > 1) {
+        for(dp=domain_list; dp; dp=dp->next_in_list)
+            if (kdb_str2deci(argv[1], &id) && dp->domain_id==id)
+                kdb_display_dom(dp);
+            else if (!strcmp(argv[1], "all")) 
+                kdb_display_dom(dp);
+    } else {
+        kdbp("Displaying current domain :\n");
+        kdb_display_dom(dp);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dirq(void)
+{
+    kdbp("dirq : dump irq bindings\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dirq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long irq, sz, offs, addr;
+    char buf[KSYM_NAME_LEN+1];
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dirq();
+
+#if XEN_VERSION < 4 && XEN_SUBVERSION < 5           /* xen 3.4.x or below */
+    kdbp("idx/irq#/status: all are in decimal\n");
+    kdbp("idx  irq#  status   action(handler name devid)\n");
+    for (irq=0; irq < NR_VECTORS; irq++) {
+        irq_desc_t  *dp = &irq_desc[irq];
+        if (!dp->action)
+            continue;
+        addr = (unsigned long)dp->action->handler;
+        kdbp("[%3ld]:irq:%3d st:%3d f:%s devnm:%s devid:0x%p\n",
+             i, vector_to_irq(irq), dp->status, (dp->status & IRQ_GUEST) ? 
+                            "GUEST IRQ" : symbols_lookup(addr, &sz, &offs, buf),
+             dp->action->name, dp->action->dev_id);
+    }
+#else
+    kdbp("irq_desc[]:%p nr_irqs: $%d nr_irqs_gsi: $%d\n", irq_desc, nr_irqs, 
+          nr_irqs_gsi);
+    kdbp("irq/vec#/status: in decimal. affinity in hex, not bitmap\n");
+    kdbp("irq-- vec sta function----------- name---- type--------- ");
+    kdbp("aff devid------------\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        void *devidp;
+        const char *symp, *nmp;
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+
+        if (!dp->handler || dp->handler==&no_irq_type || dp->status & IRQ_GUEST)
+            continue;
+
+        addr = dp->action ? (unsigned long)dp->action->handler : 0;
+        symp = addr ? symbols_lookup(addr, &sz, &offs, buf) : "n/a ";
+        nmp = addr ? dp->action->name : "n/a ";
+        devidp = addr ? dp->action->dev_id : NULL;
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %03d %03d %-19s %-8s %-13s %3s 0x%p\n", irq, archp->vector,
+             dp->status, symp, nmp, dp->handler->typename, affstr, devidp);
+    }
+    kdb_prnt_guest_mapped_irqs();
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+kdb_prnt_vec_irq_table(int cpu)
+{
+    int i,j, *tbl = per_cpu(vector_irq, cpu);
+
+    kdbp("CPU %d : ", cpu);
+    for (i=0, j=0; i < NR_VECTORS; i++)
+        if (tbl[i] != -1) {
+            kdbp("(%3d:%3d) ", i, tbl[i]);
+            if (!(++j % 5))
+                kdbp("\n        ");
+        }
+    kdbp("\n");
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dvit(void)
+{
+    kdbp("dvit [cpu|all]: dump (per cpu)vector irq table\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvit(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu, ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvit();
+    
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all")) 
+            cpu = -1;
+        else if (!kdb_str2deci(argv[1], &cpu)) {
+            kdbp("Invalid cpu:%d\n", cpu);
+            return kdb_usgf_dvit();
+        }
+    } else
+        cpu = ccpu;
+
+    kdbp("Per CPU vector irq table pairs (vector:irq) (all decimals):\n");
+    if (cpu != -1) 
+        kdb_prnt_vec_irq_table(cpu);
+    else
+        for_each_online_cpu(cpu) 
+            kdb_prnt_vec_irq_table(cpu);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* do vmexit on all cpu's so intel VMCS can be dumped */
+static kdb_cpu_cmd_t 
+kdb_all_cpu_flush_vmcs(void)
+{
+    int cpu, ccpu = smp_processor_id();
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdb_curr_cpu_flush_vmcs();
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE){  /* hung cpu */
+                kdbp("Skipping (hung?) cpu %d\n", cpu);
+                continue;
+            }
+            kdb_cpu_cmd[cpu] = KDB_CPU_DO_VMEXIT;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_DO_VMEXIT);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display VMCS or VMCB */
+static kdb_cpu_cmd_t
+kdb_usgf_dvmc(void)
+{
+    kdbp("dvmc [domid][vcpuid] : Dump vmcs/vmcb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvmc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid = 0;  /* unsigned type don't like -1 */
+    int vcpuid = -1;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvmc();
+
+    if (argc > 1) { 
+        if (!kdb_str2domid(argv[1], &domid, 1))
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2 && !kdb_str2deci(argv[2], &vcpuid)) {
+        kdbp("Bad vcpuid: 0x%x\n", vcpuid);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        kdb_all_cpu_flush_vmcs();
+        kdb_dump_vmcs(domid, (int)vcpuid);
+    } else {
+        kdb_dump_vmcb(domid, (int)vcpuid);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_mmio(void)
+{
+    kdbp("mmio: dump mmio related info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmio(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmio();
+
+    kdbp("r/o mmio ranges:\n");
+    rangeset_printk(mmio_ro_ranges);
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump timer/timers queues */
+static kdb_cpu_cmd_t
+kdb_usgf_dtrq(void)
+{
+    kdbp("dtrq: dump timer queues on all cpus\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dtrq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dtrq();
+
+    kdb_dump_timer_queues();
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct idte {
+    uint16_t offs0_15;
+    uint16_t selector;
+    uint16_t meta;
+    uint16_t offs16_31;
+    uint32_t offs32_63;
+    uint32_t resvd;
+};
+
+#ifdef __x86_64__
+static void
+kdb_print_idte(int num, struct idte *idtp) 
+{
+    uint16_t mta = idtp->meta;
+    char dpl = ((mta & 0x6000) >> 13);
+    char present = ((mta &0x8000) >> 15);
+    int tval = ((mta &0x300) >> 8);
+    char *type = (tval == 1) ? "Task" : ((tval== 2) ? "Intr" : "Trap");
+    domid_t domid = idtp->selector==__HYPERVISOR_CS64 ? DOMID_IDLE :
+                    current->domain->domain_id;
+    uint64_t addr = idtp->offs0_15 | ((uint64_t)idtp->offs16_31 << 16) | 
+                    ((uint64_t)idtp->offs32_63 << 32);
+
+    kdbp("[%03d]: %s %x  %x %04x:%016lx ", num, type, dpl, present,
+         idtp->selector, addr); 
+    kdb_prnt_addr2sym(domid, addr, "\n");
+}
+
+/* Dump 64bit idt table currently on this cpu. Intel Vol 3 section 5.14.1 */
+static kdb_cpu_cmd_t
+kdb_usgf_didt(void)
+{
+    kdbp("didt : dump IDT table on the current cpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i;
+    struct idte *idtp = (struct idte *)idt_tables[smp_processor_id()];
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_didt();
+
+    kdbp("IDT at:%p\n", idtp);
+    kdbp("idt#  Type DPL P addr (all hex except idt#)\n", idtp);
+    for (i=0; i < 256; i++, idtp++) 
+        kdb_print_idte(i, idtp);
+    return KDB_CPU_MAIN_KDB;
+}
+#else
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbp("kdb: Please implement me in 32bit hypervisor\n");
+    return KDB_CPU_MAIN_KDB;
+}
+#endif
+
+struct gdte {             /* same for TSS and LDT */
+    ulong limit0:16;
+    ulong base0:24;       /* linear address base, not pa */
+    ulong acctype:4;      /* Type: access rights */
+    ulong S:1;            /* S: 0 = system, 1 = code/data */
+    ulong DPL:2;          /* DPL */
+    ulong P:1;            /* P: Segment Present */
+    ulong limit1:4;
+    ulong AVL:1;          /* AVL: avail for use by system software */
+    ulong L:1;            /* L: 64bit code segment */
+    ulong DB:1;           /* D/B */
+    ulong G:1;            /* G: granularity */
+    ulong base1:8;        /* linear address base, not pa */
+};
+
+union gdte_u {
+    struct gdte gdte;
+    u64 gval;
+};
+
+struct call_gdte {
+    unsigned short offs0:16;
+    unsigned short sel:16;
+    unsigned short misc0:16;
+    unsigned short offs1:16;
+};
+
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
+union sgdte_u {
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
+    u64 sgval;
+};
+
+/* return binary form of a hex in string : max 4 chars 0000 to 1111 */
+static char *kdb_ret_acctype(uint acctype)
+{
+    static char buf[16];
+    char *p = buf;
+    int i;
+
+    if (acctype > 0xf) {
+        buf[0] = buf[1] = buf[2] = buf[3] = '?';
+        buf[5] = '\n';
+        return buf;
+    }
+    for (i=0; i < 4; i++, p++, acctype=acctype>>1)
+        *p = (acctype & 0x1) ? '1' : '0';
+
+    return buf;
+}
+
+/* Display GDT table. IA-32e mode is assumded. */
+/* first display non system descriptors then display system descriptors */
+static kdb_cpu_cmd_t
+kdb_usgf_dgdt(void)
+{
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
+         "given vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dgdt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    union gdte_u u1;
+    ulong start_addr, end_addr, taddr=0;
+    domid_t domid = DOMID_IDLE;
+    int idx;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dgdt();
+
+    if (argc > 1) {
+        if (argc != 3)
+            return kdb_usgf_dgdt();
+
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
+        } else {
+            kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
+            return kdb_usgf_dgdt();
+        }
+    } else {
+        __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
+    }
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
+    kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
+         "--Base Addr ----  Limit\n");
+    kdbp("                              Type\n");
+
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+            continue;
+
+        if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
+            continue;               /* what an effin x86 mess */
+
+        idx = (taddr - start_addr) / 8;
+        if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
+            taddr += sizeof(ulong);
+            continue;
+        }
+        kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
+             u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
+             (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
+             u1.gdte.limit0 | (u1.gdte.limit1<<16));
+    }
+
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
+        uint acctype;
+        u64 upper, addr64=0;
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
+            u1.gval == 0 || u1.gdte.S == 1) {
+            continue;
+        }
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+            kdbp("Could not read upper 8 bytes of system desc\n");
+            upper = 0;
+        }
+        acctype = u1.gdte.acctype;
+        if (acctype != 2 && acctype != 9 && acctype != 11 && acctype !=12 &&
+            acctype != 14 && acctype != 15)
+            continue;
+
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
+
+        /* Vol 3A: table: 3-2  page: 3-19 */
+        if (acctype == 2) {
+            kdbp("LDT gate (0010)\n");
+        }
+        else if (acctype == 9) {
+            kdbp("TSS avail gate(1001)\n");
+        }
+        else if (acctype == 11) {
+            kdbp("TSS busy gate(1011)\n");
+        }
+        else if (acctype == 12) {
+            kdbp("CALL gate (1100)\n");
+        }
+        else if (acctype == 14) {
+            kdbp("IDT gate (1110)\n");
+        }
+        else if (acctype == 15) {
+            kdbp("Trap gate (1111)\n"); 
+        }
+
+        if (acctype == 2 || acctype == 9 || acctype == 11) {
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display scheduler basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_sched(void)
+{
+    kdbp("sched: show schedular info and run queues\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sched(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_sched();
+
+    kdb_print_sched_info();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display MMU basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_mmu(void)
+{
+    kdbp("mmu: print basic MMU info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmu();
+
+    kdbp("MMU Info:\n");
+    kdbp("total  pages: %lx\n", total_pages);
+    kdbp("max page/mfn: %lx\n", max_page);
+    kdbp("frame_table:  %p\n", frame_table);
+    kdbp("DIRECTMAP_VIRT_START:  %lx\n", DIRECTMAP_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_START: %lx\n", HYPERVISOR_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_END:   %lx\n", HYPERVISOR_VIRT_END);
+    kdbp("RO_MPT_VIRT_START:     %lx\n", RO_MPT_VIRT_START);
+    kdbp("PERDOMAIN_VIRT_START:  %lx\n", PERDOMAIN_VIRT_START);
+    kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
+    kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
+         (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
+
+    kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
+    kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
+    kdbp("LAST_RESERVED_GDT_ENTRY: %lx\n", (ulong)LAST_RESERVED_GDT_ENTRY);
+    kdbp("  Per cpu non-compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(gdt_table, cpu));
+    }
+    kdbp("  Per cpu compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
+    }
+    kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
+#ifdef USER_MAPPINGS_ARE_GLOBAL
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
+#else
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
+#endif
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* for HVM/HYB guests, go thru EPT. For PV guest we need to go to the btree. 
+ * btree: pfn_to_mfn_frame_list_list is root that points (has mfns of) upto 16
+ * pages (call 'em l2 nodes) that contain mfns of guest p2m table pages 
+ * NOTE: num of entries in a p2m page is same as num of entries in l2 node */
+static noinline ulong
+kdb_gpfn2mfn(struct domain *dp, ulong gpfn, p2m_type_t *typep) 
+{
+    int idx;
+
+    if ( !paging_mode_translate(dp) ) {
+        mfn_t *mfn_va, mfn = arch_get_pfn_to_mfn_frame_list_list(dp);
+        int g_longsz = kdb_guest_bitness(dp->domain_id)/8;
+        int entries_per_pg = PAGE_SIZE/g_longsz;
+        const int shift = get_count_order(entries_per_pg);
+
+	if ( !mfn_valid(mfn) ) {
+	    kdbp("Invalid frame_list_list mfn:%lx for non-xlate guest\n", mfn);
+	    return INVALID_MFN;
+	}
+
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn >> 2*shift;     /* index in root page/node */
+        if (idx > 15) {
+            kdbp("gpfn:%lx idx:%x not in frame list limit of z16\n", gpfn, idx);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        if (mfn==0) {
+            kdbp("No mfn for idx:%d for gpfn:%lx in root pg\n", idx, gpfn);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn_va = map_domain_page(mfn);
+        KDBGP1("p2m: idx:%x fll:%lx mfn of 2nd lvl page:%lx\n", idx,
+               arch_get_pfn_to_mfn_frame_list_list(dp), mfn);
+
+        idx = (gpfn>>shift) & ((1<<shift)-1);     /* idx in l2 node */
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+        if (mfn == 0) {
+            kdbp("No mfn entry at:%x in 2nd lvl pg for gpfn:%lx\n", idx, gpfn);
+            return INVALID_MFN;
+        }
+        KDBGP1("p2m: idx:%x  mfn of p2m page:%lx\n", idx, mfn); 
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn & ((1<<shift)-1);
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+
+	*typep = -1;
+        return mfn;
+    } else
+#if XEN_SUBVERSION > 0 
+        return get_gfn(dp, gpfn, typep);
+#else
+        return get_gfn(dp, gpfn, typep);
+#endif
+
+    return INVALID_MFN;
+}
+
+/* given a pfn, find it's mfn */
+static kdb_cpu_cmd_t
+kdb_usgf_p2m(void)
+{
+    kdbp("p2m domid 0xgpfn : gpfn to mfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_p2m(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gpfn;
+    p2m_type_t p2mtype;
+
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
+        !kdb_str2ulong(argv[2], &gpfn)) {
+
+        return kdb_usgf_p2m();
+    }
+    if ( paging_mode_translate(dp) )
+        kdbp("p2m[%lx] == %lx type:%d\n", gpfn, 
+             kdb_gpfn2mfn(dp, gpfn, &p2mtype), p2mtype);
+    else 
+        kdbp("p2m[%lx] == %lx type:N/A(PV)\n", gpfn, 
+             kdb_gpfn2mfn(dp, gpfn, &p2mtype));
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an mfn, lookup pfn in the MPT */
+static kdb_cpu_cmd_t
+kdb_usgf_m2p(void)
+{
+    kdbp("m2p 0xmfn: mfn to pfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_m2p(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    mfn_t mfn;
+    if (argc > 1 && kdb_str2ulong(argv[1], &mfn))
+        if (mfn_valid(mfn))
+            kdbp("mpt[%x] == %lx\n", mfn, machine_to_phys_mapping[mfn]);
+        else
+            kdbp("Invalid mfn:%lx\n", mfn);
+    else
+        kdb_usgf_m2p();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void 
+kdb_pr_pg_pgt_flds(unsigned long type_info)
+{
+    switch (type_info & PGT_type_mask) {
+        case (PGT_l1_page_table):
+            kdbp("    page is PGT_l1_page_table\n");
+            break;
+        case PGT_l2_page_table:
+            kdbp("    page is PGT_l2_page_table\n");
+            break;
+        case PGT_l3_page_table:
+            kdbp("    page is PGT_l3_page_table\n");
+            break;
+        case PGT_l4_page_table:
+            kdbp("    page is PGT_l4_page_table\n");
+            break;
+        case PGT_seg_desc_page:
+            kdbp("    page is seg desc page\n");
+            break;
+        case PGT_writable_page:
+            kdbp("    page is writable page\n");
+            break;
+        case PGT_shared_page:
+            kdbp("    page is shared page\n");
+            break;
+    }
+    if (type_info & PGT_pinned)
+        kdbp("    page is pinned\n");
+    if (type_info & PGT_validated)
+        kdbp("    page is validated\n");
+    if (type_info & PGT_pae_xen_l2)
+        kdbp("    page is PGT_pae_xen_l2\n");
+    if (type_info & PGT_partial)
+        kdbp("    page is PGT_partial\n");
+    if (type_info & PGT_locked)
+        kdbp("    page is PGT_locked\n");
+}
+
+static void
+kdb_pr_pg_pgc_flds(unsigned long count_info)
+{
+    if (count_info & PGC_allocated)
+        kdbp("  PGC_allocated");
+    if (count_info & PGC_xen_heap)
+        kdbp("  PGC_xen_heap");
+    if (count_info & PGC_page_table)
+        kdbp("  PGC_page_table");
+    if (count_info & PGC_broken)
+        kdbp("  PGC_broken");
+#if XEN_VERSION < 4                                 /* xen 3.x.x */
+    if (count_info & PGC_offlining)
+        kdbp("  PGC_offlining");
+    if (count_info & PGC_offlined)
+        kdbp("  PGC_offlined");
+#else
+    if (count_info & PGC_state_inuse)
+        kdbp("  PGC_inuse");
+    if (count_info & PGC_state_offlining)
+        kdbp("  PGC_state_offlining");
+    if (count_info & PGC_state_offlined)
+        kdbp("  PGC_state_offlined");
+    if (count_info & PGC_state_free)
+        kdbp("  PGC_state_free");
+#endif
+    kdbp("\n");
+}
+
+/* print struct page_info{} given ptr to it or an mfn
+ * NOTE: that given an mfn there seems no way of knowing how it's used, so
+ *       here we just print all info and let user decide what's applicable */
+static kdb_cpu_cmd_t
+kdb_usgf_dpage(void)
+{
+    kdbp("dpage mfn|page-ptr : Display struct page\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dpage(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long val;
+    struct page_info *pgp;
+    struct domain *dp;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dpage();
+
+    if ((kdb_str2ulong(argv[1], &val) == 0)      ||
+        (val <  (ulong)frame_table && !mfn_valid(val))) {
+
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdbp("Page Info:\n");
+    if (val <= (ulong)frame_table) {       /* arg is mfn */
+        pgp = mfn_to_page(val);
+        kdbp("  mfn: %lx page_info:%p\n", val, pgp);
+    } else {
+        pgp = (struct page_info *)val; /* arg is struct page{} */
+        if (pgp < frame_table || pgp >= frame_table+max_page) {
+            kdbp("Invalid page ptr. below/beyond max_page\n");
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdbp("  mfn: %lx page_info:%p\n", page_to_mfn(pgp), pgp);
+    } 
+    kdbp("  count_info: %016lx  (refcnt: %x)\n", pgp->count_info,
+         pgp->count_info & PGC_count_mask);
+#if XEN_VERSION > 3 || XEN_SUBVERSION > 3             /* xen 3.4.x or later */
+    kdb_pr_pg_pgc_flds(pgp->count_info);
+
+    kdbp("In use info:\n");
+    kdbp("  type_info:%016lx\n", pgp->u.inuse.type_info);
+    kdb_pr_pg_pgt_flds(pgp->u.inuse.type_info);
+    dp = page_get_owner(pgp);
+    kdbp("  domid:%d (pickled:%lx)\n", dp ? dp->domain_id : -1, 
+         pgp->v.inuse._domain);
+
+    kdbp("Shadow Info:\n");
+    kdbp("  type:%x pinned:%x count:%x\n", pgp->u.sh.type, pgp->u.sh.pinned,
+         pgp->u.sh.count);
+    kdbp("  back:%lx  shadow_flags:%x  next_shadow:%lx\n", pgp->v.sh.back,
+         pgp->shadow_flags, pgp->next_shadow);
+
+    kdbp("Free Info\n");
+    kdbp("  need_tlbflush:%d order:%d tlbflush_timestamp:%x\n",
+         pgp->u.free.need_tlbflush, pgp->v.free.order, 
+         pgp->tlbflush_timestamp);
+#else
+    if (pgp->count_info & PGC_allocated)            /* page allocated */
+        kdbp("  PGC_allocated");
+    if (pgp->count_info & PGC_page_table)           /* page table page */
+        kdbp("  PGC_page_table");
+    kdbp("\n");
+    kdbp("  page is %s xen heap page\n", is_xen_heap_page(pgp) ? "a":"NOT");
+    kdbp("  cacheattr:%x\n", (pgp->count_info>>PGC_cacheattr_base) & 7);
+    if (pgp->count_info & PGC_count_mask) {         /* page in use */
+        dp = pgp->u.inuse._domain;         /* pickled domain */
+        kdbp("  page is in use\n");
+        kdbp("    domid: %d  (pickled dom:%x)\n", 
+             dp ? (unpickle_domptr(dp))->domain_id : -1, dp);
+        kdbp("    type_info: %lx\n", pgp->u.inuse.type_info);
+        kdb_prt_pg_type(pgp->u.inuse.type_info);
+    } else {                                         /* page is free */
+        kdbp("  page is free\n");
+        kdbp("    order: %x\n", pgp->u.free.order);
+        kdbp("    cpumask: %lx\n", pgp->u.free.cpumask.bits);
+    }
+    kdbp("  tlbflush/shadow_flags: %lx\n", pgp->shadow_flags);
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display asked msr value */
+static kdb_cpu_cmd_t
+kdb_usgf_dmsr(void)
+{
+    kdbp("dmsr address : Display msr value\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dmsr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long addr, val;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dmsr();
+
+    if ((kdb_str2ulong(argv[1], &addr) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    rdmsrl(addr, val);
+    kdbp("msr: %lx  val:%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_cpuid(void)
+{
+    kdbp("cpuid eax : Display cpuid value returned in rax\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_cpuid(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long rax=0, rbx=0, rcx=0, rdx=0;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_cpuid();
+
+    if ((kdb_str2ulong(argv[1], &rax) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+#if 0
+    __asm__ __volatile__ (
+            /* "pushl %%rax  \n" */
+
+            "movl %0, %%rax  \n"
+            "cpuid           \n" 
+            : "=&a" (rax), "=b" (rbx), "=c" (rcx), "=d" (rdx)
+            : "0" (rax)
+            : "rax", "rbx", "rcx", "rdx", "memory");
+#endif
+    cpuid(rax, &rax, &rbx, &rcx, &rdx);
+    kdbp("rax: %016lx  rbx:%016lx rcx:%016lx rdx:%016lx\n", rax, rbx,
+         rcx, rdx);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_wept(void)
+{
+    kdbp("wept domid gfn: walk ept table for given domid and gfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_wept(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gfn;
+
+    if ((argc > 1 && *argv[1] == '?') || argc != 3)
+        return kdb_usgf_wept();
+    if ((dp=kdb_strdomid2ptr(argv[1], 1)) && kdb_str2ulong(argv[2], &gfn))
+        ept_walk_table(dp, gfn);
+    else
+        kdb_usgf_wept();
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Save symbols info for a guest, dom0 or other...
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_sym(void)
+{
+   kdbp("sym domid &kallsyms_names &kallsyms_addresses &kallsyms_num_syms\n");
+   kdbp("\t [&kallsyms_token_table] [&kallsyms_token_index]\n");
+   kdbp("\ttoken _table and _index MUST be specified for el5\n");
+   return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sym(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong namesp, addrap, nump, toktblp, tokidxp;
+    domid_t domid;
+
+    if (argc < 5) {
+        return kdb_usgf_sym();
+    }
+    toktblp = tokidxp = 0;     /* optional parameters */
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &namesp)   &&
+        kdb_str2ulong(argv[3], &addrap)   &&
+        kdb_str2ulong(argv[4], &nump)     && 
+        (argc==5 || (argc==7 && kdb_str2ulong(argv[5], &toktblp) &&
+                                kdb_str2ulong(argv[6], &tokidxp)))) {
+
+        kdb_sav_dom_syminfo(domid, namesp, addrap,nump,toktblp,tokidxp);
+    } else
+        kdb_usgf_sym();
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* mods is the dumb ass &modules. modules is struct {nxt, prev}, and not ptr */
+static void
+kdb_dump_linux_modules(domid_t domid, ulong mods, uint nxtoffs, uint nmoffs, 
+                       uint coreoffs)
+{
+    const int bufsz = 56;
+    char buf[bufsz];
+    uint64_t addr, addrval, *nxtptr, *modptr;
+    uint i, num = 8;
+
+    if (kdb_guest_bitness(domid) == 32)
+        num = 4;
+
+    /* first read modules{}.next ptr */
+    if (kdb_read_mem(mods, (kdbbyt_t *)&nxtptr, num, domid) != num) {
+        kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+        return;
+    }
+
+    KDBGP("mods:%p nxtptr:%p nmoffs:%x coreoffs:%x\n", (void *)mods, nxtptr,
+          nmoffs, coreoffs);
+
+    while ((uint64_t)nxtptr != mods) {
+
+        modptr = (uint64_t *) ((ulong)nxtptr - nxtoffs);
+
+        addr = (ulong)modptr + coreoffs;
+        if (kdb_read_mem(addr, (kdbbyt_t *)&addrval, num, domid) != num) {
+            kdbp("ERROR: Could not read mod addr at :%p\n", (void *)addr);
+            return;
+        }
+
+        KDBGP("modptr:%p addr:%p\n", modptr, (void *)addr);
+        addr = (ulong)modptr + nmoffs;
+        i=0;
+        do {
+            if (kdb_read_mem(addr, (kdbbyt_t *)&buf[i], 1, domid) != 1) {
+                kdbp("ERROR:Could not read name ch at addr:%p\n", (void *)addr);
+                return;
+            }
+            addr++;
+        } while (buf[i] && i++ < bufsz);
+        buf[bufsz-1] = '\0';
+
+        kdbp("%016lx %016lx %s\n", modptr, addrval, buf);
+
+        if (kdb_read_mem((ulong)nxtptr, (kdbbyt_t *)&nxtptr, num, domid)!=num) {
+            kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+            return;
+        }
+        KDBGP("nxtptr:%p addr:%p\n", nxtptr, (void *)addr);
+    } 
+}
+
+/* Display modules loaded in linux guest */
+static kdb_cpu_cmd_t
+kdb_usgf_mod(void)
+{
+   kdbp("mod domid &modules next-offs name-offs module_core-offs\n");
+   kdbp("\twhere next-offs: &((struct module *)0)->list.next\n");
+   kdbp("\tname-offs: &((struct module *)0)->name etc..\n");
+   kdbp("\tDisplays all loaded modules in the linux guest\n");
+   kdbp("\tEg: mod 0 ffffffff80302780 8 0x18 0x178\n");
+
+   return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_cmdf_mod(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong mods, nxtoffs, nmoffs, coreoffs;
+    domid_t domid;
+
+    if (argc < 6) {
+        return kdb_usgf_mod();
+    }
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &mods)     &&
+        kdb_str2ulong(argv[3], &nxtoffs)  &&
+        kdb_str2ulong(argv[4], &nmoffs)   &&
+        kdb_str2ulong(argv[5], &coreoffs)) {
+
+        kdbp("modptr address name\n");
+        kdb_dump_linux_modules(domid, mods, nxtoffs, nmoffs, coreoffs);
+    } else
+        kdb_usgf_mod();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* toggle kdb debug trace level */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbdbg(void)
+{
+    kdbp("kdbdbg : trace info to debug kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_kdbdbg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbdbg();
+
+    kdbdbg = (kdbdbg==3) ? 0 : (kdbdbg+1);
+    kdbp("kdbdbg set to:%d\n", kdbdbg);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_reboot(void)
+{
+    kdbp("reboot: reboot system\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_reboot(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_reboot();
+
+    machine_restart(500);
+    return KDB_CPU_MAIN_KDB;              /* not reached */
+}
+
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcon(void)
+{
+    kdbp("trcon: turn user added kdb tracing on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcon(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcon();
+
+    kdb_trcon = 1;
+    kdbp("kdb tracing is now on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcoff(void)
+{
+    kdbp("trcoff: turn user added kdb tracing off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcoff(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcoff();
+
+    kdb_trcon = 0;
+    kdbp("kdb tracing is now off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcz(void)
+{
+    kdbp("trcz : zero entire trace buffer\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcz(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcz();
+
+    kdb_trczero();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcp(void)
+{
+    kdbp("trcp : give hints to dump trace buffer via dw/dd command\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcp();
+
+    kdb_trcp();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* print some basic info, constants, etc.. */
+static kdb_cpu_cmd_t
+kdb_usgf_info(void)
+{
+    kdbp("info : display basic info, constants, etc..\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_info(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    struct cpuinfo_x86 *bcdp;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_info();
+
+    kdbp("Version: %d.%d.%s (%s@%s) %s\n", xen_major_version(), 
+         xen_minor_version(), xen_extra_version(), xen_compile_by(), 
+         xen_compile_domain(), xen_compile_date());
+    kdbp("__XEN_LATEST_INTERFACE_VERSION__ : 0x%x\n", 
+         __XEN_LATEST_INTERFACE_VERSION__);
+    kdbp("__XEN_INTERFACE_VERSION__: 0x%x\n", __XEN_INTERFACE_VERSION__);
+
+    bcdp = &boot_cpu_data;
+    kdbp("CPU: (all decimal)");
+        if (bcdp->x86_vendor == X86_VENDOR_AMD)
+            kdbp(" AMD");
+        else
+            kdbp(" INTEL");
+        kdbp(" family:%d model:%d\n", bcdp->x86, bcdp->x86_model);
+        kdbp("     vendor_id:%16s model_id:%64s\n", bcdp->x86_vendor_id,
+             bcdp->x86_model_id);
+        kdbp("     cpuidlvl:%d cache:sz:%d align:%d\n", bcdp->cpuid_level,
+             bcdp->x86_cache_size, bcdp->x86_cache_alignment);
+        kdbp("     power:%d cores: max:%d booted:%d siblings:%d apicid:%d\n",
+             bcdp->x86_power, bcdp->x86_max_cores, bcdp->booted_cores,
+             bcdp->x86_num_siblings, bcdp->apicid);
+        kdbp("     ");
+        if (cpu_has_apic)
+            kdbp("_apic");
+        if (cpu_has_sep)
+            kdbp("|_sep");
+        if (cpu_has_xmm3)
+            kdbp("|_xmm3");
+        if (cpu_has_ht)
+            kdbp("|_ht");
+        if (cpu_has_nx)
+            kdbp("|_nx");
+        if (cpu_has_clflush)
+            kdbp("|_clflush");
+        if (cpu_has_page1gb)
+            kdbp("|_page1gb");
+        if (cpu_has_ffxsr)
+            kdbp("|_ffxsr");
+        if (cpu_has_x2apic)
+            kdbp("|_x2apic");
+    kdbp("\n\n");
+    kdbp("CC:");
+#if defined(CONFIG_X86_64)
+        kdbp(" CONFIG_X86_64");
+#endif
+#if defined(CONFIG_COMPAT)
+        kdbp(" CONFIG_COMPAT");
+#endif
+#if defined(CONFIG_PAGING_ASSISTANCE)
+        kdbp(" CONFIG_PAGING_ASSISTANCE");
+#endif
+    kdbp("\n");
+    kdbp("cpu has following features:\n");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ? 
+         "X86_FEATURE_TSC_RELIABLE" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_CONSTANT_TSC)? "X86_FEATURE_CONSTANT_TSC":"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ? "X86_FEATURE_NONSTOP_TSC" :"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_RDTSCP) ?  "X86_FEATURE_RDTSCP" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_FXSR) ?  "X86_FEATURE_FXSR" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_CPUID_FAULTING) ?  
+         "X86_FEATURE_CPUID_FAULTING" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_PAGE1GB) ?  "X86_FEATURE_PAGE1GB" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_MWAIT) ?  "X86_FEATURE_MWAIT" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_X2APIC) ?  "X86_FEATURE_X2APIC":"");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_XSAVE) ?  "X86_FEATURE_XSAVE":"");
+    kdbp("\n");
+
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
+    kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
+    kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
+
+    kdbp("\nDomains and their vcpus:\n");
+    for_each_domain(dp) {
+        struct vcpu *vp;
+        int printed=0;
+        kdbp("  Domain: {id:%d 0x%x   ptr:%p%s}  VCPUs:\n", 
+             dp->domain_id, dp->domain_id, dp, dp->is_dying ? " DYING":"");
+        for(vp=dp->vcpu[0]; vp; vp = vp->next_in_list) {
+            kdbp("  {id:%d p:%p runstate:%d}", vp->vcpu_id, vp, 
+                 vp->runstate.state);
+            if (++printed % 2 == 0) kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_cur(void)
+{
+    kdbp("cur : display current domid and vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Checking for guest_mode() not feasible here. if dom0->hcall->bp in xen, 
+ * then g_m() will show xen, but vcpu is still dom0. hence just look at 
+ * current only */
+static kdb_cpu_cmd_t
+kdb_cmdf_cur(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t id = current->domain->domain_id;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cur();
+
+    kdbp("domid: %d{%p} %s vcpu:%d {%p} ", id, current->domain,
+         (id==DOMID_IDLE) ? "(IDLE)" : "", current->vcpu_id, current);
+
+    /* if (id != DOMID_IDLE) { */
+        if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+            u64 addr = -1;
+            __vmptrst(&addr);
+            kdbp(" VMCS:"KDBFL, addr);
+        }
+    /* } */
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* stub to quickly and easily add a new command */
+static kdb_cpu_cmd_t
+kdb_usgf_usr1(void)
+{
+    kdbp("usr1: add any arbitrary cmd using this in kdb_cmds.c\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_usr1(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_h(void)
+{
+    kdbp("h: display all commands. See kdb/README for more info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_h(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbtab_t *tbp;
+
+    kdbp(" - ccpu is current cpu \n");
+    kdbp(" - following are always in decimal:\n");
+    kdbp("     vcpu num, cpu num, domid\n");
+    kdbp(" - otherwise, almost all numbers are in hex (0x not needed)\n");
+    kdbp(" - output: $17 means decimal 17\n");
+    kdbp(" - domid 7fff($32767) refers to hypervisor\n");
+    kdbp(" - if no domid before function name, then it's hypervisor\n");
+    kdbp(" - earlykdb in xen grub line to break into kdb during boot\n");
+    kdbp(" - command ? will show the command usage\n");
+    kdbp("\n");
+
+    for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_usgf; tbp++)
+        (*tbp->kdb_cmd_usgf)();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ===================== cmd table initialization ========================== */
+void __init
+kdb_init_cmdtab(void)
+{
+  static kdbtab_t _kdb_cmd_table[] = {
+
+    {"info", kdb_cmdf_info, kdb_usgf_info, 1, KDB_REPEAT_NONE},
+    {"cur",  kdb_cmdf_cur, kdb_usgf_cur, 1, KDB_REPEAT_NONE},
+
+    {"f",  kdb_cmdf_f,  kdb_usgf_f,  1, KDB_REPEAT_NONE},
+    {"fg", kdb_cmdf_fg, kdb_usgf_fg, 1, KDB_REPEAT_NONE},
+
+    {"dw",  kdb_cmdf_dw,  kdb_usgf_dw,  1, KDB_REPEAT_NO_ARGS},
+    {"dd",  kdb_cmdf_dd,  kdb_usgf_dd,  1, KDB_REPEAT_NO_ARGS},
+    {"dwm", kdb_cmdf_dwm, kdb_usgf_dwm, 1, KDB_REPEAT_NO_ARGS},
+    {"ddm", kdb_cmdf_ddm, kdb_usgf_ddm, 1, KDB_REPEAT_NO_ARGS},
+    {"dr",  kdb_cmdf_dr,  kdb_usgf_dr,  1, KDB_REPEAT_NONE},
+    {"drg", kdb_cmdf_drg, kdb_usgf_drg, 1, KDB_REPEAT_NONE},
+
+    {"dis", kdb_cmdf_dis,  kdb_usgf_dis,  1, KDB_REPEAT_NO_ARGS},
+    {"dism",kdb_cmdf_dism, kdb_usgf_dism, 1, KDB_REPEAT_NO_ARGS},
+
+    {"mw", kdb_cmdf_mw, kdb_usgf_mw, 1, KDB_REPEAT_NONE},
+    {"md", kdb_cmdf_md, kdb_usgf_md, 1, KDB_REPEAT_NONE},
+    {"mr", kdb_cmdf_mr, kdb_usgf_mr, 1, KDB_REPEAT_NONE},
+
+    {"bc", kdb_cmdf_bc, kdb_usgf_bc, 0, KDB_REPEAT_NONE},
+    {"bp", kdb_cmdf_bp, kdb_usgf_bp, 1, KDB_REPEAT_NONE},
+    {"btp", kdb_cmdf_btp, kdb_usgf_btp, 1, KDB_REPEAT_NONE},
+
+    {"wp", kdb_cmdf_wp, kdb_usgf_wp, 1, KDB_REPEAT_NONE},
+    {"wc", kdb_cmdf_wc, kdb_usgf_wc, 0, KDB_REPEAT_NONE},
+
+    {"ni", kdb_cmdf_ni, kdb_usgf_ni, 0, KDB_REPEAT_NO_ARGS},
+    {"ss", kdb_cmdf_ss, kdb_usgf_ss, 1, KDB_REPEAT_NO_ARGS},
+    {"ssb",kdb_cmdf_ssb,kdb_usgf_ssb,0, KDB_REPEAT_NO_ARGS},
+    {"go", kdb_cmdf_go, kdb_usgf_go, 0, KDB_REPEAT_NONE},
+
+    {"cpu",kdb_cmdf_cpu, kdb_usgf_cpu, 1, KDB_REPEAT_NONE},
+    {"nmi",kdb_cmdf_nmi, kdb_usgf_nmi, 1, KDB_REPEAT_NONE},
+    {"percpu",kdb_cmdf_percpu, kdb_usgf_percpu, 1, KDB_REPEAT_NONE},
+
+    {"sym",  kdb_cmdf_sym,   kdb_usgf_sym,   1, KDB_REPEAT_NONE},
+    {"mod",  kdb_cmdf_mod,   kdb_usgf_mod,   1, KDB_REPEAT_NONE},
+
+    {"vcpuh",kdb_cmdf_vcpuh, kdb_usgf_vcpuh, 1, KDB_REPEAT_NONE},
+    {"vcpu", kdb_cmdf_vcpu,  kdb_usgf_vcpu,  1, KDB_REPEAT_NONE},
+    {"dom",  kdb_cmdf_dom,   kdb_usgf_dom,   1, KDB_REPEAT_NONE},
+
+    {"sched", kdb_cmdf_sched, kdb_usgf_sched, 1, KDB_REPEAT_NONE},
+    {"mmu",   kdb_cmdf_mmu,   kdb_usgf_mmu,   1, KDB_REPEAT_NONE},
+    {"p2m",   kdb_cmdf_p2m,   kdb_usgf_p2m,   1, KDB_REPEAT_NONE},
+    {"m2p",   kdb_cmdf_m2p,   kdb_usgf_m2p,   1, KDB_REPEAT_NONE},
+    {"dpage", kdb_cmdf_dpage, kdb_usgf_dpage, 1, KDB_REPEAT_NONE},
+    {"dmsr",  kdb_cmdf_dmsr,  kdb_usgf_dmsr, 1, KDB_REPEAT_NONE},
+    {"cpuid",  kdb_cmdf_cpuid,  kdb_usgf_cpuid, 1, KDB_REPEAT_NONE},
+    {"wept",  kdb_cmdf_wept,  kdb_usgf_wept, 1, KDB_REPEAT_NONE},
+
+    {"dtrq", kdb_cmdf_dtrq,  kdb_usgf_dtrq, 1, KDB_REPEAT_NONE},
+    {"didt", kdb_cmdf_didt,  kdb_usgf_didt, 1, KDB_REPEAT_NONE},
+    {"dgdt", kdb_cmdf_dgdt,  kdb_usgf_dgdt, 1, KDB_REPEAT_NONE},
+    {"dirq", kdb_cmdf_dirq,  kdb_usgf_dirq, 1, KDB_REPEAT_NONE},
+    {"dvit", kdb_cmdf_dvit,  kdb_usgf_dvit, 1, KDB_REPEAT_NONE},
+    {"dvmc", kdb_cmdf_dvmc,  kdb_usgf_dvmc, 1, KDB_REPEAT_NONE},
+    {"mmio", kdb_cmdf_mmio,  kdb_usgf_mmio, 1, KDB_REPEAT_NONE},
+
+    /* tracing related commands */
+    {"trcon", kdb_cmdf_trcon,  kdb_usgf_trcon,  0, KDB_REPEAT_NONE},
+    {"trcoff",kdb_cmdf_trcoff, kdb_usgf_trcoff, 0, KDB_REPEAT_NONE},
+    {"trcz",  kdb_cmdf_trcz,   kdb_usgf_trcz,   0, KDB_REPEAT_NONE},
+    {"trcp",  kdb_cmdf_trcp,   kdb_usgf_trcp,   1, KDB_REPEAT_NONE},
+
+    {"usr1",  kdb_cmdf_usr1,   kdb_usgf_usr1,   1, KDB_REPEAT_NONE},
+    {"kdbf",  kdb_cmdf_kdbf,   kdb_usgf_kdbf,   1, KDB_REPEAT_NONE},
+    {"kdbdbg",kdb_cmdf_kdbdbg, kdb_usgf_kdbdbg, 1, KDB_REPEAT_NONE},
+    {"reboot",kdb_cmdf_reboot, kdb_usgf_reboot, 1, KDB_REPEAT_NONE},
+    {"h",     kdb_cmdf_h,      kdb_usgf_h,      1, KDB_REPEAT_NONE},
+
+    {"", NULL, NULL, 0, 0},
+  };
+    kdb_cmd_tbl = _kdb_cmd_table;
+    return;
+}
diff -r 54c8c9eaee92 xen/kdb/kdb_io.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_io.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+#include "include/kdbinc.h"
+
+#define K_BACKSPACE  0x8                   /* ctrl-H */
+#define K_BACKSPACE1 0x7f                  /* ctrl-? */
+#define K_UNDERSCORE 0x5f
+#define K_CMD_BUFSZ  160
+#define K_CMD_MAXI   (K_CMD_BUFSZ - 1)     /* max index in buffer */
+
+#if 0        /* make a history array some day */
+#define K_UP_ARROW                         /* sequence : 1b 5b 41 ie, '\e[A' */
+#define K_DN_ARROW                         /* sequence : 1b 5b 42 ie, '\e[B' */
+#define K_NUM_HIST   32
+static int cursor;
+static char cmds_a[NUM_HIST][K_CMD_BUFSZ];
+#endif
+
+static char cmds_a[K_CMD_BUFSZ];
+
+
+static int
+kdb_key_valid(int key)
+{
+    /* note: isspace() is more than ' ', hence we don't use it here */
+    if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
+            return 1;
+    return 0;
+}
+
+/* display kdb prompt and read command from the console 
+ * RETURNS: a '\n' terminated command buffer */
+char *
+kdb_get_cmdline(char *prompt)
+{
+    #define K_BELL     0x7
+    #define K_CTRL_C   0x3
+
+    int key, i=0;
+
+    kdbp(prompt);
+    memset(cmds_a, 0, K_CMD_BUFSZ);
+    cmds_a[K_CMD_BUFSZ-1] = '\n';
+
+    do {
+        key = console_getc();
+        if (key == '\r') 
+            key = '\n';
+        if (key == K_BACKSPACE1) 
+            key = K_BACKSPACE;
+
+        if (key == K_CTRL_C || (i==K_CMD_MAXI && key != '\n')) {
+            console_putc('\n');
+            if (i >= K_CMD_MAXI) {
+                kdbp("KDB: cmd buffer overflow\n");
+                console_putc(K_BELL);
+            }
+            memset(cmds_a, 0, K_CMD_BUFSZ);
+            i = 0;
+            kdbp(prompt);
+            continue;
+        }
+        if (!kdb_key_valid(key)) {
+            console_putc(K_BELL);
+            continue;
+        }
+        if (key == K_BACKSPACE) {
+            if (i==0) {
+                console_putc(K_BELL);
+                continue;
+            } else 
+                cmds_a[--i] = '\0';
+                console_putc(K_BACKSPACE);
+                console_putc(' ');        /* erase character */
+        } else
+            cmds_a[i++] = key;
+
+        console_putc(key);
+
+    } while (key != '\n');
+
+    return cmds_a;
+}
+
+/*
+ * printk takes a lock, an NMI could come in after that, and another cpu may 
+ * spin. also, the console lock is forced unlock, so panic is been seen on 
+ * 8 way. hence, no printk() calls.
+ */
+static volatile int kdbp_gate = 0;
+void
+kdbp(const char *fmt, ...)
+{
+    static char buf[1024];
+    va_list args;
+    char *p;
+    int i=0;
+
+    while ((__cmpxchg(&kdbp_gate, 0,1, sizeof(kdbp_gate)) != 0) && i++<1000)
+        mdelay(10);
+
+    va_start(args, fmt);
+    (void)vsnprintf(buf, sizeof(buf), fmt, args);
+    va_end(args);
+
+    for (p=buf; *p != '\0'; p++)
+        console_putc(*p);
+    kdbp_gate = 0;
+}
+
+
+/*
+ * copy/read machine memory. 
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mmem(kdbma_t maddr, kdbbyt_t *dbuf, int len)
+{
+    ulong remain, orig=len;
+
+    while (len > 0) {
+        ulong pagecnt = min_t(long, PAGE_SIZE-(maddr&~PAGE_MASK), len);
+        char *va = map_domain_page(maddr >> PAGE_SHIFT);
+
+        va = va + (maddr & (PAGE_SIZE-1));        /* add page offset */
+        remain = __copy_from_user(dbuf, (void *)va, pagecnt);
+        KDBGP1("maddr:%x va:%p len:%x pagecnt:%x rem:%x\n", 
+               maddr, va, len, pagecnt, remain);
+        unmap_domain_page(va);
+        len = len  - (pagecnt - remain);
+        if (remain != 0)
+            break;
+        maddr += pagecnt;
+        dbuf += pagecnt;
+    }
+    return orig - len;
+}
+
+
+/*
+ * copy/read guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mem(kdbva_t saddr, kdbbyt_t *dbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(saddr, dbuf, len, domid, 0, 0));
+}
+
+/*
+ * write guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes written
+ */
+int
+kdb_write_mem(kdbva_t daddr, kdbbyt_t *sbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(daddr, sbuf, len, domid, 1, 0));
+}
diff -r 54c8c9eaee92 xen/kdb/kdbmain.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdbmain.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+static int kdbmain(kdb_reason_t, struct cpu_user_regs *);
+static int kdbmain_fatal(struct cpu_user_regs *, int);
+static const char *kdb_gettrapname(int);
+
+/* ======================== GLOBAL VARIABLES =============================== */
+/* All global variables used by KDB must be defined here only. Module specific
+ * static variables must be declared in respective modules.
+ */
+kdbtab_t *kdb_cmd_tbl;
+char kdb_prompt[32];
+
+volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+cpumask_t kdb_cpu_traps;           /* bit per cpu to tell which cpus hit int3 */
+
+#ifndef NDEBUG
+    #error KDB is not supported on debug xen. Turn debug off
+#endif
+
+volatile int kdb_init_cpu = -1;           /* initial kdb cpu */
+volatile int kdb_session_begun = 0;       /* active kdb session? */
+volatile int kdb_enabled = 1;             /* kdb enabled currently? */
+volatile int kdb_sys_crash = 0;           /* are we in crashed state? */
+volatile int kdbdbg = 0;                  /* to debug kdb itself */
+
+static volatile int kdb_trap_immed_reason = 0;   /* reason for immed trap */
+
+static cpumask_t kdb_fatal_cpumask;       /* which cpus in fatal path */
+
+/* return index of first bit set in val. if val is 0, retval is undefined */
+static inline unsigned int kdb_firstbit(unsigned long val)
+{
+    __asm__ ( "bsf %1,%0" : "=r" (val) : "r" (val), "0" (BITS_PER_LONG) );
+    return (unsigned int)val;
+}
+
+void noinline mukchk(unsigned long ul)
+{
+}
+
+static void 
+kdb_dbg_prnt_ctrps(char *label, int ccpu)
+{
+    int i;
+    if (!kdbdbg)
+        return;
+
+    if (label || *label)
+        kdbp("%s ", label);
+    if (ccpu != -1)
+        kdbp("ccpu:%d ", ccpu);
+    kdbp("cputrps:");
+    for (i=sizeof(kdb_cpu_traps)/sizeof(kdb_cpu_traps.bits[0]) - 1; i >=0; i--)
+        kdbp(" %lx", kdb_cpu_traps.bits[i]);
+    kdbp("\n");
+}
+
+/* 
+ * Hold this cpu. Don't disable until all CPUs in kdb to avoid IPI deadlock 
+ */
+static void
+kdb_hold_this_cpu(int ccpu, struct cpu_user_regs *regs)
+{
+    KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+    do {
+        for(; kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE; cpu_relax());
+        KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DISABLE) {
+            local_irq_disable();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DO_VMEXIT) {
+            kdb_curr_cpu_flush_vmcs();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_SHOWPC) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+    } while (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE);     /* No goto, eh! */
+    KDBGP1("un hold: ccpu:%d cmd:%d\n", ccpu, kdb_cpu_cmd[ccpu]);
+}
+
+/*
+ * Pause this cpu while one CPU does main kdb processing. If that CPU does
+ * a "cpu switch" to this cpu, this cpu will become the main kdb cpu. If the
+ * user next does single step of some sort, this function will be exited,
+ * and this cpu will come back into kdb via kdb_handle_trap_entry function.
+ */
+static void 
+kdb_pause_this_cpu(struct cpu_user_regs *regs, void *unused)
+{
+    kdbmain(KDB_REASON_PAUSE_IPI, regs);
+}
+
+/* pause other cpus via an IPI. Note, disabled CPUs can't receive IPIs until
+ * enabled */
+static void
+kdb_smp_pause_cpus(void)
+{
+    int cpu, wait_count = 0;
+    int ccpu = smp_processor_id();      /* current cpu */
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL) {
+            kdbp("KDB: won't pause cpu:%d, cmd[cpu]=%d\n",cpu,kdb_cpu_cmd[cpu]);
+            cpumask_clear_cpu(cpu, &cpumask);
+        }
+    KDBGP("ccpu:%d will pause cpus. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    on_selected_cpus(&cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0);
+#else
+    on_selected_cpus(cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0, 0);
+#endif
+    mdelay(300);                     /* wait a bit for other CPUs to stop */
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+                bummer = 1;
+        if (!bummer)
+            break;
+        kdbp("ccpu:%d trying to stop other cpus...\n", ccpu);
+        mdelay(100);  /* wait 100 ms */
+    };
+    for_each_cpu(cpu, &cpumask)          /* now check who is with us */
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+            kdbp("Bummer cpu %d not paused. ccpu:%d\n", cpu,ccpu);
+        else {
+            kdb_cpu_cmd[cpu] = KDB_CPU_DISABLE;  /* tell it to disable ints */
+            while (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE);
+        }
+}
+
+/* 
+ * Do once per kdb session:  A kdb session lasts from 
+ *    keybord/HWBP/SWBP till KDB_CPU_INSTALL_BP is done. Within a session,
+ *    user may do several cpu switches, single step, next instr,  etc..
+ *
+ * DO: 1. pause other cpus if they are not already. they would already be 
+ *        if we are in single step mode
+ *     2. watchdog_disable() 
+ *     3. uninstall all sw breakpoints so that user doesn't see them
+ */
+static void
+kdb_begin_session(void)
+{
+    if (!kdb_session_begun) {
+        kdb_session_begun = 1;
+        kdb_smp_pause_cpus();
+        local_irq_disable();
+        watchdog_disable();
+        kdb_uninstall_all_swbp();
+    }
+}
+
+int noinline mukid(void)
+{
+    return smp_processor_id();
+}
+
+static void
+kdb_smp_unpause_cpus(int ccpu)
+{
+    int cpu;
+
+    int wait_count = 0;
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+
+    KDBGP("kdb_smp_unpause_other_cpus(). ccpu:%d\n", ccpu);
+    for_each_cpu(cpu, &cpumask)
+        kdb_cpu_cmd[cpu] = KDB_CPU_QUIT;
+
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+                bummer = 1;
+            if (!bummer)
+                break;
+            mdelay(90);  /* wait 90 ms, 50 too short on large systems */
+    };
+    /* now make sure they are all in there */
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+            kdbp("KDB: cpu %d still paused (cmd==%d). ccpu:%d\n",
+                 cpu, kdb_cpu_cmd[cpu], ccpu);
+}
+
+/*
+ * End of KDB session. 
+ *   This is called at the very end. In case of multiple cpus hitting BPs
+ *   and sitting on a trap handlers, the last cpu to exit will call this.
+ *   - isnstall all sw breakpoints, and purge deleted ones from table.
+ *   - clear TF here also in case go is entered on a different cpu after switch
+ */
+static void
+kdb_end_session(int ccpu, struct cpu_user_regs *regs)
+{
+    ASSERT(!cpumask_empty(&kdb_cpu_traps));
+    ASSERT(kdb_session_begun);
+    kdb_install_all_swbp();
+    kdb_flush_swbp_table();
+    kdb_install_watchpoints();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    kdb_time_resume(1);
+    kdb_session_begun = 0;      /* before unpause for kdb_install_watchpoints */
+    kdb_smp_unpause_cpus(ccpu);
+    watchdog_enable();
+    KDBGP("end_session:ccpu:%d\n", ccpu);
+}
+volatile int mukwpprnt;
+unsigned long mukaddr1 = 0xffffffff81243ae7, mukaddr2 = 0xffffffff8100986e;
+/* 
+ * check if we entered kdb because of DB trap. If yes, then check if
+ * we caused it or someone else.
+ * RETURNS: 0 : not one of ours. hypervisor must handle it. 
+ *          1 : #DB for delayed sw bp install. 
+ *          2 : this cpu must stay in kdb.
+ */
+static noinline int
+kdb_check_dbtrap(kdb_reason_t *reasp, int ss_mode, struct cpu_user_regs *regs) 
+{
+    int rc = 2;
+    int ccpu = smp_processor_id();
+
+    /* DB excp caused by hw breakpoint or the TF flag. The TF flag is set
+     * by us for ss mode or to install breakpoints. In ss mode, none of the
+     * breakpoints are installed. Check to make sure we intended BP INSTALL
+     * so we don't do it on a spurious DB trap.
+     * check for kdb_cpu_traps here also, because each cpu sitting on a trap
+     * must execute the instruction without the BP before passing control
+     * to next cpu in kdb_cpu_traps.
+     */
+    if (*reasp == KDB_REASON_DBEXCP && !ss_mode) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP) {
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                *reasp = KDB_REASON_PAUSE_IPI;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
+                kdb_init_cpu = -1;
+            } else {
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            }
+        } else if (! kdb_check_watchpoints(regs)) {
+            rc = 0;                        /* hyp must handle it */
+        } else {
+            if (regs->rip==mukaddr1 || regs->rip==mukaddr2)
+            {
+                if (mukwpprnt)
+                    kdbp("MUK: ignoring wp:%lx\n", regs->rip);
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            } 
+        }
+    }
+    return rc;
+}
+
+/* 
+ * Misc processing on kdb entry like displaying PC, adjust IP for sw bp.... 
+ */
+static void
+kdb_main_entry_misc(kdb_reason_t reason, struct cpu_user_regs *regs, 
+                    int ccpu, int ss_mode, int enabled)
+{
+    if (reason == KDB_REASON_KEYBOARD)
+        kdbp("\nEnter kdb (cpu:%d reason:%d vcpu=%d domid:%d"
+             " eflg:0x%lx irqs:%d)\n", ccpu, reason, current->vcpu_id, 
+             current->domain->domain_id, regs->eflags, enabled);
+    else if (ss_mode)
+        KDBGP1("KDBG: KDB single step mode. ccpu:%d\n", ccpu);
+
+    if (reason == KDB_REASON_BPEXCP && !ss_mode) 
+        kdbp("Breakpoint on cpu %d at 0x%lx\n", ccpu, regs->KDBIP);
+
+    /* display the current PC and instruction at it */
+    if (reason != KDB_REASON_PAUSE_IPI)
+        kdb_display_pc(regs);
+    console_start_sync();
+}
+
+/* 
+ * The MAIN kdb function. All cpus go thru this. IRQ is enabled on entry because
+ * a cpu could hit a bp set in disabled code.
+ * IPI: Even the main cpu must enable in case another CPU is trying to IPI us.
+ *      That way, it would IPI us, then get out and be ready for our pause IPI.
+ * IRQs: The reason irqs enable/disable is scattered is because on a typical
+ *       system IPIs are constantly going on amongs CPUs in a set of any size. 
+ *       As a result,  to avoid deadlock, cpus have to loop enabled, until a 
+ *       quorum is established and the session has begun.
+ * Step: Intel Vol3B 18.3.1.4 : An external interrupt may be serviced upon
+ *       single step. Since, the likely ext timer_interrupt and 
+ *       apic_timer_interrupt dont' mess with time data structs, we are prob OK
+ *       leaving enabled.
+ * Time: Very messy. Most platform timers are readonly, so we can't stop time
+ *       in the debugger. We take the only resort, let the TSC and plt run as
+ *       normal, upon leaving, "attempt" to bring everybody to current time.
+ * kdbcputraps: bit per cpu. each cpu sets it bit in entry.S. The bit is 
+ *              reliable because upon traps, Ints are disabled. the bit is set
+ *              before Ints are enabled.
+ *
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+static int
+kdbmain(kdb_reason_t reason, struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();                /* current cpu */
+    int rc = 1, cmd = kdb_cpu_cmd[ccpu];
+    int ss_mode = (cmd == KDB_CPU_SS || cmd == KDB_CPU_NI);
+    int delayed_install = (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP);
+    int enabled = local_irq_is_enabled();
+
+    KDBGP("kdbmain:ccpu:%d rsn:%d eflgs:0x%lx cmd:%d initc:%d irqs:%d "
+          "regs:%lx IP:%lx ", ccpu, reason, regs->eflags, cmd, 
+          kdb_init_cpu, enabled, regs, regs->KDBIP);
+    kdb_dbg_prnt_ctrps("", -1);
+
+    if (!ss_mode && !delayed_install)    /* initial kdb enter */
+        local_irq_enable();              /* so we can receive IPI */
+
+    if (!ss_mode && ccpu != kdb_init_cpu && reason != KDB_REASON_PAUSE_IPI){
+        int sz = sizeof(kdb_init_cpu);
+        while (__cmpxchg(&kdb_init_cpu, -1, ccpu, sz) != -1)
+            for(; kdb_init_cpu != -1; cpu_relax());
+    }
+    if (kdb_session_begun)
+        local_irq_disable();             /* kdb always runs disabled */
+
+    if (reason == KDB_REASON_BPEXCP) {             /* INT 3 */
+        cpumask_clear_cpu(ccpu, &kdb_cpu_traps);   /* remove ourself */
+        rc = kdb_check_sw_bkpts(regs);
+        if (rc == 0) {               /* not one of ours. leave kdb */
+            kdb_init_cpu = -1;
+            goto out;
+        } else if (rc == 1) {        /* one of ours but deleted */
+            if (cpumask_empty(&kdb_cpu_traps)) {
+                kdb_end_session(ccpu,regs);     
+                kdb_init_cpu = -1;
+                goto out;
+            } else {                 
+                /* release another trap cpu, and put ourself in a pause mode */
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d cmd:%d rsn:%d atrpcpu:%d initcpu:%d\n", ccpu, 
+                      kdb_cpu_cmd[ccpu], reason, a_trap_cpu, kdb_init_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                reason = KDB_REASON_PAUSE_IPI;
+                kdb_init_cpu = -1;
+            }
+        } else if (rc == 2) {        /* one of ours but condition not met */
+                kdb_begin_session();
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+        }
+    }
+
+    /* following will take care of KDB_CPU_INSTALL_BP, and also release
+     * kdb_init_cpu. it should not be done twice */
+    if ((rc=kdb_check_dbtrap(&reason, ss_mode, regs)) == 0 || rc == 1) {
+        kdb_init_cpu = -1;       /* leaving kdb */
+        goto out;                /* rc properly set to 0 or 1 */
+    }
+    if (reason != KDB_REASON_PAUSE_IPI) {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+    } else
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB && !ss_mode)
+        kdb_begin_session(); 
+
+    kdb_main_entry_misc(reason, regs, ccpu, ss_mode, enabled);
+    /* note, one or more cpu switches may occur in between */
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+            if (ccpu != kdb_init_cpu) {
+                kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_GO;
+                kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+                continue;               /* for the pause guy */
+            }
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                /* execute current instruction without 0xcc */
+                kdb_dbg_prnt_ctrps("nempty:", ccpu);
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            }
+        }
+        if (kdb_cpu_cmd[ccpu] != KDB_CPU_PAUSE  && 
+            kdb_cpu_cmd[ccpu] != KDB_CPU_MAIN_KDB)
+                break;
+    }
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+        ASSERT(cpumask_empty(&kdb_cpu_traps));
+        if (kdb_swbp_exists()) {
+            if (reason == KDB_REASON_BPEXCP) {
+                /* do delayed install */
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            } 
+        }
+        kdb_end_session(ccpu, regs);
+        kdb_init_cpu = -1;
+    }
+out:
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_QUIT) {
+        KDBGP("ccpu:%d _quit IP: %lx\n", ccpu, regs->KDBIP);
+        if (! kdb_session_begun)
+            kdb_install_watchpoints();
+        kdb_time_resume(0);
+        kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    }
+
+    /* for ss and delayed install, TF is set. not much in EXT INT handlers*/
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_NI)
+        kdb_time_resume(1);
+    if (enabled)
+        local_irq_enable();
+
+    KDBGP("kdbmain:X:ccpu:%d rc:%d cmd:%d eflg:0x%lx initc:%d sesn:%d " 
+          "cs:%x irqs:%d ", ccpu, rc, kdb_cpu_cmd[ccpu], regs->eflags, 
+          kdb_init_cpu, kdb_session_begun, regs->cs, local_irq_is_enabled());
+    kdb_dbg_prnt_ctrps("", -1);
+    return (rc ? 1 : 0);
+}
+
+/* 
+ * kdb entry function when coming in via a keyboard
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+int
+kdb_keyboard(struct cpu_user_regs *regs)
+{
+    return kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+
+#if 0
+/*
+ * this function called when kdb session active and user presses ctrl\ again.
+ * the assumption is that the user typed ni/ss cmd, and it never got back into
+ * kdb, or the user is impatient. Either case, we just fake it that the SS did
+ * finish. Since, all other kdb cpus must be holding disabled, the interrupt
+ * would be on the CPU that did the ss/ni cmd
+ */
+void
+kdb_ssni_reenter(struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();
+    int ccmd = kdb_cpu_cmd[ccpu];
+
+    if(ccmd == KDB_CPU_SS || ccmd == KDB_CPU_INSTALL_BP)
+        kdbmain(KDB_REASON_DBEXCP, regs); 
+    else 
+        kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+#endif
+
+/* 
+ * All traps are routed thru here. We care about BP (#3) trap (INT 3) and
+ * the DB trap(#1) only. 
+ * returns: 0 kdb has nothing do with this trap
+ *          1 kdb handled this trap 
+ */
+int
+kdb_handle_trap_entry(int vector, struct cpu_user_regs *regs)
+{
+    int rc = 0;
+    int ccpu = smp_processor_id();
+
+    if (vector == TRAP_int3) {
+        rc = kdbmain(KDB_REASON_BPEXCP, regs);
+
+    } else if (vector == TRAP_debug) {
+        KDBGP("ccpu:%d trapdbg reas:%d\n", ccpu, kdb_trap_immed_reason);
+
+        if (kdb_trap_immed_reason == KDB_TRAP_FATAL) { 
+            KDBGP("kdbtrp:fatal ccpu:%d vec:%d\n", ccpu, vector);
+            rc = kdbmain_fatal(regs, vector);
+            BUG();                             /* no return */
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_KDBSTACK) {
+            kdb_trap_immed_reason = 0;         /* show kdb stack */
+            show_registers(regs);
+            show_stack(regs);
+            regs->eflags &= ~X86_EFLAGS_TF;
+            rc = 1;
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_NONFATAL) {
+            kdb_trap_immed_reason = 0;
+            rc = kdb_keyboard(regs);
+        } else {                         /* ss/ni/delayed install... */
+            if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                current->arch.hvm_vcpu.single_step = 0;
+            rc = kdbmain(KDB_REASON_DBEXCP, regs); 
+        }
+
+    } else if (vector == TRAP_nmi) {                   /* external nmi */
+        /* when nmi is pressed, it could go to one or more or all cpus
+         * depending on the hardware. Also, for now assume it's fatal */
+        KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
+        rc = kdbmain_fatal(regs, TRAP_nmi);
+    } 
+    return rc;
+}
+
+int
+kdb_trap_fatal(int vector, struct cpu_user_regs *regs)
+{
+    kdbmain_fatal(regs, vector);
+    return 0;
+}
+
+/* From smp_send_nmi_allbutself() in crash.c which is static */
+void
+kdb_nmi_pause_cpus(cpumask_t cpumask)
+{
+    int ccpu = smp_processor_id();
+    mdelay(200);
+    cpumask_complement(&cpumask, &cpumask);              /* flip bit map */
+    cpumask_and(&cpumask, &cpumask, &cpu_online_map);    /* remove extra bits */
+    cpumask_clear_cpu(ccpu, &cpumask);/* absolutely make sure we're not on it */
+
+    KDBGP("ccpu:%d nmi pause. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+    if ( !cpumask_empty(&cpumask) )
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+        send_IPI_mask(&cpumask, APIC_DM_NMI);
+#else
+        send_IPI_mask(cpumask, APIC_DM_NMI);
+#endif
+    mdelay(200);
+    KDBGP("ccpu:%d nmi pause done...\n", ccpu);
+}
+
+/* 
+ * Separate function from kdbmain to keep both within sanity levels.
+ */
+DEFINE_SPINLOCK(kdb_fatal_lk);
+static int
+kdbmain_fatal(struct cpu_user_regs *regs, int vector)
+{
+    int ccpu = smp_processor_id();
+
+    console_start_sync();
+
+    KDBGP("mainf:ccpu:%d vec:%d irq:%d\n", ccpu, vector,local_irq_is_enabled());
+    cpumask_set_cpu(ccpu, &kdb_fatal_cpumask);        /* uses LOCK_PREFIX */
+
+    if (spin_trylock(&kdb_fatal_lk)) {
+
+        kdbp("*** kdb (Fatal Error on cpu:%d vec:%d %s):\n", ccpu,
+             vector, kdb_gettrapname(vector));
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+        kdb_display_pc(regs);
+
+        watchdog_disable();     /* important */
+        kdb_sys_crash = 1;
+        kdb_session_begun = 0;  /* incase session already active */
+        local_irq_enable();
+        kdb_nmi_pause_cpus(kdb_fatal_cpumask);
+
+        kdb_clear_prev_cmd();   /* buffered CRs will repeat prev cmd */
+        kdb_session_begun = 1;  /* for kdb_hold_this_cpu() */
+        local_irq_disable();
+    } else {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+    }
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+#if 0
+        /* dump is the only way to exit in crashed state */
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DUMP)
+            kdb_do_dump(regs);
+#endif
+    }
+    return 0;
+}
+
+/* Mostly called in fatal cases. earlykdb calls non-fatal.
+ * kdb_trap_immed_reason is global, so allow only one cpu at a time. Also,
+ * multiple cpu may be crashing at the same time. We enable because if there
+ * is a bad hang, at least ctrl-\ will break into kdb. Also, we don't call
+ * call kdb_keyboard directly becaue we don't have the register context.
+ */
+DEFINE_SPINLOCK(kdb_immed_lk);
+void
+kdb_trap_immed(int reason)            /* fatal, non-fatal, kdb stack etc... */
+{
+    int ccpu = smp_processor_id();
+    int disabled = !local_irq_is_enabled();
+
+    KDBGP("trapimm:ccpu:%d reas:%d\n", ccpu, reason);
+    local_irq_enable();
+    spin_lock(&kdb_immed_lk);
+    kdb_trap_immed_reason = reason;
+    barrier();
+    __asm__ __volatile__ ( "int $1" );
+    kdb_trap_immed_reason = 0;
+
+    spin_unlock(&kdb_immed_lk);
+    if (disabled)
+        local_irq_disable();
+}
+
+/* called very early during init, even before all CPUs are brought online */
+void 
+kdb_init(void)
+{
+        kdb_init_cmdtab();      /* Initialize Command Table */
+}
+
+static const char *
+kdb_gettrapname(int trapno)
+{
+    char *ret;
+    switch (trapno) {
+        case  0:  ret = "Divide Error"; break;
+        case  2:  ret = "NMI Interrupt"; break;
+        case  3:  ret = "Int 3 Trap"; break;
+        case  4:  ret = "Overflow Error"; break;
+        case  6:  ret = "Invalid Opcode"; break;
+        case  8:  ret = "Double Fault"; break;
+        case 10:  ret = "Invalid TSS"; break;
+        case 11:  ret = "Segment Not Present"; break;
+        case 12:  ret = "Stack-Segment Fault"; break;
+        case 13:  ret = "General Protection"; break;
+        case 14:  ret = "Page Fault"; break;
+        case 17:  ret = "Alignment Check"; break;
+        default: ret = " ????? ";
+    }
+    return ret;
+}
+
+
+/* ====================== Generic tracing subsystem ======================== */
+
+#define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
+                           * is 32 bytes */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
+
+typedef struct {
+    union {
+        struct { uint d0; uint cpu_trcid; } s0;
+        uint64_t l0;
+    }u;
+    uint64_t l1, l2, l3; 
+} trc_rec_t;
+
+static volatile unsigned int trcidx;    /* points to where new entry will go */
+static trc_rec_t trca[KDBTRCMAX];       /* trace array */
+
+/* atomically: add i to *p, return prev value of *p (ie, val before add) */
+static int
+kdb_fetch_and_add(int i, uint *p)
+{
+    asm volatile("lock xaddl %0, %1;" : "=r"(i) : "m"(*p), "0"(i));
+    return i;
+}
+
+/* zero out the entire buffer */
+void 
+kdb_trczero(void)
+{
+    for (trcidx = KDBTRCMAX-1; trcidx; trcidx--) {
+        memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    }
+    memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    kdbp("kdb trace buffer has been zeroed\n");
+}
+
+/* add trace entry: eg.: kdbtrc(0xe0f099, intdata, vcpu, domain, 0)
+ *    where:  0xe0f099 : 24bits max trcid, lower 8 bits are set to cpuid */
+void
+kdbtrc(uint trcid, uint int_d0, uint64_t d1_64, uint64_t d2_64, uint64_t d3_64)
+{
+    uint idx;
+
+    if (!kdb_trcon)
+        return;
+
+    idx = kdb_fetch_and_add(1, (uint*)&trcidx);
+    idx = idx % KDBTRCMAX;
+
+#if 0
+    trca[idx].u.s0.cpu_trcid = (smp_processor_id()<<24) | trcid;
+#endif
+    trca[idx].u.s0.cpu_trcid = (trcid<<8) | smp_processor_id();
+    trca[idx].u.s0.d0 = int_d0;
+    trca[idx].l1 = d1_64;
+    trca[idx].l2 = d2_64;
+    trca[idx].l3 = d3_64;
+}
+
+/* give hints so user can print trc buffer via the dd command. last has the
+ * most recent entry */
+void
+kdb_trcp(void)
+{
+    int i = trcidx % KDBTRCMAX;
+
+    i = (i==0) ? KDBTRCMAX-1 : i-1;
+    kdbp("trcbuf:    [0]: %016lx [MAX-1]: %016lx\n", &trca[0],
+         &trca[KDBTRCMAX-1]);
+    kdbp(" [most recent]: %016lx   trcidx: 0x%x\n", &trca[i], trcidx);
+}
+
diff -r 54c8c9eaee92 xen/kdb/x86/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y    := kdb_wp.o
+subdir-y += udis86-1.7
diff -r 54c8c9eaee92 xen/kdb/x86/kdb_wp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/kdb_wp.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,310 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+#if 0
+#define DR6_BT  0x00008000
+#define DR6_BS  0x00004000
+#define DR6_BD  0x00002000
+#endif
+#define DR6_B3  0x00000008
+#define DR6_B2  0x00000004
+#define DR6_B1  0x00000002
+#define DR6_B0  0x00000001
+
+#define KDB_MAXWP 4                          /* DR0 thru DR3 */
+
+struct kdb_wp {
+    kdbma_t  wp_addr;
+    int      wp_rwflag;
+    int      wp_len;
+    int      wp_deleted;                     /* pending delete */
+};
+static struct kdb_wp kdb_wpa[KDB_MAXWP];
+
+/* following because vmcs has it's own dr7. when vmcs runs, it messes up the
+ * native dr7 so we need to save/restore it */
+unsigned long kdb_dr7;
+
+
+/* Set G0-G3 bits in DR7. this does global enable of the corresponding wp */
+static void
+kdb_set_gx_in_dr7(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p | 0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p | 0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p | 0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p | 0x80;
+}
+
+/* Set LEN0 - LEN3 pair bits in DR7 (len should be 1 2 4 or 8) */
+static void
+kdb_set_len_in_dr7(int regno, kdbma_t *dr7p, int len)
+{
+    int lenbits = (len == 8) ? 2 : len-1;
+
+    *dr7p &= ~(0x3 << (18 + 4*regno));
+    *dr7p |= ((ulong)(lenbits & 0x3) << (18 + 4*regno));
+}
+
+static void
+kdb_set_dr7_rw(int regno, kdbma_t *dr7p, int rw)
+{
+    *dr7p &= ~(0x3 << (16 + 4*regno));
+    *dr7p |= ((ulong)(rw & 0x3)) << (16 + 4*regno);
+}
+
+/* get value of a debug register: DR0-DR3 DR6 DR7. other values return 0 */
+kdbma_t
+kdb_rd_dbgreg(int regnum)
+{
+    kdbma_t contents = 0;
+
+    if (regnum == 0)
+        __asm__ ("movq %%db0,%0\n\t":"=r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %%db1,%0\n\t":"=r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %%db2,%0\n\t":"=r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %%db3,%0\n\t":"=r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %%db6,%0\n\t":"=r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %%db7,%0\n\t":"=r"(contents));
+
+    return contents;
+}
+
+static void
+kdb_wr_dbgreg(int regnum, kdbma_t contents)
+{
+    if (regnum == 0)
+        __asm__ ("movq %0,%%db0\n\t"::"r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %0,%%db1\n\t"::"r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %0,%%db2\n\t"::"r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %0,%%db3\n\t"::"r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %0,%%db6\n\t"::"r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %0,%%db7\n\t"::"r"(contents));
+}
+
+static void
+kdb_print_wp_info(char *strp, int idx)
+{
+    kdbp("%s[%d]:%016lx len:%d ", strp, idx, kdb_wpa[idx].wp_addr,
+         kdb_wpa[idx].wp_len);
+    if (kdb_wpa[idx].wp_rwflag == 1)
+        kdbp("on data write only\n");
+    else if (kdb_wpa[idx].wp_rwflag == 2)
+        kdbp("on IO read/write\n");
+    else 
+        kdbp("on data read/write\n");
+}
+
+/*
+ * Returns : 0 if not one of ours
+ *           1 if one of ours
+ */
+int
+kdb_check_watchpoints(struct cpu_user_regs *regs)
+{
+    int wpnum;
+    kdbma_t dr6 = kdb_rd_dbgreg(6);
+
+    KDBGP1("check_wp: IP:%lx EFLAGS:%lx\n", regs->rip, regs->rflags);
+    if (dr6 & DR6_B0)
+        wpnum = 0;
+    else if (dr6 & DR6_B1)
+        wpnum = 1;
+    else if (dr6 & DR6_B2)
+        wpnum = 2;
+    else if (dr6 & DR6_B3)
+        wpnum = 3;
+    else
+        return 0;
+
+    kdb_print_wp_info("Watchpoint ", wpnum);
+    return 1;
+}
+
+/* set a watchpoint at a given address 
+ * PreCondition: addr != 0 */
+static void
+kdb_set_wp(kdbva_t addr, int rwflag, int len)
+{
+    int regno;
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        if (kdb_wpa[regno].wp_addr == addr && !kdb_wpa[regno].wp_deleted) {
+            kdbp("Watchpoint already set\n");
+            return;
+        }
+        if (kdb_wpa[regno].wp_deleted)
+            memset(&kdb_wpa[regno], 0, sizeof(kdb_wpa[regno]));
+    }
+    for (regno=0; regno < KDB_MAXWP && kdb_wpa[regno].wp_addr; regno++);
+    if (regno >= KDB_MAXWP) {
+        kdbp("watchpoint table full. limit:%d\n", KDB_MAXWP);
+        return;
+    }
+    kdb_wpa[regno].wp_addr = addr;
+    kdb_wpa[regno].wp_rwflag = rwflag;
+    kdb_wpa[regno].wp_len = len;
+    kdb_print_wp_info("Watchpoint set ", regno);
+}
+
+/* write reg DR0-3 with address. Update corresponding bits in DR7 */
+static void
+kdb_install_watchpoint(int regno, kdbma_t *dr7p)
+{
+    kdb_set_gx_in_dr7(regno, dr7p);
+    kdb_set_len_in_dr7(regno, dr7p, kdb_wpa[regno].wp_len); 
+    kdb_set_dr7_rw(regno, dr7p, kdb_wpa[regno].wp_rwflag);
+    kdb_wr_dbgreg(regno, kdb_wpa[regno].wp_addr);
+
+    KDBGP1("ccpu:%d installed wp. addr:%lx rw:%x len:%x dr7:%016lx\n",
+           smp_processor_id(), kdb_wpa[regno].wp_addr, 
+           kdb_wpa[regno].wp_rwflag, kdb_wpa[regno].wp_len, *dr7p);
+}
+
+/* clear G0-G3 bits in DR7 for given DR0-3 */
+static void
+kdb_clear_dr7_gx(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p & ~0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p & ~0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p & ~0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p & ~0x80;
+}
+
+/* update dr7 once, as it's slow to update debug regs and cpu's will still be 
+ * paused when leaving kdb.
+ *
+ * Just leave DR0-3 clobbered but remove bits from DR7 to disable wp 
+ */
+void
+kdb_install_watchpoints(void)
+{
+    int regno;
+    kdbma_t dr7 = kdb_rd_dbgreg(7);
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        /* do not clear wp_deleted here as all cpus must clear wps */
+        if (kdb_wpa[regno].wp_deleted) {
+            kdb_clear_dr7_gx(regno, &dr7);
+            continue;
+        }
+        if (kdb_wpa[regno].wp_addr)
+            kdb_install_watchpoint(regno, &dr7);
+    }
+    /* always clear DR6 when leaving */
+    kdb_wr_dbgreg(6, 0);
+    kdb_wr_dbgreg(7, dr7);
+
+    if (dr7 & DR7_ACTIVE_MASK)
+        kdb_dr7 = dr7;
+    else
+        kdb_dr7 = 0;
+#if 0
+    for(dp=domain_list; dp; dp=dp->next_in_list) {
+        struct vcpu *vp;
+        for_each_vcpu(dp, vp) {
+            for (regno=0; regno < KDB_MAXWP; regno++)
+                vp->arch.guest_context.debugreg[regno] = kdb_wpa[regno].wp_addr;
+
+            vp->arch.guest_context.debugreg[6] = 0;
+            vp->arch.guest_context.debugreg[7] = dr7;
+            KDBGP("kdb_install_watchpoints(): v:%p dr7:%lx\n", vp, dr7);
+            /* hvm_set_info_guest(vp);: Can't because can't vmcs_enter in kdb */
+        }
+    }
+#endif
+}
+
+/* clear watchpoint/s. wpnum == -1 to clear all watchpoints */
+void
+kdb_clear_wps(int wpnum)
+{
+    int i;
+
+    if (wpnum >= KDB_MAXWP) {
+        kdbp("Invalid wpnum %d\n", wpnum);
+        return;
+    }
+    if (wpnum >=0) {
+        if (kdb_wpa[wpnum].wp_addr) {
+            kdb_wpa[wpnum].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", wpnum);
+        } else
+            kdbp("watchpoint %d not set\n", wpnum);
+        return;
+    }
+    for (i=0; i < KDB_MAXWP; i++) {
+        if (kdb_wpa[i].wp_addr) {
+            kdb_wpa[i].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", i);
+        }
+    }
+}
+
+/* display any watchpoints that are set */
+static void
+kdb_display_wps(void)
+{
+    int i;
+    for (i=0; i < KDB_MAXWP; i++)
+        if (kdb_wpa[i].wp_addr && !kdb_wpa[i].wp_deleted) 
+            kdb_print_wp_info("", i);
+}
+
+/* 
+ * Display or Set hardware breakpoints, ie, watchpoints:
+ *   - Upto 4 are allowed
+ *   
+ *  rw_flag should be one of: 
+ *     01 == break on data write only
+ *     10 == break on IO read/write
+ *     11 == Break on data reads or writes
+ *
+ *  len should be one of : 1 2 4 8 
+ */
+void
+kdb_do_watchpoints(kdbva_t addr, int rw_flag, int len)
+{
+    if (addr == 0) {
+        kdb_display_wps();        /* display set watchpoints */
+        return;
+    }
+    kdb_set_wp(addr, rw_flag, len);
+    return;
+}
+
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/LICENSE
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/LICENSE	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,22 @@
+Copyright (c) 2002, 2003, 2004, 2005, 2006 <vivek@sig9.com>
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, 
+are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice, 
+      this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright notice, 
+      this list of conditions and the following disclaimer in the documentation 
+      and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/Makefile	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,5 @@
+
+CFLAGS		+= -D__UD_STANDALONE__
+obj-y		:= decode.o input.o itab.o kdb_dis.o syn-att.o syn.o \
+                   syn-intel.o udis86.o
+
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/README	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,10 @@
+
+http://udis86.sourceforge.net/
+udis86-1.6 : 
+  - cd libudis86
+  - cp *c to here
+  - cp *h to here
+   
+Mukesh Rathor
+04/30/2008
+
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/decode.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,1197 @@
+/* -----------------------------------------------------------------------------
+ * decode.c
+ *
+ * Copyright (c) 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <assert.h>
+#include <string.h>
+#endif
+
+#include "types.h"
+#include "itab.h"
+#include "input.h"
+#include "decode.h"
+
+/* The max number of prefixes to an instruction */
+#define MAX_PREFIXES    15
+
+static struct ud_itab_entry ie_invalid = { UD_Iinvalid, O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_pause   = { UD_Ipause,   O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_nop     = { UD_Inop,     O_NONE, O_NONE, O_NONE, P_none };
+
+
+/* Looks up mnemonic code in the mnemonic string table
+ * Returns NULL if the mnemonic code is invalid
+ */
+const char * ud_lookup_mnemonic( enum ud_mnemonic_code c )
+{
+    if ( c < UD_Id3vil )
+        return ud_mnemonics_str[ c ];
+    return NULL;
+}
+
+
+/* Extracts instruction prefixes.
+ */
+static int get_prefixes( struct ud* u )
+{
+    unsigned int have_pfx = 1;
+    unsigned int i;
+    uint8_t curr;
+
+    /* if in error state, bail out */
+    if ( u->error ) 
+        return -1; 
+
+    /* keep going as long as there are prefixes available */
+    for ( i = 0; have_pfx ; ++i ) {
+
+        /* Get next byte. */
+        inp_next(u); 
+        if ( u->error ) 
+            return -1;
+        curr = inp_curr( u );
+
+        /* rex prefixes in 64bit mode */
+        if ( u->dis_mode == 64 && ( curr & 0xF0 ) == 0x40 ) {
+            u->pfx_rex = curr;  
+        } else {
+            switch ( curr )  
+            {
+            case 0x2E : 
+                u->pfx_seg = UD_R_CS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x36 :     
+                u->pfx_seg = UD_R_SS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x3E : 
+                u->pfx_seg = UD_R_DS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x26 : 
+                u->pfx_seg = UD_R_ES; 
+                u->pfx_rex = 0;
+                break;
+            case 0x64 : 
+                u->pfx_seg = UD_R_FS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x65 : 
+                u->pfx_seg = UD_R_GS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x67 : /* adress-size override prefix */ 
+                u->pfx_adr = 0x67;
+                u->pfx_rex = 0;
+                break;
+            case 0xF0 : 
+                u->pfx_lock = 0xF0;
+                u->pfx_rex  = 0;
+                break;
+            case 0x66: 
+                /* the 0x66 sse prefix is only effective if no other sse prefix
+                 * has already been specified.
+                 */
+                if ( !u->pfx_insn ) u->pfx_insn = 0x66;
+                u->pfx_opr = 0x66;           
+                u->pfx_rex = 0;
+                break;
+            case 0xF2:
+                u->pfx_insn  = 0xF2;
+                u->pfx_repne = 0xF2; 
+                u->pfx_rex   = 0;
+                break;
+            case 0xF3:
+                u->pfx_insn = 0xF3;
+                u->pfx_rep  = 0xF3; 
+                u->pfx_repe = 0xF3; 
+                u->pfx_rex  = 0;
+                break;
+            default : 
+                /* No more prefixes */
+                have_pfx = 0;
+                break;
+            }
+        }
+
+        /* check if we reached max instruction length */
+        if ( i + 1 == MAX_INSN_LENGTH ) {
+            u->error = 1;
+            break;
+        }
+    }
+
+    /* return status */
+    if ( u->error ) 
+        return -1; 
+
+    /* rewind back one byte in stream, since the above loop 
+     * stops with a non-prefix byte. 
+     */
+    inp_back(u);
+
+    /* speculatively determine the effective operand mode,
+     * based on the prefixes and the current disassembly
+     * mode. This may be inaccurate, but useful for mode
+     * dependent decoding.
+     */
+    if ( u->dis_mode == 64 ) {
+        u->opr_mode = REX_W( u->pfx_rex ) ? 64 : ( ( u->pfx_opr ) ? 16 : 32 ) ;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 64;
+    } else if ( u->dis_mode == 32 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+        u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+    } else if ( u->dis_mode == 16 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+    }
+
+    return 0;
+}
+
+
+/* Searches the instruction tables for the right entry.
+ */
+static int search_itab( struct ud * u )
+{
+    struct ud_itab_entry * e = NULL;
+    enum ud_itab_index table;
+    uint8_t peek;
+    uint8_t did_peek = 0;
+    uint8_t curr; 
+    uint8_t index;
+
+    /* if in state of error, return */
+    if ( u->error ) 
+        return -1;
+
+    /* get first byte of opcode. */
+    inp_next(u); 
+    if ( u->error ) 
+        return -1;
+    curr = inp_curr(u); 
+
+    /* resolve xchg, nop, pause crazyness */
+    if ( 0x90 == curr ) {
+        if ( !( u->dis_mode == 64 && REX_B( u->pfx_rex ) ) ) {
+            if ( u->pfx_rep ) {
+                u->pfx_rep = 0;
+                e = & ie_pause;
+            } else {
+                e = & ie_nop;
+            }
+            goto found_entry;
+        }
+    }
+
+    /* get top-level table */
+    if ( 0x0F == curr ) {
+        table = ITAB__0F;
+        curr  = inp_next(u);
+        if ( u->error )
+            return -1;
+
+        /* 2byte opcodes can be modified by 0x66, F3, and F2 prefixes */
+        if ( 0x66 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSE66__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSE66__0F;
+                u->pfx_opr = 0;
+            }
+        } else if ( 0xF2 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF2__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF2__0F; 
+                u->pfx_repne = 0;
+            }
+        } else if ( 0xF3 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF3__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF3__0F;
+                u->pfx_repe = 0;
+                u->pfx_rep  = 0;
+            }
+        }
+    /* pick an instruction from the 1byte table */
+    } else {
+        table = ITAB__1BYTE; 
+    }
+
+    index = curr;
+
+search:
+
+    e = & ud_itab_list[ table ][ index ];
+
+    /* if mnemonic constant is a standard instruction constant
+     * our search is over.
+     */
+    
+    if ( e->mnemonic < UD_Id3vil ) {
+        if ( e->mnemonic == UD_Iinvalid ) {
+            if ( did_peek ) {
+                inp_next( u ); if ( u->error ) return -1;
+            }
+            goto found_entry;
+        }
+        goto found_entry;
+    }
+
+    table = e->prefix;
+
+    switch ( e->mnemonic )
+    {
+    case UD_Igrp_reg:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_REG( peek );
+        break;
+
+    case UD_Igrp_mod:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_MOD( peek );
+        if ( index == 3 )
+           index = ITAB__MOD_INDX__11;
+        else 
+           index = ITAB__MOD_INDX__NOT_11; 
+        break;
+
+    case UD_Igrp_rm:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = MODRM_RM( curr );
+        break;
+
+    case UD_Igrp_x87:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = curr - 0xC0;
+        break;
+
+    case UD_Igrp_osize:
+        if ( u->opr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->opr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+ 
+    case UD_Igrp_asize:
+        if ( u->adr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->adr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;               
+
+    case UD_Igrp_mode:
+        if ( u->dis_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->dis_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+
+    case UD_Igrp_vendor:
+        if ( u->vendor == UD_VENDOR_INTEL ) 
+            index = ITAB__VENDOR_INDX__INTEL; 
+        else if ( u->vendor == UD_VENDOR_AMD )
+            index = ITAB__VENDOR_INDX__AMD;
+        else {
+            kdbp("KDB:search_itab(): unrecognized vendor id\n");
+            return -1;
+        }
+        break;
+
+    case UD_Id3vil:
+        kdbp("KDB:search_itab(): invalid instr mnemonic constant Id3vil\n");
+        return -1;
+
+    default:
+        kdbp("KDB:search_itab(): invalid instruction mnemonic constant\n");
+        return -1;
+    }
+
+    goto search;
+
+found_entry:
+
+    u->itab_entry = e;
+    u->mnemonic = u->itab_entry->mnemonic;
+
+    return 0;
+}
+
+
+static unsigned int resolve_operand_size( const struct ud * u, unsigned int s )
+{
+    switch ( s ) 
+    {
+    case SZ_V:
+        return ( u->opr_mode );
+    case SZ_Z:  
+        return ( u->opr_mode == 16 ) ? 16 : 32;
+    case SZ_P:  
+        return ( u->opr_mode == 16 ) ? SZ_WP : SZ_DP;
+    case SZ_MDQ:
+        return ( u->opr_mode == 16 ) ? 32 : u->opr_mode;
+    case SZ_RDQ:
+        return ( u->dis_mode == 64 ) ? 64 : 32;
+    default:
+        return s;
+    }
+}
+
+
+static int resolve_mnemonic( struct ud* u )
+{
+  /* far/near flags */
+  u->br_far = 0;
+  u->br_near = 0;
+  /* readjust operand sizes for call/jmp instrcutions */
+  if ( u->mnemonic == UD_Icall || u->mnemonic == UD_Ijmp ) {
+    /* WP: 16bit pointer */
+    if ( u->operand[ 0 ].size == SZ_WP ) {
+        u->operand[ 0 ].size = 16;
+        u->br_far = 1;
+        u->br_near= 0;
+    /* DP: 32bit pointer */
+    } else if ( u->operand[ 0 ].size == SZ_DP ) {
+        u->operand[ 0 ].size = 32;
+        u->br_far = 1;
+        u->br_near= 0;
+    } else {
+        u->br_far = 0;
+        u->br_near= 1;
+    }
+  /* resolve 3dnow weirdness. */
+  } else if ( u->mnemonic == UD_I3dnow ) {
+    u->mnemonic = ud_itab_list[ ITAB__3DNOW ][ inp_curr( u )  ].mnemonic;
+  }
+  /* SWAPGS is only valid in 64bits mode */
+  if ( u->mnemonic == UD_Iswapgs && u->dis_mode != 64 ) {
+    u->error = 1;
+    return -1;
+  }
+
+  return 0;
+}
+
+
+/* -----------------------------------------------------------------------------
+ * decode_a()- Decodes operands of the type seg:offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_a(struct ud* u, struct ud_operand *op)
+{
+  if (u->opr_mode == 16) {  
+    /* seg16:off16 */
+    op->type = UD_OP_PTR;
+    op->size = 32;
+    op->lval.ptr.off = inp_uint16(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  } else {
+    /* seg16:off32 */
+    op->type = UD_OP_PTR;
+    op->size = 48;
+    op->lval.ptr.off = inp_uint32(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_gpr() - Returns decoded General Purpose Register 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+decode_gpr(register struct ud* u, unsigned int s, unsigned char rm)
+{
+  s = resolve_operand_size(u, s);
+        
+  switch (s) {
+    case 64:
+        return UD_R_RAX + rm;
+    case SZ_DP:
+    case 32:
+        return UD_R_EAX + rm;
+    case SZ_WP:
+    case 16:
+        return UD_R_AX  + rm;
+    case  8:
+        if (u->dis_mode == 64 && u->pfx_rex) {
+            if (rm >= 4)
+                return UD_R_SPL + (rm-4);
+            return UD_R_AL + rm;
+        } else return UD_R_AL + rm;
+    default:
+        return 0;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr64() - 64bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr64(struct ud* u, enum ud_operand_code gpr_op)
+{
+  if (gpr_op >= OP_rAXr8 && gpr_op <= OP_rDIr15)
+    gpr_op = (gpr_op - OP_rAXr8) | (REX_B(u->pfx_rex) << 3);          
+  else  gpr_op = (gpr_op - OP_rAX);
+
+  if (u->opr_mode == 16)
+    return gpr_op + UD_R_AX;
+  if (u->dis_mode == 32 || 
+    (u->opr_mode == 32 && ! (REX_W(u->pfx_rex) || u->default64))) {
+    return gpr_op + UD_R_EAX;
+  }
+
+  return gpr_op + UD_R_RAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr32 () - 32bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr32(struct ud* u, enum ud_operand_code gpr_op)
+{
+  gpr_op = gpr_op - OP_eAX;
+
+  if (u->opr_mode == 16) 
+    return gpr_op + UD_R_AX;
+
+  return gpr_op +  UD_R_EAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_reg() - Resolves the register type 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_reg(struct ud* u, unsigned int type, unsigned char i)
+{
+  switch (type) {
+    case T_MMX :    return UD_R_MM0  + (i & 7);
+    case T_XMM :    return UD_R_XMM0 + i;
+    case T_CRG :    return UD_R_CR0  + i;
+    case T_DBG :    return UD_R_DR0  + i;
+    case T_SEG :    return UD_R_ES   + (i & 7);
+    case T_NONE:
+    default:    return UD_NONE;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_imm() - Decodes Immediate values.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_imm(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  op->size = resolve_operand_size(u, s);
+  op->type = UD_OP_IMM;
+
+  switch (op->size) {
+    case  8: op->lval.sbyte = inp_uint8(u);   break;
+    case 16: op->lval.uword = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: return;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_modrm() - Decodes ModRM Byte
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_modrm(struct ud* u, struct ud_operand *op, unsigned int s, 
+         unsigned char rm_type, struct ud_operand *opreg, 
+         unsigned char reg_size, unsigned char reg_type)
+{
+  unsigned char mod, rm, reg;
+
+  inp_next(u);
+
+  /* get mod, r/m and reg fields */
+  mod = MODRM_MOD(inp_curr(u));
+  rm  = (REX_B(u->pfx_rex) << 3) | MODRM_RM(inp_curr(u));
+  reg = (REX_R(u->pfx_rex) << 3) | MODRM_REG(inp_curr(u));
+
+  op->size = resolve_operand_size(u, s);
+
+  /* if mod is 11b, then the UD_R_m specifies a gpr/mmx/sse/control/debug */
+  if (mod == 3) {
+    op->type = UD_OP_REG;
+    if (rm_type ==  T_GPR)
+        op->base = decode_gpr(u, op->size, rm);
+    else    op->base = resolve_reg(u, rm_type, (REX_B(u->pfx_rex) << 3) | (rm&7));
+  } 
+  /* else its memory addressing */  
+  else {
+    op->type = UD_OP_MEM;
+
+    /* 64bit addressing */
+    if (u->adr_mode == 64) {
+
+        op->base = UD_R_RAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && (rm & 7) == 5) {           
+            op->base = UD_R_RIP;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+            
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_RAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_RAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            /* special conditions for base reference */
+            if (op->index == UD_R_RSP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            if (op->base == UD_R_RBP || op->base == UD_R_R13) {
+                if (mod == 0) 
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 32-Bit addressing mode */
+    else if (u->adr_mode == 32) {
+
+        /* get base */
+        op->base = UD_R_EAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && rm == 5) {
+            op->base = UD_NONE;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_EAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_EAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            if (op->index == UD_R_ESP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            /* special condition for base reference */
+            if (op->base == UD_R_EBP) {
+                if (mod == 0)
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 16bit addressing mode */
+    else  {
+        switch (rm) {
+            case 0: op->base = UD_R_BX; op->index = UD_R_SI; break;
+            case 1: op->base = UD_R_BX; op->index = UD_R_DI; break;
+            case 2: op->base = UD_R_BP; op->index = UD_R_SI; break;
+            case 3: op->base = UD_R_BP; op->index = UD_R_DI; break;
+            case 4: op->base = UD_R_SI; break;
+            case 5: op->base = UD_R_DI; break;
+            case 6: op->base = UD_R_BP; break;
+            case 7: op->base = UD_R_BX; break;
+        }
+
+        if (mod == 0 && rm == 6) {
+            op->offset= 16;
+            op->base = UD_NONE;
+        }
+        else if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2) 
+            op->offset = 16;
+    }
+  }  
+
+  /* extract offset, if any */
+  switch(op->offset) {
+    case 8 : op->lval.ubyte  = inp_uint8(u);  break;
+    case 16: op->lval.uword  = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: break;
+  }
+
+  /* resolve register encoded in reg field */
+  if (opreg) {
+    opreg->type = UD_OP_REG;
+    opreg->size = resolve_operand_size(u, reg_size);
+    if (reg_type == T_GPR) 
+        opreg->base = decode_gpr(u, opreg->size, reg);
+    else opreg->base = resolve_reg(u, reg_type, reg);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_o() - Decodes offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_o(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  switch (u->adr_mode) {
+    case 64:
+        op->offset = 64; 
+        op->lval.uqword = inp_uint64(u); 
+        break;
+    case 32:
+        op->offset = 32; 
+        op->lval.udword = inp_uint32(u); 
+        break;
+    case 16:
+        op->offset = 16; 
+        op->lval.uword  = inp_uint16(u); 
+        break;
+    default:
+        return;
+  }
+  op->type = UD_OP_MEM;
+  op->size = resolve_operand_size(u, s);
+}
+
+/* -----------------------------------------------------------------------------
+ * disasm_operands() - Disassembles Operands.
+ * -----------------------------------------------------------------------------
+ */
+static int disasm_operands(register struct ud* u)
+{
+
+
+  /* mopXt = map entry, operand X, type; */
+  enum ud_operand_code mop1t = u->itab_entry->operand1.type;
+  enum ud_operand_code mop2t = u->itab_entry->operand2.type;
+  enum ud_operand_code mop3t = u->itab_entry->operand3.type;
+
+  /* mopXs = map entry, operand X, size */
+  unsigned int mop1s = u->itab_entry->operand1.size;
+  unsigned int mop2s = u->itab_entry->operand2.size;
+  unsigned int mop3s = u->itab_entry->operand3.size;
+
+  /* iop = instruction operand */
+  register struct ud_operand* iop = u->operand;
+    
+  switch(mop1t) {
+    
+    case OP_A :
+        decode_a(u, &(iop[0]));
+        break;
+    
+    /* M[b] ... */
+    case OP_M :
+        if (MODRM_MOD(inp_peek(u)) == 3)
+            u->error= 1;
+    /* E, G/P/V/I/CL/1/S */
+    case OP_E :
+        if (mop2t == OP_G) {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+            else if (mop3t == OP_CL) {
+                iop[2].type = UD_OP_REG;
+                iop[2].base = UD_R_CL;
+                iop[2].size = 8;
+            }
+        }
+        else if (mop2t == OP_P)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_MMX);
+        else if (mop2t == OP_V)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_XMM);
+        else if (mop2t == OP_S)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_SEG);
+        else {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, NULL, 0, T_NONE);
+            if (mop2t == OP_CL) {
+                iop[1].type = UD_OP_REG;
+                iop[1].base = UD_R_CL;
+                iop[1].size = 8;
+            } else if (mop2t == OP_I1) {
+                iop[1].type = UD_OP_CONST;
+                u->operand[1].lval.udword = 1;
+            } else if (mop2t == OP_I) {
+                decode_imm(u, mop2s, &(iop[1]));
+            }
+        }
+        break;
+
+    /* G, E/PR[,I]/VR */
+    case OP_G :
+        if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_W)
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        break;
+
+    /* AL..BH, I/O/DX */
+    case OP_AL : case OP_CL : case OP_DL : case OP_BL :
+    case OP_AH : case OP_CH : case OP_DH : case OP_BH :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AL + (mop1t - OP_AL);
+        iop[0].size = 8;
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        }
+        else if (mop2t == OP_O)
+            decode_o(u, mop2s, &(iop[1]));
+        break;
+
+    /* rAX[r8]..rDI[r15], I/rAX..rDI/O */
+    case OP_rAXr8 : case OP_rCXr9 : case OP_rDXr10 : case OP_rBXr11 :
+    case OP_rSPr12: case OP_rBPr13: case OP_rSIr14 : case OP_rDIr15 :
+    case OP_rAX : case OP_rCX : case OP_rDX : case OP_rBX :
+    case OP_rSP : case OP_rBP : case OP_rSI : case OP_rDI :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr64(u, mop1t);
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t >= OP_rAX && mop2t <= OP_rDI) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = resolve_gpr64(u, mop2t);
+        }
+        else if (mop2t == OP_O) {
+            decode_o(u, mop2s, &(iop[1]));  
+            iop[0].size = resolve_operand_size(u, mop2s);
+        }
+        break;
+
+    /* AL[r8b]..BH[r15b], I */
+    case OP_ALr8b : case OP_CLr9b : case OP_DLr10b : case OP_BLr11b :
+    case OP_AHr12b: case OP_CHr13b: case OP_DHr14b : case OP_BHr15b :
+    {
+        ud_type_t gpr = (mop1t - OP_ALr8b) + UD_R_AL + 
+                        (REX_B(u->pfx_rex) << 3);
+        if (UD_R_AH <= gpr && u->pfx_rex)
+            gpr = gpr + 4;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = gpr;
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+    }
+
+    /* eAX..eDX, DX/I */
+    case OP_eAX : case OP_eCX : case OP_eDX : case OP_eBX :
+    case OP_eSP : case OP_eBP : case OP_eSI : case OP_eDI :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr32(u, mop1t);
+        if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        } else if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+
+    /* ES..GS */
+    case OP_ES : case OP_CS : case OP_DS :
+    case OP_SS : case OP_FS : case OP_GS :
+
+        /* in 64bits mode, only fs and gs are allowed */
+        if (u->dis_mode == 64)
+            if (mop1t != OP_FS && mop1t != OP_GS)
+                u->error= 1;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t - OP_ES) + UD_R_ES;
+        iop[0].size = 16;
+
+        break;
+
+    /* J */
+    case OP_J :
+        decode_imm(u, mop1s, &(iop[0]));        
+        iop[0].type = UD_OP_JIMM;
+        break ;
+
+    /* PR, I */
+    case OP_PR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* VR, I */
+    case OP_VR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* P, Q[,I]/W/E[,I],VR */
+    case OP_P :
+        if (mop2t == OP_Q) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_W) {
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        }
+        break;
+
+    /* R, C/D */
+    case OP_R :
+        if (mop2t == OP_C)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_CRG);
+        else if (mop2t == OP_D)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_DBG);
+        break;
+
+    /* C, R */
+    case OP_C :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_CRG);
+        break;
+
+    /* D, R */
+    case OP_D :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_DBG);
+        break;
+
+    /* Q, P */
+    case OP_Q :
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, &(iop[1]), mop2s, T_MMX);
+        break;
+
+    /* S, E */
+    case OP_S :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_SEG);
+        break;
+
+    /* W, V */
+    case OP_W :
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, &(iop[1]), mop2s, T_XMM);
+        break;
+
+    /* V, W[,I]/Q/M/E */
+    case OP_V :
+        if (mop2t == OP_W) {
+            /* special cases for movlps and movhps */
+            if (MODRM_MOD(inp_peek(u)) == 3) {
+                if (u->mnemonic == UD_Imovlps)
+                    u->mnemonic = UD_Imovhlps;
+                else
+                if (u->mnemonic == UD_Imovhps)
+                    u->mnemonic = UD_Imovlhps;
+            }
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_XMM);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_Q)
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        else if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        }
+        break;
+
+    /* DX, eAX/AL */
+    case OP_DX :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_DX;
+        iop[0].size = 16;
+
+        if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        } else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 8;
+        }
+
+        break;
+
+    /* I, I/AL/eAX */
+    case OP_I :
+        decode_imm(u, mop1s, &(iop[0]));
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 16;
+        } else if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        }
+        break;
+
+    /* O, AL/eAX */
+    case OP_O :
+        decode_o(u, mop1s, &(iop[0]));
+        iop[1].type = UD_OP_REG;
+        iop[1].size = resolve_operand_size(u, mop1s);
+        if (mop2t == OP_AL)
+            iop[1].base = UD_R_AL;
+        else if (mop2t == OP_eAX)
+            iop[1].base = resolve_gpr32(u, mop2t);
+        else if (mop2t == OP_rAX)
+            iop[1].base = resolve_gpr64(u, mop2t);      
+        break;
+
+    /* 3 */
+    case OP_I3 :
+        iop[0].type = UD_OP_CONST;
+        iop[0].lval.sbyte = 3;
+        break;
+
+    /* ST(n), ST(n) */
+    case OP_ST0 : case OP_ST1 : case OP_ST2 : case OP_ST3 :
+    case OP_ST4 : case OP_ST5 : case OP_ST6 : case OP_ST7 :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t-OP_ST0) + UD_R_ST0;
+        iop[0].size = 0;
+
+        if (mop2t >= OP_ST0 && mop2t <= OP_ST7) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = (mop2t-OP_ST0) + UD_R_ST0;
+            iop[1].size = 0;
+        }
+        break;
+
+    /* AX */
+    case OP_AX:
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AX;
+        iop[0].size = 16;
+        break;
+
+    /* none */
+    default :
+        iop[0].type = iop[1].type = iop[2].type = UD_NONE;
+  }
+
+  return 0;
+}
+
+/* -----------------------------------------------------------------------------
+ * clear_insn() - clear instruction pointer 
+ * -----------------------------------------------------------------------------
+ */
+static int clear_insn(register struct ud* u)
+{
+  u->error     = 0;
+  u->pfx_seg   = 0;
+  u->pfx_opr   = 0;
+  u->pfx_adr   = 0;
+  u->pfx_lock  = 0;
+  u->pfx_repne = 0;
+  u->pfx_rep   = 0;
+  u->pfx_repe  = 0;
+  u->pfx_seg   = 0;
+  u->pfx_rex   = 0;
+  u->pfx_insn  = 0;
+  u->mnemonic  = UD_Inone;
+  u->itab_entry = NULL;
+
+  memset( &u->operand[ 0 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 1 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 2 ], 0, sizeof( struct ud_operand ) );
+ 
+  return 0;
+}
+
+static int do_mode( struct ud* u )
+{
+  /* if in error state, bail out */
+  if ( u->error ) return -1; 
+
+  /* propagate perfix effects */
+  if ( u->dis_mode == 64 ) {  /* set 64bit-mode flags */
+
+    /* Check validity of  instruction m64 */
+    if ( P_INV64( u->itab_entry->prefix ) ) {
+        u->error = 1;
+        return -1;
+    }
+
+    /* effective rex prefix is the  effective mask for the 
+     * instruction hard-coded in the opcode map.
+     */
+    u->pfx_rex = ( u->pfx_rex & 0x40 ) | 
+                 ( u->pfx_rex & REX_PFX_MASK( u->itab_entry->prefix ) ); 
+
+    /* whether this instruction has a default operand size of 
+     * 64bit, also hardcoded into the opcode map.
+     */
+    u->default64 = P_DEF64( u->itab_entry->prefix ); 
+    /* calculate effective operand size */
+    if ( REX_W( u->pfx_rex ) ) {
+        u->opr_mode = 64;
+    } else if ( u->pfx_opr ) {
+        u->opr_mode = 16;
+    } else {
+        /* unless the default opr size of instruction is 64,
+         * the effective operand size in the absence of rex.w
+         * prefix is 32.
+         */
+        u->opr_mode = ( u->default64 ) ? 64 : 32;
+    }
+
+    /* calculate effective address size */
+    u->adr_mode = (u->pfx_adr) ? 32 : 64;
+  } else if ( u->dis_mode == 32 ) { /* set 32bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+    u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+  } else if ( u->dis_mode == 16 ) { /* set 16bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+    u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+  }
+
+  /* These flags determine which operand to apply the operand size
+   * cast to.
+   */
+  u->c1 = ( P_C1( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c2 = ( P_C2( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c3 = ( P_C3( u->itab_entry->prefix ) ) ? 1 : 0;
+
+  /* set flags for implicit addressing */
+  u->implicit_addr = P_IMPADDR( u->itab_entry->prefix );
+
+  return 0;
+}
+
+static int gen_hex( struct ud *u )
+{
+  unsigned int i;
+  unsigned char *src_ptr = inp_sess( u );
+  char* src_hex;
+
+  /* bail out if in error stat. */
+  if ( u->error ) return -1; 
+  /* output buffer pointe */
+  src_hex = ( char* ) u->insn_hexcode;
+  /* for each byte used to decode instruction */
+  for ( i = 0; i < u->inp_ctr; ++i, ++src_ptr) {
+    snprintf( src_hex, 2, "%02x", *src_ptr & 0xFF );
+    src_hex += 2;
+  }
+  return 0;
+}
+
+/* =============================================================================
+ * ud_decode() - Instruction decoder. Returns the number of bytes decoded.
+ * =============================================================================
+ */
+unsigned int ud_decode( struct ud* u )
+{
+  inp_start(u);
+
+  if ( clear_insn( u ) ) {
+    ; /* error */
+  } else if ( get_prefixes( u ) != 0 ) {
+    ; /* error */
+  } else if ( search_itab( u ) != 0 ) {
+    ; /* error */
+  } else if ( do_mode( u ) != 0 ) {
+    ; /* error */
+  } else if ( disasm_operands( u ) != 0 ) {
+    ; /* error */
+  } else if ( resolve_mnemonic( u ) != 0 ) {
+    ; /* error */
+  }
+
+  /* Handle decode error. */
+  if ( u->error ) {
+    /* clear out the decode data. */
+    clear_insn( u );
+    /* mark the sequence of bytes as invalid. */
+    u->itab_entry = & ie_invalid;
+    u->mnemonic = u->itab_entry->mnemonic;
+  } 
+
+  u->insn_offset = u->pc; /* set offset of instruction */
+  u->insn_fill = 0;   /* set translation buffer index to 0 */
+  u->pc += u->inp_ctr;    /* move program counter by bytes decoded */
+  gen_hex( u );       /* generate hex code */
+
+  /* return number of bytes disassembled. */
+  return u->inp_ctr;
+}
+
+/* vim:cindent
+ * vim:ts=4
+ * vim:sw=4
+ * vim:expandtab
+ */
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/decode.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,273 @@
+#ifndef UD_DECODE_H
+#define UD_DECODE_H
+
+#define MAX_INSN_LENGTH 15
+
+/* register classes */
+#define T_NONE  0
+#define T_GPR   1
+#define T_MMX   2
+#define T_CRG   3
+#define T_DBG   4
+#define T_SEG   5
+#define T_XMM   6
+
+/* itab prefix bits */
+#define P_none          ( 0 )
+#define P_c1            ( 1 << 0 )
+#define P_C1(n)         ( ( n >> 0 ) & 1 )
+#define P_rexb          ( 1 << 1 )
+#define P_REXB(n)       ( ( n >> 1 ) & 1 )
+#define P_depM          ( 1 << 2 )
+#define P_DEPM(n)       ( ( n >> 2 ) & 1 )
+#define P_c3            ( 1 << 3 )
+#define P_C3(n)         ( ( n >> 3 ) & 1 )
+#define P_inv64         ( 1 << 4 )
+#define P_INV64(n)      ( ( n >> 4 ) & 1 )
+#define P_rexw          ( 1 << 5 )
+#define P_REXW(n)       ( ( n >> 5 ) & 1 )
+#define P_c2            ( 1 << 6 )
+#define P_C2(n)         ( ( n >> 6 ) & 1 )
+#define P_def64         ( 1 << 7 )
+#define P_DEF64(n)      ( ( n >> 7 ) & 1 )
+#define P_rexr          ( 1 << 8 )
+#define P_REXR(n)       ( ( n >> 8 ) & 1 )
+#define P_oso           ( 1 << 9 )
+#define P_OSO(n)        ( ( n >> 9 ) & 1 )
+#define P_aso           ( 1 << 10 )
+#define P_ASO(n)        ( ( n >> 10 ) & 1 )
+#define P_rexx          ( 1 << 11 )
+#define P_REXX(n)       ( ( n >> 11 ) & 1 )
+#define P_ImpAddr       ( 1 << 12 )
+#define P_IMPADDR(n)    ( ( n >> 12 ) & 1 )
+
+/* rex prefix bits */
+#define REX_W(r)        ( ( 0xF & ( r ) )  >> 3 )
+#define REX_R(r)        ( ( 0x7 & ( r ) )  >> 2 )
+#define REX_X(r)        ( ( 0x3 & ( r ) )  >> 1 )
+#define REX_B(r)        ( ( 0x1 & ( r ) )  >> 0 )
+#define REX_PFX_MASK(n) ( ( P_REXW(n) << 3 ) | \
+                          ( P_REXR(n) << 2 ) | \
+                          ( P_REXX(n) << 1 ) | \
+                          ( P_REXB(n) << 0 ) )
+
+/* scable-index-base bits */
+#define SIB_S(b)        ( ( b ) >> 6 )
+#define SIB_I(b)        ( ( ( b ) >> 3 ) & 7 )
+#define SIB_B(b)        ( ( b ) & 7 )
+
+/* modrm bits */
+#define MODRM_REG(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_NNN(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_MOD(b)    ( ( ( b ) >> 6 ) & 3 )
+#define MODRM_RM(b)     ( ( b ) & 7 )
+
+/* operand type constants -- order is important! */
+
+enum ud_operand_code {
+    OP_NONE,
+
+    OP_A,      OP_E,      OP_M,       OP_G,       
+    OP_I,
+
+    OP_AL,     OP_CL,     OP_DL,      OP_BL,
+    OP_AH,     OP_CH,     OP_DH,      OP_BH,
+
+    OP_ALr8b,  OP_CLr9b,  OP_DLr10b,  OP_BLr11b,
+    OP_AHr12b, OP_CHr13b, OP_DHr14b,  OP_BHr15b,
+
+    OP_AX,     OP_CX,     OP_DX,      OP_BX,
+    OP_SI,     OP_DI,     OP_SP,      OP_BP,
+
+    OP_rAX,    OP_rCX,    OP_rDX,     OP_rBX,  
+    OP_rSP,    OP_rBP,    OP_rSI,     OP_rDI,
+
+    OP_rAXr8,  OP_rCXr9,  OP_rDXr10,  OP_rBXr11,  
+    OP_rSPr12, OP_rBPr13, OP_rSIr14,  OP_rDIr15,
+
+    OP_eAX,    OP_eCX,    OP_eDX,     OP_eBX,
+    OP_eSP,    OP_eBP,    OP_eSI,     OP_eDI,
+
+    OP_ES,     OP_CS,     OP_SS,      OP_DS,  
+    OP_FS,     OP_GS,
+
+    OP_ST0,    OP_ST1,    OP_ST2,     OP_ST3,
+    OP_ST4,    OP_ST5,    OP_ST6,     OP_ST7,
+
+    OP_J,      OP_S,      OP_O,          
+    OP_I1,     OP_I3, 
+
+    OP_V,      OP_W,      OP_Q,       OP_P, 
+
+    OP_R,      OP_C,  OP_D,       OP_VR,  OP_PR
+};
+
+
+/* operand size constants */
+
+enum ud_operand_size {
+    SZ_NA  = 0,
+    SZ_Z   = 1,
+    SZ_V   = 2,
+    SZ_P   = 3,
+    SZ_WP  = 4,
+    SZ_DP  = 5,
+    SZ_MDQ = 6,
+    SZ_RDQ = 7,
+
+    /* the following values are used as is,
+     * and thus hard-coded. changing them 
+     * will break internals 
+     */
+    SZ_B   = 8,
+    SZ_W   = 16,
+    SZ_D   = 32,
+    SZ_Q   = 64,
+    SZ_T   = 80,
+};
+
+/* itab entry operand definitions */
+
+#define O_rSPr12  { OP_rSPr12,   SZ_NA    }
+#define O_BL      { OP_BL,       SZ_NA    }
+#define O_BH      { OP_BH,       SZ_NA    }
+#define O_BP      { OP_BP,       SZ_NA    }
+#define O_AHr12b  { OP_AHr12b,   SZ_NA    }
+#define O_BX      { OP_BX,       SZ_NA    }
+#define O_Jz      { OP_J,        SZ_Z     }
+#define O_Jv      { OP_J,        SZ_V     }
+#define O_Jb      { OP_J,        SZ_B     }
+#define O_rSIr14  { OP_rSIr14,   SZ_NA    }
+#define O_GS      { OP_GS,       SZ_NA    }
+#define O_D       { OP_D,        SZ_NA    }
+#define O_rBPr13  { OP_rBPr13,   SZ_NA    }
+#define O_Ob      { OP_O,        SZ_B     }
+#define O_P       { OP_P,        SZ_NA    }
+#define O_Ow      { OP_O,        SZ_W     }
+#define O_Ov      { OP_O,        SZ_V     }
+#define O_Gw      { OP_G,        SZ_W     }
+#define O_Gv      { OP_G,        SZ_V     }
+#define O_rDX     { OP_rDX,      SZ_NA    }
+#define O_Gx      { OP_G,        SZ_MDQ   }
+#define O_Gd      { OP_G,        SZ_D     }
+#define O_Gb      { OP_G,        SZ_B     }
+#define O_rBXr11  { OP_rBXr11,   SZ_NA    }
+#define O_rDI     { OP_rDI,      SZ_NA    }
+#define O_rSI     { OP_rSI,      SZ_NA    }
+#define O_ALr8b   { OP_ALr8b,    SZ_NA    }
+#define O_eDI     { OP_eDI,      SZ_NA    }
+#define O_Gz      { OP_G,        SZ_Z     }
+#define O_eDX     { OP_eDX,      SZ_NA    }
+#define O_DHr14b  { OP_DHr14b,   SZ_NA    }
+#define O_rSP     { OP_rSP,      SZ_NA    }
+#define O_PR      { OP_PR,       SZ_NA    }
+#define O_NONE    { OP_NONE,     SZ_NA    }
+#define O_rCX     { OP_rCX,      SZ_NA    }
+#define O_jWP     { OP_J,        SZ_WP    }
+#define O_rDXr10  { OP_rDXr10,   SZ_NA    }
+#define O_Md      { OP_M,        SZ_D     }
+#define O_C       { OP_C,        SZ_NA    }
+#define O_G       { OP_G,        SZ_NA    }
+#define O_Mb      { OP_M,        SZ_B     }
+#define O_Mt      { OP_M,        SZ_T     }
+#define O_S       { OP_S,        SZ_NA    }
+#define O_Mq      { OP_M,        SZ_Q     }
+#define O_W       { OP_W,        SZ_NA    }
+#define O_ES      { OP_ES,       SZ_NA    }
+#define O_rBX     { OP_rBX,      SZ_NA    }
+#define O_Ed      { OP_E,        SZ_D     }
+#define O_DLr10b  { OP_DLr10b,   SZ_NA    }
+#define O_Mw      { OP_M,        SZ_W     }
+#define O_Eb      { OP_E,        SZ_B     }
+#define O_Ex      { OP_E,        SZ_MDQ   }
+#define O_Ez      { OP_E,        SZ_Z     }
+#define O_Ew      { OP_E,        SZ_W     }
+#define O_Ev      { OP_E,        SZ_V     }
+#define O_Ep      { OP_E,        SZ_P     }
+#define O_FS      { OP_FS,       SZ_NA    }
+#define O_Ms      { OP_M,        SZ_W     }
+#define O_rAXr8   { OP_rAXr8,    SZ_NA    }
+#define O_eBP     { OP_eBP,      SZ_NA    }
+#define O_Isb     { OP_I,        SZ_SB    }
+#define O_eBX     { OP_eBX,      SZ_NA    }
+#define O_rCXr9   { OP_rCXr9,    SZ_NA    }
+#define O_jDP     { OP_J,        SZ_DP    }
+#define O_CH      { OP_CH,       SZ_NA    }
+#define O_CL      { OP_CL,       SZ_NA    }
+#define O_R       { OP_R,        SZ_RDQ   }
+#define O_V       { OP_V,        SZ_NA    }
+#define O_CS      { OP_CS,       SZ_NA    }
+#define O_CHr13b  { OP_CHr13b,   SZ_NA    }
+#define O_eCX     { OP_eCX,      SZ_NA    }
+#define O_eSP     { OP_eSP,      SZ_NA    }
+#define O_SS      { OP_SS,       SZ_NA    }
+#define O_SP      { OP_SP,       SZ_NA    }
+#define O_BLr11b  { OP_BLr11b,   SZ_NA    }
+#define O_SI      { OP_SI,       SZ_NA    }
+#define O_eSI     { OP_eSI,      SZ_NA    }
+#define O_DL      { OP_DL,       SZ_NA    }
+#define O_DH      { OP_DH,       SZ_NA    }
+#define O_DI      { OP_DI,       SZ_NA    }
+#define O_DX      { OP_DX,       SZ_NA    }
+#define O_rBP     { OP_rBP,      SZ_NA    }
+#define O_Gvw     { OP_G,        SZ_MDQ   }
+#define O_I1      { OP_I1,       SZ_NA    }
+#define O_I3      { OP_I3,       SZ_NA    }
+#define O_DS      { OP_DS,       SZ_NA    }
+#define O_ST4     { OP_ST4,      SZ_NA    }
+#define O_ST5     { OP_ST5,      SZ_NA    }
+#define O_ST6     { OP_ST6,      SZ_NA    }
+#define O_ST7     { OP_ST7,      SZ_NA    }
+#define O_ST0     { OP_ST0,      SZ_NA    }
+#define O_ST1     { OP_ST1,      SZ_NA    }
+#define O_ST2     { OP_ST2,      SZ_NA    }
+#define O_ST3     { OP_ST3,      SZ_NA    }
+#define O_E       { OP_E,        SZ_NA    }
+#define O_AH      { OP_AH,       SZ_NA    }
+#define O_M       { OP_M,        SZ_NA    }
+#define O_AL      { OP_AL,       SZ_NA    }
+#define O_CLr9b   { OP_CLr9b,    SZ_NA    }
+#define O_Q       { OP_Q,        SZ_NA    }
+#define O_eAX     { OP_eAX,      SZ_NA    }
+#define O_VR      { OP_VR,       SZ_NA    }
+#define O_AX      { OP_AX,       SZ_NA    }
+#define O_rAX     { OP_rAX,      SZ_NA    }
+#define O_Iz      { OP_I,        SZ_Z     }
+#define O_rDIr15  { OP_rDIr15,   SZ_NA    }
+#define O_Iw      { OP_I,        SZ_W     }
+#define O_Iv      { OP_I,        SZ_V     }
+#define O_Ap      { OP_A,        SZ_P     }
+#define O_CX      { OP_CX,       SZ_NA    }
+#define O_Ib      { OP_I,        SZ_B     }
+#define O_BHr15b  { OP_BHr15b,   SZ_NA    }
+
+
+/* A single operand of an entry in the instruction table. 
+ * (internal use only)
+ */
+struct ud_itab_entry_operand 
+{
+  enum ud_operand_code type;
+  enum ud_operand_size size;
+};
+
+
+/* A single entry in an instruction table. 
+ *(internal use only)
+ */
+struct ud_itab_entry 
+{
+  enum ud_mnemonic_code         mnemonic;
+  struct ud_itab_entry_operand  operand1;
+  struct ud_itab_entry_operand  operand2;
+  struct ud_itab_entry_operand  operand3;
+  uint32_t                      prefix;
+};
+
+#endif /* UD_DECODE_H */
+
+/* vim:cindent
+ * vim:expandtab
+ * vim:ts=4
+ * vim:sw=4
+ */
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/extern.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,67 @@
+/* -----------------------------------------------------------------------------
+ * extern.h
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_EXTERN_H
+#define UD_EXTERN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #include <stdio.h> */
+#include "types.h"
+
+/* ============================= PUBLIC API ================================= */
+
+extern void ud_init(struct ud*);
+
+extern void ud_set_mode(struct ud*, uint8_t);
+
+extern void ud_set_pc(struct ud*, uint64_t);
+
+extern void ud_set_input_hook(struct ud*, int (*)(struct ud*));
+
+extern void ud_set_input_buffer(struct ud*, uint8_t*, size_t);
+
+#ifndef __UD_STANDALONE__
+extern void ud_set_input_file(struct ud*, FILE*);
+#endif /* __UD_STANDALONE__ */
+
+extern void ud_set_vendor(struct ud*, unsigned);
+
+extern void ud_set_syntax(struct ud*, void (*)(struct ud*));
+
+extern void ud_input_skip(struct ud*, size_t);
+
+extern int ud_input_end(struct ud*);
+
+extern unsigned int ud_decode(struct ud*);
+
+extern unsigned int ud_disassemble(struct ud*);
+
+extern void ud_translate_intel(struct ud*);
+
+extern void ud_translate_att(struct ud*);
+
+extern char* ud_insn_asm(struct ud* u);
+
+extern uint8_t* ud_insn_ptr(struct ud* u);
+
+extern uint64_t ud_insn_off(struct ud*);
+
+extern char* ud_insn_hex(struct ud*);
+
+extern unsigned int ud_insn_len(struct ud* u);
+
+extern const char* ud_lookup_mnemonic(enum ud_mnemonic_code c);
+
+/* ========================================================================== */
+
+#ifdef __cplusplus
+}
+#endif
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/input.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,226 @@
+/* -----------------------------------------------------------------------------
+ * input.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#include "extern.h"
+#include "types.h"
+#include "input.h"
+
+/* -----------------------------------------------------------------------------
+ * inp_buff_hook() - Hook for buffered inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_buff_hook(struct ud* u)
+{
+  if (u->inp_buff < u->inp_buff_end)
+	return *u->inp_buff++;
+  else	return -1;
+}
+
+#ifndef __UD_STANDALONE__
+/* -----------------------------------------------------------------------------
+ * inp_file_hook() - Hook for FILE inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_file_hook(struct ud* u)
+{
+  return fgetc(u->inp_file);
+}
+#endif /* __UD_STANDALONE__*/
+
+/* =============================================================================
+ * ud_inp_set_hook() - Sets input hook.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_hook(register struct ud* u, int (*hook)(struct ud*))
+{
+  u->inp_hook = hook;
+  inp_init(u);
+}
+
+/* =============================================================================
+ * ud_inp_set_buffer() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_buffer(register struct ud* u, uint8_t* buf, size_t len)
+{
+  u->inp_hook = inp_buff_hook;
+  u->inp_buff = buf;
+  u->inp_buff_end = buf + len;
+  inp_init(u);
+}
+
+#ifndef __UD_STANDALONE__
+/* =============================================================================
+ * ud_input_set_file() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_file(register struct ud* u, FILE* f)
+{
+  u->inp_hook = inp_file_hook;
+  u->inp_file = f;
+  inp_init(u);
+}
+#endif /* __UD_STANDALONE__ */
+
+/* =============================================================================
+ * ud_input_skip() - Skip n input bytes.
+ * =============================================================================
+ */
+extern void 
+ud_input_skip(struct ud* u, size_t n)
+{
+  while (n--) {
+	u->inp_hook(u);
+  }
+}
+
+/* =============================================================================
+ * ud_input_end() - Test for end of input.
+ * =============================================================================
+ */
+extern int 
+ud_input_end(struct ud* u)
+{
+  return (u->inp_curr == u->inp_fill) && u->inp_end;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_next() - Loads and returns the next byte from input.
+ *
+ * inp_curr and inp_fill are pointers to the cache. The program is written based
+ * on the property that they are 8-bits in size, and will eventually wrap around
+ * forming a circular buffer. So, the size of the cache is 256 in size, kind of
+ * unnecessary yet optimized.
+ *
+ * A buffer inp_sess stores the bytes disassembled for a single session.
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t inp_next(struct ud* u) 
+{
+  int c = -1;
+  /* if current pointer is not upto the fill point in the 
+   * input cache.
+   */
+  if ( u->inp_curr != u->inp_fill ) {
+	c = u->inp_cache[ ++u->inp_curr ];
+  /* if !end-of-input, call the input hook and get a byte */
+  } else if ( u->inp_end || ( c = u->inp_hook( u ) ) == -1 ) {
+	/* end-of-input, mark it as an error, since the decoder,
+	 * expected a byte more.
+	 */
+	u->error = 1;
+	/* flag end of input */
+	u->inp_end = 1;
+	return 0;
+  } else {
+	/* increment pointers, we have a new byte.  */
+	u->inp_curr = ++u->inp_fill;
+	/* add the byte to the cache */
+	u->inp_cache[ u->inp_fill ] = c;
+  }
+  /* record bytes input per decode-session. */
+  u->inp_sess[ u->inp_ctr++ ] = c;
+  /* return byte */
+  return ( uint8_t ) c;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_back() - Move back a single byte in the stream.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_back(struct ud* u) 
+{
+  if ( u->inp_ctr > 0 ) {
+	--u->inp_curr;
+	--u->inp_ctr;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_peek() - Peek into the next byte in source. 
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t
+inp_peek(struct ud* u) 
+{
+  uint8_t r = inp_next(u);
+  if ( !u->error ) inp_back(u); /* Don't backup if there was an error */
+  return r;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_move() - Move ahead n input bytes.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_move(struct ud* u, size_t n) 
+{
+  while (n--)
+	inp_next(u);
+}
+
+/*------------------------------------------------------------------------------
+ *  inp_uintN() - return uintN from source.
+ *------------------------------------------------------------------------------
+ */
+extern uint8_t 
+inp_uint8(struct ud* u)
+{
+  return inp_next(u);
+}
+
+extern uint16_t 
+inp_uint16(struct ud* u)
+{
+  uint16_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  return ret | (r << 8);
+}
+
+extern uint32_t 
+inp_uint32(struct ud* u)
+{
+  uint32_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  return ret | (r << 24);
+}
+
+extern uint64_t 
+inp_uint64(struct ud* u)
+{
+  uint64_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  ret = ret | (r << 24);
+  r = inp_next(u);
+  ret = ret | (r << 32);
+  r = inp_next(u);
+  ret = ret | (r << 40);
+  r = inp_next(u);
+  ret = ret | (r << 48);
+  r = inp_next(u);
+  return ret | (r << 56);
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/input.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,49 @@
+/* -----------------------------------------------------------------------------
+ * input.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_INPUT_H
+#define UD_INPUT_H
+
+#include "types.h"
+
+uint8_t inp_next(struct ud*);
+uint8_t inp_peek(struct ud*);
+uint8_t inp_uint8(struct ud*);
+uint16_t inp_uint16(struct ud*);
+uint32_t inp_uint32(struct ud*);
+uint64_t inp_uint64(struct ud*);
+void inp_move(struct ud*, size_t);
+void inp_back(struct ud*);
+
+/* inp_init() - Initializes the input system. */
+#define inp_init(u) \
+do { \
+  u->inp_curr = 0; \
+  u->inp_fill = 0; \
+  u->inp_ctr  = 0; \
+  u->inp_end  = 0; \
+} while (0)
+
+/* inp_start() - Should be called before each de-code operation. */
+#define inp_start(u) u->inp_ctr = 0
+
+/* inp_back() - Resets the current pointer to its position before the current
+ * instruction disassembly was started.
+ */
+#define inp_reset(u) \
+do { \
+  u->inp_curr -= u->inp_ctr; \
+  u->inp_ctr = 0; \
+} while (0)
+
+/* inp_sess() - Returns the pointer to current session. */
+#define inp_sess(u) (u->inp_sess)
+
+/* inp_cur() - Returns the current input byte. */
+#define inp_curr(u) ((u)->inp_cache[(u)->inp_curr])
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/itab.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,3668 @@
+
+/* itab.c -- auto generated by opgen.py, do not edit. */
+
+#include "types.h"
+#include "decode.h"
+#include "itab.h"
+
+const char * ud_mnemonics_str[] = {
+  "3dnow",
+  "aaa",
+  "aad",
+  "aam",
+  "aas",
+  "adc",
+  "add",
+  "addpd",
+  "addps",
+  "addsd",
+  "addss",
+  "addsubpd",
+  "addsubps",
+  "and",
+  "andpd",
+  "andps",
+  "andnpd",
+  "andnps",
+  "arpl",
+  "movsxd",
+  "bound",
+  "bsf",
+  "bsr",
+  "bswap",
+  "bt",
+  "btc",
+  "btr",
+  "bts",
+  "call",
+  "cbw",
+  "cwde",
+  "cdqe",
+  "clc",
+  "cld",
+  "clflush",
+  "clgi",
+  "cli",
+  "clts",
+  "cmc",
+  "cmovo",
+  "cmovno",
+  "cmovb",
+  "cmovae",
+  "cmovz",
+  "cmovnz",
+  "cmovbe",
+  "cmova",
+  "cmovs",
+  "cmovns",
+  "cmovp",
+  "cmovnp",
+  "cmovl",
+  "cmovge",
+  "cmovle",
+  "cmovg",
+  "cmp",
+  "cmppd",
+  "cmpps",
+  "cmpsb",
+  "cmpsw",
+  "cmpsd",
+  "cmpsq",
+  "cmpss",
+  "cmpxchg",
+  "cmpxchg8b",
+  "comisd",
+  "comiss",
+  "cpuid",
+  "cvtdq2pd",
+  "cvtdq2ps",
+  "cvtpd2dq",
+  "cvtpd2pi",
+  "cvtpd2ps",
+  "cvtpi2ps",
+  "cvtpi2pd",
+  "cvtps2dq",
+  "cvtps2pi",
+  "cvtps2pd",
+  "cvtsd2si",
+  "cvtsd2ss",
+  "cvtsi2ss",
+  "cvtss2si",
+  "cvtss2sd",
+  "cvttpd2pi",
+  "cvttpd2dq",
+  "cvttps2dq",
+  "cvttps2pi",
+  "cvttsd2si",
+  "cvtsi2sd",
+  "cvttss2si",
+  "cwd",
+  "cdq",
+  "cqo",
+  "daa",
+  "das",
+  "dec",
+  "div",
+  "divpd",
+  "divps",
+  "divsd",
+  "divss",
+  "emms",
+  "enter",
+  "f2xm1",
+  "fabs",
+  "fadd",
+  "faddp",
+  "fbld",
+  "fbstp",
+  "fchs",
+  "fclex",
+  "fcmovb",
+  "fcmove",
+  "fcmovbe",
+  "fcmovu",
+  "fcmovnb",
+  "fcmovne",
+  "fcmovnbe",
+  "fcmovnu",
+  "fucomi",
+  "fcom",
+  "fcom2",
+  "fcomp3",
+  "fcomi",
+  "fucomip",
+  "fcomip",
+  "fcomp",
+  "fcomp5",
+  "fcompp",
+  "fcos",
+  "fdecstp",
+  "fdiv",
+  "fdivp",
+  "fdivr",
+  "fdivrp",
+  "femms",
+  "ffree",
+  "ffreep",
+  "ficom",
+  "ficomp",
+  "fild",
+  "fncstp",
+  "fninit",
+  "fiadd",
+  "fidivr",
+  "fidiv",
+  "fisub",
+  "fisubr",
+  "fist",
+  "fistp",
+  "fisttp",
+  "fld",
+  "fld1",
+  "fldl2t",
+  "fldl2e",
+  "fldlpi",
+  "fldlg2",
+  "fldln2",
+  "fldz",
+  "fldcw",
+  "fldenv",
+  "fmul",
+  "fmulp",
+  "fimul",
+  "fnop",
+  "fpatan",
+  "fprem",
+  "fprem1",
+  "fptan",
+  "frndint",
+  "frstor",
+  "fnsave",
+  "fscale",
+  "fsin",
+  "fsincos",
+  "fsqrt",
+  "fstp",
+  "fstp1",
+  "fstp8",
+  "fstp9",
+  "fst",
+  "fnstcw",
+  "fnstenv",
+  "fnstsw",
+  "fsub",
+  "fsubp",
+  "fsubr",
+  "fsubrp",
+  "ftst",
+  "fucom",
+  "fucomp",
+  "fucompp",
+  "fxam",
+  "fxch",
+  "fxch4",
+  "fxch7",
+  "fxrstor",
+  "fxsave",
+  "fpxtract",
+  "fyl2x",
+  "fyl2xp1",
+  "haddpd",
+  "haddps",
+  "hlt",
+  "hsubpd",
+  "hsubps",
+  "idiv",
+  "in",
+  "imul",
+  "inc",
+  "insb",
+  "insw",
+  "insd",
+  "int1",
+  "int3",
+  "int",
+  "into",
+  "invd",
+  "invlpg",
+  "invlpga",
+  "iretw",
+  "iretd",
+  "iretq",
+  "jo",
+  "jno",
+  "jb",
+  "jae",
+  "jz",
+  "jnz",
+  "jbe",
+  "ja",
+  "js",
+  "jns",
+  "jp",
+  "jnp",
+  "jl",
+  "jge",
+  "jle",
+  "jg",
+  "jcxz",
+  "jecxz",
+  "jrcxz",
+  "jmp",
+  "lahf",
+  "lar",
+  "lddqu",
+  "ldmxcsr",
+  "lds",
+  "lea",
+  "les",
+  "lfs",
+  "lgs",
+  "lidt",
+  "lss",
+  "leave",
+  "lfence",
+  "lgdt",
+  "lldt",
+  "lmsw",
+  "lock",
+  "lodsb",
+  "lodsw",
+  "lodsd",
+  "lodsq",
+  "loopnz",
+  "loope",
+  "loop",
+  "lsl",
+  "ltr",
+  "maskmovq",
+  "maxpd",
+  "maxps",
+  "maxsd",
+  "maxss",
+  "mfence",
+  "minpd",
+  "minps",
+  "minsd",
+  "minss",
+  "monitor",
+  "mov",
+  "movapd",
+  "movaps",
+  "movd",
+  "movddup",
+  "movdqa",
+  "movdqu",
+  "movdq2q",
+  "movhpd",
+  "movhps",
+  "movlhps",
+  "movlpd",
+  "movlps",
+  "movhlps",
+  "movmskpd",
+  "movmskps",
+  "movntdq",
+  "movnti",
+  "movntpd",
+  "movntps",
+  "movntq",
+  "movq",
+  "movqa",
+  "movq2dq",
+  "movsb",
+  "movsw",
+  "movsd",
+  "movsq",
+  "movsldup",
+  "movshdup",
+  "movss",
+  "movsx",
+  "movupd",
+  "movups",
+  "movzx",
+  "mul",
+  "mulpd",
+  "mulps",
+  "mulsd",
+  "mulss",
+  "mwait",
+  "neg",
+  "nop",
+  "not",
+  "or",
+  "orpd",
+  "orps",
+  "out",
+  "outsb",
+  "outsw",
+  "outsd",
+  "outsq",
+  "packsswb",
+  "packssdw",
+  "packuswb",
+  "paddb",
+  "paddw",
+  "paddq",
+  "paddsb",
+  "paddsw",
+  "paddusb",
+  "paddusw",
+  "pand",
+  "pandn",
+  "pause",
+  "pavgb",
+  "pavgw",
+  "pcmpeqb",
+  "pcmpeqw",
+  "pcmpeqd",
+  "pcmpgtb",
+  "pcmpgtw",
+  "pcmpgtd",
+  "pextrw",
+  "pinsrw",
+  "pmaddwd",
+  "pmaxsw",
+  "pmaxub",
+  "pminsw",
+  "pminub",
+  "pmovmskb",
+  "pmulhuw",
+  "pmulhw",
+  "pmullw",
+  "pmuludq",
+  "pop",
+  "popa",
+  "popad",
+  "popfw",
+  "popfd",
+  "popfq",
+  "por",
+  "prefetch",
+  "prefetchnta",
+  "prefetcht0",
+  "prefetcht1",
+  "prefetcht2",
+  "psadbw",
+  "pshufd",
+  "pshufhw",
+  "pshuflw",
+  "pshufw",
+  "pslldq",
+  "psllw",
+  "pslld",
+  "psllq",
+  "psraw",
+  "psrad",
+  "psrlw",
+  "psrld",
+  "psrlq",
+  "psrldq",
+  "psubb",
+  "psubw",
+  "psubd",
+  "psubq",
+  "psubsb",
+  "psubsw",
+  "psubusb",
+  "psubusw",
+  "punpckhbw",
+  "punpckhwd",
+  "punpckhdq",
+  "punpckhqdq",
+  "punpcklbw",
+  "punpcklwd",
+  "punpckldq",
+  "punpcklqdq",
+  "pi2fw",
+  "pi2fd",
+  "pf2iw",
+  "pf2id",
+  "pfnacc",
+  "pfpnacc",
+  "pfcmpge",
+  "pfmin",
+  "pfrcp",
+  "pfrsqrt",
+  "pfsub",
+  "pfadd",
+  "pfcmpgt",
+  "pfmax",
+  "pfrcpit1",
+  "pfrspit1",
+  "pfsubr",
+  "pfacc",
+  "pfcmpeq",
+  "pfmul",
+  "pfrcpit2",
+  "pmulhrw",
+  "pswapd",
+  "pavgusb",
+  "push",
+  "pusha",
+  "pushad",
+  "pushfw",
+  "pushfd",
+  "pushfq",
+  "pxor",
+  "rcl",
+  "rcr",
+  "rol",
+  "ror",
+  "rcpps",
+  "rcpss",
+  "rdmsr",
+  "rdpmc",
+  "rdtsc",
+  "rdtscp",
+  "repne",
+  "rep",
+  "ret",
+  "retf",
+  "rsm",
+  "rsqrtps",
+  "rsqrtss",
+  "sahf",
+  "sal",
+  "salc",
+  "sar",
+  "shl",
+  "shr",
+  "sbb",
+  "scasb",
+  "scasw",
+  "scasd",
+  "scasq",
+  "seto",
+  "setno",
+  "setb",
+  "setnb",
+  "setz",
+  "setnz",
+  "setbe",
+  "seta",
+  "sets",
+  "setns",
+  "setp",
+  "setnp",
+  "setl",
+  "setge",
+  "setle",
+  "setg",
+  "sfence",
+  "sgdt",
+  "shld",
+  "shrd",
+  "shufpd",
+  "shufps",
+  "sidt",
+  "sldt",
+  "smsw",
+  "sqrtps",
+  "sqrtpd",
+  "sqrtsd",
+  "sqrtss",
+  "stc",
+  "std",
+  "stgi",
+  "sti",
+  "skinit",
+  "stmxcsr",
+  "stosb",
+  "stosw",
+  "stosd",
+  "stosq",
+  "str",
+  "sub",
+  "subpd",
+  "subps",
+  "subsd",
+  "subss",
+  "swapgs",
+  "syscall",
+  "sysenter",
+  "sysexit",
+  "sysret",
+  "test",
+  "ucomisd",
+  "ucomiss",
+  "ud2",
+  "unpckhpd",
+  "unpckhps",
+  "unpcklps",
+  "unpcklpd",
+  "verr",
+  "verw",
+  "vmcall",
+  "vmclear",
+  "vmxon",
+  "vmptrld",
+  "vmptrst",
+  "vmresume",
+  "vmxoff",
+  "vmrun",
+  "vmmcall",
+  "vmload",
+  "vmsave",
+  "wait",
+  "wbinvd",
+  "wrmsr",
+  "xadd",
+  "xchg",
+  "xlatb",
+  "xor",
+  "xorpd",
+  "xorps",
+  "db",
+  "invalid",
+};
+
+
+
+static struct ud_itab_entry itab__0f[256] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_00__REG },
+  /* 01 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG },
+  /* 02 */  { UD_Ilar,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ilsl,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Isyscall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iclts,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isysret,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Iinvd,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Iwbinvd,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iud2,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_0D__REG },
+  /* 0E */  { UD_Ifemms,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovups,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovups,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_18__REG },
+  /* 19 */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1D */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1E */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1F */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 20 */  { UD_Imov,         O_R,     O_C,     O_NONE,  P_rexr },
+  /* 21 */  { UD_Imov,         O_R,     O_D,     O_NONE,  P_rexr },
+  /* 22 */  { UD_Imov,         O_C,     O_R,     O_NONE,  P_rexr },
+  /* 23 */  { UD_Imov,         O_D,     O_R,     O_NONE,  P_rexr },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovaps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovaps,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2ps,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntps,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttps2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtps2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomiss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomiss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iwrmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Irdtsc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Irdmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Irdpmc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Isysenter,    O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 35 */  { UD_Isysexit,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Icmovo,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 41 */  { UD_Icmovno,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 42 */  { UD_Icmovb,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 43 */  { UD_Icmovae,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 44 */  { UD_Icmovz,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 45 */  { UD_Icmovnz,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 46 */  { UD_Icmovbe,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 47 */  { UD_Icmova,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 48 */  { UD_Icmovs,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 49 */  { UD_Icmovns,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4A */  { UD_Icmovp,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4B */  { UD_Icmovnp,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4C */  { UD_Icmovl,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4D */  { UD_Icmovge,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4E */  { UD_Icmovle,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4F */  { UD_Icmovg,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 50 */  { UD_Imovmskps,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtps,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iandps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorps,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtps2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtdq2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Imovd,        O_P,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovq,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufw,      O_P,     O_Q,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iemms,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_P,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovq,        O_Q,     O_P,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Ijo,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 81 */  { UD_Ijno,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 82 */  { UD_Ijb,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 83 */  { UD_Ijae,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 84 */  { UD_Ijz,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 85 */  { UD_Ijnz,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 86 */  { UD_Ijbe,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 87 */  { UD_Ija,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 88 */  { UD_Ijs,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 89 */  { UD_Ijns,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8A */  { UD_Ijp,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8B */  { UD_Ijnp,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8C */  { UD_Ijl,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8D */  { UD_Ijge,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8E */  { UD_Ijle,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8F */  { UD_Ijg,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 90 */  { UD_Iseto,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 91 */  { UD_Isetno,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 92 */  { UD_Isetb,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 93 */  { UD_Isetnb,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 94 */  { UD_Isetz,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 95 */  { UD_Isetnz,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 96 */  { UD_Isetbe,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 97 */  { UD_Iseta,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 98 */  { UD_Isets,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 99 */  { UD_Isetns,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9A */  { UD_Isetp,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9B */  { UD_Isetnp,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9C */  { UD_Isetl,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9D */  { UD_Isetge,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9E */  { UD_Isetle,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9F */  { UD_Isetg,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* A0 */  { UD_Ipush,        O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A1 */  { UD_Ipop,         O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A2 */  { UD_Icpuid,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A3 */  { UD_Ibt,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A4 */  { UD_Ishld,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A5 */  { UD_Ishld,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Ipush,        O_GS,    O_NONE,  O_NONE,  P_none },
+  /* A9 */  { UD_Ipop,         O_GS,    O_NONE,  O_NONE,  P_none },
+  /* AA */  { UD_Irsm,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AB */  { UD_Ibts,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AC */  { UD_Ishrd,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AD */  { UD_Ishrd,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG },
+  /* AF */  { UD_Iimul,        O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B0 */  { UD_Icmpxchg,     O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* B1 */  { UD_Icmpxchg,     O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B2 */  { UD_Ilss,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B3 */  { UD_Ibtr,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B4 */  { UD_Ilfs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B5 */  { UD_Ilgs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B6 */  { UD_Imovzx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B7 */  { UD_Imovzx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_BA__REG },
+  /* BB */  { UD_Ibtc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BC */  { UD_Ibsf,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BD */  { UD_Ibsr,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BE */  { UD_Imovsx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BF */  { UD_Imovsx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpps,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Imovnti,      O_M,     O_Gvw,   O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C4 */  { UD_Ipinsrw,      O_P,     O_Ew,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_PR,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C6 */  { UD_Ishufps,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG },
+  /* C8 */  { UD_Ibswap,       O_rAXr8, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* C9 */  { UD_Ibswap,       O_rCXr9, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* CA */  { UD_Ibswap,       O_rDXr10, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CB */  { UD_Ibswap,       O_rBXr11, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CC */  { UD_Ibswap,       O_rSPr12, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CD */  { UD_Ibswap,       O_rBPr13, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CE */  { UD_Ibswap,       O_rSIr14, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CF */  { UD_Ibswap,       O_rDIr15, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Ipsrlw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_PR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipaddusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipaddusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Imovntq,      O_M,     O_P,     O_NONE,  P_none },
+  /* E8 */  { UD_Ipsubsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_00__reg[8] = {
+  /* 00 */  { UD_Isldt,        O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Istr,         O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Illdt,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iltr,         O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iverr,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iverw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg[8] = {
+  /* 00 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD },
+  /* 01 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD },
+  /* 02 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_02__MOD },
+  /* 03 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD },
+  /* 04 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_04__MOD },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod[2] = {
+  /* 00 */  { UD_Isgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmcall,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmresume,    O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxoff,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod[2] = {
+  /* 00 */  { UD_Isidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imonitor,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imwait,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_02__mod[2] = {
+  /* 00 */  { UD_Ilgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod[2] = {
+  /* 00 */  { UD_Ilidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR },
+  /* 06 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor[2] = {
+  /* 00 */  { UD_Ivmrun,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Ivmmcall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor[2] = {
+  /* 00 */  { UD_Ivmload,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Ivmsave,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Istgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor[2] = {
+  /* 00 */  { UD_Iclgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor[2] = {
+  /* 00 */  { UD_Iskinit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvlpga,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_04__mod[2] = {
+  /* 00 */  { UD_Ismsw,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Ilmsw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iinvlpg,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iswapgs,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Irdtscp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_0d__reg[8] = {
+  /* 00 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_18__reg[8] = {
+  /* 00 */  { UD_Iprefetchnta, O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetcht0,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetcht1,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetcht2,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ildmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Istmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iclflush,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ba__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ibt,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ibts,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ibtr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ibtc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Icmpxchg8b,   O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrld,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrst,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Ifabs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_If2xm1,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte[256] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iadd,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadd,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iadd,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iadd,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iadd,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 06 */  { UD_Ipush,        O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 07 */  { UD_Ipop,         O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 08 */  { UD_Ior,          O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 09 */  { UD_Ior,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0A */  { UD_Ior,          O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 0B */  { UD_Ior,          O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0C */  { UD_Ior,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 0D */  { UD_Ior,          O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 0E */  { UD_Ipush,        O_CS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iadc,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Iadc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Iadc,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iadc,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iadc,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 15 */  { UD_Iadc,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 16 */  { UD_Ipush,        O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 17 */  { UD_Ipop,         O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 18 */  { UD_Isbb,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 19 */  { UD_Isbb,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Isbb,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Isbb,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Isbb,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 1D */  { UD_Isbb,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 1E */  { UD_Ipush,        O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 1F */  { UD_Ipop,         O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 20 */  { UD_Iand,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 21 */  { UD_Iand,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 22 */  { UD_Iand,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 23 */  { UD_Iand,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 24 */  { UD_Iand,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 25 */  { UD_Iand,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Idaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 28 */  { UD_Isub,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Isub,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Isub,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Isub,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Isub,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 2D */  { UD_Isub,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Idas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 30 */  { UD_Ixor,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 31 */  { UD_Ixor,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 32 */  { UD_Ixor,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 33 */  { UD_Ixor,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 34 */  { UD_Ixor,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 35 */  { UD_Ixor,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iaaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 38 */  { UD_Icmp,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 39 */  { UD_Icmp,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3A */  { UD_Icmp,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 3B */  { UD_Icmp,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3C */  { UD_Icmp,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 3D */  { UD_Icmp,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iaas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 40 */  { UD_Iinc,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 41 */  { UD_Iinc,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 42 */  { UD_Iinc,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 43 */  { UD_Iinc,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 44 */  { UD_Iinc,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 45 */  { UD_Iinc,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 46 */  { UD_Iinc,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 47 */  { UD_Iinc,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 48 */  { UD_Idec,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 49 */  { UD_Idec,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 4A */  { UD_Idec,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 4B */  { UD_Idec,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 4C */  { UD_Idec,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 4D */  { UD_Idec,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 4E */  { UD_Idec,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 4F */  { UD_Idec,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 50 */  { UD_Ipush,        O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 51 */  { UD_Ipush,        O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 52 */  { UD_Ipush,        O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 53 */  { UD_Ipush,        O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 54 */  { UD_Ipush,        O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 55 */  { UD_Ipush,        O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 56 */  { UD_Ipush,        O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 57 */  { UD_Ipush,        O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 58 */  { UD_Ipop,         O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 59 */  { UD_Ipop,         O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 5A */  { UD_Ipop,         O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5B */  { UD_Ipop,         O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5C */  { UD_Ipop,         O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5D */  { UD_Ipop,         O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5E */  { UD_Ipop,         O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5F */  { UD_Ipop,         O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 60 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_60__OSIZE },
+  /* 61 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_61__OSIZE },
+  /* 62 */  { UD_Ibound,       O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* 63 */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_63__MODE },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Ipush,        O_Iz,    O_NONE,  O_NONE,  P_c1|P_oso },
+  /* 69 */  { UD_Iimul,        O_Gv,    O_Ev,    O_Iz,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipush,        O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* 6B */  { UD_Iimul,        O_Gv,    O_Ev,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinsb,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6D */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6D__OSIZE },
+  /* 6E */  { UD_Ioutsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6F */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6F__OSIZE },
+  /* 70 */  { UD_Ijo,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 71 */  { UD_Ijno,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 72 */  { UD_Ijb,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 73 */  { UD_Ijae,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 74 */  { UD_Ijz,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 75 */  { UD_Ijnz,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 76 */  { UD_Ijbe,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 77 */  { UD_Ija,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Ijs,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 79 */  { UD_Ijns,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7A */  { UD_Ijp,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7B */  { UD_Ijnp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7C */  { UD_Ijl,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7D */  { UD_Ijge,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7E */  { UD_Ijle,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7F */  { UD_Ijg,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 80 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_80__REG },
+  /* 81 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_81__REG },
+  /* 82 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_82__REG },
+  /* 83 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_83__REG },
+  /* 84 */  { UD_Itest,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 85 */  { UD_Itest,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 86 */  { UD_Ixchg,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 87 */  { UD_Ixchg,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 88 */  { UD_Imov,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 89 */  { UD_Imov,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8A */  { UD_Imov,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 8B */  { UD_Imov,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8C */  { UD_Imov,         O_Ev,    O_S,     O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8D */  { UD_Ilea,         O_Gv,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8E */  { UD_Imov,         O_S,     O_Ev,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8F */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_8F__REG },
+  /* 90 */  { UD_Ixchg,        O_rAXr8, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 91 */  { UD_Ixchg,        O_rCXr9, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 92 */  { UD_Ixchg,        O_rDXr10, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 93 */  { UD_Ixchg,        O_rBXr11, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 94 */  { UD_Ixchg,        O_rSPr12, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 95 */  { UD_Ixchg,        O_rBPr13, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 96 */  { UD_Ixchg,        O_rSIr14, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 97 */  { UD_Ixchg,        O_rDIr15, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 98 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_98__OSIZE },
+  /* 99 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_99__OSIZE },
+  /* 9A */  { UD_Icall,        O_Ap,    O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 9B */  { UD_Iwait,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9C */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE },
+  /* 9D */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE },
+  /* 9E */  { UD_Isahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9F */  { UD_Ilahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A0 */  { UD_Imov,         O_AL,    O_Ob,    O_NONE,  P_none },
+  /* A1 */  { UD_Imov,         O_rAX,   O_Ov,    O_NONE,  P_aso|P_oso|P_rexw },
+  /* A2 */  { UD_Imov,         O_Ob,    O_AL,    O_NONE,  P_none },
+  /* A3 */  { UD_Imov,         O_Ov,    O_rAX,   O_NONE,  P_aso|P_oso|P_rexw },
+  /* A4 */  { UD_Imovsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* A5 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A5__OSIZE },
+  /* A6 */  { UD_Icmpsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A7 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A7__OSIZE },
+  /* A8 */  { UD_Itest,        O_AL,    O_Ib,    O_NONE,  P_none },
+  /* A9 */  { UD_Itest,        O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* AA */  { UD_Istosb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AB */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AB__OSIZE },
+  /* AC */  { UD_Ilodsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AD */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AD__OSIZE },
+  /* AE */  { UD_Iscasb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AF__OSIZE },
+  /* B0 */  { UD_Imov,         O_ALr8b, O_Ib,    O_NONE,  P_rexb },
+  /* B1 */  { UD_Imov,         O_CLr9b, O_Ib,    O_NONE,  P_rexb },
+  /* B2 */  { UD_Imov,         O_DLr10b, O_Ib,    O_NONE, P_rexb },
+  /* B3 */  { UD_Imov,         O_BLr11b, O_Ib,    O_NONE, P_rexb },
+  /* B4 */  { UD_Imov,         O_AHr12b, O_Ib,    O_NONE, P_rexb },
+  /* B5 */  { UD_Imov,         O_CHr13b, O_Ib,    O_NONE, P_rexb },
+  /* B6 */  { UD_Imov,         O_DHr14b, O_Ib,    O_NONE, P_rexb },
+  /* B7 */  { UD_Imov,         O_BHr15b, O_Ib,    O_NONE, P_rexb },
+  /* B8 */  { UD_Imov,         O_rAXr8, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* B9 */  { UD_Imov,         O_rCXr9, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* BA */  { UD_Imov,         O_rDXr10, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BB */  { UD_Imov,         O_rBXr11, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BC */  { UD_Imov,         O_rSPr12, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BD */  { UD_Imov,         O_rBPr13, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BE */  { UD_Imov,         O_rSIr14, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BF */  { UD_Imov,         O_rDIr15, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* C0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C0__REG },
+  /* C1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C1__REG },
+  /* C2 */  { UD_Iret,         O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* C3 */  { UD_Iret,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* C4 */  { UD_Iles,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C5 */  { UD_Ilds,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C6__REG },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C7__REG },
+  /* C8 */  { UD_Ienter,       O_Iw,    O_Ib,    O_NONE,  P_def64|P_depM|P_none },
+  /* C9 */  { UD_Ileave,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CA */  { UD_Iretf,        O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* CB */  { UD_Iretf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CC */  { UD_Iint3,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CD */  { UD_Iint,         O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* CE */  { UD_Iinto,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* CF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_CF__OSIZE },
+  /* D0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D0__REG },
+  /* D1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D1__REG },
+  /* D2 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D2__REG },
+  /* D3 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D3__REG },
+  /* D4 */  { UD_Iaam,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D5 */  { UD_Iaad,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D6 */  { UD_Isalc,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D7 */  { UD_Ixlatb,       O_NONE,  O_NONE,  O_NONE,  P_rexw },
+  /* D8 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD },
+  /* D9 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD },
+  /* DA */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD },
+  /* DB */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD },
+  /* DC */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD },
+  /* DD */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD },
+  /* DE */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD },
+  /* DF */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD },
+  /* E0 */  { UD_Iloopnz,      O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E1 */  { UD_Iloope,       O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E2 */  { UD_Iloop,        O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E3 */  { UD_Igrp_asize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_E3__ASIZE },
+  /* E4 */  { UD_Iin,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* E5 */  { UD_Iin,          O_eAX,   O_Ib,    O_NONE,  P_oso },
+  /* E6 */  { UD_Iout,         O_Ib,    O_AL,    O_NONE,  P_none },
+  /* E7 */  { UD_Iout,         O_Ib,    O_eAX,   O_NONE,  P_oso },
+  /* E8 */  { UD_Icall,        O_Jz,    O_NONE,  O_NONE,  P_def64|P_oso },
+  /* E9 */  { UD_Ijmp,         O_Jz,    O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* EA */  { UD_Ijmp,         O_Ap,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* EB */  { UD_Ijmp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* EC */  { UD_Iin,          O_AL,    O_DX,    O_NONE,  P_none },
+  /* ED */  { UD_Iin,          O_eAX,   O_DX,    O_NONE,  P_oso },
+  /* EE */  { UD_Iout,         O_DX,    O_AL,    O_NONE,  P_none },
+  /* EF */  { UD_Iout,         O_DX,    O_eAX,   O_NONE,  P_oso },
+  /* F0 */  { UD_Ilock,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F1 */  { UD_Iint1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F2 */  { UD_Irepne,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F3 */  { UD_Irep,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F4 */  { UD_Ihlt,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F5 */  { UD_Icmc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F6__REG },
+  /* F7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F7__REG },
+  /* F8 */  { UD_Iclc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F9 */  { UD_Istc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FA */  { UD_Icli,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FB */  { UD_Isti,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FC */  { UD_Icld,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FD */  { UD_Istd,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FE__REG },
+  /* FF */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FF__REG },
+};
+
+static struct ud_itab_entry itab__1byte__op_60__osize[3] = {
+  /* 00 */  { UD_Ipusha,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipushad,      O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_61__osize[3] = {
+  /* 00 */  { UD_Ipopa,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipopad,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_63__mode[3] = {
+  /* 00 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 01 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 02 */  { UD_Imovsxd,      O_Gv,    O_Ed,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexx|P_rexr|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_6d__osize[3] = {
+  /* 00 */  { UD_Iinsw,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Iinsd,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_6f__osize[3] = {
+  /* 00 */  { UD_Ioutsw,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Ioutsd,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Ioutsq,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_80__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_81__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_82__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_83__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_8f__reg[8] = {
+  /* 00 */  { UD_Ipop,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_98__osize[3] = {
+  /* 00 */  { UD_Icbw,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icwde,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icdqe,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_99__osize[3] = {
+  /* 00 */  { UD_Icwd,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icdq,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icqo,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipushfq,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipopfq,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_a5__osize[3] = {
+  /* 00 */  { UD_Imovsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Imovsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Imovsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_a7__osize[3] = {
+  /* 00 */  { UD_Icmpsw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icmpsd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icmpsq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ab__osize[3] = {
+  /* 00 */  { UD_Istosw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Istosd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Istosq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ad__osize[3] = {
+  /* 00 */  { UD_Ilodsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Ilodsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Ilodsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AE__MOD__OP_00__REG },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifxsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifxrstor,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_af__osize[3] = {
+  /* 00 */  { UD_Iscasw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iscasd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iscasq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_c0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c6__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_c7__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_cf__osize[3] = {
+  /* 00 */  { UD_Iiretw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iiretd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iiretq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_d0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d2__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d3__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsub,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsub,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsub,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsub,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsub,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsub,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsub,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdiv,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdiv,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdiv,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdiv,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdiv,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdiv,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdiv,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ifst,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifldenv,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifldcw,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifnstenv,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstcw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifld,         O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifld,         O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifld,         O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifld,         O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifld,         O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifld,         O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifld,         O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifld,         O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifnop,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Ifstp1,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp1,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp1,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp1,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp1,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp1,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp1,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp1,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifchs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iftst,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifxam,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifld1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifldl2t,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifldl2e,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifldlpi,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifldlg2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifldln2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifldz,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Ifyl2x,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Ifptan,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Ifpatan,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Ifpxtract,    O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 35 */  { UD_Ifprem1,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Ifdecstp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 37 */  { UD_Ifncstp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 38 */  { UD_Ifprem,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 39 */  { UD_Ifyl2xp1,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3A */  { UD_Ifsqrt,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3B */  { UD_Ifsincos,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3C */  { UD_Ifrndint,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3D */  { UD_Ifscale,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3E */  { UD_Ifsin,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3F */  { UD_Ifcos,        O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovb,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovb,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovb,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovb,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovb,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovb,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovb,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovb,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmove,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmove,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmove,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmove,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmove,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmove,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmove,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmove,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovbe,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovbe,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovbe,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovbe,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovbe,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovbe,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovbe,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovbe,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovu,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovu,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovu,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovu,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovu,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovu,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovu,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovu,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Ifucompp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Ifld,         O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Ifstp,        O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovnb,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovnb,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovnb,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovnb,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovnb,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovnb,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovnb,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovnb,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmovne,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmovne,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmovne,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmovne,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmovne,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmovne,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmovne,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmovne,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovnbe,    O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovnbe,    O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovnbe,    O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovnbe,    O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovnbe,    O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovnbe,    O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovnbe,    O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovnbe,    O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovnu,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovnu,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovnu,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovnu,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovnu,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovnu,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovnu,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovnu,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Ifclex,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifninit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomi,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomi,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomi,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomi,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomi,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomi,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomi,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomi,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomi,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomi,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomi,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomi,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomi,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomi,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomi,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomi,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom2,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom2,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom2,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom2,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom2,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom2,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom2,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom2,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp3,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp3,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp3,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp3,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp3,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp3,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp3,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp3,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsub,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsub,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsub,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsub,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsub,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsub,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsub,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdiv,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdiv,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdiv,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdiv,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdiv,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdiv,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdiv,        O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifst,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifrstor,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ifnsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstsw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffree,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffree,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffree,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffree,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffree,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffree,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffree,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffree,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch4,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch4,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch4,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch4,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch4,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch4,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch4,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch4,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifst,         O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifst,         O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifst,         O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifst,         O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifst,         O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifst,         O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifst,         O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifst,         O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp,        O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp,        O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp,        O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp,        O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp,        O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp,        O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp,        O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp,        O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifucom,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Ifucom,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Ifucom,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifucom,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Ifucom,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifucom,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Ifucom,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 27 */  { UD_Ifucom,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 28 */  { UD_Ifucomp,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomp,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomp,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomp,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomp,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomp,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomp,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomp,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifaddp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifaddp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifaddp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifaddp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifaddp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifaddp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifaddp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifaddp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmulp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmulp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmulp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmulp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmulp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmulp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmulp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmulp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcomp5,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcomp5,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcomp5,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcomp5,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcomp5,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcomp5,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcomp5,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcomp5,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Ifcompp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Ifsubrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifbld,        O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifild,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifbstp,       O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifistp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffreep,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffreep,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffreep,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffreep,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffreep,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffreep,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffreep,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffreep,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch7,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch7,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch7,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch7,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch7,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch7,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch7,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch7,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifstp8,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifstp8,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifstp8,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifstp8,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifstp8,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifstp8,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifstp8,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifstp8,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp9,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp9,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp9,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp9,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp9,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp9,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp9,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp9,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifnstsw,      O_AX,    O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomip,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomip,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomip,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomip,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomip,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomip,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomip,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomip,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomip,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomip,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomip,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomip,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomip,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomip,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomip,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomip,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_e3__asize[3] = {
+  /* 00 */  { UD_Ijcxz,        O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 01 */  { UD_Ijecxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 02 */  { UD_Ijrcxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+};
+
+static struct ud_itab_entry itab__1byte__op_f6__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_f7__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_fe__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ff__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Icall,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Icall,        O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ijmp,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ijmp,         O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ipush,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__3dnow[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 59 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovupd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovupd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovapd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovapd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2pd,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntpd,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttpd2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtpd2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomisd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomisd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Imovmskpd,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iandpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorpd,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtpd2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtps2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Ipunpcklqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6D */  { UD_Ipunpckhqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6E */  { UD_Imovd,        O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovqa,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_V,     O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqa,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmppd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Ipinsrw,      O_V,     O_Ew,    O_Ib,    P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_VR,    O_Ib,    P_aso|P_rexr|P_rexb },
+  /* C6 */  { UD_Ishufpd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Ipsrlw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Imovq,        O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_VR,    O_NONE,  P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Icvttpd2dq,   O_V,     O_W,     O_NONE,  P_none },
+  /* E7 */  { UD_Imovntdq,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E8 */  { UD_Ipsubsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Ipsrldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Ipslldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmclear,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_ssef2__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovsd,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovddup,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2sd,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttsd2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtsd2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtsd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtsd2ss,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Isubsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Ipshuflw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpsd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovdq2q,     O_P,     O_VR,    O_NONE,  P_aso|P_rexb },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtpd2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Ilddqu,       O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovss,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovsldup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Imovshdup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2ss,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttss2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtss2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtss2sd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvttps2dq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Imovdqu,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufhw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovq,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqu,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpss,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovq2dq,     O_V,     O_PR,    O_NONE,  P_aso },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtdq2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxon,       O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+/* the order of this table matches enum ud_itab_index */
+struct ud_itab_entry * ud_itab_list[] = {
+  itab__0f,
+  itab__0f__op_00__reg,
+  itab__0f__op_01__reg,
+  itab__0f__op_01__reg__op_00__mod,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_01__mod,
+  itab__0f__op_01__reg__op_01__mod__op_01__rm,
+  itab__0f__op_01__reg__op_02__mod,
+  itab__0f__op_01__reg__op_03__mod,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor,
+  itab__0f__op_01__reg__op_04__mod,
+  itab__0f__op_01__reg__op_06__mod,
+  itab__0f__op_01__reg__op_07__mod,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_0d__reg,
+  itab__0f__op_18__reg,
+  itab__0f__op_71__reg,
+  itab__0f__op_72__reg,
+  itab__0f__op_73__reg,
+  itab__0f__op_ae__reg,
+  itab__0f__op_ae__reg__op_05__mod,
+  itab__0f__op_ae__reg__op_05__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_06__mod,
+  itab__0f__op_ae__reg__op_06__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_07__mod,
+  itab__0f__op_ae__reg__op_07__mod__op_01__rm,
+  itab__0f__op_ba__reg,
+  itab__0f__op_c7__reg,
+  itab__0f__op_c7__reg__op_00__vendor,
+  itab__0f__op_c7__reg__op_07__vendor,
+  itab__0f__op_d9__mod,
+  itab__0f__op_d9__mod__op_01__x87,
+  itab__1byte,
+  itab__1byte__op_60__osize,
+  itab__1byte__op_61__osize,
+  itab__1byte__op_63__mode,
+  itab__1byte__op_6d__osize,
+  itab__1byte__op_6f__osize,
+  itab__1byte__op_80__reg,
+  itab__1byte__op_81__reg,
+  itab__1byte__op_82__reg,
+  itab__1byte__op_83__reg,
+  itab__1byte__op_8f__reg,
+  itab__1byte__op_98__osize,
+  itab__1byte__op_99__osize,
+  itab__1byte__op_9c__mode,
+  itab__1byte__op_9c__mode__op_00__osize,
+  itab__1byte__op_9c__mode__op_01__osize,
+  itab__1byte__op_9d__mode,
+  itab__1byte__op_9d__mode__op_00__osize,
+  itab__1byte__op_9d__mode__op_01__osize,
+  itab__1byte__op_a5__osize,
+  itab__1byte__op_a7__osize,
+  itab__1byte__op_ab__osize,
+  itab__1byte__op_ad__osize,
+  itab__1byte__op_ae__mod,
+  itab__1byte__op_ae__mod__op_00__reg,
+  itab__1byte__op_af__osize,
+  itab__1byte__op_c0__reg,
+  itab__1byte__op_c1__reg,
+  itab__1byte__op_c6__reg,
+  itab__1byte__op_c7__reg,
+  itab__1byte__op_cf__osize,
+  itab__1byte__op_d0__reg,
+  itab__1byte__op_d1__reg,
+  itab__1byte__op_d2__reg,
+  itab__1byte__op_d3__reg,
+  itab__1byte__op_d8__mod,
+  itab__1byte__op_d8__mod__op_00__reg,
+  itab__1byte__op_d8__mod__op_01__x87,
+  itab__1byte__op_d9__mod,
+  itab__1byte__op_d9__mod__op_00__reg,
+  itab__1byte__op_d9__mod__op_01__x87,
+  itab__1byte__op_da__mod,
+  itab__1byte__op_da__mod__op_00__reg,
+  itab__1byte__op_da__mod__op_01__x87,
+  itab__1byte__op_db__mod,
+  itab__1byte__op_db__mod__op_00__reg,
+  itab__1byte__op_db__mod__op_01__x87,
+  itab__1byte__op_dc__mod,
+  itab__1byte__op_dc__mod__op_00__reg,
+  itab__1byte__op_dc__mod__op_01__x87,
+  itab__1byte__op_dd__mod,
+  itab__1byte__op_dd__mod__op_00__reg,
+  itab__1byte__op_dd__mod__op_01__x87,
+  itab__1byte__op_de__mod,
+  itab__1byte__op_de__mod__op_00__reg,
+  itab__1byte__op_de__mod__op_01__x87,
+  itab__1byte__op_df__mod,
+  itab__1byte__op_df__mod__op_00__reg,
+  itab__1byte__op_df__mod__op_01__x87,
+  itab__1byte__op_e3__asize,
+  itab__1byte__op_f6__reg,
+  itab__1byte__op_f7__reg,
+  itab__1byte__op_fe__reg,
+  itab__1byte__op_ff__reg,
+  itab__3dnow,
+  itab__pfx_sse66__0f,
+  itab__pfx_sse66__0f__op_71__reg,
+  itab__pfx_sse66__0f__op_72__reg,
+  itab__pfx_sse66__0f__op_73__reg,
+  itab__pfx_sse66__0f__op_c7__reg,
+  itab__pfx_sse66__0f__op_c7__reg__op_00__vendor,
+  itab__pfx_ssef2__0f,
+  itab__pfx_ssef3__0f,
+  itab__pfx_ssef3__0f__op_c7__reg,
+  itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor,
+};
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/itab.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,719 @@
+
+/* itab.h -- auto generated by opgen.py, do not edit. */
+
+#ifndef UD_ITAB_H
+#define UD_ITAB_H
+
+
+
+enum ud_itab_vendor_index {
+  ITAB__VENDOR_INDX__AMD,
+  ITAB__VENDOR_INDX__INTEL,
+};
+
+
+enum ud_itab_mode_index {
+  ITAB__MODE_INDX__16,
+  ITAB__MODE_INDX__32,
+  ITAB__MODE_INDX__64
+};
+
+
+enum ud_itab_mod_index {
+  ITAB__MOD_INDX__NOT_11,
+  ITAB__MOD_INDX__11
+};
+
+
+enum ud_itab_index {
+  ITAB__0F,
+  ITAB__0F__OP_00__REG,
+  ITAB__0F__OP_01__REG,
+  ITAB__0F__OP_01__REG__OP_00__MOD,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_01__MOD,
+  ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_02__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR,
+  ITAB__0F__OP_01__REG__OP_04__MOD,
+  ITAB__0F__OP_01__REG__OP_06__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_0D__REG,
+  ITAB__0F__OP_18__REG,
+  ITAB__0F__OP_71__REG,
+  ITAB__0F__OP_72__REG,
+  ITAB__0F__OP_73__REG,
+  ITAB__0F__OP_AE__REG,
+  ITAB__0F__OP_AE__REG__OP_05__MOD,
+  ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_06__MOD,
+  ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_07__MOD,
+  ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_BA__REG,
+  ITAB__0F__OP_C7__REG,
+  ITAB__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__0F__OP_C7__REG__OP_07__VENDOR,
+  ITAB__0F__OP_D9__MOD,
+  ITAB__0F__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE,
+  ITAB__1BYTE__OP_60__OSIZE,
+  ITAB__1BYTE__OP_61__OSIZE,
+  ITAB__1BYTE__OP_63__MODE,
+  ITAB__1BYTE__OP_6D__OSIZE,
+  ITAB__1BYTE__OP_6F__OSIZE,
+  ITAB__1BYTE__OP_80__REG,
+  ITAB__1BYTE__OP_81__REG,
+  ITAB__1BYTE__OP_82__REG,
+  ITAB__1BYTE__OP_83__REG,
+  ITAB__1BYTE__OP_8F__REG,
+  ITAB__1BYTE__OP_98__OSIZE,
+  ITAB__1BYTE__OP_99__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE,
+  ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE,
+  ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_A5__OSIZE,
+  ITAB__1BYTE__OP_A7__OSIZE,
+  ITAB__1BYTE__OP_AB__OSIZE,
+  ITAB__1BYTE__OP_AD__OSIZE,
+  ITAB__1BYTE__OP_AE__MOD,
+  ITAB__1BYTE__OP_AE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_AF__OSIZE,
+  ITAB__1BYTE__OP_C0__REG,
+  ITAB__1BYTE__OP_C1__REG,
+  ITAB__1BYTE__OP_C6__REG,
+  ITAB__1BYTE__OP_C7__REG,
+  ITAB__1BYTE__OP_CF__OSIZE,
+  ITAB__1BYTE__OP_D0__REG,
+  ITAB__1BYTE__OP_D1__REG,
+  ITAB__1BYTE__OP_D2__REG,
+  ITAB__1BYTE__OP_D3__REG,
+  ITAB__1BYTE__OP_D8__MOD,
+  ITAB__1BYTE__OP_D8__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D8__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_D9__MOD,
+  ITAB__1BYTE__OP_D9__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DA__MOD,
+  ITAB__1BYTE__OP_DA__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DA__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DB__MOD,
+  ITAB__1BYTE__OP_DB__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DB__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DC__MOD,
+  ITAB__1BYTE__OP_DC__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DC__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DD__MOD,
+  ITAB__1BYTE__OP_DD__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DD__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DE__MOD,
+  ITAB__1BYTE__OP_DE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DE__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DF__MOD,
+  ITAB__1BYTE__OP_DF__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DF__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_E3__ASIZE,
+  ITAB__1BYTE__OP_F6__REG,
+  ITAB__1BYTE__OP_F7__REG,
+  ITAB__1BYTE__OP_FE__REG,
+  ITAB__1BYTE__OP_FF__REG,
+  ITAB__3DNOW,
+  ITAB__PFX_SSE66__0F,
+  ITAB__PFX_SSE66__0F__OP_71__REG,
+  ITAB__PFX_SSE66__0F__OP_72__REG,
+  ITAB__PFX_SSE66__0F__OP_73__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__PFX_SSEF2__0F,
+  ITAB__PFX_SSEF3__0F,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR,
+};
+
+
+enum ud_mnemonic_code {
+  UD_I3dnow,
+  UD_Iaaa,
+  UD_Iaad,
+  UD_Iaam,
+  UD_Iaas,
+  UD_Iadc,
+  UD_Iadd,
+  UD_Iaddpd,
+  UD_Iaddps,
+  UD_Iaddsd,
+  UD_Iaddss,
+  UD_Iaddsubpd,
+  UD_Iaddsubps,
+  UD_Iand,
+  UD_Iandpd,
+  UD_Iandps,
+  UD_Iandnpd,
+  UD_Iandnps,
+  UD_Iarpl,
+  UD_Imovsxd,
+  UD_Ibound,
+  UD_Ibsf,
+  UD_Ibsr,
+  UD_Ibswap,
+  UD_Ibt,
+  UD_Ibtc,
+  UD_Ibtr,
+  UD_Ibts,
+  UD_Icall,
+  UD_Icbw,
+  UD_Icwde,
+  UD_Icdqe,
+  UD_Iclc,
+  UD_Icld,
+  UD_Iclflush,
+  UD_Iclgi,
+  UD_Icli,
+  UD_Iclts,
+  UD_Icmc,
+  UD_Icmovo,
+  UD_Icmovno,
+  UD_Icmovb,
+  UD_Icmovae,
+  UD_Icmovz,
+  UD_Icmovnz,
+  UD_Icmovbe,
+  UD_Icmova,
+  UD_Icmovs,
+  UD_Icmovns,
+  UD_Icmovp,
+  UD_Icmovnp,
+  UD_Icmovl,
+  UD_Icmovge,
+  UD_Icmovle,
+  UD_Icmovg,
+  UD_Icmp,
+  UD_Icmppd,
+  UD_Icmpps,
+  UD_Icmpsb,
+  UD_Icmpsw,
+  UD_Icmpsd,
+  UD_Icmpsq,
+  UD_Icmpss,
+  UD_Icmpxchg,
+  UD_Icmpxchg8b,
+  UD_Icomisd,
+  UD_Icomiss,
+  UD_Icpuid,
+  UD_Icvtdq2pd,
+  UD_Icvtdq2ps,
+  UD_Icvtpd2dq,
+  UD_Icvtpd2pi,
+  UD_Icvtpd2ps,
+  UD_Icvtpi2ps,
+  UD_Icvtpi2pd,
+  UD_Icvtps2dq,
+  UD_Icvtps2pi,
+  UD_Icvtps2pd,
+  UD_Icvtsd2si,
+  UD_Icvtsd2ss,
+  UD_Icvtsi2ss,
+  UD_Icvtss2si,
+  UD_Icvtss2sd,
+  UD_Icvttpd2pi,
+  UD_Icvttpd2dq,
+  UD_Icvttps2dq,
+  UD_Icvttps2pi,
+  UD_Icvttsd2si,
+  UD_Icvtsi2sd,
+  UD_Icvttss2si,
+  UD_Icwd,
+  UD_Icdq,
+  UD_Icqo,
+  UD_Idaa,
+  UD_Idas,
+  UD_Idec,
+  UD_Idiv,
+  UD_Idivpd,
+  UD_Idivps,
+  UD_Idivsd,
+  UD_Idivss,
+  UD_Iemms,
+  UD_Ienter,
+  UD_If2xm1,
+  UD_Ifabs,
+  UD_Ifadd,
+  UD_Ifaddp,
+  UD_Ifbld,
+  UD_Ifbstp,
+  UD_Ifchs,
+  UD_Ifclex,
+  UD_Ifcmovb,
+  UD_Ifcmove,
+  UD_Ifcmovbe,
+  UD_Ifcmovu,
+  UD_Ifcmovnb,
+  UD_Ifcmovne,
+  UD_Ifcmovnbe,
+  UD_Ifcmovnu,
+  UD_Ifucomi,
+  UD_Ifcom,
+  UD_Ifcom2,
+  UD_Ifcomp3,
+  UD_Ifcomi,
+  UD_Ifucomip,
+  UD_Ifcomip,
+  UD_Ifcomp,
+  UD_Ifcomp5,
+  UD_Ifcompp,
+  UD_Ifcos,
+  UD_Ifdecstp,
+  UD_Ifdiv,
+  UD_Ifdivp,
+  UD_Ifdivr,
+  UD_Ifdivrp,
+  UD_Ifemms,
+  UD_Iffree,
+  UD_Iffreep,
+  UD_Ificom,
+  UD_Ificomp,
+  UD_Ifild,
+  UD_Ifncstp,
+  UD_Ifninit,
+  UD_Ifiadd,
+  UD_Ifidivr,
+  UD_Ifidiv,
+  UD_Ifisub,
+  UD_Ifisubr,
+  UD_Ifist,
+  UD_Ifistp,
+  UD_Ifisttp,
+  UD_Ifld,
+  UD_Ifld1,
+  UD_Ifldl2t,
+  UD_Ifldl2e,
+  UD_Ifldlpi,
+  UD_Ifldlg2,
+  UD_Ifldln2,
+  UD_Ifldz,
+  UD_Ifldcw,
+  UD_Ifldenv,
+  UD_Ifmul,
+  UD_Ifmulp,
+  UD_Ifimul,
+  UD_Ifnop,
+  UD_Ifpatan,
+  UD_Ifprem,
+  UD_Ifprem1,
+  UD_Ifptan,
+  UD_Ifrndint,
+  UD_Ifrstor,
+  UD_Ifnsave,
+  UD_Ifscale,
+  UD_Ifsin,
+  UD_Ifsincos,
+  UD_Ifsqrt,
+  UD_Ifstp,
+  UD_Ifstp1,
+  UD_Ifstp8,
+  UD_Ifstp9,
+  UD_Ifst,
+  UD_Ifnstcw,
+  UD_Ifnstenv,
+  UD_Ifnstsw,
+  UD_Ifsub,
+  UD_Ifsubp,
+  UD_Ifsubr,
+  UD_Ifsubrp,
+  UD_Iftst,
+  UD_Ifucom,
+  UD_Ifucomp,
+  UD_Ifucompp,
+  UD_Ifxam,
+  UD_Ifxch,
+  UD_Ifxch4,
+  UD_Ifxch7,
+  UD_Ifxrstor,
+  UD_Ifxsave,
+  UD_Ifpxtract,
+  UD_Ifyl2x,
+  UD_Ifyl2xp1,
+  UD_Ihaddpd,
+  UD_Ihaddps,
+  UD_Ihlt,
+  UD_Ihsubpd,
+  UD_Ihsubps,
+  UD_Iidiv,
+  UD_Iin,
+  UD_Iimul,
+  UD_Iinc,
+  UD_Iinsb,
+  UD_Iinsw,
+  UD_Iinsd,
+  UD_Iint1,
+  UD_Iint3,
+  UD_Iint,
+  UD_Iinto,
+  UD_Iinvd,
+  UD_Iinvlpg,
+  UD_Iinvlpga,
+  UD_Iiretw,
+  UD_Iiretd,
+  UD_Iiretq,
+  UD_Ijo,
+  UD_Ijno,
+  UD_Ijb,
+  UD_Ijae,
+  UD_Ijz,
+  UD_Ijnz,
+  UD_Ijbe,
+  UD_Ija,
+  UD_Ijs,
+  UD_Ijns,
+  UD_Ijp,
+  UD_Ijnp,
+  UD_Ijl,
+  UD_Ijge,
+  UD_Ijle,
+  UD_Ijg,
+  UD_Ijcxz,
+  UD_Ijecxz,
+  UD_Ijrcxz,
+  UD_Ijmp,
+  UD_Ilahf,
+  UD_Ilar,
+  UD_Ilddqu,
+  UD_Ildmxcsr,
+  UD_Ilds,
+  UD_Ilea,
+  UD_Iles,
+  UD_Ilfs,
+  UD_Ilgs,
+  UD_Ilidt,
+  UD_Ilss,
+  UD_Ileave,
+  UD_Ilfence,
+  UD_Ilgdt,
+  UD_Illdt,
+  UD_Ilmsw,
+  UD_Ilock,
+  UD_Ilodsb,
+  UD_Ilodsw,
+  UD_Ilodsd,
+  UD_Ilodsq,
+  UD_Iloopnz,
+  UD_Iloope,
+  UD_Iloop,
+  UD_Ilsl,
+  UD_Iltr,
+  UD_Imaskmovq,
+  UD_Imaxpd,
+  UD_Imaxps,
+  UD_Imaxsd,
+  UD_Imaxss,
+  UD_Imfence,
+  UD_Iminpd,
+  UD_Iminps,
+  UD_Iminsd,
+  UD_Iminss,
+  UD_Imonitor,
+  UD_Imov,
+  UD_Imovapd,
+  UD_Imovaps,
+  UD_Imovd,
+  UD_Imovddup,
+  UD_Imovdqa,
+  UD_Imovdqu,
+  UD_Imovdq2q,
+  UD_Imovhpd,
+  UD_Imovhps,
+  UD_Imovlhps,
+  UD_Imovlpd,
+  UD_Imovlps,
+  UD_Imovhlps,
+  UD_Imovmskpd,
+  UD_Imovmskps,
+  UD_Imovntdq,
+  UD_Imovnti,
+  UD_Imovntpd,
+  UD_Imovntps,
+  UD_Imovntq,
+  UD_Imovq,
+  UD_Imovqa,
+  UD_Imovq2dq,
+  UD_Imovsb,
+  UD_Imovsw,
+  UD_Imovsd,
+  UD_Imovsq,
+  UD_Imovsldup,
+  UD_Imovshdup,
+  UD_Imovss,
+  UD_Imovsx,
+  UD_Imovupd,
+  UD_Imovups,
+  UD_Imovzx,
+  UD_Imul,
+  UD_Imulpd,
+  UD_Imulps,
+  UD_Imulsd,
+  UD_Imulss,
+  UD_Imwait,
+  UD_Ineg,
+  UD_Inop,
+  UD_Inot,
+  UD_Ior,
+  UD_Iorpd,
+  UD_Iorps,
+  UD_Iout,
+  UD_Ioutsb,
+  UD_Ioutsw,
+  UD_Ioutsd,
+  UD_Ioutsq,
+  UD_Ipacksswb,
+  UD_Ipackssdw,
+  UD_Ipackuswb,
+  UD_Ipaddb,
+  UD_Ipaddw,
+  UD_Ipaddq,
+  UD_Ipaddsb,
+  UD_Ipaddsw,
+  UD_Ipaddusb,
+  UD_Ipaddusw,
+  UD_Ipand,
+  UD_Ipandn,
+  UD_Ipause,
+  UD_Ipavgb,
+  UD_Ipavgw,
+  UD_Ipcmpeqb,
+  UD_Ipcmpeqw,
+  UD_Ipcmpeqd,
+  UD_Ipcmpgtb,
+  UD_Ipcmpgtw,
+  UD_Ipcmpgtd,
+  UD_Ipextrw,
+  UD_Ipinsrw,
+  UD_Ipmaddwd,
+  UD_Ipmaxsw,
+  UD_Ipmaxub,
+  UD_Ipminsw,
+  UD_Ipminub,
+  UD_Ipmovmskb,
+  UD_Ipmulhuw,
+  UD_Ipmulhw,
+  UD_Ipmullw,
+  UD_Ipmuludq,
+  UD_Ipop,
+  UD_Ipopa,
+  UD_Ipopad,
+  UD_Ipopfw,
+  UD_Ipopfd,
+  UD_Ipopfq,
+  UD_Ipor,
+  UD_Iprefetch,
+  UD_Iprefetchnta,
+  UD_Iprefetcht0,
+  UD_Iprefetcht1,
+  UD_Iprefetcht2,
+  UD_Ipsadbw,
+  UD_Ipshufd,
+  UD_Ipshufhw,
+  UD_Ipshuflw,
+  UD_Ipshufw,
+  UD_Ipslldq,
+  UD_Ipsllw,
+  UD_Ipslld,
+  UD_Ipsllq,
+  UD_Ipsraw,
+  UD_Ipsrad,
+  UD_Ipsrlw,
+  UD_Ipsrld,
+  UD_Ipsrlq,
+  UD_Ipsrldq,
+  UD_Ipsubb,
+  UD_Ipsubw,
+  UD_Ipsubd,
+  UD_Ipsubq,
+  UD_Ipsubsb,
+  UD_Ipsubsw,
+  UD_Ipsubusb,
+  UD_Ipsubusw,
+  UD_Ipunpckhbw,
+  UD_Ipunpckhwd,
+  UD_Ipunpckhdq,
+  UD_Ipunpckhqdq,
+  UD_Ipunpcklbw,
+  UD_Ipunpcklwd,
+  UD_Ipunpckldq,
+  UD_Ipunpcklqdq,
+  UD_Ipi2fw,
+  UD_Ipi2fd,
+  UD_Ipf2iw,
+  UD_Ipf2id,
+  UD_Ipfnacc,
+  UD_Ipfpnacc,
+  UD_Ipfcmpge,
+  UD_Ipfmin,
+  UD_Ipfrcp,
+  UD_Ipfrsqrt,
+  UD_Ipfsub,
+  UD_Ipfadd,
+  UD_Ipfcmpgt,
+  UD_Ipfmax,
+  UD_Ipfrcpit1,
+  UD_Ipfrspit1,
+  UD_Ipfsubr,
+  UD_Ipfacc,
+  UD_Ipfcmpeq,
+  UD_Ipfmul,
+  UD_Ipfrcpit2,
+  UD_Ipmulhrw,
+  UD_Ipswapd,
+  UD_Ipavgusb,
+  UD_Ipush,
+  UD_Ipusha,
+  UD_Ipushad,
+  UD_Ipushfw,
+  UD_Ipushfd,
+  UD_Ipushfq,
+  UD_Ipxor,
+  UD_Ircl,
+  UD_Ircr,
+  UD_Irol,
+  UD_Iror,
+  UD_Ircpps,
+  UD_Ircpss,
+  UD_Irdmsr,
+  UD_Irdpmc,
+  UD_Irdtsc,
+  UD_Irdtscp,
+  UD_Irepne,
+  UD_Irep,
+  UD_Iret,
+  UD_Iretf,
+  UD_Irsm,
+  UD_Irsqrtps,
+  UD_Irsqrtss,
+  UD_Isahf,
+  UD_Isal,
+  UD_Isalc,
+  UD_Isar,
+  UD_Ishl,
+  UD_Ishr,
+  UD_Isbb,
+  UD_Iscasb,
+  UD_Iscasw,
+  UD_Iscasd,
+  UD_Iscasq,
+  UD_Iseto,
+  UD_Isetno,
+  UD_Isetb,
+  UD_Isetnb,
+  UD_Isetz,
+  UD_Isetnz,
+  UD_Isetbe,
+  UD_Iseta,
+  UD_Isets,
+  UD_Isetns,
+  UD_Isetp,
+  UD_Isetnp,
+  UD_Isetl,
+  UD_Isetge,
+  UD_Isetle,
+  UD_Isetg,
+  UD_Isfence,
+  UD_Isgdt,
+  UD_Ishld,
+  UD_Ishrd,
+  UD_Ishufpd,
+  UD_Ishufps,
+  UD_Isidt,
+  UD_Isldt,
+  UD_Ismsw,
+  UD_Isqrtps,
+  UD_Isqrtpd,
+  UD_Isqrtsd,
+  UD_Isqrtss,
+  UD_Istc,
+  UD_Istd,
+  UD_Istgi,
+  UD_Isti,
+  UD_Iskinit,
+  UD_Istmxcsr,
+  UD_Istosb,
+  UD_Istosw,
+  UD_Istosd,
+  UD_Istosq,
+  UD_Istr,
+  UD_Isub,
+  UD_Isubpd,
+  UD_Isubps,
+  UD_Isubsd,
+  UD_Isubss,
+  UD_Iswapgs,
+  UD_Isyscall,
+  UD_Isysenter,
+  UD_Isysexit,
+  UD_Isysret,
+  UD_Itest,
+  UD_Iucomisd,
+  UD_Iucomiss,
+  UD_Iud2,
+  UD_Iunpckhpd,
+  UD_Iunpckhps,
+  UD_Iunpcklps,
+  UD_Iunpcklpd,
+  UD_Iverr,
+  UD_Iverw,
+  UD_Ivmcall,
+  UD_Ivmclear,
+  UD_Ivmxon,
+  UD_Ivmptrld,
+  UD_Ivmptrst,
+  UD_Ivmresume,
+  UD_Ivmxoff,
+  UD_Ivmrun,
+  UD_Ivmmcall,
+  UD_Ivmload,
+  UD_Ivmsave,
+  UD_Iwait,
+  UD_Iwbinvd,
+  UD_Iwrmsr,
+  UD_Ixadd,
+  UD_Ixchg,
+  UD_Ixlatb,
+  UD_Ixor,
+  UD_Ixorpd,
+  UD_Ixorps,
+  UD_Idb,
+  UD_Iinvalid,
+  UD_Id3vil,
+  UD_Ina,
+  UD_Igrp_reg,
+  UD_Igrp_rm,
+  UD_Igrp_vendor,
+  UD_Igrp_x87,
+  UD_Igrp_mode,
+  UD_Igrp_osize,
+  UD_Igrp_asize,
+  UD_Igrp_mod,
+  UD_Inone,
+};
+
+
+
+extern const char* ud_mnemonics_str[];;
+extern struct ud_itab_entry* ud_itab_list[];
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/kdb_dis.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include <xen/compile.h>                /* for XEN_SUBVERSION */
+#include "../../include/kdbinc.h"
+#include "extern.h"
+
+static void (*dis_syntax)(ud_t*) = UD_SYN_ATT; /* default dis-assembly syntax */
+
+static struct {                         /* info for kdb_read_byte_for_ud() */
+    kdbva_t kud_instr_addr;
+    domid_t kud_domid;
+} kdb_ud_rd_info;
+
+/* called via function ptr by ud when disassembling. 
+ * kdb info passed via kdb_ud_rd_info{} 
+ */
+static int
+kdb_read_byte_for_ud(struct ud *udp)
+{
+    kdbbyt_t bytebuf;
+    domid_t domid = kdb_ud_rd_info.kud_domid;
+    kdbva_t addr = kdb_ud_rd_info.kud_instr_addr;
+
+    if (kdb_read_mem(addr, &bytebuf, 1, domid) == 1) {
+        kdb_ud_rd_info.kud_instr_addr++;
+        KDBGP1("udrd:addr:%lx domid:%d byt:%x\n", addr, domid, bytebuf);
+        return bytebuf;
+    }
+    KDBGP1("udrd:addr:%lx domid:%d err\n", addr, domid);
+    return UD_EOI;
+}
+
+/* 
+ * given a domid, convert addr to symbol and print it 
+ * Eg: ffff828c801235e2: idle_loop+52                  jmp  idle_loop+55
+ *    Called twice here for idle_loop. In first case, nl is null, 
+ *    in the second case nl == '\n'
+ */
+void
+kdb_prnt_addr2sym(domid_t domid, kdbva_t addr, char *nl)
+{
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1], pbuf[150], prefix[8];
+    char *p = buf;
+
+    prefix[0]='\0';
+    if (domid != DOMID_IDLE) {
+        snprintf(prefix, 8, "%x:", domid);
+        p = kdb_guest_addr2sym(addr, domid, &offs);
+    } else
+        symbols_lookup(addr, &sz, &offs, buf);
+
+    snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
+    if (*nl != '\n')
+        kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
+    else
+        kdbp("%s%s", pbuf, nl);
+
+}
+
+static int
+kdb_jump_instr(enum ud_mnemonic_code mnemonic)
+{
+    return (mnemonic >= UD_Ijo && mnemonic <= UD_Ijmp);
+}
+
+/*
+ * print one instr: function so that we can print offsets of jmp etc.. as
+ *  symbol+offset instead of just address
+ */
+static void
+kdb_print_one_instr(struct ud *udp, domid_t domid)
+{
+    signed long val = 0;
+    ud_type_t type = udp->operand[0].type;
+
+    if ((udp->mnemonic == UD_Icall || kdb_jump_instr(udp->mnemonic)) &&
+        type == UD_OP_JIMM) {
+        
+        int sz = udp->operand[0].size;
+        char *p, ibuf[40], *q = ibuf;
+        kdbva_t addr;
+
+        if (sz == 8) val = udp->operand[0].lval.sbyte;
+        else if (sz == 16) val = udp->operand[0].lval.sword;
+        else if (sz == 32) val = udp->operand[0].lval.sdword;
+        else if (sz == 64) val = udp->operand[0].lval.sqword;
+        else kdbp("kdb_print_one_instr: Inval sz:z%d\n", sz);
+
+        addr = udp->pc + val;
+        for(p=ud_insn_asm(udp); (*q=*p) && *p!=' '; p++,q++);
+        *q='\0';
+        kdbp(" %-4s ", ibuf);    /* space before for long func names */
+        kdb_prnt_addr2sym(domid, addr, "\n");
+    } else
+        kdbp(" %-24s\n", ud_insn_asm(udp));
+#if 0
+    kdbp("mnemonic:z%d ", udp->mnemonic);
+    if (type == UD_OP_CONST) kdbp("type is const\n");
+    else if (type == UD_OP_JIMM) kdbp("type is JIMM\n");
+    else if (type == UD_OP_IMM) kdbp("type is IMM\n");
+    else if (type == UD_OP_PTR) kdbp("type is PTR\n");
+#endif
+}
+
+static void
+kdb_setup_ud(struct ud *udp, kdbva_t addr, domid_t domid)
+{
+    int bitness = kdb_guest_bitness(domid);
+    uint vendor = (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ?
+                                           UD_VENDOR_AMD : UD_VENDOR_INTEL;
+
+    KDBGP1("setup_ud:domid:%d bitness:%d addr:%lx\n", domid, bitness, addr);
+    ud_init(udp);
+    ud_set_mode(udp, kdb_guest_bitness(domid));
+    ud_set_syntax(udp, dis_syntax); 
+    ud_set_vendor(udp, vendor);           /* HVM: vmx/svm different instrs*/
+    ud_set_pc(udp, addr);                 /* for numbers printed on left */
+    ud_set_input_hook(udp, kdb_read_byte_for_ud);
+    kdb_ud_rd_info.kud_instr_addr = addr;
+    kdb_ud_rd_info.kud_domid = domid;
+}
+
+/*
+ * given an addr, print given number of instructions.
+ * Returns: address of next instruction in the stream
+ */
+kdbva_t
+kdb_print_instr(kdbva_t addr, long num, domid_t domid)
+{
+    struct ud ud_s;
+
+    KDBGP1("print_instr:addr:0x%lx num:%ld domid:%x\n", addr, num, domid);
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    while(num--) {
+        if (ud_disassemble(&ud_s)) {
+            uint64_t pc = ud_insn_off(&ud_s);
+            /* kdbp("%08x: ",(int)pc); */
+            kdbp("%016lx: ", pc);
+            kdb_prnt_addr2sym(domid, pc, "");
+            kdb_print_one_instr(&ud_s, domid);
+        } else
+            kdbp("KDB:Couldn't disassemble PC:0x%lx\n", addr);
+            /* for stack reads, don't always display error */
+    }
+    KDBGP1("print_instr:kudaddr:0x%lx\n", kdb_ud_rd_info.kud_instr_addr);
+    return kdb_ud_rd_info.kud_instr_addr;
+}
+
+void
+kdb_display_pc(struct cpu_user_regs *regs)
+{   
+    domid_t domid;
+    struct cpu_user_regs regs1 = *regs;
+    domid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+
+    regs1.KDBIP = regs->KDBIP;
+    kdb_print_instr(regs1.KDBIP, 1, domid);
+}
+
+/* check if the instr at the addr is call instruction
+ * RETURNS: size of the instr if it's a call instr, else 0
+ */
+int
+kdb_check_call_instr(domid_t domid, kdbva_t addr)
+{
+    struct ud ud_s;
+    int sz;
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    if ((sz=ud_disassemble(&ud_s)) && ud_s.mnemonic == UD_Icall)
+        return (sz);
+    return 0;
+}
+
+/* toggle ATT and Intel syntaxes */
+void
+kdb_toggle_dis_syntax(void)
+{
+    if (dis_syntax == UD_SYN_INTEL) {
+        dis_syntax = UD_SYN_ATT;
+        kdbp("dis syntax now set to ATT (Gas)\n");
+    } else {
+        dis_syntax = UD_SYN_INTEL;
+        kdbp("dis syntax now set to Intel (NASM)\n");
+    }
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn-att.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-att.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,211 @@
+/* -----------------------------------------------------------------------------
+ * syn-att.c
+ *
+ * Copyright (c) 2004, 2005, 2006 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case 16 : case 32 :
+		mkasm(u, "*");   break;
+	default: break;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+gen_operand(struct ud* u, struct ud_operand* op)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, "%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM:
+		if (u->br_far) opr_cast(u, op);
+		if (u->pfx_seg)
+			mkasm(u, "%%%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", (-op->lval.sbyte) & 0xff);
+			else	mkasm(u, "0x%x", op->lval.sbyte);
+		} 
+		else if (op->offset == 16) 
+			mkasm(u, "0x%x", op->lval.uword);
+		else if (op->offset == 32) 
+			mkasm(u, "0x%lx", op->lval.udword);
+		else if (op->offset == 64) 
+			mkasm(u, "0x" FMT64 "x", op->lval.uqword);
+
+		if (op->base)
+			mkasm(u, "(%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		if (op->index) {
+			if (op->base)
+				mkasm(u, ",");
+			else mkasm(u, "(");
+			mkasm(u, "%%%s", ud_reg_tab[op->index - UD_R_AL]);
+		}
+		if (op->scale)
+			mkasm(u, ",%d", op->scale);
+		if (op->base || op->index)
+			mkasm(u, ")");
+		break;
+
+	case UD_OP_IMM:
+		switch (op->size) {
+			case  8: mkasm(u, "$0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "$0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "$0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "$0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "$0x%x, $0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "$0x%x, $0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+			
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to AT&T syntax 
+ * =============================================================================
+ */
+extern void 
+ud_translate_att(struct ud *u)
+{
+  int size = 0;
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+  	mkasm(u,  "lock ");
+  if (u->pfx_rep)
+	mkasm(u,  "rep ");
+  if (u->pfx_repne)
+		mkasm(u,  "repne ");
+
+  /* special instructions */
+  switch (u->mnemonic) {
+	case UD_Iretf: 
+		mkasm(u, "lret "); 
+		break;
+	case UD_Idb:
+		mkasm(u, ".byte 0x%x", u->operand[0].lval.ubyte);
+		return;
+	case UD_Ijmp:
+	case UD_Icall:
+		if (u->br_far) mkasm(u,  "l");
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+		break;
+	case UD_Ibound:
+	case UD_Ienter:
+		if (u->operand[0].type != UD_NONE)
+			gen_operand(u, &u->operand[0]);
+		if (u->operand[1].type != UD_NONE) {
+			mkasm(u, ",");
+			gen_operand(u, &u->operand[1]);
+		}
+		return;
+	default:
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+  }
+
+  if (u->c1)
+	size = u->operand[0].size;
+  else if (u->c2)
+	size = u->operand[1].size;
+  else if (u->c3)
+	size = u->operand[2].size;
+
+  if (size == 8)
+	mkasm(u, "b");
+  else if (size == 16)
+	mkasm(u, "w");
+  else if (size == 64)
+ 	mkasm(u, "q");
+
+  mkasm(u, " ");
+
+  if (u->operand[2].type != UD_NONE) {
+	gen_operand(u, &u->operand[2]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[1].type != UD_NONE) {
+	gen_operand(u, &u->operand[1]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[0].type != UD_NONE)
+	gen_operand(u, &u->operand[0]);
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn-intel.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-intel.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,208 @@
+/* -----------------------------------------------------------------------------
+ * syn-intel.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case  8: mkasm(u, "byte " ); break;
+	case 16: mkasm(u, "word " ); break;
+	case 32: mkasm(u, "dword "); break;
+	case 64: mkasm(u, "qword "); break;
+	case 80: mkasm(u, "tword "); break;
+	default: break;
+  }
+  if (u->br_far)
+	mkasm(u, "far "); 
+  else if (u->br_near)
+	mkasm(u, "near ");
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void gen_operand(struct ud* u, struct ud_operand* op, int syn_cast)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM: {
+
+		int op_f = 0;
+
+		if (syn_cast) 
+			opr_cast(u, op);
+
+		mkasm(u, "[");
+
+		if (u->pfx_seg)
+			mkasm(u, "%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+		if (op->base) {
+			mkasm(u, "%s", ud_reg_tab[op->base - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->index) {
+			if (op_f)
+				mkasm(u, "+");
+			mkasm(u, "%s", ud_reg_tab[op->index - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->scale)
+			mkasm(u, "*%d", op->scale);
+
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", -op->lval.sbyte);
+			else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sbyte);
+		}
+		else if (op->offset == 16)
+			mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.uword);
+		else if (op->offset == 32) {
+			if (u->adr_mode == 64) {
+				if (op->lval.sdword < 0)
+					mkasm(u, "-0x%x", -op->lval.sdword);
+				else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sdword);
+			} 
+			else	mkasm(u, "%s0x%lx", (op_f) ? "+" : "", op->lval.udword);
+		}
+		else if (op->offset == 64) 
+			mkasm(u, "%s0x" FMT64 "x", (op_f) ? "+" : "", op->lval.uqword);
+
+		mkasm(u, "]");
+		break;
+	}
+			
+	case UD_OP_IMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8: mkasm(u, "0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "word 0x%x:0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "dword 0x%x:0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+
+	case UD_OP_CONST:
+		if (syn_cast) opr_cast(u, op);
+		mkasm(u, "%d", op->lval.udword);
+		break;
+
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to intel syntax 
+ * =============================================================================
+ */
+extern void ud_translate_intel(struct ud* u)
+{
+  /* -- prefixes -- */
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+	mkasm(u, "lock ");
+  if (u->pfx_rep)
+	mkasm(u, "rep ");
+  if (u->pfx_repne)
+	mkasm(u, "repne ");
+  if (u->implicit_addr && u->pfx_seg)
+	mkasm(u, "%s ", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+  /* print the instruction mnemonic */
+  mkasm(u, "%s ", ud_lookup_mnemonic(u->mnemonic));
+
+  /* operand 1 */
+  if (u->operand[0].type != UD_NONE) {
+	gen_operand(u, &u->operand[0], u->c1);
+  }
+  /* operand 2 */
+  if (u->operand[1].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[1], u->c2);
+  }
+
+  /* operand 3 */
+  if (u->operand[2].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[2], u->c3);
+  }
+}
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,61 @@
+/* -----------------------------------------------------------------------------
+ * syn.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+/* -----------------------------------------------------------------------------
+ * Intel Register Table - Order Matters (types.h)!
+ * -----------------------------------------------------------------------------
+ */
+const char* ud_reg_tab[] = 
+{
+  "al",		"cl",		"dl",		"bl",
+  "ah",		"ch",		"dh",		"bh",
+  "spl",	"bpl",		"sil",		"dil",
+  "r8b",	"r9b",		"r10b",		"r11b",
+  "r12b",	"r13b",		"r14b",		"r15b",
+
+  "ax",		"cx",		"dx",		"bx",
+  "sp",		"bp",		"si",		"di",
+  "r8w",	"r9w",		"r10w",		"r11w",
+  "r12w",	"r13W"	,	"r14w",		"r15w",
+	
+  "eax",	"ecx",		"edx",		"ebx",
+  "esp",	"ebp",		"esi",		"edi",
+  "r8d",	"r9d",		"r10d",		"r11d",
+  "r12d",	"r13d",		"r14d",		"r15d",
+	
+  "rax",	"rcx",		"rdx",		"rbx",
+  "rsp",	"rbp",		"rsi",		"rdi",
+  "r8",		"r9",		"r10",		"r11",
+  "r12",	"r13",		"r14",		"r15",
+
+  "es",		"cs",		"ss",		"ds",
+  "fs",		"gs",	
+
+  "cr0",	"cr1",		"cr2",		"cr3",
+  "cr4",	"cr5",		"cr6",		"cr7",
+  "cr8",	"cr9",		"cr10",		"cr11",
+  "cr12",	"cr13",		"cr14",		"cr15",
+	
+  "dr0",	"dr1",		"dr2",		"dr3",
+  "dr4",	"dr5",		"dr6",		"dr7",
+  "dr8",	"dr9",		"dr10",		"dr11",
+  "dr12",	"dr13",		"dr14",		"dr15",
+
+  "mm0",	"mm1",		"mm2",		"mm3",
+  "mm4",	"mm5",		"mm6",		"mm7",
+
+  "st0",	"st1",		"st2",		"st3",
+  "st4",	"st5",		"st6",		"st7", 
+
+  "xmm0",	"xmm1",		"xmm2",		"xmm3",
+  "xmm4",	"xmm5",		"xmm6",		"xmm7",
+  "xmm8",	"xmm9",		"xmm10",	"xmm11",
+  "xmm12",	"xmm13",	"xmm14",	"xmm15",
+
+  "rip"
+};
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/syn.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,27 @@
+/* -----------------------------------------------------------------------------
+ * syn.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_SYN_H
+#define UD_SYN_H
+
+#if 0
+#include <stdio.h>
+#include <stdarg.h>
+#endif
+#include "types.h"
+
+extern const char* ud_reg_tab[];
+
+static void mkasm(struct ud* u, const char* fmt, ...)
+{
+  va_list ap;
+  va_start(ap, fmt);
+  u->insn_fill += vsnprintf((char*) u->insn_buffer + u->insn_fill, 64, fmt, ap);
+  va_end(ap);
+}
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/types.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/types.h	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,186 @@
+/* -----------------------------------------------------------------------------
+ * types.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_TYPES_H
+#define UD_TYPES_H
+
+
+#include "../../include/kdbinc.h"
+
+#define FMT64 "%ll"
+#include "itab.h"
+
+/* -----------------------------------------------------------------------------
+ * All possible "types" of objects in udis86. Order is Important!
+ * -----------------------------------------------------------------------------
+ */
+enum ud_type
+{
+  UD_NONE,
+
+  /* 8 bit GPRs */
+  UD_R_AL,	UD_R_CL,	UD_R_DL,	UD_R_BL,
+  UD_R_AH,	UD_R_CH,	UD_R_DH,	UD_R_BH,
+  UD_R_SPL,	UD_R_BPL,	UD_R_SIL,	UD_R_DIL,
+  UD_R_R8B,	UD_R_R9B,	UD_R_R10B,	UD_R_R11B,
+  UD_R_R12B,	UD_R_R13B,	UD_R_R14B,	UD_R_R15B,
+
+  /* 16 bit GPRs */
+  UD_R_AX,	UD_R_CX,	UD_R_DX,	UD_R_BX,
+  UD_R_SP,	UD_R_BP,	UD_R_SI,	UD_R_DI,
+  UD_R_R8W,	UD_R_R9W,	UD_R_R10W,	UD_R_R11W,
+  UD_R_R12W,	UD_R_R13W,	UD_R_R14W,	UD_R_R15W,
+	
+  /* 32 bit GPRs */
+  UD_R_EAX,	UD_R_ECX,	UD_R_EDX,	UD_R_EBX,
+  UD_R_ESP,	UD_R_EBP,	UD_R_ESI,	UD_R_EDI,
+  UD_R_R8D,	UD_R_R9D,	UD_R_R10D,	UD_R_R11D,
+  UD_R_R12D,	UD_R_R13D,	UD_R_R14D,	UD_R_R15D,
+	
+  /* 64 bit GPRs */
+  UD_R_RAX,	UD_R_RCX,	UD_R_RDX,	UD_R_RBX,
+  UD_R_RSP,	UD_R_RBP,	UD_R_RSI,	UD_R_RDI,
+  UD_R_R8,	UD_R_R9,	UD_R_R10,	UD_R_R11,
+  UD_R_R12,	UD_R_R13,	UD_R_R14,	UD_R_R15,
+
+  /* segment registers */
+  UD_R_ES,	UD_R_CS,	UD_R_SS,	UD_R_DS,
+  UD_R_FS,	UD_R_GS,	
+
+  /* control registers*/
+  UD_R_CR0,	UD_R_CR1,	UD_R_CR2,	UD_R_CR3,
+  UD_R_CR4,	UD_R_CR5,	UD_R_CR6,	UD_R_CR7,
+  UD_R_CR8,	UD_R_CR9,	UD_R_CR10,	UD_R_CR11,
+  UD_R_CR12,	UD_R_CR13,	UD_R_CR14,	UD_R_CR15,
+	
+  /* debug registers */
+  UD_R_DR0,	UD_R_DR1,	UD_R_DR2,	UD_R_DR3,
+  UD_R_DR4,	UD_R_DR5,	UD_R_DR6,	UD_R_DR7,
+  UD_R_DR8,	UD_R_DR9,	UD_R_DR10,	UD_R_DR11,
+  UD_R_DR12,	UD_R_DR13,	UD_R_DR14,	UD_R_DR15,
+
+  /* mmx registers */
+  UD_R_MM0,	UD_R_MM1,	UD_R_MM2,	UD_R_MM3,
+  UD_R_MM4,	UD_R_MM5,	UD_R_MM6,	UD_R_MM7,
+
+  /* x87 registers */
+  UD_R_ST0,	UD_R_ST1,	UD_R_ST2,	UD_R_ST3,
+  UD_R_ST4,	UD_R_ST5,	UD_R_ST6,	UD_R_ST7, 
+
+  /* extended multimedia registers */
+  UD_R_XMM0,	UD_R_XMM1,	UD_R_XMM2,	UD_R_XMM3,
+  UD_R_XMM4,	UD_R_XMM5,	UD_R_XMM6,	UD_R_XMM7,
+  UD_R_XMM8,	UD_R_XMM9,	UD_R_XMM10,	UD_R_XMM11,
+  UD_R_XMM12,	UD_R_XMM13,	UD_R_XMM14,	UD_R_XMM15,
+
+  UD_R_RIP,
+
+  /* Operand Types */
+  UD_OP_REG,	UD_OP_MEM,	UD_OP_PTR,	UD_OP_IMM,	
+  UD_OP_JIMM,	UD_OP_CONST
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud_operand - Disassembled instruction Operand.
+ * -----------------------------------------------------------------------------
+ */
+struct ud_operand 
+{
+  enum ud_type		type;
+  uint8_t		size;
+  union {
+	int8_t		sbyte;
+	uint8_t		ubyte;
+	int16_t		sword;
+	uint16_t	uword;
+	int32_t		sdword;
+	uint32_t	udword;
+	int64_t		sqword;
+	uint64_t	uqword;
+
+	struct {
+		uint16_t seg;
+		uint32_t off;
+	} ptr;
+  } lval;
+
+  enum ud_type		base;
+  enum ud_type		index;
+  uint8_t		offset;
+  uint8_t		scale;	
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud - The udis86 object.
+ * -----------------------------------------------------------------------------
+ */
+struct ud
+{
+  int 			(*inp_hook) (struct ud*);
+  uint8_t		inp_curr;
+  uint8_t		inp_fill;
+  uint8_t		inp_ctr;
+  uint8_t*		inp_buff;
+  uint8_t*		inp_buff_end;
+  uint8_t		inp_end;
+  void			(*translator)(struct ud*);
+  uint64_t		insn_offset;
+  char			insn_hexcode[32];
+  char			insn_buffer[64];
+  unsigned int		insn_fill;
+  uint8_t		dis_mode;
+  uint64_t		pc;
+  uint8_t		vendor;
+  struct map_entry*	mapen;
+  enum ud_mnemonic_code	mnemonic;
+  struct ud_operand	operand[3];
+  uint8_t		error;
+  uint8_t	 	pfx_rex;
+  uint8_t 		pfx_seg;
+  uint8_t 		pfx_opr;
+  uint8_t 		pfx_adr;
+  uint8_t 		pfx_lock;
+  uint8_t 		pfx_rep;
+  uint8_t 		pfx_repe;
+  uint8_t 		pfx_repne;
+  uint8_t 		pfx_insn;
+  uint8_t		default64;
+  uint8_t		opr_mode;
+  uint8_t		adr_mode;
+  uint8_t		br_far;
+  uint8_t		br_near;
+  uint8_t		implicit_addr;
+  uint8_t		c1;
+  uint8_t		c2;
+  uint8_t		c3;
+  uint8_t 		inp_cache[256];
+  uint8_t		inp_sess[64];
+  struct ud_itab_entry * itab_entry;
+};
+
+/* -----------------------------------------------------------------------------
+ * Type-definitions
+ * -----------------------------------------------------------------------------
+ */
+typedef enum ud_type 		ud_type_t;
+typedef enum ud_mnemonic_code	ud_mnemonic_code_t;
+
+typedef struct ud 		ud_t;
+typedef struct ud_operand 	ud_operand_t;
+
+#define UD_SYN_INTEL		ud_translate_intel
+#define UD_SYN_ATT		ud_translate_att
+#define UD_EOI			-1
+#define UD_INP_CACHE_SZ		32
+#define UD_VENDOR_AMD		0
+#define UD_VENDOR_INTEL		1
+
+#define bail_out(ud,error_code) longjmp( (ud)->bailout, error_code )
+#define try_decode(ud) if ( setjmp( (ud)->bailout ) == 0 )
+#define catch_error() else
+
+#endif
diff -r 54c8c9eaee92 xen/kdb/x86/udis86-1.7/udis86.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/udis86.c	Wed Jun 06 14:17:11 2012 -0700
@@ -0,0 +1,156 @@
+/* -----------------------------------------------------------------------------
+ * udis86.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#endif
+
+#include "input.h"
+#include "extern.h"
+
+/* =============================================================================
+ * ud_init() - Initializes ud_t object.
+ * =============================================================================
+ */
+extern void 
+ud_init(struct ud* u)
+{
+  memset((void*)u, 0, sizeof(struct ud));
+  ud_set_mode(u, 16);
+  u->mnemonic = UD_Iinvalid;
+  ud_set_pc(u, 0);
+#ifndef __UD_STANDALONE__
+  ud_set_input_file(u, stdin);
+#endif /* __UD_STANDALONE__ */
+}
+
+/* =============================================================================
+ * ud_disassemble() - disassembles one instruction and returns the number of 
+ * bytes disassembled. A zero means end of disassembly.
+ * =============================================================================
+ */
+extern unsigned int
+ud_disassemble(struct ud* u)
+{
+  if (ud_input_end(u))
+	return 0;
+
+ 
+  u->insn_buffer[0] = u->insn_hexcode[0] = 0;
+
+ 
+  if (ud_decode(u) == 0)
+	return 0;
+  if (u->translator)
+	u->translator(u);
+  return ud_insn_len(u);
+}
+
+/* =============================================================================
+ * ud_set_mode() - Set Disassemly Mode.
+ * =============================================================================
+ */
+extern void 
+ud_set_mode(struct ud* u, uint8_t m)
+{
+  switch(m) {
+	case 16:
+	case 32:
+	case 64: u->dis_mode = m ; return;
+	default: u->dis_mode = 16; return;
+  }
+}
+
+/* =============================================================================
+ * ud_set_vendor() - Set vendor.
+ * =============================================================================
+ */
+extern void 
+ud_set_vendor(struct ud* u, unsigned v)
+{
+  switch(v) {
+	case UD_VENDOR_INTEL:
+		u->vendor = v;
+		break;
+	default:
+		u->vendor = UD_VENDOR_AMD;
+  }
+}
+
+/* =============================================================================
+ * ud_set_pc() - Sets code origin. 
+ * =============================================================================
+ */
+extern void 
+ud_set_pc(struct ud* u, uint64_t o)
+{
+  u->pc = o;
+}
+
+/* =============================================================================
+ * ud_set_syntax() - Sets the output syntax.
+ * =============================================================================
+ */
+extern void 
+ud_set_syntax(struct ud* u, void (*t)(struct ud*))
+{
+  u->translator = t;
+}
+
+/* =============================================================================
+ * ud_insn() - returns the disassembled instruction
+ * =============================================================================
+ */
+extern char* 
+ud_insn_asm(struct ud* u) 
+{
+  return u->insn_buffer;
+}
+
+/* =============================================================================
+ * ud_insn_offset() - Returns the offset.
+ * =============================================================================
+ */
+extern uint64_t
+ud_insn_off(struct ud* u) 
+{
+  return u->insn_offset;
+}
+
+
+/* =============================================================================
+ * ud_insn_hex() - Returns hex form of disassembled instruction.
+ * =============================================================================
+ */
+extern char* 
+ud_insn_hex(struct ud* u) 
+{
+  return u->insn_hexcode;
+}
+
+/* =============================================================================
+ * ud_insn_ptr() - Returns code disassembled.
+ * =============================================================================
+ */
+extern uint8_t* 
+ud_insn_ptr(struct ud* u) 
+{
+  return u->inp_sess;
+}
+
+/* =============================================================================
+ * ud_insn_len() - Returns the count of bytes disassembled.
+ * =============================================================================
+ */
+extern unsigned int 
+ud_insn_len(struct ud* u) 
+{
+  return u->inp_ctr;
+}

--MP_/61SL/dFgoelVIa2N/5RWWnn
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--MP_/61SL/dFgoelVIa2N/5RWWnn--


From xen-devel-bounces@lists.xen.org Thu Jun 07 09:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ9J-0007NO-FL; Thu, 07 Jun 2012 09:37:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1ScZ9H-0007Mt-Nb
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:37:00 +0000
Received: from [193.109.254.147:63979] by server-6.bemta-14.messagelabs.com id
	A1/AC-02426-A3670DF4; Thu, 07 Jun 2012 09:36:58 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339061818!1682602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21612 invoked from network); 7 Jun 2012 09:36:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12876460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 09:36:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 10:36:58 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1ScZ9F-0007Ci-J9;
	Thu, 07 Jun 2012 09:36:57 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1ScZEX-0003xR-Jd;
	Thu, 07 Jun 2012 10:42:25 +0100
Date: Thu, 7 Jun 2012 10:42:25 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607094225.GB15139@spongy.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338558477.17466.121.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][PATCH 0/5] Add V4V to 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 01/06 02:47, Ian Campbell wrote:
> On Thu, 2012-05-31 at 16:07 +0100, Jean Guyader wrote:
> > V4V is a copy based inter vm communication system.
> > 
> > Please have a look at this thread for more detail
> > about V4V.
> > http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html
> > 
> > This patch series is work in progress but I wanted to
> > post it early enough so I can get feedback from people.
> 
> The main thing which is missing here, which makes it rather hard to
> review, is any kind of design documentation. It would also be great to
> see the rationale for why things have to be done this way.
> 
> For example it seems that there is a bunch of stuff being added to the
> hypervisor which could live in the context of some guest or service
> domain -- putting stuff like that in the hypervisor needs strong
> arguments and rationale why it has to be there rather than somewhere
> else.
> 
> Likewise perhaps the v4v hypercall could effectively be implemented with
> a multicall containing some grant copy ops and evtchn manipulations?
> 
> But in the absence of any descriptions of the whats, hows and whys of
> v4v its rather hard to have these sorts of conversations. The above are
> some concrete examples but I'm more interested in seeing the more
> general descriptions before we get into those.
> 
> Ian.
> 
> 

(resent, sorry if you get this message twice)

* Overview
** Architecture

v4v has a very simple architecture. The receiving domain registers a ring with xen. 
The sending domain requests that xen inserts data into the receiving domain's ring.
Notification that there is new data to read is delivered by a VIRQ, and a domain can
request an interrupt be generated when sufficient space is available in another domain's
ring. The code that inserts the data into the ring is in xen, and xen writes a header
describing the data and where it came from infront of the data. As both the ring manipulation
and the header are written by the hypervisor, the receiving domain can trust their content
and the format of the ring. 

** Addressing
v4v_addr_t identifies an endpoint address.
 typedef struct v4v_addr
 {
     uint32_t port;
     domid_t domain;
 } v4v_addr_t;
struct v4v_ring_id uniquely identifies a ring on the platform.

 struct v4v_ring_id
 {
    struct v4v_addr addr;
    domid_t partner;
 };

When a send operation is performed, xen will attempt to find a ring 
registered by destination domain, with the required port, and with
a partner of the sending domain. Failing that it will then search
for a ring with the correct port and destination domain, but with 
partner set to V4V_DOMID_ANY.

** Setup
A domain first generates a ring, and a structure describing the pages in the ring.
Rings must be page aligned, and contiguous in virtual memory, but need not be 
contiguous in physical(pfn) or machine(mfn) memory. A ring is uniquely identified
on the platform by its struct v4v_ring_id.

A ring is contained in a v4v_ring_t
 typedef struct v4v_ring
 {
    uint64_t magic;
    /*
     * Identifies ring_id - xen only looks at this during register/unregister
     * and will fill in id.addr.domain
     */
    struct v4v_ring_id id;
    /* length of ring[], must be a multiple of 16 */
    uint32_t len;
    /* rx_ptr - modified by domain */
    uint32_t rx_ptr;
    /* tx_ptr - modified by xen */
    volatile uint32_t tx_ptr;
    uint64_t reserved[4];
    volatile uint8_t ring[0];
 } v4v_ring_t;

To register the ring, xen also needs a list of pfn that the ring occupies.
This is provided in a v4v_pfn_list_t
 typedef struct v4v_pfn_list_t
 {
    uint64_t magic;
    uint32_t npage;
    uint32_t pad;
    uint64_t reserved[3];
    v4v_pfn_t pages[0];
 } v4v_pfn_list_t;

Registering the ring is done with a hypercall

int hypercall(NR_V4V,V4VOP_register_ring,v4v_ring_t *ring,v4v_pfn_list_t *pfn_list);

On registering, xen will check that the tx_ptr and rx_ptr values are valid (aligned
and within the size of the ring) and modify them if they are not, it will also update
id.addr.domain with the calling domain's domid and take an internal copy of all the
relevant information. After registration the only field that xen will read is
ring->rx_ptr, xen will write to ring->ring[] and ring->tx_ptr. 
Thus pfn_list can be freed after the registration call. Critically, registration is
idempotent, and all a domain need do after hibernation or migration is re-register all
its rings. (NB the id.addr.domain field may change).

** Sending

To send data a guest merely calls the send or sendv hypercall
int hypercall(NR_V4V,V4VOP_send,v4v_addr_t *src,v4v_addr_t *dst,void *buf, uint32_t len,
              uint32_t protocol);

the caller provides a source address, a destination address, a buffer, a number of bytes to copy
and a 32 bit protocol number. Xen ignores src->domain and instead uses the domain id of the caller.

Xen will attempt to insert into a ring with id.addr equal to dst, and with
id.partner equal to the caller's domid. Otherwise it will insert into a ring
with id.addr equal to dst and id.partner equal to V4V_DOMID_ANY. If the insert is successfull
then Xen will trigger the V4V VIRQ line in the receiving domain.

** Reception

Xen pads all messages on the ring to 16 bytes (the macro V4V_ROUNDUP is provided 
for convience), and inserts a message header infront of all messages it copies onto the ring.

 struct v4v_ring_message_header
 {
    uint32_t len;
    struct v4v_addr source;
    uint16_t pad;
    uint32_t protocol;
    uint8_t data[0];
 };

len is the number of bytes in the message including the struct v4v_ring_message_header
source specifies the source address from which the message came, source.domain is
set by xen, and source.port is taken from the arguments to the send or sendv call.
protocol is the protocol value given to the send call.

An  inline function is provided to make reading from the ring easier:

 ssize_t
 v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
              void *_buf, size_t t, int consume)

v4v_copy_out will copy at most t bytes from the ring r and place them in buf, if it
is non-null. If from and protocol are not NULL pointers then the source address and
 protocol number will by copied into them. If consume is non-zero then the ring's
receive pointer will be advanced. The function returns the number of bytes of payload
that the message has (ie. the number of bytes passed to the original send or sendv call).
Thus, v4v_copy_out(r,NULL,NULL,NULL,0,0); will return the number of bytes in the next message,
and  v4v_copy_out(r,NULL,NULL,NULL,0,1);  will return the number of bytes in the next message
and delete it from the ring.

** Notification
If the receiving ring is full in a send or sendv hypercall, the hypercall will return with
the error -EAGAIN. When sufficient space becomes available in the ring xen will raise the V4V VIRQ 
line.

Jean

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09: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 1ScZ9J-0007NO-FL; Thu, 07 Jun 2012 09:37:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1ScZ9H-0007Mt-Nb
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:37:00 +0000
Received: from [193.109.254.147:63979] by server-6.bemta-14.messagelabs.com id
	A1/AC-02426-A3670DF4; Thu, 07 Jun 2012 09:36:58 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339061818!1682602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21612 invoked from network); 7 Jun 2012 09:36:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12876460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 09:36:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 10:36:58 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1ScZ9F-0007Ci-J9;
	Thu, 07 Jun 2012 09:36:57 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@citrix.com>)	id 1ScZEX-0003xR-Jd;
	Thu, 07 Jun 2012 10:42:25 +0100
Date: Thu, 7 Jun 2012 10:42:25 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607094225.GB15139@spongy.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338558477.17466.121.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][PATCH 0/5] Add V4V to 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 01/06 02:47, Ian Campbell wrote:
> On Thu, 2012-05-31 at 16:07 +0100, Jean Guyader wrote:
> > V4V is a copy based inter vm communication system.
> > 
> > Please have a look at this thread for more detail
> > about V4V.
> > http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html
> > 
> > This patch series is work in progress but I wanted to
> > post it early enough so I can get feedback from people.
> 
> The main thing which is missing here, which makes it rather hard to
> review, is any kind of design documentation. It would also be great to
> see the rationale for why things have to be done this way.
> 
> For example it seems that there is a bunch of stuff being added to the
> hypervisor which could live in the context of some guest or service
> domain -- putting stuff like that in the hypervisor needs strong
> arguments and rationale why it has to be there rather than somewhere
> else.
> 
> Likewise perhaps the v4v hypercall could effectively be implemented with
> a multicall containing some grant copy ops and evtchn manipulations?
> 
> But in the absence of any descriptions of the whats, hows and whys of
> v4v its rather hard to have these sorts of conversations. The above are
> some concrete examples but I'm more interested in seeing the more
> general descriptions before we get into those.
> 
> Ian.
> 
> 

(resent, sorry if you get this message twice)

* Overview
** Architecture

v4v has a very simple architecture. The receiving domain registers a ring with xen. 
The sending domain requests that xen inserts data into the receiving domain's ring.
Notification that there is new data to read is delivered by a VIRQ, and a domain can
request an interrupt be generated when sufficient space is available in another domain's
ring. The code that inserts the data into the ring is in xen, and xen writes a header
describing the data and where it came from infront of the data. As both the ring manipulation
and the header are written by the hypervisor, the receiving domain can trust their content
and the format of the ring. 

** Addressing
v4v_addr_t identifies an endpoint address.
 typedef struct v4v_addr
 {
     uint32_t port;
     domid_t domain;
 } v4v_addr_t;
struct v4v_ring_id uniquely identifies a ring on the platform.

 struct v4v_ring_id
 {
    struct v4v_addr addr;
    domid_t partner;
 };

When a send operation is performed, xen will attempt to find a ring 
registered by destination domain, with the required port, and with
a partner of the sending domain. Failing that it will then search
for a ring with the correct port and destination domain, but with 
partner set to V4V_DOMID_ANY.

** Setup
A domain first generates a ring, and a structure describing the pages in the ring.
Rings must be page aligned, and contiguous in virtual memory, but need not be 
contiguous in physical(pfn) or machine(mfn) memory. A ring is uniquely identified
on the platform by its struct v4v_ring_id.

A ring is contained in a v4v_ring_t
 typedef struct v4v_ring
 {
    uint64_t magic;
    /*
     * Identifies ring_id - xen only looks at this during register/unregister
     * and will fill in id.addr.domain
     */
    struct v4v_ring_id id;
    /* length of ring[], must be a multiple of 16 */
    uint32_t len;
    /* rx_ptr - modified by domain */
    uint32_t rx_ptr;
    /* tx_ptr - modified by xen */
    volatile uint32_t tx_ptr;
    uint64_t reserved[4];
    volatile uint8_t ring[0];
 } v4v_ring_t;

To register the ring, xen also needs a list of pfn that the ring occupies.
This is provided in a v4v_pfn_list_t
 typedef struct v4v_pfn_list_t
 {
    uint64_t magic;
    uint32_t npage;
    uint32_t pad;
    uint64_t reserved[3];
    v4v_pfn_t pages[0];
 } v4v_pfn_list_t;

Registering the ring is done with a hypercall

int hypercall(NR_V4V,V4VOP_register_ring,v4v_ring_t *ring,v4v_pfn_list_t *pfn_list);

On registering, xen will check that the tx_ptr and rx_ptr values are valid (aligned
and within the size of the ring) and modify them if they are not, it will also update
id.addr.domain with the calling domain's domid and take an internal copy of all the
relevant information. After registration the only field that xen will read is
ring->rx_ptr, xen will write to ring->ring[] and ring->tx_ptr. 
Thus pfn_list can be freed after the registration call. Critically, registration is
idempotent, and all a domain need do after hibernation or migration is re-register all
its rings. (NB the id.addr.domain field may change).

** Sending

To send data a guest merely calls the send or sendv hypercall
int hypercall(NR_V4V,V4VOP_send,v4v_addr_t *src,v4v_addr_t *dst,void *buf, uint32_t len,
              uint32_t protocol);

the caller provides a source address, a destination address, a buffer, a number of bytes to copy
and a 32 bit protocol number. Xen ignores src->domain and instead uses the domain id of the caller.

Xen will attempt to insert into a ring with id.addr equal to dst, and with
id.partner equal to the caller's domid. Otherwise it will insert into a ring
with id.addr equal to dst and id.partner equal to V4V_DOMID_ANY. If the insert is successfull
then Xen will trigger the V4V VIRQ line in the receiving domain.

** Reception

Xen pads all messages on the ring to 16 bytes (the macro V4V_ROUNDUP is provided 
for convience), and inserts a message header infront of all messages it copies onto the ring.

 struct v4v_ring_message_header
 {
    uint32_t len;
    struct v4v_addr source;
    uint16_t pad;
    uint32_t protocol;
    uint8_t data[0];
 };

len is the number of bytes in the message including the struct v4v_ring_message_header
source specifies the source address from which the message came, source.domain is
set by xen, and source.port is taken from the arguments to the send or sendv call.
protocol is the protocol value given to the send call.

An  inline function is provided to make reading from the ring easier:

 ssize_t
 v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
              void *_buf, size_t t, int consume)

v4v_copy_out will copy at most t bytes from the ring r and place them in buf, if it
is non-null. If from and protocol are not NULL pointers then the source address and
 protocol number will by copied into them. If consume is non-zero then the ring's
receive pointer will be advanced. The function returns the number of bytes of payload
that the message has (ie. the number of bytes passed to the original send or sendv call).
Thus, v4v_copy_out(r,NULL,NULL,NULL,0,0); will return the number of bytes in the next message,
and  v4v_copy_out(r,NULL,NULL,NULL,0,1);  will return the number of bytes in the next message
and delete it from the ring.

** Notification
If the receiving ring is full in a send or sendv hypercall, the hypercall will return with
the error -EAGAIN. When sufficient space becomes available in the ring xen will raise the V4V VIRQ 
line.

Jean

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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZCm-0007r2-AI; Thu, 07 Jun 2012 09:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScZCl-0007qk-2Q
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:40:35 +0000
Received: from [85.158.143.99:14529] by server-1.bemta-4.messagelabs.com id
	74/1B-10042-21770DF4; Thu, 07 Jun 2012 09:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339062032!31695791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10698 invoked from network); 7 Jun 2012 09:40:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12876548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 09:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	10:40:32 +0100
Message-ID: <1339062030.15265.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 10:40:30 +0100
In-Reply-To: <1338990925.32319.103.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
	<1338990925.32319.103.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:55 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 14:46 +0100, Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
> > >  xen/arch/arm/dummy.S          |    3 --
> > >  xen/include/public/arch-arm.h |    9 -----
> > >  3 files changed, 68 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > index 9339a11..62a2f3a 100644
> > > --- a/xen/arch/arm/domain.c
> > > +++ b/xen/arch/arm/domain.c
> > > @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
> > >      free_xenheap_page(v);
> > >  }
> > >  
> > > +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> > > +{
> > > +    return xmalloc(struct vcpu_guest_context);
> > > +
> > > +}
> > > +
> > > +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> > > +{
> > > +    xfree(vgc);
> > > +}
> > > +
> > >  int vcpu_initialise(struct vcpu *v)
> > >  {
> > >      int rc = 0;
> > > @@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> > >      if ( (rc = p2m_init(d)) != 0 )
> > >          goto fail;
> > >  
> > > +    if ( (rc = domain_vgic_init(d)) != 0 )
> > > +        goto fail;
> > > +
> > 
> > there is a call to domain_vgic_init already in arch_domain_create
> 
> So there is!

Rather inexplicably removing either one of those two domain_vgic_init
calls causes:
        (XEN) Unexpected Trap: Data Abort
        (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
        (XEN) CPU:    0
        (XEN) PC:     00222e7c _spin_lock+0x28/0x6c
        (XEN) CPSR:   600001da MODE:HYP
        (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
        (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
        (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
        (XEN)      SP: 40017d5c LR: 00222e68
        (XEN) 
        (XEN) HTTBR ffec1000
        (XEN) HDFAR 2c4381
        (XEN) HIFAR 0
        (XEN) HPFAR 0
        (XEN) HCR 00000835
        (XEN) HSR   94000021
        (XEN) 
        (XEN) DFSR 817 DFAR 134bc
        (XEN) IFSR 7 IFAR 4024c224
        (XEN) 
        (XEN) Xen stack trace from sp=40017d5c:
        [...]
        (XEN) Xen call trace:
        (XEN)    [<00222e7c>] _spin_lock+0x28/0x6c
        (XEN)    [<00226270>] init_timer+0xbc/0x160
        (XEN)    [<0021fc14>] sched_init_vcpu+0x94/0x200
        (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
        (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
        (XEN)    [<00241aec>] do_trap_hypervisor+0x588/0x8cc
        (XEN)    [<0023bbf0>] return_from_trap+0x0/0x4

I'm totally at a loss to explain that. domain_vgic_init allocates two
arrays so it is possible we have some sort of overrun error, although I
can't for the life of me see it in there (it could be elsewhere though).

As an experiment I tried doubling the size of both allocations in that
function (and calling it once) but that didn't help so no hints from
that...

More head scratching required 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 Thu Jun 07 09:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZCm-0007r2-AI; Thu, 07 Jun 2012 09:40:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScZCl-0007qk-2Q
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:40:35 +0000
Received: from [85.158.143.99:14529] by server-1.bemta-4.messagelabs.com id
	74/1B-10042-21770DF4; Thu, 07 Jun 2012 09:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339062032!31695791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10698 invoked from network); 7 Jun 2012 09:40:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 09:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12876548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 09:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	10:40:32 +0100
Message-ID: <1339062030.15265.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 10:40:30 +0100
In-Reply-To: <1338990925.32319.103.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
	<1338990925.32319.103.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 14:55 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 14:46 +0100, Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/domain.c         |   68 +++++++++++++++++++++++++++++++++++++++++
> > >  xen/arch/arm/dummy.S          |    3 --
> > >  xen/include/public/arch-arm.h |    9 -----
> > >  3 files changed, 68 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > index 9339a11..62a2f3a 100644
> > > --- a/xen/arch/arm/domain.c
> > > +++ b/xen/arch/arm/domain.c
> > > @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
> > >      free_xenheap_page(v);
> > >  }
> > >  
> > > +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> > > +{
> > > +    return xmalloc(struct vcpu_guest_context);
> > > +
> > > +}
> > > +
> > > +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> > > +{
> > > +    xfree(vgc);
> > > +}
> > > +
> > >  int vcpu_initialise(struct vcpu *v)
> > >  {
> > >      int rc = 0;
> > > @@ -182,6 +193,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> > >      if ( (rc = p2m_init(d)) != 0 )
> > >          goto fail;
> > >  
> > > +    if ( (rc = domain_vgic_init(d)) != 0 )
> > > +        goto fail;
> > > +
> > 
> > there is a call to domain_vgic_init already in arch_domain_create
> 
> So there is!

Rather inexplicably removing either one of those two domain_vgic_init
calls causes:
        (XEN) Unexpected Trap: Data Abort
        (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
        (XEN) CPU:    0
        (XEN) PC:     00222e7c _spin_lock+0x28/0x6c
        (XEN) CPSR:   600001da MODE:HYP
        (XEN)      R0: 002c4389 R1: 800001da R2: 00000001 R3: 0000ffff
        (XEN)      R4: 002c4381 R5: 00000080 R6: 002c4380 R7: 002c4000
        (XEN)      R8: 002c4380 R9: 4000015a R10:00000080 R11:40017d6c R12:00000000
        (XEN)      SP: 40017d5c LR: 00222e68
        (XEN) 
        (XEN) HTTBR ffec1000
        (XEN) HDFAR 2c4381
        (XEN) HIFAR 0
        (XEN) HPFAR 0
        (XEN) HCR 00000835
        (XEN) HSR   94000021
        (XEN) 
        (XEN) DFSR 817 DFAR 134bc
        (XEN) IFSR 7 IFAR 4024c224
        (XEN) 
        (XEN) Xen stack trace from sp=40017d5c:
        [...]
        (XEN) Xen call trace:
        (XEN)    [<00222e7c>] _spin_lock+0x28/0x6c
        (XEN)    [<00226270>] init_timer+0xbc/0x160
        (XEN)    [<0021fc14>] sched_init_vcpu+0x94/0x200
        (XEN)    [<002061a4>] alloc_vcpu+0x124/0x210
        (XEN)    [<00204890>] do_domctl+0xaa4/0x14e4
        (XEN)    [<00241aec>] do_trap_hypervisor+0x588/0x8cc
        (XEN)    [<0023bbf0>] return_from_trap+0x0/0x4

I'm totally at a loss to explain that. domain_vgic_init allocates two
arrays so it is possible we have some sort of overrun error, although I
can't for the life of me see it in there (it could be elsewhere though).

As an experiment I tried doubling the size of both allocations in that
function (and calling it once) but that didn't help so no hints from
that...

More head scratching required 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 Thu Jun 07 09:42:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:42: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 1ScZE3-0007yw-P4; Thu, 07 Jun 2012 09:41:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScZE2-0007yi-I2
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:41:54 +0000
Received: from [193.109.254.147:39698] by server-10.bemta-14.messagelabs.com
	id BC/1A-25709-16770DF4; Thu, 07 Jun 2012 09:41:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339062112!2883616!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12246 invoked from network); 7 Jun 2012 09:41:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:41:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZE0-000IZy-AH; Thu, 07 Jun 2012 09:41:52 +0000
Date: Thu, 7 Jun 2012 10:41:52 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607094152.GG70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 21/38] arm: dump guest s1 walk on data abort
	which is not a stage 2 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

At 15:39 +0000 on 01 Jun (1338565190), Ian Campbell wrote:
> +    offset = addr >> (12+10);
> +    printk("1ST[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",

Nit: 0x%08 prints '0' as '0x00000000', which is nicer I think.

Otherwise: ack.

Tim.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:42:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:42: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 1ScZE3-0007yw-P4; Thu, 07 Jun 2012 09:41:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScZE2-0007yi-I2
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:41:54 +0000
Received: from [193.109.254.147:39698] by server-10.bemta-14.messagelabs.com
	id BC/1A-25709-16770DF4; Thu, 07 Jun 2012 09:41:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339062112!2883616!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12246 invoked from network); 7 Jun 2012 09:41:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:41:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZE0-000IZy-AH; Thu, 07 Jun 2012 09:41:52 +0000
Date: Thu, 7 Jun 2012 10:41:52 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607094152.GG70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 21/38] arm: dump guest s1 walk on data abort
	which is not a stage 2 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

At 15:39 +0000 on 01 Jun (1338565190), Ian Campbell wrote:
> +    offset = addr >> (12+10);
> +    printk("1ST[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",

Nit: 0x%08 prints '0' as '0x00000000', which is nicer I think.

Otherwise: ack.

Tim.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:48:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:48: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 1ScZK6-0008NY-5J; Thu, 07 Jun 2012 09:48:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScZK5-0008NL-33
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:48:09 +0000
Received: from [85.158.143.99:47982] by server-2.bemta-4.messagelabs.com id
	5F/E9-17938-7D870DF4; Thu, 07 Jun 2012 09:48:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339062486!31697498!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 7 Jun 2012 09:48:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:48:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZK1-000Ib5-EE; Thu, 07 Jun 2012 09:48:05 +0000
Date: Thu, 7 Jun 2012 10:48:05 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607094805.GH70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 26/38] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:39 +0000 on 01 Jun (1338565195), Ian Campbell wrote:
> For some reason we were holding the lock over only the unmaps at the end of
> the function, rather than for the whole walk.
> 
> We might want to be more clever in the future, but for now lets just lock for
> the whole walk+create process.
> 
> 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 Jun 07 09:48:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:48: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 1ScZK6-0008NY-5J; Thu, 07 Jun 2012 09:48:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScZK5-0008NL-33
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:48:09 +0000
Received: from [85.158.143.99:47982] by server-2.bemta-4.messagelabs.com id
	5F/E9-17938-7D870DF4; Thu, 07 Jun 2012 09:48:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339062486!31697498!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 7 Jun 2012 09:48:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 09:48:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZK1-000Ib5-EE; Thu, 07 Jun 2012 09:48:05 +0000
Date: Thu, 7 Jun 2012 10:48:05 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607094805.GH70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 26/38] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:39 +0000 on 01 Jun (1338565195), Ian Campbell wrote:
> For some reason we were holding the lock over only the unmaps at the end of
> the function, rather than for the whole walk.
> 
> We might want to be more clever in the future, but for now lets just lock for
> the whole walk+create process.
> 
> 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 Jun 07 09:51:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZNM-0000Gb-HH; Thu, 07 Jun 2012 09:51: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 1ScZNL-0000G0-5G
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:51:31 +0000
Received: from [85.158.143.99:12434] by server-1.bemta-4.messagelabs.com id
	2F/CE-10042-2A970DF4; Thu, 07 Jun 2012 09:51:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339062689!24179133!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15249 invoked from network); 7 Jun 2012 09:51:29 -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; 7 Jun 2012 09:51:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZNI-000Ibn-OK; Thu, 07 Jun 2012 09:51:28 +0000
Date: Thu, 7 Jun 2012 10:51:28 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607095128.GI70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
	not just 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:39 +0000 on 01 Jun (1338565197), Ian Campbell wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index a7fb227..e15c1e8 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>  
>          if ( (rc = p2m_alloc_table(d)) != 0 )
>              goto fail;
> -    }
>  
> -    if ( (rc = domain_vgic_init(d)) != 0 )
> -        goto fail;
> +        if ( (rc = gicv_setup(d)) != 0 )
> +            goto fail;
> +
> +        if ( (rc = domain_vgic_init(d)) != 0 )
> +            goto fail;
> +    }
>  
>      rc = 0;
>  fail:
> +    /*XXX unwind allocations etc */

Ahem. :)

Tim.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 09:51:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 09:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZNM-0000Gb-HH; Thu, 07 Jun 2012 09:51: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 1ScZNL-0000G0-5G
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 09:51:31 +0000
Received: from [85.158.143.99:12434] by server-1.bemta-4.messagelabs.com id
	2F/CE-10042-2A970DF4; Thu, 07 Jun 2012 09:51:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339062689!24179133!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15249 invoked from network); 7 Jun 2012 09:51:29 -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; 7 Jun 2012 09:51:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZNI-000Ibn-OK; Thu, 07 Jun 2012 09:51:28 +0000
Date: Thu, 7 Jun 2012 10:51:28 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607095128.GI70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
	not just 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:39 +0000 on 01 Jun (1338565197), Ian Campbell wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index a7fb227..e15c1e8 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>  
>          if ( (rc = p2m_alloc_table(d)) != 0 )
>              goto fail;
> -    }
>  
> -    if ( (rc = domain_vgic_init(d)) != 0 )
> -        goto fail;
> +        if ( (rc = gicv_setup(d)) != 0 )
> +            goto fail;
> +
> +        if ( (rc = domain_vgic_init(d)) != 0 )
> +            goto fail;
> +    }
>  
>      rc = 0;
>  fail:
> +    /*XXX unwind allocations etc */

Ahem. :)

Tim.


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

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:17: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 1ScZmL-0001h3-19; Thu, 07 Jun 2012 10:17:21 +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 1ScZmJ-0001gy-Pw
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:17:20 +0000
Received: from [193.109.254.147:57359] by server-12.bemta-14.messagelabs.com
	id 8A/9D-12998-AAF70DF4; Thu, 07 Jun 2012 10:17:14 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339064211!8523340!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16511 invoked from network); 7 Jun 2012 10:16:52 -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;
	7 Jun 2012 10:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="197856636"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:16:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 06:16:49 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScZlo-0005PE-Pe;
	Thu, 07 Jun 2012 11:16:48 +0100
Message-ID: <4FD07F23.6020208@eu.citrix.com>
Date: Thu, 7 Jun 2012 11:14:59 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
In-Reply-To: <d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04 of 10] xenalyze: update trace.h to match
	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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Update trace.h to the version in xen-unstable (plus my PV_HYPERCALL_*
> patches).
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>
> diff --git a/trace.h b/trace.h
> --- a/trace.h
> +++ b/trace.h
> @@ -57,6 +57,7 @@
>   #define TRC_SCHED_CLASS     0x00022000   /* Scheduler-specific    */
>   #define TRC_SCHED_VERBOSE   0x00028000   /* More inclusive scheduling */
>
> +/* Trace classes for Hardware */
>   #define TRC_HW_PM           0x00801000   /* Power management traces */
>   #define TRC_HW_IRQ          0x00802000   /* Traces relating to the handling of IRQs */
>
> @@ -93,20 +94,51 @@
>   #define TRC_MEM_POD_ZERO_RECLAIM    (TRC_MEM + 17)
>   #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
>
> +#define TRC_PV_ENTRY   0x00201000 /* Hypervisor entry points for PV guests. */
> +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */
>
> -#define TRC_PV_HYPERCALL             (TRC_PV +  1)
> -#define TRC_PV_TRAP                  (TRC_PV +  3)
> -#define TRC_PV_PAGE_FAULT            (TRC_PV +  4)
> -#define TRC_PV_FORCED_INVALID_OP     (TRC_PV +  5)
> -#define TRC_PV_EMULATE_PRIVOP        (TRC_PV +  6)
> -#define TRC_PV_EMULATE_4GB           (TRC_PV +  7)
> -#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV +  8)
> -#define TRC_PV_PAGING_FIXUP          (TRC_PV +  9)
> -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10)
> -#define TRC_PV_PTWR_EMULATION        (TRC_PV + 11)
> -#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV + 12)
> -  /* Indicates that addresses in trace record are 64 bits */
> -#define TRC_64_FLAG               (0x100)
> +#define TRC_PV_HYPERCALL             (TRC_PV_ENTRY +  1)
> +#define TRC_PV_TRAP                  (TRC_PV_ENTRY +  3)
> +#define TRC_PV_PAGE_FAULT            (TRC_PV_ENTRY +  4)
> +#define TRC_PV_FORCED_INVALID_OP     (TRC_PV_ENTRY +  5)
> +#define TRC_PV_EMULATE_PRIVOP        (TRC_PV_ENTRY +  6)
> +#define TRC_PV_EMULATE_4GB           (TRC_PV_ENTRY +  7)
> +#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV_ENTRY +  8)
> +#define TRC_PV_PAGING_FIXUP          (TRC_PV_ENTRY +  9)
> +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10)
> +#define TRC_PV_PTWR_EMULATION        (TRC_PV_ENTRY + 11)
> +#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV_ENTRY + 12)
> +#define TRC_PV_HYPERCALL_V2          (TRC_PV_ENTRY + 13)
> +#define TRC_PV_HYPERCALL_SUBCALL     (TRC_PV_SUBCALL + 14)
> +
> +/*
> + * TRC_PV_HYPERCALL_V2 format
> + *
> + * Only some of the hypercall argument are recorded. Bit fields A0 to
> + * A5 in the first extra word are set if the argument is present and
> + * the arguments themselves are packed sequentially in the following
> + * words.
> + *
> + * The TRC_64_FLAG bit is not set for these events (even if there are
> + * 64-bit arguments in the record).
> + *
> + * Word
> + * 0    bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0
> + *          A5   |A4   |A3   |A2   |A1   |A0   |Hypercall op
> + * 1    First 32 bit (or low word of first 64 bit) arg in record
> + * 2    Second 32 bit (or high word of first 64 bit) arg in record
> + * ...
> + *
> + * A0-A5 bitfield values:
> + *
> + *   00b  Argument not present
> + *   01b  32-bit argument present
> + *   10b  64-bit argument present
> + *   11b  Reserved
> + */
> +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_MASK  (0xfff00000)
>
>   #define TRC_SHADOW_NOT_SHADOW                 (TRC_SHADOW +  1)
>   #define TRC_SHADOW_FAST_PROPAGATE             (TRC_SHADOW +  2)
> @@ -125,6 +157,7 @@
>   #define TRC_SHADOW_RESYNC_ONLY                (TRC_SHADOW + 15)
>
>   /* trace events per subclass */
> +#define TRC_HVM_NESTEDFLAG      (0x400)
>   #define TRC_HVM_VMENTRY         (TRC_HVM_ENTRYEXIT + 0x01)
>   #define TRC_HVM_VMEXIT          (TRC_HVM_ENTRYEXIT + 0x02)
>   #define TRC_HVM_VMEXIT64        (TRC_HVM_ENTRYEXIT + TRC_64_FLAG + 0x02)
> @@ -165,6 +198,7 @@
>   #define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
>   #define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
>   #define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
> +#define TRC_HVM_VLAPIC           (TRC_HVM_HANDLER + 0x25)
>
>   #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
>   #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)
> @@ -172,8 +206,9 @@
>   /* trace events for per class */
>   #define TRC_PM_FREQ_CHANGE      (TRC_HW_PM + 0x01)
>   #define TRC_PM_IDLE_ENTRY       (TRC_HW_PM + 0x02)
> -#define TRC_PM_IDLE_EXIT        (TRC_HW_PM  + 0x03)
> +#define TRC_PM_IDLE_EXIT        (TRC_HW_PM + 0x03)
>
> +/* Trace events for IRQs */
>   #define TRC_HW_IRQ_MOVE_CLEANUP_DELAY (TRC_HW_IRQ + 0x1)
>   #define TRC_HW_IRQ_MOVE_CLEANUP       (TRC_HW_IRQ + 0x2)
>   #define TRC_HW_IRQ_BIND_VECTOR        (TRC_HW_IRQ + 0x3)
> @@ -182,12 +217,15 @@
>   #define TRC_HW_IRQ_ASSIGN_VECTOR      (TRC_HW_IRQ + 0x6)
>   #define TRC_HW_IRQ_UNMAPPED_VECTOR    (TRC_HW_IRQ + 0x7)
>   #define TRC_HW_IRQ_HANDLED            (TRC_HW_IRQ + 0x8)
> -#define TRC_HW_IRQ_MSI_WRITE          (TRC_HW_IRQ + 0x9)
> -#define TRC_HW_IRQ_MAP_PIRQ_MSI       (TRC_HW_IRQ + 0xa)
> -#define TRC_HW_IRQ_MAP_PIRQ_GSI       (TRC_HW_IRQ + 0xb)
> -#define TRC_HW_IRQ_MSI_SET_AFFINITY   (TRC_HW_IRQ + 0x10)
> -#define TRC_HW_IRQ_SET_DESC_AFFINITY  (TRC_HW_IRQ + 0x11)
> -#define TRC_HW_IRQ_IOMMU_AMD_IRE      (TRC_HW_IRQ + 0x12)
> +
> +/*
> + * Event Flags
> + *
> + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple
> + * record formats.  These event flags distinguish between the
> + * different formats.
> + */
> +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */
>
>   /* This structure represents a single trace buffer record. */
>   struct t_rec {
> @@ -205,6 +243,34 @@ struct t_rec {
>       } u;
>   };
>
> +/*
> + * This structure contains the metadata for a single trace buffer.  The head
> + * field, indexes into an array of struct t_rec's.
> + */
> +struct t_buf {
> +    /* Assume the data buffer size is X.  X is generally not a power of 2.
> +     * CONS and PROD are incremented modulo (2*X):
> +     *     0<= cons<  2*X
> +     *     0<= prod<  2*X
> +     * This is done because addition modulo X breaks at 2^32 when X is not a
> +     * power of 2:
> +     *     (((2^32 - 1) % X) + 1) % X != (2^32) % X
> +     */
> +    uint32_t cons;   /* Offset of next item to be consumed by control tools. */
> +    uint32_t prod;   /* Offset of next item to be produced by Xen.           */
> +    /*  Records follow immediately after the meta-data header.    */
> +};
> +
> +/* Structure used to pass MFNs to the trace buffers back to trace consumers.
> + * Offset is an offset into the mapped structure where the mfn list will be held.
> + * MFNs will be at ((unsigned long *)(t_info))+(t_info->cpu_offset[cpu]).
> + */
> +struct t_info {
> +    uint16_t tbuf_size; /* Size in pages of each trace buffer */
> +    uint16_t mfn_offset[];  /* Offset within t_info structure of the page list per cpu */
> +    /* MFN lists immediately after the header */
> +};
> +
>   #endif /* __XEN_PUBLIC_TRACE_H__ */
>
>   /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:17: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 1ScZmL-0001h3-19; Thu, 07 Jun 2012 10:17:21 +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 1ScZmJ-0001gy-Pw
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:17:20 +0000
Received: from [193.109.254.147:57359] by server-12.bemta-14.messagelabs.com
	id 8A/9D-12998-AAF70DF4; Thu, 07 Jun 2012 10:17:14 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339064211!8523340!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16511 invoked from network); 7 Jun 2012 10:16:52 -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;
	7 Jun 2012 10:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="197856636"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:16:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 06:16:49 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScZlo-0005PE-Pe;
	Thu, 07 Jun 2012 11:16:48 +0100
Message-ID: <4FD07F23.6020208@eu.citrix.com>
Date: Thu, 7 Jun 2012 11:14:59 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
In-Reply-To: <d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04 of 10] xenalyze: update trace.h to match
	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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Update trace.h to the version in xen-unstable (plus my PV_HYPERCALL_*
> patches).
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>
> diff --git a/trace.h b/trace.h
> --- a/trace.h
> +++ b/trace.h
> @@ -57,6 +57,7 @@
>   #define TRC_SCHED_CLASS     0x00022000   /* Scheduler-specific    */
>   #define TRC_SCHED_VERBOSE   0x00028000   /* More inclusive scheduling */
>
> +/* Trace classes for Hardware */
>   #define TRC_HW_PM           0x00801000   /* Power management traces */
>   #define TRC_HW_IRQ          0x00802000   /* Traces relating to the handling of IRQs */
>
> @@ -93,20 +94,51 @@
>   #define TRC_MEM_POD_ZERO_RECLAIM    (TRC_MEM + 17)
>   #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
>
> +#define TRC_PV_ENTRY   0x00201000 /* Hypervisor entry points for PV guests. */
> +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */
>
> -#define TRC_PV_HYPERCALL             (TRC_PV +  1)
> -#define TRC_PV_TRAP                  (TRC_PV +  3)
> -#define TRC_PV_PAGE_FAULT            (TRC_PV +  4)
> -#define TRC_PV_FORCED_INVALID_OP     (TRC_PV +  5)
> -#define TRC_PV_EMULATE_PRIVOP        (TRC_PV +  6)
> -#define TRC_PV_EMULATE_4GB           (TRC_PV +  7)
> -#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV +  8)
> -#define TRC_PV_PAGING_FIXUP          (TRC_PV +  9)
> -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10)
> -#define TRC_PV_PTWR_EMULATION        (TRC_PV + 11)
> -#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV + 12)
> -  /* Indicates that addresses in trace record are 64 bits */
> -#define TRC_64_FLAG               (0x100)
> +#define TRC_PV_HYPERCALL             (TRC_PV_ENTRY +  1)
> +#define TRC_PV_TRAP                  (TRC_PV_ENTRY +  3)
> +#define TRC_PV_PAGE_FAULT            (TRC_PV_ENTRY +  4)
> +#define TRC_PV_FORCED_INVALID_OP     (TRC_PV_ENTRY +  5)
> +#define TRC_PV_EMULATE_PRIVOP        (TRC_PV_ENTRY +  6)
> +#define TRC_PV_EMULATE_4GB           (TRC_PV_ENTRY +  7)
> +#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV_ENTRY +  8)
> +#define TRC_PV_PAGING_FIXUP          (TRC_PV_ENTRY +  9)
> +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10)
> +#define TRC_PV_PTWR_EMULATION        (TRC_PV_ENTRY + 11)
> +#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV_ENTRY + 12)
> +#define TRC_PV_HYPERCALL_V2          (TRC_PV_ENTRY + 13)
> +#define TRC_PV_HYPERCALL_SUBCALL     (TRC_PV_SUBCALL + 14)
> +
> +/*
> + * TRC_PV_HYPERCALL_V2 format
> + *
> + * Only some of the hypercall argument are recorded. Bit fields A0 to
> + * A5 in the first extra word are set if the argument is present and
> + * the arguments themselves are packed sequentially in the following
> + * words.
> + *
> + * The TRC_64_FLAG bit is not set for these events (even if there are
> + * 64-bit arguments in the record).
> + *
> + * Word
> + * 0    bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0
> + *          A5   |A4   |A3   |A2   |A1   |A0   |Hypercall op
> + * 1    First 32 bit (or low word of first 64 bit) arg in record
> + * 2    Second 32 bit (or high word of first 64 bit) arg in record
> + * ...
> + *
> + * A0-A5 bitfield values:
> + *
> + *   00b  Argument not present
> + *   01b  32-bit argument present
> + *   10b  64-bit argument present
> + *   11b  Reserved
> + */
> +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_MASK  (0xfff00000)
>
>   #define TRC_SHADOW_NOT_SHADOW                 (TRC_SHADOW +  1)
>   #define TRC_SHADOW_FAST_PROPAGATE             (TRC_SHADOW +  2)
> @@ -125,6 +157,7 @@
>   #define TRC_SHADOW_RESYNC_ONLY                (TRC_SHADOW + 15)
>
>   /* trace events per subclass */
> +#define TRC_HVM_NESTEDFLAG      (0x400)
>   #define TRC_HVM_VMENTRY         (TRC_HVM_ENTRYEXIT + 0x01)
>   #define TRC_HVM_VMEXIT          (TRC_HVM_ENTRYEXIT + 0x02)
>   #define TRC_HVM_VMEXIT64        (TRC_HVM_ENTRYEXIT + TRC_64_FLAG + 0x02)
> @@ -165,6 +198,7 @@
>   #define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
>   #define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
>   #define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
> +#define TRC_HVM_VLAPIC           (TRC_HVM_HANDLER + 0x25)
>
>   #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
>   #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)
> @@ -172,8 +206,9 @@
>   /* trace events for per class */
>   #define TRC_PM_FREQ_CHANGE      (TRC_HW_PM + 0x01)
>   #define TRC_PM_IDLE_ENTRY       (TRC_HW_PM + 0x02)
> -#define TRC_PM_IDLE_EXIT        (TRC_HW_PM  + 0x03)
> +#define TRC_PM_IDLE_EXIT        (TRC_HW_PM + 0x03)
>
> +/* Trace events for IRQs */
>   #define TRC_HW_IRQ_MOVE_CLEANUP_DELAY (TRC_HW_IRQ + 0x1)
>   #define TRC_HW_IRQ_MOVE_CLEANUP       (TRC_HW_IRQ + 0x2)
>   #define TRC_HW_IRQ_BIND_VECTOR        (TRC_HW_IRQ + 0x3)
> @@ -182,12 +217,15 @@
>   #define TRC_HW_IRQ_ASSIGN_VECTOR      (TRC_HW_IRQ + 0x6)
>   #define TRC_HW_IRQ_UNMAPPED_VECTOR    (TRC_HW_IRQ + 0x7)
>   #define TRC_HW_IRQ_HANDLED            (TRC_HW_IRQ + 0x8)
> -#define TRC_HW_IRQ_MSI_WRITE          (TRC_HW_IRQ + 0x9)
> -#define TRC_HW_IRQ_MAP_PIRQ_MSI       (TRC_HW_IRQ + 0xa)
> -#define TRC_HW_IRQ_MAP_PIRQ_GSI       (TRC_HW_IRQ + 0xb)
> -#define TRC_HW_IRQ_MSI_SET_AFFINITY   (TRC_HW_IRQ + 0x10)
> -#define TRC_HW_IRQ_SET_DESC_AFFINITY  (TRC_HW_IRQ + 0x11)
> -#define TRC_HW_IRQ_IOMMU_AMD_IRE      (TRC_HW_IRQ + 0x12)
> +
> +/*
> + * Event Flags
> + *
> + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple
> + * record formats.  These event flags distinguish between the
> + * different formats.
> + */
> +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */
>
>   /* This structure represents a single trace buffer record. */
>   struct t_rec {
> @@ -205,6 +243,34 @@ struct t_rec {
>       } u;
>   };
>
> +/*
> + * This structure contains the metadata for a single trace buffer.  The head
> + * field, indexes into an array of struct t_rec's.
> + */
> +struct t_buf {
> +    /* Assume the data buffer size is X.  X is generally not a power of 2.
> +     * CONS and PROD are incremented modulo (2*X):
> +     *     0<= cons<  2*X
> +     *     0<= prod<  2*X
> +     * This is done because addition modulo X breaks at 2^32 when X is not a
> +     * power of 2:
> +     *     (((2^32 - 1) % X) + 1) % X != (2^32) % X
> +     */
> +    uint32_t cons;   /* Offset of next item to be consumed by control tools. */
> +    uint32_t prod;   /* Offset of next item to be produced by Xen.           */
> +    /*  Records follow immediately after the meta-data header.    */
> +};
> +
> +/* Structure used to pass MFNs to the trace buffers back to trace consumers.
> + * Offset is an offset into the mapped structure where the mfn list will be held.
> + * MFNs will be at ((unsigned long *)(t_info))+(t_info->cpu_offset[cpu]).
> + */
> +struct t_info {
> +    uint16_t tbuf_size; /* Size in pages of each trace buffer */
> +    uint16_t mfn_offset[];  /* Offset within t_info structure of the page list per cpu */
> +    /* MFN lists immediately after the header */
> +};
> +
>   #endif /* __XEN_PUBLIC_TRACE_H__ */
>
>   /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:18:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScZmo-0001js-Ji; Thu, 07 Jun 2012 10:17:50 +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 1ScZmm-0001jE-Gm
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:17:48 +0000
Received: from [85.158.139.83:48073] by server-10.bemta-5.messagelabs.com id
	0A/3A-23803-BCF70DF4; Thu, 07 Jun 2012 10:17:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339064265!30903312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26430 invoked from network); 7 Jun 2012 10:17:46 -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;
	7 Jun 2012 10:17:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="197856712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:17:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 06:17:44 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScZmi-0005Qt-FB;
	Thu, 07 Jun 2012 11:17:44 +0100
Message-ID: <4FD07F5A.1050204@eu.citrix.com>
Date: Thu, 7 Jun 2012 11:15:54 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
In-Reply-To: <d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04 of 10] xenalyze: update trace.h to match
	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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Update trace.h to the version in xen-unstable (plus my PV_HYPERCALL_*
> patches).
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>
> diff --git a/trace.h b/trace.h
> --- a/trace.h
> +++ b/trace.h
> @@ -57,6 +57,7 @@
>   #define TRC_SCHED_CLASS     0x00022000   /* Scheduler-specific    */
>   #define TRC_SCHED_VERBOSE   0x00028000   /* More inclusive scheduling */
>
> +/* Trace classes for Hardware */
>   #define TRC_HW_PM           0x00801000   /* Power management traces */
>   #define TRC_HW_IRQ          0x00802000   /* Traces relating to the handling of IRQs */
>
> @@ -93,20 +94,51 @@
>   #define TRC_MEM_POD_ZERO_RECLAIM    (TRC_MEM + 17)
>   #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
>
> +#define TRC_PV_ENTRY   0x00201000 /* Hypervisor entry points for PV guests. */
> +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */
>
> -#define TRC_PV_HYPERCALL             (TRC_PV +  1)
> -#define TRC_PV_TRAP                  (TRC_PV +  3)
> -#define TRC_PV_PAGE_FAULT            (TRC_PV +  4)
> -#define TRC_PV_FORCED_INVALID_OP     (TRC_PV +  5)
> -#define TRC_PV_EMULATE_PRIVOP        (TRC_PV +  6)
> -#define TRC_PV_EMULATE_4GB           (TRC_PV +  7)
> -#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV +  8)
> -#define TRC_PV_PAGING_FIXUP          (TRC_PV +  9)
> -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10)
> -#define TRC_PV_PTWR_EMULATION        (TRC_PV + 11)
> -#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV + 12)
> -  /* Indicates that addresses in trace record are 64 bits */
> -#define TRC_64_FLAG               (0x100)
> +#define TRC_PV_HYPERCALL             (TRC_PV_ENTRY +  1)
> +#define TRC_PV_TRAP                  (TRC_PV_ENTRY +  3)
> +#define TRC_PV_PAGE_FAULT            (TRC_PV_ENTRY +  4)
> +#define TRC_PV_FORCED_INVALID_OP     (TRC_PV_ENTRY +  5)
> +#define TRC_PV_EMULATE_PRIVOP        (TRC_PV_ENTRY +  6)
> +#define TRC_PV_EMULATE_4GB           (TRC_PV_ENTRY +  7)
> +#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV_ENTRY +  8)
> +#define TRC_PV_PAGING_FIXUP          (TRC_PV_ENTRY +  9)
> +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10)
> +#define TRC_PV_PTWR_EMULATION        (TRC_PV_ENTRY + 11)
> +#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV_ENTRY + 12)
> +#define TRC_PV_HYPERCALL_V2          (TRC_PV_ENTRY + 13)
> +#define TRC_PV_HYPERCALL_SUBCALL     (TRC_PV_SUBCALL + 14)
> +
> +/*
> + * TRC_PV_HYPERCALL_V2 format
> + *
> + * Only some of the hypercall argument are recorded. Bit fields A0 to
> + * A5 in the first extra word are set if the argument is present and
> + * the arguments themselves are packed sequentially in the following
> + * words.
> + *
> + * The TRC_64_FLAG bit is not set for these events (even if there are
> + * 64-bit arguments in the record).
> + *
> + * Word
> + * 0    bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0
> + *          A5   |A4   |A3   |A2   |A1   |A0   |Hypercall op
> + * 1    First 32 bit (or low word of first 64 bit) arg in record
> + * 2    Second 32 bit (or high word of first 64 bit) arg in record
> + * ...
> + *
> + * A0-A5 bitfield values:
> + *
> + *   00b  Argument not present
> + *   01b  32-bit argument present
> + *   10b  64-bit argument present
> + *   11b  Reserved
> + */
> +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_MASK  (0xfff00000)
>
>   #define TRC_SHADOW_NOT_SHADOW                 (TRC_SHADOW +  1)
>   #define TRC_SHADOW_FAST_PROPAGATE             (TRC_SHADOW +  2)
> @@ -125,6 +157,7 @@
>   #define TRC_SHADOW_RESYNC_ONLY                (TRC_SHADOW + 15)
>
>   /* trace events per subclass */
> +#define TRC_HVM_NESTEDFLAG      (0x400)
>   #define TRC_HVM_VMENTRY         (TRC_HVM_ENTRYEXIT + 0x01)
>   #define TRC_HVM_VMEXIT          (TRC_HVM_ENTRYEXIT + 0x02)
>   #define TRC_HVM_VMEXIT64        (TRC_HVM_ENTRYEXIT + TRC_64_FLAG + 0x02)
> @@ -165,6 +198,7 @@
>   #define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
>   #define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
>   #define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
> +#define TRC_HVM_VLAPIC           (TRC_HVM_HANDLER + 0x25)
>
>   #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
>   #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)
> @@ -172,8 +206,9 @@
>   /* trace events for per class */
>   #define TRC_PM_FREQ_CHANGE      (TRC_HW_PM + 0x01)
>   #define TRC_PM_IDLE_ENTRY       (TRC_HW_PM + 0x02)
> -#define TRC_PM_IDLE_EXIT        (TRC_HW_PM  + 0x03)
> +#define TRC_PM_IDLE_EXIT        (TRC_HW_PM + 0x03)
>
> +/* Trace events for IRQs */
>   #define TRC_HW_IRQ_MOVE_CLEANUP_DELAY (TRC_HW_IRQ + 0x1)
>   #define TRC_HW_IRQ_MOVE_CLEANUP       (TRC_HW_IRQ + 0x2)
>   #define TRC_HW_IRQ_BIND_VECTOR        (TRC_HW_IRQ + 0x3)
> @@ -182,12 +217,15 @@
>   #define TRC_HW_IRQ_ASSIGN_VECTOR      (TRC_HW_IRQ + 0x6)
>   #define TRC_HW_IRQ_UNMAPPED_VECTOR    (TRC_HW_IRQ + 0x7)
>   #define TRC_HW_IRQ_HANDLED            (TRC_HW_IRQ + 0x8)
> -#define TRC_HW_IRQ_MSI_WRITE          (TRC_HW_IRQ + 0x9)
> -#define TRC_HW_IRQ_MAP_PIRQ_MSI       (TRC_HW_IRQ + 0xa)
> -#define TRC_HW_IRQ_MAP_PIRQ_GSI       (TRC_HW_IRQ + 0xb)
> -#define TRC_HW_IRQ_MSI_SET_AFFINITY   (TRC_HW_IRQ + 0x10)
> -#define TRC_HW_IRQ_SET_DESC_AFFINITY  (TRC_HW_IRQ + 0x11)
> -#define TRC_HW_IRQ_IOMMU_AMD_IRE      (TRC_HW_IRQ + 0x12)
> +
> +/*
> + * Event Flags
> + *
> + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple
> + * record formats.  These event flags distinguish between the
> + * different formats.
> + */
> +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */
>
>   /* This structure represents a single trace buffer record. */
>   struct t_rec {
> @@ -205,6 +243,34 @@ struct t_rec {
>       } u;
>   };
>
> +/*
> + * This structure contains the metadata for a single trace buffer.  The head
> + * field, indexes into an array of struct t_rec's.
> + */
> +struct t_buf {
> +    /* Assume the data buffer size is X.  X is generally not a power of 2.
> +     * CONS and PROD are incremented modulo (2*X):
> +     *     0<= cons<  2*X
> +     *     0<= prod<  2*X
> +     * This is done because addition modulo X breaks at 2^32 when X is not a
> +     * power of 2:
> +     *     (((2^32 - 1) % X) + 1) % X != (2^32) % X
> +     */
> +    uint32_t cons;   /* Offset of next item to be consumed by control tools. */
> +    uint32_t prod;   /* Offset of next item to be produced by Xen.           */
> +    /*  Records follow immediately after the meta-data header.    */
> +};
> +
> +/* Structure used to pass MFNs to the trace buffers back to trace consumers.
> + * Offset is an offset into the mapped structure where the mfn list will be held.
> + * MFNs will be at ((unsigned long *)(t_info))+(t_info->cpu_offset[cpu]).
> + */
> +struct t_info {
> +    uint16_t tbuf_size; /* Size in pages of each trace buffer */
> +    uint16_t mfn_offset[];  /* Offset within t_info structure of the page list per cpu */
> +    /* MFN lists immediately after the header */
> +};
> +
>   #endif /* __XEN_PUBLIC_TRACE_H__ */
>
>   /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:18:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScZmo-0001js-Ji; Thu, 07 Jun 2012 10:17:50 +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 1ScZmm-0001jE-Gm
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:17:48 +0000
Received: from [85.158.139.83:48073] by server-10.bemta-5.messagelabs.com id
	0A/3A-23803-BCF70DF4; Thu, 07 Jun 2012 10:17:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339064265!30903312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26430 invoked from network); 7 Jun 2012 10:17:46 -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;
	7 Jun 2012 10:17:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="197856712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:17:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 06:17:44 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScZmi-0005Qt-FB;
	Thu, 07 Jun 2012 11:17:44 +0100
Message-ID: <4FD07F5A.1050204@eu.citrix.com>
Date: Thu, 7 Jun 2012 11:15:54 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
In-Reply-To: <d8962a506735776f9342.1338462980@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04 of 10] xenalyze: update trace.h to match
	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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Update trace.h to the version in xen-unstable (plus my PV_HYPERCALL_*
> patches).
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>
> diff --git a/trace.h b/trace.h
> --- a/trace.h
> +++ b/trace.h
> @@ -57,6 +57,7 @@
>   #define TRC_SCHED_CLASS     0x00022000   /* Scheduler-specific    */
>   #define TRC_SCHED_VERBOSE   0x00028000   /* More inclusive scheduling */
>
> +/* Trace classes for Hardware */
>   #define TRC_HW_PM           0x00801000   /* Power management traces */
>   #define TRC_HW_IRQ          0x00802000   /* Traces relating to the handling of IRQs */
>
> @@ -93,20 +94,51 @@
>   #define TRC_MEM_POD_ZERO_RECLAIM    (TRC_MEM + 17)
>   #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
>
> +#define TRC_PV_ENTRY   0x00201000 /* Hypervisor entry points for PV guests. */
> +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */
>
> -#define TRC_PV_HYPERCALL             (TRC_PV +  1)
> -#define TRC_PV_TRAP                  (TRC_PV +  3)
> -#define TRC_PV_PAGE_FAULT            (TRC_PV +  4)
> -#define TRC_PV_FORCED_INVALID_OP     (TRC_PV +  5)
> -#define TRC_PV_EMULATE_PRIVOP        (TRC_PV +  6)
> -#define TRC_PV_EMULATE_4GB           (TRC_PV +  7)
> -#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV +  8)
> -#define TRC_PV_PAGING_FIXUP          (TRC_PV +  9)
> -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10)
> -#define TRC_PV_PTWR_EMULATION        (TRC_PV + 11)
> -#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV + 12)
> -  /* Indicates that addresses in trace record are 64 bits */
> -#define TRC_64_FLAG               (0x100)
> +#define TRC_PV_HYPERCALL             (TRC_PV_ENTRY +  1)
> +#define TRC_PV_TRAP                  (TRC_PV_ENTRY +  3)
> +#define TRC_PV_PAGE_FAULT            (TRC_PV_ENTRY +  4)
> +#define TRC_PV_FORCED_INVALID_OP     (TRC_PV_ENTRY +  5)
> +#define TRC_PV_EMULATE_PRIVOP        (TRC_PV_ENTRY +  6)
> +#define TRC_PV_EMULATE_4GB           (TRC_PV_ENTRY +  7)
> +#define TRC_PV_MATH_STATE_RESTORE    (TRC_PV_ENTRY +  8)
> +#define TRC_PV_PAGING_FIXUP          (TRC_PV_ENTRY +  9)
> +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10)
> +#define TRC_PV_PTWR_EMULATION        (TRC_PV_ENTRY + 11)
> +#define TRC_PV_PTWR_EMULATION_PAE    (TRC_PV_ENTRY + 12)
> +#define TRC_PV_HYPERCALL_V2          (TRC_PV_ENTRY + 13)
> +#define TRC_PV_HYPERCALL_SUBCALL     (TRC_PV_SUBCALL + 14)
> +
> +/*
> + * TRC_PV_HYPERCALL_V2 format
> + *
> + * Only some of the hypercall argument are recorded. Bit fields A0 to
> + * A5 in the first extra word are set if the argument is present and
> + * the arguments themselves are packed sequentially in the following
> + * words.
> + *
> + * The TRC_64_FLAG bit is not set for these events (even if there are
> + * 64-bit arguments in the record).
> + *
> + * Word
> + * 0    bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0
> + *          A5   |A4   |A3   |A2   |A1   |A0   |Hypercall op
> + * 1    First 32 bit (or low word of first 64 bit) arg in record
> + * 2    Second 32 bit (or high word of first 64 bit) arg in record
> + * ...
> + *
> + * A0-A5 bitfield values:
> + *
> + *   00b  Argument not present
> + *   01b  32-bit argument present
> + *   10b  64-bit argument present
> + *   11b  Reserved
> + */
> +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2<<  (20 + 2*(i)))
> +#define TRC_PV_HYPERCALL_V2_ARG_MASK  (0xfff00000)
>
>   #define TRC_SHADOW_NOT_SHADOW                 (TRC_SHADOW +  1)
>   #define TRC_SHADOW_FAST_PROPAGATE             (TRC_SHADOW +  2)
> @@ -125,6 +157,7 @@
>   #define TRC_SHADOW_RESYNC_ONLY                (TRC_SHADOW + 15)
>
>   /* trace events per subclass */
> +#define TRC_HVM_NESTEDFLAG      (0x400)
>   #define TRC_HVM_VMENTRY         (TRC_HVM_ENTRYEXIT + 0x01)
>   #define TRC_HVM_VMEXIT          (TRC_HVM_ENTRYEXIT + 0x02)
>   #define TRC_HVM_VMEXIT64        (TRC_HVM_ENTRYEXIT + TRC_64_FLAG + 0x02)
> @@ -165,6 +198,7 @@
>   #define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
>   #define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
>   #define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
> +#define TRC_HVM_VLAPIC           (TRC_HVM_HANDLER + 0x25)
>
>   #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
>   #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)
> @@ -172,8 +206,9 @@
>   /* trace events for per class */
>   #define TRC_PM_FREQ_CHANGE      (TRC_HW_PM + 0x01)
>   #define TRC_PM_IDLE_ENTRY       (TRC_HW_PM + 0x02)
> -#define TRC_PM_IDLE_EXIT        (TRC_HW_PM  + 0x03)
> +#define TRC_PM_IDLE_EXIT        (TRC_HW_PM + 0x03)
>
> +/* Trace events for IRQs */
>   #define TRC_HW_IRQ_MOVE_CLEANUP_DELAY (TRC_HW_IRQ + 0x1)
>   #define TRC_HW_IRQ_MOVE_CLEANUP       (TRC_HW_IRQ + 0x2)
>   #define TRC_HW_IRQ_BIND_VECTOR        (TRC_HW_IRQ + 0x3)
> @@ -182,12 +217,15 @@
>   #define TRC_HW_IRQ_ASSIGN_VECTOR      (TRC_HW_IRQ + 0x6)
>   #define TRC_HW_IRQ_UNMAPPED_VECTOR    (TRC_HW_IRQ + 0x7)
>   #define TRC_HW_IRQ_HANDLED            (TRC_HW_IRQ + 0x8)
> -#define TRC_HW_IRQ_MSI_WRITE          (TRC_HW_IRQ + 0x9)
> -#define TRC_HW_IRQ_MAP_PIRQ_MSI       (TRC_HW_IRQ + 0xa)
> -#define TRC_HW_IRQ_MAP_PIRQ_GSI       (TRC_HW_IRQ + 0xb)
> -#define TRC_HW_IRQ_MSI_SET_AFFINITY   (TRC_HW_IRQ + 0x10)
> -#define TRC_HW_IRQ_SET_DESC_AFFINITY  (TRC_HW_IRQ + 0x11)
> -#define TRC_HW_IRQ_IOMMU_AMD_IRE      (TRC_HW_IRQ + 0x12)
> +
> +/*
> + * Event Flags
> + *
> + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple
> + * record formats.  These event flags distinguish between the
> + * different formats.
> + */
> +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */
>
>   /* This structure represents a single trace buffer record. */
>   struct t_rec {
> @@ -205,6 +243,34 @@ struct t_rec {
>       } u;
>   };
>
> +/*
> + * This structure contains the metadata for a single trace buffer.  The head
> + * field, indexes into an array of struct t_rec's.
> + */
> +struct t_buf {
> +    /* Assume the data buffer size is X.  X is generally not a power of 2.
> +     * CONS and PROD are incremented modulo (2*X):
> +     *     0<= cons<  2*X
> +     *     0<= prod<  2*X
> +     * This is done because addition modulo X breaks at 2^32 when X is not a
> +     * power of 2:
> +     *     (((2^32 - 1) % X) + 1) % X != (2^32) % X
> +     */
> +    uint32_t cons;   /* Offset of next item to be consumed by control tools. */
> +    uint32_t prod;   /* Offset of next item to be produced by Xen.           */
> +    /*  Records follow immediately after the meta-data header.    */
> +};
> +
> +/* Structure used to pass MFNs to the trace buffers back to trace consumers.
> + * Offset is an offset into the mapped structure where the mfn list will be held.
> + * MFNs will be at ((unsigned long *)(t_info))+(t_info->cpu_offset[cpu]).
> + */
> +struct t_info {
> +    uint16_t tbuf_size; /* Size in pages of each trace buffer */
> +    uint16_t mfn_offset[];  /* Offset within t_info structure of the page list per cpu */
> +    /* MFN lists immediately after the header */
> +};
> +
>   #endif /* __XEN_PUBLIC_TRACE_H__ */
>
>   /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:18:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:18: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 1ScZnT-0001qN-IE; Thu, 07 Jun 2012 10:18:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScZnR-0001pu-Pc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:18:29 +0000
Received: from [193.109.254.147:24815] by server-12.bemta-14.messagelabs.com
	id 86/BF-12998-4FF70DF4; Thu, 07 Jun 2012 10:18:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339064307!8406826!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16014 invoked from network); 7 Jun 2012 10:18:28 -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; 7 Jun 2012 10:18:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZnO-000Ig3-FS; Thu, 07 Jun 2012 10:18:26 +0000
Date: Thu, 7 Jun 2012 11:18:26 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607101826.GJ70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
	<20120607092951.GE70339@ocelot.phlegethon.org>
	<1339061691.15265.49.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339061691.15265.49.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:34 +0100 on 07 Jun (1339065291), Ian Campbell wrote:
> On Thu, 2012-06-07 at 10:29 +0100, Tim Deegan wrote:
> > > +int domain_uart0_init(struct domain *d)
> > > +{
> > > +    int rc;
> > > +    if ( d->domain_id == 0 )
> > > +        return 0;
> > 
> > Why?  There's no equivalent gate on the MMIO handlers.
> 
> dom0 has the actual uart mapped at this address, not the emulated one.
> Maybe that should be written at the caller instead?

Yes - ideally in the same place that puts the MMIO hooks in that will
call the other functions in this file. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:18:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:18: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 1ScZnT-0001qN-IE; Thu, 07 Jun 2012 10:18:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1ScZnR-0001pu-Pc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:18:29 +0000
Received: from [193.109.254.147:24815] by server-12.bemta-14.messagelabs.com
	id 86/BF-12998-4FF70DF4; Thu, 07 Jun 2012 10:18:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339064307!8406826!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16014 invoked from network); 7 Jun 2012 10:18:28 -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; 7 Jun 2012 10:18:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZnO-000Ig3-FS; Thu, 07 Jun 2012 10:18:26 +0000
Date: Thu, 7 Jun 2012 11:18:26 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607101826.GJ70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
	<20120607092951.GE70339@ocelot.phlegethon.org>
	<1339061691.15265.49.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339061691.15265.49.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:34 +0100 on 07 Jun (1339065291), Ian Campbell wrote:
> On Thu, 2012-06-07 at 10:29 +0100, Tim Deegan wrote:
> > > +int domain_uart0_init(struct domain *d)
> > > +{
> > > +    int rc;
> > > +    if ( d->domain_id == 0 )
> > > +        return 0;
> > 
> > Why?  There's no equivalent gate on the MMIO handlers.
> 
> dom0 has the actual uart mapped at this address, not the emulated one.
> Maybe that should be written at the caller instead?

Yes - ideally in the same place that puts the MMIO hooks in that will
call the other functions in this file. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:18:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:18: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 1ScZnS-0001q5-1d; Thu, 07 Jun 2012 10:18:30 +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 1ScZnQ-0001pi-HQ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:18:28 +0000
Received: from [85.158.138.51:32952] by server-3.bemta-3.messagelabs.com id
	A4/C1-25608-3FF70DF4; Thu, 07 Jun 2012 10:18:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339064305!31260186!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19867 invoked from network); 7 Jun 2012 10:18:27 -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;
	7 Jun 2012 10:18:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27181004"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:18:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 06:18:25 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScZnM-0005SE-S4;
	Thu, 07 Jun 2012 11:18:24 +0100
Message-ID: <4FD07F83.3020401@eu.citrix.com>
Date: Thu, 7 Jun 2012 11:16:35 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<9077510f38f6bdaee32e.1338462981@qabil.uk.xensource.com>
In-Reply-To: <9077510f38f6bdaee32e.1338462981@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10] xenalyze: correctly display of
	count of HW 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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> HW events where being shown under "(null)" in the summary.
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -1805,7 +1805,8 @@ enum {
>       TOPLEVEL_MEM,
>       TOPLEVEL_PV,
>       TOPLEVEL_SHADOW,
> -    TOPLEVEL_MAX=12
> +    TOPLEVEL_HW,
> +    TOPLEVEL_MAX=TOPLEVEL_HW+1,
>   };
>
>   char * toplevel_name[TOPLEVEL_MAX] = {
> @@ -1816,6 +1817,7 @@ char * toplevel_name[TOPLEVEL_MAX] = {
>       [TOPLEVEL_MEM]="mem",
>       [TOPLEVEL_PV]="pv",
>       [TOPLEVEL_SHADOW]="shadow",
> +    [TOPLEVEL_HW]="hw",
>   };
>
>   struct trace_volume {
> @@ -8595,7 +8597,6 @@ void process_cpu_change(struct pcpu_info
>       }
>   }
>
> -#define TOPLEVEL_MAX 16
>   struct tl_assert_mask {
>       unsigned p_current:1,
>           not_idle_domain:1;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:18:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:18: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 1ScZnS-0001q5-1d; Thu, 07 Jun 2012 10:18:30 +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 1ScZnQ-0001pi-HQ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:18:28 +0000
Received: from [85.158.138.51:32952] by server-3.bemta-3.messagelabs.com id
	A4/C1-25608-3FF70DF4; Thu, 07 Jun 2012 10:18:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339064305!31260186!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19867 invoked from network); 7 Jun 2012 10:18:27 -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;
	7 Jun 2012 10:18:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27181004"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 06:18:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 06:18:25 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScZnM-0005SE-S4;
	Thu, 07 Jun 2012 11:18:24 +0100
Message-ID: <4FD07F83.3020401@eu.citrix.com>
Date: Thu, 7 Jun 2012 11:16:35 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<9077510f38f6bdaee32e.1338462981@qabil.uk.xensource.com>
In-Reply-To: <9077510f38f6bdaee32e.1338462981@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10] xenalyze: correctly display of
	count of HW 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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> HW events where being shown under "(null)" in the summary.
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -1805,7 +1805,8 @@ enum {
>       TOPLEVEL_MEM,
>       TOPLEVEL_PV,
>       TOPLEVEL_SHADOW,
> -    TOPLEVEL_MAX=12
> +    TOPLEVEL_HW,
> +    TOPLEVEL_MAX=TOPLEVEL_HW+1,
>   };
>
>   char * toplevel_name[TOPLEVEL_MAX] = {
> @@ -1816,6 +1817,7 @@ char * toplevel_name[TOPLEVEL_MAX] = {
>       [TOPLEVEL_MEM]="mem",
>       [TOPLEVEL_PV]="pv",
>       [TOPLEVEL_SHADOW]="shadow",
> +    [TOPLEVEL_HW]="hw",
>   };
>
>   struct trace_volume {
> @@ -8595,7 +8597,6 @@ void process_cpu_change(struct pcpu_info
>       }
>   }
>
> -#define TOPLEVEL_MAX 16
>   struct tl_assert_mask {
>       unsigned p_current:1,
>           not_idle_domain:1;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScZpD-00027g-2W; Thu, 07 Jun 2012 10:20: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 1ScZpA-00026d-Ra
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:20:16 +0000
Received: from [85.158.138.51:62082] by server-6.bemta-3.messagelabs.com id
	11/54-05063-F5080DF4; Thu, 07 Jun 2012 10:20:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339064415!27186337!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29660 invoked from network); 7 Jun 2012 10:20:15 -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; 7 Jun 2012 10:20:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZp8-000Igb-Kv; Thu, 07 Jun 2012 10:20:14 +0000
Date: Thu, 7 Jun 2012 11:20:14 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102014.GK70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-30-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-30-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 30/38] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0000 on 01 Jun (1338565199), Ian Campbell wrote:
> Upgrading barriers is conservative and may not be necessary.
> 
> Protected Table Walk traps stage 1 page tables which refer to device memory
> (per stage 2) using a non-device mapping. This generally indicates a guest
> error but trapping it as a fault for now helps us know if something odd is
> going on.
> 
> 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 Jun 07 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScZpD-00027g-2W; Thu, 07 Jun 2012 10:20: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 1ScZpA-00026d-Ra
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:20:16 +0000
Received: from [85.158.138.51:62082] by server-6.bemta-3.messagelabs.com id
	11/54-05063-F5080DF4; Thu, 07 Jun 2012 10:20:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339064415!27186337!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29660 invoked from network); 7 Jun 2012 10:20:15 -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; 7 Jun 2012 10:20:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZp8-000Igb-Kv; Thu, 07 Jun 2012 10:20:14 +0000
Date: Thu, 7 Jun 2012 11:20:14 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102014.GK70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-30-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-30-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 30/38] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0000 on 01 Jun (1338565199), Ian Campbell wrote:
> Upgrading barriers is conservative and may not be necessary.
> 
> Protected Table Walk traps stage 1 page tables which refer to device memory
> (per stage 2) using a non-device mapping. This generally indicates a guest
> error but trapping it as a fault for now helps us know if something odd is
> going on.
> 
> 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 Jun 07 10:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZpo-0002DS-GK; Thu, 07 Jun 2012 10:20:56 +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 1ScZpn-0002DD-Sk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:20:55 +0000
Received: from [85.158.138.51:12709] by server-9.bemta-3.messagelabs.com id
	18/EA-15054-78080DF4; Thu, 07 Jun 2012 10:20:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339064454!24881695!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1987 invoked from network); 7 Jun 2012 10:20:54 -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 Jun 2012 10:20:54 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZpm-000Ih7-2L; Thu, 07 Jun 2012 10:20:54 +0000
Date: Thu, 7 Jun 2012 11:20:54 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102054.GL70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
	interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 01 Jun (1338565200), Ian Campbell wrote:
> In particular it is taken by gic_set_guest_irq which is called by
> vgic_vcpu_inject_irq
> 
> 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 Jun 07 10:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZpo-0002DS-GK; Thu, 07 Jun 2012 10:20:56 +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 1ScZpn-0002DD-Sk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:20:55 +0000
Received: from [85.158.138.51:12709] by server-9.bemta-3.messagelabs.com id
	18/EA-15054-78080DF4; Thu, 07 Jun 2012 10:20:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339064454!24881695!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1987 invoked from network); 7 Jun 2012 10:20:54 -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 Jun 2012 10:20:54 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZpm-000Ih7-2L; Thu, 07 Jun 2012 10:20:54 +0000
Date: Thu, 7 Jun 2012 11:20:54 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102054.GL70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
	interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 01 Jun (1338565200), Ian Campbell wrote:
> In particular it is taken by gic_set_guest_irq which is called by
> vgic_vcpu_inject_irq
> 
> 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 Jun 07 10:22:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZqk-0002Ne-Uq; Thu, 07 Jun 2012 10:21: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 1ScZqj-0002N7-Ku
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:21:53 +0000
Received: from [85.158.143.99:55241] by server-1.bemta-4.messagelabs.com id
	45/16-10042-0C080DF4; Thu, 07 Jun 2012 10:21:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339064511!30824770!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31372 invoked from network); 7 Jun 2012 10:21:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 10:21:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZqh-000IhW-Mm; Thu, 07 Jun 2012 10:21:51 +0000
Date: Thu, 7 Jun 2012 11:21:51 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102151.GM70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-32-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-32-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 32/38] arm: context switch virtual timer
	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:40 +0000 on 01 Jun (1338565201), 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 Jun 07 10:22:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZqk-0002Ne-Uq; Thu, 07 Jun 2012 10:21: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 1ScZqj-0002N7-Ku
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:21:53 +0000
Received: from [85.158.143.99:55241] by server-1.bemta-4.messagelabs.com id
	45/16-10042-0C080DF4; Thu, 07 Jun 2012 10:21:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339064511!30824770!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31372 invoked from network); 7 Jun 2012 10:21:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 10:21:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZqh-000IhW-Mm; Thu, 07 Jun 2012 10:21:51 +0000
Date: Thu, 7 Jun 2012 11:21:51 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102151.GM70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-32-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-32-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 32/38] arm: context switch virtual timer
	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:40 +0000 on 01 Jun (1338565201), 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 Jun 07 10:22:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:22: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 1ScZrG-0002Tv-Ch; Thu, 07 Jun 2012 10:22:26 +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 1ScZrE-0002Ta-Nf
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:22:24 +0000
Received: from [85.158.143.99:59523] by server-1.bemta-4.messagelabs.com id
	28/F6-10042-FD080DF4; Thu, 07 Jun 2012 10:22:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339064542!25169661!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21794 invoked from network); 7 Jun 2012 10:22:23 -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; 7 Jun 2012 10:22:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZrC-000Ii1-LV; Thu, 07 Jun 2012 10:22:22 +0000
Date: Thu, 7 Jun 2012 11:22:22 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102222.GN70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-33-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-33-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 33/38] arm: the hyp timer seems to work now,
	default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:40 +0000 on 01 Jun (1338565202), 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 Jun 07 10:22:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:22: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 1ScZrG-0002Tv-Ch; Thu, 07 Jun 2012 10:22:26 +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 1ScZrE-0002Ta-Nf
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:22:24 +0000
Received: from [85.158.143.99:59523] by server-1.bemta-4.messagelabs.com id
	28/F6-10042-FD080DF4; Thu, 07 Jun 2012 10:22:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339064542!25169661!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21794 invoked from network); 7 Jun 2012 10:22:23 -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; 7 Jun 2012 10:22:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZrC-000Ii1-LV; Thu, 07 Jun 2012 10:22:22 +0000
Date: Thu, 7 Jun 2012 11:22:22 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102222.GN70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-33-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-33-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 33/38] arm: the hyp timer seems to work now,
	default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:40 +0000 on 01 Jun (1338565202), 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 Jun 07 10:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZs6-0002d7-Qi; Thu, 07 Jun 2012 10:23: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 1ScZs5-0002cm-Ct
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:23:17 +0000
Received: from [85.158.139.83:42575] by server-11.bemta-5.messagelabs.com id
	23/24-25194-41180DF4; Thu, 07 Jun 2012 10:23:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339064595!18583665!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14005 invoked from network); 7 Jun 2012 10:23:15 -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; 7 Jun 2012 10:23:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZs3-000IiW-Dk; Thu, 07 Jun 2012 10:23:15 +0000
Date: Thu, 7 Jun 2012 11:23:15 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102315.GO70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-35-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-35-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 35/38] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 01 Jun (1338565204), 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 Jun 07 10:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScZs6-0002d7-Qi; Thu, 07 Jun 2012 10:23: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 1ScZs5-0002cm-Ct
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:23:17 +0000
Received: from [85.158.139.83:42575] by server-11.bemta-5.messagelabs.com id
	23/24-25194-41180DF4; Thu, 07 Jun 2012 10:23:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339064595!18583665!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14005 invoked from network); 7 Jun 2012 10:23:15 -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; 7 Jun 2012 10:23:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScZs3-000IiW-Dk; Thu, 07 Jun 2012 10:23:15 +0000
Date: Thu, 7 Jun 2012 11:23:15 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120607102315.GO70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-35-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338565207-2888-35-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 35/38] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 01 Jun (1338565204), 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 Jun 07 10:27:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:27: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 1ScZvv-0002zV-G0; Thu, 07 Jun 2012 10:27: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 1ScZvt-0002zM-Vi
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:27:14 +0000
Received: from [85.158.138.51:64123] by server-2.bemta-3.messagelabs.com id
	00/35-16299-10280DF4; Thu, 07 Jun 2012 10:27:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339064832!28367720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3501 invoked from network); 7 Jun 2012 10:27:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:27:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12877643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:27:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:27:11 +0100
Date: Thu, 7 Jun 2012 11:26:55 +0100
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: <1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071126490.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-26-git-send-email-ian.campbell@citrix.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] [PATCH 26/38] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> For some reason we were holding the lock over only the unmaps at the end of
> the function, rather than for the whole walk.
> 
> We might want to be more clever in the future, but for now lets just lock for
> the whole walk+create process.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/p2m.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 46c6f17..c4daf83 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -168,6 +168,8 @@ static int create_p2m_entries(struct domain *d,
>      paddr_t addr;
>      unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
>  
> +    spin_lock(&p2m->lock);
> +
>      /* XXX Don't actually handle 40 bit guest physical addresses */
>      BUG_ON(start_gpaddr & 0x8000000000ULL);
>      BUG_ON(end_gpaddr   & 0x8000000000ULL);
> @@ -249,8 +251,6 @@ static int create_p2m_entries(struct domain *d,
>      rc = 0;
>  
>  out:
> -    spin_lock(&p2m->lock);
> -
>      if (third) unmap_domain_page(third);
>      if (second) unmap_domain_page(second);
>      if (first) unmap_domain_page(first);
> -- 
> 1.7.9.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 Thu Jun 07 10:27:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:27: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 1ScZvv-0002zV-G0; Thu, 07 Jun 2012 10:27: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 1ScZvt-0002zM-Vi
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:27:14 +0000
Received: from [85.158.138.51:64123] by server-2.bemta-3.messagelabs.com id
	00/35-16299-10280DF4; Thu, 07 Jun 2012 10:27:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339064832!28367720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3501 invoked from network); 7 Jun 2012 10:27:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:27:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12877643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:27:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:27:11 +0100
Date: Thu, 7 Jun 2012 11:26:55 +0100
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: <1338565207-2888-26-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071126490.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-26-git-send-email-ian.campbell@citrix.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] [PATCH 26/38] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 1 Jun 2012, Ian Campbell wrote:
> For some reason we were holding the lock over only the unmaps at the end of
> the function, rather than for the whole walk.
> 
> We might want to be more clever in the future, but for now lets just lock for
> the whole walk+create process.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/p2m.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 46c6f17..c4daf83 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -168,6 +168,8 @@ static int create_p2m_entries(struct domain *d,
>      paddr_t addr;
>      unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
>  
> +    spin_lock(&p2m->lock);
> +
>      /* XXX Don't actually handle 40 bit guest physical addresses */
>      BUG_ON(start_gpaddr & 0x8000000000ULL);
>      BUG_ON(end_gpaddr   & 0x8000000000ULL);
> @@ -249,8 +251,6 @@ static int create_p2m_entries(struct domain *d,
>      rc = 0;
>  
>  out:
> -    spin_lock(&p2m->lock);
> -
>      if (third) unmap_domain_page(third);
>      if (second) unmap_domain_page(second);
>      if (first) unmap_domain_page(first);
> -- 
> 1.7.9.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 Thu Jun 07 10:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1Sca34-0003CB-I4; Thu, 07 Jun 2012 10:34:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1Sca32-0003C6-EK
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:34:36 +0000
Received: from [85.158.143.99:21625] by server-3.bemta-4.messagelabs.com id
	12/2D-29237-BB380DF4; Thu, 07 Jun 2012 10:34:35 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339065274!28348303!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15017 invoked from network); 7 Jun 2012 10:34:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	7 Jun 2012 10:34:34 -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 q57AXvSF005056
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 06:33:58 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q57AXuCb023315; Thu, 7 Jun 2012 06:33:57 -0400
Date: Thu, 7 Jun 2012 12:33:55 +0200
From: Andrea Arcangeli <aarcange@redhat.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Message-ID: <20120607103355.GA21339@redhat.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607073333.GF3210@burratino>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Sergio Gelato <Sergio.Gelato@astro.su.se>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote:
> Sergio Gelato wrote[1]:
> 
> >                          That 3.4.1-1~experimental.1 build
> > (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux)
> > is even less well-behaved under Xen: I'm getting a kernel OOPS at
> > EIP: [<c1168e54>] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c
> > The top of the trace message unfortunately scrolled off the console before I
> > could see it, and the message doesn't have time to make it to syslog (either
> > local or remote).
> [...]
> > Non-Xen boots proceed normally.
> 
> Yeah, apparently[2] that's caused by
> 
> 	commit 26c191788f18
> 	Author: Andrea Arcangeli <aarcange@redhat.com>
> 	Date:   Tue May 29 15:06:49 2012 -0700
> 
> 	    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
> 
> which was also included in Debian kernel 3.2.19-1.
> 
> [1] http://bugs.debian.org/676360
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4

Oops, sorry I didn't imagine atomic64_read on a pmd would trip.

Unfortunately to support pagetable walking with mmap_sem hold for
reading, we need an atomic read on 32bit PAE if
CONFIG_TRANSPARENT_HUGEPAGE=y.

The only case requiring this is 32bit PAE with
CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set
CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work
around this as I optimized the code in a way to avoid an expensive
cmpxchg8b.

I guess if Xen can't be updated to handle an atomic64_read on a pmd in
the guest, we can add a pmd_read paravirt op? Or if we don't want to
break the paravirt interface a loop like gup_fast with irq disabled
should also work but looping + local_irq_disable()/enable() sounded
worse and more complex than a atomic64_read (gup fast already disables
irqs because it doesn't hold the mmap_sem so it's a different cost
looping there). AFIK Xen disables THP during boot, so a check on THP
being enabled and falling back in the THP=n version of
pmd_read_atomic, would also be safe, but it's not so nice to do it
with a runtime check.

Thanks,
Andrea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1Sca34-0003CB-I4; Thu, 07 Jun 2012 10:34:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1Sca32-0003C6-EK
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:34:36 +0000
Received: from [85.158.143.99:21625] by server-3.bemta-4.messagelabs.com id
	12/2D-29237-BB380DF4; Thu, 07 Jun 2012 10:34:35 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339065274!28348303!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15017 invoked from network); 7 Jun 2012 10:34:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	7 Jun 2012 10:34:34 -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 q57AXvSF005056
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 06:33:58 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q57AXuCb023315; Thu, 7 Jun 2012 06:33:57 -0400
Date: Thu, 7 Jun 2012 12:33:55 +0200
From: Andrea Arcangeli <aarcange@redhat.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Message-ID: <20120607103355.GA21339@redhat.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607073333.GF3210@burratino>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Sergio Gelato <Sergio.Gelato@astro.su.se>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote:
> Sergio Gelato wrote[1]:
> 
> >                          That 3.4.1-1~experimental.1 build
> > (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux)
> > is even less well-behaved under Xen: I'm getting a kernel OOPS at
> > EIP: [<c1168e54>] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c
> > The top of the trace message unfortunately scrolled off the console before I
> > could see it, and the message doesn't have time to make it to syslog (either
> > local or remote).
> [...]
> > Non-Xen boots proceed normally.
> 
> Yeah, apparently[2] that's caused by
> 
> 	commit 26c191788f18
> 	Author: Andrea Arcangeli <aarcange@redhat.com>
> 	Date:   Tue May 29 15:06:49 2012 -0700
> 
> 	    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
> 
> which was also included in Debian kernel 3.2.19-1.
> 
> [1] http://bugs.debian.org/676360
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4

Oops, sorry I didn't imagine atomic64_read on a pmd would trip.

Unfortunately to support pagetable walking with mmap_sem hold for
reading, we need an atomic read on 32bit PAE if
CONFIG_TRANSPARENT_HUGEPAGE=y.

The only case requiring this is 32bit PAE with
CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set
CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work
around this as I optimized the code in a way to avoid an expensive
cmpxchg8b.

I guess if Xen can't be updated to handle an atomic64_read on a pmd in
the guest, we can add a pmd_read paravirt op? Or if we don't want to
break the paravirt interface a loop like gup_fast with irq disabled
should also work but looping + local_irq_disable()/enable() sounded
worse and more complex than a atomic64_read (gup fast already disables
irqs because it doesn't hold the mmap_sem so it's a different cost
looping there). AFIK Xen disables THP during boot, so a check on THP
being enabled and falling back in the THP=n version of
pmd_read_atomic, would also be safe, but it's not so nice to do it
with a runtime check.

Thanks,
Andrea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:35:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:35: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 1Sca3u-0003HI-Vo; Thu, 07 Jun 2012 10:35: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 1Sca3t-0003Gt-DZ
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:35:29 +0000
Received: from [85.158.143.99:29188] by server-3.bemta-4.messagelabs.com id
	DA/CE-29237-0F380DF4; Thu, 07 Jun 2012 10:35:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339065327!28348489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18009 invoked from network); 7 Jun 2012 10:35:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:35:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12877844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:35:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:35:27 +0100
Date: Thu, 7 Jun 2012 11:35:10 +0100
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: <1338565207-2888-27-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071131370.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-27-git-send-email-ian.campbell@citrix.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] [PATCH 27/38] arm: split pending SPIs (global) out
 from pending PPIs and SGIs (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

On Fri, 1 Jun 2012, Ian Campbell wrote:
> This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
> seems more logical.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/vgic.c          |   17 ++++++++++-------
>  xen/include/asm-arm/domain.h |   10 ++++++++++
>  2 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 629a0da..91d6166 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
>      d->arch.vgic.shared_irqs =
>          xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      d->arch.vgic.pending_irqs =
> -        xmalloc_array(struct pending_irq,
> -                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
> -    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
> +        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> +    for (i=0; i<d->arch.vgic.nr_lines; i++)
>          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
>      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
>          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> @@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
>  
>      spin_lock_init(&v->arch.vgic.private_irqs.lock);
>  
> +    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> +    for (i = 0; i < 32; i++)
> +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> +
>      /* For SGI and PPI the target is always this CPU */
>      for ( i = 0 ; i < 8 ; i++ )
>          v->arch.vgic.private_irqs.itargets[i] =
> @@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>      /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
>       * are used for SPIs; the rests are used for per cpu irqs */
>      if ( irq < 32 )
> -        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
> -            + v->domain->arch.vgic.nr_lines];
> +        n = &v->arch.vgic.pending_irqs[irq];
>      else
>          n = &v->domain->arch.vgic.pending_irqs[irq - 32];
>      return n;
> @@ -548,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      uint8_t priority;
>      struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
>      struct pending_irq *iter, *n = irq_to_pending(v, irq);
> +    unsigned long flags;
>  
>      /* irq still pending */
>      if (!list_empty(&n->inflight))
> @@ -564,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>  
>      gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
>  
> -    spin_lock(&v->arch.vgic.lock);
> +    spin_lock_irqsave(&v->arch.vgic.lock, flags);
>      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
>      {
>          if ( iter->priority > priority )
> @@ -575,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>          }
>      }
>      list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
> -    spin_unlock(&v->arch.vgic.lock);
> +    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>      /* we have a new higher priority irq, inject it into the guest */
>  }

Besides moving PPIs and SGIs to struct vcpu, this patch also turns
spin_lock into spin_lock_irqsave in vgic_vcpu_inject_irq: I think it is
correct because it can be called in IRQ context, but it needs to be
explicitly stated in the commit message.


> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 620b26e..32deb52 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -46,6 +46,10 @@ struct arch_domain
>          int ctlr;
>          int nr_lines;
>          struct vgic_irq_rank *shared_irqs;
> +        /*
> +         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
> +         * struct arch_vcpu.
> +         */
>          struct pending_irq *pending_irqs;
>      } vgic;
>  
> @@ -114,7 +118,13 @@ struct arch_vcpu
>      uint32_t gic_lr[64];
>  
>      struct {
> +        /*
> +         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
> +         * struct arch_domain.
> +         */
> +        struct pending_irq pending_irqs[32];
>          struct vgic_irq_rank private_irqs;
> +
>          /* This list is ordered by IRQ priority and it is used to keep
>           * track of the IRQs that the VGIC injected into the guest.
>           * Depending on the availability of LR registers, the IRQs might
> -- 
> 1.7.9.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 Thu Jun 07 10:35:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:35: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 1Sca3u-0003HI-Vo; Thu, 07 Jun 2012 10:35: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 1Sca3t-0003Gt-DZ
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:35:29 +0000
Received: from [85.158.143.99:29188] by server-3.bemta-4.messagelabs.com id
	DA/CE-29237-0F380DF4; Thu, 07 Jun 2012 10:35:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339065327!28348489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18009 invoked from network); 7 Jun 2012 10:35:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:35:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12877844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:35:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:35:27 +0100
Date: Thu, 7 Jun 2012 11:35:10 +0100
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: <1338565207-2888-27-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071131370.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-27-git-send-email-ian.campbell@citrix.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] [PATCH 27/38] arm: split pending SPIs (global) out
 from pending PPIs and SGIs (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

On Fri, 1 Jun 2012, Ian Campbell wrote:
> This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
> seems more logical.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/vgic.c          |   17 ++++++++++-------
>  xen/include/asm-arm/domain.h |   10 ++++++++++
>  2 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 629a0da..91d6166 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
>      d->arch.vgic.shared_irqs =
>          xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      d->arch.vgic.pending_irqs =
> -        xmalloc_array(struct pending_irq,
> -                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
> -    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
> +        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> +    for (i=0; i<d->arch.vgic.nr_lines; i++)
>          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
>      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
>          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> @@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
>  
>      spin_lock_init(&v->arch.vgic.private_irqs.lock);
>  
> +    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> +    for (i = 0; i < 32; i++)
> +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> +
>      /* For SGI and PPI the target is always this CPU */
>      for ( i = 0 ; i < 8 ; i++ )
>          v->arch.vgic.private_irqs.itargets[i] =
> @@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>      /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
>       * are used for SPIs; the rests are used for per cpu irqs */
>      if ( irq < 32 )
> -        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
> -            + v->domain->arch.vgic.nr_lines];
> +        n = &v->arch.vgic.pending_irqs[irq];
>      else
>          n = &v->domain->arch.vgic.pending_irqs[irq - 32];
>      return n;
> @@ -548,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      uint8_t priority;
>      struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
>      struct pending_irq *iter, *n = irq_to_pending(v, irq);
> +    unsigned long flags;
>  
>      /* irq still pending */
>      if (!list_empty(&n->inflight))
> @@ -564,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>  
>      gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
>  
> -    spin_lock(&v->arch.vgic.lock);
> +    spin_lock_irqsave(&v->arch.vgic.lock, flags);
>      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
>      {
>          if ( iter->priority > priority )
> @@ -575,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>          }
>      }
>      list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
> -    spin_unlock(&v->arch.vgic.lock);
> +    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>      /* we have a new higher priority irq, inject it into the guest */
>  }

Besides moving PPIs and SGIs to struct vcpu, this patch also turns
spin_lock into spin_lock_irqsave in vgic_vcpu_inject_irq: I think it is
correct because it can be called in IRQ context, but it needs to be
explicitly stated in the commit message.


> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 620b26e..32deb52 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -46,6 +46,10 @@ struct arch_domain
>          int ctlr;
>          int nr_lines;
>          struct vgic_irq_rank *shared_irqs;
> +        /*
> +         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
> +         * struct arch_vcpu.
> +         */
>          struct pending_irq *pending_irqs;
>      } vgic;
>  
> @@ -114,7 +118,13 @@ struct arch_vcpu
>      uint32_t gic_lr[64];
>  
>      struct {
> +        /*
> +         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
> +         * struct arch_domain.
> +         */
> +        struct pending_irq pending_irqs[32];
>          struct vgic_irq_rank private_irqs;
> +
>          /* This list is ordered by IRQ priority and it is used to keep
>           * track of the IRQs that the VGIC injected into the guest.
>           * Depending on the availability of LR registers, the IRQs might
> -- 
> 1.7.9.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 Thu Jun 07 10:39:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Sca7x-0003aN-KY; Thu, 07 Jun 2012 10:39: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 1Sca7v-0003aG-VV
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:39:40 +0000
Received: from [85.158.139.83:30939] by server-9.bemta-5.messagelabs.com id
	15/BA-29678-BE480DF4; Thu, 07 Jun 2012 10:39:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339065578!30908547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12602 invoked from network); 7 Jun 2012 10:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12877972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:39:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:39:38 +0100
Date: Thu, 7 Jun 2012 11:39:22 +0100
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: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071138250.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.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] [PATCH 28/38] arm: map GICV in all domains,
 not just 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 Fri, 1 Jun 2012, Ian Campbell wrote:
> This requires that we allocate all p2m pages from domheap without a particular
> dom because max pages is not setup yet so there is no allocation available to
> us.
> 
> At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.
> 
> Also we seem to have been calling p2m_alloc_table twice for dom0.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c       |   10 +++++++---
>  xen/arch/arm/domain_build.c |    5 -----
>  xen/arch/arm/gic.c          |    9 ++++-----
>  xen/arch/arm/gic.h          |    2 +-
>  xen/arch/arm/p2m.c          |    3 ++-
>  5 files changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index a7fb227..e15c1e8 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>  
>          if ( (rc = p2m_alloc_table(d)) != 0 )
>              goto fail;
> -    }
>  
> -    if ( (rc = domain_vgic_init(d)) != 0 )
> -        goto fail;
> +        if ( (rc = gicv_setup(d)) != 0 )
> +            goto fail;
> +
> +        if ( (rc = domain_vgic_init(d)) != 0 )
> +            goto fail;
> +    }
>  
>      rc = 0;
>  fail:
> +    /*XXX unwind allocations etc */
>      return rc;
>  }
>  
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 72e775c..1b19e54 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
>  
>      d->max_pages = ~0U;
>  
> -    if ( (rc = p2m_alloc_table(d)) != 0 )
> -        return rc;
> -
>      rc = prepare_dtb(d, &kinfo);
>      if ( rc < 0 )
>          return rc;
> @@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
>      printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
>      map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
>  
> -    gicv_setup(d);
> -
>      printk("Routing peripheral interrupts to guest\n");
>      /* TODO Get from device tree */
>      gic_route_irq_to_guest(d, 34, "timer0");
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 339c327..a398f92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -541,14 +541,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>      do_IRQ(regs, irq, is_fiq);
>  }
>  
> -void gicv_setup(struct domain *d)
> +int gicv_setup(struct domain *d)
>  {
> +    printk("GICV setup for DOM%d\n", d->domain_id);
> +
>      /* map the gic virtual cpu interface in the gic cpu interface region of
>       * the guest */
> -    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
> -           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
> -           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
> -    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
> +    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
>                          GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
>                          GIC_BASE_ADDRESS + GIC_VR_OFFSET);
>  }
> diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
> index ac9cf3a..018d820 100644
> --- a/xen/arch/arm/gic.h
> +++ b/xen/arch/arm/gic.h
> @@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
>  /* Take down a CPU's per-CPU GIC interface */
>  extern void gic_disable_cpu(void);
>  /* setup the gic virtual interface for a guest */
> -extern void gicv_setup(struct domain *d);
> +extern int gicv_setup(struct domain *d);
>  
>  /* Context switch */
>  extern void gic_save_state(struct vcpu *v);
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index c4daf83..0665445 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -4,6 +4,7 @@
>  #include <xen/errno.h>
>  #include <xen/domain_page.h>
>  #include <asm/flushtlb.h>
> +#include "gic.h"
>  
>  void dump_p2m_lookup(struct domain *d, paddr_t addr)
>  {
> @@ -138,7 +139,7 @@ static int p2m_create_entry(struct domain *d,
>  
>      BUG_ON(entry->p2m.valid);
>  
> -    page = alloc_domheap_page(d, 0);
> +    page = alloc_domheap_page(NULL, 0);
>      if ( page == NULL )
>          return -ENOMEM;
>  
> -- 
> 1.7.9.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 Thu Jun 07 10:39:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Sca7x-0003aN-KY; Thu, 07 Jun 2012 10:39: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 1Sca7v-0003aG-VV
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:39:40 +0000
Received: from [85.158.139.83:30939] by server-9.bemta-5.messagelabs.com id
	15/BA-29678-BE480DF4; Thu, 07 Jun 2012 10:39:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339065578!30908547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12602 invoked from network); 7 Jun 2012 10:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12877972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:39:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:39:38 +0100
Date: Thu, 7 Jun 2012 11:39:22 +0100
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: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071138250.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.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] [PATCH 28/38] arm: map GICV in all domains,
 not just 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 Fri, 1 Jun 2012, Ian Campbell wrote:
> This requires that we allocate all p2m pages from domheap without a particular
> dom because max pages is not setup yet so there is no allocation available to
> us.
> 
> At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.
> 
> Also we seem to have been calling p2m_alloc_table twice for dom0.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c       |   10 +++++++---
>  xen/arch/arm/domain_build.c |    5 -----
>  xen/arch/arm/gic.c          |    9 ++++-----
>  xen/arch/arm/gic.h          |    2 +-
>  xen/arch/arm/p2m.c          |    3 ++-
>  5 files changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index a7fb227..e15c1e8 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>  
>          if ( (rc = p2m_alloc_table(d)) != 0 )
>              goto fail;
> -    }
>  
> -    if ( (rc = domain_vgic_init(d)) != 0 )
> -        goto fail;
> +        if ( (rc = gicv_setup(d)) != 0 )
> +            goto fail;
> +
> +        if ( (rc = domain_vgic_init(d)) != 0 )
> +            goto fail;
> +    }
>  
>      rc = 0;
>  fail:
> +    /*XXX unwind allocations etc */
>      return rc;
>  }
>  
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 72e775c..1b19e54 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
>  
>      d->max_pages = ~0U;
>  
> -    if ( (rc = p2m_alloc_table(d)) != 0 )
> -        return rc;
> -
>      rc = prepare_dtb(d, &kinfo);
>      if ( rc < 0 )
>          return rc;
> @@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
>      printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
>      map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
>  
> -    gicv_setup(d);
> -
>      printk("Routing peripheral interrupts to guest\n");
>      /* TODO Get from device tree */
>      gic_route_irq_to_guest(d, 34, "timer0");
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 339c327..a398f92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -541,14 +541,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>      do_IRQ(regs, irq, is_fiq);
>  }
>  
> -void gicv_setup(struct domain *d)
> +int gicv_setup(struct domain *d)
>  {
> +    printk("GICV setup for DOM%d\n", d->domain_id);
> +
>      /* map the gic virtual cpu interface in the gic cpu interface region of
>       * the guest */
> -    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
> -           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
> -           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
> -    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
> +    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
>                          GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
>                          GIC_BASE_ADDRESS + GIC_VR_OFFSET);
>  }
> diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
> index ac9cf3a..018d820 100644
> --- a/xen/arch/arm/gic.h
> +++ b/xen/arch/arm/gic.h
> @@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
>  /* Take down a CPU's per-CPU GIC interface */
>  extern void gic_disable_cpu(void);
>  /* setup the gic virtual interface for a guest */
> -extern void gicv_setup(struct domain *d);
> +extern int gicv_setup(struct domain *d);
>  
>  /* Context switch */
>  extern void gic_save_state(struct vcpu *v);
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index c4daf83..0665445 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -4,6 +4,7 @@
>  #include <xen/errno.h>
>  #include <xen/domain_page.h>
>  #include <asm/flushtlb.h>
> +#include "gic.h"
>  
>  void dump_p2m_lookup(struct domain *d, paddr_t addr)
>  {
> @@ -138,7 +139,7 @@ static int p2m_create_entry(struct domain *d,
>  
>      BUG_ON(entry->p2m.valid);
>  
> -    page = alloc_domheap_page(d, 0);
> +    page = alloc_domheap_page(NULL, 0);
>      if ( page == NULL )
>          return -ENOMEM;
>  
> -- 
> 1.7.9.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 Thu Jun 07 10:42:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScaA7-0003jJ-50; Thu, 07 Jun 2012 10:41: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 1ScaA5-0003j9-Fk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:41:53 +0000
Received: from [193.109.254.147:49178] by server-10.bemta-14.messagelabs.com
	id C5/C7-25709-07580DF4; Thu, 07 Jun 2012 10:41:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339065712!6130838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27676 invoked from network); 7 Jun 2012 10:41:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:41:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:41:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:41:41 +0100
Date: Thu, 7 Jun 2012 11:41:25 +0100
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: <1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071140160.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.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] [PATCH 29/38] arm: delay enabling data-cache until
 paging 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 Fri, 1 Jun 2012, Ian Campbell wrote:
> cached before paging was enabled had been mapped with to inconsistent sets of
> attributes. I'm not convinced that isn't a model issue, nor am I convinced
> this has really fixed anything, but it seems sensible enough.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/head.S |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 9a7714a..71197af 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -148,10 +148,11 @@ hyp:
>  	 * Exceptions in LE ARM,
>  	 * Low-latency IRQs disabled,
>  	 * Write-implies-XN disabled (for now),
> -	 * I-cache and d-cache enabled,
> +	 * D-cache diabled (for now),
                 ^ misspell
> +	 * I-cache enabled,
>  	 * Alignment checking enabled,
>  	 * MMU translation disabled (for now). */
> -	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
> +	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
>  	mcr   CP32(r0, HSCTLR)
>  
>  	/* Write Xen's PT's paddr into the HTTBR */
> @@ -217,6 +218,10 @@ pt_ready:
>  	mov   pc, r1                 /* Get a proper vaddr into PC */
>  paging:
>  
> +	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
> +	orr   r0, r0, #(SCTLR_C)
> +	mcr   CP32(r0, HSCTLR)
> +
>  #ifdef EARLY_UART_ADDRESS
>  	/* Recover the UART address in the new address space. */
>  	lsl   r11, #11
> -- 
> 1.7.9.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 Thu Jun 07 10:42:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScaA7-0003jJ-50; Thu, 07 Jun 2012 10:41: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 1ScaA5-0003j9-Fk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:41:53 +0000
Received: from [193.109.254.147:49178] by server-10.bemta-14.messagelabs.com
	id C5/C7-25709-07580DF4; Thu, 07 Jun 2012 10:41:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339065712!6130838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27676 invoked from network); 7 Jun 2012 10:41:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:41:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:41:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:41:41 +0100
Date: Thu, 7 Jun 2012 11:41:25 +0100
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: <1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071140160.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.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] [PATCH 29/38] arm: delay enabling data-cache until
 paging 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 Fri, 1 Jun 2012, Ian Campbell wrote:
> cached before paging was enabled had been mapped with to inconsistent sets of
> attributes. I'm not convinced that isn't a model issue, nor am I convinced
> this has really fixed anything, but it seems sensible enough.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/head.S |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 9a7714a..71197af 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -148,10 +148,11 @@ hyp:
>  	 * Exceptions in LE ARM,
>  	 * Low-latency IRQs disabled,
>  	 * Write-implies-XN disabled (for now),
> -	 * I-cache and d-cache enabled,
> +	 * D-cache diabled (for now),
                 ^ misspell
> +	 * I-cache enabled,
>  	 * Alignment checking enabled,
>  	 * MMU translation disabled (for now). */
> -	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
> +	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
>  	mcr   CP32(r0, HSCTLR)
>  
>  	/* Write Xen's PT's paddr into the HTTBR */
> @@ -217,6 +218,10 @@ pt_ready:
>  	mov   pc, r1                 /* Get a proper vaddr into PC */
>  paging:
>  
> +	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
> +	orr   r0, r0, #(SCTLR_C)
> +	mcr   CP32(r0, HSCTLR)
> +
>  #ifdef EARLY_UART_ADDRESS
>  	/* Recover the UART address in the new address space. */
>  	lsl   r11, #11
> -- 
> 1.7.9.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 Thu Jun 07 10:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScaFW-0003y8-Up; Thu, 07 Jun 2012 10:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1ScaFW-0003y3-6U
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:47:30 +0000
Received: from [85.158.138.51:48197] by server-6.bemta-3.messagelabs.com id
	CB/B4-05063-1C680DF4; Thu, 07 Jun 2012 10:47:29 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339066048!31317894!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY4OTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22644 invoked from network); 7 Jun 2012 10:47:28 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-5.tower-174.messagelabs.com with SMTP;
	7 Jun 2012 10:47:28 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57AkgOp016338;
	Thu, 7 Jun 2012 06:46:42 -0400
Date: Thu, 07 Jun 2012 06:46:41 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4FCF5015020000780008878C@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> >>> On 06.06.12 at 10:54, Andrew Jones <drjones@redhat.com> wrote:
> 
> > https://bugzilla.redhat.com/show_bug.cgi?id=829016
> > 
> > was opened yesterday. Maybe the following commit
> > is the culprit?
> > 
> > commit cb8095bba6d24118135a5683a956f4f4fb5f17bb
> > Author: Jan Beulich <JBeulich@suse.com>
> > Date:   Fri Jan 20 16:22:04 2012 +0000
> > 
> >     x86: atomic64 assembly improvements
> 
> Hardly - that change didn't even touch atomic64_read_cx8()
> or any of its constraints.
> 
> Further more, this
> 
> *pdpt = 0000000023be6027 *pde = 00000000037c2067 *pte =
> 8000000023bdb061
> Oops: 0003 [#1] SMP
> 
> tells us that this was a write-protection fault, yet the hypervisor
> failed to emulate this (hence the hypervisor log would likely help).
> After quite some time spent looking through the upstream 3.0.4
> sources (and my local object files) I can't, however, spot where
> the call to atomic64_read() is actually located in the functions in
> question.
> 

Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
done that I would have immediately suspected a different patch instead
(mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
upstream commit 26c191788f18). We've already encountered one problem
with this patch for RHEL6 and fixed it. The patch F17 has, however, is
already the "fixed" version. Now the difference between RHEL6 and F17
though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
but RHEL6 does not. So now with this patch F17 is calling
atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScaFW-0003y8-Up; Thu, 07 Jun 2012 10:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1ScaFW-0003y3-6U
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:47:30 +0000
Received: from [85.158.138.51:48197] by server-6.bemta-3.messagelabs.com id
	CB/B4-05063-1C680DF4; Thu, 07 Jun 2012 10:47:29 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339066048!31317894!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY4OTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22644 invoked from network); 7 Jun 2012 10:47:28 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-5.tower-174.messagelabs.com with SMTP;
	7 Jun 2012 10:47:28 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57AkgOp016338;
	Thu, 7 Jun 2012 06:46:42 -0400
Date: Thu, 07 Jun 2012 06:46:41 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4FCF5015020000780008878C@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> >>> On 06.06.12 at 10:54, Andrew Jones <drjones@redhat.com> wrote:
> 
> > https://bugzilla.redhat.com/show_bug.cgi?id=829016
> > 
> > was opened yesterday. Maybe the following commit
> > is the culprit?
> > 
> > commit cb8095bba6d24118135a5683a956f4f4fb5f17bb
> > Author: Jan Beulich <JBeulich@suse.com>
> > Date:   Fri Jan 20 16:22:04 2012 +0000
> > 
> >     x86: atomic64 assembly improvements
> 
> Hardly - that change didn't even touch atomic64_read_cx8()
> or any of its constraints.
> 
> Further more, this
> 
> *pdpt = 0000000023be6027 *pde = 00000000037c2067 *pte =
> 8000000023bdb061
> Oops: 0003 [#1] SMP
> 
> tells us that this was a write-protection fault, yet the hypervisor
> failed to emulate this (hence the hypervisor log would likely help).
> After quite some time spent looking through the upstream 3.0.4
> sources (and my local object files) I can't, however, spot where
> the call to atomic64_read() is actually located in the functions in
> question.
> 

Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
done that I would have immediately suspected a different patch instead
(mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
upstream commit 26c191788f18). We've already encountered one problem
with this patch for RHEL6 and fixed it. The patch F17 has, however, is
already the "fixed" version. Now the difference between RHEL6 and F17
though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
but RHEL6 does not. So now with this patch F17 is calling
atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:50:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:50: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 1ScaHy-000449-In; Thu, 07 Jun 2012 10:50: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 1ScaHx-000442-8z
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:50:01 +0000
Received: from [85.158.139.83:16635] by server-3.bemta-5.messagelabs.com id
	CA/79-17554-85780DF4; Thu, 07 Jun 2012 10:50:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339066199!28471347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8031 invoked from network); 7 Jun 2012 10:50:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:49:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:50:00 +0100
Date: Thu, 7 Jun 2012 11:49:43 +0100
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: <1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.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] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> In particular it is taken by gic_set_guest_irq which is called by
> vgic_vcpu_inject_irq
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/gic.c |   20 ++++++++++----------
>  1 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index a398f92..ededa99 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -329,19 +329,19 @@ int __init gic_init(void)
>  /* Set up the per-CPU parts of the GIC for a secondary CPU */
>  void __cpuinit gic_init_secondary_cpu(void)
>  {
> -    spin_lock(&gic.lock);
> +    spin_lock_irq(&gic.lock);
>      gic_cpu_init();
>      gic_hyp_init();
> -    spin_unlock(&gic.lock);
> +    spin_unlock_irq(&gic.lock);
>  }
>  
>  /* Shut down the per-CPU GIC interface */
>  void gic_disable_cpu(void)
>  {
> -    spin_lock(&gic.lock);
> +    spin_lock_irq(&gic.lock);
>      gic_cpu_disable();
>      gic_hyp_disable();
> -    spin_unlock(&gic.lock);
> +    spin_unlock_irq(&gic.lock);
>  }
>  
>  void gic_route_irqs(void)
> @@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>  
>      events_maintenance(current);
>  
> -    spin_lock(&gic.lock);
> +    spin_lock_irq(&gic.lock);
>  
>      if ( list_empty(&gic.lr_pending) )
>      {
> @@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>      list_add_tail(&n->lr_queue, &gic.lr_pending);
>  
>  out:
> -    spin_unlock(&gic.lock);
> +    spin_unlock_irq(&gic.lock);
>      return;
>  }
>  
> @@ -559,7 +559,7 @@ static void events_maintenance(struct vcpu *v)
>              (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
>  
>      if (!already_pending && gic.event_mask != 0) {
> -        spin_lock(&gic.lock);
> +        spin_lock_irq(&gic.lock);
>          while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
>                          sizeof(uint64_t), i)) < sizeof(uint64_t)) {
>  
> @@ -569,7 +569,7 @@ static void events_maintenance(struct vcpu *v)
>  
>              i++;
>          }
> -        spin_unlock(&gic.lock);
> +        spin_unlock_irq(&gic.lock);
>      }
>  }
>  
> @@ -585,7 +585,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                                sizeof(eisr), i)) < sizeof(eisr)) {
>          struct pending_irq *p;
>  
> -        spin_lock(&gic.lock);
> +        spin_lock_irq(&gic.lock);
>          lr = GICH[GICH_LR + i];
>          virq = lr & GICH_LR_VIRTUAL_MASK;
>          GICH[GICH_LR + i] = 0;
> @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>          } else {
>              gic_inject_irq_stop();
>          }
> -        spin_unlock(&gic.lock);
> +        spin_unlock_irq(&gic.lock);
>  
>          spin_lock(&current->arch.vgic.lock);
               ^
shouldn't you change this into spin_lock_irq too?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:50:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:50: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 1ScaHy-000449-In; Thu, 07 Jun 2012 10:50: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 1ScaHx-000442-8z
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:50:01 +0000
Received: from [85.158.139.83:16635] by server-3.bemta-5.messagelabs.com id
	CA/79-17554-85780DF4; Thu, 07 Jun 2012 10:50:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339066199!28471347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8031 invoked from network); 7 Jun 2012 10:50:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:49:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:50:00 +0100
Date: Thu, 7 Jun 2012 11:49:43 +0100
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: <1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.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] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> In particular it is taken by gic_set_guest_irq which is called by
> vgic_vcpu_inject_irq
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/gic.c |   20 ++++++++++----------
>  1 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index a398f92..ededa99 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -329,19 +329,19 @@ int __init gic_init(void)
>  /* Set up the per-CPU parts of the GIC for a secondary CPU */
>  void __cpuinit gic_init_secondary_cpu(void)
>  {
> -    spin_lock(&gic.lock);
> +    spin_lock_irq(&gic.lock);
>      gic_cpu_init();
>      gic_hyp_init();
> -    spin_unlock(&gic.lock);
> +    spin_unlock_irq(&gic.lock);
>  }
>  
>  /* Shut down the per-CPU GIC interface */
>  void gic_disable_cpu(void)
>  {
> -    spin_lock(&gic.lock);
> +    spin_lock_irq(&gic.lock);
>      gic_cpu_disable();
>      gic_hyp_disable();
> -    spin_unlock(&gic.lock);
> +    spin_unlock_irq(&gic.lock);
>  }
>  
>  void gic_route_irqs(void)
> @@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>  
>      events_maintenance(current);
>  
> -    spin_lock(&gic.lock);
> +    spin_lock_irq(&gic.lock);
>  
>      if ( list_empty(&gic.lr_pending) )
>      {
> @@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
>      list_add_tail(&n->lr_queue, &gic.lr_pending);
>  
>  out:
> -    spin_unlock(&gic.lock);
> +    spin_unlock_irq(&gic.lock);
>      return;
>  }
>  
> @@ -559,7 +559,7 @@ static void events_maintenance(struct vcpu *v)
>              (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
>  
>      if (!already_pending && gic.event_mask != 0) {
> -        spin_lock(&gic.lock);
> +        spin_lock_irq(&gic.lock);
>          while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
>                          sizeof(uint64_t), i)) < sizeof(uint64_t)) {
>  
> @@ -569,7 +569,7 @@ static void events_maintenance(struct vcpu *v)
>  
>              i++;
>          }
> -        spin_unlock(&gic.lock);
> +        spin_unlock_irq(&gic.lock);
>      }
>  }
>  
> @@ -585,7 +585,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                                sizeof(eisr), i)) < sizeof(eisr)) {
>          struct pending_irq *p;
>  
> -        spin_lock(&gic.lock);
> +        spin_lock_irq(&gic.lock);
>          lr = GICH[GICH_LR + i];
>          virq = lr & GICH_LR_VIRTUAL_MASK;
>          GICH[GICH_LR + i] = 0;
> @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>          } else {
>              gic_inject_irq_stop();
>          }
> -        spin_unlock(&gic.lock);
> +        spin_unlock_irq(&gic.lock);
>  
>          spin_lock(&current->arch.vgic.lock);
               ^
shouldn't you change this into spin_lock_irq too?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:54:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScaLs-0004HK-Gf; Thu, 07 Jun 2012 10:54:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScaLq-0004HD-HT
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:54:02 +0000
Received: from [85.158.138.51:42861] by server-5.bemta-3.messagelabs.com id
	52/64-03598-84880DF4; Thu, 07 Jun 2012 10:54:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339066439!31268094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20676 invoked from network); 7 Jun 2012 10:53:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:53:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:53:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:53:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScaLm-0007gN-E9; Thu, 07 Jun 2012 10:53:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScaLm-00080l-Bi;
	Thu, 07 Jun 2012 11:53:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.34886.348463.178975@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 11:53:58 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-2-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 01/10] libxl: change
 libxl__ao_device_remove to libxl__ao_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

Roger Pau Monne writes ("[PATCH v5 01/10] libxl: change libxl__ao_device_remove to libxl__ao_device"):
> Introduce a new structure to track state of device backends, that will
> be used in following patches on this series.
...
> +_hidden void libxl__prepare_ao_device(libxl__ao_device *aodev, libxl__ao *ao,
> +                                      libxl__ao_device **base);

The doc comment doesn't seem to explain base.  What is it used for ?

I see only this:

> +void libxl__prepare_ao_device(libxl__ao_device *aodev, libxl__ao *ao,
> +                              libxl__ao_device **base)
...
> +    aodev->base = base;

but:

> +struct libxl__ao_device {
...
> +    /* private for implementation */
...
> +    void *base;
> +};

Why is it void* here when it's only ever set to a libxl__ao_device** ?


> +void libxl__initiate_device_remove(libxl__egc *egc,
> +                                   libxl__ao_device *aodev)
...
> -    libxl__ev_devstate_init(&aorm->ds);
> +    libxl__ev_devstate_init(&aodev->ds);
> 
> -    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
> +    rc = libxl__ev_devstate_wait(gc, &aodev->ds, device_backend_callback,
>                                   state_path, XenbusStateClosed,
>                                   LIBXL_DESTROY_TIMEOUT * 1000);

libxl__ev_devstate_init is not needed before _wait.  (Admittedly
that's there in the code before you touched it.)  In general foo_init
is not needed before foo_do_the_thing_and_call_me_back.

Given the use of `backend' in function names to refer to what is
manipulated with aodev->ds, perhaps aodev->ds should be called
aodev->backend_ds ?

I was briefly confused about whether `device_backend_cleanup' was a
general cleanup function for a libxl__ao_device (which it isn't).  And
there is of course a frontend state too, which we don't explicitly
deal with here.

How do the frontend and backend directories get removed from
xenstore ?  (I have a feeling I have asked this before but I don't
remember the answer.  Perhaps it could be a comment in the code in
some appropriate place?)


> +/* This functions sets the necessary libxl__ao_device struct values to use
> + * safely inside functions. It marks the operation as "active"

This `active' business is not used in this patch.  The variable and
its initialisation and commentary should be introduced in the same
patch as its use.

So either the ancillary functions which use `active' need to be
brought forward and documented here, or the introduction of `active'
should be postponed.

> +struct libxl__ao_device {
> +    /* filled in by user */
> +    libxl__ao *ao;
> +    /* action being performed */
> +    libxl__device_action action;
> +    libxl__device *dev;
> +    int force;
> +    libxl__device_callback *callback;
> +    /* private for implementation */
> +    int active;
...

This is a bit confusing.  I would remove the comment `/* action being
performed */' because it seems to refer to all the following variables
(and to disapply `/* filled in by user */' which does in fact apply).
And the only thing it seems to be actually trying to document is that
the variable `action' is the action, which is a bit pointless.

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 Jun 07 10:54:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10: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 1ScaLs-0004HK-Gf; Thu, 07 Jun 2012 10:54:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScaLq-0004HD-HT
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:54:02 +0000
Received: from [85.158.138.51:42861] by server-5.bemta-3.messagelabs.com id
	52/64-03598-84880DF4; Thu, 07 Jun 2012 10:54:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339066439!31268094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20676 invoked from network); 7 Jun 2012 10:53:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:53:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:53:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:53:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScaLm-0007gN-E9; Thu, 07 Jun 2012 10:53:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScaLm-00080l-Bi;
	Thu, 07 Jun 2012 11:53:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.34886.348463.178975@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 11:53:58 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-2-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 01/10] libxl: change
 libxl__ao_device_remove to libxl__ao_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

Roger Pau Monne writes ("[PATCH v5 01/10] libxl: change libxl__ao_device_remove to libxl__ao_device"):
> Introduce a new structure to track state of device backends, that will
> be used in following patches on this series.
...
> +_hidden void libxl__prepare_ao_device(libxl__ao_device *aodev, libxl__ao *ao,
> +                                      libxl__ao_device **base);

The doc comment doesn't seem to explain base.  What is it used for ?

I see only this:

> +void libxl__prepare_ao_device(libxl__ao_device *aodev, libxl__ao *ao,
> +                              libxl__ao_device **base)
...
> +    aodev->base = base;

but:

> +struct libxl__ao_device {
...
> +    /* private for implementation */
...
> +    void *base;
> +};

Why is it void* here when it's only ever set to a libxl__ao_device** ?


> +void libxl__initiate_device_remove(libxl__egc *egc,
> +                                   libxl__ao_device *aodev)
...
> -    libxl__ev_devstate_init(&aorm->ds);
> +    libxl__ev_devstate_init(&aodev->ds);
> 
> -    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
> +    rc = libxl__ev_devstate_wait(gc, &aodev->ds, device_backend_callback,
>                                   state_path, XenbusStateClosed,
>                                   LIBXL_DESTROY_TIMEOUT * 1000);

libxl__ev_devstate_init is not needed before _wait.  (Admittedly
that's there in the code before you touched it.)  In general foo_init
is not needed before foo_do_the_thing_and_call_me_back.

Given the use of `backend' in function names to refer to what is
manipulated with aodev->ds, perhaps aodev->ds should be called
aodev->backend_ds ?

I was briefly confused about whether `device_backend_cleanup' was a
general cleanup function for a libxl__ao_device (which it isn't).  And
there is of course a frontend state too, which we don't explicitly
deal with here.

How do the frontend and backend directories get removed from
xenstore ?  (I have a feeling I have asked this before but I don't
remember the answer.  Perhaps it could be a comment in the code in
some appropriate place?)


> +/* This functions sets the necessary libxl__ao_device struct values to use
> + * safely inside functions. It marks the operation as "active"

This `active' business is not used in this patch.  The variable and
its initialisation and commentary should be introduced in the same
patch as its use.

So either the ancillary functions which use `active' need to be
brought forward and documented here, or the introduction of `active'
should be postponed.

> +struct libxl__ao_device {
> +    /* filled in by user */
> +    libxl__ao *ao;
> +    /* action being performed */
> +    libxl__device_action action;
> +    libxl__device *dev;
> +    int force;
> +    libxl__device_callback *callback;
> +    /* private for implementation */
> +    int active;
...

This is a bit confusing.  I would remove the comment `/* action being
performed */' because it seems to refer to all the following variables
(and to disapply `/* filled in by user */' which does in fact apply).
And the only thing it seems to be actually trying to document is that
the variable `action' is the action, which is a bit pointless.

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 Jun 07 10:55:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScaMu-0004M2-NU; Thu, 07 Jun 2012 10:55:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ScaMs-0004LT-1A
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:55:06 +0000
Received: from [85.158.139.83:56153] by server-1.bemta-5.messagelabs.com id
	DE/08-25424-98880DF4; Thu, 07 Jun 2012 10:55:05 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339066502!28552575!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18141 invoked from network); 7 Jun 2012 10:55:03 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:55:03 -0000
Received: by obbwd20 with SMTP id wd20so1056928obb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 03:55:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=8zZOsxiJfAEzvWhBHULk+EetGikq7aOd4oFSLa3ORSY=;
	b=OPqn0i/5HK/0b1uqI+VWAXr3ywNUuxDajhjxcyayy1Rq5RjsWd78SwUkW06zUnCugj
	B6WR2p7uwwGa0coP80xyunvX6BGrW7Jc5vaLYqtuZNtEr3xwaSUWXS9npo+im/FdHbW/
	YIMgcUAjQnwd8PtbPWs3ZAQNpE1oMSQZZFUFp9MpPMiXh8fnzTC3kI9M6p5nvsCUvCtp
	2BN60JWDmdkg9oiRi2btaNgh6Fw7ps1/TABjwfHW5eMqG6cs/c3gxljpKfeGLf/9Hjaq
	mPys0ibyz7kpeb/EEDzI943d3l+gEr83MQGYC4/stoGgUSTKXqeLJG3hlgKlo/SdXI8l
	qzNQ==
Received: by 10.182.145.4 with SMTP id sq4mr1525978obb.76.1339066502192; Thu,
	07 Jun 2012 03:55:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.204.99 with HTTP; Thu, 7 Jun 2012 03:54:42 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 7 Jun 2012 12:54:42 +0200
Message-ID: <CABs9Ejmp8AnDu==8WPBysE0itQqtAr81RQVyJCfdW=9DBDq6pg@mail.gmail.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
X-Gm-Message-State: ALoCoQnYhSJYX2SUQJD1adLERQ6s4i98VSi/4WPZyjLCDVjeF8iLTsxiU3qjZd1wOP6q/QGSi22p
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 11:24 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrot=
e:
> Rolu,
>
> thanks for the feedback.
>
>
>> xen" and "help with xcp" it would be nice if there were a few lines at
>> the top of the page explaining which is which, so (new) people can
>> have a better idea of where to look.
>
>
> So you mean a link to Xen and XCP from the headline, or a tagline describ=
ing
> what Xen/XCP is? Two lines are probably OK; more would probably break up =
the
> navigation too much.
>

Yeah, a tagline, as a disambiguation between Xen and XCP. I combined a
few sentences from the various pages and got this:

--
Xen is an open-source type-1 or baremetal hypervisor, which makes it
possible to run many instances of an operating system or indeed
different operating systems in parallel on a single machine (or host).
The Xen Cloud Platform (XCP) is an open source enterprise-ready server
virtualization and cloud computing platform with Xen at the core. XCP
can be thought of as the open source release of the commercial Citrix
XenServer.
See here for a [feature matrix]
--

>>
>> The descriptions from
>> http://xen.org/products/ and a link to
>> http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
>> The latter is already linked in the "getting started with xen" column
>> but would be better off at the top since it gives a feature table of
>> both.
>
> I am wondering whether Xen Features / XCP Features in one of the boxes wo=
uld
> not be better.
>

That'd probably work too yes, and might look nicer to boot.

>>
>> As someone who started with Xen not long ago, I much prefer dedicated
>> link pages over Category: pages. The latter just give a big unsorted
>> (alphabetical doesn't count, needs to be sorted by subtopic to be a
>> useful sort) list of pages of widely varying scope and usefulness.
>> It's better than nothing, sure, but a page that sorts them by topic or
>> purpose or something (much like this proposed front page really) is a
>> lot better.
>
> How about a compromise? Category pages have two parts:
> 1) A fixed part that can be used for any content, such as lists of import=
ant
> articles by topic or other ciriteria
> =A0=A0=A0 An example of this is http://wiki.xen.org/wiki/Category:Host_In=
stall
> (and some of the pages linked from it)
> 2) The auto-generated index
>

That does certainly help. That way a manual list can be built while
keeping the category page, and it could replace it once it proves to
be good enough.

> I know that some people are don't like category pages. However, until
> somebody steps up and provides an alternative, which to do well requires
> a) Classifying articles
> b) Grouping them by topic or purpose
> c) Encoding that grouping in some manual index
> d) Keeping these up-to-date
>
> ... the category pages are all we have and are a lot better than what we =
had
> in the old wiki. And they are self-maintaining.
>

Especially d is an issue I think. Self maintenance is an attractive feature.

> The fact that we are having this discussion is actually good. I am open to
> suggestions and maybe we just need a small number of manually maintained
> indexes (or categories with maintained content at the top). Maybe to make
> this really work and get better navigability we need some degree of
> ownership in the wiki: i.e. community members owning content, categories,
> etc. and being responsible for classifying, grouping and making it more
> accessible.
>

I think the most important step would be to flesh out the high level
structure of the wiki a bit more. If that is done well, pages can be
put in their place much easier. The new front page starts this (xen
versus xcp, then the boxes) but the level below that is rather messy.
For example, there are howtos, FAQs, Q&As, books, guides, tutorials,
examples, overviews, and so on, with lots of overlap. These categories
are all about how the information is presented and that might be the
wrong approach. When I come to the wiki I'll have questions like "I
want to know more about how to handle disk storage" or "I want to know
how to install operating system XYZ in a domU" or "I want to know how
to switch toolstacks". I don't care if that info is found in a howto,
FAQ, book, guide, tutorial or example though, as long as I find it.
So, setting up and using categories that tell you what information is
there would help.

> I also started experimenting with shortcut boxes on pages such as
> http://wiki.xen.org/wiki/Xen_Overview &
> http://wiki.xen.org/wiki/Getting_Started and wanted to know what people
> thought of these and whether these improve navigability.
>

Yes, that helps. They would also make a good link page or category
though. For example, the box on the getting started page could be
titled "beginner documentation" or something.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:55:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScaMu-0004M2-NU; Thu, 07 Jun 2012 10:55:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ScaMs-0004LT-1A
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:55:06 +0000
Received: from [85.158.139.83:56153] by server-1.bemta-5.messagelabs.com id
	DE/08-25424-98880DF4; Thu, 07 Jun 2012 10:55:05 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339066502!28552575!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18141 invoked from network); 7 Jun 2012 10:55:03 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:55:03 -0000
Received: by obbwd20 with SMTP id wd20so1056928obb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 03:55:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=8zZOsxiJfAEzvWhBHULk+EetGikq7aOd4oFSLa3ORSY=;
	b=OPqn0i/5HK/0b1uqI+VWAXr3ywNUuxDajhjxcyayy1Rq5RjsWd78SwUkW06zUnCugj
	B6WR2p7uwwGa0coP80xyunvX6BGrW7Jc5vaLYqtuZNtEr3xwaSUWXS9npo+im/FdHbW/
	YIMgcUAjQnwd8PtbPWs3ZAQNpE1oMSQZZFUFp9MpPMiXh8fnzTC3kI9M6p5nvsCUvCtp
	2BN60JWDmdkg9oiRi2btaNgh6Fw7ps1/TABjwfHW5eMqG6cs/c3gxljpKfeGLf/9Hjaq
	mPys0ibyz7kpeb/EEDzI943d3l+gEr83MQGYC4/stoGgUSTKXqeLJG3hlgKlo/SdXI8l
	qzNQ==
Received: by 10.182.145.4 with SMTP id sq4mr1525978obb.76.1339066502192; Thu,
	07 Jun 2012 03:55:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.204.99 with HTTP; Thu, 7 Jun 2012 03:54:42 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 7 Jun 2012 12:54:42 +0200
Message-ID: <CABs9Ejmp8AnDu==8WPBysE0itQqtAr81RQVyJCfdW=9DBDq6pg@mail.gmail.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
X-Gm-Message-State: ALoCoQnYhSJYX2SUQJD1adLERQ6s4i98VSi/4WPZyjLCDVjeF8iLTsxiU3qjZd1wOP6q/QGSi22p
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 11:24 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrot=
e:
> Rolu,
>
> thanks for the feedback.
>
>
>> xen" and "help with xcp" it would be nice if there were a few lines at
>> the top of the page explaining which is which, so (new) people can
>> have a better idea of where to look.
>
>
> So you mean a link to Xen and XCP from the headline, or a tagline describ=
ing
> what Xen/XCP is? Two lines are probably OK; more would probably break up =
the
> navigation too much.
>

Yeah, a tagline, as a disambiguation between Xen and XCP. I combined a
few sentences from the various pages and got this:

--
Xen is an open-source type-1 or baremetal hypervisor, which makes it
possible to run many instances of an operating system or indeed
different operating systems in parallel on a single machine (or host).
The Xen Cloud Platform (XCP) is an open source enterprise-ready server
virtualization and cloud computing platform with Xen at the core. XCP
can be thought of as the open source release of the commercial Citrix
XenServer.
See here for a [feature matrix]
--

>>
>> The descriptions from
>> http://xen.org/products/ and a link to
>> http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
>> The latter is already linked in the "getting started with xen" column
>> but would be better off at the top since it gives a feature table of
>> both.
>
> I am wondering whether Xen Features / XCP Features in one of the boxes wo=
uld
> not be better.
>

That'd probably work too yes, and might look nicer to boot.

>>
>> As someone who started with Xen not long ago, I much prefer dedicated
>> link pages over Category: pages. The latter just give a big unsorted
>> (alphabetical doesn't count, needs to be sorted by subtopic to be a
>> useful sort) list of pages of widely varying scope and usefulness.
>> It's better than nothing, sure, but a page that sorts them by topic or
>> purpose or something (much like this proposed front page really) is a
>> lot better.
>
> How about a compromise? Category pages have two parts:
> 1) A fixed part that can be used for any content, such as lists of import=
ant
> articles by topic or other ciriteria
> =A0=A0=A0 An example of this is http://wiki.xen.org/wiki/Category:Host_In=
stall
> (and some of the pages linked from it)
> 2) The auto-generated index
>

That does certainly help. That way a manual list can be built while
keeping the category page, and it could replace it once it proves to
be good enough.

> I know that some people are don't like category pages. However, until
> somebody steps up and provides an alternative, which to do well requires
> a) Classifying articles
> b) Grouping them by topic or purpose
> c) Encoding that grouping in some manual index
> d) Keeping these up-to-date
>
> ... the category pages are all we have and are a lot better than what we =
had
> in the old wiki. And they are self-maintaining.
>

Especially d is an issue I think. Self maintenance is an attractive feature.

> The fact that we are having this discussion is actually good. I am open to
> suggestions and maybe we just need a small number of manually maintained
> indexes (or categories with maintained content at the top). Maybe to make
> this really work and get better navigability we need some degree of
> ownership in the wiki: i.e. community members owning content, categories,
> etc. and being responsible for classifying, grouping and making it more
> accessible.
>

I think the most important step would be to flesh out the high level
structure of the wiki a bit more. If that is done well, pages can be
put in their place much easier. The new front page starts this (xen
versus xcp, then the boxes) but the level below that is rather messy.
For example, there are howtos, FAQs, Q&As, books, guides, tutorials,
examples, overviews, and so on, with lots of overlap. These categories
are all about how the information is presented and that might be the
wrong approach. When I come to the wiki I'll have questions like "I
want to know more about how to handle disk storage" or "I want to know
how to install operating system XYZ in a domU" or "I want to know how
to switch toolstacks". I don't care if that info is found in a howto,
FAQ, book, guide, tutorial or example though, as long as I find it.
So, setting up and using categories that tell you what information is
there would help.

> I also started experimenting with shortcut boxes on pages such as
> http://wiki.xen.org/wiki/Xen_Overview &
> http://wiki.xen.org/wiki/Getting_Started and wanted to know what people
> thought of these and whether these improve navigability.
>

Yes, that helps. They would also make a good link page or category
though. For example, the box on the getting started page could be
titled "beginner documentation" or something.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScaPH-0004gv-D2; Thu, 07 Jun 2012 10:57:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScaPF-0004gg-Jg
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:57:33 +0000
Received: from [193.109.254.147:16687] by server-11.bemta-14.messagelabs.com
	id D0/21-02727-C1980DF4; Thu, 07 Jun 2012 10:57:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339066635!8550059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20197 invoked from network); 7 Jun 2012 10:57:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:57:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:57:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:57:14 +0100
Date: Thu, 7 Jun 2012 11:56:58 +0100
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: <1338565207-2888-34-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071154420.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-34-git-send-email-ian.campbell@citrix.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] [PATCH 34/38] HACK: arm: initial
 XENMAPSPACE_gmfn_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 Fri, 1 Jun 2012, Ian Campbell wrote:
> Should use same interface as hybrid x86.
> ---
>  xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
>  xen/arch/x86/mm.c             |    2 ++
>  xen/include/public/arch-arm.h |    1 +
>  xen/include/public/memory.h   |   12 +++++++-----
>  4 files changed, 36 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index ab52171..1832e7f 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -480,12 +480,32 @@ static int xenmem_add_to_physmap_once(
>  
>      switch ( xatp->space )
>      {
> -        case XENMAPSPACE_shared_info:
> -            if ( xatp->idx == 0 )
> -                mfn = virt_to_mfn(d->shared_info);
> -            break;
> -        default:
> -            return -ENOSYS;
> +    case XENMAPSPACE_shared_info:
> +        if ( xatp->idx == 0 )
> +            mfn = virt_to_mfn(d->shared_info);
> +        break;
> +    case XENMAPSPACE_gmfn_foreign:
> +    {
> +        paddr_t maddr;
> +        struct domain *od;
> +
> +        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
> +        if ( rc < 0 )
> +            return rc;
> +        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +        if ( maddr == INVALID_PADDR )
> +        {
> +            printk("bad p2m lookup\n");
> +            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +            rcu_unlock_domain(od);
> +            return -EINVAL;
> +        }
> +        mfn = maddr >> PAGE_SHIFT;
> +        rcu_unlock_domain(od);
> +        break;
> +    }

It is probably a good idea at least to test xatp->size and WARN if it is
not 1 page.


> +    default:
> +        return -ENOSYS;
>      }
>  
>      domain_lock(d);
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 876e1ef..d6c90f9 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4572,6 +4572,8 @@ static int xenmem_add_to_physmap_once(
>              mfn = idx;
>              page = mfn_to_page(mfn);
>              break;
> +        case XENMAPSPACE_gmfn_foreign:
> +            return -ENOSYS;
>          }
>          default:
>              break;
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index e915cbf..b52bfc7 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
>  #define XEN_LEGACY_MAX_VCPUS 1
>  
>  typedef uint32_t xen_ulong_t;
> +#define PRI_xen_ulong PRIx32
>  
>  struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */

Why did you need to define this here?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 10:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 10:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScaPH-0004gv-D2; Thu, 07 Jun 2012 10:57:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScaPF-0004gg-Jg
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 10:57:33 +0000
Received: from [193.109.254.147:16687] by server-11.bemta-14.messagelabs.com
	id D0/21-02727-C1980DF4; Thu, 07 Jun 2012 10:57:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339066635!8550059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20197 invoked from network); 7 Jun 2012 10:57:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:57:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 10:57:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 11:57:14 +0100
Date: Thu, 7 Jun 2012 11:56:58 +0100
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: <1338565207-2888-34-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071154420.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-34-git-send-email-ian.campbell@citrix.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] [PATCH 34/38] HACK: arm: initial
 XENMAPSPACE_gmfn_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 Fri, 1 Jun 2012, Ian Campbell wrote:
> Should use same interface as hybrid x86.
> ---
>  xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
>  xen/arch/x86/mm.c             |    2 ++
>  xen/include/public/arch-arm.h |    1 +
>  xen/include/public/memory.h   |   12 +++++++-----
>  4 files changed, 36 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index ab52171..1832e7f 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -480,12 +480,32 @@ static int xenmem_add_to_physmap_once(
>  
>      switch ( xatp->space )
>      {
> -        case XENMAPSPACE_shared_info:
> -            if ( xatp->idx == 0 )
> -                mfn = virt_to_mfn(d->shared_info);
> -            break;
> -        default:
> -            return -ENOSYS;
> +    case XENMAPSPACE_shared_info:
> +        if ( xatp->idx == 0 )
> +            mfn = virt_to_mfn(d->shared_info);
> +        break;
> +    case XENMAPSPACE_gmfn_foreign:
> +    {
> +        paddr_t maddr;
> +        struct domain *od;
> +
> +        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
> +        if ( rc < 0 )
> +            return rc;
> +        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +        if ( maddr == INVALID_PADDR )
> +        {
> +            printk("bad p2m lookup\n");
> +            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +            rcu_unlock_domain(od);
> +            return -EINVAL;
> +        }
> +        mfn = maddr >> PAGE_SHIFT;
> +        rcu_unlock_domain(od);
> +        break;
> +    }

It is probably a good idea at least to test xatp->size and WARN if it is
not 1 page.


> +    default:
> +        return -ENOSYS;
>      }
>  
>      domain_lock(d);
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 876e1ef..d6c90f9 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4572,6 +4572,8 @@ static int xenmem_add_to_physmap_once(
>              mfn = idx;
>              page = mfn_to_page(mfn);
>              break;
> +        case XENMAPSPACE_gmfn_foreign:
> +            return -ENOSYS;
>          }
>          default:
>              break;
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index e915cbf..b52bfc7 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
>  #define XEN_LEGACY_MAX_VCPUS 1
>  
>  typedef uint32_t xen_ulong_t;
> +#define PRI_xen_ulong PRIx32
>  
>  struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */

Why did you need to define this here?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:00:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1ScaSB-0004xr-2m; Thu, 07 Jun 2012 11:00:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScaS9-0004xj-Ow
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:00:33 +0000
Received: from [85.158.143.99:24202] by server-3.bemta-4.messagelabs.com id
	4D/EB-29237-0D980DF4; Thu, 07 Jun 2012 11:00:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339066831!31399469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3373 invoked from network); 7 Jun 2012 11:00:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:00:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:00:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:00:31 +0100
Date: Thu, 7 Jun 2012 12:00:14 +0100
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: <1338565207-2888-38-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071159120.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-38-git-send-email-ian.campbell@citrix.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] [PATCH 38/38] HACK: arm: disable hypercall
 continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>  xen/include/xen/sched.h |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 53804c8..15fa6b4 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
>      unsigned int op, const char *format, ...);
>  void hypercall_cancel_continuation(void);
>  
> +#ifdef CONFIG_ARM
> +#define hypercall_preempt_check() (0)
> +#else
>  #define hypercall_preempt_check() (unlikely(    \
>          softirq_pending(smp_processor_id()) |   \
>          local_events_need_delivery()            \
>      ))
> +#endif


I think it is fine for now, but could we add a TODO comment on it?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:00:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1ScaSB-0004xr-2m; Thu, 07 Jun 2012 11:00:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScaS9-0004xj-Ow
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:00:33 +0000
Received: from [85.158.143.99:24202] by server-3.bemta-4.messagelabs.com id
	4D/EB-29237-0D980DF4; Thu, 07 Jun 2012 11:00:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339066831!31399469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3373 invoked from network); 7 Jun 2012 11:00:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:00:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12878506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:00:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:00:31 +0100
Date: Thu, 7 Jun 2012 12:00:14 +0100
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: <1338565207-2888-38-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071159120.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-38-git-send-email-ian.campbell@citrix.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] [PATCH 38/38] HACK: arm: disable hypercall
 continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>  xen/include/xen/sched.h |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 53804c8..15fa6b4 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
>      unsigned int op, const char *format, ...);
>  void hypercall_cancel_continuation(void);
>  
> +#ifdef CONFIG_ARM
> +#define hypercall_preempt_check() (0)
> +#else
>  #define hypercall_preempt_check() (unlikely(    \
>          softirq_pending(smp_processor_id()) |   \
>          local_events_need_delivery()            \
>      ))
> +#endif


I think it is fine for now, but could we add a TODO comment on it?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScaYz-0005M6-0A; Thu, 07 Jun 2012 11:07:37 +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 1ScaYx-0005Lz-Fu
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:07:35 +0000
Received: from [85.158.143.35:60283] by server-3.bemta-4.messagelabs.com id
	D6/3A-29237-67B80DF4; Thu, 07 Jun 2012 11:07:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339067252!11271676!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20871 invoked from network); 7 Jun 2012 11:07:33 -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;
	7 Jun 2012 11:07:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27185343"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:07:31 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 07:07:30 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScaYs-00079l-Dd;
	Thu, 07 Jun 2012 12:07:30 +0100
Message-ID: <4FD08B04.30709@eu.citrix.com>
Date: Thu, 7 Jun 2012 12:05:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
In-Reply-To: <794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Allow xenalyze to be include (at build time) plugins that can do
> per-record actions and a summary.  These plugins can be in C or C++.
>
> The plugins entry points are in struct plugin and pointers to all the
> plugins linked in xenalyze are placed in a "plugin" section so
> plugin_init() can find them all.
>
> A new command line option (-p, --plugin=PLUGIN) is added to enable one
> or more plugins.
>
> A sample plugin (skeleton) is included (mostly because at least one
> plugin must be present for the build to work).
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
So what's the main motivation of having this plugin infrastructure?  The 
one plugin example you have ("batch-size", patch 10) seems simple enough 
that it should be fairly straightforward to just add as an option, with 
not much more boilerplate than C++ already requires.

Looks like potential advantages may include:
* Ability to use C++ language (for those who care for such things)
* Ability to use STL for complex data structures
* Ability to add an option like the "batch-size" plugin in a concise, 
self-contained way

Potential disadvantages include:
* An extra O(N) loop on the hot path (where N = # of enabled plugins)
* For each enabled plugin, an extra full function call on the hot path; 
and a C++ function at that, which (my prejudice tells me) is likely to 
be more wasteful time and space-wise than a C function.

Did I miss anything?

Obviosuly thanks for being conscious of this cost by, for example, 
having a separate list for "enabled" vs "available".

I guess I want to be convinced that allowing this kind of plug-in is 
really worth it, and won't cost too much; especially when something like 
"batch-size" could be implemented in a pretty straightforward way 
without needing a plugin.  I suppose that if there's a plugin that turns 
out to be useful, but is expensive when run as a plug-in, we could 
always pull it into the main file as an optimization.

Also, could you do a simple test to measure the overhead of having no 
plugins?  Just finding a 700MB-ish file you have lying around and 
running "xenalyze -s" with and with this patch (and with this patch and 
-p skeleton or -p batch-size) would be pretty informative, and shouldn't 
take too long.

Thanks,
  -George

> ---
>   Makefile            |   10 +++---
>   analyze.h           |   55 ++++++++++++++++++++++++++++++++++
>   plugin.cc           |   84 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>   plugin.h            |   48 +++++++++++++++++++++++++++++
>   plugin.hh           |   42 ++++++++++++++++++++++++++
>   plugins/skeleton.cc |   31 +++++++++++++++++++
>   xenalyze.c          |   72 +++++++++++++-------------------------------
>   7 files changed, 287 insertions(+), 55 deletions(-)
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,4 +1,4 @@
> -CFLAGS += -g -O2
> +CFLAGS += -g -O2 -I.
>   CFLAGS += -fno-strict-aliasing
>   CFLAGS += -std=gnu99
>   CFLAGS += -Wall -Wstrict-prototypes
> @@ -9,11 +9,15 @@ CFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFI
>   CFLAGS += -mno-tls-direct-seg-refs
>   CFLAGS += -Werror
>
> +CXXFLAGS := -g -O2 -I. -Wall -Werror -std=c++0x
> +
>   BIN := xenalyze dump-raw
>
>   xenalyze_OBJS := \
>   	mread.o \
> -	xenalyze.o
> +	plugin.o \
> +	xenalyze.o \
> +	plugins/skeleton.o
>
>   dump-raw_OBJS := \
>   	dump-raw.o
> @@ -21,7 +25,7 @@ dump-raw_OBJS := \
>   all: $(BIN)
>
>   xenalyze: $(xenalyze_OBJS)
> -	$(CC) $(LDFLAGS) -o $@ $^
> +	$(CXX) $(LDFLAGS) -o $@ $^
>
>   dump-raw: $(dump-raw_OBJS)
>   	$(CC) $(LDFLAGS) -o $@ $^
> @@ -29,6 +33,9 @@ dump-raw: $(dump-raw_OBJS)
>   %.o: %.c
>   	$(CC) $(CFLAGS) -MD -MP -c -o $@ $<
>
> +%.o: %.cc
> +	$(CXX) $(CXXFLAGS) -MD -MP -c -o $@ $<
> +
>   all_objs := $(foreach b,$(BIN),$($(b)_OBJS))
>   all_deps := $(all_objs:.o=.d)
>
> diff --git a/plugin.cc b/plugin.cc
> new file mode 100644
> --- /dev/null
> +++ b/plugin.cc
> @@ -0,0 +1,84 @@
> +/*
> + * Xenalyze plugin infrastructure.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#include<stdio.h>
> +#include<string.h>
> +#include<list>
> +
> +#include "plugin.hh"
> +
> +typedef std::list<struct plugin *>  plugin_list;
> +
> +static plugin_list available;
> +static plugin_list enabled;
> +
> +bool plugin_enable(const char *name)
> +{
> +    for (auto p = available.begin(); p != available.end(); p++) {
> +        struct plugin *plugin = *p;
> +        if (strcmp(plugin->name, name) == 0) {
> +            enabled.push_back(plugin);
> +            if (plugin->enable) {
> +                plugin->enable(plugin);
> +            }
> +            return true;
> +        }
> +    }
> +    return false;
> +}
> +
> +void plugin_process(const struct record_info *ri)
> +{
> +    for (auto p = enabled.begin(); p != enabled.end(); p++) {
> +        struct plugin *plugin = *p;
> +        if (plugin->process) {
> +            plugin->process(plugin, ri);
> +        }
> +    }
> +}
> +
> +void plugin_summary(void)
> +{
> +    for (auto p = enabled.begin(); p != enabled.end(); p++) {
> +        struct plugin *plugin = *p;
> +        if (plugin->summary) {
> +            printf("Summary for %s plugin:\n", plugin->name);
> +            plugin->summary(plugin);
> +        }
> +    }
> +}
> +
> +static void plugin_add(struct plugin *plugin)
> +{
> +    available.push_back(plugin);
> +}
> +
> +void plugin_init(void)
> +{
> +    extern struct plugin *__start_plugin;
> +    extern struct plugin *__stop_plugin;
> +    struct plugin **p;
> +
> +    for (p =&__start_plugin; p<  &__stop_plugin; p++) {
> +        plugin_add(*p);
> +    }
> +}
> +
> +void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri)
> +{
> +    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
> +    p->process(ri);
> +}
> +
> +void plugin_summary_wrapper(struct plugin *plugin)
> +{
> +    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
> +    p->summary();
> +    delete p;
> +}
> diff --git a/plugin.h b/plugin.h
> new file mode 100644
> --- /dev/null
> +++ b/plugin.h
> @@ -0,0 +1,47 @@
> +/*
> + * Xenalyze plugin C API.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#ifndef PLUGIN_H
> +#define PLUGIN_H
> +
> +#include<stdbool.h>
> +
> +#include "analyze.h"
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +struct plugin;
> +
> +typedef void (*plugin_enable_f)(struct plugin *plugin);
> +typedef void (*plugin_process_f)(struct plugin *plugin, const struct record_info *ri);
> +typedef void (*plugin_summary_f)(struct plugin *plugin);
> +
> +struct plugin {
> +    const char *name;
> +    plugin_enable_f enable;
> +    plugin_process_f process;
> +    plugin_summary_f summary;
> +    void *data;
> +};
> +
> +#define DEFINE_PLUGIN(p) \
> +    struct plugin *__plugin_ ## p __attribute__((section("plugin"))) =&p
> +
> +void plugin_init(void);
> +bool plugin_enable(const char *name);
> +void plugin_process(const struct record_info *ri);
> +void plugin_summary(void);
> +
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> +#endif /* #ifndef PLUGIN_H */
> diff --git a/plugin.hh b/plugin.hh
> new file mode 100644
> --- /dev/null
> +++ b/plugin.hh
> @@ -0,0 +1,42 @@
> +/*
> + * Xenalyze plugin C++ API.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#ifndef PLUGIN_HH
> +#define PLUGIN_HH
> +
> +#include "plugin.h"
> +
> +class xenalyze_plugin {
> +public:
> +    virtual ~xenalyze_plugin() {}
> +
> +    virtual void process(const struct record_info *ri) = 0;
> +    virtual void summary() = 0;
> +};
> +
> +#define DEFINE_CXX_PLUGIN(name, cls)                                    \
> +    static void __plugin_ ## cls ## _enable(struct plugin *plugin)      \
> +    {                                                                   \
> +        plugin->data = new cls();                                       \
> +    }                                                                   \
> +                                                                        \
> +    static struct plugin __plugin ## cls = {                            \
> +        name,                                                           \
> +        __plugin_ ## cls ## _enable,                                    \
> +        plugin_process_wrapper,                                         \
> +        plugin_summary_wrapper,                                         \
> +    };                                                                  \
> +    DEFINE_PLUGIN(__plugin ## cls)
> +
> +extern "C" {
> +void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri);
> +void plugin_summary_wrapper(struct plugin *plugin);
> +}
> +
> +#endif /* #ifndef PLUGIN_HH */
> diff --git a/plugins/skeleton.cc b/plugins/skeleton.cc
> new file mode 100644
> --- /dev/null
> +++ b/plugins/skeleton.cc
> @@ -0,0 +1,31 @@
> +/*
> + * Skeleton xenalyze plugin.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#include "plugin.hh"
> +
> +class skeleton_plugin : xenalyze_plugin {
> +public:
> +    skeleton_plugin() {}
> +    ~skeleton_plugin() {}
> +
> +    void process(const struct record_info *ri);
> +    void summary(void);
> +};
> +
> +void skeleton_plugin::process(const struct record_info *ri)
> +{
> +    /* Put per-trace record stuff here. */
> +}
> +
> +void skeleton_plugin::summary(void)
> +{
> +    /* Print a summary of the results (if applicable). */
> +}
> +
> +DEFINE_CXX_PLUGIN("skeleton", skeleton_plugin);
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -32,6 +32,7 @@
>   #include "trace.h"
>   #include "analyze.h"
>   #include "mread.h"
> +#include "plugin.h"
>   #include "pv.h"
>   #include<errno.h>
>   #include<strings.h>
> @@ -8763,6 +8764,8 @@ void process_record(struct pcpu_info *p)
>           default:
>               process_generic(ri);
>           }
> +
> +        plugin_process(ri);
>       }
>
>       UPDATE_VOLUME(p, toplevel[toplevel], ri->size);
> @@ -9346,6 +9349,7 @@ enum {
>       OPT_DUMP_ALL='a',
>       OPT_INTERVAL_LENGTH='i',
>       OPT_SUMMARY='s',
> +    OPT_PLUGIN='p',
>   };
>
>   enum {
> @@ -9816,6 +9820,15 @@ error_t cmd_parser(int key, char *arg, s
>           opt.tsc_loop_fatal = 1;
>           break;
>
> +    case OPT_PLUGIN:
> +        if (plugin_enable(arg)) {
> +            G.output_defined = 1;
> +        } else {
> +            fprintf(stderr, "ERROR: No such plugin `%s'.\n", arg);
> +            exit(1);
> +        }
> +        break;
> +
>       case ARGP_KEY_ARG:
>       {
>           /* FIXME - strcpy */
> @@ -10108,6 +10121,10 @@ const struct argp_option cmd_opts[] =  {
>         .arg = "errlevel",
>         .doc = "Sets tolerance for errors found in the file.  Default is 3; max is 6.", },
>
> +    { .name = "plugin",
> +      .key = OPT_PLUGIN,
> +      .arg = "PLUGIN",
> +      .doc = "Enable a decoder or summary plugin.", },
>
>       { 0 },
>   };
> @@ -10127,6 +10144,8 @@ int main(int argc, char *argv[]) {
>       /* Start with warn at stderr. */
>       warn = stderr;
>
> +    plugin_init();
> +
>       argp_parse(&parser_def, argc, argv, 0, NULL, NULL);
>
>       if (G.trace_file == NULL)
> @@ -10163,6 +10182,8 @@ int main(int argc, char *argv[]) {
>       if(opt.summary)
>           summary();
>
> +    plugin_summary();
> +
>       if(opt.report_pcpu)
>           report_pcpu();
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScaYz-0005M6-0A; Thu, 07 Jun 2012 11:07:37 +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 1ScaYx-0005Lz-Fu
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:07:35 +0000
Received: from [85.158.143.35:60283] by server-3.bemta-4.messagelabs.com id
	D6/3A-29237-67B80DF4; Thu, 07 Jun 2012 11:07:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339067252!11271676!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20871 invoked from network); 7 Jun 2012 11:07:33 -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;
	7 Jun 2012 11:07:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27185343"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:07:31 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 07:07:30 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScaYs-00079l-Dd;
	Thu, 07 Jun 2012 12:07:30 +0100
Message-ID: <4FD08B04.30709@eu.citrix.com>
Date: Thu, 7 Jun 2012 12:05:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
In-Reply-To: <794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Allow xenalyze to be include (at build time) plugins that can do
> per-record actions and a summary.  These plugins can be in C or C++.
>
> The plugins entry points are in struct plugin and pointers to all the
> plugins linked in xenalyze are placed in a "plugin" section so
> plugin_init() can find them all.
>
> A new command line option (-p, --plugin=PLUGIN) is added to enable one
> or more plugins.
>
> A sample plugin (skeleton) is included (mostly because at least one
> plugin must be present for the build to work).
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
So what's the main motivation of having this plugin infrastructure?  The 
one plugin example you have ("batch-size", patch 10) seems simple enough 
that it should be fairly straightforward to just add as an option, with 
not much more boilerplate than C++ already requires.

Looks like potential advantages may include:
* Ability to use C++ language (for those who care for such things)
* Ability to use STL for complex data structures
* Ability to add an option like the "batch-size" plugin in a concise, 
self-contained way

Potential disadvantages include:
* An extra O(N) loop on the hot path (where N = # of enabled plugins)
* For each enabled plugin, an extra full function call on the hot path; 
and a C++ function at that, which (my prejudice tells me) is likely to 
be more wasteful time and space-wise than a C function.

Did I miss anything?

Obviosuly thanks for being conscious of this cost by, for example, 
having a separate list for "enabled" vs "available".

I guess I want to be convinced that allowing this kind of plug-in is 
really worth it, and won't cost too much; especially when something like 
"batch-size" could be implemented in a pretty straightforward way 
without needing a plugin.  I suppose that if there's a plugin that turns 
out to be useful, but is expensive when run as a plug-in, we could 
always pull it into the main file as an optimization.

Also, could you do a simple test to measure the overhead of having no 
plugins?  Just finding a 700MB-ish file you have lying around and 
running "xenalyze -s" with and with this patch (and with this patch and 
-p skeleton or -p batch-size) would be pretty informative, and shouldn't 
take too long.

Thanks,
  -George

> ---
>   Makefile            |   10 +++---
>   analyze.h           |   55 ++++++++++++++++++++++++++++++++++
>   plugin.cc           |   84 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>   plugin.h            |   48 +++++++++++++++++++++++++++++
>   plugin.hh           |   42 ++++++++++++++++++++++++++
>   plugins/skeleton.cc |   31 +++++++++++++++++++
>   xenalyze.c          |   72 +++++++++++++-------------------------------
>   7 files changed, 287 insertions(+), 55 deletions(-)
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,4 +1,4 @@
> -CFLAGS += -g -O2
> +CFLAGS += -g -O2 -I.
>   CFLAGS += -fno-strict-aliasing
>   CFLAGS += -std=gnu99
>   CFLAGS += -Wall -Wstrict-prototypes
> @@ -9,11 +9,15 @@ CFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFI
>   CFLAGS += -mno-tls-direct-seg-refs
>   CFLAGS += -Werror
>
> +CXXFLAGS := -g -O2 -I. -Wall -Werror -std=c++0x
> +
>   BIN := xenalyze dump-raw
>
>   xenalyze_OBJS := \
>   	mread.o \
> -	xenalyze.o
> +	plugin.o \
> +	xenalyze.o \
> +	plugins/skeleton.o
>
>   dump-raw_OBJS := \
>   	dump-raw.o
> @@ -21,7 +25,7 @@ dump-raw_OBJS := \
>   all: $(BIN)
>
>   xenalyze: $(xenalyze_OBJS)
> -	$(CC) $(LDFLAGS) -o $@ $^
> +	$(CXX) $(LDFLAGS) -o $@ $^
>
>   dump-raw: $(dump-raw_OBJS)
>   	$(CC) $(LDFLAGS) -o $@ $^
> @@ -29,6 +33,9 @@ dump-raw: $(dump-raw_OBJS)
>   %.o: %.c
>   	$(CC) $(CFLAGS) -MD -MP -c -o $@ $<
>
> +%.o: %.cc
> +	$(CXX) $(CXXFLAGS) -MD -MP -c -o $@ $<
> +
>   all_objs := $(foreach b,$(BIN),$($(b)_OBJS))
>   all_deps := $(all_objs:.o=.d)
>
> diff --git a/plugin.cc b/plugin.cc
> new file mode 100644
> --- /dev/null
> +++ b/plugin.cc
> @@ -0,0 +1,84 @@
> +/*
> + * Xenalyze plugin infrastructure.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#include<stdio.h>
> +#include<string.h>
> +#include<list>
> +
> +#include "plugin.hh"
> +
> +typedef std::list<struct plugin *>  plugin_list;
> +
> +static plugin_list available;
> +static plugin_list enabled;
> +
> +bool plugin_enable(const char *name)
> +{
> +    for (auto p = available.begin(); p != available.end(); p++) {
> +        struct plugin *plugin = *p;
> +        if (strcmp(plugin->name, name) == 0) {
> +            enabled.push_back(plugin);
> +            if (plugin->enable) {
> +                plugin->enable(plugin);
> +            }
> +            return true;
> +        }
> +    }
> +    return false;
> +}
> +
> +void plugin_process(const struct record_info *ri)
> +{
> +    for (auto p = enabled.begin(); p != enabled.end(); p++) {
> +        struct plugin *plugin = *p;
> +        if (plugin->process) {
> +            plugin->process(plugin, ri);
> +        }
> +    }
> +}
> +
> +void plugin_summary(void)
> +{
> +    for (auto p = enabled.begin(); p != enabled.end(); p++) {
> +        struct plugin *plugin = *p;
> +        if (plugin->summary) {
> +            printf("Summary for %s plugin:\n", plugin->name);
> +            plugin->summary(plugin);
> +        }
> +    }
> +}
> +
> +static void plugin_add(struct plugin *plugin)
> +{
> +    available.push_back(plugin);
> +}
> +
> +void plugin_init(void)
> +{
> +    extern struct plugin *__start_plugin;
> +    extern struct plugin *__stop_plugin;
> +    struct plugin **p;
> +
> +    for (p =&__start_plugin; p<  &__stop_plugin; p++) {
> +        plugin_add(*p);
> +    }
> +}
> +
> +void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri)
> +{
> +    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
> +    p->process(ri);
> +}
> +
> +void plugin_summary_wrapper(struct plugin *plugin)
> +{
> +    xenalyze_plugin *p = static_cast<xenalyze_plugin*>(plugin->data);
> +    p->summary();
> +    delete p;
> +}
> diff --git a/plugin.h b/plugin.h
> new file mode 100644
> --- /dev/null
> +++ b/plugin.h
> @@ -0,0 +1,47 @@
> +/*
> + * Xenalyze plugin C API.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#ifndef PLUGIN_H
> +#define PLUGIN_H
> +
> +#include<stdbool.h>
> +
> +#include "analyze.h"
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +struct plugin;
> +
> +typedef void (*plugin_enable_f)(struct plugin *plugin);
> +typedef void (*plugin_process_f)(struct plugin *plugin, const struct record_info *ri);
> +typedef void (*plugin_summary_f)(struct plugin *plugin);
> +
> +struct plugin {
> +    const char *name;
> +    plugin_enable_f enable;
> +    plugin_process_f process;
> +    plugin_summary_f summary;
> +    void *data;
> +};
> +
> +#define DEFINE_PLUGIN(p) \
> +    struct plugin *__plugin_ ## p __attribute__((section("plugin"))) =&p
> +
> +void plugin_init(void);
> +bool plugin_enable(const char *name);
> +void plugin_process(const struct record_info *ri);
> +void plugin_summary(void);
> +
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> +#endif /* #ifndef PLUGIN_H */
> diff --git a/plugin.hh b/plugin.hh
> new file mode 100644
> --- /dev/null
> +++ b/plugin.hh
> @@ -0,0 +1,42 @@
> +/*
> + * Xenalyze plugin C++ API.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#ifndef PLUGIN_HH
> +#define PLUGIN_HH
> +
> +#include "plugin.h"
> +
> +class xenalyze_plugin {
> +public:
> +    virtual ~xenalyze_plugin() {}
> +
> +    virtual void process(const struct record_info *ri) = 0;
> +    virtual void summary() = 0;
> +};
> +
> +#define DEFINE_CXX_PLUGIN(name, cls)                                    \
> +    static void __plugin_ ## cls ## _enable(struct plugin *plugin)      \
> +    {                                                                   \
> +        plugin->data = new cls();                                       \
> +    }                                                                   \
> +                                                                        \
> +    static struct plugin __plugin ## cls = {                            \
> +        name,                                                           \
> +        __plugin_ ## cls ## _enable,                                    \
> +        plugin_process_wrapper,                                         \
> +        plugin_summary_wrapper,                                         \
> +    };                                                                  \
> +    DEFINE_PLUGIN(__plugin ## cls)
> +
> +extern "C" {
> +void plugin_process_wrapper(struct plugin *plugin, const struct record_info *ri);
> +void plugin_summary_wrapper(struct plugin *plugin);
> +}
> +
> +#endif /* #ifndef PLUGIN_HH */
> diff --git a/plugins/skeleton.cc b/plugins/skeleton.cc
> new file mode 100644
> --- /dev/null
> +++ b/plugins/skeleton.cc
> @@ -0,0 +1,31 @@
> +/*
> + * Skeleton xenalyze plugin.
> + *
> + * Copyright (C) 2012, 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.
> + */
> +#include "plugin.hh"
> +
> +class skeleton_plugin : xenalyze_plugin {
> +public:
> +    skeleton_plugin() {}
> +    ~skeleton_plugin() {}
> +
> +    void process(const struct record_info *ri);
> +    void summary(void);
> +};
> +
> +void skeleton_plugin::process(const struct record_info *ri)
> +{
> +    /* Put per-trace record stuff here. */
> +}
> +
> +void skeleton_plugin::summary(void)
> +{
> +    /* Print a summary of the results (if applicable). */
> +}
> +
> +DEFINE_CXX_PLUGIN("skeleton", skeleton_plugin);
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -32,6 +32,7 @@
>   #include "trace.h"
>   #include "analyze.h"
>   #include "mread.h"
> +#include "plugin.h"
>   #include "pv.h"
>   #include<errno.h>
>   #include<strings.h>
> @@ -8763,6 +8764,8 @@ void process_record(struct pcpu_info *p)
>           default:
>               process_generic(ri);
>           }
> +
> +        plugin_process(ri);
>       }
>
>       UPDATE_VOLUME(p, toplevel[toplevel], ri->size);
> @@ -9346,6 +9349,7 @@ enum {
>       OPT_DUMP_ALL='a',
>       OPT_INTERVAL_LENGTH='i',
>       OPT_SUMMARY='s',
> +    OPT_PLUGIN='p',
>   };
>
>   enum {
> @@ -9816,6 +9820,15 @@ error_t cmd_parser(int key, char *arg, s
>           opt.tsc_loop_fatal = 1;
>           break;
>
> +    case OPT_PLUGIN:
> +        if (plugin_enable(arg)) {
> +            G.output_defined = 1;
> +        } else {
> +            fprintf(stderr, "ERROR: No such plugin `%s'.\n", arg);
> +            exit(1);
> +        }
> +        break;
> +
>       case ARGP_KEY_ARG:
>       {
>           /* FIXME - strcpy */
> @@ -10108,6 +10121,10 @@ const struct argp_option cmd_opts[] =  {
>         .arg = "errlevel",
>         .doc = "Sets tolerance for errors found in the file.  Default is 3; max is 6.", },
>
> +    { .name = "plugin",
> +      .key = OPT_PLUGIN,
> +      .arg = "PLUGIN",
> +      .doc = "Enable a decoder or summary plugin.", },
>
>       { 0 },
>   };
> @@ -10127,6 +10144,8 @@ int main(int argc, char *argv[]) {
>       /* Start with warn at stderr. */
>       warn = stderr;
>
> +    plugin_init();
> +
>       argp_parse(&parser_def, argc, argv, 0, NULL, NULL);
>
>       if (G.trace_file == NULL)
> @@ -10163,6 +10182,8 @@ int main(int argc, char *argv[]) {
>       if(opt.summary)
>           summary();
>
> +    plugin_summary();
> +
>       if(opt.report_pcpu)
>           report_pcpu();
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:25:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:25: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 1Scaq3-0005cv-O1; Thu, 07 Jun 2012 11:25:15 +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 1Scaq1-0005cn-I4
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:25:13 +0000
Received: from [85.158.138.51:18163] by server-9.bemta-3.messagelabs.com id
	68/63-15054-89F80DF4; Thu, 07 Jun 2012 11:25:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339068310!31293763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14678 invoked from network); 7 Jun 2012 11:25:11 -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 Jun 2012 11:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27186768"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:25:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 07:25:08 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScaeR-0007Jd-Ov;
	Thu, 07 Jun 2012 12:13:15 +0100
Message-ID: <4FD08C5E.3010201@eu.citrix.com>
Date: Thu, 7 Jun 2012 12:11:26 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<5723153376e0d7102012.1338462982@qabil.uk.xensource.com>
In-Reply-To: <5723153376e0d7102012.1338462982@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenalyze: move struct record_info
	into a 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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Split out struct record_info onto the analyze.h so it can be used
> outside of xenalyze.c.
I assume this is mainly to support the plugin infrastructure?

  -George
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
> ---
>
> diff --git a/analyze.h b/analyze.h
> --- a/analyze.h
> +++ b/analyze.h
> @@ -1,5 +1,8 @@
>   #ifndef __ANALYZE_H
>   # define __ANALYZE_H
> +
> +#include<stdint.h>
> +
>   #define TRC_GEN_MAIN     0
>   #define TRC_SCHED_MAIN   1
>   #define TRC_DOM0OP_MAIN  2
> @@ -47,4 +50,56 @@ enum {
>   };
>
>   #define TRC_HVM_OP_DESTROY_PROC (TRC_HVM_HANDLER + 0x100)
> +
> +typedef unsigned long long tsc_t;
> +
> +/* -- on-disk trace buffer definitions -- */
> +struct trace_record {
> +    union {
> +        struct {
> +            unsigned event:28,
> +                extra_words:3,
> +                cycle_flag:1;
> +            union {
> +                struct {
> +                    uint32_t tsc_lo, tsc_hi;
> +                    uint32_t data[7];
> +                } tsc;
> +                struct {
> +                    uint32_t data[7];
> +                } notsc;
> +            } u;
> +        };
> +        uint32_t raw[8];
> +    };
> +};
> +
> +/* -- General info about a current record -- */
> +struct time_struct {
> +    unsigned long long time;
> +    unsigned int s, ns;
> +};
> +
> +#define DUMP_HEADER_MAX 256
> +
> +struct record_info {
> +    int cpu;
> +    tsc_t tsc;
> +    union {
> +        unsigned event;
> +        struct {
> +            unsigned minor:12,
> +                sub:4,
> +                main:12,
> +                unused:4;
> +        } evt;
> +    };
> +    int extra_words;
> +    int size;
> +    uint32_t *d;
> +    char dump_header[DUMP_HEADER_MAX];
> +    struct time_struct t;
> +    struct trace_record rec;
> +};
> +
>   #endif
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -40,8 +40,6 @@
>   struct mread_ctrl;
>
>
> -typedef unsigned long long tsc_t;
> -
>   #define DEFAULT_CPU_HZ 2400000000LL
>   #define ADDR_SPACE_BITS 48
>   #define DEFAULT_SAMPLE_SIZE 10240
> @@ -260,57 +258,8 @@ struct {
>       .interval = { .msec = DEFAULT_INTERVAL_LENGTH },
>   };
>
> -/* -- on-disk trace buffer definitions -- */
> -struct trace_record {
> -    union {
> -        struct {
> -            unsigned event:28,
> -                extra_words:3,
> -                cycle_flag:1;
> -            union {
> -                struct {
> -                    uint32_t tsc_lo, tsc_hi;
> -                    uint32_t data[7];
> -                } tsc;
> -                struct {
> -                    uint32_t data[7];
> -                } notsc;
> -            } u;
> -        };
> -        uint32_t raw[8];
> -    };
> -};
> -
>   FILE *warn = NULL;
>
> -/* -- General info about a current record -- */
> -struct time_struct {
> -    unsigned long long time;
> -    unsigned int s, ns;
> -};
> -
> -#define DUMP_HEADER_MAX 256
> -
> -struct record_info {
> -    int cpu;
> -    tsc_t tsc;
> -    union {
> -        unsigned event;
> -        struct {
> -            unsigned minor:12,
> -                sub:4,
> -                main:12,
> -                unused:4;
> -        } evt;
> -    };
> -    int extra_words;
> -    int size;
> -    uint32_t *d;
> -    char dump_header[DUMP_HEADER_MAX];
> -    struct time_struct t;
> -    struct trace_record rec;
> -};
> -
>   /* -- Summary data -- */
>   struct cycle_framework {
>       tsc_t first_tsc, last_tsc, total_cycles;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:25:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:25: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 1Scaq3-0005cv-O1; Thu, 07 Jun 2012 11:25:15 +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 1Scaq1-0005cn-I4
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:25:13 +0000
Received: from [85.158.138.51:18163] by server-9.bemta-3.messagelabs.com id
	68/63-15054-89F80DF4; Thu, 07 Jun 2012 11:25:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339068310!31293763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14678 invoked from network); 7 Jun 2012 11:25:11 -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 Jun 2012 11:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27186768"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:25:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 07:25:08 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScaeR-0007Jd-Ov;
	Thu, 07 Jun 2012 12:13:15 +0100
Message-ID: <4FD08C5E.3010201@eu.citrix.com>
Date: Thu, 7 Jun 2012 12:11:26 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<5723153376e0d7102012.1338462982@qabil.uk.xensource.com>
In-Reply-To: <5723153376e0d7102012.1338462982@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenalyze: move struct record_info
	into a 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-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Split out struct record_info onto the analyze.h so it can be used
> outside of xenalyze.c.
I assume this is mainly to support the plugin infrastructure?

  -George
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
> ---
>
> diff --git a/analyze.h b/analyze.h
> --- a/analyze.h
> +++ b/analyze.h
> @@ -1,5 +1,8 @@
>   #ifndef __ANALYZE_H
>   # define __ANALYZE_H
> +
> +#include<stdint.h>
> +
>   #define TRC_GEN_MAIN     0
>   #define TRC_SCHED_MAIN   1
>   #define TRC_DOM0OP_MAIN  2
> @@ -47,4 +50,56 @@ enum {
>   };
>
>   #define TRC_HVM_OP_DESTROY_PROC (TRC_HVM_HANDLER + 0x100)
> +
> +typedef unsigned long long tsc_t;
> +
> +/* -- on-disk trace buffer definitions -- */
> +struct trace_record {
> +    union {
> +        struct {
> +            unsigned event:28,
> +                extra_words:3,
> +                cycle_flag:1;
> +            union {
> +                struct {
> +                    uint32_t tsc_lo, tsc_hi;
> +                    uint32_t data[7];
> +                } tsc;
> +                struct {
> +                    uint32_t data[7];
> +                } notsc;
> +            } u;
> +        };
> +        uint32_t raw[8];
> +    };
> +};
> +
> +/* -- General info about a current record -- */
> +struct time_struct {
> +    unsigned long long time;
> +    unsigned int s, ns;
> +};
> +
> +#define DUMP_HEADER_MAX 256
> +
> +struct record_info {
> +    int cpu;
> +    tsc_t tsc;
> +    union {
> +        unsigned event;
> +        struct {
> +            unsigned minor:12,
> +                sub:4,
> +                main:12,
> +                unused:4;
> +        } evt;
> +    };
> +    int extra_words;
> +    int size;
> +    uint32_t *d;
> +    char dump_header[DUMP_HEADER_MAX];
> +    struct time_struct t;
> +    struct trace_record rec;
> +};
> +
>   #endif
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -40,8 +40,6 @@
>   struct mread_ctrl;
>
>
> -typedef unsigned long long tsc_t;
> -
>   #define DEFAULT_CPU_HZ 2400000000LL
>   #define ADDR_SPACE_BITS 48
>   #define DEFAULT_SAMPLE_SIZE 10240
> @@ -260,57 +258,8 @@ struct {
>       .interval = { .msec = DEFAULT_INTERVAL_LENGTH },
>   };
>
> -/* -- on-disk trace buffer definitions -- */
> -struct trace_record {
> -    union {
> -        struct {
> -            unsigned event:28,
> -                extra_words:3,
> -                cycle_flag:1;
> -            union {
> -                struct {
> -                    uint32_t tsc_lo, tsc_hi;
> -                    uint32_t data[7];
> -                } tsc;
> -                struct {
> -                    uint32_t data[7];
> -                } notsc;
> -            } u;
> -        };
> -        uint32_t raw[8];
> -    };
> -};
> -
>   FILE *warn = NULL;
>
> -/* -- General info about a current record -- */
> -struct time_struct {
> -    unsigned long long time;
> -    unsigned int s, ns;
> -};
> -
> -#define DUMP_HEADER_MAX 256
> -
> -struct record_info {
> -    int cpu;
> -    tsc_t tsc;
> -    union {
> -        unsigned event;
> -        struct {
> -            unsigned minor:12,
> -                sub:4,
> -                main:12,
> -                unused:4;
> -        } evt;
> -    };
> -    int extra_words;
> -    int size;
> -    uint32_t *d;
> -    char dump_header[DUMP_HEADER_MAX];
> -    struct time_struct t;
> -    struct trace_record rec;
> -};
> -
>   /* -- Summary data -- */
>   struct cycle_framework {
>       tsc_t first_tsc, last_tsc, total_cycles;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:31:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:31: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 1Scaw6-0005yR-8X; Thu, 07 Jun 2012 11:31:30 +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 1Scaw4-0005yM-JA
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:31:28 +0000
Received: from [85.158.143.35:41468] by server-2.bemta-4.messagelabs.com id
	6E/30-17938-F0190DF4; Thu, 07 Jun 2012 11:31:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339068683!14453107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26373 invoked from network); 7 Jun 2012 11:31:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:31:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27187214"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:31:23 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:31:22 -0400
Message-ID: <4FD09109.4030409@citrix.com>
Date: Thu, 7 Jun 2012 12:31:21 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<5723153376e0d7102012.1338462982@qabil.uk.xensource.com>
	<4FD08C5E.3010201@eu.citrix.com>
In-Reply-To: <4FD08C5E.3010201@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenalyze: move struct record_info
	into a 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 07/06/12 12:11, George Dunlap wrote:
> On 31/05/12 12:16, David Vrabel wrote:
>> Split out struct record_info onto the analyze.h so it can be used
>> outside of xenalyze.c.
> I assume this is mainly to support the plugin infrastructure?

Yes,  but it will also make it easier to split up the enormous
xenalyze.c file in the future.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:31:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:31: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 1Scaw6-0005yR-8X; Thu, 07 Jun 2012 11:31:30 +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 1Scaw4-0005yM-JA
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:31:28 +0000
Received: from [85.158.143.35:41468] by server-2.bemta-4.messagelabs.com id
	6E/30-17938-F0190DF4; Thu, 07 Jun 2012 11:31:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339068683!14453107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk1NTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26373 invoked from network); 7 Jun 2012 11:31:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:31:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="27187214"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:31:23 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	07:31:22 -0400
Message-ID: <4FD09109.4030409@citrix.com>
Date: Thu, 7 Jun 2012 12:31:21 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<5723153376e0d7102012.1338462982@qabil.uk.xensource.com>
	<4FD08C5E.3010201@eu.citrix.com>
In-Reply-To: <4FD08C5E.3010201@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenalyze: move struct record_info
	into a 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 07/06/12 12:11, George Dunlap wrote:
> On 31/05/12 12:16, David Vrabel wrote:
>> Split out struct record_info onto the analyze.h so it can be used
>> outside of xenalyze.c.
> I assume this is mainly to support the plugin infrastructure?

Yes,  but it will also make it easier to split up the enormous
xenalyze.c file in the future.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:33:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scay4-00066W-Oe; Thu, 07 Jun 2012 11:33:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1Scay3-00065w-DR
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:33:31 +0000
Received: from [85.158.143.35:56268] by server-1.bemta-4.messagelabs.com id
	C3/A3-10042-A8190DF4; Thu, 07 Jun 2012 11:33:30 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339068809!15221548!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8301 invoked from network); 7 Jun 2012 11:33:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:33:29 -0000
Received: by wgbed3 with SMTP id ed3so298195wgb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 04:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8CSeQGUuV2JFqF8Y5kCvN9DVu9ds4PGZDgCjJhye/A4=;
	b=D3FzCOv7tgpJYOGstCnoA+TgsWr6X7ZLCpS1nMLBPJT7bLxt4aH7kvZ/4xu27CL3cX
	soO02U4v6rjMLf7y4ttXDlWA6syZCDiy4HdHvX/ZQAIHkBl42X0jhZ8YCDuIvBpowotj
	9ULwzo1mA5U8Y1SEkGndQsCZJF0jjL4TlaAWCXLTiKuWaYa46YoNJeO5ySdPYwNamLkr
	ZrwoJGfqKe+sIXpybTDp5jU9pOcZFNudPS+MI6hcM9EZLX3xeJDDGCIKiUI4QpD/r57K
	XaOIaQeyx1ihn1yy5+QUKts0pMcCo7hfeYJc9+Ek/9Q/Z7we68tFjEr6xaTiAIolbZ7V
	xHEw==
MIME-Version: 1.0
Received: by 10.216.27.199 with SMTP id e49mr648389wea.45.1339068809615; Thu,
	07 Jun 2012 04:33:29 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Thu, 7 Jun 2012 04:33:29 -0700 (PDT)
In-Reply-To: <CAFuBCajci2vcyuUDLHADiU1YTDpSwzZGHF4ngt=eWNrDfjZv5w@mail.gmail.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD04D70.1030805@icg.tugraz.at>
	<CAFuBCajci2vcyuUDLHADiU1YTDpSwzZGHF4ngt=eWNrDfjZv5w@mail.gmail.com>
Date: Thu, 7 Jun 2012 12:33:29 +0100
Message-ID: <CAFuBCaj-GB7iV7qF-0CbbGgQxx95bDd4XuMrqxNEkPWUsvWTsQ@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: dokter@icg.tugraz.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3971348768970572645=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3971348768970572645==
Content-Type: multipart/alternative; boundary=0016e6d7ef65ba1ab104c1e040db

--0016e6d7ef65ba1ab104c1e040db
Content-Type: text/plain; charset=ISO-8859-1

Hi,

 I try with xl tool, but the error is the same.

On Thu, Jun 7, 2012 at 8:57 AM, elahe shekuhi <e.shekuhi@gmail.com> wrote:

> Hi,
>
> How to use "xl"? Should xend be disable? How do I configure host and
> destination machines for live migration? Is it as before like for xm
> utility?
>
>
> On Thu, Jun 7, 2012 at 7:42 AM, Mark Dokter <dokter@icg.tugraz.at> wrote:
>
>> On 06/06/2012 08:15 PM, elahe shekuhi wrote:
>> > Hi,
>> >
>>
>> Hi!
>>
>> Maybe you could try using xl instead of xm. They behave differently
>> concerning sources of errors imho.
>>
>> hth, Mark
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>
>

--0016e6d7ef65ba1ab104c1e040db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>=A0I try with xl tool, but the error is the sam=
e.<br><br><div class=3D"gmail_quote">On Thu, Jun 7, 2012 at 8:57 AM, elahe =
shekuhi <span dir=3D"ltr">&lt;<a href=3D"mailto:e.shekuhi@gmail.com" target=
=3D"_blank">e.shekuhi@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 dir=3D"ltr">Hi,<br><br>How to use &quot=
;xl&quot;? Should xend be disable? How do I configure host and destination =
machines for live migration? Is it as before like for xm utility?<div>
<div class=3D"h5"><br><br><div class=3D"gmail_quote">On Thu, Jun 7, 2012 at=
 7:42 AM, Mark Dokter <span dir=3D"ltr">&lt;<a href=3D"mailto:dokter@icg.tu=
graz.at" target=3D"_blank">dokter@icg.tugraz.at</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">On 06/06/2012 08:15 PM, elahe shekuhi wrote:=
<br>
&gt; Hi,<br>
&gt;<br>
<br>
Hi!<br>
<br>
Maybe you could try using xl instead of xm. They behave differently<br>
concerning sources of errors imho.<br>
<br>
hth, Mark<br>
<div><div><br>
_______________________________________________<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>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>

--0016e6d7ef65ba1ab104c1e040db--


--===============3971348768970572645==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3971348768970572645==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 11:33:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scay4-00066W-Oe; Thu, 07 Jun 2012 11:33:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1Scay3-00065w-DR
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:33:31 +0000
Received: from [85.158.143.35:56268] by server-1.bemta-4.messagelabs.com id
	C3/A3-10042-A8190DF4; Thu, 07 Jun 2012 11:33:30 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339068809!15221548!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8301 invoked from network); 7 Jun 2012 11:33:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:33:29 -0000
Received: by wgbed3 with SMTP id ed3so298195wgb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 04:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8CSeQGUuV2JFqF8Y5kCvN9DVu9ds4PGZDgCjJhye/A4=;
	b=D3FzCOv7tgpJYOGstCnoA+TgsWr6X7ZLCpS1nMLBPJT7bLxt4aH7kvZ/4xu27CL3cX
	soO02U4v6rjMLf7y4ttXDlWA6syZCDiy4HdHvX/ZQAIHkBl42X0jhZ8YCDuIvBpowotj
	9ULwzo1mA5U8Y1SEkGndQsCZJF0jjL4TlaAWCXLTiKuWaYa46YoNJeO5ySdPYwNamLkr
	ZrwoJGfqKe+sIXpybTDp5jU9pOcZFNudPS+MI6hcM9EZLX3xeJDDGCIKiUI4QpD/r57K
	XaOIaQeyx1ihn1yy5+QUKts0pMcCo7hfeYJc9+Ek/9Q/Z7we68tFjEr6xaTiAIolbZ7V
	xHEw==
MIME-Version: 1.0
Received: by 10.216.27.199 with SMTP id e49mr648389wea.45.1339068809615; Thu,
	07 Jun 2012 04:33:29 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Thu, 7 Jun 2012 04:33:29 -0700 (PDT)
In-Reply-To: <CAFuBCajci2vcyuUDLHADiU1YTDpSwzZGHF4ngt=eWNrDfjZv5w@mail.gmail.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD04D70.1030805@icg.tugraz.at>
	<CAFuBCajci2vcyuUDLHADiU1YTDpSwzZGHF4ngt=eWNrDfjZv5w@mail.gmail.com>
Date: Thu, 7 Jun 2012 12:33:29 +0100
Message-ID: <CAFuBCaj-GB7iV7qF-0CbbGgQxx95bDd4XuMrqxNEkPWUsvWTsQ@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: dokter@icg.tugraz.at
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3971348768970572645=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3971348768970572645==
Content-Type: multipart/alternative; boundary=0016e6d7ef65ba1ab104c1e040db

--0016e6d7ef65ba1ab104c1e040db
Content-Type: text/plain; charset=ISO-8859-1

Hi,

 I try with xl tool, but the error is the same.

On Thu, Jun 7, 2012 at 8:57 AM, elahe shekuhi <e.shekuhi@gmail.com> wrote:

> Hi,
>
> How to use "xl"? Should xend be disable? How do I configure host and
> destination machines for live migration? Is it as before like for xm
> utility?
>
>
> On Thu, Jun 7, 2012 at 7:42 AM, Mark Dokter <dokter@icg.tugraz.at> wrote:
>
>> On 06/06/2012 08:15 PM, elahe shekuhi wrote:
>> > Hi,
>> >
>>
>> Hi!
>>
>> Maybe you could try using xl instead of xm. They behave differently
>> concerning sources of errors imho.
>>
>> hth, Mark
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>
>

--0016e6d7ef65ba1ab104c1e040db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>=A0I try with xl tool, but the error is the sam=
e.<br><br><div class=3D"gmail_quote">On Thu, Jun 7, 2012 at 8:57 AM, elahe =
shekuhi <span dir=3D"ltr">&lt;<a href=3D"mailto:e.shekuhi@gmail.com" target=
=3D"_blank">e.shekuhi@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 dir=3D"ltr">Hi,<br><br>How to use &quot=
;xl&quot;? Should xend be disable? How do I configure host and destination =
machines for live migration? Is it as before like for xm utility?<div>
<div class=3D"h5"><br><br><div class=3D"gmail_quote">On Thu, Jun 7, 2012 at=
 7:42 AM, Mark Dokter <span dir=3D"ltr">&lt;<a href=3D"mailto:dokter@icg.tu=
graz.at" target=3D"_blank">dokter@icg.tugraz.at</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">On 06/06/2012 08:15 PM, elahe shekuhi wrote:=
<br>
&gt; Hi,<br>
&gt;<br>
<br>
Hi!<br>
<br>
Maybe you could try using xl instead of xm. They behave differently<br>
concerning sources of errors imho.<br>
<br>
hth, Mark<br>
<div><div><br>
_______________________________________________<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>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>

--0016e6d7ef65ba1ab104c1e040db--


--===============3971348768970572645==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3971348768970572645==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 11:36:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scb0K-0006R5-Bu; Thu, 07 Jun 2012 11:35: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 1Scb0I-0006Qq-Uw
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:35:51 +0000
Received: from [85.158.143.99:55928] by server-1.bemta-4.messagelabs.com id
	CA/57-10042-61290DF4; Thu, 07 Jun 2012 11:35:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339068948!24200794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 7 Jun 2012 11:35:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:35:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:35:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	12:35:48 +0100
Message-ID: <1339068947.18523.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Date: Thu, 7 Jun 2012 12:35:47 +0100
In-Reply-To: <20120607090808.GD70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
	<20120607090808.GD70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,
 core}_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

(Keir, this slightly touches common code...)

On Thu, 2012-06-07 at 10:08 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565185), Ian Campbell wrote:
> > @@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
> >          }
> >      }
> >  
> > +    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
> > +         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
> > +        BUG();
> > +
> > +    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
> > +    cpumask_clear(per_cpu(cpu_core_mask, 0));
> 
> Aren't these clear()s noops?  

Yes, they were also incorrect since a CPU is it's own sibling and shares
a core with itself. Otherwise all manner of weirdness ensues (see commit
message). These also need to be setup on all CPUs.

I replaced this patch with the following.

Ian.

8<------------------------------------------------------

>From e980ca1ec9bf92b2f1255ac5222b1da1292f9f72 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 12:25:31 +0100
Subject: [PATCH] arm: Add simple cpu_{sibling,core}_mask

This needs to be done for all cpus. The allocations require smp_prepare_cpus
to be called a bit later on.

In a previous version of this patch these maps were being zeroed (instead of
setting the CPU itself in them). This in turn causes cpumask_first to return
NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
read off the end of its cnt array. Add a couple of asserts to catch this in
the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S   |    2 --
 xen/arch/arm/setup.c   |    4 ++--
 xen/arch/arm/smpboot.c |   21 +++++++++++++++++++++
 xen/common/domctl.c    |    2 ++
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index c001e8d..03f7489 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 81ababb..d6c0178 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -173,8 +173,6 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    smp_prepare_cpus(cpus);
-
     init_xen_time();
 
     setup_mm(atag_paddr, fdt_size);
@@ -214,6 +212,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     local_irq_enable();
 
+    smp_prepare_cpus(cpus);
+
     initialize_keytable();
 
     console_init_postirq();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ea05afc..6463a8d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,6 +52,23 @@ unsigned long __initdata ready_cpus = 0;
 
 /* ID of the PCPU we're running on */
 DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awfully x86ish... */
+/* representing HT siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
+/* representing HT and core siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
+
+static void setup_cpu_sibling_map(int cpu)
+{
+    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) ||
+         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) )
+        panic("No memory for CPU sibling/core maps\n");
+
+    /* A CPU is a sibling with itself and is always on its own core. */
+    cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
+    cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
+}
+
 
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
@@ -65,6 +82,8 @@ smp_prepare_cpus (unsigned int max_cpus)
     for ( i = 0; i < max_cpus; i++ )
         cpumask_set_cpu(i, &cpu_possible_map);
     cpumask_copy(&cpu_present_map, &cpu_possible_map);
+
+    setup_cpu_sibling_map(0);
 }
 
 void __init
@@ -115,6 +134,8 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
 
     set_current(idle_vcpu[cpuid]);
 
+    setup_cpu_sibling_map(cpuid);
+
     /* Run local notifiers */
     notify_cpu_starting(cpuid);
     wmb();
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..c1acd1d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
      */
     cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
     cpu = cpumask_first(&cpu_exclude_map);
+    ASSERT(cpu < nr_cpus);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
     for_each_cpu(i, online)
     {
+        ASSERT(i < nr_cpus);
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
             continue;
         if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&
-- 
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 Thu Jun 07 11:36:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scb0K-0006R5-Bu; Thu, 07 Jun 2012 11:35: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 1Scb0I-0006Qq-Uw
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:35:51 +0000
Received: from [85.158.143.99:55928] by server-1.bemta-4.messagelabs.com id
	CA/57-10042-61290DF4; Thu, 07 Jun 2012 11:35:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339068948!24200794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 7 Jun 2012 11:35:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:35:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:35:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	12:35:48 +0100
Message-ID: <1339068947.18523.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>
Date: Thu, 7 Jun 2012 12:35:47 +0100
In-Reply-To: <20120607090808.GD70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
	<20120607090808.GD70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,
 core}_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

(Keir, this slightly touches common code...)

On Thu, 2012-06-07 at 10:08 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565185), Ian Campbell wrote:
> > @@ -230,6 +230,13 @@ void __init start_xen(unsigned long boot_phys_offset,
> >          }
> >      }
> >  
> > +    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) ||
> > +         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, 0)) )
> > +        BUG();
> > +
> > +    cpumask_clear(per_cpu(cpu_sibling_mask, 0));
> > +    cpumask_clear(per_cpu(cpu_core_mask, 0));
> 
> Aren't these clear()s noops?  

Yes, they were also incorrect since a CPU is it's own sibling and shares
a core with itself. Otherwise all manner of weirdness ensues (see commit
message). These also need to be setup on all CPUs.

I replaced this patch with the following.

Ian.

8<------------------------------------------------------

>From e980ca1ec9bf92b2f1255ac5222b1da1292f9f72 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 12:25:31 +0100
Subject: [PATCH] arm: Add simple cpu_{sibling,core}_mask

This needs to be done for all cpus. The allocations require smp_prepare_cpus
to be called a bit later on.

In a previous version of this patch these maps were being zeroed (instead of
setting the CPU itself in them). This in turn causes cpumask_first to return
NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
read off the end of its cnt array. Add a couple of asserts to catch this in
the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S   |    2 --
 xen/arch/arm/setup.c   |    4 ++--
 xen/arch/arm/smpboot.c |   21 +++++++++++++++++++++
 xen/common/domctl.c    |    2 ++
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index c001e8d..03f7489 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 81ababb..d6c0178 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -173,8 +173,6 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    smp_prepare_cpus(cpus);
-
     init_xen_time();
 
     setup_mm(atag_paddr, fdt_size);
@@ -214,6 +212,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     local_irq_enable();
 
+    smp_prepare_cpus(cpus);
+
     initialize_keytable();
 
     console_init_postirq();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ea05afc..6463a8d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,6 +52,23 @@ unsigned long __initdata ready_cpus = 0;
 
 /* ID of the PCPU we're running on */
 DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awfully x86ish... */
+/* representing HT siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
+/* representing HT and core siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
+
+static void setup_cpu_sibling_map(int cpu)
+{
+    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) ||
+         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) )
+        panic("No memory for CPU sibling/core maps\n");
+
+    /* A CPU is a sibling with itself and is always on its own core. */
+    cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
+    cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
+}
+
 
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
@@ -65,6 +82,8 @@ smp_prepare_cpus (unsigned int max_cpus)
     for ( i = 0; i < max_cpus; i++ )
         cpumask_set_cpu(i, &cpu_possible_map);
     cpumask_copy(&cpu_present_map, &cpu_possible_map);
+
+    setup_cpu_sibling_map(0);
 }
 
 void __init
@@ -115,6 +134,8 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
 
     set_current(idle_vcpu[cpuid]);
 
+    setup_cpu_sibling_map(cpuid);
+
     /* Run local notifiers */
     notify_cpu_starting(cpuid);
     wmb();
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..c1acd1d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
      */
     cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
     cpu = cpumask_first(&cpu_exclude_map);
+    ASSERT(cpu < nr_cpus);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
     for_each_cpu(i, online)
     {
+        ASSERT(i < nr_cpus);
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
             continue;
         if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&
-- 
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 Thu Jun 07 11:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scb1W-0006Yb-Sh; Thu, 07 Jun 2012 11:37:06 +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 1Scb1V-0006YQ-EQ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:37:05 +0000
Received: from [85.158.138.51:39391] by server-1.bemta-3.messagelabs.com id
	11/13-01327-06290DF4; Thu, 07 Jun 2012 11:37:04 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339069022!31329244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25694 invoked from network); 7 Jun 2012 11:37:04 -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;
	7 Jun 2012 11:37:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="197863088"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:37:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 07:37:02 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scb1R-00085K-Mr;
	Thu, 07 Jun 2012 12:37:01 +0100
Message-ID: <4FD091F0.4040209@eu.citrix.com>
Date: Thu, 7 Jun 2012 12:35:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d5f631485ce7fb1f1f4f.1338462983@qabil.uk.xensource.com>
In-Reply-To: <d5f631485ce7fb1f1f4f.1338462983@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] xenalyze: decode PV_HYPERCALL_V2
	records
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of
> the older TRC_PV_HYPERCALL format.  This updated format doesn't
> included the IP but it does include select hypercall arguments.
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
>
> diff --git a/pv.h b/pv.h
> new file mode 100644
> --- /dev/null
> +++ b/pv.h
Why does this need its own file?
> +static const char *grant_table_op_cmd_to_str(uint32_t cmd)
Hmm -- this is a different style to the other lists of this type.  I 
guess I like having it in a function.
> +{
> +    const char *cmd_str[] = {
> +        "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table",
> +        "transfer", "copy", "query_size", "unmap_and_replace",
> +        "set_version", "get_status_frames", "get_version", "swap_grant_ref",
> +    };
I'm a bit wary of having stuff just in a big list like this -- it seems 
like it makes it harder to double-check that you've gotten the right 
match-up.  I'd prefer it look like hvm_event_handler_name[], where the 
number is annotated with a comment from time to time.
> +    static char buf[32];
> +
> +    if (cmd<= 11)
> +        return cmd_str[cmd];
Instead of hardcoding the number of elements, could you use some 
calculation involving sizeof() to get that automatically?  In any case, 
it should be "cmd < N", rather than "cmd <= N-1" (where N is the number 
of elements in the array).
> +        switch(op) {
> +        case HYPERCALL_mmu_update:
> +            {
I'm not a fan of indenting a brace within a case statement -- I think 
this is emacs' default C mode, but I prefer it the other way.   (Not 
sure which config option sets this, though.)

Other than that, looks good.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scb1W-0006Yb-Sh; Thu, 07 Jun 2012 11:37:06 +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 1Scb1V-0006YQ-EQ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 11:37:05 +0000
Received: from [85.158.138.51:39391] by server-1.bemta-3.messagelabs.com id
	11/13-01327-06290DF4; Thu, 07 Jun 2012 11:37:04 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339069022!31329244!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25694 invoked from network); 7 Jun 2012 11:37:04 -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;
	7 Jun 2012 11:37:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330923600"; d="scan'208";a="197863088"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 07:37:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 07:37:02 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scb1R-00085K-Mr;
	Thu, 07 Jun 2012 12:37:01 +0100
Message-ID: <4FD091F0.4040209@eu.citrix.com>
Date: Thu, 7 Jun 2012 12:35:12 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d5f631485ce7fb1f1f4f.1338462983@qabil.uk.xensource.com>
In-Reply-To: <d5f631485ce7fb1f1f4f.1338462983@qabil.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] xenalyze: decode PV_HYPERCALL_V2
	records
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/05/12 12:16, David Vrabel wrote:
> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of
> the older TRC_PV_HYPERCALL format.  This updated format doesn't
> included the IP but it does include select hypercall arguments.
>
> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
>
> diff --git a/pv.h b/pv.h
> new file mode 100644
> --- /dev/null
> +++ b/pv.h
Why does this need its own file?
> +static const char *grant_table_op_cmd_to_str(uint32_t cmd)
Hmm -- this is a different style to the other lists of this type.  I 
guess I like having it in a function.
> +{
> +    const char *cmd_str[] = {
> +        "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table",
> +        "transfer", "copy", "query_size", "unmap_and_replace",
> +        "set_version", "get_status_frames", "get_version", "swap_grant_ref",
> +    };
I'm a bit wary of having stuff just in a big list like this -- it seems 
like it makes it harder to double-check that you've gotten the right 
match-up.  I'd prefer it look like hvm_event_handler_name[], where the 
number is annotated with a comment from time to time.
> +    static char buf[32];
> +
> +    if (cmd<= 11)
> +        return cmd_str[cmd];
Instead of hardcoding the number of elements, could you use some 
calculation involving sizeof() to get that automatically?  In any case, 
it should be "cmd < N", rather than "cmd <= N-1" (where N is the number 
of elements in the array).
> +        switch(op) {
> +        case HYPERCALL_mmu_update:
> +            {
I'm not a fan of indenting a brace within a case statement -- I think 
this is emacs' default C mode, but I prefer it the other way.   (Not 
sure which config option sets this, though.)

Other than that, looks good.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scb31-0006gc-CN; Thu, 07 Jun 2012 11:38:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scb2z-0006gU-Kz
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:38:37 +0000
Received: from [85.158.143.35:28291] by server-2.bemta-4.messagelabs.com id
	F7/DB-17938-CB290DF4; Thu, 07 Jun 2012 11:38:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339069111!11278030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30710 invoked from network); 7 Jun 2012 11:38:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:38:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:38:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scb2t-0007xw-9x; Thu, 07 Jun 2012 11:38:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scb2t-000839-8y;
	Thu, 07 Jun 2012 12:38:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.37559.262031.887156@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 12:38:31 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-5-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
	libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> This patch converts libxl_device_disk_add to an ao operation that

In the subject line `asyn' should be `async'.


> @@ -1859,11 +1883,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>      ret = 0;
> 
>      libxl_device_disk_remove(ctx, domid, disks + i, 0);
> -    libxl_device_disk_add(ctx, domid, disk);
> +    /* fixme-ao */
> +    libxl_device_disk_add(ctx, domid, disk, 0);

Is there going to be a later patch in a future version of the series
that fixes these ?


> +/* Macro to define callbacks of libxl__add_*, checks if device is last
> + * and calls the function passed as a parameter to this macro with the
> + * following syntax; func(libxl__egc *, parent_type *, int rc) */
> +#define DEFINE_DEVICES_CALLBACK(callback_name, parent_type, array_name, \
> +                                array_size_name, func_to_call)          \
> +    static void callback_name(libxl__egc *egc, libxl__ao_device *aodev) \
> +    {                                                                   \
> +        STATE_AO_GC(aodev->ao);                                         \
> +        parent_type *p = CONTAINER_OF(aodev->base, *p, array_name);     \
> +        int rc;                                                         \
> +                                                                        \
> +        rc = libxl__ao_device_check_last(gc, aodev, p->array_name,      \
> +                                         p->array_size_name);           \
> +        if (rc > 0) return;                                             \
> +        func_to_call(egc, p, rc);                                       \
> +    }

This is acceptable IMO and better than the repetition.  However the
use of a macro for this, so far from the invocation sites, is indeed
less than perfect.

Looking at the content of this macro, the only thing it needs from the
parent is array_name and array_size_name.  If you invented

    typedef struct libxl__ao_devices libxl__ao_devices;
    struct libxl__ao_devices {
        libxl__ao_device *array;
        int size;
        void (*callback)(libxl__egc*, libxl__ao_devices*, int rc);
    };

Then aodev->base could be of type libxl__ao_devices* and the macro
above could be a function.  And indeed it would have type
suitable for simply filling into aodev->callback.  Would that work ?

Doing this would also perhaps mean DEFINE_DEVICES_ADD's generated
libxl__add_FOOs functions could become one single function.  AFAICT
the only macroish things it does are: (1) accessing
d_config->num_FOOs, which could be passed in as a parameter;
(2) passing d_config->FOOs[i] to libxl__device_FOO_add, which could be
dealt with by making libxl__device_FOO_add take a void* for the config
instead, and passing the start of the d_config->FOOs array, plus the
element size, and the add function, as arguments.

Sorry to mess you about.


Whether you retain this as a macro or make it a function,

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 2dc1cee..1dc8247 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -585,6 +585,13 @@ DEFINE_DEVICES_CALLBACK(domcreate_disk_connected,
>                          libxl__domain_create_state,
>                          devices, num_devices, domcreate_launch_dm)
> 
> +static void domcreate_attach_pci(libxl__egc *egc,
> +                                 libxl__domain_create_state *dcs, int rc);
> +
> +DEFINE_DEVICES_CALLBACK(domcreate_nic_connected,
> +                        libxl__domain_create_state,
> +                        devices, num_devices, domcreate_attach_pci)
> +
>  static void domcreate_console_available(libxl__egc *egc,
>                                          libxl__domain_create_state *dcs);
> 

These seem not to be in linear execution order ?  These kind of
arrangements with a chain of callbacks should really have both the
declarations and the definitions in linear order.  Sadly that means
writing out the declarations of domcreate_nic_connected etc. here in
the declarations section but I think that's a price worth paying.
(This is something you'd have to do anyway if you replace the macro
with a function as I suggest.)


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scb31-0006gc-CN; Thu, 07 Jun 2012 11:38:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scb2z-0006gU-Kz
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:38:37 +0000
Received: from [85.158.143.35:28291] by server-2.bemta-4.messagelabs.com id
	F7/DB-17938-CB290DF4; Thu, 07 Jun 2012 11:38:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339069111!11278030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30710 invoked from network); 7 Jun 2012 11:38:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:38:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:38:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scb2t-0007xw-9x; Thu, 07 Jun 2012 11:38:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scb2t-000839-8y;
	Thu, 07 Jun 2012 12:38:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.37559.262031.887156@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 12:38:31 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-5-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
	libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> This patch converts libxl_device_disk_add to an ao operation that

In the subject line `asyn' should be `async'.


> @@ -1859,11 +1883,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>      ret = 0;
> 
>      libxl_device_disk_remove(ctx, domid, disks + i, 0);
> -    libxl_device_disk_add(ctx, domid, disk);
> +    /* fixme-ao */
> +    libxl_device_disk_add(ctx, domid, disk, 0);

Is there going to be a later patch in a future version of the series
that fixes these ?


> +/* Macro to define callbacks of libxl__add_*, checks if device is last
> + * and calls the function passed as a parameter to this macro with the
> + * following syntax; func(libxl__egc *, parent_type *, int rc) */
> +#define DEFINE_DEVICES_CALLBACK(callback_name, parent_type, array_name, \
> +                                array_size_name, func_to_call)          \
> +    static void callback_name(libxl__egc *egc, libxl__ao_device *aodev) \
> +    {                                                                   \
> +        STATE_AO_GC(aodev->ao);                                         \
> +        parent_type *p = CONTAINER_OF(aodev->base, *p, array_name);     \
> +        int rc;                                                         \
> +                                                                        \
> +        rc = libxl__ao_device_check_last(gc, aodev, p->array_name,      \
> +                                         p->array_size_name);           \
> +        if (rc > 0) return;                                             \
> +        func_to_call(egc, p, rc);                                       \
> +    }

This is acceptable IMO and better than the repetition.  However the
use of a macro for this, so far from the invocation sites, is indeed
less than perfect.

Looking at the content of this macro, the only thing it needs from the
parent is array_name and array_size_name.  If you invented

    typedef struct libxl__ao_devices libxl__ao_devices;
    struct libxl__ao_devices {
        libxl__ao_device *array;
        int size;
        void (*callback)(libxl__egc*, libxl__ao_devices*, int rc);
    };

Then aodev->base could be of type libxl__ao_devices* and the macro
above could be a function.  And indeed it would have type
suitable for simply filling into aodev->callback.  Would that work ?

Doing this would also perhaps mean DEFINE_DEVICES_ADD's generated
libxl__add_FOOs functions could become one single function.  AFAICT
the only macroish things it does are: (1) accessing
d_config->num_FOOs, which could be passed in as a parameter;
(2) passing d_config->FOOs[i] to libxl__device_FOO_add, which could be
dealt with by making libxl__device_FOO_add take a void* for the config
instead, and passing the start of the d_config->FOOs array, plus the
element size, and the add function, as arguments.

Sorry to mess you about.


Whether you retain this as a macro or make it a function,

> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 2dc1cee..1dc8247 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -585,6 +585,13 @@ DEFINE_DEVICES_CALLBACK(domcreate_disk_connected,
>                          libxl__domain_create_state,
>                          devices, num_devices, domcreate_launch_dm)
> 
> +static void domcreate_attach_pci(libxl__egc *egc,
> +                                 libxl__domain_create_state *dcs, int rc);
> +
> +DEFINE_DEVICES_CALLBACK(domcreate_nic_connected,
> +                        libxl__domain_create_state,
> +                        devices, num_devices, domcreate_attach_pci)
> +
>  static void domcreate_console_available(libxl__egc *egc,
>                                          libxl__domain_create_state *dcs);
> 

These seem not to be in linear execution order ?  These kind of
arrangements with a chain of callbacks should really have both the
declarations and the definitions in linear order.  Sadly that means
writing out the declarations of domcreate_nic_connected etc. here in
the declarations section but I think that's a price worth paying.
(This is something you'd have to do anyway if you replace the macro
with a function as I suggest.)


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scb3T-0006li-Ux; Thu, 07 Jun 2012 11:39:07 +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 1Scb3S-0006lF-K6
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:39:07 +0000
Received: from [85.158.138.51:12717] by server-4.bemta-3.messagelabs.com id
	DE/12-13598-9D290DF4; Thu, 07 Jun 2012 11:39:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339069144!31209603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26786 invoked from network); 7 Jun 2012 11:39:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:39:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:39:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:39:04 +0100
Date: Thu, 7 Jun 2012 12:38:45 +0100
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: <1338565207-2888-36-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071214020.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-36-git-send-email-ian.campbell@citrix.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] [PATCH 36/38] libxc: add ARM support to xc_dom (PV
 domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Includes ARM zImage support.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/libxc/Makefile                 |    1 +
>  tools/libxc/xc_dom.h                 |    5 +-
>  tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
>  tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_dom_core.c            |   12 ++-
>  tools/libxc/xg_private.h             |    4 +
>  6 files changed, 315 insertions(+), 9 deletions(-)
>  create mode 100644 tools/libxc/xc_dom_armzimageloader.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index ca38cbd..a01d457 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
>  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_ARM)     += xc_dom_armzimageloader.c
>  GUEST_SRCS-y                 += xc_dom_binloader.c
>  GUEST_SRCS-y                 += xc_dom_compat_linux.c
> 
> diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
> index 2aef64a..4db8fad 100644
> --- a/tools/libxc/xc_dom.h
> +++ b/tools/libxc/xc_dom.h
> @@ -93,6 +93,7 @@ struct xc_dom_image {
>      void *p2m_guest;
> 
>      /* physical memory */
> +    xen_pfn_t rambase_pfn;
>      xen_pfn_t total_pages;
>      struct xc_dom_phys *phys_pages;
>      int realmodearea_log;
> @@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
>  {
>      if (dom->shadow_enabled)
>          return pfn;
> -    return dom->p2m_host[pfn];
> +    return dom->p2m_host[pfn - dom->rambase_pfn];
>  }
> 
>  static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
> @@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
>  {
>      if (xc_dom_feature_translated(dom))
>          return pfn;
> -    return dom->p2m_host[pfn];
> +    return dom->p2m_host[pfn - dom->rambase_pfn];
>  }

I take that rambase_pfn is the offset in the guest physical address
space where the ram is located. It would be nice to write it down.


>  /* --- arch bits --------------------------------------------------- */
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index 122d0e8..9099cad 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -18,14 +18,138 @@
>   * Copyright (c) 2011, Citrix Systems
>   */
>  #include <inttypes.h>
> +
>  #include <xen/xen.h>
> +#include <xen/io/protocols.h>
> +
>  #include "xg_private.h"
>  #include "xc_dom.h"
> 
> +/* ------------------------------------------------------------------------ */
> +/*
> + * arm guests are hybrid and start off with paging disabled, therefore no
> + * pagetables and nothing to do here.
> + */
> +static int count_pgtables_arm(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    return 0;
> +}
> +
> +static int setup_pgtables_arm(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int alloc_magic_pages(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    /* XXX
> +     *   dom->p2m_guest
> +     *   dom->start_info_pfn
> +     *   dom->xenstore_pfn
> +     *   dom->console_pfn
> +     */
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int start_info_arm(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    /* XXX */
> +    return 0;
> +}
> +
> +static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    /* XXX */
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
> +{
> +    vcpu_guest_context_t *ctxt = ptr;
> +
> +    DOMPRINTF_CALLED(dom->xch);
> +
> +    /* clear everything */
> +    memset(ctxt, 0, sizeof(*ctxt));
> +
> +    ctxt->user_regs.pc = dom->parms.virt_entry;
> +    ctxt->user_regs.r0 = 0; /* SBZ */
> +    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
> +
> +    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
> +    ctxt->user_regs.r3 = 0xdeadbeef;
> +    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
> +    ctxt->ttbr0 = 0;
> +    ctxt->ttbr1 = 0;
> +    ctxt->ttbcr = 0; /* Defined Reset Value */
> +
> +    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
> +
> +    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
> +           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
> +
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static struct xc_dom_arch xc_dom_32 = {
> +    .guest_type = "xen-3.0-armv7l",
> +    .native_protocol = XEN_IO_PROTO_ABI_ARM,
> +    .page_shift = PAGE_SHIFT_ARM,
> +    .sizeof_pfn = 8,
> +    .alloc_magic_pages = alloc_magic_pages,
> +    .count_pgtables = count_pgtables_arm,
> +    .setup_pgtables = setup_pgtables_arm,
> +    .start_info = start_info_arm,
> +    .shared_info = shared_info_arm,
> +    .vcpu = vcpu_arm,
> +};
> +
> +static void __init register_arch_hooks(void)
> +{
> +    xc_dom_register_arch_hooks(&xc_dom_32);
> +}
> +
>  int arch_setup_meminit(struct xc_dom_image *dom)
>  {
> -    errno = ENOSYS;
> -    return -1;
> +    int rc;
> +    xen_pfn_t pfn, allocsz, i;
> +
> +    dom->shadow_enabled = 1;
> +
> +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> +
> +    /* setup initial p2m */
> +    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> +        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;

uhm.. so maybe rambase_pfn is the offset in the machine address space where
the guest ram has been allocated?


> +    /* allocate guest memory */
> +    for ( i = rc = allocsz = 0;
> +          (i < dom->total_pages) && !rc;
> +          i += allocsz )
> +    {
> +        allocsz = dom->total_pages - i;
> +        if ( allocsz > 1024*1024 )
> +            allocsz = 1024*1024;
> +
> +        rc = xc_domain_populate_physmap_exact(
> +            dom->xch, dom->guest_domid, allocsz,
> +            0, 0, &dom->p2m_host[i]);
> +    }
> +
> +    return 0;
>  }
> 
>  int arch_setup_bootearly(struct xc_dom_image *dom)
> @@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
> 
>  int arch_setup_bootlate(struct xc_dom_image *dom)
>  {
> -    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    /* XXX
> +     *   map shared info
> +     *   map grant tables
> +     *   setup shared info
> +     */
>      return 0;
>  }
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
> new file mode 100644
> index 0000000..220176d
> --- /dev/null
> +++ b/tools/libxc/xc_dom_armzimageloader.c
> @@ -0,0 +1,167 @@
> +/*
> + * Xen domain builder -- ARM zImage bits
> + *
> + * Parse and load ARM zImage kernel images.
> + *
> + * Copyright (C) 2012, Citrix Systems.
> + *
> + * 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
> + *
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +
> +#include <arpa/inet.h> /* XXX ntohl is not the right function... */

Yes, you are right, we should write a be32_to_cpu (the ones in Xen, QEMU
and Linux are GPLv2 rather than LGLPv2).


> +#define ZIMAGE_MAGIC_OFFSET 0x24
> +#define ZIMAGE_START_OFFSET 0x28
> +#define ZIMAGE_END_OFFSET   0x2c
> +
> +#define ZIMAGE_MAGIC 0x016f2818
> +
> +struct minimal_dtb_header {
> +    uint32_t magic;
> +    uint32_t total_size;
> +    /* There are other fields but we don't use them yet. */
> +};
> +
> +#define DTB_MAGIC 0xd00dfeed
> +
> +static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
> +{
> +    uint32_t *zimage;
> +    uint32_t end;
> +
> +    if ( dom->kernel_blob == NULL )
> +    {
> +        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> +                     "%s: no kernel image loaded", __FUNCTION__);
> +        return -EINVAL;
> +    }
> +
> +    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
> +    {
> +        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
> +        return -EINVAL;
> +    }
> +
> +    zimage = (uint32_t *)dom->kernel_blob;
> +    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
> +    {
> +        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
> +        return -EINVAL;
> +    }
> +
> +    end = zimage[ZIMAGE_END_OFFSET/4];
> +
> +    /*
> +     * Check for an appended DTB.
> +     */
> +    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
> +        struct minimal_dtb_header *dtb_hdr;
> +        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
> +        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
> +            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
> +            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
> +        }
> +    }
> +
> +    dom->kernel_size = end;
> +
> +    return 0;
> +}
> +
> +static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
> +{
> +    uint32_t *zimage;
> +    uint32_t start, entry_addr;
> +    uint64_t v_start, v_end;
> +    uint64_t rambase = 0x80000000; /* XXX */
> +
> +    DOMPRINTF_CALLED(dom->xch);
> +
> +    zimage = (uint32_t *)dom->kernel_blob;
> +
> +    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
> +
> +    v_start = rambase + 0x8000; /* XXX */
> +    v_end = v_start + dom->kernel_size;
> +
> +    start = zimage[ZIMAGE_START_OFFSET/4];
> +
> +    if (start == 0)
> +        entry_addr = v_start;
> +    else
> +        entry_addr = start;
> +
> +    /* find kernel segment */
> +    dom->kernel_seg.vstart = v_start;
> +    dom->kernel_seg.vend   = v_end;
> +
> +    dom->parms.virt_entry = entry_addr;
> +
> +    dom->guest_type = "xen-3.0-armv7l";
> +    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
> +              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
> +    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
> +              __FUNCTION__, dom->guest_type,
> +              dom->kernel_seg.vstart, dom->kernel_seg.vend);
> +    return 0;
> +}
> +
> +static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
> +{
> +    void *dst;
> +
> +    DOMPRINTF_CALLED(dom->xch);
> +
> +    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
> +
> +    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
> +              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
> +    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
> +              __func__, dom->kernel_size, dom->kernel_blob, dst);
> +
> +    memcpy(dst, dom->kernel_blob, dom->kernel_size);
> +
> +    return 0;
> +}
> +
> +static struct xc_dom_loader zimage_loader = {
> +    .name = "Linux zImage (ARM)",
> +    .probe = xc_dom_probe_zimage_kernel,
> +    .parser = xc_dom_parse_zimage_kernel,
> +    .loader = xc_dom_load_zimage_kernel,
> +};
> +
> +static void __init register_loader(void)
> +{
> +    xc_dom_register_loader(&zimage_loader);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index fea9de5..b0d48d5 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
>                          xen_pfn_t count)
>  {
>      struct xc_dom_phys *phys;
> +    xen_pfn_t offset;
>      unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
>      char *mode = "unset";
> 
> -    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
> +    offset = pfn-dom->rambase_pfn;

spaces around the '-' please


> +    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
>           count > dom->total_pages ||
> -         pfn > dom->total_pages - count )
> +         offset > dom->total_pages - count )
>      {
> -        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
> -                  __FUNCTION__, pfn, dom->total_pages);
> +        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
> +                  __FUNCTION__, pfn, offset, dom->total_pages);
>          return NULL;
>      }
> 
> @@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
>      dom->parms.virt_hv_start_low = UNSET_ADDR;
>      dom->parms.elf_paddr_offset = UNSET_ADDR;
> 
> +    dom->rambase_pfn = 0;
> +
>      dom->alloc_malloc += sizeof(*dom);
>      return dom;

There is no need to explicitly set rambase_pfn to 0, because the whole
dom struct is memset to 0 few lines above.



> diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
> index a29fa26..a271942 100644
> --- a/tools/libxc/xg_private.h
> +++ b/tools/libxc/xg_private.h
> @@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
>  #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
>  #endif
> 
> +#define PAGE_SHIFT_ARM          12
> +#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
> +#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
> +
>  #define PAGE_SHIFT_X86          12
>  #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
>  #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
> --
> 1.7.9.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 Thu Jun 07 11:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11: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 1Scb3T-0006li-Ux; Thu, 07 Jun 2012 11:39:07 +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 1Scb3S-0006lF-K6
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:39:07 +0000
Received: from [85.158.138.51:12717] by server-4.bemta-3.messagelabs.com id
	DE/12-13598-9D290DF4; Thu, 07 Jun 2012 11:39:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339069144!31209603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26786 invoked from network); 7 Jun 2012 11:39:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:39:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:39:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:39:04 +0100
Date: Thu, 7 Jun 2012 12:38:45 +0100
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: <1338565207-2888-36-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071214020.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-36-git-send-email-ian.campbell@citrix.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] [PATCH 36/38] libxc: add ARM support to xc_dom (PV
 domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Includes ARM zImage support.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/libxc/Makefile                 |    1 +
>  tools/libxc/xc_dom.h                 |    5 +-
>  tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
>  tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_dom_core.c            |   12 ++-
>  tools/libxc/xg_private.h             |    4 +
>  6 files changed, 315 insertions(+), 9 deletions(-)
>  create mode 100644 tools/libxc/xc_dom_armzimageloader.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index ca38cbd..a01d457 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
>  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_ARM)     += xc_dom_armzimageloader.c
>  GUEST_SRCS-y                 += xc_dom_binloader.c
>  GUEST_SRCS-y                 += xc_dom_compat_linux.c
> 
> diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
> index 2aef64a..4db8fad 100644
> --- a/tools/libxc/xc_dom.h
> +++ b/tools/libxc/xc_dom.h
> @@ -93,6 +93,7 @@ struct xc_dom_image {
>      void *p2m_guest;
> 
>      /* physical memory */
> +    xen_pfn_t rambase_pfn;
>      xen_pfn_t total_pages;
>      struct xc_dom_phys *phys_pages;
>      int realmodearea_log;
> @@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
>  {
>      if (dom->shadow_enabled)
>          return pfn;
> -    return dom->p2m_host[pfn];
> +    return dom->p2m_host[pfn - dom->rambase_pfn];
>  }
> 
>  static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
> @@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
>  {
>      if (xc_dom_feature_translated(dom))
>          return pfn;
> -    return dom->p2m_host[pfn];
> +    return dom->p2m_host[pfn - dom->rambase_pfn];
>  }

I take that rambase_pfn is the offset in the guest physical address
space where the ram is located. It would be nice to write it down.


>  /* --- arch bits --------------------------------------------------- */
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index 122d0e8..9099cad 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -18,14 +18,138 @@
>   * Copyright (c) 2011, Citrix Systems
>   */
>  #include <inttypes.h>
> +
>  #include <xen/xen.h>
> +#include <xen/io/protocols.h>
> +
>  #include "xg_private.h"
>  #include "xc_dom.h"
> 
> +/* ------------------------------------------------------------------------ */
> +/*
> + * arm guests are hybrid and start off with paging disabled, therefore no
> + * pagetables and nothing to do here.
> + */
> +static int count_pgtables_arm(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    return 0;
> +}
> +
> +static int setup_pgtables_arm(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int alloc_magic_pages(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    /* XXX
> +     *   dom->p2m_guest
> +     *   dom->start_info_pfn
> +     *   dom->xenstore_pfn
> +     *   dom->console_pfn
> +     */
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int start_info_arm(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    /* XXX */
> +    return 0;
> +}
> +
> +static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
> +{
> +    DOMPRINTF_CALLED(dom->xch);
> +    /* XXX */
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
> +{
> +    vcpu_guest_context_t *ctxt = ptr;
> +
> +    DOMPRINTF_CALLED(dom->xch);
> +
> +    /* clear everything */
> +    memset(ctxt, 0, sizeof(*ctxt));
> +
> +    ctxt->user_regs.pc = dom->parms.virt_entry;
> +    ctxt->user_regs.r0 = 0; /* SBZ */
> +    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
> +
> +    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
> +    ctxt->user_regs.r3 = 0xdeadbeef;
> +    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
> +    ctxt->ttbr0 = 0;
> +    ctxt->ttbr1 = 0;
> +    ctxt->ttbcr = 0; /* Defined Reset Value */
> +
> +    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
> +
> +    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
> +           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
> +
> +    return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static struct xc_dom_arch xc_dom_32 = {
> +    .guest_type = "xen-3.0-armv7l",
> +    .native_protocol = XEN_IO_PROTO_ABI_ARM,
> +    .page_shift = PAGE_SHIFT_ARM,
> +    .sizeof_pfn = 8,
> +    .alloc_magic_pages = alloc_magic_pages,
> +    .count_pgtables = count_pgtables_arm,
> +    .setup_pgtables = setup_pgtables_arm,
> +    .start_info = start_info_arm,
> +    .shared_info = shared_info_arm,
> +    .vcpu = vcpu_arm,
> +};
> +
> +static void __init register_arch_hooks(void)
> +{
> +    xc_dom_register_arch_hooks(&xc_dom_32);
> +}
> +
>  int arch_setup_meminit(struct xc_dom_image *dom)
>  {
> -    errno = ENOSYS;
> -    return -1;
> +    int rc;
> +    xen_pfn_t pfn, allocsz, i;
> +
> +    dom->shadow_enabled = 1;
> +
> +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> +
> +    /* setup initial p2m */
> +    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> +        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;

uhm.. so maybe rambase_pfn is the offset in the machine address space where
the guest ram has been allocated?


> +    /* allocate guest memory */
> +    for ( i = rc = allocsz = 0;
> +          (i < dom->total_pages) && !rc;
> +          i += allocsz )
> +    {
> +        allocsz = dom->total_pages - i;
> +        if ( allocsz > 1024*1024 )
> +            allocsz = 1024*1024;
> +
> +        rc = xc_domain_populate_physmap_exact(
> +            dom->xch, dom->guest_domid, allocsz,
> +            0, 0, &dom->p2m_host[i]);
> +    }
> +
> +    return 0;
>  }
> 
>  int arch_setup_bootearly(struct xc_dom_image *dom)
> @@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
> 
>  int arch_setup_bootlate(struct xc_dom_image *dom)
>  {
> -    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    /* XXX
> +     *   map shared info
> +     *   map grant tables
> +     *   setup shared info
> +     */
>      return 0;
>  }
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
> new file mode 100644
> index 0000000..220176d
> --- /dev/null
> +++ b/tools/libxc/xc_dom_armzimageloader.c
> @@ -0,0 +1,167 @@
> +/*
> + * Xen domain builder -- ARM zImage bits
> + *
> + * Parse and load ARM zImage kernel images.
> + *
> + * Copyright (C) 2012, Citrix Systems.
> + *
> + * 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
> + *
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +
> +#include <arpa/inet.h> /* XXX ntohl is not the right function... */

Yes, you are right, we should write a be32_to_cpu (the ones in Xen, QEMU
and Linux are GPLv2 rather than LGLPv2).


> +#define ZIMAGE_MAGIC_OFFSET 0x24
> +#define ZIMAGE_START_OFFSET 0x28
> +#define ZIMAGE_END_OFFSET   0x2c
> +
> +#define ZIMAGE_MAGIC 0x016f2818
> +
> +struct minimal_dtb_header {
> +    uint32_t magic;
> +    uint32_t total_size;
> +    /* There are other fields but we don't use them yet. */
> +};
> +
> +#define DTB_MAGIC 0xd00dfeed
> +
> +static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
> +{
> +    uint32_t *zimage;
> +    uint32_t end;
> +
> +    if ( dom->kernel_blob == NULL )
> +    {
> +        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> +                     "%s: no kernel image loaded", __FUNCTION__);
> +        return -EINVAL;
> +    }
> +
> +    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
> +    {
> +        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
> +        return -EINVAL;
> +    }
> +
> +    zimage = (uint32_t *)dom->kernel_blob;
> +    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
> +    {
> +        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
> +        return -EINVAL;
> +    }
> +
> +    end = zimage[ZIMAGE_END_OFFSET/4];
> +
> +    /*
> +     * Check for an appended DTB.
> +     */
> +    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
> +        struct minimal_dtb_header *dtb_hdr;
> +        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
> +        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
> +            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
> +            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
> +        }
> +    }
> +
> +    dom->kernel_size = end;
> +
> +    return 0;
> +}
> +
> +static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
> +{
> +    uint32_t *zimage;
> +    uint32_t start, entry_addr;
> +    uint64_t v_start, v_end;
> +    uint64_t rambase = 0x80000000; /* XXX */
> +
> +    DOMPRINTF_CALLED(dom->xch);
> +
> +    zimage = (uint32_t *)dom->kernel_blob;
> +
> +    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
> +
> +    v_start = rambase + 0x8000; /* XXX */
> +    v_end = v_start + dom->kernel_size;
> +
> +    start = zimage[ZIMAGE_START_OFFSET/4];
> +
> +    if (start == 0)
> +        entry_addr = v_start;
> +    else
> +        entry_addr = start;
> +
> +    /* find kernel segment */
> +    dom->kernel_seg.vstart = v_start;
> +    dom->kernel_seg.vend   = v_end;
> +
> +    dom->parms.virt_entry = entry_addr;
> +
> +    dom->guest_type = "xen-3.0-armv7l";
> +    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
> +              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
> +    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
> +              __FUNCTION__, dom->guest_type,
> +              dom->kernel_seg.vstart, dom->kernel_seg.vend);
> +    return 0;
> +}
> +
> +static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
> +{
> +    void *dst;
> +
> +    DOMPRINTF_CALLED(dom->xch);
> +
> +    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
> +
> +    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
> +              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
> +    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
> +              __func__, dom->kernel_size, dom->kernel_blob, dst);
> +
> +    memcpy(dst, dom->kernel_blob, dom->kernel_size);
> +
> +    return 0;
> +}
> +
> +static struct xc_dom_loader zimage_loader = {
> +    .name = "Linux zImage (ARM)",
> +    .probe = xc_dom_probe_zimage_kernel,
> +    .parser = xc_dom_parse_zimage_kernel,
> +    .loader = xc_dom_load_zimage_kernel,
> +};
> +
> +static void __init register_loader(void)
> +{
> +    xc_dom_register_loader(&zimage_loader);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index fea9de5..b0d48d5 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
>                          xen_pfn_t count)
>  {
>      struct xc_dom_phys *phys;
> +    xen_pfn_t offset;
>      unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
>      char *mode = "unset";
> 
> -    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
> +    offset = pfn-dom->rambase_pfn;

spaces around the '-' please


> +    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
>           count > dom->total_pages ||
> -         pfn > dom->total_pages - count )
> +         offset > dom->total_pages - count )
>      {
> -        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
> -                  __FUNCTION__, pfn, dom->total_pages);
> +        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
> +                  __FUNCTION__, pfn, offset, dom->total_pages);
>          return NULL;
>      }
> 
> @@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
>      dom->parms.virt_hv_start_low = UNSET_ADDR;
>      dom->parms.elf_paddr_offset = UNSET_ADDR;
> 
> +    dom->rambase_pfn = 0;
> +
>      dom->alloc_malloc += sizeof(*dom);
>      return dom;

There is no need to explicitly set rambase_pfn to 0, because the whole
dom struct is memset to 0 few lines above.



> diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
> index a29fa26..a271942 100644
> --- a/tools/libxc/xg_private.h
> +++ b/tools/libxc/xg_private.h
> @@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
>  #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
>  #endif
> 
> +#define PAGE_SHIFT_ARM          12
> +#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
> +#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
> +
>  #define PAGE_SHIFT_X86          12
>  #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
>  #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
> --
> 1.7.9.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 Thu Jun 07 11:40:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scb4x-0006zH-ER; Thu, 07 Jun 2012 11:40:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Scb4w-0006z1-6S
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:40:38 +0000
Received: from [193.109.254.147:15472] by server-12.bemta-14.messagelabs.com
	id 3D/A4-12998-53390DF4; Thu, 07 Jun 2012 11:40:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339069231!1736578!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32158 invoked from network); 7 Jun 2012 11:40:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 11:40:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scb4p-000Iuu-9y; Thu, 07 Jun 2012 11:40:31 +0000
Date: Thu, 7 Jun 2012 12:40:31 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120607114031.GP70339@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607094225.GB15139@spongy.cam.xci-test.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 

Thanks for this.

Overall, it looks like Xen is doing a few things here:
 - nameservice for registering services and finding endpoints;
 - ring manipulation arithmetic;
 - copying data; and
 - notifying endpoints. 

The shared-ring logic was able to do all of these, with a few drawbacks:
 - The xenstore handshake stuff is really grotty;
 - grant maps can cause zombie domains; and
 - it doesn't do many-to-one multicast.

Is that a fair summary?

Using copy semantics intead of shared rings fixes the zombie domain
problem, and I think we should definitely take that.

We talked last week about ways we could improve xenstore to provde the
nameservice aspects of v4v; if that can be done I think it should be.

The rest of is within spitting distance of a multicall of grant copies
and event-channel pokes - except for the many-to-one multicast.
That relies on Xen policing the ring headers to make sure the length
fields are correct.

What's the use case for that?  Do you use it just to negotiate a
dedicated ring for each sender or is there a need for multiple data
streams to be multiplexed together?

I have a few questions on the design, inline below. 

At 10:42 +0100 on 07 Jun (1339065745), Jean Guyader wrote:
> v4v has a very simple architecture. The receiving domain registers a
> ring with xen.  The sending domain requests that xen inserts data into
> the receiving domain's ring.  Notification that there is new data to
> read is delivered by a VIRQ

Not an evtchn?

> , and a domain can request an interrupt be generated when sufficient
> space is available in another domain's ring. 

How is that arranged?  It doesn't look like the receiver notifies Xen
when it consumes a ring entry.

> The code that inserts
> the data into the ring is in xen, and xen writes a header describing
> the data and where it came from infront of the data. As both the ring
> manipulation and the header are written by the hypervisor, the
> receiving domain can trust their content and the format of the ring.

Does that save a copy on the receiving side?

> ** Addressing
> v4v_addr_t identifies an endpoint address.
>  typedef struct v4v_addr
>  {
>      uint32_t port;
>      domid_t domain;
>  } v4v_addr_t;
> struct v4v_ring_id uniquely identifies a ring on the platform.
> 
>  struct v4v_ring_id
>  {
>     struct v4v_addr addr;
>     domid_t partner;
>  };
> 
> When a send operation is performed, xen will attempt to find a ring 
> registered by destination domain, with the required port, and with
> a partner of the sending domain. Failing that it will then search
> for a ring with the correct port and destination domain, but with 
> partner set to V4V_DOMID_ANY.
> 
> ** Setup
> A domain first generates a ring, and a structure describing the pages
> in the ring.  Rings must be page aligned, and contiguous in virtual
> memory, but need not be contiguous in physical(pfn) or machine(mfn)
> memory. A ring is uniquely identified on the platform by its struct
> v4v_ring_id.
>
> A ring is contained in a v4v_ring_t
>  typedef struct v4v_ring
>  {
>     uint64_t magic;
>     /*
>      * Identifies ring_id - xen only looks at this during register/unregister
>      * and will fill in id.addr.domain
>      */
>     struct v4v_ring_id id;
>     /* length of ring[], must be a multiple of 16 */
>     uint32_t len;
>     /* rx_ptr - modified by domain */
>     uint32_t rx_ptr;
>     /* tx_ptr - modified by xen */
>     volatile uint32_t tx_ptr;
>     uint64_t reserved[4];
>     volatile uint8_t ring[0];
>  } v4v_ring_t;

(Digressing into code review for a minute, I don't think we should use
'volatile' in the public headers, and possibly it will be more efficient
to use barriers anyway if we're processing the received data in place).

> To register the ring, xen also needs a list of pfn that the ring occupies.
> This is provided in a v4v_pfn_list_t
>  typedef struct v4v_pfn_list_t
>  {
>     uint64_t magic;
>     uint32_t npage;
>     uint32_t pad;
>     uint64_t reserved[3];
>     v4v_pfn_t pages[0];
>  } v4v_pfn_list_t;
> 
> Registering the ring is done with a hypercall
> 
> int hypercall(NR_V4V,V4VOP_register_ring,v4v_ring_t *ring,v4v_pfn_list_t *pfn_list);
> 
> On registering, xen will check that the tx_ptr and rx_ptr values are valid (aligned
> and within the size of the ring) and modify them if they are not

Modify them?  Not return an error?

>, it will also update
> id.addr.domain with the calling domain's domid and take an internal copy of all the
> relevant information. After registration the only field that xen will read is
> ring->rx_ptr, xen will write to ring->ring[] and ring->tx_ptr. 
> Thus pfn_list can be freed after the registration call. Critically, registration is
> idempotent, and all a domain need do after hibernation or migration is re-register all
> its rings. (NB the id.addr.domain field may change).
> 
> ** Sending
> 
> To send data a guest merely calls the send or sendv hypercall
> int hypercall(NR_V4V,V4VOP_send,v4v_addr_t *src,v4v_addr_t *dst,void *buf, uint32_t len,
>               uint32_t protocol);

What does the source address do here?  Do I need to register a ring in
order to send to another ring?

Why the separate 'protocol' argument when 'port' is bound into the address
struct?  A single ring receives messages for a given port but all protocols? 

> the caller provides a source address, a destination address, a buffer, a number of bytes to copy
> and a 32 bit protocol number. Xen ignores src->domain and instead uses the domain id of the caller.
> 
> Xen will attempt to insert into a ring with id.addr equal to dst, and with
> id.partner equal to the caller's domid. Otherwise it will insert into a ring
> with id.addr equal to dst and id.partner equal to V4V_DOMID_ANY. If the insert is successfull
> then Xen will trigger the V4V VIRQ line in the receiving domain.
> 
> ** Reception
> 
> Xen pads all messages on the ring to 16 bytes (the macro V4V_ROUNDUP is provided 
> for convience), and inserts a message header infront of all messages it copies onto the ring.
> 
>  struct v4v_ring_message_header
>  {
>     uint32_t len;
>     struct v4v_addr source;
>     uint16_t pad;
>     uint32_t protocol;
>     uint8_t data[0];
>  };
> 
> len is the number of bytes in the message including the struct v4v_ring_message_header
> source specifies the source address from which the message came, source.domain is
> set by xen, and source.port is taken from the arguments to the send or sendv call.
> protocol is the protocol value given to the send call.
> 
> An  inline function is provided to make reading from the ring easier:
> 
>  ssize_t
>  v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
>               void *_buf, size_t t, int consume)

I guess that answers my question about avoiding a copy on the receiver. :(

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 Jun 07 11:40:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scb4x-0006zH-ER; Thu, 07 Jun 2012 11:40:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Scb4w-0006z1-6S
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:40:38 +0000
Received: from [193.109.254.147:15472] by server-12.bemta-14.messagelabs.com
	id 3D/A4-12998-53390DF4; Thu, 07 Jun 2012 11:40:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339069231!1736578!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32158 invoked from network); 7 Jun 2012 11:40:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 11:40:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scb4p-000Iuu-9y; Thu, 07 Jun 2012 11:40:31 +0000
Date: Thu, 7 Jun 2012 12:40:31 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120607114031.GP70339@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607094225.GB15139@spongy.cam.xci-test.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 

Thanks for this.

Overall, it looks like Xen is doing a few things here:
 - nameservice for registering services and finding endpoints;
 - ring manipulation arithmetic;
 - copying data; and
 - notifying endpoints. 

The shared-ring logic was able to do all of these, with a few drawbacks:
 - The xenstore handshake stuff is really grotty;
 - grant maps can cause zombie domains; and
 - it doesn't do many-to-one multicast.

Is that a fair summary?

Using copy semantics intead of shared rings fixes the zombie domain
problem, and I think we should definitely take that.

We talked last week about ways we could improve xenstore to provde the
nameservice aspects of v4v; if that can be done I think it should be.

The rest of is within spitting distance of a multicall of grant copies
and event-channel pokes - except for the many-to-one multicast.
That relies on Xen policing the ring headers to make sure the length
fields are correct.

What's the use case for that?  Do you use it just to negotiate a
dedicated ring for each sender or is there a need for multiple data
streams to be multiplexed together?

I have a few questions on the design, inline below. 

At 10:42 +0100 on 07 Jun (1339065745), Jean Guyader wrote:
> v4v has a very simple architecture. The receiving domain registers a
> ring with xen.  The sending domain requests that xen inserts data into
> the receiving domain's ring.  Notification that there is new data to
> read is delivered by a VIRQ

Not an evtchn?

> , and a domain can request an interrupt be generated when sufficient
> space is available in another domain's ring. 

How is that arranged?  It doesn't look like the receiver notifies Xen
when it consumes a ring entry.

> The code that inserts
> the data into the ring is in xen, and xen writes a header describing
> the data and where it came from infront of the data. As both the ring
> manipulation and the header are written by the hypervisor, the
> receiving domain can trust their content and the format of the ring.

Does that save a copy on the receiving side?

> ** Addressing
> v4v_addr_t identifies an endpoint address.
>  typedef struct v4v_addr
>  {
>      uint32_t port;
>      domid_t domain;
>  } v4v_addr_t;
> struct v4v_ring_id uniquely identifies a ring on the platform.
> 
>  struct v4v_ring_id
>  {
>     struct v4v_addr addr;
>     domid_t partner;
>  };
> 
> When a send operation is performed, xen will attempt to find a ring 
> registered by destination domain, with the required port, and with
> a partner of the sending domain. Failing that it will then search
> for a ring with the correct port and destination domain, but with 
> partner set to V4V_DOMID_ANY.
> 
> ** Setup
> A domain first generates a ring, and a structure describing the pages
> in the ring.  Rings must be page aligned, and contiguous in virtual
> memory, but need not be contiguous in physical(pfn) or machine(mfn)
> memory. A ring is uniquely identified on the platform by its struct
> v4v_ring_id.
>
> A ring is contained in a v4v_ring_t
>  typedef struct v4v_ring
>  {
>     uint64_t magic;
>     /*
>      * Identifies ring_id - xen only looks at this during register/unregister
>      * and will fill in id.addr.domain
>      */
>     struct v4v_ring_id id;
>     /* length of ring[], must be a multiple of 16 */
>     uint32_t len;
>     /* rx_ptr - modified by domain */
>     uint32_t rx_ptr;
>     /* tx_ptr - modified by xen */
>     volatile uint32_t tx_ptr;
>     uint64_t reserved[4];
>     volatile uint8_t ring[0];
>  } v4v_ring_t;

(Digressing into code review for a minute, I don't think we should use
'volatile' in the public headers, and possibly it will be more efficient
to use barriers anyway if we're processing the received data in place).

> To register the ring, xen also needs a list of pfn that the ring occupies.
> This is provided in a v4v_pfn_list_t
>  typedef struct v4v_pfn_list_t
>  {
>     uint64_t magic;
>     uint32_t npage;
>     uint32_t pad;
>     uint64_t reserved[3];
>     v4v_pfn_t pages[0];
>  } v4v_pfn_list_t;
> 
> Registering the ring is done with a hypercall
> 
> int hypercall(NR_V4V,V4VOP_register_ring,v4v_ring_t *ring,v4v_pfn_list_t *pfn_list);
> 
> On registering, xen will check that the tx_ptr and rx_ptr values are valid (aligned
> and within the size of the ring) and modify them if they are not

Modify them?  Not return an error?

>, it will also update
> id.addr.domain with the calling domain's domid and take an internal copy of all the
> relevant information. After registration the only field that xen will read is
> ring->rx_ptr, xen will write to ring->ring[] and ring->tx_ptr. 
> Thus pfn_list can be freed after the registration call. Critically, registration is
> idempotent, and all a domain need do after hibernation or migration is re-register all
> its rings. (NB the id.addr.domain field may change).
> 
> ** Sending
> 
> To send data a guest merely calls the send or sendv hypercall
> int hypercall(NR_V4V,V4VOP_send,v4v_addr_t *src,v4v_addr_t *dst,void *buf, uint32_t len,
>               uint32_t protocol);

What does the source address do here?  Do I need to register a ring in
order to send to another ring?

Why the separate 'protocol' argument when 'port' is bound into the address
struct?  A single ring receives messages for a given port but all protocols? 

> the caller provides a source address, a destination address, a buffer, a number of bytes to copy
> and a 32 bit protocol number. Xen ignores src->domain and instead uses the domain id of the caller.
> 
> Xen will attempt to insert into a ring with id.addr equal to dst, and with
> id.partner equal to the caller's domid. Otherwise it will insert into a ring
> with id.addr equal to dst and id.partner equal to V4V_DOMID_ANY. If the insert is successfull
> then Xen will trigger the V4V VIRQ line in the receiving domain.
> 
> ** Reception
> 
> Xen pads all messages on the ring to 16 bytes (the macro V4V_ROUNDUP is provided 
> for convience), and inserts a message header infront of all messages it copies onto the ring.
> 
>  struct v4v_ring_message_header
>  {
>     uint32_t len;
>     struct v4v_addr source;
>     uint16_t pad;
>     uint32_t protocol;
>     uint8_t data[0];
>  };
> 
> len is the number of bytes in the message including the struct v4v_ring_message_header
> source specifies the source address from which the message came, source.domain is
> set by xen, and source.port is taken from the arguments to the send or sendv call.
> protocol is the protocol value given to the send call.
> 
> An  inline function is provided to make reading from the ring easier:
> 
>  ssize_t
>  v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
>               void *_buf, size_t t, int consume)

I guess that answers my question about avoiding a copy on the receiver. :(

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 Jun 07 11:42:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:42: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 1Scb6a-0007AN-U3; Thu, 07 Jun 2012 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 1Scb6Z-0007A8-6a
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:42:19 +0000
Received: from [85.158.139.83:33311] by server-11.bemta-5.messagelabs.com id
	9E/DC-25194-A9390DF4; Thu, 07 Jun 2012 11:42:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339069337!29724425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32593 invoked from network); 7 Jun 2012 11:42:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:42:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:42:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:42:17 +0100
Date: Thu, 7 Jun 2012 12:42:01 +0100
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: <1338565207-2888-37-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071239250.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-37-git-send-email-ian.campbell@citrix.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] [PATCH 37/38] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Based on init-xenstore-domain.c.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/xcutils/Makefile  |    6 ++-
>  tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 105 insertions(+), 1 deletions(-)
>  create mode 100644 tools/xcutils/xcbuild.c
> 
> diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> index 6c502f1..dcd2c84 100644
> --- a/tools/xcutils/Makefile
> +++ b/tools/xcutils/Makefile
> @@ -11,7 +11,7 @@
>  XEN_ROOT	= $(CURDIR)/../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> -PROGRAMS = xc_restore xc_save readnotes lsevtchn
> +PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
>  
>  CFLAGS += -Werror
>  
> @@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
>  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
> +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  
>  .PHONY: all
>  all: build
> @@ -32,6 +33,9 @@ xc_restore: xc_restore.o
>  xc_save: xc_save.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
>  
> +xcbuild: xcbuild.o
> +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> +
>  readnotes: readnotes.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
>  
> diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> new file mode 100644
> index 0000000..8f8660e
> --- /dev/null
> +++ b/tools/xcutils/xcbuild.c
> @@ -0,0 +1,100 @@
> +#include <unistd.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +
> +#include <errno.h>
> +
> +#include <xenctrl.h>
> +#include <xentoollog.h>
> +#include <xc_dom.h>
> +
> +int main(int argc, char **argv)
> +{
> +	xentoollog_logger *logger;
> +	xc_interface *xch;
> +	int rv;
> +	const char *image;
> +	uint32_t domid;
> +	xen_domain_handle_t handle;
> +	int maxmem = 128; /* MB */ //atoi(argv[2]);
> +	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
> +	struct xc_dom_image *dom;
> +
> +	image = (argc < 2) ? "guest.img" : argv[1];
> +	printf("Image: %s\n", image);
> +	printf("Memory: %dKB\n", memory_kb);
> +
> +	logger = (xentoollog_logger*)
> +		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
> +	if ( logger == NULL )
> +	{
> +		perror("xtl_createlogger_stdiostream");
> +		exit(1);
> +	}
> +
> +	xch = xc_interface_open(logger, logger, 0);
> +	if ( xch == NULL )
> +	{
> +		perror("xc_interface_open");
> +		exit(1);
> +	}
> +
> +	rv = xc_dom_loginit(xch);
> +	if (rv) return rv;
> +
> +	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
> +	//if (rv) return rv;
> +
> +	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
> +	printf("xc_domain_create: %d (%d)\n", rv, errno);
> +	if ( rv < 0 )
> +	{
> +		perror("xc_domain_create");
> +		exit(1);
> +	}
> +
> +	printf("building dom%d\n", domid);
> +
> +	rv = xc_domain_max_vcpus(xch, domid, 1);
> +	if ( rv < 0)
> +	{
> +		perror("xc_domain_max_vcpus");
> +		exit(1);
> +	}
> +
> +	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
> +	if ( rv < 0)
> +	{
> +		perror("xc_domain_setmaxmem");
> +		exit(1);
> +	}
> +
> +	dom = xc_dom_allocate(xch, "", NULL);
> +	rv = xc_dom_kernel_file(dom, image);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_xen_init(dom, xch, domid);
> +	if (rv) return rv;
> +	rv = xc_dom_parse_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
> +	if (rv) return rv;
> +	rv = xc_dom_boot_mem_init(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_build_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_image(dom);
> +	if (rv) return rv;
> +
> +	xc_dom_release(dom);
> +
> +	rv = xc_domain_unpause(xch, domid);
> +	if ( rv )
> +	{
> +		perror("xc_domain_unpause");
> +		exit(1);
> +	}
> +
> +	xc_interface_close(xch);
> +
> +	return 0;
> +}

It is OK but I would remove the commented out code and add a very basic
arguments check.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:42:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:42: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 1Scb6a-0007AN-U3; Thu, 07 Jun 2012 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 1Scb6Z-0007A8-6a
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:42:19 +0000
Received: from [85.158.139.83:33311] by server-11.bemta-5.messagelabs.com id
	9E/DC-25194-A9390DF4; Thu, 07 Jun 2012 11:42:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339069337!29724425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32593 invoked from network); 7 Jun 2012 11:42:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:42:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:42:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 12:42:17 +0100
Date: Thu, 7 Jun 2012 12:42:01 +0100
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: <1338565207-2888-37-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206071239250.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-37-git-send-email-ian.campbell@citrix.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] [PATCH 37/38] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Based on init-xenstore-domain.c.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/xcutils/Makefile  |    6 ++-
>  tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 105 insertions(+), 1 deletions(-)
>  create mode 100644 tools/xcutils/xcbuild.c
> 
> diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> index 6c502f1..dcd2c84 100644
> --- a/tools/xcutils/Makefile
> +++ b/tools/xcutils/Makefile
> @@ -11,7 +11,7 @@
>  XEN_ROOT	= $(CURDIR)/../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> -PROGRAMS = xc_restore xc_save readnotes lsevtchn
> +PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
>  
>  CFLAGS += -Werror
>  
> @@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
>  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
> +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  
>  .PHONY: all
>  all: build
> @@ -32,6 +33,9 @@ xc_restore: xc_restore.o
>  xc_save: xc_save.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
>  
> +xcbuild: xcbuild.o
> +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> +
>  readnotes: readnotes.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
>  
> diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> new file mode 100644
> index 0000000..8f8660e
> --- /dev/null
> +++ b/tools/xcutils/xcbuild.c
> @@ -0,0 +1,100 @@
> +#include <unistd.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +
> +#include <errno.h>
> +
> +#include <xenctrl.h>
> +#include <xentoollog.h>
> +#include <xc_dom.h>
> +
> +int main(int argc, char **argv)
> +{
> +	xentoollog_logger *logger;
> +	xc_interface *xch;
> +	int rv;
> +	const char *image;
> +	uint32_t domid;
> +	xen_domain_handle_t handle;
> +	int maxmem = 128; /* MB */ //atoi(argv[2]);
> +	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
> +	struct xc_dom_image *dom;
> +
> +	image = (argc < 2) ? "guest.img" : argv[1];
> +	printf("Image: %s\n", image);
> +	printf("Memory: %dKB\n", memory_kb);
> +
> +	logger = (xentoollog_logger*)
> +		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
> +	if ( logger == NULL )
> +	{
> +		perror("xtl_createlogger_stdiostream");
> +		exit(1);
> +	}
> +
> +	xch = xc_interface_open(logger, logger, 0);
> +	if ( xch == NULL )
> +	{
> +		perror("xc_interface_open");
> +		exit(1);
> +	}
> +
> +	rv = xc_dom_loginit(xch);
> +	if (rv) return rv;
> +
> +	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
> +	//if (rv) return rv;
> +
> +	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
> +	printf("xc_domain_create: %d (%d)\n", rv, errno);
> +	if ( rv < 0 )
> +	{
> +		perror("xc_domain_create");
> +		exit(1);
> +	}
> +
> +	printf("building dom%d\n", domid);
> +
> +	rv = xc_domain_max_vcpus(xch, domid, 1);
> +	if ( rv < 0)
> +	{
> +		perror("xc_domain_max_vcpus");
> +		exit(1);
> +	}
> +
> +	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
> +	if ( rv < 0)
> +	{
> +		perror("xc_domain_setmaxmem");
> +		exit(1);
> +	}
> +
> +	dom = xc_dom_allocate(xch, "", NULL);
> +	rv = xc_dom_kernel_file(dom, image);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_xen_init(dom, xch, domid);
> +	if (rv) return rv;
> +	rv = xc_dom_parse_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
> +	if (rv) return rv;
> +	rv = xc_dom_boot_mem_init(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_build_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_image(dom);
> +	if (rv) return rv;
> +
> +	xc_dom_release(dom);
> +
> +	rv = xc_domain_unpause(xch, domid);
> +	if ( rv )
> +	{
> +		perror("xc_domain_unpause");
> +		exit(1);
> +	}
> +
> +	xc_interface_close(xch);
> +
> +	return 0;
> +}

It is OK but I would remove the commented out code and add a very basic
arguments check.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 11:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Scb6x-0007Dg-FN; Thu, 07 Jun 2012 11:42: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 1Scb6w-0007DT-Gc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:42:42 +0000
Received: from [85.158.139.83:24557] by server-9.bemta-5.messagelabs.com id
	A6/3E-29678-1B390DF4; Thu, 07 Jun 2012 11:42:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339069360!29724498!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1800 invoked from network); 7 Jun 2012 11:42:41 -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; 7 Jun 2012 11:42:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scb6u-000Ivf-C3; Thu, 07 Jun 2012 11:42:40 +0000
Date: Thu, 7 Jun 2012 12:42:40 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607114240.GQ70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
	<20120607090808.GD70339@ocelot.phlegethon.org>
	<1339068947.18523.10.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339068947.18523.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,
	core}_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

At 12:35 +0100 on 07 Jun (1339072547), Ian Campbell wrote:
> From e980ca1ec9bf92b2f1255ac5222b1da1292f9f72 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 14 May 2012 12:25:31 +0100
> Subject: [PATCH] arm: Add simple cpu_{sibling,core}_mask
> 
> This needs to be done for all cpus. The allocations require smp_prepare_cpus
> to be called a bit later on.
> 
> In a previous version of this patch these maps were being zeroed (instead of
> setting the CPU itself in them). This in turn causes cpumask_first to return
> NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
> read off the end of its cnt array. Add a couple of asserts to catch this in
> the future.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

(ARM stuff) 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 Jun 07 11:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Scb6x-0007Dg-FN; Thu, 07 Jun 2012 11:42: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 1Scb6w-0007DT-Gc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:42:42 +0000
Received: from [85.158.139.83:24557] by server-9.bemta-5.messagelabs.com id
	A6/3E-29678-1B390DF4; Thu, 07 Jun 2012 11:42:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339069360!29724498!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1800 invoked from network); 7 Jun 2012 11:42:41 -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; 7 Jun 2012 11:42:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scb6u-000Ivf-C3; Thu, 07 Jun 2012 11:42:40 +0000
Date: Thu, 7 Jun 2012 12:42:40 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607114240.GQ70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
	<20120607090808.GD70339@ocelot.phlegethon.org>
	<1339068947.18523.10.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339068947.18523.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/38] arm: Add simple cpu_{sibling,
	core}_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

At 12:35 +0100 on 07 Jun (1339072547), Ian Campbell wrote:
> From e980ca1ec9bf92b2f1255ac5222b1da1292f9f72 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 14 May 2012 12:25:31 +0100
> Subject: [PATCH] arm: Add simple cpu_{sibling,core}_mask
> 
> This needs to be done for all cpus. The allocations require smp_prepare_cpus
> to be called a bit later on.
> 
> In a previous version of this patch these maps were being zeroed (instead of
> setting the CPU itself in them). This in turn causes cpumask_first to return
> NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
> read off the end of its cnt array. Add a couple of asserts to catch this in
> the future.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

(ARM stuff) 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 Jun 07 11:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:58: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 1ScbLV-0007an-WB; Thu, 07 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1ScbLU-0007ai-8J
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:57:44 +0000
Received: from [85.158.143.35:24306] by server-2.bemta-4.messagelabs.com id
	25/4A-17938-73790DF4; Thu, 07 Jun 2012 11:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1339070262!19281735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14503 invoked from network); 7 Jun 2012 11:57:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:57:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	12:57:41 +0100
Message-ID: <1339070260.18523.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 12:57:40 +0100
In-Reply-To: <20120607084517.GA70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
	<20120607084517.GA70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk
 of the hypervisor page 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

On Thu, 2012-06-07 at 09:45 +0100, Tim Deegan wrote:
> Hi,
> 
> At 15:39 +0000 on 01 Jun (1338565171), Ian Campbell wrote:
> > +void dump_pt_walk(uint32_t addr)
> > +{
> > +    paddr_t second_ma, third_ma;
> > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > +    uint64_t httbr = READ_CP64(HTTBR);
> > +
> > +    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
> > +           addr, httbr);
> > +
> > +    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
> > +    first = xen_pgtable;
> > +    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > +           first_table_offset(addr),
> > +           first, first_table_offset(addr),
> > +           virt_to_maddr(&first[first_table_offset(addr)]),
> > +           first[first_table_offset(addr)].bits);
> > +
> > +    if ( !first[first_table_offset(addr)].pt.valid ||
> > +         !first[first_table_offset(addr)].pt.table )
> > +        goto done;
> 
> This could probably be a for loop rather than open-coding three
> almost-identical printks.

The *_table_offsets macro names are different at each stage, I suppose I
could open code the equivalent shifts, but I'd rather keep using the
access macros.

> > +
> > +    second_ma = (paddr_t)first[first_table_offset(addr)].pt.base << PAGE_SHIFT;
> > +    second = (lpae_t *)(unsigned long)(second_ma - xen_phys_offset);
> > +    printk("2ND[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > +           second_table_offset(addr),
> > +           second, second_table_offset(addr),
> > +           virt_to_maddr(&second[second_table_offset(addr)]),
> > +           second[second_table_offset(addr)].bits);
> > +    if ( !second[second_table_offset(addr)].pt.valid ||
> > +         !second[second_table_offset(addr)].pt.table )
> > +        goto done;
> > +
> > +    third_ma = (paddr_t)second[second_table_offset(addr)].pt.base << PAGE_SHIFT;
> > +    third = (lpae_t *)(unsigned long)(third_ma - xen_phys_offset);
> > +    printk("3RD[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > +           third_table_offset(addr),
> > +           third, third_table_offset(addr),
> > +           virt_to_maddr(&third[third_table_offset(addr)]),
> > +           third[third_table_offset(addr)].bits);
> > +    if ( !third[third_table_offset(addr)].pt.valid ||
> > +         !third[third_table_offset(addr)].pt.table )
> > +        goto done;
> > +
> > +done:
> > +    return;
> 
> Maybe use return above instead of goto?

Yes, good idea.

> 
> > +}
> > +
> >  /* Map a 4k page in a fixmap entry */
> >  void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
> >  {
> > @@ -173,8 +222,8 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> >      flush_xen_data_tlb_va(dest_va);
> >  
> >      /* Calculate virt-to-phys offset for the new location */
> > -    phys_offset = xen_paddr - (unsigned long) _start;
> > -
> > +    xen_phys_offset = phys_offset = xen_paddr - (unsigned long) _start;
> > +    
> 
> Just make phys_offset file-scope static; no need to add a new variable
> for this.

Will do.

> 
> >      /* Copy */
> >      memcpy((void *) dest_va, _start, _end - _start);
> >  
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index b6df64e..22c56b5 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -312,6 +312,8 @@ static inline uint64_t gva_to_ipa(uint32_t va)
> >  /* Bits in the PAR returned by va_to_par */
> >  #define PAR_FAULT 0x1
> >  
> > +extern void dump_pt_walk(uint32_t addr);
> > +
> 
> Maybe a comment?

Yes, 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 Jun 07 11:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 11:58: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 1ScbLV-0007an-WB; Thu, 07 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1ScbLU-0007ai-8J
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 11:57:44 +0000
Received: from [85.158.143.35:24306] by server-2.bemta-4.messagelabs.com id
	25/4A-17938-73790DF4; Thu, 07 Jun 2012 11:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1339070262!19281735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14503 invoked from network); 7 Jun 2012 11:57:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 11:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,730,1330905600"; d="scan'208";a="12879769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:57:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	12:57:41 +0100
Message-ID: <1339070260.18523.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 12:57:40 +0100
In-Reply-To: <20120607084517.GA70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
	<20120607084517.GA70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk
 of the hypervisor page 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

On Thu, 2012-06-07 at 09:45 +0100, Tim Deegan wrote:
> Hi,
> 
> At 15:39 +0000 on 01 Jun (1338565171), Ian Campbell wrote:
> > +void dump_pt_walk(uint32_t addr)
> > +{
> > +    paddr_t second_ma, third_ma;
> > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > +    uint64_t httbr = READ_CP64(HTTBR);
> > +
> > +    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
> > +           addr, httbr);
> > +
> > +    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
> > +    first = xen_pgtable;
> > +    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > +           first_table_offset(addr),
> > +           first, first_table_offset(addr),
> > +           virt_to_maddr(&first[first_table_offset(addr)]),
> > +           first[first_table_offset(addr)].bits);
> > +
> > +    if ( !first[first_table_offset(addr)].pt.valid ||
> > +         !first[first_table_offset(addr)].pt.table )
> > +        goto done;
> 
> This could probably be a for loop rather than open-coding three
> almost-identical printks.

The *_table_offsets macro names are different at each stage, I suppose I
could open code the equivalent shifts, but I'd rather keep using the
access macros.

> > +
> > +    second_ma = (paddr_t)first[first_table_offset(addr)].pt.base << PAGE_SHIFT;
> > +    second = (lpae_t *)(unsigned long)(second_ma - xen_phys_offset);
> > +    printk("2ND[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > +           second_table_offset(addr),
> > +           second, second_table_offset(addr),
> > +           virt_to_maddr(&second[second_table_offset(addr)]),
> > +           second[second_table_offset(addr)].bits);
> > +    if ( !second[second_table_offset(addr)].pt.valid ||
> > +         !second[second_table_offset(addr)].pt.table )
> > +        goto done;
> > +
> > +    third_ma = (paddr_t)second[second_table_offset(addr)].pt.base << PAGE_SHIFT;
> > +    third = (lpae_t *)(unsigned long)(third_ma - xen_phys_offset);
> > +    printk("3RD[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > +           third_table_offset(addr),
> > +           third, third_table_offset(addr),
> > +           virt_to_maddr(&third[third_table_offset(addr)]),
> > +           third[third_table_offset(addr)].bits);
> > +    if ( !third[third_table_offset(addr)].pt.valid ||
> > +         !third[third_table_offset(addr)].pt.table )
> > +        goto done;
> > +
> > +done:
> > +    return;
> 
> Maybe use return above instead of goto?

Yes, good idea.

> 
> > +}
> > +
> >  /* Map a 4k page in a fixmap entry */
> >  void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
> >  {
> > @@ -173,8 +222,8 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> >      flush_xen_data_tlb_va(dest_va);
> >  
> >      /* Calculate virt-to-phys offset for the new location */
> > -    phys_offset = xen_paddr - (unsigned long) _start;
> > -
> > +    xen_phys_offset = phys_offset = xen_paddr - (unsigned long) _start;
> > +    
> 
> Just make phys_offset file-scope static; no need to add a new variable
> for this.

Will do.

> 
> >      /* Copy */
> >      memcpy((void *) dest_va, _start, _end - _start);
> >  
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index b6df64e..22c56b5 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -312,6 +312,8 @@ static inline uint64_t gva_to_ipa(uint32_t va)
> >  /* Bits in the PAR returned by va_to_par */
> >  #define PAR_FAULT 0x1
> >  
> > +extern void dump_pt_walk(uint32_t addr);
> > +
> 
> Maybe a comment?

Yes, 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 Jun 07 12:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12: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 1ScbUj-00085x-O4; Thu, 07 Jun 2012 12:07:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScbUi-00085s-MA
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:07:16 +0000
Received: from [193.109.254.147:37036] by server-7.bemta-14.messagelabs.com id
	C4/3F-29165-37990DF4; Thu, 07 Jun 2012 12:07:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339070820!8545175!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24374 invoked from network); 7 Jun 2012 12:07:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 12:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12879989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 12:06:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	13:06:50 +0100
Message-ID: <1339070809.18523.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 13:06:49 +0100
In-Reply-To: <alpine.DEB.2.02.1206071239250.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-37-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071239250.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 37/38] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 12:42 +0100, Stefano Stabellini wrote:
> It is OK but I would remove the commented out code and add a very basic
> arguments check.

Thanks, but this one was just for testing etc rather than commit

In general the things with HACK in them were just for illustration and
or to allow you to exercise the non-HACK patches.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12: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 1ScbUj-00085x-O4; Thu, 07 Jun 2012 12:07:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ScbUi-00085s-MA
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:07:16 +0000
Received: from [193.109.254.147:37036] by server-7.bemta-14.messagelabs.com id
	C4/3F-29165-37990DF4; Thu, 07 Jun 2012 12:07:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339070820!8545175!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24374 invoked from network); 7 Jun 2012 12:07:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 12:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12879989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 12:06:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	13:06:50 +0100
Message-ID: <1339070809.18523.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 13:06:49 +0100
In-Reply-To: <alpine.DEB.2.02.1206071239250.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-37-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071239250.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 37/38] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 12:42 +0100, Stefano Stabellini wrote:
> It is OK but I would remove the commented out code and add a very basic
> arguments check.

Thanks, but this one was just for testing etc rather than commit

In general the things with HACK in them were just for illustration and
or to allow you to exercise the non-HACK patches.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:27:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12: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 1Scbo0-0008GQ-KV; Thu, 07 Jun 2012 12:27: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 1Scbny-0008GL-PZ
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:27:11 +0000
Received: from [85.158.138.51:49065] by server-6.bemta-3.messagelabs.com id
	E0/A0-05063-E1E90DF4; Thu, 07 Jun 2012 12:27:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339072029!31289214!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28679 invoked from network); 7 Jun 2012 12:27:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 12:27:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12880511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 12:26:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	13:26:46 +0100
Message-ID: <1339072005.18523.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 13:26:45 +0100
In-Reply-To: <20120607084917.GB70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 09:49 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> > Useful for debug but not actually used in this patch.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/page.h |    1 +
> >  2 files changed, 35 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 4f624d8..fdbecbc 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -5,6 +5,40 @@
> >  #include <xen/domain_page.h>
> >  #include <asm/flushtlb.h>
> >  
> > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > +{
> > +    struct p2m_domain *p2m = &d->arch.p2m;
> > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > +
> > +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > +
> > +    first = __map_domain_page(p2m->first_level);
> > +    printk("1ST[%#03llx] = %#016llx\n",
> > +           first_table_offset(addr),
> > +           first[first_table_offset(addr)].bits);
> > +    if ( !first[first_table_offset(addr)].p2m.valid ||
> > +         !first[first_table_offset(addr)].p2m.table )
> > +        goto done;
> > +
> > +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > +    printk("2ND[%#03llx] = %#016llx\n",
> > +           second_table_offset(addr),
> > +           second[second_table_offset(addr)].bits);
> > +    if ( !second[second_table_offset(addr)].p2m.valid ||
> > +         !second[second_table_offset(addr)].p2m.table )
> > +        goto done;
> > +
> > +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > +    printk("3RD[%#03llx] = %#016llx\n",
> > +           third_table_offset(addr),
> > +           third[third_table_offset(addr)].bits);
> > +
> > +done:
> > +    if (third) unmap_domain_page(third);
> > +    if (second) unmap_domain_page(second);
> > +    if (first) unmap_domain_page(first);
> > +}
> 
> Can this be unified with dump_pt_walk?

Not all that easily, mainly because dump_pt_walk walks xenheap pages
(which don't need mapping) while dump_p2m_walk dumps domheap pages
(which need mapping as we go). I probably could write something generic
enough but I fear that it would be a mass of if's.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:27:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12: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 1Scbo0-0008GQ-KV; Thu, 07 Jun 2012 12:27: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 1Scbny-0008GL-PZ
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:27:11 +0000
Received: from [85.158.138.51:49065] by server-6.bemta-3.messagelabs.com id
	E0/A0-05063-E1E90DF4; Thu, 07 Jun 2012 12:27:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1339072029!31289214!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28679 invoked from network); 7 Jun 2012 12:27:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 12:27:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12880511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 12:26:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	13:26:46 +0100
Message-ID: <1339072005.18523.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 13:26:45 +0100
In-Reply-To: <20120607084917.GB70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 09:49 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> > Useful for debug but not actually used in this patch.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/page.h |    1 +
> >  2 files changed, 35 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 4f624d8..fdbecbc 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -5,6 +5,40 @@
> >  #include <xen/domain_page.h>
> >  #include <asm/flushtlb.h>
> >  
> > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > +{
> > +    struct p2m_domain *p2m = &d->arch.p2m;
> > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > +
> > +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > +
> > +    first = __map_domain_page(p2m->first_level);
> > +    printk("1ST[%#03llx] = %#016llx\n",
> > +           first_table_offset(addr),
> > +           first[first_table_offset(addr)].bits);
> > +    if ( !first[first_table_offset(addr)].p2m.valid ||
> > +         !first[first_table_offset(addr)].p2m.table )
> > +        goto done;
> > +
> > +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > +    printk("2ND[%#03llx] = %#016llx\n",
> > +           second_table_offset(addr),
> > +           second[second_table_offset(addr)].bits);
> > +    if ( !second[second_table_offset(addr)].p2m.valid ||
> > +         !second[second_table_offset(addr)].p2m.table )
> > +        goto done;
> > +
> > +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > +    printk("3RD[%#03llx] = %#016llx\n",
> > +           third_table_offset(addr),
> > +           third[third_table_offset(addr)].bits);
> > +
> > +done:
> > +    if (third) unmap_domain_page(third);
> > +    if (second) unmap_domain_page(second);
> > +    if (first) unmap_domain_page(first);
> > +}
> 
> Can this be unified with dump_pt_walk?

Not all that easily, mainly because dump_pt_walk walks xenheap pages
(which don't need mapping) while dump_p2m_walk dumps domheap pages
(which need mapping as we go). I probably could write something generic
enough but I fear that it would be a mass of if's.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:39:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:39: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 1Scbzq-00008P-Bq; Thu, 07 Jun 2012 12:39:26 +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 1Scbzp-00008K-7U
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:39:25 +0000
Received: from [193.109.254.147:15795] by server-11.bemta-14.messagelabs.com
	id EA/6E-02727-CF0A0DF4; Thu, 07 Jun 2012 12:39:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339072763!8553453!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16795 invoked from network); 7 Jun 2012 12:39:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 12:39:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scbzm-000J4d-Jz; Thu, 07 Jun 2012 12:39:22 +0000
Date: Thu, 7 Jun 2012 13:39:22 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607123922.GR70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
	<20120607084517.GA70339@ocelot.phlegethon.org>
	<1339070260.18523.14.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339070260.18523.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk
	of the hypervisor page 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 12:57 +0100 on 07 Jun (1339073860), Ian Campbell wrote:
> On Thu, 2012-06-07 at 09:45 +0100, Tim Deegan wrote:
> > Hi,
> > 
> > At 15:39 +0000 on 01 Jun (1338565171), Ian Campbell wrote:
> > > +void dump_pt_walk(uint32_t addr)
> > > +{
> > > +    paddr_t second_ma, third_ma;
> > > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > > +    uint64_t httbr = READ_CP64(HTTBR);
> > > +
> > > +    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
> > > +           addr, httbr);
> > > +
> > > +    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
> > > +    first = xen_pgtable;
> > > +    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > > +           first_table_offset(addr),
> > > +           first, first_table_offset(addr),
> > > +           virt_to_maddr(&first[first_table_offset(addr)]),
> > > +           first[first_table_offset(addr)].bits);
> > > +
> > > +    if ( !first[first_table_offset(addr)].pt.valid ||
> > > +         !first[first_table_offset(addr)].pt.table )
> > > +        goto done;
> > 
> > This could probably be a for loop rather than open-coding three
> > almost-identical printks.
> 
> The *_table_offsets macro names are different at each stage, I suppose I
> could open code the equivalent shifts, but I'd rather keep using the
> access macros.

Ah, OK.  In that case, open-coded is fine. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:39:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:39: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 1Scbzq-00008P-Bq; Thu, 07 Jun 2012 12:39:26 +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 1Scbzp-00008K-7U
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:39:25 +0000
Received: from [193.109.254.147:15795] by server-11.bemta-14.messagelabs.com
	id EA/6E-02727-CF0A0DF4; Thu, 07 Jun 2012 12:39:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339072763!8553453!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16795 invoked from network); 7 Jun 2012 12:39:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 12:39:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scbzm-000J4d-Jz; Thu, 07 Jun 2012 12:39:22 +0000
Date: Thu, 7 Jun 2012 13:39:22 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607123922.GR70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-2-git-send-email-ian.campbell@citrix.com>
	<20120607084517.GA70339@ocelot.phlegethon.org>
	<1339070260.18523.14.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339070260.18523.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/38] arm: handy function to print a walk
	of the hypervisor page 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 12:57 +0100 on 07 Jun (1339073860), Ian Campbell wrote:
> On Thu, 2012-06-07 at 09:45 +0100, Tim Deegan wrote:
> > Hi,
> > 
> > At 15:39 +0000 on 01 Jun (1338565171), Ian Campbell wrote:
> > > +void dump_pt_walk(uint32_t addr)
> > > +{
> > > +    paddr_t second_ma, third_ma;
> > > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > > +    uint64_t httbr = READ_CP64(HTTBR);
> > > +
> > > +    printk("Walking Hypervisor VA %#"PRIx32" via HTTBR %#"PRIx64"\n",
> > > +           addr, httbr);
> > > +
> > > +    BUG_ON( (lpae_t *)(unsigned long)(httbr - xen_phys_offset) != xen_pgtable );
> > > +    first = xen_pgtable;
> > > +    printk("1ST[%#03"PRIx32"] = %p[%#03"PRIx32"] = %#llx = %#016llx\n",
> > > +           first_table_offset(addr),
> > > +           first, first_table_offset(addr),
> > > +           virt_to_maddr(&first[first_table_offset(addr)]),
> > > +           first[first_table_offset(addr)].bits);
> > > +
> > > +    if ( !first[first_table_offset(addr)].pt.valid ||
> > > +         !first[first_table_offset(addr)].pt.table )
> > > +        goto done;
> > 
> > This could probably be a for loop rather than open-coding three
> > almost-identical printks.
> 
> The *_table_offsets macro names are different at each stage, I suppose I
> could open code the equivalent shifts, but I'd rather keep using the
> access macros.

Ah, OK.  In that case, open-coded is fine. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scc0z-0000Bd-QO; Thu, 07 Jun 2012 12:40: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 1Scc0y-0000BX-8y
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:40:36 +0000
Received: from [193.109.254.147:30020] by server-11.bemta-14.messagelabs.com
	id 7B/DF-02727-341A0DF4; Thu, 07 Jun 2012 12:40:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339072833!8613049!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19215 invoked from network); 7 Jun 2012 12:40:34 -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; 7 Jun 2012 12:40:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scc0v-000J5H-NQ; Thu, 07 Jun 2012 12:40:33 +0000
Date: Thu, 7 Jun 2012 13:40:33 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607124033.GS70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339072005.18523.18.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
	of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:26 +0100 on 07 Jun (1339075605), Ian Campbell wrote:
> On Thu, 2012-06-07 at 09:49 +0100, Tim Deegan wrote:
> > At 15:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> > > Useful for debug but not actually used in this patch.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
> > >  xen/include/asm-arm/page.h |    1 +
> > >  2 files changed, 35 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index 4f624d8..fdbecbc 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -5,6 +5,40 @@
> > >  #include <xen/domain_page.h>
> > >  #include <asm/flushtlb.h>
> > >  
> > > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > > +{
> > > +    struct p2m_domain *p2m = &d->arch.p2m;
> > > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > > +
> > > +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > > +
> > > +    first = __map_domain_page(p2m->first_level);
> > > +    printk("1ST[%#03llx] = %#016llx\n",
> > > +           first_table_offset(addr),
> > > +           first[first_table_offset(addr)].bits);
> > > +    if ( !first[first_table_offset(addr)].p2m.valid ||
> > > +         !first[first_table_offset(addr)].p2m.table )
> > > +        goto done;
> > > +
> > > +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > > +    printk("2ND[%#03llx] = %#016llx\n",
> > > +           second_table_offset(addr),
> > > +           second[second_table_offset(addr)].bits);
> > > +    if ( !second[second_table_offset(addr)].p2m.valid ||
> > > +         !second[second_table_offset(addr)].p2m.table )
> > > +        goto done;
> > > +
> > > +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > > +    printk("3RD[%#03llx] = %#016llx\n",
> > > +           third_table_offset(addr),
> > > +           third[third_table_offset(addr)].bits);
> > > +
> > > +done:
> > > +    if (third) unmap_domain_page(third);
> > > +    if (second) unmap_domain_page(second);
> > > +    if (first) unmap_domain_page(first);
> > > +}
> > 
> > Can this be unified with dump_pt_walk?
> 
> Not all that easily, mainly because dump_pt_walk walks xenheap pages
> (which don't need mapping) while dump_p2m_walk dumps domheap pages
> (which need mapping as we go). I probably could write something generic
> enough but I fear that it would be a mass of if's.

Is there any harm in mapping xenheap pages?  Since this is only invoked
on error paths, we don't particularly need it to be fast. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scc0z-0000Bd-QO; Thu, 07 Jun 2012 12:40: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 1Scc0y-0000BX-8y
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 12:40:36 +0000
Received: from [193.109.254.147:30020] by server-11.bemta-14.messagelabs.com
	id 7B/DF-02727-341A0DF4; Thu, 07 Jun 2012 12:40:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339072833!8613049!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19215 invoked from network); 7 Jun 2012 12:40:34 -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; 7 Jun 2012 12:40:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scc0v-000J5H-NQ; Thu, 07 Jun 2012 12:40:33 +0000
Date: Thu, 7 Jun 2012 13:40:33 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607124033.GS70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339072005.18523.18.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
	of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:26 +0100 on 07 Jun (1339075605), Ian Campbell wrote:
> On Thu, 2012-06-07 at 09:49 +0100, Tim Deegan wrote:
> > At 15:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> > > Useful for debug but not actually used in this patch.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
> > >  xen/include/asm-arm/page.h |    1 +
> > >  2 files changed, 35 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index 4f624d8..fdbecbc 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -5,6 +5,40 @@
> > >  #include <xen/domain_page.h>
> > >  #include <asm/flushtlb.h>
> > >  
> > > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > > +{
> > > +    struct p2m_domain *p2m = &d->arch.p2m;
> > > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > > +
> > > +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > > +
> > > +    first = __map_domain_page(p2m->first_level);
> > > +    printk("1ST[%#03llx] = %#016llx\n",
> > > +           first_table_offset(addr),
> > > +           first[first_table_offset(addr)].bits);
> > > +    if ( !first[first_table_offset(addr)].p2m.valid ||
> > > +         !first[first_table_offset(addr)].p2m.table )
> > > +        goto done;
> > > +
> > > +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > > +    printk("2ND[%#03llx] = %#016llx\n",
> > > +           second_table_offset(addr),
> > > +           second[second_table_offset(addr)].bits);
> > > +    if ( !second[second_table_offset(addr)].p2m.valid ||
> > > +         !second[second_table_offset(addr)].p2m.table )
> > > +        goto done;
> > > +
> > > +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > > +    printk("3RD[%#03llx] = %#016llx\n",
> > > +           third_table_offset(addr),
> > > +           third[third_table_offset(addr)].bits);
> > > +
> > > +done:
> > > +    if (third) unmap_domain_page(third);
> > > +    if (second) unmap_domain_page(second);
> > > +    if (first) unmap_domain_page(first);
> > > +}
> > 
> > Can this be unified with dump_pt_walk?
> 
> Not all that easily, mainly because dump_pt_walk walks xenheap pages
> (which don't need mapping) while dump_p2m_walk dumps domheap pages
> (which need mapping as we go). I probably could write something generic
> enough but I fear that it would be a mass of if's.

Is there any harm in mapping xenheap pages?  Since this is only invoked
on error paths, we don't particularly need it to be fast. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:43:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:43: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 1Scc3q-0000MD-Cf; Thu, 07 Jun 2012 12:43:34 +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 1Scc3o-0000M2-Q2
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:43:33 +0000
Received: from [85.158.143.35:31159] by server-3.bemta-4.messagelabs.com id
	7D/3E-29237-3F1A0DF4; Thu, 07 Jun 2012 12:43:31 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339073009!8302247!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31606 invoked from network); 7 Jun 2012 12:43:31 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Jun 2012 12:43:31 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Scc3l-00057h-BE
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 05:43:29 -0700
Date: Thu, 7 Jun 2012 05:43:29 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1339073009338-5709334.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Test result of xen-unstable changeset 25459
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.18-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25459:f6bfaf9daa50)
vi config/StdGNU.mk # Workaround for Wheezy with multiarch support, there
are parts that use LIBDIR set here instead of the one in configure (libdir)
LIBLEAFDIR_x86_64 ?= lib
vi Config.mk
PYTHON_PREFIX_ARG =
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
- libxc: do not "panic" if a kernel is not a bzImage.
- tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons
start
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb


-------------------------
Old issue:
-------------
- Network not working after save/restore on W7 64 bit domU with qemu
upstream
-------------
- HVM domU continue booting even if qemu-xen not start correctly:
xl create /etc/xen/PRECISEHVM.cfg
Parsing config from /etc/xen/PRECISEHVM.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_exec.c:371:spawn_timeout: domain 26 device model:
startup timed out
libxl: error: libxl_dm.c:1066:device_model_spawn_outcome: domain 26 device
model: spawn failed (rc=-3)
libxl: error: libxl_qmp.c:641:libxl__qmp_initialize: Connection error:
Connection refused
Daemon running with PID 9137
root@vfarm:/mnt/vm/xen/xen-unstable.hg# xl list
Name                                        ID   Mem VCPUs      State  
Time(s)
Domain-0                                     0  2047     8     r-----   
1791.8
PRECISEHVM                                  26  1015     1     ------      
0.0
-------------------------

-------------------------
Fixed issue:
-------------
-
http://xen.1045712.n5.nabble.com/Build-error-of-libxl-in-xen-unstable-changeset-25374-td5709046.html
-------------------------

-------------------------
Old regression:
-------------
- CRITICAL - PV domU unable to start:
With pygrub:
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: error: libxl_bootloader.c:517:bootloader_finished: bootloader failed
- consult logfile /var/log/xen/bootloader.14.log
libxl: error: libxl_exec.c:108:libxl_report_child_exitstatus: bootloader
[6196] exited with error status 1
--------------
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 822, in <module>
    raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel
--------------
With pv-grub:
Starts but arrive at grubdom (see with xl console)

Tried also with xen-unstable old commit and old kernel package, same
problem, cause unknown.
------------------------- 

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25459-tp5709334.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:43:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:43: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 1Scc3q-0000MD-Cf; Thu, 07 Jun 2012 12:43:34 +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 1Scc3o-0000M2-Q2
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:43:33 +0000
Received: from [85.158.143.35:31159] by server-3.bemta-4.messagelabs.com id
	7D/3E-29237-3F1A0DF4; Thu, 07 Jun 2012 12:43:31 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339073009!8302247!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31606 invoked from network); 7 Jun 2012 12:43:31 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Jun 2012 12:43:31 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Scc3l-00057h-BE
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 05:43:29 -0700
Date: Thu, 7 Jun 2012 05:43:29 -0700 (PDT)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1339073009338-5709334.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Test result of xen-unstable changeset 25459
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.18-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25459:f6bfaf9daa50)
vi config/StdGNU.mk # Workaround for Wheezy with multiarch support, there
are parts that use LIBDIR set here instead of the one in configure (libdir)
LIBLEAFDIR_x86_64 ?= lib
vi Config.mk
PYTHON_PREFIX_ARG =
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
- libxc: do not "panic" if a kernel is not a bzImage.
- tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons
start
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb


-------------------------
Old issue:
-------------
- Network not working after save/restore on W7 64 bit domU with qemu
upstream
-------------
- HVM domU continue booting even if qemu-xen not start correctly:
xl create /etc/xen/PRECISEHVM.cfg
Parsing config from /etc/xen/PRECISEHVM.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_exec.c:371:spawn_timeout: domain 26 device model:
startup timed out
libxl: error: libxl_dm.c:1066:device_model_spawn_outcome: domain 26 device
model: spawn failed (rc=-3)
libxl: error: libxl_qmp.c:641:libxl__qmp_initialize: Connection error:
Connection refused
Daemon running with PID 9137
root@vfarm:/mnt/vm/xen/xen-unstable.hg# xl list
Name                                        ID   Mem VCPUs      State  
Time(s)
Domain-0                                     0  2047     8     r-----   
1791.8
PRECISEHVM                                  26  1015     1     ------      
0.0
-------------------------

-------------------------
Fixed issue:
-------------
-
http://xen.1045712.n5.nabble.com/Build-error-of-libxl-in-xen-unstable-changeset-25374-td5709046.html
-------------------------

-------------------------
Old regression:
-------------
- CRITICAL - PV domU unable to start:
With pygrub:
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: error: libxl_bootloader.c:517:bootloader_finished: bootloader failed
- consult logfile /var/log/xen/bootloader.14.log
libxl: error: libxl_exec.c:108:libxl_report_child_exitstatus: bootloader
[6196] exited with error status 1
--------------
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 822, in <module>
    raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel
--------------
With pv-grub:
Starts but arrive at grubdom (see with xl console)

Tried also with xen-unstable old commit and old kernel package, same
problem, cause unknown.
------------------------- 

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25459-tp5709334.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12: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 1Scc6O-0000VA-UA; Thu, 07 Jun 2012 12:46: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 1Scc6N-0000V3-Km
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:46:11 +0000
Received: from [85.158.138.51:29316] by server-11.bemta-3.messagelabs.com id
	4E/67-28329-292A0DF4; Thu, 07 Jun 2012 12:46:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339073169!31344515!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8801 invoked from network); 7 Jun 2012 12:46:10 -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 Jun 2012 12:46:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scc6I-000J6Y-Lj; Thu, 07 Jun 2012 12:46:06 +0000
Date: Thu, 7 Jun 2012 13:46:06 +0100
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120607124606.GT70339@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xensource.com,
	Tim.Deegan@citrix.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
	VCPUs not currently 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

At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> +static void gic_restore_pending_irqs(struct vcpu *v)
> +{
> +    int i;
> +    struct pending_irq *p;
> +
> +    /* check for new pending irqs */
> +    if ( list_empty(&v->arch.vgic.lr_pending) )
> +        return;
> +
> +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> +    {
> +        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
> +        if ( i < nr_lrs )
> +        {
> +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +            list_del_init(&p->lr_queue);
> +            set_bit(i, &gic.lr_mask);
> +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> +                set_bit(i, &gic.event_mask);
> +        } else
> +        {
> +            return;
> +        }

This is a bit ugly - maybe "if ( i >= nr_lrs ) return" above and don't
indent the block?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12: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 1Scc6O-0000VA-UA; Thu, 07 Jun 2012 12:46: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 1Scc6N-0000V3-Km
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:46:11 +0000
Received: from [85.158.138.51:29316] by server-11.bemta-3.messagelabs.com id
	4E/67-28329-292A0DF4; Thu, 07 Jun 2012 12:46:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339073169!31344515!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8801 invoked from network); 7 Jun 2012 12:46:10 -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 Jun 2012 12:46:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scc6I-000J6Y-Lj; Thu, 07 Jun 2012 12:46:06 +0000
Date: Thu, 7 Jun 2012 13:46:06 +0100
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120607124606.GT70339@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xensource.com,
	Tim.Deegan@citrix.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
	VCPUs not currently 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

At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> +static void gic_restore_pending_irqs(struct vcpu *v)
> +{
> +    int i;
> +    struct pending_irq *p;
> +
> +    /* check for new pending irqs */
> +    if ( list_empty(&v->arch.vgic.lr_pending) )
> +        return;
> +
> +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> +    {
> +        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
> +        if ( i < nr_lrs )
> +        {
> +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +            list_del_init(&p->lr_queue);
> +            set_bit(i, &gic.lr_mask);
> +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> +                set_bit(i, &gic.event_mask);
> +        } else
> +        {
> +            return;
> +        }

This is a bit ugly - maybe "if ( i >= nr_lrs ) return" above and don't
indent the block?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 12:48:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:48: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 1Scc81-0000bK-E4; Thu, 07 Jun 2012 12:47: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 1Scc80-0000bE-Bx
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:47:52 +0000
Received: from [85.158.138.51:50087] by server-9.bemta-3.messagelabs.com id
	4D/5D-15054-7F2A0DF4; Thu, 07 Jun 2012 12:47:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339073270!12577299!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14044 invoked from network); 7 Jun 2012 12:47:50 -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; 7 Jun 2012 12:47:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scc7x-000J70-Sz; Thu, 07 Jun 2012 12:47:49 +0000
Date: Thu, 7 Jun 2012 13:47:49 +0100
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120607124749.GU70339@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/5] xen/arm: multiple guests support in the
	GIC and VGIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:20 +0100 on 06 Jun (1338985240), Stefano Stabellini wrote:
> Hi all,
> this patch series fixes the GIC, VGIC and vtimer issues that caused dom1
> to hang, as described by Ian in
> http://marc.info/?l=xen-devel&m=133856539418794.
> 
> With this patch series applied on top of Ian's, dom1 boots up to:
> 
> VFS: Cannot open root device "(null)" or unknown-block(2,0)
> 

I had one style nit on patch 3; you can add my Ack to all the others
(though IanC has a better grasp of the vgic stuff than I do and may
contradict me).

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 Jun 07 12:48:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 12:48: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 1Scc81-0000bK-E4; Thu, 07 Jun 2012 12:47: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 1Scc80-0000bE-Bx
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:47:52 +0000
Received: from [85.158.138.51:50087] by server-9.bemta-3.messagelabs.com id
	4D/5D-15054-7F2A0DF4; Thu, 07 Jun 2012 12:47:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339073270!12577299!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14044 invoked from network); 7 Jun 2012 12:47:50 -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; 7 Jun 2012 12:47:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Scc7x-000J70-Sz; Thu, 07 Jun 2012 12:47:49 +0000
Date: Thu, 7 Jun 2012 13:47:49 +0100
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120607124749.GU70339@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/5] xen/arm: multiple guests support in the
	GIC and VGIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:20 +0100 on 06 Jun (1338985240), Stefano Stabellini wrote:
> Hi all,
> this patch series fixes the GIC, VGIC and vtimer issues that caused dom1
> to hang, as described by Ian in
> http://marc.info/?l=xen-devel&m=133856539418794.
> 
> With this patch series applied on top of Ian's, dom1 boots up to:
> 
> VFS: Cannot open root device "(null)" or unknown-block(2,0)
> 

I had one style nit on patch 3; you can add my Ack to all the others
(though IanC has a better grasp of the vgic stuff than I do and may
contradict me).

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 Jun 07 13:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SccY3-0001KJ-Eu; Thu, 07 Jun 2012 13:14:47 +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 1SccY2-0001Jy-0g
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:14:46 +0000
Received: from [85.158.139.83:15513] by server-6.bemta-5.messagelabs.com id
	26/2A-18700-449A0DF4; Thu, 07 Jun 2012 13:14:44 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339074882!28190265!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6687 invoked from network); 7 Jun 2012 13:14:43 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:14:43 -0000
Received: by qaeb19 with SMTP id b19so122644qae.11
	for <multiple recipients>; Thu, 07 Jun 2012 06:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=e9TSWflGY7t9BEJAN1WDekuzfXqvwYy2apIGRWkLddQ=;
	b=PUE1se8v0Ch8Lr60prDEsDQ3ygVUo6oFT4FaMAx7mDiWTCvx+Z5+N9n9Iwnh8sC2ZG
	8WKNiPe3ZmKMKjak7ovEnU1+XydhO/2Ic0FObURDN60OxlpFkNrAAju1IOCqmRc8D6ea
	YnAuMq7d2FINuuOQvjrABQMW8zHP4x+ntEzeFVetOkbJPyvKScOkutWBrRNDljbZLcDy
	yMtCr8I4Oc2+KSU8RqkoFwJdYokcuEjpeKr/tPwCG0hPmZdmjX53AxideGmTWROGiLRW
	3TM51Xbou3qQgzaXdBK3TfmTKsxJG0wRrRvBFigYRtauD8eL8YymahcnExdu7TQCFM+m
	JxHQ==
MIME-Version: 1.0
Received: by 10.224.206.198 with SMTP id fv6mr2775401qab.6.1339074881893; Thu,
	07 Jun 2012 06:14:41 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 7 Jun 2012 06:14:41 -0700 (PDT)
In-Reply-To: <CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
Date: Thu, 7 Jun 2012 14:14:41 +0100
X-Google-Sender-Auth: fKAPQrfr9wpw1pt8PgqIuuQc40U
Message-ID: <CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Cc: Rolu <rolu@roce.org>, xen-users@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 10:24 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrot=
e:
> Rolu,
>
> thanks for the feedback.
>
>
>> xen" and "help with xcp" it would be nice if there were a few lines at
>> the top of the page explaining which is which, so (new) people can
>> have a better idea of where to look.
>
>
> So you mean a link to Xen and XCP from the headline, or a tagline describ=
ing
> what Xen/XCP is? Two lines are probably OK; more would probably break up =
the
> navigation too much.
>
>>
>> The descriptions from
>> http://xen.org/products/ and a link to
>> http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
>> The latter is already linked in the "getting started with xen" column
>> but would be better off at the top since it gives a feature table of
>> both.
>
> I am wondering whether Xen Features / XCP Features in one of the boxes wo=
uld
> not be better.
>
>>
>> As someone who started with Xen not long ago, I much prefer dedicated
>> link pages over Category: pages. The latter just give a big unsorted
>> (alphabetical doesn't count, needs to be sorted by subtopic to be a
>> useful sort) list of pages of widely varying scope and usefulness.
>> It's better than nothing, sure, but a page that sorts them by topic or
>> purpose or something (much like this proposed front page really) is a
>> lot better.
>
> How about a compromise? Category pages have two parts:
> 1) A fixed part that can be used for any content, such as lists of import=
ant
> articles by topic or other ciriteria
> =A0=A0=A0 An example of this is http://wiki.xen.org/wiki/Category:Host_In=
stall
> (and some of the pages linked from it)
> 2) The auto-generated index
>
> I know that some people are don't like category pages. However, until
> somebody steps up and provides an alternative, which to do well requires
> a) Classifying articles
> b) Grouping them by topic or purpose
> c) Encoding that grouping in some manual index
> d) Keeping these up-to-date
>
> ... the category pages are all we have and are a lot better than what we =
had
> in the old wiki. And they are self-maintaining.

Sorry to throw in a criticism without a constructive solution, but I
just want to register one opinion: To me clicking on a link and seeing
a "Category" page says very strongly, "I couldn't be bothered to
actually do any work here; I'll leave you to do all the work to figure
out what page you need."  When I encounter a Category page on my walk
through the Xen wiki, I don't even look, but immediately turn to
Google.  I think a page which is has some kind of logical flow to it
but perhaps a little out-dated is much better than a page which just
tosses up a bunch of titles in no order and lets you figure it out.

I can certainly see that there were "liveness" problems with summary
pages; but I don't think that the Categories pages, as we have now,
really help that much.

> The fact that we are having this discussion is actually good. I am open to
> suggestions and maybe we just need a small number of manually maintained
> indexes (or categories with maintained content at the top). Maybe to make
> this really work and get better navigability we need some degree of
> ownership in the wiki: i.e. community members owning content, categories,
> etc. and being responsible for classifying, grouping and making it more
> accessible.

I think in an ideal world, we'd have people who were "maintainers" of
the wiki just like there are maintainers of different subsections of
the codebase.  Until that time, could we maybe draw up a set of
"tests" to run on the docs, which can be assigned to people on DocDay?
 One simple thing could be, "Make sure X page is up-to-date" (which
may include, "Look at the Category: page and make sure everything
there is listed somewhere on the manually-generated page"); another
could be a scenario, "Pretend you're a [foo] and you want to know
[bar].  Start at the top level page and make sure you can find all the
information you need."  If each "test" was something any motivated
developer/community member could do, and only took 5-10 minutes, it
should be pretty sustainable.  What do you think?

One thing that might make the Category: page more useful is if we
could include "index tags" on articles, and then sort the Category:
pages by those tags instead of by title.  But I'm not sure how easy
that is to do with the current wiki.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:15:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SccY3-0001KJ-Eu; Thu, 07 Jun 2012 13:14:47 +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 1SccY2-0001Jy-0g
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:14:46 +0000
Received: from [85.158.139.83:15513] by server-6.bemta-5.messagelabs.com id
	26/2A-18700-449A0DF4; Thu, 07 Jun 2012 13:14:44 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339074882!28190265!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6687 invoked from network); 7 Jun 2012 13:14:43 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:14:43 -0000
Received: by qaeb19 with SMTP id b19so122644qae.11
	for <multiple recipients>; Thu, 07 Jun 2012 06:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=e9TSWflGY7t9BEJAN1WDekuzfXqvwYy2apIGRWkLddQ=;
	b=PUE1se8v0Ch8Lr60prDEsDQ3ygVUo6oFT4FaMAx7mDiWTCvx+Z5+N9n9Iwnh8sC2ZG
	8WKNiPe3ZmKMKjak7ovEnU1+XydhO/2Ic0FObURDN60OxlpFkNrAAju1IOCqmRc8D6ea
	YnAuMq7d2FINuuOQvjrABQMW8zHP4x+ntEzeFVetOkbJPyvKScOkutWBrRNDljbZLcDy
	yMtCr8I4Oc2+KSU8RqkoFwJdYokcuEjpeKr/tPwCG0hPmZdmjX53AxideGmTWROGiLRW
	3TM51Xbou3qQgzaXdBK3TfmTKsxJG0wRrRvBFigYRtauD8eL8YymahcnExdu7TQCFM+m
	JxHQ==
MIME-Version: 1.0
Received: by 10.224.206.198 with SMTP id fv6mr2775401qab.6.1339074881893; Thu,
	07 Jun 2012 06:14:41 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 7 Jun 2012 06:14:41 -0700 (PDT)
In-Reply-To: <CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
Date: Thu, 7 Jun 2012 14:14:41 +0100
X-Google-Sender-Auth: fKAPQrfr9wpw1pt8PgqIuuQc40U
Message-ID: <CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Cc: Rolu <rolu@roce.org>, xen-users@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 10:24 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrot=
e:
> Rolu,
>
> thanks for the feedback.
>
>
>> xen" and "help with xcp" it would be nice if there were a few lines at
>> the top of the page explaining which is which, so (new) people can
>> have a better idea of where to look.
>
>
> So you mean a link to Xen and XCP from the headline, or a tagline describ=
ing
> what Xen/XCP is? Two lines are probably OK; more would probably break up =
the
> navigation too much.
>
>>
>> The descriptions from
>> http://xen.org/products/ and a link to
>> http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview would work.
>> The latter is already linked in the "getting started with xen" column
>> but would be better off at the top since it gives a feature table of
>> both.
>
> I am wondering whether Xen Features / XCP Features in one of the boxes wo=
uld
> not be better.
>
>>
>> As someone who started with Xen not long ago, I much prefer dedicated
>> link pages over Category: pages. The latter just give a big unsorted
>> (alphabetical doesn't count, needs to be sorted by subtopic to be a
>> useful sort) list of pages of widely varying scope and usefulness.
>> It's better than nothing, sure, but a page that sorts them by topic or
>> purpose or something (much like this proposed front page really) is a
>> lot better.
>
> How about a compromise? Category pages have two parts:
> 1) A fixed part that can be used for any content, such as lists of import=
ant
> articles by topic or other ciriteria
> =A0=A0=A0 An example of this is http://wiki.xen.org/wiki/Category:Host_In=
stall
> (and some of the pages linked from it)
> 2) The auto-generated index
>
> I know that some people are don't like category pages. However, until
> somebody steps up and provides an alternative, which to do well requires
> a) Classifying articles
> b) Grouping them by topic or purpose
> c) Encoding that grouping in some manual index
> d) Keeping these up-to-date
>
> ... the category pages are all we have and are a lot better than what we =
had
> in the old wiki. And they are self-maintaining.

Sorry to throw in a criticism without a constructive solution, but I
just want to register one opinion: To me clicking on a link and seeing
a "Category" page says very strongly, "I couldn't be bothered to
actually do any work here; I'll leave you to do all the work to figure
out what page you need."  When I encounter a Category page on my walk
through the Xen wiki, I don't even look, but immediately turn to
Google.  I think a page which is has some kind of logical flow to it
but perhaps a little out-dated is much better than a page which just
tosses up a bunch of titles in no order and lets you figure it out.

I can certainly see that there were "liveness" problems with summary
pages; but I don't think that the Categories pages, as we have now,
really help that much.

> The fact that we are having this discussion is actually good. I am open to
> suggestions and maybe we just need a small number of manually maintained
> indexes (or categories with maintained content at the top). Maybe to make
> this really work and get better navigability we need some degree of
> ownership in the wiki: i.e. community members owning content, categories,
> etc. and being responsible for classifying, grouping and making it more
> accessible.

I think in an ideal world, we'd have people who were "maintainers" of
the wiki just like there are maintainers of different subsections of
the codebase.  Until that time, could we maybe draw up a set of
"tests" to run on the docs, which can be assigned to people on DocDay?
 One simple thing could be, "Make sure X page is up-to-date" (which
may include, "Look at the Category: page and make sure everything
there is listed somewhere on the manually-generated page"); another
could be a scenario, "Pretend you're a [foo] and you want to know
[bar].  Start at the top level page and make sure you can find all the
information you need."  If each "test" was something any motivated
developer/community member could do, and only took 5-10 minutes, it
should be pretty sustainable.  What do you think?

One thing that might make the Category: page more useful is if we
could include "index tags" on articles, and then sort the Category:
pages by those tags instead of by title.  But I'm not sure how easy
that is to do with the current wiki.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1Sccml-0002FK-Bk; Thu, 07 Jun 2012 13:29:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Borislav.Petkov@amd.com>) id 1Sccmk-0002FF-2A
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 13:29:58 +0000
Received: from [85.158.139.83:26582] by server-12.bemta-5.messagelabs.com id
	3F/DA-18374-5DCA0DF4; Thu, 07 Jun 2012 13:29:57 +0000
X-Env-Sender: Borislav.Petkov@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339075795!18624728!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32415 invoked from network); 7 Jun 2012 13:29:56 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Jun 2012 13:29:56 -0000
Received: from mail57-tx2-R.bigfish.com (10.9.14.240) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 13:24:03 +0000
Received: from mail57-tx2 (localhost [127.0.0.1])	by mail57-tx2-R.bigfish.com
	(Postfix) with ESMTP id D98233E0275;
	Thu,  7 Jun 2012 13:24:02 +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: VPS-1(zz936eIzz1202hzz8275bh8275dhz2dh668h839h944hd25hf0ah)
Received: from mail57-tx2 (localhost.localdomain [127.0.0.1]) by mail57-tx2
	(MessageSwitch) id 1339075440566334_2040;
	Thu,  7 Jun 2012 13:24:00 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.242])	by
	mail57-tx2.bigfish.com (Postfix) with ESMTP id 7B0468021C;
	Thu,  7 Jun 2012 13:24:00 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 13:23:58 +0000
X-WSS-ID: 0M59195-02-6F8-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 210A0C8196;	Thu,  7 Jun 2012 08:24:41 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 7 Jun 2012 08:24:58 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 7 Jun 2012 08:24:41 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	09:24:41 -0400
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3237949C69F; Thu,  7 Jun 2012
	14:24:40 +0100 (BST)
Date: Thu, 7 Jun 2012 15:25:05 +0200
From: Borislav Petkov <borislav.petkov@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120607132505.GG11153@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com> <4FD05CED.60905@amd.com>
	<20120607080833.GA23186@kroah.com> <4FD063F0.3060301@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD063F0.3060301@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [GIT PULL] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Peter,

so here are the final versions of the patches, as discussed. 3/4 has
lost the stable tag and all have received Konrad's Acked-by. Other than
that, 1ab46fd319bc takes care of the -stable issue for xen and Greg is
picking that one up. So all those should be queued for 3.6.

Please pull, thanks.

The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f:

  Linux 3.5-rc1 (2012-06-02 18:29:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/amd-rdmsr-cleanups-for-3.6

for you to fetch changes up to c5214c0192813ebaa5784be36d2ae142034f84db:

  x86, CPU, AMD: Deprecate AMD-specific MSR variants (2012-06-07 12:52:58 +0200)

----------------------------------------------------------------
x86, CPU, AMD: Cleanup AMD-specific MSR-rw users

This patchset takes care of all the {rd,wr}msrl_amd_safe headaches we
had wrt xen. After it is applied, the AMD-specific variants become
private to amd.c and issue a warning when used on anything else beside
K8 because they're supposed to be used only on K8.

This also contains the two patches from Andre which cleanup the PV-side
of things.

----------------------------------------------------------------
Andre Przywara (2):
      x86, pvops: Remove hooks for {rd,wr}msr_safe_regs
      x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems

Borislav Petkov (2):
      x86, CPU: Fix show_msr MSR accessing function
      x86, CPU, AMD: Deprecate AMD-specific MSR variants

 arch/x86/include/asm/msr.h            | 42 ++---------------------------------
 arch/x86/include/asm/paravirt.h       | 39 --------------------------------
 arch/x86/include/asm/paravirt_types.h |  2 --
 arch/x86/kernel/cpu/amd.c             | 37 ++++++++++++++++++++++++++++--
 arch/x86/kernel/cpu/common.c          |  2 +-
 arch/x86/kernel/paravirt.c            |  2 --
 arch/x86/lib/msr-reg-export.c         |  4 ++--
 arch/x86/lib/msr-reg.S                | 10 ++++-----
 arch/x86/xen/enlighten.c              |  2 --
 9 files changed, 45 insertions(+), 95 deletions(-)

-- 
Regards/Gruss,
Boris.

osrc-kernel@elbe.amd.com - where all your Linux questions get answered.

Operating Systems Research Center
Advanced Micro Devices, Inc.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1Sccml-0002FK-Bk; Thu, 07 Jun 2012 13:29:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Borislav.Petkov@amd.com>) id 1Sccmk-0002FF-2A
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 13:29:58 +0000
Received: from [85.158.139.83:26582] by server-12.bemta-5.messagelabs.com id
	3F/DA-18374-5DCA0DF4; Thu, 07 Jun 2012 13:29:57 +0000
X-Env-Sender: Borislav.Petkov@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339075795!18624728!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32415 invoked from network); 7 Jun 2012 13:29:56 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Jun 2012 13:29:56 -0000
Received: from mail57-tx2-R.bigfish.com (10.9.14.240) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 13:24:03 +0000
Received: from mail57-tx2 (localhost [127.0.0.1])	by mail57-tx2-R.bigfish.com
	(Postfix) with ESMTP id D98233E0275;
	Thu,  7 Jun 2012 13:24:02 +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: VPS-1(zz936eIzz1202hzz8275bh8275dhz2dh668h839h944hd25hf0ah)
Received: from mail57-tx2 (localhost.localdomain [127.0.0.1]) by mail57-tx2
	(MessageSwitch) id 1339075440566334_2040;
	Thu,  7 Jun 2012 13:24:00 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.242])	by
	mail57-tx2.bigfish.com (Postfix) with ESMTP id 7B0468021C;
	Thu,  7 Jun 2012 13:24:00 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id
	14.1.225.23; Thu, 7 Jun 2012 13:23:58 +0000
X-WSS-ID: 0M59195-02-6F8-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 210A0C8196;	Thu,  7 Jun 2012 08:24:41 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 7 Jun 2012 08:24:58 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 7 Jun 2012 08:24:41 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	09:24:41 -0400
Received: from aftab.osrc.amd.com (aftab.osrc.amd.com [165.204.15.109])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3237949C69F; Thu,  7 Jun 2012
	14:24:40 +0100 (BST)
Date: Thu, 7 Jun 2012 15:25:05 +0200
From: Borislav Petkov <borislav.petkov@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120607132505.GG11153@aftab.osrc.amd.com>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com> <4FD05CED.60905@amd.com>
	<20120607080833.GA23186@kroah.com> <4FD063F0.3060301@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD063F0.3060301@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>,
	LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: [Xen-devel] [GIT PULL] x86, CPU,
	AMD: Cleanup AMD-specific MSR-rw users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Peter,

so here are the final versions of the patches, as discussed. 3/4 has
lost the stable tag and all have received Konrad's Acked-by. Other than
that, 1ab46fd319bc takes care of the -stable issue for xen and Greg is
picking that one up. So all those should be queued for 3.6.

Please pull, thanks.

The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f:

  Linux 3.5-rc1 (2012-06-02 18:29:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/amd-rdmsr-cleanups-for-3.6

for you to fetch changes up to c5214c0192813ebaa5784be36d2ae142034f84db:

  x86, CPU, AMD: Deprecate AMD-specific MSR variants (2012-06-07 12:52:58 +0200)

----------------------------------------------------------------
x86, CPU, AMD: Cleanup AMD-specific MSR-rw users

This patchset takes care of all the {rd,wr}msrl_amd_safe headaches we
had wrt xen. After it is applied, the AMD-specific variants become
private to amd.c and issue a warning when used on anything else beside
K8 because they're supposed to be used only on K8.

This also contains the two patches from Andre which cleanup the PV-side
of things.

----------------------------------------------------------------
Andre Przywara (2):
      x86, pvops: Remove hooks for {rd,wr}msr_safe_regs
      x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems

Borislav Petkov (2):
      x86, CPU: Fix show_msr MSR accessing function
      x86, CPU, AMD: Deprecate AMD-specific MSR variants

 arch/x86/include/asm/msr.h            | 42 ++---------------------------------
 arch/x86/include/asm/paravirt.h       | 39 --------------------------------
 arch/x86/include/asm/paravirt_types.h |  2 --
 arch/x86/kernel/cpu/amd.c             | 37 ++++++++++++++++++++++++++++--
 arch/x86/kernel/cpu/common.c          |  2 +-
 arch/x86/kernel/paravirt.c            |  2 --
 arch/x86/lib/msr-reg-export.c         |  4 ++--
 arch/x86/lib/msr-reg.S                | 10 ++++-----
 arch/x86/xen/enlighten.c              |  2 --
 9 files changed, 45 insertions(+), 95 deletions(-)

-- 
Regards/Gruss,
Boris.

osrc-kernel@elbe.amd.com - where all your Linux questions get answered.

Operating Systems Research Center
Advanced Micro Devices, Inc.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sccmx-0002Fs-O2; Thu, 07 Jun 2012 13:30:11 +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 1Sccmv-0002Fk-W9
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 13:30:10 +0000
Received: from [193.109.254.147:35373] by server-12.bemta-14.messagelabs.com
	id 45/9C-12998-1ECA0DF4; Thu, 07 Jun 2012 13:30:09 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339075807!8563204!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1815 invoked from network); 7 Jun 2012 13:30:07 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:30:07 -0000
Received: by lahg1 with SMTP id g1so529072lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 06:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=xw5qWuzEwBB4UaIFSh4Jgwecv+yQxVjIHD9NYVZgXmo=;
	b=staJSwLXkm3R4MjSow8BOLQVbixjOH/RqQqAIkBMneHb+I83dfT9yN2iOQ8i+8eIOY
	GE0tYpxxf3RK6+GoGisDibU1PPXCcwmyYdFOQ6+rrzTLki2dwOeJIADA8WeJUNvAkUDa
	iT1e44Zgk4m+WKpgWVMTB2oa6oZbvG0GHSARsYh8/gHdDBUwzO+9vMUkVNALFQY71FUo
	DSpkJEvgspIKBfAzxKQK6Qsu3HcFsdYFNdXld7JN83UZeKnZl4e8rnBUlR3nP9OX6dNA
	we/DmJayPNO3JIJ210o/nzX9xJhjt9Nd/bHzOE55WNV5m88NAAZwAj8MTXSOAMa7cVRF
	LNyg==
MIME-Version: 1.0
Received: by 10.152.111.200 with SMTP id ik8mr2524420lab.15.1339075806799;
	Thu, 07 Jun 2012 06:30:06 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 06:30:06 -0700 (PDT)
Date: Thu, 7 Jun 2012 09:30:06 -0400
X-Google-Sender-Auth: xoE1xK8Qiw78BoYWwKWIJbGD8bg
Message-ID: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix the polling section of the hvc driver to use the global "last_hvc"
variable, rather than the ttys.

With this change debugging a xen dom0 kernel is possible via the
following kernel parameter:
kgdboc=hvc0

Signed-off-by: Ben Guthro <Benjamin.Guthro@citrix.com>


diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 2d691eb..3750e74 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -766,12 +766,10 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)

 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
-       struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
        int n;
        char ch;

-       n = hp->ops->get_chars(hp->vtermno, &ch, 1);
+       n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);

        if (n == 0)
                return NO_POLL_CHAR;
@@ -781,12 +779,10 @@ static int hvc_poll_get_char(struct tty_driver
*driver, int line)

 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
-       struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
        int n;

        do {
-               n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+               n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
        } while (n <= 0);
 }
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sccmx-0002Fs-O2; Thu, 07 Jun 2012 13:30:11 +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 1Sccmv-0002Fk-W9
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 13:30:10 +0000
Received: from [193.109.254.147:35373] by server-12.bemta-14.messagelabs.com
	id 45/9C-12998-1ECA0DF4; Thu, 07 Jun 2012 13:30:09 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339075807!8563204!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1815 invoked from network); 7 Jun 2012 13:30:07 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:30:07 -0000
Received: by lahg1 with SMTP id g1so529072lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 06:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=xw5qWuzEwBB4UaIFSh4Jgwecv+yQxVjIHD9NYVZgXmo=;
	b=staJSwLXkm3R4MjSow8BOLQVbixjOH/RqQqAIkBMneHb+I83dfT9yN2iOQ8i+8eIOY
	GE0tYpxxf3RK6+GoGisDibU1PPXCcwmyYdFOQ6+rrzTLki2dwOeJIADA8WeJUNvAkUDa
	iT1e44Zgk4m+WKpgWVMTB2oa6oZbvG0GHSARsYh8/gHdDBUwzO+9vMUkVNALFQY71FUo
	DSpkJEvgspIKBfAzxKQK6Qsu3HcFsdYFNdXld7JN83UZeKnZl4e8rnBUlR3nP9OX6dNA
	we/DmJayPNO3JIJ210o/nzX9xJhjt9Nd/bHzOE55WNV5m88NAAZwAj8MTXSOAMa7cVRF
	LNyg==
MIME-Version: 1.0
Received: by 10.152.111.200 with SMTP id ik8mr2524420lab.15.1339075806799;
	Thu, 07 Jun 2012 06:30:06 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 06:30:06 -0700 (PDT)
Date: Thu, 7 Jun 2012 09:30:06 -0400
X-Google-Sender-Auth: xoE1xK8Qiw78BoYWwKWIJbGD8bg
Message-ID: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix the polling section of the hvc driver to use the global "last_hvc"
variable, rather than the ttys.

With this change debugging a xen dom0 kernel is possible via the
following kernel parameter:
kgdboc=hvc0

Signed-off-by: Ben Guthro <Benjamin.Guthro@citrix.com>


diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 2d691eb..3750e74 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -766,12 +766,10 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)

 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
-       struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
        int n;
        char ch;

-       n = hp->ops->get_chars(hp->vtermno, &ch, 1);
+       n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);

        if (n == 0)
                return NO_POLL_CHAR;
@@ -781,12 +779,10 @@ static int hvc_poll_get_char(struct tty_driver
*driver, int line)

 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
-       struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
        int n;

        do {
-               n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+               n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
        } while (n <= 0);
 }
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:50:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1Scd6k-0002je-WB; Thu, 07 Jun 2012 13:50:38 +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 1Scd6j-0002jT-9B
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:50:37 +0000
Received: from [85.158.139.83:2229] by server-11.bemta-5.messagelabs.com id
	E1/B5-25194-CA1B0DF4; Thu, 07 Jun 2012 13:50:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339077035!25244416!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7813 invoked from network); 7 Jun 2012 13:50:35 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:50:35 -0000
Received: by wibhr14 with SMTP id hr14so196086wib.14
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:50:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=2FxVrs7fLo67s7DEXKhE2IyLg+Ovj7uAfI6LmyKRI+o=;
	b=LdAuBJWXc92pomUuvAvEM+g0m8ymK4UQpvYAbXtaFfyGCfIfg4jTVi9xS6SGkxa1Gr
	1GylX9vd05CcNMTLrh7KVPHmHv6CwojvD0ebmlJc08V1w4H9nQYUne3SatHnWXwh1ubs
	+N9Ma0GAGQ75LpttbV9YggZLmA7JuWqatJfqRbJ4HpQry1siDjTA+b01qhbIvEjMGw2x
	IqtkLRs1obNUuXZ+QqLG2VkjvyUj/xuSEMyVdkg/pNSq1Qn0fbgvwgIOVKUFsInLTq95
	K4BynKBMUNx40/q0dSzq1W3zT6gE1A0pZX+iD6jbMAJyvKTFXhaaEwWyNs1HQ5LPcsKl
	+8GA==
Received: by 10.216.194.139 with SMTP id m11mr961544wen.198.1339077034850;
	Thu, 07 Jun 2012 06:50:34 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id k8sm2040100wia.6.2012.06.07.06.50.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 06:50:33 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 93ff3e5ecdee68b4f949f411922d3e03d529a618
Message-Id: <93ff3e5ecdee68b4f949.1339076552@Solace>
In-Reply-To: <patchbomb.1339076551@Solace>
References: <patchbomb.1339076551@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 07 Jun 2012 15:42:32 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2 v2] libxl: propagete down the error from
 libxl_domain_sched_params_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

So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
@@ -175,7 +175,8 @@ int libxl__build_post(libxl__gc *gc, uin
     char **ents, **hvm_ents;
     int i;
 
-    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
+    if (libxl_domain_sched_params_set(CTX, domid, &info->sched_params))
+        return ERROR_INVAL;
 
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:50:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1Scd6k-0002je-WB; Thu, 07 Jun 2012 13:50:38 +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 1Scd6j-0002jT-9B
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:50:37 +0000
Received: from [85.158.139.83:2229] by server-11.bemta-5.messagelabs.com id
	E1/B5-25194-CA1B0DF4; Thu, 07 Jun 2012 13:50:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339077035!25244416!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7813 invoked from network); 7 Jun 2012 13:50:35 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:50:35 -0000
Received: by wibhr14 with SMTP id hr14so196086wib.14
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:50:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=2FxVrs7fLo67s7DEXKhE2IyLg+Ovj7uAfI6LmyKRI+o=;
	b=LdAuBJWXc92pomUuvAvEM+g0m8ymK4UQpvYAbXtaFfyGCfIfg4jTVi9xS6SGkxa1Gr
	1GylX9vd05CcNMTLrh7KVPHmHv6CwojvD0ebmlJc08V1w4H9nQYUne3SatHnWXwh1ubs
	+N9Ma0GAGQ75LpttbV9YggZLmA7JuWqatJfqRbJ4HpQry1siDjTA+b01qhbIvEjMGw2x
	IqtkLRs1obNUuXZ+QqLG2VkjvyUj/xuSEMyVdkg/pNSq1Qn0fbgvwgIOVKUFsInLTq95
	K4BynKBMUNx40/q0dSzq1W3zT6gE1A0pZX+iD6jbMAJyvKTFXhaaEwWyNs1HQ5LPcsKl
	+8GA==
Received: by 10.216.194.139 with SMTP id m11mr961544wen.198.1339077034850;
	Thu, 07 Jun 2012 06:50:34 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id k8sm2040100wia.6.2012.06.07.06.50.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 06:50:33 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 93ff3e5ecdee68b4f949f411922d3e03d529a618
Message-Id: <93ff3e5ecdee68b4f949.1339076552@Solace>
In-Reply-To: <patchbomb.1339076551@Solace>
References: <patchbomb.1339076551@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 07 Jun 2012 15:42:32 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2 v2] libxl: propagete down the error from
 libxl_domain_sched_params_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

So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
@@ -175,7 +175,8 @@ int libxl__build_post(libxl__gc *gc, uin
     char **ents, **hvm_ents;
     int i;
 
-    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
+    if (libxl_domain_sched_params_set(CTX, domid, &info->sched_params))
+        return ERROR_INVAL;
 
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scd6m-0002ju-C6; Thu, 07 Jun 2012 13:50:40 +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 1Scd6l-0002jd-5h
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:50:39 +0000
Received: from [85.158.139.83:2443] by server-8.bemta-5.messagelabs.com id
	84/2E-02058-EA1B0DF4; Thu, 07 Jun 2012 13:50:38 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339077035!25244416!2
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7945 invoked from network); 7 Jun 2012 13:50:37 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:50:37 -0000
Received: by mail-wi0-f179.google.com with SMTP id hr14so196086wib.14
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=tSukAjm1YZ10l3WGIL04wrVi7STs9m/4fPYNeGmRJJ8=;
	b=kxCuDn+fE+DJc73lKqCdX+/WXmBfaFVYwSXxrk5mZ/nCKW/Qm+c6O61Xa9r54Zow0R
	ebXymUOTA+Y6yzgpg2MuWCUbotBT9ig/xZcsUk1TKdlGrmOtx3PPnPEDA+QnwzcCeFVk
	mq98xRFYy5gXuG6KxmT22eLL0XiSgcQbn9PogS2H9oq012J6erBFONE408iVbfdkepm5
	QGfrDj3zzV0gXYb/KvSbee0/Y1xW1sceY0K2jQItjkY07PV6y8WCe97fAE9B6LQ/TDqd
	bTaA5+Y6ROpKgcbOYhhSk5jGewWMyTYholNTj35+ADI7/Xnfo/jtVHjZOE10IKFatHrd
	/hZg==
Received: by 10.216.143.206 with SMTP id l56mr961019wej.15.1339077037181;
	Thu, 07 Jun 2012 06:50:37 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id k8sm2040100wia.6.2012.06.07.06.50.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 06:50:35 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2a35be0bef3f16b8f1366d0f613cfa6c2f9e4e3a
Message-Id: <2a35be0bef3f16b8f136.1339076553@Solace>
In-Reply-To: <patchbomb.1339076551@Solace>
References: <patchbomb.1339076551@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 07 Jun 2012 15:42:33 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2 v2] xl: check for meaningful combination
 of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it happens in the implementation of `xl sched-sedf -d ...', some
consistency checking is needed for the scheduling parameters when
they come from the config file.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -550,6 +550,31 @@ vcpp_out:
     return rc;
 }
 
+static int sched_params_valid(libxl_domain_sched_params *scp)
+{
+    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
+    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
+    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    libxl_domain_sched_params sci;
+
+    libxl_domain_sched_params_get(ctx, domid, &sci);
+
+    /* The sedf scheduler needs some more consistency checking */
+    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+        if (has_weight && (has_period || has_slice))
+            return 0;
+
+        if (has_weight) {
+            scp->slice = 0;
+            scp->period = 0;
+        }
+        if (has_period || has_slice)
+            scp->weight = 0;
+    }
+
+    return 1;
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -644,6 +669,10 @@ static void parse_config_data(const char
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
+    if (!sched_params_valid(&b_info->sched_params)) {
+        fprintf(stderr, "Invalid scheduling parameters\n");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scd6m-0002ju-C6; Thu, 07 Jun 2012 13:50:40 +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 1Scd6l-0002jd-5h
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:50:39 +0000
Received: from [85.158.139.83:2443] by server-8.bemta-5.messagelabs.com id
	84/2E-02058-EA1B0DF4; Thu, 07 Jun 2012 13:50:38 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339077035!25244416!2
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7945 invoked from network); 7 Jun 2012 13:50:37 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:50:37 -0000
Received: by mail-wi0-f179.google.com with SMTP id hr14so196086wib.14
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=tSukAjm1YZ10l3WGIL04wrVi7STs9m/4fPYNeGmRJJ8=;
	b=kxCuDn+fE+DJc73lKqCdX+/WXmBfaFVYwSXxrk5mZ/nCKW/Qm+c6O61Xa9r54Zow0R
	ebXymUOTA+Y6yzgpg2MuWCUbotBT9ig/xZcsUk1TKdlGrmOtx3PPnPEDA+QnwzcCeFVk
	mq98xRFYy5gXuG6KxmT22eLL0XiSgcQbn9PogS2H9oq012J6erBFONE408iVbfdkepm5
	QGfrDj3zzV0gXYb/KvSbee0/Y1xW1sceY0K2jQItjkY07PV6y8WCe97fAE9B6LQ/TDqd
	bTaA5+Y6ROpKgcbOYhhSk5jGewWMyTYholNTj35+ADI7/Xnfo/jtVHjZOE10IKFatHrd
	/hZg==
Received: by 10.216.143.206 with SMTP id l56mr961019wej.15.1339077037181;
	Thu, 07 Jun 2012 06:50:37 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id k8sm2040100wia.6.2012.06.07.06.50.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 06:50:35 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 2a35be0bef3f16b8f1366d0f613cfa6c2f9e4e3a
Message-Id: <2a35be0bef3f16b8f136.1339076553@Solace>
In-Reply-To: <patchbomb.1339076551@Solace>
References: <patchbomb.1339076551@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 07 Jun 2012 15:42:33 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2 v2] xl: check for meaningful combination
 of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it happens in the implementation of `xl sched-sedf -d ...', some
consistency checking is needed for the scheduling parameters when
they come from the config file.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -550,6 +550,31 @@ vcpp_out:
     return rc;
 }
 
+static int sched_params_valid(libxl_domain_sched_params *scp)
+{
+    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
+    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
+    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    libxl_domain_sched_params sci;
+
+    libxl_domain_sched_params_get(ctx, domid, &sci);
+
+    /* The sedf scheduler needs some more consistency checking */
+    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+        if (has_weight && (has_period || has_slice))
+            return 0;
+
+        if (has_weight) {
+            scp->slice = 0;
+            scp->period = 0;
+        }
+        if (has_period || has_slice)
+            scp->weight = 0;
+    }
+
+    return 1;
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -644,6 +669,10 @@ static void parse_config_data(const char
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
+    if (!sched_params_valid(&b_info->sched_params)) {
+        fprintf(stderr, "Invalid scheduling parameters\n");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scd6h-0002jM-KT; Thu, 07 Jun 2012 13:50:35 +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 1Scd6g-0002jH-Tn
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:50:35 +0000
Received: from [85.158.138.51:42519] by server-3.bemta-3.messagelabs.com id
	F9/17-25608-AA1B0DF4; Thu, 07 Jun 2012 13:50:34 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339077033!27233598!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12434 invoked from network); 7 Jun 2012 13:50:33 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:50:33 -0000
Received: by werf3 with SMTP id f3so469605wer.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=rdrEOhcKbRku+W5NlADfNq3iX3Qpegz/Ww0nOkS2VGY=;
	b=Vs5/5fOjFjzXJmdlaxEmAk0aryeC4YIM/4EX89oYECP9oeIuTmLHocgMPLgdGS0Hx9
	8tayPT0ln+Btn/LZ/NfuaaQzocQVPkYV0nxTyBA6xraG8BvbMZANPnLuXqyq1N1JyQgu
	OGchfB5yLZ4JWbS4rWqKQIi+Oleswa/IZnhoSlGoX7S7mH19i+Dzv821MAo8sk/Bbqa9
	qcDlvBTJ21DeC/XhAPwpcsVbtPYYQdWyqW1Nc9PkKaw7+V3H2YLHkCjQT6i77Z3zSjiI
	tcH1uq/GsvFsuh0LRuXI7NGqn8IEVAkGwJIzQ3lIY5K3FY6gaY8C2ATpcQmIf859m7LZ
	7VcQ==
Received: by 10.216.194.93 with SMTP id l71mr969723wen.169.1339077032815;
	Thu, 07 Jun 2012 06:50:32 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id k8sm2040100wia.6.2012.06.07.06.50.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 06:50:31 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1339076551@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 07 Jun 2012 15:42:31 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 2 v2] Sanity checking of scheduling
	parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This small series achieves two goals:
 - check the return value of libxl_domain_sched_params_set() in
   libxl__build_post() and deal with the error, if that is the
   case (patch #1);
 - check and ensue we are passing along a meaningful set of sedf
   scheduling parameters when they come directly from the config file
   (patch #2)

Tested on both credit and sedf schedulers.

Changes from v1:
 * patch #1: it was not there at all in v1! :-P
 * patch #2: the if-s have been moved into an helper function. Also,
   they only happen if the domain is actually being scheduled with
   sedf (IanC, yes, I decided to do it... At the end of the day, it is
   simple enough I think).


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 Thu Jun 07 13:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scd6h-0002jM-KT; Thu, 07 Jun 2012 13:50:35 +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 1Scd6g-0002jH-Tn
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:50:35 +0000
Received: from [85.158.138.51:42519] by server-3.bemta-3.messagelabs.com id
	F9/17-25608-AA1B0DF4; Thu, 07 Jun 2012 13:50:34 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339077033!27233598!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12434 invoked from network); 7 Jun 2012 13:50:33 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:50:33 -0000
Received: by werf3 with SMTP id f3so469605wer.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=rdrEOhcKbRku+W5NlADfNq3iX3Qpegz/Ww0nOkS2VGY=;
	b=Vs5/5fOjFjzXJmdlaxEmAk0aryeC4YIM/4EX89oYECP9oeIuTmLHocgMPLgdGS0Hx9
	8tayPT0ln+Btn/LZ/NfuaaQzocQVPkYV0nxTyBA6xraG8BvbMZANPnLuXqyq1N1JyQgu
	OGchfB5yLZ4JWbS4rWqKQIi+Oleswa/IZnhoSlGoX7S7mH19i+Dzv821MAo8sk/Bbqa9
	qcDlvBTJ21DeC/XhAPwpcsVbtPYYQdWyqW1Nc9PkKaw7+V3H2YLHkCjQT6i77Z3zSjiI
	tcH1uq/GsvFsuh0LRuXI7NGqn8IEVAkGwJIzQ3lIY5K3FY6gaY8C2ATpcQmIf859m7LZ
	7VcQ==
Received: by 10.216.194.93 with SMTP id l71mr969723wen.169.1339077032815;
	Thu, 07 Jun 2012 06:50:32 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id k8sm2040100wia.6.2012.06.07.06.50.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 06:50:31 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1339076551@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 07 Jun 2012 15:42:31 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 2 v2] Sanity checking of scheduling
	parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This small series achieves two goals:
 - check the return value of libxl_domain_sched_params_set() in
   libxl__build_post() and deal with the error, if that is the
   case (patch #1);
 - check and ensue we are passing along a meaningful set of sedf
   scheduling parameters when they come directly from the config file
   (patch #2)

Tested on both credit and sedf schedulers.

Changes from v1:
 * patch #1: it was not there at all in v1! :-P
 * patch #2: the if-s have been moved into an helper function. Also,
   they only happen if the domain is actually being scheduled with
   sedf (IanC, yes, I decided to do it... At the end of the day, it is
   simple enough I think).


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 Thu Jun 07 13:52:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1Scd8B-0002v4-Rt; Thu, 07 Jun 2012 13:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jintonglei@gmail.com>) id 1Scd89-0002uo-MO
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:52:05 +0000
Received: from [85.158.138.51:3285] by server-11.bemta-3.messagelabs.com id
	14/C2-28329-402B0DF4; Thu, 07 Jun 2012 13:52:04 +0000
X-Env-Sender: jintonglei@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339077122!31359643!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24115 invoked from network); 7 Jun 2012 13:52:04 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:52:04 -0000
Received: by dadv2 with SMTP id v2so994676dad.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version
	:content-type:content-transfer-encoding;
	bh=syG3rozU2Tiqs7JEDeqtgg+3C8NEMv6bOCAlO4vTJsc=;
	b=S3Yl/9qYsf36fQiUtoguRF6nkva0TcIZNRwANUj127J3eDtf1HXqjWfguIaPhcmfWt
	38aKSGBi4DELrbff3AkfcL4HBUtbmgC+Z80qD2FuqGNXGGppp8+VvMtJymfLBij3kVt0
	kuNO1lb49LVhTYOn2PRZvdPSAyl9tGrc9DU5dClANr7w56MAYz0lJRKmeC76QlPnEs+q
	FFQoSd6vuq8uFVb3UDVS9IDQAmBvhox3+lAk7xhb9DsiTO1BUIDAvsM9RfEJ5WC1W5Xj
	1KZlIaf0bb14ncU9G7bOGABvsy52vyFm1+jMdq5AgckSOuxba8hrS7EdzigMQrqEZOdV
	4olw==
Received: by 10.68.136.65 with SMTP id py1mr9147687pbb.81.1339077121983;
	Thu, 07 Jun 2012 06:52:01 -0700 (PDT)
Received: from jintongl-9bd83b ([113.88.58.6])
	by mx.google.com with ESMTPS id nv6sm1567860pbc.42.2012.06.07.06.51.58
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 06:52:01 -0700 (PDT)
Date: Thu, 7 Jun 2012 21:48:06 +0800
From: "jintonglei" <jintonglei@gmail.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"xen-devel" <xen-devel@lists.xen.org>
References: <1338994641.32319.127.camel@zakaz.uk.xensource.com>
Message-ID: <201206072148024242094@gmail.com>
X-mailer: Foxmail 6, 15, 201, 23 [cn]
Mime-Version: 1.0
Cc: Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] Volunteers wanted to help with list moderation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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'd like to do it happily :)
but, how? 

>Most Xen.org mailing lists are moderated for non-subscribers, primarily
>as a SPAM prevention measure. We are a little short of moderators at the
>moment which means that sometimes mails for genuine posters who happen
>to not be subscribed get delayed for a few days.
>
>We are looking for volunteers to help out with this, it should be a
>couple of a minutes each day to clear out any SPAM which has made it
>through the automated filters and accept the posts from non-subscribers.
>
>The basic policy for moderation is:
>
>     "reject and blacklist spam, accept and whitelist everything else".
>
>Most of the SPAM which gets through the filters is still pretty obvious
>to the human eye and there are generally only a small number each day so
>it is usually a pretty quick job.
>
>Please let myself and Lars know if you would like to help out with one
>or more lists. The only requirement is to be an existing regular poster
>to the list.
>
>Ian.
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/xen-devel
------------------	
			 
jintonglei
2012-06-07


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:52:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1Scd8B-0002v4-Rt; Thu, 07 Jun 2012 13:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jintonglei@gmail.com>) id 1Scd89-0002uo-MO
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:52:05 +0000
Received: from [85.158.138.51:3285] by server-11.bemta-3.messagelabs.com id
	14/C2-28329-402B0DF4; Thu, 07 Jun 2012 13:52:04 +0000
X-Env-Sender: jintonglei@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339077122!31359643!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24115 invoked from network); 7 Jun 2012 13:52:04 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:52:04 -0000
Received: by dadv2 with SMTP id v2so994676dad.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 06:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version
	:content-type:content-transfer-encoding;
	bh=syG3rozU2Tiqs7JEDeqtgg+3C8NEMv6bOCAlO4vTJsc=;
	b=S3Yl/9qYsf36fQiUtoguRF6nkva0TcIZNRwANUj127J3eDtf1HXqjWfguIaPhcmfWt
	38aKSGBi4DELrbff3AkfcL4HBUtbmgC+Z80qD2FuqGNXGGppp8+VvMtJymfLBij3kVt0
	kuNO1lb49LVhTYOn2PRZvdPSAyl9tGrc9DU5dClANr7w56MAYz0lJRKmeC76QlPnEs+q
	FFQoSd6vuq8uFVb3UDVS9IDQAmBvhox3+lAk7xhb9DsiTO1BUIDAvsM9RfEJ5WC1W5Xj
	1KZlIaf0bb14ncU9G7bOGABvsy52vyFm1+jMdq5AgckSOuxba8hrS7EdzigMQrqEZOdV
	4olw==
Received: by 10.68.136.65 with SMTP id py1mr9147687pbb.81.1339077121983;
	Thu, 07 Jun 2012 06:52:01 -0700 (PDT)
Received: from jintongl-9bd83b ([113.88.58.6])
	by mx.google.com with ESMTPS id nv6sm1567860pbc.42.2012.06.07.06.51.58
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 06:52:01 -0700 (PDT)
Date: Thu, 7 Jun 2012 21:48:06 +0800
From: "jintonglei" <jintonglei@gmail.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"xen-devel" <xen-devel@lists.xen.org>
References: <1338994641.32319.127.camel@zakaz.uk.xensource.com>
Message-ID: <201206072148024242094@gmail.com>
X-mailer: Foxmail 6, 15, 201, 23 [cn]
Mime-Version: 1.0
Cc: Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Xen-devel] Volunteers wanted to help with list moderation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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'd like to do it happily :)
but, how? 

>Most Xen.org mailing lists are moderated for non-subscribers, primarily
>as a SPAM prevention measure. We are a little short of moderators at the
>moment which means that sometimes mails for genuine posters who happen
>to not be subscribed get delayed for a few days.
>
>We are looking for volunteers to help out with this, it should be a
>couple of a minutes each day to clear out any SPAM which has made it
>through the automated filters and accept the posts from non-subscribers.
>
>The basic policy for moderation is:
>
>     "reject and blacklist spam, accept and whitelist everything else".
>
>Most of the SPAM which gets through the filters is still pretty obvious
>to the human eye and there are generally only a small number each day so
>it is usually a pretty quick job.
>
>Please let myself and Lars know if you would like to help out with one
>or more lists. The only requirement is to be an existing regular poster
>to the list.
>
>Ian.
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/xen-devel
------------------	
			 
jintonglei
2012-06-07


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:54:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:54: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 1ScdAR-00038W-Co; Thu, 07 Jun 2012 13:54: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 1ScdAQ-00038N-9z
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:54:26 +0000
Received: from [85.158.143.35:22376] by server-2.bemta-4.messagelabs.com id
	C0/1B-17938-192B0DF4; Thu, 07 Jun 2012 13:54:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339077264!7520987!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10958 invoked from network); 7 Jun 2012 13:54:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12885370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 13:54:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	14:54:24 +0100
Message-ID: <1339077263.18523.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 14:54:23 +0100
In-Reply-To: <20120607124033.GS70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 13:40 +0100, Tim Deegan wrote:
> At 13:26 +0100 on 07 Jun (1339075605), Ian Campbell wrote:
> > On Thu, 2012-06-07 at 09:49 +0100, Tim Deegan wrote:
> > > At 15:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> > > > Useful for debug but not actually used in this patch.
> > > > 
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > >  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
> > > >  xen/include/asm-arm/page.h |    1 +
> > > >  2 files changed, 35 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > > index 4f624d8..fdbecbc 100644
> > > > --- a/xen/arch/arm/p2m.c
> > > > +++ b/xen/arch/arm/p2m.c
> > > > @@ -5,6 +5,40 @@
> > > >  #include <xen/domain_page.h>
> > > >  #include <asm/flushtlb.h>
> > > >  
> > > > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > > > +{
> > > > +    struct p2m_domain *p2m = &d->arch.p2m;
> > > > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > > > +
> > > > +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > > > +
> > > > +    first = __map_domain_page(p2m->first_level);
> > > > +    printk("1ST[%#03llx] = %#016llx\n",
> > > > +           first_table_offset(addr),
> > > > +           first[first_table_offset(addr)].bits);
> > > > +    if ( !first[first_table_offset(addr)].p2m.valid ||
> > > > +         !first[first_table_offset(addr)].p2m.table )
> > > > +        goto done;
> > > > +
> > > > +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > > > +    printk("2ND[%#03llx] = %#016llx\n",
> > > > +           second_table_offset(addr),
> > > > +           second[second_table_offset(addr)].bits);
> > > > +    if ( !second[second_table_offset(addr)].p2m.valid ||
> > > > +         !second[second_table_offset(addr)].p2m.table )
> > > > +        goto done;
> > > > +
> > > > +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > > > +    printk("3RD[%#03llx] = %#016llx\n",
> > > > +           third_table_offset(addr),
> > > > +           third[third_table_offset(addr)].bits);
> > > > +
> > > > +done:
> > > > +    if (third) unmap_domain_page(third);
> > > > +    if (second) unmap_domain_page(second);
> > > > +    if (first) unmap_domain_page(first);
> > > > +}
> > > 
> > > Can this be unified with dump_pt_walk?
> > 
> > Not all that easily, mainly because dump_pt_walk walks xenheap pages
> > (which don't need mapping) while dump_p2m_walk dumps domheap pages
> > (which need mapping as we go). I probably could write something generic
> > enough but I fear that it would be a mass of if's.
> 
> Is there any harm in mapping xenheap pages?  Since this is only invoked
> on error paths, we don't particularly need it to be fast. 

For some reason I thought it just didn't work -- I'll give it a go
though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:54:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13:54: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 1ScdAR-00038W-Co; Thu, 07 Jun 2012 13:54: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 1ScdAQ-00038N-9z
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:54:26 +0000
Received: from [85.158.143.35:22376] by server-2.bemta-4.messagelabs.com id
	C0/1B-17938-192B0DF4; Thu, 07 Jun 2012 13:54:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339077264!7520987!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10958 invoked from network); 7 Jun 2012 13:54:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 13:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12885370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 13:54:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	14:54:24 +0100
Message-ID: <1339077263.18523.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Jun 2012 14:54:23 +0100
In-Reply-To: <20120607124033.GS70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 13:40 +0100, Tim Deegan wrote:
> At 13:26 +0100 on 07 Jun (1339075605), Ian Campbell wrote:
> > On Thu, 2012-06-07 at 09:49 +0100, Tim Deegan wrote:
> > > At 15:39 +0000 on 01 Jun (1338565172), Ian Campbell wrote:
> > > > Useful for debug but not actually used in this patch.
> > > > 
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > >  xen/arch/arm/p2m.c         |   34 ++++++++++++++++++++++++++++++++++
> > > >  xen/include/asm-arm/page.h |    1 +
> > > >  2 files changed, 35 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > > index 4f624d8..fdbecbc 100644
> > > > --- a/xen/arch/arm/p2m.c
> > > > +++ b/xen/arch/arm/p2m.c
> > > > @@ -5,6 +5,40 @@
> > > >  #include <xen/domain_page.h>
> > > >  #include <asm/flushtlb.h>
> > > >  
> > > > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > > > +{
> > > > +    struct p2m_domain *p2m = &d->arch.p2m;
> > > > +    lpae_t *first = NULL, *second = NULL, *third = NULL;
> > > > +
> > > > +    printk("dom%d IPA %#016llx\n", d->domain_id, addr);
> > > > +
> > > > +    first = __map_domain_page(p2m->first_level);
> > > > +    printk("1ST[%#03llx] = %#016llx\n",
> > > > +           first_table_offset(addr),
> > > > +           first[first_table_offset(addr)].bits);
> > > > +    if ( !first[first_table_offset(addr)].p2m.valid ||
> > > > +         !first[first_table_offset(addr)].p2m.table )
> > > > +        goto done;
> > > > +
> > > > +    second = map_domain_page(first[first_table_offset(addr)].p2m.base);
> > > > +    printk("2ND[%#03llx] = %#016llx\n",
> > > > +           second_table_offset(addr),
> > > > +           second[second_table_offset(addr)].bits);
> > > > +    if ( !second[second_table_offset(addr)].p2m.valid ||
> > > > +         !second[second_table_offset(addr)].p2m.table )
> > > > +        goto done;
> > > > +
> > > > +    third = map_domain_page(second[second_table_offset(addr)].p2m.base);
> > > > +    printk("3RD[%#03llx] = %#016llx\n",
> > > > +           third_table_offset(addr),
> > > > +           third[third_table_offset(addr)].bits);
> > > > +
> > > > +done:
> > > > +    if (third) unmap_domain_page(third);
> > > > +    if (second) unmap_domain_page(second);
> > > > +    if (first) unmap_domain_page(first);
> > > > +}
> > > 
> > > Can this be unified with dump_pt_walk?
> > 
> > Not all that easily, mainly because dump_pt_walk walks xenheap pages
> > (which don't need mapping) while dump_p2m_walk dumps domheap pages
> > (which need mapping as we go). I probably could write something generic
> > enough but I fear that it would be a mass of if's.
> 
> Is there any harm in mapping xenheap pages?  Since this is only invoked
> on error paths, we don't particularly need it to be fast. 

For some reason I thought it just didn't work -- I'll give it a go
though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1ScdFO-0003R2-9b; Thu, 07 Jun 2012 13:59:34 +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 1ScdFM-0003Qt-9C
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:59:32 +0000
Received: from [85.158.138.51:50105] by server-4.bemta-3.messagelabs.com id
	54/C2-13598-3C3B0DF4; Thu, 07 Jun 2012 13:59:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339077570!31328359!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21850 invoked from network); 7 Jun 2012 13:59:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 13:59:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScdFK-000JI8-5g; Thu, 07 Jun 2012 13:59:30 +0000
Date: Thu, 7 Jun 2012 14:59:30 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607135930.GW70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
	<20120601170514.GD77921@ocelot.phlegethon.org>
	<1338577461.14877.61.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338577461.14877.61.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
	paging 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

At 20:04 +0100 on 01 Jun (1338581061), Ian Campbell wrote:
> On Fri, 2012-06-01 at 18:05 +0100, Tim Deegan wrote:
> > At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> > > With enough warnings enabled the model seemed to be complaining that pages
> > > cached before paging was enabled had been mapped with to inconsistent sets of
> > > attributes. I'm not convinced that isn't a model issue, nor am I convinced
> > > this has really fixed anything, but it seems sensible enough.
> > 
> > This might be what breaks secondary CPU bringup: pagetables built by CPU
> > 0 may not have been flushed all the way to RAM when CPU 1 comes up, and
> > CPU 1 isn't participating in cache coherence protocols when it
> > starts to need them.
> 
> The issue here is the lack of the necessary flush, rather than this
> change particularly, right?

It turns out to be much more prosaic - the patch to delete the identity
mapping from the boot pagetables was scuppering non-boot CPUs.

So this is OK, but can I suggest this to tidy it up?

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 71197af..0d8ce0f 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -211,17 +211,13 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
 	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
-	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
-	orr   r0, r0, #(SCTLR_C)
-	mcr   CP32(r0, HSCTLR)
-
 #ifdef EARLY_UART_ADDRESS
 	/* Recover the UART address in the new address space. */
 	lsl   r11, #11

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 13:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 13: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 1ScdFO-0003R2-9b; Thu, 07 Jun 2012 13:59:34 +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 1ScdFM-0003Qt-9C
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 13:59:32 +0000
Received: from [85.158.138.51:50105] by server-4.bemta-3.messagelabs.com id
	54/C2-13598-3C3B0DF4; Thu, 07 Jun 2012 13:59:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339077570!31328359!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21850 invoked from network); 7 Jun 2012 13:59:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 13:59:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1ScdFK-000JI8-5g; Thu, 07 Jun 2012 13:59:30 +0000
Date: Thu, 7 Jun 2012 14:59:30 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607135930.GW70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
	<20120601170514.GD77921@ocelot.phlegethon.org>
	<1338577461.14877.61.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1338577461.14877.61.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
	paging 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

At 20:04 +0100 on 01 Jun (1338581061), Ian Campbell wrote:
> On Fri, 2012-06-01 at 18:05 +0100, Tim Deegan wrote:
> > At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> > > With enough warnings enabled the model seemed to be complaining that pages
> > > cached before paging was enabled had been mapped with to inconsistent sets of
> > > attributes. I'm not convinced that isn't a model issue, nor am I convinced
> > > this has really fixed anything, but it seems sensible enough.
> > 
> > This might be what breaks secondary CPU bringup: pagetables built by CPU
> > 0 may not have been flushed all the way to RAM when CPU 1 comes up, and
> > CPU 1 isn't participating in cache coherence protocols when it
> > starts to need them.
> 
> The issue here is the lack of the necessary flush, rather than this
> change particularly, right?

It turns out to be much more prosaic - the patch to delete the identity
mapping from the boot pagetables was scuppering non-boot CPUs.

So this is OK, but can I suggest this to tidy it up?

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 71197af..0d8ce0f 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -211,17 +211,13 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
 	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
-	mrc   CP32(r0, HSCTLR)       /* Now enable data cache */
-	orr   r0, r0, #(SCTLR_C)
-	mcr   CP32(r0, HSCTLR)
-
 #ifdef EARLY_UART_ADDRESS
 	/* Recover the UART address in the new address space. */
 	lsl   r11, #11

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:20:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14: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 1ScdZW-0003uN-8q; Thu, 07 Jun 2012 14:20: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 1ScdZU-0003uI-Si
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:20:21 +0000
Received: from [85.158.139.83:49261] by server-11.bemta-5.messagelabs.com id
	B4/68-25194-4A8B0DF4; Thu, 07 Jun 2012 14:20:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339078819!28515157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2992 invoked from network); 7 Jun 2012 14:20:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:20:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12886511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:20:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:20:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScdZS-0000Tq-Sh; Thu, 07 Jun 2012 14:20:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScdZS-0008B4-Rq;
	Thu, 07 Jun 2012 15:20:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47266.847506.330124@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:20:18 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-5-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
	libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> This patch converts libxl_device_disk_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.

Just spotted:

> +void libxl__initiate_device_add(libxl__egc *egc, libxl__ao_device *aodev)
> +{
...
> +    libxl__ev_devstate_init(&aodev->ds);
> +    rc = libxl__ev_devstate_wait(gc, &aodev->ds, device_backend_callback,
> +                                 state_path, XenbusStateInitWait,
> +                                 LIBXL_INIT_TIMEOUT * 1000);

Another unneeded _init.

I won't comment on any more of these I find.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:20:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14: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 1ScdZW-0003uN-8q; Thu, 07 Jun 2012 14:20: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 1ScdZU-0003uI-Si
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:20:21 +0000
Received: from [85.158.139.83:49261] by server-11.bemta-5.messagelabs.com id
	B4/68-25194-4A8B0DF4; Thu, 07 Jun 2012 14:20:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339078819!28515157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2992 invoked from network); 7 Jun 2012 14:20:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:20:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12886511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:20:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:20:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScdZS-0000Tq-Sh; Thu, 07 Jun 2012 14:20:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScdZS-0008B4-Rq;
	Thu, 07 Jun 2012 15:20:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47266.847506.330124@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:20:18 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-5-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
	libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> This patch converts libxl_device_disk_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.

Just spotted:

> +void libxl__initiate_device_add(libxl__egc *egc, libxl__ao_device *aodev)
> +{
...
> +    libxl__ev_devstate_init(&aodev->ds);
> +    rc = libxl__ev_devstate_wait(gc, &aodev->ds, device_backend_callback,
> +                                 state_path, XenbusStateInitWait,
> +                                 LIBXL_INIT_TIMEOUT * 1000);

Another unneeded _init.

I won't comment on any more of these I find.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:26:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:26: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 1Scdf6-000468-LS; Thu, 07 Jun 2012 14: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.Jackson@eu.citrix.com>) id 1Scdf5-00045s-2o
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:26:07 +0000
Received: from [193.109.254.147:41327] by server-12.bemta-14.messagelabs.com
	id C7/EE-12998-EF9B0DF4; Thu, 07 Jun 2012 14:26:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339079157!1744126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2177 invoked from network); 7 Jun 2012 14:25:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12886930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:25:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:25:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scdeu-0000Vj-Sc; Thu, 07 Jun 2012 14:25:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scdeu-0008Bb-Rq;
	Thu, 07 Jun 2012 15:25:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47604.849028.717366@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:25:56 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-5-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
	libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> This patch converts libxl_device_disk_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.

And:

> +/* Internal AO operation to connect a disk device, called by
> + * libxl_device_disk_add and libxl__add_disks. This function calls
> + * libxl__initiate_device_add */
> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
> +                                    libxl_device_disk *disk,
> +                                    libxl__ao_device *aodev);
> +
> +/* Arranges that dev will be added to the guest, and the
> + * hotplug scripts will be executed (if necessary). When
> + * this is done (or an error happens), the callback in
> + * aodev->callback will be called.
> + */
> +_hidden void libxl__initiate_device_add(libxl__egc*, libxl__ao_device *aodev);

I don't think these comments are coherent.

I think a function which "Arranges that dev will be added to the
guest" is one which does everything necessary - ie, the outermost
entrypoint.

And you're using `internal' here to mean `internal to libxl'.  I think
that's clear from the name (which has `__').  Whereas on first reading
it sounds like you mean `internal to the device adding machinery' -
but `libxl__device_disk_add' is the main entrypoint to that
machinery.

And `libxl__initiate_device_add' is the internal helper function.

I think these comments need to be clarified and perhaps
libxl__initiate_device_add needs to be renamed to be clear about what
exactly it is for.  Eg
   /* Initiates the device-kind-independent operations blah blah
   hidden void libxl__initiate_device_add_core(libxl__egc*,
                                   libxl__ao_device *aodev);
or something.

Please do reply suggesting alternative wording

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:26:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:26: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 1Scdf6-000468-LS; Thu, 07 Jun 2012 14: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.Jackson@eu.citrix.com>) id 1Scdf5-00045s-2o
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:26:07 +0000
Received: from [193.109.254.147:41327] by server-12.bemta-14.messagelabs.com
	id C7/EE-12998-EF9B0DF4; Thu, 07 Jun 2012 14:26:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339079157!1744126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2177 invoked from network); 7 Jun 2012 14:25:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12886930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:25:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:25:57 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scdeu-0000Vj-Sc; Thu, 07 Jun 2012 14:25:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scdeu-0008Bb-Rq;
	Thu, 07 Jun 2012 15:25:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47604.849028.717366@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:25:56 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-5-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
	libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> This patch converts libxl_device_disk_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.

And:

> +/* Internal AO operation to connect a disk device, called by
> + * libxl_device_disk_add and libxl__add_disks. This function calls
> + * libxl__initiate_device_add */
> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
> +                                    libxl_device_disk *disk,
> +                                    libxl__ao_device *aodev);
> +
> +/* Arranges that dev will be added to the guest, and the
> + * hotplug scripts will be executed (if necessary). When
> + * this is done (or an error happens), the callback in
> + * aodev->callback will be called.
> + */
> +_hidden void libxl__initiate_device_add(libxl__egc*, libxl__ao_device *aodev);

I don't think these comments are coherent.

I think a function which "Arranges that dev will be added to the
guest" is one which does everything necessary - ie, the outermost
entrypoint.

And you're using `internal' here to mean `internal to libxl'.  I think
that's clear from the name (which has `__').  Whereas on first reading
it sounds like you mean `internal to the device adding machinery' -
but `libxl__device_disk_add' is the main entrypoint to that
machinery.

And `libxl__initiate_device_add' is the internal helper function.

I think these comments need to be clarified and perhaps
libxl__initiate_device_add needs to be renamed to be clear about what
exactly it is for.  Eg
   /* Initiates the device-kind-independent operations blah blah
   hidden void libxl__initiate_device_add_core(libxl__egc*,
                                   libxl__ao_device *aodev);
or something.

Please do reply suggesting alternative wording

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:26:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:26: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 1ScdfY-00049Y-2h; Thu, 07 Jun 2012 14:26:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScdfW-00049H-Ii
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:26:34 +0000
Received: from [85.158.143.99:23324] by server-2.bemta-4.messagelabs.com id
	42/E1-17938-91AB0DF4; Thu, 07 Jun 2012 14:26:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339079193!26493559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21620 invoked from network); 7 Jun 2012 14:26:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:26:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12886953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:26:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:26:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScdfU-0000Vw-P5; Thu, 07 Jun 2012 14:26:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScdfU-0008Bf-OG;
	Thu, 07 Jun 2012 15:26:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47640.736331.500556@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:26:32 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-6-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-6-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 05/10] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 05/10] libxl: convert libxl_device_nic_add to an async operation"):
> This patch converts libxl_device_nic_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.
> 
> Calls to libxl_device_nic_add have also been moved to occur after the
> device model has been launched, so when hotplug scripts are called
> from this functions the interfaces already exists.

This is now a lot smaller, excellent.

> -int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
> +int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
> +                         const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
> +    libxl__ao_device *device;

Can we call that variable `aodev' ?  Elsewhere `device' is a
libxl_device_FOO.


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:26:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:26: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 1ScdfY-00049Y-2h; Thu, 07 Jun 2012 14:26:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScdfW-00049H-Ii
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:26:34 +0000
Received: from [85.158.143.99:23324] by server-2.bemta-4.messagelabs.com id
	42/E1-17938-91AB0DF4; Thu, 07 Jun 2012 14:26:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339079193!26493559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21620 invoked from network); 7 Jun 2012 14:26:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:26:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12886953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:26:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:26:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScdfU-0000Vw-P5; Thu, 07 Jun 2012 14:26:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScdfU-0008Bf-OG;
	Thu, 07 Jun 2012 15:26:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47640.736331.500556@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:26:32 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-6-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-6-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 05/10] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 05/10] libxl: convert libxl_device_nic_add to an async operation"):
> This patch converts libxl_device_nic_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.
> 
> Calls to libxl_device_nic_add have also been moved to occur after the
> device model has been launched, so when hotplug scripts are called
> from this functions the interfaces already exists.

This is now a lot smaller, excellent.

> -int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
> +int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
> +                         const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
> +    libxl__ao_device *device;

Can we call that variable `aodev' ?  Elsewhere `device' is a
libxl_device_FOO.


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:31:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:31: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 1Scdjj-0004VZ-Ot; Thu, 07 Jun 2012 14:30:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scdji-0004VR-Dp
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:30:54 +0000
Received: from [193.109.254.147:56323] by server-11.bemta-14.messagelabs.com
	id 1E/F0-02727-D1BB0DF4; Thu, 07 Jun 2012 14:30:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339079450!8575894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 7 Jun 2012 14:30:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:30:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:30:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:30:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scdjd-0000Xb-UN; Thu, 07 Jun 2012 14:30:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scdjd-0008Bp-TY;
	Thu, 07 Jun 2012 15:30:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47897.707481.695066@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:30:49 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FC60CA8.4090404@citrix.com>
References: <1337184716-49276-1-git-send-email-roger.pau@citrix.com>
	<1337184716-49276-12-git-send-email-roger.pau@citrix.com>
	<20406.31676.266501.253510@mariner.uk.xensource.com>
	<4FBA6D52.9050809@citrix.com>
	<20420.57290.841831.831419@mariner.uk.xensource.com>
	<1338302817.14158.120.camel@zakaz.uk.xensource.com>
	<4FC60CA8.4090404@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF 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

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF by default"):
> If this is right, I have to change my hotplug patches, but this will be 
> a mess, because I have no way to tell if a domain is PV or HVM when 
> plugging in the devices, so if VIF is passed for both PV or PV+TAP I 
> will have no way of knowing that.

Hmmm.

> Should we create three different nic types? VIF (PV), IOEMU (TAP), 
> HYBRID (PV+TAP)?

I think this might be better.  Or alternatively, always provide PV,
and have a flag which says `do provide ioemu'.

I think it's very confusing if setting the `type' to `ioemu' rather
than `pv' means `do provide pv but provide ioemu as well'.

Another way of looking at it is: if we wanted to provide some other
interfaces (besides Xen PV and emulated PCI) in the future, would it
be an alternative to PV or to PCI or something additional ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:31:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:31: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 1Scdjj-0004VZ-Ot; Thu, 07 Jun 2012 14:30:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scdji-0004VR-Dp
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:30:54 +0000
Received: from [193.109.254.147:56323] by server-11.bemta-14.messagelabs.com
	id 1E/F0-02727-D1BB0DF4; Thu, 07 Jun 2012 14:30:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339079450!8575894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 7 Jun 2012 14:30:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:30:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:30:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:30:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scdjd-0000Xb-UN; Thu, 07 Jun 2012 14:30:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scdjd-0008Bp-TY;
	Thu, 07 Jun 2012 15:30:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.47897.707481.695066@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:30:49 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FC60CA8.4090404@citrix.com>
References: <1337184716-49276-1-git-send-email-roger.pau@citrix.com>
	<1337184716-49276-12-git-send-email-roger.pau@citrix.com>
	<20406.31676.266501.253510@mariner.uk.xensource.com>
	<4FBA6D52.9050809@citrix.com>
	<20420.57290.841831.831419@mariner.uk.xensource.com>
	<1338302817.14158.120.camel@zakaz.uk.xensource.com>
	<4FC60CA8.4090404@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF 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

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF by default"):
> If this is right, I have to change my hotplug patches, but this will be 
> a mess, because I have no way to tell if a domain is PV or HVM when 
> plugging in the devices, so if VIF is passed for both PV or PV+TAP I 
> will have no way of knowing that.

Hmmm.

> Should we create three different nic types? VIF (PV), IOEMU (TAP), 
> HYBRID (PV+TAP)?

I think this might be better.  Or alternatively, always provide PV,
and have a flag which says `do provide ioemu'.

I think it's very confusing if setting the `type' to `ioemu' rather
than `pv' means `do provide pv but provide ioemu as well'.

Another way of looking at it is: if we wanted to provide some other
interfaces (besides Xen PV and emulated PCI) in the future, would it
be an alternative to PV or to PCI or something additional ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:40:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scdsv-0004xu-Pt; Thu, 07 Jun 2012 14:40:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scdsu-0004xo-CN
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:40:24 +0000
Received: from [85.158.143.35:18595] by server-3.bemta-4.messagelabs.com id
	91/AD-29237-75DB0DF4; Thu, 07 Jun 2012 14:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339080018!19234799!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10031 invoked from network); 7 Jun 2012 14:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:40:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:40:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scdsn-0000an-MU; Thu, 07 Jun 2012 14:40:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scdsn-0008CN-Ld;
	Thu, 07 Jun 2012 15:40:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.48465.656538.460862@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:40:17 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-9-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-9-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 08/10] libxl: call hotplug scripts for
 disk devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 08/10] libxl: call hotplug scripts for disk devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for disk devices, that should be called when the device is added or
> removed from a guest.
...

> +static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev)
...
> +out:
> +    libxl__ev_time_deregister(gc, &aodev->ev);
> +    aodev->rc = rc;
> +    aodev->callback(egc, aodev);

This little set of things - deregistering the timeout, and calling the
callback, occur a few times.  It would also be a good idea to check
that the child has been reaped, or we may reenter this confusingly
later.

Perhaps it would be a good idea to have:

  static void device_hotplug_done(blah blah)
  {
      libxl__ev_time_deregister(gc, &aodev->ev);
      assert(!libxl__ev_child_inuse(&aodev->child));
      aodev->callback(egc, aodev);
  }

And this could be used on all of the completion paths.  (You'll have
to initialise the ev_child at the top of device_hotplug of course.)

That way the whole thing has one entry and one exit.

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 5a2a87a..9dd2404 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -72,6 +72,7 @@
> 
>  #define LIBXL_INIT_TIMEOUT 10
>  #define LIBXL_DESTROY_TIMEOUT 10
> +#define LIBXL_HOTPLUG_TIMEOUT 10
>  #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
>  #define LIBXL_XENCONSOLE_LIMIT 1048576
>  #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
> @@ -1846,6 +1847,10 @@ struct libxl__ao_device {
>      int rc;
>      libxl__ev_devstate ds;
>      void *base;
> +    /* device hotplug execution */
> +    char *what;

`const char *what;' ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:40:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scdsv-0004xu-Pt; Thu, 07 Jun 2012 14:40:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scdsu-0004xo-CN
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:40:24 +0000
Received: from [85.158.143.35:18595] by server-3.bemta-4.messagelabs.com id
	91/AD-29237-75DB0DF4; Thu, 07 Jun 2012 14:40:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339080018!19234799!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10031 invoked from network); 7 Jun 2012 14:40:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:40:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:40:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scdsn-0000an-MU; Thu, 07 Jun 2012 14:40:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scdsn-0008CN-Ld;
	Thu, 07 Jun 2012 15:40:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.48465.656538.460862@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:40:17 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-9-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-9-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 08/10] libxl: call hotplug scripts for
 disk devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 08/10] libxl: call hotplug scripts for disk devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for disk devices, that should be called when the device is added or
> removed from a guest.
...

> +static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev)
...
> +out:
> +    libxl__ev_time_deregister(gc, &aodev->ev);
> +    aodev->rc = rc;
> +    aodev->callback(egc, aodev);

This little set of things - deregistering the timeout, and calling the
callback, occur a few times.  It would also be a good idea to check
that the child has been reaped, or we may reenter this confusingly
later.

Perhaps it would be a good idea to have:

  static void device_hotplug_done(blah blah)
  {
      libxl__ev_time_deregister(gc, &aodev->ev);
      assert(!libxl__ev_child_inuse(&aodev->child));
      aodev->callback(egc, aodev);
  }

And this could be used on all of the completion paths.  (You'll have
to initialise the ev_child at the top of device_hotplug of course.)

That way the whole thing has one entry and one exit.

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 5a2a87a..9dd2404 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -72,6 +72,7 @@
> 
>  #define LIBXL_INIT_TIMEOUT 10
>  #define LIBXL_DESTROY_TIMEOUT 10
> +#define LIBXL_HOTPLUG_TIMEOUT 10
>  #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
>  #define LIBXL_XENCONSOLE_LIMIT 1048576
>  #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
> @@ -1846,6 +1847,10 @@ struct libxl__ao_device {
>      int rc;
>      libxl__ev_devstate ds;
>      void *base;
> +    /* device hotplug execution */
> +    char *what;

`const char *what;' ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:45:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scdy0-00056n-HK; Thu, 07 Jun 2012 14:45:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Scdxy-00056b-Tt
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:45:39 +0000
Received: from [85.158.138.51:44363] by server-11.bemta-3.messagelabs.com id
	CD/B0-28329-29EB0DF4; Thu, 07 Jun 2012 14:45:38 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339080336!31279644!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5639 invoked from network); 7 Jun 2012 14:45:37 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:45:37 -0000
Received: by ggnp1 with SMTP id p1so526822ggn.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 07:45:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=grVyeXaTBaGAN13sNcsp0vjevF0icQX+XOMoECLpnco=;
	b=jd38/1Lat4Sm2ogxUwjT4YcN+igIvgDCvAJfkWg6HYTzh1tWSYw7K1B51d59jQmezc
	niUUKkCNyH+j4V9zyvIRN/FDKi1rlZgMnUbtgxCHdTurTk3CWKHqiHerJvUGbc5tIMfj
	dA+5DI4gvayM5745eke9x1taD9XWYabrBKLTmzGOqOrrNcvN8HWp/8NpVO1FkGzzfgH1
	enNYRGKBceILOZjX9EmSk9MyBBtnVdUKK6JIWCNhlo6tKuPgAcoeyhqiAFcAR6JFXMfz
	YdvoYuTmoRSG+qf6imCAmAxMTFYsZMDZRyotKSkhefZr6C9I1+VW/WSZQ7RZJOPicx9V
	uh5A==
Received: by 10.60.19.67 with SMTP id c3mr2442864oee.2.1339080335836; Thu, 07
	Jun 2012 07:45:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.204.99 with HTTP; Thu, 7 Jun 2012 07:45:15 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
	<CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 7 Jun 2012 16:45:15 +0200
Message-ID: <CABs9EjnRbUgEYt=7bf1tLrq1YurLEejKWfWvr-1ijsUcrq6MOA@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
X-Gm-Message-State: ALoCoQnB4SVAy7eUSb7ODoh4rcFRODtMwVb/EtxatezXnaOwOvdXD3aG0qQO5V6DamxC+GkzmUu1
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-users@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 3:14 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Sorry to throw in a criticism without a constructive solution, but I
> just want to register one opinion: To me clicking on a link and seeing
> a "Category" page says very strongly, "I couldn't be bothered to
> actually do any work here; I'll leave you to do all the work to figure
> out what page you need." =A0When I encounter a Category page on my walk
> through the Xen wiki, I don't even look, but immediately turn to
> Google. =A0I think a page which is has some kind of logical flow to it
> but perhaps a little out-dated is much better than a page which just
> tosses up a bunch of titles in no order and lets you figure it out.
>

I do agree with this, generally. Browsing a wiki and hovering over a
link and seeing that it goes to a Category: page is... somehow
disappointing. Most of the time you won't get any help finding what
you need there so people may already be conditioned to just ignore
them.

> I think in an ideal world, we'd have people who were "maintainers" of
> the wiki just like there are maintainers of different subsections of
> the codebase. =A0Until that time, could we maybe draw up a set of
> "tests" to run on the docs, which can be assigned to people on DocDay?
> =A0One simple thing could be, "Make sure X page is up-to-date" (which
> may include, "Look at the Category: page and make sure everything
> there is listed somewhere on the manually-generated page"); another
> could be a scenario, "Pretend you're a [foo] and you want to know
> [bar]. =A0Start at the top level page and make sure you can find all the
> information you need." =A0If each "test" was something any motivated
> developer/community member could do, and only took 5-10 minutes, it
> should be pretty sustainable. =A0What do you think?
>

I think that's a really good idea. Unit tests for the documentation? ;-)

Related to the discussion: I had a go at a unified books & manuals
page: http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals

Books and manuals are, I think, the only documents that can't really
be linked by topic (beyond something general such as "xcp") as they
are generally quite large, so a page like this makes most sense. Let
me know what you think.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:45:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scdy0-00056n-HK; Thu, 07 Jun 2012 14:45:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Scdxy-00056b-Tt
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:45:39 +0000
Received: from [85.158.138.51:44363] by server-11.bemta-3.messagelabs.com id
	CD/B0-28329-29EB0DF4; Thu, 07 Jun 2012 14:45:38 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339080336!31279644!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5639 invoked from network); 7 Jun 2012 14:45:37 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:45:37 -0000
Received: by ggnp1 with SMTP id p1so526822ggn.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 07:45:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=grVyeXaTBaGAN13sNcsp0vjevF0icQX+XOMoECLpnco=;
	b=jd38/1Lat4Sm2ogxUwjT4YcN+igIvgDCvAJfkWg6HYTzh1tWSYw7K1B51d59jQmezc
	niUUKkCNyH+j4V9zyvIRN/FDKi1rlZgMnUbtgxCHdTurTk3CWKHqiHerJvUGbc5tIMfj
	dA+5DI4gvayM5745eke9x1taD9XWYabrBKLTmzGOqOrrNcvN8HWp/8NpVO1FkGzzfgH1
	enNYRGKBceILOZjX9EmSk9MyBBtnVdUKK6JIWCNhlo6tKuPgAcoeyhqiAFcAR6JFXMfz
	YdvoYuTmoRSG+qf6imCAmAxMTFYsZMDZRyotKSkhefZr6C9I1+VW/WSZQ7RZJOPicx9V
	uh5A==
Received: by 10.60.19.67 with SMTP id c3mr2442864oee.2.1339080335836; Thu, 07
	Jun 2012 07:45:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.204.99 with HTTP; Thu, 7 Jun 2012 07:45:15 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
	<CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 7 Jun 2012 16:45:15 +0200
Message-ID: <CABs9EjnRbUgEYt=7bf1tLrq1YurLEejKWfWvr-1ijsUcrq6MOA@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
X-Gm-Message-State: ALoCoQnB4SVAy7eUSb7ODoh4rcFRODtMwVb/EtxatezXnaOwOvdXD3aG0qQO5V6DamxC+GkzmUu1
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-users@lists.xen.org,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 3:14 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Sorry to throw in a criticism without a constructive solution, but I
> just want to register one opinion: To me clicking on a link and seeing
> a "Category" page says very strongly, "I couldn't be bothered to
> actually do any work here; I'll leave you to do all the work to figure
> out what page you need." =A0When I encounter a Category page on my walk
> through the Xen wiki, I don't even look, but immediately turn to
> Google. =A0I think a page which is has some kind of logical flow to it
> but perhaps a little out-dated is much better than a page which just
> tosses up a bunch of titles in no order and lets you figure it out.
>

I do agree with this, generally. Browsing a wiki and hovering over a
link and seeing that it goes to a Category: page is... somehow
disappointing. Most of the time you won't get any help finding what
you need there so people may already be conditioned to just ignore
them.

> I think in an ideal world, we'd have people who were "maintainers" of
> the wiki just like there are maintainers of different subsections of
> the codebase. =A0Until that time, could we maybe draw up a set of
> "tests" to run on the docs, which can be assigned to people on DocDay?
> =A0One simple thing could be, "Make sure X page is up-to-date" (which
> may include, "Look at the Category: page and make sure everything
> there is listed somewhere on the manually-generated page"); another
> could be a scenario, "Pretend you're a [foo] and you want to know
> [bar]. =A0Start at the top level page and make sure you can find all the
> information you need." =A0If each "test" was something any motivated
> developer/community member could do, and only took 5-10 minutes, it
> should be pretty sustainable. =A0What do you think?
>

I think that's a really good idea. Unit tests for the documentation? ;-)

Related to the discussion: I had a go at a unified books & manuals
page: http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals

Books and manuals are, I think, the only documents that can't really
be linked by topic (beyond something general such as "xcp") as they
are generally quite large, so a page like this makes most sense. Let
me know what you think.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:48:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:48: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 1Sce0s-0005S7-B9; Thu, 07 Jun 2012 14:48:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sce0r-0005Rm-Cz
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:48:37 +0000
Received: from [85.158.139.83:19351] by server-2.bemta-5.messagelabs.com id
	86/BA-20827-44FB0DF4; Thu, 07 Jun 2012 14:48:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339080515!31608055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2378 invoked from network); 7 Jun 2012 14:48:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14: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.213.0; Thu, 7 Jun 2012 15:48:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sce0p-0000dL-8D; Thu, 07 Jun 2012 14:48:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sce0p-0008Cr-7O;
	Thu, 07 Jun 2012 15:48:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.48963.214910.33148@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:48:35 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-10-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for nic devices, that should be called when the device is added or
> removed from a guest.

> @@ -1894,10 +1897,19 @@ _hidden void libxl__initiate_device_remove(libxl__egc *egc,
>   * < 0: Error
>   * 0: No need to execute hotplug script
>   * 1: Execute hotplug script
> + *
> + * The last parameter, "num_exec" refeers to the number of times hotplug
> + * scripts have been called for this device. This is currently used for
> + * IOEMU nic interfaces on Linux, since we need to call hotplug scripts twice
> + * for the same device, the first one to add the vif interface, and the second
> + * time to add the tap interface, so:
> + * num_exec == 0: execute hotplug for vif interface.
> + * num_exec == 1: execute hotplug for the associated tap interface.
>   */

I think you should add:

    * The main body of libxl will, for each device, keep calling
    * libxl__get_hotplug_script_info, with incrementing values of
    * num_exec, and executing the resulting script accordingly,
    * until libxl__get_hotplug_script_info returns <=0.

Or

    * The main body of libxl will call libxl__get_hotplug_script_info
    * with exactly the stated values of num_exec, above.  For device
    * types not mentioned the main body calls it once with
    * num_exec==0.

Personally I'm inclined think the knowledge that nics need two
invocations while disks need only one should be confined to the
non-portable Linux code.  Or do you think different platforms will
always do this the same way ?  It seems a bit odd to have the
information about num_exec spread about like this.  So I would prefer
the former comment (and the corresponding change to the code).

That also avoids a nic-specific section in the main body of libxl's
hotplug script machinery.

> +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
> +{
...
> +    }
> +
> +out:
> +    return rc;
> +}
> +

As a matter of good practice I think you should say
      rc = 0;
just before out, on the success path, and not rely on it having
happened to be set to 0 by the previous successful call.

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 Jun 07 14:48:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:48: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 1Sce0s-0005S7-B9; Thu, 07 Jun 2012 14:48:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sce0r-0005Rm-Cz
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:48:37 +0000
Received: from [85.158.139.83:19351] by server-2.bemta-5.messagelabs.com id
	86/BA-20827-44FB0DF4; Thu, 07 Jun 2012 14:48:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339080515!31608055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2378 invoked from network); 7 Jun 2012 14:48:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14: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.213.0; Thu, 7 Jun 2012 15:48:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sce0p-0000dL-8D; Thu, 07 Jun 2012 14:48:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sce0p-0008Cr-7O;
	Thu, 07 Jun 2012 15:48:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.48963.214910.33148@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:48:35 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-10-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for nic devices, that should be called when the device is added or
> removed from a guest.

> @@ -1894,10 +1897,19 @@ _hidden void libxl__initiate_device_remove(libxl__egc *egc,
>   * < 0: Error
>   * 0: No need to execute hotplug script
>   * 1: Execute hotplug script
> + *
> + * The last parameter, "num_exec" refeers to the number of times hotplug
> + * scripts have been called for this device. This is currently used for
> + * IOEMU nic interfaces on Linux, since we need to call hotplug scripts twice
> + * for the same device, the first one to add the vif interface, and the second
> + * time to add the tap interface, so:
> + * num_exec == 0: execute hotplug for vif interface.
> + * num_exec == 1: execute hotplug for the associated tap interface.
>   */

I think you should add:

    * The main body of libxl will, for each device, keep calling
    * libxl__get_hotplug_script_info, with incrementing values of
    * num_exec, and executing the resulting script accordingly,
    * until libxl__get_hotplug_script_info returns <=0.

Or

    * The main body of libxl will call libxl__get_hotplug_script_info
    * with exactly the stated values of num_exec, above.  For device
    * types not mentioned the main body calls it once with
    * num_exec==0.

Personally I'm inclined think the knowledge that nics need two
invocations while disks need only one should be confined to the
non-portable Linux code.  Or do you think different platforms will
always do this the same way ?  It seems a bit odd to have the
information about num_exec spread about like this.  So I would prefer
the former comment (and the corresponding change to the code).

That also avoids a nic-specific section in the main body of libxl's
hotplug script machinery.

> +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
> +{
...
> +    }
> +
> +out:
> +    return rc;
> +}
> +

As a matter of good practice I think you should say
      rc = 0;
just before out, on the success path, and not rely on it having
happened to be set to 0 by the previous successful call.

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 Jun 07 14:50:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Sce2L-0005bK-RH; Thu, 07 Jun 2012 14:50:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sce2K-0005bB-K0
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:50:08 +0000
Received: from [85.158.143.99:58372] by server-2.bemta-4.messagelabs.com id
	EF/97-17938-F9FB0DF4; Thu, 07 Jun 2012 14:50:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339080606!31215294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18650 invoked from network); 7 Jun 2012 14:50:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:50:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:50:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:50:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sce2I-0000e0-26; Thu, 07 Jun 2012 14:50:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sce2I-0008D3-1C;
	Thu, 07 Jun 2012 15:50:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.49054.21127.898941@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:50:06 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-11-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-11-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 10/10] libxl: use libxl__xs_path_cleanup
	on device_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

Roger Pau Monne writes ("[PATCH v5 10/10] libxl: use libxl__xs_path_cleanup on device_destroy"):
> Since the hotplug script that was in charge of cleaning the backend is
> no longer launched, we need to clean the backend by ourselves, so use
> libxl__xs_path_cleanup instead of xs_rm.

Surely this change should be in (or before) one of the earlier
patches ?  Specifically, the one where that hotplug script is
disabled.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:50:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Sce2L-0005bK-RH; Thu, 07 Jun 2012 14:50:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sce2K-0005bB-K0
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:50:08 +0000
Received: from [85.158.143.99:58372] by server-2.bemta-4.messagelabs.com id
	EF/97-17938-F9FB0DF4; Thu, 07 Jun 2012 14:50:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339080606!31215294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18650 invoked from network); 7 Jun 2012 14:50:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 14:50:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12887618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 14:50:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 15:50:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sce2I-0000e0-26; Thu, 07 Jun 2012 14:50:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sce2I-0008D3-1C;
	Thu, 07 Jun 2012 15:50:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.49054.21127.898941@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 15:50:06 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1338383275-21315-11-git-send-email-roger.pau@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-11-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 10/10] libxl: use libxl__xs_path_cleanup
	on device_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

Roger Pau Monne writes ("[PATCH v5 10/10] libxl: use libxl__xs_path_cleanup on device_destroy"):
> Since the hotplug script that was in charge of cleaning the backend is
> no longer launched, we need to clean the backend by ourselves, so use
> libxl__xs_path_cleanup instead of xs_rm.

Surely this change should be in (or before) one of the earlier
patches ?  Specifically, the one where that hotplug script is
disabled.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:55: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 1Sce7F-0005si-N4; Thu, 07 Jun 2012 14:55:13 +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 1Sce7E-0005sb-7m
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:55:12 +0000
Received: from [85.158.143.99:30676] by server-2.bemta-4.messagelabs.com id
	9A/7F-17938-FC0C0DF4; Thu, 07 Jun 2012 14:55:11 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339080909!31445913!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22013 invoked from network); 7 Jun 2012 14:55:10 -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; 7 Jun 2012 14:55:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 15:55:09 +0100
Message-Id: <4FD0CEDA0200007800085A91@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 15:55:06 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <drjones@redhat.com>
References: <4FCF5015020000780008878C@nat28.tlf.novell.com>
	<baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jones <drjones@redhat.com> 06/07/12 12:47 PM >>>
>Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
>done that I would have immediately suspected a different patch instead
>(mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
>upstream commit 26c191788f18). We've already encountered one problem
>with this patch for RHEL6 and fixed it. The patch F17 has, however, is
>already the "fixed" version. Now the difference between RHEL6 and F17
>though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
>but RHEL6 does not. So now with this patch F17 is calling
>atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().

By itself the use of atomic64_read() on page table entries shouldn't be
a problem though, particularly not if what might get written is a not
present entry (while the way atoimc64_read_cx8() works would also
allow for values with the low bit set to be pseudo-written, but neither
did that appear to be the case in at least one of the two cases where
register dumps were provided in your bugzilla, nor should an attempt
to write back a value that was already there cause any problem, even
if the low bit was set).

In any case, the hypervisor log would be interesting to see. Plus - is
this perhaps a rather old hypervisor running there (i.e. potentially
lacking some fix)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 14:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 14:55: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 1Sce7F-0005si-N4; Thu, 07 Jun 2012 14:55:13 +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 1Sce7E-0005sb-7m
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 14:55:12 +0000
Received: from [85.158.143.99:30676] by server-2.bemta-4.messagelabs.com id
	9A/7F-17938-FC0C0DF4; Thu, 07 Jun 2012 14:55:11 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339080909!31445913!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22013 invoked from network); 7 Jun 2012 14:55:10 -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; 7 Jun 2012 14:55:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 15:55:09 +0100
Message-Id: <4FD0CEDA0200007800085A91@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 15:55:06 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <drjones@redhat.com>
References: <4FCF5015020000780008878C@nat28.tlf.novell.com>
	<baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jones <drjones@redhat.com> 06/07/12 12:47 PM >>>
>Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
>done that I would have immediately suspected a different patch instead
>(mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
>upstream commit 26c191788f18). We've already encountered one problem
>with this patch for RHEL6 and fixed it. The patch F17 has, however, is
>already the "fixed" version. Now the difference between RHEL6 and F17
>though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
>but RHEL6 does not. So now with this patch F17 is calling
>atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().

By itself the use of atomic64_read() on page table entries shouldn't be
a problem though, particularly not if what might get written is a not
present entry (while the way atoimc64_read_cx8() works would also
allow for values with the low bit set to be pseudo-written, but neither
did that appear to be the case in at least one of the two cases where
register dumps were provided in your bugzilla, nor should an attempt
to write back a value that was already there cause any problem, even
if the low bit was set).

In any case, the hypervisor log would be interesting to see. Plus - is
this perhaps a rather old hypervisor running there (i.e. potentially
lacking some fix)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:04:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:04: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 1SceGK-0006JO-OK; Thu, 07 Jun 2012 15:04: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 1SceGJ-0006JJ-CA
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:04:35 +0000
Received: from [85.158.143.99:26593] by server-2.bemta-4.messagelabs.com id
	4C/5F-17938-203C0DF4; Thu, 07 Jun 2012 15:04:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339081472!30880526!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17919 invoked from network); 7 Jun 2012 15:04:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 15:04:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57F4Uec015697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 15:04: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
	q57F4UOb006974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 15:04:30 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
	q57F4U7u009739; Thu, 7 Jun 2012 10:04:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 08:04:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9E06B4030D; Thu,  7 Jun 2012 10:57:31 -0400 (EDT)
Date: Thu, 7 Jun 2012 10:57:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120607145731.GM9472@phenom.dumpdata.com>
References: <4FCF5015020000780008878C@nat28.tlf.novell.com>
	<baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
> done that I would have immediately suspected a different patch instead
> (mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
> upstream commit 26c191788f18). We've already encountered one problem
> with this patch for RHEL6 and fixed it. The patch F17 has, however, is

Was the fix for the git commit 26c191788f18 (which I understand is in RHEL6)
posted?

> already the "fixed" version. Now the difference between RHEL6 and F17
> though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
> but RHEL6 does not. So now with this patch F17 is calling
> atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().
> 
> Drew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 07 15:04:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:04: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 1SceGK-0006JO-OK; Thu, 07 Jun 2012 15:04: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 1SceGJ-0006JJ-CA
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:04:35 +0000
Received: from [85.158.143.99:26593] by server-2.bemta-4.messagelabs.com id
	4C/5F-17938-203C0DF4; Thu, 07 Jun 2012 15:04:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339081472!30880526!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17919 invoked from network); 7 Jun 2012 15:04:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 15:04:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57F4Uec015697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 15:04: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
	q57F4UOb006974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 15:04:30 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
	q57F4U7u009739; Thu, 7 Jun 2012 10:04:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 08:04:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9E06B4030D; Thu,  7 Jun 2012 10:57:31 -0400 (EDT)
Date: Thu, 7 Jun 2012 10:57:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120607145731.GM9472@phenom.dumpdata.com>
References: <4FCF5015020000780008878C@nat28.tlf.novell.com>
	<baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <baf035e2-1ee1-43f1-85b0-bac70b958351@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
> done that I would have immediately suspected a different patch instead
> (mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
> upstream commit 26c191788f18). We've already encountered one problem
> with this patch for RHEL6 and fixed it. The patch F17 has, however, is

Was the fix for the git commit 26c191788f18 (which I understand is in RHEL6)
posted?

> already the "fixed" version. Now the difference between RHEL6 and F17
> though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
> but RHEL6 does not. So now with this patch F17 is calling
> atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().
> 
> Drew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 07 15:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SceRn-0006Sz-Vq; Thu, 07 Jun 2012 15:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1SceRm-0006Su-Ax
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:16:26 +0000
Received: from [85.158.138.51:30423] by server-6.bemta-3.messagelabs.com id
	DE/6D-05063-9C5C0DF4; Thu, 07 Jun 2012 15:16:25 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339082184!12610498!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY4OTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28255 invoked from network); 7 Jun 2012 15:16:24 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-13.tower-174.messagelabs.com with SMTP;
	7 Jun 2012 15:16:24 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57FGNBa006790;
	Thu, 7 Jun 2012 11:16:23 -0400
Date: Thu, 07 Jun 2012 11:16:23 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <79761e9a-70ef-477a-b7a1-5175184444ab@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120607145731.GM9472@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ----- 
> Was the fix for the git commit 26c191788f18 (which I understand is in
> RHEL6)
> posted?

Nope, it got rolled into 26c191788f18 before 26c191788f18 was
committed. The fix was to not use __pmd, which is paravirtualized,
when doing the final creation of the pmd_t retval. Here it is
(the 2f88dfd2 referenced there is a rhel6 commit).

    Commit 2f88dfd2 introduces read_pmd_atomic which calls __pmd. __pmd is
    paravirtualized and for xen it calls xen_make_pmd(). xen_make_pmd may
    return a zero pmd in the case that the pfn's associated mfn is still
    invalid. However at the point when read_pmd_atomic is called the mfn can
    appear invalid when it isn't, if its creation was lazily deferred. If
    read_pmd_atomic returns zero in these cases then it can eventually lead to
    a crash. To resolve the issue we can avoid calling __pmd and just return
    the open coded compound literal (as native_make_pmd would do) instead.
    
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtabl
index f2d473b..4f325a1 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -73,12 +73,13 @@ static inline pmd_t read_pmd_atomic(pmd_t *pmdp)
                ret |= ((pmdval_t)*(tmp + 1)) << 32;
        }
 
-       return __pmd(ret);
+       return (pmd_t) { ret };
 }
 #else /* CONFIG_TRANSPARENT_HUGEPAGE */
 static inline pmd_t read_pmd_atomic(pmd_t *pmdp)
 {
-       return __pmd(atomic64_read((atomic64_t *)pmdp));
+       pmdval_t val = (pmdval_t)atomic64_read((atomic64_t *)pmdp);
+       return (pmd_t) { val };
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SceRn-0006Sz-Vq; Thu, 07 Jun 2012 15:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1SceRm-0006Su-Ax
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:16:26 +0000
Received: from [85.158.138.51:30423] by server-6.bemta-3.messagelabs.com id
	DE/6D-05063-9C5C0DF4; Thu, 07 Jun 2012 15:16:25 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339082184!12610498!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY4OTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28255 invoked from network); 7 Jun 2012 15:16:24 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-13.tower-174.messagelabs.com with SMTP;
	7 Jun 2012 15:16:24 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57FGNBa006790;
	Thu, 7 Jun 2012 11:16:23 -0400
Date: Thu, 07 Jun 2012 11:16:23 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <79761e9a-70ef-477a-b7a1-5175184444ab@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120607145731.GM9472@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ----- 
> Was the fix for the git commit 26c191788f18 (which I understand is in
> RHEL6)
> posted?

Nope, it got rolled into 26c191788f18 before 26c191788f18 was
committed. The fix was to not use __pmd, which is paravirtualized,
when doing the final creation of the pmd_t retval. Here it is
(the 2f88dfd2 referenced there is a rhel6 commit).

    Commit 2f88dfd2 introduces read_pmd_atomic which calls __pmd. __pmd is
    paravirtualized and for xen it calls xen_make_pmd(). xen_make_pmd may
    return a zero pmd in the case that the pfn's associated mfn is still
    invalid. However at the point when read_pmd_atomic is called the mfn can
    appear invalid when it isn't, if its creation was lazily deferred. If
    read_pmd_atomic returns zero in these cases then it can eventually lead to
    a crash. To resolve the issue we can avoid calling __pmd and just return
    the open coded compound literal (as native_make_pmd would do) instead.
    
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtabl
index f2d473b..4f325a1 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -73,12 +73,13 @@ static inline pmd_t read_pmd_atomic(pmd_t *pmdp)
                ret |= ((pmdval_t)*(tmp + 1)) << 32;
        }
 
-       return __pmd(ret);
+       return (pmd_t) { ret };
 }
 #else /* CONFIG_TRANSPARENT_HUGEPAGE */
 static inline pmd_t read_pmd_atomic(pmd_t *pmdp)
 {
-       return __pmd(atomic64_read((atomic64_t *)pmdp));
+       pmdval_t val = (pmdval_t)atomic64_read((atomic64_t *)pmdp);
+       return (pmd_t) { val };
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SceVH-0006Zd-W7; Thu, 07 Jun 2012 15:20:03 +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 1SceVG-0006ZM-1a
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:20:02 +0000
Received: from [193.109.254.147:38627] by server-4.bemta-14.messagelabs.com id
	4A/97-27598-1A6C0DF4; Thu, 07 Jun 2012 15:20:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339082399!8470182!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 7 Jun 2012 15:20:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 15:20:00 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57FJlgb002012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 15:19: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
	q57FJkvD015124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 15:19: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
	q57FJjDH021642; Thu, 7 Jun 2012 10:19:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 08:19:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D7A5F4030D; Thu,  7 Jun 2012 11:12:46 -0400 (EDT)
Date: Thu, 7 Jun 2012 11:12:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Paton <paton@cs.wisc.edu>
Message-ID: <20120607151246.GN9472@phenom.dumpdata.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
	<8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Daniel Kiper <dkiper@net-space.pl>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote:
> Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I've attached a patch for 3.3.6 in case anyone would find it useful.

You sure this is the right patch? It looks to be removing most of the code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SceVH-0006Zd-W7; Thu, 07 Jun 2012 15:20:03 +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 1SceVG-0006ZM-1a
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:20:02 +0000
Received: from [193.109.254.147:38627] by server-4.bemta-14.messagelabs.com id
	4A/97-27598-1A6C0DF4; Thu, 07 Jun 2012 15:20:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339082399!8470182!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 7 Jun 2012 15:20:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 15:20:00 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57FJlgb002012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 15:19: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
	q57FJkvD015124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 15:19: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
	q57FJjDH021642; Thu, 7 Jun 2012 10:19:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 08:19:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D7A5F4030D; Thu,  7 Jun 2012 11:12:46 -0400 (EDT)
Date: Thu, 7 Jun 2012 11:12:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Paton <paton@cs.wisc.edu>
Message-ID: <20120607151246.GN9472@phenom.dumpdata.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
	<8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Daniel Kiper <dkiper@net-space.pl>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote:
> Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I've attached a patch for 3.3.6 in case anyone would find it useful.

You sure this is the right patch? It looks to be removing most of the code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SceVB-0006Z1-Jt; Thu, 07 Jun 2012 15:19:57 +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 1SceV9-0006Yu-S1
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:19:56 +0000
Received: from [85.158.139.83:34071] by server-12.bemta-5.messagelabs.com id
	31/B5-18374-696C0DF4; Thu, 07 Jun 2012 15:19:50 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339082389!32453117!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gODM5MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9872 invoked from network); 7 Jun 2012 15:19:49 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-12.tower-182.messagelabs.com with SMTP;
	7 Jun 2012 15:19:49 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57FJmI5026028;
	Thu, 7 Jun 2012 11:19:48 -0400
Date: Thu, 07 Jun 2012 11:19:48 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4FD0CEDA0200007800085A91@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> >>> Andrew Jones <drjones@redhat.com> 06/07/12 12:47 PM >>>
> >Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
> >done that I would have immediately suspected a different patch
> >instead
> >(mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
> >upstream commit 26c191788f18). We've already encountered one problem
> >with this patch for RHEL6 and fixed it. The patch F17 has, however,
> >is
> >already the "fixed" version. Now the difference between RHEL6 and
> >F17
> >though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
> >but RHEL6 does not. So now with this patch F17 is calling
> >atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().
> 
> By itself the use of atomic64_read() on page table entries shouldn't
> be
> a problem though, particularly not if what might get written is a not
> present entry (while the way atoimc64_read_cx8() works would also
> allow for values with the low bit set to be pseudo-written, but
> neither
> did that appear to be the case in at least one of the two cases where
> register dumps were provided in your bugzilla, nor should an attempt
> to write back a value that was already there cause any problem, even
> if the low bit was set).
> 
> In any case, the hypervisor log would be interesting to see. Plus -
> is
> this perhaps a rather old hypervisor running there (i.e. potentially
> lacking some fix)?

I just reproduced this on my own test box, which is running an HV
based on older code (it's RHEL 5.8). Even with
'loglvl=all guest_loglvl=all' I didn't get anything logged in
'xm dmesg'.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:20:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SceVB-0006Z1-Jt; Thu, 07 Jun 2012 15:19:57 +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 1SceV9-0006Yu-S1
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:19:56 +0000
Received: from [85.158.139.83:34071] by server-12.bemta-5.messagelabs.com id
	31/B5-18374-696C0DF4; Thu, 07 Jun 2012 15:19:50 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339082389!32453117!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gODM5MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9872 invoked from network); 7 Jun 2012 15:19:49 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-12.tower-182.messagelabs.com with SMTP;
	7 Jun 2012 15:19:49 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57FJmI5026028;
	Thu, 7 Jun 2012 11:19:48 -0400
Date: Thu, 07 Jun 2012 11:19:48 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4FD0CEDA0200007800085A91@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> >>> Andrew Jones <drjones@redhat.com> 06/07/12 12:47 PM >>>
> >Ah, I didn't check to see what Fedora pulled in on top of 3.4. Had I
> >done that I would have immediately suspected a different patch
> >instead
> >(mm-pmd_read_atomic-fix-32bit-PAE-pmd-walk-vs-pmd_populate-SMP-race-condition.patch,
> >upstream commit 26c191788f18). We've already encountered one problem
> >with this patch for RHEL6 and fixed it. The patch F17 has, however,
> >is
> >already the "fixed" version. Now the difference between RHEL6 and
> >F17
> >though is that F17 has CONFIG_TRANSPARENT_HUGEPAGE=y for 32b guests,
> >but RHEL6 does not. So now with this patch F17 is calling
> >atomic64_read() from pmd_none_or_trans_huge_or_clear_bad().
> 
> By itself the use of atomic64_read() on page table entries shouldn't
> be
> a problem though, particularly not if what might get written is a not
> present entry (while the way atoimc64_read_cx8() works would also
> allow for values with the low bit set to be pseudo-written, but
> neither
> did that appear to be the case in at least one of the two cases where
> register dumps were provided in your bugzilla, nor should an attempt
> to write back a value that was already there cause any problem, even
> if the low bit was set).
> 
> In any case, the hypervisor log would be interesting to see. Plus -
> is
> this perhaps a rather old hypervisor running there (i.e. potentially
> lacking some fix)?

I just reproduced this on my own test box, which is running an HV
based on older code (it's RHEL 5.8). Even with
'loglvl=all guest_loglvl=all' I didn't get anything logged in
'xm dmesg'.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:20:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1SceVv-0006ew-Po; Thu, 07 Jun 2012 15:20:43 +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 1SceVu-0006ek-Io
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:20:42 +0000
Received: from [85.158.143.99:19794] by server-3.bemta-4.messagelabs.com id
	85/92-29237-9C6C0DF4; Thu, 07 Jun 2012 15:20:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339082439!22131764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6836 invoked from network); 7 Jun 2012 15:20:40 -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;
	7 Jun 2012 15:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330923600"; d="scan'208";a="197897390"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:20:30 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	11:20:30 -0400
Message-ID: <4FD0C6BD.2020403@citrix.com>
Date: Thu, 7 Jun 2012 16:20:29 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d5f631485ce7fb1f1f4f.1338462983@qabil.uk.xensource.com>
	<4FD091F0.4040209@eu.citrix.com>
In-Reply-To: <4FD091F0.4040209@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] xenalyze: decode PV_HYPERCALL_V2
	records
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 12:35, George Dunlap wrote:
> On 31/05/12 12:16, David Vrabel wrote:
>> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of
>> the older TRC_PV_HYPERCALL format.  This updated format doesn't
>> included the IP but it does include select hypercall arguments.
>>
>> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
>>
>> diff --git a/pv.h b/pv.h
>> new file mode 100644
>> --- /dev/null
>> +++ b/pv.h
> Why does this need its own file?

I would like to see Xenalyze split into more, smaller files each with
related functionality.  This is a start.

>> +static const char *grant_table_op_cmd_to_str(uint32_t cmd)
> Hmm -- this is a different style to the other lists of this type.  I 
> guess I like having it in a function.
>> +{
>> +    const char *cmd_str[] = {
>> +        "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table",
>> +        "transfer", "copy", "query_size", "unmap_and_replace",
>> +        "set_version", "get_status_frames", "get_version", "swap_grant_ref",
>> +    };
> I'm a bit wary of having stuff just in a big list like this -- it seems 
> like it makes it harder to double-check that you've gotten the right 
> match-up.  I'd prefer it look like hvm_event_handler_name[], where the 
> number is annotated with a comment from time to time.

Ok.

>> +    static char buf[32];
>> +
>> +    if (cmd<= 11)
>> +        return cmd_str[cmd];
> Instead of hardcoding the number of elements, could you use some 
> calculation involving sizeof() to get that automatically?  In any case, 
> it should be "cmd < N", rather than "cmd <= N-1" (where N is the number 
> of elements in the array).

Ok.

>> +        switch(op) {
>> +        case HYPERCALL_mmu_update:
>> +            {
> I'm not a fan of indenting a brace within a case statement -- I think 
> this is emacs' default C mode, but I prefer it the other way.   (Not 
> sure which config option sets this, though.)

Ok.

Also, this also doesn't add the event name so (null) is printed in the
summary.  I'll fix this up 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 Thu Jun 07 15:20:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1SceVv-0006ew-Po; Thu, 07 Jun 2012 15:20:43 +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 1SceVu-0006ek-Io
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:20:42 +0000
Received: from [85.158.143.99:19794] by server-3.bemta-4.messagelabs.com id
	85/92-29237-9C6C0DF4; Thu, 07 Jun 2012 15:20:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339082439!22131764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6836 invoked from network); 7 Jun 2012 15:20:40 -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;
	7 Jun 2012 15:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330923600"; d="scan'208";a="197897390"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:20:30 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	11:20:30 -0400
Message-ID: <4FD0C6BD.2020403@citrix.com>
Date: Thu, 7 Jun 2012 16:20:29 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<d5f631485ce7fb1f1f4f.1338462983@qabil.uk.xensource.com>
	<4FD091F0.4040209@eu.citrix.com>
In-Reply-To: <4FD091F0.4040209@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] xenalyze: decode PV_HYPERCALL_V2
	records
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 12:35, George Dunlap wrote:
> On 31/05/12 12:16, David Vrabel wrote:
>> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of
>> the older TRC_PV_HYPERCALL format.  This updated format doesn't
>> included the IP but it does include select hypercall arguments.
>>
>> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
>>
>> diff --git a/pv.h b/pv.h
>> new file mode 100644
>> --- /dev/null
>> +++ b/pv.h
> Why does this need its own file?

I would like to see Xenalyze split into more, smaller files each with
related functionality.  This is a start.

>> +static const char *grant_table_op_cmd_to_str(uint32_t cmd)
> Hmm -- this is a different style to the other lists of this type.  I 
> guess I like having it in a function.
>> +{
>> +    const char *cmd_str[] = {
>> +        "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table",
>> +        "transfer", "copy", "query_size", "unmap_and_replace",
>> +        "set_version", "get_status_frames", "get_version", "swap_grant_ref",
>> +    };
> I'm a bit wary of having stuff just in a big list like this -- it seems 
> like it makes it harder to double-check that you've gotten the right 
> match-up.  I'd prefer it look like hvm_event_handler_name[], where the 
> number is annotated with a comment from time to time.

Ok.

>> +    static char buf[32];
>> +
>> +    if (cmd<= 11)
>> +        return cmd_str[cmd];
> Instead of hardcoding the number of elements, could you use some 
> calculation involving sizeof() to get that automatically?  In any case, 
> it should be "cmd < N", rather than "cmd <= N-1" (where N is the number 
> of elements in the array).

Ok.

>> +        switch(op) {
>> +        case HYPERCALL_mmu_update:
>> +            {
> I'm not a fan of indenting a brace within a case statement -- I think 
> this is emacs' default C mode, but I prefer it the other way.   (Not 
> sure which config option sets this, though.)

Ok.

Also, this also doesn't add the event name so (null) is printed in the
summary.  I'll fix this up 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 Thu Jun 07 15:27:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scebp-00072z-Nj; Thu, 07 Jun 2012 15:26:49 +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 1Scebp-00072u-6b
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:26:49 +0000
Received: from [85.158.143.99:58334] by server-2.bemta-4.messagelabs.com id
	AF/41-17938-838C0DF4; Thu, 07 Jun 2012 15:26:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339082806!24746513!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22265 invoked from network); 7 Jun 2012 15:26:47 -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;
	7 Jun 2012 15:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330923600"; d="scan'208";a="197898935"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:26:46 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	11:26:46 -0400
Message-ID: <4FD0C835.4070507@citrix.com>
Date: Thu, 7 Jun 2012 16:26:45 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
	<4FD08B04.30709@eu.citrix.com>
In-Reply-To: <4FD08B04.30709@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/06/12 12:05, George Dunlap wrote:
> On 31/05/12 12:16, David Vrabel wrote:
>> Allow xenalyze to be include (at build time) plugins that can do
>> per-record actions and a summary.  These plugins can be in C or C++.
>>
>> The plugins entry points are in struct plugin and pointers to all the
>> plugins linked in xenalyze are placed in a "plugin" section so
>> plugin_init() can find them all.
>>
>> A new command line option (-p, --plugin=PLUGIN) is added to enable one
>> or more plugins.
>>
>> A sample plugin (skeleton) is included (mostly because at least one
>> plugin must be present for the build to work).
>>
>> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
> So what's the main motivation of having this plugin infrastructure?  The 
> one plugin example you have ("batch-size", patch 10) seems simple enough 
> that it should be fairly straightforward to just add as an option, with 
> not much more boilerplate than C++ already requires.
> 
> Looks like potential advantages may include:
> * Ability to use C++ language (for those who care for such things)
> * Ability to use STL for complex data structures
> * Ability to add an option like the "batch-size" plugin in a concise, 
> self-contained way

These are the main reasons.  The last is the most important.

> Potential disadvantages include:
> * An extra O(N) loop on the hot path (where N = # of enabled plugins)
> * For each enabled plugin, an extra full function call on the hot path; 
> and a C++ function at that, which (my prejudice tells me) is likely to 
> be more wasteful time and space-wise than a C function.

I'd be surprised if these had any practical performance penalty but I'll
collect some measurements.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:27:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scebp-00072z-Nj; Thu, 07 Jun 2012 15:26:49 +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 1Scebp-00072u-6b
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:26:49 +0000
Received: from [85.158.143.99:58334] by server-2.bemta-4.messagelabs.com id
	AF/41-17938-838C0DF4; Thu, 07 Jun 2012 15:26:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339082806!24746513!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22265 invoked from network); 7 Jun 2012 15:26:47 -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;
	7 Jun 2012 15:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330923600"; d="scan'208";a="197898935"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 11:26:46 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	11:26:46 -0400
Message-ID: <4FD0C835.4070507@citrix.com>
Date: Thu, 7 Jun 2012 16:26:45 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
	<4FD08B04.30709@eu.citrix.com>
In-Reply-To: <4FD08B04.30709@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/06/12 12:05, George Dunlap wrote:
> On 31/05/12 12:16, David Vrabel wrote:
>> Allow xenalyze to be include (at build time) plugins that can do
>> per-record actions and a summary.  These plugins can be in C or C++.
>>
>> The plugins entry points are in struct plugin and pointers to all the
>> plugins linked in xenalyze are placed in a "plugin" section so
>> plugin_init() can find them all.
>>
>> A new command line option (-p, --plugin=PLUGIN) is added to enable one
>> or more plugins.
>>
>> A sample plugin (skeleton) is included (mostly because at least one
>> plugin must be present for the build to work).
>>
>> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
> So what's the main motivation of having this plugin infrastructure?  The 
> one plugin example you have ("batch-size", patch 10) seems simple enough 
> that it should be fairly straightforward to just add as an option, with 
> not much more boilerplate than C++ already requires.
> 
> Looks like potential advantages may include:
> * Ability to use C++ language (for those who care for such things)
> * Ability to use STL for complex data structures
> * Ability to add an option like the "batch-size" plugin in a concise, 
> self-contained way

These are the main reasons.  The last is the most important.

> Potential disadvantages include:
> * An extra O(N) loop on the hot path (where N = # of enabled plugins)
> * For each enabled plugin, an extra full function call on the hot path; 
> and a C++ function at that, which (my prejudice tells me) is likely to 
> be more wasteful time and space-wise than a C function.

I'd be surprised if these had any practical performance penalty but I'll
collect some measurements.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scelh-0007QG-Qr; Thu, 07 Jun 2012 15:37: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 1Scelg-0007QB-LB
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:37:00 +0000
Received: from [85.158.143.35:63651] by server-2.bemta-4.messagelabs.com id
	46/2F-17938-B9AC0DF4; Thu, 07 Jun 2012 15:36:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339083419!14501156!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21686 invoked from network); 7 Jun 2012 15:36:59 -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 Jun 2012 15:36:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sceld-000JYM-H3; Thu, 07 Jun 2012 15:36:57 +0000
Date: Thu, 7 Jun 2012 16:36:57 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120607153657.GX70339@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607114031.GP70339@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 12:40 +0100 on 07 Jun (1339072831), Tim Deegan wrote:
> Hi, 
> 
> Thanks for this.
> 
> Overall, it looks like Xen is doing a few things here:
>  - nameservice for registering services and finding endpoints;
>  - ring manipulation arithmetic;
>  - copying data; and
>  - notifying endpoints. 
> 
> The shared-ring logic was able to do all of these, with a few drawbacks:
>  - The xenstore handshake stuff is really grotty;
>  - grant maps can cause zombie domains; and
>  - it doesn't do many-to-one multicast.

We've just had a discussion of this in person, and from my notes the two
things that stand out are:

 - yes, you want to do many-to-one multiplexing, in particular to 
   avoid the server needing a ring for every client; and
 - one reason not to use Xenstore is that there is only one Xenstore
   page per VM and it may not be possible to safely share it with other
   users (in particular between a BIOS/EFI user and the main OS).

The Xenstore point is understandable, and probably something that ought
to be fixed anyway -- we have seen people run into similar problems with
BIOS drivers for blkfront and netfront.

Using one ring for all clients raises the question of access control and
admission control -- in particular how do you avoid DoS from
badly-behaved clients?

And, given your concerns about sharing an OS with an uncooperative
Xenstore client, how do you handle sharing the OS with a badly behaved
v4v client?

If we _do_ need one ring with multiple writers, and therefore Xen needs
to arbitrate writes, there's still room for the policy-based parts
(controlling connection setup, for example) to live outside the
hypervisor, openvswitch-style.

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 Jun 07 15:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scelh-0007QG-Qr; Thu, 07 Jun 2012 15:37: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 1Scelg-0007QB-LB
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:37:00 +0000
Received: from [85.158.143.35:63651] by server-2.bemta-4.messagelabs.com id
	46/2F-17938-B9AC0DF4; Thu, 07 Jun 2012 15:36:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339083419!14501156!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21686 invoked from network); 7 Jun 2012 15:36:59 -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 Jun 2012 15:36:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sceld-000JYM-H3; Thu, 07 Jun 2012 15:36:57 +0000
Date: Thu, 7 Jun 2012 16:36:57 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120607153657.GX70339@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607114031.GP70339@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 12:40 +0100 on 07 Jun (1339072831), Tim Deegan wrote:
> Hi, 
> 
> Thanks for this.
> 
> Overall, it looks like Xen is doing a few things here:
>  - nameservice for registering services and finding endpoints;
>  - ring manipulation arithmetic;
>  - copying data; and
>  - notifying endpoints. 
> 
> The shared-ring logic was able to do all of these, with a few drawbacks:
>  - The xenstore handshake stuff is really grotty;
>  - grant maps can cause zombie domains; and
>  - it doesn't do many-to-one multicast.

We've just had a discussion of this in person, and from my notes the two
things that stand out are:

 - yes, you want to do many-to-one multiplexing, in particular to 
   avoid the server needing a ring for every client; and
 - one reason not to use Xenstore is that there is only one Xenstore
   page per VM and it may not be possible to safely share it with other
   users (in particular between a BIOS/EFI user and the main OS).

The Xenstore point is understandable, and probably something that ought
to be fixed anyway -- we have seen people run into similar problems with
BIOS drivers for blkfront and netfront.

Using one ring for all clients raises the question of access control and
admission control -- in particular how do you avoid DoS from
badly-behaved clients?

And, given your concerns about sharing an OS with an uncooperative
Xenstore client, how do you handle sharing the OS with a badly behaved
v4v client?

If we _do_ need one ring with multiple writers, and therefore Xen needs
to arbitrate writes, there's still room for the policy-based parts
(controlling connection setup, for example) to live outside the
hypervisor, openvswitch-style.

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 Jun 07 15:44:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScesV-0007ho-Bs; Thu, 07 Jun 2012 15:44:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScesU-0007he-HO
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:44:02 +0000
Received: from [85.158.143.35:39349] by server-3.bemta-4.messagelabs.com id
	50/F3-29237-14CC0DF4; Thu, 07 Jun 2012 15:44:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339083839!13407541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5564 invoked from network); 7 Jun 2012 15:44:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 15:44:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12890412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 15:43:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 16:43:59 +0100
Date: Thu, 7 Jun 2012 16:43:42 +0100
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: <20120607124606.GT70339@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1206071643360.2415@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120607124606.GT70339@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
 VCPUs not currently running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 7 Jun 2012, Tim Deegan wrote:
> At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> > +static void gic_restore_pending_irqs(struct vcpu *v)
> > +{
> > +    int i;
> > +    struct pending_irq *p;
> > +
> > +    /* check for new pending irqs */
> > +    if ( list_empty(&v->arch.vgic.lr_pending) )
> > +        return;
> > +
> > +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> > +    {
> > +        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
> > +        if ( i < nr_lrs )
> > +        {
> > +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +            list_del_init(&p->lr_queue);
> > +            set_bit(i, &gic.lr_mask);
> > +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> > +                set_bit(i, &gic.event_mask);
> > +        } else
> > +        {
> > +            return;
> > +        }
> 
> This is a bit ugly - maybe "if ( i >= nr_lrs ) return" above and don't
> indent the block?
> 

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 Jun 07 15:44:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScesV-0007ho-Bs; Thu, 07 Jun 2012 15:44:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScesU-0007he-HO
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:44:02 +0000
Received: from [85.158.143.35:39349] by server-3.bemta-4.messagelabs.com id
	50/F3-29237-14CC0DF4; Thu, 07 Jun 2012 15:44:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339083839!13407541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5564 invoked from network); 7 Jun 2012 15:44:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 15:44:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12890412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 15:43:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 16:43:59 +0100
Date: Thu, 7 Jun 2012 16:43:42 +0100
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: <20120607124606.GT70339@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1206071643360.2415@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120607124606.GT70339@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
 VCPUs not currently running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 7 Jun 2012, Tim Deegan wrote:
> At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> > +static void gic_restore_pending_irqs(struct vcpu *v)
> > +{
> > +    int i;
> > +    struct pending_irq *p;
> > +
> > +    /* check for new pending irqs */
> > +    if ( list_empty(&v->arch.vgic.lr_pending) )
> > +        return;
> > +
> > +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> > +    {
> > +        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
> > +        if ( i < nr_lrs )
> > +        {
> > +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +            list_del_init(&p->lr_queue);
> > +            set_bit(i, &gic.lr_mask);
> > +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> > +                set_bit(i, &gic.event_mask);
> > +        } else
> > +        {
> > +            return;
> > +        }
> 
> This is a bit ugly - maybe "if ( i >= nr_lrs ) return" above and don't
> indent the block?
> 

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 Jun 07 15:44:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scesf-0007iu-OR; Thu, 07 Jun 2012 15:44:13 +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 1Scese-0007ik-Q4
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:44:12 +0000
Received: from [193.109.254.147:56202] by server-3.bemta-14.messagelabs.com id
	0C/05-05653-B4CC0DF4; Thu, 07 Jun 2012 15:44:11 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339083850!3466174!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY4OTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12825 invoked from network); 7 Jun 2012 15:44:11 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-10.tower-27.messagelabs.com with SMTP;
	7 Jun 2012 15:44:11 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57Fi9EU011631;
	Thu, 7 Jun 2012 11:44:09 -0400
Date: Thu, 07 Jun 2012 11:44:09 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> > In any case, the hypervisor log would be interesting to see. Plus -
> > is
> > this perhaps a rather old hypervisor running there (i.e.
> > potentially
> > lacking some fix)?
> 
> I just reproduced this on my own test box, which is running an HV
> based on older code (it's RHEL 5.8). Even with
> 'loglvl=all guest_loglvl=all' I didn't get anything logged in
> 'xm dmesg'.

I don't have an later hypervisor setup for testing, but it'd
be nice to know if guests work on them. If so, then maybe RHEL5
and EC2 need to look at Xen c/s 17498 and/or others.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:44:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scesf-0007iu-OR; Thu, 07 Jun 2012 15:44:13 +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 1Scese-0007ik-Q4
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:44:12 +0000
Received: from [193.109.254.147:56202] by server-3.bemta-14.messagelabs.com id
	0C/05-05653-B4CC0DF4; Thu, 07 Jun 2012 15:44:11 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339083850!3466174!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY4OTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12825 invoked from network); 7 Jun 2012 15:44:11 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-10.tower-27.messagelabs.com with SMTP;
	7 Jun 2012 15:44:11 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q57Fi9EU011631;
	Thu, 7 Jun 2012 11:44:09 -0400
Date: Thu, 07 Jun 2012 11:44:09 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> > In any case, the hypervisor log would be interesting to see. Plus -
> > is
> > this perhaps a rather old hypervisor running there (i.e.
> > potentially
> > lacking some fix)?
> 
> I just reproduced this on my own test box, which is running an HV
> based on older code (it's RHEL 5.8). Even with
> 'loglvl=all guest_loglvl=all' I didn't get anything logged in
> 'xm dmesg'.

I don't have an later hypervisor setup for testing, but it'd
be nice to know if guests work on them. If so, then maybe RHEL5
and EC2 need to look at Xen c/s 17498 and/or others.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:44:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scet1-0007mh-5a; Thu, 07 Jun 2012 15:44:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Scesz-0007mK-Rb
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:44:34 +0000
Received: from [85.158.139.83:13931] by server-2.bemta-5.messagelabs.com id
	6D/FC-20827-06CC0DF4; Thu, 07 Jun 2012 15:44:32 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339083871!18652468!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22094 invoked from network); 7 Jun 2012 15:44:32 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 15:44:32 -0000
Received: by yhoo21 with SMTP id o21so611250yho.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 08:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=MUEgVvVdAUIGqf+CDIkY6rDrr+aw53afoeszjmI61kQ=;
	b=Lo2x5YDpF62Ujx6+3Hq9pcrKiUQSU4637Gq/TDKmzI79YimSQL+s/u+K9sxIwNbd8a
	LjZJS/RjB1iyYfYYzcqOOQxi6vJF0hena9nLdZ3KRYl5der+VCiEPsMN915A4k3edORK
	czMarr8g7soehd+N27s1DC3eI3Af2jAqm1foCYJ5BNu/zd74svCdut0QCCMLpcJ5raZc
	mU1iPBJEwc9k73jVTOhPWza7l7I4lciu+kNYCctYqk5kReuwl//CPdsqizwE9uByOcLC
	Nb11O3Ns0lSP1R8VAvpd7PYgcVY6MELL+yCOYUBXMbX0NUy/7CdHHd3vGuUkCTKaaaa9
	uD9g==
Received: by 10.101.11.18 with SMTP id o18mr741290ani.14.1339083871112;
	Thu, 07 Jun 2012 08:44:31 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id y21sm11218262yhd.5.2012.06.07.08.44.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 08:44:30 -0700 (PDT)
Message-ID: <4FD0CC3F.7020108@gmail.com>
Date: Thu, 07 Jun 2012 11:43:59 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
CC: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FC7F89F.9010203@gmail.com>
	<1338531918.14877.35.camel@dagon.hellion.org.uk>
In-Reply-To: <1338531918.14877.35.camel@dagon.hellion.org.uk>
Subject: Re: [Xen-devel] Error in compiling latest Xen 4.2-Unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 6/1/2012 2:25 AM, Ian Campbell wrote:
> On Fri, 2012-06-01 at 00:02 +0100, cyberhawk001@gmail.com wrote:
>> SO, possibly the GCC compiler is at fault and was wondering what
>> version the Xen-devel team uses?
> This issue is indeed a compiler related one.
>
> The developers use a wide variety of compilers, including ones which
> exhibit this behaviour. A few patches have been posted to xen-devel
> (e.g.
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01856.html) but
> we are still working on the final fix.
>
> As a workaround in the meantime you could either apply the patch linked
> above locally or remove the entirety of the "case -1" that is causing
> the warnings.
>
> Thanks for continuing to be patient.
>
> Ian.
>
>

Just wanted to mention that the latest version of xen-unstable.hg, rev- 
25459, (as of today) is able to compile perfectly on Debian Wheezy, with 
no errors or anything.

SO, everyone in the Xen-devel team, You guys are all just plain awesome, 
and thanks for fixing the compile issues... :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:44:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scet1-0007mh-5a; Thu, 07 Jun 2012 15:44:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Scesz-0007mK-Rb
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 15:44:34 +0000
Received: from [85.158.139.83:13931] by server-2.bemta-5.messagelabs.com id
	6D/FC-20827-06CC0DF4; Thu, 07 Jun 2012 15:44:32 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339083871!18652468!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22094 invoked from network); 7 Jun 2012 15:44:32 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 15:44:32 -0000
Received: by yhoo21 with SMTP id o21so611250yho.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 08:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=MUEgVvVdAUIGqf+CDIkY6rDrr+aw53afoeszjmI61kQ=;
	b=Lo2x5YDpF62Ujx6+3Hq9pcrKiUQSU4637Gq/TDKmzI79YimSQL+s/u+K9sxIwNbd8a
	LjZJS/RjB1iyYfYYzcqOOQxi6vJF0hena9nLdZ3KRYl5der+VCiEPsMN915A4k3edORK
	czMarr8g7soehd+N27s1DC3eI3Af2jAqm1foCYJ5BNu/zd74svCdut0QCCMLpcJ5raZc
	mU1iPBJEwc9k73jVTOhPWza7l7I4lciu+kNYCctYqk5kReuwl//CPdsqizwE9uByOcLC
	Nb11O3Ns0lSP1R8VAvpd7PYgcVY6MELL+yCOYUBXMbX0NUy/7CdHHd3vGuUkCTKaaaa9
	uD9g==
Received: by 10.101.11.18 with SMTP id o18mr741290ani.14.1339083871112;
	Thu, 07 Jun 2012 08:44:31 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id y21sm11218262yhd.5.2012.06.07.08.44.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 08:44:30 -0700 (PDT)
Message-ID: <4FD0CC3F.7020108@gmail.com>
Date: Thu, 07 Jun 2012 11:43:59 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
CC: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FC7F89F.9010203@gmail.com>
	<1338531918.14877.35.camel@dagon.hellion.org.uk>
In-Reply-To: <1338531918.14877.35.camel@dagon.hellion.org.uk>
Subject: Re: [Xen-devel] Error in compiling latest Xen 4.2-Unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 6/1/2012 2:25 AM, Ian Campbell wrote:
> On Fri, 2012-06-01 at 00:02 +0100, cyberhawk001@gmail.com wrote:
>> SO, possibly the GCC compiler is at fault and was wondering what
>> version the Xen-devel team uses?
> This issue is indeed a compiler related one.
>
> The developers use a wide variety of compilers, including ones which
> exhibit this behaviour. A few patches have been posted to xen-devel
> (e.g.
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01856.html) but
> we are still working on the final fix.
>
> As a workaround in the meantime you could either apply the patch linked
> above locally or remove the entirety of the "case -1" that is causing
> the warnings.
>
> Thanks for continuing to be patient.
>
> Ian.
>
>

Just wanted to mention that the latest version of xen-unstable.hg, rev- 
25459, (as of today) is able to compile perfectly on Debian Wheezy, with 
no errors or anything.

SO, everyone in the Xen-devel team, You guys are all just plain awesome, 
and thanks for fixing the compile issues... :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scevf-00082J-On; Thu, 07 Jun 2012 15:47:19 +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 1Sceve-00082D-M4
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:47:18 +0000
Received: from [85.158.143.99:9451] by server-3.bemta-4.messagelabs.com id
	4B/98-29237-60DC0DF4; Thu, 07 Jun 2012 15:47:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339084037!31223416!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7726 invoked from network); 7 Jun 2012 15:47:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 15:47:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12890587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 15:47:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 16:47:16 +0100
Date: Thu, 7 Jun 2012 16:47:00 +0100
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: <20120607124749.GU70339@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1206071646530.2415@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<20120607124749.GU70339@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/5] xen/arm: multiple guests support in the
 GIC and VGIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Tim Deegan wrote:
> At 12:20 +0100 on 06 Jun (1338985240), Stefano Stabellini wrote:
> > Hi all,
> > this patch series fixes the GIC, VGIC and vtimer issues that caused dom1
> > to hang, as described by Ian in
> > http://marc.info/?l=xen-devel&m=133856539418794.
> > 
> > With this patch series applied on top of Ian's, dom1 boots up to:
> > 
> > VFS: Cannot open root device "(null)" or unknown-block(2,0)
> > 
> 
> I had one style nit on patch 3; you can add my Ack to all the others
> (though IanC has a better grasp of the vgic stuff than I do and may
> contradict me).

great, thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 15:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 15: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 1Scevf-00082J-On; Thu, 07 Jun 2012 15:47:19 +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 1Sceve-00082D-M4
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 15:47:18 +0000
Received: from [85.158.143.99:9451] by server-3.bemta-4.messagelabs.com id
	4B/98-29237-60DC0DF4; Thu, 07 Jun 2012 15:47:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339084037!31223416!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7726 invoked from network); 7 Jun 2012 15:47:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 15:47:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="12890587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 15:47:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 16:47:16 +0100
Date: Thu, 7 Jun 2012 16:47:00 +0100
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: <20120607124749.GU70339@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1206071646530.2415@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<20120607124749.GU70339@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/5] xen/arm: multiple guests support in the
 GIC and VGIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Tim Deegan wrote:
> At 12:20 +0100 on 06 Jun (1338985240), Stefano Stabellini wrote:
> > Hi all,
> > this patch series fixes the GIC, VGIC and vtimer issues that caused dom1
> > to hang, as described by Ian in
> > http://marc.info/?l=xen-devel&m=133856539418794.
> > 
> > With this patch series applied on top of Ian's, dom1 boots up to:
> > 
> > VFS: Cannot open root device "(null)" or unknown-block(2,0)
> > 
> 
> I had one style nit on patch 3; you can add my Ack to all the others
> (though IanC has a better grasp of the vgic stuff than I do and may
> contradict me).

great, thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:03:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfAt-0000Qn-At; Thu, 07 Jun 2012 16:03:03 +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 1ScfAr-0000Qi-ML
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:03:01 +0000
Received: from [193.109.254.147:54126] by server-11.bemta-14.messagelabs.com
	id 25/A9-02727-5B0D0DF4; Thu, 07 Jun 2012 16:03:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339084979!8652844!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7383 invoked from network); 7 Jun 2012 16:03:00 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:03:00 -0000
Received: by qcsp15 with SMTP id p15so504276qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 09:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=axw2BB/OoMMUm1GJAmjrPkKWKPA9YNx4Msk6dpLHQYY=;
	b=HWTlIuSSe+Wm4diKf/POW5gE38sUlQvJmuI81Rtzx8sb1r5vBt+Gn0eqbW/Fe2KpBD
	68XM9mLaIej5prDii9N6VJDtt+4oQwAsfFXZoPNqJSCzs2hLpMc+uY9p+ef9Tm361366
	SiUb7SKPDSgJAFa+5k/noxIkPgvhxTkZDXwZLY/EFv38K13uSZNHhBAcpzs51/vKaIRY
	fyB8b/aljyO9gzV9u51ZfaucIm03wpGPcqiHJGjT0ezHbXYpPQvmV6Cs94TFcnWOOOuf
	T7D3h+RQJH47ke7Yir5nnfrCpllMRPhO/wSrvAzWWUTMtecLzudeoCt86nCwMtXqLYWp
	unRw==
MIME-Version: 1.0
Received: by 10.224.181.83 with SMTP id bx19mr3371258qab.79.1339084978509;
	Thu, 07 Jun 2012 09:02:58 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 7 Jun 2012 09:02:58 -0700 (PDT)
In-Reply-To: <4FD0C835.4070507@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
	<4FD08B04.30709@eu.citrix.com> <4FD0C835.4070507@citrix.com>
Date: Thu, 7 Jun 2012 17:02:58 +0100
X-Google-Sender-Auth: -ihppfkG04jG-tLFRQWIIfpfJok
Message-ID: <CAFLBxZZZTkFt2ZEmukT36287gqgXBq1JsPqmCuxxxGO4R9jziw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 7, 2012 at 4:26 PM, David Vrabel <david.vrabel@citrix.com> wrot=
e:
> On 07/06/12 12:05, George Dunlap wrote:
>> On 31/05/12 12:16, David Vrabel wrote:
>>> Allow xenalyze to be include (at build time) plugins that can do
>>> per-record actions and a summary. =A0These plugins can be in C or C++.
>>>
>>> The plugins entry points are in struct plugin and pointers to all the
>>> plugins linked in xenalyze are placed in a "plugin" section so
>>> plugin_init() can find them all.
>>>
>>> A new command line option (-p, --plugin=3DPLUGIN) is added to enable one
>>> or more plugins.
>>>
>>> A sample plugin (skeleton) is included (mostly because at least one
>>> plugin must be present for the build to work).
>>>
>>> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
>> So what's the main motivation of having this plugin infrastructure? =A0T=
he
>> one plugin example you have ("batch-size", patch 10) seems simple enough
>> that it should be fairly straightforward to just add as an option, with
>> not much more boilerplate than C++ already requires.
>>
>> Looks like potential advantages may include:
>> * Ability to use C++ language (for those who care for such things)
>> * Ability to use STL for complex data structures
>> * Ability to add an option like the "batch-size" plugin in a concise,
>> self-contained way
>
> These are the main reasons. =A0The last is the most important.
>
>> Potential disadvantages include:
>> * An extra O(N) loop on the hot path (where N =3D # of enabled plugins)
>> * For each enabled plugin, an extra full function call on the hot path;
>> and a C++ function at that, which (my prejudice tells me) is likely to
>> be more wasteful time and space-wise than a C function.
>
> I'd be surprised if these had any practical performance penalty but I'll
> collect some measurements.

Thanks.  I was going to mention but forgot: about 6 months ago I did a
week's worth of work optimizing xenalyze.  At the beginning of the
week, it was taking almost 2 minutes to do a "summary" analysis on a
700MiB file; after my optimizations, it took 10s.  In that case things
as simple as doing an extraneous integer division per record had a
measurable impact.  So I'm not just being paranoid.  Going from "I can
wait 10s for this to complete" to "I'm going to switch to a different
task" can have a pretty big impact on my working effectiveness, at
least. :-)

I also have a set of patches that speed up "xenalyze -a", but that's a
lot more tricky and invasive, as with a 700MiB file you're actually
generating and writing to disk more than 1GiB of data.  The solution
there is mainly to use bespoke printing routines, rather than the libc
ones.  Using a plugin infrastructure and going to more indirection /
abstraction seems like it would be going in the opposite direction.
:-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:03:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfAt-0000Qn-At; Thu, 07 Jun 2012 16:03:03 +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 1ScfAr-0000Qi-ML
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:03:01 +0000
Received: from [193.109.254.147:54126] by server-11.bemta-14.messagelabs.com
	id 25/A9-02727-5B0D0DF4; Thu, 07 Jun 2012 16:03:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339084979!8652844!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7383 invoked from network); 7 Jun 2012 16:03:00 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:03:00 -0000
Received: by qcsp15 with SMTP id p15so504276qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 09:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=axw2BB/OoMMUm1GJAmjrPkKWKPA9YNx4Msk6dpLHQYY=;
	b=HWTlIuSSe+Wm4diKf/POW5gE38sUlQvJmuI81Rtzx8sb1r5vBt+Gn0eqbW/Fe2KpBD
	68XM9mLaIej5prDii9N6VJDtt+4oQwAsfFXZoPNqJSCzs2hLpMc+uY9p+ef9Tm361366
	SiUb7SKPDSgJAFa+5k/noxIkPgvhxTkZDXwZLY/EFv38K13uSZNHhBAcpzs51/vKaIRY
	fyB8b/aljyO9gzV9u51ZfaucIm03wpGPcqiHJGjT0ezHbXYpPQvmV6Cs94TFcnWOOOuf
	T7D3h+RQJH47ke7Yir5nnfrCpllMRPhO/wSrvAzWWUTMtecLzudeoCt86nCwMtXqLYWp
	unRw==
MIME-Version: 1.0
Received: by 10.224.181.83 with SMTP id bx19mr3371258qab.79.1339084978509;
	Thu, 07 Jun 2012 09:02:58 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 7 Jun 2012 09:02:58 -0700 (PDT)
In-Reply-To: <4FD0C835.4070507@citrix.com>
References: <patchbomb.1338462976@qabil.uk.xensource.com>
	<794833ac346b80acbed5.1338462985@qabil.uk.xensource.com>
	<4FD08B04.30709@eu.citrix.com> <4FD0C835.4070507@citrix.com>
Date: Thu, 7 Jun 2012 17:02:58 +0100
X-Google-Sender-Auth: -ihppfkG04jG-tLFRQWIIfpfJok
Message-ID: <CAFLBxZZZTkFt2ZEmukT36287gqgXBq1JsPqmCuxxxGO4R9jziw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 7, 2012 at 4:26 PM, David Vrabel <david.vrabel@citrix.com> wrot=
e:
> On 07/06/12 12:05, George Dunlap wrote:
>> On 31/05/12 12:16, David Vrabel wrote:
>>> Allow xenalyze to be include (at build time) plugins that can do
>>> per-record actions and a summary. =A0These plugins can be in C or C++.
>>>
>>> The plugins entry points are in struct plugin and pointers to all the
>>> plugins linked in xenalyze are placed in a "plugin" section so
>>> plugin_init() can find them all.
>>>
>>> A new command line option (-p, --plugin=3DPLUGIN) is added to enable one
>>> or more plugins.
>>>
>>> A sample plugin (skeleton) is included (mostly because at least one
>>> plugin must be present for the build to work).
>>>
>>> Signed-off-by: David Vrabel<david.vrabel@citrix.com>
>> So what's the main motivation of having this plugin infrastructure? =A0T=
he
>> one plugin example you have ("batch-size", patch 10) seems simple enough
>> that it should be fairly straightforward to just add as an option, with
>> not much more boilerplate than C++ already requires.
>>
>> Looks like potential advantages may include:
>> * Ability to use C++ language (for those who care for such things)
>> * Ability to use STL for complex data structures
>> * Ability to add an option like the "batch-size" plugin in a concise,
>> self-contained way
>
> These are the main reasons. =A0The last is the most important.
>
>> Potential disadvantages include:
>> * An extra O(N) loop on the hot path (where N =3D # of enabled plugins)
>> * For each enabled plugin, an extra full function call on the hot path;
>> and a C++ function at that, which (my prejudice tells me) is likely to
>> be more wasteful time and space-wise than a C function.
>
> I'd be surprised if these had any practical performance penalty but I'll
> collect some measurements.

Thanks.  I was going to mention but forgot: about 6 months ago I did a
week's worth of work optimizing xenalyze.  At the beginning of the
week, it was taking almost 2 minutes to do a "summary" analysis on a
700MiB file; after my optimizations, it took 10s.  In that case things
as simple as doing an extraneous integer division per record had a
measurable impact.  So I'm not just being paranoid.  Going from "I can
wait 10s for this to complete" to "I'm going to switch to a different
task" can have a pretty big impact on my working effectiveness, at
least. :-)

I also have a set of patches that speed up "xenalyze -a", but that's a
lot more tricky and invasive, as with a 700MiB file you're actually
generating and writing to disk more than 1GiB of data.  The solution
there is mainly to use bespoke printing routines, rather than the libc
ones.  Using a plugin infrastructure and going to more indirection /
abstraction seems like it would be going in the opposite direction.
:-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScfCd-0000Xz-Rd; Thu, 07 Jun 2012 16:04: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 1ScfCb-0000Xn-Q9
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:04:49 +0000
Received: from [85.158.143.35:26352] by server-1.bemta-4.messagelabs.com id
	F4/A9-10042-121D0DF4; Thu, 07 Jun 2012 16:04:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339085087!19249777!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1953 invoked from network); 7 Jun 2012 16:04:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 16:04:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57G3nOH001674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 16:03:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q57G3lDS006512
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 16:03:48 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
	q57G3k0v022289; Thu, 7 Jun 2012 11:03:46 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 09:03:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6CF504030D; Thu,  7 Jun 2012 11:56:47 -0400 (EDT)
Date: Thu, 7 Jun 2012 11:56:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Message-ID: <20120607155647.GO9472@phenom.dumpdata.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
	<20120607103355.GA21339@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607103355.GA21339@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergio Gelato <Sergio.Gelato@astro.su.se>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 12:33:55PM +0200, Andrea Arcangeli wrote:
> On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote:
> > Sergio Gelato wrote[1]:
> > 
> > >                          That 3.4.1-1~experimental.1 build
> > > (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux)
> > > is even less well-behaved under Xen: I'm getting a kernel OOPS at
> > > EIP: [<c1168e54>] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c
> > > The top of the trace message unfortunately scrolled off the console before I
> > > could see it, and the message doesn't have time to make it to syslog (either
> > > local or remote).
> > [...]
> > > Non-Xen boots proceed normally.
> > 
> > Yeah, apparently[2] that's caused by
> > 
> > 	commit 26c191788f18
> > 	Author: Andrea Arcangeli <aarcange@redhat.com>
> > 	Date:   Tue May 29 15:06:49 2012 -0700
> > 
> > 	    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
> > 
> > which was also included in Debian kernel 3.2.19-1.
> > 
> > [1] http://bugs.debian.org/676360
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4
> 
> Oops, sorry I didn't imagine atomic64_read on a pmd would trip.

Hmm, so it looks like it used to do this:

 pmd = pmd_offset(pud, addr);
 ..
 pmd_t pmdval = *pmd;

but now you do:
 pmd_t ret = (pmd_val)((u32)*tmp);
 ret |= (*tmp+1) << 32;

which would read the low first and then the high one next
(or is the other way around?).  The 'pmd_offset' beforehand
manufactures the pmd using the PFN to MFN lookup tree (so
that there aren't any hypercall or traps).

Hm, with your change, you are still looking at the 'pmd'
and its contents, except that you are reading the low and
then the high part. Why that would trip the hypervisor
is not clear to me. Perhaps in the past it only read the
low bits?

If there was Xen hypervisor log that might give some ideas. Is
there any chance that the Linode folks could send that over?

> 
> Unfortunately to support pagetable walking with mmap_sem hold for
> reading, we need an atomic read on 32bit PAE if
> CONFIG_TRANSPARENT_HUGEPAGE=y.
> 
> The only case requiring this is 32bit PAE with
> CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set
> CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work
> around this as I optimized the code in a way to avoid an expensive
> cmpxchg8b.

Ah, by just skipping the thing if the low bits are zero.
> 
> I guess if Xen can't be updated to handle an atomic64_read on a pmd in
> the guest, we can add a pmd_read paravirt op? Or if we don't want to
> break the paravirt interface a loop like gup_fast with irq disabled
> should also work but looping + local_irq_disable()/enable() sounded
> worse and more complex than a atomic64_read (gup fast already disables
> irqs because it doesn't hold the mmap_sem so it's a different cost

I am not really sure what is at foot. It sounds like the hypervisor
didn't like somebody reading the high and low bit, but isn't the
pmdval_t still 64-bit ? So I would have thought this would
have been triggered? Or is that the code on pmd_val never actually
read the high bits (before your addition to the atomic_read?)?

> looping there). AFIK Xen disables THP during boot, so a check on THP
> being enabled and falling back in the THP=n version of
> pmd_read_atomic, would also be safe, but it's not so nice to do it
> with a runtime check.

The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora
17 dom0. So it looks like this is reading high part is fixed on the newer
hypervisors, but now with the older ones. And the older one is Amazon EC2
so some .. hack to workaround older hypervisors could be added.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScfCd-0000Xz-Rd; Thu, 07 Jun 2012 16:04: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 1ScfCb-0000Xn-Q9
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:04:49 +0000
Received: from [85.158.143.35:26352] by server-1.bemta-4.messagelabs.com id
	F4/A9-10042-121D0DF4; Thu, 07 Jun 2012 16:04:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339085087!19249777!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1953 invoked from network); 7 Jun 2012 16:04:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 16:04:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57G3nOH001674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 16:03:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q57G3lDS006512
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 16:03:48 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
	q57G3k0v022289; Thu, 7 Jun 2012 11:03:46 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 09:03:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6CF504030D; Thu,  7 Jun 2012 11:56:47 -0400 (EDT)
Date: Thu, 7 Jun 2012 11:56:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Message-ID: <20120607155647.GO9472@phenom.dumpdata.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
	<20120607103355.GA21339@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607103355.GA21339@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergio Gelato <Sergio.Gelato@astro.su.se>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 12:33:55PM +0200, Andrea Arcangeli wrote:
> On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote:
> > Sergio Gelato wrote[1]:
> > 
> > >                          That 3.4.1-1~experimental.1 build
> > > (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux)
> > > is even less well-behaved under Xen: I'm getting a kernel OOPS at
> > > EIP: [<c1168e54>] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c
> > > The top of the trace message unfortunately scrolled off the console before I
> > > could see it, and the message doesn't have time to make it to syslog (either
> > > local or remote).
> > [...]
> > > Non-Xen boots proceed normally.
> > 
> > Yeah, apparently[2] that's caused by
> > 
> > 	commit 26c191788f18
> > 	Author: Andrea Arcangeli <aarcange@redhat.com>
> > 	Date:   Tue May 29 15:06:49 2012 -0700
> > 
> > 	    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
> > 
> > which was also included in Debian kernel 3.2.19-1.
> > 
> > [1] http://bugs.debian.org/676360
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4
> 
> Oops, sorry I didn't imagine atomic64_read on a pmd would trip.

Hmm, so it looks like it used to do this:

 pmd = pmd_offset(pud, addr);
 ..
 pmd_t pmdval = *pmd;

but now you do:
 pmd_t ret = (pmd_val)((u32)*tmp);
 ret |= (*tmp+1) << 32;

which would read the low first and then the high one next
(or is the other way around?).  The 'pmd_offset' beforehand
manufactures the pmd using the PFN to MFN lookup tree (so
that there aren't any hypercall or traps).

Hm, with your change, you are still looking at the 'pmd'
and its contents, except that you are reading the low and
then the high part. Why that would trip the hypervisor
is not clear to me. Perhaps in the past it only read the
low bits?

If there was Xen hypervisor log that might give some ideas. Is
there any chance that the Linode folks could send that over?

> 
> Unfortunately to support pagetable walking with mmap_sem hold for
> reading, we need an atomic read on 32bit PAE if
> CONFIG_TRANSPARENT_HUGEPAGE=y.
> 
> The only case requiring this is 32bit PAE with
> CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set
> CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work
> around this as I optimized the code in a way to avoid an expensive
> cmpxchg8b.

Ah, by just skipping the thing if the low bits are zero.
> 
> I guess if Xen can't be updated to handle an atomic64_read on a pmd in
> the guest, we can add a pmd_read paravirt op? Or if we don't want to
> break the paravirt interface a loop like gup_fast with irq disabled
> should also work but looping + local_irq_disable()/enable() sounded
> worse and more complex than a atomic64_read (gup fast already disables
> irqs because it doesn't hold the mmap_sem so it's a different cost

I am not really sure what is at foot. It sounds like the hypervisor
didn't like somebody reading the high and low bit, but isn't the
pmdval_t still 64-bit ? So I would have thought this would
have been triggered? Or is that the code on pmd_val never actually
read the high bits (before your addition to the atomic_read?)?

> looping there). AFIK Xen disables THP during boot, so a check on THP
> being enabled and falling back in the THP=n version of
> pmd_read_atomic, would also be safe, but it's not so nice to do it
> with a runtime check.

The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora
17 dom0. So it looks like this is reading high part is fixed on the newer
hypervisors, but now with the older ones. And the older one is Amazon EC2
so some .. hack to workaround older hypervisors could be added.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:05:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfDG-0000cG-G4; Thu, 07 Jun 2012 16:05: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 1ScfDF-0000c3-5A
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:05:29 +0000
Received: from [85.158.138.51:13475] by server-10.bemta-3.messagelabs.com id
	28/B3-06494-841D0DF4; Thu, 07 Jun 2012 16:05:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339085126!28441623!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12493 invoked from network); 7 Jun 2012 16:05:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 16:05:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57G5Kfw003430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 16:05:21 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
	q57G5F7q009643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 16:05:16 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
	q57G5CN9001032; Thu, 7 Jun 2012 11:05:12 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 09:05:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6F05C4030D; Thu,  7 Jun 2012 11:58:14 -0400 (EDT)
Date: Thu, 7 Jun 2012 11:58:14 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "aorchis@gmail.com" <aorchis@gmail.com>, ben@guthro.net
Message-ID: <20120607155814.GP9472@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 07, 2012 at 08:49:37PM +1000, aorchis@gmail.com wrote:
> On Wed, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
> >> Hi Jeremy and Konrad,
> >
> > CC-ing xen-devel.
> >
> >>
> >> Basically the driver NVIDIA provided is a binary blob and recent
> >> versions does not work with the PAT layout of XEN so it falls back to
> >> MTRR to provide write combining (please correct me if I'm wrong).
> >
> > OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
> > NVidia driver? I've had reports that it works OK.
> =

> I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
> I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
> (v302) but both didn't work.
> =

> When the nvidia module is loaded, it prints out an error message:
> "NVRM: PAT configuration unsupported, falling back to MTRRs."
> =

> When I launch Xorg, the screen turns blank then the monitors powered down=
 and my
> box hard crashed, I had to hold the power button to turn it off.

Ok, lets CC Ben - he might have more up-to-date information. Also
you might want to setup a serial console to capture the kernel to see
where it crashes.

> =

> This only happens in dom0 under XEN, if I run my dom0 by itself then
> the nvidia module loads fine.
> =

> >> However there is no MTRR support on XEN so the driver hard crashed my
> >> machine (I can't ssh into the box anymore).
> >>
> >> Moreover, there is problem with the open source driver 'nouveau' for
> >> NVIDIA card =A0(also has something to do with PAT layout of XEN) which
> >> causes memory corruption.
> >
> > Huh? Can you point me to a bugzilla please? There was a corruption
> > issue where you can pass in 'nopat' on the command line.
> =

> Yes, that is the issue I was referring to, I had to pass "nopat" to
> GRUB in order
> to fix it.

Ok, so there is afall back for you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:05:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfDG-0000cG-G4; Thu, 07 Jun 2012 16:05: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 1ScfDF-0000c3-5A
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:05:29 +0000
Received: from [85.158.138.51:13475] by server-10.bemta-3.messagelabs.com id
	28/B3-06494-841D0DF4; Thu, 07 Jun 2012 16:05:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339085126!28441623!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12493 invoked from network); 7 Jun 2012 16:05:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 16:05:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57G5Kfw003430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 16:05:21 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
	q57G5F7q009643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 16:05:16 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
	q57G5CN9001032; Thu, 7 Jun 2012 11:05:12 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 09:05:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6F05C4030D; Thu,  7 Jun 2012 11:58:14 -0400 (EDT)
Date: Thu, 7 Jun 2012 11:58:14 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "aorchis@gmail.com" <aorchis@gmail.com>, ben@guthro.net
Message-ID: <20120607155814.GP9472@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 07, 2012 at 08:49:37PM +1000, aorchis@gmail.com wrote:
> On Wed, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
> >> Hi Jeremy and Konrad,
> >
> > CC-ing xen-devel.
> >
> >>
> >> Basically the driver NVIDIA provided is a binary blob and recent
> >> versions does not work with the PAT layout of XEN so it falls back to
> >> MTRR to provide write combining (please correct me if I'm wrong).
> >
> > OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
> > NVidia driver? I've had reports that it works OK.
> =

> I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
> I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
> (v302) but both didn't work.
> =

> When the nvidia module is loaded, it prints out an error message:
> "NVRM: PAT configuration unsupported, falling back to MTRRs."
> =

> When I launch Xorg, the screen turns blank then the monitors powered down=
 and my
> box hard crashed, I had to hold the power button to turn it off.

Ok, lets CC Ben - he might have more up-to-date information. Also
you might want to setup a serial console to capture the kernel to see
where it crashes.

> =

> This only happens in dom0 under XEN, if I run my dom0 by itself then
> the nvidia module loads fine.
> =

> >> However there is no MTRR support on XEN so the driver hard crashed my
> >> machine (I can't ssh into the box anymore).
> >>
> >> Moreover, there is problem with the open source driver 'nouveau' for
> >> NVIDIA card =A0(also has something to do with PAT layout of XEN) which
> >> causes memory corruption.
> >
> > Huh? Can you point me to a bugzilla please? There was a corruption
> > issue where you can pass in 'nopat' on the command line.
> =

> Yes, that is the issue I was referring to, I had to pass "nopat" to
> GRUB in order
> to fix it.

Ok, so there is afall back for you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:17:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScfOk-00015Y-Sd; Thu, 07 Jun 2012 16:17:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1ScfOj-00015T-7b
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:17:21 +0000
Received: from [85.158.143.99:30652] by server-2.bemta-4.messagelabs.com id
	05/12-17938-014D0DF4; Thu, 07 Jun 2012 16:17:20 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339085839!30892405!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16352 invoked from network); 7 Jun 2012 16:17:19 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	7 Jun 2012 16:17:19 -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 q57GH7mW026803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 12:17:07 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q57GH4jZ031821; Thu, 7 Jun 2012 12:17:06 -0400
Date: Thu, 7 Jun 2012 18:17:04 +0200
From: Andrea Arcangeli <aarcange@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120607161704.GE21339@redhat.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
	<20120607103355.GA21339@redhat.com>
	<20120607155647.GO9472@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607155647.GO9472@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergio Gelato <Sergio.Gelato@astro.su.se>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Thu, Jun 07, 2012 at 11:56:47AM -0400, Konrad Rzeszutek Wilk wrote:
> then the high part. Why that would trip the hypervisor
> is not clear to me. Perhaps in the past it only read the

That is the CONFIG_TRANSPARENT_HUGEPAGE=n case and in fact it doesn't
trip the hypervisor. That was tested too, it should work fine.

The problem is with the atomic64_read version, that one uses cmpxchg8b
to read the contents of the pmdp.

> Ah, by just skipping the thing if the low bits are zero.

Yep.

> didn't like somebody reading the high and low bit, but isn't the
> pmdval_t still 64-bit ? So I would have thought this would

The pmd format is unchanged, that's hardware.

> The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora
> 17 dom0. So it looks like this is reading high part is fixed on the newer
> hypervisors, but now with the older ones. And the older one is Amazon EC2
> so some .. hack to workaround older hypervisors could be added.

The insn oopsing is cmpxchg8b and it's not reading the low/high part
in two separate insn but reading it in a single insn, which means the
kernel oopsing was built with CONFIG_TRANSPARENT_HUGEPAGE=y.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:17:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScfOk-00015Y-Sd; Thu, 07 Jun 2012 16:17:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1ScfOj-00015T-7b
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:17:21 +0000
Received: from [85.158.143.99:30652] by server-2.bemta-4.messagelabs.com id
	05/12-17938-014D0DF4; Thu, 07 Jun 2012 16:17:20 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339085839!30892405!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16352 invoked from network); 7 Jun 2012 16:17:19 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	7 Jun 2012 16:17:19 -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 q57GH7mW026803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 12:17:07 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q57GH4jZ031821; Thu, 7 Jun 2012 12:17:06 -0400
Date: Thu, 7 Jun 2012 18:17:04 +0200
From: Andrea Arcangeli <aarcange@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120607161704.GE21339@redhat.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
	<20120607103355.GA21339@redhat.com>
	<20120607155647.GO9472@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607155647.GO9472@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergio Gelato <Sergio.Gelato@astro.su.se>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Thu, Jun 07, 2012 at 11:56:47AM -0400, Konrad Rzeszutek Wilk wrote:
> then the high part. Why that would trip the hypervisor
> is not clear to me. Perhaps in the past it only read the

That is the CONFIG_TRANSPARENT_HUGEPAGE=n case and in fact it doesn't
trip the hypervisor. That was tested too, it should work fine.

The problem is with the atomic64_read version, that one uses cmpxchg8b
to read the contents of the pmdp.

> Ah, by just skipping the thing if the low bits are zero.

Yep.

> didn't like somebody reading the high and low bit, but isn't the
> pmdval_t still 64-bit ? So I would have thought this would

The pmd format is unchanged, that's hardware.

> The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora
> 17 dom0. So it looks like this is reading high part is fixed on the newer
> hypervisors, but now with the older ones. And the older one is Amazon EC2
> so some .. hack to workaround older hypervisors could be added.

The insn oopsing is cmpxchg8b and it's not reading the low/high part
in two separate insn but reading it in a single insn, which means the
kernel oopsing was built with CONFIG_TRANSPARENT_HUGEPAGE=y.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:31:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfcK-0001XL-TF; Thu, 07 Jun 2012 16:31:24 +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 1ScfcJ-0001XF-Qg
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:31:23 +0000
Received: from [85.158.139.83:54538] by server-2.bemta-5.messagelabs.com id
	D2/3D-20827-A57D0DF4; Thu, 07 Jun 2012 16:31:22 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339086680!28227351!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22878 invoked from network); 7 Jun 2012 16:31:22 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 16:31:22 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q57GRn6G028548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 09:27:51 -0700
Message-ID: <4FD0D67E.3080506@zytor.com>
Date: Thu, 07 Jun 2012 09:27:42 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com>
	<4FD05CED.60905@amd.com> <20120607080833.GA23186@kroah.com>
In-Reply-To: <20120607080833.GA23186@kroah.com>
X-Enigmail-Version: 1.4.1
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/07/2012 01:08 AM, Greg KH wrote:
> 
> What?  So I don't need to do anything?
> 

Correct, you're fine as-is.
	
	-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 Jun 07 16:31:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfcK-0001XL-TF; Thu, 07 Jun 2012 16:31:24 +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 1ScfcJ-0001XF-Qg
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:31:23 +0000
Received: from [85.158.139.83:54538] by server-2.bemta-5.messagelabs.com id
	D2/3D-20827-A57D0DF4; Thu, 07 Jun 2012 16:31:22 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339086680!28227351!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22878 invoked from network); 7 Jun 2012 16:31:22 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 16:31:22 -0000
Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f::feed:face:f00d])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q57GRn6G028548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 09:27:51 -0700
Message-ID: <4FD0D67E.3080506@zytor.com>
Date: Thu, 07 Jun 2012 09:27:42 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <1338562358-28182-1-git-send-email-bp@amd64.org>
	<1338562358-28182-4-git-send-email-bp@amd64.org>
	<4FCFD2EE.8060508@zytor.com>
	<20120607072159.GB9856@aftab.osrc.amd.com>
	<4FD05CED.60905@amd.com> <20120607080833.GA23186@kroah.com>
In-Reply-To: <20120607080833.GA23186@kroah.com>
X-Enigmail-Version: 1.4.1
Cc: Andre Przywara <andre.przywara@amd.com>, jeremy@goop.org,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Jacob Shin <jacob.shin@amd.com>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@amd64.org>, stable@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/4] x86,
	AMD: Fix crash as Xen Dom0 on AMD Trinity systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/07/2012 01:08 AM, Greg KH wrote:
> 
> What?  So I don't need to do anything?
> 

Correct, you're fine as-is.
	
	-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 Jun 07 16:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScffM-0001hI-Fx; Thu, 07 Jun 2012 16:34: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 1ScffK-0001hB-PC
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:34:31 +0000
Received: from [85.158.139.83:16932] by server-5.bemta-5.messagelabs.com id
	4C/0D-04481-518D0DF4; Thu, 07 Jun 2012 16:34:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339086869!18660235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12332 invoked from network); 7 Jun 2012 16:34:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:34:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:34:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:34:29 +0100
Message-ID: <1339086867.18523.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 7 Jun 2012 17:34:27 +0100
In-Reply-To: <1339077263.18523.19.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
	<1339077263.18523.19.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > > > index 4f624d8..fdbecbc 100644
> > > > > --- a/xen/arch/arm/p2m.c
> > > > > +++ b/xen/arch/arm/p2m.c
> > > > > @@ -5,6 +5,40 @@
> > > > >  #include <xen/domain_page.h>
> > > > >  #include <asm/flushtlb.h>
> > > > >  
> > > > > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > > > > +{
[...]
> > > > > +}
> > > > 
> > > > Can this be unified with dump_pt_walk?
> > > 
> > > Not all that easily, mainly because dump_pt_walk walks xenheap pages
> > > (which don't need mapping) while dump_p2m_walk dumps domheap pages
> > > (which need mapping as we go). I probably could write something generic
> > > enough but I fear that it would be a mass of if's.
> > 
> > Is there any harm in mapping xenheap pages?  Since this is only invoked
> > on error paths, we don't particularly need it to be fast. 
> 
> For some reason I thought it just didn't work -- I'll give it a go
> though.

Well it works, this means that this patch and the previous patch then
collapse down into a single patch:

8<-------------------------------------------------------

>From 055fe5f4a3a77f292d5a2a6b9f56a4d14dad3519 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 2 Mar 2012 12:02:42 +0000
Subject: [PATCH] arm: handy function to print a walk of a page table

Include helpers for dumping hypervisor walks and guest p2m walks.

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c          |   49 +++++++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/p2m.c         |   15 +++++++++++++
 xen/include/asm-arm/page.h |   26 +++++++++++++++++++++++
 3 files changed, 89 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 10ff883..715a98a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -26,6 +26,7 @@
 #include <xen/preempt.h>
 #include <xen/errno.h>
 #include <xen/guest_access.h>
+#include <xen/domain_page.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <public/memory.h>
@@ -42,6 +43,8 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t boot_httbr;
 
+static paddr_t phys_offset;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -53,6 +56,50 @@ unsigned long max_page;
 
 extern char __init_begin[], __init_end[];
 
+void dump_pt_walk(lpae_t *first, paddr_t addr)
+{
+    lpae_t *second = NULL, *third = NULL;
+
+    if ( first_table_offset(addr) >= LPAE_ENTRIES )
+        return;
+
+    printk("1ST[0x%llx] = 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),
+           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),
+           third[third_table_offset(addr)].bits);
+
+done:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+
+}
+
+void dump_hyp_walk(uint32_t addr)
+{
+    uint64_t httbr = READ_CP64(HTTBR);
+
+    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
+           addr, httbr);
+
+    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    dump_pt_walk(xen_pgtable, addr);
+}
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
@@ -159,7 +206,7 @@ void unmap_domain_page(const void *va)
  * Changes here may need matching changes in head.S */
 void __init setup_pagetables(unsigned long boot_phys_offset)
 {
-    paddr_t xen_paddr, phys_offset;
+    paddr_t xen_paddr;
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 4f624d8..ea385a6 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -5,6 +5,21 @@
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
 
+void dump_p2m_lookup(struct domain *d, paddr_t addr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first;
+
+    printk("dom%d IPA 0x%"PRIpaddr"\n", d->domain_id, addr);
+
+    printk("P2M @ %p mfn:0x%lx\n",
+           p2m->first_level, page_to_mfn(p2m->first_level));
+
+    first = __map_domain_page(p2m->first_level);
+    dump_pt_walk(first, addr);
+    unmap_domain_page(first);
+}
+
 void p2m_load_VTTBR(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b6df64e..183ba5f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -132,10 +132,28 @@ typedef struct {
     unsigned long sbz1:5;
 } __attribute__((__packed__)) lpae_p2m_t;
 
+/*
+ * Walk is the common bits of p2m and pt entries which are needed to
+ * simply walk the table (e.g. for debug).
+ */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    unsigned long pad2:10;
+
+    /* The base address must be appropriately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+
+    unsigned long pad1:24;
+} __attribute__((__packed__)) lpae_walk_t;
+
 typedef union {
     uint64_t bits;
     lpae_pt_t pt;
     lpae_p2m_t p2m;
+    lpae_walk_t walk;
 } lpae_t;
 
 /* Standard entry type that we'll use to build Xen's own pagetables.
@@ -252,6 +270,14 @@ static inline void flush_guest_tlb(void)
     WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
 }
 
+/* Print a walk of an arbitrary page table */
+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);
+/* 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)
 {
-- 
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 Thu Jun 07 16:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScffM-0001hI-Fx; Thu, 07 Jun 2012 16:34: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 1ScffK-0001hB-PC
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:34:31 +0000
Received: from [85.158.139.83:16932] by server-5.bemta-5.messagelabs.com id
	4C/0D-04481-518D0DF4; Thu, 07 Jun 2012 16:34:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339086869!18660235!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12332 invoked from network); 7 Jun 2012 16:34:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:34:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:34:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:34:29 +0100
Message-ID: <1339086867.18523.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 7 Jun 2012 17:34:27 +0100
In-Reply-To: <1339077263.18523.19.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
	<1339077263.18523.19.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > > > index 4f624d8..fdbecbc 100644
> > > > > --- a/xen/arch/arm/p2m.c
> > > > > +++ b/xen/arch/arm/p2m.c
> > > > > @@ -5,6 +5,40 @@
> > > > >  #include <xen/domain_page.h>
> > > > >  #include <asm/flushtlb.h>
> > > > >  
> > > > > +void dump_p2m_lookup(struct domain *d, paddr_t addr)
> > > > > +{
[...]
> > > > > +}
> > > > 
> > > > Can this be unified with dump_pt_walk?
> > > 
> > > Not all that easily, mainly because dump_pt_walk walks xenheap pages
> > > (which don't need mapping) while dump_p2m_walk dumps domheap pages
> > > (which need mapping as we go). I probably could write something generic
> > > enough but I fear that it would be a mass of if's.
> > 
> > Is there any harm in mapping xenheap pages?  Since this is only invoked
> > on error paths, we don't particularly need it to be fast. 
> 
> For some reason I thought it just didn't work -- I'll give it a go
> though.

Well it works, this means that this patch and the previous patch then
collapse down into a single patch:

8<-------------------------------------------------------

>From 055fe5f4a3a77f292d5a2a6b9f56a4d14dad3519 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 2 Mar 2012 12:02:42 +0000
Subject: [PATCH] arm: handy function to print a walk of a page table

Include helpers for dumping hypervisor walks and guest p2m walks.

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c          |   49 +++++++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/p2m.c         |   15 +++++++++++++
 xen/include/asm-arm/page.h |   26 +++++++++++++++++++++++
 3 files changed, 89 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 10ff883..715a98a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -26,6 +26,7 @@
 #include <xen/preempt.h>
 #include <xen/errno.h>
 #include <xen/guest_access.h>
+#include <xen/domain_page.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <public/memory.h>
@@ -42,6 +43,8 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t boot_httbr;
 
+static paddr_t phys_offset;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -53,6 +56,50 @@ unsigned long max_page;
 
 extern char __init_begin[], __init_end[];
 
+void dump_pt_walk(lpae_t *first, paddr_t addr)
+{
+    lpae_t *second = NULL, *third = NULL;
+
+    if ( first_table_offset(addr) >= LPAE_ENTRIES )
+        return;
+
+    printk("1ST[0x%llx] = 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),
+           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),
+           third[third_table_offset(addr)].bits);
+
+done:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+
+}
+
+void dump_hyp_walk(uint32_t addr)
+{
+    uint64_t httbr = READ_CP64(HTTBR);
+
+    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
+           addr, httbr);
+
+    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    dump_pt_walk(xen_pgtable, addr);
+}
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
@@ -159,7 +206,7 @@ void unmap_domain_page(const void *va)
  * Changes here may need matching changes in head.S */
 void __init setup_pagetables(unsigned long boot_phys_offset)
 {
-    paddr_t xen_paddr, phys_offset;
+    paddr_t xen_paddr;
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 4f624d8..ea385a6 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -5,6 +5,21 @@
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
 
+void dump_p2m_lookup(struct domain *d, paddr_t addr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first;
+
+    printk("dom%d IPA 0x%"PRIpaddr"\n", d->domain_id, addr);
+
+    printk("P2M @ %p mfn:0x%lx\n",
+           p2m->first_level, page_to_mfn(p2m->first_level));
+
+    first = __map_domain_page(p2m->first_level);
+    dump_pt_walk(first, addr);
+    unmap_domain_page(first);
+}
+
 void p2m_load_VTTBR(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b6df64e..183ba5f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -132,10 +132,28 @@ typedef struct {
     unsigned long sbz1:5;
 } __attribute__((__packed__)) lpae_p2m_t;
 
+/*
+ * Walk is the common bits of p2m and pt entries which are needed to
+ * simply walk the table (e.g. for debug).
+ */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    unsigned long pad2:10;
+
+    /* The base address must be appropriately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+
+    unsigned long pad1:24;
+} __attribute__((__packed__)) lpae_walk_t;
+
 typedef union {
     uint64_t bits;
     lpae_pt_t pt;
     lpae_p2m_t p2m;
+    lpae_walk_t walk;
 } lpae_t;
 
 /* Standard entry type that we'll use to build Xen's own pagetables.
@@ -252,6 +270,14 @@ static inline void flush_guest_tlb(void)
     WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
 }
 
+/* Print a walk of an arbitrary page table */
+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);
+/* 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)
 {
-- 
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 Thu Jun 07 16:40:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfkP-0001uC-7Q; Thu, 07 Jun 2012 16:39: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 1ScfkO-0001u5-6d
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:39:44 +0000
Received: from [85.158.143.35:64067] by server-2.bemta-4.messagelabs.com id
	9F/C8-17938-F49D0DF4; Thu, 07 Jun 2012 16:39:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339087182!19254639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1812 invoked from network); 7 Jun 2012 16:39:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:39:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:39:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:39:42 +0100
Message-ID: <1339087181.22331.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 7 Jun 2012 17:39:41 +0100
In-Reply-To: <1339086867.18523.36.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
	<1339077263.18523.19.camel@zakaz.uk.xensource.com>
	<1339086867.18523.36.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 17:34 +0100, Ian Campbell wrote:

> +    /* The base address must be appropriately aligned for Block entries */

I fixed upo a typo in this in my mail client, but when I went to fix it
in my tree I noticed I'd just cut-n-pasted it from some other places, so
I actually just added to my series:

8<----------------------

>From 7a04d5c045df2afee7a9302c26b007e6f1901e01 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 7 Jun 2012 16:35:12 +0000
Subject: [PATCH] arm: fix typo s/approprately/appropriately/g

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/page.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 20de411..3c59923 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -87,7 +87,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long ng:1;         /* Not-Global */
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz:12;       /* Must be zero */
 
@@ -122,7 +122,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long sbz4:1;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz3:12;
 
@@ -147,7 +147,7 @@ typedef struct {
 
     unsigned long pad2:10;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
 
     unsigned long pad1:24;
-- 
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 Thu Jun 07 16:40:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1ScfkP-0001uC-7Q; Thu, 07 Jun 2012 16:39: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 1ScfkO-0001u5-6d
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:39:44 +0000
Received: from [85.158.143.35:64067] by server-2.bemta-4.messagelabs.com id
	9F/C8-17938-F49D0DF4; Thu, 07 Jun 2012 16:39:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339087182!19254639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1812 invoked from network); 7 Jun 2012 16:39:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:39:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:39:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:39:42 +0100
Message-ID: <1339087181.22331.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 7 Jun 2012 17:39:41 +0100
In-Reply-To: <1339086867.18523.36.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
	<1339077263.18523.19.camel@zakaz.uk.xensource.com>
	<1339086867.18523.36.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
 of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 17:34 +0100, Ian Campbell wrote:

> +    /* The base address must be appropriately aligned for Block entries */

I fixed upo a typo in this in my mail client, but when I went to fix it
in my tree I noticed I'd just cut-n-pasted it from some other places, so
I actually just added to my series:

8<----------------------

>From 7a04d5c045df2afee7a9302c26b007e6f1901e01 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 7 Jun 2012 16:35:12 +0000
Subject: [PATCH] arm: fix typo s/approprately/appropriately/g

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/page.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 20de411..3c59923 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -87,7 +87,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long ng:1;         /* Not-Global */
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz:12;       /* Must be zero */
 
@@ -122,7 +122,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long sbz4:1;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz3:12;
 
@@ -147,7 +147,7 @@ typedef struct {
 
     unsigned long pad2:10;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
 
     unsigned long pad1:24;
-- 
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 Thu Jun 07 16:42:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:42: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 1ScfmT-00020H-Ok; Thu, 07 Jun 2012 16:41: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 1ScfmS-00020C-Vo
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:41:53 +0000
Received: from [193.109.254.147:63154] by server-12.bemta-14.messagelabs.com
	id 62/31-12998-0D9D0DF4; Thu, 07 Jun 2012 16:41:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339087311!1768668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6257 invoked from network); 7 Jun 2012 16:41:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:41:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:41:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 17:41:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScfmQ-0001HL-Ti; Thu, 07 Jun 2012 16:41:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScfmQ-0008Ij-Sl;
	Thu, 07 Jun 2012 17:41:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.55756.587767.208290@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 17:41:48 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <93ff3e5ecdee68b4f949.1339076552@Solace>
References: <patchbomb.1339076551@Solace>
	<93ff3e5ecdee68b4f949.1339076552@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v2] libxl: propagete down the error
 from libxl_domain_sched_params_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

Dario Faggioli writes ("[PATCH 1 of 2 v2] libxl: propagete down the error from libxl_domain_sched_params_set"):
> So that the caller (e.g., libxl__build_post() ) knows and can deal with it.
...
> -    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
> +    if (libxl_domain_sched_params_set(CTX, domid, &info->sched_params))
> +        return ERROR_INVAL;

This is not correct.  It should return whatever error code
libxl_domain_sched_params_set returns, not unconditionally
ERROR_INVAL.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:42:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:42: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 1ScfmT-00020H-Ok; Thu, 07 Jun 2012 16:41: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 1ScfmS-00020C-Vo
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:41:53 +0000
Received: from [193.109.254.147:63154] by server-12.bemta-14.messagelabs.com
	id 62/31-12998-0D9D0DF4; Thu, 07 Jun 2012 16:41:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339087311!1768668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6257 invoked from network); 7 Jun 2012 16:41:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:41:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:41:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 17:41:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScfmQ-0001HL-Ti; Thu, 07 Jun 2012 16:41:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScfmQ-0008Ij-Sl;
	Thu, 07 Jun 2012 17:41:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.55756.587767.208290@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 17:41:48 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <93ff3e5ecdee68b4f949.1339076552@Solace>
References: <patchbomb.1339076551@Solace>
	<93ff3e5ecdee68b4f949.1339076552@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v2] libxl: propagete down the error
 from libxl_domain_sched_params_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

Dario Faggioli writes ("[PATCH 1 of 2 v2] libxl: propagete down the error from libxl_domain_sched_params_set"):
> So that the caller (e.g., libxl__build_post() ) knows and can deal with it.
...
> -    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
> +    if (libxl_domain_sched_params_set(CTX, domid, &info->sched_params))
> +        return ERROR_INVAL;

This is not correct.  It should return whatever error code
libxl_domain_sched_params_set returns, not unconditionally
ERROR_INVAL.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:42:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scfn7-00023M-6K; Thu, 07 Jun 2012 16:42: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 1Scfn5-000235-Hi
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:42:31 +0000
Received: from [85.158.138.51:41891] by server-2.bemta-3.messagelabs.com id
	56/3F-16299-6F9D0DF4; Thu, 07 Jun 2012 16:42:30 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339087350!31393003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29685 invoked from network); 7 Jun 2012 16:42:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:42:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:42:30 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:42:30 +0100
Message-ID: <4FD0D9EC.4050700@citrix.com>
Date: Thu, 7 Jun 2012 18:42:20 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47266.847506.330124@mariner.uk.xensource.com>
In-Reply-To: <20432.47266.847506.330124@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>> we reached the desired xenbus state.
>
> Just spotted:
>
>> +void libxl__initiate_device_add(libxl__egc *egc, libxl__ao_device *aodev)
>> +{
> ...
>> +    libxl__ev_devstate_init(&aodev->ds);
>> +    rc = libxl__ev_devstate_wait(gc,&aodev->ds, device_backend_callback,
>> +                                 state_path, XenbusStateInitWait,
>> +                                 LIBXL_INIT_TIMEOUT * 1000);
>
> Another unneeded _init.

Ok, I thought that you need to call libxl__ev_devstate_init before 
libxl__ev_devstate_wait? I just saw that _wait performs the _init itself 
(but without calling _init).

Can't we remove _init, if it's not needed? Having and _init function 
makes people thing they have to use it, and the comments doesn't say 
anything about _wait calling _init itself.

> I won't comment on any more of these I find.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:42:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scfn7-00023M-6K; Thu, 07 Jun 2012 16:42: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 1Scfn5-000235-Hi
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:42:31 +0000
Received: from [85.158.138.51:41891] by server-2.bemta-3.messagelabs.com id
	56/3F-16299-6F9D0DF4; Thu, 07 Jun 2012 16:42:30 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339087350!31393003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29685 invoked from network); 7 Jun 2012 16:42:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:42:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:42:30 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:42:30 +0100
Message-ID: <4FD0D9EC.4050700@citrix.com>
Date: Thu, 7 Jun 2012 18:42:20 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47266.847506.330124@mariner.uk.xensource.com>
In-Reply-To: <20432.47266.847506.330124@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>> we reached the desired xenbus state.
>
> Just spotted:
>
>> +void libxl__initiate_device_add(libxl__egc *egc, libxl__ao_device *aodev)
>> +{
> ...
>> +    libxl__ev_devstate_init(&aodev->ds);
>> +    rc = libxl__ev_devstate_wait(gc,&aodev->ds, device_backend_callback,
>> +                                 state_path, XenbusStateInitWait,
>> +                                 LIBXL_INIT_TIMEOUT * 1000);
>
> Another unneeded _init.

Ok, I thought that you need to call libxl__ev_devstate_init before 
libxl__ev_devstate_wait? I just saw that _wait performs the _init itself 
(but without calling _init).

Can't we remove _init, if it's not needed? Having and _init function 
makes people thing they have to use it, and the comments doesn't say 
anything about _wait calling _init itself.

> I won't comment on any more of these I find.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scfro-0002UU-1q; Thu, 07 Jun 2012 16:47: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 1Scfrn-0002UP-HG
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:47:23 +0000
Received: from [85.158.138.51:7579] by server-5.bemta-3.messagelabs.com id
	F0/47-03598-91BD0DF4; Thu, 07 Jun 2012 16:47:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339087640!31360669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29845 invoked from network); 7 Jun 2012 16:47:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:47:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:47:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 17:47:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScfrU-0001J1-4s; Thu, 07 Jun 2012 16:47:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScfrU-0008JR-42;
	Thu, 07 Jun 2012 17:47:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.56072.109629.746759@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 17:47:04 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0D9EC.4050700@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47266.847506.330124@mariner.uk.xensource.com>
	<4FD0D9EC.4050700@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 v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> Can't we remove _init, if it's not needed? Having and _init function 
> makes people thing they have to use it, and the comments doesn't say 
> anything about _wait calling _init itself.

_init is needed to provide a way to initialise the structure so that
it is safe to pass to _cancel.  This means that caller can use
idempotent initialisation and cleanup, which avoids leaks and logic
errors.

This is the same way it's done for many other of the event functions,
eg:
    libxl__ev_FOO_{init,register,deregister}
    libxl__datacopier_{state,init,start,kill}
    libxl__bootloader_{state,init,run}

Feel free to provide a comment clarifying the API.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scfro-0002UU-1q; Thu, 07 Jun 2012 16:47: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 1Scfrn-0002UP-HG
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:47:23 +0000
Received: from [85.158.138.51:7579] by server-5.bemta-3.messagelabs.com id
	F0/47-03598-91BD0DF4; Thu, 07 Jun 2012 16:47:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339087640!31360669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29845 invoked from network); 7 Jun 2012 16:47:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:47:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:47:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 17:47:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScfrU-0001J1-4s; Thu, 07 Jun 2012 16:47:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScfrU-0008JR-42;
	Thu, 07 Jun 2012 17:47:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.56072.109629.746759@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 17:47:04 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0D9EC.4050700@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47266.847506.330124@mariner.uk.xensource.com>
	<4FD0D9EC.4050700@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 v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> Can't we remove _init, if it's not needed? Having and _init function 
> makes people thing they have to use it, and the comments doesn't say 
> anything about _wait calling _init itself.

_init is needed to provide a way to initialise the structure so that
it is safe to pass to _cancel.  This means that caller can use
idempotent initialisation and cleanup, which avoids leaks and logic
errors.

This is the same way it's done for many other of the event functions,
eg:
    libxl__ev_FOO_{init,register,deregister}
    libxl__datacopier_{state,init,start,kill}
    libxl__bootloader_{state,init,run}

Feel free to provide a comment clarifying the API.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:47:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:47: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 1Scfs5-0002Wm-El; Thu, 07 Jun 2012 16:47: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 1Scfs3-0002Wa-Pq
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:47:39 +0000
Received: from [85.158.143.35:36969] by server-2.bemta-4.messagelabs.com id
	FD/00-17938-B2BD0DF4; Thu, 07 Jun 2012 16:47:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339087656!13416551!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15223 invoked from network); 7 Jun 2012 16:47:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 16:47:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57GlXbd014378
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 16:47:34 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
	q57GlWIe029867
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 16:47:33 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q57GlW8f032079; Thu, 7 Jun 2012 11:47:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 09:47:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 263C14030D; Thu,  7 Jun 2012 12:40:34 -0400 (EDT)
Date: Thu, 7 Jun 2012 12:40:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120607164034.GQ9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
 kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 09:30:06AM -0400, Ben Guthro wrote:
> Fix the polling section of the hvc driver to use the global "last_hvc"
> variable, rather than the ttys.

Could you just do:

       struct tty_struct *tty = driver->ttys[last_hvc];

as well? So how come the '0' one did not work? Is that b/c
of console=tty becoming '0' instead of hvc0? Is there a crash
involved with this? Or is that it just is listening on the
wrong console (and which one is that?)
> 
> With this change debugging a xen dom0 kernel is possible via the
> following kernel parameter:
> kgdboc=hvc0

Hm, if that is the problem then this should also be a problem on
IBM Power boxes I would think?

> 
> Signed-off-by: Ben Guthro <Benjamin.Guthro@citrix.com>
> 
> 
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 2d691eb..3750e74 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -766,12 +766,10 @@ int hvc_poll_init(struct tty_driver *driver, int
> line, char *options)
> 
>  static int hvc_poll_get_char(struct tty_driver *driver, int line)
>  {
> -       struct tty_struct *tty = driver->ttys[0];
> -       struct hvc_struct *hp = tty->driver_data;
>         int n;
>         char ch;
> 
> -       n = hp->ops->get_chars(hp->vtermno, &ch, 1);
> +       n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
> 
>         if (n == 0)
>                 return NO_POLL_CHAR;
> @@ -781,12 +779,10 @@ static int hvc_poll_get_char(struct tty_driver
> *driver, int line)
> 
>  static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
>  {
> -       struct tty_struct *tty = driver->ttys[0];
> -       struct hvc_struct *hp = tty->driver_data;
>         int n;
> 
>         do {
> -               n = hp->ops->put_chars(hp->vtermno, &ch, 1);
> +               n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
>         } while (n <= 0);
>  }
>  #endif
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:47:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:47: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 1Scfs5-0002Wm-El; Thu, 07 Jun 2012 16:47: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 1Scfs3-0002Wa-Pq
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 16:47:39 +0000
Received: from [85.158.143.35:36969] by server-2.bemta-4.messagelabs.com id
	FD/00-17938-B2BD0DF4; Thu, 07 Jun 2012 16:47:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339087656!13416551!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15223 invoked from network); 7 Jun 2012 16:47:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 16:47:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57GlXbd014378
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 16:47:34 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
	q57GlWIe029867
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 16:47:33 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q57GlW8f032079; Thu, 7 Jun 2012 11:47:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 09:47:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 263C14030D; Thu,  7 Jun 2012 12:40:34 -0400 (EDT)
Date: Thu, 7 Jun 2012 12:40:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120607164034.GQ9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
 kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 09:30:06AM -0400, Ben Guthro wrote:
> Fix the polling section of the hvc driver to use the global "last_hvc"
> variable, rather than the ttys.

Could you just do:

       struct tty_struct *tty = driver->ttys[last_hvc];

as well? So how come the '0' one did not work? Is that b/c
of console=tty becoming '0' instead of hvc0? Is there a crash
involved with this? Or is that it just is listening on the
wrong console (and which one is that?)
> 
> With this change debugging a xen dom0 kernel is possible via the
> following kernel parameter:
> kgdboc=hvc0

Hm, if that is the problem then this should also be a problem on
IBM Power boxes I would think?

> 
> Signed-off-by: Ben Guthro <Benjamin.Guthro@citrix.com>
> 
> 
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 2d691eb..3750e74 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -766,12 +766,10 @@ int hvc_poll_init(struct tty_driver *driver, int
> line, char *options)
> 
>  static int hvc_poll_get_char(struct tty_driver *driver, int line)
>  {
> -       struct tty_struct *tty = driver->ttys[0];
> -       struct hvc_struct *hp = tty->driver_data;
>         int n;
>         char ch;
> 
> -       n = hp->ops->get_chars(hp->vtermno, &ch, 1);
> +       n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
> 
>         if (n == 0)
>                 return NO_POLL_CHAR;
> @@ -781,12 +779,10 @@ static int hvc_poll_get_char(struct tty_driver
> *driver, int line)
> 
>  static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
>  {
> -       struct tty_struct *tty = driver->ttys[0];
> -       struct hvc_struct *hp = tty->driver_data;
>         int n;
> 
>         do {
> -               n = hp->ops->put_chars(hp->vtermno, &ch, 1);
> +               n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
>         } while (n <= 0);
>  }
>  #endif
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:55:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:55: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 1Scfzm-0002nz-Cr; Thu, 07 Jun 2012 16:55:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Scfzl-0002nu-1f
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:55:37 +0000
Received: from [85.158.139.83:28284] by server-12.bemta-5.messagelabs.com id
	FB/51-18374-80DD0DF4; Thu, 07 Jun 2012 16:55:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339088134!32529712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23213 invoked from network); 7 Jun 2012 16:55:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:55:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:55:34 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:55:34 +0100
Message-ID: <4FD0DD03.2020704@citrix.com>
Date: Thu, 7 Jun 2012 18:55:31 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
In-Reply-To: <20432.47604.849028.717366@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>> we reached the desired xenbus state.
>
> And:
>
>> +/* Internal AO operation to connect a disk device, called by
>> + * libxl_device_disk_add and libxl__add_disks. This function calls
>> + * libxl__initiate_device_add */
>> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
>> +                                    libxl_device_disk *disk,
>> +                                    libxl__ao_device *aodev);
>> +
>> +/* Arranges that dev will be added to the guest, and the
>> + * hotplug scripts will be executed (if necessary). When
>> + * this is done (or an error happens), the callback in
>> + * aodev->callback will be called.
>> + */
>> +_hidden void libxl__initiate_device_add(libxl__egc*, libxl__ao_device *aodev);
>
> I don't think these comments are coherent.
>
> I think a function which "Arranges that dev will be added to the
> guest" is one which does everything necessary - ie, the outermost
> entrypoint.
>
> And you're using `internal' here to mean `internal to libxl'.  I think
> that's clear from the name (which has `__').  Whereas on first reading
> it sounds like you mean `internal to the device adding machinery' -
> but `libxl__device_disk_add' is the main entrypoint to that
> machinery.

I've used 'internal' here to reflex the difference between 
libxl_device_disk_add and libxl__device_disk_add, but probably leads to 
confusion.

> And `libxl__initiate_device_add' is the internal helper function.
>
> I think these comments need to be clarified and perhaps
> libxl__initiate_device_add needs to be renamed to be clear about what
> exactly it is for.  Eg
>     /* Initiates the device-kind-independent operations blah blah
>     hidden void libxl__initiate_device_add_core(libxl__egc*,
>                                     libxl__ao_device *aodev);
> or something.
>
> Please do reply suggesting alternative wording
>
> Ian.

Well the order is the following:

libxl__device_{disk/nic}_add (device type dependant function) -> 
libxl__initiate_device_add (device type independent).

I'm really bad about this naming thing. But the fact is that 
libxl__initiate_device_add is not a good name, since when we call this 
function the device is already added (to xenstore), this merely waits 
for it to reach the desired state and performs the necessary actions to 
"add" it to the guest (call hotplug scripts). Maybe "connect" is a more 
appropriate name than "add".

I liked the nomenclature because it follows the same style as 
libxl__initiate_device_remove, and I think (and I might be wrong) it 
makes things easier to understand.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:55:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16:55: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 1Scfzm-0002nz-Cr; Thu, 07 Jun 2012 16:55:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Scfzl-0002nu-1f
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:55:37 +0000
Received: from [85.158.139.83:28284] by server-12.bemta-5.messagelabs.com id
	FB/51-18374-80DD0DF4; Thu, 07 Jun 2012 16:55:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339088134!32529712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23213 invoked from network); 7 Jun 2012 16:55:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:55:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:55:34 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:55:34 +0100
Message-ID: <4FD0DD03.2020704@citrix.com>
Date: Thu, 7 Jun 2012 18:55:31 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
In-Reply-To: <20432.47604.849028.717366@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>> we reached the desired xenbus state.
>
> And:
>
>> +/* Internal AO operation to connect a disk device, called by
>> + * libxl_device_disk_add and libxl__add_disks. This function calls
>> + * libxl__initiate_device_add */
>> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
>> +                                    libxl_device_disk *disk,
>> +                                    libxl__ao_device *aodev);
>> +
>> +/* Arranges that dev will be added to the guest, and the
>> + * hotplug scripts will be executed (if necessary). When
>> + * this is done (or an error happens), the callback in
>> + * aodev->callback will be called.
>> + */
>> +_hidden void libxl__initiate_device_add(libxl__egc*, libxl__ao_device *aodev);
>
> I don't think these comments are coherent.
>
> I think a function which "Arranges that dev will be added to the
> guest" is one which does everything necessary - ie, the outermost
> entrypoint.
>
> And you're using `internal' here to mean `internal to libxl'.  I think
> that's clear from the name (which has `__').  Whereas on first reading
> it sounds like you mean `internal to the device adding machinery' -
> but `libxl__device_disk_add' is the main entrypoint to that
> machinery.

I've used 'internal' here to reflex the difference between 
libxl_device_disk_add and libxl__device_disk_add, but probably leads to 
confusion.

> And `libxl__initiate_device_add' is the internal helper function.
>
> I think these comments need to be clarified and perhaps
> libxl__initiate_device_add needs to be renamed to be clear about what
> exactly it is for.  Eg
>     /* Initiates the device-kind-independent operations blah blah
>     hidden void libxl__initiate_device_add_core(libxl__egc*,
>                                     libxl__ao_device *aodev);
> or something.
>
> Please do reply suggesting alternative wording
>
> Ian.

Well the order is the following:

libxl__device_{disk/nic}_add (device type dependant function) -> 
libxl__initiate_device_add (device type independent).

I'm really bad about this naming thing. But the fact is that 
libxl__initiate_device_add is not a good name, since when we call this 
function the device is already added (to xenstore), this merely waits 
for it to reach the desired state and performs the necessary actions to 
"add" it to the guest (call hotplug scripts). Maybe "connect" is a more 
appropriate name than "add".

I liked the nomenclature because it follows the same style as 
libxl__initiate_device_remove, and I think (and I might be wrong) it 
makes things easier to understand.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 16:57:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scg1B-0002s9-VU; Thu, 07 Jun 2012 16:57: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 1Scg1B-0002s4-Ds
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:57:05 +0000
Received: from [193.109.254.147:18381] by server-11.bemta-14.messagelabs.com
	id A1/C8-02727-06DD0DF4; Thu, 07 Jun 2012 16:57:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339088223!3477100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1528 invoked from network); 7 Jun 2012 16:57:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:57:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:57:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:57:03 +0100
Message-ID: <1339088221.22331.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 17:57:01 +0100
In-Reply-To: <alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 16:26 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> > smaller guest.
> > 
> > The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> > MAX_VIRT_CPUS -- but making that change caused:
> 
> Are you sure? I made that change and I didn't see the error.
> I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
> max_vcpus = 8.

This was the same heap corruption again as seen in "[PATCH 16/38] arm:
Add simple cpu_{sibling,core}_mask"  and having fixed that I don't see
the crash with MAX_VIRT_CPUS == 8 any more...

The patch becomes:

>From b68c4abe1dec44f3ed87a0d7ae98f4269043cce3 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 7 Jun 2012 16:52:46 +0000
Subject: [PATCH] arm: do not set max_vcpus = 8 in arch_domain_create.

XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
smaller guest.

The limit of 8 (due to GIC limits) should be expressed in MAX_VIRT_CPUS.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c        |    2 --
 xen/include/asm-arm/config.h |    2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1336dc4..040a2ce 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -338,8 +338,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
     }
 
-    d->max_vcpus = 8;
-
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 91e87e1..7d02cc7 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -27,7 +27,7 @@
 #define NR_CPUS 128
 #endif
 
-#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_VIRT_CPUS 8
 #define MAX_HVM_VCPUS MAX_VIRT_CPUS
 
 #define asmlinkage /* Nothing needed */
-- 
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 Thu Jun 07 16:57:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scg1B-0002s9-VU; Thu, 07 Jun 2012 16:57: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 1Scg1B-0002s4-Ds
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:57:05 +0000
Received: from [193.109.254.147:18381] by server-11.bemta-14.messagelabs.com
	id A1/C8-02727-06DD0DF4; Thu, 07 Jun 2012 16:57:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339088223!3477100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1528 invoked from network); 7 Jun 2012 16:57:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:57:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:57:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	17:57:03 +0100
Message-ID: <1339088221.22331.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 17:57:01 +0100
In-Reply-To: <alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 16:26 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> > smaller guest.
> > 
> > The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> > MAX_VIRT_CPUS -- but making that change caused:
> 
> Are you sure? I made that change and I didn't see the error.
> I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
> max_vcpus = 8.

This was the same heap corruption again as seen in "[PATCH 16/38] arm:
Add simple cpu_{sibling,core}_mask"  and having fixed that I don't see
the crash with MAX_VIRT_CPUS == 8 any more...

The patch becomes:

>From b68c4abe1dec44f3ed87a0d7ae98f4269043cce3 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 7 Jun 2012 16:52:46 +0000
Subject: [PATCH] arm: do not set max_vcpus = 8 in arch_domain_create.

XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
smaller guest.

The limit of 8 (due to GIC limits) should be expressed in MAX_VIRT_CPUS.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c        |    2 --
 xen/include/asm-arm/config.h |    2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1336dc4..040a2ce 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -338,8 +338,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
     }
 
-    d->max_vcpus = 8;
-
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 91e87e1..7d02cc7 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -27,7 +27,7 @@
 #define NR_CPUS 128
 #endif
 
-#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_VIRT_CPUS 8
 #define MAX_HVM_VCPUS MAX_VIRT_CPUS
 
 #define asmlinkage /* Nothing needed */
-- 
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 Thu Jun 07 16:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scg3S-00030q-H6; Thu, 07 Jun 2012 16:59: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 1Scg3R-00030h-6L
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:59:25 +0000
Received: from [85.158.138.51:10413] by server-1.bemta-3.messagelabs.com id
	4E/85-01327-CEDD0DF4; Thu, 07 Jun 2012 16:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339088363!12627916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32382 invoked from network); 7 Jun 2012 16:59:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:59:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:59:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 17:59:23 +0100
Date: Thu, 7 Jun 2012 17:59:07 +0100
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: <1339088221.22331.6.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206071759000.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
	<1339088221.22331.6.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] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 7 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-06 at 16:26 +0100, Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> > > smaller guest.
> > > 
> > > The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> > > MAX_VIRT_CPUS -- but making that change caused:
> > 
> > Are you sure? I made that change and I didn't see the error.
> > I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
> > max_vcpus = 8.
> 
> This was the same heap corruption again as seen in "[PATCH 16/38] arm:
> Add simple cpu_{sibling,core}_mask"  and having fixed that I don't see
> the crash with MAX_VIRT_CPUS == 8 any more...
> 
> The patch becomes:
> 
> From b68c4abe1dec44f3ed87a0d7ae98f4269043cce3 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 7 Jun 2012 16:52:46 +0000
> Subject: [PATCH] arm: do not set max_vcpus = 8 in arch_domain_create.
> 
> XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> smaller guest.
> 
> The limit of 8 (due to GIC limits) should be expressed in MAX_VIRT_CPUS.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c        |    2 --
>  xen/include/asm-arm/config.h |    2 +-
>  2 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 1336dc4..040a2ce 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -338,8 +338,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>              goto fail;
>      }
>  
> -    d->max_vcpus = 8;
> -
>      if ( (rc = domain_vgic_init(d)) != 0 )
>          goto fail;
>  
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 91e87e1..7d02cc7 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -27,7 +27,7 @@
>  #define NR_CPUS 128
>  #endif
>  
> -#define MAX_VIRT_CPUS 128 /* XXX */
> +#define MAX_VIRT_CPUS 8
>  #define MAX_HVM_VCPUS MAX_VIRT_CPUS
>  
>  #define asmlinkage /* Nothing needed */
> -- 
> 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 Thu Jun 07 16:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 16: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 1Scg3S-00030q-H6; Thu, 07 Jun 2012 16:59: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 1Scg3R-00030h-6L
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 16:59:25 +0000
Received: from [85.158.138.51:10413] by server-1.bemta-3.messagelabs.com id
	4E/85-01327-CEDD0DF4; Thu, 07 Jun 2012 16:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339088363!12627916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32382 invoked from network); 7 Jun 2012 16:59:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 16:59:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 16:59:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 17:59:23 +0100
Date: Thu, 7 Jun 2012 17:59:07 +0100
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: <1339088221.22331.6.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206071759000.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-14-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061623240.6030@kaball.uk.xensource.com>
	<1339088221.22331.6.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] [PATCH 14/38] arm: do not set max_vcpus = 8 in
 arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 7 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-06 at 16:26 +0100, Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> > > smaller guest.
> > > 
> > > The limit of 8 (due to GIC limits) should be expressed elsewhere, likely in
> > > MAX_VIRT_CPUS -- but making that change caused:
> > 
> > Are you sure? I made that change and I didn't see the error.
> > I think this patch should set MAX_VIRT_CPUS to 8 as well as removing
> > max_vcpus = 8.
> 
> This was the same heap corruption again as seen in "[PATCH 16/38] arm:
> Add simple cpu_{sibling,core}_mask"  and having fixed that I don't see
> the crash with MAX_VIRT_CPUS == 8 any more...
> 
> The patch becomes:
> 
> From b68c4abe1dec44f3ed87a0d7ae98f4269043cce3 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 7 Jun 2012 16:52:46 +0000
> Subject: [PATCH] arm: do not set max_vcpus = 8 in arch_domain_create.
> 
> XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
> smaller guest.
> 
> The limit of 8 (due to GIC limits) should be expressed in MAX_VIRT_CPUS.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain.c        |    2 --
>  xen/include/asm-arm/config.h |    2 +-
>  2 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 1336dc4..040a2ce 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -338,8 +338,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>              goto fail;
>      }
>  
> -    d->max_vcpus = 8;
> -
>      if ( (rc = domain_vgic_init(d)) != 0 )
>          goto fail;
>  
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 91e87e1..7d02cc7 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -27,7 +27,7 @@
>  #define NR_CPUS 128
>  #endif
>  
> -#define MAX_VIRT_CPUS 128 /* XXX */
> +#define MAX_VIRT_CPUS 8
>  #define MAX_HVM_VCPUS MAX_VIRT_CPUS
>  
>  #define asmlinkage /* Nothing needed */
> -- 
> 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 Thu Jun 07 17:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scg5g-0003BS-24; Thu, 07 Jun 2012 17:01:44 +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 1Scg5e-0003BL-LV
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:01:42 +0000
Received: from [193.109.254.147:29804] by server-3.bemta-14.messagelabs.com id
	1A/42-05653-57ED0DF4; Thu, 07 Jun 2012 17:01:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339088498!8601152!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27163 invoked from network); 7 Jun 2012 17:01:40 -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;
	7 Jun 2012 17:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330923600"; d="scan'208";a="197915183"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 13:01:38 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 13:01:37 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Scg5Y-0008EY-UL;
	Thu, 07 Jun 2012 18:01:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 7 Jun 2012 18:01:34 +0100
Message-ID: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if they
	haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

When switching tasks in a Xen PV guest, avoid updating the TLS
descriptors if they haven't changed.  This improves the speed of
context switches by almost 10% as much of the time the descriptors are
the same or only one is different.

The descriptors written into the GDT by Xen are modified from the
values passed in the update_descriptor hypercall so we keep shadow
copies of the three TLS descriptors to compare against.

lmbench3 test     Before  After  Improvement
--------------------------------------------
lat_ctx -s 32 24   7.19    6.52  9%
lat_pipe          12.56   11.66  7%

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
in desc_struct as deprecated but there seems to be no suitable
alternatives.
---
 arch/x86/xen/enlighten.c |   30 +++++++++++++++++++++++++++---
 1 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e74df95..18e14af 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -124,6 +124,19 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
  */
 static int have_vcpu_info_placement = 1;
 
+struct tls_descs {
+	struct desc_struct desc[3];
+};
+
+/*
+ * Updating the 3 TLS descriptors in the GDT on every task switch is
+ * surprisingly expensive so we avoid updating them if they haven't
+ * changed.  Since Xen writes different descriptors than the one
+ * passed in the update_descriptor hypercall we keep shadow copies to
+ * compare against.
+ */
+static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
+
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -535,9 +548,20 @@ static void __init xen_load_gdt_boot(const struct desc_ptr *dtr)
 static void load_TLS_descriptor(struct thread_struct *t,
 				unsigned int cpu, unsigned int i)
 {
-	struct desc_struct *gdt = get_cpu_gdt_table(cpu);
-	xmaddr_t maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
-	struct multicall_space mc = __xen_mc_entry(0);
+	struct desc_struct *shadow = &per_cpu(shadow_tls_desc, cpu).desc[i];
+	struct desc_struct *gdt;
+	xmaddr_t maddr;
+	struct multicall_space mc;
+
+	if (shadow->a == t->tls_array[i].a && shadow->b == t->tls_array[i].b)
+		return;
+
+	shadow->a = t->tls_array[i].a;
+	shadow->b = t->tls_array[i].b;
+
+	gdt = get_cpu_gdt_table(cpu);
+	maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
+	mc = __xen_mc_entry(0);
 
 	MULTI_update_descriptor(mc.mc, maddr.maddr, t->tls_array[i]);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scg5g-0003BS-24; Thu, 07 Jun 2012 17:01:44 +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 1Scg5e-0003BL-LV
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:01:42 +0000
Received: from [193.109.254.147:29804] by server-3.bemta-14.messagelabs.com id
	1A/42-05653-57ED0DF4; Thu, 07 Jun 2012 17:01:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339088498!8601152!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27163 invoked from network); 7 Jun 2012 17:01:40 -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;
	7 Jun 2012 17:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330923600"; d="scan'208";a="197915183"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 13:01:38 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 7 Jun 2012 13:01:37 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1Scg5Y-0008EY-UL;
	Thu, 07 Jun 2012 18:01:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 7 Jun 2012 18:01:34 +0100
Message-ID: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if they
	haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

When switching tasks in a Xen PV guest, avoid updating the TLS
descriptors if they haven't changed.  This improves the speed of
context switches by almost 10% as much of the time the descriptors are
the same or only one is different.

The descriptors written into the GDT by Xen are modified from the
values passed in the update_descriptor hypercall so we keep shadow
copies of the three TLS descriptors to compare against.

lmbench3 test     Before  After  Improvement
--------------------------------------------
lat_ctx -s 32 24   7.19    6.52  9%
lat_pipe          12.56   11.66  7%

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
in desc_struct as deprecated but there seems to be no suitable
alternatives.
---
 arch/x86/xen/enlighten.c |   30 +++++++++++++++++++++++++++---
 1 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e74df95..18e14af 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -124,6 +124,19 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
  */
 static int have_vcpu_info_placement = 1;
 
+struct tls_descs {
+	struct desc_struct desc[3];
+};
+
+/*
+ * Updating the 3 TLS descriptors in the GDT on every task switch is
+ * surprisingly expensive so we avoid updating them if they haven't
+ * changed.  Since Xen writes different descriptors than the one
+ * passed in the update_descriptor hypercall we keep shadow copies to
+ * compare against.
+ */
+static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
+
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -535,9 +548,20 @@ static void __init xen_load_gdt_boot(const struct desc_ptr *dtr)
 static void load_TLS_descriptor(struct thread_struct *t,
 				unsigned int cpu, unsigned int i)
 {
-	struct desc_struct *gdt = get_cpu_gdt_table(cpu);
-	xmaddr_t maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
-	struct multicall_space mc = __xen_mc_entry(0);
+	struct desc_struct *shadow = &per_cpu(shadow_tls_desc, cpu).desc[i];
+	struct desc_struct *gdt;
+	xmaddr_t maddr;
+	struct multicall_space mc;
+
+	if (shadow->a == t->tls_array[i].a && shadow->b == t->tls_array[i].b)
+		return;
+
+	shadow->a = t->tls_array[i].a;
+	shadow->b = t->tls_array[i].b;
+
+	gdt = get_cpu_gdt_table(cpu);
+	maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
+	mc = __xen_mc_entry(0);
 
 	MULTI_update_descriptor(mc.mc, maddr.maddr, t->tls_array[i]);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:03:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Scg7J-0003KZ-He; Thu, 07 Jun 2012 17:03: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 1Scg7H-0003KQ-7h
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:03:23 +0000
Received: from [85.158.143.35:47092] by server-3.bemta-4.messagelabs.com id
	42/B1-29237-ADED0DF4; Thu, 07 Jun 2012 17:03:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339088601!7552666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8445 invoked from network); 7 Jun 2012 17:03:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:03:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	18:03:00 +0100
Message-ID: <1339088579.22331.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 18:02:59 +0100
In-Reply-To: <1339062030.15265.53.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
	<1338990925.32319.103.camel@zakaz.uk.xensource.com>
	<1339062030.15265.53.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 10:40 +0100, Ian Campbell wrote:
> More head scratching required I think!

This turned out to be the problem with not initialising cpu_sibling_mask
properly, see the thread against "[PATCH 16/38] arm: Add simple
cpu_{sibling,core}_mask".

Having fixed that I updated based on your comments to:

8<-----------------------------------------------------------

>From 75cff29f4645dd19d07175109b5891fd44de9d60 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 13 Apr 2012 16:07:21 +0100
Subject: [PATCH] arm: allocate and setup a guest vcpu.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c         |   67 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/dummy.S          |    3 --
 xen/include/public/arch-arm.h |    9 -----
 3 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9339a11..b099d91 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
     free_xenheap_page(v);
 }
 
+struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+{
+    return xmalloc(struct vcpu_guest_context);
+
+}
+
+void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
+{
+    xfree(vgc);
+}
+
 int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
@@ -212,6 +223,62 @@ void arch_domain_destroy(struct domain *d)
     /* domain_vgic_destroy */
 }
 
+static int is_guest_psr(uint32_t psr)
+{
+    switch (psr & PSR_MODE_MASK)
+    {
+    case PSR_MODE_USR:
+    case PSR_MODE_FIQ:
+    case PSR_MODE_IRQ:
+    case PSR_MODE_SVC:
+    case PSR_MODE_ABT:
+    case PSR_MODE_UND:
+    case PSR_MODE_SYS:
+        return 1;
+    case PSR_MODE_MON:
+    case PSR_MODE_HYP:
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Initialise VCPU state. The context can be supplied by either the
+ * toolstack (XEN_DOMCTL_setvcpucontext) or the guest
+ * (VCPUOP_initialise) and therefore must be properly validated.
+ */
+int arch_set_info_guest(
+    struct vcpu *v, vcpu_guest_context_u c)
+{
+    struct cpu_user_regs *regs = &c.nat->user_regs;
+
+    if ( !is_guest_psr(regs->cpsr) )
+        return -EINVAL;
+
+    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
+        return -EINVAL;
+    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
+        return -EINVAL;
+    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
+        return -EINVAL;
+    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
+        return -EINVAL;
+    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
+        return -EINVAL;
+
+    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+
+    /* XXX other state:
+     * - SCTLR
+     * - TTBR0/1
+     * - TTBCR
+     */
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
+
 void arch_dump_domain_info(struct domain *d)
 {
 }
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 016340c..3b48917 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
 DUMMY(pirq_set_affinity);
 
 /* VCPU */
-DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1b1bcf3..e439727 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
-    union {
-        uint32_t reg[16];
-        struct {
-            uint32_t __pad[12];
-            uint32_t sp; /* r13 */
-            uint32_t lr; /* r14 */
-            uint32_t pc; /* r15 */
-        };
-    };
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Thu Jun 07 17:03:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Scg7J-0003KZ-He; Thu, 07 Jun 2012 17:03: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 1Scg7H-0003KQ-7h
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:03:23 +0000
Received: from [85.158.143.35:47092] by server-3.bemta-4.messagelabs.com id
	42/B1-29237-ADED0DF4; Thu, 07 Jun 2012 17:03:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339088601!7552666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8445 invoked from network); 7 Jun 2012 17:03:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:03:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	18:03:00 +0100
Message-ID: <1339088579.22331.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 7 Jun 2012 18:02:59 +0100
In-Reply-To: <1339062030.15265.53.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com>
	<1338990925.32319.103.camel@zakaz.uk.xensource.com>
	<1339062030.15265.53.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 10:40 +0100, Ian Campbell wrote:
> More head scratching required I think!

This turned out to be the problem with not initialising cpu_sibling_mask
properly, see the thread against "[PATCH 16/38] arm: Add simple
cpu_{sibling,core}_mask".

Having fixed that I updated based on your comments to:

8<-----------------------------------------------------------

>From 75cff29f4645dd19d07175109b5891fd44de9d60 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 13 Apr 2012 16:07:21 +0100
Subject: [PATCH] arm: allocate and setup a guest vcpu.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c         |   67 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/dummy.S          |    3 --
 xen/include/public/arch-arm.h |    9 -----
 3 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9339a11..b099d91 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
     free_xenheap_page(v);
 }
 
+struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+{
+    return xmalloc(struct vcpu_guest_context);
+
+}
+
+void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
+{
+    xfree(vgc);
+}
+
 int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
@@ -212,6 +223,62 @@ void arch_domain_destroy(struct domain *d)
     /* domain_vgic_destroy */
 }
 
+static int is_guest_psr(uint32_t psr)
+{
+    switch (psr & PSR_MODE_MASK)
+    {
+    case PSR_MODE_USR:
+    case PSR_MODE_FIQ:
+    case PSR_MODE_IRQ:
+    case PSR_MODE_SVC:
+    case PSR_MODE_ABT:
+    case PSR_MODE_UND:
+    case PSR_MODE_SYS:
+        return 1;
+    case PSR_MODE_MON:
+    case PSR_MODE_HYP:
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Initialise VCPU state. The context can be supplied by either the
+ * toolstack (XEN_DOMCTL_setvcpucontext) or the guest
+ * (VCPUOP_initialise) and therefore must be properly validated.
+ */
+int arch_set_info_guest(
+    struct vcpu *v, vcpu_guest_context_u c)
+{
+    struct cpu_user_regs *regs = &c.nat->user_regs;
+
+    if ( !is_guest_psr(regs->cpsr) )
+        return -EINVAL;
+
+    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
+        return -EINVAL;
+    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
+        return -EINVAL;
+    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
+        return -EINVAL;
+    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
+        return -EINVAL;
+    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
+        return -EINVAL;
+
+    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+
+    /* XXX other state:
+     * - SCTLR
+     * - TTBR0/1
+     * - TTBCR
+     */
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
+
 void arch_dump_domain_info(struct domain *d)
 {
 }
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 016340c..3b48917 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
 DUMMY(pirq_set_affinity);
 
 /* VCPU */
-DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1b1bcf3..e439727 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
-    union {
-        uint32_t reg[16];
-        struct {
-            uint32_t __pad[12];
-            uint32_t sp; /* r13 */
-            uint32_t lr; /* r14 */
-            uint32_t pc; /* r15 */
-        };
-    };
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Thu Jun 07 17:04:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scg8R-0003V4-5c; Thu, 07 Jun 2012 17:04:35 +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 1Scg8Q-0003Uv-9R
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:04:34 +0000
Received: from [193.109.254.147:53726] by server-8.bemta-14.messagelabs.com id
	78/97-27132-12FD0DF4; Thu, 07 Jun 2012 17:04:33 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339088672!8618957!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1487 invoked from network); 7 Jun 2012 17:04:33 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:04:33 -0000
Received: by lahc1 with SMTP id c1so753351lah.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 10:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=BY7Ul3pyZpc6MtF5nMinxvknZD8Sakuem6GV0M1GU4E=;
	b=B98c9br4VoBHna6HXINdgZdSvRB2NWbWdStKwCGW04ijEOna5Th45TgUgRGS60ZvBn
	U1/YdMS4lxe5KSEWjpnXkVfsG6nuWgKbSzHRIsUg7ec2KL1zT8YeSb89Ct5hAd2TQ5zY
	5gvjAemcJep0qrUwq3iPEtesjiC7cfXXq9uCl83O8rCJg7vCHYVyzXDoP3CLeQ7VoKy6
	xGjlGnOwooEMVt0U1CShrw6ihqDoG/bhk1onpxqvUA0e0200fjwhJ9msaKR2fm6vHmXz
	6uHEcHX7LE4CuQCgMdZNs2S54/5zTCWF456dKVdyFOaXjpxfIanyfL+3uwsDWGvI+blK
	U/AQ==
MIME-Version: 1.0
Received: by 10.152.111.200 with SMTP id ik8mr3400727lab.15.1339088672424;
	Thu, 07 Jun 2012 10:04:32 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 10:04:32 -0700 (PDT)
In-Reply-To: <20120607151246.GN9472@phenom.dumpdata.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
	<8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
	<20120607151246.GN9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 13:04:32 -0400
X-Google-Sender-Auth: QMVFgCqaDsIF2bgqEU9nE7QLz7s
Message-ID: <CAOvdn6X3tzD29CSwEP7AojvTEYgUgxZ-aRROsCP6wWJZKMvvGw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: James Paton <paton@cs.wisc.edu>, Ian Campbell <Ian.Campbell@citrix.com>,
	Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 patch is in reverse of what it should be.

On Thu, Jun 7, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote:
>> Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I've attached a patch for 3.3.6 in case anyone would find it useful.
>
> You sure this is the right patch? It looks to be removing most of the code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:04:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scg8R-0003V4-5c; Thu, 07 Jun 2012 17:04:35 +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 1Scg8Q-0003Uv-9R
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:04:34 +0000
Received: from [193.109.254.147:53726] by server-8.bemta-14.messagelabs.com id
	78/97-27132-12FD0DF4; Thu, 07 Jun 2012 17:04:33 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339088672!8618957!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1487 invoked from network); 7 Jun 2012 17:04:33 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:04:33 -0000
Received: by lahc1 with SMTP id c1so753351lah.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 10:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=BY7Ul3pyZpc6MtF5nMinxvknZD8Sakuem6GV0M1GU4E=;
	b=B98c9br4VoBHna6HXINdgZdSvRB2NWbWdStKwCGW04ijEOna5Th45TgUgRGS60ZvBn
	U1/YdMS4lxe5KSEWjpnXkVfsG6nuWgKbSzHRIsUg7ec2KL1zT8YeSb89Ct5hAd2TQ5zY
	5gvjAemcJep0qrUwq3iPEtesjiC7cfXXq9uCl83O8rCJg7vCHYVyzXDoP3CLeQ7VoKy6
	xGjlGnOwooEMVt0U1CShrw6ihqDoG/bhk1onpxqvUA0e0200fjwhJ9msaKR2fm6vHmXz
	6uHEcHX7LE4CuQCgMdZNs2S54/5zTCWF456dKVdyFOaXjpxfIanyfL+3uwsDWGvI+blK
	U/AQ==
MIME-Version: 1.0
Received: by 10.152.111.200 with SMTP id ik8mr3400727lab.15.1339088672424;
	Thu, 07 Jun 2012 10:04:32 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 10:04:32 -0700 (PDT)
In-Reply-To: <20120607151246.GN9472@phenom.dumpdata.com>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
	<8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
	<20120607151246.GN9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 13:04:32 -0400
X-Google-Sender-Auth: QMVFgCqaDsIF2bgqEU9nE7QLz7s
Message-ID: <CAOvdn6X3tzD29CSwEP7AojvTEYgUgxZ-aRROsCP6wWJZKMvvGw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: James Paton <paton@cs.wisc.edu>, Ian Campbell <Ian.Campbell@citrix.com>,
	Daniel Kiper <dkiper@net-space.pl>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 patch is in reverse of what it should be.

On Thu, Jun 7, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote:
>> Thank you! I am using 3.3.6, but by manually applying your patch, I got it to work. I've attached a patch for 3.3.6 in case anyone would find it useful.
>
> You sure this is the right patch? It looks to be removing most of the code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:05:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scg90-0003Zk-J4; Thu, 07 Jun 2012 17:05: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 1Scg8z-0003ZT-82
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:05:09 +0000
Received: from [85.158.138.51:41286] by server-7.bemta-3.messagelabs.com id
	84/DC-01983-44FD0DF4; Thu, 07 Jun 2012 17:05:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339088707!22421364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6551 invoked from network); 7 Jun 2012 17:05:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:05:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:05:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:05:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scg8w-0001Qk-Ue; Thu, 07 Jun 2012 17:05:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scg8w-0008L2-TS;
	Thu, 07 Jun 2012 18:05:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.57154.896582.606950@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:05:06 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0DD03.2020704@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
	<4FD0DD03.2020704@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 v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> Ian Jackson wrote:
> > And you're using `internal' here to mean `internal to libxl'.  I think
> > that's clear from the name (which has `__').  Whereas on first reading
> > it sounds like you mean `internal to the device adding machinery' -
> > but `libxl__device_disk_add' is the main entrypoint to that
> > machinery.
> 
> I've used 'internal' here to reflex the difference between 
> libxl_device_disk_add and libxl__device_disk_add, but probably leads to 
> confusion.

Yes.

> Well the order is the following:
> 
> libxl__device_{disk/nic}_add (device type dependant function) -> 
> libxl__initiate_device_add (device type independent).

Yes.

> I'm really bad about this naming thing. But the fact is that 
> libxl__initiate_device_add is not a good name, since when we call this 
> function the device is already added (to xenstore), this merely waits 
> for it to reach the desired state and performs the necessary actions to 
> "add" it to the guest (call hotplug scripts). Maybe "connect" is a more 
> appropriate name than "add".

Perhaps so.

> I liked the nomenclature because it follows the same style as 
> libxl__initiate_device_remove, and I think (and I might be wrong) it 
> makes things easier to understand.

But  libxl__initiate_device_remove  _is_ the function which actually
initiates a device removal.  It isn't an internal helper for a
family of  libxl__device_FOO_remove  functions.

If it were symmetrical,  libxl__initate_device_add  would be the
single entrypoint and it would call something kind-specific as a helper.
That's what the comments and names seem to suggest to me, apart from
the explicit statement that it's the other way around.

Hence my feeling that it needs to be clarified and perhaps this
function renamed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:05:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scg90-0003Zk-J4; Thu, 07 Jun 2012 17:05: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 1Scg8z-0003ZT-82
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:05:09 +0000
Received: from [85.158.138.51:41286] by server-7.bemta-3.messagelabs.com id
	84/DC-01983-44FD0DF4; Thu, 07 Jun 2012 17:05:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339088707!22421364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6551 invoked from network); 7 Jun 2012 17:05:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:05:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:05:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:05:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scg8w-0001Qk-Ue; Thu, 07 Jun 2012 17:05:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scg8w-0008L2-TS;
	Thu, 07 Jun 2012 18:05:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.57154.896582.606950@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:05:06 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0DD03.2020704@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
	<4FD0DD03.2020704@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 v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> Ian Jackson wrote:
> > And you're using `internal' here to mean `internal to libxl'.  I think
> > that's clear from the name (which has `__').  Whereas on first reading
> > it sounds like you mean `internal to the device adding machinery' -
> > but `libxl__device_disk_add' is the main entrypoint to that
> > machinery.
> 
> I've used 'internal' here to reflex the difference between 
> libxl_device_disk_add and libxl__device_disk_add, but probably leads to 
> confusion.

Yes.

> Well the order is the following:
> 
> libxl__device_{disk/nic}_add (device type dependant function) -> 
> libxl__initiate_device_add (device type independent).

Yes.

> I'm really bad about this naming thing. But the fact is that 
> libxl__initiate_device_add is not a good name, since when we call this 
> function the device is already added (to xenstore), this merely waits 
> for it to reach the desired state and performs the necessary actions to 
> "add" it to the guest (call hotplug scripts). Maybe "connect" is a more 
> appropriate name than "add".

Perhaps so.

> I liked the nomenclature because it follows the same style as 
> libxl__initiate_device_remove, and I think (and I might be wrong) it 
> makes things easier to understand.

But  libxl__initiate_device_remove  _is_ the function which actually
initiates a device removal.  It isn't an internal helper for a
family of  libxl__device_FOO_remove  functions.

If it were symmetrical,  libxl__initate_device_add  would be the
single entrypoint and it would call something kind-specific as a helper.
That's what the comments and names seem to suggest to me, apart from
the explicit statement that it's the other way around.

Hence my feeling that it needs to be clarified and perhaps this
function renamed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgCJ-00040p-73; Thu, 07 Jun 2012 17:08:35 +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 1ScgCH-00040U-4o
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:08:33 +0000
Received: from [85.158.143.35:45035] by server-1.bemta-4.messagelabs.com id
	34/AB-10042-010E0DF4; Thu, 07 Jun 2012 17:08:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339088911!14890087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 916 invoked from network); 7 Jun 2012 17:08:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:07:43 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	18:07:43 +0100
Message-ID: <4FD0DFDC.4020602@citrix.com>
Date: Thu, 7 Jun 2012 19:07:40 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
	<4FD0DD03.2020704@citrix.com>
	<20432.57154.896582.606950@mariner.uk.xensource.com>
In-Reply-To: <20432.57154.896582.606950@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> Ian Jackson wrote:
>>> And you're using `internal' here to mean `internal to libxl'.  I think
>>> that's clear from the name (which has `__').  Whereas on first reading
>>> it sounds like you mean `internal to the device adding machinery' -
>>> but `libxl__device_disk_add' is the main entrypoint to that
>>> machinery.
>> I've used 'internal' here to reflex the difference between
>> libxl_device_disk_add and libxl__device_disk_add, but probably leads to
>> confusion.
>
> Yes.
>
>> Well the order is the following:
>>
>> libxl__device_{disk/nic}_add (device type dependant function) ->
>> libxl__initiate_device_add (device type independent).
>
> Yes.
>
>> I'm really bad about this naming thing. But the fact is that
>> libxl__initiate_device_add is not a good name, since when we call this
>> function the device is already added (to xenstore), this merely waits
>> for it to reach the desired state and performs the necessary actions to
>> "add" it to the guest (call hotplug scripts). Maybe "connect" is a more
>> appropriate name than "add".
>
> Perhaps so.
>
>> I liked the nomenclature because it follows the same style as
>> libxl__initiate_device_remove, and I think (and I might be wrong) it
>> makes things easier to understand.
>
> But  libxl__initiate_device_remove  _is_ the function which actually
> initiates a device removal.  It isn't an internal helper for a
> family of  libxl__device_FOO_remove  functions.
>
> If it were symmetrical,  libxl__initate_device_add  would be the
> single entrypoint and it would call something kind-specific as a helper.
> That's what the comments and names seem to suggest to me, apart from
> the explicit statement that it's the other way around.
>
> Hence my feeling that it needs to be clarified and perhaps this
> function renamed.

What about libxl__initiate_device_connection?

and thanks for reviewing the code :).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgCJ-00040p-73; Thu, 07 Jun 2012 17:08:35 +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 1ScgCH-00040U-4o
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:08:33 +0000
Received: from [85.158.143.35:45035] by server-1.bemta-4.messagelabs.com id
	34/AB-10042-010E0DF4; Thu, 07 Jun 2012 17:08:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339088911!14890087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 916 invoked from network); 7 Jun 2012 17:08:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:07:43 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	18:07:43 +0100
Message-ID: <4FD0DFDC.4020602@citrix.com>
Date: Thu, 7 Jun 2012 19:07:40 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
	<4FD0DD03.2020704@citrix.com>
	<20432.57154.896582.606950@mariner.uk.xensource.com>
In-Reply-To: <20432.57154.896582.606950@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> Ian Jackson wrote:
>>> And you're using `internal' here to mean `internal to libxl'.  I think
>>> that's clear from the name (which has `__').  Whereas on first reading
>>> it sounds like you mean `internal to the device adding machinery' -
>>> but `libxl__device_disk_add' is the main entrypoint to that
>>> machinery.
>> I've used 'internal' here to reflex the difference between
>> libxl_device_disk_add and libxl__device_disk_add, but probably leads to
>> confusion.
>
> Yes.
>
>> Well the order is the following:
>>
>> libxl__device_{disk/nic}_add (device type dependant function) ->
>> libxl__initiate_device_add (device type independent).
>
> Yes.
>
>> I'm really bad about this naming thing. But the fact is that
>> libxl__initiate_device_add is not a good name, since when we call this
>> function the device is already added (to xenstore), this merely waits
>> for it to reach the desired state and performs the necessary actions to
>> "add" it to the guest (call hotplug scripts). Maybe "connect" is a more
>> appropriate name than "add".
>
> Perhaps so.
>
>> I liked the nomenclature because it follows the same style as
>> libxl__initiate_device_remove, and I think (and I might be wrong) it
>> makes things easier to understand.
>
> But  libxl__initiate_device_remove  _is_ the function which actually
> initiates a device removal.  It isn't an internal helper for a
> family of  libxl__device_FOO_remove  functions.
>
> If it were symmetrical,  libxl__initate_device_add  would be the
> single entrypoint and it would call something kind-specific as a helper.
> That's what the comments and names seem to suggest to me, apart from
> the explicit statement that it's the other way around.
>
> Hence my feeling that it needs to be clarified and perhaps this
> function renamed.

What about libxl__initiate_device_connection?

and thanks for reviewing the code :).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:10:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:10: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 1ScgDv-00047n-Ms; Thu, 07 Jun 2012 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 <paton@cs.wisc.edu>) id 1ScgDu-00047g-CF
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:10:14 +0000
Received: from [85.158.139.83:59368] by server-2.bemta-5.messagelabs.com id
	F2/C3-20827-570E0DF4; Thu, 07 Jun 2012 17:10:13 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339089011!30985678!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21175 invoked from network); 7 Jun 2012 17:10:12 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:10:12 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q57HA7qV017786
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 7 Jun 2012 12:10:07 -0500
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1"
From: James Paton <paton@cs.wisc.edu>
In-Reply-To: <CAOvdn6X3tzD29CSwEP7AojvTEYgUgxZ-aRROsCP6wWJZKMvvGw@mail.gmail.com>
Date: Thu, 7 Jun 2012 12:10:05 -0500
Message-Id: <DBF88F6C-83F5-439E-A54D-1E14B6FD12DB@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
	<8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
	<20120607151246.GN9472@phenom.dumpdata.com>
	<CAOvdn6X3tzD29CSwEP7AojvTEYgUgxZ-aRROsCP6wWJZKMvvGw@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
X-Mailer: Apple Mail (2.1278)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Daniel Kiper <dkiper@net-space.pl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=iso-8859-1

Oops, sorry. This is my first patch ever. Is this one better?


--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Disposition: attachment;
	filename=hvc.patch
Content-Type: application/octet-stream;
	name="hvc.patch"
Content-Transfer-Encoding: 7bit

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4e517d4..c4c38a5 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -66,6 +66,7 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
+#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -759,6 +760,12 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+	
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f2ce60a..64b78f7 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -474,8 +474,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+void xen_send_IPI_mask(const struct cpumask *mask, 
+		int vector)
 {
 	unsigned cpu;
 
@@ -504,6 +504,38 @@ static void xen_smp_send_call_function_single_ipi(int cpu)
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
+void xen_send_IPI_all(int vector)
+{
+	xen_send_IPI_mask(cpu_online_mask, vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	xen_send_IPI_one(smp_processor_id(), vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+	       int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+	
+	if (!(num_online_cpus() > 1))
+		return;
+	
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+	
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
+}
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8e684e4
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_SMP_H
+#define _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+	int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index b6b2d18..401e9e3 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -775,13 +775,10 @@ int hvc_poll_init(struct tty_driver *driver, int line, char *options)
 
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
-	struct tty_struct *tty = driver->ttys[0];
-	struct hvc_struct *hp = tty->driver_data;
 	int n;
 	char ch;
 
-	n = hp->ops->get_chars(hp->vtermno, &ch, 1);
-
+	n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
 	if (n == 0)
 		return NO_POLL_CHAR;
 
@@ -790,12 +787,10 @@ static int hvc_poll_get_char(struct tty_driver *driver, int line)
 
 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
-	struct tty_struct *tty = driver->ttys[0];
-	struct hvc_struct *hp = tty->driver_data;
 	int n;
 
 	do {
-		n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+		n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
 	} while (n <= 0);
 }
 #endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 7fda904..1be125f 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -576,12 +576,14 @@ return_normal:
 		kgdb_roundup_cpus(flags);
 #endif
 
+#ifndef CONFIG_XEN
 	/*
 	 * Wait for the other CPUs to be notified and be waiting for us:
 	 */
 	while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
 				atomic_read(&slaves_in_kgdb)) != online_cpus)
 		cpu_relax();
+#endif
 
 	/*
 	 * At this point the primary processor is completely

--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1



On Jun 7, 2012, at 12:04 PM, Ben Guthro wrote:

> The patch is in reverse of what it should be.
>=20
> On Thu, Jun 7, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote:
>>> Thank you! I am using 3.3.6, but by manually applying your patch, I =
got it to work. I've attached a patch for 3.3.6 in case anyone would =
find it useful.
>>=20
>> You sure this is the right patch? It looks to be removing most of the =
code.


--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1--


From xen-devel-bounces@lists.xen.org Thu Jun 07 17:10:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:10: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 1ScgDv-00047n-Ms; Thu, 07 Jun 2012 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 <paton@cs.wisc.edu>) id 1ScgDu-00047g-CF
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:10:14 +0000
Received: from [85.158.139.83:59368] by server-2.bemta-5.messagelabs.com id
	F2/C3-20827-570E0DF4; Thu, 07 Jun 2012 17:10:13 +0000
X-Env-Sender: paton@cs.wisc.edu
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339089011!30985678!1
X-Originating-IP: [128.105.6.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21175 invoked from network); 7 Jun 2012 17:10:12 -0000
Received: from sabe.cs.wisc.edu (HELO sabe.cs.wisc.edu) (128.105.6.20)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:10:12 -0000
Received: from [192.168.11.49] (97-87-15-71.dhcp.mdsn.wi.charter.com
	[97.87.15.71]) (authenticated bits=0)
	by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q57HA7qV017786
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 7 Jun 2012 12:10:07 -0500
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1"
From: James Paton <paton@cs.wisc.edu>
In-Reply-To: <CAOvdn6X3tzD29CSwEP7AojvTEYgUgxZ-aRROsCP6wWJZKMvvGw@mail.gmail.com>
Date: Thu, 7 Jun 2012 12:10:05 -0500
Message-Id: <DBF88F6C-83F5-439E-A54D-1E14B6FD12DB@cs.wisc.edu>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606125047.GA12043@router-fw-old.local.net-space.pl>
	<BF75E04A-94D4-46FC-AFB1-2D4860BE6438@cs.wisc.edu>
	<CAOvdn6W4qWNPgVAJ3nCxjoC4N-cgHB+zTmYOZhpveaEAArKpVg@mail.gmail.com>
	<8BFFFA2F-F438-42FB-9FBB-6C4775387E4D@cs.wisc.edu>
	<20120607151246.GN9472@phenom.dumpdata.com>
	<CAOvdn6X3tzD29CSwEP7AojvTEYgUgxZ-aRROsCP6wWJZKMvvGw@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
X-Mailer: Apple Mail (2.1278)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Daniel Kiper <dkiper@net-space.pl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=iso-8859-1

Oops, sorry. This is my first patch ever. Is this one better?


--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Disposition: attachment;
	filename=hvc.patch
Content-Type: application/octet-stream;
	name="hvc.patch"
Content-Transfer-Encoding: 7bit

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4e517d4..c4c38a5 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -66,6 +66,7 @@
 
 #include "xen-ops.h"
 #include "mmu.h"
+#include "smp.h"
 #include "multicalls.h"
 
 EXPORT_SYMBOL_GPL(hypercall_page);
@@ -759,6 +760,12 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+	
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
 }
 
 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f2ce60a..64b78f7 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -474,8 +474,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }
 
-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+void xen_send_IPI_mask(const struct cpumask *mask, 
+		int vector)
 {
 	unsigned cpu;
 
@@ -504,6 +504,38 @@ static void xen_smp_send_call_function_single_ipi(int cpu)
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }
 
+void xen_send_IPI_all(int vector)
+{
+	xen_send_IPI_mask(cpu_online_mask, vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	xen_send_IPI_one(smp_processor_id(), vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+	       int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+	
+	if (!(num_online_cpus() > 1))
+		return;
+	
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+	
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
+}
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
new file mode 100644
index 0000000..8e684e4
--- /dev/null
+++ b/arch/x86/xen/smp.h
@@ -0,0 +1,13 @@
+#ifndef _XEN_SMP_H
+#define _XEN_SMP_H
+
+extern void xen_send_IPI_mask(const struct cpumask *mask,
+      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+	int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
+#endif
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index b6b2d18..401e9e3 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -775,13 +775,10 @@ int hvc_poll_init(struct tty_driver *driver, int line, char *options)
 
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
-	struct tty_struct *tty = driver->ttys[0];
-	struct hvc_struct *hp = tty->driver_data;
 	int n;
 	char ch;
 
-	n = hp->ops->get_chars(hp->vtermno, &ch, 1);
-
+	n = cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &ch, 1);
 	if (n == 0)
 		return NO_POLL_CHAR;
 
@@ -790,12 +787,10 @@ static int hvc_poll_get_char(struct tty_driver *driver, int line)
 
 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
-	struct tty_struct *tty = driver->ttys[0];
-	struct hvc_struct *hp = tty->driver_data;
 	int n;
 
 	do {
-		n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+		n = cons_ops[last_hvc]->put_chars(vtermnos[last_hvc], &ch, 1);
 	} while (n <= 0);
 }
 #endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 7fda904..1be125f 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -576,12 +576,14 @@ return_normal:
 		kgdb_roundup_cpus(flags);
 #endif
 
+#ifndef CONFIG_XEN
 	/*
 	 * Wait for the other CPUs to be notified and be waiting for us:
 	 */
 	while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
 				atomic_read(&slaves_in_kgdb)) != online_cpus)
 		cpu_relax();
+#endif
 
 	/*
 	 * At this point the primary processor is completely

--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1



On Jun 7, 2012, at 12:04 PM, Ben Guthro wrote:

> The patch is in reverse of what it should be.
>=20
> On Thu, Jun 7, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Wed, Jun 06, 2012 at 05:07:52PM -0500, James Paton wrote:
>>> Thank you! I am using 3.3.6, but by manually applying your patch, I =
got it to work. I've attached a patch for 3.3.6 in case anyone would =
find it useful.
>>=20
>> You sure this is the right patch? It looks to be removing most of the =
code.


--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--Apple-Mail=_58E9D4CF-565A-41A0-BB74-ECCBD72064B1--


From xen-devel-bounces@lists.xen.org Thu Jun 07 17:11:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgFC-0004E9-65; Thu, 07 Jun 2012 17:11: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 1ScgFA-0004Dt-Bc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:11:32 +0000
Received: from [85.158.138.51:11789] by server-3.bemta-3.messagelabs.com id
	F3/EF-25608-3C0E0DF4; Thu, 07 Jun 2012 17:11:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339089090!31305392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11680 invoked from network); 7 Jun 2012 17:11:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:11:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:11:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:11:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgF8-0001Uz-BM; Thu, 07 Jun 2012 17:11:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgF8-0008Lr-Aa;
	Thu, 07 Jun 2012 18:11:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.57538.313046.472467@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:11:30 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0DFDC.4020602@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
	<4FD0DD03.2020704@citrix.com>
	<20432.57154.896582.606950@mariner.uk.xensource.com>
	<4FD0DFDC.4020602@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 v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> Ian Jackson wrote:
...
> > Hence my feeling that it needs to be clarified and perhaps this
> > function renamed.
> 
> What about libxl__initiate_device_connection?

That would be fine by me.  You'll want to improve the comments too.

> and thanks for reviewing the code :).

You're welcome.  Sorry I found things this time round that I could
have perhaps seen last time...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:11:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgFC-0004E9-65; Thu, 07 Jun 2012 17:11: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 1ScgFA-0004Dt-Bc
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:11:32 +0000
Received: from [85.158.138.51:11789] by server-3.bemta-3.messagelabs.com id
	F3/EF-25608-3C0E0DF4; Thu, 07 Jun 2012 17:11:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339089090!31305392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11680 invoked from network); 7 Jun 2012 17:11:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:11:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12892939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:11:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:11:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgF8-0001Uz-BM; Thu, 07 Jun 2012 17:11:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgF8-0008Lr-Aa;
	Thu, 07 Jun 2012 18:11:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.57538.313046.472467@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:11:30 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0DFDC.4020602@citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.47604.849028.717366@mariner.uk.xensource.com>
	<4FD0DD03.2020704@citrix.com>
	<20432.57154.896582.606950@mariner.uk.xensource.com>
	<4FD0DFDC.4020602@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 v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
> Ian Jackson wrote:
...
> > Hence my feeling that it needs to be clarified and perhaps this
> > function renamed.
> 
> What about libxl__initiate_device_connection?

That would be fine by me.  You'll want to improve the comments too.

> and thanks for reviewing the code :).

You're welcome.  Sorry I found things this time round that I could
have perhaps seen last time...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:16:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgKH-0004TC-6g; Thu, 07 Jun 2012 17:16:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1ScgKG-0004Sj-1a
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:16:48 +0000
Received: from [85.158.143.99:47780] by server-3.bemta-4.messagelabs.com id
	06/CB-29237-EF1E0DF4; Thu, 07 Jun 2012 17:16:46 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339089404!28418877!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7764 invoked from network); 7 Jun 2012 17:16:45 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:16:45 -0000
Received: by eaak12 with SMTP id k12so357265eaa.32
	for <multiple recipients>; Thu, 07 Jun 2012 10:16:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc
	:subject:references:in-reply-to:content-type;
	bh=+dQE84Lyt4jpZ0IJZeLEfv6m4bSb6fZCJtgrrEQt9mk=;
	b=nMTP2mzqExuIfn26/xtC9g5KcqsUx/BT31cR94P8NimlVSWwCk1wWQ3V2WG4RcIwQJ
	qnD+uDzf06sJVxpnh6EL/0jkISUrejH271+8re6WZ+ipQlIqz1Gp4vpQeA2kZEjf3xJB
	siFpwIDoN+K3XLGGnrXDpW5agPeLg6cX6003SIehW7GTC8t/K9N23JnTCjc3k+5T8kxT
	YgyJTWxZdiGvsYSHNEVTSMPucLHzvbybLxWAm0E6WDyljW3dvAIZB6m2h6UmGKVjDXeY
	odARLxZG11hT8SmwFbY8Q7rOpWDTcU+cetYuqiH6WjIEejzpTkWloPKrFdOYfj5zZHgX
	y0EA==
Received: by 10.14.185.137 with SMTP id u9mr1569216eem.220.1339089404594;
	Thu, 07 Jun 2012 10:16:44 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id m5sm12981044eeh.17.2012.06.07.10.16.40
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 10:16:42 -0700 (PDT)
Message-ID: <4FD0E1F4.4020203@xen.org>
Date: Thu, 07 Jun 2012 18:16:36 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
	<CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
In-Reply-To: <CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, Rolu <rolu@roce.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-devel@lists.xen.org, xen-users@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
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="===============2805034523586149923=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2805034523586149923==
Content-Type: multipart/alternative;
 boundary="------------000207000704050909050209"

This is a multi-part message in MIME format.
--------------000207000704050909050209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 07/06/2012 14:14, George Dunlap wrote:
> Sorry to throw in a criticism without a constructive solution, but I 
> just want to register one opinion: To me clicking on a link and seeing 
> a "Category" page says very strongly, "I couldn't be bothered to 
> actually do any work here; I'll leave you to do all the work to figure 
> out what page you need." 
One question: do you feel this for any category page, or just "empty" 
category pages? For example, if the content listed in 
http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals was actually the 
first thing you saw when going to 
http://wiki.xen.org/wiki/Category:Manual would you still feel that way?

> When I encounter a Category page on my walk through the Xen wiki, I 
> don't even look, but immediately turn to Google. I think a page which 
> is has some kind of logical flow to it but perhaps a little out-dated 
> is much better than a page which just tosses up a bunch of titles in 
> no order and lets you figure it out. 
There is no reason why a category page cannot have a logical flow at the 
top and just the list of articles at the bottom.

> I can certainly see that there were "liveness" problems with summary 
> pages; but I don't think that the Categories pages, as we have now, 
> really help that much. 
Right now they are just indexes. The advantage of using category pages 
with content at the top is that it is relatively easy to make sure that 
every article in the category is in some kind of logical group.

> I think in an ideal world, we'd have people who were "maintainers" of
> the wiki just like there are maintainers of different subsections of
> the codebase.  Until that time, could we maybe draw up a set of
> "tests" to run on the docs, which can be assigned to people on DocDay?
>   One simple thing could be, "Make sure X page is up-to-date" (which
> may include, "Look at the Category: page and make sure everything
> there is listed somewhere on the manually-generated page"); another
> could be a scenario, "Pretend you're a [foo] and you want to know
> [bar].  Start at the top level page and make sure you can find all the
> information you need."  If each "test" was something any motivated
> developer/community member could do, and only took 5-10 minutes, it
> should be pretty sustainable.  What do you think?
Again, that would be almost a case in point for having some better 
manually created index at the top of a category page.
If there was an easy way of finding out what is new in a category index 
(I am not sure it is), then creating such tests would be relatively easy.

However to be honest, there were already "easy" items like this since 
the beginning of docs days, which have been on the TODO list since day 
1. E.g.
* http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting
* http://wiki.xen.org/wiki/Category:Contains_TODO
* http://wiki.xen.org/wiki/Category:Contains_Needs_Action

But apart from me, nobody really cares. So having some tests won't work, 
unless people will execute them. And I don't have much hope for that.

> One thing that might make the Category: page more useful is if we
> could include "index tags" on articles, and then sort the Category:
> pages by those tags instead of by title.  But I'm not sure how easy
> that is to do with the current wiki.
I am not quite sure what you mean. There are actually a few extensions 
which may deliver what you need, but of course we likely wont be able to 
install these as these dont come as Debian packages.

With those type of plug-ins it would be possible to create indexes 
using  criteria such as:
  - List Xen Tutorials (i.e. articles in Xen and Tutorials)
  - List Xen Tutorials for Debian
  - List XCP FAQs for Debian that have been edited recently
  - Etc.

Examples of such extensions are:

  * Semantic MediaWiki <http://semantic-mediawiki.org>
      o <http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki#Where_SMW_can_help>allows
        further intersection with sets of pages defined in terms of
        relations and attributes
      o <http://semantic-mediawiki.org/wiki/Help:Inline_queries>provides
        relation- and attribute-related info about the selected pages
        and in-page display on any page of categories the same or
        another page is in

  * DynamicPageList
    <http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28third-party%29>
    (ext) or DynamicPageList
    <http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28Wikimedia%29>
    (MW) extension can be used to:
      o intersection of categories
      o generate a list of all those articles (or a random sample)
      o show metadata of the articles (popularity, date of last update, ..)
      o show one or more chapters of the articles ('transclude' content)
      o show parameter values which are passed to the common template
      o order articles appropriately
      o present the result in a sortable table (e.g.)
      o use multi column output

  * Forum <http://peize.wikia.com/wiki/Help:Forum>
      o intersection of categories and complements of categories
      o provides the time of last edit for each page




--------------000207000704050909050209
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">
    On 07/06/2012 14:14, George Dunlap wrote:
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">
      Sorry to throw in a criticism without a constructive solution, but
      I
      just want to register one opinion: To me clicking on a link and
      seeing
      a "Category" page says very strongly, "I couldn't be bothered to
      actually do any work here; I'll leave you to do all the work to
      figure
      out what page you need." </blockquote>
    One question: do you feel this for any category page, or just
    "empty" category pages? For example, if the content listed in <a
      class="moz-txt-link-freetext"
      href="http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals">http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals</a>
    was actually the first thing you saw when going to
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Manual">http://wiki.xen.org/wiki/Category:Manual</a> would you still feel that
    way?<br>
    <br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">When I encounter a Category page on my walk
      through the Xen wiki, I don't even look, but immediately turn to
      Google. I think a page which is has some kind of logical flow to
      it
      but perhaps a little out-dated is much better than a page which
      just
      tosses up a bunch of titles in no order and lets you figure it
      out.
    </blockquote>
    There is no reason why a category page cannot have a logical flow at
    the top and just the list of articles at the bottom.<br>
    <br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">I can certainly see that there were "liveness"
      problems with summary
      pages; but I don't think that the Categories pages, as we have
      now,
      really help that much.
    </blockquote>
    Right now they are just indexes. The advantage of using category
    pages with content at the top is that it is relatively easy to make
    sure that every article in the category is in some kind of logical
    group.<br>
    &nbsp;<br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">
      <pre wrap="">I think in an ideal world, we'd have people who were "maintainers" of
the wiki just like there are maintainers of different subsections of
the codebase.  Until that time, could we maybe draw up a set of
"tests" to run on the docs, which can be assigned to people on DocDay?
 One simple thing could be, "Make sure X page is up-to-date" (which
may include, "Look at the Category: page and make sure everything
there is listed somewhere on the manually-generated page"); another
could be a scenario, "Pretend you're a [foo] and you want to know
[bar].  Start at the top level page and make sure you can find all the
information you need."  If each "test" was something any motivated
developer/community member could do, and only took 5-10 minutes, it
should be pretty sustainable.  What do you think?</pre>
    </blockquote>
    Again, that would be almost a case in point for having some better
    manually created index at the top of a category page. <br>
    If there was an easy way of finding out what is new in a category
    index (I am not sure it is), then creating such tests would be
    relatively easy. <br>
    <br>
    However to be honest, there were already "easy" items like this
    since the beginning of docs days, which have been on the TODO list
    since day 1. E.g.<br>
    * <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting">http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting</a><br>
    * <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Contains_TODO">http://wiki.xen.org/wiki/Category:Contains_TODO</a><br>
    * <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Contains_Needs_Action">http://wiki.xen.org/wiki/Category:Contains_Needs_Action</a><br>
    <br>
    But apart from me, nobody really cares. So having some tests won't
    work, unless people will execute them. And I don't have much hope
    for that.<br>
    <br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">
      <pre wrap="">One thing that might make the Category: page more useful is if we
could include "index tags" on articles, and then sort the Category:
pages by those tags instead of by title.  But I'm not sure how easy
that is to do with the current wiki.
</pre>
    </blockquote>
    I am not quite sure what you mean. There are actually a few
    extensions which may deliver what you need, but of course we likely
    wont be able to install these as these dont come as Debian packages.
    <br>
    <br>
    With those type of plug-ins it would be possible to create indexes
    using&nbsp; criteria such as:<br>
    &nbsp;- List Xen Tutorials (i.e. articles in Xen and Tutorials) <br>
    &nbsp;- List Xen Tutorials for Debian<br>
    &nbsp;- List XCP FAQs for Debian that have been edited recently<br>
    &nbsp;- Etc.<br>
    <br>
    Examples of such extensions are:<br>
    <ul>
      <li><a href="http://semantic-mediawiki.org">Semantic MediaWiki</a>
        <ul>
          <li><a class="external text"
href="http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki#Where_SMW_can_help"></a>allows
            further intersection with sets of pages defined in terms of
            relations and attributes</li>
          <li><a class="external text"
              href="http://semantic-mediawiki.org/wiki/Help:Inline_queries"></a>provides
            relation- and attribute-related info about the selected
            pages and in-page display on any page of categories the same
            or another page is in</li>
        </ul>
        <br>
      </li>
      <li><a class="external text"
href="http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28third-party%29">DynamicPageList</a>
        (ext) or <a
href="http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28Wikimedia%29">DynamicPageList</a>
        (MW) extension can be used to:
        <ul>
          <li>intersection of categories</li>
          <li>generate a list of all those articles (or a random sample)</li>
          <li>show metadata of the articles (popularity, date of last
            update, ..)</li>
          <li>show one or more chapters of the articles ('transclude'
            content)</li>
          <li>show parameter values which are passed to the common
            template</li>
          <li>order articles appropriately</li>
          <li>present the result in a sortable table (e.g.)</li>
          <li>use multi column output</li>
        </ul>
      </li>
    </ul>
    <ul>
      <li><a rel="nofollow" class="external text"
          href="http://peize.wikia.com/wiki/Help:Forum">Forum</a>
        <ul>
          <li>intersection of categories and complements of categories</li>
          <li>provides the time of last edit for each page</li>
        </ul>
      </li>
    </ul>
    <br>
    <br>
  </body>
</html>

--------------000207000704050909050209--


--===============2805034523586149923==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2805034523586149923==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 17:16:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgKH-0004TC-6g; Thu, 07 Jun 2012 17:16:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1ScgKG-0004Sj-1a
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:16:48 +0000
Received: from [85.158.143.99:47780] by server-3.bemta-4.messagelabs.com id
	06/CB-29237-EF1E0DF4; Thu, 07 Jun 2012 17:16:46 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339089404!28418877!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7764 invoked from network); 7 Jun 2012 17:16:45 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:16:45 -0000
Received: by eaak12 with SMTP id k12so357265eaa.32
	for <multiple recipients>; Thu, 07 Jun 2012 10:16:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc
	:subject:references:in-reply-to:content-type;
	bh=+dQE84Lyt4jpZ0IJZeLEfv6m4bSb6fZCJtgrrEQt9mk=;
	b=nMTP2mzqExuIfn26/xtC9g5KcqsUx/BT31cR94P8NimlVSWwCk1wWQ3V2WG4RcIwQJ
	qnD+uDzf06sJVxpnh6EL/0jkISUrejH271+8re6WZ+ipQlIqz1Gp4vpQeA2kZEjf3xJB
	siFpwIDoN+K3XLGGnrXDpW5agPeLg6cX6003SIehW7GTC8t/K9N23JnTCjc3k+5T8kxT
	YgyJTWxZdiGvsYSHNEVTSMPucLHzvbybLxWAm0E6WDyljW3dvAIZB6m2h6UmGKVjDXeY
	odARLxZG11hT8SmwFbY8Q7rOpWDTcU+cetYuqiH6WjIEejzpTkWloPKrFdOYfj5zZHgX
	y0EA==
Received: by 10.14.185.137 with SMTP id u9mr1569216eem.220.1339089404594;
	Thu, 07 Jun 2012 10:16:44 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id m5sm12981044eeh.17.2012.06.07.10.16.40
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 10:16:42 -0700 (PDT)
Message-ID: <4FD0E1F4.4020203@xen.org>
Date: Thu, 07 Jun 2012 18:16:36 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <m2n.s.1SaP2B-131944@chiark.greenend.org.uk>
	<20425.472.655564.805506@mariner.uk.xensource.com>
	<4FCF78BD.3040909@xen.org>
	<CABs9EjnT2=cJqz9NEeWfVt61c7cekb3M5_YwUbmoxuLnZopFHg@mail.gmail.com>
	<CAOqnZH4qTTQxQkJZpc3oAYwr56YbUtcJ-0HWog5nDbMWncONxg@mail.gmail.com>
	<CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
In-Reply-To: <CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com>
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, Rolu <rolu@roce.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-devel@lists.xen.org, xen-users@lists.xen.org
Subject: Re: [Xen-devel] Proposals/changes for a new Wiki Front-Page - need
 input/mods/creative proposals
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="===============2805034523586149923=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2805034523586149923==
Content-Type: multipart/alternative;
 boundary="------------000207000704050909050209"

This is a multi-part message in MIME format.
--------------000207000704050909050209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 07/06/2012 14:14, George Dunlap wrote:
> Sorry to throw in a criticism without a constructive solution, but I 
> just want to register one opinion: To me clicking on a link and seeing 
> a "Category" page says very strongly, "I couldn't be bothered to 
> actually do any work here; I'll leave you to do all the work to figure 
> out what page you need." 
One question: do you feel this for any category page, or just "empty" 
category pages? For example, if the content listed in 
http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals was actually the 
first thing you saw when going to 
http://wiki.xen.org/wiki/Category:Manual would you still feel that way?

> When I encounter a Category page on my walk through the Xen wiki, I 
> don't even look, but immediately turn to Google. I think a page which 
> is has some kind of logical flow to it but perhaps a little out-dated 
> is much better than a page which just tosses up a bunch of titles in 
> no order and lets you figure it out. 
There is no reason why a category page cannot have a logical flow at the 
top and just the list of articles at the bottom.

> I can certainly see that there were "liveness" problems with summary 
> pages; but I don't think that the Categories pages, as we have now, 
> really help that much. 
Right now they are just indexes. The advantage of using category pages 
with content at the top is that it is relatively easy to make sure that 
every article in the category is in some kind of logical group.

> I think in an ideal world, we'd have people who were "maintainers" of
> the wiki just like there are maintainers of different subsections of
> the codebase.  Until that time, could we maybe draw up a set of
> "tests" to run on the docs, which can be assigned to people on DocDay?
>   One simple thing could be, "Make sure X page is up-to-date" (which
> may include, "Look at the Category: page and make sure everything
> there is listed somewhere on the manually-generated page"); another
> could be a scenario, "Pretend you're a [foo] and you want to know
> [bar].  Start at the top level page and make sure you can find all the
> information you need."  If each "test" was something any motivated
> developer/community member could do, and only took 5-10 minutes, it
> should be pretty sustainable.  What do you think?
Again, that would be almost a case in point for having some better 
manually created index at the top of a category page.
If there was an easy way of finding out what is new in a category index 
(I am not sure it is), then creating such tests would be relatively easy.

However to be honest, there were already "easy" items like this since 
the beginning of docs days, which have been on the TODO list since day 
1. E.g.
* http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting
* http://wiki.xen.org/wiki/Category:Contains_TODO
* http://wiki.xen.org/wiki/Category:Contains_Needs_Action

But apart from me, nobody really cares. So having some tests won't work, 
unless people will execute them. And I don't have much hope for that.

> One thing that might make the Category: page more useful is if we
> could include "index tags" on articles, and then sort the Category:
> pages by those tags instead of by title.  But I'm not sure how easy
> that is to do with the current wiki.
I am not quite sure what you mean. There are actually a few extensions 
which may deliver what you need, but of course we likely wont be able to 
install these as these dont come as Debian packages.

With those type of plug-ins it would be possible to create indexes 
using  criteria such as:
  - List Xen Tutorials (i.e. articles in Xen and Tutorials)
  - List Xen Tutorials for Debian
  - List XCP FAQs for Debian that have been edited recently
  - Etc.

Examples of such extensions are:

  * Semantic MediaWiki <http://semantic-mediawiki.org>
      o <http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki#Where_SMW_can_help>allows
        further intersection with sets of pages defined in terms of
        relations and attributes
      o <http://semantic-mediawiki.org/wiki/Help:Inline_queries>provides
        relation- and attribute-related info about the selected pages
        and in-page display on any page of categories the same or
        another page is in

  * DynamicPageList
    <http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28third-party%29>
    (ext) or DynamicPageList
    <http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28Wikimedia%29>
    (MW) extension can be used to:
      o intersection of categories
      o generate a list of all those articles (or a random sample)
      o show metadata of the articles (popularity, date of last update, ..)
      o show one or more chapters of the articles ('transclude' content)
      o show parameter values which are passed to the common template
      o order articles appropriately
      o present the result in a sortable table (e.g.)
      o use multi column output

  * Forum <http://peize.wikia.com/wiki/Help:Forum>
      o intersection of categories and complements of categories
      o provides the time of last edit for each page




--------------000207000704050909050209
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">
    On 07/06/2012 14:14, George Dunlap wrote:
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">
      Sorry to throw in a criticism without a constructive solution, but
      I
      just want to register one opinion: To me clicking on a link and
      seeing
      a "Category" page says very strongly, "I couldn't be bothered to
      actually do any work here; I'll leave you to do all the work to
      figure
      out what page you need." </blockquote>
    One question: do you feel this for any category page, or just
    "empty" category pages? For example, if the content listed in <a
      class="moz-txt-link-freetext"
      href="http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals">http://wiki.xen.org/wiki/User:Rolu/Books_and_Manuals</a>
    was actually the first thing you saw when going to
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Manual">http://wiki.xen.org/wiki/Category:Manual</a> would you still feel that
    way?<br>
    <br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">When I encounter a Category page on my walk
      through the Xen wiki, I don't even look, but immediately turn to
      Google. I think a page which is has some kind of logical flow to
      it
      but perhaps a little out-dated is much better than a page which
      just
      tosses up a bunch of titles in no order and lets you figure it
      out.
    </blockquote>
    There is no reason why a category page cannot have a logical flow at
    the top and just the list of articles at the bottom.<br>
    <br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">I can certainly see that there were "liveness"
      problems with summary
      pages; but I don't think that the Categories pages, as we have
      now,
      really help that much.
    </blockquote>
    Right now they are just indexes. The advantage of using category
    pages with content at the top is that it is relatively easy to make
    sure that every article in the category is in some kind of logical
    group.<br>
    &nbsp;<br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">
      <pre wrap="">I think in an ideal world, we'd have people who were "maintainers" of
the wiki just like there are maintainers of different subsections of
the codebase.  Until that time, could we maybe draw up a set of
"tests" to run on the docs, which can be assigned to people on DocDay?
 One simple thing could be, "Make sure X page is up-to-date" (which
may include, "Look at the Category: page and make sure everything
there is listed somewhere on the manually-generated page"); another
could be a scenario, "Pretend you're a [foo] and you want to know
[bar].  Start at the top level page and make sure you can find all the
information you need."  If each "test" was something any motivated
developer/community member could do, and only took 5-10 minutes, it
should be pretty sustainable.  What do you think?</pre>
    </blockquote>
    Again, that would be almost a case in point for having some better
    manually created index at the top of a category page. <br>
    If there was an easy way of finding out what is new in a category
    index (I am not sure it is), then creating such tests would be
    relatively easy. <br>
    <br>
    However to be honest, there were already "easy" items like this
    since the beginning of docs days, which have been on the TODO list
    since day 1. E.g.<br>
    * <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting">http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting</a><br>
    * <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Contains_TODO">http://wiki.xen.org/wiki/Category:Contains_TODO</a><br>
    * <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Category:Contains_Needs_Action">http://wiki.xen.org/wiki/Category:Contains_Needs_Action</a><br>
    <br>
    But apart from me, nobody really cares. So having some tests won't
    work, unless people will execute them. And I don't have much hope
    for that.<br>
    <br>
    <blockquote
cite="mid:CAFLBxZYKYvsbKaMPTm3Nx5sj3HXY0Edh3cwU2tVOYsC6dBfciA@mail.gmail.com"
      type="cite">
      <pre wrap="">One thing that might make the Category: page more useful is if we
could include "index tags" on articles, and then sort the Category:
pages by those tags instead of by title.  But I'm not sure how easy
that is to do with the current wiki.
</pre>
    </blockquote>
    I am not quite sure what you mean. There are actually a few
    extensions which may deliver what you need, but of course we likely
    wont be able to install these as these dont come as Debian packages.
    <br>
    <br>
    With those type of plug-ins it would be possible to create indexes
    using&nbsp; criteria such as:<br>
    &nbsp;- List Xen Tutorials (i.e. articles in Xen and Tutorials) <br>
    &nbsp;- List Xen Tutorials for Debian<br>
    &nbsp;- List XCP FAQs for Debian that have been edited recently<br>
    &nbsp;- Etc.<br>
    <br>
    Examples of such extensions are:<br>
    <ul>
      <li><a href="http://semantic-mediawiki.org">Semantic MediaWiki</a>
        <ul>
          <li><a class="external text"
href="http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki#Where_SMW_can_help"></a>allows
            further intersection with sets of pages defined in terms of
            relations and attributes</li>
          <li><a class="external text"
              href="http://semantic-mediawiki.org/wiki/Help:Inline_queries"></a>provides
            relation- and attribute-related info about the selected
            pages and in-page display on any page of categories the same
            or another page is in</li>
        </ul>
        <br>
      </li>
      <li><a class="external text"
href="http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28third-party%29">DynamicPageList</a>
        (ext) or <a
href="http://www.mediawiki.org/wiki/Extension:DynamicPageList_%28Wikimedia%29">DynamicPageList</a>
        (MW) extension can be used to:
        <ul>
          <li>intersection of categories</li>
          <li>generate a list of all those articles (or a random sample)</li>
          <li>show metadata of the articles (popularity, date of last
            update, ..)</li>
          <li>show one or more chapters of the articles ('transclude'
            content)</li>
          <li>show parameter values which are passed to the common
            template</li>
          <li>order articles appropriately</li>
          <li>present the result in a sortable table (e.g.)</li>
          <li>use multi column output</li>
        </ul>
      </li>
    </ul>
    <ul>
      <li><a rel="nofollow" class="external text"
          href="http://peize.wikia.com/wiki/Help:Forum">Forum</a>
        <ul>
          <li>intersection of categories and complements of categories</li>
          <li>provides the time of last edit for each page</li>
        </ul>
      </li>
    </ul>
    <br>
    <br>
  </body>
</html>

--------------000207000704050909050209--


--===============2805034523586149923==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2805034523586149923==--


From xen-devel-bounces@lists.xen.org Thu Jun 07 17:20:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScgNx-0004sK-R2; Thu, 07 Jun 2012 17:20:37 +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 1ScgNw-0004sB-L5
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:20:36 +0000
Received: from [85.158.139.83:62136] by server-5.bemta-5.messagelabs.com id
	DC/5B-04481-3E2E0DF4; Thu, 07 Jun 2012 17:20:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339089633!29786793!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14737 invoked from network); 7 Jun 2012 17:20:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:20:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HKKC6017852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:20:21 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
	q57HKJSl027540
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:20:20 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
	q57HKJBu018310; Thu, 7 Jun 2012 12:20:19 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:20:18 -0700
Date: Thu, 7 Jun 2012 10:20:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607102017.638ea263@mantra.us.oracle.com>
In-Reply-To: <1339050446.6557.19.camel@dagon.hellion.org.uk>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606141751.37305f89@mantra.us.oracle.com>
	<1339050446.6557.19.camel@dagon.hellion.org.uk>
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: James Paton <paton@cs.wisc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012 07:27:26 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-06-06 at 22:17 +0100, Mukesh Rathor wrote:
> > I wrote up a debugger for xen, also (mis)named kdb. It halts the 
> > system, lets you poke memory, data structs, set breakpoints, etc.
> > To use it, you must have prior experience of a kernel debugger. I
> > am attaching patch build for changeset 25287 in unstable tree, if
> > you wanna try it. Start with kdb/README.
> 
> I think this is for the hypervisor itself, right?

kdb can be used to set breakpoints, single step, examine memory of the 
entire system, etc..  so it can be used to debug xen, dom0, domUs. 


> James was asking about debugging the dom0 kernel. I also considered
> mentioning gdbsx but I think that can only work with domU?
 
Right. gdbsx runs on dom0, so can only be used to debug domUs.

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 Jun 07 17:20:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScgNx-0004sK-R2; Thu, 07 Jun 2012 17:20:37 +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 1ScgNw-0004sB-L5
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:20:36 +0000
Received: from [85.158.139.83:62136] by server-5.bemta-5.messagelabs.com id
	DC/5B-04481-3E2E0DF4; Thu, 07 Jun 2012 17:20:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339089633!29786793!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14737 invoked from network); 7 Jun 2012 17:20:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:20:35 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HKKC6017852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:20:21 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
	q57HKJSl027540
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:20:20 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
	q57HKJBu018310; Thu, 7 Jun 2012 12:20:19 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:20:18 -0700
Date: Thu, 7 Jun 2012 10:20:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607102017.638ea263@mantra.us.oracle.com>
In-Reply-To: <1339050446.6557.19.camel@dagon.hellion.org.uk>
References: <64CC3033-765F-450F-A262-B19676ECA99A@cs.wisc.edu>
	<1338974024.32319.29.camel@zakaz.uk.xensource.com>
	<20120606141751.37305f89@mantra.us.oracle.com>
	<1339050446.6557.19.camel@dagon.hellion.org.uk>
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: James Paton <paton@cs.wisc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Debugging Dom0 kernel over serial
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012 07:27:26 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-06-06 at 22:17 +0100, Mukesh Rathor wrote:
> > I wrote up a debugger for xen, also (mis)named kdb. It halts the 
> > system, lets you poke memory, data structs, set breakpoints, etc.
> > To use it, you must have prior experience of a kernel debugger. I
> > am attaching patch build for changeset 25287 in unstable tree, if
> > you wanna try it. Start with kdb/README.
> 
> I think this is for the hypervisor itself, right?

kdb can be used to set breakpoints, single step, examine memory of the 
entire system, etc..  so it can be used to debug xen, dom0, domUs. 


> James was asking about debugging the dom0 kernel. I also considered
> mentioning gdbsx but I think that can only work with domU?
 
Right. gdbsx runs on dom0, so can only be used to debug domUs.

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 Jun 07 17:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScgQw-00053y-EN; Thu, 07 Jun 2012 17:23:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScgQv-00053p-7b
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:23:41 +0000
Received: from [85.158.143.35:61128] by server-2.bemta-4.messagelabs.com id
	BA/DB-17938-C93E0DF4; Thu, 07 Jun 2012 17:23:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339089819!8854411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28075 invoked from network); 7 Jun 2012 17:23:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:23:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:23:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:23:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgQt-0001Yz-3c; Thu, 07 Jun 2012 17:23:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgQt-0008Uo-2s;
	Thu, 07 Jun 2012 18:23:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.58267.74965.486623@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:23:39 +0100
To: Simon Rowe <simon.rowe@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1338973648@drall.uk.xensource.com>
References: <patchbomb.1338973648@drall.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2 V3] xs: fixes to watch thread creation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Simon Rowe writes ("[Xen-devel] [PATCH 0 of 2 V3] xs: fixes to watch thread creation"):
> A pair of patches to the xenstore library that:
> 
>   1) blocks signal delivery before creating the watch wakeup thread
> 
>   2) reduces the stack size of the watch wakeup thread.

Thanks, both:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScgQw-00053y-EN; Thu, 07 Jun 2012 17:23:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScgQv-00053p-7b
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:23:41 +0000
Received: from [85.158.143.35:61128] by server-2.bemta-4.messagelabs.com id
	BA/DB-17938-C93E0DF4; Thu, 07 Jun 2012 17:23:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339089819!8854411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28075 invoked from network); 7 Jun 2012 17:23:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:23:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:23:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:23:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgQt-0001Yz-3c; Thu, 07 Jun 2012 17:23:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgQt-0008Uo-2s;
	Thu, 07 Jun 2012 18:23:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.58267.74965.486623@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:23:39 +0100
To: Simon Rowe <simon.rowe@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1338973648@drall.uk.xensource.com>
References: <patchbomb.1338973648@drall.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 2 V3] xs: fixes to watch thread creation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Simon Rowe writes ("[Xen-devel] [PATCH 0 of 2 V3] xs: fixes to watch thread creation"):
> A pair of patches to the xenstore library that:
> 
>   1) blocks signal delivery before creating the watch wakeup thread
> 
>   2) reduces the stack size of the watch wakeup thread.

Thanks, both:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:29:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScgVt-0005Hr-ER; Thu, 07 Jun 2012 17:28: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 1ScgVr-0005Hj-Qq
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:28:48 +0000
Received: from [193.109.254.147:15044] by server-3.bemta-14.messagelabs.com id
	36/16-05653-FC4E0DF4; Thu, 07 Jun 2012 17:28:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339090124!8704413!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10652 invoked from network); 7 Jun 2012 17:28:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:28:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HRet7023761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:27: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
	q57HRdwZ006224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:27:39 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
	q57HRcF6018180; Thu, 7 Jun 2012 12:27:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:27:38 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1221A4030D; Thu,  7 Jun 2012 13:20:40 -0400 (EDT)
Date: Thu, 7 Jun 2012 13:20:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120607172039.GR9472@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120606205523.GA10891@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 06:45:39AM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
> >>> From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00
> >>> 2001 
> >> From: root <root@ljsromley.bj.intel.com>
> >> Date: Fri, 1 Jun 2012 03:12:51 +0800
> >> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
> >> 
> >> When MCA error occurs, it would be handled by Xen hypervisor first,
> >> and then the error information would be sent to initial domain for
> >> logging. 
> >> 
> >> This patch gets error information from Xen hypervisor and convert
> >> Xen format error into Linux format mcelog. This logic is basically
> >> self-contained, not touching other kernel components.
> >> 
> >> By using tools like mcelog tool users could read specific error
> >> information, like what they did under native Linux.
> >> 
> >> To test follow directions outlined in
> >> Documentation/acpi/apei/einj.txt 
> > 
> > [   53.264610] switch: port 1(eth0) entered forwarding state
> > [ 1058.051938] BUG: sleeping function called from invalid context at
> > /home/konrad/linux/include/linux/kernel.h:199 [ 1058.052066]
> > in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog [
> > 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O
> > 3.5.0-rc1upstream-00041-ga16e594-dirty #2 [ 1058.052235] Call Trace:
> > [ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100 [
> > 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140 [
> > 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190 [ 1058.052461]
> > [<ffffffff81148f4c>] sys_read+0x4c/0x90 [ 1058.052515] 
> > [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1 
> > 
> > ?
> 
> I will debug it. Would you tell me the steps to reproduce the bug, and your .config file?


# echo 0x00000008 > error_type
# echo 1 > error_inject
(XEN) CMCI: send CMCI to DOM0 through virq
[  214.207962] BUG: sleeping function called from invalid context at /home/konradinux/kernel.h:199
[  214.208129] in_atomic(): 1, irqs_disabled(): 0, pid: 4581, name: mcelog
[  214.208242] Pid: 4581, comm: mcelog Tainted: G           O 3.5.0-rc1upstream-00003-g149000b-dirty #1
# [  214.208384] Call Trace:
[  214.208490]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100
[  214.208606]  [<ffffffff81329b0b>] xen_mce_chrdev_read+0xab/0x140
[  214.208715]  [<ffffffff81148945>] vfs_read+0xc5/0x190
[  214.208816]  [<ffffffff81148b0c>] sys_read+0x4c/0x90
[  214.208923]  [<ffffffff815bd039>] system_call_fastpath+0x16/0x1b

> (Some issue w/ my email box this morning, just notice this)


#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.5.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
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=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
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_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_FHANDLE is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
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_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=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

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=64
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_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=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_CGROUP_MEM_RES_CTLR 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 is not set
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_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_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_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_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
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_STOP_MACHINE=y
CONFIG_BLOCK=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
CONFIG_BLOCK_COMPAT=y

#
# 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_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
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_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=500
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
CONFIG_KVM_CLOCK=y
CONFIG_KVM_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_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=512
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_IRQ_TIME_ACCOUNTING=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_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=y
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
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_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=6
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
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 is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_CLEANCACHE=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=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_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
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_CAN_PM_TRACE=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_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT 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

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=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_POWERNOW_K8=m
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_P4_CLOCKMOD=m

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
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=y
CONFIG_PCI_PASID=y
# CONFIG_PCI_IOAPIC is not set
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
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_FAKE 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_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
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_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_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_NFLOG=y
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=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_NF_NAT_FTP=y
CONFIG_NF_NAT_IRC=y
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
CONFIG_NF_NAT_SIP=y
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_NET_DSA is not set
# 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
# CONFIG_BPF_JIT is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE 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
CONFIG_HAVE_BPF_JIT=y

#
# 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
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_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP 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
CONFIG_SCSI_WAIT_SCAN=m

#
# 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_UFSHCD is not set
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
# 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_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 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_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_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 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
#
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_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 is not set
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_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_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_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_OMAP4 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_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_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_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=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_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_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_XILINX_PS_UART is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_HW_RANDOM_VIA=y
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM 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_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_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_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 is not set

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
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_SMB347 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_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_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_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_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_SM501 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_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_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_S5M_CORE 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_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=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_DRM_NOUVEAU_BACKLIGHT is not set
CONFIG_DRM_NOUVEAU_DEBUG=y

#
# 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_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_PROGEAR is not set
# 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_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
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_GENERIC=m
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_LOGITECH=m
CONFIG_HID_LOGITECH_DJ=m
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_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_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
# CONFIG_USB_UAS is not set
CONFIG_USB_LIBUSUAL=y

#
# 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

#
# USB Physical Layer drivers
#
# CONFIG_USB_ISP1301 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_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_OT200 is not set
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# 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_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

#
# 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
CONFIG_VIRTIO_RING=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=y
# CONFIG_VIRTIO_MMIO 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_MCE_LOG=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_RTS_PSTOR 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_PHONE is not set
# CONFIG_USB_WPAN_HCD is not set
# CONFIG_IPACK_BUS is not set
# CONFIG_WIMAX_GDM72XX 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_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_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_STATS=y
# CONFIG_AMD_IOMMU_V2 is not set
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IRQ_REMAP is not set

#
# Remoteproc drivers (EXPERIMENTAL)
#

#
# 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

#
# 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_XATTR=y
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_QUOTACTL_COMPAT=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_RAM is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_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_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_DETECT_HUNG_TASK is not set
# 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_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_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_KOBJECT 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=60
# 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_CPU_NOTIFIER_ERROR_INJECT 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_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=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_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE 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=m
# CONFIG_IOMMU_DEBUG is not set
# 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_INTEL_TXT=y
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_SHA1_SSSE3 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
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_X86_64 is not set
# 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_BLOWFISH_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAMELLIA_X86_64 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_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY 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_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_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_VHOST_NET=y
# CONFIG_BINARY_PRINTF is not set

#
# 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_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=y
# 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_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_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
> 
> Thanks,
> Jinsong
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 07 17:29:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1ScgVt-0005Hr-ER; Thu, 07 Jun 2012 17:28: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 1ScgVr-0005Hj-Qq
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:28:48 +0000
Received: from [193.109.254.147:15044] by server-3.bemta-14.messagelabs.com id
	36/16-05653-FC4E0DF4; Thu, 07 Jun 2012 17:28:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339090124!8704413!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10652 invoked from network); 7 Jun 2012 17:28:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:28:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HRet7023761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:27: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
	q57HRdwZ006224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:27:39 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
	q57HRcF6018180; Thu, 7 Jun 2012 12:27:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:27:38 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1221A4030D; Thu,  7 Jun 2012 13:20:40 -0400 (EDT)
Date: Thu, 7 Jun 2012 13:20:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120607172039.GR9472@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120606205523.GA10891@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 06:45:39AM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
> >>> From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00
> >>> 2001 
> >> From: root <root@ljsromley.bj.intel.com>
> >> Date: Fri, 1 Jun 2012 03:12:51 +0800
> >> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
> >> 
> >> When MCA error occurs, it would be handled by Xen hypervisor first,
> >> and then the error information would be sent to initial domain for
> >> logging. 
> >> 
> >> This patch gets error information from Xen hypervisor and convert
> >> Xen format error into Linux format mcelog. This logic is basically
> >> self-contained, not touching other kernel components.
> >> 
> >> By using tools like mcelog tool users could read specific error
> >> information, like what they did under native Linux.
> >> 
> >> To test follow directions outlined in
> >> Documentation/acpi/apei/einj.txt 
> > 
> > [   53.264610] switch: port 1(eth0) entered forwarding state
> > [ 1058.051938] BUG: sleeping function called from invalid context at
> > /home/konrad/linux/include/linux/kernel.h:199 [ 1058.052066]
> > in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog [
> > 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O
> > 3.5.0-rc1upstream-00041-ga16e594-dirty #2 [ 1058.052235] Call Trace:
> > [ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100 [
> > 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140 [
> > 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190 [ 1058.052461]
> > [<ffffffff81148f4c>] sys_read+0x4c/0x90 [ 1058.052515] 
> > [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1 
> > 
> > ?
> 
> I will debug it. Would you tell me the steps to reproduce the bug, and your .config file?


# echo 0x00000008 > error_type
# echo 1 > error_inject
(XEN) CMCI: send CMCI to DOM0 through virq
[  214.207962] BUG: sleeping function called from invalid context at /home/konradinux/kernel.h:199
[  214.208129] in_atomic(): 1, irqs_disabled(): 0, pid: 4581, name: mcelog
[  214.208242] Pid: 4581, comm: mcelog Tainted: G           O 3.5.0-rc1upstream-00003-g149000b-dirty #1
# [  214.208384] Call Trace:
[  214.208490]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100
[  214.208606]  [<ffffffff81329b0b>] xen_mce_chrdev_read+0xab/0x140
[  214.208715]  [<ffffffff81148945>] vfs_read+0xc5/0x190
[  214.208816]  [<ffffffff81148b0c>] sys_read+0x4c/0x90
[  214.208923]  [<ffffffff815bd039>] system_call_fastpath+0x16/0x1b

> (Some issue w/ my email box this morning, just notice this)


#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.5.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
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=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
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_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_FHANDLE is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
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_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=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

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=64
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_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=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_CGROUP_MEM_RES_CTLR 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 is not set
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_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_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_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_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
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_STOP_MACHINE=y
CONFIG_BLOCK=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
CONFIG_BLOCK_COMPAT=y

#
# 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_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
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_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=500
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
CONFIG_KVM_CLOCK=y
CONFIG_KVM_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_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=512
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_IRQ_TIME_ACCOUNTING=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_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=y
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
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_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=6
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
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 is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_CLEANCACHE=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=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_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
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_CAN_PM_TRACE=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_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT 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

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=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_POWERNOW_K8=m
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_P4_CLOCKMOD=m

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
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=y
CONFIG_PCI_PASID=y
# CONFIG_PCI_IOAPIC is not set
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
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_FAKE 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_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
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_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_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_NFLOG=y
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=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_NF_NAT_FTP=y
CONFIG_NF_NAT_IRC=y
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
CONFIG_NF_NAT_SIP=y
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_NET_DSA is not set
# 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
# CONFIG_BPF_JIT is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE 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
CONFIG_HAVE_BPF_JIT=y

#
# 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
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_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP 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
CONFIG_SCSI_WAIT_SCAN=m

#
# 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_UFSHCD is not set
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
# 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_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 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_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_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 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
#
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_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 is not set
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_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_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_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_OMAP4 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_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_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_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=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_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_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_XILINX_PS_UART is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_HW_RANDOM_VIA=y
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM 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_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_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_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 is not set

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
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_SMB347 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_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_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_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_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_SM501 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_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_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_S5M_CORE 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_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=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_DRM_NOUVEAU_BACKLIGHT is not set
CONFIG_DRM_NOUVEAU_DEBUG=y

#
# 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_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_PROGEAR is not set
# 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_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
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_GENERIC=m
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_LOGITECH=m
CONFIG_HID_LOGITECH_DJ=m
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_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_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
# CONFIG_USB_UAS is not set
CONFIG_USB_LIBUSUAL=y

#
# 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

#
# USB Physical Layer drivers
#
# CONFIG_USB_ISP1301 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_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_OT200 is not set
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# 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_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

#
# 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
CONFIG_VIRTIO_RING=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=y
# CONFIG_VIRTIO_MMIO 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_MCE_LOG=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_RTS_PSTOR 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_PHONE is not set
# CONFIG_USB_WPAN_HCD is not set
# CONFIG_IPACK_BUS is not set
# CONFIG_WIMAX_GDM72XX 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_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_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_STATS=y
# CONFIG_AMD_IOMMU_V2 is not set
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IRQ_REMAP is not set

#
# Remoteproc drivers (EXPERIMENTAL)
#

#
# 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

#
# 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_XATTR=y
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_QUOTACTL_COMPAT=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_RAM is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_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_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_DETECT_HUNG_TASK is not set
# 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_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_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_KOBJECT 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=60
# 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_CPU_NOTIFIER_ERROR_INJECT 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_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=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_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE 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=m
# CONFIG_IOMMU_DEBUG is not set
# 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_INTEL_TXT=y
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_SHA1_SSSE3 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
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_X86_64 is not set
# 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_BLOWFISH_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAMELLIA_X86_64 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_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY 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_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_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_VHOST_NET=y
# CONFIG_BINARY_PRINTF is not set

#
# 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_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=y
# 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_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_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
> 
> Thanks,
> Jinsong
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 07 17:31:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:31:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScgYm-0005RK-8B; Thu, 07 Jun 2012 17:31:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1ScgYl-0005RA-15
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:31:47 +0000
Received: from [193.109.254.147:36663] by server-5.bemta-14.messagelabs.com id
	94/6D-31398-285E0DF4; Thu, 07 Jun 2012 17:31:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339090302!8665301!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7786 invoked from network); 7 Jun 2012 17:31:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:31:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HV2oO032490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:31:03 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q57HV1tR020604
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:31:01 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
	q57HV0TM030952; Thu, 7 Jun 2012 12:31:00 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:31:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 64F804030D; Thu,  7 Jun 2012 13:24:02 -0400 (EDT)
Date: Thu, 7 Jun 2012 13:24:02 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alex Moskalenko <mav@elserv.ru>
Message-ID: <20120607172402.GS9472@phenom.dumpdata.com>
References: <4FD0747D.10103@elserv.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD0747D.10103@elserv.ru>
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: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 01:29:33PM +0400, Alex Moskalenko wrote:
> Hi people,
> 
> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel
> on IBM eServer x3400. Without noacpi command line option dom0 kernel

Well yes! We don't do 'noacpi' Why do you supply 'noacpi'?

> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without
> hypervisor all kernels run without any problems.
> 
> There are several patches (available on http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/kernel-image-xen-dom0,
> commits f1f91babc9cc9402ccee8938b888240f5bae1574,
> 72db7b5e069002765ced64f030c1117d72352331,
> adc4c567a08d4d2377060179639cbfdc3d9d8e0e and
> 9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32
> to boot on this hardware. This patches written by kernel package
> maintainer of ALT Linux distribution. Discussion of this issue is
> available on Sysadmins ALTLinux mailing list
> (http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html
> and follows) in Russian.
> 
> I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need
> this messages for more recent versions of Xen and kernel, or more
> information about hardware, please let me know.

Please provide the crash using the v3.4 kernel.

> 
> Ideally, I would like to run current versions of Xen and Linux
> kernels on this hardware. Can you help me please?

Well sure. But pls explain to me why:
 - you are using 'noacpi'
 - why are not using the v3.4 kernel?
> 
> 
> --
>  WBR, Alex Moskalenko


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 07 17:31:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:31:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScgYm-0005RK-8B; Thu, 07 Jun 2012 17:31:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1ScgYl-0005RA-15
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:31:47 +0000
Received: from [193.109.254.147:36663] by server-5.bemta-14.messagelabs.com id
	94/6D-31398-285E0DF4; Thu, 07 Jun 2012 17:31:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339090302!8665301!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7786 invoked from network); 7 Jun 2012 17:31:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:31:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HV2oO032490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:31:03 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q57HV1tR020604
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:31:01 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
	q57HV0TM030952; Thu, 7 Jun 2012 12:31:00 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:31:00 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 64F804030D; Thu,  7 Jun 2012 13:24:02 -0400 (EDT)
Date: Thu, 7 Jun 2012 13:24:02 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alex Moskalenko <mav@elserv.ru>
Message-ID: <20120607172402.GS9472@phenom.dumpdata.com>
References: <4FD0747D.10103@elserv.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD0747D.10103@elserv.ru>
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: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 01:29:33PM +0400, Alex Moskalenko wrote:
> Hi people,
> 
> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel
> on IBM eServer x3400. Without noacpi command line option dom0 kernel

Well yes! We don't do 'noacpi' Why do you supply 'noacpi'?

> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without
> hypervisor all kernels run without any problems.
> 
> There are several patches (available on http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/kernel-image-xen-dom0,
> commits f1f91babc9cc9402ccee8938b888240f5bae1574,
> 72db7b5e069002765ced64f030c1117d72352331,
> adc4c567a08d4d2377060179639cbfdc3d9d8e0e and
> 9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32
> to boot on this hardware. This patches written by kernel package
> maintainer of ALT Linux distribution. Discussion of this issue is
> available on Sysadmins ALTLinux mailing list
> (http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html
> and follows) in Russian.
> 
> I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need
> this messages for more recent versions of Xen and kernel, or more
> information about hardware, please let me know.

Please provide the crash using the v3.4 kernel.

> 
> Ideally, I would like to run current versions of Xen and Linux
> kernels on this hardware. Can you help me please?

Well sure. But pls explain to me why:
 - you are using 'noacpi'
 - why are not using the v3.4 kernel?
> 
> 
> --
>  WBR, Alex Moskalenko


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 07 17:32:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgYn-0005RY-K3; Thu, 07 Jun 2012 17:31: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 1ScgYm-0005RH-De
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:31:48 +0000
Received: from [85.158.143.35:31451] by server-2.bemta-4.messagelabs.com id
	E0/51-17938-385E0DF4; Thu, 07 Jun 2012 17:31:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339090307!14022830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26725 invoked from network); 7 Jun 2012 17:31:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:31:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:26:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:26:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgTd-0001a0-Ig; Thu, 07 Jun 2012 17:26:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgTd-0008VB-GH;
	Thu, 07 Jun 2012 18:26:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.58433.896128.959563@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:26:25 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default
	in	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

Stefano Stabellini writes ("[Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:32:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgYn-0005RY-K3; Thu, 07 Jun 2012 17:31: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 1ScgYm-0005RH-De
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:31:48 +0000
Received: from [85.158.143.35:31451] by server-2.bemta-4.messagelabs.com id
	E0/51-17938-385E0DF4; Thu, 07 Jun 2012 17:31:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339090307!14022830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26725 invoked from network); 7 Jun 2012 17:31:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:31:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:26:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:26:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgTd-0001a0-Ig; Thu, 07 Jun 2012 17:26:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgTd-0008VB-GH;
	Thu, 07 Jun 2012 18:26:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.58433.896128.959563@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:26:25 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default
	in	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

Stefano Stabellini writes ("[Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScgaW-0005iq-6F; Thu, 07 Jun 2012 17:33: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 1ScgaV-0005iZ-68
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:33:35 +0000
Received: from [85.158.139.83:6935] by server-7.bemta-5.messagelabs.com id
	6D/45-19648-EE5E0DF4; Thu, 07 Jun 2012 17:33:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339090413!28627589!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23365 invoked from network); 7 Jun 2012 17:33:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:33:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:33:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgaT-0001c4-7H; Thu, 07 Jun 2012 17:33:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgaT-0004OV-44;
	Thu, 07 Jun 2012 18:33:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.58861.111503.228035@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:33:33 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
References: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: remove libxl__error_set prototype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: remove libxl__error_set prototype"):
> libxl: remove libxl__error_set prototype

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScgaW-0005iq-6F; Thu, 07 Jun 2012 17:33: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 1ScgaV-0005iZ-68
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:33:35 +0000
Received: from [85.158.139.83:6935] by server-7.bemta-5.messagelabs.com id
	6D/45-19648-EE5E0DF4; Thu, 07 Jun 2012 17:33:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339090413!28627589!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23365 invoked from network); 7 Jun 2012 17:33:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:33:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:33:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgaT-0001c4-7H; Thu, 07 Jun 2012 17:33:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgaT-0004OV-44;
	Thu, 07 Jun 2012 18:33:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.58861.111503.228035@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:33:33 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
References: <bda11a77fad7c42a58cd.1338988503@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: remove libxl__error_set prototype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] libxl: remove libxl__error_set prototype"):
> libxl: remove libxl__error_set prototype

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgbX-0005rv-LC; Thu, 07 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1ScgbV-0005rb-Jl
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:34:37 +0000
Received: from [85.158.143.35:8364] by server-3.bemta-4.messagelabs.com id
	3B/28-29237-C26E0DF4; Thu, 07 Jun 2012 17:34:36 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339090475!15283774!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17081 invoked from network); 7 Jun 2012 17:34:36 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:34:36 -0000
Received: by lbom4 with SMTP id m4so933259lbo.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 10:34:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=k8IWXjWksIRQLyPIqGz2lmwGv+swez6uyuv+TYNUmPY=;
	b=JpawjncTzn1DlFLt3IFczSAY5gapl8fb0sRbtfYid+rHKcEm96cQm9OClcXO8cz1+E
	wCPEysxETqaP0OlNDxhVbQaCk7gj4qoB8NPMxiKhVtpvQhAFWjBVQ1ezG2Ov4z6AKE/A
	P+Uxnk7IA3tiJMsgwI76WdrbIOpgjFmybqxOxNOsk5xOqG7f43pmWn6DsPlkmMJWLq+S
	fWMJ/C2pNt+WER9IpTGAal4ynt4bJUoAPGt11wyIkyuknz14yCUFJXtZLIT+eBs1G61b
	Dd1ZMe3nVI9ExrOzBFDdXLbJKpBazpd3Tal/0lVVLg/WjAO2lELH/253KCuczKkvfxUu
	A+Lg==
MIME-Version: 1.0
Received: by 10.112.32.35 with SMTP id f3mr1798765lbi.47.1339090475518; Thu,
	07 Jun 2012 10:34:35 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 10:34:35 -0700 (PDT)
In-Reply-To: <20120607164034.GQ9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 13:34:35 -0400
X-Google-Sender-Auth: cZTbZVxs9dCqppUOdvq4J4z6INs
Message-ID: <CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 12:40 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Jun 07, 2012 at 09:30:06AM -0400, Ben Guthro wrote:
>> Fix the polling section of the hvc driver to use the global "last_hvc"
>> variable, rather than the ttys.
>
> Could you just do:
>
> =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[last_hvc];
>
> as well?

No. I tried this, and never got to the kdb prompt.
It seems that the problem is that you need to use the cons_ops variable

My efforts to fully understand the inner-workings of the console code
were thwarted by time. Its a twisty bunch of code.
If I used the cons_ops variable static to the module, it was OK.
If I used driver->ttys - {get,put}_chars() never got called.


> So how come the '0' one did not work? Is that b/c
> of console=3Dtty becoming '0' instead of hvc0? Is there a crash
> involved with this? Or is that it just is listening on the
> wrong console (and which one is that?)

See above.

>>
>> With this change debugging a xen dom0 kernel is possible via the
>> following kernel parameter:
>> kgdboc=3Dhvc0
>
> Hm, if that is the problem then this should also be a problem on
> IBM Power boxes I would think?

Not sure...but I think the original submitter of this code was

commit 762e77ae7dd055d0b77e0ad34d87db7416df109e
Author: Anton Blanchard <anton@samba.org>
Date:   Tue Jul 12 19:44:05 2011 +0000

    hvc_console: Add kdb support


Was that for IBM?

>
>>
>> Signed-off-by: Ben Guthro <Benjamin.Guthro@citrix.com>
>>
>>
>> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console=
.c
>> index 2d691eb..3750e74 100644
>> --- a/drivers/tty/hvc/hvc_console.c
>> +++ b/drivers/tty/hvc/hvc_console.c
>> @@ -766,12 +766,10 @@ int hvc_poll_init(struct tty_driver *driver, int
>> line, char *options)
>>
>> =A0static int hvc_poll_get_char(struct tty_driver *driver, int line)
>> =A0{
>> - =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[0];
>> - =A0 =A0 =A0 struct hvc_struct *hp =3D tty->driver_data;
>> =A0 =A0 =A0 =A0 int n;
>> =A0 =A0 =A0 =A0 char ch;
>>
>> - =A0 =A0 =A0 n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
>> + =A0 =A0 =A0 n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &c=
h, 1);
>>
>> =A0 =A0 =A0 =A0 if (n =3D=3D 0)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NO_POLL_CHAR;
>> @@ -781,12 +779,10 @@ static int hvc_poll_get_char(struct tty_driver
>> *driver, int line)
>>
>> =A0static void hvc_poll_put_char(struct tty_driver *driver, int line, ch=
ar ch)
>> =A0{
>> - =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[0];
>> - =A0 =A0 =A0 struct hvc_struct *hp =3D tty->driver_data;
>> =A0 =A0 =A0 =A0 int n;
>>
>> =A0 =A0 =A0 =A0 do {
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 n =3D hp->ops->put_chars(hp->vtermno, &ch,=
 1);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 n =3D cons_ops[last_hvc]->put_chars(vtermn=
os[last_hvc], &ch, 1);
>> =A0 =A0 =A0 =A0 } while (n <=3D 0);
>> =A0}
>> =A0#endif
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1ScgbX-0005rv-LC; Thu, 07 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1ScgbV-0005rb-Jl
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:34:37 +0000
Received: from [85.158.143.35:8364] by server-3.bemta-4.messagelabs.com id
	3B/28-29237-C26E0DF4; Thu, 07 Jun 2012 17:34:36 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339090475!15283774!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17081 invoked from network); 7 Jun 2012 17:34:36 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:34:36 -0000
Received: by lbom4 with SMTP id m4so933259lbo.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 10:34:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=k8IWXjWksIRQLyPIqGz2lmwGv+swez6uyuv+TYNUmPY=;
	b=JpawjncTzn1DlFLt3IFczSAY5gapl8fb0sRbtfYid+rHKcEm96cQm9OClcXO8cz1+E
	wCPEysxETqaP0OlNDxhVbQaCk7gj4qoB8NPMxiKhVtpvQhAFWjBVQ1ezG2Ov4z6AKE/A
	P+Uxnk7IA3tiJMsgwI76WdrbIOpgjFmybqxOxNOsk5xOqG7f43pmWn6DsPlkmMJWLq+S
	fWMJ/C2pNt+WER9IpTGAal4ynt4bJUoAPGt11wyIkyuknz14yCUFJXtZLIT+eBs1G61b
	Dd1ZMe3nVI9ExrOzBFDdXLbJKpBazpd3Tal/0lVVLg/WjAO2lELH/253KCuczKkvfxUu
	A+Lg==
MIME-Version: 1.0
Received: by 10.112.32.35 with SMTP id f3mr1798765lbi.47.1339090475518; Thu,
	07 Jun 2012 10:34:35 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 10:34:35 -0700 (PDT)
In-Reply-To: <20120607164034.GQ9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 13:34:35 -0400
X-Google-Sender-Auth: cZTbZVxs9dCqppUOdvq4J4z6INs
Message-ID: <CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 12:40 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Jun 07, 2012 at 09:30:06AM -0400, Ben Guthro wrote:
>> Fix the polling section of the hvc driver to use the global "last_hvc"
>> variable, rather than the ttys.
>
> Could you just do:
>
> =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[last_hvc];
>
> as well?

No. I tried this, and never got to the kdb prompt.
It seems that the problem is that you need to use the cons_ops variable

My efforts to fully understand the inner-workings of the console code
were thwarted by time. Its a twisty bunch of code.
If I used the cons_ops variable static to the module, it was OK.
If I used driver->ttys - {get,put}_chars() never got called.


> So how come the '0' one did not work? Is that b/c
> of console=3Dtty becoming '0' instead of hvc0? Is there a crash
> involved with this? Or is that it just is listening on the
> wrong console (and which one is that?)

See above.

>>
>> With this change debugging a xen dom0 kernel is possible via the
>> following kernel parameter:
>> kgdboc=3Dhvc0
>
> Hm, if that is the problem then this should also be a problem on
> IBM Power boxes I would think?

Not sure...but I think the original submitter of this code was

commit 762e77ae7dd055d0b77e0ad34d87db7416df109e
Author: Anton Blanchard <anton@samba.org>
Date:   Tue Jul 12 19:44:05 2011 +0000

    hvc_console: Add kdb support


Was that for IBM?

>
>>
>> Signed-off-by: Ben Guthro <Benjamin.Guthro@citrix.com>
>>
>>
>> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console=
.c
>> index 2d691eb..3750e74 100644
>> --- a/drivers/tty/hvc/hvc_console.c
>> +++ b/drivers/tty/hvc/hvc_console.c
>> @@ -766,12 +766,10 @@ int hvc_poll_init(struct tty_driver *driver, int
>> line, char *options)
>>
>> =A0static int hvc_poll_get_char(struct tty_driver *driver, int line)
>> =A0{
>> - =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[0];
>> - =A0 =A0 =A0 struct hvc_struct *hp =3D tty->driver_data;
>> =A0 =A0 =A0 =A0 int n;
>> =A0 =A0 =A0 =A0 char ch;
>>
>> - =A0 =A0 =A0 n =3D hp->ops->get_chars(hp->vtermno, &ch, 1);
>> + =A0 =A0 =A0 n =3D cons_ops[last_hvc]->get_chars(vtermnos[last_hvc], &c=
h, 1);
>>
>> =A0 =A0 =A0 =A0 if (n =3D=3D 0)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NO_POLL_CHAR;
>> @@ -781,12 +779,10 @@ static int hvc_poll_get_char(struct tty_driver
>> *driver, int line)
>>
>> =A0static void hvc_poll_put_char(struct tty_driver *driver, int line, ch=
ar ch)
>> =A0{
>> - =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[0];
>> - =A0 =A0 =A0 struct hvc_struct *hp =3D tty->driver_data;
>> =A0 =A0 =A0 =A0 int n;
>>
>> =A0 =A0 =A0 =A0 do {
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 n =3D hp->ops->put_chars(hp->vtermno, &ch,=
 1);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 n =3D cons_ops[last_hvc]->put_chars(vtermn=
os[last_hvc], &ch, 1);
>> =A0 =A0 =A0 =A0 } while (n <=3D 0);
>> =A0}
>> =A0#endif
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:36:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scgd4-0006Az-8L; Thu, 07 Jun 2012 17:36:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scgd2-0006Aj-EW
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:36:12 +0000
Received: from [85.158.139.83:22506] by server-5.bemta-5.messagelabs.com id
	5D/5C-04481-B86E0DF4; Thu, 07 Jun 2012 17:36:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339090570!30988459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27268 invoked from network); 7 Jun 2012 17:36:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:36:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893539"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:36:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:36:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scgd0-0001d8-F2; Thu, 07 Jun 2012 17:36:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scgd0-0004P3-E9;
	Thu, 07 Jun 2012 18:36:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59018.420423.884384@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:36:10 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20432.58433.896128.959563@mariner.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default
	in	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 Jackson writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> Stefano Stabellini writes ("[Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

In fact I did a build test before pushing and it failed.  See below.

The source directory /u/iwj/work/1/qemu-upstream-unstable.git contains
6d8b472233779c2a028a03843603030d2b1aee86 and I did a hg/git clean
before the build test.

So I have stripped out that changeset.

Ian.

make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-traditional-dir'
make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make[2]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools'
if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
                mkdir -p qemu-xen-dir; \
        else \
                export GIT=git; \
                /u/iwj/work/xen-unstable-tools.hg/tools/../scripts/git-checkout.sh /u/iwj/work/1/qemu-upstream-unstable.git master qemu-xen-dir ; \
        fi
if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
                source=/u/iwj/work/1/qemu-upstream-unstable.git; \
        else \
                source=.; \
        fi; \
        cd qemu-xen-dir; \
        $source/configure --enable-xen --target-list=i386-softmmu \
                --source-path=$source \
                --extra-cflags="-I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/include \
                -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
                -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore \
                -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore/compat" \
                --extra-ldflags="-L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
                -L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore" \
                --bindir=/usr/lib/xen/bin \
                --datadir=/usr/share/qemu-xen \
                --disable-kvm \
                --disable-virtfs \
                --python=python \
                ; \
        make install
ERROR: unknown option --disable-virtfs

Usage: configure [options]
Options: [defaults in brackets after descriptions]

Standard options:
  --help                   print this message
  --prefix=PREFIX          install in PREFIX [/usr/local]
  --interp-prefix=PREFIX   where to find shared libraries, etc.
                           use %M for cpu name [/usr/gnemul/qemu-%M]
  --target-list=LIST       set target list (default: build everything)
                           Available targets: i386-softmmu x86_64-softmmu 
                           alpha-softmmu arm-softmmu cris-softmmu lm32-softmmu 
                           m68k-softmmu microblaze-softmmu microblazeel-softmmu 
                           mips-softmmu mipsel-softmmu mips64-softmmu 
                           mips64el-softmmu ppc-softmmu ppcemb-softmmu 
                           ppc64-softmmu sh4-softmmu sh4eb-softmmu 
                           sparc-softmmu sparc64-softmmu s390x-softmmu 
                           xtensa-softmmu xtensaeb-softmmu i386-linux-user 
                           x86_64-linux-user alpha-linux-user arm-linux-user 
                           armeb-linux-user cris-linux-user m68k-linux-user 
                           microblaze-linux-user microblazeel-linux-user 
                           mips-linux-user mipsel-linux-user ppc-linux-user 
                           ppc64-linux-user ppc64abi32-linux-user 
                           sh4-linux-user sh4eb-linux-user sparc-linux-user 
                           sparc64-linux-user sparc32plus-linux-user 
                           unicore32-linux-user s390x-linux-user 

Advanced options (experts only):
  --source-path=PATH       path of source code [/u/iwj/work/1/qemu-upstream-unstable.git]
  --cross-prefix=PREFIX    use PREFIX for compile tools []
  --cc=CC                  use C compiler CC [gcc]
  --host-cc=CC             use C compiler CC [gcc] for code run at
                           build time
  --extra-cflags=CFLAGS    append extra C compiler flags QEMU_CFLAGS
  --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS
  --make=MAKE              use specified make [make]
  --install=INSTALL        use specified install [install]
  --python=PYTHON          use specified python [python]
  --smbd=SMBD              use specified smbd [/usr/sbin/smbd]
  --static                 enable static build [no]
  --mandir=PATH            install man pages in PATH
  --datadir=PATH           install firmware in PATH
  --docdir=PATH            install documentation in PATH
  --bindir=PATH            install binaries in PATH
  --sysconfdir=PATH        install config in PATH/qemu
  --enable-debug-tcg       enable TCG debugging
  --disable-debug-tcg      disable TCG debugging (default)
  --enable-debug           enable common debug build options
  --enable-sparse          enable sparse checker
  --disable-sparse         disable sparse checker (default)
  --disable-strip          disable stripping binaries
  --disable-werror         disable compilation abort on warning
  --disable-sdl            disable SDL
  --enable-sdl             enable SDL
  --disable-vnc            disable VNC
  --enable-vnc             enable VNC
  --enable-cocoa           enable COCOA (Mac OS X only)
  --audio-drv-list=LIST    set audio drivers list:
                           Available drivers: oss alsa sdl esd pa fmod
  --audio-card-list=LIST   set list of emulated audio cards [ac97 es1370 sb16 hda]
                           Available cards: ac97 es1370 sb16 cs4231a adlib gus hda
  --block-drv-whitelist=L  set block driver whitelist
                           (affects only QEMU, not qemu-img)
  --enable-mixemu          enable mixer emulation
  --disable-xen            disable xen backend driver support
  --enable-xen             enable xen backend driver support
  --disable-brlapi         disable BrlAPI
  --enable-brlapi          enable BrlAPI
  --disable-vnc-tls        disable TLS encryption for VNC server
  --enable-vnc-tls         enable TLS encryption for VNC server
  --disable-vnc-sasl       disable SASL encryption for VNC server
  --enable-vnc-sasl        enable SASL encryption for VNC server
  --disable-vnc-jpeg       disable JPEG lossy compression for VNC server
  --enable-vnc-jpeg        enable JPEG lossy compression for VNC server
  --disable-vnc-png        disable PNG compression for VNC server (default)
  --enable-vnc-png         enable PNG compression for VNC server
  --disable-vnc-thread     disable threaded VNC server
  --enable-vnc-thread      enable threaded VNC server
  --disable-curses         disable curses output
  --enable-curses          enable curses output
  --disable-curl           disable curl connectivity
  --enable-curl            enable curl connectivity
  --disable-fdt            disable fdt device tree
  --enable-fdt             enable fdt device tree
  --disable-check-utests   disable check unit-tests
  --enable-check-utests    enable check unit-tests
  --disable-bluez          disable bluez stack connectivity
  --enable-bluez           enable bluez stack connectivity
  --disable-slirp          disable SLIRP userspace network connectivity
  --disable-kvm            disable KVM acceleration support
  --enable-kvm             enable KVM acceleration support
  --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)
  --disable-nptl           disable usermode NPTL support
  --enable-nptl            enable usermode NPTL support
  --enable-system          enable all system emulation targets
  --disable-system         disable all system emulation targets
  --enable-user            enable supported user emulation targets
  --disable-user           disable all user emulation targets
  --enable-linux-user      enable all linux usermode emulation targets
  --disable-linux-user     disable all linux usermode emulation targets
  --enable-darwin-user     enable all darwin usermode emulation targets
  --disable-darwin-user    disable all darwin usermode emulation targets
  --enable-bsd-user        enable all BSD usermode emulation targets
  --disable-bsd-user       disable all BSD usermode emulation targets
  --enable-guest-base      enable GUEST_BASE support for usermode
                           emulation targets
  --disable-guest-base     disable GUEST_BASE support
  --enable-pie             build Position Independent Executables
  --disable-pie            do not build Position Independent Executables
  --fmod-lib               path to FMOD library
  --fmod-inc               path to FMOD includes
  --oss-lib                path to OSS library
  --enable-uname-release=R Return R for uname -r in usermode emulation
  --cpu=CPU                Build for host CPU [i386]
  --sparc_cpu=V            Build qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9
  --disable-uuid           disable uuid support
  --enable-uuid            enable uuid support
  --disable-vde            disable support for vde network
  --enable-vde             enable support for vde network
  --disable-linux-aio      disable Linux AIO support
  --enable-linux-aio       enable Linux AIO support
  --disable-attr           disables attr and xattr support
  --enable-attr            enable attr and xattr support
  --disable-blobs          disable installing provided firmware blobs
  --enable-docs            enable documentation build
  --disable-docs           disable documentation build
  --disable-vhost-net      disable vhost-net acceleration support
  --enable-vhost-net       enable vhost-net acceleration support
  --enable-trace-backend=B Set trace backend
                           Available backends: nop simple stderr ust dtrace
  --with-trace-file=NAME   Full PATH,NAME of file to store traces
                           Default:trace-<pid>
  --disable-spice          disable spice
  --enable-spice           enable spice
  --enable-rbd             enable building the rados block device (rbd)
  --disable-libiscsi       disable iscsi support
  --enable-libiscsi        enable iscsi support
  --disable-smartcard      disable smartcard support
  --enable-smartcard       enable smartcard support
  --disable-smartcard-nss  disable smartcard nss support
  --enable-smartcard-nss   enable smartcard nss support
  --disable-usb-redir      disable usb network redirection support
  --enable-usb-redir       enable usb network redirection support
  --disable-guest-agent    disable building of the QEMU Guest Agent
  --enable-guest-agent     enable building of the QEMU Guest Agent

NOTE: The object files are built at the place where configure is launched
make[3]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
make[3]: *** No rule to make target `install'.  Stop.
make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
make[2]: *** [subdir-install-qemu-xen-dir] Error 2
make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make: *** [install-tools] Error 2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:36:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scgd4-0006Az-8L; Thu, 07 Jun 2012 17:36:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scgd2-0006Aj-EW
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:36:12 +0000
Received: from [85.158.139.83:22506] by server-5.bemta-5.messagelabs.com id
	5D/5C-04481-B86E0DF4; Thu, 07 Jun 2012 17:36:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339090570!30988459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27268 invoked from network); 7 Jun 2012 17:36:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:36:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893539"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:36:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:36:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scgd0-0001d8-F2; Thu, 07 Jun 2012 17:36:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scgd0-0004P3-E9;
	Thu, 07 Jun 2012 18:36:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59018.420423.884384@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:36:10 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20432.58433.896128.959563@mariner.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default
	in	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 Jackson writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> Stefano Stabellini writes ("[Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

In fact I did a build test before pushing and it failed.  See below.

The source directory /u/iwj/work/1/qemu-upstream-unstable.git contains
6d8b472233779c2a028a03843603030d2b1aee86 and I did a hg/git clean
before the build test.

So I have stripped out that changeset.

Ian.

make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-traditional-dir'
make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make[2]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools'
if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
                mkdir -p qemu-xen-dir; \
        else \
                export GIT=git; \
                /u/iwj/work/xen-unstable-tools.hg/tools/../scripts/git-checkout.sh /u/iwj/work/1/qemu-upstream-unstable.git master qemu-xen-dir ; \
        fi
if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
                source=/u/iwj/work/1/qemu-upstream-unstable.git; \
        else \
                source=.; \
        fi; \
        cd qemu-xen-dir; \
        $source/configure --enable-xen --target-list=i386-softmmu \
                --source-path=$source \
                --extra-cflags="-I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/include \
                -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
                -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore \
                -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore/compat" \
                --extra-ldflags="-L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
                -L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore" \
                --bindir=/usr/lib/xen/bin \
                --datadir=/usr/share/qemu-xen \
                --disable-kvm \
                --disable-virtfs \
                --python=python \
                ; \
        make install
ERROR: unknown option --disable-virtfs

Usage: configure [options]
Options: [defaults in brackets after descriptions]

Standard options:
  --help                   print this message
  --prefix=PREFIX          install in PREFIX [/usr/local]
  --interp-prefix=PREFIX   where to find shared libraries, etc.
                           use %M for cpu name [/usr/gnemul/qemu-%M]
  --target-list=LIST       set target list (default: build everything)
                           Available targets: i386-softmmu x86_64-softmmu 
                           alpha-softmmu arm-softmmu cris-softmmu lm32-softmmu 
                           m68k-softmmu microblaze-softmmu microblazeel-softmmu 
                           mips-softmmu mipsel-softmmu mips64-softmmu 
                           mips64el-softmmu ppc-softmmu ppcemb-softmmu 
                           ppc64-softmmu sh4-softmmu sh4eb-softmmu 
                           sparc-softmmu sparc64-softmmu s390x-softmmu 
                           xtensa-softmmu xtensaeb-softmmu i386-linux-user 
                           x86_64-linux-user alpha-linux-user arm-linux-user 
                           armeb-linux-user cris-linux-user m68k-linux-user 
                           microblaze-linux-user microblazeel-linux-user 
                           mips-linux-user mipsel-linux-user ppc-linux-user 
                           ppc64-linux-user ppc64abi32-linux-user 
                           sh4-linux-user sh4eb-linux-user sparc-linux-user 
                           sparc64-linux-user sparc32plus-linux-user 
                           unicore32-linux-user s390x-linux-user 

Advanced options (experts only):
  --source-path=PATH       path of source code [/u/iwj/work/1/qemu-upstream-unstable.git]
  --cross-prefix=PREFIX    use PREFIX for compile tools []
  --cc=CC                  use C compiler CC [gcc]
  --host-cc=CC             use C compiler CC [gcc] for code run at
                           build time
  --extra-cflags=CFLAGS    append extra C compiler flags QEMU_CFLAGS
  --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS
  --make=MAKE              use specified make [make]
  --install=INSTALL        use specified install [install]
  --python=PYTHON          use specified python [python]
  --smbd=SMBD              use specified smbd [/usr/sbin/smbd]
  --static                 enable static build [no]
  --mandir=PATH            install man pages in PATH
  --datadir=PATH           install firmware in PATH
  --docdir=PATH            install documentation in PATH
  --bindir=PATH            install binaries in PATH
  --sysconfdir=PATH        install config in PATH/qemu
  --enable-debug-tcg       enable TCG debugging
  --disable-debug-tcg      disable TCG debugging (default)
  --enable-debug           enable common debug build options
  --enable-sparse          enable sparse checker
  --disable-sparse         disable sparse checker (default)
  --disable-strip          disable stripping binaries
  --disable-werror         disable compilation abort on warning
  --disable-sdl            disable SDL
  --enable-sdl             enable SDL
  --disable-vnc            disable VNC
  --enable-vnc             enable VNC
  --enable-cocoa           enable COCOA (Mac OS X only)
  --audio-drv-list=LIST    set audio drivers list:
                           Available drivers: oss alsa sdl esd pa fmod
  --audio-card-list=LIST   set list of emulated audio cards [ac97 es1370 sb16 hda]
                           Available cards: ac97 es1370 sb16 cs4231a adlib gus hda
  --block-drv-whitelist=L  set block driver whitelist
                           (affects only QEMU, not qemu-img)
  --enable-mixemu          enable mixer emulation
  --disable-xen            disable xen backend driver support
  --enable-xen             enable xen backend driver support
  --disable-brlapi         disable BrlAPI
  --enable-brlapi          enable BrlAPI
  --disable-vnc-tls        disable TLS encryption for VNC server
  --enable-vnc-tls         enable TLS encryption for VNC server
  --disable-vnc-sasl       disable SASL encryption for VNC server
  --enable-vnc-sasl        enable SASL encryption for VNC server
  --disable-vnc-jpeg       disable JPEG lossy compression for VNC server
  --enable-vnc-jpeg        enable JPEG lossy compression for VNC server
  --disable-vnc-png        disable PNG compression for VNC server (default)
  --enable-vnc-png         enable PNG compression for VNC server
  --disable-vnc-thread     disable threaded VNC server
  --enable-vnc-thread      enable threaded VNC server
  --disable-curses         disable curses output
  --enable-curses          enable curses output
  --disable-curl           disable curl connectivity
  --enable-curl            enable curl connectivity
  --disable-fdt            disable fdt device tree
  --enable-fdt             enable fdt device tree
  --disable-check-utests   disable check unit-tests
  --enable-check-utests    enable check unit-tests
  --disable-bluez          disable bluez stack connectivity
  --enable-bluez           enable bluez stack connectivity
  --disable-slirp          disable SLIRP userspace network connectivity
  --disable-kvm            disable KVM acceleration support
  --enable-kvm             enable KVM acceleration support
  --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)
  --disable-nptl           disable usermode NPTL support
  --enable-nptl            enable usermode NPTL support
  --enable-system          enable all system emulation targets
  --disable-system         disable all system emulation targets
  --enable-user            enable supported user emulation targets
  --disable-user           disable all user emulation targets
  --enable-linux-user      enable all linux usermode emulation targets
  --disable-linux-user     disable all linux usermode emulation targets
  --enable-darwin-user     enable all darwin usermode emulation targets
  --disable-darwin-user    disable all darwin usermode emulation targets
  --enable-bsd-user        enable all BSD usermode emulation targets
  --disable-bsd-user       disable all BSD usermode emulation targets
  --enable-guest-base      enable GUEST_BASE support for usermode
                           emulation targets
  --disable-guest-base     disable GUEST_BASE support
  --enable-pie             build Position Independent Executables
  --disable-pie            do not build Position Independent Executables
  --fmod-lib               path to FMOD library
  --fmod-inc               path to FMOD includes
  --oss-lib                path to OSS library
  --enable-uname-release=R Return R for uname -r in usermode emulation
  --cpu=CPU                Build for host CPU [i386]
  --sparc_cpu=V            Build qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9
  --disable-uuid           disable uuid support
  --enable-uuid            enable uuid support
  --disable-vde            disable support for vde network
  --enable-vde             enable support for vde network
  --disable-linux-aio      disable Linux AIO support
  --enable-linux-aio       enable Linux AIO support
  --disable-attr           disables attr and xattr support
  --enable-attr            enable attr and xattr support
  --disable-blobs          disable installing provided firmware blobs
  --enable-docs            enable documentation build
  --disable-docs           disable documentation build
  --disable-vhost-net      disable vhost-net acceleration support
  --enable-vhost-net       enable vhost-net acceleration support
  --enable-trace-backend=B Set trace backend
                           Available backends: nop simple stderr ust dtrace
  --with-trace-file=NAME   Full PATH,NAME of file to store traces
                           Default:trace-<pid>
  --disable-spice          disable spice
  --enable-spice           enable spice
  --enable-rbd             enable building the rados block device (rbd)
  --disable-libiscsi       disable iscsi support
  --enable-libiscsi        enable iscsi support
  --disable-smartcard      disable smartcard support
  --enable-smartcard       enable smartcard support
  --disable-smartcard-nss  disable smartcard nss support
  --enable-smartcard-nss   enable smartcard nss support
  --disable-usb-redir      disable usb network redirection support
  --enable-usb-redir       enable usb network redirection support
  --disable-guest-agent    disable building of the QEMU Guest Agent
  --enable-guest-agent     enable building of the QEMU Guest Agent

NOTE: The object files are built at the place where configure is launched
make[3]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
make[3]: *** No rule to make target `install'.  Stop.
make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
make[2]: *** [subdir-install-qemu-xen-dir] Error 2
make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
make: *** [install-tools] Error 2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:42:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scgib-0006UD-9H; Thu, 07 Jun 2012 17:41:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScgiZ-0006U8-Lk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:41:55 +0000
Received: from [85.158.143.99:18378] by server-3.bemta-4.messagelabs.com id
	03/8D-29237-3E7E0DF4; Thu, 07 Jun 2012 17:41:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339090914!30902798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16360 invoked from network); 7 Jun 2012 17:41:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:41:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:41:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:41:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgiY-0001f4-AJ; Thu, 07 Jun 2012 17:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgiX-0000VO-TN;
	Thu, 07 Jun 2012 18:41:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59361.773966.629519@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:41:53 +0100
To: "W. Michael Petullo" <mike@flyn.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20431.13200.114406.125096@mariner.uk.xensource.com>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Using "xl create" without domain 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

Ian Jackson writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
> W. Michael Petullo writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
> ...
> > -    if (!S_ISREG(stab.st_mode)) {
> > -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
> > +    if (S_ISDIR(stab.st_mode)) {
> > +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);
> 
> This is not correct.  If, for example, /dev/tty is specified, it will
> go wrong.
> 
> The reason for the restriction to plain files is that those are the
> only thing on which stat works to provide the size.  If we are to
> support other objects, we need to change the reading algorithm.

Another alternative would be to special-case the string "/dev/null"
(in xl, not libxl) and not read a config file at all in that case.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:42:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scgib-0006UD-9H; Thu, 07 Jun 2012 17:41:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScgiZ-0006U8-Lk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:41:55 +0000
Received: from [85.158.143.99:18378] by server-3.bemta-4.messagelabs.com id
	03/8D-29237-3E7E0DF4; Thu, 07 Jun 2012 17:41:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339090914!30902798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16360 invoked from network); 7 Jun 2012 17:41:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:41:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:41:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:41:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScgiY-0001f4-AJ; Thu, 07 Jun 2012 17:41:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScgiX-0000VO-TN;
	Thu, 07 Jun 2012 18:41:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59361.773966.629519@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:41:53 +0100
To: "W. Michael Petullo" <mike@flyn.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20431.13200.114406.125096@mariner.uk.xensource.com>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Using "xl create" without domain 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

Ian Jackson writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
> W. Michael Petullo writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
> ...
> > -    if (!S_ISREG(stab.st_mode)) {
> > -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
> > +    if (S_ISDIR(stab.st_mode)) {
> > +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);
> 
> This is not correct.  If, for example, /dev/tty is specified, it will
> go wrong.
> 
> The reason for the restriction to plain files is that those are the
> only thing on which stat works to provide the size.  If we are to
> support other objects, we need to change the reading algorithm.

Another alternative would be to special-case the string "/dev/null"
(in xl, not libxl) and not read a config file at all in that case.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:45:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:45: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 1ScgmA-0006c5-UF; Thu, 07 Jun 2012 17:45: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 1Scgm9-0006by-08
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:45:37 +0000
Received: from [85.158.143.35:22447] by server-1.bemta-4.messagelabs.com id
	F5/95-10042-0C8E0DF4; Thu, 07 Jun 2012 17:45:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339091132!4833330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8634 invoked from network); 7 Jun 2012 17:45:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:45:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:45:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:45:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scgm4-0001gC-GS; Thu, 07 Jun 2012 17:45:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scgm4-0001YN-Fa;
	Thu, 07 Jun 2012 18:45:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59580.369626.308988@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:45:32 +0100
To: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20431.25122.99704.458764@mariner.uk.xensource.com>
References: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
	<20431.25122.99704.458764@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] xend: do not run a hotplug script from
	qemu	on 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

Ian Jackson writes ("Re: [Xen-devel] [PATCH] xend: do not run a hotplug script from qemu on Linux"):
> Ian Campbell writes ("[PATCH] xend: do not run a hotplug script from qemu on Linux"):
> > xend: do not run a hotplug script from qemu on Linux

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:45:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:45: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 1ScgmA-0006c5-UF; Thu, 07 Jun 2012 17:45: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 1Scgm9-0006by-08
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:45:37 +0000
Received: from [85.158.143.35:22447] by server-1.bemta-4.messagelabs.com id
	F5/95-10042-0C8E0DF4; Thu, 07 Jun 2012 17:45:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339091132!4833330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8634 invoked from network); 7 Jun 2012 17:45:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:45:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:45:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:45:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scgm4-0001gC-GS; Thu, 07 Jun 2012 17:45:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scgm4-0001YN-Fa;
	Thu, 07 Jun 2012 18:45:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59580.369626.308988@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:45:32 +0100
To: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20431.25122.99704.458764@mariner.uk.xensource.com>
References: <76d9122d2740b9d9fe9c.1338988898@cosworth.uk.xensource.com>
	<20431.25122.99704.458764@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] xend: do not run a hotplug script from
	qemu	on 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

Ian Jackson writes ("Re: [Xen-devel] [PATCH] xend: do not run a hotplug script from qemu on Linux"):
> Ian Campbell writes ("[PATCH] xend: do not run a hotplug script from qemu on Linux"):
> > xend: do not run a hotplug script from qemu on Linux

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scgp7-0006jZ-FG; Thu, 07 Jun 2012 17:48: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 1Scgp6-0006jO-35
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:48:40 +0000
Received: from [85.158.138.51:55131] by server-9.bemta-3.messagelabs.com id
	46/EA-15054-779E0DF4; Thu, 07 Jun 2012 17:48:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339091318!22426603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7548 invoked from network); 7 Jun 2012 17:48:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:48:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:48:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:48:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scgp4-0001h6-4P; Thu, 07 Jun 2012 17:48:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scgp4-0001Ys-2A;
	Thu, 07 Jun 2012 18:48:38 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59766.6064.299261@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:48:38 +0100
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
References: <4FCC8F3A020000780008812B@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>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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

Jan Beulich writes ("[Xen-devel] [PATCH] tools: adjust --datadir option passed to qemu-upstream's configure script"):
> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> os-posix.c:os_find_datadir() works. While one would generally expect
> that function to honour the --datadir configure option, fixing this is
> quite a bit more involved than simply adjusting the configure options
> to match the function's behavior (in that, for an installed binary, it
> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> due to (presumably) some other qemu instance being installed on
> people's systems (but being absent when running qemu-system-i386 from
> the dist/ portion of the build tree).

Anthony, Stefano, do you have an opinion ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scgp7-0006jZ-FG; Thu, 07 Jun 2012 17:48: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 1Scgp6-0006jO-35
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 17:48:40 +0000
Received: from [85.158.138.51:55131] by server-9.bemta-3.messagelabs.com id
	46/EA-15054-779E0DF4; Thu, 07 Jun 2012 17:48:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339091318!22426603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7548 invoked from network); 7 Jun 2012 17:48:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:48:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12893914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:48:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 18:48:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scgp4-0001h6-4P; Thu, 07 Jun 2012 17:48:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scgp4-0001Ys-2A;
	Thu, 07 Jun 2012 18:48:38 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.59766.6064.299261@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 18:48:38 +0100
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
References: <4FCC8F3A020000780008812B@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>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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

Jan Beulich writes ("[Xen-devel] [PATCH] tools: adjust --datadir option passed to qemu-upstream's configure script"):
> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> os-posix.c:os_find_datadir() works. While one would generally expect
> that function to honour the --datadir configure option, fixing this is
> quite a bit more involved than simply adjusting the configure options
> to match the function's behavior (in that, for an installed binary, it
> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> due to (presumably) some other qemu instance being installed on
> people's systems (but being absent when running qemu-system-i386 from
> the dist/ portion of the build tree).

Anthony, Stefano, do you have an opinion ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:55: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 1ScgvZ-0006ub-BP; Thu, 07 Jun 2012 17:55: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 1ScgvY-0006uW-BF
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:55:20 +0000
Received: from [85.158.139.83:38997] by server-9.bemta-5.messagelabs.com id
	B2/4B-29678-70BE0DF4; Thu, 07 Jun 2012 17:55:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339091717!18670249!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21565 invoked from network); 7 Jun 2012 17:55:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:55:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HtEtN023439
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:55:15 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
	q57HtESX006667
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:55:14 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
	q57HtEwC009571; Thu, 7 Jun 2012 12:55:14 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:55:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BB1C84029B; Thu,  7 Jun 2012 13:48:15 -0400 (EDT)
Date: Thu, 7 Jun 2012 13:48:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120607174815.GU9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
 kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 07, 2012 at 09:30:06AM -0400, Ben Guthro wrote:
> >> Fix the polling section of the hvc driver to use the global "last_hvc"
> >> variable, rather than the ttys.
> >
> > Could you just do:
> >
> > =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[last_hvc];
> >
> > as well?
> =

> No. I tried this, and never got to the kdb prompt.
> It seems that the problem is that you need to use the cons_ops variable
> =

> My efforts to fully understand the inner-workings of the console code
> were thwarted by time. Its a twisty bunch of code.
> If I used the cons_ops variable static to the module, it was OK.
> If I used driver->ttys - {get,put}_chars() never got called.

Well, now that you guys are working for a big corporation
you can relax and afford to spend some time digging in the
inner-workings I think :-)
.. snip..
> > Hm, if that is the problem then this should also be a problem on
> > IBM Power boxes I would think?
> =

> Not sure...but I think the original submitter of this code was
> =

> commit 762e77ae7dd055d0b77e0ad34d87db7416df109e
> Author: Anton Blanchard <anton@samba.org>
> Date:   Tue Jul 12 19:44:05 2011 +0000
> =

>     hvc_console: Add kdb support
> =

> =

> Was that for IBM?

No. But the 'hvc' system is used on IBM Power machines as well.
Hence my thought that if it didn't work under Xen it probably
didn't work under IBM Power machines either.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17:55: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 1ScgvZ-0006ub-BP; Thu, 07 Jun 2012 17:55: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 1ScgvY-0006uW-BF
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:55:20 +0000
Received: from [85.158.139.83:38997] by server-9.bemta-5.messagelabs.com id
	B2/4B-29678-70BE0DF4; Thu, 07 Jun 2012 17:55:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339091717!18670249!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21565 invoked from network); 7 Jun 2012 17:55:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 17:55:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57HtEtN023439
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:55:15 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
	q57HtESX006667
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 17:55:14 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
	q57HtEwC009571; Thu, 7 Jun 2012 12:55:14 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 10:55:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BB1C84029B; Thu,  7 Jun 2012 13:48:15 -0400 (EDT)
Date: Thu, 7 Jun 2012 13:48:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120607174815.GU9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
 kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 07, 2012 at 09:30:06AM -0400, Ben Guthro wrote:
> >> Fix the polling section of the hvc driver to use the global "last_hvc"
> >> variable, rather than the ttys.
> >
> > Could you just do:
> >
> > =A0 =A0 =A0 struct tty_struct *tty =3D driver->ttys[last_hvc];
> >
> > as well?
> =

> No. I tried this, and never got to the kdb prompt.
> It seems that the problem is that you need to use the cons_ops variable
> =

> My efforts to fully understand the inner-workings of the console code
> were thwarted by time. Its a twisty bunch of code.
> If I used the cons_ops variable static to the module, it was OK.
> If I used driver->ttys - {get,put}_chars() never got called.

Well, now that you guys are working for a big corporation
you can relax and afford to spend some time digging in the
inner-workings I think :-)
.. snip..
> > Hm, if that is the problem then this should also be a problem on
> > IBM Power boxes I would think?
> =

> Not sure...but I think the original submitter of this code was
> =

> commit 762e77ae7dd055d0b77e0ad34d87db7416df109e
> Author: Anton Blanchard <anton@samba.org>
> Date:   Tue Jul 12 19:44:05 2011 +0000
> =

>     hvc_console: Add kdb support
> =

> =

> Was that for IBM?

No. But the 'hvc' system is used on IBM Power machines as well.
Hence my thought that if it didn't work under Xen it probably
didn't work under IBM Power machines either.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scgwr-0006yd-QM; Thu, 07 Jun 2012 17:56:41 +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 1Scgwq-0006yW-DJ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:56:40 +0000
Received: from [85.158.143.35:59902] by server-3.bemta-4.messagelabs.com id
	59/27-29237-75BE0DF4; Thu, 07 Jun 2012 17:56:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339091799!19263473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26219 invoked from network); 7 Jun 2012 17:56:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:56:38 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	18:56:38 +0100
Message-ID: <4FD0EB53.2040603@citrix.com>
Date: Thu, 7 Jun 2012 19:56:35 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1205281439080.26786@kaball-desktop>
	<1338287956-24691-8-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1338287956-24691-8-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 08/11] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stabellini wrote:
>   int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
>   {
> -    /* Nothing to do for PHYSTYPE_PHY. */
> +    int rc = 0;
>
> -    /*
> -     * For other device types assume that the blktap2 process is
> -     * needed by the soon to be started domain and do nothing.
> -     */
> +    switch (disk->backend) {
> +        case LIBXL_DISK_BACKEND_QDISK:
> +            if (disk->vdev != NULL) {
> +                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
> +                        disk, 0);

I was just looking at this code, and I have the feeling this could be 
dangerous, since you call libxl__device_disk_local_detach from an 
already running ao (the bootloader ao), and libxl_device_disk_remove 
will initiate another ao, and set it to completed inside of an already 
running ao.

> +                rc = libxl_device_disk_destroy(gc->owner,
> +                        LIBXL_TOOLSTACK_DOMID, disk);
> +            }
> +            break;
> +        default:
> +            /*
> +             * Nothing to do for PHYSTYPE_PHY.
> +             * For other device types assume that the blktap2 process is
> +             * needed by the soon to be started domain and do nothing.
> +             */
> +            break;
> +    }
>
>       free(disk->pdev_path);
>       free(disk->script);
> -    return 0;
> +
> +    return rc;
>   }
>
>   /******************************************************************************/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 17:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 17: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 1Scgwr-0006yd-QM; Thu, 07 Jun 2012 17:56:41 +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 1Scgwq-0006yW-DJ
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 17:56:40 +0000
Received: from [85.158.143.35:59902] by server-3.bemta-4.messagelabs.com id
	59/27-29237-75BE0DF4; Thu, 07 Jun 2012 17:56:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339091799!19263473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26219 invoked from network); 7 Jun 2012 17:56:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 17:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 17:56:38 +0000
Received: from [192.168.1.132] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 7 Jun 2012
	18:56:38 +0100
Message-ID: <4FD0EB53.2040603@citrix.com>
Date: Thu, 7 Jun 2012 19:56:35 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1205281439080.26786@kaball-desktop>
	<1338287956-24691-8-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1338287956-24691-8-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 08/11] xl/libxl: implement QDISK
	libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Stabellini wrote:
>   int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
>   {
> -    /* Nothing to do for PHYSTYPE_PHY. */
> +    int rc = 0;
>
> -    /*
> -     * For other device types assume that the blktap2 process is
> -     * needed by the soon to be started domain and do nothing.
> -     */
> +    switch (disk->backend) {
> +        case LIBXL_DISK_BACKEND_QDISK:
> +            if (disk->vdev != NULL) {
> +                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
> +                        disk, 0);

I was just looking at this code, and I have the feeling this could be 
dangerous, since you call libxl__device_disk_local_detach from an 
already running ao (the bootloader ao), and libxl_device_disk_remove 
will initiate another ao, and set it to completed inside of an already 
running ao.

> +                rc = libxl_device_disk_destroy(gc->owner,
> +                        LIBXL_TOOLSTACK_DOMID, disk);
> +            }
> +            break;
> +        default:
> +            /*
> +             * Nothing to do for PHYSTYPE_PHY.
> +             * For other device types assume that the blktap2 process is
> +             * needed by the soon to be started domain and do nothing.
> +             */
> +            break;
> +    }
>
>       free(disk->pdev_path);
>       free(disk->script);
> -    return 0;
> +
> +    return rc;
>   }
>
>   /******************************************************************************/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:04:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1Sch3o-0007LA-Pw; Thu, 07 Jun 2012 18:03:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1Sch3n-0007L5-A7
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:03:51 +0000
Received: from [85.158.143.99:15189] by server-2.bemta-4.messagelabs.com id
	D4/16-17938-60DE0DF4; Thu, 07 Jun 2012 18:03:50 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339092228!26525519!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27100 invoked from network); 7 Jun 2012 18:03:49 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:03:49 -0000
Received: by lahg1 with SMTP id g1so815798lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 11:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SNBIydXzf27SFDHMgblDaq/25yGsKgUIC10H6UghUEk=;
	b=lbRxoRx+0e1uI4g6HDlNzDSFRODnEnGDsLdtNqRVIGB1LqKeHe7xK+lXtpJIf8Srlf
	JuSsrezlQpuVSu0+sPUB9VJ6w7qpDRCnLKvD6Z+7gsL325+Npn/4zaU30ZMrAYU0GwY5
	TCpkMN5K6jSBFD7ETxDV4FRzMq/Ca/HhCnCLMLJM9crpcQYxU7PlWwA46GkbrYsST1K2
	5zOsDNfUEWn/Qkt3h4KSZX+BuuRh9Wjb+2f7womQ75rfIkA5oplCcWIcK8aHi3vwoLjA
	DdXxFSlUBAW9/fq/OUi6bnSS1lOBMhpTVBrbdLqKayOrM1mJ6rVxUeX05kK/afe2gLbG
	uRcg==
MIME-Version: 1.0
Received: by 10.152.148.199 with SMTP id tu7mr3611959lab.43.1339092228110;
	Thu, 07 Jun 2012 11:03:48 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 11:03:48 -0700 (PDT)
In-Reply-To: <20120607174815.GU9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 14:03:48 -0400
X-Google-Sender-Auth: jSsIAWte9pnufKwGRZc0KiWSg7U
Message-ID: <CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 7, 2012 at 1:48 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
...snip...

> Well, now that you guys are working for a big corporation
> you can relax and afford to spend some time digging in the
> inner-workings I think :-)

I'll pass along that suggestion.
So far, that hasn't come to pass...

I understood it when I wrote this months ago. I really should have
written this up then.
I'll try to dig in a bit, and report back.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:04:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1Sch3o-0007LA-Pw; Thu, 07 Jun 2012 18:03:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1Sch3n-0007L5-A7
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:03:51 +0000
Received: from [85.158.143.99:15189] by server-2.bemta-4.messagelabs.com id
	D4/16-17938-60DE0DF4; Thu, 07 Jun 2012 18:03:50 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339092228!26525519!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27100 invoked from network); 7 Jun 2012 18:03:49 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:03:49 -0000
Received: by lahg1 with SMTP id g1so815798lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 11:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SNBIydXzf27SFDHMgblDaq/25yGsKgUIC10H6UghUEk=;
	b=lbRxoRx+0e1uI4g6HDlNzDSFRODnEnGDsLdtNqRVIGB1LqKeHe7xK+lXtpJIf8Srlf
	JuSsrezlQpuVSu0+sPUB9VJ6w7qpDRCnLKvD6Z+7gsL325+Npn/4zaU30ZMrAYU0GwY5
	TCpkMN5K6jSBFD7ETxDV4FRzMq/Ca/HhCnCLMLJM9crpcQYxU7PlWwA46GkbrYsST1K2
	5zOsDNfUEWn/Qkt3h4KSZX+BuuRh9Wjb+2f7womQ75rfIkA5oplCcWIcK8aHi3vwoLjA
	DdXxFSlUBAW9/fq/OUi6bnSS1lOBMhpTVBrbdLqKayOrM1mJ6rVxUeX05kK/afe2gLbG
	uRcg==
MIME-Version: 1.0
Received: by 10.152.148.199 with SMTP id tu7mr3611959lab.43.1339092228110;
	Thu, 07 Jun 2012 11:03:48 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 11:03:48 -0700 (PDT)
In-Reply-To: <20120607174815.GU9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 14:03:48 -0400
X-Google-Sender-Auth: jSsIAWte9pnufKwGRZc0KiWSg7U
Message-ID: <CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 7, 2012 at 1:48 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
...snip...

> Well, now that you guys are working for a big corporation
> you can relax and afford to spend some time digging in the
> inner-workings I think :-)

I'll pass along that suggestion.
So far, that hasn't come to pass...

I understood it when I wrote this months ago. I really should have
written this up then.
I'll try to dig in a bit, and report back.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1Sch8n-0007g1-HK; Thu, 07 Jun 2012 18:09:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Sch8m-0007fu-7k
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:09:00 +0000
Received: from [85.158.143.35:15298] by server-2.bemta-4.messagelabs.com id
	2A/09-17938-B3EE0DF4; Thu, 07 Jun 2012 18:08:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339092537!8354604!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32047 invoked from network); 7 Jun 2012 18:08:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 18:08:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57I8t1I007513
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 18:08:56 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
	q57I8sjR013521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 18:08:55 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
	q57I8sSN013560; Thu, 7 Jun 2012 13:08:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 11:08:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3BA684029B; Thu,  7 Jun 2012 14:01:56 -0400 (EDT)
Date: Thu, 7 Jun 2012 14:01:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120607180156.GX9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
	<CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
 kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 02:03:48PM -0400, Ben Guthro wrote:
> On Thu, Jun 7, 2012 at 1:48 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> ...snip...
> 
> > Well, now that you guys are working for a big corporation
> > you can relax and afford to spend some time digging in the
> > inner-workings I think :-)
> 
> I'll pass along that suggestion.
> So far, that hasn't come to pass...
> 
> I understood it when I wrote this months ago. I really should have
> written this up then.
> I'll try to dig in a bit, and report back.

OK. Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1Sch8n-0007g1-HK; Thu, 07 Jun 2012 18:09:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Sch8m-0007fu-7k
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:09:00 +0000
Received: from [85.158.143.35:15298] by server-2.bemta-4.messagelabs.com id
	2A/09-17938-B3EE0DF4; Thu, 07 Jun 2012 18:08:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339092537!8354604!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NzYyOQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32047 invoked from network); 7 Jun 2012 18:08:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 18:08:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57I8t1I007513
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 18:08:56 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
	q57I8sjR013521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 18:08:55 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
	q57I8sSN013560; Thu, 7 Jun 2012 13:08:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 11:08:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3BA684029B; Thu,  7 Jun 2012 14:01:56 -0400 (EDT)
Date: Thu, 7 Jun 2012 14:01:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120607180156.GX9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
	<CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
 kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 02:03:48PM -0400, Ben Guthro wrote:
> On Thu, Jun 7, 2012 at 1:48 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> ...snip...
> 
> > Well, now that you guys are working for a big corporation
> > you can relax and afford to spend some time digging in the
> > inner-workings I think :-)
> 
> I'll pass along that suggestion.
> So far, that hasn't come to pass...
> 
> I understood it when I wrote this months ago. I really should have
> written this up then.
> I'll try to dig in a bit, and report back.

OK. Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:24:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18:24: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 1SchN1-0007q1-UZ; Thu, 07 Jun 2012 18:23:43 +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 1SchN0-0007pw-5s
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:23:42 +0000
Received: from [193.109.254.147:62362] by server-11.bemta-14.messagelabs.com
	id 8C/60-02727-DA1F0DF4; Thu, 07 Jun 2012 18:23:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339093420!8710485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10689 invoked from network); 7 Jun 2012 18:23:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:23:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:23:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:23:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SchMs-0001tb-5c; Thu, 07 Jun 2012 18:23:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SchMs-0006WN-3k;
	Thu, 07 Jun 2012 19:23:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.61862.101759.76662@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:23:34 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <92a75908163cb0c5a46f.1338846971@probook.site>
References: <92a75908163cb0c5a46f.1338846971@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools: pass EXTRA_CFLAGS via environment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: pass EXTRA_CFLAGS via environment"):
> tools: pass EXTRA_CFLAGS via environment

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:24:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18:24: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 1SchN1-0007q1-UZ; Thu, 07 Jun 2012 18:23:43 +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 1SchN0-0007pw-5s
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:23:42 +0000
Received: from [193.109.254.147:62362] by server-11.bemta-14.messagelabs.com
	id 8C/60-02727-DA1F0DF4; Thu, 07 Jun 2012 18:23:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339093420!8710485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10689 invoked from network); 7 Jun 2012 18:23:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:23:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:23:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:23:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SchMs-0001tb-5c; Thu, 07 Jun 2012 18:23:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SchMs-0006WN-3k;
	Thu, 07 Jun 2012 19:23:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.61862.101759.76662@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:23:34 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <92a75908163cb0c5a46f.1338846971@probook.site>
References: <92a75908163cb0c5a46f.1338846971@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools: pass EXTRA_CFLAGS via environment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: pass EXTRA_CFLAGS via environment"):
> tools: pass EXTRA_CFLAGS via environment

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:27:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18:27: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 1SchQP-0007zd-Mc; Thu, 07 Jun 2012 18:27: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 1SchQO-0007zS-A8
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:27:12 +0000
Received: from [85.158.139.83:34829] by server-11.bemta-5.messagelabs.com id
	55/79-25194-F72F0DF4; Thu, 07 Jun 2012 18:27:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339093630!25288120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15490 invoked from network); 7 Jun 2012 18:27:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:27:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:27:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:27:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SchQM-0001uq-AS; Thu, 07 Jun 2012 18:27:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SchQM-0006Wf-9F;
	Thu, 07 Jun 2012 19:27:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.62078.265596.607954@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:27:10 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0EB53.2040603@citrix.com>
References: <alpine.DEB.2.00.1205281439080.26786@kaball-desktop>
	<1338287956-24691-8-git-send-email-stefano.stabellini@eu.citrix.com>
	<4FD0EB53.2040603@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>
Subject: Re: [Xen-devel] [PATCH v8 08/11] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH v8 08/11] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> Stefano Stabellini wrote:
> >   int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
> >   {
> > -    /* Nothing to do for PHYSTYPE_PHY. */
> > +    int rc = 0;
> >
> > -    /*
> > -     * For other device types assume that the blktap2 process is
> > -     * needed by the soon to be started domain and do nothing.
> > -     */
> > +    switch (disk->backend) {
> > +        case LIBXL_DISK_BACKEND_QDISK:
> > +            if (disk->vdev != NULL) {
> > +                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
> > +                        disk, 0);
> 
> I was just looking at this code, and I have the feeling this could be 
> dangerous, since you call libxl__device_disk_local_detach from an 
> already running ao (the bootloader ao), and libxl_device_disk_remove 
> will initiate another ao, and set it to completed inside of an already 
> running ao.

This is indeed forbidden.  The inner ao function exit will reenter the
libxl event loop, which might do almost anything, including
unexpectedly recursively reentering the other asynchronous operation
(the lock doesn't prevent this since it's the same thread).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:27:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18:27: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 1SchQP-0007zd-Mc; Thu, 07 Jun 2012 18:27: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 1SchQO-0007zS-A8
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 18:27:12 +0000
Received: from [85.158.139.83:34829] by server-11.bemta-5.messagelabs.com id
	55/79-25194-F72F0DF4; Thu, 07 Jun 2012 18:27:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339093630!25288120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15490 invoked from network); 7 Jun 2012 18:27:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:27:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:27:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:27:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SchQM-0001uq-AS; Thu, 07 Jun 2012 18:27:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SchQM-0006Wf-9F;
	Thu, 07 Jun 2012 19:27:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.62078.265596.607954@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:27:10 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FD0EB53.2040603@citrix.com>
References: <alpine.DEB.2.00.1205281439080.26786@kaball-desktop>
	<1338287956-24691-8-git-send-email-stefano.stabellini@eu.citrix.com>
	<4FD0EB53.2040603@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>
Subject: Re: [Xen-devel] [PATCH v8 08/11] xl/libxl: implement QDISK
 libxl_device_disk_local_attach
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH v8 08/11] xl/libxl: implement QDISK libxl_device_disk_local_attach"):
> Stefano Stabellini wrote:
> >   int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
> >   {
> > -    /* Nothing to do for PHYSTYPE_PHY. */
> > +    int rc = 0;
> >
> > -    /*
> > -     * For other device types assume that the blktap2 process is
> > -     * needed by the soon to be started domain and do nothing.
> > -     */
> > +    switch (disk->backend) {
> > +        case LIBXL_DISK_BACKEND_QDISK:
> > +            if (disk->vdev != NULL) {
> > +                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
> > +                        disk, 0);
> 
> I was just looking at this code, and I have the feeling this could be 
> dangerous, since you call libxl__device_disk_local_detach from an 
> already running ao (the bootloader ao), and libxl_device_disk_remove 
> will initiate another ao, and set it to completed inside of an already 
> running ao.

This is indeed forbidden.  The inner ao function exit will reenter the
libxl event loop, which might do almost anything, including
unexpectedly recursively reentering the other asynchronous operation
(the lock doesn't prevent this since it's the same thread).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:39:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1Schc3-0008Rf-VU; Thu, 07 Jun 2012 18:39: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 1Schc3-0008Ra-48
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 18:39:15 +0000
Received: from [85.158.143.35:22820] by server-3.bemta-4.messagelabs.com id
	79/DF-29237-255F0DF4; Thu, 07 Jun 2012 18:39:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339094353!19267502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14114 invoked from network); 7 Jun 2012 18:39:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:39:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:39:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Schc0-0001yv-V0; Thu, 07 Jun 2012 18:39:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Schc0-0007HK-TC;
	Thu, 07 Jun 2012 19:39:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.62800.579982.885091@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:39:12 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1205301449330.26786@kaball-desktop>
References: <1338385522-21949-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.00.1205301449330.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Kevin Wolf <kwolf@redhat.com>, Adam Hamsik <haad@netbsd.org>,
	Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] qemu-xen-trad/block: fixes for NetBSD
 block-raw.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0/2] qemu-xen-trad/block: fixes for NetBSD block-raw."):
> On Wed, 30 May 2012, Roger Pau Monne wrote:
> > Both patches are already present in upstream qemu, this is only a 
> > backport.
> 
> Much better now thanks, I would consider them for 4.2

I have applied both, 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 Thu Jun 07 18:39:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1Schc3-0008Rf-VU; Thu, 07 Jun 2012 18:39: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 1Schc3-0008Ra-48
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 18:39:15 +0000
Received: from [85.158.143.35:22820] by server-3.bemta-4.messagelabs.com id
	79/DF-29237-255F0DF4; Thu, 07 Jun 2012 18:39:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339094353!19267502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14114 invoked from network); 7 Jun 2012 18:39:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:39:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:39:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Schc0-0001yv-V0; Thu, 07 Jun 2012 18:39:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Schc0-0007HK-TC;
	Thu, 07 Jun 2012 19:39:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.62800.579982.885091@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:39:12 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1205301449330.26786@kaball-desktop>
References: <1338385522-21949-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.00.1205301449330.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Kevin Wolf <kwolf@redhat.com>, Adam Hamsik <haad@netbsd.org>,
	Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] qemu-xen-trad/block: fixes for NetBSD
 block-raw.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0/2] qemu-xen-trad/block: fixes for NetBSD block-raw."):
> On Wed, 30 May 2012, Roger Pau Monne wrote:
> > Both patches are already present in upstream qemu, this is only a 
> > backport.
> 
> Much better now thanks, I would consider them for 4.2

I have applied both, 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 Thu Jun 07 18:47:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1SchjT-00009P-Tb; Thu, 07 Jun 2012 18:46: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 1SchjS-00009K-BM
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 18:46:54 +0000
Received: from [85.158.143.35:47678] by server-1.bemta-4.messagelabs.com id
	40/09-10042-D17F0DF4; Thu, 07 Jun 2012 18:46:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339094813!8862439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25102 invoked from network); 7 Jun 2012 18:46:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:46:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:46:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:46:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SchjK-00021N-QR; Thu, 07 Jun 2012 18:46:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SchjK-00071H-P4;
	Thu, 07 Jun 2012 19:46:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.63254.756851.724416@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:46:46 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1206011158570.26786@kaball-desktop>
References: <1338548259-3767-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.00.1206011158570.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on
	BSD	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on BSD systems"):
> On Fri, 1 Jun 2012, Roger Pau Monne wrote:
> > BSD systems already have a sys/queue.h file, which has more macros
> > than the one Qemu uses, and some header files depend on having that
> > macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
> > systems and include the native one.
> > 
> > This is not a backport because the original patch is too dificult to
> > backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
> > 
> > Doing a diff -bB shows that the Qemu version is just a stripped
> > version of the original NetBSD header, with many macros removed, but
> > no new ones added.
> > 
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:47:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18: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 1SchjT-00009P-Tb; Thu, 07 Jun 2012 18:46: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 1SchjS-00009K-BM
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 18:46:54 +0000
Received: from [85.158.143.35:47678] by server-1.bemta-4.messagelabs.com id
	40/09-10042-D17F0DF4; Thu, 07 Jun 2012 18:46:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339094813!8862439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE0Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25102 invoked from network); 7 Jun 2012 18:46:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 18:46:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="12894947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jun 2012 18:46:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 7 Jun 2012 19:46:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SchjK-00021N-QR; Thu, 07 Jun 2012 18:46:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SchjK-00071H-P4;
	Thu, 07 Jun 2012 19:46:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20432.63254.756851.724416@mariner.uk.xensource.com>
Date: Thu, 7 Jun 2012 19:46:46 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1206011158570.26786@kaball-desktop>
References: <1338548259-3767-1-git-send-email-roger.pau@citrix.com>
	<alpine.DEB.2.00.1206011158570.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on
	BSD	systems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu-xen-trad: fix sys-queue.h usage on BSD systems"):
> On Fri, 1 Jun 2012, Roger Pau Monne wrote:
> > BSD systems already have a sys/queue.h file, which has more macros
> > than the one Qemu uses, and some header files depend on having that
> > macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
> > systems and include the native one.
> > 
> > This is not a backport because the original patch is too dificult to
> > backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
> > 
> > Doing a diff -bB shows that the Qemu version is just a stripped
> > version of the original NetBSD header, with many macros removed, but
> > no new ones added.
> > 
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:49:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18:49: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 1SchlJ-0000EZ-DN; Thu, 07 Jun 2012 18:48:49 +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 1SchlH-0000EP-Fr
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 18:48:47 +0000
Received: from [85.158.143.99:7203] by server-3.bemta-4.messagelabs.com id
	D6/C4-29237-E87F0DF4; Thu, 07 Jun 2012 18:48:46 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339094926!28427901!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21549 invoked from network); 7 Jun 2012 18:48:46 -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; 7 Jun 2012 18:48:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 19:48:45 +0100
Message-Id: <4FD1059C0200007800085ACA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 19:48:44 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <drjones@redhat.com>
References: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
	<1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jones <drjones@redhat.com> 06/07/12 5:44 PM >>>
>> > In any case, the hypervisor log would be interesting to see. Plus -
>> > is
>> > this perhaps a rather old hypervisor running there (i.e.
>> > potentially
>> > lacking some fix)?
>> 
>> I just reproduced this on my own test box, which is running an HV
>> based on older code (it's RHEL 5.8). Even with
>> 'loglvl=all guest_loglvl=all' I didn't get anything logged in
>> 'xm dmesg'.
>
>I don't have an later hypervisor setup for testing, but it'd
>be nice to know if guests work on them. If so, then maybe RHEL5
>and EC2 need to look at Xen c/s 17498 and/or others.

Is it perhaps the really old 3.0.4 based one, and lacking a backport of
14041:b010e556fe2c? In that case the comparison part of the
cmpxchg8b emulation failing would apparently be treated equally to
e.g. a fault having occurred during the emulation (i.e. the original
page fault would get forwarded rather than just EFLAGS.ZF getting
set).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 18:49:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 18:49: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 1SchlJ-0000EZ-DN; Thu, 07 Jun 2012 18:48:49 +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 1SchlH-0000EP-Fr
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 18:48:47 +0000
Received: from [85.158.143.99:7203] by server-3.bemta-4.messagelabs.com id
	D6/C4-29237-E87F0DF4; Thu, 07 Jun 2012 18:48:46 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339094926!28427901!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21549 invoked from network); 7 Jun 2012 18:48:46 -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; 7 Jun 2012 18:48:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 19:48:45 +0100
Message-Id: <4FD1059C0200007800085ACA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 19:48:44 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <drjones@redhat.com>
References: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
	<1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jones <drjones@redhat.com> 06/07/12 5:44 PM >>>
>> > In any case, the hypervisor log would be interesting to see. Plus -
>> > is
>> > this perhaps a rather old hypervisor running there (i.e.
>> > potentially
>> > lacking some fix)?
>> 
>> I just reproduced this on my own test box, which is running an HV
>> based on older code (it's RHEL 5.8). Even with
>> 'loglvl=all guest_loglvl=all' I didn't get anything logged in
>> 'xm dmesg'.
>
>I don't have an later hypervisor setup for testing, but it'd
>be nice to know if guests work on them. If so, then maybe RHEL5
>and EC2 need to look at Xen c/s 17498 and/or others.

Is it perhaps the really old 3.0.4 based one, and lacking a backport of
14041:b010e556fe2c? In that case the comparison part of the
cmpxchg8b emulation failing would apparently be treated equally to
e.g. a fault having occurred during the emulation (i.e. the original
page fault would get forwarded rather than just EFLAGS.ZF getting
set).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:00:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1SchwG-0000Y7-Ry; Thu, 07 Jun 2012 19:00:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1SchwF-0000Y2-LT
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:00:07 +0000
Received: from [85.158.139.83:26187] by server-5.bemta-5.messagelabs.com id
	E6/C9-04481-63AF0DF4; Thu, 07 Jun 2012 19:00:06 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339095604!29796632!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15866 invoked from network); 7 Jun 2012 19:00:05 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 19:00:05 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id AE732B4
	for <xen-devel@lists.xen.org>; Thu,  7 Jun 2012 23:00:03 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id EVP4wvSCWrB8 for <xen-devel@lists.xen.org>;
	Thu,  7 Jun 2012 23:00:01 +0400 (MSK)
Received: from fixxxer-pc.fixxxerhome.local (unknown [85.159.41.68])
	(Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id 3253A1C
	for <xen-devel@lists.xen.org>; Thu,  7 Jun 2012 23:00:01 +0400 (MSK)
Message-ID: <4FD0FA30.6080705@elserv.ru>
Date: Thu, 07 Jun 2012 23:00:00 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD0747D.10103@elserv.ru>
	<20120607172402.GS9472@phenom.dumpdata.com>
In-Reply-To: <20120607172402.GS9472@phenom.dumpdata.com>
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

MDcuMDYuMjAxMiAyMToyNCwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrINC/0LjRiNC10YI6Cj4gT24g
VGh1LCBKdW4gMDcsIDIwMTIgYXQgMDE6Mjk6MzNQTSArMDQwMCwgQWxleCBNb3NrYWxlbmtvIHdy
b3RlOgo+PiBIaSBwZW9wbGUsCj4+Cj4+IEkgcmFuIGludG8gYSB0cm91YmxlIHdoZW4gdHJ5aW5n
IHRvIHJ1biBYZW4gNC4xLnggd2l0aCBwdl9vcHMga2VybmVsCj4+IG9uIElCTSBlU2VydmVyIHgz
NDAwLiBXaXRob3V0IG5vYWNwaSBjb21tYW5kIGxpbmUgb3B0aW9uIGRvbTAga2VybmVsCj4gV2Vs
bCB5ZXMhIFdlIGRvbid0IGRvICdub2FjcGknIFdoeSBkbyB5b3Ugc3VwcGx5ICdub2FjcGknPwpJ
ZiBJIGRvbid0IHN1cHBseSAnbm9hY3BpJyBvcHRpb24sIGRvbTAga2VybmVsIGNyYXNoZXMgd2l0
aCBtZXNzYWdlcyAKbWVudGlvbmVkIGluIG15IHByZXZpb3VzIGxldHRlci4gJ25vYWNwaScgYWxs
b3dzIGtlcm5lbCB0byBib290IHdpdGggCnNvbWUgSVJRIGlzc3VlcyAob25seSBSQUlEIGFudCBu
ZXR3b3JrIGFkYXB0ZXJzIHdvcmsgcHJvcGVybHksIGFueSBvdGhlciAKb25ib2FyZCBQQ0kgZGV2
aWNlIGRvZXMgbm90IHdvcmsgYXQgYWxsKS4KCj4+IGNyYXNoZXMgb24gQUNQSSBpbml0aWFsaXph
dGlvbi4gS2VybWVscyAyLjYuMzIgKHdpdGgga29ucmFkIHhlbgo+PiBwYXRjaGVzKSwgMy4xLCAz
LjMsIFhlbiA0LjEuMiBiZWhhdmUgdGhlIHNhbWUgd2F5LiBXaXRob3V0Cj4+IGh5cGVydmlzb3Ig
YWxsIGtlcm5lbHMgcnVuIHdpdGhvdXQgYW55IHByb2JsZW1zLgo+Pgo+PiBUaGVyZSBhcmUgc2V2
ZXJhbCBwYXRjaGVzIChhdmFpbGFibGUgb24gaHR0cDovL2dpdC5hbHRsaW51eC5vcmcvcGVvcGxl
L3NpbGljaXVtL3BhY2thZ2VzLz9wPWtlcm5lbC1pbWFnZS5naXQ7YT1zaG9ydGxvZztoPXJlZnMv
aGVhZHMva2VybmVsLWltYWdlLXhlbi1kb20wLAo+PiBjb21taXRzIGYxZjkxYmFiYzljYzk0MDJj
Y2VlODkzOGI4ODgyNDBmNWJhZTE1NzQsCj4+IDcyZGI3YjVlMDY5MDAyNzY1Y2VkNjRmMDMwYzEx
MTdkNzIzNTIzMzEsCj4+IGFkYzRjNTY3YTA4ZDRkMjM3NzA2MDE3OTYzOWNiZmRjM2Q5ZDhlMGUg
YW5kCj4+IDliZWVhYzU1ODljZTVjNDE1ZTQ1MTMwMTZjNzhlOTYzNzRiOGE4OTUpIHRoYXQgYWxs
b3cga2VybmVsIDIuNi4zMgo+PiB0byBib290IG9uIHRoaXMgaGFyZHdhcmUuIFRoaXMgcGF0Y2hl
cyB3cml0dGVuIGJ5IGtlcm5lbCBwYWNrYWdlCj4+IG1haW50YWluZXIgb2YgQUxUIExpbnV4IGRp
c3RyaWJ1dGlvbi4gRGlzY3Vzc2lvbiBvZiB0aGlzIGlzc3VlIGlzCj4+IGF2YWlsYWJsZSBvbiBT
eXNhZG1pbnMgQUxUTGludXggbWFpbGluZyBsaXN0Cj4+IChodHRwOi8vbGlzdHMuYWx0bGludXgu
b3JnL3BpcGVybWFpbC9zeXNhZG1pbnMvMjAxMS1BcHJpbC8wMzQ0NzEuaHRtbAo+PiBhbmQgZm9s
bG93cykgaW4gUnVzc2lhbi4KPj4KPj4gSSBhdHRhY2hlZCBYZW4gNC4xLjAgd2l0aCBrZXJuZWwg
Mi42LjMyIGNyYXNoIG1lc3NhZ2VzLiBJZiB5b3UgbmVlZAo+PiB0aGlzIG1lc3NhZ2VzIGZvciBt
b3JlIHJlY2VudCB2ZXJzaW9ucyBvZiBYZW4gYW5kIGtlcm5lbCwgb3IgbW9yZQo+PiBpbmZvcm1h
dGlvbiBhYm91dCBoYXJkd2FyZSwgcGxlYXNlIGxldCBtZSBrbm93Lgo+IFBsZWFzZSBwcm92aWRl
IHRoZSBjcmFzaCB1c2luZyB0aGUgdjMuNCBrZXJuZWwuCkkgd2lsbCBwcm92aWRlIGl0IGFzIHNv
b24gYXMgcG9zc2libGUuCgo+PiBJZGVhbGx5LCBJIHdvdWxkIGxpa2UgdG8gcnVuIGN1cnJlbnQg
dmVyc2lvbnMgb2YgWGVuIGFuZCBMaW51eAo+PiBrZXJuZWxzIG9uIHRoaXMgaGFyZHdhcmUuIENh
biB5b3UgaGVscCBtZSBwbGVhc2U/Cj4gV2VsbCBzdXJlLiBCdXQgcGxzIGV4cGxhaW4gdG8gbWUg
d2h5Ogo+ICAgLSB5b3UgYXJlIHVzaW5nICdub2FjcGknCj4gICAtIHdoeSBhcmUgbm90IHVzaW5n
IHRoZSB2My40IGtlcm5lbD8KLSBPbmx5IHdpdGggJ25vYWNwaScga2VybmVsIGRvZXMgbm90IGNy
dXNoLiBXaXRob3V0IGl0IGtlcm5lbCBjcmFzaGVzIAp3aXRoIGxvZ3MgSSBwcmV2aW91c2x5IGF0
dGFjaGVkLgotIEkgZGVhbCB3aXRoIHRoaXMgaXNzdWUgaW4gQXByaWwgMjAxMSwgd2hlbiAzLngg
a2VybmVsIHdhcyBub3QgeWV0IApyZWFkeSB0byB3b3JrIGFzIGRvbTAga2VybmVsLiBQZXJpb2Rp
Y2FsbHkgSSB0ZXN0IG5ldyBrZXJuZWwgdmVyc2lvbnMgCigzLjEsIDMuMiwgMy4zIGluY2x1ZGlu
ZyAzLjMuOCksIGJ1bCBhbGwgb2YgdGhleSBhcmUgYWxzbyBjcmFzaGluZyBpbiAKQUNQSSBpbml0
aWFsaXphdGlvbi4gSSB3aWxsIHRyeSAzLjQga2VybmVsIGFzIHNvb24gYXMgcG9zc2libGUuCgpU
aGFuayB5b3UgZm9yIHJlcGx5IQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:00:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1SchwG-0000Y7-Ry; Thu, 07 Jun 2012 19:00:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1SchwF-0000Y2-LT
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:00:07 +0000
Received: from [85.158.139.83:26187] by server-5.bemta-5.messagelabs.com id
	E6/C9-04481-63AF0DF4; Thu, 07 Jun 2012 19:00:06 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339095604!29796632!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15866 invoked from network); 7 Jun 2012 19:00:05 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jun 2012 19:00:05 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id AE732B4
	for <xen-devel@lists.xen.org>; Thu,  7 Jun 2012 23:00:03 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id EVP4wvSCWrB8 for <xen-devel@lists.xen.org>;
	Thu,  7 Jun 2012 23:00:01 +0400 (MSK)
Received: from fixxxer-pc.fixxxerhome.local (unknown [85.159.41.68])
	(Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id 3253A1C
	for <xen-devel@lists.xen.org>; Thu,  7 Jun 2012 23:00:01 +0400 (MSK)
Message-ID: <4FD0FA30.6080705@elserv.ru>
Date: Thu, 07 Jun 2012 23:00:00 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD0747D.10103@elserv.ru>
	<20120607172402.GS9472@phenom.dumpdata.com>
In-Reply-To: <20120607172402.GS9472@phenom.dumpdata.com>
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

MDcuMDYuMjAxMiAyMToyNCwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrINC/0LjRiNC10YI6Cj4gT24g
VGh1LCBKdW4gMDcsIDIwMTIgYXQgMDE6Mjk6MzNQTSArMDQwMCwgQWxleCBNb3NrYWxlbmtvIHdy
b3RlOgo+PiBIaSBwZW9wbGUsCj4+Cj4+IEkgcmFuIGludG8gYSB0cm91YmxlIHdoZW4gdHJ5aW5n
IHRvIHJ1biBYZW4gNC4xLnggd2l0aCBwdl9vcHMga2VybmVsCj4+IG9uIElCTSBlU2VydmVyIHgz
NDAwLiBXaXRob3V0IG5vYWNwaSBjb21tYW5kIGxpbmUgb3B0aW9uIGRvbTAga2VybmVsCj4gV2Vs
bCB5ZXMhIFdlIGRvbid0IGRvICdub2FjcGknIFdoeSBkbyB5b3Ugc3VwcGx5ICdub2FjcGknPwpJ
ZiBJIGRvbid0IHN1cHBseSAnbm9hY3BpJyBvcHRpb24sIGRvbTAga2VybmVsIGNyYXNoZXMgd2l0
aCBtZXNzYWdlcyAKbWVudGlvbmVkIGluIG15IHByZXZpb3VzIGxldHRlci4gJ25vYWNwaScgYWxs
b3dzIGtlcm5lbCB0byBib290IHdpdGggCnNvbWUgSVJRIGlzc3VlcyAob25seSBSQUlEIGFudCBu
ZXR3b3JrIGFkYXB0ZXJzIHdvcmsgcHJvcGVybHksIGFueSBvdGhlciAKb25ib2FyZCBQQ0kgZGV2
aWNlIGRvZXMgbm90IHdvcmsgYXQgYWxsKS4KCj4+IGNyYXNoZXMgb24gQUNQSSBpbml0aWFsaXph
dGlvbi4gS2VybWVscyAyLjYuMzIgKHdpdGgga29ucmFkIHhlbgo+PiBwYXRjaGVzKSwgMy4xLCAz
LjMsIFhlbiA0LjEuMiBiZWhhdmUgdGhlIHNhbWUgd2F5LiBXaXRob3V0Cj4+IGh5cGVydmlzb3Ig
YWxsIGtlcm5lbHMgcnVuIHdpdGhvdXQgYW55IHByb2JsZW1zLgo+Pgo+PiBUaGVyZSBhcmUgc2V2
ZXJhbCBwYXRjaGVzIChhdmFpbGFibGUgb24gaHR0cDovL2dpdC5hbHRsaW51eC5vcmcvcGVvcGxl
L3NpbGljaXVtL3BhY2thZ2VzLz9wPWtlcm5lbC1pbWFnZS5naXQ7YT1zaG9ydGxvZztoPXJlZnMv
aGVhZHMva2VybmVsLWltYWdlLXhlbi1kb20wLAo+PiBjb21taXRzIGYxZjkxYmFiYzljYzk0MDJj
Y2VlODkzOGI4ODgyNDBmNWJhZTE1NzQsCj4+IDcyZGI3YjVlMDY5MDAyNzY1Y2VkNjRmMDMwYzEx
MTdkNzIzNTIzMzEsCj4+IGFkYzRjNTY3YTA4ZDRkMjM3NzA2MDE3OTYzOWNiZmRjM2Q5ZDhlMGUg
YW5kCj4+IDliZWVhYzU1ODljZTVjNDE1ZTQ1MTMwMTZjNzhlOTYzNzRiOGE4OTUpIHRoYXQgYWxs
b3cga2VybmVsIDIuNi4zMgo+PiB0byBib290IG9uIHRoaXMgaGFyZHdhcmUuIFRoaXMgcGF0Y2hl
cyB3cml0dGVuIGJ5IGtlcm5lbCBwYWNrYWdlCj4+IG1haW50YWluZXIgb2YgQUxUIExpbnV4IGRp
c3RyaWJ1dGlvbi4gRGlzY3Vzc2lvbiBvZiB0aGlzIGlzc3VlIGlzCj4+IGF2YWlsYWJsZSBvbiBT
eXNhZG1pbnMgQUxUTGludXggbWFpbGluZyBsaXN0Cj4+IChodHRwOi8vbGlzdHMuYWx0bGludXgu
b3JnL3BpcGVybWFpbC9zeXNhZG1pbnMvMjAxMS1BcHJpbC8wMzQ0NzEuaHRtbAo+PiBhbmQgZm9s
bG93cykgaW4gUnVzc2lhbi4KPj4KPj4gSSBhdHRhY2hlZCBYZW4gNC4xLjAgd2l0aCBrZXJuZWwg
Mi42LjMyIGNyYXNoIG1lc3NhZ2VzLiBJZiB5b3UgbmVlZAo+PiB0aGlzIG1lc3NhZ2VzIGZvciBt
b3JlIHJlY2VudCB2ZXJzaW9ucyBvZiBYZW4gYW5kIGtlcm5lbCwgb3IgbW9yZQo+PiBpbmZvcm1h
dGlvbiBhYm91dCBoYXJkd2FyZSwgcGxlYXNlIGxldCBtZSBrbm93Lgo+IFBsZWFzZSBwcm92aWRl
IHRoZSBjcmFzaCB1c2luZyB0aGUgdjMuNCBrZXJuZWwuCkkgd2lsbCBwcm92aWRlIGl0IGFzIHNv
b24gYXMgcG9zc2libGUuCgo+PiBJZGVhbGx5LCBJIHdvdWxkIGxpa2UgdG8gcnVuIGN1cnJlbnQg
dmVyc2lvbnMgb2YgWGVuIGFuZCBMaW51eAo+PiBrZXJuZWxzIG9uIHRoaXMgaGFyZHdhcmUuIENh
biB5b3UgaGVscCBtZSBwbGVhc2U/Cj4gV2VsbCBzdXJlLiBCdXQgcGxzIGV4cGxhaW4gdG8gbWUg
d2h5Ogo+ICAgLSB5b3UgYXJlIHVzaW5nICdub2FjcGknCj4gICAtIHdoeSBhcmUgbm90IHVzaW5n
IHRoZSB2My40IGtlcm5lbD8KLSBPbmx5IHdpdGggJ25vYWNwaScga2VybmVsIGRvZXMgbm90IGNy
dXNoLiBXaXRob3V0IGl0IGtlcm5lbCBjcmFzaGVzIAp3aXRoIGxvZ3MgSSBwcmV2aW91c2x5IGF0
dGFjaGVkLgotIEkgZGVhbCB3aXRoIHRoaXMgaXNzdWUgaW4gQXByaWwgMjAxMSwgd2hlbiAzLngg
a2VybmVsIHdhcyBub3QgeWV0IApyZWFkeSB0byB3b3JrIGFzIGRvbTAga2VybmVsLiBQZXJpb2Rp
Y2FsbHkgSSB0ZXN0IG5ldyBrZXJuZWwgdmVyc2lvbnMgCigzLjEsIDMuMiwgMy4zIGluY2x1ZGlu
ZyAzLjMuOCksIGJ1bCBhbGwgb2YgdGhleSBhcmUgYWxzbyBjcmFzaGluZyBpbiAKQUNQSSBpbml0
aWFsaXphdGlvbi4gSSB3aWxsIHRyeSAzLjQga2VybmVsIGFzIHNvb24gYXMgcG9zc2libGUuCgpU
aGFuayB5b3UgZm9yIHJlcGx5IQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:10:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1Sci6T-0000xo-0t; Thu, 07 Jun 2012 19:10: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 1Sci6Q-0000xj-T2
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:10:39 +0000
Received: from [85.158.138.51:31261] by server-2.bemta-3.messagelabs.com id
	1B/C5-16299-EACF0DF4; Thu, 07 Jun 2012 19:10:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339096237!24979852!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3480 invoked from network); 7 Jun 2012 19:10:37 -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 Jun 2012 19:10:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sci6N-000KA7-EE; Thu, 07 Jun 2012 19:10:35 +0000
Date: Thu, 7 Jun 2012 20:10:35 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607191035.GA76463@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
	<1339077263.18523.19.camel@zakaz.uk.xensource.com>
	<1339086867.18523.36.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339086867.18523.36.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
	of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:34 +0100 on 07 Jun (1339090467), Ian Campbell wrote:
> Well it works, this means that this patch and the previous patch then
> collapse down into a single patch:
> 
> 8<-------------------------------------------------------
> 
> From 055fe5f4a3a77f292d5a2a6b9f56a4d14dad3519 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 2 Mar 2012 12:02:42 +0000
> Subject: [PATCH] arm: handy function to print a walk of a page table
> 
> Include helpers for dumping hypervisor walks and guest p2m walks.
> 
> Useful for debug but not actually used in this patch.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Great!  For this and the follow-up typo fix:
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 Jun 07 19:10:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1Sci6T-0000xo-0t; Thu, 07 Jun 2012 19:10: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 1Sci6Q-0000xj-T2
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:10:39 +0000
Received: from [85.158.138.51:31261] by server-2.bemta-3.messagelabs.com id
	1B/C5-16299-EACF0DF4; Thu, 07 Jun 2012 19:10:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339096237!24979852!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3480 invoked from network); 7 Jun 2012 19:10:37 -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 Jun 2012 19:10:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sci6N-000KA7-EE; Thu, 07 Jun 2012 19:10:35 +0000
Date: Thu, 7 Jun 2012 20:10:35 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120607191035.GA76463@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-3-git-send-email-ian.campbell@citrix.com>
	<20120607084917.GB70339@ocelot.phlegethon.org>
	<1339072005.18523.18.camel@zakaz.uk.xensource.com>
	<20120607124033.GS70339@ocelot.phlegethon.org>
	<1339077263.18523.19.camel@zakaz.uk.xensource.com>
	<1339086867.18523.36.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339086867.18523.36.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/38] arm: handy function to print a walk
	of a domain's p2m.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:34 +0100 on 07 Jun (1339090467), Ian Campbell wrote:
> Well it works, this means that this patch and the previous patch then
> collapse down into a single patch:
> 
> 8<-------------------------------------------------------
> 
> From 055fe5f4a3a77f292d5a2a6b9f56a4d14dad3519 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 2 Mar 2012 12:02:42 +0000
> Subject: [PATCH] arm: handy function to print a walk of a page table
> 
> Include helpers for dumping hypervisor walks and guest p2m walks.
> 
> Useful for debug but not actually used in this patch.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Great!  For this and the follow-up typo fix:
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 Jun 07 19:11:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1Sci6d-0000yK-De; Thu, 07 Jun 2012 19:10: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 1Sci6c-0000yD-4v
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:10:50 +0000
Received: from [85.158.143.99:3568] by server-3.bemta-4.messagelabs.com id
	E8/11-29237-9BCF0DF4; Thu, 07 Jun 2012 19:10:49 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339096248!31476970!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29378 invoked from network); 7 Jun 2012 19:10:48 -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; 7 Jun 2012 19:10:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 20:10:47 +0100
Message-Id: <4FD10AC60200007800085AEE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 20:10:46 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <keir.xen@gmail.com>
References: <4FCF3E5002000078000886D7@nat28.tlf.novell.com>
	<CBF4FBEF.3558E%keir.xen@gmail.com>
In-Reply-To: <CBF4FBEF.3558E%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jisooy@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <keir.xen@gmail.com> 06/06/12 1:28 PM >>>
>On 06/06/2012 10:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 06.06.12 at 11:02, Keir Fraser <keir@xen.org> wrote:
>>> On 06/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
>>> 
>>> ASSERT(first->list.prev == PAGE_LIST_NULL); ?
>>> 
>>> It seems odd to have one assumption encoded as an ASSERTion, and one as a
>>> code comment... A second assertion makes the assumption explicit, and
>>> run-time checked in debug builds.
>> 
>> But the __list_splice() equivalent assignment would be
>> 
>>     first->list.prev = at->list.prev;
>> 
>> which is why I chose the assert expression that way, yet made
>> the comment clarify what the actual state is. If the comment
>> just repeated what the ASSERT() already says, I'd rather drop
>> the comment altogether.
>
>I mean to replace the comment with a second assertion, not to replace the
>assertion your patch already adds. Does that make sense?

>From the perspective of the operation here, we really just want to make
sure that the new list head's prev points to where the old one's pointed;
the fact that they're both supposed to be PAGE_LIST_NULL doesn't really
matter. Hence simply asserting that the assignment is superfluous seems
the best choice to me, with the comment explaining why. If you have
suggestions for better wording of the comment, I'll gladly take those.

The second best choice imo would be to just have the superfluous
assignment there (making it likely that later someone will come and
ask why it's there when not really 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 Jun 07 19:11:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1Sci6d-0000yK-De; Thu, 07 Jun 2012 19:10: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 1Sci6c-0000yD-4v
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:10:50 +0000
Received: from [85.158.143.99:3568] by server-3.bemta-4.messagelabs.com id
	E8/11-29237-9BCF0DF4; Thu, 07 Jun 2012 19:10:49 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339096248!31476970!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29378 invoked from network); 7 Jun 2012 19:10:48 -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; 7 Jun 2012 19:10:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 20:10:47 +0100
Message-Id: <4FD10AC60200007800085AEE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 20:10:46 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <keir.xen@gmail.com>
References: <4FCF3E5002000078000886D7@nat28.tlf.novell.com>
	<CBF4FBEF.3558E%keir.xen@gmail.com>
In-Reply-To: <CBF4FBEF.3558E%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jisooy@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <keir.xen@gmail.com> 06/06/12 1:28 PM >>>
>On 06/06/2012 10:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 06.06.12 at 11:02, Keir Fraser <keir@xen.org> wrote:
>>> On 06/06/2012 09:23, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> +    /* Both first->list.prev and at->list.prev are PAGE_LIST_NULL. */
>>> 
>>> ASSERT(first->list.prev == PAGE_LIST_NULL); ?
>>> 
>>> It seems odd to have one assumption encoded as an ASSERTion, and one as a
>>> code comment... A second assertion makes the assumption explicit, and
>>> run-time checked in debug builds.
>> 
>> But the __list_splice() equivalent assignment would be
>> 
>>     first->list.prev = at->list.prev;
>> 
>> which is why I chose the assert expression that way, yet made
>> the comment clarify what the actual state is. If the comment
>> just repeated what the ASSERT() already says, I'd rather drop
>> the comment altogether.
>
>I mean to replace the comment with a second assertion, not to replace the
>assertion your patch already adds. Does that make sense?

>From the perspective of the operation here, we really just want to make
sure that the new list head's prev points to where the old one's pointed;
the fact that they're both supposed to be PAGE_LIST_NULL doesn't really
matter. Hence simply asserting that the assignment is superfluous seems
the best choice to me, with the comment explaining why. If you have
suggestions for better wording of the comment, I'll gladly take those.

The second best choice imo would be to just have the superfluous
assignment there (making it likely that later someone will come and
ask why it's there when not really 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 Jun 07 19:19:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SciEp-0001HW-G6; Thu, 07 Jun 2012 19:19:19 +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 1SciEo-0001HR-Fk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:19:18 +0000
Received: from [85.158.143.35:15148] by server-2.bemta-4.messagelabs.com id
	E5/BD-17938-5BEF0DF4; Thu, 07 Jun 2012 19:19:17 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339096757!8865401!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4359 invoked from network); 7 Jun 2012 19:19:17 -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; 7 Jun 2012 19:19:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 19:59:02 +0100
Message-Id: <4FD108050200007800085AD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 19:59:01 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <e.shekuhi@gmail.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
In-Reply-To: <CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> elahe shekuhi <e.shekuhi@gmail.com> 06/06/12 8:15 PM >>>
>On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Does migration fail in both directions? Or perhaps just from the
>> newer to the older system (in which case I would guess you're
>> not masking features properly on the newer one)?
>>
>
>Yes, Migration failed in both directions, but the error in Xend.log is
>different. When I do migrate VM from core 2 quad to core i7 machine the
>error in Xend.log is

Are you certain (i.e. is this really with the VM freshly started on the Core2
system)? I ask because this ...

>[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn't
>set eXtended States for vcpu0 (22 = Invalid argument): Internal error

... indicates that XSAVE state was available for the guest, but couldn't
be restored, yet iirc Core2 doesn't know XSAVE yet.

Irrespective of that you could try booting the hypervisors on both sides
with "no-xsave" and see whether that makes things any better (i.e.
work at least in one direction). But generally, if you opened an entry in
our bugzilla for this, we'd tell you that migration is only supported
between feature-identical machines, or at best with features masked
to the common subset on both systems.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:19:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SciEp-0001HW-G6; Thu, 07 Jun 2012 19:19:19 +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 1SciEo-0001HR-Fk
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:19:18 +0000
Received: from [85.158.143.35:15148] by server-2.bemta-4.messagelabs.com id
	E5/BD-17938-5BEF0DF4; Thu, 07 Jun 2012 19:19:17 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339096757!8865401!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4359 invoked from network); 7 Jun 2012 19:19:17 -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; 7 Jun 2012 19:19:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 19:59:02 +0100
Message-Id: <4FD108050200007800085AD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 19:59:01 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <e.shekuhi@gmail.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
In-Reply-To: <CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> elahe shekuhi <e.shekuhi@gmail.com> 06/06/12 8:15 PM >>>
>On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Does migration fail in both directions? Or perhaps just from the
>> newer to the older system (in which case I would guess you're
>> not masking features properly on the newer one)?
>>
>
>Yes, Migration failed in both directions, but the error in Xend.log is
>different. When I do migrate VM from core 2 quad to core i7 machine the
>error in Xend.log is

Are you certain (i.e. is this really with the VM freshly started on the Core2
system)? I ask because this ...

>[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn't
>set eXtended States for vcpu0 (22 = Invalid argument): Internal error

... indicates that XSAVE state was available for the guest, but couldn't
be restored, yet iirc Core2 doesn't know XSAVE yet.

Irrespective of that you could try booting the hypervisors on both sides
with "no-xsave" and see whether that makes things any better (i.e.
work at least in one direction). But generally, if you opened an entry in
our bugzilla for this, we'd tell you that migration is only supported
between feature-identical machines, or at best with features masked
to the common subset on both systems.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:43:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1Scibu-0001s6-Pr; Thu, 07 Jun 2012 19:43:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Scibt-0001s1-BI
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:43:09 +0000
Received: from [85.158.138.51:45424] by server-12.bemta-3.messagelabs.com id
	D0/97-24185-C4401DF4; Thu, 07 Jun 2012 19:43:08 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339098187!31293076!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15634 invoked from network); 7 Jun 2012 19:43:08 -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; 7 Jun 2012 19:43:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 20:43:07 +0100
Message-Id: <4FD112580200007800085AF7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 20:43:04 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <drjones@redhat.com>
References: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
	<1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
	<4FD1059C0200007800085ACA@nat28.tlf.novell.com>
In-Reply-To: <4FD1059C0200007800085ACA@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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" <jbeulich@suse.com> 06/07/12 8:50 PM >>>
>Is it perhaps the really old 3.0.4 based one, and lacking a backport of
>14041:b010e556fe2c? In that case the comparison part of the
>cmpxchg8b emulation failing would apparently be treated equally to
>e.g. a fault having occurred during the emulation (i.e. the original
>page fault would get forwarded rather than just EFLAGS.ZF getting
>set).

Having read the other thread with Andrea's explanation, that's unlikely
the culprit. He says the cmpxchg8b is being done on a PMD entry,
which the ptwr code definitely doesn't support so far.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:43:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19: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 1Scibu-0001s6-Pr; Thu, 07 Jun 2012 19:43:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Scibt-0001s1-BI
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 19:43:09 +0000
Received: from [85.158.138.51:45424] by server-12.bemta-3.messagelabs.com id
	D0/97-24185-C4401DF4; Thu, 07 Jun 2012 19:43:08 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339098187!31293076!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15634 invoked from network); 7 Jun 2012 19:43:08 -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; 7 Jun 2012 19:43:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 20:43:07 +0100
Message-Id: <4FD112580200007800085AF7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 20:43:04 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <drjones@redhat.com>
References: <479067bf-785e-4c5e-b9c9-f01653ddca7c@zmail17.collab.prod.int.phx2.redhat.com>
	<1281dad2-9115-425a-8bd3-7a23d8b8dd7f@zmail17.collab.prod.int.phx2.redhat.com>
	<4FD1059C0200007800085ACA@nat28.tlf.novell.com>
In-Reply-To: <4FD1059C0200007800085ACA@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PAE PV guest kernel regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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" <jbeulich@suse.com> 06/07/12 8:50 PM >>>
>Is it perhaps the really old 3.0.4 based one, and lacking a backport of
>14041:b010e556fe2c? In that case the comparison part of the
>cmpxchg8b emulation failing would apparently be treated equally to
>e.g. a fault having occurred during the emulation (i.e. the original
>page fault would get forwarded rather than just EFLAGS.ZF getting
>set).

Having read the other thread with Andrea's explanation, that's unlikely
the culprit. He says the cmpxchg8b is being done on a PMD entry,
which the ptwr code definitely doesn't support so far.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sciis-00020y-LO; Thu, 07 Jun 2012 19:50:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Sciiq-00020t-B0
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 19:50:20 +0000
Received: from [85.158.138.51:53832] by server-8.bemta-3.messagelabs.com id
	19/4D-22118-BF501DF4; Thu, 07 Jun 2012 19:50:19 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339098618!31322219!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30567 invoked from network); 7 Jun 2012 19:50:18 -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; 7 Jun 2012 19:50:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 20:50:17 +0100
Message-Id: <4FD114080200007800085B0A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 20:50:16 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <jrnieder@gmail.com>,<aarcange@redhat.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino> <20120607103355.GA21339@redhat.com>
In-Reply-To: <20120607103355.GA21339@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: akpm@linux-foundation.org, Sergio.Gelato@astro.su.se,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Andrea Arcangeli <aarcange@redhat.com> 06/07/12 12:35 PM >>>
>Oops, sorry I didn't imagine atomic64_read on a pmd would trip.

The problem really is that the cmpxchg8b is a write, and hence won't go
through without faulting on a write protected page (which all page table
pages necessarily are).

>I guess if Xen can't be updated to handle an atomic64_read on a pmd in
>the guest, we can add a pmd_read paravirt op?

Xen could certainly be updated to treat cmpxchg8b on a PMD entry as a
simple 8-byte read when compared-to and to-be-stored values are
identical, but the problem would be that hypervisors in the field wouldn't
necessarily get updated.

>Or if we don't want to
>break the paravirt interface a loop like gup_fast with irq disabled
>should also work but looping + local_irq_disable()/enable() sounded
>worse and more complex than a atomic64_read (gup fast already disables
>irqs because it doesn't hold the mmap_sem so it's a different cost
>looping there). AFIK Xen disables THP during boot, so a check on THP
>being enabled and falling back in the THP=n version of
>pmd_read_atomic, would also be safe, but it's not so nice to do it
>with a runtime check.

That would probably nevertheless be the most viable option. If
performance critical(?), maybe this could be hidden with something
like the alternative instruction or paravirt patching mechanisms?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 19:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 19:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sciis-00020y-LO; Thu, 07 Jun 2012 19:50:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Sciiq-00020t-B0
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 19:50:20 +0000
Received: from [85.158.138.51:53832] by server-8.bemta-3.messagelabs.com id
	19/4D-22118-BF501DF4; Thu, 07 Jun 2012 19:50:19 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339098618!31322219!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30567 invoked from network); 7 Jun 2012 19:50:18 -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; 7 Jun 2012 19:50:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Jun 2012 20:50:17 +0100
Message-Id: <4FD114080200007800085B0A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 07 Jun 2012 20:50:16 +0100
From: "Jan Beulich" <jbeulich@suse.com>
To: <jrnieder@gmail.com>,<aarcange@redhat.com>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino> <20120607103355.GA21339@redhat.com>
In-Reply-To: <20120607103355.GA21339@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: akpm@linux-foundation.org, Sergio.Gelato@astro.su.se,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Andrea Arcangeli <aarcange@redhat.com> 06/07/12 12:35 PM >>>
>Oops, sorry I didn't imagine atomic64_read on a pmd would trip.

The problem really is that the cmpxchg8b is a write, and hence won't go
through without faulting on a write protected page (which all page table
pages necessarily are).

>I guess if Xen can't be updated to handle an atomic64_read on a pmd in
>the guest, we can add a pmd_read paravirt op?

Xen could certainly be updated to treat cmpxchg8b on a PMD entry as a
simple 8-byte read when compared-to and to-be-stored values are
identical, but the problem would be that hypervisors in the field wouldn't
necessarily get updated.

>Or if we don't want to
>break the paravirt interface a loop like gup_fast with irq disabled
>should also work but looping + local_irq_disable()/enable() sounded
>worse and more complex than a atomic64_read (gup fast already disables
>irqs because it doesn't hold the mmap_sem so it's a different cost
>looping there). AFIK Xen disables THP during boot, so a check on THP
>being enabled and falling back in the THP=n version of
>pmd_read_atomic, would also be safe, but it's not so nice to do it
>with a runtime check.

That would probably nevertheless be the most viable option. If
performance critical(?), maybe this could be hidden with something
like the alternative instruction or paravirt patching mechanisms?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 20:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Scizg-0002RF-6b; Thu, 07 Jun 2012 20:07: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 1Scize-0002RA-QN
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 20:07:43 +0000
Received: from [85.158.138.51:55156] by server-4.bemta-3.messagelabs.com id
	9B/F5-13598-E0A01DF4; Thu, 07 Jun 2012 20:07:42 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339099661!22440614!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8714 invoked from network); 7 Jun 2012 20:07:41 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 20:07:41 -0000
Received: by lbom4 with SMTP id m4so1066469lbo.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 13:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=PaspWjFgu6eIamRGDye3+mPvxVv22h+ouUD4NUwjeII=;
	b=xazSBMw/Sg/hlueNHu2M2NvSqjqBGmfs8exVs06d7q1a5rFr/oMuCob4Qv4zFIOv1H
	sEJ9Avn6OOG/DR4vYJgMmcdyc+aYedkx35/bfXS7MAKQrS99fUXKvf7VwIvn/wD2ZhgJ
	ZL7L5/SaZJW8FNxEE4Oltfndihkdd3QwjcTMegTTzl3YFc9VaxLRKRF6j9LRE0Wx+TgN
	zlZ1lLL9FERP60gsUOLJyATxs/lCZLoN0NBEOGz5o4ijmWzIqTorSUSoGhw0MbERNfcn
	I64y7dT+30sM4m6kfbkAHfhJnTEP1uiAJvJq6yqrd8McnbcG/j5EPjsBK/mai7jmAk1D
	XMBw==
MIME-Version: 1.0
Received: by 10.112.103.194 with SMTP id fy2mr2027723lbb.64.1339099660816;
	Thu, 07 Jun 2012 13:07:40 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 13:07:40 -0700 (PDT)
In-Reply-To: <20120607180156.GX9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
	<CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
	<20120607180156.GX9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 16:07:40 -0400
X-Google-Sender-Auth: 6eKwEFY6I49uWbZtHCmQaxMIwxQ
Message-ID: <CAOvdn6UV1b89+wp4cfyj7ofU6T0=sdhNEoMZinPW=-AZWBOmSA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 7, 2012 at 2:01 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
<snip>
>> I'll try to dig in a bit, and report back.
>
> OK. Thanks!


OK, after throwing a bit of trace in, I remember now, the issue I was
working around.

The tty layer does not seem keep the console open.
It opens, and closes the tty based on whether there is data to print.

However, the CONFIG_CONSOLE_POLL code goes around all of this, and
uses the polling capabilities of the driver.
Most of the drivers that implement this mechanism are serial devices
where they are actually polling the UART.

When Alt+SysRq+g is pressed, the output is flushed, all references to
the hvc are released, and then hvc_close() is called.

However, since this code fully bypasses the tty layer, no reference is
grabbed - and so, when we come into hvc_poll_put_char, and the
necessary structures aren't available.

Below is an updated version of this patch that will use the
tty->driver_data, if available - but will fall back to using cons_ops.

This will guarantee that any existing users of hvc where the above
claim is not true will see no change in behavior.

However...The part of this that I don't really understand why we need
is in kernel/debug/debug_core.c
I don't like having to put the ifdef in there. I was hoping to be able
to remove it, with the upstreaming of the xen IPI code... but in
testing, it seems to still be necessary.



diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 2d691eb..7f965e1 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -767,11 +767,14 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
        struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
+       struct hvc_struct *hp = tty ? tty->driver_data : NULL;
+       struct hv_ops *ops = (hp && hp->ops) ? hp->ops : cons_ops[last_hvc];
+       uint32_t vtno = hp ? hp->vtermno : vtermnos[last_hvc];
+
        int n;
        char ch;

-       n = hp->ops->get_chars(hp->vtermno, &ch, 1);
+       n = ops->get_chars(vtno, &ch, 1);

        if (n == 0)
                return NO_POLL_CHAR;
@@ -782,11 +785,14 @@ static int hvc_poll_get_char(struct tty_driver
*driver, int line)
 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
        struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
+       struct hvc_struct *hp = tty ? tty->driver_data : NULL;
+       struct hv_ops *ops = (hp && hp->ops) ? hp->ops : cons_ops[last_hvc];
+       uint32_t vtno = hp ? hp->vtermno : vtermnos[last_hvc];
+
        int n;

        do {
-               n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+               n = ops->put_chars(vtno, &ch, 1);
        } while (n <= 0);
 }
 #endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 0557f24..853b1d7 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -579,12 +579,14 @@ return_normal:
                kgdb_roundup_cpus(flags);
 #endif

+#ifndef CONFIG_XEN
        /*
         * Wait for the other CPUs to be notified and be waiting for us:
         */
        while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
                                atomic_read(&slaves_in_kgdb)) != online_cpus)
                cpu_relax();
+#endif

        /*
         * At this point the primary processor is completely

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 20:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1Scizg-0002RF-6b; Thu, 07 Jun 2012 20:07: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 1Scize-0002RA-QN
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 20:07:43 +0000
Received: from [85.158.138.51:55156] by server-4.bemta-3.messagelabs.com id
	9B/F5-13598-E0A01DF4; Thu, 07 Jun 2012 20:07:42 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339099661!22440614!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8714 invoked from network); 7 Jun 2012 20:07:41 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 20:07:41 -0000
Received: by lbom4 with SMTP id m4so1066469lbo.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 13:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=PaspWjFgu6eIamRGDye3+mPvxVv22h+ouUD4NUwjeII=;
	b=xazSBMw/Sg/hlueNHu2M2NvSqjqBGmfs8exVs06d7q1a5rFr/oMuCob4Qv4zFIOv1H
	sEJ9Avn6OOG/DR4vYJgMmcdyc+aYedkx35/bfXS7MAKQrS99fUXKvf7VwIvn/wD2ZhgJ
	ZL7L5/SaZJW8FNxEE4Oltfndihkdd3QwjcTMegTTzl3YFc9VaxLRKRF6j9LRE0Wx+TgN
	zlZ1lLL9FERP60gsUOLJyATxs/lCZLoN0NBEOGz5o4ijmWzIqTorSUSoGhw0MbERNfcn
	I64y7dT+30sM4m6kfbkAHfhJnTEP1uiAJvJq6yqrd8McnbcG/j5EPjsBK/mai7jmAk1D
	XMBw==
MIME-Version: 1.0
Received: by 10.112.103.194 with SMTP id fy2mr2027723lbb.64.1339099660816;
	Thu, 07 Jun 2012 13:07:40 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 13:07:40 -0700 (PDT)
In-Reply-To: <20120607180156.GX9472@phenom.dumpdata.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
	<CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
	<20120607180156.GX9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 16:07:40 -0400
X-Google-Sender-Auth: 6eKwEFY6I49uWbZtHCmQaxMIwxQ
Message-ID: <CAOvdn6UV1b89+wp4cfyj7ofU6T0=sdhNEoMZinPW=-AZWBOmSA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 7, 2012 at 2:01 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
<snip>
>> I'll try to dig in a bit, and report back.
>
> OK. Thanks!


OK, after throwing a bit of trace in, I remember now, the issue I was
working around.

The tty layer does not seem keep the console open.
It opens, and closes the tty based on whether there is data to print.

However, the CONFIG_CONSOLE_POLL code goes around all of this, and
uses the polling capabilities of the driver.
Most of the drivers that implement this mechanism are serial devices
where they are actually polling the UART.

When Alt+SysRq+g is pressed, the output is flushed, all references to
the hvc are released, and then hvc_close() is called.

However, since this code fully bypasses the tty layer, no reference is
grabbed - and so, when we come into hvc_poll_put_char, and the
necessary structures aren't available.

Below is an updated version of this patch that will use the
tty->driver_data, if available - but will fall back to using cons_ops.

This will guarantee that any existing users of hvc where the above
claim is not true will see no change in behavior.

However...The part of this that I don't really understand why we need
is in kernel/debug/debug_core.c
I don't like having to put the ifdef in there. I was hoping to be able
to remove it, with the upstreaming of the xen IPI code... but in
testing, it seems to still be necessary.



diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 2d691eb..7f965e1 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -767,11 +767,14 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
        struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
+       struct hvc_struct *hp = tty ? tty->driver_data : NULL;
+       struct hv_ops *ops = (hp && hp->ops) ? hp->ops : cons_ops[last_hvc];
+       uint32_t vtno = hp ? hp->vtermno : vtermnos[last_hvc];
+
        int n;
        char ch;

-       n = hp->ops->get_chars(hp->vtermno, &ch, 1);
+       n = ops->get_chars(vtno, &ch, 1);

        if (n == 0)
                return NO_POLL_CHAR;
@@ -782,11 +785,14 @@ static int hvc_poll_get_char(struct tty_driver
*driver, int line)
 static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
 {
        struct tty_struct *tty = driver->ttys[0];
-       struct hvc_struct *hp = tty->driver_data;
+       struct hvc_struct *hp = tty ? tty->driver_data : NULL;
+       struct hv_ops *ops = (hp && hp->ops) ? hp->ops : cons_ops[last_hvc];
+       uint32_t vtno = hp ? hp->vtermno : vtermnos[last_hvc];
+
        int n;

        do {
-               n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+               n = ops->put_chars(vtno, &ch, 1);
        } while (n <= 0);
 }
 #endif
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 0557f24..853b1d7 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -579,12 +579,14 @@ return_normal:
                kgdb_roundup_cpus(flags);
 #endif

+#ifndef CONFIG_XEN
        /*
         * Wait for the other CPUs to be notified and be waiting for us:
         */
        while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
                                atomic_read(&slaves_in_kgdb)) != online_cpus)
                cpu_relax();
+#endif

        /*
         * At this point the primary processor is completely

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:01:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21: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 1Scjp7-0002u5-E8; Thu, 07 Jun 2012 21:00:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1Scjp5-0002u0-GE
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 21:00:51 +0000
Received: from [193.109.254.147:32390] by server-2.bemta-14.messagelabs.com id
	5F/6A-27740-28611DF4; Thu, 07 Jun 2012 21:00:50 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339102849!8509987!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4995 invoked from network); 7 Jun 2012 21:00:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	7 Jun 2012 21:00:49 -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 q57L0ZWs019868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:00:35 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q57L0Yb3027596; Thu, 7 Jun 2012 17:00:34 -0400
From: Andrea Arcangeli <aarcange@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>
Date: Thu,  7 Jun 2012 23:00:32 +0200
Message-Id: <1339102833-12358-1-git-send-email-aarcange@redhat.com>
In-Reply-To: <20120607190414.GF21339@redhat.com>
References: <20120607190414.GF21339@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Petr Matousek <pmatouse@redhat.com>,
	Jan Beulich <jbeulich@suse.com>,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd
	walk vs pmd_populate SMP race condition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

this should avoid the cmpxchg8b (to make Xen happy) but without
reintroducing the race condition. It's actually going to be faster
too, but it's conceptually more complicated as the pmd high/low may be
inconsistent at times, but at those times we're going to declare the
pmd unstable and ignore it anyway so it's ok.

NOTE: in theory I could also drop the high part when THP=y thanks to
the barrier() in the caller (and the barrier is needed for the generic
version anyway):

static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
	pmdval_t ret;
	u32 *tmp = (u32 *)pmdp;

	ret = (pmdval_t) (*tmp);
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
	if (ret) {
		/*
		 * If the low part is null, we must not read the high part
		 * or we can end up with a partial pmd.
		 */
		smp_rmb();
		ret |= ((pmdval_t)*(tmp + 1)) << 32;
	}
+#endif

	return (pmd_t) { ret };
}

But it's not worth the extra complexity. It looks cleaner if we deal
with "good" pmds if they're later found pointing to a pte (even if we
discard them and force pte_offset to re-read the *pmd).

Andrea Arcangeli (1):
  thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE

 arch/x86/include/asm/pgtable-3level.h |   30 +++++++++++++++++-------------
 include/asm-generic/pgtable.h         |   10 ++++++++++
 2 files changed, 27 insertions(+), 13 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:01:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21: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 1Scjp7-0002u5-E8; Thu, 07 Jun 2012 21:00:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1Scjp5-0002u0-GE
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 21:00:51 +0000
Received: from [193.109.254.147:32390] by server-2.bemta-14.messagelabs.com id
	5F/6A-27740-28611DF4; Thu, 07 Jun 2012 21:00:50 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339102849!8509987!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4995 invoked from network); 7 Jun 2012 21:00:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	7 Jun 2012 21:00:49 -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 q57L0ZWs019868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:00:35 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q57L0Yb3027596; Thu, 7 Jun 2012 17:00:34 -0400
From: Andrea Arcangeli <aarcange@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>
Date: Thu,  7 Jun 2012 23:00:32 +0200
Message-Id: <1339102833-12358-1-git-send-email-aarcange@redhat.com>
In-Reply-To: <20120607190414.GF21339@redhat.com>
References: <20120607190414.GF21339@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Petr Matousek <pmatouse@redhat.com>,
	Jan Beulich <jbeulich@suse.com>,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd
	walk vs pmd_populate SMP race condition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

this should avoid the cmpxchg8b (to make Xen happy) but without
reintroducing the race condition. It's actually going to be faster
too, but it's conceptually more complicated as the pmd high/low may be
inconsistent at times, but at those times we're going to declare the
pmd unstable and ignore it anyway so it's ok.

NOTE: in theory I could also drop the high part when THP=y thanks to
the barrier() in the caller (and the barrier is needed for the generic
version anyway):

static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
	pmdval_t ret;
	u32 *tmp = (u32 *)pmdp;

	ret = (pmdval_t) (*tmp);
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
	if (ret) {
		/*
		 * If the low part is null, we must not read the high part
		 * or we can end up with a partial pmd.
		 */
		smp_rmb();
		ret |= ((pmdval_t)*(tmp + 1)) << 32;
	}
+#endif

	return (pmd_t) { ret };
}

But it's not worth the extra complexity. It looks cleaner if we deal
with "good" pmds if they're later found pointing to a pte (even if we
discard them and force pte_offset to re-read the *pmd).

Andrea Arcangeli (1):
  thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE

 arch/x86/include/asm/pgtable-3level.h |   30 +++++++++++++++++-------------
 include/asm-generic/pgtable.h         |   10 ++++++++++
 2 files changed, 27 insertions(+), 13 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scjp9-0002uL-QQ; Thu, 07 Jun 2012 21:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1Scjp8-0002uC-H0
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 21:00:54 +0000
Received: from [85.158.143.35:36032] by server-2.bemta-4.messagelabs.com id
	AC/FB-17938-58611DF4; Thu, 07 Jun 2012 21:00:53 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339102851!4850881!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28903 invoked from network); 7 Jun 2012 21:00:52 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	7 Jun 2012 21:00:52 -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 q57L0ZsJ005974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:00:35 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q57L0Y5t002402; Thu, 7 Jun 2012 17:00:34 -0400
From: Andrea Arcangeli <aarcange@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>
Date: Thu,  7 Jun 2012 23:00:33 +0200
Message-Id: <1339102833-12358-2-git-send-email-aarcange@redhat.com>
In-Reply-To: <20120607190414.GF21339@redhat.com>
References: <20120607190414.GF21339@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, Petr Matousek <pmatouse@redhat.com>,
	Jan Beulich <jbeulich@suse.com>,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic for
	32bit 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>
MIME-Version: 1.0
Content-Type: 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 x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding
the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
contents under Xen.

So instead of dealing only with "consistent" pmdvals in
pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
where the low 32bit and high 32bit could be inconsistent (to avoid
having to use cmpxchg8b).

The only guarantee we get from pmd_read_atomic is that if the low part
of the pmd was found null, the high part will be null too (so the pmd
will be considered unstable). And if the low part of the pmd is found
"stable" later, then it means the whole pmd was read atomically
(because after a pmd is stable, neither MADV_DONTNEED nor page faults
can alter it anymore, and we read the high part after the low part).

In the 32bit PAE x86 case, it is enough to read the low part of the
pmdval atomically to declare the pmd as "stable" and that's true for
THP and no THP, furthermore in the THP case we also have a barrier()
that will prevent any inconsistent pmdvals to be cached by a later
re-read of the *pmd.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
 arch/x86/include/asm/pgtable-3level.h |   30 +++++++++++++++++-------------
 include/asm-generic/pgtable.h         |   10 ++++++++++
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..cb00ccc 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
  * they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
  * operations.
  *
- * Without THP if the mmap_sem is hold for reading, the
- * pmd can only transition from null to not null while pmd_read_atomic runs.
- * So there's no need of literally reading it atomically.
+ * Without THP if the mmap_sem is hold for reading, the pmd can only
+ * transition from null to not null while pmd_read_atomic runs. So
+ * we can always return atomic pmd values with this function.
  *
  * With THP if the mmap_sem is hold for reading, the pmd can become
- * THP or null or point to a pte (and in turn become "stable") at any
- * time under pmd_read_atomic, so it's mandatory to read it atomically
- * with cmpxchg8b.
+ * trans_huge or none or point to a pte (and in turn become "stable")
+ * at any time under pmd_read_atomic. We could read it really
+ * atomically here with a atomic64_read for the THP enabled case (and
+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we
+ * only return an atomic pmdval if the low part of the pmdval is later
+ * found stable (i.e. pointing to a pte). And we're returning a none
+ * pmdval if the low part of the pmd is none. In some cases the high
+ * and low part of the pmdval returned may not be consistent if THP is
+ * enabled (the low part may point to previously mapped hugepage,
+ * while the high part may point to a more recently mapped hugepage),
+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
+ * of the pmd to be read atomically to decide if the pmd is unstable
+ * or not, with the only exception of when the low part of the pmd is
+ * zero in which case we return a none pmd.
  */
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
 static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
 {
 	pmdval_t ret;
@@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
 
 	return (pmd_t) { ret };
 }
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
-{
-	return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
-}
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
 {
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index ae39c4b..0ff87ec 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -484,6 +484,16 @@ static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
 	/*
 	 * The barrier will stabilize the pmdval in a register or on
 	 * the stack so that it will stop changing under the code.
+	 *
+	 * When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
+	 * pmd_read_atomic is allowed to return a not atomic pmdval
+	 * (for example pointing to an hugepage that has never been
+	 * mapped in the pmd). The below checks will only care about
+	 * the low part of the pmd with 32bit PAE x86 anyway, with the
+	 * exception of pmd_none(). So the important thing is that if
+	 * the low part of the pmd is found null, the high part will
+	 * be also null or the pmd_none() check below would be
+	 * confused.
 	 */
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	barrier();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scjp9-0002uL-QQ; Thu, 07 Jun 2012 21:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1Scjp8-0002uC-H0
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 21:00:54 +0000
Received: from [85.158.143.35:36032] by server-2.bemta-4.messagelabs.com id
	AC/FB-17938-58611DF4; Thu, 07 Jun 2012 21:00:53 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339102851!4850881!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28903 invoked from network); 7 Jun 2012 21:00:52 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	7 Jun 2012 21:00:52 -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 q57L0ZsJ005974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 17:00:35 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q57L0Y5t002402; Thu, 7 Jun 2012 17:00:34 -0400
From: Andrea Arcangeli <aarcange@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>
Date: Thu,  7 Jun 2012 23:00:33 +0200
Message-Id: <1339102833-12358-2-git-send-email-aarcange@redhat.com>
In-Reply-To: <20120607190414.GF21339@redhat.com>
References: <20120607190414.GF21339@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, Petr Matousek <pmatouse@redhat.com>,
	Jan Beulich <jbeulich@suse.com>,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic for
	32bit 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>
MIME-Version: 1.0
Content-Type: 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 x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding
the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
contents under Xen.

So instead of dealing only with "consistent" pmdvals in
pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
where the low 32bit and high 32bit could be inconsistent (to avoid
having to use cmpxchg8b).

The only guarantee we get from pmd_read_atomic is that if the low part
of the pmd was found null, the high part will be null too (so the pmd
will be considered unstable). And if the low part of the pmd is found
"stable" later, then it means the whole pmd was read atomically
(because after a pmd is stable, neither MADV_DONTNEED nor page faults
can alter it anymore, and we read the high part after the low part).

In the 32bit PAE x86 case, it is enough to read the low part of the
pmdval atomically to declare the pmd as "stable" and that's true for
THP and no THP, furthermore in the THP case we also have a barrier()
that will prevent any inconsistent pmdvals to be cached by a later
re-read of the *pmd.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
 arch/x86/include/asm/pgtable-3level.h |   30 +++++++++++++++++-------------
 include/asm-generic/pgtable.h         |   10 ++++++++++
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..cb00ccc 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
  * they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
  * operations.
  *
- * Without THP if the mmap_sem is hold for reading, the
- * pmd can only transition from null to not null while pmd_read_atomic runs.
- * So there's no need of literally reading it atomically.
+ * Without THP if the mmap_sem is hold for reading, the pmd can only
+ * transition from null to not null while pmd_read_atomic runs. So
+ * we can always return atomic pmd values with this function.
  *
  * With THP if the mmap_sem is hold for reading, the pmd can become
- * THP or null or point to a pte (and in turn become "stable") at any
- * time under pmd_read_atomic, so it's mandatory to read it atomically
- * with cmpxchg8b.
+ * trans_huge or none or point to a pte (and in turn become "stable")
+ * at any time under pmd_read_atomic. We could read it really
+ * atomically here with a atomic64_read for the THP enabled case (and
+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we
+ * only return an atomic pmdval if the low part of the pmdval is later
+ * found stable (i.e. pointing to a pte). And we're returning a none
+ * pmdval if the low part of the pmd is none. In some cases the high
+ * and low part of the pmdval returned may not be consistent if THP is
+ * enabled (the low part may point to previously mapped hugepage,
+ * while the high part may point to a more recently mapped hugepage),
+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
+ * of the pmd to be read atomically to decide if the pmd is unstable
+ * or not, with the only exception of when the low part of the pmd is
+ * zero in which case we return a none pmd.
  */
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
 static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
 {
 	pmdval_t ret;
@@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
 
 	return (pmd_t) { ret };
 }
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
-{
-	return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
-}
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
 {
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index ae39c4b..0ff87ec 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -484,6 +484,16 @@ static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
 	/*
 	 * The barrier will stabilize the pmdval in a register or on
 	 * the stack so that it will stop changing under the code.
+	 *
+	 * When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
+	 * pmd_read_atomic is allowed to return a not atomic pmdval
+	 * (for example pointing to an hugepage that has never been
+	 * mapped in the pmd). The below checks will only care about
+	 * the low part of the pmd with 32bit PAE x86 anyway, with the
+	 * exception of pmd_none(). So the important thing is that if
+	 * the low part of the pmd is found null, the high part will
+	 * be also null or the pmd_none() check below would be
+	 * confused.
 	 */
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	barrier();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:02:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21: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 1Scjqe-00031W-9v; Thu, 07 Jun 2012 21:02:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1Scjqd-00031N-9D
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 21:02:27 +0000
Received: from [85.158.138.51:50087] by server-9.bemta-3.messagelabs.com id
	BD/84-15054-2E611DF4; Thu, 07 Jun 2012 21:02:26 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339102945!22445430!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3861 invoked from network); 7 Jun 2012 21:02:25 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 21:02:25 -0000
Received: by bkty5 with SMTP id y5so1235410bkt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 14:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:reply-to:to:cc:subject:x-mailer:references:in-reply-to
	:content-type:content-id:date:message-id:mime-version
	:content-transfer-encoding;
	bh=qh1ELsiTMCZ22V5gJeazhGeldZZ2QObxHsHhz/K0K6o=;
	b=ZHiG91cWO2AAibTKCbh2jB/1X+JBjYuxbhHLALcaA4VZzhONWLKlOMf7DvGzNiIGAq
	g9D3MGNhG1j5sSJSYgS9S0qYNKCg5P3Ac4kDaMijLp2D6MSrGSssgs4nKHm36VXbQVKy
	qrSJg4m66GWRFZFweUpzHIIzbmL7Pizi3DXjubqQ2xxF3OwI0i+1D/Jz9g4naPnGiXu7
	qUHxIIkdz7tPbMd1sFoPnLKxVvrZJIx6wncqz5qcWAS9nR3z0MMttXQu7QGkNMXd8Pf/
	PxKQ+T3TCjCPmVHiFJT+iIoybkYWATDwN9QGPtYJ72v7Y0nu1c2HrXWAjn8MMB/KILFb
	aejg==
Received: by 10.204.154.214 with SMTP id p22mr2941275bkw.115.1339102945283;
	Thu, 07 Jun 2012 14:02:25 -0700 (PDT)
Received: from [192.168.0.99] ([95.237.223.176])
	by mx.google.com with ESMTPS id ig1sm5279056bkc.4.2012.06.07.14.02.21
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 14:02:22 -0700 (PDT)
From: geaaru <geaaru@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailer: Modest 3.90.7
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
In-Reply-To: <20120607155814.GP9472@phenom.dumpdata.com>
Content-ID: <1339102907.2434.2.camel@Nokia-N900>
Date: Thu, 07 Jun 2012 23:01:48 +0200
Message-Id: <1339102908.2434.3.camel@Nokia-N900>
Mime-Version: 1.0
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru <geaaru@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgYXQgYWxsLAoKSSBjb25maXJtIHRoaXMgaXNzdWUgb24gZ2VudG9vIHdpdGgga2VybmVsIDMu
NC4wLgoKSG93ZXZlciwgaW4gbXkgY2FzZSBpIGNhbid0IHVzZSBub3V2ZWF1IGJlY2F1c2UgZmFu
IGlzIGFsd2F5cyBhdCAxMDAlIGZvciBhIHByb2JsZW0gb2YgdGhlIGRyaXZlci4KCklmIEkgdXNl
IG52aWRpYSBkcml2ZXIgaW4gbXkgY2FzZSBrZXJuZWwgZG9lc24ndCBvb3BwcyBidXQgSSBoYXZl
IGFsd2F5cyBibGFjayBzY3JlZW4uIFNvIGlmIEkgY2FuIGhlbHAgeW91IEkgY2FuIHJldHJpZXZl
IGRtZXNnIGFuZCBrZXJuZWwgbG9nIHRocm91Z2ggc3NoLgoKTXkgdmlkZW8gY2FyZCBpcyBndHMg
MjUwLgoKUmVnYXJkcywKCmdlYWFydQoKCk9uIFRodSBKdW7CoCAgNyAyMDEyIDA1OjU4OjE0IFBN
IENFU1QsIEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gd3Jv
dGU6Cgo+IE9uIFRodSwgSnVuIDA3LCAyMDEyIGF0IDA4OjQ5OjM3UE0gKzEwMDAsIGFvcmNoaXNA
Z21haWwuY29tIHdyb3RlOgo+ID4gT24gV2VkLCBKdW4gNiwgMjAxMiBhdCAyOjE3IEFNLCBLb25y
YWQgUnplc3p1dGVrIFdpbGsKPiA+IDxrb25yYWQud2lsa0BvcmFjbGUuY29tPiB3cm90ZToKPiA+
ID4gT24gU3VuLCBKdW4gMDMsIDIwMTIgYXQgMDU6MzE6MzJQTSArMTAwMCwgYW9yY2hpc0BnbWFp
bC5jb20gd3JvdGU6Cj4gPiA+ID4gSGkgSmVyZW15IGFuZCBLb25yYWQsCj4gPiA+IAo+ID4gPiBD
Qy1pbmcgeGVuLWRldmVsLgo+ID4gPiAKPiA+ID4gPiAKPiA+ID4gPiBCYXNpY2FsbHkgdGhlIGRy
aXZlciBOVklESUEgcHJvdmlkZWQgaXMgYSBiaW5hcnkgYmxvYiBhbmQgcmVjZW50Cj4gPiA+ID4g
dmVyc2lvbnMgZG9lcyBub3Qgd29yayB3aXRoIHRoZSBQQVQgbGF5b3V0IG9mIFhFTiBzbyBpdCBm
YWxscyBiYWNrCj4gPiA+ID4gdG8gTVRSUiB0byBwcm92aWRlIHdyaXRlIGNvbWJpbmluZyAocGxl
YXNlIGNvcnJlY3QgbWUgaWYgSSdtCj4gPiA+ID4gd3JvbmcpLgo+ID4gPiAKPiA+ID4gT0s/IFdo
aWNoIGlzIHN0aWxsIE9LLiBBcmUgeW91IHVzaW5nIGEgdjMuNCBrZXJuZWwgd2l0aCBhbiB1cC10
by1kYXRlCj4gPiA+IE5WaWRpYSBkcml2ZXI/IEkndmUgaGFkIHJlcG9ydHMgdGhhdCBpdCB3b3Jr
cyBPSy4KPiA+IAo+ID4gSSBicmllZmx5IHRyaWVkIGtlcm5lbCAzLjQgdG8gc2VlIGlmIHRoZSBw
cm9ibGVtIGlzIGZpeGVkIGJ1dCBpdCdzIG5vdC4KPiA+IEkgdXNlZCB2My40IGtlcm5lbCB3aXRo
IE5WSURJQSBkcml2ZXIgdjI5NS40OSBhbmQgYSBiZXRhIHZlcnNpb24KPiA+ICh2MzAyKSBidXQg
Ym90aCBkaWRuJ3Qgd29yay4KPiA+IAo+ID4gV2hlbiB0aGUgbnZpZGlhIG1vZHVsZSBpcyBsb2Fk
ZWQsIGl0IHByaW50cyBvdXQgYW4gZXJyb3IgbWVzc2FnZToKPiA+ICJOVlJNOiBQQVQgY29uZmln
dXJhdGlvbiB1bnN1cHBvcnRlZCwgZmFsbGluZyBiYWNrIHRvIE1UUlJzLiIKPiA+IAo+ID4gV2hl
biBJIGxhdW5jaCBYb3JnLCB0aGUgc2NyZWVuIHR1cm5zIGJsYW5rIHRoZW4gdGhlIG1vbml0b3Jz
IHBvd2VyZWQKPiA+IGRvd24gYW5kIG15IGJveCBoYXJkIGNyYXNoZWQsIEkgaGFkIHRvIGhvbGQg
dGhlIHBvd2VyIGJ1dHRvbiB0byB0dXJuCj4gPiBpdCBvZmYuCj4gCj4gT2ssIGxldHMgQ0MgQmVu
IC0gaGUgbWlnaHQgaGF2ZSBtb3JlIHVwLXRvLWRhdGUgaW5mb3JtYXRpb24uIEFsc28KPiB5b3Ug
bWlnaHQgd2FudCB0byBzZXR1cCBhIHNlcmlhbCBjb25zb2xlIHRvIGNhcHR1cmUgdGhlIGtlcm5l
bCB0byBzZWUKPiB3aGVyZSBpdCBjcmFzaGVzLgo+IAo+ID4gCj4gPiBUaGlzIG9ubHkgaGFwcGVu
cyBpbiBkb20wIHVuZGVyIFhFTiwgaWYgSSBydW4gbXkgZG9tMCBieSBpdHNlbGYgdGhlbgo+ID4g
dGhlIG52aWRpYSBtb2R1bGUgbG9hZHMgZmluZS4KPiA+IAo+ID4gPiA+IEhvd2V2ZXIgdGhlcmUg
aXMgbm8gTVRSUiBzdXBwb3J0IG9uIFhFTiBzbyB0aGUgZHJpdmVyIGhhcmQgY3Jhc2hlZAo+ID4g
PiA+IG15IG1hY2hpbmUgKEkgY2FuJ3Qgc3NoIGludG8gdGhlIGJveCBhbnltb3JlKS4KPiA+ID4g
PiAKPiA+ID4gPiBNb3Jlb3ZlciwgdGhlcmUgaXMgcHJvYmxlbSB3aXRoIHRoZSBvcGVuIHNvdXJj
ZSBkcml2ZXIgJ25vdXZlYXUnCj4gPiA+ID4gZm9yIE5WSURJQSBjYXJkIMKgKGFsc28gaGFzIHNv
bWV0aGluZyB0byBkbyB3aXRoIFBBVCBsYXlvdXQgb2YgWEVOKQo+ID4gPiA+IHdoaWNoIGNhdXNl
cyBtZW1vcnkgY29ycnVwdGlvbi4KPiA+ID4gCj4gPiA+IEh1aD8gQ2FuIHlvdSBwb2ludCBtZSB0
byBhIGJ1Z3ppbGxhIHBsZWFzZT8gVGhlcmUgd2FzIGEgY29ycnVwdGlvbgo+ID4gPiBpc3N1ZSB3
aGVyZSB5b3UgY2FuIHBhc3MgaW4gJ25vcGF0JyBvbiB0aGUgY29tbWFuZCBsaW5lLgo+ID4gCj4g
PiBZZXMsIHRoYXQgaXMgdGhlIGlzc3VlIEkgd2FzIHJlZmVycmluZyB0bywgSSBoYWQgdG8gcGFz
cyAibm9wYXQiIHRvCj4gPiBHUlVCIGluIG9yZGVyCj4gPiB0byBmaXggaXQuCj4gCj4gT2ssIHNv
IHRoZXJlIGlzIGFmYWxsIGJhY2sgZm9yIHlvdS4KPiAKPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:02:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21: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 1Scjqe-00031W-9v; Thu, 07 Jun 2012 21:02:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1Scjqd-00031N-9D
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 21:02:27 +0000
Received: from [85.158.138.51:50087] by server-9.bemta-3.messagelabs.com id
	BD/84-15054-2E611DF4; Thu, 07 Jun 2012 21:02:26 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339102945!22445430!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3861 invoked from network); 7 Jun 2012 21:02:25 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 21:02:25 -0000
Received: by bkty5 with SMTP id y5so1235410bkt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 14:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:reply-to:to:cc:subject:x-mailer:references:in-reply-to
	:content-type:content-id:date:message-id:mime-version
	:content-transfer-encoding;
	bh=qh1ELsiTMCZ22V5gJeazhGeldZZ2QObxHsHhz/K0K6o=;
	b=ZHiG91cWO2AAibTKCbh2jB/1X+JBjYuxbhHLALcaA4VZzhONWLKlOMf7DvGzNiIGAq
	g9D3MGNhG1j5sSJSYgS9S0qYNKCg5P3Ac4kDaMijLp2D6MSrGSssgs4nKHm36VXbQVKy
	qrSJg4m66GWRFZFweUpzHIIzbmL7Pizi3DXjubqQ2xxF3OwI0i+1D/Jz9g4naPnGiXu7
	qUHxIIkdz7tPbMd1sFoPnLKxVvrZJIx6wncqz5qcWAS9nR3z0MMttXQu7QGkNMXd8Pf/
	PxKQ+T3TCjCPmVHiFJT+iIoybkYWATDwN9QGPtYJ72v7Y0nu1c2HrXWAjn8MMB/KILFb
	aejg==
Received: by 10.204.154.214 with SMTP id p22mr2941275bkw.115.1339102945283;
	Thu, 07 Jun 2012 14:02:25 -0700 (PDT)
Received: from [192.168.0.99] ([95.237.223.176])
	by mx.google.com with ESMTPS id ig1sm5279056bkc.4.2012.06.07.14.02.21
	(version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 14:02:22 -0700 (PDT)
From: geaaru <geaaru@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailer: Modest 3.90.7
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
In-Reply-To: <20120607155814.GP9472@phenom.dumpdata.com>
Content-ID: <1339102907.2434.2.camel@Nokia-N900>
Date: Thu, 07 Jun 2012 23:01:48 +0200
Message-Id: <1339102908.2434.3.camel@Nokia-N900>
Mime-Version: 1.0
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru <geaaru@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgYXQgYWxsLAoKSSBjb25maXJtIHRoaXMgaXNzdWUgb24gZ2VudG9vIHdpdGgga2VybmVsIDMu
NC4wLgoKSG93ZXZlciwgaW4gbXkgY2FzZSBpIGNhbid0IHVzZSBub3V2ZWF1IGJlY2F1c2UgZmFu
IGlzIGFsd2F5cyBhdCAxMDAlIGZvciBhIHByb2JsZW0gb2YgdGhlIGRyaXZlci4KCklmIEkgdXNl
IG52aWRpYSBkcml2ZXIgaW4gbXkgY2FzZSBrZXJuZWwgZG9lc24ndCBvb3BwcyBidXQgSSBoYXZl
IGFsd2F5cyBibGFjayBzY3JlZW4uIFNvIGlmIEkgY2FuIGhlbHAgeW91IEkgY2FuIHJldHJpZXZl
IGRtZXNnIGFuZCBrZXJuZWwgbG9nIHRocm91Z2ggc3NoLgoKTXkgdmlkZW8gY2FyZCBpcyBndHMg
MjUwLgoKUmVnYXJkcywKCmdlYWFydQoKCk9uIFRodSBKdW7CoCAgNyAyMDEyIDA1OjU4OjE0IFBN
IENFU1QsIEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gd3Jv
dGU6Cgo+IE9uIFRodSwgSnVuIDA3LCAyMDEyIGF0IDA4OjQ5OjM3UE0gKzEwMDAsIGFvcmNoaXNA
Z21haWwuY29tIHdyb3RlOgo+ID4gT24gV2VkLCBKdW4gNiwgMjAxMiBhdCAyOjE3IEFNLCBLb25y
YWQgUnplc3p1dGVrIFdpbGsKPiA+IDxrb25yYWQud2lsa0BvcmFjbGUuY29tPiB3cm90ZToKPiA+
ID4gT24gU3VuLCBKdW4gMDMsIDIwMTIgYXQgMDU6MzE6MzJQTSArMTAwMCwgYW9yY2hpc0BnbWFp
bC5jb20gd3JvdGU6Cj4gPiA+ID4gSGkgSmVyZW15IGFuZCBLb25yYWQsCj4gPiA+IAo+ID4gPiBD
Qy1pbmcgeGVuLWRldmVsLgo+ID4gPiAKPiA+ID4gPiAKPiA+ID4gPiBCYXNpY2FsbHkgdGhlIGRy
aXZlciBOVklESUEgcHJvdmlkZWQgaXMgYSBiaW5hcnkgYmxvYiBhbmQgcmVjZW50Cj4gPiA+ID4g
dmVyc2lvbnMgZG9lcyBub3Qgd29yayB3aXRoIHRoZSBQQVQgbGF5b3V0IG9mIFhFTiBzbyBpdCBm
YWxscyBiYWNrCj4gPiA+ID4gdG8gTVRSUiB0byBwcm92aWRlIHdyaXRlIGNvbWJpbmluZyAocGxl
YXNlIGNvcnJlY3QgbWUgaWYgSSdtCj4gPiA+ID4gd3JvbmcpLgo+ID4gPiAKPiA+ID4gT0s/IFdo
aWNoIGlzIHN0aWxsIE9LLiBBcmUgeW91IHVzaW5nIGEgdjMuNCBrZXJuZWwgd2l0aCBhbiB1cC10
by1kYXRlCj4gPiA+IE5WaWRpYSBkcml2ZXI/IEkndmUgaGFkIHJlcG9ydHMgdGhhdCBpdCB3b3Jr
cyBPSy4KPiA+IAo+ID4gSSBicmllZmx5IHRyaWVkIGtlcm5lbCAzLjQgdG8gc2VlIGlmIHRoZSBw
cm9ibGVtIGlzIGZpeGVkIGJ1dCBpdCdzIG5vdC4KPiA+IEkgdXNlZCB2My40IGtlcm5lbCB3aXRo
IE5WSURJQSBkcml2ZXIgdjI5NS40OSBhbmQgYSBiZXRhIHZlcnNpb24KPiA+ICh2MzAyKSBidXQg
Ym90aCBkaWRuJ3Qgd29yay4KPiA+IAo+ID4gV2hlbiB0aGUgbnZpZGlhIG1vZHVsZSBpcyBsb2Fk
ZWQsIGl0IHByaW50cyBvdXQgYW4gZXJyb3IgbWVzc2FnZToKPiA+ICJOVlJNOiBQQVQgY29uZmln
dXJhdGlvbiB1bnN1cHBvcnRlZCwgZmFsbGluZyBiYWNrIHRvIE1UUlJzLiIKPiA+IAo+ID4gV2hl
biBJIGxhdW5jaCBYb3JnLCB0aGUgc2NyZWVuIHR1cm5zIGJsYW5rIHRoZW4gdGhlIG1vbml0b3Jz
IHBvd2VyZWQKPiA+IGRvd24gYW5kIG15IGJveCBoYXJkIGNyYXNoZWQsIEkgaGFkIHRvIGhvbGQg
dGhlIHBvd2VyIGJ1dHRvbiB0byB0dXJuCj4gPiBpdCBvZmYuCj4gCj4gT2ssIGxldHMgQ0MgQmVu
IC0gaGUgbWlnaHQgaGF2ZSBtb3JlIHVwLXRvLWRhdGUgaW5mb3JtYXRpb24uIEFsc28KPiB5b3Ug
bWlnaHQgd2FudCB0byBzZXR1cCBhIHNlcmlhbCBjb25zb2xlIHRvIGNhcHR1cmUgdGhlIGtlcm5l
bCB0byBzZWUKPiB3aGVyZSBpdCBjcmFzaGVzLgo+IAo+ID4gCj4gPiBUaGlzIG9ubHkgaGFwcGVu
cyBpbiBkb20wIHVuZGVyIFhFTiwgaWYgSSBydW4gbXkgZG9tMCBieSBpdHNlbGYgdGhlbgo+ID4g
dGhlIG52aWRpYSBtb2R1bGUgbG9hZHMgZmluZS4KPiA+IAo+ID4gPiA+IEhvd2V2ZXIgdGhlcmUg
aXMgbm8gTVRSUiBzdXBwb3J0IG9uIFhFTiBzbyB0aGUgZHJpdmVyIGhhcmQgY3Jhc2hlZAo+ID4g
PiA+IG15IG1hY2hpbmUgKEkgY2FuJ3Qgc3NoIGludG8gdGhlIGJveCBhbnltb3JlKS4KPiA+ID4g
PiAKPiA+ID4gPiBNb3Jlb3ZlciwgdGhlcmUgaXMgcHJvYmxlbSB3aXRoIHRoZSBvcGVuIHNvdXJj
ZSBkcml2ZXIgJ25vdXZlYXUnCj4gPiA+ID4gZm9yIE5WSURJQSBjYXJkIMKgKGFsc28gaGFzIHNv
bWV0aGluZyB0byBkbyB3aXRoIFBBVCBsYXlvdXQgb2YgWEVOKQo+ID4gPiA+IHdoaWNoIGNhdXNl
cyBtZW1vcnkgY29ycnVwdGlvbi4KPiA+ID4gCj4gPiA+IEh1aD8gQ2FuIHlvdSBwb2ludCBtZSB0
byBhIGJ1Z3ppbGxhIHBsZWFzZT8gVGhlcmUgd2FzIGEgY29ycnVwdGlvbgo+ID4gPiBpc3N1ZSB3
aGVyZSB5b3UgY2FuIHBhc3MgaW4gJ25vcGF0JyBvbiB0aGUgY29tbWFuZCBsaW5lLgo+ID4gCj4g
PiBZZXMsIHRoYXQgaXMgdGhlIGlzc3VlIEkgd2FzIHJlZmVycmluZyB0bywgSSBoYWQgdG8gcGFz
cyAibm9wYXQiIHRvCj4gPiBHUlVCIGluIG9yZGVyCj4gPiB0byBmaXggaXQuCj4gCj4gT2ssIHNv
IHRoZXJlIGlzIGFmYWxsIGJhY2sgZm9yIHlvdS4KPiAKPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21: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 1SckCz-0003aj-Eg; Thu, 07 Jun 2012 21:25:33 +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 1SckCx-0003ae-Nb
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 21:25:31 +0000
Received: from [85.158.138.51:19611] by server-1.bemta-3.messagelabs.com id
	BD/33-01327-A4C11DF4; Thu, 07 Jun 2012 21:25:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339104329!27296692!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDU2NTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32442 invoked from network); 7 Jun 2012 21:25:30 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 21:25:30 -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 E39A91E98;
	Fri,  8 Jun 2012 00:25:27 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 492AC2005D; Fri,  8 Jun 2012 00:25:27 +0300 (EEST)
Date: Fri, 8 Jun 2012 00:25:27 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Alex Moskalenko <mav@elserv.ru>
Message-ID: <20120607212526.GQ2058@reaktio.net>
References: <4FD0747D.10103@elserv.ru>
	<20120607172402.GS9472@phenom.dumpdata.com>
	<4FD0FA30.6080705@elserv.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD0FA30.6080705@elserv.ru>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 11:00:00PM +0400, Alex Moskalenko wrote:
> 07.06.2012 21:24, Konrad Rzeszutek Wilk ??????????:
> >On Thu, Jun 07, 2012 at 01:29:33PM +0400, Alex Moskalenko wrote:
> >>Hi people,
> >>
> >>I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel
> >>on IBM eServer x3400. Without noacpi command line option dom0 kernel
> >Well yes! We don't do 'noacpi' Why do you supply 'noacpi'?
> If I don't supply 'noacpi' option, dom0 kernel crashes with messages
> mentioned in my previous letter. 'noacpi' allows kernel to boot with
> some IRQ issues (only RAID ant network adapters work properly, any
> other onboard PCI device does not work at all).
> 
> >>crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
> >>patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without
> >>hypervisor all kernels run without any problems.
> >>
> >>There are several patches (available on http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/kernel-image-xen-dom0,
> >>commits f1f91babc9cc9402ccee8938b888240f5bae1574,
> >>72db7b5e069002765ced64f030c1117d72352331,
> >>adc4c567a08d4d2377060179639cbfdc3d9d8e0e and
> >>9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32
> >>to boot on this hardware. This patches written by kernel package
> >>maintainer of ALT Linux distribution. Discussion of this issue is
> >>available on Sysadmins ALTLinux mailing list
> >>(http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html
> >>and follows) in Russian.
> >>
> >>I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need
> >>this messages for more recent versions of Xen and kernel, or more
> >>information about hardware, please let me know.
> >Please provide the crash using the v3.4 kernel.
> I will provide it as soon as possible.
> 

When posting the log with Linux 3.4.x please don't compress the log with bzip2, 
it makes it difficult to read/comment about it on the mailinglist.

It isn't that big really..

> >>Ideally, I would like to run current versions of Xen and Linux
> >>kernels on this hardware. Can you help me please?
> >Well sure. But pls explain to me why:
> >  - you are using 'noacpi'
> >  - why are not using the v3.4 kernel?
> - Only with 'noacpi' kernel does not crush. Without it kernel
> crashes with logs I previously attached.
>

I didn't even notice it earlier because it was bzip2'd :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 21: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 1SckCz-0003aj-Eg; Thu, 07 Jun 2012 21:25:33 +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 1SckCx-0003ae-Nb
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 21:25:31 +0000
Received: from [85.158.138.51:19611] by server-1.bemta-3.messagelabs.com id
	BD/33-01327-A4C11DF4; Thu, 07 Jun 2012 21:25:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339104329!27296692!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDU2NTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32442 invoked from network); 7 Jun 2012 21:25:30 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 21:25:30 -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 E39A91E98;
	Fri,  8 Jun 2012 00:25:27 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 492AC2005D; Fri,  8 Jun 2012 00:25:27 +0300 (EEST)
Date: Fri, 8 Jun 2012 00:25:27 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Alex Moskalenko <mav@elserv.ru>
Message-ID: <20120607212526.GQ2058@reaktio.net>
References: <4FD0747D.10103@elserv.ru>
	<20120607172402.GS9472@phenom.dumpdata.com>
	<4FD0FA30.6080705@elserv.ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD0FA30.6080705@elserv.ru>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 11:00:00PM +0400, Alex Moskalenko wrote:
> 07.06.2012 21:24, Konrad Rzeszutek Wilk ??????????:
> >On Thu, Jun 07, 2012 at 01:29:33PM +0400, Alex Moskalenko wrote:
> >>Hi people,
> >>
> >>I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel
> >>on IBM eServer x3400. Without noacpi command line option dom0 kernel
> >Well yes! We don't do 'noacpi' Why do you supply 'noacpi'?
> If I don't supply 'noacpi' option, dom0 kernel crashes with messages
> mentioned in my previous letter. 'noacpi' allows kernel to boot with
> some IRQ issues (only RAID ant network adapters work properly, any
> other onboard PCI device does not work at all).
> 
> >>crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
> >>patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without
> >>hypervisor all kernels run without any problems.
> >>
> >>There are several patches (available on http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/kernel-image-xen-dom0,
> >>commits f1f91babc9cc9402ccee8938b888240f5bae1574,
> >>72db7b5e069002765ced64f030c1117d72352331,
> >>adc4c567a08d4d2377060179639cbfdc3d9d8e0e and
> >>9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32
> >>to boot on this hardware. This patches written by kernel package
> >>maintainer of ALT Linux distribution. Discussion of this issue is
> >>available on Sysadmins ALTLinux mailing list
> >>(http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html
> >>and follows) in Russian.
> >>
> >>I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need
> >>this messages for more recent versions of Xen and kernel, or more
> >>information about hardware, please let me know.
> >Please provide the crash using the v3.4 kernel.
> I will provide it as soon as possible.
> 

When posting the log with Linux 3.4.x please don't compress the log with bzip2, 
it makes it difficult to read/comment about it on the mailinglist.

It isn't that big really..

> >>Ideally, I would like to run current versions of Xen and Linux
> >>kernels on this hardware. Can you help me please?
> >Well sure. But pls explain to me why:
> >  - you are using 'noacpi'
> >  - why are not using the v3.4 kernel?
> - Only with 'noacpi' kernel does not crush. Without it kernel
> crashes with logs I previously attached.
>

I didn't even notice it earlier because it was bzip2'd :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:44:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1SckVO-000414-4P; Thu, 07 Jun 2012 21:44:34 +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 1SckVM-00040z-6T
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 21:44:32 +0000
Received: from [85.158.139.83:16486] by server-2.bemta-5.messagelabs.com id
	0A/CC-20827-FB021DF4; Thu, 07 Jun 2012 21:44:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339105470!32840812!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk0MzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk0MzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8067 invoked from network); 7 Jun 2012 21:44:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 21:44:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV4kY=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-8.vodafone-net.de [80.226.24.8])
	by smtp.strato.de (jorabe mo87) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U01090o57HlM9V ;
	Thu, 7 Jun 2012 23:44:29 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id A907A18638; Thu,  7 Jun 2012 23:44:27 +0200 (CEST)
Date: Thu, 7 Jun 2012 23:44:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: elahe shekuhi <e.shekuhi@gmail.com>
Message-ID: <20120607214427.GA30772@aepfle.de>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCBKdW4gMDYsIGVsYWhlIHNoZWt1aGkgd3JvdGU6Cgo+IChPbmUgbWFjaGluZSBoYXMg
Y29yZSBpNyBwcm9jZXNzb3Igd2hpbGUgYW5vdGhlciBpcyBjb3JlIDIgcXVhZCBzeXN0ZW0pLgo+
IAo+IAo+IMKgSSBoYXZlIHNlYXJjaGVkIHRoZSBuZXQgYW5kIHRoaXMgbGlzdCBhbmQgZm91bmQg
YSBmZXcgcG9zdHMgbWVudGlvbmluZyB0aGlzCj4gZXJyb3IsIGJ1dCBubyBzb2x1dGlvbiwgbm90
IGV2ZW4gYSBoaW50Cj4gwqAgwqBvbiB0aGUgc291cmNlIG9mIHRoZSBwcm9ibGVtLgoKQXMgbWVu
dGlvbmVkIGJ5IG90aGVycywgZm9yIG1pZ3JhdGlvbiAob3Igc2F2ZS9yZXN0b3JlKSBlaXRoZXIg
Ym90aApzeXN0ZW1zIGhhdmUgdG8gaGF2ZSBpZGVudGljYWwgY3B1cyBvciB0aGUgZ3Vlc3RzIHZp
ZXcgb2YgdGhlIGNwdSBoYXMgdG8KYmUgYWRqdXN0ZWQgd2l0aCB0aGUgY3B1aWQ9IGNvbmZpZyBv
cHRpb24gaW4gdGhlIHZtIGNvbmZpZyBmaWxlLiBJbgpvdGhlciB3b3JkcywgdGhlICJsZWFzdCBj
b21tb24gZGVub21pbmF0b3IiIG9mIGNwdSBmZWF0dXJlcyBoYXMgdG8gYmUKY29uZmlndXJlZC4K
ClNlZSBteSByZWNlbnQgcG9zdCB3aGljaCB0cmllcyB0byBleHBsYWluIHRoZSBjcHVpZD0gY29u
ZmlnIG9wdGlvbjoKCmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVs
LzIwMTItMDYvbXNnMDAzMDMuaHRtbAoKVGhlcmUgaXMgYW4gZXhhbXBsZSBpbiB0aGVyZSBmb3Ig
eGVuZCwgYW5kIGFsc28gYSBsaW5rIHRvIHdpa2lwZWRpYQp3aGljaCBoYXMgYSBnb29kIGxpc3Qg
b2YgY3B1IGZlYXR1cmVzLiBJIHN1Z2dlc3QgdG8gYm9vdCBib3RoIHN5c3RlbXMKd2l0aCBhIG5h
dGl2ZSBrZXJuZWwgYW5kIGNvbXBhcmUgdGhlIGNwdSBmZWF0dXJlcy4gUGVyaGFwcyB3aXRoCnNv
bWV0aGluZyBsaWtlIHRoaXM6CgpncmVwIC13bTEgXmZsYWdzIC9wcm9jL2NwdWluZm8gfCB4YXJn
cyAtbjEgfCBzb3J0ID4gL3NoYXJlX2Rpci9jb3JlMi50eHQKZ3JlcCAtd20xIF5mbGFncyAvcHJv
Yy9jcHVpbmZvIHwgeGFyZ3MgLW4xIHwgc29ydCA+IC9zaGFyZV9kaXIvaTcudHh0CmRpZmYgLXUg
L3NoYXJlX2Rpci9jb3JlMi50eHQgL3NoYXJlX2Rpci9pNy50eHQKCkkgdGhpbmsgbW9zdCBvZiB0
aGUgbGluZXMgc3RhcnRpbmcgd2l0aCAnKycgYXJlIGZlYXR1cmVzIHdoaWNoIGV4aXN0Cm9ubHkg
aW4gaTcsIHdoaWNoIGNhbiBiZSBoaWRkZW4gd2l0aCB0aGUgY3B1aWQ9IG9wdGlvbi4KCgpNYWtl
IHN1cmUgdG8gaW5zdGFsbCB0aGUgeGVuIHBhY2thZ2VzIGZyb20gdGhlIDEyLjEgdXBkYXRlIHJl
cG9zaXRvcnkKc2luY2UgdGhleSBjb250YWluIHR3byBmaXhlcyBmb3IgeW91ciBlbnZpcm9ubWVu
dDogYW4geHNhdmUgcmVsYXRlZCBidWcKd2FzIGZpeGVkLCBhbmQgYWxzbyBndWVzdHMgd2l0aCBh
IGNwdWlkPSBvcHRpb24gd2VyZSBub3QgcmVzdG9yZWQgYXQgYWxsCmR1cmluZyBzeXN0ZW0gc3Rh
cnR1cC4KCgpPbGFmCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 07 21:44:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 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 1SckVO-000414-4P; Thu, 07 Jun 2012 21:44:34 +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 1SckVM-00040z-6T
	for xen-devel@lists.xen.org; Thu, 07 Jun 2012 21:44:32 +0000
Received: from [85.158.139.83:16486] by server-2.bemta-5.messagelabs.com id
	0A/CC-20827-FB021DF4; Thu, 07 Jun 2012 21:44:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339105470!32840812!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk0MzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk0MzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8067 invoked from network); 7 Jun 2012 21:44:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 21:44:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV4kY=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-8.vodafone-net.de [80.226.24.8])
	by smtp.strato.de (jorabe mo87) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U01090o57HlM9V ;
	Thu, 7 Jun 2012 23:44:29 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id A907A18638; Thu,  7 Jun 2012 23:44:27 +0200 (CEST)
Date: Thu, 7 Jun 2012 23:44:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: elahe shekuhi <e.shekuhi@gmail.com>
Message-ID: <20120607214427.GA30772@aepfle.de>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCBKdW4gMDYsIGVsYWhlIHNoZWt1aGkgd3JvdGU6Cgo+IChPbmUgbWFjaGluZSBoYXMg
Y29yZSBpNyBwcm9jZXNzb3Igd2hpbGUgYW5vdGhlciBpcyBjb3JlIDIgcXVhZCBzeXN0ZW0pLgo+
IAo+IAo+IMKgSSBoYXZlIHNlYXJjaGVkIHRoZSBuZXQgYW5kIHRoaXMgbGlzdCBhbmQgZm91bmQg
YSBmZXcgcG9zdHMgbWVudGlvbmluZyB0aGlzCj4gZXJyb3IsIGJ1dCBubyBzb2x1dGlvbiwgbm90
IGV2ZW4gYSBoaW50Cj4gwqAgwqBvbiB0aGUgc291cmNlIG9mIHRoZSBwcm9ibGVtLgoKQXMgbWVu
dGlvbmVkIGJ5IG90aGVycywgZm9yIG1pZ3JhdGlvbiAob3Igc2F2ZS9yZXN0b3JlKSBlaXRoZXIg
Ym90aApzeXN0ZW1zIGhhdmUgdG8gaGF2ZSBpZGVudGljYWwgY3B1cyBvciB0aGUgZ3Vlc3RzIHZp
ZXcgb2YgdGhlIGNwdSBoYXMgdG8KYmUgYWRqdXN0ZWQgd2l0aCB0aGUgY3B1aWQ9IGNvbmZpZyBv
cHRpb24gaW4gdGhlIHZtIGNvbmZpZyBmaWxlLiBJbgpvdGhlciB3b3JkcywgdGhlICJsZWFzdCBj
b21tb24gZGVub21pbmF0b3IiIG9mIGNwdSBmZWF0dXJlcyBoYXMgdG8gYmUKY29uZmlndXJlZC4K
ClNlZSBteSByZWNlbnQgcG9zdCB3aGljaCB0cmllcyB0byBleHBsYWluIHRoZSBjcHVpZD0gY29u
ZmlnIG9wdGlvbjoKCmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVs
LzIwMTItMDYvbXNnMDAzMDMuaHRtbAoKVGhlcmUgaXMgYW4gZXhhbXBsZSBpbiB0aGVyZSBmb3Ig
eGVuZCwgYW5kIGFsc28gYSBsaW5rIHRvIHdpa2lwZWRpYQp3aGljaCBoYXMgYSBnb29kIGxpc3Qg
b2YgY3B1IGZlYXR1cmVzLiBJIHN1Z2dlc3QgdG8gYm9vdCBib3RoIHN5c3RlbXMKd2l0aCBhIG5h
dGl2ZSBrZXJuZWwgYW5kIGNvbXBhcmUgdGhlIGNwdSBmZWF0dXJlcy4gUGVyaGFwcyB3aXRoCnNv
bWV0aGluZyBsaWtlIHRoaXM6CgpncmVwIC13bTEgXmZsYWdzIC9wcm9jL2NwdWluZm8gfCB4YXJn
cyAtbjEgfCBzb3J0ID4gL3NoYXJlX2Rpci9jb3JlMi50eHQKZ3JlcCAtd20xIF5mbGFncyAvcHJv
Yy9jcHVpbmZvIHwgeGFyZ3MgLW4xIHwgc29ydCA+IC9zaGFyZV9kaXIvaTcudHh0CmRpZmYgLXUg
L3NoYXJlX2Rpci9jb3JlMi50eHQgL3NoYXJlX2Rpci9pNy50eHQKCkkgdGhpbmsgbW9zdCBvZiB0
aGUgbGluZXMgc3RhcnRpbmcgd2l0aCAnKycgYXJlIGZlYXR1cmVzIHdoaWNoIGV4aXN0Cm9ubHkg
aW4gaTcsIHdoaWNoIGNhbiBiZSBoaWRkZW4gd2l0aCB0aGUgY3B1aWQ9IG9wdGlvbi4KCgpNYWtl
IHN1cmUgdG8gaW5zdGFsbCB0aGUgeGVuIHBhY2thZ2VzIGZyb20gdGhlIDEyLjEgdXBkYXRlIHJl
cG9zaXRvcnkKc2luY2UgdGhleSBjb250YWluIHR3byBmaXhlcyBmb3IgeW91ciBlbnZpcm9ubWVu
dDogYW4geHNhdmUgcmVsYXRlZCBidWcKd2FzIGZpeGVkLCBhbmQgYWxzbyBndWVzdHMgd2l0aCBh
IGNwdWlkPSBvcHRpb24gd2VyZSBub3QgcmVzdG9yZWQgYXQgYWxsCmR1cmluZyBzeXN0ZW0gc3Rh
cnR1cC4KCgpPbGFmCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 07 22:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 22: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 1Sckr1-0004Oh-7D; Thu, 07 Jun 2012 22:06:55 +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 1Sckqz-0004Oc-6A
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 22:06:53 +0000
Received: from [85.158.143.99:43736] by server-1.bemta-4.messagelabs.com id
	3A/F4-10042-CF521DF4; Thu, 07 Jun 2012 22:06:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339106810!20623635!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28955 invoked from network); 7 Jun 2012 22:06:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 22:06:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57M6gkh029173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 22:06:43 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q57M6fi0022793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 22:06:41 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
	q57M6eNw005177; Thu, 7 Jun 2012 17:06:40 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 15:06:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 430014029B; Thu,  7 Jun 2012 17:59:42 -0400 (EDT)
Date: Thu, 7 Jun 2012 17:59:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120607215942.GA13592@phenom.dumpdata.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"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>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 11:16:29AM +0100, Stefano Stabellini wrote:
> On Thu, 31 May 2012, Konrad Rzeszutek Wilk wrote:
> > The blkfront_remove part is .. that is going to take some surgery to do
> > and I don't think I am going to be able to attempt that within the next couple
> > of weeks. So lets put that on the TODO list and just do this one?
> 
> OK
> 
> > >From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Fri, 25 May 2012 17:34:51 -0400
> > Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> > 
> > Part of the ring structure is the 'id' field which is under
> > control of the frontend. The frontend stamps it with "some"
> > value (this some in this implementation being a value less
> > than BLK_RING_SIZE), and when it gets a response expects
> > said value to be in the response structure. We have a check
> > for the id field when spolling new requests but not when
> > de-spolling responses.
> > 
> > We also add an extra check in add_id_to_freelist to make
> > sure that the 'struct request' was not NULL - as we cannot
> > pass a NULL to __blk_end_request_all, otherwise that crashes
> > (and all the operations that the response is dealing with
> > end up with __blk_end_request_all).
> > 
> > Lastly we also print the name of the operation that failed.
> > 
> > [v1: s/BUG/WARN/ suggested by Stefano]
> > [v2: Add extra check in add_id_to_freelist]
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
> >  1 files changed, 29 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 60eed4b..c7ef8a4 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info *info)
> >  static void add_id_to_freelist(struct blkfront_info *info,
> >  			       unsigned long id)
> >  {
> > +	BUG_ON(info->shadow[id].req.u.rw.id != id);
> >  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> > +	BUG_ON(info->shadow[id].request == NULL);
> >  	info->shadow[id].request = NULL;
> >  	info->shadow_free = id;
> >  }
> 
> Like Jan said, it would be best to change the two BUG_ON into WARN_ON
> and return an error.

Yes. I missed that.
> 
> 
> > +static const char *op_name(int op)
> > +{
> > +	const char *names[BLKIF_OP_DISCARD+1] = {
> > +		"read" , "write", "barrier", "flush", "reserved", "discard"};
> > +
> > +	if (op > BLKIF_OP_DISCARD)
> > +		return "unknown";
> > +	return names[op];
> > +}
> 
> Considering that op is an int, shoudn't we check for negative values
> too?

Yes! I also converted this per Jan's excellent idea.

Please see:


>From 3877611c3096423a7741e99e9c9b9e63a9f2e557 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 25 May 2012 17:34:51 -0400
Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.

Part of the ring structure is the 'id' field which is under
control of the frontend. The frontend stamps it with "some"
value (this some in this implementation being a value less
than BLK_RING_SIZE), and when it gets a response expects
said value to be in the response structure. We have a check
for the id field when spolling new requests but not when
de-spolling responses.

We also add an extra check in add_id_to_freelist to make
sure that the 'struct request' was not NULL - as we cannot
pass a NULL to __blk_end_request_all, otherwise that crashes
(and all the operations that the response is dealing with
end up with __blk_end_request_all).

Lastly we also print the name of the operation that failed.

[v1: s/BUG/WARN/ suggested by Stefano]
[v2: Add extra check in add_id_to_freelist]
[v3: Redid op_name per Jan's suggestion]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c     |   58 +++++++++++++++++++++++++++++--------
 include/xen/interface/io/blkif.h |    6 ++++
 2 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..ae8e3b7 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -141,14 +141,33 @@ static int get_id_from_freelist(struct blkfront_info *info)
 	return free;
 }
 
-static void add_id_to_freelist(struct blkfront_info *info,
+static int add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
+	if (info->shadow[id].req.u.rw.id != id)
+		return -EINVAL;
+	if (info->shadow[id].request == NULL)
+		return -EINVAL;
 	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
+	return 0;
 }
 
+static const char *op_name(int op)
+{
+	static const char *names[] = {
+		[BLKIF_OP_READ] = "read",
+		[BLKIF_OP_WRITE] = "write",
+		[BLKIF_OP_WRITE_BARRIER] = "barrier",
+		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
+		[BLKIF_OP_RESERVED_1] = "reserved",
+		[BLKIF_OP_DISCARD] = "discard" };
+
+	if (op < 0 || op >= ARRAY_SIZE(names))
+		return "unknown";
+	return names[op];
+}
 static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 {
 	unsigned int end = minor + nr;
@@ -744,20 +763,31 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 
 		bret = RING_GET_RESPONSE(&info->ring, i);
 		id   = bret->id;
+		/*
+		 * The backend has messed up and given us an id that we would
+		 * never have given to it (we stamp it up to BLK_RING_SIZE -
+		 * look in get_id_from_freelist.
+		 */
+		if (id >= BLK_RING_SIZE)
+			/* We can't safely get the 'struct request' as
+			 * the id is busted. So limp along. */
+			goto err_out;
+
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
 			blkif_completion(&info->shadow[id]);
 
-		add_id_to_freelist(info, id);
+		if (add_id_to_freelist(info, id))
+			goto err_out;
 
 		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
 		switch (bret->operation) {
 		case BLKIF_OP_DISCARD:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
 				struct request_queue *rq = info->rq;
-				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
-					   info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+					   info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
 				info->feature_secdiscard = 0;
@@ -769,18 +799,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		case BLKIF_OP_FLUSH_DISKCACHE:
 		case BLKIF_OP_WRITE_BARRIER:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
-				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
 				     info->shadow[id].req.u.rw.nr_segments == 0)) {
-				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(error)) {
@@ -813,12 +839,18 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 			goto again;
 	} else
 		info->ring.sring->rsp_event = i + 1;
-
 	kick_pending_request_queues(info);
 
 	spin_unlock_irqrestore(&blkif_io_lock, flags);
 
 	return IRQ_HANDLED;
+err_out:
+	WARN(1, "%s: response to %s has incorrect id\n",
+	     info->gd->disk_name, op_name(bret->operation));
+
+	spin_unlock_irqrestore(&info->io_lock, flags);
+
+	return IRQ_HANDLED;
 }
 
 
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index ee338bf..bc75c75 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -59,6 +59,12 @@ typedef uint64_t blkif_sector_t;
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 
 /*
+ * Used in SLES sources for device specific command packet
+ * contained within the request. Reserved for that purpose.
+ */
+#define BLKIF_OP_RESERVED_1        4
+
+/*
  * Recognised only if "feature-discard" is present in backend xenbus info.
  * The "feature-discard" node contains a boolean indicating whether trim
  * (ATA) or unmap (SCSI) - conviently called discard requests are likely
-- 
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 Jun 07 22:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 22: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 1Sckr1-0004Oh-7D; Thu, 07 Jun 2012 22:06:55 +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 1Sckqz-0004Oc-6A
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 22:06:53 +0000
Received: from [85.158.143.99:43736] by server-1.bemta-4.messagelabs.com id
	3A/F4-10042-CF521DF4; Thu, 07 Jun 2012 22:06:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339106810!20623635!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1NTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28955 invoked from network); 7 Jun 2012 22:06:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Jun 2012 22:06:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q57M6gkh029173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Jun 2012 22:06:43 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q57M6fi0022793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Jun 2012 22:06:41 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
	q57M6eNw005177; Thu, 7 Jun 2012 17:06:40 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Jun 2012 15:06:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 430014029B; Thu,  7 Jun 2012 17:59:42 -0400 (EDT)
Date: Thu, 7 Jun 2012 17:59:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120607215942.GA13592@phenom.dumpdata.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"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>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 01, 2012 at 11:16:29AM +0100, Stefano Stabellini wrote:
> On Thu, 31 May 2012, Konrad Rzeszutek Wilk wrote:
> > The blkfront_remove part is .. that is going to take some surgery to do
> > and I don't think I am going to be able to attempt that within the next couple
> > of weeks. So lets put that on the TODO list and just do this one?
> 
> OK
> 
> > >From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Fri, 25 May 2012 17:34:51 -0400
> > Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> > 
> > Part of the ring structure is the 'id' field which is under
> > control of the frontend. The frontend stamps it with "some"
> > value (this some in this implementation being a value less
> > than BLK_RING_SIZE), and when it gets a response expects
> > said value to be in the response structure. We have a check
> > for the id field when spolling new requests but not when
> > de-spolling responses.
> > 
> > We also add an extra check in add_id_to_freelist to make
> > sure that the 'struct request' was not NULL - as we cannot
> > pass a NULL to __blk_end_request_all, otherwise that crashes
> > (and all the operations that the response is dealing with
> > end up with __blk_end_request_all).
> > 
> > Lastly we also print the name of the operation that failed.
> > 
> > [v1: s/BUG/WARN/ suggested by Stefano]
> > [v2: Add extra check in add_id_to_freelist]
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
> >  1 files changed, 29 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 60eed4b..c7ef8a4 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info *info)
> >  static void add_id_to_freelist(struct blkfront_info *info,
> >  			       unsigned long id)
> >  {
> > +	BUG_ON(info->shadow[id].req.u.rw.id != id);
> >  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> > +	BUG_ON(info->shadow[id].request == NULL);
> >  	info->shadow[id].request = NULL;
> >  	info->shadow_free = id;
> >  }
> 
> Like Jan said, it would be best to change the two BUG_ON into WARN_ON
> and return an error.

Yes. I missed that.
> 
> 
> > +static const char *op_name(int op)
> > +{
> > +	const char *names[BLKIF_OP_DISCARD+1] = {
> > +		"read" , "write", "barrier", "flush", "reserved", "discard"};
> > +
> > +	if (op > BLKIF_OP_DISCARD)
> > +		return "unknown";
> > +	return names[op];
> > +}
> 
> Considering that op is an int, shoudn't we check for negative values
> too?

Yes! I also converted this per Jan's excellent idea.

Please see:


>From 3877611c3096423a7741e99e9c9b9e63a9f2e557 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 25 May 2012 17:34:51 -0400
Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.

Part of the ring structure is the 'id' field which is under
control of the frontend. The frontend stamps it with "some"
value (this some in this implementation being a value less
than BLK_RING_SIZE), and when it gets a response expects
said value to be in the response structure. We have a check
for the id field when spolling new requests but not when
de-spolling responses.

We also add an extra check in add_id_to_freelist to make
sure that the 'struct request' was not NULL - as we cannot
pass a NULL to __blk_end_request_all, otherwise that crashes
(and all the operations that the response is dealing with
end up with __blk_end_request_all).

Lastly we also print the name of the operation that failed.

[v1: s/BUG/WARN/ suggested by Stefano]
[v2: Add extra check in add_id_to_freelist]
[v3: Redid op_name per Jan's suggestion]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c     |   58 +++++++++++++++++++++++++++++--------
 include/xen/interface/io/blkif.h |    6 ++++
 2 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..ae8e3b7 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -141,14 +141,33 @@ static int get_id_from_freelist(struct blkfront_info *info)
 	return free;
 }
 
-static void add_id_to_freelist(struct blkfront_info *info,
+static int add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
+	if (info->shadow[id].req.u.rw.id != id)
+		return -EINVAL;
+	if (info->shadow[id].request == NULL)
+		return -EINVAL;
 	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
+	return 0;
 }
 
+static const char *op_name(int op)
+{
+	static const char *names[] = {
+		[BLKIF_OP_READ] = "read",
+		[BLKIF_OP_WRITE] = "write",
+		[BLKIF_OP_WRITE_BARRIER] = "barrier",
+		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
+		[BLKIF_OP_RESERVED_1] = "reserved",
+		[BLKIF_OP_DISCARD] = "discard" };
+
+	if (op < 0 || op >= ARRAY_SIZE(names))
+		return "unknown";
+	return names[op];
+}
 static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 {
 	unsigned int end = minor + nr;
@@ -744,20 +763,31 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 
 		bret = RING_GET_RESPONSE(&info->ring, i);
 		id   = bret->id;
+		/*
+		 * The backend has messed up and given us an id that we would
+		 * never have given to it (we stamp it up to BLK_RING_SIZE -
+		 * look in get_id_from_freelist.
+		 */
+		if (id >= BLK_RING_SIZE)
+			/* We can't safely get the 'struct request' as
+			 * the id is busted. So limp along. */
+			goto err_out;
+
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
 			blkif_completion(&info->shadow[id]);
 
-		add_id_to_freelist(info, id);
+		if (add_id_to_freelist(info, id))
+			goto err_out;
 
 		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
 		switch (bret->operation) {
 		case BLKIF_OP_DISCARD:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
 				struct request_queue *rq = info->rq;
-				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
-					   info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+					   info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
 				info->feature_secdiscard = 0;
@@ -769,18 +799,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		case BLKIF_OP_FLUSH_DISKCACHE:
 		case BLKIF_OP_WRITE_BARRIER:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
-				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
 				     info->shadow[id].req.u.rw.nr_segments == 0)) {
-				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(error)) {
@@ -813,12 +839,18 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 			goto again;
 	} else
 		info->ring.sring->rsp_event = i + 1;
-
 	kick_pending_request_queues(info);
 
 	spin_unlock_irqrestore(&blkif_io_lock, flags);
 
 	return IRQ_HANDLED;
+err_out:
+	WARN(1, "%s: response to %s has incorrect id\n",
+	     info->gd->disk_name, op_name(bret->operation));
+
+	spin_unlock_irqrestore(&info->io_lock, flags);
+
+	return IRQ_HANDLED;
 }
 
 
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index ee338bf..bc75c75 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -59,6 +59,12 @@ typedef uint64_t blkif_sector_t;
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 
 /*
+ * Used in SLES sources for device specific command packet
+ * contained within the request. Reserved for that purpose.
+ */
+#define BLKIF_OP_RESERVED_1        4
+
+/*
  * Recognised only if "feature-discard" is present in backend xenbus info.
  * The "feature-discard" node contains a boolean indicating whether trim
  * (ATA) or unmap (SCSI) - conviently called discard requests are likely
-- 
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 Jun 07 23:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 23:40: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 1ScmJ4-0005QN-80; Thu, 07 Jun 2012 23:39:58 +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 1ScmJ2-0005QH-7N
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 23:39:56 +0000
Received: from [85.158.138.51:40320] by server-7.bemta-3.messagelabs.com id
	57/F8-01983-BCB31DF4; Thu, 07 Jun 2012 23:39:55 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339112394!12664683!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14823 invoked from network); 7 Jun 2012 23:39:54 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 23:39:54 -0000
Received: by lahg1 with SMTP id g1so1076041lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 16:39:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=E2ByHQW6YamLhN21KrVz6dY28c8mY0g/DGMjJJ9RYck=;
	b=hHTWTsTe8pIUZ1Uh+LU6DZUz2a9vXH+9BgZNx9W9mQkF2znIazED/XkE81UkotSbSZ
	K8IrXHNAP6gJ2KrANEp3K5nWSbhXYipaB96IxsEEvdW9DsNbxxN4rQWlVS8dEAmPC//L
	nUCRV4xJBUfydoyG3CqnMtw7HY9kZbgVgVmB1wU+xQzM5aJamrjElB2KDjkuvBXrVmDt
	mXXMiu3NFVCLwNg647ioccrjWTZyo1B0KGz0bQFeG5oarLZuoszq+7T+23OaFcJrzsh4
	e+HycTLseI121qjOJwsKeKobpDZkqmHznVdsTYt8mOzGn5RMg8mCgnUEXRAcYGGIZ0HN
	opXw==
MIME-Version: 1.0
Received: by 10.152.103.11 with SMTP id fs11mr4738903lab.23.1339112393942;
	Thu, 07 Jun 2012 16:39:53 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 16:39:53 -0700 (PDT)
In-Reply-To: <20120607155814.GP9472@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 19:39:53 -0400
X-Google-Sender-Auth: iI36NC-8N8zIMVWQFFkc8Us99yA
Message-ID: <CAOvdn6Up2tvr7r_=hv8GP0EoeXNqu8QWUbgYak89eAoevHN+Hg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	"aorchis@gmail.com" <aorchis@gmail.com>
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 11:58 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Jun 07, 2012 at 08:49:37PM +1000, aorchis@gmail.com wrote:
>> On Wed, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>> > On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
>> >> Hi Jeremy and Konrad,
>> >
>> > CC-ing xen-devel.
>> >
>> >>
>> >> Basically the driver NVIDIA provided is a binary blob and recent
>> >> versions does not work with the PAT layout of XEN so it falls back to
>> >> MTRR to provide write combining (please correct me if I'm wrong).
>> >
>> > OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
>> > NVidia driver? I've had reports that it works OK.
>>
>> I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
>> I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
>> (v302) but both didn't work.
>>
>> When the nvidia module is loaded, it prints out an error message:
>> "NVRM: PAT configuration unsupported, falling back to MTRRs."
>>
>> When I launch Xorg, the screen turns blank then the monitors powered dow=
n and my
>> box hard crashed, I had to hold the power button to turn it off.
>
> Ok, lets CC Ben - he might have more up-to-date information. Also
> you might want to setup a serial console to capture the kernel to see
> where it crashes.
>

Sorry - we ended up needing to abandon using the closed source driver,
as despite compiling it with IGNORE_XEN_PRESENCE set, I was never able
to get it to work with the 3.2 linux kernel.

Since we had reasonably good luck with the nouveau drivers, and our
OpenGL use case is pretty basic - it ended up being sufficient for our
needs.

I'd have to do some email archeology to see what the specific failure
was...but it sounds very similar to the problem desribed above.

I apologize that I'm not a lot of help here.

/btg

>>
>> This only happens in dom0 under XEN, if I run my dom0 by itself then
>> the nvidia module loads fine.
>>
>> >> However there is no MTRR support on XEN so the driver hard crashed my
>> >> machine (I can't ssh into the box anymore).
>> >>
>> >> Moreover, there is problem with the open source driver 'nouveau' for
>> >> NVIDIA card =A0(also has something to do with PAT layout of XEN) which
>> >> causes memory corruption.
>> >
>> > Huh? Can you point me to a bugzilla please? There was a corruption
>> > issue where you can pass in 'nopat' on the command line.
>>
>> Yes, that is the issue I was referring to, I had to pass "nopat" to
>> GRUB in order
>> to fix it.
>
> Ok, so there is afall back for you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 23:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 23:40: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 1ScmJ4-0005QN-80; Thu, 07 Jun 2012 23:39:58 +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 1ScmJ2-0005QH-7N
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 23:39:56 +0000
Received: from [85.158.138.51:40320] by server-7.bemta-3.messagelabs.com id
	57/F8-01983-BCB31DF4; Thu, 07 Jun 2012 23:39:55 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339112394!12664683!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14823 invoked from network); 7 Jun 2012 23:39:54 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 23:39:54 -0000
Received: by lahg1 with SMTP id g1so1076041lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 16:39:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=E2ByHQW6YamLhN21KrVz6dY28c8mY0g/DGMjJJ9RYck=;
	b=hHTWTsTe8pIUZ1Uh+LU6DZUz2a9vXH+9BgZNx9W9mQkF2znIazED/XkE81UkotSbSZ
	K8IrXHNAP6gJ2KrANEp3K5nWSbhXYipaB96IxsEEvdW9DsNbxxN4rQWlVS8dEAmPC//L
	nUCRV4xJBUfydoyG3CqnMtw7HY9kZbgVgVmB1wU+xQzM5aJamrjElB2KDjkuvBXrVmDt
	mXXMiu3NFVCLwNg647ioccrjWTZyo1B0KGz0bQFeG5oarLZuoszq+7T+23OaFcJrzsh4
	e+HycTLseI121qjOJwsKeKobpDZkqmHznVdsTYt8mOzGn5RMg8mCgnUEXRAcYGGIZ0HN
	opXw==
MIME-Version: 1.0
Received: by 10.152.103.11 with SMTP id fs11mr4738903lab.23.1339112393942;
	Thu, 07 Jun 2012 16:39:53 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 16:39:53 -0700 (PDT)
In-Reply-To: <20120607155814.GP9472@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 19:39:53 -0400
X-Google-Sender-Auth: iI36NC-8N8zIMVWQFFkc8Us99yA
Message-ID: <CAOvdn6Up2tvr7r_=hv8GP0EoeXNqu8QWUbgYak89eAoevHN+Hg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	"aorchis@gmail.com" <aorchis@gmail.com>
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 11:58 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Jun 07, 2012 at 08:49:37PM +1000, aorchis@gmail.com wrote:
>> On Wed, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>> > On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
>> >> Hi Jeremy and Konrad,
>> >
>> > CC-ing xen-devel.
>> >
>> >>
>> >> Basically the driver NVIDIA provided is a binary blob and recent
>> >> versions does not work with the PAT layout of XEN so it falls back to
>> >> MTRR to provide write combining (please correct me if I'm wrong).
>> >
>> > OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
>> > NVidia driver? I've had reports that it works OK.
>>
>> I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
>> I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
>> (v302) but both didn't work.
>>
>> When the nvidia module is loaded, it prints out an error message:
>> "NVRM: PAT configuration unsupported, falling back to MTRRs."
>>
>> When I launch Xorg, the screen turns blank then the monitors powered dow=
n and my
>> box hard crashed, I had to hold the power button to turn it off.
>
> Ok, lets CC Ben - he might have more up-to-date information. Also
> you might want to setup a serial console to capture the kernel to see
> where it crashes.
>

Sorry - we ended up needing to abandon using the closed source driver,
as despite compiling it with IGNORE_XEN_PRESENCE set, I was never able
to get it to work with the 3.2 linux kernel.

Since we had reasonably good luck with the nouveau drivers, and our
OpenGL use case is pretty basic - it ended up being sufficient for our
needs.

I'd have to do some email archeology to see what the specific failure
was...but it sounds very similar to the problem desribed above.

I apologize that I'm not a lot of help here.

/btg

>>
>> This only happens in dom0 under XEN, if I run my dom0 by itself then
>> the nvidia module loads fine.
>>
>> >> However there is no MTRR support on XEN so the driver hard crashed my
>> >> machine (I can't ssh into the box anymore).
>> >>
>> >> Moreover, there is problem with the open source driver 'nouveau' for
>> >> NVIDIA card =A0(also has something to do with PAT layout of XEN) which
>> >> causes memory corruption.
>> >
>> > Huh? Can you point me to a bugzilla please? There was a corruption
>> > issue where you can pass in 'nopat' on the command line.
>>
>> Yes, that is the issue I was referring to, I had to pass "nopat" to
>> GRUB in order
>> to fix it.
>
> Ok, so there is afall back for you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 23:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 23: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 1ScmNC-0005aO-St; Thu, 07 Jun 2012 23:44:14 +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 1ScmNC-0005aI-4r
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 23:44:14 +0000
Received: from [193.109.254.147:25865] by server-9.bemta-14.messagelabs.com id
	C9/AE-27072-DCC31DF4; Thu, 07 Jun 2012 23:44:13 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339112651!8736136!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18148 invoked from network); 7 Jun 2012 23:44:11 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 23:44:11 -0000
Received: by lahg1 with SMTP id g1so1078209lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 16:44:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=HFXvOr4cZulLynwRmZ2CAMIW3ZJH9BAvhsf6eqO/b/g=;
	b=t7jiogzjZ9HwYv1VkX9qC4W2Ah/tv9ROFaoQqenJrisW2+uyDw15BhYZigFMLQkTAT
	Zy07ADE/pMiGkYwRDIK4vbuUil5LHtz39x8p7M/nmIUS1lYyLiAF7BKL96/nESZDZ/ZR
	ewneu4CMJ6I/DQ7p+MU0xuwVzvtiEsWNPlSU2Iy6Kz1cfV94AlCsnYSimWX9T7GLX42x
	8NlnlzTKM0l+zlQe0M+JsVLbQqIUFwItiur9Cy25vRqP895OJfh/a4KbWsNLvz4oTdGk
	2QOGCNt+c1ylSFCChaksfzNJBmUDi653515xPTGnWeeUBP/ocVtwXu5nz6djI3cr2oGD
	nONg==
MIME-Version: 1.0
Received: by 10.152.102.234 with SMTP id fr10mr4834895lab.32.1339112651089;
	Thu, 07 Jun 2012 16:44:11 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 16:44:11 -0700 (PDT)
In-Reply-To: <CAOvdn6Up2tvr7r_=hv8GP0EoeXNqu8QWUbgYak89eAoevHN+Hg@mail.gmail.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
	<CAOvdn6Up2tvr7r_=hv8GP0EoeXNqu8QWUbgYak89eAoevHN+Hg@mail.gmail.com>
Date: Thu, 7 Jun 2012 19:44:11 -0400
X-Google-Sender-Auth: megcyFCJALD1C9-OfMwEPo4F-i0
Message-ID: <CAOvdn6WxWFcHLchx-nN8sHyrREC45kA1Vhc6wUE9Yft_hJXZBA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	"aorchis@gmail.com" <aorchis@gmail.com>
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These were the failures I was seeing:

http://www.nvnews.net/vbulletin/showthread.php?t=3D174219

going back through old xen-devel emails, the XID failure looks like it
has been happening for about a year, at least.

I have not tried on kernels newer than 3.2

On Thu, Jun 7, 2012 at 7:39 PM, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Jun 7, 2012 at 11:58 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Thu, Jun 07, 2012 at 08:49:37PM +1000, aorchis@gmail.com wrote:
>>> On Wed, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote:
>>> > On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
>>> >> Hi Jeremy and Konrad,
>>> >
>>> > CC-ing xen-devel.
>>> >
>>> >>
>>> >> Basically the driver NVIDIA provided is a binary blob and recent
>>> >> versions does not work with the PAT layout of XEN so it falls back to
>>> >> MTRR to provide write combining (please correct me if I'm wrong).
>>> >
>>> > OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
>>> > NVidia driver? I've had reports that it works OK.
>>>
>>> I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
>>> I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
>>> (v302) but both didn't work.
>>>
>>> When the nvidia module is loaded, it prints out an error message:
>>> "NVRM: PAT configuration unsupported, falling back to MTRRs."
>>>
>>> When I launch Xorg, the screen turns blank then the monitors powered do=
wn and my
>>> box hard crashed, I had to hold the power button to turn it off.
>>
>> Ok, lets CC Ben - he might have more up-to-date information. Also
>> you might want to setup a serial console to capture the kernel to see
>> where it crashes.
>>
>
> Sorry - we ended up needing to abandon using the closed source driver,
> as despite compiling it with IGNORE_XEN_PRESENCE set, I was never able
> to get it to work with the 3.2 linux kernel.
>
> Since we had reasonably good luck with the nouveau drivers, and our
> OpenGL use case is pretty basic - it ended up being sufficient for our
> needs.
>
> I'd have to do some email archeology to see what the specific failure
> was...but it sounds very similar to the problem desribed above.
>
> I apologize that I'm not a lot of help here.
>
> /btg
>
>>>
>>> This only happens in dom0 under XEN, if I run my dom0 by itself then
>>> the nvidia module loads fine.
>>>
>>> >> However there is no MTRR support on XEN so the driver hard crashed my
>>> >> machine (I can't ssh into the box anymore).
>>> >>
>>> >> Moreover, there is problem with the open source driver 'nouveau' for
>>> >> NVIDIA card =A0(also has something to do with PAT layout of XEN) whi=
ch
>>> >> causes memory corruption.
>>> >
>>> > Huh? Can you point me to a bugzilla please? There was a corruption
>>> > issue where you can pass in 'nopat' on the command line.
>>>
>>> Yes, that is the issue I was referring to, I had to pass "nopat" to
>>> GRUB in order
>>> to fix it.
>>
>> Ok, so there is afall back for you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 07 23:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Jun 2012 23: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 1ScmNC-0005aO-St; Thu, 07 Jun 2012 23:44:14 +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 1ScmNC-0005aI-4r
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 23:44:14 +0000
Received: from [193.109.254.147:25865] by server-9.bemta-14.messagelabs.com id
	C9/AE-27072-DCC31DF4; Thu, 07 Jun 2012 23:44:13 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339112651!8736136!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18148 invoked from network); 7 Jun 2012 23:44:11 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 23:44:11 -0000
Received: by lahg1 with SMTP id g1so1078209lah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 16:44:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=HFXvOr4cZulLynwRmZ2CAMIW3ZJH9BAvhsf6eqO/b/g=;
	b=t7jiogzjZ9HwYv1VkX9qC4W2Ah/tv9ROFaoQqenJrisW2+uyDw15BhYZigFMLQkTAT
	Zy07ADE/pMiGkYwRDIK4vbuUil5LHtz39x8p7M/nmIUS1lYyLiAF7BKL96/nESZDZ/ZR
	ewneu4CMJ6I/DQ7p+MU0xuwVzvtiEsWNPlSU2Iy6Kz1cfV94AlCsnYSimWX9T7GLX42x
	8NlnlzTKM0l+zlQe0M+JsVLbQqIUFwItiur9Cy25vRqP895OJfh/a4KbWsNLvz4oTdGk
	2QOGCNt+c1ylSFCChaksfzNJBmUDi653515xPTGnWeeUBP/ocVtwXu5nz6djI3cr2oGD
	nONg==
MIME-Version: 1.0
Received: by 10.152.102.234 with SMTP id fr10mr4834895lab.32.1339112651089;
	Thu, 07 Jun 2012 16:44:11 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Thu, 7 Jun 2012 16:44:11 -0700 (PDT)
In-Reply-To: <CAOvdn6Up2tvr7r_=hv8GP0EoeXNqu8QWUbgYak89eAoevHN+Hg@mail.gmail.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
	<CAOvdn6Up2tvr7r_=hv8GP0EoeXNqu8QWUbgYak89eAoevHN+Hg@mail.gmail.com>
Date: Thu, 7 Jun 2012 19:44:11 -0400
X-Google-Sender-Auth: megcyFCJALD1C9-OfMwEPo4F-i0
Message-ID: <CAOvdn6WxWFcHLchx-nN8sHyrREC45kA1Vhc6wUE9Yft_hJXZBA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	"aorchis@gmail.com" <aorchis@gmail.com>
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These were the failures I was seeing:

http://www.nvnews.net/vbulletin/showthread.php?t=3D174219

going back through old xen-devel emails, the XID failure looks like it
has been happening for about a year, at least.

I have not tried on kernels newer than 3.2

On Thu, Jun 7, 2012 at 7:39 PM, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Jun 7, 2012 at 11:58 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Thu, Jun 07, 2012 at 08:49:37PM +1000, aorchis@gmail.com wrote:
>>> On Wed, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote:
>>> > On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
>>> >> Hi Jeremy and Konrad,
>>> >
>>> > CC-ing xen-devel.
>>> >
>>> >>
>>> >> Basically the driver NVIDIA provided is a binary blob and recent
>>> >> versions does not work with the PAT layout of XEN so it falls back to
>>> >> MTRR to provide write combining (please correct me if I'm wrong).
>>> >
>>> > OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
>>> > NVidia driver? I've had reports that it works OK.
>>>
>>> I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
>>> I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
>>> (v302) but both didn't work.
>>>
>>> When the nvidia module is loaded, it prints out an error message:
>>> "NVRM: PAT configuration unsupported, falling back to MTRRs."
>>>
>>> When I launch Xorg, the screen turns blank then the monitors powered do=
wn and my
>>> box hard crashed, I had to hold the power button to turn it off.
>>
>> Ok, lets CC Ben - he might have more up-to-date information. Also
>> you might want to setup a serial console to capture the kernel to see
>> where it crashes.
>>
>
> Sorry - we ended up needing to abandon using the closed source driver,
> as despite compiling it with IGNORE_XEN_PRESENCE set, I was never able
> to get it to work with the 3.2 linux kernel.
>
> Since we had reasonably good luck with the nouveau drivers, and our
> OpenGL use case is pretty basic - it ended up being sufficient for our
> needs.
>
> I'd have to do some email archeology to see what the specific failure
> was...but it sounds very similar to the problem desribed above.
>
> I apologize that I'm not a lot of help here.
>
> /btg
>
>>>
>>> This only happens in dom0 under XEN, if I run my dom0 by itself then
>>> the nvidia module loads fine.
>>>
>>> >> However there is no MTRR support on XEN so the driver hard crashed my
>>> >> machine (I can't ssh into the box anymore).
>>> >>
>>> >> Moreover, there is problem with the open source driver 'nouveau' for
>>> >> NVIDIA card =A0(also has something to do with PAT layout of XEN) whi=
ch
>>> >> causes memory corruption.
>>> >
>>> > Huh? Can you point me to a bugzilla please? There was a corruption
>>> > issue where you can pass in 'nopat' on the command line.
>>>
>>> Yes, that is the issue I was referring to, I had to pass "nopat" to
>>> GRUB in order
>>> to fix it.
>>
>> Ok, so there is afall back for you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 00:44:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 00:44: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 1ScnJ6-0006uq-B6; Fri, 08 Jun 2012 00:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScnJ3-0006ul-TE
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 00:44:02 +0000
Received: from [85.158.143.99:19658] by server-3.bemta-4.messagelabs.com id
	A9/77-29237-1DA41DF4; Fri, 08 Jun 2012 00:44:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339116240!25279523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE2NTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8800 invoked from network); 8 Jun 2012 00:44:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 00:44:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,734,1330905600"; d="scan'208";a="12898883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 00:43:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 01:43:58 +0100
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 1ScnIz-0003u6-Qz;
	Fri, 08 Jun 2012 00:43:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScnIz-0004Uc-Ia;
	Fri, 08 Jun 2012 01:43:57 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13024-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Jun 2012 01:43:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13024: 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 13024 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13024/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13023

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  32034d1914a6
baseline version:
 xen                  f6bfaf9daa50

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=32034d1914a6
+ . 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 32034d1914a6
+ branch=xen-unstable
+ revision=32034d1914a6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 32034d1914a6 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 8 changesets with 11 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 Fri Jun 08 00:44:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 00:44: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 1ScnJ6-0006uq-B6; Fri, 08 Jun 2012 00:44:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ScnJ3-0006ul-TE
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 00:44:02 +0000
Received: from [85.158.143.99:19658] by server-3.bemta-4.messagelabs.com id
	A9/77-29237-1DA41DF4; Fri, 08 Jun 2012 00:44:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339116240!25279523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE2NTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8800 invoked from network); 8 Jun 2012 00:44:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 00:44:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,734,1330905600"; d="scan'208";a="12898883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 00:43:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 01:43:58 +0100
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 1ScnIz-0003u6-Qz;
	Fri, 08 Jun 2012 00:43:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScnIz-0004Uc-Ia;
	Fri, 08 Jun 2012 01:43:57 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13024-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Jun 2012 01:43:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13024: 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 13024 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13024/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13023

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  32034d1914a6
baseline version:
 xen                  f6bfaf9daa50

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=32034d1914a6
+ . 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 32034d1914a6
+ branch=xen-unstable
+ revision=32034d1914a6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 32034d1914a6 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 8 changesets with 11 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 Fri Jun 08 06:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 06:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScsUq-00073V-9s; Fri, 08 Jun 2012 06:16: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 1ScsUo-00073Q-7Z
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 06:16:30 +0000
Received: from [193.109.254.147:12351] by server-4.bemta-14.messagelabs.com id
	3A/0E-27598-DB891DF4; Fri, 08 Jun 2012 06:16:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339136138!1827893!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE2NTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21747 invoked from network); 8 Jun 2012 06:15:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 06:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,734,1330905600"; d="scan'208";a="12900811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 06:15:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 07:15:37 +0100
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 1ScsTx-0005f3-CD;
	Fri, 08 Jun 2012 06:15:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScsTw-0000W7-B4;
	Fri, 08 Jun 2012 07:15:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13025-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Jun 2012 07:15:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13025: 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 13025 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13025/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 13024

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13024

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  32034d1914a6
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 06:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 06:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScsUq-00073V-9s; Fri, 08 Jun 2012 06:16: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 1ScsUo-00073Q-7Z
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 06:16:30 +0000
Received: from [193.109.254.147:12351] by server-4.bemta-14.messagelabs.com id
	3A/0E-27598-DB891DF4; Fri, 08 Jun 2012 06:16:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339136138!1827893!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE2NTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21747 invoked from network); 8 Jun 2012 06:15:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 06:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,734,1330905600"; d="scan'208";a="12900811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 06:15:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 07:15:37 +0100
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 1ScsTx-0005f3-CD;
	Fri, 08 Jun 2012 06:15:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ScsTw-0000W7-B4;
	Fri, 08 Jun 2012 07:15:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13025-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Jun 2012 07:15:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13025: 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 13025 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13025/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 13024

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13024

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  32034d1914a6
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 07:13:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 07:13: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 1SctNJ-0007rT-6F; Fri, 08 Jun 2012 07:12: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 1SctNH-0007rN-7U
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 07:12:47 +0000
Received: from [85.158.138.51:11186] by server-3.bemta-3.messagelabs.com id
	AD/6E-25608-EE5A1DF4; Fri, 08 Jun 2012 07:12:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339139564!28529085!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1034 invoked from network); 8 Jun 2012 07:12:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 07:12:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 08:12:44 +0100
Message-Id: <4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 08:12:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
In-Reply-To: <20120607215942.GA13592@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.06.12 at 23:59, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -141,14 +141,33 @@ static int get_id_from_freelist(struct blkfront_info 
> *info)
>  	return free;
>  }
>  
> -static void add_id_to_freelist(struct blkfront_info *info,
> +static int add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	if (info->shadow[id].req.u.rw.id != id)
> +		return -EINVAL;
> +	if (info->shadow[id].request == NULL)
> +		return -EINVAL;
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
> +	return 0;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	static const char *names[] = {

Could/should really be "static const char *const names[]".

> +		[BLKIF_OP_READ] = "read",
> +		[BLKIF_OP_WRITE] = "write",
> +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> +		[BLKIF_OP_RESERVED_1] = "reserved",
> +		[BLKIF_OP_DISCARD] = "discard" };
> +
> +	if (op < 0 || op >= ARRAY_SIZE(names))
> +		return "unknown";
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -744,20 +763,31 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE)
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			goto err_out;

Getting out of the loop here isn't really what I'd call "limp along" -
it'd likely get the communication to a halt (if there are more
responses ready). I'd rather see this print something, and then
continue the loop. Or alternatively, if we really want to stop
communication in such a case, initiate tear down of the device.

> +
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
>  			blkif_completion(&info->shadow[id]);
>  
> -		add_id_to_freelist(info, id);
> +		if (add_id_to_freelist(info, id))
> +			goto err_out;

Same here, obviously.

>  
>  		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
>  		switch (bret->operation) {
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -769,18 +799,14 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> @@ -813,12 +839,18 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  			goto again;
>  	} else
>  		info->ring.sring->rsp_event = i + 1;
> -
>  	kick_pending_request_queues(info);
>  
>  	spin_unlock_irqrestore(&blkif_io_lock, flags);
>  
>  	return IRQ_HANDLED;
> +err_out:
> +	WARN(1, "%s: response to %s has incorrect id\n",
> +	     info->gd->disk_name, op_name(bret->operation));
> +
> +	spin_unlock_irqrestore(&info->io_lock, flags);
> +
> +	return IRQ_HANDLED;
>  }
>  
>  
> diff --git a/include/xen/interface/io/blkif.h 
> b/include/xen/interface/io/blkif.h
> index ee338bf..bc75c75 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -59,6 +59,12 @@ typedef uint64_t blkif_sector_t;
>  #define BLKIF_OP_FLUSH_DISKCACHE   3
>  
>  /*
> + * Used in SLES sources for device specific command packet
> + * contained within the request. Reserved for that purpose.
> + */
> +#define BLKIF_OP_RESERVED_1        4

If you really want to give this a numeric tag, wouldn't it be better
to make this _4? But maybe you could leave out the definition here
altogether, and leave the corresponding names[] slot set to NULL?

Jan

> +
> +/*
>   * Recognised only if "feature-discard" is present in backend xenbus info.
>   * The "feature-discard" node contains a boolean indicating whether trim
>   * (ATA) or unmap (SCSI) - conviently called discard requests are likely
> -- 
> 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 Fri Jun 08 07:13:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 07:13: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 1SctNJ-0007rT-6F; Fri, 08 Jun 2012 07:12: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 1SctNH-0007rN-7U
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 07:12:47 +0000
Received: from [85.158.138.51:11186] by server-3.bemta-3.messagelabs.com id
	AD/6E-25608-EE5A1DF4; Fri, 08 Jun 2012 07:12:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339139564!28529085!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1034 invoked from network); 8 Jun 2012 07:12:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 07:12:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 08:12:44 +0100
Message-Id: <4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 08:12:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
In-Reply-To: <20120607215942.GA13592@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.06.12 at 23:59, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -141,14 +141,33 @@ static int get_id_from_freelist(struct blkfront_info 
> *info)
>  	return free;
>  }
>  
> -static void add_id_to_freelist(struct blkfront_info *info,
> +static int add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	if (info->shadow[id].req.u.rw.id != id)
> +		return -EINVAL;
> +	if (info->shadow[id].request == NULL)
> +		return -EINVAL;
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
> +	return 0;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	static const char *names[] = {

Could/should really be "static const char *const names[]".

> +		[BLKIF_OP_READ] = "read",
> +		[BLKIF_OP_WRITE] = "write",
> +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> +		[BLKIF_OP_RESERVED_1] = "reserved",
> +		[BLKIF_OP_DISCARD] = "discard" };
> +
> +	if (op < 0 || op >= ARRAY_SIZE(names))
> +		return "unknown";
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -744,20 +763,31 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE)
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			goto err_out;

Getting out of the loop here isn't really what I'd call "limp along" -
it'd likely get the communication to a halt (if there are more
responses ready). I'd rather see this print something, and then
continue the loop. Or alternatively, if we really want to stop
communication in such a case, initiate tear down of the device.

> +
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
>  			blkif_completion(&info->shadow[id]);
>  
> -		add_id_to_freelist(info, id);
> +		if (add_id_to_freelist(info, id))
> +			goto err_out;

Same here, obviously.

>  
>  		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
>  		switch (bret->operation) {
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -769,18 +799,14 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> @@ -813,12 +839,18 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  			goto again;
>  	} else
>  		info->ring.sring->rsp_event = i + 1;
> -
>  	kick_pending_request_queues(info);
>  
>  	spin_unlock_irqrestore(&blkif_io_lock, flags);
>  
>  	return IRQ_HANDLED;
> +err_out:
> +	WARN(1, "%s: response to %s has incorrect id\n",
> +	     info->gd->disk_name, op_name(bret->operation));
> +
> +	spin_unlock_irqrestore(&info->io_lock, flags);
> +
> +	return IRQ_HANDLED;
>  }
>  
>  
> diff --git a/include/xen/interface/io/blkif.h 
> b/include/xen/interface/io/blkif.h
> index ee338bf..bc75c75 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -59,6 +59,12 @@ typedef uint64_t blkif_sector_t;
>  #define BLKIF_OP_FLUSH_DISKCACHE   3
>  
>  /*
> + * Used in SLES sources for device specific command packet
> + * contained within the request. Reserved for that purpose.
> + */
> +#define BLKIF_OP_RESERVED_1        4

If you really want to give this a numeric tag, wouldn't it be better
to make this _4? But maybe you could leave out the definition here
altogether, and leave the corresponding names[] slot set to NULL?

Jan

> +
> +/*
>   * Recognised only if "feature-discard" is present in backend xenbus info.
>   * The "feature-discard" node contains a boolean indicating whether trim
>   * (ATA) or unmap (SCSI) - conviently called discard requests are likely
> -- 
> 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 Fri Jun 08 07:52:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 07:52: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 1Sctyq-0008QP-1o; Fri, 08 Jun 2012 07:51:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Sctyn-0008QI-Sv
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 07:51:34 +0000
Received: from [85.158.138.51:19867] by server-10.bemta-3.messagelabs.com id
	8A/99-06494-40FA1DF4; Fri, 08 Jun 2012 07:51:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339141891!31448824!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6158 invoked from network); 8 Jun 2012 07:51:32 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 07:51:32 -0000
Received: by eekd41 with SMTP id d41so1006744eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 00:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Jn7WhfZy2fkGXkm/hNuFbe2pRJw2ioSTS3Ck92/WGZQ=;
	b=IYlvs7hqyPOFpBMQFYMrVKV4e+XUdyK+Qx0Wusdll6X9B5FiYsZ1+QPgES4WCQmN5G
	BX6nyvyZ8bCAzyvhkUuzAM+TQnlbGAvfX4Y/KC7fZJMhqnTZkzWAiMybZcry3TYlxdOo
	7xKOZJUXZCetTHwBA0CFXUToS+qpxURDGBY2Vx7xDrVzy/yIe5NGmGaksl2edaeAk42W
	VwuSLpv/SLEjz3xph6gmKroUlV9SJisRi/ff2l2z0hcKrz0e8pyKeR9gGVXHpYgdxzsj
	EN92PafasxeZIHlrW+x8yAkXuYxF9TfO9j6SznNTw3HQNdSFPKRGsU0FF/4rrdrAlf5f
	FbeA==
Received: by 10.14.187.11 with SMTP id x11mr3346743eem.57.1339141877607;
	Fri, 08 Jun 2012 00:51:17 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-18-132.range81-152.btcentralplus.com.
	[81.152.18.132])
	by mx.google.com with ESMTPS id t3sm19151304eeb.15.2012.06.08.00.51.15
	(version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 00:51:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 08 Jun 2012 08:51:08 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <CBF76D7C.35992%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] fix page_list_splice()
Thread-Index: Ac1FS3a0R9qsSdhHVUOnojMBMgdb2w==
In-Reply-To: <4FD10AC60200007800085AEE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: jisooy@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 20:10, "Jan Beulich" <jbeulich@suse.com> wrote:

>> I mean to replace the comment with a second assertion, not to replace the
>> assertion your patch already adds. Does that make sense?
> 
> From the perspective of the operation here, we really just want to make
> sure that the new list head's prev points to where the old one's pointed;
> the fact that they're both supposed to be PAGE_LIST_NULL doesn't really
> matter. Hence simply asserting that the assignment is superfluous seems
> the best choice to me, with the comment explaining why. If you have
> suggestions for better wording of the comment, I'll gladly take those.
> 
> The second best choice imo would be to just have the superfluous
> assignment there (making it likely that later someone will come and
> ask why it's there when not really needed).

Well, I already did check in a version with two assertions, yesterday. :) I
like assertions, and asserting things about the good form of the data
structure being manipulated, even if that good form is not essential to this
specific operation, is not necessarily bad. Especially while we're already
asserting other things about those same list pointers.

It's not a major point here of course, it just seemed silly to to me to take
up a source line with a comment which could be stated just as clearly with
an assertion, and with added benefit (imo).

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 07:52:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 07:52: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 1Sctyq-0008QP-1o; Fri, 08 Jun 2012 07:51:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Sctyn-0008QI-Sv
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 07:51:34 +0000
Received: from [85.158.138.51:19867] by server-10.bemta-3.messagelabs.com id
	8A/99-06494-40FA1DF4; Fri, 08 Jun 2012 07:51:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339141891!31448824!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6158 invoked from network); 8 Jun 2012 07:51:32 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 07:51:32 -0000
Received: by eekd41 with SMTP id d41so1006744eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 00:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Jn7WhfZy2fkGXkm/hNuFbe2pRJw2ioSTS3Ck92/WGZQ=;
	b=IYlvs7hqyPOFpBMQFYMrVKV4e+XUdyK+Qx0Wusdll6X9B5FiYsZ1+QPgES4WCQmN5G
	BX6nyvyZ8bCAzyvhkUuzAM+TQnlbGAvfX4Y/KC7fZJMhqnTZkzWAiMybZcry3TYlxdOo
	7xKOZJUXZCetTHwBA0CFXUToS+qpxURDGBY2Vx7xDrVzy/yIe5NGmGaksl2edaeAk42W
	VwuSLpv/SLEjz3xph6gmKroUlV9SJisRi/ff2l2z0hcKrz0e8pyKeR9gGVXHpYgdxzsj
	EN92PafasxeZIHlrW+x8yAkXuYxF9TfO9j6SznNTw3HQNdSFPKRGsU0FF/4rrdrAlf5f
	FbeA==
Received: by 10.14.187.11 with SMTP id x11mr3346743eem.57.1339141877607;
	Fri, 08 Jun 2012 00:51:17 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-18-132.range81-152.btcentralplus.com.
	[81.152.18.132])
	by mx.google.com with ESMTPS id t3sm19151304eeb.15.2012.06.08.00.51.15
	(version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 00:51:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 08 Jun 2012 08:51:08 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <CBF76D7C.35992%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] fix page_list_splice()
Thread-Index: Ac1FS3a0R9qsSdhHVUOnojMBMgdb2w==
In-Reply-To: <4FD10AC60200007800085AEE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: jisooy@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] fix page_list_splice()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 20:10, "Jan Beulich" <jbeulich@suse.com> wrote:

>> I mean to replace the comment with a second assertion, not to replace the
>> assertion your patch already adds. Does that make sense?
> 
> From the perspective of the operation here, we really just want to make
> sure that the new list head's prev points to where the old one's pointed;
> the fact that they're both supposed to be PAGE_LIST_NULL doesn't really
> matter. Hence simply asserting that the assignment is superfluous seems
> the best choice to me, with the comment explaining why. If you have
> suggestions for better wording of the comment, I'll gladly take those.
> 
> The second best choice imo would be to just have the superfluous
> assignment there (making it likely that later someone will come and
> ask why it's there when not really needed).

Well, I already did check in a version with two assertions, yesterday. :) I
like assertions, and asserting things about the good form of the data
structure being manipulated, even if that good form is not essential to this
specific operation, is not necessarily bad. Especially while we're already
asserting other things about those same list pointers.

It's not a major point here of course, it just seemed silly to to me to take
up a source line with a comment which could be stated just as clearly with
an assertion, and with added benefit (imo).

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 08:04:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 08:04:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScuAb-0000rY-M1; Fri, 08 Jun 2012 08:03:45 +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 1ScuAa-0000rT-9B
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 08:03:44 +0000
Received: from [85.158.143.35:15839] by server-2.bemta-4.messagelabs.com id
	84/23-17938-FD1B1DF4; Fri, 08 Jun 2012 08:03:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339142622!15361557!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5964 invoked from network); 8 Jun 2012 08:03:42 -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; 8 Jun 2012 08:03:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 08:43:20 +0100
Message-Id: <4FD1C9370200007800088AD8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 08:43:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Moskalenko" <mav@elserv.ru>
References: <4FD0747D.10103@elserv.ru>
In-Reply-To: <4FD0747D.10103@elserv.ru>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:29, Alex Moskalenko <mav@elserv.ru> wrote:
> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on 
> IBM eServer x3400. Without noacpi command line option dom0 kernel 
> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen 
> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor 
> all kernels run without any problems.

This is an issue that was reported and discussed previously.
Fundamentally, it is a firmware problem from my pov: ACPI has
_nothing_ to do with the MMIO space used for the IO-APICs of
the system once they are under control of the OS. It shouldn't
even be reading from them (which iirc was the case in earlier
reports), but in your case it looks like it's even writing them. I
had been considering to allow Dom0 read access to those pages,
but obviously this wouldn't help in your case.

Could you extract and supply the ACPI tables of that system, so
we can make an attempt at checking whether there is some reason
for the firmware writing to the IO-APIC that we didn't think of so
far?

> There are several patches (available on 
> http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=short 
> log;h=refs/heads/kernel-image-xen-dom0, 
> commits f1f91babc9cc9402ccee8938b888240f5bae1574, 
> 72db7b5e069002765ced64f030c1117d72352331, 
> adc4c567a08d4d2377060179639cbfdc3d9d8e0e and 
> 9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32 to 
> boot on this hardware. This patches written by kernel package maintainer 

While they could make an attempt at upstreaming them, I don't
think the way this is being dealt with (altering the set_pte() and
set_pte_at() return types) would be well received. (The Xen-
specific adjustments look bogus altogether, btw.)

> of ALT Linux distribution. Discussion of this issue is available on 
> Sysadmins ALTLinux mailing list 
> (http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html 
> and follows) in Russian.

But there's no real analysis of the underlying problem there.
Perhaps the author of the patches should have turned here?

(As a side note - non-pvops Xen wouldn't have this problem, as
the hypercalls underlying ioremap() get properly error-checked
there, and result in the ioremap() failing rather than a #PF
getting raised.)

Jan

> I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need this 
> messages for more recent versions of Xen and kernel, or more information 
> about hardware, please let me know.
> 
> Ideally, I would like to run current versions of Xen and Linux kernels 
> on this hardware. Can you help me please?
> 
> 
> --
>   WBR, Alex Moskalenko




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 08:04:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 08:04:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScuAb-0000rY-M1; Fri, 08 Jun 2012 08:03:45 +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 1ScuAa-0000rT-9B
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 08:03:44 +0000
Received: from [85.158.143.35:15839] by server-2.bemta-4.messagelabs.com id
	84/23-17938-FD1B1DF4; Fri, 08 Jun 2012 08:03:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339142622!15361557!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5964 invoked from network); 8 Jun 2012 08:03:42 -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; 8 Jun 2012 08:03:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 08:43:20 +0100
Message-Id: <4FD1C9370200007800088AD8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 08:43:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Moskalenko" <mav@elserv.ru>
References: <4FD0747D.10103@elserv.ru>
In-Reply-To: <4FD0747D.10103@elserv.ru>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:29, Alex Moskalenko <mav@elserv.ru> wrote:
> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on 
> IBM eServer x3400. Without noacpi command line option dom0 kernel 
> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen 
> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor 
> all kernels run without any problems.

This is an issue that was reported and discussed previously.
Fundamentally, it is a firmware problem from my pov: ACPI has
_nothing_ to do with the MMIO space used for the IO-APICs of
the system once they are under control of the OS. It shouldn't
even be reading from them (which iirc was the case in earlier
reports), but in your case it looks like it's even writing them. I
had been considering to allow Dom0 read access to those pages,
but obviously this wouldn't help in your case.

Could you extract and supply the ACPI tables of that system, so
we can make an attempt at checking whether there is some reason
for the firmware writing to the IO-APIC that we didn't think of so
far?

> There are several patches (available on 
> http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=short 
> log;h=refs/heads/kernel-image-xen-dom0, 
> commits f1f91babc9cc9402ccee8938b888240f5bae1574, 
> 72db7b5e069002765ced64f030c1117d72352331, 
> adc4c567a08d4d2377060179639cbfdc3d9d8e0e and 
> 9beeac5589ce5c415e4513016c78e96374b8a895) that allow kernel 2.6.32 to 
> boot on this hardware. This patches written by kernel package maintainer 

While they could make an attempt at upstreaming them, I don't
think the way this is being dealt with (altering the set_pte() and
set_pte_at() return types) would be well received. (The Xen-
specific adjustments look bogus altogether, btw.)

> of ALT Linux distribution. Discussion of this issue is available on 
> Sysadmins ALTLinux mailing list 
> (http://lists.altlinux.org/pipermail/sysadmins/2011-April/034471.html 
> and follows) in Russian.

But there's no real analysis of the underlying problem there.
Perhaps the author of the patches should have turned here?

(As a side note - non-pvops Xen wouldn't have this problem, as
the hypercalls underlying ioremap() get properly error-checked
there, and result in the ioremap() failing rather than a #PF
getting raised.)

Jan

> I attached Xen 4.1.0 with kernel 2.6.32 crash messages. If you need this 
> messages for more recent versions of Xen and kernel, or more information 
> about hardware, please let me know.
> 
> Ideally, I would like to run current versions of Xen and Linux kernels 
> on this hardware. Can you help me please?
> 
> 
> --
>   WBR, Alex Moskalenko




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 08:58:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 08: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 1Scv1O-0001FD-3J; Fri, 08 Jun 2012 08:58:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Scv1N-0001F8-0g
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 08:58:17 +0000
Received: from [85.158.143.99:48846] by server-1.bemta-4.messagelabs.com id
	0B/2A-10042-8AEB1DF4; Fri, 08 Jun 2012 08:58:16 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339145895!20686459!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 8 Jun 2012 08:58:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-216.messagelabs.com with SMTP;
	8 Jun 2012 08:58:15 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78741684; Fri, 08 Jun 2012 10:58:14 +0200
Message-ID: <1339145879.5003.0.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 10:57:59 +0200
In-Reply-To: <20432.55756.587767.208290@mariner.uk.xensource.com>
References: <patchbomb.1339076551@Solace>
	<93ff3e5ecdee68b4f949.1339076552@Solace>
	<20432.55756.587767.208290@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v2] libxl: propagete down the error
 from libxl_domain_sched_params_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: multipart/mixed; boundary="===============7556366922351361540=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7556366922351361540==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-KKXsnM9DjNPx8jFX5nuK"


--=-KKXsnM9DjNPx8jFX5nuK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-07 at 17:41 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 1 of 2 v2] libxl: propagete down the error=
 from libxl_domain_sched_params_set"):
> > So that the caller (e.g., libxl__build_post() ) knows and can deal with=
 it.
> ...
> > -    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
> > +    if (libxl_domain_sched_params_set(CTX, domid, &info->sched_params)=
)
> > +        return ERROR_INVAL;
>=20
> This is not correct.  It should return whatever error code
> libxl_domain_sched_params_set returns, not unconditionally
> ERROR_INVAL.
>=20
Ops, you're right, sorry... New version coming!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-KKXsnM9DjNPx8jFX5nuK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/RvpcACgkQk4XaBE3IOsTxbgCeNWvVYVVt5KhfDIgtxdWLmJSG
pAsAnijzkRdmf7qxO//p5GcD1pfLWk96
=SpXv
-----END PGP SIGNATURE-----

--=-KKXsnM9DjNPx8jFX5nuK--



--===============7556366922351361540==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7556366922351361540==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 08:58:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 08: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 1Scv1O-0001FD-3J; Fri, 08 Jun 2012 08:58:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Scv1N-0001F8-0g
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 08:58:17 +0000
Received: from [85.158.143.99:48846] by server-1.bemta-4.messagelabs.com id
	0B/2A-10042-8AEB1DF4; Fri, 08 Jun 2012 08:58:16 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339145895!20686459!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 8 Jun 2012 08:58:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-216.messagelabs.com with SMTP;
	8 Jun 2012 08:58:15 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78741684; Fri, 08 Jun 2012 10:58:14 +0200
Message-ID: <1339145879.5003.0.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 10:57:59 +0200
In-Reply-To: <20432.55756.587767.208290@mariner.uk.xensource.com>
References: <patchbomb.1339076551@Solace>
	<93ff3e5ecdee68b4f949.1339076552@Solace>
	<20432.55756.587767.208290@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v2] libxl: propagete down the error
 from libxl_domain_sched_params_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: multipart/mixed; boundary="===============7556366922351361540=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7556366922351361540==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-KKXsnM9DjNPx8jFX5nuK"


--=-KKXsnM9DjNPx8jFX5nuK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-07 at 17:41 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 1 of 2 v2] libxl: propagete down the error=
 from libxl_domain_sched_params_set"):
> > So that the caller (e.g., libxl__build_post() ) knows and can deal with=
 it.
> ...
> > -    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
> > +    if (libxl_domain_sched_params_set(CTX, domid, &info->sched_params)=
)
> > +        return ERROR_INVAL;
>=20
> This is not correct.  It should return whatever error code
> libxl_domain_sched_params_set returns, not unconditionally
> ERROR_INVAL.
>=20
Ops, you're right, sorry... New version coming!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-KKXsnM9DjNPx8jFX5nuK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/RvpcACgkQk4XaBE3IOsTxbgCeNWvVYVVt5KhfDIgtxdWLmJSG
pAsAnijzkRdmf7qxO//p5GcD1pfLWk96
=SpXv
-----END PGP SIGNATURE-----

--=-KKXsnM9DjNPx8jFX5nuK--



--===============7556366922351361540==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7556366922351361540==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 09:10:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09: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 1ScvCG-0001Zn-90; Fri, 08 Jun 2012 09:09:32 +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 1ScvCE-0001Zi-Ah
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 09:09:30 +0000
Received: from [193.109.254.147:31760] by server-12.bemta-14.messagelabs.com
	id DD/A9-12998-941C1DF4; Fri, 08 Jun 2012 09:09:29 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339146548!8583573!3
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15487 invoked from network); 8 Jun 2012 09:09:14 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 09:09:14 -0000
Received: by mail-ee0-f45.google.com with SMTP id d41so1099383eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 02:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=tSukAjm1YZ10l3WGIL04wrVi7STs9m/4fPYNeGmRJJ8=;
	b=FZ7bRHxdJHyxtPNYuyjjic3tDn6a5BFesAQekGdoRkwAwBKF3u7uNVHJGu08dUWclz
	och0toccN4U1niRe13srImCyoWwKnYTbDxY4/zlVLz5kQB7TnqzzCN7dcB7K+kZScCi6
	E5zkjFM8VS47KViPH74wMbn7qLrgNelFPGo2swDBvGZGejvNBma3rjiQONPNyudXrtZQ
	TYz8DzyhdbkZsj+ki8AtpDpjwxAeLDiaNBUlYc3lcTag3nVB4WH7itqMuOR61tKA2pKB
	c4vEu2PKNoESdL4LXX3zy9gdfxrqViBpOE7fijzHWVJvPuzTmR9fmoekduKTBIDiWuGV
	FXjQ==
Received: by 10.14.119.205 with SMTP id n53mr3559498eeh.128.1339146553986;
	Fri, 08 Jun 2012 02:09:13 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id bn9sm75542wib.5.2012.06.08.02.09.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 08 Jun 2012 02:09:12 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e0c4a09877d727255103191ad1731b5d51dade29
Message-Id: <e0c4a09877d727255103.1339146489@Solace>
In-Reply-To: <patchbomb.1339146487@Solace>
References: <patchbomb.1339146487@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 08 Jun 2012 11:08:09 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful combination
 of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it happens in the implementation of `xl sched-sedf -d ...', some
consistency checking is needed for the scheduling parameters when
they come from the config file.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -550,6 +550,31 @@ vcpp_out:
     return rc;
 }
 
+static int sched_params_valid(libxl_domain_sched_params *scp)
+{
+    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
+    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
+    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    libxl_domain_sched_params sci;
+
+    libxl_domain_sched_params_get(ctx, domid, &sci);
+
+    /* The sedf scheduler needs some more consistency checking */
+    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+        if (has_weight && (has_period || has_slice))
+            return 0;
+
+        if (has_weight) {
+            scp->slice = 0;
+            scp->period = 0;
+        }
+        if (has_period || has_slice)
+            scp->weight = 0;
+    }
+
+    return 1;
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -644,6 +669,10 @@ static void parse_config_data(const char
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
+    if (!sched_params_valid(&b_info->sched_params)) {
+        fprintf(stderr, "Invalid scheduling parameters\n");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 09:10:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09: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 1ScvCG-0001Zn-90; Fri, 08 Jun 2012 09:09:32 +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 1ScvCE-0001Zi-Ah
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 09:09:30 +0000
Received: from [193.109.254.147:31760] by server-12.bemta-14.messagelabs.com
	id DD/A9-12998-941C1DF4; Fri, 08 Jun 2012 09:09:29 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339146548!8583573!3
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15487 invoked from network); 8 Jun 2012 09:09:14 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 09:09:14 -0000
Received: by mail-ee0-f45.google.com with SMTP id d41so1099383eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 02:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=tSukAjm1YZ10l3WGIL04wrVi7STs9m/4fPYNeGmRJJ8=;
	b=FZ7bRHxdJHyxtPNYuyjjic3tDn6a5BFesAQekGdoRkwAwBKF3u7uNVHJGu08dUWclz
	och0toccN4U1niRe13srImCyoWwKnYTbDxY4/zlVLz5kQB7TnqzzCN7dcB7K+kZScCi6
	E5zkjFM8VS47KViPH74wMbn7qLrgNelFPGo2swDBvGZGejvNBma3rjiQONPNyudXrtZQ
	TYz8DzyhdbkZsj+ki8AtpDpjwxAeLDiaNBUlYc3lcTag3nVB4WH7itqMuOR61tKA2pKB
	c4vEu2PKNoESdL4LXX3zy9gdfxrqViBpOE7fijzHWVJvPuzTmR9fmoekduKTBIDiWuGV
	FXjQ==
Received: by 10.14.119.205 with SMTP id n53mr3559498eeh.128.1339146553986;
	Fri, 08 Jun 2012 02:09:13 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id bn9sm75542wib.5.2012.06.08.02.09.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 08 Jun 2012 02:09:12 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e0c4a09877d727255103191ad1731b5d51dade29
Message-Id: <e0c4a09877d727255103.1339146489@Solace>
In-Reply-To: <patchbomb.1339146487@Solace>
References: <patchbomb.1339146487@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 08 Jun 2012 11:08:09 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful combination
 of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it happens in the implementation of `xl sched-sedf -d ...', some
consistency checking is needed for the scheduling parameters when
they come from the config file.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -550,6 +550,31 @@ vcpp_out:
     return rc;
 }
 
+static int sched_params_valid(libxl_domain_sched_params *scp)
+{
+    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
+    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
+    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    libxl_domain_sched_params sci;
+
+    libxl_domain_sched_params_get(ctx, domid, &sci);
+
+    /* The sedf scheduler needs some more consistency checking */
+    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+        if (has_weight && (has_period || has_slice))
+            return 0;
+
+        if (has_weight) {
+            scp->slice = 0;
+            scp->period = 0;
+        }
+        if (has_period || has_slice)
+            scp->weight = 0;
+    }
+
+    return 1;
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -644,6 +669,10 @@ static void parse_config_data(const char
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
+    if (!sched_params_valid(&b_info->sched_params)) {
+        fprintf(stderr, "Invalid scheduling parameters\n");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 09:10:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09: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 1ScvCM-0001aA-L3; Fri, 08 Jun 2012 09:09:38 +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 1ScvCK-0001a0-SB
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 09:09:37 +0000
Received: from [193.109.254.147:2349] by server-6.bemta-14.messagelabs.com id
	EF/7B-02426-051C1DF4; Fri, 08 Jun 2012 09:09:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339146548!8583573!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14979 invoked from network); 8 Jun 2012 09:09:08 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 09:09:08 -0000
Received: by eekd41 with SMTP id d41so1099383eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 02:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=m0OifCgMz2zGh2TwyDmJg4zot0nZKoMkq5vLprgXhEA=;
	b=sSpIbaibMaEebUQ/6Q20ashR0Vdwat8WzlcXoAKDE7GNrhMAfxXXNNzDlhAfYiTCY4
	tkIjD3kXuOPFOvYn5cn6ZB0gg6AfLVz1VBEYpZNIaDVnwokrTM9fDOMt9MkX2aAR7jlE
	jJ7zMALPflGQ3NJIBw/X0fwVCXFHf5++eJwqKRdUKIBjFOrnTwgiEmEnI4lj3wH8iY6e
	mpcqmz6nndY2UQcFrf8tVAH9ev2rvVim65dioysWqtGPp0OagJa+It7MtQqKoO7Q4LCS
	tB3AZe8onaJYpJ7GCrwn/WiZ/f/fQaj4H39hoJpYZcq9hR7RHUGPpZvk5SP/IR/uBLOR
	aYQg==
Received: by 10.14.97.131 with SMTP id t3mr3138082eef.196.1339146548329;
	Fri, 08 Jun 2012 02:09:08 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id bn9sm75542wib.5.2012.06.08.02.09.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 08 Jun 2012 02:09:07 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1339146487@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 08 Jun 2012 11:08:07 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 2 v3] Sanity checking of scheduling
	parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This small series achieves two goals:
 - check the return value of libxl_domain_sched_params_set() in
   libxl__build_post() and deal with the error, if that is the
   case (patch #1);
 - check and ensue we are passing along a meaningful set of sedf
   scheduling parameters when they come directly from the config file
   (patch #2)

Tested on both credit and sedf schedulers.

Changes from v2:
 * actually propagate the error correctly instead of always returning
   INVAL (in patch #1).

Changes from v1:
 * patch #1: it was not there at all in v1! :-P
 * patch #2: the if-s have been moved into an helper function. Also,
   they only happen if the domain is actually being scheduled with
   sedf (IanC, yes, I decided to do it... At the end of the day, it is
   simple enough I think).


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 Jun 08 09:10:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09: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 1ScvCM-0001aA-L3; Fri, 08 Jun 2012 09:09:38 +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 1ScvCK-0001a0-SB
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 09:09:37 +0000
Received: from [193.109.254.147:2349] by server-6.bemta-14.messagelabs.com id
	EF/7B-02426-051C1DF4; Fri, 08 Jun 2012 09:09:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339146548!8583573!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14979 invoked from network); 8 Jun 2012 09:09:08 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 09:09:08 -0000
Received: by eekd41 with SMTP id d41so1099383eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 02:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=m0OifCgMz2zGh2TwyDmJg4zot0nZKoMkq5vLprgXhEA=;
	b=sSpIbaibMaEebUQ/6Q20ashR0Vdwat8WzlcXoAKDE7GNrhMAfxXXNNzDlhAfYiTCY4
	tkIjD3kXuOPFOvYn5cn6ZB0gg6AfLVz1VBEYpZNIaDVnwokrTM9fDOMt9MkX2aAR7jlE
	jJ7zMALPflGQ3NJIBw/X0fwVCXFHf5++eJwqKRdUKIBjFOrnTwgiEmEnI4lj3wH8iY6e
	mpcqmz6nndY2UQcFrf8tVAH9ev2rvVim65dioysWqtGPp0OagJa+It7MtQqKoO7Q4LCS
	tB3AZe8onaJYpJ7GCrwn/WiZ/f/fQaj4H39hoJpYZcq9hR7RHUGPpZvk5SP/IR/uBLOR
	aYQg==
Received: by 10.14.97.131 with SMTP id t3mr3138082eef.196.1339146548329;
	Fri, 08 Jun 2012 02:09:08 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id bn9sm75542wib.5.2012.06.08.02.09.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 08 Jun 2012 02:09:07 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1339146487@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 08 Jun 2012 11:08:07 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 2 v3] Sanity checking of scheduling
	parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This small series achieves two goals:
 - check the return value of libxl_domain_sched_params_set() in
   libxl__build_post() and deal with the error, if that is the
   case (patch #1);
 - check and ensue we are passing along a meaningful set of sedf
   scheduling parameters when they come directly from the config file
   (patch #2)

Tested on both credit and sedf schedulers.

Changes from v2:
 * actually propagate the error correctly instead of always returning
   INVAL (in patch #1).

Changes from v1:
 * patch #1: it was not there at all in v1! :-P
 * patch #2: the if-s have been moved into an helper function. Also,
   they only happen if the domain is actually being scheduled with
   sedf (IanC, yes, I decided to do it... At the end of the day, it is
   simple enough I think).


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 Jun 08 09:10:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09:10: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 1ScvCU-0001at-0t; Fri, 08 Jun 2012 09:09:46 +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 1ScvCS-0001ad-DZ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 09:09:44 +0000
Received: from [193.109.254.147:37151] by server-7.bemta-14.messagelabs.com id
	D7/A2-29165-751C1DF4; Fri, 08 Jun 2012 09:09:43 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339146548!8583573!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15273 invoked from network); 8 Jun 2012 09:09:11 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 09:09:11 -0000
Received: by mail-ee0-f45.google.com with SMTP id d41so1099383eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 02:09:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=WvRzw8n64dVtv6+qskvGDtnsrrTLEJMUX2xjwlvDYGE=;
	b=AaThrtsa4XmP4xYKaFOZGRBmnru/aLxgf+JMekYwhzsppG6+uRPF9U+QfgLhyiOWha
	b4QbbKPz+U2pOjUSBmXgagqOu7lT2j1NEorlgqMDcSx3u0Wxws0GhhiI3jYwHbIz7r6U
	GJuJtMDmXEiSo7I+MvD79O08+ks5GBdBBoxB4OFWlFgGQ64aAkeNAHSLxlpFOtwcQX20
	edpmyiMLxEoRJd5gxzaqGwNwEEjSM+gfKcQP21nOCFdiVL4+5dv1iX/JYUHFhRF0lscP
	LTigJLDj7aVFlNQ/WRkAhVhyjBPIglrXpbROi171G+JrQq3YB7mVlnNRO5xGFRyXD2LJ
	gVGw==
Received: by 10.14.95.134 with SMTP id p6mr3178373eef.18.1339146551311;
	Fri, 08 Jun 2012 02:09:11 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id bn9sm75542wib.5.2012.06.08.02.09.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 08 Jun 2012 02:09:09 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 0b8bf8724ee035adf384eee361997be697c445ea
Message-Id: <0b8bf8724ee035adf384.1339146488@Solace>
In-Reply-To: <patchbomb.1339146487@Solace>
References: <patchbomb.1339146487@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 08 Jun 2012 11:08:08 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2 v3] libxl: propagete down the error from
 libxl_domain_sched_params_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

So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
@@ -173,9 +173,11 @@ int libxl__build_post(libxl__gc *gc, uin
     char *dom_path, *vm_path;
     xs_transaction_t t;
     char **ents, **hvm_ents;
-    int i;
+    int i, rc;
 
-    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
+    rc = libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
+    if (rc)
+        return rc;
 
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 09:10:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09:10: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 1ScvCU-0001at-0t; Fri, 08 Jun 2012 09:09:46 +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 1ScvCS-0001ad-DZ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 09:09:44 +0000
Received: from [193.109.254.147:37151] by server-7.bemta-14.messagelabs.com id
	D7/A2-29165-751C1DF4; Fri, 08 Jun 2012 09:09:43 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339146548!8583573!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15273 invoked from network); 8 Jun 2012 09:09:11 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 09:09:11 -0000
Received: by mail-ee0-f45.google.com with SMTP id d41so1099383eek.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 02:09:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=WvRzw8n64dVtv6+qskvGDtnsrrTLEJMUX2xjwlvDYGE=;
	b=AaThrtsa4XmP4xYKaFOZGRBmnru/aLxgf+JMekYwhzsppG6+uRPF9U+QfgLhyiOWha
	b4QbbKPz+U2pOjUSBmXgagqOu7lT2j1NEorlgqMDcSx3u0Wxws0GhhiI3jYwHbIz7r6U
	GJuJtMDmXEiSo7I+MvD79O08+ks5GBdBBoxB4OFWlFgGQ64aAkeNAHSLxlpFOtwcQX20
	edpmyiMLxEoRJd5gxzaqGwNwEEjSM+gfKcQP21nOCFdiVL4+5dv1iX/JYUHFhRF0lscP
	LTigJLDj7aVFlNQ/WRkAhVhyjBPIglrXpbROi171G+JrQq3YB7mVlnNRO5xGFRyXD2LJ
	gVGw==
Received: by 10.14.95.134 with SMTP id p6mr3178373eef.18.1339146551311;
	Fri, 08 Jun 2012 02:09:11 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id bn9sm75542wib.5.2012.06.08.02.09.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 08 Jun 2012 02:09:09 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 0b8bf8724ee035adf384eee361997be697c445ea
Message-Id: <0b8bf8724ee035adf384.1339146488@Solace>
In-Reply-To: <patchbomb.1339146487@Solace>
References: <patchbomb.1339146487@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 08 Jun 2012 11:08:08 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2 v3] libxl: propagete down the error from
 libxl_domain_sched_params_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

So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
@@ -173,9 +173,11 @@ int libxl__build_post(libxl__gc *gc, uin
     char *dom_path, *vm_path;
     xs_transaction_t t;
     char **ents, **hvm_ents;
-    int i;
+    int i, rc;
 
-    libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
+    rc = libxl_domain_sched_params_set(CTX, domid, &info->sched_params);
+    if (rc)
+        return rc;
 
     libxl_cpuid_apply_policy(ctx, domid);
     if (info->cpuid != NULL)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 09:27:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1ScvTa-00020a-Ma; Fri, 08 Jun 2012 09:27:26 +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 1ScvTY-00020S-Vz
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 09:27:25 +0000
Received: from [85.158.143.99:19676] by server-2.bemta-4.messagelabs.com id
	D8/73-17938-C75C1DF4; Fri, 08 Jun 2012 09:27:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339147642!26615156!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk0NzE3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4898 invoked from network); 8 Jun 2012 09:27:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-216.messagelabs.com with SMTP;
	8 Jun 2012 09:27:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 08 Jun 2012 02:27:22 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="153409155"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 08 Jun 2012 02:27:22 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 8 Jun 2012 02:27:22 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Fri, 8 Jun 2012 17:27:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
Thread-Index: AQHNRNHcM9HNPWGJrkGbs3SSikmUqJbwJzvA
Date: Fri, 8 Jun 2012 09:27:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522160D@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120606205523.GA10891@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
	<20120607172039.GR9472@phenom.dumpdata.com>
In-Reply-To: <20120607172039.GR9472@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 07, 2012 at 06:45:39AM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
>>>>> From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00
>>>>> 2001
>>>> From: root <root@ljsromley.bj.intel.com>
>>>> Date: Fri, 1 Jun 2012 03:12:51 +0800
>>>> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
>>>> 
>>>> When MCA error occurs, it would be handled by Xen hypervisor first,
>>>> and then the error information would be sent to initial domain for
>>>> logging. 
>>>> 
>>>> This patch gets error information from Xen hypervisor and convert
>>>> Xen format error into Linux format mcelog. This logic is basically
>>>> self-contained, not touching other kernel components.
>>>> 
>>>> By using tools like mcelog tool users could read specific error
>>>> information, like what they did under native Linux.
>>>> 
>>>> To test follow directions outlined in
>>>> Documentation/acpi/apei/einj.txt
>>> 
>>> [   53.264610] switch: port 1(eth0) entered forwarding state
>>> [ 1058.051938] BUG: sleeping function called from invalid context at
>>> /home/konrad/linux/include/linux/kernel.h:199 [ 1058.052066]
>>> in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog [
>>> 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O
>>> 3.5.0-rc1upstream-00041-ga16e594-dirty #2 [ 1058.052235] Call Trace:
>>> [ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100 [
>>> 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140 [
>>> 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190 [
>>> 1058.052461] [<ffffffff81148f4c>] sys_read+0x4c/0x90 [ 1058.052515]
>>> [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1
>>> 
>>> ?
>> 
>> I will debug it. Would you tell me the steps to reproduce the bug,
>> and your .config file? 
> 
> 
> # echo 0x00000008 > error_type
> # echo 1 > error_inject
> (XEN) CMCI: send CMCI to DOM0 through virq
> [  214.207962] BUG: sleeping function called from invalid context at
> /home/konradinux/kernel.h:199 [  214.208129] in_atomic(): 1,
> irqs_disabled(): 0, pid: 4581, name: mcelog [  214.208242] Pid: 4581,
> comm: mcelog Tainted: G           O
> 3.5.0-rc1upstream-00003-g149000b-dirty #1 # [  214.208384] Call
> Trace: [  214.208490]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100
> [  214.208606]  [<ffffffff81329b0b>] xen_mce_chrdev_read+0xab/0x140 [
> 214.208715]  [<ffffffff81148945>] vfs_read+0xc5/0x190 [  214.208816] 
> [<ffffffff81148b0c>] sys_read+0x4c/0x90 [  214.208923] 
> [<ffffffff815bd039>] system_call_fastpath+0x16/0x1b 
> 

Thanks! it caused by copy_to_user (might sleep) in an atomic spinlock context.
Send patch to fix it later, draft test OK.

Regards,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 09:27:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1ScvTa-00020a-Ma; Fri, 08 Jun 2012 09:27:26 +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 1ScvTY-00020S-Vz
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 09:27:25 +0000
Received: from [85.158.143.99:19676] by server-2.bemta-4.messagelabs.com id
	D8/73-17938-C75C1DF4; Fri, 08 Jun 2012 09:27:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339147642!26615156!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk0NzE3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4898 invoked from network); 8 Jun 2012 09:27:23 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-216.messagelabs.com with SMTP;
	8 Jun 2012 09:27:23 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 08 Jun 2012 02:27:22 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="153409155"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 08 Jun 2012 02:27:22 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 8 Jun 2012 02:27:22 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Fri, 8 Jun 2012 17:27:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
	platform
Thread-Index: AQHNRNHcM9HNPWGJrkGbs3SSikmUqJbwJzvA
Date: Fri, 8 Jun 2012 09:27:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522160D@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923351FEE7C@SHSMSX101.ccr.corp.intel.com>
	<20120606205523.GA10891@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC829233521AF4B@SHSMSX101.ccr.corp.intel.com>
	<20120607172039.GR9472@phenom.dumpdata.com>
In-Reply-To: <20120607172039.GR9472@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/mce: Add mcelog support for Xen
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 07, 2012 at 06:45:39AM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Thu, May 31, 2012 at 12:57:44PM +0000, Liu, Jinsong wrote:
>>>>> From 1a7951d6ca01d7f2c9dd2bdb6de5f8e7fdcb8bbd Mon Sep 17 00:00:00
>>>>> 2001
>>>> From: root <root@ljsromley.bj.intel.com>
>>>> Date: Fri, 1 Jun 2012 03:12:51 +0800
>>>> Subject: [PATCH 1/2] xen/mce: Add mcelog support for Xen platform
>>>> 
>>>> When MCA error occurs, it would be handled by Xen hypervisor first,
>>>> and then the error information would be sent to initial domain for
>>>> logging. 
>>>> 
>>>> This patch gets error information from Xen hypervisor and convert
>>>> Xen format error into Linux format mcelog. This logic is basically
>>>> self-contained, not touching other kernel components.
>>>> 
>>>> By using tools like mcelog tool users could read specific error
>>>> information, like what they did under native Linux.
>>>> 
>>>> To test follow directions outlined in
>>>> Documentation/acpi/apei/einj.txt
>>> 
>>> [   53.264610] switch: port 1(eth0) entered forwarding state
>>> [ 1058.051938] BUG: sleeping function called from invalid context at
>>> /home/konrad/linux/include/linux/kernel.h:199 [ 1058.052066]
>>> in_atomic(): 1, irqs_disabled(): 0, pid: 4552, name: mcelog [
>>> 1058.052130] Pid: 4552, comm: mcelog Tainted: G           O
>>> 3.5.0-rc1upstream-00041-ga16e594-dirty #2 [ 1058.052235] Call Trace:
>>> [ 1058.052291]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100 [
>>> 1058.052349]  [<ffffffff8132a55b>] xen_mce_chrdev_read+0xab/0x140 [
>>> 1058.052408]  [<ffffffff81148d85>] vfs_read+0xc5/0x190 [
>>> 1058.052461] [<ffffffff81148f4c>] sys_read+0x4c/0x90 [ 1058.052515]
>>> [<ffffffff815bdd79>] system_call_fastpath+0x16/0x1
>>> 
>>> ?
>> 
>> I will debug it. Would you tell me the steps to reproduce the bug,
>> and your .config file? 
> 
> 
> # echo 0x00000008 > error_type
> # echo 1 > error_inject
> (XEN) CMCI: send CMCI to DOM0 through virq
> [  214.207962] BUG: sleeping function called from invalid context at
> /home/konradinux/kernel.h:199 [  214.208129] in_atomic(): 1,
> irqs_disabled(): 0, pid: 4581, name: mcelog [  214.208242] Pid: 4581,
> comm: mcelog Tainted: G           O
> 3.5.0-rc1upstream-00003-g149000b-dirty #1 # [  214.208384] Call
> Trace: [  214.208490]  [<ffffffff8109ad9a>] __might_sleep+0xda/0x100
> [  214.208606]  [<ffffffff81329b0b>] xen_mce_chrdev_read+0xab/0x140 [
> 214.208715]  [<ffffffff81148945>] vfs_read+0xc5/0x190 [  214.208816] 
> [<ffffffff81148b0c>] sys_read+0x4c/0x90 [  214.208923] 
> [<ffffffff815bd039>] system_call_fastpath+0x16/0x1b 
> 

Thanks! it caused by copy_to_user (might sleep) in an atomic spinlock context.
Send patch to fix it later, draft test OK.

Regards,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 09:37:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09: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 1ScvdC-0002JD-Oy; Fri, 08 Jun 2012 09:37:22 +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 1ScvdA-0002J8-MM
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 09:37:21 +0000
Received: from [85.158.138.51:27263] by server-6.bemta-3.messagelabs.com id
	B3/EF-05063-FC7C1DF4; Fri, 08 Jun 2012 09:37:19 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339148237!31415636!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUwMDc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2106 invoked from network); 8 Jun 2012 09:37:18 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-174.messagelabs.com with SMTP;
	8 Jun 2012 09:37:18 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 08 Jun 2012 02:37:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="109492289"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 08 Jun 2012 02:37:09 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 8 Jun 2012 02:37:08 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.93]) with mapi id
	14.01.0355.002; Fri, 8 Jun 2012 17:37:06 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
	atomic context
Thread-Index: Ac1FWkRWxEyD+XUzS/eqorQpXCRDrw==
Date: Fri, 8 Jun 2012 09:37:06 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335221654@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_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From a9c5f29330a056291356b912816b5b2e0e061a30 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Sat, 9 Jun 2012 00:56:46 +0800
Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in atomi=
c context

copy_to_user might sleep and print a stack trace if it is executed
in an atomic spinlock context. This patch add a mutex lock and a
buffer to avoid the case.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 72e87d2..4046f01 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo;
 static uint32_t ncpus;
=20
 static DEFINE_SPINLOCK(mcelog_lock);
+static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
=20
 static struct xen_mce_log xen_mcelog =3D {
 	.signature	=3D XEN_MCE_LOG_SIGNATURE,
 	.len		=3D XEN_MCE_LOG_LEN,
 	.recordlen	=3D sizeof(struct xen_mce),
 };
+static struct xen_mce_log xen_mcelog_u;
=20
 static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
 static int xen_mce_chrdev_open_count;	/* #times opened */
@@ -99,6 +101,10 @@ static int xen_mce_chrdev_release(struct inode *inode, =
struct file *file)
 	return 0;
 }
=20
+/*
+ * copy_to_user might sleep and print a stack trace
+ * if it is executed in an atomic spinlock context
+ */
 static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
 				size_t usize, loff_t *off)
 {
@@ -106,9 +112,15 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, =
char __user *ubuf,
 	unsigned num;
 	int i, err;
=20
+	mutex_lock(&xen_mce_chrdev_read_mutex);
+
 	spin_lock(&mcelog_lock);
+	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
=20
 	num =3D xen_mcelog.next;
+	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog.next =3D 0;
+	spin_unlock(&mcelog_lock);
=20
 	/* Only supports full reads right now */
 	err =3D -EINVAL;
@@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file *filp,=
 char __user *ubuf,
=20
 	err =3D 0;
 	for (i =3D 0; i < num; i++) {
-		struct xen_mce *m =3D &xen_mcelog.entry[i];
+		struct xen_mce *m =3D &xen_mcelog_u.entry[i];
=20
 		err |=3D copy_to_user(buf, m, sizeof(*m));
 		buf +=3D sizeof(*m);
 	}
=20
-	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
-	xen_mcelog.next =3D 0;
+	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog_u.next =3D 0;
=20
 	if (err)
 		err =3D -EFAULT;
=20
 out:
-	spin_unlock(&mcelog_lock);
+	mutex_unlock(&xen_mce_chrdev_read_mutex);
=20
 	return err ? err : buf - ubuf;
 }
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch"
Content-Description: 0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch";
	size=2676; creation-date="Fri, 08 Jun 2012 09:28:53 GMT";
	modification-date="Fri, 08 Jun 2012 17:07:04 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhOWM1ZjI5MzMwYTA1NjI5MTM1NmI5MTI4MTZiNWIyZTBlMDYxYTMwIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU2F0LCA5IEp1biAyMDEyIDAwOjU2OjQ2ICswODAwClN1YmplY3Q6IFtQQVRDSF0geGVu
L21jZTogQWRkIG11dGV4IGxvY2sgYW5kIGJ1ZmZlciB0byBhdm9pZCBzbGVlcCBpbiBhdG9taWMg
Y29udGV4dAoKY29weV90b191c2VyIG1pZ2h0IHNsZWVwIGFuZCBwcmludCBhIHN0YWNrIHRyYWNl
IGlmIGl0IGlzIGV4ZWN1dGVkCmluIGFuIGF0b21pYyBzcGlubG9jayBjb250ZXh0LiBUaGlzIHBh
dGNoIGFkZCBhIG11dGV4IGxvY2sgYW5kIGEKYnVmZmVyIHRvIGF2b2lkIHRoZSBjYXNlLgoKUmVw
b3J0ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4K
U2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQog
ZHJpdmVycy94ZW4vbWNlbG9nLmMgfCAgIDIwICsrKysrKysrKysrKysrKystLS0tCiAxIGZpbGVz
IGNoYW5nZWQsIDE2IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy94ZW4vbWNlbG9nLmMgYi9kcml2ZXJzL3hlbi9tY2Vsb2cuYwppbmRleCA3MmU4N2Qy
Li40MDQ2ZjAxIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9tY2Vsb2cuYworKysgYi9kcml2ZXJz
L3hlbi9tY2Vsb2cuYwpAQCAtNTYsMTIgKzU2LDE0IEBAIHN0YXRpYyBzdHJ1Y3QgbWNpbmZvX2xv
Z2ljYWxfY3B1ICpnX3BoeXNpbmZvOwogc3RhdGljIHVpbnQzMl90IG5jcHVzOwogCiBzdGF0aWMg
REVGSU5FX1NQSU5MT0NLKG1jZWxvZ19sb2NrKTsKK3N0YXRpYyBERUZJTkVfTVVURVgoeGVuX21j
ZV9jaHJkZXZfcmVhZF9tdXRleCk7CiAKIHN0YXRpYyBzdHJ1Y3QgeGVuX21jZV9sb2cgeGVuX21j
ZWxvZyA9IHsKIAkuc2lnbmF0dXJlCT0gWEVOX01DRV9MT0dfU0lHTkFUVVJFLAogCS5sZW4JCT0g
WEVOX01DRV9MT0dfTEVOLAogCS5yZWNvcmRsZW4JPSBzaXplb2Yoc3RydWN0IHhlbl9tY2UpLAog
fTsKK3N0YXRpYyBzdHJ1Y3QgeGVuX21jZV9sb2cgeGVuX21jZWxvZ191OwogCiBzdGF0aWMgREVG
SU5FX1NQSU5MT0NLKHhlbl9tY2VfY2hyZGV2X3N0YXRlX2xvY2spOwogc3RhdGljIGludCB4ZW5f
bWNlX2NocmRldl9vcGVuX2NvdW50OwkvKiAjdGltZXMgb3BlbmVkICovCkBAIC05OSw2ICsxMDEs
MTAgQEAgc3RhdGljIGludCB4ZW5fbWNlX2NocmRldl9yZWxlYXNlKHN0cnVjdCBpbm9kZSAqaW5v
ZGUsIHN0cnVjdCBmaWxlICpmaWxlKQogCXJldHVybiAwOwogfQogCisvKgorICogY29weV90b191
c2VyIG1pZ2h0IHNsZWVwIGFuZCBwcmludCBhIHN0YWNrIHRyYWNlCisgKiBpZiBpdCBpcyBleGVj
dXRlZCBpbiBhbiBhdG9taWMgc3BpbmxvY2sgY29udGV4dAorICovCiBzdGF0aWMgc3NpemVfdCB4
ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFyIF9fdXNlciAqdWJ1ZiwK
IAkJCQlzaXplX3QgdXNpemUsIGxvZmZfdCAqb2ZmKQogewpAQCAtMTA2LDkgKzExMiwxNSBAQCBz
dGF0aWMgc3NpemVfdCB4ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFy
IF9fdXNlciAqdWJ1ZiwKIAl1bnNpZ25lZCBudW07CiAJaW50IGksIGVycjsKIAorCW11dGV4X2xv
Y2soJnhlbl9tY2VfY2hyZGV2X3JlYWRfbXV0ZXgpOworCiAJc3Bpbl9sb2NrKCZtY2Vsb2dfbG9j
ayk7CisJbWVtY3B5KCZ4ZW5fbWNlbG9nX3UsICZ4ZW5fbWNlbG9nLCBzaXplb2Yoc3RydWN0IHhl
bl9tY2VfbG9nKSk7CiAKIAludW0gPSB4ZW5fbWNlbG9nLm5leHQ7CisJbWVtc2V0KHhlbl9tY2Vs
b2cuZW50cnksIDAsIG51bSAqIHNpemVvZihzdHJ1Y3QgeGVuX21jZSkpOworCXhlbl9tY2Vsb2cu
bmV4dCA9IDA7CisJc3Bpbl91bmxvY2soJm1jZWxvZ19sb2NrKTsKIAogCS8qIE9ubHkgc3VwcG9y
dHMgZnVsbCByZWFkcyByaWdodCBub3cgKi8KIAllcnIgPSAtRUlOVkFMOwpAQCAtMTE3LDIwICsx
MjksMjAgQEAgc3RhdGljIHNzaXplX3QgeGVuX21jZV9jaHJkZXZfcmVhZChzdHJ1Y3QgZmlsZSAq
ZmlscCwgY2hhciBfX3VzZXIgKnVidWYsCiAKIAllcnIgPSAwOwogCWZvciAoaSA9IDA7IGkgPCBu
dW07IGkrKykgewotCQlzdHJ1Y3QgeGVuX21jZSAqbSA9ICZ4ZW5fbWNlbG9nLmVudHJ5W2ldOwor
CQlzdHJ1Y3QgeGVuX21jZSAqbSA9ICZ4ZW5fbWNlbG9nX3UuZW50cnlbaV07CiAKIAkJZXJyIHw9
IGNvcHlfdG9fdXNlcihidWYsIG0sIHNpemVvZigqbSkpOwogCQlidWYgKz0gc2l6ZW9mKCptKTsK
IAl9CiAKLQltZW1zZXQoeGVuX21jZWxvZy5lbnRyeSwgMCwgbnVtICogc2l6ZW9mKHN0cnVjdCB4
ZW5fbWNlKSk7Ci0JeGVuX21jZWxvZy5uZXh0ID0gMDsKKwltZW1zZXQoeGVuX21jZWxvZ191LmVu
dHJ5LCAwLCBudW0gKiBzaXplb2Yoc3RydWN0IHhlbl9tY2UpKTsKKwl4ZW5fbWNlbG9nX3UubmV4
dCA9IDA7CiAKIAlpZiAoZXJyKQogCQllcnIgPSAtRUZBVUxUOwogCiBvdXQ6Ci0Jc3Bpbl91bmxv
Y2soJm1jZWxvZ19sb2NrKTsKKwltdXRleF91bmxvY2soJnhlbl9tY2VfY2hyZGV2X3JlYWRfbXV0
ZXgpOwogCiAJcmV0dXJuIGVyciA/IGVyciA6IGJ1ZiAtIHVidWY7CiB9Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Jun 08 09:37:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 09: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 1ScvdC-0002JD-Oy; Fri, 08 Jun 2012 09:37:22 +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 1ScvdA-0002J8-MM
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 09:37:21 +0000
Received: from [85.158.138.51:27263] by server-6.bemta-3.messagelabs.com id
	B3/EF-05063-FC7C1DF4; Fri, 08 Jun 2012 09:37:19 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339148237!31415636!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUwMDc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2106 invoked from network); 8 Jun 2012 09:37:18 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-174.messagelabs.com with SMTP;
	8 Jun 2012 09:37:18 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 08 Jun 2012 02:37:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="109492289"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 08 Jun 2012 02:37:09 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 8 Jun 2012 02:37:08 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.93]) with mapi id
	14.01.0355.002; Fri, 8 Jun 2012 17:37:06 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
	atomic context
Thread-Index: Ac1FWkRWxEyD+XUzS/eqorQpXCRDrw==
Date: Fri, 8 Jun 2012 09:37:06 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335221654@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_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From a9c5f29330a056291356b912816b5b2e0e061a30 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Sat, 9 Jun 2012 00:56:46 +0800
Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in atomi=
c context

copy_to_user might sleep and print a stack trace if it is executed
in an atomic spinlock context. This patch add a mutex lock and a
buffer to avoid the case.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 72e87d2..4046f01 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo;
 static uint32_t ncpus;
=20
 static DEFINE_SPINLOCK(mcelog_lock);
+static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
=20
 static struct xen_mce_log xen_mcelog =3D {
 	.signature	=3D XEN_MCE_LOG_SIGNATURE,
 	.len		=3D XEN_MCE_LOG_LEN,
 	.recordlen	=3D sizeof(struct xen_mce),
 };
+static struct xen_mce_log xen_mcelog_u;
=20
 static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
 static int xen_mce_chrdev_open_count;	/* #times opened */
@@ -99,6 +101,10 @@ static int xen_mce_chrdev_release(struct inode *inode, =
struct file *file)
 	return 0;
 }
=20
+/*
+ * copy_to_user might sleep and print a stack trace
+ * if it is executed in an atomic spinlock context
+ */
 static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
 				size_t usize, loff_t *off)
 {
@@ -106,9 +112,15 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, =
char __user *ubuf,
 	unsigned num;
 	int i, err;
=20
+	mutex_lock(&xen_mce_chrdev_read_mutex);
+
 	spin_lock(&mcelog_lock);
+	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
=20
 	num =3D xen_mcelog.next;
+	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog.next =3D 0;
+	spin_unlock(&mcelog_lock);
=20
 	/* Only supports full reads right now */
 	err =3D -EINVAL;
@@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file *filp,=
 char __user *ubuf,
=20
 	err =3D 0;
 	for (i =3D 0; i < num; i++) {
-		struct xen_mce *m =3D &xen_mcelog.entry[i];
+		struct xen_mce *m =3D &xen_mcelog_u.entry[i];
=20
 		err |=3D copy_to_user(buf, m, sizeof(*m));
 		buf +=3D sizeof(*m);
 	}
=20
-	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
-	xen_mcelog.next =3D 0;
+	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog_u.next =3D 0;
=20
 	if (err)
 		err =3D -EFAULT;
=20
 out:
-	spin_unlock(&mcelog_lock);
+	mutex_unlock(&xen_mce_chrdev_read_mutex);
=20
 	return err ? err : buf - ubuf;
 }
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch"
Content-Description: 0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch";
	size=2676; creation-date="Fri, 08 Jun 2012 09:28:53 GMT";
	modification-date="Fri, 08 Jun 2012 17:07:04 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhOWM1ZjI5MzMwYTA1NjI5MTM1NmI5MTI4MTZiNWIyZTBlMDYxYTMwIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU2F0LCA5IEp1biAyMDEyIDAwOjU2OjQ2ICswODAwClN1YmplY3Q6IFtQQVRDSF0geGVu
L21jZTogQWRkIG11dGV4IGxvY2sgYW5kIGJ1ZmZlciB0byBhdm9pZCBzbGVlcCBpbiBhdG9taWMg
Y29udGV4dAoKY29weV90b191c2VyIG1pZ2h0IHNsZWVwIGFuZCBwcmludCBhIHN0YWNrIHRyYWNl
IGlmIGl0IGlzIGV4ZWN1dGVkCmluIGFuIGF0b21pYyBzcGlubG9jayBjb250ZXh0LiBUaGlzIHBh
dGNoIGFkZCBhIG11dGV4IGxvY2sgYW5kIGEKYnVmZmVyIHRvIGF2b2lkIHRoZSBjYXNlLgoKUmVw
b3J0ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4K
U2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQog
ZHJpdmVycy94ZW4vbWNlbG9nLmMgfCAgIDIwICsrKysrKysrKysrKysrKystLS0tCiAxIGZpbGVz
IGNoYW5nZWQsIDE2IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy94ZW4vbWNlbG9nLmMgYi9kcml2ZXJzL3hlbi9tY2Vsb2cuYwppbmRleCA3MmU4N2Qy
Li40MDQ2ZjAxIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9tY2Vsb2cuYworKysgYi9kcml2ZXJz
L3hlbi9tY2Vsb2cuYwpAQCAtNTYsMTIgKzU2LDE0IEBAIHN0YXRpYyBzdHJ1Y3QgbWNpbmZvX2xv
Z2ljYWxfY3B1ICpnX3BoeXNpbmZvOwogc3RhdGljIHVpbnQzMl90IG5jcHVzOwogCiBzdGF0aWMg
REVGSU5FX1NQSU5MT0NLKG1jZWxvZ19sb2NrKTsKK3N0YXRpYyBERUZJTkVfTVVURVgoeGVuX21j
ZV9jaHJkZXZfcmVhZF9tdXRleCk7CiAKIHN0YXRpYyBzdHJ1Y3QgeGVuX21jZV9sb2cgeGVuX21j
ZWxvZyA9IHsKIAkuc2lnbmF0dXJlCT0gWEVOX01DRV9MT0dfU0lHTkFUVVJFLAogCS5sZW4JCT0g
WEVOX01DRV9MT0dfTEVOLAogCS5yZWNvcmRsZW4JPSBzaXplb2Yoc3RydWN0IHhlbl9tY2UpLAog
fTsKK3N0YXRpYyBzdHJ1Y3QgeGVuX21jZV9sb2cgeGVuX21jZWxvZ191OwogCiBzdGF0aWMgREVG
SU5FX1NQSU5MT0NLKHhlbl9tY2VfY2hyZGV2X3N0YXRlX2xvY2spOwogc3RhdGljIGludCB4ZW5f
bWNlX2NocmRldl9vcGVuX2NvdW50OwkvKiAjdGltZXMgb3BlbmVkICovCkBAIC05OSw2ICsxMDEs
MTAgQEAgc3RhdGljIGludCB4ZW5fbWNlX2NocmRldl9yZWxlYXNlKHN0cnVjdCBpbm9kZSAqaW5v
ZGUsIHN0cnVjdCBmaWxlICpmaWxlKQogCXJldHVybiAwOwogfQogCisvKgorICogY29weV90b191
c2VyIG1pZ2h0IHNsZWVwIGFuZCBwcmludCBhIHN0YWNrIHRyYWNlCisgKiBpZiBpdCBpcyBleGVj
dXRlZCBpbiBhbiBhdG9taWMgc3BpbmxvY2sgY29udGV4dAorICovCiBzdGF0aWMgc3NpemVfdCB4
ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFyIF9fdXNlciAqdWJ1ZiwK
IAkJCQlzaXplX3QgdXNpemUsIGxvZmZfdCAqb2ZmKQogewpAQCAtMTA2LDkgKzExMiwxNSBAQCBz
dGF0aWMgc3NpemVfdCB4ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFy
IF9fdXNlciAqdWJ1ZiwKIAl1bnNpZ25lZCBudW07CiAJaW50IGksIGVycjsKIAorCW11dGV4X2xv
Y2soJnhlbl9tY2VfY2hyZGV2X3JlYWRfbXV0ZXgpOworCiAJc3Bpbl9sb2NrKCZtY2Vsb2dfbG9j
ayk7CisJbWVtY3B5KCZ4ZW5fbWNlbG9nX3UsICZ4ZW5fbWNlbG9nLCBzaXplb2Yoc3RydWN0IHhl
bl9tY2VfbG9nKSk7CiAKIAludW0gPSB4ZW5fbWNlbG9nLm5leHQ7CisJbWVtc2V0KHhlbl9tY2Vs
b2cuZW50cnksIDAsIG51bSAqIHNpemVvZihzdHJ1Y3QgeGVuX21jZSkpOworCXhlbl9tY2Vsb2cu
bmV4dCA9IDA7CisJc3Bpbl91bmxvY2soJm1jZWxvZ19sb2NrKTsKIAogCS8qIE9ubHkgc3VwcG9y
dHMgZnVsbCByZWFkcyByaWdodCBub3cgKi8KIAllcnIgPSAtRUlOVkFMOwpAQCAtMTE3LDIwICsx
MjksMjAgQEAgc3RhdGljIHNzaXplX3QgeGVuX21jZV9jaHJkZXZfcmVhZChzdHJ1Y3QgZmlsZSAq
ZmlscCwgY2hhciBfX3VzZXIgKnVidWYsCiAKIAllcnIgPSAwOwogCWZvciAoaSA9IDA7IGkgPCBu
dW07IGkrKykgewotCQlzdHJ1Y3QgeGVuX21jZSAqbSA9ICZ4ZW5fbWNlbG9nLmVudHJ5W2ldOwor
CQlzdHJ1Y3QgeGVuX21jZSAqbSA9ICZ4ZW5fbWNlbG9nX3UuZW50cnlbaV07CiAKIAkJZXJyIHw9
IGNvcHlfdG9fdXNlcihidWYsIG0sIHNpemVvZigqbSkpOwogCQlidWYgKz0gc2l6ZW9mKCptKTsK
IAl9CiAKLQltZW1zZXQoeGVuX21jZWxvZy5lbnRyeSwgMCwgbnVtICogc2l6ZW9mKHN0cnVjdCB4
ZW5fbWNlKSk7Ci0JeGVuX21jZWxvZy5uZXh0ID0gMDsKKwltZW1zZXQoeGVuX21jZWxvZ191LmVu
dHJ5LCAwLCBudW0gKiBzaXplb2Yoc3RydWN0IHhlbl9tY2UpKTsKKwl4ZW5fbWNlbG9nX3UubmV4
dCA9IDA7CiAKIAlpZiAoZXJyKQogCQllcnIgPSAtRUZBVUxUOwogCiBvdXQ6Ci0Jc3Bpbl91bmxv
Y2soJm1jZWxvZ19sb2NrKTsKKwltdXRleF91bmxvY2soJnhlbl9tY2VfY2hyZGV2X3JlYWRfbXV0
ZXgpOwogCiAJcmV0dXJuIGVyciA/IGVyciA6IGJ1ZiAtIHVidWY7CiB9Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335221654SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Jun 08 10:02:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw0U-000352-6Q; Fri, 08 Jun 2012 10:01:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Scw0S-00034u-JJ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 10:01:24 +0000
Received: from [85.158.143.35:29284] by server-1.bemta-4.messagelabs.com id
	31/1F-10042-37DC1DF4; Fri, 08 Jun 2012 10:01:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339149643!14124250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26110 invoked from network); 8 Jun 2012 10:00:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:00:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12905299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:00:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 11:00:43 +0100
Date: Fri, 8 Jun 2012 11:00:26 +0100
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: <1339088579.22331.8.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206081100050.14957@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com> 
	<1338990925.32319.103.camel@zakaz.uk.xensource.com>
	<1339062030.15265.53.camel@zakaz.uk.xensource.com>
	<1339088579.22331.8.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] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> On Thu, 2012-06-07 at 10:40 +0100, Ian Campbell wrote:
> > More head scratching required I think!
> 
> This turned out to be the problem with not initialising cpu_sibling_mask
> properly, see the thread against "[PATCH 16/38] arm: Add simple
> cpu_{sibling,core}_mask".
> 
> Having fixed that I updated based on your comments to:
> 
> 8<-----------------------------------------------------------
> 
> From 75cff29f4645dd19d07175109b5891fd44de9d60 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 13 Apr 2012 16:07:21 +0100
> Subject: [PATCH] arm: allocate and setup a guest vcpu.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

It looks OK now.


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  xen/arch/arm/domain.c         |   67 +++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/dummy.S          |    3 --
>  xen/include/public/arch-arm.h |    9 -----
>  3 files changed, 67 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 9339a11..b099d91 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
>      free_xenheap_page(v);
>  }
>  
> +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> +{
> +    return xmalloc(struct vcpu_guest_context);
> +
> +}
> +
> +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> +{
> +    xfree(vgc);
> +}
> +
>  int vcpu_initialise(struct vcpu *v)
>  {
>      int rc = 0;
> @@ -212,6 +223,62 @@ void arch_domain_destroy(struct domain *d)
>      /* domain_vgic_destroy */
>  }
>  
> +static int is_guest_psr(uint32_t psr)
> +{
> +    switch (psr & PSR_MODE_MASK)
> +    {
> +    case PSR_MODE_USR:
> +    case PSR_MODE_FIQ:
> +    case PSR_MODE_IRQ:
> +    case PSR_MODE_SVC:
> +    case PSR_MODE_ABT:
> +    case PSR_MODE_UND:
> +    case PSR_MODE_SYS:
> +        return 1;
> +    case PSR_MODE_MON:
> +    case PSR_MODE_HYP:
> +    default:
> +        return 0;
> +    }
> +}
> +
> +/*
> + * Initialise VCPU state. The context can be supplied by either the
> + * toolstack (XEN_DOMCTL_setvcpucontext) or the guest
> + * (VCPUOP_initialise) and therefore must be properly validated.
> + */
> +int arch_set_info_guest(
> +    struct vcpu *v, vcpu_guest_context_u c)
> +{
> +    struct cpu_user_regs *regs = &c.nat->user_regs;
> +
> +    if ( !is_guest_psr(regs->cpsr) )
> +        return -EINVAL;
> +
> +    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
> +        return -EINVAL;
> +    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
> +        return -EINVAL;
> +    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
> +        return -EINVAL;
> +    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
> +        return -EINVAL;
> +    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
> +        return -EINVAL;
> +
> +    v->arch.cpu_info->guest_cpu_user_regs = *regs;
> +
> +    /* XXX other state:
> +     * - SCTLR
> +     * - TTBR0/1
> +     * - TTBCR
> +     */
> +
> +    clear_bit(_VPF_down, &v->pause_flags);
> +
> +    return 0;
> +}
> +
>  void arch_dump_domain_info(struct domain *d)
>  {
>  }
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 016340c..3b48917 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
>  DUMMY(pirq_set_affinity);
>  
>  /* VCPU */
> -DUMMY(alloc_vcpu_guest_context);
>  DUMMY(arch_get_info_guest);
> -DUMMY(arch_set_info_guest);
>  DUMMY(arch_vcpu_reset);
> -DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
>  DUMMY(vcpu_show_execution_state);
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 1b1bcf3..e439727 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
>  
>  struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> -    union {
> -        uint32_t reg[16];
> -        struct {
> -            uint32_t __pad[12];
> -            uint32_t sp; /* r13 */
> -            uint32_t lr; /* r14 */
> -            uint32_t pc; /* r15 */
> -        };
> -    };
>  };
>  typedef struct vcpu_guest_context vcpu_guest_context_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
> -- 
> 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 Jun 08 10:02:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw0U-000352-6Q; Fri, 08 Jun 2012 10:01:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Scw0S-00034u-JJ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 10:01:24 +0000
Received: from [85.158.143.35:29284] by server-1.bemta-4.messagelabs.com id
	31/1F-10042-37DC1DF4; Fri, 08 Jun 2012 10:01:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339149643!14124250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26110 invoked from network); 8 Jun 2012 10:00:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:00:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12905299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:00:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 11:00:43 +0100
Date: Fri, 8 Jun 2012 11:00:26 +0100
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: <1339088579.22331.8.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206081100050.14957@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-8-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061443300.6030@kaball.uk.xensource.com> 
	<1338990925.32319.103.camel@zakaz.uk.xensource.com>
	<1339062030.15265.53.camel@zakaz.uk.xensource.com>
	<1339088579.22331.8.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] [PATCH 08/38] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> On Thu, 2012-06-07 at 10:40 +0100, Ian Campbell wrote:
> > More head scratching required I think!
> 
> This turned out to be the problem with not initialising cpu_sibling_mask
> properly, see the thread against "[PATCH 16/38] arm: Add simple
> cpu_{sibling,core}_mask".
> 
> Having fixed that I updated based on your comments to:
> 
> 8<-----------------------------------------------------------
> 
> From 75cff29f4645dd19d07175109b5891fd44de9d60 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 13 Apr 2012 16:07:21 +0100
> Subject: [PATCH] arm: allocate and setup a guest vcpu.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

It looks OK now.


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  xen/arch/arm/domain.c         |   67 +++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/dummy.S          |    3 --
>  xen/include/public/arch-arm.h |    9 -----
>  3 files changed, 67 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 9339a11..b099d91 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
>      free_xenheap_page(v);
>  }
>  
> +struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> +{
> +    return xmalloc(struct vcpu_guest_context);
> +
> +}
> +
> +void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
> +{
> +    xfree(vgc);
> +}
> +
>  int vcpu_initialise(struct vcpu *v)
>  {
>      int rc = 0;
> @@ -212,6 +223,62 @@ void arch_domain_destroy(struct domain *d)
>      /* domain_vgic_destroy */
>  }
>  
> +static int is_guest_psr(uint32_t psr)
> +{
> +    switch (psr & PSR_MODE_MASK)
> +    {
> +    case PSR_MODE_USR:
> +    case PSR_MODE_FIQ:
> +    case PSR_MODE_IRQ:
> +    case PSR_MODE_SVC:
> +    case PSR_MODE_ABT:
> +    case PSR_MODE_UND:
> +    case PSR_MODE_SYS:
> +        return 1;
> +    case PSR_MODE_MON:
> +    case PSR_MODE_HYP:
> +    default:
> +        return 0;
> +    }
> +}
> +
> +/*
> + * Initialise VCPU state. The context can be supplied by either the
> + * toolstack (XEN_DOMCTL_setvcpucontext) or the guest
> + * (VCPUOP_initialise) and therefore must be properly validated.
> + */
> +int arch_set_info_guest(
> +    struct vcpu *v, vcpu_guest_context_u c)
> +{
> +    struct cpu_user_regs *regs = &c.nat->user_regs;
> +
> +    if ( !is_guest_psr(regs->cpsr) )
> +        return -EINVAL;
> +
> +    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
> +        return -EINVAL;
> +    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
> +        return -EINVAL;
> +    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
> +        return -EINVAL;
> +    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
> +        return -EINVAL;
> +    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
> +        return -EINVAL;
> +
> +    v->arch.cpu_info->guest_cpu_user_regs = *regs;
> +
> +    /* XXX other state:
> +     * - SCTLR
> +     * - TTBR0/1
> +     * - TTBCR
> +     */
> +
> +    clear_bit(_VPF_down, &v->pause_flags);
> +
> +    return 0;
> +}
> +
>  void arch_dump_domain_info(struct domain *d)
>  {
>  }
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 016340c..3b48917 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
>  DUMMY(pirq_set_affinity);
>  
>  /* VCPU */
> -DUMMY(alloc_vcpu_guest_context);
>  DUMMY(arch_get_info_guest);
> -DUMMY(arch_set_info_guest);
>  DUMMY(arch_vcpu_reset);
> -DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
>  DUMMY(vcpu_show_execution_state);
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 1b1bcf3..e439727 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
>  
>  struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> -    union {
> -        uint32_t reg[16];
> -        struct {
> -            uint32_t __pad[12];
> -            uint32_t sp; /* r13 */
> -            uint32_t lr; /* r14 */
> -            uint32_t pc; /* r15 */
> -        };
> -    };
>  };
>  typedef struct vcpu_guest_context vcpu_guest_context_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
> -- 
> 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 Jun 08 10:07:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw5d-0003NC-Ul; Fri, 08 Jun 2012 10:06:45 +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 1Scw5c-0003N7-Kc
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 10:06:45 +0000
Received: from [193.109.254.147:24779] by server-6.bemta-14.messagelabs.com id
	B7/55-02426-3BEC1DF4; Fri, 08 Jun 2012 10:06:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339149997!3589030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31549 invoked from network); 8 Jun 2012 10:06:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12905440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:06:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 11:06:37 +0100
Date: Fri, 8 Jun 2012 11:06:20 +0100
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: <20120607215942.GA13592@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1206081106080.14957@kaball.uk.xensource.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 7 Jun 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 01, 2012 at 11:16:29AM +0100, Stefano Stabellini wrote:
> > On Thu, 31 May 2012, Konrad Rzeszutek Wilk wrote:
> > > The blkfront_remove part is .. that is going to take some surgery to do
> > > and I don't think I am going to be able to attempt that within the next couple
> > > of weeks. So lets put that on the TODO list and just do this one?
> > 
> > OK
> > 
> > > >From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> > > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Date: Fri, 25 May 2012 17:34:51 -0400
> > > Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> > > 
> > > Part of the ring structure is the 'id' field which is under
> > > control of the frontend. The frontend stamps it with "some"
> > > value (this some in this implementation being a value less
> > > than BLK_RING_SIZE), and when it gets a response expects
> > > said value to be in the response structure. We have a check
> > > for the id field when spolling new requests but not when
> > > de-spolling responses.
> > > 
> > > We also add an extra check in add_id_to_freelist to make
> > > sure that the 'struct request' was not NULL - as we cannot
> > > pass a NULL to __blk_end_request_all, otherwise that crashes
> > > (and all the operations that the response is dealing with
> > > end up with __blk_end_request_all).
> > > 
> > > Lastly we also print the name of the operation that failed.
> > > 
> > > [v1: s/BUG/WARN/ suggested by Stefano]
> > > [v2: Add extra check in add_id_to_freelist]
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
> > >  1 files changed, 29 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > > index 60eed4b..c7ef8a4 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info *info)
> > >  static void add_id_to_freelist(struct blkfront_info *info,
> > >  			       unsigned long id)
> > >  {
> > > +	BUG_ON(info->shadow[id].req.u.rw.id != id);
> > >  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> > > +	BUG_ON(info->shadow[id].request == NULL);
> > >  	info->shadow[id].request = NULL;
> > >  	info->shadow_free = id;
> > >  }
> > 
> > Like Jan said, it would be best to change the two BUG_ON into WARN_ON
> > and return an error.
> 
> Yes. I missed that.
> > 
> > 
> > > +static const char *op_name(int op)
> > > +{
> > > +	const char *names[BLKIF_OP_DISCARD+1] = {
> > > +		"read" , "write", "barrier", "flush", "reserved", "discard"};
> > > +
> > > +	if (op > BLKIF_OP_DISCARD)
> > > +		return "unknown";
> > > +	return names[op];
> > > +}
> > 
> > Considering that op is an int, shoudn't we check for negative values
> > too?
> 
> Yes! I also converted this per Jan's excellent idea.
> 
> Please see:
> 
> 
> >From 3877611c3096423a7741e99e9c9b9e63a9f2e557 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]
> [v2: Add extra check in add_id_to_freelist]
> [v3: Redid op_name per Jan's suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  drivers/block/xen-blkfront.c     |   58 +++++++++++++++++++++++++++++--------
>  include/xen/interface/io/blkif.h |    6 ++++
>  2 files changed, 51 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..ae8e3b7 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -141,14 +141,33 @@ static int get_id_from_freelist(struct blkfront_info *info)
>  	return free;
>  }
>  
> -static void add_id_to_freelist(struct blkfront_info *info,
> +static int add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	if (info->shadow[id].req.u.rw.id != id)
> +		return -EINVAL;
> +	if (info->shadow[id].request == NULL)
> +		return -EINVAL;
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
> +	return 0;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	static const char *names[] = {
> +		[BLKIF_OP_READ] = "read",
> +		[BLKIF_OP_WRITE] = "write",
> +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> +		[BLKIF_OP_RESERVED_1] = "reserved",
> +		[BLKIF_OP_DISCARD] = "discard" };
> +
> +	if (op < 0 || op >= ARRAY_SIZE(names))
> +		return "unknown";
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -744,20 +763,31 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE)
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			goto err_out;
> +
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
>  			blkif_completion(&info->shadow[id]);
>  
> -		add_id_to_freelist(info, id);
> +		if (add_id_to_freelist(info, id))
> +			goto err_out;
>  
>  		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
>  		switch (bret->operation) {
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -769,18 +799,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> @@ -813,12 +839,18 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  			goto again;
>  	} else
>  		info->ring.sring->rsp_event = i + 1;
> -
>  	kick_pending_request_queues(info);
>  
>  	spin_unlock_irqrestore(&blkif_io_lock, flags);
>  
>  	return IRQ_HANDLED;
> +err_out:
> +	WARN(1, "%s: response to %s has incorrect id\n",
> +	     info->gd->disk_name, op_name(bret->operation));
> +
> +	spin_unlock_irqrestore(&info->io_lock, flags);
> +
> +	return IRQ_HANDLED;
>  }
>  
>  
> diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> index ee338bf..bc75c75 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -59,6 +59,12 @@ typedef uint64_t blkif_sector_t;
>  #define BLKIF_OP_FLUSH_DISKCACHE   3
>  
>  /*
> + * Used in SLES sources for device specific command packet
> + * contained within the request. Reserved for that purpose.
> + */
> +#define BLKIF_OP_RESERVED_1        4
> +
> +/*
>   * Recognised only if "feature-discard" is present in backend xenbus info.
>   * The "feature-discard" node contains a boolean indicating whether trim
>   * (ATA) or unmap (SCSI) - conviently called discard requests are likely
> -- 
> 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 Fri Jun 08 10:07:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw5d-0003NC-Ul; Fri, 08 Jun 2012 10:06:45 +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 1Scw5c-0003N7-Kc
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 10:06:45 +0000
Received: from [193.109.254.147:24779] by server-6.bemta-14.messagelabs.com id
	B7/55-02426-3BEC1DF4; Fri, 08 Jun 2012 10:06:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1339149997!3589030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31549 invoked from network); 8 Jun 2012 10:06:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12905440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:06:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 11:06:37 +0100
Date: Fri, 8 Jun 2012 11:06:20 +0100
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: <20120607215942.GA13592@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1206081106080.14957@kaball.uk.xensource.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 7 Jun 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 01, 2012 at 11:16:29AM +0100, Stefano Stabellini wrote:
> > On Thu, 31 May 2012, Konrad Rzeszutek Wilk wrote:
> > > The blkfront_remove part is .. that is going to take some surgery to do
> > > and I don't think I am going to be able to attempt that within the next couple
> > > of weeks. So lets put that on the TODO list and just do this one?
> > 
> > OK
> > 
> > > >From 4aabb5b44778fc0c0b8d4f5a2e2cd8e8490064d7 Mon Sep 17 00:00:00 2001
> > > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Date: Fri, 25 May 2012 17:34:51 -0400
> > > Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> > > 
> > > Part of the ring structure is the 'id' field which is under
> > > control of the frontend. The frontend stamps it with "some"
> > > value (this some in this implementation being a value less
> > > than BLK_RING_SIZE), and when it gets a response expects
> > > said value to be in the response structure. We have a check
> > > for the id field when spolling new requests but not when
> > > de-spolling responses.
> > > 
> > > We also add an extra check in add_id_to_freelist to make
> > > sure that the 'struct request' was not NULL - as we cannot
> > > pass a NULL to __blk_end_request_all, otherwise that crashes
> > > (and all the operations that the response is dealing with
> > > end up with __blk_end_request_all).
> > > 
> > > Lastly we also print the name of the operation that failed.
> > > 
> > > [v1: s/BUG/WARN/ suggested by Stefano]
> > > [v2: Add extra check in add_id_to_freelist]
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/block/xen-blkfront.c |   39 +++++++++++++++++++++++++++++----------
> > >  1 files changed, 29 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > > index 60eed4b..c7ef8a4 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -144,11 +144,22 @@ static int get_id_from_freelist(struct blkfront_info *info)
> > >  static void add_id_to_freelist(struct blkfront_info *info,
> > >  			       unsigned long id)
> > >  {
> > > +	BUG_ON(info->shadow[id].req.u.rw.id != id);
> > >  	info->shadow[id].req.u.rw.id  = info->shadow_free;
> > > +	BUG_ON(info->shadow[id].request == NULL);
> > >  	info->shadow[id].request = NULL;
> > >  	info->shadow_free = id;
> > >  }
> > 
> > Like Jan said, it would be best to change the two BUG_ON into WARN_ON
> > and return an error.
> 
> Yes. I missed that.
> > 
> > 
> > > +static const char *op_name(int op)
> > > +{
> > > +	const char *names[BLKIF_OP_DISCARD+1] = {
> > > +		"read" , "write", "barrier", "flush", "reserved", "discard"};
> > > +
> > > +	if (op > BLKIF_OP_DISCARD)
> > > +		return "unknown";
> > > +	return names[op];
> > > +}
> > 
> > Considering that op is an int, shoudn't we check for negative values
> > too?
> 
> Yes! I also converted this per Jan's excellent idea.
> 
> Please see:
> 
> 
> >From 3877611c3096423a7741e99e9c9b9e63a9f2e557 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]
> [v2: Add extra check in add_id_to_freelist]
> [v3: Redid op_name per Jan's suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  drivers/block/xen-blkfront.c     |   58 +++++++++++++++++++++++++++++--------
>  include/xen/interface/io/blkif.h |    6 ++++
>  2 files changed, 51 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..ae8e3b7 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -141,14 +141,33 @@ static int get_id_from_freelist(struct blkfront_info *info)
>  	return free;
>  }
>  
> -static void add_id_to_freelist(struct blkfront_info *info,
> +static int add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	if (info->shadow[id].req.u.rw.id != id)
> +		return -EINVAL;
> +	if (info->shadow[id].request == NULL)
> +		return -EINVAL;
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
> +	return 0;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	static const char *names[] = {
> +		[BLKIF_OP_READ] = "read",
> +		[BLKIF_OP_WRITE] = "write",
> +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> +		[BLKIF_OP_RESERVED_1] = "reserved",
> +		[BLKIF_OP_DISCARD] = "discard" };
> +
> +	if (op < 0 || op >= ARRAY_SIZE(names))
> +		return "unknown";
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -744,20 +763,31 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE)
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. So limp along. */
> +			goto err_out;
> +
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
>  			blkif_completion(&info->shadow[id]);
>  
> -		add_id_to_freelist(info, id);
> +		if (add_id_to_freelist(info, id))
> +			goto err_out;
>  
>  		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
>  		switch (bret->operation) {
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -769,18 +799,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> @@ -813,12 +839,18 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  			goto again;
>  	} else
>  		info->ring.sring->rsp_event = i + 1;
> -
>  	kick_pending_request_queues(info);
>  
>  	spin_unlock_irqrestore(&blkif_io_lock, flags);
>  
>  	return IRQ_HANDLED;
> +err_out:
> +	WARN(1, "%s: response to %s has incorrect id\n",
> +	     info->gd->disk_name, op_name(bret->operation));
> +
> +	spin_unlock_irqrestore(&info->io_lock, flags);
> +
> +	return IRQ_HANDLED;
>  }
>  
>  
> diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> index ee338bf..bc75c75 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -59,6 +59,12 @@ typedef uint64_t blkif_sector_t;
>  #define BLKIF_OP_FLUSH_DISKCACHE   3
>  
>  /*
> + * Used in SLES sources for device specific command packet
> + * contained within the request. Reserved for that purpose.
> + */
> +#define BLKIF_OP_RESERVED_1        4
> +
> +/*
>   * Recognised only if "feature-discard" is present in backend xenbus info.
>   * The "feature-discard" node contains a boolean indicating whether trim
>   * (ATA) or unmap (SCSI) - conviently called discard requests are likely
> -- 
> 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 Fri Jun 08 10:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw7B-0003Vj-Lp; Fri, 08 Jun 2012 10:08:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aorchis@gmail.com>) id 1ScaHd-00043Y-Fj
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:49:41 +0000
Received: from [193.109.254.147:63654] by server-10.bemta-14.messagelabs.com
	id 01/72-25709-44780DF4; Thu, 07 Jun 2012 10:49:40 +0000
X-Env-Sender: aorchis@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339066178!8524306!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16137 invoked from network); 7 Jun 2012 10:49:39 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:49:39 -0000
Received: by dajz8 with SMTP id z8so789001daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 03:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=oq/IaBiSfX3GCkEBM7upiUxF2eWLYbkywmn+6oXxnQU=;
	b=vZwmvEW6jSQS7C9LKL4dQhqwSKJXlwgLL4yx+zY+R1XsMTxkcYfopdCc2lC4rC7my8
	VvC4tl315PKM1TwDWdDWHzDShZsjidZriZC5A9RkBaD+zxLsTqy2tv7wDq119xlY5IC8
	be4PSvz6iWqbTlSqRNkh73gUc+7BDncax5tDwKsOvsCFfW/vZL+O/Pq2hCVV53bu7T+U
	9Xd/8DB8mMfg83HsSmWgoE0I7sj0Q8P4NHWevIyy/xtWbug7lXYXlp3MaIoPsGh3HGR2
	xaEPMAErGq7+FN5qdxx4L/Ng6OOKXAhtsChQHaMLb5LvfGtn+y2zlCna+iHUluuCPmfR
	ym/g==
MIME-Version: 1.0
Received: by 10.68.225.135 with SMTP id rk7mr3322769pbc.38.1339066177490; Thu,
	07 Jun 2012 03:49:37 -0700 (PDT)
Received: by 10.68.197.40 with HTTP; Thu, 7 Jun 2012 03:49:37 -0700 (PDT)
In-Reply-To: <20120605161737.GC24031@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 20:49:37 +1000
Message-ID: <CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
From: "aorchis@gmail.com" <aorchis@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 08 Jun 2012 10:08:20 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
>> Hi Jeremy and Konrad,
>
> CC-ing xen-devel.
>
>>
>> Basically the driver NVIDIA provided is a binary blob and recent
>> versions does not work with the PAT layout of XEN so it falls back to
>> MTRR to provide write combining (please correct me if I'm wrong).
>
> OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
> NVidia driver? I've had reports that it works OK.

I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
(v302) but both didn't work.

When the nvidia module is loaded, it prints out an error message:
"NVRM: PAT configuration unsupported, falling back to MTRRs."

When I launch Xorg, the screen turns blank then the monitors powered down a=
nd my
box hard crashed, I had to hold the power button to turn it off.

This only happens in dom0 under XEN, if I run my dom0 by itself then
the nvidia module loads fine.

>> However there is no MTRR support on XEN so the driver hard crashed my
>> machine (I can't ssh into the box anymore).
>>
>> Moreover, there is problem with the open source driver 'nouveau' for
>> NVIDIA card =A0(also has something to do with PAT layout of XEN) which
>> causes memory corruption.
>
> Huh? Can you point me to a bugzilla please? There was a corruption
> issue where you can pass in 'nopat' on the command line.

Yes, that is the issue I was referring to, I had to pass "nopat" to
GRUB in order
to fix it.

>>
>> I found several patches for XEN which supposedly provide basic MTRR
>> support for XEN however there is still no /proc/mtrr. Jeremy, can you
>> tell me if you had been able to get /proc/mtrr on XEN dom0?
>
>>
>> Thanks for your time.
>>
>> Damien.
>>
>>
>> On Sun, Jun 3, 2012 at 5:37 AM, Jeremy Fitzhardinge <jeremy@goop.org> wr=
ote:
>> > On 06/02/2012 03:13 AM, aorchis@gmail.com wrote:
>> >> Hi Jeremy,
>> >>
>> >> Is there any way I can get back MTRR support in XEN in 3.0 kernel? To
>> >> make a long story short, NVIDIA binary driver rejects PAT in XEN and
>> >> it falls back to using MTRR but MTRR in XEN was taken out a long time
>> >> ago so now there's no way to get the NVIDIA binary blob running under
>> >> a linux XEN dom0. I was about to tear my hair out looking for
>> >> solutions high and low.
>> >
>> > Hi!
>> >
>> > Firstly, Konrad is probably the person you should send this to these
>> > days, since I'm not managing to get much Xen stuff done.
>> >
>> > Secondly, hm. =A0Unfortunately, the changes we did have to integrate X=
en's
>> > MTRR machinery with Linux have been solidly rejected by the upstream
>> > maintainers several times, so I think its unlikely that they will ever
>> > make it into the mainline kernel. =A0And it doesn't seem to have really
>> > made a difference because PAT does subsume MTRR for at least all the in
>> > kernel users, as far as I know.
>> >
>> > What do you mean by "[the] NVIDIA binary driver rejects PAT in XEN and
>> > it falls back to using MTRR"? =A0Why does the Nvidia driver reject PAT?
>> > Perhaps addressing that would be a more profitable way of getting this
>> > working. =A0In the past we've talked about changing Xen's PAT mapping =
to
>> > match the kernel's (or make it configurable), but for now we're
>> > remapping between the PAT schemes in the pte pvops. =A0If the NVIDIA
>> > driver is using that mechanism to set ptes (as it must to get anywhere
>> > in a pvops kernel), then it should be fine with the remapping. =A0Or i=
ts
>> > possible they're having problems with reading a pte back and mapping
>> > from Xen->Linux PAT formats, which is a problem some of the in-kernel
>> > drivers also had. =A0Konrad, how did that turn out in the end?
>
> Attic. I've turned it off since we had corruption issues (the WC didn't
> turn back into WB b/c of page_attr using the pte_flag instead of pte_var).
> Peter was talking about some software PAT lookup code but I hadn't
> focused on that. There is also some performance numbers to run and collec=
t.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw7B-0003Vj-Lp; Fri, 08 Jun 2012 10:08:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aorchis@gmail.com>) id 1ScaHd-00043Y-Fj
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 10:49:41 +0000
Received: from [193.109.254.147:63654] by server-10.bemta-14.messagelabs.com
	id 01/72-25709-44780DF4; Thu, 07 Jun 2012 10:49:40 +0000
X-Env-Sender: aorchis@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339066178!8524306!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16137 invoked from network); 7 Jun 2012 10:49:39 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jun 2012 10:49:39 -0000
Received: by dajz8 with SMTP id z8so789001daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Jun 2012 03:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=oq/IaBiSfX3GCkEBM7upiUxF2eWLYbkywmn+6oXxnQU=;
	b=vZwmvEW6jSQS7C9LKL4dQhqwSKJXlwgLL4yx+zY+R1XsMTxkcYfopdCc2lC4rC7my8
	VvC4tl315PKM1TwDWdDWHzDShZsjidZriZC5A9RkBaD+zxLsTqy2tv7wDq119xlY5IC8
	be4PSvz6iWqbTlSqRNkh73gUc+7BDncax5tDwKsOvsCFfW/vZL+O/Pq2hCVV53bu7T+U
	9Xd/8DB8mMfg83HsSmWgoE0I7sj0Q8P4NHWevIyy/xtWbug7lXYXlp3MaIoPsGh3HGR2
	xaEPMAErGq7+FN5qdxx4L/Ng6OOKXAhtsChQHaMLb5LvfGtn+y2zlCna+iHUluuCPmfR
	ym/g==
MIME-Version: 1.0
Received: by 10.68.225.135 with SMTP id rk7mr3322769pbc.38.1339066177490; Thu,
	07 Jun 2012 03:49:37 -0700 (PDT)
Received: by 10.68.197.40 with HTTP; Thu, 7 Jun 2012 03:49:37 -0700 (PDT)
In-Reply-To: <20120605161737.GC24031@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
Date: Thu, 7 Jun 2012 20:49:37 +1000
Message-ID: <CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
From: "aorchis@gmail.com" <aorchis@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 08 Jun 2012 10:08:20 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 6, 2012 at 2:17 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Jun 03, 2012 at 05:31:32PM +1000, aorchis@gmail.com wrote:
>> Hi Jeremy and Konrad,
>
> CC-ing xen-devel.
>
>>
>> Basically the driver NVIDIA provided is a binary blob and recent
>> versions does not work with the PAT layout of XEN so it falls back to
>> MTRR to provide write combining (please correct me if I'm wrong).
>
> OK? Which is still OK. Are you using a v3.4 kernel with an up-to-date
> NVidia driver? I've had reports that it works OK.

I briefly tried kernel 3.4 to see if the problem is fixed but it's not.
I used v3.4 kernel with NVIDIA driver v295.49 and a beta version
(v302) but both didn't work.

When the nvidia module is loaded, it prints out an error message:
"NVRM: PAT configuration unsupported, falling back to MTRRs."

When I launch Xorg, the screen turns blank then the monitors powered down a=
nd my
box hard crashed, I had to hold the power button to turn it off.

This only happens in dom0 under XEN, if I run my dom0 by itself then
the nvidia module loads fine.

>> However there is no MTRR support on XEN so the driver hard crashed my
>> machine (I can't ssh into the box anymore).
>>
>> Moreover, there is problem with the open source driver 'nouveau' for
>> NVIDIA card =A0(also has something to do with PAT layout of XEN) which
>> causes memory corruption.
>
> Huh? Can you point me to a bugzilla please? There was a corruption
> issue where you can pass in 'nopat' on the command line.

Yes, that is the issue I was referring to, I had to pass "nopat" to
GRUB in order
to fix it.

>>
>> I found several patches for XEN which supposedly provide basic MTRR
>> support for XEN however there is still no /proc/mtrr. Jeremy, can you
>> tell me if you had been able to get /proc/mtrr on XEN dom0?
>
>>
>> Thanks for your time.
>>
>> Damien.
>>
>>
>> On Sun, Jun 3, 2012 at 5:37 AM, Jeremy Fitzhardinge <jeremy@goop.org> wr=
ote:
>> > On 06/02/2012 03:13 AM, aorchis@gmail.com wrote:
>> >> Hi Jeremy,
>> >>
>> >> Is there any way I can get back MTRR support in XEN in 3.0 kernel? To
>> >> make a long story short, NVIDIA binary driver rejects PAT in XEN and
>> >> it falls back to using MTRR but MTRR in XEN was taken out a long time
>> >> ago so now there's no way to get the NVIDIA binary blob running under
>> >> a linux XEN dom0. I was about to tear my hair out looking for
>> >> solutions high and low.
>> >
>> > Hi!
>> >
>> > Firstly, Konrad is probably the person you should send this to these
>> > days, since I'm not managing to get much Xen stuff done.
>> >
>> > Secondly, hm. =A0Unfortunately, the changes we did have to integrate X=
en's
>> > MTRR machinery with Linux have been solidly rejected by the upstream
>> > maintainers several times, so I think its unlikely that they will ever
>> > make it into the mainline kernel. =A0And it doesn't seem to have really
>> > made a difference because PAT does subsume MTRR for at least all the in
>> > kernel users, as far as I know.
>> >
>> > What do you mean by "[the] NVIDIA binary driver rejects PAT in XEN and
>> > it falls back to using MTRR"? =A0Why does the Nvidia driver reject PAT?
>> > Perhaps addressing that would be a more profitable way of getting this
>> > working. =A0In the past we've talked about changing Xen's PAT mapping =
to
>> > match the kernel's (or make it configurable), but for now we're
>> > remapping between the PAT schemes in the pte pvops. =A0If the NVIDIA
>> > driver is using that mechanism to set ptes (as it must to get anywhere
>> > in a pvops kernel), then it should be fine with the remapping. =A0Or i=
ts
>> > possible they're having problems with reading a pte back and mapping
>> > from Xen->Linux PAT formats, which is a problem some of the in-kernel
>> > drivers also had. =A0Konrad, how did that turn out in the end?
>
> Attic. I've turned it off since we had corruption issues (the WC didn't
> turn back into WB b/c of page_attr using the pte_flag instead of pte_var).
> Peter was talking about some software PAT lookup code but I hadn't
> focused on that. There is also some performance numbers to run and collec=
t.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw7C-0003Vv-2D; Fri, 08 Jun 2012 10:08:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Sergio.Gelato@astro.su.se>) id 1ScbrG-0008Mw-JB
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:30:34 +0000
Received: from [85.158.138.51:18217] by server-10.bemta-3.messagelabs.com id
	29/59-06494-9EE90DF4; Thu, 07 Jun 2012 12:30:33 +0000
X-Env-Sender: Sergio.Gelato@astro.su.se
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339072233!27215550!1
X-Originating-IP: [130.237.164.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3365 invoked from network); 7 Jun 2012 12:30:33 -0000
Received: from smtp2.su.se (HELO smtp.su.se) (130.237.164.53)
	by server-10.tower-174.messagelabs.com with SMTP;
	7 Jun 2012 12:30:33 -0000
Received: from localhost (localhost [127.0.0.1])
	by smtp.su.se (Postfix) with ESMTP id F2275819DE
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 14:30:32 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at av-in.su.se
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-9999 required=7 tests=[none]
Received: from smtp.su.se ([127.0.0.1])
	by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 2kUhpRtooC45 for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 14:30:32 +0200 (CEST)
Received: from hermes.astro.su.se (hermes.astro.su.se [130.237.166.29])
	by smtp.su.se (Postfix) with SMTP id E30FF819E2
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 14:30:31 +0200 (CEST)
Received: (qmail 31765 invoked from network); 7 Jun 2012 12:30:31 -0000
Received: from ebisu.astro.su.se (HELO localhost) (130.237.166.60)
	by hermes.astro.su.se with SMTP; 7 Jun 2012 12:30:31 -0000
Date: Thu, 7 Jun 2012 14:30:31 +0200
From: Sergio Gelato <Sergio.Gelato@astro.su.se>
To: Andrea Arcangeli <aarcange@redhat.com>
Message-ID: <20120607123031.GB2112@hanuman.astro.su.se>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
	<20120607103355.GA21339@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607103355.GA21339@redhat.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 08 Jun 2012 10:08:20 +0000
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* Andrea Arcangeli [2012-06-07 12:33:55 +0200]:
> I guess if Xen can't be updated to handle an atomic64_read on a pmd in
> the guest, 

I'm not sure if it makes a difference, but just in case: I observed the
problem in a dom0.

>            we can add a pmd_read paravirt op? Or if we don't want to
> break the paravirt interface a loop like gup_fast with irq disabled
> should also work but looping + local_irq_disable()/enable() sounded
> worse and more complex than a atomic64_read (gup fast already disables
> irqs because it doesn't hold the mmap_sem so it's a different cost
> looping there). AFIK Xen disables THP during boot, so a check on THP
> being enabled and falling back in the THP=n version of
> pmd_read_atomic, would also be safe, but it's not so nice to do it
> with a runtime check.
> 
> Thanks,
> Andrea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:08:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw7C-0003Vv-2D; Fri, 08 Jun 2012 10:08:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Sergio.Gelato@astro.su.se>) id 1ScbrG-0008Mw-JB
	for xen-devel@lists.xensource.com; Thu, 07 Jun 2012 12:30:34 +0000
Received: from [85.158.138.51:18217] by server-10.bemta-3.messagelabs.com id
	29/59-06494-9EE90DF4; Thu, 07 Jun 2012 12:30:33 +0000
X-Env-Sender: Sergio.Gelato@astro.su.se
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339072233!27215550!1
X-Originating-IP: [130.237.164.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3365 invoked from network); 7 Jun 2012 12:30:33 -0000
Received: from smtp2.su.se (HELO smtp.su.se) (130.237.164.53)
	by server-10.tower-174.messagelabs.com with SMTP;
	7 Jun 2012 12:30:33 -0000
Received: from localhost (localhost [127.0.0.1])
	by smtp.su.se (Postfix) with ESMTP id F2275819DE
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 14:30:32 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at av-in.su.se
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-9999 required=7 tests=[none]
Received: from smtp.su.se ([127.0.0.1])
	by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 2kUhpRtooC45 for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 14:30:32 +0200 (CEST)
Received: from hermes.astro.su.se (hermes.astro.su.se [130.237.166.29])
	by smtp.su.se (Postfix) with SMTP id E30FF819E2
	for <xen-devel@lists.xensource.com>;
	Thu,  7 Jun 2012 14:30:31 +0200 (CEST)
Received: (qmail 31765 invoked from network); 7 Jun 2012 12:30:31 -0000
Received: from ebisu.astro.su.se (HELO localhost) (130.237.166.60)
	by hermes.astro.su.se with SMTP; 7 Jun 2012 12:30:31 -0000
Date: Thu, 7 Jun 2012 14:30:31 +0200
From: Sergio Gelato <Sergio.Gelato@astro.su.se>
To: Andrea Arcangeli <aarcange@redhat.com>
Message-ID: <20120607123031.GB2112@hanuman.astro.su.se>
References: <20120606132012.GB24320@hanuman.astro.su.se>
	<20120606163000.GD9354@burratino>
	<20120607064017.GA2112@hanuman.astro.su.se>
	<20120607073333.GF3210@burratino>
	<20120607103355.GA21339@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607103355.GA21339@redhat.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 08 Jun 2012 10:08:20 +0000
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	xen-devel@lists.xensource.com, 676360@bugs.debian.org
Subject: Re: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* Andrea Arcangeli [2012-06-07 12:33:55 +0200]:
> I guess if Xen can't be updated to handle an atomic64_read on a pmd in
> the guest, 

I'm not sure if it makes a difference, but just in case: I observed the
problem in a dom0.

>            we can add a pmd_read paravirt op? Or if we don't want to
> break the paravirt interface a loop like gup_fast with irq disabled
> should also work but looping + local_irq_disable()/enable() sounded
> worse and more complex than a atomic64_read (gup fast already disables
> irqs because it doesn't hold the mmap_sem so it's a different cost
> looping there). AFIK Xen disables THP during boot, so a check on THP
> being enabled and falling back in the THP=n version of
> pmd_read_atomic, would also be safe, but it's not so nice to do it
> with a runtime check.
> 
> Thanks,
> Andrea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw7C-0003W7-Er; Fri, 08 Jun 2012 10:08:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasonbstubbs@gmail.com>) id 1Scs1H-0006Yp-Hs
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 05:46:00 +0000
Received: from [85.158.139.83:55451] by server-8.bemta-5.messagelabs.com id
	BB/9C-02058-69191DF4; Fri, 08 Jun 2012 05:45:58 +0000
X-Env-Sender: jasonbstubbs@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339134354!32531995!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4443 invoked from network); 8 Jun 2012 05:45:56 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 05:45:56 -0000
Received: by pbbro12 with SMTP id ro12so2219435pbb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 22:45:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=HP8UKG/VSilTGafot5u1E6VaIS3QR/+fX49r38T61/c=;
	b=okFefa0Snc+FReZiiibcwSm34YN2NAcX4+dcaRl1xhIRLaxcdjfl67ZudpxhoL5tkK
	wGcUJcE6wTpuPR4rk92iTyaxbUESHxX3OgLDS2n5OhPtzc7Qo+iDnifkcAYdjZKn2GLL
	F1MeWzXqfUA8NMrr9e0+l64NOYZJQXQ+/qqk3vNUdeESRU9JgNwtrAVvkkTol5o34Ofs
	fejaXh5uqTqfmZdiRkcdrIyvmLB5V/zdsytOiFvk2aaw73hVWKvLXjEkz2m5gyvkZSvQ
	Dw9+67yPH8ky6q0xuWJ5U86ekvm5f5rWcANwJa/YQ3aLlqdh5FIdD23CcQ23edv8pWpI
	BzYg==
Received: by 10.68.213.234 with SMTP id nv10mr16471275pbc.56.1339134354014;
	Thu, 07 Jun 2012 22:45:54 -0700 (PDT)
Received: from Jasons-MacBook-Pro.local
	(ppp59-167-188-156.static.internode.on.net. [59.167.188.156])
	by mx.google.com with ESMTPS id ru4sm6638280pbc.66.2012.06.07.22.45.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 22:45:52 -0700 (PDT)
Message-ID: <4FD1918A.2060908@gmail.com>
Date: Fri, 08 Jun 2012 15:45:46 +1000
From: Jason Stubbs <jasonbstubbs@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 08 Jun 2012 10:08:20 +0000
Subject: [Xen-devel] PROBLEM: Possible race between  xen, md, dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

To quickly summarize, on a Xen domU instance with a disk structure of XFS on
LVM2 on RAID10 on 8x virtual disks, all tasks performing I/O to said XFS
partition hung and I cannot prove or disprove it to be dom0 issue.

And now the long(er) version:

On an Amazon EC2 (xen) instance, I had I/O to one of the EBS (Elastic Block
Store virtual disk) devices block with iostat showing one single request
pending. Kernel logs showed hung tasks so after grabbing those I reset the
instance but - while I'm told that Amazon's logs don't show any problems
with the EBS - Amazon want the opportunity to exclude an EBS problem by
examining things from the dom0 side while the problem is occurring before
delving into the kernel.

So what I'm really hoping for is for somebody to take a look at the call
stacks of the hung tasks and rule in/out a race condition. The kernel is
linux-2.6.35.14-106.53.amzn1 but I've resolved the call stack to the source
using gdb "list *(...)" as described in http://ds9a.nl/symoops.html. If it's
needed, I'll send the relevant parts (or all of it) in a separate mail as
it'll make this one too big.

I'm sending to xen-devel as I'd think XFS on LVM2 on RAID10 would be not so
uncommon, so I'd say Xen has something to do with it if there is in fact a
race condition.

I think that covers everything. Thanks in advance to anybody who takes the
time to glance at this. Please ensure my mail address is included in replies
as I am not subscribed.


Firstly, the hung task information:

INFO: task md127_raid10:967 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
md127_raid10  D ffff88000ab98200     0   967      2 0x00000000
 ffff880882801c40 0000000000000246 0000000000000000 0000000000014200
 ffff880882801fd8 0000000000014200 ffff880882801fd8 ffff8808828b1690
 0000000000014200 0000000000014200 ffff880882801fd8 0000000000014200
Call Trace:
 [<ffffffff8124f211>] md_super_wait+0xd1/0xf0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8124f7c8>] md_update_sb+0x268/0x3e0
 [<ffffffff813192b9>] ? _raw_spin_unlock_irqrestore+0x19/0x20
 [<ffffffff81253cca>] md_check_recovery+0x21a/0x540
 [<ffffffffa0014a57>] raid10d+0x47/0x920 [raid10]
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff8100766f>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff813192b9>] ? _raw_spin_unlock_irqrestore+0x19/0x20
 [<ffffffff8124ef56>] md_thread+0x116/0x150
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8124ee40>] ? md_thread+0x0/0x150
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10

INFO: task kdmflush:1004 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kdmflush      D ffff88000abd0200     0  1004      2 0x00000000
 ffff880882ff5d30 0000000000000246 0000000000000000 0000000000014200
 ffff880882ff5fd8 0000000000014200 ffff880882ff5fd8 ffff8808828b43b0
 0000000000014200 0000000000014200 ffff880882ff5fd8 0000000000014200
Call Trace:
 [<ffffffff8131738e>] io_schedule+0x6e/0xb0
 [<ffffffffa0002052>] dm_wait_for_completion+0xc2/0x150 [dm_mod]
 [<ffffffff81049650>] ? default_wake_function+0x0/0x10
 [<ffffffffa0002de0>] ? dm_wq_work+0x0/0x1d0 [dm_mod]
 [<ffffffffa0002d8e>] dm_flush+0x1e/0x70 [dm_mod]
 [<ffffffffa0002e22>] dm_wq_work+0x42/0x1d0 [dm_mod]
 [<ffffffffa0002de0>] ? dm_wq_work+0x0/0x1d0 [dm_mod]
 [<ffffffff81064130>] worker_thread+0x160/0x250
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff81063fd0>] ? worker_thread+0x0/0x250
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10

INFO: task xfsbufd/dm-0:1470 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
xfsbufd/dm-0  D ffff88000abd0200     0  1470      2 0x00000000
 ffff88088518fb70 0000000000000246 0000000000000000 0000000000014200
 ffff88088518ffd8 0000000000014200 ffff88088518ffd8 ffff8808853b9690
 0000000000014200 0000000000014200 ffff88088518ffd8 0000000000014200
Call Trace:
 [<ffffffff8124d95d>] md_write_start+0xad/0x1d0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00162b0>] make_request+0x70/0x530 [raid10]
 [<ffffffff8124dbc1>] md_make_request+0xc1/0x220
 [<ffffffffa00030a1>] ? dm_request+0xf1/0x230 [dm_mod]
 [<ffffffff81198bf3>] generic_make_request+0x1f3/0x3c0
 [<ffffffffa0001e26>] ? dm_get_live_table+0x46/0x60 [dm_mod]
 [<ffffffffa00032fc>] ? dm_merge_bvec+0xbc/0x140 [dm_mod]
 [<ffffffff81198e3f>] submit_bio+0x7f/0x110
 [<ffffffffa0119abc>] _xfs_buf_ioapply+0x18c/0x2c0 [xfs]
 [<ffffffffa011ab51>] xfs_buf_iorequest+0x31/0x80 [xfs]
 [<ffffffffa011b96d>] xfs_bdstrat_cb+0x2d/0x50 [xfs]
 [<ffffffffa011afc2>] xfsbufd+0xe2/0x1a0 [xfs]
 [<ffffffffa011aee0>] ? xfsbufd+0x0/0x1a0 [xfs]
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10

INFO: task mysqld:5207 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
mysqld        D ffff88000abec200     0  5207   4991 0x00000000
 ffff8808836098b8 0000000000000286 0000000000000000 0000000000014200
 ffff880883609fd8 0000000000014200 ffff880883609fd8 ffff880883ae8000
 0000000000014200 0000000000014200 ffff880883609fd8 0000000000014200
Call Trace:
 [<ffffffff813192b9>] ? _raw_spin_unlock_irqrestore+0x19/0x20
 [<ffffffff8124d95d>] md_write_start+0xad/0x1d0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00162b0>] make_request+0x70/0x530 [raid10]
 [<ffffffff8124dbc1>] md_make_request+0xc1/0x220
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffffa00030a1>] ? dm_request+0xf1/0x230 [dm_mod]
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff81198bf3>] generic_make_request+0x1f3/0x3c0
 [<ffffffffa0001e26>] ? dm_get_live_table+0x46/0x60 [dm_mod]
 [<ffffffffa0005aad>] ? linear_merge+0x4d/0x60 [dm_mod]
 [<ffffffffa00032fc>] ? dm_merge_bvec+0xbc/0x140 [dm_mod]
 [<ffffffff81198e3f>] submit_bio+0x7f/0x110
 [<ffffffffa0117732>] xfs_submit_ioend_bio+0x52/0x90 [xfs]
 [<ffffffffa0117821>] xfs_submit_ioend+0xb1/0x110 [xfs]
 [<ffffffffa0118880>] xfs_page_state_convert+0x330/0x6a0 [xfs]
 [<ffffffffa0118d46>] xfs_vm_writepage+0x76/0x110 [xfs]
 [<ffffffff810bfc22>] __writepage+0x12/0x40
 [<ffffffff810c0ccf>] write_cache_pages+0x1cf/0x3f0
 [<ffffffff810bfc10>] ? __writepage+0x0/0x40
 [<ffffffff81007521>] ? xen_clocksource_read+0x21/0x30
 [<ffffffff810c0f0f>] generic_writepages+0x1f/0x30
 [<ffffffffa0117cb8>] xfs_vm_writepages+0x58/0x70 [xfs]
 [<ffffffff810c0f3c>] do_writepages+0x1c/0x30
 [<ffffffff810b8b83>] __filemap_fdatawrite_range+0x53/0x60
 [<ffffffff810b8bea>] filemap_write_and_wait_range+0x5a/0x80
 [<ffffffff8111c9b2>] vfs_fsync_range+0x52/0x90
 [<ffffffff8111ca57>] vfs_fsync+0x17/0x20
 [<ffffffff8111ca95>] do_fsync+0x35/0x60
 [<ffffffff8111caeb>] sys_fsync+0xb/0x10
 [<ffffffff8100ae42>] system_call_fastpath+0x16/0x1b

INFO: task flush-253:0:14617 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
flush-253:0   D ffff88000abd0200     0 14617      2 0x00000000
 ffff880882b07620 0000000000000246 0000000000000000 0000000000014200
 ffff880882b07fd8 0000000000014200 ffff880882b07fd8 ffff8808055643b0
 0000000000014200 0000000000014200 ffff880882b07fd8 0000000000014200
Call Trace:
 [<ffffffff8124d95d>] md_write_start+0xad/0x1d0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00162b0>] make_request+0x70/0x530 [raid10]
 [<ffffffff8124dbc1>] md_make_request+0xc1/0x220
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffffa00030a1>] ? dm_request+0xf1/0x230 [dm_mod]
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff81198bf3>] generic_make_request+0x1f3/0x3c0
 [<ffffffff81007521>] ? xen_clocksource_read+0x21/0x30
 [<ffffffff81198e3f>] submit_bio+0x7f/0x110
 [<ffffffff811189a2>] ? __mark_inode_dirty+0x92/0x170
 [<ffffffffa0117732>] xfs_submit_ioend_bio+0x52/0x90 [xfs]
 [<ffffffffa0117866>] xfs_submit_ioend+0xf6/0x110 [xfs]
 [<ffffffffa0118880>] xfs_page_state_convert+0x330/0x6a0 [xfs]
 [<ffffffffa0118d46>] xfs_vm_writepage+0x76/0x110 [xfs]
 [<ffffffff810bfc22>] __writepage+0x12/0x40
 [<ffffffff810c0ccf>] write_cache_pages+0x1cf/0x3f0
 [<ffffffff810bfc10>] ? __writepage+0x0/0x40
 [<ffffffff810c0f0f>] generic_writepages+0x1f/0x30
 [<ffffffffa0117cb8>] xfs_vm_writepages+0x58/0x70 [xfs]
 [<ffffffff810c0f3c>] do_writepages+0x1c/0x30
 [<ffffffff81117c5a>] writeback_single_inode+0xea/0x3f0
 [<ffffffff811183ad>] writeback_sb_inodes+0x18d/0x270
 [<ffffffff81007521>] ? xen_clocksource_read+0x21/0x30
 [<ffffffff81118c94>] writeback_inodes_wb+0xa4/0x1b0
 [<ffffffff81118feb>] wb_writeback+0x24b/0x2b0
 [<ffffffff8102e568>] ? pvclock_clocksource_read+0x58/0xd0
 [<ffffffff810084f5>] ? xen_spin_lock+0xa5/0x110
 [<ffffffff811191af>] wb_do_writeback+0x15f/0x170
 [<ffffffff8105c6a0>] ? process_timeout+0x0/0x10
 [<ffffffff8111920f>] bdi_writeback_task+0x4f/0x160
 [<ffffffff81068512>] ? bit_waitqueue+0x12/0xc0
 [<ffffffff810cda21>] bdi_start_fn+0x81/0x100
 [<ffffffff810cd9a0>] ? bdi_start_fn+0x0/0x100
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10


And then dmesg output:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.35.14-106.53.amzn1.x86_64 (mockbuild@build-31006.build) (gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC) ) #1 SMP Fri Jan 6 16:20:10 UTC 2012
[    0.000000] Command line: root=LABEL=/ console=hvc0 LANG=en_US.UTF-8 KEYTABLE=us
[    0.000000] Marking TSC unstable due to Xen domain
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 000000088b800000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x88b800 max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
[    0.000000]  0000000000 - 0100000000 page 4k
[    0.000000] kernel direct mapping tables up to 100000000 @ 100000-905000
[    0.000000] init_memory_mapping: 0000000100000000-000000088b800000
[    0.000000]  0100000000 - 088b800000 page 4k
[    0.000000] kernel direct mapping tables up to 88b800000 @ 6ed9000-b359000
[    0.000000] RAMDISK: 0185a000 - 02a3f000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-000000088b800000
[    0.000000] Initmem setup node 0 0000000000000000-000000088b800000
[    0.000000]   NODE_DATA [0000000100000000 - 0000000100004fff]
[    0.000000] early_res array is doubled to 64 at [7000 - 77ff]
[    0.000000] early_res array is doubled to 128 at [7800 - 87ff]
[    0.000000] early_res array is doubled to 256 at [8800 - a7ff]
[    0.000000] early_res array is doubled to 512 at [a800 - e7ff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000001 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x0088b800
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000001 -> 0x000000a0
[    0.000000]     0: 0x00000100 -> 0x0088b800
[    0.000000] On node 0 totalpages: 8959903
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3943 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: 108164 pages used for memmap
[    0.000000]   Normal zone: 7803260 pages, LIFO batch:31
[    0.000000] SMP: Allowing 4 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] PCI: Warning: Cannot find a gap in the 32bit address range
[    0.000000] PCI: Unassigned devices with 32bit resource registers may break!
[    0.000000] Allocating PCI resources starting at 88b900000 (gap: 88b900000:400000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88000ab84000 s85568 r8192 d20928 u114688
[    0.000000] pcpu-alloc: s85568 r8192 d20928 u114688 alloc=28*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] trying to map vcpu_info 0 at ffff88000ab8f020, mfn e1df7f, offset 32
[    0.000000] cpu 0 using vcpu_info at ffff88000ab8f020
[    0.000000] trying to map vcpu_info 1 at ffff88000abab020, mfn e1df63, offset 32
[    0.000000] cpu 1 using vcpu_info at ffff88000abab020
[    0.000000] trying to map vcpu_info 2 at ffff88000abc7020, mfn e1df47, offset 32
[    0.000000] cpu 2 using vcpu_info at ffff88000abc7020
[    0.000000] trying to map vcpu_info 3 at ffff88000abe3020, mfn e1df2b, offset 32
[    0.000000] cpu 3 using vcpu_info at ffff88000abe3020
[    0.000000] Xen: using vcpu_info placement
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8837403
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=LABEL=/ console=hvc0 LANG=en_US.UTF-8 KEYTABLE=us
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Subtract (281 early reservations)
[    0.000000]   #1 [0006e9e000 - 0006ed9000]  XEN PAGETABLES
[    0.000000]   #2 [0001000000 - 00018389d0]   TEXT DATA BSS
[    0.000000]   #3 [000185a000 - 0002a3f000]         RAMDISK
[    0.000000]   #4 [0002a3f000 - 0006e9e000]  XEN START INFO
[    0.000000]   #5 [0000001000 - 0000003000]      TRAMPOLINE
[    0.000000]   #6 [0000003000 - 0000007000]     ACPI WAKEUP
[    0.000000]   #7 [0000100000 - 00008c7000]         PGTABLE
[    0.000000]   #8 [0006ed9000 - 000ab54000]         PGTABLE
[    0.000000]   #9 [0100000000 - 0100005000]       NODE_DATA
[    0.000000]   #10 [0001838a00 - 0001839a00]         BOOTMEM
[    0.000000]   #11 [0001839a00 - 000183aa00]         BOOTMEM
[    0.000000]   #12 [000183aa00 - 000183bb20]         BOOTMEM
[    0.000000]   #13 [0100005000 - 0100006000]         BOOTMEM
[    0.000000]   #14 [0100006000 - 0100007000]         BOOTMEM
[    0.000000]   #15 [0100007000 - 0100008000]         BOOTMEM
[    0.000000]   #16 [0100008000 - 0100009000]         BOOTMEM
[    0.000000]   #17 [0100009000 - 010000a000]         BOOTMEM
[    0.000000]   #18 [010000a000 - 010000b000]         BOOTMEM
[    0.000000]   #19 [010000b000 - 010000c000]         BOOTMEM
[    0.000000]   #20 [010000c000 - 010000d000]         BOOTMEM
[    0.000000]   #21 [010000d000 - 010000e000]         BOOTMEM
[    0.000000]   #22 [010000e000 - 010000f000]         BOOTMEM
[    0.000000]   #23 [010000f000 - 0100010000]         BOOTMEM
[    0.000000]   #24 [0100010000 - 0100011000]         BOOTMEM
[    0.000000]   #25 [0100011000 - 0100012000]         BOOTMEM
[    0.000000]   #26 [0100012000 - 0100013000]         BOOTMEM
[    0.000000]   #27 [0100013000 - 0100014000]         BOOTMEM
[    0.000000]   #28 [0100014000 - 0100015000]         BOOTMEM
[    0.000000]   #29 [0100015000 - 0100016000]         BOOTMEM
[    0.000000]   #30 [0100016000 - 0100017000]         BOOTMEM
[    0.000000]   #31 [0100017000 - 0100018000]         BOOTMEM
[    0.000000]   #32 [0100018000 - 0100019000]         BOOTMEM
[    0.000000]   #33 [0100019000 - 010001a000]         BOOTMEM
[    0.000000]   #34 [010001a000 - 010001b000]         BOOTMEM
[    0.000000]   #35 [010001b000 - 010001c000]         BOOTMEM
[    0.000000]   #36 [010001c000 - 010001d000]         BOOTMEM
[    0.000000]   #37 [010001d000 - 010001e000]         BOOTMEM
[    0.000000]   #38 [010001e000 - 010001f000]         BOOTMEM
[    0.000000]   #39 [010001f000 - 0100020000]         BOOTMEM
[    0.000000]   #40 [0100020000 - 0100021000]         BOOTMEM
[    0.000000]   #41 [0100021000 - 0100022000]         BOOTMEM
[    0.000000]   #42 [0100022000 - 0100023000]         BOOTMEM
[    0.000000]   #43 [0100023000 - 0100024000]         BOOTMEM
[    0.000000]   #44 [0100024000 - 0100025000]         BOOTMEM
[    0.000000]   #45 [0100025000 - 0100026000]         BOOTMEM
[    0.000000]   #46 [0100026000 - 0100027000]         BOOTMEM
[    0.000000]   #47 [0100027000 - 0100028000]         BOOTMEM
[    0.000000]   #48 [0100028000 - 0100029000]         BOOTMEM
[    0.000000]   #49 [0100029000 - 010002a000]         BOOTMEM
[    0.000000]   #50 [010002a000 - 010002b000]         BOOTMEM
[    0.000000]   #51 [010002b000 - 010002c000]         BOOTMEM
[    0.000000]   #52 [010002c000 - 010002d000]         BOOTMEM
[    0.000000]   #53 [010002d000 - 010002e000]         BOOTMEM
[    0.000000]   #54 [010002e000 - 010002f000]         BOOTMEM
[    0.000000]   #55 [010002f000 - 0100030000]         BOOTMEM
[    0.000000]   #56 [0100030000 - 0100031000]         BOOTMEM
[    0.000000]   #57 [0100031000 - 0100032000]         BOOTMEM
[    0.000000]   #58 [0100032000 - 0100033000]         BOOTMEM
[    0.000000]   #59 [0100033000 - 0100034000]         BOOTMEM
[    0.000000]   #60 [0100034000 - 0100035000]         BOOTMEM
[    0.000000]   #61 [0100035000 - 0100036000]         BOOTMEM
[    0.000000]   #62 [0100036000 - 0100037000]         BOOTMEM
[    0.000000]   #63 [0100037000 - 0100038000]         BOOTMEM
[    0.000000]   #64 [0100038000 - 0100039000]         BOOTMEM
[    0.000000]   #65 [0100039000 - 010003a000]         BOOTMEM
[    0.000000]   #66 [010003a000 - 010003b000]         BOOTMEM
[    0.000000]   #67 [010003b000 - 010003c000]         BOOTMEM
[    0.000000]   #68 [010003c000 - 010003d000]         BOOTMEM
[    0.000000]   #69 [010003d000 - 010003e000]         BOOTMEM
[    0.000000]   #70 [010003e000 - 010003f000]         BOOTMEM
[    0.000000]   #71 [010003f000 - 0100040000]         BOOTMEM
[    0.000000]   #72 [0100040000 - 0100041000]         BOOTMEM
[    0.000000]   #73 [0100041000 - 0100042000]         BOOTMEM
[    0.000000]   #74 [0100042000 - 0100043000]         BOOTMEM
[    0.000000]   #75 [0100043000 - 0100044000]         BOOTMEM
[    0.000000]   #76 [0100044000 - 0100045000]         BOOTMEM
[    0.000000]   #77 [0100045000 - 0100046000]         BOOTMEM
[    0.000000]   #78 [0100046000 - 0100047000]         BOOTMEM
[    0.000000]   #79 [0100047000 - 0100048000]         BOOTMEM
[    0.000000]   #80 [0100048000 - 0100049000]         BOOTMEM
[    0.000000]   #81 [0100049000 - 010004a000]         BOOTMEM
[    0.000000]   #82 [010004a000 - 010004b000]         BOOTMEM
[    0.000000]   #83 [010004b000 - 010004c000]         BOOTMEM
[    0.000000]   #84 [010004c000 - 010004d000]         BOOTMEM
[    0.000000]   #85 [010004d000 - 010004e000]         BOOTMEM
[    0.000000]   #86 [010004e000 - 010004f000]         BOOTMEM
[    0.000000]   #87 [010004f000 - 0100050000]         BOOTMEM
[    0.000000]   #88 [0100050000 - 0100051000]         BOOTMEM
[    0.000000]   #89 [0100051000 - 0100052000]         BOOTMEM
[    0.000000]   #90 [0100052000 - 0100053000]         BOOTMEM
[    0.000000]   #91 [0100053000 - 0100054000]         BOOTMEM
[    0.000000]   #92 [0100054000 - 0100055000]         BOOTMEM
[    0.000000]   #93 [0100055000 - 0100056000]         BOOTMEM
[    0.000000]   #94 [0100056000 - 0100057000]         BOOTMEM
[    0.000000]   #95 [0100057000 - 0100058000]         BOOTMEM
[    0.000000]   #96 [0100058000 - 0100059000]         BOOTMEM
[    0.000000]   #97 [0100059000 - 010005a000]         BOOTMEM
[    0.000000]   #98 [010005a000 - 010005b000]         BOOTMEM
[    0.000000]   #99 [010005b000 - 010005c000]         BOOTMEM
[    0.000000]   #100 [010005c000 - 010005d000]         BOOTMEM
[    0.000000]   #101 [010005d000 - 010005e000]         BOOTMEM
[    0.000000]   #102 [010005e000 - 010005f000]         BOOTMEM
[    0.000000]   #103 [010005f000 - 0100060000]         BOOTMEM
[    0.000000]   #104 [0100060000 - 0100061000]         BOOTMEM
[    0.000000]   #105 [0100061000 - 0100062000]         BOOTMEM
[    0.000000]   #106 [0100062000 - 0100063000]         BOOTMEM
[    0.000000]   #107 [0100063000 - 0100064000]         BOOTMEM
[    0.000000]   #108 [0100064000 - 0100065000]         BOOTMEM
[    0.000000]   #109 [0100065000 - 0100066000]         BOOTMEM
[    0.000000]   #110 [0100066000 - 0100067000]         BOOTMEM
[    0.000000]   #111 [0100067000 - 0100068000]         BOOTMEM
[    0.000000]   #112 [0100068000 - 0100069000]         BOOTMEM
[    0.000000]   #113 [0100069000 - 010006a000]         BOOTMEM
[    0.000000]   #114 [010006a000 - 010006b000]         BOOTMEM
[    0.000000]   #115 [010006b000 - 010006c000]         BOOTMEM
[    0.000000]   #116 [010006c000 - 010006d000]         BOOTMEM
[    0.000000]   #117 [010006d000 - 010006e000]         BOOTMEM
[    0.000000]   #118 [010006e000 - 010006f000]         BOOTMEM
[    0.000000]   #119 [010006f000 - 0100070000]         BOOTMEM
[    0.000000]   #120 [0100070000 - 0100071000]         BOOTMEM
[    0.000000]   #121 [0100071000 - 0100072000]         BOOTMEM
[    0.000000]   #122 [0100072000 - 0100073000]         BOOTMEM
[    0.000000]   #123 [0100073000 - 0100074000]         BOOTMEM
[    0.000000]   #124 [0100074000 - 0100075000]         BOOTMEM
[    0.000000]   #125 [0100075000 - 0100076000]         BOOTMEM
[    0.000000]   #126 [0100076000 - 0100077000]         BOOTMEM
[    0.000000]   #127 [0100077000 - 0100078000]         BOOTMEM
[    0.000000]   #128 [0100078000 - 0100079000]         BOOTMEM
[    0.000000]   #129 [0100079000 - 010007a000]         BOOTMEM
[    0.000000]   #130 [010007a000 - 010007b000]         BOOTMEM
[    0.000000]   #131 [010007b000 - 010007c000]         BOOTMEM
[    0.000000]   #132 [010007c000 - 010007d000]         BOOTMEM
[    0.000000]   #133 [010007d000 - 010007e000]         BOOTMEM
[    0.000000]   #134 [010007e000 - 010007f000]         BOOTMEM
[    0.000000]   #135 [010007f000 - 0100080000]         BOOTMEM
[    0.000000]   #136 [0100080000 - 0100081000]         BOOTMEM
[    0.000000]   #137 [0100081000 - 0100082000]         BOOTMEM
[    0.000000]   #138 [0100082000 - 0100083000]         BOOTMEM
[    0.000000]   #139 [0100083000 - 0100084000]         BOOTMEM
[    0.000000]   #140 [0100084000 - 0100085000]         BOOTMEM
[    0.000000]   #141 [0100085000 - 0100086000]         BOOTMEM
[    0.000000]   #142 [0100086000 - 0100087000]         BOOTMEM
[    0.000000]   #143 [0100087000 - 0100088000]         BOOTMEM
[    0.000000]   #144 [0100088000 - 0100089000]         BOOTMEM
[    0.000000]   #145 [0100089000 - 010008a000]         BOOTMEM
[    0.000000]   #146 [010008a000 - 010008b000]         BOOTMEM
[    0.000000]   #147 [010008b000 - 010008c000]         BOOTMEM
[    0.000000]   #148 [010008c000 - 010008d000]         BOOTMEM
[    0.000000]   #149 [010008d000 - 010008e000]         BOOTMEM
[    0.000000]   #150 [010008e000 - 010008f000]         BOOTMEM
[    0.000000]   #151 [010008f000 - 0100090000]         BOOTMEM
[    0.000000]   #152 [0100090000 - 0100091000]         BOOTMEM
[    0.000000]   #153 [0100091000 - 0100092000]         BOOTMEM
[    0.000000]   #154 [0100092000 - 0100093000]         BOOTMEM
[    0.000000]   #155 [0100093000 - 0100094000]         BOOTMEM
[    0.000000]   #156 [0100094000 - 0100095000]         BOOTMEM
[    0.000000]   #157 [0100095000 - 0100096000]         BOOTMEM
[    0.000000]   #158 [0100096000 - 0100097000]         BOOTMEM
[    0.000000]   #159 [0100097000 - 0100098000]         BOOTMEM
[    0.000000]   #160 [0100098000 - 0100099000]         BOOTMEM
[    0.000000]   #161 [0100099000 - 010009a000]         BOOTMEM
[    0.000000]   #162 [010009a000 - 010009b000]         BOOTMEM
[    0.000000]   #163 [010009b000 - 010009c000]         BOOTMEM
[    0.000000]   #164 [010009c000 - 010009d000]         BOOTMEM
[    0.000000]   #165 [010009d000 - 010009e000]         BOOTMEM
[    0.000000]   #166 [010009e000 - 010009f000]         BOOTMEM
[    0.000000]   #167 [010009f000 - 01000a0000]         BOOTMEM
[    0.000000]   #168 [01000a0000 - 01000a1000]         BOOTMEM
[    0.000000]   #169 [01000a1000 - 01000a2000]         BOOTMEM
[    0.000000]   #170 [01000a2000 - 01000a3000]         BOOTMEM
[    0.000000]   #171 [01000a3000 - 01000a4000]         BOOTMEM
[    0.000000]   #172 [01000a4000 - 01000a5000]         BOOTMEM
[    0.000000]   #173 [01000a5000 - 01000a6000]         BOOTMEM
[    0.000000]   #174 [01000a6000 - 01000a7000]         BOOTMEM
[    0.000000]   #175 [01000a7000 - 01000a8000]         BOOTMEM
[    0.000000]   #176 [01000a8000 - 01000a9000]         BOOTMEM
[    0.000000]   #177 [01000a9000 - 01000aa000]         BOOTMEM
[    0.000000]   #178 [01000aa000 - 01000ab000]         BOOTMEM
[    0.000000]   #179 [01000ab000 - 01000ac000]         BOOTMEM
[    0.000000]   #180 [01000ac000 - 01000ad000]         BOOTMEM
[    0.000000]   #181 [01000ad000 - 01000ae000]         BOOTMEM
[    0.000000]   #182 [01000ae000 - 01000af000]         BOOTMEM
[    0.000000]   #183 [01000af000 - 01000b0000]         BOOTMEM
[    0.000000]   #184 [01000b0000 - 01000b1000]         BOOTMEM
[    0.000000]   #185 [01000b1000 - 01000b2000]         BOOTMEM
[    0.000000]   #186 [01000b2000 - 01000b3000]         BOOTMEM
[    0.000000]   #187 [01000b3000 - 01000b4000]         BOOTMEM
[    0.000000]   #188 [01000b4000 - 01000b5000]         BOOTMEM
[    0.000000]   #189 [01000b5000 - 01000b6000]         BOOTMEM
[    0.000000]   #190 [01000b6000 - 01000b7000]         BOOTMEM
[    0.000000]   #191 [01000b7000 - 01000b8000]         BOOTMEM
[    0.000000]   #192 [01000b8000 - 01000b9000]         BOOTMEM
[    0.000000]   #193 [01000b9000 - 01000ba000]         BOOTMEM
[    0.000000]   #194 [01000ba000 - 01000bb000]         BOOTMEM
[    0.000000]   #195 [01000bb000 - 01000bc000]         BOOTMEM
[    0.000000]   #196 [01000bc000 - 01000bd000]         BOOTMEM
[    0.000000]   #197 [01000bd000 - 01000be000]         BOOTMEM
[    0.000000]   #198 [01000be000 - 01000bf000]         BOOTMEM
[    0.000000]   #199 [01000bf000 - 01000c0000]         BOOTMEM
[    0.000000]   #200 [01000c0000 - 01000c1000]         BOOTMEM
[    0.000000]   #201 [01000c1000 - 01000c2000]         BOOTMEM
[    0.000000]   #202 [01000c2000 - 01000c3000]         BOOTMEM
[    0.000000]   #203 [01000c3000 - 01000c4000]         BOOTMEM
[    0.000000]   #204 [01000c4000 - 01000c5000]         BOOTMEM
[    0.000000]   #205 [01000c5000 - 01000c6000]         BOOTMEM
[    0.000000]   #206 [01000c6000 - 01000c7000]         BOOTMEM
[    0.000000]   #207 [01000c7000 - 01000c8000]         BOOTMEM
[    0.000000]   #208 [01000c8000 - 01000c9000]         BOOTMEM
[    0.000000]   #209 [01000c9000 - 01000ca000]         BOOTMEM
[    0.000000]   #210 [01000ca000 - 01000cb000]         BOOTMEM
[    0.000000]   #211 [01000cb000 - 01000cc000]         BOOTMEM
[    0.000000]   #212 [01000cc000 - 01000cd000]         BOOTMEM
[    0.000000]   #213 [01000cd000 - 01000ce000]         BOOTMEM
[    0.000000]   #214 [01000ce000 - 01000cf000]         BOOTMEM
[    0.000000]   #215 [01000cf000 - 01000d0000]         BOOTMEM
[    0.000000]   #216 [01000d0000 - 01000d1000]         BOOTMEM
[    0.000000]   #217 [01000d1000 - 01000d2000]         BOOTMEM
[    0.000000]   #218 [01000d2000 - 01000d3000]         BOOTMEM
[    0.000000]   #219 [01000d3000 - 01000d4000]         BOOTMEM
[    0.000000]   #220 [01000d4000 - 01000d5000]         BOOTMEM
[    0.000000]   #221 [01000d5000 - 01000d6000]         BOOTMEM
[    0.000000]   #222 [01000d6000 - 01000d7000]         BOOTMEM
[    0.000000]   #223 [01000d7000 - 01000d8000]         BOOTMEM
[    0.000000]   #224 [01000d8000 - 01000d9000]         BOOTMEM
[    0.000000]   #225 [01000d9000 - 01000da000]         BOOTMEM
[    0.000000]   #226 [01000da000 - 01000db000]         BOOTMEM
[    0.000000]   #227 [01000db000 - 01000dc000]         BOOTMEM
[    0.000000]   #228 [01000dc000 - 01000dd000]         BOOTMEM
[    0.000000]   #229 [01000dd000 - 01000de000]         BOOTMEM
[    0.000000]   #230 [01000de000 - 01000df000]         BOOTMEM
[    0.000000]   #231 [01000df000 - 01000e0000]         BOOTMEM
[    0.000000]   #232 [01000e0000 - 01000e1000]         BOOTMEM
[    0.000000]   #233 [01000e1000 - 01000e2000]         BOOTMEM
[    0.000000]   #234 [01000e2000 - 01000e3000]         BOOTMEM
[    0.000000]   #235 [01000e3000 - 01000e4000]         BOOTMEM
[    0.000000]   #236 [01000e4000 - 01000e5000]         BOOTMEM
[    0.000000]   #237 [01000e5000 - 01000e6000]         BOOTMEM
[    0.000000]   #238 [01000e6000 - 01000e7000]         BOOTMEM
[    0.000000]   #239 [01000e7000 - 01000e8000]         BOOTMEM
[    0.000000]   #240 [01000e8000 - 01000e9000]         BOOTMEM
[    0.000000]   #241 [01000e9000 - 01000ea000]         BOOTMEM
[    0.000000]   #242 [01000ea000 - 01000eb000]         BOOTMEM
[    0.000000]   #243 [01000eb000 - 01000ec000]         BOOTMEM
[    0.000000]   #244 [01000ec000 - 01000ed000]         BOOTMEM
[    0.000000]   #245 [01000ed000 - 01000ee000]         BOOTMEM
[    0.000000]   #246 [01000ee000 - 01000ef000]         BOOTMEM
[    0.000000]   #247 [01000ef000 - 01000f0000]         BOOTMEM
[    0.000000]   #248 [01000f0000 - 01000f1000]         BOOTMEM
[    0.000000]   #249 [01000f1000 - 01000f2000]         BOOTMEM
[    0.000000]   #250 [01000f2000 - 01000f3000]         BOOTMEM
[    0.000000]   #251 [01000f3000 - 01000f4000]         BOOTMEM
[    0.000000]   #252 [01000f4000 - 01000f5000]         BOOTMEM
[    0.000000]   #253 [01000f5000 - 01000f6000]         BOOTMEM
[    0.000000]   #254 [01000f6000 - 01000f7000]         BOOTMEM
[    0.000000]   #255 [0100200000 - 011e180000]        MEMMAP 0
[    0.000000]   #256 [000183bb40 - 0001853b40]         BOOTMEM
[    0.000000]   #257 [000ab54000 - 000ab6c000]         BOOTMEM
[    0.000000]   #258 [000ab6c000 - 000ab84000]         BOOTMEM
[    0.000000]   #259 [0001854000 - 0001855000]         BOOTMEM
[    0.000000]   #260 [0001855000 - 0001856000]         BOOTMEM
[    0.000000]   #261 [0001856000 - 0001857000]         BOOTMEM
[    0.000000]   #262 [0001853b40 - 0001853c20]         BOOTMEM
[    0.000000]   #263 [0001853c40 - 0001853ca8]         BOOTMEM
[    0.000000]   #264 [0001853cc0 - 0001853d28]         BOOTMEM
[    0.000000]   #265 [0001853d40 - 0001853da8]         BOOTMEM
[    0.000000]   #266 [0001853dc0 - 0001853df7]         BOOTMEM
[    0.000000]   #267 [0001853e00 - 0001853e37]         BOOTMEM
[    0.000000]   #268 [000ab84000 - 000abf4000]         BOOTMEM
[    0.000000]   #269 [0001853e40 - 0001853e48]         BOOTMEM
[    0.000000]   #270 [0001853e80 - 0001853e88]         BOOTMEM
[    0.000000]   #271 [0001853ec0 - 0001853ed0]         BOOTMEM
[    0.000000]   #272 [0001853f00 - 0001853f20]         BOOTMEM
[    0.000000]   #273 [0001859000 - 0001859100]         BOOTMEM
[    0.000000]   #274 [0001853f40 - 0001853f88]         BOOTMEM
[    0.000000]   #275 [0001859100 - 0001859148]         BOOTMEM
[    0.000000]   #276 [000abf4000 - 000abfc000]         BOOTMEM
[    0.000000]   #277 [000abfc000 - 000ebfc000]         BOOTMEM
[    0.000000]   #278 [000ebfc000 - 000ec1c000]         BOOTMEM
[    0.000000]   #279 [000ec1c000 - 000ec5c000]         BOOTMEM
[    0.000000]   #280 [000000e800 - 0000016800]         BOOTMEM
[    0.000000] Memory: 35113952k/35840000k available (3206k kernel code, 388k absent, 725660k reserved, 3713k data, 500k init)
[    0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] 	RCU-based detection of stalled CPUs is disabled.
[    0.000000] 	Verbose stalled-CPUs detection is disabled.
[    0.000000] NR_IRQS:4352 nr_irqs:304
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] Detected 2666.760 MHz processor.
[    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 5333.52 BogoMIPS (lpj=2666760)
[    0.000999] pid_max: default: 32768 minimum: 301
[    0.000999] Security Framework initialized
[    0.000999] SELinux:  Disabled at boot.
[    0.005404] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
[    0.020712] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    0.028351] Mount-cache hash table entries: 256
[    0.028548] Initializing cgroup subsys ns
[    0.028556] Initializing cgroup subsys cpuacct
[    0.028564] Initializing cgroup subsys devices
[    0.028571] Initializing cgroup subsys freezer
[    0.028618] CPU: Unsupported number of siblings 16
[    0.028624] Performance Events: unsupported p6 CPU model 26 no PMU driver, software events only.
[    0.028704] SMP alternatives: switching to UP code
[    0.029073] cpu 0 spinlock event irq 1
[    0.029261] installing Xen timer for CPU 1
[    0.029274] cpu 1 spinlock event irq 7
[    0.029299] SMP alternatives: switching to SMP code
[    0.000999] CPU: Unsupported number of siblings 16
[    0.030203] installing Xen timer for CPU 2
[    0.030224] cpu 2 spinlock event irq 13
[    0.030254]   alloc irq_desc for 16 on node 0
[    0.030257]   alloc kstat_irqs on node 0
[    0.030264]   alloc irq_desc for 17 on node 0
[    0.030267]   alloc kstat_irqs on node 0
[    0.000999] CPU: Unsupported number of siblings 16
[    0.030449] installing Xen timer for CPU 3
[    0.030459]   alloc irq_desc for 18 on node 0
[    0.030462]   alloc kstat_irqs on node 0
[    0.030468]   alloc irq_desc for 19 on node 0
[    0.030471]   alloc kstat_irqs on node 0
[    0.030477] cpu 3 spinlock event irq 19
[    0.030496]   alloc irq_desc for 20 on node 0
[    0.030498]   alloc kstat_irqs on node 0
[    0.030505]   alloc irq_desc for 21 on node 0
[    0.030507]   alloc kstat_irqs on node 0
[    0.030514]   alloc irq_desc for 22 on node 0
[    0.030516]   alloc kstat_irqs on node 0
[    0.030522]   alloc irq_desc for 23 on node 0
[    0.030524]   alloc kstat_irqs on node 0
[    0.000999] CPU: Unsupported number of siblings 16
[    0.030604] Brought up 4 CPUs
[    0.030612] sizeof(vma)=184 bytes
[    0.030614] sizeof(page)=56 bytes
[    0.030617] sizeof(inode)=616 bytes
[    0.030619] sizeof(dentry)=192 bytes
[    0.030622] sizeof(ext3inode)=832 bytes
[    0.030625] sizeof(buffer_head)=104 bytes
[    0.030627] sizeof(skbuff)=232 bytes
[    0.030630] sizeof(task_struct)=5776 bytes
[    0.030705] devtmpfs: initialized
[    0.049732] Grant table initialized
[    0.049732] NET: Registered protocol family 16
[    0.050023]   alloc irq_desc for 24 on node 0
[    0.050023]   alloc kstat_irqs on node 0
[    0.050055] PCI: Fatal: No config space access function found
[    0.056041] bio: create slab <bio-0> at 0
[    0.056056] ACPI: Interpreter disabled.
[    0.056056] xen_balloon: Initialising balloon driver.
[    0.057206] vgaarb: loaded
[    0.057206] PCI: System does not support PCI
[    0.057206] PCI: System does not support PCI
[    0.058024] NetLabel: Initializing
[    0.058028] NetLabel:  domain hash size = 128
[    0.058032] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.058050] NetLabel:  unlabeled traffic allowed by default
[    0.058231] Switching to clocksource xen
[    0.058242] pnp: PnP ACPI: disabled
[    0.064983] NET: Registered protocol family 2
[    0.065724] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.067725] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.069338] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.069527] TCP: Hash tables configured (established 524288 bind 65536)
[    0.069534] TCP reno registered
[    0.069735] UDP hash table entries: 32768 (order: 8, 1048576 bytes)
[    0.070086] UDP-Lite hash table entries: 32768 (order: 8, 1048576 bytes)
[    0.070377] NET: Registered protocol family 1
[    0.070391] PCI: CLS 0 bytes, default 64
[    0.070452] Unpacking initramfs...
[    0.093561] Freeing initrd memory: 18324k freed
[    0.098828] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.098844] Placing 64MB software IO TLB between ffff88000abfc000 - ffff88000ebfc000
[    0.098850] software IO TLB at phys 0xabfc000 - 0xebfc000
[    0.099483] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.102533] audit: initializing netlink socket (disabled)
[    0.102554] type=2000 audit(1338184539.000:1): initialized
[    0.119492] VFS: Disk quotas dquot_6.5.2
[    0.119601] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.119671] msgmni has been set to 32768
[    0.120289] alg: No test for stdrng (krng)
[    0.120461] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[    0.121449] io scheduler noop registered (default)
[    0.153417]   alloc irq_desc for 25 on node 0
[    0.153420]   alloc kstat_irqs on node 0
[    0.154172] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.156832] loop: module loaded
[    0.157217]   alloc irq_desc for 26 on node 0
[    0.157221]   alloc kstat_irqs on node 0
[    0.158591]   alloc irq_desc for 27 on node 0
[    0.158594]   alloc kstat_irqs on node 0
[    0.160859]   alloc irq_desc for 28 on node 0
[    0.160862]   alloc kstat_irqs on node 0
[    0.164045]   alloc irq_desc for 29 on node 0
[    0.164049]   alloc kstat_irqs on node 0
[    0.167433]   alloc irq_desc for 30 on node 0
[    0.167437]   alloc kstat_irqs on node 0
[    0.170735]   alloc irq_desc for 31 on node 0
[    0.170738]   alloc kstat_irqs on node 0
[    0.175135]   alloc irq_desc for 32 on node 0
[    0.175139]   alloc kstat_irqs on node 0
[    0.178564]   alloc irq_desc for 33 on node 0
[    0.178569]   alloc kstat_irqs on node 0
[    0.182198]   alloc irq_desc for 34 on node 0
[    0.182203]   alloc kstat_irqs on node 0
[    0.184058] Initialising Xen virtual ethernet driver.
[    0.185857] blkfront: regular deviceid=0x801 major,minor=8,1, assuming parts/disk=16
[    0.188580] blkfront: regular deviceid=0x855 major,minor=8,85, assuming parts/disk=16
[    0.189479] PNP: No PS/2 controller found. Probing ports directly.
[    0.190535] mice: PS/2 mouse device common for all mice
[    0.190634] cpuidle: using governor ladder
[    0.190640] cpuidle: using governor menu
[    0.190715] TCP cubic registered
[    0.190722] NET: Registered protocol family 17
[    0.190842] blkfront: regular deviceid=0x856 major,minor=8,86, assuming parts/disk=16
[    0.191095] registered taskstats version 1
[    0.191761] blkfront: regular deviceid=0x857 major,minor=8,87, assuming parts/disk=16
[    0.192561] blkfront: regular deviceid=0x858 major,minor=8,88, assuming parts/disk=16
[    0.193397] blkfront: regular deviceid=0x851 major,minor=8,81, assuming parts/disk=16
[    0.194274] blkfront: regular deviceid=0x852 major,minor=8,82, assuming parts/disk=16
[    0.195039] blkfront: regular deviceid=0x853 major,minor=8,83, assuming parts/disk=16
[    0.195888] blkfront: regular deviceid=0x854 major,minor=8,84, assuming parts/disk=16
[    0.196588]   alloc irq_desc for 35 on node 0
[    0.196591]   alloc kstat_irqs on node 0
[    0.291074] XENBUS: Device with no driver: device/console/0
[    0.291315] Freeing unused kernel memory: 500k freed
[    0.291457] Write protecting the kernel read-only data: 6144k
[    0.294260] Freeing unused kernel memory: 872k freed
[    0.294770] Freeing unused kernel memory: 772k freed
[    0.338850] device-mapper: uevent: version 1.0.3
[    0.339070] device-mapper: ioctl: 4.19.1-ioctl (2010-10-12) initialised: dm-devel@redhat.com
[    0.347400] udev: starting version 147
[    0.464874] md: bind<xvdf8>
[    0.474746] md: bind<xvdf7>
[    0.482043] md: bind<xvdf4>
[    0.540137] md: bind<xvdf3>
[    0.548545] md: bind<xvdf5>
[    0.558959] md: bind<xvdf2>
[    0.590210] md: bind<xvdf6>
[    0.605807] md: bind<xvdf1>
[    0.617615] md: raid10 personality registered for level 10
[    0.617973] md/raid10:md127: active with 8 out of 8 devices
[    0.618052] md127: detected capacity change from 0 to 42944430080
[    0.619764]  md127: unknown partition table
[    0.853476] dracut: Scanning devices md127  for LVM volume groups 
[    0.952821] dracut: Reading all physical volumes. This may take a while...
[    0.952917] dracut: Found volume group "lvm" using metadata type lvm2
[    1.001982] dracut: /dev/mapper/lvm-mysql not set up by udev: Falling back to direct node creation.
[    1.002490] dracut: The link /dev/lvm/mysql should had been created by udev but it was not found. Falling back to direct link creation.
[    1.002901] dracut: 1 logical volume(s) in volume group "lvm" now active
[    1.009194] dracut: Assembling MD RAID arrays
[    1.522720] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    1.714045] dracut: Remounting /dev/disk/by-label/\x2f with -o noatime,ro
[    1.724168] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    1.731079] dracut: Mounted root filesystem /dev/xvda1
[    2.074312] dracut: Loading SELinux policy
[    4.435236] dracut: /sbin/load_policy: Can't load policy: No such device
[    4.497683] dracut: Switching root
[    7.536918] usbcore: registered new interface driver usbfs
[    7.537147] usbcore: registered new interface driver hub
[    7.537356] usbcore: registered new device driver usb
[    9.689524] udev: starting version 147
[   10.573499] rtc_cmos: probe of rtc_cmos failed with error -16
[   15.475706] EXT4-fs (xvda1): re-mounted. Opts: (null)
[   15.887250] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[   15.889278] SGI XFS Quota Management subsystem
[   15.893832] XFS mounting filesystem dm-0
[   16.415440] Ending clean XFS mount for filesystem: dm-0
[   16.927608] Adding 1048572k swap on /.swapfile.  Priority:-1 extents:4 across:1073148k SS


--
Regards,
Jason Stubbs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1Scw7C-0003W7-Er; Fri, 08 Jun 2012 10:08:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasonbstubbs@gmail.com>) id 1Scs1H-0006Yp-Hs
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 05:46:00 +0000
Received: from [85.158.139.83:55451] by server-8.bemta-5.messagelabs.com id
	BB/9C-02058-69191DF4; Fri, 08 Jun 2012 05:45:58 +0000
X-Env-Sender: jasonbstubbs@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339134354!32531995!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4443 invoked from network); 8 Jun 2012 05:45:56 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 05:45:56 -0000
Received: by pbbro12 with SMTP id ro12so2219435pbb.32
	for <xen-devel@lists.xen.org>; Thu, 07 Jun 2012 22:45:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=HP8UKG/VSilTGafot5u1E6VaIS3QR/+fX49r38T61/c=;
	b=okFefa0Snc+FReZiiibcwSm34YN2NAcX4+dcaRl1xhIRLaxcdjfl67ZudpxhoL5tkK
	wGcUJcE6wTpuPR4rk92iTyaxbUESHxX3OgLDS2n5OhPtzc7Qo+iDnifkcAYdjZKn2GLL
	F1MeWzXqfUA8NMrr9e0+l64NOYZJQXQ+/qqk3vNUdeESRU9JgNwtrAVvkkTol5o34Ofs
	fejaXh5uqTqfmZdiRkcdrIyvmLB5V/zdsytOiFvk2aaw73hVWKvLXjEkz2m5gyvkZSvQ
	Dw9+67yPH8ky6q0xuWJ5U86ekvm5f5rWcANwJa/YQ3aLlqdh5FIdD23CcQ23edv8pWpI
	BzYg==
Received: by 10.68.213.234 with SMTP id nv10mr16471275pbc.56.1339134354014;
	Thu, 07 Jun 2012 22:45:54 -0700 (PDT)
Received: from Jasons-MacBook-Pro.local
	(ppp59-167-188-156.static.internode.on.net. [59.167.188.156])
	by mx.google.com with ESMTPS id ru4sm6638280pbc.66.2012.06.07.22.45.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 07 Jun 2012 22:45:52 -0700 (PDT)
Message-ID: <4FD1918A.2060908@gmail.com>
Date: Fri, 08 Jun 2012 15:45:46 +1000
From: Jason Stubbs <jasonbstubbs@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 08 Jun 2012 10:08:20 +0000
Subject: [Xen-devel] PROBLEM: Possible race between  xen, md, dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

To quickly summarize, on a Xen domU instance with a disk structure of XFS on
LVM2 on RAID10 on 8x virtual disks, all tasks performing I/O to said XFS
partition hung and I cannot prove or disprove it to be dom0 issue.

And now the long(er) version:

On an Amazon EC2 (xen) instance, I had I/O to one of the EBS (Elastic Block
Store virtual disk) devices block with iostat showing one single request
pending. Kernel logs showed hung tasks so after grabbing those I reset the
instance but - while I'm told that Amazon's logs don't show any problems
with the EBS - Amazon want the opportunity to exclude an EBS problem by
examining things from the dom0 side while the problem is occurring before
delving into the kernel.

So what I'm really hoping for is for somebody to take a look at the call
stacks of the hung tasks and rule in/out a race condition. The kernel is
linux-2.6.35.14-106.53.amzn1 but I've resolved the call stack to the source
using gdb "list *(...)" as described in http://ds9a.nl/symoops.html. If it's
needed, I'll send the relevant parts (or all of it) in a separate mail as
it'll make this one too big.

I'm sending to xen-devel as I'd think XFS on LVM2 on RAID10 would be not so
uncommon, so I'd say Xen has something to do with it if there is in fact a
race condition.

I think that covers everything. Thanks in advance to anybody who takes the
time to glance at this. Please ensure my mail address is included in replies
as I am not subscribed.


Firstly, the hung task information:

INFO: task md127_raid10:967 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
md127_raid10  D ffff88000ab98200     0   967      2 0x00000000
 ffff880882801c40 0000000000000246 0000000000000000 0000000000014200
 ffff880882801fd8 0000000000014200 ffff880882801fd8 ffff8808828b1690
 0000000000014200 0000000000014200 ffff880882801fd8 0000000000014200
Call Trace:
 [<ffffffff8124f211>] md_super_wait+0xd1/0xf0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8124f7c8>] md_update_sb+0x268/0x3e0
 [<ffffffff813192b9>] ? _raw_spin_unlock_irqrestore+0x19/0x20
 [<ffffffff81253cca>] md_check_recovery+0x21a/0x540
 [<ffffffffa0014a57>] raid10d+0x47/0x920 [raid10]
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff8100766f>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff813192b9>] ? _raw_spin_unlock_irqrestore+0x19/0x20
 [<ffffffff8124ef56>] md_thread+0x116/0x150
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8124ee40>] ? md_thread+0x0/0x150
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10

INFO: task kdmflush:1004 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kdmflush      D ffff88000abd0200     0  1004      2 0x00000000
 ffff880882ff5d30 0000000000000246 0000000000000000 0000000000014200
 ffff880882ff5fd8 0000000000014200 ffff880882ff5fd8 ffff8808828b43b0
 0000000000014200 0000000000014200 ffff880882ff5fd8 0000000000014200
Call Trace:
 [<ffffffff8131738e>] io_schedule+0x6e/0xb0
 [<ffffffffa0002052>] dm_wait_for_completion+0xc2/0x150 [dm_mod]
 [<ffffffff81049650>] ? default_wake_function+0x0/0x10
 [<ffffffffa0002de0>] ? dm_wq_work+0x0/0x1d0 [dm_mod]
 [<ffffffffa0002d8e>] dm_flush+0x1e/0x70 [dm_mod]
 [<ffffffffa0002e22>] dm_wq_work+0x42/0x1d0 [dm_mod]
 [<ffffffffa0002de0>] ? dm_wq_work+0x0/0x1d0 [dm_mod]
 [<ffffffff81064130>] worker_thread+0x160/0x250
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff81063fd0>] ? worker_thread+0x0/0x250
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10

INFO: task xfsbufd/dm-0:1470 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
xfsbufd/dm-0  D ffff88000abd0200     0  1470      2 0x00000000
 ffff88088518fb70 0000000000000246 0000000000000000 0000000000014200
 ffff88088518ffd8 0000000000014200 ffff88088518ffd8 ffff8808853b9690
 0000000000014200 0000000000014200 ffff88088518ffd8 0000000000014200
Call Trace:
 [<ffffffff8124d95d>] md_write_start+0xad/0x1d0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00162b0>] make_request+0x70/0x530 [raid10]
 [<ffffffff8124dbc1>] md_make_request+0xc1/0x220
 [<ffffffffa00030a1>] ? dm_request+0xf1/0x230 [dm_mod]
 [<ffffffff81198bf3>] generic_make_request+0x1f3/0x3c0
 [<ffffffffa0001e26>] ? dm_get_live_table+0x46/0x60 [dm_mod]
 [<ffffffffa00032fc>] ? dm_merge_bvec+0xbc/0x140 [dm_mod]
 [<ffffffff81198e3f>] submit_bio+0x7f/0x110
 [<ffffffffa0119abc>] _xfs_buf_ioapply+0x18c/0x2c0 [xfs]
 [<ffffffffa011ab51>] xfs_buf_iorequest+0x31/0x80 [xfs]
 [<ffffffffa011b96d>] xfs_bdstrat_cb+0x2d/0x50 [xfs]
 [<ffffffffa011afc2>] xfsbufd+0xe2/0x1a0 [xfs]
 [<ffffffffa011aee0>] ? xfsbufd+0x0/0x1a0 [xfs]
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10

INFO: task mysqld:5207 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
mysqld        D ffff88000abec200     0  5207   4991 0x00000000
 ffff8808836098b8 0000000000000286 0000000000000000 0000000000014200
 ffff880883609fd8 0000000000014200 ffff880883609fd8 ffff880883ae8000
 0000000000014200 0000000000014200 ffff880883609fd8 0000000000014200
Call Trace:
 [<ffffffff813192b9>] ? _raw_spin_unlock_irqrestore+0x19/0x20
 [<ffffffff8124d95d>] md_write_start+0xad/0x1d0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00162b0>] make_request+0x70/0x530 [raid10]
 [<ffffffff8124dbc1>] md_make_request+0xc1/0x220
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffffa00030a1>] ? dm_request+0xf1/0x230 [dm_mod]
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff81198bf3>] generic_make_request+0x1f3/0x3c0
 [<ffffffffa0001e26>] ? dm_get_live_table+0x46/0x60 [dm_mod]
 [<ffffffffa0005aad>] ? linear_merge+0x4d/0x60 [dm_mod]
 [<ffffffffa00032fc>] ? dm_merge_bvec+0xbc/0x140 [dm_mod]
 [<ffffffff81198e3f>] submit_bio+0x7f/0x110
 [<ffffffffa0117732>] xfs_submit_ioend_bio+0x52/0x90 [xfs]
 [<ffffffffa0117821>] xfs_submit_ioend+0xb1/0x110 [xfs]
 [<ffffffffa0118880>] xfs_page_state_convert+0x330/0x6a0 [xfs]
 [<ffffffffa0118d46>] xfs_vm_writepage+0x76/0x110 [xfs]
 [<ffffffff810bfc22>] __writepage+0x12/0x40
 [<ffffffff810c0ccf>] write_cache_pages+0x1cf/0x3f0
 [<ffffffff810bfc10>] ? __writepage+0x0/0x40
 [<ffffffff81007521>] ? xen_clocksource_read+0x21/0x30
 [<ffffffff810c0f0f>] generic_writepages+0x1f/0x30
 [<ffffffffa0117cb8>] xfs_vm_writepages+0x58/0x70 [xfs]
 [<ffffffff810c0f3c>] do_writepages+0x1c/0x30
 [<ffffffff810b8b83>] __filemap_fdatawrite_range+0x53/0x60
 [<ffffffff810b8bea>] filemap_write_and_wait_range+0x5a/0x80
 [<ffffffff8111c9b2>] vfs_fsync_range+0x52/0x90
 [<ffffffff8111ca57>] vfs_fsync+0x17/0x20
 [<ffffffff8111ca95>] do_fsync+0x35/0x60
 [<ffffffff8111caeb>] sys_fsync+0xb/0x10
 [<ffffffff8100ae42>] system_call_fastpath+0x16/0x1b

INFO: task flush-253:0:14617 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
flush-253:0   D ffff88000abd0200     0 14617      2 0x00000000
 ffff880882b07620 0000000000000246 0000000000000000 0000000000014200
 ffff880882b07fd8 0000000000014200 ffff880882b07fd8 ffff8808055643b0
 0000000000014200 0000000000014200 ffff880882b07fd8 0000000000014200
Call Trace:
 [<ffffffff8124d95d>] md_write_start+0xad/0x1d0
 [<ffffffff81068630>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00162b0>] make_request+0x70/0x530 [raid10]
 [<ffffffff8124dbc1>] md_make_request+0xc1/0x220
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffffa00030a1>] ? dm_request+0xf1/0x230 [dm_mod]
 [<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff81198bf3>] generic_make_request+0x1f3/0x3c0
 [<ffffffff81007521>] ? xen_clocksource_read+0x21/0x30
 [<ffffffff81198e3f>] submit_bio+0x7f/0x110
 [<ffffffff811189a2>] ? __mark_inode_dirty+0x92/0x170
 [<ffffffffa0117732>] xfs_submit_ioend_bio+0x52/0x90 [xfs]
 [<ffffffffa0117866>] xfs_submit_ioend+0xf6/0x110 [xfs]
 [<ffffffffa0118880>] xfs_page_state_convert+0x330/0x6a0 [xfs]
 [<ffffffffa0118d46>] xfs_vm_writepage+0x76/0x110 [xfs]
 [<ffffffff810bfc22>] __writepage+0x12/0x40
 [<ffffffff810c0ccf>] write_cache_pages+0x1cf/0x3f0
 [<ffffffff810bfc10>] ? __writepage+0x0/0x40
 [<ffffffff810c0f0f>] generic_writepages+0x1f/0x30
 [<ffffffffa0117cb8>] xfs_vm_writepages+0x58/0x70 [xfs]
 [<ffffffff810c0f3c>] do_writepages+0x1c/0x30
 [<ffffffff81117c5a>] writeback_single_inode+0xea/0x3f0
 [<ffffffff811183ad>] writeback_sb_inodes+0x18d/0x270
 [<ffffffff81007521>] ? xen_clocksource_read+0x21/0x30
 [<ffffffff81118c94>] writeback_inodes_wb+0xa4/0x1b0
 [<ffffffff81118feb>] wb_writeback+0x24b/0x2b0
 [<ffffffff8102e568>] ? pvclock_clocksource_read+0x58/0xd0
 [<ffffffff810084f5>] ? xen_spin_lock+0xa5/0x110
 [<ffffffff811191af>] wb_do_writeback+0x15f/0x170
 [<ffffffff8105c6a0>] ? process_timeout+0x0/0x10
 [<ffffffff8111920f>] bdi_writeback_task+0x4f/0x160
 [<ffffffff81068512>] ? bit_waitqueue+0x12/0xc0
 [<ffffffff810cda21>] bdi_start_fn+0x81/0x100
 [<ffffffff810cd9a0>] ? bdi_start_fn+0x0/0x100
 [<ffffffff8106816e>] kthread+0x8e/0xa0
 [<ffffffff8100bc64>] kernel_thread_helper+0x4/0x10
 [<ffffffff8100b063>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8131975d>] ? retint_restore_args+0x5/0x6
 [<ffffffff8100bc60>] ? kernel_thread_helper+0x0/0x10


And then dmesg output:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.35.14-106.53.amzn1.x86_64 (mockbuild@build-31006.build) (gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC) ) #1 SMP Fri Jan 6 16:20:10 UTC 2012
[    0.000000] Command line: root=LABEL=/ console=hvc0 LANG=en_US.UTF-8 KEYTABLE=us
[    0.000000] Marking TSC unstable due to Xen domain
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] released 0 pages of unused memory
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 000000088b800000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x88b800 max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
[    0.000000]  0000000000 - 0100000000 page 4k
[    0.000000] kernel direct mapping tables up to 100000000 @ 100000-905000
[    0.000000] init_memory_mapping: 0000000100000000-000000088b800000
[    0.000000]  0100000000 - 088b800000 page 4k
[    0.000000] kernel direct mapping tables up to 88b800000 @ 6ed9000-b359000
[    0.000000] RAMDISK: 0185a000 - 02a3f000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-000000088b800000
[    0.000000] Initmem setup node 0 0000000000000000-000000088b800000
[    0.000000]   NODE_DATA [0000000100000000 - 0000000100004fff]
[    0.000000] early_res array is doubled to 64 at [7000 - 77ff]
[    0.000000] early_res array is doubled to 128 at [7800 - 87ff]
[    0.000000] early_res array is doubled to 256 at [8800 - a7ff]
[    0.000000] early_res array is doubled to 512 at [a800 - e7ff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000001 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x0088b800
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000001 -> 0x000000a0
[    0.000000]     0: 0x00000100 -> 0x0088b800
[    0.000000] On node 0 totalpages: 8959903
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3943 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: 108164 pages used for memmap
[    0.000000]   Normal zone: 7803260 pages, LIFO batch:31
[    0.000000] SMP: Allowing 4 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] PCI: Warning: Cannot find a gap in the 32bit address range
[    0.000000] PCI: Unassigned devices with 32bit resource registers may break!
[    0.000000] Allocating PCI resources starting at 88b900000 (gap: 88b900000:400000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88000ab84000 s85568 r8192 d20928 u114688
[    0.000000] pcpu-alloc: s85568 r8192 d20928 u114688 alloc=28*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] trying to map vcpu_info 0 at ffff88000ab8f020, mfn e1df7f, offset 32
[    0.000000] cpu 0 using vcpu_info at ffff88000ab8f020
[    0.000000] trying to map vcpu_info 1 at ffff88000abab020, mfn e1df63, offset 32
[    0.000000] cpu 1 using vcpu_info at ffff88000abab020
[    0.000000] trying to map vcpu_info 2 at ffff88000abc7020, mfn e1df47, offset 32
[    0.000000] cpu 2 using vcpu_info at ffff88000abc7020
[    0.000000] trying to map vcpu_info 3 at ffff88000abe3020, mfn e1df2b, offset 32
[    0.000000] cpu 3 using vcpu_info at ffff88000abe3020
[    0.000000] Xen: using vcpu_info placement
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8837403
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=LABEL=/ console=hvc0 LANG=en_US.UTF-8 KEYTABLE=us
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Subtract (281 early reservations)
[    0.000000]   #1 [0006e9e000 - 0006ed9000]  XEN PAGETABLES
[    0.000000]   #2 [0001000000 - 00018389d0]   TEXT DATA BSS
[    0.000000]   #3 [000185a000 - 0002a3f000]         RAMDISK
[    0.000000]   #4 [0002a3f000 - 0006e9e000]  XEN START INFO
[    0.000000]   #5 [0000001000 - 0000003000]      TRAMPOLINE
[    0.000000]   #6 [0000003000 - 0000007000]     ACPI WAKEUP
[    0.000000]   #7 [0000100000 - 00008c7000]         PGTABLE
[    0.000000]   #8 [0006ed9000 - 000ab54000]         PGTABLE
[    0.000000]   #9 [0100000000 - 0100005000]       NODE_DATA
[    0.000000]   #10 [0001838a00 - 0001839a00]         BOOTMEM
[    0.000000]   #11 [0001839a00 - 000183aa00]         BOOTMEM
[    0.000000]   #12 [000183aa00 - 000183bb20]         BOOTMEM
[    0.000000]   #13 [0100005000 - 0100006000]         BOOTMEM
[    0.000000]   #14 [0100006000 - 0100007000]         BOOTMEM
[    0.000000]   #15 [0100007000 - 0100008000]         BOOTMEM
[    0.000000]   #16 [0100008000 - 0100009000]         BOOTMEM
[    0.000000]   #17 [0100009000 - 010000a000]         BOOTMEM
[    0.000000]   #18 [010000a000 - 010000b000]         BOOTMEM
[    0.000000]   #19 [010000b000 - 010000c000]         BOOTMEM
[    0.000000]   #20 [010000c000 - 010000d000]         BOOTMEM
[    0.000000]   #21 [010000d000 - 010000e000]         BOOTMEM
[    0.000000]   #22 [010000e000 - 010000f000]         BOOTMEM
[    0.000000]   #23 [010000f000 - 0100010000]         BOOTMEM
[    0.000000]   #24 [0100010000 - 0100011000]         BOOTMEM
[    0.000000]   #25 [0100011000 - 0100012000]         BOOTMEM
[    0.000000]   #26 [0100012000 - 0100013000]         BOOTMEM
[    0.000000]   #27 [0100013000 - 0100014000]         BOOTMEM
[    0.000000]   #28 [0100014000 - 0100015000]         BOOTMEM
[    0.000000]   #29 [0100015000 - 0100016000]         BOOTMEM
[    0.000000]   #30 [0100016000 - 0100017000]         BOOTMEM
[    0.000000]   #31 [0100017000 - 0100018000]         BOOTMEM
[    0.000000]   #32 [0100018000 - 0100019000]         BOOTMEM
[    0.000000]   #33 [0100019000 - 010001a000]         BOOTMEM
[    0.000000]   #34 [010001a000 - 010001b000]         BOOTMEM
[    0.000000]   #35 [010001b000 - 010001c000]         BOOTMEM
[    0.000000]   #36 [010001c000 - 010001d000]         BOOTMEM
[    0.000000]   #37 [010001d000 - 010001e000]         BOOTMEM
[    0.000000]   #38 [010001e000 - 010001f000]         BOOTMEM
[    0.000000]   #39 [010001f000 - 0100020000]         BOOTMEM
[    0.000000]   #40 [0100020000 - 0100021000]         BOOTMEM
[    0.000000]   #41 [0100021000 - 0100022000]         BOOTMEM
[    0.000000]   #42 [0100022000 - 0100023000]         BOOTMEM
[    0.000000]   #43 [0100023000 - 0100024000]         BOOTMEM
[    0.000000]   #44 [0100024000 - 0100025000]         BOOTMEM
[    0.000000]   #45 [0100025000 - 0100026000]         BOOTMEM
[    0.000000]   #46 [0100026000 - 0100027000]         BOOTMEM
[    0.000000]   #47 [0100027000 - 0100028000]         BOOTMEM
[    0.000000]   #48 [0100028000 - 0100029000]         BOOTMEM
[    0.000000]   #49 [0100029000 - 010002a000]         BOOTMEM
[    0.000000]   #50 [010002a000 - 010002b000]         BOOTMEM
[    0.000000]   #51 [010002b000 - 010002c000]         BOOTMEM
[    0.000000]   #52 [010002c000 - 010002d000]         BOOTMEM
[    0.000000]   #53 [010002d000 - 010002e000]         BOOTMEM
[    0.000000]   #54 [010002e000 - 010002f000]         BOOTMEM
[    0.000000]   #55 [010002f000 - 0100030000]         BOOTMEM
[    0.000000]   #56 [0100030000 - 0100031000]         BOOTMEM
[    0.000000]   #57 [0100031000 - 0100032000]         BOOTMEM
[    0.000000]   #58 [0100032000 - 0100033000]         BOOTMEM
[    0.000000]   #59 [0100033000 - 0100034000]         BOOTMEM
[    0.000000]   #60 [0100034000 - 0100035000]         BOOTMEM
[    0.000000]   #61 [0100035000 - 0100036000]         BOOTMEM
[    0.000000]   #62 [0100036000 - 0100037000]         BOOTMEM
[    0.000000]   #63 [0100037000 - 0100038000]         BOOTMEM
[    0.000000]   #64 [0100038000 - 0100039000]         BOOTMEM
[    0.000000]   #65 [0100039000 - 010003a000]         BOOTMEM
[    0.000000]   #66 [010003a000 - 010003b000]         BOOTMEM
[    0.000000]   #67 [010003b000 - 010003c000]         BOOTMEM
[    0.000000]   #68 [010003c000 - 010003d000]         BOOTMEM
[    0.000000]   #69 [010003d000 - 010003e000]         BOOTMEM
[    0.000000]   #70 [010003e000 - 010003f000]         BOOTMEM
[    0.000000]   #71 [010003f000 - 0100040000]         BOOTMEM
[    0.000000]   #72 [0100040000 - 0100041000]         BOOTMEM
[    0.000000]   #73 [0100041000 - 0100042000]         BOOTMEM
[    0.000000]   #74 [0100042000 - 0100043000]         BOOTMEM
[    0.000000]   #75 [0100043000 - 0100044000]         BOOTMEM
[    0.000000]   #76 [0100044000 - 0100045000]         BOOTMEM
[    0.000000]   #77 [0100045000 - 0100046000]         BOOTMEM
[    0.000000]   #78 [0100046000 - 0100047000]         BOOTMEM
[    0.000000]   #79 [0100047000 - 0100048000]         BOOTMEM
[    0.000000]   #80 [0100048000 - 0100049000]         BOOTMEM
[    0.000000]   #81 [0100049000 - 010004a000]         BOOTMEM
[    0.000000]   #82 [010004a000 - 010004b000]         BOOTMEM
[    0.000000]   #83 [010004b000 - 010004c000]         BOOTMEM
[    0.000000]   #84 [010004c000 - 010004d000]         BOOTMEM
[    0.000000]   #85 [010004d000 - 010004e000]         BOOTMEM
[    0.000000]   #86 [010004e000 - 010004f000]         BOOTMEM
[    0.000000]   #87 [010004f000 - 0100050000]         BOOTMEM
[    0.000000]   #88 [0100050000 - 0100051000]         BOOTMEM
[    0.000000]   #89 [0100051000 - 0100052000]         BOOTMEM
[    0.000000]   #90 [0100052000 - 0100053000]         BOOTMEM
[    0.000000]   #91 [0100053000 - 0100054000]         BOOTMEM
[    0.000000]   #92 [0100054000 - 0100055000]         BOOTMEM
[    0.000000]   #93 [0100055000 - 0100056000]         BOOTMEM
[    0.000000]   #94 [0100056000 - 0100057000]         BOOTMEM
[    0.000000]   #95 [0100057000 - 0100058000]         BOOTMEM
[    0.000000]   #96 [0100058000 - 0100059000]         BOOTMEM
[    0.000000]   #97 [0100059000 - 010005a000]         BOOTMEM
[    0.000000]   #98 [010005a000 - 010005b000]         BOOTMEM
[    0.000000]   #99 [010005b000 - 010005c000]         BOOTMEM
[    0.000000]   #100 [010005c000 - 010005d000]         BOOTMEM
[    0.000000]   #101 [010005d000 - 010005e000]         BOOTMEM
[    0.000000]   #102 [010005e000 - 010005f000]         BOOTMEM
[    0.000000]   #103 [010005f000 - 0100060000]         BOOTMEM
[    0.000000]   #104 [0100060000 - 0100061000]         BOOTMEM
[    0.000000]   #105 [0100061000 - 0100062000]         BOOTMEM
[    0.000000]   #106 [0100062000 - 0100063000]         BOOTMEM
[    0.000000]   #107 [0100063000 - 0100064000]         BOOTMEM
[    0.000000]   #108 [0100064000 - 0100065000]         BOOTMEM
[    0.000000]   #109 [0100065000 - 0100066000]         BOOTMEM
[    0.000000]   #110 [0100066000 - 0100067000]         BOOTMEM
[    0.000000]   #111 [0100067000 - 0100068000]         BOOTMEM
[    0.000000]   #112 [0100068000 - 0100069000]         BOOTMEM
[    0.000000]   #113 [0100069000 - 010006a000]         BOOTMEM
[    0.000000]   #114 [010006a000 - 010006b000]         BOOTMEM
[    0.000000]   #115 [010006b000 - 010006c000]         BOOTMEM
[    0.000000]   #116 [010006c000 - 010006d000]         BOOTMEM
[    0.000000]   #117 [010006d000 - 010006e000]         BOOTMEM
[    0.000000]   #118 [010006e000 - 010006f000]         BOOTMEM
[    0.000000]   #119 [010006f000 - 0100070000]         BOOTMEM
[    0.000000]   #120 [0100070000 - 0100071000]         BOOTMEM
[    0.000000]   #121 [0100071000 - 0100072000]         BOOTMEM
[    0.000000]   #122 [0100072000 - 0100073000]         BOOTMEM
[    0.000000]   #123 [0100073000 - 0100074000]         BOOTMEM
[    0.000000]   #124 [0100074000 - 0100075000]         BOOTMEM
[    0.000000]   #125 [0100075000 - 0100076000]         BOOTMEM
[    0.000000]   #126 [0100076000 - 0100077000]         BOOTMEM
[    0.000000]   #127 [0100077000 - 0100078000]         BOOTMEM
[    0.000000]   #128 [0100078000 - 0100079000]         BOOTMEM
[    0.000000]   #129 [0100079000 - 010007a000]         BOOTMEM
[    0.000000]   #130 [010007a000 - 010007b000]         BOOTMEM
[    0.000000]   #131 [010007b000 - 010007c000]         BOOTMEM
[    0.000000]   #132 [010007c000 - 010007d000]         BOOTMEM
[    0.000000]   #133 [010007d000 - 010007e000]         BOOTMEM
[    0.000000]   #134 [010007e000 - 010007f000]         BOOTMEM
[    0.000000]   #135 [010007f000 - 0100080000]         BOOTMEM
[    0.000000]   #136 [0100080000 - 0100081000]         BOOTMEM
[    0.000000]   #137 [0100081000 - 0100082000]         BOOTMEM
[    0.000000]   #138 [0100082000 - 0100083000]         BOOTMEM
[    0.000000]   #139 [0100083000 - 0100084000]         BOOTMEM
[    0.000000]   #140 [0100084000 - 0100085000]         BOOTMEM
[    0.000000]   #141 [0100085000 - 0100086000]         BOOTMEM
[    0.000000]   #142 [0100086000 - 0100087000]         BOOTMEM
[    0.000000]   #143 [0100087000 - 0100088000]         BOOTMEM
[    0.000000]   #144 [0100088000 - 0100089000]         BOOTMEM
[    0.000000]   #145 [0100089000 - 010008a000]         BOOTMEM
[    0.000000]   #146 [010008a000 - 010008b000]         BOOTMEM
[    0.000000]   #147 [010008b000 - 010008c000]         BOOTMEM
[    0.000000]   #148 [010008c000 - 010008d000]         BOOTMEM
[    0.000000]   #149 [010008d000 - 010008e000]         BOOTMEM
[    0.000000]   #150 [010008e000 - 010008f000]         BOOTMEM
[    0.000000]   #151 [010008f000 - 0100090000]         BOOTMEM
[    0.000000]   #152 [0100090000 - 0100091000]         BOOTMEM
[    0.000000]   #153 [0100091000 - 0100092000]         BOOTMEM
[    0.000000]   #154 [0100092000 - 0100093000]         BOOTMEM
[    0.000000]   #155 [0100093000 - 0100094000]         BOOTMEM
[    0.000000]   #156 [0100094000 - 0100095000]         BOOTMEM
[    0.000000]   #157 [0100095000 - 0100096000]         BOOTMEM
[    0.000000]   #158 [0100096000 - 0100097000]         BOOTMEM
[    0.000000]   #159 [0100097000 - 0100098000]         BOOTMEM
[    0.000000]   #160 [0100098000 - 0100099000]         BOOTMEM
[    0.000000]   #161 [0100099000 - 010009a000]         BOOTMEM
[    0.000000]   #162 [010009a000 - 010009b000]         BOOTMEM
[    0.000000]   #163 [010009b000 - 010009c000]         BOOTMEM
[    0.000000]   #164 [010009c000 - 010009d000]         BOOTMEM
[    0.000000]   #165 [010009d000 - 010009e000]         BOOTMEM
[    0.000000]   #166 [010009e000 - 010009f000]         BOOTMEM
[    0.000000]   #167 [010009f000 - 01000a0000]         BOOTMEM
[    0.000000]   #168 [01000a0000 - 01000a1000]         BOOTMEM
[    0.000000]   #169 [01000a1000 - 01000a2000]         BOOTMEM
[    0.000000]   #170 [01000a2000 - 01000a3000]         BOOTMEM
[    0.000000]   #171 [01000a3000 - 01000a4000]         BOOTMEM
[    0.000000]   #172 [01000a4000 - 01000a5000]         BOOTMEM
[    0.000000]   #173 [01000a5000 - 01000a6000]         BOOTMEM
[    0.000000]   #174 [01000a6000 - 01000a7000]         BOOTMEM
[    0.000000]   #175 [01000a7000 - 01000a8000]         BOOTMEM
[    0.000000]   #176 [01000a8000 - 01000a9000]         BOOTMEM
[    0.000000]   #177 [01000a9000 - 01000aa000]         BOOTMEM
[    0.000000]   #178 [01000aa000 - 01000ab000]         BOOTMEM
[    0.000000]   #179 [01000ab000 - 01000ac000]         BOOTMEM
[    0.000000]   #180 [01000ac000 - 01000ad000]         BOOTMEM
[    0.000000]   #181 [01000ad000 - 01000ae000]         BOOTMEM
[    0.000000]   #182 [01000ae000 - 01000af000]         BOOTMEM
[    0.000000]   #183 [01000af000 - 01000b0000]         BOOTMEM
[    0.000000]   #184 [01000b0000 - 01000b1000]         BOOTMEM
[    0.000000]   #185 [01000b1000 - 01000b2000]         BOOTMEM
[    0.000000]   #186 [01000b2000 - 01000b3000]         BOOTMEM
[    0.000000]   #187 [01000b3000 - 01000b4000]         BOOTMEM
[    0.000000]   #188 [01000b4000 - 01000b5000]         BOOTMEM
[    0.000000]   #189 [01000b5000 - 01000b6000]         BOOTMEM
[    0.000000]   #190 [01000b6000 - 01000b7000]         BOOTMEM
[    0.000000]   #191 [01000b7000 - 01000b8000]         BOOTMEM
[    0.000000]   #192 [01000b8000 - 01000b9000]         BOOTMEM
[    0.000000]   #193 [01000b9000 - 01000ba000]         BOOTMEM
[    0.000000]   #194 [01000ba000 - 01000bb000]         BOOTMEM
[    0.000000]   #195 [01000bb000 - 01000bc000]         BOOTMEM
[    0.000000]   #196 [01000bc000 - 01000bd000]         BOOTMEM
[    0.000000]   #197 [01000bd000 - 01000be000]         BOOTMEM
[    0.000000]   #198 [01000be000 - 01000bf000]         BOOTMEM
[    0.000000]   #199 [01000bf000 - 01000c0000]         BOOTMEM
[    0.000000]   #200 [01000c0000 - 01000c1000]         BOOTMEM
[    0.000000]   #201 [01000c1000 - 01000c2000]         BOOTMEM
[    0.000000]   #202 [01000c2000 - 01000c3000]         BOOTMEM
[    0.000000]   #203 [01000c3000 - 01000c4000]         BOOTMEM
[    0.000000]   #204 [01000c4000 - 01000c5000]         BOOTMEM
[    0.000000]   #205 [01000c5000 - 01000c6000]         BOOTMEM
[    0.000000]   #206 [01000c6000 - 01000c7000]         BOOTMEM
[    0.000000]   #207 [01000c7000 - 01000c8000]         BOOTMEM
[    0.000000]   #208 [01000c8000 - 01000c9000]         BOOTMEM
[    0.000000]   #209 [01000c9000 - 01000ca000]         BOOTMEM
[    0.000000]   #210 [01000ca000 - 01000cb000]         BOOTMEM
[    0.000000]   #211 [01000cb000 - 01000cc000]         BOOTMEM
[    0.000000]   #212 [01000cc000 - 01000cd000]         BOOTMEM
[    0.000000]   #213 [01000cd000 - 01000ce000]         BOOTMEM
[    0.000000]   #214 [01000ce000 - 01000cf000]         BOOTMEM
[    0.000000]   #215 [01000cf000 - 01000d0000]         BOOTMEM
[    0.000000]   #216 [01000d0000 - 01000d1000]         BOOTMEM
[    0.000000]   #217 [01000d1000 - 01000d2000]         BOOTMEM
[    0.000000]   #218 [01000d2000 - 01000d3000]         BOOTMEM
[    0.000000]   #219 [01000d3000 - 01000d4000]         BOOTMEM
[    0.000000]   #220 [01000d4000 - 01000d5000]         BOOTMEM
[    0.000000]   #221 [01000d5000 - 01000d6000]         BOOTMEM
[    0.000000]   #222 [01000d6000 - 01000d7000]         BOOTMEM
[    0.000000]   #223 [01000d7000 - 01000d8000]         BOOTMEM
[    0.000000]   #224 [01000d8000 - 01000d9000]         BOOTMEM
[    0.000000]   #225 [01000d9000 - 01000da000]         BOOTMEM
[    0.000000]   #226 [01000da000 - 01000db000]         BOOTMEM
[    0.000000]   #227 [01000db000 - 01000dc000]         BOOTMEM
[    0.000000]   #228 [01000dc000 - 01000dd000]         BOOTMEM
[    0.000000]   #229 [01000dd000 - 01000de000]         BOOTMEM
[    0.000000]   #230 [01000de000 - 01000df000]         BOOTMEM
[    0.000000]   #231 [01000df000 - 01000e0000]         BOOTMEM
[    0.000000]   #232 [01000e0000 - 01000e1000]         BOOTMEM
[    0.000000]   #233 [01000e1000 - 01000e2000]         BOOTMEM
[    0.000000]   #234 [01000e2000 - 01000e3000]         BOOTMEM
[    0.000000]   #235 [01000e3000 - 01000e4000]         BOOTMEM
[    0.000000]   #236 [01000e4000 - 01000e5000]         BOOTMEM
[    0.000000]   #237 [01000e5000 - 01000e6000]         BOOTMEM
[    0.000000]   #238 [01000e6000 - 01000e7000]         BOOTMEM
[    0.000000]   #239 [01000e7000 - 01000e8000]         BOOTMEM
[    0.000000]   #240 [01000e8000 - 01000e9000]         BOOTMEM
[    0.000000]   #241 [01000e9000 - 01000ea000]         BOOTMEM
[    0.000000]   #242 [01000ea000 - 01000eb000]         BOOTMEM
[    0.000000]   #243 [01000eb000 - 01000ec000]         BOOTMEM
[    0.000000]   #244 [01000ec000 - 01000ed000]         BOOTMEM
[    0.000000]   #245 [01000ed000 - 01000ee000]         BOOTMEM
[    0.000000]   #246 [01000ee000 - 01000ef000]         BOOTMEM
[    0.000000]   #247 [01000ef000 - 01000f0000]         BOOTMEM
[    0.000000]   #248 [01000f0000 - 01000f1000]         BOOTMEM
[    0.000000]   #249 [01000f1000 - 01000f2000]         BOOTMEM
[    0.000000]   #250 [01000f2000 - 01000f3000]         BOOTMEM
[    0.000000]   #251 [01000f3000 - 01000f4000]         BOOTMEM
[    0.000000]   #252 [01000f4000 - 01000f5000]         BOOTMEM
[    0.000000]   #253 [01000f5000 - 01000f6000]         BOOTMEM
[    0.000000]   #254 [01000f6000 - 01000f7000]         BOOTMEM
[    0.000000]   #255 [0100200000 - 011e180000]        MEMMAP 0
[    0.000000]   #256 [000183bb40 - 0001853b40]         BOOTMEM
[    0.000000]   #257 [000ab54000 - 000ab6c000]         BOOTMEM
[    0.000000]   #258 [000ab6c000 - 000ab84000]         BOOTMEM
[    0.000000]   #259 [0001854000 - 0001855000]         BOOTMEM
[    0.000000]   #260 [0001855000 - 0001856000]         BOOTMEM
[    0.000000]   #261 [0001856000 - 0001857000]         BOOTMEM
[    0.000000]   #262 [0001853b40 - 0001853c20]         BOOTMEM
[    0.000000]   #263 [0001853c40 - 0001853ca8]         BOOTMEM
[    0.000000]   #264 [0001853cc0 - 0001853d28]         BOOTMEM
[    0.000000]   #265 [0001853d40 - 0001853da8]         BOOTMEM
[    0.000000]   #266 [0001853dc0 - 0001853df7]         BOOTMEM
[    0.000000]   #267 [0001853e00 - 0001853e37]         BOOTMEM
[    0.000000]   #268 [000ab84000 - 000abf4000]         BOOTMEM
[    0.000000]   #269 [0001853e40 - 0001853e48]         BOOTMEM
[    0.000000]   #270 [0001853e80 - 0001853e88]         BOOTMEM
[    0.000000]   #271 [0001853ec0 - 0001853ed0]         BOOTMEM
[    0.000000]   #272 [0001853f00 - 0001853f20]         BOOTMEM
[    0.000000]   #273 [0001859000 - 0001859100]         BOOTMEM
[    0.000000]   #274 [0001853f40 - 0001853f88]         BOOTMEM
[    0.000000]   #275 [0001859100 - 0001859148]         BOOTMEM
[    0.000000]   #276 [000abf4000 - 000abfc000]         BOOTMEM
[    0.000000]   #277 [000abfc000 - 000ebfc000]         BOOTMEM
[    0.000000]   #278 [000ebfc000 - 000ec1c000]         BOOTMEM
[    0.000000]   #279 [000ec1c000 - 000ec5c000]         BOOTMEM
[    0.000000]   #280 [000000e800 - 0000016800]         BOOTMEM
[    0.000000] Memory: 35113952k/35840000k available (3206k kernel code, 388k absent, 725660k reserved, 3713k data, 500k init)
[    0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] 	RCU-based detection of stalled CPUs is disabled.
[    0.000000] 	Verbose stalled-CPUs detection is disabled.
[    0.000000] NR_IRQS:4352 nr_irqs:304
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] Detected 2666.760 MHz processor.
[    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 5333.52 BogoMIPS (lpj=2666760)
[    0.000999] pid_max: default: 32768 minimum: 301
[    0.000999] Security Framework initialized
[    0.000999] SELinux:  Disabled at boot.
[    0.005404] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
[    0.020712] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    0.028351] Mount-cache hash table entries: 256
[    0.028548] Initializing cgroup subsys ns
[    0.028556] Initializing cgroup subsys cpuacct
[    0.028564] Initializing cgroup subsys devices
[    0.028571] Initializing cgroup subsys freezer
[    0.028618] CPU: Unsupported number of siblings 16
[    0.028624] Performance Events: unsupported p6 CPU model 26 no PMU driver, software events only.
[    0.028704] SMP alternatives: switching to UP code
[    0.029073] cpu 0 spinlock event irq 1
[    0.029261] installing Xen timer for CPU 1
[    0.029274] cpu 1 spinlock event irq 7
[    0.029299] SMP alternatives: switching to SMP code
[    0.000999] CPU: Unsupported number of siblings 16
[    0.030203] installing Xen timer for CPU 2
[    0.030224] cpu 2 spinlock event irq 13
[    0.030254]   alloc irq_desc for 16 on node 0
[    0.030257]   alloc kstat_irqs on node 0
[    0.030264]   alloc irq_desc for 17 on node 0
[    0.030267]   alloc kstat_irqs on node 0
[    0.000999] CPU: Unsupported number of siblings 16
[    0.030449] installing Xen timer for CPU 3
[    0.030459]   alloc irq_desc for 18 on node 0
[    0.030462]   alloc kstat_irqs on node 0
[    0.030468]   alloc irq_desc for 19 on node 0
[    0.030471]   alloc kstat_irqs on node 0
[    0.030477] cpu 3 spinlock event irq 19
[    0.030496]   alloc irq_desc for 20 on node 0
[    0.030498]   alloc kstat_irqs on node 0
[    0.030505]   alloc irq_desc for 21 on node 0
[    0.030507]   alloc kstat_irqs on node 0
[    0.030514]   alloc irq_desc for 22 on node 0
[    0.030516]   alloc kstat_irqs on node 0
[    0.030522]   alloc irq_desc for 23 on node 0
[    0.030524]   alloc kstat_irqs on node 0
[    0.000999] CPU: Unsupported number of siblings 16
[    0.030604] Brought up 4 CPUs
[    0.030612] sizeof(vma)=184 bytes
[    0.030614] sizeof(page)=56 bytes
[    0.030617] sizeof(inode)=616 bytes
[    0.030619] sizeof(dentry)=192 bytes
[    0.030622] sizeof(ext3inode)=832 bytes
[    0.030625] sizeof(buffer_head)=104 bytes
[    0.030627] sizeof(skbuff)=232 bytes
[    0.030630] sizeof(task_struct)=5776 bytes
[    0.030705] devtmpfs: initialized
[    0.049732] Grant table initialized
[    0.049732] NET: Registered protocol family 16
[    0.050023]   alloc irq_desc for 24 on node 0
[    0.050023]   alloc kstat_irqs on node 0
[    0.050055] PCI: Fatal: No config space access function found
[    0.056041] bio: create slab <bio-0> at 0
[    0.056056] ACPI: Interpreter disabled.
[    0.056056] xen_balloon: Initialising balloon driver.
[    0.057206] vgaarb: loaded
[    0.057206] PCI: System does not support PCI
[    0.057206] PCI: System does not support PCI
[    0.058024] NetLabel: Initializing
[    0.058028] NetLabel:  domain hash size = 128
[    0.058032] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.058050] NetLabel:  unlabeled traffic allowed by default
[    0.058231] Switching to clocksource xen
[    0.058242] pnp: PnP ACPI: disabled
[    0.064983] NET: Registered protocol family 2
[    0.065724] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.067725] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.069338] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.069527] TCP: Hash tables configured (established 524288 bind 65536)
[    0.069534] TCP reno registered
[    0.069735] UDP hash table entries: 32768 (order: 8, 1048576 bytes)
[    0.070086] UDP-Lite hash table entries: 32768 (order: 8, 1048576 bytes)
[    0.070377] NET: Registered protocol family 1
[    0.070391] PCI: CLS 0 bytes, default 64
[    0.070452] Unpacking initramfs...
[    0.093561] Freeing initrd memory: 18324k freed
[    0.098828] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.098844] Placing 64MB software IO TLB between ffff88000abfc000 - ffff88000ebfc000
[    0.098850] software IO TLB at phys 0xabfc000 - 0xebfc000
[    0.099483] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.102533] audit: initializing netlink socket (disabled)
[    0.102554] type=2000 audit(1338184539.000:1): initialized
[    0.119492] VFS: Disk quotas dquot_6.5.2
[    0.119601] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.119671] msgmni has been set to 32768
[    0.120289] alg: No test for stdrng (krng)
[    0.120461] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[    0.121449] io scheduler noop registered (default)
[    0.153417]   alloc irq_desc for 25 on node 0
[    0.153420]   alloc kstat_irqs on node 0
[    0.154172] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.156832] loop: module loaded
[    0.157217]   alloc irq_desc for 26 on node 0
[    0.157221]   alloc kstat_irqs on node 0
[    0.158591]   alloc irq_desc for 27 on node 0
[    0.158594]   alloc kstat_irqs on node 0
[    0.160859]   alloc irq_desc for 28 on node 0
[    0.160862]   alloc kstat_irqs on node 0
[    0.164045]   alloc irq_desc for 29 on node 0
[    0.164049]   alloc kstat_irqs on node 0
[    0.167433]   alloc irq_desc for 30 on node 0
[    0.167437]   alloc kstat_irqs on node 0
[    0.170735]   alloc irq_desc for 31 on node 0
[    0.170738]   alloc kstat_irqs on node 0
[    0.175135]   alloc irq_desc for 32 on node 0
[    0.175139]   alloc kstat_irqs on node 0
[    0.178564]   alloc irq_desc for 33 on node 0
[    0.178569]   alloc kstat_irqs on node 0
[    0.182198]   alloc irq_desc for 34 on node 0
[    0.182203]   alloc kstat_irqs on node 0
[    0.184058] Initialising Xen virtual ethernet driver.
[    0.185857] blkfront: regular deviceid=0x801 major,minor=8,1, assuming parts/disk=16
[    0.188580] blkfront: regular deviceid=0x855 major,minor=8,85, assuming parts/disk=16
[    0.189479] PNP: No PS/2 controller found. Probing ports directly.
[    0.190535] mice: PS/2 mouse device common for all mice
[    0.190634] cpuidle: using governor ladder
[    0.190640] cpuidle: using governor menu
[    0.190715] TCP cubic registered
[    0.190722] NET: Registered protocol family 17
[    0.190842] blkfront: regular deviceid=0x856 major,minor=8,86, assuming parts/disk=16
[    0.191095] registered taskstats version 1
[    0.191761] blkfront: regular deviceid=0x857 major,minor=8,87, assuming parts/disk=16
[    0.192561] blkfront: regular deviceid=0x858 major,minor=8,88, assuming parts/disk=16
[    0.193397] blkfront: regular deviceid=0x851 major,minor=8,81, assuming parts/disk=16
[    0.194274] blkfront: regular deviceid=0x852 major,minor=8,82, assuming parts/disk=16
[    0.195039] blkfront: regular deviceid=0x853 major,minor=8,83, assuming parts/disk=16
[    0.195888] blkfront: regular deviceid=0x854 major,minor=8,84, assuming parts/disk=16
[    0.196588]   alloc irq_desc for 35 on node 0
[    0.196591]   alloc kstat_irqs on node 0
[    0.291074] XENBUS: Device with no driver: device/console/0
[    0.291315] Freeing unused kernel memory: 500k freed
[    0.291457] Write protecting the kernel read-only data: 6144k
[    0.294260] Freeing unused kernel memory: 872k freed
[    0.294770] Freeing unused kernel memory: 772k freed
[    0.338850] device-mapper: uevent: version 1.0.3
[    0.339070] device-mapper: ioctl: 4.19.1-ioctl (2010-10-12) initialised: dm-devel@redhat.com
[    0.347400] udev: starting version 147
[    0.464874] md: bind<xvdf8>
[    0.474746] md: bind<xvdf7>
[    0.482043] md: bind<xvdf4>
[    0.540137] md: bind<xvdf3>
[    0.548545] md: bind<xvdf5>
[    0.558959] md: bind<xvdf2>
[    0.590210] md: bind<xvdf6>
[    0.605807] md: bind<xvdf1>
[    0.617615] md: raid10 personality registered for level 10
[    0.617973] md/raid10:md127: active with 8 out of 8 devices
[    0.618052] md127: detected capacity change from 0 to 42944430080
[    0.619764]  md127: unknown partition table
[    0.853476] dracut: Scanning devices md127  for LVM volume groups 
[    0.952821] dracut: Reading all physical volumes. This may take a while...
[    0.952917] dracut: Found volume group "lvm" using metadata type lvm2
[    1.001982] dracut: /dev/mapper/lvm-mysql not set up by udev: Falling back to direct node creation.
[    1.002490] dracut: The link /dev/lvm/mysql should had been created by udev but it was not found. Falling back to direct link creation.
[    1.002901] dracut: 1 logical volume(s) in volume group "lvm" now active
[    1.009194] dracut: Assembling MD RAID arrays
[    1.522720] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    1.714045] dracut: Remounting /dev/disk/by-label/\x2f with -o noatime,ro
[    1.724168] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    1.731079] dracut: Mounted root filesystem /dev/xvda1
[    2.074312] dracut: Loading SELinux policy
[    4.435236] dracut: /sbin/load_policy: Can't load policy: No such device
[    4.497683] dracut: Switching root
[    7.536918] usbcore: registered new interface driver usbfs
[    7.537147] usbcore: registered new interface driver hub
[    7.537356] usbcore: registered new device driver usb
[    9.689524] udev: starting version 147
[   10.573499] rtc_cmos: probe of rtc_cmos failed with error -16
[   15.475706] EXT4-fs (xvda1): re-mounted. Opts: (null)
[   15.887250] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[   15.889278] SGI XFS Quota Management subsystem
[   15.893832] XFS mounting filesystem dm-0
[   16.415440] Ending clean XFS mount for filesystem: dm-0
[   16.927608] Adding 1048572k swap on /.swapfile.  Priority:-1 extents:4 across:1073148k SS


--
Regards,
Jason Stubbs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:18:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1ScwGX-0004pf-Sf; Fri, 08 Jun 2012 10:18:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScwGV-0004pU-EH
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 10:17:59 +0000
Received: from [85.158.138.51:6449] by server-9.bemta-3.messagelabs.com id
	B4/81-15054-651D1DF4; Fri, 08 Jun 2012 10:17:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339150677!12749023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13996 invoked from network); 8 Jun 2012 10:17:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:17:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12905721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:17:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 11:17:57 +0100
Date: Fri, 8 Jun 2012 11:17:50 +0100
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: <20432.59018.420423.884384@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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 Thu, 7 Jun 2012, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > Stefano Stabellini writes ("[Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> In fact I did a build test before pushing and it failed.  See below.
> 
> The source directory /u/iwj/work/1/qemu-upstream-unstable.git contains
> 6d8b472233779c2a028a03843603030d2b1aee86 and I did a hg/git clean
> before the build test.
> 
> So I have stripped out that changeset.
> 

Thanks! I was working on the wrong tree (QEMU 1.1 rather than QEMU
1.0). Unfortunately the fix that went upstream for this compilation
issue is not suitable for 1.0 either, so we'll have to live with this
bug a little while longer.


> 
> make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-traditional-dir'
> make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make[2]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
>                 mkdir -p qemu-xen-dir; \
>         else \
>                 export GIT=git; \
>                 /u/iwj/work/xen-unstable-tools.hg/tools/../scripts/git-checkout.sh /u/iwj/work/1/qemu-upstream-unstable.git master qemu-xen-dir ; \
>         fi
> if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
>                 source=/u/iwj/work/1/qemu-upstream-unstable.git; \
>         else \
>                 source=.; \
>         fi; \
>         cd qemu-xen-dir; \
>         $source/configure --enable-xen --target-list=i386-softmmu \
>                 --source-path=$source \
>                 --extra-cflags="-I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/include \
>                 -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
>                 -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore \
>                 -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore/compat" \
>                 --extra-ldflags="-L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
>                 -L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore" \
>                 --bindir=/usr/lib/xen/bin \
>                 --datadir=/usr/share/qemu-xen \
>                 --disable-kvm \
>                 --disable-virtfs \
>                 --python=python \
>                 ; \
>         make install
> ERROR: unknown option --disable-virtfs
> 
> Usage: configure [options]
> Options: [defaults in brackets after descriptions]
> 
> Standard options:
>   --help                   print this message
>   --prefix=PREFIX          install in PREFIX [/usr/local]
>   --interp-prefix=PREFIX   where to find shared libraries, etc.
>                            use %M for cpu name [/usr/gnemul/qemu-%M]
>   --target-list=LIST       set target list (default: build everything)
>                            Available targets: i386-softmmu x86_64-softmmu 
>                            alpha-softmmu arm-softmmu cris-softmmu lm32-softmmu 
>                            m68k-softmmu microblaze-softmmu microblazeel-softmmu 
>                            mips-softmmu mipsel-softmmu mips64-softmmu 
>                            mips64el-softmmu ppc-softmmu ppcemb-softmmu 
>                            ppc64-softmmu sh4-softmmu sh4eb-softmmu 
>                            sparc-softmmu sparc64-softmmu s390x-softmmu 
>                            xtensa-softmmu xtensaeb-softmmu i386-linux-user 
>                            x86_64-linux-user alpha-linux-user arm-linux-user 
>                            armeb-linux-user cris-linux-user m68k-linux-user 
>                            microblaze-linux-user microblazeel-linux-user 
>                            mips-linux-user mipsel-linux-user ppc-linux-user 
>                            ppc64-linux-user ppc64abi32-linux-user 
>                            sh4-linux-user sh4eb-linux-user sparc-linux-user 
>                            sparc64-linux-user sparc32plus-linux-user 
>                            unicore32-linux-user s390x-linux-user 
> 
> Advanced options (experts only):
>   --source-path=PATH       path of source code [/u/iwj/work/1/qemu-upstream-unstable.git]
>   --cross-prefix=PREFIX    use PREFIX for compile tools []
>   --cc=CC                  use C compiler CC [gcc]
>   --host-cc=CC             use C compiler CC [gcc] for code run at
>                            build time
>   --extra-cflags=CFLAGS    append extra C compiler flags QEMU_CFLAGS
>   --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS
>   --make=MAKE              use specified make [make]
>   --install=INSTALL        use specified install [install]
>   --python=PYTHON          use specified python [python]
>   --smbd=SMBD              use specified smbd [/usr/sbin/smbd]
>   --static                 enable static build [no]
>   --mandir=PATH            install man pages in PATH
>   --datadir=PATH           install firmware in PATH
>   --docdir=PATH            install documentation in PATH
>   --bindir=PATH            install binaries in PATH
>   --sysconfdir=PATH        install config in PATH/qemu
>   --enable-debug-tcg       enable TCG debugging
>   --disable-debug-tcg      disable TCG debugging (default)
>   --enable-debug           enable common debug build options
>   --enable-sparse          enable sparse checker
>   --disable-sparse         disable sparse checker (default)
>   --disable-strip          disable stripping binaries
>   --disable-werror         disable compilation abort on warning
>   --disable-sdl            disable SDL
>   --enable-sdl             enable SDL
>   --disable-vnc            disable VNC
>   --enable-vnc             enable VNC
>   --enable-cocoa           enable COCOA (Mac OS X only)
>   --audio-drv-list=LIST    set audio drivers list:
>                            Available drivers: oss alsa sdl esd pa fmod
>   --audio-card-list=LIST   set list of emulated audio cards [ac97 es1370 sb16 hda]
>                            Available cards: ac97 es1370 sb16 cs4231a adlib gus hda
>   --block-drv-whitelist=L  set block driver whitelist
>                            (affects only QEMU, not qemu-img)
>   --enable-mixemu          enable mixer emulation
>   --disable-xen            disable xen backend driver support
>   --enable-xen             enable xen backend driver support
>   --disable-brlapi         disable BrlAPI
>   --enable-brlapi          enable BrlAPI
>   --disable-vnc-tls        disable TLS encryption for VNC server
>   --enable-vnc-tls         enable TLS encryption for VNC server
>   --disable-vnc-sasl       disable SASL encryption for VNC server
>   --enable-vnc-sasl        enable SASL encryption for VNC server
>   --disable-vnc-jpeg       disable JPEG lossy compression for VNC server
>   --enable-vnc-jpeg        enable JPEG lossy compression for VNC server
>   --disable-vnc-png        disable PNG compression for VNC server (default)
>   --enable-vnc-png         enable PNG compression for VNC server
>   --disable-vnc-thread     disable threaded VNC server
>   --enable-vnc-thread      enable threaded VNC server
>   --disable-curses         disable curses output
>   --enable-curses          enable curses output
>   --disable-curl           disable curl connectivity
>   --enable-curl            enable curl connectivity
>   --disable-fdt            disable fdt device tree
>   --enable-fdt             enable fdt device tree
>   --disable-check-utests   disable check unit-tests
>   --enable-check-utests    enable check unit-tests
>   --disable-bluez          disable bluez stack connectivity
>   --enable-bluez           enable bluez stack connectivity
>   --disable-slirp          disable SLIRP userspace network connectivity
>   --disable-kvm            disable KVM acceleration support
>   --enable-kvm             enable KVM acceleration support
>   --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)
>   --disable-nptl           disable usermode NPTL support
>   --enable-nptl            enable usermode NPTL support
>   --enable-system          enable all system emulation targets
>   --disable-system         disable all system emulation targets
>   --enable-user            enable supported user emulation targets
>   --disable-user           disable all user emulation targets
>   --enable-linux-user      enable all linux usermode emulation targets
>   --disable-linux-user     disable all linux usermode emulation targets
>   --enable-darwin-user     enable all darwin usermode emulation targets
>   --disable-darwin-user    disable all darwin usermode emulation targets
>   --enable-bsd-user        enable all BSD usermode emulation targets
>   --disable-bsd-user       disable all BSD usermode emulation targets
>   --enable-guest-base      enable GUEST_BASE support for usermode
>                            emulation targets
>   --disable-guest-base     disable GUEST_BASE support
>   --enable-pie             build Position Independent Executables
>   --disable-pie            do not build Position Independent Executables
>   --fmod-lib               path to FMOD library
>   --fmod-inc               path to FMOD includes
>   --oss-lib                path to OSS library
>   --enable-uname-release=R Return R for uname -r in usermode emulation
>   --cpu=CPU                Build for host CPU [i386]
>   --sparc_cpu=V            Build qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9
>   --disable-uuid           disable uuid support
>   --enable-uuid            enable uuid support
>   --disable-vde            disable support for vde network
>   --enable-vde             enable support for vde network
>   --disable-linux-aio      disable Linux AIO support
>   --enable-linux-aio       enable Linux AIO support
>   --disable-attr           disables attr and xattr support
>   --enable-attr            enable attr and xattr support
>   --disable-blobs          disable installing provided firmware blobs
>   --enable-docs            enable documentation build
>   --disable-docs           disable documentation build
>   --disable-vhost-net      disable vhost-net acceleration support
>   --enable-vhost-net       enable vhost-net acceleration support
>   --enable-trace-backend=B Set trace backend
>                            Available backends: nop simple stderr ust dtrace
>   --with-trace-file=NAME   Full PATH,NAME of file to store traces
>                            Default:trace-<pid>
>   --disable-spice          disable spice
>   --enable-spice           enable spice
>   --enable-rbd             enable building the rados block device (rbd)
>   --disable-libiscsi       disable iscsi support
>   --enable-libiscsi        enable iscsi support
>   --disable-smartcard      disable smartcard support
>   --enable-smartcard       enable smartcard support
>   --disable-smartcard-nss  disable smartcard nss support
>   --enable-smartcard-nss   enable smartcard nss support
>   --disable-usb-redir      disable usb network redirection support
>   --enable-usb-redir       enable usb network redirection support
>   --disable-guest-agent    disable building of the QEMU Guest Agent
>   --enable-guest-agent     enable building of the QEMU Guest Agent
> 
> NOTE: The object files are built at the place where configure is launched
> make[3]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
> make[3]: *** No rule to make target `install'.  Stop.
> make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
> make[2]: *** [subdir-install-qemu-xen-dir] Error 2
> make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make: *** [install-tools] Error 2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:18:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1ScwGX-0004pf-Sf; Fri, 08 Jun 2012 10:18:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1ScwGV-0004pU-EH
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 10:17:59 +0000
Received: from [85.158.138.51:6449] by server-9.bemta-3.messagelabs.com id
	B4/81-15054-651D1DF4; Fri, 08 Jun 2012 10:17:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339150677!12749023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13996 invoked from network); 8 Jun 2012 10:17:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:17:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12905721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:17:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 11:17:57 +0100
Date: Fri, 8 Jun 2012 11:17:50 +0100
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: <20432.59018.420423.884384@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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 Thu, 7 Jun 2012, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > Stefano Stabellini writes ("[Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> In fact I did a build test before pushing and it failed.  See below.
> 
> The source directory /u/iwj/work/1/qemu-upstream-unstable.git contains
> 6d8b472233779c2a028a03843603030d2b1aee86 and I did a hg/git clean
> before the build test.
> 
> So I have stripped out that changeset.
> 

Thanks! I was working on the wrong tree (QEMU 1.1 rather than QEMU
1.0). Unfortunately the fix that went upstream for this compilation
issue is not suitable for 1.0 either, so we'll have to live with this
bug a little while longer.


> 
> make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-traditional-dir'
> make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make[2]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
>                 mkdir -p qemu-xen-dir; \
>         else \
>                 export GIT=git; \
>                 /u/iwj/work/xen-unstable-tools.hg/tools/../scripts/git-checkout.sh /u/iwj/work/1/qemu-upstream-unstable.git master qemu-xen-dir ; \
>         fi
> if test -d /u/iwj/work/1/qemu-upstream-unstable.git ; then \
>                 source=/u/iwj/work/1/qemu-upstream-unstable.git; \
>         else \
>                 source=.; \
>         fi; \
>         cd qemu-xen-dir; \
>         $source/configure --enable-xen --target-list=i386-softmmu \
>                 --source-path=$source \
>                 --extra-cflags="-I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/include \
>                 -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
>                 -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore \
>                 -I/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore/compat" \
>                 --extra-ldflags="-L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/libxc \
>                 -L/u/iwj/work/xen-unstable-tools.hg/tools/../tools/xenstore" \
>                 --bindir=/usr/lib/xen/bin \
>                 --datadir=/usr/share/qemu-xen \
>                 --disable-kvm \
>                 --disable-virtfs \
>                 --python=python \
>                 ; \
>         make install
> ERROR: unknown option --disable-virtfs
> 
> Usage: configure [options]
> Options: [defaults in brackets after descriptions]
> 
> Standard options:
>   --help                   print this message
>   --prefix=PREFIX          install in PREFIX [/usr/local]
>   --interp-prefix=PREFIX   where to find shared libraries, etc.
>                            use %M for cpu name [/usr/gnemul/qemu-%M]
>   --target-list=LIST       set target list (default: build everything)
>                            Available targets: i386-softmmu x86_64-softmmu 
>                            alpha-softmmu arm-softmmu cris-softmmu lm32-softmmu 
>                            m68k-softmmu microblaze-softmmu microblazeel-softmmu 
>                            mips-softmmu mipsel-softmmu mips64-softmmu 
>                            mips64el-softmmu ppc-softmmu ppcemb-softmmu 
>                            ppc64-softmmu sh4-softmmu sh4eb-softmmu 
>                            sparc-softmmu sparc64-softmmu s390x-softmmu 
>                            xtensa-softmmu xtensaeb-softmmu i386-linux-user 
>                            x86_64-linux-user alpha-linux-user arm-linux-user 
>                            armeb-linux-user cris-linux-user m68k-linux-user 
>                            microblaze-linux-user microblazeel-linux-user 
>                            mips-linux-user mipsel-linux-user ppc-linux-user 
>                            ppc64-linux-user ppc64abi32-linux-user 
>                            sh4-linux-user sh4eb-linux-user sparc-linux-user 
>                            sparc64-linux-user sparc32plus-linux-user 
>                            unicore32-linux-user s390x-linux-user 
> 
> Advanced options (experts only):
>   --source-path=PATH       path of source code [/u/iwj/work/1/qemu-upstream-unstable.git]
>   --cross-prefix=PREFIX    use PREFIX for compile tools []
>   --cc=CC                  use C compiler CC [gcc]
>   --host-cc=CC             use C compiler CC [gcc] for code run at
>                            build time
>   --extra-cflags=CFLAGS    append extra C compiler flags QEMU_CFLAGS
>   --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS
>   --make=MAKE              use specified make [make]
>   --install=INSTALL        use specified install [install]
>   --python=PYTHON          use specified python [python]
>   --smbd=SMBD              use specified smbd [/usr/sbin/smbd]
>   --static                 enable static build [no]
>   --mandir=PATH            install man pages in PATH
>   --datadir=PATH           install firmware in PATH
>   --docdir=PATH            install documentation in PATH
>   --bindir=PATH            install binaries in PATH
>   --sysconfdir=PATH        install config in PATH/qemu
>   --enable-debug-tcg       enable TCG debugging
>   --disable-debug-tcg      disable TCG debugging (default)
>   --enable-debug           enable common debug build options
>   --enable-sparse          enable sparse checker
>   --disable-sparse         disable sparse checker (default)
>   --disable-strip          disable stripping binaries
>   --disable-werror         disable compilation abort on warning
>   --disable-sdl            disable SDL
>   --enable-sdl             enable SDL
>   --disable-vnc            disable VNC
>   --enable-vnc             enable VNC
>   --enable-cocoa           enable COCOA (Mac OS X only)
>   --audio-drv-list=LIST    set audio drivers list:
>                            Available drivers: oss alsa sdl esd pa fmod
>   --audio-card-list=LIST   set list of emulated audio cards [ac97 es1370 sb16 hda]
>                            Available cards: ac97 es1370 sb16 cs4231a adlib gus hda
>   --block-drv-whitelist=L  set block driver whitelist
>                            (affects only QEMU, not qemu-img)
>   --enable-mixemu          enable mixer emulation
>   --disable-xen            disable xen backend driver support
>   --enable-xen             enable xen backend driver support
>   --disable-brlapi         disable BrlAPI
>   --enable-brlapi          enable BrlAPI
>   --disable-vnc-tls        disable TLS encryption for VNC server
>   --enable-vnc-tls         enable TLS encryption for VNC server
>   --disable-vnc-sasl       disable SASL encryption for VNC server
>   --enable-vnc-sasl        enable SASL encryption for VNC server
>   --disable-vnc-jpeg       disable JPEG lossy compression for VNC server
>   --enable-vnc-jpeg        enable JPEG lossy compression for VNC server
>   --disable-vnc-png        disable PNG compression for VNC server (default)
>   --enable-vnc-png         enable PNG compression for VNC server
>   --disable-vnc-thread     disable threaded VNC server
>   --enable-vnc-thread      enable threaded VNC server
>   --disable-curses         disable curses output
>   --enable-curses          enable curses output
>   --disable-curl           disable curl connectivity
>   --enable-curl            enable curl connectivity
>   --disable-fdt            disable fdt device tree
>   --enable-fdt             enable fdt device tree
>   --disable-check-utests   disable check unit-tests
>   --enable-check-utests    enable check unit-tests
>   --disable-bluez          disable bluez stack connectivity
>   --enable-bluez           enable bluez stack connectivity
>   --disable-slirp          disable SLIRP userspace network connectivity
>   --disable-kvm            disable KVM acceleration support
>   --enable-kvm             enable KVM acceleration support
>   --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)
>   --disable-nptl           disable usermode NPTL support
>   --enable-nptl            enable usermode NPTL support
>   --enable-system          enable all system emulation targets
>   --disable-system         disable all system emulation targets
>   --enable-user            enable supported user emulation targets
>   --disable-user           disable all user emulation targets
>   --enable-linux-user      enable all linux usermode emulation targets
>   --disable-linux-user     disable all linux usermode emulation targets
>   --enable-darwin-user     enable all darwin usermode emulation targets
>   --disable-darwin-user    disable all darwin usermode emulation targets
>   --enable-bsd-user        enable all BSD usermode emulation targets
>   --disable-bsd-user       disable all BSD usermode emulation targets
>   --enable-guest-base      enable GUEST_BASE support for usermode
>                            emulation targets
>   --disable-guest-base     disable GUEST_BASE support
>   --enable-pie             build Position Independent Executables
>   --disable-pie            do not build Position Independent Executables
>   --fmod-lib               path to FMOD library
>   --fmod-inc               path to FMOD includes
>   --oss-lib                path to OSS library
>   --enable-uname-release=R Return R for uname -r in usermode emulation
>   --cpu=CPU                Build for host CPU [i386]
>   --sparc_cpu=V            Build qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9
>   --disable-uuid           disable uuid support
>   --enable-uuid            enable uuid support
>   --disable-vde            disable support for vde network
>   --enable-vde             enable support for vde network
>   --disable-linux-aio      disable Linux AIO support
>   --enable-linux-aio       enable Linux AIO support
>   --disable-attr           disables attr and xattr support
>   --enable-attr            enable attr and xattr support
>   --disable-blobs          disable installing provided firmware blobs
>   --enable-docs            enable documentation build
>   --disable-docs           disable documentation build
>   --disable-vhost-net      disable vhost-net acceleration support
>   --enable-vhost-net       enable vhost-net acceleration support
>   --enable-trace-backend=B Set trace backend
>                            Available backends: nop simple stderr ust dtrace
>   --with-trace-file=NAME   Full PATH,NAME of file to store traces
>                            Default:trace-<pid>
>   --disable-spice          disable spice
>   --enable-spice           enable spice
>   --enable-rbd             enable building the rados block device (rbd)
>   --disable-libiscsi       disable iscsi support
>   --enable-libiscsi        enable iscsi support
>   --disable-smartcard      disable smartcard support
>   --enable-smartcard       enable smartcard support
>   --disable-smartcard-nss  disable smartcard nss support
>   --enable-smartcard-nss   enable smartcard nss support
>   --disable-usb-redir      disable usb network redirection support
>   --enable-usb-redir       enable usb network redirection support
>   --disable-guest-agent    disable building of the QEMU Guest Agent
>   --enable-guest-agent     enable building of the QEMU Guest Agent
> 
> NOTE: The object files are built at the place where configure is launched
> make[3]: Entering directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
> make[3]: *** No rule to make target `install'.  Stop.
> make[3]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools/qemu-xen-dir'
> make[2]: *** [subdir-install-qemu-xen-dir] Error 2
> make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/tools'
> make: *** [install-tools] Error 2
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:19:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10:19: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 1ScwHs-0004vB-By; Fri, 08 Jun 2012 10:19:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1ScwHr-0004ux-2s
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 10:19:23 +0000
Received: from [85.158.143.35:62352] by server-1.bemta-4.messagelabs.com id
	A5/8F-10042-AA1D1DF4; Fri, 08 Jun 2012 10:19:22 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339150759!14996725!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3927 invoked from network); 8 Jun 2012 10:19:21 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 10:19:21 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id 1F59FA5
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 14:19:19 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id YWFjmlN3GrHv for <xen-devel@lists.xen.org>;
	Fri,  8 Jun 2012 14:19:18 +0400 (MSK)
Received: from sysadmin.office.main.elserv.ru (sysadmin.office.main.elserv.ru
	[192.168.3.135]) (Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id 9C05C1C
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 14:19:18 +0400 (MSK)
Message-ID: <4FD1D1A6.4090900@elserv.ru>
Date: Fri, 08 Jun 2012 14:19:18 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
In-Reply-To: <4FD1C9370200007800088AD8@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------030302030402000700080000"
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------030302030402000700080000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

08.06.2012 11:43, Jan Beulich пишет:
>>>> On 07.06.12 at 11:29, Alex Moskalenko<mav@elserv.ru>  wrote:
>> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on
>> IBM eServer x3400. Without noacpi command line option dom0 kernel
>> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
>> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor
>> all kernels run without any problems.
> This is an issue that was reported and discussed previously.
> Fundamentally, it is a firmware problem from my pov: ACPI has
> _nothing_ to do with the MMIO space used for the IO-APICs of
> the system once they are under control of the OS. It shouldn't
> even be reading from them (which iirc was the case in earlier
> reports), but in your case it looks like it's even writing them. I
> had been considering to allow Dom0 read access to those pages,
> but obviously this wouldn't help in your case.
>
> Could you extract and supply the ACPI tables of that system, so
> we can make an attempt at checking whether there is some reason
> for the firmware writing to the IO-APIC that we didn't think of so
> far?
Please see attached archive. Tables are grabbed with acpidump -b under 
Xen 4.1.2 and patched kernel 2.6.32.

-- 
WBR, Alex Moskalenko


--------------030302030402000700080000
Content-Type: application/x-bzip;
 name="acpi_tables.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="acpi_tables.tar.bz2"

QlpoOTFBWSZTWZJsNkwAGLH////////////+/////f////v//n/V/1X+x+dE8FRU/unJ4CW9
901ctxd2qy83F1T3bdzsbVG94bvZ7t4FmD2xOuop29c7UZWpvNrTSttQNg5bu7mtdLjcZOrl
g7rb2zO64dmp07s1ve72yJK3c95SilpgMRSQprpkrtsJJBCEaaaYgJtMmmhkIyZGmhlTyZT9
NTJPRp6nqRsk09Mp6jQ2jSGjR6IyA9TTRppoaDQ0DQAaA0DQZADEEoUaaYgTTEICaaZAiGmy
TMp5RtRmpkYjCMJoAAGmmg0AAAAAGQDRoAAAAAAaA1M9SnpKap5NT1PahPUep6mmg0GnqekG
jIGah6mh6gA9QMQNAGgADQAAAAGgGg0AGgBpoAAASaUoCE02gp6NTJtGkGjTTSZpT8ITyU81
T1PUZiaanqeo2oGgDTQNHpNGgD1AANHqAaAAAA0ANANBpogZMmQDJkABpghoA0AAGhiGmgGQ
AAaAaBkNANADIDQNNGINGgAANAAGgKoiCATTQm0INARkwk2BMJkyJ6EBpG9MlPUz1NTR6JtC
ZGhiGJoaDINPSAyANGjIGhoAaADRofIyfIySBsgHo5PqdIFgaAYGXdoOjG3uW2223Drf4YUF
ZDaTin4CH/1J7zvd7A9bY9j1UL8AmQqQEFGUx2fo1fh43V0dZSCHc6QCQ5UKFReVfMln52eE
8qYQoODSglA42nbVPcyiMvy6Qh4MjANBFMQk9XMMV1GDHQij6PgVgMV0qBxJgcSG4ydJ5aBm
jCCkHqzx/Tejly9+Br4IS7ta7SIlBSUHWFxS7rUa08WYiIsshyhUYnBYHAgGoAZDSyGlBVKk
A2eQSiDAGcxt9P3Hdt03953vU+KVrfgfX87HM87HmNjm4dsaXdNl/bPNPvHnFG8xq6VrP8M/
EZO8JTy/+XTVPH/VJYqszJkyZOCfcc2hu9DIQmRNx47AMvnGeZvWQysZ2EDM486yXPc+sWqy
l2SkFqRZDLTppgb/u88fJHq1KYPwK4MVlc3ZnaTOtuajtZ09dc8oJ9FPYV1Zqn0sqirlZNNJ
EAYZ0pSlKT30sqqqrKWqaad0pSjGL4cZmizRjGMYxgJOHMITRjGL4xi+FrNFmjGMYxi8hCEI
QhCEKRYNCEIQfCGGMsQ5ceZqxEKImIQUvMu6WRqbgdr3lURokDF7/4LyvyuOssoka8nCiYFG
lJKiZngJGC1lBtNB/dPgzBkQKiHcVz83dzEDC8PdYxys+DhycOWnc+rq3ut9O/b7NJp7qbuu
zddLrvFUwLo1DEhIT7rHSfNb2l/AbZm7SiG1oyqaLXw042CHaLoMXtHP8jUHJ4xQ2ZJE7rtJ
b/wfwrEfmCXlSMZbQXjS4lEZMc0A2k8XJ2vCyQ78yawKGDaZCYa9B1l6dIUDpuHVO36GDm2+
7vM/Xz+lwO69vqZmhEN1sKO+Zkd/gpAREMuzGcIpHLwwIAtuNfbftjbcbu3LNbA7QOs53xnO
6Gg49Zdu1MDufGVVVfBDNlzPpGMYz9Ahugag9tesw2DSBnEmtvAAKJOIUXlWZmZsBJQnrVma
rxE7xkVrWta1rCibLLiSlcr/Vu63kpJ+Mwb7MZY0hg6PR496X50G59DkcUYr+3yOntcl/ev5
WIVcJxy++p33tvebPYzIP/ME/MA4IPY7Q6IHsbB7fxBw/E5is8yZ5iz2pzh7Cc5KSamfIYyP
YfBTLltt0G+YphGPnjVpPxva5Moe+n0npPtVT0Z9J6T0q+hKIeVtbgdeyEFuh31a9buUpSlK
aK1r7267x8Hd09HZmES29O29TmXOkD0HmAArEB5p4C07kMxM/qXhhBABEBBUSGk3MeWO+kNc
Ss3xCT5VkzMRMFwTk2ESxghHwdnPvzga1XWbg6kdjXlnT9qS/Fgj7e6wYw25M1MvA4DAJGAg
xjMvrHI0aCPS8bHh+gTv8eZ/N5vfvmoY3tIezzPhP+Zubj/teX5j8biMkXwJZeRbeAejXyPF
Z2XmSILhhg4jqvu4sc25dfMwm3+W8SKIySYBhNjgyBhMIBi/tGVmtacVFN5w0zvzPAgIORwv
Pm4JjS+Rdr6l+BfMRFpKZgmYJQ63V2fE3mXq39UhPYGBxvsN4k9kt/qNvuRHE2/VP8jDHlAT
0XkpK9CL0mmB72RLtf4Hd7JzSAXZNWgndAqNuDJaLMCfzYMhJMTx8SQsVJA7I7oGKggO2G4H
xsntX10pbIcffb8uRJii1nIUsg26cCnAzMyUtQXnozCFbNbLw7cfamkQfruBQumEPuiJMgju
dqXbtEL4JgLwC41waqsIRqzpREWqSKtXwupLIkyPc6OfCdzCMBgMBgMBgeeT5kiIiIiRIiIi
IqqqIqqqqqqqqqqqqqqqqqquTqd6B6AVj28mLhQ/bqQq5vXrbLTLDPCx0iEfTlo2qDa2KCWS
JAtywWQgEp5BhmBbA3YSat9PsF3Fpz7F3V7K1JbHF1L8i7jWOnHEx+fYy8KPus3Q03ITt+0r
wI69D2u4M5wgxKGNFWynRWGBh4kIZDO6wLDcYjEW0wL9U/f+Bu5o0LuXpduzGXQNiR6viGC5
6F8XwrEZtufzByL9AvZB4Vu0VJNqmPj5hr6cY4N7rifMz4Gnp62e9GjapBYZBxTEfLOE2cu1
vN5HJ0vae7GfusurCGASCLIHgnTBEEOXy2ILGZAwBkA5WaZLNRh7XvOaVKJZi2mNoM7oK7ve
TMzMzMzMzMzMzM31eXupcLoemrB6oFoIUkwC2WWWWWXRQTRyoQqlNNKUvxpjIOg5mnRZu0BZ
ZZZZZfnEO4UzRGYXxYDTUgYpVTk2WpreszxQiRy5vXAOuilayGg0y4E2FznaWajS993R3Q4H
rLE4y8WZsjKu6aSmUuI6cw0uoWmeG1tPhv7nJ4eGHL4VoWj3rgNSa23kyDjTSZu+bbatQy8y
eR5IKFE1w3Qz8rfFzo4+JzPnoff7V5F3S2KVh04Ha56P4rDA6YWGuoCHAMIrV7t27d0c/Pll
llllllsgXKtyrem/ByQyEUYyHMERk5EVJZkLWlIMouCkSyglRgOMYw4uLih42bmd7SygjOIM
JOnSHcEIQnd0IQgAAAAAAKq1rtFllmP2fKnM1BMeeadMRRH6QmL1FIgkCB7ACboboRgijEln
moRhys+2ag2hmFfhXruZmOiMuqpA70UyuJCoqIoKmSYjlvEnvsxLdmcS8DIClAHijxUvzYWe
G7nzHreQYF6KigKCy7oBURhO9AukizBZdqmMZydm1i/WiUjGo1lLSQqKiKCpv79qJp3LValv
dhmJxVHbOwYDwUMQzY4Nse+v6PWTu86GfIoRUUBQWr6W5ztOPQac+msxbWfTqg5znOdkW9Pf
sb2AOFRURRUnrNg2AYMkQoChFiRGeuHkgb2retpzjmatnY7Po4exPBA4jMbHcyKbbNtWjYbB
Q5g0atRjyvqnEcG3c3dThflLrtOzwNqzWaxQyb0vpxeZogXl5qDbbbNv8eG5ddubmIxG3QvU
AVYAUuV22bFlhYjyw75mRFUhbYBsijwqlPxeRUq0bqG0sLxbOJbbxLuJ0laENpV3CsCxA49v
abAUheCTxL82a6kKQpDRUgRLciglJEYCAKEAtSneHvrrgEAriJDmA4HAyQhCEJUhSEw1evzr
dni3AX22qrtlb7RA9SAbeYqHPVuv3ilDgqI5UEHrAZk5IPnMQZCPFHRjSd4Kh4Y0oU7WBi2s
a1am+bUdQYmSU/tMhqWb/KUspM6elYs42ErbOlMenPASY57NWljjjji5znOdaEVoe+vhiyeB
rDIb3T0gKB5IBQz9clO9z6uLoPEGsb07mJycnsubY43Dq42yWj5EhsqKqp6qqqqnve97307M
VqKi4zhLACgLYdSDiwVZVNprK12hN8Trk3S0ko8VhFV9lnL1YvQ62J99LJlmdDHY0cDNWlKd
SS5dTBVjIms4tirv8qNGXviGBWt64MFRUVZTd/ZAx7BwXOExpoYcQ9pikMCn2Y38Uj1yXCND
DWF+Sh4ctzOpnUdwIWAK/l+P5ORQARXr5+fvN5vNTh7QKl6uCXvt4VanA5ncT14nxWac/QnT
0RNVZiikGT8fLkCYI8Klh3pIjCg9Dl9SyOjHNHAZDAUKZTJKeSCEt9YsWLFixYsZmtcJ5PIQ
y8url0+Rh269u3vRCWzDo37CUxmMC7ZWh3PN9beLKQX9WrVq7v3CmrU61bciC0mAuF8J3Pzg
N5hTH3ZAG1WZ2rqs228BjifK2uyOf3KoypekYpKYETMzP2Uudnj1NvL6nHcnu4aMufQ7DsL5
AYErkBaXG5wPgwMiNCLRUbew6D3PbV9ny4wRicVy3bJVwpUAcTOKlaS4amqza+vr09fX3gFV
BkJKxEiTJUghOBPOiT8YsRhV0z2WWbFHHqAZKlF1J0jY2Wwmzpx97B3fkcRy5NPiUWrIsJTH
XKlDpZyAxjKjKs6S1QPw7WVmbJmyAAAAAABVrXvFllmzEGvqZlJJ1KKERqS1JhCPJiHIwUgs
KxnQPBIYtLEQL05pen1agA9IO7y7FkrlKQ2S+OcUwKQLXGESLhaJhaB0x0pZYdG4MJsx+awG
76AsfGjhcijt8pqgIo8CEGhRCEOXbGUN7fnTdim/eT9k5dJTTRGqbBCZgvTKyi35Zoqc2+Mk
zWLTfm9HbJRmO3ufMmleFusdSa8gIpITIAokKEOtRx232REcBQk6kzLFDHVD/USLLUqWmSvG
lt3eyq4OuZzE8kW054hZxGRZcLqGTeQzVswoRFtEXk2XiSiUlYeTFfgieeG7x77kJhbMav0a
0s32Th4Mqhl1u8ETif851AaiNu2HlJs2kIjE5nFOu70+U/Pb58zvMl8qA+873gAX4fWp2cWI
HLDAn051UgOqt0lsZ77/l/Hfk0tIp78i2Qy9DoR0P6cBsDjz2sXTyW5Bhx80qLfsMQ8FpQJa
RdCmBRW1LItGIDRNCJOHz9/DBszVpYaWBqSXwBCoM2e4k4cNLcL6J6CgY7iGz21gOnp7wEtL
3TIIItEkEXgoC+5obl8Wsrc7WR6RMLHM0zV4dZmg9SJC0WSMOTyOpfLNt+Jssq2wr67iHHqq
KMyc8UYV6jKoqTDM9WUkTc4GIsGFY4mOBfVIlItxNAtcwghsKgIfucBCu/REVXTWYKSFp5lq
FKYKGCDc5VVaUUOHmUwimRKmzactrv9+Y28wHK6fOixZ2PPm3JrGxypAJp4VpbrBAmMYtuJP
gSCpz0c5zMzM22OnNmgMxkZiYc7bJpu/A4EuEbtJIbScC5rcIxi5Iv0TNw1qqCrFw2sa60LW
OTBmqGRJALls90ZoENLYWy2t266mnf0VXJDX36ydErJ0spk0GJMCOQslN1sicgxrhTMXdAQ3
zfKDA1q6ipEnzrdwekZEJlODYIZ53KCqyIY7tQmpcxfYBuIxcFO1rVG40UiZyEBU3MnAM2Bk
XbBSJFgZVTFuDcW2zOsNWRVVg22c1WMi9JCiEQUeSYuUSIKBp1uFqeYQVtHjAKsb6du++mG1
ozZYyFcYij2J815XZNuoKZxV2ldwZyZFFKy7PXcN/FGqW3akb7V2xSmJrptYDDjGGRZYIoCd
+g0arWcNSLcs01tVOOeGmjTmtApls332DkGWekaTbY0z0zatrk3bob5jkYDBjcF3ruEEyPoc
G9sBknNriVmust06u0UpXZYRc2TFvDFZYKlloU7Bnw1YCEzY4q7fGiaTQuNhrylU7Wwwz4Ct
OZxRSzLgasU0EySkhOlMZEN6MuCGzOsrj2bVKSrMzMzWE00zMzM1GmdtQTTVXl4QewDstFZo
s0aL8p9FlZSTCpUqKwpVPz7jdtZMgLJpkYbXrzC4YSatma4wBzswTAKHQ0KBr3yFJUZW5ZOs
yttFYsFFJuozmwuQLWwDCGIgrllmFkQxkq1mIOcwHgwHY34khSUVuwow3ayQK67AZtYpsmjF
lRhBRLSqq0bNXfaq3F4OcwE+BtmByFVxLeBRQNITPo4eEtW22222223PrTmZjEhrzf8TBsbw
Gvzv3BzZHD/5yZNTkK+Xko1WxbveMk50OjzZ9ZHXb7bIyMmCFDCjAUomqz70K0tnWyrIiOVY
UvmJuiRqJVrnQazk4dEcq2zh6gmCKQhWy6Y3xRLCoqotIaJTaKIUUEpEpGbg2Tr+19/5HNPR
1kesRict5Hk3LDxvIiIjl9QN/AatKGCMI+SHgBIkldAPEs/4hopsTD2WC/YDZEW2SVfUt0Wc
2JB8+Z9p4MkiDoMAKDItDkxyJ0AtRUZRPYhKZNcl142oqJKFChQsVFBJUQQwUIiATcEIm4bE
djkyLIsiydzbdRB9hO7me8XhvDnc3X07Wr2FpxeUqqqrp9ft9izJjaqqqqqszNs4XeM3g4Ks
qQQkuvA0mRjJMms1LjbDPsgcInB+H2OBdx7sOpV0SkRCiC6YhEciUMQlddSIW6OoG/z9kKQC
e98/ocv1L5PMznZNMEYIwRh7rTn9f319bToNEEYIwR+Y0Zv6PiX3OjkYwqqqqvCYXozR/n6L
u0nWCoLFNFVQEs7TgCgogJK7Vmc5mcY8DJkyYDGMdXrLueRfGLaW0tpbS2ltLaZcmjGCOKpd
BHpn1Aj6kNU0x3M+fLSlKUpleV6ru9judzyvV7XmqqqqrrhDXgRkO43+v3hxYycfjqTZDZQu
WW1s0XvrDblVi3SzKiIdkAyEKWrUChVRHAN7iwIUhNHXMupPJ4xOwZTnHH4taijFA/K4eR9J
8C+f0dBoAEQEgaxrYkcFkRhIIgIQZgAO+jT/vwG7GI6ZhZm1/L8bf4CrWAJRCDC0NkFioXI3
4lgoR9YDxjONUMfKYgQMo3oNb/PyMk170Dq8etyzjmGVTSN6RIkSJEiP3ECn6SSV3b3UEJCn
db6Ryn7aVkZmMkNKvf0dLD1OXLomg8Hg9zrrX0sdQVDAxs7EcPurlNZ16wUcZs1H56mMUfCu
v0JruMuam7joYzSRGEwdImMZeMA5Q8Ib0cockZRvcSQyr7v1KUqrDNMUWWVfHsL4nUkkTExM
S+jmzhsGt3xx9LEmajPDcN3DwN9zmSJTKZWSo5SIeQeOIMKcelm8dpUJLaEZIXpl3uZg8SES
iE4E3c/gsh15qfLWLp8O46nBz/e9KJBEWA7ljOjcmSjF1oBmDyWRxbX2l+VL7PNRbmowpaJZ
GYlmlQ8OOLlnIOc5/gcHoCkrKRZLRuRCI72PZn6fyjXlsS0y/mYc/RA5rKxR6LwGbynteL2f
oO8oM6l6lanShaJlrh/YAU2xo3xyrN9y9269QtFpf2rYq5C/V3J7E9iezPcnz58+e9e0FgsF
gsFgsFhiiCZhA7fVXMJtcfyGQY9VyuWTpPRAkJO16JDy0lMHk6FVVVRmGSeF2T2UUWLNW94X
N63W6+k0k0ozPnz58+nRpxjGENBpRRYqQhCEIUwUgkFVKKaYQfCEThdQAXIgioc4DjgKJFIg
UFBIkSJEiRISHjb7/34/vd9wfOHhCRqiRnHsBQczx8nW/KxfWx7XdRto4LbDxnnN8VQq3rtF
rYVZ35HeF5/eiR0DQ2tMWEMKLHRKmQ1BQtMwsMwqZhU8sWHGFTeivGExrxriI5IKwBggaIY6
zGQyidqDiULIlV1tbF4GtwNbOzGZmVVVdw4wijAEYjIikD4vVDUB1TO4NVRF0TWfIE4BcIQL
P1uLj7yIAnMXjCc/GdXzcWoyZWrj1YHvqRQLbFtXR8ZTlodkK4Ig+HqHT6dC2gWrkCHbO66W
vlnAB78Dp99AiyQWUomalKJkmottvscAALVAQ444OzgABVs/Lz3EEfnUrTAjjEhtxoI+ZpWG
49lk5++mtMESTp8lgKEh9khKcU5vSfZ1fNZ5v82mgqSgiIiIIIIiCII+Y5PYobQhhzHga82o
VFdbOsz4eJiXAAAiyUzM2EkhKmE6SFZv164zNL1uXLkgABNk4DuybQ0u4+Lg5vY0sRLkGwc9
mbNIqREeEsyQUXoxDeph7QEITs68vopKVU0ClBSxKYiJiIViJsyurkMo3FtrPq2luUtuQRzJ
QkIvKxghEf0uSBqBXJ29Qh24IpPFll6p6qUVs9x1vxN7lZjqJpAf7+7N56qKdIGIiMQYh5mt
vcgFBQUFBQxse7m3/jDN6mIQJ8n0e13s7fKhCTl6uNtPD2fDnEGgDdPvHSle2le2ldSV1JXq
pXbSvb5EDxNdeEJ9AcHBS3l6nGvCdnG8eMcRwB8VQhCtSdcEjZKce+amKRERFIiIikRDFByI
pERCChCEIKEIH52bdbs25T1pZLox2BeER4RIkSJN6/m3pNnc0kkwH+m733qdlH0tbKFPBgxF
xPIrYrMzDIYZmxsDHh+j7Xqe5+j5x2+jegSQ1QEZq08cuz4v59OaiiiiiwzEwqySyLwblHqU
/n/46/uahQk2QA9hTxX76tFwHpdtHaAJzgQLpPA86SSgYJCd2wIsAflpK+ghWYCCxRGSSKA8
35zHKyeYhiCLJ1OXF/zp8q4cEXwhs5kTERGWoiJiItREqiQJGEk4PU+P+djHYNY8Izzyj7gD
ywE9vJEVUP51YosVRYsQ6ITKQyBbshM/rbWIHg5PKSAAAAAAAAAAF1LLqaJat1SihbyTTGCU
SZBlcZwlLyJJbMYskiEKCgGe4czJ0j82YKoUpWMxBohSKwWQ2NAHFm0gsCRA9+hyYb+/rEJJ
3gBnPr+tPIQWLGanRcTl9Rf5Wiy2xbTnneiSTZN9nFm7QWiAUAKJt4vAlmZVVVVVVVVXP0dj
p4uMcfrbXlYuMaub5exsKzDIYZmkv7MONDh0qFEvqrqgtX1y8/lBUzDEeVbBvTEtOGbqzYuN
jUKqqooqBWBvRnASx/T7uOzd4HTd5S6xu1x1kIR+iNWIj6nzAacmxxWvm3PijWx6vN6MylKU
pEREREREREREcEDghEZ2+OX/O3ogBACAEAIAQAgIpKphqmzYDXeVjjj7+mvojxVLxrjmBhXz
wtwj2+nC2VydMzKgbSjG2QtWkLVVVVVVVyt6+TMAOmliIjuQUGlClGpREalSkKFLKwJlF+Gg
mrM5SJGTZHF3vf7/X7/f7/YMevsUana10DYavjxRFQwthZHE6UPD6PL4tvEvcjc3sY50Ka+v
uqLCllmtKNZQUQSUrBC6ylqZid7mzZlViqqqsd3AAdrf2QhnAOyGpCRk1ydDxF4x6fEqrkMh
z3ZkMwBse8FBSswo4vFwQUp6+PM2vMpSm49YlLO/eYUv9yrQsSuP50kszZ00Snf7PoW73s+U
lvIQbk7hSOf1QmAPFylJ33+w5Tc7pVxaqqqq8rh7sA7zh6vl39YcMN50PAjwhqUtqKUcpnrb
McLwLjZscrcUUi9iq4k6d06emG0Ftiak0UZDZNbL0qKGSxrtYphTbtW3U9R7uw+oNQ2/dZii
RK1phxyaladXDRLO/6lPnByQ9Ul3ek/7+FQwGwIqMnCDJZvlttokGUcW0SJZQZUSDjGMn1EZ
lIcYD4fxgl9k7ju4+kX2xkSz7V86k0xxe42+EHBWTkcZg2rlre3Dr4eNHN4295PJ5PJlllll
lvv8iMFtvV/N7T6G6DO6I+K43RfK3R29OGCdWZ+GXvuR8jySq+IRk6223HYdb92fTrFOuPNH
to5BJMIJQAqXolcAmpcT7sUF4BN0A74PQ/zjy1hMwMyGjAdnpoEeXEqTMzBN2ePW9sWPX1oc
p6jdHby/1JRlkNfk7nI8DpD1TiOc4zw7S1ValasKsNBfvjGTS09MhCEJZZdc2DF53G6oZaTs
dnAfpi9mZvJ7WSKWEXWErPV8H5MYbOM4Dn933Gjzsb2I6M+jFqG0OePga8R4Mb1sD4hxo+OM
7+UyOQdvz7bMn2D6AlFRY3nCQ5z6HYRc2ESX0URbOLea/tBZunlD52bhOE76/qtebyfbhgJi
JLG99BEfxtI3d841sP8EfeS3Knn/6UkeoIPCAqfV+Ej20orahQkbFVSKoWLlRVCQlSHTO4Jh
v7mB4r6UHrzwY9VlF7Ghcvn7g+PDD/HXoZU8U8ROHUQuZ+uVQBySMeEa9u5mtX4kEX87S8BZ
OzJDOEN6HF4pyee9lrWta1rWt1AeHk80FIGzp6JxzXdwzodFqEoxKTGqbRtFA74Lyg80Fa2d
jkYWrnCqnFWzQkBYYODCfGsvEmITMzDM0FtB7UhhAVMP+kZWqu11WcddrpS92jx0bDA388mT
zcPsVrXZ2heRnYV10zGs+M4nuNRnbReZCxVJlOIcMqXm1lzmT3PEOI4PzwvbaNMweBiKeZkH
3dd6Fq9t8j1qHYtOSbpybViHt0M0e8W+bikuHNjqISQ6lj+5vfpx4mxGE7Y6iHjdXB3C26y9
DzZHafWCozwq6o3w+xEj0BI9ISOLpb0ZpFkeNFZj06oxWQ1A4fmYq2UpTLSLvLc7L1h1RpA/
uA1gCgbZgRPamT3qr17ev2NUPMyquLbMwdefC2g9x66qqqqqqq5+Pbbbbbbbbbbdbe3bbbbb
bbbbbb4gd1n3U9U+m5J7bHtPd++1KqzNevZWkaoZMeSWFkyMleTjNt3UpdTszNmJe9/+t9dy
O+n3ebzWkxjpnDKQe9n0p3bNyp0iYF03Tdddhs6UuFERpKDhj+kckcw+LEJtfEExSeoUCwGz
uBPiSRiSYATw+xjEc2TJjJIgxCUdEtusiB4c+GSiDYFFCI0rgXx+t83DzrWWihXBRyCUSlEZ
cUHGTLHZ0cH9qBfzJVVVVdnPsbR3R63S8G22222222222222227FubMZj0betiTEmJMSW3re
n7f0/P9A3QNJDWDEKJYhLbFaVx48ePHaeXsjrt5o0Tu9zpTrC9iMWVqiWqN3MULjQaCouNBo
PILzB9LHOCrKitk2ZliKFxkMhUZDIZDIXm5rIYp1Oznb81E8cc0kbZ4x2h2B7vgzNwG8B6pO
VxAZdj9fxwnpalVVVV4AMobJ7wFsMpN2trjoFo4Ikbg+BHgc34M6ciYbRI0EZhqMsp2vdVbC
VC+DdqPhV3mxbSO+H1duPP8brUocVjJ7jus0pBENRuCzO64WFQAwTpEDJJiPZtAOEimnFf4U
zZ2cCk8wjqEeQLDtrzomGkz0CihxyUh1t0Asp6GEqHdfU8cBqOimpFsQ5bDALNJ8/nuXHn9S
3E00hlJyJKGRqq7cwzKlanqczhjZMTCZIlVKqViJYVC3pThFq57OxYbvLUR50hrPeXzNmudE
vM15UnSvkDL/D8N4LY5mt2UEDgG4/Zcx6wmLAGfbrOAv9Byt4ijwN1jxMh4HI5Ej5J07HAtg
UgKcn5VXNCXAcHiKNFiiqXp/2WKrlx66wpKYrRYlKsXz/2H4of/POmUovv+bhpFTATTF7yvI
4zjzUZjNMPEdQVkaeMkEMbMqRloyO88AvvfPixmFxTtUiSzAc0pQm21z5yfOdtVSkzbUX0C8
txPAKbjj7b4Px+YfDP/nPn1BsbAagtDLzrdkjJJv43w/MhT/76rM8iw97UX5VBkjngDACRBM
AoLwh6Evx7BYie9KGciIaoQsKCKiZQSB/+LuSKcKEhJNhsmA
--------------030302030402000700080000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030302030402000700080000--


From xen-devel-bounces@lists.xen.org Fri Jun 08 10:19:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10:19: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 1ScwHs-0004vB-By; Fri, 08 Jun 2012 10:19:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1ScwHr-0004ux-2s
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 10:19:23 +0000
Received: from [85.158.143.35:62352] by server-1.bemta-4.messagelabs.com id
	A5/8F-10042-AA1D1DF4; Fri, 08 Jun 2012 10:19:22 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339150759!14996725!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3927 invoked from network); 8 Jun 2012 10:19:21 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 10:19:21 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id 1F59FA5
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 14:19:19 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id YWFjmlN3GrHv for <xen-devel@lists.xen.org>;
	Fri,  8 Jun 2012 14:19:18 +0400 (MSK)
Received: from sysadmin.office.main.elserv.ru (sysadmin.office.main.elserv.ru
	[192.168.3.135]) (Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id 9C05C1C
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 14:19:18 +0400 (MSK)
Message-ID: <4FD1D1A6.4090900@elserv.ru>
Date: Fri, 08 Jun 2012 14:19:18 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
In-Reply-To: <4FD1C9370200007800088AD8@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------030302030402000700080000"
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------030302030402000700080000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

08.06.2012 11:43, Jan Beulich пишет:
>>>> On 07.06.12 at 11:29, Alex Moskalenko<mav@elserv.ru>  wrote:
>> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on
>> IBM eServer x3400. Without noacpi command line option dom0 kernel
>> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
>> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor
>> all kernels run without any problems.
> This is an issue that was reported and discussed previously.
> Fundamentally, it is a firmware problem from my pov: ACPI has
> _nothing_ to do with the MMIO space used for the IO-APICs of
> the system once they are under control of the OS. It shouldn't
> even be reading from them (which iirc was the case in earlier
> reports), but in your case it looks like it's even writing them. I
> had been considering to allow Dom0 read access to those pages,
> but obviously this wouldn't help in your case.
>
> Could you extract and supply the ACPI tables of that system, so
> we can make an attempt at checking whether there is some reason
> for the firmware writing to the IO-APIC that we didn't think of so
> far?
Please see attached archive. Tables are grabbed with acpidump -b under 
Xen 4.1.2 and patched kernel 2.6.32.

-- 
WBR, Alex Moskalenko


--------------030302030402000700080000
Content-Type: application/x-bzip;
 name="acpi_tables.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="acpi_tables.tar.bz2"

QlpoOTFBWSZTWZJsNkwAGLH////////////+/////f////v//n/V/1X+x+dE8FRU/unJ4CW9
901ctxd2qy83F1T3bdzsbVG94bvZ7t4FmD2xOuop29c7UZWpvNrTSttQNg5bu7mtdLjcZOrl
g7rb2zO64dmp07s1ve72yJK3c95SilpgMRSQprpkrtsJJBCEaaaYgJtMmmhkIyZGmhlTyZT9
NTJPRp6nqRsk09Mp6jQ2jSGjR6IyA9TTRppoaDQ0DQAaA0DQZADEEoUaaYgTTEICaaZAiGmy
TMp5RtRmpkYjCMJoAAGmmg0AAAAAGQDRoAAAAAAaA1M9SnpKap5NT1PahPUep6mmg0GnqekG
jIGah6mh6gA9QMQNAGgADQAAAAGgGg0AGgBpoAAASaUoCE02gp6NTJtGkGjTTSZpT8ITyU81
T1PUZiaanqeo2oGgDTQNHpNGgD1AANHqAaAAAA0ANANBpogZMmQDJkABpghoA0AAGhiGmgGQ
AAaAaBkNANADIDQNNGINGgAANAAGgKoiCATTQm0INARkwk2BMJkyJ6EBpG9MlPUz1NTR6JtC
ZGhiGJoaDINPSAyANGjIGhoAaADRofIyfIySBsgHo5PqdIFgaAYGXdoOjG3uW2223Drf4YUF
ZDaTin4CH/1J7zvd7A9bY9j1UL8AmQqQEFGUx2fo1fh43V0dZSCHc6QCQ5UKFReVfMln52eE
8qYQoODSglA42nbVPcyiMvy6Qh4MjANBFMQk9XMMV1GDHQij6PgVgMV0qBxJgcSG4ydJ5aBm
jCCkHqzx/Tejly9+Br4IS7ta7SIlBSUHWFxS7rUa08WYiIsshyhUYnBYHAgGoAZDSyGlBVKk
A2eQSiDAGcxt9P3Hdt03953vU+KVrfgfX87HM87HmNjm4dsaXdNl/bPNPvHnFG8xq6VrP8M/
EZO8JTy/+XTVPH/VJYqszJkyZOCfcc2hu9DIQmRNx47AMvnGeZvWQysZ2EDM486yXPc+sWqy
l2SkFqRZDLTppgb/u88fJHq1KYPwK4MVlc3ZnaTOtuajtZ09dc8oJ9FPYV1Zqn0sqirlZNNJ
EAYZ0pSlKT30sqqqrKWqaad0pSjGL4cZmizRjGMYxgJOHMITRjGL4xi+FrNFmjGMYxi8hCEI
QhCEKRYNCEIQfCGGMsQ5ceZqxEKImIQUvMu6WRqbgdr3lURokDF7/4LyvyuOssoka8nCiYFG
lJKiZngJGC1lBtNB/dPgzBkQKiHcVz83dzEDC8PdYxys+DhycOWnc+rq3ut9O/b7NJp7qbuu
zddLrvFUwLo1DEhIT7rHSfNb2l/AbZm7SiG1oyqaLXw042CHaLoMXtHP8jUHJ4xQ2ZJE7rtJ
b/wfwrEfmCXlSMZbQXjS4lEZMc0A2k8XJ2vCyQ78yawKGDaZCYa9B1l6dIUDpuHVO36GDm2+
7vM/Xz+lwO69vqZmhEN1sKO+Zkd/gpAREMuzGcIpHLwwIAtuNfbftjbcbu3LNbA7QOs53xnO
6Gg49Zdu1MDufGVVVfBDNlzPpGMYz9Ahugag9tesw2DSBnEmtvAAKJOIUXlWZmZsBJQnrVma
rxE7xkVrWta1rCibLLiSlcr/Vu63kpJ+Mwb7MZY0hg6PR496X50G59DkcUYr+3yOntcl/ev5
WIVcJxy++p33tvebPYzIP/ME/MA4IPY7Q6IHsbB7fxBw/E5is8yZ5iz2pzh7Cc5KSamfIYyP
YfBTLltt0G+YphGPnjVpPxva5Moe+n0npPtVT0Z9J6T0q+hKIeVtbgdeyEFuh31a9buUpSlK
aK1r7267x8Hd09HZmES29O29TmXOkD0HmAArEB5p4C07kMxM/qXhhBABEBBUSGk3MeWO+kNc
Ss3xCT5VkzMRMFwTk2ESxghHwdnPvzga1XWbg6kdjXlnT9qS/Fgj7e6wYw25M1MvA4DAJGAg
xjMvrHI0aCPS8bHh+gTv8eZ/N5vfvmoY3tIezzPhP+Zubj/teX5j8biMkXwJZeRbeAejXyPF
Z2XmSILhhg4jqvu4sc25dfMwm3+W8SKIySYBhNjgyBhMIBi/tGVmtacVFN5w0zvzPAgIORwv
Pm4JjS+Rdr6l+BfMRFpKZgmYJQ63V2fE3mXq39UhPYGBxvsN4k9kt/qNvuRHE2/VP8jDHlAT
0XkpK9CL0mmB72RLtf4Hd7JzSAXZNWgndAqNuDJaLMCfzYMhJMTx8SQsVJA7I7oGKggO2G4H
xsntX10pbIcffb8uRJii1nIUsg26cCnAzMyUtQXnozCFbNbLw7cfamkQfruBQumEPuiJMgju
dqXbtEL4JgLwC41waqsIRqzpREWqSKtXwupLIkyPc6OfCdzCMBgMBgMBgeeT5kiIiIiRIiIi
IqqqIqqqqqqqqqqqqqqqqqquTqd6B6AVj28mLhQ/bqQq5vXrbLTLDPCx0iEfTlo2qDa2KCWS
JAtywWQgEp5BhmBbA3YSat9PsF3Fpz7F3V7K1JbHF1L8i7jWOnHEx+fYy8KPus3Q03ITt+0r
wI69D2u4M5wgxKGNFWynRWGBh4kIZDO6wLDcYjEW0wL9U/f+Bu5o0LuXpduzGXQNiR6viGC5
6F8XwrEZtufzByL9AvZB4Vu0VJNqmPj5hr6cY4N7rifMz4Gnp62e9GjapBYZBxTEfLOE2cu1
vN5HJ0vae7GfusurCGASCLIHgnTBEEOXy2ILGZAwBkA5WaZLNRh7XvOaVKJZi2mNoM7oK7ve
TMzMzMzMzMzMzM31eXupcLoemrB6oFoIUkwC2WWWWWXRQTRyoQqlNNKUvxpjIOg5mnRZu0BZ
ZZZZZfnEO4UzRGYXxYDTUgYpVTk2WpreszxQiRy5vXAOuilayGg0y4E2FznaWajS993R3Q4H
rLE4y8WZsjKu6aSmUuI6cw0uoWmeG1tPhv7nJ4eGHL4VoWj3rgNSa23kyDjTSZu+bbatQy8y
eR5IKFE1w3Qz8rfFzo4+JzPnoff7V5F3S2KVh04Ha56P4rDA6YWGuoCHAMIrV7t27d0c/Pll
llllllsgXKtyrem/ByQyEUYyHMERk5EVJZkLWlIMouCkSyglRgOMYw4uLih42bmd7SygjOIM
JOnSHcEIQnd0IQgAAAAAAKq1rtFllmP2fKnM1BMeeadMRRH6QmL1FIgkCB7ACboboRgijEln
moRhys+2ag2hmFfhXruZmOiMuqpA70UyuJCoqIoKmSYjlvEnvsxLdmcS8DIClAHijxUvzYWe
G7nzHreQYF6KigKCy7oBURhO9AukizBZdqmMZydm1i/WiUjGo1lLSQqKiKCpv79qJp3LValv
dhmJxVHbOwYDwUMQzY4Nse+v6PWTu86GfIoRUUBQWr6W5ztOPQac+msxbWfTqg5znOdkW9Pf
sb2AOFRURRUnrNg2AYMkQoChFiRGeuHkgb2retpzjmatnY7Po4exPBA4jMbHcyKbbNtWjYbB
Q5g0atRjyvqnEcG3c3dThflLrtOzwNqzWaxQyb0vpxeZogXl5qDbbbNv8eG5ddubmIxG3QvU
AVYAUuV22bFlhYjyw75mRFUhbYBsijwqlPxeRUq0bqG0sLxbOJbbxLuJ0laENpV3CsCxA49v
abAUheCTxL82a6kKQpDRUgRLciglJEYCAKEAtSneHvrrgEAriJDmA4HAyQhCEJUhSEw1evzr
dni3AX22qrtlb7RA9SAbeYqHPVuv3ilDgqI5UEHrAZk5IPnMQZCPFHRjSd4Kh4Y0oU7WBi2s
a1am+bUdQYmSU/tMhqWb/KUspM6elYs42ErbOlMenPASY57NWljjjji5znOdaEVoe+vhiyeB
rDIb3T0gKB5IBQz9clO9z6uLoPEGsb07mJycnsubY43Dq42yWj5EhsqKqp6qqqqnve97307M
VqKi4zhLACgLYdSDiwVZVNprK12hN8Trk3S0ko8VhFV9lnL1YvQ62J99LJlmdDHY0cDNWlKd
SS5dTBVjIms4tirv8qNGXviGBWt64MFRUVZTd/ZAx7BwXOExpoYcQ9pikMCn2Y38Uj1yXCND
DWF+Sh4ctzOpnUdwIWAK/l+P5ORQARXr5+fvN5vNTh7QKl6uCXvt4VanA5ncT14nxWac/QnT
0RNVZiikGT8fLkCYI8Klh3pIjCg9Dl9SyOjHNHAZDAUKZTJKeSCEt9YsWLFixYsZmtcJ5PIQ
y8url0+Rh269u3vRCWzDo37CUxmMC7ZWh3PN9beLKQX9WrVq7v3CmrU61bciC0mAuF8J3Pzg
N5hTH3ZAG1WZ2rqs228BjifK2uyOf3KoypekYpKYETMzP2Uudnj1NvL6nHcnu4aMufQ7DsL5
AYErkBaXG5wPgwMiNCLRUbew6D3PbV9ny4wRicVy3bJVwpUAcTOKlaS4amqza+vr09fX3gFV
BkJKxEiTJUghOBPOiT8YsRhV0z2WWbFHHqAZKlF1J0jY2Wwmzpx97B3fkcRy5NPiUWrIsJTH
XKlDpZyAxjKjKs6S1QPw7WVmbJmyAAAAAABVrXvFllmzEGvqZlJJ1KKERqS1JhCPJiHIwUgs
KxnQPBIYtLEQL05pen1agA9IO7y7FkrlKQ2S+OcUwKQLXGESLhaJhaB0x0pZYdG4MJsx+awG
76AsfGjhcijt8pqgIo8CEGhRCEOXbGUN7fnTdim/eT9k5dJTTRGqbBCZgvTKyi35Zoqc2+Mk
zWLTfm9HbJRmO3ufMmleFusdSa8gIpITIAokKEOtRx232REcBQk6kzLFDHVD/USLLUqWmSvG
lt3eyq4OuZzE8kW054hZxGRZcLqGTeQzVswoRFtEXk2XiSiUlYeTFfgieeG7x77kJhbMav0a
0s32Th4Mqhl1u8ETif851AaiNu2HlJs2kIjE5nFOu70+U/Pb58zvMl8qA+873gAX4fWp2cWI
HLDAn051UgOqt0lsZ77/l/Hfk0tIp78i2Qy9DoR0P6cBsDjz2sXTyW5Bhx80qLfsMQ8FpQJa
RdCmBRW1LItGIDRNCJOHz9/DBszVpYaWBqSXwBCoM2e4k4cNLcL6J6CgY7iGz21gOnp7wEtL
3TIIItEkEXgoC+5obl8Wsrc7WR6RMLHM0zV4dZmg9SJC0WSMOTyOpfLNt+Jssq2wr67iHHqq
KMyc8UYV6jKoqTDM9WUkTc4GIsGFY4mOBfVIlItxNAtcwghsKgIfucBCu/REVXTWYKSFp5lq
FKYKGCDc5VVaUUOHmUwimRKmzactrv9+Y28wHK6fOixZ2PPm3JrGxypAJp4VpbrBAmMYtuJP
gSCpz0c5zMzM22OnNmgMxkZiYc7bJpu/A4EuEbtJIbScC5rcIxi5Iv0TNw1qqCrFw2sa60LW
OTBmqGRJALls90ZoENLYWy2t266mnf0VXJDX36ydErJ0spk0GJMCOQslN1sicgxrhTMXdAQ3
zfKDA1q6ipEnzrdwekZEJlODYIZ53KCqyIY7tQmpcxfYBuIxcFO1rVG40UiZyEBU3MnAM2Bk
XbBSJFgZVTFuDcW2zOsNWRVVg22c1WMi9JCiEQUeSYuUSIKBp1uFqeYQVtHjAKsb6du++mG1
ozZYyFcYij2J815XZNuoKZxV2ldwZyZFFKy7PXcN/FGqW3akb7V2xSmJrptYDDjGGRZYIoCd
+g0arWcNSLcs01tVOOeGmjTmtApls332DkGWekaTbY0z0zatrk3bob5jkYDBjcF3ruEEyPoc
G9sBknNriVmust06u0UpXZYRc2TFvDFZYKlloU7Bnw1YCEzY4q7fGiaTQuNhrylU7Wwwz4Ct
OZxRSzLgasU0EySkhOlMZEN6MuCGzOsrj2bVKSrMzMzWE00zMzM1GmdtQTTVXl4QewDstFZo
s0aL8p9FlZSTCpUqKwpVPz7jdtZMgLJpkYbXrzC4YSatma4wBzswTAKHQ0KBr3yFJUZW5ZOs
yttFYsFFJuozmwuQLWwDCGIgrllmFkQxkq1mIOcwHgwHY34khSUVuwow3ayQK67AZtYpsmjF
lRhBRLSqq0bNXfaq3F4OcwE+BtmByFVxLeBRQNITPo4eEtW22222223PrTmZjEhrzf8TBsbw
Gvzv3BzZHD/5yZNTkK+Xko1WxbveMk50OjzZ9ZHXb7bIyMmCFDCjAUomqz70K0tnWyrIiOVY
UvmJuiRqJVrnQazk4dEcq2zh6gmCKQhWy6Y3xRLCoqotIaJTaKIUUEpEpGbg2Tr+19/5HNPR
1kesRict5Hk3LDxvIiIjl9QN/AatKGCMI+SHgBIkldAPEs/4hopsTD2WC/YDZEW2SVfUt0Wc
2JB8+Z9p4MkiDoMAKDItDkxyJ0AtRUZRPYhKZNcl142oqJKFChQsVFBJUQQwUIiATcEIm4bE
djkyLIsiydzbdRB9hO7me8XhvDnc3X07Wr2FpxeUqqqrp9ft9izJjaqqqqqszNs4XeM3g4Ks
qQQkuvA0mRjJMms1LjbDPsgcInB+H2OBdx7sOpV0SkRCiC6YhEciUMQlddSIW6OoG/z9kKQC
e98/ocv1L5PMznZNMEYIwRh7rTn9f319bToNEEYIwR+Y0Zv6PiX3OjkYwqqqqvCYXozR/n6L
u0nWCoLFNFVQEs7TgCgogJK7Vmc5mcY8DJkyYDGMdXrLueRfGLaW0tpbS2ltLaZcmjGCOKpd
BHpn1Aj6kNU0x3M+fLSlKUpleV6ru9judzyvV7XmqqqqrrhDXgRkO43+v3hxYycfjqTZDZQu
WW1s0XvrDblVi3SzKiIdkAyEKWrUChVRHAN7iwIUhNHXMupPJ4xOwZTnHH4taijFA/K4eR9J
8C+f0dBoAEQEgaxrYkcFkRhIIgIQZgAO+jT/vwG7GI6ZhZm1/L8bf4CrWAJRCDC0NkFioXI3
4lgoR9YDxjONUMfKYgQMo3oNb/PyMk170Dq8etyzjmGVTSN6RIkSJEiP3ECn6SSV3b3UEJCn
db6Ryn7aVkZmMkNKvf0dLD1OXLomg8Hg9zrrX0sdQVDAxs7EcPurlNZ16wUcZs1H56mMUfCu
v0JruMuam7joYzSRGEwdImMZeMA5Q8Ib0cockZRvcSQyr7v1KUqrDNMUWWVfHsL4nUkkTExM
S+jmzhsGt3xx9LEmajPDcN3DwN9zmSJTKZWSo5SIeQeOIMKcelm8dpUJLaEZIXpl3uZg8SES
iE4E3c/gsh15qfLWLp8O46nBz/e9KJBEWA7ljOjcmSjF1oBmDyWRxbX2l+VL7PNRbmowpaJZ
GYlmlQ8OOLlnIOc5/gcHoCkrKRZLRuRCI72PZn6fyjXlsS0y/mYc/RA5rKxR6LwGbynteL2f
oO8oM6l6lanShaJlrh/YAU2xo3xyrN9y9269QtFpf2rYq5C/V3J7E9iezPcnz58+e9e0FgsF
gsFgsFhiiCZhA7fVXMJtcfyGQY9VyuWTpPRAkJO16JDy0lMHk6FVVVRmGSeF2T2UUWLNW94X
N63W6+k0k0ozPnz58+nRpxjGENBpRRYqQhCEIUwUgkFVKKaYQfCEThdQAXIgioc4DjgKJFIg
UFBIkSJEiRISHjb7/34/vd9wfOHhCRqiRnHsBQczx8nW/KxfWx7XdRto4LbDxnnN8VQq3rtF
rYVZ35HeF5/eiR0DQ2tMWEMKLHRKmQ1BQtMwsMwqZhU8sWHGFTeivGExrxriI5IKwBggaIY6
zGQyidqDiULIlV1tbF4GtwNbOzGZmVVVdw4wijAEYjIikD4vVDUB1TO4NVRF0TWfIE4BcIQL
P1uLj7yIAnMXjCc/GdXzcWoyZWrj1YHvqRQLbFtXR8ZTlodkK4Ig+HqHT6dC2gWrkCHbO66W
vlnAB78Dp99AiyQWUomalKJkmottvscAALVAQ444OzgABVs/Lz3EEfnUrTAjjEhtxoI+ZpWG
49lk5++mtMESTp8lgKEh9khKcU5vSfZ1fNZ5v82mgqSgiIiIIIIiCII+Y5PYobQhhzHga82o
VFdbOsz4eJiXAAAiyUzM2EkhKmE6SFZv164zNL1uXLkgABNk4DuybQ0u4+Lg5vY0sRLkGwc9
mbNIqREeEsyQUXoxDeph7QEITs68vopKVU0ClBSxKYiJiIViJsyurkMo3FtrPq2luUtuQRzJ
QkIvKxghEf0uSBqBXJ29Qh24IpPFll6p6qUVs9x1vxN7lZjqJpAf7+7N56qKdIGIiMQYh5mt
vcgFBQUFBQxse7m3/jDN6mIQJ8n0e13s7fKhCTl6uNtPD2fDnEGgDdPvHSle2le2ldSV1JXq
pXbSvb5EDxNdeEJ9AcHBS3l6nGvCdnG8eMcRwB8VQhCtSdcEjZKce+amKRERFIiIikRDFByI
pERCChCEIKEIH52bdbs25T1pZLox2BeER4RIkSJN6/m3pNnc0kkwH+m733qdlH0tbKFPBgxF
xPIrYrMzDIYZmxsDHh+j7Xqe5+j5x2+jegSQ1QEZq08cuz4v59OaiiiiiwzEwqySyLwblHqU
/n/46/uahQk2QA9hTxX76tFwHpdtHaAJzgQLpPA86SSgYJCd2wIsAflpK+ghWYCCxRGSSKA8
35zHKyeYhiCLJ1OXF/zp8q4cEXwhs5kTERGWoiJiItREqiQJGEk4PU+P+djHYNY8Izzyj7gD
ywE9vJEVUP51YosVRYsQ6ITKQyBbshM/rbWIHg5PKSAAAAAAAAAAF1LLqaJat1SihbyTTGCU
SZBlcZwlLyJJbMYskiEKCgGe4czJ0j82YKoUpWMxBohSKwWQ2NAHFm0gsCRA9+hyYb+/rEJJ
3gBnPr+tPIQWLGanRcTl9Rf5Wiy2xbTnneiSTZN9nFm7QWiAUAKJt4vAlmZVVVVVVVVXP0dj
p4uMcfrbXlYuMaub5exsKzDIYZmkv7MONDh0qFEvqrqgtX1y8/lBUzDEeVbBvTEtOGbqzYuN
jUKqqooqBWBvRnASx/T7uOzd4HTd5S6xu1x1kIR+iNWIj6nzAacmxxWvm3PijWx6vN6MylKU
pEREREREREREcEDghEZ2+OX/O3ogBACAEAIAQAgIpKphqmzYDXeVjjj7+mvojxVLxrjmBhXz
wtwj2+nC2VydMzKgbSjG2QtWkLVVVVVVVyt6+TMAOmliIjuQUGlClGpREalSkKFLKwJlF+Gg
mrM5SJGTZHF3vf7/X7/f7/YMevsUana10DYavjxRFQwthZHE6UPD6PL4tvEvcjc3sY50Ka+v
uqLCllmtKNZQUQSUrBC6ylqZid7mzZlViqqqsd3AAdrf2QhnAOyGpCRk1ydDxF4x6fEqrkMh
z3ZkMwBse8FBSswo4vFwQUp6+PM2vMpSm49YlLO/eYUv9yrQsSuP50kszZ00Snf7PoW73s+U
lvIQbk7hSOf1QmAPFylJ33+w5Tc7pVxaqqqq8rh7sA7zh6vl39YcMN50PAjwhqUtqKUcpnrb
McLwLjZscrcUUi9iq4k6d06emG0Ftiak0UZDZNbL0qKGSxrtYphTbtW3U9R7uw+oNQ2/dZii
RK1phxyaladXDRLO/6lPnByQ9Ul3ek/7+FQwGwIqMnCDJZvlttokGUcW0SJZQZUSDjGMn1EZ
lIcYD4fxgl9k7ju4+kX2xkSz7V86k0xxe42+EHBWTkcZg2rlre3Dr4eNHN4295PJ5PJlllll
lvv8iMFtvV/N7T6G6DO6I+K43RfK3R29OGCdWZ+GXvuR8jySq+IRk6223HYdb92fTrFOuPNH
to5BJMIJQAqXolcAmpcT7sUF4BN0A74PQ/zjy1hMwMyGjAdnpoEeXEqTMzBN2ePW9sWPX1oc
p6jdHby/1JRlkNfk7nI8DpD1TiOc4zw7S1ValasKsNBfvjGTS09MhCEJZZdc2DF53G6oZaTs
dnAfpi9mZvJ7WSKWEXWErPV8H5MYbOM4Dn933Gjzsb2I6M+jFqG0OePga8R4Mb1sD4hxo+OM
7+UyOQdvz7bMn2D6AlFRY3nCQ5z6HYRc2ESX0URbOLea/tBZunlD52bhOE76/qtebyfbhgJi
JLG99BEfxtI3d841sP8EfeS3Knn/6UkeoIPCAqfV+Ej20orahQkbFVSKoWLlRVCQlSHTO4Jh
v7mB4r6UHrzwY9VlF7Ghcvn7g+PDD/HXoZU8U8ROHUQuZ+uVQBySMeEa9u5mtX4kEX87S8BZ
OzJDOEN6HF4pyee9lrWta1rWt1AeHk80FIGzp6JxzXdwzodFqEoxKTGqbRtFA74Lyg80Fa2d
jkYWrnCqnFWzQkBYYODCfGsvEmITMzDM0FtB7UhhAVMP+kZWqu11WcddrpS92jx0bDA388mT
zcPsVrXZ2heRnYV10zGs+M4nuNRnbReZCxVJlOIcMqXm1lzmT3PEOI4PzwvbaNMweBiKeZkH
3dd6Fq9t8j1qHYtOSbpybViHt0M0e8W+bikuHNjqISQ6lj+5vfpx4mxGE7Y6iHjdXB3C26y9
DzZHafWCozwq6o3w+xEj0BI9ISOLpb0ZpFkeNFZj06oxWQ1A4fmYq2UpTLSLvLc7L1h1RpA/
uA1gCgbZgRPamT3qr17ev2NUPMyquLbMwdefC2g9x66qqqqqqq5+Pbbbbbbbbbbdbe3bbbbb
bbbbbb4gd1n3U9U+m5J7bHtPd++1KqzNevZWkaoZMeSWFkyMleTjNt3UpdTszNmJe9/+t9dy
O+n3ebzWkxjpnDKQe9n0p3bNyp0iYF03Tdddhs6UuFERpKDhj+kckcw+LEJtfEExSeoUCwGz
uBPiSRiSYATw+xjEc2TJjJIgxCUdEtusiB4c+GSiDYFFCI0rgXx+t83DzrWWihXBRyCUSlEZ
cUHGTLHZ0cH9qBfzJVVVVdnPsbR3R63S8G22222222222222227FubMZj0betiTEmJMSW3re
n7f0/P9A3QNJDWDEKJYhLbFaVx48ePHaeXsjrt5o0Tu9zpTrC9iMWVqiWqN3MULjQaCouNBo
PILzB9LHOCrKitk2ZliKFxkMhUZDIZDIXm5rIYp1Oznb81E8cc0kbZ4x2h2B7vgzNwG8B6pO
VxAZdj9fxwnpalVVVV4AMobJ7wFsMpN2trjoFo4Ikbg+BHgc34M6ciYbRI0EZhqMsp2vdVbC
VC+DdqPhV3mxbSO+H1duPP8brUocVjJ7jus0pBENRuCzO64WFQAwTpEDJJiPZtAOEimnFf4U
zZ2cCk8wjqEeQLDtrzomGkz0CihxyUh1t0Asp6GEqHdfU8cBqOimpFsQ5bDALNJ8/nuXHn9S
3E00hlJyJKGRqq7cwzKlanqczhjZMTCZIlVKqViJYVC3pThFq57OxYbvLUR50hrPeXzNmudE
vM15UnSvkDL/D8N4LY5mt2UEDgG4/Zcx6wmLAGfbrOAv9Byt4ijwN1jxMh4HI5Ej5J07HAtg
UgKcn5VXNCXAcHiKNFiiqXp/2WKrlx66wpKYrRYlKsXz/2H4of/POmUovv+bhpFTATTF7yvI
4zjzUZjNMPEdQVkaeMkEMbMqRloyO88AvvfPixmFxTtUiSzAc0pQm21z5yfOdtVSkzbUX0C8
txPAKbjj7b4Px+YfDP/nPn1BsbAagtDLzrdkjJJv43w/MhT/76rM8iw97UX5VBkjngDACRBM
AoLwh6Evx7BYie9KGciIaoQsKCKiZQSB/+LuSKcKEhJNhsmA
--------------030302030402000700080000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030302030402000700080000--


From xen-devel-bounces@lists.xen.org Fri Jun 08 10:52:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1ScwnZ-0005TI-EA; Fri, 08 Jun 2012 10:52:09 +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 1ScwnX-0005TD-SE
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 10:52:08 +0000
Received: from [85.158.138.51:29885] by server-3.bemta-3.messagelabs.com id
	11/F4-25608-659D1DF4; Fri, 08 Jun 2012 10:52:06 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339152723!31403760!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12790 invoked from network); 8 Jun 2012 10:52:04 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:52:04 -0000
Received: by qadb33 with SMTP id b33so696313qad.9
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 03:52:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=AJRzASSfUPUxb4AHxg7TSK4NvOnoopRfb55CBrFi22I=;
	b=xpJTJvXOqMKiVONGvMd9Rl+XSbfRStlwcgW/sYj4uGgkeRB5LG0vuI4fQ0/V1M1DIs
	VgATwVWPNulS4+BaKvarXsiWXS+pLG4L17LP6aAWI//apQtY2Wbnw55Q06eFr5Vwg34r
	/KOt6Yaidqaywo0AHyqyaiA53mqCXK3lmCkN3YHqJ011eG6d8cSWu5ZWqq5BmlT0qTPe
	ADp8q5VdhShXJ2vJyncTsWTjNXwqJ5Xjta2+/r58Mi4bHeM+lk4gAg8LHpsSx1RrtZGm
	EmZMpPSE+uP7hndik//4EnQ2fKY+7kimXz7fxWyyKjoeKP7VN7ihFT0lAY4chFl1LGNY
	Gklg==
MIME-Version: 1.0
Received: by 10.224.101.8 with SMTP id a8mr6759800qao.1.1339152723046; Fri, 08
	Jun 2012 03:52:03 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 03:52:02 -0700 (PDT)
In-Reply-To: <20110509082716.GG24068@whitby.uk.xensource.com>
References: <patchbomb.1304690477@elijah>
	<be5d93d38f283329dea1.1304690478@elijah> <4DC40841.9020108@amd.com>
	<20110506150028.GF24068@whitby.uk.xensource.com>
	<4DC40B7A.4010605@amd.com>
	<BANLkTinsZO5ZObUDtEVoTU_SWzW8c6scuQ@mail.gmail.com>
	<20110509082716.GG24068@whitby.uk.xensource.com>
Date: Fri, 8 Jun 2012 11:52:02 +0100
X-Google-Sender-Auth: e5BGs3DUMy-f4ATp661KbOR7qGo
Message-ID: <CAFLBxZbBpSoAQrRsZD_xg7poii2xsCBafC3b1bFe+eubg_2Oxw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4] p2m: Keep statistics on order of p2m
	entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, May 9, 2011 at 9:27 AM, Tim Deegan <Tim.Deegan@citrix.com> wrote:
> At 16:34 +0100 on 06 May (1304699686), George Dunlap wrote:
>> This patch is actually not necessary for the series -- just for the
>> verification that it worked. =A0I could drop this patch so we can
>> discuss it, and send the other three by themselves (since they seem
>> pretty uncontroversial).
>
> I think that's best. =A0I'll be looking at reference-counting p2m entries
> soon, I hope, and I'll add some bookkeeping when I do. =A0I suspect I can
> isolate it into a single place then.\

Tim, I realize this is over a year ago now, but did you ever end up
adding this bookkeeping?  I'm trying to port this patch again...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 10:52:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 10: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 1ScwnZ-0005TI-EA; Fri, 08 Jun 2012 10:52:09 +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 1ScwnX-0005TD-SE
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 10:52:08 +0000
Received: from [85.158.138.51:29885] by server-3.bemta-3.messagelabs.com id
	11/F4-25608-659D1DF4; Fri, 08 Jun 2012 10:52:06 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339152723!31403760!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12790 invoked from network); 8 Jun 2012 10:52:04 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 10:52:04 -0000
Received: by qadb33 with SMTP id b33so696313qad.9
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 03:52:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=AJRzASSfUPUxb4AHxg7TSK4NvOnoopRfb55CBrFi22I=;
	b=xpJTJvXOqMKiVONGvMd9Rl+XSbfRStlwcgW/sYj4uGgkeRB5LG0vuI4fQ0/V1M1DIs
	VgATwVWPNulS4+BaKvarXsiWXS+pLG4L17LP6aAWI//apQtY2Wbnw55Q06eFr5Vwg34r
	/KOt6Yaidqaywo0AHyqyaiA53mqCXK3lmCkN3YHqJ011eG6d8cSWu5ZWqq5BmlT0qTPe
	ADp8q5VdhShXJ2vJyncTsWTjNXwqJ5Xjta2+/r58Mi4bHeM+lk4gAg8LHpsSx1RrtZGm
	EmZMpPSE+uP7hndik//4EnQ2fKY+7kimXz7fxWyyKjoeKP7VN7ihFT0lAY4chFl1LGNY
	Gklg==
MIME-Version: 1.0
Received: by 10.224.101.8 with SMTP id a8mr6759800qao.1.1339152723046; Fri, 08
	Jun 2012 03:52:03 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 03:52:02 -0700 (PDT)
In-Reply-To: <20110509082716.GG24068@whitby.uk.xensource.com>
References: <patchbomb.1304690477@elijah>
	<be5d93d38f283329dea1.1304690478@elijah> <4DC40841.9020108@amd.com>
	<20110506150028.GF24068@whitby.uk.xensource.com>
	<4DC40B7A.4010605@amd.com>
	<BANLkTinsZO5ZObUDtEVoTU_SWzW8c6scuQ@mail.gmail.com>
	<20110509082716.GG24068@whitby.uk.xensource.com>
Date: Fri, 8 Jun 2012 11:52:02 +0100
X-Google-Sender-Auth: e5BGs3DUMy-f4ATp661KbOR7qGo
Message-ID: <CAFLBxZbBpSoAQrRsZD_xg7poii2xsCBafC3b1bFe+eubg_2Oxw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4] p2m: Keep statistics on order of p2m
	entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, May 9, 2011 at 9:27 AM, Tim Deegan <Tim.Deegan@citrix.com> wrote:
> At 16:34 +0100 on 06 May (1304699686), George Dunlap wrote:
>> This patch is actually not necessary for the series -- just for the
>> verification that it worked. =A0I could drop this patch so we can
>> discuss it, and send the other three by themselves (since they seem
>> pretty uncontroversial).
>
> I think that's best. =A0I'll be looking at reference-counting p2m entries
> soon, I hope, and I'll add some bookkeeping when I do. =A0I suspect I can
> isolate it into a single place then.\

Tim, I realize this is over a year ago now, but did you ever end up
adding this bookkeeping?  I'm trying to port this patch again...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scx4F-0005lZ-3b; Fri, 08 Jun 2012 11:09: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 1Scx4C-0005lU-KH
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:09:21 +0000
Received: from [85.158.143.35:46857] by server-1.bemta-4.messagelabs.com id
	4A/0C-10042-F5DD1DF4; Fri, 08 Jun 2012 11:09:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339153759!14384596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2354 invoked from network); 8 Jun 2012 11:09:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:09:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:09:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx49-0007Lg-Hz; Fri, 08 Jun 2012 11:09:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx49-0006f0-Ds;
	Fri, 08 Jun 2012 12:09:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56669.262325.348583@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:09:17 +0100
To: xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC] libxl: DO NOT APPLY enforce prohibition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Apropos of an observation by Roger that it is too easy to violate the
restriction on reentering libxl and in particular too easy to
start multiple nested aos on a single thread, which is forbidden:


DO NOT APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

   
In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.


Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>

---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/gentypes.py      |    1 -
 tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 5 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e11354f..5eeb639 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 4f1f4fd..2195043 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -640,7 +652,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -658,7 +671,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -669,14 +683,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6e6e5fd..cd507db 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_libxl_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1534,10 +1540,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
tg: (0f31282..) t/xen/xl.external-callers-only (depends on: t/xen/xl.ao.progress-ignored-free-event)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scx4F-0005lZ-3b; Fri, 08 Jun 2012 11:09: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 1Scx4C-0005lU-KH
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:09:21 +0000
Received: from [85.158.143.35:46857] by server-1.bemta-4.messagelabs.com id
	4A/0C-10042-F5DD1DF4; Fri, 08 Jun 2012 11:09:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339153759!14384596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2354 invoked from network); 8 Jun 2012 11:09:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:09:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:09:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx49-0007Lg-Hz; Fri, 08 Jun 2012 11:09:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx49-0006f0-Ds;
	Fri, 08 Jun 2012 12:09:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56669.262325.348583@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:09:17 +0100
To: xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC] libxl: DO NOT APPLY enforce prohibition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Apropos of an observation by Roger that it is too easy to violate the
restriction on reentering libxl and in particular too easy to
start multiple nested aos on a single thread, which is forbidden:


DO NOT APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

   
In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.


Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>

---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/gentypes.py      |    1 -
 tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 5 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e11354f..5eeb639 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 4f1f4fd..2195043 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -640,7 +652,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -658,7 +671,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -669,14 +683,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6e6e5fd..cd507db 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_libxl_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1534,10 +1540,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
tg: (0f31282..) t/xen/xl.external-callers-only (depends on: t/xen/xl.ao.progress-ignored-free-event)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scx5Z-0005p3-Ik; Fri, 08 Jun 2012 11:10:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scx5Y-0005ot-ET
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:10:44 +0000
Received: from [85.158.143.99:59863] by server-3.bemta-4.messagelabs.com id
	9B/9E-29237-3BDD1DF4; Fri, 08 Jun 2012 11:10:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339153842!29578100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29625 invoked from network); 8 Jun 2012 11:10:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:10:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:10:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:10:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx5W-0007Mx-6h; Fri, 08 Jun 2012 11:10:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx5W-0006fK-50;
	Fri, 08 Jun 2012 12:10:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56754.133034.440704@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:10:42 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <e0c4a09877d727255103.1339146489@Solace>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> As it happens in the implementation of `xl sched-sedf -d ...', some
> consistency checking is needed for the scheduling parameters when
> they come from the config file.

Thanks, I am happy with this from a libxl point of view.  I would like
to see an ack from George from a scheduler point of view.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scx5Z-0005p3-Ik; Fri, 08 Jun 2012 11:10:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scx5Y-0005ot-ET
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:10:44 +0000
Received: from [85.158.143.99:59863] by server-3.bemta-4.messagelabs.com id
	9B/9E-29237-3BDD1DF4; Fri, 08 Jun 2012 11:10:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339153842!29578100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29625 invoked from network); 8 Jun 2012 11:10:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:10:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:10:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:10:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx5W-0007Mx-6h; Fri, 08 Jun 2012 11:10:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx5W-0006fK-50;
	Fri, 08 Jun 2012 12:10:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56754.133034.440704@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:10:42 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <e0c4a09877d727255103.1339146489@Solace>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> As it happens in the implementation of `xl sched-sedf -d ...', some
> consistency checking is needed for the scheduling parameters when
> they come from the config file.

Thanks, I am happy with this from a libxl point of view.  I would like
to see an ack from George from a scheduler point of view.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:11:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scx5g-0005pd-Ut; Fri, 08 Jun 2012 11:10: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 1Scx5f-0005pT-P2
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:10:51 +0000
Received: from [85.158.138.51:10715] by server-10.bemta-3.messagelabs.com id
	C3/B3-06494-ABDD1DF4; Fri, 08 Jun 2012 11:10:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339153850!31528959!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28053 invoked from network); 8 Jun 2012 11:10:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:10:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:10:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:10:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx5d-0007N4-K8; Fri, 08 Jun 2012 11:10:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx5d-0006fO-IP;
	Fri, 08 Jun 2012 12:10:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56761.556911.396389@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:10:49 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <0b8bf8724ee035adf384.1339146488@Solace>
References: <patchbomb.1339146487@Solace>
	<0b8bf8724ee035adf384.1339146488@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] libxl: propagete down the error
 from libxl_domain_sched_params_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

Dario Faggioli writes ("[PATCH 1 of 2 v3] libxl: propagete down the error from libxl_domain_sched_params_set"):
> So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:11:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scx5g-0005pd-Ut; Fri, 08 Jun 2012 11:10: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 1Scx5f-0005pT-P2
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:10:51 +0000
Received: from [85.158.138.51:10715] by server-10.bemta-3.messagelabs.com id
	C3/B3-06494-ABDD1DF4; Fri, 08 Jun 2012 11:10:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339153850!31528959!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28053 invoked from network); 8 Jun 2012 11:10:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:10:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:10:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:10:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx5d-0007N4-K8; Fri, 08 Jun 2012 11:10:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx5d-0006fO-IP;
	Fri, 08 Jun 2012 12:10:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56761.556911.396389@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:10:49 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <0b8bf8724ee035adf384.1339146488@Solace>
References: <patchbomb.1339146487@Solace>
	<0b8bf8724ee035adf384.1339146488@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] libxl: propagete down the error
 from libxl_domain_sched_params_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

Dario Faggioli writes ("[PATCH 1 of 2 v3] libxl: propagete down the error from libxl_domain_sched_params_set"):
> So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:11:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Scx6T-0005vG-CN; Fri, 08 Jun 2012 11:11:41 +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 1Scx6S-0005v0-3m
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:11:40 +0000
Received: from [85.158.143.35:56432] by server-3.bemta-4.messagelabs.com id
	F7/60-29237-BEDD1DF4; Fri, 08 Jun 2012 11:11:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339153896!14385102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13211 invoked from network); 8 Jun 2012 11:11:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:11:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:11:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:11:36 +0100
Date: Fri, 8 Jun 2012 12:11:19 +0100
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: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@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>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Mon, 4 Jun 2012, Jan Beulich wrote:
> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> os-posix.c:os_find_datadir() works. While one would generally expect
> that function to honour the --datadir configure option, fixing this is
> quite a bit more involved than simply adjusting the configure options
> to match the function's behavior (in that, for an installed binary, it
> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> due to (presumably) some other qemu instance being installed on
> people's systems (but being absent when running qemu-system-i386 from
> the dist/ portion of the build tree).
> 
> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> 
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>  		-L$(XEN_ROOT)/tools/xenstore" \
>  		--bindir=$(LIBEXEC) \
> -		--datadir=$(SHAREDIR)/qemu-xen \
> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>  		--disable-kvm \
>  		--python=$(PYTHON) \
>  		$(IOEMU_CONFIGURE_CROSS); \
> 
> 
> 
> 

This is a QEMU bug, so I would rather fix it there.
In fact the fix could be as simple as the appended patch.
Does it work for you?

diff --git a/os-posix.c b/os-posix.c
index dc4a6bb..d0c873d 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
             g_free(res);
             res = NULL;
         }
+    } else {
+        g_free(res);
+        res = NULL;
     }
 
     return res;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:11:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Scx6T-0005vG-CN; Fri, 08 Jun 2012 11:11:41 +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 1Scx6S-0005v0-3m
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:11:40 +0000
Received: from [85.158.143.35:56432] by server-3.bemta-4.messagelabs.com id
	F7/60-29237-BEDD1DF4; Fri, 08 Jun 2012 11:11:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339153896!14385102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13211 invoked from network); 8 Jun 2012 11:11:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:11:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:11:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:11:36 +0100
Date: Fri, 8 Jun 2012 12:11:19 +0100
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: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@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>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Mon, 4 Jun 2012, Jan Beulich wrote:
> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> os-posix.c:os_find_datadir() works. While one would generally expect
> that function to honour the --datadir configure option, fixing this is
> quite a bit more involved than simply adjusting the configure options
> to match the function's behavior (in that, for an installed binary, it
> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> due to (presumably) some other qemu instance being installed on
> people's systems (but being absent when running qemu-system-i386 from
> the dist/ portion of the build tree).
> 
> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> 
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>  		-L$(XEN_ROOT)/tools/xenstore" \
>  		--bindir=$(LIBEXEC) \
> -		--datadir=$(SHAREDIR)/qemu-xen \
> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>  		--disable-kvm \
>  		--python=$(PYTHON) \
>  		$(IOEMU_CONFIGURE_CROSS); \
> 
> 
> 
> 

This is a QEMU bug, so I would rather fix it there.
In fact the fix could be as simple as the appended patch.
Does it work for you?

diff --git a/os-posix.c b/os-posix.c
index dc4a6bb..d0c873d 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
             g_free(res);
             res = NULL;
         }
+    } else {
+        g_free(res);
+        res = NULL;
     }
 
     return res;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:12:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:12: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 1Scx6i-0005yL-VO; Fri, 08 Jun 2012 11:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scx6h-0005xl-8L
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:11:55 +0000
Received: from [85.158.143.99:7611] by server-2.bemta-4.messagelabs.com id
	43/70-17938-AFDD1DF4; Fri, 08 Jun 2012 11:11:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339153913!26635794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29643 invoked from network); 8 Jun 2012 11:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:11:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:11:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx6f-0007NY-Bm; Fri, 08 Jun 2012 11:11:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx6f-0006fd-Ak;
	Fri, 08 Jun 2012 12:11:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56825.315554.351483@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:11:53 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@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>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> Thanks! I was working on the wrong tree (QEMU 1.1 rather than QEMU
> 1.0). Unfortunately the fix that went upstream for this compilation
> issue is not suitable for 1.0 either, so we'll have to live with this
> bug a little while longer.

Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
a potential security issue which might allow guests to do something
exciting ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:12:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:12: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 1Scx6i-0005yL-VO; Fri, 08 Jun 2012 11:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Scx6h-0005xl-8L
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:11:55 +0000
Received: from [85.158.143.99:7611] by server-2.bemta-4.messagelabs.com id
	43/70-17938-AFDD1DF4; Fri, 08 Jun 2012 11:11:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339153913!26635794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29643 invoked from network); 8 Jun 2012 11:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12906857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:11:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:11:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Scx6f-0007NY-Bm; Fri, 08 Jun 2012 11:11:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Scx6f-0006fd-Ak;
	Fri, 08 Jun 2012 12:11:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.56825.315554.351483@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:11:53 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@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>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> Thanks! I was working on the wrong tree (QEMU 1.1 rather than QEMU
> 1.0). Unfortunately the fix that went upstream for this compilation
> issue is not suitable for 1.0 either, so we'll have to live with this
> bug a little while longer.

Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
a potential security issue which might allow guests to do something
exciting ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:13:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scx84-0006DF-Ei; Fri, 08 Jun 2012 11:13:20 +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 1Scx83-0006Cw-Cu
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:13:19 +0000
Received: from [85.158.139.83:47909] by server-9.bemta-5.messagelabs.com id
	BB/A1-29678-E4ED1DF4; Fri, 08 Jun 2012 11:13:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339153996!32654497!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15623 invoked from network); 8 Jun 2012 11:13:18 -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;
	8 Jun 2012 11:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198010379"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:13:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:13:16 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scx7z-0002nK-NQ;
	Fri, 08 Jun 2012 12:13:15 +0100
Message-ID: <4FD1DDDC.6020405@eu.citrix.com>
Date: Fri, 8 Jun 2012 12:11:24 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
In-Reply-To: <20433.56754.133034.440704@mariner.uk.xensource.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/06/12 12:10, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
>> As it happens in the implementation of `xl sched-sedf -d ...', some
>> consistency checking is needed for the scheduling parameters when
>> they come from the config file.
> Thanks, I am happy with this from a libxl point of view.  I would like
> to see an ack from George from a scheduler point of view.
I think Dario knows more about what sedf wants than I do; and since it 
only does anything when the domain is using sedf, I think it's fine.

So FWIW:

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 Fri Jun 08 11:13:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scx84-0006DF-Ei; Fri, 08 Jun 2012 11:13:20 +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 1Scx83-0006Cw-Cu
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:13:19 +0000
Received: from [85.158.139.83:47909] by server-9.bemta-5.messagelabs.com id
	BB/A1-29678-E4ED1DF4; Fri, 08 Jun 2012 11:13:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339153996!32654497!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15623 invoked from network); 8 Jun 2012 11:13:18 -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;
	8 Jun 2012 11:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198010379"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:13:16 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:13:16 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scx7z-0002nK-NQ;
	Fri, 08 Jun 2012 12:13:15 +0100
Message-ID: <4FD1DDDC.6020405@eu.citrix.com>
Date: Fri, 8 Jun 2012 12:11:24 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
In-Reply-To: <20433.56754.133034.440704@mariner.uk.xensource.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/06/12 12:10, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
>> As it happens in the implementation of `xl sched-sedf -d ...', some
>> consistency checking is needed for the scheduling parameters when
>> they come from the config file.
> Thanks, I am happy with this from a libxl point of view.  I would like
> to see an ack from George from a scheduler point of view.
I think Dario knows more about what sedf wants than I do; and since it 
only does anything when the domain is using sedf, I think it's fine.

So FWIW:

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 Fri Jun 08 11:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxEB-0006gl-52; Fri, 08 Jun 2012 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 <lars.kurth.xen@gmail.com>) id 1ScxE8-0006g8-Kn
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:19:36 +0000
Received: from [85.158.138.51:23273] by server-9.bemta-3.messagelabs.com id
	7C/FF-15054-5CFD1DF4; Fri, 08 Jun 2012 11:19:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339154371!12763098!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9459 invoked from network); 8 Jun 2012 11:19:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:19:31 -0000
Received: by eekd41 with SMTP id d41so1259863eek.32
	for <multiple recipients>; Fri, 08 Jun 2012 04:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=6F4xkaMrk32KeVtwma2+sEf2HiGHqL2WagbM1G0jW6U=;
	b=yG7qEG/wbFDbR8rWqCROb804boqgcztoNwHt1xB3jSKEuCURhLO6ZS5pou1TV74CwP
	BZ9IRfTjy19UY+t4+zV9IOxkfpDK3u7MOHOlZDsmhk6bLi6siDT88nGB9uCuTMW5jx2P
	5/RtKL8f6vAfM8p/yrewzQ+QXmKoyet2r8PEPcRj543Ymb+/ZYnpSoMW4o28hbqb6f4t
	QKlmQLdiwKjJzSIOvqa3BfQYWc9wiu75II8dCORpzDzaYZD38QxQFQ27dCCt1tzdwmNb
	UGPkCCYdNIQ2lvw25casJL1mPBWU8uGb9FpPB8ttllblYDuNrmWrJBkedCo88qxTJD5/
	tuMQ==
Received: by 10.14.188.139 with SMTP id a11mr3521317een.139.1339154370822;
	Fri, 08 Jun 2012 04:19:30 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id t3sm21088591eeb.15.2012.06.08.04.19.28
	(version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 04:19:29 -0700 (PDT)
Message-ID: <4FD1DFBF.7070100@xen.org>
Date: Fri, 08 Jun 2012 12:19:27 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-api@lists.xen.org" <xen-api@lists.xen.org>, 
	xen-devel@lists.xen.org, xen-arm@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] New Xen Wiki Front page
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

If there are no objections, I will replace 
http://wiki.xen.org/wiki/Proposals/Main_Page1 with 
http://wiki.xen.org/wiki/Proposals/Main_Page1

Generally feedback on this has been positive, with the exception that we 
need to do something about categories, but this will take maybe a little 
longer to sort out

Please shout if you object

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 Jun 08 11:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxEB-0006gl-52; Fri, 08 Jun 2012 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 <lars.kurth.xen@gmail.com>) id 1ScxE8-0006g8-Kn
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:19:36 +0000
Received: from [85.158.138.51:23273] by server-9.bemta-3.messagelabs.com id
	7C/FF-15054-5CFD1DF4; Fri, 08 Jun 2012 11:19:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339154371!12763098!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9459 invoked from network); 8 Jun 2012 11:19:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:19:31 -0000
Received: by eekd41 with SMTP id d41so1259863eek.32
	for <multiple recipients>; Fri, 08 Jun 2012 04:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=6F4xkaMrk32KeVtwma2+sEf2HiGHqL2WagbM1G0jW6U=;
	b=yG7qEG/wbFDbR8rWqCROb804boqgcztoNwHt1xB3jSKEuCURhLO6ZS5pou1TV74CwP
	BZ9IRfTjy19UY+t4+zV9IOxkfpDK3u7MOHOlZDsmhk6bLi6siDT88nGB9uCuTMW5jx2P
	5/RtKL8f6vAfM8p/yrewzQ+QXmKoyet2r8PEPcRj543Ymb+/ZYnpSoMW4o28hbqb6f4t
	QKlmQLdiwKjJzSIOvqa3BfQYWc9wiu75II8dCORpzDzaYZD38QxQFQ27dCCt1tzdwmNb
	UGPkCCYdNIQ2lvw25casJL1mPBWU8uGb9FpPB8ttllblYDuNrmWrJBkedCo88qxTJD5/
	tuMQ==
Received: by 10.14.188.139 with SMTP id a11mr3521317een.139.1339154370822;
	Fri, 08 Jun 2012 04:19:30 -0700 (PDT)
Received: from [172.16.25.10] (b0fb96e9.bb.sky.com. [176.251.150.233])
	by mx.google.com with ESMTPS id t3sm21088591eeb.15.2012.06.08.04.19.28
	(version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 04:19:29 -0700 (PDT)
Message-ID: <4FD1DFBF.7070100@xen.org>
Date: Fri, 08 Jun 2012 12:19:27 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-api@lists.xen.org" <xen-api@lists.xen.org>, 
	xen-devel@lists.xen.org, xen-arm@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] New Xen Wiki Front page
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

If there are no objections, I will replace 
http://wiki.xen.org/wiki/Proposals/Main_Page1 with 
http://wiki.xen.org/wiki/Proposals/Main_Page1

Generally feedback on this has been positive, with the exception that we 
need to do something about categories, but this will take maybe a little 
longer to sort out

Please shout if you object

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 Jun 08 11:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxFV-0006sR-M4; Fri, 08 Jun 2012 11:21: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 1ScxFT-0006s8-TO
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:21:00 +0000
Received: from [85.158.143.99:12497] by server-3.bemta-4.messagelabs.com id
	71/E1-29237-A10E1DF4; Fri, 08 Jun 2012 11:20:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339154458!25360240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31657 invoked from network); 8 Jun 2012 11:20:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:20:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12907022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:20:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:20:58 +0100
Date: Fri, 8 Jun 2012 12:20:51 +0100
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: <20433.56825.315554.351483@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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, 8 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > Thanks! I was working on the wrong tree (QEMU 1.1 rather than QEMU
> > 1.0). Unfortunately the fix that went upstream for this compilation
> > issue is not suitable for 1.0 either, so we'll have to live with this
> > bug a little while longer.
> 
> Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
> a potential security issue which might allow guests to do something
> exciting ?

virtfs allows guest and host to share a folder. You can restrict
access to the folder in various ways:

http://wiki.qemu.org/Documentation/9psetup

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxFV-0006sR-M4; Fri, 08 Jun 2012 11:21: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 1ScxFT-0006s8-TO
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:21:00 +0000
Received: from [85.158.143.99:12497] by server-3.bemta-4.messagelabs.com id
	71/E1-29237-A10E1DF4; Fri, 08 Jun 2012 11:20:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339154458!25360240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31657 invoked from network); 8 Jun 2012 11:20:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:20:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12907022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:20:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:20:58 +0100
Date: Fri, 8 Jun 2012 12:20:51 +0100
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: <20433.56825.315554.351483@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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, 8 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > Thanks! I was working on the wrong tree (QEMU 1.1 rather than QEMU
> > 1.0). Unfortunately the fix that went upstream for this compilation
> > issue is not suitable for 1.0 either, so we'll have to live with this
> > bug a little while longer.
> 
> Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
> a potential security issue which might allow guests to do something
> exciting ?

virtfs allows guest and host to share a folder. You can restrict
access to the folder in various ways:

http://wiki.qemu.org/Documentation/9psetup

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:27:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxLw-0007Ho-K9; Fri, 08 Jun 2012 11:27: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 1ScxLv-0007Hh-36
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:27:39 +0000
Received: from [193.109.254.147:18721] by server-7.bemta-14.messagelabs.com id
	56/0E-29165-AA1E1DF4; Fri, 08 Jun 2012 11:27:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339154857!3098522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8671 invoked from network); 8 Jun 2012 11:27:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:27:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12907173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:27:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:27:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScxLf-0007U4-Ad; Fri, 08 Jun 2012 11:27:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScxLf-0007Nr-9P;
	Fri, 08 Jun 2012 12:27:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.57755.274531.968750@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:27:23 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@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>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> On Fri, 8 Jun 2012, Ian Jackson wrote:
> > Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
> > a potential security issue which might allow guests to do something
> > exciting ?
> 
> virtfs allows guest and host to share a folder. You can restrict
> access to the folder in various ways:

So what is the default configuration ?  Do we have any protection from
possible bugs in the virtfs access control system ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:27:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxLw-0007Ho-K9; Fri, 08 Jun 2012 11:27: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 1ScxLv-0007Hh-36
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:27:39 +0000
Received: from [193.109.254.147:18721] by server-7.bemta-14.messagelabs.com id
	56/0E-29165-AA1E1DF4; Fri, 08 Jun 2012 11:27:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339154857!3098522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8671 invoked from network); 8 Jun 2012 11:27:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:27:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12907173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:27:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:27:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ScxLf-0007U4-Ad; Fri, 08 Jun 2012 11:27:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ScxLf-0007Nr-9P;
	Fri, 08 Jun 2012 12:27:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20433.57755.274531.968750@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 12:27:23 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@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>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> On Fri, 8 Jun 2012, Ian Jackson wrote:
> > Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
> > a potential security issue which might allow guests to do something
> > exciting ?
> 
> virtfs allows guest and host to share a folder. You can restrict
> access to the folder in various ways:

So what is the default configuration ?  Do we have any protection from
possible bugs in the virtfs access control system ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:29:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:29: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 1ScxNB-0007NC-30; Fri, 08 Jun 2012 11:28: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 1ScxN9-0007N3-6a
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:28:55 +0000
Received: from [85.158.138.51:35473] by server-8.bemta-3.messagelabs.com id
	49/B4-22118-6F1E1DF4; Fri, 08 Jun 2012 11:28:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339154933!22557966!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28445 invoked from network); 8 Jun 2012 11:28:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 11:28:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 12:28:53 +0100
Message-Id: <4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 12:29:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Mon, 4 Jun 2012, Jan Beulich wrote:
>> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
>> os-posix.c:os_find_datadir() works. While one would generally expect
>> that function to honour the --datadir configure option, fixing this is
>> quite a bit more involved than simply adjusting the configure options
>> to match the function's behavior (in that, for an installed binary, it
>> looks in $bindir/../share/qemu). Afaict, so far this can have worked
>> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
>> due to (presumably) some other qemu instance being installed on
>> people's systems (but being absent when running qemu-system-i386 from
>> the dist/ portion of the build tree).
>> 
>> Signed-off-by: Jan Beulich <JBeulich@suse.com>
>> 
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>>  		-L$(XEN_ROOT)/tools/xenstore" \
>>  		--bindir=$(LIBEXEC) \
>> -		--datadir=$(SHAREDIR)/qemu-xen \
>> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>>  		--disable-kvm \
>>  		--python=$(PYTHON) \
>>  		$(IOEMU_CONFIGURE_CROSS); \
>> 
>> 
>> 
>> 
> 
> This is a QEMU bug, so I would rather fix it there.

That's not as simple as you appear to think, as it would be necessary
to meaningfully express an arbitrary datadir relative to bindir.

> In fact the fix could be as simple as the appended patch.
> Does it work for you?
> 
> diff --git a/os-posix.c b/os-posix.c
> index dc4a6bb..d0c873d 100644
> --- a/os-posix.c
> +++ b/os-posix.c
> @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
>              g_free(res);
>              res = NULL;
>          }
> +    } else {
> +        g_free(res);
> +        res = NULL;

How can this work? Afaict it would even break currently working
cases, as it now makes the function return NULL not only when
both access() checks failed, but also when the first one succeeded.

Jan

>      }
>  
>      return res;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:29:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:29: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 1ScxNB-0007NC-30; Fri, 08 Jun 2012 11:28: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 1ScxN9-0007N3-6a
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:28:55 +0000
Received: from [85.158.138.51:35473] by server-8.bemta-3.messagelabs.com id
	49/B4-22118-6F1E1DF4; Fri, 08 Jun 2012 11:28:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339154933!22557966!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28445 invoked from network); 8 Jun 2012 11:28:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 11:28:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 12:28:53 +0100
Message-Id: <4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 12:29:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Mon, 4 Jun 2012, Jan Beulich wrote:
>> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
>> os-posix.c:os_find_datadir() works. While one would generally expect
>> that function to honour the --datadir configure option, fixing this is
>> quite a bit more involved than simply adjusting the configure options
>> to match the function's behavior (in that, for an installed binary, it
>> looks in $bindir/../share/qemu). Afaict, so far this can have worked
>> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
>> due to (presumably) some other qemu instance being installed on
>> people's systems (but being absent when running qemu-system-i386 from
>> the dist/ portion of the build tree).
>> 
>> Signed-off-by: Jan Beulich <JBeulich@suse.com>
>> 
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>>  		-L$(XEN_ROOT)/tools/xenstore" \
>>  		--bindir=$(LIBEXEC) \
>> -		--datadir=$(SHAREDIR)/qemu-xen \
>> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>>  		--disable-kvm \
>>  		--python=$(PYTHON) \
>>  		$(IOEMU_CONFIGURE_CROSS); \
>> 
>> 
>> 
>> 
> 
> This is a QEMU bug, so I would rather fix it there.

That's not as simple as you appear to think, as it would be necessary
to meaningfully express an arbitrary datadir relative to bindir.

> In fact the fix could be as simple as the appended patch.
> Does it work for you?
> 
> diff --git a/os-posix.c b/os-posix.c
> index dc4a6bb..d0c873d 100644
> --- a/os-posix.c
> +++ b/os-posix.c
> @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
>              g_free(res);
>              res = NULL;
>          }
> +    } else {
> +        g_free(res);
> +        res = NULL;

How can this work? Afaict it would even break currently working
cases, as it now makes the function return NULL not only when
both access() checks failed, but also when the first one succeeded.

Jan

>      }
>  
>      return res;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:43:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Scxb7-0007oN-GI; Fri, 08 Jun 2012 11:43:21 +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 1Scxb5-0007oI-Co
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:43:19 +0000
Received: from [85.158.143.99:43646] by server-3.bemta-4.messagelabs.com id
	15/C7-29237-655E1DF4; Fri, 08 Jun 2012 11:43:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339155797!31018408!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14951 invoked from network); 8 Jun 2012 11:43:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:43:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12907520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:43:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:43:17 +0100
Date: Fri, 8 Jun 2012 12:42:59 +0100
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: <4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Fri, 8 Jun 2012, Jan Beulich wrote:
> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Mon, 4 Jun 2012, Jan Beulich wrote:
> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> >> os-posix.c:os_find_datadir() works. While one would generally expect
> >> that function to honour the --datadir configure option, fixing this is
> >> quite a bit more involved than simply adjusting the configure options
> >> to match the function's behavior (in that, for an installed binary, it
> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> >> due to (presumably) some other qemu instance being installed on
> >> people's systems (but being absent when running qemu-system-i386 from
> >> the dist/ portion of the build tree).
> >> 
> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> >> 
> >> --- a/tools/Makefile
> >> +++ b/tools/Makefile
> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
> >>  		-L$(XEN_ROOT)/tools/xenstore" \
> >>  		--bindir=$(LIBEXEC) \
> >> -		--datadir=$(SHAREDIR)/qemu-xen \
> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
> >>  		--disable-kvm \
> >>  		--python=$(PYTHON) \
> >>  		$(IOEMU_CONFIGURE_CROSS); \
> >> 
> >> 
> >> 
> >> 
> > 
> > This is a QEMU bug, so I would rather fix it there.
> 
> That's not as simple as you appear to think, as it would be necessary
> to meaningfully express an arbitrary datadir relative to bindir.
> 
> > In fact the fix could be as simple as the appended patch.
> > Does it work for you?
> > 
> > diff --git a/os-posix.c b/os-posix.c
> > index dc4a6bb..d0c873d 100644
> > --- a/os-posix.c
> > +++ b/os-posix.c
> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
> >              g_free(res);
> >              res = NULL;
> >          }
> > +    } else {
> > +        g_free(res);
> > +        res = NULL;
> 
> How can this work? Afaict it would even break currently working
> cases, as it now makes the function return NULL not only when
> both access() checks failed, but also when the first one succeeded.

Yes, you are right, I misread the error condition of "access".

Like you wrote, os_find_datadir checks for the existence of
$bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
it checks for /usr/lib/xen/pc-bios and if they both don't exist return
NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).

While it is certainly not how I would have written this code, it should
work correctly. How is that you system has /usr/lib/xen/pc-bios or
/usr/lib/xen/share/qemu?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:43:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Scxb7-0007oN-GI; Fri, 08 Jun 2012 11:43:21 +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 1Scxb5-0007oI-Co
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:43:19 +0000
Received: from [85.158.143.99:43646] by server-3.bemta-4.messagelabs.com id
	15/C7-29237-655E1DF4; Fri, 08 Jun 2012 11:43:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339155797!31018408!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14951 invoked from network); 8 Jun 2012 11:43:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:43:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="12907520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 11:43:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 12:43:17 +0100
Date: Fri, 8 Jun 2012 12:42:59 +0100
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: <4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Fri, 8 Jun 2012, Jan Beulich wrote:
> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Mon, 4 Jun 2012, Jan Beulich wrote:
> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> >> os-posix.c:os_find_datadir() works. While one would generally expect
> >> that function to honour the --datadir configure option, fixing this is
> >> quite a bit more involved than simply adjusting the configure options
> >> to match the function's behavior (in that, for an installed binary, it
> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> >> due to (presumably) some other qemu instance being installed on
> >> people's systems (but being absent when running qemu-system-i386 from
> >> the dist/ portion of the build tree).
> >> 
> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> >> 
> >> --- a/tools/Makefile
> >> +++ b/tools/Makefile
> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
> >>  		-L$(XEN_ROOT)/tools/xenstore" \
> >>  		--bindir=$(LIBEXEC) \
> >> -		--datadir=$(SHAREDIR)/qemu-xen \
> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
> >>  		--disable-kvm \
> >>  		--python=$(PYTHON) \
> >>  		$(IOEMU_CONFIGURE_CROSS); \
> >> 
> >> 
> >> 
> >> 
> > 
> > This is a QEMU bug, so I would rather fix it there.
> 
> That's not as simple as you appear to think, as it would be necessary
> to meaningfully express an arbitrary datadir relative to bindir.
> 
> > In fact the fix could be as simple as the appended patch.
> > Does it work for you?
> > 
> > diff --git a/os-posix.c b/os-posix.c
> > index dc4a6bb..d0c873d 100644
> > --- a/os-posix.c
> > +++ b/os-posix.c
> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
> >              g_free(res);
> >              res = NULL;
> >          }
> > +    } else {
> > +        g_free(res);
> > +        res = NULL;
> 
> How can this work? Afaict it would even break currently working
> cases, as it now makes the function return NULL not only when
> both access() checks failed, but also when the first one succeeded.

Yes, you are right, I misread the error condition of "access".

Like you wrote, os_find_datadir checks for the existence of
$bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
it checks for /usr/lib/xen/pc-bios and if they both don't exist return
NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).

While it is certainly not how I would have written this code, it should
work correctly. How is that you system has /usr/lib/xen/pc-bios or
/usr/lib/xen/share/qemu?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:45:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:45: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 1ScxdJ-0007u8-17; Fri, 08 Jun 2012 11:45:37 +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 1ScxdH-0007ty-JQ
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:45:35 +0000
Received: from [85.158.138.51:50229] by server-12.bemta-3.messagelabs.com id
	FC/5B-24185-ED5E1DF4; Fri, 08 Jun 2012 11:45:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339155932!25106369!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8489 invoked from network); 8 Jun 2012 11:45:34 -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;
	8 Jun 2012 11:45:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198013419"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:45:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:45:32 -0400
Received: from exile.uk.xensource.com ([10.80.224.144] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScxdD-0003d2-Pb;
	Fri, 08 Jun 2012 12:45:31 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1339155931@exile>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 8 Jun 2012 11:45:31 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 RFC] Rework populate-on-demand sweeping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rework populate-on-demand sweeping

Last summer I did some work on testing whether our PoD sweeping code
was achieving its goals: namely, never crashing unnecessairly,
minimizing boot time, and maximizing the number of superpages in the
p2m table.

This is one of the resulting patch series.  

I'm posting it to make sure that maintainers think it's still suitable
for inclusion in 4.2.  The patces against 4.1 have been extensively in
the XenServer testing framework and have been in use by XenServer
customers for over 9 months now.  But the p2m code has changed
extensively in that time, so one could argue that the testing doesn't
give us the same degree of confidence in the patches against 4.2 as
against 4.1.  (On the other hand, the PoD code hasn't changed that
much.)

I haven't done more than compile-test it at this point, so please just
review ideas and "is this 4.2 material".  If I get positive feedback,
I'll do more testing and re-submit.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:45:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:45: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 1ScxdJ-0007u8-17; Fri, 08 Jun 2012 11:45:37 +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 1ScxdH-0007ty-JQ
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:45:35 +0000
Received: from [85.158.138.51:50229] by server-12.bemta-3.messagelabs.com id
	FC/5B-24185-ED5E1DF4; Fri, 08 Jun 2012 11:45:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339155932!25106369!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8489 invoked from network); 8 Jun 2012 11:45:34 -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;
	8 Jun 2012 11:45:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198013419"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:45:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:45:32 -0400
Received: from exile.uk.xensource.com ([10.80.224.144] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScxdD-0003d2-Pb;
	Fri, 08 Jun 2012 12:45:31 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1339155931@exile>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 8 Jun 2012 11:45:31 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 RFC] Rework populate-on-demand sweeping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rework populate-on-demand sweeping

Last summer I did some work on testing whether our PoD sweeping code
was achieving its goals: namely, never crashing unnecessairly,
minimizing boot time, and maximizing the number of superpages in the
p2m table.

This is one of the resulting patch series.  

I'm posting it to make sure that maintainers think it's still suitable
for inclusion in 4.2.  The patces against 4.1 have been extensively in
the XenServer testing framework and have been in use by XenServer
customers for over 9 months now.  But the p2m code has changed
extensively in that time, so one could argue that the testing doesn't
give us the same degree of confidence in the patches against 4.2 as
against 4.1.  (On the other hand, the PoD code hasn't changed that
much.)

I haven't done more than compile-test it at this point, so please just
review ideas and "is this 4.2 material".  If I get positive feedback,
I'll do more testing and re-submit.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:45:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxdL-0007ui-9H; Fri, 08 Jun 2012 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 <George.Dunlap@eu.citrix.com>) id 1ScxdJ-0007u3-2r
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:45:37 +0000
Received: from [85.158.138.51:50335] by server-9.bemta-3.messagelabs.com id
	99/3D-15054-0E5E1DF4; Fri, 08 Jun 2012 11:45:36 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339155932!25106369!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8581 invoked from network); 8 Jun 2012 11:45:35 -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;
	8 Jun 2012 11:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198013421"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:45:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:45:32 -0400
Received: from exile.uk.xensource.com ([10.80.224.144] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScxdD-0003d2-Qg;
	Fri, 08 Jun 2012 12:45:31 +0100
MIME-Version: 1.0
X-Mercurial-Node: 6e760eb25dac400f4873d392dd7a2e537644a364
Message-ID: <6e760eb25dac400f4873.1339155933@exile>
In-Reply-To: <patchbomb.1339155931@exile>
References: <patchbomb.1339155931@exile>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 8 Jun 2012 11:45:33 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 RFC] xen, pod: Only sweep in an emergency,
 and only for 4k 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

Testing has shown that doing sweeps for superpages slows down boot
significantly, but does not result in a significantly higher number of
superpages after boot.  Early sweeping for 4k pages causes superpages
to be broken up unnecessarily.

Only sweep if we're really out of memory.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -880,34 +880,6 @@ p2m_pod_zero_check(struct p2m_domain *p2
 }
 
 #define POD_SWEEP_LIMIT 1024
-static void
-p2m_pod_emergency_sweep_super(struct p2m_domain *p2m)
-{
-    unsigned long i, start, limit;
-
-    if ( p2m->pod.reclaim_super == 0 )
-    {
-        p2m->pod.reclaim_super = (p2m->pod.max_guest>>PAGE_ORDER_2M)<<PAGE_ORDER_2M;
-        p2m->pod.reclaim_super -= SUPERPAGE_PAGES;
-    }
-    
-    start = p2m->pod.reclaim_super;
-    limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
-
-    for ( i=p2m->pod.reclaim_super ; i > 0 ; i -= SUPERPAGE_PAGES )
-    {
-        p2m_pod_zero_check_superpage(p2m, i);
-        /* Stop if we're past our limit and we have found *something*.
-         *
-         * NB that this is a zero-sum game; we're increasing our cache size
-         * by increasing our 'debt'.  Since we hold the p2m lock,
-         * (entry_count - count) must remain the same. */
-        if ( !page_list_empty(&p2m->pod.super) &&  i < limit )
-            break;
-    }
-
-    p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
-}
 
 /* When populating a new superpage, look at recently populated superpages
  * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
@@ -1021,34 +993,18 @@ p2m_pod_demand_populate(struct p2m_domai
         return 0;
     }
 
-    /* Once we've ballooned down enough that we can fill the remaining
-     * PoD entries from the cache, don't sweep even if the particular
-     * list we want to use is empty: that can lead to thrashing zero pages 
-     * through the cache for no good reason.  */
-    if ( p2m->pod.entry_count > p2m->pod.count )
-    {
+    /* Only sweep if we're actually out of memory.  Doing anything else
+     * causes unnecessary time and fragmentation of superpages in the p2m. */
+    if ( p2m->pod.count == 0 )
+        p2m_pod_emergency_sweep(p2m);
 
-        /* If we're low, start a sweep */
-        if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
-            /* Note that sweeps scan other ranges in the p2m. In an scenario
-             * in which p2m locks are fine-grained, this may result in deadlock.
-             * Using trylock on the gfn's as we sweep would avoid it. */
-            p2m_pod_emergency_sweep_super(p2m);
-
-        if ( page_list_empty(&p2m->pod.single) &&
-             ( ( order == PAGE_ORDER_4K )
-               || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
-            /* Same comment regarding deadlock applies */
-            p2m_pod_emergency_sweep(p2m);
-    }
+    if ( p2m->pod.count == 0 )
+        goto out_of_memory;
 
     /* Keep track of the highest gfn demand-populated by a guest fault */
     if ( gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    if ( p2m->pod.count == 0 )
-        goto out_of_memory;
-
     /* Get a page f/ the cache.  A NULL return value indicates that the
      * 2-meg range should be marked singleton PoD, and retried */
     if ( (p = p2m_pod_cache_get(p2m, order)) == NULL )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:45:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxdL-0007ui-9H; Fri, 08 Jun 2012 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 <George.Dunlap@eu.citrix.com>) id 1ScxdJ-0007u3-2r
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:45:37 +0000
Received: from [85.158.138.51:50335] by server-9.bemta-3.messagelabs.com id
	99/3D-15054-0E5E1DF4; Fri, 08 Jun 2012 11:45:36 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339155932!25106369!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8581 invoked from network); 8 Jun 2012 11:45:35 -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;
	8 Jun 2012 11:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198013421"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:45:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:45:32 -0400
Received: from exile.uk.xensource.com ([10.80.224.144] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScxdD-0003d2-Qg;
	Fri, 08 Jun 2012 12:45:31 +0100
MIME-Version: 1.0
X-Mercurial-Node: 6e760eb25dac400f4873d392dd7a2e537644a364
Message-ID: <6e760eb25dac400f4873.1339155933@exile>
In-Reply-To: <patchbomb.1339155931@exile>
References: <patchbomb.1339155931@exile>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 8 Jun 2012 11:45:33 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 RFC] xen, pod: Only sweep in an emergency,
 and only for 4k 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

Testing has shown that doing sweeps for superpages slows down boot
significantly, but does not result in a significantly higher number of
superpages after boot.  Early sweeping for 4k pages causes superpages
to be broken up unnecessarily.

Only sweep if we're really out of memory.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -880,34 +880,6 @@ p2m_pod_zero_check(struct p2m_domain *p2
 }
 
 #define POD_SWEEP_LIMIT 1024
-static void
-p2m_pod_emergency_sweep_super(struct p2m_domain *p2m)
-{
-    unsigned long i, start, limit;
-
-    if ( p2m->pod.reclaim_super == 0 )
-    {
-        p2m->pod.reclaim_super = (p2m->pod.max_guest>>PAGE_ORDER_2M)<<PAGE_ORDER_2M;
-        p2m->pod.reclaim_super -= SUPERPAGE_PAGES;
-    }
-    
-    start = p2m->pod.reclaim_super;
-    limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
-
-    for ( i=p2m->pod.reclaim_super ; i > 0 ; i -= SUPERPAGE_PAGES )
-    {
-        p2m_pod_zero_check_superpage(p2m, i);
-        /* Stop if we're past our limit and we have found *something*.
-         *
-         * NB that this is a zero-sum game; we're increasing our cache size
-         * by increasing our 'debt'.  Since we hold the p2m lock,
-         * (entry_count - count) must remain the same. */
-        if ( !page_list_empty(&p2m->pod.super) &&  i < limit )
-            break;
-    }
-
-    p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
-}
 
 /* When populating a new superpage, look at recently populated superpages
  * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
@@ -1021,34 +993,18 @@ p2m_pod_demand_populate(struct p2m_domai
         return 0;
     }
 
-    /* Once we've ballooned down enough that we can fill the remaining
-     * PoD entries from the cache, don't sweep even if the particular
-     * list we want to use is empty: that can lead to thrashing zero pages 
-     * through the cache for no good reason.  */
-    if ( p2m->pod.entry_count > p2m->pod.count )
-    {
+    /* Only sweep if we're actually out of memory.  Doing anything else
+     * causes unnecessary time and fragmentation of superpages in the p2m. */
+    if ( p2m->pod.count == 0 )
+        p2m_pod_emergency_sweep(p2m);
 
-        /* If we're low, start a sweep */
-        if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
-            /* Note that sweeps scan other ranges in the p2m. In an scenario
-             * in which p2m locks are fine-grained, this may result in deadlock.
-             * Using trylock on the gfn's as we sweep would avoid it. */
-            p2m_pod_emergency_sweep_super(p2m);
-
-        if ( page_list_empty(&p2m->pod.single) &&
-             ( ( order == PAGE_ORDER_4K )
-               || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
-            /* Same comment regarding deadlock applies */
-            p2m_pod_emergency_sweep(p2m);
-    }
+    if ( p2m->pod.count == 0 )
+        goto out_of_memory;
 
     /* Keep track of the highest gfn demand-populated by a guest fault */
     if ( gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    if ( p2m->pod.count == 0 )
-        goto out_of_memory;
-
     /* Get a page f/ the cache.  A NULL return value indicates that the
      * 2-meg range should be marked singleton PoD, and retried */
     if ( (p = p2m_pod_cache_get(p2m, order)) == NULL )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:45:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxdK-0007uX-QL; Fri, 08 Jun 2012 11:45:38 +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 1ScxdI-0007u3-Hq
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:45:36 +0000
Received: from [85.158.138.51:43223] by server-9.bemta-3.messagelabs.com id
	14/3D-15054-FD5E1DF4; Fri, 08 Jun 2012 11:45:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339155932!25106369!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 8 Jun 2012 11:45:34 -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;
	8 Jun 2012 11:45:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198013420"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:45:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:45:32 -0400
Received: from exile.uk.xensource.com ([10.80.224.144] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScxdD-0003d2-QB;
	Fri, 08 Jun 2012 12:45:31 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4145b32d0c43d7d4665083642d49a4fbf758cfcc
Message-ID: <4145b32d0c43d7d46650.1339155932@exile>
In-Reply-To: <patchbomb.1339155931@exile>
References: <patchbomb.1339155931@exile>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 8 Jun 2012 11:45:32 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 RFC] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 demand-populating pages due to guest accesses, check recently populated
pages to see if we can reclaim them for the cache.  This should keep the PoD
cache filled when the start-of-day scrubber is going through.

The number 128 was chosen by experiment.  Windows does its page
scrubbing in parallel; while a small nubmer like 4 works well for
single VMs, it breaks down as multiple vcpus are scrubbing different
pages in parallel.  Increasing to 128 works well for higher numbers of
vcpus.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -909,6 +909,26 @@ p2m_pod_emergency_sweep_super(struct p2m
     p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
 }
 
+/* When populating a new superpage, look at recently populated superpages
+ * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
+ * the guest OS is done with them. */
+static void
+p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
+{
+    unsigned long check_gfn;
+
+    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
+
+    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
+
+    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
+
+    p2m->pod.last_populated_index = ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
+
+    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m, check_gfn);
+}
+
+
 #define POD_SWEEP_STRIDE  16
 static void
 p2m_pod_emergency_sweep(struct p2m_domain *p2m)
@@ -1066,6 +1086,12 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    /* Check the last guest demand-populate */
+    if ( p2m->pod.entry_count > p2m->pod.count 
+         && order == 9
+         && q & P2M_ALLOC )
+        p2m_pod_check_last_super(p2m, gfn_aligned);
+
     pod_unlock(p2m);
     return 0;
 out_of_memory:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -287,6 +287,9 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+#define POD_HISTORY_MAX 128
+        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */
+        int              last_populated_index;
         mm_lock_t        lock;         /* Locking of private pod structs,   *
                                         * not relying on the p2m lock.      */
     } pod;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:45:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ScxdK-0007uX-QL; Fri, 08 Jun 2012 11:45:38 +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 1ScxdI-0007u3-Hq
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:45:36 +0000
Received: from [85.158.138.51:43223] by server-9.bemta-3.messagelabs.com id
	14/3D-15054-FD5E1DF4; Fri, 08 Jun 2012 11:45:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339155932!25106369!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 8 Jun 2012 11:45:34 -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;
	8 Jun 2012 11:45:34 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198013420"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:45:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:45:32 -0400
Received: from exile.uk.xensource.com ([10.80.224.144] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ScxdD-0003d2-QB;
	Fri, 08 Jun 2012 12:45:31 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4145b32d0c43d7d4665083642d49a4fbf758cfcc
Message-ID: <4145b32d0c43d7d46650.1339155932@exile>
In-Reply-To: <patchbomb.1339155931@exile>
References: <patchbomb.1339155931@exile>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 8 Jun 2012 11:45:32 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 RFC] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 demand-populating pages due to guest accesses, check recently populated
pages to see if we can reclaim them for the cache.  This should keep the PoD
cache filled when the start-of-day scrubber is going through.

The number 128 was chosen by experiment.  Windows does its page
scrubbing in parallel; while a small nubmer like 4 works well for
single VMs, it breaks down as multiple vcpus are scrubbing different
pages in parallel.  Increasing to 128 works well for higher numbers of
vcpus.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -909,6 +909,26 @@ p2m_pod_emergency_sweep_super(struct p2m
     p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
 }
 
+/* When populating a new superpage, look at recently populated superpages
+ * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
+ * the guest OS is done with them. */
+static void
+p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
+{
+    unsigned long check_gfn;
+
+    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
+
+    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
+
+    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
+
+    p2m->pod.last_populated_index = ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
+
+    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m, check_gfn);
+}
+
+
 #define POD_SWEEP_STRIDE  16
 static void
 p2m_pod_emergency_sweep(struct p2m_domain *p2m)
@@ -1066,6 +1086,12 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    /* Check the last guest demand-populate */
+    if ( p2m->pod.entry_count > p2m->pod.count 
+         && order == 9
+         && q & P2M_ALLOC )
+        p2m_pod_check_last_super(p2m, gfn_aligned);
+
     pod_unlock(p2m);
     return 0;
 out_of_memory:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -287,6 +287,9 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+#define POD_HISTORY_MAX 128
+        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */
+        int              last_populated_index;
         mm_lock_t        lock;         /* Locking of private pod structs,   *
                                         * not relying on the p2m lock.      */
     } pod;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:47:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxeW-00088A-Qg; Fri, 08 Jun 2012 11:46: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 1ScxeV-00087e-4M
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:46:51 +0000
Received: from [85.158.143.99:6551] by server-1.bemta-4.messagelabs.com id
	3B/0C-10042-A26E1DF4; Fri, 08 Jun 2012 11:46:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339156009!26642111!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32467 invoked from network); 8 Jun 2012 11:46:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 11:46:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 12:46:49 +0100
Message-Id: <4FD202720200007800088BFB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 12:47:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Moskalenko" <mav@elserv.ru>
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
	<4FD1D1A6.4090900@elserv.ru>
In-Reply-To: <4FD1D1A6.4090900@elserv.ru>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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+IE9uIDA4LjA2LjEyIGF0IDEyOjE5LCBBbGV4IE1vc2thbGVua28gPG1hdkBlbHNlcnYucnU+
IHdyb3RlOgo+IDA4LjA2LjIwMTIgMTE6NDMsIEphbiBCZXVsaWNoINC/0LjRiNC10YI6Cj4+Pj4+
IE9uIDA3LjA2LjEyIGF0IDExOjI5LCBBbGV4IE1vc2thbGVua288bWF2QGVsc2Vydi5ydT4gIHdy
b3RlOgo+Pj4gSSByYW4gaW50byBhIHRyb3VibGUgd2hlbiB0cnlpbmcgdG8gcnVuIFhlbiA0LjEu
eCB3aXRoIHB2X29wcyBrZXJuZWwgb24KPj4+IElCTSBlU2VydmVyIHgzNDAwLiBXaXRob3V0IG5v
YWNwaSBjb21tYW5kIGxpbmUgb3B0aW9uIGRvbTAga2VybmVsCj4+PiBjcmFzaGVzIG9uIEFDUEkg
aW5pdGlhbGl6YXRpb24uIEtlcm1lbHMgMi42LjMyICh3aXRoIGtvbnJhZCB4ZW4KPj4+IHBhdGNo
ZXMpLCAzLjEsIDMuMywgWGVuIDQuMS4yIGJlaGF2ZSB0aGUgc2FtZSB3YXkuIFdpdGhvdXQgaHlw
ZXJ2aXNvcgo+Pj4gYWxsIGtlcm5lbHMgcnVuIHdpdGhvdXQgYW55IHByb2JsZW1zLgo+PiBUaGlz
IGlzIGFuIGlzc3VlIHRoYXQgd2FzIHJlcG9ydGVkIGFuZCBkaXNjdXNzZWQgcHJldmlvdXNseS4K
Pj4gRnVuZGFtZW50YWxseSwgaXQgaXMgYSBmaXJtd2FyZSBwcm9ibGVtIGZyb20gbXkgcG92OiBB
Q1BJIGhhcwo+PiBfbm90aGluZ18gdG8gZG8gd2l0aCB0aGUgTU1JTyBzcGFjZSB1c2VkIGZvciB0
aGUgSU8tQVBJQ3Mgb2YKPj4gdGhlIHN5c3RlbSBvbmNlIHRoZXkgYXJlIHVuZGVyIGNvbnRyb2wg
b2YgdGhlIE9TLiBJdCBzaG91bGRuJ3QKPj4gZXZlbiBiZSByZWFkaW5nIGZyb20gdGhlbSAod2hp
Y2ggaWlyYyB3YXMgdGhlIGNhc2UgaW4gZWFybGllcgo+PiByZXBvcnRzKSwgYnV0IGluIHlvdXIg
Y2FzZSBpdCBsb29rcyBsaWtlIGl0J3MgZXZlbiB3cml0aW5nIHRoZW0uIEkKPj4gaGFkIGJlZW4g
Y29uc2lkZXJpbmcgdG8gYWxsb3cgRG9tMCByZWFkIGFjY2VzcyB0byB0aG9zZSBwYWdlcywKPj4g
YnV0IG9idmlvdXNseSB0aGlzIHdvdWxkbid0IGhlbHAgaW4geW91ciBjYXNlLgo+Pgo+PiBDb3Vs
ZCB5b3UgZXh0cmFjdCBhbmQgc3VwcGx5IHRoZSBBQ1BJIHRhYmxlcyBvZiB0aGF0IHN5c3RlbSwg
c28KPj4gd2UgY2FuIG1ha2UgYW4gYXR0ZW1wdCBhdCBjaGVja2luZyB3aGV0aGVyIHRoZXJlIGlz
IHNvbWUgcmVhc29uCj4+IGZvciB0aGUgZmlybXdhcmUgd3JpdGluZyB0byB0aGUgSU8tQVBJQyB0
aGF0IHdlIGRpZG4ndCB0aGluayBvZiBzbwo+PiBmYXI/Cj4gUGxlYXNlIHNlZSBhdHRhY2hlZCBh
cmNoaXZlLiBUYWJsZXMgYXJlIGdyYWJiZWQgd2l0aCBhY3BpZHVtcCAtYiB1bmRlciAKPiBYZW4g
NC4xLjIgYW5kIHBhdGNoZWQga2VybmVsIDIuNi4zMi4KCl9TQi5QQ0kwLl9DUlMgaGFzCgogICAg
ICAgICAgICAgICAgU3RvcmUgKDB4MkUsIElEWCkKICAgICAgICAgICAgICAgIEFuZCAoMHhGRkZF
RkZGRiwgV05ELCBXTkQpCgp3aXRoCgogICAgT3BlcmF0aW9uUmVnaW9uIChaMDBELCBTeXN0ZW1N
ZW1vcnksIDB4RkVDODAwMDAsIDB4MDEwMCkKICAgIEZpZWxkIChaMDBELCBEV29yZEFjYywgTG9j
aywgUHJlc2VydmUpCiAgICB7CiAgICAgICAgSURYLCAgICAzMiwgCiAgICAgICAgICAgICAgICBP
ZmZzZXQgKDB4MTApLCAKICAgICAgICBXTkQsICAgIDMyCiAgICB9CgpzbyB3aGF0IHRoZSBCSU9T
IHRyaWVzIHRvIGRvIGlzIHVubWFzayBwaW4gMTUgb2YgdGhlIHNlY29uZApJTy1BUElDLiBUbyBt
ZSB0aGlzIG1ha2VzIG5vIHNlbnNlIGF0IGFsbCAoYW5kIGlzIGRlZmluaXRlbHkKaW1wb3NzaWJs
ZSB0byBiZSBzeW5jLWVkIHByb3Blcmx5IHdpdGggYW55IE9TZXMgYWNjZXNzZXMgdG8KdGhlIElP
LUFQSUMgcmVnaXN0ZXJzKSwgYnV0IGNvdWxkIHlvdSBuZXZlcnRoZWxlc3MgYm9vdCBhCm5hdGl2
ZSBrZXJuZWwgd2l0aCAiYXBpYz1kZWJ1ZyIgYW5kIHBvc3QgdGhlIGZ1bGwgc2V0IG9mIGJvb3QK
bWVzc2FnZXMgKHRoZSBkdW1wcyBvZiB0aGUgSU8tQVBJQ3MgYmVpbmcgd2hhdCBJJ20gcmVhbGx5
CmFmdGVyKS4gQWx0ZXJuYXRpdmVseSwgImFwaWNfdmVyYm9zaXR5PWRlYnVnIiBwYXNzZWQgdG8g
WGVuCm9yIHNlbmRpbmcgdGhlICd6JyBkZWJ1ZyBrZXkgd291bGQgcHJvZHVjZSBzaW1pbGFyIGlu
Zm9ybWF0aW9uLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:47:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxeW-00088A-Qg; Fri, 08 Jun 2012 11:46: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 1ScxeV-00087e-4M
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 11:46:51 +0000
Received: from [85.158.143.99:6551] by server-1.bemta-4.messagelabs.com id
	3B/0C-10042-A26E1DF4; Fri, 08 Jun 2012 11:46:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339156009!26642111!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32467 invoked from network); 8 Jun 2012 11:46:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 11:46:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 12:46:49 +0100
Message-Id: <4FD202720200007800088BFB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 12:47:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Moskalenko" <mav@elserv.ru>
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
	<4FD1D1A6.4090900@elserv.ru>
In-Reply-To: <4FD1D1A6.4090900@elserv.ru>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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+IE9uIDA4LjA2LjEyIGF0IDEyOjE5LCBBbGV4IE1vc2thbGVua28gPG1hdkBlbHNlcnYucnU+
IHdyb3RlOgo+IDA4LjA2LjIwMTIgMTE6NDMsIEphbiBCZXVsaWNoINC/0LjRiNC10YI6Cj4+Pj4+
IE9uIDA3LjA2LjEyIGF0IDExOjI5LCBBbGV4IE1vc2thbGVua288bWF2QGVsc2Vydi5ydT4gIHdy
b3RlOgo+Pj4gSSByYW4gaW50byBhIHRyb3VibGUgd2hlbiB0cnlpbmcgdG8gcnVuIFhlbiA0LjEu
eCB3aXRoIHB2X29wcyBrZXJuZWwgb24KPj4+IElCTSBlU2VydmVyIHgzNDAwLiBXaXRob3V0IG5v
YWNwaSBjb21tYW5kIGxpbmUgb3B0aW9uIGRvbTAga2VybmVsCj4+PiBjcmFzaGVzIG9uIEFDUEkg
aW5pdGlhbGl6YXRpb24uIEtlcm1lbHMgMi42LjMyICh3aXRoIGtvbnJhZCB4ZW4KPj4+IHBhdGNo
ZXMpLCAzLjEsIDMuMywgWGVuIDQuMS4yIGJlaGF2ZSB0aGUgc2FtZSB3YXkuIFdpdGhvdXQgaHlw
ZXJ2aXNvcgo+Pj4gYWxsIGtlcm5lbHMgcnVuIHdpdGhvdXQgYW55IHByb2JsZW1zLgo+PiBUaGlz
IGlzIGFuIGlzc3VlIHRoYXQgd2FzIHJlcG9ydGVkIGFuZCBkaXNjdXNzZWQgcHJldmlvdXNseS4K
Pj4gRnVuZGFtZW50YWxseSwgaXQgaXMgYSBmaXJtd2FyZSBwcm9ibGVtIGZyb20gbXkgcG92OiBB
Q1BJIGhhcwo+PiBfbm90aGluZ18gdG8gZG8gd2l0aCB0aGUgTU1JTyBzcGFjZSB1c2VkIGZvciB0
aGUgSU8tQVBJQ3Mgb2YKPj4gdGhlIHN5c3RlbSBvbmNlIHRoZXkgYXJlIHVuZGVyIGNvbnRyb2wg
b2YgdGhlIE9TLiBJdCBzaG91bGRuJ3QKPj4gZXZlbiBiZSByZWFkaW5nIGZyb20gdGhlbSAod2hp
Y2ggaWlyYyB3YXMgdGhlIGNhc2UgaW4gZWFybGllcgo+PiByZXBvcnRzKSwgYnV0IGluIHlvdXIg
Y2FzZSBpdCBsb29rcyBsaWtlIGl0J3MgZXZlbiB3cml0aW5nIHRoZW0uIEkKPj4gaGFkIGJlZW4g
Y29uc2lkZXJpbmcgdG8gYWxsb3cgRG9tMCByZWFkIGFjY2VzcyB0byB0aG9zZSBwYWdlcywKPj4g
YnV0IG9idmlvdXNseSB0aGlzIHdvdWxkbid0IGhlbHAgaW4geW91ciBjYXNlLgo+Pgo+PiBDb3Vs
ZCB5b3UgZXh0cmFjdCBhbmQgc3VwcGx5IHRoZSBBQ1BJIHRhYmxlcyBvZiB0aGF0IHN5c3RlbSwg
c28KPj4gd2UgY2FuIG1ha2UgYW4gYXR0ZW1wdCBhdCBjaGVja2luZyB3aGV0aGVyIHRoZXJlIGlz
IHNvbWUgcmVhc29uCj4+IGZvciB0aGUgZmlybXdhcmUgd3JpdGluZyB0byB0aGUgSU8tQVBJQyB0
aGF0IHdlIGRpZG4ndCB0aGluayBvZiBzbwo+PiBmYXI/Cj4gUGxlYXNlIHNlZSBhdHRhY2hlZCBh
cmNoaXZlLiBUYWJsZXMgYXJlIGdyYWJiZWQgd2l0aCBhY3BpZHVtcCAtYiB1bmRlciAKPiBYZW4g
NC4xLjIgYW5kIHBhdGNoZWQga2VybmVsIDIuNi4zMi4KCl9TQi5QQ0kwLl9DUlMgaGFzCgogICAg
ICAgICAgICAgICAgU3RvcmUgKDB4MkUsIElEWCkKICAgICAgICAgICAgICAgIEFuZCAoMHhGRkZF
RkZGRiwgV05ELCBXTkQpCgp3aXRoCgogICAgT3BlcmF0aW9uUmVnaW9uIChaMDBELCBTeXN0ZW1N
ZW1vcnksIDB4RkVDODAwMDAsIDB4MDEwMCkKICAgIEZpZWxkIChaMDBELCBEV29yZEFjYywgTG9j
aywgUHJlc2VydmUpCiAgICB7CiAgICAgICAgSURYLCAgICAzMiwgCiAgICAgICAgICAgICAgICBP
ZmZzZXQgKDB4MTApLCAKICAgICAgICBXTkQsICAgIDMyCiAgICB9CgpzbyB3aGF0IHRoZSBCSU9T
IHRyaWVzIHRvIGRvIGlzIHVubWFzayBwaW4gMTUgb2YgdGhlIHNlY29uZApJTy1BUElDLiBUbyBt
ZSB0aGlzIG1ha2VzIG5vIHNlbnNlIGF0IGFsbCAoYW5kIGlzIGRlZmluaXRlbHkKaW1wb3NzaWJs
ZSB0byBiZSBzeW5jLWVkIHByb3Blcmx5IHdpdGggYW55IE9TZXMgYWNjZXNzZXMgdG8KdGhlIElP
LUFQSUMgcmVnaXN0ZXJzKSwgYnV0IGNvdWxkIHlvdSBuZXZlcnRoZWxlc3MgYm9vdCBhCm5hdGl2
ZSBrZXJuZWwgd2l0aCAiYXBpYz1kZWJ1ZyIgYW5kIHBvc3QgdGhlIGZ1bGwgc2V0IG9mIGJvb3QK
bWVzc2FnZXMgKHRoZSBkdW1wcyBvZiB0aGUgSU8tQVBJQ3MgYmVpbmcgd2hhdCBJJ20gcmVhbGx5
CmFmdGVyKS4gQWx0ZXJuYXRpdmVseSwgImFwaWNfdmVyYm9zaXR5PWRlYnVnIiBwYXNzZWQgdG8g
WGVuCm9yIHNlbmRpbmcgdGhlICd6JyBkZWJ1ZyBrZXkgd291bGQgcHJvZHVjZSBzaW1pbGFyIGlu
Zm9ybWF0aW9uLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo8-00006L-Kc; Fri, 08 Jun 2012 11:56:48 +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 1Scxo6-00005j-TY
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:47 +0000
Received: from [85.158.143.99:11363] by server-1.bemta-4.messagelabs.com id
	1D/2C-10042-E78E1DF4; Fri, 08 Jun 2012 11:56:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339156603!29586880!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5384 invoked from network); 8 Jun 2012 11:56:45 -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;
	8 Jun 2012 11:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="27343357"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-RK;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7cb3f51992976cf00cab37d3251c161be3d4427d
Message-ID: <7cb3f51992976cf00cab.1339156493@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 RFC] imported patch
	CA-72761-libxc-error.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

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -87,8 +87,8 @@ static ssize_t rdexact(xc_interface *xch
         if ( (len == -1) && ((errno == EINTR) || (errno == EAGAIN)) )
             continue;
         if ( len == 0 ) {
-            ERROR("0-length read");
-            errno = 0;
+            errno = EPIPE;
+            return -1;
         }
         if ( len <= 0 ) {
             ERROR("read_exact_timed failed (read rc: %d, errno: %d, size %d, offset %d)",
@@ -1253,7 +1253,7 @@ int xc_domain_restore(xc_interface *xch,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
-	        DPERROR(tdom, "Error when reading batch");
+	        /* pagebuf_get_one already returned a proper error */
                 goto out;
             }
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo8-00006L-Kc; Fri, 08 Jun 2012 11:56:48 +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 1Scxo6-00005j-TY
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:47 +0000
Received: from [85.158.143.99:11363] by server-1.bemta-4.messagelabs.com id
	1D/2C-10042-E78E1DF4; Fri, 08 Jun 2012 11:56:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339156603!29586880!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5384 invoked from network); 8 Jun 2012 11:56:45 -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;
	8 Jun 2012 11:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="27343357"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-RK;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7cb3f51992976cf00cab37d3251c161be3d4427d
Message-ID: <7cb3f51992976cf00cab.1339156493@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4 RFC] imported patch
	CA-72761-libxc-error.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

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -87,8 +87,8 @@ static ssize_t rdexact(xc_interface *xch
         if ( (len == -1) && ((errno == EINTR) || (errno == EAGAIN)) )
             continue;
         if ( len == 0 ) {
-            ERROR("0-length read");
-            errno = 0;
+            errno = EPIPE;
+            return -1;
         }
         if ( len <= 0 ) {
             ERROR("read_exact_timed failed (read rc: %d, errno: %d, size %d, offset %d)",
@@ -1253,7 +1253,7 @@ int xc_domain_restore(xc_interface *xch,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
-	        DPERROR(tdom, "Error when reading batch");
+	        /* pagebuf_get_one already returned a proper error */
                 goto out;
             }
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo7-000065-TO; Fri, 08 Jun 2012 11:56:47 +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 1Scxo6-00005i-GM
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:46 +0000
Received: from [85.158.143.99:15161] by server-3.bemta-4.messagelabs.com id
	C1/8D-29237-D78E1DF4; Fri, 08 Jun 2012 11:56:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339156603!29586880!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5348 invoked from network); 8 Jun 2012 11:56:44 -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;
	8 Jun 2012 11:56:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="27343356"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-Pn;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:50 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 RFC] Populate-on-demand: Check pages
 being returned by the balloon 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

Populate-on-demand: Check pages being returned by the balloon driver

This patch series is the second result of my work last summer on
decreasing fragmentation of superpages in a guests' p2m when using
populate-on-demand.

This patch series is against 4.1; I'm posting it to get feedback on
the viability of getting a ported version of this patch into 4.2.

As with the previous series, the patces against 4.1 have been
extensively in the XenServer testing framework and have been in use by
XenServer customers for over 9 months now.  But the p2m code has
changed extensively in that time, so one could argue that the testing
doesn't give us the same degree of confidence in the patches against
4.2 as against 4.1.

Looking at it now, there are a number of ugly bits -- "#if 0" and
such; please overlook this for now, as it will all be cleaned up as
part of the porting process.

If this looks good, I'll do the work of porting and testing it before
posting it again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo7-000065-TO; Fri, 08 Jun 2012 11:56:47 +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 1Scxo6-00005i-GM
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:46 +0000
Received: from [85.158.143.99:15161] by server-3.bemta-4.messagelabs.com id
	C1/8D-29237-D78E1DF4; Fri, 08 Jun 2012 11:56:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339156603!29586880!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5348 invoked from network); 8 Jun 2012 11:56:44 -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;
	8 Jun 2012 11:56:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="27343356"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-Pn;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:50 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4 RFC] Populate-on-demand: Check pages
 being returned by the balloon 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

Populate-on-demand: Check pages being returned by the balloon driver

This patch series is the second result of my work last summer on
decreasing fragmentation of superpages in a guests' p2m when using
populate-on-demand.

This patch series is against 4.1; I'm posting it to get feedback on
the viability of getting a ported version of this patch into 4.2.

As with the previous series, the patces against 4.1 have been
extensively in the XenServer testing framework and have been in use by
XenServer customers for over 9 months now.  But the p2m code has
changed extensively in that time, so one could argue that the testing
doesn't give us the same degree of confidence in the patches against
4.2 as against 4.1.

Looking at it now, there are a number of ugly bits -- "#if 0" and
such; please overlook this for now, as it will all be cleaned up as
part of the porting process.

If this looks good, I'll do the work of porting and testing it before
posting it again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo9-00006k-Ch; Fri, 08 Jun 2012 11:56:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Scxo7-00005j-CV
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:47 +0000
Received: from [85.158.143.99:11395] by server-1.bemta-4.messagelabs.com id
	BF/2C-10042-E78E1DF4; Fri, 08 Jun 2012 11:56:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339156604!31589312!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18440 invoked from network); 8 Jun 2012 11:56:45 -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;
	8 Jun 2012 11:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198014261"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-QN;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 672e9628f27845d24a3f37f245c33209cccdc586
Message-ID: <672e9628f27845d24a3f.1339156491@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:51 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Return the p2m level of the entry which filled this request.
Intended to be used to see if pages returned by the balloon
driver are part of a superpage, and reclaim them if so.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3644,6 +3644,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
         p2m_type_t t;
         p2m_access_t ac;
         mfn_t mfn;
+        int l;
 
         /* Interface access to internal p2m accesses */
         hvmmem_access_t memaccess[] = {
@@ -3681,7 +3682,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 goto param_fail6;
 
             rc = -ESRCH;
-            mfn = p2m->get_entry(p2m, a.pfn, &t, &ac, p2m_query);
+            mfn = p2m->get_entry(p2m, a.pfn, &t, &ac, &l, p2m_query);
 
             if ( mfn_x(mfn) == INVALID_MFN )
                 goto param_fail6;
diff --git a/xen/arch/x86/mm/hap/p2m-ept.c b/xen/arch/x86/mm/hap/p2m-ept.c
--- a/xen/arch/x86/mm/hap/p2m-ept.c
+++ b/xen/arch/x86/mm/hap/p2m-ept.c
@@ -527,14 +527,14 @@ out:
 /* Read ept p2m entries */
 static mfn_t ept_get_entry(struct p2m_domain *p2m,
                            unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
-                           p2m_query_t q)
+                           int *level, p2m_query_t q)
 {
     struct domain *d = p2m->domain;
     ept_entry_t *table = map_domain_page(ept_get_asr(d));
     unsigned long gfn_remainder = gfn;
     ept_entry_t *ept_entry;
     u32 index;
-    int i;
+    int i=5;
     int ret = 0;
     mfn_t mfn = _mfn(INVALID_MFN);
 
@@ -616,6 +616,7 @@ static mfn_t ept_get_entry(struct p2m_do
     }
 
 out:
+    *level=i+1;
     unmap_domain_page(table);
     return mfn;
 }
@@ -709,9 +710,10 @@ out:
 
 static mfn_t ept_get_entry_current(struct p2m_domain *p2m,
                                    unsigned long gfn, p2m_type_t *t, p2m_access_t *a,
+                                   int *l,
                                    p2m_query_t q)
 {
-    return ept_get_entry(p2m, gfn, t, a, q);
+    return ept_get_entry(p2m, gfn, t, a, l, q);
 }
 
 /*
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1579,7 +1579,7 @@ out:
 
 static mfn_t
 p2m_gfn_to_mfn(struct p2m_domain *p2m, unsigned long gfn, p2m_type_t *t, p2m_access_t *a,
-               p2m_query_t q)
+               int *level, p2m_query_t q)
 {
     mfn_t mfn;
     paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
@@ -1594,7 +1594,8 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u
      * XXX we will return p2m_invalid for unmapped gfns */
     *t = p2m_mmio_dm;
     /* Not implemented except with EPT */
-    *a = p2m_access_rwx; 
+    *a = p2m_access_rwx;
+    *level = 5;
 
     mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
 
@@ -1602,6 +1603,7 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u
         /* This pfn is higher than the highest the p2m map currently holds */
         return _mfn(INVALID_MFN);
 
+    *level = 4;
 #if CONFIG_PAGING_LEVELS >= 4
     {
         l4_pgentry_t *l4e = map_domain_page(mfn_x(mfn));
@@ -1615,6 +1617,7 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u
         unmap_domain_page(l4e);
     }
 #endif
+    *level=3;
     {
         l3_pgentry_t *l3e = map_domain_page(mfn_x(mfn));
 #if CONFIG_PAGING_LEVELS == 3
@@ -1662,6 +1665,7 @@ pod_retry_l3:
 
     l2e = map_domain_page(mfn_x(mfn));
     l2e += l2_table_offset(addr);
+    *level=2;
 
 pod_retry_l2:
     if ( (l2e_get_flags(*l2e) & _PAGE_PRESENT) == 0 )
@@ -1695,6 +1699,7 @@ pod_retry_l2:
 
     l1e = map_domain_page(mfn_x(mfn));
     l1e += l1_table_offset(addr);
+    *level=1;
 pod_retry_l1:
     if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
     {
@@ -1723,7 +1728,7 @@ pod_retry_l1:
 /* Read the current domain's p2m table (through the linear mapping). */
 static mfn_t p2m_gfn_to_mfn_current(struct p2m_domain *p2m,
                                     unsigned long gfn, p2m_type_t *t, p2m_access_t *a,
-                                    p2m_query_t q)
+                                    int *level, p2m_query_t q)
 {
     mfn_t mfn = _mfn(INVALID_MFN);
     p2m_type_t p2mt = p2m_mmio_dm;
@@ -1735,6 +1740,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
 
     /* Not currently implemented except for EPT */
     *a = p2m_access_rwx;
+    *level=5;
 
     if ( gfn <= p2m->max_mapped_pfn )
     {
@@ -1749,6 +1755,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
                / sizeof(l1_pgentry_t));
 
 #if CONFIG_PAGING_LEVELS >= 4
+    *level=3;
         /*
          * Read & process L3
          */
@@ -1802,6 +1809,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
         p2m_entry = &__linear_l1_table[l1_linear_offset(RO_MPT_VIRT_START)
                                        + l2_linear_offset(addr)];
 
+    *level=2;
     pod_retry_l2:
         ret = __copy_from_user(&l2e,
                                p2m_entry,
@@ -1855,6 +1863,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
 
         /* Need to __copy_from_user because the p2m is sparse and this
          * part might not exist */
+    *level=1;
     pod_retry_l1:
         p2m_entry = &phys_to_machine_mapping[gfn];
 
@@ -2069,6 +2078,7 @@ void p2m_teardown(struct p2m_domain *p2m
     unsigned long gfn;
     p2m_type_t t;
     p2m_access_t a;
+    int l;
     mfn_t mfn;
 #endif
 
@@ -2077,7 +2087,7 @@ void p2m_teardown(struct p2m_domain *p2m
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
-        mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query);
+        mfn = p2m->get_entry(p2m, gfn, &t, &a, &l, p2m_query);
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
             BUG_ON(mem_sharing_unshare_page(p2m, gfn, MEM_SHARING_DESTROY_GFN));
     }
@@ -2375,6 +2385,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
     mfn_t mfn_return;
     p2m_type_t t;
     p2m_access_t a;
+    int l;
 
     if ( !paging_mode_translate(p2m->domain) )
     {
@@ -2390,7 +2401,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
     {
         for ( i = 0; i < (1UL << page_order); i++ )
         {
-            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query);
+            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, &l, p2m_query);
             if ( !p2m_is_grant(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
@@ -3079,10 +3090,11 @@ void p2m_mem_access_check(unsigned long 
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
+    int p2ml;
     
     /* First, handle rx2rw conversion automatically */
     p2m_lock(p2m);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, &p2ml, p2m_query);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -216,11 +216,13 @@ struct p2m_domain {
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,
                                        p2m_access_t *p2ma,
+                                       int *level,
                                        p2m_query_t q);
     mfn_t              (*get_entry_current)(struct p2m_domain *p2m,
                                             unsigned long gfn,
                                             p2m_type_t *p2mt,
                                             p2m_access_t *p2ma,
+                                            int *level,
                                             p2m_query_t q);
     void               (*change_entry_type_global)(struct p2m_domain *p2m,
                                                    p2m_type_t ot,
@@ -334,7 +336,8 @@ static inline mfn_t gfn_to_mfn_type_curr
                                             p2m_access_t *a,
                                             p2m_query_t q)
 {
-    return p2m->get_entry_current(p2m, gfn, t, a, q);
+    int l;
+    return p2m->get_entry_current(p2m, gfn, t, a, &l, q);
 }
 
 /* Read P2M table, mapping pages as we go.
@@ -344,7 +347,8 @@ gfn_to_mfn_type_p2m(struct p2m_domain *p
                               p2m_type_t *t, p2m_query_t q)
 {
     p2m_access_t a = 0;
-    return p2m->get_entry(p2m, gfn, t, &a, q);
+    int l;
+    return p2m->get_entry(p2m, gfn, t, &a, &l, q);
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo9-00006k-Ch; Fri, 08 Jun 2012 11:56:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Scxo7-00005j-CV
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:47 +0000
Received: from [85.158.143.99:11395] by server-1.bemta-4.messagelabs.com id
	BF/2C-10042-E78E1DF4; Fri, 08 Jun 2012 11:56:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339156604!31589312!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18440 invoked from network); 8 Jun 2012 11:56:45 -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;
	8 Jun 2012 11:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198014261"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-QN;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 672e9628f27845d24a3f37f245c33209cccdc586
Message-ID: <672e9628f27845d24a3f.1339156491@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:51 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Return the p2m level of the entry which filled this request.
Intended to be used to see if pages returned by the balloon
driver are part of a superpage, and reclaim them if so.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3644,6 +3644,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
         p2m_type_t t;
         p2m_access_t ac;
         mfn_t mfn;
+        int l;
 
         /* Interface access to internal p2m accesses */
         hvmmem_access_t memaccess[] = {
@@ -3681,7 +3682,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 goto param_fail6;
 
             rc = -ESRCH;
-            mfn = p2m->get_entry(p2m, a.pfn, &t, &ac, p2m_query);
+            mfn = p2m->get_entry(p2m, a.pfn, &t, &ac, &l, p2m_query);
 
             if ( mfn_x(mfn) == INVALID_MFN )
                 goto param_fail6;
diff --git a/xen/arch/x86/mm/hap/p2m-ept.c b/xen/arch/x86/mm/hap/p2m-ept.c
--- a/xen/arch/x86/mm/hap/p2m-ept.c
+++ b/xen/arch/x86/mm/hap/p2m-ept.c
@@ -527,14 +527,14 @@ out:
 /* Read ept p2m entries */
 static mfn_t ept_get_entry(struct p2m_domain *p2m,
                            unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
-                           p2m_query_t q)
+                           int *level, p2m_query_t q)
 {
     struct domain *d = p2m->domain;
     ept_entry_t *table = map_domain_page(ept_get_asr(d));
     unsigned long gfn_remainder = gfn;
     ept_entry_t *ept_entry;
     u32 index;
-    int i;
+    int i=5;
     int ret = 0;
     mfn_t mfn = _mfn(INVALID_MFN);
 
@@ -616,6 +616,7 @@ static mfn_t ept_get_entry(struct p2m_do
     }
 
 out:
+    *level=i+1;
     unmap_domain_page(table);
     return mfn;
 }
@@ -709,9 +710,10 @@ out:
 
 static mfn_t ept_get_entry_current(struct p2m_domain *p2m,
                                    unsigned long gfn, p2m_type_t *t, p2m_access_t *a,
+                                   int *l,
                                    p2m_query_t q)
 {
-    return ept_get_entry(p2m, gfn, t, a, q);
+    return ept_get_entry(p2m, gfn, t, a, l, q);
 }
 
 /*
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1579,7 +1579,7 @@ out:
 
 static mfn_t
 p2m_gfn_to_mfn(struct p2m_domain *p2m, unsigned long gfn, p2m_type_t *t, p2m_access_t *a,
-               p2m_query_t q)
+               int *level, p2m_query_t q)
 {
     mfn_t mfn;
     paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
@@ -1594,7 +1594,8 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u
      * XXX we will return p2m_invalid for unmapped gfns */
     *t = p2m_mmio_dm;
     /* Not implemented except with EPT */
-    *a = p2m_access_rwx; 
+    *a = p2m_access_rwx;
+    *level = 5;
 
     mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
 
@@ -1602,6 +1603,7 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u
         /* This pfn is higher than the highest the p2m map currently holds */
         return _mfn(INVALID_MFN);
 
+    *level = 4;
 #if CONFIG_PAGING_LEVELS >= 4
     {
         l4_pgentry_t *l4e = map_domain_page(mfn_x(mfn));
@@ -1615,6 +1617,7 @@ p2m_gfn_to_mfn(struct p2m_domain *p2m, u
         unmap_domain_page(l4e);
     }
 #endif
+    *level=3;
     {
         l3_pgentry_t *l3e = map_domain_page(mfn_x(mfn));
 #if CONFIG_PAGING_LEVELS == 3
@@ -1662,6 +1665,7 @@ pod_retry_l3:
 
     l2e = map_domain_page(mfn_x(mfn));
     l2e += l2_table_offset(addr);
+    *level=2;
 
 pod_retry_l2:
     if ( (l2e_get_flags(*l2e) & _PAGE_PRESENT) == 0 )
@@ -1695,6 +1699,7 @@ pod_retry_l2:
 
     l1e = map_domain_page(mfn_x(mfn));
     l1e += l1_table_offset(addr);
+    *level=1;
 pod_retry_l1:
     if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
     {
@@ -1723,7 +1728,7 @@ pod_retry_l1:
 /* Read the current domain's p2m table (through the linear mapping). */
 static mfn_t p2m_gfn_to_mfn_current(struct p2m_domain *p2m,
                                     unsigned long gfn, p2m_type_t *t, p2m_access_t *a,
-                                    p2m_query_t q)
+                                    int *level, p2m_query_t q)
 {
     mfn_t mfn = _mfn(INVALID_MFN);
     p2m_type_t p2mt = p2m_mmio_dm;
@@ -1735,6 +1740,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
 
     /* Not currently implemented except for EPT */
     *a = p2m_access_rwx;
+    *level=5;
 
     if ( gfn <= p2m->max_mapped_pfn )
     {
@@ -1749,6 +1755,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
                / sizeof(l1_pgentry_t));
 
 #if CONFIG_PAGING_LEVELS >= 4
+    *level=3;
         /*
          * Read & process L3
          */
@@ -1802,6 +1809,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
         p2m_entry = &__linear_l1_table[l1_linear_offset(RO_MPT_VIRT_START)
                                        + l2_linear_offset(addr)];
 
+    *level=2;
     pod_retry_l2:
         ret = __copy_from_user(&l2e,
                                p2m_entry,
@@ -1855,6 +1863,7 @@ static mfn_t p2m_gfn_to_mfn_current(stru
 
         /* Need to __copy_from_user because the p2m is sparse and this
          * part might not exist */
+    *level=1;
     pod_retry_l1:
         p2m_entry = &phys_to_machine_mapping[gfn];
 
@@ -2069,6 +2078,7 @@ void p2m_teardown(struct p2m_domain *p2m
     unsigned long gfn;
     p2m_type_t t;
     p2m_access_t a;
+    int l;
     mfn_t mfn;
 #endif
 
@@ -2077,7 +2087,7 @@ void p2m_teardown(struct p2m_domain *p2m
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
-        mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query);
+        mfn = p2m->get_entry(p2m, gfn, &t, &a, &l, p2m_query);
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
             BUG_ON(mem_sharing_unshare_page(p2m, gfn, MEM_SHARING_DESTROY_GFN));
     }
@@ -2375,6 +2385,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
     mfn_t mfn_return;
     p2m_type_t t;
     p2m_access_t a;
+    int l;
 
     if ( !paging_mode_translate(p2m->domain) )
     {
@@ -2390,7 +2401,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
     {
         for ( i = 0; i < (1UL << page_order); i++ )
         {
-            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query);
+            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, &l, p2m_query);
             if ( !p2m_is_grant(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
@@ -3079,10 +3090,11 @@ void p2m_mem_access_check(unsigned long 
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
+    int p2ml;
     
     /* First, handle rx2rw conversion automatically */
     p2m_lock(p2m);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, &p2ml, p2m_query);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -216,11 +216,13 @@ struct p2m_domain {
                                        unsigned long gfn,
                                        p2m_type_t *p2mt,
                                        p2m_access_t *p2ma,
+                                       int *level,
                                        p2m_query_t q);
     mfn_t              (*get_entry_current)(struct p2m_domain *p2m,
                                             unsigned long gfn,
                                             p2m_type_t *p2mt,
                                             p2m_access_t *p2ma,
+                                            int *level,
                                             p2m_query_t q);
     void               (*change_entry_type_global)(struct p2m_domain *p2m,
                                                    p2m_type_t ot,
@@ -334,7 +336,8 @@ static inline mfn_t gfn_to_mfn_type_curr
                                             p2m_access_t *a,
                                             p2m_query_t q)
 {
-    return p2m->get_entry_current(p2m, gfn, t, a, q);
+    int l;
+    return p2m->get_entry_current(p2m, gfn, t, a, &l, q);
 }
 
 /* Read P2M table, mapping pages as we go.
@@ -344,7 +347,8 @@ gfn_to_mfn_type_p2m(struct p2m_domain *p
                               p2m_type_t *t, p2m_query_t q)
 {
     p2m_access_t a = 0;
-    return p2m->get_entry(p2m, gfn, t, &a, q);
+    int l;
+    return p2m->get_entry(p2m, gfn, t, &a, &l, q);
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo8-00006C-8L; Fri, 08 Jun 2012 11:56:48 +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 1Scxo6-00005h-HA
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:46 +0000
Received: from [85.158.143.99:11336] by server-2.bemta-4.messagelabs.com id
	5D/AA-17938-D78E1DF4; Fri, 08 Jun 2012 11:56:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339156604!31589312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18389 invoked from network); 8 Jun 2012 11:56:45 -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;
	8 Jun 2012 11:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198014260"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-Qt;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8264589787b484b7f9036daab2b517d07eeb03b2
Message-ID: <8264589787b484b7f903.1339156492@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:52 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 RFC] xen,
 pod: Check zero-check pages returned by the balloon 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

When a gfn is passed back by the balloon driver to Xen, check
to see if it's in a superpage; and if so, check to see if that
page is zeroed, and if so reclaim it.

This patch significantly reduces superpage fragmentation when
running on a high number of vcpus and significant memory
ballooning.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -74,6 +74,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
 
 #define SUPERPAGE_PAGES (1UL << 9)
 #define superpage_aligned(_x)  (((_x)&(SUPERPAGE_PAGES-1))==0)
+#define order_aligned(_x,_o)  (((_x)&((1<<(_o))-1))==0)
 
 static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
 {
@@ -767,6 +768,9 @@ p2m_pod_offline_or_broken_replace(struct
     return;
 }
 
+static int p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn);
+
+
 /* This function is needed for two reasons:
  * + To properly handle clearing of PoD entries
  * + To "steal back" memory being freed for the PoD cache, rather than
@@ -774,6 +778,9 @@ p2m_pod_offline_or_broken_replace(struct
  *
  * Once both of these functions have been completed, we can return and
  * allow decrease_reservation() to handle everything else.
+ *
+ * Because the balloon driver races with the page scrubber, we also
+ * scan for zeroed superpages we can reclaim.
  */
 int
 p2m_pod_decrease_reservation(struct domain *d,
@@ -781,11 +788,16 @@ p2m_pod_decrease_reservation(struct doma
                              unsigned int order)
 {
     int ret=0;
-    int i;
+    int i, entry_size=0;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     int steal_for_cache = 0;
-    int pod = 0, nonpod = 0, ram = 0;
+    int nonpod = 0;
+#if 0
+    unsigned long gfn_aligned;
+
+    int nonpod = 0, ram = 0;
+#endif
     
 
     /* If we don't have any outstanding PoD entries, let things take their
@@ -794,7 +806,8 @@ p2m_pod_decrease_reservation(struct doma
         goto out;
 
     /* Figure out if we need to steal some freed memory for our cache */
-    steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
+    if ( p2m->pod.entry_count > p2m->pod.count )
+        steal_for_cache = ( p2m->pod.entry_count - p2m->pod.count );
 
     p2m_lock(p2m);
     audit_p2m(p2m, 1);
@@ -802,7 +815,7 @@ p2m_pod_decrease_reservation(struct doma
     if ( unlikely(d->is_dying) )
         goto out_unlock;
 
-    /* See what's in here. */
+#if 0
     /* FIXME: Add contiguous; query for PSE entries? */
     for ( i=0; i<(1<<order); i++)
     {
@@ -876,12 +889,105 @@ p2m_pod_decrease_reservation(struct doma
         }
     }    
 
+#else
+/*
+ * while(more pages to look at)
+ *  - Find the next page unit
+ *    - if req_decrease >= page_size
+ *         or page is zero
+ *       - Reclaim whole page
+ *    - else
+ *       - Reclaim req_decrease         
+ *       - break out of the loop
+ */
+    /* FIXME: Add contiguous; query for PSE entries? */
+    for ( i=0; i<(1<<order); i+=entry_size)
+    {
+        mfn_t mfn;
+        p2m_type_t t;
+        p2m_access_t a;
+        int l, entry_order;
+
+        /* See what's in here. */
+        mfn = p2m->get_entry(p2m, gpfn + i, &t, &a, &l, p2m_query);
+
+        /* NB: entry_size is used by the loop update; so if you change the
+         * level at which you're working (i.e., decide to work w/ 4k
+         * pages instead of a superpage), you must change entry_size
+         * so that the loop logic works right. */
+        entry_order = (l-1)*9;
+        entry_size = 1<<(entry_order);
+
+        /* If this is in a superpage and we need ram, try to nab it */
+        if ( steal_for_cache
+             && entry_order == 9
+             && p2m_is_ram(t)
+             && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)) )
+        {
+            /* Now we have a PoD entry to deal with; update
+             * steal_for_cache, and set entry_size to 0 so that we
+             * re-process the entry. */
+            entry_size=0;
+
+            /* Update steal_for_cache */
+            if ( p2m->pod.entry_count > p2m->pod.count )
+                steal_for_cache = ( p2m->pod.entry_count - p2m->pod.count );
+            else
+                steal_for_cache = 0;
+            
+            continue;
+        }
+
+        /* Switch to singleton pages if we don't want to reclaim the
+         * whole page, or if the start is not SP aligned.  Future
+         * iterations to this superpage frame will then be */
+        if ( entry_order > 0
+             && ( i + entry_size > (1<<order)
+                  || !superpage_aligned(gpfn + i) ) )
+        {
+            entry_order = 0;
+            entry_size = 1;
+        }
+
+        if ( t == p2m_populate_on_demand )
+        {
+            set_p2m_entry(p2m, gpfn+i, _mfn(INVALID_MFN), entry_order, p2m_invalid, p2m->default_access);
+            p2m->pod.entry_count-=(1<<entry_order); /* Lock: p2m */
+            BUG_ON(p2m->pod.entry_count < 0);
+        }
+        else if( p2m_is_ram(t) )
+        {
+            if ( steal_for_cache )
+            {
+                struct page_info *page;
+                
+                ASSERT(mfn_valid(mfn));
+                
+                page = mfn_to_page(mfn);
+                
+                set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), entry_order,
+                              p2m_invalid, p2m->default_access);
+                set_gpfn_from_mfn(mfn_x(mfn), INVALID_M2P_ENTRY);
+                
+                p2m_pod_cache_add(p2m, page, entry_order);
+                
+                /* Update steal_for_cache */
+                if ( p2m->pod.entry_count > p2m->pod.count )
+                    steal_for_cache = ( p2m->pod.entry_count - p2m->pod.count );
+                else
+                    steal_for_cache = 0;
+            }
+            else
+                nonpod++;
+        }
+    }
+#endif
     /* If there are no more non-PoD entries, tell decrease_reservation() that
      * there's nothing left to do. */
     if ( nonpod == 0 )
         ret = 1;
 
-out_entry_check:
+//out_entry_check:
     /* If we've reduced our "liabilities" beyond our "assets", free some */
     if ( p2m->pod.entry_count < p2m->pod.count )
     {
@@ -1040,6 +1146,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     p2m_pod_cache_add(p2m, mfn_to_page(mfn0), 9);
     p2m->pod.entry_count += SUPERPAGE_PAGES;
 
+    ret = SUPERPAGE_PAGES;
+
 out_reset:
     if ( reset )
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo8-00006C-8L; Fri, 08 Jun 2012 11:56:48 +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 1Scxo6-00005h-HA
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:46 +0000
Received: from [85.158.143.99:11336] by server-2.bemta-4.messagelabs.com id
	5D/AA-17938-D78E1DF4; Fri, 08 Jun 2012 11:56:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339156604!31589312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTg3NjU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18389 invoked from network); 8 Jun 2012 11:56:45 -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;
	8 Jun 2012 11:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="198014260"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-Qt;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8264589787b484b7f9036daab2b517d07eeb03b2
Message-ID: <8264589787b484b7f903.1339156492@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:52 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4 RFC] xen,
 pod: Check zero-check pages returned by the balloon 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

When a gfn is passed back by the balloon driver to Xen, check
to see if it's in a superpage; and if so, check to see if that
page is zeroed, and if so reclaim it.

This patch significantly reduces superpage fragmentation when
running on a high number of vcpus and significant memory
ballooning.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -74,6 +74,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
 
 #define SUPERPAGE_PAGES (1UL << 9)
 #define superpage_aligned(_x)  (((_x)&(SUPERPAGE_PAGES-1))==0)
+#define order_aligned(_x,_o)  (((_x)&((1<<(_o))-1))==0)
 
 static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
 {
@@ -767,6 +768,9 @@ p2m_pod_offline_or_broken_replace(struct
     return;
 }
 
+static int p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn);
+
+
 /* This function is needed for two reasons:
  * + To properly handle clearing of PoD entries
  * + To "steal back" memory being freed for the PoD cache, rather than
@@ -774,6 +778,9 @@ p2m_pod_offline_or_broken_replace(struct
  *
  * Once both of these functions have been completed, we can return and
  * allow decrease_reservation() to handle everything else.
+ *
+ * Because the balloon driver races with the page scrubber, we also
+ * scan for zeroed superpages we can reclaim.
  */
 int
 p2m_pod_decrease_reservation(struct domain *d,
@@ -781,11 +788,16 @@ p2m_pod_decrease_reservation(struct doma
                              unsigned int order)
 {
     int ret=0;
-    int i;
+    int i, entry_size=0;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     int steal_for_cache = 0;
-    int pod = 0, nonpod = 0, ram = 0;
+    int nonpod = 0;
+#if 0
+    unsigned long gfn_aligned;
+
+    int nonpod = 0, ram = 0;
+#endif
     
 
     /* If we don't have any outstanding PoD entries, let things take their
@@ -794,7 +806,8 @@ p2m_pod_decrease_reservation(struct doma
         goto out;
 
     /* Figure out if we need to steal some freed memory for our cache */
-    steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
+    if ( p2m->pod.entry_count > p2m->pod.count )
+        steal_for_cache = ( p2m->pod.entry_count - p2m->pod.count );
 
     p2m_lock(p2m);
     audit_p2m(p2m, 1);
@@ -802,7 +815,7 @@ p2m_pod_decrease_reservation(struct doma
     if ( unlikely(d->is_dying) )
         goto out_unlock;
 
-    /* See what's in here. */
+#if 0
     /* FIXME: Add contiguous; query for PSE entries? */
     for ( i=0; i<(1<<order); i++)
     {
@@ -876,12 +889,105 @@ p2m_pod_decrease_reservation(struct doma
         }
     }    
 
+#else
+/*
+ * while(more pages to look at)
+ *  - Find the next page unit
+ *    - if req_decrease >= page_size
+ *         or page is zero
+ *       - Reclaim whole page
+ *    - else
+ *       - Reclaim req_decrease         
+ *       - break out of the loop
+ */
+    /* FIXME: Add contiguous; query for PSE entries? */
+    for ( i=0; i<(1<<order); i+=entry_size)
+    {
+        mfn_t mfn;
+        p2m_type_t t;
+        p2m_access_t a;
+        int l, entry_order;
+
+        /* See what's in here. */
+        mfn = p2m->get_entry(p2m, gpfn + i, &t, &a, &l, p2m_query);
+
+        /* NB: entry_size is used by the loop update; so if you change the
+         * level at which you're working (i.e., decide to work w/ 4k
+         * pages instead of a superpage), you must change entry_size
+         * so that the loop logic works right. */
+        entry_order = (l-1)*9;
+        entry_size = 1<<(entry_order);
+
+        /* If this is in a superpage and we need ram, try to nab it */
+        if ( steal_for_cache
+             && entry_order == 9
+             && p2m_is_ram(t)
+             && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)) )
+        {
+            /* Now we have a PoD entry to deal with; update
+             * steal_for_cache, and set entry_size to 0 so that we
+             * re-process the entry. */
+            entry_size=0;
+
+            /* Update steal_for_cache */
+            if ( p2m->pod.entry_count > p2m->pod.count )
+                steal_for_cache = ( p2m->pod.entry_count - p2m->pod.count );
+            else
+                steal_for_cache = 0;
+            
+            continue;
+        }
+
+        /* Switch to singleton pages if we don't want to reclaim the
+         * whole page, or if the start is not SP aligned.  Future
+         * iterations to this superpage frame will then be */
+        if ( entry_order > 0
+             && ( i + entry_size > (1<<order)
+                  || !superpage_aligned(gpfn + i) ) )
+        {
+            entry_order = 0;
+            entry_size = 1;
+        }
+
+        if ( t == p2m_populate_on_demand )
+        {
+            set_p2m_entry(p2m, gpfn+i, _mfn(INVALID_MFN), entry_order, p2m_invalid, p2m->default_access);
+            p2m->pod.entry_count-=(1<<entry_order); /* Lock: p2m */
+            BUG_ON(p2m->pod.entry_count < 0);
+        }
+        else if( p2m_is_ram(t) )
+        {
+            if ( steal_for_cache )
+            {
+                struct page_info *page;
+                
+                ASSERT(mfn_valid(mfn));
+                
+                page = mfn_to_page(mfn);
+                
+                set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), entry_order,
+                              p2m_invalid, p2m->default_access);
+                set_gpfn_from_mfn(mfn_x(mfn), INVALID_M2P_ENTRY);
+                
+                p2m_pod_cache_add(p2m, page, entry_order);
+                
+                /* Update steal_for_cache */
+                if ( p2m->pod.entry_count > p2m->pod.count )
+                    steal_for_cache = ( p2m->pod.entry_count - p2m->pod.count );
+                else
+                    steal_for_cache = 0;
+            }
+            else
+                nonpod++;
+        }
+    }
+#endif
     /* If there are no more non-PoD entries, tell decrease_reservation() that
      * there's nothing left to do. */
     if ( nonpod == 0 )
         ret = 1;
 
-out_entry_check:
+//out_entry_check:
     /* If we've reduced our "liabilities" beyond our "assets", free some */
     if ( p2m->pod.entry_count < p2m->pod.count )
     {
@@ -1040,6 +1146,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     p2m_pod_cache_add(p2m, mfn_to_page(mfn0), 9);
     p2m->pod.entry_count += SUPERPAGE_PAGES;
 
+    ret = SUPERPAGE_PAGES;
+
 out_reset:
     if ( reset )
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo9-00006a-0W; Fri, 08 Jun 2012 11:56:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Scxo7-00005i-1B
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:47 +0000
Received: from [85.158.143.99:11405] by server-3.bemta-4.messagelabs.com id
	AB/8D-29237-E78E1DF4; Fri, 08 Jun 2012 11:56:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339156603!29586880!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5437 invoked from network); 8 Jun 2012 11:56: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;
	8 Jun 2012 11:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="27343358"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-Rm;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 12351514c58974be97d1c0a4c53e5bfdc1de3a97
Message-ID: <12351514c58974be97d1.1339156494@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:54 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 RFC] imported patch
	pygrub-invalid-disk-catch.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

diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -814,22 +814,27 @@ if __name__ == "__main__":
 
     # get list of offsets into file which start partitions
     part_offs = get_partition_offsets(file)
+    if len(part_offs) < 1:
+        raise RuntimeError, "Disk has no partitions"
 
-    fs = fsimage.open(file, part_offs[0], bootfsoptions)
+    try:
+        fs = fsimage.open(file, part_offs[0], bootfsoptions)
 
-    # We always boot the "default" kernel if it exists, rather than 
-    # parsing the grub menu
-    initrd_path = None
-    if fs.file_exists("/xenkernel"):
-        incfg["kernel"] = "/xenkernel"
-        incfg["args"] = default_args
-        if fs.file_exists("/xeninitrd"):
-            incfg["ramdisk"] = "/xeninitrd"
-    elif fs.file_exists("/boot/xenkernel"):
-        incfg["kernel"] = "/boot/xenkernel"
-        incfg["args"] = default_args
-        if fs.file_exists("/boot/xeninitrd"):
-            incfg["ramdisk"] = "/boot/xeninitrd"
+        # We always boot the "default" kernel if it exists, rather than 
+        # parsing the grub menu
+        initrd_path = None
+        if fs.file_exists("/xenkernel"):
+            incfg["kernel"] = "/xenkernel"
+            incfg["args"] = default_args
+            if fs.file_exists("/xeninitrd"):
+                incfg["ramdisk"] = "/xeninitrd"
+        elif fs.file_exists("/boot/xenkernel"):
+            incfg["kernel"] = "/boot/xenkernel"
+            incfg["args"] = default_args
+            if fs.file_exists("/boot/xeninitrd"):
+                incfg["ramdisk"] = "/boot/xeninitrd"
+    except:
+        raise RuntimeError, "Unable to find partition containing kernel"
 
     for offset in part_offs:
         try:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:56:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxo9-00006a-0W; Fri, 08 Jun 2012 11:56:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Scxo7-00005i-1B
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:56:47 +0000
Received: from [85.158.143.99:11405] by server-3.bemta-4.messagelabs.com id
	AB/8D-29237-E78E1DF4; Fri, 08 Jun 2012 11:56:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339156603!29586880!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5437 invoked from network); 8 Jun 2012 11:56: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;
	8 Jun 2012 11:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,737,1330923600"; d="scan'208";a="27343358"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 07:56:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 07:56:43 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Scxo2-0003wi-Rm;
	Fri, 08 Jun 2012 12:56:42 +0100
MIME-Version: 1.0
X-Mercurial-Node: 12351514c58974be97d1c0a4c53e5bfdc1de3a97
Message-ID: <12351514c58974be97d1.1339156494@elijah>
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Jun 2012 12:54:54 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4 RFC] imported patch
	pygrub-invalid-disk-catch.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

diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -814,22 +814,27 @@ if __name__ == "__main__":
 
     # get list of offsets into file which start partitions
     part_offs = get_partition_offsets(file)
+    if len(part_offs) < 1:
+        raise RuntimeError, "Disk has no partitions"
 
-    fs = fsimage.open(file, part_offs[0], bootfsoptions)
+    try:
+        fs = fsimage.open(file, part_offs[0], bootfsoptions)
 
-    # We always boot the "default" kernel if it exists, rather than 
-    # parsing the grub menu
-    initrd_path = None
-    if fs.file_exists("/xenkernel"):
-        incfg["kernel"] = "/xenkernel"
-        incfg["args"] = default_args
-        if fs.file_exists("/xeninitrd"):
-            incfg["ramdisk"] = "/xeninitrd"
-    elif fs.file_exists("/boot/xenkernel"):
-        incfg["kernel"] = "/boot/xenkernel"
-        incfg["args"] = default_args
-        if fs.file_exists("/boot/xeninitrd"):
-            incfg["ramdisk"] = "/boot/xeninitrd"
+        # We always boot the "default" kernel if it exists, rather than 
+        # parsing the grub menu
+        initrd_path = None
+        if fs.file_exists("/xenkernel"):
+            incfg["kernel"] = "/xenkernel"
+            incfg["args"] = default_args
+            if fs.file_exists("/xeninitrd"):
+                incfg["ramdisk"] = "/xeninitrd"
+        elif fs.file_exists("/boot/xenkernel"):
+            incfg["kernel"] = "/boot/xenkernel"
+            incfg["args"] = default_args
+            if fs.file_exists("/boot/xeninitrd"):
+                incfg["ramdisk"] = "/boot/xeninitrd"
+    except:
+        raise RuntimeError, "Unable to find partition containing kernel"
 
     for offset in part_offs:
         try:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:58:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxpR-0000Rs-29; Fri, 08 Jun 2012 11:58:09 +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 1ScxpP-0000RW-Pn
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:58:07 +0000
Received: from [193.109.254.147:12424] by server-2.bemta-14.messagelabs.com id
	FE/FE-27740-FC8E1DF4; Fri, 08 Jun 2012 11:58:07 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339156682!1895413!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16400 invoked from network); 8 Jun 2012 11:58:03 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:58:03 -0000
Received: by qadb33 with SMTP id b33so722347qad.9
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 04:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=RNn+duJ+P+MlevLNoizE1tH0V3CcIvHTmtxfuNwcm5g=;
	b=0Gi4uwX2c9lFvkHPsML4KNIPCNh+K1CQkXMmnxyQYC/B3cBgwuk0xQu6qzldTRXj4Q
	wToE8vzBJmkA5Nq2HyK5D9scjedsmtp7TicmX5lwcyxJwaf34OJi84FffWXPooUupctH
	GN1HAFyhtuaTPTj8H+Nsl3VpGdFkosgVRJoztfHyU6TUtJpAIolbp2Q+l9pf5lufQb/y
	prz/BhKNWG/x881YkExYe3o8158lnjIlrgZvC7GZ1GoZcD9D7jgAyFAxtj+6Jnbcw1go
	sYx0s95gOrSDgximkKDE9K5A2diMh/zZkm3qkiyGn9I+5OtfF2yCWhLZQqLeFdpv4Baa
	4aQQ==
MIME-Version: 1.0
Received: by 10.224.86.206 with SMTP id t14mr6857319qal.11.1339156682439; Fri,
	08 Jun 2012 04:58:02 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 04:58:02 -0700 (PDT)
In-Reply-To: <12351514c58974be97d1.1339156494@elijah>
References: <patchbomb.1339156490@elijah>
	<12351514c58974be97d1.1339156494@elijah>
Date: Fri, 8 Jun 2012 12:58:02 +0100
X-Google-Sender-Auth: U3GXjW2gRIqjbLjkwBEQh1LI9_o
Message-ID: <CAFLBxZYfoKoBgy1qf4bPM7NseAtnSN0sAXXa=rREYMd=g5jk1A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 4 RFC] imported patch
	pygrub-invalid-disk-catch.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

GAH... please ignore this particular patch, it's a mistake.

On Fri, Jun 8, 2012 at 12:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -814,22 +814,27 @@ if __name__ =3D=3D "__main__":
>
> =A0 =A0 # get list of offsets into file which start partitions
> =A0 =A0 part_offs =3D get_partition_offsets(file)
> + =A0 =A0if len(part_offs) < 1:
> + =A0 =A0 =A0 =A0raise RuntimeError, "Disk has no partitions"
>
> - =A0 =A0fs =3D fsimage.open(file, part_offs[0], bootfsoptions)
> + =A0 =A0try:
> + =A0 =A0 =A0 =A0fs =3D fsimage.open(file, part_offs[0], bootfsoptions)
>
> - =A0 =A0# We always boot the "default" kernel if it exists, rather than
> - =A0 =A0# parsing the grub menu
> - =A0 =A0initrd_path =3D None
> - =A0 =A0if fs.file_exists("/xenkernel"):
> - =A0 =A0 =A0 =A0incfg["kernel"] =3D "/xenkernel"
> - =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> - =A0 =A0 =A0 =A0if fs.file_exists("/xeninitrd"):
> - =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/xeninitrd"
> - =A0 =A0elif fs.file_exists("/boot/xenkernel"):
> - =A0 =A0 =A0 =A0incfg["kernel"] =3D "/boot/xenkernel"
> - =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> - =A0 =A0 =A0 =A0if fs.file_exists("/boot/xeninitrd"):
> - =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/boot/xeninitrd"
> + =A0 =A0 =A0 =A0# We always boot the "default" kernel if it exists, rath=
er than
> + =A0 =A0 =A0 =A0# parsing the grub menu
> + =A0 =A0 =A0 =A0initrd_path =3D None
> + =A0 =A0 =A0 =A0if fs.file_exists("/xenkernel"):
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["kernel"] =3D "/xenkernel"
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> + =A0 =A0 =A0 =A0 =A0 =A0if fs.file_exists("/xeninitrd"):
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/xeninitrd"
> + =A0 =A0 =A0 =A0elif fs.file_exists("/boot/xenkernel"):
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["kernel"] =3D "/boot/xenkernel"
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> + =A0 =A0 =A0 =A0 =A0 =A0if fs.file_exists("/boot/xeninitrd"):
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/boot/xeninitrd"
> + =A0 =A0except:
> + =A0 =A0 =A0 =A0raise RuntimeError, "Unable to find partition containing=
 kernel"
>
> =A0 =A0 for offset in part_offs:
> =A0 =A0 =A0 =A0 try:
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 11:58:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxpR-0000Rs-29; Fri, 08 Jun 2012 11:58:09 +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 1ScxpP-0000RW-Pn
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:58:07 +0000
Received: from [193.109.254.147:12424] by server-2.bemta-14.messagelabs.com id
	FE/FE-27740-FC8E1DF4; Fri, 08 Jun 2012 11:58:07 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339156682!1895413!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16400 invoked from network); 8 Jun 2012 11:58:03 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:58:03 -0000
Received: by qadb33 with SMTP id b33so722347qad.9
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 04:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=RNn+duJ+P+MlevLNoizE1tH0V3CcIvHTmtxfuNwcm5g=;
	b=0Gi4uwX2c9lFvkHPsML4KNIPCNh+K1CQkXMmnxyQYC/B3cBgwuk0xQu6qzldTRXj4Q
	wToE8vzBJmkA5Nq2HyK5D9scjedsmtp7TicmX5lwcyxJwaf34OJi84FffWXPooUupctH
	GN1HAFyhtuaTPTj8H+Nsl3VpGdFkosgVRJoztfHyU6TUtJpAIolbp2Q+l9pf5lufQb/y
	prz/BhKNWG/x881YkExYe3o8158lnjIlrgZvC7GZ1GoZcD9D7jgAyFAxtj+6Jnbcw1go
	sYx0s95gOrSDgximkKDE9K5A2diMh/zZkm3qkiyGn9I+5OtfF2yCWhLZQqLeFdpv4Baa
	4aQQ==
MIME-Version: 1.0
Received: by 10.224.86.206 with SMTP id t14mr6857319qal.11.1339156682439; Fri,
	08 Jun 2012 04:58:02 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 04:58:02 -0700 (PDT)
In-Reply-To: <12351514c58974be97d1.1339156494@elijah>
References: <patchbomb.1339156490@elijah>
	<12351514c58974be97d1.1339156494@elijah>
Date: Fri, 8 Jun 2012 12:58:02 +0100
X-Google-Sender-Auth: U3GXjW2gRIqjbLjkwBEQh1LI9_o
Message-ID: <CAFLBxZYfoKoBgy1qf4bPM7NseAtnSN0sAXXa=rREYMd=g5jk1A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 4 RFC] imported patch
	pygrub-invalid-disk-catch.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

GAH... please ignore this particular patch, it's a mistake.

On Fri, Jun 8, 2012 at 12:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -814,22 +814,27 @@ if __name__ =3D=3D "__main__":
>
> =A0 =A0 # get list of offsets into file which start partitions
> =A0 =A0 part_offs =3D get_partition_offsets(file)
> + =A0 =A0if len(part_offs) < 1:
> + =A0 =A0 =A0 =A0raise RuntimeError, "Disk has no partitions"
>
> - =A0 =A0fs =3D fsimage.open(file, part_offs[0], bootfsoptions)
> + =A0 =A0try:
> + =A0 =A0 =A0 =A0fs =3D fsimage.open(file, part_offs[0], bootfsoptions)
>
> - =A0 =A0# We always boot the "default" kernel if it exists, rather than
> - =A0 =A0# parsing the grub menu
> - =A0 =A0initrd_path =3D None
> - =A0 =A0if fs.file_exists("/xenkernel"):
> - =A0 =A0 =A0 =A0incfg["kernel"] =3D "/xenkernel"
> - =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> - =A0 =A0 =A0 =A0if fs.file_exists("/xeninitrd"):
> - =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/xeninitrd"
> - =A0 =A0elif fs.file_exists("/boot/xenkernel"):
> - =A0 =A0 =A0 =A0incfg["kernel"] =3D "/boot/xenkernel"
> - =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> - =A0 =A0 =A0 =A0if fs.file_exists("/boot/xeninitrd"):
> - =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/boot/xeninitrd"
> + =A0 =A0 =A0 =A0# We always boot the "default" kernel if it exists, rath=
er than
> + =A0 =A0 =A0 =A0# parsing the grub menu
> + =A0 =A0 =A0 =A0initrd_path =3D None
> + =A0 =A0 =A0 =A0if fs.file_exists("/xenkernel"):
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["kernel"] =3D "/xenkernel"
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> + =A0 =A0 =A0 =A0 =A0 =A0if fs.file_exists("/xeninitrd"):
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/xeninitrd"
> + =A0 =A0 =A0 =A0elif fs.file_exists("/boot/xenkernel"):
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["kernel"] =3D "/boot/xenkernel"
> + =A0 =A0 =A0 =A0 =A0 =A0incfg["args"] =3D default_args
> + =A0 =A0 =A0 =A0 =A0 =A0if fs.file_exists("/boot/xeninitrd"):
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0incfg["ramdisk"] =3D "/boot/xeninitrd"
> + =A0 =A0except:
> + =A0 =A0 =A0 =A0raise RuntimeError, "Unable to find partition containing=
 kernel"
>
> =A0 =A0 for offset in part_offs:
> =A0 =A0 =A0 =A0 try:
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 11:58:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxpR-0000S3-ES; Fri, 08 Jun 2012 11:58:09 +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 1ScxpQ-0000Rb-FH
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:58:08 +0000
Received: from [193.109.254.147:12484] by server-1.bemta-14.messagelabs.com id
	6A/DF-08067-FC8E1DF4; Fri, 08 Jun 2012 11:58:07 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339156662!8734455!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20486 invoked from network); 8 Jun 2012 11:57:43 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:57:43 -0000
Received: by qcsp15 with SMTP id p15so1053369qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 04:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=jHKC4sRxuEAgPstgiBoc8jxGn0qt9bDVUKZhD62k2TE=;
	b=yqRV8igUeBwXTlUNAlUm4WwJI9tNVOkehCfBLN+ZSP40AbJoof71h0gDV7dZZotNrF
	LrX/l6pJ+S0XmWlTbXKCDUy+OzidXO/VI2/nu8lUlE+bzPcgr2m8jXlehLtIeKarMowC
	Fb8sGxWXF2pGkN5oklxYgO7T14GXwdGrP7WxSCihvtXGXmVHzR6MSZwPDSuvWZPJBFF1
	TtyzRYlQc/lifrp8Wi0tPixKCJaotAdqy0HxXP+xCNAOTh7hQH/fqwhBeDNNDVLM7tKM
	gKLxi55Qz+yB+UmYobVozBbe12NVWIT08jSJxHq6oxcTudpBF86uThf0rk6VwxDuKL7U
	OoIw==
MIME-Version: 1.0
Received: by 10.229.136.149 with SMTP id r21mr1752621qct.75.1339156660778;
	Fri, 08 Jun 2012 04:57:40 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 04:57:40 -0700 (PDT)
In-Reply-To: <7cb3f51992976cf00cab.1339156493@elijah>
References: <patchbomb.1339156490@elijah>
	<7cb3f51992976cf00cab.1339156493@elijah>
Date: Fri, 8 Jun 2012 12:57:40 +0100
X-Google-Sender-Auth: hVMQ61yBpZL4xz6B-oyqy0fl3xE
Message-ID: <CAFLBxZYG7vJQK9gmSQPcuhVtb3zKMD8+VfycatU8yqN-4mH=xg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 RFC] imported patch
	CA-72761-libxc-error.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

GAH... please ignore this particular patch, it's an accident.

On Fri, Jun 8, 2012 at 12:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_rest=
ore.c
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -87,8 +87,8 @@ static ssize_t rdexact(xc_interface *xch
> =A0 =A0 =A0 =A0 if ( (len =3D=3D -1) && ((errno =3D=3D EINTR) || (errno =
=3D=3D EAGAIN)) )
> =A0 =A0 =A0 =A0 =A0 =A0 continue;
> =A0 =A0 =A0 =A0 if ( len =3D=3D 0 ) {
> - =A0 =A0 =A0 =A0 =A0 =A0ERROR("0-length read");
> - =A0 =A0 =A0 =A0 =A0 =A0errno =3D 0;
> + =A0 =A0 =A0 =A0 =A0 =A0errno =3D EPIPE;
> + =A0 =A0 =A0 =A0 =A0 =A0return -1;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 if ( len <=3D 0 ) {
> =A0 =A0 =A0 =A0 =A0 =A0 ERROR("read_exact_timed failed (read rc: %d, errn=
o: %d, size %d, offset %d)",
> @@ -1253,7 +1253,7 @@ int xc_domain_restore(xc_interface *xch,
> =A0 =A0 =A0 =A0 if ( !ctx->completed ) {
> =A0 =A0 =A0 =A0 =A0 =A0 pagebuf.nr_physpages =3D pagebuf.nr_pages =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, d=
om) < 0 ) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPERROR(tdom, "Error when reading batch");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* pagebuf_get_one already returned a prope=
r error */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:58:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1ScxpR-0000S3-ES; Fri, 08 Jun 2012 11:58:09 +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 1ScxpQ-0000Rb-FH
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:58:08 +0000
Received: from [193.109.254.147:12484] by server-1.bemta-14.messagelabs.com id
	6A/DF-08067-FC8E1DF4; Fri, 08 Jun 2012 11:58:07 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339156662!8734455!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20486 invoked from network); 8 Jun 2012 11:57:43 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:57:43 -0000
Received: by qcsp15 with SMTP id p15so1053369qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 04:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=jHKC4sRxuEAgPstgiBoc8jxGn0qt9bDVUKZhD62k2TE=;
	b=yqRV8igUeBwXTlUNAlUm4WwJI9tNVOkehCfBLN+ZSP40AbJoof71h0gDV7dZZotNrF
	LrX/l6pJ+S0XmWlTbXKCDUy+OzidXO/VI2/nu8lUlE+bzPcgr2m8jXlehLtIeKarMowC
	Fb8sGxWXF2pGkN5oklxYgO7T14GXwdGrP7WxSCihvtXGXmVHzR6MSZwPDSuvWZPJBFF1
	TtyzRYlQc/lifrp8Wi0tPixKCJaotAdqy0HxXP+xCNAOTh7hQH/fqwhBeDNNDVLM7tKM
	gKLxi55Qz+yB+UmYobVozBbe12NVWIT08jSJxHq6oxcTudpBF86uThf0rk6VwxDuKL7U
	OoIw==
MIME-Version: 1.0
Received: by 10.229.136.149 with SMTP id r21mr1752621qct.75.1339156660778;
	Fri, 08 Jun 2012 04:57:40 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 04:57:40 -0700 (PDT)
In-Reply-To: <7cb3f51992976cf00cab.1339156493@elijah>
References: <patchbomb.1339156490@elijah>
	<7cb3f51992976cf00cab.1339156493@elijah>
Date: Fri, 8 Jun 2012 12:57:40 +0100
X-Google-Sender-Auth: hVMQ61yBpZL4xz6B-oyqy0fl3xE
Message-ID: <CAFLBxZYG7vJQK9gmSQPcuhVtb3zKMD8+VfycatU8yqN-4mH=xg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4 RFC] imported patch
	CA-72761-libxc-error.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

GAH... please ignore this particular patch, it's an accident.

On Fri, Jun 8, 2012 at 12:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_rest=
ore.c
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -87,8 +87,8 @@ static ssize_t rdexact(xc_interface *xch
> =A0 =A0 =A0 =A0 if ( (len =3D=3D -1) && ((errno =3D=3D EINTR) || (errno =
=3D=3D EAGAIN)) )
> =A0 =A0 =A0 =A0 =A0 =A0 continue;
> =A0 =A0 =A0 =A0 if ( len =3D=3D 0 ) {
> - =A0 =A0 =A0 =A0 =A0 =A0ERROR("0-length read");
> - =A0 =A0 =A0 =A0 =A0 =A0errno =3D 0;
> + =A0 =A0 =A0 =A0 =A0 =A0errno =3D EPIPE;
> + =A0 =A0 =A0 =A0 =A0 =A0return -1;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 if ( len <=3D 0 ) {
> =A0 =A0 =A0 =A0 =A0 =A0 ERROR("read_exact_timed failed (read rc: %d, errn=
o: %d, size %d, offset %d)",
> @@ -1253,7 +1253,7 @@ int xc_domain_restore(xc_interface *xch,
> =A0 =A0 =A0 =A0 if ( !ctx->completed ) {
> =A0 =A0 =A0 =A0 =A0 =A0 pagebuf.nr_physpages =3D pagebuf.nr_pages =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, d=
om) < 0 ) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPERROR(tdom, "Error when reading batch");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* pagebuf_get_one already returned a prope=
r error */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 11:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxq8-0000eU-SV; Fri, 08 Jun 2012 11:58:52 +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 1Scxq7-0000e3-Oh
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:58:51 +0000
Received: from [85.158.138.51:22203] by server-8.bemta-3.messagelabs.com id
	FF/64-22118-AF8E1DF4; Fri, 08 Jun 2012 11:58:50 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339156729!28587857!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16854 invoked from network); 8 Jun 2012 11:58:50 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:58:50 -0000
Received: by qcsp15 with SMTP id p15so1053911qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 04:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=RwzTdenXO00qiV9IFqDyLsVnx2pmmaeVr885KpLBc7k=;
	b=BiYpmvgBCm/GTeSbBvQmxGIOXv49PHk8jznjGH2hw5wNPW4JwT/1m5GTpTiC66fV5e
	xm++C3tbRx7NSDtOKkquy/WpjbtmJS60tGAQYuGKymZrKSrt4XSwrGJJ818crRJ7NnxU
	VbjVj4U3W1R0I5Ea9HMazT4/b6j+XLwcHHk+R+gvSK6jO0tAoqp3ddX1/YskgHNBd1mW
	lo/vHJ8dBy4F+biuuvlHRyTJuMxgRBIA2echrOGCLWGCf9WoP0YgEpKZRYtfKQMEzoD8
	iMaR9d0s8uDiYW4fqsbjiIFre6A9713S2NJuOkUxlleQKjnPPFLdPg6PBJu+88F8ykUn
	a3xA==
MIME-Version: 1.0
Received: by 10.229.135.9 with SMTP id l9mr1797562qct.91.1339156728930; Fri,
	08 Jun 2012 04:58:48 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 04:58:48 -0700 (PDT)
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
Date: Fri, 8 Jun 2012 12:58:48 +0100
X-Google-Sender-Auth: mJfmrDcskdo-X_K1MbaPo-wqw3M
Message-ID: <CAFLBxZbMZPCuZ0cFRBbo2vuH25PgiGZqLhUdoCTkSwJ7aT4tgg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 RFC] Populate-on-demand: Check pages
 being returned by the balloon 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hmm, a mistake in my command line (and the lack of -n) sent two
extraneous patches.  Please look at just patches 1 and 2, and ignore 3
and 4.

Thanks,
 -George

On Fri, Jun 8, 2012 at 12:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> Populate-on-demand: Check pages being returned by the balloon driver
>
> This patch series is the second result of my work last summer on
> decreasing fragmentation of superpages in a guests' p2m when using
> populate-on-demand.
>
> This patch series is against 4.1; I'm posting it to get feedback on
> the viability of getting a ported version of this patch into 4.2.
>
> As with the previous series, the patces against 4.1 have been
> extensively in the XenServer testing framework and have been in use by
> XenServer customers for over 9 months now. =A0But the p2m code has
> changed extensively in that time, so one could argue that the testing
> doesn't give us the same degree of confidence in the patches against
> 4.2 as against 4.1.
>
> Looking at it now, there are a number of ugly bits -- "#if 0" and
> such; please overlook this for now, as it will all be cleaned up as
> part of the porting process.
>
> If this looks good, I'll do the work of porting and testing it before
> posting it again.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 11:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 11: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 1Scxq8-0000eU-SV; Fri, 08 Jun 2012 11:58:52 +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 1Scxq7-0000e3-Oh
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 11:58:51 +0000
Received: from [85.158.138.51:22203] by server-8.bemta-3.messagelabs.com id
	FF/64-22118-AF8E1DF4; Fri, 08 Jun 2012 11:58:50 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339156729!28587857!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16854 invoked from network); 8 Jun 2012 11:58:50 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 11:58:50 -0000
Received: by qcsp15 with SMTP id p15so1053911qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 04:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=RwzTdenXO00qiV9IFqDyLsVnx2pmmaeVr885KpLBc7k=;
	b=BiYpmvgBCm/GTeSbBvQmxGIOXv49PHk8jznjGH2hw5wNPW4JwT/1m5GTpTiC66fV5e
	xm++C3tbRx7NSDtOKkquy/WpjbtmJS60tGAQYuGKymZrKSrt4XSwrGJJ818crRJ7NnxU
	VbjVj4U3W1R0I5Ea9HMazT4/b6j+XLwcHHk+R+gvSK6jO0tAoqp3ddX1/YskgHNBd1mW
	lo/vHJ8dBy4F+biuuvlHRyTJuMxgRBIA2echrOGCLWGCf9WoP0YgEpKZRYtfKQMEzoD8
	iMaR9d0s8uDiYW4fqsbjiIFre6A9713S2NJuOkUxlleQKjnPPFLdPg6PBJu+88F8ykUn
	a3xA==
MIME-Version: 1.0
Received: by 10.229.135.9 with SMTP id l9mr1797562qct.91.1339156728930; Fri,
	08 Jun 2012 04:58:48 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 04:58:48 -0700 (PDT)
In-Reply-To: <patchbomb.1339156490@elijah>
References: <patchbomb.1339156490@elijah>
Date: Fri, 8 Jun 2012 12:58:48 +0100
X-Google-Sender-Auth: mJfmrDcskdo-X_K1MbaPo-wqw3M
Message-ID: <CAFLBxZbMZPCuZ0cFRBbo2vuH25PgiGZqLhUdoCTkSwJ7aT4tgg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 RFC] Populate-on-demand: Check pages
 being returned by the balloon 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hmm, a mistake in my command line (and the lack of -n) sent two
extraneous patches.  Please look at just patches 1 and 2, and ignore 3
and 4.

Thanks,
 -George

On Fri, Jun 8, 2012 at 12:54 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> Populate-on-demand: Check pages being returned by the balloon driver
>
> This patch series is the second result of my work last summer on
> decreasing fragmentation of superpages in a guests' p2m when using
> populate-on-demand.
>
> This patch series is against 4.1; I'm posting it to get feedback on
> the viability of getting a ported version of this patch into 4.2.
>
> As with the previous series, the patces against 4.1 have been
> extensively in the XenServer testing framework and have been in use by
> XenServer customers for over 9 months now. =A0But the p2m code has
> changed extensively in that time, so one could argue that the testing
> doesn't give us the same degree of confidence in the patches against
> 4.2 as against 4.1.
>
> Looking at it now, there are a number of ugly bits -- "#if 0" and
> such; please overlook this for now, as it will all be cleaned up as
> part of the porting process.
>
> If this looks good, I'll do the work of porting and testing it before
> posting it again.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 12:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 12: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 1Scxsp-0001GL-9f; Fri, 08 Jun 2012 12:01: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 1Scxsn-0001Fu-8e
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 12:01:37 +0000
Received: from [85.158.138.51:45682] by server-4.bemta-3.messagelabs.com id
	B2/B5-13598-0A9E1DF4; Fri, 08 Jun 2012 12:01:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339156895!28588504!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30453 invoked from network); 8 Jun 2012 12:01:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 12:01:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 13:01:35 +0100
Message-Id: <4FD205E80200007800088C36@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 13:02:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <george.dunlap@eu.citrix.com>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
In-Reply-To: <4145b32d0c43d7d46650.1339155932@exile>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:45, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> When demand-populating pages due to guest accesses, check recently populated
> pages to see if we can reclaim them for the cache.  This should keep the PoD
> cache filled when the start-of-day scrubber is going through.
> 
> The number 128 was chosen by experiment.  Windows does its page
> scrubbing in parallel; while a small nubmer like 4 works well for
> single VMs, it breaks down as multiple vcpus are scrubbing different
> pages in parallel.  Increasing to 128 works well for higher numbers of
> vcpus.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -909,6 +909,26 @@ p2m_pod_emergency_sweep_super(struct p2m
>      p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
>  }
>  
> +/* When populating a new superpage, look at recently populated superpages
> + * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
> + * the guest OS is done with them. */
> +static void
> +p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
> +{
> +    unsigned long check_gfn;
> +
> +    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
> +
> +    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
> +
> +    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
> +
> +    p2m->pod.last_populated_index = ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
> +
> +    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m, check_gfn);
> +}
> +
> +
>  #define POD_SWEEP_STRIDE  16
>  static void
>  p2m_pod_emergency_sweep(struct p2m_domain *p2m)
> @@ -1066,6 +1086,12 @@ p2m_pod_demand_populate(struct p2m_domai
>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>      }
>  
> +    /* Check the last guest demand-populate */
> +    if ( p2m->pod.entry_count > p2m->pod.count 
> +         && order == 9
> +         && q & P2M_ALLOC )
> +        p2m_pod_check_last_super(p2m, gfn_aligned);
> +
>      pod_unlock(p2m);
>      return 0;
>  out_of_memory:
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -287,6 +287,9 @@ struct p2m_domain {
>          unsigned         reclaim_super; /* Last gpfn of a scan */
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest demand-populate */
> +#define POD_HISTORY_MAX 128
> +        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */

unsigned long?

Also, wouldn't it be better to allocate this table dynamically, at
once allowing its size to scale with the number of vCPU-s in the
guest?

> +        int              last_populated_index;

'unsigned int' is generally better suited for array indexes (and
definitely on x86-64).

Jan

>          mm_lock_t        lock;         /* Locking of private pod structs,   
> *
>                                          * not relying on the p2m lock.      
> */
>      } pod;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 08 12:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 12: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 1Scxsp-0001GL-9f; Fri, 08 Jun 2012 12:01: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 1Scxsn-0001Fu-8e
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 12:01:37 +0000
Received: from [85.158.138.51:45682] by server-4.bemta-3.messagelabs.com id
	B2/B5-13598-0A9E1DF4; Fri, 08 Jun 2012 12:01:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339156895!28588504!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30453 invoked from network); 8 Jun 2012 12:01:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 12:01:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 13:01:35 +0100
Message-Id: <4FD205E80200007800088C36@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 13:02:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <george.dunlap@eu.citrix.com>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
In-Reply-To: <4145b32d0c43d7d46650.1339155932@exile>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:45, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> When demand-populating pages due to guest accesses, check recently populated
> pages to see if we can reclaim them for the cache.  This should keep the PoD
> cache filled when the start-of-day scrubber is going through.
> 
> The number 128 was chosen by experiment.  Windows does its page
> scrubbing in parallel; while a small nubmer like 4 works well for
> single VMs, it breaks down as multiple vcpus are scrubbing different
> pages in parallel.  Increasing to 128 works well for higher numbers of
> vcpus.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -909,6 +909,26 @@ p2m_pod_emergency_sweep_super(struct p2m
>      p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
>  }
>  
> +/* When populating a new superpage, look at recently populated superpages
> + * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
> + * the guest OS is done with them. */
> +static void
> +p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
> +{
> +    unsigned long check_gfn;
> +
> +    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
> +
> +    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
> +
> +    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
> +
> +    p2m->pod.last_populated_index = ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
> +
> +    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m, check_gfn);
> +}
> +
> +
>  #define POD_SWEEP_STRIDE  16
>  static void
>  p2m_pod_emergency_sweep(struct p2m_domain *p2m)
> @@ -1066,6 +1086,12 @@ p2m_pod_demand_populate(struct p2m_domai
>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>      }
>  
> +    /* Check the last guest demand-populate */
> +    if ( p2m->pod.entry_count > p2m->pod.count 
> +         && order == 9
> +         && q & P2M_ALLOC )
> +        p2m_pod_check_last_super(p2m, gfn_aligned);
> +
>      pod_unlock(p2m);
>      return 0;
>  out_of_memory:
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -287,6 +287,9 @@ struct p2m_domain {
>          unsigned         reclaim_super; /* Last gpfn of a scan */
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest demand-populate */
> +#define POD_HISTORY_MAX 128
> +        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */

unsigned long?

Also, wouldn't it be better to allocate this table dynamically, at
once allowing its size to scale with the number of vCPU-s in the
guest?

> +        int              last_populated_index;

'unsigned int' is generally better suited for array indexes (and
definitely on x86-64).

Jan

>          mm_lock_t        lock;         /* Locking of private pod structs,   
> *
>                                          * not relying on the p2m lock.      
> */
>      } pod;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 08 12:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 12:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scy6l-0001nc-Rd; Fri, 08 Jun 2012 12:16:03 +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 1Scy6j-0001nX-Qi
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 12:16:02 +0000
Received: from [85.158.143.99:23400] by server-3.bemta-4.messagelabs.com id
	B6/3F-29237-10DE1DF4; Fri, 08 Jun 2012 12:16:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339157760!26595292!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24950 invoked from network); 8 Jun 2012 12:16:00 -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; 8 Jun 2012 12:16:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 13:16:00 +0100
Message-Id: <4FD209480200007800088C52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 13:16:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 08.06.12 at 13:42, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Fri, 8 Jun 2012, Jan Beulich wrote:
>> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> wrote:
>> > On Mon, 4 Jun 2012, Jan Beulich wrote:
>> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
>> >> os-posix.c:os_find_datadir() works. While one would generally expect
>> >> that function to honour the --datadir configure option, fixing this is
>> >> quite a bit more involved than simply adjusting the configure options
>> >> to match the function's behavior (in that, for an installed binary, it
>> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
>> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
>> >> due to (presumably) some other qemu instance being installed on
>> >> people's systems (but being absent when running qemu-system-i386 from
>> >> the dist/ portion of the build tree).
>> >> 
>> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
>> >> 
>> >> --- a/tools/Makefile
>> >> +++ b/tools/Makefile
>> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>> >>  		-L$(XEN_ROOT)/tools/xenstore" \
>> >>  		--bindir=$(LIBEXEC) \
>> >> -		--datadir=$(SHAREDIR)/qemu-xen \
>> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>> >>  		--disable-kvm \
>> >>  		--python=$(PYTHON) \
>> >>  		$(IOEMU_CONFIGURE_CROSS); \
>> >> 
>> >> 
>> >> 
>> >> 
>> > 
>> > This is a QEMU bug, so I would rather fix it there.
>> 
>> That's not as simple as you appear to think, as it would be necessary
>> to meaningfully express an arbitrary datadir relative to bindir.
>> 
>> > In fact the fix could be as simple as the appended patch.
>> > Does it work for you?
>> > 
>> > diff --git a/os-posix.c b/os-posix.c
>> > index dc4a6bb..d0c873d 100644
>> > --- a/os-posix.c
>> > +++ b/os-posix.c
>> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
>> >              g_free(res);
>> >              res = NULL;
>> >          }
>> > +    } else {
>> > +        g_free(res);
>> > +        res = NULL;
>> 
>> How can this work? Afaict it would even break currently working
>> cases, as it now makes the function return NULL not only when
>> both access() checks failed, but also when the first one succeeded.
> 
> Yes, you are right, I misread the error condition of "access".
> 
> Like you wrote, os_find_datadir checks for the existence of
> $bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
> it checks for /usr/lib/xen/pc-bios and if they both don't exist return
> NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).

That is what you want in the installed case.

> While it is certainly not how I would have written this code, it should
> work correctly. How is that you system has /usr/lib/xen/pc-bios or
> /usr/lib/xen/share/qemu?

As I had written in the description, I'm after the non-installed
case instead (i.e. running from the build tree's dist/), and that
case can only be covered by either fixing os_find_datadir() or
forcing the value of --datadir to match the function's
expectations.

Additionally, for the installed case it doesn't matter where the
bits are put, as it'll always be the configured value that gets
used.

(The reason for caring about the not-installed case is quite
obviously that running multiple versions of Xen in parallel on
a single system wouldn't work well if one was to install each
version.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 12:16:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 12:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Scy6l-0001nc-Rd; Fri, 08 Jun 2012 12:16:03 +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 1Scy6j-0001nX-Qi
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 12:16:02 +0000
Received: from [85.158.143.99:23400] by server-3.bemta-4.messagelabs.com id
	B6/3F-29237-10DE1DF4; Fri, 08 Jun 2012 12:16:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339157760!26595292!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24950 invoked from network); 8 Jun 2012 12:16:00 -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; 8 Jun 2012 12:16:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 13:16:00 +0100
Message-Id: <4FD209480200007800088C52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 13:16:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 08.06.12 at 13:42, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Fri, 8 Jun 2012, Jan Beulich wrote:
>> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> wrote:
>> > On Mon, 4 Jun 2012, Jan Beulich wrote:
>> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
>> >> os-posix.c:os_find_datadir() works. While one would generally expect
>> >> that function to honour the --datadir configure option, fixing this is
>> >> quite a bit more involved than simply adjusting the configure options
>> >> to match the function's behavior (in that, for an installed binary, it
>> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
>> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
>> >> due to (presumably) some other qemu instance being installed on
>> >> people's systems (but being absent when running qemu-system-i386 from
>> >> the dist/ portion of the build tree).
>> >> 
>> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
>> >> 
>> >> --- a/tools/Makefile
>> >> +++ b/tools/Makefile
>> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>> >>  		-L$(XEN_ROOT)/tools/xenstore" \
>> >>  		--bindir=$(LIBEXEC) \
>> >> -		--datadir=$(SHAREDIR)/qemu-xen \
>> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>> >>  		--disable-kvm \
>> >>  		--python=$(PYTHON) \
>> >>  		$(IOEMU_CONFIGURE_CROSS); \
>> >> 
>> >> 
>> >> 
>> >> 
>> > 
>> > This is a QEMU bug, so I would rather fix it there.
>> 
>> That's not as simple as you appear to think, as it would be necessary
>> to meaningfully express an arbitrary datadir relative to bindir.
>> 
>> > In fact the fix could be as simple as the appended patch.
>> > Does it work for you?
>> > 
>> > diff --git a/os-posix.c b/os-posix.c
>> > index dc4a6bb..d0c873d 100644
>> > --- a/os-posix.c
>> > +++ b/os-posix.c
>> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
>> >              g_free(res);
>> >              res = NULL;
>> >          }
>> > +    } else {
>> > +        g_free(res);
>> > +        res = NULL;
>> 
>> How can this work? Afaict it would even break currently working
>> cases, as it now makes the function return NULL not only when
>> both access() checks failed, but also when the first one succeeded.
> 
> Yes, you are right, I misread the error condition of "access".
> 
> Like you wrote, os_find_datadir checks for the existence of
> $bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
> it checks for /usr/lib/xen/pc-bios and if they both don't exist return
> NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).

That is what you want in the installed case.

> While it is certainly not how I would have written this code, it should
> work correctly. How is that you system has /usr/lib/xen/pc-bios or
> /usr/lib/xen/share/qemu?

As I had written in the description, I'm after the non-installed
case instead (i.e. running from the build tree's dist/), and that
case can only be covered by either fixing os_find_datadir() or
forcing the value of --datadir to match the function's
expectations.

Additionally, for the installed case it doesn't matter where the
bits are put, as it'll always be the configured value that gets
used.

(The reason for caring about the not-installed case is quite
obviously that running multiple versions of Xen in parallel on
a single system wouldn't work well if one was to install each
version.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:12:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:12: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 1Scyz6-0002Iv-Ap; Fri, 08 Jun 2012 13:12:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1Scyz5-0002Iq-FR
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:12:11 +0000
Received: from [193.109.254.147:11995] by server-8.bemta-14.messagelabs.com id
	27/E3-27132-A2AF1DF4; Fri, 08 Jun 2012 13:12:10 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339161099!8765701!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMTUwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12400 invoked from network); 8 Jun 2012 13:11:40 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 13:11:40 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B279D207DD
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 09:11:07 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute1.internal (MEProxy); Fri, 08 Jun 2012 09:11:07 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=mesmtp; bh=BrQRCYpSmP2nUXvVculNyJFnVys=; b=
	gQCBWTQjFIJU53pWP+JJJBzZujch1zbkRyMYYL9MidQDdEvVLM7TifJKTgsjAKfZ
	+eIJJqG6WaWGrf8/Qkw6XRgyBzZcsfMTo6j53Enmj/zI4AdX2MT2bH/gcvcp6Gp8
	gnhgHVSbW89s62fc4O4Epn2n+TklM1FgWEo+Foq/aRE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=smtpout; bh=BrQRCYpSmP2nUXvVculNyJFnVys
	=; b=QZBNBv2HE9lxiK2kKyH01XcpCP7RpUiVaz1bjh1LBUoaVe7rdaN/D7mjXK2
	0j9xIQxF3dCE1FO9Sc6q22y8wzKAM7cR+gmYc/b9OXFSopUBhnYtFhr+mkibFV0M
	Ve8aJ6Fc7YsExVpDS13SzehrsECmQHegtDHvEy2zMYqy95PQ=
X-Sasl-enc: MwuL4QECTkJmM5inP5aCk9KbiZjUY/vo5R+LaACb3i9V 1339161067
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 509E84837F6
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 09:11:07 -0400 (EDT)
Message-ID: <4FD1F9E8.20508@invisiblethingslab.com>
Date: Fri, 08 Jun 2012 15:11:04 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.1
Subject: [Xen-devel] block backend 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: multipart/mixed; boundary="===============3773219682007729060=="
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)
--===============3773219682007729060==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigFFD4C680D67EA0F80C21907E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFFD4C680D67EA0F80C21907E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey,

I've faced strange problem with block devices. When trying to read some f=
ile
(from read-only ext3), everything looks good, except that file content is=

corrupted! But this can be coincidence (that "failed" reads doesn't hit
filesystem metadata).
fsck in dom0 on filesystem image returns no errors.
fsck (with -nf flags) in domU on the device causes the kernel to output
"blkfront: flush disk cache: empty write xvdd op failed", "blkfront: xvdd=
:
barrier or flush: disable". And returns no filesystem errors. From that p=
oint,
file reads return correct file content. For most cases dropping block cac=
he
(echo 3 > /proc/sys/vm/drop_caches) or remounting device also "fixes" the=
 problem.

On RW device (with different size, filesystem and content), domU kernel
complains about EXT4 errors.
Doesn't observed such strange issues on device-mapper backed devices.

On 3.2.7 it worked, problem observed on 3.3.5 and 3.4 in dom0, regardless=
 of
domU kernel (tried 3.2.7, 3.3.5, 3.4.0).

I've suspected feature-flush-cache/feature-barrier, but when disabled its=

advertise in blkback code, problem still occurs.

Some details:
dom0: 3.4.0-1.pvops.qubes.x86_64 (vanilla 3.4 + Konrad's patches for ACPI=
 S3)
domU: 3.3.5-1.pvops.qubes.x86_64 (vanilla 3.3.5 + Konrad's patches for AC=
PI S3)

domU:
# mount | grep /lib/modules
/dev/xvdd on /usr/lib/modules type ext3
(ro,relatime,errors=3Dcontinue,barrier=3D1,data=3Dordered)
# pwd
/lib/modules/3.3.5-1.pvops.qubes.x86_64/kernel
# md5sum ./sound/usb/snd-usbmidi-lib.ko
fbc0aeb4dd5c0c3b041a5899a15c6566  ./sound/usb/snd-usbmidi-lib.ko
# ls -l ./sound/usb/snd-usbmidi-lib.ko
-rwxr--r-- 1 root root 38248 May 20 14:14 ./sound/usb/snd-usbmidi-lib.ko

dom0:
# mount|grep modules
/var/lib/qubes/vm-kernels/3.3.5/modules.img on /mnt/tmp type ext3
(ro,loop=3D/dev/loop10)
# pwd
/mnt/tmp/3.3.5-1.pvops.qubes.x86_64/kernel
# md5sum ./sound/usb/snd-usbmidi-lib.ko
9d2d3fedd4a357252e367fa8109c16ed  ./sound/usb/snd-usbmidi-lib.ko
# ls -l ./sound/usb/snd-usbmidi-lib.ko
-rwxr--r-- 1 root root 38248 May 20 14:14 ./sound/usb/snd-usbmidi-lib.ko

And block backend parameters:
# xenstore-ls /local/domain/0/backend/vbd/3/51760
frontend =3D "/local/domain/3/device/vbd/51760"
params =3D "/var/lib/qubes/vm-kernels/3.3.5/modules.img"
scripted =3D "1"
frontend-id =3D "3"
online =3D "1"
removable =3D "0"
bootable =3D "1"
state =3D "4"
dev =3D "xvdd"
type =3D "file"
mode =3D "r"
node =3D "/dev/loop4"
physical-device =3D "7:4"
hotplug-status =3D "connected"
feature-flush-cache =3D "1"
discard-granularity =3D "4096"
discard-alignment =3D "0"
discard-secure =3D "0"
feature-discard =3D "1"
feature-barrier =3D "1"
sectors =3D "409600"
info =3D "4"
sector-size =3D "512"

BTW 3.2.7 advertise feature-flush-cache=3D0 and feature-barrier=3D0 on th=
is one
device (RO, loop backed). Don't know why, but seems irrelevant to this is=
sue.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigFFD4C680D67EA0F80C21907E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP0fnoAAoJENuP0xzK19csX3QH/0rWMObmYSQmjXQn+LdcuAyZ
FqVqDlv/2229qUMBeVfmLst6jFX2WhKuAH+WEiJSW6ZTxfpZ4uha8s4k5Nh3ARqJ
rOM/lTxx7MtY19mwt0cZvdfip6UI1pV0kVH3m0vxsrL5kV30UVaCY6XlT55T1sO+
YSvkvq1MFG1EInbW2QFhQ1+rxfVRL42+tsXo7iBrvPrzwMVcfKy6BiAlDDg/lkwQ
TFsKTlbesp/EATVmZRXilLh1mxTL1oGZ5pESrR0y3uJrVE+bqA1uqBgQ2UJYpTJE
HSBFHEReFTrFh1y/00hR0BCQPXTFPQ/s+jsfg1GH3IwGxN+oxiyMRMpFW2uAVZQ=
=Gtdx
-----END PGP SIGNATURE-----

--------------enigFFD4C680D67EA0F80C21907E--


--===============3773219682007729060==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3773219682007729060==--


From xen-devel-bounces@lists.xen.org Fri Jun 08 13:12:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:12: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 1Scyz6-0002Iv-Ap; Fri, 08 Jun 2012 13:12:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1Scyz5-0002Iq-FR
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:12:11 +0000
Received: from [193.109.254.147:11995] by server-8.bemta-14.messagelabs.com id
	27/E3-27132-A2AF1DF4; Fri, 08 Jun 2012 13:12:10 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339161099!8765701!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMTUwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12400 invoked from network); 8 Jun 2012 13:11:40 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 13:11:40 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B279D207DD
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 09:11:07 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute1.internal (MEProxy); Fri, 08 Jun 2012 09:11:07 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=mesmtp; bh=BrQRCYpSmP2nUXvVculNyJFnVys=; b=
	gQCBWTQjFIJU53pWP+JJJBzZujch1zbkRyMYYL9MidQDdEvVLM7TifJKTgsjAKfZ
	+eIJJqG6WaWGrf8/Qkw6XRgyBzZcsfMTo6j53Enmj/zI4AdX2MT2bH/gcvcp6Gp8
	gnhgHVSbW89s62fc4O4Epn2n+TklM1FgWEo+Foq/aRE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=smtpout; bh=BrQRCYpSmP2nUXvVculNyJFnVys
	=; b=QZBNBv2HE9lxiK2kKyH01XcpCP7RpUiVaz1bjh1LBUoaVe7rdaN/D7mjXK2
	0j9xIQxF3dCE1FO9Sc6q22y8wzKAM7cR+gmYc/b9OXFSopUBhnYtFhr+mkibFV0M
	Ve8aJ6Fc7YsExVpDS13SzehrsECmQHegtDHvEy2zMYqy95PQ=
X-Sasl-enc: MwuL4QECTkJmM5inP5aCk9KbiZjUY/vo5R+LaACb3i9V 1339161067
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 509E84837F6
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 09:11:07 -0400 (EDT)
Message-ID: <4FD1F9E8.20508@invisiblethingslab.com>
Date: Fri, 08 Jun 2012 15:11:04 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.1
Subject: [Xen-devel] block backend 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: multipart/mixed; boundary="===============3773219682007729060=="
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)
--===============3773219682007729060==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigFFD4C680D67EA0F80C21907E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFFD4C680D67EA0F80C21907E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey,

I've faced strange problem with block devices. When trying to read some f=
ile
(from read-only ext3), everything looks good, except that file content is=

corrupted! But this can be coincidence (that "failed" reads doesn't hit
filesystem metadata).
fsck in dom0 on filesystem image returns no errors.
fsck (with -nf flags) in domU on the device causes the kernel to output
"blkfront: flush disk cache: empty write xvdd op failed", "blkfront: xvdd=
:
barrier or flush: disable". And returns no filesystem errors. From that p=
oint,
file reads return correct file content. For most cases dropping block cac=
he
(echo 3 > /proc/sys/vm/drop_caches) or remounting device also "fixes" the=
 problem.

On RW device (with different size, filesystem and content), domU kernel
complains about EXT4 errors.
Doesn't observed such strange issues on device-mapper backed devices.

On 3.2.7 it worked, problem observed on 3.3.5 and 3.4 in dom0, regardless=
 of
domU kernel (tried 3.2.7, 3.3.5, 3.4.0).

I've suspected feature-flush-cache/feature-barrier, but when disabled its=

advertise in blkback code, problem still occurs.

Some details:
dom0: 3.4.0-1.pvops.qubes.x86_64 (vanilla 3.4 + Konrad's patches for ACPI=
 S3)
domU: 3.3.5-1.pvops.qubes.x86_64 (vanilla 3.3.5 + Konrad's patches for AC=
PI S3)

domU:
# mount | grep /lib/modules
/dev/xvdd on /usr/lib/modules type ext3
(ro,relatime,errors=3Dcontinue,barrier=3D1,data=3Dordered)
# pwd
/lib/modules/3.3.5-1.pvops.qubes.x86_64/kernel
# md5sum ./sound/usb/snd-usbmidi-lib.ko
fbc0aeb4dd5c0c3b041a5899a15c6566  ./sound/usb/snd-usbmidi-lib.ko
# ls -l ./sound/usb/snd-usbmidi-lib.ko
-rwxr--r-- 1 root root 38248 May 20 14:14 ./sound/usb/snd-usbmidi-lib.ko

dom0:
# mount|grep modules
/var/lib/qubes/vm-kernels/3.3.5/modules.img on /mnt/tmp type ext3
(ro,loop=3D/dev/loop10)
# pwd
/mnt/tmp/3.3.5-1.pvops.qubes.x86_64/kernel
# md5sum ./sound/usb/snd-usbmidi-lib.ko
9d2d3fedd4a357252e367fa8109c16ed  ./sound/usb/snd-usbmidi-lib.ko
# ls -l ./sound/usb/snd-usbmidi-lib.ko
-rwxr--r-- 1 root root 38248 May 20 14:14 ./sound/usb/snd-usbmidi-lib.ko

And block backend parameters:
# xenstore-ls /local/domain/0/backend/vbd/3/51760
frontend =3D "/local/domain/3/device/vbd/51760"
params =3D "/var/lib/qubes/vm-kernels/3.3.5/modules.img"
scripted =3D "1"
frontend-id =3D "3"
online =3D "1"
removable =3D "0"
bootable =3D "1"
state =3D "4"
dev =3D "xvdd"
type =3D "file"
mode =3D "r"
node =3D "/dev/loop4"
physical-device =3D "7:4"
hotplug-status =3D "connected"
feature-flush-cache =3D "1"
discard-granularity =3D "4096"
discard-alignment =3D "0"
discard-secure =3D "0"
feature-discard =3D "1"
feature-barrier =3D "1"
sectors =3D "409600"
info =3D "4"
sector-size =3D "512"

BTW 3.2.7 advertise feature-flush-cache=3D0 and feature-barrier=3D0 on th=
is one
device (RO, loop backed). Don't know why, but seems irrelevant to this is=
sue.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigFFD4C680D67EA0F80C21907E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP0fnoAAoJENuP0xzK19csX3QH/0rWMObmYSQmjXQn+LdcuAyZ
FqVqDlv/2229qUMBeVfmLst6jFX2WhKuAH+WEiJSW6ZTxfpZ4uha8s4k5Nh3ARqJ
rOM/lTxx7MtY19mwt0cZvdfip6UI1pV0kVH3m0vxsrL5kV30UVaCY6XlT55T1sO+
YSvkvq1MFG1EInbW2QFhQ1+rxfVRL42+tsXo7iBrvPrzwMVcfKy6BiAlDDg/lkwQ
TFsKTlbesp/EATVmZRXilLh1mxTL1oGZ5pESrR0y3uJrVE+bqA1uqBgQ2UJYpTJE
HSBFHEReFTrFh1y/00hR0BCQPXTFPQ/s+jsfg1GH3IwGxN+oxiyMRMpFW2uAVZQ=
=Gtdx
-----END PGP SIGNATURE-----

--------------enigFFD4C680D67EA0F80C21907E--


--===============3773219682007729060==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3773219682007729060==--


From xen-devel-bounces@lists.xen.org Fri Jun 08 13:14:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:14: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 1Scz0U-0002Qq-R4; Fri, 08 Jun 2012 13:13:38 +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 1Scz0S-0002Qi-SA
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:13:37 +0000
Received: from [85.158.138.51:14230] by server-7.bemta-3.messagelabs.com id
	CB/13-01983-F7AF1DF4; Fri, 08 Jun 2012 13:13:35 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339161215!25125364!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20425 invoked from network); 8 Jun 2012 13:13:35 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 13:13:35 -0000
Received: by lahg1 with SMTP id g1so1532622lah.30
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 06:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=9D82kOlYlwlRWcAymig83ezMs+u8Kc1z/qpMuBt1qHM=;
	b=xSV3itVvyFrtq8bfBQ1K/s14byjRiImXM7eThmMyQd3AmIU5QS/6kYNwfvcHd/45In
	2AyztMhemO5IC4vqpwFBNiLegd1z8bFf1s1YcghYPfliFuD3Ua2Z5jo4+dcqnuIsYAmB
	h8MgoCGibIh55fAjIOxg3wocI9cNOJGy25UqdcLmtyTXpWeMlGC7yVJRC46ZYPzz+4M9
	Xnq0gHvIdANhpyrwR3YZFqO3wvCUx4IZoLNrMBRviG/BgQzm41L/oNsoNz7j3P7AT9XY
	9YvwSull7wgrMsMf4exj/J/wQiWoXuhCiRjNUmAVbMc5cVSuMTb3s0sTDpHF2fQk7a9C
	6R+A==
MIME-Version: 1.0
Received: by 10.152.102.234 with SMTP id fr10mr8482769lab.32.1339161214601;
	Fri, 08 Jun 2012 06:13:34 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Fri, 8 Jun 2012 06:13:34 -0700 (PDT)
In-Reply-To: <CAOvdn6UV1b89+wp4cfyj7ofU6T0=sdhNEoMZinPW=-AZWBOmSA@mail.gmail.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
	<CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
	<20120607180156.GX9472@phenom.dumpdata.com>
	<CAOvdn6UV1b89+wp4cfyj7ofU6T0=sdhNEoMZinPW=-AZWBOmSA@mail.gmail.com>
Date: Fri, 8 Jun 2012 09:13:34 -0400
X-Google-Sender-Auth: x2qQtogGon5tj5ZToeofwShnXm4
Message-ID: <CAOvdn6VNhi0O9fo7KUOV4Lrux=KBJ75hJOhhtozMPsp0FGB=Hg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 4:07 PM, Ben Guthro <ben@guthro.net> wrote:

<snip>

> +#ifndef CONFIG_XEN
> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * Wait for the other CPUs to be notified and be waiting f=
or us:
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0atomic_rea=
d(&slaves_in_kgdb)) !=3D online_cpus)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpu_relax();
> +#endif
>
> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * At this point the primary processor is completely


The cpu roundup seems to not be working as expected here.
While I get into the kgdb exception code on the master cpu - none of
the slave cpus ever get into the code that is counting them up.

Ignoring this CPU roundup is useful to get into the kdb code, but
probably not correct.

Does you have any thoughts as to why I might not be getting into this
code under Xen?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:14:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:14: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 1Scz0U-0002Qq-R4; Fri, 08 Jun 2012 13:13:38 +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 1Scz0S-0002Qi-SA
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:13:37 +0000
Received: from [85.158.138.51:14230] by server-7.bemta-3.messagelabs.com id
	CB/13-01983-F7AF1DF4; Fri, 08 Jun 2012 13:13:35 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339161215!25125364!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20425 invoked from network); 8 Jun 2012 13:13:35 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 13:13:35 -0000
Received: by lahg1 with SMTP id g1so1532622lah.30
	for <xen-devel@lists.xensource.com>;
	Fri, 08 Jun 2012 06:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=9D82kOlYlwlRWcAymig83ezMs+u8Kc1z/qpMuBt1qHM=;
	b=xSV3itVvyFrtq8bfBQ1K/s14byjRiImXM7eThmMyQd3AmIU5QS/6kYNwfvcHd/45In
	2AyztMhemO5IC4vqpwFBNiLegd1z8bFf1s1YcghYPfliFuD3Ua2Z5jo4+dcqnuIsYAmB
	h8MgoCGibIh55fAjIOxg3wocI9cNOJGy25UqdcLmtyTXpWeMlGC7yVJRC46ZYPzz+4M9
	Xnq0gHvIdANhpyrwR3YZFqO3wvCUx4IZoLNrMBRviG/BgQzm41L/oNsoNz7j3P7AT9XY
	9YvwSull7wgrMsMf4exj/J/wQiWoXuhCiRjNUmAVbMc5cVSuMTb3s0sTDpHF2fQk7a9C
	6R+A==
MIME-Version: 1.0
Received: by 10.152.102.234 with SMTP id fr10mr8482769lab.32.1339161214601;
	Fri, 08 Jun 2012 06:13:34 -0700 (PDT)
Received: by 10.112.104.73 with HTTP; Fri, 8 Jun 2012 06:13:34 -0700 (PDT)
In-Reply-To: <CAOvdn6UV1b89+wp4cfyj7ofU6T0=sdhNEoMZinPW=-AZWBOmSA@mail.gmail.com>
References: <CAOvdn6VWdOy1nNM+x3ogCCFXy8FExZjTJaV-s6SR7kbGu+REOA@mail.gmail.com>
	<20120607164034.GQ9472@phenom.dumpdata.com>
	<CAOvdn6WJ+Ub+LbhHKKQJi3AzsbCqX6-ksWhoxnZS5_OH=hkghQ@mail.gmail.com>
	<20120607174815.GU9472@phenom.dumpdata.com>
	<CAOvdn6VtmWyMo4SEAWT+ipJTHBTwPm+DZ1TXZT4q3UobFv=2DA@mail.gmail.com>
	<20120607180156.GX9472@phenom.dumpdata.com>
	<CAOvdn6UV1b89+wp4cfyj7ofU6T0=sdhNEoMZinPW=-AZWBOmSA@mail.gmail.com>
Date: Fri, 8 Jun 2012 09:13:34 -0400
X-Google-Sender-Auth: x2qQtogGon5tj5ZToeofwShnXm4
Message-ID: <CAOvdn6VNhi0O9fo7KUOV4Lrux=KBJ75hJOhhtozMPsp0FGB=Hg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/hvc: Fix polling mode to work with
	kdb/kgdb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 7, 2012 at 4:07 PM, Ben Guthro <ben@guthro.net> wrote:

<snip>

> +#ifndef CONFIG_XEN
> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * Wait for the other CPUs to be notified and be waiting f=
or us:
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0atomic_rea=
d(&slaves_in_kgdb)) !=3D online_cpus)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cpu_relax();
> +#endif
>
> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * At this point the primary processor is completely


The cpu roundup seems to not be working as expected here.
While I get into the kgdb exception code on the master cpu - none of
the slave cpus ever get into the code that is counting them up.

Ignoring this CPU roundup is useful to get into the kdb code, but
probably not correct.

Does you have any thoughts as to why I might not be getting into this
code under Xen?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:28:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:28: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 1SczEJ-0002hP-8P; Fri, 08 Jun 2012 13:27:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SczEH-0002hK-KN
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:27:53 +0000
Received: from [85.158.139.83:21168] by server-10.bemta-5.messagelabs.com id
	82/9F-23803-8DDF1DF4; Fri, 08 Jun 2012 13:27:52 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339162070!31134037!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21620 invoked from network); 8 Jun 2012 13:27:51 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 13:27:51 -0000
Received: from mail145-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:26:59 +0000
Received: from mail145-va3 (localhost [127.0.0.1])	by
	mail145-va3-R.bigfish.com (Postfix) with ESMTP id A654D48046D;
	Fri,  8 Jun 2012 13:26:59 +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: VPS-1(zzc89bhc85dh4015Izz1202hzzz2dh668h839hd25he5bhf0ah34h)
Received: from mail145-va3 (localhost.localdomain [127.0.0.1]) by mail145-va3
	(MessageSwitch) id 1339162017367697_30058;
	Fri,  8 Jun 2012 13:26:57 +0000 (UTC)
Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.237])	by
	mail145-va3.bigfish.com (Postfix) with ESMTP id 4CCC32C007C;
	Fri,  8 Jun 2012 13:26:57 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:26:55 +0000
X-WSS-ID: 0M5AW27-02-3E5-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 2133BC81A8;	Fri,  8 Jun 2012 08:27:42 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 08:28:03 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 08:27:43 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	09:27:42 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 723A049C20C; Fri,  8 Jun 2012
	14:27:41 +0100 (BST)
Message-ID: <4FD1FDE2.5010907@amd.com>
Date: Fri, 8 Jun 2012 15:28:02 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------000709040604060600000200"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0 disabled
	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

--------------000709040604060600000200
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Jan,
I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability=20
for some reasons and iommu cannot generate any interrupts in this case.
Attached patch re-enables it in device assignment.

Thanks,
Wei

--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis M=FCnchen Registergericht M=FCnchen,
HRB Nr. 43632 WEEE Registrierungsnummer 129 19551
Gesch=E4ftsf=FChrer:
Alberto Bozzo

--------------000709040604060600000200
Content-Type: text/x-patch; name="iommu-msi.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommu-msi.patch"
Content-Description: iommu-msi.patch

# HG changeset patch
# Parent f6bfaf9daa508c31b2bca0e461202db2759426fc
# User Wei Wang <wei.wang2@amd.com>
Re-enable iommu msi capability block if it is disabled by dom0

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f6bfaf9daa50 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Jun 06 16:37:05 2012 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Jun 08 15:13:11 2012 +0200
@@ -81,6 +81,30 @@ static void disable_translation(u32 *dte
     dte[0] = entry;
 }
 
+static void iommu_msi_check_enable(struct amd_iommu *iommu)
+{
+    unsigned long flags;
+    uint16_t control;
+    uint8_t bus = PCI_BUS(iommu->bdf);
+    uint8_t dev = PCI_SLOT(iommu->bdf);
+    uint8_t func = PCI_FUNC(iommu->bdf);
+
+    ASSERT( iommu->msi_cap );
+    
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    control = pci_conf_read16(iommu->seg, bus, dev, func,
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    if ( !(control & IOMMU_CONTROL_ENABLED) )
+    {    
+        control |= IOMMU_CONTROL_ENABLED;
+        pci_conf_write16(iommu->seg, bus, dev, func,
+                         iommu->msi_cap + PCI_MSI_FLAGS, control);
+    }
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
 static void amd_iommu_setup_domain_device(
     struct domain *domain, struct amd_iommu *iommu, int bdf)
 {
@@ -101,6 +125,12 @@ static void amd_iommu_setup_domain_devic
     if ( ats_enabled )
         dte_i = 1;
 
+    /* 
+     * In some cases, dom0 disables iommu msi capability, 
+     * re-enable it here.
+     */
+    iommu_msi_check_enable(iommu); 
+
     /* get device-table entry */
     req_id = get_dma_requestor_id(iommu->seg, bdf);
     dte = iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE);

--------------000709040604060600000200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000709040604060600000200--


From xen-devel-bounces@lists.xen.org Fri Jun 08 13:28:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:28: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 1SczEJ-0002hP-8P; Fri, 08 Jun 2012 13:27:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SczEH-0002hK-KN
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:27:53 +0000
Received: from [85.158.139.83:21168] by server-10.bemta-5.messagelabs.com id
	82/9F-23803-8DDF1DF4; Fri, 08 Jun 2012 13:27:52 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339162070!31134037!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21620 invoked from network); 8 Jun 2012 13:27:51 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 13:27:51 -0000
Received: from mail145-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:26:59 +0000
Received: from mail145-va3 (localhost [127.0.0.1])	by
	mail145-va3-R.bigfish.com (Postfix) with ESMTP id A654D48046D;
	Fri,  8 Jun 2012 13:26:59 +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: VPS-1(zzc89bhc85dh4015Izz1202hzzz2dh668h839hd25he5bhf0ah34h)
Received: from mail145-va3 (localhost.localdomain [127.0.0.1]) by mail145-va3
	(MessageSwitch) id 1339162017367697_30058;
	Fri,  8 Jun 2012 13:26:57 +0000 (UTC)
Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.237])	by
	mail145-va3.bigfish.com (Postfix) with ESMTP id 4CCC32C007C;
	Fri,  8 Jun 2012 13:26:57 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:26:55 +0000
X-WSS-ID: 0M5AW27-02-3E5-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 2133BC81A8;	Fri,  8 Jun 2012 08:27:42 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 08:28:03 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 08:27:43 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	09:27:42 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 723A049C20C; Fri,  8 Jun 2012
	14:27:41 +0100 (BST)
Message-ID: <4FD1FDE2.5010907@amd.com>
Date: Fri, 8 Jun 2012 15:28:02 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------000709040604060600000200"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0 disabled
	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

--------------000709040604060600000200
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Jan,
I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability=20
for some reasons and iommu cannot generate any interrupts in this case.
Attached patch re-enables it in device assignment.

Thanks,
Wei

--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis M=FCnchen Registergericht M=FCnchen,
HRB Nr. 43632 WEEE Registrierungsnummer 129 19551
Gesch=E4ftsf=FChrer:
Alberto Bozzo

--------------000709040604060600000200
Content-Type: text/x-patch; name="iommu-msi.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommu-msi.patch"
Content-Description: iommu-msi.patch

# HG changeset patch
# Parent f6bfaf9daa508c31b2bca0e461202db2759426fc
# User Wei Wang <wei.wang2@amd.com>
Re-enable iommu msi capability block if it is disabled by dom0

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f6bfaf9daa50 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Jun 06 16:37:05 2012 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Jun 08 15:13:11 2012 +0200
@@ -81,6 +81,30 @@ static void disable_translation(u32 *dte
     dte[0] = entry;
 }
 
+static void iommu_msi_check_enable(struct amd_iommu *iommu)
+{
+    unsigned long flags;
+    uint16_t control;
+    uint8_t bus = PCI_BUS(iommu->bdf);
+    uint8_t dev = PCI_SLOT(iommu->bdf);
+    uint8_t func = PCI_FUNC(iommu->bdf);
+
+    ASSERT( iommu->msi_cap );
+    
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    control = pci_conf_read16(iommu->seg, bus, dev, func,
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    if ( !(control & IOMMU_CONTROL_ENABLED) )
+    {    
+        control |= IOMMU_CONTROL_ENABLED;
+        pci_conf_write16(iommu->seg, bus, dev, func,
+                         iommu->msi_cap + PCI_MSI_FLAGS, control);
+    }
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
 static void amd_iommu_setup_domain_device(
     struct domain *domain, struct amd_iommu *iommu, int bdf)
 {
@@ -101,6 +125,12 @@ static void amd_iommu_setup_domain_devic
     if ( ats_enabled )
         dte_i = 1;
 
+    /* 
+     * In some cases, dom0 disables iommu msi capability, 
+     * re-enable it here.
+     */
+    iommu_msi_check_enable(iommu); 
+
     /* get device-table entry */
     req_id = get_dma_requestor_id(iommu->seg, bdf);
     dte = iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE);

--------------000709040604060600000200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000709040604060600000200--


From xen-devel-bounces@lists.xen.org Fri Jun 08 13:37:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:37: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 1SczND-0002ya-RH; Fri, 08 Jun 2012 13:37:07 +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 1SczNB-0002yV-VB
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:37:06 +0000
Received: from [193.109.254.147:58141] by server-3.bemta-14.messagelabs.com id
	19/36-05653-10002DF4; Fri, 08 Jun 2012 13:37:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339162623!8800459!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21660 invoked from network); 8 Jun 2012 13:37:04 -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;
	8 Jun 2012 13:37:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330923600"; d="scan'208";a="27353760"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 09:31:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 09:31:53 -0400
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 1SczI8-0006bW-Nh;
	Fri, 08 Jun 2012 14:31:52 +0100
Message-ID: <4FD1FEC8.5000708@citrix.com>
Date: Fri, 8 Jun 2012 14:31:52 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Wang <wei.wang2@amd.com>
References: <4FD1FDE2.5010907@amd.com>
In-Reply-To: <4FD1FDE2.5010907@amd.com>
X-Enigmail-Version: 1.4.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/06/12 14:28, Wei Wang wrote:
> Hi Jan,
> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability =

> for some reasons and iommu cannot generate any interrupts in this case.
> Attached patch re-enables it in device assignment.

Under which circumstances should dom0 able to play with the IOMMUs ? =

Surely the fact that dom0 can play with the IOMMUs is a bug in itself.

>
> Thanks,
> Wei
>
> --
> Advanced Micro Devices GmbH
> Sitz: Dornach, Gemeinde Aschheim,
> Landkreis M=FCnchen Registergericht M=FCnchen,
> HRB Nr. 43632 WEEE Registrierungsnummer 129 19551
> Gesch=E4ftsf=FChrer:
> Alberto Bozzo

-- =

Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:37:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:37: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 1SczND-0002ya-RH; Fri, 08 Jun 2012 13:37:07 +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 1SczNB-0002yV-VB
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:37:06 +0000
Received: from [193.109.254.147:58141] by server-3.bemta-14.messagelabs.com id
	19/36-05653-10002DF4; Fri, 08 Jun 2012 13:37:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339162623!8800459!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21660 invoked from network); 8 Jun 2012 13:37:04 -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;
	8 Jun 2012 13:37:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330923600"; d="scan'208";a="27353760"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 09:31:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 09:31:53 -0400
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 1SczI8-0006bW-Nh;
	Fri, 08 Jun 2012 14:31:52 +0100
Message-ID: <4FD1FEC8.5000708@citrix.com>
Date: Fri, 8 Jun 2012 14:31:52 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Wang <wei.wang2@amd.com>
References: <4FD1FDE2.5010907@amd.com>
In-Reply-To: <4FD1FDE2.5010907@amd.com>
X-Enigmail-Version: 1.4.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/06/12 14:28, Wei Wang wrote:
> Hi Jan,
> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability =

> for some reasons and iommu cannot generate any interrupts in this case.
> Attached patch re-enables it in device assignment.

Under which circumstances should dom0 able to play with the IOMMUs ? =

Surely the fact that dom0 can play with the IOMMUs is a bug in itself.

>
> Thanks,
> Wei
>
> --
> Advanced Micro Devices GmbH
> Sitz: Dornach, Gemeinde Aschheim,
> Landkreis M=FCnchen Registergericht M=FCnchen,
> HRB Nr. 43632 WEEE Registrierungsnummer 129 19551
> Gesch=E4ftsf=FChrer:
> Alberto Bozzo

-- =

Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:41:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13: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 1SczQs-0003CD-Tu; Fri, 08 Jun 2012 13:40:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SczQr-0003C4-4a
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:40:53 +0000
Received: from [85.158.139.83:49963] by server-7.bemta-5.messagelabs.com id
	28/F5-19648-4E002DF4; Fri, 08 Jun 2012 13:40:52 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339162848!32684710!1
X-Originating-IP: [213.199.154.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4472 invoked from network); 8 Jun 2012 13:40:49 -0000
Received: from db3ehsobe004.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.142)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 13:40:49 -0000
Received: from mail86-db3-R.bigfish.com (10.3.81.241) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:39:57 +0000
Received: from mail86-db3 (localhost [127.0.0.1])	by mail86-db3-R.bigfish.com
	(Postfix) with ESMTP id 92361100321;
	Fri,  8 Jun 2012 13:39:57 +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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371Ic89bh1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah)
Received: from mail86-db3 (localhost.localdomain [127.0.0.1]) by mail86-db3
	(MessageSwitch) id 1339162795614038_25521;
	Fri,  8 Jun 2012 13:39:55 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.241])	by
	mail86-db3.bigfish.com (Postfix) with ESMTP id 937C82C0043;
	Fri,  8 Jun 2012 13:39:55 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:39:54 +0000
X-WSS-ID: 0M5AWNT-02-47I-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 2212FC81A6;	Fri,  8 Jun 2012 08:40:40 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 08:41:01 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 08:40:41 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	09:40:40 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 43D5549C20C; Fri,  8 Jun 2012
	14:40:39 +0100 (BST)
Message-ID: <4FD200EC.6050005@amd.com>
Date: Fri, 8 Jun 2012 15:41:00 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <4FD1FDE2.5010907@amd.com> <4FD1FEC8.5000708@citrix.com>
In-Reply-To: <4FD1FEC8.5000708@citrix.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled 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: 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 06/08/2012 03:31 PM, Andrew Cooper wrote:
> On 08/06/12 14:28, Wei Wang wrote:
>> Hi Jan,
>> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability
>> for some reasons and iommu cannot generate any interrupts in this case.
>> Attached patch re-enables it in device assignment.
>
> Under which circumstances should dom0 able to play with the IOMMUs ?
> Surely the fact that dom0 can play with the IOMMUs is a bug in itself.

It looks like some generic msi/pci codes disable it, not the Linux iommu =

driver itself, which is only loaded on bare metal. AMD IOMMU expose =

interrupt capability as a normal msi block. So the general pci/msi layer =

of dom0 might touch it...

Thanks,
Wei


>>
>> Thanks,
>> Wei
>>
>> --
>> Advanced Micro Devices GmbH
>> Sitz: Dornach, Gemeinde Aschheim,
>> Landkreis M=FCnchen Registergericht M=FCnchen,
>> HRB Nr. 43632 WEEE Registrierungsnummer 129 19551
>> Gesch=E4ftsf=FChrer:
>> Alberto Bozzo
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:41:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13: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 1SczQs-0003CD-Tu; Fri, 08 Jun 2012 13:40:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SczQr-0003C4-4a
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:40:53 +0000
Received: from [85.158.139.83:49963] by server-7.bemta-5.messagelabs.com id
	28/F5-19648-4E002DF4; Fri, 08 Jun 2012 13:40:52 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339162848!32684710!1
X-Originating-IP: [213.199.154.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4472 invoked from network); 8 Jun 2012 13:40:49 -0000
Received: from db3ehsobe004.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.142)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 13:40:49 -0000
Received: from mail86-db3-R.bigfish.com (10.3.81.241) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:39:57 +0000
Received: from mail86-db3 (localhost [127.0.0.1])	by mail86-db3-R.bigfish.com
	(Postfix) with ESMTP id 92361100321;
	Fri,  8 Jun 2012 13:39:57 +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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371Ic89bh1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah)
Received: from mail86-db3 (localhost.localdomain [127.0.0.1]) by mail86-db3
	(MessageSwitch) id 1339162795614038_25521;
	Fri,  8 Jun 2012 13:39:55 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.241])	by
	mail86-db3.bigfish.com (Postfix) with ESMTP id 937C82C0043;
	Fri,  8 Jun 2012 13:39:55 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 13:39:54 +0000
X-WSS-ID: 0M5AWNT-02-47I-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 2212FC81A6;	Fri,  8 Jun 2012 08:40:40 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 08:41:01 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 08:40:41 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	09:40:40 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 43D5549C20C; Fri,  8 Jun 2012
	14:40:39 +0100 (BST)
Message-ID: <4FD200EC.6050005@amd.com>
Date: Fri, 8 Jun 2012 15:41:00 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <4FD1FDE2.5010907@amd.com> <4FD1FEC8.5000708@citrix.com>
In-Reply-To: <4FD1FEC8.5000708@citrix.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled 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: 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 06/08/2012 03:31 PM, Andrew Cooper wrote:
> On 08/06/12 14:28, Wei Wang wrote:
>> Hi Jan,
>> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability
>> for some reasons and iommu cannot generate any interrupts in this case.
>> Attached patch re-enables it in device assignment.
>
> Under which circumstances should dom0 able to play with the IOMMUs ?
> Surely the fact that dom0 can play with the IOMMUs is a bug in itself.

It looks like some generic msi/pci codes disable it, not the Linux iommu =

driver itself, which is only loaded on bare metal. AMD IOMMU expose =

interrupt capability as a normal msi block. So the general pci/msi layer =

of dom0 might touch it...

Thanks,
Wei


>>
>> Thanks,
>> Wei
>>
>> --
>> Advanced Micro Devices GmbH
>> Sitz: Dornach, Gemeinde Aschheim,
>> Landkreis M=FCnchen Registergericht M=FCnchen,
>> HRB Nr. 43632 WEEE Registrierungsnummer 129 19551
>> Gesch=E4ftsf=FChrer:
>> Alberto Bozzo
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13: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 1SczX1-0003QW-OJ; Fri, 08 Jun 2012 13: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 1SczX0-0003QR-Fj
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:47:14 +0000
Received: from [85.158.143.99:18152] by server-1.bemta-4.messagelabs.com id
	1B/BF-10042-16202DF4; Fri, 08 Jun 2012 13:47:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339163232!25386058!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12663 invoked from network); 8 Jun 2012 13:47:12 -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; 8 Jun 2012 13:47:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 14:47:41 +0100
Message-Id: <4FD21EA80200007800088C95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 14:47:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD1FDE2.5010907@amd.com>
In-Reply-To: <4FD1FDE2.5010907@amd.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] amd iommu: re-enable iommu msi if dom0
	disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.06.12 at 15:28, Wei Wang <wei.wang2@amd.com> wrote:
> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability 
> for some reasons and iommu cannot generate any interrupts in this case.

That shouldn't happen in the first place, and hence should be fixed
in the kernel.

> Attached patch re-enables it in device assignment.

I'm not really keen on taking this - it's silently working around a
problem, and doesn't appear to cover the case where Dom0
would have its I/O got through the IOMMU as well.

If anything, I'd be much more in favor of hiding the entire config
space of the IOMMU device from Dom0 (or at least making it
read-only), which admittedly might be a little tricky. So first of
all let's understand whether this can't reasonably be fixed in
Linux.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13: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 1SczX1-0003QW-OJ; Fri, 08 Jun 2012 13: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 1SczX0-0003QR-Fj
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:47:14 +0000
Received: from [85.158.143.99:18152] by server-1.bemta-4.messagelabs.com id
	1B/BF-10042-16202DF4; Fri, 08 Jun 2012 13:47:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339163232!25386058!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12663 invoked from network); 8 Jun 2012 13:47:12 -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; 8 Jun 2012 13:47:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 14:47:41 +0100
Message-Id: <4FD21EA80200007800088C95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 14:47:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD1FDE2.5010907@amd.com>
In-Reply-To: <4FD1FDE2.5010907@amd.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] amd iommu: re-enable iommu msi if dom0
	disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.06.12 at 15:28, Wei Wang <wei.wang2@amd.com> wrote:
> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability 
> for some reasons and iommu cannot generate any interrupts in this case.

That shouldn't happen in the first place, and hence should be fixed
in the kernel.

> Attached patch re-enables it in device assignment.

I'm not really keen on taking this - it's silently working around a
problem, and doesn't appear to cover the case where Dom0
would have its I/O got through the IOMMU as well.

If anything, I'd be much more in favor of hiding the entire config
space of the IOMMU device from Dom0 (or at least making it
read-only), which admittedly might be a little tricky. So first of
all let's understand whether this can't reasonably be fixed in
Linux.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:48:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:48: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 1SczYH-0003Tt-6e; Fri, 08 Jun 2012 13:48:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1SczYG-0003Tk-4R
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:48:32 +0000
Received: from [85.158.143.35:18339] by server-3.bemta-4.messagelabs.com id
	0B/7A-29237-FA202DF4; Fri, 08 Jun 2012 13:48:31 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339163309!16256156!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16614 invoked from network); 8 Jun 2012 13:48:29 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-3.tower-21.messagelabs.com with SMTP;
	8 Jun 2012 13:48:29 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id B0305161889
	for <xen-devel@lists.xensource.com>;
	Fri,  8 Jun 2012 14:48:28 +0100 (BST)
X-Virus-Scanned: amavisd-new at overnetdata.com
Received: from zimbra.overnetdata.com ([127.0.0.1])
	by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Sb0udzhrHlGR for <xen-devel@lists.xensource.com>;
	Fri,  8 Jun 2012 14:48:18 +0100 (BST)
Received: from [192.168.1.52] (unknown [192.168.1.52])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id A14331617C0
	for <xen-devel@lists.xensource.com>;
	Fri,  8 Jun 2012 14:48:18 +0100 (BST)
Message-ID: <4FD202A0.2080104@overnetdata.com>
Date: Fri, 08 Jun 2012 14:48:16 +0100
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.1
Content-Type: multipart/mixed; boundary="------------000006000403030200020905"
Subject: [Xen-devel] Bug - DomUs failing to restart - issue with maxmem_mb
	set to 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 multi-part message in MIME format.
--------------000006000403030200020905
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I have a process that monitors DomU's, and when they shutdown it spots
it and restarts the DomU.

If I restart them immediately very frequently I get an internal error,
and the DomU fails to start. If I add a 2 second sleep before restarting
the DomU, it restarts nicely. If I restart the DomU after it has failed
to start once, it will restart nicely. The xen config for all the DomUs
is identical.

I notice that in xend.log, when a DomU fails to restart the
XendDomainInfo.recreate parameters online_vcpus, maxmem_mb and mem_kb
are all set to 0. When the DomU starts correctly these parameters have
sensible values.

I'm running Xen 4.1.2 with kernel 3.3.2 all in 32 bit mode.

I'm attaching the output from xl create and the sections from xend.log.

Anthony.

--------------000006000403030200020905
Content-Type: text/plain; charset=windows-1252;
 name="xl-create.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-create.log"

xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1: Internal error
xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1: Internal error
xc: error: panic: xc_dom_boot.c:159: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory
libxl: error: libxl_dom.c:204:libxl__build_pv xc_dom_boot_mem_init failed: No such process
cannot (re-)build domain: -3
libxl: error: libxl.c:711:libxl_domain_destroy non-existant domain 29

--------------000006000403030200020905
Content-Type: text/plain; charset=windows-1252;
 name="xend.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xend.log"

[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 0, 'cpu_time': 0L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 0, 'domid': 29, 'paused': 1, 'crashed': 0, 'running': 0, 'maxmem_kb': 0L, 'shutdown': 0, 'mem_kb': 0L, 'handle': [241, 186, 174, 38, 56, 252, 73, 149, 174, 115, 115, 95, 251, 69, 33, 189], 'blocked': 0, 'cpupool': 0})                                       
[2012-06-08 14:20:38 676] ERROR (XendDomain:447) Unable to recreate domain                                     
Traceback (most recent call last):                                                                             
  File "usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line 445, in _refreshTxn                      
    new_dom = XendDomainInfo.recreate(dom, False)                                                              
  File "usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 155, in recreate
    xeninfo = XendConfig.XendConfig(dominfo = info)
  File "usr/lib/python2.4/site-packages/xen/xend/XendConfig.py", line 360, in __init__
    self._dominfo_to_xapi(dominfo, update_mem = True)
  File "usr/lib/python2.4/site-packages/xen/xend/XendConfig.py", line 574, in _dominfo_to_xapi
    self._memory_sanity_check()
  File "usr/lib/python2.4/site-packages/xen/xend/XendConfig.py", line 455, in _memory_sanity_check
    raise XendConfigError("memory_dynamic_max must be greater " \
XendConfigError: Invalid Configuration: memory_dynamic_max must be greater than zero
[2012-06-08 14:20:38 676] ERROR (XendDomainInfo:3085) XendDomainInfo.destroy: domain destruction failed.
Traceback (most recent call last):
  File "usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 3078, in destroy
    xc.domain_pause(self.domid)
Error: (3, 'No such process')
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:2401) Destroying device model
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:2408) Releasing devices
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:2414) Removing console/0
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = console, device = console/0
[2012-06-08 14:20:54 676] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 0, 'cpu_time': 0L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 1, 'domid': 30, 'paused': 1, 'crashed': 0, 'running': 0, 'maxmem_kb': 132096L, 'shutdown': 0, 'mem_kb': 131072L, 'handle': [237, 80, 222, 13, 176, 6, 68, 29, 142, 126, 214, 197, 194, 221, 142, 25], 'blocked': 0, 'cpupool': 0})
[2012-06-08 14:20:54 676] INFO (XendDomainInfo:168) Recreating domain 30, UUID ed50de0d-b006-441d-8e7e-d6c5c2dd8e19. at /local/domain/30
[2012-06-08 14:21:01 676] DEBUG (XendDomain:476) Adding Domain: 30
[2012-06-08 14:21:02 676] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch

--------------000006000403030200020905
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000006000403030200020905--


From xen-devel-bounces@lists.xen.org Fri Jun 08 13:48:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:48: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 1SczYH-0003Tt-6e; Fri, 08 Jun 2012 13:48:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1SczYG-0003Tk-4R
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 13:48:32 +0000
Received: from [85.158.143.35:18339] by server-3.bemta-4.messagelabs.com id
	0B/7A-29237-FA202DF4; Fri, 08 Jun 2012 13:48:31 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339163309!16256156!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16614 invoked from network); 8 Jun 2012 13:48:29 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-3.tower-21.messagelabs.com with SMTP;
	8 Jun 2012 13:48:29 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id B0305161889
	for <xen-devel@lists.xensource.com>;
	Fri,  8 Jun 2012 14:48:28 +0100 (BST)
X-Virus-Scanned: amavisd-new at overnetdata.com
Received: from zimbra.overnetdata.com ([127.0.0.1])
	by localhost (zimbra.overnetdata.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Sb0udzhrHlGR for <xen-devel@lists.xensource.com>;
	Fri,  8 Jun 2012 14:48:18 +0100 (BST)
Received: from [192.168.1.52] (unknown [192.168.1.52])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id A14331617C0
	for <xen-devel@lists.xensource.com>;
	Fri,  8 Jun 2012 14:48:18 +0100 (BST)
Message-ID: <4FD202A0.2080104@overnetdata.com>
Date: Fri, 08 Jun 2012 14:48:16 +0100
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.1
Content-Type: multipart/mixed; boundary="------------000006000403030200020905"
Subject: [Xen-devel] Bug - DomUs failing to restart - issue with maxmem_mb
	set to 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 multi-part message in MIME format.
--------------000006000403030200020905
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I have a process that monitors DomU's, and when they shutdown it spots
it and restarts the DomU.

If I restart them immediately very frequently I get an internal error,
and the DomU fails to start. If I add a 2 second sleep before restarting
the DomU, it restarts nicely. If I restart the DomU after it has failed
to start once, it will restart nicely. The xen config for all the DomUs
is identical.

I notice that in xend.log, when a DomU fails to restart the
XendDomainInfo.recreate parameters online_vcpus, maxmem_mb and mem_kb
are all set to 0. When the DomU starts correctly these parameters have
sensible values.

I'm running Xen 4.1.2 with kernel 3.3.2 all in 32 bit mode.

I'm attaching the output from xl create and the sections from xend.log.

Anthony.

--------------000006000403030200020905
Content-Type: text/plain; charset=windows-1252;
 name="xl-create.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-create.log"

xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1: Internal error
xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1: Internal error
xc: error: panic: xc_dom_boot.c:159: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory
libxl: error: libxl_dom.c:204:libxl__build_pv xc_dom_boot_mem_init failed: No such process
cannot (re-)build domain: -3
libxl: error: libxl.c:711:libxl_domain_destroy non-existant domain 29

--------------000006000403030200020905
Content-Type: text/plain; charset=windows-1252;
 name="xend.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xend.log"

[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 0, 'cpu_time': 0L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 0, 'domid': 29, 'paused': 1, 'crashed': 0, 'running': 0, 'maxmem_kb': 0L, 'shutdown': 0, 'mem_kb': 0L, 'handle': [241, 186, 174, 38, 56, 252, 73, 149, 174, 115, 115, 95, 251, 69, 33, 189], 'blocked': 0, 'cpupool': 0})                                       
[2012-06-08 14:20:38 676] ERROR (XendDomain:447) Unable to recreate domain                                     
Traceback (most recent call last):                                                                             
  File "usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line 445, in _refreshTxn                      
    new_dom = XendDomainInfo.recreate(dom, False)                                                              
  File "usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 155, in recreate
    xeninfo = XendConfig.XendConfig(dominfo = info)
  File "usr/lib/python2.4/site-packages/xen/xend/XendConfig.py", line 360, in __init__
    self._dominfo_to_xapi(dominfo, update_mem = True)
  File "usr/lib/python2.4/site-packages/xen/xend/XendConfig.py", line 574, in _dominfo_to_xapi
    self._memory_sanity_check()
  File "usr/lib/python2.4/site-packages/xen/xend/XendConfig.py", line 455, in _memory_sanity_check
    raise XendConfigError("memory_dynamic_max must be greater " \
XendConfigError: Invalid Configuration: memory_dynamic_max must be greater than zero
[2012-06-08 14:20:38 676] ERROR (XendDomainInfo:3085) XendDomainInfo.destroy: domain destruction failed.
Traceback (most recent call last):
  File "usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 3078, in destroy
    xc.domain_pause(self.domid)
Error: (3, 'No such process')
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:2401) Destroying device model
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:2408) Releasing devices
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:2414) Removing console/0
[2012-06-08 14:20:38 676] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = console, device = console/0
[2012-06-08 14:20:54 676] DEBUG (XendDomainInfo:151) XendDomainInfo.recreate({'max_vcpu_id': 0, 'cpu_time': 0L, 'ssidref': 0, 'hvm': 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 1, 'domid': 30, 'paused': 1, 'crashed': 0, 'running': 0, 'maxmem_kb': 132096L, 'shutdown': 0, 'mem_kb': 131072L, 'handle': [237, 80, 222, 13, 176, 6, 68, 29, 142, 126, 214, 197, 194, 221, 142, 25], 'blocked': 0, 'cpupool': 0})
[2012-06-08 14:20:54 676] INFO (XendDomainInfo:168) Recreating domain 30, UUID ed50de0d-b006-441d-8e7e-d6c5c2dd8e19. at /local/domain/30
[2012-06-08 14:21:01 676] DEBUG (XendDomain:476) Adding Domain: 30
[2012-06-08 14:21:02 676] DEBUG (XendDomainInfo:1881) XendDomainInfo.handleShutdownWatch

--------------000006000403030200020905
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000006000403030200020905--


From xen-devel-bounces@lists.xen.org Fri Jun 08 13:53:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:53: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 1Sczd7-0003hG-Tk; Fri, 08 Jun 2012 13:53: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 1Sczd5-0003hA-PI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:53:31 +0000
Received: from [85.158.138.51:15135] by server-8.bemta-3.messagelabs.com id
	15/51-22118-AD302DF4; Fri, 08 Jun 2012 13:53:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339163610!28612608!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6219 invoked from network); 8 Jun 2012 13:53:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 13:53:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12910689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 13: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.213.0; Fri, 8 Jun 2012 14:52:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SczcI-0008FR-6E; Fri, 08 Jun 2012 13:52:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SczcI-0007Uc-5E;
	Fri, 08 Jun 2012 14:52:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.938.126095.932066@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 14:52:42 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
	<4FC78D5502000078000875A7@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used"):
> On Thu, 31 May 2012, Jan Beulich wrote:
> > > It should be applied to qemu-xen-traditional too.
> > 
> > And the other one ("qemu/xendisk: properly update stats in
> > ioreq_release()") probably too.
> 
> Right.
> That patch is already in upstream QEMU and qemu-xen-upstream but it is
> missing in qemu-xen-traditional.

Can you tell me the commit id in qemu-xen-upstream so I can put it in
the commit message in qemu-xen-traditional ?

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 Jun 08 13:53:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:53: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 1Sczd7-0003hG-Tk; Fri, 08 Jun 2012 13:53: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 1Sczd5-0003hA-PI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:53:31 +0000
Received: from [85.158.138.51:15135] by server-8.bemta-3.messagelabs.com id
	15/51-22118-AD302DF4; Fri, 08 Jun 2012 13:53:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339163610!28612608!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6219 invoked from network); 8 Jun 2012 13:53:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 13:53:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12910689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 13: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.213.0; Fri, 8 Jun 2012 14:52:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SczcI-0008FR-6E; Fri, 08 Jun 2012 13:52:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SczcI-0007Uc-5E;
	Fri, 08 Jun 2012 14:52:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.938.126095.932066@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 14:52:42 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
	<4FC78D5502000078000875A7@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used"):
> On Thu, 31 May 2012, Jan Beulich wrote:
> > > It should be applied to qemu-xen-traditional too.
> > 
> > And the other one ("qemu/xendisk: properly update stats in
> > ioreq_release()") probably too.
> 
> Right.
> That patch is already in upstream QEMU and qemu-xen-upstream but it is
> missing in qemu-xen-traditional.

Can you tell me the commit id in qemu-xen-upstream so I can put it in
the commit message in qemu-xen-traditional ?

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 Jun 08 13:55:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:55: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 1SczeY-0003lv-CV; Fri, 08 Jun 2012 13:55: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 1SczeW-0003lo-VI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:55:01 +0000
Received: from [85.158.143.99:44757] by server-3.bemta-4.messagelabs.com id
	AD/95-29237-43402DF4; Fri, 08 Jun 2012 13:55:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339163699!28564602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32272 invoked from network); 8 Jun 2012 13:54:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 13:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12910727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 13:54:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 14:54:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SczeV-0008GB-9S; Fri, 08 Jun 2012 13:54:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SczeV-0007Uz-7q;
	Fri, 08 Jun 2012 14:54:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1075.163267.752415@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 14:54:59 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1338474659.15014.28.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<2cc22366943347deab77.1338466269@Solace>
	<20423.31878.217570.145066@mariner.uk.xensource.com>
	<1338474659.15014.28.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04 of 11] libxl: expand the libxl_{cpu,
	node}map API a 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

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 04 of 11] libxl: expand the libxl_{cpu, node}map API a bit"):
> On Thu, 2012-05-31 at 15:13 +0100, Ian Jackson wrote:
> > Dario Faggioli writes ("[PATCH 04 of 11] libxl: expand the libxl_{cpu,node}map API a bit"):
> > > +void libxl_cpumap_copy(/*XXX libxl_ctx *ctx,*/ libxl_cpumap *dst,
> > 
> > XXX ?
> 
> Yep, I left it on purpose but I also wanted to mention that in the
> changelog, which I apparently missed. Sorry.
> 
> However, now that we are here, the whole point is, does that function
> need a libxl_ctx argument? It doesn't use it, but I was concerned about
> consistency with the other libxl_cpumap_* calls, and maybe future
> needs...

Yes.  It should take a ctx.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 13:55:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 13:55: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 1SczeY-0003lv-CV; Fri, 08 Jun 2012 13:55: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 1SczeW-0003lo-VI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:55:01 +0000
Received: from [85.158.143.99:44757] by server-3.bemta-4.messagelabs.com id
	AD/95-29237-43402DF4; Fri, 08 Jun 2012 13:55:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339163699!28564602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32272 invoked from network); 8 Jun 2012 13:54:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 13:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12910727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 13:54:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 14:54:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SczeV-0008GB-9S; Fri, 08 Jun 2012 13:54:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SczeV-0007Uz-7q;
	Fri, 08 Jun 2012 14:54:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1075.163267.752415@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 14:54:59 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1338474659.15014.28.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<2cc22366943347deab77.1338466269@Solace>
	<20423.31878.217570.145066@mariner.uk.xensource.com>
	<1338474659.15014.28.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04 of 11] libxl: expand the libxl_{cpu,
	node}map API a 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

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 04 of 11] libxl: expand the libxl_{cpu, node}map API a bit"):
> On Thu, 2012-05-31 at 15:13 +0100, Ian Jackson wrote:
> > Dario Faggioli writes ("[PATCH 04 of 11] libxl: expand the libxl_{cpu,node}map API a bit"):
> > > +void libxl_cpumap_copy(/*XXX libxl_ctx *ctx,*/ libxl_cpumap *dst,
> > 
> > XXX ?
> 
> Yep, I left it on purpose but I also wanted to mention that in the
> changelog, which I apparently missed. Sorry.
> 
> However, now that we are here, the whole point is, does that function
> need a libxl_ctx argument? It doesn't use it, but I was concerned about
> consistency with the other libxl_cpumap_* calls, and maybe future
> needs...

Yes.  It should take a ctx.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:01:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Sczke-000438-6F; Fri, 08 Jun 2012 14:01:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sczkd-000433-0T
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:01:19 +0000
Received: from [193.109.254.147:43916] by server-11.bemta-14.messagelabs.com
	id D6/6B-02727-EA502DF4; Fri, 08 Jun 2012 14:01:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339164071!8640389!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4781 invoked from network); 8 Jun 2012 14:01:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:01:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12910962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:01:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:01:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SczkU-0008I9-Hj; Fri, 08 Jun 2012 14:01:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SczkU-0007VP-Gv;
	Fri, 08 Jun 2012 15:01:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1446.507811.744249@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:01:10 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1338478895.15014.60.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA
	placement	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation"):
> On Thu, 2012-05-31 at 16:08 +0100, Ian Jackson wrote:
> > In general I would prefer to see docs come in the same patch but I
> > guess I can read it here:
> 
> I can put it there. Would you recommend _moving_ it in the source file o
> also leaving a copy, o maybe just some pointers, here?

In general I don't mind whether API docs are in a separate file or in
the source headers.  What we have here is sufficiently complex that it
seems to merit its own file.  A reference to it from libxl.h would be
appropriate.

> Right, that is of couse an option, and I thought about going that way
> for quite a while. However, what I think is best for libxl is to provide
> a set of building blocks for its user to be able to implement the actual
> heuristics.

The difficulty with this is that this is supposedly becoming a stable
API.  If we change the approach later, we may want to change the API.
Do we know clearly enough what building blocks are needed and what
they should be like ?

I think it would be easier, at this stage for 4.2, simply to offer a
single `do something sensible' heuristic, and then think about more
complicated control by the caller for 4.3.

> Doing it the other way, i.e., one big function doing everything, would
> mean that as soon as we want to change or improve the placement
> heuristics, we need to modify the behaviour of that API call, which I
> think it is suboptimal.

If we have a function whose documented behaviour is `try to do a
roughly optimal thing' then improving its optimisation is not a change
to the API semantics.

Specifically, existing code then will, when upgraded to a newer libxl,
behaviour differently - better, we hope.  Is that not the intent ?

>   Also, if some other user of libxl does not like
> the heuristics I came out with, they have to reimplement the whole
> placement.

I think users of 4.2 won't be doing that.  That is, we can tell them
to please wait for 4.3 when we will have a richer API for this kind of
thing.

> So, like it is right now, the actual heuristics is implemented in xl, on
> top of these placement candidate generation and manipulation facilities,
> which I finally decided it was the way I liked this whole thing
> most. :-)

So how much of the code currently in libxl should be reproduced in
(say) libvirt ?

> Again, you're right in asking this reasoning to be part of the
> documentation, and to be put in the proper place, and I will do that.
> However, now that I've put it here, do you think it makes some sense?

I think it's fine for it to be in a separate file.  But I think it
should ideally be in the same patch as the implementation.

> > > +        libxl_numa_candidate_count_domains(libxl_ctx *ctx,
> > > +                                           libxl_numa_candidate *candidate);
> > > +
> > > +This is what counts the number of domains that are currently pinned
> > > +to the CPUs of the nodes of a given candidate.
> > 
> > Why is that useful ?  It is used by some of your other code so I guess
> > this is a facility which is useful to the implementors of other
> > placement algorithms ?
> 
> As I tried to explain above, yes, exactly like that.

Are we really sure that we want to support this API for a long 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 Jun 08 14:01:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Sczke-000438-6F; Fri, 08 Jun 2012 14:01:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sczkd-000433-0T
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:01:19 +0000
Received: from [193.109.254.147:43916] by server-11.bemta-14.messagelabs.com
	id D6/6B-02727-EA502DF4; Fri, 08 Jun 2012 14:01:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339164071!8640389!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4781 invoked from network); 8 Jun 2012 14:01:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:01:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12910962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:01:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:01:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SczkU-0008I9-Hj; Fri, 08 Jun 2012 14:01:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SczkU-0007VP-Gv;
	Fri, 08 Jun 2012 15:01:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1446.507811.744249@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:01:10 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1338478895.15014.60.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA
	placement	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation"):
> On Thu, 2012-05-31 at 16:08 +0100, Ian Jackson wrote:
> > In general I would prefer to see docs come in the same patch but I
> > guess I can read it here:
> 
> I can put it there. Would you recommend _moving_ it in the source file o
> also leaving a copy, o maybe just some pointers, here?

In general I don't mind whether API docs are in a separate file or in
the source headers.  What we have here is sufficiently complex that it
seems to merit its own file.  A reference to it from libxl.h would be
appropriate.

> Right, that is of couse an option, and I thought about going that way
> for quite a while. However, what I think is best for libxl is to provide
> a set of building blocks for its user to be able to implement the actual
> heuristics.

The difficulty with this is that this is supposedly becoming a stable
API.  If we change the approach later, we may want to change the API.
Do we know clearly enough what building blocks are needed and what
they should be like ?

I think it would be easier, at this stage for 4.2, simply to offer a
single `do something sensible' heuristic, and then think about more
complicated control by the caller for 4.3.

> Doing it the other way, i.e., one big function doing everything, would
> mean that as soon as we want to change or improve the placement
> heuristics, we need to modify the behaviour of that API call, which I
> think it is suboptimal.

If we have a function whose documented behaviour is `try to do a
roughly optimal thing' then improving its optimisation is not a change
to the API semantics.

Specifically, existing code then will, when upgraded to a newer libxl,
behaviour differently - better, we hope.  Is that not the intent ?

>   Also, if some other user of libxl does not like
> the heuristics I came out with, they have to reimplement the whole
> placement.

I think users of 4.2 won't be doing that.  That is, we can tell them
to please wait for 4.3 when we will have a richer API for this kind of
thing.

> So, like it is right now, the actual heuristics is implemented in xl, on
> top of these placement candidate generation and manipulation facilities,
> which I finally decided it was the way I liked this whole thing
> most. :-)

So how much of the code currently in libxl should be reproduced in
(say) libvirt ?

> Again, you're right in asking this reasoning to be part of the
> documentation, and to be put in the proper place, and I will do that.
> However, now that I've put it here, do you think it makes some sense?

I think it's fine for it to be in a separate file.  But I think it
should ideally be in the same patch as the implementation.

> > > +        libxl_numa_candidate_count_domains(libxl_ctx *ctx,
> > > +                                           libxl_numa_candidate *candidate);
> > > +
> > > +This is what counts the number of domains that are currently pinned
> > > +to the CPUs of the nodes of a given candidate.
> > 
> > Why is that useful ?  It is used by some of your other code so I guess
> > this is a facility which is useful to the implementors of other
> > placement algorithms ?
> 
> As I tried to explain above, yes, exactly like that.

Are we really sure that we want to support this API for a long 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 Jun 08 14:03:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sczmt-00049x-NL; Fri, 08 Jun 2012 14:03:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sczms-00049n-95
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:03:38 +0000
Received: from [193.109.254.147:35321] by server-6.bemta-14.messagelabs.com id
	B4/39-02426-93602DF4; Fri, 08 Jun 2012 14:03:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339164215!1920331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 935 invoked from network); 8 Jun 2012 14:03:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:03:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:03:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:03:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sczmo-0008Iu-KT; Fri, 08 Jun 2012 14:03:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sczmo-0007Vm-J9;
	Fri, 08 Jun 2012 15:03:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1587.672976.543703@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:03:31 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0233305f23816261bb49.1338466270@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
	IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> And make all the required infrastructure updates to enable this.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Tested-by: Dario Faggioli <dario.faggioli@citrix.com>

You write `From: Dario' in the headers but it has a S-o-b from Ian.

I think you should write
  From: Ian Campbell <ian.campbell@citrix.com>
if he actually wrote it.

git-commit --author will do this for you and I think git-send-email
will then generate appropriate output.

Can you point me at your git tree so I can easily clone it and see
what the output from this new IDL generator looks like ?

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 Jun 08 14:03:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sczmt-00049x-NL; Fri, 08 Jun 2012 14:03:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sczms-00049n-95
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:03:38 +0000
Received: from [193.109.254.147:35321] by server-6.bemta-14.messagelabs.com id
	B4/39-02426-93602DF4; Fri, 08 Jun 2012 14:03:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339164215!1920331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 935 invoked from network); 8 Jun 2012 14:03:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:03:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:03:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:03:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sczmo-0008Iu-KT; Fri, 08 Jun 2012 14:03:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sczmo-0007Vm-J9;
	Fri, 08 Jun 2012 15:03:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1587.672976.543703@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:03:31 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0233305f23816261bb49.1338466270@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
	IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> And make all the required infrastructure updates to enable this.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Tested-by: Dario Faggioli <dario.faggioli@citrix.com>

You write `From: Dario' in the headers but it has a S-o-b from Ian.

I think you should write
  From: Ian Campbell <ian.campbell@citrix.com>
if he actually wrote it.

git-commit --author will do this for you and I think git-send-email
will then generate appropriate output.

Can you point me at your git tree so I can easily clone it and see
what the output from this new IDL generator looks like ?

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 Jun 08 14:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sczop-0004JU-DC; Fri, 08 Jun 2012 14:05:39 +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 1Sczoo-0004JI-9G
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:05:38 +0000
Received: from [85.158.138.51:47899] by server-11.bemta-3.messagelabs.com id
	64/20-28329-1B602DF4; Fri, 08 Jun 2012 14:05:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339164335!22592042!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27324 invoked from network); 8 Jun 2012 14:05:36 -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;
	8 Jun 2012 14:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330923600"; d="scan'208";a="27358059"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:05:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 10:05:18 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SczoU-0007Va-DY;
	Fri, 08 Jun 2012 15:05:18 +0100
Message-ID: <4FD2062E.1040308@eu.citrix.com>
Date: Fri, 8 Jun 2012 15:03:26 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
In-Reply-To: <20434.1446.507811.744249@mariner.uk.xensource.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/06/12 15:01, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation"):
>> On Thu, 2012-05-31 at 16:08 +0100, Ian Jackson wrote:
>>> In general I would prefer to see docs come in the same patch but I
>>> guess I can read it here:
>> I can put it there. Would you recommend _moving_ it in the source file o
>> also leaving a copy, o maybe just some pointers, here?
> In general I don't mind whether API docs are in a separate file or in
> the source headers.  What we have here is sufficiently complex that it
> seems to merit its own file.  A reference to it from libxl.h would be
> appropriate.
>
>> Right, that is of couse an option, and I thought about going that way
>> for quite a while. However, what I think is best for libxl is to provide
>> a set of building blocks for its user to be able to implement the actual
>> heuristics.
> The difficulty with this is that this is supposedly becoming a stable
> API.  If we change the approach later, we may want to change the API.
> Do we know clearly enough what building blocks are needed and what
> they should be like ?
>
> I think it would be easier, at this stage for 4.2, simply to offer a
> single `do something sensible' heuristic, and then think about more
> complicated control by the caller for 4.3.
In fact, I think it would probably be better to take Ian Campbell's 
suggestion and either just do it in xl completely (with no libxl 
changes) or do it entirely with libxl, with no external interface.  Then 
we'll have something better than nothing, and the whole 4.3 dev cycle to 
come up with a good interface we can commit to.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sczop-0004JU-DC; Fri, 08 Jun 2012 14:05:39 +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 1Sczoo-0004JI-9G
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:05:38 +0000
Received: from [85.158.138.51:47899] by server-11.bemta-3.messagelabs.com id
	64/20-28329-1B602DF4; Fri, 08 Jun 2012 14:05:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339164335!22592042!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27324 invoked from network); 8 Jun 2012 14:05:36 -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;
	8 Jun 2012 14:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330923600"; d="scan'208";a="27358059"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 10:05:19 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 10:05:18 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SczoU-0007Va-DY;
	Fri, 08 Jun 2012 15:05:18 +0100
Message-ID: <4FD2062E.1040308@eu.citrix.com>
Date: Fri, 8 Jun 2012 15:03:26 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
In-Reply-To: <20434.1446.507811.744249@mariner.uk.xensource.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/06/12 15:01, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation"):
>> On Thu, 2012-05-31 at 16:08 +0100, Ian Jackson wrote:
>>> In general I would prefer to see docs come in the same patch but I
>>> guess I can read it here:
>> I can put it there. Would you recommend _moving_ it in the source file o
>> also leaving a copy, o maybe just some pointers, here?
> In general I don't mind whether API docs are in a separate file or in
> the source headers.  What we have here is sufficiently complex that it
> seems to merit its own file.  A reference to it from libxl.h would be
> appropriate.
>
>> Right, that is of couse an option, and I thought about going that way
>> for quite a while. However, what I think is best for libxl is to provide
>> a set of building blocks for its user to be able to implement the actual
>> heuristics.
> The difficulty with this is that this is supposedly becoming a stable
> API.  If we change the approach later, we may want to change the API.
> Do we know clearly enough what building blocks are needed and what
> they should be like ?
>
> I think it would be easier, at this stage for 4.2, simply to offer a
> single `do something sensible' heuristic, and then think about more
> complicated control by the caller for 4.3.
In fact, I think it would probably be better to take Ian Campbell's 
suggestion and either just do it in xl completely (with no libxl 
changes) or do it entirely with libxl, with no external interface.  Then 
we'll have something better than nothing, and the whole 4.3 dev cycle to 
come up with a good interface we can commit to.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:06:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:06: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 1Sczpu-0004QQ-SM; Fri, 08 Jun 2012 14:06: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 1Sczpt-0004Q3-Kg
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:06:45 +0000
Received: from [85.158.143.35:14064] by server-2.bemta-4.messagelabs.com id
	2D/5C-17938-5F602DF4; Fri, 08 Jun 2012 14:06:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339164404!16259488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23065 invoked from network); 8 Jun 2012 14:06:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:06:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:06:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sczpr-0008KC-T0; Fri, 08 Jun 2012 14:06:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sczpr-0007WT-SH;
	Fri, 08 Jun 2012 15:06:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1779.861143.892286@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:06:43 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4FD2062E.1040308@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
	<4FD2062E.1040308@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
 documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation"):
> On 08/06/12 15:01, Ian Jackson wrote:
> > I think it would be easier, at this stage for 4.2, simply to offer a
> > single `do something sensible' heuristic, and then think about more
> > complicated control by the caller for 4.3.
>
> In fact, I think it would probably be better to take Ian Campbell's 
> suggestion and either just do it in xl completely (with no libxl 
> changes) or do it entirely with libxl, with no external interface.  Then 
> we'll have something better than nothing, and the whole 4.3 dev cycle to 
> come up with a good interface we can commit to.

Yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:06:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:06: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 1Sczpu-0004QQ-SM; Fri, 08 Jun 2012 14:06: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 1Sczpt-0004Q3-Kg
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:06:45 +0000
Received: from [85.158.143.35:14064] by server-2.bemta-4.messagelabs.com id
	2D/5C-17938-5F602DF4; Fri, 08 Jun 2012 14:06:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339164404!16259488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23065 invoked from network); 8 Jun 2012 14:06:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:06:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:06:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sczpr-0008KC-T0; Fri, 08 Jun 2012 14:06:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sczpr-0007WT-SH;
	Fri, 08 Jun 2012 15:06:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1779.861143.892286@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:06:43 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <4FD2062E.1040308@eu.citrix.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
	<4FD2062E.1040308@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
 documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation"):
> On 08/06/12 15:01, Ian Jackson wrote:
> > I think it would be easier, at this stage for 4.2, simply to offer a
> > single `do something sensible' heuristic, and then think about more
> > complicated control by the caller for 4.3.
>
> In fact, I think it would probably be better to take Ian Campbell's 
> suggestion and either just do it in xl completely (with no libxl 
> changes) or do it entirely with libxl, with no external interface.  Then 
> we'll have something better than nothing, and the whole 4.3 dev cycle to 
> come up with a good interface we can commit to.

Yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sczqm-0004W5-AV; Fri, 08 Jun 2012 14:07: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 1Sczqk-0004Vu-Ih
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 14:07:38 +0000
Received: from [85.158.138.51:63740] by server-4.bemta-3.messagelabs.com id
	2C/82-13598-92702DF4; Fri, 08 Jun 2012 14:07:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339164456!31475679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28673 invoked from network); 8 Jun 2012 14:07:37 -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; 8 Jun 2012 14:07:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 15:09:10 +0100
Message-Id: <4FD223710200007800088CC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 15:08:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD1FDE2.5010907@amd.com> <4FD1FEC8.5000708@citrix.com>
	<4FD200EC.6050005@amd.com>
In-Reply-To: <4FD200EC.6050005@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.06.12 at 15:41, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/08/2012 03:31 PM, Andrew Cooper wrote:
>> On 08/06/12 14:28, Wei Wang wrote:
>>> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability
>>> for some reasons and iommu cannot generate any interrupts in this case.
>>> Attached patch re-enables it in device assignment.
>>
>> Under which circumstances should dom0 able to play with the IOMMUs ?
>> Surely the fact that dom0 can play with the IOMMUs is a bug in itself.
> 
> It looks like some generic msi/pci codes disable it, not the Linux iommu 
> driver itself, which is only loaded on bare metal. AMD IOMMU expose 
> interrupt capability as a normal msi block. So the general pci/msi layer 
> of dom0 might touch it...

In that case it wouldn't be on pv-ops alone (which your patch
says).

Also, your patch using IOMMU_CONTROL_ENABLED instead of
PCI_MSI_FLAGS_ENABLE is quite misleading (as it hides the fact
the what you play with is not IOMMU-specific).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sczqm-0004W5-AV; Fri, 08 Jun 2012 14:07: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 1Sczqk-0004Vu-Ih
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 14:07:38 +0000
Received: from [85.158.138.51:63740] by server-4.bemta-3.messagelabs.com id
	2C/82-13598-92702DF4; Fri, 08 Jun 2012 14:07:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339164456!31475679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28673 invoked from network); 8 Jun 2012 14:07:37 -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; 8 Jun 2012 14:07:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 15:09:10 +0100
Message-Id: <4FD223710200007800088CC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 15:08:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD1FDE2.5010907@amd.com> <4FD1FEC8.5000708@citrix.com>
	<4FD200EC.6050005@amd.com>
In-Reply-To: <4FD200EC.6050005@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.06.12 at 15:41, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/08/2012 03:31 PM, Andrew Cooper wrote:
>> On 08/06/12 14:28, Wei Wang wrote:
>>> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability
>>> for some reasons and iommu cannot generate any interrupts in this case.
>>> Attached patch re-enables it in device assignment.
>>
>> Under which circumstances should dom0 able to play with the IOMMUs ?
>> Surely the fact that dom0 can play with the IOMMUs is a bug in itself.
> 
> It looks like some generic msi/pci codes disable it, not the Linux iommu 
> driver itself, which is only loaded on bare metal. AMD IOMMU expose 
> interrupt capability as a normal msi block. So the general pci/msi layer 
> of dom0 might touch it...

In that case it wouldn't be on pv-ops alone (which your patch
says).

Also, your patch using IOMMU_CONTROL_ENABLED instead of
PCI_MSI_FLAGS_ENABLE is quite misleading (as it hides the fact
the what you play with is not IOMMU-specific).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:08:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sczrb-0004e3-OQ; Fri, 08 Jun 2012 14:08:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sczra-0004dh-6d
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 14:08:30 +0000
Received: from [85.158.139.83:25393] by server-11.bemta-5.messagelabs.com id
	07/BC-25194-D5702DF4; Fri, 08 Jun 2012 14:08:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339164508!32690872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11472 invoked from network); 8 Jun 2012 14:08:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:07:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:07:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sczqy-0008KX-V8; Fri, 08 Jun 2012 14:07:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sczqy-0007Wh-Tg;
	Fri, 08 Jun 2012 15:07:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1848.747678.259199@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:07:52 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FC766F7.2030802@tiscali.it>
References: <4FC766F7.2030802@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other
 xen kernel modules on xencommons start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):
> # HG changeset patch
> # User Fabio Fantoni
> # Date 1338467204 -7200
> # Node ID 1f57503f10112718ecbbe424fa8fc9c55785f4c0
> # Parent  dd7319230f4ac295b6d14ce2e2a3dccf82bb87d8
> tools/hotplug/Linux/init.d/: added other xen kernel modules on 
> xencommons start

This looks at least harmless to me.

I'm surprised, however, that these things aren't loaded automatically.
For example, shouldn't the xenbus driver's enumeration automatically
load blkback too ?

Having said that, I'm inclined to apply this unless someone 
explains that it's a bad idea.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:08:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sczrb-0004e3-OQ; Fri, 08 Jun 2012 14:08:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sczra-0004dh-6d
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 14:08:30 +0000
Received: from [85.158.139.83:25393] by server-11.bemta-5.messagelabs.com id
	07/BC-25194-D5702DF4; Fri, 08 Jun 2012 14:08:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339164508!32690872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11472 invoked from network); 8 Jun 2012 14:08:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:07:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:07:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sczqy-0008KX-V8; Fri, 08 Jun 2012 14:07:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sczqy-0007Wh-Tg;
	Fri, 08 Jun 2012 15:07:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.1848.747678.259199@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:07:52 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FC766F7.2030802@tiscali.it>
References: <4FC766F7.2030802@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other
 xen kernel modules on xencommons start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fabio Fantoni writes ("[Xen-devel] [PATCH] tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommons start"):
> # HG changeset patch
> # User Fabio Fantoni
> # Date 1338467204 -7200
> # Node ID 1f57503f10112718ecbbe424fa8fc9c55785f4c0
> # Parent  dd7319230f4ac295b6d14ce2e2a3dccf82bb87d8
> tools/hotplug/Linux/init.d/: added other xen kernel modules on 
> xencommons start

This looks at least harmless to me.

I'm surprised, however, that these things aren't loaded automatically.
For example, shouldn't the xenbus driver's enumeration automatically
load blkback too ?

Having said that, I'm inclined to apply this unless someone 
explains that it's a bad idea.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1SczzI-00054a-MR; Fri, 08 Jun 2012 14:16:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SczzH-00054V-Ak
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 14:16:27 +0000
Received: from [193.109.254.147:54306] by server-9.bemta-14.messagelabs.com id
	D8/7E-27072-A3902DF4; Fri, 08 Jun 2012 14:16:26 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339164958!8761390!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1997 invoked from network); 8 Jun 2012 14:16:01 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 14:16:01 -0000
Received: from mail151-ch1-R.bigfish.com (10.43.68.253) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 14:15:07 +0000
Received: from mail151-ch1 (localhost [127.0.0.1])	by
	mail151-ch1-R.bigfish.com (Postfix) with ESMTP id BEB5EE03FB;
	Fri,  8 Jun 2012 14:15:07 +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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1
	(MessageSwitch) id 1339164905629322_11829;
	Fri,  8 Jun 2012 14:15:05 +0000 (UTC)
Received: from CH1EHSMHS009.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.226])	by mail151-ch1.bigfish.com (Postfix) with ESMTP id
	97A1B42009C;	Fri,  8 Jun 2012 14:15:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 14:15:05 +0000
X-WSS-ID: 0M5AYAH-02-6F5-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 2B26EC8196;	Fri,  8 Jun 2012 09:15:53 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 09:16:14 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 8 Jun 2012 09:15:54 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	10:15:51 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1EAEE49C20C; Fri,  8 Jun 2012
	15:15:50 +0100 (BST)
Message-ID: <4FD2092B.3030209@amd.com>
Date: Fri, 8 Jun 2012 16:16:11 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD1FDE2.5010907@amd.com> <4FD1FEC8.5000708@citrix.com>
	<4FD200EC.6050005@amd.com>
	<4FD223710200007800088CC3@nat28.tlf.novell.com>
In-Reply-To: <4FD223710200007800088CC3@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled 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 06/08/2012 04:08 PM, Jan Beulich wrote:
>>>> On 08.06.12 at 15:41, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/08/2012 03:31 PM, Andrew Cooper wrote:
>>> On 08/06/12 14:28, Wei Wang wrote:
>>>> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability
>>>> for some reasons and iommu cannot generate any interrupts in this case.
>>>> Attached patch re-enables it in device assignment.
>>>
>>> Under which circumstances should dom0 able to play with the IOMMUs ?
>>> Surely the fact that dom0 can play with the IOMMUs is a bug in itself.
>>
>> It looks like some generic msi/pci codes disable it, not the Linux iommu
>> driver itself, which is only loaded on bare metal. AMD IOMMU expose
>> interrupt capability as a normal msi block. So the general pci/msi layer
>> of dom0 might touch it...
>
> In that case it wouldn't be on pv-ops alone (which your patch
> says).

Yes, probably upstream Linux also has this issue. I will check that. But 
I did not see this issue on 3.2 pv_ops & 2.6 pv_ops.

> Also, your patch using IOMMU_CONTROL_ENABLED instead of
> PCI_MSI_FLAGS_ENABLE is quite misleading (as it hides the fact
> the what you play with is not IOMMU-specific).

Thanks, I will use PCI_MSI_FLAGS_ENABLE in next post.

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 Jun 08 14:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1SczzI-00054a-MR; Fri, 08 Jun 2012 14:16:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SczzH-00054V-Ak
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 14:16:27 +0000
Received: from [193.109.254.147:54306] by server-9.bemta-14.messagelabs.com id
	D8/7E-27072-A3902DF4; Fri, 08 Jun 2012 14:16:26 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339164958!8761390!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1997 invoked from network); 8 Jun 2012 14:16:01 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 14:16:01 -0000
Received: from mail151-ch1-R.bigfish.com (10.43.68.253) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 14:15:07 +0000
Received: from mail151-ch1 (localhost [127.0.0.1])	by
	mail151-ch1-R.bigfish.com (Postfix) with ESMTP id BEB5EE03FB;
	Fri,  8 Jun 2012 14:15:07 +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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1
	(MessageSwitch) id 1339164905629322_11829;
	Fri,  8 Jun 2012 14:15:05 +0000 (UTC)
Received: from CH1EHSMHS009.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.226])	by mail151-ch1.bigfish.com (Postfix) with ESMTP id
	97A1B42009C;	Fri,  8 Jun 2012 14:15:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 14:15:05 +0000
X-WSS-ID: 0M5AYAH-02-6F5-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 2B26EC8196;	Fri,  8 Jun 2012 09:15:53 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 09:16:14 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 8 Jun 2012 09:15:54 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	10:15:51 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1EAEE49C20C; Fri,  8 Jun 2012
	15:15:50 +0100 (BST)
Message-ID: <4FD2092B.3030209@amd.com>
Date: Fri, 8 Jun 2012 16:16:11 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD1FDE2.5010907@amd.com> <4FD1FEC8.5000708@citrix.com>
	<4FD200EC.6050005@amd.com>
	<4FD223710200007800088CC3@nat28.tlf.novell.com>
In-Reply-To: <4FD223710200007800088CC3@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] amd iommu: re-enable iommu msi if dom0
 disabled 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 06/08/2012 04:08 PM, Jan Beulich wrote:
>>>> On 08.06.12 at 15:41, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/08/2012 03:31 PM, Andrew Cooper wrote:
>>> On 08/06/12 14:28, Wei Wang wrote:
>>>> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability
>>>> for some reasons and iommu cannot generate any interrupts in this case.
>>>> Attached patch re-enables it in device assignment.
>>>
>>> Under which circumstances should dom0 able to play with the IOMMUs ?
>>> Surely the fact that dom0 can play with the IOMMUs is a bug in itself.
>>
>> It looks like some generic msi/pci codes disable it, not the Linux iommu
>> driver itself, which is only loaded on bare metal. AMD IOMMU expose
>> interrupt capability as a normal msi block. So the general pci/msi layer
>> of dom0 might touch it...
>
> In that case it wouldn't be on pv-ops alone (which your patch
> says).

Yes, probably upstream Linux also has this issue. I will check that. But 
I did not see this issue on 3.2 pv_ops & 2.6 pv_ops.

> Also, your patch using IOMMU_CONTROL_ENABLED instead of
> PCI_MSI_FLAGS_ENABLE is quite misleading (as it hides the fact
> the what you play with is not IOMMU-specific).

Thanks, I will use PCI_MSI_FLAGS_ENABLE in next post.

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 Jun 08 14:19:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sd01m-0005AQ-7Y; Fri, 08 Jun 2012 14:19:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1Sd01l-0005AJ-5j
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:19:01 +0000
Received: from [85.158.143.99:36708] by server-2.bemta-4.messagelabs.com id
	D4/CE-17938-4D902DF4; Fri, 08 Jun 2012 14:19:00 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339165138!26663118!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28411 invoked from network); 8 Jun 2012 14:18:58 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Jun 2012 14:18:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:Content-Type:MIME-Version:Reply-To:Message-ID:Cc:To:From:Date;
	bh=DA/E3VO98GKMmfx3iriOuK2GQHSu+bZddWp4McJ/GSc=; 
	b=pvYffxOXgV3/NgyOmb8vnKYI9Z0gAdP77YA2FyrdoYWMQPkK+ItDFDK5JMPRkq9FrnTViu1cxNQjc/tJQwf6prRAia1Vq6rvj6mlrMNNn3LldO5KnO8QYfno/RAFfHU/;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>)
	id 1Sd01h-0001nr-Hd; Fri, 08 Jun 2012 14:18:57 +0000
Date: Fri, 8 Jun 2012 14:18:57 +0000
From: Andy Smith <andy@strugglers.net>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <20120608141857.GG11695@bitfolk.com>
MIME-Version: 1.0
Content-Disposition: inline
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Fri,
	08 Jun 2012 14:18:57 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd2.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Cc: "olivier.hanesse" <olivier.hanesse@gmail.com>
Subject: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: xen-devel@lists.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: 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 two installs of Xen 4.0.1 on Debian squeeze dom0s that
occasionally skew the time by 3000 seconds. It is always 3000
seconds and it always affects all guests.

Depending on the kernels in the guests they will say:

    tp0 kernel: [9339489.266542] Clocksource tsc unstable (delta = -2999660317697 ns)

or perhaps the kernel doesn't notice but ntpd does:

    ls0 ntpd[15009]: time reset -2999.683517 s

the point is it does affect all guests.

Back in February 2011 there was a thread started by Olivier Hanesse
which appears to be exactly the same issue:

    http://old-list-archives.xen.org/archives/html/xen-users/2011-02/msg00609.html

Like Olivier, one of my hosts used to run Xen 3.x and did not
experience this issue until after it was upgraded to Xen 4. The
other has only ever run 4.0.x so I don't know.

The above thread ends with Olivier using clocksource=pit on his Xen
command line and waiting to see if it fixed things. If you are
reading, Olivier, did it fix things for you?

These are Debian squeeze installs so using packaged versions of xen
and kernel:

ii  linux-image-2.6.32-5-xen-amd64 2.6.32-45 Linux 2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.0-amd64       4.0.1-4   The Xen Hypervisor on AMD64

One of the hosts affected is:

CPU: Xeon 5410
Motherboard: Supermicro X7DCL-i

The other is:

CPU: Xeon E5606
Motherboard: SUpermicro X8DTN+

but I do have other servers with same hardware as both of these that
aren't affected.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:19:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sd01m-0005AQ-7Y; Fri, 08 Jun 2012 14:19:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1Sd01l-0005AJ-5j
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:19:01 +0000
Received: from [85.158.143.99:36708] by server-2.bemta-4.messagelabs.com id
	D4/CE-17938-4D902DF4; Fri, 08 Jun 2012 14:19:00 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339165138!26663118!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28411 invoked from network); 8 Jun 2012 14:18:58 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Jun 2012 14:18:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:Content-Type:MIME-Version:Reply-To:Message-ID:Cc:To:From:Date;
	bh=DA/E3VO98GKMmfx3iriOuK2GQHSu+bZddWp4McJ/GSc=; 
	b=pvYffxOXgV3/NgyOmb8vnKYI9Z0gAdP77YA2FyrdoYWMQPkK+ItDFDK5JMPRkq9FrnTViu1cxNQjc/tJQwf6prRAia1Vq6rvj6mlrMNNn3LldO5KnO8QYfno/RAFfHU/;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>)
	id 1Sd01h-0001nr-Hd; Fri, 08 Jun 2012 14:18:57 +0000
Date: Fri, 8 Jun 2012 14:18:57 +0000
From: Andy Smith <andy@strugglers.net>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <20120608141857.GG11695@bitfolk.com>
MIME-Version: 1.0
Content-Disposition: inline
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Fri,
	08 Jun 2012 14:18:57 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd2.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Cc: "olivier.hanesse" <olivier.hanesse@gmail.com>
Subject: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: xen-devel@lists.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: 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 two installs of Xen 4.0.1 on Debian squeeze dom0s that
occasionally skew the time by 3000 seconds. It is always 3000
seconds and it always affects all guests.

Depending on the kernels in the guests they will say:

    tp0 kernel: [9339489.266542] Clocksource tsc unstable (delta = -2999660317697 ns)

or perhaps the kernel doesn't notice but ntpd does:

    ls0 ntpd[15009]: time reset -2999.683517 s

the point is it does affect all guests.

Back in February 2011 there was a thread started by Olivier Hanesse
which appears to be exactly the same issue:

    http://old-list-archives.xen.org/archives/html/xen-users/2011-02/msg00609.html

Like Olivier, one of my hosts used to run Xen 3.x and did not
experience this issue until after it was upgraded to Xen 4. The
other has only ever run 4.0.x so I don't know.

The above thread ends with Olivier using clocksource=pit on his Xen
command line and waiting to see if it fixed things. If you are
reading, Olivier, did it fix things for you?

These are Debian squeeze installs so using packaged versions of xen
and kernel:

ii  linux-image-2.6.32-5-xen-amd64 2.6.32-45 Linux 2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.0-amd64       4.0.1-4   The Xen Hypervisor on AMD64

One of the hosts affected is:

CPU: Xeon 5410
Motherboard: Supermicro X7DCL-i

The other is:

CPU: Xeon E5606
Motherboard: SUpermicro X8DTN+

but I do have other servers with same hardware as both of these that
aren't affected.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:26:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd08t-0005ME-4m; Fri, 08 Jun 2012 14:26: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 1Sd08r-0005M9-Hl
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:26:21 +0000
Received: from [85.158.138.51:16813] by server-3.bemta-3.messagelabs.com id
	33/2F-25608-C8B02DF4; Fri, 08 Jun 2012 14:26:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339165580!31450772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24884 invoked from network); 8 Jun 2012 14:26:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:26:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:26:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:26:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd08p-0008RY-Bh; Fri, 08 Jun 2012 14:26:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd08p-0007Za-Am;
	Fri, 08 Jun 2012 15:26:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.2955.317215.979906@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:26:19 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FD1DDDC.6020405@eu.citrix.com>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> On 08/06/12 12:10, Ian Jackson wrote:
> > Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> >> As it happens in the implementation of `xl sched-sedf -d ...', some
> >> consistency checking is needed for the scheduling parameters when
> >> they come from the config file.
> > Thanks, I am happy with this from a libxl point of view.  I would like
> > to see an ack from George from a scheduler point of view.
> I think Dario knows more about what sedf wants than I do; and since it 
> only does anything when the domain is using sedf, I think it's fine.
> 
> So FWIW:
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Great, thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:26:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd08t-0005ME-4m; Fri, 08 Jun 2012 14:26: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 1Sd08r-0005M9-Hl
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:26:21 +0000
Received: from [85.158.138.51:16813] by server-3.bemta-3.messagelabs.com id
	33/2F-25608-C8B02DF4; Fri, 08 Jun 2012 14:26:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339165580!31450772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24884 invoked from network); 8 Jun 2012 14:26:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:26:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12911979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:26:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:26:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd08p-0008RY-Bh; Fri, 08 Jun 2012 14:26:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd08p-0007Za-Am;
	Fri, 08 Jun 2012 15:26:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.2955.317215.979906@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:26:19 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FD1DDDC.6020405@eu.citrix.com>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> On 08/06/12 12:10, Ian Jackson wrote:
> > Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> >> As it happens in the implementation of `xl sched-sedf -d ...', some
> >> consistency checking is needed for the scheduling parameters when
> >> they come from the config file.
> > Thanks, I am happy with this from a libxl point of view.  I would like
> > to see an ack from George from a scheduler point of view.
> I think Dario knows more about what sedf wants than I do; and since it 
> only does anything when the domain is using sedf, I think it's fine.
> 
> So FWIW:
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Great, thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sd0Gc-0005bv-3E; Fri, 08 Jun 2012 14:34: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 1Sd0Gb-0005bq-5I
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:34:21 +0000
Received: from [85.158.143.35:32491] by server-3.bemta-4.messagelabs.com id
	CF/E5-29237-C6D02DF4; Fri, 08 Jun 2012 14:34:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339166050!9006170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22301 invoked from network); 8 Jun 2012 14:34:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:34:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12912208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:34:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:34:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0GQ-0008WL-Ic; Fri, 08 Jun 2012 14:34:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0GQ-0007bU-Hg;
	Fri, 08 Jun 2012 15:34:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.3426.323707.395333@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:34:10 +0100
To: <Xuesen.Guo@hitachiconsulting.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1338188093.3965.6.camel@goosenl-desktop>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
	<1335432002.28015.78.camel@zakaz.uk.xensource.com>
	<1335433871.4742.18.camel@goosenl-desktop>
	<1335487527.4742.19.camel@goosenl-desktop>
	<20397.16795.166767.442835@mariner.uk.xensource.com>
	<1336754967.23818.142.camel@zakaz.uk.xensource.com>
	<1338185019.3965.5.camel@goosenl-desktop>
	<1338188093.3965.6.camel@goosenl-desktop>
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] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xuesen Guo writes ("Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support"):
> Also the attached is the patch.
...
> > readnote: Add bzImage kernel support
...
> > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14: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 1Sd0Gc-0005bv-3E; Fri, 08 Jun 2012 14:34: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 1Sd0Gb-0005bq-5I
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:34:21 +0000
Received: from [85.158.143.35:32491] by server-3.bemta-4.messagelabs.com id
	CF/E5-29237-C6D02DF4; Fri, 08 Jun 2012 14:34:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339166050!9006170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22301 invoked from network); 8 Jun 2012 14:34:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:34:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12912208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:34:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 15:34:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0GQ-0008WL-Ic; Fri, 08 Jun 2012 14:34:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0GQ-0007bU-Hg;
	Fri, 08 Jun 2012 15:34:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.3426.323707.395333@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 15:34:10 +0100
To: <Xuesen.Guo@hitachiconsulting.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1338188093.3965.6.camel@goosenl-desktop>
References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6>
	<4F992DCF0200007800080283@nat28.tlf.novell.com>
	<1335432002.28015.78.camel@zakaz.uk.xensource.com>
	<1335433871.4742.18.camel@goosenl-desktop>
	<1335487527.4742.19.camel@goosenl-desktop>
	<20397.16795.166767.442835@mariner.uk.xensource.com>
	<1336754967.23818.142.camel@zakaz.uk.xensource.com>
	<1338185019.3965.5.camel@goosenl-desktop>
	<1338188093.3965.6.camel@goosenl-desktop>
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] [PATCH] readnote: Add bzImage kernel support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xuesen Guo writes ("Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support"):
> Also the attached is the patch.
...
> > readnote: Add bzImage kernel support
...
> > Signed-off-by: Xuesen Guo <Xuesen.Guo@hitachiconsulting.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:35:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd0Hm-0005ls-NV; Fri, 08 Jun 2012 14:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd0Hl-0005lk-By
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:35:33 +0000
Received: from [85.158.143.35:44769] by server-1.bemta-4.messagelabs.com id
	A7/BC-10042-4BD02DF4; Fri, 08 Jun 2012 14:35:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339166130!11490485!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1215 invoked from network); 8 Jun 2012 14:35:31 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	8 Jun 2012 14:35:31 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78751645; Fri, 08 Jun 2012 16:35:30 +0200
Message-ID: <1339166124.5003.12.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 16:35:24 +0200
In-Reply-To: <20434.1779.861143.892286@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
	<4FD2062E.1040308@eu.citrix.com>
	<20434.1779.861143.892286@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
 documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9110280590513766519=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============9110280590513766519==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-CKCtTYG16qCOoTPyecRJ"


--=-CKCtTYG16qCOoTPyecRJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 15:06 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NU=
MA placement documentation"):
> > On 08/06/12 15:01, Ian Jackson wrote:
> > > I think it would be easier, at this stage for 4.2, simply to offer a
> > > single `do something sensible' heuristic, and then think about more
> > > complicated control by the caller for 4.3.
> >
> > In fact, I think it would probably be better to take Ian Campbell's=20
> > suggestion and either just do it in xl completely (with no libxl=20
> > changes) or do it entirely with libxl, with no external interface.  The=
n=20
> > we'll have something better than nothing, and the whole 4.3 dev cycle t=
o=20
> > come up with a good interface we can commit to.
>=20
> Yes.
>=20
That's fine. As also discussed on IRC with Ian Campbell and George, I'm
putting everything inside libxl, but with _no_ public API exposure of it
at all (as per analogy to it being in xend).

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-CKCtTYG16qCOoTPyecRJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SDawACgkQk4XaBE3IOsQGVQCdHNZIbkDBLqVWcySghrpowD3W
vJIAoKeGblmuwGtu9EJ2WFcx9jMM0xLE
=LaUQ
-----END PGP SIGNATURE-----

--=-CKCtTYG16qCOoTPyecRJ--



--===============9110280590513766519==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9110280590513766519==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 14:35:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd0Hm-0005ls-NV; Fri, 08 Jun 2012 14:35:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd0Hl-0005lk-By
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:35:33 +0000
Received: from [85.158.143.35:44769] by server-1.bemta-4.messagelabs.com id
	A7/BC-10042-4BD02DF4; Fri, 08 Jun 2012 14:35:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339166130!11490485!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1215 invoked from network); 8 Jun 2012 14:35:31 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	8 Jun 2012 14:35:31 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78751645; Fri, 08 Jun 2012 16:35:30 +0200
Message-ID: <1339166124.5003.12.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 16:35:24 +0200
In-Reply-To: <20434.1779.861143.892286@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
	<4FD2062E.1040308@eu.citrix.com>
	<20434.1779.861143.892286@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
 documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9110280590513766519=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============9110280590513766519==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-CKCtTYG16qCOoTPyecRJ"


--=-CKCtTYG16qCOoTPyecRJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 15:06 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NU=
MA placement documentation"):
> > On 08/06/12 15:01, Ian Jackson wrote:
> > > I think it would be easier, at this stage for 4.2, simply to offer a
> > > single `do something sensible' heuristic, and then think about more
> > > complicated control by the caller for 4.3.
> >
> > In fact, I think it would probably be better to take Ian Campbell's=20
> > suggestion and either just do it in xl completely (with no libxl=20
> > changes) or do it entirely with libxl, with no external interface.  The=
n=20
> > we'll have something better than nothing, and the whole 4.3 dev cycle t=
o=20
> > come up with a good interface we can commit to.
>=20
> Yes.
>=20
That's fine. As also discussed on IRC with Ian Campbell and George, I'm
putting everything inside libxl, but with _no_ public API exposure of it
at all (as per analogy to it being in xend).

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-CKCtTYG16qCOoTPyecRJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SDawACgkQk4XaBE3IOsQGVQCdHNZIbkDBLqVWcySghrpowD3W
vJIAoKeGblmuwGtu9EJ2WFcx9jMM0xLE
=LaUQ
-----END PGP SIGNATURE-----

--=-CKCtTYG16qCOoTPyecRJ--



--===============9110280590513766519==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9110280590513766519==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 14:47:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd0T9-00061t-4M; Fri, 08 Jun 2012 14:47: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 1Sd0T7-00061o-Ga
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:47:17 +0000
Received: from [85.158.139.83:61749] by server-12.bemta-5.messagelabs.com id
	40/44-18374-47012DF4; Fri, 08 Jun 2012 14:47:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339166836!32568714!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8316 invoked from network); 8 Jun 2012 14:47:16 -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; 8 Jun 2012 14:47:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 15:48:48 +0100
Message-Id: <4FD22CBD0200007800088D05@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 15:47:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <20120608141857.GG11695@bitfolk.com>
In-Reply-To: <20120608141857.GG11695@bitfolk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "olivier.hanesse" <olivier.hanesse@gmail.com>
Subject: Re: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.06.12 at 16:18, Andy Smith <andy@strugglers.net> wrote:
> I have two installs of Xen 4.0.1 on Debian squeeze dom0s that
> occasionally skew the time by 3000 seconds. It is always 3000
> seconds and it always affects all guests.
> 
> Depending on the kernels in the guests they will say:
> 
>     tp0 kernel: [9339489.266542] Clocksource tsc unstable (delta = 
> -2999660317697 ns)
> 
> or perhaps the kernel doesn't notice but ntpd does:
> 
>     ls0 ntpd[15009]: time reset -2999.683517 s
> 
> the point is it does affect all guests.

So it ought to come from Dom0 (you didn't say whether there
was anything in its logs, or anything interesting going on on it
at the point where the time change happens), or would have
to be "invented" strait in the hypervisor (you didn't say
anything about its log either).

Also you didn't clarify how frequent "occasionally" is, and
whether this is e.g. always happening after a certain amount
of uptime, at some specific time during the day, etc.

> These are Debian squeeze installs so using packaged versions of xen
> and kernel:
> 
> ii  linux-image-2.6.32-5-xen-amd64 2.6.32-45 Linux 2.6.32 for 64-bit PCs, Xen dom0 
> support
> ii  xen-hypervisor-4.0-amd64       4.0.1-4   The Xen Hypervisor on AMD64

Clearly we'd want to know if this also occurs with current -unstable.

> One of the hosts affected is:
> 
> CPU: Xeon 5410
> Motherboard: Supermicro X7DCL-i
> 
> The other is:
> 
> CPU: Xeon E5606
> Motherboard: SUpermicro X8DTN+
> 
> but I do have other servers with same hardware as both of these that
> aren't affected.

Which hints towards something specific to the configurations of
the two affected hosts, suggesting that it would be a good idea
to narrow down the differences between affected and non-
affected, physically identical machines...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:47:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd0T9-00061t-4M; Fri, 08 Jun 2012 14:47: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 1Sd0T7-00061o-Ga
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:47:17 +0000
Received: from [85.158.139.83:61749] by server-12.bemta-5.messagelabs.com id
	40/44-18374-47012DF4; Fri, 08 Jun 2012 14:47:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339166836!32568714!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8316 invoked from network); 8 Jun 2012 14:47:16 -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; 8 Jun 2012 14:47:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Jun 2012 15:48:48 +0100
Message-Id: <4FD22CBD0200007800088D05@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 08 Jun 2012 15:47:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <20120608141857.GG11695@bitfolk.com>
In-Reply-To: <20120608141857.GG11695@bitfolk.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "olivier.hanesse" <olivier.hanesse@gmail.com>
Subject: Re: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.06.12 at 16:18, Andy Smith <andy@strugglers.net> wrote:
> I have two installs of Xen 4.0.1 on Debian squeeze dom0s that
> occasionally skew the time by 3000 seconds. It is always 3000
> seconds and it always affects all guests.
> 
> Depending on the kernels in the guests they will say:
> 
>     tp0 kernel: [9339489.266542] Clocksource tsc unstable (delta = 
> -2999660317697 ns)
> 
> or perhaps the kernel doesn't notice but ntpd does:
> 
>     ls0 ntpd[15009]: time reset -2999.683517 s
> 
> the point is it does affect all guests.

So it ought to come from Dom0 (you didn't say whether there
was anything in its logs, or anything interesting going on on it
at the point where the time change happens), or would have
to be "invented" strait in the hypervisor (you didn't say
anything about its log either).

Also you didn't clarify how frequent "occasionally" is, and
whether this is e.g. always happening after a certain amount
of uptime, at some specific time during the day, etc.

> These are Debian squeeze installs so using packaged versions of xen
> and kernel:
> 
> ii  linux-image-2.6.32-5-xen-amd64 2.6.32-45 Linux 2.6.32 for 64-bit PCs, Xen dom0 
> support
> ii  xen-hypervisor-4.0-amd64       4.0.1-4   The Xen Hypervisor on AMD64

Clearly we'd want to know if this also occurs with current -unstable.

> One of the hosts affected is:
> 
> CPU: Xeon 5410
> Motherboard: Supermicro X7DCL-i
> 
> The other is:
> 
> CPU: Xeon E5606
> Motherboard: SUpermicro X8DTN+
> 
> but I do have other servers with same hardware as both of these that
> aren't affected.

Which hints towards something specific to the configurations of
the two affected hosts, suggesting that it would be a good idea
to narrow down the differences between affected and non-
affected, physically identical machines...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 14:56:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd0bu-0006Ba-5g; Fri, 08 Jun 2012 14:56:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Sd0bs-0006BV-Pp
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:56:20 +0000
Received: from [85.158.143.99:6916] by server-3.bemta-4.messagelabs.com id
	51/16-29237-49212DF4; Fri, 08 Jun 2012 14:56:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339167377!20752023!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27803 invoked from network); 8 Jun 2012 14:56:18 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:56:18 -0000
Received: by qcsc20 with SMTP id c20so1150404qcs.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 07:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Ft29Qus5XPhECaVN6wdbzMwPrS1fiSUSJ64xJiQQAq0=;
	b=eUyI9huP/RAuoq2TQEqmQy/4viVmUgg3cI2ll6rzCC48PR9UxErQNdlX0h8I0Pv+WE
	BFzky3RDND46OAdcwOu2SFdIaRHREllHqZIVF878SxSspfkf7NkGjp5ZWqbWfle62hzi
	S/ZmqABYwOQCmBWsZE60mnzOGlLZ7bHBggCzP+Qpge1jlY0pR3TwB0gaeHaiosU1IHkH
	/VcDLQkC0tpyydYYpL4A7p5GGaAqRxr40BEHbmkNCdAk2AxxLA2P1iwSmoQsD1FowE2r
	weOcnCaitR12w/7zOd+/aeLtCfW8mCXvPzFTTX9dJ0jRwsl15KJSxJVQ5rLQBDyw8qEj
	c3Ow==
MIME-Version: 1.0
Received: by 10.224.101.8 with SMTP id a8mr7575493qao.1.1339167376797; Fri, 08
	Jun 2012 07:56:16 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 07:56:16 -0700 (PDT)
In-Reply-To: <4FC8A41F.6040201@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8A41F.6040201@citrix.com>
Date: Fri, 8 Jun 2012 15:56:16 +0100
X-Google-Sender-Auth: zx53ayEkHEATuoitp7b6Nr78dVw
Message-ID: <CAFLBxZbWHPfFhyyrZQkODwNE+gKSiK93S-woTpATM4QJ1dj=ew@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian, ping?  I think Anthony's original patch (as well as his
follow-up) should both be applied.

 -George

On Fri, Jun 1, 2012 at 12:14 PM, Anthony PERARD
<anthony.perard@citrix.com> wrote:
> On 01/06/12 11:11, George Dunlap wrote:
>>
>> On 01/06/12 09:29, Ian Campbell wrote:
>>>
>>> > =A0On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>>>
>>>> >> =A0On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>>> >> =A0<George.Dunlap@eu.citrix.com> =A0 wrote:
>>>>>
>>>>> >>> =A0The strange thing is that there*is* =A0a pygrub in the right p=
lace,
>>>>> >>> so
>>>>>
>>>>> >>> =A0it appears that thefollowing line ($INSTALL_PYTHON_PROG) is
>>>>> >>> redundant?
>>>>
>>>> >> =A0It's seems that the right on the script are already set to 755 by
>>>> >> the
>>>> >> =A0setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>>>
>>> > =A0What is the conclusion here? Is the original patch correct and/or =
is
>>> > =A0there a subsequent additional fix?
>>
>> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
>> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
>> fixes the bug (only installed in $(DESTDIR).
>>
>> I think there is a redundant command in the Makefile as well, where
>> pygrub will be copied to $(DESTDIR)/foo twice. =A0That doesn't cause
>> incorrect behavior, but I would probably still consider it a bug.
>>
>> So the original patch is correct, but there is a subsequent fix.
>
>
> I'll send a patch that remove this extra line as the pygrub script is cop=
ied
> by setup.py.
>
> --
> Anthony PERARD
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 14:56:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:56:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd0bu-0006Ba-5g; Fri, 08 Jun 2012 14:56:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Sd0bs-0006BV-Pp
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:56:20 +0000
Received: from [85.158.143.99:6916] by server-3.bemta-4.messagelabs.com id
	51/16-29237-49212DF4; Fri, 08 Jun 2012 14:56:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339167377!20752023!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27803 invoked from network); 8 Jun 2012 14:56:18 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 14:56:18 -0000
Received: by qcsc20 with SMTP id c20so1150404qcs.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 07:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=Ft29Qus5XPhECaVN6wdbzMwPrS1fiSUSJ64xJiQQAq0=;
	b=eUyI9huP/RAuoq2TQEqmQy/4viVmUgg3cI2ll6rzCC48PR9UxErQNdlX0h8I0Pv+WE
	BFzky3RDND46OAdcwOu2SFdIaRHREllHqZIVF878SxSspfkf7NkGjp5ZWqbWfle62hzi
	S/ZmqABYwOQCmBWsZE60mnzOGlLZ7bHBggCzP+Qpge1jlY0pR3TwB0gaeHaiosU1IHkH
	/VcDLQkC0tpyydYYpL4A7p5GGaAqRxr40BEHbmkNCdAk2AxxLA2P1iwSmoQsD1FowE2r
	weOcnCaitR12w/7zOd+/aeLtCfW8mCXvPzFTTX9dJ0jRwsl15KJSxJVQ5rLQBDyw8qEj
	c3Ow==
MIME-Version: 1.0
Received: by 10.224.101.8 with SMTP id a8mr7575493qao.1.1339167376797; Fri, 08
	Jun 2012 07:56:16 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 07:56:16 -0700 (PDT)
In-Reply-To: <4FC8A41F.6040201@citrix.com>
References: <1338397005-7051-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZaVdyJ8RTBtHTLacrHa+BPew16jARTAXOZ-uC5L-0AFjg@mail.gmail.com>
	<CAJJyHjJkmqyp+f121durEp-UGUv3qVdGFKBsWJ_cDPrTVVm-kQ@mail.gmail.com>
	<1338539390.17466.26.camel@zakaz.uk.xensource.com>
	<4FC89556.7090502@eu.citrix.com> <4FC8A41F.6040201@citrix.com>
Date: Fri, 8 Jun 2012 15:56:16 +0100
X-Google-Sender-Auth: zx53ayEkHEATuoitp7b6Nr78dVw
Message-ID: <CAFLBxZbWHPfFhyyrZQkODwNE+gKSiK93S-woTpATM4QJ1dj=ew@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix pygrub 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian, ping?  I think Anthony's original patch (as well as his
follow-up) should both be applied.

 -George

On Fri, Jun 1, 2012 at 12:14 PM, Anthony PERARD
<anthony.perard@citrix.com> wrote:
> On 01/06/12 11:11, George Dunlap wrote:
>>
>> On 01/06/12 09:29, Ian Campbell wrote:
>>>
>>> > =A0On Thu, 2012-05-31 at 10:54 +0100, Anthony PERARD wrote:
>>>>
>>>> >> =A0On Thu, May 31, 2012 at 10:42 AM, George Dunlap
>>>> >> =A0<George.Dunlap@eu.citrix.com> =A0 wrote:
>>>>>
>>>>> >>> =A0The strange thing is that there*is* =A0a pygrub in the right p=
lace,
>>>>> >>> so
>>>>>
>>>>> >>> =A0it appears that thefollowing line ($INSTALL_PYTHON_PROG) is
>>>>> >>> redundant?
>>>>
>>>> >> =A0It's seems that the right on the script are already set to 755 by
>>>> >> the
>>>> >> =A0setup.py, so this $INSTALL_PYTHON_PROG line is probably an extra.
>>>
>>> > =A0What is the conclusion here? Is the original patch correct and/or =
is
>>> > =A0there a subsequent additional fix?
>>
>> There is a bug (pygrub is installed both in $(DESTDIR)/foo and
>> $(DESTDIR)/$(DESTDIR)/foo), and Anthony's first patch (AFAICT) correctly
>> fixes the bug (only installed in $(DESTDIR).
>>
>> I think there is a redundant command in the Makefile as well, where
>> pygrub will be copied to $(DESTDIR)/foo twice. =A0That doesn't cause
>> incorrect behavior, but I would probably still consider it a bug.
>>
>> So the original patch is correct, but there is a subsequent fix.
>
>
> I'll send a patch that remove this extra line as the pygrub script is cop=
ied
> by setup.py.
>
> --
> Anthony PERARD
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 14:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:57: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 1Sd0cT-0006Db-Ic; Fri, 08 Jun 2012 14:56:57 +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 1Sd0cS-0006DS-Nu
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:56:56 +0000
Received: from [85.158.143.35:50584] by server-3.bemta-4.messagelabs.com id
	20/F6-29237-8B212DF4; Fri, 08 Jun 2012 14:56:56 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339167414!11493710!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16244 invoked from network); 8 Jun 2012 14:56:55 -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;
	8 Jun 2012 14:56:55 -0000
Received: by qaeb19 with SMTP id b19so855392qae.11
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 07:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=GuiJjhlaYlkRyFSKmFDXN0BDzPtXMr6eJT3FbfmbEiw=;
	b=v87ZCm8p1gKabTChtrWZO0VoA6quBStcHAlK1sSTe2W8O+Sdjs86HGFlWqpclRNQrC
	zorqni/ewteND/OYPOYL0EQQQDZ2tK7XIpQFKHO7tDG3rXuMTQCP3q9n6GRlX5/B23gm
	hFaSi4PGalTbX1Ocxii5KAAW2ZmYCbxNZRNiiVU8pBwpad6aWGx8/hfjjK52rIWnYfCI
	klSYR8dPg7VPLWejDDhUXTFBR4tPv1/o934TIX/7HV4DVnaaSwlt/i4lEQvpMWWa/xI5
	iVdDcp0G20SCcNPxWtCrATOC2Oe+Cx0VZLkTTs29v7AQuZlICzgQCbpJBg8dzwA+p5wo
	RDFw==
MIME-Version: 1.0
Received: by 10.229.136.149 with SMTP id r21mr1945721qct.75.1339167414289;
	Fri, 08 Jun 2012 07:56:54 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 07:56:54 -0700 (PDT)
In-Reply-To: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
References: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
Date: Fri, 8 Jun 2012 15:56:54 +0100
X-Google-Sender-Auth: gwWNO6_7qFG_v8xecHW3aKKrFWQ
Message-ID: <CAFLBxZbaiDR1pVfYT17+yHOSrB3VjGYSq=UddwdoTnHCvXQjGw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub Makefile cleanup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 1, 2012 at 12:26 PM, Anthony PERARD
<anthony.perard@citrix.com> wrote:
> This patch removes the extra command `install pygrub` because this is alr=
eady
> done by the setup.py script.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

> ---
> This patch need to be applied after the patch named "Fix pygrub install."
>
> =A0tools/pygrub/Makefile | =A0 =A01 -
> =A01 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
> index af2b8a5..bd22dd4 100644
> --- a/tools/pygrub/Makefile
> +++ b/tools/pygrub/Makefile
> @@ -13,7 +13,6 @@ install: all
> =A0 =A0 =A0 =A0CC=3D"$(CC)" CFLAGS=3D"$(CFLAGS)" $(PYTHON) setup.py insta=
ll \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$(PYTHON_PREFIX_ARG) --root=3D"$(DESTDIR)"=
 \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--install-scripts=3D$(PRIVATE_BINDIR) --fo=
rce
> - =A0 =A0 =A0 $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BIND=
IR)/pygrub
> =A0 =A0 =A0 =A0$(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot
> =A0 =A0 =A0 =A0ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR)
>
> --
> Anthony PERARD
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 14:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 14:57: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 1Sd0cT-0006Db-Ic; Fri, 08 Jun 2012 14:56:57 +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 1Sd0cS-0006DS-Nu
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 14:56:56 +0000
Received: from [85.158.143.35:50584] by server-3.bemta-4.messagelabs.com id
	20/F6-29237-8B212DF4; Fri, 08 Jun 2012 14:56:56 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339167414!11493710!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16244 invoked from network); 8 Jun 2012 14:56:55 -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;
	8 Jun 2012 14:56:55 -0000
Received: by qaeb19 with SMTP id b19so855392qae.11
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 07:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=GuiJjhlaYlkRyFSKmFDXN0BDzPtXMr6eJT3FbfmbEiw=;
	b=v87ZCm8p1gKabTChtrWZO0VoA6quBStcHAlK1sSTe2W8O+Sdjs86HGFlWqpclRNQrC
	zorqni/ewteND/OYPOYL0EQQQDZ2tK7XIpQFKHO7tDG3rXuMTQCP3q9n6GRlX5/B23gm
	hFaSi4PGalTbX1Ocxii5KAAW2ZmYCbxNZRNiiVU8pBwpad6aWGx8/hfjjK52rIWnYfCI
	klSYR8dPg7VPLWejDDhUXTFBR4tPv1/o934TIX/7HV4DVnaaSwlt/i4lEQvpMWWa/xI5
	iVdDcp0G20SCcNPxWtCrATOC2Oe+Cx0VZLkTTs29v7AQuZlICzgQCbpJBg8dzwA+p5wo
	RDFw==
MIME-Version: 1.0
Received: by 10.229.136.149 with SMTP id r21mr1945721qct.75.1339167414289;
	Fri, 08 Jun 2012 07:56:54 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Fri, 8 Jun 2012 07:56:54 -0700 (PDT)
In-Reply-To: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
References: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
Date: Fri, 8 Jun 2012 15:56:54 +0100
X-Google-Sender-Auth: gwWNO6_7qFG_v8xecHW3aKKrFWQ
Message-ID: <CAFLBxZbaiDR1pVfYT17+yHOSrB3VjGYSq=UddwdoTnHCvXQjGw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub Makefile cleanup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 1, 2012 at 12:26 PM, Anthony PERARD
<anthony.perard@citrix.com> wrote:
> This patch removes the extra command `install pygrub` because this is alr=
eady
> done by the setup.py script.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

> ---
> This patch need to be applied after the patch named "Fix pygrub install."
>
> =A0tools/pygrub/Makefile | =A0 =A01 -
> =A01 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
> index af2b8a5..bd22dd4 100644
> --- a/tools/pygrub/Makefile
> +++ b/tools/pygrub/Makefile
> @@ -13,7 +13,6 @@ install: all
> =A0 =A0 =A0 =A0CC=3D"$(CC)" CFLAGS=3D"$(CFLAGS)" $(PYTHON) setup.py insta=
ll \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$(PYTHON_PREFIX_ARG) --root=3D"$(DESTDIR)"=
 \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--install-scripts=3D$(PRIVATE_BINDIR) --fo=
rce
> - =A0 =A0 =A0 $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BIND=
IR)/pygrub
> =A0 =A0 =A0 =A0$(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot
> =A0 =A0 =A0 =A0ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR)
>
> --
> Anthony PERARD
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 08 15:05:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0kI-0006ep-HX; Fri, 08 Jun 2012 15:05: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 1Sd0kH-0006ek-D7
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:05:01 +0000
Received: from [85.158.143.35:48731] by server-1.bemta-4.messagelabs.com id
	25/17-10042-C9412DF4; Fri, 08 Jun 2012 15:05:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339167900!14427630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10220 invoked from network); 8 Jun 2012 15:05:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15: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.213.0; Fri, 8 Jun 2012 16:04:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0kF-0000I5-QV; Fri, 08 Jun 2012 15:04:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0kF-0001A6-M9;
	Fri, 08 Jun 2012 16:04:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.5275.502193.738163@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:04:59 +0100
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FBE50C5.50609@amd.com>
References: <4FBE50C5.50609@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX to install qemu-upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX to install qemu-upstream"):
> Use PREFIX to install qemu-upstream.
> This installs docs and config files with same PREFIX
> as we do for the binary and firmware.

The effect of this that in the default build, lots of files move about
in dist/install, generally from dist/install/usr/local to
dist/install/usr.

Now our build tree output locations are perhaps haphazard but I don't
think changing them at this stage of the 4.2 release cycle is
appropriate.

We should revisit this when 4.3 development is open.

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 Jun 08 15:05:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0kI-0006ep-HX; Fri, 08 Jun 2012 15:05: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 1Sd0kH-0006ek-D7
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:05:01 +0000
Received: from [85.158.143.35:48731] by server-1.bemta-4.messagelabs.com id
	25/17-10042-C9412DF4; Fri, 08 Jun 2012 15:05:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339167900!14427630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10220 invoked from network); 8 Jun 2012 15:05:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15: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.213.0; Fri, 8 Jun 2012 16:04:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0kF-0000I5-QV; Fri, 08 Jun 2012 15:04:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0kF-0001A6-M9;
	Fri, 08 Jun 2012 16:04:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.5275.502193.738163@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:04:59 +0100
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FBE50C5.50609@amd.com>
References: <4FBE50C5.50609@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX to install qemu-upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX to install qemu-upstream"):
> Use PREFIX to install qemu-upstream.
> This installs docs and config files with same PREFIX
> as we do for the binary and firmware.

The effect of this that in the default build, lots of files move about
in dist/install, generally from dist/install/usr/local to
dist/install/usr.

Now our build tree output locations are perhaps haphazard but I don't
think changing them at this stage of the 4.2 release cycle is
appropriate.

We should revisit this when 4.3 development is open.

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 Jun 08 15:14:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0tU-0006oH-KV; Fri, 08 Jun 2012 15:14:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd0tS-0006oC-Px
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:14:30 +0000
Received: from [193.109.254.147:50893] by server-4.bemta-14.messagelabs.com id
	3E/FD-27598-6D612DF4; Fri, 08 Jun 2012 15:14:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339168469!8770872!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5461 invoked from network); 8 Jun 2012 15:14:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	8 Jun 2012 15:14:29 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78752715; Fri, 08 Jun 2012 17:14:28 +0200
Message-ID: <1339168462.5003.15.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 17:14:22 +0200
In-Reply-To: <20434.1587.672976.543703@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4151071263408265814=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4151071263408265814==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-6X4+HkgDMFRi3st5z7St"


--=-6X4+HkgDMFRi3st5z7St
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Arr=
ay type to the IDL"):
> > And make all the required infrastructure updates to enable this.
> >=20
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> You write `From: Dario' in the headers but it has a S-o-b from Ian.
>=20
Right.

> I think you should write
>   From: Ian Campbell <ian.campbell@citrix.com>
> if he actually wrote it.
>=20
Yes, this is by Ian...

> git-commit --author will do this for you and I think git-send-email
> will then generate appropriate output.
>=20
Oh, thanks... Do you happen to know what a mercurial equivalent for this
could be? :-P

> Can you point me at your git tree so I can easily clone it and see
> what the output from this new IDL generator looks like ?
>=20
Well, it's an hg tree + patchqueue that I don't have anywhere public. I
just put a fresh clone of xen-unstable plus this patch here (on a Citrix
NIS machine):

 ~dariof/Repositories/xen-unstable-array.hg

is that fine for now?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-6X4+HkgDMFRi3st5z7St
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SFs4ACgkQk4XaBE3IOsTPRgCfU5WtghX0MrR77/Koh9eyO0Om
eQEAoKAY4TLdNh6c02r3QeAdoYtTAqAu
=ykCa
-----END PGP SIGNATURE-----

--=-6X4+HkgDMFRi3st5z7St--



--===============4151071263408265814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4151071263408265814==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 15:14:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0tU-0006oH-KV; Fri, 08 Jun 2012 15:14:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd0tS-0006oC-Px
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:14:30 +0000
Received: from [193.109.254.147:50893] by server-4.bemta-14.messagelabs.com id
	3E/FD-27598-6D612DF4; Fri, 08 Jun 2012 15:14:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339168469!8770872!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5461 invoked from network); 8 Jun 2012 15:14:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	8 Jun 2012 15:14:29 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78752715; Fri, 08 Jun 2012 17:14:28 +0200
Message-ID: <1339168462.5003.15.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 17:14:22 +0200
In-Reply-To: <20434.1587.672976.543703@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4151071263408265814=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4151071263408265814==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-6X4+HkgDMFRi3st5z7St"


--=-6X4+HkgDMFRi3st5z7St
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Arr=
ay type to the IDL"):
> > And make all the required infrastructure updates to enable this.
> >=20
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> You write `From: Dario' in the headers but it has a S-o-b from Ian.
>=20
Right.

> I think you should write
>   From: Ian Campbell <ian.campbell@citrix.com>
> if he actually wrote it.
>=20
Yes, this is by Ian...

> git-commit --author will do this for you and I think git-send-email
> will then generate appropriate output.
>=20
Oh, thanks... Do you happen to know what a mercurial equivalent for this
could be? :-P

> Can you point me at your git tree so I can easily clone it and see
> what the output from this new IDL generator looks like ?
>=20
Well, it's an hg tree + patchqueue that I don't have anywhere public. I
just put a fresh clone of xen-unstable plus this patch here (on a Citrix
NIS machine):

 ~dariof/Repositories/xen-unstable-array.hg

is that fine for now?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-6X4+HkgDMFRi3st5z7St
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SFs4ACgkQk4XaBE3IOsTPRgCfU5WtghX0MrR77/Koh9eyO0Om
eQEAoKAY4TLdNh6c02r3QeAdoYtTAqAu
=ykCa
-----END PGP SIGNATURE-----

--=-6X4+HkgDMFRi3st5z7St--



--===============4151071263408265814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4151071263408265814==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 15:16:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0vU-0006st-GD; Fri, 08 Jun 2012 15:16: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 1Sd0vS-0006sa-VI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:16:35 +0000
Received: from [85.158.138.51:52124] by server-11.bemta-3.messagelabs.com id
	16/FA-28329-25712DF4; Fri, 08 Jun 2012 15:16:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339168592!25150319!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29103 invoked from network); 8 Jun 2012 15:16:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:16:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:16:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:16:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0vR-0000ND-3e; Fri, 08 Jun 2012 15:16:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0vR-00067B-2E;
	Fri, 08 Jun 2012 16:16:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.5969.44426.378773@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:16:33 +0100
To: Ian Campbell <ian.campbell@citrix.com>,
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20431.25137.851561.2815@mariner.uk.xensource.com>,
	<beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>,
	<20415.26017.916720.373727@mariner.uk.xensource.com>
References: <42b4ca522057ecf3bf48.1337937892@cosworth.uk.xensource.com>
	<20415.26017.916720.373727@mariner.uk.xensource.com>
	<beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
	<20431.25137.851561.2815@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not
	a	bzImage [and 2 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] libxc: do not "panic" if a kernel is not a bzImage"):
> Ian Campbell writes ("[PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> > libxc: do not "panic" if a kernel is not a bzImage.
> > 
> > Up until the point where we think this is a bzImage there is no point in
> > printing panicy messages -- some other loader will have a go (probably the
> > compressed ELF one)
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian Campbell writes ("[Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> libxc: do not "panic" if a kernel is not a bzImage.
> 
> Up until the point where we think this is a bzImage there is no point in
> printing panicy messages -- some other loader will have a go (probably the
> compressed ELF one)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 04b4bfaaed2f -r beca28fe812f tools/libxc/xc_dom_bzimageloader.c

Ian Jackson writes ("Re: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> Ian Campbell writes ("[PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> > libxc: do not "panic" if a kernel is not a bzImage.
> > 
> > Up until the point where we think this is a bzImage there is no point in
> > printing panicy messages -- some other loader will have a go (probably the
> > compressed ELF one)
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:16:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0vU-0006st-GD; Fri, 08 Jun 2012 15:16: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 1Sd0vS-0006sa-VI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:16:35 +0000
Received: from [85.158.138.51:52124] by server-11.bemta-3.messagelabs.com id
	16/FA-28329-25712DF4; Fri, 08 Jun 2012 15:16:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339168592!25150319!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29103 invoked from network); 8 Jun 2012 15:16:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:16:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:16:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:16:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0vR-0000ND-3e; Fri, 08 Jun 2012 15:16:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0vR-00067B-2E;
	Fri, 08 Jun 2012 16:16:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.5969.44426.378773@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:16:33 +0100
To: Ian Campbell <ian.campbell@citrix.com>,
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20431.25137.851561.2815@mariner.uk.xensource.com>,
	<beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>,
	<20415.26017.916720.373727@mariner.uk.xensource.com>
References: <42b4ca522057ecf3bf48.1337937892@cosworth.uk.xensource.com>
	<20415.26017.916720.373727@mariner.uk.xensource.com>
	<beca28fe812ffd3c8e50.1338988918@cosworth.uk.xensource.com>
	<20431.25137.851561.2815@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not
	a	bzImage [and 2 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] libxc: do not "panic" if a kernel is not a bzImage"):
> Ian Campbell writes ("[PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> > libxc: do not "panic" if a kernel is not a bzImage.
> > 
> > Up until the point where we think this is a bzImage there is no point in
> > printing panicy messages -- some other loader will have a go (probably the
> > compressed ELF one)
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian Campbell writes ("[Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> libxc: do not "panic" if a kernel is not a bzImage.
> 
> Up until the point where we think this is a bzImage there is no point in
> printing panicy messages -- some other loader will have a go (probably the
> compressed ELF one)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 04b4bfaaed2f -r beca28fe812f tools/libxc/xc_dom_bzimageloader.c

Ian Jackson writes ("Re: [Xen-devel] [PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> Ian Campbell writes ("[PATCH] libxc: do not "panic" if a kernel is not a bzImage"):
> > libxc: do not "panic" if a kernel is not a bzImage.
> > 
> > Up until the point where we think this is a bzImage there is no point in
> > printing panicy messages -- some other loader will have a go (probably the
> > compressed ELF one)
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:16:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0vT-0006sc-4i; Fri, 08 Jun 2012 15:16: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 1Sd0vR-0006sU-Tx
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:16:34 +0000
Received: from [85.158.138.51:52061] by server-6.bemta-3.messagelabs.com id
	2D/CA-05063-15712DF4; Fri, 08 Jun 2012 15:16:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339168592!25150319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29079 invoked from network); 8 Jun 2012 15:16:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:16:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:16:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0vP-0000NA-EU; Fri, 08 Jun 2012 15:16:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0vP-00066y-Cg;
	Fri, 08 Jun 2012 16:16:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.5967.152902.104636@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:16:31 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1337624654-7044-1-git-send-email-anthony.perard@citrix.com>
References: <1337624654-7044-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Store VNC passwd in xenstore with
	QEMU	upstream.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Store VNC passwd in xenstore with QEMU upstream."):
> This patch stores the VNC password in xenstore after it has been sent to QEMU.
> This will be usefull with the vncviewer command with --autopass.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:16:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0vT-0006sc-4i; Fri, 08 Jun 2012 15:16: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 1Sd0vR-0006sU-Tx
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:16:34 +0000
Received: from [85.158.138.51:52061] by server-6.bemta-3.messagelabs.com id
	2D/CA-05063-15712DF4; Fri, 08 Jun 2012 15:16:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339168592!25150319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29079 invoked from network); 8 Jun 2012 15:16:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:16:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:16:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0vP-0000NA-EU; Fri, 08 Jun 2012 15:16:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0vP-00066y-Cg;
	Fri, 08 Jun 2012 16:16:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.5967.152902.104636@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:16:31 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1337624654-7044-1-git-send-email-anthony.perard@citrix.com>
References: <1337624654-7044-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Store VNC passwd in xenstore with
	QEMU	upstream.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl: Store VNC passwd in xenstore with QEMU upstream."):
> This patch stores the VNC password in xenstore after it has been sent to QEMU.
> This will be usefull with the vncviewer command with --autopass.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:17:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:17: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 1Sd0wH-00070f-4Z; Fri, 08 Jun 2012 15:17:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd0wF-00070K-TE
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:17:24 +0000
Received: from [85.158.143.99:9466] by server-2.bemta-4.messagelabs.com id
	89/E1-17938-38712DF4; Fri, 08 Jun 2012 15:17:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339168641!24919512!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9915 invoked from network); 8 Jun 2012 15:17:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:17:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:17:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0wC-0000Nj-PJ; Fri, 08 Jun 2012 15:17:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0wC-00067M-OP;
	Fri, 08 Jun 2012 16:17:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.6016.731308.637972@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:17:20 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339168462.5003.15.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > git-commit --author will do this for you and I think git-send-email
> > will then generate appropriate output.
> 
> Oh, thanks... Do you happen to know what a mercurial equivalent for this
> could be? :-P

hg ci -u

> > Can you point me at your git tree so I can easily clone it and see
> > what the output from this new IDL generator looks like ?
> 
> Well, it's an hg tree + patchqueue that I don't have anywhere public. I
> just put a fresh clone of xen-unstable plus this patch here (on a Citrix
> NIS machine):
> 
>  ~dariof/Repositories/xen-unstable-array.hg
> 
> is that fine for now?

Thanks, that's great.  I'll take a look.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:17:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:17: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 1Sd0wH-00070f-4Z; Fri, 08 Jun 2012 15:17:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd0wF-00070K-TE
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:17:24 +0000
Received: from [85.158.143.99:9466] by server-2.bemta-4.messagelabs.com id
	89/E1-17938-38712DF4; Fri, 08 Jun 2012 15:17:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339168641!24919512!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9915 invoked from network); 8 Jun 2012 15:17:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:17:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:17:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd0wC-0000Nj-PJ; Fri, 08 Jun 2012 15:17:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd0wC-00067M-OP;
	Fri, 08 Jun 2012 16:17:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.6016.731308.637972@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:17:20 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339168462.5003.15.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > git-commit --author will do this for you and I think git-send-email
> > will then generate appropriate output.
> 
> Oh, thanks... Do you happen to know what a mercurial equivalent for this
> could be? :-P

hg ci -u

> > Can you point me at your git tree so I can easily clone it and see
> > what the output from this new IDL generator looks like ?
> 
> Well, it's an hg tree + patchqueue that I don't have anywhere public. I
> just put a fresh clone of xen-unstable plus this patch here (on a Citrix
> NIS machine):
> 
>  ~dariof/Repositories/xen-unstable-array.hg
> 
> is that fine for now?

Thanks, that's great.  I'll take a look.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0y3-0007EL-Kz; Fri, 08 Jun 2012 15:19:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd0y2-0007ED-84
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:19:14 +0000
Received: from [85.158.143.99:22039] by server-2.bemta-4.messagelabs.com id
	C9/84-17938-1F712DF4; Fri, 08 Jun 2012 15:19:13 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339168752!26673095!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23578 invoked from network); 8 Jun 2012 15:19:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-216.messagelabs.com with SMTP;
	8 Jun 2012 15:19:12 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78752849; Fri, 08 Jun 2012 17:19:12 +0200
Message-ID: <1339168746.5003.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 17:19:06 +0200
In-Reply-To: <20434.1446.507811.744249@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
 documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0434216109526874126=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0434216109526874126==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-urQqpiHinmrJfTw2X2Vr"


--=-urQqpiHinmrJfTw2X2Vr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 15:01 +0100, Ian Jackson wrote:
> > Right, that is of couse an option, and I thought about going that way
> > for quite a while. However, what I think is best for libxl is to provid=
e
> > a set of building blocks for its user to be able to implement the actua=
l
> > heuristics.
>=20
> The difficulty with this is that this is supposedly becoming a stable
> API.  If we change the approach later, we may want to change the API.
> Do we know clearly enough what building blocks are needed and what
> they should be like ?
>=20
No, you all are right, not yet... More investigation is needed here and
it is not now the moment to do it.

> > Doing it the other way, i.e., one big function doing everything, would
> > mean that as soon as we want to change or improve the placement
> > heuristics, we need to modify the behaviour of that API call, which I
> > think it is suboptimal.
>=20
> If we have a function whose documented behaviour is `try to do a
> roughly optimal thing' then improving its optimisation is not a change
> to the API semantics.
>=20
> Specifically, existing code then will, when upgraded to a newer libxl,
> behaviour differently - better, we hope.  Is that not the intent ?
>=20
It is. I'm changing this all into something like "when you do not say
anything, libxl will place the domain `sensibly`, +/- as xend was
doing". We'll then add all the necessary interface and API in place
during 4.3.

> > So, like it is right now, the actual heuristics is implemented in xl, o=
n
> > top of these placement candidate generation and manipulation facilities=
,
> > which I finally decided it was the way I liked this whole thing
> > most. :-)
>=20
> So how much of the code currently in libxl should be reproduced in
> (say) libvirt ?
>=20
Again, I agree. Let's leave this for now, but I'll definitely
investigate this later.

Thanks a lot for looking into this, :-)
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-urQqpiHinmrJfTw2X2Vr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SF+oACgkQk4XaBE3IOsRmmACfbhgNqVU1jo7/rqmfKUwqAdz3
OfoAnjDFKkinwGSgjXAplcKTXfQQRnX4
=m1O0
-----END PGP SIGNATURE-----

--=-urQqpiHinmrJfTw2X2Vr--



--===============0434216109526874126==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0434216109526874126==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 15:19:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd0y3-0007EL-Kz; Fri, 08 Jun 2012 15:19:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd0y2-0007ED-84
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:19:14 +0000
Received: from [85.158.143.99:22039] by server-2.bemta-4.messagelabs.com id
	C9/84-17938-1F712DF4; Fri, 08 Jun 2012 15:19:13 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339168752!26673095!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23578 invoked from network); 8 Jun 2012 15:19:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-216.messagelabs.com with SMTP;
	8 Jun 2012 15:19:12 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78752849; Fri, 08 Jun 2012 17:19:12 +0200
Message-ID: <1339168746.5003.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 17:19:06 +0200
In-Reply-To: <20434.1446.507811.744249@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<e9b2e81e4afbde8c3ceb.1338466276@Solace>
	<20423.35189.904831.64711@mariner.uk.xensource.com>
	<1338478895.15014.60.camel@Solace>
	<20434.1446.507811.744249@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement
 documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0434216109526874126=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0434216109526874126==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-urQqpiHinmrJfTw2X2Vr"


--=-urQqpiHinmrJfTw2X2Vr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 15:01 +0100, Ian Jackson wrote:
> > Right, that is of couse an option, and I thought about going that way
> > for quite a while. However, what I think is best for libxl is to provid=
e
> > a set of building blocks for its user to be able to implement the actua=
l
> > heuristics.
>=20
> The difficulty with this is that this is supposedly becoming a stable
> API.  If we change the approach later, we may want to change the API.
> Do we know clearly enough what building blocks are needed and what
> they should be like ?
>=20
No, you all are right, not yet... More investigation is needed here and
it is not now the moment to do it.

> > Doing it the other way, i.e., one big function doing everything, would
> > mean that as soon as we want to change or improve the placement
> > heuristics, we need to modify the behaviour of that API call, which I
> > think it is suboptimal.
>=20
> If we have a function whose documented behaviour is `try to do a
> roughly optimal thing' then improving its optimisation is not a change
> to the API semantics.
>=20
> Specifically, existing code then will, when upgraded to a newer libxl,
> behaviour differently - better, we hope.  Is that not the intent ?
>=20
It is. I'm changing this all into something like "when you do not say
anything, libxl will place the domain `sensibly`, +/- as xend was
doing". We'll then add all the necessary interface and API in place
during 4.3.

> > So, like it is right now, the actual heuristics is implemented in xl, o=
n
> > top of these placement candidate generation and manipulation facilities=
,
> > which I finally decided it was the way I liked this whole thing
> > most. :-)
>=20
> So how much of the code currently in libxl should be reproduced in
> (say) libvirt ?
>=20
Again, I agree. Let's leave this for now, but I'll definitely
investigate this later.

Thanks a lot for looking into this, :-)
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-urQqpiHinmrJfTw2X2Vr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SF+oACgkQk4XaBE3IOsRmmACfbhgNqVU1jo7/rqmfKUwqAdz3
OfoAnjDFKkinwGSgjXAplcKTXfQQRnX4
=m1O0
-----END PGP SIGNATURE-----

--=-urQqpiHinmrJfTw2X2Vr--



--===============0434216109526874126==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0434216109526874126==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 15:22:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:22: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 1Sd11H-0007UN-AE; Fri, 08 Jun 2012 15:22: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 1Sd11F-0007UH-SM
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:22:33 +0000
Received: from [85.158.138.51:63179] by server-8.bemta-3.messagelabs.com id
	E2/F4-22118-9B812DF4; Fri, 08 Jun 2012 15:22:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339168952!31461348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13884 invoked from network); 8 Jun 2012 15:22:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:22:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:22:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:22:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd11E-0000PX-2U; Fri, 08 Jun 2012 15:22:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd11E-00068d-09;
	Fri, 08 Jun 2012 16:22:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.6327.981198.867739@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:22:31 +0100
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FB3C94A.2030603@amd.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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

Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
> On 05/11/12 16:13, Roger Pau Monne wrote:
> > NetBSD doesn't have a gntdev, so libvchan is unable to build due to
> > the lack of the header files gntalloc.h.

>   Acked-by: Christoph Egger <Christoph.Egger@amd.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:22:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:22: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 1Sd11H-0007UN-AE; Fri, 08 Jun 2012 15:22: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 1Sd11F-0007UH-SM
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:22:33 +0000
Received: from [85.158.138.51:63179] by server-8.bemta-3.messagelabs.com id
	E2/F4-22118-9B812DF4; Fri, 08 Jun 2012 15:22:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339168952!31461348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13884 invoked from network); 8 Jun 2012 15:22:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:22:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:22:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:22:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd11E-0000PX-2U; Fri, 08 Jun 2012 15:22:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd11E-00068d-09;
	Fri, 08 Jun 2012 16:22:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.6327.981198.867739@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:22:31 +0100
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FB3C94A.2030603@amd.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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

Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
> On 05/11/12 16:13, Roger Pau Monne wrote:
> > NetBSD doesn't have a gntdev, so libvchan is unable to build due to
> > the lack of the header files gntalloc.h.

>   Acked-by: Christoph Egger <Christoph.Egger@amd.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:22:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd11U-0007Vi-N6; Fri, 08 Jun 2012 15:22: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 1Sd11T-0007VN-2X
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:22:47 +0000
Received: from [85.158.143.99:2806] by server-2.bemta-4.messagelabs.com id
	51/B9-17938-6C812DF4; Fri, 08 Jun 2012 15:22:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339168965!26673627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2763 invoked from network); 8 Jun 2012 15:22:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:22:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:22:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd11R-0000Pe-Bc; Fri, 08 Jun 2012 15:22:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd11R-00068h-AA;
	Fri, 08 Jun 2012 16:22:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.6341.292944.748723@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:22:45 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1336745632-28158-4-git-send-email-roger.pau@citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-4-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES
	and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
> Parse those options correctly, since the "+=" operator is not valid.
> Also added CPPFLAGS, so headers checks don't give strange results.
...
>  CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
> +CPPFLAGS="$CFLAGS"

Surely that can't be right.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:22:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd11U-0007Vi-N6; Fri, 08 Jun 2012 15:22: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 1Sd11T-0007VN-2X
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:22:47 +0000
Received: from [85.158.143.99:2806] by server-2.bemta-4.messagelabs.com id
	51/B9-17938-6C812DF4; Fri, 08 Jun 2012 15:22:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339168965!26673627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2763 invoked from network); 8 Jun 2012 15:22:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12913935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:22:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:22:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd11R-0000Pe-Bc; Fri, 08 Jun 2012 15:22:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd11R-00068h-AA;
	Fri, 08 Jun 2012 16:22:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.6341.292944.748723@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:22:45 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1336745632-28158-4-git-send-email-roger.pau@citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-4-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES
	and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
> Parse those options correctly, since the "+=" operator is not valid.
> Also added CPPFLAGS, so headers checks don't give strange results.
...
>  CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
> +CPPFLAGS="$CFLAGS"

Surely that can't be right.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:35:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:35: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 1Sd1Da-0007xL-VW; Fri, 08 Jun 2012 15:35:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1DY-0007w3-Qd
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:35:17 +0000
Received: from [193.109.254.147:45520] by server-1.bemta-14.messagelabs.com id
	27/3D-08067-3BB12DF4; Fri, 08 Jun 2012 15:35:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339169714!8874147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21682 invoked from network); 8 Jun 2012 15:35:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:35:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:35:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1DV-0000W7-FQ; Fri, 08 Jun 2012 15:35:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1DV-0005wl-9R;
	Fri, 08 Jun 2012 16:35:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.7083.345990.653451@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:35:07 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1337168683.27824.92.camel@zakaz.uk.xensource.com>
References: <db614e92faf743e20b3f.1337096977@kodo2>
	<4FB29D6F0200007800083E81@nat28.tlf.novell.com>
	<4FB28295.8020905@eu.citrix.com>
	<1337156497.27824.2.camel@zakaz.uk.xensource.com>
	<4FB3886A020000780008402F@nat28.tlf.novell.com>
	<1337159777.27824.39.camel@zakaz.uk.xensource.com>
	<4FB394AE0200007800084098@nat28.tlf.novell.com>
	<1337162232.27824.55.camel@zakaz.uk.xensource.com>
	<4FB38634.7050807@eu.citrix.com>
	<1337168683.27824.92.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap driver"):
> On Wed, 2012-05-16 at 11:49 +0100, George Dunlap wrote:
> > On 16/05/12 10:57, Ian Campbell wrote:
> > >>> The blktap detection code is necessarily OS-specific. I previously
> > >>> discounted it because of the possibility of a race between the
> > >>> completion of modprobe and the driver actually registering enough for
> > >>> detection to succeed. Maybe I was too pessimistic or someone has a
> > >>> bright idea?
> > >> modprobe only exits when the driver's init function completed,
> > >> at which point the driver can be expected to be in a usable state.
> > > OK, so maybe that works then.
> > So what's the plan?  Options seem to be:
> > 1. Put this on the blocker list, so it definitely gets done before release
> > 2. Accept the patch that started this thread (or a version of it), and 
> > put "do it right" on the "nice-to-have" list.  I can do it if I get a 
> > chance.
> > 3. Someone can volunteer who can prioritize it.
> 
> My preference, in decreasing order would be 2, 3, 1.

AFAICT this is still outstanding.  Have we made a decision ?

I'm inclined to throw all of these best-effort modprobes into 4.2 and
try to sort out something saner (if possible) in 4.3.

Ian: can you make sure this is on the 4.2 TODO ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:35:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:35: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 1Sd1Da-0007xL-VW; Fri, 08 Jun 2012 15:35:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1DY-0007w3-Qd
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:35:17 +0000
Received: from [193.109.254.147:45520] by server-1.bemta-14.messagelabs.com id
	27/3D-08067-3BB12DF4; Fri, 08 Jun 2012 15:35:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339169714!8874147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21682 invoked from network); 8 Jun 2012 15:35:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:35:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:35:13 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1DV-0000W7-FQ; Fri, 08 Jun 2012 15:35:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1DV-0005wl-9R;
	Fri, 08 Jun 2012 16:35:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.7083.345990.653451@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:35:07 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1337168683.27824.92.camel@zakaz.uk.xensource.com>
References: <db614e92faf743e20b3f.1337096977@kodo2>
	<4FB29D6F0200007800083E81@nat28.tlf.novell.com>
	<4FB28295.8020905@eu.citrix.com>
	<1337156497.27824.2.camel@zakaz.uk.xensource.com>
	<4FB3886A020000780008402F@nat28.tlf.novell.com>
	<1337159777.27824.39.camel@zakaz.uk.xensource.com>
	<4FB394AE0200007800084098@nat28.tlf.novell.com>
	<1337162232.27824.55.camel@zakaz.uk.xensource.com>
	<4FB38634.7050807@eu.citrix.com>
	<1337168683.27824.92.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap driver"):
> On Wed, 2012-05-16 at 11:49 +0100, George Dunlap wrote:
> > On 16/05/12 10:57, Ian Campbell wrote:
> > >>> The blktap detection code is necessarily OS-specific. I previously
> > >>> discounted it because of the possibility of a race between the
> > >>> completion of modprobe and the driver actually registering enough for
> > >>> detection to succeed. Maybe I was too pessimistic or someone has a
> > >>> bright idea?
> > >> modprobe only exits when the driver's init function completed,
> > >> at which point the driver can be expected to be in a usable state.
> > > OK, so maybe that works then.
> > So what's the plan?  Options seem to be:
> > 1. Put this on the blocker list, so it definitely gets done before release
> > 2. Accept the patch that started this thread (or a version of it), and 
> > put "do it right" on the "nice-to-have" list.  I can do it if I get a 
> > chance.
> > 3. Someone can volunteer who can prioritize it.
> 
> My preference, in decreasing order would be 2, 3, 1.

AFAICT this is still outstanding.  Have we made a decision ?

I'm inclined to throw all of these best-effort modprobes into 4.2 and
try to sort out something saner (if possible) in 4.3.

Ian: can you make sure this is on the 4.2 TODO ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:37:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd1Fe-00083Z-He; Fri, 08 Jun 2012 15: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.Jackson@eu.citrix.com>) id 1Sd1Fd-00083S-2Q
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:37:25 +0000
Received: from [85.158.138.51:14677] by server-6.bemta-3.messagelabs.com id
	D4/68-05063-43C12DF4; Fri, 08 Jun 2012 15:37:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339169843!31550776!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2478 invoked from network); 8 Jun 2012 15:37:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:37:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:37:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1Fb-0000Wy-3L; Fri, 08 Jun 2012 15:37:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1Fa-0005x2-VI;
	Fri, 08 Jun 2012 16:37:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.7215.399396.585324@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:37:19 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339168462.5003.15.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > Can you point me at your git tree so I can easily clone it and see
> > what the output from this new IDL generator looks like ?
> 
> Well, it's an hg tree + patchqueue that I don't have anywhere public. I
> just put a fresh clone of xen-unstable plus this patch here (on a Citrix
> NIS machine):
> 
>  ~dariof/Repositories/xen-unstable-array.hg
> 
> is that fine for now?

Uh, can you please push your whole queue there ?  In order to review
the IDL generator output I naturally need a user of the new array
type.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:37:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd1Fe-00083Z-He; Fri, 08 Jun 2012 15: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.Jackson@eu.citrix.com>) id 1Sd1Fd-00083S-2Q
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:37:25 +0000
Received: from [85.158.138.51:14677] by server-6.bemta-3.messagelabs.com id
	D4/68-05063-43C12DF4; Fri, 08 Jun 2012 15:37:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339169843!31550776!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2478 invoked from network); 8 Jun 2012 15:37:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:37:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:37:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1Fb-0000Wy-3L; Fri, 08 Jun 2012 15:37:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1Fa-0005x2-VI;
	Fri, 08 Jun 2012 16:37:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.7215.399396.585324@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:37:19 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339168462.5003.15.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > Can you point me at your git tree so I can easily clone it and see
> > what the output from this new IDL generator looks like ?
> 
> Well, it's an hg tree + patchqueue that I don't have anywhere public. I
> just put a fresh clone of xen-unstable plus this patch here (on a Citrix
> NIS machine):
> 
>  ~dariof/Repositories/xen-unstable-array.hg
> 
> is that fine for now?

Uh, can you please push your whole queue there ?  In order to review
the IDL generator output I naturally need a user of the new array
type.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:38:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd1GB-00086C-Ub; Fri, 08 Jun 2012 15:37: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 1Sd1GA-00085x-3Y
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 15:37:58 +0000
Received: from [193.109.254.147:3849] by server-3.bemta-14.messagelabs.com id
	FD/18-05653-55C12DF4; Fri, 08 Jun 2012 15:37:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339169875!8834134!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4MDAwMg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11810 invoked from network); 8 Jun 2012 15:37:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 15:37:56 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q58Fbp6e001305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Jun 2012 15:37:52 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
	q58Fbo8x014080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Jun 2012 15:37:51 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
	q58Fbo7f031541; Fri, 8 Jun 2012 10:37:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Jun 2012 08:37:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D9AE44029B; Fri,  8 Jun 2012 11:30:52 -0400 (EDT)
Date: Fri, 8 Jun 2012 11:30:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: geaaru <geaaru@gmail.com>
Message-ID: <20120608153052.GE13668@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
	<1339102908.2434.3.camel@Nokia-N900>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339102908.2434.3.camel@Nokia-N900>
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, ben@guthro.net
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 11:01:48PM +0200, geaaru wrote:
> Hi at all,
> 
> I confirm this issue on gentoo with kernel 3.4.0.

Can you try cherry-pick these two patches from stable/for-x86-3.3:
4f93aa02acd0e34806d4ac9c3a700bb5d040eab6

f474007a0761d0ecb6b84ceaf4f97f4f1de92038

and revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1.

The easiest way is to do this:
git clone  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
cd xen
git cherry-pick 4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
git cherry-pick f474007a0761d0ecb6b84ceaf4f97f4f1de92038
git revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1

and then build the kernel and install it and such.

[What you are doing is removing the band-aid for the PAT
issue and adding in code that allows PAT to work]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:38:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd1GB-00086C-Ub; Fri, 08 Jun 2012 15:37: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 1Sd1GA-00085x-3Y
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 15:37:58 +0000
Received: from [193.109.254.147:3849] by server-3.bemta-14.messagelabs.com id
	FD/18-05653-55C12DF4; Fri, 08 Jun 2012 15:37:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339169875!8834134!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4MDAwMg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11810 invoked from network); 8 Jun 2012 15:37:56 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 15:37:56 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q58Fbp6e001305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Jun 2012 15:37:52 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
	q58Fbo8x014080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Jun 2012 15:37:51 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
	q58Fbo7f031541; Fri, 8 Jun 2012 10:37:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Jun 2012 08:37:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D9AE44029B; Fri,  8 Jun 2012 11:30:52 -0400 (EDT)
Date: Fri, 8 Jun 2012 11:30:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: geaaru <geaaru@gmail.com>
Message-ID: <20120608153052.GE13668@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
	<1339102908.2434.3.camel@Nokia-N900>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339102908.2434.3.camel@Nokia-N900>
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, ben@guthro.net
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 11:01:48PM +0200, geaaru wrote:
> Hi at all,
> 
> I confirm this issue on gentoo with kernel 3.4.0.

Can you try cherry-pick these two patches from stable/for-x86-3.3:
4f93aa02acd0e34806d4ac9c3a700bb5d040eab6

f474007a0761d0ecb6b84ceaf4f97f4f1de92038

and revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1.

The easiest way is to do this:
git clone  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
cd xen
git cherry-pick 4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
git cherry-pick f474007a0761d0ecb6b84ceaf4f97f4f1de92038
git revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1

and then build the kernel and install it and such.

[What you are doing is removing the band-aid for the PAT
issue and adding in code that allows PAT to work]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:41:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd1Jj-0008KP-I3; Fri, 08 Jun 2012 15:41:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1Ji-0008KF-7C
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 15:41:38 +0000
Received: from [193.109.254.147:41578] by server-12.bemta-14.messagelabs.com
	id EB/1D-12998-13D12DF4; Fri, 08 Jun 2012 15:41:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339170097!8775985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 499 invoked from network); 8 Jun 2012 15:41:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:41:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914377"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:41:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:41:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1Jg-0000aT-BB; Fri, 08 Jun 2012 15:41:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1Jg-00015O-9a;
	Fri, 08 Jun 2012 16:41:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.7472.210383.755782@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:41:36 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1337153677.3891.60.camel@dagon.hellion.org.uk>
References: <c034634fda0e1d96768d.1337142981@nehalem1>
	<1337153677.3891.60.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Correct typo introduced by cs25334
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Correct typo introduced by cs25334"):
> On Wed, 2012-05-16 at 05:36 +0100, Juergen Gross wrote:
> > Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
> 
> Oops, thanks!
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:41:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd1Jj-0008KP-I3; Fri, 08 Jun 2012 15:41:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1Ji-0008KF-7C
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 15:41:38 +0000
Received: from [193.109.254.147:41578] by server-12.bemta-14.messagelabs.com
	id EB/1D-12998-13D12DF4; Fri, 08 Jun 2012 15:41:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339170097!8775985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 499 invoked from network); 8 Jun 2012 15:41:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:41:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914377"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:41:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:41:36 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1Jg-0000aT-BB; Fri, 08 Jun 2012 15:41:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1Jg-00015O-9a;
	Fri, 08 Jun 2012 16:41:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.7472.210383.755782@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:41:36 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1337153677.3891.60.camel@dagon.hellion.org.uk>
References: <c034634fda0e1d96768d.1337142981@nehalem1>
	<1337153677.3891.60.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Correct typo introduced by cs25334
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Correct typo introduced by cs25334"):
> On Wed, 2012-05-16 at 05:36 +0100, Juergen Gross wrote:
> > Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
> 
> Oops, thanks!
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:52:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:52: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 1Sd1Tv-0000Jn-FR; Fri, 08 Jun 2012 15:52:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd1Tt-0000Jg-N0
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:52:09 +0000
Received: from [193.109.254.147:28883] by server-10.bemta-14.messagelabs.com
	id F2/C0-25709-9AF12DF4; Fri, 08 Jun 2012 15:52:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339170727!1938355!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10225 invoked from network); 8 Jun 2012 15:52:07 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	8 Jun 2012 15:52:07 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78753605; Fri, 08 Jun 2012 17:52:07 +0200
Message-ID: <1339170721.5003.22.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 17:52:01 +0200
In-Reply-To: <20434.7215.399396.585324@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<20434.7215.399396.585324@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1734311419590705741=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1734311419590705741==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8aOvHuS/wi9YO7RAlfm7"


--=-8aOvHuS/wi9YO7RAlfm7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 16:37 +0100, Ian Jackson wrote:
> > Well, it's an hg tree + patchqueue that I don't have anywhere public. I
> > just put a fresh clone of xen-unstable plus this patch here (on a Citri=
x
> > NIS machine):
> >=20
> >  ~dariof/Repositories/xen-unstable-array.hg
> >=20
> > is that fine for now?
>=20
> Uh, can you please push your whole queue there ?  In order to review
> the IDL generator output I naturally need a user of the new array
> type.
>=20
Gah, right! The whole queue is under deep restructuring, but I should
have pushed the patch that constitutes the direct user of the new
type...

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-8aOvHuS/wi9YO7RAlfm7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SH6EACgkQk4XaBE3IOsS70QCfTKrhnhjG5Nx/iGUUy/ZUu/2g
sG0An0kRS+VIYOmTEv2lkF+7AILrRuWc
=shA9
-----END PGP SIGNATURE-----

--=-8aOvHuS/wi9YO7RAlfm7--



--===============1734311419590705741==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1734311419590705741==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 15:52:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15:52: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 1Sd1Tv-0000Jn-FR; Fri, 08 Jun 2012 15:52:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sd1Tt-0000Jg-N0
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:52:09 +0000
Received: from [193.109.254.147:28883] by server-10.bemta-14.messagelabs.com
	id F2/C0-25709-9AF12DF4; Fri, 08 Jun 2012 15:52:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339170727!1938355!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10225 invoked from network); 8 Jun 2012 15:52:07 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	8 Jun 2012 15:52:07 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78753605; Fri, 08 Jun 2012 17:52:07 +0200
Message-ID: <1339170721.5003.22.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 08 Jun 2012 17:52:01 +0200
In-Reply-To: <20434.7215.399396.585324@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<20434.7215.399396.585324@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1734311419590705741=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1734311419590705741==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-8aOvHuS/wi9YO7RAlfm7"


--=-8aOvHuS/wi9YO7RAlfm7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-08 at 16:37 +0100, Ian Jackson wrote:
> > Well, it's an hg tree + patchqueue that I don't have anywhere public. I
> > just put a fresh clone of xen-unstable plus this patch here (on a Citri=
x
> > NIS machine):
> >=20
> >  ~dariof/Repositories/xen-unstable-array.hg
> >=20
> > is that fine for now?
>=20
> Uh, can you please push your whole queue there ?  In order to review
> the IDL generator output I naturally need a user of the new array
> type.
>=20
Gah, right! The whole queue is under deep restructuring, but I should
have pushed the patch that constitutes the direct user of the new
type...

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-8aOvHuS/wi9YO7RAlfm7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/SH6EACgkQk4XaBE3IOsS70QCfTKrhnhjG5Nx/iGUUy/ZUu/2g
sG0An0kRS+VIYOmTEv2lkF+7AILrRuWc
=shA9
-----END PGP SIGNATURE-----

--=-8aOvHuS/wi9YO7RAlfm7--



--===============1734311419590705741==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1734311419590705741==--



From xen-devel-bounces@lists.xen.org Fri Jun 08 15:58:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd1ZR-0000WM-8D; Fri, 08 Jun 2012 15:57: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 1Sd1ZQ-0000WH-CI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:57:52 +0000
Received: from [85.158.139.83:20268] by server-3.bemta-5.messagelabs.com id
	57/C1-17554-FF022DF4; Fri, 08 Jun 2012 15:57:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339171070!31160909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15506 invoked from network); 8 Jun 2012 15:57:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:57:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:57:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1ZO-0000fq-Jj; Fri, 08 Jun 2012 15:57:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1ZO-00061s-IH;
	Fri, 08 Jun 2012 16:57:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.8446.527363.447501@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:57:50 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339170721.5003.22.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<20434.7215.399396.585324@mariner.uk.xensource.com>
	<1339170721.5003.22.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> Gah, right! The whole queue is under deep restructuring, but I should
> have pushed the patch that constitutes the direct user of the new
> type...

I'm happy to wait.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:58:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd1ZR-0000WM-8D; Fri, 08 Jun 2012 15:57: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 1Sd1ZQ-0000WH-CI
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:57:52 +0000
Received: from [85.158.139.83:20268] by server-3.bemta-5.messagelabs.com id
	57/C1-17554-FF022DF4; Fri, 08 Jun 2012 15:57:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339171070!31160909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15506 invoked from network); 8 Jun 2012 15:57:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:57:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:57:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1ZO-0000fq-Jj; Fri, 08 Jun 2012 15:57:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1ZO-00061s-IH;
	Fri, 08 Jun 2012 16:57:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.8446.527363.447501@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:57:50 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339170721.5003.22.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<20434.7215.399396.585324@mariner.uk.xensource.com>
	<1339170721.5003.22.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> Gah, right! The whole queue is under deep restructuring, but I should
> have pushed the patch that constitutes the direct user of the new
> type...

I'm happy to wait.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 15:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd1aL-0000Zh-Mc; Fri, 08 Jun 2012 15:58:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1aK-0000ZU-B5
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:58:48 +0000
Received: from [85.158.143.99:34292] by server-3.bemta-4.messagelabs.com id
	5F/7A-29237-73122DF4; Fri, 08 Jun 2012 15:58:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339171127!20760741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22830 invoked from network); 8 Jun 2012 15:58:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:58:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:58:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1Zs-0000g1-03; Fri, 08 Jun 2012 15:58:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1Zr-000624-Va;
	Fri, 08 Jun 2012 16:58:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.8475.942958.972499@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:58:19 +0100
To: George Dunlap <George.Dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAFLBxZbaiDR1pVfYT17+yHOSrB3VjGYSq=UddwdoTnHCvXQjGw@mail.gmail.com>
References: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZbaiDR1pVfYT17+yHOSrB3VjGYSq=UddwdoTnHCvXQjGw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub Makefile cleanup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH] pygrub Makefile cleanup."):
> On Fri, Jun 1, 2012 at 12:26 PM, Anthony PERARD
> <anthony.perard@citrix.com> wrote:
> > This patch removes the extra command `install pygrub` because this is already
> > done by the setup.py script.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> > This patch need to be applied after the patch named "Fix pygrub install."

I have applied both of these, 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 Jun 08 15:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 15: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 1Sd1aL-0000Zh-Mc; Fri, 08 Jun 2012 15:58:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1aK-0000ZU-B5
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 15:58:48 +0000
Received: from [85.158.143.99:34292] by server-3.bemta-4.messagelabs.com id
	5F/7A-29237-73122DF4; Fri, 08 Jun 2012 15:58:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339171127!20760741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22830 invoked from network); 8 Jun 2012 15:58:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 15:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 15:58:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 16:58:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1Zs-0000g1-03; Fri, 08 Jun 2012 15:58:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1Zr-000624-Va;
	Fri, 08 Jun 2012 16:58:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.8475.942958.972499@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 16:58:19 +0100
To: George Dunlap <George.Dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAFLBxZbaiDR1pVfYT17+yHOSrB3VjGYSq=UddwdoTnHCvXQjGw@mail.gmail.com>
References: <1338549963-26186-1-git-send-email-anthony.perard@citrix.com>
	<CAFLBxZbaiDR1pVfYT17+yHOSrB3VjGYSq=UddwdoTnHCvXQjGw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub Makefile cleanup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH] pygrub Makefile cleanup."):
> On Fri, Jun 1, 2012 at 12:26 PM, Anthony PERARD
> <anthony.perard@citrix.com> wrote:
> > This patch removes the extra command `install pygrub` because this is already
> > done by the setup.py script.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> > This patch need to be applied after the patch named "Fix pygrub install."

I have applied both of these, 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 Jun 08 16:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 16: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 1Sd1c7-00017i-8a; Fri, 08 Jun 2012 16:00:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1c5-00017W-6U
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 16:00:37 +0000
Received: from [85.158.143.99:42341] by server-1.bemta-4.messagelabs.com id
	5C/9E-10042-4A122DF4; Fri, 08 Jun 2012 16:00:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339171235!28584193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17670 invoked from network); 8 Jun 2012 16:00:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 16:00:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 16:00:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 17:00:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1c3-0000go-7O; Fri, 08 Jun 2012 16:00:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1c3-00064C-6S;
	Fri, 08 Jun 2012 17:00:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.8608.380332.714117@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 17:00:32 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0e4a303989d132ca49c7.1338998070@probook.site>,
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
	<0e4a303989d132ca49c7.1338998070@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <dunlapg@umich.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= option [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

Olaf Hering writes ("[Xen-devel] [PATCH] xl.cfg: document the cpuid= option"):
> xl.cfg: document the cpuid= option

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 16:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 16: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 1Sd1c7-00017i-8a; Fri, 08 Jun 2012 16:00:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd1c5-00017W-6U
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 16:00:37 +0000
Received: from [85.158.143.99:42341] by server-1.bemta-4.messagelabs.com id
	5C/9E-10042-4A122DF4; Fri, 08 Jun 2012 16:00:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339171235!28584193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17670 invoked from network); 8 Jun 2012 16:00:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 16:00:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12914976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 16:00:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 17:00:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd1c3-0000go-7O; Fri, 08 Jun 2012 16:00:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd1c3-00064C-6S;
	Fri, 08 Jun 2012 17:00:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20434.8608.380332.714117@mariner.uk.xensource.com>
Date: Fri, 8 Jun 2012 17:00:32 +0100
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0e4a303989d132ca49c7.1338998070@probook.site>,
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
References: <3da83ff08d6b6431c104.1338572903@probook.site>
	<CAFLBxZY0eLSqs1ramgf2zUymvNXc3gW7XaYkr-wv2zY_SxRO=w@mail.gmail.com>
	<0e4a303989d132ca49c7.1338998070@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <dunlapg@umich.edu>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the cpuid= option [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

Olaf Hering writes ("[Xen-devel] [PATCH] xl.cfg: document the cpuid= option"):
> xl.cfg: document the cpuid= option

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 16:15:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 16: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 1Sd1pt-0001d3-Rt; Fri, 08 Jun 2012 16:14:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Sd1ps-0001cy-Fq
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 16:14:52 +0000
Received: from [85.158.138.51:44327] by server-8.bemta-3.messagelabs.com id
	4B/BA-22118-BF422DF4; Fri, 08 Jun 2012 16:14:51 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339172089!27464632!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31153 invoked from network); 8 Jun 2012 16:14:50 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-10.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 16:14:50 -0000
Received: from mail189-va3-R.bigfish.com (10.7.14.249) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 8 Jun 2012 16:13:58 +0000
Received: from mail189-va3 (localhost [127.0.0.1])	by
	mail189-va3-R.bigfish.com (Postfix) with ESMTP id D458DE0111;
	Fri,  8 Jun 2012 16:13:57 +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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah34h)
Received: from mail189-va3 (localhost.localdomain [127.0.0.1]) by mail189-va3
	(MessageSwitch) id 1339172035229993_4642;
	Fri,  8 Jun 2012 16:13:55 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.243])	by
	mail189-va3.bigfish.com (Postfix) with ESMTP id 2CDD9400044;
	Fri,  8 Jun 2012 16:13:55 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 16:13:49 +0000
X-WSS-ID: 0M5B3SC-02-154-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 2EA0CC819E;	Fri,  8 Jun 2012 11:14:36 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 11:14:58 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 11:14:37 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	12:14:36 -0400
Message-ID: <4FD224EA.5080704@amd.com>
Date: Fri, 8 Jun 2012 18:14:34 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <4FC8B8F5.9000102@amd.com>
	<20424.61304.260546.736913@mariner.uk.xensource.com>
	<4FCF6762.7080904@amd.com>
In-Reply-To: <4FCF6762.7080904@amd.com>
Content-Type: multipart/mixed; boundary="------------020702070007020502010607"
X-OriginatorOrg: amd.com
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] netbsd: pci passthrough for HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------020702070007020502010607
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Implement pci passthrough for HVM guests for NetBSD Dom0.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
From: Manuel Bouyer <bouyer@netbsd.org>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------020702070007020502010607
Content-Type: text/plain; charset="us-ascii";
	name="qemu_xen_traditional_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="qemu_xen_traditional_pci_netbsd.diff"
Content-Description: qemu_xen_traditional_pci_netbsd.diff

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..ca2f75a 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -84,8 +84,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 #include "pt-msi.h"
 #include "qemu-xen.h"
 #include "iomulti.h"
diff --git a/hw/pass-through.h b/hw/pass-through.h
index d7d837c..98b6f5e 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -20,8 +20,13 @@
 
 #include "hw.h"
 #include "pci.h"
+#ifdef __NetBSD__
+#include "pciutils/header.h"
+#include "pciutils/pci.h"
+#else
 #include "pci/header.h"
 #include "pci/pci.h"
+#endif
 #include "exec-all.h"
 #include "sys-queue.h"
 #include "qemu-timer.h"
diff --git a/hw/piix4acpi.c b/hw/piix4acpi.c
index fb1e5c3..d8ca298 100644
--- a/hw/piix4acpi.c
+++ b/hw/piix4acpi.c
@@ -41,7 +41,7 @@
 #define PIIX4ACPI_LOG(level, fmt, ...) do { if (level <= PIIX4ACPI_LOGLEVEL) qemu_log(fmt, ## __VA_ARGS__); } while (0)
 
 #ifdef CONFIG_PASSTHROUGH
-#include <pci/header.h>
+#include "pass-through.h"
 #endif
 
 /* PM1a_CNT bits, as defined in the ACPI specification. */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..3bbd856 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,8 +3,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 
 #include <unistd.h>
 #include <sys/ioctl.h>
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..0bd9446 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -22,6 +22,11 @@
 #include "pt-msi.h"
 #include <sys/mman.h>
 
+#ifdef __NetBSD__
+/* MAP_LOCKED is Linux specific. MAP_WIRED is NetBSD's equivalent. */
+#define MAP_LOCKED MAP_WIRED
+#endif
+
 void msi_set_enable(struct pt_dev *dev, int en)
 {
     uint16_t val = 0;
diff --git a/hw/pt-msi.h b/hw/pt-msi.h
index 94e0d35..4b552dc 100644
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -1,7 +1,6 @@
 #ifndef _PT_MSI_H
 #define _PT_MSI_H
 
-#include "pci/pci.h"
 #include "pass-through.h"
 
 #define  PCI_CAP_ID_MSI     0x05    /* Message Signalled Interrupts */
diff --git a/xen-hooks.mak b/xen-hooks.mak
index b55f45b..430c40d 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -57,8 +57,16 @@ endif
 ifdef CONFIG_STUBDOM
 CONFIG_PASSTHROUGH=1
 else
-  ifeq (,$(wildcard /usr/include/pci))
-$(warning === pciutils-dev package not found - missing /usr/include/pci)
+  PCIUTILS_NetBSD=/usr/pkg/include/pciutils
+  PCIUTILS_Linux=/usr/include/pci
+  ifeq ($(CONFIG_NetBSD), y)
+PCIUTILS_HEADER=$(PCIUTILS_NetBSD)
+  endif
+  ifeq ($(CONFIG_Linux), y)
+PCIUTILS_HEADER=$(PCITUILS_Linux)
+  endif
+  ifeq (,$(wildcard $(PCIUTILS_HEADER)))
+$(warning === pciutils-dev package not found - missing $(PCIUTILS_HEADER))
 $(warning === PCI passthrough capability has been disabled)
   else
 CONFIG_PASSTHROUGH=1
@@ -67,7 +75,11 @@ endif
 
 ifdef CONFIG_PASSTHROUGH
 OBJS+= pass-through.o pt-msi.o pt-graphics.o
+ifeq ($(CONFIG_NetBSD), y)
+LIBS += -lpciutils -lpci
+else
 LIBS += -lpci
+endif
 CFLAGS += -DCONFIG_PASSTHROUGH 
 $(info === PCI passthrough capability has been enabled ===)
 endif

--------------020702070007020502010607
Content-Type: text/plain; charset="us-ascii"; name="libxl_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libxl_pci_netbsd.diff"
Content-Description: libxl_pci_netbsd.diff

diff -r 88df118150e4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu May 24 11:20:47 2012 +0200
+++ b/tools/libxl/libxl_internal.h	Wed Jun 06 16:03:27 2012 +0200
@@ -343,8 +343,6 @@ typedef struct {
 #define PCI_SLOT(devfn)         (((devfn) >> 3) & 0x1f)
 #define PCI_FUNC(devfn)         ((devfn) & 0x07)
 #define AUTO_PHP_SLOT          0x100
-#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
-#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #define XENSTORE_PID_FILE      "/var/run/xenstored.pid"
 
 #define PROC_PCI_NUM_RESOURCES 7
diff -r 88df118150e4 tools/libxl/libxl_osdeps.h
--- a/tools/libxl/libxl_osdeps.h	Thu May 24 11:20:47 2012 +0200
+++ b/tools/libxl/libxl_osdeps.h	Wed Jun 06 16:03:27 2012 +0200
@@ -23,14 +23,27 @@
 
 #define _GNU_SOURCE
 
-#if defined(__NetBSD__) || defined(__OpenBSD__)
+#if defined(__NetBSD__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/kern/xen/pci"
+#include <util.h>
+#elif defined(__OpenBSD__)
 #include <util.h>
 #elif defined(__linux__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #include <pty.h>
 #elif defined(__sun__)
 #include <stropts.h>
 #endif
 
+#ifndef SYSFS_PCIBACK_DRIVER
+#error define SYSFS_PCIBACK_DRIVER for your platform
+#endif
+#ifndef SYSFS_PCI_DEV
+#error define SYSFS_PCI_DEV for your platform
+#endif
+
 #ifdef NEED_OWN_ASPRINTF
 #include <stdarg.h>
 

--------------020702070007020502010607
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020702070007020502010607--


From xen-devel-bounces@lists.xen.org Fri Jun 08 16:15:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 16: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 1Sd1pt-0001d3-Rt; Fri, 08 Jun 2012 16:14:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Sd1ps-0001cy-Fq
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 16:14:52 +0000
Received: from [85.158.138.51:44327] by server-8.bemta-3.messagelabs.com id
	4B/BA-22118-BF422DF4; Fri, 08 Jun 2012 16:14:51 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339172089!27464632!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31153 invoked from network); 8 Jun 2012 16:14:50 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-10.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 16:14:50 -0000
Received: from mail189-va3-R.bigfish.com (10.7.14.249) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 8 Jun 2012 16:13:58 +0000
Received: from mail189-va3 (localhost [127.0.0.1])	by
	mail189-va3-R.bigfish.com (Postfix) with ESMTP id D458DE0111;
	Fri,  8 Jun 2012 16:13:57 +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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah34h)
Received: from mail189-va3 (localhost.localdomain [127.0.0.1]) by mail189-va3
	(MessageSwitch) id 1339172035229993_4642;
	Fri,  8 Jun 2012 16:13:55 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.243])	by
	mail189-va3.bigfish.com (Postfix) with ESMTP id 2CDD9400044;
	Fri,  8 Jun 2012 16:13:55 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 16:13:49 +0000
X-WSS-ID: 0M5B3SC-02-154-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 2EA0CC819E;	Fri,  8 Jun 2012 11:14:36 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 11:14:58 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 11:14:37 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	12:14:36 -0400
Message-ID: <4FD224EA.5080704@amd.com>
Date: Fri, 8 Jun 2012 18:14:34 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <4FC8B8F5.9000102@amd.com>
	<20424.61304.260546.736913@mariner.uk.xensource.com>
	<4FCF6762.7080904@amd.com>
In-Reply-To: <4FCF6762.7080904@amd.com>
Content-Type: multipart/mixed; boundary="------------020702070007020502010607"
X-OriginatorOrg: amd.com
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] netbsd: pci passthrough for HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------020702070007020502010607
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Implement pci passthrough for HVM guests for NetBSD Dom0.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
From: Manuel Bouyer <bouyer@netbsd.org>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------020702070007020502010607
Content-Type: text/plain; charset="us-ascii";
	name="qemu_xen_traditional_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="qemu_xen_traditional_pci_netbsd.diff"
Content-Description: qemu_xen_traditional_pci_netbsd.diff

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..ca2f75a 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -84,8 +84,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 #include "pt-msi.h"
 #include "qemu-xen.h"
 #include "iomulti.h"
diff --git a/hw/pass-through.h b/hw/pass-through.h
index d7d837c..98b6f5e 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -20,8 +20,13 @@
 
 #include "hw.h"
 #include "pci.h"
+#ifdef __NetBSD__
+#include "pciutils/header.h"
+#include "pciutils/pci.h"
+#else
 #include "pci/header.h"
 #include "pci/pci.h"
+#endif
 #include "exec-all.h"
 #include "sys-queue.h"
 #include "qemu-timer.h"
diff --git a/hw/piix4acpi.c b/hw/piix4acpi.c
index fb1e5c3..d8ca298 100644
--- a/hw/piix4acpi.c
+++ b/hw/piix4acpi.c
@@ -41,7 +41,7 @@
 #define PIIX4ACPI_LOG(level, fmt, ...) do { if (level <= PIIX4ACPI_LOGLEVEL) qemu_log(fmt, ## __VA_ARGS__); } while (0)
 
 #ifdef CONFIG_PASSTHROUGH
-#include <pci/header.h>
+#include "pass-through.h"
 #endif
 
 /* PM1a_CNT bits, as defined in the ACPI specification. */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..3bbd856 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,8 +3,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 
 #include <unistd.h>
 #include <sys/ioctl.h>
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..0bd9446 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -22,6 +22,11 @@
 #include "pt-msi.h"
 #include <sys/mman.h>
 
+#ifdef __NetBSD__
+/* MAP_LOCKED is Linux specific. MAP_WIRED is NetBSD's equivalent. */
+#define MAP_LOCKED MAP_WIRED
+#endif
+
 void msi_set_enable(struct pt_dev *dev, int en)
 {
     uint16_t val = 0;
diff --git a/hw/pt-msi.h b/hw/pt-msi.h
index 94e0d35..4b552dc 100644
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -1,7 +1,6 @@
 #ifndef _PT_MSI_H
 #define _PT_MSI_H
 
-#include "pci/pci.h"
 #include "pass-through.h"
 
 #define  PCI_CAP_ID_MSI     0x05    /* Message Signalled Interrupts */
diff --git a/xen-hooks.mak b/xen-hooks.mak
index b55f45b..430c40d 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -57,8 +57,16 @@ endif
 ifdef CONFIG_STUBDOM
 CONFIG_PASSTHROUGH=1
 else
-  ifeq (,$(wildcard /usr/include/pci))
-$(warning === pciutils-dev package not found - missing /usr/include/pci)
+  PCIUTILS_NetBSD=/usr/pkg/include/pciutils
+  PCIUTILS_Linux=/usr/include/pci
+  ifeq ($(CONFIG_NetBSD), y)
+PCIUTILS_HEADER=$(PCIUTILS_NetBSD)
+  endif
+  ifeq ($(CONFIG_Linux), y)
+PCIUTILS_HEADER=$(PCITUILS_Linux)
+  endif
+  ifeq (,$(wildcard $(PCIUTILS_HEADER)))
+$(warning === pciutils-dev package not found - missing $(PCIUTILS_HEADER))
 $(warning === PCI passthrough capability has been disabled)
   else
 CONFIG_PASSTHROUGH=1
@@ -67,7 +75,11 @@ endif
 
 ifdef CONFIG_PASSTHROUGH
 OBJS+= pass-through.o pt-msi.o pt-graphics.o
+ifeq ($(CONFIG_NetBSD), y)
+LIBS += -lpciutils -lpci
+else
 LIBS += -lpci
+endif
 CFLAGS += -DCONFIG_PASSTHROUGH 
 $(info === PCI passthrough capability has been enabled ===)
 endif

--------------020702070007020502010607
Content-Type: text/plain; charset="us-ascii"; name="libxl_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libxl_pci_netbsd.diff"
Content-Description: libxl_pci_netbsd.diff

diff -r 88df118150e4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu May 24 11:20:47 2012 +0200
+++ b/tools/libxl/libxl_internal.h	Wed Jun 06 16:03:27 2012 +0200
@@ -343,8 +343,6 @@ typedef struct {
 #define PCI_SLOT(devfn)         (((devfn) >> 3) & 0x1f)
 #define PCI_FUNC(devfn)         ((devfn) & 0x07)
 #define AUTO_PHP_SLOT          0x100
-#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
-#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #define XENSTORE_PID_FILE      "/var/run/xenstored.pid"
 
 #define PROC_PCI_NUM_RESOURCES 7
diff -r 88df118150e4 tools/libxl/libxl_osdeps.h
--- a/tools/libxl/libxl_osdeps.h	Thu May 24 11:20:47 2012 +0200
+++ b/tools/libxl/libxl_osdeps.h	Wed Jun 06 16:03:27 2012 +0200
@@ -23,14 +23,27 @@
 
 #define _GNU_SOURCE
 
-#if defined(__NetBSD__) || defined(__OpenBSD__)
+#if defined(__NetBSD__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/kern/xen/pci"
+#include <util.h>
+#elif defined(__OpenBSD__)
 #include <util.h>
 #elif defined(__linux__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #include <pty.h>
 #elif defined(__sun__)
 #include <stropts.h>
 #endif
 
+#ifndef SYSFS_PCIBACK_DRIVER
+#error define SYSFS_PCIBACK_DRIVER for your platform
+#endif
+#ifndef SYSFS_PCI_DEV
+#error define SYSFS_PCI_DEV for your platform
+#endif
+
 #ifdef NEED_OWN_ASPRINTF
 #include <stdarg.h>
 

--------------020702070007020502010607
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020702070007020502010607--


From xen-devel-bounces@lists.xen.org Fri Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd356-0002cg-Ap; Fri, 08 Jun 2012 17:34:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002aw-Gf
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.139.83:6193] by server-2.bemta-5.messagelabs.com id
	81/EC-20827-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16111 invoked from network); 8 Jun 2012 17:34:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bc-K2; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005A-Hz;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:17 +0100
Message-ID: <1339176870-32652-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/19] libxl: rename libxl_dom:save_helper to
	physmap_path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"save_helper" isn't very descriptive.  Also it is now confusing
because it reads like it might refer to the libxl-save-helper
executable which runs xc_domain_save and xc_domain_restore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fea0c94..a597627 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -734,7 +734,7 @@ int libxl__domain_suspend_common_callback(void *user)
     return 1;
 }
 
-static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
     return libxl__sprintf(gc,
@@ -779,21 +779,21 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        xs_path = physmap_path(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "size");
+        xs_path = physmap_path(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "name");
+        xs_path = physmap_path(gc, domid, phys_offset, "name");
         name = libxl__xs_read(gc, 0, xs_path);
         if (name == NULL)
             namelen = 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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35B-0002h6-04; Fri, 08 Jun 2012 17:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd355-0002ax-1F
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:8085] by server-3.bemta-4.messagelabs.com id
	5D/DD-29237-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15229 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C2-73; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005l-4W;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:26 +0100
Message-ID: <1339176870-32652-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/19] xl: Handle return value from
	libxl_domain_suspend correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl_domain_suspend returns a libxl error code.  So it must be
wrapped with MUST and not CHK_ERRNO.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 19daa1c..a9125cc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd355-0002bj-2P; Fri, 08 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd352-0002at-Qs
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:7994] by server-1.bemta-4.messagelabs.com id
	1E/0E-10042-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12642 invoked from network); 8 Jun 2012 17:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BM-6M; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd34z-0008WN-Nh;
	Fri, 08 Jun 2012 18:34:33 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:11 +0100
Message-ID: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v3 of my series to asyncify save/restore, rebased to current
tip, retested, and with all comments addressed.

In the list below "A" indicates a patch which has been acked
sufficiently to go in (assuming its dependencies were to go in too).
"*" indicates a new patch in v3.

Preparatory work:

   01/19 libxc: xc_domain_restore, make toolstack_restore const-correct
   02/19 libxl: domain save: rename variables etc.
   03/19 libxl: domain restore: reshuffle, preparing for ao
   04/19 libxl: domain save: API changes for asynchrony

The meat:

   05/19 libxl: domain save/restore: run in a separate process

Some fixups:

 A 06/19 libxl: rename libxl_dom:save_helper to physmap_path
   07/19 libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
   08/19 libxl: wait for qemu to acknowledge logdirty command

Asyncify writing of qemu save file, too:

   09/19 libxl: datacopier: provide "prefix data" facility
   10/19 libxl: prepare for asynchronous writing of qemu save file
   11/19 libxl: Make libxl__domain_save_device_model asynchronous

Fix gc_opt handling:

 * 12/19 libxl: Add a gc to libxl_get_cpu_topology
 * 13/19 libxl: Do not pass NULL as gc_opt; introduce NOGC
 * 14/19 libxl: Get compiler to warn about gc_opt==NULL

Work on essentially-unrelated bugs:

 A 15/19 xl: Handle return value from libxl_domain_suspend correctly
 A 16/19 libxl: do not leak dms->saved_state
   17/19 libxl: do not leak spawned middle children
 A 18/19 libxl: do not leak an event struct on ignored ao progress
 * 19/19 libxl: DO NOT APPLY enforce prohibition on internal

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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd357-0002d7-Ga; Fri, 08 Jun 2012 17:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002at-3r
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:49257] by server-1.bemta-4.messagelabs.com id
	C1/1E-10042-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12714 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001Bt-0S; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005Y-UV;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:23 +0100
Message-ID: <1339176870-32652-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/19] libxl: Add a gc to libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.

libxl_get_cpu_topology doesn't have one but does use NOGC.
Fix this by:
 - introducing an `out' label
 - replacing the only call to `return' with a suitable assignment
   to ret and a `goto out'.
 - adding uses of GC_INIT and GC_FREE.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7de026b..2a31528 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3202,6 +3202,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
@@ -3214,7 +3215,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
     if (max_cpus == 0)
     {
         LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
-        return NULL;
+        ret = NULL;
+        goto out;
     }
 
     coremap = xc_hypercall_buffer_alloc
@@ -3259,6 +3261,8 @@ fail:
 
     if (ret)
         *nr = max_cpus;
+ out:
+    GC_FREE;
     return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd358-0002dS-7F; Fri, 08 Jun 2012 17:34:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002at-Gg
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8097] by server-1.bemta-4.messagelabs.com id
	D2/1E-10042-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12731 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C3-9D; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005p-6s;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:27 +0100
Message-ID: <1339176870-32652-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/19] libxl: do not leak dms->saved_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

This was allocated using asprintf but never freed.  Use GCSPRINTF.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ab000bc..5618293 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -740,9 +740,8 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
         goto out;
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
+        state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
     }
 
 out:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd357-0002dK-SJ; Fri, 08 Jun 2012 17:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002au-Dy
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8088] by server-2.bemta-4.messagelabs.com id
	E4/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12722 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001Bz-4f; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005g-2S;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:25 +0100
Message-ID: <1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
	gc_opt==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

Since it used to be legal to pass gc_opt==NULL, and there are various
patches floating about and under developmetn which do so, add a
compiler annotation which makes the build fail when that is done.

This turns a runtime crash into a build failure, and should ensure
that we don't accidentally commit a broken combination of patches.

This is something of an annoying approach because it adds a macro
invocation to the RHS of every declaration of a function taking a
gc_opt.  So it should be reverted after Xen 4.2rc1.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e69482c..8635764 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * psuedo-gc.
  */
 /* register ptr in gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
+
+#define NN1 __attribute__((nonnull(1)))
+ /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
+  * warn about this if any slip through. */
+
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
 
 /* Each of these logs errors and returns a libxl error code.
  * They do not mind if path is already removed.
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd356-0002cn-MW; Fri, 08 Jun 2012 17:34:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002ax-Go
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:49222] by server-3.bemta-4.messagelabs.com id
	7A/DD-29237-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12658 invoked from network); 8 Jun 2012 17:34:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BW-FF; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-000052-CU;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:15 +0100
Message-ID: <1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
	asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the internal and external APIs for domain save (suspend) to be
capable of asynchronous operation.  The implementation remains
synchronous.  The interfaces surrounding device model saving are still
synchronous.

Public API changes:

 * libxl_domain_save takes an ao_how.

 * libxl_domain_remus_start takes an ao_how.  If the
   libxl_domain_remus_info is NULL, we abort rather than returning an
   error.

 * The `suspend_callback' function passed to libxl_domain_save is
   never called by the existing implementation in libxl.  Abolish it.

 * libxl_domain_save takes its flags parameter as an argument.
   Thus libxl_domain_suspend_info is abolished.

 * XL_SUSPEND_* flags renamed to LIBXL_SAVE_*.

 * Callers in xl updated.

Internal code restructuring:

 * libxl__domain_suspend_state member types and names rationalised.

 * libxl__domain_suspend renamed from libxl__domain_suspend_common.
   (_common here actually meant "internal function").

 * libxl__domain_suspend takes a libxl__domain_suspend_state, which
   where the parameters to the operation are filled in by the caller.

 * xc_domain_save is now called via libxl__xc_domain_save which can
   itself become asynchronous.

 * Consequently, libxl__domain_suspend is split into two functions at
   the callback boundary; the second half is
   libxl__xc_domain_save_done.

 * libxl__domain_save_device_model is now called by the actual
   implementation rather than by the public wrapper.  It is already in
   its proper place in the domain save execution sequence.  So
   officially make it part of that execution sequence, renaming it to
   domain_save_device_model.

 * Effectively, rewrite the public wrapper functions
   libxl_domain_suspend and libxl_domain_remus_start.

 * Remove a needless #include <xenctrl.h>

 * libxl__domain_suspend aborts on unexpected domain types rather
   than mysteriously returning EINVAL.

 * struct save_callbacks moved from the stack to the dss.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Remove `hvm' and `xcflags' args to libxl__xc_domain_save.  Instead,
   just use the values from the dss.

Changes in v2:
 * Move save_callbacks too.
 * Merge with Remus changes.
 * Improvements to commit message.
 * Do not rename libxl_domain_suspend any more.
---
 tools/libxl/libxl.c              |   95 +++++++++++++++++++++---------
 tools/libxl/libxl.h              |   22 ++++----
 tools/libxl/libxl_dom.c          |  121 +++++++++++++++++++++++++++-----------
 tools/libxl/libxl_internal.h     |   45 ++++++++++++---
 tools/libxl/libxl_save_callout.c |   11 ++++
 tools/libxl/xl_cmdimpl.c         |    9 +--
 6 files changed, 215 insertions(+), 88 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..7de026b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
     return ptr;
 }
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc);
+
 /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd)
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    libxl_domain_type type = libxl__domain_type(gc, domid);
-    int rc = 0;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_suspend_state *dss;
+    int rc;
 
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
-        goto remus_fail;
+        goto out;
     }
 
-    if (info == NULL) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "No remus_info structure supplied for domain %d", domid);
-        rc = ERROR_INVAL;
-        goto remus_fail;
-    }
+    GCNEW(dss);
+    dss->ao = ao;
+    dss->callback = remus_crashed_cb;
+    dss->domid = domid;
+    dss->fd = send_fd;
+    /* TODO do something with recv_fd */
+    dss->type = type;
+    dss->live = 1;
+    dss->debug = 0;
+    dss->remus = info;
+
+    assert(info);
 
     /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
 
     /* Point of no return */
-    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
-                                      /* debug */ 0, info);
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out:
+    return AO_ABORT(rc);
+}
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
     /*
      * With Remus, if we reach this point, it means either
      * backup died or some network error occurred preventing us
@@ -683,27 +702,47 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
     /* TBD: Remus cleanup - i.e. detach qdisc, release other
      * resources.
      */
- remus_fail:
-    GC_FREE;
-    return rc;
+    libxl__ao_complete(egc, ao, rc);
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                         uint32_t domid, int fd)
+static void domain_suspend_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
 {
-    GC_INIT(ctx);
+    STATE_AO_GC(dss->ao);
+    libxl__ao_complete(egc,ao,rc);
+
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    int rc;
+
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
-    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
-    int rc = 0;
+    if (type < 0) {
+        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);
+        rc = ERROR_FAIL;
+        goto out_err;
+    }
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
-                                      /* No Remus */ NULL);
+    libxl__domain_suspend_state *dss;
+    GCNEW(dss);
 
-    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(gc, domid, fd);
-    GC_FREE;
-    return rc;
+    dss->ao = ao;
+    dss->callback = domain_suspend_cb;
+
+    dss->domid = domid;
+    dss->fd = fd;
+    dss->type = type;
+    dss->live = flags & LIBXL_SUSPEND_LIVE;
+    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out_err:
+    return AO_ABORT(rc);
 }
 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..10d7115 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
 
-typedef struct {
-#define XL_SUSPEND_DEBUG 1
-#define XL_SUSPEND_LIVE 2
-    int flags;
-    int (*suspend_callback)(void *, int);
-} libxl_domain_suspend_info;
-
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
@@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
-int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd);
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                          uint32_t domid, int fd);
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_asyncop_how *ao_how);
+#define LIBXL_SUSPEND_DEBUG 1
+#define LIBXL_SUSPEND_LIVE 2
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
  *   must support this.
  */
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
+
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how);
+
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1d4e809..b48452c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -17,13 +17,11 @@
 
 #include <glob.h>
 
-#include <xenctrl.h>
-#include <xc_dom.h>
+#include "libxl_internal.h"
 
+#include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl_internal.h"
-
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -521,11 +519,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-static int libxl__domain_suspend_common_switch_qemu_logdirty
+/*==================== Domain suspend (save) ====================*/
+
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc);
+
+/*----- callbacks, called by xc_domain_save -----*/
+
+int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
 
@@ -590,10 +595,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
@@ -714,7 +719,7 @@ static int libxl__domain_suspend_common_callback(void *data)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss->domid);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -731,11 +736,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -806,6 +811,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
     return 0;
 }
 
+/*----- remus callbacks -----*/
+
 static int libxl__remus_domain_suspend_callback(void *data)
 {
     /* TODO: Issue disk and network checkpoint reqs. */
@@ -815,7 +822,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
 static int libxl__remus_domain_resume_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
     if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
@@ -828,10 +835,11 @@ static int libxl__remus_domain_resume_callback(void *data)
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
     if (dss->hvm &&
-        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
+        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
@@ -839,17 +847,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
     return 1;
 }
 
-int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                 libxl_domain_type type,
-                                 int live, int debug,
-                                 const libxl_domain_remus_info *r_info)
+/*----- main code for suspending, in order of execution -----*/
+
+void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 {
+    STATE_AO_GC(dss->ao);
     int port;
-    struct save_callbacks callbacks[1];
-    libxl__domain_suspend_state dss[1];
     int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+    const libxl_domain_type type = dss->type;
+    const int live = dss->live;
+    const int debug = dss->debug;
+    const libxl_domain_remus_info *const r_info = dss->remus;
+    struct save_callbacks *const callbacks = &dss->callbacks;
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
@@ -868,15 +882,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->hvm = 0;
         break;
     default:
-        return ERROR_INVAL;
+        abort();
     }
 
     dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (dss->hvm) ? XCFLAGS_HVM : 0;
 
-    dss->domid = domid;
-    dss->gc = gc;
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
 
@@ -884,10 +896,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->interval = r_info->interval;
         if (r_info->compression)
             dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        dss->save_fd = fd;
     }
-    else
-        dss->save_fd = -1;
 
     dss->xce = xc_evtchn_open(NULL, 0);
     if (dss->xce == NULL)
@@ -917,10 +926,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     callbacks->toolstack_save = libxl__toolstack_save;
     callbacks->data = dss;
 
-    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
-                        dss->hvm, vm_generationid_addr);
-    if ( rc ) {
-        LOGE(ERROR, "saving domain: %s",
+    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
+    return;
+
+ out:
+    domain_suspend_done(egc, dss, rc);
+}
+
+void libxl__xc_domain_save_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss,
+                                int rc, int retval, int errnoval)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const libxl_domain_type type = dss->type;
+    const uint32_t domid = dss->domid;
+
+    if (rc)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "saving domain: %s",
                          dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
@@ -928,16 +955,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
+        goto out;
     }
 
-    if (dss->suspend_eventchn > 0)
-        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                                  dss->suspend_eventchn);
-    if (dss->xce != NULL)
-        xc_evtchn_close(dss->xce);
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, domid);
+        if (rc) goto out;
+        
+        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
+        if (rc) goto out;
+    }
+
+    rc = 0;
 
 out:
-    return rc;
+    domain_suspend_done(egc, dss, rc);
 }
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
@@ -992,6 +1024,25 @@ out:
     return rc;
 }
 
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
+
+    dss->callback(egc, dss, rc);
+}
+
+/*==================== Miscellaneous ====================*/
+
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
     char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 28478ea..e72b8d2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
+typedef void libxl__domain_suspend_cb(libxl__egc*,
+                                      libxl__domain_suspend_state*, int rc);
+
 struct libxl__domain_suspend_state {
-    libxl__gc *gc;
+    /* set by caller of libxl__domain_suspend */
+    libxl__ao *ao;
+    libxl__domain_suspend_cb *callback;
+
+    uint32_t domid;
+    int fd;
+    libxl_domain_type type;
+    int live;
+    int debug;
+    const libxl_domain_remus_info *remus;
+    /* private */
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
-    int domid;
     int hvm;
-    unsigned int xcflags;
+    int xcflags;
     int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
     int interval; /* checkpoint interval (for Remus) */
+    struct save_callbacks callbacks;
 };
 
 
@@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
 
 /*----- Domain suspend (save) functions -----*/
 
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
+/* calls callback when done */
+_hidden void libxl__domain_suspend(libxl__egc *egc,
+                                   libxl__domain_suspend_state *dss);
+
+
+/* calls libxl__xc_domain_suspend_done when done */
+_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
+                                   unsigned long vm_generationid_addr);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_save_done(libxl__egc*,
+                                        libxl__domain_suspend_state*,
+                                        int rc, int retval, int errnoval);
+
+_hidden int libxl__domain_suspend_common_callback(void *data);
+_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data);
+_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data);
+
 
 /* calls libxl__xc_domain_restore_done when done */
 _hidden void libxl__xc_domain_restore(libxl__egc *egc,
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 2f8db9f..1b481ab 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               &state->vm_generationid_addr, &dcs->callbacks);
     libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
 }
+
+void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
+                           unsigned long vm_generationid_addr)
+{
+    STATE_AO_GC(dss->ao);
+    int r;
+
+    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
+                       &dss->callbacks, dss->hvm, vm_generationid_addr);
+    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3ea95ef..19daa1c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
+    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
@@ -3008,7 +3008,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     pid_t child = -1;
     int rc;
     int send_fd = -1, recv_fd = -1;
-    libxl_domain_suspend_info suspinfo;
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
@@ -3030,9 +3029,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    memset(&suspinfo, 0, sizeof(suspinfo));
-    suspinfo.flags |= XL_SUSPEND_LIVE;
-    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
+    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -6604,7 +6601,7 @@ int main_remus(int argc, char **argv)
     }
 
     /* Point of no return */
-    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
 
     /* If we are here, it means backup has failed/domain suspend failed.
      * Try to resume the domain and exit gracefully.
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd355-0002cC-Ii; Fri, 08 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd352-0002au-Sm
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:49181] by server-2.bemta-4.messagelabs.com id
	D0/41-17938-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12637 invoked from network); 8 Jun 2012 17:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BN-6Q; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd34z-0008WP-Pv;
	Fri, 08 Jun 2012 18:34:33 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 8 Jun 2012 18:34:12 +0100
Message-ID: <1339176870-32652-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/19] libxc: xc_domain_restore,
	make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the one provider of this callback, in libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * No longer introduce function pointer typedefs into the libxc API.
---
 tools/libxc/xenguest.h  |    2 +-
 tools/libxl/libxl_dom.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 91d53f7..707e31c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
     /* callback to restore toolstack specific data */
-    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
             uint32_t size, void* data);
 
     /* to be provided as the last argument to each callback function */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 10f8c1f..677db1d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,13 +467,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = (libxl__gc *) data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
-    uint8_t *ptr = buf;
+    const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
     struct libxl__physmap_info* pi;
     char *xs_path;
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd359-0002fW-KV; Fri, 08 Jun 2012 17:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002au-Sq
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:49271] by server-2.bemta-4.messagelabs.com id
	25/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15217 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bs-VH; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005U-SO;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:22 +0100
Message-ID: <1339176870-32652-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/19] libxl: Make
	libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in series v3:
 * Improve one more a debugging message.
---
 tools/libxl/libxl_dom.c      |  100 +++++++++++++++++++++++++++---------------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3a53f97..14eb77e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1147,15 +1147,17 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
 void libxl__domain_save_device_model(libxl__egc *egc,
                                      libxl__domain_suspend_state *dss,
                                      libxl__save_device_model_cb *callback)
 {
     STATE_AO_GC(dss->ao);
-    int rc, fd2 = -1, c;
-    char buf[1024];
     struct stat st;
     uint32_t qemu_state_len;
+    int rc;
 
     dss->save_dm_callback = callback;
 
@@ -1163,49 +1165,77 @@ void libxl__domain_save_device_model(libxl__egc *egc,
     const char *const filename = dss->dm_savefile;
     const int fd = dss->fd;
 
-    if (stat(filename, &st) < 0)
+    libxl__datacopier_state *dc = &dss->save_dm_datacopier;
+    memset(dc, 0, sizeof(*dc));
+    dc->readwhat = GCSPRINTF("qemu save file %s", filename);
+    dc->ao = ao;
+    dc->readfd = -1;
+    dc->writefd = fd;
+    dc->maxsz = INT_MAX;
+    dc->copywhat = GCSPRINTF("qemu save file for domain %"PRIu32, dss->domid);
+    dc->writewhat = "save/migration stream";
+    dc->callback = save_device_model_datacopier_done;
+
+    dc->readfd = open(filename, O_RDONLY);
+    if (dc->readfd < 0) {
+        LOGE(ERROR, "unable to open %s", dc->readwhat);
+        goto out;
+    }
+
+    if (fstat(dc->readfd, &st))
     {
-        LOG(ERROR, "Unable to stat qemu save file\n");
-        rc = ERROR_FAIL;
+        LOGE(ERROR, "unable to fstat %s", dc->readwhat);
+        goto out;
+    }
+
+    if (!S_ISREG(st.st_mode)) {
+        LOG(ERROR, "%s is not a plain file!", dc->readwhat);
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "%s is %d bytes", dc->readwhat, qemu_state_len);
 
-    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
-    if (rc)
-        goto out;
+    rc = libxl__datacopier_start(dc);
+    if (rc) goto out;
 
-    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
-                            "saved-state file", "saved-state length");
-    if (rc)
-        goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 QEMU_SIGNATURE, strlen(QEMU_SIGNATURE));
 
-    fd2 = open(filename, O_RDONLY);
-    if (fd2 < 0) {
-        LOGE(ERROR, "Unable to open qemu save file\n");
-        goto out;
-    }
-    while ((c = read(fd2, buf, sizeof(buf))) != 0) {
-        if (c < 0) {
-            if (errno == EINTR)
-                continue;
-            rc = errno;
-            goto out;
-        }
-        rc = libxl_write_exactly(
-            CTX, fd, buf, c, "saved-state file", "qemu state");
-        if (rc)
-            goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 &qemu_state_len, sizeof(qemu_state_len));
+    return;
+
+ out:
+    save_device_model_datacopier_done(egc, dc, -1, 0);
+}
+
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(dc, *dss, save_dm_datacopier);
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    int our_rc = 0;
+    int rc;
+
+    libxl__datacopier_kill(dc);
+
+    if (onwrite || errnoval)
+        our_rc = ERROR_FAIL;
+
+    if (dc->readfd >= 0) {
+        close(dc->readfd);
+        dc->readfd = -1;
     }
-    rc = 0;
-out:
-    if (fd2 >= 0) close(fd2);
-    unlink(filename);
 
-    dss->save_dm_callback(egc, dss, rc);
+    rc = libxl__remove_file(gc, filename);
+    if (!our_rc) our_rc = rc;
+
+    dss->save_dm_callback(egc, dss, our_rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c7fe9e9..f90814a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1901,6 +1901,7 @@ struct libxl__domain_suspend_state {
     libxl__logdirty_switch logdirty;
     /* private for libxl__domain_save_device_model */
     libxl__save_device_model_cb *save_dm_callback;
+    libxl__datacopier_state save_dm_datacopier;
 };
 
 
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd359-0002fG-6K; Fri, 08 Jun 2012 17:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002ax-82
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8063] by server-3.bemta-4.messagelabs.com id
	7C/DD-29237-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12698 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Ba-IE; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-000056-FC;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:16 +0100
Message-ID: <1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.
---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   21 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   36 ++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  332 +++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  279 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  393 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1104 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_save_helper.c
 create mode 100755 tools/libxl/libxl_save_msgs_gen.pl

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..1b81963 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -170,6 +184,7 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4439367..00705d8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -601,7 +601,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -641,7 +642,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -661,10 +661,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b48452c..fea0c94 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -465,16 +465,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -527,9 +531,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -595,9 +600,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -737,9 +743,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -808,6 +814,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -862,7 +870,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -923,8 +932,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -933,10 +941,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e72b8d2..dbf7722 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..a39f434 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,19 @@
 
 #include "libxl_internal.h"
 
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int data_fd,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +40,319 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        restore_fd, domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc;
+    uint32_t toolstack_data_len;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
+                              &toolstack_data_len, dss);
+    if (r) { rc = ERROR_FAIL; goto out; }
+
+    dss->shs.toolstack_data_file = tmpfile();
+    if (!dss->shs.toolstack_data_file) {
+        LOGE(ERROR, "cannot create toolstack data tmpfile");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    int toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+    r = libxl_write_exactly(CTX, toolstack_data_fd,
+                            toolstack_data_buf, toolstack_data_len,
+                            "toolstack data tmpfile", 0);
+    if (r) { rc = ERROR_FAIL; goto out; }
+
+    r = lseek(toolstack_data_fd, 0, SEEK_SET);
+    if (r) {
+        LOGE(ERROR, "rewind toolstack data tmpfile");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    const unsigned long argnums[] = {
+        dss->fd, dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int data_fd,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[3 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    for (i=0; i<2; i++) {
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
+        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        libxl_fd_set_cloexec(CTX, data_fd, 0);
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & POLLPRI) {
+        LOG(ERROR, "%s signaled POLLERR", shs->stdout_what);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..d29f1f7
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    *buf = xmalloc(toolstack_save_len);
+    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    toolstack_save_fd = -1;
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        helper_save_callbacks.toolstack_save = toolstack_save_cb;
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..cd0837e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,393 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copius debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END
+
+#include "libxl_internal.h"
+
+END
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}", <<END.($debug ? <<END : '').<<END);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END
+    switch (mtype) {
+
+END
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name", <<END.($debug ? <<END : '').<<END);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name", (<<END.($debug ? <<END : '').<<END));
+    int r = ${helper}_getreply(user);
+END
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END
+    return r;
+END
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd358-0002dS-7F; Fri, 08 Jun 2012 17:34:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002at-Gg
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8097] by server-1.bemta-4.messagelabs.com id
	D2/1E-10042-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12731 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C3-9D; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005p-6s;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:27 +0100
Message-ID: <1339176870-32652-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/19] libxl: do not leak dms->saved_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

This was allocated using asprintf but never freed.  Use GCSPRINTF.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ab000bc..5618293 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -740,9 +740,8 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
         goto out;
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
+        state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
     }
 
 out:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd356-0002cn-MW; Fri, 08 Jun 2012 17:34:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002ax-Go
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:49222] by server-3.bemta-4.messagelabs.com id
	7A/DD-29237-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12658 invoked from network); 8 Jun 2012 17:34:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BW-FF; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-000052-CU;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:15 +0100
Message-ID: <1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
	asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the internal and external APIs for domain save (suspend) to be
capable of asynchronous operation.  The implementation remains
synchronous.  The interfaces surrounding device model saving are still
synchronous.

Public API changes:

 * libxl_domain_save takes an ao_how.

 * libxl_domain_remus_start takes an ao_how.  If the
   libxl_domain_remus_info is NULL, we abort rather than returning an
   error.

 * The `suspend_callback' function passed to libxl_domain_save is
   never called by the existing implementation in libxl.  Abolish it.

 * libxl_domain_save takes its flags parameter as an argument.
   Thus libxl_domain_suspend_info is abolished.

 * XL_SUSPEND_* flags renamed to LIBXL_SAVE_*.

 * Callers in xl updated.

Internal code restructuring:

 * libxl__domain_suspend_state member types and names rationalised.

 * libxl__domain_suspend renamed from libxl__domain_suspend_common.
   (_common here actually meant "internal function").

 * libxl__domain_suspend takes a libxl__domain_suspend_state, which
   where the parameters to the operation are filled in by the caller.

 * xc_domain_save is now called via libxl__xc_domain_save which can
   itself become asynchronous.

 * Consequently, libxl__domain_suspend is split into two functions at
   the callback boundary; the second half is
   libxl__xc_domain_save_done.

 * libxl__domain_save_device_model is now called by the actual
   implementation rather than by the public wrapper.  It is already in
   its proper place in the domain save execution sequence.  So
   officially make it part of that execution sequence, renaming it to
   domain_save_device_model.

 * Effectively, rewrite the public wrapper functions
   libxl_domain_suspend and libxl_domain_remus_start.

 * Remove a needless #include <xenctrl.h>

 * libxl__domain_suspend aborts on unexpected domain types rather
   than mysteriously returning EINVAL.

 * struct save_callbacks moved from the stack to the dss.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Remove `hvm' and `xcflags' args to libxl__xc_domain_save.  Instead,
   just use the values from the dss.

Changes in v2:
 * Move save_callbacks too.
 * Merge with Remus changes.
 * Improvements to commit message.
 * Do not rename libxl_domain_suspend any more.
---
 tools/libxl/libxl.c              |   95 +++++++++++++++++++++---------
 tools/libxl/libxl.h              |   22 ++++----
 tools/libxl/libxl_dom.c          |  121 +++++++++++++++++++++++++++-----------
 tools/libxl/libxl_internal.h     |   45 ++++++++++++---
 tools/libxl/libxl_save_callout.c |   11 ++++
 tools/libxl/xl_cmdimpl.c         |    9 +--
 6 files changed, 215 insertions(+), 88 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..7de026b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
     return ptr;
 }
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc);
+
 /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd)
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    libxl_domain_type type = libxl__domain_type(gc, domid);
-    int rc = 0;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_suspend_state *dss;
+    int rc;
 
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
-        goto remus_fail;
+        goto out;
     }
 
-    if (info == NULL) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "No remus_info structure supplied for domain %d", domid);
-        rc = ERROR_INVAL;
-        goto remus_fail;
-    }
+    GCNEW(dss);
+    dss->ao = ao;
+    dss->callback = remus_crashed_cb;
+    dss->domid = domid;
+    dss->fd = send_fd;
+    /* TODO do something with recv_fd */
+    dss->type = type;
+    dss->live = 1;
+    dss->debug = 0;
+    dss->remus = info;
+
+    assert(info);
 
     /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
 
     /* Point of no return */
-    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
-                                      /* debug */ 0, info);
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out:
+    return AO_ABORT(rc);
+}
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
     /*
      * With Remus, if we reach this point, it means either
      * backup died or some network error occurred preventing us
@@ -683,27 +702,47 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
     /* TBD: Remus cleanup - i.e. detach qdisc, release other
      * resources.
      */
- remus_fail:
-    GC_FREE;
-    return rc;
+    libxl__ao_complete(egc, ao, rc);
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                         uint32_t domid, int fd)
+static void domain_suspend_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
 {
-    GC_INIT(ctx);
+    STATE_AO_GC(dss->ao);
+    libxl__ao_complete(egc,ao,rc);
+
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    int rc;
+
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
-    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
-    int rc = 0;
+    if (type < 0) {
+        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);
+        rc = ERROR_FAIL;
+        goto out_err;
+    }
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
-                                      /* No Remus */ NULL);
+    libxl__domain_suspend_state *dss;
+    GCNEW(dss);
 
-    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(gc, domid, fd);
-    GC_FREE;
-    return rc;
+    dss->ao = ao;
+    dss->callback = domain_suspend_cb;
+
+    dss->domid = domid;
+    dss->fd = fd;
+    dss->type = type;
+    dss->live = flags & LIBXL_SUSPEND_LIVE;
+    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out_err:
+    return AO_ABORT(rc);
 }
 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..10d7115 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
 
-typedef struct {
-#define XL_SUSPEND_DEBUG 1
-#define XL_SUSPEND_LIVE 2
-    int flags;
-    int (*suspend_callback)(void *, int);
-} libxl_domain_suspend_info;
-
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
@@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
-int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd);
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                          uint32_t domid, int fd);
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_asyncop_how *ao_how);
+#define LIBXL_SUSPEND_DEBUG 1
+#define LIBXL_SUSPEND_LIVE 2
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
  *   must support this.
  */
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
+
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how);
+
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1d4e809..b48452c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -17,13 +17,11 @@
 
 #include <glob.h>
 
-#include <xenctrl.h>
-#include <xc_dom.h>
+#include "libxl_internal.h"
 
+#include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl_internal.h"
-
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -521,11 +519,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-static int libxl__domain_suspend_common_switch_qemu_logdirty
+/*==================== Domain suspend (save) ====================*/
+
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc);
+
+/*----- callbacks, called by xc_domain_save -----*/
+
+int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
 
@@ -590,10 +595,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
@@ -714,7 +719,7 @@ static int libxl__domain_suspend_common_callback(void *data)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss->domid);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -731,11 +736,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -806,6 +811,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
     return 0;
 }
 
+/*----- remus callbacks -----*/
+
 static int libxl__remus_domain_suspend_callback(void *data)
 {
     /* TODO: Issue disk and network checkpoint reqs. */
@@ -815,7 +822,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
 static int libxl__remus_domain_resume_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
     if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
@@ -828,10 +835,11 @@ static int libxl__remus_domain_resume_callback(void *data)
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
     if (dss->hvm &&
-        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
+        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
@@ -839,17 +847,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
     return 1;
 }
 
-int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                 libxl_domain_type type,
-                                 int live, int debug,
-                                 const libxl_domain_remus_info *r_info)
+/*----- main code for suspending, in order of execution -----*/
+
+void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 {
+    STATE_AO_GC(dss->ao);
     int port;
-    struct save_callbacks callbacks[1];
-    libxl__domain_suspend_state dss[1];
     int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+    const libxl_domain_type type = dss->type;
+    const int live = dss->live;
+    const int debug = dss->debug;
+    const libxl_domain_remus_info *const r_info = dss->remus;
+    struct save_callbacks *const callbacks = &dss->callbacks;
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
@@ -868,15 +882,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->hvm = 0;
         break;
     default:
-        return ERROR_INVAL;
+        abort();
     }
 
     dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (dss->hvm) ? XCFLAGS_HVM : 0;
 
-    dss->domid = domid;
-    dss->gc = gc;
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
 
@@ -884,10 +896,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->interval = r_info->interval;
         if (r_info->compression)
             dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        dss->save_fd = fd;
     }
-    else
-        dss->save_fd = -1;
 
     dss->xce = xc_evtchn_open(NULL, 0);
     if (dss->xce == NULL)
@@ -917,10 +926,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     callbacks->toolstack_save = libxl__toolstack_save;
     callbacks->data = dss;
 
-    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
-                        dss->hvm, vm_generationid_addr);
-    if ( rc ) {
-        LOGE(ERROR, "saving domain: %s",
+    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
+    return;
+
+ out:
+    domain_suspend_done(egc, dss, rc);
+}
+
+void libxl__xc_domain_save_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss,
+                                int rc, int retval, int errnoval)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const libxl_domain_type type = dss->type;
+    const uint32_t domid = dss->domid;
+
+    if (rc)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "saving domain: %s",
                          dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
@@ -928,16 +955,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
+        goto out;
     }
 
-    if (dss->suspend_eventchn > 0)
-        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                                  dss->suspend_eventchn);
-    if (dss->xce != NULL)
-        xc_evtchn_close(dss->xce);
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, domid);
+        if (rc) goto out;
+        
+        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
+        if (rc) goto out;
+    }
+
+    rc = 0;
 
 out:
-    return rc;
+    domain_suspend_done(egc, dss, rc);
 }
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
@@ -992,6 +1024,25 @@ out:
     return rc;
 }
 
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
+
+    dss->callback(egc, dss, rc);
+}
+
+/*==================== Miscellaneous ====================*/
+
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
     char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 28478ea..e72b8d2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
+typedef void libxl__domain_suspend_cb(libxl__egc*,
+                                      libxl__domain_suspend_state*, int rc);
+
 struct libxl__domain_suspend_state {
-    libxl__gc *gc;
+    /* set by caller of libxl__domain_suspend */
+    libxl__ao *ao;
+    libxl__domain_suspend_cb *callback;
+
+    uint32_t domid;
+    int fd;
+    libxl_domain_type type;
+    int live;
+    int debug;
+    const libxl_domain_remus_info *remus;
+    /* private */
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
-    int domid;
     int hvm;
-    unsigned int xcflags;
+    int xcflags;
     int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
     int interval; /* checkpoint interval (for Remus) */
+    struct save_callbacks callbacks;
 };
 
 
@@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
 
 /*----- Domain suspend (save) functions -----*/
 
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
+/* calls callback when done */
+_hidden void libxl__domain_suspend(libxl__egc *egc,
+                                   libxl__domain_suspend_state *dss);
+
+
+/* calls libxl__xc_domain_suspend_done when done */
+_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
+                                   unsigned long vm_generationid_addr);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_save_done(libxl__egc*,
+                                        libxl__domain_suspend_state*,
+                                        int rc, int retval, int errnoval);
+
+_hidden int libxl__domain_suspend_common_callback(void *data);
+_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data);
+_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data);
+
 
 /* calls libxl__xc_domain_restore_done when done */
 _hidden void libxl__xc_domain_restore(libxl__egc *egc,
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 2f8db9f..1b481ab 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               &state->vm_generationid_addr, &dcs->callbacks);
     libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
 }
+
+void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
+                           unsigned long vm_generationid_addr)
+{
+    STATE_AO_GC(dss->ao);
+    int r;
+
+    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
+                       &dss->callbacks, dss->hvm, vm_generationid_addr);
+    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3ea95ef..19daa1c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
+    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
@@ -3008,7 +3008,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     pid_t child = -1;
     int rc;
     int send_fd = -1, recv_fd = -1;
-    libxl_domain_suspend_info suspinfo;
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
@@ -3030,9 +3029,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    memset(&suspinfo, 0, sizeof(suspinfo));
-    suspinfo.flags |= XL_SUSPEND_LIVE;
-    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
+    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -6604,7 +6601,7 @@ int main_remus(int argc, char **argv)
     }
 
     /* Point of no return */
-    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
 
     /* If we are here, it means backup has failed/domain suspend failed.
      * Try to resume the domain and exit gracefully.
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd359-0002fG-6K; Fri, 08 Jun 2012 17:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002ax-82
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8063] by server-3.bemta-4.messagelabs.com id
	7C/DD-29237-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12698 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Ba-IE; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-000056-FC;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:16 +0100
Message-ID: <1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.
---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   21 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   36 ++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  332 +++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  279 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  393 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1104 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_save_helper.c
 create mode 100755 tools/libxl/libxl_save_msgs_gen.pl

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..1b81963 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -170,6 +184,7 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4439367..00705d8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -601,7 +601,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -641,7 +642,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -661,10 +661,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b48452c..fea0c94 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -465,16 +465,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -527,9 +531,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -595,9 +600,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -737,9 +743,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -808,6 +814,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -862,7 +870,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -923,8 +932,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -933,10 +941,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e72b8d2..dbf7722 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..a39f434 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,19 @@
 
 #include "libxl_internal.h"
 
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int data_fd,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +40,319 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        restore_fd, domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc;
+    uint32_t toolstack_data_len;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
+                              &toolstack_data_len, dss);
+    if (r) { rc = ERROR_FAIL; goto out; }
+
+    dss->shs.toolstack_data_file = tmpfile();
+    if (!dss->shs.toolstack_data_file) {
+        LOGE(ERROR, "cannot create toolstack data tmpfile");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    int toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+    r = libxl_write_exactly(CTX, toolstack_data_fd,
+                            toolstack_data_buf, toolstack_data_len,
+                            "toolstack data tmpfile", 0);
+    if (r) { rc = ERROR_FAIL; goto out; }
+
+    r = lseek(toolstack_data_fd, 0, SEEK_SET);
+    if (r) {
+        LOGE(ERROR, "rewind toolstack data tmpfile");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    const unsigned long argnums[] = {
+        dss->fd, dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int data_fd,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[3 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    for (i=0; i<2; i++) {
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
+        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        libxl_fd_set_cloexec(CTX, data_fd, 0);
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & POLLPRI) {
+        LOG(ERROR, "%s signaled POLLERR", shs->stdout_what);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..d29f1f7
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    *buf = xmalloc(toolstack_save_len);
+    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    toolstack_save_fd = -1;
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        helper_save_callbacks.toolstack_save = toolstack_save_cb;
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..cd0837e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,393 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copius debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END
+
+#include "libxl_internal.h"
+
+END
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}", <<END.($debug ? <<END : '').<<END);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END
+    switch (mtype) {
+
+END
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name", <<END.($debug ? <<END : '').<<END);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name", (<<END.($debug ? <<END : '').<<END));
+    int r = ${helper}_getreply(user);
+END
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END
+    return r;
+END
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd355-0002cC-Ii; Fri, 08 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd352-0002au-Sm
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:49181] by server-2.bemta-4.messagelabs.com id
	D0/41-17938-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12637 invoked from network); 8 Jun 2012 17:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BN-6Q; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd34z-0008WP-Pv;
	Fri, 08 Jun 2012 18:34:33 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 8 Jun 2012 18:34:12 +0100
Message-ID: <1339176870-32652-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/19] libxc: xc_domain_restore,
	make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the one provider of this callback, in libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * No longer introduce function pointer typedefs into the libxc API.
---
 tools/libxc/xenguest.h  |    2 +-
 tools/libxl/libxl_dom.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 91d53f7..707e31c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
     /* callback to restore toolstack specific data */
-    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
             uint32_t size, void* data);
 
     /* to be provided as the last argument to each callback function */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 10f8c1f..677db1d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,13 +467,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = (libxl__gc *) data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
-    uint8_t *ptr = buf;
+    const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
     struct libxl__physmap_info* pi;
     char *xs_path;
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35B-0002h6-04; Fri, 08 Jun 2012 17:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd355-0002ax-1F
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:8085] by server-3.bemta-4.messagelabs.com id
	5D/DD-29237-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15229 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C2-73; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005l-4W;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:26 +0100
Message-ID: <1339176870-32652-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/19] xl: Handle return value from
	libxl_domain_suspend correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl_domain_suspend returns a libxl error code.  So it must be
wrapped with MUST and not CHK_ERRNO.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 19daa1c..a9125cc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd356-0002cg-Ap; Fri, 08 Jun 2012 17:34:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002aw-Gf
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.139.83:6193] by server-2.bemta-5.messagelabs.com id
	81/EC-20827-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16111 invoked from network); 8 Jun 2012 17:34:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bc-K2; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005A-Hz;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:17 +0100
Message-ID: <1339176870-32652-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/19] libxl: rename libxl_dom:save_helper to
	physmap_path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"save_helper" isn't very descriptive.  Also it is now confusing
because it reads like it might refer to the libxl-save-helper
executable which runs xc_domain_save and xc_domain_restore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fea0c94..a597627 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -734,7 +734,7 @@ int libxl__domain_suspend_common_callback(void *user)
     return 1;
 }
 
-static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
     return libxl__sprintf(gc,
@@ -779,21 +779,21 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        xs_path = physmap_path(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "size");
+        xs_path = physmap_path(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "name");
+        xs_path = physmap_path(gc, domid, phys_offset, "name");
         name = libxl__xs_read(gc, 0, xs_path);
         if (name == NULL)
             namelen = 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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd359-0002fW-KV; Fri, 08 Jun 2012 17:34:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002au-Sq
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:49271] by server-2.bemta-4.messagelabs.com id
	25/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15217 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bs-VH; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005U-SO;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:22 +0100
Message-ID: <1339176870-32652-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/19] libxl: Make
	libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in series v3:
 * Improve one more a debugging message.
---
 tools/libxl/libxl_dom.c      |  100 +++++++++++++++++++++++++++---------------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3a53f97..14eb77e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1147,15 +1147,17 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
 void libxl__domain_save_device_model(libxl__egc *egc,
                                      libxl__domain_suspend_state *dss,
                                      libxl__save_device_model_cb *callback)
 {
     STATE_AO_GC(dss->ao);
-    int rc, fd2 = -1, c;
-    char buf[1024];
     struct stat st;
     uint32_t qemu_state_len;
+    int rc;
 
     dss->save_dm_callback = callback;
 
@@ -1163,49 +1165,77 @@ void libxl__domain_save_device_model(libxl__egc *egc,
     const char *const filename = dss->dm_savefile;
     const int fd = dss->fd;
 
-    if (stat(filename, &st) < 0)
+    libxl__datacopier_state *dc = &dss->save_dm_datacopier;
+    memset(dc, 0, sizeof(*dc));
+    dc->readwhat = GCSPRINTF("qemu save file %s", filename);
+    dc->ao = ao;
+    dc->readfd = -1;
+    dc->writefd = fd;
+    dc->maxsz = INT_MAX;
+    dc->copywhat = GCSPRINTF("qemu save file for domain %"PRIu32, dss->domid);
+    dc->writewhat = "save/migration stream";
+    dc->callback = save_device_model_datacopier_done;
+
+    dc->readfd = open(filename, O_RDONLY);
+    if (dc->readfd < 0) {
+        LOGE(ERROR, "unable to open %s", dc->readwhat);
+        goto out;
+    }
+
+    if (fstat(dc->readfd, &st))
     {
-        LOG(ERROR, "Unable to stat qemu save file\n");
-        rc = ERROR_FAIL;
+        LOGE(ERROR, "unable to fstat %s", dc->readwhat);
+        goto out;
+    }
+
+    if (!S_ISREG(st.st_mode)) {
+        LOG(ERROR, "%s is not a plain file!", dc->readwhat);
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "%s is %d bytes", dc->readwhat, qemu_state_len);
 
-    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
-    if (rc)
-        goto out;
+    rc = libxl__datacopier_start(dc);
+    if (rc) goto out;
 
-    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
-                            "saved-state file", "saved-state length");
-    if (rc)
-        goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 QEMU_SIGNATURE, strlen(QEMU_SIGNATURE));
 
-    fd2 = open(filename, O_RDONLY);
-    if (fd2 < 0) {
-        LOGE(ERROR, "Unable to open qemu save file\n");
-        goto out;
-    }
-    while ((c = read(fd2, buf, sizeof(buf))) != 0) {
-        if (c < 0) {
-            if (errno == EINTR)
-                continue;
-            rc = errno;
-            goto out;
-        }
-        rc = libxl_write_exactly(
-            CTX, fd, buf, c, "saved-state file", "qemu state");
-        if (rc)
-            goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 &qemu_state_len, sizeof(qemu_state_len));
+    return;
+
+ out:
+    save_device_model_datacopier_done(egc, dc, -1, 0);
+}
+
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(dc, *dss, save_dm_datacopier);
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    int our_rc = 0;
+    int rc;
+
+    libxl__datacopier_kill(dc);
+
+    if (onwrite || errnoval)
+        our_rc = ERROR_FAIL;
+
+    if (dc->readfd >= 0) {
+        close(dc->readfd);
+        dc->readfd = -1;
     }
-    rc = 0;
-out:
-    if (fd2 >= 0) close(fd2);
-    unlink(filename);
 
-    dss->save_dm_callback(egc, dss, rc);
+    rc = libxl__remove_file(gc, filename);
+    if (!our_rc) our_rc = rc;
+
+    dss->save_dm_callback(egc, dss, our_rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c7fe9e9..f90814a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1901,6 +1901,7 @@ struct libxl__domain_suspend_state {
     libxl__logdirty_switch logdirty;
     /* private for libxl__domain_save_device_model */
     libxl__save_device_model_cb *save_dm_callback;
+    libxl__datacopier_state save_dm_datacopier;
 };
 
 
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35C-0002iY-96; Fri, 08 Jun 2012 17:34: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 1Sd355-0002au-9e
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:8089] by server-2.bemta-4.messagelabs.com id
	05/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15202 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bg-OA; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005I-Lo;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:19 +0100
Message-ID: <1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
	logdirty 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

The current migration code in libxl instructs qemu to start or stop
logdirty, but it does not wait for an acknowledgement from qemu before
continuing.  This might lead to memory corruption (!)

Fix this by waiting for qemu to acknowledge the command.

Unfortunately the necessary ao arrangements for waiting for this
command are unique because qemu has a special protocol for this
particular operation.

Also, this change means that the switch_qemu_logdirty callback
implementation in libxl can no longer synchronously produce its return
value, as it now needs to wait for xenstore.  So we tell the
marshalling code generator that it is a message which does not need a
reply.  This turns the callback function called by the marshaller into
one which returns void; the callback function arranges to later
explicitly sends the reply to the helper, when the xs watch triggers
and the appropriate value is read from xenstore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_dom.c            |  176 +++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h       |   18 ++++-
 tools/libxl/libxl_save_callout.c   |    8 ++
 tools/libxl/libxl_save_msgs_gen.pl |    7 +-
 4 files changed, 193 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a597627..d5ac79f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -528,30 +528,180 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
 static void domain_suspend_done(libxl__egc *egc,
                         libxl__domain_suspend_state *dss, int rc);
 
-/*----- callbacks, called by xc_domain_save -----*/
+/*----- complicated callback, called by xc_domain_save -----*/
+
+/*
+ * We implement the other end of protocol for controlling qemu-dm's
+ * logdirty.  There is no documentation for this protocol, but our
+ * counterparty's implementation is in
+ * qemu-xen-traditional.git:xenstore.c in the function
+ * xenstore_process_logdirty_event
+ */
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs);
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok);
 
-int libxl__domain_suspend_common_switch_qemu_logdirty
+static void logdirty_init(libxl__logdirty_switch *lds)
+{
+    lds->cmd_path = 0;
+    libxl__ev_xswatch_init(&lds->watch);
+    libxl__ev_time_init(&lds->timeout);
+}
+
+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);
+    libxl__logdirty_switch *lds = &dss->logdirty;
     STATE_AO_GC(dss->ao);
-    char *path;
-    bool rc;
+    int rc;
+    xs_transaction_t t = 0;
+    const char *got;
 
-    path = libxl__sprintf(gc,
+    if (!lds->cmd_path) {
+        lds->cmd_path = GCSPRINTF(
                    "/local/domain/0/device-model/%u/logdirty/cmd", domid);
-    if (!path)
-        return 1;
+        lds->ret_path = GCSPRINTF(
+                   "/local/domain/0/device-model/%u/logdirty/ret", domid);
+    }
+    lds->cmd = enable ? "enable" : "disable";
 
-    if (enable)
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
-    else
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
+    rc = libxl__ev_xswatch_register(gc, &lds->watch,
+                                switch_logdirty_xswatch, lds->ret_path);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_register_rel(gc, &lds->timeout,
+                                switch_logdirty_timeout, 10*1000);
+    if (rc) goto out;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->cmd_path, &got);
+        if (rc) goto out;
+
+        if (got) {
+            const char *got_ret;
+            rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got_ret);
+            if (rc) goto out;
 
-    return rc ? 0 : 1;
+            if (strcmp(got, got_ret)) {
+                LOG(ERROR,"controlling logdirty: qemu was already sent"
+                    " command `%s' (xenstore path `%s') but result is `%s'",
+                    got, lds->cmd_path, got_ret ? got_ret : "<none>");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+            rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+            if (rc) goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_write_checked(gc, t, lds->cmd_path, lds->cmd);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t);
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+    /* OK, wait for some callback */
+    return;
+
+ out:
+    LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+    switch_logdirty_done(egc,dss,0);
+}
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
+    STATE_AO_GC(dss->ao);
+    LOG(ERROR,"logdirty switch: wait for device model timed out");
+    switch_logdirty_done(egc,dss,0);
 }
 
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(watch, *dss, logdirty.watch);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+    STATE_AO_GC(dss->ao);
+    const char *got;
+    xs_transaction_t t = 0;
+    int rc;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
+        if (rc) goto out;
+
+        if (!got) {
+            rc = +1;
+            goto out;
+        }
+
+        if (strcmp(got, lds->cmd)) {
+            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
+                " (xenstore paths `%s' / `%s')", lds->cmd, got,
+                lds->cmd_path, lds->ret_path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t); 
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+ out:
+    /* rc < 0: error
+     * rc == 0: ok, we are done
+     * rc == +1: need to keep waiting
+     */
+    libxl__xs_transaction_abort(gc, &t);
+
+    if (!rc) {
+        switch_logdirty_done(egc,dss,1);
+    } else if (rc < 0) {
+        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);
+        switch_logdirty_done(egc,dss,0);
+    }
+}
+
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok)
+{
+    STATE_AO_GC(dss->ao);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+
+    libxl__ev_xswatch_deregister(gc, &lds->watch);
+    libxl__ev_time_deregister(gc, &lds->timeout);
+
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, ok);
+}
+
+/*----- callbacks, called by xc_domain_save -----*/
+
 int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -873,6 +1023,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     libxl__srm_save_autogen_callbacks *const callbacks =
         &dss->shs.callbacks.save.a;
 
+    logdirty_init(&dss->logdirty);
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4634f5a..3b4d250 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1864,6 +1864,14 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
 
+typedef struct libxl__logdirty_switch {
+    const char *cmd;
+    const char *cmd_path;
+    const char *ret_path;
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+} libxl__logdirty_switch;
+
 struct libxl__domain_suspend_state {
     /* set by caller of libxl__domain_suspend */
     libxl__ao *ao;
@@ -1883,6 +1891,7 @@ struct libxl__domain_suspend_state {
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
+    libxl__logdirty_switch logdirty;
 };
 
 
@@ -2013,8 +2022,15 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
+/* Used by asynchronous callbacks: ie ones which xc regards as
+ * returning a value, but which we want to handle asynchronously.
+ * Such functions' actual callback function return void in libxl
+ * When they are ready to indicate completion, they call this. */
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value);
+
 _hidden int libxl__domain_suspend_common_callback(void *data);
-_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+_hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data);
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index a39f434..ded311c 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -128,6 +128,14 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
 }
 
 
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value)
+{
+    shs->egc = egc;
+    libxl__srm_callout_sendreply(return_value, shs);
+    shs->egc = 0;
+}
+
 /*----- helper execution -----*/
 
 static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index cd0837e..8832c46 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -14,6 +14,7 @@ our @msgs = (
     #   x  - function pointer is in struct {save,restore}_callbacks
     #         and its null-ness needs to be passed through to the helper's xc
     #   W  - needs a return value; callback is synchronous
+    #   A  - needs a return value; callback is asynchronous
     [  1, 'sr',     "log",                   [qw(uint32_t level
                                                  uint32_t errnoval
                                                  STRING context
@@ -25,7 +26,7 @@ our @msgs = (
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
     [  5, 'scxW',   "checkpoint", [] ],      
-    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+    [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
     [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
@@ -260,7 +261,7 @@ foreach my $msginfo (@msgs) {
         $f_more_sr->("        int r;\n");
     }
 
-    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_helper = $flags =~ m/[WA]/ ? 'int' : 'void';
     my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
     my $c_decl = '(';
     my $c_callback_args = '';
@@ -348,7 +349,7 @@ END
     assert(len == allocd);
     ${transmit}(buf, len, user);
 ");
-    if ($flags =~ m/W/) {
+    if ($flags =~ m/[WA]/) {
 	f_more("${encode}_$name", (<<END.($debug ? <<END : '').<<END));
     int r = ${helper}_getreply(user);
 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 Fri Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd355-0002bj-2P; Fri, 08 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd352-0002at-Qs
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:7994] by server-1.bemta-4.messagelabs.com id
	1E/0E-10042-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12642 invoked from network); 8 Jun 2012 17:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BM-6M; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd34z-0008WN-Nh;
	Fri, 08 Jun 2012 18:34:33 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:11 +0100
Message-ID: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v3 of my series to asyncify save/restore, rebased to current
tip, retested, and with all comments addressed.

In the list below "A" indicates a patch which has been acked
sufficiently to go in (assuming its dependencies were to go in too).
"*" indicates a new patch in v3.

Preparatory work:

   01/19 libxc: xc_domain_restore, make toolstack_restore const-correct
   02/19 libxl: domain save: rename variables etc.
   03/19 libxl: domain restore: reshuffle, preparing for ao
   04/19 libxl: domain save: API changes for asynchrony

The meat:

   05/19 libxl: domain save/restore: run in a separate process

Some fixups:

 A 06/19 libxl: rename libxl_dom:save_helper to physmap_path
   07/19 libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
   08/19 libxl: wait for qemu to acknowledge logdirty command

Asyncify writing of qemu save file, too:

   09/19 libxl: datacopier: provide "prefix data" facility
   10/19 libxl: prepare for asynchronous writing of qemu save file
   11/19 libxl: Make libxl__domain_save_device_model asynchronous

Fix gc_opt handling:

 * 12/19 libxl: Add a gc to libxl_get_cpu_topology
 * 13/19 libxl: Do not pass NULL as gc_opt; introduce NOGC
 * 14/19 libxl: Get compiler to warn about gc_opt==NULL

Work on essentially-unrelated bugs:

 A 15/19 xl: Handle return value from libxl_domain_suspend correctly
 A 16/19 libxl: do not leak dms->saved_state
   17/19 libxl: do not leak spawned middle children
 A 18/19 libxl: do not leak an event struct on ignored ao progress
 * 19/19 libxl: DO NOT APPLY enforce prohibition on internal

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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35A-0002gI-7h; Fri, 08 Jun 2012 17:34: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 1Sd354-0002bK-Ln
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:6290] by server-7.bemta-5.messagelabs.com id
	39/B9-19648-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16164 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001Bx-3m; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005c-0Q;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:24 +0100
Message-ID: <1339176870-32652-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: [Xen-devel] [PATCH 13/19] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc (and which replaces the previous
#define NOGC NULL).

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2a31528..a257902 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 00705d8..ab000bc 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -108,7 +108,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f90814a..e69482c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
-#define NOGC          NULL
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 67ef82c..08c7dac 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35A-0002gI-7h; Fri, 08 Jun 2012 17:34: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 1Sd354-0002bK-Ln
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:6290] by server-7.bemta-5.messagelabs.com id
	39/B9-19648-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16164 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001Bx-3m; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005c-0Q;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:24 +0100
Message-ID: <1339176870-32652-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: [Xen-devel] [PATCH 13/19] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc (and which replaces the previous
#define NOGC NULL).

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2a31528..a257902 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 00705d8..ab000bc 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -108,7 +108,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f90814a..e69482c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
-#define NOGC          NULL
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 67ef82c..08c7dac 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd357-0002dK-SJ; Fri, 08 Jun 2012 17:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002au-Dy
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8088] by server-2.bemta-4.messagelabs.com id
	E4/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12722 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001Bz-4f; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005g-2S;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:25 +0100
Message-ID: <1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
	gc_opt==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

Since it used to be legal to pass gc_opt==NULL, and there are various
patches floating about and under developmetn which do so, add a
compiler annotation which makes the build fail when that is done.

This turns a runtime crash into a build failure, and should ensure
that we don't accidentally commit a broken combination of patches.

This is something of an annoying approach because it adds a macro
invocation to the RHS of every declaration of a function taking a
gc_opt.  So it should be reverted after Xen 4.2rc1.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e69482c..8635764 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * psuedo-gc.
  */
 /* register ptr in gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
+
+#define NN1 __attribute__((nonnull(1)))
+ /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
+  * warn about this if any slip through. */
+
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
 
 /* Each of these logs errors and returns a libxl error code.
  * They do not mind if path is already removed.
-- 
1.7.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 Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd357-0002d7-Ga; Fri, 08 Jun 2012 17:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002at-3r
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:49257] by server-1.bemta-4.messagelabs.com id
	C1/1E-10042-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12714 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001Bt-0S; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005Y-UV;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:23 +0100
Message-ID: <1339176870-32652-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/19] libxl: Add a gc to libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.

libxl_get_cpu_topology doesn't have one but does use NOGC.
Fix this by:
 - introducing an `out' label
 - replacing the only call to `return' with a suitable assignment
   to ret and a `goto out'.
 - adding uses of GC_INIT and GC_FREE.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7de026b..2a31528 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3202,6 +3202,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
@@ -3214,7 +3215,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
     if (max_cpus == 0)
     {
         LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
-        return NULL;
+        ret = NULL;
+        goto out;
     }
 
     coremap = xc_hypercall_buffer_alloc
@@ -3259,6 +3261,8 @@ fail:
 
     if (ret)
         *nr = max_cpus;
+ out:
+    GC_FREE;
     return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 17:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35C-0002iY-96; Fri, 08 Jun 2012 17:34: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 1Sd355-0002au-9e
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:8089] by server-2.bemta-4.messagelabs.com id
	05/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15202 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bg-OA; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005I-Lo;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:19 +0100
Message-ID: <1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
	logdirty 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

The current migration code in libxl instructs qemu to start or stop
logdirty, but it does not wait for an acknowledgement from qemu before
continuing.  This might lead to memory corruption (!)

Fix this by waiting for qemu to acknowledge the command.

Unfortunately the necessary ao arrangements for waiting for this
command are unique because qemu has a special protocol for this
particular operation.

Also, this change means that the switch_qemu_logdirty callback
implementation in libxl can no longer synchronously produce its return
value, as it now needs to wait for xenstore.  So we tell the
marshalling code generator that it is a message which does not need a
reply.  This turns the callback function called by the marshaller into
one which returns void; the callback function arranges to later
explicitly sends the reply to the helper, when the xs watch triggers
and the appropriate value is read from xenstore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_dom.c            |  176 +++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h       |   18 ++++-
 tools/libxl/libxl_save_callout.c   |    8 ++
 tools/libxl/libxl_save_msgs_gen.pl |    7 +-
 4 files changed, 193 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a597627..d5ac79f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -528,30 +528,180 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
 static void domain_suspend_done(libxl__egc *egc,
                         libxl__domain_suspend_state *dss, int rc);
 
-/*----- callbacks, called by xc_domain_save -----*/
+/*----- complicated callback, called by xc_domain_save -----*/
+
+/*
+ * We implement the other end of protocol for controlling qemu-dm's
+ * logdirty.  There is no documentation for this protocol, but our
+ * counterparty's implementation is in
+ * qemu-xen-traditional.git:xenstore.c in the function
+ * xenstore_process_logdirty_event
+ */
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs);
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok);
 
-int libxl__domain_suspend_common_switch_qemu_logdirty
+static void logdirty_init(libxl__logdirty_switch *lds)
+{
+    lds->cmd_path = 0;
+    libxl__ev_xswatch_init(&lds->watch);
+    libxl__ev_time_init(&lds->timeout);
+}
+
+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);
+    libxl__logdirty_switch *lds = &dss->logdirty;
     STATE_AO_GC(dss->ao);
-    char *path;
-    bool rc;
+    int rc;
+    xs_transaction_t t = 0;
+    const char *got;
 
-    path = libxl__sprintf(gc,
+    if (!lds->cmd_path) {
+        lds->cmd_path = GCSPRINTF(
                    "/local/domain/0/device-model/%u/logdirty/cmd", domid);
-    if (!path)
-        return 1;
+        lds->ret_path = GCSPRINTF(
+                   "/local/domain/0/device-model/%u/logdirty/ret", domid);
+    }
+    lds->cmd = enable ? "enable" : "disable";
 
-    if (enable)
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
-    else
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
+    rc = libxl__ev_xswatch_register(gc, &lds->watch,
+                                switch_logdirty_xswatch, lds->ret_path);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_register_rel(gc, &lds->timeout,
+                                switch_logdirty_timeout, 10*1000);
+    if (rc) goto out;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->cmd_path, &got);
+        if (rc) goto out;
+
+        if (got) {
+            const char *got_ret;
+            rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got_ret);
+            if (rc) goto out;
 
-    return rc ? 0 : 1;
+            if (strcmp(got, got_ret)) {
+                LOG(ERROR,"controlling logdirty: qemu was already sent"
+                    " command `%s' (xenstore path `%s') but result is `%s'",
+                    got, lds->cmd_path, got_ret ? got_ret : "<none>");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+            rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+            if (rc) goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_write_checked(gc, t, lds->cmd_path, lds->cmd);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t);
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+    /* OK, wait for some callback */
+    return;
+
+ out:
+    LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+    switch_logdirty_done(egc,dss,0);
+}
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
+    STATE_AO_GC(dss->ao);
+    LOG(ERROR,"logdirty switch: wait for device model timed out");
+    switch_logdirty_done(egc,dss,0);
 }
 
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(watch, *dss, logdirty.watch);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+    STATE_AO_GC(dss->ao);
+    const char *got;
+    xs_transaction_t t = 0;
+    int rc;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
+        if (rc) goto out;
+
+        if (!got) {
+            rc = +1;
+            goto out;
+        }
+
+        if (strcmp(got, lds->cmd)) {
+            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
+                " (xenstore paths `%s' / `%s')", lds->cmd, got,
+                lds->cmd_path, lds->ret_path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t); 
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+ out:
+    /* rc < 0: error
+     * rc == 0: ok, we are done
+     * rc == +1: need to keep waiting
+     */
+    libxl__xs_transaction_abort(gc, &t);
+
+    if (!rc) {
+        switch_logdirty_done(egc,dss,1);
+    } else if (rc < 0) {
+        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);
+        switch_logdirty_done(egc,dss,0);
+    }
+}
+
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok)
+{
+    STATE_AO_GC(dss->ao);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+
+    libxl__ev_xswatch_deregister(gc, &lds->watch);
+    libxl__ev_time_deregister(gc, &lds->timeout);
+
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, ok);
+}
+
+/*----- callbacks, called by xc_domain_save -----*/
+
 int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -873,6 +1023,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     libxl__srm_save_autogen_callbacks *const callbacks =
         &dss->shs.callbacks.save.a;
 
+    logdirty_init(&dss->logdirty);
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4634f5a..3b4d250 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1864,6 +1864,14 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
 
+typedef struct libxl__logdirty_switch {
+    const char *cmd;
+    const char *cmd_path;
+    const char *ret_path;
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+} libxl__logdirty_switch;
+
 struct libxl__domain_suspend_state {
     /* set by caller of libxl__domain_suspend */
     libxl__ao *ao;
@@ -1883,6 +1891,7 @@ struct libxl__domain_suspend_state {
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
+    libxl__logdirty_switch logdirty;
 };
 
 
@@ -2013,8 +2022,15 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
+/* Used by asynchronous callbacks: ie ones which xc regards as
+ * returning a value, but which we want to handle asynchronously.
+ * Such functions' actual callback function return void in libxl
+ * When they are ready to indicate completion, they call this. */
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value);
+
 _hidden int libxl__domain_suspend_common_callback(void *data);
-_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+_hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data);
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index a39f434..ded311c 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -128,6 +128,14 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
 }
 
 
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value)
+{
+    shs->egc = egc;
+    libxl__srm_callout_sendreply(return_value, shs);
+    shs->egc = 0;
+}
+
 /*----- helper execution -----*/
 
 static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index cd0837e..8832c46 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -14,6 +14,7 @@ our @msgs = (
     #   x  - function pointer is in struct {save,restore}_callbacks
     #         and its null-ness needs to be passed through to the helper's xc
     #   W  - needs a return value; callback is synchronous
+    #   A  - needs a return value; callback is asynchronous
     [  1, 'sr',     "log",                   [qw(uint32_t level
                                                  uint32_t errnoval
                                                  STRING context
@@ -25,7 +26,7 @@ our @msgs = (
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
     [  5, 'scxW',   "checkpoint", [] ],      
-    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+    [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
     [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
@@ -260,7 +261,7 @@ foreach my $msginfo (@msgs) {
         $f_more_sr->("        int r;\n");
     }
 
-    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_helper = $flags =~ m/[WA]/ ? 'int' : 'void';
     my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
     my $c_decl = '(';
     my $c_callback_args = '';
@@ -348,7 +349,7 @@ END
     assert(len == allocd);
     ${transmit}(buf, len, user);
 ");
-    if ($flags =~ m/W/) {
+    if ($flags =~ m/[WA]/) {
 	f_more("${encode}_$name", (<<END.($debug ? <<END : '').<<END));
     int r = ${helper}_getreply(user);
 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 Fri Jun 08 17:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd35D-0002kL-Qh; Fri, 08 Jun 2012 17: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.Jackson@eu.citrix.com>) id 1Sd355-0002c8-Uz
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:40 +0000
Received: from [85.158.139.83:57205] by server-6.bemta-5.messagelabs.com id
	DB/33-18700-FA732DF4; Fri, 08 Jun 2012 17:34:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16178 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C9-Bi; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005x-Ai;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:29 +0100
Message-ID: <1339176870-32652-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/19] libxl: do not leak an event struct on
	ignored ao 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 entry to libxl__ao_progress_report, the caller has allocated an
event.  If the progress report is to be ignored, we need to free it.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index eb23a93..1957505 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1602,6 +1602,7 @@ void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
     ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
+        libxl_event_free(CTX,ev);
         /* ignore */
     } else if (how->callback) {
         libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
-- 
1.7.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 Jun 08 17:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd35D-0002kL-Qh; Fri, 08 Jun 2012 17: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.Jackson@eu.citrix.com>) id 1Sd355-0002c8-Uz
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:40 +0000
Received: from [85.158.139.83:57205] by server-6.bemta-5.messagelabs.com id
	DB/33-18700-FA732DF4; Fri, 08 Jun 2012 17:34:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16178 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C9-Bi; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005x-Ai;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:29 +0100
Message-ID: <1339176870-32652-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/19] libxl: do not leak an event struct on
	ignored ao 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 entry to libxl__ao_progress_report, the caller has allocated an
event.  If the progress report is to be ignored, we need to free it.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index eb23a93..1957505 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1602,6 +1602,7 @@ void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
     ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
+        libxl_event_free(CTX,ev);
         /* ignore */
     } else if (how->callback) {
         libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
-- 
1.7.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 Jun 08 17:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd35C-0002is-M4; Fri, 08 Jun 2012 17:34: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 1Sd355-0002av-1N
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:57057] by server-3.bemta-5.messagelabs.com id
	06/82-17554-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16098 invoked from network); 8 Jun 2012 17:34:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BT-Cd; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00004x-93;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 8 Jun 2012 18:34:14 +0100
Message-ID: <1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle,
	preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to arrange that libxl, instead of calling
xc_domain_restore, calls a stub function which forks and execs a
helper program, so that restore can be asynchronous rather than
blocking the whole toolstack.

This stub function will be called libxl__xc_domain_restore.

However, its prospective call site is unsuitable for a function which
needs to make a callback, and is buried in two nested single-call-site
functions which are logically part of the domain creation procedure.

So we first abolish those single-call-site functions, integrate their
contents into domain creation in their proper temporal order, and
break out libxl__xc_domain_restore ready for its reimplementation.

No functional change - just the following reorganisation:

* Abolish libxl__domain_restore_common, as it had only one caller.
  Move its contents into (what was) domain_restore.

* There is a new stage function domcreate_rebuild_done containing what
  used to be the bulk of domcreate_bootloader_done, since
  domcreate_bootloader_done now simply starts the restore (or does the
  rebuild) and arranges to call the next stage.

* Move the contents of domain_restore into its correct place in the
  domain creation sequence.  We put it inside
  domcreate_bootloader_done, which now either calls
  libxl__xc_domain_restore which will call the new function
  domcreate_rebuild_done.

* Various general-purpose local variables (`i' etc.) and convenience
  alias variables need to be shuffled about accordingly.

* Consequently libxl__toolstack_restore needs to gain external linkage
  as it is now in a different file to its user.

* Move the xc_domain_save callbacks struct from the stack into
  libxl__domain_create_state.

In general the moved code remains almost identical.  Two returns in
what used to be libxl__domain_restore_common have been changed to set
the return value and "goto out", and the call sites for the abolished
and new functions have been adjusted.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v2:
 * Also move the save callbacks
---
 tools/libxl/Makefile             |    1 +
 tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
 tools/libxl/libxl_dom.c          |   45 +-------
 tools/libxl/libxl_internal.h     |   19 +++-
 tools/libxl/libxl_save_callout.c |   37 ++++++
 5 files changed, 206 insertions(+), 140 deletions(-)
 create mode 100644 tools/libxl/libxl_save_callout.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e7d5cc2..1d8b80a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
+			libxl_save_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4456ae8..4439367 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -21,7 +21,6 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
-#include <xenguest.h>
 
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -317,89 +316,6 @@ out:
     return ret;
 }
 
-static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
-                          uint32_t domid, int fd,
-                          libxl__domain_build_state *state)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    char **vments = NULL, **localents = NULL;
-    struct timeval start_time;
-    int i, ret, esave, flags;
-
-    ret = libxl__build_pre(gc, domid, info, state);
-    if (ret)
-        goto out;
-
-    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
-    if (ret)
-        goto out;
-
-    gettimeofday(&start_time, NULL);
-
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        vments = libxl__calloc(gc, 7, sizeof(char *));
-        vments[0] = "rtc/timeoffset";
-        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
-        vments[2] = "image/ostype";
-        vments[3] = "hvm";
-        vments[4] = "start_time";
-        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        vments = libxl__calloc(gc, 11, sizeof(char *));
-        i = 0;
-        vments[i++] = "image/ostype";
-        vments[i++] = "linux";
-        vments[i++] = "image/kernel";
-        vments[i++] = (char *) state->pv_kernel.path;
-        vments[i++] = "start_time";
-        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        if (state->pv_ramdisk.path) {
-            vments[i++] = "image/ramdisk";
-            vments[i++] = (char *) state->pv_ramdisk.path;
-        }
-        if (state->pv_cmdline) {
-            vments[i++] = "image/cmdline";
-            vments[i++] = (char *) state->pv_cmdline;
-        }
-        break;
-    default:
-        ret = ERROR_INVAL;
-        goto out;
-    }
-    ret = libxl__build_post(gc, domid, info, state, vments, localents);
-    if (ret)
-        goto out;
-
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
-                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
-    }
-
-out:
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
-        libxl__file_reference_unmap(&state->pv_kernel);
-        libxl__file_reference_unmap(&state->pv_ramdisk);
-    }
-
-    esave = errno;
-
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
-    } else {
-        flags &= ~O_NONBLOCK;
-        if (fcntl(fd, F_SETFL, flags) == -1)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
-                         " back to blocking mode");
-    }
-
-    errno = esave;
-    return ret;
-}
-
 int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
@@ -580,10 +496,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
-
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -671,20 +590,20 @@ static void domcreate_console_available(libxl__egc *egc,
 
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
-                                      int ret)
+                                      int rc)
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    libxl_ctx *const ctx = CTX;
+    struct restore_callbacks *const callbacks = &dcs->callbacks;
 
-    if (ret) goto error_out;
+    if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
     /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
      * been initialised by the bootloader already.
@@ -700,12 +619,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
+    if ( restore_fd < 0 ) {
+        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    /* Restore */
+
+    rc = libxl__build_pre(gc, domid, info, state);
+    if (rc)
+        goto out;
+
+    /* read signature */
+    int hvm, pae, superpages;
+    int no_incr_generationid;
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        hvm = 1;
+        superpages = 1;
+        pae = libxl_defbool_val(info->u.hvm.pae);
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        hvm = 0;
+        superpages = 0;
+        pae = 1;
+        no_incr_generationid = 0;
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+    libxl__xc_domain_restore(egc, dcs,
+                             hvm, pae, superpages, no_incr_generationid);
+    return;
+
+ out:
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret, int retval, int errnoval)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char **vments = NULL, **localents = NULL;
+    struct timeval start_time;
+    int i, esave, flags;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    const int fd = dcs->restore_fd;
+
+    if (ret)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "restoring domain");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    gettimeofday(&start_time, NULL);
+
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        vments = libxl__calloc(gc, 7, sizeof(char *));
+        vments[0] = "rtc/timeoffset";
+        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
+        vments[2] = "image/ostype";
+        vments[3] = "hvm";
+        vments[4] = "start_time";
+        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        vments = libxl__calloc(gc, 11, sizeof(char *));
+        i = 0;
+        vments[i++] = "image/ostype";
+        vments[i++] = "linux";
+        vments[i++] = "image/kernel";
+        vments[i++] = (char *) state->pv_kernel.path;
+        vments[i++] = "start_time";
+        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        if (state->pv_ramdisk.path) {
+            vments[i++] = "image/ramdisk";
+            vments[i++] = (char *) state->pv_ramdisk.path;
+        }
+        if (state->pv_cmdline) {
+            vments[i++] = "image/cmdline";
+            vments[i++] = (char *) state->pv_cmdline;
+        }
+        break;
+    default:
+        ret = ERROR_INVAL;
+        goto out;
+    }
+    ret = libxl__build_post(gc, domid, info, state, vments, localents);
+    if (ret)
+        goto out;
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = asprintf(&state->saved_state,
+                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+        ret = (ret < 0) ? ERROR_FAIL : 0;
+    }
+
+out:
+    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+        libxl__file_reference_unmap(&state->pv_kernel);
+        libxl__file_reference_unmap(&state->pv_ramdisk);
+    }
+
+    esave = errno;
+
+    flags = fcntl(fd, F_GETFL);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        flags &= ~O_NONBLOCK;
+        if (fcntl(fd, F_SETFL, flags) == -1)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
+                         " back to blocking mode");
     }
 
+    errno = esave;
+    domcreate_rebuild_done(egc, dcs, ret);
+}
+
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret)
+{
+    STATE_AO_GC(dcs->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
         ret = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e90030d..1d4e809 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -19,7 +19,6 @@
 
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xenguest.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
@@ -467,7 +466,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = data;
@@ -522,48 +521,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                 libxl_domain_build_info *info,
-                                 libxl__domain_build_state *state,
-                                 int fd)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    /* read signature */
-    int rc;
-    int hvm, pae, superpages;
-    struct restore_callbacks callbacks[1];
-    int no_incr_generationid;
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        hvm = 1;
-        superpages = 1;
-        pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        hvm = 0;
-        superpages = 0;
-        pae = 1;
-        no_incr_generationid = 0;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-    rc = xc_domain_restore(ctx->xch, fd, domid,
-                           state->store_port, &state->store_mfn,
-                           state->store_domid, state->console_port,
-                           &state->console_mfn, state->console_domid,
-                           hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, callbacks);
-    if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 static int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f22bf94..28478ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -46,6 +46,7 @@
 
 #include <xenstore.h>
 #include <xenctrl.h>
+#include <xenguest.h>
 
 #include "xentoollog.h"
 
@@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
 
-_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                         libxl_domain_build_info *info,
-                                         libxl__domain_build_state *state,
-                                         int fd);
+_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+                                     uint32_t size, void *data);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    struct restore_callbacks callbacks;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          int live, int debug,
                                          const libxl_domain_remus_info *r_info);
 
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_restore(libxl__egc *egc,
+                                      libxl__domain_create_state *dcs,
+                                      int hvm, int pae, int superpages,
+                                      int no_incr_generationid);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                           libxl__domain_create_state *dcs,
+                                           int rc, int retval, int errnoval);
 
 
 /*
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
new file mode 100644
index 0000000..2f8db9f
--- /dev/null
+++ b/tools/libxl/libxl_save_callout.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h"
+
+#include "libxl_internal.h"
+
+void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
+                              int hvm, int pae, int superpages,
+                              int no_incr_generationid)
+{
+    STATE_AO_GC(dcs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
+                              state->store_port, &state->store_mfn,
+                              state->store_domid, state->console_port,
+                              &state->console_mfn, state->console_domid,
+                              hvm, pae, superpages, no_incr_generationid,
+                              &state->vm_generationid_addr, &dcs->callbacks);
+    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+}
-- 
1.7.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 Jun 08 17:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd35C-0002is-M4; Fri, 08 Jun 2012 17:34: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 1Sd355-0002av-1N
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:57057] by server-3.bemta-5.messagelabs.com id
	06/82-17554-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16098 invoked from network); 8 Jun 2012 17:34:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BT-Cd; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00004x-93;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 8 Jun 2012 18:34:14 +0100
Message-ID: <1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle,
	preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to arrange that libxl, instead of calling
xc_domain_restore, calls a stub function which forks and execs a
helper program, so that restore can be asynchronous rather than
blocking the whole toolstack.

This stub function will be called libxl__xc_domain_restore.

However, its prospective call site is unsuitable for a function which
needs to make a callback, and is buried in two nested single-call-site
functions which are logically part of the domain creation procedure.

So we first abolish those single-call-site functions, integrate their
contents into domain creation in their proper temporal order, and
break out libxl__xc_domain_restore ready for its reimplementation.

No functional change - just the following reorganisation:

* Abolish libxl__domain_restore_common, as it had only one caller.
  Move its contents into (what was) domain_restore.

* There is a new stage function domcreate_rebuild_done containing what
  used to be the bulk of domcreate_bootloader_done, since
  domcreate_bootloader_done now simply starts the restore (or does the
  rebuild) and arranges to call the next stage.

* Move the contents of domain_restore into its correct place in the
  domain creation sequence.  We put it inside
  domcreate_bootloader_done, which now either calls
  libxl__xc_domain_restore which will call the new function
  domcreate_rebuild_done.

* Various general-purpose local variables (`i' etc.) and convenience
  alias variables need to be shuffled about accordingly.

* Consequently libxl__toolstack_restore needs to gain external linkage
  as it is now in a different file to its user.

* Move the xc_domain_save callbacks struct from the stack into
  libxl__domain_create_state.

In general the moved code remains almost identical.  Two returns in
what used to be libxl__domain_restore_common have been changed to set
the return value and "goto out", and the call sites for the abolished
and new functions have been adjusted.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v2:
 * Also move the save callbacks
---
 tools/libxl/Makefile             |    1 +
 tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
 tools/libxl/libxl_dom.c          |   45 +-------
 tools/libxl/libxl_internal.h     |   19 +++-
 tools/libxl/libxl_save_callout.c |   37 ++++++
 5 files changed, 206 insertions(+), 140 deletions(-)
 create mode 100644 tools/libxl/libxl_save_callout.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e7d5cc2..1d8b80a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
+			libxl_save_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4456ae8..4439367 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -21,7 +21,6 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
-#include <xenguest.h>
 
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -317,89 +316,6 @@ out:
     return ret;
 }
 
-static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
-                          uint32_t domid, int fd,
-                          libxl__domain_build_state *state)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    char **vments = NULL, **localents = NULL;
-    struct timeval start_time;
-    int i, ret, esave, flags;
-
-    ret = libxl__build_pre(gc, domid, info, state);
-    if (ret)
-        goto out;
-
-    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
-    if (ret)
-        goto out;
-
-    gettimeofday(&start_time, NULL);
-
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        vments = libxl__calloc(gc, 7, sizeof(char *));
-        vments[0] = "rtc/timeoffset";
-        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
-        vments[2] = "image/ostype";
-        vments[3] = "hvm";
-        vments[4] = "start_time";
-        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        vments = libxl__calloc(gc, 11, sizeof(char *));
-        i = 0;
-        vments[i++] = "image/ostype";
-        vments[i++] = "linux";
-        vments[i++] = "image/kernel";
-        vments[i++] = (char *) state->pv_kernel.path;
-        vments[i++] = "start_time";
-        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        if (state->pv_ramdisk.path) {
-            vments[i++] = "image/ramdisk";
-            vments[i++] = (char *) state->pv_ramdisk.path;
-        }
-        if (state->pv_cmdline) {
-            vments[i++] = "image/cmdline";
-            vments[i++] = (char *) state->pv_cmdline;
-        }
-        break;
-    default:
-        ret = ERROR_INVAL;
-        goto out;
-    }
-    ret = libxl__build_post(gc, domid, info, state, vments, localents);
-    if (ret)
-        goto out;
-
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
-                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
-    }
-
-out:
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
-        libxl__file_reference_unmap(&state->pv_kernel);
-        libxl__file_reference_unmap(&state->pv_ramdisk);
-    }
-
-    esave = errno;
-
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
-    } else {
-        flags &= ~O_NONBLOCK;
-        if (fcntl(fd, F_SETFL, flags) == -1)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
-                         " back to blocking mode");
-    }
-
-    errno = esave;
-    return ret;
-}
-
 int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
@@ -580,10 +496,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
-
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -671,20 +590,20 @@ static void domcreate_console_available(libxl__egc *egc,
 
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
-                                      int ret)
+                                      int rc)
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    libxl_ctx *const ctx = CTX;
+    struct restore_callbacks *const callbacks = &dcs->callbacks;
 
-    if (ret) goto error_out;
+    if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
     /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
      * been initialised by the bootloader already.
@@ -700,12 +619,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
+    if ( restore_fd < 0 ) {
+        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    /* Restore */
+
+    rc = libxl__build_pre(gc, domid, info, state);
+    if (rc)
+        goto out;
+
+    /* read signature */
+    int hvm, pae, superpages;
+    int no_incr_generationid;
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        hvm = 1;
+        superpages = 1;
+        pae = libxl_defbool_val(info->u.hvm.pae);
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        hvm = 0;
+        superpages = 0;
+        pae = 1;
+        no_incr_generationid = 0;
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+    libxl__xc_domain_restore(egc, dcs,
+                             hvm, pae, superpages, no_incr_generationid);
+    return;
+
+ out:
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret, int retval, int errnoval)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char **vments = NULL, **localents = NULL;
+    struct timeval start_time;
+    int i, esave, flags;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    const int fd = dcs->restore_fd;
+
+    if (ret)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "restoring domain");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    gettimeofday(&start_time, NULL);
+
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        vments = libxl__calloc(gc, 7, sizeof(char *));
+        vments[0] = "rtc/timeoffset";
+        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
+        vments[2] = "image/ostype";
+        vments[3] = "hvm";
+        vments[4] = "start_time";
+        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        vments = libxl__calloc(gc, 11, sizeof(char *));
+        i = 0;
+        vments[i++] = "image/ostype";
+        vments[i++] = "linux";
+        vments[i++] = "image/kernel";
+        vments[i++] = (char *) state->pv_kernel.path;
+        vments[i++] = "start_time";
+        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        if (state->pv_ramdisk.path) {
+            vments[i++] = "image/ramdisk";
+            vments[i++] = (char *) state->pv_ramdisk.path;
+        }
+        if (state->pv_cmdline) {
+            vments[i++] = "image/cmdline";
+            vments[i++] = (char *) state->pv_cmdline;
+        }
+        break;
+    default:
+        ret = ERROR_INVAL;
+        goto out;
+    }
+    ret = libxl__build_post(gc, domid, info, state, vments, localents);
+    if (ret)
+        goto out;
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = asprintf(&state->saved_state,
+                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+        ret = (ret < 0) ? ERROR_FAIL : 0;
+    }
+
+out:
+    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+        libxl__file_reference_unmap(&state->pv_kernel);
+        libxl__file_reference_unmap(&state->pv_ramdisk);
+    }
+
+    esave = errno;
+
+    flags = fcntl(fd, F_GETFL);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        flags &= ~O_NONBLOCK;
+        if (fcntl(fd, F_SETFL, flags) == -1)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
+                         " back to blocking mode");
     }
 
+    errno = esave;
+    domcreate_rebuild_done(egc, dcs, ret);
+}
+
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret)
+{
+    STATE_AO_GC(dcs->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
         ret = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e90030d..1d4e809 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -19,7 +19,6 @@
 
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xenguest.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
@@ -467,7 +466,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = data;
@@ -522,48 +521,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                 libxl_domain_build_info *info,
-                                 libxl__domain_build_state *state,
-                                 int fd)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    /* read signature */
-    int rc;
-    int hvm, pae, superpages;
-    struct restore_callbacks callbacks[1];
-    int no_incr_generationid;
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        hvm = 1;
-        superpages = 1;
-        pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        hvm = 0;
-        superpages = 0;
-        pae = 1;
-        no_incr_generationid = 0;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-    rc = xc_domain_restore(ctx->xch, fd, domid,
-                           state->store_port, &state->store_mfn,
-                           state->store_domid, state->console_port,
-                           &state->console_mfn, state->console_domid,
-                           hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, callbacks);
-    if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 static int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f22bf94..28478ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -46,6 +46,7 @@
 
 #include <xenstore.h>
 #include <xenctrl.h>
+#include <xenguest.h>
 
 #include "xentoollog.h"
 
@@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
 
-_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                         libxl_domain_build_info *info,
-                                         libxl__domain_build_state *state,
-                                         int fd);
+_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+                                     uint32_t size, void *data);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    struct restore_callbacks callbacks;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          int live, int debug,
                                          const libxl_domain_remus_info *r_info);
 
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_restore(libxl__egc *egc,
+                                      libxl__domain_create_state *dcs,
+                                      int hvm, int pae, int superpages,
+                                      int no_incr_generationid);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                           libxl__domain_create_state *dcs,
+                                           int rc, int retval, int errnoval);
 
 
 /*
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
new file mode 100644
index 0000000..2f8db9f
--- /dev/null
+++ b/tools/libxl/libxl_save_callout.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h"
+
+#include "libxl_internal.h"
+
+void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
+                              int hvm, int pae, int superpages,
+                              int no_incr_generationid)
+{
+    STATE_AO_GC(dcs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
+                              state->store_port, &state->store_mfn,
+                              state->store_domid, state->console_port,
+                              &state->console_mfn, state->console_domid,
+                              hvm, pae, superpages, no_incr_generationid,
+                              &state->vm_generationid_addr, &dcs->callbacks);
+    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+}
-- 
1.7.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 Jun 08 17:35:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35D-0002jJ-2M; Fri, 08 Jun 2012 17:34: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 1Sd355-0002at-GF
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:49283] by server-1.bemta-4.messagelabs.com id
	63/1E-10042-EA732DF4; Fri, 08 Jun 2012 17:34:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15283 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C8-BW; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005t-8o;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:28 +0100
Message-ID: <1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn would, when libxl__spawn_detach was called, make
the spawn become idle immediately.  However it still has a child
process which needs to be waited for: the `detachable' spawned
child.

This is wrong because the ultimate in-libxl caller may return to the
application, with a child process still forked but not reaped libxl
contrary to the documented behaviour of libxl.

Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
which is asynchronous.  The detachable spawned children are abolished;
instead, we defer calling back to the in-libxl user until the middle
child has been reaped.

Also, remove erroneous comment suggesting that `death' callback
parameter to libxl__ev_child_fork may be NULL.  It may not, and there
are no callers which pass NULL.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3 of series:
 * Now also remove erroneous comment about NULL fork death callback.
---
 tools/libxl/libxl_dm.c       |   14 ++++-
 tools/libxl/libxl_exec.c     |  124 ++++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   43 ++++++++-------
 3 files changed, 104 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..b3de145 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -908,6 +908,8 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
 static void device_model_startup_failed(libxl__egc *egc,
                                         libxl__spawn_state *spawn);
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn);
 
 /* our "next step" function, called from those callbacks and elsewhere */
 static void device_model_spawn_outcome(libxl__egc *egc,
@@ -1015,6 +1017,7 @@ retry_transaction:
     spawn->midproc_cb = libxl__spawn_record_pid;
     spawn->confirm_cb = device_model_confirm;
     spawn->failure_cb = device_model_startup_failed;
+    spawn->detached_cb = device_model_detached;
 
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
@@ -1048,9 +1051,7 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
     if (strcmp(xsdata, "running"))
         return;
 
-    libxl__spawn_detach(gc, spawn);
-
-    device_model_spawn_outcome(egc, dmss, 0);
+    libxl__spawn_initiate_detach(gc, spawn);
 }
 
 static void device_model_startup_failed(libxl__egc *egc,
@@ -1060,6 +1061,13 @@ static void device_model_startup_failed(libxl__egc *egc,
     device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
 }
 
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, 0);
+}
+
 static void device_model_spawn_outcome(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index cfa379c..bb85682 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -238,15 +238,16 @@ err:
 /*
  * Full set of possible states of a libxl__spawn_state and its _detachable:
  *
- *               ss->        ss->        ss->    | ssd->       ssd->
- *               timeout     xswatch     ssd     |  mid         ss
- *  - Undefined   undef       undef       no     |  -           -
- *  - Idle        Idle        Idle        no     |  -           -
- *  - Active      Active      Active      yes    |  Active      yes
- *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
- *  - Detached    -           -           -      |  Active      no
+ *                   detaching failed  mid     timeout      xswatch          
+ *  - Undefined         undef   undef   -        undef        undef
+ *  - Idle              any     any     Idle     Idle         Idle
+ *  - Attached OK       0       0       Active   Active       Active
+ *  - Attached Failed   0       1       Active   Idle         Idle
+ *  - Detaching         1       maybe   Active   Idle         Idle
+ *  - Partial           any     any     Idle     Active/Idle  Active/Idle
  *
- * When in state Detached, the middle process has been sent a SIGKILL.
+ * When in states Detaching or Attached Failed, the middle process has
+ * been sent a SIGKILL.
  */
 
 /* Event callbacks. */
@@ -257,19 +258,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status);
 
-/* Precondition: Partial.  Results: Detached. */
+/* Precondition: Partial.  Results: Idle. */
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-/* Precondition: Partial; caller has logged failure reason.
- * Results: Caller notified of failure;
- *  after return, ss may be completely invalid as caller may reuse it */
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
+/* Precondition: Attached or Detaching; caller has logged failure reason.
+ * Results: Detaching, or Attached Failing */
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss);
 
 void libxl__spawn_init(libxl__spawn_state *ss)
 {
+    libxl__ev_child_init(&ss->mid);
     libxl__ev_time_init(&ss->timeout);
     libxl__ev_xswatch_init(&ss->xswatch);
-    ss->ssd = 0;
 }
 
 int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -280,8 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
-    libxl__ev_child_init(&ss->ssd->mid);
+    ss->failed = ss->detaching = 0;
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
                                      spawn_timeout, ss->timeout_ms);
@@ -291,7 +290,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
                                     spawn_watch_event, ss->xspath);
     if (rc) goto out_err;
 
-    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    pid_t middle = libxl__ev_child_fork(gc, &ss->mid, spawn_middle_death);
     if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
 
     if (middle) {
@@ -344,54 +343,64 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
+    assert(!libxl__ev_child_inuse(&ss->mid));
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+}
+
+static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+/* Precondition: Attached or Detaching, but caller must have just set
+ * at least one of detaching or failed.
+ * Results: Detaching or Attached Failed */
+{
     int r;
 
+    assert(libxl__ev_child_inuse(&ss->mid));
     libxl__ev_time_deregister(gc, &ss->timeout);
     libxl__ev_xswatch_deregister(gc, &ss->xswatch);
 
-    libxl__spawn_state_detachable *ssd = ss->ssd;
-    if (ssd) {
-        if (libxl__ev_child_inuse(&ssd->mid)) {
-            pid_t child = ssd->mid.pid;
-            r = kill(child, SIGKILL);
-            if (r && errno != ESRCH)
-                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
-                     ss->what, (unsigned long)child);
-        }
+    pid_t child = ss->mid.pid;
+    r = kill(child, SIGKILL);
+    if (r && errno != ESRCH)
+        LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+             ss->what, (unsigned long)child);
+}
 
-        /* disconnect the ss and ssd from each other */
-        ssd->ss = 0;
-        ss->ssd = 0;
-    }
+void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    ss->detaching = 1;
+    spawn_detach(gc, ss);
 }
 
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss)
+/* Caller must have logged.  Must be last thing in calling function,
+ * as it may make the callback.  Precondition: Attached or Detaching. */
 {
     EGC_GC;
-    spawn_cleanup(gc, ss);
-    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+    ss->failed = 1;
+    spawn_detach(gc, ss);
 }
 
 static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
                           const struct timeval *requested_abs)
 {
-    /* Before event, was Active; is now Partial. */
+    /* Before event, was Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
     LOG(ERROR, "%s: startup timed out", ss->what);
-    spawn_failed(egc, ss); /* must be last */
+    spawn_fail(egc, ss); /* must be last */
 }
 
 static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
                               const char *watch_path, const char *event_path)
 {
-    /* On entry, is Active. */
+    /* On entry, is Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
     char *p = libxl__xs_read(gc, 0, ss->xspath);
     if (!p && errno != ENOENT) {
         LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
-        spawn_failed(egc, ss); /* must be last */
+        spawn_fail(egc, ss); /* must be last */
         return;
     }
     ss->confirm_cb(egc, ss, p); /* must be last */
@@ -399,20 +408,22 @@ static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
 
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status)
-    /* Before event, was Active or Detached;
-     * is now Active or Detached except that ssd->mid is Idle */
+    /* On entry, is Attached or Detaching */
 {
     EGC_GC;
-    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
-    libxl__spawn_state *ss = ssd->ss;
-
-    if (!WIFEXITED(status)) {
+    libxl__spawn_state *ss = CONTAINER_OF(childw, *ss, mid);
+
+    if ((ss->failed || ss->detaching) &&
+        ((WIFEXITED(status) && WEXITSTATUS(status)==0) ||
+         (WIFSIGNALED(status) && WTERMSIG(status)==SIGKILL))) {
+        /* as expected */
+    } else if (!WIFEXITED(status)) {
+        int loglevel = ss->detaching ? XTL_WARN : XTL_ERROR;
         const char *what =
-            GCSPRINTF("%s intermediate process (startup monitor)",
-                      ss ? ss->what : "(detached)");
-        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+            GCSPRINTF("%s intermediate process (startup monitor)", ss->what);
         libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
-    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        ss->failed = 1;
+    } else {
         if (!status)
             LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
                 " when we were waiting for it to confirm startup",
@@ -430,15 +441,22 @@ static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                 LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
                     " signal number %d", ss->what, (unsigned long)pid, sig);
         }
-        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
-        spawn_failed(egc, ss); /* must be last use of ss */
+        ss->failed = 1;
     }
-    free(ssd);
-}
 
-void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
-{
     spawn_cleanup(gc, ss);
+
+    if (ss->failed && !ss->detaching) {
+        ss->failure_cb(egc, ss); /* must be last */
+        return;
+    }
+    
+    if (ss->failed && ss->detaching)
+        LOG(WARN,"%s underlying machinery seemed to fail,"
+            " but its function seems to have been successful", ss->what);
+
+    assert(ss->detaching);
+    ss->detached_cb(egc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8635764..f9ee949 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -690,8 +690,7 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
  * the libxl event machinery.
  *
  * The parent may signal the child but it must not reap it.  That will
- * be done by the event machinery.  death may be NULL in which case
- * the child is still reaped but its death is ignored.
+ * be done by the event machinery.
  *
  * It is not possible to "deregister" the child death event source.
  * It will generate exactly one event callback; until then the childw
@@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
  *
  * Higher-level double-fork and separate detach eg as for device models
  *
- * Each libxl__spawn_state is in one of the conventional states
- *    Undefined, Idle, Active
+ * Each libxl__spawn_state is in one of these states
+ *    Undefined, Idle, Attached, Detaching
  */
 
 typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
@@ -1040,15 +1039,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
  * intermediate or final child; an error message will have been
  * logged.
  *
- * confirm_cb and failure_cb will not be called reentrantly from
- * within libxl__spawn_spawn.
+ * confirm_cb, failure_cb and detached_cb will not be called
+ * reentrantly from within libxl__spawn_spawn.
  *
  * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
  *  < 0   error, *spawn is now Idle and need not be detached
- *   +1   caller is the parent, *spawn is Active and must eventually be detached
+ *   +1   caller is the parent, *spawn is Attached and must be detached
  *    0   caller is now the inner child, should probably call libxl__exec
  *
  * The spawn state must be Undefined or Idle on entry.
@@ -1056,12 +1055,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
 _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl__spawn_detach - Detaches the daemonic child.
+ * libxl__spawn_request_detach - Detaches the daemonic child.
  *
  * Works by killing the intermediate process from spawn_spawn.
  * After this function returns, failures of either child are no
  * longer reported via failure_cb.
  *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
  * If called before the inner child has been created, this may prevent
  * it from running at all.  Thus this should be called only when the
  * inner child has notified that it is ready.  Normally it will be
@@ -1069,10 +1071,10 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
  *
  * Logs errors.
  *
- * The spawn state must be Active or Idle on entry and will be Idle
+ * The spawn state must be Attached entry and will be Detaching
  * on return.
  */
-_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
+_hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
  * If successful, this should return 0.
@@ -1109,15 +1111,11 @@ typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
 typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
                                      const char *xsdata);
 
-typedef struct {
-    /* Private to the spawn implementation.
-     */
-    /* This separate struct, from malloc, allows us to "detach"
-     * the child and reap it later, when our user has gone
-     * away and freed its libxl__spawn_state */
-    struct libxl__spawn_state *ss;
-    libxl__ev_child mid;
-} libxl__spawn_state_detachable;
+/*
+ * Called when the detach (requested by libxl__spawn_initiate_detach) has
+ * completed.  On entry to the callback the spawn state is Idle.
+ */
+typedef void libxl__spawn_detached_cb(libxl__egc*, libxl__spawn_state*);
 
 struct libxl__spawn_state {
     /* must be filled in by user and remain valid */
@@ -1129,15 +1127,18 @@ struct libxl__spawn_state {
     libxl__spawn_midproc_cb *midproc_cb;
     libxl__spawn_failure_cb *failure_cb;
     libxl__spawn_confirm_cb *confirm_cb;
+    libxl__spawn_detached_cb *detached_cb;
 
     /* remaining fields are private to libxl_spawn_... */
+    int detaching; /* we are in Detaching */
+    int failed; /* might be true whenever we are not Idle */
+    libxl__ev_child mid; /* always in use whenever we are not Idle */
     libxl__ev_time timeout;
     libxl__ev_xswatch xswatch;
-    libxl__spawn_state_detachable *ssd;
 };
 
 static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
-    { return !!ss->ssd; }
+    { return libxl__ev_child_inuse(&ss->mid); }
 
 /*
  * libxl_spawner_record_pid - Record given pid in xenstore
-- 
1.7.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 Jun 08 17:35:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17:35: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 1Sd35D-0002jJ-2M; Fri, 08 Jun 2012 17:34: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 1Sd355-0002at-GF
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:49283] by server-1.bemta-4.messagelabs.com id
	63/1E-10042-EA732DF4; Fri, 08 Jun 2012 17:34:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339176877!31411121!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15283 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001C8-BW; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-00005t-8o;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:28 +0100
Message-ID: <1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn would, when libxl__spawn_detach was called, make
the spawn become idle immediately.  However it still has a child
process which needs to be waited for: the `detachable' spawned
child.

This is wrong because the ultimate in-libxl caller may return to the
application, with a child process still forked but not reaped libxl
contrary to the documented behaviour of libxl.

Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
which is asynchronous.  The detachable spawned children are abolished;
instead, we defer calling back to the in-libxl user until the middle
child has been reaped.

Also, remove erroneous comment suggesting that `death' callback
parameter to libxl__ev_child_fork may be NULL.  It may not, and there
are no callers which pass NULL.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3 of series:
 * Now also remove erroneous comment about NULL fork death callback.
---
 tools/libxl/libxl_dm.c       |   14 ++++-
 tools/libxl/libxl_exec.c     |  124 ++++++++++++++++++++++++------------------
 tools/libxl/libxl_internal.h |   43 ++++++++-------
 3 files changed, 104 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..b3de145 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -908,6 +908,8 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
 static void device_model_startup_failed(libxl__egc *egc,
                                         libxl__spawn_state *spawn);
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn);
 
 /* our "next step" function, called from those callbacks and elsewhere */
 static void device_model_spawn_outcome(libxl__egc *egc,
@@ -1015,6 +1017,7 @@ retry_transaction:
     spawn->midproc_cb = libxl__spawn_record_pid;
     spawn->confirm_cb = device_model_confirm;
     spawn->failure_cb = device_model_startup_failed;
+    spawn->detached_cb = device_model_detached;
 
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
@@ -1048,9 +1051,7 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
     if (strcmp(xsdata, "running"))
         return;
 
-    libxl__spawn_detach(gc, spawn);
-
-    device_model_spawn_outcome(egc, dmss, 0);
+    libxl__spawn_initiate_detach(gc, spawn);
 }
 
 static void device_model_startup_failed(libxl__egc *egc,
@@ -1060,6 +1061,13 @@ static void device_model_startup_failed(libxl__egc *egc,
     device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
 }
 
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, 0);
+}
+
 static void device_model_spawn_outcome(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index cfa379c..bb85682 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -238,15 +238,16 @@ err:
 /*
  * Full set of possible states of a libxl__spawn_state and its _detachable:
  *
- *               ss->        ss->        ss->    | ssd->       ssd->
- *               timeout     xswatch     ssd     |  mid         ss
- *  - Undefined   undef       undef       no     |  -           -
- *  - Idle        Idle        Idle        no     |  -           -
- *  - Active      Active      Active      yes    |  Active      yes
- *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
- *  - Detached    -           -           -      |  Active      no
+ *                   detaching failed  mid     timeout      xswatch          
+ *  - Undefined         undef   undef   -        undef        undef
+ *  - Idle              any     any     Idle     Idle         Idle
+ *  - Attached OK       0       0       Active   Active       Active
+ *  - Attached Failed   0       1       Active   Idle         Idle
+ *  - Detaching         1       maybe   Active   Idle         Idle
+ *  - Partial           any     any     Idle     Active/Idle  Active/Idle
  *
- * When in state Detached, the middle process has been sent a SIGKILL.
+ * When in states Detaching or Attached Failed, the middle process has
+ * been sent a SIGKILL.
  */
 
 /* Event callbacks. */
@@ -257,19 +258,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status);
 
-/* Precondition: Partial.  Results: Detached. */
+/* Precondition: Partial.  Results: Idle. */
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-/* Precondition: Partial; caller has logged failure reason.
- * Results: Caller notified of failure;
- *  after return, ss may be completely invalid as caller may reuse it */
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
+/* Precondition: Attached or Detaching; caller has logged failure reason.
+ * Results: Detaching, or Attached Failing */
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss);
 
 void libxl__spawn_init(libxl__spawn_state *ss)
 {
+    libxl__ev_child_init(&ss->mid);
     libxl__ev_time_init(&ss->timeout);
     libxl__ev_xswatch_init(&ss->xswatch);
-    ss->ssd = 0;
 }
 
 int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -280,8 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
-    libxl__ev_child_init(&ss->ssd->mid);
+    ss->failed = ss->detaching = 0;
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
                                      spawn_timeout, ss->timeout_ms);
@@ -291,7 +290,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
                                     spawn_watch_event, ss->xspath);
     if (rc) goto out_err;
 
-    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    pid_t middle = libxl__ev_child_fork(gc, &ss->mid, spawn_middle_death);
     if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
 
     if (middle) {
@@ -344,54 +343,64 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
+    assert(!libxl__ev_child_inuse(&ss->mid));
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+}
+
+static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+/* Precondition: Attached or Detaching, but caller must have just set
+ * at least one of detaching or failed.
+ * Results: Detaching or Attached Failed */
+{
     int r;
 
+    assert(libxl__ev_child_inuse(&ss->mid));
     libxl__ev_time_deregister(gc, &ss->timeout);
     libxl__ev_xswatch_deregister(gc, &ss->xswatch);
 
-    libxl__spawn_state_detachable *ssd = ss->ssd;
-    if (ssd) {
-        if (libxl__ev_child_inuse(&ssd->mid)) {
-            pid_t child = ssd->mid.pid;
-            r = kill(child, SIGKILL);
-            if (r && errno != ESRCH)
-                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
-                     ss->what, (unsigned long)child);
-        }
+    pid_t child = ss->mid.pid;
+    r = kill(child, SIGKILL);
+    if (r && errno != ESRCH)
+        LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+             ss->what, (unsigned long)child);
+}
 
-        /* disconnect the ss and ssd from each other */
-        ssd->ss = 0;
-        ss->ssd = 0;
-    }
+void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    ss->detaching = 1;
+    spawn_detach(gc, ss);
 }
 
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss)
+/* Caller must have logged.  Must be last thing in calling function,
+ * as it may make the callback.  Precondition: Attached or Detaching. */
 {
     EGC_GC;
-    spawn_cleanup(gc, ss);
-    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+    ss->failed = 1;
+    spawn_detach(gc, ss);
 }
 
 static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
                           const struct timeval *requested_abs)
 {
-    /* Before event, was Active; is now Partial. */
+    /* Before event, was Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
     LOG(ERROR, "%s: startup timed out", ss->what);
-    spawn_failed(egc, ss); /* must be last */
+    spawn_fail(egc, ss); /* must be last */
 }
 
 static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
                               const char *watch_path, const char *event_path)
 {
-    /* On entry, is Active. */
+    /* On entry, is Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
     char *p = libxl__xs_read(gc, 0, ss->xspath);
     if (!p && errno != ENOENT) {
         LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
-        spawn_failed(egc, ss); /* must be last */
+        spawn_fail(egc, ss); /* must be last */
         return;
     }
     ss->confirm_cb(egc, ss, p); /* must be last */
@@ -399,20 +408,22 @@ static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
 
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status)
-    /* Before event, was Active or Detached;
-     * is now Active or Detached except that ssd->mid is Idle */
+    /* On entry, is Attached or Detaching */
 {
     EGC_GC;
-    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
-    libxl__spawn_state *ss = ssd->ss;
-
-    if (!WIFEXITED(status)) {
+    libxl__spawn_state *ss = CONTAINER_OF(childw, *ss, mid);
+
+    if ((ss->failed || ss->detaching) &&
+        ((WIFEXITED(status) && WEXITSTATUS(status)==0) ||
+         (WIFSIGNALED(status) && WTERMSIG(status)==SIGKILL))) {
+        /* as expected */
+    } else if (!WIFEXITED(status)) {
+        int loglevel = ss->detaching ? XTL_WARN : XTL_ERROR;
         const char *what =
-            GCSPRINTF("%s intermediate process (startup monitor)",
-                      ss ? ss->what : "(detached)");
-        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+            GCSPRINTF("%s intermediate process (startup monitor)", ss->what);
         libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
-    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        ss->failed = 1;
+    } else {
         if (!status)
             LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
                 " when we were waiting for it to confirm startup",
@@ -430,15 +441,22 @@ static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                 LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
                     " signal number %d", ss->what, (unsigned long)pid, sig);
         }
-        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
-        spawn_failed(egc, ss); /* must be last use of ss */
+        ss->failed = 1;
     }
-    free(ssd);
-}
 
-void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
-{
     spawn_cleanup(gc, ss);
+
+    if (ss->failed && !ss->detaching) {
+        ss->failure_cb(egc, ss); /* must be last */
+        return;
+    }
+    
+    if (ss->failed && ss->detaching)
+        LOG(WARN,"%s underlying machinery seemed to fail,"
+            " but its function seems to have been successful", ss->what);
+
+    assert(ss->detaching);
+    ss->detached_cb(egc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8635764..f9ee949 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -690,8 +690,7 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
  * the libxl event machinery.
  *
  * The parent may signal the child but it must not reap it.  That will
- * be done by the event machinery.  death may be NULL in which case
- * the child is still reaped but its death is ignored.
+ * be done by the event machinery.
  *
  * It is not possible to "deregister" the child death event source.
  * It will generate exactly one event callback; until then the childw
@@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
  *
  * Higher-level double-fork and separate detach eg as for device models
  *
- * Each libxl__spawn_state is in one of the conventional states
- *    Undefined, Idle, Active
+ * Each libxl__spawn_state is in one of these states
+ *    Undefined, Idle, Attached, Detaching
  */
 
 typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
@@ -1040,15 +1039,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
  * intermediate or final child; an error message will have been
  * logged.
  *
- * confirm_cb and failure_cb will not be called reentrantly from
- * within libxl__spawn_spawn.
+ * confirm_cb, failure_cb and detached_cb will not be called
+ * reentrantly from within libxl__spawn_spawn.
  *
  * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
  *  < 0   error, *spawn is now Idle and need not be detached
- *   +1   caller is the parent, *spawn is Active and must eventually be detached
+ *   +1   caller is the parent, *spawn is Attached and must be detached
  *    0   caller is now the inner child, should probably call libxl__exec
  *
  * The spawn state must be Undefined or Idle on entry.
@@ -1056,12 +1055,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
 _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl__spawn_detach - Detaches the daemonic child.
+ * libxl__spawn_request_detach - Detaches the daemonic child.
  *
  * Works by killing the intermediate process from spawn_spawn.
  * After this function returns, failures of either child are no
  * longer reported via failure_cb.
  *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
  * If called before the inner child has been created, this may prevent
  * it from running at all.  Thus this should be called only when the
  * inner child has notified that it is ready.  Normally it will be
@@ -1069,10 +1071,10 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
  *
  * Logs errors.
  *
- * The spawn state must be Active or Idle on entry and will be Idle
+ * The spawn state must be Attached entry and will be Detaching
  * on return.
  */
-_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
+_hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
  * If successful, this should return 0.
@@ -1109,15 +1111,11 @@ typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
 typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
                                      const char *xsdata);
 
-typedef struct {
-    /* Private to the spawn implementation.
-     */
-    /* This separate struct, from malloc, allows us to "detach"
-     * the child and reap it later, when our user has gone
-     * away and freed its libxl__spawn_state */
-    struct libxl__spawn_state *ss;
-    libxl__ev_child mid;
-} libxl__spawn_state_detachable;
+/*
+ * Called when the detach (requested by libxl__spawn_initiate_detach) has
+ * completed.  On entry to the callback the spawn state is Idle.
+ */
+typedef void libxl__spawn_detached_cb(libxl__egc*, libxl__spawn_state*);
 
 struct libxl__spawn_state {
     /* must be filled in by user and remain valid */
@@ -1129,15 +1127,18 @@ struct libxl__spawn_state {
     libxl__spawn_midproc_cb *midproc_cb;
     libxl__spawn_failure_cb *failure_cb;
     libxl__spawn_confirm_cb *confirm_cb;
+    libxl__spawn_detached_cb *detached_cb;
 
     /* remaining fields are private to libxl_spawn_... */
+    int detaching; /* we are in Detaching */
+    int failed; /* might be true whenever we are not Idle */
+    libxl__ev_child mid; /* always in use whenever we are not Idle */
     libxl__ev_time timeout;
     libxl__ev_xswatch xswatch;
-    libxl__spawn_state_detachable *ssd;
 };
 
 static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
-    { return !!ss->ssd; }
+    { return libxl__ev_child_inuse(&ss->mid); }
 
 /*
  * libxl_spawner_record_pid - Record given pid in xenstore
-- 
1.7.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 Jun 08 17:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd35B-0002hV-Bt; Fri, 08 Jun 2012 17:34: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 1Sd354-0002bJ-QK
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:6275] by server-1.bemta-5.messagelabs.com id
	7A/A9-25424-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16151 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Be-MF; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005E-Jp;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:18 +0100
Message-ID: <1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/19] libxl: provide libxl__xs_*_checked and
	libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 useful utility functions make dealing with xenstore a little
less painful.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Fixed typo `transacton' in log messages.
---
 tools/libxl/libxl_internal.h |   38 +++++++++++++++++++++
 tools/libxl/libxl_xshelp.c   |   76 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index dbf7722..4634f5a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -498,6 +498,44 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*----- "checked" xenstore access functions -----*/
+/* Each of these functions will check that it succeeded; if it
+ * fails it logs and returns ERROR_FAIL.
+ */
+
+/* On success, *result_out came from the gc.
+ * On error, *result_out is undefined.
+ * ENOENT counts as success but sets *result_out=0
+ */
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out);
+
+/* Does not include a trailing null.
+ * May usefully be combined with GCSPRINTF if the format string
+ * behaviour of libxl__xs_write is desirable. */
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string);
+
+/* ENOENT is not an error (even if the parent directories don't exist) */
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
+
+/* Transaction functions, best used together.
+ * The caller should initialise *t to 0 (XBT_NULL) before calling start.
+ * Each function leaves *t!=0 iff the transaction needs cleaning up.
+ *
+ * libxl__xs_transaction_commit returns:
+ *   <0  failure - a libxl error code
+ *   +1  commit conflict; transaction has been destroyed and caller
+ *        must go round again (call _start again and retry)
+ *    0  commited successfully
+ */
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
+
+
+
 /*
  * This is a recursive delete, from top to bottom. What this function does
  * is remove empty folders that contained the deleted entry.
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index c5b5364..993f527 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,82 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out)
+{
+    char *result = libxl__xs_read(gc, t, path);
+    if (!result) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "xenstore read failed: `%s'", path);
+            return ERROR_FAIL;
+        }
+    }
+    *result_out = result;
+    return 0;
+}
+
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string)
+{
+    size_t length = strlen(string);
+    if (!xs_write(CTX->xsh, t, path, string, length)) {
+        LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, string);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path)
+{
+    if (!xs_rm(CTX->xsh, t, path)) {
+        if (errno == ENOENT)
+            return 0;
+
+        LOGE(ERROR, "xenstore rm failed: `%s'", path);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(!*t);
+    *t = xs_transaction_start(CTX->xsh);
+    if (!*t) {
+        LOGE(ERROR, "could not create xenstore transaction");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(*t);
+
+    if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        if (errno == EAGAIN)
+            return +1;
+
+        *t = 0;
+        LOGE(ERROR, "could not commit xenstore transaction");
+        return ERROR_FAIL;
+    }
+
+    *t = 0;
+    return 0;
+}
+
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t)
+{
+    if (!*t)
+        return;
+
+    if (!xs_transaction_end(CTX->xsh, *t, 1))
+        LOGE(ERROR, "could not abort xenstore transaction");
+
+    *t = 0;
+}
+
 int libxl__xs_path_cleanup(libxl__gc *gc, xs_transaction_t t, char *user_path)
 {
     unsigned int nb = 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 Jun 08 17:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd35B-0002hV-Bt; Fri, 08 Jun 2012 17:34: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 1Sd354-0002bJ-QK
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:6275] by server-1.bemta-5.messagelabs.com id
	7A/A9-25424-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16151 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Be-MF; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005E-Jp;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:18 +0100
Message-ID: <1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/19] libxl: provide libxl__xs_*_checked and
	libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 useful utility functions make dealing with xenstore a little
less painful.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Fixed typo `transacton' in log messages.
---
 tools/libxl/libxl_internal.h |   38 +++++++++++++++++++++
 tools/libxl/libxl_xshelp.c   |   76 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index dbf7722..4634f5a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -498,6 +498,44 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*----- "checked" xenstore access functions -----*/
+/* Each of these functions will check that it succeeded; if it
+ * fails it logs and returns ERROR_FAIL.
+ */
+
+/* On success, *result_out came from the gc.
+ * On error, *result_out is undefined.
+ * ENOENT counts as success but sets *result_out=0
+ */
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out);
+
+/* Does not include a trailing null.
+ * May usefully be combined with GCSPRINTF if the format string
+ * behaviour of libxl__xs_write is desirable. */
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string);
+
+/* ENOENT is not an error (even if the parent directories don't exist) */
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
+
+/* Transaction functions, best used together.
+ * The caller should initialise *t to 0 (XBT_NULL) before calling start.
+ * Each function leaves *t!=0 iff the transaction needs cleaning up.
+ *
+ * libxl__xs_transaction_commit returns:
+ *   <0  failure - a libxl error code
+ *   +1  commit conflict; transaction has been destroyed and caller
+ *        must go round again (call _start again and retry)
+ *    0  commited successfully
+ */
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
+
+
+
 /*
  * This is a recursive delete, from top to bottom. What this function does
  * is remove empty folders that contained the deleted entry.
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index c5b5364..993f527 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,82 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out)
+{
+    char *result = libxl__xs_read(gc, t, path);
+    if (!result) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "xenstore read failed: `%s'", path);
+            return ERROR_FAIL;
+        }
+    }
+    *result_out = result;
+    return 0;
+}
+
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string)
+{
+    size_t length = strlen(string);
+    if (!xs_write(CTX->xsh, t, path, string, length)) {
+        LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, string);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path)
+{
+    if (!xs_rm(CTX->xsh, t, path)) {
+        if (errno == ENOENT)
+            return 0;
+
+        LOGE(ERROR, "xenstore rm failed: `%s'", path);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(!*t);
+    *t = xs_transaction_start(CTX->xsh);
+    if (!*t) {
+        LOGE(ERROR, "could not create xenstore transaction");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(*t);
+
+    if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        if (errno == EAGAIN)
+            return +1;
+
+        *t = 0;
+        LOGE(ERROR, "could not commit xenstore transaction");
+        return ERROR_FAIL;
+    }
+
+    *t = 0;
+    return 0;
+}
+
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t)
+{
+    if (!*t)
+        return;
+
+    if (!xs_transaction_end(CTX->xsh, *t, 1))
+        LOGE(ERROR, "could not abort xenstore transaction");
+
+    *t = 0;
+}
+
 int libxl__xs_path_cleanup(libxl__gc *gc, xs_transaction_t t, char *user_path)
 {
     unsigned int nb = 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 Jun 08 17:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd357-0002cu-3C; Fri, 08 Jun 2012 17:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002au-UK
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8075] by server-2.bemta-4.messagelabs.com id
	74/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12709 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bj-QY; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005M-O4;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:20 +0100
Message-ID: <1339176870-32652-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/19] libxl: datacopier: provide "prefix data"
	facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used to write the qemu data banner to the save/migration
stream.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Clarified and added comments explaining the `immediately'
   constraint and the lack of a reentrancy/threading hazard.
 * Fixed subject line typo.
---
 tools/libxl/libxl_aoutils.c  |   22 ++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index ee0df57..7f8d6d3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -74,6 +74,28 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
     }
 }
 
+void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
+                                  const void *data, size_t len)
+{
+    libxl__datacopier_buf *buf;
+    /*
+     * It is safe for this to be called immediately after _start, as
+     * is documented in the public comment.  _start's caller must have
+     * the ctx locked, so other threads don't get to mess with the
+     * contents, and the fd events cannot happen reentrantly.  So we
+     * are guaranteed to beat the first data from the read fd.
+     */
+
+    assert(len < dc->maxsz - dc->used);
+
+    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf->used = len;
+    memcpy(buf->buf, data, len);
+
+    dc->used += len;
+    LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+}
+
 static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
                                 int fd, short events, short revents) {
     libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3b4d250..7e0ab11 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1811,6 +1811,12 @@ _hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
 _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
+/* Inserts literal data into the output stream.  The data is copied.
+ * May safely be used only immediately after libxl__datacopier_start
+ * (before the ctx is unlocked).  But may be called multiple times.
+ * NB exceeding maxsz will fail an assertion! */
+_hidden void libxl__datacopier_prefixdata(libxl__egc*, libxl__datacopier_state*,
+                                          const void *data, size_t len);
 
 /*----- Save/restore helper (used by creation and suspend) -----*/
 
-- 
1.7.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 Jun 08 17:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd357-0002cu-3C; Fri, 08 Jun 2012 17:34:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002au-UK
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:38 +0000
Received: from [85.158.143.99:8075] by server-2.bemta-4.messagelabs.com id
	74/41-17938-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12709 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bj-QY; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005M-O4;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:20 +0100
Message-ID: <1339176870-32652-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/19] libxl: datacopier: provide "prefix data"
	facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used to write the qemu data banner to the save/migration
stream.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Clarified and added comments explaining the `immediately'
   constraint and the lack of a reentrancy/threading hazard.
 * Fixed subject line typo.
---
 tools/libxl/libxl_aoutils.c  |   22 ++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index ee0df57..7f8d6d3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -74,6 +74,28 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
     }
 }
 
+void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
+                                  const void *data, size_t len)
+{
+    libxl__datacopier_buf *buf;
+    /*
+     * It is safe for this to be called immediately after _start, as
+     * is documented in the public comment.  _start's caller must have
+     * the ctx locked, so other threads don't get to mess with the
+     * contents, and the fd events cannot happen reentrantly.  So we
+     * are guaranteed to beat the first data from the read fd.
+     */
+
+    assert(len < dc->maxsz - dc->used);
+
+    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf->used = len;
+    memcpy(buf->buf, data, len);
+
+    dc->used += len;
+    LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+}
+
 static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
                                 int fd, short events, short revents) {
     libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3b4d250..7e0ab11 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1811,6 +1811,12 @@ _hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
 _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
+/* Inserts literal data into the output stream.  The data is copied.
+ * May safely be used only immediately after libxl__datacopier_start
+ * (before the ctx is unlocked).  But may be called multiple times.
+ * NB exceeding maxsz will fail an assertion! */
+_hidden void libxl__datacopier_prefixdata(libxl__egc*, libxl__datacopier_state*,
+                                          const void *data, size_t len);
 
 /*----- Save/restore helper (used by creation and suspend) -----*/
 
-- 
1.7.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 Jun 08 17:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd355-0002cU-Um; Fri, 08 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002at-Dc
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:8011] by server-1.bemta-4.messagelabs.com id
	FE/0E-10042-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12649 invoked from network); 8 Jun 2012 17:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916786"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BO-9B; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-0008WT-0L;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 8 Jun 2012 18:34:13 +0100
Message-ID: <1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/19] libxl: domain save: rename variables etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Preparatory work for making domain suspend asynchronous:

* Rename `struct suspendinfo' to `libxl__domain_suspend_state'
  and move it to libxl_internal.h.

* Rename variables `si' to `dss'.

* Change the stack-allocated state and callbacks from
    struct suspendinfo si;
    struct save_callbacks callbacks;
    struct restore_callbacks callbacks;
  to
    libxl__domain_suspend_state dss[1];
    struct save_callbacks callbacks[1];
    struct restore_callbacks callbacks[1];
  so that it may be referred to as a pointer variable everywhere.

* Rename the variable `flags' (in libxl__domain_suspend_state) to
  `xcflags', to help distinguish it from the other `flags' which is
  passed in from the calling application in libxl_domain_suspend_info.
  Abolish the local variable in libxl__domain_suspend_common, as it
  can use the one in the dss.

* Move the prototypes of suspend-related functions in libxl_internal.h
  to after the definition of the state struct.

* Replace several ctx variables with gc variables and
  consequently references to ctx with CTX.  Change references
  to `dss->gc' in the functional code to simply `gc'.

* Use LOG* rather than LIBXL__LOG* in a number of places.

* In libxl__domain_save_device_model use `rc' instead of `ret'.

* Introduce and use `gc' and `domid' in
  libxl__domain_suspend_common_callback.

* Wrap some long lines.

* Add an extra pair of parens for clarity in a flag test.

* Remove two pointless casts from void* to a struct*.

No functional change whatsoever.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Abolish local variables `xcflags' and `hvm' in
   libxl__domain_suspend_common; just use dss->xcflags and dss->hvm
   instead and hence do not lose some of the changes to xcflags.

Changes in v2:
 * Make callbacks into arrays (for pointerisation) too.
 * Updated to cope with new remus code.
 * Fixed typo in commit message.
---
 tools/libxl/libxl_dom.c      |  261 ++++++++++++++++++++----------------------
 tools/libxl/libxl_internal.h |   30 ++++-
 2 files changed, 151 insertions(+), 140 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 677db1d..e90030d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -470,7 +470,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
-    libxl__gc *gc = (libxl__gc *) data;
+    libxl__gc *gc = data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
     const uint8_t *ptr = buf;
@@ -531,7 +531,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
-    struct restore_callbacks callbacks;
+    struct restore_callbacks callbacks[1];
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -539,8 +539,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks.toolstack_restore = libxl__toolstack_restore;
-        callbacks.data = gc;
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -556,7 +556,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, &callbacks);
+                           &state->vm_generationid_addr, callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -564,33 +564,23 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-struct suspendinfo {
-    libxl__gc *gc;
-    xc_evtchn *xce; /* event channel handle */
-    int suspend_eventchn;
-    int domid;
-    int hvm;
-    unsigned int flags;
-    int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
-    int interval; /* checkpoint interval (for Remus) */
-};
-
-static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
+static int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     char *path;
     bool rc;
 
-    path = libxl__sprintf(si->gc, "/local/domain/0/device-model/%u/logdirty/cmd", domid);
+    path = libxl__sprintf(gc,
+                   "/local/domain/0/device-model/%u/logdirty/cmd", domid);
     if (!path)
         return 1;
 
     if (enable)
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "enable", strlen("enable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
     else
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "disable", strlen("disable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
 
     return rc ? 0 : 1;
 }
@@ -645,53 +635,56 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
 
 static int libxl__domain_suspend_common_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
     int watchdog;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
 
-    if (si->hvm) {
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->hvm) {
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
     }
 
-    if ((hvm_s_state == 0) && (si->suspend_eventchn >= 0)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via event channel",
-                   si->hvm ? "PVHVM" : "PV");
-        ret = xc_evtchn_notify(si->xce, si->suspend_eventchn);
+    if ((hvm_s_state == 0) && (dss->suspend_eventchn >= 0)) {
+        LOG(DEBUG, "issuing %s suspend request via event channel",
+            dss->hvm ? "PVHVM" : "PV");
+        ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_evtchn_notify failed ret=%d", ret);
+            LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
             return 0;
         }
-        ret = xc_await_suspend(ctx->xch, si->xce, si->suspend_eventchn);
+        ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_await_suspend failed ret=%d", ret);
+            LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
             return 0;
         }
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
         goto guest_suspended;
     }
 
-    if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling xc_domain_shutdown on HVM domain");
-        xc_domain_shutdown(ctx->xch, si->domid, SHUTDOWN_suspend);
+    if (dss->hvm && (!hvm_pvdrv || hvm_s_state)) {
+        LOG(DEBUG, "Calling xc_domain_shutdown on HVM domain");
+        xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
         /* The guest does not (need to) respond to this sort of request. */
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
     } else {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
-                   si->hvm ? "PVHVM" : "PV");
+        LOG(DEBUG, "issuing %s suspend request via XenBus control node",
+            dss->hvm ? "PVHVM" : "PV");
 
-        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
+        libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
+        LOG(DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
             if (!state) state = "";
 
             watchdog--;
@@ -707,17 +700,17 @@ static int libxl__domain_suspend_common_callback(void *data)
          * at the last minute.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, cancelling request");
+            LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
         retry_transaction:
-            t = xs_transaction_start(ctx->xsh);
+            t = xs_transaction_start(CTX->xsh);
 
-            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, t, domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
+                libxl__domain_pvcontrol_write(gc, t, domid, "");
 
-            if (!xs_transaction_end(ctx->xsh, t, 0))
+            if (!xs_transaction_end(CTX->xsh, t, 0))
                 if (errno == EAGAIN)
                     goto retry_transaction;
 
@@ -729,27 +722,29 @@ static int libxl__domain_suspend_common_callback(void *data)
          * case we lost the race while cancelling and should continue.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, request cancelled");
+            LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
             return 0;
         }
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest acknowledged suspend request");
-        si->guest_responded = 1;
+        LOG(DEBUG, "guest acknowledged suspend request");
+        dss->guest_responded = 1;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to suspend");
+    LOG(DEBUG, "wait for the guest to suspend");
     watchdog = 60;
     while (watchdog > 0) {
         xc_domaininfo_t info;
 
         usleep(100000);
-        ret = xc_domain_getinfolist(ctx->xch, si->domid, 1, &info);
-        if (ret == 1 && info.domain == si->domid && info.flags & XEN_DOMINF_shutdown) {
+        ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
+        if (ret == 1 && info.domain == domid &&
+            (info.flags & XEN_DOMINF_shutdown)) {
             int shutdown_reason;
 
-            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
+            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+                & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
+                LOG(DEBUG, "guest has suspended");
                 goto guest_suspended;
             }
         }
@@ -757,15 +752,14 @@ static int libxl__domain_suspend_common_callback(void *data)
         watchdog--;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
+    LOG(ERROR, "guest did not suspend");
     return 0;
 
  guest_suspended:
-    if (si->hvm) {
-        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+    if (dss->hvm) {
+        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
         if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
         }
     }
@@ -783,9 +777,8 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
-    struct suspendinfo *si = (struct suspendinfo *) data;
-    libxl__gc *gc = (libxl__gc *) si->gc;
-    libxl_ctx *ctx = gc->owner;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -814,21 +807,21 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         char *xs_path;
         phys_offset = entries[i];
         if (phys_offset == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            LOG(ERROR, "phys_offset %d is NULL", i);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
@@ -864,11 +857,11 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
 
     /* Resumes the domain and the device model */
-    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+    if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
         return 0;
 
     /* TODO: Deal with disk. Start a new network output buffer */
@@ -877,15 +870,15 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
 
     /* This would go into tailbuf. */
-    if (si->hvm &&
-        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+    if (dss->hvm &&
+        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
-    usleep(si->interval * 1000);
+    usleep(dss->interval * 1000);
     return 1;
 }
 
@@ -894,12 +887,10 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  int live, int debug,
                                  const libxl_domain_remus_info *r_info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags;
     int port;
-    struct save_callbacks callbacks;
-    struct suspendinfo si;
-    int hvm, rc = ERROR_FAIL;
+    struct save_callbacks callbacks[1];
+    libxl__domain_suspend_state dss[1];
+    int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
     switch (type) {
@@ -912,82 +903,81 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
         vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
-        hvm = 1;
+        dss->hvm = 1;
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
         vm_generationid_addr = 0;
-        hvm = 0;
+        dss->hvm = 0;
         break;
     default:
         return ERROR_INVAL;
     }
 
-    memset(&si, 0, sizeof(si));
-    flags = (live) ? XCFLAGS_LIVE : 0
+    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
-          | (hvm) ? XCFLAGS_HVM : 0;
+          | (dss->hvm) ? XCFLAGS_HVM : 0;
+
+    dss->domid = domid;
+    dss->gc = gc;
+    dss->suspend_eventchn = -1;
+    dss->guest_responded = 0;
 
     if (r_info != NULL) {
-        si.interval = r_info->interval;
+        dss->interval = r_info->interval;
         if (r_info->compression)
-            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        si.save_fd = fd;
+            dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        dss->save_fd = fd;
     }
     else
-        si.save_fd = -1;
+        dss->save_fd = -1;
 
-    si.domid = domid;
-    si.flags = flags;
-    si.hvm = hvm;
-    si.gc = gc;
-    si.suspend_eventchn = -1;
-    si.guest_responded = 0;
-
-    si.xce = xc_evtchn_open(NULL, 0);
-    if (si.xce == NULL)
+    dss->xce = xc_evtchn_open(NULL, 0);
+    if (dss->xce == NULL)
         goto out;
     else
     {
-        port = xs_suspend_evtchn_port(si.domid);
+        port = xs_suspend_evtchn_port(dss->domid);
 
         if (port >= 0) {
-            si.suspend_eventchn = xc_suspend_evtchn_init(ctx->xch, si.xce, si.domid, port);
+            dss->suspend_eventchn =
+                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
 
-            if (si.suspend_eventchn < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "Suspend event channel initialization failed");
+            if (dss->suspend_eventchn < 0)
+                LOG(WARN, "Suspend event channel initialization failed");
         }
     }
 
-    memset(&callbacks, 0, sizeof(callbacks));
+    memset(callbacks, 0, sizeof(*callbacks));
     if (r_info != NULL) {
-        callbacks.suspend = libxl__remus_domain_suspend_callback;
-        callbacks.postcopy = libxl__remus_domain_resume_callback;
-        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+        callbacks->suspend = libxl__remus_domain_suspend_callback;
+        callbacks->postcopy = libxl__remus_domain_resume_callback;
+        callbacks->checkpoint = libxl__remus_domain_checkpoint_callback;
     } else
-        callbacks.suspend = libxl__domain_suspend_common_callback;
+        callbacks->suspend = libxl__domain_suspend_common_callback;
 
-    callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks.toolstack_save = libxl__toolstack_save;
-    callbacks.data = &si;
+    callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks->toolstack_save = libxl__toolstack_save;
+    callbacks->data = dss;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-                        hvm, vm_generationid_addr);
+    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
+                        dss->hvm, vm_generationid_addr);
     if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
-                         si.guest_responded ?
+        LOGE(ERROR, "saving domain: %s",
+                         dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
-        if ( !si.guest_responded )
+        if ( !dss->guest_responded )
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
     }
 
-    if (si.suspend_eventchn > 0)
-        xc_suspend_evtchn_release(ctx->xch, si.xce, domid, si.suspend_eventchn);
-    if (si.xce != NULL)
-        xc_evtchn_close(si.xce);
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
 
 out:
     return rc;
@@ -995,8 +985,7 @@ out:
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
+    int rc, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -1004,46 +993,46 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 
     if (stat(filename, &st) < 0)
     {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        ret = ERROR_FAIL;
+        LOG(ERROR, "Unable to stat qemu save file\n");
+        rc = ERROR_FAIL;
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
                               "saved-state file", "qemu signature");
-    if (ret)
+    if (rc)
         goto out;
 
-    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (ret)
+    if (rc)
         goto out;
 
     fd2 = open(filename, O_RDONLY);
     if (fd2 < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        LOGE(ERROR, "Unable to open qemu save file\n");
         goto out;
     }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            ret = errno;
+            rc = errno;
             goto out;
         }
-        ret = libxl_write_exactly(
-            ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (ret)
+        rc = libxl_write_exactly(
+            CTX, fd, buf, c, "saved-state file", "qemu state");
+        if (rc)
             goto out;
     }
-    ret = 0;
+    rc = 0;
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return ret;
+    return rc;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..f22bf94 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -786,10 +786,6 @@ _hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                          libxl_domain_build_info *info,
                                          libxl__domain_build_state *state,
                                          int fd);
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1778,6 +1774,23 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Domain suspend (save) state structure -----*/
+
+typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
+
+struct libxl__domain_suspend_state {
+    libxl__gc *gc;
+    xc_evtchn *xce; /* event channel handle */
+    int suspend_eventchn;
+    int domid;
+    int hvm;
+    unsigned int xcflags;
+    int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
+};
+
+
 /*----- openpty -----*/
 
 /*
@@ -1888,6 +1901,15 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
 };
 
+/*----- Domain suspend (save) functions -----*/
+
+_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
+                                         libxl_domain_type type,
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
+
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 17:35:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd355-0002cU-Um; Fri, 08 Jun 2012 17:34:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd353-0002at-Dc
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:37 +0000
Received: from [85.158.143.99:8011] by server-1.bemta-4.messagelabs.com id
	FE/0E-10042-CA732DF4; Fri, 08 Jun 2012 17:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12649 invoked from network); 8 Jun 2012 17:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916786"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001BO-9B; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-0008WT-0L;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 8 Jun 2012 18:34:13 +0100
Message-ID: <1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/19] libxl: domain save: rename variables etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Preparatory work for making domain suspend asynchronous:

* Rename `struct suspendinfo' to `libxl__domain_suspend_state'
  and move it to libxl_internal.h.

* Rename variables `si' to `dss'.

* Change the stack-allocated state and callbacks from
    struct suspendinfo si;
    struct save_callbacks callbacks;
    struct restore_callbacks callbacks;
  to
    libxl__domain_suspend_state dss[1];
    struct save_callbacks callbacks[1];
    struct restore_callbacks callbacks[1];
  so that it may be referred to as a pointer variable everywhere.

* Rename the variable `flags' (in libxl__domain_suspend_state) to
  `xcflags', to help distinguish it from the other `flags' which is
  passed in from the calling application in libxl_domain_suspend_info.
  Abolish the local variable in libxl__domain_suspend_common, as it
  can use the one in the dss.

* Move the prototypes of suspend-related functions in libxl_internal.h
  to after the definition of the state struct.

* Replace several ctx variables with gc variables and
  consequently references to ctx with CTX.  Change references
  to `dss->gc' in the functional code to simply `gc'.

* Use LOG* rather than LIBXL__LOG* in a number of places.

* In libxl__domain_save_device_model use `rc' instead of `ret'.

* Introduce and use `gc' and `domid' in
  libxl__domain_suspend_common_callback.

* Wrap some long lines.

* Add an extra pair of parens for clarity in a flag test.

* Remove two pointless casts from void* to a struct*.

No functional change whatsoever.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v3:
 * Abolish local variables `xcflags' and `hvm' in
   libxl__domain_suspend_common; just use dss->xcflags and dss->hvm
   instead and hence do not lose some of the changes to xcflags.

Changes in v2:
 * Make callbacks into arrays (for pointerisation) too.
 * Updated to cope with new remus code.
 * Fixed typo in commit message.
---
 tools/libxl/libxl_dom.c      |  261 ++++++++++++++++++++----------------------
 tools/libxl/libxl_internal.h |   30 ++++-
 2 files changed, 151 insertions(+), 140 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 677db1d..e90030d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -470,7 +470,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
-    libxl__gc *gc = (libxl__gc *) data;
+    libxl__gc *gc = data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
     const uint8_t *ptr = buf;
@@ -531,7 +531,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
-    struct restore_callbacks callbacks;
+    struct restore_callbacks callbacks[1];
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -539,8 +539,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks.toolstack_restore = libxl__toolstack_restore;
-        callbacks.data = gc;
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -556,7 +556,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, &callbacks);
+                           &state->vm_generationid_addr, callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -564,33 +564,23 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-struct suspendinfo {
-    libxl__gc *gc;
-    xc_evtchn *xce; /* event channel handle */
-    int suspend_eventchn;
-    int domid;
-    int hvm;
-    unsigned int flags;
-    int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
-    int interval; /* checkpoint interval (for Remus) */
-};
-
-static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
+static int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     char *path;
     bool rc;
 
-    path = libxl__sprintf(si->gc, "/local/domain/0/device-model/%u/logdirty/cmd", domid);
+    path = libxl__sprintf(gc,
+                   "/local/domain/0/device-model/%u/logdirty/cmd", domid);
     if (!path)
         return 1;
 
     if (enable)
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "enable", strlen("enable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
     else
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "disable", strlen("disable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
 
     return rc ? 0 : 1;
 }
@@ -645,53 +635,56 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
 
 static int libxl__domain_suspend_common_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
     int watchdog;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
 
-    if (si->hvm) {
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->hvm) {
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
     }
 
-    if ((hvm_s_state == 0) && (si->suspend_eventchn >= 0)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via event channel",
-                   si->hvm ? "PVHVM" : "PV");
-        ret = xc_evtchn_notify(si->xce, si->suspend_eventchn);
+    if ((hvm_s_state == 0) && (dss->suspend_eventchn >= 0)) {
+        LOG(DEBUG, "issuing %s suspend request via event channel",
+            dss->hvm ? "PVHVM" : "PV");
+        ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_evtchn_notify failed ret=%d", ret);
+            LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
             return 0;
         }
-        ret = xc_await_suspend(ctx->xch, si->xce, si->suspend_eventchn);
+        ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_await_suspend failed ret=%d", ret);
+            LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
             return 0;
         }
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
         goto guest_suspended;
     }
 
-    if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling xc_domain_shutdown on HVM domain");
-        xc_domain_shutdown(ctx->xch, si->domid, SHUTDOWN_suspend);
+    if (dss->hvm && (!hvm_pvdrv || hvm_s_state)) {
+        LOG(DEBUG, "Calling xc_domain_shutdown on HVM domain");
+        xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
         /* The guest does not (need to) respond to this sort of request. */
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
     } else {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
-                   si->hvm ? "PVHVM" : "PV");
+        LOG(DEBUG, "issuing %s suspend request via XenBus control node",
+            dss->hvm ? "PVHVM" : "PV");
 
-        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
+        libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
+        LOG(DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
             if (!state) state = "";
 
             watchdog--;
@@ -707,17 +700,17 @@ static int libxl__domain_suspend_common_callback(void *data)
          * at the last minute.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, cancelling request");
+            LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
         retry_transaction:
-            t = xs_transaction_start(ctx->xsh);
+            t = xs_transaction_start(CTX->xsh);
 
-            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, t, domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
+                libxl__domain_pvcontrol_write(gc, t, domid, "");
 
-            if (!xs_transaction_end(ctx->xsh, t, 0))
+            if (!xs_transaction_end(CTX->xsh, t, 0))
                 if (errno == EAGAIN)
                     goto retry_transaction;
 
@@ -729,27 +722,29 @@ static int libxl__domain_suspend_common_callback(void *data)
          * case we lost the race while cancelling and should continue.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, request cancelled");
+            LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
             return 0;
         }
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest acknowledged suspend request");
-        si->guest_responded = 1;
+        LOG(DEBUG, "guest acknowledged suspend request");
+        dss->guest_responded = 1;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to suspend");
+    LOG(DEBUG, "wait for the guest to suspend");
     watchdog = 60;
     while (watchdog > 0) {
         xc_domaininfo_t info;
 
         usleep(100000);
-        ret = xc_domain_getinfolist(ctx->xch, si->domid, 1, &info);
-        if (ret == 1 && info.domain == si->domid && info.flags & XEN_DOMINF_shutdown) {
+        ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
+        if (ret == 1 && info.domain == domid &&
+            (info.flags & XEN_DOMINF_shutdown)) {
             int shutdown_reason;
 
-            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
+            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+                & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
+                LOG(DEBUG, "guest has suspended");
                 goto guest_suspended;
             }
         }
@@ -757,15 +752,14 @@ static int libxl__domain_suspend_common_callback(void *data)
         watchdog--;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
+    LOG(ERROR, "guest did not suspend");
     return 0;
 
  guest_suspended:
-    if (si->hvm) {
-        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+    if (dss->hvm) {
+        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
         if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
         }
     }
@@ -783,9 +777,8 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
-    struct suspendinfo *si = (struct suspendinfo *) data;
-    libxl__gc *gc = (libxl__gc *) si->gc;
-    libxl_ctx *ctx = gc->owner;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -814,21 +807,21 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         char *xs_path;
         phys_offset = entries[i];
         if (phys_offset == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            LOG(ERROR, "phys_offset %d is NULL", i);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
@@ -864,11 +857,11 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
 
     /* Resumes the domain and the device model */
-    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+    if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
         return 0;
 
     /* TODO: Deal with disk. Start a new network output buffer */
@@ -877,15 +870,15 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
 
     /* This would go into tailbuf. */
-    if (si->hvm &&
-        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+    if (dss->hvm &&
+        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
-    usleep(si->interval * 1000);
+    usleep(dss->interval * 1000);
     return 1;
 }
 
@@ -894,12 +887,10 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  int live, int debug,
                                  const libxl_domain_remus_info *r_info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags;
     int port;
-    struct save_callbacks callbacks;
-    struct suspendinfo si;
-    int hvm, rc = ERROR_FAIL;
+    struct save_callbacks callbacks[1];
+    libxl__domain_suspend_state dss[1];
+    int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
     switch (type) {
@@ -912,82 +903,81 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
         vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
-        hvm = 1;
+        dss->hvm = 1;
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
         vm_generationid_addr = 0;
-        hvm = 0;
+        dss->hvm = 0;
         break;
     default:
         return ERROR_INVAL;
     }
 
-    memset(&si, 0, sizeof(si));
-    flags = (live) ? XCFLAGS_LIVE : 0
+    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
-          | (hvm) ? XCFLAGS_HVM : 0;
+          | (dss->hvm) ? XCFLAGS_HVM : 0;
+
+    dss->domid = domid;
+    dss->gc = gc;
+    dss->suspend_eventchn = -1;
+    dss->guest_responded = 0;
 
     if (r_info != NULL) {
-        si.interval = r_info->interval;
+        dss->interval = r_info->interval;
         if (r_info->compression)
-            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        si.save_fd = fd;
+            dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        dss->save_fd = fd;
     }
     else
-        si.save_fd = -1;
+        dss->save_fd = -1;
 
-    si.domid = domid;
-    si.flags = flags;
-    si.hvm = hvm;
-    si.gc = gc;
-    si.suspend_eventchn = -1;
-    si.guest_responded = 0;
-
-    si.xce = xc_evtchn_open(NULL, 0);
-    if (si.xce == NULL)
+    dss->xce = xc_evtchn_open(NULL, 0);
+    if (dss->xce == NULL)
         goto out;
     else
     {
-        port = xs_suspend_evtchn_port(si.domid);
+        port = xs_suspend_evtchn_port(dss->domid);
 
         if (port >= 0) {
-            si.suspend_eventchn = xc_suspend_evtchn_init(ctx->xch, si.xce, si.domid, port);
+            dss->suspend_eventchn =
+                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
 
-            if (si.suspend_eventchn < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "Suspend event channel initialization failed");
+            if (dss->suspend_eventchn < 0)
+                LOG(WARN, "Suspend event channel initialization failed");
         }
     }
 
-    memset(&callbacks, 0, sizeof(callbacks));
+    memset(callbacks, 0, sizeof(*callbacks));
     if (r_info != NULL) {
-        callbacks.suspend = libxl__remus_domain_suspend_callback;
-        callbacks.postcopy = libxl__remus_domain_resume_callback;
-        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+        callbacks->suspend = libxl__remus_domain_suspend_callback;
+        callbacks->postcopy = libxl__remus_domain_resume_callback;
+        callbacks->checkpoint = libxl__remus_domain_checkpoint_callback;
     } else
-        callbacks.suspend = libxl__domain_suspend_common_callback;
+        callbacks->suspend = libxl__domain_suspend_common_callback;
 
-    callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks.toolstack_save = libxl__toolstack_save;
-    callbacks.data = &si;
+    callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks->toolstack_save = libxl__toolstack_save;
+    callbacks->data = dss;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-                        hvm, vm_generationid_addr);
+    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
+                        dss->hvm, vm_generationid_addr);
     if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
-                         si.guest_responded ?
+        LOGE(ERROR, "saving domain: %s",
+                         dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
-        if ( !si.guest_responded )
+        if ( !dss->guest_responded )
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
     }
 
-    if (si.suspend_eventchn > 0)
-        xc_suspend_evtchn_release(ctx->xch, si.xce, domid, si.suspend_eventchn);
-    if (si.xce != NULL)
-        xc_evtchn_close(si.xce);
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
 
 out:
     return rc;
@@ -995,8 +985,7 @@ out:
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
+    int rc, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -1004,46 +993,46 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 
     if (stat(filename, &st) < 0)
     {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        ret = ERROR_FAIL;
+        LOG(ERROR, "Unable to stat qemu save file\n");
+        rc = ERROR_FAIL;
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
                               "saved-state file", "qemu signature");
-    if (ret)
+    if (rc)
         goto out;
 
-    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (ret)
+    if (rc)
         goto out;
 
     fd2 = open(filename, O_RDONLY);
     if (fd2 < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        LOGE(ERROR, "Unable to open qemu save file\n");
         goto out;
     }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            ret = errno;
+            rc = errno;
             goto out;
         }
-        ret = libxl_write_exactly(
-            ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (ret)
+        rc = libxl_write_exactly(
+            CTX, fd, buf, c, "saved-state file", "qemu state");
+        if (rc)
             goto out;
     }
-    ret = 0;
+    rc = 0;
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return ret;
+    return rc;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..f22bf94 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -786,10 +786,6 @@ _hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                          libxl_domain_build_info *info,
                                          libxl__domain_build_state *state,
                                          int fd);
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1778,6 +1774,23 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Domain suspend (save) state structure -----*/
+
+typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
+
+struct libxl__domain_suspend_state {
+    libxl__gc *gc;
+    xc_evtchn *xce; /* event channel handle */
+    int suspend_eventchn;
+    int domid;
+    int hvm;
+    unsigned int xcflags;
+    int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
+};
+
+
 /*----- openpty -----*/
 
 /*
@@ -1888,6 +1901,15 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
 };
 
+/*----- Domain suspend (save) functions -----*/
+
+_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
+                                         libxl_domain_type type,
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
+
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 17:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd35A-0002ga-Kd; Fri, 08 Jun 2012 17:34: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 1Sd354-0002bI-Ng
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:6280] by server-9.bemta-5.messagelabs.com id
	2A/46-29678-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16153 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bm-SX; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005Q-QT;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:21 +0100
Message-ID: <1339176870-32652-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/19] libxl: prepare for asynchronous writing
	of qemu save 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

* Combine the various calls to libxl__device_model_savefile into one
  at the start of libxl__domain_suspend, storing the result in the
  dss.  Consequently a few functions take a dss instead of some or all
  of their other arguments.

* Make libxl__domain_save_device_model's API into an asynchronous
  style which takes a callback.  The function is, however, still
  synchronous; it will be made actually async in the next patch.

* Consequently make libxl__remus_domain_checkpoint_callback into an
  asynchronous callback.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h       |   18 ++++++++++--
 tools/libxl/libxl_save_msgs_gen.pl |    2 +-
 3 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d5ac79f..3a53f97 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -702,11 +702,13 @@ static void switch_logdirty_done(libxl__egc *egc,
 
 /*----- callbacks, called by xc_domain_save -----*/
 
-int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                       libxl__domain_suspend_state *dss)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
-    const char *filename = libxl__device_model_savefile(gc, domid);
+    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: {
@@ -875,7 +877,7 @@ int libxl__domain_suspend_common_callback(void *user)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -990,19 +992,32 @@ static int libxl__remus_domain_resume_callback(void *data)
     return 1;
 }
 
-static int libxl__remus_domain_checkpoint_callback(void *data)
+/*----- remus asynchronous checkpoint callback -----*/
+
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc);
+
+static void libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
-    if (dss->hvm &&
-        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
-        return 0;
+    if (dss->hvm) {
+        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
+    } else {
+        remus_checkpoint_dm_saved(egc, dss, 0);
+    }
+}
 
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc)
+{
     /* TODO: Wait for disk and memory ack, release network buffer */
+    /* TODO: make this asynchronous */
     usleep(dss->interval * 1000);
-    return 1;
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
 }
 
 /*----- main code for suspending, in order of execution -----*/
@@ -1052,6 +1067,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
+    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
 
     if (r_info != NULL) {
         dss->interval = r_info->interval;
@@ -1101,7 +1117,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
 
     /* Convenience aliases */
     const libxl_domain_type type = dss->type;
-    const uint32_t domid = dss->domid;
 
     if (rc)
         goto out;
@@ -1119,11 +1134,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
     }
 
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
-        rc = libxl__domain_suspend_device_model(gc, domid);
+        rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
         
-        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
-        if (rc) goto out;
+        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
+        return;
     }
 
     rc = 0;
@@ -1132,14 +1147,22 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback)
 {
+    STATE_AO_GC(dss->ao);
     int rc, fd2 = -1, c;
     char buf[1024];
-    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
+    dss->save_dm_callback = callback;
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    const int fd = dss->fd;
+
     if (stat(filename, &st) < 0)
     {
         LOG(ERROR, "Unable to stat qemu save file\n");
@@ -1181,7 +1204,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return rc;
+
+    dss->save_dm_callback(egc, dss, rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7e0ab11..c7fe9e9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 
 _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
                                      uint32_t size, void *data);
-_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
+
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
+typedef void libxl__save_device_model_cb(libxl__egc*,
+                                         libxl__domain_suspend_state*, int rc);
 
 typedef struct libxl__logdirty_switch {
     const char *cmd;
@@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
     int hvm;
     int xcflags;
     int guest_responded;
+    const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
     libxl__logdirty_switch logdirty;
+    /* private for libxl__domain_save_device_model */
+    libxl__save_device_model_cb *save_dm_callback;
 };
 
 
@@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
+/* Each time the dm needs to be saved, we must call suspend and then save */
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                           libxl__domain_suspend_state *dss);
+_hidden void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback);
+
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+
 
 /*
  * Convenience macros.
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index 8832c46..3ac6f80 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -25,7 +25,7 @@ our @msgs = (
                                                 'unsigned long', 'total'] ],
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
-    [  5, 'scxW',   "checkpoint", [] ],      
+    [  5, 'scxA',   "checkpoint", [] ],      
     [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
-- 
1.7.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 Jun 08 17:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 17: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 1Sd35A-0002ga-Kd; Fri, 08 Jun 2012 17:34: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 1Sd354-0002bI-Ng
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.139.83:6280] by server-9.bemta-5.messagelabs.com id
	2A/46-29678-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339176875!32721786!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16153 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd350-0001Bm-SX; Fri, 08 Jun 2012 17:34:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd350-00005Q-QT;
	Fri, 08 Jun 2012 18:34:34 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:21 +0100
Message-ID: <1339176870-32652-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/19] libxl: prepare for asynchronous writing
	of qemu save 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

* Combine the various calls to libxl__device_model_savefile into one
  at the start of libxl__domain_suspend, storing the result in the
  dss.  Consequently a few functions take a dss instead of some or all
  of their other arguments.

* Make libxl__domain_save_device_model's API into an asynchronous
  style which takes a callback.  The function is, however, still
  synchronous; it will be made actually async in the next patch.

* Consequently make libxl__remus_domain_checkpoint_callback into an
  asynchronous callback.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h       |   18 ++++++++++--
 tools/libxl/libxl_save_msgs_gen.pl |    2 +-
 3 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d5ac79f..3a53f97 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -702,11 +702,13 @@ static void switch_logdirty_done(libxl__egc *egc,
 
 /*----- callbacks, called by xc_domain_save -----*/
 
-int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                       libxl__domain_suspend_state *dss)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
-    const char *filename = libxl__device_model_savefile(gc, domid);
+    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: {
@@ -875,7 +877,7 @@ int libxl__domain_suspend_common_callback(void *user)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -990,19 +992,32 @@ static int libxl__remus_domain_resume_callback(void *data)
     return 1;
 }
 
-static int libxl__remus_domain_checkpoint_callback(void *data)
+/*----- remus asynchronous checkpoint callback -----*/
+
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc);
+
+static void libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
-    if (dss->hvm &&
-        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
-        return 0;
+    if (dss->hvm) {
+        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
+    } else {
+        remus_checkpoint_dm_saved(egc, dss, 0);
+    }
+}
 
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc)
+{
     /* TODO: Wait for disk and memory ack, release network buffer */
+    /* TODO: make this asynchronous */
     usleep(dss->interval * 1000);
-    return 1;
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
 }
 
 /*----- main code for suspending, in order of execution -----*/
@@ -1052,6 +1067,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
+    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
 
     if (r_info != NULL) {
         dss->interval = r_info->interval;
@@ -1101,7 +1117,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
 
     /* Convenience aliases */
     const libxl_domain_type type = dss->type;
-    const uint32_t domid = dss->domid;
 
     if (rc)
         goto out;
@@ -1119,11 +1134,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
     }
 
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
-        rc = libxl__domain_suspend_device_model(gc, domid);
+        rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
         
-        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
-        if (rc) goto out;
+        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
+        return;
     }
 
     rc = 0;
@@ -1132,14 +1147,22 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback)
 {
+    STATE_AO_GC(dss->ao);
     int rc, fd2 = -1, c;
     char buf[1024];
-    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
+    dss->save_dm_callback = callback;
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    const int fd = dss->fd;
+
     if (stat(filename, &st) < 0)
     {
         LOG(ERROR, "Unable to stat qemu save file\n");
@@ -1181,7 +1204,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return rc;
+
+    dss->save_dm_callback(egc, dss, rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7e0ab11..c7fe9e9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 
 _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
                                      uint32_t size, void *data);
-_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
+
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
+typedef void libxl__save_device_model_cb(libxl__egc*,
+                                         libxl__domain_suspend_state*, int rc);
 
 typedef struct libxl__logdirty_switch {
     const char *cmd;
@@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
     int hvm;
     int xcflags;
     int guest_responded;
+    const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
     libxl__logdirty_switch logdirty;
+    /* private for libxl__domain_save_device_model */
+    libxl__save_device_model_cb *save_dm_callback;
 };
 
 
@@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
+/* Each time the dm needs to be saved, we must call suspend and then save */
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                           libxl__domain_suspend_state *dss);
+_hidden void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback);
+
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+
 
 /*
  * Convenience macros.
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index 8832c46..3ac6f80 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -25,7 +25,7 @@ our @msgs = (
                                                 'unsigned long', 'total'] ],
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
-    [  5, 'scxW',   "checkpoint", [] ],      
+    [  5, 'scxA',   "checkpoint", [] ],      
     [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
-- 
1.7.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 Jun 08 17:35:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Sd35B-0002hq-OM; Fri, 08 Jun 2012 17:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002at-TQ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:49280] by server-1.bemta-4.messagelabs.com id
	33/1E-10042-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12747 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001CA-DF; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-000060-BT;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:30 +0100
Message-ID: <1339176870-32652-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 19/19] libxl: DO NOT APPLY enforce prohibition
	on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/gentypes.py      |    1 -
 tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 5 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1b81963..deff6f8 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 10d7115..1a32d9e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f9ee949..0972f0e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1537,10 +1543,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
1.7.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 Jun 08 17:35:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 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 1Sd35B-0002hq-OM; Fri, 08 Jun 2012 17:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sd354-0002at-TQ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 17:34:39 +0000
Received: from [85.158.143.99:49280] by server-1.bemta-4.messagelabs.com id
	33/1E-10042-DA732DF4; Fri, 08 Jun 2012 17:34:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339176875!26642663!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3NDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12747 invoked from network); 8 Jun 2012 17:34:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 17:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="12916803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 17:34:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 8 Jun 2012 18:34:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sd351-0001CA-DF; Fri, 08 Jun 2012 17:34:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sd351-000060-BT;
	Fri, 08 Jun 2012 18:34:35 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Jun 2012 18:34:30 +0100
Message-ID: <1339176870-32652-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 19/19] libxl: DO NOT APPLY enforce prohibition
	on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/gentypes.py      |    1 -
 tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 5 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1b81963..deff6f8 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 10d7115..1a32d9e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f9ee949..0972f0e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1537,10 +1543,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
1.7.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 Jun 08 18:07:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd3ah-0005qI-Nq; Fri, 08 Jun 2012 18:07:19 +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 1Sd3ag-0005qD-Du
	for Xen-devel@lists.xensource.com; Fri, 08 Jun 2012 18:07:18 +0000
Received: from [85.158.143.99:34921] by server-1.bemta-4.messagelabs.com id
	CE/90-10042-55F32DF4; Fri, 08 Jun 2012 18:07:17 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339178835!24938919!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4MDAwMg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28153 invoked from network); 8 Jun 2012 18:07:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 18:07:17 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q58I7CR2011534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <Xen-devel@lists.xensource.com>; Fri, 8 Jun 2012 18:07:13 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
	q58I7C7n004649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <Xen-devel@lists.xensource.com>; Fri, 8 Jun 2012 18:07:12 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
	q58I7BI0006072
	for <Xen-devel@lists.xensource.com>; Fri, 8 Jun 2012 13:07:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Jun 2012 11:07:11 -0700
Date: Fri, 8 Jun 2012 11:07:10 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120608110710.11850064@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
Content-Type: multipart/mixed; boundary="MP_/JsXDkVYMe/xsCaVOLECMtgA"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH]: gdbsx: send virq to guest if gdbsx_vcpu_event
 is not active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/JsXDkVYMe/xsCaVOLECMtgA
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


gdbsx got broken along the way. During domain pause, don't send
VIRQ_DEBUGGER to guest if gdbsx is active on that guest.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>


thanks,
Mukesh

--MP_/JsXDkVYMe/xsCaVOLECMtgA
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=gdbsx.patch

diff -r 32034d1914a6 xen/common/domain.c
--- a/xen/common/domain.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/domain.c	Fri Jun 08 11:02:59 2012 -0700
@@ -624,7 +624,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* if gdbsx active, we just need to pause the domain */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */

--MP_/JsXDkVYMe/xsCaVOLECMtgA
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MP_/JsXDkVYMe/xsCaVOLECMtgA--


From xen-devel-bounces@lists.xen.org Fri Jun 08 18:07:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sd3ah-0005qI-Nq; Fri, 08 Jun 2012 18:07:19 +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 1Sd3ag-0005qD-Du
	for Xen-devel@lists.xensource.com; Fri, 08 Jun 2012 18:07:18 +0000
Received: from [85.158.143.99:34921] by server-1.bemta-4.messagelabs.com id
	CE/90-10042-55F32DF4; Fri, 08 Jun 2012 18:07:17 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339178835!24938919!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4MDAwMg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28153 invoked from network); 8 Jun 2012 18:07:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Jun 2012 18:07:17 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q58I7CR2011534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <Xen-devel@lists.xensource.com>; Fri, 8 Jun 2012 18:07:13 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
	q58I7C7n004649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <Xen-devel@lists.xensource.com>; Fri, 8 Jun 2012 18:07:12 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
	q58I7BI0006072
	for <Xen-devel@lists.xensource.com>; Fri, 8 Jun 2012 13:07:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Jun 2012 11:07:11 -0700
Date: Fri, 8 Jun 2012 11:07:10 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120608110710.11850064@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
Content-Type: multipart/mixed; boundary="MP_/JsXDkVYMe/xsCaVOLECMtgA"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH]: gdbsx: send virq to guest if gdbsx_vcpu_event
 is not active
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/JsXDkVYMe/xsCaVOLECMtgA
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


gdbsx got broken along the way. During domain pause, don't send
VIRQ_DEBUGGER to guest if gdbsx is active on that guest.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>


thanks,
Mukesh

--MP_/JsXDkVYMe/xsCaVOLECMtgA
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=gdbsx.patch

diff -r 32034d1914a6 xen/common/domain.c
--- a/xen/common/domain.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/domain.c	Fri Jun 08 11:02:59 2012 -0700
@@ -624,7 +624,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* if gdbsx active, we just need to pause the domain */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */

--MP_/JsXDkVYMe/xsCaVOLECMtgA
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MP_/JsXDkVYMe/xsCaVOLECMtgA--


From xen-devel-bounces@lists.xen.org Fri Jun 08 18:15:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18: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 1Sd3if-00062e-NQ; Fri, 08 Jun 2012 18:15:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1Sd3ie-00062Z-1N
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 18:15:32 +0000
Received: from [85.158.139.83:64081] by server-9.bemta-5.messagelabs.com id
	37/4E-29678-34142DF4; Fri, 08 Jun 2012 18:15:31 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339179329!33007470!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2838 invoked from network); 8 Jun 2012 18:15:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 18:15:30 -0000
Received: by werf3 with SMTP id f3so974672wer.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 11:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+cMITHKjHIYuLkurFsKqKTllMj3+sDjkK+wit5GLFX8=;
	b=uDbEnGfvZeksdl2Db8TwTq54J5jL8QCJQPpa9H1YC3+XhhM1tUvHc32QUOfRmDgCtU
	zgRSAqyO1o07RsxjE0Jz1YOsqlDLK1BgPuoKcnU+DIrrBTK61j/ZFsRsEMDVRKxNdOVx
	cnH0w3n87oSn5yWJG5xr8fDMhCO7NEtycqLzvPSRT8JP2J4aeo+ln8WKxwsAE8YlRQAi
	DnX5LH6ZzBakrfvfWzgeNup5DPpXnZFt2THzPoPFhXtZ82nO6HCzqyDdfcluaJW4kaYH
	trDFoGsmJ6POoFj+2TEtkGcOuBwM7k2pG3+2wVSkDu7ybcnxvDVEn8UEzMd/w+Uh/zsR
	Bxnw==
MIME-Version: 1.0
Received: by 10.216.143.200 with SMTP id l50mr1730903wej.58.1339179329612;
	Fri, 08 Jun 2012 11:15:29 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Fri, 8 Jun 2012 11:15:29 -0700 (PDT)
In-Reply-To: <1339050679.6557.21.camel@dagon.hellion.org.uk>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
Date: Fri, 8 Jun 2012 11:15:29 -0700
Message-ID: <CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3350830703301219946=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3350830703301219946==
Content-Type: multipart/alternative; boundary=0016e6dedd8c3b6a4704c1f9fc58

--0016e6dedd8c3b6a4704c1f9fc58
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 6, 2012 at 11:31 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> Please don't top post, it makes it hard to follow the flow of the
> conversation.
>
> You might also find it useful to read
> http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions
>
> On Thu, 2012-06-07 at 05:29 +0100, Zeinab Alebouyeh wrote:
> > Thanks but I think if I find the base physical address of xen image I
> > can convert virtual address to physical address
>
> I'm not sure what this has to do with taking the address of a label,
> like you originally asked, but...
>
> There are macros to convert a xenheap virtual address into a physical
> one and back, see __pa and __va. (Note that these only work for xenheap
> addresses).
>
> > I'm working in xen4 and my platform is: Processor AMD 64 and Centos 6
> > i386 with 8G of RAM
>
> Are you using a 32-bit or 64-bit hypervisor?
>
> I strongly recommend basing all future x86 work on 64-bit Xen, even if
> you are using a 32 bit dom0.
>
> > Can anyone tell me The physical address that xen image load in it?
> > This physical address depends on platform?
>
> Yes, Xen will relocate itself at start of day. You should be able to
> figure out the details from the implementation of __pa and __va.
>
> It might be helpful if you described what you are actually trying to
> achieve here -- what is your end goal?
>
> Ian.
>

Hi
Because currently I'm not in lab I don't know my hypervisor is 32b or 64
bit.
I'm working in a security project. for improve security of applications
running in virtualized environment. I want to use the security instruction
of AMD SVM named SKINIT.
because this instruction must run in ring0, I add a hypercall in xen and
write my codes in my hypercall function.
The skinit instruction takes the physical address of a block as an input
operand( in the eax register) and establish a secure execution environment
for a software component(block)
I have a label in my hypercall function that is the start of my block. In
order to use skinit I want grab the physical address of my label to save in
eax register.

Thanks if anyone help me.

--0016e6dedd8c3b6a4704c1f9fc58
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Jun 6, 2012 at 11:31 PM, Ian Cam=
pbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" targ=
et=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:1px #ccc solid=
;padding-left:1ex">
Please don&#39;t top post, it makes it hard to follow the flow of the<br>
conversation.<br>
<br>
You might also find it useful to read<br>
<a href=3D"http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions" target=3D"_=
blank">http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions</a><br>
<div class=3D"im"><br>
On Thu, 2012-06-07 at 05:29 +0100, Zeinab Alebouyeh wrote:<br>
&gt; Thanks but I think if I find the base physical address of xen image I<=
br>
&gt; can convert virtual address to physical address<br>
<br>
</div>I&#39;m not sure what this has to do with taking the address of a lab=
el,<br>
like you originally asked, but...<br>
<br>
There are macros to convert a xenheap virtual address into a physical<br>
one and back, see __pa and __va. (Note that these only work for xenheap<br>
addresses).<br>
<div class=3D"im"><br>
&gt; I&#39;m working in xen4 and my platform is: Processor AMD 64 and Cento=
s 6<br>
&gt; i386 with 8G of RAM<br>
<br>
</div>Are you using a 32-bit or 64-bit hypervisor?<br>
<br>
I strongly recommend basing all future x86 work on 64-bit Xen, even if<br>
you are using a 32 bit dom0.<br>
<div class=3D"im"><br>
&gt; Can anyone tell me The physical address that xen image load in it?<br>
&gt; This physical address depends on platform?<br>
<br>
</div>Yes, Xen will relocate itself at start of day. You should be able to<=
br>
figure out the details from the implementation of __pa and __va.<br>
<br>
It might be helpful if you described what you are actually trying to<br>
achieve here -- what is your end goal?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br></font></span></blockquote><div><br>Hi<br>Because currently I&#39;m=
 not in lab I don&#39;t know my hypervisor is 32b or 64 bit.<br>I&#39;m wor=
king in a security project. for improve security of applications running in=
 virtualized environment. I want to use the security instruction of AMD SVM=
 named SKINIT.<br>
because this instruction must run in ring0, I add a hypercall in xen and wr=
ite my codes in my hypercall function.<br>The skinit instruction takes the =
physical address of a block as an input operand( in the eax register) and e=
stablish a secure execution environment for a software component(block)<br>
I have a label in my hypercall function that is the start of my block. In o=
rder to use skinit I want grab the physical address of my label to save in =
eax register.<br><br>Thanks if anyone help me.<br></div></div><br>

--0016e6dedd8c3b6a4704c1f9fc58--


--===============3350830703301219946==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3350830703301219946==--


From xen-devel-bounces@lists.xen.org Fri Jun 08 18:15:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18: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 1Sd3if-00062e-NQ; Fri, 08 Jun 2012 18:15:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1Sd3ie-00062Z-1N
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 18:15:32 +0000
Received: from [85.158.139.83:64081] by server-9.bemta-5.messagelabs.com id
	37/4E-29678-34142DF4; Fri, 08 Jun 2012 18:15:31 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339179329!33007470!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2838 invoked from network); 8 Jun 2012 18:15:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 18:15:30 -0000
Received: by werf3 with SMTP id f3so974672wer.32
	for <xen-devel@lists.xen.org>; Fri, 08 Jun 2012 11:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+cMITHKjHIYuLkurFsKqKTllMj3+sDjkK+wit5GLFX8=;
	b=uDbEnGfvZeksdl2Db8TwTq54J5jL8QCJQPpa9H1YC3+XhhM1tUvHc32QUOfRmDgCtU
	zgRSAqyO1o07RsxjE0Jz1YOsqlDLK1BgPuoKcnU+DIrrBTK61j/ZFsRsEMDVRKxNdOVx
	cnH0w3n87oSn5yWJG5xr8fDMhCO7NEtycqLzvPSRT8JP2J4aeo+ln8WKxwsAE8YlRQAi
	DnX5LH6ZzBakrfvfWzgeNup5DPpXnZFt2THzPoPFhXtZ82nO6HCzqyDdfcluaJW4kaYH
	trDFoGsmJ6POoFj+2TEtkGcOuBwM7k2pG3+2wVSkDu7ybcnxvDVEn8UEzMd/w+Uh/zsR
	Bxnw==
MIME-Version: 1.0
Received: by 10.216.143.200 with SMTP id l50mr1730903wej.58.1339179329612;
	Fri, 08 Jun 2012 11:15:29 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Fri, 8 Jun 2012 11:15:29 -0700 (PDT)
In-Reply-To: <1339050679.6557.21.camel@dagon.hellion.org.uk>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
Date: Fri, 8 Jun 2012 11:15:29 -0700
Message-ID: <CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3350830703301219946=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3350830703301219946==
Content-Type: multipart/alternative; boundary=0016e6dedd8c3b6a4704c1f9fc58

--0016e6dedd8c3b6a4704c1f9fc58
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 6, 2012 at 11:31 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> Please don't top post, it makes it hard to follow the flow of the
> conversation.
>
> You might also find it useful to read
> http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions
>
> On Thu, 2012-06-07 at 05:29 +0100, Zeinab Alebouyeh wrote:
> > Thanks but I think if I find the base physical address of xen image I
> > can convert virtual address to physical address
>
> I'm not sure what this has to do with taking the address of a label,
> like you originally asked, but...
>
> There are macros to convert a xenheap virtual address into a physical
> one and back, see __pa and __va. (Note that these only work for xenheap
> addresses).
>
> > I'm working in xen4 and my platform is: Processor AMD 64 and Centos 6
> > i386 with 8G of RAM
>
> Are you using a 32-bit or 64-bit hypervisor?
>
> I strongly recommend basing all future x86 work on 64-bit Xen, even if
> you are using a 32 bit dom0.
>
> > Can anyone tell me The physical address that xen image load in it?
> > This physical address depends on platform?
>
> Yes, Xen will relocate itself at start of day. You should be able to
> figure out the details from the implementation of __pa and __va.
>
> It might be helpful if you described what you are actually trying to
> achieve here -- what is your end goal?
>
> Ian.
>

Hi
Because currently I'm not in lab I don't know my hypervisor is 32b or 64
bit.
I'm working in a security project. for improve security of applications
running in virtualized environment. I want to use the security instruction
of AMD SVM named SKINIT.
because this instruction must run in ring0, I add a hypercall in xen and
write my codes in my hypercall function.
The skinit instruction takes the physical address of a block as an input
operand( in the eax register) and establish a secure execution environment
for a software component(block)
I have a label in my hypercall function that is the start of my block. In
order to use skinit I want grab the physical address of my label to save in
eax register.

Thanks if anyone help me.

--0016e6dedd8c3b6a4704c1f9fc58
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Jun 6, 2012 at 11:31 PM, Ian Cam=
pbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" targ=
et=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:1px #ccc solid=
;padding-left:1ex">
Please don&#39;t top post, it makes it hard to follow the flow of the<br>
conversation.<br>
<br>
You might also find it useful to read<br>
<a href=3D"http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions" target=3D"_=
blank">http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions</a><br>
<div class=3D"im"><br>
On Thu, 2012-06-07 at 05:29 +0100, Zeinab Alebouyeh wrote:<br>
&gt; Thanks but I think if I find the base physical address of xen image I<=
br>
&gt; can convert virtual address to physical address<br>
<br>
</div>I&#39;m not sure what this has to do with taking the address of a lab=
el,<br>
like you originally asked, but...<br>
<br>
There are macros to convert a xenheap virtual address into a physical<br>
one and back, see __pa and __va. (Note that these only work for xenheap<br>
addresses).<br>
<div class=3D"im"><br>
&gt; I&#39;m working in xen4 and my platform is: Processor AMD 64 and Cento=
s 6<br>
&gt; i386 with 8G of RAM<br>
<br>
</div>Are you using a 32-bit or 64-bit hypervisor?<br>
<br>
I strongly recommend basing all future x86 work on 64-bit Xen, even if<br>
you are using a 32 bit dom0.<br>
<div class=3D"im"><br>
&gt; Can anyone tell me The physical address that xen image load in it?<br>
&gt; This physical address depends on platform?<br>
<br>
</div>Yes, Xen will relocate itself at start of day. You should be able to<=
br>
figure out the details from the implementation of __pa and __va.<br>
<br>
It might be helpful if you described what you are actually trying to<br>
achieve here -- what is your end goal?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br></font></span></blockquote><div><br>Hi<br>Because currently I&#39;m=
 not in lab I don&#39;t know my hypervisor is 32b or 64 bit.<br>I&#39;m wor=
king in a security project. for improve security of applications running in=
 virtualized environment. I want to use the security instruction of AMD SVM=
 named SKINIT.<br>
because this instruction must run in ring0, I add a hypercall in xen and wr=
ite my codes in my hypercall function.<br>The skinit instruction takes the =
physical address of a block as an input operand( in the eax register) and e=
stablish a secure execution environment for a software component(block)<br>
I have a label in my hypercall function that is the start of my block. In o=
rder to use skinit I want grab the physical address of my label to save in =
eax register.<br><br>Thanks if anyone help me.<br></div></div><br>

--0016e6dedd8c3b6a4704c1f9fc58--


--===============3350830703301219946==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3350830703301219946==--


From xen-devel-bounces@lists.xen.org Fri Jun 08 18:31:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18:31: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 1Sd3xn-0006Gy-4R; Fri, 08 Jun 2012 18:31:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1Sd3xl-0006Gt-OX
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 18:31:09 +0000
Received: from [85.158.143.35:32223] by server-2.bemta-4.messagelabs.com id
	30/BE-17938-CE442DF4; Fri, 08 Jun 2012 18:31:08 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339180267!8532198!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3438 invoked from network); 8 Jun 2012 18:31:08 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-2.tower-21.messagelabs.com with SMTP;
	8 Jun 2012 18:31:08 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id F30F31F880A4
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 14:34:02 -0400 (EDT)
Received: (qmail 18056 invoked by uid 108); 8 Jun 2012 14:31:07 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.102.212.111)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 8 Jun 2012 14:31:07 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id B81A83784BD; Fri,  8 Jun 2012 13:31:06 -0500 (CDT)
Date: Fri, 8 Jun 2012 13:31:06 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120608183106.GA12674@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
	<20432.59361.773966.629519@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20432.59361.773966.629519@mariner.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] Using "xl create" without domain 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

[...]

>>> -    if (!S_ISREG(stab.st_mode)) {
>>> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
>>> +    if (S_ISDIR(stab.st_mode)) {
>>> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);
>>
>> This is not correct.  If, for example, /dev/tty is specified, it will
>> go wrong.
>>
>> The reason for the restriction to plain files is that those are the
>> only thing on which stat works to provide the size.  If we are to
>> support other objects, we need to change the reading algorithm.
>
> Another alternative would be to special-case the string "/dev/null"
> (in xl, not libxl) and not read a config file at all in that case.

This patch treats /dev/null as a special case.

# HG changeset patch
# Parent 435493696053a079ec17d6e1a63e5f2be3a2c9d0
xl: Allow use of /dev/null with xl create to enable command-line definition

xm allows specifying /dev/null as the domain configuration argument to its
create option; add same functionality to xl. xl treats the configuration
argument /dev/null as a special case.  This allows specifying an entire
domain configuration on the command line.

Signed-off-by: W. Michael Petullo <mike@flyn.org>

diff -r 435493696053 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Fri May 25 08:18:47 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 07 22:40:58 2012 -0500
@@ -1454,10 +1454,13 @@ static int create_domain(struct domain_c

     if (config_file) {
         free(config_data);  config_data = 0;
-        ret = libxl_read_file_contents(&ctx, config_file,
-                                       &config_data, &config_len);
-        if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
-                           config_file, strerror(errno)); return ERROR_FAIL; }
+        // /dev/null represents special case (read config. from command line)
+        if (strcmp(config_file, "/dev/null")) {
+            ret = libxl_read_file_contents(&ctx, config_file,
+                                           &config_data, &config_len);
+            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
+                               config_file, strerror(errno)); return ERROR_FAIL; }
+        }
         if (!restore_file && extra_config && strlen(extra_config)) {
             if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
                 fprintf(stderr, "Failed to attach extra configration\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 18:31:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18:31: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 1Sd3xn-0006Gy-4R; Fri, 08 Jun 2012 18:31:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1Sd3xl-0006Gt-OX
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 18:31:09 +0000
Received: from [85.158.143.35:32223] by server-2.bemta-4.messagelabs.com id
	30/BE-17938-CE442DF4; Fri, 08 Jun 2012 18:31:08 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339180267!8532198!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3438 invoked from network); 8 Jun 2012 18:31:08 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-2.tower-21.messagelabs.com with SMTP;
	8 Jun 2012 18:31:08 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id F30F31F880A4
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 14:34:02 -0400 (EDT)
Received: (qmail 18056 invoked by uid 108); 8 Jun 2012 14:31:07 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.102.212.111)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 8 Jun 2012 14:31:07 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id B81A83784BD; Fri,  8 Jun 2012 13:31:06 -0500 (CDT)
Date: Fri, 8 Jun 2012 13:31:06 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120608183106.GA12674@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
	<20432.59361.773966.629519@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20432.59361.773966.629519@mariner.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] Using "xl create" without domain 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

[...]

>>> -    if (!S_ISREG(stab.st_mode)) {
>>> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not a plain file", filename);
>>> +    if (S_ISDIR(stab.st_mode)) {
>>> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is a directory", filename);
>>
>> This is not correct.  If, for example, /dev/tty is specified, it will
>> go wrong.
>>
>> The reason for the restriction to plain files is that those are the
>> only thing on which stat works to provide the size.  If we are to
>> support other objects, we need to change the reading algorithm.
>
> Another alternative would be to special-case the string "/dev/null"
> (in xl, not libxl) and not read a config file at all in that case.

This patch treats /dev/null as a special case.

# HG changeset patch
# Parent 435493696053a079ec17d6e1a63e5f2be3a2c9d0
xl: Allow use of /dev/null with xl create to enable command-line definition

xm allows specifying /dev/null as the domain configuration argument to its
create option; add same functionality to xl. xl treats the configuration
argument /dev/null as a special case.  This allows specifying an entire
domain configuration on the command line.

Signed-off-by: W. Michael Petullo <mike@flyn.org>

diff -r 435493696053 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Fri May 25 08:18:47 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 07 22:40:58 2012 -0500
@@ -1454,10 +1454,13 @@ static int create_domain(struct domain_c

     if (config_file) {
         free(config_data);  config_data = 0;
-        ret = libxl_read_file_contents(&ctx, config_file,
-                                       &config_data, &config_len);
-        if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
-                           config_file, strerror(errno)); return ERROR_FAIL; }
+        // /dev/null represents special case (read config. from command line)
+        if (strcmp(config_file, "/dev/null")) {
+            ret = libxl_read_file_contents(&ctx, config_file,
+                                           &config_data, &config_len);
+            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
+                               config_file, strerror(errno)); return ERROR_FAIL; }
+        }
         if (!restore_file && extra_config && strlen(extra_config)) {
             if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
                 fprintf(stderr, "Failed to attach extra configration\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 18:56:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18: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 1Sd4MI-0006iD-D5; Fri, 08 Jun 2012 18:56:30 +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 1Sd4MH-0006i8-CQ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 18:56:29 +0000
Received: from [85.158.143.99:60484] by server-2.bemta-4.messagelabs.com id
	47/F9-17938-CDA42DF4; Fri, 08 Jun 2012 18:56:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339181786!22327038!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 8 Jun 2012 18:56:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 18:56:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330923600"; d="scan'208";a="27400337"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:56:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 14:56:25 -0400
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 1Sd4MD-0006ox-Ai;
	Fri, 08 Jun 2012 19:56:25 +0100
Message-ID: <4FD24AD9.3010607@citrix.com>
Date: Fri, 8 Jun 2012 19:56:25 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------060602030301090907040708"
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] x86/nmi: Fix deadlock in unknown_nmi_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060602030301090907040708
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

x86/nmi: Fix deadlock in unknown_nmi_error()

Additionally, correct the text description to reflect what is being
done, and
make use of fatal_trap() in preference to kexec_crash() in case an
unknown NMI
occurs before a kdump kernel has been loaded.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>


diff -r 32034d1914a6 -r 996f7fe3c3b8 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3293,7 +3293,7 @@ static void io_check_error(struct cpu_us
     outb((inb(0x61) & 0x07) | 0x00, 0x61); /* enable IOCK */
 }
 
-static void unknown_nmi_error(unsigned char reason)
+static void unknown_nmi_error(struct cpu_user_regs *regs, unsigned char
reason)
 {
     switch ( opt_nmi[0] )
     {
@@ -3302,10 +3302,10 @@ static void unknown_nmi_error(unsigned c
     case 'i': /* 'ignore' */
         break;
     default:  /* 'fatal' */
+        console_force_unlock();
         printk("Uhhuh. NMI received for unknown reason %02x.\n", reason);
-        printk("Dazed and confused, but trying to continue\n");
         printk("Do you have a strange power saving mode enabled?\n");
-        kexec_crash();
+        fatal_trap(TRAP_nmi, regs);
     }
 }
 
@@ -3338,7 +3338,7 @@ void do_nmi(struct cpu_user_regs *regs)
         else if ( reason & 0x40 )
             io_check_error(regs);
         else if ( !nmi_watchdog )
-            unknown_nmi_error((unsigned char)(reason&0xff));
+            unknown_nmi_error(regs, (unsigned char)(reason&0xff));
     }
 }

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060602030301090907040708
Content-Type: text/x-patch; name="nmi-fix-deadlock.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="nmi-fix-deadlock.patch"

# HG changeset patch
# Parent 32034d1914a607d7b6f1f060352b4cac973600f8
x86/nmi: Fix deadlock in unknown_nmi_error()

Additionally, correct the text description to reflect what is being done, and
make use of fatal_trap() in preference to kexec_crash() in case an unknown NMI
occurs before a kdump kernel has been loaded.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 32034d1914a6 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3293,7 +3293,7 @@ static void io_check_error(struct cpu_us
     outb((inb(0x61) & 0x07) | 0x00, 0x61); /* enable IOCK */
 }
 
-static void unknown_nmi_error(unsigned char reason)
+static void unknown_nmi_error(struct cpu_user_regs *regs, unsigned char reason)
 {
     switch ( opt_nmi[0] )
     {
@@ -3302,10 +3302,10 @@ static void unknown_nmi_error(unsigned c
     case 'i': /* 'ignore' */
         break;
     default:  /* 'fatal' */
+        console_force_unlock();
         printk("Uhhuh. NMI received for unknown reason %02x.\n", reason);
-        printk("Dazed and confused, but trying to continue\n");
         printk("Do you have a strange power saving mode enabled?\n");
-        kexec_crash();
+        fatal_trap(TRAP_nmi, regs);
     }
 }
 
@@ -3338,7 +3338,7 @@ void do_nmi(struct cpu_user_regs *regs)
         else if ( reason & 0x40 )
             io_check_error(regs);
         else if ( !nmi_watchdog )
-            unknown_nmi_error((unsigned char)(reason&0xff));
+            unknown_nmi_error(regs, (unsigned char)(reason&0xff));
     }
 }
 

--------------060602030301090907040708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060602030301090907040708--


From xen-devel-bounces@lists.xen.org Fri Jun 08 18:56:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 18: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 1Sd4MI-0006iD-D5; Fri, 08 Jun 2012 18:56:30 +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 1Sd4MH-0006i8-CQ
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 18:56:29 +0000
Received: from [85.158.143.99:60484] by server-2.bemta-4.messagelabs.com id
	47/F9-17938-CDA42DF4; Fri, 08 Jun 2012 18:56:28 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339181786!22327038!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDk4Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 8 Jun 2012 18:56:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jun 2012 18:56:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,738,1330923600"; d="scan'208";a="27400337"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jun 2012 14:56:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 8 Jun 2012 14:56:25 -0400
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 1Sd4MD-0006ox-Ai;
	Fri, 08 Jun 2012 19:56:25 +0100
Message-ID: <4FD24AD9.3010607@citrix.com>
Date: Fri, 8 Jun 2012 19:56:25 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------060602030301090907040708"
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] x86/nmi: Fix deadlock in unknown_nmi_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060602030301090907040708
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

x86/nmi: Fix deadlock in unknown_nmi_error()

Additionally, correct the text description to reflect what is being
done, and
make use of fatal_trap() in preference to kexec_crash() in case an
unknown NMI
occurs before a kdump kernel has been loaded.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>


diff -r 32034d1914a6 -r 996f7fe3c3b8 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3293,7 +3293,7 @@ static void io_check_error(struct cpu_us
     outb((inb(0x61) & 0x07) | 0x00, 0x61); /* enable IOCK */
 }
 
-static void unknown_nmi_error(unsigned char reason)
+static void unknown_nmi_error(struct cpu_user_regs *regs, unsigned char
reason)
 {
     switch ( opt_nmi[0] )
     {
@@ -3302,10 +3302,10 @@ static void unknown_nmi_error(unsigned c
     case 'i': /* 'ignore' */
         break;
     default:  /* 'fatal' */
+        console_force_unlock();
         printk("Uhhuh. NMI received for unknown reason %02x.\n", reason);
-        printk("Dazed and confused, but trying to continue\n");
         printk("Do you have a strange power saving mode enabled?\n");
-        kexec_crash();
+        fatal_trap(TRAP_nmi, regs);
     }
 }
 
@@ -3338,7 +3338,7 @@ void do_nmi(struct cpu_user_regs *regs)
         else if ( reason & 0x40 )
             io_check_error(regs);
         else if ( !nmi_watchdog )
-            unknown_nmi_error((unsigned char)(reason&0xff));
+            unknown_nmi_error(regs, (unsigned char)(reason&0xff));
     }
 }

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060602030301090907040708
Content-Type: text/x-patch; name="nmi-fix-deadlock.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="nmi-fix-deadlock.patch"

# HG changeset patch
# Parent 32034d1914a607d7b6f1f060352b4cac973600f8
x86/nmi: Fix deadlock in unknown_nmi_error()

Additionally, correct the text description to reflect what is being done, and
make use of fatal_trap() in preference to kexec_crash() in case an unknown NMI
occurs before a kdump kernel has been loaded.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 32034d1914a6 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3293,7 +3293,7 @@ static void io_check_error(struct cpu_us
     outb((inb(0x61) & 0x07) | 0x00, 0x61); /* enable IOCK */
 }
 
-static void unknown_nmi_error(unsigned char reason)
+static void unknown_nmi_error(struct cpu_user_regs *regs, unsigned char reason)
 {
     switch ( opt_nmi[0] )
     {
@@ -3302,10 +3302,10 @@ static void unknown_nmi_error(unsigned c
     case 'i': /* 'ignore' */
         break;
     default:  /* 'fatal' */
+        console_force_unlock();
         printk("Uhhuh. NMI received for unknown reason %02x.\n", reason);
-        printk("Dazed and confused, but trying to continue\n");
         printk("Do you have a strange power saving mode enabled?\n");
-        kexec_crash();
+        fatal_trap(TRAP_nmi, regs);
     }
 }
 
@@ -3338,7 +3338,7 @@ void do_nmi(struct cpu_user_regs *regs)
         else if ( reason & 0x40 )
             io_check_error(regs);
         else if ( !nmi_watchdog )
-            unknown_nmi_error((unsigned char)(reason&0xff));
+            unknown_nmi_error(regs, (unsigned char)(reason&0xff));
     }
 }
 

--------------060602030301090907040708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060602030301090907040708--


From xen-devel-bounces@lists.xen.org Fri Jun 08 19:32:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 19:32: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 1Sd4uj-000779-HN; Fri, 08 Jun 2012 19:32:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Sd4uh-000774-VB
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 19:32:04 +0000
Received: from [85.158.139.83:25443] by server-9.bemta-5.messagelabs.com id
	FE/ED-29678-23352DF4; Fri, 08 Jun 2012 19:32:02 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339183921!28744227!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32216 invoked from network); 8 Jun 2012 19:32:02 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 19:32:02 -0000
Received: from mail185-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 19:31:10 +0000
Received: from mail185-va3 (localhost [127.0.0.1])	by
	mail185-va3-R.bigfish.com (Postfix) with ESMTP id A0E96160327;
	Fri,  8 Jun 2012 19:31:09 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail185-va3 (localhost.localdomain [127.0.0.1]) by mail185-va3
	(MessageSwitch) id 1339183867188808_7600;
	Fri,  8 Jun 2012 19:31:07 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.253])	by
	mail185-va3.bigfish.com (Postfix) with ESMTP id 27A28360051;
	Fri,  8 Jun 2012 19:31:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 19:31:05 +0000
X-WSS-ID: 0M5BCX6-01-A3C-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25DF01028182;	Fri,  8 Jun 2012 14:31:53 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 14:32:15 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 14:31:54 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	15:28:06 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3990149C20C; Fri,  8 Jun 2012
	20:28:05 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 270AF2D202B; Fri,
	8 Jun 2012 21:28:05 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 64754e082aa4ce22116cc86da60f544e97b0e3b1
Message-ID: <64754e082aa4ce22116c.1339183680@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Fri, 8 Jun 2012 21:28:00 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <roger.pau@entel.upc.edu>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools,
 configure: Fix LIB_PATH computation in configure scripts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339181838 -7200
# Node ID 64754e082aa4ce22116cc86da60f544e97b0e3b1
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools, configure: Fix LIB_PATH computation in configure scripts

tool's configure script sets LIB_PATH by chopping off ${exec_prefix}
from $libdir and it does so by computing length of ${exec_prefix} value.
However, $libdir's value is a literal '${exec_prefix}/lib' string
(i.e. $exec_prefix is not substituted) and therefore LIB_PATH may be
computed incorrectly, most likely as "c_prefix}/lib64" assuming that
exec_prefix is NONE.

Instead, we should start at offset `expr length '${exec_prefix}/'
(which is 15).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r 64754e082aa4 tools/configure
--- a/tools/configure	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/configure	Fri Jun 08 20:57:18 2012 +0200
@@ -6062,7 +6062,7 @@ fi
 
 else
 
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length '${exec_prefix}/'`}"
 
 fi
 
diff -r 32034d1914a6 -r 64754e082aa4 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/m4/default_lib.m4	Fri Jun 08 20:57:18 2012 +0200
@@ -9,6 +9,6 @@ AC_DEFUN([AX_DEFAULT_LIB],
         LIB_PATH="lib"
     ])
 ], [
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length "${exec_prefix}/"`}"
 ])
 AC_SUBST(LIB_PATH)])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 19:32:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 19:32: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 1Sd4uj-000779-HN; Fri, 08 Jun 2012 19:32:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Sd4uh-000774-VB
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 19:32:04 +0000
Received: from [85.158.139.83:25443] by server-9.bemta-5.messagelabs.com id
	FE/ED-29678-23352DF4; Fri, 08 Jun 2012 19:32:02 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339183921!28744227!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32216 invoked from network); 8 Jun 2012 19:32:02 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 19:32:02 -0000
Received: from mail185-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 19:31:10 +0000
Received: from mail185-va3 (localhost [127.0.0.1])	by
	mail185-va3-R.bigfish.com (Postfix) with ESMTP id A0E96160327;
	Fri,  8 Jun 2012 19:31:09 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail185-va3 (localhost.localdomain [127.0.0.1]) by mail185-va3
	(MessageSwitch) id 1339183867188808_7600;
	Fri,  8 Jun 2012 19:31:07 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.253])	by
	mail185-va3.bigfish.com (Postfix) with ESMTP id 27A28360051;
	Fri,  8 Jun 2012 19:31:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 19:31:05 +0000
X-WSS-ID: 0M5BCX6-01-A3C-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25DF01028182;	Fri,  8 Jun 2012 14:31:53 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 14:32:15 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 14:31:54 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	15:28:06 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3990149C20C; Fri,  8 Jun 2012
	20:28:05 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 270AF2D202B; Fri,
	8 Jun 2012 21:28:05 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 64754e082aa4ce22116cc86da60f544e97b0e3b1
Message-ID: <64754e082aa4ce22116c.1339183680@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Fri, 8 Jun 2012 21:28:00 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <roger.pau@entel.upc.edu>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools,
 configure: Fix LIB_PATH computation in configure scripts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339181838 -7200
# Node ID 64754e082aa4ce22116cc86da60f544e97b0e3b1
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools, configure: Fix LIB_PATH computation in configure scripts

tool's configure script sets LIB_PATH by chopping off ${exec_prefix}
from $libdir and it does so by computing length of ${exec_prefix} value.
However, $libdir's value is a literal '${exec_prefix}/lib' string
(i.e. $exec_prefix is not substituted) and therefore LIB_PATH may be
computed incorrectly, most likely as "c_prefix}/lib64" assuming that
exec_prefix is NONE.

Instead, we should start at offset `expr length '${exec_prefix}/'
(which is 15).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r 64754e082aa4 tools/configure
--- a/tools/configure	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/configure	Fri Jun 08 20:57:18 2012 +0200
@@ -6062,7 +6062,7 @@ fi
 
 else
 
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length '${exec_prefix}/'`}"
 
 fi
 
diff -r 32034d1914a6 -r 64754e082aa4 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/m4/default_lib.m4	Fri Jun 08 20:57:18 2012 +0200
@@ -9,6 +9,6 @@ AC_DEFUN([AX_DEFAULT_LIB],
         LIB_PATH="lib"
     ])
 ], [
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length "${exec_prefix}/"`}"
 ])
 AC_SUBST(LIB_PATH)])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 20:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 20: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 1Sd5kU-0007lV-VO; Fri, 08 Jun 2012 20:25:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Sd5kT-0007lQ-HV
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 20:25:33 +0000
Received: from [193.109.254.147:56071] by server-10.bemta-14.messagelabs.com
	id A0/77-25709-CBF52DF4; Fri, 08 Jun 2012 20:25:32 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339187131!8862941!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5255 invoked from network); 8 Jun 2012 20:25:32 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 20:25:32 -0000
Received: from mail147-va3-R.bigfish.com (10.7.14.246) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 20:24:39 +0000
Received: from mail147-va3 (localhost [127.0.0.1])	by
	mail147-va3-R.bigfish.com (Postfix) with ESMTP id 3DEBA1E03DD;
	Fri,  8 Jun 2012 20:24:39 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail147-va3 (localhost.localdomain [127.0.0.1]) by mail147-va3
	(MessageSwitch) id 133918707776324_30896;
	Fri,  8 Jun 2012 20:24:37 +0000 (UTC)
Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.243])	by
	mail147-va3.bigfish.com (Postfix) with ESMTP id 04CAF2C00A6;
	Fri,  8 Jun 2012 20:24:37 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 20:24:34 +0000
X-WSS-ID: 0M5BFEC-01-06K-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 235D31028171;	Fri,  8 Jun 2012 15:25:24 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 15:25:46 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 15:25:25 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	16:23:43 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id ACB4049C20C; Fri,  8 Jun 2012
	21:23:42 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 9BC332D202B; Fri,
	8 Jun 2012 22:23:42 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: fa21f847fc66619fad38923cd87d6ba51d731eba
Message-ID: <fa21f847fc66619fad38.1339187014@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Fri, 8 Jun 2012 22:23:34 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <roger.pau@entel.upc.edu>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] tools,
 configure: Fix LIB_PATH computation in configure scripts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339185838 -7200
# Node ID fa21f847fc66619fad38923cd87d6ba51d731eba
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools, configure: Fix LIB_PATH computation in configure scripts

tool's configure script sets LIB_PATH by chopping off ${exec_prefix}
from $libdir and it does so by computing length of ${exec_prefix} value.
However, $libdir's value is a literal '${exec_prefix}/lib' string
(i.e. $exec_prefix is not substituted) and therefore LIB_PATH may be
computed incorrectly, most likely as "c_prefix}/lib64" assuming that
exec_prefix is NONE.

Instead, we should start at offset `expr length '${exec_prefix}/'
(which is 15).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r fa21f847fc66 tools/configure
--- a/tools/configure	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/configure	Fri Jun 08 22:03:58 2012 +0200
@@ -6062,7 +6062,7 @@ fi
 
 else
 
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length '${exec_prefix}/'`}"
 
 fi
 
diff -r 32034d1914a6 -r fa21f847fc66 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/m4/default_lib.m4	Fri Jun 08 22:03:58 2012 +0200
@@ -9,6 +9,6 @@ AC_DEFUN([AX_DEFAULT_LIB],
         LIB_PATH="lib"
     ])
 ], [
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length '${exec_prefix}/'`}"
 ])
 AC_SUBST(LIB_PATH)])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 20:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 20: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 1Sd5kU-0007lV-VO; Fri, 08 Jun 2012 20:25:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Sd5kT-0007lQ-HV
	for xen-devel@lists.xensource.com; Fri, 08 Jun 2012 20:25:33 +0000
Received: from [193.109.254.147:56071] by server-10.bemta-14.messagelabs.com
	id A0/77-25709-CBF52DF4; Fri, 08 Jun 2012 20:25:32 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339187131!8862941!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5255 invoked from network); 8 Jun 2012 20:25:32 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Jun 2012 20:25:32 -0000
Received: from mail147-va3-R.bigfish.com (10.7.14.246) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 20:24:39 +0000
Received: from mail147-va3 (localhost [127.0.0.1])	by
	mail147-va3-R.bigfish.com (Postfix) with ESMTP id 3DEBA1E03DD;
	Fri,  8 Jun 2012 20:24:39 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail147-va3 (localhost.localdomain [127.0.0.1]) by mail147-va3
	(MessageSwitch) id 133918707776324_30896;
	Fri,  8 Jun 2012 20:24:37 +0000 (UTC)
Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.243])	by
	mail147-va3.bigfish.com (Postfix) with ESMTP id 04CAF2C00A6;
	Fri,  8 Jun 2012 20:24:37 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Jun 2012 20:24:34 +0000
X-WSS-ID: 0M5BFEC-01-06K-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 235D31028171;	Fri,  8 Jun 2012 15:25:24 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Jun 2012 15:25:46 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 8 Jun 2012 15:25:25 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 8 Jun 2012
	16:23:43 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id ACB4049C20C; Fri,  8 Jun 2012
	21:23:42 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 9BC332D202B; Fri,
	8 Jun 2012 22:23:42 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: fa21f847fc66619fad38923cd87d6ba51d731eba
Message-ID: <fa21f847fc66619fad38.1339187014@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Fri, 8 Jun 2012 22:23:34 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <roger.pau@entel.upc.edu>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] tools,
 configure: Fix LIB_PATH computation in configure scripts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339185838 -7200
# Node ID fa21f847fc66619fad38923cd87d6ba51d731eba
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools, configure: Fix LIB_PATH computation in configure scripts

tool's configure script sets LIB_PATH by chopping off ${exec_prefix}
from $libdir and it does so by computing length of ${exec_prefix} value.
However, $libdir's value is a literal '${exec_prefix}/lib' string
(i.e. $exec_prefix is not substituted) and therefore LIB_PATH may be
computed incorrectly, most likely as "c_prefix}/lib64" assuming that
exec_prefix is NONE.

Instead, we should start at offset `expr length '${exec_prefix}/'
(which is 15).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r fa21f847fc66 tools/configure
--- a/tools/configure	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/configure	Fri Jun 08 22:03:58 2012 +0200
@@ -6062,7 +6062,7 @@ fi
 
 else
 
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length '${exec_prefix}/'`}"
 
 fi
 
diff -r 32034d1914a6 -r fa21f847fc66 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/m4/default_lib.m4	Fri Jun 08 22:03:58 2012 +0200
@@ -9,6 +9,6 @@ AC_DEFUN([AX_DEFAULT_LIB],
         LIB_PATH="lib"
     ])
 ], [
-    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
+    LIB_PATH="${libdir:`expr length '${exec_prefix}/'`}"
 ])
 AC_SUBST(LIB_PATH)])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 08 21:12:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 21:12: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 1Sd6TL-0008Ki-Kf; Fri, 08 Jun 2012 21:11:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1Sd6TK-0008Kd-6M
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 21:11:54 +0000
Received: from [85.158.138.51:12279] by server-11.bemta-3.messagelabs.com id
	45/B9-28329-99A62DF4; Fri, 08 Jun 2012 21:11:53 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339189910!27493291!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16101 invoked from network); 8 Jun 2012 21:11:51 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 21:11:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id 71145CF
	for <xen-devel@lists.xen.org>; Sat,  9 Jun 2012 01:11:49 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id 2CoWoIbI10so for <xen-devel@lists.xen.org>;
	Sat,  9 Jun 2012 01:11:49 +0400 (MSK)
Received: from fixxxer-pc.fixxxerhome.local (unknown [85.159.41.68])
	(Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id CB44C1C
	for <xen-devel@lists.xen.org>; Sat,  9 Jun 2012 01:11:48 +0400 (MSK)
Message-ID: <4FD26A93.9070002@elserv.ru>
Date: Sat, 09 Jun 2012 01:11:47 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
	<4FD1D1A6.4090900@elserv.ru>
	<4FD202720200007800088BFB@nat28.tlf.novell.com>
In-Reply-To: <4FD202720200007800088BFB@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------000806010101050806020801"
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------000806010101050806020801
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

08.06.2012 15:47, Jan Beulich пишет:
>>>> On 08.06.12 at 12:19, Alex Moskalenko<mav@elserv.ru>  wrote:
>> 08.06.2012 11:43, Jan Beulich пишет:
>>>>>> On 07.06.12 at 11:29, Alex Moskalenko<mav@elserv.ru>   wrote:
>>>> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on
>>>> IBM eServer x3400. Without noacpi command line option dom0 kernel
>>>> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
>>>> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor
>>>> all kernels run without any problems.
>>> This is an issue that was reported and discussed previously.
>>> Fundamentally, it is a firmware problem from my pov: ACPI has
>>> _nothing_ to do with the MMIO space used for the IO-APICs of
>>> the system once they are under control of the OS. It shouldn't
>>> even be reading from them (which iirc was the case in earlier
>>> reports), but in your case it looks like it's even writing them. I
>>> had been considering to allow Dom0 read access to those pages,
>>> but obviously this wouldn't help in your case.
>>>
>>> Could you extract and supply the ACPI tables of that system, so
>>> we can make an attempt at checking whether there is some reason
>>> for the firmware writing to the IO-APIC that we didn't think of so
>>> far?
>> Please see attached archive. Tables are grabbed with acpidump -b under
>> Xen 4.1.2 and patched kernel 2.6.32.
> _SB.PCI0._CRS has
>
>                  Store (0x2E, IDX)
>                  And (0xFFFEFFFF, WND, WND)
>
> with
>
>      OperationRegion (Z00D, SystemMemory, 0xFEC80000, 0x0100)
>      Field (Z00D, DWordAcc, Lock, Preserve)
>      {
>          IDX,    32,
>                  Offset (0x10),
>          WND,    32
>      }
>
> so what the BIOS tries to do is unmask pin 15 of the second
> IO-APIC. To me this makes no sense at all (and is definitely
> impossible to be sync-ed properly with any OSes accesses to
> the IO-APIC registers), but could you nevertheless boot a
> native kernel with "apic=debug" and post the full set of boot
> messages (the dumps of the IO-APICs being what I'm really
> after). Alternatively, "apic_verbosity=debug" passed to Xen
> or sending the 'z' debug key would produce similar information.

Thank you for our answer, Jan!

I attached full dmesg output of kernel 3.3.8.

Also I removed the 'Store' and 'And' statements from DSDT and compiled 
it. When altered DSDT is loaded with grub, kernel 3.3.8 boots 
successfully (good!). But with hypervisor boot process hangs at loading 
aacraid module (last message is about setting up IRQ). Aacraid module 
loads without any problem on bare hardware. Kernel 2.6.32 boots 
successfully and loads all modules. I think this issue is not related to 
patched DSDT, but I'm not sure.

--
WBR, Alex Moskalenko


--------------000806010101050806020801
Content-Type: application/x-bzip;
 name="dmesg.apic_debug.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="dmesg.apic_debug.bz2"

QlpoOTFBWSZTWcklPi8AXlR/gH/0SAJ8/////////r////RgUH54sffeauHVeUdqVredN7He
9UGTp0dt9gy8xvYHoCnvZ6AHQJzHPvnwO8vrr7ve86lCxrZ8+2j0wfb728wHTnrpvtp8J73b
zw4+rZ9re4wHe7dj03X3fPeNsc12twHbuaAuwB8cwdBmxoc9wbsa7uz6LU9szVanO11WsitW
mp3098oADoH3HvnLtstS2q7mmLdtK9jhDqvs31qzbdXud6w3LVdndyrqO4wOmmnbBy0VXW6W
p3d9nnY09ui7NBJIJoBMjQAIGjRGmCBoCptTbRTyQA9TRp6jIZBpoAhEhEyaJ6mTaT1TRpoN
NNGgAAAAAAAGmmSaIiaaTDUob1RoGyjBMg0aA0Gg0AaaNAyDQSaUIQImIRpiGQo9TanqPUYT
aRoaGmgAAAAARJETI1MTCNIAmEJ6TampvQao9T1PIynpqPUyeU0NBhA0EiIIBAmQE0xBA1MD
VHoU9qnqbyo/VP0p+ppAGmQ0DRvCB+EkBITwkQpKGvYWSFIBxVUQIMASRVWQEGrCUA2UQSNA
HzMwPuZnEAoBtC0HZISZiAgLAwElRhlWFg4EVLCySCwhIsJFcElhCWMFAMDIQRIloCFNDCAQ
T9n8Leo/H/Un+TX7re3+OOP7/izK1Yc+V+GPL9OPFIn/zmeHl3u8PXVigAMw6TltzVv0f64P
r9mXZ+501MlofVIv3+2rCNv6b6bbDJu/jljf6ttlDMO0U72flT3M/oywMrfrSW9E+OVk0Grd
Dl6JStG16nbbufNPbNg+1J5Rm/+r/k38ZDpU02FVUzskmAFc72jby6qV+esT7uqZvGJYk1Oh
mW9N3reb1/kBPs35+3u93hK7OCkx9Rz/jRn1IjB7MEhIQkSSXElq+WVVVuPR8rmHVJ8fpu26
/bgMYxbcBhCoc2ZtKkrLaVlbizCHw9bGRkHX0g73vVI88OHLnafp2pvv5kbYNAZuXDQlKREI
VVVVFRVVFFV544yTKSAywkBukKM5OltdrVzLxNsJ58oK/9TD/F+XlrON/0BlVjTW92T1Sjlx
+nO1vPhd29VXp/b2uoTpp4bK991FiuwXwdUT2LSxIbQ2Ozbzynxa/7Py9vX7rZWsydfeQgq4
uhB5eQATcj8ePHjpx00z0UUUUUTxwJ6NXKxwg7f0TcBp45rjEBuN8tdb7YQxPpt3ZPxsfUnX
UNVP7i3Kx/bN04aHVl2usthGNTGquonnGx09BZRFLk6CqSKRbCeCPJxuu/OQr0R0gHS/mNP2
UGXdH+Qsgvf8deFqC6EdM00yCi6Mz8UxMgwqIeOI6gBgVQjb2qF8uz0dIeV+2PDPGfBdv9Lb
KU7avCh0r+Z2Ruj+WmqvVGMHO3W/+/nSjM4wZwISEjDj4eHQHVofhkoiimxF3AkgEIBIwQCQ
YH8hEVKRe2WCKEULCokisUmTJgAS86RZ+0rB4HoQYu1tpUfkbjefp/zMSbhlRki74rGAppnO
O/8/mxDDioy2dId6C0okOuDxOxFy/oCkALk4lK0wQ/QDUQEwBcFbJcgDCMBgGN6LAtep8WBs
uMeAOw1Nrc4FUQFUhG0xBI4hO1rXm5RTcGFYDH6wxfP0T4cERPgauy6D3RbjPQkKbO6fLbjt
9XLmB/Q7Bx+sX9+e7DDrbbbbbbb18Nt32soQVvzd+p22NF0j02VmkOyaq2HeznMNsoNNX9Tv
gdZ3/a8DZNPRQ+nPxyOYunbryh4kPW/x+JXGux48ZWg8cw9y+8hR+dLUW9+/kHrl93lz4d/L
9uFi1rW6XuGxGORkZGWWRST0z0FBRRRRCiec+Hw3nIcN82KTOpLS220tJbMmQAD3fKu7yB5/
xpLIfmQBqtVA/v1DccKKAf/dVBmdCqX1QvvgkvFC7aNq1tu06dMNcdc002vXr2bt2fHbbbbb
tttfmWod3cIO/qP4ykv9AIP6WgPJiHbjLG4dRa1FrUWtVBUhPyCSbRkjGQGMwhX0KsgxVZBK
NVZBirFIUx0CUjyoDbkB/CvobNUU2ap+lt+b6rff2Nj79LGKiKiKiKnHPEwjGIpyT0+F+me+
593ifJzyafbYfeJD1MgKqqqqttttJGTRdqOfxDE37zlB4WJzp6TBQpMw60DQSF3VCvFek8g1
/GY9OcIOaQWwTIYcjx9AiLD8BChGblRpPx8cHFpbS8YwYtLjGDG5ZDbuDYvnDUkiStIkJrDl
AohA/Gm2adEPBUMYpdvtHBBIfo+2yKHTGjQfuMJKZi0/dnfLs1bRTIYikgdUDMxL67i8Yt+n
liOzxopSSOTAsAewlNHVgU8pHnq+w89beq01hD22K7uRUBa1ZmbrZkCLZpPLKxK6YwVOy02e
askSJpusmIngBNNiMs9qoooJTt1AUE8g8NE5hgW8Q5QZisWsUZ9kwahEGh3U9/x7PaaXFYX9
+/Uk2XRnSvpz3SCE6r3AT/iTS9Vrx5s+2GfR4zeVe/ZVoAmPUw/ZteaEdESVud+I1O0O3XGq
Ud7CtL40YmJYx1usFFPz0v9aMEo3zhzzHTCM7VNrmdk9Kv0Qv1KlhmMDMZarbTKBTDB0aE4d
/Nsb9bY777YAXs7psYC95fCNxLHngtJS41fe6bFsAdbaW8MUZ1hjdgAzbMPPVKE3wPpPqiyJ
LVbK3TnYkPUHP40OZzOfLPIDXHKfJuzMzL5UMuPcHFLfKr16dPHstiyTURKkmlyjTQBUPAzp
UOH9zCKG6effv0d/v8Of5dPDIGHDGMxtS0+o5edv2cztQq+ZO1DwT/CCSAb2fHsJKfaC/h7y
HUHSkmZIgH1w7PzG07sk3PZzA9rCMNZB+41iKZC62SNdn4TXApWyTuDN0P3tA97F9AUUTbzR
xuhv9TudBWGfpPw2p8Fbidjog9vIHGQFrjJtGGQQUcNdCQU8BA4rgZH3yloYnK1/EgrkJGaI
23uqCHIhmvmbwLJBWc2t9CwHF72YHK4sR88UffEDhIy5PDt7+jv4d/Nx77b/KnfbRMZFlxna
8L9BThzxBz+VE5Dg4+C02RgNqEfap+INtst7B2ogIOGjiSBdEUlo00E9ZRnaHePpubOBqRd0
97Lr+jerBH2HVbsyNIJIA+BTUji3QqIUd7tRLB9aQW1vBy/fYAyxWQPHovAk9HU5y2U55HRH
NZug7fTMV6subMGZJBJSCCh9kfF3QDzVPPrxPx8vh8ZrLu1mIio9BjNWte9QP5u1bT7fEhHF
FBBAn+Qc4uta7UEhd02cMCeSOkTl7/Lw+IZWd5JQEAjj7BYpNE9S2O19puW+weBKL50eyFvk
FyZ+wr8ZCj3+yEDQdSJs/kRVSMQN9K9vNI57uVwWW/FmVhfKTxr9Kthzf2caBvTolxQPJpCm
+puJJ86ezCqK8xrPn1aW0y8Ehw5z5dXeTQ6dZ1oM0CIHmyKXu/YJWAyByOLGDRYBmxyHP4e0
ftbN4zC7aTKh+6mcSL2ALtuYB8K3JSPbd/MIUHefTrIul/aRICHP7CJAGL6JaXvttuCS6+ku
COPqLhx9ZcOPoLgOC/Vi65F0/oW7W3Ypm0qNpbMuDFCltLjGBQT3Dn4hhGDAifsUgo6wdLk1
baRaqbaK38vWMUEBMD9md9VvIWoX6ZnakAZMt5at+8gVY7mzSEY0bYFkcbS42FpTOS77aeaC
AmGTScafr9081WyfJzhdpXH4eILf+N6/s8Hy3fZjkvedlrXPYIWR620htttsbEZiesnyeNXd
h6/KnFLLobO0wT0PLrnS1WokJPP34nMTjBk8+L/kia6yWznAquEG9CYX47LrcxE2Wvddycd1
tRPUgC6sMtPv1fLD+lVVSTqil0MZmMdXHPRLEA/3vx6/VfaKOh9B1OpjDu0cyD2shZjGCvUk
WYZIYHN5c/lV0heissc+l0MrsOvpbEK/UtNFjbetwvY2/pdZbcpP96DjACc9SHRt6rXQqYCo
IXHjGgZBJIXI4JCb1b3W1Vb1S+f5p/i/WHFaGs2x9/45/PDl4cOHDx86NGrxooozMzMzMzMz
MzMzMzMzPd9fyfR7p/Q/4+qUH0yf1kHu+lkAp9nCPYEHtQCOC7jXy9wKszZ9x1d8S8ZIlz4Q
XrYxGJ1k4GyzFgli8r6J1gwjxRIcjSdQgv/VoCQtDvr4ftJ8tktTTmOnZkcuZ9x3MTzOJkFO
5EkRwZv3BZgicoY7BybP1MJ6RFhJYz/y28J6U9FnHyoutKgldug7e4RSBLLTCaegu4CeBjsd
cz6zweunOVC9b7ArwNff4ff+6NbaaEsgFOTQxVkmx23rdfZZakmzMTeh270X/TJj0rxveUNv
yebHohP15XY0WxQ5hkMcmf72vyzJLTj/B7Pyn/B6/wszN9v8OZmZmZmZmZmZnq94I2H9uOIQ
khk7TiUA3ajPl84slLNT0oY1fSqx5zLd09EV5cunbtdo2PftyZ+YquyHZk0PSQkR1DhCOdkt
7Bt+tSiMwzFDHv2+XyAVVUVVUDbx9/v25cUgQ7hPGSXFx/p+vbn17+wNqZ+iNOzeu9+o/Rx5
Mo4ZMQQwhrkm8aVd/VdN451u2AeOUmXwaZ2QyyPaWIQd2QXfk7eX8fq/soFn4onmz9OfUcKE
fHO7zasr5kh2yCQEEqOubVu2qSw5GfVx70BeIeTLoTeocEYFRFnv+TstJOwdEPFg04Y4gcIx
BXZewp8qChrM1KWZttFUCHi09CVTtjzDpgg8rAN2uDfl/AEfKnKXOxAsoijQOwLu3PLEyIqc
Pu6Ht7QPLRNhW2XpAdAQntQqAcSOVjZHLkhVZyRSVBlC86Amnrwx5fZ4+yakBVJJkK6vsr5V
nmiMlKcMAegPb6lHj165KnkrLDbWkkXDqvqgUBPG1TaMlC1UTFLlPsnNTY6/cNR8P2UkLHRb
IMb/u9kSXqp6C9Ln0qzKIF58u480zJmTQmR4aWyL580jyx+kLnfWyizb8PozDsOPIfpXvwho
b7AjxHJMwzMzMzMMj1jFqN3Gd1kcIuSOoYDYx5MIEzCYfgJ4JLtZIKgGBKp3T83oe2/sbHl3
RAcl3Rp0nLoxyK7mOnQfd7OB5yS896n6nOgcsBQVRVVV5WRXgw7zmf5W6SJW4q7pKhoCmvoo
5OycIA7fcd25kVtP7vCjYzTkg13xw25dJkE5jLvKKdnK+yj06zTfKoxctfxCm5TT49ddmLLX
5a8WP0SSXx/Xlm5ujmoBZElniwOymVDGYFQJ0EoMgfk9uMMBscpkDI0U8KtWixAXUE+ZxbFC
nOvHImldJS46OeDmN4288D2hzoQbWQ4BgsfpP8PQxzhrJjX0DY8BnRhNAhCEOEFuKTmBhkvG
KQFB35/P7dZznHHW9dtts20sQU4JaQzbJD5Q9kD72LB2qkLbAUFgZJMBgkgX62PujVHzZGxb
bAgVB8RhPrN9buIbhxENuIg+Y6y3EwzJx98UoZIg/AZlkQe9mptBoPi/YAI/FciDMu5sRz9q
PL0Gn6qdIRmw+hHlA0OUYmxPxFPOB1XApzL99S4wKU/jQ8ndT1+bNrA5zwjp3HxQlkrXuf5E
Gkw93A8vG4Iw4ayqKqmc3s6YRRArBlXGKh7IABf3cNtywA8vVQvKHVp39O/byRoq+FXb3FFK
M6CmLaC3gC3RaoUllNcQqAMjvIHnMoMChQYoVQBkVAdGaFk/UooEBxYgesWPujBoXl3d3dDC
nFQKKKaOZbS75q13reDCAjMqIApCShRSFIjbva7yViM59YS4OId6KXfXYyXUGzoRGJyYN6Ym
MWSVDCMS1Ttthsp0R0bwRFkZOfMzgLkshzNXpkNsQMczjFqiCimbjkayBtd+V5hmE3DVhVAy
gQlZUMJA4OVsrYAGpqkIRZAI8u3IwZk5kSS83p0hctZoaC4mDAHJ55znLuGNrxVWsRLAUahm
KVUXGCVBVqIM6T0nvB6D+aQyvZ7FE9NUIe/yuls6dH0oXyGKHCdv6FmjZMOxDyd8+w6exIQ8
/b4kd0GS8byMOVitmyNJEyMY+L3Q/Z3wxMlREe/PZyK6iG7q8tlsH6ey9YzrZJeuIMcq4UVS
W49TCSSAFnq/dJjlDcxz28b6wMOVsi+WyJSAexEGAngIClAExCTu3p5mA99A2S/upR2Sxc33
em4yWM+ywPJE+QQgphhOwwo0b+W4Ny+y5hgokel5uWA3rzKxylkk7T0rwPGZwO/Ah7ic49wA
+nqxztf/k9M4F25YyAQJf4JwwSsvHYyqArzx49vLn5k4so2TfbKbtl0ToAtTF7Bc9bkkAFLI
RBAGEkgwpGUBSEpQiKMZI5sggWDCgEQ8J6VIfqwPPlXigflhrggKOzyxeKdLnLpNyLvM+FYp
EWBl23sLtmA1XpcHW+vr7M6iseO8WQBrQBcDUgbBF2LMVo3yjgqLtg2VERrLuriu8wTgYPex
0vctZs3G7dj0234QKBQKIi5cRQKrVQSMzypJhfOtd1gta1YmEyLFClVY5XmkL6AsLTjjRKq3
B7vD4PqxHbJ6Qig/dAU+A/iUgo96AaHI37nfKklQOGOHO+V0XWpDnFJkcDjn2NZB2hkI7DWv
KEWMrQWnKcB0HdeAkJGB/hoYPLfjQkikUJnsbK04WBhAQLADcz+1808678yh+LkJ0lTuC+FA
Bb34MQvlF74umcoo0dKUyVKaVCTOufkw1XMRTtKvYMDC/HsXVnrMkaWCyCxAigs7mzkTmo4B
DcztMa5LXYpyScjG7tm1vPUwGIuVqi1tJqAVwY5OerRw5LhMLscu81NZ1KMlaNO3LY2JDjW8
DcjMIKTAcs+zRV2epkx2lVko02hye47qoQWSHUkEgwIIJEGIMQEQgJEIkUR2FSTprrqyvCwG
/qx2XQwE3sxImGKWkhNoBsb3LhnvvfKlLpeweebuU+xotMsstyXEjhwULcrKM3bdDc7qLhtS
u5xaLG0Qhw8KAckBpVe2i0gG1aGhEm/QdpZCATmeiVbq5oDZ7UcI0EDwUH6L9ILcKsKveukR
Bw3HIZ02J1A0YgCGxDBbAdUoQkTBIjhSpuogRLEh5DHSM9xL0rpo6l1ZvctminPqoShA4Aol
PMKKGteHUuVCqzPyIVV85aeiYUQ9i1LDK4b9EB7AKm5h0GI1YsnqOY4xOtiDrtD2w4tC24yW
6GsrcJUwwApHKka8iTkDLuHpWZYzDmEIu+NqIKYYBON5vGYCOLOIWnjw7K78Yz46DXjO9pVN
B0DGY+Yda5cDkBUcIhZPhFo4FXWSYgpGaernVb8q4RpRu5AfanvyArUDEikiVRf+NZ2zzlRr
yyuoTK787X3PUwEAYAw8HsR5cixRqGPonlopzYB7OjhJllt1LLwFtbLK7SO1xbaGsnQGDqJO
gqr4XNCFpOiUUFF4PTA7jsii4PVq6BtnGSCAoLU7NqiTSIAFCkxUy56HqA8d3zxp31su9doO
zJEr2vWi9lGIDFdKO5Gmc7BGSewK1XWsq52r6HLaAjugC+0T6qId3KOgXpJyBgTP5HH3UyeC
C8ukT+DS+DAVdmtRQziEiUgaAjLHSuCLQaWIliAlC/HazwLqK6kB6C0I+og2Coor7KZkQmAC
RJMNM6D1gSm8K9yolZa9l+6e/i549Nb3+SLmMvSTHvLWzzu8vybgfiuiOanIxt8eZuCAGcaq
JsQVDRSrKxDZjrcu13f3UnUSNAqosv0HICIR5+4ptgnoQPkImdMuWYMhZpkNAwNMFlTv+Qog
OA6FwRAhgGKAkTQ+fS3zeFx2s54G8BPsQ4fqYFSIkggyJGRVVVIkSJEiRVVUEVVVVVUirFTv
lqqqqq0lq2W2UpZSlltlKUpSKyHw0oiKqrFVVcAX7EwryQ0kMJwkUIWAkWMQYjX97ZsYwWgj
GMYxhPwGlqCQIEVVUggqqggggqCQVIMEGCQZwqFEREQQH0d/D5XGvuGDbyd+PVP5vLKOzrfj
50OWrbpENs63X5LJIOxDBiQMKCp9+fIfA4cL0QYfdwF8WitXvtLhEEi50AjYeY8SdZk17aJs
GqdLv6vONQS1FqSg2lxU4IuZMM1pw6aRh/afHCXiWHTygqhg0Yx28EYVuQn3kRDzypkxSsaV
V7vbhc9u6jTZM/F6DCz3/kr+kiYttdzxZemSkBsAfL7LfcVfGU/ee4+Lp/pBlGvUmesG/EMf
mt1aXcUjvtB/AVu7xUHKoTJk/N85OCLK4ypoEZzru6ZOe+Ui3dPQtjJYhtlbhpODNipjiJJB
UyHPCRZCR5UOvlXMHAu+awDSBOUC7I+Gud+PEoWZ9++FZcagacI2bglw4KboWEhuGgunhF1L
ja98KqqMc1MLnTndfePCLN8SfFe4a2zSKfXhfbylYZbyOTxOGMTpm7TxpjO4wW/GOPGUlUvn
MQjei+W1ZrmyC4YlDTDBzAkRL1v37Y7ZQATy160HAIAcdJ3KqPOA9gUEQDB08zbjsK/hsGda
ZOiH7TgGQCBuXRz6mAfyuF5Hjoh6lQ9d+BO4oQoGCiEzx4ZB7eLaqDzltHj75ftaHdeTWdeN
+i+alYnUx6hHlicsfa89ZpnO58gzlQLgAeHgwWt+WGugRumMcAXLlvwW+IN+9EGx/6JjXUke
lHLFbArLNuGG+uK/dBCMD7GDaf0SilKMbJ/awLsRLMFphpKV4C2btCZmUPR9XDpy3dezv8u3
NY7ZfTHO7TupAvasORTnUgXNJS1W5TvGbacc1LMsCHlWlmqjUzI7cxSu25+xIuNSte4A6js3
GdHEHkVchZbOR7xgXFIMBLmRShHQhhCHYqBuSWaGDVYfl2eR6qNki1nj/Cl7/m6s1xlZnHYM
oNCTHs08JEnUzxnrenJZ7Bz/TYO07dMLJFl7sI4WoEHnvn6PfCkt+ljGvARZaEnFbmQlZM1+
VWEUpWkN3hHYDRLA/ajoWOWWV25pBASLHTd4+4yulfDtptuS0KWIHaFBEAukQ/otFmYbn1pI
rcZFYkqyFtQn0mCM6/TaDYFAGNeLz50pibG7D8z48HoG24kgbvBkqJxqj0AvJGDJL7WOOuPe
qAkZAdgAmb7a+88td+5qcAddn1PmgOyiCCOF/ivklYWmEUkbDqcnyrwYTpKVASQ/FV5oYcnJ
Kk0nSKIYYqwk5l72jhOhgozhmFwvrhSACnAOWEPfnyInLnu/TzxLH2gTwQUwMOdsFnZnZPAI
ztnpjwTkzh5AyW2pYt1hzhThbISxog/QzOAZEJqxq1k0Vx2Fz11x3Gs4gxXI2ost1cwPbNHZ
dvRu6gSj2m9t0URgNXN8lUlgGhxFD5vUyajWaAjFlXfNzSPXwW17S/eO/f5iSfQWKqgwEAIB
JCqYhQTqcJBmP5+cHA/nc1ocYrw4buBWlONbpBOEK14rDqcvupFPWGzl1Zug/og1oXby9Kc6
udsszQpmdsdoVrqCmG7FTXgarAfgDr2BQj0ZW+R39/iPRhGE1lEMvGmeMhjnH0p5Py6R4+RF
7dISoSeuLrN98SOYjvxFBXpyvS8QZvi1luRHhZFCTBiNvpW6fbSPIuGv30VGchogFYD+7fPf
3nBXZmQKtBGZRc99pMOEUr43t44V6QFMCzvjeXl4GkHn0DHbtfRvG3BccXqFel7PcW9fT7Ne
bAjxnprtu56gsA6OHUD5vHdcg5Hg+PT4jwIRLIq+n7QEsUSF4XaZhHLK6r31DI8b0JOoIuY7
28EzDO4CFzqp63I+1znybTcsi3vOPRo7Ksiy7BEEdx5GjQu4bsTbGep64o4E0QAlqFAAogKd
s7hwHI8HklVILzuFVW1siZoXtQDSo5CzpkHId4RhDK0bJ4z4vQquaDaHAVNbGg+9gzIDqwUq
TKiXgqiaDEmIgUWW9a3682IiCN2ojYgQmKgoqg8IdevXAuze3GN0MW6p27rp9c6SI8hyEoqQ
EJ6wIOAGR+JNuJ/M2IoYQVcBDzloTxxypLm+b4WICIi1zU4bya7HN2nLjKqoNvDXUqKp2fMy
8D1MTVwtUHM3n5vsjR2SVtjVdJGD+dIIKzDaHSYPDflZUMIE7aYBGIIdsose8oJefG1d/SJC
jIfvd54P3+wjEdXswMUEe3HfYrZwfhBvsqQdZSmuWMh4VylQ/b3cOgVI2JxXdv08hWTCcTXU
DigS2qaTHbyk838d2U8i7kuFXiGBqdhCTxBioT1r2+JBs0aDBDHd2GLsakxpENvua6UKRKMC
RkdKlDG1Uprgk2C1FzLfICUW47qX3rv2H46SBybLp0U11vqKtiwgWySZjqptWNkxJF0IvE3S
N7nfqd2lFQRBWFB5CwRt2iaWNgKPECGUBSCYa2c8UgDeItiDaK1FqqC2JM8jI6r2zPfLaBY3
UDdOa0bWrIQOIuwmYNCZ3QZaVkqTAUYDWw4GaQohhDiD2cKbWmMZxvv376u+dubjGFkMIFUQ
UkNsamcwAUmcusINS3KwwhpPBR11SswKuRBalzUKXI4a2biDJbURb1TjZX6FjJNspfGDXPJX
UKIREctBlpu1tC1CyGQkClWFWydMA4eYThAYB1g6OaUwvCFNEbF7t7d/mz0892B2eEeAUYOp
VXLVvfTCoJ3dcBt1db9n1RfWOMI729xAgDv1QhdhHuNoXbKCAJ471w4pHEo4xPknS3OTa2Kq
LWRJYtYg5DwpZhVUHYLkNiBBGTQmCLmIipBqpkm6EmC9StpNmpREH21AVUGDH1HojJvi81n1
h7b5d2gBhYVfoL/D2LZkwVUD2REtYcNtqVfp7JDqBMMUVIOscg+2iZXks7TP481Ra3NxiU2w
3yWROUwtKEFKQRKIqojo2aXFMggY550y2fl9VovA4AKS5z3kbkCpe7AibUnPdfV4KtyC6SHS
m1bzZJFWVbZmmQM5oWJNJAqRYE2YG2d9BeRo1hd9ilS4TNaw9UrhoQEbqb3CnWKsxPtSG5Z1
IcYWwWGLUUFig4oVBQVXHGC8YFsaqwKC6GFKSKzRFaVUiQTNVLHENTsC8vDcc3LyZ5yA1AxI
zHDq7NFxo3Uki60+9CRd3QiKCINq43EXbMVVULAyWfdD6i13sVhulGyxqFLrWshg2OFccwWw
WwTZtqaJm3EgqGuJnUOzepIPvBUUE7ICAL2OwG51dv28dcbtt9X3aVLiqmaEF3zHRIWSLoQk
TmSaZZWmDzk2tyq3LDMiFfJxnyoMysrExdTBtpefn9+52s7GwFKAfpllT1ooQfCOCzn2Q7d+
xeRjxvsvHj4yjZI8OgHskD5nKlZvm4Q8ONHjddHmnZvGZ9eEGRdpXf8vl0q6danWRHhRVAqD
oV07slcM6rnjbB6Uy6EC8tQiyYMXgMTDHazEIvgiPnULSgu7MPPNsJgDCASt5MQkFErHZlI0
Q6NpRqlaMciVGgJFggVTeQIezm8Xd/ZaaPCNi9KmWLcZQ8kHa1D3JydfXJ93Dg1jru3g6dkH
oq/Q6nrbW/n5FscjbsfON9XpEQem98eq5zl2EpC7zI28QKVuFXZWehd0IgwRkBj28hVzH61l
jpsRQy0TrmKo3zk8DCq2XcIBZosaGldsyINMXgRMry2TUBcy8dzmwA0UEYoDp4eTqxbseAlJ
7B4g7GUiAC/WOeNx03iIttqYDKaztXl2ECphZEvDA5du8uReJRvIUK8SMFrhm6DBZIHbVNNi
1IT3oPWjo+pb3tsnw6cYS4J+HQi5aKi75mR4wuW/Xlar49/KmTaPNIQjCQsAZ+nNb12sbkBE
QVMRHficLrfdNSy72thtaBNlEJFrHr8s1MKDpXXS3y2ZCWGEaba5sahQ+s3uWwbvT6F3DPlW
UEKYIGHSIM1ToiK0ErAyqy1q1CIiJqw72zHGxWXeMZOm9162dVnGXKUZMF9lrlxzmQN6V6za
X00AliVO2pV2uLJfcqaMUUY466kYWFFMNciAASiPfrEbbImHpm7kckPtjNy99h/cFCoQm/aJ
933hnj5Bg6+by3A8NtfRvV5+kbuHak2p6Dqy5Z1byZGpdVt4haoU73UiZcyaDLOUuLmTMZU0
KvLpaDXEQ+MsPeHX1W1SF0/kdTjaZvb19jy6IgcVCqWUVKIds1EhpVvbCmyq4Kyjq3ZSyorl
uzD2IsfWNkRrH5sITzte5I3sBv0mOqBWySkziGLZqyzszaetIW0C3YCBW13NbPqpxExMzJsk
wppkeFMSnZlohnAzgh6MS6+dxBaxurPCtXTlN8Yw07USqVMiq9aQG1Jxq3k71ZBhnOZTVZWq
/0IMzBpfMDW9kpS+h+6Dxgc132W0Ce9bbXG+RD4RFASr66OAdcG/5BFObntQINh8Ymlfkwpf
TopRsgFHkdqkPQudQFnRTOgOmxw4HACPVa6gasLBZHBeFh9KtupNNVYVmYa72rMBFBqZVySB
YpUYq9/QHwIPr2WDInYsb4uldVfTSyyQEAVSonxzjV8DpZB1OzZUyxW8qhrYokNy6xGw6HdA
eCJM4yOwsP5WUG+DkKYAcU9OusTYIFl0RB323J825Y3mjyAY66l7R/eGCkfZRQ3FHcHe9+F4
6vXOlWkEzNijUhqyJkPRWmZVXLElBkiqilMvbiMhEyYp5Kifnz0sazGC1YI8IEKlUAKDQI/L
OxtOYq6DV+RzuJkeevQ/A+2qu/eX167dR6bbrULNjAXr9NqY6lpL37UthoKdIdsOvQIOv17v
PPbjBDFRo40gCGBg9LWyttGveLLHB1SRjhUSxtIYpYLeEed7AbXobFxsIUZc2EYokHGLm2fd
Co3No5gjA5K+AQFhY3mhtyz5q7wUy8kY0hiUBUoxBgqiOJh31moGcM6fe10MNscAEPY2RLa2
ML7mQ+CButABtWwFxCrWKxEUqKGKk0wWNssUHdiZtAsGIxLZSI+oiHkjnTEtwng/F3LRxdPd
99W8g8x0dmZ0EZJMLyVIs6G12NaWiFBVYKKXxYfW6OM7AaAS/ltY9/1vyLbN7hmx47ju1AiX
ONTzUUWc1MPYllyVdlAa7Sbmhk5U1EK91Ey2L6RFSt1EVTL4/sCq2yKJxsL756lyHA/x5KYJ
3ezR/D3O/Mm/D5QoEaWSYZJHZ7hiCjDbmaaoLfdW52HUC+ncL8PK+H0bdd2vO8+DPO3utRRR
RMW4pa7P5eZtzOXv4nhw+i5qQu7u7L/szlquU7mPesQtoVq1FO/a1Pxyy/+OfVkpNED5EqMT
X7Nqt1isnjjfT67588SK0gP4QkutttinQ90kzbzn+sfWWQfx/kFPhh+tig5YzX7d0lWzYaI5
O+9vdFUBsYIg9GuF+LH6fX9dO1B+cFm7WtQo06UphhW2mvc903BDAyGCsM9NayBTpFmns1Lm
yGX9ueaU9vhi8K8dmTu7i8wMWJSZsU9EinWJdKZ3U9X54rrDxg1VVtPvfzogStjzPlJ0dH5e
jMqqD4fH7mZSzcH5z6/L3yrNsT2gBuI21pSXEMO+Oq9OdIwQYdH0kq2xPDqy76hDNDIgGjS+
khFCYzxxxzwSCzxGMawHiIYI4dYus8dxvzzZCwuPe2LKbcc/JNq6I/PZTMiZpVMDhdphZKCV
RL+/ea59jlJp576UYhoGgYnln0I3UzywnDLKFGUFBnvKa/VnHGxhUcW2ltqreLbioeBPVD24
21t7fNsw8fP8s1Za3urmiSSSSSUQysqzDZqqVfJVamnXPWUWNuazMkrI7ODjNqmPVjxzKjZH
kgkI0ykMwyR8vP6G4MnhbnPwW23WtbWl20IXaBiAlbjGMUtVVUGAgMV0G58/La+/6/bt1UgY
rQoJotmhCCa4glCkEinfCxWDLCBooAdEWO2PX69aRzq41qmGDBIaQttSskq/E2sEgwD2vfIX
0yTjY0QUmUU2QyHMkCngzk71tYBdSRgjASCiZh9fgC2WwGCOmZmYdhEID0oHpvH3NXdHM+ci
w0c9LPKSAXxJkWZMJzaj+MA3H1HHwHVVGykKCb8LDsgfziY4oe9quqYgsze4rPmPKyY9KHGc
p8n1EZz4ACMlQZxTO9vriGrxOHjxKcPsHLF83+z0k5C5C2sCSIA8W4/PryCr8v6BfngvxYNp
IRFpmBrh/jlJWi9cwwW8fdJMQP2lAhb76ULQIRIi3A5qcCX1f4DkvkYyYThknx0Ou+tiB4hL
XJBgWDgAk5m5l6KtkZoE5WMWBUkX2mgt13VSQFo0a0l9gzUUGNCmWCRbJoDWwgvBGTXg0hGY
M2YoZiMZEK8wB8e696X7M9PA1qdTClXhrWecVRkRxh3GUEiAyAOEEnW/hgUGzhQaSwAPS4lz
Z3tZanf3+WOiLdl8sYQl2sCSRHo0i4oIezr7dXWNsrK1wo7oV5epNYhi7aJPKRULpYGASdWc
Bz7IyGHUIanrg40IOjJbDp09VEAvQyLgTE2bBWAj5XTTZfvejaQ5nkaXGO8cfcx198Ljr3z3
SRw050/Jbx/1F7GK8ggla407aC3NLZpHOLIyQYmePHCckFzhNP8NPRucXFy2K7kowy12js8n
pGFxXUURyTHtYeZqOn3hAQZBiaZcwDPF5cX62Seo+VmhA8vgFJJgWJCKwlW3GDDUKJAhoLIZ
T12eg0EsmWGzISkRZIRjJi/9kfuIvumCCnMsarIhvspdj2HIvGBcy1G05oQZJewBkUsjewCL
1vQG6x644nGhQNkfEBAzhz6+E1CZYAvsgga+f6zCbwapBK9XJdI4nnhFgCwVh84VPh3Af7Xf
pmOpToEAPLHzHLY9WhSkzJVXS0c9lAEHTwaAy7PaTPztWf0vuNMnqqRIIxpRHMDJvPL7DBO4
ZN+GfX3seCoQVOqAHfIAnCB5HCsK1fVDbJRLNYEdwERrEkODitGcFOkKAZMUT2AFuAQTw5nW
1ZEJt7sKS12HW42QNkt8YQUoUsHHQfQJ7Z/cTHcoPkI5TCtGI9802APuSYuiU2nWWBr2wIFd
Ifm0EMUhtfiVc8xiUGtU2sBA3RJZgBIKMggwxWKJlA7IsieubzTGwOXqp5qbCvllQDBE/XoW
Rf1QHXJFPtAiEj4AEOgJgvgY8UjsKB2cIMkrS5ccZmvh6exah8CYxPL/XXeeLVX5E7REogiX
kL1mPvyztxUtwJ3RQNZQQCM19plG5G4aCXVafvKySFFW/eDGj8qKNSP3GKN1vEAn8PMpoaNY
qZeKHhqcuWBVe+diZhAQIzgqFrlOl+gWZYEOhnCqkX3ESc5hfIJtIcSlvL3kAK4/axJNlhVI
DDoLn1d7ErePHg6ATzv3FqrC/IUBMgOLYpmt0bHr6gyLhNK6ct7NRCYy5YCzzkVSFHZtTyCP
/Wi1yRSqx6RQMGlQTTzzZ2UJaJyPLiCczX00vzypBP0FqCzFNJ9ebdAUCcpMyIHpQMacnIn5
rE48gmcLOkgpgceo7btPTH1w2BF/aiCIQ/397yZawXgI/MB9hlaex/xv5MNUHP5/s9vPYoMi
qgetT/DH5D8SfdMUwLC/lW0az+V+V/Za+hmnCpu6xtj0ZzgUfyr82v0r9mBZCPqxA+CSSIjh
7y336frSXPrxVVMyoNtU8u3ljSePq8+e55av5t8J3b1fFhWpmtrwNTjN783v89w+dqeLXp5i
j5rlFFRFFFpQgdM9j4+r7ePZytnynJJJxPKaxDqU4xpytl+hbEytpXlguoV5p1oPQmKyFy8y
2zQCOy5by0XWqqtVVaqqo1VVDv4zMlVXOvH6vw+v6vuevPZ6vb35D2g+xq8ufMG0lHKjfMRa
KEkxCJKmauczDoWpWwT2e7xAu8PFN9dAElSgBKIB1QExxXFqHIzqsxgQHmloPsDrphm14V21
uCUcjRndURypsh16imbqg1NI0MrTVONVLMaYQ0OsQsYNPmhqrmZzKJnVTLrqCshmsoiKRBwg
ddddP0tMNgEUhERwCOtvIUhEXyfHE8604Gsap7KhyttF2r999qvJ5XHbfJW6jSmxFtx376Ly
DUxajUVlbVvEpmzJItlLLVa3VVcr415AbpR873kTmtc4Ufq1pQr2Kc3DutFSau4bunJJXINR
GC7JZ5JiTbRBZjDPY0izAs5S2YyxV6jHnLsWQCiLoMMmu2TJFbzYfJUS6jerbFu8paotJFGb
lmZqyQtnGqFKFaNWuPUVUzcNEzbVkq8tNB1rk3bzTUcrK0q07XOOZWqimpWwZgp3WXeCxxYk
W2UwoVCqXeLijS2uZlVYWM50qq7iG27bbbbbbbdVVaznV5ujqhnAxtEAYiNRQeIzUO7vOqGo
yLK3lFZzLhcRpFEObyYZ2yryak0YDty5lJqSGGMus0sqXEWtCDNMoapYhzVLcCcVpUU1bfGn
KsxC6B0wKlFWoK23z4pAtsxImqeK8/P0O8nKe++Lh66MV1C2s7h9WCXG7a8yblcmVtRavLim
q5mcmairrHp2irymhoDq5jLOLgHd4AHhjc9+Z6En1QYrrp0pGvw7NfInbAH8yTj4JH9Eh8x/
M7UfgfM0hEaH8z4dD4WEB4pjY2NjY2NjZ8DD+WKVqN4lf9R7PouVpGn9hBYMc0oxwnrCdu3x
j1YRt+h0DWFEGdZl8rSqYmBznxXmz8AkW4eJjPw2UUwg86FTpeWcuCM0wMCWHu78g6bzcf3P
dQ/OFWToleFTP8SKfenbLd9bkC0isgQIFNDDXu65xt4uQPh7cFDJQ9x3fA4/OAbSpcgDwVSC
pWxoZL+0WIjtLw31TsWLY6Lng9kKCpEPMtl0lD2ur8nZ87s1OcWi5wNQ5TkJSISxZQ0M8b9G
pHBLwHcbfmKkM6Q97aYOtGcAeQGD18JSUDKS0uo3e+ep/xQYKX68sv7mgDQwmAiJa6hVrepv
zLNxdaE82SHppIps4Gthrh4O9RrXNHGshPhzlHPFT5uQdpEc+HFOxEKm81APXQhBcYLLbr2Z
RANMNJX9m6pbnJkIyYabqPJ+DCzWnLEmlGJrj4BJPQSqHLJAV1K9PN5NXweq9e/W8EcDEIMI
JCDDx3pHoE7ghxOMeIXxGROGiKHCZHiwL2jImj1vyWdeRVTOHAqSzNV7DST1/H6np7xOIz7i
IfDOo63LwsO3AToHJVveCrQ5CVD+JK8ZVQc799zBCDkDmQdOHFkRFORxKVrH/jFOJG1CHsP0
4RFeyomI8j31+8t5MUoQTHp7ghyuMbNK/SzMQiBCgBXaNUwDw58q4+0px31QBLqzvZMwLT43
3T9MobdZAoHCRDl5Z2c5K8OezeK6LKZi4h+vmzyEQ0rNNDTabFeq1unhZe0tSauykkIXzzc1
4A1DhGZ9KMcCIiqqIh7jtRruYaD1ZK4xilH5Ji/d76hj8r2/qQP7QAwYzJSz6QBYAp3MltuI
sbYWBWFQlJFTyy/bTeLO+JbRdi8YRDX1wD8Zv6oGsoUPOVTZ3D0BBkJBhAVYIEVsGxooYatL
FIRuDTzkqA3VeiQRJPcfVPwGYQBMohkPtNdjYARD1eDccM8GQxJxrdSiY/r6jpED1KMEHUKd
9RyzJf4sEONneB6Wgj62pIGZA91kh9DJ21bbbbbbaG9J6h4zJDPgE+M58bgujUhZ2EhxosGE
YpPOklakOwm6EmWRM2BOEmGDUCoodUdUyg3Qg2PABna8AxUTT1HjwAqe5DAoM5Fati4YImRX
CIS+u4bLaN4xW5nFzwSPW9hemy/fN6eOYFQXGrAPzNxN2sLKDOkUx468w3Ei8le6Cb2CurqI
B58Q3pjBHoBU+l4MLOvYI7a0F7dur0SzqAlVppPQ6c1y8o7QoCCoQ26ig89BviOhinG3uE9Z
BxjdFCDJliZrYE7cNuB52JxFcjUc+YeWfGaZ6LpyvLZ8/jcp4YlvKmKByKAFDSWdbYRf+JqA
xFjCLrvCiWpS2PZPTfPT8kL92+nrD4TvvaINohZSzvRzgq0xNMMYASNfxoMHKgorughotJCB
0qjGlnpCKFgI9tlnjmJZ3yDdtop3qqyMHpt7iDLK9oxETlaqpRIUxo9qJAqSjYCCWSrgaApW
M8Kgs9NUaPVXsoIWD0Q4oDfTwR9U7UjSMeK7EPHrU8pnI9k6e4d4sbl1AqJt+TObDUs6zBqZ
GeZzG4MYnTsPWlCJCRJwnI3Bzm2eemRJY6rLDNjzZOZE1OOunxK3Bi+6a7mjp56lj0QyAvti
qkg6J50Ugv7iSAHgMDwdn9nIb1OUHdZADvNIKpDPOsVrxmqrUukyhaYcbR1KCv5JOTOgV1yB
iMAxhFPm3qZKSiARfbAoteaLgjLWFpihRrTPHy0SoAx1itkOgN4NYt0z5iVCxWMtfgcZ6+1B
mLeZiIDckwnlkDb7O9W0DIpVoNdjrMMFFiBFhH49ENwcMekKWQBxcC6tgcFvFUrgeBDKqwLs
AVkJDpraVPng7Q6kdaLSagPDt8KE8ftiSzv61h4K7bHp+Qzw1SQcblk66cfv6GpakHZ5YVrX
WCQAQhEiW+iMAeIDFP25+f4zUjU4JDzCQstpIZ4Hl53NQ5ExDpA3IaneYIXq2ag/freiB4kC
+yXDHpbXvPxi3HcbcaYI9e2UylvYk8pzNk0kN1O/11bigcoKfdWtKVIVBDGYKwb0wwwJHz8B
2IQNEEDtQPj49iQvj4zRlzTXfy4daJhIVFMn9YRvRq8fQ1SK+QZiYd2aYJuAvm7SLJntwosC
GjFXHx1kLEQMRyvj3P08AEl7nDTPpnwG1HhFUiKfOywHsEaPusYv534XAh67nQltKE+SPx9e
yyYwfcJdjcXHPUOex6RwHdvj9jPG1Oz3qKqvNqqqcufGnbpsbbcY2HgVVFXhKqKxVY222wmX
hKyw7QXeg3IxDOxcp9yKbn9/2C+3qKL7ub7tymqAKhFgbBVd/c0pdyACh06WcmC/g9NNemkh
lPIiBJPQaeVttqk5QCJ8pnt/FMGW8VFVVUSaHLu8k6oSa7L5dPD7e4sfD83HG9t5nXz61q22
3GOOOk7/Cxtlvdz8ESqXw259t4iqdMUaqq6urE4AUczBlZQ59CB5e6Y9ETRYPQN2AwhL5o5Y
B8uSeYEZ/SgcgDFpN1Hpt1aeVyNmUboyTcgSK1AoW0CxFDCBZGdcVApiJt9VRNAkg0/F63NP
R+V0sABjpD4lUUBIySBxOuO4AxUQFn+eiukPcsUgVi5rZAVHK+y3QRLvk0DP30Mbk3nhDdLA
W8wmCBYoGtjKBO3BAMxNegDAJmZpIhq9udhkV+vD6YOF+4+k1ZCXGCeQEiag3lAHcL80xQAd
QJ2ngoHlV7QIP1Ecjxkov8p5LhcuihrAIB4fGbooRAv1fXqocLoBPNXKytG7eUZwTIPPktC7
QgLGde/wHvJYgkBeZnqsRiBEYmwkONgfLBGRMTmDIVBkoegMyIAhfIQxARDKAdG+oV4ZL2e2
i6GcKyfOMmGYQ74sr6jIaSUhDhseRkkAdgZvR1yPw34+zgdM4reHmMaSMimUPmJQFq4OJSjL
Neeq/PEK7E76+BWkkYObLsgMVQ0dyKEXQZ7/JpL9ALpSiwBFsBhQpDswW7v9iKnz6l+A7syQ
8NI3I3CD2QhQ2Ntk29EqWM/TvPwQMLVFsMBthRgCkGlIfOH7mD4shN9wDxmSy3ZvEHDym77Y
lduNhTWmeFVVy7R43inSIe5YC4phJfZOZGAkijAS5Y9B+UPt9D3lwQG++82mzgvf3+fuqOZn
TER4Y0PcYwJTecYCh5hcX31wwi7Ixph+bhfsvCDhwQYjIjlSnK1UqHz3Dfp6mERMZaS0ioiM
4wYwaZRTAVbMUq4aMjMCWatEA76U35fD93r6vVLA2QgZf1QBuC6FnOZuBFoos/BFGYRCRb4R
IGH5j32QdKl2YG7OfKwh5amKScje6m9S+agiEPEa97sK15F1MB+wwsY3ZKAly9hNYBE+WTMd
psaPslPze7zdH5qcQ2UHZRYyNPhte0bmqoGt6cLn1oWd7h3d81xBAES0kRqzovHp2WdNw1iZ
ZJPg15roXd2Q7E1r52HeIhNKXfjSN4fb+rFDrihnh1nYbeQHrAXCKrPD/yUB6oIbTRrIQmR2
nK1g2tG1/MYOTyoJjfLvGQTsSBJkyplmShdYiyuuPOyi1RQjuI5FFQYbMKMFFkZFthsGIFnE
aSwZ1TAmG91+new2kFTSGzCiZYKew1D+ZAnrIwdQ3X4g41AzAuZJS0KEhZSygGTJIJCQ2+NE
K0VzUrDFAsOKpYbiCGpYDhnuubMFfGJJqKLEAL6XFDLh02Jn0t4r0bTdZEb9oomzqQbpWnPx
7Q3FwoKjhNqsyQja9FwbmBhVopASAXhAboMQCoYITbmDqcBOkFU3i/2pUoRoImq1JabyDzsV
VNoUBrgeYvWMr0hfaNKUnxa0YGYZ5GBwiZNKf6mWD3EKso+kq99FGsJpwQ6nybX0l3bn3Kwf
EaNMUMM2+GABgF5SDNb11ukgdaZpAYGQtR7qFIgjt6KY9FA38f/j7bxYFxzPNSAaBlVECDGC
SM+Ppz1vy9hwF7y1Cko7Q4bPQf6dldrUpVMI7IyHK/VQYxINh2fVZHsxYGfJjF+umPP2pGIv
IGXMHuL6oDxQUO8o69gtuc+gH5xOQTsihEMYsQCLEnmgTZ9BCtmtcEgasv2p7Lhv8HETugnT
VGYFKgwSSNiJEjWTSW5IYEoEW6CZQ3CBZDAOcdoORfa/mXTpcQIjvSxIK0qtKCJpCFHXbQQ2
QMYHxQ12X8ksAqfQQ/lFB+pIFth5OxBD6qXaNY2ddbvEFg0ur3gDBAauEBDHXE368sNGqj46
um8oUG/L8pZZAzLQktES0SDaGg4xwibFW6ie3Gh+Agy/lgJjq6WHrF9ETVDuQcNaoHlj/bm9
QPs9txJJueVCoIvag2VFUCCMVFWNbUqL3EoUFICgIn5NGxhFvNcCkibApKKSistEtzQgbStm
p9Fj6s0vl9un69DYbeuMaHFTAVSEVY0MhXZS1RLGBVNFVO4bUvdfR8XXc4xHYBlIQV7dScQ4
hNAAsCHXBOUQC8yQmCRX4UJ44onFLwoqOxHr66RDc+vigJTyUew9ML4RBVBkoR8n5C+oDhfc
Hi02AxohIxygDOBiVGSCG856aBJIo5IPdzAdnJcgVLl0xdy55ArCSzrqtjancIQbqyqpiFBH
SqEbUhIpFkipFgOFuWfMRsq890AlSCTRHOVDMMkDDDp4dFnte/l/QhzRCfpz6MEOujavJEC8
EyCFIh1eCgsLpyg6Z2k4RQe+F3AngUDXUFnnrMqboiaEue/Wl7VI244hbNriCyLGFyUPkSfI
HRDy1saJ42GkgdB5d17dFUUjSo00FLt2wnP/hE9wYYG0Z4HZjkWYt6AuFtR9BKohI13CQGr4
DPoQjBEhrzwFTezrE0Zk5Met6h7m6nQSyDE1XpHCA7rg1qJ4VE4OvsCAGZ2KqKqw2PGBwyC9
3hme1NTqRYTLrKmYtoFndrWCJzZf0pDdqSm6lIhAhOMCioAUv9jYHvl6Eui0QwF5Z2zA4CUb
BAoECyCCEIXwEYgM8S5XRL53CFLEDjYBgnhdsp4aUeq5edOMjExMdrUvsCaQYdiwtC/IBcmo
b7SakM6DP1JrGSFku1ACD0EBTC2OBODZjIAQS9b0iBHgql8bkAFK4aGiCLu2dUqDO2+jkxAa
bMSkqZPUyBuGoCMcklZ7JCmbWA8Wg0qRofOBoGQGDe1s1uTWaOYLy4gFzsUNaULLeotrlDRn
bJNbQG7Kze1PRlmIc8E2rDegGcTEUpzQhWqAcyTAHmwOKk3jJAoRjBJp5AFdQxIBwjMDiGCQ
9Leqy2/eKAwEGe8kSqa4b+BtOFkihwpKEpApW97q8CerUDE+TQhb41/hfUQlkGGgWjFmZsUm
6v3AVjhUk2g0rZDKyD23oF780M4hvyvsvFEMMsLeJdgHAFxDzsGTKEbIIuLuUJFQyOLYZykg
NdWg2E1Iwp6W9QBIg7UhTJVnDQWAXUpE1iDMKdpCTL14gmQLEQ6p7cmrcnE0MISdDqmWyA/G
AYuRP5nXzN6dQpGLPGWmKBRtLtJI6IR7I/HLJIZDbEUN90rqg8FUa4UeYdnuEEA90gJkxeDV
ZQHVYsgzXPDAEqaw1CdDYhmn4fRc1PXwxfDghLEUuLhQCWcIqYFeSk82AHfgGyG8E3kBEDaB
MsJDOMnGTxGoE0IExFoJGAd9+vu61W+qiWFkIB+heQJW6a4lgLaB7g6KfZMQ2BRcv+kUBMoA
ECAhC/1/fRa6qhxNbSCS9hNNdoEnkH1YhO2fahq+fOta1PWBjhqLtvYQsGfF6cTOhL4bS9Ig
ekh48ewCBBdFD0vYR4I6RTYL/+LuSKcKEhkkp8Xg
--------------000806010101050806020801
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000806010101050806020801--


From xen-devel-bounces@lists.xen.org Fri Jun 08 21:12:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Jun 2012 21:12: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 1Sd6TL-0008Ki-Kf; Fri, 08 Jun 2012 21:11:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mav@elserv.ru>) id 1Sd6TK-0008Kd-6M
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 21:11:54 +0000
Received: from [85.158.138.51:12279] by server-11.bemta-3.messagelabs.com id
	45/B9-28329-99A62DF4; Fri, 08 Jun 2012 21:11:53 +0000
X-Env-Sender: mav@elserv.ru
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339189910!27493291!1
X-Originating-IP: [213.247.194.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16101 invoked from network); 8 Jun 2012 21:11:51 -0000
Received: from main.elserv.ru (HELO main.elserv.ru) (213.247.194.98)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Jun 2012 21:11:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.elserv.ru (Postfix) with ESMTP id 71145CF
	for <xen-devel@lists.xen.org>; Sat,  9 Jun 2012 01:11:49 +0400 (MSK)
X-Virus-Scanned: amavisd-new at elserv.ru
Received: from mail.elserv.ru ([127.0.0.1])
	by localhost (mail.crypt-host.office.main.elserv.ru [127.0.0.1])
	(amavisd-new, port 10024)
	with LMTP id 2CoWoIbI10so for <xen-devel@lists.xen.org>;
	Sat,  9 Jun 2012 01:11:49 +0400 (MSK)
Received: from fixxxer-pc.fixxxerhome.local (unknown [85.159.41.68])
	(Authenticated sender: moskalenko)
	by mail.elserv.ru (Postfix) with ESMTPSA id CB44C1C
	for <xen-devel@lists.xen.org>; Sat,  9 Jun 2012 01:11:48 +0400 (MSK)
Message-ID: <4FD26A93.9070002@elserv.ru>
Date: Sat, 09 Jun 2012 01:11:47 +0400
From: Alex Moskalenko <mav@elserv.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.3) Gecko/20120426 Thunderbird/10.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
	<4FD1D1A6.4090900@elserv.ru>
	<4FD202720200007800088BFB@nat28.tlf.novell.com>
In-Reply-To: <4FD202720200007800088BFB@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------000806010101050806020801"
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------000806010101050806020801
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

08.06.2012 15:47, Jan Beulich пишет:
>>>> On 08.06.12 at 12:19, Alex Moskalenko<mav@elserv.ru>  wrote:
>> 08.06.2012 11:43, Jan Beulich пишет:
>>>>>> On 07.06.12 at 11:29, Alex Moskalenko<mav@elserv.ru>   wrote:
>>>> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on
>>>> IBM eServer x3400. Without noacpi command line option dom0 kernel
>>>> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
>>>> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor
>>>> all kernels run without any problems.
>>> This is an issue that was reported and discussed previously.
>>> Fundamentally, it is a firmware problem from my pov: ACPI has
>>> _nothing_ to do with the MMIO space used for the IO-APICs of
>>> the system once they are under control of the OS. It shouldn't
>>> even be reading from them (which iirc was the case in earlier
>>> reports), but in your case it looks like it's even writing them. I
>>> had been considering to allow Dom0 read access to those pages,
>>> but obviously this wouldn't help in your case.
>>>
>>> Could you extract and supply the ACPI tables of that system, so
>>> we can make an attempt at checking whether there is some reason
>>> for the firmware writing to the IO-APIC that we didn't think of so
>>> far?
>> Please see attached archive. Tables are grabbed with acpidump -b under
>> Xen 4.1.2 and patched kernel 2.6.32.
> _SB.PCI0._CRS has
>
>                  Store (0x2E, IDX)
>                  And (0xFFFEFFFF, WND, WND)
>
> with
>
>      OperationRegion (Z00D, SystemMemory, 0xFEC80000, 0x0100)
>      Field (Z00D, DWordAcc, Lock, Preserve)
>      {
>          IDX,    32,
>                  Offset (0x10),
>          WND,    32
>      }
>
> so what the BIOS tries to do is unmask pin 15 of the second
> IO-APIC. To me this makes no sense at all (and is definitely
> impossible to be sync-ed properly with any OSes accesses to
> the IO-APIC registers), but could you nevertheless boot a
> native kernel with "apic=debug" and post the full set of boot
> messages (the dumps of the IO-APICs being what I'm really
> after). Alternatively, "apic_verbosity=debug" passed to Xen
> or sending the 'z' debug key would produce similar information.

Thank you for our answer, Jan!

I attached full dmesg output of kernel 3.3.8.

Also I removed the 'Store' and 'And' statements from DSDT and compiled 
it. When altered DSDT is loaded with grub, kernel 3.3.8 boots 
successfully (good!). But with hypervisor boot process hangs at loading 
aacraid module (last message is about setting up IRQ). Aacraid module 
loads without any problem on bare hardware. Kernel 2.6.32 boots 
successfully and loads all modules. I think this issue is not related to 
patched DSDT, but I'm not sure.

--
WBR, Alex Moskalenko


--------------000806010101050806020801
Content-Type: application/x-bzip;
 name="dmesg.apic_debug.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="dmesg.apic_debug.bz2"

QlpoOTFBWSZTWcklPi8AXlR/gH/0SAJ8/////////r////RgUH54sffeauHVeUdqVredN7He
9UGTp0dt9gy8xvYHoCnvZ6AHQJzHPvnwO8vrr7ve86lCxrZ8+2j0wfb728wHTnrpvtp8J73b
zw4+rZ9re4wHe7dj03X3fPeNsc12twHbuaAuwB8cwdBmxoc9wbsa7uz6LU9szVanO11WsitW
mp3098oADoH3HvnLtstS2q7mmLdtK9jhDqvs31qzbdXud6w3LVdndyrqO4wOmmnbBy0VXW6W
p3d9nnY09ui7NBJIJoBMjQAIGjRGmCBoCptTbRTyQA9TRp6jIZBpoAhEhEyaJ6mTaT1TRpoN
NNGgAAAAAAAGmmSaIiaaTDUob1RoGyjBMg0aA0Gg0AaaNAyDQSaUIQImIRpiGQo9TanqPUYT
aRoaGmgAAAAARJETI1MTCNIAmEJ6TampvQao9T1PIynpqPUyeU0NBhA0EiIIBAmQE0xBA1MD
VHoU9qnqbyo/VP0p+ppAGmQ0DRvCB+EkBITwkQpKGvYWSFIBxVUQIMASRVWQEGrCUA2UQSNA
HzMwPuZnEAoBtC0HZISZiAgLAwElRhlWFg4EVLCySCwhIsJFcElhCWMFAMDIQRIloCFNDCAQ
T9n8Leo/H/Un+TX7re3+OOP7/izK1Yc+V+GPL9OPFIn/zmeHl3u8PXVigAMw6TltzVv0f64P
r9mXZ+501MlofVIv3+2rCNv6b6bbDJu/jljf6ttlDMO0U72flT3M/oywMrfrSW9E+OVk0Grd
Dl6JStG16nbbufNPbNg+1J5Rm/+r/k38ZDpU02FVUzskmAFc72jby6qV+esT7uqZvGJYk1Oh
mW9N3reb1/kBPs35+3u93hK7OCkx9Rz/jRn1IjB7MEhIQkSSXElq+WVVVuPR8rmHVJ8fpu26
/bgMYxbcBhCoc2ZtKkrLaVlbizCHw9bGRkHX0g73vVI88OHLnafp2pvv5kbYNAZuXDQlKREI
VVVVFRVVFFV544yTKSAywkBukKM5OltdrVzLxNsJ58oK/9TD/F+XlrON/0BlVjTW92T1Sjlx
+nO1vPhd29VXp/b2uoTpp4bK991FiuwXwdUT2LSxIbQ2Ozbzynxa/7Py9vX7rZWsydfeQgq4
uhB5eQATcj8ePHjpx00z0UUUUUTxwJ6NXKxwg7f0TcBp45rjEBuN8tdb7YQxPpt3ZPxsfUnX
UNVP7i3Kx/bN04aHVl2usthGNTGquonnGx09BZRFLk6CqSKRbCeCPJxuu/OQr0R0gHS/mNP2
UGXdH+Qsgvf8deFqC6EdM00yCi6Mz8UxMgwqIeOI6gBgVQjb2qF8uz0dIeV+2PDPGfBdv9Lb
KU7avCh0r+Z2Ruj+WmqvVGMHO3W/+/nSjM4wZwISEjDj4eHQHVofhkoiimxF3AkgEIBIwQCQ
YH8hEVKRe2WCKEULCokisUmTJgAS86RZ+0rB4HoQYu1tpUfkbjefp/zMSbhlRki74rGAppnO
O/8/mxDDioy2dId6C0okOuDxOxFy/oCkALk4lK0wQ/QDUQEwBcFbJcgDCMBgGN6LAtep8WBs
uMeAOw1Nrc4FUQFUhG0xBI4hO1rXm5RTcGFYDH6wxfP0T4cERPgauy6D3RbjPQkKbO6fLbjt
9XLmB/Q7Bx+sX9+e7DDrbbbbbbb18Nt32soQVvzd+p22NF0j02VmkOyaq2HeznMNsoNNX9Tv
gdZ3/a8DZNPRQ+nPxyOYunbryh4kPW/x+JXGux48ZWg8cw9y+8hR+dLUW9+/kHrl93lz4d/L
9uFi1rW6XuGxGORkZGWWRST0z0FBRRRRCiec+Hw3nIcN82KTOpLS220tJbMmQAD3fKu7yB5/
xpLIfmQBqtVA/v1DccKKAf/dVBmdCqX1QvvgkvFC7aNq1tu06dMNcdc002vXr2bt2fHbbbbb
tttfmWod3cIO/qP4ykv9AIP6WgPJiHbjLG4dRa1FrUWtVBUhPyCSbRkjGQGMwhX0KsgxVZBK
NVZBirFIUx0CUjyoDbkB/CvobNUU2ap+lt+b6rff2Nj79LGKiKiKiKnHPEwjGIpyT0+F+me+
593ifJzyafbYfeJD1MgKqqqqttttJGTRdqOfxDE37zlB4WJzp6TBQpMw60DQSF3VCvFek8g1
/GY9OcIOaQWwTIYcjx9AiLD8BChGblRpPx8cHFpbS8YwYtLjGDG5ZDbuDYvnDUkiStIkJrDl
AohA/Gm2adEPBUMYpdvtHBBIfo+2yKHTGjQfuMJKZi0/dnfLs1bRTIYikgdUDMxL67i8Yt+n
liOzxopSSOTAsAewlNHVgU8pHnq+w89beq01hD22K7uRUBa1ZmbrZkCLZpPLKxK6YwVOy02e
askSJpusmIngBNNiMs9qoooJTt1AUE8g8NE5hgW8Q5QZisWsUZ9kwahEGh3U9/x7PaaXFYX9
+/Uk2XRnSvpz3SCE6r3AT/iTS9Vrx5s+2GfR4zeVe/ZVoAmPUw/ZteaEdESVud+I1O0O3XGq
Ud7CtL40YmJYx1usFFPz0v9aMEo3zhzzHTCM7VNrmdk9Kv0Qv1KlhmMDMZarbTKBTDB0aE4d
/Nsb9bY777YAXs7psYC95fCNxLHngtJS41fe6bFsAdbaW8MUZ1hjdgAzbMPPVKE3wPpPqiyJ
LVbK3TnYkPUHP40OZzOfLPIDXHKfJuzMzL5UMuPcHFLfKr16dPHstiyTURKkmlyjTQBUPAzp
UOH9zCKG6effv0d/v8Of5dPDIGHDGMxtS0+o5edv2cztQq+ZO1DwT/CCSAb2fHsJKfaC/h7y
HUHSkmZIgH1w7PzG07sk3PZzA9rCMNZB+41iKZC62SNdn4TXApWyTuDN0P3tA97F9AUUTbzR
xuhv9TudBWGfpPw2p8Fbidjog9vIHGQFrjJtGGQQUcNdCQU8BA4rgZH3yloYnK1/EgrkJGaI
23uqCHIhmvmbwLJBWc2t9CwHF72YHK4sR88UffEDhIy5PDt7+jv4d/Nx77b/KnfbRMZFlxna
8L9BThzxBz+VE5Dg4+C02RgNqEfap+INtst7B2ogIOGjiSBdEUlo00E9ZRnaHePpubOBqRd0
97Lr+jerBH2HVbsyNIJIA+BTUji3QqIUd7tRLB9aQW1vBy/fYAyxWQPHovAk9HU5y2U55HRH
NZug7fTMV6subMGZJBJSCCh9kfF3QDzVPPrxPx8vh8ZrLu1mIio9BjNWte9QP5u1bT7fEhHF
FBBAn+Qc4uta7UEhd02cMCeSOkTl7/Lw+IZWd5JQEAjj7BYpNE9S2O19puW+weBKL50eyFvk
FyZ+wr8ZCj3+yEDQdSJs/kRVSMQN9K9vNI57uVwWW/FmVhfKTxr9Kthzf2caBvTolxQPJpCm
+puJJ86ezCqK8xrPn1aW0y8Ehw5z5dXeTQ6dZ1oM0CIHmyKXu/YJWAyByOLGDRYBmxyHP4e0
ftbN4zC7aTKh+6mcSL2ALtuYB8K3JSPbd/MIUHefTrIul/aRICHP7CJAGL6JaXvttuCS6+ku
COPqLhx9ZcOPoLgOC/Vi65F0/oW7W3Ypm0qNpbMuDFCltLjGBQT3Dn4hhGDAifsUgo6wdLk1
baRaqbaK38vWMUEBMD9md9VvIWoX6ZnakAZMt5at+8gVY7mzSEY0bYFkcbS42FpTOS77aeaC
AmGTScafr9081WyfJzhdpXH4eILf+N6/s8Hy3fZjkvedlrXPYIWR620htttsbEZiesnyeNXd
h6/KnFLLobO0wT0PLrnS1WokJPP34nMTjBk8+L/kia6yWznAquEG9CYX47LrcxE2Wvddycd1
tRPUgC6sMtPv1fLD+lVVSTqil0MZmMdXHPRLEA/3vx6/VfaKOh9B1OpjDu0cyD2shZjGCvUk
WYZIYHN5c/lV0heissc+l0MrsOvpbEK/UtNFjbetwvY2/pdZbcpP96DjACc9SHRt6rXQqYCo
IXHjGgZBJIXI4JCb1b3W1Vb1S+f5p/i/WHFaGs2x9/45/PDl4cOHDx86NGrxooozMzMzMzMz
MzMzMzMzPd9fyfR7p/Q/4+qUH0yf1kHu+lkAp9nCPYEHtQCOC7jXy9wKszZ9x1d8S8ZIlz4Q
XrYxGJ1k4GyzFgli8r6J1gwjxRIcjSdQgv/VoCQtDvr4ftJ8tktTTmOnZkcuZ9x3MTzOJkFO
5EkRwZv3BZgicoY7BybP1MJ6RFhJYz/y28J6U9FnHyoutKgldug7e4RSBLLTCaegu4CeBjsd
cz6zweunOVC9b7ArwNff4ff+6NbaaEsgFOTQxVkmx23rdfZZakmzMTeh270X/TJj0rxveUNv
yebHohP15XY0WxQ5hkMcmf72vyzJLTj/B7Pyn/B6/wszN9v8OZmZmZmZmZmZnq94I2H9uOIQ
khk7TiUA3ajPl84slLNT0oY1fSqx5zLd09EV5cunbtdo2PftyZ+YquyHZk0PSQkR1DhCOdkt
7Bt+tSiMwzFDHv2+XyAVVUVVUDbx9/v25cUgQ7hPGSXFx/p+vbn17+wNqZ+iNOzeu9+o/Rx5
Mo4ZMQQwhrkm8aVd/VdN451u2AeOUmXwaZ2QyyPaWIQd2QXfk7eX8fq/soFn4onmz9OfUcKE
fHO7zasr5kh2yCQEEqOubVu2qSw5GfVx70BeIeTLoTeocEYFRFnv+TstJOwdEPFg04Y4gcIx
BXZewp8qChrM1KWZttFUCHi09CVTtjzDpgg8rAN2uDfl/AEfKnKXOxAsoijQOwLu3PLEyIqc
Pu6Ht7QPLRNhW2XpAdAQntQqAcSOVjZHLkhVZyRSVBlC86Amnrwx5fZ4+yakBVJJkK6vsr5V
nmiMlKcMAegPb6lHj165KnkrLDbWkkXDqvqgUBPG1TaMlC1UTFLlPsnNTY6/cNR8P2UkLHRb
IMb/u9kSXqp6C9Ln0qzKIF58u480zJmTQmR4aWyL580jyx+kLnfWyizb8PozDsOPIfpXvwho
b7AjxHJMwzMzMzMMj1jFqN3Gd1kcIuSOoYDYx5MIEzCYfgJ4JLtZIKgGBKp3T83oe2/sbHl3
RAcl3Rp0nLoxyK7mOnQfd7OB5yS896n6nOgcsBQVRVVV5WRXgw7zmf5W6SJW4q7pKhoCmvoo
5OycIA7fcd25kVtP7vCjYzTkg13xw25dJkE5jLvKKdnK+yj06zTfKoxctfxCm5TT49ddmLLX
5a8WP0SSXx/Xlm5ujmoBZElniwOymVDGYFQJ0EoMgfk9uMMBscpkDI0U8KtWixAXUE+ZxbFC
nOvHImldJS46OeDmN4288D2hzoQbWQ4BgsfpP8PQxzhrJjX0DY8BnRhNAhCEOEFuKTmBhkvG
KQFB35/P7dZznHHW9dtts20sQU4JaQzbJD5Q9kD72LB2qkLbAUFgZJMBgkgX62PujVHzZGxb
bAgVB8RhPrN9buIbhxENuIg+Y6y3EwzJx98UoZIg/AZlkQe9mptBoPi/YAI/FciDMu5sRz9q
PL0Gn6qdIRmw+hHlA0OUYmxPxFPOB1XApzL99S4wKU/jQ8ndT1+bNrA5zwjp3HxQlkrXuf5E
Gkw93A8vG4Iw4ayqKqmc3s6YRRArBlXGKh7IABf3cNtywA8vVQvKHVp39O/byRoq+FXb3FFK
M6CmLaC3gC3RaoUllNcQqAMjvIHnMoMChQYoVQBkVAdGaFk/UooEBxYgesWPujBoXl3d3dDC
nFQKKKaOZbS75q13reDCAjMqIApCShRSFIjbva7yViM59YS4OId6KXfXYyXUGzoRGJyYN6Ym
MWSVDCMS1Ttthsp0R0bwRFkZOfMzgLkshzNXpkNsQMczjFqiCimbjkayBtd+V5hmE3DVhVAy
gQlZUMJA4OVsrYAGpqkIRZAI8u3IwZk5kSS83p0hctZoaC4mDAHJ55znLuGNrxVWsRLAUahm
KVUXGCVBVqIM6T0nvB6D+aQyvZ7FE9NUIe/yuls6dH0oXyGKHCdv6FmjZMOxDyd8+w6exIQ8
/b4kd0GS8byMOVitmyNJEyMY+L3Q/Z3wxMlREe/PZyK6iG7q8tlsH6ey9YzrZJeuIMcq4UVS
W49TCSSAFnq/dJjlDcxz28b6wMOVsi+WyJSAexEGAngIClAExCTu3p5mA99A2S/upR2Sxc33
em4yWM+ywPJE+QQgphhOwwo0b+W4Ny+y5hgokel5uWA3rzKxylkk7T0rwPGZwO/Ah7ic49wA
+nqxztf/k9M4F25YyAQJf4JwwSsvHYyqArzx49vLn5k4so2TfbKbtl0ToAtTF7Bc9bkkAFLI
RBAGEkgwpGUBSEpQiKMZI5sggWDCgEQ8J6VIfqwPPlXigflhrggKOzyxeKdLnLpNyLvM+FYp
EWBl23sLtmA1XpcHW+vr7M6iseO8WQBrQBcDUgbBF2LMVo3yjgqLtg2VERrLuriu8wTgYPex
0vctZs3G7dj0234QKBQKIi5cRQKrVQSMzypJhfOtd1gta1YmEyLFClVY5XmkL6AsLTjjRKq3
B7vD4PqxHbJ6Qig/dAU+A/iUgo96AaHI37nfKklQOGOHO+V0XWpDnFJkcDjn2NZB2hkI7DWv
KEWMrQWnKcB0HdeAkJGB/hoYPLfjQkikUJnsbK04WBhAQLADcz+1808678yh+LkJ0lTuC+FA
Bb34MQvlF74umcoo0dKUyVKaVCTOufkw1XMRTtKvYMDC/HsXVnrMkaWCyCxAigs7mzkTmo4B
DcztMa5LXYpyScjG7tm1vPUwGIuVqi1tJqAVwY5OerRw5LhMLscu81NZ1KMlaNO3LY2JDjW8
DcjMIKTAcs+zRV2epkx2lVko02hye47qoQWSHUkEgwIIJEGIMQEQgJEIkUR2FSTprrqyvCwG
/qx2XQwE3sxImGKWkhNoBsb3LhnvvfKlLpeweebuU+xotMsstyXEjhwULcrKM3bdDc7qLhtS
u5xaLG0Qhw8KAckBpVe2i0gG1aGhEm/QdpZCATmeiVbq5oDZ7UcI0EDwUH6L9ILcKsKveukR
Bw3HIZ02J1A0YgCGxDBbAdUoQkTBIjhSpuogRLEh5DHSM9xL0rpo6l1ZvctminPqoShA4Aol
PMKKGteHUuVCqzPyIVV85aeiYUQ9i1LDK4b9EB7AKm5h0GI1YsnqOY4xOtiDrtD2w4tC24yW
6GsrcJUwwApHKka8iTkDLuHpWZYzDmEIu+NqIKYYBON5vGYCOLOIWnjw7K78Yz46DXjO9pVN
B0DGY+Yda5cDkBUcIhZPhFo4FXWSYgpGaernVb8q4RpRu5AfanvyArUDEikiVRf+NZ2zzlRr
yyuoTK787X3PUwEAYAw8HsR5cixRqGPonlopzYB7OjhJllt1LLwFtbLK7SO1xbaGsnQGDqJO
gqr4XNCFpOiUUFF4PTA7jsii4PVq6BtnGSCAoLU7NqiTSIAFCkxUy56HqA8d3zxp31su9doO
zJEr2vWi9lGIDFdKO5Gmc7BGSewK1XWsq52r6HLaAjugC+0T6qId3KOgXpJyBgTP5HH3UyeC
C8ukT+DS+DAVdmtRQziEiUgaAjLHSuCLQaWIliAlC/HazwLqK6kB6C0I+og2Coor7KZkQmAC
RJMNM6D1gSm8K9yolZa9l+6e/i549Nb3+SLmMvSTHvLWzzu8vybgfiuiOanIxt8eZuCAGcaq
JsQVDRSrKxDZjrcu13f3UnUSNAqosv0HICIR5+4ptgnoQPkImdMuWYMhZpkNAwNMFlTv+Qog
OA6FwRAhgGKAkTQ+fS3zeFx2s54G8BPsQ4fqYFSIkggyJGRVVVIkSJEiRVVUEVVVVVUirFTv
lqqqqq0lq2W2UpZSlltlKUpSKyHw0oiKqrFVVcAX7EwryQ0kMJwkUIWAkWMQYjX97ZsYwWgj
GMYxhPwGlqCQIEVVUggqqggggqCQVIMEGCQZwqFEREQQH0d/D5XGvuGDbyd+PVP5vLKOzrfj
50OWrbpENs63X5LJIOxDBiQMKCp9+fIfA4cL0QYfdwF8WitXvtLhEEi50AjYeY8SdZk17aJs
GqdLv6vONQS1FqSg2lxU4IuZMM1pw6aRh/afHCXiWHTygqhg0Yx28EYVuQn3kRDzypkxSsaV
V7vbhc9u6jTZM/F6DCz3/kr+kiYttdzxZemSkBsAfL7LfcVfGU/ee4+Lp/pBlGvUmesG/EMf
mt1aXcUjvtB/AVu7xUHKoTJk/N85OCLK4ypoEZzru6ZOe+Ui3dPQtjJYhtlbhpODNipjiJJB
UyHPCRZCR5UOvlXMHAu+awDSBOUC7I+Gud+PEoWZ9++FZcagacI2bglw4KboWEhuGgunhF1L
ja98KqqMc1MLnTndfePCLN8SfFe4a2zSKfXhfbylYZbyOTxOGMTpm7TxpjO4wW/GOPGUlUvn
MQjei+W1ZrmyC4YlDTDBzAkRL1v37Y7ZQATy160HAIAcdJ3KqPOA9gUEQDB08zbjsK/hsGda
ZOiH7TgGQCBuXRz6mAfyuF5Hjoh6lQ9d+BO4oQoGCiEzx4ZB7eLaqDzltHj75ftaHdeTWdeN
+i+alYnUx6hHlicsfa89ZpnO58gzlQLgAeHgwWt+WGugRumMcAXLlvwW+IN+9EGx/6JjXUke
lHLFbArLNuGG+uK/dBCMD7GDaf0SilKMbJ/awLsRLMFphpKV4C2btCZmUPR9XDpy3dezv8u3
NY7ZfTHO7TupAvasORTnUgXNJS1W5TvGbacc1LMsCHlWlmqjUzI7cxSu25+xIuNSte4A6js3
GdHEHkVchZbOR7xgXFIMBLmRShHQhhCHYqBuSWaGDVYfl2eR6qNki1nj/Cl7/m6s1xlZnHYM
oNCTHs08JEnUzxnrenJZ7Bz/TYO07dMLJFl7sI4WoEHnvn6PfCkt+ljGvARZaEnFbmQlZM1+
VWEUpWkN3hHYDRLA/ajoWOWWV25pBASLHTd4+4yulfDtptuS0KWIHaFBEAukQ/otFmYbn1pI
rcZFYkqyFtQn0mCM6/TaDYFAGNeLz50pibG7D8z48HoG24kgbvBkqJxqj0AvJGDJL7WOOuPe
qAkZAdgAmb7a+88td+5qcAddn1PmgOyiCCOF/ivklYWmEUkbDqcnyrwYTpKVASQ/FV5oYcnJ
Kk0nSKIYYqwk5l72jhOhgozhmFwvrhSACnAOWEPfnyInLnu/TzxLH2gTwQUwMOdsFnZnZPAI
ztnpjwTkzh5AyW2pYt1hzhThbISxog/QzOAZEJqxq1k0Vx2Fz11x3Gs4gxXI2ost1cwPbNHZ
dvRu6gSj2m9t0URgNXN8lUlgGhxFD5vUyajWaAjFlXfNzSPXwW17S/eO/f5iSfQWKqgwEAIB
JCqYhQTqcJBmP5+cHA/nc1ocYrw4buBWlONbpBOEK14rDqcvupFPWGzl1Zug/og1oXby9Kc6
udsszQpmdsdoVrqCmG7FTXgarAfgDr2BQj0ZW+R39/iPRhGE1lEMvGmeMhjnH0p5Py6R4+RF
7dISoSeuLrN98SOYjvxFBXpyvS8QZvi1luRHhZFCTBiNvpW6fbSPIuGv30VGchogFYD+7fPf
3nBXZmQKtBGZRc99pMOEUr43t44V6QFMCzvjeXl4GkHn0DHbtfRvG3BccXqFel7PcW9fT7Ne
bAjxnprtu56gsA6OHUD5vHdcg5Hg+PT4jwIRLIq+n7QEsUSF4XaZhHLK6r31DI8b0JOoIuY7
28EzDO4CFzqp63I+1znybTcsi3vOPRo7Ksiy7BEEdx5GjQu4bsTbGep64o4E0QAlqFAAogKd
s7hwHI8HklVILzuFVW1siZoXtQDSo5CzpkHId4RhDK0bJ4z4vQquaDaHAVNbGg+9gzIDqwUq
TKiXgqiaDEmIgUWW9a3682IiCN2ojYgQmKgoqg8IdevXAuze3GN0MW6p27rp9c6SI8hyEoqQ
EJ6wIOAGR+JNuJ/M2IoYQVcBDzloTxxypLm+b4WICIi1zU4bya7HN2nLjKqoNvDXUqKp2fMy
8D1MTVwtUHM3n5vsjR2SVtjVdJGD+dIIKzDaHSYPDflZUMIE7aYBGIIdsose8oJefG1d/SJC
jIfvd54P3+wjEdXswMUEe3HfYrZwfhBvsqQdZSmuWMh4VylQ/b3cOgVI2JxXdv08hWTCcTXU
DigS2qaTHbyk838d2U8i7kuFXiGBqdhCTxBioT1r2+JBs0aDBDHd2GLsakxpENvua6UKRKMC
RkdKlDG1Uprgk2C1FzLfICUW47qX3rv2H46SBybLp0U11vqKtiwgWySZjqptWNkxJF0IvE3S
N7nfqd2lFQRBWFB5CwRt2iaWNgKPECGUBSCYa2c8UgDeItiDaK1FqqC2JM8jI6r2zPfLaBY3
UDdOa0bWrIQOIuwmYNCZ3QZaVkqTAUYDWw4GaQohhDiD2cKbWmMZxvv376u+dubjGFkMIFUQ
UkNsamcwAUmcusINS3KwwhpPBR11SswKuRBalzUKXI4a2biDJbURb1TjZX6FjJNspfGDXPJX
UKIREctBlpu1tC1CyGQkClWFWydMA4eYThAYB1g6OaUwvCFNEbF7t7d/mz0892B2eEeAUYOp
VXLVvfTCoJ3dcBt1db9n1RfWOMI729xAgDv1QhdhHuNoXbKCAJ471w4pHEo4xPknS3OTa2Kq
LWRJYtYg5DwpZhVUHYLkNiBBGTQmCLmIipBqpkm6EmC9StpNmpREH21AVUGDH1HojJvi81n1
h7b5d2gBhYVfoL/D2LZkwVUD2REtYcNtqVfp7JDqBMMUVIOscg+2iZXks7TP481Ra3NxiU2w
3yWROUwtKEFKQRKIqojo2aXFMggY550y2fl9VovA4AKS5z3kbkCpe7AibUnPdfV4KtyC6SHS
m1bzZJFWVbZmmQM5oWJNJAqRYE2YG2d9BeRo1hd9ilS4TNaw9UrhoQEbqb3CnWKsxPtSG5Z1
IcYWwWGLUUFig4oVBQVXHGC8YFsaqwKC6GFKSKzRFaVUiQTNVLHENTsC8vDcc3LyZ5yA1AxI
zHDq7NFxo3Uki60+9CRd3QiKCINq43EXbMVVULAyWfdD6i13sVhulGyxqFLrWshg2OFccwWw
WwTZtqaJm3EgqGuJnUOzepIPvBUUE7ICAL2OwG51dv28dcbtt9X3aVLiqmaEF3zHRIWSLoQk
TmSaZZWmDzk2tyq3LDMiFfJxnyoMysrExdTBtpefn9+52s7GwFKAfpllT1ooQfCOCzn2Q7d+
xeRjxvsvHj4yjZI8OgHskD5nKlZvm4Q8ONHjddHmnZvGZ9eEGRdpXf8vl0q6danWRHhRVAqD
oV07slcM6rnjbB6Uy6EC8tQiyYMXgMTDHazEIvgiPnULSgu7MPPNsJgDCASt5MQkFErHZlI0
Q6NpRqlaMciVGgJFggVTeQIezm8Xd/ZaaPCNi9KmWLcZQ8kHa1D3JydfXJ93Dg1jru3g6dkH
oq/Q6nrbW/n5FscjbsfON9XpEQem98eq5zl2EpC7zI28QKVuFXZWehd0IgwRkBj28hVzH61l
jpsRQy0TrmKo3zk8DCq2XcIBZosaGldsyINMXgRMry2TUBcy8dzmwA0UEYoDp4eTqxbseAlJ
7B4g7GUiAC/WOeNx03iIttqYDKaztXl2ECphZEvDA5du8uReJRvIUK8SMFrhm6DBZIHbVNNi
1IT3oPWjo+pb3tsnw6cYS4J+HQi5aKi75mR4wuW/Xlar49/KmTaPNIQjCQsAZ+nNb12sbkBE
QVMRHficLrfdNSy72thtaBNlEJFrHr8s1MKDpXXS3y2ZCWGEaba5sahQ+s3uWwbvT6F3DPlW
UEKYIGHSIM1ToiK0ErAyqy1q1CIiJqw72zHGxWXeMZOm9162dVnGXKUZMF9lrlxzmQN6V6za
X00AliVO2pV2uLJfcqaMUUY466kYWFFMNciAASiPfrEbbImHpm7kckPtjNy99h/cFCoQm/aJ
933hnj5Bg6+by3A8NtfRvV5+kbuHak2p6Dqy5Z1byZGpdVt4haoU73UiZcyaDLOUuLmTMZU0
KvLpaDXEQ+MsPeHX1W1SF0/kdTjaZvb19jy6IgcVCqWUVKIds1EhpVvbCmyq4Kyjq3ZSyorl
uzD2IsfWNkRrH5sITzte5I3sBv0mOqBWySkziGLZqyzszaetIW0C3YCBW13NbPqpxExMzJsk
wppkeFMSnZlohnAzgh6MS6+dxBaxurPCtXTlN8Yw07USqVMiq9aQG1Jxq3k71ZBhnOZTVZWq
/0IMzBpfMDW9kpS+h+6Dxgc132W0Ce9bbXG+RD4RFASr66OAdcG/5BFObntQINh8Ymlfkwpf
TopRsgFHkdqkPQudQFnRTOgOmxw4HACPVa6gasLBZHBeFh9KtupNNVYVmYa72rMBFBqZVySB
YpUYq9/QHwIPr2WDInYsb4uldVfTSyyQEAVSonxzjV8DpZB1OzZUyxW8qhrYokNy6xGw6HdA
eCJM4yOwsP5WUG+DkKYAcU9OusTYIFl0RB323J825Y3mjyAY66l7R/eGCkfZRQ3FHcHe9+F4
6vXOlWkEzNijUhqyJkPRWmZVXLElBkiqilMvbiMhEyYp5Kifnz0sazGC1YI8IEKlUAKDQI/L
OxtOYq6DV+RzuJkeevQ/A+2qu/eX167dR6bbrULNjAXr9NqY6lpL37UthoKdIdsOvQIOv17v
PPbjBDFRo40gCGBg9LWyttGveLLHB1SRjhUSxtIYpYLeEed7AbXobFxsIUZc2EYokHGLm2fd
Co3No5gjA5K+AQFhY3mhtyz5q7wUy8kY0hiUBUoxBgqiOJh31moGcM6fe10MNscAEPY2RLa2
ML7mQ+CButABtWwFxCrWKxEUqKGKk0wWNssUHdiZtAsGIxLZSI+oiHkjnTEtwng/F3LRxdPd
99W8g8x0dmZ0EZJMLyVIs6G12NaWiFBVYKKXxYfW6OM7AaAS/ltY9/1vyLbN7hmx47ju1AiX
ONTzUUWc1MPYllyVdlAa7Sbmhk5U1EK91Ey2L6RFSt1EVTL4/sCq2yKJxsL756lyHA/x5KYJ
3ezR/D3O/Mm/D5QoEaWSYZJHZ7hiCjDbmaaoLfdW52HUC+ncL8PK+H0bdd2vO8+DPO3utRRR
RMW4pa7P5eZtzOXv4nhw+i5qQu7u7L/szlquU7mPesQtoVq1FO/a1Pxyy/+OfVkpNED5EqMT
X7Nqt1isnjjfT67588SK0gP4QkutttinQ90kzbzn+sfWWQfx/kFPhh+tig5YzX7d0lWzYaI5
O+9vdFUBsYIg9GuF+LH6fX9dO1B+cFm7WtQo06UphhW2mvc903BDAyGCsM9NayBTpFmns1Lm
yGX9ueaU9vhi8K8dmTu7i8wMWJSZsU9EinWJdKZ3U9X54rrDxg1VVtPvfzogStjzPlJ0dH5e
jMqqD4fH7mZSzcH5z6/L3yrNsT2gBuI21pSXEMO+Oq9OdIwQYdH0kq2xPDqy76hDNDIgGjS+
khFCYzxxxzwSCzxGMawHiIYI4dYus8dxvzzZCwuPe2LKbcc/JNq6I/PZTMiZpVMDhdphZKCV
RL+/ea59jlJp576UYhoGgYnln0I3UzywnDLKFGUFBnvKa/VnHGxhUcW2ltqreLbioeBPVD24
21t7fNsw8fP8s1Za3urmiSSSSSUQysqzDZqqVfJVamnXPWUWNuazMkrI7ODjNqmPVjxzKjZH
kgkI0ykMwyR8vP6G4MnhbnPwW23WtbWl20IXaBiAlbjGMUtVVUGAgMV0G58/La+/6/bt1UgY
rQoJotmhCCa4glCkEinfCxWDLCBooAdEWO2PX69aRzq41qmGDBIaQttSskq/E2sEgwD2vfIX
0yTjY0QUmUU2QyHMkCngzk71tYBdSRgjASCiZh9fgC2WwGCOmZmYdhEID0oHpvH3NXdHM+ci
w0c9LPKSAXxJkWZMJzaj+MA3H1HHwHVVGykKCb8LDsgfziY4oe9quqYgsze4rPmPKyY9KHGc
p8n1EZz4ACMlQZxTO9vriGrxOHjxKcPsHLF83+z0k5C5C2sCSIA8W4/PryCr8v6BfngvxYNp
IRFpmBrh/jlJWi9cwwW8fdJMQP2lAhb76ULQIRIi3A5qcCX1f4DkvkYyYThknx0Ou+tiB4hL
XJBgWDgAk5m5l6KtkZoE5WMWBUkX2mgt13VSQFo0a0l9gzUUGNCmWCRbJoDWwgvBGTXg0hGY
M2YoZiMZEK8wB8e696X7M9PA1qdTClXhrWecVRkRxh3GUEiAyAOEEnW/hgUGzhQaSwAPS4lz
Z3tZanf3+WOiLdl8sYQl2sCSRHo0i4oIezr7dXWNsrK1wo7oV5epNYhi7aJPKRULpYGASdWc
Bz7IyGHUIanrg40IOjJbDp09VEAvQyLgTE2bBWAj5XTTZfvejaQ5nkaXGO8cfcx198Ljr3z3
SRw050/Jbx/1F7GK8ggla407aC3NLZpHOLIyQYmePHCckFzhNP8NPRucXFy2K7kowy12js8n
pGFxXUURyTHtYeZqOn3hAQZBiaZcwDPF5cX62Seo+VmhA8vgFJJgWJCKwlW3GDDUKJAhoLIZ
T12eg0EsmWGzISkRZIRjJi/9kfuIvumCCnMsarIhvspdj2HIvGBcy1G05oQZJewBkUsjewCL
1vQG6x644nGhQNkfEBAzhz6+E1CZYAvsgga+f6zCbwapBK9XJdI4nnhFgCwVh84VPh3Af7Xf
pmOpToEAPLHzHLY9WhSkzJVXS0c9lAEHTwaAy7PaTPztWf0vuNMnqqRIIxpRHMDJvPL7DBO4
ZN+GfX3seCoQVOqAHfIAnCB5HCsK1fVDbJRLNYEdwERrEkODitGcFOkKAZMUT2AFuAQTw5nW
1ZEJt7sKS12HW42QNkt8YQUoUsHHQfQJ7Z/cTHcoPkI5TCtGI9802APuSYuiU2nWWBr2wIFd
Ifm0EMUhtfiVc8xiUGtU2sBA3RJZgBIKMggwxWKJlA7IsieubzTGwOXqp5qbCvllQDBE/XoW
Rf1QHXJFPtAiEj4AEOgJgvgY8UjsKB2cIMkrS5ccZmvh6exah8CYxPL/XXeeLVX5E7REogiX
kL1mPvyztxUtwJ3RQNZQQCM19plG5G4aCXVafvKySFFW/eDGj8qKNSP3GKN1vEAn8PMpoaNY
qZeKHhqcuWBVe+diZhAQIzgqFrlOl+gWZYEOhnCqkX3ESc5hfIJtIcSlvL3kAK4/axJNlhVI
DDoLn1d7ErePHg6ATzv3FqrC/IUBMgOLYpmt0bHr6gyLhNK6ct7NRCYy5YCzzkVSFHZtTyCP
/Wi1yRSqx6RQMGlQTTzzZ2UJaJyPLiCczX00vzypBP0FqCzFNJ9ebdAUCcpMyIHpQMacnIn5
rE48gmcLOkgpgceo7btPTH1w2BF/aiCIQ/397yZawXgI/MB9hlaex/xv5MNUHP5/s9vPYoMi
qgetT/DH5D8SfdMUwLC/lW0az+V+V/Za+hmnCpu6xtj0ZzgUfyr82v0r9mBZCPqxA+CSSIjh
7y336frSXPrxVVMyoNtU8u3ljSePq8+e55av5t8J3b1fFhWpmtrwNTjN783v89w+dqeLXp5i
j5rlFFRFFFpQgdM9j4+r7ePZytnynJJJxPKaxDqU4xpytl+hbEytpXlguoV5p1oPQmKyFy8y
2zQCOy5by0XWqqtVVaqqo1VVDv4zMlVXOvH6vw+v6vuevPZ6vb35D2g+xq8ufMG0lHKjfMRa
KEkxCJKmauczDoWpWwT2e7xAu8PFN9dAElSgBKIB1QExxXFqHIzqsxgQHmloPsDrphm14V21
uCUcjRndURypsh16imbqg1NI0MrTVONVLMaYQ0OsQsYNPmhqrmZzKJnVTLrqCshmsoiKRBwg
ddddP0tMNgEUhERwCOtvIUhEXyfHE8604Gsap7KhyttF2r999qvJ5XHbfJW6jSmxFtx376Ly
DUxajUVlbVvEpmzJItlLLVa3VVcr415AbpR873kTmtc4Ufq1pQr2Kc3DutFSau4bunJJXINR
GC7JZ5JiTbRBZjDPY0izAs5S2YyxV6jHnLsWQCiLoMMmu2TJFbzYfJUS6jerbFu8paotJFGb
lmZqyQtnGqFKFaNWuPUVUzcNEzbVkq8tNB1rk3bzTUcrK0q07XOOZWqimpWwZgp3WXeCxxYk
W2UwoVCqXeLijS2uZlVYWM50qq7iG27bbbbbbbdVVaznV5ujqhnAxtEAYiNRQeIzUO7vOqGo
yLK3lFZzLhcRpFEObyYZ2yryak0YDty5lJqSGGMus0sqXEWtCDNMoapYhzVLcCcVpUU1bfGn
KsxC6B0wKlFWoK23z4pAtsxImqeK8/P0O8nKe++Lh66MV1C2s7h9WCXG7a8yblcmVtRavLim
q5mcmairrHp2irymhoDq5jLOLgHd4AHhjc9+Z6En1QYrrp0pGvw7NfInbAH8yTj4JH9Eh8x/
M7UfgfM0hEaH8z4dD4WEB4pjY2NjY2NjZ8DD+WKVqN4lf9R7PouVpGn9hBYMc0oxwnrCdu3x
j1YRt+h0DWFEGdZl8rSqYmBznxXmz8AkW4eJjPw2UUwg86FTpeWcuCM0wMCWHu78g6bzcf3P
dQ/OFWToleFTP8SKfenbLd9bkC0isgQIFNDDXu65xt4uQPh7cFDJQ9x3fA4/OAbSpcgDwVSC
pWxoZL+0WIjtLw31TsWLY6Lng9kKCpEPMtl0lD2ur8nZ87s1OcWi5wNQ5TkJSISxZQ0M8b9G
pHBLwHcbfmKkM6Q97aYOtGcAeQGD18JSUDKS0uo3e+ep/xQYKX68sv7mgDQwmAiJa6hVrepv
zLNxdaE82SHppIps4Gthrh4O9RrXNHGshPhzlHPFT5uQdpEc+HFOxEKm81APXQhBcYLLbr2Z
RANMNJX9m6pbnJkIyYabqPJ+DCzWnLEmlGJrj4BJPQSqHLJAV1K9PN5NXweq9e/W8EcDEIMI
JCDDx3pHoE7ghxOMeIXxGROGiKHCZHiwL2jImj1vyWdeRVTOHAqSzNV7DST1/H6np7xOIz7i
IfDOo63LwsO3AToHJVveCrQ5CVD+JK8ZVQc799zBCDkDmQdOHFkRFORxKVrH/jFOJG1CHsP0
4RFeyomI8j31+8t5MUoQTHp7ghyuMbNK/SzMQiBCgBXaNUwDw58q4+0px31QBLqzvZMwLT43
3T9MobdZAoHCRDl5Z2c5K8OezeK6LKZi4h+vmzyEQ0rNNDTabFeq1unhZe0tSauykkIXzzc1
4A1DhGZ9KMcCIiqqIh7jtRruYaD1ZK4xilH5Ji/d76hj8r2/qQP7QAwYzJSz6QBYAp3MltuI
sbYWBWFQlJFTyy/bTeLO+JbRdi8YRDX1wD8Zv6oGsoUPOVTZ3D0BBkJBhAVYIEVsGxooYatL
FIRuDTzkqA3VeiQRJPcfVPwGYQBMohkPtNdjYARD1eDccM8GQxJxrdSiY/r6jpED1KMEHUKd
9RyzJf4sEONneB6Wgj62pIGZA91kh9DJ21bbbbbbaG9J6h4zJDPgE+M58bgujUhZ2EhxosGE
YpPOklakOwm6EmWRM2BOEmGDUCoodUdUyg3Qg2PABna8AxUTT1HjwAqe5DAoM5Fati4YImRX
CIS+u4bLaN4xW5nFzwSPW9hemy/fN6eOYFQXGrAPzNxN2sLKDOkUx468w3Ei8le6Cb2CurqI
B58Q3pjBHoBU+l4MLOvYI7a0F7dur0SzqAlVppPQ6c1y8o7QoCCoQ26ig89BviOhinG3uE9Z
BxjdFCDJliZrYE7cNuB52JxFcjUc+YeWfGaZ6LpyvLZ8/jcp4YlvKmKByKAFDSWdbYRf+JqA
xFjCLrvCiWpS2PZPTfPT8kL92+nrD4TvvaINohZSzvRzgq0xNMMYASNfxoMHKgorughotJCB
0qjGlnpCKFgI9tlnjmJZ3yDdtop3qqyMHpt7iDLK9oxETlaqpRIUxo9qJAqSjYCCWSrgaApW
M8Kgs9NUaPVXsoIWD0Q4oDfTwR9U7UjSMeK7EPHrU8pnI9k6e4d4sbl1AqJt+TObDUs6zBqZ
GeZzG4MYnTsPWlCJCRJwnI3Bzm2eemRJY6rLDNjzZOZE1OOunxK3Bi+6a7mjp56lj0QyAvti
qkg6J50Ugv7iSAHgMDwdn9nIb1OUHdZADvNIKpDPOsVrxmqrUukyhaYcbR1KCv5JOTOgV1yB
iMAxhFPm3qZKSiARfbAoteaLgjLWFpihRrTPHy0SoAx1itkOgN4NYt0z5iVCxWMtfgcZ6+1B
mLeZiIDckwnlkDb7O9W0DIpVoNdjrMMFFiBFhH49ENwcMekKWQBxcC6tgcFvFUrgeBDKqwLs
AVkJDpraVPng7Q6kdaLSagPDt8KE8ftiSzv61h4K7bHp+Qzw1SQcblk66cfv6GpakHZ5YVrX
WCQAQhEiW+iMAeIDFP25+f4zUjU4JDzCQstpIZ4Hl53NQ5ExDpA3IaneYIXq2ag/freiB4kC
+yXDHpbXvPxi3HcbcaYI9e2UylvYk8pzNk0kN1O/11bigcoKfdWtKVIVBDGYKwb0wwwJHz8B
2IQNEEDtQPj49iQvj4zRlzTXfy4daJhIVFMn9YRvRq8fQ1SK+QZiYd2aYJuAvm7SLJntwosC
GjFXHx1kLEQMRyvj3P08AEl7nDTPpnwG1HhFUiKfOywHsEaPusYv534XAh67nQltKE+SPx9e
yyYwfcJdjcXHPUOex6RwHdvj9jPG1Oz3qKqvNqqqcufGnbpsbbcY2HgVVFXhKqKxVY222wmX
hKyw7QXeg3IxDOxcp9yKbn9/2C+3qKL7ub7tymqAKhFgbBVd/c0pdyACh06WcmC/g9NNemkh
lPIiBJPQaeVttqk5QCJ8pnt/FMGW8VFVVUSaHLu8k6oSa7L5dPD7e4sfD83HG9t5nXz61q22
3GOOOk7/Cxtlvdz8ESqXw259t4iqdMUaqq6urE4AUczBlZQ59CB5e6Y9ETRYPQN2AwhL5o5Y
B8uSeYEZ/SgcgDFpN1Hpt1aeVyNmUboyTcgSK1AoW0CxFDCBZGdcVApiJt9VRNAkg0/F63NP
R+V0sABjpD4lUUBIySBxOuO4AxUQFn+eiukPcsUgVi5rZAVHK+y3QRLvk0DP30Mbk3nhDdLA
W8wmCBYoGtjKBO3BAMxNegDAJmZpIhq9udhkV+vD6YOF+4+k1ZCXGCeQEiag3lAHcL80xQAd
QJ2ngoHlV7QIP1Ecjxkov8p5LhcuihrAIB4fGbooRAv1fXqocLoBPNXKytG7eUZwTIPPktC7
QgLGde/wHvJYgkBeZnqsRiBEYmwkONgfLBGRMTmDIVBkoegMyIAhfIQxARDKAdG+oV4ZL2e2
i6GcKyfOMmGYQ74sr6jIaSUhDhseRkkAdgZvR1yPw34+zgdM4reHmMaSMimUPmJQFq4OJSjL
Neeq/PEK7E76+BWkkYObLsgMVQ0dyKEXQZ7/JpL9ALpSiwBFsBhQpDswW7v9iKnz6l+A7syQ
8NI3I3CD2QhQ2Ntk29EqWM/TvPwQMLVFsMBthRgCkGlIfOH7mD4shN9wDxmSy3ZvEHDym77Y
lduNhTWmeFVVy7R43inSIe5YC4phJfZOZGAkijAS5Y9B+UPt9D3lwQG++82mzgvf3+fuqOZn
TER4Y0PcYwJTecYCh5hcX31wwi7Ixph+bhfsvCDhwQYjIjlSnK1UqHz3Dfp6mERMZaS0ioiM
4wYwaZRTAVbMUq4aMjMCWatEA76U35fD93r6vVLA2QgZf1QBuC6FnOZuBFoos/BFGYRCRb4R
IGH5j32QdKl2YG7OfKwh5amKScje6m9S+agiEPEa97sK15F1MB+wwsY3ZKAly9hNYBE+WTMd
psaPslPze7zdH5qcQ2UHZRYyNPhte0bmqoGt6cLn1oWd7h3d81xBAES0kRqzovHp2WdNw1iZ
ZJPg15roXd2Q7E1r52HeIhNKXfjSN4fb+rFDrihnh1nYbeQHrAXCKrPD/yUB6oIbTRrIQmR2
nK1g2tG1/MYOTyoJjfLvGQTsSBJkyplmShdYiyuuPOyi1RQjuI5FFQYbMKMFFkZFthsGIFnE
aSwZ1TAmG91+new2kFTSGzCiZYKew1D+ZAnrIwdQ3X4g41AzAuZJS0KEhZSygGTJIJCQ2+NE
K0VzUrDFAsOKpYbiCGpYDhnuubMFfGJJqKLEAL6XFDLh02Jn0t4r0bTdZEb9oomzqQbpWnPx
7Q3FwoKjhNqsyQja9FwbmBhVopASAXhAboMQCoYITbmDqcBOkFU3i/2pUoRoImq1JabyDzsV
VNoUBrgeYvWMr0hfaNKUnxa0YGYZ5GBwiZNKf6mWD3EKso+kq99FGsJpwQ6nybX0l3bn3Kwf
EaNMUMM2+GABgF5SDNb11ukgdaZpAYGQtR7qFIgjt6KY9FA38f/j7bxYFxzPNSAaBlVECDGC
SM+Ppz1vy9hwF7y1Cko7Q4bPQf6dldrUpVMI7IyHK/VQYxINh2fVZHsxYGfJjF+umPP2pGIv
IGXMHuL6oDxQUO8o69gtuc+gH5xOQTsihEMYsQCLEnmgTZ9BCtmtcEgasv2p7Lhv8HETugnT
VGYFKgwSSNiJEjWTSW5IYEoEW6CZQ3CBZDAOcdoORfa/mXTpcQIjvSxIK0qtKCJpCFHXbQQ2
QMYHxQ12X8ksAqfQQ/lFB+pIFth5OxBD6qXaNY2ddbvEFg0ur3gDBAauEBDHXE368sNGqj46
um8oUG/L8pZZAzLQktES0SDaGg4xwibFW6ie3Gh+Agy/lgJjq6WHrF9ETVDuQcNaoHlj/bm9
QPs9txJJueVCoIvag2VFUCCMVFWNbUqL3EoUFICgIn5NGxhFvNcCkibApKKSistEtzQgbStm
p9Fj6s0vl9un69DYbeuMaHFTAVSEVY0MhXZS1RLGBVNFVO4bUvdfR8XXc4xHYBlIQV7dScQ4
hNAAsCHXBOUQC8yQmCRX4UJ44onFLwoqOxHr66RDc+vigJTyUew9ML4RBVBkoR8n5C+oDhfc
Hi02AxohIxygDOBiVGSCG856aBJIo5IPdzAdnJcgVLl0xdy55ArCSzrqtjancIQbqyqpiFBH
SqEbUhIpFkipFgOFuWfMRsq890AlSCTRHOVDMMkDDDp4dFnte/l/QhzRCfpz6MEOujavJEC8
EyCFIh1eCgsLpyg6Z2k4RQe+F3AngUDXUFnnrMqboiaEue/Wl7VI244hbNriCyLGFyUPkSfI
HRDy1saJ42GkgdB5d17dFUUjSo00FLt2wnP/hE9wYYG0Z4HZjkWYt6AuFtR9BKohI13CQGr4
DPoQjBEhrzwFTezrE0Zk5Met6h7m6nQSyDE1XpHCA7rg1qJ4VE4OvsCAGZ2KqKqw2PGBwyC9
3hme1NTqRYTLrKmYtoFndrWCJzZf0pDdqSm6lIhAhOMCioAUv9jYHvl6Eui0QwF5Z2zA4CUb
BAoECyCCEIXwEYgM8S5XRL53CFLEDjYBgnhdsp4aUeq5edOMjExMdrUvsCaQYdiwtC/IBcmo
b7SakM6DP1JrGSFku1ACD0EBTC2OBODZjIAQS9b0iBHgql8bkAFK4aGiCLu2dUqDO2+jkxAa
bMSkqZPUyBuGoCMcklZ7JCmbWA8Wg0qRofOBoGQGDe1s1uTWaOYLy4gFzsUNaULLeotrlDRn
bJNbQG7Kze1PRlmIc8E2rDegGcTEUpzQhWqAcyTAHmwOKk3jJAoRjBJp5AFdQxIBwjMDiGCQ
9Leqy2/eKAwEGe8kSqa4b+BtOFkihwpKEpApW97q8CerUDE+TQhb41/hfUQlkGGgWjFmZsUm
6v3AVjhUk2g0rZDKyD23oF780M4hvyvsvFEMMsLeJdgHAFxDzsGTKEbIIuLuUJFQyOLYZykg
NdWg2E1Iwp6W9QBIg7UhTJVnDQWAXUpE1iDMKdpCTL14gmQLEQ6p7cmrcnE0MISdDqmWyA/G
AYuRP5nXzN6dQpGLPGWmKBRtLtJI6IR7I/HLJIZDbEUN90rqg8FUa4UeYdnuEEA90gJkxeDV
ZQHVYsgzXPDAEqaw1CdDYhmn4fRc1PXwxfDghLEUuLhQCWcIqYFeSk82AHfgGyG8E3kBEDaB
MsJDOMnGTxGoE0IExFoJGAd9+vu61W+qiWFkIB+heQJW6a4lgLaB7g6KfZMQ2BRcv+kUBMoA
ECAhC/1/fRa6qhxNbSCS9hNNdoEnkH1YhO2fahq+fOta1PWBjhqLtvYQsGfF6cTOhL4bS9Ig
ekh48ewCBBdFD0vYR4I6RTYL/+LuSKcKEhkkp8Xg
--------------000806010101050806020801
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000806010101050806020801--


From xen-devel-bounces@lists.xen.org Sat Jun 09 00:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 00: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 1Sd9GY-00032p-L2; Sat, 09 Jun 2012 00:10: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 1Sd9GX-00032k-Rh
	for xen-devel@lists.xensource.com; Sat, 09 Jun 2012 00:10:54 +0000
Received: from [85.158.138.51:34366] by server-4.bemta-3.messagelabs.com id
	ED/14-13598-D8492DF4; Sat, 09 Jun 2012 00:10:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339200652!12862989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE5Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25429 invoked from network); 9 Jun 2012 00:10:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 00:10:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,739,1330905600"; d="scan'208";a="12921884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jun 2012 00:10:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 9 Jun 2012 01:10:40 +0100
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 1Sd9GK-0003Ih-Q5;
	Sat, 09 Jun 2012 00:10:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sd9GK-0000pC-Bx;
	Sat, 09 Jun 2012 01:10:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13026-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Jun 2012 01:10:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13026: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13026 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13026/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 09 00:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 00: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 1Sd9GY-00032p-L2; Sat, 09 Jun 2012 00:10: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 1Sd9GX-00032k-Rh
	for xen-devel@lists.xensource.com; Sat, 09 Jun 2012 00:10:54 +0000
Received: from [85.158.138.51:34366] by server-4.bemta-3.messagelabs.com id
	ED/14-13598-D8492DF4; Sat, 09 Jun 2012 00:10:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339200652!12862989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE5Njc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25429 invoked from network); 9 Jun 2012 00:10:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 00:10:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,739,1330905600"; d="scan'208";a="12921884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jun 2012 00:10:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 9 Jun 2012 01:10:40 +0100
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 1Sd9GK-0003Ih-Q5;
	Sat, 09 Jun 2012 00:10:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sd9GK-0000pC-Bx;
	Sat, 09 Jun 2012 01:10:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13026-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Jun 2012 01:10:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13026: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13026 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13026/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 09 08:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 08:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SdGpr-0004Yj-5K; Sat, 09 Jun 2012 08:15:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <1013338600@qq.com>) id 1SdGpp-0004Ye-CN
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 08:15:49 +0000
Received: from [85.158.139.83:14648] by server-5.bemta-5.messagelabs.com id
	FA/A1-04481-43603DF4; Sat, 09 Jun 2012 08:15:48 +0000
X-Env-Sender: 1013338600@qq.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339229747!25521773!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.8 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTkxOTU4\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTkxOTU4\n,FROM_EXCESS_BASE64,
	FROM_STARTS_WITH_NUMS,HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23425 invoked from network); 9 Jun 2012 08:15:47 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-11.tower-182.messagelabs.com with SMTP;
	9 Jun 2012 08:15:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1339229745; bh=HeW0VUzijEcDOBZVjNiT50U29ysEtNNxOL/4evl75eM=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=D4/JtbKYd8/Ldb1mq6bCEFExeNU7EX1hS+SN2mVfFT+RccFdItm5hi6nHgS8Y4rWi
	fmiAoUDmIPRRrG4230t8jWkNYiC0n0oUBIWf1g4LnxecpjHKGJsZ1O71DfWiDLa
X-QQ-SSF: 0000000000000040000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 221.204.181.68
X-QQ-STYLE: 
X-QQ-mid: webmail182t1339229743t4659671
From: "=?ISO-8859-1?B?Ynln?=" <1013338600@qq.com>
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Date: Sat, 9 Jun 2012 16:15:42 +0800
X-Priority: 3
Message-ID: <tencent_6E68F7DE3476DF173EC26FF4@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9043274942777126592=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============9043274942777126592==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4FD3062E_082B0060_50D0545E"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4FD3062E_082B0060_50D0545E
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

aGkgYWxsDQogIA0KIGkgd2FudCB0byBidWlsZCBoeGVuIGZvciB3aW5kb3dzLCBoZWxwIG1l
Lg0KICANCiB1c2UgbWluZ3cgb24gd2luZG93cy4NCiAgDQogeDg2LW1pbmd3MzItYnVpbGQu
c2g6IHVucGFja2luZyAvaG9tZS9UaGlua1BhZC94ZW4vdG9vbHMvY3Jvc3MtbWluZ3cvbWlu
Z3cvcGFja2ENCmdlcy9iaW51dGlscy0yLjE3LjUwLTIwMDYwNzE2LTEtc3JjLnRhci5neiAu
Li4gZG9uZS4NCmNyZWF0aW5nIGNhY2hlIC4vY29uZmlnLmNhY2hlDQpjaGVja2luZyBob3N0
IHN5c3RlbSB0eXBlLi4uIGk2ODYtcGMtbWluZ3czMg0KY2hlY2tpbmcgdGFyZ2V0IHN5c3Rl
bSB0eXBlLi4uIGkzODYtcGMtbWluZ3czMg0KY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUu
Li4gaTY4Ni1wYy1taW5ndzMyDQpjaGVja2luZyBmb3IgYSBCU0QgY29tcGF0aWJsZSBpbnN0
YWxsLi4uIC9iaW4vaW5zdGFsbCAtYw0KY2hlY2tpbmcgd2hldGhlciBsbiB3b3Jrcy4uLiB5
ZXMNCmNoZWNraW5nIHdoZXRoZXIgbG4gLXMgd29ya3MuLi4gbm8NCmNoZWNraW5nIGZvciBn
Y2MuLi4gZ2NjDQpjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIChnY2MgICkgd29y
a3MuLi4gbm8NCmNvbmZpZ3VyZTogZXJyb3I6IGluc3RhbGxhdGlvbiBvciBjb25maWd1cmF0
aW9uIHByb2JsZW06IEMgY29tcGlsZXIgY2Fubm90IGNyZWF0DQplIGV4ZWN1dGFibGVzLg0K
eDg2LW1pbmd3MzItYnVpbGQuc2g6IHVucmVjb3ZlcmFibGUgZXJyb3IgY29uZmlndXJpbmcg
YmludXRpbHMNCm1ha2VbM106ICoqKiBbbWluZ3cvLmJ1aWx0XSBFcnJvciAxDQptYWtlWzNd
OiBMZWF2aW5nIGRpcmVjdG9yeSBgL2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1p
bmd3Jw0KbWFrZVsyXTogKioqIFt0b29sc10gRXJyb3IgMg0KbWFrZVsyXTogTGVhdmluZyBk
aXJlY3RvcnkgYC9ob21lL1RoaW5rUGFkL3hlbi93aW5kb3dzJw0KbWFrZVsxXTogKioqIFt0
b29scy1kZXBdIEVycm9yIDINCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9U
aGlua1BhZC94ZW4vd2luZG93cycNCm1ha2U6ICoqKiBbZGlzdF0gRXJyb3IgMg0KDQogIA0K
IHUyMDANCiB0aGFua3Mh

------=_NextPart_4FD3062E_082B0060_50D0545E
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPmhpIGFsbDwvRElWPg0KPERJVj4mbmJz
cDs8L0RJVj4NCjxESVY+aSB3YW50IHRvIGJ1aWxkIGh4ZW4gZm9yIHdpbmRvd3MsIGhlbHAg
bWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj51c2UgbWluZ3cgb24gd2luZG93
cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPng4Ni1taW5ndzMyLWJ1aWxkLnNo
OiB1bnBhY2tpbmcgL2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3L21pbmd3
L3BhY2thPEJSPmdlcy9iaW51dGlscy0yLjE3LjUwLTIwMDYwNzE2LTEtc3JjLnRhci5neiAu
Li4gZG9uZS48QlI+Y3JlYXRpbmcgY2FjaGUgLi9jb25maWcuY2FjaGU8QlI+Y2hlY2tpbmcg
aG9zdCBzeXN0ZW0gdHlwZS4uLiBpNjg2LXBjLW1pbmd3MzI8QlI+Y2hlY2tpbmcgdGFyZ2V0
IHN5c3RlbSB0eXBlLi4uIGkzODYtcGMtbWluZ3czMjxCUj5jaGVja2luZyBidWlsZCBzeXN0
ZW0gdHlwZS4uLiBpNjg2LXBjLW1pbmd3MzI8QlI+Y2hlY2tpbmcgZm9yIGEgQlNEIGNvbXBh
dGlibGUgaW5zdGFsbC4uLiAvYmluL2luc3RhbGwgLWM8QlI+Y2hlY2tpbmcgd2hldGhlciBs
biB3b3Jrcy4uLiB5ZXM8QlI+Y2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3Jrcy4uLiBubzxC
Uj5jaGVja2luZyBmb3IgZ2NjLi4uIGdjYzxCUj5jaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv
bXBpbGVyIChnY2MmbmJzcDsgKSB3b3Jrcy4uLiBubzxCUj5jb25maWd1cmU6IGVycm9yOiBp
bnN0YWxsYXRpb24gb3IgY29uZmlndXJhdGlvbiBwcm9ibGVtOiBDIGNvbXBpbGVyIGNhbm5v
dCBjcmVhdDxCUj5lIGV4ZWN1dGFibGVzLjxCUj54ODYtbWluZ3czMi1idWlsZC5zaDogdW5y
ZWNvdmVyYWJsZSBlcnJvciBjb25maWd1cmluZyBiaW51dGlsczxCUj5tYWtlWzNdOiAqKiog
W21pbmd3Ly5idWlsdF0gRXJyb3IgMTxCUj5tYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBg
L2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3JzxCUj5tYWtlWzJdOiAqKiog
W3Rvb2xzXSBFcnJvciAyPEJSPm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9U
aGlua1BhZC94ZW4vd2luZG93cyc8QlI+bWFrZVsxXTogKioqIFt0b29scy1kZXBdIEVycm9y
IDI8QlI+bWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC9ob21lL1RoaW5rUGFkL3hlbi93
aW5kb3dzJzxCUj5tYWtlOiAqKiogW2Rpc3RdIEVycm9yIDI8QlI+PC9ESVY+DQo8RElWPiZu
YnNwOzwvRElWPg0KPERJVj51MjAwPC9ESVY+DQo8RElWPnRoYW5rcyE8L0RJVj4NCjxTVFlM
RT4jbWFpbENvbnRlbnRDb250YWluZXIgLnR4dCB7aGVpZ2h0OmF1dG87fTwvU1RZTEU+DQo8
L0RJVj4=

------=_NextPart_4FD3062E_082B0060_50D0545E--



--===============9043274942777126592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9043274942777126592==--



From xen-devel-bounces@lists.xen.org Sat Jun 09 08:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 08:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SdGpr-0004Yj-5K; Sat, 09 Jun 2012 08:15:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <1013338600@qq.com>) id 1SdGpp-0004Ye-CN
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 08:15:49 +0000
Received: from [85.158.139.83:14648] by server-5.bemta-5.messagelabs.com id
	FA/A1-04481-43603DF4; Sat, 09 Jun 2012 08:15:48 +0000
X-Env-Sender: 1013338600@qq.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339229747!25521773!1
X-Originating-IP: [64.71.138.44]
X-SpamReason: No, hits=2.8 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTkxOTU4\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDQgPT4gMTkxOTU4\n,FROM_EXCESS_BASE64,
	FROM_STARTS_WITH_NUMS,HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23425 invoked from network); 9 Jun 2012 08:15:47 -0000
Received: from smtpbg55.qq.com (HELO smtpbg55.qq.com) (64.71.138.44)
	by server-11.tower-182.messagelabs.com with SMTP;
	9 Jun 2012 08:15:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1339229745; bh=HeW0VUzijEcDOBZVjNiT50U29ysEtNNxOL/4evl75eM=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=D4/JtbKYd8/Ldb1mq6bCEFExeNU7EX1hS+SN2mVfFT+RccFdItm5hi6nHgS8Y4rWi
	fmiAoUDmIPRRrG4230t8jWkNYiC0n0oUBIWf1g4LnxecpjHKGJsZ1O71DfWiDLa
X-QQ-SSF: 0000000000000040000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 221.204.181.68
X-QQ-STYLE: 
X-QQ-mid: webmail182t1339229743t4659671
From: "=?ISO-8859-1?B?Ynln?=" <1013338600@qq.com>
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Date: Sat, 9 Jun 2012 16:15:42 +0800
X-Priority: 3
Message-ID: <tencent_6E68F7DE3476DF173EC26FF4@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9043274942777126592=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============9043274942777126592==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4FD3062E_082B0060_50D0545E"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4FD3062E_082B0060_50D0545E
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

aGkgYWxsDQogIA0KIGkgd2FudCB0byBidWlsZCBoeGVuIGZvciB3aW5kb3dzLCBoZWxwIG1l
Lg0KICANCiB1c2UgbWluZ3cgb24gd2luZG93cy4NCiAgDQogeDg2LW1pbmd3MzItYnVpbGQu
c2g6IHVucGFja2luZyAvaG9tZS9UaGlua1BhZC94ZW4vdG9vbHMvY3Jvc3MtbWluZ3cvbWlu
Z3cvcGFja2ENCmdlcy9iaW51dGlscy0yLjE3LjUwLTIwMDYwNzE2LTEtc3JjLnRhci5neiAu
Li4gZG9uZS4NCmNyZWF0aW5nIGNhY2hlIC4vY29uZmlnLmNhY2hlDQpjaGVja2luZyBob3N0
IHN5c3RlbSB0eXBlLi4uIGk2ODYtcGMtbWluZ3czMg0KY2hlY2tpbmcgdGFyZ2V0IHN5c3Rl
bSB0eXBlLi4uIGkzODYtcGMtbWluZ3czMg0KY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUu
Li4gaTY4Ni1wYy1taW5ndzMyDQpjaGVja2luZyBmb3IgYSBCU0QgY29tcGF0aWJsZSBpbnN0
YWxsLi4uIC9iaW4vaW5zdGFsbCAtYw0KY2hlY2tpbmcgd2hldGhlciBsbiB3b3Jrcy4uLiB5
ZXMNCmNoZWNraW5nIHdoZXRoZXIgbG4gLXMgd29ya3MuLi4gbm8NCmNoZWNraW5nIGZvciBn
Y2MuLi4gZ2NjDQpjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIChnY2MgICkgd29y
a3MuLi4gbm8NCmNvbmZpZ3VyZTogZXJyb3I6IGluc3RhbGxhdGlvbiBvciBjb25maWd1cmF0
aW9uIHByb2JsZW06IEMgY29tcGlsZXIgY2Fubm90IGNyZWF0DQplIGV4ZWN1dGFibGVzLg0K
eDg2LW1pbmd3MzItYnVpbGQuc2g6IHVucmVjb3ZlcmFibGUgZXJyb3IgY29uZmlndXJpbmcg
YmludXRpbHMNCm1ha2VbM106ICoqKiBbbWluZ3cvLmJ1aWx0XSBFcnJvciAxDQptYWtlWzNd
OiBMZWF2aW5nIGRpcmVjdG9yeSBgL2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1p
bmd3Jw0KbWFrZVsyXTogKioqIFt0b29sc10gRXJyb3IgMg0KbWFrZVsyXTogTGVhdmluZyBk
aXJlY3RvcnkgYC9ob21lL1RoaW5rUGFkL3hlbi93aW5kb3dzJw0KbWFrZVsxXTogKioqIFt0
b29scy1kZXBdIEVycm9yIDINCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9U
aGlua1BhZC94ZW4vd2luZG93cycNCm1ha2U6ICoqKiBbZGlzdF0gRXJyb3IgMg0KDQogIA0K
IHUyMDANCiB0aGFua3Mh

------=_NextPart_4FD3062E_082B0060_50D0545E
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPmhpIGFsbDwvRElWPg0KPERJVj4mbmJz
cDs8L0RJVj4NCjxESVY+aSB3YW50IHRvIGJ1aWxkIGh4ZW4gZm9yIHdpbmRvd3MsIGhlbHAg
bWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj51c2UgbWluZ3cgb24gd2luZG93
cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPng4Ni1taW5ndzMyLWJ1aWxkLnNo
OiB1bnBhY2tpbmcgL2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3L21pbmd3
L3BhY2thPEJSPmdlcy9iaW51dGlscy0yLjE3LjUwLTIwMDYwNzE2LTEtc3JjLnRhci5neiAu
Li4gZG9uZS48QlI+Y3JlYXRpbmcgY2FjaGUgLi9jb25maWcuY2FjaGU8QlI+Y2hlY2tpbmcg
aG9zdCBzeXN0ZW0gdHlwZS4uLiBpNjg2LXBjLW1pbmd3MzI8QlI+Y2hlY2tpbmcgdGFyZ2V0
IHN5c3RlbSB0eXBlLi4uIGkzODYtcGMtbWluZ3czMjxCUj5jaGVja2luZyBidWlsZCBzeXN0
ZW0gdHlwZS4uLiBpNjg2LXBjLW1pbmd3MzI8QlI+Y2hlY2tpbmcgZm9yIGEgQlNEIGNvbXBh
dGlibGUgaW5zdGFsbC4uLiAvYmluL2luc3RhbGwgLWM8QlI+Y2hlY2tpbmcgd2hldGhlciBs
biB3b3Jrcy4uLiB5ZXM8QlI+Y2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3Jrcy4uLiBubzxC
Uj5jaGVja2luZyBmb3IgZ2NjLi4uIGdjYzxCUj5jaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv
bXBpbGVyIChnY2MmbmJzcDsgKSB3b3Jrcy4uLiBubzxCUj5jb25maWd1cmU6IGVycm9yOiBp
bnN0YWxsYXRpb24gb3IgY29uZmlndXJhdGlvbiBwcm9ibGVtOiBDIGNvbXBpbGVyIGNhbm5v
dCBjcmVhdDxCUj5lIGV4ZWN1dGFibGVzLjxCUj54ODYtbWluZ3czMi1idWlsZC5zaDogdW5y
ZWNvdmVyYWJsZSBlcnJvciBjb25maWd1cmluZyBiaW51dGlsczxCUj5tYWtlWzNdOiAqKiog
W21pbmd3Ly5idWlsdF0gRXJyb3IgMTxCUj5tYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBg
L2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3JzxCUj5tYWtlWzJdOiAqKiog
W3Rvb2xzXSBFcnJvciAyPEJSPm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9U
aGlua1BhZC94ZW4vd2luZG93cyc8QlI+bWFrZVsxXTogKioqIFt0b29scy1kZXBdIEVycm9y
IDI8QlI+bWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC9ob21lL1RoaW5rUGFkL3hlbi93
aW5kb3dzJzxCUj5tYWtlOiAqKiogW2Rpc3RdIEVycm9yIDI8QlI+PC9ESVY+DQo8RElWPiZu
YnNwOzwvRElWPg0KPERJVj51MjAwPC9ESVY+DQo8RElWPnRoYW5rcyE8L0RJVj4NCjxTVFlM
RT4jbWFpbENvbnRlbnRDb250YWluZXIgLnR4dCB7aGVpZ2h0OmF1dG87fTwvU1RZTEU+DQo8
L0RJVj4=

------=_NextPart_4FD3062E_082B0060_50D0545E--



--===============9043274942777126592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9043274942777126592==--



From xen-devel-bounces@lists.xen.org Sat Jun 09 08:30:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 08:30: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 1SdH3V-0004iT-TA; Sat, 09 Jun 2012 08:29:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SdH3U-0004iO-0N
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 08:29:56 +0000
Received: from [193.109.254.147:63270] by server-2.bemta-14.messagelabs.com id
	D1/E0-27740-38903DF4; Sat, 09 Jun 2012 08:29:55 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339230593!3219479!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9165 invoked from network); 9 Jun 2012 08:29:53 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 08:29:53 -0000
Received: by wgbed3 with SMTP id ed3so1105068wgb.32
	for <xen-devel@lists.xen.org>; Sat, 09 Jun 2012 01:29:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=A5N6NMy7u/+i3x+4+4R7T7wLz3rnxWHi39bX/Lk7sFE=;
	b=PrQPacROfVhq9rUY8HZD8UcEofhpAtXwRHX5GyeHbmCFigAIwhY4u6VeYLcy56rLeR
	97zuzzU6VX2gXRZWl9oCy/u3/X1yg58fP9q4wi2opegLy9T443tsTNw+uUrrEPxIufAP
	FD29v410rxCZelXmYPPvpSLgp6PyN617vpIplsMaFrK+7JOapGQbqF4jEvgtyttSkiI1
	nKYtfa2Q4+0e/3nG8rI2FhJtRm6G5D/pFG+xDaC6GqiCINw3em/eLBBCvdou6toMKwdY
	4AvjxKsP4IbYEWBgNYotg8ZK2kpDLJco218Dn5FBAEJw4Ar6QDDVNkclGxz35YSMP9pu
	nS1w==
MIME-Version: 1.0
Received: by 10.216.217.228 with SMTP id i78mr2819494wep.126.1339230593554;
	Sat, 09 Jun 2012 01:29:53 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Sat, 9 Jun 2012 01:29:53 -0700 (PDT)
In-Reply-To: <4FD108050200007800085AD9@nat28.tlf.novell.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD108050200007800085AD9@nat28.tlf.novell.com>
Date: Sat, 9 Jun 2012 09:29:53 +0100
Message-ID: <CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4265326742506126052=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4265326742506126052==
Content-Type: multipart/alternative; boundary=00504502e0c7cd186904c205eb7b

--00504502e0c7cd186904c205eb7b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 7, 2012 at 7:59 PM, Jan Beulich <jbeulich@suse.com> wrote:

> >>> elahe shekuhi <e.shekuhi@gmail.com> 06/06/12 8:15 PM >>>
> >On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> Does migration fail in both directions? Or perhaps just from the
> >> newer to the older system (in which case I would guess you're
> >> not masking features properly on the newer one)?
> >>
> >
> >Yes, Migration failed in both directions, but the error in Xend.log is
> >different. When I do migrate VM from core 2 quad to core i7 machine the
> >error in Xend.log is
>
> Are you certain (i.e. is this really with the VM freshly started on the
> Core2
> system)? I ask because this ...
>

   Yes I'm certain that the VM freshly started on the Core2 system. When I
migrate the VM from Core2 to Core i7 I always see this error(i.e. "Couldn't
set eXtended States for vcpu0 (22 = Invalid argument): Internal error" ) in
the Xend.log on Core i7 machine.

>
> >[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn't
> >set eXtended States for vcpu0 (22 = Invalid argument): Internal error
>
> ... indicates that XSAVE state was available for the guest, but couldn't
> be restored, yet iirc Core2 doesn't know XSAVE yet.
>
> Irrespective of that you could try booting the hypervisors on both sides
> with "no-xsave" and see whether that makes things any better (i.e.
> work at least in one direction). But generally, if you opened an entry in
> our bugzilla for this, we'd tell you that migration is only supported
> between feature-identical machines, or at best with features masked
> to the common subset on both systems.
>


   Also, when I migrate a VM freshly started on the Core i7 system to core
2, I get another error in xend.log on core2 system(i.e. destination
system). The error is

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:3150)
XendDomainInfo.destroy: domid=2

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2465) Destroying device
model

[2012-06-07 12:03:31 30425] INFO (image:711) s1 device model terminated

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2472) Releasing devices

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing vif/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing vkbd/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vkbd, device = vkbd/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing console/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = console, device = console/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51728

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vfb/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2470) No device model

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2472) Releasing devices

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vif/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51728

[2012-06-07 12:03:32 30425] ERROR (XendCheckpoint:421) Device 51712 (vbd)
could not be connected. losetup /dev/loop0
/home/elahe/xen/images/sles11/disk0.raw failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 412, in restore
    wait_devs(dominfo)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 277, in wait_devs
    dominfo.waitForDevices() # Wait for backends to set up
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py",
line 1239, in waitForDevices
    self.getDeviceController(devclass).waitForDevices()
  File
"/usr/lib64/python2.7/site-packages/xen/xend/server/DevController.py", line
140, in waitForDevices
    return map(self.waitForDevice, self.deviceIDs())
  File
"/usr/lib64/python2.7/site-packages/xen/xend/server/DevController.py", line
168, in waitForDevice
    "%s" % (devid, self.deviceClass, err))
VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0
/home/elahe/xen/images/sles11/disk0.raw failed

[2012-06-07 12:03:32 30425] ERROR (XendDomain:1200) Restore failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line
1184, in domain_restore_fd
    dominfo = XendCheckpoint.restore(self, fd, paused=paused,
relocating=relocating)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 422, in restore
    raise exn
VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0
/home/elahe/xen/images/sles11/disk0.raw failed

Elahe,

>
> Jan
>
>

--00504502e0c7cd186904c205eb7b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">On Thu, Jun 7, 2012 at =
7:59 PM, Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:jbeulich@suse.=
com" target=3D"_blank">jbeulich@suse.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
&gt;&gt;&gt; elahe shekuhi &lt;<a href=3D"mailto:e.shekuhi@gmail.com">e.she=
kuhi@gmail.com</a>&gt; 06/06/12 8:15 PM &gt;&gt;&gt;<br>
<div class=3D"im">&gt;On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich &lt;<a hr=
ef=3D"mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
</div><div class=3D"im">&gt;&gt; Does migration fail in both directions? Or=
 perhaps just from the<br>
&gt;&gt; newer to the older system (in which case I would guess you&#39;re<=
br>
&gt;&gt; not masking features properly on the newer one)?<br>
&gt;&gt;<br>
&gt;<br>
&gt;Yes, Migration failed in both directions, but the error in Xend.log is<=
br>
&gt;different. When I do migrate VM from core 2 quad to core i7 machine the=
<br>
&gt;error in Xend.log is<br>
<br>
</div>Are you certain (i.e. is this really with the VM freshly started on t=
he Core2<br>
system)? I ask because this ...<br></blockquote><div><br>=A0=A0 Yes I&#39;m=
 certain that the VM freshly started on the Core2 system. When I migrate th=
e VM from Core2 to Core i7 I always see this error(i.e. &quot;Couldn&#39;t =
set eXtended States for vcpu0 (22 =3D Invalid argument): Internal error&quo=
t; ) in the Xend.log on Core i7 machine.<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
&gt;[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn&=
#39;t<br>
&gt;set eXtended States for vcpu0 (22 =3D Invalid argument): Internal error=
<br>
<br>
</div>... indicates that XSAVE state was available for the guest, but could=
n&#39;t<br>
be restored, yet iirc Core2 doesn&#39;t know XSAVE yet.<br>
<br>
Irrespective of that you could try booting the hypervisors on both sides<br=
>
with &quot;no-xsave&quot; and see whether that makes things any better (i.e=
.<br>
work at least in one direction). But generally, if you opened an entry in<b=
r>
our bugzilla for this, we&#39;d tell you that migration is only supported<b=
r>
between feature-identical machines, or at best with features masked<br>
to the common subset on both systems.<br></blockquote><div><br><br>=A0=A0 A=
lso, when I migrate a VM freshly started on the Core i7 system to core 2, I=
 get another error in xend.log on core2 system(i.e. destination system). Th=
e error is<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:3150) XendDomainInfo.=
destroy: domid=3D2<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo=
:2465) Destroying device model<br><br>[2012-06-07 12:03:31 30425] INFO (ima=
ge:711) s1 device model terminated<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2472) Releasing devic=
es<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing =
vif/0<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278) XendDo=
mainInfo.destroyDevice: deviceClass =3D vif, device =3D vif/0<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing vkbd/0=
<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278) XendDomainI=
nfo.destroyDevice: deviceClass =3D vkbd, device =3D vkbd/0<br><br>[2012-06-=
07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing console/0<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.=
destroyDevice: deviceClass =3D console, device =3D console/0<br><br>[2012-0=
6-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728<br><br>
[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.dest=
royDevice: deviceClass =3D vbd, device =3D vbd/51728<br><br>[2012-06-07 12:=
03:32 30425] DEBUG (XendDomainInfo:2478) Removing vfb/0<br><br>[2012-06-07 =
12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.destroyDevice: d=
eviceClass =3D vfb, device =3D vfb/0<br>
<br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2470) No device model=
<br><br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2472) Releasing d=
evices<br><br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Remov=
ing vif/0<br>
<br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.=
destroyDevice: deviceClass =3D vif, device =3D vif/0<br><br>[2012-06-07 12:=
03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728<br><br>[2012-06=
-07 12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.destroyDevic=
e: deviceClass =3D vbd, device =3D vbd/51728<br>
<br>[2012-06-07 12:03:32 30425] ERROR (XendCheckpoint:421) Device 51712 (vb=
d) could not be connected. losetup /dev/loop0 /home/elahe/xen/images/sles11=
/disk0.raw failed<br>Traceback (most recent call last):<br>=A0 File &quot;/=
usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py&quot;, line 41=
2, in restore<br>
=A0=A0=A0 wait_devs(dominfo)<br>=A0 File &quot;/usr/lib64/python2.7/site-pa=
ckages/xen/xend/XendCheckpoint.py&quot;, line 277, in wait_devs<br>=A0=A0=
=A0 dominfo.waitForDevices() # Wait for backends to set up<br>=A0 File &quo=
t;/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py&quot;, line=
 1239, in waitForDevices<br>
=A0=A0=A0 self.getDeviceController(devclass).waitForDevices()<br>=A0 File &=
quot;/usr/lib64/python2.7/site-packages/xen/xend/server/DevController.py&qu=
ot;, line 140, in waitForDevices<br>=A0=A0=A0 return map(self.waitForDevice=
, self.deviceIDs())<br>
=A0 File &quot;/usr/lib64/python2.7/site-packages/xen/xend/server/DevContro=
ller.py&quot;, line 168, in waitForDevice<br>=A0=A0=A0 &quot;%s&quot; % (de=
vid, self.deviceClass, err))<br>VmError: Device 51712 (vbd) could not be co=
nnected. losetup /dev/loop0 /home/elahe/xen/images/sles11/disk0.raw failed<=
br>
<br>[2012-06-07 12:03:32 30425] ERROR (XendDomain:1200) Restore failed<br>T=
raceback (most recent call last):<br>=A0 File &quot;/usr/lib64/python2.7/si=
te-packages/xen/xend/XendDomain.py&quot;, line 1184, in domain_restore_fd<b=
r>
=A0=A0=A0 dominfo =3D XendCheckpoint.restore(self, fd, paused=3Dpaused, rel=
ocating=3Drelocating)<br>=A0 File &quot;/usr/lib64/python2.7/site-packages/=
xen/xend/XendCheckpoint.py&quot;, line 422, in restore<br>=A0=A0=A0 raise e=
xn<br>VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop=
0 /home/elahe/xen/images/sles11/disk0.raw failed<br>
<br>Elahe,<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0=
pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--00504502e0c7cd186904c205eb7b--


--===============4265326742506126052==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4265326742506126052==--


From xen-devel-bounces@lists.xen.org Sat Jun 09 08:30:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 08:30: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 1SdH3V-0004iT-TA; Sat, 09 Jun 2012 08:29:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SdH3U-0004iO-0N
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 08:29:56 +0000
Received: from [193.109.254.147:63270] by server-2.bemta-14.messagelabs.com id
	D1/E0-27740-38903DF4; Sat, 09 Jun 2012 08:29:55 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339230593!3219479!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9165 invoked from network); 9 Jun 2012 08:29:53 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 08:29:53 -0000
Received: by wgbed3 with SMTP id ed3so1105068wgb.32
	for <xen-devel@lists.xen.org>; Sat, 09 Jun 2012 01:29:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=A5N6NMy7u/+i3x+4+4R7T7wLz3rnxWHi39bX/Lk7sFE=;
	b=PrQPacROfVhq9rUY8HZD8UcEofhpAtXwRHX5GyeHbmCFigAIwhY4u6VeYLcy56rLeR
	97zuzzU6VX2gXRZWl9oCy/u3/X1yg58fP9q4wi2opegLy9T443tsTNw+uUrrEPxIufAP
	FD29v410rxCZelXmYPPvpSLgp6PyN617vpIplsMaFrK+7JOapGQbqF4jEvgtyttSkiI1
	nKYtfa2Q4+0e/3nG8rI2FhJtRm6G5D/pFG+xDaC6GqiCINw3em/eLBBCvdou6toMKwdY
	4AvjxKsP4IbYEWBgNYotg8ZK2kpDLJco218Dn5FBAEJw4Ar6QDDVNkclGxz35YSMP9pu
	nS1w==
MIME-Version: 1.0
Received: by 10.216.217.228 with SMTP id i78mr2819494wep.126.1339230593554;
	Sat, 09 Jun 2012 01:29:53 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Sat, 9 Jun 2012 01:29:53 -0700 (PDT)
In-Reply-To: <4FD108050200007800085AD9@nat28.tlf.novell.com>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD108050200007800085AD9@nat28.tlf.novell.com>
Date: Sat, 9 Jun 2012 09:29:53 +0100
Message-ID: <CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4265326742506126052=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4265326742506126052==
Content-Type: multipart/alternative; boundary=00504502e0c7cd186904c205eb7b

--00504502e0c7cd186904c205eb7b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 7, 2012 at 7:59 PM, Jan Beulich <jbeulich@suse.com> wrote:

> >>> elahe shekuhi <e.shekuhi@gmail.com> 06/06/12 8:15 PM >>>
> >On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> Does migration fail in both directions? Or perhaps just from the
> >> newer to the older system (in which case I would guess you're
> >> not masking features properly on the newer one)?
> >>
> >
> >Yes, Migration failed in both directions, but the error in Xend.log is
> >different. When I do migrate VM from core 2 quad to core i7 machine the
> >error in Xend.log is
>
> Are you certain (i.e. is this really with the VM freshly started on the
> Core2
> system)? I ask because this ...
>

   Yes I'm certain that the VM freshly started on the Core2 system. When I
migrate the VM from Core2 to Core i7 I always see this error(i.e. "Couldn't
set eXtended States for vcpu0 (22 = Invalid argument): Internal error" ) in
the Xend.log on Core i7 machine.

>
> >[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn't
> >set eXtended States for vcpu0 (22 = Invalid argument): Internal error
>
> ... indicates that XSAVE state was available for the guest, but couldn't
> be restored, yet iirc Core2 doesn't know XSAVE yet.
>
> Irrespective of that you could try booting the hypervisors on both sides
> with "no-xsave" and see whether that makes things any better (i.e.
> work at least in one direction). But generally, if you opened an entry in
> our bugzilla for this, we'd tell you that migration is only supported
> between feature-identical machines, or at best with features masked
> to the common subset on both systems.
>


   Also, when I migrate a VM freshly started on the Core i7 system to core
2, I get another error in xend.log on core2 system(i.e. destination
system). The error is

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:3150)
XendDomainInfo.destroy: domid=2

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2465) Destroying device
model

[2012-06-07 12:03:31 30425] INFO (image:711) s1 device model terminated

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2472) Releasing devices

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing vif/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing vkbd/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vkbd, device = vkbd/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing console/0

[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = console, device = console/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51728

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vfb/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2470) No device model

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2472) Releasing devices

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vif/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728

[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278)
XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51728

[2012-06-07 12:03:32 30425] ERROR (XendCheckpoint:421) Device 51712 (vbd)
could not be connected. losetup /dev/loop0
/home/elahe/xen/images/sles11/disk0.raw failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 412, in restore
    wait_devs(dominfo)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 277, in wait_devs
    dominfo.waitForDevices() # Wait for backends to set up
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py",
line 1239, in waitForDevices
    self.getDeviceController(devclass).waitForDevices()
  File
"/usr/lib64/python2.7/site-packages/xen/xend/server/DevController.py", line
140, in waitForDevices
    return map(self.waitForDevice, self.deviceIDs())
  File
"/usr/lib64/python2.7/site-packages/xen/xend/server/DevController.py", line
168, in waitForDevice
    "%s" % (devid, self.deviceClass, err))
VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0
/home/elahe/xen/images/sles11/disk0.raw failed

[2012-06-07 12:03:32 30425] ERROR (XendDomain:1200) Restore failed
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line
1184, in domain_restore_fd
    dominfo = XendCheckpoint.restore(self, fd, paused=paused,
relocating=relocating)
  File "/usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py",
line 422, in restore
    raise exn
VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0
/home/elahe/xen/images/sles11/disk0.raw failed

Elahe,

>
> Jan
>
>

--00504502e0c7cd186904c205eb7b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">On Thu, Jun 7, 2012 at =
7:59 PM, Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:jbeulich@suse.=
com" target=3D"_blank">jbeulich@suse.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
&gt;&gt;&gt; elahe shekuhi &lt;<a href=3D"mailto:e.shekuhi@gmail.com">e.she=
kuhi@gmail.com</a>&gt; 06/06/12 8:15 PM &gt;&gt;&gt;<br>
<div class=3D"im">&gt;On Wed, Jun 6, 2012 at 8:41 AM, Jan Beulich &lt;<a hr=
ef=3D"mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
</div><div class=3D"im">&gt;&gt; Does migration fail in both directions? Or=
 perhaps just from the<br>
&gt;&gt; newer to the older system (in which case I would guess you&#39;re<=
br>
&gt;&gt; not masking features properly on the newer one)?<br>
&gt;&gt;<br>
&gt;<br>
&gt;Yes, Migration failed in both directions, but the error in Xend.log is<=
br>
&gt;different. When I do migrate VM from core 2 quad to core i7 machine the=
<br>
&gt;error in Xend.log is<br>
<br>
</div>Are you certain (i.e. is this really with the VM freshly started on t=
he Core2<br>
system)? I ask because this ...<br></blockquote><div><br>=A0=A0 Yes I&#39;m=
 certain that the VM freshly started on the Core2 system. When I migrate th=
e VM from Core2 to Core i7 I always see this error(i.e. &quot;Couldn&#39;t =
set eXtended States for vcpu0 (22 =3D Invalid argument): Internal error&quo=
t; ) in the Xend.log on Core i7 machine.<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
&gt;[2012-04-23 17:26:41 1405] INFO (XendCheckpoint:487) xc: error: Couldn&=
#39;t<br>
&gt;set eXtended States for vcpu0 (22 =3D Invalid argument): Internal error=
<br>
<br>
</div>... indicates that XSAVE state was available for the guest, but could=
n&#39;t<br>
be restored, yet iirc Core2 doesn&#39;t know XSAVE yet.<br>
<br>
Irrespective of that you could try booting the hypervisors on both sides<br=
>
with &quot;no-xsave&quot; and see whether that makes things any better (i.e=
.<br>
work at least in one direction). But generally, if you opened an entry in<b=
r>
our bugzilla for this, we&#39;d tell you that migration is only supported<b=
r>
between feature-identical machines, or at best with features masked<br>
to the common subset on both systems.<br></blockquote><div><br><br>=A0=A0 A=
lso, when I migrate a VM freshly started on the Core i7 system to core 2, I=
 get another error in xend.log on core2 system(i.e. destination system). Th=
e error is<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:3150) XendDomainInfo.=
destroy: domid=3D2<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo=
:2465) Destroying device model<br><br>[2012-06-07 12:03:31 30425] INFO (ima=
ge:711) s1 device model terminated<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2472) Releasing devic=
es<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing =
vif/0<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278) XendDo=
mainInfo.destroyDevice: deviceClass =3D vif, device =3D vif/0<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing vkbd/0=
<br><br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278) XendDomainI=
nfo.destroyDevice: deviceClass =3D vkbd, device =3D vkbd/0<br><br>[2012-06-=
07 12:03:31 30425] DEBUG (XendDomainInfo:2478) Removing console/0<br>
<br>[2012-06-07 12:03:31 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.=
destroyDevice: deviceClass =3D console, device =3D console/0<br><br>[2012-0=
6-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728<br><br>
[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.dest=
royDevice: deviceClass =3D vbd, device =3D vbd/51728<br><br>[2012-06-07 12:=
03:32 30425] DEBUG (XendDomainInfo:2478) Removing vfb/0<br><br>[2012-06-07 =
12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.destroyDevice: d=
eviceClass =3D vfb, device =3D vfb/0<br>
<br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2470) No device model=
<br><br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2472) Releasing d=
evices<br><br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:2478) Remov=
ing vif/0<br>
<br>[2012-06-07 12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.=
destroyDevice: deviceClass =3D vif, device =3D vif/0<br><br>[2012-06-07 12:=
03:32 30425] DEBUG (XendDomainInfo:2478) Removing vbd/51728<br><br>[2012-06=
-07 12:03:32 30425] DEBUG (XendDomainInfo:1278) XendDomainInfo.destroyDevic=
e: deviceClass =3D vbd, device =3D vbd/51728<br>
<br>[2012-06-07 12:03:32 30425] ERROR (XendCheckpoint:421) Device 51712 (vb=
d) could not be connected. losetup /dev/loop0 /home/elahe/xen/images/sles11=
/disk0.raw failed<br>Traceback (most recent call last):<br>=A0 File &quot;/=
usr/lib64/python2.7/site-packages/xen/xend/XendCheckpoint.py&quot;, line 41=
2, in restore<br>
=A0=A0=A0 wait_devs(dominfo)<br>=A0 File &quot;/usr/lib64/python2.7/site-pa=
ckages/xen/xend/XendCheckpoint.py&quot;, line 277, in wait_devs<br>=A0=A0=
=A0 dominfo.waitForDevices() # Wait for backends to set up<br>=A0 File &quo=
t;/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py&quot;, line=
 1239, in waitForDevices<br>
=A0=A0=A0 self.getDeviceController(devclass).waitForDevices()<br>=A0 File &=
quot;/usr/lib64/python2.7/site-packages/xen/xend/server/DevController.py&qu=
ot;, line 140, in waitForDevices<br>=A0=A0=A0 return map(self.waitForDevice=
, self.deviceIDs())<br>
=A0 File &quot;/usr/lib64/python2.7/site-packages/xen/xend/server/DevContro=
ller.py&quot;, line 168, in waitForDevice<br>=A0=A0=A0 &quot;%s&quot; % (de=
vid, self.deviceClass, err))<br>VmError: Device 51712 (vbd) could not be co=
nnected. losetup /dev/loop0 /home/elahe/xen/images/sles11/disk0.raw failed<=
br>
<br>[2012-06-07 12:03:32 30425] ERROR (XendDomain:1200) Restore failed<br>T=
raceback (most recent call last):<br>=A0 File &quot;/usr/lib64/python2.7/si=
te-packages/xen/xend/XendDomain.py&quot;, line 1184, in domain_restore_fd<b=
r>
=A0=A0=A0 dominfo =3D XendCheckpoint.restore(self, fd, paused=3Dpaused, rel=
ocating=3Drelocating)<br>=A0 File &quot;/usr/lib64/python2.7/site-packages/=
xen/xend/XendCheckpoint.py&quot;, line 422, in restore<br>=A0=A0=A0 raise e=
xn<br>VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop=
0 /home/elahe/xen/images/sles11/disk0.raw failed<br>
<br>Elahe,<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0=
pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--00504502e0c7cd186904c205eb7b--


--===============4265326742506126052==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4265326742506126052==--


From xen-devel-bounces@lists.xen.org Sat Jun 09 08:48:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 08:48: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 1SdHKb-0004yl-IN; Sat, 09 Jun 2012 08:47:37 +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 1SdHKZ-0004yg-8P
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 08:47:35 +0000
Received: from [85.158.139.83:60820] by server-4.bemta-5.messagelabs.com id
	FA/72-05858-6AD03DF4; Sat, 09 Jun 2012 08:47:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339231653!28793881!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEyMTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEyMTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14284 invoked from network); 9 Jun 2012 08:47:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jun 2012 08:47:34 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69n6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-11.vodafone-net.de [80.226.24.11])
	by smtp.strato.de (josoe mo5) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y018dao598VZz0 ;
	Sat, 9 Jun 2012 10:47:33 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 37DEC18638; Sat,  9 Jun 2012 10:47:31 +0200 (CEST)
Date: Sat, 9 Jun 2012 10:47:31 +0200
From: Olaf Hering <olaf@aepfle.de>
To: elahe shekuhi <e.shekuhi@gmail.com>
Message-ID: <20120609084731.GA27152@aepfle.de>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD108050200007800085AD9@nat28.tlf.novell.com>
	<CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jun 09, elahe shekuhi wrote:

> VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0 /home/
> elahe/xen/images/sles11/disk0.raw failed

Is the directory /home/elahe reachable from both hosts?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 09 08:48:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 08:48: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 1SdHKb-0004yl-IN; Sat, 09 Jun 2012 08:47:37 +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 1SdHKZ-0004yg-8P
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 08:47:35 +0000
Received: from [85.158.139.83:60820] by server-4.bemta-5.messagelabs.com id
	FA/72-05858-6AD03DF4; Sat, 09 Jun 2012 08:47:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339231653!28793881!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEyMTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzEyMTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14284 invoked from network); 9 Jun 2012 08:47:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jun 2012 08:47:34 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69n6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-11.vodafone-net.de [80.226.24.11])
	by smtp.strato.de (josoe mo5) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y018dao598VZz0 ;
	Sat, 9 Jun 2012 10:47:33 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 37DEC18638; Sat,  9 Jun 2012 10:47:31 +0200 (CEST)
Date: Sat, 9 Jun 2012 10:47:31 +0200
From: Olaf Hering <olaf@aepfle.de>
To: elahe shekuhi <e.shekuhi@gmail.com>
Message-ID: <20120609084731.GA27152@aepfle.de>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD108050200007800085AD9@nat28.tlf.novell.com>
	<CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jun 09, elahe shekuhi wrote:

> VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0 /home/
> elahe/xen/images/sles11/disk0.raw failed

Is the directory /home/elahe reachable from both hosts?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 09 09:55:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 09:55: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 1SdINA-0005Sx-Vj; Sat, 09 Jun 2012 09:54:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SdIN9-0005Ss-5R
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 09:54:19 +0000
Received: from [85.158.143.99:4449] by server-3.bemta-4.messagelabs.com id
	C5/68-29237-A4D13DF4; Sat, 09 Jun 2012 09:54:18 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339235657!31132669!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30703 invoked from network); 9 Jun 2012 09:54:17 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 09:54:17 -0000
Received: by werf3 with SMTP id f3so1351251wer.32
	for <xen-devel@lists.xen.org>; Sat, 09 Jun 2012 02:54:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=YbeM4Pb3E6kr46Pa+4RV5GZnrhiA3Fc1Nuv0+YVqbIU=;
	b=hYhAUY1XhR98rudi2PpRkiU4yd3Py536XpJIq/RhO8z6VbbIElCfeCT5eO+Ca1lk7T
	9amshzOv+cJiMrHkgBK6kd7z7wrQK7CM0+ou7bLCICKBpM6uWAa/sETQullkMJWifO8K
	GWYtWRJzqbEKLnrlFRqNqMsV+D+hZiN6DIwwzToWmi7xl1McFlFchMemnMjEAUwoA/vI
	d/hyN5MK023/OS6pHCgafhfEufJc8K3+SwOvebERLC9sXdOWeUef8MmLVLfvUA2E8WPv
	+mumSwFMhcVyXVvOuw0u9NiGPp0Y8nZHmNYk/lHoOzOqIdfP6m2sFBlJgolKbwNBfTB0
	FCxw==
MIME-Version: 1.0
Received: by 10.180.92.69 with SMTP id ck5mr6927722wib.14.1339235657218; Sat,
	09 Jun 2012 02:54:17 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Sat, 9 Jun 2012 02:54:17 -0700 (PDT)
In-Reply-To: <20120609084731.GA27152@aepfle.de>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD108050200007800085AD9@nat28.tlf.novell.com>
	<CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
	<20120609084731.GA27152@aepfle.de>
Date: Sat, 9 Jun 2012 10:54:17 +0100
Message-ID: <CAFuBCaj0jkiQtF24RsWCY7Ob1VAAX-bk7wbFkYa_HFLubgL92A@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4761229345985688435=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4761229345985688435==
Content-Type: multipart/alternative; boundary=20cf306847399e7a2a04c2071997

--20cf306847399e7a2a04c2071997
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jun 9, 2012 at 9:47 AM, Olaf Hering <olaf@aepfle.de> wrote:

> On Sat, Jun 09, elahe shekuhi wrote:
>
> > VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0
> /home/
> > elahe/xen/images/sles11/disk0.raw failed
>
> Is the directory /home/elahe reachable from both hosts?
>

   Yes, it is using nfs4.

>
> Olaf
>

--20cf306847399e7a2a04c2071997
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">On Sat, Jun 9, 2012 at =
9:47 AM, Olaf Hering <span dir=3D"ltr">&lt;<a href=3D"mailto:olaf@aepfle.de=
" target=3D"_blank">olaf@aepfle.de</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div class=3D"im">On Sat, Jun 09, elahe shekuhi wrote:<br>
<br>
&gt; VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0=
 /home/<br>
&gt; elahe/xen/images/sles11/disk0.raw failed<br>
<br>
</div>Is the directory /home/elahe reachable from both hosts?<br></blockquo=
te><div><br>=A0=A0 Yes, it is using nfs4. <br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Olaf<br>
</font></span></blockquote></div><br></div>

--20cf306847399e7a2a04c2071997--


--===============4761229345985688435==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4761229345985688435==--


From xen-devel-bounces@lists.xen.org Sat Jun 09 09:55:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 09:55: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 1SdINA-0005Sx-Vj; Sat, 09 Jun 2012 09:54:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <e.shekuhi@gmail.com>) id 1SdIN9-0005Ss-5R
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 09:54:19 +0000
Received: from [85.158.143.99:4449] by server-3.bemta-4.messagelabs.com id
	C5/68-29237-A4D13DF4; Sat, 09 Jun 2012 09:54:18 +0000
X-Env-Sender: e.shekuhi@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339235657!31132669!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30703 invoked from network); 9 Jun 2012 09:54:17 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 09:54:17 -0000
Received: by werf3 with SMTP id f3so1351251wer.32
	for <xen-devel@lists.xen.org>; Sat, 09 Jun 2012 02:54:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=YbeM4Pb3E6kr46Pa+4RV5GZnrhiA3Fc1Nuv0+YVqbIU=;
	b=hYhAUY1XhR98rudi2PpRkiU4yd3Py536XpJIq/RhO8z6VbbIElCfeCT5eO+Ca1lk7T
	9amshzOv+cJiMrHkgBK6kd7z7wrQK7CM0+ou7bLCICKBpM6uWAa/sETQullkMJWifO8K
	GWYtWRJzqbEKLnrlFRqNqMsV+D+hZiN6DIwwzToWmi7xl1McFlFchMemnMjEAUwoA/vI
	d/hyN5MK023/OS6pHCgafhfEufJc8K3+SwOvebERLC9sXdOWeUef8MmLVLfvUA2E8WPv
	+mumSwFMhcVyXVvOuw0u9NiGPp0Y8nZHmNYk/lHoOzOqIdfP6m2sFBlJgolKbwNBfTB0
	FCxw==
MIME-Version: 1.0
Received: by 10.180.92.69 with SMTP id ck5mr6927722wib.14.1339235657218; Sat,
	09 Jun 2012 02:54:17 -0700 (PDT)
Received: by 10.216.222.201 with HTTP; Sat, 9 Jun 2012 02:54:17 -0700 (PDT)
In-Reply-To: <20120609084731.GA27152@aepfle.de>
References: <CAFuBCagmHxWteZk8DnXCWfTMaPLs7rxYkpBD=nSADjzKvbTNsA@mail.gmail.com>
	<4FCF25E7020000780008866D@nat28.tlf.novell.com>
	<CAFuBCaigYtC=fgJhLNjnaMC7hV-kvrg3i+pH+VW9N5Q72pkjXA@mail.gmail.com>
	<4FD108050200007800085AD9@nat28.tlf.novell.com>
	<CAFuBCajY+mSwuU_2rHuSBXVQYNrJ0hkE++gaM9f9+zP9oo65gg@mail.gmail.com>
	<20120609084731.GA27152@aepfle.de>
Date: Sat, 9 Jun 2012 10:54:17 +0100
Message-ID: <CAFuBCaj0jkiQtF24RsWCY7Ob1VAAX-bk7wbFkYa_HFLubgL92A@mail.gmail.com>
From: elahe shekuhi <e.shekuhi@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen live migration falied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4761229345985688435=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4761229345985688435==
Content-Type: multipart/alternative; boundary=20cf306847399e7a2a04c2071997

--20cf306847399e7a2a04c2071997
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jun 9, 2012 at 9:47 AM, Olaf Hering <olaf@aepfle.de> wrote:

> On Sat, Jun 09, elahe shekuhi wrote:
>
> > VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0
> /home/
> > elahe/xen/images/sles11/disk0.raw failed
>
> Is the directory /home/elahe reachable from both hosts?
>

   Yes, it is using nfs4.

>
> Olaf
>

--20cf306847399e7a2a04c2071997
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">On Sat, Jun 9, 2012 at =
9:47 AM, Olaf Hering <span dir=3D"ltr">&lt;<a href=3D"mailto:olaf@aepfle.de=
" target=3D"_blank">olaf@aepfle.de</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div class=3D"im">On Sat, Jun 09, elahe shekuhi wrote:<br>
<br>
&gt; VmError: Device 51712 (vbd) could not be connected. losetup /dev/loop0=
 /home/<br>
&gt; elahe/xen/images/sles11/disk0.raw failed<br>
<br>
</div>Is the directory /home/elahe reachable from both hosts?<br></blockquo=
te><div><br>=A0=A0 Yes, it is using nfs4. <br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Olaf<br>
</font></span></blockquote></div><br></div>

--20cf306847399e7a2a04c2071997--


--===============4761229345985688435==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4761229345985688435==--


From xen-devel-bounces@lists.xen.org Sat Jun 09 10:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 10: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 1SdITT-0005fB-Qs; Sat, 09 Jun 2012 10:00:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <1013338600@qq.com>) id 1SdITS-0005f6-2F
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 10:00:50 +0000
Received: from [85.158.143.35:31549] by server-2.bemta-4.messagelabs.com id
	63/9A-17938-1DE13DF4; Sat, 09 Jun 2012 10:00:49 +0000
X-Env-Sender: 1013338600@qq.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339236047!14509600!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjY0MDAw\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjY0MDAw\n,FROM_EXCESS_BASE64,
	FROM_STARTS_WITH_NUMS,HTML_30_40,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32180 invoked from network); 9 Jun 2012 10:00:48 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-13.tower-21.messagelabs.com with SMTP;
	9 Jun 2012 10:00:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1339236046; bh=IYgxPy/bmLwYTNGWEBmLRTH/vIoOALw9E6L7ulwLryQ=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=G0xh3T9ShQdujv+JZuehWUhlyam+290ucJjOjxMv7nq2UPHPYFa/pfMWIm606azBg
	/v6aTL8gdy0k/jI9/tPe/ewZCr0hbAKjUU9MR7Iy9CnS0Q3oaPWl9V8zPA1vYZt
X-QQ-SSF: 0000000000000040000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 221.204.181.68
X-QQ-STYLE: 
X-QQ-mid: webmail182t1339236044t1919555
From: "=?ISO-8859-1?B?Ynln?=" <1013338600@qq.com>
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Date: Sat, 9 Jun 2012 18:00:44 +0800
X-Priority: 3
Message-ID: <tencent_2FC3F760282EA33D432B99E5@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8428911802580705430=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============8428911802580705430==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4FD31ECC_086DDEA0_1284C992"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4FD31ECC_086DDEA0_1284C992
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

aGkgYWxsDQogIA0KIGkgd2FudCB0byBidWlsZCBoeGVuIGZvciB3aW5kb3dzLCBoZWxwIG1l
Lg0KICANCiB1c2UgbWluZ3cgb24gd2luZG93cy4NCiAgDQogY2hlY2tpbmcgd2hldGhlciB0
aGUgQyBjb21waWxlciAoZ2NjICApIHdvcmtzLi4uIG5vDQpjb25maWd1cmU6IGVycm9yOiBp
bnN0YWxsYXRpb24gb3IgY29uZmlndXJhdGlvbiBwcm9ibGVtOiBDIGNvbXBpbGVyIGNhbm5v
dCBjcmVhdGUgZXhlY3V0YWJsZXMuDQogIA0KIDtjb25maWcubG9nDQogY29uZmlndXJlOjE5
Nzk6IGdjYyAtbyBjb25mdGVzdCAgICBjb25mdGVzdC5jICAxPiY1DQovdXNyL2hvbWUvVGhp
bmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3L2J1aWxkLWJpbi9nY2M6IGxpbmUgMTQ6IGV4
ZWM6IC1vOiBpbnZhbGlkIG9wdGlvbg0KZXhlYzogdXNhZ2U6IGV4ZWMgWy1jbF0gWy1hIG5h
bWVdIGZpbGUgW3JlZGlyZWN0aW9uIC4uLl0NCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0g
d2FzOg0KICNsaW5lIDE5NzQgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29uZmRlZnMuaCIN
CiBtYWluKCl7cmV0dXJuKDApO30NCg0KIHUyMDANCiB0aGFua3Mh

------=_NextPart_4FD31ECC_086DDEA0_1284C992
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPmhpIGFsbDwvRElWPg0KPERJVj4mbmJz
cDs8L0RJVj4NCjxESVY+aSB3YW50IHRvIGJ1aWxkIGh4ZW4gZm9yIHdpbmRvd3MsIGhlbHAg
bWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj51c2UgbWluZ3cgb24gd2luZG93
cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmNoZWNraW5nIHdoZXRoZXIgdGhl
IEMgY29tcGlsZXIgKGdjYyZuYnNwOyApIHdvcmtzLi4uIG5vPEJSPmNvbmZpZ3VyZTogZXJy
b3I6IGluc3RhbGxhdGlvbiBvciBjb25maWd1cmF0aW9uIHByb2JsZW06IEMgY29tcGlsZXIg
Y2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8
RElWPjtjb25maWcubG9nPC9ESVY+DQo8RElWPmNvbmZpZ3VyZToxOTc5OiBnY2MgLW8gY29u
ZnRlc3QmbmJzcDsmbmJzcDsmbmJzcDsgY29uZnRlc3QuYyZuYnNwOyAxJmd0OyZhbXA7NTxC
Uj4vdXNyL2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3L2J1aWxkLWJpbi9n
Y2M6IGxpbmUgMTQ6IGV4ZWM6IC1vOiBpbnZhbGlkIG9wdGlvbjxCUj5leGVjOiB1c2FnZTog
ZXhlYyBbLWNsXSBbLWEgbmFtZV0gZmlsZSBbcmVkaXJlY3Rpb24gLi4uXTxCUj5jb25maWd1
cmU6IGZhaWxlZCBwcm9ncmFtIHdhczo8L0RJVj4NCjxESVY+I2xpbmUgMTk3NCAiY29uZmln
dXJlIjwvRElWPg0KPERJVj4jaW5jbHVkZSAiY29uZmRlZnMuaCI8L0RJVj4NCjxESVY+bWFp
bigpe3JldHVybigwKTt9PEJSPjwvRElWPg0KPERJVj51MjAwPC9ESVY+DQo8RElWPnRoYW5r
cyE8L0RJVj4NCjxTVFlMRT4jbWFpbENvbnRlbnRDb250YWluZXIgLnR4dCB7aGVpZ2h0OmF1
dG87fTwvU1RZTEU+DQo8L0RJVj4=

------=_NextPart_4FD31ECC_086DDEA0_1284C992--



--===============8428911802580705430==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8428911802580705430==--



From xen-devel-bounces@lists.xen.org Sat Jun 09 10:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 10: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 1SdITT-0005fB-Qs; Sat, 09 Jun 2012 10:00:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <1013338600@qq.com>) id 1SdITS-0005f6-2F
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 10:00:50 +0000
Received: from [85.158.143.35:31549] by server-2.bemta-4.messagelabs.com id
	63/9A-17938-1DE13DF4; Sat, 09 Jun 2012 10:00:49 +0000
X-Env-Sender: 1013338600@qq.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339236047!14509600!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjY0MDAw\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjY0MDAw\n,FROM_EXCESS_BASE64,
	FROM_STARTS_WITH_NUMS,HTML_30_40,HTML_MESSAGE,MIME_BASE64_TEXT,
	MIME_BOUND_NEXTPART,received_headers: No Received headers
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32180 invoked from network); 9 Jun 2012 10:00:48 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-13.tower-21.messagelabs.com with SMTP;
	9 Jun 2012 10:00:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1339236046; bh=IYgxPy/bmLwYTNGWEBmLRTH/vIoOALw9E6L7ulwLryQ=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=G0xh3T9ShQdujv+JZuehWUhlyam+290ucJjOjxMv7nq2UPHPYFa/pfMWIm606azBg
	/v6aTL8gdy0k/jI9/tPe/ewZCr0hbAKjUU9MR7Iy9CnS0Q3oaPWl9V8zPA1vYZt
X-QQ-SSF: 0000000000000040000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 221.204.181.68
X-QQ-STYLE: 
X-QQ-mid: webmail182t1339236044t1919555
From: "=?ISO-8859-1?B?Ynln?=" <1013338600@qq.com>
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Date: Sat, 9 Jun 2012 18:00:44 +0800
X-Priority: 3
Message-ID: <tencent_2FC3F760282EA33D432B99E5@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Subject: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8428911802580705430=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============8428911802580705430==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4FD31ECC_086DDEA0_1284C992"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4FD31ECC_086DDEA0_1284C992
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

aGkgYWxsDQogIA0KIGkgd2FudCB0byBidWlsZCBoeGVuIGZvciB3aW5kb3dzLCBoZWxwIG1l
Lg0KICANCiB1c2UgbWluZ3cgb24gd2luZG93cy4NCiAgDQogY2hlY2tpbmcgd2hldGhlciB0
aGUgQyBjb21waWxlciAoZ2NjICApIHdvcmtzLi4uIG5vDQpjb25maWd1cmU6IGVycm9yOiBp
bnN0YWxsYXRpb24gb3IgY29uZmlndXJhdGlvbiBwcm9ibGVtOiBDIGNvbXBpbGVyIGNhbm5v
dCBjcmVhdGUgZXhlY3V0YWJsZXMuDQogIA0KIDtjb25maWcubG9nDQogY29uZmlndXJlOjE5
Nzk6IGdjYyAtbyBjb25mdGVzdCAgICBjb25mdGVzdC5jICAxPiY1DQovdXNyL2hvbWUvVGhp
bmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3L2J1aWxkLWJpbi9nY2M6IGxpbmUgMTQ6IGV4
ZWM6IC1vOiBpbnZhbGlkIG9wdGlvbg0KZXhlYzogdXNhZ2U6IGV4ZWMgWy1jbF0gWy1hIG5h
bWVdIGZpbGUgW3JlZGlyZWN0aW9uIC4uLl0NCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0g
d2FzOg0KICNsaW5lIDE5NzQgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29uZmRlZnMuaCIN
CiBtYWluKCl7cmV0dXJuKDApO30NCg0KIHUyMDANCiB0aGFua3Mh

------=_NextPart_4FD31ECC_086DDEA0_1284C992
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPmhpIGFsbDwvRElWPg0KPERJVj4mbmJz
cDs8L0RJVj4NCjxESVY+aSB3YW50IHRvIGJ1aWxkIGh4ZW4gZm9yIHdpbmRvd3MsIGhlbHAg
bWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj51c2UgbWluZ3cgb24gd2luZG93
cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmNoZWNraW5nIHdoZXRoZXIgdGhl
IEMgY29tcGlsZXIgKGdjYyZuYnNwOyApIHdvcmtzLi4uIG5vPEJSPmNvbmZpZ3VyZTogZXJy
b3I6IGluc3RhbGxhdGlvbiBvciBjb25maWd1cmF0aW9uIHByb2JsZW06IEMgY29tcGlsZXIg
Y2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8
RElWPjtjb25maWcubG9nPC9ESVY+DQo8RElWPmNvbmZpZ3VyZToxOTc5OiBnY2MgLW8gY29u
ZnRlc3QmbmJzcDsmbmJzcDsmbmJzcDsgY29uZnRlc3QuYyZuYnNwOyAxJmd0OyZhbXA7NTxC
Uj4vdXNyL2hvbWUvVGhpbmtQYWQveGVuL3Rvb2xzL2Nyb3NzLW1pbmd3L2J1aWxkLWJpbi9n
Y2M6IGxpbmUgMTQ6IGV4ZWM6IC1vOiBpbnZhbGlkIG9wdGlvbjxCUj5leGVjOiB1c2FnZTog
ZXhlYyBbLWNsXSBbLWEgbmFtZV0gZmlsZSBbcmVkaXJlY3Rpb24gLi4uXTxCUj5jb25maWd1
cmU6IGZhaWxlZCBwcm9ncmFtIHdhczo8L0RJVj4NCjxESVY+I2xpbmUgMTk3NCAiY29uZmln
dXJlIjwvRElWPg0KPERJVj4jaW5jbHVkZSAiY29uZmRlZnMuaCI8L0RJVj4NCjxESVY+bWFp
bigpe3JldHVybigwKTt9PEJSPjwvRElWPg0KPERJVj51MjAwPC9ESVY+DQo8RElWPnRoYW5r
cyE8L0RJVj4NCjxTVFlMRT4jbWFpbENvbnRlbnRDb250YWluZXIgLnR4dCB7aGVpZ2h0OmF1
dG87fTwvU1RZTEU+DQo8L0RJVj4=

------=_NextPart_4FD31ECC_086DDEA0_1284C992--



--===============8428911802580705430==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8428911802580705430==--



From xen-devel-bounces@lists.xen.org Sat Jun 09 10:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 10: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 1SdJBT-00060z-FO; Sat, 09 Jun 2012 10:46:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1SdJBS-00060u-0u
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 10:46:18 +0000
Received: from [85.158.143.35:5255] by server-3.bemta-4.messagelabs.com id
	00/6A-29237-97923DF4; Sat, 09 Jun 2012 10:46:17 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339238775!8594435!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14325 invoked from network); 9 Jun 2012 10:46:16 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 10:46:16 -0000
Received: by pbbro12 with SMTP id ro12so3819423pbb.32
	for <xen-devel@lists.xen.org>; Sat, 09 Jun 2012 03:46:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=5iT50CBn4w3zrMHOsfZriq4h4gBJaP9bGb38H4Ibyos=;
	b=EmGIPGMlYJCGRQc1h98pQhj9tjeiKEGVxPBRGkH3mQv72lhOVsrRF1M2FMfZ4VFj9s
	axyRim2SmCzD9xwtMfo6f0Hr8z9QaeX3sOBsUEVwirGa6tgf9/CBrEsSj8Wwj3fkruE3
	rEOfhPdJYgtxeLUKg4ZOlnfLM8Z49ESOXHBK7g2mmnH0g4B9RWAlOoQX5KDIiaZQssT8
	VYJUocMkzjYGICaBnrhmpgZTQ8fUYGqh+L8r3Jo86MlGTlNT7YO/9/e9w/92ejauywcR
	Nt+PgjYl/EcIHgBUrdi1GQMM3y4kIXhp5F526jrWBZuYJGZsS+E37o24e8Yxhm+CvVxl
	nFHg==
MIME-Version: 1.0
Received: by 10.68.131.35 with SMTP id oj3mr4690397pbb.156.1339238774547; Sat,
	09 Jun 2012 03:46:14 -0700 (PDT)
Received: by 10.68.213.230 with HTTP; Sat, 9 Jun 2012 03:46:14 -0700 (PDT)
In-Reply-To: <tencent_2FC3F760282EA33D432B99E5@qq.com>
References: <tencent_2FC3F760282EA33D432B99E5@qq.com>
Date: Sat, 9 Jun 2012 17:46:14 +0700
Message-ID: <CAG1y0sc0bDmKFiAg0mW0YaHUkrLumn=FG9UkJhJU_XHN7szsYA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: byg <1013338600@qq.com>
X-Gm-Message-State: ALoCoQnkuN9kunRp/WLM79GIE8grjCI1YIdK6rqqGejwUnSLCCLVeLHd6HzLo5eefR5VZTnRULdD
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Jun 9, 2012 at 5:00 PM, byg <1013338600@qq.com> wrote:
>
> hi all
>
> i want to build hxen for windows, help me.
>
> use mingw on windows.
>
> checking whether the C compiler (gcc=A0 ) works... no
> configure: error: installation or configuration problem: C compiler cannot
> create executables.
>
> ;config.log
> configure:1979: gcc -o conftest=A0=A0=A0 conftest.c=A0 1>&5
> /usr/home/ThinkPad/xen/tools/cross-mingw/build-bin/gcc: line 14: exec: -o:
> invalid option
> exec: usage: exec [-cl] [-a name] file [redirection ...]
> configure: failed program was:
> #line 1974 "configure"
> #include "confdefs.h"
> main(){return(0);}
> u200
> thanks!


I don't think anyone is currently working on hxen. If you're just an
end user, better use something else.
If you want to try anyway, I suggest you look at your gcc
installation, cause it's failing at a basic command:

> configure:1979: gcc -o conftest=A0=A0=A0 conftest.c=A0 1>&5
> /usr/home/ThinkPad/xen/tools/cross-mingw/build-bin/gcc: line 14: exec: -o:
> invalid option

Was the file replaced by an incorrect shell script, perhaps?

-- =

Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 09 10:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 10: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 1SdJBT-00060z-FO; Sat, 09 Jun 2012 10:46:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1SdJBS-00060u-0u
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 10:46:18 +0000
Received: from [85.158.143.35:5255] by server-3.bemta-4.messagelabs.com id
	00/6A-29237-97923DF4; Sat, 09 Jun 2012 10:46:17 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339238775!8594435!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14325 invoked from network); 9 Jun 2012 10:46:16 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 10:46:16 -0000
Received: by pbbro12 with SMTP id ro12so3819423pbb.32
	for <xen-devel@lists.xen.org>; Sat, 09 Jun 2012 03:46:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-gm-message-state;
	bh=5iT50CBn4w3zrMHOsfZriq4h4gBJaP9bGb38H4Ibyos=;
	b=EmGIPGMlYJCGRQc1h98pQhj9tjeiKEGVxPBRGkH3mQv72lhOVsrRF1M2FMfZ4VFj9s
	axyRim2SmCzD9xwtMfo6f0Hr8z9QaeX3sOBsUEVwirGa6tgf9/CBrEsSj8Wwj3fkruE3
	rEOfhPdJYgtxeLUKg4ZOlnfLM8Z49ESOXHBK7g2mmnH0g4B9RWAlOoQX5KDIiaZQssT8
	VYJUocMkzjYGICaBnrhmpgZTQ8fUYGqh+L8r3Jo86MlGTlNT7YO/9/e9w/92ejauywcR
	Nt+PgjYl/EcIHgBUrdi1GQMM3y4kIXhp5F526jrWBZuYJGZsS+E37o24e8Yxhm+CvVxl
	nFHg==
MIME-Version: 1.0
Received: by 10.68.131.35 with SMTP id oj3mr4690397pbb.156.1339238774547; Sat,
	09 Jun 2012 03:46:14 -0700 (PDT)
Received: by 10.68.213.230 with HTTP; Sat, 9 Jun 2012 03:46:14 -0700 (PDT)
In-Reply-To: <tencent_2FC3F760282EA33D432B99E5@qq.com>
References: <tencent_2FC3F760282EA33D432B99E5@qq.com>
Date: Sat, 9 Jun 2012 17:46:14 +0700
Message-ID: <CAG1y0sc0bDmKFiAg0mW0YaHUkrLumn=FG9UkJhJU_XHN7szsYA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: byg <1013338600@qq.com>
X-Gm-Message-State: ALoCoQnkuN9kunRp/WLM79GIE8grjCI1YIdK6rqqGejwUnSLCCLVeLHd6HzLo5eefR5VZTnRULdD
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Jun 9, 2012 at 5:00 PM, byg <1013338600@qq.com> wrote:
>
> hi all
>
> i want to build hxen for windows, help me.
>
> use mingw on windows.
>
> checking whether the C compiler (gcc=A0 ) works... no
> configure: error: installation or configuration problem: C compiler cannot
> create executables.
>
> ;config.log
> configure:1979: gcc -o conftest=A0=A0=A0 conftest.c=A0 1>&5
> /usr/home/ThinkPad/xen/tools/cross-mingw/build-bin/gcc: line 14: exec: -o:
> invalid option
> exec: usage: exec [-cl] [-a name] file [redirection ...]
> configure: failed program was:
> #line 1974 "configure"
> #include "confdefs.h"
> main(){return(0);}
> u200
> thanks!


I don't think anyone is currently working on hxen. If you're just an
end user, better use something else.
If you want to try anyway, I suggest you look at your gcc
installation, cause it's failing at a basic command:

> configure:1979: gcc -o conftest=A0=A0=A0 conftest.c=A0 1>&5
> /usr/home/ThinkPad/xen/tools/cross-mingw/build-bin/gcc: line 14: exec: -o:
> invalid option

Was the file replaced by an incorrect shell script, perhaps?

-- =

Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 09 12:03:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 12: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 1SdKNU-0006Z3-SK; Sat, 09 Jun 2012 12:02:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SdKNT-0006Yw-R3
	for xen-devel@lists.xensource.com; Sat, 09 Jun 2012 12:02:48 +0000
Received: from [193.109.254.147:35273] by server-5.bemta-14.messagelabs.com id
	42/78-31398-76B33DF4; Sat, 09 Jun 2012 12:02:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339243366!1708489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE5NzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29853 invoked from network); 9 Jun 2012 12:02:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 12:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,741,1330905600"; d="scan'208";a="12924058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jun 2012 12:02:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 9 Jun 2012 13:02:45 +0100
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 1SdKNR-0007Di-JW;
	Sat, 09 Jun 2012 12:02:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SdKNR-0001iA-Gx;
	Sat, 09 Jun 2012 13:02:45 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13027-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Jun 2012 13:02:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13027: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13027 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13027/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2         fail pass in 13026

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 09 12:03:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Jun 2012 12: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 1SdKNU-0006Z3-SK; Sat, 09 Jun 2012 12:02:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SdKNT-0006Yw-R3
	for xen-devel@lists.xensource.com; Sat, 09 Jun 2012 12:02:48 +0000
Received: from [193.109.254.147:35273] by server-5.bemta-14.messagelabs.com id
	42/78-31398-76B33DF4; Sat, 09 Jun 2012 12:02:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339243366!1708489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE5NzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29853 invoked from network); 9 Jun 2012 12:02:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jun 2012 12:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,741,1330905600"; d="scan'208";a="12924058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jun 2012 12:02:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 9 Jun 2012 13:02:45 +0100
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 1SdKNR-0007Di-JW;
	Sat, 09 Jun 2012 12:02:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SdKNR-0001iA-Gx;
	Sat, 09 Jun 2012 13:02:45 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13027-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Jun 2012 13:02:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13027: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13027 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13027/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2         fail pass in 13026

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 03:42:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 03:42: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 1SdZ1t-0006yf-Vu; Sun, 10 Jun 2012 03:41:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <byg2@qq.com>)
	id 1SdE6H-0002Yh-7W
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 05:20:37 +0000
Received: from [85.158.139.83:47923] by server-5.bemta-5.messagelabs.com id
	DC/AE-04481-42DD2DF4; Sat, 09 Jun 2012 05:20:36 +0000
X-Env-Sender: byg2@qq.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339219233!28463765!1
X-Originating-IP: [183.60.2.223]
X-SpamReason: No, hits=1.2 required=7.0 tests=FROM_EXCESS_BASE64,
	HTML_MESSAGE,HTML_SHORT_COMMENT,MIME_BASE64_TEXT,MIME_BOUND_NEXTPART,
	received_headers: No Received headers
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10482 invoked from network); 9 Jun 2012 05:20:35 -0000
Received: from smtpbg220.qq.com (HELO smtpbg220.qq.com) (183.60.2.223)
	by server-14.tower-182.messagelabs.com with SMTP;
	9 Jun 2012 05:20:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1339219229; bh=rUcBxuykCn33kKXFd237QoeyqFzYT1/ceuK8/kEUPPQ=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=bzq6Tlh9ezcnV+jLmJFo4tmzzPE0RKtgyJBzoY55vU9R94L+AX0CvL8/yhGC1RQgC
	iChr6hHIJDwf/fFN2uJS3fY4ngSmNsazm4vUkYtvHIPgxGsm4fw5zbWjKGdA8wH
X-QQ-SSF: 0000000000000040000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 221.204.181.68
X-QQ-STYLE: 
X-QQ-mid: webmail182t1339219227t4703893
From: "=?ISO-8859-1?B?Ynln?=" <byg2@qq.com>
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Date: Sat, 9 Jun 2012 13:20:27 +0800
X-Priority: 3
Message-ID: <tencent_2D42FBC132F48914463F7003@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-Mailman-Approved-At: Sun, 10 Jun 2012 03:41:28 +0000
Subject: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0192186272878584365=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============0192186272878584365==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

aGkgYWxsDQogIA0KIGkgd2FudCB0byBidWlsZCBoeGVuIGZvciB3aW5kb3dzLCBoZWxwIG1l
Lg0KICANCiB1MjAwDQogdGhhbmtzIQ==

------=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPmhpIGFsbDwvRElWPg0KPERJVj4mbmJz
cDs8L0RJVj4NCjxESVY+aSB3YW50IHRvIGJ1aWxkIGh4ZW4gZm9yIHdpbmRvd3MsIGhlbHAg
bWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj51MjAwPC9ESVY+DQo8RElWPnRo
YW5rcyE8L0RJVj48IS0tIC0tPg0KPFNUWUxFPiNtYWlsQ29udGVudENvbnRhaW5lciAudHh0
IHtoZWlnaHQ6YXV0bzt9PC9TVFlMRT4NCg0KDQo8L0RJVj4=

------=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4--



--===============0192186272878584365==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0192186272878584365==--



From xen-devel-bounces@lists.xen.org Sun Jun 10 03:42:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 03:42: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 1SdZ1t-0006yf-Vu; Sun, 10 Jun 2012 03:41:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <byg2@qq.com>)
	id 1SdE6H-0002Yh-7W
	for xen-devel@lists.xen.org; Sat, 09 Jun 2012 05:20:37 +0000
Received: from [85.158.139.83:47923] by server-5.bemta-5.messagelabs.com id
	DC/AE-04481-42DD2DF4; Sat, 09 Jun 2012 05:20:36 +0000
X-Env-Sender: byg2@qq.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339219233!28463765!1
X-Originating-IP: [183.60.2.223]
X-SpamReason: No, hits=1.2 required=7.0 tests=FROM_EXCESS_BASE64,
	HTML_MESSAGE,HTML_SHORT_COMMENT,MIME_BASE64_TEXT,MIME_BOUND_NEXTPART,
	received_headers: No Received headers
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10482 invoked from network); 9 Jun 2012 05:20:35 -0000
Received: from smtpbg220.qq.com (HELO smtpbg220.qq.com) (183.60.2.223)
	by server-14.tower-182.messagelabs.com with SMTP;
	9 Jun 2012 05:20:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1339219229; bh=rUcBxuykCn33kKXFd237QoeyqFzYT1/ceuK8/kEUPPQ=;
	h=X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:
	X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=bzq6Tlh9ezcnV+jLmJFo4tmzzPE0RKtgyJBzoY55vU9R94L+AX0CvL8/yhGC1RQgC
	iChr6hHIJDwf/fFN2uJS3fY4ngSmNsazm4vUkYtvHIPgxGsm4fw5zbWjKGdA8wH
X-QQ-SSF: 0000000000000040000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 221.204.181.68
X-QQ-STYLE: 
X-QQ-mid: webmail182t1339219227t4703893
From: "=?ISO-8859-1?B?Ynln?=" <byg2@qq.com>
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Date: Sat, 9 Jun 2012 13:20:27 +0800
X-Priority: 3
Message-ID: <tencent_2D42FBC132F48914463F7003@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-Mailman-Approved-At: Sun, 10 Jun 2012 03:41:28 +0000
Subject: [Xen-devel] i want to build hxen for windows, help me.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0192186272878584365=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============0192186272878584365==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

aGkgYWxsDQogIA0KIGkgd2FudCB0byBidWlsZCBoeGVuIGZvciB3aW5kb3dzLCBoZWxwIG1l
Lg0KICANCiB1MjAwDQogdGhhbmtzIQ==

------=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPmhpIGFsbDwvRElWPg0KPERJVj4mbmJz
cDs8L0RJVj4NCjxESVY+aSB3YW50IHRvIGJ1aWxkIGh4ZW4gZm9yIHdpbmRvd3MsIGhlbHAg
bWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj51MjAwPC9ESVY+DQo8RElWPnRo
YW5rcyE8L0RJVj48IS0tIC0tPg0KPFNUWUxFPiNtYWlsQ29udGVudENvbnRhaW5lciAudHh0
IHtoZWlnaHQ6YXV0bzt9PC9TVFlMRT4NCg0KDQo8L0RJVj4=

------=_NextPart_4FD2DD1B_DD6CF310_62A4F7A4--



--===============0192186272878584365==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0192186272878584365==--



From xen-devel-bounces@lists.xen.org Sun Jun 10 03:42:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 03: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 1SdZ1t-0006yY-KA; Sun, 10 Jun 2012 03:41:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yoshink@alpha.co.jp>) id 1SczNS-00030C-Pz
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:37:23 +0000
Received: from [193.109.254.147:43696] by server-11.bemta-14.messagelabs.com
	id 49/4D-02727-21002DF4; Fri, 08 Jun 2012 13:37:22 +0000
X-Env-Sender: yoshink@alpha.co.jp
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339162638!8812950!1
X-Originating-IP: [219.127.235.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27956 invoked from network); 8 Jun 2012 13:37:20 -0000
Received: from mgw1.alpha.co.jp (HELO mgw1.alpha.co.jp) (219.127.235.68)
	by server-8.tower-27.messagelabs.com with SMTP;
	8 Jun 2012 13:37:20 -0000
Received: from (unknown [10.133.235.68]) by SPS-0013.alpha.co.jp with smtp
	id 1562_5205_44340844_b16f_11e1_ba39_001517fbe004;
	Fri, 08 Jun 2012 22:38:48 +0900
Received: from ms5.alpha.co.jp (ms5.alpha.co.jp [10.130.240.97])
	by mgw1.alpha.co.jp (Postfix) with ESMTP id 6F43CA7C5A4
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 22:37:14 +0900 (JST)
Received: from (unknown [10.130.240.97]) by SPS-0013.alpha.co.jp with smtp
	id 1568_7f15_43b164d4_b16f_11e1_bffb_001517fbe004;
	Fri, 08 Jun 2012 22:38:42 +0900
Received: from [10.146.176.222] (unknown [10.146.176.222])
	by ms5.alpha.co.jp (Postfix) with ESMTP id 4F5B9191C35A;
	Fri,  8 Jun 2012 22:37:14 +0900 (JST)
Message-ID: <4FD20009.7000302@alpha.co.jp>
Date: Fri, 08 Jun 2012 22:37:13 +0900
From: Kazuto Yoshino <yoshink@alpha.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org, yoshink@alpha.co.jp
X-Mailman-Approved-At: Sun, 10 Jun 2012 03:41:28 +0000
Subject: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 all,

SCSI passthrough of DVD drive is tried on Windows.
If vcpus=1 is used, it works.
However, if vcpus=2 is used, it does not work.
The log is as follows.


Hardware:
DELL Optiplex 990
Intel Core i5 2500


Software:
xen 4.2-unstable (25452:6bea63e6c780)
dom0: Linux 3.1.0-rc10+ 64bit
domU: Windows 7 SP1 64bit
GPLPV 0.10.0.357


domU config:
kernel = "hvmloader"
builder='hvm'
memory = 2048
name = "win7x64"
vcpus=2
vif = [ 'type=ioemu, mac=00:16:3e:19:18:7b, bridge=virbr0' ]
disk = [ 'file:/etc/xen/win7x64.img,hda,w' ]
device_model = 'qemu-dm'
sdl=0
opengl=1
vnc=1
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0


command:
# xm create /etc/xen/win7x64.hvm
# xm scsi-attach win7x64 1:0:0:0 2:0:0:0


qemu-dm log:
12983594247656: XenPCI --> XenPci_DeviceWatchHandler
12983594247656: XenPCI     Rescanning child list
12983594247656: XenPCI --> XenPci_EvtChildListScanForChildren
12983594247656: XenPCI     Found path = device/vbd/768
12983594247656: XenPCI     Found path = device/vif/0
12983594247671: XenPCI     Found path = device/vscsi/2
12983594247671: XenPCI <-- XenPci_EvtChildListScanForChildren
12983594247671: XenPCI --> XenPci_EvtChildListCreateDevice
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247671: XenPCI     device = 'vscsi', index = '2', path = 
'device/vscsi/2'
12983594247671: XenPCI --> XenPci_DeviceWatchHandler
12983594247671: XenPCI <-- XenPci_EvtChildListCreateDevice
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247671: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12983594247671: XenPCI --> XenPci_DeviceWatchHandler
12983594247671: XenPCI     device/vscsi/2
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247671: XenPCI     CmResourceTypeMemory (0)
12983594247671: XenPCI --> XenPci_DeviceWatchHandler
12983594247671: XenPCI     Start = f2000000, Length = 0
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247687: XenPCI     pfn[0] = 0000d445
12983594247687: XenPCI     New Start = 000000000d445000, Length = 4096
12983594247687: XenPCI     CmResourceTypeMemory (1)
12983594247687: XenPCI     Start = f2000001, Length = 0
12983594247687: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12983594247687: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12983594247687: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12983594247687: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12983594247687: XenPCI     path = device/vscsi/2
12983594247687: XenPCI     WdfPowerDeviceD3Final
12983594247687: XenPCI --> XenPci_GetBackendAndAddWatch
12983594247687: XenPCI <-- XenPci_GetBackendAndAddWatch
12983594247687: XenPCI --> XenPci_UpdateBackendState
12983594247687: XenPCI --> XenConfig_InitConfigPage
12983594247687: XenPCI     Backend State Changed to InitWait
12983594247687: XenPCI     fdo_driver_object = FFFFFA80025B9E70
12983594247687: XenPCI <-- XenPci_UpdateBackendState
12983594247687: XenPCI     fdo_driver_extension = FFFFFA8001869010
12983594247703: XenPCI <-- XenConfig_InitConfigPage
12983594247703: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8002AB9000
12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
12983594247703: XenPCI --> XenPci_DeviceWatchHandler
12983594247703: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8
12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
12983594247703: XenPCI --> EvtChn_BindIrq
12983594247703: XenPCI --> XenPci_DeviceWatchHandler
12983594247703: XenPCI <-- EvtChn_BindIrq
12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
12983594247703: XenPCI --> XenPci_ChangeFrontendStateMap
12983594247703: XenPCI --> XenPci_ChangeFrontendState
12983594247703: XenPCI --> XenPci_DeviceWatchHandler
12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
12983594247703: XenPCI --> XenPci_UpdateBackendState
12983594247718: XenPCI     Backend State Changed to Connected
12983594247718: XenPCI <-- XenPci_UpdateBackendState
12983594247718: XenPCI <-- XenPci_ChangeFrontendState
12983594247718: XenPCI <-- XenPci_ChangeFrontendStateMap
12983594247718: XenPCI --> XenPci_ChangeFrontendStateMap
12983594247718: XenPCI --> XenPci_ChangeFrontendState
12983594247734: XenPCI <-- XenPci_ChangeFrontendState
12983594247734: XenPCI --> XenPci_DeviceWatchHandler
12983594247734: XenPCI <-- XenPci_ChangeFrontendStateMap
12983594247734: XenPCI <-- XenPci_DeviceWatchHandler
12983594247734: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12983594247734: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12983594247734: XenSCSI --> XenScsi_HwScsiFindAdapter
12983594247734: XenSCSI     IRQL = 0
12983594247734: XenSCSI     BusInterruptLevel = 28
12983594247734: XenSCSI     BusInterruptVector = 01c
12983594247734: XenSCSI     RangeStart = 0d445000, RangeLength = 00001000
12983594247734: XenSCSI     XEN_INIT_TYPE_13
12983594247734: XenSCSI     XEN_INIT_TYPE_VECTORS
12983594247734: XenSCSI     XEN_INIT_TYPE_11
12983594247734: XenSCSI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8002AB9000
12983594247734: XenSCSI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8
12983594247750: XenSCSI     XEN_INIT_TYPE_GRANT_ENTRIES - 144
12983594247750: XenSCSI     Dma64BitAddresses supported
12983594247750: XenPCI --> XenPci_XenBus_AddWatch
12983594247750: XenPCI     XenPci_XenBus_AddWatch - 
/local/domain/0/backend/vscsi/3/2/vscsi-devs = NULL
12983594247750: XenSCSI --> XenScsi_DevWatch
12983594247750: XenPCI <-- XenPci_XenBus_AddWatch
12983594247750: XenSCSI     Waiting for pause...
12983594247750: XenSCSI <-- XenScsi_HwScsiFindAdapter
12983594247750: XenSCSI --> XenScsi_HwScsiInitialize
12983594247750: XenSCSI <-- XenScsi_HwScsiInitialize
12983594247750: XenSCSI --> XenScsi_HwScsiAdapterControl
12983594247750: XenSCSI     IRQL = 0
12983594247750: XenSCSI     ScsiQuerySupportedControlTypes (Max = 5)
12983594247750: XenSCSI <-- XenScsi_HwScsiAdapterControl
12983594247750: XenSCSI     Busy
12983594247859: XenSCSI     Waiting for pause...
12983594247968: XenSCSI     Waiting for pause...
12983594248078: XenSCSI     Waiting for pause...
12983594248187: XenSCSI     Waiting for pause...
12983594248296: XenSCSI     Waiting for pause...
12983594248406: XenSCSI     Waiting for pause...
12983594248515: XenSCSI     Waiting for pause...
12983594248625: XenSCSI     Waiting for pause...
12983594248734: XenSCSI     Waiting for pause...
12983594248843: XenSCSI     Waiting for pause...



It worked, when correcting the source code of GPLPV as follows.


--- a/xenscsi/xenscsi.c
+++ b/xenscsi/xenscsi.c
@@ -278,17 +278,27 @@
     /* this can only be called from a watch and so is always serialised */
     FUNCTION_ENTER();

-  #if DBG
-  oldpause =
-  #endif
-    InterlockedExchange(&xsdd->shared_paused, 
SHARED_PAUSED_PASSIVE_PAUSED);
-  ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
-
-  while (InterlockedCompareExchange(&xsdd->shared_paused, 
SHARED_PAUSED_SCSIPORT_PAUSED, SHARED_PAUSED_SCSIPORT_PAUSED) != 
SHARED_PAUSED_SCSIPORT_PAUSED)
+  while (1)
     {
-    KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
-    wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
-    KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
+    if (InterlockedCompareExchange(&xsdd->shared_paused, 
SHARED_PAUSED_SCSIPORT_UNPAUSED, SHARED_PAUSED_SCSIPORT_UNPAUSED) == 
SHARED_PAUSED_SCSIPORT_UNPAUSED)
+    {
+      #if DBG
+      oldpause =
+      #endif
+        InterlockedExchange(&xsdd->shared_paused, 
SHARED_PAUSED_PASSIVE_PAUSED);
+      ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
+    }
+
+    if (InterlockedCompareExchange(&xsdd->shared_paused, 
SHARED_PAUSED_SCSIPORT_PAUSED, SHARED_PAUSED_SCSIPORT_PAUSED) != 
SHARED_PAUSED_SCSIPORT_PAUSED)
+    {
+      KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
+      wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
+      KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
+    }
+    else
+    {
+      break;
+    }
     }

     KdPrint((__DRIVER_NAME "     Watch triggered on %s\n", path));


Thanks,
Kazuto Yoshino.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 03:42:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 03: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 1SdZ1t-0006yY-KA; Sun, 10 Jun 2012 03:41:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yoshink@alpha.co.jp>) id 1SczNS-00030C-Pz
	for xen-devel@lists.xen.org; Fri, 08 Jun 2012 13:37:23 +0000
Received: from [193.109.254.147:43696] by server-11.bemta-14.messagelabs.com
	id 49/4D-02727-21002DF4; Fri, 08 Jun 2012 13:37:22 +0000
X-Env-Sender: yoshink@alpha.co.jp
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339162638!8812950!1
X-Originating-IP: [219.127.235.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27956 invoked from network); 8 Jun 2012 13:37:20 -0000
Received: from mgw1.alpha.co.jp (HELO mgw1.alpha.co.jp) (219.127.235.68)
	by server-8.tower-27.messagelabs.com with SMTP;
	8 Jun 2012 13:37:20 -0000
Received: from (unknown [10.133.235.68]) by SPS-0013.alpha.co.jp with smtp
	id 1562_5205_44340844_b16f_11e1_ba39_001517fbe004;
	Fri, 08 Jun 2012 22:38:48 +0900
Received: from ms5.alpha.co.jp (ms5.alpha.co.jp [10.130.240.97])
	by mgw1.alpha.co.jp (Postfix) with ESMTP id 6F43CA7C5A4
	for <xen-devel@lists.xen.org>; Fri,  8 Jun 2012 22:37:14 +0900 (JST)
Received: from (unknown [10.130.240.97]) by SPS-0013.alpha.co.jp with smtp
	id 1568_7f15_43b164d4_b16f_11e1_bffb_001517fbe004;
	Fri, 08 Jun 2012 22:38:42 +0900
Received: from [10.146.176.222] (unknown [10.146.176.222])
	by ms5.alpha.co.jp (Postfix) with ESMTP id 4F5B9191C35A;
	Fri,  8 Jun 2012 22:37:14 +0900 (JST)
Message-ID: <4FD20009.7000302@alpha.co.jp>
Date: Fri, 08 Jun 2012 22:37:13 +0900
From: Kazuto Yoshino <yoshink@alpha.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org, yoshink@alpha.co.jp
X-Mailman-Approved-At: Sun, 10 Jun 2012 03:41:28 +0000
Subject: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 all,

SCSI passthrough of DVD drive is tried on Windows.
If vcpus=1 is used, it works.
However, if vcpus=2 is used, it does not work.
The log is as follows.


Hardware:
DELL Optiplex 990
Intel Core i5 2500


Software:
xen 4.2-unstable (25452:6bea63e6c780)
dom0: Linux 3.1.0-rc10+ 64bit
domU: Windows 7 SP1 64bit
GPLPV 0.10.0.357


domU config:
kernel = "hvmloader"
builder='hvm'
memory = 2048
name = "win7x64"
vcpus=2
vif = [ 'type=ioemu, mac=00:16:3e:19:18:7b, bridge=virbr0' ]
disk = [ 'file:/etc/xen/win7x64.img,hda,w' ]
device_model = 'qemu-dm'
sdl=0
opengl=1
vnc=1
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0


command:
# xm create /etc/xen/win7x64.hvm
# xm scsi-attach win7x64 1:0:0:0 2:0:0:0


qemu-dm log:
12983594247656: XenPCI --> XenPci_DeviceWatchHandler
12983594247656: XenPCI     Rescanning child list
12983594247656: XenPCI --> XenPci_EvtChildListScanForChildren
12983594247656: XenPCI     Found path = device/vbd/768
12983594247656: XenPCI     Found path = device/vif/0
12983594247671: XenPCI     Found path = device/vscsi/2
12983594247671: XenPCI <-- XenPci_EvtChildListScanForChildren
12983594247671: XenPCI --> XenPci_EvtChildListCreateDevice
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247671: XenPCI     device = 'vscsi', index = '2', path = 
'device/vscsi/2'
12983594247671: XenPCI --> XenPci_DeviceWatchHandler
12983594247671: XenPCI <-- XenPci_EvtChildListCreateDevice
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247671: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12983594247671: XenPCI --> XenPci_DeviceWatchHandler
12983594247671: XenPCI     device/vscsi/2
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247671: XenPCI     CmResourceTypeMemory (0)
12983594247671: XenPCI --> XenPci_DeviceWatchHandler
12983594247671: XenPCI     Start = f2000000, Length = 0
12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
12983594247687: XenPCI     pfn[0] = 0000d445
12983594247687: XenPCI     New Start = 000000000d445000, Length = 4096
12983594247687: XenPCI     CmResourceTypeMemory (1)
12983594247687: XenPCI     Start = f2000001, Length = 0
12983594247687: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12983594247687: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12983594247687: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12983594247687: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12983594247687: XenPCI     path = device/vscsi/2
12983594247687: XenPCI     WdfPowerDeviceD3Final
12983594247687: XenPCI --> XenPci_GetBackendAndAddWatch
12983594247687: XenPCI <-- XenPci_GetBackendAndAddWatch
12983594247687: XenPCI --> XenPci_UpdateBackendState
12983594247687: XenPCI --> XenConfig_InitConfigPage
12983594247687: XenPCI     Backend State Changed to InitWait
12983594247687: XenPCI     fdo_driver_object = FFFFFA80025B9E70
12983594247687: XenPCI <-- XenPci_UpdateBackendState
12983594247687: XenPCI     fdo_driver_extension = FFFFFA8001869010
12983594247703: XenPCI <-- XenConfig_InitConfigPage
12983594247703: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8002AB9000
12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
12983594247703: XenPCI --> XenPci_DeviceWatchHandler
12983594247703: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8
12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
12983594247703: XenPCI --> EvtChn_BindIrq
12983594247703: XenPCI --> XenPci_DeviceWatchHandler
12983594247703: XenPCI <-- EvtChn_BindIrq
12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
12983594247703: XenPCI --> XenPci_ChangeFrontendStateMap
12983594247703: XenPCI --> XenPci_ChangeFrontendState
12983594247703: XenPCI --> XenPci_DeviceWatchHandler
12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
12983594247703: XenPCI --> XenPci_UpdateBackendState
12983594247718: XenPCI     Backend State Changed to Connected
12983594247718: XenPCI <-- XenPci_UpdateBackendState
12983594247718: XenPCI <-- XenPci_ChangeFrontendState
12983594247718: XenPCI <-- XenPci_ChangeFrontendStateMap
12983594247718: XenPCI --> XenPci_ChangeFrontendStateMap
12983594247718: XenPCI --> XenPci_ChangeFrontendState
12983594247734: XenPCI <-- XenPci_ChangeFrontendState
12983594247734: XenPCI --> XenPci_DeviceWatchHandler
12983594247734: XenPCI <-- XenPci_ChangeFrontendStateMap
12983594247734: XenPCI <-- XenPci_DeviceWatchHandler
12983594247734: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12983594247734: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12983594247734: XenSCSI --> XenScsi_HwScsiFindAdapter
12983594247734: XenSCSI     IRQL = 0
12983594247734: XenSCSI     BusInterruptLevel = 28
12983594247734: XenSCSI     BusInterruptVector = 01c
12983594247734: XenSCSI     RangeStart = 0d445000, RangeLength = 00001000
12983594247734: XenSCSI     XEN_INIT_TYPE_13
12983594247734: XenSCSI     XEN_INIT_TYPE_VECTORS
12983594247734: XenSCSI     XEN_INIT_TYPE_11
12983594247734: XenSCSI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8002AB9000
12983594247734: XenSCSI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 8
12983594247750: XenSCSI     XEN_INIT_TYPE_GRANT_ENTRIES - 144
12983594247750: XenSCSI     Dma64BitAddresses supported
12983594247750: XenPCI --> XenPci_XenBus_AddWatch
12983594247750: XenPCI     XenPci_XenBus_AddWatch - 
/local/domain/0/backend/vscsi/3/2/vscsi-devs = NULL
12983594247750: XenSCSI --> XenScsi_DevWatch
12983594247750: XenPCI <-- XenPci_XenBus_AddWatch
12983594247750: XenSCSI     Waiting for pause...
12983594247750: XenSCSI <-- XenScsi_HwScsiFindAdapter
12983594247750: XenSCSI --> XenScsi_HwScsiInitialize
12983594247750: XenSCSI <-- XenScsi_HwScsiInitialize
12983594247750: XenSCSI --> XenScsi_HwScsiAdapterControl
12983594247750: XenSCSI     IRQL = 0
12983594247750: XenSCSI     ScsiQuerySupportedControlTypes (Max = 5)
12983594247750: XenSCSI <-- XenScsi_HwScsiAdapterControl
12983594247750: XenSCSI     Busy
12983594247859: XenSCSI     Waiting for pause...
12983594247968: XenSCSI     Waiting for pause...
12983594248078: XenSCSI     Waiting for pause...
12983594248187: XenSCSI     Waiting for pause...
12983594248296: XenSCSI     Waiting for pause...
12983594248406: XenSCSI     Waiting for pause...
12983594248515: XenSCSI     Waiting for pause...
12983594248625: XenSCSI     Waiting for pause...
12983594248734: XenSCSI     Waiting for pause...
12983594248843: XenSCSI     Waiting for pause...



It worked, when correcting the source code of GPLPV as follows.


--- a/xenscsi/xenscsi.c
+++ b/xenscsi/xenscsi.c
@@ -278,17 +278,27 @@
     /* this can only be called from a watch and so is always serialised */
     FUNCTION_ENTER();

-  #if DBG
-  oldpause =
-  #endif
-    InterlockedExchange(&xsdd->shared_paused, 
SHARED_PAUSED_PASSIVE_PAUSED);
-  ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
-
-  while (InterlockedCompareExchange(&xsdd->shared_paused, 
SHARED_PAUSED_SCSIPORT_PAUSED, SHARED_PAUSED_SCSIPORT_PAUSED) != 
SHARED_PAUSED_SCSIPORT_PAUSED)
+  while (1)
     {
-    KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
-    wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
-    KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
+    if (InterlockedCompareExchange(&xsdd->shared_paused, 
SHARED_PAUSED_SCSIPORT_UNPAUSED, SHARED_PAUSED_SCSIPORT_UNPAUSED) == 
SHARED_PAUSED_SCSIPORT_UNPAUSED)
+    {
+      #if DBG
+      oldpause =
+      #endif
+        InterlockedExchange(&xsdd->shared_paused, 
SHARED_PAUSED_PASSIVE_PAUSED);
+      ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
+    }
+
+    if (InterlockedCompareExchange(&xsdd->shared_paused, 
SHARED_PAUSED_SCSIPORT_PAUSED, SHARED_PAUSED_SCSIPORT_PAUSED) != 
SHARED_PAUSED_SCSIPORT_PAUSED)
+    {
+      KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
+      wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
+      KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
+    }
+    else
+    {
+      break;
+    }
     }

     KdPrint((__DRIVER_NAME "     Watch triggered on %s\n", path));


Thanks,
Kazuto Yoshino.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 03:42:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 03: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 1SdZ1u-0006ym-Bl; Sun, 10 Jun 2012 03:41:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1SdXVF-0006gH-DR
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 02:03:41 +0000
Received: from [85.158.139.83:56519] by server-4.bemta-5.messagelabs.com id
	DC/95-05858-C7004DF4; Sun, 10 Jun 2012 02:03:40 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339293818!31295200!1
X-Originating-IP: [209.85.216.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2927 invoked from network); 10 Jun 2012 02:03:39 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 02:03:39 -0000
Received: by qady23 with SMTP id y23so1974547qad.7
	for <xen-devel@lists.xensource.com>;
	Sat, 09 Jun 2012 19:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=r3L368o3GYmeawz4bzGqgtoKeESLAvh3MWLtuEvL1d4=;
	b=P9XzF2GUOCCtcgqh+E3RtsmpH892l1AbYU9oQpa9Bl5Odpg+6tg9fFRK9oIE4wUWch
	A+gZeID8XbY72l3Z695ZcwaI4VM5YQMWALev77pyG/5BeCC+wiT688I9a+G0x4wX0fUn
	8yWlh+7olNCGfWtm7c3322MzIBmikGguOhbMRQ8WmdCfblxLimDT+/T5WYKyXDb5G71F
	9uwNGpe6qWI2brLZ4p3zP5IW+MctdSnIDzkOGWEIDfR02MV3n711Y/gRFg+VlMpD6PRE
	EvTCV+xVr7oaDJlz/B/PBTND8o6zM4p6C0cUfGNZ+PQsC8WITSx350le5+1lcsksszXx
	ioHg==
Received: by 10.224.108.129 with SMTP id f1mr5648901qap.53.1339293818284;
	Sat, 09 Jun 2012 19:03:38 -0700 (PDT)
Received: from localhost.localdomain
	(209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com. [209.6.85.33])
	by mx.google.com with ESMTPS id
	cc16sm19926434qab.16.2012.06.09.19.03.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 09 Jun 2012 19:03:37 -0700 (PDT)
Date: Sat, 9 Jun 2012 22:03:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrea Arcangeli <aarcange@redhat.com>, drjones@redhat.com
Message-ID: <20120610020331.GA26100@localhost.localdomain>
References: <20120607190414.GF21339@redhat.com>
	<1339102833-12358-2-git-send-email-aarcange@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339102833-12358-2-git-send-email-aarcange@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Sun, 10 Jun 2012 03:41:28 +0000
Cc: xen-devel@lists.xensource.com, Petr Matousek <pmatouse@redhat.com>,
	Jan Beulich <jbeulich@suse.com>,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
 for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 11:00:33PM +0200, Andrea Arcangeli wrote:
> In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding
> the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
> contents under Xen.
> 
> So instead of dealing only with "consistent" pmdvals in
> pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
> simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
> where the low 32bit and high 32bit could be inconsistent (to avoid
> having to use cmpxchg8b).

<nods>
> 
> The only guarantee we get from pmd_read_atomic is that if the low part
> of the pmd was found null, the high part will be null too (so the pmd
> will be considered unstable). And if the low part of the pmd is found
> "stable" later, then it means the whole pmd was read atomically
> (because after a pmd is stable, neither MADV_DONTNEED nor page faults
> can alter it anymore, and we read the high part after the low part).
> 
> In the 32bit PAE x86 case, it is enough to read the low part of the
> pmdval atomically to declare the pmd as "stable" and that's true for
> THP and no THP, furthermore in the THP case we also have a barrier()
> that will prevent any inconsistent pmdvals to be cached by a later
> re-read of the *pmd.

Nice. Andrew, any chane you could test this patch on the affected
Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
hypervisor or is it really only on Linode and Amazon EC2?

> 
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
> ---
>  arch/x86/include/asm/pgtable-3level.h |   30 +++++++++++++++++-------------
>  include/asm-generic/pgtable.h         |   10 ++++++++++
>  2 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
> index 43876f1..cb00ccc 100644
> --- a/arch/x86/include/asm/pgtable-3level.h
> +++ b/arch/x86/include/asm/pgtable-3level.h
> @@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
>   * they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
>   * operations.
>   *
> - * Without THP if the mmap_sem is hold for reading, the
> - * pmd can only transition from null to not null while pmd_read_atomic runs.
> - * So there's no need of literally reading it atomically.
> + * Without THP if the mmap_sem is hold for reading, the pmd can only
> + * transition from null to not null while pmd_read_atomic runs. So
> + * we can always return atomic pmd values with this function.
>   *
>   * With THP if the mmap_sem is hold for reading, the pmd can become
> - * THP or null or point to a pte (and in turn become "stable") at any
> - * time under pmd_read_atomic, so it's mandatory to read it atomically
> - * with cmpxchg8b.
> + * trans_huge or none or point to a pte (and in turn become "stable")
> + * at any time under pmd_read_atomic. We could read it really
> + * atomically here with a atomic64_read for the THP enabled case (and
> + * it would be a whole lot simpler), but to avoid using cmpxchg8b we
> + * only return an atomic pmdval if the low part of the pmdval is later
> + * found stable (i.e. pointing to a pte). And we're returning a none
> + * pmdval if the low part of the pmd is none. In some cases the high
> + * and low part of the pmdval returned may not be consistent if THP is
> + * enabled (the low part may point to previously mapped hugepage,
> + * while the high part may point to a more recently mapped hugepage),
> + * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
> + * of the pmd to be read atomically to decide if the pmd is unstable
> + * or not, with the only exception of when the low part of the pmd is
> + * zero in which case we return a none pmd.
>   */
> -#ifndef CONFIG_TRANSPARENT_HUGEPAGE
>  static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
>  {
>  	pmdval_t ret;
> @@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
>  
>  	return (pmd_t) { ret };
>  }
> -#else /* CONFIG_TRANSPARENT_HUGEPAGE */
> -static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
> -{
> -	return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
> -}
> -#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  
>  static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
>  {
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index ae39c4b..0ff87ec 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -484,6 +484,16 @@ static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
>  	/*
>  	 * The barrier will stabilize the pmdval in a register or on
>  	 * the stack so that it will stop changing under the code.
> +	 *
> +	 * When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
> +	 * pmd_read_atomic is allowed to return a not atomic pmdval
> +	 * (for example pointing to an hugepage that has never been
> +	 * mapped in the pmd). The below checks will only care about
> +	 * the low part of the pmd with 32bit PAE x86 anyway, with the
> +	 * exception of pmd_none(). So the important thing is that if
> +	 * the low part of the pmd is found null, the high part will
> +	 * be also null or the pmd_none() check below would be
> +	 * confused.
>  	 */
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  	barrier();
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 03:42:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 03: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 1SdZ1u-0006ym-Bl; Sun, 10 Jun 2012 03:41:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1SdXVF-0006gH-DR
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 02:03:41 +0000
Received: from [85.158.139.83:56519] by server-4.bemta-5.messagelabs.com id
	DC/95-05858-C7004DF4; Sun, 10 Jun 2012 02:03:40 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339293818!31295200!1
X-Originating-IP: [209.85.216.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2927 invoked from network); 10 Jun 2012 02:03:39 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 02:03:39 -0000
Received: by qady23 with SMTP id y23so1974547qad.7
	for <xen-devel@lists.xensource.com>;
	Sat, 09 Jun 2012 19:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=r3L368o3GYmeawz4bzGqgtoKeESLAvh3MWLtuEvL1d4=;
	b=P9XzF2GUOCCtcgqh+E3RtsmpH892l1AbYU9oQpa9Bl5Odpg+6tg9fFRK9oIE4wUWch
	A+gZeID8XbY72l3Z695ZcwaI4VM5YQMWALev77pyG/5BeCC+wiT688I9a+G0x4wX0fUn
	8yWlh+7olNCGfWtm7c3322MzIBmikGguOhbMRQ8WmdCfblxLimDT+/T5WYKyXDb5G71F
	9uwNGpe6qWI2brLZ4p3zP5IW+MctdSnIDzkOGWEIDfR02MV3n711Y/gRFg+VlMpD6PRE
	EvTCV+xVr7oaDJlz/B/PBTND8o6zM4p6C0cUfGNZ+PQsC8WITSx350le5+1lcsksszXx
	ioHg==
Received: by 10.224.108.129 with SMTP id f1mr5648901qap.53.1339293818284;
	Sat, 09 Jun 2012 19:03:38 -0700 (PDT)
Received: from localhost.localdomain
	(209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com. [209.6.85.33])
	by mx.google.com with ESMTPS id
	cc16sm19926434qab.16.2012.06.09.19.03.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 09 Jun 2012 19:03:37 -0700 (PDT)
Date: Sat, 9 Jun 2012 22:03:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrea Arcangeli <aarcange@redhat.com>, drjones@redhat.com
Message-ID: <20120610020331.GA26100@localhost.localdomain>
References: <20120607190414.GF21339@redhat.com>
	<1339102833-12358-2-git-send-email-aarcange@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339102833-12358-2-git-send-email-aarcange@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Sun, 10 Jun 2012 03:41:28 +0000
Cc: xen-devel@lists.xensource.com, Petr Matousek <pmatouse@redhat.com>,
	Jan Beulich <jbeulich@suse.com>,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
 for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 07, 2012 at 11:00:33PM +0200, Andrea Arcangeli wrote:
> In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding
> the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
> contents under Xen.
> 
> So instead of dealing only with "consistent" pmdvals in
> pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
> simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
> where the low 32bit and high 32bit could be inconsistent (to avoid
> having to use cmpxchg8b).

<nods>
> 
> The only guarantee we get from pmd_read_atomic is that if the low part
> of the pmd was found null, the high part will be null too (so the pmd
> will be considered unstable). And if the low part of the pmd is found
> "stable" later, then it means the whole pmd was read atomically
> (because after a pmd is stable, neither MADV_DONTNEED nor page faults
> can alter it anymore, and we read the high part after the low part).
> 
> In the 32bit PAE x86 case, it is enough to read the low part of the
> pmdval atomically to declare the pmd as "stable" and that's true for
> THP and no THP, furthermore in the THP case we also have a barrier()
> that will prevent any inconsistent pmdvals to be cached by a later
> re-read of the *pmd.

Nice. Andrew, any chane you could test this patch on the affected
Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
hypervisor or is it really only on Linode and Amazon EC2?

> 
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
> ---
>  arch/x86/include/asm/pgtable-3level.h |   30 +++++++++++++++++-------------
>  include/asm-generic/pgtable.h         |   10 ++++++++++
>  2 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
> index 43876f1..cb00ccc 100644
> --- a/arch/x86/include/asm/pgtable-3level.h
> +++ b/arch/x86/include/asm/pgtable-3level.h
> @@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
>   * they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
>   * operations.
>   *
> - * Without THP if the mmap_sem is hold for reading, the
> - * pmd can only transition from null to not null while pmd_read_atomic runs.
> - * So there's no need of literally reading it atomically.
> + * Without THP if the mmap_sem is hold for reading, the pmd can only
> + * transition from null to not null while pmd_read_atomic runs. So
> + * we can always return atomic pmd values with this function.
>   *
>   * With THP if the mmap_sem is hold for reading, the pmd can become
> - * THP or null or point to a pte (and in turn become "stable") at any
> - * time under pmd_read_atomic, so it's mandatory to read it atomically
> - * with cmpxchg8b.
> + * trans_huge or none or point to a pte (and in turn become "stable")
> + * at any time under pmd_read_atomic. We could read it really
> + * atomically here with a atomic64_read for the THP enabled case (and
> + * it would be a whole lot simpler), but to avoid using cmpxchg8b we
> + * only return an atomic pmdval if the low part of the pmdval is later
> + * found stable (i.e. pointing to a pte). And we're returning a none
> + * pmdval if the low part of the pmd is none. In some cases the high
> + * and low part of the pmdval returned may not be consistent if THP is
> + * enabled (the low part may point to previously mapped hugepage,
> + * while the high part may point to a more recently mapped hugepage),
> + * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
> + * of the pmd to be read atomically to decide if the pmd is unstable
> + * or not, with the only exception of when the low part of the pmd is
> + * zero in which case we return a none pmd.
>   */
> -#ifndef CONFIG_TRANSPARENT_HUGEPAGE
>  static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
>  {
>  	pmdval_t ret;
> @@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
>  
>  	return (pmd_t) { ret };
>  }
> -#else /* CONFIG_TRANSPARENT_HUGEPAGE */
> -static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
> -{
> -	return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
> -}
> -#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  
>  static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
>  {
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index ae39c4b..0ff87ec 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -484,6 +484,16 @@ static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
>  	/*
>  	 * The barrier will stabilize the pmdval in a register or on
>  	 * the stack so that it will stop changing under the code.
> +	 *
> +	 * When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
> +	 * pmd_read_atomic is allowed to return a not atomic pmdval
> +	 * (for example pointing to an hugepage that has never been
> +	 * mapped in the pmd). The below checks will only care about
> +	 * the low part of the pmd with 32bit PAE x86 anyway, with the
> +	 * exception of pmd_none(). So the important thing is that if
> +	 * the low part of the pmd is found null, the high part will
> +	 * be also null or the pmd_none() check below would be
> +	 * confused.
>  	 */
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  	barrier();
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 04:11:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 04: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 1SdZUL-0000AM-I8; Sun, 10 Jun 2012 04:10:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SdZUK-0000AH-1s
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 04:10:52 +0000
Received: from [85.158.143.99:25766] by server-3.bemta-4.messagelabs.com id
	AA/EC-29237-B4E14DF4; Sun, 10 Jun 2012 04:10:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339301450!22314221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwNzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22600 invoked from network); 10 Jun 2012 04:10:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 04:10:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,744,1330905600"; d="scan'208";a="12926774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jun 2012 04:10:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 10 Jun 2012 05:10:50 +0100
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 1SdZUI-0003sm-0a;
	Sun, 10 Jun 2012 04:10:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SdZUH-0004Ui-Vp;
	Sun, 10 Jun 2012 05:10:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13038-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Jun 2012 05:10:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13038: regressions - trouble:
	blocked/fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13038 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13038/

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. 13025
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13025
 build-amd64                   4 xen-build                 fail REGR. vs. 13025
 build-i386                    4 xen-build                 fail REGR. vs. 13025
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 04:11:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 04: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 1SdZUL-0000AM-I8; Sun, 10 Jun 2012 04:10:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SdZUK-0000AH-1s
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 04:10:52 +0000
Received: from [85.158.143.99:25766] by server-3.bemta-4.messagelabs.com id
	AA/EC-29237-B4E14DF4; Sun, 10 Jun 2012 04:10:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339301450!22314221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwNzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22600 invoked from network); 10 Jun 2012 04:10:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 04:10:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,744,1330905600"; d="scan'208";a="12926774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jun 2012 04:10:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 10 Jun 2012 05:10:50 +0100
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 1SdZUI-0003sm-0a;
	Sun, 10 Jun 2012 04:10:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SdZUH-0004Ui-Vp;
	Sun, 10 Jun 2012 05:10:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13038-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Jun 2012 05:10:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13038: regressions - trouble:
	blocked/fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13038 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13038/

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. 13025
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13025
 build-amd64                   4 xen-build                 fail REGR. vs. 13025
 build-i386                    4 xen-build                 fail REGR. vs. 13025
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 04:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 04:40: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 1SdZwg-0000ib-LY; Sun, 10 Jun 2012 04:40:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SdZwe-0000iT-EV
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 04:40:08 +0000
Received: from [85.158.143.99:2305] by server-2.bemta-4.messagelabs.com id
	B2/8C-17938-72524DF4; Sun, 10 Jun 2012 04:40:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339303206!24561895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwNzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13199 invoked from network); 10 Jun 2012 04:40:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 04:40:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,744,1330905600"; d="scan'208";a="12926873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jun 2012 04:40:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 10 Jun 2012 05:40:06 +0100
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 1SdZwc-00042P-30;
	Sun, 10 Jun 2012 04:40:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SdZwc-000538-2P;
	Sun, 10 Jun 2012 05:40:06 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13045-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Jun 2012 05:40:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13045: regressions - trouble:
	blocked/fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13045 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13045/

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. 13025
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13025
 build-amd64                   4 xen-build                 fail REGR. vs. 13025
 build-i386                    4 xen-build                 fail REGR. vs. 13025
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 04:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 04:40: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 1SdZwg-0000ib-LY; Sun, 10 Jun 2012 04:40:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SdZwe-0000iT-EV
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 04:40:08 +0000
Received: from [85.158.143.99:2305] by server-2.bemta-4.messagelabs.com id
	B2/8C-17938-72524DF4; Sun, 10 Jun 2012 04:40:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339303206!24561895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwNzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13199 invoked from network); 10 Jun 2012 04:40:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 04:40:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,744,1330905600"; d="scan'208";a="12926873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jun 2012 04:40:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 10 Jun 2012 05:40:06 +0100
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 1SdZwc-00042P-30;
	Sun, 10 Jun 2012 04:40:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SdZwc-000538-2P;
	Sun, 10 Jun 2012 05:40:06 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13045-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Jun 2012 05:40:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13045: regressions - trouble:
	blocked/fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13045 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13045/

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. 13025
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13025
 build-amd64                   4 xen-build                 fail REGR. vs. 13025
 build-i386                    4 xen-build                 fail REGR. vs. 13025
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  a70b35deb2b5
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 04:50:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 04: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 1Sda5w-0000sw-N6; Sun, 10 Jun 2012 04:49:44 +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 1Sda5u-0000sr-5D
	for xen-devel@lists.xen.org; Sun, 10 Jun 2012 04:49:42 +0000
Received: from [85.158.139.83:18403] by server-12.bemta-5.messagelabs.com id
	11/42-18374-56724DF4; Sun, 10 Jun 2012 04:49:41 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339303776!25597290!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16801 invoked from network); 10 Jun 2012 04:49:39 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Jun 2012 04:49:39 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1Sda5l-0008Bs-HK; Sun, 10 Jun 2012 14:49:33 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 10 Jun 2012 14:49:33 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Sun, 10 Jun 2012 14:49:32 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Kazuto Yoshino <yoshink@alpha.co.jp>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
Thread-Index: AQHNRruowITCCms7JUGKH2FKKIEAE5by+wNQ
Date: Sun, 10 Jun 2012 04:49:30 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B28904C1B@BITCOM1.int.sbss.com.au>
References: <4FD20009.7000302@alpha.co.jp>
In-Reply-To: <4FD20009.7000302@alpha.co.jp>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18960.004
x-tm-as-result: No--41.985500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Jun 2012 04:49:33.0341 (UTC)
	FILETIME=[6DCEB4D0:01CD46C4]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for that. That locking code is really nasty... do you think your patch is fixing the problem or just working around it?

James

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Kazuto Yoshino
> Sent: Friday, 8 June 2012 11:37 PM
> To: xen-devel@lists.xen.org; yoshink@alpha.co.jp
> Subject: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
> 
> Hi all,
> 
> SCSI passthrough of DVD drive is tried on Windows.
> If vcpus=1 is used, it works.
> However, if vcpus=2 is used, it does not work.
> The log is as follows.
> 
> 
> Hardware:
> DELL Optiplex 990
> Intel Core i5 2500
> 
> 
> Software:
> xen 4.2-unstable (25452:6bea63e6c780)
> dom0: Linux 3.1.0-rc10+ 64bit
> domU: Windows 7 SP1 64bit
> GPLPV 0.10.0.357
> 
> 
> domU config:
> kernel = "hvmloader"
> builder='hvm'
> memory = 2048
> name = "win7x64"
> vcpus=2
> vif = [ 'type=ioemu, mac=00:16:3e:19:18:7b, bridge=virbr0' ] disk = [
> 'file:/etc/xen/win7x64.img,hda,w' ] device_model = 'qemu-dm'
> sdl=0
> opengl=1
> vnc=1
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> 
> 
> command:
> # xm create /etc/xen/win7x64.hvm
> # xm scsi-attach win7x64 1:0:0:0 2:0:0:0
> 
> 
> qemu-dm log:
> 12983594247656: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247656: XenPCI     Rescanning child list
> 12983594247656: XenPCI --> XenPci_EvtChildListScanForChildren
> 12983594247656: XenPCI     Found path = device/vbd/768
> 12983594247656: XenPCI     Found path = device/vif/0
> 12983594247671: XenPCI     Found path = device/vscsi/2
> 12983594247671: XenPCI <-- XenPci_EvtChildListScanForChildren
> 12983594247671: XenPCI --> XenPci_EvtChildListCreateDevice
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     device = 'vscsi', index = '2', path =
> 'device/vscsi/2'
> 12983594247671: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247671: XenPCI <-- XenPci_EvtChildListCreateDevice
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247671: XenPCI -->
> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
> 12983594247671: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     device/vscsi/2
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     CmResourceTypeMemory (0)
> 12983594247671: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     Start = f2000000, Length = 0
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247687: XenPCI     pfn[0] = 0000d445
> 12983594247687: XenPCI     New Start = 000000000d445000, Length = 4096
> 12983594247687: XenPCI     CmResourceTypeMemory (1)
> 12983594247687: XenPCI     Start = f2000001, Length = 0
> 12983594247687: XenPCI <--
> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
> 12983594247687: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
> 12983594247687: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
> 12983594247687: XenPCI --> XenPciPdo_EvtDeviceD0Entry
> 12983594247687: XenPCI     path = device/vscsi/2
> 12983594247687: XenPCI     WdfPowerDeviceD3Final
> 12983594247687: XenPCI --> XenPci_GetBackendAndAddWatch
> 12983594247687: XenPCI <-- XenPci_GetBackendAndAddWatch
> 12983594247687: XenPCI --> XenPci_UpdateBackendState
> 12983594247687: XenPCI --> XenConfig_InitConfigPage
> 12983594247687: XenPCI     Backend State Changed to InitWait
> 12983594247687: XenPCI     fdo_driver_object = FFFFFA80025B9E70
> 12983594247687: XenPCI <-- XenPci_UpdateBackendState
> 12983594247687: XenPCI     fdo_driver_extension = FFFFFA8001869010
> 12983594247703: XenPCI <-- XenConfig_InitConfigPage
> 12983594247703: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref =
> FFFFFA8002AB9000
> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
> 12983594247703: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247703: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
> channel = 8
> 12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247703: XenPCI --> EvtChn_BindIrq
> 12983594247703: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247703: XenPCI <-- EvtChn_BindIrq
> 12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247703: XenPCI --> XenPci_ChangeFrontendStateMap
> 12983594247703: XenPCI --> XenPci_ChangeFrontendState
> 12983594247703: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247703: XenPCI --> XenPci_UpdateBackendState
> 12983594247718: XenPCI     Backend State Changed to Connected
> 12983594247718: XenPCI <-- XenPci_UpdateBackendState
> 12983594247718: XenPCI <-- XenPci_ChangeFrontendState
> 12983594247718: XenPCI <-- XenPci_ChangeFrontendStateMap
> 12983594247718: XenPCI --> XenPci_ChangeFrontendStateMap
> 12983594247718: XenPCI --> XenPci_ChangeFrontendState
> 12983594247734: XenPCI <-- XenPci_ChangeFrontendState
> 12983594247734: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247734: XenPCI <-- XenPci_ChangeFrontendStateMap
> 12983594247734: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247734: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
> 12983594247734: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
> 12983594247734: XenSCSI --> XenScsi_HwScsiFindAdapter
> 12983594247734: XenSCSI     IRQL = 0
> 12983594247734: XenSCSI     BusInterruptLevel = 28
> 12983594247734: XenSCSI     BusInterruptVector = 01c
> 12983594247734: XenSCSI     RangeStart = 0d445000, RangeLength = 00001000
> 12983594247734: XenSCSI     XEN_INIT_TYPE_13
> 12983594247734: XenSCSI     XEN_INIT_TYPE_VECTORS
> 12983594247734: XenSCSI     XEN_INIT_TYPE_11
> 12983594247734: XenSCSI     XEN_INIT_TYPE_RING - ring-ref =
> FFFFFA8002AB9000
> 12983594247734: XenSCSI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
> channel = 8
> 12983594247750: XenSCSI     XEN_INIT_TYPE_GRANT_ENTRIES - 144
> 12983594247750: XenSCSI     Dma64BitAddresses supported
> 12983594247750: XenPCI --> XenPci_XenBus_AddWatch
> 12983594247750: XenPCI     XenPci_XenBus_AddWatch -
> /local/domain/0/backend/vscsi/3/2/vscsi-devs = NULL
> 12983594247750: XenSCSI --> XenScsi_DevWatch
> 12983594247750: XenPCI <-- XenPci_XenBus_AddWatch
> 12983594247750: XenSCSI     Waiting for pause...
> 12983594247750: XenSCSI <-- XenScsi_HwScsiFindAdapter
> 12983594247750: XenSCSI --> XenScsi_HwScsiInitialize
> 12983594247750: XenSCSI <-- XenScsi_HwScsiInitialize
> 12983594247750: XenSCSI --> XenScsi_HwScsiAdapterControl
> 12983594247750: XenSCSI     IRQL = 0
> 12983594247750: XenSCSI     ScsiQuerySupportedControlTypes (Max = 5)
> 12983594247750: XenSCSI <-- XenScsi_HwScsiAdapterControl
> 12983594247750: XenSCSI     Busy
> 12983594247859: XenSCSI     Waiting for pause...
> 12983594247968: XenSCSI     Waiting for pause...
> 12983594248078: XenSCSI     Waiting for pause...
> 12983594248187: XenSCSI     Waiting for pause...
> 12983594248296: XenSCSI     Waiting for pause...
> 12983594248406: XenSCSI     Waiting for pause...
> 12983594248515: XenSCSI     Waiting for pause...
> 12983594248625: XenSCSI     Waiting for pause...
> 12983594248734: XenSCSI     Waiting for pause...
> 12983594248843: XenSCSI     Waiting for pause...
> 
> 
> 
> It worked, when correcting the source code of GPLPV as follows.
> 
> 
> --- a/xenscsi/xenscsi.c
> +++ b/xenscsi/xenscsi.c
> @@ -278,17 +278,27 @@
>      /* this can only be called from a watch and so is always serialised */
>      FUNCTION_ENTER();
> 
> -  #if DBG
> -  oldpause =
> -  #endif
> -    InterlockedExchange(&xsdd->shared_paused,
> SHARED_PAUSED_PASSIVE_PAUSED);
> -  ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
> -
> -  while (InterlockedCompareExchange(&xsdd->shared_paused,
> SHARED_PAUSED_SCSIPORT_PAUSED,
> SHARED_PAUSED_SCSIPORT_PAUSED) !=
> SHARED_PAUSED_SCSIPORT_PAUSED)
> +  while (1)
>      {
> -    KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
> -    wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
> -    KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
> SHARED_PAUSED_SCSIPORT_UNPAUSED,
> SHARED_PAUSED_SCSIPORT_UNPAUSED) ==
> SHARED_PAUSED_SCSIPORT_UNPAUSED)
> +    {
> +      #if DBG
> +      oldpause =
> +      #endif
> +        InterlockedExchange(&xsdd->shared_paused,
> SHARED_PAUSED_PASSIVE_PAUSED);
> +      ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
> +    }
> +
> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
> SHARED_PAUSED_SCSIPORT_PAUSED,
> SHARED_PAUSED_SCSIPORT_PAUSED) !=
> SHARED_PAUSED_SCSIPORT_PAUSED)
> +    {
> +      KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
> +      wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
> +      KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
> +    }
> +    else
> +    {
> +      break;
> +    }
>      }
> 
>      KdPrint((__DRIVER_NAME "     Watch triggered on %s\n", path));
> 
> 
> Thanks,
> Kazuto Yoshino.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 04:50:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 04: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 1Sda5w-0000sw-N6; Sun, 10 Jun 2012 04:49:44 +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 1Sda5u-0000sr-5D
	for xen-devel@lists.xen.org; Sun, 10 Jun 2012 04:49:42 +0000
Received: from [85.158.139.83:18403] by server-12.bemta-5.messagelabs.com id
	11/42-18374-56724DF4; Sun, 10 Jun 2012 04:49:41 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339303776!25597290!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16801 invoked from network); 10 Jun 2012 04:49:39 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Jun 2012 04:49:39 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1Sda5l-0008Bs-HK; Sun, 10 Jun 2012 14:49:33 +1000
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 10 Jun 2012 14:49:33 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi;
	Sun, 10 Jun 2012 14:49:32 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Kazuto Yoshino <yoshink@alpha.co.jp>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
Thread-Index: AQHNRruowITCCms7JUGKH2FKKIEAE5by+wNQ
Date: Sun, 10 Jun 2012 04:49:30 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B28904C1B@BITCOM1.int.sbss.com.au>
References: <4FD20009.7000302@alpha.co.jp>
In-Reply-To: <4FD20009.7000302@alpha.co.jp>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18960.004
x-tm-as-result: No--41.985500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Jun 2012 04:49:33.0341 (UTC)
	FILETIME=[6DCEB4D0:01CD46C4]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for that. That locking code is really nasty... do you think your patch is fixing the problem or just working around it?

James

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Kazuto Yoshino
> Sent: Friday, 8 June 2012 11:37 PM
> To: xen-devel@lists.xen.org; yoshink@alpha.co.jp
> Subject: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
> 
> Hi all,
> 
> SCSI passthrough of DVD drive is tried on Windows.
> If vcpus=1 is used, it works.
> However, if vcpus=2 is used, it does not work.
> The log is as follows.
> 
> 
> Hardware:
> DELL Optiplex 990
> Intel Core i5 2500
> 
> 
> Software:
> xen 4.2-unstable (25452:6bea63e6c780)
> dom0: Linux 3.1.0-rc10+ 64bit
> domU: Windows 7 SP1 64bit
> GPLPV 0.10.0.357
> 
> 
> domU config:
> kernel = "hvmloader"
> builder='hvm'
> memory = 2048
> name = "win7x64"
> vcpus=2
> vif = [ 'type=ioemu, mac=00:16:3e:19:18:7b, bridge=virbr0' ] disk = [
> 'file:/etc/xen/win7x64.img,hda,w' ] device_model = 'qemu-dm'
> sdl=0
> opengl=1
> vnc=1
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> 
> 
> command:
> # xm create /etc/xen/win7x64.hvm
> # xm scsi-attach win7x64 1:0:0:0 2:0:0:0
> 
> 
> qemu-dm log:
> 12983594247656: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247656: XenPCI     Rescanning child list
> 12983594247656: XenPCI --> XenPci_EvtChildListScanForChildren
> 12983594247656: XenPCI     Found path = device/vbd/768
> 12983594247656: XenPCI     Found path = device/vif/0
> 12983594247671: XenPCI     Found path = device/vscsi/2
> 12983594247671: XenPCI <-- XenPci_EvtChildListScanForChildren
> 12983594247671: XenPCI --> XenPci_EvtChildListCreateDevice
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     device = 'vscsi', index = '2', path =
> 'device/vscsi/2'
> 12983594247671: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247671: XenPCI <-- XenPci_EvtChildListCreateDevice
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247671: XenPCI -->
> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
> 12983594247671: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     device/vscsi/2
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     CmResourceTypeMemory (0)
> 12983594247671: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247671: XenPCI     Start = f2000000, Length = 0
> 12983594247671: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247687: XenPCI     pfn[0] = 0000d445
> 12983594247687: XenPCI     New Start = 000000000d445000, Length = 4096
> 12983594247687: XenPCI     CmResourceTypeMemory (1)
> 12983594247687: XenPCI     Start = f2000001, Length = 0
> 12983594247687: XenPCI <--
> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
> 12983594247687: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
> 12983594247687: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
> 12983594247687: XenPCI --> XenPciPdo_EvtDeviceD0Entry
> 12983594247687: XenPCI     path = device/vscsi/2
> 12983594247687: XenPCI     WdfPowerDeviceD3Final
> 12983594247687: XenPCI --> XenPci_GetBackendAndAddWatch
> 12983594247687: XenPCI <-- XenPci_GetBackendAndAddWatch
> 12983594247687: XenPCI --> XenPci_UpdateBackendState
> 12983594247687: XenPCI --> XenConfig_InitConfigPage
> 12983594247687: XenPCI     Backend State Changed to InitWait
> 12983594247687: XenPCI     fdo_driver_object = FFFFFA80025B9E70
> 12983594247687: XenPCI <-- XenPci_UpdateBackendState
> 12983594247687: XenPCI     fdo_driver_extension = FFFFFA8001869010
> 12983594247703: XenPCI <-- XenConfig_InitConfigPage
> 12983594247703: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref =
> FFFFFA8002AB9000
> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
> 12983594247703: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247703: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
> channel = 8
> 12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247703: XenPCI --> EvtChn_BindIrq
> 12983594247703: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247703: XenPCI <-- EvtChn_BindIrq
> 12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247703: XenPCI --> XenPci_ChangeFrontendStateMap
> 12983594247703: XenPCI --> XenPci_ChangeFrontendState
> 12983594247703: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247703: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247703: XenPCI --> XenPci_UpdateBackendState
> 12983594247718: XenPCI     Backend State Changed to Connected
> 12983594247718: XenPCI <-- XenPci_UpdateBackendState
> 12983594247718: XenPCI <-- XenPci_ChangeFrontendState
> 12983594247718: XenPCI <-- XenPci_ChangeFrontendStateMap
> 12983594247718: XenPCI --> XenPci_ChangeFrontendStateMap
> 12983594247718: XenPCI --> XenPci_ChangeFrontendState
> 12983594247734: XenPCI <-- XenPci_ChangeFrontendState
> 12983594247734: XenPCI --> XenPci_DeviceWatchHandler
> 12983594247734: XenPCI <-- XenPci_ChangeFrontendStateMap
> 12983594247734: XenPCI <-- XenPci_DeviceWatchHandler
> 12983594247734: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
> 12983594247734: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
> 12983594247734: XenSCSI --> XenScsi_HwScsiFindAdapter
> 12983594247734: XenSCSI     IRQL = 0
> 12983594247734: XenSCSI     BusInterruptLevel = 28
> 12983594247734: XenSCSI     BusInterruptVector = 01c
> 12983594247734: XenSCSI     RangeStart = 0d445000, RangeLength = 00001000
> 12983594247734: XenSCSI     XEN_INIT_TYPE_13
> 12983594247734: XenSCSI     XEN_INIT_TYPE_VECTORS
> 12983594247734: XenSCSI     XEN_INIT_TYPE_11
> 12983594247734: XenSCSI     XEN_INIT_TYPE_RING - ring-ref =
> FFFFFA8002AB9000
> 12983594247734: XenSCSI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
> channel = 8
> 12983594247750: XenSCSI     XEN_INIT_TYPE_GRANT_ENTRIES - 144
> 12983594247750: XenSCSI     Dma64BitAddresses supported
> 12983594247750: XenPCI --> XenPci_XenBus_AddWatch
> 12983594247750: XenPCI     XenPci_XenBus_AddWatch -
> /local/domain/0/backend/vscsi/3/2/vscsi-devs = NULL
> 12983594247750: XenSCSI --> XenScsi_DevWatch
> 12983594247750: XenPCI <-- XenPci_XenBus_AddWatch
> 12983594247750: XenSCSI     Waiting for pause...
> 12983594247750: XenSCSI <-- XenScsi_HwScsiFindAdapter
> 12983594247750: XenSCSI --> XenScsi_HwScsiInitialize
> 12983594247750: XenSCSI <-- XenScsi_HwScsiInitialize
> 12983594247750: XenSCSI --> XenScsi_HwScsiAdapterControl
> 12983594247750: XenSCSI     IRQL = 0
> 12983594247750: XenSCSI     ScsiQuerySupportedControlTypes (Max = 5)
> 12983594247750: XenSCSI <-- XenScsi_HwScsiAdapterControl
> 12983594247750: XenSCSI     Busy
> 12983594247859: XenSCSI     Waiting for pause...
> 12983594247968: XenSCSI     Waiting for pause...
> 12983594248078: XenSCSI     Waiting for pause...
> 12983594248187: XenSCSI     Waiting for pause...
> 12983594248296: XenSCSI     Waiting for pause...
> 12983594248406: XenSCSI     Waiting for pause...
> 12983594248515: XenSCSI     Waiting for pause...
> 12983594248625: XenSCSI     Waiting for pause...
> 12983594248734: XenSCSI     Waiting for pause...
> 12983594248843: XenSCSI     Waiting for pause...
> 
> 
> 
> It worked, when correcting the source code of GPLPV as follows.
> 
> 
> --- a/xenscsi/xenscsi.c
> +++ b/xenscsi/xenscsi.c
> @@ -278,17 +278,27 @@
>      /* this can only be called from a watch and so is always serialised */
>      FUNCTION_ENTER();
> 
> -  #if DBG
> -  oldpause =
> -  #endif
> -    InterlockedExchange(&xsdd->shared_paused,
> SHARED_PAUSED_PASSIVE_PAUSED);
> -  ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
> -
> -  while (InterlockedCompareExchange(&xsdd->shared_paused,
> SHARED_PAUSED_SCSIPORT_PAUSED,
> SHARED_PAUSED_SCSIPORT_PAUSED) !=
> SHARED_PAUSED_SCSIPORT_PAUSED)
> +  while (1)
>      {
> -    KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
> -    wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
> -    KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
> SHARED_PAUSED_SCSIPORT_UNPAUSED,
> SHARED_PAUSED_SCSIPORT_UNPAUSED) ==
> SHARED_PAUSED_SCSIPORT_UNPAUSED)
> +    {
> +      #if DBG
> +      oldpause =
> +      #endif
> +        InterlockedExchange(&xsdd->shared_paused,
> SHARED_PAUSED_PASSIVE_PAUSED);
> +      ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
> +    }
> +
> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
> SHARED_PAUSED_SCSIPORT_PAUSED,
> SHARED_PAUSED_SCSIPORT_PAUSED) !=
> SHARED_PAUSED_SCSIPORT_PAUSED)
> +    {
> +      KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
> +      wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
> +      KeDelayExecutionThread(KernelMode, FALSE, &wait_time);
> +    }
> +    else
> +    {
> +      break;
> +    }
>      }
> 
>      KdPrint((__DRIVER_NAME "     Watch triggered on %s\n", path));
> 
> 
> Thanks,
> Kazuto Yoshino.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 09:47:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 09: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 1Sdej7-0003zz-PN; Sun, 10 Jun 2012 09:46:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cplusplus328@gmail.com>) id 1Sdej6-0003zu-Na
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 09:46:28 +0000
Received: from [85.158.139.83:11085] by server-11.bemta-5.messagelabs.com id
	69/15-25194-3FC64DF4; Sun, 10 Jun 2012 09:46:27 +0000
X-Env-Sender: cplusplus328@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339321583!32286746!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1259 invoked from network); 10 Jun 2012 09:46:24 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 09:46:24 -0000
Received: by lbom4 with SMTP id m4so2780219lbo.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 02:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=subFxjr0/YbTfcS3hm8l1JGkXcSRRd2CNaDU2qddpUo=;
	b=RpuxKyg20d5a12hJgDunfU6zsx/qd7gsXdrsbq4CuEkd9OyJQxycpzlAbNVwtgttwL
	pbHKVjqI5F5SE+SmDLVq/ffO4ntv+IIQ9DCu8aFHrS3FmQ98deyRIWRrfm40I1Phc5zA
	KQ6zGxKIeQ/lS76JxHB59sMIvIh8fW60hmrqkOg+N+wLdFOSNBSQVsojrdtx8xngeEeO
	nfM/hiWMi5vihPccT6iVuKFynuW1UyzOb3lUqK3Xd4SGUm6blRMZRvcxnPQRJt42Faq9
	QdMtak7LBJ0Mz2EtlOkrSdj/G4mJ9P007roq/abPfFOc41Xt4RZxXqPK9ep5MeqZahUM
	IlEw==
Received: by 10.152.144.133 with SMTP id sm5mr14206576lab.4.1339321583243;
	Sun, 10 Jun 2012 02:46:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.21.5 with HTTP; Sun, 10 Jun 2012 02:46:03 -0700 (PDT)
From: Aaron Lebahn <cplusplus328@gmail.com>
Date: Sun, 10 Jun 2012 03:46:03 -0600
Message-ID: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenbits 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="===============0055061680711532614=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0055061680711532614==
Content-Type: multipart/alternative; boundary=e89a8f23496335900304c21b1b49

--e89a8f23496335900304c21b1b49
Content-Type: text/plain; charset=ISO-8859-1

Xenbits seems to be down. It was acting slow before it went.

-- 
Aaron Lebahn
cplusplus328@gmail.com

--e89a8f23496335900304c21b1b49
Content-Type: text/html; charset=ISO-8859-1

Xenbits seems to be down. It was acting slow before it went.<br clear="all"><br>-- <br>Aaron Lebahn<br><a href="mailto:cplusplus328@gmail.com" target="_blank">cplusplus328@gmail.com</a><br>

--e89a8f23496335900304c21b1b49--


--===============0055061680711532614==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0055061680711532614==--


From xen-devel-bounces@lists.xen.org Sun Jun 10 09:47:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 09: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 1Sdej7-0003zz-PN; Sun, 10 Jun 2012 09:46:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cplusplus328@gmail.com>) id 1Sdej6-0003zu-Na
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 09:46:28 +0000
Received: from [85.158.139.83:11085] by server-11.bemta-5.messagelabs.com id
	69/15-25194-3FC64DF4; Sun, 10 Jun 2012 09:46:27 +0000
X-Env-Sender: cplusplus328@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339321583!32286746!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1259 invoked from network); 10 Jun 2012 09:46:24 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 09:46:24 -0000
Received: by lbom4 with SMTP id m4so2780219lbo.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 02:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=subFxjr0/YbTfcS3hm8l1JGkXcSRRd2CNaDU2qddpUo=;
	b=RpuxKyg20d5a12hJgDunfU6zsx/qd7gsXdrsbq4CuEkd9OyJQxycpzlAbNVwtgttwL
	pbHKVjqI5F5SE+SmDLVq/ffO4ntv+IIQ9DCu8aFHrS3FmQ98deyRIWRrfm40I1Phc5zA
	KQ6zGxKIeQ/lS76JxHB59sMIvIh8fW60hmrqkOg+N+wLdFOSNBSQVsojrdtx8xngeEeO
	nfM/hiWMi5vihPccT6iVuKFynuW1UyzOb3lUqK3Xd4SGUm6blRMZRvcxnPQRJt42Faq9
	QdMtak7LBJ0Mz2EtlOkrSdj/G4mJ9P007roq/abPfFOc41Xt4RZxXqPK9ep5MeqZahUM
	IlEw==
Received: by 10.152.144.133 with SMTP id sm5mr14206576lab.4.1339321583243;
	Sun, 10 Jun 2012 02:46:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.21.5 with HTTP; Sun, 10 Jun 2012 02:46:03 -0700 (PDT)
From: Aaron Lebahn <cplusplus328@gmail.com>
Date: Sun, 10 Jun 2012 03:46:03 -0600
Message-ID: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenbits 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="===============0055061680711532614=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0055061680711532614==
Content-Type: multipart/alternative; boundary=e89a8f23496335900304c21b1b49

--e89a8f23496335900304c21b1b49
Content-Type: text/plain; charset=ISO-8859-1

Xenbits seems to be down. It was acting slow before it went.

-- 
Aaron Lebahn
cplusplus328@gmail.com

--e89a8f23496335900304c21b1b49
Content-Type: text/html; charset=ISO-8859-1

Xenbits seems to be down. It was acting slow before it went.<br clear="all"><br>-- <br>Aaron Lebahn<br><a href="mailto:cplusplus328@gmail.com" target="_blank">cplusplus328@gmail.com</a><br>

--e89a8f23496335900304c21b1b49--


--===============0055061680711532614==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0055061680711532614==--


From xen-devel-bounces@lists.xen.org Sun Jun 10 10:24:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 10:24: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 1SdfJN-0004J4-SX; Sun, 10 Jun 2012 10:23:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SdfJM-0004Iz-JR
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 10:23:56 +0000
Received: from [85.158.143.35:49899] by server-3.bemta-4.messagelabs.com id
	9E/96-29237-BB574DF4; Sun, 10 Jun 2012 10:23:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339323832!8681916!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11593 invoked from network); 10 Jun 2012 10:23:54 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jun 2012 10:23:54 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q5AANli3014995
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 10 Jun 2012 06:23:48 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q5AANlG0014993;
	Sun, 10 Jun 2012 06:23:47 -0400
Date: Sun, 10 Jun 2012 06:23:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120610102347.GA14968@andromeda.dapyr.net>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120605160746.GB24031@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
	xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > In xen_set_pte() if batching is unavailable (because the caller is in
> > an interrupt context such as handling a page fault) it would fall back
> > to using native_set_pte() and trapping and emulating the PTE write.
> > 
> > On 32-bit guests this requires two traps for each PTE write (one for
> > each dword of the PTE).  Instead, do one mmu_update hypercall
> > directly.
> 
> OK.
> > 
> > This significantly improves page fault performance in 32-bit PV
> > guests.
> 
> Nice!

With this patch I keep on getting this (which is v3.5-rc2 plus my
patches in stable/for-linus-3.5 and yours):

Loading latest/xen.gz... ok
Loading latest/vmlinuz... ok
Loading latest/initramfs.cpio.gz... ok
 __  __            _  _    _    _ ____   ___  ____ ____  _____=20
 \ \/ /___ _ __   | || |  / |  / |___ \ / _ \| ___|___ \|___ /            =
=20
(XEN) Xen version 4.1-120609 (konrad@dumpdata.com) (gcc version 4.4.4 20100=
503 (Red Hat 4.4.4-2) (GCC) ) Sat Jun  9 10:49:23 EDT 2012
(XEN) Latest ChangeSet: Fri May 25 08:18:47 2012 +0100 23298:435493696053
(XEN) Bootloader: unknown
(XEN) Command line: com1=3D115200,8n1 console=3Dcom1,vga guest_loglvl=3Dall=
 dom0_mem=3D1G,max:2G dom0_max_vcpus=3D2 cpufreq=3Dperformance,verbose logl=
vl=3Dall apic=3Ddebug
(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) ACPI: FACP BADD0308, 00F4 (r4 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: DSDT BADC9150, 71B5 (r2 ALASKA    A M I       15 INTL 20051117)
(XEN) ACPI: FACS BAE0BF80, 0040
(XEN) ACPI: APIC BADD0400, 0072 (r3 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: SSDT BADD0478, 0102 (r1 AMICPU     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
(X000000000000000, 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) Detected 3093.009 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCirtualisation disa=
bled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 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
(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=3D0x1000000 memsz=3D0x7a3000
(XEN) elf_parse_binary: phdr: paddr=3D0x1800000 memsz=3D0x850e8
(XEN)_binary: memory: 0x1000000 -> 0x1e41000
(XEN) elf_xen_parse_note: GUEST_OS =3D "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION =3D "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION =3D "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY =3D 0xffffffff8189a210
(XEN) elf_xen_parse_note: HYPERCALL_PAGE =3D 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES =3D "!writable_page_tables|pae_pgdir_abo=
ve_4gb"
(XEN) elf_xen_parse_note: PAE_MODE =3D "yes"
(XEN) elf_xen_parse_note: LOADER =3D "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1
(XEN) elf_xen_parse_note: HV_START_LOW =3D 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET =3D 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        =3D 0xffffffff80000000
(XEN)     elf_paddr_offset =3D 0x0
(XEN)     virt_offset      =3D 0xffffffff80000000
(XEN)     virt_kstart      =3D 0xffffffff81000000
(XEN)     virt_kend        =3D 0xffffffff81e41000
(XEN)     virt_entry       =3D 0xffffffff8189a210
(XEN)     p2m_base         =3D 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1e41000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000224000000->0000000228000000 (187430 pages to b=
e allocated)
(XEN)  Init. ramdisk: 0000000231a26000->000000023fdffa00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81e41000
(XEN)  Init. ramdisk: ffffffff81e41000->ffffffff9021aa00
(XEN)  Phys-Mach map: ffffffff9021b000->ffffffff9041b000
(XEN)  Start info:    ffffffff9041b000->ffffffff9041b4b4
(XEN)  Page tables:   ffffffff9041c000->ffffffff904a3000
(XEN)  Boot stack:    ffffffff904a3000->ffffffff904a4000
(XEN)  TOTAL:         ffffffff80000000->ffffffff90800000
(XEN)  ENTRY ADDRESS: ffffffff8189a210
(XEN) Dom0 has maximum 2 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817a3000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818850e8
(XEN) elf_load_binary: phdr 2 at 0xffffffff81886000 -> 0xffffffff81899280
(XEN) elf_load_binary: phdr 3 at 0xffffffff8189a000 -> 0xffffffff8193e000
(XEN) Scrubbing Free RAM: .................................................=
=2E...................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA co cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.5.0-rc2upstream-00011-g3dccb5f-dirty (konrad=
@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) =
#1 SMP Sat Jun 9 10:49:11 EDT 2012
[    0.000000] Command line: earlyprintk=3Dxen debug nofb console=3Dtty con=
sole=3Dhvc0 loglevel=3D10
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] Released 610 pages of unused memory
[    0.000000] Set 283999 page(s) to 1-1 mapping
[    0.000000] Populating 40200-40462 pfn range: 610 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-0x0000000080461fff] usable
[    0.000000] Xen: [mem 0x0000000080462000-0x00000000bad7ffff] unusable
[    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] unusable
[    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] unusable
[    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] unusable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 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-0x0000ffff] usable =3D=3D> rese=
rved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn =3D 0x80462 max_arch_pfn =3D 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000fcde0-0x000fcdef] mapped at =
[ffff8800000fcde0]
[    0.000000] initial memory mapped: [mem 0x00000000-0x1021afff]
[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x80461fff]
[    0.000000]  [mem 0x00000000-0x80461fff] page 4k
[    0.000000] kernel direct mapping tables up to 0x80461fff @ [mem 0x00bf9=
000-0x00ffffff]
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 10:24:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 10:24: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 1SdfJN-0004J4-SX; Sun, 10 Jun 2012 10:23:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1SdfJM-0004Iz-JR
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 10:23:56 +0000
Received: from [85.158.143.35:49899] by server-3.bemta-4.messagelabs.com id
	9E/96-29237-BB574DF4; Sun, 10 Jun 2012 10:23:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339323832!8681916!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11593 invoked from network); 10 Jun 2012 10:23:54 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jun 2012 10:23:54 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q5AANli3014995
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 10 Jun 2012 06:23:48 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q5AANlG0014993;
	Sun, 10 Jun 2012 06:23:47 -0400
Date: Sun, 10 Jun 2012 06:23:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120610102347.GA14968@andromeda.dapyr.net>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120605160746.GB24031@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
	xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > In xen_set_pte() if batching is unavailable (because the caller is in
> > an interrupt context such as handling a page fault) it would fall back
> > to using native_set_pte() and trapping and emulating the PTE write.
> > 
> > On 32-bit guests this requires two traps for each PTE write (one for
> > each dword of the PTE).  Instead, do one mmu_update hypercall
> > directly.
> 
> OK.
> > 
> > This significantly improves page fault performance in 32-bit PV
> > guests.
> 
> Nice!

With this patch I keep on getting this (which is v3.5-rc2 plus my
patches in stable/for-linus-3.5 and yours):

Loading latest/xen.gz... ok
Loading latest/vmlinuz... ok
Loading latest/initramfs.cpio.gz... ok
 __  __            _  _    _    _ ____   ___  ____ ____  _____=20
 \ \/ /___ _ __   | || |  / |  / |___ \ / _ \| ___|___ \|___ /            =
=20
(XEN) Xen version 4.1-120609 (konrad@dumpdata.com) (gcc version 4.4.4 20100=
503 (Red Hat 4.4.4-2) (GCC) ) Sat Jun  9 10:49:23 EDT 2012
(XEN) Latest ChangeSet: Fri May 25 08:18:47 2012 +0100 23298:435493696053
(XEN) Bootloader: unknown
(XEN) Command line: com1=3D115200,8n1 console=3Dcom1,vga guest_loglvl=3Dall=
 dom0_mem=3D1G,max:2G dom0_max_vcpus=3D2 cpufreq=3Dperformance,verbose logl=
vl=3Dall apic=3Ddebug
(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) ACPI: FACP BADD0308, 00F4 (r4 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: DSDT BADC9150, 71B5 (r2 ALASKA    A M I       15 INTL 20051117)
(XEN) ACPI: FACS BAE0BF80, 0040
(XEN) ACPI: APIC BADD0400, 0072 (r3 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: SSDT BADD0478, 0102 (r1 AMICPU     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
(X000000000000000, 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) Detected 3093.009 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCirtualisation disa=
bled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 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
(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=3D0x1000000 memsz=3D0x7a3000
(XEN) elf_parse_binary: phdr: paddr=3D0x1800000 memsz=3D0x850e8
(XEN)_binary: memory: 0x1000000 -> 0x1e41000
(XEN) elf_xen_parse_note: GUEST_OS =3D "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION =3D "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION =3D "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY =3D 0xffffffff8189a210
(XEN) elf_xen_parse_note: HYPERCALL_PAGE =3D 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES =3D "!writable_page_tables|pae_pgdir_abo=
ve_4gb"
(XEN) elf_xen_parse_note: PAE_MODE =3D "yes"
(XEN) elf_xen_parse_note: LOADER =3D "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1
(XEN) elf_xen_parse_note: HV_START_LOW =3D 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET =3D 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        =3D 0xffffffff80000000
(XEN)     elf_paddr_offset =3D 0x0
(XEN)     virt_offset      =3D 0xffffffff80000000
(XEN)     virt_kstart      =3D 0xffffffff81000000
(XEN)     virt_kend        =3D 0xffffffff81e41000
(XEN)     virt_entry       =3D 0xffffffff8189a210
(XEN)     p2m_base         =3D 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1e41000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000224000000->0000000228000000 (187430 pages to b=
e allocated)
(XEN)  Init. ramdisk: 0000000231a26000->000000023fdffa00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81e41000
(XEN)  Init. ramdisk: ffffffff81e41000->ffffffff9021aa00
(XEN)  Phys-Mach map: ffffffff9021b000->ffffffff9041b000
(XEN)  Start info:    ffffffff9041b000->ffffffff9041b4b4
(XEN)  Page tables:   ffffffff9041c000->ffffffff904a3000
(XEN)  Boot stack:    ffffffff904a3000->ffffffff904a4000
(XEN)  TOTAL:         ffffffff80000000->ffffffff90800000
(XEN)  ENTRY ADDRESS: ffffffff8189a210
(XEN) Dom0 has maximum 2 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff817a3000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81800000 -> 0xffffffff818850e8
(XEN) elf_load_binary: phdr 2 at 0xffffffff81886000 -> 0xffffffff81899280
(XEN) elf_load_binary: phdr 3 at 0xffffffff8189a000 -> 0xffffffff8193e000
(XEN) Scrubbing Free RAM: .................................................=
=2E...................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA co cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.5.0-rc2upstream-00011-g3dccb5f-dirty (konrad=
@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) =
#1 SMP Sat Jun 9 10:49:11 EDT 2012
[    0.000000] Command line: earlyprintk=3Dxen debug nofb console=3Dtty con=
sole=3Dhvc0 loglevel=3D10
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] Released 610 pages of unused memory
[    0.000000] Set 283999 page(s) to 1-1 mapping
[    0.000000] Populating 40200-40462 pfn range: 610 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-0x0000000080461fff] usable
[    0.000000] Xen: [mem 0x0000000080462000-0x00000000bad7ffff] unusable
[    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] unusable
[    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] unusable
[    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] unusable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 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-0x0000ffff] usable =3D=3D> rese=
rved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn =3D 0x80462 max_arch_pfn =3D 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000fcde0-0x000fcdef] mapped at =
[ffff8800000fcde0]
[    0.000000] initial memory mapped: [mem 0x00000000-0x1021afff]
[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x80461fff]
[    0.000000]  [mem 0x00000000-0x80461fff] page 4k
[    0.000000] kernel direct mapping tables up to 0x80461fff @ [mem 0x00bf9=
000-0x00ffffff]
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
(XEN) mm.c:3460:d0 Could not get page for normal update
(XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 14:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 14:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sdivz-0005XO-At; Sun, 10 Jun 2012 14:16:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1Sdivx-0005XB-RY
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 14:16:02 +0000
Received: from [85.158.139.83:64990] by server-7.bemta-5.messagelabs.com id
	EC/DC-19648-02CA4DF4; Sun, 10 Jun 2012 14:16:00 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339337759!32831012!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2863 invoked from network); 10 Jun 2012 14:15:59 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 14:15:59 -0000
Received: by bkty5 with SMTP id y5so3571132bkt.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 07:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:reply-to:to:cc:in-reply-to:references
	:content-type:date:mime-version:x-mailer:content-transfer-encoding;
	bh=JbDc8lE5a+sSKA5DMMIpd+mdhjam5FqthimLpZN+0Ik=;
	b=XEDJeRgzJIJWLHnlnY3jyHt7QtiXJ1u+zyu4Bb6k/XLvj3JwAXvPkfkh94LGe4q2/r
	j3JNAYGCezUfGKXw0hg7YzqZX+91vtkxACt5/J5G3Y1WLpseFktU/rg2yjrOcvZii0Mg
	XbFPgWpX2bZgMoqI9S6hmQwjnR6tHLY5pXtePktPIwFa5IDIXY9S77o+w0461Ql1Vl3L
	dWj7WCfKfwZG9xlhc90ot0kOuf8U7L4RanEkAzFUaiacwFrgFQLt0Lr6zNC4PQmUbM4f
	iqw059ldcLATBuNmWPd/N7+N0xgkmu6OUUSsNLkFTiiCJdL+T/ZvQJBcL759ZTgWFcxC
	k8xw==
Received: by 10.204.150.92 with SMTP id x28mr9030548bkv.61.1339337759237;
	Sun, 10 Jun 2012 07:15:59 -0700 (PDT)
Received: from [192.168.0.90] ([95.237.223.176])
	by mx.google.com with ESMTPS id h18sm12993131bkh.8.2012.06.10.07.15.56
	(version=SSLv3 cipher=OTHER); Sun, 10 Jun 2012 07:15:57 -0700 (PDT)
Message-ID: <1339337051.4535.9.camel@ironlight2.geaaru.homelinux.net>
From: "Ge@@ru" <geaaru@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120608153052.GE13668@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
	<1339102908.2434.3.camel@Nokia-N900>
	<20120608153052.GE13668@phenom.dumpdata.com>
Date: Sun, 10 Jun 2012 16:04:11 +0200
Mime-Version: 1.0
X-Mailer: Evolution 3.4.2 
Cc: xen-devel@lists.xensource.com, ben@guthro.net
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, thanks for reply.

I test this kernel version but some issue.

# dmesg | grep PAT
[   11.098566] NVRM: PAT configuration unsupported, falling back to
MTRRs.

# uname -a
Linux localhost 3.4.0+ #1 SMP PREEMPT Sat Jun 9 16:37:11 CEST 2012
x86_64 Pentium(R) Dual-Core CPU E5200 @ 2.50GHz GenuineIntel GNU/Linux

On X log I see:

[   389.551] (II) NVIDIA(0): The NVIDIA X driver has encountered an
error; attempting to
[   389.551] (II) NVIDIA(0):     recover...

and on dmesg:

[  389.548750] NVRM: Xid (0000:01:00): 6, PE0001 
[  389.555804] NVRM: Xid (0000:01:00): 6, PE0001 
[  392.363472] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.365793] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.368036] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.370266] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.372486] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.374720] NVRM: Xid (0000:01:00): 6, PE007e 

/proc/mtrr doesn't exits.

While on PAT I have this:

# cat /sys/kernel/debug/x86/pat_memtype_list
PAT memtype list:
uncached-minus @ 0xcfee0000-0xcfee1000
uncached-minus @ 0xcfee3000-0xcfee8000
uncached-minus @ 0xcfee8000-0xcfee9000
write-combining @ 0xd0000000-0xd0001000
uncached-minus @ 0xe0000000-0xe4000000
uncached-minus @ 0xe0008000-0xe0009000
uncached-minus @ 0xe0100000-0xe0101000
write-combining @ 0xe4000000-0xe5000000
uncached-minus @ 0xe6000000-0xe7000000
uncached-minus @ 0xe6060000-0xe6061000
uncached-minus @ 0xe6640000-0xe6641000
uncached-minus @ 0xe6647000-0xe6648000
uncached-minus @ 0xe6647000-0xe6648000
uncached-minus @ 0xe6c02000-0xe6c03000
uncached-minus @ 0xea010000-0xea011000
uncached-minus @ 0xea100000-0xea101000
uncached-minus @ 0xea200000-0xea204000
uncached-minus @ 0xea204000-0xea205000
uncached-minus @ 0xea205000-0xea206000
uncached-minus @ 0xfed1f000-0xfed20000
uncached-minus @ 0xfed1f000-0xfed20000





On Fri, 2012-06-08 at 11:30 -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 07, 2012 at 11:01:48PM +0200, geaaru wrote:
> > Hi at all,
> > 
> > I confirm this issue on gentoo with kernel 3.4.0.
> 
> Can you try cherry-pick these two patches from stable/for-x86-3.3:
> 4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
> 
> f474007a0761d0ecb6b84ceaf4f97f4f1de92038
> 
> and revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1.
> 
> The easiest way is to do this:
> git clone  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> cd xen
> git cherry-pick 4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
> git cherry-pick f474007a0761d0ecb6b84ceaf4f97f4f1de92038
> git revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> 
> and then build the kernel and install it and such.
> 
> [What you are doing is removing the band-aid for the PAT
> issue and adding in code that allows PAT to work]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 14:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 14:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sdivz-0005XO-At; Sun, 10 Jun 2012 14:16:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1Sdivx-0005XB-RY
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 14:16:02 +0000
Received: from [85.158.139.83:64990] by server-7.bemta-5.messagelabs.com id
	EC/DC-19648-02CA4DF4; Sun, 10 Jun 2012 14:16:00 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339337759!32831012!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2863 invoked from network); 10 Jun 2012 14:15:59 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 14:15:59 -0000
Received: by bkty5 with SMTP id y5so3571132bkt.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 07:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:reply-to:to:cc:in-reply-to:references
	:content-type:date:mime-version:x-mailer:content-transfer-encoding;
	bh=JbDc8lE5a+sSKA5DMMIpd+mdhjam5FqthimLpZN+0Ik=;
	b=XEDJeRgzJIJWLHnlnY3jyHt7QtiXJ1u+zyu4Bb6k/XLvj3JwAXvPkfkh94LGe4q2/r
	j3JNAYGCezUfGKXw0hg7YzqZX+91vtkxACt5/J5G3Y1WLpseFktU/rg2yjrOcvZii0Mg
	XbFPgWpX2bZgMoqI9S6hmQwjnR6tHLY5pXtePktPIwFa5IDIXY9S77o+w0461Ql1Vl3L
	dWj7WCfKfwZG9xlhc90ot0kOuf8U7L4RanEkAzFUaiacwFrgFQLt0Lr6zNC4PQmUbM4f
	iqw059ldcLATBuNmWPd/N7+N0xgkmu6OUUSsNLkFTiiCJdL+T/ZvQJBcL759ZTgWFcxC
	k8xw==
Received: by 10.204.150.92 with SMTP id x28mr9030548bkv.61.1339337759237;
	Sun, 10 Jun 2012 07:15:59 -0700 (PDT)
Received: from [192.168.0.90] ([95.237.223.176])
	by mx.google.com with ESMTPS id h18sm12993131bkh.8.2012.06.10.07.15.56
	(version=SSLv3 cipher=OTHER); Sun, 10 Jun 2012 07:15:57 -0700 (PDT)
Message-ID: <1339337051.4535.9.camel@ironlight2.geaaru.homelinux.net>
From: "Ge@@ru" <geaaru@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120608153052.GE13668@phenom.dumpdata.com>
References: <CAJaJ6uYCzMcg0t9_PgeBc-VTYHdkwak=YQPP2HY=VE63RgYazQ@mail.gmail.com>
	<4FCA6B80.6080103@goop.org>
	<CAJaJ6ubTMvtzQpjHbFu8Sv+HJBtg_aNzc5OKfi9e-B27qt=4GQ@mail.gmail.com>
	<20120605161737.GC24031@phenom.dumpdata.com>
	<CAJaJ6uam13C1WR_pW+J_PD9GyzoJKGqYHi5+B-S5TtfO5-Ez8A@mail.gmail.com>
	<20120607155814.GP9472@phenom.dumpdata.com>
	<1339102908.2434.3.camel@Nokia-N900>
	<20120608153052.GE13668@phenom.dumpdata.com>
Date: Sun, 10 Jun 2012 16:04:11 +0200
Mime-Version: 1.0
X-Mailer: Evolution 3.4.2 
Cc: xen-devel@lists.xensource.com, ben@guthro.net
Subject: Re: [Xen-devel] XEN MTRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, thanks for reply.

I test this kernel version but some issue.

# dmesg | grep PAT
[   11.098566] NVRM: PAT configuration unsupported, falling back to
MTRRs.

# uname -a
Linux localhost 3.4.0+ #1 SMP PREEMPT Sat Jun 9 16:37:11 CEST 2012
x86_64 Pentium(R) Dual-Core CPU E5200 @ 2.50GHz GenuineIntel GNU/Linux

On X log I see:

[   389.551] (II) NVIDIA(0): The NVIDIA X driver has encountered an
error; attempting to
[   389.551] (II) NVIDIA(0):     recover...

and on dmesg:

[  389.548750] NVRM: Xid (0000:01:00): 6, PE0001 
[  389.555804] NVRM: Xid (0000:01:00): 6, PE0001 
[  392.363472] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.365793] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.368036] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.370266] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.372486] NVRM: Xid (0000:01:00): 6, PE007e 
[  392.374720] NVRM: Xid (0000:01:00): 6, PE007e 

/proc/mtrr doesn't exits.

While on PAT I have this:

# cat /sys/kernel/debug/x86/pat_memtype_list
PAT memtype list:
uncached-minus @ 0xcfee0000-0xcfee1000
uncached-minus @ 0xcfee3000-0xcfee8000
uncached-minus @ 0xcfee8000-0xcfee9000
write-combining @ 0xd0000000-0xd0001000
uncached-minus @ 0xe0000000-0xe4000000
uncached-minus @ 0xe0008000-0xe0009000
uncached-minus @ 0xe0100000-0xe0101000
write-combining @ 0xe4000000-0xe5000000
uncached-minus @ 0xe6000000-0xe7000000
uncached-minus @ 0xe6060000-0xe6061000
uncached-minus @ 0xe6640000-0xe6641000
uncached-minus @ 0xe6647000-0xe6648000
uncached-minus @ 0xe6647000-0xe6648000
uncached-minus @ 0xe6c02000-0xe6c03000
uncached-minus @ 0xea010000-0xea011000
uncached-minus @ 0xea100000-0xea101000
uncached-minus @ 0xea200000-0xea204000
uncached-minus @ 0xea204000-0xea205000
uncached-minus @ 0xea205000-0xea206000
uncached-minus @ 0xfed1f000-0xfed20000
uncached-minus @ 0xfed1f000-0xfed20000





On Fri, 2012-06-08 at 11:30 -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 07, 2012 at 11:01:48PM +0200, geaaru wrote:
> > Hi at all,
> > 
> > I confirm this issue on gentoo with kernel 3.4.0.
> 
> Can you try cherry-pick these two patches from stable/for-x86-3.3:
> 4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
> 
> f474007a0761d0ecb6b84ceaf4f97f4f1de92038
> 
> and revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1.
> 
> The easiest way is to do this:
> git clone  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> cd xen
> git cherry-pick 4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
> git cherry-pick f474007a0761d0ecb6b84ceaf4f97f4f1de92038
> git revert 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> 
> and then build the kernel and install it and such.
> 
> [What you are doing is removing the band-aid for the PAT
> issue and adding in code that allows PAT to work]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 10 18:51:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 18: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 1SdnEA-00075H-Ba; Sun, 10 Jun 2012 18:51:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cplusplus328@gmail.com>) id 1SdnE8-00075C-M2
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 18:51:04 +0000
Received: from [193.109.254.147:58897] by server-10.bemta-14.messagelabs.com
	id F6/2C-25709-89CE4DF4; Sun, 10 Jun 2012 18:51:04 +0000
X-Env-Sender: cplusplus328@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339354262!9081965!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17147 invoked from network); 10 Jun 2012 18:51:03 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 18:51:03 -0000
Received: by lahg1 with SMTP id g1so2788516lah.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 11:51:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=g7Vq4+8KseWut/OfgNUJuqCdjVg+tJIAju4qPiX6Wzo=;
	b=U1/BWASH9jHR5PyjIZXxNhN/Xh5fyqFvt+Eu2nYa/XwpFz4PonsboImoSMHpHFpMD4
	yAiXz49Zh3CeY6Lf406DNFBVwkWxV9q8Ai1GgKp0XqhN+AG3AclAhWkg2Ma67rpQpxKt
	crnERCjBREkcHUQttfjfxxSbL+egwnVHaSPtbkd+BQKO/bblF8ksXiMwunY3uv9kuU6t
	cXuXeS6/Cx10amIKJf7PmfQlNa60dsDUhjdW4ButIpCVxIv/7GKmlcODCm2duh6lS/JI
	tL4gcgimx6OHa+4DJr9Q4Aku/Gt2Msu+9RjF7WfrL5wN7Npmf68sTDcvu9b3TlJpTVji
	21QA==
Received: by 10.152.144.133 with SMTP id sm5mr15269962lab.4.1339354262366;
	Sun, 10 Jun 2012 11:51:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.21.5 with HTTP; Sun, 10 Jun 2012 11:50:42 -0700 (PDT)
In-Reply-To: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
References: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
From: Aaron Lebahn <cplusplus328@gmail.com>
Date: Sun, 10 Jun 2012 12:50:42 -0600
Message-ID: <CALJtybT2OARKqv67M7YcLBQHNuShNzk16PghSsS8+mL0=4PTDA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xenbits 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="===============8493724849738956037=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8493724849738956037==
Content-Type: multipart/alternative; boundary=e89a8f234963096a4704c222b70d

--e89a8f234963096a4704c222b70d
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jun 10, 2012 at 3:46 AM, Aaron Lebahn <cplusplus328@gmail.com>wrote:

> Xenbits seems to be down. It was acting slow before it went.
>
> --
> Aaron Lebahn
> cplusplus328@gmail.com
>

Does anyone have a mirror for the xen-unstable Mercurial repo?

-- 
Aaron Lebahn
cplusplus328@gmail.com

--e89a8f234963096a4704c222b70d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Sun, Jun 10, 2012 at 3:46 AM, Aaron Lebah=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:cplusplus328@gmail.com" target=3D=
"_blank">cplusplus328@gmail.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">

Xenbits seems to be down. It was acting slow before it went.<span class=3D"=
HOEnZb"><font color=3D"#888888"><br clear=3D"all"><br>-- <br>Aaron Lebahn<b=
r><a href=3D"mailto:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@=
gmail.com</a><br>


</font></span></blockquote></div><br>Does anyone have a mirror for the xen-=
unstable Mercurial repo?<br clear=3D"all"><br>-- <br>Aaron Lebahn<br><a hre=
f=3D"mailto:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@gmail.co=
m</a><br>



--e89a8f234963096a4704c222b70d--


--===============8493724849738956037==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8493724849738956037==--


From xen-devel-bounces@lists.xen.org Sun Jun 10 18:51:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 18: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 1SdnEA-00075H-Ba; Sun, 10 Jun 2012 18:51:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cplusplus328@gmail.com>) id 1SdnE8-00075C-M2
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 18:51:04 +0000
Received: from [193.109.254.147:58897] by server-10.bemta-14.messagelabs.com
	id F6/2C-25709-89CE4DF4; Sun, 10 Jun 2012 18:51:04 +0000
X-Env-Sender: cplusplus328@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339354262!9081965!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17147 invoked from network); 10 Jun 2012 18:51:03 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 18:51:03 -0000
Received: by lahg1 with SMTP id g1so2788516lah.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 11:51:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=g7Vq4+8KseWut/OfgNUJuqCdjVg+tJIAju4qPiX6Wzo=;
	b=U1/BWASH9jHR5PyjIZXxNhN/Xh5fyqFvt+Eu2nYa/XwpFz4PonsboImoSMHpHFpMD4
	yAiXz49Zh3CeY6Lf406DNFBVwkWxV9q8Ai1GgKp0XqhN+AG3AclAhWkg2Ma67rpQpxKt
	crnERCjBREkcHUQttfjfxxSbL+egwnVHaSPtbkd+BQKO/bblF8ksXiMwunY3uv9kuU6t
	cXuXeS6/Cx10amIKJf7PmfQlNa60dsDUhjdW4ButIpCVxIv/7GKmlcODCm2duh6lS/JI
	tL4gcgimx6OHa+4DJr9Q4Aku/Gt2Msu+9RjF7WfrL5wN7Npmf68sTDcvu9b3TlJpTVji
	21QA==
Received: by 10.152.144.133 with SMTP id sm5mr15269962lab.4.1339354262366;
	Sun, 10 Jun 2012 11:51:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.21.5 with HTTP; Sun, 10 Jun 2012 11:50:42 -0700 (PDT)
In-Reply-To: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
References: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
From: Aaron Lebahn <cplusplus328@gmail.com>
Date: Sun, 10 Jun 2012 12:50:42 -0600
Message-ID: <CALJtybT2OARKqv67M7YcLBQHNuShNzk16PghSsS8+mL0=4PTDA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xenbits 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="===============8493724849738956037=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8493724849738956037==
Content-Type: multipart/alternative; boundary=e89a8f234963096a4704c222b70d

--e89a8f234963096a4704c222b70d
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jun 10, 2012 at 3:46 AM, Aaron Lebahn <cplusplus328@gmail.com>wrote:

> Xenbits seems to be down. It was acting slow before it went.
>
> --
> Aaron Lebahn
> cplusplus328@gmail.com
>

Does anyone have a mirror for the xen-unstable Mercurial repo?

-- 
Aaron Lebahn
cplusplus328@gmail.com

--e89a8f234963096a4704c222b70d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Sun, Jun 10, 2012 at 3:46 AM, Aaron Lebah=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:cplusplus328@gmail.com" target=3D=
"_blank">cplusplus328@gmail.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">

Xenbits seems to be down. It was acting slow before it went.<span class=3D"=
HOEnZb"><font color=3D"#888888"><br clear=3D"all"><br>-- <br>Aaron Lebahn<b=
r><a href=3D"mailto:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@=
gmail.com</a><br>


</font></span></blockquote></div><br>Does anyone have a mirror for the xen-=
unstable Mercurial repo?<br clear=3D"all"><br>-- <br>Aaron Lebahn<br><a hre=
f=3D"mailto:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@gmail.co=
m</a><br>



--e89a8f234963096a4704c222b70d--


--===============8493724849738956037==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8493724849738956037==--


From xen-devel-bounces@lists.xen.org Sun Jun 10 23:35:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 23:35: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 1Sdre7-0008A5-W0; Sun, 10 Jun 2012 23:34:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cplusplus328@gmail.com>) id 1Sdre7-0008A0-7U
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 23:34:11 +0000
Received: from [85.158.143.99:49027] by server-1.bemta-4.messagelabs.com id
	A3/98-10042-2FE25DF4; Sun, 10 Jun 2012 23:34:10 +0000
X-Env-Sender: cplusplus328@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339371247!26885400!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30092 invoked from network); 10 Jun 2012 23:34:08 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 23:34:08 -0000
Received: by lahg1 with SMTP id g1so2875783lah.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 16:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=5QGUT7oecetS65C5Ea0gJb6Ct22AGQbXmiRrAcsQpWo=;
	b=kTsdmZIoDj0Y8kL366ZlzuHrdV+OmoU8JTlrTWRVXnov0ViqWwBMwL+4Opk872iYwW
	pp4xpC6DgolQbCB4kqOq0FEJWRpn9ZtQdn/zINLWHIHGDKTkr6IuPq9JPpuA30odBCsr
	Xa7HErM+sdXAYcLNsRrCwB1ZhE09NanhoYqspBnI36OuR3d2VA54QOe2u/0aIwXUXr97
	xLD9hb4HAwkpWLwj7Ul2N2FwDWJ0c6QOiiQUXDSNd+CupOiPa447EUWyb2v6gur7xwHc
	wUQsFwIDjMKjut5NMhTiQkKszq22ik+uFU260yrsT21OteRpJrULXqAJfyYN/DXs3SeJ
	jCTA==
Received: by 10.152.146.163 with SMTP id td3mr15709706lab.26.1339371247334;
	Sun, 10 Jun 2012 16:34:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.21.5 with HTTP; Sun, 10 Jun 2012 16:33:47 -0700 (PDT)
In-Reply-To: <CALJtybT2OARKqv67M7YcLBQHNuShNzk16PghSsS8+mL0=4PTDA@mail.gmail.com>
References: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
	<CALJtybT2OARKqv67M7YcLBQHNuShNzk16PghSsS8+mL0=4PTDA@mail.gmail.com>
From: Aaron Lebahn <cplusplus328@gmail.com>
Date: Sun, 10 Jun 2012 17:33:47 -0600
Message-ID: <CALJtybQGmn-B-bbAZnKjh+EsxAOwWGBzQFzAuM2rG8dPKjnGRA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [Solved] xenbits 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="===============4992608188844770856=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4992608188844770856==
Content-Type: multipart/alternative; boundary=e89a8f2345676b73b804c226ab6b

--e89a8f2345676b73b804c226ab6b
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jun 10, 2012 at 12:50 PM, Aaron Lebahn <cplusplus328@gmail.com>wrote:

>
> On Sun, Jun 10, 2012 at 3:46 AM, Aaron Lebahn <cplusplus328@gmail.com>wrote:
>
>> Xenbits seems to be down. It was acting slow before it went.
>>
>> --
>> Aaron Lebahn
>> cplusplus328@gmail.com
>>
>
> Does anyone have a mirror for the xen-unstable Mercurial repo?
>
> --
> Aaron Lebahn
> cplusplus328@gmail.com
>

It seems to be working now. Thanks. I have enjoyed our one-sided
conversation.

-- 
Aaron Lebahn
cplusplus328@gmail.com

--e89a8f2345676b73b804c226ab6b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Jun 10, 2012 at 12:50 PM, Aaron =
Lebahn <span dir=3D"ltr">&lt;<a href=3D"mailto:cplusplus328@gmail.com" targ=
et=3D"_blank">cplusplus328@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5"><br><div class=3D"gmail_quote">On S=
un, Jun 10, 2012 at 3:46 AM, Aaron Lebahn <span dir=3D"ltr">&lt;<a href=3D"=
mailto:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@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">
Xenbits seems to be down. It was acting slow before it went.<span><font col=
or=3D"#888888"><br clear=3D"all"><br>-- <br>Aaron Lebahn<br><a href=3D"mail=
to:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@gmail.com</a><br>

</font></span></blockquote></div><br></div></div>Does anyone have a mirror =
for the xen-unstable Mercurial repo?<span class=3D"HOEnZb"><font color=3D"#=
888888"><br clear=3D"all"><br>-- <br>Aaron Lebahn<br><a href=3D"mailto:cplu=
splus328@gmail.com" target=3D"_blank">cplusplus328@gmail.com</a><br>



</font></span></blockquote></div><br>It seems to be working now. Thanks. I =
have enjoyed our one-sided conversation.<br clear=3D"all"><br>-- <br>Aaron =
Lebahn<br><a href=3D"mailto:cplusplus328@gmail.com" target=3D"_blank">cplus=
plus328@gmail.com</a><br>



--e89a8f2345676b73b804c226ab6b--


--===============4992608188844770856==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4992608188844770856==--


From xen-devel-bounces@lists.xen.org Sun Jun 10 23:35:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Jun 2012 23:35: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 1Sdre7-0008A5-W0; Sun, 10 Jun 2012 23:34:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cplusplus328@gmail.com>) id 1Sdre7-0008A0-7U
	for xen-devel@lists.xensource.com; Sun, 10 Jun 2012 23:34:11 +0000
Received: from [85.158.143.99:49027] by server-1.bemta-4.messagelabs.com id
	A3/98-10042-2FE25DF4; Sun, 10 Jun 2012 23:34:10 +0000
X-Env-Sender: cplusplus328@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339371247!26885400!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30092 invoked from network); 10 Jun 2012 23:34:08 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jun 2012 23:34:08 -0000
Received: by lahg1 with SMTP id g1so2875783lah.30
	for <xen-devel@lists.xensource.com>;
	Sun, 10 Jun 2012 16:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=5QGUT7oecetS65C5Ea0gJb6Ct22AGQbXmiRrAcsQpWo=;
	b=kTsdmZIoDj0Y8kL366ZlzuHrdV+OmoU8JTlrTWRVXnov0ViqWwBMwL+4Opk872iYwW
	pp4xpC6DgolQbCB4kqOq0FEJWRpn9ZtQdn/zINLWHIHGDKTkr6IuPq9JPpuA30odBCsr
	Xa7HErM+sdXAYcLNsRrCwB1ZhE09NanhoYqspBnI36OuR3d2VA54QOe2u/0aIwXUXr97
	xLD9hb4HAwkpWLwj7Ul2N2FwDWJ0c6QOiiQUXDSNd+CupOiPa447EUWyb2v6gur7xwHc
	wUQsFwIDjMKjut5NMhTiQkKszq22ik+uFU260yrsT21OteRpJrULXqAJfyYN/DXs3SeJ
	jCTA==
Received: by 10.152.146.163 with SMTP id td3mr15709706lab.26.1339371247334;
	Sun, 10 Jun 2012 16:34:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.21.5 with HTTP; Sun, 10 Jun 2012 16:33:47 -0700 (PDT)
In-Reply-To: <CALJtybT2OARKqv67M7YcLBQHNuShNzk16PghSsS8+mL0=4PTDA@mail.gmail.com>
References: <CALJtybQNm45N_vBPFZNHbPV3co_Lwc+XweJ97X7xhPqA65kVRg@mail.gmail.com>
	<CALJtybT2OARKqv67M7YcLBQHNuShNzk16PghSsS8+mL0=4PTDA@mail.gmail.com>
From: Aaron Lebahn <cplusplus328@gmail.com>
Date: Sun, 10 Jun 2012 17:33:47 -0600
Message-ID: <CALJtybQGmn-B-bbAZnKjh+EsxAOwWGBzQFzAuM2rG8dPKjnGRA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [Solved] xenbits 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="===============4992608188844770856=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4992608188844770856==
Content-Type: multipart/alternative; boundary=e89a8f2345676b73b804c226ab6b

--e89a8f2345676b73b804c226ab6b
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jun 10, 2012 at 12:50 PM, Aaron Lebahn <cplusplus328@gmail.com>wrote:

>
> On Sun, Jun 10, 2012 at 3:46 AM, Aaron Lebahn <cplusplus328@gmail.com>wrote:
>
>> Xenbits seems to be down. It was acting slow before it went.
>>
>> --
>> Aaron Lebahn
>> cplusplus328@gmail.com
>>
>
> Does anyone have a mirror for the xen-unstable Mercurial repo?
>
> --
> Aaron Lebahn
> cplusplus328@gmail.com
>

It seems to be working now. Thanks. I have enjoyed our one-sided
conversation.

-- 
Aaron Lebahn
cplusplus328@gmail.com

--e89a8f2345676b73b804c226ab6b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Jun 10, 2012 at 12:50 PM, Aaron =
Lebahn <span dir=3D"ltr">&lt;<a href=3D"mailto:cplusplus328@gmail.com" targ=
et=3D"_blank">cplusplus328@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5"><br><div class=3D"gmail_quote">On S=
un, Jun 10, 2012 at 3:46 AM, Aaron Lebahn <span dir=3D"ltr">&lt;<a href=3D"=
mailto:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@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">
Xenbits seems to be down. It was acting slow before it went.<span><font col=
or=3D"#888888"><br clear=3D"all"><br>-- <br>Aaron Lebahn<br><a href=3D"mail=
to:cplusplus328@gmail.com" target=3D"_blank">cplusplus328@gmail.com</a><br>

</font></span></blockquote></div><br></div></div>Does anyone have a mirror =
for the xen-unstable Mercurial repo?<span class=3D"HOEnZb"><font color=3D"#=
888888"><br clear=3D"all"><br>-- <br>Aaron Lebahn<br><a href=3D"mailto:cplu=
splus328@gmail.com" target=3D"_blank">cplusplus328@gmail.com</a><br>



</font></span></blockquote></div><br>It seems to be working now. Thanks. I =
have enjoyed our one-sided conversation.<br clear=3D"all"><br>-- <br>Aaron =
Lebahn<br><a href=3D"mailto:cplusplus328@gmail.com" target=3D"_blank">cplus=
plus328@gmail.com</a><br>



--e89a8f2345676b73b804c226ab6b--


--===============4992608188844770856==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4992608188844770856==--


From xen-devel-bounces@lists.xen.org Mon Jun 11 00:02:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 00:02: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 1Sds4l-0000L5-Cv; Mon, 11 Jun 2012 00:01:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1Sds4j-0000L0-D5
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 00:01:41 +0000
Received: from [85.158.143.35:27531] by server-2.bemta-4.messagelabs.com id
	A7/DC-17938-46535DF4; Mon, 11 Jun 2012 00:01:40 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339372896!11719323!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20522 invoked from network); 11 Jun 2012 00:01:37 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 00:01:37 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5C4DA90B49;
	Mon, 11 Jun 2012 02:01:36 +0200 (CEST)
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
To: qemu-devel@nongnu.org
Date: Mon, 11 Jun 2012 02:00:55 +0200
Message-Id: <1339372859-30148-24-git-send-email-afaerber@suse.de>
X-Mailer: git-send-email 1.7.7
In-Reply-To: <1339372859-30148-1-git-send-email-afaerber@suse.de>
References: <1339372859-30148-1-git-send-email-afaerber@suse.de>
MIME-Version: 1.0
Cc: "open list:X86" <xen-devel@lists.xensource.com>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/27] xen_machine_pv: Use cpu_x86_init() to
	obtain X86CPU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

TmVlZGVkIGZvciBtb3ZpbmcgaGFsdGVkIGZpZWxkIHRvIENQVVN0YXRlLgoKU2lnbmVkLW9mZi1i
eTogQW5kcmVhcyBGw6RyYmVyIDxhZmFlcmJlckBzdXNlLmRlPgpUZXN0ZWQtYnk6IFN0ZWZhbm8g
U3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+Ci0tLQogaHcveGVu
X21hY2hpbmVfcHYuYyB8ICAgIDQgKysrLQogMSBmaWxlcyBjaGFuZ2VkLCAzIGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvaHcveGVuX21hY2hpbmVfcHYuYyBiL2h3
L3hlbl9tYWNoaW5lX3B2LmMKaW5kZXggN2VlZTc3MC4uNGI3MmFhNyAxMDA2NDQKLS0tIGEvaHcv
eGVuX21hY2hpbmVfcHYuYworKysgYi9ody94ZW5fbWFjaGluZV9wdi5jCkBAIC0zNiw2ICszNiw3
IEBAIHN0YXRpYyB2b2lkIHhlbl9pbml0X3B2KHJhbV9hZGRyX3QgcmFtX3NpemUsCiAJCQljb25z
dCBjaGFyICppbml0cmRfZmlsZW5hbWUsCiAJCQljb25zdCBjaGFyICpjcHVfbW9kZWwpCiB7Cisg
ICAgWDg2Q1BVICpjcHU7CiAgICAgQ1BVWDg2U3RhdGUgKmVudjsKICAgICBEcml2ZUluZm8gKmRp
bmZvOwogICAgIGludCBpOwpAQCAtNDgsNyArNDksOCBAQCBzdGF0aWMgdm9pZCB4ZW5faW5pdF9w
dihyYW1fYWRkcl90IHJhbV9zaXplLAogICAgICAgICBjcHVfbW9kZWwgPSAicWVtdTMyIjsKICNl
bmRpZgogICAgIH0KLSAgICBlbnYgPSBjcHVfaW5pdChjcHVfbW9kZWwpOworICAgIGNwdSA9IGNw
dV94ODZfaW5pdChjcHVfbW9kZWwpOworICAgIGVudiA9ICZjcHUtPmVudjsKICAgICBlbnYtPmhh
bHRlZCA9IDE7CiAKICAgICAvKiBJbml0aWFsaXplIGJhY2tlbmQgY29yZSAmIGRyaXZlcnMgKi8K
LS0gCjEuNy43CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Jun 11 00:02:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 00:02: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 1Sds4l-0000L5-Cv; Mon, 11 Jun 2012 00:01:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1Sds4j-0000L0-D5
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 00:01:41 +0000
Received: from [85.158.143.35:27531] by server-2.bemta-4.messagelabs.com id
	A7/DC-17938-46535DF4; Mon, 11 Jun 2012 00:01:40 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339372896!11719323!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20522 invoked from network); 11 Jun 2012 00:01:37 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 00:01:37 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5C4DA90B49;
	Mon, 11 Jun 2012 02:01:36 +0200 (CEST)
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
To: qemu-devel@nongnu.org
Date: Mon, 11 Jun 2012 02:00:55 +0200
Message-Id: <1339372859-30148-24-git-send-email-afaerber@suse.de>
X-Mailer: git-send-email 1.7.7
In-Reply-To: <1339372859-30148-1-git-send-email-afaerber@suse.de>
References: <1339372859-30148-1-git-send-email-afaerber@suse.de>
MIME-Version: 1.0
Cc: "open list:X86" <xen-devel@lists.xensource.com>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/27] xen_machine_pv: Use cpu_x86_init() to
	obtain X86CPU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

TmVlZGVkIGZvciBtb3ZpbmcgaGFsdGVkIGZpZWxkIHRvIENQVVN0YXRlLgoKU2lnbmVkLW9mZi1i
eTogQW5kcmVhcyBGw6RyYmVyIDxhZmFlcmJlckBzdXNlLmRlPgpUZXN0ZWQtYnk6IFN0ZWZhbm8g
U3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+Ci0tLQogaHcveGVu
X21hY2hpbmVfcHYuYyB8ICAgIDQgKysrLQogMSBmaWxlcyBjaGFuZ2VkLCAzIGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvaHcveGVuX21hY2hpbmVfcHYuYyBiL2h3
L3hlbl9tYWNoaW5lX3B2LmMKaW5kZXggN2VlZTc3MC4uNGI3MmFhNyAxMDA2NDQKLS0tIGEvaHcv
eGVuX21hY2hpbmVfcHYuYworKysgYi9ody94ZW5fbWFjaGluZV9wdi5jCkBAIC0zNiw2ICszNiw3
IEBAIHN0YXRpYyB2b2lkIHhlbl9pbml0X3B2KHJhbV9hZGRyX3QgcmFtX3NpemUsCiAJCQljb25z
dCBjaGFyICppbml0cmRfZmlsZW5hbWUsCiAJCQljb25zdCBjaGFyICpjcHVfbW9kZWwpCiB7Cisg
ICAgWDg2Q1BVICpjcHU7CiAgICAgQ1BVWDg2U3RhdGUgKmVudjsKICAgICBEcml2ZUluZm8gKmRp
bmZvOwogICAgIGludCBpOwpAQCAtNDgsNyArNDksOCBAQCBzdGF0aWMgdm9pZCB4ZW5faW5pdF9w
dihyYW1fYWRkcl90IHJhbV9zaXplLAogICAgICAgICBjcHVfbW9kZWwgPSAicWVtdTMyIjsKICNl
bmRpZgogICAgIH0KLSAgICBlbnYgPSBjcHVfaW5pdChjcHVfbW9kZWwpOworICAgIGNwdSA9IGNw
dV94ODZfaW5pdChjcHVfbW9kZWwpOworICAgIGVudiA9ICZjcHUtPmVudjsKICAgICBlbnYtPmhh
bHRlZCA9IDE7CiAKICAgICAvKiBJbml0aWFsaXplIGJhY2tlbmQgY29yZSAmIGRyaXZlcnMgKi8K
LS0gCjEuNy43CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Jun 11 01:54:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 01:54: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 1SdtpF-0004YZ-PY; Mon, 11 Jun 2012 01:53:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yoshink@alpha.co.jp>) id 1SdtpE-0004YU-Tf
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 01:53:49 +0000
Received: from [85.158.139.83:52323] by server-5.bemta-5.messagelabs.com id
	B7/C1-04481-CAF45DF4; Mon, 11 Jun 2012 01:53:48 +0000
X-Env-Sender: yoshink@alpha.co.jp
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339379624!32872495!1
X-Originating-IP: [219.127.235.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26448 invoked from network); 11 Jun 2012 01:53:45 -0000
Received: from mgw1.alpha.co.jp (HELO mgw1.alpha.co.jp) (219.127.235.68)
	by server-12.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 01:53:45 -0000
Received: from (unknown [10.133.235.68]) by SPS-0013.alpha.co.jp with smtp
	id 2da3_1c3d_7d74876e_b368_11e1_9249_001517fbe004;
	Mon, 11 Jun 2012 10:55:17 +0900
Received: from ms4.alpha.co.jp (ms4.alpha.co.jp [10.108.1.42])
	by mgw1.alpha.co.jp (Postfix) with ESMTP id C49CBA7C59F;
	Mon, 11 Jun 2012 10:53:40 +0900 (JST)
Received: from (unknown [10.108.1.42]) by SPS-0013.alpha.co.jp with smtp
	id 2da3_1c2d_7c1aa402_b368_11e1_9249_001517fbe004;
	Mon, 11 Jun 2012 10:55:13 +0900
Received: from [10.146.176.222] (unknown [10.146.176.222])
	by ms4.alpha.co.jp (Postfix) with ESMTP id 543B219F01E2;
	Mon, 11 Jun 2012 10:53:40 +0900 (JST)
Message-ID: <4FD54FA4.1070704@alpha.co.jp>
Date: Mon, 11 Jun 2012 10:53:40 +0900
From: Kazuto Yoshino <yoshink@alpha.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: james.harper@bendigoit.com.au, xen-devel@lists.xen.org
References: <4FD20009.7000302@alpha.co.jp>
	<6035A0D088A63A46850C3988ED045A4B28904C1B@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B28904C1B@BITCOM1.int.sbss.com.au>
Subject: Re: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

I think that this patch is insufficient.
Although work is carried out, it is very doubtful.
Would you correct to the better form, if possible?


Thanks,
Kazuto Yoshino.

(2012/06/10 13:49), James Harper wrote:
> Thanks for that. That locking code is really nasty... do you think your patch is fixing the problem or just working around it?
>
> James
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Kazuto Yoshino
>> Sent: Friday, 8 June 2012 11:37 PM
>> To: xen-devel@lists.xen.org; yoshink@alpha.co.jp
>> Subject: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
>>
>> Hi all,
>>
>> SCSI passthrough of DVD drive is tried on Windows.
>> If vcpus=1 is used, it works.
>> However, if vcpus=2 is used, it does not work.
>> The log is as follows.
>>
>>
>> Hardware:
>> DELL Optiplex 990
>> Intel Core i5 2500
>>
>>
>> Software:
>> xen 4.2-unstable (25452:6bea63e6c780)
>> dom0: Linux 3.1.0-rc10+ 64bit
>> domU: Windows 7 SP1 64bit
>> GPLPV 0.10.0.357
>>
>>
>> domU config:
>> kernel = "hvmloader"
>> builder='hvm'
>> memory = 2048
>> name = "win7x64"
>> vcpus=2
>> vif = [ 'type=ioemu, mac=00:16:3e:19:18:7b, bridge=virbr0' ] disk = [
>> 'file:/etc/xen/win7x64.img,hda,w' ] device_model = 'qemu-dm'
>> sdl=0
>> opengl=1
>> vnc=1
>> vnclisten="0.0.0.0"
>> vncpasswd=''
>> stdvga=0
>> serial='pty'
>> tsc_mode=0
>>
>>
>> command:
>> # xm create /etc/xen/win7x64.hvm
>> # xm scsi-attach win7x64 1:0:0:0 2:0:0:0
>>
>>
>> qemu-dm log:
>> 12983594247656: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247656: XenPCI     Rescanning child list
>> 12983594247656: XenPCI -->  XenPci_EvtChildListScanForChildren
>> 12983594247656: XenPCI     Found path = device/vbd/768
>> 12983594247656: XenPCI     Found path = device/vif/0
>> 12983594247671: XenPCI     Found path = device/vscsi/2
>> 12983594247671: XenPCI<-- XenPci_EvtChildListScanForChildren
>> 12983594247671: XenPCI -->  XenPci_EvtChildListCreateDevice
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     device = 'vscsi', index = '2', path =
>> 'device/vscsi/2'
>> 12983594247671: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI<-- XenPci_EvtChildListCreateDevice
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI -->
>> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
>> 12983594247671: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     device/vscsi/2
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     CmResourceTypeMemory (0)
>> 12983594247671: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     Start = f2000000, Length = 0
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247687: XenPCI     pfn[0] = 0000d445
>> 12983594247687: XenPCI     New Start = 000000000d445000, Length = 4096
>> 12983594247687: XenPCI     CmResourceTypeMemory (1)
>> 12983594247687: XenPCI     Start = f2000001, Length = 0
>> 12983594247687: XenPCI<--
>> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
>> 12983594247687: XenPCI -->  XenPciPdo_EvtDevicePrepareHardware
>> 12983594247687: XenPCI<-- XenPciPdo_EvtDevicePrepareHardware
>> 12983594247687: XenPCI -->  XenPciPdo_EvtDeviceD0Entry
>> 12983594247687: XenPCI     path = device/vscsi/2
>> 12983594247687: XenPCI     WdfPowerDeviceD3Final
>> 12983594247687: XenPCI -->  XenPci_GetBackendAndAddWatch
>> 12983594247687: XenPCI<-- XenPci_GetBackendAndAddWatch
>> 12983594247687: XenPCI -->  XenPci_UpdateBackendState
>> 12983594247687: XenPCI -->  XenConfig_InitConfigPage
>> 12983594247687: XenPCI     Backend State Changed to InitWait
>> 12983594247687: XenPCI     fdo_driver_object = FFFFFA80025B9E70
>> 12983594247687: XenPCI<-- XenPci_UpdateBackendState
>> 12983594247687: XenPCI     fdo_driver_extension = FFFFFA8001869010
>> 12983594247703: XenPCI<-- XenConfig_InitConfigPage
>> 12983594247703: XenPCI -->  XenPci_XenConfigDeviceSpecifyBuffers
>> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref =
>> FFFFFA8002AB9000
>> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
>> 12983594247703: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
>> channel = 8
>> 12983594247703: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI -->  EvtChn_BindIrq
>> 12983594247703: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI<-- EvtChn_BindIrq
>> 12983594247703: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI -->  XenPci_ChangeFrontendStateMap
>> 12983594247703: XenPCI -->  XenPci_ChangeFrontendState
>> 12983594247703: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI -->  XenPci_UpdateBackendState
>> 12983594247718: XenPCI     Backend State Changed to Connected
>> 12983594247718: XenPCI<-- XenPci_UpdateBackendState
>> 12983594247718: XenPCI<-- XenPci_ChangeFrontendState
>> 12983594247718: XenPCI<-- XenPci_ChangeFrontendStateMap
>> 12983594247718: XenPCI -->  XenPci_ChangeFrontendStateMap
>> 12983594247718: XenPCI -->  XenPci_ChangeFrontendState
>> 12983594247734: XenPCI<-- XenPci_ChangeFrontendState
>> 12983594247734: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247734: XenPCI<-- XenPci_ChangeFrontendStateMap
>> 12983594247734: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247734: XenPCI<-- XenPci_XenConfigDeviceSpecifyBuffers
>> 12983594247734: XenPCI<-- XenPciPdo_EvtDeviceD0Entry
>> 12983594247734: XenSCSI -->  XenScsi_HwScsiFindAdapter
>> 12983594247734: XenSCSI     IRQL = 0
>> 12983594247734: XenSCSI     BusInterruptLevel = 28
>> 12983594247734: XenSCSI     BusInterruptVector = 01c
>> 12983594247734: XenSCSI     RangeStart = 0d445000, RangeLength = 00001000
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_13
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_VECTORS
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_11
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_RING - ring-ref =
>> FFFFFA8002AB9000
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
>> channel = 8
>> 12983594247750: XenSCSI     XEN_INIT_TYPE_GRANT_ENTRIES - 144
>> 12983594247750: XenSCSI     Dma64BitAddresses supported
>> 12983594247750: XenPCI -->  XenPci_XenBus_AddWatch
>> 12983594247750: XenPCI     XenPci_XenBus_AddWatch -
>> /local/domain/0/backend/vscsi/3/2/vscsi-devs = NULL
>> 12983594247750: XenSCSI -->  XenScsi_DevWatch
>> 12983594247750: XenPCI<-- XenPci_XenBus_AddWatch
>> 12983594247750: XenSCSI     Waiting for pause...
>> 12983594247750: XenSCSI<-- XenScsi_HwScsiFindAdapter
>> 12983594247750: XenSCSI -->  XenScsi_HwScsiInitialize
>> 12983594247750: XenSCSI<-- XenScsi_HwScsiInitialize
>> 12983594247750: XenSCSI -->  XenScsi_HwScsiAdapterControl
>> 12983594247750: XenSCSI     IRQL = 0
>> 12983594247750: XenSCSI     ScsiQuerySupportedControlTypes (Max = 5)
>> 12983594247750: XenSCSI<-- XenScsi_HwScsiAdapterControl
>> 12983594247750: XenSCSI     Busy
>> 12983594247859: XenSCSI     Waiting for pause...
>> 12983594247968: XenSCSI     Waiting for pause...
>> 12983594248078: XenSCSI     Waiting for pause...
>> 12983594248187: XenSCSI     Waiting for pause...
>> 12983594248296: XenSCSI     Waiting for pause...
>> 12983594248406: XenSCSI     Waiting for pause...
>> 12983594248515: XenSCSI     Waiting for pause...
>> 12983594248625: XenSCSI     Waiting for pause...
>> 12983594248734: XenSCSI     Waiting for pause...
>> 12983594248843: XenSCSI     Waiting for pause...
>>
>>
>>
>> It worked, when correcting the source code of GPLPV as follows.
>>
>>
>> --- a/xenscsi/xenscsi.c
>> +++ b/xenscsi/xenscsi.c
>> @@ -278,17 +278,27 @@
>>       /* this can only be called from a watch and so is always serialised */
>>       FUNCTION_ENTER();
>>
>> -  #if DBG
>> -  oldpause =
>> -  #endif
>> -    InterlockedExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_PASSIVE_PAUSED);
>> -  ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
>> -
>> -  while (InterlockedCompareExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_SCSIPORT_PAUSED,
>> SHARED_PAUSED_SCSIPORT_PAUSED) !=
>> SHARED_PAUSED_SCSIPORT_PAUSED)
>> +  while (1)
>>       {
>> -    KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
>> -    wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
>> -    KeDelayExecutionThread(KernelMode, FALSE,&wait_time);
>> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_SCSIPORT_UNPAUSED,
>> SHARED_PAUSED_SCSIPORT_UNPAUSED) ==
>> SHARED_PAUSED_SCSIPORT_UNPAUSED)
>> +    {
>> +      #if DBG
>> +      oldpause =
>> +      #endif
>> +        InterlockedExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_PASSIVE_PAUSED);
>> +      ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
>> +    }
>> +
>> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_SCSIPORT_PAUSED,
>> SHARED_PAUSED_SCSIPORT_PAUSED) !=
>> SHARED_PAUSED_SCSIPORT_PAUSED)
>> +    {
>> +      KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
>> +      wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
>> +      KeDelayExecutionThread(KernelMode, FALSE,&wait_time);
>> +    }
>> +    else
>> +    {
>> +      break;
>> +    }
>>       }
>>
>>       KdPrint((__DRIVER_NAME "     Watch triggered on %s\n", path));
>>
>>
>> Thanks,
>> Kazuto Yoshino.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Jun 11 01:54:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 01:54: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 1SdtpF-0004YZ-PY; Mon, 11 Jun 2012 01:53:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yoshink@alpha.co.jp>) id 1SdtpE-0004YU-Tf
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 01:53:49 +0000
Received: from [85.158.139.83:52323] by server-5.bemta-5.messagelabs.com id
	B7/C1-04481-CAF45DF4; Mon, 11 Jun 2012 01:53:48 +0000
X-Env-Sender: yoshink@alpha.co.jp
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339379624!32872495!1
X-Originating-IP: [219.127.235.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26448 invoked from network); 11 Jun 2012 01:53:45 -0000
Received: from mgw1.alpha.co.jp (HELO mgw1.alpha.co.jp) (219.127.235.68)
	by server-12.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 01:53:45 -0000
Received: from (unknown [10.133.235.68]) by SPS-0013.alpha.co.jp with smtp
	id 2da3_1c3d_7d74876e_b368_11e1_9249_001517fbe004;
	Mon, 11 Jun 2012 10:55:17 +0900
Received: from ms4.alpha.co.jp (ms4.alpha.co.jp [10.108.1.42])
	by mgw1.alpha.co.jp (Postfix) with ESMTP id C49CBA7C59F;
	Mon, 11 Jun 2012 10:53:40 +0900 (JST)
Received: from (unknown [10.108.1.42]) by SPS-0013.alpha.co.jp with smtp
	id 2da3_1c2d_7c1aa402_b368_11e1_9249_001517fbe004;
	Mon, 11 Jun 2012 10:55:13 +0900
Received: from [10.146.176.222] (unknown [10.146.176.222])
	by ms4.alpha.co.jp (Postfix) with ESMTP id 543B219F01E2;
	Mon, 11 Jun 2012 10:53:40 +0900 (JST)
Message-ID: <4FD54FA4.1070704@alpha.co.jp>
Date: Mon, 11 Jun 2012 10:53:40 +0900
From: Kazuto Yoshino <yoshink@alpha.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: james.harper@bendigoit.com.au, xen-devel@lists.xen.org
References: <4FD20009.7000302@alpha.co.jp>
	<6035A0D088A63A46850C3988ED045A4B28904C1B@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B28904C1B@BITCOM1.int.sbss.com.au>
Subject: Re: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi James,

I think that this patch is insufficient.
Although work is carried out, it is very doubtful.
Would you correct to the better form, if possible?


Thanks,
Kazuto Yoshino.

(2012/06/10 13:49), James Harper wrote:
> Thanks for that. That locking code is really nasty... do you think your patch is fixing the problem or just working around it?
>
> James
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Kazuto Yoshino
>> Sent: Friday, 8 June 2012 11:37 PM
>> To: xen-devel@lists.xen.org; yoshink@alpha.co.jp
>> Subject: [Xen-devel] [SOLVED] GPLPV SCSI passthrough does not working
>>
>> Hi all,
>>
>> SCSI passthrough of DVD drive is tried on Windows.
>> If vcpus=1 is used, it works.
>> However, if vcpus=2 is used, it does not work.
>> The log is as follows.
>>
>>
>> Hardware:
>> DELL Optiplex 990
>> Intel Core i5 2500
>>
>>
>> Software:
>> xen 4.2-unstable (25452:6bea63e6c780)
>> dom0: Linux 3.1.0-rc10+ 64bit
>> domU: Windows 7 SP1 64bit
>> GPLPV 0.10.0.357
>>
>>
>> domU config:
>> kernel = "hvmloader"
>> builder='hvm'
>> memory = 2048
>> name = "win7x64"
>> vcpus=2
>> vif = [ 'type=ioemu, mac=00:16:3e:19:18:7b, bridge=virbr0' ] disk = [
>> 'file:/etc/xen/win7x64.img,hda,w' ] device_model = 'qemu-dm'
>> sdl=0
>> opengl=1
>> vnc=1
>> vnclisten="0.0.0.0"
>> vncpasswd=''
>> stdvga=0
>> serial='pty'
>> tsc_mode=0
>>
>>
>> command:
>> # xm create /etc/xen/win7x64.hvm
>> # xm scsi-attach win7x64 1:0:0:0 2:0:0:0
>>
>>
>> qemu-dm log:
>> 12983594247656: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247656: XenPCI     Rescanning child list
>> 12983594247656: XenPCI -->  XenPci_EvtChildListScanForChildren
>> 12983594247656: XenPCI     Found path = device/vbd/768
>> 12983594247656: XenPCI     Found path = device/vif/0
>> 12983594247671: XenPCI     Found path = device/vscsi/2
>> 12983594247671: XenPCI<-- XenPci_EvtChildListScanForChildren
>> 12983594247671: XenPCI -->  XenPci_EvtChildListCreateDevice
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     device = 'vscsi', index = '2', path =
>> 'device/vscsi/2'
>> 12983594247671: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI<-- XenPci_EvtChildListCreateDevice
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI -->
>> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
>> 12983594247671: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     device/vscsi/2
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     CmResourceTypeMemory (0)
>> 12983594247671: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247671: XenPCI     Start = f2000000, Length = 0
>> 12983594247671: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247687: XenPCI     pfn[0] = 0000d445
>> 12983594247687: XenPCI     New Start = 000000000d445000, Length = 4096
>> 12983594247687: XenPCI     CmResourceTypeMemory (1)
>> 12983594247687: XenPCI     Start = f2000001, Length = 0
>> 12983594247687: XenPCI<--
>> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
>> 12983594247687: XenPCI -->  XenPciPdo_EvtDevicePrepareHardware
>> 12983594247687: XenPCI<-- XenPciPdo_EvtDevicePrepareHardware
>> 12983594247687: XenPCI -->  XenPciPdo_EvtDeviceD0Entry
>> 12983594247687: XenPCI     path = device/vscsi/2
>> 12983594247687: XenPCI     WdfPowerDeviceD3Final
>> 12983594247687: XenPCI -->  XenPci_GetBackendAndAddWatch
>> 12983594247687: XenPCI<-- XenPci_GetBackendAndAddWatch
>> 12983594247687: XenPCI -->  XenPci_UpdateBackendState
>> 12983594247687: XenPCI -->  XenConfig_InitConfigPage
>> 12983594247687: XenPCI     Backend State Changed to InitWait
>> 12983594247687: XenPCI     fdo_driver_object = FFFFFA80025B9E70
>> 12983594247687: XenPCI<-- XenPci_UpdateBackendState
>> 12983594247687: XenPCI     fdo_driver_extension = FFFFFA8001869010
>> 12983594247703: XenPCI<-- XenConfig_InitConfigPage
>> 12983594247703: XenPCI -->  XenPci_XenConfigDeviceSpecifyBuffers
>> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref =
>> FFFFFA8002AB9000
>> 12983594247703: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
>> 12983594247703: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
>> channel = 8
>> 12983594247703: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI -->  EvtChn_BindIrq
>> 12983594247703: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI<-- EvtChn_BindIrq
>> 12983594247703: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI -->  XenPci_ChangeFrontendStateMap
>> 12983594247703: XenPCI -->  XenPci_ChangeFrontendState
>> 12983594247703: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247703: XenPCI -->  XenPci_UpdateBackendState
>> 12983594247718: XenPCI     Backend State Changed to Connected
>> 12983594247718: XenPCI<-- XenPci_UpdateBackendState
>> 12983594247718: XenPCI<-- XenPci_ChangeFrontendState
>> 12983594247718: XenPCI<-- XenPci_ChangeFrontendStateMap
>> 12983594247718: XenPCI -->  XenPci_ChangeFrontendStateMap
>> 12983594247718: XenPCI -->  XenPci_ChangeFrontendState
>> 12983594247734: XenPCI<-- XenPci_ChangeFrontendState
>> 12983594247734: XenPCI -->  XenPci_DeviceWatchHandler
>> 12983594247734: XenPCI<-- XenPci_ChangeFrontendStateMap
>> 12983594247734: XenPCI<-- XenPci_DeviceWatchHandler
>> 12983594247734: XenPCI<-- XenPci_XenConfigDeviceSpecifyBuffers
>> 12983594247734: XenPCI<-- XenPciPdo_EvtDeviceD0Entry
>> 12983594247734: XenSCSI -->  XenScsi_HwScsiFindAdapter
>> 12983594247734: XenSCSI     IRQL = 0
>> 12983594247734: XenSCSI     BusInterruptLevel = 28
>> 12983594247734: XenSCSI     BusInterruptVector = 01c
>> 12983594247734: XenSCSI     RangeStart = 0d445000, RangeLength = 00001000
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_13
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_VECTORS
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_11
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_RING - ring-ref =
>> FFFFFA8002AB9000
>> 12983594247734: XenSCSI     XEN_INIT_TYPE_EVENT_CHANNEL - event-
>> channel = 8
>> 12983594247750: XenSCSI     XEN_INIT_TYPE_GRANT_ENTRIES - 144
>> 12983594247750: XenSCSI     Dma64BitAddresses supported
>> 12983594247750: XenPCI -->  XenPci_XenBus_AddWatch
>> 12983594247750: XenPCI     XenPci_XenBus_AddWatch -
>> /local/domain/0/backend/vscsi/3/2/vscsi-devs = NULL
>> 12983594247750: XenSCSI -->  XenScsi_DevWatch
>> 12983594247750: XenPCI<-- XenPci_XenBus_AddWatch
>> 12983594247750: XenSCSI     Waiting for pause...
>> 12983594247750: XenSCSI<-- XenScsi_HwScsiFindAdapter
>> 12983594247750: XenSCSI -->  XenScsi_HwScsiInitialize
>> 12983594247750: XenSCSI<-- XenScsi_HwScsiInitialize
>> 12983594247750: XenSCSI -->  XenScsi_HwScsiAdapterControl
>> 12983594247750: XenSCSI     IRQL = 0
>> 12983594247750: XenSCSI     ScsiQuerySupportedControlTypes (Max = 5)
>> 12983594247750: XenSCSI<-- XenScsi_HwScsiAdapterControl
>> 12983594247750: XenSCSI     Busy
>> 12983594247859: XenSCSI     Waiting for pause...
>> 12983594247968: XenSCSI     Waiting for pause...
>> 12983594248078: XenSCSI     Waiting for pause...
>> 12983594248187: XenSCSI     Waiting for pause...
>> 12983594248296: XenSCSI     Waiting for pause...
>> 12983594248406: XenSCSI     Waiting for pause...
>> 12983594248515: XenSCSI     Waiting for pause...
>> 12983594248625: XenSCSI     Waiting for pause...
>> 12983594248734: XenSCSI     Waiting for pause...
>> 12983594248843: XenSCSI     Waiting for pause...
>>
>>
>>
>> It worked, when correcting the source code of GPLPV as follows.
>>
>>
>> --- a/xenscsi/xenscsi.c
>> +++ b/xenscsi/xenscsi.c
>> @@ -278,17 +278,27 @@
>>       /* this can only be called from a watch and so is always serialised */
>>       FUNCTION_ENTER();
>>
>> -  #if DBG
>> -  oldpause =
>> -  #endif
>> -    InterlockedExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_PASSIVE_PAUSED);
>> -  ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
>> -
>> -  while (InterlockedCompareExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_SCSIPORT_PAUSED,
>> SHARED_PAUSED_SCSIPORT_PAUSED) !=
>> SHARED_PAUSED_SCSIPORT_PAUSED)
>> +  while (1)
>>       {
>> -    KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
>> -    wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
>> -    KeDelayExecutionThread(KernelMode, FALSE,&wait_time);
>> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_SCSIPORT_UNPAUSED,
>> SHARED_PAUSED_SCSIPORT_UNPAUSED) ==
>> SHARED_PAUSED_SCSIPORT_UNPAUSED)
>> +    {
>> +      #if DBG
>> +      oldpause =
>> +      #endif
>> +        InterlockedExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_PASSIVE_PAUSED);
>> +      ASSERT(oldpause == SHARED_PAUSED_SCSIPORT_UNPAUSED);
>> +    }
>> +
>> +    if (InterlockedCompareExchange(&xsdd->shared_paused,
>> SHARED_PAUSED_SCSIPORT_PAUSED,
>> SHARED_PAUSED_SCSIPORT_PAUSED) !=
>> SHARED_PAUSED_SCSIPORT_PAUSED)
>> +    {
>> +      KdPrint((__DRIVER_NAME "     Waiting for pause...\n"));
>> +      wait_time.QuadPart = -100 * 1000 * 10; /* 100ms */
>> +      KeDelayExecutionThread(KernelMode, FALSE,&wait_time);
>> +    }
>> +    else
>> +    {
>> +      break;
>> +    }
>>       }
>>
>>       KdPrint((__DRIVER_NAME "     Watch triggered on %s\n", path));
>>
>>
>> Thanks,
>> Kazuto Yoshino.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Jun 11 03:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 03:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SdvjW-0006oM-NH; Mon, 11 Jun 2012 03:56:02 +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 1SdvjV-0006oH-0w
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 03:56:01 +0000
Received: from [85.158.139.83:51308] by server-7.bemta-5.messagelabs.com id
	83/CA-19648-05C65DF4; Mon, 11 Jun 2012 03:56:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339386958!32813021!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxMDA0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9736 invoked from network); 11 Jun 2012 03:55:58 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 03:55:58 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 10 Jun 2012 20:55:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="154548846"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 10 Jun 2012 20:55:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 10 Jun 2012 20:55:03 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Mon, 11 Jun 2012 11:55:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
	atomic context
Thread-Index: Ac1FWkRWxEyD+XUzS/eqorQpXCRDrwCKowEg
Date: Mon, 11 Jun 2012 03:55:00 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335221654@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335221654@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_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Liu, Jinsong wrote:
> From a9c5f29330a056291356b912816b5b2e0e061a30 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Sat, 9 Jun 2012 00:56:46 +0800
> Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
> atomic context=20
>=20

Sorry, I update the patch a little, for spinlock to avoid deadlock.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From db6c0ac9372c6fbc3637ec4216830e7ee01b31aa Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Mon, 11 Jun 2012 19:21:24 +0800
Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in atomi=
c context

copy_to_user might sleep and print a stack trace if it is executed
in an atomic spinlock context. This patch add a mutex lock and a
buffer to avoid the issue.

This patch also change the manipulation of mcelog_lock from
spin_lock_irqsave to spin_trylock to avoid deadlock, since
mcelog_lock is used at normal process context and
mce context (which is async exception context that could
not protected by spin_lock_irqsave). When fail to get spinlock,
mc_info would be transferred by hypervisor next time.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   38 +++++++++++++++++++++++++++++++-------
 1 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 72e87d2..fac29e4 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo;
 static uint32_t ncpus;
=20
 static DEFINE_SPINLOCK(mcelog_lock);
+static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
=20
 static struct xen_mce_log xen_mcelog =3D {
 	.signature	=3D XEN_MCE_LOG_SIGNATURE,
 	.len		=3D XEN_MCE_LOG_LEN,
 	.recordlen	=3D sizeof(struct xen_mce),
 };
+static struct xen_mce_log xen_mcelog_u;
=20
 static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
 static int xen_mce_chrdev_open_count;	/* #times opened */
@@ -106,9 +108,19 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, =
char __user *ubuf,
 	unsigned num;
 	int i, err;
=20
+	/*
+	 * copy_to_user might sleep and print a stack trace
+	 * if it is executed in an atomic spinlock context
+	 */
+	mutex_lock(&xen_mce_chrdev_read_mutex);
+
 	spin_lock(&mcelog_lock);
+	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
=20
 	num =3D xen_mcelog.next;
+	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog.next =3D 0;
+	spin_unlock(&mcelog_lock);
=20
 	/* Only supports full reads right now */
 	err =3D -EINVAL;
@@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file *filp,=
 char __user *ubuf,
=20
 	err =3D 0;
 	for (i =3D 0; i < num; i++) {
-		struct xen_mce *m =3D &xen_mcelog.entry[i];
+		struct xen_mce *m =3D &xen_mcelog_u.entry[i];
=20
 		err |=3D copy_to_user(buf, m, sizeof(*m));
 		buf +=3D sizeof(*m);
 	}
=20
-	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
-	xen_mcelog.next =3D 0;
+	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog_u.next =3D 0;
=20
 	if (err)
 		err =3D -EFAULT;
=20
 out:
-	spin_unlock(&mcelog_lock);
+	mutex_unlock(&xen_mce_chrdev_read_mutex);
=20
 	return err ? err : buf - ubuf;
 }
@@ -313,9 +325,21 @@ static int mc_queue_handle(uint32_t flags)
 static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
 {
 	int err;
-	unsigned long tmp;
=20
-	spin_lock_irqsave(&mcelog_lock, tmp);
+	/*
+	 * mcelog_lock is used at normal process context and
+	 * mce context (which is async exception context that could
+	 * not protected by spin_lock_irqsave).
+	 *
+	 * use spin_trylock to avoid deadlock. When fail to get spinlock,
+	 * mc_info would be transferred by hypervisor next time.
+	 */
+	if (unlikely(!spin_trylock(&mcelog_lock))) {
+		pr_err(XEN_MCELOG
+		       "Failed to get mcelog_lock, mc_info would "
+		       "be transferred by hypervisor next time.\n");
+		return IRQ_NONE;
+	}
=20
 	/* urgent mc_info */
 	err =3D mc_queue_handle(XEN_MC_URGENT);
@@ -330,7 +354,7 @@ static irqreturn_t xen_mce_interrupt(int irq, void *dev=
_id)
 		pr_err(XEN_MCELOG
 		       "Failed to handle nonurgent mc_info queue.\n");
=20
-	spin_unlock_irqrestore(&mcelog_lock, tmp);
+	spin_unlock(&mcelog_lock);
=20
 	return IRQ_HANDLED;
 }
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch"
Content-Description: 0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch";
	size=3858; creation-date="Mon, 11 Jun 2012 03:45:27 GMT";
	modification-date="Mon, 11 Jun 2012 11:39:54 GMT"
Content-Transfer-Encoding: base64

RnJvbSBkYjZjMGFjOTM3MmM2ZmJjMzYzN2VjNDIxNjgzMGU3ZWUwMWIzMWFhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogTW9uLCAxMSBKdW4gMjAxMiAxOToyMToyNCArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IEFkZCBtdXRleCBsb2NrIGFuZCBidWZmZXIgdG8gYXZvaWQgc2xlZXAgaW4gYXRvbWlj
IGNvbnRleHQKCmNvcHlfdG9fdXNlciBtaWdodCBzbGVlcCBhbmQgcHJpbnQgYSBzdGFjayB0cmFj
ZSBpZiBpdCBpcyBleGVjdXRlZAppbiBhbiBhdG9taWMgc3BpbmxvY2sgY29udGV4dC4gVGhpcyBw
YXRjaCBhZGQgYSBtdXRleCBsb2NrIGFuZCBhCmJ1ZmZlciB0byBhdm9pZCB0aGUgaXNzdWUuCgpU
aGlzIHBhdGNoIGFsc28gY2hhbmdlIHRoZSBtYW5pcHVsYXRpb24gb2YgbWNlbG9nX2xvY2sgZnJv
bQpzcGluX2xvY2tfaXJxc2F2ZSB0byBzcGluX3RyeWxvY2sgdG8gYXZvaWQgZGVhZGxvY2ssIHNp
bmNlCm1jZWxvZ19sb2NrIGlzIHVzZWQgYXQgbm9ybWFsIHByb2Nlc3MgY29udGV4dCBhbmQKbWNl
IGNvbnRleHQgKHdoaWNoIGlzIGFzeW5jIGV4Y2VwdGlvbiBjb250ZXh0IHRoYXQgY291bGQKbm90
IHByb3RlY3RlZCBieSBzcGluX2xvY2tfaXJxc2F2ZSkuIFdoZW4gZmFpbCB0byBnZXQgc3Bpbmxv
Y2ssCm1jX2luZm8gd291bGQgYmUgdHJhbnNmZXJyZWQgYnkgaHlwZXJ2aXNvciBuZXh0IHRpbWUu
CgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
LS0tCiBkcml2ZXJzL3hlbi9tY2Vsb2cuYyB8ICAgMzggKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKy0tLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgMzEgaW5zZXJ0aW9ucygrKSwgNyBkZWxl
dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9tY2Vsb2cuYyBiL2RyaXZlcnMveGVu
L21jZWxvZy5jCmluZGV4IDcyZTg3ZDIuLmZhYzI5ZTQgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVu
L21jZWxvZy5jCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC01NiwxMiArNTYsMTQgQEAg
c3RhdGljIHN0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUgKmdfcGh5c2luZm87CiBzdGF0aWMgdWlu
dDMyX3QgbmNwdXM7CiAKIHN0YXRpYyBERUZJTkVfU1BJTkxPQ0sobWNlbG9nX2xvY2spOworc3Rh
dGljIERFRklORV9NVVRFWCh4ZW5fbWNlX2NocmRldl9yZWFkX211dGV4KTsKIAogc3RhdGljIHN0
cnVjdCB4ZW5fbWNlX2xvZyB4ZW5fbWNlbG9nID0gewogCS5zaWduYXR1cmUJPSBYRU5fTUNFX0xP
R19TSUdOQVRVUkUsCiAJLmxlbgkJPSBYRU5fTUNFX0xPR19MRU4sCiAJLnJlY29yZGxlbgk9IHNp
emVvZihzdHJ1Y3QgeGVuX21jZSksCiB9Oworc3RhdGljIHN0cnVjdCB4ZW5fbWNlX2xvZyB4ZW5f
bWNlbG9nX3U7CiAKIHN0YXRpYyBERUZJTkVfU1BJTkxPQ0soeGVuX21jZV9jaHJkZXZfc3RhdGVf
bG9jayk7CiBzdGF0aWMgaW50IHhlbl9tY2VfY2hyZGV2X29wZW5fY291bnQ7CS8qICN0aW1lcyBv
cGVuZWQgKi8KQEAgLTEwNiw5ICsxMDgsMTkgQEAgc3RhdGljIHNzaXplX3QgeGVuX21jZV9jaHJk
ZXZfcmVhZChzdHJ1Y3QgZmlsZSAqZmlscCwgY2hhciBfX3VzZXIgKnVidWYsCiAJdW5zaWduZWQg
bnVtOwogCWludCBpLCBlcnI7CiAKKwkvKgorCSAqIGNvcHlfdG9fdXNlciBtaWdodCBzbGVlcCBh
bmQgcHJpbnQgYSBzdGFjayB0cmFjZQorCSAqIGlmIGl0IGlzIGV4ZWN1dGVkIGluIGFuIGF0b21p
YyBzcGlubG9jayBjb250ZXh0CisJICovCisJbXV0ZXhfbG9jaygmeGVuX21jZV9jaHJkZXZfcmVh
ZF9tdXRleCk7CisKIAlzcGluX2xvY2soJm1jZWxvZ19sb2NrKTsKKwltZW1jcHkoJnhlbl9tY2Vs
b2dfdSwgJnhlbl9tY2Vsb2csIHNpemVvZihzdHJ1Y3QgeGVuX21jZV9sb2cpKTsKIAogCW51bSA9
IHhlbl9tY2Vsb2cubmV4dDsKKwltZW1zZXQoeGVuX21jZWxvZy5lbnRyeSwgMCwgbnVtICogc2l6
ZW9mKHN0cnVjdCB4ZW5fbWNlKSk7CisJeGVuX21jZWxvZy5uZXh0ID0gMDsKKwlzcGluX3VubG9j
aygmbWNlbG9nX2xvY2spOwogCiAJLyogT25seSBzdXBwb3J0cyBmdWxsIHJlYWRzIHJpZ2h0IG5v
dyAqLwogCWVyciA9IC1FSU5WQUw7CkBAIC0xMTcsMjAgKzEyOSwyMCBAQCBzdGF0aWMgc3NpemVf
dCB4ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFyIF9fdXNlciAqdWJ1
ZiwKIAogCWVyciA9IDA7CiAJZm9yIChpID0gMDsgaSA8IG51bTsgaSsrKSB7Ci0JCXN0cnVjdCB4
ZW5fbWNlICptID0gJnhlbl9tY2Vsb2cuZW50cnlbaV07CisJCXN0cnVjdCB4ZW5fbWNlICptID0g
Jnhlbl9tY2Vsb2dfdS5lbnRyeVtpXTsKIAogCQllcnIgfD0gY29weV90b191c2VyKGJ1ZiwgbSwg
c2l6ZW9mKCptKSk7CiAJCWJ1ZiArPSBzaXplb2YoKm0pOwogCX0KIAotCW1lbXNldCh4ZW5fbWNl
bG9nLmVudHJ5LCAwLCBudW0gKiBzaXplb2Yoc3RydWN0IHhlbl9tY2UpKTsKLQl4ZW5fbWNlbG9n
Lm5leHQgPSAwOworCW1lbXNldCh4ZW5fbWNlbG9nX3UuZW50cnksIDAsIG51bSAqIHNpemVvZihz
dHJ1Y3QgeGVuX21jZSkpOworCXhlbl9tY2Vsb2dfdS5uZXh0ID0gMDsKIAogCWlmIChlcnIpCiAJ
CWVyciA9IC1FRkFVTFQ7CiAKIG91dDoKLQlzcGluX3VubG9jaygmbWNlbG9nX2xvY2spOworCW11
dGV4X3VubG9jaygmeGVuX21jZV9jaHJkZXZfcmVhZF9tdXRleCk7CiAKIAlyZXR1cm4gZXJyID8g
ZXJyIDogYnVmIC0gdWJ1ZjsKIH0KQEAgLTMxMyw5ICszMjUsMjEgQEAgc3RhdGljIGludCBtY19x
dWV1ZV9oYW5kbGUodWludDMyX3QgZmxhZ3MpCiBzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQogewogCWludCBlcnI7Ci0JdW5zaWduZWQg
bG9uZyB0bXA7CiAKLQlzcGluX2xvY2tfaXJxc2F2ZSgmbWNlbG9nX2xvY2ssIHRtcCk7CisJLyoK
KwkgKiBtY2Vsb2dfbG9jayBpcyB1c2VkIGF0IG5vcm1hbCBwcm9jZXNzIGNvbnRleHQgYW5kCisJ
ICogbWNlIGNvbnRleHQgKHdoaWNoIGlzIGFzeW5jIGV4Y2VwdGlvbiBjb250ZXh0IHRoYXQgY291
bGQKKwkgKiBub3QgcHJvdGVjdGVkIGJ5IHNwaW5fbG9ja19pcnFzYXZlKS4KKwkgKgorCSAqIHVz
ZSBzcGluX3RyeWxvY2sgdG8gYXZvaWQgZGVhZGxvY2suIFdoZW4gZmFpbCB0byBnZXQgc3Bpbmxv
Y2ssCisJICogbWNfaW5mbyB3b3VsZCBiZSB0cmFuc2ZlcnJlZCBieSBoeXBlcnZpc29yIG5leHQg
dGltZS4KKwkgKi8KKwlpZiAodW5saWtlbHkoIXNwaW5fdHJ5bG9jaygmbWNlbG9nX2xvY2spKSkg
eworCQlwcl9lcnIoWEVOX01DRUxPRworCQkgICAgICAgIkZhaWxlZCB0byBnZXQgbWNlbG9nX2xv
Y2ssIG1jX2luZm8gd291bGQgIgorCQkgICAgICAgImJlIHRyYW5zZmVycmVkIGJ5IGh5cGVydmlz
b3IgbmV4dCB0aW1lLlxuIik7CisJCXJldHVybiBJUlFfTk9ORTsKKwl9CiAKIAkvKiB1cmdlbnQg
bWNfaW5mbyAqLwogCWVyciA9IG1jX3F1ZXVlX2hhbmRsZShYRU5fTUNfVVJHRU5UKTsKQEAgLTMz
MCw3ICszNTQsNyBAQCBzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9pbnRlcnJ1cHQoaW50IGly
cSwgdm9pZCAqZGV2X2lkKQogCQlwcl9lcnIoWEVOX01DRUxPRwogCQkgICAgICAgIkZhaWxlZCB0
byBoYW5kbGUgbm9udXJnZW50IG1jX2luZm8gcXVldWUuXG4iKTsKIAotCXNwaW5fdW5sb2NrX2ly
cXJlc3RvcmUoJm1jZWxvZ19sb2NrLCB0bXApOworCXNwaW5fdW5sb2NrKCZtY2Vsb2dfbG9jayk7
CiAKIAlyZXR1cm4gSVJRX0hBTkRMRUQ7CiB9Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Jun 11 03:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 03:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SdvjW-0006oM-NH; Mon, 11 Jun 2012 03:56:02 +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 1SdvjV-0006oH-0w
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 03:56:01 +0000
Received: from [85.158.139.83:51308] by server-7.bemta-5.messagelabs.com id
	83/CA-19648-05C65DF4; Mon, 11 Jun 2012 03:56:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339386958!32813021!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxMDA0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9736 invoked from network); 11 Jun 2012 03:55:58 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 03:55:58 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 10 Jun 2012 20:55:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="154548846"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 10 Jun 2012 20:55:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 10 Jun 2012 20:55:03 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Mon, 11 Jun 2012 11:55:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
	atomic context
Thread-Index: Ac1FWkRWxEyD+XUzS/eqorQpXCRDrwCKowEg
Date: Mon, 11 Jun 2012 03:55:00 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335221654@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335221654@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_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Liu, Jinsong wrote:
> From a9c5f29330a056291356b912816b5b2e0e061a30 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Sat, 9 Jun 2012 00:56:46 +0800
> Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
> atomic context=20
>=20

Sorry, I update the patch a little, for spinlock to avoid deadlock.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From db6c0ac9372c6fbc3637ec4216830e7ee01b31aa Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Mon, 11 Jun 2012 19:21:24 +0800
Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in atomi=
c context

copy_to_user might sleep and print a stack trace if it is executed
in an atomic spinlock context. This patch add a mutex lock and a
buffer to avoid the issue.

This patch also change the manipulation of mcelog_lock from
spin_lock_irqsave to spin_trylock to avoid deadlock, since
mcelog_lock is used at normal process context and
mce context (which is async exception context that could
not protected by spin_lock_irqsave). When fail to get spinlock,
mc_info would be transferred by hypervisor next time.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   38 +++++++++++++++++++++++++++++++-------
 1 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 72e87d2..fac29e4 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo;
 static uint32_t ncpus;
=20
 static DEFINE_SPINLOCK(mcelog_lock);
+static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
=20
 static struct xen_mce_log xen_mcelog =3D {
 	.signature	=3D XEN_MCE_LOG_SIGNATURE,
 	.len		=3D XEN_MCE_LOG_LEN,
 	.recordlen	=3D sizeof(struct xen_mce),
 };
+static struct xen_mce_log xen_mcelog_u;
=20
 static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
 static int xen_mce_chrdev_open_count;	/* #times opened */
@@ -106,9 +108,19 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, =
char __user *ubuf,
 	unsigned num;
 	int i, err;
=20
+	/*
+	 * copy_to_user might sleep and print a stack trace
+	 * if it is executed in an atomic spinlock context
+	 */
+	mutex_lock(&xen_mce_chrdev_read_mutex);
+
 	spin_lock(&mcelog_lock);
+	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
=20
 	num =3D xen_mcelog.next;
+	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog.next =3D 0;
+	spin_unlock(&mcelog_lock);
=20
 	/* Only supports full reads right now */
 	err =3D -EINVAL;
@@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file *filp,=
 char __user *ubuf,
=20
 	err =3D 0;
 	for (i =3D 0; i < num; i++) {
-		struct xen_mce *m =3D &xen_mcelog.entry[i];
+		struct xen_mce *m =3D &xen_mcelog_u.entry[i];
=20
 		err |=3D copy_to_user(buf, m, sizeof(*m));
 		buf +=3D sizeof(*m);
 	}
=20
-	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
-	xen_mcelog.next =3D 0;
+	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
+	xen_mcelog_u.next =3D 0;
=20
 	if (err)
 		err =3D -EFAULT;
=20
 out:
-	spin_unlock(&mcelog_lock);
+	mutex_unlock(&xen_mce_chrdev_read_mutex);
=20
 	return err ? err : buf - ubuf;
 }
@@ -313,9 +325,21 @@ static int mc_queue_handle(uint32_t flags)
 static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
 {
 	int err;
-	unsigned long tmp;
=20
-	spin_lock_irqsave(&mcelog_lock, tmp);
+	/*
+	 * mcelog_lock is used at normal process context and
+	 * mce context (which is async exception context that could
+	 * not protected by spin_lock_irqsave).
+	 *
+	 * use spin_trylock to avoid deadlock. When fail to get spinlock,
+	 * mc_info would be transferred by hypervisor next time.
+	 */
+	if (unlikely(!spin_trylock(&mcelog_lock))) {
+		pr_err(XEN_MCELOG
+		       "Failed to get mcelog_lock, mc_info would "
+		       "be transferred by hypervisor next time.\n");
+		return IRQ_NONE;
+	}
=20
 	/* urgent mc_info */
 	err =3D mc_queue_handle(XEN_MC_URGENT);
@@ -330,7 +354,7 @@ static irqreturn_t xen_mce_interrupt(int irq, void *dev=
_id)
 		pr_err(XEN_MCELOG
 		       "Failed to handle nonurgent mc_info queue.\n");
=20
-	spin_unlock_irqrestore(&mcelog_lock, tmp);
+	spin_unlock(&mcelog_lock);
=20
 	return IRQ_HANDLED;
 }
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch"
Content-Description: 0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-Add-mutex-lock-and-buffer-to-avoid-sleep-in-.patch";
	size=3858; creation-date="Mon, 11 Jun 2012 03:45:27 GMT";
	modification-date="Mon, 11 Jun 2012 11:39:54 GMT"
Content-Transfer-Encoding: base64

RnJvbSBkYjZjMGFjOTM3MmM2ZmJjMzYzN2VjNDIxNjgzMGU3ZWUwMWIzMWFhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogTW9uLCAxMSBKdW4gMjAxMiAxOToyMToyNCArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IEFkZCBtdXRleCBsb2NrIGFuZCBidWZmZXIgdG8gYXZvaWQgc2xlZXAgaW4gYXRvbWlj
IGNvbnRleHQKCmNvcHlfdG9fdXNlciBtaWdodCBzbGVlcCBhbmQgcHJpbnQgYSBzdGFjayB0cmFj
ZSBpZiBpdCBpcyBleGVjdXRlZAppbiBhbiBhdG9taWMgc3BpbmxvY2sgY29udGV4dC4gVGhpcyBw
YXRjaCBhZGQgYSBtdXRleCBsb2NrIGFuZCBhCmJ1ZmZlciB0byBhdm9pZCB0aGUgaXNzdWUuCgpU
aGlzIHBhdGNoIGFsc28gY2hhbmdlIHRoZSBtYW5pcHVsYXRpb24gb2YgbWNlbG9nX2xvY2sgZnJv
bQpzcGluX2xvY2tfaXJxc2F2ZSB0byBzcGluX3RyeWxvY2sgdG8gYXZvaWQgZGVhZGxvY2ssIHNp
bmNlCm1jZWxvZ19sb2NrIGlzIHVzZWQgYXQgbm9ybWFsIHByb2Nlc3MgY29udGV4dCBhbmQKbWNl
IGNvbnRleHQgKHdoaWNoIGlzIGFzeW5jIGV4Y2VwdGlvbiBjb250ZXh0IHRoYXQgY291bGQKbm90
IHByb3RlY3RlZCBieSBzcGluX2xvY2tfaXJxc2F2ZSkuIFdoZW4gZmFpbCB0byBnZXQgc3Bpbmxv
Y2ssCm1jX2luZm8gd291bGQgYmUgdHJhbnNmZXJyZWQgYnkgaHlwZXJ2aXNvciBuZXh0IHRpbWUu
CgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUu
Y29tPgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
LS0tCiBkcml2ZXJzL3hlbi9tY2Vsb2cuYyB8ICAgMzggKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKy0tLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgMzEgaW5zZXJ0aW9ucygrKSwgNyBkZWxl
dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9tY2Vsb2cuYyBiL2RyaXZlcnMveGVu
L21jZWxvZy5jCmluZGV4IDcyZTg3ZDIuLmZhYzI5ZTQgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVu
L21jZWxvZy5jCisrKyBiL2RyaXZlcnMveGVuL21jZWxvZy5jCkBAIC01NiwxMiArNTYsMTQgQEAg
c3RhdGljIHN0cnVjdCBtY2luZm9fbG9naWNhbF9jcHUgKmdfcGh5c2luZm87CiBzdGF0aWMgdWlu
dDMyX3QgbmNwdXM7CiAKIHN0YXRpYyBERUZJTkVfU1BJTkxPQ0sobWNlbG9nX2xvY2spOworc3Rh
dGljIERFRklORV9NVVRFWCh4ZW5fbWNlX2NocmRldl9yZWFkX211dGV4KTsKIAogc3RhdGljIHN0
cnVjdCB4ZW5fbWNlX2xvZyB4ZW5fbWNlbG9nID0gewogCS5zaWduYXR1cmUJPSBYRU5fTUNFX0xP
R19TSUdOQVRVUkUsCiAJLmxlbgkJPSBYRU5fTUNFX0xPR19MRU4sCiAJLnJlY29yZGxlbgk9IHNp
emVvZihzdHJ1Y3QgeGVuX21jZSksCiB9Oworc3RhdGljIHN0cnVjdCB4ZW5fbWNlX2xvZyB4ZW5f
bWNlbG9nX3U7CiAKIHN0YXRpYyBERUZJTkVfU1BJTkxPQ0soeGVuX21jZV9jaHJkZXZfc3RhdGVf
bG9jayk7CiBzdGF0aWMgaW50IHhlbl9tY2VfY2hyZGV2X29wZW5fY291bnQ7CS8qICN0aW1lcyBv
cGVuZWQgKi8KQEAgLTEwNiw5ICsxMDgsMTkgQEAgc3RhdGljIHNzaXplX3QgeGVuX21jZV9jaHJk
ZXZfcmVhZChzdHJ1Y3QgZmlsZSAqZmlscCwgY2hhciBfX3VzZXIgKnVidWYsCiAJdW5zaWduZWQg
bnVtOwogCWludCBpLCBlcnI7CiAKKwkvKgorCSAqIGNvcHlfdG9fdXNlciBtaWdodCBzbGVlcCBh
bmQgcHJpbnQgYSBzdGFjayB0cmFjZQorCSAqIGlmIGl0IGlzIGV4ZWN1dGVkIGluIGFuIGF0b21p
YyBzcGlubG9jayBjb250ZXh0CisJICovCisJbXV0ZXhfbG9jaygmeGVuX21jZV9jaHJkZXZfcmVh
ZF9tdXRleCk7CisKIAlzcGluX2xvY2soJm1jZWxvZ19sb2NrKTsKKwltZW1jcHkoJnhlbl9tY2Vs
b2dfdSwgJnhlbl9tY2Vsb2csIHNpemVvZihzdHJ1Y3QgeGVuX21jZV9sb2cpKTsKIAogCW51bSA9
IHhlbl9tY2Vsb2cubmV4dDsKKwltZW1zZXQoeGVuX21jZWxvZy5lbnRyeSwgMCwgbnVtICogc2l6
ZW9mKHN0cnVjdCB4ZW5fbWNlKSk7CisJeGVuX21jZWxvZy5uZXh0ID0gMDsKKwlzcGluX3VubG9j
aygmbWNlbG9nX2xvY2spOwogCiAJLyogT25seSBzdXBwb3J0cyBmdWxsIHJlYWRzIHJpZ2h0IG5v
dyAqLwogCWVyciA9IC1FSU5WQUw7CkBAIC0xMTcsMjAgKzEyOSwyMCBAQCBzdGF0aWMgc3NpemVf
dCB4ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFyIF9fdXNlciAqdWJ1
ZiwKIAogCWVyciA9IDA7CiAJZm9yIChpID0gMDsgaSA8IG51bTsgaSsrKSB7Ci0JCXN0cnVjdCB4
ZW5fbWNlICptID0gJnhlbl9tY2Vsb2cuZW50cnlbaV07CisJCXN0cnVjdCB4ZW5fbWNlICptID0g
Jnhlbl9tY2Vsb2dfdS5lbnRyeVtpXTsKIAogCQllcnIgfD0gY29weV90b191c2VyKGJ1ZiwgbSwg
c2l6ZW9mKCptKSk7CiAJCWJ1ZiArPSBzaXplb2YoKm0pOwogCX0KIAotCW1lbXNldCh4ZW5fbWNl
bG9nLmVudHJ5LCAwLCBudW0gKiBzaXplb2Yoc3RydWN0IHhlbl9tY2UpKTsKLQl4ZW5fbWNlbG9n
Lm5leHQgPSAwOworCW1lbXNldCh4ZW5fbWNlbG9nX3UuZW50cnksIDAsIG51bSAqIHNpemVvZihz
dHJ1Y3QgeGVuX21jZSkpOworCXhlbl9tY2Vsb2dfdS5uZXh0ID0gMDsKIAogCWlmIChlcnIpCiAJ
CWVyciA9IC1FRkFVTFQ7CiAKIG91dDoKLQlzcGluX3VubG9jaygmbWNlbG9nX2xvY2spOworCW11
dGV4X3VubG9jaygmeGVuX21jZV9jaHJkZXZfcmVhZF9tdXRleCk7CiAKIAlyZXR1cm4gZXJyID8g
ZXJyIDogYnVmIC0gdWJ1ZjsKIH0KQEAgLTMxMyw5ICszMjUsMjEgQEAgc3RhdGljIGludCBtY19x
dWV1ZV9oYW5kbGUodWludDMyX3QgZmxhZ3MpCiBzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9p
bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQogewogCWludCBlcnI7Ci0JdW5zaWduZWQg
bG9uZyB0bXA7CiAKLQlzcGluX2xvY2tfaXJxc2F2ZSgmbWNlbG9nX2xvY2ssIHRtcCk7CisJLyoK
KwkgKiBtY2Vsb2dfbG9jayBpcyB1c2VkIGF0IG5vcm1hbCBwcm9jZXNzIGNvbnRleHQgYW5kCisJ
ICogbWNlIGNvbnRleHQgKHdoaWNoIGlzIGFzeW5jIGV4Y2VwdGlvbiBjb250ZXh0IHRoYXQgY291
bGQKKwkgKiBub3QgcHJvdGVjdGVkIGJ5IHNwaW5fbG9ja19pcnFzYXZlKS4KKwkgKgorCSAqIHVz
ZSBzcGluX3RyeWxvY2sgdG8gYXZvaWQgZGVhZGxvY2suIFdoZW4gZmFpbCB0byBnZXQgc3Bpbmxv
Y2ssCisJICogbWNfaW5mbyB3b3VsZCBiZSB0cmFuc2ZlcnJlZCBieSBoeXBlcnZpc29yIG5leHQg
dGltZS4KKwkgKi8KKwlpZiAodW5saWtlbHkoIXNwaW5fdHJ5bG9jaygmbWNlbG9nX2xvY2spKSkg
eworCQlwcl9lcnIoWEVOX01DRUxPRworCQkgICAgICAgIkZhaWxlZCB0byBnZXQgbWNlbG9nX2xv
Y2ssIG1jX2luZm8gd291bGQgIgorCQkgICAgICAgImJlIHRyYW5zZmVycmVkIGJ5IGh5cGVydmlz
b3IgbmV4dCB0aW1lLlxuIik7CisJCXJldHVybiBJUlFfTk9ORTsKKwl9CiAKIAkvKiB1cmdlbnQg
bWNfaW5mbyAqLwogCWVyciA9IG1jX3F1ZXVlX2hhbmRsZShYRU5fTUNfVVJHRU5UKTsKQEAgLTMz
MCw3ICszNTQsNyBAQCBzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9pbnRlcnJ1cHQoaW50IGly
cSwgdm9pZCAqZGV2X2lkKQogCQlwcl9lcnIoWEVOX01DRUxPRwogCQkgICAgICAgIkZhaWxlZCB0
byBoYW5kbGUgbm9udXJnZW50IG1jX2luZm8gcXVldWUuXG4iKTsKIAotCXNwaW5fdW5sb2NrX2ly
cXJlc3RvcmUoJm1jZWxvZ19sb2NrLCB0bXApOworCXNwaW5fdW5sb2NrKCZtY2Vsb2dfbG9jayk7
CiAKIAlyZXR1cm4gSVJRX0hBTkRMRUQ7CiB9Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335225796SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Jun 11 05:57:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 05: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 1SdxcN-0007XI-Op; Mon, 11 Jun 2012 05:56:47 +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 1SdxcL-0007XA-96
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 05:56:45 +0000
Received: from [85.158.143.35:35715] by server-3.bemta-4.messagelabs.com id
	86/27-05808-C9885DF4; Mon, 11 Jun 2012 05:56:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339394201!11623285!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk1NjA1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9356 invoked from network); 11 Jun 2012 05:56:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-21.messagelabs.com with SMTP;
	11 Jun 2012 05:56:42 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 10 Jun 2012 22:56:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="110541021"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 10 Jun 2012 22:56:40 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 10 Jun 2012 22:56:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Mon, 11 Jun 2012 13:56:30 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] Xen physical cpus online/offline sys interface
Thread-Index: Ac1HlvJigoMtmxewSn6Qfo6O3a56Lw==
Date: Mon, 11 Jun 2012 05:56:29 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352259E4@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_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] Xen physical cpus online/offline sys interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Konrad,

Our old patch of cpu online/offline is based on old kernel tree.
I rebase it to your latest xen.git
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git   branch devel=
/mce.v3

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From 29152bb054d87334ef970ad037888b7bb032f8ef Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Mon, 11 Jun 2012 20:38:08 +0800
Subject: [PATCH] Xen physical cpus online/offline sys interface

This patch provide Xen physical cpus online/offline sys interface.
User can use it for their own purpose, like power saving:
by offlining some cpus when light workload it save power greatly.

Its basic workflow is, user online/offline cpu via sys interface,
then hypercall xen to implement, after done xen inject virq back to dom0,
and then dom0 sync cpu status.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 .../ABI/testing/sysfs-devices-system-xen_cpu       |   20 +
 drivers/xen/Makefile                               |    1 +
 drivers/xen/pcpu.c                                 |  371 ++++++++++++++++=
++++
 include/xen/interface/platform.h                   |    8 +
 include/xen/interface/xen.h                        |    1 +
 5 files changed, 401 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu
 create mode 100644 drivers/xen/pcpu.c

diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Docum=
entation/ABI/testing/sysfs-devices-system-xen_cpu
new file mode 100644
index 0000000..9ca02fb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu
@@ -0,0 +1,20 @@
+What:		/sys/devices/system/xen_cpu/
+Date:		May 2012
+Contact:	Liu, Jinsong <jinsong.liu@intel.com>
+Description:
+		A collection of global/individual Xen physical cpu attributes
+
+		Individual physical cpu attributes are contained in
+		subdirectories named by the Xen's logical cpu number, e.g.:
+		/sys/devices/system/xen_cpu/xen_cpu#/
+
+
+What:		/sys/devices/system/xen_cpu/xen_cpu#/online
+Date:		May 2012
+Contact:	Liu, Jinsong <jinsong.liu@intel.com>
+Description:
+		Interface to online/offline Xen physical cpus
+
+		When running under Xen platform, it provide user interface
+		to online/offline physical cpus, except cpu0 due to several
+		logic restrictions and assumptions.
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index a787029..d80bea5 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
 obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
+obj-$(CONFIG_XEN_DOM0)			+=3D pcpu.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o acpi.o
 obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..067fcfa
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,371 @@
+/*************************************************************************=
*****
+ * pcpu.c
+ * Management physical cpu in dom0, get pcpu info and provide sys interfac=
e
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/cpu.h>
+#include <linux/stat.h>
+#include <linux/capability.h>
+
+#include <xen/xen.h>
+#include <xen/xenbus.h>
+#include <xen/events.h>
+#include <xen/interface/platform.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+#define XEN_PCPU "xen_cpu: "
+
+/*
+ * @cpu_id: Xen physical cpu logic number
+ * @flags: Xen physical cpu status flag
+ * - XEN_PCPU_FLAGS_ONLINE: cpu is online
+ * - XEN_PCPU_FLAGS_INVALID: cpu is not present
+ */
+struct pcpu {
+	struct list_head list;
+	struct device dev;
+	uint32_t cpu_id;
+	uint32_t flags;
+};
+
+static struct bus_type xen_pcpu_subsys =3D {
+	.name =3D "xen_cpu",
+	.dev_name =3D "xen_cpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+
+static LIST_HEAD(xen_pcpus);
+
+static int xen_pcpu_down(uint32_t cpu_id)
+{
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D cpu_id,
+	};
+
+	return HYPERVISOR_dom0_op(&op);
+}
+
+static int xen_pcpu_up(uint32_t cpu_id)
+{
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D cpu_id,
+	};
+
+	return HYPERVISOR_dom0_op(&op);
+}
+
+static ssize_t show_online(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *pcpu =3D container_of(dev, struct pcpu, dev);
+	unsigned long long val;
+	ssize_t ret;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	if (kstrtoull(buf, 0, &val) < 0)
+		return -EINVAL;
+
+	switch (val) {
+	case 0:
+		ret =3D xen_pcpu_down(pcpu->cpu_id);
+		break;
+	case 1:
+		ret =3D xen_pcpu_up(pcpu->cpu_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);
+
+static bool xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+static void pcpu_online_status(struct xenpf_pcpuinfo *info,
+			       struct pcpu *pcpu)
+{
+	if (xen_pcpu_online(info->flags) &&
+	   !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
+	} else if (!xen_pcpu_online(info->flags) &&
+		    xen_pcpu_online(pcpu->flags)) {
+		/* The pcpu is offlined */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
+	}
+}
+
+static struct pcpu *get_pcpu(uint32_t cpu_id)
+{
+	struct pcpu *pcpu;
+
+	list_for_each_entry(pcpu, &xen_pcpus, list) {
+		if (pcpu->cpu_id =3D=3D cpu_id)
+			return pcpu;
+	}
+
+	return NULL;
+}
+
+static void pcpu_release(struct device *dev)
+{
+	struct pcpu *pcpu =3D container_of(dev, struct pcpu, dev);
+
+	list_del(&pcpu->list);
+	kfree(pcpu);
+}
+
+static void unregister_and_remove_pcpu(struct pcpu *pcpu)
+{
+	struct device *dev;
+
+	if (!pcpu)
+		return;
+
+	dev =3D &pcpu->dev;
+	if (dev->id)
+		device_remove_file(dev, &dev_attr_online);
+
+	/* pcpu remove would be implicitly done */
+	device_unregister(dev);
+}
+
+static int register_pcpu(struct pcpu *pcpu)
+{
+	struct device *dev;
+	int err =3D -EINVAL;
+
+	if (!pcpu)
+		return err;
+
+	dev =3D &pcpu->dev;
+	dev->bus =3D &xen_pcpu_subsys;
+	dev->id =3D pcpu->cpu_id;
+	dev->release =3D pcpu_release;
+
+	err =3D device_register(dev);
+	if (err) {
+		pcpu_release(dev);
+		return err;
+	}
+
+	/*
+	 * Xen never offline cpu0 due to several restrictions
+	 * and assumptions. This basically doesn't add a sys control
+	 * to user, one cannot attempt to offline BSP.
+	 */
+	if (dev->id) {
+		err =3D device_create_file(dev, &dev_attr_online);
+		if (err) {
+			device_unregister(dev);
+			return err;
+		}
+	}
+
+	return 0;
+}
+
+static struct pcpu *create_and_register_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+	int err;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return ERR_PTR(-ENODEV);
+
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&pcpu->list);
+	pcpu->cpu_id =3D info->xen_cpuid;
+	pcpu->flags =3D info->flags;
+
+	/* Need hold on xen_pcpu_lock before pcpu list manipulations */
+	list_add_tail(&pcpu->list, &xen_pcpus);
+
+	err =3D register_pcpu(pcpu);
+	if (err) {
+		pr_warning(XEN_PCPU "Failed to register pcpu%u\n",
+			   info->xen_cpuid);
+		return ERR_PTR(-ENOENT);
+	}
+
+	return pcpu;
+}
+
+/*
+ * Caller should hold the xen_pcpu_lock
+ */
+static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu)
+{
+	int ret;
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	struct xen_platform_op op =3D {
+		.cmd                   =3D XENPF_get_cpuinfo,
+		.interface_version     =3D XENPF_INTERFACE_VERSION,
+		.u.pcpu_info.xen_cpuid =3D cpu,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	info =3D &op.u.pcpu_info;
+	if (max_cpu)
+		*max_cpu =3D info->max_present;
+
+	pcpu =3D get_pcpu(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);
+		return 0;
+	}
+
+	if (!pcpu) {
+		pcpu =3D create_and_register_pcpu(info);
+		if (IS_ERR_OR_NULL(pcpu))
+			return -ENODEV;
+	} else
+		pcpu_online_status(info, pcpu);
+
+	return 0;
+}
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	uint32_t cpu =3D 0, max_cpu =3D 0;
+	int err =3D 0;
+	struct pcpu *pcpu, *tmp;
+
+	mutex_lock(&xen_pcpu_lock);
+
+	while (!err && (cpu <=3D max_cpu)) {
+		err =3D sync_pcpu(cpu, &max_cpu);
+		cpu++;
+	}
+
+	if (err)
+		list_for_each_entry_safe(pcpu, tmp, &xen_pcpus, list)
+			unregister_and_remove_pcpu(pcpu);
+
+	mutex_unlock(&xen_pcpu_lock);
+
+	return err;
+}
+
+static void xen_pcpu_work_fn(struct work_struct *work)
+{
+	xen_sync_pcpus();
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int irq, ret;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	irq =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
+				      xen_pcpu_interrupt, 0,
+				      "xen-pcpu", NULL);
+	if (irq < 0) {
+		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");
+		return irq;
+	}
+
+	ret =3D subsys_system_register(&xen_pcpu_subsys, NULL);
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
+		goto err1;
+	}
+
+	ret =3D xen_sync_pcpus();
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
+		goto err2;
+	}
+
+	return 0;
+
+err2:
+	bus_unregister(&xen_pcpu_subsys);
+err1:
+	unbind_from_irqhandler(irq, NULL);
+	return ret;
+}
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 486653f..61fa661 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
=20
+#define XENPF_cpu_online	56
+#define XENPF_cpu_offline	57
+struct xenpf_cpu_ol {
+	uint32_t cpuid;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -330,6 +337,7 @@ struct xen_platform_op {
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..0801468 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Xen-physical-cpus-online-offline-sys-interface.patch"
Content-Description: 0001-Xen-physical-cpus-online-offline-sys-interface.patch
Content-Disposition: attachment;
	filename="0001-Xen-physical-cpus-online-offline-sys-interface.patch";
	size=12976; creation-date="Mon, 11 Jun 2012 05:50:08 GMT";
	modification-date="Mon, 11 Jun 2012 13:44:12 GMT"
Content-Transfer-Encoding: base64

RnJvbSAyOTE1MmJiMDU0ZDg3MzM0ZWY5NzBhZDAzNzg4OGI3YmIwMzJmOGVmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogTW9uLCAxMSBKdW4gMjAxMiAyMDozODowOCArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIFhl
biBwaHlzaWNhbCBjcHVzIG9ubGluZS9vZmZsaW5lIHN5cyBpbnRlcmZhY2UKClRoaXMgcGF0Y2gg
cHJvdmlkZSBYZW4gcGh5c2ljYWwgY3B1cyBvbmxpbmUvb2ZmbGluZSBzeXMgaW50ZXJmYWNlLgpV
c2VyIGNhbiB1c2UgaXQgZm9yIHRoZWlyIG93biBwdXJwb3NlLCBsaWtlIHBvd2VyIHNhdmluZzoK
Ynkgb2ZmbGluaW5nIHNvbWUgY3B1cyB3aGVuIGxpZ2h0IHdvcmtsb2FkIGl0IHNhdmUgcG93ZXIg
Z3JlYXRseS4KCkl0cyBiYXNpYyB3b3JrZmxvdyBpcywgdXNlciBvbmxpbmUvb2ZmbGluZSBjcHUg
dmlhIHN5cyBpbnRlcmZhY2UsCnRoZW4gaHlwZXJjYWxsIHhlbiB0byBpbXBsZW1lbnQsIGFmdGVy
IGRvbmUgeGVuIGluamVjdCB2aXJxIGJhY2sgdG8gZG9tMCwKYW5kIHRoZW4gZG9tMCBzeW5jIGNw
dSBzdGF0dXMuCgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0Bp
bnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwu
Y29tPgotLS0KIC4uLi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5fY3B1ICAg
ICAgIHwgICAyMCArCiBkcml2ZXJzL3hlbi9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICAgIDEgKwogZHJpdmVycy94ZW4vcGNwdS5jICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfCAgMzcxICsrKysrKysrKysrKysrKysrKysrCiBpbmNsdWRlL3hlbi9pbnRl
cmZhY2UvcGxhdGZvcm0uaCAgICAgICAgICAgICAgICAgICB8ICAgIDggKwogaW5jbHVkZS94ZW4v
aW50ZXJmYWNlL3hlbi5oICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAxICsKIDUgZmlsZXMg
Y2hhbmdlZCwgNDAxIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAx
MDA2NDQgRG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5f
Y3B1CiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4vcGNwdS5jCgpkaWZmIC0tZ2l0IGEv
RG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5fY3B1IGIv
RG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5fY3B1Cm5l
dyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjljYTAyZmIKLS0tIC9kZXYvbnVsbAor
KysgYi9Eb2N1bWVudGF0aW9uL0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9j
cHUKQEAgLTAsMCArMSwyMCBAQAorV2hhdDoJCS9zeXMvZGV2aWNlcy9zeXN0ZW0veGVuX2NwdS8K
K0RhdGU6CQlNYXkgMjAxMgorQ29udGFjdDoJTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRl
bC5jb20+CitEZXNjcmlwdGlvbjoKKwkJQSBjb2xsZWN0aW9uIG9mIGdsb2JhbC9pbmRpdmlkdWFs
IFhlbiBwaHlzaWNhbCBjcHUgYXR0cmlidXRlcworCisJCUluZGl2aWR1YWwgcGh5c2ljYWwgY3B1
IGF0dHJpYnV0ZXMgYXJlIGNvbnRhaW5lZCBpbgorCQlzdWJkaXJlY3RvcmllcyBuYW1lZCBieSB0
aGUgWGVuJ3MgbG9naWNhbCBjcHUgbnVtYmVyLCBlLmcuOgorCQkvc3lzL2RldmljZXMvc3lzdGVt
L3hlbl9jcHUveGVuX2NwdSMvCisKKworV2hhdDoJCS9zeXMvZGV2aWNlcy9zeXN0ZW0veGVuX2Nw
dS94ZW5fY3B1Iy9vbmxpbmUKK0RhdGU6CQlNYXkgMjAxMgorQ29udGFjdDoJTGl1LCBKaW5zb25n
IDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CitEZXNjcmlwdGlvbjoKKwkJSW50ZXJmYWNlIHRvIG9u
bGluZS9vZmZsaW5lIFhlbiBwaHlzaWNhbCBjcHVzCisKKwkJV2hlbiBydW5uaW5nIHVuZGVyIFhl
biBwbGF0Zm9ybSwgaXQgcHJvdmlkZSB1c2VyIGludGVyZmFjZQorCQl0byBvbmxpbmUvb2ZmbGlu
ZSBwaHlzaWNhbCBjcHVzLCBleGNlcHQgY3B1MCBkdWUgdG8gc2V2ZXJhbAorCQlsb2dpYyByZXN0
cmljdGlvbnMgYW5kIGFzc3VtcHRpb25zLgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vTWFrZWZp
bGUgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQppbmRleCBhNzg3MDI5Li5kODBiZWE1IDEwMDY0NAot
LS0gYS9kcml2ZXJzL3hlbi9NYWtlZmlsZQorKysgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQpAQCAt
MTcsNiArMTcsNyBAQCBvYmotJChDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SKQkrPSBzeXMtaHlw
ZXJ2aXNvci5vCiBvYmotJChDT05GSUdfWEVOX1BWSFZNKQkJCSs9IHBsYXRmb3JtLXBjaS5vCiBv
YmotJChDT05GSUdfWEVOX1RNRU0pCQkJKz0gdG1lbS5vCiBvYmotJChDT05GSUdfU1dJT1RMQl9Y
RU4pCQkrPSBzd2lvdGxiLXhlbi5vCitvYmotJChDT05GSUdfWEVOX0RPTTApCQkJKz0gcGNwdS5v
CiBvYmotJChDT05GSUdfWEVOX0RPTTApCQkJKz0gcGNpLm8gYWNwaS5vCiBvYmotJChDT05GSUdf
WEVOX01DRV9MT0cpCQkrPSBtY2Vsb2cubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO
RCkJKz0geGVuLXBjaWJhY2svCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wY3B1LmMgYi9kcml2
ZXJzL3hlbi9wY3B1LmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMDY3ZmNm
YQotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL3BjcHUuYwpAQCAtMCwwICsxLDM3MSBA
QAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKgorICogcGNwdS5jCisgKiBNYW5hZ2VtZW50IHBoeXNp
Y2FsIGNwdSBpbiBkb20wLCBnZXQgcGNwdSBpbmZvIGFuZCBwcm92aWRlIHN5cyBpbnRlcmZhY2UK
KyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24KKyAqIEF1dGhvcjog
TGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKiBBdXRob3I6IEppYW5nLCBZ
dW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkg
aXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJz
aW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBv
ciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwg
b3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0
IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBn
cmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5Cisg
KiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNv
ZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2Fy
ZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJu
aXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKyNpbmNsdWRlIDxsaW51eC9pbnRlcnJ1cHQuaD4KKyNpbmNsdWRlIDxsaW51
eC9zcGlubG9jay5oPgorI2luY2x1ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPGxpbnV4L3N0
YXQuaD4KKyNpbmNsdWRlIDxsaW51eC9jYXBhYmlsaXR5Lmg+CisKKyNpbmNsdWRlIDx4ZW4veGVu
Lmg+CisjaW5jbHVkZSA8eGVuL3hlbmJ1cy5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNp
bmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBl
cnZpc29yLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKworI2RlZmluZSBYRU5f
UENQVSAieGVuX2NwdTogIgorCisvKgorICogQGNwdV9pZDogWGVuIHBoeXNpY2FsIGNwdSBsb2dp
YyBudW1iZXIKKyAqIEBmbGFnczogWGVuIHBoeXNpY2FsIGNwdSBzdGF0dXMgZmxhZworICogLSBY
RU5fUENQVV9GTEFHU19PTkxJTkU6IGNwdSBpcyBvbmxpbmUKKyAqIC0gWEVOX1BDUFVfRkxBR1Nf
SU5WQUxJRDogY3B1IGlzIG5vdCBwcmVzZW50CisgKi8KK3N0cnVjdCBwY3B1IHsKKwlzdHJ1Y3Qg
bGlzdF9oZWFkIGxpc3Q7CisJc3RydWN0IGRldmljZSBkZXY7CisJdWludDMyX3QgY3B1X2lkOwor
CXVpbnQzMl90IGZsYWdzOworfTsKKworc3RhdGljIHN0cnVjdCBidXNfdHlwZSB4ZW5fcGNwdV9z
dWJzeXMgPSB7CisJLm5hbWUgPSAieGVuX2NwdSIsCisJLmRldl9uYW1lID0gInhlbl9jcHUiLAor
fTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9sb2NrKTsKKworc3RhdGljIExJU1Rf
SEVBRCh4ZW5fcGNwdXMpOworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgY3B1
X2lkKQoreworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBG
X2NwdV9vZmZsaW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVS
U0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCQk9IGNwdV9pZCwKKwl9OworCisJcmV0dXJuIEhZUEVS
VklTT1JfZG9tMF9vcCgmb3ApOworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQzMl90
IGNwdV9pZCkKK3sKKwlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kCQkJPSBY
RU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0Vf
VkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCQk9IGNwdV9pZCwKKwl9OworCisJcmV0dXJuIEhZ
UEVSVklTT1JfZG9tMF9vcCgmb3ApOworfQorCitzdGF0aWMgc3NpemVfdCBzaG93X29ubGluZShz
dHJ1Y3QgZGV2aWNlICpkZXYsCisJCQkgICBzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwK
KwkJCSAgIGNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNwdSAqY3B1ID0gY29udGFpbmVyX29mKGRl
diwgc3RydWN0IHBjcHUsIGRldik7CisKKwlyZXR1cm4gc3ByaW50ZihidWYsICIldVxuIiwgISEo
Y3B1LT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX09OTElORSkpOworfQorCitzdGF0aWMgc3NpemVf
dCBfX3JlZiBzdG9yZV9vbmxpbmUoc3RydWN0IGRldmljZSAqZGV2LAorCQkJCSAgc3RydWN0IGRl
dmljZV9hdHRyaWJ1dGUgKmF0dHIsCisJCQkJICBjb25zdCBjaGFyICpidWYsIHNpemVfdCBjb3Vu
dCkKK3sKKwlzdHJ1Y3QgcGNwdSAqcGNwdSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1
LCBkZXYpOworCXVuc2lnbmVkIGxvbmcgbG9uZyB2YWw7CisJc3NpemVfdCByZXQ7CisKKwlpZiAo
IWNhcGFibGUoQ0FQX1NZU19BRE1JTikpCisJCXJldHVybiAtRVBFUk07CisKKwlpZiAoa3N0cnRv
dWxsKGJ1ZiwgMCwgJnZhbCkgPCAwKQorCQlyZXR1cm4gLUVJTlZBTDsKKworCXN3aXRjaCAodmFs
KSB7CisJY2FzZSAwOgorCQlyZXQgPSB4ZW5fcGNwdV9kb3duKHBjcHUtPmNwdV9pZCk7CisJCWJy
ZWFrOworCWNhc2UgMToKKwkJcmV0ID0geGVuX3BjcHVfdXAocGNwdS0+Y3B1X2lkKTsKKwkJYnJl
YWs7CisJZGVmYXVsdDoKKwkJcmV0ID0gLUVJTlZBTDsKKwl9CisKKwlpZiAocmV0ID49IDApCisJ
CXJldCA9IGNvdW50OworCXJldHVybiByZXQ7Cit9CitzdGF0aWMgREVWSUNFX0FUVFIob25saW5l
LCBTX0lSVUdPIHwgU19JV1VTUiwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0YXRp
YyBib29sIHhlbl9wY3B1X29ubGluZSh1aW50MzJfdCBmbGFncykKK3sKKwlyZXR1cm4gISEoZmxh
Z3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUpOworfQorCitzdGF0aWMgdm9pZCBwY3B1X29ubGlu
ZV9zdGF0dXMoc3RydWN0IHhlbnBmX3BjcHVpbmZvICppbmZvLAorCQkJICAgICAgIHN0cnVjdCBw
Y3B1ICpwY3B1KQoreworCWlmICh4ZW5fcGNwdV9vbmxpbmUoaW5mby0+ZmxhZ3MpICYmCisJICAg
IXhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykpIHsKKwkJLyogdGhlIHBjcHUgaXMgb25saW5l
ZCAqLworCQlwY3B1LT5mbGFncyB8PSBYRU5fUENQVV9GTEFHU19PTkxJTkU7CisJCWtvYmplY3Rf
dWV2ZW50KCZwY3B1LT5kZXYua29iaiwgS09CSl9PTkxJTkUpOworCX0gZWxzZSBpZiAoIXhlbl9w
Y3B1X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJICAgIHhlbl9wY3B1X29ubGluZShwY3B1LT5m
bGFncykpIHsKKwkJLyogVGhlIHBjcHUgaXMgb2ZmbGluZWQgKi8KKwkJcGNwdS0+ZmxhZ3MgJj0g
flhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91ZXZlbnQoJnBjcHUtPmRldi5rb2Jq
LCBLT0JKX09GRkxJTkUpOworCX0KK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICpnZXRfcGNwdSh1
aW50MzJfdCBjcHVfaWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHU7CisKKwlsaXN0X2Zvcl9lYWNo
X2VudHJ5KHBjcHUsICZ4ZW5fcGNwdXMsIGxpc3QpIHsKKwkJaWYgKHBjcHUtPmNwdV9pZCA9PSBj
cHVfaWQpCisJCQlyZXR1cm4gcGNwdTsKKwl9CisKKwlyZXR1cm4gTlVMTDsKK30KKworc3RhdGlj
IHZvaWQgcGNwdV9yZWxlYXNlKHN0cnVjdCBkZXZpY2UgKmRldikKK3sKKwlzdHJ1Y3QgcGNwdSAq
cGNwdSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBkZXYpOworCisJbGlzdF9kZWwo
JnBjcHUtPmxpc3QpOworCWtmcmVlKHBjcHUpOworfQorCitzdGF0aWMgdm9pZCB1bnJlZ2lzdGVy
X2FuZF9yZW1vdmVfcGNwdShzdHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlzdHJ1Y3QgZGV2aWNlICpk
ZXY7CisKKwlpZiAoIXBjcHUpCisJCXJldHVybjsKKworCWRldiA9ICZwY3B1LT5kZXY7CisJaWYg
KGRldi0+aWQpCisJCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0cl9vbmxpbmUpOwor
CisJLyogcGNwdSByZW1vdmUgd291bGQgYmUgaW1wbGljaXRseSBkb25lICovCisJZGV2aWNlX3Vu
cmVnaXN0ZXIoZGV2KTsKK30KKworc3RhdGljIGludCByZWdpc3Rlcl9wY3B1KHN0cnVjdCBwY3B1
ICpwY3B1KQoreworCXN0cnVjdCBkZXZpY2UgKmRldjsKKwlpbnQgZXJyID0gLUVJTlZBTDsKKwor
CWlmICghcGNwdSkKKwkJcmV0dXJuIGVycjsKKworCWRldiA9ICZwY3B1LT5kZXY7CisJZGV2LT5i
dXMgPSAmeGVuX3BjcHVfc3Vic3lzOworCWRldi0+aWQgPSBwY3B1LT5jcHVfaWQ7CisJZGV2LT5y
ZWxlYXNlID0gcGNwdV9yZWxlYXNlOworCisJZXJyID0gZGV2aWNlX3JlZ2lzdGVyKGRldik7CisJ
aWYgKGVycikgeworCQlwY3B1X3JlbGVhc2UoZGV2KTsKKwkJcmV0dXJuIGVycjsKKwl9CisKKwkv
KgorCSAqIFhlbiBuZXZlciBvZmZsaW5lIGNwdTAgZHVlIHRvIHNldmVyYWwgcmVzdHJpY3Rpb25z
CisJICogYW5kIGFzc3VtcHRpb25zLiBUaGlzIGJhc2ljYWxseSBkb2Vzbid0IGFkZCBhIHN5cyBj
b250cm9sCisJICogdG8gdXNlciwgb25lIGNhbm5vdCBhdHRlbXB0IHRvIG9mZmxpbmUgQlNQLgor
CSAqLworCWlmIChkZXYtPmlkKSB7CisJCWVyciA9IGRldmljZV9jcmVhdGVfZmlsZShkZXYsICZk
ZXZfYXR0cl9vbmxpbmUpOworCQlpZiAoZXJyKSB7CisJCQlkZXZpY2VfdW5yZWdpc3RlcihkZXYp
OworCQkJcmV0dXJuIGVycjsKKwkJfQorCX0KKworCXJldHVybiAwOworfQorCitzdGF0aWMgc3Ry
dWN0IHBjcHUgKmNyZWF0ZV9hbmRfcmVnaXN0ZXJfcGNwdShzdHJ1Y3QgeGVucGZfcGNwdWluZm8g
KmluZm8pCit7CisJc3RydWN0IHBjcHUgKnBjcHU7CisJaW50IGVycjsKKworCWlmIChpbmZvLT5m
bGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpCisJCXJldHVybiBFUlJfUFRSKC1FTk9ERVYp
OworCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwgR0ZQX0tFUk5FTCk7CisJ
aWYgKCFwY3B1KQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKworCUlOSVRfTElTVF9IRUFE
KCZwY3B1LT5saXN0KTsKKwlwY3B1LT5jcHVfaWQgPSBpbmZvLT54ZW5fY3B1aWQ7CisJcGNwdS0+
ZmxhZ3MgPSBpbmZvLT5mbGFnczsKKworCS8qIE5lZWQgaG9sZCBvbiB4ZW5fcGNwdV9sb2NrIGJl
Zm9yZSBwY3B1IGxpc3QgbWFuaXB1bGF0aW9ucyAqLworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPmxp
c3QsICZ4ZW5fcGNwdXMpOworCisJZXJyID0gcmVnaXN0ZXJfcGNwdShwY3B1KTsKKwlpZiAoZXJy
KSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZhaWxlZCB0byByZWdpc3RlciBwY3B1JXVcbiIs
CisJCQkgICBpbmZvLT54ZW5fY3B1aWQpOworCQlyZXR1cm4gRVJSX1BUUigtRU5PRU5UKTsKKwl9
CisKKwlyZXR1cm4gcGNwdTsKK30KKworLyoKKyAqIENhbGxlciBzaG91bGQgaG9sZCB0aGUgeGVu
X3BjcHVfbG9jaworICovCitzdGF0aWMgaW50IHN5bmNfcGNwdSh1aW50MzJfdCBjcHUsIHVpbnQz
Ml90ICptYXhfY3B1KQoreworCWludCByZXQ7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOwor
CXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9w
ID0geworCQkuY21kICAgICAgICAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgICAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUucGNw
dV9pbmZvLnhlbl9jcHVpZCA9IGNwdSwKKwl9OworCisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29w
KCZvcCk7CisJaWYgKHJldCkKKwkJcmV0dXJuIHJldDsKKworCWluZm8gPSAmb3AudS5wY3B1X2lu
Zm87CisJaWYgKG1heF9jcHUpCisJCSptYXhfY3B1ID0gaW5mby0+bWF4X3ByZXNlbnQ7CisKKwlw
Y3B1ID0gZ2V0X3BjcHUoY3B1KTsKKworCS8qCisJICogT25seSB0aG9zZSBhdCBjcHUgcHJlc2Vu
dCBtYXAgaGFzIGl0cyBzeXMgaW50ZXJmYWNlLgorCSAqLworCWlmIChpbmZvLT5mbGFncyAmIFhF
Tl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJaWYgKHBjcHUpCisJCQl1bnJlZ2lzdGVyX2FuZF9y
ZW1vdmVfcGNwdShwY3B1KTsKKwkJcmV0dXJuIDA7CisJfQorCisJaWYgKCFwY3B1KSB7CisJCXBj
cHUgPSBjcmVhdGVfYW5kX3JlZ2lzdGVyX3BjcHUoaW5mbyk7CisJCWlmIChJU19FUlJfT1JfTlVM
TChwY3B1KSkKKwkJCXJldHVybiAtRU5PREVWOworCX0gZWxzZQorCQlwY3B1X29ubGluZV9zdGF0
dXMoaW5mbywgcGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworLyoKKyAqIFN5bmMgZG9tMCdzIHBj
cHUgaW5mb3JtYXRpb24gd2l0aCB4ZW4gaHlwZXJ2aXNvcidzCisgKi8KK3N0YXRpYyBpbnQgeGVu
X3N5bmNfcGNwdXModm9pZCkKK3sKKwkvKgorCSAqIEJvb3QgY3B1IGFsd2F5cyBoYXZlIGNwdV9p
ZCAwIGluIHhlbgorCSAqLworCXVpbnQzMl90IGNwdSA9IDAsIG1heF9jcHUgPSAwOworCWludCBl
cnIgPSAwOworCXN0cnVjdCBwY3B1ICpwY3B1LCAqdG1wOworCisJbXV0ZXhfbG9jaygmeGVuX3Bj
cHVfbG9jayk7CisKKwl3aGlsZSAoIWVyciAmJiAoY3B1IDw9IG1heF9jcHUpKSB7CisJCWVyciA9
IHN5bmNfcGNwdShjcHUsICZtYXhfY3B1KTsKKwkJY3B1Kys7CisJfQorCisJaWYgKGVycikKKwkJ
bGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBjcHUsIHRtcCwgJnhlbl9wY3B1cywgbGlzdCkKKwkJ
CXVucmVnaXN0ZXJfYW5kX3JlbW92ZV9wY3B1KHBjcHUpOworCisJbXV0ZXhfdW5sb2NrKCZ4ZW5f
cGNwdV9sb2NrKTsKKworCXJldHVybiBlcnI7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X3dv
cmtfZm4oc3RydWN0IHdvcmtfc3RydWN0ICp3b3JrKQoreworCXhlbl9zeW5jX3BjcHVzKCk7Cit9
CitzdGF0aWMgREVDTEFSRV9XT1JLKHhlbl9wY3B1X3dvcmssIHhlbl9wY3B1X3dvcmtfZm4pOwor
CitzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX3BjcHVfaW50ZXJydXB0KGludCBpcnEsIHZvaWQgKmRl
dl9pZCkKK3sKKwlzY2hlZHVsZV93b3JrKCZ4ZW5fcGNwdV93b3JrKTsKKwlyZXR1cm4gSVJRX0hB
TkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1X2luaXQodm9pZCkKK3sKKwlp
bnQgaXJxLCByZXQ7CisKKwlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQorCQlyZXR1cm4gLUVO
T0RFVjsKKworCWlycSA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJUlFfUENQVV9TVEFURSwg
MCwKKwkJCQkgICAgICB4ZW5fcGNwdV9pbnRlcnJ1cHQsIDAsCisJCQkJICAgICAgInhlbi1wY3B1
IiwgTlVMTCk7CisJaWYgKGlycSA8IDApIHsKKwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVk
IHRvIGJpbmQgcGNwdSB2aXJxXG4iKTsKKwkJcmV0dXJuIGlycTsKKwl9CisKKwlyZXQgPSBzdWJz
eXNfc3lzdGVtX3JlZ2lzdGVyKCZ4ZW5fcGNwdV9zdWJzeXMsIE5VTEwpOworCWlmIChyZXQpIHsK
KwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVkIHRvIHJlZ2lzdGVyIHBjcHUgc3Vic3lzXG4i
KTsKKwkJZ290byBlcnIxOworCX0KKworCXJldCA9IHhlbl9zeW5jX3BjcHVzKCk7CisJaWYgKHJl
dCkgeworCQlwcl93YXJuaW5nKFhFTl9QQ1BVICJGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9cbiIp
OworCQlnb3RvIGVycjI7CisJfQorCisJcmV0dXJuIDA7CisKK2VycjI6CisJYnVzX3VucmVnaXN0
ZXIoJnhlbl9wY3B1X3N1YnN5cyk7CitlcnIxOgorCXVuYmluZF9mcm9tX2lycWhhbmRsZXIoaXJx
LCBOVUxMKTsKKwlyZXR1cm4gcmV0OworfQorYXJjaF9pbml0Y2FsbCh4ZW5fcGNwdV9pbml0KTsK
ZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIGIvaW5jbHVkZS94
ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggNDg2NjUzZi4uNjFmYTY2MSAxMDA2NDQKLS0t
IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKKysrIGIvaW5jbHVkZS94ZW4vaW50
ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMxNCw2ICszMTQsMTMgQEAgc3RydWN0IHhlbnBmX3BjcHVp
bmZvIHsKIH07CiBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5wZl9wY3B1aW5mbyk7CiAK
KyNkZWZpbmUgWEVOUEZfY3B1X29ubGluZQk1NgorI2RlZmluZSBYRU5QRl9jcHVfb2ZmbGluZQk1
Nworc3RydWN0IHhlbnBmX2NwdV9vbCB7CisJdWludDMyX3QgY3B1aWQ7Cit9OworREVGSU5FX0dV
RVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29sKTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9v
cCB7CiAJdWludDMyX3QgY21kOwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5Q
Rl9JTlRFUkZBQ0VfVkVSU0lPTiAqLwpAQCAtMzMwLDYgKzMzNyw3IEBAIHN0cnVjdCB4ZW5fcGxh
dGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZfZ2V0aWRsZXRpbWUgICAgICAgZ2V0aWRsZXRpbWU7
CiAJCXN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyBzZXRfcG1pbmZvOwogCQlzdHJ1
Y3QgeGVucGZfcGNwdWluZm8gICAgICAgICAgcGNwdV9pbmZvOworCQlzdHJ1Y3QgeGVucGZfY3B1
X29sICAgICAgICAgICAgY3B1X29sOwogCQl1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAg
cGFkWzEyOF07CiAJfSB1OwogfTsKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94
ZW4uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAppbmRleCBhODkwODA0Li4wODAxNDY4
IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKKysrIGIvaW5jbHVkZS94
ZW4vaW50ZXJmYWNlL3hlbi5oCkBAIC04MCw2ICs4MCw3IEBACiAjZGVmaW5lIFZJUlFfQ09OU09M
RSAgICAyICAvKiAoRE9NMCkgQnl0ZXMgcmVjZWl2ZWQgb24gZW1lcmdlbmN5IGNvbnNvbGUuICov
CiAjZGVmaW5lIFZJUlFfRE9NX0VYQyAgICAzICAvKiAoRE9NMCkgRXhjZXB0aW9uYWwgZXZlbnQg
Zm9yIHNvbWUgZG9tYWluLiAgICovCiAjZGVmaW5lIFZJUlFfREVCVUdHRVIgICA2ICAvKiAoRE9N
MCkgQSBkb21haW4gaGFzIHBhdXNlZCBmb3IgZGVidWdnaW5nLiAgICovCisjZGVmaW5lIFZJUlFf
UENQVV9TVEFURSA5ICAvKiAoRE9NMCkgUENQVSBzdGF0ZSBjaGFuZ2VkICAgICAgICAgICAgICAg
ICAgICovCiAKIC8qIEFyY2hpdGVjdHVyZS1zcGVjaWZpYyBWSVJRIGRlZmluaXRpb25zLiAqLwog
I2RlZmluZSBWSVJRX0FSQ0hfMCAgICAxNgotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Jun 11 05:57:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 05: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 1SdxcN-0007XI-Op; Mon, 11 Jun 2012 05:56:47 +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 1SdxcL-0007XA-96
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 05:56:45 +0000
Received: from [85.158.143.35:35715] by server-3.bemta-4.messagelabs.com id
	86/27-05808-C9885DF4; Mon, 11 Jun 2012 05:56:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339394201!11623285!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk1NjA1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9356 invoked from network); 11 Jun 2012 05:56:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-21.messagelabs.com with SMTP;
	11 Jun 2012 05:56:42 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 10 Jun 2012 22:56:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="110541021"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 10 Jun 2012 22:56:40 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 10 Jun 2012 22:56:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Mon, 11 Jun 2012 13:56:30 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] Xen physical cpus online/offline sys interface
Thread-Index: Ac1HlvJigoMtmxewSn6Qfo6O3a56Lw==
Date: Mon, 11 Jun 2012 05:56:29 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352259E4@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_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] Xen physical cpus online/offline sys interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Konrad,

Our old patch of cpu online/offline is based on old kernel tree.
I rebase it to your latest xen.git
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git   branch devel=
/mce.v3

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From 29152bb054d87334ef970ad037888b7bb032f8ef Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Mon, 11 Jun 2012 20:38:08 +0800
Subject: [PATCH] Xen physical cpus online/offline sys interface

This patch provide Xen physical cpus online/offline sys interface.
User can use it for their own purpose, like power saving:
by offlining some cpus when light workload it save power greatly.

Its basic workflow is, user online/offline cpu via sys interface,
then hypercall xen to implement, after done xen inject virq back to dom0,
and then dom0 sync cpu status.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 .../ABI/testing/sysfs-devices-system-xen_cpu       |   20 +
 drivers/xen/Makefile                               |    1 +
 drivers/xen/pcpu.c                                 |  371 ++++++++++++++++=
++++
 include/xen/interface/platform.h                   |    8 +
 include/xen/interface/xen.h                        |    1 +
 5 files changed, 401 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu
 create mode 100644 drivers/xen/pcpu.c

diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Docum=
entation/ABI/testing/sysfs-devices-system-xen_cpu
new file mode 100644
index 0000000..9ca02fb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu
@@ -0,0 +1,20 @@
+What:		/sys/devices/system/xen_cpu/
+Date:		May 2012
+Contact:	Liu, Jinsong <jinsong.liu@intel.com>
+Description:
+		A collection of global/individual Xen physical cpu attributes
+
+		Individual physical cpu attributes are contained in
+		subdirectories named by the Xen's logical cpu number, e.g.:
+		/sys/devices/system/xen_cpu/xen_cpu#/
+
+
+What:		/sys/devices/system/xen_cpu/xen_cpu#/online
+Date:		May 2012
+Contact:	Liu, Jinsong <jinsong.liu@intel.com>
+Description:
+		Interface to online/offline Xen physical cpus
+
+		When running under Xen platform, it provide user interface
+		to online/offline physical cpus, except cpu0 due to several
+		logic restrictions and assumptions.
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index a787029..d80bea5 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+=3D sys-hypervisor.o
 obj-$(CONFIG_XEN_PVHVM)			+=3D platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+=3D tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
+obj-$(CONFIG_XEN_DOM0)			+=3D pcpu.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o acpi.o
 obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
new file mode 100644
index 0000000..067fcfa
--- /dev/null
+++ b/drivers/xen/pcpu.c
@@ -0,0 +1,371 @@
+/*************************************************************************=
*****
+ * pcpu.c
+ * Management physical cpu in dom0, get pcpu info and provide sys interfac=
e
+ *
+ * Copyright (c) 2012 Intel Corporation
+ * Author: Liu, Jinsong <jinsong.liu@intel.com>
+ * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modi=
fy,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Softw=
are,
+ * and to permit persons to whom the Software is furnished to do so, subje=
ct to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/cpu.h>
+#include <linux/stat.h>
+#include <linux/capability.h>
+
+#include <xen/xen.h>
+#include <xen/xenbus.h>
+#include <xen/events.h>
+#include <xen/interface/platform.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+#define XEN_PCPU "xen_cpu: "
+
+/*
+ * @cpu_id: Xen physical cpu logic number
+ * @flags: Xen physical cpu status flag
+ * - XEN_PCPU_FLAGS_ONLINE: cpu is online
+ * - XEN_PCPU_FLAGS_INVALID: cpu is not present
+ */
+struct pcpu {
+	struct list_head list;
+	struct device dev;
+	uint32_t cpu_id;
+	uint32_t flags;
+};
+
+static struct bus_type xen_pcpu_subsys =3D {
+	.name =3D "xen_cpu",
+	.dev_name =3D "xen_cpu",
+};
+
+static DEFINE_MUTEX(xen_pcpu_lock);
+
+static LIST_HEAD(xen_pcpus);
+
+static int xen_pcpu_down(uint32_t cpu_id)
+{
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_offline,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D cpu_id,
+	};
+
+	return HYPERVISOR_dom0_op(&op);
+}
+
+static int xen_pcpu_up(uint32_t cpu_id)
+{
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_cpu_online,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.cpu_ol.cpuid		=3D cpu_id,
+	};
+
+	return HYPERVISOR_dom0_op(&op);
+}
+
+static ssize_t show_online(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	struct pcpu *cpu =3D container_of(dev, struct pcpu, dev);
+
+	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
+}
+
+static ssize_t __ref store_online(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t count)
+{
+	struct pcpu *pcpu =3D container_of(dev, struct pcpu, dev);
+	unsigned long long val;
+	ssize_t ret;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	if (kstrtoull(buf, 0, &val) < 0)
+		return -EINVAL;
+
+	switch (val) {
+	case 0:
+		ret =3D xen_pcpu_down(pcpu->cpu_id);
+		break;
+	case 1:
+		ret =3D xen_pcpu_up(pcpu->cpu_id);
+		break;
+	default:
+		ret =3D -EINVAL;
+	}
+
+	if (ret >=3D 0)
+		ret =3D count;
+	return ret;
+}
+static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);
+
+static bool xen_pcpu_online(uint32_t flags)
+{
+	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
+}
+
+static void pcpu_online_status(struct xenpf_pcpuinfo *info,
+			       struct pcpu *pcpu)
+{
+	if (xen_pcpu_online(info->flags) &&
+	   !xen_pcpu_online(pcpu->flags)) {
+		/* the pcpu is onlined */
+		pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
+	} else if (!xen_pcpu_online(info->flags) &&
+		    xen_pcpu_online(pcpu->flags)) {
+		/* The pcpu is offlined */
+		pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE;
+		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
+	}
+}
+
+static struct pcpu *get_pcpu(uint32_t cpu_id)
+{
+	struct pcpu *pcpu;
+
+	list_for_each_entry(pcpu, &xen_pcpus, list) {
+		if (pcpu->cpu_id =3D=3D cpu_id)
+			return pcpu;
+	}
+
+	return NULL;
+}
+
+static void pcpu_release(struct device *dev)
+{
+	struct pcpu *pcpu =3D container_of(dev, struct pcpu, dev);
+
+	list_del(&pcpu->list);
+	kfree(pcpu);
+}
+
+static void unregister_and_remove_pcpu(struct pcpu *pcpu)
+{
+	struct device *dev;
+
+	if (!pcpu)
+		return;
+
+	dev =3D &pcpu->dev;
+	if (dev->id)
+		device_remove_file(dev, &dev_attr_online);
+
+	/* pcpu remove would be implicitly done */
+	device_unregister(dev);
+}
+
+static int register_pcpu(struct pcpu *pcpu)
+{
+	struct device *dev;
+	int err =3D -EINVAL;
+
+	if (!pcpu)
+		return err;
+
+	dev =3D &pcpu->dev;
+	dev->bus =3D &xen_pcpu_subsys;
+	dev->id =3D pcpu->cpu_id;
+	dev->release =3D pcpu_release;
+
+	err =3D device_register(dev);
+	if (err) {
+		pcpu_release(dev);
+		return err;
+	}
+
+	/*
+	 * Xen never offline cpu0 due to several restrictions
+	 * and assumptions. This basically doesn't add a sys control
+	 * to user, one cannot attempt to offline BSP.
+	 */
+	if (dev->id) {
+		err =3D device_create_file(dev, &dev_attr_online);
+		if (err) {
+			device_unregister(dev);
+			return err;
+		}
+	}
+
+	return 0;
+}
+
+static struct pcpu *create_and_register_pcpu(struct xenpf_pcpuinfo *info)
+{
+	struct pcpu *pcpu;
+	int err;
+
+	if (info->flags & XEN_PCPU_FLAGS_INVALID)
+		return ERR_PTR(-ENODEV);
+
+	pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL);
+	if (!pcpu)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&pcpu->list);
+	pcpu->cpu_id =3D info->xen_cpuid;
+	pcpu->flags =3D info->flags;
+
+	/* Need hold on xen_pcpu_lock before pcpu list manipulations */
+	list_add_tail(&pcpu->list, &xen_pcpus);
+
+	err =3D register_pcpu(pcpu);
+	if (err) {
+		pr_warning(XEN_PCPU "Failed to register pcpu%u\n",
+			   info->xen_cpuid);
+		return ERR_PTR(-ENOENT);
+	}
+
+	return pcpu;
+}
+
+/*
+ * Caller should hold the xen_pcpu_lock
+ */
+static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu)
+{
+	int ret;
+	struct pcpu *pcpu =3D NULL;
+	struct xenpf_pcpuinfo *info;
+	struct xen_platform_op op =3D {
+		.cmd                   =3D XENPF_get_cpuinfo,
+		.interface_version     =3D XENPF_INTERFACE_VERSION,
+		.u.pcpu_info.xen_cpuid =3D cpu,
+	};
+
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	info =3D &op.u.pcpu_info;
+	if (max_cpu)
+		*max_cpu =3D info->max_present;
+
+	pcpu =3D get_pcpu(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);
+		return 0;
+	}
+
+	if (!pcpu) {
+		pcpu =3D create_and_register_pcpu(info);
+		if (IS_ERR_OR_NULL(pcpu))
+			return -ENODEV;
+	} else
+		pcpu_online_status(info, pcpu);
+
+	return 0;
+}
+
+/*
+ * Sync dom0's pcpu information with xen hypervisor's
+ */
+static int xen_sync_pcpus(void)
+{
+	/*
+	 * Boot cpu always have cpu_id 0 in xen
+	 */
+	uint32_t cpu =3D 0, max_cpu =3D 0;
+	int err =3D 0;
+	struct pcpu *pcpu, *tmp;
+
+	mutex_lock(&xen_pcpu_lock);
+
+	while (!err && (cpu <=3D max_cpu)) {
+		err =3D sync_pcpu(cpu, &max_cpu);
+		cpu++;
+	}
+
+	if (err)
+		list_for_each_entry_safe(pcpu, tmp, &xen_pcpus, list)
+			unregister_and_remove_pcpu(pcpu);
+
+	mutex_unlock(&xen_pcpu_lock);
+
+	return err;
+}
+
+static void xen_pcpu_work_fn(struct work_struct *work)
+{
+	xen_sync_pcpus();
+}
+static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn);
+
+static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_pcpu_work);
+	return IRQ_HANDLED;
+}
+
+static int __init xen_pcpu_init(void)
+{
+	int irq, ret;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	irq =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
+				      xen_pcpu_interrupt, 0,
+				      "xen-pcpu", NULL);
+	if (irq < 0) {
+		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");
+		return irq;
+	}
+
+	ret =3D subsys_system_register(&xen_pcpu_subsys, NULL);
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
+		goto err1;
+	}
+
+	ret =3D xen_sync_pcpus();
+	if (ret) {
+		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
+		goto err2;
+	}
+
+	return 0;
+
+err2:
+	bus_unregister(&xen_pcpu_subsys);
+err1:
+	unbind_from_irqhandler(irq, NULL);
+	return ret;
+}
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 486653f..61fa661 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
=20
+#define XENPF_cpu_online	56
+#define XENPF_cpu_offline	57
+struct xenpf_cpu_ol {
+	uint32_t cpuid;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -330,6 +337,7 @@ struct xen_platform_op {
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
+		struct xenpf_cpu_ol            cpu_ol;
 		uint8_t                        pad[128];
 	} u;
 };
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..0801468 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -80,6 +80,7 @@
 #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. =
*/
 #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   =
*/
 #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   =
*/
+#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   =
*/
=20
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Xen-physical-cpus-online-offline-sys-interface.patch"
Content-Description: 0001-Xen-physical-cpus-online-offline-sys-interface.patch
Content-Disposition: attachment;
	filename="0001-Xen-physical-cpus-online-offline-sys-interface.patch";
	size=12976; creation-date="Mon, 11 Jun 2012 05:50:08 GMT";
	modification-date="Mon, 11 Jun 2012 13:44:12 GMT"
Content-Transfer-Encoding: base64

RnJvbSAyOTE1MmJiMDU0ZDg3MzM0ZWY5NzBhZDAzNzg4OGI3YmIwMzJmOGVmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogTW9uLCAxMSBKdW4gMjAxMiAyMDozODowOCArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIFhl
biBwaHlzaWNhbCBjcHVzIG9ubGluZS9vZmZsaW5lIHN5cyBpbnRlcmZhY2UKClRoaXMgcGF0Y2gg
cHJvdmlkZSBYZW4gcGh5c2ljYWwgY3B1cyBvbmxpbmUvb2ZmbGluZSBzeXMgaW50ZXJmYWNlLgpV
c2VyIGNhbiB1c2UgaXQgZm9yIHRoZWlyIG93biBwdXJwb3NlLCBsaWtlIHBvd2VyIHNhdmluZzoK
Ynkgb2ZmbGluaW5nIHNvbWUgY3B1cyB3aGVuIGxpZ2h0IHdvcmtsb2FkIGl0IHNhdmUgcG93ZXIg
Z3JlYXRseS4KCkl0cyBiYXNpYyB3b3JrZmxvdyBpcywgdXNlciBvbmxpbmUvb2ZmbGluZSBjcHUg
dmlhIHN5cyBpbnRlcmZhY2UsCnRoZW4gaHlwZXJjYWxsIHhlbiB0byBpbXBsZW1lbnQsIGFmdGVy
IGRvbmUgeGVuIGluamVjdCB2aXJxIGJhY2sgdG8gZG9tMCwKYW5kIHRoZW4gZG9tMCBzeW5jIGNw
dSBzdGF0dXMuCgpTaWduZWQtb2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0Bp
bnRlbC5jb20+ClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwu
Y29tPgotLS0KIC4uLi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5fY3B1ICAg
ICAgIHwgICAyMCArCiBkcml2ZXJzL3hlbi9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICAgIDEgKwogZHJpdmVycy94ZW4vcGNwdS5jICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfCAgMzcxICsrKysrKysrKysrKysrKysrKysrCiBpbmNsdWRlL3hlbi9pbnRl
cmZhY2UvcGxhdGZvcm0uaCAgICAgICAgICAgICAgICAgICB8ICAgIDggKwogaW5jbHVkZS94ZW4v
aW50ZXJmYWNlL3hlbi5oICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAxICsKIDUgZmlsZXMg
Y2hhbmdlZCwgNDAxIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAx
MDA2NDQgRG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5f
Y3B1CiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4vcGNwdS5jCgpkaWZmIC0tZ2l0IGEv
RG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5fY3B1IGIv
RG9jdW1lbnRhdGlvbi9BQkkvdGVzdGluZy9zeXNmcy1kZXZpY2VzLXN5c3RlbS14ZW5fY3B1Cm5l
dyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjljYTAyZmIKLS0tIC9kZXYvbnVsbAor
KysgYi9Eb2N1bWVudGF0aW9uL0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9j
cHUKQEAgLTAsMCArMSwyMCBAQAorV2hhdDoJCS9zeXMvZGV2aWNlcy9zeXN0ZW0veGVuX2NwdS8K
K0RhdGU6CQlNYXkgMjAxMgorQ29udGFjdDoJTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRl
bC5jb20+CitEZXNjcmlwdGlvbjoKKwkJQSBjb2xsZWN0aW9uIG9mIGdsb2JhbC9pbmRpdmlkdWFs
IFhlbiBwaHlzaWNhbCBjcHUgYXR0cmlidXRlcworCisJCUluZGl2aWR1YWwgcGh5c2ljYWwgY3B1
IGF0dHJpYnV0ZXMgYXJlIGNvbnRhaW5lZCBpbgorCQlzdWJkaXJlY3RvcmllcyBuYW1lZCBieSB0
aGUgWGVuJ3MgbG9naWNhbCBjcHUgbnVtYmVyLCBlLmcuOgorCQkvc3lzL2RldmljZXMvc3lzdGVt
L3hlbl9jcHUveGVuX2NwdSMvCisKKworV2hhdDoJCS9zeXMvZGV2aWNlcy9zeXN0ZW0veGVuX2Nw
dS94ZW5fY3B1Iy9vbmxpbmUKK0RhdGU6CQlNYXkgMjAxMgorQ29udGFjdDoJTGl1LCBKaW5zb25n
IDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CitEZXNjcmlwdGlvbjoKKwkJSW50ZXJmYWNlIHRvIG9u
bGluZS9vZmZsaW5lIFhlbiBwaHlzaWNhbCBjcHVzCisKKwkJV2hlbiBydW5uaW5nIHVuZGVyIFhl
biBwbGF0Zm9ybSwgaXQgcHJvdmlkZSB1c2VyIGludGVyZmFjZQorCQl0byBvbmxpbmUvb2ZmbGlu
ZSBwaHlzaWNhbCBjcHVzLCBleGNlcHQgY3B1MCBkdWUgdG8gc2V2ZXJhbAorCQlsb2dpYyByZXN0
cmljdGlvbnMgYW5kIGFzc3VtcHRpb25zLgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vTWFrZWZp
bGUgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQppbmRleCBhNzg3MDI5Li5kODBiZWE1IDEwMDY0NAot
LS0gYS9kcml2ZXJzL3hlbi9NYWtlZmlsZQorKysgYi9kcml2ZXJzL3hlbi9NYWtlZmlsZQpAQCAt
MTcsNiArMTcsNyBAQCBvYmotJChDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SKQkrPSBzeXMtaHlw
ZXJ2aXNvci5vCiBvYmotJChDT05GSUdfWEVOX1BWSFZNKQkJCSs9IHBsYXRmb3JtLXBjaS5vCiBv
YmotJChDT05GSUdfWEVOX1RNRU0pCQkJKz0gdG1lbS5vCiBvYmotJChDT05GSUdfU1dJT1RMQl9Y
RU4pCQkrPSBzd2lvdGxiLXhlbi5vCitvYmotJChDT05GSUdfWEVOX0RPTTApCQkJKz0gcGNwdS5v
CiBvYmotJChDT05GSUdfWEVOX0RPTTApCQkJKz0gcGNpLm8gYWNwaS5vCiBvYmotJChDT05GSUdf
WEVOX01DRV9MT0cpCQkrPSBtY2Vsb2cubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO
RCkJKz0geGVuLXBjaWJhY2svCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wY3B1LmMgYi9kcml2
ZXJzL3hlbi9wY3B1LmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMDY3ZmNm
YQotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMveGVuL3BjcHUuYwpAQCAtMCwwICsxLDM3MSBA
QAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKgorICogcGNwdS5jCisgKiBNYW5hZ2VtZW50IHBoeXNp
Y2FsIGNwdSBpbiBkb20wLCBnZXQgcGNwdSBpbmZvIGFuZCBwcm92aWRlIHN5cyBpbnRlcmZhY2UK
KyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24KKyAqIEF1dGhvcjog
TGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKiBBdXRob3I6IEppYW5nLCBZ
dW5ob25nIDx5dW5ob25nLmppYW5nQGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkg
aXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJz
aW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBv
ciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwg
b3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0
IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBn
cmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5Cisg
KiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNv
ZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwg
ZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2Fy
ZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJu
aXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoK
KyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5v
dGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBw
b3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVE
ICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElN
UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVS
Q0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5P
TklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlS
SUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisg
KiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9U
SEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBU
SEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRX
QVJFLgorICovCisKKyNpbmNsdWRlIDxsaW51eC9pbnRlcnJ1cHQuaD4KKyNpbmNsdWRlIDxsaW51
eC9zcGlubG9jay5oPgorI2luY2x1ZGUgPGxpbnV4L2NwdS5oPgorI2luY2x1ZGUgPGxpbnV4L3N0
YXQuaD4KKyNpbmNsdWRlIDxsaW51eC9jYXBhYmlsaXR5Lmg+CisKKyNpbmNsdWRlIDx4ZW4veGVu
Lmg+CisjaW5jbHVkZSA8eGVuL3hlbmJ1cy5oPgorI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNp
bmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBl
cnZpc29yLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKworI2RlZmluZSBYRU5f
UENQVSAieGVuX2NwdTogIgorCisvKgorICogQGNwdV9pZDogWGVuIHBoeXNpY2FsIGNwdSBsb2dp
YyBudW1iZXIKKyAqIEBmbGFnczogWGVuIHBoeXNpY2FsIGNwdSBzdGF0dXMgZmxhZworICogLSBY
RU5fUENQVV9GTEFHU19PTkxJTkU6IGNwdSBpcyBvbmxpbmUKKyAqIC0gWEVOX1BDUFVfRkxBR1Nf
SU5WQUxJRDogY3B1IGlzIG5vdCBwcmVzZW50CisgKi8KK3N0cnVjdCBwY3B1IHsKKwlzdHJ1Y3Qg
bGlzdF9oZWFkIGxpc3Q7CisJc3RydWN0IGRldmljZSBkZXY7CisJdWludDMyX3QgY3B1X2lkOwor
CXVpbnQzMl90IGZsYWdzOworfTsKKworc3RhdGljIHN0cnVjdCBidXNfdHlwZSB4ZW5fcGNwdV9z
dWJzeXMgPSB7CisJLm5hbWUgPSAieGVuX2NwdSIsCisJLmRldl9uYW1lID0gInhlbl9jcHUiLAor
fTsKKworc3RhdGljIERFRklORV9NVVRFWCh4ZW5fcGNwdV9sb2NrKTsKKworc3RhdGljIExJU1Rf
SEVBRCh4ZW5fcGNwdXMpOworCitzdGF0aWMgaW50IHhlbl9wY3B1X2Rvd24odWludDMyX3QgY3B1
X2lkKQoreworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBG
X2NwdV9vZmZsaW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVS
U0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCQk9IGNwdV9pZCwKKwl9OworCisJcmV0dXJuIEhZUEVS
VklTT1JfZG9tMF9vcCgmb3ApOworfQorCitzdGF0aWMgaW50IHhlbl9wY3B1X3VwKHVpbnQzMl90
IGNwdV9pZCkKK3sKKwlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kCQkJPSBY
RU5QRl9jcHVfb25saW5lLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0Vf
VkVSU0lPTiwKKwkJLnUuY3B1X29sLmNwdWlkCQk9IGNwdV9pZCwKKwl9OworCisJcmV0dXJuIEhZ
UEVSVklTT1JfZG9tMF9vcCgmb3ApOworfQorCitzdGF0aWMgc3NpemVfdCBzaG93X29ubGluZShz
dHJ1Y3QgZGV2aWNlICpkZXYsCisJCQkgICBzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwK
KwkJCSAgIGNoYXIgKmJ1ZikKK3sKKwlzdHJ1Y3QgcGNwdSAqY3B1ID0gY29udGFpbmVyX29mKGRl
diwgc3RydWN0IHBjcHUsIGRldik7CisKKwlyZXR1cm4gc3ByaW50ZihidWYsICIldVxuIiwgISEo
Y3B1LT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX09OTElORSkpOworfQorCitzdGF0aWMgc3NpemVf
dCBfX3JlZiBzdG9yZV9vbmxpbmUoc3RydWN0IGRldmljZSAqZGV2LAorCQkJCSAgc3RydWN0IGRl
dmljZV9hdHRyaWJ1dGUgKmF0dHIsCisJCQkJICBjb25zdCBjaGFyICpidWYsIHNpemVfdCBjb3Vu
dCkKK3sKKwlzdHJ1Y3QgcGNwdSAqcGNwdSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1
LCBkZXYpOworCXVuc2lnbmVkIGxvbmcgbG9uZyB2YWw7CisJc3NpemVfdCByZXQ7CisKKwlpZiAo
IWNhcGFibGUoQ0FQX1NZU19BRE1JTikpCisJCXJldHVybiAtRVBFUk07CisKKwlpZiAoa3N0cnRv
dWxsKGJ1ZiwgMCwgJnZhbCkgPCAwKQorCQlyZXR1cm4gLUVJTlZBTDsKKworCXN3aXRjaCAodmFs
KSB7CisJY2FzZSAwOgorCQlyZXQgPSB4ZW5fcGNwdV9kb3duKHBjcHUtPmNwdV9pZCk7CisJCWJy
ZWFrOworCWNhc2UgMToKKwkJcmV0ID0geGVuX3BjcHVfdXAocGNwdS0+Y3B1X2lkKTsKKwkJYnJl
YWs7CisJZGVmYXVsdDoKKwkJcmV0ID0gLUVJTlZBTDsKKwl9CisKKwlpZiAocmV0ID49IDApCisJ
CXJldCA9IGNvdW50OworCXJldHVybiByZXQ7Cit9CitzdGF0aWMgREVWSUNFX0FUVFIob25saW5l
LCBTX0lSVUdPIHwgU19JV1VTUiwgc2hvd19vbmxpbmUsIHN0b3JlX29ubGluZSk7CisKK3N0YXRp
YyBib29sIHhlbl9wY3B1X29ubGluZSh1aW50MzJfdCBmbGFncykKK3sKKwlyZXR1cm4gISEoZmxh
Z3MgJiBYRU5fUENQVV9GTEFHU19PTkxJTkUpOworfQorCitzdGF0aWMgdm9pZCBwY3B1X29ubGlu
ZV9zdGF0dXMoc3RydWN0IHhlbnBmX3BjcHVpbmZvICppbmZvLAorCQkJICAgICAgIHN0cnVjdCBw
Y3B1ICpwY3B1KQoreworCWlmICh4ZW5fcGNwdV9vbmxpbmUoaW5mby0+ZmxhZ3MpICYmCisJICAg
IXhlbl9wY3B1X29ubGluZShwY3B1LT5mbGFncykpIHsKKwkJLyogdGhlIHBjcHUgaXMgb25saW5l
ZCAqLworCQlwY3B1LT5mbGFncyB8PSBYRU5fUENQVV9GTEFHU19PTkxJTkU7CisJCWtvYmplY3Rf
dWV2ZW50KCZwY3B1LT5kZXYua29iaiwgS09CSl9PTkxJTkUpOworCX0gZWxzZSBpZiAoIXhlbl9w
Y3B1X29ubGluZShpbmZvLT5mbGFncykgJiYKKwkJICAgIHhlbl9wY3B1X29ubGluZShwY3B1LT5m
bGFncykpIHsKKwkJLyogVGhlIHBjcHUgaXMgb2ZmbGluZWQgKi8KKwkJcGNwdS0+ZmxhZ3MgJj0g
flhFTl9QQ1BVX0ZMQUdTX09OTElORTsKKwkJa29iamVjdF91ZXZlbnQoJnBjcHUtPmRldi5rb2Jq
LCBLT0JKX09GRkxJTkUpOworCX0KK30KKworc3RhdGljIHN0cnVjdCBwY3B1ICpnZXRfcGNwdSh1
aW50MzJfdCBjcHVfaWQpCit7CisJc3RydWN0IHBjcHUgKnBjcHU7CisKKwlsaXN0X2Zvcl9lYWNo
X2VudHJ5KHBjcHUsICZ4ZW5fcGNwdXMsIGxpc3QpIHsKKwkJaWYgKHBjcHUtPmNwdV9pZCA9PSBj
cHVfaWQpCisJCQlyZXR1cm4gcGNwdTsKKwl9CisKKwlyZXR1cm4gTlVMTDsKK30KKworc3RhdGlj
IHZvaWQgcGNwdV9yZWxlYXNlKHN0cnVjdCBkZXZpY2UgKmRldikKK3sKKwlzdHJ1Y3QgcGNwdSAq
cGNwdSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBwY3B1LCBkZXYpOworCisJbGlzdF9kZWwo
JnBjcHUtPmxpc3QpOworCWtmcmVlKHBjcHUpOworfQorCitzdGF0aWMgdm9pZCB1bnJlZ2lzdGVy
X2FuZF9yZW1vdmVfcGNwdShzdHJ1Y3QgcGNwdSAqcGNwdSkKK3sKKwlzdHJ1Y3QgZGV2aWNlICpk
ZXY7CisKKwlpZiAoIXBjcHUpCisJCXJldHVybjsKKworCWRldiA9ICZwY3B1LT5kZXY7CisJaWYg
KGRldi0+aWQpCisJCWRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZfYXR0cl9vbmxpbmUpOwor
CisJLyogcGNwdSByZW1vdmUgd291bGQgYmUgaW1wbGljaXRseSBkb25lICovCisJZGV2aWNlX3Vu
cmVnaXN0ZXIoZGV2KTsKK30KKworc3RhdGljIGludCByZWdpc3Rlcl9wY3B1KHN0cnVjdCBwY3B1
ICpwY3B1KQoreworCXN0cnVjdCBkZXZpY2UgKmRldjsKKwlpbnQgZXJyID0gLUVJTlZBTDsKKwor
CWlmICghcGNwdSkKKwkJcmV0dXJuIGVycjsKKworCWRldiA9ICZwY3B1LT5kZXY7CisJZGV2LT5i
dXMgPSAmeGVuX3BjcHVfc3Vic3lzOworCWRldi0+aWQgPSBwY3B1LT5jcHVfaWQ7CisJZGV2LT5y
ZWxlYXNlID0gcGNwdV9yZWxlYXNlOworCisJZXJyID0gZGV2aWNlX3JlZ2lzdGVyKGRldik7CisJ
aWYgKGVycikgeworCQlwY3B1X3JlbGVhc2UoZGV2KTsKKwkJcmV0dXJuIGVycjsKKwl9CisKKwkv
KgorCSAqIFhlbiBuZXZlciBvZmZsaW5lIGNwdTAgZHVlIHRvIHNldmVyYWwgcmVzdHJpY3Rpb25z
CisJICogYW5kIGFzc3VtcHRpb25zLiBUaGlzIGJhc2ljYWxseSBkb2Vzbid0IGFkZCBhIHN5cyBj
b250cm9sCisJICogdG8gdXNlciwgb25lIGNhbm5vdCBhdHRlbXB0IHRvIG9mZmxpbmUgQlNQLgor
CSAqLworCWlmIChkZXYtPmlkKSB7CisJCWVyciA9IGRldmljZV9jcmVhdGVfZmlsZShkZXYsICZk
ZXZfYXR0cl9vbmxpbmUpOworCQlpZiAoZXJyKSB7CisJCQlkZXZpY2VfdW5yZWdpc3RlcihkZXYp
OworCQkJcmV0dXJuIGVycjsKKwkJfQorCX0KKworCXJldHVybiAwOworfQorCitzdGF0aWMgc3Ry
dWN0IHBjcHUgKmNyZWF0ZV9hbmRfcmVnaXN0ZXJfcGNwdShzdHJ1Y3QgeGVucGZfcGNwdWluZm8g
KmluZm8pCit7CisJc3RydWN0IHBjcHUgKnBjcHU7CisJaW50IGVycjsKKworCWlmIChpbmZvLT5m
bGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpCisJCXJldHVybiBFUlJfUFRSKC1FTk9ERVYp
OworCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBwY3B1KSwgR0ZQX0tFUk5FTCk7CisJ
aWYgKCFwY3B1KQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKworCUlOSVRfTElTVF9IRUFE
KCZwY3B1LT5saXN0KTsKKwlwY3B1LT5jcHVfaWQgPSBpbmZvLT54ZW5fY3B1aWQ7CisJcGNwdS0+
ZmxhZ3MgPSBpbmZvLT5mbGFnczsKKworCS8qIE5lZWQgaG9sZCBvbiB4ZW5fcGNwdV9sb2NrIGJl
Zm9yZSBwY3B1IGxpc3QgbWFuaXB1bGF0aW9ucyAqLworCWxpc3RfYWRkX3RhaWwoJnBjcHUtPmxp
c3QsICZ4ZW5fcGNwdXMpOworCisJZXJyID0gcmVnaXN0ZXJfcGNwdShwY3B1KTsKKwlpZiAoZXJy
KSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZhaWxlZCB0byByZWdpc3RlciBwY3B1JXVcbiIs
CisJCQkgICBpbmZvLT54ZW5fY3B1aWQpOworCQlyZXR1cm4gRVJSX1BUUigtRU5PRU5UKTsKKwl9
CisKKwlyZXR1cm4gcGNwdTsKK30KKworLyoKKyAqIENhbGxlciBzaG91bGQgaG9sZCB0aGUgeGVu
X3BjcHVfbG9jaworICovCitzdGF0aWMgaW50IHN5bmNfcGNwdSh1aW50MzJfdCBjcHUsIHVpbnQz
Ml90ICptYXhfY3B1KQoreworCWludCByZXQ7CisJc3RydWN0IHBjcHUgKnBjcHUgPSBOVUxMOwor
CXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbzsKKwlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9w
ID0geworCQkuY21kICAgICAgICAgICAgICAgICAgID0gWEVOUEZfZ2V0X2NwdWluZm8sCisJCS5p
bnRlcmZhY2VfdmVyc2lvbiAgICAgPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUucGNw
dV9pbmZvLnhlbl9jcHVpZCA9IGNwdSwKKwl9OworCisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29w
KCZvcCk7CisJaWYgKHJldCkKKwkJcmV0dXJuIHJldDsKKworCWluZm8gPSAmb3AudS5wY3B1X2lu
Zm87CisJaWYgKG1heF9jcHUpCisJCSptYXhfY3B1ID0gaW5mby0+bWF4X3ByZXNlbnQ7CisKKwlw
Y3B1ID0gZ2V0X3BjcHUoY3B1KTsKKworCS8qCisJICogT25seSB0aG9zZSBhdCBjcHUgcHJlc2Vu
dCBtYXAgaGFzIGl0cyBzeXMgaW50ZXJmYWNlLgorCSAqLworCWlmIChpbmZvLT5mbGFncyAmIFhF
Tl9QQ1BVX0ZMQUdTX0lOVkFMSUQpIHsKKwkJaWYgKHBjcHUpCisJCQl1bnJlZ2lzdGVyX2FuZF9y
ZW1vdmVfcGNwdShwY3B1KTsKKwkJcmV0dXJuIDA7CisJfQorCisJaWYgKCFwY3B1KSB7CisJCXBj
cHUgPSBjcmVhdGVfYW5kX3JlZ2lzdGVyX3BjcHUoaW5mbyk7CisJCWlmIChJU19FUlJfT1JfTlVM
TChwY3B1KSkKKwkJCXJldHVybiAtRU5PREVWOworCX0gZWxzZQorCQlwY3B1X29ubGluZV9zdGF0
dXMoaW5mbywgcGNwdSk7CisKKwlyZXR1cm4gMDsKK30KKworLyoKKyAqIFN5bmMgZG9tMCdzIHBj
cHUgaW5mb3JtYXRpb24gd2l0aCB4ZW4gaHlwZXJ2aXNvcidzCisgKi8KK3N0YXRpYyBpbnQgeGVu
X3N5bmNfcGNwdXModm9pZCkKK3sKKwkvKgorCSAqIEJvb3QgY3B1IGFsd2F5cyBoYXZlIGNwdV9p
ZCAwIGluIHhlbgorCSAqLworCXVpbnQzMl90IGNwdSA9IDAsIG1heF9jcHUgPSAwOworCWludCBl
cnIgPSAwOworCXN0cnVjdCBwY3B1ICpwY3B1LCAqdG1wOworCisJbXV0ZXhfbG9jaygmeGVuX3Bj
cHVfbG9jayk7CisKKwl3aGlsZSAoIWVyciAmJiAoY3B1IDw9IG1heF9jcHUpKSB7CisJCWVyciA9
IHN5bmNfcGNwdShjcHUsICZtYXhfY3B1KTsKKwkJY3B1Kys7CisJfQorCisJaWYgKGVycikKKwkJ
bGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBjcHUsIHRtcCwgJnhlbl9wY3B1cywgbGlzdCkKKwkJ
CXVucmVnaXN0ZXJfYW5kX3JlbW92ZV9wY3B1KHBjcHUpOworCisJbXV0ZXhfdW5sb2NrKCZ4ZW5f
cGNwdV9sb2NrKTsKKworCXJldHVybiBlcnI7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9wY3B1X3dv
cmtfZm4oc3RydWN0IHdvcmtfc3RydWN0ICp3b3JrKQoreworCXhlbl9zeW5jX3BjcHVzKCk7Cit9
CitzdGF0aWMgREVDTEFSRV9XT1JLKHhlbl9wY3B1X3dvcmssIHhlbl9wY3B1X3dvcmtfZm4pOwor
CitzdGF0aWMgaXJxcmV0dXJuX3QgeGVuX3BjcHVfaW50ZXJydXB0KGludCBpcnEsIHZvaWQgKmRl
dl9pZCkKK3sKKwlzY2hlZHVsZV93b3JrKCZ4ZW5fcGNwdV93b3JrKTsKKwlyZXR1cm4gSVJRX0hB
TkRMRUQ7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IHhlbl9wY3B1X2luaXQodm9pZCkKK3sKKwlp
bnQgaXJxLCByZXQ7CisKKwlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQorCQlyZXR1cm4gLUVO
T0RFVjsKKworCWlycSA9IGJpbmRfdmlycV90b19pcnFoYW5kbGVyKFZJUlFfUENQVV9TVEFURSwg
MCwKKwkJCQkgICAgICB4ZW5fcGNwdV9pbnRlcnJ1cHQsIDAsCisJCQkJICAgICAgInhlbi1wY3B1
IiwgTlVMTCk7CisJaWYgKGlycSA8IDApIHsKKwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVk
IHRvIGJpbmQgcGNwdSB2aXJxXG4iKTsKKwkJcmV0dXJuIGlycTsKKwl9CisKKwlyZXQgPSBzdWJz
eXNfc3lzdGVtX3JlZ2lzdGVyKCZ4ZW5fcGNwdV9zdWJzeXMsIE5VTEwpOworCWlmIChyZXQpIHsK
KwkJcHJfd2FybmluZyhYRU5fUENQVSAiRmFpbGVkIHRvIHJlZ2lzdGVyIHBjcHUgc3Vic3lzXG4i
KTsKKwkJZ290byBlcnIxOworCX0KKworCXJldCA9IHhlbl9zeW5jX3BjcHVzKCk7CisJaWYgKHJl
dCkgeworCQlwcl93YXJuaW5nKFhFTl9QQ1BVICJGYWlsZWQgdG8gc3luYyBwY3B1IGluZm9cbiIp
OworCQlnb3RvIGVycjI7CisJfQorCisJcmV0dXJuIDA7CisKK2VycjI6CisJYnVzX3VucmVnaXN0
ZXIoJnhlbl9wY3B1X3N1YnN5cyk7CitlcnIxOgorCXVuYmluZF9mcm9tX2lycWhhbmRsZXIoaXJx
LCBOVUxMKTsKKwlyZXR1cm4gcmV0OworfQorYXJjaF9pbml0Y2FsbCh4ZW5fcGNwdV9pbml0KTsK
ZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIGIvaW5jbHVkZS94
ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggNDg2NjUzZi4uNjFmYTY2MSAxMDA2NDQKLS0t
IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKKysrIGIvaW5jbHVkZS94ZW4vaW50
ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMxNCw2ICszMTQsMTMgQEAgc3RydWN0IHhlbnBmX3BjcHVp
bmZvIHsKIH07CiBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5wZl9wY3B1aW5mbyk7CiAK
KyNkZWZpbmUgWEVOUEZfY3B1X29ubGluZQk1NgorI2RlZmluZSBYRU5QRl9jcHVfb2ZmbGluZQk1
Nworc3RydWN0IHhlbnBmX2NwdV9vbCB7CisJdWludDMyX3QgY3B1aWQ7Cit9OworREVGSU5FX0dV
RVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY3B1X29sKTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9v
cCB7CiAJdWludDMyX3QgY21kOwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5Q
Rl9JTlRFUkZBQ0VfVkVSU0lPTiAqLwpAQCAtMzMwLDYgKzMzNyw3IEBAIHN0cnVjdCB4ZW5fcGxh
dGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZfZ2V0aWRsZXRpbWUgICAgICAgZ2V0aWRsZXRpbWU7
CiAJCXN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyBzZXRfcG1pbmZvOwogCQlzdHJ1
Y3QgeGVucGZfcGNwdWluZm8gICAgICAgICAgcGNwdV9pbmZvOworCQlzdHJ1Y3QgeGVucGZfY3B1
X29sICAgICAgICAgICAgY3B1X29sOwogCQl1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAg
cGFkWzEyOF07CiAJfSB1OwogfTsKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS94
ZW4uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaAppbmRleCBhODkwODA0Li4wODAxNDY4
IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKKysrIGIvaW5jbHVkZS94
ZW4vaW50ZXJmYWNlL3hlbi5oCkBAIC04MCw2ICs4MCw3IEBACiAjZGVmaW5lIFZJUlFfQ09OU09M
RSAgICAyICAvKiAoRE9NMCkgQnl0ZXMgcmVjZWl2ZWQgb24gZW1lcmdlbmN5IGNvbnNvbGUuICov
CiAjZGVmaW5lIFZJUlFfRE9NX0VYQyAgICAzICAvKiAoRE9NMCkgRXhjZXB0aW9uYWwgZXZlbnQg
Zm9yIHNvbWUgZG9tYWluLiAgICovCiAjZGVmaW5lIFZJUlFfREVCVUdHRVIgICA2ICAvKiAoRE9N
MCkgQSBkb21haW4gaGFzIHBhdXNlZCBmb3IgZGVidWdnaW5nLiAgICovCisjZGVmaW5lIFZJUlFf
UENQVV9TVEFURSA5ICAvKiAoRE9NMCkgUENQVSBzdGF0ZSBjaGFuZ2VkICAgICAgICAgICAgICAg
ICAgICovCiAKIC8qIEFyY2hpdGVjdHVyZS1zcGVjaWZpYyBWSVJRIGRlZmluaXRpb25zLiAqLwog
I2RlZmluZSBWSVJRX0FSQ0hfMCAgICAxNgotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923352259E4SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Jun 11 07:39:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 07:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SdzDX-0008Ob-6a; Mon, 11 Jun 2012 07:39:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>) id 1SdzDV-0008OS-K8
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 07:39:13 +0000
Received: from [85.158.143.99:26329] by server-3.bemta-4.messagelabs.com id
	14/A4-05808-0A0A5DF4; Mon, 11 Jun 2012 07:39:12 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339400352!28831580!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTY3NTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15578 invoked from network); 11 Jun 2012 07:39:12 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 07:39:12 -0000
Received: by mail.swisscom.com; Mon, 11 Jun 2012 09:39:11 +0200
From: <Philippe.Simonet@swisscom.com>
To: <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
Thread-Index: AQHNRYG6VKrmQrS7FkO4U0Ip5+I07Zb0vhLQ
Date: Mon, 11 Jun 2012 07:39:10 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF7313927BD@sg000713.corproot.net>
References: <20120608141857.GG11695@bitfolk.com>
In-Reply-To: <20120608141857.GG11695@bitfolk.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.36]
MIME-Version: 1.0
Cc: andy@strugglers.net
Subject: Re: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hallo

i had the same  problem ** a lot of time **, on 4 different system, but not anymore since I reboot my machines at regular interval (each month ....)
what says your xm dmesg after the problem? what was your system uptime ? 

by me it occurs on 4 different  HP DL 385 with  AMD Opteron(tm) Processor 6174
but never on same machines but with Quad-Core AMD Opteron(tm) Processor 2384.

Regards

Philippe


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Andy Smith
> Sent: Friday, June 08, 2012 4:19 PM
> To: xen-devel@lists.xen.org
> Cc: olivier.hanesse
> Subject: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
> 
> Hi,
> 
> I have two installs of Xen 4.0.1 on Debian squeeze dom0s that occasionally
> skew the time by 3000 seconds. It is always 3000 seconds and it always
> affects all guests.
> 
> Depending on the kernels in the guests they will say:
> 
>     tp0 kernel: [9339489.266542] Clocksource tsc unstable (delta = -
> 2999660317697 ns)
> 
> or perhaps the kernel doesn't notice but ntpd does:
> 
>     ls0 ntpd[15009]: time reset -2999.683517 s
> 
> the point is it does affect all guests.
> 
> Back in February 2011 there was a thread started by Olivier Hanesse which
> appears to be exactly the same issue:
> 
>     http://old-list-archives.xen.org/archives/html/xen-users/2011-
> 02/msg00609.html
> 
> Like Olivier, one of my hosts used to run Xen 3.x and did not experience this
> issue until after it was upgraded to Xen 4. The other has only ever run 4.0.x
> so I don't know.
> 
> The above thread ends with Olivier using clocksource=pit on his Xen
> command line and waiting to see if it fixed things. If you are reading,
> Olivier, did it fix things for you?
> 
> These are Debian squeeze installs so using packaged versions of xen and
> kernel:
> 
> ii  linux-image-2.6.32-5-xen-amd64 2.6.32-45 Linux 2.6.32 for 64-bit PCs, Xen
> dom0 support
> ii  xen-hypervisor-4.0-amd64       4.0.1-4   The Xen Hypervisor on AMD64
> 
> One of the hosts affected is:
> 
> CPU: Xeon 5410
> Motherboard: Supermicro X7DCL-i
> 
> The other is:
> 
> CPU: Xeon E5606
> Motherboard: SUpermicro X8DTN+
> 
> but I do have other servers with same hardware as both of these that aren't
> affected.
> 
> Cheers,
> Andy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 11 07:39:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 07:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SdzDX-0008Ob-6a; Mon, 11 Jun 2012 07:39:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>) id 1SdzDV-0008OS-K8
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 07:39:13 +0000
Received: from [85.158.143.99:26329] by server-3.bemta-4.messagelabs.com id
	14/A4-05808-0A0A5DF4; Mon, 11 Jun 2012 07:39:12 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339400352!28831580!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTY3NTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15578 invoked from network); 11 Jun 2012 07:39:12 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 07:39:12 -0000
Received: by mail.swisscom.com; Mon, 11 Jun 2012 09:39:11 +0200
From: <Philippe.Simonet@swisscom.com>
To: <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
Thread-Index: AQHNRYG6VKrmQrS7FkO4U0Ip5+I07Zb0vhLQ
Date: Mon, 11 Jun 2012 07:39:10 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF7313927BD@sg000713.corproot.net>
References: <20120608141857.GG11695@bitfolk.com>
In-Reply-To: <20120608141857.GG11695@bitfolk.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.36]
MIME-Version: 1.0
Cc: andy@strugglers.net
Subject: Re: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hallo

i had the same  problem ** a lot of time **, on 4 different system, but not anymore since I reboot my machines at regular interval (each month ....)
what says your xm dmesg after the problem? what was your system uptime ? 

by me it occurs on 4 different  HP DL 385 with  AMD Opteron(tm) Processor 6174
but never on same machines but with Quad-Core AMD Opteron(tm) Processor 2384.

Regards

Philippe


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Andy Smith
> Sent: Friday, June 08, 2012 4:19 PM
> To: xen-devel@lists.xen.org
> Cc: olivier.hanesse
> Subject: [Xen-devel] Xen 4.0.x 3,000 second time skew problem
> 
> Hi,
> 
> I have two installs of Xen 4.0.1 on Debian squeeze dom0s that occasionally
> skew the time by 3000 seconds. It is always 3000 seconds and it always
> affects all guests.
> 
> Depending on the kernels in the guests they will say:
> 
>     tp0 kernel: [9339489.266542] Clocksource tsc unstable (delta = -
> 2999660317697 ns)
> 
> or perhaps the kernel doesn't notice but ntpd does:
> 
>     ls0 ntpd[15009]: time reset -2999.683517 s
> 
> the point is it does affect all guests.
> 
> Back in February 2011 there was a thread started by Olivier Hanesse which
> appears to be exactly the same issue:
> 
>     http://old-list-archives.xen.org/archives/html/xen-users/2011-
> 02/msg00609.html
> 
> Like Olivier, one of my hosts used to run Xen 3.x and did not experience this
> issue until after it was upgraded to Xen 4. The other has only ever run 4.0.x
> so I don't know.
> 
> The above thread ends with Olivier using clocksource=pit on his Xen
> command line and waiting to see if it fixed things. If you are reading,
> Olivier, did it fix things for you?
> 
> These are Debian squeeze installs so using packaged versions of xen and
> kernel:
> 
> ii  linux-image-2.6.32-5-xen-amd64 2.6.32-45 Linux 2.6.32 for 64-bit PCs, Xen
> dom0 support
> ii  xen-hypervisor-4.0-amd64       4.0.1-4   The Xen Hypervisor on AMD64
> 
> One of the hosts affected is:
> 
> CPU: Xeon 5410
> Motherboard: Supermicro X7DCL-i
> 
> The other is:
> 
> CPU: Xeon E5606
> Motherboard: SUpermicro X8DTN+
> 
> but I do have other servers with same hardware as both of these that aren't
> affected.
> 
> Cheers,
> Andy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 11 08:00:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 08:00: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 1SdzXc-0000HV-3m; Mon, 11 Jun 2012 08:00: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 1SdzXa-0000HQ-GI
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 07:59:58 +0000
Received: from [85.158.139.83:16988] by server-9.bemta-5.messagelabs.com id
	E4/0B-29678-D75A5DF4; Mon, 11 Jun 2012 07:59:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339401596!33255778!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32209 invoked from network); 11 Jun 2012 07:59:57 -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; 11 Jun 2012 07:59:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 08:59:56 +0100
Message-Id: <4FD5C19702000078000892B0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 08:59:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Moskalenko" <mav@elserv.ru>
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
	<4FD1D1A6.4090900@elserv.ru>
	<4FD202720200007800088BFB@nat28.tlf.novell.com>
	<4FD26A93.9070002@elserv.ru>
In-Reply-To: <4FD26A93.9070002@elserv.ru>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 23:11, Alex Moskalenko <mav@elserv.ru> wrote:
> I attached full dmesg output of kernel 3.3.8.

So this

[    1.752498] IO APIC #9......
...
[    1.752558]  0f 00  0    0    0   0   0    0    0    00

clearly is a firmware bug - it's plain unacceptable for the firmware
to unmask a completely uninitialized RTE. I'm afraid you'll need to
get IBM to address this (assuming you're running the latest
firmware, and hence they haven't already).

> Also I removed the 'Store' and 'And' statements from DSDT and compiled 
> it. When altered DSDT is loaded with grub, kernel 3.3.8 boots 
> successfully (good!). But with hypervisor boot process hangs at loading 
> aacraid module (last message is about setting up IRQ). Aacraid module 
> loads without any problem on bare hardware. Kernel 2.6.32 boots 
> successfully and loads all modules. I think this issue is not related to 
> patched DSDT, but I'm not sure.

Given the above plus the fact that the driver uses PCI-MSI this
is indeed unlikely. But you ought to post kernel _and_ hypervisor
logs to be able to at least try to help.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 08:00:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 08:00: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 1SdzXc-0000HV-3m; Mon, 11 Jun 2012 08:00: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 1SdzXa-0000HQ-GI
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 07:59:58 +0000
Received: from [85.158.139.83:16988] by server-9.bemta-5.messagelabs.com id
	E4/0B-29678-D75A5DF4; Mon, 11 Jun 2012 07:59:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339401596!33255778!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32209 invoked from network); 11 Jun 2012 07:59:57 -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; 11 Jun 2012 07:59:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 08:59:56 +0100
Message-Id: <4FD5C19702000078000892B0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 08:59:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Moskalenko" <mav@elserv.ru>
References: <4FD0747D.10103@elserv.ru>
	<4FD1C9370200007800088AD8@nat28.tlf.novell.com>
	<4FD1D1A6.4090900@elserv.ru>
	<4FD202720200007800088BFB@nat28.tlf.novell.com>
	<4FD26A93.9070002@elserv.ru>
In-Reply-To: <4FD26A93.9070002@elserv.ru>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Pv_ops Dom0 crash on IBM eServer x3400
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 23:11, Alex Moskalenko <mav@elserv.ru> wrote:
> I attached full dmesg output of kernel 3.3.8.

So this

[    1.752498] IO APIC #9......
...
[    1.752558]  0f 00  0    0    0   0   0    0    0    00

clearly is a firmware bug - it's plain unacceptable for the firmware
to unmask a completely uninitialized RTE. I'm afraid you'll need to
get IBM to address this (assuming you're running the latest
firmware, and hence they haven't already).

> Also I removed the 'Store' and 'And' statements from DSDT and compiled 
> it. When altered DSDT is loaded with grub, kernel 3.3.8 boots 
> successfully (good!). But with hypervisor boot process hangs at loading 
> aacraid module (last message is about setting up IRQ). Aacraid module 
> loads without any problem on bare hardware. Kernel 2.6.32 boots 
> successfully and loads all modules. I think this issue is not related to 
> patched DSDT, but I'm not sure.

Given the above plus the fact that the driver uses PCI-MSI this
is indeed unlikely. But you ought to post kernel _and_ hypervisor
logs to be able to at least try to help.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 08:42:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 08: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 1Se0C9-0001BI-K6; Mon, 11 Jun 2012 08:41: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 1Se0C7-0001B8-Ki
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 08:41:52 +0000
Received: from [85.158.143.99:18033] by server-3.bemta-4.messagelabs.com id
	76/9A-05808-E4FA5DF4; Mon, 11 Jun 2012 08:41:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339404109!29886514!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5561 invoked from network); 11 Jun 2012 08:41:50 -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; 11 Jun 2012 08:41:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 09:41:49 +0100
Message-Id: <4FD5CB6A02000078000892D0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 09:41:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0729905A.0__="
Cc: Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH] x86: get rid of BOOT_TRAMPOLINE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part0729905A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We recently saw a machine that has the EBDA extending as low as 0x7c000,
so that Xen fails to boot after relocating the trampoline.  To fix this,
I removed BOOT_TRAMPOLINE and bootsym_phys completely.

Here are the parts:

1) the trampoline segment is set to 64k below the EBDA.  head.S grows
the ability to relocate the trampoline segment

2) reloc.c is made position-independent.  It allocates data below the
trampoline, whose address is passed in _eax.

3) cmdline.S is called before relocating, so all bootsym_phys there
become sym_phys.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

jb: - fall back to low memory size (instead of segment 0x7c00) if EBDA
      value is out of range
    - also add upper limit check on EBDA value
    - fix and simplify inline assembly operands in reloc_mbi_struct()
    - use lret instead of retf
    - renamed early_stack to wakeup_stack, defined and used now only
      in wakeup.S
    - aligned reloc.bin's end of .text to 16 bytes, so that checking
      __bss_start =3D=3D end works reliably

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -2,8 +2,7 @@ obj-bin-y +=3D head.o
=20
 head.o: reloc.S
=20
-BOOT_TRAMPOLINE :=3D $(shell sed -n 's,^\#define[[:space:]]\{1\,\}BOOT_TRA=
MPOLINE[[:space:]]\{1\,\},,p' head.S)
 %.S: %.c
-	RELOC=3D$(BOOT_TRAMPOLINE) $(MAKE) -f build32.mk $@
+	$(MAKE) -f build32.mk $@
=20
 reloc.S: head.S
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -16,9 +16,10 @@ CFLAGS :=3D $(filter-out -flto,$(CFLAGS))=20
 	$(OBJCOPY) -O binary $< $@
=20
 %.lnk: %.o
-	$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(RELOC) -o $@ $<
+	$(LD) $(LDFLAGS_DIRECT) -N -Ttext 0 -o $@ $<
=20
 %.o: %.c
-	$(CC) $(CFLAGS) -c $< -o $@
+	$(CC) $(CFLAGS) -c -fpic $< -o $@
=20
 reloc.o: $(BASEDIR)/include/asm-x86/config.h
+.PRECIOUS: %.bin %.lnk
--- a/xen/arch/x86/boot/cmdline.S
+++ b/xen/arch/x86/boot/cmdline.S
@@ -164,13 +164,13 @@ cmdline_parse_early:
         pushl   MB_cmdline(%ebx)
         call    .Lfind_option
         test    %eax,%eax
-        setnz   bootsym_phys(skip_realmode)
+        setnz   sym_phys(skip_realmode)
=20
         /* Check for 'tboot=3D' command-line option. */
         movl    $sym_phys(.Ltboot_opt),4(%esp)
         call    .Lfind_option
         test    %eax,%eax
-        setnz   bootsym_phys(skip_realmode) /* tboot=3D implies no-real-mo=
de */
+        setnz   sym_phys(skip_realmode) /* tboot=3D implies no-real-mode =
*/
=20
 .Lparse_edd:
         /* Check for 'edd=3D' command-line option. */
@@ -181,13 +181,13 @@ cmdline_parse_early:
         cmpb    $'=3D',3(%eax)
         jne     .Lparse_edid
         add     $4,%eax
-        movb    $2,bootsym_phys(opt_edd)  /* opt_edd=3D2: edd=3Doff */
+        movb    $2,sym_phys(opt_edd)  /* opt_edd=3D2: edd=3Doff */
         cmpw    $0x666f,(%eax)            /* 0x666f =3D=3D "of" */
         je      .Lparse_edid
-        decb    bootsym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr =
*/
+        decb    sym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr */
         cmpw    $0x6b73,(%eax)            /* 0x6b73 =3D=3D "sk" */
         je      .Lparse_edid
-        decb    bootsym_phys(opt_edd)     /* opt_edd=3D0: edd=3Don =
(default) */
+        decb    sym_phys(opt_edd)     /* opt_edd=3D0: edd=3Don (default) =
*/
=20
 .Lparse_edid:
         /* Check for 'edid=3D' command-line option. */
@@ -203,17 +203,17 @@ cmdline_parse_early:
         pushl   $sym_phys(.Ledid_force)
         call    .Lstr_prefix
         add     $8,%esp
-        movb    $2,bootsym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce =
*/
+        movb    $2,sym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce */
         test    %eax,%eax
         jz      .Lparse_vga
         push    %ebx
         pushl   $sym_phys(.Ledid_no)
         call    .Lstr_prefix
         add     $8,%esp
-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D1: edid=3Dno */
+        decb    sym_phys(opt_edid)    /* opt_edid=3D1: edid=3Dno */
         test    %eax,%eax
         jz      .Lparse_vga
-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D0: default */
+        decb    sym_phys(opt_edid)    /* opt_edid=3D0: default */
=20
 .Lparse_vga:
         /* Check for 'vga=3D' command-line option. */
@@ -227,7 +227,7 @@ cmdline_parse_early:
         add     $4,%eax
=20
         /* Found the 'vga=3D' option. Default option is to display vga =
menu. */
-        movw    $ASK_VGA,bootsym_phys(boot_vid_mode)
+        movw    $ASK_VGA,sym_phys(boot_vid_mode)
=20
         /* Check for 'vga=3Dtext-80x<rows>. */
         mov     %eax,%ebx
@@ -251,7 +251,7 @@ cmdline_parse_early:
         cmp     %ax,%bx
         lodsw
         jne     1b
-        mov     %ax,bootsym_phys(boot_vid_mode)
+        mov     %ax,sym_phys(boot_vid_mode)
         jmp     .Lcmdline_exit
=20
 .Lparse_vga_gfx:
@@ -270,7 +270,7 @@ cmdline_parse_early:
         push    %ebx
         call    .Latoi
         pop     %esi
-        mov     %ax,bootsym_phys(vesa_size)+0
+        mov     %ax,sym_phys(vesa_size)+0
         /* skip 'x' */
         lodsb
         cmpb    $'x',%al
@@ -279,7 +279,7 @@ cmdline_parse_early:
         push    %esi
         call    .Latoi
         pop     %esi
-        mov     %ax,bootsym_phys(vesa_size)+2
+        mov     %ax,sym_phys(vesa_size)+2
         /* skip 'x' */
         lodsb
         cmpb    $'x',%al
@@ -288,9 +288,9 @@ cmdline_parse_early:
         push    %esi
         call    .Latoi
         pop     %esi
-        mov     %ax,bootsym_phys(vesa_size)+4
+        mov     %ax,sym_phys(vesa_size)+4
         /* commit to vesa mode */
-        movw    $VIDEO_VESA_BY_SIZE,bootsym_phys(boot_vid_mode)
+        movw    $VIDEO_VESA_BY_SIZE,sym_phys(boot_vid_mode)
         jmp     .Lcmdline_exit
=20
 .Lparse_vga_mode:
@@ -307,7 +307,7 @@ cmdline_parse_early:
         push    %ebx
         call    .Latoi
         add     $4,%esp
-        mov     %ax,bootsym_phys(boot_vid_mode)
+        mov     %ax,sym_phys(boot_vid_mode)
         jmp     .Lcmdline_exit
=20
 .Lparse_vga_current:
@@ -320,7 +320,7 @@ cmdline_parse_early:
         jnz     .Lcmdline_exit
=20
         /* We have 'vga=3Dcurrent'. */
-        movw    $VIDEO_CURRENT_MODE,bootsym_phys(boot_vid_mode)
+        movw    $VIDEO_CURRENT_MODE,sym_phys(boot_vid_mode)
=20
 .Lcmdline_exit:
         popa
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -9,9 +9,7 @@
         .text
         .code32
=20
-#define BOOT_TRAMPOLINE   0x7c000
 #define sym_phys(sym)     ((sym) - __XEN_VIRT_START)
-#define bootsym_phys(sym) ((sym) - trampoline_start + BOOT_TRAMPOLINE)
=20
 #define BOOT_CS32        0x0008
 #define BOOT_CS64        0x0010
@@ -79,6 +77,23 @@ __start:
         cmp     $0x2BADB002,%eax
         jne     not_multiboot
=20
+        /* Set up trampoline segment 64k below EBDA */
+        movzwl  0x40e,%eax          /* EBDA segment */
+        cmp     $0xa000,%eax        /* sanity check (high) */
+        jae     0f
+        cmp     $0x4000,%eax        /* sanity check (low) */
+        jae     1f
+0:
+        movzwl  0x413,%eax          /* use base memory size on failure */
+        shl     $10-4,%eax
+1:
+        sub     $0x1000,%eax
+
+        /* From arch/x86/smpboot.c: start_eip had better be page-aligned! =
*/
+        xor     %al, %al
+        shl     $4, %eax
+        mov     %eax,sym_phys(trampoline_phys)
+
         /* Save the Multiboot info struct (after relocation) for later =
use. */
         mov     $sym_phys(cpu0_stack)+1024,%esp
         push    %ebx
@@ -190,7 +205,7 @@ __start:
 #endif
=20
         /* Apply relocations to bootstrap trampoline. */
-        mov     $BOOT_TRAMPOLINE,%edx
+        mov     sym_phys(trampoline_phys),%edx
         mov     $sym_phys(__trampoline_rel_start),%edi
         mov     %edx,sym_phys(trampoline_phys)
 1:
@@ -200,22 +215,35 @@ __start:
         cmp     $sym_phys(__trampoline_rel_stop),%edi
         jb      1b
=20
+        /* Patch in the trampoline segment. */
+        shr     $4,%edx
+        mov     $sym_phys(__trampoline_seg_start),%edi
+1:
+        mov     (%edi),%eax
+        mov     %dx,(%edi,%eax)
+        add     $4,%edi
+        cmp     $sym_phys(__trampoline_seg_stop),%edi
+        jb      1b
+
+        call    cmdline_parse_early
+
+        /* Switch to low-memory stack.  */
+        mov     sym_phys(trampoline_phys),%edi
+        lea     0x10000(%edi),%esp
+        lea     trampoline_boot_cpu_entry-trampoline_start(%edi),%eax
+        pushl   $BOOT_CS32
+        push    %eax
+
         /* Copy bootstrap trampoline to low memory, below 1MB. */
         mov     $sym_phys(trampoline_start),%esi
-        mov     %edx,%edi
         mov     $trampoline_end - trampoline_start,%ecx
         rep     movsb
=20
-        lea     early_stack-trampoline_start(%edx),%esp
-        call    cmdline_parse_early
-
         /* Jump into the relocated trampoline. */
-        jmp     $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry)
+        lret
=20
 #include "cmdline.S"
=20
-#undef bootsym_phys
-
 reloc:
 #include "reloc.S"
=20
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -10,42 +10,49 @@
  *    Keir Fraser <keir@xen.org>
  */
=20
+/* entered with %eax =3D BOOT_TRAMPOLINE */
 asm (
     "    .text                         \n"
     "    .globl _start                 \n"
     "_start:                           \n"
-    "    mov  $_start,%edi             \n"
     "    call 1f                       \n"
-    "1:  pop  %esi                     \n"
-    "    sub  $1b-_start,%esi          \n"
-    "    mov  $__bss_start-_start,%ecx \n"
-    "    rep  movsb                    \n"
-    "    xor  %eax,%eax                \n"
-    "    mov  $_end,%ecx               \n"
-    "    sub  %edi,%ecx                \n"
-    "    rep  stosb                    \n"
-    "    mov  $reloc,%eax              \n"
-    "    jmp  *%eax                    \n"
+    "1:  pop  %ebx                     \n"
+    "    mov  %eax,alloc-1b(%ebx)      \n"
+    "    mov  $_end,%ecx               \n"  /* check that BSS is empty! =
*/
+    "    sub  $__bss_start,%ecx        \n"
+    "    jz reloc                      \n"
+    "1:  jmp 1b                        \n"
+    );
+
+/* This is our data.  Because the code must be relocatable, no BSS is
+ * allowed.  All data is accessed PC-relative with inline assembly.
+ */
+asm (
+    "alloc:                            \n"
+    "    .long 0                       \n"
+    "    .subsection 1                 \n"
+    "    .p2align 4, 0xcc              \n"
+    "    .subsection 0                 \n"
     );
=20
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
=20
-extern char _start[];
-
-static void *memcpy(void *dest, const void *src, unsigned int n)
-{
-    char *s =3D (char *)src, *d =3D dest;
-    while ( n-- )
-        *d++ =3D *s++;
-    return dest;
-}
-
 static void *reloc_mbi_struct(void *old, unsigned int bytes)
 {
-    static void *alloc =3D &_start;
-    alloc =3D (void *)(((unsigned long)alloc - bytes) & ~15ul);
-    return memcpy(alloc, old, bytes);
+    void *new;
+    asm(
+    "    call 1f                      \n"
+    "1:  pop  %%edx                   \n"
+    "    mov  alloc-1b(%%edx),%0      \n"
+    "    sub  %1,%0                   \n"
+    "    and  $~15,%0                 \n"
+    "    mov  %0,alloc-1b(%%edx)      \n"
+    "    mov  %0,%%edi                \n"
+    "    rep  movsb                   \n"
+       : "=3D&r" (new), "+c" (bytes), "+S" (old)
+	: : "edx", "edi");
+    return new;
 }
=20
 static char *reloc_mbi_string(char *old)
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -11,6 +11,13 @@
         .long 111b - (off) - .;            \
         .popsection
=20
+#define bootsym_segrel(sym, off)           \
+        $0,$bootsym(sym);                  \
+111:;                                      \
+        .pushsection .trampoline_seg, "a"; \
+        .long 111b - (off) - .;            \
+        .popsection
+
         .globl trampoline_realmode_entry
 trampoline_realmode_entry:
         mov     %cs,%ax
@@ -151,14 +158,14 @@ trampoline_boot_cpu_entry:
 1:      mov     %eax,%cr0                 # CR0.PE =3D 0 (leave protected =
mode)
=20
         /* Load proper real-mode values into %cs, %ds, %es and %ss. */
-        ljmp    $(BOOT_TRAMPOLINE>>4),$bootsym(1f)
+        ljmp    bootsym_segrel(1f,2)
 1:      mov     %cs,%ax
         mov     %ax,%ds
         mov     %ax,%es
         mov     %ax,%ss
=20
         /* Initialise stack pointer and IDT, and enable irqs. */
-        mov     $bootsym(early_stack),%sp
+        xor     %sp,%sp
         lidt    bootsym(rm_idt)
         sti
=20
@@ -220,7 +227,3 @@ rm_idt: .word   256*4-1, 0, 0
 #include "edd.S"
 #include "video.S"
 #include "wakeup.S"
-
-        .align  16
-        .fill   PAGE_SIZE,1,0
-early_stack:
--- a/xen/arch/x86/boot/wakeup.S
+++ b/xen/arch/x86/boot/wakeup.S
@@ -11,7 +11,7 @@ ENTRY(wakeup_start)
         movw    %cs, %ax
         movw    %ax, %ds
         movw    %ax, %ss        # A stack required for BIOS call
-        movw    $wakesym(early_stack), %sp
+        movw    $wakesym(wakeup_stack), %sp
=20
         pushl   $0              # Kill dangerous flag early
         popfl
@@ -101,7 +101,7 @@ real_magic:     .long 0x12345678
          .globl video_mode, video_flags
 video_mode:     .long 0
 video_flags:    .long 0
-trampoline_seg: .word BOOT_TRAMPOLINE >> 4
+trampoline_seg: .word 0
         .pushsection .trampoline_seg, "a"
         .long   trampoline_seg - .
         .popsection
@@ -116,7 +116,7 @@ wakeup_32:
         mov     $BOOT_DS, %eax
         mov     %eax, %ds
         mov     %eax, %ss
-        mov     $bootsym_rel(early_stack, 4, %esp)
+        mov     $bootsym_rel(wakeup_stack, 4, %esp)
=20
         # check saved magic again
         mov     $sym_phys(saved_magic), %eax
@@ -188,3 +188,7 @@ ret_point:
 bogus_saved_magic:
         movw    $0x0e00 + 'S', 0xb8014
         jmp     bogus_saved_magic
+
+        .align  16
+        .fill   PAGE_SIZE,1,0
+wakeup_stack:



--=__Part0729905A.0__=
Content-Type: text/plain; name="x86-boot-trampoline-remove.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-boot-trampoline-remove.patch"

x86: get rid of BOOT_TRAMPOLINE=0A=0AWe recently saw a machine that has =
the EBDA extending as low as 0x7c000,=0Aso that Xen fails to boot after =
relocating the trampoline.  To fix this,=0AI removed BOOT_TRAMPOLINE and =
bootsym_phys completely.=0A=0AHere are the parts:=0A=0A1) the trampoline =
segment is set to 64k below the EBDA.  head.S grows=0Athe ability to =
relocate the trampoline segment=0A=0A2) reloc.c is made position-independen=
t.  It allocates data below the=0Atrampoline, whose address is passed in =
_eax.=0A=0A3) cmdline.S is called before relocating, so all bootsym_phys =
there=0Abecome sym_phys.=0A=0ASigned-off-by: Paolo Bonzini <pbonzini@redhat=
.com>=0A=0Ajb: - fall back to low memory size (instead of segment 0x7c00) =
if EBDA=0A      value is out of range=0A    - also add upper limit check =
on EBDA value=0A    - fix and simplify inline assembly operands in =
reloc_mbi_struct()=0A    - use lret instead of retf=0A    - renamed =
early_stack to wakeup_stack, defined and used now only=0A      in =
wakeup.S=0A    - aligned reloc.bin's end of .text to 16 bytes, so that =
checking=0A      __bss_start =3D=3D end works reliably=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/boot/Makefile=0A+++=
 b/xen/arch/x86/boot/Makefile=0A@@ -2,8 +2,7 @@ obj-bin-y +=3D head.o=0A =
=0A head.o: reloc.S=0A =0A-BOOT_TRAMPOLINE :=3D $(shell sed -n 's,^\#define=
[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\},,p' head.S)=0A %.S: =
%.c=0A-	RELOC=3D$(BOOT_TRAMPOLINE) $(MAKE) -f build32.mk $@=0A+	$(MAKE) -f =
build32.mk $@=0A =0A reloc.S: head.S=0A--- a/xen/arch/x86/boot/build32.mk=
=0A+++ b/xen/arch/x86/boot/build32.mk=0A@@ -16,9 +16,10 @@ CFLAGS :=3D =
$(filter-out -flto,$(CFLAGS)) =0A 	$(OBJCOPY) -O binary $< $@=0A =0A =
%.lnk: %.o=0A-	$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(RELOC) -o $@ $<=0A+	=
$(LD) $(LDFLAGS_DIRECT) -N -Ttext 0 -o $@ $<=0A =0A %.o: %.c=0A-	=
$(CC) $(CFLAGS) -c $< -o $@=0A+	$(CC) $(CFLAGS) -c -fpic $< -o $@=0A =0A =
reloc.o: $(BASEDIR)/include/asm-x86/config.h=0A+.PRECIOUS: %.bin %.lnk=0A--=
- a/xen/arch/x86/boot/cmdline.S=0A+++ b/xen/arch/x86/boot/cmdline.S=0A@@ =
-164,13 +164,13 @@ cmdline_parse_early:=0A         pushl   MB_cmdline(%ebx)=
=0A         call    .Lfind_option=0A         test    %eax,%eax=0A-        =
setnz   bootsym_phys(skip_realmode)=0A+        setnz   sym_phys(skip_realmo=
de)=0A =0A         /* Check for 'tboot=3D' command-line option. */=0A      =
   movl    $sym_phys(.Ltboot_opt),4(%esp)=0A         call    .Lfind_option=
=0A         test    %eax,%eax=0A-        setnz   bootsym_phys(skip_realmode=
) /* tboot=3D implies no-real-mode */=0A+        setnz   sym_phys(skip_real=
mode) /* tboot=3D implies no-real-mode */=0A =0A .Lparse_edd:=0A         =
/* Check for 'edd=3D' command-line option. */=0A@@ -181,13 +181,13 @@ =
cmdline_parse_early:=0A         cmpb    $'=3D',3(%eax)=0A         jne     =
.Lparse_edid=0A         add     $4,%eax=0A-        movb    $2,bootsym_phys(=
opt_edd)  /* opt_edd=3D2: edd=3Doff */=0A+        movb    $2,sym_phys(opt_e=
dd)  /* opt_edd=3D2: edd=3Doff */=0A         cmpw    $0x666f,(%eax)        =
    /* 0x666f =3D=3D "of" */=0A         je      .Lparse_edid=0A-        =
decb    bootsym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr */=0A+     =
   decb    sym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr */=0A       =
  cmpw    $0x6b73,(%eax)            /* 0x6b73 =3D=3D "sk" */=0A         je =
     .Lparse_edid=0A-        decb    bootsym_phys(opt_edd)     /* =
opt_edd=3D0: edd=3Don (default) */=0A+        decb    sym_phys(opt_edd)    =
 /* opt_edd=3D0: edd=3Don (default) */=0A =0A .Lparse_edid:=0A         /* =
Check for 'edid=3D' command-line option. */=0A@@ -203,17 +203,17 @@ =
cmdline_parse_early:=0A         pushl   $sym_phys(.Ledid_force)=0A         =
call    .Lstr_prefix=0A         add     $8,%esp=0A-        movb    =
$2,bootsym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce */=0A+        movb =
   $2,sym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce */=0A         test  =
  %eax,%eax=0A         jz      .Lparse_vga=0A         push    %ebx=0A      =
   pushl   $sym_phys(.Ledid_no)=0A         call    .Lstr_prefix=0A         =
add     $8,%esp=0A-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D=
1: edid=3Dno */=0A+        decb    sym_phys(opt_edid)    /* opt_edid=3D1: =
edid=3Dno */=0A         test    %eax,%eax=0A         jz      .Lparse_vga=0A=
-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D0: default */=0A+ =
       decb    sym_phys(opt_edid)    /* opt_edid=3D0: default */=0A =0A =
.Lparse_vga:=0A         /* Check for 'vga=3D' command-line option. */=0A@@ =
-227,7 +227,7 @@ cmdline_parse_early:=0A         add     $4,%eax=0A =0A    =
     /* Found the 'vga=3D' option. Default option is to display vga menu. =
*/=0A-        movw    $ASK_VGA,bootsym_phys(boot_vid_mode)=0A+        movw =
   $ASK_VGA,sym_phys(boot_vid_mode)=0A =0A         /* Check for 'vga=3Dtext=
-80x<rows>. */=0A         mov     %eax,%ebx=0A@@ -251,7 +251,7 @@ =
cmdline_parse_early:=0A         cmp     %ax,%bx=0A         lodsw=0A        =
 jne     1b=0A-        mov     %ax,bootsym_phys(boot_vid_mode)=0A+        =
mov     %ax,sym_phys(boot_vid_mode)=0A         jmp     .Lcmdline_exit=0A =
=0A .Lparse_vga_gfx:=0A@@ -270,7 +270,7 @@ cmdline_parse_early:=0A         =
push    %ebx=0A         call    .Latoi=0A         pop     %esi=0A-        =
mov     %ax,bootsym_phys(vesa_size)+0=0A+        mov     %ax,sym_phys(vesa_=
size)+0=0A         /* skip 'x' */=0A         lodsb=0A         cmpb    =
$'x',%al=0A@@ -279,7 +279,7 @@ cmdline_parse_early:=0A         push    =
%esi=0A         call    .Latoi=0A         pop     %esi=0A-        mov     =
%ax,bootsym_phys(vesa_size)+2=0A+        mov     %ax,sym_phys(vesa_size)+2=
=0A         /* skip 'x' */=0A         lodsb=0A         cmpb    $'x',%al=0A@=
@ -288,9 +288,9 @@ cmdline_parse_early:=0A         push    %esi=0A         =
call    .Latoi=0A         pop     %esi=0A-        mov     %ax,bootsym_phys(=
vesa_size)+4=0A+        mov     %ax,sym_phys(vesa_size)+4=0A         /* =
commit to vesa mode */=0A-        movw    $VIDEO_VESA_BY_SIZE,bootsym_phys(=
boot_vid_mode)=0A+        movw    $VIDEO_VESA_BY_SIZE,sym_phys(boot_vid_mod=
e)=0A         jmp     .Lcmdline_exit=0A =0A .Lparse_vga_mode:=0A@@ -307,7 =
+307,7 @@ cmdline_parse_early:=0A         push    %ebx=0A         call    =
.Latoi=0A         add     $4,%esp=0A-        mov     %ax,bootsym_phys(boot_=
vid_mode)=0A+        mov     %ax,sym_phys(boot_vid_mode)=0A         jmp    =
 .Lcmdline_exit=0A =0A .Lparse_vga_current:=0A@@ -320,7 +320,7 @@ =
cmdline_parse_early:=0A         jnz     .Lcmdline_exit=0A =0A         /* =
We have 'vga=3Dcurrent'. */=0A-        movw    $VIDEO_CURRENT_MODE,bootsym_=
phys(boot_vid_mode)=0A+        movw    $VIDEO_CURRENT_MODE,sym_phys(boot_vi=
d_mode)=0A =0A .Lcmdline_exit:=0A         popa=0A--- a/xen/arch/x86/boot/he=
ad.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ -9,9 +9,7 @@=0A         =
.text=0A         .code32=0A =0A-#define BOOT_TRAMPOLINE   0x7c000=0A =
#define sym_phys(sym)     ((sym) - __XEN_VIRT_START)=0A-#define bootsym_phy=
s(sym) ((sym) - trampoline_start + BOOT_TRAMPOLINE)=0A =0A #define =
BOOT_CS32        0x0008=0A #define BOOT_CS64        0x0010=0A@@ -79,6 =
+77,23 @@ __start:=0A         cmp     $0x2BADB002,%eax=0A         jne     =
not_multiboot=0A =0A+        /* Set up trampoline segment 64k below EBDA =
*/=0A+        movzwl  0x40e,%eax          /* EBDA segment */=0A+        =
cmp     $0xa000,%eax        /* sanity check (high) */=0A+        jae     =
0f=0A+        cmp     $0x4000,%eax        /* sanity check (low) */=0A+     =
   jae     1f=0A+0:=0A+        movzwl  0x413,%eax          /* use base =
memory size on failure */=0A+        shl     $10-4,%eax=0A+1:=0A+        =
sub     $0x1000,%eax=0A+=0A+        /* From arch/x86/smpboot.c: start_eip =
had better be page-aligned! */=0A+        xor     %al, %al=0A+        shl  =
   $4, %eax=0A+        mov     %eax,sym_phys(trampoline_phys)=0A+=0A       =
  /* Save the Multiboot info struct (after relocation) for later use. =
*/=0A         mov     $sym_phys(cpu0_stack)+1024,%esp=0A         push    =
%ebx=0A@@ -190,7 +205,7 @@ __start:=0A #endif=0A =0A         /* Apply =
relocations to bootstrap trampoline. */=0A-        mov     $BOOT_TRAMPOLINE=
,%edx=0A+        mov     sym_phys(trampoline_phys),%edx=0A         mov     =
$sym_phys(__trampoline_rel_start),%edi=0A         mov     %edx,sym_phys(tra=
mpoline_phys)=0A 1:=0A@@ -200,22 +215,35 @@ __start:=0A         cmp     =
$sym_phys(__trampoline_rel_stop),%edi=0A         jb      1b=0A =0A+        =
/* Patch in the trampoline segment. */=0A+        shr     $4,%edx=0A+      =
  mov     $sym_phys(__trampoline_seg_start),%edi=0A+1:=0A+        mov     =
(%edi),%eax=0A+        mov     %dx,(%edi,%eax)=0A+        add     =
$4,%edi=0A+        cmp     $sym_phys(__trampoline_seg_stop),%edi=0A+       =
 jb      1b=0A+=0A+        call    cmdline_parse_early=0A+=0A+        /* =
Switch to low-memory stack.  */=0A+        mov     sym_phys(trampoline_phys=
),%edi=0A+        lea     0x10000(%edi),%esp=0A+        lea     trampoline_=
boot_cpu_entry-trampoline_start(%edi),%eax=0A+        pushl   $BOOT_CS32=0A=
+        push    %eax=0A+=0A         /* Copy bootstrap trampoline to low =
memory, below 1MB. */=0A         mov     $sym_phys(trampoline_start),%esi=
=0A-        mov     %edx,%edi=0A         mov     $trampoline_end - =
trampoline_start,%ecx=0A         rep     movsb=0A =0A-        lea     =
early_stack-trampoline_start(%edx),%esp=0A-        call    cmdline_parse_ea=
rly=0A-=0A         /* Jump into the relocated trampoline. */=0A-        =
jmp     $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry)=0A+        =
lret=0A =0A #include "cmdline.S"=0A =0A-#undef bootsym_phys=0A-=0A =
reloc:=0A #include "reloc.S"=0A =0A--- a/xen/arch/x86/boot/reloc.c=0A+++ =
b/xen/arch/x86/boot/reloc.c=0A@@ -10,42 +10,49 @@=0A  *    Keir Fraser =
<keir@xen.org>=0A  */=0A =0A+/* entered with %eax =3D BOOT_TRAMPOLINE =
*/=0A asm (=0A     "    .text                         \n"=0A     "    =
.globl _start                 \n"=0A     "_start:                          =
 \n"=0A-    "    mov  $_start,%edi             \n"=0A     "    call 1f     =
                  \n"=0A-    "1:  pop  %esi                     \n"=0A-    =
"    sub  $1b-_start,%esi          \n"=0A-    "    mov  $__bss_start-_start=
,%ecx \n"=0A-    "    rep  movsb                    \n"=0A-    "    xor  =
%eax,%eax                \n"=0A-    "    mov  $_end,%ecx               =
\n"=0A-    "    sub  %edi,%ecx                \n"=0A-    "    rep  stosb   =
                 \n"=0A-    "    mov  $reloc,%eax              \n"=0A-    =
"    jmp  *%eax                    \n"=0A+    "1:  pop  %ebx               =
      \n"=0A+    "    mov  %eax,alloc-1b(%ebx)      \n"=0A+    "    mov  =
$_end,%ecx               \n"  /* check that BSS is empty! */=0A+    "    =
sub  $__bss_start,%ecx        \n"=0A+    "    jz reloc                     =
 \n"=0A+    "1:  jmp 1b                        \n"=0A+    );=0A+=0A+/* =
This is our data.  Because the code must be relocatable, no BSS is=0A+ * =
allowed.  All data is accessed PC-relative with inline assembly.=0A+ =
*/=0A+asm (=0A+    "alloc:                            \n"=0A+    "    =
.long 0                       \n"=0A+    "    .subsection 1                =
 \n"=0A+    "    .p2align 4, 0xcc              \n"=0A+    "    .subsection =
0                 \n"=0A     );=0A =0A typedef unsigned int u32;=0A =
#include "../../../include/xen/multiboot.h"=0A =0A-extern char _start[];=0A=
-=0A-static void *memcpy(void *dest, const void *src, unsigned int =
n)=0A-{=0A-    char *s =3D (char *)src, *d =3D dest;=0A-    while ( n-- =
)=0A-        *d++ =3D *s++;=0A-    return dest;=0A-}=0A-=0A static void =
*reloc_mbi_struct(void *old, unsigned int bytes)=0A {=0A-    static void =
*alloc =3D &_start;=0A-    alloc =3D (void *)(((unsigned long)alloc - =
bytes) & ~15ul);=0A-    return memcpy(alloc, old, bytes);=0A+    void =
*new;=0A+    asm(=0A+    "    call 1f                      \n"=0A+    "1:  =
pop  %%edx                   \n"=0A+    "    mov  alloc-1b(%%edx),%0      =
\n"=0A+    "    sub  %1,%0                   \n"=0A+    "    and  $~15,%0  =
               \n"=0A+    "    mov  %0,alloc-1b(%%edx)      \n"=0A+    "   =
 mov  %0,%%edi                \n"=0A+    "    rep  movsb                   =
\n"=0A+       : "=3D&r" (new), "+c" (bytes), "+S" (old)=0A+	: : "edx", =
"edi");=0A+    return new;=0A }=0A =0A static char *reloc_mbi_string(char =
*old)=0A--- a/xen/arch/x86/boot/trampoline.S=0A+++ b/xen/arch/x86/boot/tram=
poline.S=0A@@ -11,6 +11,13 @@=0A         .long 111b - (off) - .;           =
 \=0A         .popsection=0A =0A+#define bootsym_segrel(sym, off)          =
 \=0A+        $0,$bootsym(sym);                  \=0A+111:;                =
                      \=0A+        .pushsection .trampoline_seg, "a"; =
\=0A+        .long 111b - (off) - .;            \=0A+        .popsection=0A=
+=0A         .globl trampoline_realmode_entry=0A trampoline_realmode_entry:=
=0A         mov     %cs,%ax=0A@@ -151,14 +158,14 @@ trampoline_boot_cpu_ent=
ry:=0A 1:      mov     %eax,%cr0                 # CR0.PE =3D 0 (leave =
protected mode)=0A =0A         /* Load proper real-mode values into %cs, =
%ds, %es and %ss. */=0A-        ljmp    $(BOOT_TRAMPOLINE>>4),$bootsym(1f)=
=0A+        ljmp    bootsym_segrel(1f,2)=0A 1:      mov     %cs,%ax=0A     =
    mov     %ax,%ds=0A         mov     %ax,%es=0A         mov     =
%ax,%ss=0A =0A         /* Initialise stack pointer and IDT, and enable =
irqs. */=0A-        mov     $bootsym(early_stack),%sp=0A+        xor     =
%sp,%sp=0A         lidt    bootsym(rm_idt)=0A         sti=0A =0A@@ -220,7 =
+227,3 @@ rm_idt: .word   256*4-1, 0, 0=0A #include "edd.S"=0A #include =
"video.S"=0A #include "wakeup.S"=0A-=0A-        .align  16=0A-        =
.fill   PAGE_SIZE,1,0=0A-early_stack:=0A--- a/xen/arch/x86/boot/wakeup.S=0A=
+++ b/xen/arch/x86/boot/wakeup.S=0A@@ -11,7 +11,7 @@ ENTRY(wakeup_start)=0A=
         movw    %cs, %ax=0A         movw    %ax, %ds=0A         movw    =
%ax, %ss        # A stack required for BIOS call=0A-        movw    =
$wakesym(early_stack), %sp=0A+        movw    $wakesym(wakeup_stack), =
%sp=0A =0A         pushl   $0              # Kill dangerous flag early=0A  =
       popfl=0A@@ -101,7 +101,7 @@ real_magic:     .long 0x12345678=0A     =
     .globl video_mode, video_flags=0A video_mode:     .long 0=0A =
video_flags:    .long 0=0A-trampoline_seg: .word BOOT_TRAMPOLINE >> =
4=0A+trampoline_seg: .word 0=0A         .pushsection .trampoline_seg, =
"a"=0A         .long   trampoline_seg - .=0A         .popsection=0A@@ =
-116,7 +116,7 @@ wakeup_32:=0A         mov     $BOOT_DS, %eax=0A         =
mov     %eax, %ds=0A         mov     %eax, %ss=0A-        mov     =
$bootsym_rel(early_stack, 4, %esp)=0A+        mov     $bootsym_rel(wakeup_s=
tack, 4, %esp)=0A =0A         # check saved magic again=0A         mov     =
$sym_phys(saved_magic), %eax=0A@@ -188,3 +188,7 @@ ret_point:=0A bogus_save=
d_magic:=0A         movw    $0x0e00 + 'S', 0xb8014=0A         jmp     =
bogus_saved_magic=0A+=0A+        .align  16=0A+        .fill   PAGE_SIZE,1,=
0=0A+wakeup_stack:=0A
--=__Part0729905A.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

--=__Part0729905A.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 11 08:42:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 08: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 1Se0C9-0001BI-K6; Mon, 11 Jun 2012 08:41: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 1Se0C7-0001B8-Ki
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 08:41:52 +0000
Received: from [85.158.143.99:18033] by server-3.bemta-4.messagelabs.com id
	76/9A-05808-E4FA5DF4; Mon, 11 Jun 2012 08:41:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339404109!29886514!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5561 invoked from network); 11 Jun 2012 08:41:50 -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; 11 Jun 2012 08:41:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 09:41:49 +0100
Message-Id: <4FD5CB6A02000078000892D0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 09:41:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0729905A.0__="
Cc: Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH] x86: get rid of BOOT_TRAMPOLINE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part0729905A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We recently saw a machine that has the EBDA extending as low as 0x7c000,
so that Xen fails to boot after relocating the trampoline.  To fix this,
I removed BOOT_TRAMPOLINE and bootsym_phys completely.

Here are the parts:

1) the trampoline segment is set to 64k below the EBDA.  head.S grows
the ability to relocate the trampoline segment

2) reloc.c is made position-independent.  It allocates data below the
trampoline, whose address is passed in _eax.

3) cmdline.S is called before relocating, so all bootsym_phys there
become sym_phys.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

jb: - fall back to low memory size (instead of segment 0x7c00) if EBDA
      value is out of range
    - also add upper limit check on EBDA value
    - fix and simplify inline assembly operands in reloc_mbi_struct()
    - use lret instead of retf
    - renamed early_stack to wakeup_stack, defined and used now only
      in wakeup.S
    - aligned reloc.bin's end of .text to 16 bytes, so that checking
      __bss_start =3D=3D end works reliably

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -2,8 +2,7 @@ obj-bin-y +=3D head.o
=20
 head.o: reloc.S
=20
-BOOT_TRAMPOLINE :=3D $(shell sed -n 's,^\#define[[:space:]]\{1\,\}BOOT_TRA=
MPOLINE[[:space:]]\{1\,\},,p' head.S)
 %.S: %.c
-	RELOC=3D$(BOOT_TRAMPOLINE) $(MAKE) -f build32.mk $@
+	$(MAKE) -f build32.mk $@
=20
 reloc.S: head.S
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -16,9 +16,10 @@ CFLAGS :=3D $(filter-out -flto,$(CFLAGS))=20
 	$(OBJCOPY) -O binary $< $@
=20
 %.lnk: %.o
-	$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(RELOC) -o $@ $<
+	$(LD) $(LDFLAGS_DIRECT) -N -Ttext 0 -o $@ $<
=20
 %.o: %.c
-	$(CC) $(CFLAGS) -c $< -o $@
+	$(CC) $(CFLAGS) -c -fpic $< -o $@
=20
 reloc.o: $(BASEDIR)/include/asm-x86/config.h
+.PRECIOUS: %.bin %.lnk
--- a/xen/arch/x86/boot/cmdline.S
+++ b/xen/arch/x86/boot/cmdline.S
@@ -164,13 +164,13 @@ cmdline_parse_early:
         pushl   MB_cmdline(%ebx)
         call    .Lfind_option
         test    %eax,%eax
-        setnz   bootsym_phys(skip_realmode)
+        setnz   sym_phys(skip_realmode)
=20
         /* Check for 'tboot=3D' command-line option. */
         movl    $sym_phys(.Ltboot_opt),4(%esp)
         call    .Lfind_option
         test    %eax,%eax
-        setnz   bootsym_phys(skip_realmode) /* tboot=3D implies no-real-mo=
de */
+        setnz   sym_phys(skip_realmode) /* tboot=3D implies no-real-mode =
*/
=20
 .Lparse_edd:
         /* Check for 'edd=3D' command-line option. */
@@ -181,13 +181,13 @@ cmdline_parse_early:
         cmpb    $'=3D',3(%eax)
         jne     .Lparse_edid
         add     $4,%eax
-        movb    $2,bootsym_phys(opt_edd)  /* opt_edd=3D2: edd=3Doff */
+        movb    $2,sym_phys(opt_edd)  /* opt_edd=3D2: edd=3Doff */
         cmpw    $0x666f,(%eax)            /* 0x666f =3D=3D "of" */
         je      .Lparse_edid
-        decb    bootsym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr =
*/
+        decb    sym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr */
         cmpw    $0x6b73,(%eax)            /* 0x6b73 =3D=3D "sk" */
         je      .Lparse_edid
-        decb    bootsym_phys(opt_edd)     /* opt_edd=3D0: edd=3Don =
(default) */
+        decb    sym_phys(opt_edd)     /* opt_edd=3D0: edd=3Don (default) =
*/
=20
 .Lparse_edid:
         /* Check for 'edid=3D' command-line option. */
@@ -203,17 +203,17 @@ cmdline_parse_early:
         pushl   $sym_phys(.Ledid_force)
         call    .Lstr_prefix
         add     $8,%esp
-        movb    $2,bootsym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce =
*/
+        movb    $2,sym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce */
         test    %eax,%eax
         jz      .Lparse_vga
         push    %ebx
         pushl   $sym_phys(.Ledid_no)
         call    .Lstr_prefix
         add     $8,%esp
-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D1: edid=3Dno */
+        decb    sym_phys(opt_edid)    /* opt_edid=3D1: edid=3Dno */
         test    %eax,%eax
         jz      .Lparse_vga
-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D0: default */
+        decb    sym_phys(opt_edid)    /* opt_edid=3D0: default */
=20
 .Lparse_vga:
         /* Check for 'vga=3D' command-line option. */
@@ -227,7 +227,7 @@ cmdline_parse_early:
         add     $4,%eax
=20
         /* Found the 'vga=3D' option. Default option is to display vga =
menu. */
-        movw    $ASK_VGA,bootsym_phys(boot_vid_mode)
+        movw    $ASK_VGA,sym_phys(boot_vid_mode)
=20
         /* Check for 'vga=3Dtext-80x<rows>. */
         mov     %eax,%ebx
@@ -251,7 +251,7 @@ cmdline_parse_early:
         cmp     %ax,%bx
         lodsw
         jne     1b
-        mov     %ax,bootsym_phys(boot_vid_mode)
+        mov     %ax,sym_phys(boot_vid_mode)
         jmp     .Lcmdline_exit
=20
 .Lparse_vga_gfx:
@@ -270,7 +270,7 @@ cmdline_parse_early:
         push    %ebx
         call    .Latoi
         pop     %esi
-        mov     %ax,bootsym_phys(vesa_size)+0
+        mov     %ax,sym_phys(vesa_size)+0
         /* skip 'x' */
         lodsb
         cmpb    $'x',%al
@@ -279,7 +279,7 @@ cmdline_parse_early:
         push    %esi
         call    .Latoi
         pop     %esi
-        mov     %ax,bootsym_phys(vesa_size)+2
+        mov     %ax,sym_phys(vesa_size)+2
         /* skip 'x' */
         lodsb
         cmpb    $'x',%al
@@ -288,9 +288,9 @@ cmdline_parse_early:
         push    %esi
         call    .Latoi
         pop     %esi
-        mov     %ax,bootsym_phys(vesa_size)+4
+        mov     %ax,sym_phys(vesa_size)+4
         /* commit to vesa mode */
-        movw    $VIDEO_VESA_BY_SIZE,bootsym_phys(boot_vid_mode)
+        movw    $VIDEO_VESA_BY_SIZE,sym_phys(boot_vid_mode)
         jmp     .Lcmdline_exit
=20
 .Lparse_vga_mode:
@@ -307,7 +307,7 @@ cmdline_parse_early:
         push    %ebx
         call    .Latoi
         add     $4,%esp
-        mov     %ax,bootsym_phys(boot_vid_mode)
+        mov     %ax,sym_phys(boot_vid_mode)
         jmp     .Lcmdline_exit
=20
 .Lparse_vga_current:
@@ -320,7 +320,7 @@ cmdline_parse_early:
         jnz     .Lcmdline_exit
=20
         /* We have 'vga=3Dcurrent'. */
-        movw    $VIDEO_CURRENT_MODE,bootsym_phys(boot_vid_mode)
+        movw    $VIDEO_CURRENT_MODE,sym_phys(boot_vid_mode)
=20
 .Lcmdline_exit:
         popa
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -9,9 +9,7 @@
         .text
         .code32
=20
-#define BOOT_TRAMPOLINE   0x7c000
 #define sym_phys(sym)     ((sym) - __XEN_VIRT_START)
-#define bootsym_phys(sym) ((sym) - trampoline_start + BOOT_TRAMPOLINE)
=20
 #define BOOT_CS32        0x0008
 #define BOOT_CS64        0x0010
@@ -79,6 +77,23 @@ __start:
         cmp     $0x2BADB002,%eax
         jne     not_multiboot
=20
+        /* Set up trampoline segment 64k below EBDA */
+        movzwl  0x40e,%eax          /* EBDA segment */
+        cmp     $0xa000,%eax        /* sanity check (high) */
+        jae     0f
+        cmp     $0x4000,%eax        /* sanity check (low) */
+        jae     1f
+0:
+        movzwl  0x413,%eax          /* use base memory size on failure */
+        shl     $10-4,%eax
+1:
+        sub     $0x1000,%eax
+
+        /* From arch/x86/smpboot.c: start_eip had better be page-aligned! =
*/
+        xor     %al, %al
+        shl     $4, %eax
+        mov     %eax,sym_phys(trampoline_phys)
+
         /* Save the Multiboot info struct (after relocation) for later =
use. */
         mov     $sym_phys(cpu0_stack)+1024,%esp
         push    %ebx
@@ -190,7 +205,7 @@ __start:
 #endif
=20
         /* Apply relocations to bootstrap trampoline. */
-        mov     $BOOT_TRAMPOLINE,%edx
+        mov     sym_phys(trampoline_phys),%edx
         mov     $sym_phys(__trampoline_rel_start),%edi
         mov     %edx,sym_phys(trampoline_phys)
 1:
@@ -200,22 +215,35 @@ __start:
         cmp     $sym_phys(__trampoline_rel_stop),%edi
         jb      1b
=20
+        /* Patch in the trampoline segment. */
+        shr     $4,%edx
+        mov     $sym_phys(__trampoline_seg_start),%edi
+1:
+        mov     (%edi),%eax
+        mov     %dx,(%edi,%eax)
+        add     $4,%edi
+        cmp     $sym_phys(__trampoline_seg_stop),%edi
+        jb      1b
+
+        call    cmdline_parse_early
+
+        /* Switch to low-memory stack.  */
+        mov     sym_phys(trampoline_phys),%edi
+        lea     0x10000(%edi),%esp
+        lea     trampoline_boot_cpu_entry-trampoline_start(%edi),%eax
+        pushl   $BOOT_CS32
+        push    %eax
+
         /* Copy bootstrap trampoline to low memory, below 1MB. */
         mov     $sym_phys(trampoline_start),%esi
-        mov     %edx,%edi
         mov     $trampoline_end - trampoline_start,%ecx
         rep     movsb
=20
-        lea     early_stack-trampoline_start(%edx),%esp
-        call    cmdline_parse_early
-
         /* Jump into the relocated trampoline. */
-        jmp     $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry)
+        lret
=20
 #include "cmdline.S"
=20
-#undef bootsym_phys
-
 reloc:
 #include "reloc.S"
=20
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -10,42 +10,49 @@
  *    Keir Fraser <keir@xen.org>
  */
=20
+/* entered with %eax =3D BOOT_TRAMPOLINE */
 asm (
     "    .text                         \n"
     "    .globl _start                 \n"
     "_start:                           \n"
-    "    mov  $_start,%edi             \n"
     "    call 1f                       \n"
-    "1:  pop  %esi                     \n"
-    "    sub  $1b-_start,%esi          \n"
-    "    mov  $__bss_start-_start,%ecx \n"
-    "    rep  movsb                    \n"
-    "    xor  %eax,%eax                \n"
-    "    mov  $_end,%ecx               \n"
-    "    sub  %edi,%ecx                \n"
-    "    rep  stosb                    \n"
-    "    mov  $reloc,%eax              \n"
-    "    jmp  *%eax                    \n"
+    "1:  pop  %ebx                     \n"
+    "    mov  %eax,alloc-1b(%ebx)      \n"
+    "    mov  $_end,%ecx               \n"  /* check that BSS is empty! =
*/
+    "    sub  $__bss_start,%ecx        \n"
+    "    jz reloc                      \n"
+    "1:  jmp 1b                        \n"
+    );
+
+/* This is our data.  Because the code must be relocatable, no BSS is
+ * allowed.  All data is accessed PC-relative with inline assembly.
+ */
+asm (
+    "alloc:                            \n"
+    "    .long 0                       \n"
+    "    .subsection 1                 \n"
+    "    .p2align 4, 0xcc              \n"
+    "    .subsection 0                 \n"
     );
=20
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
=20
-extern char _start[];
-
-static void *memcpy(void *dest, const void *src, unsigned int n)
-{
-    char *s =3D (char *)src, *d =3D dest;
-    while ( n-- )
-        *d++ =3D *s++;
-    return dest;
-}
-
 static void *reloc_mbi_struct(void *old, unsigned int bytes)
 {
-    static void *alloc =3D &_start;
-    alloc =3D (void *)(((unsigned long)alloc - bytes) & ~15ul);
-    return memcpy(alloc, old, bytes);
+    void *new;
+    asm(
+    "    call 1f                      \n"
+    "1:  pop  %%edx                   \n"
+    "    mov  alloc-1b(%%edx),%0      \n"
+    "    sub  %1,%0                   \n"
+    "    and  $~15,%0                 \n"
+    "    mov  %0,alloc-1b(%%edx)      \n"
+    "    mov  %0,%%edi                \n"
+    "    rep  movsb                   \n"
+       : "=3D&r" (new), "+c" (bytes), "+S" (old)
+	: : "edx", "edi");
+    return new;
 }
=20
 static char *reloc_mbi_string(char *old)
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -11,6 +11,13 @@
         .long 111b - (off) - .;            \
         .popsection
=20
+#define bootsym_segrel(sym, off)           \
+        $0,$bootsym(sym);                  \
+111:;                                      \
+        .pushsection .trampoline_seg, "a"; \
+        .long 111b - (off) - .;            \
+        .popsection
+
         .globl trampoline_realmode_entry
 trampoline_realmode_entry:
         mov     %cs,%ax
@@ -151,14 +158,14 @@ trampoline_boot_cpu_entry:
 1:      mov     %eax,%cr0                 # CR0.PE =3D 0 (leave protected =
mode)
=20
         /* Load proper real-mode values into %cs, %ds, %es and %ss. */
-        ljmp    $(BOOT_TRAMPOLINE>>4),$bootsym(1f)
+        ljmp    bootsym_segrel(1f,2)
 1:      mov     %cs,%ax
         mov     %ax,%ds
         mov     %ax,%es
         mov     %ax,%ss
=20
         /* Initialise stack pointer and IDT, and enable irqs. */
-        mov     $bootsym(early_stack),%sp
+        xor     %sp,%sp
         lidt    bootsym(rm_idt)
         sti
=20
@@ -220,7 +227,3 @@ rm_idt: .word   256*4-1, 0, 0
 #include "edd.S"
 #include "video.S"
 #include "wakeup.S"
-
-        .align  16
-        .fill   PAGE_SIZE,1,0
-early_stack:
--- a/xen/arch/x86/boot/wakeup.S
+++ b/xen/arch/x86/boot/wakeup.S
@@ -11,7 +11,7 @@ ENTRY(wakeup_start)
         movw    %cs, %ax
         movw    %ax, %ds
         movw    %ax, %ss        # A stack required for BIOS call
-        movw    $wakesym(early_stack), %sp
+        movw    $wakesym(wakeup_stack), %sp
=20
         pushl   $0              # Kill dangerous flag early
         popfl
@@ -101,7 +101,7 @@ real_magic:     .long 0x12345678
          .globl video_mode, video_flags
 video_mode:     .long 0
 video_flags:    .long 0
-trampoline_seg: .word BOOT_TRAMPOLINE >> 4
+trampoline_seg: .word 0
         .pushsection .trampoline_seg, "a"
         .long   trampoline_seg - .
         .popsection
@@ -116,7 +116,7 @@ wakeup_32:
         mov     $BOOT_DS, %eax
         mov     %eax, %ds
         mov     %eax, %ss
-        mov     $bootsym_rel(early_stack, 4, %esp)
+        mov     $bootsym_rel(wakeup_stack, 4, %esp)
=20
         # check saved magic again
         mov     $sym_phys(saved_magic), %eax
@@ -188,3 +188,7 @@ ret_point:
 bogus_saved_magic:
         movw    $0x0e00 + 'S', 0xb8014
         jmp     bogus_saved_magic
+
+        .align  16
+        .fill   PAGE_SIZE,1,0
+wakeup_stack:



--=__Part0729905A.0__=
Content-Type: text/plain; name="x86-boot-trampoline-remove.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-boot-trampoline-remove.patch"

x86: get rid of BOOT_TRAMPOLINE=0A=0AWe recently saw a machine that has =
the EBDA extending as low as 0x7c000,=0Aso that Xen fails to boot after =
relocating the trampoline.  To fix this,=0AI removed BOOT_TRAMPOLINE and =
bootsym_phys completely.=0A=0AHere are the parts:=0A=0A1) the trampoline =
segment is set to 64k below the EBDA.  head.S grows=0Athe ability to =
relocate the trampoline segment=0A=0A2) reloc.c is made position-independen=
t.  It allocates data below the=0Atrampoline, whose address is passed in =
_eax.=0A=0A3) cmdline.S is called before relocating, so all bootsym_phys =
there=0Abecome sym_phys.=0A=0ASigned-off-by: Paolo Bonzini <pbonzini@redhat=
.com>=0A=0Ajb: - fall back to low memory size (instead of segment 0x7c00) =
if EBDA=0A      value is out of range=0A    - also add upper limit check =
on EBDA value=0A    - fix and simplify inline assembly operands in =
reloc_mbi_struct()=0A    - use lret instead of retf=0A    - renamed =
early_stack to wakeup_stack, defined and used now only=0A      in =
wakeup.S=0A    - aligned reloc.bin's end of .text to 16 bytes, so that =
checking=0A      __bss_start =3D=3D end works reliably=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/boot/Makefile=0A+++=
 b/xen/arch/x86/boot/Makefile=0A@@ -2,8 +2,7 @@ obj-bin-y +=3D head.o=0A =
=0A head.o: reloc.S=0A =0A-BOOT_TRAMPOLINE :=3D $(shell sed -n 's,^\#define=
[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\},,p' head.S)=0A %.S: =
%.c=0A-	RELOC=3D$(BOOT_TRAMPOLINE) $(MAKE) -f build32.mk $@=0A+	$(MAKE) -f =
build32.mk $@=0A =0A reloc.S: head.S=0A--- a/xen/arch/x86/boot/build32.mk=
=0A+++ b/xen/arch/x86/boot/build32.mk=0A@@ -16,9 +16,10 @@ CFLAGS :=3D =
$(filter-out -flto,$(CFLAGS)) =0A 	$(OBJCOPY) -O binary $< $@=0A =0A =
%.lnk: %.o=0A-	$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(RELOC) -o $@ $<=0A+	=
$(LD) $(LDFLAGS_DIRECT) -N -Ttext 0 -o $@ $<=0A =0A %.o: %.c=0A-	=
$(CC) $(CFLAGS) -c $< -o $@=0A+	$(CC) $(CFLAGS) -c -fpic $< -o $@=0A =0A =
reloc.o: $(BASEDIR)/include/asm-x86/config.h=0A+.PRECIOUS: %.bin %.lnk=0A--=
- a/xen/arch/x86/boot/cmdline.S=0A+++ b/xen/arch/x86/boot/cmdline.S=0A@@ =
-164,13 +164,13 @@ cmdline_parse_early:=0A         pushl   MB_cmdline(%ebx)=
=0A         call    .Lfind_option=0A         test    %eax,%eax=0A-        =
setnz   bootsym_phys(skip_realmode)=0A+        setnz   sym_phys(skip_realmo=
de)=0A =0A         /* Check for 'tboot=3D' command-line option. */=0A      =
   movl    $sym_phys(.Ltboot_opt),4(%esp)=0A         call    .Lfind_option=
=0A         test    %eax,%eax=0A-        setnz   bootsym_phys(skip_realmode=
) /* tboot=3D implies no-real-mode */=0A+        setnz   sym_phys(skip_real=
mode) /* tboot=3D implies no-real-mode */=0A =0A .Lparse_edd:=0A         =
/* Check for 'edd=3D' command-line option. */=0A@@ -181,13 +181,13 @@ =
cmdline_parse_early:=0A         cmpb    $'=3D',3(%eax)=0A         jne     =
.Lparse_edid=0A         add     $4,%eax=0A-        movb    $2,bootsym_phys(=
opt_edd)  /* opt_edd=3D2: edd=3Doff */=0A+        movb    $2,sym_phys(opt_e=
dd)  /* opt_edd=3D2: edd=3Doff */=0A         cmpw    $0x666f,(%eax)        =
    /* 0x666f =3D=3D "of" */=0A         je      .Lparse_edid=0A-        =
decb    bootsym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr */=0A+     =
   decb    sym_phys(opt_edd)     /* opt_edd=3D1: edd=3Dskipmbr */=0A       =
  cmpw    $0x6b73,(%eax)            /* 0x6b73 =3D=3D "sk" */=0A         je =
     .Lparse_edid=0A-        decb    bootsym_phys(opt_edd)     /* =
opt_edd=3D0: edd=3Don (default) */=0A+        decb    sym_phys(opt_edd)    =
 /* opt_edd=3D0: edd=3Don (default) */=0A =0A .Lparse_edid:=0A         /* =
Check for 'edid=3D' command-line option. */=0A@@ -203,17 +203,17 @@ =
cmdline_parse_early:=0A         pushl   $sym_phys(.Ledid_force)=0A         =
call    .Lstr_prefix=0A         add     $8,%esp=0A-        movb    =
$2,bootsym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce */=0A+        movb =
   $2,sym_phys(opt_edid) /* opt_edid=3D2: edid=3Dforce */=0A         test  =
  %eax,%eax=0A         jz      .Lparse_vga=0A         push    %ebx=0A      =
   pushl   $sym_phys(.Ledid_no)=0A         call    .Lstr_prefix=0A         =
add     $8,%esp=0A-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D=
1: edid=3Dno */=0A+        decb    sym_phys(opt_edid)    /* opt_edid=3D1: =
edid=3Dno */=0A         test    %eax,%eax=0A         jz      .Lparse_vga=0A=
-        decb    bootsym_phys(opt_edid)    /* opt_edid=3D0: default */=0A+ =
       decb    sym_phys(opt_edid)    /* opt_edid=3D0: default */=0A =0A =
.Lparse_vga:=0A         /* Check for 'vga=3D' command-line option. */=0A@@ =
-227,7 +227,7 @@ cmdline_parse_early:=0A         add     $4,%eax=0A =0A    =
     /* Found the 'vga=3D' option. Default option is to display vga menu. =
*/=0A-        movw    $ASK_VGA,bootsym_phys(boot_vid_mode)=0A+        movw =
   $ASK_VGA,sym_phys(boot_vid_mode)=0A =0A         /* Check for 'vga=3Dtext=
-80x<rows>. */=0A         mov     %eax,%ebx=0A@@ -251,7 +251,7 @@ =
cmdline_parse_early:=0A         cmp     %ax,%bx=0A         lodsw=0A        =
 jne     1b=0A-        mov     %ax,bootsym_phys(boot_vid_mode)=0A+        =
mov     %ax,sym_phys(boot_vid_mode)=0A         jmp     .Lcmdline_exit=0A =
=0A .Lparse_vga_gfx:=0A@@ -270,7 +270,7 @@ cmdline_parse_early:=0A         =
push    %ebx=0A         call    .Latoi=0A         pop     %esi=0A-        =
mov     %ax,bootsym_phys(vesa_size)+0=0A+        mov     %ax,sym_phys(vesa_=
size)+0=0A         /* skip 'x' */=0A         lodsb=0A         cmpb    =
$'x',%al=0A@@ -279,7 +279,7 @@ cmdline_parse_early:=0A         push    =
%esi=0A         call    .Latoi=0A         pop     %esi=0A-        mov     =
%ax,bootsym_phys(vesa_size)+2=0A+        mov     %ax,sym_phys(vesa_size)+2=
=0A         /* skip 'x' */=0A         lodsb=0A         cmpb    $'x',%al=0A@=
@ -288,9 +288,9 @@ cmdline_parse_early:=0A         push    %esi=0A         =
call    .Latoi=0A         pop     %esi=0A-        mov     %ax,bootsym_phys(=
vesa_size)+4=0A+        mov     %ax,sym_phys(vesa_size)+4=0A         /* =
commit to vesa mode */=0A-        movw    $VIDEO_VESA_BY_SIZE,bootsym_phys(=
boot_vid_mode)=0A+        movw    $VIDEO_VESA_BY_SIZE,sym_phys(boot_vid_mod=
e)=0A         jmp     .Lcmdline_exit=0A =0A .Lparse_vga_mode:=0A@@ -307,7 =
+307,7 @@ cmdline_parse_early:=0A         push    %ebx=0A         call    =
.Latoi=0A         add     $4,%esp=0A-        mov     %ax,bootsym_phys(boot_=
vid_mode)=0A+        mov     %ax,sym_phys(boot_vid_mode)=0A         jmp    =
 .Lcmdline_exit=0A =0A .Lparse_vga_current:=0A@@ -320,7 +320,7 @@ =
cmdline_parse_early:=0A         jnz     .Lcmdline_exit=0A =0A         /* =
We have 'vga=3Dcurrent'. */=0A-        movw    $VIDEO_CURRENT_MODE,bootsym_=
phys(boot_vid_mode)=0A+        movw    $VIDEO_CURRENT_MODE,sym_phys(boot_vi=
d_mode)=0A =0A .Lcmdline_exit:=0A         popa=0A--- a/xen/arch/x86/boot/he=
ad.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ -9,9 +9,7 @@=0A         =
.text=0A         .code32=0A =0A-#define BOOT_TRAMPOLINE   0x7c000=0A =
#define sym_phys(sym)     ((sym) - __XEN_VIRT_START)=0A-#define bootsym_phy=
s(sym) ((sym) - trampoline_start + BOOT_TRAMPOLINE)=0A =0A #define =
BOOT_CS32        0x0008=0A #define BOOT_CS64        0x0010=0A@@ -79,6 =
+77,23 @@ __start:=0A         cmp     $0x2BADB002,%eax=0A         jne     =
not_multiboot=0A =0A+        /* Set up trampoline segment 64k below EBDA =
*/=0A+        movzwl  0x40e,%eax          /* EBDA segment */=0A+        =
cmp     $0xa000,%eax        /* sanity check (high) */=0A+        jae     =
0f=0A+        cmp     $0x4000,%eax        /* sanity check (low) */=0A+     =
   jae     1f=0A+0:=0A+        movzwl  0x413,%eax          /* use base =
memory size on failure */=0A+        shl     $10-4,%eax=0A+1:=0A+        =
sub     $0x1000,%eax=0A+=0A+        /* From arch/x86/smpboot.c: start_eip =
had better be page-aligned! */=0A+        xor     %al, %al=0A+        shl  =
   $4, %eax=0A+        mov     %eax,sym_phys(trampoline_phys)=0A+=0A       =
  /* Save the Multiboot info struct (after relocation) for later use. =
*/=0A         mov     $sym_phys(cpu0_stack)+1024,%esp=0A         push    =
%ebx=0A@@ -190,7 +205,7 @@ __start:=0A #endif=0A =0A         /* Apply =
relocations to bootstrap trampoline. */=0A-        mov     $BOOT_TRAMPOLINE=
,%edx=0A+        mov     sym_phys(trampoline_phys),%edx=0A         mov     =
$sym_phys(__trampoline_rel_start),%edi=0A         mov     %edx,sym_phys(tra=
mpoline_phys)=0A 1:=0A@@ -200,22 +215,35 @@ __start:=0A         cmp     =
$sym_phys(__trampoline_rel_stop),%edi=0A         jb      1b=0A =0A+        =
/* Patch in the trampoline segment. */=0A+        shr     $4,%edx=0A+      =
  mov     $sym_phys(__trampoline_seg_start),%edi=0A+1:=0A+        mov     =
(%edi),%eax=0A+        mov     %dx,(%edi,%eax)=0A+        add     =
$4,%edi=0A+        cmp     $sym_phys(__trampoline_seg_stop),%edi=0A+       =
 jb      1b=0A+=0A+        call    cmdline_parse_early=0A+=0A+        /* =
Switch to low-memory stack.  */=0A+        mov     sym_phys(trampoline_phys=
),%edi=0A+        lea     0x10000(%edi),%esp=0A+        lea     trampoline_=
boot_cpu_entry-trampoline_start(%edi),%eax=0A+        pushl   $BOOT_CS32=0A=
+        push    %eax=0A+=0A         /* Copy bootstrap trampoline to low =
memory, below 1MB. */=0A         mov     $sym_phys(trampoline_start),%esi=
=0A-        mov     %edx,%edi=0A         mov     $trampoline_end - =
trampoline_start,%ecx=0A         rep     movsb=0A =0A-        lea     =
early_stack-trampoline_start(%edx),%esp=0A-        call    cmdline_parse_ea=
rly=0A-=0A         /* Jump into the relocated trampoline. */=0A-        =
jmp     $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry)=0A+        =
lret=0A =0A #include "cmdline.S"=0A =0A-#undef bootsym_phys=0A-=0A =
reloc:=0A #include "reloc.S"=0A =0A--- a/xen/arch/x86/boot/reloc.c=0A+++ =
b/xen/arch/x86/boot/reloc.c=0A@@ -10,42 +10,49 @@=0A  *    Keir Fraser =
<keir@xen.org>=0A  */=0A =0A+/* entered with %eax =3D BOOT_TRAMPOLINE =
*/=0A asm (=0A     "    .text                         \n"=0A     "    =
.globl _start                 \n"=0A     "_start:                          =
 \n"=0A-    "    mov  $_start,%edi             \n"=0A     "    call 1f     =
                  \n"=0A-    "1:  pop  %esi                     \n"=0A-    =
"    sub  $1b-_start,%esi          \n"=0A-    "    mov  $__bss_start-_start=
,%ecx \n"=0A-    "    rep  movsb                    \n"=0A-    "    xor  =
%eax,%eax                \n"=0A-    "    mov  $_end,%ecx               =
\n"=0A-    "    sub  %edi,%ecx                \n"=0A-    "    rep  stosb   =
                 \n"=0A-    "    mov  $reloc,%eax              \n"=0A-    =
"    jmp  *%eax                    \n"=0A+    "1:  pop  %ebx               =
      \n"=0A+    "    mov  %eax,alloc-1b(%ebx)      \n"=0A+    "    mov  =
$_end,%ecx               \n"  /* check that BSS is empty! */=0A+    "    =
sub  $__bss_start,%ecx        \n"=0A+    "    jz reloc                     =
 \n"=0A+    "1:  jmp 1b                        \n"=0A+    );=0A+=0A+/* =
This is our data.  Because the code must be relocatable, no BSS is=0A+ * =
allowed.  All data is accessed PC-relative with inline assembly.=0A+ =
*/=0A+asm (=0A+    "alloc:                            \n"=0A+    "    =
.long 0                       \n"=0A+    "    .subsection 1                =
 \n"=0A+    "    .p2align 4, 0xcc              \n"=0A+    "    .subsection =
0                 \n"=0A     );=0A =0A typedef unsigned int u32;=0A =
#include "../../../include/xen/multiboot.h"=0A =0A-extern char _start[];=0A=
-=0A-static void *memcpy(void *dest, const void *src, unsigned int =
n)=0A-{=0A-    char *s =3D (char *)src, *d =3D dest;=0A-    while ( n-- =
)=0A-        *d++ =3D *s++;=0A-    return dest;=0A-}=0A-=0A static void =
*reloc_mbi_struct(void *old, unsigned int bytes)=0A {=0A-    static void =
*alloc =3D &_start;=0A-    alloc =3D (void *)(((unsigned long)alloc - =
bytes) & ~15ul);=0A-    return memcpy(alloc, old, bytes);=0A+    void =
*new;=0A+    asm(=0A+    "    call 1f                      \n"=0A+    "1:  =
pop  %%edx                   \n"=0A+    "    mov  alloc-1b(%%edx),%0      =
\n"=0A+    "    sub  %1,%0                   \n"=0A+    "    and  $~15,%0  =
               \n"=0A+    "    mov  %0,alloc-1b(%%edx)      \n"=0A+    "   =
 mov  %0,%%edi                \n"=0A+    "    rep  movsb                   =
\n"=0A+       : "=3D&r" (new), "+c" (bytes), "+S" (old)=0A+	: : "edx", =
"edi");=0A+    return new;=0A }=0A =0A static char *reloc_mbi_string(char =
*old)=0A--- a/xen/arch/x86/boot/trampoline.S=0A+++ b/xen/arch/x86/boot/tram=
poline.S=0A@@ -11,6 +11,13 @@=0A         .long 111b - (off) - .;           =
 \=0A         .popsection=0A =0A+#define bootsym_segrel(sym, off)          =
 \=0A+        $0,$bootsym(sym);                  \=0A+111:;                =
                      \=0A+        .pushsection .trampoline_seg, "a"; =
\=0A+        .long 111b - (off) - .;            \=0A+        .popsection=0A=
+=0A         .globl trampoline_realmode_entry=0A trampoline_realmode_entry:=
=0A         mov     %cs,%ax=0A@@ -151,14 +158,14 @@ trampoline_boot_cpu_ent=
ry:=0A 1:      mov     %eax,%cr0                 # CR0.PE =3D 0 (leave =
protected mode)=0A =0A         /* Load proper real-mode values into %cs, =
%ds, %es and %ss. */=0A-        ljmp    $(BOOT_TRAMPOLINE>>4),$bootsym(1f)=
=0A+        ljmp    bootsym_segrel(1f,2)=0A 1:      mov     %cs,%ax=0A     =
    mov     %ax,%ds=0A         mov     %ax,%es=0A         mov     =
%ax,%ss=0A =0A         /* Initialise stack pointer and IDT, and enable =
irqs. */=0A-        mov     $bootsym(early_stack),%sp=0A+        xor     =
%sp,%sp=0A         lidt    bootsym(rm_idt)=0A         sti=0A =0A@@ -220,7 =
+227,3 @@ rm_idt: .word   256*4-1, 0, 0=0A #include "edd.S"=0A #include =
"video.S"=0A #include "wakeup.S"=0A-=0A-        .align  16=0A-        =
.fill   PAGE_SIZE,1,0=0A-early_stack:=0A--- a/xen/arch/x86/boot/wakeup.S=0A=
+++ b/xen/arch/x86/boot/wakeup.S=0A@@ -11,7 +11,7 @@ ENTRY(wakeup_start)=0A=
         movw    %cs, %ax=0A         movw    %ax, %ds=0A         movw    =
%ax, %ss        # A stack required for BIOS call=0A-        movw    =
$wakesym(early_stack), %sp=0A+        movw    $wakesym(wakeup_stack), =
%sp=0A =0A         pushl   $0              # Kill dangerous flag early=0A  =
       popfl=0A@@ -101,7 +101,7 @@ real_magic:     .long 0x12345678=0A     =
     .globl video_mode, video_flags=0A video_mode:     .long 0=0A =
video_flags:    .long 0=0A-trampoline_seg: .word BOOT_TRAMPOLINE >> =
4=0A+trampoline_seg: .word 0=0A         .pushsection .trampoline_seg, =
"a"=0A         .long   trampoline_seg - .=0A         .popsection=0A@@ =
-116,7 +116,7 @@ wakeup_32:=0A         mov     $BOOT_DS, %eax=0A         =
mov     %eax, %ds=0A         mov     %eax, %ss=0A-        mov     =
$bootsym_rel(early_stack, 4, %esp)=0A+        mov     $bootsym_rel(wakeup_s=
tack, 4, %esp)=0A =0A         # check saved magic again=0A         mov     =
$sym_phys(saved_magic), %eax=0A@@ -188,3 +188,7 @@ ret_point:=0A bogus_save=
d_magic:=0A         movw    $0x0e00 + 'S', 0xb8014=0A         jmp     =
bogus_saved_magic=0A+=0A+        .align  16=0A+        .fill   PAGE_SIZE,1,=
0=0A+wakeup_stack:=0A
--=__Part0729905A.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

--=__Part0729905A.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 11 08:55:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 08:55: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 1Se0OP-0001TB-0v; Mon, 11 Jun 2012 08:54:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Se0ON-0001T5-Hi
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 08:54:31 +0000
Received: from [85.158.138.51:6698] by server-12.bemta-3.messagelabs.com id
	D5/F8-24185-642B5DF4; Mon, 11 Jun 2012 08:54:30 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339404869!23715808!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY1NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18380 invoked from network); 11 Jun 2012 08:54:30 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-3.tower-174.messagelabs.com with SMTP;
	11 Jun 2012 08:54:30 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5B8sSeH013394;
	Mon, 11 Jun 2012 04:54:28 -0400
Date: Mon, 11 Jun 2012 04:54:28 -0400 (EDT)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <506157dc-4ca3-4bd6-93a0-6a768f3bf7fa@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4FD5CB6A02000078000892D0@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.112.17]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: get rid of BOOT_TRAMPOLINE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

CgotLS0tLSBNZXNzYWdnaW8gb3JpZ2luYWxlIC0tLS0tCj4gRGE6ICJKYW4gQmV1bGljaCIgPEpC
ZXVsaWNoQHN1c2UuY29tPgo+IEE6ICJ4ZW4tZGV2ZWwiIDx4ZW4tZGV2ZWxAbGlzdHMueGVuLm9y
Zz4KPiBDYzogIlBhb2xvIEJvbnppbmkiIDxwYm9uemluaUByZWRoYXQuY29tPgo+IEludmlhdG86
IEx1bmVkw6wsIDExIGdpdWdubyAyMDEyIDEwOjQxOjQ2Cj4gT2dnZXR0bzogW1BBVENIXSB4ODY6
IGdldCByaWQgb2YgQk9PVF9UUkFNUE9MSU5FCj4gCj4gV2UgcmVjZW50bHkgc2F3IGEgbWFjaGlu
ZSB0aGF0IGhhcyB0aGUgRUJEQSBleHRlbmRpbmcgYXMgbG93IGFzCj4gMHg3YzAwMCwKPiBzbyB0
aGF0IFhlbiBmYWlscyB0byBib290IGFmdGVyIHJlbG9jYXRpbmcgdGhlIHRyYW1wb2xpbmUuICBU
byBmaXgKPiB0aGlzLAo+IEkgcmVtb3ZlZCBCT09UX1RSQU1QT0xJTkUgYW5kIGJvb3RzeW1fcGh5
cyBjb21wbGV0ZWx5Lgo+IAo+IEhlcmUgYXJlIHRoZSBwYXJ0czoKPiAKPiAxKSB0aGUgdHJhbXBv
bGluZSBzZWdtZW50IGlzIHNldCB0byA2NGsgYmVsb3cgdGhlIEVCREEuICBoZWFkLlMgZ3Jvd3MK
PiB0aGUgYWJpbGl0eSB0byByZWxvY2F0ZSB0aGUgdHJhbXBvbGluZSBzZWdtZW50Cj4gCj4gMikg
cmVsb2MuYyBpcyBtYWRlIHBvc2l0aW9uLWluZGVwZW5kZW50LiAgSXQgYWxsb2NhdGVzIGRhdGEg
YmVsb3cgdGhlCj4gdHJhbXBvbGluZSwgd2hvc2UgYWRkcmVzcyBpcyBwYXNzZWQgaW4gX2VheC4K
PiAKPiAzKSBjbWRsaW5lLlMgaXMgY2FsbGVkIGJlZm9yZSByZWxvY2F0aW5nLCBzbyBhbGwgYm9v
dHN5bV9waHlzIHRoZXJlCj4gYmVjb21lIHN5bV9waHlzLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFBh
b2xvIEJvbnppbmkgPHBib256aW5pQHJlZGhhdC5jb20+Cj4gCj4gamI6IC0gZmFsbCBiYWNrIHRv
IGxvdyBtZW1vcnkgc2l6ZSAoaW5zdGVhZCBvZiBzZWdtZW50IDB4N2MwMCkgaWYKPiBFQkRBCj4g
ICAgICAgdmFsdWUgaXMgb3V0IG9mIHJhbmdlCj4gICAgIC0gYWxzbyBhZGQgdXBwZXIgbGltaXQg
Y2hlY2sgb24gRUJEQSB2YWx1ZQo+ICAgICAtIGZpeCBhbmQgc2ltcGxpZnkgaW5saW5lIGFzc2Vt
Ymx5IG9wZXJhbmRzIGluIHJlbG9jX21iaV9zdHJ1Y3QoKQo+ICAgICAtIHVzZSBscmV0IGluc3Rl
YWQgb2YgcmV0Zgo+ICAgICAtIHJlbmFtZWQgZWFybHlfc3RhY2sgdG8gd2FrZXVwX3N0YWNrLCBk
ZWZpbmVkIGFuZCB1c2VkIG5vdyBvbmx5Cj4gICAgICAgaW4gd2FrZXVwLlMKPiAgICAgLSBhbGln
bmVkIHJlbG9jLmJpbidzIGVuZCBvZiAudGV4dCB0byAxNiBieXRlcywgc28gdGhhdCBjaGVja2lu
Zwo+ICAgICAgIF9fYnNzX3N0YXJ0ID09IGVuZCB3b3JrcyByZWxpYWJseQo+IAo+IFNpZ25lZC1v
ZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KClJldmlld2VkLWJ5OiBQYW9s
byBCb256aW5pIDxwYm9uemluaUByZWRoYXQuY29tPgoKVGhhbmtzIGZvciBwaWNraW5nIHVwIHRo
ZSB3b3JrIGFuZCBzZW5kaW5nIHRoZSBwYXRjaCB1cHN0cmVhbS4KClBhb2xvCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Mon Jun 11 08:55:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 08:55: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 1Se0OP-0001TB-0v; Mon, 11 Jun 2012 08:54:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Se0ON-0001T5-Hi
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 08:54:31 +0000
Received: from [85.158.138.51:6698] by server-12.bemta-3.messagelabs.com id
	D5/F8-24185-642B5DF4; Mon, 11 Jun 2012 08:54:30 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339404869!23715808!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNzY1NTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18380 invoked from network); 11 Jun 2012 08:54:30 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-3.tower-174.messagelabs.com with SMTP;
	11 Jun 2012 08:54:30 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5B8sSeH013394;
	Mon, 11 Jun 2012 04:54:28 -0400
Date: Mon, 11 Jun 2012 04:54:28 -0400 (EDT)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <506157dc-4ca3-4bd6-93a0-6a768f3bf7fa@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4FD5CB6A02000078000892D0@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.112.17]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: get rid of BOOT_TRAMPOLINE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

CgotLS0tLSBNZXNzYWdnaW8gb3JpZ2luYWxlIC0tLS0tCj4gRGE6ICJKYW4gQmV1bGljaCIgPEpC
ZXVsaWNoQHN1c2UuY29tPgo+IEE6ICJ4ZW4tZGV2ZWwiIDx4ZW4tZGV2ZWxAbGlzdHMueGVuLm9y
Zz4KPiBDYzogIlBhb2xvIEJvbnppbmkiIDxwYm9uemluaUByZWRoYXQuY29tPgo+IEludmlhdG86
IEx1bmVkw6wsIDExIGdpdWdubyAyMDEyIDEwOjQxOjQ2Cj4gT2dnZXR0bzogW1BBVENIXSB4ODY6
IGdldCByaWQgb2YgQk9PVF9UUkFNUE9MSU5FCj4gCj4gV2UgcmVjZW50bHkgc2F3IGEgbWFjaGlu
ZSB0aGF0IGhhcyB0aGUgRUJEQSBleHRlbmRpbmcgYXMgbG93IGFzCj4gMHg3YzAwMCwKPiBzbyB0
aGF0IFhlbiBmYWlscyB0byBib290IGFmdGVyIHJlbG9jYXRpbmcgdGhlIHRyYW1wb2xpbmUuICBU
byBmaXgKPiB0aGlzLAo+IEkgcmVtb3ZlZCBCT09UX1RSQU1QT0xJTkUgYW5kIGJvb3RzeW1fcGh5
cyBjb21wbGV0ZWx5Lgo+IAo+IEhlcmUgYXJlIHRoZSBwYXJ0czoKPiAKPiAxKSB0aGUgdHJhbXBv
bGluZSBzZWdtZW50IGlzIHNldCB0byA2NGsgYmVsb3cgdGhlIEVCREEuICBoZWFkLlMgZ3Jvd3MK
PiB0aGUgYWJpbGl0eSB0byByZWxvY2F0ZSB0aGUgdHJhbXBvbGluZSBzZWdtZW50Cj4gCj4gMikg
cmVsb2MuYyBpcyBtYWRlIHBvc2l0aW9uLWluZGVwZW5kZW50LiAgSXQgYWxsb2NhdGVzIGRhdGEg
YmVsb3cgdGhlCj4gdHJhbXBvbGluZSwgd2hvc2UgYWRkcmVzcyBpcyBwYXNzZWQgaW4gX2VheC4K
PiAKPiAzKSBjbWRsaW5lLlMgaXMgY2FsbGVkIGJlZm9yZSByZWxvY2F0aW5nLCBzbyBhbGwgYm9v
dHN5bV9waHlzIHRoZXJlCj4gYmVjb21lIHN5bV9waHlzLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFBh
b2xvIEJvbnppbmkgPHBib256aW5pQHJlZGhhdC5jb20+Cj4gCj4gamI6IC0gZmFsbCBiYWNrIHRv
IGxvdyBtZW1vcnkgc2l6ZSAoaW5zdGVhZCBvZiBzZWdtZW50IDB4N2MwMCkgaWYKPiBFQkRBCj4g
ICAgICAgdmFsdWUgaXMgb3V0IG9mIHJhbmdlCj4gICAgIC0gYWxzbyBhZGQgdXBwZXIgbGltaXQg
Y2hlY2sgb24gRUJEQSB2YWx1ZQo+ICAgICAtIGZpeCBhbmQgc2ltcGxpZnkgaW5saW5lIGFzc2Vt
Ymx5IG9wZXJhbmRzIGluIHJlbG9jX21iaV9zdHJ1Y3QoKQo+ICAgICAtIHVzZSBscmV0IGluc3Rl
YWQgb2YgcmV0Zgo+ICAgICAtIHJlbmFtZWQgZWFybHlfc3RhY2sgdG8gd2FrZXVwX3N0YWNrLCBk
ZWZpbmVkIGFuZCB1c2VkIG5vdyBvbmx5Cj4gICAgICAgaW4gd2FrZXVwLlMKPiAgICAgLSBhbGln
bmVkIHJlbG9jLmJpbidzIGVuZCBvZiAudGV4dCB0byAxNiBieXRlcywgc28gdGhhdCBjaGVja2lu
Zwo+ICAgICAgIF9fYnNzX3N0YXJ0ID09IGVuZCB3b3JrcyByZWxpYWJseQo+IAo+IFNpZ25lZC1v
ZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KClJldmlld2VkLWJ5OiBQYW9s
byBCb256aW5pIDxwYm9uemluaUByZWRoYXQuY29tPgoKVGhhbmtzIGZvciBwaWNraW5nIHVwIHRo
ZSB3b3JrIGFuZCBzZW5kaW5nIHRoZSBwYXRjaCB1cHN0cmVhbS4KClBhb2xvCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Mon Jun 11 09:47:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 09: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 1Se1DH-0002ex-6d; Mon, 11 Jun 2012 09:47:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Se1DF-0002es-GE
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 09:47:05 +0000
Received: from [85.158.143.99:34989] by server-2.bemta-4.messagelabs.com id
	EB/32-17938-89EB5DF4; Mon, 11 Jun 2012 09:47:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339408024!25200963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 561 invoked from network); 11 Jun 2012 09:47:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 09:47:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,748,1330905600"; d="scan'208";a="12939195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 09:47:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 10:47:03 +0100
Date: Mon, 11 Jun 2012 10:46:54 +0100
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: <20433.57755.274531.968750@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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, 8 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
> > > a potential security issue which might allow guests to do something
> > > exciting ?
> > 
> > virtfs allows guest and host to share a folder. You can restrict
> > access to the folder in various ways:
> 
> So what is the default configuration ?

The default is on.


> Do we have any protection from
> possible bugs in the virtfs access control system ?

Nothing more and nothing less than QEMU 1.0 stable provides.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 09:47:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 09: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 1Se1DH-0002ex-6d; Mon, 11 Jun 2012 09:47:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Se1DF-0002es-GE
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 09:47:05 +0000
Received: from [85.158.143.99:34989] by server-2.bemta-4.messagelabs.com id
	EB/32-17938-89EB5DF4; Mon, 11 Jun 2012 09:47:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339408024!25200963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 561 invoked from network); 11 Jun 2012 09:47:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 09:47:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,748,1330905600"; d="scan'208";a="12939195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 09:47:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 10:47:03 +0100
Date: Mon, 11 Jun 2012 10:46:54 +0100
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: <20433.57755.274531.968750@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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, 8 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > Forgive my ignorance, but now I want to know: what is virtfs ?  Is it
> > > a potential security issue which might allow guests to do something
> > > exciting ?
> > 
> > virtfs allows guest and host to share a folder. You can restrict
> > access to the folder in various ways:
> 
> So what is the default configuration ?

The default is on.


> Do we have any protection from
> possible bugs in the virtfs access control system ?

Nothing more and nothing less than QEMU 1.0 stable provides.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se1Ys-0003jR-SH; Mon, 11 Jun 2012 10:09:26 +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 1Se1Yr-0003jM-BU
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:09:25 +0000
Received: from [85.158.143.99:23944] by server-1.bemta-4.messagelabs.com id
	AE/DC-24392-4D3C5DF4; Mon, 11 Jun 2012 10:09:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339409363!31681468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 11 Jun 2012 10:09:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:09:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12940351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:09:23 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:09:23 +0100
Message-ID: <4FD5C3D2.1040905@citrix.com>
Date: Mon, 11 Jun 2012 11:09:22 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-2-git-send-email-roger.pau@citrix.com>
	<20432.34886.348463.178975@mariner.uk.xensource.com>
In-Reply-To: <20432.34886.348463.178975@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 01/10] libxl: change
	libxl__ao_device_remove to libxl__ao_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

Ian Jackson wrote:

I've fixed al other comments, so I'm not going to reply to every one of 
them :)

>> +void libxl__initiate_device_remove(libxl__egc *egc,
>> +                                   libxl__ao_device *aodev)
> ...
>> -    libxl__ev_devstate_init(&aorm->ds);
>> +    libxl__ev_devstate_init(&aodev->ds);
>>
>> -    rc = libxl__ev_devstate_wait(gc,&aorm->ds, device_remove_callback,
>> +    rc = libxl__ev_devstate_wait(gc,&aodev->ds, device_backend_callback,
>>                                    state_path, XenbusStateClosed,
>>                                    LIBXL_DESTROY_TIMEOUT * 1000);
>
> libxl__ev_devstate_init is not needed before _wait.  (Admittedly
> that's there in the code before you touched it.)  In general foo_init
> is not needed before foo_do_the_thing_and_call_me_back.
>
> Given the use of `backend' in function names to refer to what is
> manipulated with aodev->ds, perhaps aodev->ds should be called
> aodev->backend_ds ?

Done, I've changed it to backend_ds

> I was briefly confused about whether `device_backend_cleanup' was a
> general cleanup function for a libxl__ao_device (which it isn't).  And
> there is of course a frontend state too, which we don't explicitly
> deal with here.
>
> How do the frontend and backend directories get removed from
> xenstore ?  (I have a feeling I have asked this before but I don't
> remember the answer.  Perhaps it could be a comment in the code in
> some appropriate place?)

We talked about this, and now I've introduced a function that is always 
called before the user callback, that deletes both frontend and backend 
xs entries.

So the flow of execution is a little bit more "linear", and we have 
common entry and exit points, we only call the callback from the exit 
function.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se1Ys-0003jR-SH; Mon, 11 Jun 2012 10:09:26 +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 1Se1Yr-0003jM-BU
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:09:25 +0000
Received: from [85.158.143.99:23944] by server-1.bemta-4.messagelabs.com id
	AE/DC-24392-4D3C5DF4; Mon, 11 Jun 2012 10:09:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339409363!31681468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 11 Jun 2012 10:09:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:09:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12940351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:09:23 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:09:23 +0100
Message-ID: <4FD5C3D2.1040905@citrix.com>
Date: Mon, 11 Jun 2012 11:09:22 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-2-git-send-email-roger.pau@citrix.com>
	<20432.34886.348463.178975@mariner.uk.xensource.com>
In-Reply-To: <20432.34886.348463.178975@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 01/10] libxl: change
	libxl__ao_device_remove to libxl__ao_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

Ian Jackson wrote:

I've fixed al other comments, so I'm not going to reply to every one of 
them :)

>> +void libxl__initiate_device_remove(libxl__egc *egc,
>> +                                   libxl__ao_device *aodev)
> ...
>> -    libxl__ev_devstate_init(&aorm->ds);
>> +    libxl__ev_devstate_init(&aodev->ds);
>>
>> -    rc = libxl__ev_devstate_wait(gc,&aorm->ds, device_remove_callback,
>> +    rc = libxl__ev_devstate_wait(gc,&aodev->ds, device_backend_callback,
>>                                    state_path, XenbusStateClosed,
>>                                    LIBXL_DESTROY_TIMEOUT * 1000);
>
> libxl__ev_devstate_init is not needed before _wait.  (Admittedly
> that's there in the code before you touched it.)  In general foo_init
> is not needed before foo_do_the_thing_and_call_me_back.
>
> Given the use of `backend' in function names to refer to what is
> manipulated with aodev->ds, perhaps aodev->ds should be called
> aodev->backend_ds ?

Done, I've changed it to backend_ds

> I was briefly confused about whether `device_backend_cleanup' was a
> general cleanup function for a libxl__ao_device (which it isn't).  And
> there is of course a frontend state too, which we don't explicitly
> deal with here.
>
> How do the frontend and backend directories get removed from
> xenstore ?  (I have a feeling I have asked this before but I don't
> remember the answer.  Perhaps it could be a comment in the code in
> some appropriate place?)

We talked about this, and now I've introduced a function that is always 
called before the user callback, that deletes both frontend and backend 
xs entries.

So the flow of execution is a little bit more "linear", and we have 
common entry and exit points, we only call the callback from the exit 
function.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:16:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10:16: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 1Se1en-0003sq-N1; Mon, 11 Jun 2012 10:15: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 1Se1em-0003sk-7n
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:15:32 +0000
Received: from [85.158.139.83:64521] by server-10.bemta-5.messagelabs.com id
	88/13-23803-345C5DF4; Mon, 11 Jun 2012 10:15:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339409730!25627730!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24916 invoked from network); 11 Jun 2012 10:15:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12940511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:15:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:15:20 +0100
Date: Mon, 11 Jun 2012 11:15:00 +0100
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: <20434.938.126095.932066@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206111114490.14957@kaball.uk.xensource.com>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
	<4FC78D5502000078000875A7@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
	<20434.938.126095.932066@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 8 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used"):
> > On Thu, 31 May 2012, Jan Beulich wrote:
> > > > It should be applied to qemu-xen-traditional too.
> > > 
> > > And the other one ("qemu/xendisk: properly update stats in
> > > ioreq_release()") probably too.
> > 
> > Right.
> > That patch is already in upstream QEMU and qemu-xen-upstream but it is
> > missing in qemu-xen-traditional.
> 
> Can you tell me the commit id in qemu-xen-upstream so I can put it in
> the commit message in qemu-xen-traditional ?

I'll let you know when I have one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:16:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10:16: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 1Se1en-0003sq-N1; Mon, 11 Jun 2012 10:15: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 1Se1em-0003sk-7n
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:15:32 +0000
Received: from [85.158.139.83:64521] by server-10.bemta-5.messagelabs.com id
	88/13-23803-345C5DF4; Mon, 11 Jun 2012 10:15:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339409730!25627730!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24916 invoked from network); 11 Jun 2012 10:15:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12940511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:15:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:15:20 +0100
Date: Mon, 11 Jun 2012 11:15:00 +0100
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: <20434.938.126095.932066@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206111114490.14957@kaball.uk.xensource.com>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
	<4FC78D5502000078000875A7@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
	<20434.938.126095.932066@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 8 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used"):
> > On Thu, 31 May 2012, Jan Beulich wrote:
> > > > It should be applied to qemu-xen-traditional too.
> > > 
> > > And the other one ("qemu/xendisk: properly update stats in
> > > ioreq_release()") probably too.
> > 
> > Right.
> > That patch is already in upstream QEMU and qemu-xen-upstream but it is
> > missing in qemu-xen-traditional.
> 
> Can you tell me the commit id in qemu-xen-upstream so I can put it in
> the commit message in qemu-xen-traditional ?

I'll let you know when I have one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:20:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10: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 1Se1hr-0003yz-9q; Mon, 11 Jun 2012 10:18:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Se1hq-0003yu-El
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:18:42 +0000
Received: from [85.158.139.83:41091] by server-6.bemta-5.messagelabs.com id
	5B/93-18700-106C5DF4; Mon, 11 Jun 2012 10:18:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339409920!28987038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21256 invoked from network); 11 Jun 2012 10:18:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:18:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12940789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:18:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:18:40 +0100
Date: Mon, 11 Jun 2012 11:18:21 +0100
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: <alpine.DEB.2.02.1206111114490.14957@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206111116590.14957@kaball.uk.xensource.com>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
	<4FC78D5502000078000875A7@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
	<20434.938.126095.932066@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111114490.14957@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 11 Jun 2012, Stefano Stabellini wrote:
> On Fri, 8 Jun 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used"):
> > > On Thu, 31 May 2012, Jan Beulich wrote:
> > > > > It should be applied to qemu-xen-traditional too.
> > > > 
> > > > And the other one ("qemu/xendisk: properly update stats in
> > > > ioreq_release()") probably too.
> > > 
> > > Right.
> > > That patch is already in upstream QEMU and qemu-xen-upstream but it is
> > > missing in qemu-xen-traditional.
> > 
> > Can you tell me the commit id in qemu-xen-upstream so I can put it in
> > the commit message in qemu-xen-traditional ?
> 
> I'll let you know when I have one.

Reading more carefully, you are actually talking about a different
patch from the one in the subject line.
Here is what you are looking for:

commit ed5477664369c1e9de23b0e7e8f16a418573bd2a
Author: Jan Beulich <JBeulich@suse.com>
Date:   Mon May 14 16:46:33 2012 +0000

    xen_disk: properly update stats in ioreq_release()
    
    While for the "normal" case (called from blk_send_response_all())
    decrementing requests_finished is correct, doing so in the parse error
    case is wrong; requests_inflight needs to be decremented instead.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:20:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10: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 1Se1hr-0003yz-9q; Mon, 11 Jun 2012 10:18:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Se1hq-0003yu-El
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:18:42 +0000
Received: from [85.158.139.83:41091] by server-6.bemta-5.messagelabs.com id
	5B/93-18700-106C5DF4; Mon, 11 Jun 2012 10:18:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339409920!28987038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21256 invoked from network); 11 Jun 2012 10:18:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:18:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12940789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:18:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:18:40 +0100
Date: Mon, 11 Jun 2012 11:18:21 +0100
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: <alpine.DEB.2.02.1206111114490.14957@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206111116590.14957@kaball.uk.xensource.com>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
	<4FC78D5502000078000875A7@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311432190.26786@kaball-desktop>
	<20434.938.126095.932066@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111114490.14957@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 11 Jun 2012, Stefano Stabellini wrote:
> On Fri, 8 Jun 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used"):
> > > On Thu, 31 May 2012, Jan Beulich wrote:
> > > > > It should be applied to qemu-xen-traditional too.
> > > > 
> > > > And the other one ("qemu/xendisk: properly update stats in
> > > > ioreq_release()") probably too.
> > > 
> > > Right.
> > > That patch is already in upstream QEMU and qemu-xen-upstream but it is
> > > missing in qemu-xen-traditional.
> > 
> > Can you tell me the commit id in qemu-xen-upstream so I can put it in
> > the commit message in qemu-xen-traditional ?
> 
> I'll let you know when I have one.

Reading more carefully, you are actually talking about a different
patch from the one in the subject line.
Here is what you are looking for:

commit ed5477664369c1e9de23b0e7e8f16a418573bd2a
Author: Jan Beulich <JBeulich@suse.com>
Date:   Mon May 14 16:46:33 2012 +0000

    xen_disk: properly update stats in ioreq_release()
    
    While for the "normal" case (called from blk_send_response_all())
    decrementing requests_finished is correct, doing so in the parse error
    case is wrong; requests_inflight needs to be decremented instead.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Reviewed-by: Kevin Wolf <kwolf@redhat.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10: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 1Se1mH-00049A-W9; Mon, 11 Jun 2012 10:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Se1mG-000491-9x
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 10:23:16 +0000
Received: from [85.158.143.35:65309] by server-2.bemta-4.messagelabs.com id
	74/BB-17938-317C5DF4; Mon, 11 Jun 2012 10:23:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339410193!12496002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTkxNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29489 invoked from network); 11 Jun 2012 10:23:15 -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;
	11 Jun 2012 10:23:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330923600"; d="scan'208";a="198246296"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 06:23:13 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 11 Jun 2012
	06:23:13 -0400
Message-ID: <4FD5C70F.20707@citrix.com>
Date: Mon, 11 Jun 2012 11:23:11 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
	<20120610102347.GA14968@andromeda.dapyr.net>
In-Reply-To: <20120610102347.GA14968@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
 xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/06/12 11:23, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
>>> From: David Vrabel <david.vrabel@citrix.com>
>>>
>>> In xen_set_pte() if batching is unavailable (because the caller is in
>>> an interrupt context such as handling a page fault) it would fall back
>>> to using native_set_pte() and trapping and emulating the PTE write.
>>>
>>> On 32-bit guests this requires two traps for each PTE write (one for
>>> each dword of the PTE).  Instead, do one mmu_update hypercall
>>> directly.
>>
>> OK.
>>>
>>> This significantly improves page fault performance in 32-bit PV
>>> guests.
>>
>> Nice!
> 
> With this patch I keep on getting this (which is v3.5-rc2 plus my
> patches in stable/for-linus-3.5 and yours):
[...]
> (XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
> (XEN) mm.c:3460:d0 Could not get page for normal update

Are you talking about these?  I've not seen them.  Do you know when they
happen?

The patch doesn't change what PTEs are written or their value so I don't
think I've introduced a regression -- only it now prints a new
warning/error.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10: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 1Se1mH-00049A-W9; Mon, 11 Jun 2012 10:23:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Se1mG-000491-9x
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 10:23:16 +0000
Received: from [85.158.143.35:65309] by server-2.bemta-4.messagelabs.com id
	74/BB-17938-317C5DF4; Mon, 11 Jun 2012 10:23:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339410193!12496002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTkxNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29489 invoked from network); 11 Jun 2012 10:23:15 -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;
	11 Jun 2012 10:23:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330923600"; d="scan'208";a="198246296"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 06:23:13 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 11 Jun 2012
	06:23:13 -0400
Message-ID: <4FD5C70F.20707@citrix.com>
Date: Mon, 11 Jun 2012 11:23:11 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
	<20120610102347.GA14968@andromeda.dapyr.net>
In-Reply-To: <20120610102347.GA14968@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
 xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/06/12 11:23, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
>>> From: David Vrabel <david.vrabel@citrix.com>
>>>
>>> In xen_set_pte() if batching is unavailable (because the caller is in
>>> an interrupt context such as handling a page fault) it would fall back
>>> to using native_set_pte() and trapping and emulating the PTE write.
>>>
>>> On 32-bit guests this requires two traps for each PTE write (one for
>>> each dword of the PTE).  Instead, do one mmu_update hypercall
>>> directly.
>>
>> OK.
>>>
>>> This significantly improves page fault performance in 32-bit PV
>>> guests.
>>
>> Nice!
> 
> With this patch I keep on getting this (which is v3.5-rc2 plus my
> patches in stable/for-linus-3.5 and yours):
[...]
> (XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
> (XEN) mm.c:3460:d0 Could not get page for normal update

Are you talking about these?  I've not seen them.  Do you know when they
happen?

The patch doesn't change what PTEs are written or their value so I don't
think I've introduced a regression -- only it now prints a new
warning/error.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10: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 1Se1xp-0004L8-6s; Mon, 11 Jun 2012 10:35:13 +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 1Se1xn-0004L3-IK
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 10:35:11 +0000
Received: from [85.158.139.83:42001] by server-10.bemta-5.messagelabs.com id
	16/B9-23803-ED9C5DF4; Mon, 11 Jun 2012 10:35:10 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339410909!19138743!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gODQ0NjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9876 invoked from network); 11 Jun 2012 10:35:10 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-8.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 10:35:10 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5BAY5rS015934;
	Mon, 11 Jun 2012 06:34:05 -0400
Date: Mon, 11 Jun 2012 06:34:05 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120610020331.GA26100@localhost.localdomain>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Andrea Arcangeli <aarcange@redhat.com>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>, 676360@bugs.debian.org,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, Jan Beulich <jbeulich@suse.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
	for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



----- Original Message -----
> On Thu, Jun 07, 2012 at 11:00:33PM +0200, Andrea Arcangeli wrote:
> > In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while
> > holding
> > the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
> > contents under Xen.
> > 
> > So instead of dealing only with "consistent" pmdvals in
> > pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
> > simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with
> > pmdvals
> > where the low 32bit and high 32bit could be inconsistent (to avoid
> > having to use cmpxchg8b).
> 
> <nods>
> > 
> > The only guarantee we get from pmd_read_atomic is that if the low
> > part
> > of the pmd was found null, the high part will be null too (so the
> > pmd
> > will be considered unstable). And if the low part of the pmd is
> > found
> > "stable" later, then it means the whole pmd was read atomically
> > (because after a pmd is stable, neither MADV_DONTNEED nor page
> > faults
> > can alter it anymore, and we read the high part after the low
> > part).
> > 
> > In the 32bit PAE x86 case, it is enough to read the low part of the
> > pmdval atomically to declare the pmd as "stable" and that's true
> > for
> > THP and no THP, furthermore in the THP case we also have a
> > barrier()
> > that will prevent any inconsistent pmdvals to be cached by a later
> > re-read of the *pmd.
> 
> Nice. Andrew, any chane you could test this patch on the affected
> Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> hypervisor or is it really only on Linode and Amazon EC2?
> 

Originally, I was able to reproduce the issue easily with a RHEL5
host. Now, with this patch it's fixed.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10: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 1Se1xp-0004L8-6s; Mon, 11 Jun 2012 10:35:13 +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 1Se1xn-0004L3-IK
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 10:35:11 +0000
Received: from [85.158.139.83:42001] by server-10.bemta-5.messagelabs.com id
	16/B9-23803-ED9C5DF4; Mon, 11 Jun 2012 10:35:10 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339410909!19138743!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gODQ0NjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9876 invoked from network); 11 Jun 2012 10:35:10 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-8.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 10:35:10 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5BAY5rS015934;
	Mon, 11 Jun 2012 06:34:05 -0400
Date: Mon, 11 Jun 2012 06:34:05 -0400 (EDT)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120610020331.GA26100@localhost.localdomain>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Andrea Arcangeli <aarcange@redhat.com>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>, 676360@bugs.debian.org,
	"linux-mm@kvack.org Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, Jan Beulich <jbeulich@suse.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
	for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



----- Original Message -----
> On Thu, Jun 07, 2012 at 11:00:33PM +0200, Andrea Arcangeli wrote:
> > In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while
> > holding
> > the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
> > contents under Xen.
> > 
> > So instead of dealing only with "consistent" pmdvals in
> > pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
> > simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with
> > pmdvals
> > where the low 32bit and high 32bit could be inconsistent (to avoid
> > having to use cmpxchg8b).
> 
> <nods>
> > 
> > The only guarantee we get from pmd_read_atomic is that if the low
> > part
> > of the pmd was found null, the high part will be null too (so the
> > pmd
> > will be considered unstable). And if the low part of the pmd is
> > found
> > "stable" later, then it means the whole pmd was read atomically
> > (because after a pmd is stable, neither MADV_DONTNEED nor page
> > faults
> > can alter it anymore, and we read the high part after the low
> > part).
> > 
> > In the 32bit PAE x86 case, it is enough to read the low part of the
> > pmdval atomically to declare the pmd as "stable" and that's true
> > for
> > THP and no THP, furthermore in the THP case we also have a
> > barrier()
> > that will prevent any inconsistent pmdvals to be cached by a later
> > re-read of the *pmd.
> 
> Nice. Andrew, any chane you could test this patch on the affected
> Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> hypervisor or is it really only on Linode and Amazon EC2?
> 

Originally, I was able to reproduce the issue easily with a RHEL5
host. Now, with this patch it's fixed.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se2Gk-0004Wf-8I; Mon, 11 Jun 2012 10:54: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 1Se2Gi-0004WZ-FR
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:54:44 +0000
Received: from [193.109.254.147:15903] by server-12.bemta-14.messagelabs.com
	id 46/FA-12998-37EC5DF4; Mon, 11 Jun 2012 10:54:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339412081!6690397!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27307 invoked from network); 11 Jun 2012 10:54:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12941987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:54:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:54:40 +0100
Date: Mon, 11 Jun 2012 11:54:21 +0100
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: <4FD209480200007800088C52@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Fri, 8 Jun 2012, Jan Beulich wrote:
> >>> On 08.06.12 at 13:42, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Fri, 8 Jun 2012, Jan Beulich wrote:
> >> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> wrote:
> >> > On Mon, 4 Jun 2012, Jan Beulich wrote:
> >> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> >> >> os-posix.c:os_find_datadir() works. While one would generally expect
> >> >> that function to honour the --datadir configure option, fixing this is
> >> >> quite a bit more involved than simply adjusting the configure options
> >> >> to match the function's behavior (in that, for an installed binary, it
> >> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> >> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> >> >> due to (presumably) some other qemu instance being installed on
> >> >> people's systems (but being absent when running qemu-system-i386 from
> >> >> the dist/ portion of the build tree).
> >> >> 
> >> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> >> >> 
> >> >> --- a/tools/Makefile
> >> >> +++ b/tools/Makefile
> >> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
> >> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
> >> >>  		-L$(XEN_ROOT)/tools/xenstore" \
> >> >>  		--bindir=$(LIBEXEC) \
> >> >> -		--datadir=$(SHAREDIR)/qemu-xen \
> >> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
> >> >>  		--disable-kvm \
> >> >>  		--python=$(PYTHON) \
> >> >>  		$(IOEMU_CONFIGURE_CROSS); \
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> > 
> >> > This is a QEMU bug, so I would rather fix it there.
> >> 
> >> That's not as simple as you appear to think, as it would be necessary
> >> to meaningfully express an arbitrary datadir relative to bindir.
> >> 
> >> > In fact the fix could be as simple as the appended patch.
> >> > Does it work for you?
> >> > 
> >> > diff --git a/os-posix.c b/os-posix.c
> >> > index dc4a6bb..d0c873d 100644
> >> > --- a/os-posix.c
> >> > +++ b/os-posix.c
> >> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
> >> >              g_free(res);
> >> >              res = NULL;
> >> >          }
> >> > +    } else {
> >> > +        g_free(res);
> >> > +        res = NULL;
> >> 
> >> How can this work? Afaict it would even break currently working
> >> cases, as it now makes the function return NULL not only when
> >> both access() checks failed, but also when the first one succeeded.
> > 
> > Yes, you are right, I misread the error condition of "access".
> > 
> > Like you wrote, os_find_datadir checks for the existence of
> > $bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
> > it checks for /usr/lib/xen/pc-bios and if they both don't exist return
> > NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).
> 
> That is what you want in the installed case.
> 
> > While it is certainly not how I would have written this code, it should
> > work correctly. How is that you system has /usr/lib/xen/pc-bios or
> > /usr/lib/xen/share/qemu?
> 
> As I had written in the description, I'm after the non-installed
> case instead (i.e. running from the build tree's dist/), and that
> case can only be covered by either fixing os_find_datadir() or
> forcing the value of --datadir to match the function's
> expectations.
> 
> Additionally, for the installed case it doesn't matter where the
> bits are put, as it'll always be the configured value that gets
> used.

However your patch changes the location of data_dir for the
installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
If you are after the non-installed case, you must be already setting
device_model_override in your VM config file to point to the right
binary. You might as well pass:

device_model_args = ['-L', '/path/to/share/file' ]

that should solve your problem.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 10:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 10:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se2Gk-0004Wf-8I; Mon, 11 Jun 2012 10:54: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 1Se2Gi-0004WZ-FR
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 10:54:44 +0000
Received: from [193.109.254.147:15903] by server-12.bemta-14.messagelabs.com
	id 46/FA-12998-37EC5DF4; Mon, 11 Jun 2012 10:54:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339412081!6690397!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27307 invoked from network); 11 Jun 2012 10:54:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 10:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12941987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 10:54:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 11:54:40 +0100
Date: Mon, 11 Jun 2012 11:54:21 +0100
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: <4FD209480200007800088C52@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Fri, 8 Jun 2012, Jan Beulich wrote:
> >>> On 08.06.12 at 13:42, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Fri, 8 Jun 2012, Jan Beulich wrote:
> >> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> wrote:
> >> > On Mon, 4 Jun 2012, Jan Beulich wrote:
> >> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
> >> >> os-posix.c:os_find_datadir() works. While one would generally expect
> >> >> that function to honour the --datadir configure option, fixing this is
> >> >> quite a bit more involved than simply adjusting the configure options
> >> >> to match the function's behavior (in that, for an installed binary, it
> >> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
> >> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
> >> >> due to (presumably) some other qemu instance being installed on
> >> >> people's systems (but being absent when running qemu-system-i386 from
> >> >> the dist/ portion of the build tree).
> >> >> 
> >> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> >> >> 
> >> >> --- a/tools/Makefile
> >> >> +++ b/tools/Makefile
> >> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
> >> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
> >> >>  		-L$(XEN_ROOT)/tools/xenstore" \
> >> >>  		--bindir=$(LIBEXEC) \
> >> >> -		--datadir=$(SHAREDIR)/qemu-xen \
> >> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
> >> >>  		--disable-kvm \
> >> >>  		--python=$(PYTHON) \
> >> >>  		$(IOEMU_CONFIGURE_CROSS); \
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> > 
> >> > This is a QEMU bug, so I would rather fix it there.
> >> 
> >> That's not as simple as you appear to think, as it would be necessary
> >> to meaningfully express an arbitrary datadir relative to bindir.
> >> 
> >> > In fact the fix could be as simple as the appended patch.
> >> > Does it work for you?
> >> > 
> >> > diff --git a/os-posix.c b/os-posix.c
> >> > index dc4a6bb..d0c873d 100644
> >> > --- a/os-posix.c
> >> > +++ b/os-posix.c
> >> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
> >> >              g_free(res);
> >> >              res = NULL;
> >> >          }
> >> > +    } else {
> >> > +        g_free(res);
> >> > +        res = NULL;
> >> 
> >> How can this work? Afaict it would even break currently working
> >> cases, as it now makes the function return NULL not only when
> >> both access() checks failed, but also when the first one succeeded.
> > 
> > Yes, you are right, I misread the error condition of "access".
> > 
> > Like you wrote, os_find_datadir checks for the existence of
> > $bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
> > it checks for /usr/lib/xen/pc-bios and if they both don't exist return
> > NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).
> 
> That is what you want in the installed case.
> 
> > While it is certainly not how I would have written this code, it should
> > work correctly. How is that you system has /usr/lib/xen/pc-bios or
> > /usr/lib/xen/share/qemu?
> 
> As I had written in the description, I'm after the non-installed
> case instead (i.e. running from the build tree's dist/), and that
> case can only be covered by either fixing os_find_datadir() or
> forcing the value of --datadir to match the function's
> expectations.
> 
> Additionally, for the installed case it doesn't matter where the
> bits are put, as it'll always be the configured value that gets
> used.

However your patch changes the location of data_dir for the
installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
If you are after the non-installed case, you must be already setting
device_model_override in your VM config file to point to the right
binary. You might as well pass:

device_model_args = ['-L', '/path/to/share/file' ]

that should solve your problem.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 11:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se2Yf-0004om-55; Mon, 11 Jun 2012 11:13: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 1Se2Yd-0004oh-Pd
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 11:13:15 +0000
Received: from [85.158.143.35:57982] by server-3.bemta-4.messagelabs.com id
	7A/5A-05808-BC2D5DF4; Mon, 11 Jun 2012 11:13:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339413194!13160686!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11395 invoked from network); 11 Jun 2012 11:13:14 -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; 11 Jun 2012 11:13:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 12:13:13 +0100
Message-Id: <4FD5EF10020000780008932D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 12:13:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 11.06.12 at 12:54, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Fri, 8 Jun 2012, Jan Beulich wrote:
>> >>> On 08.06.12 at 13:42, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> wrote:
>> > On Fri, 8 Jun 2012, Jan Beulich wrote:
>> >> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> >> wrote:
>> >> > On Mon, 4 Jun 2012, Jan Beulich wrote:
>> >> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
>> >> >> os-posix.c:os_find_datadir() works. While one would generally expect
>> >> >> that function to honour the --datadir configure option, fixing this is
>> >> >> quite a bit more involved than simply adjusting the configure options
>> >> >> to match the function's behavior (in that, for an installed binary, it
>> >> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
>> >> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
>> >> >> due to (presumably) some other qemu instance being installed on
>> >> >> people's systems (but being absent when running qemu-system-i386 from
>> >> >> the dist/ portion of the build tree).
>> >> >> 
>> >> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
>> >> >> 
>> >> >> --- a/tools/Makefile
>> >> >> +++ b/tools/Makefile
>> >> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>> >> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>> >> >>  		-L$(XEN_ROOT)/tools/xenstore" \
>> >> >>  		--bindir=$(LIBEXEC) \
>> >> >> -		--datadir=$(SHAREDIR)/qemu-xen \
>> >> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>> >> >>  		--disable-kvm \
>> >> >>  		--python=$(PYTHON) \
>> >> >>  		$(IOEMU_CONFIGURE_CROSS); \
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> 
>> >> > 
>> >> > This is a QEMU bug, so I would rather fix it there.
>> >> 
>> >> That's not as simple as you appear to think, as it would be necessary
>> >> to meaningfully express an arbitrary datadir relative to bindir.
>> >> 
>> >> > In fact the fix could be as simple as the appended patch.
>> >> > Does it work for you?
>> >> > 
>> >> > diff --git a/os-posix.c b/os-posix.c
>> >> > index dc4a6bb..d0c873d 100644
>> >> > --- a/os-posix.c
>> >> > +++ b/os-posix.c
>> >> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
>> >> >              g_free(res);
>> >> >              res = NULL;
>> >> >          }
>> >> > +    } else {
>> >> > +        g_free(res);
>> >> > +        res = NULL;
>> >> 
>> >> How can this work? Afaict it would even break currently working
>> >> cases, as it now makes the function return NULL not only when
>> >> both access() checks failed, but also when the first one succeeded.
>> > 
>> > Yes, you are right, I misread the error condition of "access".
>> > 
>> > Like you wrote, os_find_datadir checks for the existence of
>> > $bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
>> > it checks for /usr/lib/xen/pc-bios and if they both don't exist return
>> > NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).
>> 
>> That is what you want in the installed case.
>> 
>> > While it is certainly not how I would have written this code, it should
>> > work correctly. How is that you system has /usr/lib/xen/pc-bios or
>> > /usr/lib/xen/share/qemu?
>> 
>> As I had written in the description, I'm after the non-installed
>> case instead (i.e. running from the build tree's dist/), and that
>> case can only be covered by either fixing os_find_datadir() or
>> forcing the value of --datadir to match the function's
>> expectations.
>> 
>> Additionally, for the installed case it doesn't matter where the
>> bits are put, as it'll always be the configured value that gets
>> used.
> 
> However your patch changes the location of data_dir for the
> installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.

Sure. But it doesn't matter where exactly the bits get put (and I
actually view the pace they're currently at as less consistent then
where they would end up with the patch, but admittedly that's
likely a matter of taste).

> If you are after the non-installed case, you must be already setting
> device_model_override in your VM config file to point to the right
> binary. You might as well pass:

No, I did not have to set anything like that - xl/libxl appear to
be figuring out quite fine where the binary is. Having to add such
or this ...

> device_model_args = ['-L', '/path/to/share/file' ]

... would additionally require the VM config files to be updated
each time I update to the tip of -unstable, as I'm having a date
tag somewhere in the path.

> that should solve your problem.

It certainly would, but at a price I consider too high.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 11:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se2Yf-0004om-55; Mon, 11 Jun 2012 11:13: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 1Se2Yd-0004oh-Pd
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 11:13:15 +0000
Received: from [85.158.143.35:57982] by server-3.bemta-4.messagelabs.com id
	7A/5A-05808-BC2D5DF4; Mon, 11 Jun 2012 11:13:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339413194!13160686!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11395 invoked from network); 11 Jun 2012 11:13:14 -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; 11 Jun 2012 11:13:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 12:13:13 +0100
Message-Id: <4FD5EF10020000780008932D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 12:13:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 11.06.12 at 12:54, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Fri, 8 Jun 2012, Jan Beulich wrote:
>> >>> On 08.06.12 at 13:42, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> wrote:
>> > On Fri, 8 Jun 2012, Jan Beulich wrote:
>> >> >>> On 08.06.12 at 13:11, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> >> wrote:
>> >> > On Mon, 4 Jun 2012, Jan Beulich wrote:
>> >> >> Passing $(SHAREDIR)/qemu-xen isn't compatible with the way
>> >> >> os-posix.c:os_find_datadir() works. While one would generally expect
>> >> >> that function to honour the --datadir configure option, fixing this is
>> >> >> quite a bit more involved than simply adjusting the configure options
>> >> >> to match the function's behavior (in that, for an installed binary, it
>> >> >> looks in $bindir/../share/qemu). Afaict, so far this can have worked
>> >> >> only by virtue of what CONFIG_QEMU_DATADIR points to being populated
>> >> >> due to (presumably) some other qemu instance being installed on
>> >> >> people's systems (but being absent when running qemu-system-i386 from
>> >> >> the dist/ portion of the build tree).
>> >> >> 
>> >> >> Signed-off-by: Jan Beulich <JBeulich@suse.com>
>> >> >> 
>> >> >> --- a/tools/Makefile
>> >> >> +++ b/tools/Makefile
>> >> >> @@ -155,7 +155,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>> >> >>  		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
>> >> >>  		-L$(XEN_ROOT)/tools/xenstore" \
>> >> >>  		--bindir=$(LIBEXEC) \
>> >> >> -		--datadir=$(SHAREDIR)/qemu-xen \
>> >> >> +		--datadir=$(dir $(LIBEXEC))share/qemu \
>> >> >>  		--disable-kvm \
>> >> >>  		--python=$(PYTHON) \
>> >> >>  		$(IOEMU_CONFIGURE_CROSS); \
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> 
>> >> > 
>> >> > This is a QEMU bug, so I would rather fix it there.
>> >> 
>> >> That's not as simple as you appear to think, as it would be necessary
>> >> to meaningfully express an arbitrary datadir relative to bindir.
>> >> 
>> >> > In fact the fix could be as simple as the appended patch.
>> >> > Does it work for you?
>> >> > 
>> >> > diff --git a/os-posix.c b/os-posix.c
>> >> > index dc4a6bb..d0c873d 100644
>> >> > --- a/os-posix.c
>> >> > +++ b/os-posix.c
>> >> > @@ -136,6 +136,9 @@ char *os_find_datadir(const char *argv0)
>> >> >              g_free(res);
>> >> >              res = NULL;
>> >> >          }
>> >> > +    } else {
>> >> > +        g_free(res);
>> >> > +        res = NULL;
>> >> 
>> >> How can this work? Afaict it would even break currently working
>> >> cases, as it now makes the function return NULL not only when
>> >> both access() checks failed, but also when the first one succeeded.
>> > 
>> > Yes, you are right, I misread the error condition of "access".
>> > 
>> > Like you wrote, os_find_datadir checks for the existence of
>> > $bindir/../share/qemu that normally means /usr/lib/xen/share/qemu, then
>> > it checks for /usr/lib/xen/pc-bios and if they both don't exist return
>> > NULL and data_dir is set to CONFIG_QEMU_DATADIR (that is what we want).
>> 
>> That is what you want in the installed case.
>> 
>> > While it is certainly not how I would have written this code, it should
>> > work correctly. How is that you system has /usr/lib/xen/pc-bios or
>> > /usr/lib/xen/share/qemu?
>> 
>> As I had written in the description, I'm after the non-installed
>> case instead (i.e. running from the build tree's dist/), and that
>> case can only be covered by either fixing os_find_datadir() or
>> forcing the value of --datadir to match the function's
>> expectations.
>> 
>> Additionally, for the installed case it doesn't matter where the
>> bits are put, as it'll always be the configured value that gets
>> used.
> 
> However your patch changes the location of data_dir for the
> installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.

Sure. But it doesn't matter where exactly the bits get put (and I
actually view the pace they're currently at as less consistent then
where they would end up with the patch, but admittedly that's
likely a matter of taste).

> If you are after the non-installed case, you must be already setting
> device_model_override in your VM config file to point to the right
> binary. You might as well pass:

No, I did not have to set anything like that - xl/libxl appear to
be figuring out quite fine where the binary is. Having to add such
or this ...

> device_model_args = ['-L', '/path/to/share/file' ]

... would additionally require the VM config files to be updated
each time I update to the tip of -unstable, as I'm having a date
tag somewhere in the path.

> that should solve your problem.

It certainly would, but at a price I consider too high.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 11:42:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se2z6-00052G-Fd; Mon, 11 Jun 2012 11:40:36 +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 1Se2z4-00052B-M5
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 11:40:34 +0000
Received: from [85.158.143.99:37944] by server-3.bemta-4.messagelabs.com id
	E7/AE-05808-139D5DF4; Mon, 11 Jun 2012 11:40:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339414832!25225717!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDM2Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDM2Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25604 invoked from network); 11 Jun 2012 11:40:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 11:40:33 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo27) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k01f9fo5BB6lsj
	for <xen-devel@lists.xen.org>; Mon, 11 Jun 2012 13:40:31 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 83FD918638; Mon, 11 Jun 2012 13:40:29 +0200 (CEST)
Date: Mon, 11 Jun 2012 13:40:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20120611114029.GA10576@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] using configure options to specifiy mandir,
	docdir and others
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 currently preparing a patch to install the documentation files
referenced in the various man pages.  While doing that I tried to add
the config options from configure into config/Tools.mk. But this fails
because @docdir@ expands to something like
${datadir}/doc/$PACKAGE_TARNAME instead of something useful. I see
DOCDIR and other variables are already hardcoded in Config.mk, and even
PYTHON is listed in Config.mk instead of Tools.mk.

Is there way to use the values passed to configure instead of hardcoding
them into Config.mk?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 11:42:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se2z6-00052G-Fd; Mon, 11 Jun 2012 11:40:36 +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 1Se2z4-00052B-M5
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 11:40:34 +0000
Received: from [85.158.143.99:37944] by server-3.bemta-4.messagelabs.com id
	E7/AE-05808-139D5DF4; Mon, 11 Jun 2012 11:40:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339414832!25225717!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDM2Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDM2Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25604 invoked from network); 11 Jun 2012 11:40:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 11:40:33 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo27) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k01f9fo5BB6lsj
	for <xen-devel@lists.xen.org>; Mon, 11 Jun 2012 13:40:31 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 83FD918638; Mon, 11 Jun 2012 13:40:29 +0200 (CEST)
Date: Mon, 11 Jun 2012 13:40:29 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20120611114029.GA10576@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] using configure options to specifiy mandir,
	docdir and others
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 currently preparing a patch to install the documentation files
referenced in the various man pages.  While doing that I tried to add
the config options from configure into config/Tools.mk. But this fails
because @docdir@ expands to something like
${datadir}/doc/$PACKAGE_TARNAME instead of something useful. I see
DOCDIR and other variables are already hardcoded in Config.mk, and even
PYTHON is listed in Config.mk instead of Tools.mk.

Is there way to use the values passed to configure instead of hardcoding
them into Config.mk?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 11:43:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se30E-00054k-UF; Mon, 11 Jun 2012 11:41:46 +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 1Se30C-00054W-PH
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 11:41:45 +0000
Received: from [85.158.139.83:4440] by server-4.bemta-5.messagelabs.com id
	8E/88-05858-879D5DF4; Mon, 11 Jun 2012 11:41:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339414903!29116471!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19873 invoked from network); 11 Jun 2012 11:41:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 11:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12943178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 11:41:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 12:41:43 +0100
Date: Mon, 11 Jun 2012 12:41:23 +0100
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: <4FD5EF10020000780008932D@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
	<4FD5EF10020000780008932D@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Mon, 11 Jun 2012, Jan Beulich wrote:
> > However your patch changes the location of data_dir for the
> > installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
> 
> Sure. But it doesn't matter where exactly the bits get put (and I
> actually view the pace they're currently at as less consistent then
> where they would end up with the patch, but admittedly that's
> likely a matter of taste).
> 
> > If you are after the non-installed case, you must be already setting
> > device_model_override in your VM config file to point to the right
> > binary. You might as well pass:
> 
> No, I did not have to set anything like that - xl/libxl appear to
> be figuring out quite fine where the binary is. Having to add such
> or this ...

xl loads the binary from LIBEXEC/qemu-system-i386, where LIBEXEC is
usually /usr/lib/xen/bin.  Do you set the LIBEXEC configuration
differently somewhere?


> > device_model_args = ['-L', '/path/to/share/file' ]
> 
> ... would additionally require the VM config files to be updated
> each time I update to the tip of -unstable, as I'm having a date
> tag somewhere in the path.
> 
> > that should solve your problem.
> 
> It certainly would, but at a price I consider too high.

I understand what you say, but I fail to see how you can have a working
out of the box configuration using qemu from the build tree... 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 11:43:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se30E-00054k-UF; Mon, 11 Jun 2012 11:41:46 +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 1Se30C-00054W-PH
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 11:41:45 +0000
Received: from [85.158.139.83:4440] by server-4.bemta-5.messagelabs.com id
	8E/88-05858-879D5DF4; Mon, 11 Jun 2012 11:41:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339414903!29116471!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19873 invoked from network); 11 Jun 2012 11:41:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 11:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12943178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 11:41:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 12:41:43 +0100
Date: Mon, 11 Jun 2012 12:41:23 +0100
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: <4FD5EF10020000780008932D@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
	<4FD5EF10020000780008932D@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Mon, 11 Jun 2012, Jan Beulich wrote:
> > However your patch changes the location of data_dir for the
> > installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
> 
> Sure. But it doesn't matter where exactly the bits get put (and I
> actually view the pace they're currently at as less consistent then
> where they would end up with the patch, but admittedly that's
> likely a matter of taste).
> 
> > If you are after the non-installed case, you must be already setting
> > device_model_override in your VM config file to point to the right
> > binary. You might as well pass:
> 
> No, I did not have to set anything like that - xl/libxl appear to
> be figuring out quite fine where the binary is. Having to add such
> or this ...

xl loads the binary from LIBEXEC/qemu-system-i386, where LIBEXEC is
usually /usr/lib/xen/bin.  Do you set the LIBEXEC configuration
differently somewhere?


> > device_model_args = ['-L', '/path/to/share/file' ]
> 
> ... would additionally require the VM config files to be updated
> each time I update to the tip of -unstable, as I'm having a date
> tag somewhere in the path.
> 
> > that should solve your problem.
> 
> It certainly would, but at a price I consider too high.

I understand what you say, but I fail to see how you can have a working
out of the box configuration using qemu from the build tree... 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 11:58:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se3Eo-0005LL-Cw; Mon, 11 Jun 2012 11:56:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Se3En-0005LG-Gz
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 11:56:49 +0000
Received: from [85.158.143.99:33196] by server-3.bemta-4.messagelabs.com id
	0D/CD-05808-00DD5DF4; Mon, 11 Jun 2012 11:56:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339415807!24728710!1
X-Originating-IP: [82.57.200.102]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 11 Jun 2012 11:56:47 -0000
Received: from smtp206.alice.it (HELO smtp206.alice.it) (82.57.200.102)
	by server-11.tower-216.messagelabs.com with SMTP;
	11 Jun 2012 11:56:47 -0000
Received: from [192.168.178.50] (82.60.25.40) by smtp206.alice.it (8.6.023.02)
	id 4F9BF1D305057F7A; Mon, 11 Jun 2012 13:56:43 +0200
Message-ID: <4FD5DCF7.2070103@tiscali.it>
Date: Mon, 11 Jun 2012 13:56:39 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ZhouPeng <zpengxen@gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
In-Reply-To: <CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
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="===============5379157639064068241=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============5379157639064068241==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090800020503060207080703"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090800020503060207080703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 24/05/2012 13:28, ZhouPeng ha scritto:
> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com>  wrote:
>> On Thu, 24 May 2012, ZhouPeng wrote:
>>> Sorry for late reply, I am not on this mail these days because of my =
work.
>>>
>>> I further test qxl-vga and I think I figure out the problem in some e=
xtend.
>>>
>>> If using qxl device, the default memory size of vga is 64M.
>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>
>>> The exact reason is xc_domain_populate_physmap_exact fails, because
>>> xen-hypervisor
>>> fail,
>>> it's because of   alloc_domheap_pages(d, a->extent_order, a->memflags=
)
>>> fails in hypervisor.
>>>
>>> I am not very familiar with xen's memory management, Does 64M exceed
>>> xen's heap space in this context?
>> XL sets an upper bound of memory that can be allocated to the VM in
>> libxl__build_pre, calling xc_domain_setmaxmem.
>> My guess is that a 64MB allocation would go over that limit.
>> You could try increasing the limit manually changing the
>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting=

>> videoram=3D64 in the VM config file.
> Your guess is absolutely right!
>
> But set videoram=3D128 or
> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>
> Then I successfuly install qxl driver in win-hvm and QXL can work prope=
rly.
>
> I will send some patch to add qxl support to libxl.
I tried your 3 patches taken from the mailing list, it works but doesn't =

solve qxl problems for me, on linux domU (Precise and Wheezy) xorg=20
doesn't start and on windows 7 I have heavy performance problem (unusable=
).
I tried also with qemu 1.1.0 but nothing change.
Does it work correctly for you? If so can I have some detail of your=20
configurations please?
For audio support this is needed too: (tested and working)
-device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu=20
invocation and env QEMU_AUDIO_DRV=3Dspice
Can you add audio support on libxl please?




--------------ms090800020503060207080703
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYxMTExNTYzOVowIwYJKoZIhvcNAQkEMRYEFCQZmud5fzSQWIvjvPzkSBMb
OfmmMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQAOVVcUgHFaBWRZZLl4snz2HC38FAzCoJDFh9pRl9qd
Ilcjm8kn2ahiqsDiwzDcYH6RcAkRgVmxNPBlEokqHpmfD52N4YWmCz93lHZ7Cb6jdbQZPGZD
vs/xE3rrY8yLQjFnQI7Vn5ok4gnqXyCr7ItEkJ9cBVhmQBsx0WCcTQY3vPEGSeRAZ1E5DrSv
7ISnq984T5+Vi9r1xM5vhuFEAd470QjONpFm7mYahve8kRDVYBZ+wtD7H4MogxwKaZxpnQof
CqgwWVXA6Q+9FPL4YRqV6X07d4TNQa6g3s/EEWwoiPylg5KIfs/4yvtfjoAhzeAAILiJomyg
fXTWyx5xSpF6AAAAAAAA
--------------ms090800020503060207080703--


--===============5379157639064068241==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5379157639064068241==--


From xen-devel-bounces@lists.xen.org Mon Jun 11 11:58:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 11: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 1Se3Eo-0005LL-Cw; Mon, 11 Jun 2012 11:56:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Se3En-0005LG-Gz
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 11:56:49 +0000
Received: from [85.158.143.99:33196] by server-3.bemta-4.messagelabs.com id
	0D/CD-05808-00DD5DF4; Mon, 11 Jun 2012 11:56:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339415807!24728710!1
X-Originating-IP: [82.57.200.102]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 11 Jun 2012 11:56:47 -0000
Received: from smtp206.alice.it (HELO smtp206.alice.it) (82.57.200.102)
	by server-11.tower-216.messagelabs.com with SMTP;
	11 Jun 2012 11:56:47 -0000
Received: from [192.168.178.50] (82.60.25.40) by smtp206.alice.it (8.6.023.02)
	id 4F9BF1D305057F7A; Mon, 11 Jun 2012 13:56:43 +0200
Message-ID: <4FD5DCF7.2070103@tiscali.it>
Date: Mon, 11 Jun 2012 13:56:39 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ZhouPeng <zpengxen@gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
In-Reply-To: <CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
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="===============5379157639064068241=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============5379157639064068241==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090800020503060207080703"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090800020503060207080703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 24/05/2012 13:28, ZhouPeng ha scritto:
> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com>  wrote:
>> On Thu, 24 May 2012, ZhouPeng wrote:
>>> Sorry for late reply, I am not on this mail these days because of my =
work.
>>>
>>> I further test qxl-vga and I think I figure out the problem in some e=
xtend.
>>>
>>> If using qxl device, the default memory size of vga is 64M.
>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>
>>> The exact reason is xc_domain_populate_physmap_exact fails, because
>>> xen-hypervisor
>>> fail,
>>> it's because of   alloc_domheap_pages(d, a->extent_order, a->memflags=
)
>>> fails in hypervisor.
>>>
>>> I am not very familiar with xen's memory management, Does 64M exceed
>>> xen's heap space in this context?
>> XL sets an upper bound of memory that can be allocated to the VM in
>> libxl__build_pre, calling xc_domain_setmaxmem.
>> My guess is that a 64MB allocation would go over that limit.
>> You could try increasing the limit manually changing the
>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting=

>> videoram=3D64 in the VM config file.
> Your guess is absolutely right!
>
> But set videoram=3D128 or
> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>
> Then I successfuly install qxl driver in win-hvm and QXL can work prope=
rly.
>
> I will send some patch to add qxl support to libxl.
I tried your 3 patches taken from the mailing list, it works but doesn't =

solve qxl problems for me, on linux domU (Precise and Wheezy) xorg=20
doesn't start and on windows 7 I have heavy performance problem (unusable=
).
I tried also with qemu 1.1.0 but nothing change.
Does it work correctly for you? If so can I have some detail of your=20
configurations please?
For audio support this is needed too: (tested and working)
-device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu=20
invocation and env QEMU_AUDIO_DRV=3Dspice
Can you add audio support on libxl please?




--------------ms090800020503060207080703
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYxMTExNTYzOVowIwYJKoZIhvcNAQkEMRYEFCQZmud5fzSQWIvjvPzkSBMb
OfmmMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQAOVVcUgHFaBWRZZLl4snz2HC38FAzCoJDFh9pRl9qd
Ilcjm8kn2ahiqsDiwzDcYH6RcAkRgVmxNPBlEokqHpmfD52N4YWmCz93lHZ7Cb6jdbQZPGZD
vs/xE3rrY8yLQjFnQI7Vn5ok4gnqXyCr7ItEkJ9cBVhmQBsx0WCcTQY3vPEGSeRAZ1E5DrSv
7ISnq984T5+Vi9r1xM5vhuFEAd470QjONpFm7mYahve8kRDVYBZ+wtD7H4MogxwKaZxpnQof
CqgwWVXA6Q+9FPL4YRqV6X07d4TNQa6g3s/EEWwoiPylg5KIfs/4yvtfjoAhzeAAILiJomyg
fXTWyx5xSpF6AAAAAAAA
--------------ms090800020503060207080703--


--===============5379157639064068241==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5379157639064068241==--


From xen-devel-bounces@lists.xen.org Mon Jun 11 12:20:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 12: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 1Se3bT-0005jL-2q; Mon, 11 Jun 2012 12:20:15 +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 1Se3bR-0005jG-Tt
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 12:20:14 +0000
Received: from [85.158.143.99:3135] by server-2.bemta-4.messagelabs.com id
	6A/0C-17938-D72E5DF4; Mon, 11 Jun 2012 12:20:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339417201!25234199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11055 invoked from network); 11 Jun 2012 12:20:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 12:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12944092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 12:20:01 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 13:20:01 +0100
Message-ID: <4FD5E270.4000305@citrix.com>
Date: Mon, 11 Jun 2012 13:20:00 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <20120611114029.GA10576@aepfle.de>
In-Reply-To: <20120611114029.GA10576@aepfle.de>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using configure options to specifiy mandir,
 docdir and others
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Hering wrote:
> I'm currently preparing a patch to install the documentation files
> referenced in the various man pages.  While doing that I tried to add
> the config options from configure into config/Tools.mk. But this fails
> because @docdir@ expands to something like
> ${datadir}/doc/$PACKAGE_TARNAME instead of something useful. I see

Why don't you export datadir also in Tools.mk if needed?

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Installation-Directory-Variables.html

> DOCDIR and other variables are already hardcoded in Config.mk, and even
> PYTHON is listed in Config.mk instead of Tools.mk.

PYTHON is in Config.mk because it is needed to build the hypervisor, and 
we agreed that building the hypervisor doesn't require the user to run 
the configure script.

Other paths should be in Config/Tools.mk or Config/Docs.mk (don't really 
know if we want to split this into two different files).

> Is there way to use the values passed to configure instead of hardcoding
> them into Config.mk?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 12:20:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 12: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 1Se3bT-0005jL-2q; Mon, 11 Jun 2012 12:20:15 +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 1Se3bR-0005jG-Tt
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 12:20:14 +0000
Received: from [85.158.143.99:3135] by server-2.bemta-4.messagelabs.com id
	6A/0C-17938-D72E5DF4; Mon, 11 Jun 2012 12:20:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339417201!25234199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11055 invoked from network); 11 Jun 2012 12:20:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 12:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12944092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 12:20:01 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 13:20:01 +0100
Message-ID: <4FD5E270.4000305@citrix.com>
Date: Mon, 11 Jun 2012 13:20:00 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <20120611114029.GA10576@aepfle.de>
In-Reply-To: <20120611114029.GA10576@aepfle.de>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using configure options to specifiy mandir,
 docdir and others
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Hering wrote:
> I'm currently preparing a patch to install the documentation files
> referenced in the various man pages.  While doing that I tried to add
> the config options from configure into config/Tools.mk. But this fails
> because @docdir@ expands to something like
> ${datadir}/doc/$PACKAGE_TARNAME instead of something useful. I see

Why don't you export datadir also in Tools.mk if needed?

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Installation-Directory-Variables.html

> DOCDIR and other variables are already hardcoded in Config.mk, and even
> PYTHON is listed in Config.mk instead of Tools.mk.

PYTHON is in Config.mk because it is needed to build the hypervisor, and 
we agreed that building the hypervisor doesn't require the user to run 
the configure script.

Other paths should be in Config/Tools.mk or Config/Docs.mk (don't really 
know if we want to split this into two different files).

> Is there way to use the values passed to configure instead of hardcoding
> them into Config.mk?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 12:30:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 12:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se3kt-0005sk-5H; Mon, 11 Jun 2012 12:29:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Se3kr-0005sf-Bv
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 12:29:57 +0000
Received: from [85.158.143.35:37086] by server-3.bemta-4.messagelabs.com id
	41/CE-05808-4C4E5DF4; Mon, 11 Jun 2012 12:29:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339417794!12524123!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3457 invoked from network); 11 Jun 2012 12:29:56 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jun 2012 12:29:56 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q5BCTp2M015807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 11 Jun 2012 08:29:51 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q5BCTo1F015804;
	Mon, 11 Jun 2012 08:29:50 -0400
Date: Mon, 11 Jun 2012 08:29:50 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120611122950.GA15622@andromeda.dapyr.net>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
	<20120610102347.GA14968@andromeda.dapyr.net>
	<4FD5C70F.20707@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD5C70F.20707@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
	xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 11, 2012 at 11:23:11AM +0100, David Vrabel wrote:
> On 10/06/12 11:23, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
> >>> From: David Vrabel <david.vrabel@citrix.com>
> >>>
> >>> In xen_set_pte() if batching is unavailable (because the caller is in
> >>> an interrupt context such as handling a page fault) it would fall back
> >>> to using native_set_pte() and trapping and emulating the PTE write.
> >>>
> >>> On 32-bit guests this requires two traps for each PTE write (one for
> >>> each dword of the PTE).  Instead, do one mmu_update hypercall
> >>> directly.
> >>
> >> OK.
> >>>
> >>> This significantly improves page fault performance in 32-bit PV
> >>> guests.
> >>
> >> Nice!
> > 
> > With this patch I keep on getting this (which is v3.5-rc2 plus my
> > patches in stable/for-linus-3.5 and yours):
> [...]
> > (XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
> > (XEN) mm.c:3460:d0 Could not get page for normal update
> 
> Are you talking about these?  I've not seen them.  Do you know when they
> happen?

During the bootup. I hadn't really done much investigation - but reverting
your patch (so v3.5-rc2+stable/for-linus-3.5 minus your patch) makes these
errors go away.
> 
> The patch doesn't change what PTEs are written or their value so I don't
> think I've introduced a regression -- only it now prints a new
> warning/error.

The boot doesn't finish. It keeps on printing those forever. This is
of course dom0 - I hadn't gotten to trying out a domU guest.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 12:30:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 12:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se3kt-0005sk-5H; Mon, 11 Jun 2012 12:29:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Se3kr-0005sf-Bv
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 12:29:57 +0000
Received: from [85.158.143.35:37086] by server-3.bemta-4.messagelabs.com id
	41/CE-05808-4C4E5DF4; Mon, 11 Jun 2012 12:29:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339417794!12524123!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3457 invoked from network); 11 Jun 2012 12:29:56 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jun 2012 12:29:56 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q5BCTp2M015807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 11 Jun 2012 08:29:51 -0400
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q5BCTo1F015804;
	Mon, 11 Jun 2012 08:29:50 -0400
Date: Mon, 11 Jun 2012 08:29:50 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120611122950.GA15622@andromeda.dapyr.net>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
	<20120610102347.GA14968@andromeda.dapyr.net>
	<4FD5C70F.20707@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD5C70F.20707@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
	xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 11, 2012 at 11:23:11AM +0100, David Vrabel wrote:
> On 10/06/12 11:23, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
> >>> From: David Vrabel <david.vrabel@citrix.com>
> >>>
> >>> In xen_set_pte() if batching is unavailable (because the caller is in
> >>> an interrupt context such as handling a page fault) it would fall back
> >>> to using native_set_pte() and trapping and emulating the PTE write.
> >>>
> >>> On 32-bit guests this requires two traps for each PTE write (one for
> >>> each dword of the PTE).  Instead, do one mmu_update hypercall
> >>> directly.
> >>
> >> OK.
> >>>
> >>> This significantly improves page fault performance in 32-bit PV
> >>> guests.
> >>
> >> Nice!
> > 
> > With this patch I keep on getting this (which is v3.5-rc2 plus my
> > patches in stable/for-linus-3.5 and yours):
> [...]
> > (XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
> > (XEN) mm.c:3460:d0 Could not get page for normal update
> 
> Are you talking about these?  I've not seen them.  Do you know when they
> happen?

During the bootup. I hadn't really done much investigation - but reverting
your patch (so v3.5-rc2+stable/for-linus-3.5 minus your patch) makes these
errors go away.
> 
> The patch doesn't change what PTEs are written or their value so I don't
> think I've introduced a regression -- only it now prints a new
> warning/error.

The boot doesn't finish. It keeps on printing those forever. This is
of course dom0 - I hadn't gotten to trying out a domU guest.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 12:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 12:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se3o4-0005z9-O4; Mon, 11 Jun 2012 12:33:16 +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 1Se3o2-0005z3-Kl
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 12:33:14 +0000
Received: from [85.158.139.83:39808] by server-6.bemta-5.messagelabs.com id
	95/09-18700-985E5DF4; Mon, 11 Jun 2012 12:33:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339417993!32132593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12260 invoked from network); 11 Jun 2012 12:33:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 12:33:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12944390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 12:33:13 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 13:33:13 +0100
Message-ID: <4FD5E587.8020005@citrix.com>
Date: Mon, 11 Jun 2012 13:33:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.37559.262031.887156@mariner.uk.xensource.com>
In-Reply-To: <20432.37559.262031.887156@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>
> In the subject line `asyn' should be `async'.
>
>
>> @@ -1859,11 +1883,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>>       ret = 0;
>>
>>       libxl_device_disk_remove(ctx, domid, disks + i, 0);
>> -    libxl_device_disk_add(ctx, domid, disk);
>> +    /* fixme-ao */
>> +    libxl_device_disk_add(ctx, domid, disk, 0);
>
> Is there going to be a later patch in a future version of the series
> that fixes these ?
>

Not really, but I might add one.

>
>> +/* Macro to define callbacks of libxl__add_*, checks if device is last
>> + * and calls the function passed as a parameter to this macro with the
>> + * following syntax; func(libxl__egc *, parent_type *, int rc) */
>> +#define DEFINE_DEVICES_CALLBACK(callback_name, parent_type, array_name, \
>> +                                array_size_name, func_to_call)          \
>> +    static void callback_name(libxl__egc *egc, libxl__ao_device *aodev) \
>> +    {                                                                   \
>> +        STATE_AO_GC(aodev->ao);                                         \
>> +        parent_type *p = CONTAINER_OF(aodev->base, *p, array_name);     \
>> +        int rc;                                                         \
>> +                                                                        \
>> +        rc = libxl__ao_device_check_last(gc, aodev, p->array_name,      \
>> +                                         p->array_size_name);           \
>> +        if (rc>  0) return;                                             \
>> +        func_to_call(egc, p, rc);                                       \
>> +    }
>
> This is acceptable IMO and better than the repetition.  However the
> use of a macro for this, so far from the invocation sites, is indeed
> less than perfect.
>
> Looking at the content of this macro, the only thing it needs from the
> parent is array_name and array_size_name.  If you invented
>
>      typedef struct libxl__ao_devices libxl__ao_devices;
>      struct libxl__ao_devices {
>          libxl__ao_device *array;
>          int size;
>          void (*callback)(libxl__egc*, libxl__ao_devices*, int rc);
>      };
>
> Then aodev->base could be of type libxl__ao_devices* and the macro
> above could be a function.  And indeed it would have type
> suitable for simply filling into aodev->callback.  Would that work ?

Yes, I've applied this change.

> Doing this would also perhaps mean DEFINE_DEVICES_ADD's generated
> libxl__add_FOOs functions could become one single function.  AFAICT
> the only macroish things it does are: (1) accessing
> d_config->num_FOOs, which could be passed in as a parameter;
> (2) passing d_config->FOOs[i] to libxl__device_FOO_add, which could be
> dealt with by making libxl__device_FOO_add take a void* for the config
> instead, and passing the start of the d_config->FOOs array, plus the
> element size, and the add function, as arguments.

I think this is really too complex for the benefits it introduces, 
libxl__add_{disks/nics} already takes a lot of arguments. Also take into 
account that libxl__device_disk_add is different from the rest now, 
because it takes the extra xs_transaction parameter.

> Sorry to mess you about.
>
>
> Whether you retain this as a macro or make it a function,
>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 2dc1cee..1dc8247 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -585,6 +585,13 @@ DEFINE_DEVICES_CALLBACK(domcreate_disk_connected,
>>                           libxl__domain_create_state,
>>                           devices, num_devices, domcreate_launch_dm)
>>
>> +static void domcreate_attach_pci(libxl__egc *egc,
>> +                                 libxl__domain_create_state *dcs, int rc);
>> +
>> +DEFINE_DEVICES_CALLBACK(domcreate_nic_connected,
>> +                        libxl__domain_create_state,
>> +                        devices, num_devices, domcreate_attach_pci)
>> +
>>   static void domcreate_console_available(libxl__egc *egc,
>>                                           libxl__domain_create_state *dcs);
>>
>
> These seem not to be in linear execution order ?  These kind of
> arrangements with a chain of callbacks should really have both the
> declarations and the definitions in linear order.  Sadly that means
> writing out the declarations of domcreate_nic_connected etc. here in
> the declarations section but I think that's a price worth paying.
> (This is something you'd have to do anyway if you replace the macro
> with a function as I suggest.)

Done.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 12:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 12:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se3o4-0005z9-O4; Mon, 11 Jun 2012 12:33:16 +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 1Se3o2-0005z3-Kl
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 12:33:14 +0000
Received: from [85.158.139.83:39808] by server-6.bemta-5.messagelabs.com id
	95/09-18700-985E5DF4; Mon, 11 Jun 2012 12:33:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339417993!32132593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12260 invoked from network); 11 Jun 2012 12:33:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 12:33:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,749,1330905600"; d="scan'208";a="12944390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 12:33:13 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 13:33:13 +0100
Message-ID: <4FD5E587.8020005@citrix.com>
Date: Mon, 11 Jun 2012 13:33:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-5-git-send-email-roger.pau@citrix.com>
	<20432.37559.262031.887156@mariner.uk.xensource.com>
In-Reply-To: <20432.37559.262031.887156@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 04/10] libxl: convert
 libxl_device_disk_add to an asyn op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 04/10] libxl: convert libxl_device_disk_add to an asyn op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>
> In the subject line `asyn' should be `async'.
>
>
>> @@ -1859,11 +1883,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>>       ret = 0;
>>
>>       libxl_device_disk_remove(ctx, domid, disks + i, 0);
>> -    libxl_device_disk_add(ctx, domid, disk);
>> +    /* fixme-ao */
>> +    libxl_device_disk_add(ctx, domid, disk, 0);
>
> Is there going to be a later patch in a future version of the series
> that fixes these ?
>

Not really, but I might add one.

>
>> +/* Macro to define callbacks of libxl__add_*, checks if device is last
>> + * and calls the function passed as a parameter to this macro with the
>> + * following syntax; func(libxl__egc *, parent_type *, int rc) */
>> +#define DEFINE_DEVICES_CALLBACK(callback_name, parent_type, array_name, \
>> +                                array_size_name, func_to_call)          \
>> +    static void callback_name(libxl__egc *egc, libxl__ao_device *aodev) \
>> +    {                                                                   \
>> +        STATE_AO_GC(aodev->ao);                                         \
>> +        parent_type *p = CONTAINER_OF(aodev->base, *p, array_name);     \
>> +        int rc;                                                         \
>> +                                                                        \
>> +        rc = libxl__ao_device_check_last(gc, aodev, p->array_name,      \
>> +                                         p->array_size_name);           \
>> +        if (rc>  0) return;                                             \
>> +        func_to_call(egc, p, rc);                                       \
>> +    }
>
> This is acceptable IMO and better than the repetition.  However the
> use of a macro for this, so far from the invocation sites, is indeed
> less than perfect.
>
> Looking at the content of this macro, the only thing it needs from the
> parent is array_name and array_size_name.  If you invented
>
>      typedef struct libxl__ao_devices libxl__ao_devices;
>      struct libxl__ao_devices {
>          libxl__ao_device *array;
>          int size;
>          void (*callback)(libxl__egc*, libxl__ao_devices*, int rc);
>      };
>
> Then aodev->base could be of type libxl__ao_devices* and the macro
> above could be a function.  And indeed it would have type
> suitable for simply filling into aodev->callback.  Would that work ?

Yes, I've applied this change.

> Doing this would also perhaps mean DEFINE_DEVICES_ADD's generated
> libxl__add_FOOs functions could become one single function.  AFAICT
> the only macroish things it does are: (1) accessing
> d_config->num_FOOs, which could be passed in as a parameter;
> (2) passing d_config->FOOs[i] to libxl__device_FOO_add, which could be
> dealt with by making libxl__device_FOO_add take a void* for the config
> instead, and passing the start of the d_config->FOOs array, plus the
> element size, and the add function, as arguments.

I think this is really too complex for the benefits it introduces, 
libxl__add_{disks/nics} already takes a lot of arguments. Also take into 
account that libxl__device_disk_add is different from the rest now, 
because it takes the extra xs_transaction parameter.

> Sorry to mess you about.
>
>
> Whether you retain this as a macro or make it a function,
>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 2dc1cee..1dc8247 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -585,6 +585,13 @@ DEFINE_DEVICES_CALLBACK(domcreate_disk_connected,
>>                           libxl__domain_create_state,
>>                           devices, num_devices, domcreate_launch_dm)
>>
>> +static void domcreate_attach_pci(libxl__egc *egc,
>> +                                 libxl__domain_create_state *dcs, int rc);
>> +
>> +DEFINE_DEVICES_CALLBACK(domcreate_nic_connected,
>> +                        libxl__domain_create_state,
>> +                        devices, num_devices, domcreate_attach_pci)
>> +
>>   static void domcreate_console_available(libxl__egc *egc,
>>                                           libxl__domain_create_state *dcs);
>>
>
> These seem not to be in linear execution order ?  These kind of
> arrangements with a chain of callbacks should really have both the
> declarations and the definitions in linear order.  Sadly that means
> writing out the declarations of domcreate_nic_connected etc. here in
> the declarations section but I think that's a price worth paying.
> (This is something you'd have to do anyway if you replace the macro
> with a function as I suggest.)

Done.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 13:42:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13: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 1Se4sS-0006W9-Vx; Mon, 11 Jun 2012 13:41:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Se4sR-0006Vy-5L
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 13:41:51 +0000
Received: from [193.109.254.147:62898] by server-9.bemta-14.messagelabs.com id
	8E/EC-27072-E95F5DF4; Mon, 11 Jun 2012 13:41:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339422107!9216921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16427 invoked from network); 11 Jun 2012 13:41:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 13:41:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12946660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 13:41:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 14:41:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Se4sG-0007Cn-NZ; Mon, 11 Jun 2012 13:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Se4sG-0004J0-Jn;
	Mon, 11 Jun 2012 14:41:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20437.62868.542710.418122@mariner.uk.xensource.com>
Date: Mon, 11 Jun 2012 14:41:40 +0100
To: "W. Michael Petullo" <mike@flyn.org>
In-Reply-To: <20120608183106.GA12674@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
	<20432.59361.773966.629519@mariner.uk.xensource.com>
	<20120608183106.GA12674@imp.flyn.org>
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] Using "xl create" without domain 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

W. Michael Petullo writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
> [...]
> > Another alternative would be to special-case the string "/dev/null"
> > (in xl, not libxl) and not read a config file at all in that case.
> 
> This patch treats /dev/null as a special case.

Thanks, this is going in the right direction I think.  Just two
niggles:

> diff -r 435493696053 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri May 25 08:18:47 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 07 22:40:58 2012 -0500
> @@ -1454,10 +1454,13 @@ static int create_domain(struct domain_c
> 
>      if (config_file) {
>          free(config_data);  config_data = 0;
...
> +        // /dev/null represents special case (read config. from command line)

libxl coding style uses /*...*/ comments.

> +        if (strcmp(config_file, "/dev/null")) {
> +            ret = libxl_read_file_contents(&ctx, config_file,
> +                                           &config_data, &config_len);

I think this fails to set config_len to 0 in the /dev/null case, which
it should do.  Although config_len is initialised to 0 it may have
been set to a non-0 value from the length of the old config file if
we're doing a restore, and in this case it needs to be rezeroed.

> +            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
> +                               config_file, strerror(errno)); return ERROR_FAIL; }
> +        }
>          if (!restore_file && extra_config && strlen(extra_config)) {
>              if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
>                  fprintf(stderr, "Failed to attach extra configration\n");

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 Jun 11 13:42:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13: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 1Se4sS-0006W9-Vx; Mon, 11 Jun 2012 13:41:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Se4sR-0006Vy-5L
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 13:41:51 +0000
Received: from [193.109.254.147:62898] by server-9.bemta-14.messagelabs.com id
	8E/EC-27072-E95F5DF4; Mon, 11 Jun 2012 13:41:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339422107!9216921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16427 invoked from network); 11 Jun 2012 13:41:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 13:41:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12946660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 13:41:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 14:41:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Se4sG-0007Cn-NZ; Mon, 11 Jun 2012 13:41:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Se4sG-0004J0-Jn;
	Mon, 11 Jun 2012 14:41:40 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20437.62868.542710.418122@mariner.uk.xensource.com>
Date: Mon, 11 Jun 2012 14:41:40 +0100
To: "W. Michael Petullo" <mike@flyn.org>
In-Reply-To: <20120608183106.GA12674@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
	<20432.59361.773966.629519@mariner.uk.xensource.com>
	<20120608183106.GA12674@imp.flyn.org>
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] Using "xl create" without domain 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

W. Michael Petullo writes ("Re: [Xen-devel] Using "xl create" without domain config file"):
> [...]
> > Another alternative would be to special-case the string "/dev/null"
> > (in xl, not libxl) and not read a config file at all in that case.
> 
> This patch treats /dev/null as a special case.

Thanks, this is going in the right direction I think.  Just two
niggles:

> diff -r 435493696053 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri May 25 08:18:47 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 07 22:40:58 2012 -0500
> @@ -1454,10 +1454,13 @@ static int create_domain(struct domain_c
> 
>      if (config_file) {
>          free(config_data);  config_data = 0;
...
> +        // /dev/null represents special case (read config. from command line)

libxl coding style uses /*...*/ comments.

> +        if (strcmp(config_file, "/dev/null")) {
> +            ret = libxl_read_file_contents(&ctx, config_file,
> +                                           &config_data, &config_len);

I think this fails to set config_len to 0 in the /dev/null case, which
it should do.  Although config_len is initialised to 0 it may have
been set to a non-0 value from the length of the old config file if
we're doing a restore, and in this case it needs to be rezeroed.

> +            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
> +                               config_file, strerror(errno)); return ERROR_FAIL; }
> +        }
>          if (!restore_file && extra_config && strlen(extra_config)) {
>              if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
>                  fprintf(stderr, "Failed to attach extra configration\n");

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 Jun 11 13:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se4y2-0006nM-Om; Mon, 11 Jun 2012 13:47:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Se4y0-0006nD-QQ
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 13:47:37 +0000
Received: from [85.158.139.83:30001] by server-8.bemta-5.messagelabs.com id
	1D/C9-02058-7F6F5DF4; Mon, 11 Jun 2012 13:47:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339422455!19184199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23523 invoked from network); 11 Jun 2012 13:47:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 13:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12946839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 13:47:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 14:47:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Se4xy-0007Es-Me; Mon, 11 Jun 2012 13:47:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Se4xy-0004JY-Lf;
	Mon, 11 Jun 2012 14:47:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20437.63222.655663.76990@mariner.uk.xensource.com>
Date: Mon, 11 Jun 2012 14:47:34 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@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>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> On Fri, 8 Jun 2012, Ian Jackson wrote:
> > So what is the default configuration ?
> 
> The default is on.
>
> > Do we have any protection from
> > possible bugs in the virtfs access control system ?
> 
> Nothing more and nothing less than QEMU 1.0 stable provides.

That situation seems like a release-critical bug from our point of
view.

And this is relevant because we're now using upstream qemu 1.0 by
default for some guests.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 13:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se4y2-0006nM-Om; Mon, 11 Jun 2012 13:47:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Se4y0-0006nD-QQ
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 13:47:37 +0000
Received: from [85.158.139.83:30001] by server-8.bemta-5.messagelabs.com id
	1D/C9-02058-7F6F5DF4; Mon, 11 Jun 2012 13:47:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339422455!19184199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23523 invoked from network); 11 Jun 2012 13:47:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 13:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12946839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 13:47:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 14:47:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Se4xy-0007Es-Me; Mon, 11 Jun 2012 13:47:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Se4xy-0004JY-Lf;
	Mon, 11 Jun 2012 14:47:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20437.63222.655663.76990@mariner.uk.xensource.com>
Date: Mon, 11 Jun 2012 14:47:34 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@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>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> On Fri, 8 Jun 2012, Ian Jackson wrote:
> > So what is the default configuration ?
> 
> The default is on.
>
> > Do we have any protection from
> > possible bugs in the virtfs access control system ?
> 
> Nothing more and nothing less than QEMU 1.0 stable provides.

That situation seems like a release-critical bug from our point of
view.

And this is relevant because we're now using upstream qemu 1.0 by
default for some guests.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 13:57:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13:57: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 1Se57R-00072E-Oz; Mon, 11 Jun 2012 13:57:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Se57R-000728-Bj
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 13:57:21 +0000
Received: from [85.158.143.35:59806] by server-3.bemta-4.messagelabs.com id
	D4/62-05808-049F5DF4; Mon, 11 Jun 2012 13:57:20 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339423037!15699897!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4604 invoked from network); 11 Jun 2012 13:57:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 13:57:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BDvDdv025243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 13:57: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
	q5BDvDY5024681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 13:57:13 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
	q5BDvCOi001311; Mon, 11 Jun 2012 08:57:12 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 06:57:12 -0700
MIME-Version: 1.0
X-Mercurial-Node: eb72d7090b5956490b2f26c858cd9d896feca309
Message-Id: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 11 Jun 2012 09:59:32 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1339421383 14400
# Node ID eb72d7090b5956490b2f26c858cd9d896feca309
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools/hotplug: fix locking

The current locking implementation would allow two processes get the lock
simultaneously:

++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 5 -gt 5 ']'
+ sleep 0
+ retries=6
+ '[' 6 -lt 100 ']'
+ mkdir /var/run/xen-hotplug/block
++ _lock_owner /var/run/xen-hotplug/block
++ cat /var/run/xen-hotplug/block/owner
+ local 'new_owner=16741: /etc/xen/scripts/block'
+ '[' '16741: /etc/xen/scripts/block' '!=' '16741: /etc/xen/scripts/block' ']'
++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 6 -gt 5 ']'
+ sleep 1
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ xenstore_write backend/vbd/33/51920/node /dev/loop27
+ _xenstore_write backend/vbd/33/51920/node /dev/loop27
+ log debug 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
ioctl: LOOP_SET_FD: Device or resource busy
+ xenstore-write backend/vbd/33/51920/node /dev/loop27
+ fatal losetup -r /dev/loop27 '/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img failed'

This patch removes the ownner support and fixed this issue per my test.

Kouya: would you please help to confirm this fix is correct?

Anyone has encountered this issue please help to test.

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Kouya Shimura <kouya@jp.fujitsu.com>

diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
@@ -48,32 +48,14 @@ sigerr() {
 _claim_lock()
 {
   local lockdir="$1"
-  local owner=$(_lock_owner "$lockdir")
   local retries=0
 
   while [ $retries -lt $LOCK_RETRIES ]
   do
-    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
-      _update_lock_info "$lockdir" && return
-
-    local new_owner=$(_lock_owner "$lockdir")
-    if [ "$new_owner" != "$owner" ]
-    then
-      owner="$new_owner"
-      retries=0
-    else
-      local pid=$(echo $owner | cut -d : -f 1)
-      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
-      then
-        _release_lock $lockdir
-      fi
-    fi
-
+    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
     if [ $retries -gt $LOCK_SPINNING_RETRIES ]
     then
       sleep $LOCK_SLEEPTIME
-    else
-      sleep 0
     fi
     retries=$(($retries + 1))
   done
@@ -91,20 +73,7 @@ _release_lock()
 _steal_lock()
 {
   local lockdir="$1"
-  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
-  log err "Forced to steal lock on $lockdir from $owner!"
+  log err "Forced to steal lock on $lockdir!"
   _release_lock "$lockdir"
   _claim_lock "$lockdir"
 }
-
-
-_lock_owner()
-{
-  cat "$1/owner" 2>/dev/null || echo "unknown"
-}
-
-
-_update_lock_info()
-{
-  echo "$$: $0" >"$1/owner"
-}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 13:57:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13:57: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 1Se57R-00072E-Oz; Mon, 11 Jun 2012 13:57:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Se57R-000728-Bj
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 13:57:21 +0000
Received: from [85.158.143.35:59806] by server-3.bemta-4.messagelabs.com id
	D4/62-05808-049F5DF4; Mon, 11 Jun 2012 13:57:20 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339423037!15699897!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4604 invoked from network); 11 Jun 2012 13:57:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 13:57:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BDvDdv025243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 13:57: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
	q5BDvDY5024681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 13:57:13 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
	q5BDvCOi001311; Mon, 11 Jun 2012 08:57:12 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 06:57:12 -0700
MIME-Version: 1.0
X-Mercurial-Node: eb72d7090b5956490b2f26c858cd9d896feca309
Message-Id: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 11 Jun 2012 09:59:32 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1339421383 14400
# Node ID eb72d7090b5956490b2f26c858cd9d896feca309
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools/hotplug: fix locking

The current locking implementation would allow two processes get the lock
simultaneously:

++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 5 -gt 5 ']'
+ sleep 0
+ retries=6
+ '[' 6 -lt 100 ']'
+ mkdir /var/run/xen-hotplug/block
++ _lock_owner /var/run/xen-hotplug/block
++ cat /var/run/xen-hotplug/block/owner
+ local 'new_owner=16741: /etc/xen/scripts/block'
+ '[' '16741: /etc/xen/scripts/block' '!=' '16741: /etc/xen/scripts/block' ']'
++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 6 -gt 5 ']'
+ sleep 1
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ xenstore_write backend/vbd/33/51920/node /dev/loop27
+ _xenstore_write backend/vbd/33/51920/node /dev/loop27
+ log debug 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
ioctl: LOOP_SET_FD: Device or resource busy
+ xenstore-write backend/vbd/33/51920/node /dev/loop27
+ fatal losetup -r /dev/loop27 '/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img failed'

This patch removes the ownner support and fixed this issue per my test.

Kouya: would you please help to confirm this fix is correct?

Anyone has encountered this issue please help to test.

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Kouya Shimura <kouya@jp.fujitsu.com>

diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
@@ -48,32 +48,14 @@ sigerr() {
 _claim_lock()
 {
   local lockdir="$1"
-  local owner=$(_lock_owner "$lockdir")
   local retries=0
 
   while [ $retries -lt $LOCK_RETRIES ]
   do
-    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
-      _update_lock_info "$lockdir" && return
-
-    local new_owner=$(_lock_owner "$lockdir")
-    if [ "$new_owner" != "$owner" ]
-    then
-      owner="$new_owner"
-      retries=0
-    else
-      local pid=$(echo $owner | cut -d : -f 1)
-      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
-      then
-        _release_lock $lockdir
-      fi
-    fi
-
+    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
     if [ $retries -gt $LOCK_SPINNING_RETRIES ]
     then
       sleep $LOCK_SLEEPTIME
-    else
-      sleep 0
     fi
     retries=$(($retries + 1))
   done
@@ -91,20 +73,7 @@ _release_lock()
 _steal_lock()
 {
   local lockdir="$1"
-  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
-  log err "Forced to steal lock on $lockdir from $owner!"
+  log err "Forced to steal lock on $lockdir!"
   _release_lock "$lockdir"
   _claim_lock "$lockdir"
 }
-
-
-_lock_owner()
-{
-  cat "$1/owner" 2>/dev/null || echo "unknown"
-}
-
-
-_update_lock_info()
-{
-  echo "$$: $0" >"$1/owner"
-}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 13:59:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13:59: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 1Se58m-00076M-8f; Mon, 11 Jun 2012 13:58: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 1Se58k-00076A-OB
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 13:58:42 +0000
Received: from [85.158.143.35:63243] by server-1.bemta-4.messagelabs.com id
	C6/CA-24392-099F5DF4; Mon, 11 Jun 2012 13:58:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339423119!12543833!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23295 invoked from network); 11 Jun 2012 13:58:39 -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; 11 Jun 2012 13:58:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 14:58:39 +0100
Message-Id: <4FD615D902000078000893A3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 14:59:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
	<4FD5EF10020000780008932D@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 11.06.12 at 13:41, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Mon, 11 Jun 2012, Jan Beulich wrote:
>> > However your patch changes the location of data_dir for the
>> > installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
>> 
>> Sure. But it doesn't matter where exactly the bits get put (and I
>> actually view the pace they're currently at as less consistent then
>> where they would end up with the patch, but admittedly that's
>> likely a matter of taste).
>> 
>> > If you are after the non-installed case, you must be already setting
>> > device_model_override in your VM config file to point to the right
>> > binary. You might as well pass:
>> 
>> No, I did not have to set anything like that - xl/libxl appear to
>> be figuring out quite fine where the binary is. Having to add such
>> or this ...
> 
> xl loads the binary from LIBEXEC/qemu-system-i386, where LIBEXEC is
> usually /usr/lib/xen/bin.  Do you set the LIBEXEC configuration
> differently somewhere?

Not directly - I'm patching Config.mk:buildmakevars2file:

@@ -143,7 +143,7 @@ define buildmakevars2file-closure
 	          SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR     \
 	          XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
 	          XEN_RUN_DIR XEN_PAGING_DIR,                               \
-	          echo "$(var)=\"$($(var))\"" >>$(1).tmp;)        \
+	          echo "$(var)=\"$(DESTDIR)$($(var))\"" >>$(1).tmp;)        \
 	$(call move-if-changed,$(1).tmp,$(1))
 endef
 
>> > device_model_args = ['-L', '/path/to/share/file' ]
>> 
>> ... would additionally require the VM config files to be updated
>> each time I update to the tip of -unstable, as I'm having a date
>> tag somewhere in the path.
>> 
>> > that should solve your problem.
>> 
>> It certainly would, but at a price I consider too high.
> 
> I understand what you say, but I fail to see how you can have a working
> out of the box configuration using qemu from the build tree... 

Correct, without above patch (inherited from xend days) this
presumably wouldn't work. But it really should (and should always
have also for xend/xm), but for making it work both in the not-
installed and installed cases, much more than the above patch is
going to be needed afaict.

So in the end I assume I'll have to carry that hunk we're discussing
here alongside the other adjustment...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 13:59:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 13:59: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 1Se58m-00076M-8f; Mon, 11 Jun 2012 13:58: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 1Se58k-00076A-OB
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 13:58:42 +0000
Received: from [85.158.143.35:63243] by server-1.bemta-4.messagelabs.com id
	C6/CA-24392-099F5DF4; Mon, 11 Jun 2012 13:58:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339423119!12543833!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0OTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23295 invoked from network); 11 Jun 2012 13:58:39 -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; 11 Jun 2012 13:58:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 11 Jun 2012 14:58:39 +0100
Message-Id: <4FD615D902000078000893A3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 11 Jun 2012 14:59:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
	<4FD5EF10020000780008932D@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 11.06.12 at 13:41, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Mon, 11 Jun 2012, Jan Beulich wrote:
>> > However your patch changes the location of data_dir for the
>> > installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
>> 
>> Sure. But it doesn't matter where exactly the bits get put (and I
>> actually view the pace they're currently at as less consistent then
>> where they would end up with the patch, but admittedly that's
>> likely a matter of taste).
>> 
>> > If you are after the non-installed case, you must be already setting
>> > device_model_override in your VM config file to point to the right
>> > binary. You might as well pass:
>> 
>> No, I did not have to set anything like that - xl/libxl appear to
>> be figuring out quite fine where the binary is. Having to add such
>> or this ...
> 
> xl loads the binary from LIBEXEC/qemu-system-i386, where LIBEXEC is
> usually /usr/lib/xen/bin.  Do you set the LIBEXEC configuration
> differently somewhere?

Not directly - I'm patching Config.mk:buildmakevars2file:

@@ -143,7 +143,7 @@ define buildmakevars2file-closure
 	          SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR     \
 	          XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
 	          XEN_RUN_DIR XEN_PAGING_DIR,                               \
-	          echo "$(var)=\"$($(var))\"" >>$(1).tmp;)        \
+	          echo "$(var)=\"$(DESTDIR)$($(var))\"" >>$(1).tmp;)        \
 	$(call move-if-changed,$(1).tmp,$(1))
 endef
 
>> > device_model_args = ['-L', '/path/to/share/file' ]
>> 
>> ... would additionally require the VM config files to be updated
>> each time I update to the tip of -unstable, as I'm having a date
>> tag somewhere in the path.
>> 
>> > that should solve your problem.
>> 
>> It certainly would, but at a price I consider too high.
> 
> I understand what you say, but I fail to see how you can have a working
> out of the box configuration using qemu from the build tree... 

Correct, without above patch (inherited from xend days) this
presumably wouldn't work. But it really should (and should always
have also for xend/xm), but for making it work both in the not-
installed and installed cases, much more than the above patch is
going to be needed afaict.

So in the end I assume I'll have to carry that hunk we're discussing
here alongside the other adjustment...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 14:05:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 14:05: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 1Se5FA-0007Sp-8E; Mon, 11 Jun 2012 14:05: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 1Se5F8-0007Sk-SF
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 14:05:19 +0000
Received: from [85.158.143.35:5899] by server-3.bemta-4.messagelabs.com id
	BF/E1-05808-C1BF5DF4; Mon, 11 Jun 2012 14:05:16 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339423506!14479113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18961 invoked from network); 11 Jun 2012 14:05:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 14:05:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12947333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 14:05:05 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 15:05:05 +0100
Message-ID: <4FD5FB10.2090406@citrix.com>
Date: Mon, 11 Jun 2012 15:05:04 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1337184716-49276-1-git-send-email-roger.pau@citrix.com>
	<1337184716-49276-12-git-send-email-roger.pau@citrix.com>
	<20406.31676.266501.253510@mariner.uk.xensource.com>
	<4FBA6D52.9050809@citrix.com>
	<20420.57290.841831.831419@mariner.uk.xensource.com>
	<1338302817.14158.120.camel@zakaz.uk.xensource.com>
	<4FC60CA8.4090404@citrix.com>
	<20432.47897.707481.695066@mariner.uk.xensource.com>
In-Reply-To: <20432.47897.707481.695066@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF by default"):
>> If this is right, I have to change my hotplug patches, but this will be
>> a mess, because I have no way to tell if a domain is PV or HVM when
>> plugging in the devices, so if VIF is passed for both PV or PV+TAP I
>> will have no way of knowing that.
>
> Hmmm.
>
>> Should we create three different nic types? VIF (PV), IOEMU (TAP),
>> HYBRID (PV+TAP)?
>
> I think this might be better.  Or alternatively, always provide PV,
> and have a flag which says `do provide ioemu'.

This looks reasonable given the current types of nic interfaces.

>
> I think it's very confusing if setting the `type' to `ioemu' rather
> than `pv' means `do provide pv but provide ioemu as well'.
>
> Another way of looking at it is: if we wanted to provide some other
> interfaces (besides Xen PV and emulated PCI) in the future, would it
> be an alternative to PV or to PCI or something additional ?

I have no idea, could someone shed some light on this?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 14:05:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 14:05: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 1Se5FA-0007Sp-8E; Mon, 11 Jun 2012 14:05: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 1Se5F8-0007Sk-SF
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 14:05:19 +0000
Received: from [85.158.143.35:5899] by server-3.bemta-4.messagelabs.com id
	BF/E1-05808-C1BF5DF4; Mon, 11 Jun 2012 14:05:16 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339423506!14479113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18961 invoked from network); 11 Jun 2012 14:05:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 14:05:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12947333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 14:05:05 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 15:05:05 +0100
Message-ID: <4FD5FB10.2090406@citrix.com>
Date: Mon, 11 Jun 2012 15:05:04 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1337184716-49276-1-git-send-email-roger.pau@citrix.com>
	<1337184716-49276-12-git-send-email-roger.pau@citrix.com>
	<20406.31676.266501.253510@mariner.uk.xensource.com>
	<4FBA6D52.9050809@citrix.com>
	<20420.57290.841831.831419@mariner.uk.xensource.com>
	<1338302817.14158.120.camel@zakaz.uk.xensource.com>
	<4FC60CA8.4090404@citrix.com>
	<20432.47897.707481.695066@mariner.uk.xensource.com>
In-Reply-To: <20432.47897.707481.695066@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 11/13] libxl: set nic type to VIF by default"):
>> If this is right, I have to change my hotplug patches, but this will be
>> a mess, because I have no way to tell if a domain is PV or HVM when
>> plugging in the devices, so if VIF is passed for both PV or PV+TAP I
>> will have no way of knowing that.
>
> Hmmm.
>
>> Should we create three different nic types? VIF (PV), IOEMU (TAP),
>> HYBRID (PV+TAP)?
>
> I think this might be better.  Or alternatively, always provide PV,
> and have a flag which says `do provide ioemu'.

This looks reasonable given the current types of nic interfaces.

>
> I think it's very confusing if setting the `type' to `ioemu' rather
> than `pv' means `do provide pv but provide ioemu as well'.
>
> Another way of looking at it is: if we wanted to provide some other
> interfaces (besides Xen PV and emulated PCI) in the future, would it
> be an alternative to PV or to PCI or something additional ?

I have no idea, could someone shed some light on this?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 14:35:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 14:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se5hc-00081i-O5; Mon, 11 Jun 2012 14:34:44 +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 1Se5ha-00081d-UQ
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 14:34:43 +0000
Received: from [85.158.143.99:40709] by server-2.bemta-4.messagelabs.com id
	49/28-17938-20206DF4; Mon, 11 Jun 2012 14:34:42 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339425281!25262162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28103 invoked from network); 11 Jun 2012 14:34:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 14:34:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12948212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 14:34:41 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 15:34:41 +0100
Message-ID: <4FD60200.2030802@citrix.com>
Date: Mon, 11 Jun 2012 15:34:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
	<20432.48963.214910.33148@mariner.uk.xensource.com>
In-Reply-To: <20432.48963.214910.33148@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
>> Since most of the needed work is already done in previous patches,
>> this patch only contains the necessary code to call hotplug scripts
>> for nic devices, that should be called when the device is added or
>> removed from a guest.
>
>> @@ -1894,10 +1897,19 @@ _hidden void libxl__initiate_device_remove(libxl__egc *egc,
>>    *<  0: Error
>>    * 0: No need to execute hotplug script
>>    * 1: Execute hotplug script
>> + *
>> + * The last parameter, "num_exec" refeers to the number of times hotplug
>> + * scripts have been called for this device. This is currently used for
>> + * IOEMU nic interfaces on Linux, since we need to call hotplug scripts twice
>> + * for the same device, the first one to add the vif interface, and the second
>> + * time to add the tap interface, so:
>> + * num_exec == 0: execute hotplug for vif interface.
>> + * num_exec == 1: execute hotplug for the associated tap interface.
>>    */
>
> I think you should add:
>
>      * The main body of libxl will, for each device, keep calling
>      * libxl__get_hotplug_script_info, with incrementing values of
>      * num_exec, and executing the resulting script accordingly,
>      * until libxl__get_hotplug_script_info returns<=0.
>
> Or
>
>      * The main body of libxl will call libxl__get_hotplug_script_info
>      * with exactly the stated values of num_exec, above.  For device
>      * types not mentioned the main body calls it once with
>      * num_exec==0.
>
> Personally I'm inclined think the knowledge that nics need two
> invocations while disks need only one should be confined to the
> non-portable Linux code.  Or do you think different platforms will
> always do this the same way ?  It seems a bit odd to have the
> information about num_exec spread about like this.  So I would prefer
> the former comment (and the corresponding change to the code).
>
> That also avoids a nic-specific section in the main body of libxl's
> hotplug script machinery.


What do you think about having a function in the non-portable code that 
tells you the number of times you have to call 
libxl__get_hotplug_script_info? So we can do something like:

aodev->total_exec = libxl__get_hotplug_num_exec(...)

It's not pretty, but at least will allow us to abstract this code from 
Linux/NetBSD, since what I basically do now with NetBSD is return 0 on 
the second call, thus avoiding executing anything. But we still have the 
ugly Linux part of the code in libxl_device.

>> +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
>> +{
> ...
>> +    }
>> +
>> +out:
>> +    return rc;
>> +}
>> +
>
> As a matter of good practice I think you should say
>        rc = 0;
> just before out, on the success path, and not rely on it having
> happened to be set to 0 by the previous successful call.
>
> 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 Jun 11 14:35:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 14:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Se5hc-00081i-O5; Mon, 11 Jun 2012 14:34:44 +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 1Se5ha-00081d-UQ
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 14:34:43 +0000
Received: from [85.158.143.99:40709] by server-2.bemta-4.messagelabs.com id
	49/28-17938-20206DF4; Mon, 11 Jun 2012 14:34:42 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339425281!25262162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28103 invoked from network); 11 Jun 2012 14:34:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 14:34:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12948212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 14:34:41 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 15:34:41 +0100
Message-ID: <4FD60200.2030802@citrix.com>
Date: Mon, 11 Jun 2012 15:34:40 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
	<20432.48963.214910.33148@mariner.uk.xensource.com>
In-Reply-To: <20432.48963.214910.33148@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
>> Since most of the needed work is already done in previous patches,
>> this patch only contains the necessary code to call hotplug scripts
>> for nic devices, that should be called when the device is added or
>> removed from a guest.
>
>> @@ -1894,10 +1897,19 @@ _hidden void libxl__initiate_device_remove(libxl__egc *egc,
>>    *<  0: Error
>>    * 0: No need to execute hotplug script
>>    * 1: Execute hotplug script
>> + *
>> + * The last parameter, "num_exec" refeers to the number of times hotplug
>> + * scripts have been called for this device. This is currently used for
>> + * IOEMU nic interfaces on Linux, since we need to call hotplug scripts twice
>> + * for the same device, the first one to add the vif interface, and the second
>> + * time to add the tap interface, so:
>> + * num_exec == 0: execute hotplug for vif interface.
>> + * num_exec == 1: execute hotplug for the associated tap interface.
>>    */
>
> I think you should add:
>
>      * The main body of libxl will, for each device, keep calling
>      * libxl__get_hotplug_script_info, with incrementing values of
>      * num_exec, and executing the resulting script accordingly,
>      * until libxl__get_hotplug_script_info returns<=0.
>
> Or
>
>      * The main body of libxl will call libxl__get_hotplug_script_info
>      * with exactly the stated values of num_exec, above.  For device
>      * types not mentioned the main body calls it once with
>      * num_exec==0.
>
> Personally I'm inclined think the knowledge that nics need two
> invocations while disks need only one should be confined to the
> non-portable Linux code.  Or do you think different platforms will
> always do this the same way ?  It seems a bit odd to have the
> information about num_exec spread about like this.  So I would prefer
> the former comment (and the corresponding change to the code).
>
> That also avoids a nic-specific section in the main body of libxl's
> hotplug script machinery.


What do you think about having a function in the non-portable code that 
tells you the number of times you have to call 
libxl__get_hotplug_script_info? So we can do something like:

aodev->total_exec = libxl__get_hotplug_num_exec(...)

It's not pretty, but at least will allow us to abstract this code from 
Linux/NetBSD, since what I basically do now with NetBSD is return 0 on 
the second call, thus avoiding executing anything. But we still have the 
ugly Linux part of the code in libxl_device.

>> +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
>> +{
> ...
>> +    }
>> +
>> +out:
>> +    return rc;
>> +}
>> +
>
> As a matter of good practice I think you should say
>        rc = 0;
> just before out, on the success path, and not rely on it having
> happened to be set to 0 by the previous successful call.
>
> 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 Jun 11 15:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 15:57: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 1Se6yt-0000ft-Hw; Mon, 11 Jun 2012 15:56:39 +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 1Se6ys-0000fo-Ms
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 15:56:39 +0000
Received: from [193.109.254.147:45196] by server-2.bemta-14.messagelabs.com id
	2A/02-27740-53516DF4; Mon, 11 Jun 2012 15:56:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339430196!3523018!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzIxODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzIxODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 985 invoked from network); 11 Jun 2012 15:56:36 -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; 11 Jun 2012 15:56:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jorabe mo13) (RZmta 29.11 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y036e4o5BETOb6
	for <xen-devel@lists.xensource.com>;
	Mon, 11 Jun 2012 17:56:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9845318637
	for <xen-devel@lists.xensource.com>;
	Mon, 11 Jun 2012 17:56:33 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: d5280420afc9c1e52d8e8bf35bb36512120e0556
Message-Id: <d5280420afc9c1e52d8e.1339430192@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 11 Jun 2012 17:56:32 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] docs: install documentation which is referenced
	in man 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1339429861 -7200
# Node ID d5280420afc9c1e52d8e8bf35bb36512120e0556
# Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
docs: install documentation which is referenced in man pages

Currently the various man pages refer to some other documentation files
in the source tree. For example, xl.cfg.5 refers to
docs/misc/xl-disk-configuration.txt, which in turn refers to
docs/misc/vbd-interface.txt.

Since these files are not packaged, the provided documentation appears
incomplete. Fix this by installing the additional files into DOCDIR and
also adjust the contents of the man pages and affected documentation
files to contain the full path of DOCDIR.

xl.cfg.5 refers to non-existant files named xl-disk-configuration and
xl-network-configuration. Adjust to new DOCDIR location.

Simplify the pod2man call, merge two sed calls into a single one.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a70b35deb2b5 -r d5280420afc9 docs/Makefile
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -21,6 +21,10 @@ DOC_TXT         := $(patsubst %.txt,txt/
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
+DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
+			misc/xl-disk-configuration.txt \
+			misc/vbd-interface.txt \
+			misc/xl-network-configuration.markdown
 .PHONY: all
 all: build
 
@@ -57,13 +61,17 @@ man-pages:
 
 man1/%.1: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2MAN) --release=$(VERSION) --name=`echo $@ | sed 's/^man1.//'| \
-		sed 's/.1//'` -s 1 -c "Xen" $< $@
+	sed 's|@DOCDIR@|$(DOCDIR)|g' $< | \
+	$(POD2MAN) --release=$(VERSION) \
+		--name=`echo $@ | sed 's/^man1.//;s/.1//'` \
+		-s 1 -c "Xen" - $@
 
 man5/%.5: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2MAN) --release=$(VERSION) --name=`echo $@ | sed 's/^man5.//'| \
-		sed 's/.5//'` -s 5 -c "Xen" $< $@
+	sed 's|@DOCDIR@|$(DOCDIR)|g' $< | \
+	$(POD2MAN) --release=$(VERSION) \
+		--name=`echo $@ | sed 's/^man5.//;s/.5//'` \
+		-s 5 -c "Xen" - $@
 
 .PHONY: clean
 clean:
@@ -89,6 +97,9 @@ install: all
 	cp -dR man1 $(DESTDIR)$(MANDIR)
 	cp -dR man5 $(DESTDIR)$(MANDIR)
 	[ ! -d html ] || cp -dR html $(DESTDIR)$(DOCDIR)
+	for i in $(DOC_MAN_REFS) ; do \
+		sed 's|@DOCDIR@|$(DOCDIR)|g' $$i > $(DESTDIR)$(DOCDIR)/`basename $$i` ; \
+		done
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -255,13 +255,13 @@ devices which the guest will contain.
 
 Specifies the disks (both emulated disks and Xen virtual block
 devices) which are to be provided to the guest, and what objects on
-the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
 
 =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
 
 Specifies the networking provision (both emulated network adapters,
 and Xen virtual interfaces) to provided to the guest.  See
-F<docs/misc/xl-network-configuration.markdown>.
+F<@DOCDIR@/xl-network-configuration.markdown>.
 
 =item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
 
@@ -652,7 +652,7 @@ frequency changes.
 
 =back
 
-Please see F<docs/misc/tscmode.txt> for more information on this option.
+Please see F<@DOCDIR@/tscmode.txt> for more information on this option.
 
 =item B<localtime=BOOLEAN>
 
@@ -1062,9 +1062,11 @@ See L<qemu(1)> for more information.
 
 =item L<xl(1)>
 
-=item F<xl-disk-configuration>
+=item F<@DOCDIR@/tscmode.txt>
 
-=item F<xl-network-configuration>
+=item F<@DOCDIR@/xl-disk-configuration.txt>
+
+=item F<@DOCDIR@/xl-network-configuration.markdown>
 
 =back
 
@@ -1072,7 +1074,6 @@ See L<qemu(1)> for more information.
 
 F</etc/xen/NAME.cfg>
 F</var/xen/dump/NAME>
-F<docs/misc/tscmode.txt>
 
 =head1 BUGS
 
diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -876,7 +876,7 @@ Restrict output to domains in the specif
 Set or get Simple EDF (Earliest Deadline First) scheduler parameters. This
 scheduler provides weighted CPU sharing in an intuitive way and uses
 realtime-algorithms to ensure time guarantees.  For more information see
-docs/misc/sedf_scheduler_mini-HOWTO.txt in the Xen distribution.
+F<@DOCDIR@/sedf_scheduler_mini-HOWTO.txt> in the Xen distribution.
 
 B<OPTIONS>
 
diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xm.pod.1
--- a/docs/man/xm.pod.1
+++ b/docs/man/xm.pod.1
@@ -774,7 +774,7 @@ no upper cap.
 Set Simple EDF (Earliest Deadline First) scheduler parameters.  This
 scheduler provides weighted CPU sharing in an intuitive way and uses
 realtime-algorithms to ensure time guarantees.  For more information
-see docs/misc/sedf_scheduler_mini-HOWTO.txt in the Xen distribution.
+see F<@DOCDIR@/sedf_scheduler_mini-HOWTO.txt> in the Xen distribution.
 
 B<PARAMETERS>
 
diff -r a70b35deb2b5 -r d5280420afc9 docs/misc/xl-disk-configuration.txt
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -97,7 +97,7 @@ vdev
 
 Description:           Virtual device as seen by the guest (also
                        referred to as guest drive designation in some
-                       specifications).  See docs/misc/vbd-interface.txt.
+                       specifications).  See @DOCDIR@/vbd-interface.txt.
 Supported values:      hd[x], xvd[x], sd[x] etc.  Please refer to the
                        above specification for further details.
 Deprecated values:     None

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 15:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 15:57: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 1Se6yt-0000ft-Hw; Mon, 11 Jun 2012 15:56:39 +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 1Se6ys-0000fo-Ms
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 15:56:39 +0000
Received: from [193.109.254.147:45196] by server-2.bemta-14.messagelabs.com id
	2A/02-27740-53516DF4; Mon, 11 Jun 2012 15:56:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339430196!3523018!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzIxODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzIxODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 985 invoked from network); 11 Jun 2012 15:56:36 -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; 11 Jun 2012 15:56:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jorabe mo13) (RZmta 29.11 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y036e4o5BETOb6
	for <xen-devel@lists.xensource.com>;
	Mon, 11 Jun 2012 17:56:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9845318637
	for <xen-devel@lists.xensource.com>;
	Mon, 11 Jun 2012 17:56:33 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: d5280420afc9c1e52d8e8bf35bb36512120e0556
Message-Id: <d5280420afc9c1e52d8e.1339430192@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 11 Jun 2012 17:56:32 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] docs: install documentation which is referenced
	in man 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1339429861 -7200
# Node ID d5280420afc9c1e52d8e8bf35bb36512120e0556
# Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
docs: install documentation which is referenced in man pages

Currently the various man pages refer to some other documentation files
in the source tree. For example, xl.cfg.5 refers to
docs/misc/xl-disk-configuration.txt, which in turn refers to
docs/misc/vbd-interface.txt.

Since these files are not packaged, the provided documentation appears
incomplete. Fix this by installing the additional files into DOCDIR and
also adjust the contents of the man pages and affected documentation
files to contain the full path of DOCDIR.

xl.cfg.5 refers to non-existant files named xl-disk-configuration and
xl-network-configuration. Adjust to new DOCDIR location.

Simplify the pod2man call, merge two sed calls into a single one.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a70b35deb2b5 -r d5280420afc9 docs/Makefile
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -21,6 +21,10 @@ DOC_TXT         := $(patsubst %.txt,txt/
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
+DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
+			misc/xl-disk-configuration.txt \
+			misc/vbd-interface.txt \
+			misc/xl-network-configuration.markdown
 .PHONY: all
 all: build
 
@@ -57,13 +61,17 @@ man-pages:
 
 man1/%.1: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2MAN) --release=$(VERSION) --name=`echo $@ | sed 's/^man1.//'| \
-		sed 's/.1//'` -s 1 -c "Xen" $< $@
+	sed 's|@DOCDIR@|$(DOCDIR)|g' $< | \
+	$(POD2MAN) --release=$(VERSION) \
+		--name=`echo $@ | sed 's/^man1.//;s/.1//'` \
+		-s 1 -c "Xen" - $@
 
 man5/%.5: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2MAN) --release=$(VERSION) --name=`echo $@ | sed 's/^man5.//'| \
-		sed 's/.5//'` -s 5 -c "Xen" $< $@
+	sed 's|@DOCDIR@|$(DOCDIR)|g' $< | \
+	$(POD2MAN) --release=$(VERSION) \
+		--name=`echo $@ | sed 's/^man5.//;s/.5//'` \
+		-s 5 -c "Xen" - $@
 
 .PHONY: clean
 clean:
@@ -89,6 +97,9 @@ install: all
 	cp -dR man1 $(DESTDIR)$(MANDIR)
 	cp -dR man5 $(DESTDIR)$(MANDIR)
 	[ ! -d html ] || cp -dR html $(DESTDIR)$(DOCDIR)
+	for i in $(DOC_MAN_REFS) ; do \
+		sed 's|@DOCDIR@|$(DOCDIR)|g' $$i > $(DESTDIR)$(DOCDIR)/`basename $$i` ; \
+		done
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -255,13 +255,13 @@ devices which the guest will contain.
 
 Specifies the disks (both emulated disks and Xen virtual block
 devices) which are to be provided to the guest, and what objects on
-the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
 
 =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
 
 Specifies the networking provision (both emulated network adapters,
 and Xen virtual interfaces) to provided to the guest.  See
-F<docs/misc/xl-network-configuration.markdown>.
+F<@DOCDIR@/xl-network-configuration.markdown>.
 
 =item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
 
@@ -652,7 +652,7 @@ frequency changes.
 
 =back
 
-Please see F<docs/misc/tscmode.txt> for more information on this option.
+Please see F<@DOCDIR@/tscmode.txt> for more information on this option.
 
 =item B<localtime=BOOLEAN>
 
@@ -1062,9 +1062,11 @@ See L<qemu(1)> for more information.
 
 =item L<xl(1)>
 
-=item F<xl-disk-configuration>
+=item F<@DOCDIR@/tscmode.txt>
 
-=item F<xl-network-configuration>
+=item F<@DOCDIR@/xl-disk-configuration.txt>
+
+=item F<@DOCDIR@/xl-network-configuration.markdown>
 
 =back
 
@@ -1072,7 +1074,6 @@ See L<qemu(1)> for more information.
 
 F</etc/xen/NAME.cfg>
 F</var/xen/dump/NAME>
-F<docs/misc/tscmode.txt>
 
 =head1 BUGS
 
diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -876,7 +876,7 @@ Restrict output to domains in the specif
 Set or get Simple EDF (Earliest Deadline First) scheduler parameters. This
 scheduler provides weighted CPU sharing in an intuitive way and uses
 realtime-algorithms to ensure time guarantees.  For more information see
-docs/misc/sedf_scheduler_mini-HOWTO.txt in the Xen distribution.
+F<@DOCDIR@/sedf_scheduler_mini-HOWTO.txt> in the Xen distribution.
 
 B<OPTIONS>
 
diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xm.pod.1
--- a/docs/man/xm.pod.1
+++ b/docs/man/xm.pod.1
@@ -774,7 +774,7 @@ no upper cap.
 Set Simple EDF (Earliest Deadline First) scheduler parameters.  This
 scheduler provides weighted CPU sharing in an intuitive way and uses
 realtime-algorithms to ensure time guarantees.  For more information
-see docs/misc/sedf_scheduler_mini-HOWTO.txt in the Xen distribution.
+see F<@DOCDIR@/sedf_scheduler_mini-HOWTO.txt> in the Xen distribution.
 
 B<PARAMETERS>
 
diff -r a70b35deb2b5 -r d5280420afc9 docs/misc/xl-disk-configuration.txt
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -97,7 +97,7 @@ vdev
 
 Description:           Virtual device as seen by the guest (also
                        referred to as guest drive designation in some
-                       specifications).  See docs/misc/vbd-interface.txt.
+                       specifications).  See @DOCDIR@/vbd-interface.txt.
 Supported values:      hd[x], xvd[x], sd[x] etc.  Please refer to the
                        above specification for further details.
 Deprecated values:     None

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 16:43:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 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 1Se7hp-0001hn-Rg; Mon, 11 Jun 2012 16:43: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 1Se7ho-0001hi-Kn
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 16:43:04 +0000
Received: from [85.158.139.83:9558] by server-3.bemta-5.messagelabs.com id
	57/70-17554-71026DF4; Mon, 11 Jun 2012 16:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339432981!32957683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31634 invoked from network); 11 Jun 2012 16:43:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 16:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12951186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 16:43:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 17:43:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Se7hl-0008DR-2L; Mon, 11 Jun 2012 16:43:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Se7hk-0004d6-Vx;
	Mon, 11 Jun 2012 17:43:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20438.8212.973369.347692@mariner.uk.xensource.com>
Date: Mon, 11 Jun 2012 17:43:00 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE
 process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Here's another patch which needs to go on top of my async save/restore
series.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE

* Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
  handlng.  At every call site, replace it with an open-coded call to
  libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.

* This involves adding an `out:' to libxl_domain_unpause.

* In libxl_domain_destroy and do_pci_add, do not `default: abort();'
  if the domain type cannot be found.  Instead switch on
  LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
  handling.

* In libxl__primary_console_find, remove a spurious default clause
  from the domain type switch.

* In libxl_domain_suspend (as reorganised) error check, check for
  LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl.c          |   33 ++++++++++++++++++++++++---------
 tools/libxl/libxl_internal.h |    5 +++--
 tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
 3 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a257902..cd2dbda 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
         goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_resume_device_model(gc, domid);
         if (rc) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -723,8 +729,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
     int rc;
 
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    if (type < 0) {
-        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
         goto out_err;
     }
@@ -789,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
@@ -803,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
+ out:
     GC_FREE;
     return rc;
 }
@@ -814,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
     unsigned long pvdriver = 0;
     int ret;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV)
         return 1;
 
     ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
@@ -1214,8 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     dom_path = libxl__xs_get_dompath(gc, domid);
@@ -1363,8 +1380,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
         case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-        default:
-            abort();
         }
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f9ee949..c9725a3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
 _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
                                     libxl_domain_sched_params *scparams);
-#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
-    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
+
 typedef struct {
     uint32_t store_port;
     uint32_t store_domid;
@@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+/* returns 0 or 1, or a libxl error code */
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+
 _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
                                             xs_transaction_t t, uint32_t domid);
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..81438be 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
     if (!num_devs)
         return libxl__create_pci_backend(gc, domid, pcidev, 1);
 
-    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0)
             return ERROR_FAIL;
     }
@@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
         return ERROR_INVAL;
     num = atoi(num_devs);
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -199,7 +207,7 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
         }
         break;
     }
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        return ERROR_FAIL;
     }
 out:
     if (!libxl_is_stubdom(ctx, domid, NULL)) {
-- 
tg: (966769c..) t/xen/xl.domain-type-fixups-v2 (depends on: t/xen/xl.ao.progress-ignored-free-event)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 16:43:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 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 1Se7hp-0001hn-Rg; Mon, 11 Jun 2012 16:43: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 1Se7ho-0001hi-Kn
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 16:43:04 +0000
Received: from [85.158.139.83:9558] by server-3.bemta-5.messagelabs.com id
	57/70-17554-71026DF4; Mon, 11 Jun 2012 16:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339432981!32957683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31634 invoked from network); 11 Jun 2012 16:43:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 16:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208";a="12951186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 16:43:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 17:43:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Se7hl-0008DR-2L; Mon, 11 Jun 2012 16:43:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Se7hk-0004d6-Vx;
	Mon, 11 Jun 2012 17:43:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20438.8212.973369.347692@mariner.uk.xensource.com>
Date: Mon, 11 Jun 2012 17:43:00 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE
 process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Here's another patch which needs to go on top of my async save/restore
series.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE

* Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
  handlng.  At every call site, replace it with an open-coded call to
  libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.

* This involves adding an `out:' to libxl_domain_unpause.

* In libxl_domain_destroy and do_pci_add, do not `default: abort();'
  if the domain type cannot be found.  Instead switch on
  LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
  handling.

* In libxl__primary_console_find, remove a spurious default clause
  from the domain type switch.

* In libxl_domain_suspend (as reorganised) error check, check for
  LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl.c          |   33 ++++++++++++++++++++++++---------
 tools/libxl/libxl_internal.h |    5 +++--
 tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
 3 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a257902..cd2dbda 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
         goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_resume_device_model(gc, domid);
         if (rc) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -723,8 +729,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
     int rc;
 
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    if (type < 0) {
-        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
         goto out_err;
     }
@@ -789,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
@@ -803,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
+ out:
     GC_FREE;
     return rc;
 }
@@ -814,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
     unsigned long pvdriver = 0;
     int ret;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV)
         return 1;
 
     ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
@@ -1214,8 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     dom_path = libxl__xs_get_dompath(gc, domid);
@@ -1363,8 +1380,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
         case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-        default:
-            abort();
         }
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f9ee949..c9725a3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
 _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
                                     libxl_domain_sched_params *scparams);
-#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
-    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
+
 typedef struct {
     uint32_t store_port;
     uint32_t store_domid;
@@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+/* returns 0 or 1, or a libxl error code */
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+
 _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
                                             xs_transaction_t t, uint32_t domid);
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..81438be 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
     if (!num_devs)
         return libxl__create_pci_backend(gc, domid, pcidev, 1);
 
-    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0)
             return ERROR_FAIL;
     }
@@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
         return ERROR_INVAL;
     num = atoi(num_devs);
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -199,7 +207,7 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
         }
         break;
     }
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        return ERROR_FAIL;
     }
 out:
     if (!libxl_is_stubdom(ctx, domid, NULL)) {
-- 
tg: (966769c..) t/xen/xl.domain-type-fixups-v2 (depends on: t/xen/xl.ao.progress-ignored-free-event)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 17:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 17: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 1Se8ff-00024w-Kv; Mon, 11 Jun 2012 17:44:55 +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 1Se8fe-00024r-MW
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 17:44:54 +0000
Received: from [85.158.138.51:11890] by server-5.bemta-3.messagelabs.com id
	87/A9-03598-59E26DF4; Mon, 11 Jun 2012 17:44:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339436693!23033953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7725 invoked from network); 11 Jun 2012 17:44:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 17:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,751,1330905600"; d="scan'208";a="12952195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 17:44:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 18:44:52 +0100
Date: Mon, 11 Jun 2012 18:44:32 +0100
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: <4FD615D902000078000893A3@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206111843580.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
	<4FD5EF10020000780008932D@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
	<4FD615D902000078000893A3@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Mon, 11 Jun 2012, Jan Beulich wrote:
> >>> On 11.06.12 at 13:41, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Mon, 11 Jun 2012, Jan Beulich wrote:
> >> > However your patch changes the location of data_dir for the
> >> > installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
> >> 
> >> Sure. But it doesn't matter where exactly the bits get put (and I
> >> actually view the pace they're currently at as less consistent then
> >> where they would end up with the patch, but admittedly that's
> >> likely a matter of taste).
> >> 
> >> > If you are after the non-installed case, you must be already setting
> >> > device_model_override in your VM config file to point to the right
> >> > binary. You might as well pass:
> >> 
> >> No, I did not have to set anything like that - xl/libxl appear to
> >> be figuring out quite fine where the binary is. Having to add such
> >> or this ...
> > 
> > xl loads the binary from LIBEXEC/qemu-system-i386, where LIBEXEC is
> > usually /usr/lib/xen/bin.  Do you set the LIBEXEC configuration
> > differently somewhere?
> 
> Not directly - I'm patching Config.mk:buildmakevars2file:
> 
> @@ -143,7 +143,7 @@ define buildmakevars2file-closure
>  	          SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR     \
>  	          XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
>  	          XEN_RUN_DIR XEN_PAGING_DIR,                               \
> -	          echo "$(var)=\"$($(var))\"" >>$(1).tmp;)        \
> +	          echo "$(var)=\"$(DESTDIR)$($(var))\"" >>$(1).tmp;)        \
>  	$(call move-if-changed,$(1).tmp,$(1))
>  endef
>  
> >> > device_model_args = ['-L', '/path/to/share/file' ]
> >> 
> >> ... would additionally require the VM config files to be updated
> >> each time I update to the tip of -unstable, as I'm having a date
> >> tag somewhere in the path.
> >> 
> >> > that should solve your problem.
> >> 
> >> It certainly would, but at a price I consider too high.
> > 
> > I understand what you say, but I fail to see how you can have a working
> > out of the box configuration using qemu from the build tree... 
> 
> Correct, without above patch (inherited from xend days) this
> presumably wouldn't work. But it really should (and should always
> have also for xend/xm), but for making it work both in the not-
> installed and installed cases, much more than the above patch is
> going to be needed afaict.
> 
> So in the end I assume I'll have to carry that hunk we're discussing
> here alongside the other adjustment...
 
I think so :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 17:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 17: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 1Se8ff-00024w-Kv; Mon, 11 Jun 2012 17:44:55 +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 1Se8fe-00024r-MW
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 17:44:54 +0000
Received: from [85.158.138.51:11890] by server-5.bemta-3.messagelabs.com id
	87/A9-03598-59E26DF4; Mon, 11 Jun 2012 17:44:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339436693!23033953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7725 invoked from network); 11 Jun 2012 17:44:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jun 2012 17:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,751,1330905600"; d="scan'208";a="12952195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jun 2012 17:44:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 11 Jun 2012 18:44:52 +0100
Date: Mon, 11 Jun 2012 18:44:32 +0100
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: <4FD615D902000078000893A3@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206111843580.14957@kaball.uk.xensource.com>
References: <4FCC8F3A020000780008812B@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081210260.14957@kaball.uk.xensource.com>
	<4FD1FE3E0200007800088BE9@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206081234460.14957@kaball.uk.xensource.com>
	<4FD209480200007800088C52@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111133080.14957@kaball.uk.xensource.com>
	<4FD5EF10020000780008932D@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206111235260.14957@kaball.uk.xensource.com>
	<4FD615D902000078000893A3@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: adjust --datadir option passed to
 qemu-upstream's configure 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 Mon, 11 Jun 2012, Jan Beulich wrote:
> >>> On 11.06.12 at 13:41, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Mon, 11 Jun 2012, Jan Beulich wrote:
> >> > However your patch changes the location of data_dir for the
> >> > installed case too, from /usr/share/qemu-xen to /usr/lib/xen/share/qemu.
> >> 
> >> Sure. But it doesn't matter where exactly the bits get put (and I
> >> actually view the pace they're currently at as less consistent then
> >> where they would end up with the patch, but admittedly that's
> >> likely a matter of taste).
> >> 
> >> > If you are after the non-installed case, you must be already setting
> >> > device_model_override in your VM config file to point to the right
> >> > binary. You might as well pass:
> >> 
> >> No, I did not have to set anything like that - xl/libxl appear to
> >> be figuring out quite fine where the binary is. Having to add such
> >> or this ...
> > 
> > xl loads the binary from LIBEXEC/qemu-system-i386, where LIBEXEC is
> > usually /usr/lib/xen/bin.  Do you set the LIBEXEC configuration
> > differently somewhere?
> 
> Not directly - I'm patching Config.mk:buildmakevars2file:
> 
> @@ -143,7 +143,7 @@ define buildmakevars2file-closure
>  	          SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR     \
>  	          XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
>  	          XEN_RUN_DIR XEN_PAGING_DIR,                               \
> -	          echo "$(var)=\"$($(var))\"" >>$(1).tmp;)        \
> +	          echo "$(var)=\"$(DESTDIR)$($(var))\"" >>$(1).tmp;)        \
>  	$(call move-if-changed,$(1).tmp,$(1))
>  endef
>  
> >> > device_model_args = ['-L', '/path/to/share/file' ]
> >> 
> >> ... would additionally require the VM config files to be updated
> >> each time I update to the tip of -unstable, as I'm having a date
> >> tag somewhere in the path.
> >> 
> >> > that should solve your problem.
> >> 
> >> It certainly would, but at a price I consider too high.
> > 
> > I understand what you say, but I fail to see how you can have a working
> > out of the box configuration using qemu from the build tree... 
> 
> Correct, without above patch (inherited from xend days) this
> presumably wouldn't work. But it really should (and should always
> have also for xend/xm), but for making it work both in the not-
> installed and installed cases, much more than the above patch is
> going to be needed afaict.
> 
> So in the end I assume I'll have to carry that hunk we're discussing
> here alongside the other adjustment...
 
I think so :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 18:30:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 18: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 1Se9NE-0002lG-Vo; Mon, 11 Jun 2012 18:29:56 +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 1Se9ND-0002lB-8S
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 18:29:55 +0000
Received: from [85.158.143.35:19967] by server-2.bemta-4.messagelabs.com id
	0A/73-17938-22936DF4; Mon, 11 Jun 2012 18:29:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339439392!12583065!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28571 invoked from network); 11 Jun 2012 18:29:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 18:29:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BITj5J024535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 18:29:45 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
	q5BITiQH024942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 18:29:44 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
	q5BITijk001349; Mon, 11 Jun 2012 13:29:44 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 11:29:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0A6234029A; Mon, 11 Jun 2012 14:22:29 -0400 (EDT)
Date: Mon, 11 Jun 2012 14:22:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120611182229.GC14535@phenom.dumpdata.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
	<4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +static const char *op_name(int op)
> > +{
> > +	static const char *names[] = {
> 
> Could/should really be "static const char *const names[]".

It should. I forgot the extra 'const' 
> 
> > +		[BLKIF_OP_READ] = "read",
> > +		[BLKIF_OP_WRITE] = "write",
> > +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> > +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> > +		[BLKIF_OP_RESERVED_1] = "reserved",
> > +		[BLKIF_OP_DISCARD] = "discard" };
> > +
.. snip..
> > +		if (id >= BLK_RING_SIZE)
> > +			/* We can't safely get the 'struct request' as
> > +			 * the id is busted. So limp along. */
> > +			goto err_out;
> 
> Getting out of the loop here isn't really what I'd call "limp along" -
> it'd likely get the communication to a halt (if there are more
> responses ready). I'd rather see this print something, and then
> continue the loop. Or alternatively, if we really want to stop
> communication in such a case, initiate tear down of the device.
> 
> > +
> >  		req  = info->shadow[id].request;
> >  
> >  		if (bret->operation != BLKIF_OP_DISCARD)
> >  			blkif_completion(&info->shadow[id]);
> >  
> > -		add_id_to_freelist(info, id);
> > +		if (add_id_to_freelist(info, id))
> > +			goto err_out;
> 
> Same here, obviously.

<nods> Will do.
.. snip.k
> > +#define BLKIF_OP_RESERVED_1        4
> 
> If you really want to give this a numeric tag, wouldn't it be better
> to make this _4? But maybe you could leave out the definition here
> altogether, and leave the corresponding names[] slot set to NULL?

That would work too. Please see
>From 98e01250daadc66c1476e3d14603df69ff2a9e14 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 25 May 2012 17:34:51 -0400
Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.

Part of the ring structure is the 'id' field which is under
control of the frontend. The frontend stamps it with "some"
value (this some in this implementation being a value less
than BLK_RING_SIZE), and when it gets a response expects
said value to be in the response structure. We have a check
for the id field when spolling new requests but not when
de-spolling responses.

We also add an extra check in add_id_to_freelist to make
sure that the 'struct request' was not NULL - as we cannot
pass a NULL to __blk_end_request_all, otherwise that crashes
(and all the operations that the response is dealing with
end up with __blk_end_request_all).

Lastly we also print the name of the operation that failed.

[v1: s/BUG/WARN/ suggested by Stefano]
[v2: Add extra check in add_id_to_freelist]
[v3: Redid op_name per Jan's suggestion]
[v4: add const * and add WARN on failure returns]
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c |   62 +++++++++++++++++++++++++++++++++--------
 1 files changed, 50 insertions(+), 12 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..88510e4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -141,14 +141,36 @@ static int get_id_from_freelist(struct blkfront_info *info)
 	return free;
 }
 
-static void add_id_to_freelist(struct blkfront_info *info,
+static int add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
+	if (info->shadow[id].req.u.rw.id != id)
+		return -EINVAL;
+	if (info->shadow[id].request == NULL)
+		return -EINVAL;
 	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
+	return 0;
 }
 
+static const char *op_name(int op)
+{
+	static const char *const names[] = {
+		[BLKIF_OP_READ] = "read",
+		[BLKIF_OP_WRITE] = "write",
+		[BLKIF_OP_WRITE_BARRIER] = "barrier",
+		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
+		[BLKIF_OP_DISCARD] = "discard" };
+
+	if (op < 0 || op >= ARRAY_SIZE(names))
+		return "unknown";
+
+	if (!names[op])
+		return "reserved";
+
+	return names[op];
+}
 static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 {
 	unsigned int end = minor + nr;
@@ -744,20 +766,36 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 
 		bret = RING_GET_RESPONSE(&info->ring, i);
 		id   = bret->id;
+		/*
+		 * The backend has messed up and given us an id that we would
+		 * never have given to it (we stamp it up to BLK_RING_SIZE -
+		 * look in get_id_from_freelist.
+		 */
+		if (id >= BLK_RING_SIZE) {
+			WARN(1, "%s: response to %s has incorrect id (%ld)\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			/* We can't safely get the 'struct request' as
+			 * the id is busted. So quit. */
+			goto err_out;
+		}
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
 			blkif_completion(&info->shadow[id]);
 
-		add_id_to_freelist(info, id);
+		if (add_id_to_freelist(info, id)) {
+			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			goto err_out;
+		}
 
 		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
 		switch (bret->operation) {
 		case BLKIF_OP_DISCARD:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
 				struct request_queue *rq = info->rq;
-				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
-					   info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+					   info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
 				info->feature_secdiscard = 0;
@@ -769,18 +807,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		case BLKIF_OP_FLUSH_DISKCACHE:
 		case BLKIF_OP_WRITE_BARRIER:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
-				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
 				     info->shadow[id].req.u.rw.nr_segments == 0)) {
-				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(error)) {
@@ -819,6 +853,10 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 	spin_unlock_irqrestore(&blkif_io_lock, flags);
 
 	return IRQ_HANDLED;
+err_out:
+	spin_unlock_irqrestore(&info->io_lock, flags);
+
+	return IRQ_HANDLED;
 }
 
 
-- 
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 Jun 11 18:30:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 18: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 1Se9NE-0002lG-Vo; Mon, 11 Jun 2012 18:29:56 +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 1Se9ND-0002lB-8S
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 18:29:55 +0000
Received: from [85.158.143.35:19967] by server-2.bemta-4.messagelabs.com id
	0A/73-17938-22936DF4; Mon, 11 Jun 2012 18:29:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339439392!12583065!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28571 invoked from network); 11 Jun 2012 18:29:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 18:29:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BITj5J024535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 18:29:45 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
	q5BITiQH024942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 18:29:44 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
	q5BITijk001349; Mon, 11 Jun 2012 13:29:44 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 11:29:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0A6234029A; Mon, 11 Jun 2012 14:22:29 -0400 (EDT)
Date: Mon, 11 Jun 2012 14:22:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120611182229.GC14535@phenom.dumpdata.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
	<4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +static const char *op_name(int op)
> > +{
> > +	static const char *names[] = {
> 
> Could/should really be "static const char *const names[]".

It should. I forgot the extra 'const' 
> 
> > +		[BLKIF_OP_READ] = "read",
> > +		[BLKIF_OP_WRITE] = "write",
> > +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> > +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> > +		[BLKIF_OP_RESERVED_1] = "reserved",
> > +		[BLKIF_OP_DISCARD] = "discard" };
> > +
.. snip..
> > +		if (id >= BLK_RING_SIZE)
> > +			/* We can't safely get the 'struct request' as
> > +			 * the id is busted. So limp along. */
> > +			goto err_out;
> 
> Getting out of the loop here isn't really what I'd call "limp along" -
> it'd likely get the communication to a halt (if there are more
> responses ready). I'd rather see this print something, and then
> continue the loop. Or alternatively, if we really want to stop
> communication in such a case, initiate tear down of the device.
> 
> > +
> >  		req  = info->shadow[id].request;
> >  
> >  		if (bret->operation != BLKIF_OP_DISCARD)
> >  			blkif_completion(&info->shadow[id]);
> >  
> > -		add_id_to_freelist(info, id);
> > +		if (add_id_to_freelist(info, id))
> > +			goto err_out;
> 
> Same here, obviously.

<nods> Will do.
.. snip.k
> > +#define BLKIF_OP_RESERVED_1        4
> 
> If you really want to give this a numeric tag, wouldn't it be better
> to make this _4? But maybe you could leave out the definition here
> altogether, and leave the corresponding names[] slot set to NULL?

That would work too. Please see
>From 98e01250daadc66c1476e3d14603df69ff2a9e14 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 25 May 2012 17:34:51 -0400
Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.

Part of the ring structure is the 'id' field which is under
control of the frontend. The frontend stamps it with "some"
value (this some in this implementation being a value less
than BLK_RING_SIZE), and when it gets a response expects
said value to be in the response structure. We have a check
for the id field when spolling new requests but not when
de-spolling responses.

We also add an extra check in add_id_to_freelist to make
sure that the 'struct request' was not NULL - as we cannot
pass a NULL to __blk_end_request_all, otherwise that crashes
(and all the operations that the response is dealing with
end up with __blk_end_request_all).

Lastly we also print the name of the operation that failed.

[v1: s/BUG/WARN/ suggested by Stefano]
[v2: Add extra check in add_id_to_freelist]
[v3: Redid op_name per Jan's suggestion]
[v4: add const * and add WARN on failure returns]
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c |   62 +++++++++++++++++++++++++++++++++--------
 1 files changed, 50 insertions(+), 12 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..88510e4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -141,14 +141,36 @@ static int get_id_from_freelist(struct blkfront_info *info)
 	return free;
 }
 
-static void add_id_to_freelist(struct blkfront_info *info,
+static int add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
+	if (info->shadow[id].req.u.rw.id != id)
+		return -EINVAL;
+	if (info->shadow[id].request == NULL)
+		return -EINVAL;
 	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
+	return 0;
 }
 
+static const char *op_name(int op)
+{
+	static const char *const names[] = {
+		[BLKIF_OP_READ] = "read",
+		[BLKIF_OP_WRITE] = "write",
+		[BLKIF_OP_WRITE_BARRIER] = "barrier",
+		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
+		[BLKIF_OP_DISCARD] = "discard" };
+
+	if (op < 0 || op >= ARRAY_SIZE(names))
+		return "unknown";
+
+	if (!names[op])
+		return "reserved";
+
+	return names[op];
+}
 static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 {
 	unsigned int end = minor + nr;
@@ -744,20 +766,36 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 
 		bret = RING_GET_RESPONSE(&info->ring, i);
 		id   = bret->id;
+		/*
+		 * The backend has messed up and given us an id that we would
+		 * never have given to it (we stamp it up to BLK_RING_SIZE -
+		 * look in get_id_from_freelist.
+		 */
+		if (id >= BLK_RING_SIZE) {
+			WARN(1, "%s: response to %s has incorrect id (%ld)\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			/* We can't safely get the 'struct request' as
+			 * the id is busted. So quit. */
+			goto err_out;
+		}
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
 			blkif_completion(&info->shadow[id]);
 
-		add_id_to_freelist(info, id);
+		if (add_id_to_freelist(info, id)) {
+			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			goto err_out;
+		}
 
 		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
 		switch (bret->operation) {
 		case BLKIF_OP_DISCARD:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
 				struct request_queue *rq = info->rq;
-				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
-					   info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+					   info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
 				info->feature_secdiscard = 0;
@@ -769,18 +807,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		case BLKIF_OP_FLUSH_DISKCACHE:
 		case BLKIF_OP_WRITE_BARRIER:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
-				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
 				     info->shadow[id].req.u.rw.nr_segments == 0)) {
-				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(error)) {
@@ -819,6 +853,10 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 	spin_unlock_irqrestore(&blkif_io_lock, flags);
 
 	return IRQ_HANDLED;
+err_out:
+	spin_unlock_irqrestore(&info->io_lock, flags);
+
+	return IRQ_HANDLED;
 }
 
 
-- 
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 Jun 11 19:00:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:00: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 1Se9qX-000313-Kj; Mon, 11 Jun 2012 19:00: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 1Se9qV-00030v-FG
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:00:11 +0000
Received: from [85.158.139.83:37027] by server-3.bemta-5.messagelabs.com id
	61/BE-17554-A3046DF4; Mon, 11 Jun 2012 19:00:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339441207!19230586!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4Mjc3OQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19527 invoked from network); 11 Jun 2012 19:00:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 19:00:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BIxvPh024424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 18:59:58 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
	q5BIxuJU001579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 18:59:57 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
	q5BIxu3Y005766; Mon, 11 Jun 2012 13:59:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 11:59:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E134E4029A; Mon, 11 Jun 2012 14:52:41 -0400 (EDT)
Date: Mon, 11 Jun 2012 14:52:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120611185241.GJ14535@phenom.dumpdata.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
	<4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
	<20120611182229.GC14535@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120611182229.GC14535@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Getting out of the loop here isn't really what I'd call "limp along" -
> > it'd likely get the communication to a halt (if there are more
> > responses ready). I'd rather see this print something, and then
> > continue the loop. Or alternatively, if we really want to stop
> > communication in such a case, initiate tear down of the device.

And this is what I get from reading without coffee.. This patch
does the 'continue' instead of tear down of the device. Long-term
tear-down is proper but that is a bit more complex.

>From 24a400057010ef280c3ebe33d1c4d74de43dcbea Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 25 May 2012 17:34:51 -0400
Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.

Part of the ring structure is the 'id' field which is under
control of the frontend. The frontend stamps it with "some"
value (this some in this implementation being a value less
than BLK_RING_SIZE), and when it gets a response expects
said value to be in the response structure. We have a check
for the id field when spolling new requests but not when
de-spolling responses.

We also add an extra check in add_id_to_freelist to make
sure that the 'struct request' was not NULL - as we cannot
pass a NULL to __blk_end_request_all, otherwise that crashes
(and all the operations that the response is dealing with
end up with __blk_end_request_all).

Lastly we also print the name of the operation that failed.

[v1: s/BUG/WARN/ suggested by Stefano]
[v2: Add extra check in add_id_to_freelist]
[v3: Redid op_name per Jan's suggestion]
[v4: add const * and add WARN on failure returns]
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c |   58 +++++++++++++++++++++++++++++++++--------
 1 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 60eed4b..e4fb337 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -141,14 +141,36 @@ static int get_id_from_freelist(struct blkfront_info *info)
 	return free;
 }
 
-static void add_id_to_freelist(struct blkfront_info *info,
+static int add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
+	if (info->shadow[id].req.u.rw.id != id)
+		return -EINVAL;
+	if (info->shadow[id].request == NULL)
+		return -EINVAL;
 	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
+	return 0;
 }
 
+static const char *op_name(int op)
+{
+	static const char *const names[] = {
+		[BLKIF_OP_READ] = "read",
+		[BLKIF_OP_WRITE] = "write",
+		[BLKIF_OP_WRITE_BARRIER] = "barrier",
+		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
+		[BLKIF_OP_DISCARD] = "discard" };
+
+	if (op < 0 || op >= ARRAY_SIZE(names))
+		return "unknown";
+
+	if (!names[op])
+		return "reserved";
+
+	return names[op];
+}
 static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 {
 	unsigned int end = minor + nr;
@@ -746,20 +768,36 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 
 		bret = RING_GET_RESPONSE(&info->ring, i);
 		id   = bret->id;
+		/*
+		 * The backend has messed up and given us an id that we would
+		 * never have given to it (we stamp it up to BLK_RING_SIZE -
+		 * look in get_id_from_freelist.
+		 */
+		if (id >= BLK_RING_SIZE) {
+			WARN(1, "%s: response to %s has incorrect id (%ld)\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			/* We can't safely get the 'struct request' as
+			 * the id is busted. */
+			continue;
+		}
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
 			blkif_completion(&info->shadow[id]);
 
-		add_id_to_freelist(info, id);
+		if (add_id_to_freelist(info, id)) {
+			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			continue;
+		}
 
 		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
 		switch (bret->operation) {
 		case BLKIF_OP_DISCARD:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
 				struct request_queue *rq = info->rq;
-				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
-					   info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+					   info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
 				info->feature_secdiscard = 0;
@@ -771,18 +809,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		case BLKIF_OP_FLUSH_DISKCACHE:
 		case BLKIF_OP_WRITE_BARRIER:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
-				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
 				     info->shadow[id].req.u.rw.nr_segments == 0)) {
-				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(error)) {
-- 
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 Jun 11 19:00:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:00: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 1Se9qX-000313-Kj; Mon, 11 Jun 2012 19:00: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 1Se9qV-00030v-FG
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:00:11 +0000
Received: from [85.158.139.83:37027] by server-3.bemta-5.messagelabs.com id
	61/BE-17554-A3046DF4; Mon, 11 Jun 2012 19:00:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339441207!19230586!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4Mjc3OQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19527 invoked from network); 11 Jun 2012 19:00:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 19:00:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BIxvPh024424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 18:59:58 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
	q5BIxuJU001579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 18:59:57 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
	q5BIxu3Y005766; Mon, 11 Jun 2012 13:59:56 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 11:59:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E134E4029A; Mon, 11 Jun 2012 14:52:41 -0400 (EDT)
Date: Mon, 11 Jun 2012 14:52:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120611185241.GJ14535@phenom.dumpdata.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
	<4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
	<20120611182229.GC14535@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120611182229.GC14535@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Getting out of the loop here isn't really what I'd call "limp along" -
> > it'd likely get the communication to a halt (if there are more
> > responses ready). I'd rather see this print something, and then
> > continue the loop. Or alternatively, if we really want to stop
> > communication in such a case, initiate tear down of the device.

And this is what I get from reading without coffee.. This patch
does the 'continue' instead of tear down of the device. Long-term
tear-down is proper but that is a bit more complex.

>From 24a400057010ef280c3ebe33d1c4d74de43dcbea Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 25 May 2012 17:34:51 -0400
Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.

Part of the ring structure is the 'id' field which is under
control of the frontend. The frontend stamps it with "some"
value (this some in this implementation being a value less
than BLK_RING_SIZE), and when it gets a response expects
said value to be in the response structure. We have a check
for the id field when spolling new requests but not when
de-spolling responses.

We also add an extra check in add_id_to_freelist to make
sure that the 'struct request' was not NULL - as we cannot
pass a NULL to __blk_end_request_all, otherwise that crashes
(and all the operations that the response is dealing with
end up with __blk_end_request_all).

Lastly we also print the name of the operation that failed.

[v1: s/BUG/WARN/ suggested by Stefano]
[v2: Add extra check in add_id_to_freelist]
[v3: Redid op_name per Jan's suggestion]
[v4: add const * and add WARN on failure returns]
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c |   58 +++++++++++++++++++++++++++++++++--------
 1 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 60eed4b..e4fb337 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -141,14 +141,36 @@ static int get_id_from_freelist(struct blkfront_info *info)
 	return free;
 }
 
-static void add_id_to_freelist(struct blkfront_info *info,
+static int add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
+	if (info->shadow[id].req.u.rw.id != id)
+		return -EINVAL;
+	if (info->shadow[id].request == NULL)
+		return -EINVAL;
 	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
+	return 0;
 }
 
+static const char *op_name(int op)
+{
+	static const char *const names[] = {
+		[BLKIF_OP_READ] = "read",
+		[BLKIF_OP_WRITE] = "write",
+		[BLKIF_OP_WRITE_BARRIER] = "barrier",
+		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
+		[BLKIF_OP_DISCARD] = "discard" };
+
+	if (op < 0 || op >= ARRAY_SIZE(names))
+		return "unknown";
+
+	if (!names[op])
+		return "reserved";
+
+	return names[op];
+}
 static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 {
 	unsigned int end = minor + nr;
@@ -746,20 +768,36 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 
 		bret = RING_GET_RESPONSE(&info->ring, i);
 		id   = bret->id;
+		/*
+		 * The backend has messed up and given us an id that we would
+		 * never have given to it (we stamp it up to BLK_RING_SIZE -
+		 * look in get_id_from_freelist.
+		 */
+		if (id >= BLK_RING_SIZE) {
+			WARN(1, "%s: response to %s has incorrect id (%ld)\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			/* We can't safely get the 'struct request' as
+			 * the id is busted. */
+			continue;
+		}
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
 			blkif_completion(&info->shadow[id]);
 
-		add_id_to_freelist(info, id);
+		if (add_id_to_freelist(info, id)) {
+			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
+			     info->gd->disk_name, op_name(bret->operation), id);
+			continue;
+		}
 
 		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
 		switch (bret->operation) {
 		case BLKIF_OP_DISCARD:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
 				struct request_queue *rq = info->rq;
-				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
-					   info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+					   info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
 				info->feature_secdiscard = 0;
@@ -771,18 +809,14 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		case BLKIF_OP_FLUSH_DISKCACHE:
 		case BLKIF_OP_WRITE_BARRIER:
 			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
-				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
 				     info->shadow[id].req.u.rw.nr_segments == 0)) {
-				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
-				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-				       "barrier" :  "flush disk cache",
-				       info->gd->disk_name);
+				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
+				       info->gd->disk_name, op_name(bret->operation));
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(error)) {
-- 
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 Jun 11 19:20:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:20: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 1SeA9R-0003EG-Tq; Mon, 11 Jun 2012 19:19:45 +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 1SeA9P-0003EA-Ss
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:19:44 +0000
Received: from [193.109.254.147:25929] by server-12.bemta-14.messagelabs.com
	id 82/77-12998-FC446DF4; Mon, 11 Jun 2012 19:19:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339442381!9221451!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7880 invoked from network); 11 Jun 2012 19:19:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 19:19:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BJJTml013015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 19:19:30 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
	q5BJJSrW010148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 19:19:29 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
	q5BJJSPL027352; Mon, 11 Jun 2012 14:19:28 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 12:19:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 590AA4029A; Mon, 11 Jun 2012 15:12:14 -0400 (EDT)
Date: Mon, 11 Jun 2012 15:12:14 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120611191214.GL14535@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335221654@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 11, 2012 at 03:55:00AM +0000, Liu, Jinsong wrote:
> Liu, Jinsong wrote:
> > From a9c5f29330a056291356b912816b5b2e0e061a30 Mon Sep 17 00:00:00 2001
> > From: Liu, Jinsong <jinsong.liu@intel.com>
> > Date: Sat, 9 Jun 2012 00:56:46 +0800
> > Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
> > atomic context 
> > 
> 
> Sorry, I update the patch a little, for spinlock to avoid deadlock.
> 
> Thanks,
> Jinsong
> 
> ====================
> >From db6c0ac9372c6fbc3637ec4216830e7ee01b31aa Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Mon, 11 Jun 2012 19:21:24 +0800
> Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in atomic context
> 
> copy_to_user might sleep and print a stack trace if it is executed
> in an atomic spinlock context. This patch add a mutex lock and a
> buffer to avoid the issue.
> 
> This patch also change the manipulation of mcelog_lock from
> spin_lock_irqsave to spin_trylock to avoid deadlock, since
> mcelog_lock is used at normal process context and
> mce context (which is async exception context that could

Could you explain in more details what is 'async exception
context' and 'mce context' ?

> not protected by spin_lock_irqsave). When fail to get spinlock,
> mc_info would be transferred by hypervisor next time.

What does that mean? How would 'mcelog' program get the data?

> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  drivers/xen/mcelog.c |   38 +++++++++++++++++++++++++++++++-------
>  1 files changed, 31 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> index 72e87d2..fac29e4 100644
> --- a/drivers/xen/mcelog.c
> +++ b/drivers/xen/mcelog.c
> @@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo;
>  static uint32_t ncpus;
>  
>  static DEFINE_SPINLOCK(mcelog_lock);
> +static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
>  
>  static struct xen_mce_log xen_mcelog = {
>  	.signature	= XEN_MCE_LOG_SIGNATURE,
>  	.len		= XEN_MCE_LOG_LEN,
>  	.recordlen	= sizeof(struct xen_mce),
>  };
> +static struct xen_mce_log xen_mcelog_u;
>  
>  static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
>  static int xen_mce_chrdev_open_count;	/* #times opened */
> @@ -106,9 +108,19 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  	unsigned num;
>  	int i, err;
>  
> +	/*
> +	 * copy_to_user might sleep and print a stack trace
> +	 * if it is executed in an atomic spinlock context
> +	 */
> +	mutex_lock(&xen_mce_chrdev_read_mutex);
> +
>  	spin_lock(&mcelog_lock);
> +	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
>  
>  	num = xen_mcelog.next;
> +	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
> +	xen_mcelog.next = 0;
> +	spin_unlock(&mcelog_lock);
>  
>  	/* Only supports full reads right now */
>  	err = -EINVAL;
> @@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  
>  	err = 0;
>  	for (i = 0; i < num; i++) {
> -		struct xen_mce *m = &xen_mcelog.entry[i];
> +		struct xen_mce *m = &xen_mcelog_u.entry[i];
>  
>  		err |= copy_to_user(buf, m, sizeof(*m));
>  		buf += sizeof(*m);
>  	}
>  
> -	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
> -	xen_mcelog.next = 0;
> +	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
> +	xen_mcelog_u.next = 0;
>  
>  	if (err)
>  		err = -EFAULT;
>  
>  out:
> -	spin_unlock(&mcelog_lock);
> +	mutex_unlock(&xen_mce_chrdev_read_mutex);
>  
>  	return err ? err : buf - ubuf;
>  }
> @@ -313,9 +325,21 @@ static int mc_queue_handle(uint32_t flags)
>  static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
>  {
>  	int err;
> -	unsigned long tmp;
>  
> -	spin_lock_irqsave(&mcelog_lock, tmp);
> +	/*
> +	 * mcelog_lock is used at normal process context and
> +	 * mce context (which is async exception context that could
> +	 * not protected by spin_lock_irqsave).
> +	 *
> +	 * use spin_trylock to avoid deadlock. When fail to get spinlock,
> +	 * mc_info would be transferred by hypervisor next time.
> +	 */
> +	if (unlikely(!spin_trylock(&mcelog_lock))) {
> +		pr_err(XEN_MCELOG
> +		       "Failed to get mcelog_lock, mc_info would "
> +		       "be transferred by hypervisor next time.\n");

Ugh. Why the printk? How does this benefit the user? If it
recovers - which I presume "..next time" means then it should be OK?

What does 'transferred by hypervisor' mean actually?

Would it be better to schedule a workqueue to poll the data? Perhaps that
is how this whole IRQ handler should be done - it kicks of an IRQ handler
that de-spolls the data?

> +		return IRQ_NONE;
> +	}
>  
>  	/* urgent mc_info */
>  	err = mc_queue_handle(XEN_MC_URGENT);
> @@ -330,7 +354,7 @@ static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
>  		pr_err(XEN_MCELOG
>  		       "Failed to handle nonurgent mc_info queue.\n");
>  
> -	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +	spin_unlock(&mcelog_lock);
>  
>  	return IRQ_HANDLED;
>  }
> -- 
> 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 Jun 11 19:20:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:20: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 1SeA9R-0003EG-Tq; Mon, 11 Jun 2012 19:19:45 +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 1SeA9P-0003EA-Ss
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:19:44 +0000
Received: from [193.109.254.147:25929] by server-12.bemta-14.messagelabs.com
	id 82/77-12998-FC446DF4; Mon, 11 Jun 2012 19:19:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339442381!9221451!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7880 invoked from network); 11 Jun 2012 19:19:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 19:19:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BJJTml013015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 19:19:30 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
	q5BJJSrW010148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 19:19:29 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
	q5BJJSPL027352; Mon, 11 Jun 2012 14:19:28 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 12:19:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 590AA4029A; Mon, 11 Jun 2012 15:12:14 -0400 (EDT)
Date: Mon, 11 Jun 2012 15:12:14 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120611191214.GL14535@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335221654@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 11, 2012 at 03:55:00AM +0000, Liu, Jinsong wrote:
> Liu, Jinsong wrote:
> > From a9c5f29330a056291356b912816b5b2e0e061a30 Mon Sep 17 00:00:00 2001
> > From: Liu, Jinsong <jinsong.liu@intel.com>
> > Date: Sat, 9 Jun 2012 00:56:46 +0800
> > Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
> > atomic context 
> > 
> 
> Sorry, I update the patch a little, for spinlock to avoid deadlock.
> 
> Thanks,
> Jinsong
> 
> ====================
> >From db6c0ac9372c6fbc3637ec4216830e7ee01b31aa Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Mon, 11 Jun 2012 19:21:24 +0800
> Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in atomic context
> 
> copy_to_user might sleep and print a stack trace if it is executed
> in an atomic spinlock context. This patch add a mutex lock and a
> buffer to avoid the issue.
> 
> This patch also change the manipulation of mcelog_lock from
> spin_lock_irqsave to spin_trylock to avoid deadlock, since
> mcelog_lock is used at normal process context and
> mce context (which is async exception context that could

Could you explain in more details what is 'async exception
context' and 'mce context' ?

> not protected by spin_lock_irqsave). When fail to get spinlock,
> mc_info would be transferred by hypervisor next time.

What does that mean? How would 'mcelog' program get the data?

> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  drivers/xen/mcelog.c |   38 +++++++++++++++++++++++++++++++-------
>  1 files changed, 31 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> index 72e87d2..fac29e4 100644
> --- a/drivers/xen/mcelog.c
> +++ b/drivers/xen/mcelog.c
> @@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo;
>  static uint32_t ncpus;
>  
>  static DEFINE_SPINLOCK(mcelog_lock);
> +static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
>  
>  static struct xen_mce_log xen_mcelog = {
>  	.signature	= XEN_MCE_LOG_SIGNATURE,
>  	.len		= XEN_MCE_LOG_LEN,
>  	.recordlen	= sizeof(struct xen_mce),
>  };
> +static struct xen_mce_log xen_mcelog_u;
>  
>  static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
>  static int xen_mce_chrdev_open_count;	/* #times opened */
> @@ -106,9 +108,19 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  	unsigned num;
>  	int i, err;
>  
> +	/*
> +	 * copy_to_user might sleep and print a stack trace
> +	 * if it is executed in an atomic spinlock context
> +	 */
> +	mutex_lock(&xen_mce_chrdev_read_mutex);
> +
>  	spin_lock(&mcelog_lock);
> +	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
>  
>  	num = xen_mcelog.next;
> +	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
> +	xen_mcelog.next = 0;
> +	spin_unlock(&mcelog_lock);
>  
>  	/* Only supports full reads right now */
>  	err = -EINVAL;
> @@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  
>  	err = 0;
>  	for (i = 0; i < num; i++) {
> -		struct xen_mce *m = &xen_mcelog.entry[i];
> +		struct xen_mce *m = &xen_mcelog_u.entry[i];
>  
>  		err |= copy_to_user(buf, m, sizeof(*m));
>  		buf += sizeof(*m);
>  	}
>  
> -	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
> -	xen_mcelog.next = 0;
> +	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
> +	xen_mcelog_u.next = 0;
>  
>  	if (err)
>  		err = -EFAULT;
>  
>  out:
> -	spin_unlock(&mcelog_lock);
> +	mutex_unlock(&xen_mce_chrdev_read_mutex);
>  
>  	return err ? err : buf - ubuf;
>  }
> @@ -313,9 +325,21 @@ static int mc_queue_handle(uint32_t flags)
>  static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
>  {
>  	int err;
> -	unsigned long tmp;
>  
> -	spin_lock_irqsave(&mcelog_lock, tmp);
> +	/*
> +	 * mcelog_lock is used at normal process context and
> +	 * mce context (which is async exception context that could
> +	 * not protected by spin_lock_irqsave).
> +	 *
> +	 * use spin_trylock to avoid deadlock. When fail to get spinlock,
> +	 * mc_info would be transferred by hypervisor next time.
> +	 */
> +	if (unlikely(!spin_trylock(&mcelog_lock))) {
> +		pr_err(XEN_MCELOG
> +		       "Failed to get mcelog_lock, mc_info would "
> +		       "be transferred by hypervisor next time.\n");

Ugh. Why the printk? How does this benefit the user? If it
recovers - which I presume "..next time" means then it should be OK?

What does 'transferred by hypervisor' mean actually?

Would it be better to schedule a workqueue to poll the data? Perhaps that
is how this whole IRQ handler should be done - it kicks of an IRQ handler
that de-spolls the data?

> +		return IRQ_NONE;
> +	}
>  
>  	/* urgent mc_info */
>  	err = mc_queue_handle(XEN_MC_URGENT);
> @@ -330,7 +354,7 @@ static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
>  		pr_err(XEN_MCELOG
>  		       "Failed to handle nonurgent mc_info queue.\n");
>  
> -	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +	spin_unlock(&mcelog_lock);
>  
>  	return IRQ_HANDLED;
>  }
> -- 
> 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 Jun 11 19:36:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeAPA-0003QA-Fh; Mon, 11 Jun 2012 19:36:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SeAP9-0003Q5-9s
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:35:59 +0000
Received: from [85.158.143.99:56543] by server-2.bemta-4.messagelabs.com id
	77/D9-17938-E9846DF4; Mon, 11 Jun 2012 19:35:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339443356!27054949!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14305 invoked from network); 11 Jun 2012 19:35:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jun 2012 19:35:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BJYuQ0026642
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 19:34:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5BJYsJf001451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 19:34:55 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
	q5BJYr2U029435; Mon, 11 Jun 2012 14:34:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 12:34:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87BA14029A; Mon, 11 Jun 2012 15:27:38 -0400 (EDT)
Date: Mon, 11 Jun 2012 15:27:38 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120611192738.GM14535@phenom.dumpdata.com>
References: <20120610020331.GA26100@localhost.localdomain>
	<4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Andrea Arcangeli <aarcange@redhat.com>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>, Jan Beulich <jbeulich@suse.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
 for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Nice. Andrew, any chane you could test this patch on the affected
> > Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> > hypervisor or is it really only on Linode and Amazon EC2?
> > 
> 
> Originally, I was able to reproduce the issue easily with a RHEL5
> host. Now, with this patch it's fixed.

OK, so Tested-by: Andrew Jones..
and from my perspective it looks good - so Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Andrea, any chance you can respin this patch and send it to Linus for 3.5 please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 19:36:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeAPA-0003QA-Fh; Mon, 11 Jun 2012 19:36:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SeAP9-0003Q5-9s
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:35:59 +0000
Received: from [85.158.143.99:56543] by server-2.bemta-4.messagelabs.com id
	77/D9-17938-E9846DF4; Mon, 11 Jun 2012 19:35:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339443356!27054949!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgwNjMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14305 invoked from network); 11 Jun 2012 19:35:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jun 2012 19:35:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BJYuQ0026642
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 19:34:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5BJYsJf001451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 19:34:55 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
	q5BJYr2U029435; Mon, 11 Jun 2012 14:34:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 12:34:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87BA14029A; Mon, 11 Jun 2012 15:27:38 -0400 (EDT)
Date: Mon, 11 Jun 2012 15:27:38 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120611192738.GM14535@phenom.dumpdata.com>
References: <20120610020331.GA26100@localhost.localdomain>
	<4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Andrea Arcangeli <aarcange@redhat.com>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>, Jan Beulich <jbeulich@suse.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
 for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Nice. Andrew, any chane you could test this patch on the affected
> > Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> > hypervisor or is it really only on Linode and Amazon EC2?
> > 
> 
> Originally, I was able to reproduce the issue easily with a RHEL5
> host. Now, with this patch it's fixed.

OK, so Tested-by: Andrew Jones..
and from my perspective it looks good - so Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Andrea, any chance you can respin this patch and send it to Linus for 3.5 please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 19:42:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:42: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 1SeAVE-0003ai-Lr; Mon, 11 Jun 2012 19:42:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1SeAVC-0003ac-HY
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:42:14 +0000
Received: from [85.158.139.83:49458] by server-6.bemta-5.messagelabs.com id
	56/7D-18700-51A46DF4; Mon, 11 Jun 2012 19:42:13 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339443732!31552383!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13518 invoked from network); 11 Jun 2012 19:42:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 19:42: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 q5BJfKcl006659
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 15:41:20 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q5BJfHJh006667; Mon, 11 Jun 2012 15:41:18 -0400
Date: Mon, 11 Jun 2012 21:41:16 +0200
From: Andrea Arcangeli <aarcange@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120611194113.GH3094@redhat.com>
References: <20120610020331.GA26100@localhost.localdomain>
	<4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
	<20120611192738.GM14535@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120611192738.GM14535@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>, Jan Beulich <jbeulich@suse.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
 for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Mon, Jun 11, 2012 at 03:27:38PM -0400, Konrad Rzeszutek Wilk wrote:
> > > Nice. Andrew, any chane you could test this patch on the affected
> > > Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> > > hypervisor or is it really only on Linode and Amazon EC2?
> > > 
> > 
> > Originally, I was able to reproduce the issue easily with a RHEL5
> > host. Now, with this patch it's fixed.
> 
> OK, so Tested-by: Andrew Jones..
> and from my perspective it looks good - so Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks for testing and reviews.

> Andrea, any chance you can respin this patch and send it to Linus for 3.5 please?

Andrew merged it in -mm last Friday, so I would expect it to go
upstream soon through the -mm flow (I assume everyone has been
rightfully waiting a bit of time for testing and reviews to be sure).

Andrea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 19:42:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 19:42: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 1SeAVE-0003ai-Lr; Mon, 11 Jun 2012 19:42:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aarcange@redhat.com>) id 1SeAVC-0003ac-HY
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:42:14 +0000
Received: from [85.158.139.83:49458] by server-6.bemta-5.messagelabs.com id
	56/7D-18700-51A46DF4; Mon, 11 Jun 2012 19:42:13 +0000
X-Env-Sender: aarcange@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339443732!31552383!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5MTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13518 invoked from network); 11 Jun 2012 19:42:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	11 Jun 2012 19:42: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 q5BJfKcl006659
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 15:41:20 -0400
Received: from random.random (ovpn-116-96.ams2.redhat.com [10.36.116.96])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q5BJfHJh006667; Mon, 11 Jun 2012 15:41:18 -0400
Date: Mon, 11 Jun 2012 21:41:16 +0200
From: Andrea Arcangeli <aarcange@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120611194113.GH3094@redhat.com>
References: <20120610020331.GA26100@localhost.localdomain>
	<4728e392-7130-4967-aa79-8da12f929191@zmail17.collab.prod.int.phx2.redhat.com>
	<20120611192738.GM14535@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120611192738.GM14535@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>, Jan Beulich <jbeulich@suse.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Hugh Dickins <hughd@google.com>, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Ulrich Obergfell <uobergfe@redhat.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Mel Gorman <mgorman@suse.de>, 676360@bugs.debian.org,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Larry Woodman <lwoodman@redhat.com>, alan@lxorguk.ukuu.org.uk
Subject: Re: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic
 for 32bit 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Mon, Jun 11, 2012 at 03:27:38PM -0400, Konrad Rzeszutek Wilk wrote:
> > > Nice. Andrew, any chane you could test this patch on the affected
> > > Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> > > hypervisor or is it really only on Linode and Amazon EC2?
> > > 
> > 
> > Originally, I was able to reproduce the issue easily with a RHEL5
> > host. Now, with this patch it's fixed.
> 
> OK, so Tested-by: Andrew Jones..
> and from my perspective it looks good - so Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks for testing and reviews.

> Andrea, any chance you can respin this patch and send it to Linus for 3.5 please?

Andrew merged it in -mm last Friday, so I would expect it to go
upstream soon through the -mm flow (I assume everyone has been
rightfully waiting a bit of time for testing and reviews to be sure).

Andrea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 20:23:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 20:23: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 1SeB8F-0003y2-FN; Mon, 11 Jun 2012 20:22:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1SeB8E-0003xx-Dv
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 20:22:34 +0000
Received: from [85.158.138.51:28330] by server-4.bemta-3.messagelabs.com id
	D3/44-13598-98356DF4; Mon, 11 Jun 2012 20:22:33 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339446152!23049949!1
X-Originating-IP: [72.251.202.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19203 invoked from network); 11 Jun 2012 20:22:32 -0000
Received: from cust-smtp2.lga6.us.voxel.net (HELO
	cust-smtp2.lga6.us.voxel.net) (72.251.202.115)
	by server-7.tower-174.messagelabs.com with SMTP;
	11 Jun 2012 20:22:32 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp2.lga6.us.voxel.net (Postfix) with ESMTP id 5341CF00F2
	for <xen-devel@lists.xen.org>; Mon, 11 Jun 2012 16:22:32 -0400 (EDT)
Received: (qmail 22720 invoked by uid 108); 11 Jun 2012 16:22:32 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@131.193.36.87)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 11 Jun 2012 16:22:32 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 306443783D7; Mon, 11 Jun 2012 15:22:30 -0500 (CDT)
Date: Mon, 11 Jun 2012 15:22:24 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120611202224.GA22246@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
	<20432.59361.773966.629519@mariner.uk.xensource.com>
	<20120608183106.GA12674@imp.flyn.org>
	<20437.62868.542710.418122@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20437.62868.542710.418122@mariner.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] Using "xl create" without domain 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

[...]
> Thanks, this is going in the right direction I think.  Just two
> niggles:
 
>> diff -r 435493696053 tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c  Fri May 25 08:18:47 2012 +0100
>> +++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 07 22:40:58 2012 -0500
>> @@ -1454,10 +1454,13 @@ static int create_domain(struct domain_c
>> 
>>      if (config_file) {
>>          free(config_data);  config_data = 0;
[...]
>> +        // /dev/null represents special case (read config. from command line)
 
> libxl coding style uses /*...*/ comments.
 
>> +        if (strcmp(config_file, "/dev/null")) {
>> +            ret = libxl_read_file_contents(&ctx, config_file,
>> +                                           &config_data, &config_len);
 
> I think this fails to set config_len to 0 in the /dev/null case, which
> it should do.  Although config_len is initialised to 0 it may have
> been set to a non-0 value from the length of the old config file if
> we're doing a restore, and in this case it needs to be rezeroed.
 
>> +            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
>> +                               config_file, strerror(errno)); return ERROR_FAIL; }
>> +        }
>>          if (!restore_file && extra_config && strlen(extra_config)) {
>>              if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
>>                  fprintf(stderr, "Failed to attach extra configration\n");

This version addresses the two issues above:

# HG changeset patch
# Parent 435493696053a079ec17d6e1a63e5f2be3a2c9d0
xl: Allow use of /dev/null with xl create to enable command-line definition

xm allows specifying /dev/null as the domain configuration argument to its
create option; add same functionality to xl. xl treats the configuration
argument /dev/null as a special case.  This allows specifying an entire
domain configuration on the command line.

Signed-off-by: W. Michael Petullo <mike@flyn.org>

diff -r 435493696053 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri May 25 08:18:47 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jun 11 15:18:23 2012 -0500
@@ -1454,10 +1454,15 @@ static int create_domain(struct domain_c
 
     if (config_file) {
         free(config_data);  config_data = 0;
-        ret = libxl_read_file_contents(&ctx, config_file,
-                                       &config_data, &config_len);
-        if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
-                           config_file, strerror(errno)); return ERROR_FAIL; }
+        /* /dev/null represents special case (read config. from command line) */
+        if (!strcmp(config_file, "/dev/null")) {
+            config_len = 0;
+        } else {
+            ret = libxl_read_file_contents(&ctx, config_file,
+                                           &config_data, &config_len);
+            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
+                               config_file, strerror(errno)); return ERROR_FAIL; }
+        }
         if (!restore_file && extra_config && strlen(extra_config)) {
             if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
                 fprintf(stderr, "Failed to attach extra configration\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 20:23:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 20:23: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 1SeB8F-0003y2-FN; Mon, 11 Jun 2012 20:22:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1SeB8E-0003xx-Dv
	for xen-devel@lists.xen.org; Mon, 11 Jun 2012 20:22:34 +0000
Received: from [85.158.138.51:28330] by server-4.bemta-3.messagelabs.com id
	D3/44-13598-98356DF4; Mon, 11 Jun 2012 20:22:33 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339446152!23049949!1
X-Originating-IP: [72.251.202.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19203 invoked from network); 11 Jun 2012 20:22:32 -0000
Received: from cust-smtp2.lga6.us.voxel.net (HELO
	cust-smtp2.lga6.us.voxel.net) (72.251.202.115)
	by server-7.tower-174.messagelabs.com with SMTP;
	11 Jun 2012 20:22:32 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp2.lga6.us.voxel.net (Postfix) with ESMTP id 5341CF00F2
	for <xen-devel@lists.xen.org>; Mon, 11 Jun 2012 16:22:32 -0400 (EDT)
Received: (qmail 22720 invoked by uid 108); 11 Jun 2012 16:22:32 -0400
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@131.193.36.87)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 11 Jun 2012 16:22:32 -0400
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 306443783D7; Mon, 11 Jun 2012 15:22:30 -0500 (CDT)
Date: Mon, 11 Jun 2012 15:22:24 -0500
From: "W. Michael Petullo" <mike@flyn.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120611202224.GA22246@imp.flyn.org>
References: <20120531045040.GA16124@imp.flyn.org>
	<20425.863.785362.721748@mariner.uk.xensource.com>
	<20120602141903.GA2903@imp.flyn.org>
	<20431.13200.114406.125096@mariner.uk.xensource.com>
	<20432.59361.773966.629519@mariner.uk.xensource.com>
	<20120608183106.GA12674@imp.flyn.org>
	<20437.62868.542710.418122@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20437.62868.542710.418122@mariner.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] Using "xl create" without domain 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

[...]
> Thanks, this is going in the right direction I think.  Just two
> niggles:
 
>> diff -r 435493696053 tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c  Fri May 25 08:18:47 2012 +0100
>> +++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 07 22:40:58 2012 -0500
>> @@ -1454,10 +1454,13 @@ static int create_domain(struct domain_c
>> 
>>      if (config_file) {
>>          free(config_data);  config_data = 0;
[...]
>> +        // /dev/null represents special case (read config. from command line)
 
> libxl coding style uses /*...*/ comments.
 
>> +        if (strcmp(config_file, "/dev/null")) {
>> +            ret = libxl_read_file_contents(&ctx, config_file,
>> +                                           &config_data, &config_len);
 
> I think this fails to set config_len to 0 in the /dev/null case, which
> it should do.  Although config_len is initialised to 0 it may have
> been set to a non-0 value from the length of the old config file if
> we're doing a restore, and in this case it needs to be rezeroed.
 
>> +            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
>> +                               config_file, strerror(errno)); return ERROR_FAIL; }
>> +        }
>>          if (!restore_file && extra_config && strlen(extra_config)) {
>>              if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
>>                  fprintf(stderr, "Failed to attach extra configration\n");

This version addresses the two issues above:

# HG changeset patch
# Parent 435493696053a079ec17d6e1a63e5f2be3a2c9d0
xl: Allow use of /dev/null with xl create to enable command-line definition

xm allows specifying /dev/null as the domain configuration argument to its
create option; add same functionality to xl. xl treats the configuration
argument /dev/null as a special case.  This allows specifying an entire
domain configuration on the command line.

Signed-off-by: W. Michael Petullo <mike@flyn.org>

diff -r 435493696053 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri May 25 08:18:47 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jun 11 15:18:23 2012 -0500
@@ -1454,10 +1454,15 @@ static int create_domain(struct domain_c
 
     if (config_file) {
         free(config_data);  config_data = 0;
-        ret = libxl_read_file_contents(&ctx, config_file,
-                                       &config_data, &config_len);
-        if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
-                           config_file, strerror(errno)); return ERROR_FAIL; }
+        /* /dev/null represents special case (read config. from command line) */
+        if (!strcmp(config_file, "/dev/null")) {
+            config_len = 0;
+        } else {
+            ret = libxl_read_file_contents(&ctx, config_file,
+                                           &config_data, &config_len);
+            if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n",
+                               config_file, strerror(errno)); return ERROR_FAIL; }
+        }
         if (!restore_file && extra_config && strlen(extra_config)) {
             if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
                 fprintf(stderr, "Failed to attach extra configration\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 20:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 20: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 1SeBD2-00045X-5k; Mon, 11 Jun 2012 20:27:32 +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 1SeBD0-00045S-S8
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 20:27:31 +0000
Received: from [85.158.143.99:57099] by server-2.bemta-4.messagelabs.com id
	70/16-17938-2B456DF4; Mon, 11 Jun 2012 20:27:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339446448!31439304!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4Mjc3OQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29761 invoked from network); 11 Jun 2012 20:27:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jun 2012 20:27:29 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BKROQi011240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 20:27:25 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
	q5BKRNe8018328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 20:27:24 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
	q5BKRMKP032060; Mon, 11 Jun 2012 15:27:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 13:27:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DCC5B4029A; Mon, 11 Jun 2012 16:20:08 -0400 (EDT)
Date: Mon, 11 Jun 2012 16:20:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120611202008.GA14435@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923352259E4@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923352259E4@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] Xen physical cpus online/offline sys
 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 Mon, Jun 11, 2012 at 05:56:29AM +0000, Liu, Jinsong wrote:
> Konrad,
> 
> Our old patch of cpu online/offline is based on old kernel tree.
> I rebase it to your latest xen.git
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git   branch devel/mce.v3

applied.
> 
> Thanks,
> Jinsong
> 
> =====================
> >From 29152bb054d87334ef970ad037888b7bb032f8ef Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Mon, 11 Jun 2012 20:38:08 +0800
> Subject: [PATCH] Xen physical cpus online/offline sys interface
> 
> This patch provide Xen physical cpus online/offline sys interface.
> User can use it for their own purpose, like power saving:
> by offlining some cpus when light workload it save power greatly.
> 
> Its basic workflow is, user online/offline cpu via sys interface,
> then hypercall xen to implement, after done xen inject virq back to dom0,
> and then dom0 sync cpu status.
> 
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  .../ABI/testing/sysfs-devices-system-xen_cpu       |   20 +
>  drivers/xen/Makefile                               |    1 +
>  drivers/xen/pcpu.c                                 |  371 ++++++++++++++++++++
>  include/xen/interface/platform.h                   |    8 +
>  include/xen/interface/xen.h                        |    1 +
>  5 files changed, 401 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu
>  create mode 100644 drivers/xen/pcpu.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu
> new file mode 100644
> index 0000000..9ca02fb
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu
> @@ -0,0 +1,20 @@
> +What:		/sys/devices/system/xen_cpu/
> +Date:		May 2012
> +Contact:	Liu, Jinsong <jinsong.liu@intel.com>
> +Description:
> +		A collection of global/individual Xen physical cpu attributes
> +
> +		Individual physical cpu attributes are contained in
> +		subdirectories named by the Xen's logical cpu number, e.g.:
> +		/sys/devices/system/xen_cpu/xen_cpu#/
> +
> +
> +What:		/sys/devices/system/xen_cpu/xen_cpu#/online
> +Date:		May 2012
> +Contact:	Liu, Jinsong <jinsong.liu@intel.com>
> +Description:
> +		Interface to online/offline Xen physical cpus
> +
> +		When running under Xen platform, it provide user interface
> +		to online/offline physical cpus, except cpu0 due to several
> +		logic restrictions and assumptions.
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index a787029..d80bea5 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> +obj-$(CONFIG_XEN_DOM0)			+= pcpu.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o acpi.o
>  obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> new file mode 100644
> index 0000000..067fcfa
> --- /dev/null
> +++ b/drivers/xen/pcpu.c
> @@ -0,0 +1,371 @@
> +/******************************************************************************
> + * pcpu.c
> + * Management physical cpu in dom0, get pcpu info and provide sys interface
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <linux/cpu.h>
> +#include <linux/stat.h>
> +#include <linux/capability.h>
> +
> +#include <xen/xen.h>
> +#include <xen/xenbus.h>
> +#include <xen/events.h>
> +#include <xen/interface/platform.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +#define XEN_PCPU "xen_cpu: "
> +
> +/*
> + * @cpu_id: Xen physical cpu logic number
> + * @flags: Xen physical cpu status flag
> + * - XEN_PCPU_FLAGS_ONLINE: cpu is online
> + * - XEN_PCPU_FLAGS_INVALID: cpu is not present
> + */
> +struct pcpu {
> +	struct list_head list;
> +	struct device dev;
> +	uint32_t cpu_id;
> +	uint32_t flags;
> +};
> +
> +static struct bus_type xen_pcpu_subsys = {
> +	.name = "xen_cpu",
> +	.dev_name = "xen_cpu",
> +};
> +
> +static DEFINE_MUTEX(xen_pcpu_lock);
> +
> +static LIST_HEAD(xen_pcpus);
> +
> +static int xen_pcpu_down(uint32_t cpu_id)
> +{
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_offline,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= cpu_id,
> +	};
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +
> +static int xen_pcpu_up(uint32_t cpu_id)
> +{
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_online,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= cpu_id,
> +	};
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +
> +static ssize_t show_online(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
> +}
> +
> +static ssize_t __ref store_online(struct device *dev,
> +				  struct device_attribute *attr,
> +				  const char *buf, size_t count)
> +{
> +	struct pcpu *pcpu = container_of(dev, struct pcpu, dev);
> +	unsigned long long val;
> +	ssize_t ret;
> +
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EPERM;
> +
> +	if (kstrtoull(buf, 0, &val) < 0)
> +		return -EINVAL;
> +
> +	switch (val) {
> +	case 0:
> +		ret = xen_pcpu_down(pcpu->cpu_id);
> +		break;
> +	case 1:
> +		ret = xen_pcpu_up(pcpu->cpu_id);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	if (ret >= 0)
> +		ret = count;
> +	return ret;
> +}
> +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);
> +
> +static bool xen_pcpu_online(uint32_t flags)
> +{
> +	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
> +}
> +
> +static void pcpu_online_status(struct xenpf_pcpuinfo *info,
> +			       struct pcpu *pcpu)
> +{
> +	if (xen_pcpu_online(info->flags) &&
> +	   !xen_pcpu_online(pcpu->flags)) {
> +		/* the pcpu is onlined */
> +		pcpu->flags |= XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
> +	} else if (!xen_pcpu_online(info->flags) &&
> +		    xen_pcpu_online(pcpu->flags)) {
> +		/* The pcpu is offlined */
> +		pcpu->flags &= ~XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
> +	}
> +}
> +
> +static struct pcpu *get_pcpu(uint32_t cpu_id)
> +{
> +	struct pcpu *pcpu;
> +
> +	list_for_each_entry(pcpu, &xen_pcpus, list) {
> +		if (pcpu->cpu_id == cpu_id)
> +			return pcpu;
> +	}
> +
> +	return NULL;
> +}
> +
> +static void pcpu_release(struct device *dev)
> +{
> +	struct pcpu *pcpu = container_of(dev, struct pcpu, dev);
> +
> +	list_del(&pcpu->list);
> +	kfree(pcpu);
> +}
> +
> +static void unregister_and_remove_pcpu(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +
> +	if (!pcpu)
> +		return;
> +
> +	dev = &pcpu->dev;
> +	if (dev->id)
> +		device_remove_file(dev, &dev_attr_online);
> +
> +	/* pcpu remove would be implicitly done */
> +	device_unregister(dev);
> +}
> +
> +static int register_pcpu(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +	int err = -EINVAL;
> +
> +	if (!pcpu)
> +		return err;
> +
> +	dev = &pcpu->dev;
> +	dev->bus = &xen_pcpu_subsys;
> +	dev->id = pcpu->cpu_id;
> +	dev->release = pcpu_release;
> +
> +	err = device_register(dev);
> +	if (err) {
> +		pcpu_release(dev);
> +		return err;
> +	}
> +
> +	/*
> +	 * Xen never offline cpu0 due to several restrictions
> +	 * and assumptions. This basically doesn't add a sys control
> +	 * to user, one cannot attempt to offline BSP.
> +	 */
> +	if (dev->id) {
> +		err = device_create_file(dev, &dev_attr_online);
> +		if (err) {
> +			device_unregister(dev);
> +			return err;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static struct pcpu *create_and_register_pcpu(struct xenpf_pcpuinfo *info)
> +{
> +	struct pcpu *pcpu;
> +	int err;
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID)
> +		return ERR_PTR(-ENODEV);
> +
> +	pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL);
> +	if (!pcpu)
> +		return ERR_PTR(-ENOMEM);
> +
> +	INIT_LIST_HEAD(&pcpu->list);
> +	pcpu->cpu_id = info->xen_cpuid;
> +	pcpu->flags = info->flags;
> +
> +	/* Need hold on xen_pcpu_lock before pcpu list manipulations */
> +	list_add_tail(&pcpu->list, &xen_pcpus);
> +
> +	err = register_pcpu(pcpu);
> +	if (err) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu%u\n",
> +			   info->xen_cpuid);
> +		return ERR_PTR(-ENOENT);
> +	}
> +
> +	return pcpu;
> +}
> +
> +/*
> + * Caller should hold the xen_pcpu_lock
> + */
> +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu)
> +{
> +	int ret;
> +	struct pcpu *pcpu = NULL;
> +	struct xenpf_pcpuinfo *info;
> +	struct xen_platform_op op = {
> +		.cmd                   = XENPF_get_cpuinfo,
> +		.interface_version     = XENPF_INTERFACE_VERSION,
> +		.u.pcpu_info.xen_cpuid = cpu,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	info = &op.u.pcpu_info;
> +	if (max_cpu)
> +		*max_cpu = info->max_present;
> +
> +	pcpu = get_pcpu(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);
> +		return 0;
> +	}
> +
> +	if (!pcpu) {
> +		pcpu = create_and_register_pcpu(info);
> +		if (IS_ERR_OR_NULL(pcpu))
> +			return -ENODEV;
> +	} else
> +		pcpu_online_status(info, pcpu);
> +
> +	return 0;
> +}
> +
> +/*
> + * Sync dom0's pcpu information with xen hypervisor's
> + */
> +static int xen_sync_pcpus(void)
> +{
> +	/*
> +	 * Boot cpu always have cpu_id 0 in xen
> +	 */
> +	uint32_t cpu = 0, max_cpu = 0;
> +	int err = 0;
> +	struct pcpu *pcpu, *tmp;
> +
> +	mutex_lock(&xen_pcpu_lock);
> +
> +	while (!err && (cpu <= max_cpu)) {
> +		err = sync_pcpu(cpu, &max_cpu);
> +		cpu++;
> +	}
> +
> +	if (err)
> +		list_for_each_entry_safe(pcpu, tmp, &xen_pcpus, list)
> +			unregister_and_remove_pcpu(pcpu);
> +
> +	mutex_unlock(&xen_pcpu_lock);
> +
> +	return err;
> +}
> +
> +static void xen_pcpu_work_fn(struct work_struct *work)
> +{
> +	xen_sync_pcpus();
> +}
> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn);
> +
> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_pcpu_init(void)
> +{
> +	int irq, ret;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	irq = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
> +				      xen_pcpu_interrupt, 0,
> +				      "xen-pcpu", NULL);
> +	if (irq < 0) {
> +		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");
> +		return irq;
> +	}
> +
> +	ret = subsys_system_register(&xen_pcpu_subsys, NULL);
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
> +		goto err1;
> +	}
> +
> +	ret = xen_sync_pcpus();
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
> +		goto err2;
> +	}
> +
> +	return 0;
> +
> +err2:
> +	bus_unregister(&xen_pcpu_subsys);
> +err1:
> +	unbind_from_irqhandler(irq, NULL);
> +	return ret;
> +}
> +arch_initcall(xen_pcpu_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 486653f..61fa661 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
>  
> +#define XENPF_cpu_online	56
> +#define XENPF_cpu_offline	57
> +struct xenpf_cpu_ol {
> +	uint32_t cpuid;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -330,6 +337,7 @@ struct xen_platform_op {
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
>  		struct xenpf_pcpuinfo          pcpu_info;
> +		struct xenpf_cpu_ol            cpu_ol;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index a890804..0801468 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -80,6 +80,7 @@
>  #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. */
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> +#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> -- 
> 1.7.1


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 11 20:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Jun 2012 20: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 1SeBD2-00045X-5k; Mon, 11 Jun 2012 20:27:32 +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 1SeBD0-00045S-S8
	for xen-devel@lists.xensource.com; Mon, 11 Jun 2012 20:27:31 +0000
Received: from [85.158.143.99:57099] by server-2.bemta-4.messagelabs.com id
	70/16-17938-2B456DF4; Mon, 11 Jun 2012 20:27:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339446448!31439304!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4Mjc3OQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29761 invoked from network); 11 Jun 2012 20:27:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jun 2012 20:27:29 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BKROQi011240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 20:27:25 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
	q5BKRNe8018328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 20:27:24 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
	q5BKRMKP032060; Mon, 11 Jun 2012 15:27:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 13:27:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DCC5B4029A; Mon, 11 Jun 2012 16:20:08 -0400 (EDT)
Date: Mon, 11 Jun 2012 16:20:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120611202008.GA14435@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923352259E4@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923352259E4@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] Xen physical cpus online/offline sys
 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 Mon, Jun 11, 2012 at 05:56:29AM +0000, Liu, Jinsong wrote:
> Konrad,
> 
> Our old patch of cpu online/offline is based on old kernel tree.
> I rebase it to your latest xen.git
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git   branch devel/mce.v3

applied.
> 
> Thanks,
> Jinsong
> 
> =====================
> >From 29152bb054d87334ef970ad037888b7bb032f8ef Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Mon, 11 Jun 2012 20:38:08 +0800
> Subject: [PATCH] Xen physical cpus online/offline sys interface
> 
> This patch provide Xen physical cpus online/offline sys interface.
> User can use it for their own purpose, like power saving:
> by offlining some cpus when light workload it save power greatly.
> 
> Its basic workflow is, user online/offline cpu via sys interface,
> then hypercall xen to implement, after done xen inject virq back to dom0,
> and then dom0 sync cpu status.
> 
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  .../ABI/testing/sysfs-devices-system-xen_cpu       |   20 +
>  drivers/xen/Makefile                               |    1 +
>  drivers/xen/pcpu.c                                 |  371 ++++++++++++++++++++
>  include/xen/interface/platform.h                   |    8 +
>  include/xen/interface/xen.h                        |    1 +
>  5 files changed, 401 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu
>  create mode 100644 drivers/xen/pcpu.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu
> new file mode 100644
> index 0000000..9ca02fb
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu
> @@ -0,0 +1,20 @@
> +What:		/sys/devices/system/xen_cpu/
> +Date:		May 2012
> +Contact:	Liu, Jinsong <jinsong.liu@intel.com>
> +Description:
> +		A collection of global/individual Xen physical cpu attributes
> +
> +		Individual physical cpu attributes are contained in
> +		subdirectories named by the Xen's logical cpu number, e.g.:
> +		/sys/devices/system/xen_cpu/xen_cpu#/
> +
> +
> +What:		/sys/devices/system/xen_cpu/xen_cpu#/online
> +Date:		May 2012
> +Contact:	Liu, Jinsong <jinsong.liu@intel.com>
> +Description:
> +		Interface to online/offline Xen physical cpus
> +
> +		When running under Xen platform, it provide user interface
> +		to online/offline physical cpus, except cpu0 due to several
> +		logic restrictions and assumptions.
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index a787029..d80bea5 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> +obj-$(CONFIG_XEN_DOM0)			+= pcpu.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o acpi.o
>  obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> new file mode 100644
> index 0000000..067fcfa
> --- /dev/null
> +++ b/drivers/xen/pcpu.c
> @@ -0,0 +1,371 @@
> +/******************************************************************************
> + * pcpu.c
> + * Management physical cpu in dom0, get pcpu info and provide sys interface
> + *
> + * Copyright (c) 2012 Intel Corporation
> + * Author: Liu, Jinsong <jinsong.liu@intel.com>
> + * Author: Jiang, Yunhong <yunhong.jiang@intel.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/spinlock.h>
> +#include <linux/cpu.h>
> +#include <linux/stat.h>
> +#include <linux/capability.h>
> +
> +#include <xen/xen.h>
> +#include <xen/xenbus.h>
> +#include <xen/events.h>
> +#include <xen/interface/platform.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +#define XEN_PCPU "xen_cpu: "
> +
> +/*
> + * @cpu_id: Xen physical cpu logic number
> + * @flags: Xen physical cpu status flag
> + * - XEN_PCPU_FLAGS_ONLINE: cpu is online
> + * - XEN_PCPU_FLAGS_INVALID: cpu is not present
> + */
> +struct pcpu {
> +	struct list_head list;
> +	struct device dev;
> +	uint32_t cpu_id;
> +	uint32_t flags;
> +};
> +
> +static struct bus_type xen_pcpu_subsys = {
> +	.name = "xen_cpu",
> +	.dev_name = "xen_cpu",
> +};
> +
> +static DEFINE_MUTEX(xen_pcpu_lock);
> +
> +static LIST_HEAD(xen_pcpus);
> +
> +static int xen_pcpu_down(uint32_t cpu_id)
> +{
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_offline,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= cpu_id,
> +	};
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +
> +static int xen_pcpu_up(uint32_t cpu_id)
> +{
> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_cpu_online,
> +		.interface_version	= XENPF_INTERFACE_VERSION,
> +		.u.cpu_ol.cpuid		= cpu_id,
> +	};
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +
> +static ssize_t show_online(struct device *dev,
> +			   struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct pcpu *cpu = container_of(dev, struct pcpu, dev);
> +
> +	return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE));
> +}
> +
> +static ssize_t __ref store_online(struct device *dev,
> +				  struct device_attribute *attr,
> +				  const char *buf, size_t count)
> +{
> +	struct pcpu *pcpu = container_of(dev, struct pcpu, dev);
> +	unsigned long long val;
> +	ssize_t ret;
> +
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EPERM;
> +
> +	if (kstrtoull(buf, 0, &val) < 0)
> +		return -EINVAL;
> +
> +	switch (val) {
> +	case 0:
> +		ret = xen_pcpu_down(pcpu->cpu_id);
> +		break;
> +	case 1:
> +		ret = xen_pcpu_up(pcpu->cpu_id);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	if (ret >= 0)
> +		ret = count;
> +	return ret;
> +}
> +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online);
> +
> +static bool xen_pcpu_online(uint32_t flags)
> +{
> +	return !!(flags & XEN_PCPU_FLAGS_ONLINE);
> +}
> +
> +static void pcpu_online_status(struct xenpf_pcpuinfo *info,
> +			       struct pcpu *pcpu)
> +{
> +	if (xen_pcpu_online(info->flags) &&
> +	   !xen_pcpu_online(pcpu->flags)) {
> +		/* the pcpu is onlined */
> +		pcpu->flags |= XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE);
> +	} else if (!xen_pcpu_online(info->flags) &&
> +		    xen_pcpu_online(pcpu->flags)) {
> +		/* The pcpu is offlined */
> +		pcpu->flags &= ~XEN_PCPU_FLAGS_ONLINE;
> +		kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE);
> +	}
> +}
> +
> +static struct pcpu *get_pcpu(uint32_t cpu_id)
> +{
> +	struct pcpu *pcpu;
> +
> +	list_for_each_entry(pcpu, &xen_pcpus, list) {
> +		if (pcpu->cpu_id == cpu_id)
> +			return pcpu;
> +	}
> +
> +	return NULL;
> +}
> +
> +static void pcpu_release(struct device *dev)
> +{
> +	struct pcpu *pcpu = container_of(dev, struct pcpu, dev);
> +
> +	list_del(&pcpu->list);
> +	kfree(pcpu);
> +}
> +
> +static void unregister_and_remove_pcpu(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +
> +	if (!pcpu)
> +		return;
> +
> +	dev = &pcpu->dev;
> +	if (dev->id)
> +		device_remove_file(dev, &dev_attr_online);
> +
> +	/* pcpu remove would be implicitly done */
> +	device_unregister(dev);
> +}
> +
> +static int register_pcpu(struct pcpu *pcpu)
> +{
> +	struct device *dev;
> +	int err = -EINVAL;
> +
> +	if (!pcpu)
> +		return err;
> +
> +	dev = &pcpu->dev;
> +	dev->bus = &xen_pcpu_subsys;
> +	dev->id = pcpu->cpu_id;
> +	dev->release = pcpu_release;
> +
> +	err = device_register(dev);
> +	if (err) {
> +		pcpu_release(dev);
> +		return err;
> +	}
> +
> +	/*
> +	 * Xen never offline cpu0 due to several restrictions
> +	 * and assumptions. This basically doesn't add a sys control
> +	 * to user, one cannot attempt to offline BSP.
> +	 */
> +	if (dev->id) {
> +		err = device_create_file(dev, &dev_attr_online);
> +		if (err) {
> +			device_unregister(dev);
> +			return err;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static struct pcpu *create_and_register_pcpu(struct xenpf_pcpuinfo *info)
> +{
> +	struct pcpu *pcpu;
> +	int err;
> +
> +	if (info->flags & XEN_PCPU_FLAGS_INVALID)
> +		return ERR_PTR(-ENODEV);
> +
> +	pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL);
> +	if (!pcpu)
> +		return ERR_PTR(-ENOMEM);
> +
> +	INIT_LIST_HEAD(&pcpu->list);
> +	pcpu->cpu_id = info->xen_cpuid;
> +	pcpu->flags = info->flags;
> +
> +	/* Need hold on xen_pcpu_lock before pcpu list manipulations */
> +	list_add_tail(&pcpu->list, &xen_pcpus);
> +
> +	err = register_pcpu(pcpu);
> +	if (err) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu%u\n",
> +			   info->xen_cpuid);
> +		return ERR_PTR(-ENOENT);
> +	}
> +
> +	return pcpu;
> +}
> +
> +/*
> + * Caller should hold the xen_pcpu_lock
> + */
> +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu)
> +{
> +	int ret;
> +	struct pcpu *pcpu = NULL;
> +	struct xenpf_pcpuinfo *info;
> +	struct xen_platform_op op = {
> +		.cmd                   = XENPF_get_cpuinfo,
> +		.interface_version     = XENPF_INTERFACE_VERSION,
> +		.u.pcpu_info.xen_cpuid = cpu,
> +	};
> +
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	info = &op.u.pcpu_info;
> +	if (max_cpu)
> +		*max_cpu = info->max_present;
> +
> +	pcpu = get_pcpu(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);
> +		return 0;
> +	}
> +
> +	if (!pcpu) {
> +		pcpu = create_and_register_pcpu(info);
> +		if (IS_ERR_OR_NULL(pcpu))
> +			return -ENODEV;
> +	} else
> +		pcpu_online_status(info, pcpu);
> +
> +	return 0;
> +}
> +
> +/*
> + * Sync dom0's pcpu information with xen hypervisor's
> + */
> +static int xen_sync_pcpus(void)
> +{
> +	/*
> +	 * Boot cpu always have cpu_id 0 in xen
> +	 */
> +	uint32_t cpu = 0, max_cpu = 0;
> +	int err = 0;
> +	struct pcpu *pcpu, *tmp;
> +
> +	mutex_lock(&xen_pcpu_lock);
> +
> +	while (!err && (cpu <= max_cpu)) {
> +		err = sync_pcpu(cpu, &max_cpu);
> +		cpu++;
> +	}
> +
> +	if (err)
> +		list_for_each_entry_safe(pcpu, tmp, &xen_pcpus, list)
> +			unregister_and_remove_pcpu(pcpu);
> +
> +	mutex_unlock(&xen_pcpu_lock);
> +
> +	return err;
> +}
> +
> +static void xen_pcpu_work_fn(struct work_struct *work)
> +{
> +	xen_sync_pcpus();
> +}
> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn);
> +
> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_pcpu_work);
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_pcpu_init(void)
> +{
> +	int irq, ret;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	irq = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0,
> +				      xen_pcpu_interrupt, 0,
> +				      "xen-pcpu", NULL);
> +	if (irq < 0) {
> +		pr_warning(XEN_PCPU "Failed to bind pcpu virq\n");
> +		return irq;
> +	}
> +
> +	ret = subsys_system_register(&xen_pcpu_subsys, NULL);
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to register pcpu subsys\n");
> +		goto err1;
> +	}
> +
> +	ret = xen_sync_pcpus();
> +	if (ret) {
> +		pr_warning(XEN_PCPU "Failed to sync pcpu info\n");
> +		goto err2;
> +	}
> +
> +	return 0;
> +
> +err2:
> +	bus_unregister(&xen_pcpu_subsys);
> +err1:
> +	unbind_from_irqhandler(irq, NULL);
> +	return ret;
> +}
> +arch_initcall(xen_pcpu_init);
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 486653f..61fa661 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo);
>  
> +#define XENPF_cpu_online	56
> +#define XENPF_cpu_offline	57
> +struct xenpf_cpu_ol {
> +	uint32_t cpuid;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -330,6 +337,7 @@ struct xen_platform_op {
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
>  		struct xenpf_pcpuinfo          pcpu_info;
> +		struct xenpf_cpu_ol            cpu_ol;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index a890804..0801468 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -80,6 +80,7 @@
>  #define VIRQ_CONSOLE    2  /* (DOM0) Bytes received on emergency console. */
>  #define VIRQ_DOM_EXC    3  /* (DOM0) Exceptional event for some domain.   */
>  #define VIRQ_DEBUGGER   6  /* (DOM0) A domain has paused for debugging.   */
> +#define VIRQ_PCPU_STATE 9  /* (DOM0) PCPU state changed                   */
>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16
> -- 
> 1.7.1


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 06:54:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 06:54: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 1SeKz4-0005Wt-Q1; Tue, 12 Jun 2012 06:53:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1SeKz2-0005Wm-TF
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 06:53:45 +0000
Received: from [85.158.139.83:58598] by server-4.bemta-5.messagelabs.com id
	89/8C-05858-877E6DF4; Tue, 12 Jun 2012 06:53:44 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339484021!33442142!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDIwOTc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26530 invoked from network); 12 Jun 2012 06:53:43 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 06:53:43 -0000
Received: from m2.gw.fujitsu.co.jp (unknown [10.0.50.72])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 53F063EE081
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from smail (m2 [127.0.0.1])
	by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 3AFBF45DE5C
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92])
	by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 2173045DE59
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 112471DB803E
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from g01exch-yt01.g01.fujitsu.local (g01exch-yt01.g01.fujitsu.local
	[10.128.168.145])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id AF99A1DB802C
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:35 +0900 (JST)
Received: from G01EXCH-YT03.g01.fujitsu.local (10.128.168.143) by
	g01exch-yt01.g01.fujitsu.local (10.128.168.145) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 15:53:34 +0900
Received: from pingu.sky.yk.fujitsu.co.jp (10.33.110.112) by
	g01exch-yt03.g01.fujitsu.local (10.128.168.143) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 15:53:33 +0900
Message-ID: <87hauhvx5x.fsf@jp.fujitsu.com>
MIME-Version: 1.0
Date: Tue, 12 Jun 2012 15:53:06 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
In-Reply-To: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
X-Mailer: VM 7.19 under Emacs 23.1.1
X-Originating-IP: [10.33.110.112]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

The owner support is introduced in c/s 8175, not by me.
Anyway, something is wrong with your execution trace.

> + '[' 6 -gt 5 ']'
> + sleep 1
<<< Why claim_lock() returns here???
> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/Vi

I don't know what is a problem and whether your patch resolves the issue or not.

It would be better to replace locking.sh with the RHEL5 implementation
which uses 'flock' rather than to fix it.

Thanks,
Kouya


Zhigang Wang writes:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1339421383 14400
> # Node ID eb72d7090b5956490b2f26c858cd9d896feca309
> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> tools/hotplug: fix locking
> 
> The current locking implementation would allow two processes get the lock
> simultaneously:
> 
> ++ echo 16741: /etc/xen/scripts/block
> ++ cut -d : -f 1
> + local pid=16741
> + '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
> + '[' 5 -gt 5 ']'
> + sleep 0
> + retries=6
> + '[' 6 -lt 100 ']'
> + mkdir /var/run/xen-hotplug/block
> ++ _lock_owner /var/run/xen-hotplug/block
> ++ cat /var/run/xen-hotplug/block/owner
> + local 'new_owner=16741: /etc/xen/scripts/block'
> + '[' '16741: /etc/xen/scripts/block' '!=' '16741: /etc/xen/scripts/block' ']'

> ++ echo 16741: /etc/xen/scripts/block
> ++ cut -d : -f 1
> + local pid=16741
> + '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
> + '[' 6 -gt 5 ']'
> + sleep 1
> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
> + xenstore_write backend/vbd/33/51920/node /dev/loop27
> + _xenstore_write backend/vbd/33/51920/node /dev/loop27
> + log debug 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
> + local level=debug
> + shift
> + logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
> ioctl: LOOP_SET_FD: Device or resource busy
> + xenstore-write backend/vbd/33/51920/node /dev/loop27
> + fatal losetup -r /dev/loop27 '/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img failed'
> 
> This patch removes the ownner support and fixed this issue per my test.
> 
> Kouya: would you please help to confirm this fix is correct?
> 
> Anyone has encountered this issue please help to test.
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> 
> diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
> @@ -48,32 +48,14 @@ sigerr() {
>  _claim_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(_lock_owner "$lockdir")
>    local retries=0
>  
>    while [ $retries -lt $LOCK_RETRIES ]
>    do
> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> -      _update_lock_info "$lockdir" && return
> -
> -    local new_owner=$(_lock_owner "$lockdir")
> -    if [ "$new_owner" != "$owner" ]
> -    then
> -      owner="$new_owner"
> -      retries=0
> -    else
> -      local pid=$(echo $owner | cut -d : -f 1)
> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> -      then
> -        _release_lock $lockdir
> -      fi
> -    fi
> -
> +    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
>      if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>      then
>        sleep $LOCK_SLEEPTIME
> -    else
> -      sleep 0
>      fi
>      retries=$(($retries + 1))
>    done
> @@ -91,20 +73,7 @@ _release_lock()
>  _steal_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> -  log err "Forced to steal lock on $lockdir from $owner!"
> +  log err "Forced to steal lock on $lockdir!"
>    _release_lock "$lockdir"
>    _claim_lock "$lockdir"
>  }
> -
> -
> -_lock_owner()
> -{
> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> -}
> -
> -
> -_update_lock_info()
> -{
> -  echo "$$: $0" >"$1/owner"
> -}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 06:54:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 06:54: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 1SeKz4-0005Wt-Q1; Tue, 12 Jun 2012 06:53:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1SeKz2-0005Wm-TF
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 06:53:45 +0000
Received: from [85.158.139.83:58598] by server-4.bemta-5.messagelabs.com id
	89/8C-05858-877E6DF4; Tue, 12 Jun 2012 06:53:44 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339484021!33442142!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDIwOTc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26530 invoked from network); 12 Jun 2012 06:53:43 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 06:53:43 -0000
Received: from m2.gw.fujitsu.co.jp (unknown [10.0.50.72])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 53F063EE081
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from smail (m2 [127.0.0.1])
	by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 3AFBF45DE5C
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92])
	by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 2173045DE59
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 112471DB803E
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:36 +0900 (JST)
Received: from g01exch-yt01.g01.fujitsu.local (g01exch-yt01.g01.fujitsu.local
	[10.128.168.145])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id AF99A1DB802C
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 15:53:35 +0900 (JST)
Received: from G01EXCH-YT03.g01.fujitsu.local (10.128.168.143) by
	g01exch-yt01.g01.fujitsu.local (10.128.168.145) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 15:53:34 +0900
Received: from pingu.sky.yk.fujitsu.co.jp (10.33.110.112) by
	g01exch-yt03.g01.fujitsu.local (10.128.168.143) with Microsoft SMTP
	Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 15:53:33 +0900
Message-ID: <87hauhvx5x.fsf@jp.fujitsu.com>
MIME-Version: 1.0
Date: Tue, 12 Jun 2012 15:53:06 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
In-Reply-To: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
X-Mailer: VM 7.19 under Emacs 23.1.1
X-Originating-IP: [10.33.110.112]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

The owner support is introduced in c/s 8175, not by me.
Anyway, something is wrong with your execution trace.

> + '[' 6 -gt 5 ']'
> + sleep 1
<<< Why claim_lock() returns here???
> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/Vi

I don't know what is a problem and whether your patch resolves the issue or not.

It would be better to replace locking.sh with the RHEL5 implementation
which uses 'flock' rather than to fix it.

Thanks,
Kouya


Zhigang Wang writes:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1339421383 14400
> # Node ID eb72d7090b5956490b2f26c858cd9d896feca309
> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> tools/hotplug: fix locking
> 
> The current locking implementation would allow two processes get the lock
> simultaneously:
> 
> ++ echo 16741: /etc/xen/scripts/block
> ++ cut -d : -f 1
> + local pid=16741
> + '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
> + '[' 5 -gt 5 ']'
> + sleep 0
> + retries=6
> + '[' 6 -lt 100 ']'
> + mkdir /var/run/xen-hotplug/block
> ++ _lock_owner /var/run/xen-hotplug/block
> ++ cat /var/run/xen-hotplug/block/owner
> + local 'new_owner=16741: /etc/xen/scripts/block'
> + '[' '16741: /etc/xen/scripts/block' '!=' '16741: /etc/xen/scripts/block' ']'

> ++ echo 16741: /etc/xen/scripts/block
> ++ cut -d : -f 1
> + local pid=16741
> + '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
> + '[' 6 -gt 5 ']'
> + sleep 1
> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
> + xenstore_write backend/vbd/33/51920/node /dev/loop27
> + _xenstore_write backend/vbd/33/51920/node /dev/loop27
> + log debug 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
> + local level=debug
> + shift
> + logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
> ioctl: LOOP_SET_FD: Device or resource busy
> + xenstore-write backend/vbd/33/51920/node /dev/loop27
> + fatal losetup -r /dev/loop27 '/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img failed'
> 
> This patch removes the ownner support and fixed this issue per my test.
> 
> Kouya: would you please help to confirm this fix is correct?
> 
> Anyone has encountered this issue please help to test.
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> 
> diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
> @@ -48,32 +48,14 @@ sigerr() {
>  _claim_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(_lock_owner "$lockdir")
>    local retries=0
>  
>    while [ $retries -lt $LOCK_RETRIES ]
>    do
> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> -      _update_lock_info "$lockdir" && return
> -
> -    local new_owner=$(_lock_owner "$lockdir")
> -    if [ "$new_owner" != "$owner" ]
> -    then
> -      owner="$new_owner"
> -      retries=0
> -    else
> -      local pid=$(echo $owner | cut -d : -f 1)
> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> -      then
> -        _release_lock $lockdir
> -      fi
> -    fi
> -
> +    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
>      if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>      then
>        sleep $LOCK_SLEEPTIME
> -    else
> -      sleep 0
>      fi
>      retries=$(($retries + 1))
>    done
> @@ -91,20 +73,7 @@ _release_lock()
>  _steal_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> -  log err "Forced to steal lock on $lockdir from $owner!"
> +  log err "Forced to steal lock on $lockdir!"
>    _release_lock "$lockdir"
>    _claim_lock "$lockdir"
>  }
> -
> -
> -_lock_owner()
> -{
> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> -}
> -
> -
> -_update_lock_info()
> -{
> -  echo "$$: $0" >"$1/owner"
> -}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 07:00:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 07: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 1SeL56-0005ga-PQ; Tue, 12 Jun 2012 07:00: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 1SeL55-0005gU-S0
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 07:00:00 +0000
Received: from [85.158.143.35:26416] by server-2.bemta-4.messagelabs.com id
	E7/65-17938-FE8E6DF4; Tue, 12 Jun 2012 06:59:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339484398!4796862!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29237 invoked from network); 12 Jun 2012 06:59:58 -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; 12 Jun 2012 06:59:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 07:59:52 +0100
Message-Id: <4FD70533020000780008952E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 08:00:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.05.12 at 13:27, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 31 May 2012, Jan Beulich wrote:
>> Legacy (non-pvops) gntdev drivers may require this to be done when the
>> number of grants intended to be used simultaneously exceeds a certain
>> driver specific default limit.
>> 
>> Change in v2: Double the number requested, as we need to account for
>> the allocations needing to happen in contiguous chunks. The worst case
>> number would be max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
>> but in order to keep things simple just use 2 * max_req * max_seg.
>> 
>> Change in v3: introduce MAX_GRANTS(), and add a comment explaining its
>> definition.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I think it is OK, I'll submit it as a bug fix for QEMU 1.1.
> 
> It should be applied to qemu-xen-traditional too.

This is commit 64c27e5b1fdb6d94bdc0bda3b1869d7383a35c65 in
git.qemu.org/?p=qemu.git.

Jan

>> --- a/hw/xen_disk.c
>> +++ b/hw/xen_disk.c
>> @@ -537,6 +537,15 @@ static void blk_bh(void *opaque)
>>      blk_handle_requests(blkdev);
>>  }
>>  
>> +/*
>> + * We need to account for the grant allocations requiring contiguous
>> + * chunks; the worst case number would be
>> + *     max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
>> + * but in order to keep things simple just use
>> + *     2 * max_req * max_seg.
>> + */
>> +#define MAX_GRANTS(max_req, max_seg) (2 * (max_req) * (max_seg))
>> +
>>  static void blk_alloc(struct XenDevice *xendev)
>>  {
>>      struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, 
> xendev);
>> @@ -548,6 +557,11 @@ static void blk_alloc(struct XenDevice *
>>      if (xen_mode != XEN_EMULATE) {
>>          batch_maps = 1;
>>      }
>> +    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
>> +            MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < 0) {
>> +        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
>> +                      strerror(errno));
>> +    }
>>  }
>>  
>>  static int blk_init(struct XenDevice *xendev)
>> 
>> 
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 07:00:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 07: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 1SeL56-0005ga-PQ; Tue, 12 Jun 2012 07:00: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 1SeL55-0005gU-S0
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 07:00:00 +0000
Received: from [85.158.143.35:26416] by server-2.bemta-4.messagelabs.com id
	E7/65-17938-FE8E6DF4; Tue, 12 Jun 2012 06:59:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339484398!4796862!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29237 invoked from network); 12 Jun 2012 06:59:58 -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; 12 Jun 2012 06:59:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 07:59:52 +0100
Message-Id: <4FD70533020000780008952E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 08:00:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4FC770E20200007800087298@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1205311226060.26786@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH,
 v3] qemu/xendisk: set maximum number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.05.12 at 13:27, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 31 May 2012, Jan Beulich wrote:
>> Legacy (non-pvops) gntdev drivers may require this to be done when the
>> number of grants intended to be used simultaneously exceeds a certain
>> driver specific default limit.
>> 
>> Change in v2: Double the number requested, as we need to account for
>> the allocations needing to happen in contiguous chunks. The worst case
>> number would be max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
>> but in order to keep things simple just use 2 * max_req * max_seg.
>> 
>> Change in v3: introduce MAX_GRANTS(), and add a comment explaining its
>> definition.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I think it is OK, I'll submit it as a bug fix for QEMU 1.1.
> 
> It should be applied to qemu-xen-traditional too.

This is commit 64c27e5b1fdb6d94bdc0bda3b1869d7383a35c65 in
git.qemu.org/?p=qemu.git.

Jan

>> --- a/hw/xen_disk.c
>> +++ b/hw/xen_disk.c
>> @@ -537,6 +537,15 @@ static void blk_bh(void *opaque)
>>      blk_handle_requests(blkdev);
>>  }
>>  
>> +/*
>> + * We need to account for the grant allocations requiring contiguous
>> + * chunks; the worst case number would be
>> + *     max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
>> + * but in order to keep things simple just use
>> + *     2 * max_req * max_seg.
>> + */
>> +#define MAX_GRANTS(max_req, max_seg) (2 * (max_req) * (max_seg))
>> +
>>  static void blk_alloc(struct XenDevice *xendev)
>>  {
>>      struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, 
> xendev);
>> @@ -548,6 +557,11 @@ static void blk_alloc(struct XenDevice *
>>      if (xen_mode != XEN_EMULATE) {
>>          batch_maps = 1;
>>      }
>> +    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
>> +            MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < 0) {
>> +        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
>> +                      strerror(errno));
>> +    }
>>  }
>>  
>>  static int blk_init(struct XenDevice *xendev)
>> 
>> 
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 07:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 07:52: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 1SeLse-0006Dp-W2; Tue, 12 Jun 2012 07:51:12 +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 1SeLsc-0006Dh-Tm
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 07:51:11 +0000
Received: from [85.158.139.83:46702] by server-9.bemta-5.messagelabs.com id
	17/84-29678-EE4F6DF4; Tue, 12 Jun 2012 07:51:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339487468!29152686!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxNTE3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4705 invoked from network); 12 Jun 2012 07:51:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-182.messagelabs.com with SMTP;
	12 Jun 2012 07:51:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 12 Jun 2012 00:51:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="111057321"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 12 Jun 2012 00:51:07 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 12 Jun 2012 00:51:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Tue, 12 Jun 2012 15:51:05 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic
	context
Thread-Index: Ac1IcB2Zmrg1zlUCRGutICBqPpSu9A==
Date: Tue, 12 Jun 2012 07:51:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335228748@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_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/mce: schedule a workqueue to avoid sleep in
 atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Tue, 12 Jun 2012 23:11:16 +0800
Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic con=
text

copy_to_user might sleep and print a stack trace if it is executed
in an atomic spinlock context.

This patch schedule a workqueue for IRQ handler to poll the data,
and use mutex instead of spinlock, so copy_to_user sleep in atomic
context would not occur.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 72e87d2..804aa3c 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -55,7 +55,7 @@ static struct mc_info g_mi;
 static struct mcinfo_logical_cpu *g_physinfo;
 static uint32_t ncpus;
=20
-static DEFINE_SPINLOCK(mcelog_lock);
+static DEFINE_MUTEX(mcelog_lock);
=20
 static struct xen_mce_log xen_mcelog =3D {
 	.signature	=3D XEN_MCE_LOG_SIGNATURE,
@@ -106,7 +106,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, c=
har __user *ubuf,
 	unsigned num;
 	int i, err;
=20
-	spin_lock(&mcelog_lock);
+	mutex_lock(&mcelog_lock);
=20
 	num =3D xen_mcelog.next;
=20
@@ -130,7 +130,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, c=
har __user *ubuf,
 		err =3D -EFAULT;
=20
 out:
-	spin_unlock(&mcelog_lock);
+	mutex_unlock(&mcelog_lock);
=20
 	return err ? err : buf - ubuf;
 }
@@ -310,12 +310,11 @@ static int mc_queue_handle(uint32_t flags)
 }
=20
 /* virq handler for machine check error info*/
-static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
+static void xen_mce_work_fn(struct work_struct *work)
 {
 	int err;
-	unsigned long tmp;
=20
-	spin_lock_irqsave(&mcelog_lock, tmp);
+	mutex_lock(&mcelog_lock);
=20
 	/* urgent mc_info */
 	err =3D mc_queue_handle(XEN_MC_URGENT);
@@ -330,8 +329,13 @@ static irqreturn_t xen_mce_interrupt(int irq, void *de=
v_id)
 		pr_err(XEN_MCELOG
 		       "Failed to handle nonurgent mc_info queue.\n");
=20
-	spin_unlock_irqrestore(&mcelog_lock, tmp);
+	mutex_unlock(&mcelog_lock);
+}
+static DECLARE_WORK(xen_mce_work, xen_mce_work_fn);
=20
+static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_mce_work);
 	return IRQ_HANDLED;
 }
=20
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-schedule-a-workqueue-to-avoid-sleep-in-atomi.patch"
Content-Description: 0001-xen-mce-schedule-a-workqueue-to-avoid-sleep-in-atomi.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-schedule-a-workqueue-to-avoid-sleep-in-atomi.patch";
	size=2441; creation-date="Tue, 12 Jun 2012 07:45:53 GMT";
	modification-date="Tue, 12 Jun 2012 15:39:38 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhYTJjZTc0NDBmMTYwMDIyNjZkYzg0NjRmNzQ5OTkyZDBjOGFjMGU1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogVHVlLCAxMiBKdW4gMjAxMiAyMzoxMToxNiArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IHNjaGVkdWxlIGEgd29ya3F1ZXVlIHRvIGF2b2lkIHNsZWVwIGluIGF0b21pYyBjb250
ZXh0Cgpjb3B5X3RvX3VzZXIgbWlnaHQgc2xlZXAgYW5kIHByaW50IGEgc3RhY2sgdHJhY2UgaWYg
aXQgaXMgZXhlY3V0ZWQKaW4gYW4gYXRvbWljIHNwaW5sb2NrIGNvbnRleHQuCgpUaGlzIHBhdGNo
IHNjaGVkdWxlIGEgd29ya3F1ZXVlIGZvciBJUlEgaGFuZGxlciB0byBwb2xsIHRoZSBkYXRhLAph
bmQgdXNlIG11dGV4IGluc3RlYWQgb2Ygc3BpbmxvY2ssIHNvIGNvcHlfdG9fdXNlciBzbGVlcCBp
biBhdG9taWMKY29udGV4dCB3b3VsZCBub3Qgb2NjdXIuCgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpTdWdnZXN0ZWQtYnk6IEtvbnJh
ZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KU2lnbmVkLW9mZi1ieTog
TGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4vbWNl
bG9nLmMgfCAgIDE4ICsrKysrKysrKysrLS0tLS0tLQogMSBmaWxlcyBjaGFuZ2VkLCAxMSBpbnNl
cnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxv
Zy5jIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKaW5kZXggNzJlODdkMi4uODA0YWEzYyAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vbWNlbG9nLmMKKysrIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKQEAg
LTU1LDcgKzU1LDcgQEAgc3RhdGljIHN0cnVjdCBtY19pbmZvIGdfbWk7CiBzdGF0aWMgc3RydWN0
IG1jaW5mb19sb2dpY2FsX2NwdSAqZ19waHlzaW5mbzsKIHN0YXRpYyB1aW50MzJfdCBuY3B1czsK
IAotc3RhdGljIERFRklORV9TUElOTE9DSyhtY2Vsb2dfbG9jayk7CitzdGF0aWMgREVGSU5FX01V
VEVYKG1jZWxvZ19sb2NrKTsKIAogc3RhdGljIHN0cnVjdCB4ZW5fbWNlX2xvZyB4ZW5fbWNlbG9n
ID0gewogCS5zaWduYXR1cmUJPSBYRU5fTUNFX0xPR19TSUdOQVRVUkUsCkBAIC0xMDYsNyArMTA2
LDcgQEAgc3RhdGljIHNzaXplX3QgeGVuX21jZV9jaHJkZXZfcmVhZChzdHJ1Y3QgZmlsZSAqZmls
cCwgY2hhciBfX3VzZXIgKnVidWYsCiAJdW5zaWduZWQgbnVtOwogCWludCBpLCBlcnI7CiAKLQlz
cGluX2xvY2soJm1jZWxvZ19sb2NrKTsKKwltdXRleF9sb2NrKCZtY2Vsb2dfbG9jayk7CiAKIAlu
dW0gPSB4ZW5fbWNlbG9nLm5leHQ7CiAKQEAgLTEzMCw3ICsxMzAsNyBAQCBzdGF0aWMgc3NpemVf
dCB4ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFyIF9fdXNlciAqdWJ1
ZiwKIAkJZXJyID0gLUVGQVVMVDsKIAogb3V0OgotCXNwaW5fdW5sb2NrKCZtY2Vsb2dfbG9jayk7
CisJbXV0ZXhfdW5sb2NrKCZtY2Vsb2dfbG9jayk7CiAKIAlyZXR1cm4gZXJyID8gZXJyIDogYnVm
IC0gdWJ1ZjsKIH0KQEAgLTMxMCwxMiArMzEwLDExIEBAIHN0YXRpYyBpbnQgbWNfcXVldWVfaGFu
ZGxlKHVpbnQzMl90IGZsYWdzKQogfQogCiAvKiB2aXJxIGhhbmRsZXIgZm9yIG1hY2hpbmUgY2hl
Y2sgZXJyb3IgaW5mbyovCi1zdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9pbnRlcnJ1cHQoaW50
IGlycSwgdm9pZCAqZGV2X2lkKQorc3RhdGljIHZvaWQgeGVuX21jZV93b3JrX2ZuKHN0cnVjdCB3
b3JrX3N0cnVjdCAqd29yaykKIHsKIAlpbnQgZXJyOwotCXVuc2lnbmVkIGxvbmcgdG1wOwogCi0J
c3Bpbl9sb2NrX2lycXNhdmUoJm1jZWxvZ19sb2NrLCB0bXApOworCW11dGV4X2xvY2soJm1jZWxv
Z19sb2NrKTsKIAogCS8qIHVyZ2VudCBtY19pbmZvICovCiAJZXJyID0gbWNfcXVldWVfaGFuZGxl
KFhFTl9NQ19VUkdFTlQpOwpAQCAtMzMwLDggKzMyOSwxMyBAQCBzdGF0aWMgaXJxcmV0dXJuX3Qg
eGVuX21jZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQogCQlwcl9lcnIoWEVOX01D
RUxPRwogCQkgICAgICAgIkZhaWxlZCB0byBoYW5kbGUgbm9udXJnZW50IG1jX2luZm8gcXVldWUu
XG4iKTsKIAotCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJm1jZWxvZ19sb2NrLCB0bXApOworCW11
dGV4X3VubG9jaygmbWNlbG9nX2xvY2spOworfQorc3RhdGljIERFQ0xBUkVfV09SSyh4ZW5fbWNl
X3dvcmssIHhlbl9tY2Vfd29ya19mbik7CiAKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fbWNlX2lu
dGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaWQpCit7CisJc2NoZWR1bGVfd29yaygmeGVuX21j
ZV93b3JrKTsKIAlyZXR1cm4gSVJRX0hBTkRMRUQ7CiB9CiAKLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 12 07:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 07:52: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 1SeLse-0006Dp-W2; Tue, 12 Jun 2012 07:51:12 +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 1SeLsc-0006Dh-Tm
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 07:51:11 +0000
Received: from [85.158.139.83:46702] by server-9.bemta-5.messagelabs.com id
	17/84-29678-EE4F6DF4; Tue, 12 Jun 2012 07:51:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339487468!29152686!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxNTE3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4705 invoked from network); 12 Jun 2012 07:51:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-182.messagelabs.com with SMTP;
	12 Jun 2012 07:51:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 12 Jun 2012 00:51:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="111057321"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 12 Jun 2012 00:51:07 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 12 Jun 2012 00:51:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Tue, 12 Jun 2012 15:51:05 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic
	context
Thread-Index: Ac1IcB2Zmrg1zlUCRGutICBqPpSu9A==
Date: Tue, 12 Jun 2012 07:51:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335228748@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_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/mce: schedule a workqueue to avoid sleep in
 atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Tue, 12 Jun 2012 23:11:16 +0800
Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic con=
text

copy_to_user might sleep and print a stack trace if it is executed
in an atomic spinlock context.

This patch schedule a workqueue for IRQ handler to poll the data,
and use mutex instead of spinlock, so copy_to_user sleep in atomic
context would not occur.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 72e87d2..804aa3c 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -55,7 +55,7 @@ static struct mc_info g_mi;
 static struct mcinfo_logical_cpu *g_physinfo;
 static uint32_t ncpus;
=20
-static DEFINE_SPINLOCK(mcelog_lock);
+static DEFINE_MUTEX(mcelog_lock);
=20
 static struct xen_mce_log xen_mcelog =3D {
 	.signature	=3D XEN_MCE_LOG_SIGNATURE,
@@ -106,7 +106,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, c=
har __user *ubuf,
 	unsigned num;
 	int i, err;
=20
-	spin_lock(&mcelog_lock);
+	mutex_lock(&mcelog_lock);
=20
 	num =3D xen_mcelog.next;
=20
@@ -130,7 +130,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, c=
har __user *ubuf,
 		err =3D -EFAULT;
=20
 out:
-	spin_unlock(&mcelog_lock);
+	mutex_unlock(&mcelog_lock);
=20
 	return err ? err : buf - ubuf;
 }
@@ -310,12 +310,11 @@ static int mc_queue_handle(uint32_t flags)
 }
=20
 /* virq handler for machine check error info*/
-static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
+static void xen_mce_work_fn(struct work_struct *work)
 {
 	int err;
-	unsigned long tmp;
=20
-	spin_lock_irqsave(&mcelog_lock, tmp);
+	mutex_lock(&mcelog_lock);
=20
 	/* urgent mc_info */
 	err =3D mc_queue_handle(XEN_MC_URGENT);
@@ -330,8 +329,13 @@ static irqreturn_t xen_mce_interrupt(int irq, void *de=
v_id)
 		pr_err(XEN_MCELOG
 		       "Failed to handle nonurgent mc_info queue.\n");
=20
-	spin_unlock_irqrestore(&mcelog_lock, tmp);
+	mutex_unlock(&mcelog_lock);
+}
+static DECLARE_WORK(xen_mce_work, xen_mce_work_fn);
=20
+static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
+{
+	schedule_work(&xen_mce_work);
 	return IRQ_HANDLED;
 }
=20
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-schedule-a-workqueue-to-avoid-sleep-in-atomi.patch"
Content-Description: 0001-xen-mce-schedule-a-workqueue-to-avoid-sleep-in-atomi.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-schedule-a-workqueue-to-avoid-sleep-in-atomi.patch";
	size=2441; creation-date="Tue, 12 Jun 2012 07:45:53 GMT";
	modification-date="Tue, 12 Jun 2012 15:39:38 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhYTJjZTc0NDBmMTYwMDIyNjZkYzg0NjRmNzQ5OTkyZDBjOGFjMGU1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogVHVlLCAxMiBKdW4gMjAxMiAyMzoxMToxNiArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IHNjaGVkdWxlIGEgd29ya3F1ZXVlIHRvIGF2b2lkIHNsZWVwIGluIGF0b21pYyBjb250
ZXh0Cgpjb3B5X3RvX3VzZXIgbWlnaHQgc2xlZXAgYW5kIHByaW50IGEgc3RhY2sgdHJhY2UgaWYg
aXQgaXMgZXhlY3V0ZWQKaW4gYW4gYXRvbWljIHNwaW5sb2NrIGNvbnRleHQuCgpUaGlzIHBhdGNo
IHNjaGVkdWxlIGEgd29ya3F1ZXVlIGZvciBJUlEgaGFuZGxlciB0byBwb2xsIHRoZSBkYXRhLAph
bmQgdXNlIG11dGV4IGluc3RlYWQgb2Ygc3BpbmxvY2ssIHNvIGNvcHlfdG9fdXNlciBzbGVlcCBp
biBhdG9taWMKY29udGV4dCB3b3VsZCBub3Qgb2NjdXIuCgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpTdWdnZXN0ZWQtYnk6IEtvbnJh
ZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KU2lnbmVkLW9mZi1ieTog
TGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4vbWNl
bG9nLmMgfCAgIDE4ICsrKysrKysrKysrLS0tLS0tLQogMSBmaWxlcyBjaGFuZ2VkLCAxMSBpbnNl
cnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL21jZWxv
Zy5jIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKaW5kZXggNzJlODdkMi4uODA0YWEzYyAxMDA2NDQK
LS0tIGEvZHJpdmVycy94ZW4vbWNlbG9nLmMKKysrIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKQEAg
LTU1LDcgKzU1LDcgQEAgc3RhdGljIHN0cnVjdCBtY19pbmZvIGdfbWk7CiBzdGF0aWMgc3RydWN0
IG1jaW5mb19sb2dpY2FsX2NwdSAqZ19waHlzaW5mbzsKIHN0YXRpYyB1aW50MzJfdCBuY3B1czsK
IAotc3RhdGljIERFRklORV9TUElOTE9DSyhtY2Vsb2dfbG9jayk7CitzdGF0aWMgREVGSU5FX01V
VEVYKG1jZWxvZ19sb2NrKTsKIAogc3RhdGljIHN0cnVjdCB4ZW5fbWNlX2xvZyB4ZW5fbWNlbG9n
ID0gewogCS5zaWduYXR1cmUJPSBYRU5fTUNFX0xPR19TSUdOQVRVUkUsCkBAIC0xMDYsNyArMTA2
LDcgQEAgc3RhdGljIHNzaXplX3QgeGVuX21jZV9jaHJkZXZfcmVhZChzdHJ1Y3QgZmlsZSAqZmls
cCwgY2hhciBfX3VzZXIgKnVidWYsCiAJdW5zaWduZWQgbnVtOwogCWludCBpLCBlcnI7CiAKLQlz
cGluX2xvY2soJm1jZWxvZ19sb2NrKTsKKwltdXRleF9sb2NrKCZtY2Vsb2dfbG9jayk7CiAKIAlu
dW0gPSB4ZW5fbWNlbG9nLm5leHQ7CiAKQEAgLTEzMCw3ICsxMzAsNyBAQCBzdGF0aWMgc3NpemVf
dCB4ZW5fbWNlX2NocmRldl9yZWFkKHN0cnVjdCBmaWxlICpmaWxwLCBjaGFyIF9fdXNlciAqdWJ1
ZiwKIAkJZXJyID0gLUVGQVVMVDsKIAogb3V0OgotCXNwaW5fdW5sb2NrKCZtY2Vsb2dfbG9jayk7
CisJbXV0ZXhfdW5sb2NrKCZtY2Vsb2dfbG9jayk7CiAKIAlyZXR1cm4gZXJyID8gZXJyIDogYnVm
IC0gdWJ1ZjsKIH0KQEAgLTMxMCwxMiArMzEwLDExIEBAIHN0YXRpYyBpbnQgbWNfcXVldWVfaGFu
ZGxlKHVpbnQzMl90IGZsYWdzKQogfQogCiAvKiB2aXJxIGhhbmRsZXIgZm9yIG1hY2hpbmUgY2hl
Y2sgZXJyb3IgaW5mbyovCi1zdGF0aWMgaXJxcmV0dXJuX3QgeGVuX21jZV9pbnRlcnJ1cHQoaW50
IGlycSwgdm9pZCAqZGV2X2lkKQorc3RhdGljIHZvaWQgeGVuX21jZV93b3JrX2ZuKHN0cnVjdCB3
b3JrX3N0cnVjdCAqd29yaykKIHsKIAlpbnQgZXJyOwotCXVuc2lnbmVkIGxvbmcgdG1wOwogCi0J
c3Bpbl9sb2NrX2lycXNhdmUoJm1jZWxvZ19sb2NrLCB0bXApOworCW11dGV4X2xvY2soJm1jZWxv
Z19sb2NrKTsKIAogCS8qIHVyZ2VudCBtY19pbmZvICovCiAJZXJyID0gbWNfcXVldWVfaGFuZGxl
KFhFTl9NQ19VUkdFTlQpOwpAQCAtMzMwLDggKzMyOSwxMyBAQCBzdGF0aWMgaXJxcmV0dXJuX3Qg
eGVuX21jZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQogCQlwcl9lcnIoWEVOX01D
RUxPRwogCQkgICAgICAgIkZhaWxlZCB0byBoYW5kbGUgbm9udXJnZW50IG1jX2luZm8gcXVldWUu
XG4iKTsKIAotCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJm1jZWxvZ19sb2NrLCB0bXApOworCW11
dGV4X3VubG9jaygmbWNlbG9nX2xvY2spOworfQorc3RhdGljIERFQ0xBUkVfV09SSyh4ZW5fbWNl
X3dvcmssIHhlbl9tY2Vfd29ya19mbik7CiAKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fbWNlX2lu
dGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaWQpCit7CisJc2NoZWR1bGVfd29yaygmeGVuX21j
ZV93b3JrKTsKIAlyZXR1cm4gSVJRX0hBTkRMRUQ7CiB9CiAKLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335228748SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 12 08:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 08:09: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 1SeM9x-0006qG-Dq; Tue, 12 Jun 2012 08:09:05 +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 1SeM9w-0006qB-GH
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 08:09:04 +0000
Received: from [193.109.254.147:35645] by server-1.bemta-14.messagelabs.com id
	49/1E-08067-F19F6DF4; Tue, 12 Jun 2012 08:09:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339488541!2089384!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxNTE3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29919 invoked from network); 12 Jun 2012 08:09:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Jun 2012 08:09:02 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 12 Jun 2012 01:09:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="155157379"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 12 Jun 2012 01:09:00 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 12 Jun 2012 01:09:00 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Tue, 12 Jun 2012 16:08:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
	atomic context
Thread-Index: AQHNSAYbxEyD+XUzS/eqorQpXCRDr5b2UJwg
Date: Tue, 12 Jun 2012 08:08:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335228869@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335221654@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
	<20120611191214.GL14535@phenom.dumpdata.com>
In-Reply-To: <20120611191214.GL14535@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>> From db6c0ac9372c6fbc3637ec4216830e7ee01b31aa Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Mon, 11 Jun 2012 19:21:24 +0800
>> Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep
>> in atomic context 
>> 
>> copy_to_user might sleep and print a stack trace if it is executed
>> in an atomic spinlock context. This patch add a mutex lock and a
>> buffer to avoid the issue.
>> 
>> This patch also change the manipulation of mcelog_lock from
>> spin_lock_irqsave to spin_trylock to avoid deadlock, since
>> mcelog_lock is used at normal process context and
>> mce context (which is async exception context that could
> 
> Could you explain in more details what is 'async exception
> context' and 'mce context' ?

mce context, I meant here is, in mce scenario (originally triggerred and handled by hypervisor mce logic and then virq to dom0 mcelog handler). It's 'async' (unlike other exception which is 'sync'), and could not be protected by spin_lock_irqsave.

> 
>> not protected by spin_lock_irqsave). When fail to get spinlock,
>> mc_info would be transferred by hypervisor next time.
> 
> What does that mean? How would 'mcelog' program get the data?

It fail to get mc_info this time if spin trylock fail. Error info still kept at hypervisor mc data structure. When next mce occur, dom0 mcelog would get these mc_info then. Hmm, ugly.

> 
>> 
>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---
>>  drivers/xen/mcelog.c |   38 +++++++++++++++++++++++++++++++-------
>>  1 files changed, 31 insertions(+), 7 deletions(-)
>> 
>> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
>> index 72e87d2..fac29e4 100644
>> --- a/drivers/xen/mcelog.c
>> +++ b/drivers/xen/mcelog.c
>> @@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo; 
>> static uint32_t ncpus; 
>> 
>>  static DEFINE_SPINLOCK(mcelog_lock);
>> +static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
>> 
>>  static struct xen_mce_log xen_mcelog = {
>>  	.signature	= XEN_MCE_LOG_SIGNATURE,
>>  	.len		= XEN_MCE_LOG_LEN,
>>  	.recordlen	= sizeof(struct xen_mce),
>>  };
>> +static struct xen_mce_log xen_mcelog_u;
>> 
>>  static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
>>  static int xen_mce_chrdev_open_count;	/* #times opened */
>> @@ -106,9 +108,19 @@ static ssize_t xen_mce_chrdev_read(struct file
>>  	*filp, char __user *ubuf,  	unsigned num; int i, err;
>> 
>> +	/*
>> +	 * copy_to_user might sleep and print a stack trace
>> +	 * if it is executed in an atomic spinlock context +	 */
>> +	mutex_lock(&xen_mce_chrdev_read_mutex);
>> +
>>  	spin_lock(&mcelog_lock);
>> +	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
>> 
>>  	num = xen_mcelog.next;
>> +	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
>> +	xen_mcelog.next = 0; +	spin_unlock(&mcelog_lock);
>> 
>>  	/* Only supports full reads right now */
>>  	err = -EINVAL;
>> @@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file
>> *filp, char __user *ubuf, 
>> 
>>  	err = 0;
>>  	for (i = 0; i < num; i++) {
>> -		struct xen_mce *m = &xen_mcelog.entry[i];
>> +		struct xen_mce *m = &xen_mcelog_u.entry[i];
>> 
>>  		err |= copy_to_user(buf, m, sizeof(*m));
>>  		buf += sizeof(*m);
>>  	}
>> 
>> -	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
>> -	xen_mcelog.next = 0;
>> +	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
>> +	xen_mcelog_u.next = 0; 
>> 
>>  	if (err)
>>  		err = -EFAULT;
>> 
>>  out:
>> -	spin_unlock(&mcelog_lock);
>> +	mutex_unlock(&xen_mce_chrdev_read_mutex);
>> 
>>  	return err ? err : buf - ubuf;
>>  }
>> @@ -313,9 +325,21 @@ static int mc_queue_handle(uint32_t flags)
>>  static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)  {
>>  	int err;
>> -	unsigned long tmp;
>> 
>> -	spin_lock_irqsave(&mcelog_lock, tmp);
>> +	/*
>> +	 * mcelog_lock is used at normal process context and
>> +	 * mce context (which is async exception context that could
>> +	 * not protected by spin_lock_irqsave).
>> +	 *
>> +	 * use spin_trylock to avoid deadlock. When fail to get spinlock,
>> +	 * mc_info would be transferred by hypervisor next time. +	 */
>> +	if (unlikely(!spin_trylock(&mcelog_lock))) {
>> +		pr_err(XEN_MCELOG
>> +		       "Failed to get mcelog_lock, mc_info would "
>> +		       "be transferred by hypervisor next time.\n");
> 
> Ugh. Why the printk? How does this benefit the user? If it
> recovers - which I presume "..next time" means then it should be OK?
> 
> What does 'transferred by hypervisor' mean actually?
> 
> Would it be better to schedule a workqueue to poll the data? Perhaps
> that is how this whole IRQ handler should be done - it kicks of an
> IRQ handler that de-spolls the data?

Yep, much much better!
have updated patch accordingly and sent out.

Thanks,
Jinsong

> 
>> +		return IRQ_NONE;
>> +	}
>> 
>>  	/* urgent mc_info */
>>  	err = mc_queue_handle(XEN_MC_URGENT);
>> @@ -330,7 +354,7 @@ static irqreturn_t xen_mce_interrupt(int irq,
>>  		       void *dev_id)  		pr_err(XEN_MCELOG "Failed to handle
>> nonurgent mc_info queue.\n"); 
>> 
>> -	spin_unlock_irqrestore(&mcelog_lock, tmp);
>> +	spin_unlock(&mcelog_lock);
>> 
>>  	return IRQ_HANDLED;
>>  }
>> --
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 08:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 08:09: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 1SeM9x-0006qG-Dq; Tue, 12 Jun 2012 08:09:05 +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 1SeM9w-0006qB-GH
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 08:09:04 +0000
Received: from [193.109.254.147:35645] by server-1.bemta-14.messagelabs.com id
	49/1E-08067-F19F6DF4; Tue, 12 Jun 2012 08:09:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339488541!2089384!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxNTE3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29919 invoked from network); 12 Jun 2012 08:09:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Jun 2012 08:09:02 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 12 Jun 2012 01:09:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="155157379"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 12 Jun 2012 01:09:00 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 12 Jun 2012 01:09:00 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Tue, 12 Jun 2012 16:08:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep in
	atomic context
Thread-Index: AQHNSAYbxEyD+XUzS/eqorQpXCRDr5b2UJwg
Date: Tue, 12 Jun 2012 08:08:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335228869@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335221654@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC8292335225796@SHSMSX101.ccr.corp.intel.com>
	<20120611191214.GL14535@phenom.dumpdata.com>
In-Reply-To: <20120611191214.GL14535@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: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: Add mutex lock and buffer to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>> From db6c0ac9372c6fbc3637ec4216830e7ee01b31aa Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Mon, 11 Jun 2012 19:21:24 +0800
>> Subject: [PATCH] xen/mce: Add mutex lock and buffer to avoid sleep
>> in atomic context 
>> 
>> copy_to_user might sleep and print a stack trace if it is executed
>> in an atomic spinlock context. This patch add a mutex lock and a
>> buffer to avoid the issue.
>> 
>> This patch also change the manipulation of mcelog_lock from
>> spin_lock_irqsave to spin_trylock to avoid deadlock, since
>> mcelog_lock is used at normal process context and
>> mce context (which is async exception context that could
> 
> Could you explain in more details what is 'async exception
> context' and 'mce context' ?

mce context, I meant here is, in mce scenario (originally triggerred and handled by hypervisor mce logic and then virq to dom0 mcelog handler). It's 'async' (unlike other exception which is 'sync'), and could not be protected by spin_lock_irqsave.

> 
>> not protected by spin_lock_irqsave). When fail to get spinlock,
>> mc_info would be transferred by hypervisor next time.
> 
> What does that mean? How would 'mcelog' program get the data?

It fail to get mc_info this time if spin trylock fail. Error info still kept at hypervisor mc data structure. When next mce occur, dom0 mcelog would get these mc_info then. Hmm, ugly.

> 
>> 
>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---
>>  drivers/xen/mcelog.c |   38 +++++++++++++++++++++++++++++++-------
>>  1 files changed, 31 insertions(+), 7 deletions(-)
>> 
>> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
>> index 72e87d2..fac29e4 100644
>> --- a/drivers/xen/mcelog.c
>> +++ b/drivers/xen/mcelog.c
>> @@ -56,12 +56,14 @@ static struct mcinfo_logical_cpu *g_physinfo; 
>> static uint32_t ncpus; 
>> 
>>  static DEFINE_SPINLOCK(mcelog_lock);
>> +static DEFINE_MUTEX(xen_mce_chrdev_read_mutex);
>> 
>>  static struct xen_mce_log xen_mcelog = {
>>  	.signature	= XEN_MCE_LOG_SIGNATURE,
>>  	.len		= XEN_MCE_LOG_LEN,
>>  	.recordlen	= sizeof(struct xen_mce),
>>  };
>> +static struct xen_mce_log xen_mcelog_u;
>> 
>>  static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
>>  static int xen_mce_chrdev_open_count;	/* #times opened */
>> @@ -106,9 +108,19 @@ static ssize_t xen_mce_chrdev_read(struct file
>>  	*filp, char __user *ubuf,  	unsigned num; int i, err;
>> 
>> +	/*
>> +	 * copy_to_user might sleep and print a stack trace
>> +	 * if it is executed in an atomic spinlock context +	 */
>> +	mutex_lock(&xen_mce_chrdev_read_mutex);
>> +
>>  	spin_lock(&mcelog_lock);
>> +	memcpy(&xen_mcelog_u, &xen_mcelog, sizeof(struct xen_mce_log));
>> 
>>  	num = xen_mcelog.next;
>> +	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
>> +	xen_mcelog.next = 0; +	spin_unlock(&mcelog_lock);
>> 
>>  	/* Only supports full reads right now */
>>  	err = -EINVAL;
>> @@ -117,20 +129,20 @@ static ssize_t xen_mce_chrdev_read(struct file
>> *filp, char __user *ubuf, 
>> 
>>  	err = 0;
>>  	for (i = 0; i < num; i++) {
>> -		struct xen_mce *m = &xen_mcelog.entry[i];
>> +		struct xen_mce *m = &xen_mcelog_u.entry[i];
>> 
>>  		err |= copy_to_user(buf, m, sizeof(*m));
>>  		buf += sizeof(*m);
>>  	}
>> 
>> -	memset(xen_mcelog.entry, 0, num * sizeof(struct xen_mce));
>> -	xen_mcelog.next = 0;
>> +	memset(xen_mcelog_u.entry, 0, num * sizeof(struct xen_mce));
>> +	xen_mcelog_u.next = 0; 
>> 
>>  	if (err)
>>  		err = -EFAULT;
>> 
>>  out:
>> -	spin_unlock(&mcelog_lock);
>> +	mutex_unlock(&xen_mce_chrdev_read_mutex);
>> 
>>  	return err ? err : buf - ubuf;
>>  }
>> @@ -313,9 +325,21 @@ static int mc_queue_handle(uint32_t flags)
>>  static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)  {
>>  	int err;
>> -	unsigned long tmp;
>> 
>> -	spin_lock_irqsave(&mcelog_lock, tmp);
>> +	/*
>> +	 * mcelog_lock is used at normal process context and
>> +	 * mce context (which is async exception context that could
>> +	 * not protected by spin_lock_irqsave).
>> +	 *
>> +	 * use spin_trylock to avoid deadlock. When fail to get spinlock,
>> +	 * mc_info would be transferred by hypervisor next time. +	 */
>> +	if (unlikely(!spin_trylock(&mcelog_lock))) {
>> +		pr_err(XEN_MCELOG
>> +		       "Failed to get mcelog_lock, mc_info would "
>> +		       "be transferred by hypervisor next time.\n");
> 
> Ugh. Why the printk? How does this benefit the user? If it
> recovers - which I presume "..next time" means then it should be OK?
> 
> What does 'transferred by hypervisor' mean actually?
> 
> Would it be better to schedule a workqueue to poll the data? Perhaps
> that is how this whole IRQ handler should be done - it kicks of an
> IRQ handler that de-spolls the data?

Yep, much much better!
have updated patch accordingly and sent out.

Thanks,
Jinsong

> 
>> +		return IRQ_NONE;
>> +	}
>> 
>>  	/* urgent mc_info */
>>  	err = mc_queue_handle(XEN_MC_URGENT);
>> @@ -330,7 +354,7 @@ static irqreturn_t xen_mce_interrupt(int irq,
>>  		       void *dev_id)  		pr_err(XEN_MCELOG "Failed to handle
>> nonurgent mc_info queue.\n"); 
>> 
>> -	spin_unlock_irqrestore(&mcelog_lock, tmp);
>> +	spin_unlock(&mcelog_lock);
>> 
>>  	return IRQ_HANDLED;
>>  }
>> --
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 08:45:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 08:45: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 1SeMi6-00078R-BL; Tue, 12 Jun 2012 08:44: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 1SeMi5-00078M-6B
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 08:44:21 +0000
Received: from [85.158.139.83:58307] by server-6.bemta-5.messagelabs.com id
	7D/49-18700-46107DF4; Tue, 12 Jun 2012 08:44:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339490659!28880677!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26301 invoked from network); 12 Jun 2012 08:44:19 -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 Jun 2012 08:44:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 09:44:19 +0100
Message-Id: <4FD71DAD0200007800089578@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 09:45:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
	<4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
	<20120611182229.GC14535@phenom.dumpdata.com>
	<20120611185241.GJ14535@phenom.dumpdata.com>
In-Reply-To: <20120611185241.GJ14535@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.06.12 at 20:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]
> [v2: Add extra check in add_id_to_freelist]
> [v3: Redid op_name per Jan's suggestion]
> [v4: add const * and add WARN on failure returns]
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  drivers/block/xen-blkfront.c |   58 +++++++++++++++++++++++++++++++++--------
>  1 files changed, 46 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 60eed4b..e4fb337 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -141,14 +141,36 @@ static int get_id_from_freelist(struct blkfront_info 
> *info)
>  	return free;
>  }
>  
> -static void add_id_to_freelist(struct blkfront_info *info,
> +static int add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	if (info->shadow[id].req.u.rw.id != id)
> +		return -EINVAL;
> +	if (info->shadow[id].request == NULL)
> +		return -EINVAL;
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
> +	return 0;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	static const char *const names[] = {
> +		[BLKIF_OP_READ] = "read",
> +		[BLKIF_OP_WRITE] = "write",
> +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> +		[BLKIF_OP_DISCARD] = "discard" };
> +
> +	if (op < 0 || op >= ARRAY_SIZE(names))
> +		return "unknown";
> +
> +	if (!names[op])
> +		return "reserved";
> +
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -746,20 +768,36 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE) {
> +			WARN(1, "%s: response to %s has incorrect id (%ld)\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. */
> +			continue;
> +		}
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
>  			blkif_completion(&info->shadow[id]);
>  
> -		add_id_to_freelist(info, id);
> +		if (add_id_to_freelist(info, id)) {
> +			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			continue;
> +		}
>  
>  		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
>  		switch (bret->operation) {
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -771,18 +809,14 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> -- 
> 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 Tue Jun 12 08:45:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 08:45: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 1SeMi6-00078R-BL; Tue, 12 Jun 2012 08:44: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 1SeMi5-00078M-6B
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 08:44:21 +0000
Received: from [85.158.139.83:58307] by server-6.bemta-5.messagelabs.com id
	7D/49-18700-46107DF4; Tue, 12 Jun 2012 08:44:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339490659!28880677!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26301 invoked from network); 12 Jun 2012 08:44:19 -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 Jun 2012 08:44:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 09:44:19 +0100
Message-Id: <4FD71DAD0200007800089578@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 09:45:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1337982603-15692-1-git-send-email-konrad.wilk@oracle.com>
	<1337982603-15692-3-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.00.1205281111460.26786@kaball-desktop>
	<4FC4A10F0200007800086842@nat28.tlf.novell.com>
	<20120531181712.GA19700@phenom.dumpdata.com>
	<alpine.DEB.2.00.1206011111590.26786@kaball-desktop>
	<20120607215942.GA13592@phenom.dumpdata.com>
	<4FD1C20A0200007800088AC4@nat28.tlf.novell.com>
	<20120611182229.GC14535@phenom.dumpdata.com>
	<20120611185241.GJ14535@phenom.dumpdata.com>
In-Reply-To: <20120611185241.GJ14535@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/blkfront: Add BUG_ON to deal with
 misbehaving backends.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.06.12 at 20:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 25 May 2012 17:34:51 -0400
> Subject: [PATCH] xen/blkfront: Add WARN to deal with misbehaving backends.
> 
> Part of the ring structure is the 'id' field which is under
> control of the frontend. The frontend stamps it with "some"
> value (this some in this implementation being a value less
> than BLK_RING_SIZE), and when it gets a response expects
> said value to be in the response structure. We have a check
> for the id field when spolling new requests but not when
> de-spolling responses.
> 
> We also add an extra check in add_id_to_freelist to make
> sure that the 'struct request' was not NULL - as we cannot
> pass a NULL to __blk_end_request_all, otherwise that crashes
> (and all the operations that the response is dealing with
> end up with __blk_end_request_all).
> 
> Lastly we also print the name of the operation that failed.
> 
> [v1: s/BUG/WARN/ suggested by Stefano]
> [v2: Add extra check in add_id_to_freelist]
> [v3: Redid op_name per Jan's suggestion]
> [v4: add const * and add WARN on failure returns]
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  drivers/block/xen-blkfront.c |   58 +++++++++++++++++++++++++++++++++--------
>  1 files changed, 46 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 60eed4b..e4fb337 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -141,14 +141,36 @@ static int get_id_from_freelist(struct blkfront_info 
> *info)
>  	return free;
>  }
>  
> -static void add_id_to_freelist(struct blkfront_info *info,
> +static int add_id_to_freelist(struct blkfront_info *info,
>  			       unsigned long id)
>  {
> +	if (info->shadow[id].req.u.rw.id != id)
> +		return -EINVAL;
> +	if (info->shadow[id].request == NULL)
> +		return -EINVAL;
>  	info->shadow[id].req.u.rw.id  = info->shadow_free;
>  	info->shadow[id].request = NULL;
>  	info->shadow_free = id;
> +	return 0;
>  }
>  
> +static const char *op_name(int op)
> +{
> +	static const char *const names[] = {
> +		[BLKIF_OP_READ] = "read",
> +		[BLKIF_OP_WRITE] = "write",
> +		[BLKIF_OP_WRITE_BARRIER] = "barrier",
> +		[BLKIF_OP_FLUSH_DISKCACHE] = "flush",
> +		[BLKIF_OP_DISCARD] = "discard" };
> +
> +	if (op < 0 || op >= ARRAY_SIZE(names))
> +		return "unknown";
> +
> +	if (!names[op])
> +		return "reserved";
> +
> +	return names[op];
> +}
>  static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  {
>  	unsigned int end = minor + nr;
> @@ -746,20 +768,36 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  
>  		bret = RING_GET_RESPONSE(&info->ring, i);
>  		id   = bret->id;
> +		/*
> +		 * The backend has messed up and given us an id that we would
> +		 * never have given to it (we stamp it up to BLK_RING_SIZE -
> +		 * look in get_id_from_freelist.
> +		 */
> +		if (id >= BLK_RING_SIZE) {
> +			WARN(1, "%s: response to %s has incorrect id (%ld)\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			/* We can't safely get the 'struct request' as
> +			 * the id is busted. */
> +			continue;
> +		}
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
>  			blkif_completion(&info->shadow[id]);
>  
> -		add_id_to_freelist(info, id);
> +		if (add_id_to_freelist(info, id)) {
> +			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> +			     info->gd->disk_name, op_name(bret->operation), id);
> +			continue;
> +		}
>  
>  		error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
>  		switch (bret->operation) {
>  		case BLKIF_OP_DISCARD:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
>  				struct request_queue *rq = info->rq;
> -				printk(KERN_WARNING "blkfront: %s: discard op failed\n",
> -					   info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +					   info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  				info->feature_discard = 0;
>  				info->feature_secdiscard = 0;
> @@ -771,18 +809,14 @@ static irqreturn_t blkif_interrupt(int irq, void 
> *dev_id)
>  		case BLKIF_OP_FLUSH_DISKCACHE:
>  		case BLKIF_OP_WRITE_BARRIER:
>  			if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) {
> -				printk(KERN_WARNING "blkfront: %s: write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
>  				     info->shadow[id].req.u.rw.nr_segments == 0)) {
> -				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
> -				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -				       "barrier" :  "flush disk cache",
> -				       info->gd->disk_name);
> +				printk(KERN_WARNING "blkfront: %s: empty %s op failed\n",
> +				       info->gd->disk_name, op_name(bret->operation));
>  				error = -EOPNOTSUPP;
>  			}
>  			if (unlikely(error)) {
> -- 
> 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 Tue Jun 12 08:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 08:57: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 1SeMtw-0007K5-RY; Tue, 12 Jun 2012 08:56: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 1SeMtv-0007K0-Az
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 08:56:35 +0000
Received: from [85.158.143.35:55363] by server-3.bemta-4.messagelabs.com id
	EF/E3-05808-24407DF4; Tue, 12 Jun 2012 08:56:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339491384!14605426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIxMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10175 invoked from network); 12 Jun 2012 08:56:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 08:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,755,1330905600"; d="scan'208";a="12961258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 08:56:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 09:56:03 +0100
Message-ID: <1339491361.24104.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 09:56:01 +0100
In-Reply-To: <20434.7083.345990.653451@mariner.uk.xensource.com>
References: <db614e92faf743e20b3f.1337096977@kodo2>
	<4FB29D6F0200007800083E81@nat28.tlf.novell.com>
	<4FB28295.8020905@eu.citrix.com>
	<1337156497.27824.2.camel@zakaz.uk.xensource.com>
	<4FB3886A020000780008402F@nat28.tlf.novell.com>
	<1337159777.27824.39.camel@zakaz.uk.xensource.com>
	<4FB394AE0200007800084098@nat28.tlf.novell.com>
	<1337162232.27824.55.camel@zakaz.uk.xensource.com>
	<4FB38634.7050807@eu.citrix.com>
	<1337168683.27824.92.camel@zakaz.uk.xensource.com>
	<20434.7083.345990.653451@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap 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 Fri, 2012-06-08 at 16:35 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap driver"):
> > On Wed, 2012-05-16 at 11:49 +0100, George Dunlap wrote:
> > > On 16/05/12 10:57, Ian Campbell wrote:
> > > >>> The blktap detection code is necessarily OS-specific. I previously
> > > >>> discounted it because of the possibility of a race between the
> > > >>> completion of modprobe and the driver actually registering enough for
> > > >>> detection to succeed. Maybe I was too pessimistic or someone has a
> > > >>> bright idea?
> > > >> modprobe only exits when the driver's init function completed,
> > > >> at which point the driver can be expected to be in a usable state.
> > > > OK, so maybe that works then.
> > > So what's the plan?  Options seem to be:
> > > 1. Put this on the blocker list, so it definitely gets done before release
> > > 2. Accept the patch that started this thread (or a version of it), and 
> > > put "do it right" on the "nice-to-have" list.  I can do it if I get a 
> > > chance.
> > > 3. Someone can volunteer who can prioritize it.
> > 
> > My preference, in decreasing order would be 2, 3, 1.
> 
> AFAICT this is still outstanding.  Have we made a decision ?
> 
> I'm inclined to throw all of these best-effort modprobes into 4.2 and
> try to sort out something saner (if possible) in 4.3.
> 
> Ian: can you make sure this is on the 4.2 TODO ?

I've added, to tools nice to have:

    * Load blktap driver from xencommons initscript if available, thread at:
      <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
      properly in 4.3

I'll post an update of the TODO list after I've processed my
post-vacation email backlog.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 08:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 08:57: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 1SeMtw-0007K5-RY; Tue, 12 Jun 2012 08:56: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 1SeMtv-0007K0-Az
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 08:56:35 +0000
Received: from [85.158.143.35:55363] by server-3.bemta-4.messagelabs.com id
	EF/E3-05808-24407DF4; Tue, 12 Jun 2012 08:56:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339491384!14605426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIxMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10175 invoked from network); 12 Jun 2012 08:56:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 08:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,755,1330905600"; d="scan'208";a="12961258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 08:56:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 09:56:03 +0100
Message-ID: <1339491361.24104.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 09:56:01 +0100
In-Reply-To: <20434.7083.345990.653451@mariner.uk.xensource.com>
References: <db614e92faf743e20b3f.1337096977@kodo2>
	<4FB29D6F0200007800083E81@nat28.tlf.novell.com>
	<4FB28295.8020905@eu.citrix.com>
	<1337156497.27824.2.camel@zakaz.uk.xensource.com>
	<4FB3886A020000780008402F@nat28.tlf.novell.com>
	<1337159777.27824.39.camel@zakaz.uk.xensource.com>
	<4FB394AE0200007800084098@nat28.tlf.novell.com>
	<1337162232.27824.55.camel@zakaz.uk.xensource.com>
	<4FB38634.7050807@eu.citrix.com>
	<1337168683.27824.92.camel@zakaz.uk.xensource.com>
	<20434.7083.345990.653451@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap 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 Fri, 2012-06-08 at 16:35 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap driver"):
> > On Wed, 2012-05-16 at 11:49 +0100, George Dunlap wrote:
> > > On 16/05/12 10:57, Ian Campbell wrote:
> > > >>> The blktap detection code is necessarily OS-specific. I previously
> > > >>> discounted it because of the possibility of a race between the
> > > >>> completion of modprobe and the driver actually registering enough for
> > > >>> detection to succeed. Maybe I was too pessimistic or someone has a
> > > >>> bright idea?
> > > >> modprobe only exits when the driver's init function completed,
> > > >> at which point the driver can be expected to be in a usable state.
> > > > OK, so maybe that works then.
> > > So what's the plan?  Options seem to be:
> > > 1. Put this on the blocker list, so it definitely gets done before release
> > > 2. Accept the patch that started this thread (or a version of it), and 
> > > put "do it right" on the "nice-to-have" list.  I can do it if I get a 
> > > chance.
> > > 3. Someone can volunteer who can prioritize it.
> > 
> > My preference, in decreasing order would be 2, 3, 1.
> 
> AFAICT this is still outstanding.  Have we made a decision ?
> 
> I'm inclined to throw all of these best-effort modprobes into 4.2 and
> try to sort out something saner (if possible) in 4.3.
> 
> Ian: can you make sure this is on the 4.2 TODO ?

I've added, to tools nice to have:

    * Load blktap driver from xencommons initscript if available, thread at:
      <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
      properly in 4.3

I'll post an update of the TODO list after I've processed my
post-vacation email backlog.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 09:02:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 09: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 1SeMzg-0007Ua-A9; Tue, 12 Jun 2012 09:02: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 1SeMzf-0007UV-1k
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 09:02:31 +0000
Received: from [85.158.138.51:3743] by server-5.bemta-3.messagelabs.com id
	A9/1E-03598-6A507DF4; Tue, 12 Jun 2012 09:02:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339491749!32078307!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14830 invoked from network); 12 Jun 2012 09:02:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 09:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,755,1330905600"; d="scan'208";a="12961445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 09:02:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 10:02:12 +0100
Message-ID: <1339491730.24104.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 12 Jun 2012 10:02:10 +0100
In-Reply-To: <1339168462.5003.15.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 16:14 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > git-commit --author will do this for you and I think git-send-email
> > will then generate appropriate output.
> > 
> Oh, thanks... Do you happen to know what a mercurial equivalent for this
> could be? :-P

Ian J answered for the general commit case but in case you are
interested for the mq case you can put a comment at the top of the patch
(before the changelog) with the same form as what "hg export" gives you.
e.g.:
        # HG changeset patch
        # User Ian Campbell <ian.campbell@citrix.com>

This makes qpush do the right thing (IIRC, I didn't try it just now...).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 09:02:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 09: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 1SeMzg-0007Ua-A9; Tue, 12 Jun 2012 09:02: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 1SeMzf-0007UV-1k
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 09:02:31 +0000
Received: from [85.158.138.51:3743] by server-5.bemta-3.messagelabs.com id
	A9/1E-03598-6A507DF4; Tue, 12 Jun 2012 09:02:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339491749!32078307!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14830 invoked from network); 12 Jun 2012 09:02:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 09:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,755,1330905600"; d="scan'208";a="12961445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 09:02:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 10:02:12 +0100
Message-ID: <1339491730.24104.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 12 Jun 2012 10:02:10 +0100
In-Reply-To: <1339168462.5003.15.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 16:14 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > git-commit --author will do this for you and I think git-send-email
> > will then generate appropriate output.
> > 
> Oh, thanks... Do you happen to know what a mercurial equivalent for this
> could be? :-P

Ian J answered for the general commit case but in case you are
interested for the mq case you can put a comment at the top of the patch
(before the changelog) with the same form as what "hg export" gives you.
e.g.:
        # HG changeset patch
        # User Ian Campbell <ian.campbell@citrix.com>

This makes qpush do the right thing (IIRC, I didn't try it just now...).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 09:06:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 09:06: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 1SeN3Z-0007gi-IJ; Tue, 12 Jun 2012 09:06: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 1SeN3Y-0007gT-CV
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 09:06:32 +0000
Received: from [85.158.143.99:49299] by server-2.bemta-4.messagelabs.com id
	4D/E0-17938-69607DF4; Tue, 12 Jun 2012 09:06:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339491979!32394808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIxMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29221 invoked from network); 12 Jun 2012 09:06:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 09:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,755,1330905600"; d="scan'208";a="12961575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 09:05:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 10:05:41 +0100
Message-ID: <1339491940.24104.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Tue, 12 Jun 2012 10:05:40 +0100
In-Reply-To: <CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
	<CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 19:15 +0100, Zeinab Alebouyeh wrote:

> Because currently I'm not in lab I don't know my hypervisor is 32b or
> 64 bit.
> I'm working in a security project. for improve security of
> applications running in virtualized environment. I want to use the
> security instruction of AMD SVM named SKINIT.
> because this instruction must run in ring0, I add a hypercall in xen
> and write my codes in my hypercall function.
> The skinit instruction takes the physical address of a block as an
> input operand( in the eax register) and establish a secure execution
> environment for a software component(block)
> I have a label in my hypercall function that is the start of my block.
> In order to use skinit I want grab the physical address of my label to
> save in eax register.

Rather than use a label in the current function for this magic block you
should use a separate function, either in a .S or a .c file. Then you
can simply use &function_name to get the address and you don't run the
risk of accidentally falling through into the special code from the
non-skinit context etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 09:06:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 09:06: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 1SeN3Z-0007gi-IJ; Tue, 12 Jun 2012 09:06: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 1SeN3Y-0007gT-CV
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 09:06:32 +0000
Received: from [85.158.143.99:49299] by server-2.bemta-4.messagelabs.com id
	4D/E0-17938-69607DF4; Tue, 12 Jun 2012 09:06:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339491979!32394808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIxMjg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29221 invoked from network); 12 Jun 2012 09:06:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 09:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,755,1330905600"; d="scan'208";a="12961575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 09:05:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 10:05:41 +0100
Message-ID: <1339491940.24104.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Tue, 12 Jun 2012 10:05:40 +0100
In-Reply-To: <CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
	<CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 19:15 +0100, Zeinab Alebouyeh wrote:

> Because currently I'm not in lab I don't know my hypervisor is 32b or
> 64 bit.
> I'm working in a security project. for improve security of
> applications running in virtualized environment. I want to use the
> security instruction of AMD SVM named SKINIT.
> because this instruction must run in ring0, I add a hypercall in xen
> and write my codes in my hypercall function.
> The skinit instruction takes the physical address of a block as an
> input operand( in the eax register) and establish a secure execution
> environment for a software component(block)
> I have a label in my hypercall function that is the start of my block.
> In order to use skinit I want grab the physical address of my label to
> save in eax register.

Rather than use a label in the current function for this magic block you
should use a separate function, either in a .S or a .c file. Then you
can simply use &function_name to get the address and you don't run the
risk of accidentally falling through into the special code from the
non-skinit context etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 10:22:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 10:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeOEV-0001k9-3F; Tue, 12 Jun 2012 10:21: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 1SeOET-0001k4-SQ
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 10:21:54 +0000
Received: from [85.158.138.51:14892] by server-9.bemta-3.messagelabs.com id
	9B/32-15054-14817DF4; Tue, 12 Jun 2012 10:21:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339496512!32135090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12795 invoked from network); 12 Jun 2012 10:21:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 10:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12963837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 10:20:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:20:51 +0100
Message-ID: <1339496450.24104.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 11:20:50 +0100
In-Reply-To: <20437.63222.655663.76990@mariner.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
	<20437.63222.655663.76990@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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, 2012-06-11 at 14:47 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > So what is the default configuration ?
> > 
> > The default is on.
> >
> > > Do we have any protection from
> > > possible bugs in the virtfs access control system ?
> > 
> > Nothing more and nothing less than QEMU 1.0 stable provides.
> 
> That situation seems like a release-critical bug from our point of
> view.
> 
> And this is relevant because we're now using upstream qemu 1.0 by
> default for some guests.

Is the "fix" here as simple as hardcoding some sort of "-virtfs=off" in
the libxl function which builds the command line for upstream qemu?

Is it possible to access virtfs if virtio is not 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 Jun 12 10:22:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 10:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeOEV-0001k9-3F; Tue, 12 Jun 2012 10:21: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 1SeOET-0001k4-SQ
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 10:21:54 +0000
Received: from [85.158.138.51:14892] by server-9.bemta-3.messagelabs.com id
	9B/32-15054-14817DF4; Tue, 12 Jun 2012 10:21:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339496512!32135090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12795 invoked from network); 12 Jun 2012 10:21:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 10:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12963837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 10:20:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:20:51 +0100
Message-ID: <1339496450.24104.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 11:20:50 +0100
In-Reply-To: <20437.63222.655663.76990@mariner.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
	<20437.63222.655663.76990@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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, 2012-06-11 at 14:47 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > So what is the default configuration ?
> > 
> > The default is on.
> >
> > > Do we have any protection from
> > > possible bugs in the virtfs access control system ?
> > 
> > Nothing more and nothing less than QEMU 1.0 stable provides.
> 
> That situation seems like a release-critical bug from our point of
> view.
> 
> And this is relevant because we're now using upstream qemu 1.0 by
> default for some guests.

Is the "fix" here as simple as hardcoding some sort of "-virtfs=off" in
the libxl function which builds the command line for upstream qemu?

Is it possible to access virtfs if virtio is not 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 Jun 12 10:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 10:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeON8-0001tI-31; Tue, 12 Jun 2012 10:30: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 1SeON6-0001tB-P5
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 10:30:48 +0000
Received: from [85.158.143.99:22829] by server-1.bemta-4.messagelabs.com id
	A4/7F-24392-85A17DF4; Tue, 12 Jun 2012 10:30:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339497046!27153506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9651 invoked from network); 12 Jun 2012 10:30:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 10:30:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12964146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 10:30:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 11:30:46 +0100
Date: Tue, 12 Jun 2012 11:30:35 +0100
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: <20437.63222.655663.76990@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206121121440.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
	<20437.63222.655663.76990@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > So what is the default configuration ?
> > 
> > The default is on.
> >
> > > Do we have any protection from
> > > possible bugs in the virtfs access control system ?
> > 
> > Nothing more and nothing less than QEMU 1.0 stable provides.
> 
> That situation seems like a release-critical bug from our point of
> view.

virtfs is not enabled unless you pass specific arguments to QEMU,
which we do not.

Besides saying that an open source technology X is dangerous because it
has been developed by a different community than ours, without giving
any technical reasons for it, is just spreading FUD.


QEMU provides a much wider surface of attack than just virtfs.
What protections do we have from the other QEMU bugs?

Linux PV backend drivers are directly exposed to guest frontend PV
drivers. What protections do we have in Linux?

What protections do we have from other Linux bugs in dom0?


> And this is relevant because we're now using upstream qemu 1.0 by
> default for some guests.

Only in PV guests, for which this discussion is not relevant.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 10:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 10:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeON8-0001tI-31; Tue, 12 Jun 2012 10:30: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 1SeON6-0001tB-P5
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 10:30:48 +0000
Received: from [85.158.143.99:22829] by server-1.bemta-4.messagelabs.com id
	A4/7F-24392-85A17DF4; Tue, 12 Jun 2012 10:30:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339497046!27153506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9651 invoked from network); 12 Jun 2012 10:30:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 10:30:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12964146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 10:30:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 11:30:46 +0100
Date: Tue, 12 Jun 2012 11:30:35 +0100
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: <20437.63222.655663.76990@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206121121440.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
	<20437.63222.655663.76990@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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 Jun 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > So what is the default configuration ?
> > 
> > The default is on.
> >
> > > Do we have any protection from
> > > possible bugs in the virtfs access control system ?
> > 
> > Nothing more and nothing less than QEMU 1.0 stable provides.
> 
> That situation seems like a release-critical bug from our point of
> view.

virtfs is not enabled unless you pass specific arguments to QEMU,
which we do not.

Besides saying that an open source technology X is dangerous because it
has been developed by a different community than ours, without giving
any technical reasons for it, is just spreading FUD.


QEMU provides a much wider surface of attack than just virtfs.
What protections do we have from the other QEMU bugs?

Linux PV backend drivers are directly exposed to guest frontend PV
drivers. What protections do we have in Linux?

What protections do we have from other Linux bugs in dom0?


> And this is relevant because we're now using upstream qemu 1.0 by
> default for some guests.

Only in PV guests, for which this discussion is not relevant.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePnk-0002U3-LC; Tue, 12 Jun 2012 12:02:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SePni-0002Tx-NL
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:02:22 +0000
Received: from [85.158.143.99:55441] by server-2.bemta-4.messagelabs.com id
	C8/B3-17938-ECF27DF4; Tue, 12 Jun 2012 12:02:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339502540!32125064!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6793 invoked from network); 12 Jun 2012 12:02:21 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jun 2012 12:02:21 -0000
Received: from mail125-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 12:01:17 +0000
Received: from mail125-tx2 (localhost [127.0.0.1])	by
	mail125-tx2-R.bigfish.com (Postfix) with ESMTP id ABACB420352;
	Tue, 12 Jun 2012 12:01:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzc85dh4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah34h)
Received: from mail125-tx2 (localhost.localdomain [127.0.0.1]) by mail125-tx2
	(MessageSwitch) id 1339502475230806_10688;
	Tue, 12 Jun 2012 12:01:15 +0000 (UTC)
Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.237])	by
	mail125-tx2.bigfish.com (Postfix) with ESMTP id 264D946004B;
	Tue, 12 Jun 2012 12:01:15 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 12:03:03 +0000
X-WSS-ID: 0M5I6RO-01-5UB-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22E6710280AB;	Tue, 12 Jun 2012 07:02:12 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 12 Jun 2012 07:10:30 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 12 Jun 2012 07:02:12 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012
	08:02:11 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C88CF49C145; Tue, 12 Jun 2012
	13:02:10 +0100 (BST)
Message-ID: <4FD72FE4.80009@amd.com>
Date: Tue, 12 Jun 2012 14:02:44 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: multipart/mixed; boundary="------------050807040804010300090702"
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
	disabled 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

--------------050807040804010300090702
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan & Andrew

I had attached a revised patch, please check it.

I found that the following Linux commit triggers this issue. It has been 
included into 3.4 pv_ops.

" commit a776c491ca5e38c26d9f66923ff574d041e747f4
   Author: Eric W. Biederman <ebiederm@xmission.com>
   Date:   Mon Oct 17 11:46:06 2011 -0700

   PCI: msi: Disable msi interrupts when we initialize a pci device "

Thanks,
Wei

--------------050807040804010300090702
Content-Type: text/x-patch; name="iommu-msi.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommu-msi.patch"
Content-Description: iommu-msi.patch

# HG changeset patch
# Parent f6bfaf9daa508c31b2bca0e461202db2759426fc
# User Wei Wang <wei.wang2@amd.com>
Re-enable iommu msi capability block if it is disabled by dom0
Linux commit a776c491ca5e38c26d9f66923ff574d041e747f4 disables msi interrupts. If is
running as a dom0, iommu interrupt will be disabled and hypervisor cannot process any
event and ppr logs afterwards.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f6bfaf9daa50 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Jun 06 16:37:05 2012 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jun 12 13:58:40 2012 +0200
@@ -81,6 +81,30 @@ static void disable_translation(u32 *dte
     dte[0] = entry;
 }
 
+static void iommu_msi_check_enable(struct amd_iommu *iommu)
+{
+    unsigned long flags;
+    uint16_t control;
+    uint8_t bus = PCI_BUS(iommu->bdf);
+    uint8_t dev = PCI_SLOT(iommu->bdf);
+    uint8_t func = PCI_FUNC(iommu->bdf);
+
+    ASSERT( iommu->msi_cap );
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    control = pci_conf_read16(iommu->seg, bus, dev, func,
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    if ( !(control & PCI_MSI_FLAGS_ENABLE) )
+    {    
+        control |= PCI_MSI_FLAGS_ENABLE;
+        pci_conf_write16(iommu->seg, bus, dev, func,
+                         iommu->msi_cap + PCI_MSI_FLAGS, control);
+    }
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
 static void amd_iommu_setup_domain_device(
     struct domain *domain, struct amd_iommu *iommu, int bdf)
 {
@@ -101,6 +125,12 @@ static void amd_iommu_setup_domain_devic
     if ( ats_enabled )
         dte_i = 1;
 
+    /* 
+     * In some cases, dom0 disables iommu msi capability, 
+     * check and re-enable it here.
+     */
+    iommu_msi_check_enable(iommu); 
+
     /* get device-table entry */
     req_id = get_dma_requestor_id(iommu->seg, bdf);
     dte = iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE);

--------------050807040804010300090702
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050807040804010300090702--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePnk-0002U3-LC; Tue, 12 Jun 2012 12:02:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SePni-0002Tx-NL
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:02:22 +0000
Received: from [85.158.143.99:55441] by server-2.bemta-4.messagelabs.com id
	C8/B3-17938-ECF27DF4; Tue, 12 Jun 2012 12:02:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339502540!32125064!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6793 invoked from network); 12 Jun 2012 12:02:21 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jun 2012 12:02:21 -0000
Received: from mail125-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 12:01:17 +0000
Received: from mail125-tx2 (localhost [127.0.0.1])	by
	mail125-tx2-R.bigfish.com (Postfix) with ESMTP id ABACB420352;
	Tue, 12 Jun 2012 12:01:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzc85dh4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah34h)
Received: from mail125-tx2 (localhost.localdomain [127.0.0.1]) by mail125-tx2
	(MessageSwitch) id 1339502475230806_10688;
	Tue, 12 Jun 2012 12:01:15 +0000 (UTC)
Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.237])	by
	mail125-tx2.bigfish.com (Postfix) with ESMTP id 264D946004B;
	Tue, 12 Jun 2012 12:01:15 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 12:03:03 +0000
X-WSS-ID: 0M5I6RO-01-5UB-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22E6710280AB;	Tue, 12 Jun 2012 07:02:12 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 12 Jun 2012 07:10:30 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 12 Jun 2012 07:02:12 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012
	08:02:11 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C88CF49C145; Tue, 12 Jun 2012
	13:02:10 +0100 (BST)
Message-ID: <4FD72FE4.80009@amd.com>
Date: Tue, 12 Jun 2012 14:02:44 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: multipart/mixed; boundary="------------050807040804010300090702"
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
	disabled 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

--------------050807040804010300090702
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan & Andrew

I had attached a revised patch, please check it.

I found that the following Linux commit triggers this issue. It has been 
included into 3.4 pv_ops.

" commit a776c491ca5e38c26d9f66923ff574d041e747f4
   Author: Eric W. Biederman <ebiederm@xmission.com>
   Date:   Mon Oct 17 11:46:06 2011 -0700

   PCI: msi: Disable msi interrupts when we initialize a pci device "

Thanks,
Wei

--------------050807040804010300090702
Content-Type: text/x-patch; name="iommu-msi.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommu-msi.patch"
Content-Description: iommu-msi.patch

# HG changeset patch
# Parent f6bfaf9daa508c31b2bca0e461202db2759426fc
# User Wei Wang <wei.wang2@amd.com>
Re-enable iommu msi capability block if it is disabled by dom0
Linux commit a776c491ca5e38c26d9f66923ff574d041e747f4 disables msi interrupts. If is
running as a dom0, iommu interrupt will be disabled and hypervisor cannot process any
event and ppr logs afterwards.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f6bfaf9daa50 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Wed Jun 06 16:37:05 2012 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jun 12 13:58:40 2012 +0200
@@ -81,6 +81,30 @@ static void disable_translation(u32 *dte
     dte[0] = entry;
 }
 
+static void iommu_msi_check_enable(struct amd_iommu *iommu)
+{
+    unsigned long flags;
+    uint16_t control;
+    uint8_t bus = PCI_BUS(iommu->bdf);
+    uint8_t dev = PCI_SLOT(iommu->bdf);
+    uint8_t func = PCI_FUNC(iommu->bdf);
+
+    ASSERT( iommu->msi_cap );
+
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    control = pci_conf_read16(iommu->seg, bus, dev, func,
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    if ( !(control & PCI_MSI_FLAGS_ENABLE) )
+    {    
+        control |= PCI_MSI_FLAGS_ENABLE;
+        pci_conf_write16(iommu->seg, bus, dev, func,
+                         iommu->msi_cap + PCI_MSI_FLAGS, control);
+    }
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
 static void amd_iommu_setup_domain_device(
     struct domain *domain, struct amd_iommu *iommu, int bdf)
 {
@@ -101,6 +125,12 @@ static void amd_iommu_setup_domain_devic
     if ( ats_enabled )
         dte_i = 1;
 
+    /* 
+     * In some cases, dom0 disables iommu msi capability, 
+     * check and re-enable it here.
+     */
+    iommu_msi_check_enable(iommu); 
+
     /* get device-table entry */
     req_id = get_dma_requestor_id(iommu->seg, bdf);
     dte = iommu->dev_table.buffer + (req_id * IOMMU_DEV_TABLE_ENTRY_SIZE);

--------------050807040804010300090702
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050807040804010300090702--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:03:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePoD-0002W3-9X; Tue, 12 Jun 2012 12:02:53 +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 1SePoB-0002Vm-Mb
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:02:51 +0000
Received: from [85.158.138.51:59523] by server-3.bemta-3.messagelabs.com id
	DC/7C-25608-AEF27DF4; Tue, 12 Jun 2012 12:02:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339502570!32040004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5247 invoked from network); 12 Jun 2012 12:02:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:02:26 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:02:26 +0100
Message-ID: <4FD72FD2.3040008@citrix.com>
Date: Tue, 12 Jun 2012 13:02:26 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-4-git-send-email-roger.pau@citrix.com>
	<20434.6341.292944.748723@mariner.uk.xensource.com>
In-Reply-To: <20434.6341.292944.748723@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES
 and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
>> Parse those options correctly, since the "+=" operator is not valid.
>> Also added CPPFLAGS, so headers checks don't give strange results.
> ...
>>   CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
>> +CPPFLAGS="$CFLAGS"

Without this I get the following (harmless but noisy) error:

checking yajl/yajl_version.h usability... yes
checking yajl/yajl_version.h presence... no
configure: WARNING: yajl/yajl_version.h: accepted by the compiler, 
rejected by the preprocessor!
configure: WARNING: yajl/yajl_version.h: proceeding with the compiler's 
result

> Surely that can't be right.

 From http://www.edwardrosten.com/code/autoconf/:

"Just append stuff to CFLAGS (for the C compiler), CPPFLAGS (for the C 
preprocessor, C and C++ compilers), CXXFLAGS (for the C++ compiler) and 
LIBS (for the linker)."

It seems like the preprocessor check uses CPPFLAGS instead of CFLAGS, so 
we have to set both.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:03:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePoD-0002W3-9X; Tue, 12 Jun 2012 12:02:53 +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 1SePoB-0002Vm-Mb
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:02:51 +0000
Received: from [85.158.138.51:59523] by server-3.bemta-3.messagelabs.com id
	DC/7C-25608-AEF27DF4; Tue, 12 Jun 2012 12:02:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339502570!32040004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5247 invoked from network); 12 Jun 2012 12:02:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:02:26 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:02:26 +0100
Message-ID: <4FD72FD2.3040008@citrix.com>
Date: Tue, 12 Jun 2012 13:02:26 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-4-git-send-email-roger.pau@citrix.com>
	<20434.6341.292944.748723@mariner.uk.xensource.com>
In-Reply-To: <20434.6341.292944.748723@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES
 and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
>> Parse those options correctly, since the "+=" operator is not valid.
>> Also added CPPFLAGS, so headers checks don't give strange results.
> ...
>>   CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
>> +CPPFLAGS="$CFLAGS"

Without this I get the following (harmless but noisy) error:

checking yajl/yajl_version.h usability... yes
checking yajl/yajl_version.h presence... no
configure: WARNING: yajl/yajl_version.h: accepted by the compiler, 
rejected by the preprocessor!
configure: WARNING: yajl/yajl_version.h: proceeding with the compiler's 
result

> Surely that can't be right.

 From http://www.edwardrosten.com/code/autoconf/:

"Just append stuff to CFLAGS (for the C compiler), CPPFLAGS (for the C 
preprocessor, C and C++ compilers), CXXFLAGS (for the C++ compiler) and 
LIBS (for the linker)."

It seems like the preprocessor check uses CPPFLAGS instead of CFLAGS, so 
we have to set both.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:03:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePoQ-0002YP-B4; Tue, 12 Jun 2012 12:03:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SePoO-0002Xf-OY
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:03:04 +0000
Received: from [85.158.139.83:53523] by server-12.bemta-5.messagelabs.com id
	A5/CC-18374-6FF27DF4; Tue, 12 Jun 2012 12:03:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339502581!25849996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12638 invoked from network); 12 Jun 2012 12:03:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:03:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:02:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:02:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePns-0006QG-Ea; Tue, 12 Jun 2012 12:02:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePns-0005Tn-CB;
	Tue, 12 Jun 2012 13:02:32 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="xk0dLwRkyW"
Content-Transfer-Encoding: 7bit
Message-ID: <20439.12248.291249.667993@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:02:32 +0100
From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, oss-security@lists.openwall.com
Subject: [Xen-devel] Xen Security Advisory 7 (CVE-2012-0217) - PV privilege
	escalation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--xk0dLwRkyW
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

              Xen Security Advisory CVE-2012-0217 / XSA-7
                            version 9

           64-bit PV guest privilege escalation vulnerability

UPDATES IN VERSION 9
====================

Public release.  Previous versions were embargoed.

ISSUE DESCRIPTION
=================

Rafal Wojtczuk has discovered a vulnerability which can allow a 64-bit
PV guest kernel running on a 64-bit hypervisor to escalate privileges
to that of the host by arranging for a system call to return via
sysret to a non-canonical RIP.  Intel CPUs deliver the resulting
exception in an undesirable processor state.

IMPACT
======

Guest administrators can gain control of the host.

Depending on the particular guest kernel it is also possible that
non-privileged guest user processes can also elevate their privileges
to that of the host.

VULNERABLE SYSTEMS
==================

All systems running 64 bit Xen hypervisor running 64 bit PV guests on
Intel CPUs are vulnerable to this issue.

Systems using AMD CPUs are not vulnerable to this privilege
escalation. AMD have issued the following statement:
   AMD processors' SYSRET behavior is such that a non-canonical
   address in RCX does not generate a #GP while in CPL0. We have
   verified this with our architecture team, with our design team, and
   have performed tests that verified this on silicon. Therefore, this
   privilege escalation exposure is not applicable to any AMD
   processor.

While investigating this, it was noted that some older AMD CPUs will
lock up under similar circumstances, causing a denial of service. See
XSA-9 for details.

MITIGATION
==========

This issue can be mitigated by running HVM (fully-virtualised)
or 32 bit PV guests only.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

These patches also resolve the issue described in XSA-8 (CVE-2012-0128).

These changes have been made to the staging Xen repositories:
                    XSA-7:              XSA-8:
 xen-unstable.hg     25480:76eaf5966c05  25200:80f4113be500+25204:569d6f05e1ef
 xen-4.1-testing.hg  23299:f08e61b9b33f  23300:0fec1afa4638
 xen-4.0-testing.hg  21590:dd367837e089  21591:adb943a387c8
 xen-3.4-testing.hg  19996:894aa06e4f79  19997:ddb7578abb89

PATCH INFORMATION
=================

The attached patches resolve both this issue and that reported in
XSA-8 (CVE-2012-0128).

 xen-unstable 25204:569d6f05e1ef or later    xsa7-xsa8-unstable-recent.patch  
 xen-unstable 25199:6092641e3644 or earlier  xsa7-xsa8-unstable-apr16.patch
 Xen 4.1, 4.1.x                              xsa7-xsa8-xen-4.1.patch
 Xen 4.0, 4.0.x                              xsa7-xsa8-xen-4.0.patch
 Xen 3.4, 3.4.x                              xsa7-xsa8-xen-3.4.patch

$ sha256sum xsa7-xsa8-*patch
00853d799d24af16b17c8bbbdb5bb5144a8a7fad31467c4be3d879244774f8d2  xsa7-xsa8-unstable-apr16.patch
71f9907a58c1a1cd601d8088faf8791923d78f77065b94dba8df2a61f512530d  xsa7-xsa8-unstable-recent.patch
55fb925a7f4519ea31a0bc42d3ee83093bb7abd98b3a0e4f58591f1ae738840a  xsa7-xsa8-xen-3.4.patch
6a7e39121ec1f134351fdf34f494d108500aaa4190a9f7965e81c4e96270924e  xsa7-xsa8-xen-4.0.patch
52d8288718b4a833eb437fd18d92b7d412fbe01900dbd0b437744a1df4d459da  xsa7-xsa8-xen-4.1.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP1yqTAAoJEIP+FMlX6CvZntwH/jzuqabF9yGMIXQBckjZUv1E
XeY9dbz1uGoMzy0mBFufwbJQqdBt89SNYDkr2BxKxSghSvBs608KHuh8giF1hzvm
8oP2K5T3Rk/jl0gdc3VlZz15Yi9kVEDUOSu2rPQLbhmiv6ht+Y2Of2cp63RioEvq
G2QQouHDsipCUZV4Ow5xnPY/KBifh46uCCnLDjV5Q/6WScI8VOIreOADryOpn2+/
8QmyCo2Sl2F+YxlbCl7k3qyqihaSONymeVg0pkJbH5LmRdTQnJX9fMJSQvfV6Bxs
U4PD4ve0C9+/Usz4XFejlQLt/kv4ZNPD6QF2rXei3oElmYAVcHL2XdLVCNLbAeY=
=S6KX
-----END PGP SIGNATURE-----


--xk0dLwRkyW
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-recent.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-recent.patch"
Content-Transfer-Encoding: base64

eDg2XzY0OiBEbyBub3QgZXhlY3V0ZSBzeXNyZXQgd2l0aCBhIG5vbi1jYW5vbmljYWwgcmV0dXJu
IGFkZHJlc3MKCkNoZWNrIGZvciBub24tY2Fub25pY2FsIGd1ZXN0IFJJUCBiZWZvcmUgYXR0ZW1w
dGluZyB0byBleGVjdXRlIHN5c3JldC4KSWYgc3lzcmV0IGlzIGV4ZWN1dGVkIHdpdGggYSBub24t
Y2Fub25pY2FsIHZhbHVlIGluIFJDWCwgSW50ZWwgQ1BVcwp0YWtlIHRoZSBmYXVsdCBpbiByaW5n
MCwgYnV0IHdlIHdpbGwgbmVjZXNzYXJpbHkgYWxyZWFkeSBoYXZlIHN3aXRjaGVkCnRvIHRoZSB0
aGUgdXNlcidzIHN0YWNrIHBvaW50ZXIuCgpUaGlzIGlzIGEgc2VjdXJpdHkgdnVsbmVyYWJpbGl0
eSwgWFNBLTcgLyBDVkUtMjAxMi0wMjE3LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPEpC
ZXVsaWNoQHN1c2UuY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUu
Y2l0cml4LmNvbT4KVGVzdGVkLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXgu
Y29tPgpBY2tlZC1ieTogS2VpciBGcmFzZXIgPGtlaXIueGVuQGdtYWlsLmNvbT4KQ29tbWl0dGVk
LWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLXIgMzQw
MDYyZmFmMjk4IC1yIGFkODc5MDNmZGNhMSB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCVdlZCBNYXkgMjMgMTE6MDY6NDkgMjAxMiAr
MDEwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowMjoz
NSAyMDEyICswMTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAg
ICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90
b19ndWVzdAogCisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJu
IGFkZHJlc3MgaXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4
CisgICAgICAgIHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21w
bCAgJDEsJWVjeAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAk
OCwlcnNwCiAgICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAg
ICAgIHBvcHEgICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBA
IHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAor
Lkxmb3JjZV9pcmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAg
ICAgIG1vdnEgIDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0
KCVyc3ApLCVyMTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVj
aWFsIHJlZ2lzdGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0Ogo=
--xk0dLwRkyW
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-apr16.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-apr16.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgQXByIDE3IDE1OjA1OjA1
IDIwMTIgKzAyMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMTQ1LDYgKzE0NSw3IEBAIHZvaWQgX19kdW1t
eV9fKHZvaWQpCiAKICAgICBPRkZTRVQoVFJBUElORk9fZWlwLCBzdHJ1Y3QgdHJhcF9pbmZvLCBh
ZGRyZXNzKTsKICAgICBPRkZTRVQoVFJBUElORk9fY3MsIHN0cnVjdCB0cmFwX2luZm8sIGNzKTsK
KyAgICBPRkZTRVQoVFJBUElORk9fZmxhZ3MsIHN0cnVjdCB0cmFwX2luZm8sIGZsYWdzKTsKICAg
ICBERUZJTkUoVFJBUElORk9fc2l6ZW9mLCBzaXplb2Yoc3RydWN0IHRyYXBfaW5mbykpOwogICAg
IEJMQU5LKCk7CiAKZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCVR1ZSBB
cHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBh
dC9lbnRyeS5TCVRodSBNYXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMjEzLDYgKzIxMyw3
IEBAIDE6ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKIEVOVFJZKGNvbXBh
dF9wb3N0X2hhbmRsZV9leGNlcHRpb24pCiAgICAgICAgIHRlc3RiICRUQkZfRVhDRVBUSU9OLFRS
QVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50
cworLkxjb21wYXRfYm91bmNlX2V4Y2VwdGlvbjoKICAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0
ZV9ib3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCkBAIC0yMjUsMjAgKzIyNiwyMSBA
QCBFTlRSWShjb21wYXRfc3lzY2FsbCkKICAgICAgICAgbGVhcSAgVkNQVV90cmFwX2JvdW5jZSgl
cmJ4KSwlcmR4CiAgICAgICAgIHRlc3RsICR+MywlZXNpCiAgICAgICAgIGxlYWwgICgsJXJjeCxU
QkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEgICVyYXgs
VFJBUEJPVU5DRV9laXAoJXJkeCkKK1VOTElLRUxZX1NUQVJUKHosIGNvbXBhdF9zeXNjYWxsX2dw
ZikKKyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJkaQorICAgICAgICBtb3Zs
ICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VibCAg
JDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29k
ZSglcmR4KQorICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsg
VFJBUElORk9fZWlwKCVyZGkpLCVlYXgKKyAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBU
UkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcmRpKSwlZXNpCisgICAgICAgIHRlc3RiICQ0
LFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19mbGFncyglcmRpKQor
ICAgICAgICBzZXRueiAlY2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREUoLCVyY3gsVEJGX0lOVEVSUlVQVCksJWVjeAorVU5MSUtFTFlfRU5EKGNvbXBh
dF9zeXNjYWxsX2dwZikKKyAgICAgICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQog
ICAgICAgICBtb3Z3ICAlc2ksVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3ZiICAlY2ws
VFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICBjYWxsICBjb21wYXRfY3JlYXRlX2JvdW5j
ZV9mcmFtZQotICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dnEgIFZDUFVfdHJhcF9jdHh0KCVyYngpLCVyc2kKLSAgICAgICAgbW92bCAgJFRSQVBfZ3BfZmF1
bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3ApCi0gICAgICAgIHN1YmwgICQyLFVSRUdTX3JpcCgl
cnNwKQotICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsgVFJB
UElORk9fZWlwKCVyc2kpLCVlYXgKLSAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBUUkFQ
SU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcnNpKSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJG
X0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAg
ICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAx
YgorICAgICAgICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBh
dF9zeXNlbnRlcikKICAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJjeApkaWZm
IC1yIDYwOTI2NDFlMzY0NCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2Fy
Y2gveDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBBcHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysg
Yi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowNToxOSAyMDEyICsw
MTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcg
JFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAog
CisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3Mg
aXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAg
IHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVj
eAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAg
ICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEg
ICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBAIHJlc3RvcmVf
YWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9p
cmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEg
IDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVy
MTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lz
dGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjc3LDIwICsyODgs
MjIgQEAgc3lzZW50ZXJfZWZsYWdzX3NhdmVkOgogICAgICAgICBsZWFxICBWQ1BVX3RyYXBfYm91
bmNlKCVyYngpLCVyZHgKICAgICAgICAgdGVzdHEgJXJheCwlcmF4CiAgICAgICAgIGxlYWwgICgs
JXJjeCxUQkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEg
IFZDUFVfZG9tYWluKCVyYngpLCVyZGkKK1VOTElLRUxZX1NUQVJUKHosIHN5c2VudGVyX2dwZikK
KyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJzaQorICAgICAgICBtb3ZsICAk
VFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VicSAgJDIs
VVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2Rl
KCVyZHgpCisgICAgICAgIG1vdnEgIFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBU
UkFQSU5GT19laXAoJXJzaSksJXJheAorICAgICAgICB0ZXN0YiAkNCxUUkFQX2dwX2ZhdWx0ICog
VFJBUElORk9fc2l6ZW9mICsgVFJBUElORk9fZmxhZ3MoJXJzaSkKKyAgICAgICAgc2V0bnogJWNs
CisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4
LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChzeXNlbnRlcl9ncGYpCisgICAgICAg
IG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAgICAgbW92cSAgJXJheCxUUkFQQk9V
TkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYoJXJkaSkKICAgICAgICAgam56ICAg
Y29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAg
ICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1vdnEgIFZDUFVfdHJhcF9jdHh0KCVy
YngpLCVyY3gKLSAgICAgICAgbW92bCAgJWVheCxUUkFQQk9VTkNFX2Vycm9yX2NvZGUoJXJkeCkK
LSAgICAgICAgbW92cSAgVFJBUF9ncF9mYXVsdCAqIFRSQVBJTkZPX3NpemVvZiArIFRSQVBJTkZP
X2VpcCglcmN4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRUUkFQX2dwX2Zh
dWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgorICAgICAgICBq
bXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3RyYXApCiAgICAg
ICAgIHB1c2hxICQwCkBAIC00ODMsNiArNDk2LDcgQEAgMTogICAgICBtb3ZxICAlcnNwLCVyZGkK
ICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAgICAgICB0ZXN0
YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIGp6ICAgIHRl
c3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxsICBjcmVhdGVf
Ym91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAg
ICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--xk0dLwRkyW
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.1.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciAzNTI0OGJlNjY5ZTcgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTI6MzMgMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjEyOjMzIDIwMTIgKzAxMDAKQEAgLTIxNCw2ICsyMTQsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjI2LDE5ICsyMjcsMjAgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAgICAgICAgIGxlYXEgIFZDUFVfdHJhcF9ib3VuY2UoJXJieCksJXJkeAogICAg
ICAgICB0ZXN0bCAkfjMsJWVzaQogICAgICAgICBsZWFsICAoLCVyY3gsVEJGX0lOVEVSUlVQVCks
JWVjeAotICAgICAgICBqeiAgICAyZgotMTogICAgICBtb3ZxICAlcmF4LFRSQVBCT1VOQ0VfZWlw
KCVyZHgpCitVTkxJS0VMWV9TVEFSVCh6LCBjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJs
ICAkMixVUkVHU19yaXAoJXJzcCkKKyAgICAgICAgbW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9j
b2RlKCVyZHgpCisgICAgICAgIG1vdmwgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlZWF4Cisg
ICAgICAgIG1vdnp3bCBWQ1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCisgICAgICAgIHRlc3Ri
ICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAg
IGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRF
UlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAgICAgbW92dyAgJXNpLFRSQVBCT1VO
Q0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKLSAg
ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgY29t
cGF0X3Rlc3RfYWxsX2V2ZW50cwotMjogICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19l
bnRyeV92ZWN0b3IoJXJzcCkKLSAgICAgICAgc3VibCAgJDIsVVJFR1NfcmlwKCVyc3ApCi0gICAg
ICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdnp3bCBW
Q1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElP
TnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwg
ICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAxYgorICAgICAg
ICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBhdF9zeXNlbnRl
cikKICAgICAgICAgY21wbCAgJFRSQVBfZ3BfZmF1bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3Ap
CmRpZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwotLS0gYS94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJTW9uIE1heSAxNCAxNjo1OToxMiAyMDEyICswMTAw
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwlUaHUgTWF5IDI0IDExOjEyOjMzIDIw
MTIgKzAxMDAKQEAgLTQwLDYgKzQwLDEzIEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICB0
ZXN0dyAkVFJBUF9zeXNjYWxsLDQoJXJzcCkKICAgICAgICAganogICAgaXJldF9leGl0X3RvX2d1
ZXN0CiAKKyAgICAgICAgLyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRoIGlmIHRoZSByZXR1cm4gYWRk
cmVzcyBpcyBub3QgY2Fub25pY2FsLiAqLworICAgICAgICBtb3ZxICA4KCVyc3ApLCVyY3gKKyAg
ICAgICAgc2FycSAgJDQ3LCVyY3gKKyAgICAgICAgaW5jbCAgJWVjeAorICAgICAgICBjbXBsICAk
MSwlZWN4CisgICAgICAgIGphICAgIC5MZm9yY2VfaXJldAorCiAgICAgICAgIGFkZHEgICQ4LCVy
c3AKICAgICAgICAgcG9wcSAgJXJjeCAgICAgICAgICAgICAgICAgICAgIyBSSVAKICAgICAgICAg
cG9wcSAgJXIxMSAgICAgICAgICAgICAgICAgICAgIyBDUwpAQCAtNTAsNiArNTcsMTAgQEAgcmVz
dG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIHN5c3JldHEKIDE6ICAgICAgc3lzcmV0bAogCisuTGZv
cmNlX2lyZXQ6CisgICAgICAgIC8qIE1pbWljIFNZU1JFVCBiZWhhdmlvci4gKi8KKyAgICAgICAg
bW92cSAgOCglcnNwKSwlcmN4ICAgICAgICAgICAgIyBSSVAKKyAgICAgICAgbW92cSAgMjQoJXJz
cCksJXIxMSAgICAgICAgICAgIyBSRkxBR1MKICAgICAgICAgQUxJR04KIC8qIE5vIHNwZWNpYWwg
cmVnaXN0ZXIgYXNzdW1wdGlvbnMuICovCiBpcmV0X2V4aXRfdG9fZ3Vlc3Q6CkBAIC0yNzgsMTkg
KzI4OSwyMSBAQCBzeXNlbnRlcl9lZmxhZ3Nfc2F2ZWQ6CiAgICAgICAgIGxlYXEgIFZDUFVfdHJh
cF9ib3VuY2UoJXJieCksJXJkeAogICAgICAgICB0ZXN0cSAlcmF4LCVyYXgKICAgICAgICAgbGVh
bCAgKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKLSAgICAgICAganogICAgMmYKLTE6ICAgICAg
bW92cSAgVkNQVV9kb21haW4oJXJieCksJXJkaQorVU5MSUtFTFlfU1RBUlQoeiwgc3lzZW50ZXJf
Z3BmKQorICAgICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJz
cCkKKyAgICAgICAgc3VicSAgJDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgs
VFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRf
YWRkciglcmJ4KSwlcmF4CisgICAgICAgIHRlc3RiICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJi
eCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VY
Q0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChz
eXNlbnRlcl9ncGYpCisgICAgICAgIG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAg
ICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJB
UEJPVU5DRV9mbGFncyglcmR4KQogICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYo
JXJkaSkKICAgICAgICAgam56ICAgY29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0
ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCi0gICAgICAgIG1vdnEgIFZDUFVf
Z3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxU
QkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRU
UkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgor
ICAgICAgICBqbXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3Ry
YXApCiAgICAgICAgIHB1c2hxICQwCkBAIC00ODIsNiArNDk1LDcgQEAgMTogICAgICBtb3ZxICAl
cnNwLCVyZGkKICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAg
ICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAg
IGp6ICAgIHRlc3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxs
ICBjcmVhdGVfYm91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3Mo
JXJkeCkKICAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--xk0dLwRkyW
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.0.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.0.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciBkOGZkNDI1YjYwZDMgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTg6NDcgMjAxMiArMDEwMApAQCAtODksNiArODksOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgZDhmZDQyNWI2MGQzIHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjE4OjQ3IDIwMTIgKzAxMDAKQEAgLTIyNyw2ICsyMjcsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjQzLDE0ICsyNDQsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IGQ4ZmQ0MjViNjBkMyB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBNYXkgMDEgMTQ6MTg6NDYgMjAxMiArMDEwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMToxODo0NyAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk4LDEyICszMDksMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ5MCw2ICs1MDMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--xk0dLwRkyW
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-3.4.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-3.4.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA1MWJkMWYxNzI3NTggeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTI6NDE6MDggMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgNTFiZDFmMTcyNzU4IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDEyOjQxOjA4IDIwMTIgKzAxMDAKQEAgLTIxNSw2ICsyMTUsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjMxLDE0ICsyMzIsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IDUxYmQxZjE3Mjc1OCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCUZyaSBTZXAgMzAgMTc6MzU6MjkgMjAxMSAtMDQwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMjo0MTowOCAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk2LDEyICszMDcsMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ4MCw2ICs0OTMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--xk0dLwRkyW
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--xk0dLwRkyW--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:03:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePoQ-0002YP-B4; Tue, 12 Jun 2012 12:03:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SePoO-0002Xf-OY
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:03:04 +0000
Received: from [85.158.139.83:53523] by server-12.bemta-5.messagelabs.com id
	A5/CC-18374-6FF27DF4; Tue, 12 Jun 2012 12:03:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339502581!25849996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12638 invoked from network); 12 Jun 2012 12:03:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:03:02 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:02:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:02:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePns-0006QG-Ea; Tue, 12 Jun 2012 12:02:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePns-0005Tn-CB;
	Tue, 12 Jun 2012 13:02:32 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="xk0dLwRkyW"
Content-Transfer-Encoding: 7bit
Message-ID: <20439.12248.291249.667993@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:02:32 +0100
From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, oss-security@lists.openwall.com
Subject: [Xen-devel] Xen Security Advisory 7 (CVE-2012-0217) - PV privilege
	escalation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--xk0dLwRkyW
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

              Xen Security Advisory CVE-2012-0217 / XSA-7
                            version 9

           64-bit PV guest privilege escalation vulnerability

UPDATES IN VERSION 9
====================

Public release.  Previous versions were embargoed.

ISSUE DESCRIPTION
=================

Rafal Wojtczuk has discovered a vulnerability which can allow a 64-bit
PV guest kernel running on a 64-bit hypervisor to escalate privileges
to that of the host by arranging for a system call to return via
sysret to a non-canonical RIP.  Intel CPUs deliver the resulting
exception in an undesirable processor state.

IMPACT
======

Guest administrators can gain control of the host.

Depending on the particular guest kernel it is also possible that
non-privileged guest user processes can also elevate their privileges
to that of the host.

VULNERABLE SYSTEMS
==================

All systems running 64 bit Xen hypervisor running 64 bit PV guests on
Intel CPUs are vulnerable to this issue.

Systems using AMD CPUs are not vulnerable to this privilege
escalation. AMD have issued the following statement:
   AMD processors' SYSRET behavior is such that a non-canonical
   address in RCX does not generate a #GP while in CPL0. We have
   verified this with our architecture team, with our design team, and
   have performed tests that verified this on silicon. Therefore, this
   privilege escalation exposure is not applicable to any AMD
   processor.

While investigating this, it was noted that some older AMD CPUs will
lock up under similar circumstances, causing a denial of service. See
XSA-9 for details.

MITIGATION
==========

This issue can be mitigated by running HVM (fully-virtualised)
or 32 bit PV guests only.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

These patches also resolve the issue described in XSA-8 (CVE-2012-0128).

These changes have been made to the staging Xen repositories:
                    XSA-7:              XSA-8:
 xen-unstable.hg     25480:76eaf5966c05  25200:80f4113be500+25204:569d6f05e1ef
 xen-4.1-testing.hg  23299:f08e61b9b33f  23300:0fec1afa4638
 xen-4.0-testing.hg  21590:dd367837e089  21591:adb943a387c8
 xen-3.4-testing.hg  19996:894aa06e4f79  19997:ddb7578abb89

PATCH INFORMATION
=================

The attached patches resolve both this issue and that reported in
XSA-8 (CVE-2012-0128).

 xen-unstable 25204:569d6f05e1ef or later    xsa7-xsa8-unstable-recent.patch  
 xen-unstable 25199:6092641e3644 or earlier  xsa7-xsa8-unstable-apr16.patch
 Xen 4.1, 4.1.x                              xsa7-xsa8-xen-4.1.patch
 Xen 4.0, 4.0.x                              xsa7-xsa8-xen-4.0.patch
 Xen 3.4, 3.4.x                              xsa7-xsa8-xen-3.4.patch

$ sha256sum xsa7-xsa8-*patch
00853d799d24af16b17c8bbbdb5bb5144a8a7fad31467c4be3d879244774f8d2  xsa7-xsa8-unstable-apr16.patch
71f9907a58c1a1cd601d8088faf8791923d78f77065b94dba8df2a61f512530d  xsa7-xsa8-unstable-recent.patch
55fb925a7f4519ea31a0bc42d3ee83093bb7abd98b3a0e4f58591f1ae738840a  xsa7-xsa8-xen-3.4.patch
6a7e39121ec1f134351fdf34f494d108500aaa4190a9f7965e81c4e96270924e  xsa7-xsa8-xen-4.0.patch
52d8288718b4a833eb437fd18d92b7d412fbe01900dbd0b437744a1df4d459da  xsa7-xsa8-xen-4.1.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP1yqTAAoJEIP+FMlX6CvZntwH/jzuqabF9yGMIXQBckjZUv1E
XeY9dbz1uGoMzy0mBFufwbJQqdBt89SNYDkr2BxKxSghSvBs608KHuh8giF1hzvm
8oP2K5T3Rk/jl0gdc3VlZz15Yi9kVEDUOSu2rPQLbhmiv6ht+Y2Of2cp63RioEvq
G2QQouHDsipCUZV4Ow5xnPY/KBifh46uCCnLDjV5Q/6WScI8VOIreOADryOpn2+/
8QmyCo2Sl2F+YxlbCl7k3qyqihaSONymeVg0pkJbH5LmRdTQnJX9fMJSQvfV6Bxs
U4PD4ve0C9+/Usz4XFejlQLt/kv4ZNPD6QF2rXei3oElmYAVcHL2XdLVCNLbAeY=
=S6KX
-----END PGP SIGNATURE-----


--xk0dLwRkyW
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-recent.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-recent.patch"
Content-Transfer-Encoding: base64

eDg2XzY0OiBEbyBub3QgZXhlY3V0ZSBzeXNyZXQgd2l0aCBhIG5vbi1jYW5vbmljYWwgcmV0dXJu
IGFkZHJlc3MKCkNoZWNrIGZvciBub24tY2Fub25pY2FsIGd1ZXN0IFJJUCBiZWZvcmUgYXR0ZW1w
dGluZyB0byBleGVjdXRlIHN5c3JldC4KSWYgc3lzcmV0IGlzIGV4ZWN1dGVkIHdpdGggYSBub24t
Y2Fub25pY2FsIHZhbHVlIGluIFJDWCwgSW50ZWwgQ1BVcwp0YWtlIHRoZSBmYXVsdCBpbiByaW5n
MCwgYnV0IHdlIHdpbGwgbmVjZXNzYXJpbHkgYWxyZWFkeSBoYXZlIHN3aXRjaGVkCnRvIHRoZSB0
aGUgdXNlcidzIHN0YWNrIHBvaW50ZXIuCgpUaGlzIGlzIGEgc2VjdXJpdHkgdnVsbmVyYWJpbGl0
eSwgWFNBLTcgLyBDVkUtMjAxMi0wMjE3LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPEpC
ZXVsaWNoQHN1c2UuY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUu
Y2l0cml4LmNvbT4KVGVzdGVkLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXgu
Y29tPgpBY2tlZC1ieTogS2VpciBGcmFzZXIgPGtlaXIueGVuQGdtYWlsLmNvbT4KQ29tbWl0dGVk
LWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLXIgMzQw
MDYyZmFmMjk4IC1yIGFkODc5MDNmZGNhMSB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCVdlZCBNYXkgMjMgMTE6MDY6NDkgMjAxMiAr
MDEwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowMjoz
NSAyMDEyICswMTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAg
ICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90
b19ndWVzdAogCisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJu
IGFkZHJlc3MgaXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4
CisgICAgICAgIHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21w
bCAgJDEsJWVjeAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAk
OCwlcnNwCiAgICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAg
ICAgIHBvcHEgICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBA
IHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAor
Lkxmb3JjZV9pcmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAg
ICAgIG1vdnEgIDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0
KCVyc3ApLCVyMTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVj
aWFsIHJlZ2lzdGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0Ogo=
--xk0dLwRkyW
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-apr16.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-apr16.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgQXByIDE3IDE1OjA1OjA1
IDIwMTIgKzAyMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMTQ1LDYgKzE0NSw3IEBAIHZvaWQgX19kdW1t
eV9fKHZvaWQpCiAKICAgICBPRkZTRVQoVFJBUElORk9fZWlwLCBzdHJ1Y3QgdHJhcF9pbmZvLCBh
ZGRyZXNzKTsKICAgICBPRkZTRVQoVFJBUElORk9fY3MsIHN0cnVjdCB0cmFwX2luZm8sIGNzKTsK
KyAgICBPRkZTRVQoVFJBUElORk9fZmxhZ3MsIHN0cnVjdCB0cmFwX2luZm8sIGZsYWdzKTsKICAg
ICBERUZJTkUoVFJBUElORk9fc2l6ZW9mLCBzaXplb2Yoc3RydWN0IHRyYXBfaW5mbykpOwogICAg
IEJMQU5LKCk7CiAKZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCVR1ZSBB
cHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBh
dC9lbnRyeS5TCVRodSBNYXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMjEzLDYgKzIxMyw3
IEBAIDE6ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKIEVOVFJZKGNvbXBh
dF9wb3N0X2hhbmRsZV9leGNlcHRpb24pCiAgICAgICAgIHRlc3RiICRUQkZfRVhDRVBUSU9OLFRS
QVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50
cworLkxjb21wYXRfYm91bmNlX2V4Y2VwdGlvbjoKICAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0
ZV9ib3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCkBAIC0yMjUsMjAgKzIyNiwyMSBA
QCBFTlRSWShjb21wYXRfc3lzY2FsbCkKICAgICAgICAgbGVhcSAgVkNQVV90cmFwX2JvdW5jZSgl
cmJ4KSwlcmR4CiAgICAgICAgIHRlc3RsICR+MywlZXNpCiAgICAgICAgIGxlYWwgICgsJXJjeCxU
QkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEgICVyYXgs
VFJBUEJPVU5DRV9laXAoJXJkeCkKK1VOTElLRUxZX1NUQVJUKHosIGNvbXBhdF9zeXNjYWxsX2dw
ZikKKyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJkaQorICAgICAgICBtb3Zs
ICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VibCAg
JDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29k
ZSglcmR4KQorICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsg
VFJBUElORk9fZWlwKCVyZGkpLCVlYXgKKyAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBU
UkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcmRpKSwlZXNpCisgICAgICAgIHRlc3RiICQ0
LFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19mbGFncyglcmRpKQor
ICAgICAgICBzZXRueiAlY2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREUoLCVyY3gsVEJGX0lOVEVSUlVQVCksJWVjeAorVU5MSUtFTFlfRU5EKGNvbXBh
dF9zeXNjYWxsX2dwZikKKyAgICAgICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQog
ICAgICAgICBtb3Z3ICAlc2ksVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3ZiICAlY2ws
VFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICBjYWxsICBjb21wYXRfY3JlYXRlX2JvdW5j
ZV9mcmFtZQotICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dnEgIFZDUFVfdHJhcF9jdHh0KCVyYngpLCVyc2kKLSAgICAgICAgbW92bCAgJFRSQVBfZ3BfZmF1
bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3ApCi0gICAgICAgIHN1YmwgICQyLFVSRUdTX3JpcCgl
cnNwKQotICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsgVFJB
UElORk9fZWlwKCVyc2kpLCVlYXgKLSAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBUUkFQ
SU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcnNpKSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJG
X0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAg
ICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAx
YgorICAgICAgICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBh
dF9zeXNlbnRlcikKICAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJjeApkaWZm
IC1yIDYwOTI2NDFlMzY0NCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2Fy
Y2gveDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBBcHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysg
Yi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowNToxOSAyMDEyICsw
MTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcg
JFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAog
CisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3Mg
aXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAg
IHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVj
eAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAg
ICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEg
ICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBAIHJlc3RvcmVf
YWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9p
cmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEg
IDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVy
MTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lz
dGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjc3LDIwICsyODgs
MjIgQEAgc3lzZW50ZXJfZWZsYWdzX3NhdmVkOgogICAgICAgICBsZWFxICBWQ1BVX3RyYXBfYm91
bmNlKCVyYngpLCVyZHgKICAgICAgICAgdGVzdHEgJXJheCwlcmF4CiAgICAgICAgIGxlYWwgICgs
JXJjeCxUQkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEg
IFZDUFVfZG9tYWluKCVyYngpLCVyZGkKK1VOTElLRUxZX1NUQVJUKHosIHN5c2VudGVyX2dwZikK
KyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJzaQorICAgICAgICBtb3ZsICAk
VFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VicSAgJDIs
VVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2Rl
KCVyZHgpCisgICAgICAgIG1vdnEgIFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBU
UkFQSU5GT19laXAoJXJzaSksJXJheAorICAgICAgICB0ZXN0YiAkNCxUUkFQX2dwX2ZhdWx0ICog
VFJBUElORk9fc2l6ZW9mICsgVFJBUElORk9fZmxhZ3MoJXJzaSkKKyAgICAgICAgc2V0bnogJWNs
CisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4
LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChzeXNlbnRlcl9ncGYpCisgICAgICAg
IG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAgICAgbW92cSAgJXJheCxUUkFQQk9V
TkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYoJXJkaSkKICAgICAgICAgam56ICAg
Y29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAg
ICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1vdnEgIFZDUFVfdHJhcF9jdHh0KCVy
YngpLCVyY3gKLSAgICAgICAgbW92bCAgJWVheCxUUkFQQk9VTkNFX2Vycm9yX2NvZGUoJXJkeCkK
LSAgICAgICAgbW92cSAgVFJBUF9ncF9mYXVsdCAqIFRSQVBJTkZPX3NpemVvZiArIFRSQVBJTkZP
X2VpcCglcmN4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRUUkFQX2dwX2Zh
dWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgorICAgICAgICBq
bXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3RyYXApCiAgICAg
ICAgIHB1c2hxICQwCkBAIC00ODMsNiArNDk2LDcgQEAgMTogICAgICBtb3ZxICAlcnNwLCVyZGkK
ICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAgICAgICB0ZXN0
YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIGp6ICAgIHRl
c3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxsICBjcmVhdGVf
Ym91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAg
ICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--xk0dLwRkyW
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.1.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciAzNTI0OGJlNjY5ZTcgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTI6MzMgMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjEyOjMzIDIwMTIgKzAxMDAKQEAgLTIxNCw2ICsyMTQsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjI2LDE5ICsyMjcsMjAgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAgICAgICAgIGxlYXEgIFZDUFVfdHJhcF9ib3VuY2UoJXJieCksJXJkeAogICAg
ICAgICB0ZXN0bCAkfjMsJWVzaQogICAgICAgICBsZWFsICAoLCVyY3gsVEJGX0lOVEVSUlVQVCks
JWVjeAotICAgICAgICBqeiAgICAyZgotMTogICAgICBtb3ZxICAlcmF4LFRSQVBCT1VOQ0VfZWlw
KCVyZHgpCitVTkxJS0VMWV9TVEFSVCh6LCBjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJs
ICAkMixVUkVHU19yaXAoJXJzcCkKKyAgICAgICAgbW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9j
b2RlKCVyZHgpCisgICAgICAgIG1vdmwgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlZWF4Cisg
ICAgICAgIG1vdnp3bCBWQ1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCisgICAgICAgIHRlc3Ri
ICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAg
IGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRF
UlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAgICAgbW92dyAgJXNpLFRSQVBCT1VO
Q0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKLSAg
ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgY29t
cGF0X3Rlc3RfYWxsX2V2ZW50cwotMjogICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19l
bnRyeV92ZWN0b3IoJXJzcCkKLSAgICAgICAgc3VibCAgJDIsVVJFR1NfcmlwKCVyc3ApCi0gICAg
ICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdnp3bCBW
Q1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElP
TnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwg
ICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAxYgorICAgICAg
ICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBhdF9zeXNlbnRl
cikKICAgICAgICAgY21wbCAgJFRSQVBfZ3BfZmF1bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3Ap
CmRpZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwotLS0gYS94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJTW9uIE1heSAxNCAxNjo1OToxMiAyMDEyICswMTAw
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwlUaHUgTWF5IDI0IDExOjEyOjMzIDIw
MTIgKzAxMDAKQEAgLTQwLDYgKzQwLDEzIEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICB0
ZXN0dyAkVFJBUF9zeXNjYWxsLDQoJXJzcCkKICAgICAgICAganogICAgaXJldF9leGl0X3RvX2d1
ZXN0CiAKKyAgICAgICAgLyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRoIGlmIHRoZSByZXR1cm4gYWRk
cmVzcyBpcyBub3QgY2Fub25pY2FsLiAqLworICAgICAgICBtb3ZxICA4KCVyc3ApLCVyY3gKKyAg
ICAgICAgc2FycSAgJDQ3LCVyY3gKKyAgICAgICAgaW5jbCAgJWVjeAorICAgICAgICBjbXBsICAk
MSwlZWN4CisgICAgICAgIGphICAgIC5MZm9yY2VfaXJldAorCiAgICAgICAgIGFkZHEgICQ4LCVy
c3AKICAgICAgICAgcG9wcSAgJXJjeCAgICAgICAgICAgICAgICAgICAgIyBSSVAKICAgICAgICAg
cG9wcSAgJXIxMSAgICAgICAgICAgICAgICAgICAgIyBDUwpAQCAtNTAsNiArNTcsMTAgQEAgcmVz
dG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIHN5c3JldHEKIDE6ICAgICAgc3lzcmV0bAogCisuTGZv
cmNlX2lyZXQ6CisgICAgICAgIC8qIE1pbWljIFNZU1JFVCBiZWhhdmlvci4gKi8KKyAgICAgICAg
bW92cSAgOCglcnNwKSwlcmN4ICAgICAgICAgICAgIyBSSVAKKyAgICAgICAgbW92cSAgMjQoJXJz
cCksJXIxMSAgICAgICAgICAgIyBSRkxBR1MKICAgICAgICAgQUxJR04KIC8qIE5vIHNwZWNpYWwg
cmVnaXN0ZXIgYXNzdW1wdGlvbnMuICovCiBpcmV0X2V4aXRfdG9fZ3Vlc3Q6CkBAIC0yNzgsMTkg
KzI4OSwyMSBAQCBzeXNlbnRlcl9lZmxhZ3Nfc2F2ZWQ6CiAgICAgICAgIGxlYXEgIFZDUFVfdHJh
cF9ib3VuY2UoJXJieCksJXJkeAogICAgICAgICB0ZXN0cSAlcmF4LCVyYXgKICAgICAgICAgbGVh
bCAgKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKLSAgICAgICAganogICAgMmYKLTE6ICAgICAg
bW92cSAgVkNQVV9kb21haW4oJXJieCksJXJkaQorVU5MSUtFTFlfU1RBUlQoeiwgc3lzZW50ZXJf
Z3BmKQorICAgICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJz
cCkKKyAgICAgICAgc3VicSAgJDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgs
VFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRf
YWRkciglcmJ4KSwlcmF4CisgICAgICAgIHRlc3RiICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJi
eCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VY
Q0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChz
eXNlbnRlcl9ncGYpCisgICAgICAgIG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAg
ICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJB
UEJPVU5DRV9mbGFncyglcmR4KQogICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYo
JXJkaSkKICAgICAgICAgam56ICAgY29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0
ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCi0gICAgICAgIG1vdnEgIFZDUFVf
Z3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxU
QkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRU
UkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgor
ICAgICAgICBqbXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3Ry
YXApCiAgICAgICAgIHB1c2hxICQwCkBAIC00ODIsNiArNDk1LDcgQEAgMTogICAgICBtb3ZxICAl
cnNwLCVyZGkKICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAg
ICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAg
IGp6ICAgIHRlc3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxs
ICBjcmVhdGVfYm91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3Mo
JXJkeCkKICAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--xk0dLwRkyW
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.0.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.0.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciBkOGZkNDI1YjYwZDMgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTg6NDcgMjAxMiArMDEwMApAQCAtODksNiArODksOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgZDhmZDQyNWI2MGQzIHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjE4OjQ3IDIwMTIgKzAxMDAKQEAgLTIyNyw2ICsyMjcsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjQzLDE0ICsyNDQsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IGQ4ZmQ0MjViNjBkMyB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBNYXkgMDEgMTQ6MTg6NDYgMjAxMiArMDEwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMToxODo0NyAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk4LDEyICszMDksMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ5MCw2ICs1MDMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--xk0dLwRkyW
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-3.4.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-3.4.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA1MWJkMWYxNzI3NTggeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTI6NDE6MDggMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgNTFiZDFmMTcyNzU4IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDEyOjQxOjA4IDIwMTIgKzAxMDAKQEAgLTIxNSw2ICsyMTUsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjMxLDE0ICsyMzIsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IDUxYmQxZjE3Mjc1OCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCUZyaSBTZXAgMzAgMTc6MzU6MjkgMjAxMSAtMDQwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMjo0MTowOCAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk2LDEyICszMDcsMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ4MCw2ICs0OTMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--xk0dLwRkyW
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--xk0dLwRkyW--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:04:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePoj-0002eU-RR; Tue, 12 Jun 2012 12:03:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SePoi-0002dk-8J
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:03:24 +0000
Received: from [85.158.143.99:64771] by server-1.bemta-4.messagelabs.com id
	3E/91-24392-A0037DF4; Tue, 12 Jun 2012 12:03:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339502601!30118335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13741 invoked from network); 12 Jun 2012 12:03:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:03:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:03:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePod-0006Qb-2T; Tue, 12 Jun 2012 12:03:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePod-0005U2-1b;
	Tue, 12 Jun 2012 13:03:19 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="dbC35hETsu"
Content-Transfer-Encoding: 7bit
Message-ID: <20439.12295.26429.618451@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:03:19 +0100
From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, oss-security@lists.openwall.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen Security Advisory 8 (CVE-2012-0218) - syscall/enter
	guest DoS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--dbC35hETsu
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

               Xen Security Advisory CVE-2012-0218 / XSA-8
                              version 7

     guest denial of service on syscall/sysenter exception generation

UPDATES IN VERSION 7
====================

Public release.  Previous versions were embargoed.

ISSUE DESCRIPTION
=================

When guest user code running inside a Xen guest operating system
attempts to execute a syscall or sysenter instruction, but when the
guest operating system has not registered a handler for that
instruction, a General Protection Fault may need to be injected into
the guest.

It has been discovered that the code in Xen which does this fails to
clear a flag requesting exception injection, with the result that a
future exception taken by the guest and handled entirely inside Xen
will also be injected into the guest despite Xen having handled it
already, probably crashing the guest.

IMPACT
======

User space processes on some guest operating systems may be able to
crash the guest.

VULNERABLE SYSTEMS
==================

HVM guests are not vulnerable.

32- and 64-bit PV guests may be vulnerable, depending on the CPU
hardware, the guest operating system, and its exact kernel version and
configuration.

MITIGATION
==========

This issue can be mitigated by running HVM (fully-virtualised).

In some cases this issue can be mitigated by upgrading the guest
kernel to one which installs hooks for sysenter and/or syscall, as
applicable.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

These patches also resolve the (more serious) issue described in
XSA-7 (CVE-2012-0217).

These changes have been made to the staging Xen repositories:
                    XSA-7:              XSA-8:
 xen-unstable.hg     25480:76eaf5966c05  25200:80f4113be500+25204:569d6f05e1ef
 xen-4.1-testing.hg  23299:f08e61b9b33f  23300:0fec1afa4638
 xen-4.0-testing.hg  21590:dd367837e089  21591:adb943a387c8
 xen-3.4-testing.hg  19996:894aa06e4f79  19997:ddb7578abb89

PATCH INFORMATION
=================

The attached patches resolve both this issue and that reported in
XSA-7 (CVE-2012-0217).

 xen-unstable 25204:569d6f05e1ef or later    xsa7-xsa8-unstable-recent.patch  
 xen-unstable 25199:6092641e3644 or earlier  xsa7-xsa8-unstable-apr16.patch
 Xen 4.1, 4.1.x                              xsa7-xsa8-xen-4.1.patch
 Xen 4.0, 4.0.x                              xsa7-xsa8-xen-4.0.patch
 Xen 3.4, 3.4.x                              xsa7-xsa8-xen-3.4.patch

$ sha256sum xsa7-xsa8-*patch
00853d799d24af16b17c8bbbdb5bb5144a8a7fad31467c4be3d879244774f8d2  xsa7-xsa8-unstable-apr16.patch
71f9907a58c1a1cd601d8088faf8791923d78f77065b94dba8df2a61f512530d  xsa7-xsa8-unstable-recent.patch
55fb925a7f4519ea31a0bc42d3ee83093bb7abd98b3a0e4f58591f1ae738840a  xsa7-xsa8-xen-3.4.patch
6a7e39121ec1f134351fdf34f494d108500aaa4190a9f7965e81c4e96270924e  xsa7-xsa8-xen-4.0.patch
52d8288718b4a833eb437fd18d92b7d412fbe01900dbd0b437744a1df4d459da  xsa7-xsa8-xen-4.1.patch

NOTE REGARDING EMBARGO
======================

The fix for this issue has already been published as xen-unstable.hg
changesets 25200:80f4113be500 and 25204:569d6f05e1ef.  However, this
has not been flagged as a security problem, and since the affected
area of code is the same as that for XSA-7 (CVE-2012-0217), we have
concluded that this advisory should be under the same embargo as
XSA-7.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP1yqMAAoJEIP+FMlX6CvZQRoH/1Do71YkaMvKoPo/VCHqUuB1
5mJve/SiTK5Y5kggnLfnpZeuLjlntHCT5F//Do7N21WDVdwZXFBItlvjhKyNGA0Y
ohqzqzAQ0c2l/mE3ToaLhhtuFb8U06q8Ud+pQ9QbMHHpJvGXPzDbNG12L/fZDwyf
ZbMqB2j8+TVuRXPlbdZabNUAcZ+HOJHb1NloKCbX0qwMG4p5FJ3OdkDX7r5OjPKj
sIJAaltBINGjRrqYMLB4UUQdrftu1ftfU/GFVYy8+t3uNj0fBgkCPUlGbbQs2SF2
+VtLUUG6rzVlRdHyhVMswz3sZtR7Tow6xwPk3Sr4yfrI15rH2pUJI7if8vZ1ZQ8=
=elZi
-----END PGP SIGNATURE-----


--dbC35hETsu
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-recent.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-recent.patch"
Content-Transfer-Encoding: base64

eDg2XzY0OiBEbyBub3QgZXhlY3V0ZSBzeXNyZXQgd2l0aCBhIG5vbi1jYW5vbmljYWwgcmV0dXJu
IGFkZHJlc3MKCkNoZWNrIGZvciBub24tY2Fub25pY2FsIGd1ZXN0IFJJUCBiZWZvcmUgYXR0ZW1w
dGluZyB0byBleGVjdXRlIHN5c3JldC4KSWYgc3lzcmV0IGlzIGV4ZWN1dGVkIHdpdGggYSBub24t
Y2Fub25pY2FsIHZhbHVlIGluIFJDWCwgSW50ZWwgQ1BVcwp0YWtlIHRoZSBmYXVsdCBpbiByaW5n
MCwgYnV0IHdlIHdpbGwgbmVjZXNzYXJpbHkgYWxyZWFkeSBoYXZlIHN3aXRjaGVkCnRvIHRoZSB0
aGUgdXNlcidzIHN0YWNrIHBvaW50ZXIuCgpUaGlzIGlzIGEgc2VjdXJpdHkgdnVsbmVyYWJpbGl0
eSwgWFNBLTcgLyBDVkUtMjAxMi0wMjE3LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPEpC
ZXVsaWNoQHN1c2UuY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUu
Y2l0cml4LmNvbT4KVGVzdGVkLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXgu
Y29tPgpBY2tlZC1ieTogS2VpciBGcmFzZXIgPGtlaXIueGVuQGdtYWlsLmNvbT4KQ29tbWl0dGVk
LWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLXIgMzQw
MDYyZmFmMjk4IC1yIGFkODc5MDNmZGNhMSB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCVdlZCBNYXkgMjMgMTE6MDY6NDkgMjAxMiAr
MDEwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowMjoz
NSAyMDEyICswMTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAg
ICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90
b19ndWVzdAogCisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJu
IGFkZHJlc3MgaXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4
CisgICAgICAgIHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21w
bCAgJDEsJWVjeAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAk
OCwlcnNwCiAgICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAg
ICAgIHBvcHEgICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBA
IHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAor
Lkxmb3JjZV9pcmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAg
ICAgIG1vdnEgIDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0
KCVyc3ApLCVyMTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVj
aWFsIHJlZ2lzdGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0Ogo=
--dbC35hETsu
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-apr16.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-apr16.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgQXByIDE3IDE1OjA1OjA1
IDIwMTIgKzAyMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMTQ1LDYgKzE0NSw3IEBAIHZvaWQgX19kdW1t
eV9fKHZvaWQpCiAKICAgICBPRkZTRVQoVFJBUElORk9fZWlwLCBzdHJ1Y3QgdHJhcF9pbmZvLCBh
ZGRyZXNzKTsKICAgICBPRkZTRVQoVFJBUElORk9fY3MsIHN0cnVjdCB0cmFwX2luZm8sIGNzKTsK
KyAgICBPRkZTRVQoVFJBUElORk9fZmxhZ3MsIHN0cnVjdCB0cmFwX2luZm8sIGZsYWdzKTsKICAg
ICBERUZJTkUoVFJBUElORk9fc2l6ZW9mLCBzaXplb2Yoc3RydWN0IHRyYXBfaW5mbykpOwogICAg
IEJMQU5LKCk7CiAKZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCVR1ZSBB
cHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBh
dC9lbnRyeS5TCVRodSBNYXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMjEzLDYgKzIxMyw3
IEBAIDE6ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKIEVOVFJZKGNvbXBh
dF9wb3N0X2hhbmRsZV9leGNlcHRpb24pCiAgICAgICAgIHRlc3RiICRUQkZfRVhDRVBUSU9OLFRS
QVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50
cworLkxjb21wYXRfYm91bmNlX2V4Y2VwdGlvbjoKICAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0
ZV9ib3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCkBAIC0yMjUsMjAgKzIyNiwyMSBA
QCBFTlRSWShjb21wYXRfc3lzY2FsbCkKICAgICAgICAgbGVhcSAgVkNQVV90cmFwX2JvdW5jZSgl
cmJ4KSwlcmR4CiAgICAgICAgIHRlc3RsICR+MywlZXNpCiAgICAgICAgIGxlYWwgICgsJXJjeCxU
QkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEgICVyYXgs
VFJBUEJPVU5DRV9laXAoJXJkeCkKK1VOTElLRUxZX1NUQVJUKHosIGNvbXBhdF9zeXNjYWxsX2dw
ZikKKyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJkaQorICAgICAgICBtb3Zs
ICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VibCAg
JDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29k
ZSglcmR4KQorICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsg
VFJBUElORk9fZWlwKCVyZGkpLCVlYXgKKyAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBU
UkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcmRpKSwlZXNpCisgICAgICAgIHRlc3RiICQ0
LFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19mbGFncyglcmRpKQor
ICAgICAgICBzZXRueiAlY2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREUoLCVyY3gsVEJGX0lOVEVSUlVQVCksJWVjeAorVU5MSUtFTFlfRU5EKGNvbXBh
dF9zeXNjYWxsX2dwZikKKyAgICAgICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQog
ICAgICAgICBtb3Z3ICAlc2ksVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3ZiICAlY2ws
VFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICBjYWxsICBjb21wYXRfY3JlYXRlX2JvdW5j
ZV9mcmFtZQotICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dnEgIFZDUFVfdHJhcF9jdHh0KCVyYngpLCVyc2kKLSAgICAgICAgbW92bCAgJFRSQVBfZ3BfZmF1
bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3ApCi0gICAgICAgIHN1YmwgICQyLFVSRUdTX3JpcCgl
cnNwKQotICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsgVFJB
UElORk9fZWlwKCVyc2kpLCVlYXgKLSAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBUUkFQ
SU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcnNpKSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJG
X0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAg
ICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAx
YgorICAgICAgICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBh
dF9zeXNlbnRlcikKICAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJjeApkaWZm
IC1yIDYwOTI2NDFlMzY0NCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2Fy
Y2gveDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBBcHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysg
Yi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowNToxOSAyMDEyICsw
MTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcg
JFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAog
CisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3Mg
aXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAg
IHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVj
eAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAg
ICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEg
ICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBAIHJlc3RvcmVf
YWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9p
cmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEg
IDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVy
MTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lz
dGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjc3LDIwICsyODgs
MjIgQEAgc3lzZW50ZXJfZWZsYWdzX3NhdmVkOgogICAgICAgICBsZWFxICBWQ1BVX3RyYXBfYm91
bmNlKCVyYngpLCVyZHgKICAgICAgICAgdGVzdHEgJXJheCwlcmF4CiAgICAgICAgIGxlYWwgICgs
JXJjeCxUQkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEg
IFZDUFVfZG9tYWluKCVyYngpLCVyZGkKK1VOTElLRUxZX1NUQVJUKHosIHN5c2VudGVyX2dwZikK
KyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJzaQorICAgICAgICBtb3ZsICAk
VFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VicSAgJDIs
VVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2Rl
KCVyZHgpCisgICAgICAgIG1vdnEgIFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBU
UkFQSU5GT19laXAoJXJzaSksJXJheAorICAgICAgICB0ZXN0YiAkNCxUUkFQX2dwX2ZhdWx0ICog
VFJBUElORk9fc2l6ZW9mICsgVFJBUElORk9fZmxhZ3MoJXJzaSkKKyAgICAgICAgc2V0bnogJWNs
CisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4
LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChzeXNlbnRlcl9ncGYpCisgICAgICAg
IG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAgICAgbW92cSAgJXJheCxUUkFQQk9V
TkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYoJXJkaSkKICAgICAgICAgam56ICAg
Y29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAg
ICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1vdnEgIFZDUFVfdHJhcF9jdHh0KCVy
YngpLCVyY3gKLSAgICAgICAgbW92bCAgJWVheCxUUkFQQk9VTkNFX2Vycm9yX2NvZGUoJXJkeCkK
LSAgICAgICAgbW92cSAgVFJBUF9ncF9mYXVsdCAqIFRSQVBJTkZPX3NpemVvZiArIFRSQVBJTkZP
X2VpcCglcmN4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRUUkFQX2dwX2Zh
dWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgorICAgICAgICBq
bXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3RyYXApCiAgICAg
ICAgIHB1c2hxICQwCkBAIC00ODMsNiArNDk2LDcgQEAgMTogICAgICBtb3ZxICAlcnNwLCVyZGkK
ICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAgICAgICB0ZXN0
YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIGp6ICAgIHRl
c3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxsICBjcmVhdGVf
Ym91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAg
ICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--dbC35hETsu
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.1.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciAzNTI0OGJlNjY5ZTcgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTI6MzMgMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjEyOjMzIDIwMTIgKzAxMDAKQEAgLTIxNCw2ICsyMTQsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjI2LDE5ICsyMjcsMjAgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAgICAgICAgIGxlYXEgIFZDUFVfdHJhcF9ib3VuY2UoJXJieCksJXJkeAogICAg
ICAgICB0ZXN0bCAkfjMsJWVzaQogICAgICAgICBsZWFsICAoLCVyY3gsVEJGX0lOVEVSUlVQVCks
JWVjeAotICAgICAgICBqeiAgICAyZgotMTogICAgICBtb3ZxICAlcmF4LFRSQVBCT1VOQ0VfZWlw
KCVyZHgpCitVTkxJS0VMWV9TVEFSVCh6LCBjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJs
ICAkMixVUkVHU19yaXAoJXJzcCkKKyAgICAgICAgbW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9j
b2RlKCVyZHgpCisgICAgICAgIG1vdmwgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlZWF4Cisg
ICAgICAgIG1vdnp3bCBWQ1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCisgICAgICAgIHRlc3Ri
ICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAg
IGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRF
UlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAgICAgbW92dyAgJXNpLFRSQVBCT1VO
Q0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKLSAg
ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgY29t
cGF0X3Rlc3RfYWxsX2V2ZW50cwotMjogICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19l
bnRyeV92ZWN0b3IoJXJzcCkKLSAgICAgICAgc3VibCAgJDIsVVJFR1NfcmlwKCVyc3ApCi0gICAg
ICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdnp3bCBW
Q1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElP
TnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwg
ICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAxYgorICAgICAg
ICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBhdF9zeXNlbnRl
cikKICAgICAgICAgY21wbCAgJFRSQVBfZ3BfZmF1bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3Ap
CmRpZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwotLS0gYS94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJTW9uIE1heSAxNCAxNjo1OToxMiAyMDEyICswMTAw
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwlUaHUgTWF5IDI0IDExOjEyOjMzIDIw
MTIgKzAxMDAKQEAgLTQwLDYgKzQwLDEzIEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICB0
ZXN0dyAkVFJBUF9zeXNjYWxsLDQoJXJzcCkKICAgICAgICAganogICAgaXJldF9leGl0X3RvX2d1
ZXN0CiAKKyAgICAgICAgLyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRoIGlmIHRoZSByZXR1cm4gYWRk
cmVzcyBpcyBub3QgY2Fub25pY2FsLiAqLworICAgICAgICBtb3ZxICA4KCVyc3ApLCVyY3gKKyAg
ICAgICAgc2FycSAgJDQ3LCVyY3gKKyAgICAgICAgaW5jbCAgJWVjeAorICAgICAgICBjbXBsICAk
MSwlZWN4CisgICAgICAgIGphICAgIC5MZm9yY2VfaXJldAorCiAgICAgICAgIGFkZHEgICQ4LCVy
c3AKICAgICAgICAgcG9wcSAgJXJjeCAgICAgICAgICAgICAgICAgICAgIyBSSVAKICAgICAgICAg
cG9wcSAgJXIxMSAgICAgICAgICAgICAgICAgICAgIyBDUwpAQCAtNTAsNiArNTcsMTAgQEAgcmVz
dG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIHN5c3JldHEKIDE6ICAgICAgc3lzcmV0bAogCisuTGZv
cmNlX2lyZXQ6CisgICAgICAgIC8qIE1pbWljIFNZU1JFVCBiZWhhdmlvci4gKi8KKyAgICAgICAg
bW92cSAgOCglcnNwKSwlcmN4ICAgICAgICAgICAgIyBSSVAKKyAgICAgICAgbW92cSAgMjQoJXJz
cCksJXIxMSAgICAgICAgICAgIyBSRkxBR1MKICAgICAgICAgQUxJR04KIC8qIE5vIHNwZWNpYWwg
cmVnaXN0ZXIgYXNzdW1wdGlvbnMuICovCiBpcmV0X2V4aXRfdG9fZ3Vlc3Q6CkBAIC0yNzgsMTkg
KzI4OSwyMSBAQCBzeXNlbnRlcl9lZmxhZ3Nfc2F2ZWQ6CiAgICAgICAgIGxlYXEgIFZDUFVfdHJh
cF9ib3VuY2UoJXJieCksJXJkeAogICAgICAgICB0ZXN0cSAlcmF4LCVyYXgKICAgICAgICAgbGVh
bCAgKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKLSAgICAgICAganogICAgMmYKLTE6ICAgICAg
bW92cSAgVkNQVV9kb21haW4oJXJieCksJXJkaQorVU5MSUtFTFlfU1RBUlQoeiwgc3lzZW50ZXJf
Z3BmKQorICAgICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJz
cCkKKyAgICAgICAgc3VicSAgJDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgs
VFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRf
YWRkciglcmJ4KSwlcmF4CisgICAgICAgIHRlc3RiICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJi
eCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VY
Q0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChz
eXNlbnRlcl9ncGYpCisgICAgICAgIG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAg
ICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJB
UEJPVU5DRV9mbGFncyglcmR4KQogICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYo
JXJkaSkKICAgICAgICAgam56ICAgY29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0
ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCi0gICAgICAgIG1vdnEgIFZDUFVf
Z3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxU
QkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRU
UkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgor
ICAgICAgICBqbXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3Ry
YXApCiAgICAgICAgIHB1c2hxICQwCkBAIC00ODIsNiArNDk1LDcgQEAgMTogICAgICBtb3ZxICAl
cnNwLCVyZGkKICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAg
ICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAg
IGp6ICAgIHRlc3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxs
ICBjcmVhdGVfYm91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3Mo
JXJkeCkKICAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--dbC35hETsu
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.0.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.0.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciBkOGZkNDI1YjYwZDMgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTg6NDcgMjAxMiArMDEwMApAQCAtODksNiArODksOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgZDhmZDQyNWI2MGQzIHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjE4OjQ3IDIwMTIgKzAxMDAKQEAgLTIyNyw2ICsyMjcsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjQzLDE0ICsyNDQsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IGQ4ZmQ0MjViNjBkMyB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBNYXkgMDEgMTQ6MTg6NDYgMjAxMiArMDEwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMToxODo0NyAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk4LDEyICszMDksMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ5MCw2ICs1MDMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--dbC35hETsu
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-3.4.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-3.4.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA1MWJkMWYxNzI3NTggeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTI6NDE6MDggMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgNTFiZDFmMTcyNzU4IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDEyOjQxOjA4IDIwMTIgKzAxMDAKQEAgLTIxNSw2ICsyMTUsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjMxLDE0ICsyMzIsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IDUxYmQxZjE3Mjc1OCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCUZyaSBTZXAgMzAgMTc6MzU6MjkgMjAxMSAtMDQwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMjo0MTowOCAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk2LDEyICszMDcsMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ4MCw2ICs0OTMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--dbC35hETsu
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--dbC35hETsu--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:04:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePoj-0002eU-RR; Tue, 12 Jun 2012 12:03:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SePoi-0002dk-8J
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:03:24 +0000
Received: from [85.158.143.99:64771] by server-1.bemta-4.messagelabs.com id
	3E/91-24392-A0037DF4; Tue, 12 Jun 2012 12:03:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339502601!30118335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13741 invoked from network); 12 Jun 2012 12:03:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:03:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:03:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePod-0006Qb-2T; Tue, 12 Jun 2012 12:03:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePod-0005U2-1b;
	Tue, 12 Jun 2012 13:03:19 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="dbC35hETsu"
Content-Transfer-Encoding: 7bit
Message-ID: <20439.12295.26429.618451@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:03:19 +0100
From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, oss-security@lists.openwall.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen Security Advisory 8 (CVE-2012-0218) - syscall/enter
	guest DoS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--dbC35hETsu
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

               Xen Security Advisory CVE-2012-0218 / XSA-8
                              version 7

     guest denial of service on syscall/sysenter exception generation

UPDATES IN VERSION 7
====================

Public release.  Previous versions were embargoed.

ISSUE DESCRIPTION
=================

When guest user code running inside a Xen guest operating system
attempts to execute a syscall or sysenter instruction, but when the
guest operating system has not registered a handler for that
instruction, a General Protection Fault may need to be injected into
the guest.

It has been discovered that the code in Xen which does this fails to
clear a flag requesting exception injection, with the result that a
future exception taken by the guest and handled entirely inside Xen
will also be injected into the guest despite Xen having handled it
already, probably crashing the guest.

IMPACT
======

User space processes on some guest operating systems may be able to
crash the guest.

VULNERABLE SYSTEMS
==================

HVM guests are not vulnerable.

32- and 64-bit PV guests may be vulnerable, depending on the CPU
hardware, the guest operating system, and its exact kernel version and
configuration.

MITIGATION
==========

This issue can be mitigated by running HVM (fully-virtualised).

In some cases this issue can be mitigated by upgrading the guest
kernel to one which installs hooks for sysenter and/or syscall, as
applicable.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

These patches also resolve the (more serious) issue described in
XSA-7 (CVE-2012-0217).

These changes have been made to the staging Xen repositories:
                    XSA-7:              XSA-8:
 xen-unstable.hg     25480:76eaf5966c05  25200:80f4113be500+25204:569d6f05e1ef
 xen-4.1-testing.hg  23299:f08e61b9b33f  23300:0fec1afa4638
 xen-4.0-testing.hg  21590:dd367837e089  21591:adb943a387c8
 xen-3.4-testing.hg  19996:894aa06e4f79  19997:ddb7578abb89

PATCH INFORMATION
=================

The attached patches resolve both this issue and that reported in
XSA-7 (CVE-2012-0217).

 xen-unstable 25204:569d6f05e1ef or later    xsa7-xsa8-unstable-recent.patch  
 xen-unstable 25199:6092641e3644 or earlier  xsa7-xsa8-unstable-apr16.patch
 Xen 4.1, 4.1.x                              xsa7-xsa8-xen-4.1.patch
 Xen 4.0, 4.0.x                              xsa7-xsa8-xen-4.0.patch
 Xen 3.4, 3.4.x                              xsa7-xsa8-xen-3.4.patch

$ sha256sum xsa7-xsa8-*patch
00853d799d24af16b17c8bbbdb5bb5144a8a7fad31467c4be3d879244774f8d2  xsa7-xsa8-unstable-apr16.patch
71f9907a58c1a1cd601d8088faf8791923d78f77065b94dba8df2a61f512530d  xsa7-xsa8-unstable-recent.patch
55fb925a7f4519ea31a0bc42d3ee83093bb7abd98b3a0e4f58591f1ae738840a  xsa7-xsa8-xen-3.4.patch
6a7e39121ec1f134351fdf34f494d108500aaa4190a9f7965e81c4e96270924e  xsa7-xsa8-xen-4.0.patch
52d8288718b4a833eb437fd18d92b7d412fbe01900dbd0b437744a1df4d459da  xsa7-xsa8-xen-4.1.patch

NOTE REGARDING EMBARGO
======================

The fix for this issue has already been published as xen-unstable.hg
changesets 25200:80f4113be500 and 25204:569d6f05e1ef.  However, this
has not been flagged as a security problem, and since the affected
area of code is the same as that for XSA-7 (CVE-2012-0217), we have
concluded that this advisory should be under the same embargo as
XSA-7.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP1yqMAAoJEIP+FMlX6CvZQRoH/1Do71YkaMvKoPo/VCHqUuB1
5mJve/SiTK5Y5kggnLfnpZeuLjlntHCT5F//Do7N21WDVdwZXFBItlvjhKyNGA0Y
ohqzqzAQ0c2l/mE3ToaLhhtuFb8U06q8Ud+pQ9QbMHHpJvGXPzDbNG12L/fZDwyf
ZbMqB2j8+TVuRXPlbdZabNUAcZ+HOJHb1NloKCbX0qwMG4p5FJ3OdkDX7r5OjPKj
sIJAaltBINGjRrqYMLB4UUQdrftu1ftfU/GFVYy8+t3uNj0fBgkCPUlGbbQs2SF2
+VtLUUG6rzVlRdHyhVMswz3sZtR7Tow6xwPk3Sr4yfrI15rH2pUJI7if8vZ1ZQ8=
=elZi
-----END PGP SIGNATURE-----


--dbC35hETsu
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-recent.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-recent.patch"
Content-Transfer-Encoding: base64

eDg2XzY0OiBEbyBub3QgZXhlY3V0ZSBzeXNyZXQgd2l0aCBhIG5vbi1jYW5vbmljYWwgcmV0dXJu
IGFkZHJlc3MKCkNoZWNrIGZvciBub24tY2Fub25pY2FsIGd1ZXN0IFJJUCBiZWZvcmUgYXR0ZW1w
dGluZyB0byBleGVjdXRlIHN5c3JldC4KSWYgc3lzcmV0IGlzIGV4ZWN1dGVkIHdpdGggYSBub24t
Y2Fub25pY2FsIHZhbHVlIGluIFJDWCwgSW50ZWwgQ1BVcwp0YWtlIHRoZSBmYXVsdCBpbiByaW5n
MCwgYnV0IHdlIHdpbGwgbmVjZXNzYXJpbHkgYWxyZWFkeSBoYXZlIHN3aXRjaGVkCnRvIHRoZSB0
aGUgdXNlcidzIHN0YWNrIHBvaW50ZXIuCgpUaGlzIGlzIGEgc2VjdXJpdHkgdnVsbmVyYWJpbGl0
eSwgWFNBLTcgLyBDVkUtMjAxMi0wMjE3LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPEpC
ZXVsaWNoQHN1c2UuY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUu
Y2l0cml4LmNvbT4KVGVzdGVkLWJ5OiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXgu
Y29tPgpBY2tlZC1ieTogS2VpciBGcmFzZXIgPGtlaXIueGVuQGdtYWlsLmNvbT4KQ29tbWl0dGVk
LWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLXIgMzQw
MDYyZmFmMjk4IC1yIGFkODc5MDNmZGNhMSB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCVdlZCBNYXkgMjMgMTE6MDY6NDkgMjAxMiAr
MDEwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowMjoz
NSAyMDEyICswMTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAg
ICAgdGVzdHcgJFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90
b19ndWVzdAogCisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJu
IGFkZHJlc3MgaXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4
CisgICAgICAgIHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21w
bCAgJDEsJWVjeAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAk
OCwlcnNwCiAgICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAg
ICAgIHBvcHEgICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBA
IHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAor
Lkxmb3JjZV9pcmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAg
ICAgIG1vdnEgIDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0
KCVyc3ApLCVyMTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVj
aWFsIHJlZ2lzdGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0Ogo=
--dbC35hETsu
Content-Type: application/octet-stream;
	name="xsa7-xsa8-unstable-apr16.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-unstable-apr16.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgQXByIDE3IDE1OjA1OjA1
IDIwMTIgKzAyMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMTQ1LDYgKzE0NSw3IEBAIHZvaWQgX19kdW1t
eV9fKHZvaWQpCiAKICAgICBPRkZTRVQoVFJBUElORk9fZWlwLCBzdHJ1Y3QgdHJhcF9pbmZvLCBh
ZGRyZXNzKTsKICAgICBPRkZTRVQoVFJBUElORk9fY3MsIHN0cnVjdCB0cmFwX2luZm8sIGNzKTsK
KyAgICBPRkZTRVQoVFJBUElORk9fZmxhZ3MsIHN0cnVjdCB0cmFwX2luZm8sIGZsYWdzKTsKICAg
ICBERUZJTkUoVFJBUElORk9fc2l6ZW9mLCBzaXplb2Yoc3RydWN0IHRyYXBfaW5mbykpOwogICAg
IEJMQU5LKCk7CiAKZGlmZiAtciA2MDkyNjQxZTM2NDQgeGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwotLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCVR1ZSBB
cHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBh
dC9lbnRyeS5TCVRodSBNYXkgMjQgMTE6MDU6MTkgMjAxMiArMDEwMApAQCAtMjEzLDYgKzIxMyw3
IEBAIDE6ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKIEVOVFJZKGNvbXBh
dF9wb3N0X2hhbmRsZV9leGNlcHRpb24pCiAgICAgICAgIHRlc3RiICRUQkZfRVhDRVBUSU9OLFRS
QVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50
cworLkxjb21wYXRfYm91bmNlX2V4Y2VwdGlvbjoKICAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0
ZV9ib3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCkBAIC0yMjUsMjAgKzIyNiwyMSBA
QCBFTlRSWShjb21wYXRfc3lzY2FsbCkKICAgICAgICAgbGVhcSAgVkNQVV90cmFwX2JvdW5jZSgl
cmJ4KSwlcmR4CiAgICAgICAgIHRlc3RsICR+MywlZXNpCiAgICAgICAgIGxlYWwgICgsJXJjeCxU
QkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEgICVyYXgs
VFJBUEJPVU5DRV9laXAoJXJkeCkKK1VOTElLRUxZX1NUQVJUKHosIGNvbXBhdF9zeXNjYWxsX2dw
ZikKKyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJkaQorICAgICAgICBtb3Zs
ICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VibCAg
JDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29k
ZSglcmR4KQorICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsg
VFJBUElORk9fZWlwKCVyZGkpLCVlYXgKKyAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBU
UkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcmRpKSwlZXNpCisgICAgICAgIHRlc3RiICQ0
LFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBUUkFQSU5GT19mbGFncyglcmRpKQor
ICAgICAgICBzZXRueiAlY2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREUoLCVyY3gsVEJGX0lOVEVSUlVQVCksJWVjeAorVU5MSUtFTFlfRU5EKGNvbXBh
dF9zeXNjYWxsX2dwZikKKyAgICAgICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQog
ICAgICAgICBtb3Z3ICAlc2ksVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3ZiICAlY2ws
VFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICBjYWxsICBjb21wYXRfY3JlYXRlX2JvdW5j
ZV9mcmFtZQotICAgICAgICBqbXAgICBjb21wYXRfdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dnEgIFZDUFVfdHJhcF9jdHh0KCVyYngpLCVyc2kKLSAgICAgICAgbW92bCAgJFRSQVBfZ3BfZmF1
bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3ApCi0gICAgICAgIHN1YmwgICQyLFVSRUdTX3JpcCgl
cnNwKQotICAgICAgICBtb3ZsICBUUkFQX2dwX2ZhdWx0ICogVFJBUElORk9fc2l6ZW9mICsgVFJB
UElORk9fZWlwKCVyc2kpLCVlYXgKLSAgICAgICAgbW92endsIFRSQVBfZ3BfZmF1bHQgKiBUUkFQ
SU5GT19zaXplb2YgKyBUUkFQSU5GT19jcyglcnNpKSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJG
X0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAg
ICAgIG1vdmwgICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAx
YgorICAgICAgICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBh
dF9zeXNlbnRlcikKICAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJjeApkaWZm
IC1yIDYwOTI2NDFlMzY0NCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2Fy
Y2gveDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBBcHIgMTcgMTU6MDU6MDUgMjAxMiArMDIwMAorKysg
Yi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMTowNToxOSAyMDEyICsw
MTAwCkBAIC00MCw2ICs0MCwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcg
JFRSQVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAog
CisgICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3Mg
aXMgbm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAg
IHNhcnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVj
eAorICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAg
ICAgICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEg
ICVyMTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTUwLDYgKzU3LDEwIEBAIHJlc3RvcmVf
YWxsX2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9p
cmV0OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEg
IDgoJXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVy
MTEgICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lz
dGVyIGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjc3LDIwICsyODgs
MjIgQEAgc3lzZW50ZXJfZWZsYWdzX3NhdmVkOgogICAgICAgICBsZWFxICBWQ1BVX3RyYXBfYm91
bmNlKCVyYngpLCVyZHgKICAgICAgICAgdGVzdHEgJXJheCwlcmF4CiAgICAgICAgIGxlYWwgICgs
JXJjeCxUQkZfSU5URVJSVVBUKSwlZWN4Ci0gICAgICAgIGp6ICAgIDJmCi0xOiAgICAgIG1vdnEg
IFZDUFVfZG9tYWluKCVyYngpLCVyZGkKK1VOTElLRUxZX1NUQVJUKHosIHN5c2VudGVyX2dwZikK
KyAgICAgICAgbW92cSAgVkNQVV90cmFwX2N0eHQoJXJieCksJXJzaQorICAgICAgICBtb3ZsICAk
VFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJzcCkKKyAgICAgICAgc3VicSAgJDIs
VVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2Rl
KCVyZHgpCisgICAgICAgIG1vdnEgIFRSQVBfZ3BfZmF1bHQgKiBUUkFQSU5GT19zaXplb2YgKyBU
UkFQSU5GT19laXAoJXJzaSksJXJheAorICAgICAgICB0ZXN0YiAkNCxUUkFQX2dwX2ZhdWx0ICog
VFJBUElORk9fc2l6ZW9mICsgVFJBUElORk9fZmxhZ3MoJXJzaSkKKyAgICAgICAgc2V0bnogJWNs
CisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4
LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChzeXNlbnRlcl9ncGYpCisgICAgICAg
IG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAgICAgbW92cSAgJXJheCxUUkFQQk9V
TkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJBUEJPVU5DRV9mbGFncyglcmR4KQog
ICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYoJXJkaSkKICAgICAgICAgam56ICAg
Y29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAg
ICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1vdnEgIFZDUFVfdHJhcF9jdHh0KCVy
YngpLCVyY3gKLSAgICAgICAgbW92bCAgJWVheCxUUkFQQk9VTkNFX2Vycm9yX2NvZGUoJXJkeCkK
LSAgICAgICAgbW92cSAgVFJBUF9ncF9mYXVsdCAqIFRSQVBJTkZPX3NpemVvZiArIFRSQVBJTkZP
X2VpcCglcmN4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBU
SU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRUUkFQX2dwX2Zh
dWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgorICAgICAgICBq
bXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3RyYXApCiAgICAg
ICAgIHB1c2hxICQwCkBAIC00ODMsNiArNDk2LDcgQEAgMTogICAgICBtb3ZxICAlcnNwLCVyZGkK
ICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAgICAgICB0ZXN0
YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIGp6ICAgIHRl
c3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxsICBjcmVhdGVf
Ym91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAg
ICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--dbC35hETsu
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.1.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciAzNTI0OGJlNjY5ZTcgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTI6MzMgMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlNb24gTWF5IDE0IDE2OjU5OjEy
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjEyOjMzIDIwMTIgKzAxMDAKQEAgLTIxNCw2ICsyMTQsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjI2LDE5ICsyMjcsMjAgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAgICAgICAgIGxlYXEgIFZDUFVfdHJhcF9ib3VuY2UoJXJieCksJXJkeAogICAg
ICAgICB0ZXN0bCAkfjMsJWVzaQogICAgICAgICBsZWFsICAoLCVyY3gsVEJGX0lOVEVSUlVQVCks
JWVjeAotICAgICAgICBqeiAgICAyZgotMTogICAgICBtb3ZxICAlcmF4LFRSQVBCT1VOQ0VfZWlw
KCVyZHgpCitVTkxJS0VMWV9TVEFSVCh6LCBjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJs
ICAkMixVUkVHU19yaXAoJXJzcCkKKyAgICAgICAgbW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9j
b2RlKCVyZHgpCisgICAgICAgIG1vdmwgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlZWF4Cisg
ICAgICAgIG1vdnp3bCBWQ1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCisgICAgICAgIHRlc3Ri
ICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAg
IGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRF
UlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChjb21wYXRfc3lzY2FsbF9ncGYpCisgICAgICAgIG1v
dnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAgICAgbW92dyAgJXNpLFRSQVBCT1VO
Q0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKLSAg
ICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgY29t
cGF0X3Rlc3RfYWxsX2V2ZW50cwotMjogICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19l
bnRyeV92ZWN0b3IoJXJzcCkKLSAgICAgICAgc3VibCAgJDIsVVJFR1NfcmlwKCVyc3ApCi0gICAg
ICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdnp3bCBW
Q1BVX2dwX2ZhdWx0X3NlbCglcmJ4KSwlZXNpCi0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElP
TnxUQkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwg
ICQwLFRSQVBCT1VOQ0VfZXJyb3JfY29kZSglcmR4KQotICAgICAgICBqbXAgICAxYgorICAgICAg
ICBqbXAgICAuTGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAKIEVOVFJZKGNvbXBhdF9zeXNlbnRl
cikKICAgICAgICAgY21wbCAgJFRSQVBfZ3BfZmF1bHQsVVJFR1NfZW50cnlfdmVjdG9yKCVyc3Ap
CmRpZmYgLXIgMzUyNDhiZTY2OWU3IHhlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwotLS0gYS94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJTW9uIE1heSAxNCAxNjo1OToxMiAyMDEyICswMTAw
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwlUaHUgTWF5IDI0IDExOjEyOjMzIDIw
MTIgKzAxMDAKQEAgLTQwLDYgKzQwLDEzIEBAIHJlc3RvcmVfYWxsX2d1ZXN0OgogICAgICAgICB0
ZXN0dyAkVFJBUF9zeXNjYWxsLDQoJXJzcCkKICAgICAgICAganogICAgaXJldF9leGl0X3RvX2d1
ZXN0CiAKKyAgICAgICAgLyogRG9uJ3QgdXNlIFNZU1JFVCBwYXRoIGlmIHRoZSByZXR1cm4gYWRk
cmVzcyBpcyBub3QgY2Fub25pY2FsLiAqLworICAgICAgICBtb3ZxICA4KCVyc3ApLCVyY3gKKyAg
ICAgICAgc2FycSAgJDQ3LCVyY3gKKyAgICAgICAgaW5jbCAgJWVjeAorICAgICAgICBjbXBsICAk
MSwlZWN4CisgICAgICAgIGphICAgIC5MZm9yY2VfaXJldAorCiAgICAgICAgIGFkZHEgICQ4LCVy
c3AKICAgICAgICAgcG9wcSAgJXJjeCAgICAgICAgICAgICAgICAgICAgIyBSSVAKICAgICAgICAg
cG9wcSAgJXIxMSAgICAgICAgICAgICAgICAgICAgIyBDUwpAQCAtNTAsNiArNTcsMTAgQEAgcmVz
dG9yZV9hbGxfZ3Vlc3Q6CiAgICAgICAgIHN5c3JldHEKIDE6ICAgICAgc3lzcmV0bAogCisuTGZv
cmNlX2lyZXQ6CisgICAgICAgIC8qIE1pbWljIFNZU1JFVCBiZWhhdmlvci4gKi8KKyAgICAgICAg
bW92cSAgOCglcnNwKSwlcmN4ICAgICAgICAgICAgIyBSSVAKKyAgICAgICAgbW92cSAgMjQoJXJz
cCksJXIxMSAgICAgICAgICAgIyBSRkxBR1MKICAgICAgICAgQUxJR04KIC8qIE5vIHNwZWNpYWwg
cmVnaXN0ZXIgYXNzdW1wdGlvbnMuICovCiBpcmV0X2V4aXRfdG9fZ3Vlc3Q6CkBAIC0yNzgsMTkg
KzI4OSwyMSBAQCBzeXNlbnRlcl9lZmxhZ3Nfc2F2ZWQ6CiAgICAgICAgIGxlYXEgIFZDUFVfdHJh
cF9ib3VuY2UoJXJieCksJXJkeAogICAgICAgICB0ZXN0cSAlcmF4LCVyYXgKICAgICAgICAgbGVh
bCAgKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKLSAgICAgICAganogICAgMmYKLTE6ICAgICAg
bW92cSAgVkNQVV9kb21haW4oJXJieCksJXJkaQorVU5MSUtFTFlfU1RBUlQoeiwgc3lzZW50ZXJf
Z3BmKQorICAgICAgICBtb3ZsICAkVFJBUF9ncF9mYXVsdCxVUkVHU19lbnRyeV92ZWN0b3IoJXJz
cCkKKyAgICAgICAgc3VicSAgJDIsVVJFR1NfcmlwKCVyc3ApCisgICAgICAgIG1vdmwgICVlYXgs
VFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRf
YWRkciglcmJ4KSwlcmF4CisgICAgICAgIHRlc3RiICQ0LFZDUFVfZ3BfZmF1bHRfZmxhZ3MoJXJi
eCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwgIFRCRl9FWENFUFRJT058VEJGX0VY
Q0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQpLCVlY3gKK1VOTElLRUxZX0VORChz
eXNlbnRlcl9ncGYpCisgICAgICAgIG1vdnEgIFZDUFVfZG9tYWluKCVyYngpLCVyZGkKICAgICAg
ICAgbW92cSAgJXJheCxUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAgICBtb3ZiICAlY2wsVFJB
UEJPVU5DRV9mbGFncyglcmR4KQogICAgICAgICB0ZXN0YiAkMSxET01BSU5faXNfMzJiaXRfcHYo
JXJkaSkKICAgICAgICAgam56ICAgY29tcGF0X3N5c2VudGVyCi0gICAgICAgIGNhbGwgIGNyZWF0
ZV9ib3VuY2VfZnJhbWUKLSAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCi0yOiAgICAgIG1v
dmwgICVlYXgsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCi0gICAgICAgIG1vdnEgIFZDUFVf
Z3BfZmF1bHRfYWRkciglcmJ4KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxU
QkZfRVhDRVBUSU9OX0VSUkNPREV8VEJGX0lOVEVSUlVQVCksJWNsCi0gICAgICAgIG1vdmwgICRU
UkFQX2dwX2ZhdWx0LFVSRUdTX2VudHJ5X3ZlY3RvciglcnNwKQotICAgICAgICBqbXAgICAxYgor
ICAgICAgICBqbXAgICAuTGJvdW5jZV9leGNlcHRpb24KIAogRU5UUlkoaW50ODBfZGlyZWN0X3Ry
YXApCiAgICAgICAgIHB1c2hxICQwCkBAIC00ODIsNiArNDk1LDcgQEAgMTogICAgICBtb3ZxICAl
cnNwLCVyZGkKICAgICAgICAgam56ICAgY29tcGF0X3Bvc3RfaGFuZGxlX2V4Y2VwdGlvbgogICAg
ICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAg
IGp6ICAgIHRlc3RfYWxsX2V2ZW50cworLkxib3VuY2VfZXhjZXB0aW9uOgogICAgICAgICBjYWxs
ICBjcmVhdGVfYm91bmNlX2ZyYW1lCiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3Mo
JXJkeCkKICAgICAgICAgam1wICAgdGVzdF9hbGxfZXZlbnRzCg==
--dbC35hETsu
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-4.0.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-4.0.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciBkOGZkNDI1YjYwZDMgeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTE6MTg6NDcgMjAxMiArMDEwMApAQCAtODksNiArODksOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgZDhmZDQyNWI2MGQzIHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUdWUgTWF5IDAxIDE0OjE4OjQ2
IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDExOjE4OjQ3IDIwMTIgKzAxMDAKQEAgLTIyNyw2ICsyMjcsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjQzLDE0ICsyNDQsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IGQ4ZmQ0MjViNjBkMyB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCVR1ZSBNYXkgMDEgMTQ6MTg6NDYgMjAxMiArMDEwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMToxODo0NyAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk4LDEyICszMDksMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ5MCw2ICs1MDMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--dbC35hETsu
Content-Type: application/octet-stream; name="xsa7-xsa8-xen-3.4.patch"
Content-Disposition: attachment; filename="xsa7-xsa8-xen-3.4.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtciA1MWJkMWYxNzI3NTggeGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvYXNtLW9mZnNldHMuYwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9hc20tb2Zmc2V0cy5jCVRodSBN
YXkgMjQgMTI6NDE6MDggMjAxMiArMDEwMApAQCAtOTAsNiArOTAsOCBAQCB2b2lkIF9fZHVtbXlf
Xyh2b2lkKQogICAgICAgICAgICBhcmNoLmd1ZXN0X2NvbnRleHQudHJhcF9jdHh0W1RSQVBfZ3Bf
ZmF1bHRdLmFkZHJlc3MpOwogICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X3NlbCwgc3RydWN0IHZj
cHUsCiAgICAgICAgICAgIGFyY2guZ3Vlc3RfY29udGV4dC50cmFwX2N0eHRbVFJBUF9ncF9mYXVs
dF0uY3MpOworICAgIE9GRlNFVChWQ1BVX2dwX2ZhdWx0X2ZsYWdzLCBzdHJ1Y3QgdmNwdSwKKyAg
ICAgICAgICAgYXJjaC5ndWVzdF9jb250ZXh0LnRyYXBfY3R4dFtUUkFQX2dwX2ZhdWx0XS5mbGFn
cyk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NwLCBzdHJ1Y3QgdmNwdSwgYXJjaC5ndWVzdF9j
b250ZXh0Lmtlcm5lbF9zcCk7CiAgICAgT0ZGU0VUKFZDUFVfa2VybmVsX3NzLCBzdHJ1Y3QgdmNw
dSwgYXJjaC5ndWVzdF9jb250ZXh0Lmtlcm5lbF9zcyk7CiAgICAgT0ZGU0VUKFZDUFVfZ3Vlc3Rf
Y29udGV4dF9mbGFncywgc3RydWN0IHZjcHUsIGFyY2guZ3Vlc3RfY29udGV4dC5mbGFncyk7CmRp
ZmYgLXIgNTFiZDFmMTcyNzU4IHhlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKLS0t
IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlGcmkgU2VwIDMwIDE3OjM1OjI5
IDIwMTEgLTA0MDAKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwlUaHUg
TWF5IDI0IDEyOjQxOjA4IDIwMTIgKzAxMDAKQEAgLTIxNSw2ICsyMTUsNyBAQCAxOiAgICAgIGNh
bGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1lCiBFTlRSWShjb21wYXRfcG9zdF9oYW5kbGVf
ZXhjZXB0aW9uKQogICAgICAgICB0ZXN0YiAkVEJGX0VYQ0VQVElPTixUUkFQQk9VTkNFX2ZsYWdz
KCVyZHgpCiAgICAgICAgIGp6ICAgIGNvbXBhdF90ZXN0X2FsbF9ldmVudHMKKy5MY29tcGF0X2Jv
dW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNvbXBhdF9jcmVhdGVfYm91bmNlX2ZyYW1l
CiAgICAgICAgIG1vdmIgICQwLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAgam1wICAg
Y29tcGF0X3Rlc3RfYWxsX2V2ZW50cwpAQCAtMjMxLDE0ICsyMzIsMTUgQEAgRU5UUlkoY29tcGF0
X3N5c2NhbGwpCiAxOiAgICAgIG1vdnEgICVyYXgsVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92dyAgJXNpLFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92YiAgJWNsLFRSQVBC
T1VOQ0VfZmxhZ3MoJXJkeCkKLSAgICAgICAgY2FsbCAgY29tcGF0X2NyZWF0ZV9ib3VuY2VfZnJh
bWUKLSAgICAgICAgam1wICAgY29tcGF0X3Rlc3RfYWxsX2V2ZW50cworICAgICAgICBqbXAgICAu
TGNvbXBhdF9ib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVS
RUdTX2VudHJ5X3ZlY3RvciglcnNwKQogICAgICAgICBzdWJsICAkMixVUkVHU19yaXAoJXJzcCkK
ICAgICAgICAgbW92cSAgVkNQVV9ncF9mYXVsdF9hZGRyKCVyYngpLCVyYXgKICAgICAgICAgbW92
endsIFZDUFVfZ3BfZmF1bHRfc2VsKCVyYngpLCVlc2kKLSAgICAgICAgbW92YiAgJChUQkZfRVhD
RVBUSU9OfFRCRl9FWENFUFRJT05fRVJSQ09ERXxUQkZfSU5URVJSVVBUKSwlY2wKICAgICAgICAg
bW92bCAgJDAsVFJBUEJPVU5DRV9lcnJvcl9jb2RlKCVyZHgpCisgICAgICAgIHRlc3RiICQ0LFZD
UFVfZ3BfZmF1bHRfZmxhZ3MoJXJieCkKKyAgICAgICAgc2V0bnogJWNsCisgICAgICAgIGxlYWwg
IFRCRl9FWENFUFRJT058VEJGX0VYQ0VQVElPTl9FUlJDT0RFKCwlcmN4LFRCRl9JTlRFUlJVUFQp
LCVlY3gKICAgICAgICAgam1wICAgMWIKIAogRU5UUlkoY29tcGF0X3N5c2VudGVyKQpkaWZmIC1y
IDUxYmQxZjE3Mjc1OCB4ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKLS0tIGEveGVuL2FyY2gv
eDg2L3g4Nl82NC9lbnRyeS5TCUZyaSBTZXAgMzAgMTc6MzU6MjkgMjAxMSAtMDQwMAorKysgYi94
ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMJVGh1IE1heSAyNCAxMjo0MTowOCAyMDEyICswMTAw
CkBAIC01MSw2ICs1MSwxMyBAQCByZXN0b3JlX2FsbF9ndWVzdDoKICAgICAgICAgdGVzdHcgJFRS
QVBfc3lzY2FsbCw0KCVyc3ApCiAgICAgICAgIGp6ICAgIGlyZXRfZXhpdF90b19ndWVzdAogCisg
ICAgICAgIC8qIERvbid0IHVzZSBTWVNSRVQgcGF0aCBpZiB0aGUgcmV0dXJuIGFkZHJlc3MgaXMg
bm90IGNhbm9uaWNhbC4gKi8KKyAgICAgICAgbW92cSAgOCglcnNwKSwlcmN4CisgICAgICAgIHNh
cnEgICQ0NywlcmN4CisgICAgICAgIGluY2wgICVlY3gKKyAgICAgICAgY21wbCAgJDEsJWVjeAor
ICAgICAgICBqYSAgICAuTGZvcmNlX2lyZXQKKwogICAgICAgICBhZGRxICAkOCwlcnNwCiAgICAg
ICAgIHBvcHEgICVyY3ggICAgICAgICAgICAgICAgICAgICMgUklQCiAgICAgICAgIHBvcHEgICVy
MTEgICAgICAgICAgICAgICAgICAgICMgQ1MKQEAgLTYxLDYgKzY4LDEwIEBAIHJlc3RvcmVfYWxs
X2d1ZXN0OgogICAgICAgICBzeXNyZXRxCiAxOiAgICAgIHN5c3JldGwKIAorLkxmb3JjZV9pcmV0
OgorICAgICAgICAvKiBNaW1pYyBTWVNSRVQgYmVoYXZpb3IuICovCisgICAgICAgIG1vdnEgIDgo
JXJzcCksJXJjeCAgICAgICAgICAgICMgUklQCisgICAgICAgIG1vdnEgIDI0KCVyc3ApLCVyMTEg
ICAgICAgICAgICMgUkZMQUdTCiAgICAgICAgIEFMSUdOCiAvKiBObyBzcGVjaWFsIHJlZ2lzdGVy
IGFzc3VtcHRpb25zLiAqLwogaXJldF9leGl0X3RvX2d1ZXN0OgpAQCAtMjk2LDEyICszMDcsMTQg
QEAgMTogICAgICBtb3ZxICBWQ1BVX2RvbWFpbiglcmJ4KSwlcmRpCiAgICAgICAgIG1vdmIgICVj
bCxUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCiAgICAgICAgIHRlc3RiICQxLERPTUFJTl9pc18zMmJp
dF9wdiglcmRpKQogICAgICAgICBqbnogICBjb21wYXRfc3lzZW50ZXIKLSAgICAgICAgY2FsbCAg
Y3JlYXRlX2JvdW5jZV9mcmFtZQotICAgICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMKKyAgICAg
ICAgam1wICAgLkxib3VuY2VfZXhjZXB0aW9uCiAyOiAgICAgIG1vdmwgICVlYXgsVFJBUEJPVU5D
RV9lcnJvcl9jb2RlKCVyZHgpCiAgICAgICAgIG1vdnEgIFZDUFVfZ3BfZmF1bHRfYWRkciglcmJ4
KSwlcmF4Ci0gICAgICAgIG1vdmIgICQoVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNP
REV8VEJGX0lOVEVSUlVQVCksJWNsCiAgICAgICAgIG1vdmwgICRUUkFQX2dwX2ZhdWx0LFVSRUdT
X2VudHJ5X3ZlY3RvciglcnNwKQorICAgICAgICBzdWJxICAkMixVUkVHU19yaXAoJXJzcCkKKyAg
ICAgICAgdGVzdGIgJDQsVkNQVV9ncF9mYXVsdF9mbGFncyglcmJ4KQorICAgICAgICBzZXRueiAl
Y2wKKyAgICAgICAgbGVhbCAgVEJGX0VYQ0VQVElPTnxUQkZfRVhDRVBUSU9OX0VSUkNPREUoLCVy
Y3gsVEJGX0lOVEVSUlVQVCksJWVjeAogICAgICAgICBqbXAgICAxYgogCiBFTlRSWShpbnQ4MF9k
aXJlY3RfdHJhcCkKQEAgLTQ4MCw2ICs0OTMsNyBAQCAxOiAgICAgIG1vdnEgICVyc3AsJXJkaQog
ICAgICAgICBqbnogICBjb21wYXRfcG9zdF9oYW5kbGVfZXhjZXB0aW9uCiAgICAgICAgIHRlc3Ri
ICRUQkZfRVhDRVBUSU9OLFRSQVBCT1VOQ0VfZmxhZ3MoJXJkeCkKICAgICAgICAganogICAgdGVz
dF9hbGxfZXZlbnRzCisuTGJvdW5jZV9leGNlcHRpb246CiAgICAgICAgIGNhbGwgIGNyZWF0ZV9i
b3VuY2VfZnJhbWUKICAgICAgICAgbW92YiAgJDAsVFJBUEJPVU5DRV9mbGFncyglcmR4KQogICAg
ICAgICBqbXAgICB0ZXN0X2FsbF9ldmVudHMK
--dbC35hETsu
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--dbC35hETsu--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:04:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePp6-0002mD-Ei; Tue, 12 Jun 2012 12: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.Jackson@eu.citrix.com>) id 1SePp4-0002lL-VC
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:03:47 +0000
Received: from [85.158.139.83:61187] by server-8.bemta-5.messagelabs.com id
	72/E2-02058-12037DF4; Tue, 12 Jun 2012 12:03:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339502624!33231507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1983 invoked from network); 12 Jun 2012 12:03:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:03:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:03:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:03:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePp1-0006Qk-Kq; Tue, 12 Jun 2012 12:03:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePp1-0005UW-Ig;
	Tue, 12 Jun 2012 13:03:43 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="GkZFEJHiah"
Content-Transfer-Encoding: 7bit
Message-ID: <20439.12319.545744.59925@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:03:43 +0100
From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, oss-security@lists.openwall.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen Security Advisory 9 (CVE-2012-2934) - PV guest host
	DoS (AMD erratum #121)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--GkZFEJHiah
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2012-2934 / XSA-9
                            version 3

		   PV guest host Denial of Service

UPDATES IN VERSION 3
====================

Public release.  Previous versions were embargoed.

Remove leftover statement that CVE number had not been assigned.
The correct CVE for this issue is CVE-2012-2934.

ISSUE DESCRIPTION
=================

A Xen user has discovered that some older AMD CPUs can be made to lock
up due to AMD processor erratum #121.

This issue was discovered during testing of the fix for XSA-7
(CVE-2012-0217). Although the two issues are unrelated the situations
which can trigger them may overlap.

REFERENCES
==========

AMD Erratum #121 is described in "Revision Guide for AMD Athlon 64 and AMD
Opteron Processors": http://support.amd.com/us/Processor_TechDocs/25759.pdf

IMPACT
======

A guest user or administrator of a 64 bit PV guest on a vulnerable
system can cause the processor to lock up, leading to a Denial of
Service attack against the host.

Systems which run only 32 bit guest kernels are not vulnerable.

VULNERABLE SYSTEMS
==================

The following 130nm and 90nm (DDR1-only) AMD processors are subject
to this erratum:

 * First-generation AMD-Opteron(tm) single and dual core processors
   in either 939 or 940 packages:
   * AMD Opteron(tm) 100-Series Processors
   * AMD Opteron(tm) 200-Series Processors
   * AMD Opteron(tm) 800-Series Processors
 * AMD Athlon(tm) processors in either 754, 939 or 940 packages
 * AMD Sempron(tm) processor in either 754 or 939 packages
 * AMD Turion(tm) Mobile Technology in 754 package

None of the affected processors support AMD SVM.  Therefore, any
system which has any HVM Xen guests is not vulnerable.

This issue does not affect Intel processors.

MITIGATION
==========

Running a 64 bit PV guest kernel (which must necessarily be host
administrator controlled) which itself contains the fix for erratum
#121 will prevent unprivileged users in guests from exploiting this
issue.  All Windows operating systems and current versions of the
Linux and Solaris kernels, for example, are known to contain the fix
for erratum #121.

There is no mitigation when running untrusted 64 bit guest kernels or
against untrusted administrators of 64 bit guests.

Systems which run only 32 bit PV guest kernels are not
vulnerable. Note that this may mean only booting known good kernels or
vetting any user supplied kernels to ensure they are not 64 bit.

RESOLUTION
==========

There is no software fix for this issue. The workaround suggested by
AMD in erratum #121 cannot be applied to Xen since the relevant address
is under guest control.

Applying the patch will cause Xen to detect vulnerable systems and
refuse to boot. A command line override is provided to allow users who
accept the risks or who are able to mitigate as above to continue to
do so. To activate the override add "allow_unsafe" to your hypervisor
command line.

This change has been made to the staging Xen repositories:
  xen-unstable.hg      25481:bc2f3a848f9a
  xen-4.1-testing.hg   23301:a9c0a89c08f2
  xen-4.0-testing.hg   21592:e35c8bb53255

PATCH INFORMATION
=================

 xen-unstable                                xsa9-unstable.patch  
 Xen 4.1, 4.1.x                              xsa9-xen-4.1.patch
 Xen 4.0, 4.0.x                              xsa9-xen-4.0.patch

$ sha256sum xsa9-*.patch
b48a2f1d5a7eb52f8533dccfb8bf0d6d403609011c1dd5915bcfcea92a5e8873  xsa9-unstable.patch
8ec1fa01b8094750e908bd5992b451e5c2acbe97ea1061e20c9244909d960262  xsa9-xen-4.0.patch
cb7686178ec8a2f021c01ae9706bfb3f1f44a098dba5723f1a645d959da5f2f3  xsa9-xen-4.1.patch

NOTE REGARDING EMBARGO
======================

Due to the relationship between this issue and XSA-7 (CVE-2012-0217),
we have concluded that this advisory should be under the same embargo
as XSA-7.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP1yzzAAoJEIP+FMlX6CvZXvgH/1og/ULBFEj1E5i7eySDdbMl
RtFfxCXbtTcsUvBQNZ6oKLKYyumhfQPhGUyhq5epuxZVhFmYEHdztH3Gf1fQLXuN
AhGLomV3vA5ANzs2Dc+jvMhM25VWGekZbqQCfV+3FhZEyiqneUGbVUrvIJlpe3LH
b5g4gWgvPpsFUewTtR7MgqJgBbVi1KbIc69r1Fh3Y+i6/KczxDwGUXtcVv1BZ3HJ
Qkts3oT2bEFiqUgPtZKdRnKJegRJGQipOueqQMzYO5xtzElqGJVuD9C01VK2Qxzh
Og7jsvajNM+9ulw5tTkbc2p84KBKaV2zrivfLfptir5IZOhI6RN6v880iyrNvpw=
=X3We
-----END PGP SIGNATURE-----


--GkZFEJHiah
Content-Type: application/octet-stream; name="xsa9-unstable.patch"
Content-Disposition: attachment; filename="xsa9-unstable.patch"
Content-Transfer-Encoding: base64

eDg2LTY0OiBkZXRlY3QgcHJvY2Vzc29ycyBzdWJqZWN0IHRvIEFNRCBlcnJhdHVtICMxMjEgYW5k
IHJlZnVzZSB0byBib290CgpQcm9jZXNzb3JzIHdpdGggdGhpcyBlcnJhdHVtIGFyZSBzdWJqZWN0
IHRvIGEgRG9TIGF0dGFjayBieSB1bnByaXZpbGVnZWQKZ3Vlc3QgdXNlcnMuCgpUaGlzIGlzIFhT
QS05IC8gQ1ZFLTIwMDYtMDc0NC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxKQmV1bGlj
aEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCi0tLSBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBi
L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xMjYsNiArMTI2LDE2IEBA
IE92ZXJyaWRlIFhlbidzIGxvZ2ljIGZvciBjaG9vc2luZyB0aGUgQVAKIHRoZXJlIGFyZSBtb3Jl
IHRoYW4gOCBDUFVzLCBYZW4gd2lsbCBzd2l0Y2ggdG8gYGJpZ3NtcGAgb3ZlcgogYGRlZmF1bHRg
LgogCisjIyMgYWxsb3dcX3Vuc2FmZQorPiBgPSA8Ym9vbGVhbj5gCisKK0ZvcmNlIGJvb3Qgb24g
cG90ZW50aWFsbHkgdW5zYWZlIHN5c3RlbXMuIEJ5IGRlZmF1bHQgWGVuIHdpbGwgcmVmdXNlIHRv
IGJvb3Qgb24KK3N5c3RlbXMgd2l0aCB0aGUgZm9sbG93aW5nIGVycmF0YToKKworKiBBTUQgRXJy
YXR1bSAxMjEuIFByb2Nlc3NvcnMgd2l0aCB0aGlzIGVycmF0dW0gYXJlIHN1YmplY3QgdG8gYSBn
dWVzdAorICB0cmlnZ2VyYWJsZSBEZW5pYWwgb2YgU2VydmljZS4gT3ZlcnJpZGUgb25seSBpZiB5
b3UgdHJ1c3QgYWxsIG9mIHlvdXIgUFYKKyAgZ3Vlc3RzLgorCiAjIyMgYXBpY1xfdmVyYm9zaXR5
CiA+IGA9IHZlcmJvc2UgfCBkZWJ1Z2AKIAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L2FtZC5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKQEAgLTMyLDYgKzMyLDkgQEAKIHN0YXRpYyBjaGFy
IG9wdF9mYW1yZXZbMTRdOwogc3RyaW5nX3BhcmFtKCJjcHVpZF9tYXNrX2NwdSIsIG9wdF9mYW1y
ZXYpOwogCitzdGF0aWMgYm9vbF90IG9wdF9hbGxvd191bnNhZmU7Citib29sZWFuX3BhcmFtKCJh
bGxvd191bnNhZmUiLCBvcHRfYWxsb3dfdW5zYWZlKTsKKwogc3RhdGljIGlubGluZSB2b2lkIHdy
bXNyX2FtZCh1bnNpZ25lZCBpbnQgaW5kZXgsIHVuc2lnbmVkIGludCBsbywgCiAJCXVuc2lnbmVk
IGludCBoaSkKIHsKQEAgLTQ3OCw2ICs0ODEsMTEgQEAgc3RhdGljIHZvaWQgX19kZXZpbml0IGlu
aXRfYW1kKHN0cnVjdCBjcAogCQljbGVhcl9iaXQoWDg2X0ZFQVRVUkVfTVdBSVQsIGMtPng4Nl9j
YXBhYmlsaXR5KTsKIAogI2lmZGVmIF9feDg2XzY0X18KKwlpZiAoY3B1X2hhc19hbWRfZXJyYXR1
bShjLCBBTURfRVJSQVRVTV8xMjEpICYmICFvcHRfYWxsb3dfdW5zYWZlKQorCQlwYW5pYygiWGVu
IHdpbGwgbm90IGJvb3Qgb24gdGhpcyBDUFUgZm9yIHNlY3VyaXR5IHJlYXNvbnMuXG4iCisJCSAg
ICAgICJQYXNzIFwiYWxsb3dfdW5zYWZlXCIgaWYgeW91J3JlIHRydXN0aW5nIGFsbCB5b3VyIgor
CQkgICAgICAiIChQVikgZ3Vlc3Qga2VybmVscy5cbiIpOworCiAJLyogQU1EIENQVXMgZG8gbm90
IHN1cHBvcnQgU1lTRU5URVIgb3V0c2lkZSBvZiBsZWdhY3kgbW9kZS4gKi8KIAljbGVhcl9iaXQo
WDg2X0ZFQVRVUkVfU0VQLCBjLT54ODZfY2FwYWJpbGl0eSk7CiAKLS0tIGEveGVuL2luY2x1ZGUv
YXNtLXg4Ni9hbWQuaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2FtZC5oCkBAIC0xMjcsNiAr
MTI3LDkgQEAKICNkZWZpbmUgQU1EX01PREVMX1JBTkdFX1NUQVJUKHJhbmdlKSAgICAoKChyYW5n
ZSkgPj4gMTIpICYgMHhmZmYpCiAjZGVmaW5lIEFNRF9NT0RFTF9SQU5HRV9FTkQocmFuZ2UpICAg
ICAgKChyYW5nZSkgJiAweGZmZikKIAorI2RlZmluZSBBTURfRVJSQVRVTV8xMjEgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIEFNRF9MRUdBQ1lf
RVJSQVRVTShBTURfTU9ERUxfUkFOR0UoMHgwZiwgMHgwLCAweDAsIDB4M2YsIDB4ZikpCisKICNk
ZWZpbmUgQU1EX0VSUkFUVU1fMTcwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKICAgICBBTURfTEVHQUNZX0VSUkFUVU0oQU1EX01PREVMX1JBTkdFKDB4
MGYsIDB4MCwgMHgwLCAweDY3LCAweGYpKQogCg==
--GkZFEJHiah
Content-Type: application/octet-stream; name="xsa9-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa9-xen-4.1.patch"
Content-Transfer-Encoding: base64

eDg2LTY0OiBkZXRlY3QgcHJvY2Vzc29ycyBzdWJqZWN0IHRvIEFNRCBlcnJhdHVtICMxMjEgYW5k
IHJlZnVzZSB0byBib290CgpQcm9jZXNzb3JzIHdpdGggdGhpcyBlcnJhdHVtIGFyZSBzdWJqZWN0
IHRvIGEgRG9TIGF0dGFjayBieSB1bnByaXZpbGVnZWQKZ3Vlc3QgdXNlcnMuCgpUaGlzIGlzIFhT
QS05IC8gQ1ZFLTIwMDYtMDc0NC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxKQmV1bGlj
aEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKKysrIGIveGVuL2FyY2gveDg2
L2NwdS9hbWQuYwpAQCAtMzIsNiArMzIsOSBAQAogc3RhdGljIGNoYXIgb3B0X2ZhbXJldlsxNF07
CiBzdHJpbmdfcGFyYW0oImNwdWlkX21hc2tfY3B1Iiwgb3B0X2ZhbXJldik7CiAKK3N0YXRpYyBp
bnQgb3B0X2FsbG93X3Vuc2FmZTsKK2Jvb2xlYW5fcGFyYW0oImFsbG93X3Vuc2FmZSIsIG9wdF9h
bGxvd191bnNhZmUpOworCiBzdGF0aWMgaW5saW5lIHZvaWQgd3Jtc3JfYW1kKHVuc2lnbmVkIGlu
dCBpbmRleCwgdW5zaWduZWQgaW50IGxvLCAKIAkJdW5zaWduZWQgaW50IGhpKQogewpAQCAtNjIw
LDYgKzYyMywxMSBAQCBzdGF0aWMgdm9pZCBfX2RldmluaXQgaW5pdF9hbWQoc3RydWN0IGNwCiAJ
CWNsZWFyX2JpdChYODZfRkVBVFVSRV9NQ0UsIGMtPng4Nl9jYXBhYmlsaXR5KTsKIAogI2lmZGVm
IF9feDg2XzY0X18KKwlpZiAoY3B1X2hhc19hbWRfZXJyYXR1bShjLCBBTURfRVJSQVRVTV8xMjEp
ICYmICFvcHRfYWxsb3dfdW5zYWZlKQorCQlwYW5pYygiWGVuIHdpbGwgbm90IGJvb3Qgb24gdGhp
cyBDUFUgZm9yIHNlY3VyaXR5IHJlYXNvbnMuXG4iCisJCSAgICAgICJQYXNzIFwiYWxsb3dfdW5z
YWZlXCIgaWYgeW91J3JlIHRydXN0aW5nIGFsbCB5b3VyIgorCQkgICAgICAiIChQVikgZ3Vlc3Qg
a2VybmVscy5cbiIpOworCiAJLyogQU1EIENQVXMgZG8gbm90IHN1cHBvcnQgU1lTRU5URVIgb3V0
c2lkZSBvZiBsZWdhY3kgbW9kZS4gKi8KIAljbGVhcl9iaXQoWDg2X0ZFQVRVUkVfU0VQLCBjLT54
ODZfY2FwYWJpbGl0eSk7CiAKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9hbWQuaAorKysgYi94
ZW4vaW5jbHVkZS9hc20teDg2L2FtZC5oCkBAIC0xMjcsNiArMTI3LDkgQEAKICNkZWZpbmUgQU1E
X01PREVMX1JBTkdFX1NUQVJUKHJhbmdlKSAgICAoKChyYW5nZSkgPj4gMTIpICYgMHhmZmYpCiAj
ZGVmaW5lIEFNRF9NT0RFTF9SQU5HRV9FTkQocmFuZ2UpICAgICAgKChyYW5nZSkgJiAweGZmZikK
IAorI2RlZmluZSBBTURfRVJSQVRVTV8xMjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAorICAgIEFNRF9MRUdBQ1lfRVJSQVRVTShBTURfTU9ERUxfUkFO
R0UoMHgwZiwgMHgwLCAweDAsIDB4M2YsIDB4ZikpCisKICNkZWZpbmUgQU1EX0VSUkFUVU1fMTcw
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBB
TURfTEVHQUNZX0VSUkFUVU0oQU1EX01PREVMX1JBTkdFKDB4MGYsIDB4MCwgMHgwLCAweDY3LCAw
eGYpKQogCg==
--GkZFEJHiah
Content-Type: application/octet-stream; name="xsa9-xen-4.0.patch"
Content-Disposition: attachment; filename="xsa9-xen-4.0.patch"
Content-Transfer-Encoding: base64

eDg2LTY0OiBkZXRlY3QgcHJvY2Vzc29ycyBzdWJqZWN0IHRvIEFNRCBlcnJhdHVtICMxMjEgYW5k
IHJlZnVzZSB0byBib290CgpQcm9jZXNzb3JzIHdpdGggdGhpcyBlcnJhdHVtIGFyZSBzdWJqZWN0
IHRvIGEgRG9TIGF0dGFjayBieSB1bnByaXZpbGVnZWQKZ3Vlc3QgdXNlcnMuCgpUaGlzIGlzIFhT
QS05IC8gQ1ZFLTIwMDYtMDc0NC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxKQmV1bGlj
aEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKKysrIGIveGVuL2FyY2gveDg2
L2NwdS9hbWQuYwpAQCAtNDEsNiArNDEsOSBAQCB2b2lkIHN0YXJ0X3N2bShzdHJ1Y3QgY3B1aW5m
b194ODYgKmMpOwogaW50ZWdlcl9wYXJhbSgiY3B1aWRfbWFza19leHRfZWN4Iiwgb3B0X2NwdWlk
X21hc2tfZXh0X2VjeCk7CiBpbnRlZ2VyX3BhcmFtKCJjcHVpZF9tYXNrX2V4dF9lZHgiLCBvcHRf
Y3B1aWRfbWFza19leHRfZWR4KTsKIAorc3RhdGljIGludCBvcHRfYWxsb3dfdW5zYWZlOworYm9v
bGVhbl9wYXJhbSgiYWxsb3dfdW5zYWZlIiwgb3B0X2FsbG93X3Vuc2FmZSk7CisKIHN0YXRpYyBp
bmxpbmUgdm9pZCB3cm1zcl9hbWQodW5zaWduZWQgaW50IGluZGV4LCB1bnNpZ25lZCBpbnQgbG8s
IAogCQl1bnNpZ25lZCBpbnQgaGkpCiB7CkBAIC02NDAsNiArNjQzLDExIEBAIHN0YXRpYyB2b2lk
IF9fZGV2aW5pdCBpbml0X2FtZChzdHJ1Y3QgY3AKIAkJY2xlYXJfYml0KFg4Nl9GRUFUVVJFX01D
RSwgYy0+eDg2X2NhcGFiaWxpdHkpOwogCiAjaWZkZWYgX194ODZfNjRfXworCWlmIChjcHVfaGFz
X2FtZF9lcnJhdHVtKGMsIEFNRF9FUlJBVFVNXzEyMSkgJiYgIW9wdF9hbGxvd191bnNhZmUpCisJ
CXBhbmljKCJYZW4gd2lsbCBub3QgYm9vdCBvbiB0aGlzIENQVSBmb3Igc2VjdXJpdHkgcmVhc29u
cy5cbiIKKwkJICAgICAgIlBhc3MgXCJhbGxvd191bnNhZmVcIiBpZiB5b3UncmUgdHJ1c3Rpbmcg
YWxsIHlvdXIiCisJCSAgICAgICIgKFBWKSBndWVzdCBrZXJuZWxzLlxuIik7CisKIAkvKiBBTUQg
Q1BVcyBkbyBub3Qgc3VwcG9ydCBTWVNFTlRFUiBvdXRzaWRlIG9mIGxlZ2FjeSBtb2RlLiAqLwog
CWNsZWFyX2JpdChYODZfRkVBVFVSRV9TRVAsIGMtPng4Nl9jYXBhYmlsaXR5KTsKICNlbmRpZgot
LS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2FtZC5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYv
YW1kLmgKQEAgLTEyNyw2ICsxMjcsOSBAQAogI2RlZmluZSBBTURfTU9ERUxfUkFOR0VfU1RBUlQo
cmFuZ2UpICAgICgoKHJhbmdlKSA+PiAxMikgJiAweGZmZikKICNkZWZpbmUgQU1EX01PREVMX1JB
TkdFX0VORChyYW5nZSkgICAgICAoKHJhbmdlKSAmIDB4ZmZmKQogCisjZGVmaW5lIEFNRF9FUlJB
VFVNXzEyMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
CisgICAgQU1EX0xFR0FDWV9FUlJBVFVNKEFNRF9NT0RFTF9SQU5HRSgweDBmLCAweDAsIDB4MCwg
MHgzZiwgMHhmKSkKKwogI2RlZmluZSBBTURfRVJSQVRVTV8xNzAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIEFNRF9MRUdBQ1lfRVJSQVRVTShB
TURfTU9ERUxfUkFOR0UoMHgwZiwgMHgwLCAweDAsIDB4NjcsIDB4ZikpCiAK
--GkZFEJHiah
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--GkZFEJHiah--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:04:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePp6-0002mD-Ei; Tue, 12 Jun 2012 12: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.Jackson@eu.citrix.com>) id 1SePp4-0002lL-VC
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:03:47 +0000
Received: from [85.158.139.83:61187] by server-8.bemta-5.messagelabs.com id
	72/E2-02058-12037DF4; Tue, 12 Jun 2012 12:03:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339502624!33231507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1983 invoked from network); 12 Jun 2012 12:03:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:03:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:03:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:03:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePp1-0006Qk-Kq; Tue, 12 Jun 2012 12:03:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePp1-0005UW-Ig;
	Tue, 12 Jun 2012 13:03:43 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="GkZFEJHiah"
Content-Transfer-Encoding: 7bit
Message-ID: <20439.12319.545744.59925@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:03:43 +0100
From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, oss-security@lists.openwall.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen Security Advisory 9 (CVE-2012-2934) - PV guest host
	DoS (AMD erratum #121)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--GkZFEJHiah
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2012-2934 / XSA-9
                            version 3

		   PV guest host Denial of Service

UPDATES IN VERSION 3
====================

Public release.  Previous versions were embargoed.

Remove leftover statement that CVE number had not been assigned.
The correct CVE for this issue is CVE-2012-2934.

ISSUE DESCRIPTION
=================

A Xen user has discovered that some older AMD CPUs can be made to lock
up due to AMD processor erratum #121.

This issue was discovered during testing of the fix for XSA-7
(CVE-2012-0217). Although the two issues are unrelated the situations
which can trigger them may overlap.

REFERENCES
==========

AMD Erratum #121 is described in "Revision Guide for AMD Athlon 64 and AMD
Opteron Processors": http://support.amd.com/us/Processor_TechDocs/25759.pdf

IMPACT
======

A guest user or administrator of a 64 bit PV guest on a vulnerable
system can cause the processor to lock up, leading to a Denial of
Service attack against the host.

Systems which run only 32 bit guest kernels are not vulnerable.

VULNERABLE SYSTEMS
==================

The following 130nm and 90nm (DDR1-only) AMD processors are subject
to this erratum:

 * First-generation AMD-Opteron(tm) single and dual core processors
   in either 939 or 940 packages:
   * AMD Opteron(tm) 100-Series Processors
   * AMD Opteron(tm) 200-Series Processors
   * AMD Opteron(tm) 800-Series Processors
 * AMD Athlon(tm) processors in either 754, 939 or 940 packages
 * AMD Sempron(tm) processor in either 754 or 939 packages
 * AMD Turion(tm) Mobile Technology in 754 package

None of the affected processors support AMD SVM.  Therefore, any
system which has any HVM Xen guests is not vulnerable.

This issue does not affect Intel processors.

MITIGATION
==========

Running a 64 bit PV guest kernel (which must necessarily be host
administrator controlled) which itself contains the fix for erratum
#121 will prevent unprivileged users in guests from exploiting this
issue.  All Windows operating systems and current versions of the
Linux and Solaris kernels, for example, are known to contain the fix
for erratum #121.

There is no mitigation when running untrusted 64 bit guest kernels or
against untrusted administrators of 64 bit guests.

Systems which run only 32 bit PV guest kernels are not
vulnerable. Note that this may mean only booting known good kernels or
vetting any user supplied kernels to ensure they are not 64 bit.

RESOLUTION
==========

There is no software fix for this issue. The workaround suggested by
AMD in erratum #121 cannot be applied to Xen since the relevant address
is under guest control.

Applying the patch will cause Xen to detect vulnerable systems and
refuse to boot. A command line override is provided to allow users who
accept the risks or who are able to mitigate as above to continue to
do so. To activate the override add "allow_unsafe" to your hypervisor
command line.

This change has been made to the staging Xen repositories:
  xen-unstable.hg      25481:bc2f3a848f9a
  xen-4.1-testing.hg   23301:a9c0a89c08f2
  xen-4.0-testing.hg   21592:e35c8bb53255

PATCH INFORMATION
=================

 xen-unstable                                xsa9-unstable.patch  
 Xen 4.1, 4.1.x                              xsa9-xen-4.1.patch
 Xen 4.0, 4.0.x                              xsa9-xen-4.0.patch

$ sha256sum xsa9-*.patch
b48a2f1d5a7eb52f8533dccfb8bf0d6d403609011c1dd5915bcfcea92a5e8873  xsa9-unstable.patch
8ec1fa01b8094750e908bd5992b451e5c2acbe97ea1061e20c9244909d960262  xsa9-xen-4.0.patch
cb7686178ec8a2f021c01ae9706bfb3f1f44a098dba5723f1a645d959da5f2f3  xsa9-xen-4.1.patch

NOTE REGARDING EMBARGO
======================

Due to the relationship between this issue and XSA-7 (CVE-2012-0217),
we have concluded that this advisory should be under the same embargo
as XSA-7.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP1yzzAAoJEIP+FMlX6CvZXvgH/1og/ULBFEj1E5i7eySDdbMl
RtFfxCXbtTcsUvBQNZ6oKLKYyumhfQPhGUyhq5epuxZVhFmYEHdztH3Gf1fQLXuN
AhGLomV3vA5ANzs2Dc+jvMhM25VWGekZbqQCfV+3FhZEyiqneUGbVUrvIJlpe3LH
b5g4gWgvPpsFUewTtR7MgqJgBbVi1KbIc69r1Fh3Y+i6/KczxDwGUXtcVv1BZ3HJ
Qkts3oT2bEFiqUgPtZKdRnKJegRJGQipOueqQMzYO5xtzElqGJVuD9C01VK2Qxzh
Og7jsvajNM+9ulw5tTkbc2p84KBKaV2zrivfLfptir5IZOhI6RN6v880iyrNvpw=
=X3We
-----END PGP SIGNATURE-----


--GkZFEJHiah
Content-Type: application/octet-stream; name="xsa9-unstable.patch"
Content-Disposition: attachment; filename="xsa9-unstable.patch"
Content-Transfer-Encoding: base64

eDg2LTY0OiBkZXRlY3QgcHJvY2Vzc29ycyBzdWJqZWN0IHRvIEFNRCBlcnJhdHVtICMxMjEgYW5k
IHJlZnVzZSB0byBib290CgpQcm9jZXNzb3JzIHdpdGggdGhpcyBlcnJhdHVtIGFyZSBzdWJqZWN0
IHRvIGEgRG9TIGF0dGFjayBieSB1bnByaXZpbGVnZWQKZ3Vlc3QgdXNlcnMuCgpUaGlzIGlzIFhT
QS05IC8gQ1ZFLTIwMDYtMDc0NC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxKQmV1bGlj
aEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCi0tLSBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBi
L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xMjYsNiArMTI2LDE2IEBA
IE92ZXJyaWRlIFhlbidzIGxvZ2ljIGZvciBjaG9vc2luZyB0aGUgQVAKIHRoZXJlIGFyZSBtb3Jl
IHRoYW4gOCBDUFVzLCBYZW4gd2lsbCBzd2l0Y2ggdG8gYGJpZ3NtcGAgb3ZlcgogYGRlZmF1bHRg
LgogCisjIyMgYWxsb3dcX3Vuc2FmZQorPiBgPSA8Ym9vbGVhbj5gCisKK0ZvcmNlIGJvb3Qgb24g
cG90ZW50aWFsbHkgdW5zYWZlIHN5c3RlbXMuIEJ5IGRlZmF1bHQgWGVuIHdpbGwgcmVmdXNlIHRv
IGJvb3Qgb24KK3N5c3RlbXMgd2l0aCB0aGUgZm9sbG93aW5nIGVycmF0YToKKworKiBBTUQgRXJy
YXR1bSAxMjEuIFByb2Nlc3NvcnMgd2l0aCB0aGlzIGVycmF0dW0gYXJlIHN1YmplY3QgdG8gYSBn
dWVzdAorICB0cmlnZ2VyYWJsZSBEZW5pYWwgb2YgU2VydmljZS4gT3ZlcnJpZGUgb25seSBpZiB5
b3UgdHJ1c3QgYWxsIG9mIHlvdXIgUFYKKyAgZ3Vlc3RzLgorCiAjIyMgYXBpY1xfdmVyYm9zaXR5
CiA+IGA9IHZlcmJvc2UgfCBkZWJ1Z2AKIAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L2FtZC5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKQEAgLTMyLDYgKzMyLDkgQEAKIHN0YXRpYyBjaGFy
IG9wdF9mYW1yZXZbMTRdOwogc3RyaW5nX3BhcmFtKCJjcHVpZF9tYXNrX2NwdSIsIG9wdF9mYW1y
ZXYpOwogCitzdGF0aWMgYm9vbF90IG9wdF9hbGxvd191bnNhZmU7Citib29sZWFuX3BhcmFtKCJh
bGxvd191bnNhZmUiLCBvcHRfYWxsb3dfdW5zYWZlKTsKKwogc3RhdGljIGlubGluZSB2b2lkIHdy
bXNyX2FtZCh1bnNpZ25lZCBpbnQgaW5kZXgsIHVuc2lnbmVkIGludCBsbywgCiAJCXVuc2lnbmVk
IGludCBoaSkKIHsKQEAgLTQ3OCw2ICs0ODEsMTEgQEAgc3RhdGljIHZvaWQgX19kZXZpbml0IGlu
aXRfYW1kKHN0cnVjdCBjcAogCQljbGVhcl9iaXQoWDg2X0ZFQVRVUkVfTVdBSVQsIGMtPng4Nl9j
YXBhYmlsaXR5KTsKIAogI2lmZGVmIF9feDg2XzY0X18KKwlpZiAoY3B1X2hhc19hbWRfZXJyYXR1
bShjLCBBTURfRVJSQVRVTV8xMjEpICYmICFvcHRfYWxsb3dfdW5zYWZlKQorCQlwYW5pYygiWGVu
IHdpbGwgbm90IGJvb3Qgb24gdGhpcyBDUFUgZm9yIHNlY3VyaXR5IHJlYXNvbnMuXG4iCisJCSAg
ICAgICJQYXNzIFwiYWxsb3dfdW5zYWZlXCIgaWYgeW91J3JlIHRydXN0aW5nIGFsbCB5b3VyIgor
CQkgICAgICAiIChQVikgZ3Vlc3Qga2VybmVscy5cbiIpOworCiAJLyogQU1EIENQVXMgZG8gbm90
IHN1cHBvcnQgU1lTRU5URVIgb3V0c2lkZSBvZiBsZWdhY3kgbW9kZS4gKi8KIAljbGVhcl9iaXQo
WDg2X0ZFQVRVUkVfU0VQLCBjLT54ODZfY2FwYWJpbGl0eSk7CiAKLS0tIGEveGVuL2luY2x1ZGUv
YXNtLXg4Ni9hbWQuaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2FtZC5oCkBAIC0xMjcsNiAr
MTI3LDkgQEAKICNkZWZpbmUgQU1EX01PREVMX1JBTkdFX1NUQVJUKHJhbmdlKSAgICAoKChyYW5n
ZSkgPj4gMTIpICYgMHhmZmYpCiAjZGVmaW5lIEFNRF9NT0RFTF9SQU5HRV9FTkQocmFuZ2UpICAg
ICAgKChyYW5nZSkgJiAweGZmZikKIAorI2RlZmluZSBBTURfRVJSQVRVTV8xMjEgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIEFNRF9MRUdBQ1lf
RVJSQVRVTShBTURfTU9ERUxfUkFOR0UoMHgwZiwgMHgwLCAweDAsIDB4M2YsIDB4ZikpCisKICNk
ZWZpbmUgQU1EX0VSUkFUVU1fMTcwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKICAgICBBTURfTEVHQUNZX0VSUkFUVU0oQU1EX01PREVMX1JBTkdFKDB4
MGYsIDB4MCwgMHgwLCAweDY3LCAweGYpKQogCg==
--GkZFEJHiah
Content-Type: application/octet-stream; name="xsa9-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa9-xen-4.1.patch"
Content-Transfer-Encoding: base64

eDg2LTY0OiBkZXRlY3QgcHJvY2Vzc29ycyBzdWJqZWN0IHRvIEFNRCBlcnJhdHVtICMxMjEgYW5k
IHJlZnVzZSB0byBib290CgpQcm9jZXNzb3JzIHdpdGggdGhpcyBlcnJhdHVtIGFyZSBzdWJqZWN0
IHRvIGEgRG9TIGF0dGFjayBieSB1bnByaXZpbGVnZWQKZ3Vlc3QgdXNlcnMuCgpUaGlzIGlzIFhT
QS05IC8gQ1ZFLTIwMDYtMDc0NC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxKQmV1bGlj
aEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKKysrIGIveGVuL2FyY2gveDg2
L2NwdS9hbWQuYwpAQCAtMzIsNiArMzIsOSBAQAogc3RhdGljIGNoYXIgb3B0X2ZhbXJldlsxNF07
CiBzdHJpbmdfcGFyYW0oImNwdWlkX21hc2tfY3B1Iiwgb3B0X2ZhbXJldik7CiAKK3N0YXRpYyBp
bnQgb3B0X2FsbG93X3Vuc2FmZTsKK2Jvb2xlYW5fcGFyYW0oImFsbG93X3Vuc2FmZSIsIG9wdF9h
bGxvd191bnNhZmUpOworCiBzdGF0aWMgaW5saW5lIHZvaWQgd3Jtc3JfYW1kKHVuc2lnbmVkIGlu
dCBpbmRleCwgdW5zaWduZWQgaW50IGxvLCAKIAkJdW5zaWduZWQgaW50IGhpKQogewpAQCAtNjIw
LDYgKzYyMywxMSBAQCBzdGF0aWMgdm9pZCBfX2RldmluaXQgaW5pdF9hbWQoc3RydWN0IGNwCiAJ
CWNsZWFyX2JpdChYODZfRkVBVFVSRV9NQ0UsIGMtPng4Nl9jYXBhYmlsaXR5KTsKIAogI2lmZGVm
IF9feDg2XzY0X18KKwlpZiAoY3B1X2hhc19hbWRfZXJyYXR1bShjLCBBTURfRVJSQVRVTV8xMjEp
ICYmICFvcHRfYWxsb3dfdW5zYWZlKQorCQlwYW5pYygiWGVuIHdpbGwgbm90IGJvb3Qgb24gdGhp
cyBDUFUgZm9yIHNlY3VyaXR5IHJlYXNvbnMuXG4iCisJCSAgICAgICJQYXNzIFwiYWxsb3dfdW5z
YWZlXCIgaWYgeW91J3JlIHRydXN0aW5nIGFsbCB5b3VyIgorCQkgICAgICAiIChQVikgZ3Vlc3Qg
a2VybmVscy5cbiIpOworCiAJLyogQU1EIENQVXMgZG8gbm90IHN1cHBvcnQgU1lTRU5URVIgb3V0
c2lkZSBvZiBsZWdhY3kgbW9kZS4gKi8KIAljbGVhcl9iaXQoWDg2X0ZFQVRVUkVfU0VQLCBjLT54
ODZfY2FwYWJpbGl0eSk7CiAKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9hbWQuaAorKysgYi94
ZW4vaW5jbHVkZS9hc20teDg2L2FtZC5oCkBAIC0xMjcsNiArMTI3LDkgQEAKICNkZWZpbmUgQU1E
X01PREVMX1JBTkdFX1NUQVJUKHJhbmdlKSAgICAoKChyYW5nZSkgPj4gMTIpICYgMHhmZmYpCiAj
ZGVmaW5lIEFNRF9NT0RFTF9SQU5HRV9FTkQocmFuZ2UpICAgICAgKChyYW5nZSkgJiAweGZmZikK
IAorI2RlZmluZSBBTURfRVJSQVRVTV8xMjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAorICAgIEFNRF9MRUdBQ1lfRVJSQVRVTShBTURfTU9ERUxfUkFO
R0UoMHgwZiwgMHgwLCAweDAsIDB4M2YsIDB4ZikpCisKICNkZWZpbmUgQU1EX0VSUkFUVU1fMTcw
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBB
TURfTEVHQUNZX0VSUkFUVU0oQU1EX01PREVMX1JBTkdFKDB4MGYsIDB4MCwgMHgwLCAweDY3LCAw
eGYpKQogCg==
--GkZFEJHiah
Content-Type: application/octet-stream; name="xsa9-xen-4.0.patch"
Content-Disposition: attachment; filename="xsa9-xen-4.0.patch"
Content-Transfer-Encoding: base64

eDg2LTY0OiBkZXRlY3QgcHJvY2Vzc29ycyBzdWJqZWN0IHRvIEFNRCBlcnJhdHVtICMxMjEgYW5k
IHJlZnVzZSB0byBib290CgpQcm9jZXNzb3JzIHdpdGggdGhpcyBlcnJhdHVtIGFyZSBzdWJqZWN0
IHRvIGEgRG9TIGF0dGFjayBieSB1bnByaXZpbGVnZWQKZ3Vlc3QgdXNlcnMuCgpUaGlzIGlzIFhT
QS05IC8gQ1ZFLTIwMDYtMDc0NC4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxKQmV1bGlj
aEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMKKysrIGIveGVuL2FyY2gveDg2
L2NwdS9hbWQuYwpAQCAtNDEsNiArNDEsOSBAQCB2b2lkIHN0YXJ0X3N2bShzdHJ1Y3QgY3B1aW5m
b194ODYgKmMpOwogaW50ZWdlcl9wYXJhbSgiY3B1aWRfbWFza19leHRfZWN4Iiwgb3B0X2NwdWlk
X21hc2tfZXh0X2VjeCk7CiBpbnRlZ2VyX3BhcmFtKCJjcHVpZF9tYXNrX2V4dF9lZHgiLCBvcHRf
Y3B1aWRfbWFza19leHRfZWR4KTsKIAorc3RhdGljIGludCBvcHRfYWxsb3dfdW5zYWZlOworYm9v
bGVhbl9wYXJhbSgiYWxsb3dfdW5zYWZlIiwgb3B0X2FsbG93X3Vuc2FmZSk7CisKIHN0YXRpYyBp
bmxpbmUgdm9pZCB3cm1zcl9hbWQodW5zaWduZWQgaW50IGluZGV4LCB1bnNpZ25lZCBpbnQgbG8s
IAogCQl1bnNpZ25lZCBpbnQgaGkpCiB7CkBAIC02NDAsNiArNjQzLDExIEBAIHN0YXRpYyB2b2lk
IF9fZGV2aW5pdCBpbml0X2FtZChzdHJ1Y3QgY3AKIAkJY2xlYXJfYml0KFg4Nl9GRUFUVVJFX01D
RSwgYy0+eDg2X2NhcGFiaWxpdHkpOwogCiAjaWZkZWYgX194ODZfNjRfXworCWlmIChjcHVfaGFz
X2FtZF9lcnJhdHVtKGMsIEFNRF9FUlJBVFVNXzEyMSkgJiYgIW9wdF9hbGxvd191bnNhZmUpCisJ
CXBhbmljKCJYZW4gd2lsbCBub3QgYm9vdCBvbiB0aGlzIENQVSBmb3Igc2VjdXJpdHkgcmVhc29u
cy5cbiIKKwkJICAgICAgIlBhc3MgXCJhbGxvd191bnNhZmVcIiBpZiB5b3UncmUgdHJ1c3Rpbmcg
YWxsIHlvdXIiCisJCSAgICAgICIgKFBWKSBndWVzdCBrZXJuZWxzLlxuIik7CisKIAkvKiBBTUQg
Q1BVcyBkbyBub3Qgc3VwcG9ydCBTWVNFTlRFUiBvdXRzaWRlIG9mIGxlZ2FjeSBtb2RlLiAqLwog
CWNsZWFyX2JpdChYODZfRkVBVFVSRV9TRVAsIGMtPng4Nl9jYXBhYmlsaXR5KTsKICNlbmRpZgot
LS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2FtZC5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYv
YW1kLmgKQEAgLTEyNyw2ICsxMjcsOSBAQAogI2RlZmluZSBBTURfTU9ERUxfUkFOR0VfU1RBUlQo
cmFuZ2UpICAgICgoKHJhbmdlKSA+PiAxMikgJiAweGZmZikKICNkZWZpbmUgQU1EX01PREVMX1JB
TkdFX0VORChyYW5nZSkgICAgICAoKHJhbmdlKSAmIDB4ZmZmKQogCisjZGVmaW5lIEFNRF9FUlJB
VFVNXzEyMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
CisgICAgQU1EX0xFR0FDWV9FUlJBVFVNKEFNRF9NT0RFTF9SQU5HRSgweDBmLCAweDAsIDB4MCwg
MHgzZiwgMHhmKSkKKwogI2RlZmluZSBBTURfRVJSQVRVTV8xNzAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIEFNRF9MRUdBQ1lfRVJSQVRVTShB
TURfTU9ERUxfUkFOR0UoMHgwZiwgMHgwLCAweDAsIDB4NjcsIDB4ZikpCiAK
--GkZFEJHiah
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--GkZFEJHiah--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:07:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12:07: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 1SePsC-0003kj-Ff; Tue, 12 Jun 2012 12:07:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david@fromorbit.com>) id 1SeIEg-0004Xb-Rx
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 03:57:43 +0000
Received: from [85.158.139.83:23401] by server-9.bemta-5.messagelabs.com id
	11/56-29678-53EB6DF4; Tue, 12 Jun 2012 03:57:41 +0000
X-Env-Sender: david@fromorbit.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339473460!33142955!1
X-Originating-IP: [150.101.137.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAxNTAuMTAxLjEzNy4xMjkgPT4gMTQ0MjQ1\n,sa_preprocessor: 
	QmFkIElQOiAxNTAuMTAxLjEzNy4xMjkgPT4gMTQ0MjQ1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21872 invoked from network); 12 Jun 2012 03:57:41 -0000
Received: from ipmail06.adl2.internode.on.net (HELO
	ipmail06.adl2.internode.on.net) (150.101.137.129)
	by server-5.tower-182.messagelabs.com with SMTP;
	12 Jun 2012 03:57:41 -0000
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak0JAFG91k95LKXc/2dsb2JhbABFs2gEgTCBCIIYAQEFOhwjEAgDGC4UJQMhE4gKuQIUiw8gMIVBA5Uej3yCcoFF
Received: from ppp121-44-165-220.lns20.syd7.internode.on.net (HELO dastard)
	([121.44.165.220])
	by ipmail06.adl2.internode.on.net with ESMTP; 12 Jun 2012 13:27:39 +0930
Received: from dave by dastard with local (Exim 4.76)
	(envelope-from <david@fromorbit.com>)
	id 1SeIEb-0005WM-B3; Tue, 12 Jun 2012 13:57:37 +1000
Date: Tue, 12 Jun 2012 13:57:37 +1000
From: Dave Chinner <david@fromorbit.com>
To: Jason Stubbs <jasonbstubbs@gmail.com>
Message-ID: <20120612035737.GL22848@dastard>
References: <4FD1918A.2060908@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD1918A.2060908@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Tue, 12 Jun 2012 12:06:59 +0000
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PROBLEM: Possible race between  xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 08, 2012 at 03:45:46PM +1000, Jason Stubbs wrote:
> Hi,
> 
> To quickly summarize, on a Xen domU instance with a disk structure of XFS on
> LVM2 on RAID10 on 8x virtual disks, all tasks performing I/O to said XFS
> partition hung and I cannot prove or disprove it to be dom0 issue.
> 
> And now the long(er) version:
> 
> On an Amazon EC2 (xen) instance, I had I/O to one of the EBS (Elastic Block
> Store virtual disk) devices block with iostat showing one single request
> pending. Kernel logs showed hung tasks so after grabbing those I reset the
> instance but - while I'm told that Amazon's logs don't show any problems
> with the EBS - Amazon want the opportunity to exclude an EBS problem by
> examining things from the dom0 side while the problem is occurring before
> delving into the kernel.

Yup, everything is hung waiting for that one IO to complete. Nothing
wrong with MD, LVM, or XFS. The problem is either that EBS never
completed the IO, or Xen swallowed it and it never made to it to the
guest OS. Either way, it does not appear to be a problem in the
higher levels of the linux storage stack.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:07:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12:07: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 1SePsC-0003kj-Ff; Tue, 12 Jun 2012 12:07:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david@fromorbit.com>) id 1SeIEg-0004Xb-Rx
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 03:57:43 +0000
Received: from [85.158.139.83:23401] by server-9.bemta-5.messagelabs.com id
	11/56-29678-53EB6DF4; Tue, 12 Jun 2012 03:57:41 +0000
X-Env-Sender: david@fromorbit.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339473460!33142955!1
X-Originating-IP: [150.101.137.129]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAxNTAuMTAxLjEzNy4xMjkgPT4gMTQ0MjQ1\n,sa_preprocessor: 
	QmFkIElQOiAxNTAuMTAxLjEzNy4xMjkgPT4gMTQ0MjQ1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21872 invoked from network); 12 Jun 2012 03:57:41 -0000
Received: from ipmail06.adl2.internode.on.net (HELO
	ipmail06.adl2.internode.on.net) (150.101.137.129)
	by server-5.tower-182.messagelabs.com with SMTP;
	12 Jun 2012 03:57:41 -0000
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak0JAFG91k95LKXc/2dsb2JhbABFs2gEgTCBCIIYAQEFOhwjEAgDGC4UJQMhE4gKuQIUiw8gMIVBA5Uej3yCcoFF
Received: from ppp121-44-165-220.lns20.syd7.internode.on.net (HELO dastard)
	([121.44.165.220])
	by ipmail06.adl2.internode.on.net with ESMTP; 12 Jun 2012 13:27:39 +0930
Received: from dave by dastard with local (Exim 4.76)
	(envelope-from <david@fromorbit.com>)
	id 1SeIEb-0005WM-B3; Tue, 12 Jun 2012 13:57:37 +1000
Date: Tue, 12 Jun 2012 13:57:37 +1000
From: Dave Chinner <david@fromorbit.com>
To: Jason Stubbs <jasonbstubbs@gmail.com>
Message-ID: <20120612035737.GL22848@dastard>
References: <4FD1918A.2060908@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD1918A.2060908@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Tue, 12 Jun 2012 12:06:59 +0000
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PROBLEM: Possible race between  xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 08, 2012 at 03:45:46PM +1000, Jason Stubbs wrote:
> Hi,
> 
> To quickly summarize, on a Xen domU instance with a disk structure of XFS on
> LVM2 on RAID10 on 8x virtual disks, all tasks performing I/O to said XFS
> partition hung and I cannot prove or disprove it to be dom0 issue.
> 
> And now the long(er) version:
> 
> On an Amazon EC2 (xen) instance, I had I/O to one of the EBS (Elastic Block
> Store virtual disk) devices block with iostat showing one single request
> pending. Kernel logs showed hung tasks so after grabbing those I reset the
> instance but - while I'm told that Amazon's logs don't show any problems
> with the EBS - Amazon want the opportunity to exclude an EBS problem by
> examining things from the dom0 side while the problem is occurring before
> delving into the kernel.

Yup, everything is hung waiting for that one IO to complete. Nothing
wrong with MD, LVM, or XFS. The problem is either that EBS never
completed the IO, or Xen swallowed it and it never made to it to the
guest OS. Either way, it does not appear to be a problem in the
higher levels of the linux storage stack.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePsG-0003mC-UC; Tue, 12 Jun 2012 12:07:04 +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 1SeAVN-0003b3-ON
	for Xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:42:27 +0000
Received: from [85.158.143.35:16653] by server-1.bemta-4.messagelabs.com id
	08/28-24392-02A46DF4; Mon, 11 Jun 2012 19:42:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339443740!11390857!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4Mjc3OQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12310 invoked from network); 11 Jun 2012 19:42:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 19:42:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BJgH5l004676
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 19:42:18 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
	q5BJgG3o011857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 19:42:16 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
	q5BJgF4F018174; Mon, 11 Jun 2012 14:42:15 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 12:42:14 -0700
Date: Mon, 11 Jun 2012 12:42:13 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Cyclonus J <cyclonusj@gmail.com>
Message-ID: <20120611124213.18e2c7fb@mantra.us.oracle.com>
In-Reply-To: <CAOzbF4cp8M4eYCkJgnsyxLREOOMiHUfc0ftacNnMuX5ZB6SBCA@mail.gmail.com>
References: <CAOzbF4cp8M4eYCkJgnsyxLREOOMiHUfc0ftacNnMuX5ZB6SBCA@mail.gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="MP_/X3qA/jwEscosmMB+TVJPo3b"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Tue, 12 Jun 2012 12:07:02 +0000
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen debugger support for newer version of 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

--MP_/X3qA/jwEscosmMB+TVJPo3b
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sat, 9 Jun 2012 01:56:32 -0700
Cyclonus J <cyclonusj@gmail.com> wrote:

> Hi Mukesh,
> 
> I am currently dealing some device driver issues with Xen 4.1.2 and
> would like to try out your great Xen debugger, but it looks like that
> your Xen debugger only supports 4.1.0-rc3 and the last update is
> almost one year ago.
> 
> So my question is what would be your plan to support Xen debugger for
> future Xen releases? And if there is a plan, may I help you?
> 
> Thanks,
> CJ

I've been just maintaining it here. I add/update as needed for my
debugging. I am attaching patch that should apply cleanly to unstable
c/s 25467. You should be able to back it up to 4.1.2 with minor
changes, like header/struct changes, (so fixup printk's), etc. Give
it a shot. This is the latest. If you have difficulty, I can send you
4.1.2 version, but I'd need to update it a bit. 

Hope that helps,
Mukesh



--MP_/X3qA/jwEscosmMB+TVJPo3b
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=kdb.patch

diff -r 32034d1914a6 -r e4b01842b71c xen/Makefile
--- a/xen/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -61,6 +61,7 @@ _clean: delete-unfresh-files
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C kdb clean
 	rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET)-syms *~ core
 	rm -f include/asm-*/asm-offsets.h
 	[ -d tools/figlet ] && rm -f .banner*
@@ -129,7 +130,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h
 	  echo ""; \
 	  echo "#endif") <$< >$@
 
-SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers
+SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers kdb
 define all_sources
     ( find include/asm-$(TARGET_ARCH) -name '*.h' -print; \
       find include -name 'asm-*' -prune -o -name '*.h' -print; \
diff -r 32034d1914a6 -r e4b01842b71c xen/Rules.mk
--- a/xen/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Rules.mk	Fri Jun 08 10:56:24 2012 -0700
@@ -10,6 +10,7 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto           ?= n
+kdb           ?= n
 
 include $(XEN_ROOT)/Config.mk
 
@@ -40,6 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/d
 ALL_OBJS-y               += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(kdb)          += $(BASEDIR)/kdb/built_in.o
 
 CFLAGS-y                += -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
@@ -53,6 +55,7 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFIL
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(kdb)           += -DXEN_KDB_CONFIG
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y                += -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/svm/entry.S
--- a/xen/arch/x86/hvm/svm/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -59,12 +59,23 @@ ENTRY(svm_asm_do_resume)
         get_current(bx)
         CLGI
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         testl $~0,(r(dx),r(ax),1)
         jnz  .Lsvm_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0, VCPU_nsvm_hap_enabled(r(bx))
 UNLIKELY_START(nz, nsvm_hap)
         mov  VCPU_nhvm_p2m(r(bx)),r(ax)
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2170,6 +2170,10 @@ void svm_vmexit_handler(struct cpu_user_
         break;
 
     case VMEXIT_EXCEPTION_DB:
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+	    break;
+#endif
         if ( !v->domain->debugger_attached )
             goto exit_and_crash;
         domain_pause_for_debugger();
@@ -2182,6 +2186,10 @@ void svm_vmexit_handler(struct cpu_user_
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
         __update_guest_eip(regs, inst_len);
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_int3, regs))
+            break;
+#endif
         current->arch.gdbsx_vcpu_event = TRAP_int3;
         domain_pause_for_debugger();
         break;
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Fri Jun 08 10:56:24 2012 -0700
@@ -315,6 +315,36 @@ void setup_vmcb_dump(void)
     register_keyhandler('v', &vmcb_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+/* did == 0 : display for all HVM domains. domid 0 is never HVM.
+ *  * vid == -1 : display for all HVM VCPUs
+ *   */
+void kdb_dump_vmcb(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain (dp) {
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+            kdbp("  VMCB [domid: %d  vcpu:%d]:\n", dp->domain_id, vp->vcpu_id);
+            svm_vmcb_dump("kdb", vp->arch.hvm_svm.vmcb);
+            kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    rcu_read_unlock(&domlist_read_lock);
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/vmx/entry.S
--- a/xen/arch/x86/hvm/vmx/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -124,12 +124,23 @@ vmx_asm_do_vmentry:
         get_current(bx)
         cli
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         cmpl $0,(r(dx),r(ax),1)
         jnz  .Lvmx_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0xff,VCPU_vmx_emulate(r(bx))
         jnz .Lvmx_goto_emulator
         testb $0xff,VCPU_vmx_realmode(r(bx))
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Fri Jun 08 10:56:24 2012 -0700
@@ -1117,6 +1117,13 @@ void vmx_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
+#if defined(XEN_KDB_CONFIG)
+    if (kdb_dr7)
+        __vmwrite(GUEST_DR7, kdb_dr7);
+    else
+        __vmwrite(GUEST_DR7, 0);
+#endif
+
     debug_state = v->domain->debugger_attached
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_INT3]
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP];
@@ -1326,6 +1333,220 @@ void setup_vmcs_dump(void)
     register_keyhandler('v', &vmcs_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+#define GUEST_EFER      0x2806   /* see page 23-20 */
+#define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+
+/* it's a shame we can't use vmcs_dump_vcpu(), but it does vmx_vmcs_enter which
+ * will IPI other CPUs. also, print a subset relevant to software debugging */
+static void noinline kdb_print_vmcs(struct vcpu *vp)
+{
+    struct cpu_user_regs *regs = &vp->arch.user_regs;
+    unsigned long long x;
+
+    kdbp("*** Guest State ***\n");
+    kdbp("CR0: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR0),
+         (unsigned long long)vmr(CR0_READ_SHADOW), 
+         (unsigned long long)vmr(CR0_GUEST_HOST_MASK));
+    kdbp("CR4: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR4),
+         (unsigned long long)vmr(CR4_READ_SHADOW), 
+         (unsigned long long)vmr(CR4_GUEST_HOST_MASK));
+    kdbp("CR3: actual=0x%016llx, target_count=%d\n",
+         (unsigned long long)vmr(GUEST_CR3),
+         (int)vmr(CR3_TARGET_COUNT));
+    kdbp("     target0=%016llx, target1=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE0),
+         (unsigned long long)vmr(CR3_TARGET_VALUE1));
+    kdbp("     target2=%016llx, target3=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE2),
+         (unsigned long long)vmr(CR3_TARGET_VALUE3));
+    kdbp("RSP = 0x%016llx (0x%016llx)  RIP = 0x%016llx (0x%016llx)\n", 
+         (unsigned long long)vmr(GUEST_RSP),
+         (unsigned long long)regs->esp,
+         (unsigned long long)vmr(GUEST_RIP),
+         (unsigned long long)regs->eip);
+    kdbp("RFLAGS=0x%016llx (0x%016llx)  DR7 = 0x%016llx\n", 
+         (unsigned long long)vmr(GUEST_RFLAGS),
+         (unsigned long long)regs->eflags,
+         (unsigned long long)vmr(GUEST_DR7));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+         (unsigned long long)vmr(GUEST_SYSENTER_ESP),
+         (int)vmr(GUEST_SYSENTER_CS),
+         (unsigned long long)vmr(GUEST_SYSENTER_EIP));
+    vmx_dump_sel("CS", GUEST_CS_SELECTOR);
+    vmx_dump_sel("DS", GUEST_DS_SELECTOR);
+    vmx_dump_sel("SS", GUEST_SS_SELECTOR);
+    vmx_dump_sel("ES", GUEST_ES_SELECTOR);
+    vmx_dump_sel("FS", GUEST_FS_SELECTOR);
+    vmx_dump_sel("GS", GUEST_GS_SELECTOR);
+    vmx_dump_sel2("GDTR", GUEST_GDTR_LIMIT);
+    vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
+    vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
+    vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
+    kdbp("Guest PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
+    x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
+    x |= (uint32_t)vmr(TSC_OFFSET);
+    kdbp("TSC Offset = %016llx\n", x);
+    x  = (unsigned long long)vmr(GUEST_IA32_DEBUGCTL_HIGH) << 32;
+    x |= (uint32_t)vmr(GUEST_IA32_DEBUGCTL);
+    kdbp("DebugCtl=%016llx DebugExceptions=%016llx\n", x,
+           (unsigned long long)vmr(GUEST_PENDING_DBG_EXCEPTIONS));
+    kdbp("Interruptibility=%04x ActivityState=%04x\n",
+           (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
+           (int)vmr(GUEST_ACTIVITY_STATE));
+
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
+    kdbp("\n*** Host State ***\n");
+    kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
+           (unsigned long long)vmr(HOST_RSP),
+           (unsigned long long)vmr(HOST_RIP));
+    kdbp("CS=%04x DS=%04x ES=%04x FS=%04x GS=%04x SS=%04x TR=%04x\n",
+           (uint16_t)vmr(HOST_CS_SELECTOR),
+           (uint16_t)vmr(HOST_DS_SELECTOR),
+           (uint16_t)vmr(HOST_ES_SELECTOR),
+           (uint16_t)vmr(HOST_FS_SELECTOR),
+           (uint16_t)vmr(HOST_GS_SELECTOR),
+           (uint16_t)vmr(HOST_SS_SELECTOR),
+           (uint16_t)vmr(HOST_TR_SELECTOR));
+    kdbp("FSBase=%016llx GSBase=%016llx TRBase=%016llx\n",
+           (unsigned long long)vmr(HOST_FS_BASE),
+           (unsigned long long)vmr(HOST_GS_BASE),
+           (unsigned long long)vmr(HOST_TR_BASE));
+    kdbp("GDTBase=%016llx IDTBase=%016llx\n",
+           (unsigned long long)vmr(HOST_GDTR_BASE),
+           (unsigned long long)vmr(HOST_IDTR_BASE));
+    kdbp("CR0=%016llx CR3=%016llx CR4=%016llx\n",
+           (unsigned long long)vmr(HOST_CR0),
+           (unsigned long long)vmr(HOST_CR3),
+           (unsigned long long)vmr(HOST_CR4));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+           (unsigned long long)vmr(HOST_SYSENTER_ESP),
+           (int)vmr(HOST_SYSENTER_CS),
+           (unsigned long long)vmr(HOST_SYSENTER_EIP));
+    kdbp("Host PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(HOST_PAT_HIGH), (uint32_t)vmr(HOST_PAT));
+
+    kdbp("\n*** Control State ***\n");
+    kdbp("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n",
+           (uint32_t)vmr(PIN_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(CPU_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(SECONDARY_VM_EXEC_CONTROL));
+    kdbp("EntryControls=%08x ExitControls=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_CONTROLS),
+           (uint32_t)vmr(VM_EXIT_CONTROLS));
+    kdbp("ExceptionBitmap=%08x\n",
+           (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
+    kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_INTR_INFO),
+           (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("VMExit: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_EXIT_INTR_INFO),
+           (uint32_t)vmr(VM_EXIT_INTR_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("        reason=%08x qualification=%08x\n",
+           (uint32_t)vmr(VM_EXIT_REASON),
+           (uint32_t)vmr(EXIT_QUALIFICATION));
+    kdbp("IDTVectoring: info=%08x errcode=%08x\n",
+           (uint32_t)vmr(IDT_VECTORING_INFO),
+           (uint32_t)vmr(IDT_VECTORING_ERROR_CODE));
+    kdbp("TPR Threshold = 0x%02x\n",
+           (uint32_t)vmr(TPR_THRESHOLD));
+    kdbp("EPT pointer = 0x%08x%08x\n",
+           (uint32_t)vmr(EPT_POINTER_HIGH), (uint32_t)vmr(EPT_POINTER));
+    kdbp("Virtual processor ID = 0x%04x\n",
+           (uint32_t)vmr(VIRTUAL_PROCESSOR_ID));
+    kdbp("=================================================================\n");
+}
+
+/* Flush VMCS on this cpu if it needs to: 
+ *   - Upon leaving kdb, the HVM cpu will resume in vmx_vmexit_handler() and 
+ *     do __vmreads. So, the VMCS pointer can't be left cleared.
+ *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
+ *     vmlaunch must be done and not vmresume. This means, we must clear 
+ *     arch_vmx->launched.
+ */
+void kdb_curr_cpu_flush_vmcs(void)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    int ccpu = smp_processor_id();
+    struct vmcs_struct *cvp = this_cpu(current_vmcs);
+
+    if (this_cpu(current_vmcs) == NULL)
+        return;             /* no HVM active on this CPU */
+
+    kdbp("KDB:[%d] curvmcs:%lx/%lx\n", ccpu, cvp, virt_to_maddr(cvp));
+
+    /* looks like we got one. unfortunately, current_vmcs points to vmcs 
+     * and not VCPU, so we gotta search the entire list... */
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        for_each_vcpu (dp, vp) {
+            if ( vp->arch.hvm_vmx.vmcs == cvp ) {
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched = 0;
+                this_cpu(current_vmcs) = NULL;
+                kdbp("KDB:[%d] %d:%d current_vmcs:%lx flushed\n", 
+		     ccpu, dp->domain_id, vp->vcpu_id, cvp, virt_to_maddr(cvp));
+            }
+        }
+    }
+}
+
+/*
+ * domid == 0 : display for all HVM domains  (dom0 is never an HVM domain)
+ * vcpu id == -1 : display all vcpuids
+ * PreCondition: all HVM cpus (including current cpu) have flushed VMCS
+ */
+void kdb_dump_vmcs(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    struct vmcs_struct  *vmcsp;
+    u64 addr = -1;
+
+    ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
+    __vmptrst(&addr);
+
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+	    vmcsp = vp->arch.hvm_vmx.vmcs;
+            kdbp("VMCS %lx/%lx [domid:%d (%p)  vcpu:%d (%p)]:\n", vmcsp,
+	         virt_to_maddr(vmcsp), dp->domain_id, dp, vp->vcpu_id, vp);
+            __vmptrld(virt_to_maddr(vmcsp));
+            kdb_print_vmcs(vp);
+            __vmpclear(virt_to_maddr(vmcsp));
+            vp->arch.hvm_vmx.launched = 0;
+        }
+        kdbp("\n");
+    }
+    /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
+    if (addr && addr != (u64)-1)
+        __vmptrld(addr);
+}
+#endif
 
 /*
  * Local variables:
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2183,11 +2183,14 @@ static void vmx_failed_vmentry(unsigned 
         printk("reason not known yet!");
         break;
     }
-
+#if defined(XEN_KDB_CONFIG)
+    kdbp("\n************* VMCS Area **************\n");
+    kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
-
+#endif
     domain_crash(curr->domain);
 }
 
@@ -2415,6 +2418,12 @@ void vmx_vmexit_handler(struct cpu_user_
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
+
+#if defined(XEN_KDB_CONFIG)
+            /* TRAP_debug: IP points correctly to next instr */
+            if (kdb_handle_trap_entry(vector, regs))
+                break;
+#endif
             domain_pause_for_debugger();
             break;
         case TRAP_int3: 
@@ -2423,6 +2432,13 @@ void vmx_vmexit_handler(struct cpu_user_
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
+#if defined(XEN_KDB_CONFIG)
+                /* vmcs.IP points to bp, kdb expects bp+1. Hence after the above
+                 * update_guest_eip which updates to bp+1. works for gdbsx too 
+                 */
+                if (kdb_handle_trap_entry(vector, regs))
+                    break;
+#endif
                 current->arch.gdbsx_vcpu_event = TRAP_int3;
                 domain_pause_for_debugger();
                 break;
@@ -2707,6 +2723,10 @@ void vmx_vmexit_handler(struct cpu_user_
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
+#if defined(XEN_KDB_CONFIG)
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+            break;
+#endif
         if ( v->arch.hvm_vcpu.single_step ) {
           hvm_memory_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/irq.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2305,3 +2305,29 @@ bool_t hvm_domain_use_pirq(const struct 
     return is_hvm_domain(d) && pirq &&
            pirq->arch.hvm.emuirq != IRQ_UNBOUND; 
 }
+
+#ifdef XEN_KDB_CONFIG
+void kdb_prnt_guest_mapped_irqs(void)
+{
+    int irq, j;
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    kdbp("irq  vec  aff  type  domid:mapped-pirq pairs  (all in decimal)\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+        irq_guest_action_t *actp = (irq_guest_action_t *)dp->action;
+
+        if (!dp->handler ||dp->handler==&no_irq_type || !(dp->status&IRQ_GUEST))
+            continue;
+
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %3d %3s %-13s ", irq, archp->vector, affstr,
+             dp->handler->typename);
+        for (j=0; j < actp->nr_guests; j++)
+            kdbp("%03d:%04d ", actp->guest[j]->domain_id,
+                 domain_irq_to_pirq(actp->guest[j], irq));
+        kdbp("\n");
+    }
+}
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/setup.c	Fri Jun 08 10:56:24 2012 -0700
@@ -47,6 +47,13 @@
 #include <xen/cpu.h>
 #include <asm/nmi.h>
 
+#ifdef XEN_KDB_CONFIG
+#include <asm/debugger.h>
+
+int opt_earlykdb=0;
+boolean_param("earlykdb", opt_earlykdb);
+#endif
+
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
 boolean_param("nosmp", opt_nosmp);
@@ -1242,6 +1249,11 @@ void __init __start_xen(unsigned long mb
 
     trap_init();
 
+#ifdef XEN_KDB_CONFIG
+    kdb_init();
+    if (opt_earlykdb)
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+#endif
     rcu_init();
     
     early_time_init();
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/smp.c
--- a/xen/arch/x86/smp.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/smp.c	Fri Jun 08 10:56:24 2012 -0700
@@ -273,7 +273,7 @@ void smp_send_event_check_mask(const cpu
  * Structure and data for smp_call_function()/on_selected_cpus().
  */
 
-static void __smp_call_function_interrupt(void);
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs);
 static DEFINE_SPINLOCK(call_lock);
 static struct call_data_struct {
     void (*func) (void *info);
@@ -321,7 +321,7 @@ void on_selected_cpus(
     if ( cpumask_test_cpu(smp_processor_id(), &call_data.selected) )
     {
         local_irq_disable();
-        __smp_call_function_interrupt();
+        __smp_call_function_interrupt(NULL);
         local_irq_enable();
     }
 
@@ -390,7 +390,7 @@ void event_check_interrupt(struct cpu_us
     this_cpu(irq_count)++;
 }
 
-static void __smp_call_function_interrupt(void)
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs)
 {
     void (*func)(void *info) = call_data.func;
     void *info = call_data.info;
@@ -411,6 +411,11 @@ static void __smp_call_function_interrup
     {
         mb();
         cpumask_clear_cpu(cpu, &call_data.selected);
+#ifdef XEN_KDB_CONFIG
+        if (info && !strcmp(info, "XENKDB")) {           /* called from kdb */
+                (*(void (*)(struct cpu_user_regs *, void *))func)(regs, info);
+        } else
+#endif
         (*func)(info);
     }
 
@@ -421,5 +426,5 @@ void call_function_interrupt(struct cpu_
 {
     ack_APIC_irq();
     perfc_incr(ipis);
-    __smp_call_function_interrupt();
+    __smp_call_function_interrupt(regs);
 }
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/time.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2007,6 +2007,46 @@ static int __init setup_dump_softtsc(voi
 }
 __initcall(setup_dump_softtsc);
 
+#ifdef XEN_KDB_CONFIG
+void kdb_time_resume(int update_domains)
+{
+        s_time_t now;
+        int ccpu = smp_processor_id();
+        struct cpu_time *t = &this_cpu(cpu_time);
+
+        if (!plt_src.read_counter)            /* not initialized for earlykdb */
+                return;
+
+        if (update_domains) {
+                plt_stamp = plt_src.read_counter();
+                platform_timer_stamp = plt_stamp64;
+                platform_time_calibration();
+                do_settime(get_cmos_time(), 0, read_platform_stime());
+        }
+        if (local_irq_is_enabled())
+                kdbp("kdb BUG: enabled in time_resume(). ccpu:%d\n", ccpu);
+
+        rdtscll(t->local_tsc_stamp);
+        now = read_platform_stime();
+        t->stime_master_stamp = now;
+        t->stime_local_stamp  = now;
+
+        update_vcpu_system_time(current);
+
+        if (update_domains)
+                set_timer(&calibration_timer, NOW() + EPOCH);
+}
+
+void kdb_dump_time_pcpu(void)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        kdbp("[%d]: cpu_time: %016lx\n", cpu, &per_cpu(cpu_time, cpu));
+        kdbp("[%d]: cpu_calibration: %016lx\n", cpu, 
+             &per_cpu(cpu_calibration, cpu));
+    }
+}
+#endif
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/traps.c	Fri Jun 08 10:56:24 2012 -0700
@@ -225,7 +225,7 @@ static void show_trace(struct cpu_user_r
 
 #else
 
-static void show_trace(struct cpu_user_regs *regs)
+void show_trace(struct cpu_user_regs *regs)
 {
     unsigned long *frame, next, addr, low, high;
 
@@ -3326,6 +3326,10 @@ void do_nmi(struct cpu_user_regs *regs)
     if ( nmi_callback(regs, cpu) )
         return;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_enabled && kdb_handle_trap_entry(TRAP_nmi, regs))
+        return;
+#endif
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
 
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/x86_64/compat/entry.S
--- a/xen/arch/x86/x86_64/compat/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/compat/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -95,6 +95,10 @@ compat_skip_clobber:
 /* %rbx: struct vcpu */
 ENTRY(compat_test_all_events)
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG
+        testl $1, kdb_session_begun(%rip)
+        jnz   compat_restore_all_guest
+#endif
 /*compat_test_softirqs:*/
         movl  VCPU_processor(%rbx),%eax
         shlq  $IRQSTAT_shift,%rax
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/x86_64/entry.S
--- a/xen/arch/x86/x86_64/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -184,6 +184,10 @@ skip_clobber:
 /* %rbx: struct vcpu */
 test_all_events:
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG                   /* 64bit dom0 will resume here */
+        testl $1, kdb_session_begun(%rip)
+        jnz   restore_all_guest
+#endif
 /*test_softirqs:*/  
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
@@ -546,6 +550,13 @@ ENTRY(debug)
 
 ENTRY(int3)
         pushq $0
+#ifdef XEN_KDB_CONFIG
+        pushq %rax
+        GET_CPUINFO_FIELD(CPUINFO_processor_id, %rax)
+        movq  (%rax), %rax
+        lock  bts %rax, kdb_cpu_traps(%rip)
+        popq  %rax
+#endif
         movl  $TRAP_int3,4(%rsp)
         jmp   handle_exception
 
diff -r 32034d1914a6 -r e4b01842b71c xen/common/domain.c
--- a/xen/common/domain.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/domain.c	Fri Jun 08 10:56:24 2012 -0700
@@ -530,6 +530,14 @@ void domain_shutdown(struct domain *d, u
 {
     struct vcpu *v;
 
+#ifdef XEN_KDB_CONFIG
+    if (reason == SHUTDOWN_crash) {
+        if ( IS_PRIV(d) )
+            kdb_trap_immed(KDB_TRAP_FATAL);
+        else
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+    }
+#endif
     spin_lock(&d->shutdown_lock);
 
     if ( d->shutdown_code == -1 )
@@ -624,7 +632,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* send VIRQ_DEBUGGER to guest only if gdbsx_vcpu_event is not active */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r 32034d1914a6 -r e4b01842b71c xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/sched_credit.c	Fri Jun 08 10:56:24 2012 -0700
@@ -1475,6 +1475,33 @@ csched_dump_vcpu(struct csched_vcpu *svc
     printk("\n");
 }
 
+#ifdef XEN_KDB_CONFIG
+static void kdb_csched_dump(int cpu)
+{
+    struct csched_pcpu *pcpup = CSCHED_PCPU(cpu);
+    struct vcpu *scurrvp = (CSCHED_VCPU(current))->vcpu;
+    struct list_head *tmp, *runq = RUNQ(cpu);
+
+    kdbp("    csched_pcpu: %p\n", pcpup);
+    kdbp("    curr csched:%p {vcpu:%p id:%d domid:%d}\n", (current)->sched_priv,
+         scurrvp, scurrvp->vcpu_id, scurrvp->domain->domain_id);
+    kdbp("    runq:\n");
+
+    /* next is top of struct, so screw stupid, ugly hard to follow macros */
+    if (offsetof(struct csched_vcpu, runq_elem.next) != 0) {
+        kdbp("next is not first in struct csched_vcpu. please fixme\n");
+        return;        /* otherwise for loop will crash */
+    }
+    for (tmp = runq->next; tmp != runq; tmp = tmp->next) {
+
+        struct csched_vcpu *csp = (struct csched_vcpu *)tmp;
+        struct vcpu *vp = csp->vcpu;
+        kdbp("      csp:%p pri:%02d vcpu: {p:%p id:%d domid:%d}\n", csp,
+             csp->pri, vp, vp->vcpu_id, vp->domain->domain_id);
+    };
+}
+#endif
+
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
@@ -1484,6 +1511,10 @@ csched_dump_pcpu(const struct scheduler 
     int loop;
 #define cpustr keyhandler_scratch
 
+#ifdef XEN_KDB_CONFIG
+    kdb_csched_dump(cpu);
+    return;
+#endif
     spc = CSCHED_PCPU(cpu);
     runq = &spc->runq;
 
diff -r 32034d1914a6 -r e4b01842b71c xen/common/schedule.c
--- a/xen/common/schedule.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/schedule.c	Fri Jun 08 10:56:24 2012 -0700
@@ -1454,6 +1454,25 @@ void wait(void)
     schedule();
 }
 
+#ifdef XEN_KDB_CONFIG
+void kdb_print_sched_info(void)
+{
+    int cpu;
+
+    kdbp("Scheduler: name:%s opt_name:%s id:%d\n", ops.name, ops.opt_name,
+         ops.sched_id);
+    kdbp("per cpu schedule_data:\n");
+    for_each_online_cpu(cpu) {
+        struct schedule_data *p =  &per_cpu(schedule_data, cpu);
+        kdbp("  cpu:%d  &(per cpu)schedule_data:%p\n", cpu, p);
+        kdbp("         curr:%p sched_priv:%p\n", p->curr, p->sched_priv);
+        kdbp("\n");
+        ops.dump_cpu_state(&ops, cpu);
+        kdbp("\n");
+    }
+}
+#endif
+
 #ifdef CONFIG_COMPAT
 #include "compat/schedule.c"
 #endif
diff -r 32034d1914a6 -r e4b01842b71c xen/common/symbols.c
--- a/xen/common/symbols.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/symbols.c	Fri Jun 08 10:56:24 2012 -0700
@@ -168,3 +168,21 @@ void __print_symbol(const char *fmt, uns
 
     spin_unlock_irqrestore(&lock, flags);
 }
+
+#ifdef XEN_KDB_CONFIG
+/*
+ *  * Given a symbol, return its address 
+ *   */
+unsigned long address_lookup(char *symp)
+{
+    int i, off = 0;
+    char namebuf[KSYM_NAME_LEN+1];
+
+    for (i=0; i < symbols_num_syms; i++) {
+        off = symbols_expand_symbol(off, namebuf);
+        if (strcmp(namebuf, symp) == 0)                  /* found it */
+            return symbols_address(i);
+    }
+    return 0;
+}
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/common/timer.c
--- a/xen/common/timer.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/timer.c	Fri Jun 08 10:56:24 2012 -0700
@@ -643,6 +643,48 @@ void __init timer_init(void)
     register_keyhandler('a', &dump_timerq_keyhandler);
 }
 
+#ifdef XEN_KDB_CONFIG
+#include <xen/symbols.h>
+void kdb_dump_timer_queues(void)
+{
+    struct timer  *t;
+    struct timers *ts;
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1];
+    int cpu, j;
+    u64 tsc;
+
+    for_each_online_cpu( cpu )
+    {
+        ts = &per_cpu(timers, cpu);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
+
+        /* timers in the heap */
+        for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
+            t = ts->heap[j];
+            kdbp("  %d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+        /* timers on the link list */
+        for ( t = ts->list, j = 0; t != NULL; t = t->list_next, j++ ) {
+            kdbp(" L%d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+    }
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 -r e4b01842b71c xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/char/console.c	Fri Jun 08 10:56:24 2012 -0700
@@ -295,6 +295,21 @@ static void serial_rx(char c, struct cpu
 {
     static int switch_code_count = 0;
 
+#ifdef XEN_KDB_CONFIG
+    /* if ctrl-\ pressed and kdb handles it, return */
+    if (kdb_enabled && c == 0x1c) {
+        if (!kdb_session_begun) {
+            if (kdb_keyboard(regs))
+                return;
+        } else {
+            kdbp("Sorry... kdb session already active.. please try again..\n");
+            return;
+        }
+    }
+    if (kdb_session_begun)      /* kdb should already be polling */
+        return;                 /* swallow chars so they don't buffer in dom0 */
+#endif
+
     if ( switch_code && (c == switch_code) )
     {
         /* We eat CTRL-<switch_char> in groups of 3 to switch console input. */
@@ -710,6 +725,18 @@ void console_end_sync(void)
     atomic_dec(&print_everything);
 }
 
+#ifdef XEN_KDB_CONFIG
+void console_putc(char c)
+{
+    serial_putc(sercon_handle, c);
+}
+
+int console_getc(void)
+{
+    return serial_getc(sercon_handle);
+}
+#endif
+
 /*
  * printk rate limiting, lifted from Linux.
  *
diff -r 32034d1914a6 -r e4b01842b71c xen/include/asm-x86/debugger.h
--- a/xen/include/asm-x86/debugger.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/asm-x86/debugger.h	Fri Jun 08 10:56:24 2012 -0700
@@ -39,7 +39,11 @@
 #define DEBUGGER_trap_fatal(_v, _r) \
     if ( debugger_trap_fatal(_v, _r) ) return;
 
-#if defined(CRASH_DEBUG)
+#if defined(XEN_KDB_CONFIG)
+#define debugger_trap_immediate() kdb_trap_immed(KDB_TRAP_NONFATAL)
+#define debugger_trap_fatal(_v, _r) kdb_trap_fatal(_v, _r)
+
+#elif defined(CRASH_DEBUG)
 
 #include <xen/gdbstub.h>
 
@@ -70,6 +74,10 @@ static inline int debugger_trap_entry(
 {
     struct vcpu *v = current;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_handle_trap_entry(vector, regs))
+        return 1;
+#endif
     if ( guest_kernel_mode(v, regs) && v->domain->debugger_attached &&
          ((vector == TRAP_int3) || (vector == TRAP_debug)) )
     {
diff -r 32034d1914a6 -r e4b01842b71c xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/lib.h	Fri Jun 08 10:56:24 2012 -0700
@@ -116,4 +116,7 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+#ifdef XEN_KDB_CONFIG
+#include "../../kdb/include/kdb_extern.h"
+#endif
 #endif /* __LIB_H__ */
diff -r 32034d1914a6 -r e4b01842b71c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/sched.h	Fri Jun 08 10:56:24 2012 -0700
@@ -576,11 +576,14 @@ extern void (*dead_idle) (void);
 unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
-
+#ifdef XEN_KDB_CONFIG
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,5 @@
+
+obj-y		+= kdbmain.o kdb_cmds.o kdb_io.o 
+
+subdir-y += x86 guest
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/README	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,243 @@
+
+Welcome to kdb for xen, a hypervisor built in debugger.
+
+FEATURES:
+   - set breakpoints in hypervisor
+   - examine virt/machine memory, registers, domains, vcpus, etc...
+   - single step, single step till jump/call, step over call to next
+     instruction after the call.
+   - examine memory of a PV/HVM guest. 
+   - set breakpoints, single step, etc... for a PV guest.
+   - breaking into the debugger will freeze the system, all CPUs will pause,
+     no interrupts are acknowledged in the debugger. (Hence, the wall clock
+     will drift)
+   - single step will step only that cpu.
+   - earlykdb: break into kdb very early during boot. Put "earlykdb" on the
+               xen command line in grub.conf.
+   - generic tracing functions (see below) for quick tracing to debug timing
+     related problems. To use:
+        o set KDBTRCMAX to max num of recs in circular trc buffer in kdbmain.c
+	o call kdb_trc() from anywhere in xen
+	o turn tracing on by setting kdb_trcon in kdbmain.c or trcon command.
+	o trcp in kdb will give hints to dump trace recs. Use dd to see buffer
+	o trcz will zero out the entire buffer if needed.
+
+NOTE:
+   - since almost all numbers are in hex, 0x is not prefixed. Instead, decimal
+     numbers are preceded by $, as in $17 (sorry, one gets used to it). Note,
+     vcpu num, cpu num, domid are always displayed in decimal, without $.
+   - watchdog must be disabled to use kdb
+
+ISSUES:
+   - Currently, debug hypervisor is not supported. Make sure NDEBUG is defined
+     or compile with debug=n
+   - "timer went backwards" messages on dom0, but kdb/hyp should be fine.
+     I usually do "echo 2 > /proc/sys/kernel/printk" when using kdb.
+   - 32bit hypervisor may hang. Tested on 64bit hypervisor only.
+    
+
+TO BUILD:
+ - do >make kdb=y
+
+HOW TO USE:
+  1. A serial line is needed to use the debugger. Set up a serial line
+     from the source machine to target victim. Make sure the serial line
+     is working properly by displaying login prompt and loging in etc....
+
+  2. Add following to grub.conf:
+        kernel /xen.kdb console=com1,vga com1=57600,8n1 dom0_mem=542M
+
+        (57600 or whatever used in step 1 above)
+
+  3. Boot the hypervisor built with the debugger. 
+
+  4. ctrl-\ (ctrl and backslash) will break into the debugger. If the system is
+     badly hung, pressing NMI would also break into it. However, once kdb is
+     entered via NMI, normal execution can't continue.
+
+  5. type 'h' for list of commands.
+
+  6. Command line editing is limited to backspace. ctrl-c to start a new cmd.
+
+
+
+GUEST debug:
+  - type sym in the debugger
+  - for REL4, grep kallsyms_names, kallsyms_addresses, and kallsyms_num_syms
+    in the guest System.map* file. Run sym again with domid and the three
+    values on the command line.
+  - Now basic symbols can be used for guest debug. Note, if the binary is not
+    built with symbols, only function names are available, but not global vars.
+
+    Eg: sym 0 c0696084 c068a590 c0696080 c06b43e8 c06b4740
+        will set symbols for dom 0. Then :
+
+        [4]xkdb> bp some_function 0
+
+	wills set bp at some_function in dom 0
+
+	[3]xkdb> dw c068a590 32 0 : display 32 bytes of dom0 memory
+
+
+Tips:
+  - In "[0]xkdb>"  : 0 is the cpu number in decimal
+  - In
+      00000000c042645c: 0:do_timer+17                  push %ebp
+    0:do_timer : 0 is the domid in hex
+    offset +17 is in hex.
+
+    absense of 0: would indicate it's a hypervisor function
+
+  - commands starting with kdb (kdb*) are for kdb debug only.
+
+
+Finally,
+ - think hex.
+ - bug/problem: enter kdbdbg, reproduce, and send me the output.
+   If the output is not enough, I may ask to run kdbdbg twice, then collect
+   output.
+
+
+Thanks,
+Mukesh Rathor
+Oracle Corporatin, 
+Redwood Shores, CA 94065
+
+--------------------------------------------------------------------------------
+COMMAND DESCRIPTION:
+
+info:  Print basic info like version, compile flags, etc..
+
+cur:  print current domain id and vcpu id
+
+f: display current stack. If a vcpu ptr is given, then print stack for that
+   VCPU by using its IP and SP.
+
+fg: display stack for a guest given domid, SP and IP.
+
+dw: display words of memory. 'num' of bytes is optional, but if displaying guest
+    memory, then is required.
+
+dd: same as above, but display doublewords.
+
+dwm: same as above but the address is machine address instead of virtual.
+
+ddm: same as above, but display doublewords.
+
+dr: display registers. if 'sp' is specified then print few extra registers.
+
+drg: display guest context saved on stack bottom.
+
+dis: disassemble instructions. If disassembling for guest, then 'num' must
+     be specified. 'num' is number of instrs to display.
+
+dism: toggle disassembly mode between Intel and ATT/GAS.
+
+mw: modify word in memory given virtual address. 'domid' may be specified if
+    modifying guest memory. value is assumed in hex even without 0x.
+
+md: same as above but modify doubleword.
+
+mr: modify register. value is assumd hex.
+
+bc: clear given or all breakpoints
+
+bp: display breakpoints or set a breakpoint. Domid may be specified to set a bp
+    in guest. kdb functions may not be specified if debugging kdb.
+    Example:
+      xkdb> bp acpi_processor_idle  : will set bp in xen
+      xkdb> bp default_idle 0 :   will set bp in domid 0
+      xkdb> bp idle_cpu 9 :   will set bp in domid 9
+
+     Conditions may be specified for a bp: lhs == rhs or lhs != rhs
+     where : lhs is register like 'r6', 'rax', etc...  or memory location
+             rhs is hex value with or without leading 0x.
+     Thus,
+      xkdb> bp acpi_processor_idle rdi == c000 
+      xkdb> bp 0xffffffff80062ebc 0 rsi == ffff880021edbc98 : will break into
+            kdb at 0xffffffff80062ebc in dom0 when rsi is ffff880021edbc98 
+
+btp: break point trace. Upon bp, print some info and continue without stopping.
+   Ex: btp idle_cpu 7 rax rbx 0x20ef5a5 r9
+
+   will print: rax, rbx, *(long *)0x20ef5a5, r9 upon hitting idle_cpu() and 
+               continue.
+
+wp: set a watchpoint at a virtual address which can belong to hypervisor or
+    any guest. Do not specify wp in kdb path if debugging kdb.
+
+wc: clear given or all watchpoints.
+
+ni: single step, stepping over function calls.
+
+ss: single step. Be carefull when in interrupt handlers or context switches.
+    
+ssb: single step to branch. Use with care.
+
+go: leave kdb and continue.
+
+cpu: go back to orig cpu when entering kdb. If 'cpu number' given, then switch 
+     to that cpu. If 'all' then show status of all cpus.
+
+nmi: Only available in hung/crash state. Send NMI to a cpu that may be hung.
+
+sym: Initialize a symbol table for debugging a guest. Look into the System.map
+     file of guest for certain symbol values and provide them here.
+
+vcpuh: Given vcpu ptr, display hvm_vcpu struct.
+
+vcpu: Display current vcpu struct. If 'vcpu-ptr' given, display that vcpu.
+
+dom: display current domain. If 'domid' then display that domid. If 'all', then
+     display all domains.
+
+sched: show schedular info and run queues.
+
+mmu: print basic mmu info
+
+p2m: convert a gpfn to mfn given a domid. value in hex even without 0x.
+
+m2p: convert mfn to pfn. value in hex even without 0x.
+
+dpage: display struct page given a mfn or struct page ptr. Since, no info is 
+       kept on page type, we display all possible page types.
+
+dtrq: display timer queues.
+
+didt: dump IDT table.
+
+dgt: dump GDT table.
+
+dirq: display IRQ bindings.
+
+dvmc: display all or given dom/vcpu VMCS or VMCB.
+
+trcon: turn tracing on. Trace hooks must be added in xen and kdb function
+       called directly from there.
+
+trcoff: turn tracing off.
+
+trcz: zero trace buffer.
+
+trcp: give hints to print the circular trace buffer, like current active ptr.
+
+usr1: allows to add any arbitraty command quickly.
+
+--------------------------------------------------------------------------------
+/*
+ * Copyright (C) 2008 Oracle.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/guest/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y           := kdb_guest.o
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/guest/kdb_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/kdb_guest.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,342 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+/* information for symbols for a guest (includeing dom 0 ) is saved here */
+struct gst_syminfo {           /* guest symbols info */
+    int   domid;               /* which domain */
+    int   bitness;             /* 32 or 64 */
+    void *addrtblp;            /* ptr to (32/64)addresses tbl */
+    u8   *toktbl;              /* ptr to kallsyms_token_table */
+    u16  *tokidxtbl;           /* ptr to kallsyms_token_index */
+    u8   *kallsyms_names;      /* ptr to kallsyms_names */
+    long  kallsyms_num_syms;   /* ptr to kallsyms_num_syms */
+    kdbva_t  stext;            /* value of _stext in guest */
+    kdbva_t  etext;            /* value of _etext in guest */
+    kdbva_t  sinittext;        /* value of _sinittext in guest */
+    kdbva_t  einittext;        /* value of _einittext in guest */
+};
+
+#define MAX_CACHE 16                              /* cache upto 16 guests */
+struct gst_syminfo gst_syminfoa[MAX_CACHE];       /* guest symbol info array */
+
+static struct gst_syminfo *
+kdb_get_syminfo_slot(void)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].addrtblp == NULL)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+static struct gst_syminfo *
+kdb_domid2syminfop(domid_t domid)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].domid == domid)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+/* check if an address looks like text address in guest */
+int
+kdb_is_addr_guest_text(kdbva_t addr, int domid)
+{
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    if (!gp || !gp->stext || !gp->etext)
+        return 0;
+    KDBGP1("guestaddr: addr:%lx domid:%d\n", addr, domid);
+
+    return ( (addr >= gp->stext && addr <= gp->etext) ||
+             (addr >= gp->sinittext && addr <= gp->einittext) );
+}
+
+/*
+ * returns: value of kallsyms_addresses[idx];
+ */
+static kdbva_t
+kdb_rd_guest_addrtbl(struct gst_syminfo *gp, int idx)
+{
+    kdbva_t addr, retaddr=0;
+    int num = gp->bitness/8;       /* whether 4 byte or 8 byte ptrs */
+    domid_t id = gp->domid;
+
+    addr = (kdbva_t)(((char *)gp->addrtblp) + idx * num);
+    KDBGP1("rdguestaddrtbl:addr:%lx idx:%d\n", addr, idx);
+
+    if (kdb_read_mem(addr, (kdbbyt_t *)&retaddr,num,id) != num) {
+        kdbp("Can't read addrtbl domid:%d at:%lx\n", id, addr);
+        return 0;
+    }
+    KDBGP1("rdguestaddrtbl:exit:retaddr:%lx\n", retaddr);
+    return retaddr;
+}
+
+/* Based on el5 kallsyms.c file. */
+static unsigned int 
+kdb_expand_el5_sym(struct gst_syminfo *gp, unsigned int off, char *result)
+{   
+    int len, skipped_first = 0;
+    u8 u8idx, *tptr, *datap;
+    domid_t domid = gp->domid;
+
+    *result = '\0';
+
+    /* get the compressed symbol length from the first symbol byte */
+    datap = gp->kallsyms_names + off;
+    len = 0;
+    if ((kdb_read_mem((kdbva_t)datap, (kdbbyt_t *)&len, 1, domid)) != 1) {
+        KDBGP("failed to read guest memory\n");
+        return 0;
+    }
+    datap++;
+
+    /* update the offset to return the offset for the next symbol on
+     * the compressed stream */
+    off += len + 1;
+
+    /* for every byte on the compressed symbol data, copy the table
+     * entry for that byte */
+    while(len) {
+        u16 u16idx, *u16p;
+        if (kdb_read_mem((kdbva_t)datap,(kdbbyt_t *)&u8idx,1,domid)!=1){
+            kdbp("memory (u8idx) read error:%p\n",gp->tokidxtbl);
+            return 0;
+        }
+        u16p = u8idx + gp->tokidxtbl;
+        if (kdb_read_mem((kdbva_t)u16p,(kdbbyt_t *)&u16idx,2,domid)!=2){
+            kdbp("tokidxtbl read error:%p\n", u16p);
+            return 0;
+        }
+        tptr = gp->toktbl + u16idx;
+        datap++;
+        len--;
+
+        while ((kdb_read_mem((kdbva_t)tptr, (kdbbyt_t *)&u8idx, 1, domid)==1) &&
+               u8idx) {
+
+            if(skipped_first) {
+                *result = u8idx;
+                result++;
+            } else
+                skipped_first = 1;
+            tptr++;
+        }
+    }
+    *result = '\0';
+    return off;          /* return to offset to the next symbol */
+}
+
+#define EL4_NMLEN 127
+/* so much pain, so not sure of it's worth .. :).. */
+static kdbva_t
+kdb_expand_el4_sym(struct gst_syminfo *gp, int low, char *result, char *symp)
+{   
+    int i, j;
+    u8 *nmp = gp->kallsyms_names;       /* guest address space */
+    kdbbyt_t byte, prefix;
+    domid_t id = gp->domid;
+    kdbva_t addr;
+
+    KDBGP1("Eel4sym:nmp:%p maxidx:$%d sym:%s\n", nmp, low, symp);
+    for (i=0; i <= low; i++) {
+        /* unsigned prefix = *name++; */
+        if (kdb_read_mem((kdbva_t)nmp, &prefix, 1, id) != 1) {
+            kdbp("failed to read:%p domid:%x\n", nmp, id);
+            return 0;
+        }
+        KDBGP2("el4:i:%d prefix:%x\n", i, prefix);
+        nmp++;
+        /* strncpy(namebuf + prefix, name, KSYM_NAME_LEN - prefix); */
+        addr = (long)result + prefix;
+        for (j=0; j < EL4_NMLEN-prefix; j++) {
+            if (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) != 1) {
+                kdbp("failed read:%p domid:%x\n", nmp, id);
+                return 0;
+            }
+            KDBGP2("el4:j:%d byte:%x\n", j, byte);
+            *(kdbbyt_t *)addr = byte;
+            addr++; nmp++;
+            if (byte == '\0')
+                break;
+        }
+        KDBGP2("el4sym:i:%d res:%s\n", i, result);
+        if (symp && strcmp(result, symp) == 0)
+            return(kdb_rd_guest_addrtbl(gp, i));
+
+        /* kallsyms.c: name += strlen(name) + 1; */
+        if (j == EL4_NMLEN-prefix && byte != '\0')
+            while (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) && byte != '\0')
+                nmp++;
+    }
+    KDBGP1("Xel4sym: na-ga-da\n");
+    return 0;
+}
+
+static unsigned int
+kdb_get_el5_symoffset(struct gst_syminfo *gp, long pos)
+{
+    int i;
+    u8 data, *namep;
+    domid_t domid = gp->domid;
+
+    namep = gp->kallsyms_names;
+    for (i=0; i < pos; i++) {
+        if (kdb_read_mem((kdbva_t)namep, &data, 1, domid) != 1) {
+            kdbp("Can't read id:$%d mem:%p\n", domid, namep);
+            return 0;
+        }
+        namep = namep + data + 1;
+    }
+    return namep - gp->kallsyms_names;
+}
+
+/*
+ * for a given guest domid (domid >= 0 && < KDB_HYPDOMID), convert addr to
+ * symbol. offset is set to  addr - symbolstart
+ */
+char *
+kdb_guest_addr2sym(unsigned long addr, domid_t domid, ulong *offsp)
+{
+    static char namebuf[KSYM_NAME_LEN+1];
+    unsigned long low, high, mid;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    *offsp = 0;
+    if(!gp || gp->kallsyms_num_syms == 0)
+        return " ??? ";
+
+    namebuf[0] = namebuf[KSYM_NAME_LEN] = '\0';
+    if (1) {
+        /* do a binary search on the sorted kallsyms_addresses array */
+        low = 0;
+        high = gp->kallsyms_num_syms;
+
+        while (high-low > 1) {
+            mid = (low + high) / 2;
+            if (kdb_rd_guest_addrtbl(gp, mid) <= addr) 
+                low = mid;
+            else 
+                high = mid;
+        }
+        /* Grab name */
+        if (gp->toktbl) {
+            int symoff = kdb_get_el5_symoffset(gp,low);
+            kdb_expand_el5_sym(gp, symoff, namebuf);
+        } else
+            kdb_expand_el4_sym(gp, low, namebuf, NULL);
+        *offsp = addr - kdb_rd_guest_addrtbl(gp, low);
+        return namebuf;
+    }
+    return " ???? ";
+}
+
+
+/* 
+ * save guest (dom0 and others) symbols info : domid and following addresses:
+ *     &kallsyms_names &kallsyms_addresses &kallsyms_num_syms \
+ *     &kallsyms_token_table &kallsyms_token_index
+ */
+void
+kdb_sav_dom_syminfo(domid_t domid, long namesp, long addrap, long nump,
+                    long toktblp, long tokidxp)
+{
+    int bytes;
+    long val = 0;    /* must be set to zero for 32 on 64 cases */
+    struct gst_syminfo *gp = kdb_get_syminfo_slot();
+
+    if (gp == NULL) {
+        kdbp("kdb:kdb_sav_dom_syminfo():Table full.. symbols not saved\n");
+        return;
+    }
+    memset(gp, 0, sizeof(*gp));
+
+    gp->domid = domid;
+    gp->bitness = kdb_guest_bitness(domid);
+    gp->addrtblp = (void *)addrap;
+    gp->kallsyms_names = (u8 *)namesp;
+    gp->toktbl = (u8 *)toktblp;
+    gp->tokidxtbl = (u16 *)tokidxp;
+
+    KDBGP("domid:%x bitness:$%d numsyms:$%ld arrayp:%p\n", domid,
+          gp->bitness, gp->kallsyms_num_syms, gp->addrtblp);
+
+    bytes = gp->bitness/8;
+    if (kdb_read_mem(nump, (kdbbyt_t *)&val, bytes, domid) != bytes) {
+
+        kdbp("Unable to read number of symbols from:%lx\n", nump);
+        memset(gp, 0, sizeof(*gp));
+        return;
+    } else
+        kdbp("Number of symbols:$%ld\n", val);
+
+    gp->kallsyms_num_syms = val;
+
+    bytes = (gp->bitness/8) * gp->kallsyms_num_syms;
+    gp->stext = kdb_guest_sym2addr("_stext", domid);
+    gp->etext = kdb_guest_sym2addr("_etext", domid);
+    if (!gp->stext || !gp->etext)
+        kdbp("Warn: Can't find stext/etext\n");
+
+    if (gp->toktbl && gp->tokidxtbl) {
+        gp->sinittext = kdb_guest_sym2addr("_sinittext", domid);
+        gp->einittext = kdb_guest_sym2addr("_einittext", domid);
+        if (!gp->sinittext || !gp->einittext) {
+            kdbp("Warn: Can't find sinittext/einittext\n");
+    } 
+    }
+    KDBGP1("stxt:%lx etxt:%lx sitxt:%lx eitxt:%lx\n", gp->stext, gp->etext,
+           gp->sinittext, gp->einittext);
+    kdbp("Succesfully saved symbol info\n");
+}
+
+/*
+ * given a symbol string for a guest/domid, return its address
+ */
+kdbva_t
+kdb_guest_sym2addr(char *symp, domid_t domid)
+{
+    char namebuf[KSYM_NAME_LEN+1];
+    int i, off=0;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    KDBGP("sym2a: sym:%s domid:%x numsyms:%ld\n", symp, domid,
+          gp ? gp->kallsyms_num_syms: -1);
+
+    if (!gp)
+        return 0;
+
+    if (gp->toktbl == 0 || gp->tokidxtbl == 0)
+        return(kdb_expand_el4_sym(gp, gp->kallsyms_num_syms, namebuf, symp));
+
+    for (i=0; i < gp->kallsyms_num_syms; i++) {
+        off = kdb_expand_el5_sym(gp, off, namebuf);
+        KDBGP1("i:%d namebuf:%s\n", i, namebuf);
+        if (strcmp(namebuf, symp) == 0) {
+            return(kdb_rd_guest_addrtbl(gp, i));
+        }
+    }
+    KDBGP("sym2a:exit:na-ga-da\n");
+    return 0;
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdb_extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdb_extern.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDB_EXTERN_H
+#define _KDB_EXTERN_H
+
+#define KDB_TRAP_FATAL     1    /* trap is fatal. can't resume from kdb */
+#define KDB_TRAP_NONFATAL  2    /* can resume from kdb */
+#define KDB_TRAP_KDBSTACK  3    /* to debug kdb itself. dump kdb stack */
+
+/* following can be called from anywhere in xen to debug */
+extern void kdb_trap_immed(int);
+extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
+extern void kdbp(const char *fmt, ...);
+
+typedef unsigned long kdbva_t;
+typedef unsigned char kdbbyt_t;
+typedef unsigned long kdbma_t;
+
+extern unsigned long kdb_dr7;
+
+
+extern volatile int kdb_session_begun;
+extern volatile int kdb_enabled;
+extern void kdb_init(void);
+extern int kdb_keyboard(struct cpu_user_regs *);
+extern void kdb_ssni_reenter(struct cpu_user_regs *);
+extern int kdb_handle_trap_entry(int, struct cpu_user_regs *);
+extern int kdb_trap_fatal(int, struct cpu_user_regs *);  /* fatal with regs */
+extern void kdb_dump_vmcs(uint16_t did, int vid);
+void kdb_dump_vmcb(uint16_t did, int vid);
+extern void kdb_dump_time_pcpu(void);
+
+
+#define VMPTRST_OPCODE  ".byte 0x0f,0xc7\n"     /* reg/opcode: /7 */
+#define MODRM_EAX_07    ".byte 0x38\n"          /* [EAX], with reg/opcode: /7 */
+static inline void __vmptrst(u64 *addr)
+{
+    asm volatile ( VMPTRST_OPCODE
+                   MODRM_EAX_07
+                   :
+                   : "a" (addr)
+                   : "memory");
+}
+
+extern void mukchk(unsigned long);
+#define is_hvm_or_hyb_domain is_hvm_domain
+#define is_hvm_or_hyb_vcpu is_hvm_vcpu
+
+
+#endif  /* _KDB_EXTERN_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdbdefs.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbdefs.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBDEFS_H
+#define _KDBDEFS_H
+
+/* reason we are entering kdbmain (bp == breakpoint) */
+typedef enum {
+    KDB_REASON_KEYBOARD=1,  /* Keyboard entry - always 1 */
+    KDB_REASON_BPEXCP,      /* #BP excp: sw bp (INT3) */
+    KDB_REASON_DBEXCP,      /* #DB excp: TF flag or HW bp */
+    KDB_REASON_PAUSE_IPI,   /* received pause IPI from another CPU */
+} kdb_reason_t;
+
+
+/* cpu state: past, present, and future */
+typedef enum {
+    KDB_CPU_INVAL=0,     /* invalid value. not in or leaving kdb */
+    KDB_CPU_QUIT,        /* main cpu does GO. all others do QUIT */
+    KDB_CPU_PAUSE,       /* cpu is paused */
+    KDB_CPU_DISABLE,     /* disable interrupts */
+    KDB_CPU_SHOWPC,      /* all cpus must display their pc */
+    KDB_CPU_DO_VMEXIT,   /* all cpus must do vmcs vmexit. intel only */
+    KDB_CPU_MAIN_KDB,    /* cpu in kdb main command loop */
+    KDB_CPU_GO,          /* user entered go for this cpu */
+    KDB_CPU_SS,          /* single step for this cpu */
+    KDB_CPU_NI,          /* go to next instr after the call instr */
+    KDB_CPU_INSTALL_BP,  /* delayed install of sw bp(s) by this cpu */
+} kdb_cpu_cmd_t;
+
+/* ============= kdb commands ============================================= */
+
+typedef kdb_cpu_cmd_t (*kdb_func_t)(int, const char **, struct cpu_user_regs *);
+typedef kdb_cpu_cmd_t (*kdb_usgf_t)(void);
+
+typedef enum {
+    KDB_REPEAT_NONE = 0,    /* Do not repeat this command */
+    KDB_REPEAT_NO_ARGS,     /* Repeat the command without arguments */
+    KDB_REPEAT_WITH_ARGS,   /* Repeat the command including its arguments */
+} kdb_repeat_t;
+
+typedef struct _kdbtab {
+    char        *kdb_cmd_name;        /* Command name */
+    kdb_func_t   kdb_cmd_func;        /* ptr to function to execute command */
+    kdb_usgf_t   kdb_cmd_usgf;        /* usage function ptr */
+    int          kdb_cmd_crash_avail; /* available in sys fatal/crash state */
+    kdb_repeat_t kdb_cmd_repeat;      /* Does command auto repeat on enter? */
+} kdbtab_t;
+
+
+/* ============= types and stuff ========================================= */
+#define BFD_INVAL (~0UL)            /* invalid bfd_vma */
+
+#if defined(__x86_64__)
+  #define KDBIP rip
+  #define KDBSP rsp
+#else
+  #define KDBIP eip
+  #define KDBSP esp
+#endif
+
+/* ============= macros ================================================== */
+extern volatile int kdbdbg;
+#define KDBGP(...) {(kdbdbg) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP3(...) {0;};
+
+#define KDBMIN(x,y) (((x)<(y))?(x):(y))
+
+#endif  /* !_KDBDEFS_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdbinc.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbinc.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBINC_H
+#define _KDBINC_H
+
+#include <xen/compile.h>
+#include <xen/config.h>
+#include <xen/version.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/mm.h>
+#include <xen/event.h>
+#include <xen/time.h>
+#include <xen/console.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/rangeset.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/delay.h>
+#include <xen/shutdown.h>
+#include <xen/percpu.h>
+#include <xen/multicall.h>
+#include <xen/rcupdate.h>
+#include <xen/ctype.h>
+#include <xen/symbols.h>
+#include <xen/shutdown.h>
+#include <xen/serial.h>
+#include <xen/grant_table.h>
+#include <asm/debugger.h>
+#include <asm/shared.h>
+#include <asm/apicdef.h>
+
+#include <asm/nmi.h>
+#include <asm/p2m.h>
+#include <asm/debugreg.h>
+#include <public/sched.h>
+#include <public/vcpu.h>
+#ifdef _XEN_LATEST
+#include <xsm/xsm.h>
+#endif
+
+#include <asm/hvm/vmx/vmx.h>
+
+#include "kdb_extern.h"
+#include "kdbdefs.h"
+#include "kdbproto.h"
+
+#endif /* !_KDBINC_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdbproto.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbproto.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBPROTO_H
+#define _KDBPROTO_H
+
+/* hypervisor interfaces use by kdb or kdb interfaces in xen files */
+extern void console_putc(char);
+extern int console_getc(void);
+extern void show_trace(struct cpu_user_regs *);
+extern void kdb_dump_timer_queues(void);
+extern void kdb_time_resume(int);
+extern void kdb_print_sched_info(void);
+extern void kdb_curr_cpu_flush_vmcs(void);
+extern unsigned long address_lookup(char *);
+extern void kdb_prnt_guest_mapped_irqs(void);
+
+/* kdb globals */
+extern kdbtab_t *kdb_cmd_tbl;
+extern char kdb_prompt[32];
+extern volatile int kdb_sys_crash;
+extern volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+extern volatile int kdb_trcon;
+
+/* kdb interfaces */
+extern void __init kdb_io_init(void);
+extern void kdb_init_cmdtab(void);
+extern void kdb_do_cmds(struct cpu_user_regs *);
+extern int kdb_check_sw_bkpts(struct cpu_user_regs *);
+extern int kdb_check_watchpoints(struct cpu_user_regs *);
+extern void kdb_do_watchpoints(kdbva_t, int, int);
+extern void kdb_install_watchpoints(void);
+extern void kdb_clear_wps(int);
+extern kdbma_t kdb_rd_dbgreg(int);
+
+
+
+extern char *kdb_get_cmdline(char *);
+extern void kdb_clear_prev_cmd(void);
+extern void kdb_toggle_dis_syntax(void);
+extern int kdb_check_call_instr(domid_t, kdbva_t);
+extern void kdb_display_pc(struct cpu_user_regs *);
+extern kdbva_t kdb_print_instr(kdbva_t, long, domid_t);
+extern int kdb_read_mmem(kdbva_t, kdbbyt_t *, int);
+extern int kdb_read_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+extern int kdb_write_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+
+extern void kdb_install_all_swbp(void);
+extern void kdb_uninstall_all_swbp(void);
+extern int kdb_swbp_exists(void);
+extern void kdb_flush_swbp_table(void);
+extern int kdb_is_addr_guest_text(kdbva_t, int);
+extern kdbva_t kdb_guest_sym2addr(char *, domid_t);
+extern char *kdb_guest_addr2sym(unsigned long, domid_t, ulong *);
+extern void kdb_prnt_addr2sym(domid_t, kdbva_t, char *);
+extern void kdb_sav_dom_syminfo(domid_t, long, long, long, long, long);
+extern int kdb_guest_bitness(domid_t);
+extern void kdb_nmi_pause_cpus(cpumask_t);
+
+extern void kdb_trczero(void);
+void kdb_trcp(void);
+
+
+
+#endif /* !_KDBPROTO_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/kdb_cmds.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_cmds.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3769 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+#if defined(__x86_64__)
+    #define KDBF64 "%lx"
+    #define KDBFL "%016lx"         /* print long all digits */
+#else
+    #define KDBF64 "%llx"
+    #define KDBFL "%08lx"
+#endif
+
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    #define KDB_LKDEF(l) ((l).raw.lock)
+    #define KDB_PGLLE(t) ((t).tail)    /* page list last element ^%$#@ */
+#else
+    #define KDB_LKDEF(l) ((l).lock)
+    #define KDB_PGLLE(t) ((t).prev)    /* page list last element ^%$#@ */
+#endif
+
+#define KDB_CMD_HISTORY_COUNT   32
+#define CMD_BUFLEN              200     /* kdb_printf: max printline == 256 */
+
+#define KDBMAXSBP 16                    /* max number of software breakpoints */
+#define KDB_MAXARGC 16                  /* max args in a kdb command */
+#define KDB_MAXBTP  8                   /* max display args in btp */
+
+/* condition is: 'r6 == 0x123f' or '0xffffffff82800000 != deadbeef'  */
+struct kdb_bpcond {
+    kdbbyt_t bp_cond_status;       /* 0 == off, 1 == register, 2 == memory */
+    kdbbyt_t bp_cond_type;         /* 0 == bad, 1 == equal, 2 == not equal */
+    ulong    bp_cond_lhs;          /* lhs of condition: reg offset or mem loc */
+    ulong    bp_cond_rhs;          /* right hand side of condition */
+};
+
+/* software breakpoint structure */
+struct kdb_sbrkpt {
+    kdbva_t  bp_addr;              /* address the bp is set at */
+    domid_t  bp_domid;             /* which domain the bp belongs to */
+    kdbbyt_t bp_originst;          /* save orig instr/s here */
+    kdbbyt_t bp_deleted;           /* delete pending on this bp */
+    kdbbyt_t bp_ni;                /* set for KDB_CPU_NI */
+    kdbbyt_t bp_just_added;        /* added in the current kdb session */
+    kdbbyt_t bp_type;              /* 0 = normal, 1 == cond,  2 == btp */
+    union {
+        struct kdb_bpcond bp_cond;
+        ulong *bp_btp;
+    } u;
+};
+
+/* don't use kmalloc in kdb which hijacks all cpus */
+static ulong kdb_btp_argsa[KDBMAXSBP][KDB_MAXBTP];
+static ulong *kdb_btp_ap[KDBMAXSBP];
+
+static struct kdb_reg_nmofs {
+    char *reg_nm;
+    int reg_offs;
+} kdb_reg_nm_offs[] =  {
+       { "rax", offsetof(struct cpu_user_regs, rax) },
+       { "rbx", offsetof(struct cpu_user_regs, rbx) },
+       { "rcx", offsetof(struct cpu_user_regs, rcx) },
+       { "rdx", offsetof(struct cpu_user_regs, rdx) },
+       { "rsi", offsetof(struct cpu_user_regs, rsi) },
+       { "rdi", offsetof(struct cpu_user_regs, rdi) },
+       { "rbp", offsetof(struct cpu_user_regs, rbp) },
+       { "rsp", offsetof(struct cpu_user_regs, rsp) },
+       { "r8",  offsetof(struct cpu_user_regs, r8) },
+       { "r9",  offsetof(struct cpu_user_regs, r9) },
+       { "r10", offsetof(struct cpu_user_regs, r10) },
+       { "r11", offsetof(struct cpu_user_regs, r11) },
+       { "r12", offsetof(struct cpu_user_regs, r12) },
+       { "r13", offsetof(struct cpu_user_regs, r13) },
+       { "r14", offsetof(struct cpu_user_regs, r14) },
+       { "r15", offsetof(struct cpu_user_regs, r15) },
+       { "rflags", offsetof(struct cpu_user_regs, rflags) } };
+
+static const int KDBBPSZ=1;                   /* size of KDB_BPINST is 1 byte*/
+static kdbbyt_t kdb_bpinst = 0xcc;            /* breakpoint instr: INT3 */
+static struct kdb_sbrkpt kdb_sbpa[KDBMAXSBP]; /* soft brkpt array/table */
+static kdbtab_t *tbp;
+
+static int kdb_set_bp(domid_t, kdbva_t, int, ulong *, char*, char*, char*);
+static void kdb_print_uregs(struct cpu_user_regs *);
+
+
+/* ===================== cmdline functions  ================================ */
+
+/* lp points to a string of only alpha numeric chars terminated by '\n'.
+ * Parse the string into argv pointers, and RETURN argc
+ * Eg:  if lp --> "dr  sp\n" :  argv[0]=="dr\0"  argv[1]=="sp\0"  argc==2
+ */
+static int
+kdb_parse_cmdline(char *lp, const char **argv)
+{
+    int i=0;
+
+    for (; *lp == ' '; lp++);      /* note: isspace() skips '\n' also */
+    while ( *lp != '\n' ) {
+        if (i == KDB_MAXARGC) {
+            printk("kdb: max args exceeded\n");
+            break;
+        }
+        argv[i++] = lp;
+        for (; *lp != ' ' && *lp != '\n'; lp++);
+        if (*lp != '\n')
+            *lp++ = '\0';
+        for (; *lp == ' '; lp++);
+    }
+    *lp = '\0';
+    return i;
+}
+
+void
+kdb_clear_prev_cmd()             /* so previous command is not repeated */
+{
+    tbp = NULL;
+}
+
+void
+kdb_do_cmds(struct cpu_user_regs *regs)
+{
+    char *cmdlinep;
+    const char *argv[KDB_MAXARGC];
+    int argc = 0, curcpu = smp_processor_id();
+    kdb_cpu_cmd_t result = KDB_CPU_MAIN_KDB;
+
+    snprintf(kdb_prompt, sizeof(kdb_prompt), "[%d]xkdb> ", curcpu);
+
+    while (result == KDB_CPU_MAIN_KDB) {
+        cmdlinep = kdb_get_cmdline(kdb_prompt);
+        if (*cmdlinep == '\n') {
+            if (tbp==NULL || tbp->kdb_cmd_func==NULL)
+                continue;
+            else
+                argc = -1;    /* repeat prev command */
+        } else {
+            argc = kdb_parse_cmdline(cmdlinep, argv);
+            for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_func; tbp++)  {
+                if (strcmp(argv[0], tbp->kdb_cmd_name)==0) 
+                    break;
+            }
+        }
+        if (kdb_sys_crash && tbp->kdb_cmd_func && !tbp->kdb_cmd_crash_avail) {
+            kdbp("cmd not available in fatal/crashed state....\n");
+            continue;
+        }
+        if (tbp->kdb_cmd_func) {
+            result = (*tbp->kdb_cmd_func)(argc, argv, regs);
+            if (tbp->kdb_cmd_repeat == KDB_REPEAT_NONE)
+                tbp = NULL;
+        } else
+            kdbp("kdb: Unknown cmd: %s\n", cmdlinep);
+    }
+    kdb_cpu_cmd[curcpu] = result;
+    return;
+}
+
+/* ===================== Util functions  ==================================== */
+
+int
+kdb_vcpu_valid(struct vcpu *in_vp)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    for(dp=domain_list; in_vp && dp; dp=dp->next_in_list)
+        for_each_vcpu(dp, vp)
+            if (in_vp == vp)
+                return 1;
+    return 0;     /* not found */
+}
+
+/*
+ * Given a symbol, find it's address
+ */
+static kdbva_t
+kdb_sym2addr(const char *p, domid_t domid)
+{
+    kdbva_t addr;
+
+    KDBGP1("sym2addr: p:%s domid:%d\n", p, domid);
+    if (domid == DOMID_IDLE)
+        addr = address_lookup((char *)p);
+    else
+        addr = (kdbva_t)kdb_guest_sym2addr((char *)p, domid);
+    KDBGP1("sym2addr: exit: addr returned:0x%lx\n", addr);
+    return addr;
+}
+
+/*
+ * convert ascii to int decimal (base 10). 
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2deci(const char *strp, int *intp)
+{
+    const char *endp;
+
+    KDBGP2("str2deci: str:%s\n", strp);
+    if (!isdigit(*strp))
+        return 0;
+    *intp = (int)simple_strtoul(strp, &endp, 10);
+    if (endp != strp+strlen(strp))
+        return 0;
+    KDBGP2("str2deci: intval:$%d\n", *intp);
+    return 1;
+}
+/*
+ * convert ascii to long. NOTE: base is 16
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2ulong(const char *strp, ulong *longp)
+{
+    ulong val;
+    const char *endp;
+
+    KDBGP2("str2long: str:%s\n", strp);
+    if (!isxdigit(*strp))
+        return 0;
+    val = (long)simple_strtoul(strp, &endp, 16);   /* handles leading 0x */
+    if (endp != strp+strlen(strp))
+        return 0;
+    if (longp)
+        *longp = val;
+    KDBGP2("str2long: val:0x%lx\n", val);
+    return 1;
+}
+/*
+ * convert a symbol or ascii address to hex address
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2addr(const char *strp, kdbva_t *addrp, domid_t id)
+{
+    kdbva_t addr;
+    const char *endp;
+
+    /* assume it's an address */
+    KDBGP2("str2addr: str:%s id:%d\n", strp, id);
+    addr = (kdbva_t)simple_strtoul(strp, &endp, 16); /*handles leading 0x */
+    if (endp != strp+strlen(strp))
+        if ( !(addr=kdb_sym2addr(strp, id)) )
+            return 0;
+    *addrp = addr;
+    KDBGP2("str2addr: addr:0x%lx\n", addr);
+    return 1;
+}
+
+/* Given domid, return ptr to struct domain 
+ * IF domid == DOMID_IDLE return ptr to idle_domain 
+ * IF domid == valid domain, return ptr to domain struct
+ * else domid is bad and return NULL
+ */
+static struct domain *
+kdb_domid2ptr(domid_t domid)
+{
+    struct domain *dp;
+
+    /* get_domain_by_id() ret NULL for both DOMID_IDLE and bad domids */
+    if (domid == DOMID_IDLE)
+        dp = idle_vcpu[smp_processor_id()]->domain;
+    else 
+        dp = get_domain_by_id(domid);   /* NULL now means bad domid */
+    return dp;
+}
+
+/*
+ * Returns:  0: failed. invalid domid or string, *idp not changed.
+ */
+static int
+kdb_str2domid(const char *domstr, domid_t *idp, int perr)
+{
+    int id;
+    if (!kdb_str2deci(domstr, &id) || !kdb_domid2ptr((domid_t)id)) {
+        if (perr)
+            kdbp("Invalid domid:%s\n", domstr);
+        return 0;
+    }
+    *idp = (domid_t)id;
+    return 1;
+}
+
+static struct domain *
+kdb_strdomid2ptr(const char *domstr, int perror)
+{
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
+}
+
+/* return a guest bitness: 32 or 64 */
+int
+kdb_guest_bitness(domid_t domid)
+{
+    const int HYPSZ = sizeof(long) * 8;
+    struct domain *dp = kdb_domid2ptr(domid);
+    int retval; 
+
+    if (is_idle_domain(dp))
+        retval = HYPSZ;
+    else if (is_hvm_or_hyb_domain(dp))
+        retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
+    else 
+        retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
+    KDBGP1("gbitness: domid:%d dp:%p bitness:%d\n", domid, dp, retval);
+    return retval;
+}
+
+/* kdb_print_spin_lock(&xyz_lock, "xyz_lock:", "\n"); */
+static void
+kdb_print_spin_lock(char *strp, spinlock_t *lkp, char *nlp)
+{
+    kdbp("%s %04hx %d %d%s", strp, KDB_LKDEF(*lkp), lkp->recurse_cpu,
+         lkp->recurse_cnt, nlp);
+}
+
+/* check if register string is valid. if yes, return offset to the register
+ * in cpu_user_regs, else return -1 */
+static int
+kdb_valid_reg(const char *nmp) 
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (strcmp(kdb_reg_nm_offs[i].reg_nm, nmp) == 0)
+            return kdb_reg_nm_offs[i].reg_offs;
+    return -1;
+}
+
+/* given offset of register, return register name string. if offset is invalid
+ * return NULL */
+static char *kdb_regoffs_to_name(int offs)
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (kdb_reg_nm_offs[i].reg_offs == offs)
+            return kdb_reg_nm_offs[i].reg_nm;
+    return NULL;
+}
+
+/* ===================== util struct funcs ================================= */
+static void
+kdb_prnt_timer(struct timer *tp)
+{
+#if XEN_SUBVERSION == 0 
+    kdbp(" expires:%016lx expires_end:%016lx cpu:%d status:%x\n", tp->expires, 
+         tp->expires_end, tp->cpu, tp->status);
+#else
+    kdbp(" expires:%016lx cpu:%d status:%x\n", tp->expires, tp->cpu,tp->status);
+#endif
+    kdbp(" function data:%p ptr:%p ", tp->data, tp->function);
+    kdb_prnt_addr2sym(DOMID_IDLE, (kdbva_t)tp->function, "\n");
+}
+
+static void 
+kdb_prnt_periodic_time(struct periodic_time *ptp)
+{
+    kdbp(" next:%p prev:%p\n", ptp->list.next, ptp->list.prev);
+    kdbp(" on_list:%d one_shot:%d dont_freeze:%d irq_issued:%d src:%x irq:%x\n",
+         ptp->on_list, ptp->one_shot, ptp->do_not_freeze, ptp->irq_issued,
+         ptp->source, ptp->irq);
+    kdbp(" vcpu:%p pending_intr_nr:%08x period:%016lx\n", ptp->vcpu,
+         ptp->pending_intr_nr, ptp->period);
+    kdbp(" scheduled:%016lx last_plt_gtime:%016lx\n", ptp->scheduled,
+         ptp->last_plt_gtime);
+    kdbp(" \n          timer info:\n");
+    kdb_prnt_timer(&ptp->timer);
+    kdbp("\n");
+}
+
+/* ===================== cmd functions  ==================================== */
+
+/*
+ * FUNCTION: Disassemble instructions
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dis(void)
+{
+    kdbp("dis [addr|sym][num][domid] : Disassemble instrs\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dis(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int num = 8;                           /* display 8 instr by default */
+    static kdbva_t addr = BFD_INVAL;
+    static domid_t domid;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dis();
+
+    if (argc != -1)      /* not a command repeat */
+        domid = guest_mode(regs) ?  current->domain->domain_id : DOMID_IDLE;
+
+    if (argc >= 4 && !kdb_str2domid(argv[3], &domid, 1)) { 
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc >= 3 && !kdb_str2deci(argv[2], &num)) {
+        kdbp("kdb:Invalid num\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc > 1 && !kdb_str2addr(argv[1], &addr, domid)) {
+        kdbp("kdb:Invalid addr/sym\n");
+        kdbp("(num has to be specified if providing domid)\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc == 1)                    /* not command repeat */
+        addr = regs->KDBIP;           /* PC is the default */
+    else if (addr == BFD_INVAL) {
+        kdbp("kdb:Invalid addr/sym\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    addr = kdb_print_instr(addr, num, domid);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* FUNCTION: kdb_cmdf_dism() Toggle disassembly syntax from Intel to ATT/GAS */
+static kdb_cpu_cmd_t
+kdb_usgf_dism(void)
+{
+    kdbp("dism: toggle disassembly mode between ATT/GAS and INTEL\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dism(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dism();
+
+    kdb_toggle_dis_syntax();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+_kdb_show_guest_stack(domid_t domid, kdbva_t ipaddr, kdbva_t spaddr)
+{
+    kdbva_t val;
+    int num=0, max=0, rd = kdb_guest_bitness(domid)/8;
+
+    kdb_print_instr(ipaddr, 1, domid);
+    KDBGP("_guest_stack:sp:%lx domid:%d rd:$%d\n", spaddr, domid, rd);
+    val = 0;                          /* must zero, in case guest is 32bit */
+    while((kdb_read_mem(spaddr,(kdbbyt_t *)&val,rd,domid)==rd) && num < 16){
+        KDBGP1("gstk:addr:%lx val:%lx\n", spaddr, val);
+        if (kdb_is_addr_guest_text(val, domid)) {
+            kdb_print_instr(val, 1, domid);
+            num++;
+        }
+        if (max++ > 10000)            /* don't walk down the stack forever */
+            break;                    /* 10k is chosen randomly */
+        spaddr += rd;
+    }
+}
+
+/* Read guest memory and display address that looks like text. */
+static void
+kdb_show_guest_stack(struct cpu_user_regs *regs, struct vcpu *vcpup)
+{
+    kdbva_t ipaddr=regs->KDBIP, spaddr = regs->KDBSP;
+    domid_t domid = vcpup->domain->domain_id;
+
+    ASSERT(domid != DOMID_IDLE);
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+}
+
+/* display stack. if vcpu ptr given, then display stack for that. Otherwise,
+ * use current regs */
+static kdb_cpu_cmd_t
+kdb_usgf_f(void)
+{
+    kdbp("f [vcpu-ptr]: dump current/vcpu stack\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_f(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_f();
+
+    if (argc > 1 ) {
+        struct vcpu *vp;
+        if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp)) {
+            kdbp("kdb: Bad VCPU ptr:%s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdb_show_guest_stack(&vp->arch.user_regs, vp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs))
+        kdb_show_guest_stack(regs, current);
+    else
+        show_trace(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an spaddr and domid for guest, dump stack */
+static kdb_cpu_cmd_t
+kdb_usgf_fg(void)
+{
+    kdbp("fg domid RIP ESP: dump guest stack given domid, RIP, and ESP\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_fg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid;
+    kdbva_t ipaddr, spaddr;
+
+    if (argc != 4) 
+        return kdb_usgf_fg();
+
+    if (kdb_str2domid(argv[1], &domid, 1)==0) {
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[2], &ipaddr)==0) {
+        kdbp("Bad ipaddr:%s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[3], &spaddr)==0) {
+        kdbp("Bad spaddr:%s\n", argv[3]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display kdb stack. for debugging kdb itself */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbf(void)
+{
+    kdbp("kdbf: display kdb stack. for debugging kdb only\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_kdbf(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbf();
+
+    kdb_trap_immed(KDB_TRAP_KDBSTACK);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* worker function to display memory. Request could be for any guest, domid.
+ * Also address could be machine or virtual */
+static void
+_kdb_display_mem(kdbva_t *addrp, int *lenp, int wordsz, int domid, int is_maddr)
+{
+    #define DDBUFSZ 4096
+
+    kdbbyt_t buf[DDBUFSZ], *bp;
+    int numrd, bytes;
+    int len = *lenp;
+    kdbva_t addr = *addrp;
+
+    /* round len down to wordsz boundry because on intel endian, printing
+     * characters is not prudent, (long and ints can't be interpreted 
+     * easily) */
+    len &= ~(wordsz-1);
+    len = KDBMIN(DDBUFSZ, len);
+    len = len ? len : wordsz;
+
+    KDBGP("dmem:addr:%lx buf:%p len:$%d domid:%d sz:$%d maddr:%d\n", addr,
+          buf, len, domid, wordsz, is_maddr);
+    if (is_maddr)
+        numrd=kdb_read_mmem((kdbma_t)addr, buf, len);
+    else
+        numrd=kdb_read_mem(addr, buf, len, domid);
+    if (numrd != len)
+        kdbp("Memory read error. Bytes read:$%d\n", numrd);
+
+    for (bp = buf; numrd > 0;) {
+        kdbp("%016lx: ", addr); 
+
+        /* display 16 bytes per line */
+        for (bytes=0; bytes < 16 && numrd > 0; bytes += wordsz) {
+            if (numrd >= wordsz) {
+                if (wordsz == 8)
+                    kdbp(" %016lx", *(long *)bp);
+                else
+                    kdbp(" %08x", *(int *)bp);
+                bp += wordsz;
+                numrd -= wordsz;
+                addr += wordsz;
+            }
+        }
+        kdbp("\n");
+        continue;
+    }
+    *lenp = len;
+    *addrp = addr;
+}
+
+/* display machine mem, ie, the given address is machine address */
+static kdb_cpu_cmd_t 
+kdb_display_mmem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbma_t maddr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&maddr, &len, wordsz, id, 1);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                                     /* default read len */
+
+    if (!kdb_str2ulong(argv[1], &maddr)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_display_mem(&maddr, &len, wordsz, 0, 1);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dwm(void)
+{
+    kdbp("dwm:  maddr|sym [num] : dump memory word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dwm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 4, kdb_usgf_dwm);
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ddm(void)
+{
+    kdbp("ddm:  maddr|sym [num] : dump double word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ddm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 8, kdb_usgf_ddm);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory : word or doubleword
+ *           wordsz : bytes in word. 4 or 8
+ *
+ *           We display upto BUFSZ bytes. User can just press enter for more.
+ *           addr is always in hex with or without leading 0x
+ */
+static kdb_cpu_cmd_t 
+kdb_display_mem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbva_t addr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&addr, &len, wordsz, id, 0);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    id = DOMID_IDLE;                /* not a command repeat, reset dom id */
+    if (argc >= 4) { 
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                       /* default read len */
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    _kdb_display_mem(&addr, &len, wordsz, id, 0);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dw(void)
+{
+    kdbp("dw vaddr|sym [num][domid] : dump mem word. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 4, kdb_usgf_dw);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dd(void)
+{
+    kdbp("dd vaddr|sym [num][domid] : dump dword. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dd(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 8, kdb_usgf_dd);
+}
+
+/* 
+ * FUNCTION: Modify Memory Word 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mw(void)
+{
+    kdbp("mw vaddr|sym val [domid] : modify memory word in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_mw();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val, 4, id) != 4)
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_md(void)
+{
+    kdbp("md vaddr|sym val [domid] : modify memory dword in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_md(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_md();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) {
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val,sizeof(val),id) != sizeof(val))
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct  Xgt_desc_struct {
+    unsigned short size;
+    unsigned long address __attribute__((packed));
+};
+
+void
+kdb_show_special_regs(struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    unsigned short tr;                 /* Task Register segment selector */
+    __u64 efer;
+
+    kdbp("\nSpecial Registers:\n");
+    __asm__ __volatile__ ("sidt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("IDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+    __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("GDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+
+    kdbp("cr0: %016lx  cr2: %016lx\n", read_cr0(), read_cr2());
+    kdbp("cr3: %016lx  cr4: %016lx\n", read_cr3(), read_cr4());
+    __asm__ __volatile__ ("str (%0) \n":: "a"(&tr) : "memory");
+    kdbp("TR: %x\n", tr);
+
+    rdmsrl(MSR_EFER, efer);    /* IA32_EFER */
+    kdbp("efer:"KDBF64" LMA(IA-32e mode):%d SCE(syscall/sysret):%d\n",
+         efer, ((efer&EFER_LMA) != 0), ((efer&EFER_SCE) != 0));
+
+    kdbp("DR0: %016lx  DR1:%016lx  DR2:%016lx\n", kdb_rd_dbgreg(0),
+         kdb_rd_dbgreg(1), kdb_rd_dbgreg(2)); 
+    kdbp("DR3: %016lx  DR6:%016lx  DR7:%016lx\n", kdb_rd_dbgreg(3),
+         kdb_rd_dbgreg(6), kdb_rd_dbgreg(7)); 
+}
+
+/* 
+ * FUNCTION: Dispaly Registers. If "sp" argument, then display additional regs
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dr(void)
+{
+    kdbp("dr [sp]: display registers. sp to display special regs also\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dr();
+
+    KDBGP1("regs:%p .rsp:%lx .rip:%lx\n", regs, regs->rsp, regs->rip);
+    show_registers(regs);
+    if (argc > 1 && !strcmp(argv[1], "sp")) 
+        kdb_show_special_regs(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* show registers on stack bottom where guest context is. same as dr if
+ * not running in guest mode */
+static kdb_cpu_cmd_t
+kdb_usgf_drg(void)
+{
+    kdbp("drg: display active guest registers at stack bottom\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_drg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_drg();
+
+    kdbp("\tNote: ds/es/fs/gs etc.. are not saved from the cpu\n");
+    kdb_print_uregs(guest_cpu_user_regs());
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Register
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mr(void)
+{
+    kdbp("mr reg val : Modify Register. val assumed in hex\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int regoffs;
+    ulong val;
+
+    if (argc != 3 || !kdb_str2ulong(argv[2], &val)) {
+        return kdb_usgf_mr();
+    }
+    argp = argv[1];
+
+#if defined(__x86_64__)
+    if ((regoffs=kdb_valid_reg(argp)) != -1)
+        *((uint64_t *)((char *)regs+regoffs)) = val;
+#else
+    if (!strcmp(argp, "eax"))
+        regs->eax = val;
+    else if (!strcmp(argp, "ebx"))
+        regs->ebx = val;
+    else if (!strcmp(argp, "ecx"))
+        regs->ecx = val;
+    else if (!strcmp(argp, "edx"))
+        regs->edx = val;
+    else if (!strcmp(argp, "esi"))
+        regs->esi = val;
+    else if (!strcmp(argp, "edi"))
+        regs->edi = val;
+    else if (!strcmp(argp, "ebp"))
+        regs->ebp = val;
+    else if (!strcmp(argp, "esp"))
+        regs->esp = val;
+    else if (!strcmp(argp, "eflags") || !strcmp(argp, "rflags"))
+        regs->eflags = val;
+#endif
+    else
+        kdbp("Error. Bad register : %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Single Step
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ss(void)
+{
+    kdbp("ss: single step\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ss(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    #define KDB_HALT_INSTR 0xf4
+
+    kdbbyt_t byte;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ss();
+
+    KDBGP("enter kdb_cmdf_ss \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_read_mem(regs->KDBIP, &byte, 1, id) == 1) {
+        if (byte == KDB_HALT_INSTR) {
+            kdbp("kdb: jumping over halt instruction\n");
+            regs->KDBIP++;
+        }
+    } else {
+        kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
+        current->arch.hvm_vcpu.single_step = 1;
+    } else
+        regs->eflags |= X86_EFLAGS_TF;
+
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Next Instruction, step over the call instr to the next instr
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ni(void)
+{
+    kdbp("ni: single step, stepping over function calls\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ni(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int sz, i;
+    domid_t id=guest_mode(regs) ? current->domain->domain_id:DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ni();
+
+    KDBGP("enter kdb_cmdf_ni \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if ((sz=kdb_check_call_instr(id, regs->KDBIP)) == 0)  /* !call instr */
+        return kdb_cmdf_ss(argc, argv, regs);         /* just do ss */
+
+    if ((i=kdb_set_bp(id, regs->KDBIP+sz, 1,0,0,0,0)) >= KDBMAXSBP) /* failed */
+        return KDB_CPU_MAIN_KDB;
+
+    kdb_sbpa[i].bp_ni = 1;
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+        current->arch.hvm_vcpu.single_step = 0;
+    else
+        regs->eflags &= ~X86_EFLAGS_TF;
+
+    return KDB_CPU_NI;
+}
+
+static void
+kdb_btf_enable(void)
+{
+    u64 debugctl;
+    rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 0x2);
+}
+
+/* 
+ * FUNCTION: Single Step to branch. Doesn't seem to work very well.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ssb(void)
+{
+    kdbp("ssb: singe step to branch\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ssb(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ssb();
+
+    KDBGP("MUK: enter kdb_cmdf_ssb\n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (is_hvm_or_hyb_vcpu(current)) 
+        current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
+
+    regs->eflags |= X86_EFLAGS_TF;
+    kdb_btf_enable();
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Continue Execution. TF must be cleared here as this could run on 
+ *           any cpu. Hence not OK to do it from kdb_end_session.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_go(void)
+{
+    kdbp("go: leave kdb and continue execution\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_go(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_go();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    return KDB_CPU_GO;
+}
+
+/* All cpus must display their current context */
+static kdb_cpu_cmd_t 
+kdb_cpu_status_all(int ccpu, struct cpu_user_regs *regs)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)   /* hung cpu */
+                continue;
+            kdb_cpu_cmd[cpu] = KDB_CPU_SHOWPC;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_SHOWPC);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * display/switch CPU. 
+ *  Argument:
+ *     none:   just go back to initial cpu
+ *     cpunum: switch to given vpu
+ *     "all":  show one line status of all cpus
+ */
+extern volatile int kdb_init_cpu;
+static kdb_cpu_cmd_t
+kdb_usgf_cpu(void)
+{
+    kdbp("cpu [all|num]: none will switch back to initial cpu\n");
+    kdbp("               cpunum to switch to the vcpu. all to show status\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_cpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+    int ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cpu();
+
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all"))
+            return kdb_cpu_status_all(ccpu, regs);
+
+            cpu = (int)simple_strtoul(argv[1], NULL, 0); /* handles 0x */
+            if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && 
+                cpu_online(cpu) && kdb_cpu_cmd[cpu] == KDB_CPU_PAUSE)
+            {
+                kdbp("Switching to cpu:%d\n", cpu);
+                kdb_cpu_cmd[cpu] = KDB_CPU_MAIN_KDB;
+
+                /* clear any single step on the current cpu */
+                regs->eflags &= ~X86_EFLAGS_TF;
+                return KDB_CPU_PAUSE;
+            } else {
+                if (cpu != ccpu)
+                    kdbp("Unable to switch to cpu:%d\n", cpu);
+                else {
+                    kdb_display_pc(regs);
+                }
+                return KDB_CPU_MAIN_KDB;
+            }
+    }
+    /* no arg means back to initial cpu */
+    if (!kdb_sys_crash && ccpu != kdb_init_cpu) {
+        if (kdb_cpu_cmd[kdb_init_cpu] == KDB_CPU_PAUSE) {
+            regs->eflags &= ~X86_EFLAGS_TF;
+            kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_MAIN_KDB;
+            return KDB_CPU_PAUSE;
+        } else
+            kdbp("Unable to switch to: %d\n", kdb_init_cpu);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* send NMI to all or given CPU. Must be crashed/fatal state */
+static kdb_cpu_cmd_t
+kdb_usgf_nmi(void)
+{
+    kdbp("nmi cpu#|all: send nmi cpu/s. must reboot when done with kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_nmi(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    cpumask_t cpumask;
+    int ccpu = smp_processor_id();
+
+    if (argc <= 1 || (argc > 1 && *argv[1] == '?'))
+        return kdb_usgf_nmi();
+
+    if (!kdb_sys_crash) {
+        kdbp("kdb: nmi cmd available in crashed state only\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!strcmp(argv[1], "all"))
+        cpumask = cpu_online_map;
+    else {
+        int cpu = (int)simple_strtoul(argv[1], NULL, 0);
+        if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && cpu_online(cpu))
+            cpumask = *cpumask_of(cpu);
+        else {
+            kdbp("KDB nmi: invalid cpu %s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    kdb_nmi_pause_cpus(cpumask);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_percpu(void)
+{
+    kdbp("percpu: display per cpu pointers\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_percpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_percpu();
+    kdb_dump_time_pcpu();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ========================= Breakpoints ==================================== */
+
+static void
+kdb_prnt_bp_cond(int bpnum)
+{
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {
+        kdbp("     ( %s %c%c %lx )\n", 
+             kdb_regoffs_to_name(bpcp->bp_cond_lhs),
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    } else {
+        kdbp("     ( %lx %c%c %lx )\n", bpcp->bp_cond_lhs,
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    }
+}
+
+static void
+kdb_prnt_bp_extra(int bpnum)
+{
+    if (kdb_sbpa[bpnum].bp_type == 2) {
+        ulong i, arg, *btp = kdb_sbpa[bpnum].u.bp_btp;
+        
+        kdbp("   will trace ");
+        for (i=0; i < KDB_MAXBTP && btp[i]; i++)
+            if ((arg=btp[i]) < sizeof (struct cpu_user_regs)) {
+                kdbp(" %s ", kdb_regoffs_to_name(arg));
+            } else {
+                kdbp(" %lx ", arg);
+            }
+        kdbp("\n");
+
+    } else if (kdb_sbpa[bpnum].bp_type == 1)
+        kdb_prnt_bp_cond(bpnum);
+}
+
+/*
+ * List software breakpoints
+ */
+static kdb_cpu_cmd_t
+kdb_display_sbkpts(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted) {
+            struct domain *dp = kdb_domid2ptr(kdb_sbpa[i].bp_domid);
+
+            if (dp == NULL || dp->is_dying) {
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                continue;
+            }
+            kdbp("[%d]: domid:%d 0x%lx   ", i, 
+                 kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr);
+            kdb_prnt_addr2sym(kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr,"\n");
+            kdb_prnt_bp_extra(i);
+        }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Check if any breakpoints that we need to install (delayed install)
+ * Returns: 1 if yes, 0 if none.
+ */
+int
+kdb_swbp_exists(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+/*
+ * Check if any breakpoints were deleted this kdb session
+ * Returns: 0 if none, 1 if yes
+ */
+static int
+kdb_swbp_deleted(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+
+/*
+ * Flush deleted sw breakpoints
+ */
+void
+kdb_flush_swbp_table(void)
+{
+    int i;
+    KDBGP("ccpu:%d flush_swbp_table: deleted:%x\n", smp_processor_id(), 
+          kdb_swbp_deleted());
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted) {
+            KDBGP("flush:[%x] addr:0x%lx\n",i,kdb_sbpa[i].bp_addr);
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        }
+}
+
+/*
+ * Delete/Clear a sw breakpoint
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bc(void)
+{
+    kdbp("bc $num|all : clear given or all breakpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, bpnum = -1, delall = 0;
+    const char *argp;
+
+    if (argc != 2 || *argv[1] == '?')
+        return kdb_usgf_bc();
+
+    if (!kdb_swbp_exists()) {
+        kdbp("No breakpoints are set\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        delall = 1;
+    else if (!kdb_str2deci(argp, &bpnum) || bpnum < 0 || bpnum > KDBMAXSBP) {
+        kdbp("Invalid bpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (delall && kdb_sbpa[i].bp_addr) {
+            kdbp("Deleted breakpoint [%x] addr:0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            continue;
+        }
+        if (bpnum != -1 && bpnum == i) {
+            kdbp("Deleted breakpoint [%x] at 0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            break;
+        }
+    }
+    if (i >= KDBMAXSBP && !delall)
+        kdbp("Unable to delete breakpoint: %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Install a breakpoint in the given array entry
+ * Returns: 0 : failed to install
+ *          1 : installed successfully
+ */
+static int
+kdb_install_swbp(int idx)                   /* which entry in the bp array */
+{
+    kdbva_t addr = kdb_sbpa[idx].bp_addr;
+    domid_t domid = kdb_sbpa[idx].bp_domid;
+    kdbbyt_t *p = &kdb_sbpa[idx].bp_originst;
+    struct domain *dp = kdb_domid2ptr(domid);
+
+    if (dp == NULL || dp->is_dying) {
+        memset(&kdb_sbpa[idx], 0, sizeof(kdb_sbpa[idx]));
+        kdbp("Removed bp %d addr:%p domid:%d\n", idx, addr, domid);
+        return 0;
+    }
+
+    if (kdb_read_mem(addr, p, KDBBPSZ, domid) != KDBBPSZ){
+        kdbp("Failed(R) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    if (kdb_write_mem(addr, &kdb_bpinst, KDBBPSZ, domid) != KDBBPSZ) {
+        kdbp("Failed(W) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    KDBGP("install_swbp: installed bp:%x at:0x%lx ccpu:%x domid:%d\n",
+          idx, kdb_sbpa[idx].bp_addr, smp_processor_id(), domid);
+    return 1;
+}
+
+/*
+ * Install all the software breakpoints
+ */
+void
+kdb_install_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_deleted && kdb_sbpa[i].bp_addr)
+            kdb_install_swbp(i);
+}
+
+static void
+kdb_uninstall_a_swbp(int i)
+{
+    kdbva_t addr = kdb_sbpa[i].bp_addr;
+    kdbbyt_t originst = kdb_sbpa[i].bp_originst;
+    domid_t id = kdb_sbpa[i].bp_domid;
+
+    kdb_sbpa[i].bp_just_added = 0;
+    if (!addr)
+        return;
+    if (kdb_write_mem(addr, &originst, KDBBPSZ, id) != KDBBPSZ) {
+        kdbp("Failed to uninstall breakpoint %x at:0x%lx domid:%d\n",
+             i, kdb_sbpa[i].bp_addr, id);
+    }
+}
+
+/*
+ * Uninstall all the software breakpoints at beginning of kdb session
+ */
+void
+kdb_uninstall_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++) 
+        kdb_uninstall_a_swbp(i);
+    KDBGP("ccpu:%d uninstalled all bps\n", smp_processor_id());
+}
+
+/* RETURNS: rc == 2: condition was not met,  rc == 3: condition was met */
+static int
+kdb_check_bp_condition(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong res = 0, lhsval=0;
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {             /* register condition */
+        uint64_t *rp = (uint64_t *)((char *)regs + bpcp->bp_cond_lhs);
+        lhsval = *rp;
+    } else if (bpcp->bp_cond_status == 2) {      /* memaddr condition */
+        ulong addr = bpcp->bp_cond_lhs;
+        int num = sizeof(lhsval);
+
+        if (kdb_read_mem(addr, (kdbbyt_t *)&lhsval, num, domid) != num) {
+            kdbp("kdb: unable to read %d bytes at %lx\n", num, addr);
+            return 3;
+        }
+    }
+    if (bpcp->bp_cond_type == 1)                 /* lhs == rhs */
+        res = (lhsval == bpcp->bp_cond_rhs);
+    else                                         /* lhs != rhs */
+        res = (lhsval != bpcp->bp_cond_rhs);
+
+    if (!res)
+        kdbp("KDB: [%d]Ignoring bp:%d condition not met. val:%lx\n", 
+              smp_processor_id(), bpnum, lhsval); 
+
+    KDBGP1("bpnum:%d domid:%d cond: %d %d %lx %lx res:%d\n", bpnum, domid, 
+           bpcp->bp_cond_status, bpcp->bp_cond_type, bpcp->bp_cond_lhs, 
+           bpcp->bp_cond_rhs, res);
+
+    return (res ? 3 : 2);
+}
+
+static void
+kdb_prnt_btp_info(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong i, arg, val, num, *btp = kdb_sbpa[bpnum].u.bp_btp;
+
+    kdb_prnt_addr2sym(domid, regs->KDBIP, "\n");
+    num = kdb_guest_bitness(domid)/8;
+    for (i=0; i < KDB_MAXBTP && (arg=btp[i]); i++) {
+        if (arg < sizeof (struct cpu_user_regs)) {
+            uint64_t *rp = (uint64_t *)((char *)regs + arg);
+            kdbp(" %s: %016lx ", kdb_regoffs_to_name(arg), *rp);
+        } else {
+            if (kdb_read_mem(arg, (kdbbyt_t *)&val, num, domid) != num)
+                kdbp("kdb: unable to read %d bytes at %lx\n", num, arg);
+            if (num == 8)
+                kdbp(" %016lx:%016lx ", arg, val);
+            else
+                kdbp(" %08lx:%08lx ", arg, val);
+        }
+    }
+    kdbp("\n");
+    KDBGP1("bpnum:%d domid:%d btp:%p num:%d\n", bpnum, domid, btp, num);
+}
+
+/*
+ * Check if the BP trap belongs to us. 
+ * Return: 0 : not one of ours. IP not changed. (leave kdb)
+ *         1 : one of ours but deleted. IP decremented. (leave kdb)
+ *         2 : one of ours but condition not met, or btp. IP decremented.(leave)
+ *         3 : one of ours and active. IP decremented. (stay in kdb)
+ */
+int 
+kdb_check_sw_bkpts(struct cpu_user_regs *regs)
+{
+    int i, rc=0;
+    domid_t curid;
+
+    curid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    for(i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_domid == curid  && 
+            kdb_sbpa[i].bp_addr == (regs->KDBIP- KDBBPSZ)) {
+
+            regs->KDBIP -= KDBBPSZ;
+            rc = 3;
+
+            if (kdb_sbpa[i].bp_ni) {
+                kdb_uninstall_a_swbp(i);
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            } else if (kdb_sbpa[i].bp_deleted) {
+                rc = 1;
+            } else if (kdb_sbpa[i].bp_type == 1) {
+                rc = kdb_check_bp_condition(i, regs, curid);
+            } else if (kdb_sbpa[i].bp_type == 2) {
+                kdb_prnt_btp_info(i, regs, curid);
+                rc = 2;
+            }
+            KDBGP1("ccpu:%d rc:%d curid:%d domid:%d addr:%lx\n", 
+                   smp_processor_id(), rc, curid, kdb_sbpa[i].bp_domid, 
+                   kdb_sbpa[i].bp_addr);
+            break;
+        }
+    }
+    return (rc);
+}
+
+/* Eg: r6 == 0x123EDF  or 0xFFFF2034 != 0xDEADBEEF
+ * regoffs: -1 means lhs is not reg. else offset of reg in cpu_user_regs
+ * addr: memory location if lhs is not register, eg, 0xFFFF2034
+ * condp : points to != or ==
+ * rhsval : right hand side value
+ */
+static void
+kdb_set_bp_cond(int bpnum, int regoffs, ulong addr, char *condp, ulong rhsval)
+{
+    if (bpnum >= KDBMAXSBP) {
+        kdbp("BUG: %s got invalid bpnum\n", __FUNCTION__);
+        return;
+    }
+    if (regoffs != -1) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 1;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = regoffs;
+    } else if (addr != 0) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 2;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = addr;
+    } else {
+        kdbp("error: invalid call to kdb_set_bp_cond\n");
+        return;
+    }
+    kdb_sbpa[bpnum].u.bp_cond.bp_cond_rhs = rhsval;
+
+    if (*condp == '!')
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 2;
+    else
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 1;
+}
+
+/* install breakpt at given addr. 
+ * ni: bp for next instr 
+ * btpa: ptr to args for btp for printing when bp is hit
+ * lhsp/condp/rhsp: point to strings of condition
+ *
+ * RETURNS: the index in array where installed. KDBMAXSBP if error 
+ */
+static int
+kdb_set_bp(domid_t domid, kdbva_t addr, int ni, ulong *btpa, char *lhsp, 
+           char *condp, char *rhsp)
+{
+    int i, pre_existing = 0, regoffs = -1;
+    ulong memloc=0, rhsval=0, tmpul;
+
+    if (btpa && (lhsp || rhsp || condp)) {
+        kdbp("internal error. btpa and (lhsp || rhsp || condp) set\n");
+        return KDBMAXSBP;
+    }
+    if (lhsp && ((regoffs=kdb_valid_reg(lhsp)) == -1)  &&
+        kdb_str2ulong(lhsp, &memloc) &&
+        kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0) {
+
+        kdbp("error: invalid argument: %s\n", lhsp);
+        return KDBMAXSBP;
+    }
+    if (rhsp && ! kdb_str2ulong(rhsp, &rhsval)) {
+        kdbp("error: invalid argument: %s\n", rhsp);
+        return KDBMAXSBP;
+    }
+
+    /* see if bp already set */
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_addr==addr && kdb_sbpa[i].bp_domid==domid) {
+
+            if (kdb_sbpa[i].bp_deleted) {
+                /* just re-set this bp again */
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                pre_existing = 1;
+            } else {
+                kdbp("Breakpoint already set \n");
+                return KDBMAXSBP;
+            }
+        }
+    }
+    /* see if any room left for another breakpoint */
+    for (i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_addr)
+            break;
+    if (i >= KDBMAXSBP) {
+        kdbp("ERROR: Breakpoint table full....\n");
+        return i;
+    }
+    kdb_sbpa[i].bp_addr = addr;
+    kdb_sbpa[i].bp_domid = domid;
+    if (btpa) {
+        kdb_sbpa[i].bp_type = 2;
+        kdb_sbpa[i].u.bp_btp = btpa;
+    } else if (regoffs != -1 || memloc) {
+        kdb_sbpa[i].bp_type = 1;
+        kdb_set_bp_cond(i, regoffs, memloc, condp, rhsval);
+    } else
+        kdb_sbpa[i].bp_type = 0;
+
+    if (kdb_install_swbp(i)) {                  /* make sure it can be done */
+        if (ni)
+            return i;
+
+        kdb_uninstall_a_swbp(i);                /* dont' show user INT3 */
+        if (!pre_existing)               /* make sure no is cpu sitting on it */
+            kdb_sbpa[i].bp_just_added = 1;
+
+        kdbp("bp %d set for domid:%d at: 0x%lx ", i, kdb_sbpa[i].bp_domid, 
+             kdb_sbpa[i].bp_addr);
+        kdb_prnt_addr2sym(domid, addr, "\n");
+        kdb_prnt_bp_extra(i);
+    } else {
+        kdbp("ERROR:Can't install bp: 0x%lx domid:%d\n", addr, domid);
+        if (pre_existing)     /* in case a cpu is sitting on this bp in traps */
+            kdb_sbpa[i].bp_deleted = 1;
+        else
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        return KDBMAXSBP;
+    }
+    /* make sure swbp reporting is enabled in the vmcb/vmcs */
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        struct domain *dp = kdb_domid2ptr(domid);
+        dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
+        KDBGP("debugger_attached set. domid:%d\n", domid);
+    }
+    return i;
+}
+
+/* 
+ * Set/List Software Breakpoint/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bp(void)
+{
+    kdbp("bp [addr|sym][domid][condition]: display or set a breakpoint\n");
+    kdbp("  where cond is like: r6 == 0x123F or rax != DEADBEEF or \n");
+    kdbp("       ffff82c48038fe58 == 321E or 0xffff82c48038fe58 != 0\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9");
+    kdbp(" r10 r11 r12 r13 r14 r15 rflags\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    int idx = -1;
+    domid_t domid = DOMID_IDLE;
+    char *domidstrp, *lhsp=NULL, *condp=NULL, *rhsp=NULL;
+
+    if ((argc > 1 && *argv[1] == '?') || argc == 4 || argc > 6)
+        return kdb_usgf_bp();
+
+    if (argc < 2 || kdb_sys_crash)         /* list all set breakpoints */
+        return kdb_display_sbkpts();
+
+    /* valid argc either: 2 3 5 or 6 
+     * 'bp idle_loop r6 == 0xc000' OR 'bp idle_loop 3 r9 != 0xdeadbeef' */
+    idx = (argc == 5) ? 2 : ((argc == 6) ? 3 : idx);
+    if (argc >= 5 ) {
+        lhsp = (char *)argv[idx];
+        condp = (char *)argv[idx+1];
+        rhsp = (char *)argv[idx+2];
+
+        if (!kdb_str2ulong(rhsp, NULL) || *(condp+1) != '=' || 
+            (*condp != '=' && *condp != '!')) {
+
+            return kdb_usgf_bp();
+        }
+    }
+    domidstrp = (argc == 3 || argc == 6 ) ? (char *)argv[2] : NULL;
+    if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
+        return kdb_usgf_bp();
+    }
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        kdbp("HVM domain not supported yet for conditional bp\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    /* make sure xen addr is in xen text, otherwise bp set in 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_set_bp(domid, addr, 0, NULL, lhsp, condp, rhsp);     /* 0 is ni flag */
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* trace breakpoint, meaning, upon bp trace/print some info and continue */
+
+static kdb_cpu_cmd_t
+kdb_usgf_btp(void)
+{
+    kdbp("btp addr|sym [domid] reg|domid-mem-addr... : breakpoint trace\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9 ");
+    kdbp("r10 r11 r12 r13 r14 r15 rflags\n");
+    kdbp("  Eg. btp idle_cpu 7 rax rbx 0x20ef5a5 r9\n");
+    kdbp("      will print rax, rbx, *(long *)0x20ef5a5, r9 and continue\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_btp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, btpidx, numrd, argsidx, regoffs = -1;
+    kdbva_t addr, memloc=0;
+    domid_t domid = DOMID_IDLE;
+    ulong *btpa, tmpul;
+
+    if ((argc > 1 && *argv[1] == '?') || argc < 3)
+        return kdb_usgf_btp();
+
+    argsidx = 2;                   /* assume 3rd arg is not domid */
+    if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
+
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+            kdbp("HVM domains are not currently supprted\n");
+            return KDB_CPU_MAIN_KDB;
+        } else
+            argsidx = 3;               /* 3rd arg is a domid */
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    /* make sure xen addr is in xen text, otherwise will trace 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    numrd = kdb_guest_bitness(domid)/8;
+    if (kdb_read_mem(addr, (kdbbyt_t *)&tmpul, numrd, domid) != numrd) {
+        kdbp("Unable to read mem from %s (%lx)\n", argv[1], addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    for (btpidx=0; btpidx < KDBMAXSBP && kdb_btp_ap[btpidx]; btpidx++);
+    if (btpidx >= KDBMAXSBP) {
+        kdbp("error: table full. delete few breakpoints\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    btpa = kdb_btp_argsa[btpidx];
+    memset(btpa, 0, sizeof(kdb_btp_argsa[0]));
+
+    for (i=0; argv[argsidx]; i++, argsidx++) {
+
+        if (((regoffs=kdb_valid_reg(argv[argsidx])) == -1)  &&
+            kdb_str2ulong(argv[argsidx], &memloc) &&
+            (memloc < sizeof (struct cpu_user_regs) ||
+            kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0)){
+
+            kdbp("error: invalid argument: %s\n", argv[argsidx]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        if (i >= KDB_MAXBTP) {
+            kdbp("error: cannot specify more than %d args\n", KDB_MAXBTP);
+            return KDB_CPU_MAIN_KDB;
+        }
+        btpa[i] = (regoffs == -1) ? memloc : regoffs;
+    }
+
+    i = kdb_set_bp(domid, addr, 0, btpa, 0, 0, 0);     /* 0 is ni flag */
+    if (i < KDBMAXSBP)
+        kdb_btp_ap[btpidx] = kdb_btp_argsa[btpidx];
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * Set/List watchpoints, ie, hardware breakpoint/s, in hypervisor
+ *   Usage: wp [sym|addr] [w|i]   w == write only data watchpoint
+ *                                i == IO watchpoint (read/write)
+ *
+ *   Eg:  wp        : list all watchpoints set
+ *        wp addr   : set a read/write wp at given addr
+ *        wp addr w : set a write only wp at given addr
+ *        wp addr i : set an IO wp at given addr (16bits port #)
+ *
+ *  TBD: allow to be set on particular cpu
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_wp(void)
+{
+    kdbp("wp [addr|sym][w|i]: display or set watchpoint. writeonly or IO\n");
+    kdbp("\tnote: watchpoint is triggered after the instruction executes\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    domid_t domid = DOMID_IDLE;
+    int rw = 3, len = 4;       /* for now just default to 4 bytes len */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_wp();
+
+    if (argc <= 1 || kdb_sys_crash) {       /* list all set watchpoints */
+        kdb_do_watchpoints(0, 0, 0);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2) {
+        if (!strcmp(argv[2], "w"))
+            rw = 1;
+        else if (!strcmp(argv[2], "i"))
+            rw = 2;
+        else {
+            return kdb_usgf_wp();
+        }
+    }
+    kdb_do_watchpoints(addr, rw, len);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_wc(void)
+{
+    kdbp("wc $num|all : clear given or all watchpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int wpnum;              /* wp num to delete. -1 for all */
+
+    if (argc != 2 || *argv[1] == '?') 
+        return kdb_usgf_wc();
+
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        wpnum = -1;
+    else if (!kdb_str2deci(argp, &wpnum)) {
+        kdbp("Invalid wpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_clear_wps(wpnum);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display struct hvm_vcpu{} in struct vcpu.arch{} */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpuh(void)
+{
+    kdbp("vcpuh vcpu-ptr : display hvm_vcpu struct\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpuh(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *vp;
+    struct hvm_vcpu *hvp;
+    struct hvm_io_op *ioop;
+    struct vlapic *vlp;
+
+    if (argc < 2 || *argv[1] == '?') 
+        return kdb_usgf_vcpuh();
+
+    if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
+        !is_hvm_or_hyb_vcpu(vp)) {
+
+        kdbp("kdb: Bad VCPU: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    hvp = &vp->arch.hvm_vcpu;
+    vlp = &hvp->vlapic;
+    kdbp("vcpu:%lx id:%d domid:%d\n", vp, vp->vcpu_id, vp->domain->domain_id);
+
+    ioop = NULL;   /* compiler warning */
+    kdbp("&hvm_vcpu:%lx  guest_efer:"KDBFL"\n", hvp, hvp->guest_efer);
+    kdbp("  guest_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->guest_cr[0],
+         hvp->guest_cr[1],hvp->guest_cr[2]);
+    kdbp("            [3]:"KDBFL" [4]:"KDBFL"\n", hvp->guest_cr[3],
+         hvp->guest_cr[4]);
+    kdbp("  hw_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->hw_cr[0],
+         hvp->hw_cr[1], hvp->hw_cr[2]);
+    kdbp("          [3]:"KDBFL" [4]:"KDBFL"\n", hvp->hw_cr[3], hvp->hw_cr[4]);
+
+    kdbp("  VLAPIC: base msr:"KDBF64" dis:%x tmrdiv:%x\n", 
+         vlp->hw.apic_base_msr, vlp->hw.disabled, vlp->hw.timer_divisor);
+    kdbp("          regs:%p regs_page:%p\n", vlp->regs, vlp->regs_page);
+    kdbp("          periodic time:\n"); 
+    kdb_prnt_periodic_time(&vlp->pt);
+
+    kdbp("  xen_port:%x flag_dr_dirty:%x dbg_st_latch:%x\n", hvp->xen_port,
+         hvp->flag_dr_dirty, hvp->debug_state_latch);
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+
+        struct arch_vmx_struct *vxp = &hvp->u.vmx;
+        kdbp("  &vmx: %p vmcs:%lx active_cpu:%x launched:%x\n", vxp, vxp->vmcs, 
+             vxp->active_cpu, vxp->launched);
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("    exec_ctrl:%x vpid:$%d\n", vxp->exec_control, vxp->vpid);
+#endif
+        kdbp("    host_cr0: "KDBFL" vmx: {realm:%x emulate:%x}\n",
+             vxp->host_cr0, vxp->vmx_realmode, vxp->vmx_emulate);
+
+#ifdef __x86_64__
+        kdbp("    &msr_state:%p\n", &vxp->msr_state);
+#endif
+    } else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+        struct arch_svm_struct *svp = &hvp->u.svm;
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("  &svm: vmcb:%lx pa:"KDBF64" asid:"KDBF64"\n", svp, svp->vmcb,
+             svp->vmcb_pa, svp->asid_generation);
+#endif
+        kdbp("    msrpm:%p lnch_core:%x vmcb_sync:%x\n", svp->msrpm, 
+             svp->launch_core, svp->vmcb_in_sync);
+    }
+    kdbp("  cachemode:%x io: {state: %x data: "KDBFL"}\n", hvp->cache_mode,
+         hvp->hvm_io.io_state, hvp->hvm_io.io_data);
+    kdbp("  mmio: {gva: "KDBFL" gpfn: "KDBFL"}\n", hvp->hvm_io.mmio_gva,
+         hvp->hvm_io.mmio_gpfn);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* also look into arch_get_info_guest() to get context */
+static void
+kdb_print_uregs(struct cpu_user_regs *regs)
+{
+#ifdef __x86_64__
+    kdbp("      rflags: %016lx   rip: %016lx\n", regs->rflags, regs->rip);
+    kdbp("         rax: %016lx   rbx: %016lx   rcx: %016lx\n",
+         regs->rax, regs->rbx, regs->rcx);
+    kdbp("         rdx: %016lx   rsi: %016lx   rdi: %016lx\n",
+         regs->rdx, regs->rsi, regs->rdi);
+    kdbp("         rbp: %016lx   rsp: %016lx    r8: %016lx\n",
+         regs->rbp, regs->rsp, regs->r8);
+    kdbp("          r9:  %016lx  r10: %016lx   r11: %016lx\n",
+         regs->r9,  regs->r10, regs->r11);
+    kdbp("         r12: %016lx   r13: %016lx   r14: %016lx\n",
+         regs->r12, regs->r13, regs->r14);
+    kdbp("         r15: %016lx\n", regs->r15);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+         "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%08lx entryvec:%08lx upcall_mask:%lx\n",
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#else
+    kdbp("      eflags: %016lx eip: 016lx\n", regs->eflags, regs->eip);
+    kdbp("      eax: %08x   ebx: %08x   ecx: %08x   edx: %08x\n",
+         regs->eax, regs->ebx, regs->ecx, regs->edx);
+    kdbp("      esi: %08x   edi: %08x   ebp: %08x   esp: %08x\n",
+         regs->esi, regs->edi, regs->ebp, regs->esp);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+     "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%04lx entryvec:%04lx upcall_mask:%lx\n", 
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#endif
+}
+
+#if XEN_SUBVERSION < 3             /* xen 3.1.x or xen 3.2.x */
+#ifdef CONFIG_COMPAT
+    #undef vcpu_info
+    #define vcpu_info(v, field)             \
+    (*(!has_32bit_shinfo((v)->domain) ?                                       \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->native.field : \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->compat.field))
+
+    #undef __shared_info
+    #define __shared_info(d, s, field)                      \
+    (*(!has_32bit_shinfo(d) ?                           \
+       (typeof(&(s)->compat.field))&(s)->native.field : \
+       (typeof(&(s)->compat.field))&(s)->compat.field))
+#endif
+#endif
+
+static void kdb_display_pv_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct pv_vcpu *gp = &vp->arch.pv_vcpu;
+
+    kdbp("      GDT_VIRT_START(vcpu): %lx\n", GDT_VIRT_START(vp));
+    kdbp("      GDT: entries:0x%lx  frames:\n", gp->gdt_ents);
+    for (i=0; i < 16; i=i+4) 
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->gdt_frames[i], 
+             gp->gdt_frames[i+1], gp->gdt_frames[i+2],gp->gdt_frames[i+3]);
+    
+    kdbp("      trap_ctxt:%lx kernel_ss:%lx kernel_sp:%lx\n", gp->trap_ctxt,
+         gp->kernel_ss, gp->kernel_sp);
+    kdbp("      ctrlregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->ctrlreg[i], 
+             gp->ctrlreg[i+1], gp->ctrlreg[i+2], gp->ctrlreg[i+3]);
+#ifdef __x86_64__
+    kdbp("      callback:   event: %016lx   failsafe: %016lx\n", 
+         gp->event_callback_eip, gp->failsafe_callback_eip);
+    kdbp("      base: fs:0x%lx gskern:0x%lx gsuser:0x%lx\n", 
+         gp->fs_base, gp->gs_base_kernel, gp->gs_base_user);
+#else
+    kdbp("      callback:   event: %08lx:%08lx   failsafe: %08lx:%08lx\n", 
+         gp->event_callback_cs, gp->event_callback_eip, 
+         gp->failsafe_callback_cs, gp->failsafe_callback_eip);
+#endif
+    kdbp("    vcpu_info_mfn: %lx  iopl: %x\n", gp->vcpu_info_mfn, gp->iopl);
+    kdbp("\n");
+}
+
+/* Display one VCPU info */
+static void
+kdb_display_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct arch_vcpu *avp = &vp->arch;
+    struct paging_vcpu *pvp = &vp->arch.paging;
+    int domid = vp->domain->domain_id;
+
+    kdbp("\nVCPU:  vcpu-id:%d  vcpu-ptr:%p ", vp->vcpu_id, vp);
+    kdbp("  processor:%d domid:%d  domp:%p\n", vp->processor, domid,vp->domain);
+
+    if (domid == DOMID_IDLE) {
+        kdbp("    IDLE vcpu.\n");
+        return;
+    }
+    kdbp("  pause: flags:0x%016lx count:%x\n", vp->pause_flags, 
+         vp->pause_count.counter);
+    kdbp("  vcpu: initdone:%d running:%d\n", 
+         vp->is_initialised, vp->is_running);
+    kdbp("  mcepend:%d nmipend:%d shut: def:%d paused:%d\n", 
+         vp->mce_pending,  vp->nmi_pending, vp->defer_shutdown, 
+         vp->paused_for_shutdown);
+    kdbp("  &vcpu_info:%p : evtchn_upc_pend:%x _mask:%x\n",
+         vp->vcpu_info, vcpu_info(vp, evtchn_upcall_pending),
+         vcpu_info(vp, evtchn_upcall_mask));
+    kdbp("  evt_pend_sel:%lx poll_evtchn:%x ", 
+         *(unsigned long *)&vcpu_info(vp, evtchn_pending_sel), vp->poll_evtchn);
+    kdb_print_spin_lock("virq_lock:", &vp->virq_lock, "\n");
+    for (i=0; i < NR_VIRQS; i++)
+        if (vp->virq_to_evtchn[i] != 0)
+            kdbp("      virq:$%d port:$%d\n", i, vp->virq_to_evtchn[i]);
+
+    kdbp("  next:%p periodic: period:0x%lx last_event:0x%lx\n", 
+         vp->next_in_list, vp->periodic_period, vp->periodic_last_event);
+    kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:%p sched_priv:0x%p\n",
+         vp->cpu_affinity, vp->vcpu_dirty_cpumask, vp->sched_priv);
+    kdbp("  &runstate: %p state: %x (eg. RUNSTATE_running) guestptr:%p\n", 
+         &vp->runstate, vp->runstate.state, runstate_guest(vp));
+    kdbp("\n");
+    kdbp("  arch info: (%p)\n", &vp->arch);
+    kdbp("    guest_context: VGCF_ flags:%lx", 
+         vp->arch.vgc_flags); /* VGCF_in_kernel */
+    if (is_hvm_or_hyb_vcpu(vp))
+        kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
+    kdbp("\n");
+    kdb_print_uregs(&vp->arch.user_regs);
+    kdbp("      debugregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", avp->debugreg[i], 
+             avp->debugreg[i+1], avp->debugreg[i+2], avp->debugreg[i+3]);
+    kdb_display_pv_vcpu(vp);
+
+    kdbp("    TF_flags: %016lx  guest_table: %016lx cr3:%016lx\n", 
+         vp->arch.flags, vp->arch.guest_table.pfn, avp->cr3); 
+    kdbp("    paging: \n");
+    kdbp("      vtlb:%p\n", &pvp->vtlb);
+    kdbp("      &pg_mode:%p gstlevels:%d &shadow:%p shlevels:%d\n",
+         pvp->mode, pvp->mode->guest_levels, &pvp->mode->shadow,
+         pvp->mode->shadow.shadow_levels);
+    kdbp("      shadow_vcpu:\n");
+    kdbp("        guest_vtable:%p last em_mfn:"KDBFL"\n",
+         pvp->shadow.guest_vtable, pvp->shadow.last_emulated_mfn);
+#if CONFIG_PAGING_LEVELS >= 3
+    kdbp("         l3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.l3table[3].l3, pvp->shadow.l3table[2].l3, 
+     pvp->shadow.l3table[1].l3, pvp->shadow.l3table[0].l3);
+    kdbp("        gl3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.gl3e[3].l3, pvp->shadow.gl3e[2].l3, 
+     pvp->shadow.gl3e[1].l3, pvp->shadow.gl3e[0].l3);
+#endif
+    kdbp("  gdbsx_vcpu_event:%x\n", vp->arch.gdbsx_vcpu_event);
+}
+
+/* 
+ * FUNCTION: Dispaly (current) VCPU/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpu(void)
+{
+    kdbp("vcpu [vcpu-ptr] : display current/vcpu-ptr vcpu info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *v = current;
+
+    if (argc > 2 || (argc > 1 && *argv[1] == '?'))
+        kdb_usgf_vcpu();
+    else if (argc <= 1)
+        kdb_display_vcpu(v);
+    else if (kdb_str2ulong(argv[1], (ulong *)&v) && kdb_vcpu_valid(v))
+        kdb_display_vcpu(v);
+    else 
+        kdbp("Invalid usage/argument:%s v:%lx\n", argv[1], (long)v);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* from paging_dump_domain_info() */
+static void kdb_pr_dom_pg_modes(struct domain *d)
+{
+    if (paging_mode_enabled(d)) {
+        kdbp(" paging mode enabled");
+        if ( paging_mode_shadow(d) )
+            kdbp(" shadow(PG_SH_enable)");
+        if ( paging_mode_hap(d) )
+            kdbp(" hap(PG_HAP_enable) ");
+        if ( paging_mode_refcounts(d) )
+            kdbp(" refcounts(PG_refcounts) ");
+        if ( paging_mode_log_dirty(d) )
+            kdbp(" log_dirty(PG_log_dirty) ");
+        if ( paging_mode_translate(d) )
+            kdbp(" translate(PG_translate) ");
+        if ( paging_mode_external(d) )
+            kdbp(" external(PG_external) ");
+    } else
+        kdbp(" disabled");
+    kdbp("\n");
+}
+
+/* print event channels info for a given domain 
+ * NOTE: very confusing, port and event channel refer to the same thing. evtchn
+ * is arry of pointers to a bucket of pointers to 128 struct evtchn{}. while
+ * 64bit xen can handle 4096 max channels, a 32bit guest is limited to 1024 */
+static void noinline kdb_print_dom_eventinfo(struct domain *dp)
+{
+    uint chn;
+
+    kdbp("\n");
+    kdbp("  Evt: MAX_EVTCHNS:$%d ptr:%p pollmsk:%08lx ",
+         MAX_EVTCHNS(dp), dp->evtchn, dp->poll_mask[0]);
+    kdb_print_spin_lock("lk:", &dp->event_lock, "\n");
+    kdbp("    &evtchn_pending:%p &evtchn_mask:%p\n", 
+         shared_info(dp, evtchn_pending), shared_info(dp, evtchn_mask));
+
+    kdbp("   Channels info: (everything is in decimal):\n");
+    for (chn=0; chn < MAX_EVTCHNS(dp); chn++ ) {
+        struct evtchn *bktp = dp->evtchn[chn/EVTCHNS_PER_BUCKET];
+        struct evtchn *chnp = &bktp[chn & (EVTCHNS_PER_BUCKET-1)];
+        char pbit = test_bit(chn, &shared_info(dp, evtchn_pending)) ? 'Y' : 'N';
+        char mbit = test_bit(chn, &shared_info(dp, evtchn_mask)) ? 'Y' : 'N';
+
+        if (bktp==NULL || chnp->state==ECS_FREE)
+            continue;
+
+        kdbp("    chn:%4u st:%d _xen=%d _vcpu_id:%2d ", chn, chnp->state,
+             chnp->xen_consumer, chnp->notify_vcpu_id);
+        if (chnp->state == ECS_UNBOUND)
+            kdbp(" rem-domid:%d", chnp->u.unbound.remote_domid);
+        else if (chnp->state == ECS_INTERDOMAIN)
+            kdbp(" rem-port:%d rem-dom:%d", chnp->u.interdomain.remote_port,
+                 chnp->u.interdomain.remote_dom->domain_id);
+        else if (chnp->state == ECS_PIRQ)
+            kdbp(" pirq:%d", chnp->u.pirq);
+        else if (chnp->state == ECS_VIRQ)
+            kdbp(" virq:%d", chnp->u.virq);
+
+        kdbp("  pend:%c mask:%c\n", pbit, mbit);
+    }
+#if 0
+    kdbp("pirq to evtchn mapping (pirq:evtchn) (all decimal):\n");
+    for (i=0; i < dp->nr_pirqs; i ++)
+        if (dp->pirq_to_evtchn[i])
+            kdbp("(%d:%d) ", i, dp->pirq_to_evtchn[i]);
+    kdbp("\n");
+#endif
+}
+
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    struct hvm_domain *hvp = &dp->arch.hvm_domain;
+
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+    if (hvp == NULL)
+        return;
+
+    if (hvp->irq.callback_via_type == HVMIRQ_callback_vector)
+        kdbp("    HVMIRQ_callback_vector: %x\n", hvp->irq.callback_via.vector);
+
+    if (!is_hvm_domain(dp))
+        return;
+
+    kdbp("    HVM PARAMS (all in hex):\n");
+    kdbp("\tioreq.page:%lx ioreq.va:%lx\n", hvp->ioreq.page, hvp->ioreq.va);
+    kdbp("\tbuf_ioreq.page:%lx ioreq.va:%lx\n", hvp->buf_ioreq.page, 
+         hvp->buf_ioreq.va);
+    kdbp("\tHVM_PARAM_CALLBACK_IRQ: %x\n", hvp->params[HVM_PARAM_CALLBACK_IRQ]);
+    kdbp("\tHVM_PARAM_STORE_PFN: %x\n", hvp->params[HVM_PARAM_STORE_PFN]);
+    kdbp("\tHVM_PARAM_STORE_EVTCHN: %x\n", hvp->params[HVM_PARAM_STORE_EVTCHN]);
+    kdbp("\tHVM_PARAM_PAE_ENABLED: %x\n", hvp->params[HVM_PARAM_PAE_ENABLED]);
+    kdbp("\tHVM_PARAM_IOREQ_PFN: %x\n", hvp->params[HVM_PARAM_IOREQ_PFN]);
+    kdbp("\tHVM_PARAM_BUFIOREQ_PFN: %x\n", hvp->params[HVM_PARAM_BUFIOREQ_PFN]);
+    kdbp("\tHVM_PARAM_VIRIDIAN: %x\n", hvp->params[HVM_PARAM_VIRIDIAN]);
+    kdbp("\tHVM_PARAM_TIMER_MODE: %x\n", hvp->params[HVM_PARAM_TIMER_MODE]);
+    kdbp("\tHVM_PARAM_HPET_ENABLED: %x\n", hvp->params[HVM_PARAM_HPET_ENABLED]);
+    kdbp("\tHVM_PARAM_IDENT_PT: %x\n", hvp->params[HVM_PARAM_IDENT_PT]);
+    kdbp("\tHVM_PARAM_DM_DOMAIN: %x\n", hvp->params[HVM_PARAM_DM_DOMAIN]);
+    kdbp("\tHVM_PARAM_ACPI_S_STATE: %x\n", hvp->params[HVM_PARAM_ACPI_S_STATE]);
+    kdbp("\tHVM_PARAM_VM86_TSS: %x\n", hvp->params[HVM_PARAM_VM86_TSS]);
+    kdbp("\tHVM_PARAM_VPT_ALIGN: %x\n", hvp->params[HVM_PARAM_VPT_ALIGN]);
+    kdbp("\tHVM_PARAM_CONSOLE_PFN: %x\n", hvp->params[HVM_PARAM_CONSOLE_PFN]);
+    kdbp("\tHVM_PARAM_CONSOLE_EVTCHN: %x\n", 
+         hvp->params[HVM_PARAM_CONSOLE_EVTCHN]);
+    kdbp("\tHVM_PARAM_ACPI_IOPORTS_LOCATION: %x\n", 
+         hvp->params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+    kdbp("\tHVM_PARAM_MEMORY_EVENT_SINGLE_STEP: %x\n", 
+         hvp->params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP]);
+}
+static void kdb_print_rangesets(struct domain *dp)
+{
+    int locked = spin_is_locked(&dp->rangesets_lock);
+
+    if (locked)
+        spin_unlock(&dp->rangesets_lock);
+    rangeset_domain_printk(dp);
+    if (locked)
+        spin_lock(&dp->rangesets_lock);
+}
+
+static void kdb_pr_vtsc_info(struct arch_domain *ap)
+{
+    kdbp("    VTSC info: tsc_mode:%x  vtsc:%x  vtsc_last:%016lx\n", 
+         ap->tsc_mode, ap->vtsc, ap->vtsc_last);
+    kdbp("        vtsc_offset:%016lx tsc_khz:%08lx incarnation:%x\n", 
+         ap->vtsc_offset, ap->vtsc_offset, ap->incarnation);
+    kdbp("        vtsc_kerncount:%016lx _usercount:%016lx\n",
+         ap->vtsc_kerncount, ap->vtsc_usercount);
+}
+
+/* display one domain info */
+static void
+kdb_display_dom(struct domain *dp)
+{
+    struct vcpu *vp;
+    int printed = 0;
+    struct grant_table *gp = dp->grant_table;
+    struct arch_domain *ap = &dp->arch;
+
+    kdbp("\nDOMAIN :    domid:0x%04x ptr:0x%p\n", dp->domain_id, dp);
+    if (dp->domain_id == DOMID_IDLE) {
+        kdbp("    IDLE domain.\n");
+        return;
+    }
+    if (dp->is_dying) {
+        kdbp("    domain is DYING.\n");
+        return;
+    }
+#if 0
+    kdb_print_spin_lock("  pgalk:", &dp->page_alloc_lock, "\n");
+    kdbp("  pglist:  0x%p 0x%p\n", dp->page_list.next,KDB_PGLLE(dp->page_list));
+    kdbp("  xpglist: 0x%p 0x%p\n", dp->xenpage_list.next, 
+         KDB_PGLLE(dp->xenpage_list));
+    kdbp("  next:0x%p hashnext:0x%p\n", 
+         dp->next_in_list, dp->next_in_hashbucket);
+#endif
+    kdbp("  PAGES: tot:0x%08x max:0x%08x xenheap:0x%08x\n", 
+         dp->tot_pages, dp->max_pages, dp->xenheap_pages);
+
+    kdb_print_rangesets(dp);
+    kdb_print_dom_eventinfo(dp);
+    kdbp("\n");
+    kdbp("  Grant table: gp:0x%p\n", gp);
+    if (gp) {
+        kdbp("    nr_frames:0x%08x shpp:0x%p active:0x%p\n",
+             gp->nr_grant_frames, gp->shared_raw, gp->active);
+        kdbp("    maptrk:0x%p maphd:0x%08x maplmt:0x%08x\n", 
+             gp->maptrack, gp->maptrack_head, gp->maptrack_limit);
+        kdbp("    mapcnt:");
+        kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
+    }
+    kdbp("  hvm:%d priv:%d need_iommu:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_privileged, dp->need_iommu,
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
+    kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
+    kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
+         dp->is_shut_down, dp->shutdown_code);
+    kdbp("  pausecnt:0x%08x vm_assist:0x"KDBFL" refcnt:0x%08x\n",
+         dp->pause_count.counter, dp->vm_assist, dp->refcnt.counter);
+    kdbp("  &domain_dirty_cpumask:%p\n", &dp->domain_dirty_cpumask); 
+
+    kdbp("  shared == vcpu_info[]: %p\n",  dp->shared_info); 
+    kdbp("    arch_shared: maxpfn: %lx pfn-mfn-frame-ll mfn: %lx\n", 
+         arch_get_max_pfn(dp), arch_get_pfn_to_mfn_frame_list_list(dp));
+    kdbp("\n");
+    kdbp("  arch_domain at : %p\n", ap);
+
+#ifdef CONFIG_X86_64
+    kdbp("    pt_pages:0x%p ", ap->mm_perdomain_pt_pages);
+    kdbp("    l2:0x%p l3:0x%p\n", ap->mm_perdomain_l2, ap->mm_perdomain_l3);
+#else
+    kdbp("    pt:0x%p ", ap->mm_perdomain_pt);
+#endif
+#ifdef CONFIG_X86_32
+    kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
+#endif
+    kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
+    kdb_pr_dom_pg_modes(dp);
+    kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
+         KDB_PGLLE(ap->p2m->pages));
+    kdbp("       max_mapped_pfn:"KDBFL, ap->p2m->max_mapped_pfn);
+#if XEN_SUBVERSION > 0 && XEN_VERSION == 4              /* xen 4.1 and above */
+    kdbp("  phys_table:%p\n", ap->p2m->phys_table.pfn);
+#else
+    kdbp("  phys_table.pfn:"KDBFL"\n", ap->phys_table.pfn);
+#endif
+    kdbp("    physaddr_bitsz:%d 32bit_pv:%d has_32bit_shinfo:%d\n", 
+         ap->physaddr_bitsize, ap->is_32bit_pv, ap->has_32bit_shinfo);
+    kdb_pr_vtsc_info(ap);
+    kdbp("  sched:0x%p  &handle:0x%p\n", dp->sched_priv, &dp->handle);
+    kdbp("  vcpu ptrs:\n   ");
+    for_each_vcpu(dp, vp) {
+        kdbp(" %d:%p", vp->vcpu_id, vp);
+        if (++printed % 4 == 0) kdbp("\n   ");
+    }
+    kdbp("\n");
+}
+
+/* 
+ * FUNCTION: Dispaly (current) domain/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dom(void)
+{
+    kdbp("dom [all|domid]: Display current/all/given domain/s\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dom(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int id;
+    struct domain *dp = current->domain;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dom();
+
+    if (argc > 1) {
+        for(dp=domain_list; dp; dp=dp->next_in_list)
+            if (kdb_str2deci(argv[1], &id) && dp->domain_id==id)
+                kdb_display_dom(dp);
+            else if (!strcmp(argv[1], "all")) 
+                kdb_display_dom(dp);
+    } else {
+        kdbp("Displaying current domain :\n");
+        kdb_display_dom(dp);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dirq(void)
+{
+    kdbp("dirq : dump irq bindings\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dirq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long irq, sz, offs, addr;
+    char buf[KSYM_NAME_LEN+1];
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dirq();
+
+#if XEN_VERSION < 4 && XEN_SUBVERSION < 5           /* xen 3.4.x or below */
+    kdbp("idx/irq#/status: all are in decimal\n");
+    kdbp("idx  irq#  status   action(handler name devid)\n");
+    for (irq=0; irq < NR_VECTORS; irq++) {
+        irq_desc_t  *dp = &irq_desc[irq];
+        if (!dp->action)
+            continue;
+        addr = (unsigned long)dp->action->handler;
+        kdbp("[%3ld]:irq:%3d st:%3d f:%s devnm:%s devid:0x%p\n",
+             i, vector_to_irq(irq), dp->status, (dp->status & IRQ_GUEST) ? 
+                            "GUEST IRQ" : symbols_lookup(addr, &sz, &offs, buf),
+             dp->action->name, dp->action->dev_id);
+    }
+#else
+    kdbp("irq_desc[]:%p nr_irqs: $%d nr_irqs_gsi: $%d\n", irq_desc, nr_irqs, 
+          nr_irqs_gsi);
+    kdbp("irq/vec#/status: in decimal. affinity in hex, not bitmap\n");
+    kdbp("irq-- vec sta function----------- name---- type--------- ");
+    kdbp("aff devid------------\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        void *devidp;
+        const char *symp, *nmp;
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+
+        if (!dp->handler || dp->handler==&no_irq_type || dp->status & IRQ_GUEST)
+            continue;
+
+        addr = dp->action ? (unsigned long)dp->action->handler : 0;
+        symp = addr ? symbols_lookup(addr, &sz, &offs, buf) : "n/a ";
+        nmp = addr ? dp->action->name : "n/a ";
+        devidp = addr ? dp->action->dev_id : NULL;
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %03d %03d %-19s %-8s %-13s %3s 0x%p\n", irq, archp->vector,
+             dp->status, symp, nmp, dp->handler->typename, affstr, devidp);
+    }
+    kdb_prnt_guest_mapped_irqs();
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+kdb_prnt_vec_irq_table(int cpu)
+{
+    int i,j, *tbl = per_cpu(vector_irq, cpu);
+
+    kdbp("CPU %d : ", cpu);
+    for (i=0, j=0; i < NR_VECTORS; i++)
+        if (tbl[i] != -1) {
+            kdbp("(%3d:%3d) ", i, tbl[i]);
+            if (!(++j % 5))
+                kdbp("\n        ");
+        }
+    kdbp("\n");
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dvit(void)
+{
+    kdbp("dvit [cpu|all]: dump (per cpu)vector irq table\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvit(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu, ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvit();
+    
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all")) 
+            cpu = -1;
+        else if (!kdb_str2deci(argv[1], &cpu)) {
+            kdbp("Invalid cpu:%d\n", cpu);
+            return kdb_usgf_dvit();
+        }
+    } else
+        cpu = ccpu;
+
+    kdbp("Per CPU vector irq table pairs (vector:irq) (all decimals):\n");
+    if (cpu != -1) 
+        kdb_prnt_vec_irq_table(cpu);
+    else
+        for_each_online_cpu(cpu) 
+            kdb_prnt_vec_irq_table(cpu);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* do vmexit on all cpu's so intel VMCS can be dumped */
+static kdb_cpu_cmd_t 
+kdb_all_cpu_flush_vmcs(void)
+{
+    int cpu, ccpu = smp_processor_id();
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdb_curr_cpu_flush_vmcs();
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE){  /* hung cpu */
+                kdbp("Skipping (hung?) cpu %d\n", cpu);
+                continue;
+            }
+            kdb_cpu_cmd[cpu] = KDB_CPU_DO_VMEXIT;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_DO_VMEXIT);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display VMCS or VMCB */
+static kdb_cpu_cmd_t
+kdb_usgf_dvmc(void)
+{
+    kdbp("dvmc [domid][vcpuid] : Dump vmcs/vmcb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvmc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid = 0;  /* unsigned type don't like -1 */
+    int vcpuid = -1;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvmc();
+
+    if (argc > 1) { 
+        if (!kdb_str2domid(argv[1], &domid, 1))
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2 && !kdb_str2deci(argv[2], &vcpuid)) {
+        kdbp("Bad vcpuid: 0x%x\n", vcpuid);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        kdb_all_cpu_flush_vmcs();
+        kdb_dump_vmcs(domid, (int)vcpuid);
+    } else {
+        kdb_dump_vmcb(domid, (int)vcpuid);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_mmio(void)
+{
+    kdbp("mmio: dump mmio related info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmio(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmio();
+
+    kdbp("r/o mmio ranges:\n");
+    rangeset_printk(mmio_ro_ranges);
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump timer/timers queues */
+static kdb_cpu_cmd_t
+kdb_usgf_dtrq(void)
+{
+    kdbp("dtrq: dump timer queues on all cpus\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dtrq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dtrq();
+
+    kdb_dump_timer_queues();
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct idte {
+    uint16_t offs0_15;
+    uint16_t selector;
+    uint16_t meta;
+    uint16_t offs16_31;
+    uint32_t offs32_63;
+    uint32_t resvd;
+};
+
+#ifdef __x86_64__
+static void
+kdb_print_idte(int num, struct idte *idtp) 
+{
+    uint16_t mta = idtp->meta;
+    char dpl = ((mta & 0x6000) >> 13);
+    char present = ((mta &0x8000) >> 15);
+    int tval = ((mta &0x300) >> 8);
+    char *type = (tval == 1) ? "Task" : ((tval== 2) ? "Intr" : "Trap");
+    domid_t domid = idtp->selector==__HYPERVISOR_CS64 ? DOMID_IDLE :
+                    current->domain->domain_id;
+    uint64_t addr = idtp->offs0_15 | ((uint64_t)idtp->offs16_31 << 16) | 
+                    ((uint64_t)idtp->offs32_63 << 32);
+
+    kdbp("[%03d]: %s %x  %x %04x:%016lx ", num, type, dpl, present,
+         idtp->selector, addr); 
+    kdb_prnt_addr2sym(domid, addr, "\n");
+}
+
+/* Dump 64bit idt table currently on this cpu. Intel Vol 3 section 5.14.1 */
+static kdb_cpu_cmd_t
+kdb_usgf_didt(void)
+{
+    kdbp("didt : dump IDT table on the current cpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i;
+    struct idte *idtp = (struct idte *)idt_tables[smp_processor_id()];
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_didt();
+
+    kdbp("IDT at:%p\n", idtp);
+    kdbp("idt#  Type DPL P addr (all hex except idt#)\n", idtp);
+    for (i=0; i < 256; i++, idtp++) 
+        kdb_print_idte(i, idtp);
+    return KDB_CPU_MAIN_KDB;
+}
+#else
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbp("kdb: Please implement me in 32bit hypervisor\n");
+    return KDB_CPU_MAIN_KDB;
+}
+#endif
+
+struct gdte {             /* same for TSS and LDT */
+    ulong limit0:16;
+    ulong base0:24;       /* linear address base, not pa */
+    ulong acctype:4;      /* Type: access rights */
+    ulong S:1;            /* S: 0 = system, 1 = code/data */
+    ulong DPL:2;          /* DPL */
+    ulong P:1;            /* P: Segment Present */
+    ulong limit1:4;
+    ulong AVL:1;          /* AVL: avail for use by system software */
+    ulong L:1;            /* L: 64bit code segment */
+    ulong DB:1;           /* D/B */
+    ulong G:1;            /* G: granularity */
+    ulong base1:8;        /* linear address base, not pa */
+};
+
+union gdte_u {
+    struct gdte gdte;
+    u64 gval;
+};
+
+struct call_gdte {
+    unsigned short offs0:16;
+    unsigned short sel:16;
+    unsigned short misc0:16;
+    unsigned short offs1:16;
+};
+
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
+union sgdte_u {
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
+    u64 sgval;
+};
+
+/* return binary form of a hex in string : max 4 chars 0000 to 1111 */
+static char *kdb_ret_acctype(uint acctype)
+{
+    static char buf[16];
+    char *p = buf;
+    int i;
+
+    if (acctype > 0xf) {
+        buf[0] = buf[1] = buf[2] = buf[3] = '?';
+        buf[5] = '\n';
+        return buf;
+    }
+    for (i=0; i < 4; i++, p++, acctype=acctype>>1)
+        *p = (acctype & 0x1) ? '1' : '0';
+
+    return buf;
+}
+
+/* Display GDT table. IA-32e mode is assumded. */
+/* first display non system descriptors then display system descriptors */
+static kdb_cpu_cmd_t
+kdb_usgf_dgdt(void)
+{
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
+         "given vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dgdt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    union gdte_u u1;
+    ulong start_addr, end_addr, taddr=0;
+    domid_t domid = DOMID_IDLE;
+    int idx;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dgdt();
+
+    if (argc > 1) {
+        if (argc != 3)
+            return kdb_usgf_dgdt();
+
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
+        } else {
+            kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
+            return kdb_usgf_dgdt();
+        }
+    } else {
+        __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
+    }
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
+    kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
+         "--Base Addr ----  Limit\n");
+    kdbp("                              Type\n");
+
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+            continue;
+
+        if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
+            continue;               /* what an effin x86 mess */
+
+        idx = (taddr - start_addr) / 8;
+        if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
+            taddr += sizeof(ulong);
+            continue;
+        }
+        kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
+             u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
+             (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
+             u1.gdte.limit0 | (u1.gdte.limit1<<16));
+    }
+
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
+        uint acctype;
+        u64 upper, addr64=0;
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
+            u1.gval == 0 || u1.gdte.S == 1) {
+            continue;
+        }
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+            kdbp("Could not read upper 8 bytes of system desc\n");
+            upper = 0;
+        }
+        acctype = u1.gdte.acctype;
+        if (acctype != 2 && acctype != 9 && acctype != 11 && acctype !=12 &&
+            acctype != 14 && acctype != 15)
+            continue;
+
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
+
+        /* Vol 3A: table: 3-2  page: 3-19 */
+        if (acctype == 2) {
+            kdbp("LDT gate (0010)\n");
+        }
+        else if (acctype == 9) {
+            kdbp("TSS avail gate(1001)\n");
+        }
+        else if (acctype == 11) {
+            kdbp("TSS busy gate(1011)\n");
+        }
+        else if (acctype == 12) {
+            kdbp("CALL gate (1100)\n");
+        }
+        else if (acctype == 14) {
+            kdbp("IDT gate (1110)\n");
+        }
+        else if (acctype == 15) {
+            kdbp("Trap gate (1111)\n"); 
+        }
+
+        if (acctype == 2 || acctype == 9 || acctype == 11) {
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display scheduler basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_sched(void)
+{
+    kdbp("sched: show schedular info and run queues\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sched(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_sched();
+
+    kdb_print_sched_info();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display MMU basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_mmu(void)
+{
+    kdbp("mmu: print basic MMU info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmu();
+
+    kdbp("MMU Info:\n");
+    kdbp("total  pages: %lx\n", total_pages);
+    kdbp("max page/mfn: %lx\n", max_page);
+    kdbp("frame_table:  %p\n", frame_table);
+    kdbp("DIRECTMAP_VIRT_START:  %lx\n", DIRECTMAP_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_START: %lx\n", HYPERVISOR_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_END:   %lx\n", HYPERVISOR_VIRT_END);
+    kdbp("RO_MPT_VIRT_START:     %lx\n", RO_MPT_VIRT_START);
+    kdbp("PERDOMAIN_VIRT_START:  %lx\n", PERDOMAIN_VIRT_START);
+    kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
+    kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
+         (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
+
+    kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
+    kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
+    kdbp("LAST_RESERVED_GDT_ENTRY: %lx\n", (ulong)LAST_RESERVED_GDT_ENTRY);
+    kdbp("  Per cpu non-compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(gdt_table, cpu));
+    }
+    kdbp("  Per cpu compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
+    }
+    kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
+#ifdef USER_MAPPINGS_ARE_GLOBAL
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
+#else
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
+#endif
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* for HVM/HYB guests, go thru EPT. For PV guest we need to go to the btree. 
+ * btree: pfn_to_mfn_frame_list_list is root that points (has mfns of) upto 16
+ * pages (call 'em l2 nodes) that contain mfns of guest p2m table pages 
+ * NOTE: num of entries in a p2m page is same as num of entries in l2 node */
+static noinline ulong
+kdb_gpfn2mfn(struct domain *dp, ulong gpfn, p2m_type_t *typep) 
+{
+    int idx;
+
+    if ( !paging_mode_translate(dp) ) {
+        mfn_t *mfn_va, mfn = arch_get_pfn_to_mfn_frame_list_list(dp);
+        int g_longsz = kdb_guest_bitness(dp->domain_id)/8;
+        int entries_per_pg = PAGE_SIZE/g_longsz;
+        const int shift = get_count_order(entries_per_pg);
+
+	if ( !mfn_valid(mfn) ) {
+	    kdbp("Invalid frame_list_list mfn:%lx for non-xlate guest\n", mfn);
+	    return INVALID_MFN;
+	}
+
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn >> 2*shift;     /* index in root page/node */
+        if (idx > 15) {
+            kdbp("gpfn:%lx idx:%x not in frame list limit of z16\n", gpfn, idx);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        if (mfn==0) {
+            kdbp("No mfn for idx:%d for gpfn:%lx in root pg\n", idx, gpfn);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn_va = map_domain_page(mfn);
+        KDBGP1("p2m: idx:%x fll:%lx mfn of 2nd lvl page:%lx\n", idx,
+               arch_get_pfn_to_mfn_frame_list_list(dp), mfn);
+
+        idx = (gpfn>>shift) & ((1<<shift)-1);     /* idx in l2 node */
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+        if (mfn == 0) {
+            kdbp("No mfn entry at:%x in 2nd lvl pg for gpfn:%lx\n", idx, gpfn);
+            return INVALID_MFN;
+        }
+        KDBGP1("p2m: idx:%x  mfn of p2m page:%lx\n", idx, mfn); 
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn & ((1<<shift)-1);
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+
+	*typep = -1;
+        return mfn;
+    } else
+        return get_gfn_query(dp, gpfn, typep);
+
+    return INVALID_MFN;
+}
+
+/* given a pfn, find it's mfn */
+static kdb_cpu_cmd_t
+kdb_usgf_p2m(void)
+{
+    kdbp("p2m domid 0xgpfn : gpfn to mfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_p2m(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gpfn, mfn;
+    p2m_type_t p2mtype;
+
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
+        !kdb_str2ulong(argv[2], &gpfn)) {
+
+        return kdb_usgf_p2m();
+    }
+    mfn = kdb_gpfn2mfn(dp, gpfn, &p2mtype);
+    if ( paging_mode_translate(dp) )
+        kdbp("p2m[%lx] == %lx type:%d/0x%x\n", gpfn, mfn, p2mtype, p2mtype);
+    else 
+        kdbp("p2m[%lx] == %lx type:N/A(PV)\n", gpfn, mfn);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an mfn, lookup pfn in the MPT */
+static kdb_cpu_cmd_t
+kdb_usgf_m2p(void)
+{
+    kdbp("m2p 0xmfn: mfn to pfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_m2p(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    mfn_t mfn;
+    if (argc > 1 && kdb_str2ulong(argv[1], &mfn))
+        if (mfn_valid(mfn))
+            kdbp("mpt[%x] == %lx\n", mfn, machine_to_phys_mapping[mfn]);
+        else
+            kdbp("Invalid mfn:%lx\n", mfn);
+    else
+        kdb_usgf_m2p();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void 
+kdb_pr_pg_pgt_flds(unsigned long type_info)
+{
+    switch (type_info & PGT_type_mask) {
+        case (PGT_l1_page_table):
+            kdbp("    page is PGT_l1_page_table\n");
+            break;
+        case PGT_l2_page_table:
+            kdbp("    page is PGT_l2_page_table\n");
+            break;
+        case PGT_l3_page_table:
+            kdbp("    page is PGT_l3_page_table\n");
+            break;
+        case PGT_l4_page_table:
+            kdbp("    page is PGT_l4_page_table\n");
+            break;
+        case PGT_seg_desc_page:
+            kdbp("    page is seg desc page\n");
+            break;
+        case PGT_writable_page:
+            kdbp("    page is writable page\n");
+            break;
+        case PGT_shared_page:
+            kdbp("    page is shared page\n");
+            break;
+    }
+    if (type_info & PGT_pinned)
+        kdbp("    page is pinned\n");
+    if (type_info & PGT_validated)
+        kdbp("    page is validated\n");
+    if (type_info & PGT_pae_xen_l2)
+        kdbp("    page is PGT_pae_xen_l2\n");
+    if (type_info & PGT_partial)
+        kdbp("    page is PGT_partial\n");
+    if (type_info & PGT_locked)
+        kdbp("    page is PGT_locked\n");
+}
+
+static void
+kdb_pr_pg_pgc_flds(unsigned long count_info)
+{
+    if (count_info & PGC_allocated)
+        kdbp("  PGC_allocated");
+    if (count_info & PGC_xen_heap)
+        kdbp("  PGC_xen_heap");
+    if (count_info & PGC_page_table)
+        kdbp("  PGC_page_table");
+    if (count_info & PGC_broken)
+        kdbp("  PGC_broken");
+#if XEN_VERSION < 4                                 /* xen 3.x.x */
+    if (count_info & PGC_offlining)
+        kdbp("  PGC_offlining");
+    if (count_info & PGC_offlined)
+        kdbp("  PGC_offlined");
+#else
+    if (count_info & PGC_state_inuse)
+        kdbp("  PGC_inuse");
+    if (count_info & PGC_state_offlining)
+        kdbp("  PGC_state_offlining");
+    if (count_info & PGC_state_offlined)
+        kdbp("  PGC_state_offlined");
+    if (count_info & PGC_state_free)
+        kdbp("  PGC_state_free");
+#endif
+    kdbp("\n");
+}
+
+/* print struct page_info{} given ptr to it or an mfn
+ * NOTE: that given an mfn there seems no way of knowing how it's used, so
+ *       here we just print all info and let user decide what's applicable */
+static kdb_cpu_cmd_t
+kdb_usgf_dpage(void)
+{
+    kdbp("dpage mfn|page-ptr : Display struct page\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dpage(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long val;
+    struct page_info *pgp;
+    struct domain *dp;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dpage();
+
+    if ((kdb_str2ulong(argv[1], &val) == 0)      ||
+        (val <  (ulong)frame_table && !mfn_valid(val))) {
+
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdbp("Page Info:\n");
+    if (val <= (ulong)frame_table) {       /* arg is mfn */
+        pgp = mfn_to_page(val);
+        kdbp("  mfn: %lx page_info:%p\n", val, pgp);
+    } else {
+        pgp = (struct page_info *)val; /* arg is struct page{} */
+        if (pgp < frame_table || pgp >= frame_table+max_page) {
+            kdbp("Invalid page ptr. below/beyond max_page\n");
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdbp("  mfn: %lx page_info:%p\n", page_to_mfn(pgp), pgp);
+    } 
+    kdbp("  count_info: %016lx  (refcnt: %x)\n", pgp->count_info,
+         pgp->count_info & PGC_count_mask);
+#if XEN_VERSION > 3 || XEN_SUBVERSION > 3             /* xen 3.4.x or later */
+    kdb_pr_pg_pgc_flds(pgp->count_info);
+
+    kdbp("In use info:\n");
+    kdbp("  type_info:%016lx\n", pgp->u.inuse.type_info);
+    kdb_pr_pg_pgt_flds(pgp->u.inuse.type_info);
+    dp = page_get_owner(pgp);
+    kdbp("  domid:%d (pickled:%lx)\n", dp ? dp->domain_id : -1, 
+         pgp->v.inuse._domain);
+
+    kdbp("Shadow Info:\n");
+    kdbp("  type:%x pinned:%x count:%x\n", pgp->u.sh.type, pgp->u.sh.pinned,
+         pgp->u.sh.count);
+    kdbp("  back:%lx  shadow_flags:%x  next_shadow:%lx\n", pgp->v.sh.back,
+         pgp->shadow_flags, pgp->next_shadow);
+
+    kdbp("Free Info\n");
+    kdbp("  need_tlbflush:%d order:%d tlbflush_timestamp:%x\n",
+         pgp->u.free.need_tlbflush, pgp->v.free.order, 
+         pgp->tlbflush_timestamp);
+#else
+    if (pgp->count_info & PGC_allocated)            /* page allocated */
+        kdbp("  PGC_allocated");
+    if (pgp->count_info & PGC_page_table)           /* page table page */
+        kdbp("  PGC_page_table");
+    kdbp("\n");
+    kdbp("  page is %s xen heap page\n", is_xen_heap_page(pgp) ? "a":"NOT");
+    kdbp("  cacheattr:%x\n", (pgp->count_info>>PGC_cacheattr_base) & 7);
+    if (pgp->count_info & PGC_count_mask) {         /* page in use */
+        dp = pgp->u.inuse._domain;         /* pickled domain */
+        kdbp("  page is in use\n");
+        kdbp("    domid: %d  (pickled dom:%x)\n", 
+             dp ? (unpickle_domptr(dp))->domain_id : -1, dp);
+        kdbp("    type_info: %lx\n", pgp->u.inuse.type_info);
+        kdb_prt_pg_type(pgp->u.inuse.type_info);
+    } else {                                         /* page is free */
+        kdbp("  page is free\n");
+        kdbp("    order: %x\n", pgp->u.free.order);
+        kdbp("    cpumask: %lx\n", pgp->u.free.cpumask.bits);
+    }
+    kdbp("  tlbflush/shadow_flags: %lx\n", pgp->shadow_flags);
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display asked msr value */
+static kdb_cpu_cmd_t
+kdb_usgf_dmsr(void)
+{
+    kdbp("dmsr address : Display msr value\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dmsr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long addr, val;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dmsr();
+
+    if ((kdb_str2ulong(argv[1], &addr) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    rdmsrl(addr, val);
+    kdbp("msr: %lx  val:%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_cpuid(void)
+{
+    kdbp("cpuid eax : Display cpuid value returned in rax\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_cpuid(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long rax=0, rbx=0, rcx=0, rdx=0;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_cpuid();
+
+    if ((kdb_str2ulong(argv[1], &rax) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+#if 0
+    __asm__ __volatile__ (
+            /* "pushl %%rax  \n" */
+
+            "movl %0, %%rax  \n"
+            "cpuid           \n" 
+            : "=&a" (rax), "=b" (rbx), "=c" (rcx), "=d" (rdx)
+            : "0" (rax)
+            : "rax", "rbx", "rcx", "rdx", "memory");
+#endif
+    cpuid(rax, &rax, &rbx, &rcx, &rdx);
+    kdbp("rax: %016lx  rbx:%016lx rcx:%016lx rdx:%016lx\n", rax, rbx,
+         rcx, rdx);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_wept(void)
+{
+    kdbp("wept domid gfn: walk ept table for given domid and gfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_wept(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gfn;
+
+    if ((argc > 1 && *argv[1] == '?') || argc != 3)
+        return kdb_usgf_wept();
+    if ((dp=kdb_strdomid2ptr(argv[1], 1)) && kdb_str2ulong(argv[2], &gfn))
+        ept_walk_table(dp, gfn);
+    else
+        kdb_usgf_wept();
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Save symbols info for a guest, dom0 or other...
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_sym(void)
+{
+   kdbp("sym domid &kallsyms_names &kallsyms_addresses &kallsyms_num_syms\n");
+   kdbp("\t [&kallsyms_token_table] [&kallsyms_token_index]\n");
+   kdbp("\ttoken _table and _index MUST be specified for el5\n");
+   return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sym(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong namesp, addrap, nump, toktblp, tokidxp;
+    domid_t domid;
+
+    if (argc < 5) {
+        return kdb_usgf_sym();
+    }
+    toktblp = tokidxp = 0;     /* optional parameters */
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &namesp)   &&
+        kdb_str2ulong(argv[3], &addrap)   &&
+        kdb_str2ulong(argv[4], &nump)     && 
+        (argc==5 || (argc==7 && kdb_str2ulong(argv[5], &toktblp) &&
+                                kdb_str2ulong(argv[6], &tokidxp)))) {
+
+        kdb_sav_dom_syminfo(domid, namesp, addrap,nump,toktblp,tokidxp);
+    } else
+        kdb_usgf_sym();
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* mods is the dumb ass &modules. modules is struct {nxt, prev}, and not ptr */
+static void
+kdb_dump_linux_modules(domid_t domid, ulong mods, uint nxtoffs, uint nmoffs, 
+                       uint coreoffs)
+{
+    const int bufsz = 56;
+    char buf[bufsz];
+    uint64_t addr, addrval, *nxtptr, *modptr;
+    uint i, num = 8;
+
+    if (kdb_guest_bitness(domid) == 32)
+        num = 4;
+
+    /* first read modules{}.next ptr */
+    if (kdb_read_mem(mods, (kdbbyt_t *)&nxtptr, num, domid) != num) {
+        kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+        return;
+    }
+
+    KDBGP("mods:%p nxtptr:%p nmoffs:%x coreoffs:%x\n", (void *)mods, nxtptr,
+          nmoffs, coreoffs);
+
+    while ((uint64_t)nxtptr != mods) {
+
+        modptr = (uint64_t *) ((ulong)nxtptr - nxtoffs);
+
+        addr = (ulong)modptr + coreoffs;
+        if (kdb_read_mem(addr, (kdbbyt_t *)&addrval, num, domid) != num) {
+            kdbp("ERROR: Could not read mod addr at :%p\n", (void *)addr);
+            return;
+        }
+
+        KDBGP("modptr:%p addr:%p\n", modptr, (void *)addr);
+        addr = (ulong)modptr + nmoffs;
+        i=0;
+        do {
+            if (kdb_read_mem(addr, (kdbbyt_t *)&buf[i], 1, domid) != 1) {
+                kdbp("ERROR:Could not read name ch at addr:%p\n", (void *)addr);
+                return;
+            }
+            addr++;
+        } while (buf[i] && i++ < bufsz);
+        buf[bufsz-1] = '\0';
+
+        kdbp("%016lx %016lx %s\n", modptr, addrval, buf);
+
+        if (kdb_read_mem((ulong)nxtptr, (kdbbyt_t *)&nxtptr, num, domid)!=num) {
+            kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+            return;
+        }
+        KDBGP("nxtptr:%p addr:%p\n", nxtptr, (void *)addr);
+    } 
+}
+
+/* Display modules loaded in linux guest */
+static kdb_cpu_cmd_t
+kdb_usgf_mod(void)
+{
+   kdbp("mod domid &modules next-offs name-offs module_core-offs\n");
+   kdbp("\twhere next-offs: &((struct module *)0)->list.next\n");
+   kdbp("\tname-offs: &((struct module *)0)->name etc..\n");
+   kdbp("\tDisplays all loaded modules in the linux guest\n");
+   kdbp("\tEg: mod 0 ffffffff80302780 8 0x18 0x178\n");
+
+   return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_cmdf_mod(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong mods, nxtoffs, nmoffs, coreoffs;
+    domid_t domid;
+
+    if (argc < 6) {
+        return kdb_usgf_mod();
+    }
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &mods)     &&
+        kdb_str2ulong(argv[3], &nxtoffs)  &&
+        kdb_str2ulong(argv[4], &nmoffs)   &&
+        kdb_str2ulong(argv[5], &coreoffs)) {
+
+        kdbp("modptr address name\n");
+        kdb_dump_linux_modules(domid, mods, nxtoffs, nmoffs, coreoffs);
+    } else
+        kdb_usgf_mod();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* toggle kdb debug trace level */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbdbg(void)
+{
+    kdbp("kdbdbg : trace info to debug kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_kdbdbg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbdbg();
+
+    kdbdbg = (kdbdbg==3) ? 0 : (kdbdbg+1);
+    kdbp("kdbdbg set to:%d\n", kdbdbg);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_reboot(void)
+{
+    kdbp("reboot: reboot system\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_reboot(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_reboot();
+
+    machine_restart(500);
+    return KDB_CPU_MAIN_KDB;              /* not reached */
+}
+
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcon(void)
+{
+    kdbp("trcon: turn user added kdb tracing on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcon(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcon();
+
+    kdb_trcon = 1;
+    kdbp("kdb tracing is now on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcoff(void)
+{
+    kdbp("trcoff: turn user added kdb tracing off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcoff(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcoff();
+
+    kdb_trcon = 0;
+    kdbp("kdb tracing is now off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcz(void)
+{
+    kdbp("trcz : zero entire trace buffer\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcz(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcz();
+
+    kdb_trczero();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcp(void)
+{
+    kdbp("trcp : give hints to dump trace buffer via dw/dd command\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcp();
+
+    kdb_trcp();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* print some basic info, constants, etc.. */
+static kdb_cpu_cmd_t
+kdb_usgf_info(void)
+{
+    kdbp("info : display basic info, constants, etc..\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_info(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    struct cpuinfo_x86 *bcdp;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_info();
+
+    kdbp("Version: %d.%d.%s (%s@%s) %s\n", xen_major_version(), 
+         xen_minor_version(), xen_extra_version(), xen_compile_by(), 
+         xen_compile_domain(), xen_compile_date());
+    kdbp("__XEN_LATEST_INTERFACE_VERSION__ : 0x%x\n", 
+         __XEN_LATEST_INTERFACE_VERSION__);
+    kdbp("__XEN_INTERFACE_VERSION__: 0x%x\n", __XEN_INTERFACE_VERSION__);
+
+    bcdp = &boot_cpu_data;
+    kdbp("CPU: (all decimal)");
+        if (bcdp->x86_vendor == X86_VENDOR_AMD)
+            kdbp(" AMD");
+        else
+            kdbp(" INTEL");
+        kdbp(" family:%d model:%d\n", bcdp->x86, bcdp->x86_model);
+        kdbp("     vendor_id:%16s model_id:%64s\n", bcdp->x86_vendor_id,
+             bcdp->x86_model_id);
+        kdbp("     cpuidlvl:%d cache:sz:%d align:%d\n", bcdp->cpuid_level,
+             bcdp->x86_cache_size, bcdp->x86_cache_alignment);
+        kdbp("     power:%d cores: max:%d booted:%d siblings:%d apicid:%d\n",
+             bcdp->x86_power, bcdp->x86_max_cores, bcdp->booted_cores,
+             bcdp->x86_num_siblings, bcdp->apicid);
+        kdbp("     ");
+        if (cpu_has_apic)
+            kdbp("_apic");
+        if (cpu_has_sep)
+            kdbp("|_sep");
+        if (cpu_has_xmm3)
+            kdbp("|_xmm3");
+        if (cpu_has_ht)
+            kdbp("|_ht");
+        if (cpu_has_nx)
+            kdbp("|_nx");
+        if (cpu_has_clflush)
+            kdbp("|_clflush");
+        if (cpu_has_page1gb)
+            kdbp("|_page1gb");
+        if (cpu_has_ffxsr)
+            kdbp("|_ffxsr");
+        if (cpu_has_x2apic)
+            kdbp("|_x2apic");
+    kdbp("\n\n");
+    kdbp("CC:");
+#if defined(CONFIG_X86_64)
+        kdbp(" CONFIG_X86_64");
+#endif
+#if defined(CONFIG_COMPAT)
+        kdbp(" CONFIG_COMPAT");
+#endif
+#if defined(CONFIG_PAGING_ASSISTANCE)
+        kdbp(" CONFIG_PAGING_ASSISTANCE");
+#endif
+    kdbp("\n");
+    kdbp("cpu has following features:\n");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ? 
+         "X86_FEATURE_TSC_RELIABLE" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_CONSTANT_TSC)? "X86_FEATURE_CONSTANT_TSC":"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ? "X86_FEATURE_NONSTOP_TSC" :"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_RDTSCP) ?  "X86_FEATURE_RDTSCP" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_FXSR) ?  "X86_FEATURE_FXSR" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_CPUID_FAULTING) ?  
+         "X86_FEATURE_CPUID_FAULTING" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_PAGE1GB) ?  "X86_FEATURE_PAGE1GB" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_MWAIT) ?  "X86_FEATURE_MWAIT" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_X2APIC) ?  "X86_FEATURE_X2APIC":"");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_XSAVE) ?  "X86_FEATURE_XSAVE":"");
+    kdbp("\n");
+
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
+    kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
+    kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
+
+    kdbp("\nDomains and their vcpus:\n");
+    for_each_domain(dp) {
+        struct vcpu *vp;
+        int printed=0;
+        kdbp("  Domain: {id:%d 0x%x   ptr:%p%s}  VCPUs:\n", 
+             dp->domain_id, dp->domain_id, dp, dp->is_dying ? " DYING":"");
+        for(vp=dp->vcpu[0]; vp; vp = vp->next_in_list) {
+            kdbp("  {id:%d p:%p runstate:%d}", vp->vcpu_id, vp, 
+                 vp->runstate.state);
+            if (++printed % 2 == 0) kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_cur(void)
+{
+    kdbp("cur : display current domid and vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Checking for guest_mode() not feasible here. if dom0->hcall->bp in xen, 
+ * then g_m() will show xen, but vcpu is still dom0. hence just look at 
+ * current only */
+static kdb_cpu_cmd_t
+kdb_cmdf_cur(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t id = current->domain->domain_id;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cur();
+
+    kdbp("domid: %d{%p} %s vcpu:%d {%p} ", id, current->domain,
+         (id==DOMID_IDLE) ? "(IDLE)" : "", current->vcpu_id, current);
+
+    /* if (id != DOMID_IDLE) { */
+        if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+            u64 addr = -1;
+            __vmptrst(&addr);
+            kdbp(" VMCS:"KDBFL, addr);
+        }
+    /* } */
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* stub to quickly and easily add a new command */
+static kdb_cpu_cmd_t
+kdb_usgf_usr1(void)
+{
+    kdbp("usr1: add any arbitrary cmd using this in kdb_cmds.c\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_usr1(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_h(void)
+{
+    kdbp("h: display all commands. See kdb/README for more info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_h(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbtab_t *tbp;
+
+    kdbp(" - ccpu is current cpu \n");
+    kdbp(" - following are always in decimal:\n");
+    kdbp("     vcpu num, cpu num, domid\n");
+    kdbp(" - otherwise, almost all numbers are in hex (0x not needed)\n");
+    kdbp(" - output: $17 means decimal 17\n");
+    kdbp(" - domid 7fff($32767) refers to hypervisor\n");
+    kdbp(" - if no domid before function name, then it's hypervisor\n");
+    kdbp(" - earlykdb in xen grub line to break into kdb during boot\n");
+    kdbp(" - command ? will show the command usage\n");
+    kdbp("\n");
+
+    for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_usgf; tbp++)
+        (*tbp->kdb_cmd_usgf)();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ===================== cmd table initialization ========================== */
+void __init
+kdb_init_cmdtab(void)
+{
+  static kdbtab_t _kdb_cmd_table[] = {
+
+    {"info", kdb_cmdf_info, kdb_usgf_info, 1, KDB_REPEAT_NONE},
+    {"cur",  kdb_cmdf_cur, kdb_usgf_cur, 1, KDB_REPEAT_NONE},
+
+    {"f",  kdb_cmdf_f,  kdb_usgf_f,  1, KDB_REPEAT_NONE},
+    {"fg", kdb_cmdf_fg, kdb_usgf_fg, 1, KDB_REPEAT_NONE},
+
+    {"dw",  kdb_cmdf_dw,  kdb_usgf_dw,  1, KDB_REPEAT_NO_ARGS},
+    {"dd",  kdb_cmdf_dd,  kdb_usgf_dd,  1, KDB_REPEAT_NO_ARGS},
+    {"dwm", kdb_cmdf_dwm, kdb_usgf_dwm, 1, KDB_REPEAT_NO_ARGS},
+    {"ddm", kdb_cmdf_ddm, kdb_usgf_ddm, 1, KDB_REPEAT_NO_ARGS},
+    {"dr",  kdb_cmdf_dr,  kdb_usgf_dr,  1, KDB_REPEAT_NONE},
+    {"drg", kdb_cmdf_drg, kdb_usgf_drg, 1, KDB_REPEAT_NONE},
+
+    {"dis", kdb_cmdf_dis,  kdb_usgf_dis,  1, KDB_REPEAT_NO_ARGS},
+    {"dism",kdb_cmdf_dism, kdb_usgf_dism, 1, KDB_REPEAT_NO_ARGS},
+
+    {"mw", kdb_cmdf_mw, kdb_usgf_mw, 1, KDB_REPEAT_NONE},
+    {"md", kdb_cmdf_md, kdb_usgf_md, 1, KDB_REPEAT_NONE},
+    {"mr", kdb_cmdf_mr, kdb_usgf_mr, 1, KDB_REPEAT_NONE},
+
+    {"bc", kdb_cmdf_bc, kdb_usgf_bc, 0, KDB_REPEAT_NONE},
+    {"bp", kdb_cmdf_bp, kdb_usgf_bp, 1, KDB_REPEAT_NONE},
+    {"btp", kdb_cmdf_btp, kdb_usgf_btp, 1, KDB_REPEAT_NONE},
+
+    {"wp", kdb_cmdf_wp, kdb_usgf_wp, 1, KDB_REPEAT_NONE},
+    {"wc", kdb_cmdf_wc, kdb_usgf_wc, 0, KDB_REPEAT_NONE},
+
+    {"ni", kdb_cmdf_ni, kdb_usgf_ni, 0, KDB_REPEAT_NO_ARGS},
+    {"ss", kdb_cmdf_ss, kdb_usgf_ss, 1, KDB_REPEAT_NO_ARGS},
+    {"ssb",kdb_cmdf_ssb,kdb_usgf_ssb,0, KDB_REPEAT_NO_ARGS},
+    {"go", kdb_cmdf_go, kdb_usgf_go, 0, KDB_REPEAT_NONE},
+
+    {"cpu",kdb_cmdf_cpu, kdb_usgf_cpu, 1, KDB_REPEAT_NONE},
+    {"nmi",kdb_cmdf_nmi, kdb_usgf_nmi, 1, KDB_REPEAT_NONE},
+    {"percpu",kdb_cmdf_percpu, kdb_usgf_percpu, 1, KDB_REPEAT_NONE},
+
+    {"sym",  kdb_cmdf_sym,   kdb_usgf_sym,   1, KDB_REPEAT_NONE},
+    {"mod",  kdb_cmdf_mod,   kdb_usgf_mod,   1, KDB_REPEAT_NONE},
+
+    {"vcpuh",kdb_cmdf_vcpuh, kdb_usgf_vcpuh, 1, KDB_REPEAT_NONE},
+    {"vcpu", kdb_cmdf_vcpu,  kdb_usgf_vcpu,  1, KDB_REPEAT_NONE},
+    {"dom",  kdb_cmdf_dom,   kdb_usgf_dom,   1, KDB_REPEAT_NONE},
+
+    {"sched", kdb_cmdf_sched, kdb_usgf_sched, 1, KDB_REPEAT_NONE},
+    {"mmu",   kdb_cmdf_mmu,   kdb_usgf_mmu,   1, KDB_REPEAT_NONE},
+    {"p2m",   kdb_cmdf_p2m,   kdb_usgf_p2m,   1, KDB_REPEAT_NONE},
+    {"m2p",   kdb_cmdf_m2p,   kdb_usgf_m2p,   1, KDB_REPEAT_NONE},
+    {"dpage", kdb_cmdf_dpage, kdb_usgf_dpage, 1, KDB_REPEAT_NONE},
+    {"dmsr",  kdb_cmdf_dmsr,  kdb_usgf_dmsr, 1, KDB_REPEAT_NONE},
+    {"cpuid",  kdb_cmdf_cpuid,  kdb_usgf_cpuid, 1, KDB_REPEAT_NONE},
+    {"wept",  kdb_cmdf_wept,  kdb_usgf_wept, 1, KDB_REPEAT_NONE},
+
+    {"dtrq", kdb_cmdf_dtrq,  kdb_usgf_dtrq, 1, KDB_REPEAT_NONE},
+    {"didt", kdb_cmdf_didt,  kdb_usgf_didt, 1, KDB_REPEAT_NONE},
+    {"dgdt", kdb_cmdf_dgdt,  kdb_usgf_dgdt, 1, KDB_REPEAT_NONE},
+    {"dirq", kdb_cmdf_dirq,  kdb_usgf_dirq, 1, KDB_REPEAT_NONE},
+    {"dvit", kdb_cmdf_dvit,  kdb_usgf_dvit, 1, KDB_REPEAT_NONE},
+    {"dvmc", kdb_cmdf_dvmc,  kdb_usgf_dvmc, 1, KDB_REPEAT_NONE},
+    {"mmio", kdb_cmdf_mmio,  kdb_usgf_mmio, 1, KDB_REPEAT_NONE},
+
+    /* tracing related commands */
+    {"trcon", kdb_cmdf_trcon,  kdb_usgf_trcon,  0, KDB_REPEAT_NONE},
+    {"trcoff",kdb_cmdf_trcoff, kdb_usgf_trcoff, 0, KDB_REPEAT_NONE},
+    {"trcz",  kdb_cmdf_trcz,   kdb_usgf_trcz,   0, KDB_REPEAT_NONE},
+    {"trcp",  kdb_cmdf_trcp,   kdb_usgf_trcp,   1, KDB_REPEAT_NONE},
+
+    {"usr1",  kdb_cmdf_usr1,   kdb_usgf_usr1,   1, KDB_REPEAT_NONE},
+    {"kdbf",  kdb_cmdf_kdbf,   kdb_usgf_kdbf,   1, KDB_REPEAT_NONE},
+    {"kdbdbg",kdb_cmdf_kdbdbg, kdb_usgf_kdbdbg, 1, KDB_REPEAT_NONE},
+    {"reboot",kdb_cmdf_reboot, kdb_usgf_reboot, 1, KDB_REPEAT_NONE},
+    {"h",     kdb_cmdf_h,      kdb_usgf_h,      1, KDB_REPEAT_NONE},
+
+    {"", NULL, NULL, 0, 0},
+  };
+    kdb_cmd_tbl = _kdb_cmd_table;
+    return;
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/kdb_io.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_io.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+#include "include/kdbinc.h"
+
+#define K_BACKSPACE  0x8                   /* ctrl-H */
+#define K_BACKSPACE1 0x7f                  /* ctrl-? */
+#define K_UNDERSCORE 0x5f
+#define K_CMD_BUFSZ  160
+#define K_CMD_MAXI   (K_CMD_BUFSZ - 1)     /* max index in buffer */
+
+#if 0        /* make a history array some day */
+#define K_UP_ARROW                         /* sequence : 1b 5b 41 ie, '\e[A' */
+#define K_DN_ARROW                         /* sequence : 1b 5b 42 ie, '\e[B' */
+#define K_NUM_HIST   32
+static int cursor;
+static char cmds_a[NUM_HIST][K_CMD_BUFSZ];
+#endif
+
+static char cmds_a[K_CMD_BUFSZ];
+
+
+static int
+kdb_key_valid(int key)
+{
+    /* note: isspace() is more than ' ', hence we don't use it here */
+    if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
+            return 1;
+    return 0;
+}
+
+/* display kdb prompt and read command from the console 
+ * RETURNS: a '\n' terminated command buffer */
+char *
+kdb_get_cmdline(char *prompt)
+{
+    #define K_BELL     0x7
+    #define K_CTRL_C   0x3
+
+    int key, i=0;
+
+    kdbp(prompt);
+    memset(cmds_a, 0, K_CMD_BUFSZ);
+    cmds_a[K_CMD_BUFSZ-1] = '\n';
+
+    do {
+        key = console_getc();
+        if (key == '\r') 
+            key = '\n';
+        if (key == K_BACKSPACE1) 
+            key = K_BACKSPACE;
+
+        if (key == K_CTRL_C || (i==K_CMD_MAXI && key != '\n')) {
+            console_putc('\n');
+            if (i >= K_CMD_MAXI) {
+                kdbp("KDB: cmd buffer overflow\n");
+                console_putc(K_BELL);
+            }
+            memset(cmds_a, 0, K_CMD_BUFSZ);
+            i = 0;
+            kdbp(prompt);
+            continue;
+        }
+        if (!kdb_key_valid(key)) {
+            console_putc(K_BELL);
+            continue;
+        }
+        if (key == K_BACKSPACE) {
+            if (i==0) {
+                console_putc(K_BELL);
+                continue;
+            } else 
+                cmds_a[--i] = '\0';
+                console_putc(K_BACKSPACE);
+                console_putc(' ');        /* erase character */
+        } else
+            cmds_a[i++] = key;
+
+        console_putc(key);
+
+    } while (key != '\n');
+
+    return cmds_a;
+}
+
+/*
+ * printk takes a lock, an NMI could come in after that, and another cpu may 
+ * spin. also, the console lock is forced unlock, so panic is been seen on 
+ * 8 way. hence, no printk() calls.
+ */
+static volatile int kdbp_gate = 0;
+void
+kdbp(const char *fmt, ...)
+{
+    static char buf[1024];
+    va_list args;
+    char *p;
+    int i=0;
+
+    while ((__cmpxchg(&kdbp_gate, 0,1, sizeof(kdbp_gate)) != 0) && i++<1000)
+        mdelay(10);
+
+    va_start(args, fmt);
+    (void)vsnprintf(buf, sizeof(buf), fmt, args);
+    va_end(args);
+
+    for (p=buf; *p != '\0'; p++)
+        console_putc(*p);
+    kdbp_gate = 0;
+}
+
+
+/*
+ * copy/read machine memory. 
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mmem(kdbma_t maddr, kdbbyt_t *dbuf, int len)
+{
+    ulong remain, orig=len;
+
+    while (len > 0) {
+        ulong pagecnt = min_t(long, PAGE_SIZE-(maddr&~PAGE_MASK), len);
+        char *va = map_domain_page(maddr >> PAGE_SHIFT);
+
+        va = va + (maddr & (PAGE_SIZE-1));        /* add page offset */
+        remain = __copy_from_user(dbuf, (void *)va, pagecnt);
+        KDBGP1("maddr:%x va:%p len:%x pagecnt:%x rem:%x\n", 
+               maddr, va, len, pagecnt, remain);
+        unmap_domain_page(va);
+        len = len  - (pagecnt - remain);
+        if (remain != 0)
+            break;
+        maddr += pagecnt;
+        dbuf += pagecnt;
+    }
+    return orig - len;
+}
+
+
+/*
+ * copy/read guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mem(kdbva_t saddr, kdbbyt_t *dbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(saddr, dbuf, len, domid, 0, 0));
+}
+
+/*
+ * write guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes written
+ */
+int
+kdb_write_mem(kdbva_t daddr, kdbbyt_t *sbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(daddr, sbuf, len, domid, 1, 0));
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/kdbmain.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdbmain.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+static int kdbmain(kdb_reason_t, struct cpu_user_regs *);
+static int kdbmain_fatal(struct cpu_user_regs *, int);
+static const char *kdb_gettrapname(int);
+
+/* ======================== GLOBAL VARIABLES =============================== */
+/* All global variables used by KDB must be defined here only. Module specific
+ * static variables must be declared in respective modules.
+ */
+kdbtab_t *kdb_cmd_tbl;
+char kdb_prompt[32];
+
+volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+cpumask_t kdb_cpu_traps;           /* bit per cpu to tell which cpus hit int3 */
+
+#ifndef NDEBUG
+    #error KDB is not supported on debug xen. Turn debug off
+#endif
+
+volatile int kdb_init_cpu = -1;           /* initial kdb cpu */
+volatile int kdb_session_begun = 0;       /* active kdb session? */
+volatile int kdb_enabled = 1;             /* kdb enabled currently? */
+volatile int kdb_sys_crash = 0;           /* are we in crashed state? */
+volatile int kdbdbg = 0;                  /* to debug kdb itself */
+
+static volatile int kdb_trap_immed_reason = 0;   /* reason for immed trap */
+
+static cpumask_t kdb_fatal_cpumask;       /* which cpus in fatal path */
+
+/* return index of first bit set in val. if val is 0, retval is undefined */
+static inline unsigned int kdb_firstbit(unsigned long val)
+{
+    __asm__ ( "bsf %1,%0" : "=r" (val) : "r" (val), "0" (BITS_PER_LONG) );
+    return (unsigned int)val;
+}
+
+void noinline mukchk(unsigned long ul)
+{
+}
+
+static void 
+kdb_dbg_prnt_ctrps(char *label, int ccpu)
+{
+    int i;
+    if (!kdbdbg)
+        return;
+
+    if (label || *label)
+        kdbp("%s ", label);
+    if (ccpu != -1)
+        kdbp("ccpu:%d ", ccpu);
+    kdbp("cputrps:");
+    for (i=sizeof(kdb_cpu_traps)/sizeof(kdb_cpu_traps.bits[0]) - 1; i >=0; i--)
+        kdbp(" %lx", kdb_cpu_traps.bits[i]);
+    kdbp("\n");
+}
+
+/* 
+ * Hold this cpu. Don't disable until all CPUs in kdb to avoid IPI deadlock 
+ */
+static void
+kdb_hold_this_cpu(int ccpu, struct cpu_user_regs *regs)
+{
+    KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+    do {
+        for(; kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE; cpu_relax());
+        KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DISABLE) {
+            local_irq_disable();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DO_VMEXIT) {
+            kdb_curr_cpu_flush_vmcs();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_SHOWPC) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+    } while (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE);     /* No goto, eh! */
+    KDBGP1("un hold: ccpu:%d cmd:%d\n", ccpu, kdb_cpu_cmd[ccpu]);
+}
+
+/*
+ * Pause this cpu while one CPU does main kdb processing. If that CPU does
+ * a "cpu switch" to this cpu, this cpu will become the main kdb cpu. If the
+ * user next does single step of some sort, this function will be exited,
+ * and this cpu will come back into kdb via kdb_handle_trap_entry function.
+ */
+static void 
+kdb_pause_this_cpu(struct cpu_user_regs *regs, void *unused)
+{
+    kdbmain(KDB_REASON_PAUSE_IPI, regs);
+}
+
+/* pause other cpus via an IPI. Note, disabled CPUs can't receive IPIs until
+ * enabled */
+static void
+kdb_smp_pause_cpus(void)
+{
+    int cpu, wait_count = 0;
+    int ccpu = smp_processor_id();      /* current cpu */
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL) {
+            kdbp("KDB: won't pause cpu:%d, cmd[cpu]=%d\n",cpu,kdb_cpu_cmd[cpu]);
+            cpumask_clear_cpu(cpu, &cpumask);
+        }
+    KDBGP("ccpu:%d will pause cpus. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    on_selected_cpus(&cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0);
+#else
+    on_selected_cpus(cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0, 0);
+#endif
+    mdelay(300);                     /* wait a bit for other CPUs to stop */
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+                bummer = 1;
+        if (!bummer)
+            break;
+        kdbp("ccpu:%d trying to stop other cpus...\n", ccpu);
+        mdelay(100);  /* wait 100 ms */
+    };
+    for_each_cpu(cpu, &cpumask)          /* now check who is with us */
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+            kdbp("Bummer cpu %d not paused. ccpu:%d\n", cpu,ccpu);
+        else {
+            kdb_cpu_cmd[cpu] = KDB_CPU_DISABLE;  /* tell it to disable ints */
+            while (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE);
+        }
+}
+
+/* 
+ * Do once per kdb session:  A kdb session lasts from 
+ *    keybord/HWBP/SWBP till KDB_CPU_INSTALL_BP is done. Within a session,
+ *    user may do several cpu switches, single step, next instr,  etc..
+ *
+ * DO: 1. pause other cpus if they are not already. they would already be 
+ *        if we are in single step mode
+ *     2. watchdog_disable() 
+ *     3. uninstall all sw breakpoints so that user doesn't see them
+ */
+static void
+kdb_begin_session(void)
+{
+    if (!kdb_session_begun) {
+        kdb_session_begun = 1;
+        kdb_smp_pause_cpus();
+        local_irq_disable();
+        watchdog_disable();
+        kdb_uninstall_all_swbp();
+    }
+}
+
+int noinline mukid(void)
+{
+    return smp_processor_id();
+}
+
+static void
+kdb_smp_unpause_cpus(int ccpu)
+{
+    int cpu;
+
+    int wait_count = 0;
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+
+    KDBGP("kdb_smp_unpause_other_cpus(). ccpu:%d\n", ccpu);
+    for_each_cpu(cpu, &cpumask)
+        kdb_cpu_cmd[cpu] = KDB_CPU_QUIT;
+
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+                bummer = 1;
+            if (!bummer)
+                break;
+            mdelay(90);  /* wait 90 ms, 50 too short on large systems */
+    };
+    /* now make sure they are all in there */
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+            kdbp("KDB: cpu %d still paused (cmd==%d). ccpu:%d\n",
+                 cpu, kdb_cpu_cmd[cpu], ccpu);
+}
+
+/*
+ * End of KDB session. 
+ *   This is called at the very end. In case of multiple cpus hitting BPs
+ *   and sitting on a trap handlers, the last cpu to exit will call this.
+ *   - isnstall all sw breakpoints, and purge deleted ones from table.
+ *   - clear TF here also in case go is entered on a different cpu after switch
+ */
+static void
+kdb_end_session(int ccpu, struct cpu_user_regs *regs)
+{
+    ASSERT(!cpumask_empty(&kdb_cpu_traps));
+    ASSERT(kdb_session_begun);
+    kdb_install_all_swbp();
+    kdb_flush_swbp_table();
+    kdb_install_watchpoints();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    kdb_time_resume(1);
+    kdb_session_begun = 0;      /* before unpause for kdb_install_watchpoints */
+    kdb_smp_unpause_cpus(ccpu);
+    watchdog_enable();
+    KDBGP("end_session:ccpu:%d\n", ccpu);
+}
+volatile int mukwpprnt;
+unsigned long mukaddr1 = 0xffffffff81243ae7, mukaddr2 = 0xffffffff8100986e;
+/* 
+ * check if we entered kdb because of DB trap. If yes, then check if
+ * we caused it or someone else.
+ * RETURNS: 0 : not one of ours. hypervisor must handle it. 
+ *          1 : #DB for delayed sw bp install. 
+ *          2 : this cpu must stay in kdb.
+ */
+static noinline int
+kdb_check_dbtrap(kdb_reason_t *reasp, int ss_mode, struct cpu_user_regs *regs) 
+{
+    int rc = 2;
+    int ccpu = smp_processor_id();
+
+    /* DB excp caused by hw breakpoint or the TF flag. The TF flag is set
+     * by us for ss mode or to install breakpoints. In ss mode, none of the
+     * breakpoints are installed. Check to make sure we intended BP INSTALL
+     * so we don't do it on a spurious DB trap.
+     * check for kdb_cpu_traps here also, because each cpu sitting on a trap
+     * must execute the instruction without the BP before passing control
+     * to next cpu in kdb_cpu_traps.
+     */
+    if (*reasp == KDB_REASON_DBEXCP && !ss_mode) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP) {
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                *reasp = KDB_REASON_PAUSE_IPI;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
+                kdb_init_cpu = -1;
+            } else {
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            }
+        } else if (! kdb_check_watchpoints(regs)) {
+            rc = 0;                        /* hyp must handle it */
+        } else {
+            if (regs->rip==mukaddr1 || regs->rip==mukaddr2)
+            {
+                if (mukwpprnt)
+                    kdbp("MUK: ignoring wp:%lx\n", regs->rip);
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            } 
+        }
+    }
+    return rc;
+}
+
+/* 
+ * Misc processing on kdb entry like displaying PC, adjust IP for sw bp.... 
+ */
+static void
+kdb_main_entry_misc(kdb_reason_t reason, struct cpu_user_regs *regs, 
+                    int ccpu, int ss_mode, int enabled)
+{
+    if (reason == KDB_REASON_KEYBOARD)
+        kdbp("\nEnter kdb (cpu:%d reason:%d vcpu=%d domid:%d"
+             " eflg:0x%lx irqs:%d)\n", ccpu, reason, current->vcpu_id, 
+             current->domain->domain_id, regs->eflags, enabled);
+    else if (ss_mode)
+        KDBGP1("KDBG: KDB single step mode. ccpu:%d\n", ccpu);
+
+    if (reason == KDB_REASON_BPEXCP && !ss_mode) 
+        kdbp("Breakpoint on cpu %d at 0x%lx\n", ccpu, regs->KDBIP);
+
+    /* display the current PC and instruction at it */
+    if (reason != KDB_REASON_PAUSE_IPI)
+        kdb_display_pc(regs);
+    console_start_sync();
+}
+
+/* 
+ * The MAIN kdb function. All cpus go thru this. IRQ is enabled on entry because
+ * a cpu could hit a bp set in disabled code.
+ * IPI: Even the main cpu must enable in case another CPU is trying to IPI us.
+ *      That way, it would IPI us, then get out and be ready for our pause IPI.
+ * IRQs: The reason irqs enable/disable is scattered is because on a typical
+ *       system IPIs are constantly going on amongs CPUs in a set of any size. 
+ *       As a result,  to avoid deadlock, cpus have to loop enabled, until a 
+ *       quorum is established and the session has begun.
+ * Step: Intel Vol3B 18.3.1.4 : An external interrupt may be serviced upon
+ *       single step. Since, the likely ext timer_interrupt and 
+ *       apic_timer_interrupt dont' mess with time data structs, we are prob OK
+ *       leaving enabled.
+ * Time: Very messy. Most platform timers are readonly, so we can't stop time
+ *       in the debugger. We take the only resort, let the TSC and plt run as
+ *       normal, upon leaving, "attempt" to bring everybody to current time.
+ * kdbcputraps: bit per cpu. each cpu sets it bit in entry.S. The bit is 
+ *              reliable because upon traps, Ints are disabled. the bit is set
+ *              before Ints are enabled.
+ *
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+static int
+kdbmain(kdb_reason_t reason, struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();                /* current cpu */
+    int rc = 1, cmd = kdb_cpu_cmd[ccpu];
+    int ss_mode = (cmd == KDB_CPU_SS || cmd == KDB_CPU_NI);
+    int delayed_install = (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP);
+    int enabled = local_irq_is_enabled();
+
+    KDBGP("kdbmain:ccpu:%d rsn:%d eflgs:0x%lx cmd:%d initc:%d irqs:%d "
+          "regs:%lx IP:%lx ", ccpu, reason, regs->eflags, cmd, 
+          kdb_init_cpu, enabled, regs, regs->KDBIP);
+    kdb_dbg_prnt_ctrps("", -1);
+
+    if (!ss_mode && !delayed_install)    /* initial kdb enter */
+        local_irq_enable();              /* so we can receive IPI */
+
+    if (!ss_mode && ccpu != kdb_init_cpu && reason != KDB_REASON_PAUSE_IPI){
+        int sz = sizeof(kdb_init_cpu);
+        while (__cmpxchg(&kdb_init_cpu, -1, ccpu, sz) != -1)
+            for(; kdb_init_cpu != -1; cpu_relax());
+    }
+    if (kdb_session_begun)
+        local_irq_disable();             /* kdb always runs disabled */
+
+    if (reason == KDB_REASON_BPEXCP) {             /* INT 3 */
+        cpumask_clear_cpu(ccpu, &kdb_cpu_traps);   /* remove ourself */
+        rc = kdb_check_sw_bkpts(regs);
+        if (rc == 0) {               /* not one of ours. leave kdb */
+            kdb_init_cpu = -1;
+            goto out;
+        } else if (rc == 1) {        /* one of ours but deleted */
+            if (cpumask_empty(&kdb_cpu_traps)) {
+                kdb_end_session(ccpu,regs);     
+                kdb_init_cpu = -1;
+                goto out;
+            } else {                 
+                /* release another trap cpu, and put ourself in a pause mode */
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d cmd:%d rsn:%d atrpcpu:%d initcpu:%d\n", ccpu, 
+                      kdb_cpu_cmd[ccpu], reason, a_trap_cpu, kdb_init_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                reason = KDB_REASON_PAUSE_IPI;
+                kdb_init_cpu = -1;
+            }
+        } else if (rc == 2) {        /* one of ours but condition not met */
+                kdb_begin_session();
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+        }
+    }
+
+    /* following will take care of KDB_CPU_INSTALL_BP, and also release
+     * kdb_init_cpu. it should not be done twice */
+    if ((rc=kdb_check_dbtrap(&reason, ss_mode, regs)) == 0 || rc == 1) {
+        kdb_init_cpu = -1;       /* leaving kdb */
+        goto out;                /* rc properly set to 0 or 1 */
+    }
+    if (reason != KDB_REASON_PAUSE_IPI) {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+    } else
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB && !ss_mode)
+        kdb_begin_session(); 
+
+    kdb_main_entry_misc(reason, regs, ccpu, ss_mode, enabled);
+    /* note, one or more cpu switches may occur in between */
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+            if (ccpu != kdb_init_cpu) {
+                kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_GO;
+                kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+                continue;               /* for the pause guy */
+            }
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                /* execute current instruction without 0xcc */
+                kdb_dbg_prnt_ctrps("nempty:", ccpu);
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            }
+        }
+        if (kdb_cpu_cmd[ccpu] != KDB_CPU_PAUSE  && 
+            kdb_cpu_cmd[ccpu] != KDB_CPU_MAIN_KDB)
+                break;
+    }
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+        ASSERT(cpumask_empty(&kdb_cpu_traps));
+        if (kdb_swbp_exists()) {
+            if (reason == KDB_REASON_BPEXCP) {
+                /* do delayed install */
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            } 
+        }
+        kdb_end_session(ccpu, regs);
+        kdb_init_cpu = -1;
+    }
+out:
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_QUIT) {
+        KDBGP("ccpu:%d _quit IP: %lx\n", ccpu, regs->KDBIP);
+        if (! kdb_session_begun)
+            kdb_install_watchpoints();
+        kdb_time_resume(0);
+        kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    }
+
+    /* for ss and delayed install, TF is set. not much in EXT INT handlers*/
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_NI)
+        kdb_time_resume(1);
+    if (enabled)
+        local_irq_enable();
+
+    KDBGP("kdbmain:X:ccpu:%d rc:%d cmd:%d eflg:0x%lx initc:%d sesn:%d " 
+          "cs:%x irqs:%d ", ccpu, rc, kdb_cpu_cmd[ccpu], regs->eflags, 
+          kdb_init_cpu, kdb_session_begun, regs->cs, local_irq_is_enabled());
+    kdb_dbg_prnt_ctrps("", -1);
+    return (rc ? 1 : 0);
+}
+
+/* 
+ * kdb entry function when coming in via a keyboard
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+int
+kdb_keyboard(struct cpu_user_regs *regs)
+{
+    return kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+
+#if 0
+/*
+ * this function called when kdb session active and user presses ctrl\ again.
+ * the assumption is that the user typed ni/ss cmd, and it never got back into
+ * kdb, or the user is impatient. Either case, we just fake it that the SS did
+ * finish. Since, all other kdb cpus must be holding disabled, the interrupt
+ * would be on the CPU that did the ss/ni cmd
+ */
+void
+kdb_ssni_reenter(struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();
+    int ccmd = kdb_cpu_cmd[ccpu];
+
+    if(ccmd == KDB_CPU_SS || ccmd == KDB_CPU_INSTALL_BP)
+        kdbmain(KDB_REASON_DBEXCP, regs); 
+    else 
+        kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+#endif
+
+/* 
+ * All traps are routed thru here. We care about BP (#3) trap (INT 3) and
+ * the DB trap(#1) only. 
+ * returns: 0 kdb has nothing do with this trap
+ *          1 kdb handled this trap 
+ */
+int
+kdb_handle_trap_entry(int vector, struct cpu_user_regs *regs)
+{
+    int rc = 0;
+    int ccpu = smp_processor_id();
+
+    if (vector == TRAP_int3) {
+        rc = kdbmain(KDB_REASON_BPEXCP, regs);
+
+    } else if (vector == TRAP_debug) {
+        KDBGP("ccpu:%d trapdbg reas:%d\n", ccpu, kdb_trap_immed_reason);
+
+        if (kdb_trap_immed_reason == KDB_TRAP_FATAL) { 
+            KDBGP("kdbtrp:fatal ccpu:%d vec:%d\n", ccpu, vector);
+            rc = kdbmain_fatal(regs, vector);
+            BUG();                             /* no return */
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_KDBSTACK) {
+            kdb_trap_immed_reason = 0;         /* show kdb stack */
+            show_registers(regs);
+            show_stack(regs);
+            regs->eflags &= ~X86_EFLAGS_TF;
+            rc = 1;
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_NONFATAL) {
+            kdb_trap_immed_reason = 0;
+            rc = kdb_keyboard(regs);
+        } else {                         /* ss/ni/delayed install... */
+            if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                current->arch.hvm_vcpu.single_step = 0;
+            rc = kdbmain(KDB_REASON_DBEXCP, regs); 
+        }
+
+    } else if (vector == TRAP_nmi) {                   /* external nmi */
+        /* when nmi is pressed, it could go to one or more or all cpus
+         * depending on the hardware. Also, for now assume it's fatal */
+        KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
+        rc = kdbmain_fatal(regs, TRAP_nmi);
+    } 
+    return rc;
+}
+
+int
+kdb_trap_fatal(int vector, struct cpu_user_regs *regs)
+{
+    kdbmain_fatal(regs, vector);
+    return 0;
+}
+
+/* From smp_send_nmi_allbutself() in crash.c which is static */
+void
+kdb_nmi_pause_cpus(cpumask_t cpumask)
+{
+    int ccpu = smp_processor_id();
+    mdelay(200);
+    cpumask_complement(&cpumask, &cpumask);              /* flip bit map */
+    cpumask_and(&cpumask, &cpumask, &cpu_online_map);    /* remove extra bits */
+    cpumask_clear_cpu(ccpu, &cpumask);/* absolutely make sure we're not on it */
+
+    KDBGP("ccpu:%d nmi pause. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+    if ( !cpumask_empty(&cpumask) )
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+        send_IPI_mask(&cpumask, APIC_DM_NMI);
+#else
+        send_IPI_mask(cpumask, APIC_DM_NMI);
+#endif
+    mdelay(200);
+    KDBGP("ccpu:%d nmi pause done...\n", ccpu);
+}
+
+/* 
+ * Separate function from kdbmain to keep both within sanity levels.
+ */
+DEFINE_SPINLOCK(kdb_fatal_lk);
+static int
+kdbmain_fatal(struct cpu_user_regs *regs, int vector)
+{
+    int ccpu = smp_processor_id();
+
+    console_start_sync();
+
+    KDBGP("mainf:ccpu:%d vec:%d irq:%d\n", ccpu, vector,local_irq_is_enabled());
+    cpumask_set_cpu(ccpu, &kdb_fatal_cpumask);        /* uses LOCK_PREFIX */
+
+    if (spin_trylock(&kdb_fatal_lk)) {
+
+        kdbp("*** kdb (Fatal Error on cpu:%d vec:%d %s):\n", ccpu,
+             vector, kdb_gettrapname(vector));
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+        kdb_display_pc(regs);
+
+        watchdog_disable();     /* important */
+        kdb_sys_crash = 1;
+        kdb_session_begun = 0;  /* incase session already active */
+        local_irq_enable();
+        kdb_nmi_pause_cpus(kdb_fatal_cpumask);
+
+        kdb_clear_prev_cmd();   /* buffered CRs will repeat prev cmd */
+        kdb_session_begun = 1;  /* for kdb_hold_this_cpu() */
+        local_irq_disable();
+    } else {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+    }
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+#if 0
+        /* dump is the only way to exit in crashed state */
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DUMP)
+            kdb_do_dump(regs);
+#endif
+    }
+    return 0;
+}
+
+/* Mostly called in fatal cases. earlykdb calls non-fatal.
+ * kdb_trap_immed_reason is global, so allow only one cpu at a time. Also,
+ * multiple cpu may be crashing at the same time. We enable because if there
+ * is a bad hang, at least ctrl-\ will break into kdb. Also, we don't call
+ * call kdb_keyboard directly becaue we don't have the register context.
+ */
+DEFINE_SPINLOCK(kdb_immed_lk);
+void
+kdb_trap_immed(int reason)            /* fatal, non-fatal, kdb stack etc... */
+{
+    int ccpu = smp_processor_id();
+    int disabled = !local_irq_is_enabled();
+
+    KDBGP("trapimm:ccpu:%d reas:%d\n", ccpu, reason);
+    local_irq_enable();
+    spin_lock(&kdb_immed_lk);
+    kdb_trap_immed_reason = reason;
+    barrier();
+    __asm__ __volatile__ ( "int $1" );
+    kdb_trap_immed_reason = 0;
+
+    spin_unlock(&kdb_immed_lk);
+    if (disabled)
+        local_irq_disable();
+}
+
+/* called very early during init, even before all CPUs are brought online */
+void 
+kdb_init(void)
+{
+        kdb_init_cmdtab();      /* Initialize Command Table */
+}
+
+static const char *
+kdb_gettrapname(int trapno)
+{
+    char *ret;
+    switch (trapno) {
+        case  0:  ret = "Divide Error"; break;
+        case  2:  ret = "NMI Interrupt"; break;
+        case  3:  ret = "Int 3 Trap"; break;
+        case  4:  ret = "Overflow Error"; break;
+        case  6:  ret = "Invalid Opcode"; break;
+        case  8:  ret = "Double Fault"; break;
+        case 10:  ret = "Invalid TSS"; break;
+        case 11:  ret = "Segment Not Present"; break;
+        case 12:  ret = "Stack-Segment Fault"; break;
+        case 13:  ret = "General Protection"; break;
+        case 14:  ret = "Page Fault"; break;
+        case 17:  ret = "Alignment Check"; break;
+        default: ret = " ????? ";
+    }
+    return ret;
+}
+
+
+/* ====================== Generic tracing subsystem ======================== */
+
+#define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
+                           * is 32 bytes */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
+
+typedef struct {
+    union {
+        struct { uint d0; uint cpu_trcid; } s0;
+        uint64_t l0;
+    }u;
+    uint64_t l1, l2, l3; 
+} trc_rec_t;
+
+static volatile unsigned int trcidx;    /* points to where new entry will go */
+static trc_rec_t trca[KDBTRCMAX];       /* trace array */
+
+/* atomically: add i to *p, return prev value of *p (ie, val before add) */
+static int
+kdb_fetch_and_add(int i, uint *p)
+{
+    asm volatile("lock xaddl %0, %1;" : "=r"(i) : "m"(*p), "0"(i));
+    return i;
+}
+
+/* zero out the entire buffer */
+void 
+kdb_trczero(void)
+{
+    for (trcidx = KDBTRCMAX-1; trcidx; trcidx--) {
+        memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    }
+    memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    kdbp("kdb trace buffer has been zeroed\n");
+}
+
+/* add trace entry: eg.: kdbtrc(0xe0f099, intdata, vcpu, domain, 0)
+ *    where:  0xe0f099 : 24bits max trcid, lower 8 bits are set to cpuid */
+void
+kdbtrc(uint trcid, uint int_d0, uint64_t d1_64, uint64_t d2_64, uint64_t d3_64)
+{
+    uint idx;
+
+    if (!kdb_trcon)
+        return;
+
+    idx = kdb_fetch_and_add(1, (uint*)&trcidx);
+    idx = idx % KDBTRCMAX;
+
+#if 0
+    trca[idx].u.s0.cpu_trcid = (smp_processor_id()<<24) | trcid;
+#endif
+    trca[idx].u.s0.cpu_trcid = (trcid<<8) | smp_processor_id();
+    trca[idx].u.s0.d0 = int_d0;
+    trca[idx].l1 = d1_64;
+    trca[idx].l2 = d2_64;
+    trca[idx].l3 = d3_64;
+}
+
+/* give hints so user can print trc buffer via the dd command. last has the
+ * most recent entry */
+void
+kdb_trcp(void)
+{
+    int i = trcidx % KDBTRCMAX;
+
+    i = (i==0) ? KDBTRCMAX-1 : i-1;
+    kdbp("trcbuf:    [0]: %016lx [MAX-1]: %016lx\n", &trca[0],
+         &trca[KDBTRCMAX-1]);
+    kdbp(" [most recent]: %016lx   trcidx: 0x%x\n", &trca[i], trcidx);
+}
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y    := kdb_wp.o
+subdir-y += udis86-1.7
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/kdb_wp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/kdb_wp.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,310 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+#if 0
+#define DR6_BT  0x00008000
+#define DR6_BS  0x00004000
+#define DR6_BD  0x00002000
+#endif
+#define DR6_B3  0x00000008
+#define DR6_B2  0x00000004
+#define DR6_B1  0x00000002
+#define DR6_B0  0x00000001
+
+#define KDB_MAXWP 4                          /* DR0 thru DR3 */
+
+struct kdb_wp {
+    kdbma_t  wp_addr;
+    int      wp_rwflag;
+    int      wp_len;
+    int      wp_deleted;                     /* pending delete */
+};
+static struct kdb_wp kdb_wpa[KDB_MAXWP];
+
+/* following because vmcs has it's own dr7. when vmcs runs, it messes up the
+ * native dr7 so we need to save/restore it */
+unsigned long kdb_dr7;
+
+
+/* Set G0-G3 bits in DR7. this does global enable of the corresponding wp */
+static void
+kdb_set_gx_in_dr7(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p | 0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p | 0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p | 0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p | 0x80;
+}
+
+/* Set LEN0 - LEN3 pair bits in DR7 (len should be 1 2 4 or 8) */
+static void
+kdb_set_len_in_dr7(int regno, kdbma_t *dr7p, int len)
+{
+    int lenbits = (len == 8) ? 2 : len-1;
+
+    *dr7p &= ~(0x3 << (18 + 4*regno));
+    *dr7p |= ((ulong)(lenbits & 0x3) << (18 + 4*regno));
+}
+
+static void
+kdb_set_dr7_rw(int regno, kdbma_t *dr7p, int rw)
+{
+    *dr7p &= ~(0x3 << (16 + 4*regno));
+    *dr7p |= ((ulong)(rw & 0x3)) << (16 + 4*regno);
+}
+
+/* get value of a debug register: DR0-DR3 DR6 DR7. other values return 0 */
+kdbma_t
+kdb_rd_dbgreg(int regnum)
+{
+    kdbma_t contents = 0;
+
+    if (regnum == 0)
+        __asm__ ("movq %%db0,%0\n\t":"=r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %%db1,%0\n\t":"=r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %%db2,%0\n\t":"=r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %%db3,%0\n\t":"=r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %%db6,%0\n\t":"=r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %%db7,%0\n\t":"=r"(contents));
+
+    return contents;
+}
+
+static void
+kdb_wr_dbgreg(int regnum, kdbma_t contents)
+{
+    if (regnum == 0)
+        __asm__ ("movq %0,%%db0\n\t"::"r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %0,%%db1\n\t"::"r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %0,%%db2\n\t"::"r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %0,%%db3\n\t"::"r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %0,%%db6\n\t"::"r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %0,%%db7\n\t"::"r"(contents));
+}
+
+static void
+kdb_print_wp_info(char *strp, int idx)
+{
+    kdbp("%s[%d]:%016lx len:%d ", strp, idx, kdb_wpa[idx].wp_addr,
+         kdb_wpa[idx].wp_len);
+    if (kdb_wpa[idx].wp_rwflag == 1)
+        kdbp("on data write only\n");
+    else if (kdb_wpa[idx].wp_rwflag == 2)
+        kdbp("on IO read/write\n");
+    else 
+        kdbp("on data read/write\n");
+}
+
+/*
+ * Returns : 0 if not one of ours
+ *           1 if one of ours
+ */
+int
+kdb_check_watchpoints(struct cpu_user_regs *regs)
+{
+    int wpnum;
+    kdbma_t dr6 = kdb_rd_dbgreg(6);
+
+    KDBGP1("check_wp: IP:%lx EFLAGS:%lx\n", regs->rip, regs->rflags);
+    if (dr6 & DR6_B0)
+        wpnum = 0;
+    else if (dr6 & DR6_B1)
+        wpnum = 1;
+    else if (dr6 & DR6_B2)
+        wpnum = 2;
+    else if (dr6 & DR6_B3)
+        wpnum = 3;
+    else
+        return 0;
+
+    kdb_print_wp_info("Watchpoint ", wpnum);
+    return 1;
+}
+
+/* set a watchpoint at a given address 
+ * PreCondition: addr != 0 */
+static void
+kdb_set_wp(kdbva_t addr, int rwflag, int len)
+{
+    int regno;
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        if (kdb_wpa[regno].wp_addr == addr && !kdb_wpa[regno].wp_deleted) {
+            kdbp("Watchpoint already set\n");
+            return;
+        }
+        if (kdb_wpa[regno].wp_deleted)
+            memset(&kdb_wpa[regno], 0, sizeof(kdb_wpa[regno]));
+    }
+    for (regno=0; regno < KDB_MAXWP && kdb_wpa[regno].wp_addr; regno++);
+    if (regno >= KDB_MAXWP) {
+        kdbp("watchpoint table full. limit:%d\n", KDB_MAXWP);
+        return;
+    }
+    kdb_wpa[regno].wp_addr = addr;
+    kdb_wpa[regno].wp_rwflag = rwflag;
+    kdb_wpa[regno].wp_len = len;
+    kdb_print_wp_info("Watchpoint set ", regno);
+}
+
+/* write reg DR0-3 with address. Update corresponding bits in DR7 */
+static void
+kdb_install_watchpoint(int regno, kdbma_t *dr7p)
+{
+    kdb_set_gx_in_dr7(regno, dr7p);
+    kdb_set_len_in_dr7(regno, dr7p, kdb_wpa[regno].wp_len); 
+    kdb_set_dr7_rw(regno, dr7p, kdb_wpa[regno].wp_rwflag);
+    kdb_wr_dbgreg(regno, kdb_wpa[regno].wp_addr);
+
+    KDBGP1("ccpu:%d installed wp. addr:%lx rw:%x len:%x dr7:%016lx\n",
+           smp_processor_id(), kdb_wpa[regno].wp_addr, 
+           kdb_wpa[regno].wp_rwflag, kdb_wpa[regno].wp_len, *dr7p);
+}
+
+/* clear G0-G3 bits in DR7 for given DR0-3 */
+static void
+kdb_clear_dr7_gx(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p & ~0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p & ~0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p & ~0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p & ~0x80;
+}
+
+/* update dr7 once, as it's slow to update debug regs and cpu's will still be 
+ * paused when leaving kdb.
+ *
+ * Just leave DR0-3 clobbered but remove bits from DR7 to disable wp 
+ */
+void
+kdb_install_watchpoints(void)
+{
+    int regno;
+    kdbma_t dr7 = kdb_rd_dbgreg(7);
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        /* do not clear wp_deleted here as all cpus must clear wps */
+        if (kdb_wpa[regno].wp_deleted) {
+            kdb_clear_dr7_gx(regno, &dr7);
+            continue;
+        }
+        if (kdb_wpa[regno].wp_addr)
+            kdb_install_watchpoint(regno, &dr7);
+    }
+    /* always clear DR6 when leaving */
+    kdb_wr_dbgreg(6, 0);
+    kdb_wr_dbgreg(7, dr7);
+
+    if (dr7 & DR7_ACTIVE_MASK)
+        kdb_dr7 = dr7;
+    else
+        kdb_dr7 = 0;
+#if 0
+    for(dp=domain_list; dp; dp=dp->next_in_list) {
+        struct vcpu *vp;
+        for_each_vcpu(dp, vp) {
+            for (regno=0; regno < KDB_MAXWP; regno++)
+                vp->arch.guest_context.debugreg[regno] = kdb_wpa[regno].wp_addr;
+
+            vp->arch.guest_context.debugreg[6] = 0;
+            vp->arch.guest_context.debugreg[7] = dr7;
+            KDBGP("kdb_install_watchpoints(): v:%p dr7:%lx\n", vp, dr7);
+            /* hvm_set_info_guest(vp);: Can't because can't vmcs_enter in kdb */
+        }
+    }
+#endif
+}
+
+/* clear watchpoint/s. wpnum == -1 to clear all watchpoints */
+void
+kdb_clear_wps(int wpnum)
+{
+    int i;
+
+    if (wpnum >= KDB_MAXWP) {
+        kdbp("Invalid wpnum %d\n", wpnum);
+        return;
+    }
+    if (wpnum >=0) {
+        if (kdb_wpa[wpnum].wp_addr) {
+            kdb_wpa[wpnum].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", wpnum);
+        } else
+            kdbp("watchpoint %d not set\n", wpnum);
+        return;
+    }
+    for (i=0; i < KDB_MAXWP; i++) {
+        if (kdb_wpa[i].wp_addr) {
+            kdb_wpa[i].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", i);
+        }
+    }
+}
+
+/* display any watchpoints that are set */
+static void
+kdb_display_wps(void)
+{
+    int i;
+    for (i=0; i < KDB_MAXWP; i++)
+        if (kdb_wpa[i].wp_addr && !kdb_wpa[i].wp_deleted) 
+            kdb_print_wp_info("", i);
+}
+
+/* 
+ * Display or Set hardware breakpoints, ie, watchpoints:
+ *   - Upto 4 are allowed
+ *   
+ *  rw_flag should be one of: 
+ *     01 == break on data write only
+ *     10 == break on IO read/write
+ *     11 == Break on data reads or writes
+ *
+ *  len should be one of : 1 2 4 8 
+ */
+void
+kdb_do_watchpoints(kdbva_t addr, int rw_flag, int len)
+{
+    if (addr == 0) {
+        kdb_display_wps();        /* display set watchpoints */
+        return;
+    }
+    kdb_set_wp(addr, rw_flag, len);
+    return;
+}
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/LICENSE
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/LICENSE	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,22 @@
+Copyright (c) 2002, 2003, 2004, 2005, 2006 <vivek@sig9.com>
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, 
+are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice, 
+      this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright notice, 
+      this list of conditions and the following disclaimer in the documentation 
+      and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,5 @@
+
+CFLAGS		+= -D__UD_STANDALONE__
+obj-y		:= decode.o input.o itab.o kdb_dis.o syn-att.o syn.o \
+                   syn-intel.o udis86.o
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/README	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,10 @@
+
+http://udis86.sourceforge.net/
+udis86-1.6 : 
+  - cd libudis86
+  - cp *c to here
+  - cp *h to here
+   
+Mukesh Rathor
+04/30/2008
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/decode.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,1197 @@
+/* -----------------------------------------------------------------------------
+ * decode.c
+ *
+ * Copyright (c) 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <assert.h>
+#include <string.h>
+#endif
+
+#include "types.h"
+#include "itab.h"
+#include "input.h"
+#include "decode.h"
+
+/* The max number of prefixes to an instruction */
+#define MAX_PREFIXES    15
+
+static struct ud_itab_entry ie_invalid = { UD_Iinvalid, O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_pause   = { UD_Ipause,   O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_nop     = { UD_Inop,     O_NONE, O_NONE, O_NONE, P_none };
+
+
+/* Looks up mnemonic code in the mnemonic string table
+ * Returns NULL if the mnemonic code is invalid
+ */
+const char * ud_lookup_mnemonic( enum ud_mnemonic_code c )
+{
+    if ( c < UD_Id3vil )
+        return ud_mnemonics_str[ c ];
+    return NULL;
+}
+
+
+/* Extracts instruction prefixes.
+ */
+static int get_prefixes( struct ud* u )
+{
+    unsigned int have_pfx = 1;
+    unsigned int i;
+    uint8_t curr;
+
+    /* if in error state, bail out */
+    if ( u->error ) 
+        return -1; 
+
+    /* keep going as long as there are prefixes available */
+    for ( i = 0; have_pfx ; ++i ) {
+
+        /* Get next byte. */
+        inp_next(u); 
+        if ( u->error ) 
+            return -1;
+        curr = inp_curr( u );
+
+        /* rex prefixes in 64bit mode */
+        if ( u->dis_mode == 64 && ( curr & 0xF0 ) == 0x40 ) {
+            u->pfx_rex = curr;  
+        } else {
+            switch ( curr )  
+            {
+            case 0x2E : 
+                u->pfx_seg = UD_R_CS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x36 :     
+                u->pfx_seg = UD_R_SS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x3E : 
+                u->pfx_seg = UD_R_DS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x26 : 
+                u->pfx_seg = UD_R_ES; 
+                u->pfx_rex = 0;
+                break;
+            case 0x64 : 
+                u->pfx_seg = UD_R_FS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x65 : 
+                u->pfx_seg = UD_R_GS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x67 : /* adress-size override prefix */ 
+                u->pfx_adr = 0x67;
+                u->pfx_rex = 0;
+                break;
+            case 0xF0 : 
+                u->pfx_lock = 0xF0;
+                u->pfx_rex  = 0;
+                break;
+            case 0x66: 
+                /* the 0x66 sse prefix is only effective if no other sse prefix
+                 * has already been specified.
+                 */
+                if ( !u->pfx_insn ) u->pfx_insn = 0x66;
+                u->pfx_opr = 0x66;           
+                u->pfx_rex = 0;
+                break;
+            case 0xF2:
+                u->pfx_insn  = 0xF2;
+                u->pfx_repne = 0xF2; 
+                u->pfx_rex   = 0;
+                break;
+            case 0xF3:
+                u->pfx_insn = 0xF3;
+                u->pfx_rep  = 0xF3; 
+                u->pfx_repe = 0xF3; 
+                u->pfx_rex  = 0;
+                break;
+            default : 
+                /* No more prefixes */
+                have_pfx = 0;
+                break;
+            }
+        }
+
+        /* check if we reached max instruction length */
+        if ( i + 1 == MAX_INSN_LENGTH ) {
+            u->error = 1;
+            break;
+        }
+    }
+
+    /* return status */
+    if ( u->error ) 
+        return -1; 
+
+    /* rewind back one byte in stream, since the above loop 
+     * stops with a non-prefix byte. 
+     */
+    inp_back(u);
+
+    /* speculatively determine the effective operand mode,
+     * based on the prefixes and the current disassembly
+     * mode. This may be inaccurate, but useful for mode
+     * dependent decoding.
+     */
+    if ( u->dis_mode == 64 ) {
+        u->opr_mode = REX_W( u->pfx_rex ) ? 64 : ( ( u->pfx_opr ) ? 16 : 32 ) ;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 64;
+    } else if ( u->dis_mode == 32 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+        u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+    } else if ( u->dis_mode == 16 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+    }
+
+    return 0;
+}
+
+
+/* Searches the instruction tables for the right entry.
+ */
+static int search_itab( struct ud * u )
+{
+    struct ud_itab_entry * e = NULL;
+    enum ud_itab_index table;
+    uint8_t peek;
+    uint8_t did_peek = 0;
+    uint8_t curr; 
+    uint8_t index;
+
+    /* if in state of error, return */
+    if ( u->error ) 
+        return -1;
+
+    /* get first byte of opcode. */
+    inp_next(u); 
+    if ( u->error ) 
+        return -1;
+    curr = inp_curr(u); 
+
+    /* resolve xchg, nop, pause crazyness */
+    if ( 0x90 == curr ) {
+        if ( !( u->dis_mode == 64 && REX_B( u->pfx_rex ) ) ) {
+            if ( u->pfx_rep ) {
+                u->pfx_rep = 0;
+                e = & ie_pause;
+            } else {
+                e = & ie_nop;
+            }
+            goto found_entry;
+        }
+    }
+
+    /* get top-level table */
+    if ( 0x0F == curr ) {
+        table = ITAB__0F;
+        curr  = inp_next(u);
+        if ( u->error )
+            return -1;
+
+        /* 2byte opcodes can be modified by 0x66, F3, and F2 prefixes */
+        if ( 0x66 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSE66__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSE66__0F;
+                u->pfx_opr = 0;
+            }
+        } else if ( 0xF2 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF2__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF2__0F; 
+                u->pfx_repne = 0;
+            }
+        } else if ( 0xF3 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF3__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF3__0F;
+                u->pfx_repe = 0;
+                u->pfx_rep  = 0;
+            }
+        }
+    /* pick an instruction from the 1byte table */
+    } else {
+        table = ITAB__1BYTE; 
+    }
+
+    index = curr;
+
+search:
+
+    e = & ud_itab_list[ table ][ index ];
+
+    /* if mnemonic constant is a standard instruction constant
+     * our search is over.
+     */
+    
+    if ( e->mnemonic < UD_Id3vil ) {
+        if ( e->mnemonic == UD_Iinvalid ) {
+            if ( did_peek ) {
+                inp_next( u ); if ( u->error ) return -1;
+            }
+            goto found_entry;
+        }
+        goto found_entry;
+    }
+
+    table = e->prefix;
+
+    switch ( e->mnemonic )
+    {
+    case UD_Igrp_reg:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_REG( peek );
+        break;
+
+    case UD_Igrp_mod:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_MOD( peek );
+        if ( index == 3 )
+           index = ITAB__MOD_INDX__11;
+        else 
+           index = ITAB__MOD_INDX__NOT_11; 
+        break;
+
+    case UD_Igrp_rm:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = MODRM_RM( curr );
+        break;
+
+    case UD_Igrp_x87:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = curr - 0xC0;
+        break;
+
+    case UD_Igrp_osize:
+        if ( u->opr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->opr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+ 
+    case UD_Igrp_asize:
+        if ( u->adr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->adr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;               
+
+    case UD_Igrp_mode:
+        if ( u->dis_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->dis_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+
+    case UD_Igrp_vendor:
+        if ( u->vendor == UD_VENDOR_INTEL ) 
+            index = ITAB__VENDOR_INDX__INTEL; 
+        else if ( u->vendor == UD_VENDOR_AMD )
+            index = ITAB__VENDOR_INDX__AMD;
+        else {
+            kdbp("KDB:search_itab(): unrecognized vendor id\n");
+            return -1;
+        }
+        break;
+
+    case UD_Id3vil:
+        kdbp("KDB:search_itab(): invalid instr mnemonic constant Id3vil\n");
+        return -1;
+
+    default:
+        kdbp("KDB:search_itab(): invalid instruction mnemonic constant\n");
+        return -1;
+    }
+
+    goto search;
+
+found_entry:
+
+    u->itab_entry = e;
+    u->mnemonic = u->itab_entry->mnemonic;
+
+    return 0;
+}
+
+
+static unsigned int resolve_operand_size( const struct ud * u, unsigned int s )
+{
+    switch ( s ) 
+    {
+    case SZ_V:
+        return ( u->opr_mode );
+    case SZ_Z:  
+        return ( u->opr_mode == 16 ) ? 16 : 32;
+    case SZ_P:  
+        return ( u->opr_mode == 16 ) ? SZ_WP : SZ_DP;
+    case SZ_MDQ:
+        return ( u->opr_mode == 16 ) ? 32 : u->opr_mode;
+    case SZ_RDQ:
+        return ( u->dis_mode == 64 ) ? 64 : 32;
+    default:
+        return s;
+    }
+}
+
+
+static int resolve_mnemonic( struct ud* u )
+{
+  /* far/near flags */
+  u->br_far = 0;
+  u->br_near = 0;
+  /* readjust operand sizes for call/jmp instrcutions */
+  if ( u->mnemonic == UD_Icall || u->mnemonic == UD_Ijmp ) {
+    /* WP: 16bit pointer */
+    if ( u->operand[ 0 ].size == SZ_WP ) {
+        u->operand[ 0 ].size = 16;
+        u->br_far = 1;
+        u->br_near= 0;
+    /* DP: 32bit pointer */
+    } else if ( u->operand[ 0 ].size == SZ_DP ) {
+        u->operand[ 0 ].size = 32;
+        u->br_far = 1;
+        u->br_near= 0;
+    } else {
+        u->br_far = 0;
+        u->br_near= 1;
+    }
+  /* resolve 3dnow weirdness. */
+  } else if ( u->mnemonic == UD_I3dnow ) {
+    u->mnemonic = ud_itab_list[ ITAB__3DNOW ][ inp_curr( u )  ].mnemonic;
+  }
+  /* SWAPGS is only valid in 64bits mode */
+  if ( u->mnemonic == UD_Iswapgs && u->dis_mode != 64 ) {
+    u->error = 1;
+    return -1;
+  }
+
+  return 0;
+}
+
+
+/* -----------------------------------------------------------------------------
+ * decode_a()- Decodes operands of the type seg:offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_a(struct ud* u, struct ud_operand *op)
+{
+  if (u->opr_mode == 16) {  
+    /* seg16:off16 */
+    op->type = UD_OP_PTR;
+    op->size = 32;
+    op->lval.ptr.off = inp_uint16(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  } else {
+    /* seg16:off32 */
+    op->type = UD_OP_PTR;
+    op->size = 48;
+    op->lval.ptr.off = inp_uint32(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_gpr() - Returns decoded General Purpose Register 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+decode_gpr(register struct ud* u, unsigned int s, unsigned char rm)
+{
+  s = resolve_operand_size(u, s);
+        
+  switch (s) {
+    case 64:
+        return UD_R_RAX + rm;
+    case SZ_DP:
+    case 32:
+        return UD_R_EAX + rm;
+    case SZ_WP:
+    case 16:
+        return UD_R_AX  + rm;
+    case  8:
+        if (u->dis_mode == 64 && u->pfx_rex) {
+            if (rm >= 4)
+                return UD_R_SPL + (rm-4);
+            return UD_R_AL + rm;
+        } else return UD_R_AL + rm;
+    default:
+        return 0;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr64() - 64bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr64(struct ud* u, enum ud_operand_code gpr_op)
+{
+  if (gpr_op >= OP_rAXr8 && gpr_op <= OP_rDIr15)
+    gpr_op = (gpr_op - OP_rAXr8) | (REX_B(u->pfx_rex) << 3);          
+  else  gpr_op = (gpr_op - OP_rAX);
+
+  if (u->opr_mode == 16)
+    return gpr_op + UD_R_AX;
+  if (u->dis_mode == 32 || 
+    (u->opr_mode == 32 && ! (REX_W(u->pfx_rex) || u->default64))) {
+    return gpr_op + UD_R_EAX;
+  }
+
+  return gpr_op + UD_R_RAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr32 () - 32bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr32(struct ud* u, enum ud_operand_code gpr_op)
+{
+  gpr_op = gpr_op - OP_eAX;
+
+  if (u->opr_mode == 16) 
+    return gpr_op + UD_R_AX;
+
+  return gpr_op +  UD_R_EAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_reg() - Resolves the register type 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_reg(struct ud* u, unsigned int type, unsigned char i)
+{
+  switch (type) {
+    case T_MMX :    return UD_R_MM0  + (i & 7);
+    case T_XMM :    return UD_R_XMM0 + i;
+    case T_CRG :    return UD_R_CR0  + i;
+    case T_DBG :    return UD_R_DR0  + i;
+    case T_SEG :    return UD_R_ES   + (i & 7);
+    case T_NONE:
+    default:    return UD_NONE;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_imm() - Decodes Immediate values.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_imm(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  op->size = resolve_operand_size(u, s);
+  op->type = UD_OP_IMM;
+
+  switch (op->size) {
+    case  8: op->lval.sbyte = inp_uint8(u);   break;
+    case 16: op->lval.uword = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: return;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_modrm() - Decodes ModRM Byte
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_modrm(struct ud* u, struct ud_operand *op, unsigned int s, 
+         unsigned char rm_type, struct ud_operand *opreg, 
+         unsigned char reg_size, unsigned char reg_type)
+{
+  unsigned char mod, rm, reg;
+
+  inp_next(u);
+
+  /* get mod, r/m and reg fields */
+  mod = MODRM_MOD(inp_curr(u));
+  rm  = (REX_B(u->pfx_rex) << 3) | MODRM_RM(inp_curr(u));
+  reg = (REX_R(u->pfx_rex) << 3) | MODRM_REG(inp_curr(u));
+
+  op->size = resolve_operand_size(u, s);
+
+  /* if mod is 11b, then the UD_R_m specifies a gpr/mmx/sse/control/debug */
+  if (mod == 3) {
+    op->type = UD_OP_REG;
+    if (rm_type ==  T_GPR)
+        op->base = decode_gpr(u, op->size, rm);
+    else    op->base = resolve_reg(u, rm_type, (REX_B(u->pfx_rex) << 3) | (rm&7));
+  } 
+  /* else its memory addressing */  
+  else {
+    op->type = UD_OP_MEM;
+
+    /* 64bit addressing */
+    if (u->adr_mode == 64) {
+
+        op->base = UD_R_RAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && (rm & 7) == 5) {           
+            op->base = UD_R_RIP;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+            
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_RAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_RAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            /* special conditions for base reference */
+            if (op->index == UD_R_RSP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            if (op->base == UD_R_RBP || op->base == UD_R_R13) {
+                if (mod == 0) 
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 32-Bit addressing mode */
+    else if (u->adr_mode == 32) {
+
+        /* get base */
+        op->base = UD_R_EAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && rm == 5) {
+            op->base = UD_NONE;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_EAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_EAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            if (op->index == UD_R_ESP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            /* special condition for base reference */
+            if (op->base == UD_R_EBP) {
+                if (mod == 0)
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 16bit addressing mode */
+    else  {
+        switch (rm) {
+            case 0: op->base = UD_R_BX; op->index = UD_R_SI; break;
+            case 1: op->base = UD_R_BX; op->index = UD_R_DI; break;
+            case 2: op->base = UD_R_BP; op->index = UD_R_SI; break;
+            case 3: op->base = UD_R_BP; op->index = UD_R_DI; break;
+            case 4: op->base = UD_R_SI; break;
+            case 5: op->base = UD_R_DI; break;
+            case 6: op->base = UD_R_BP; break;
+            case 7: op->base = UD_R_BX; break;
+        }
+
+        if (mod == 0 && rm == 6) {
+            op->offset= 16;
+            op->base = UD_NONE;
+        }
+        else if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2) 
+            op->offset = 16;
+    }
+  }  
+
+  /* extract offset, if any */
+  switch(op->offset) {
+    case 8 : op->lval.ubyte  = inp_uint8(u);  break;
+    case 16: op->lval.uword  = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: break;
+  }
+
+  /* resolve register encoded in reg field */
+  if (opreg) {
+    opreg->type = UD_OP_REG;
+    opreg->size = resolve_operand_size(u, reg_size);
+    if (reg_type == T_GPR) 
+        opreg->base = decode_gpr(u, opreg->size, reg);
+    else opreg->base = resolve_reg(u, reg_type, reg);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_o() - Decodes offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_o(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  switch (u->adr_mode) {
+    case 64:
+        op->offset = 64; 
+        op->lval.uqword = inp_uint64(u); 
+        break;
+    case 32:
+        op->offset = 32; 
+        op->lval.udword = inp_uint32(u); 
+        break;
+    case 16:
+        op->offset = 16; 
+        op->lval.uword  = inp_uint16(u); 
+        break;
+    default:
+        return;
+  }
+  op->type = UD_OP_MEM;
+  op->size = resolve_operand_size(u, s);
+}
+
+/* -----------------------------------------------------------------------------
+ * disasm_operands() - Disassembles Operands.
+ * -----------------------------------------------------------------------------
+ */
+static int disasm_operands(register struct ud* u)
+{
+
+
+  /* mopXt = map entry, operand X, type; */
+  enum ud_operand_code mop1t = u->itab_entry->operand1.type;
+  enum ud_operand_code mop2t = u->itab_entry->operand2.type;
+  enum ud_operand_code mop3t = u->itab_entry->operand3.type;
+
+  /* mopXs = map entry, operand X, size */
+  unsigned int mop1s = u->itab_entry->operand1.size;
+  unsigned int mop2s = u->itab_entry->operand2.size;
+  unsigned int mop3s = u->itab_entry->operand3.size;
+
+  /* iop = instruction operand */
+  register struct ud_operand* iop = u->operand;
+    
+  switch(mop1t) {
+    
+    case OP_A :
+        decode_a(u, &(iop[0]));
+        break;
+    
+    /* M[b] ... */
+    case OP_M :
+        if (MODRM_MOD(inp_peek(u)) == 3)
+            u->error= 1;
+    /* E, G/P/V/I/CL/1/S */
+    case OP_E :
+        if (mop2t == OP_G) {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+            else if (mop3t == OP_CL) {
+                iop[2].type = UD_OP_REG;
+                iop[2].base = UD_R_CL;
+                iop[2].size = 8;
+            }
+        }
+        else if (mop2t == OP_P)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_MMX);
+        else if (mop2t == OP_V)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_XMM);
+        else if (mop2t == OP_S)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_SEG);
+        else {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, NULL, 0, T_NONE);
+            if (mop2t == OP_CL) {
+                iop[1].type = UD_OP_REG;
+                iop[1].base = UD_R_CL;
+                iop[1].size = 8;
+            } else if (mop2t == OP_I1) {
+                iop[1].type = UD_OP_CONST;
+                u->operand[1].lval.udword = 1;
+            } else if (mop2t == OP_I) {
+                decode_imm(u, mop2s, &(iop[1]));
+            }
+        }
+        break;
+
+    /* G, E/PR[,I]/VR */
+    case OP_G :
+        if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_W)
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        break;
+
+    /* AL..BH, I/O/DX */
+    case OP_AL : case OP_CL : case OP_DL : case OP_BL :
+    case OP_AH : case OP_CH : case OP_DH : case OP_BH :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AL + (mop1t - OP_AL);
+        iop[0].size = 8;
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        }
+        else if (mop2t == OP_O)
+            decode_o(u, mop2s, &(iop[1]));
+        break;
+
+    /* rAX[r8]..rDI[r15], I/rAX..rDI/O */
+    case OP_rAXr8 : case OP_rCXr9 : case OP_rDXr10 : case OP_rBXr11 :
+    case OP_rSPr12: case OP_rBPr13: case OP_rSIr14 : case OP_rDIr15 :
+    case OP_rAX : case OP_rCX : case OP_rDX : case OP_rBX :
+    case OP_rSP : case OP_rBP : case OP_rSI : case OP_rDI :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr64(u, mop1t);
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t >= OP_rAX && mop2t <= OP_rDI) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = resolve_gpr64(u, mop2t);
+        }
+        else if (mop2t == OP_O) {
+            decode_o(u, mop2s, &(iop[1]));  
+            iop[0].size = resolve_operand_size(u, mop2s);
+        }
+        break;
+
+    /* AL[r8b]..BH[r15b], I */
+    case OP_ALr8b : case OP_CLr9b : case OP_DLr10b : case OP_BLr11b :
+    case OP_AHr12b: case OP_CHr13b: case OP_DHr14b : case OP_BHr15b :
+    {
+        ud_type_t gpr = (mop1t - OP_ALr8b) + UD_R_AL + 
+                        (REX_B(u->pfx_rex) << 3);
+        if (UD_R_AH <= gpr && u->pfx_rex)
+            gpr = gpr + 4;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = gpr;
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+    }
+
+    /* eAX..eDX, DX/I */
+    case OP_eAX : case OP_eCX : case OP_eDX : case OP_eBX :
+    case OP_eSP : case OP_eBP : case OP_eSI : case OP_eDI :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr32(u, mop1t);
+        if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        } else if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+
+    /* ES..GS */
+    case OP_ES : case OP_CS : case OP_DS :
+    case OP_SS : case OP_FS : case OP_GS :
+
+        /* in 64bits mode, only fs and gs are allowed */
+        if (u->dis_mode == 64)
+            if (mop1t != OP_FS && mop1t != OP_GS)
+                u->error= 1;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t - OP_ES) + UD_R_ES;
+        iop[0].size = 16;
+
+        break;
+
+    /* J */
+    case OP_J :
+        decode_imm(u, mop1s, &(iop[0]));        
+        iop[0].type = UD_OP_JIMM;
+        break ;
+
+    /* PR, I */
+    case OP_PR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* VR, I */
+    case OP_VR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* P, Q[,I]/W/E[,I],VR */
+    case OP_P :
+        if (mop2t == OP_Q) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_W) {
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        }
+        break;
+
+    /* R, C/D */
+    case OP_R :
+        if (mop2t == OP_C)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_CRG);
+        else if (mop2t == OP_D)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_DBG);
+        break;
+
+    /* C, R */
+    case OP_C :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_CRG);
+        break;
+
+    /* D, R */
+    case OP_D :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_DBG);
+        break;
+
+    /* Q, P */
+    case OP_Q :
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, &(iop[1]), mop2s, T_MMX);
+        break;
+
+    /* S, E */
+    case OP_S :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_SEG);
+        break;
+
+    /* W, V */
+    case OP_W :
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, &(iop[1]), mop2s, T_XMM);
+        break;
+
+    /* V, W[,I]/Q/M/E */
+    case OP_V :
+        if (mop2t == OP_W) {
+            /* special cases for movlps and movhps */
+            if (MODRM_MOD(inp_peek(u)) == 3) {
+                if (u->mnemonic == UD_Imovlps)
+                    u->mnemonic = UD_Imovhlps;
+                else
+                if (u->mnemonic == UD_Imovhps)
+                    u->mnemonic = UD_Imovlhps;
+            }
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_XMM);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_Q)
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        else if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        }
+        break;
+
+    /* DX, eAX/AL */
+    case OP_DX :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_DX;
+        iop[0].size = 16;
+
+        if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        } else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 8;
+        }
+
+        break;
+
+    /* I, I/AL/eAX */
+    case OP_I :
+        decode_imm(u, mop1s, &(iop[0]));
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 16;
+        } else if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        }
+        break;
+
+    /* O, AL/eAX */
+    case OP_O :
+        decode_o(u, mop1s, &(iop[0]));
+        iop[1].type = UD_OP_REG;
+        iop[1].size = resolve_operand_size(u, mop1s);
+        if (mop2t == OP_AL)
+            iop[1].base = UD_R_AL;
+        else if (mop2t == OP_eAX)
+            iop[1].base = resolve_gpr32(u, mop2t);
+        else if (mop2t == OP_rAX)
+            iop[1].base = resolve_gpr64(u, mop2t);      
+        break;
+
+    /* 3 */
+    case OP_I3 :
+        iop[0].type = UD_OP_CONST;
+        iop[0].lval.sbyte = 3;
+        break;
+
+    /* ST(n), ST(n) */
+    case OP_ST0 : case OP_ST1 : case OP_ST2 : case OP_ST3 :
+    case OP_ST4 : case OP_ST5 : case OP_ST6 : case OP_ST7 :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t-OP_ST0) + UD_R_ST0;
+        iop[0].size = 0;
+
+        if (mop2t >= OP_ST0 && mop2t <= OP_ST7) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = (mop2t-OP_ST0) + UD_R_ST0;
+            iop[1].size = 0;
+        }
+        break;
+
+    /* AX */
+    case OP_AX:
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AX;
+        iop[0].size = 16;
+        break;
+
+    /* none */
+    default :
+        iop[0].type = iop[1].type = iop[2].type = UD_NONE;
+  }
+
+  return 0;
+}
+
+/* -----------------------------------------------------------------------------
+ * clear_insn() - clear instruction pointer 
+ * -----------------------------------------------------------------------------
+ */
+static int clear_insn(register struct ud* u)
+{
+  u->error     = 0;
+  u->pfx_seg   = 0;
+  u->pfx_opr   = 0;
+  u->pfx_adr   = 0;
+  u->pfx_lock  = 0;
+  u->pfx_repne = 0;
+  u->pfx_rep   = 0;
+  u->pfx_repe  = 0;
+  u->pfx_seg   = 0;
+  u->pfx_rex   = 0;
+  u->pfx_insn  = 0;
+  u->mnemonic  = UD_Inone;
+  u->itab_entry = NULL;
+
+  memset( &u->operand[ 0 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 1 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 2 ], 0, sizeof( struct ud_operand ) );
+ 
+  return 0;
+}
+
+static int do_mode( struct ud* u )
+{
+  /* if in error state, bail out */
+  if ( u->error ) return -1; 
+
+  /* propagate perfix effects */
+  if ( u->dis_mode == 64 ) {  /* set 64bit-mode flags */
+
+    /* Check validity of  instruction m64 */
+    if ( P_INV64( u->itab_entry->prefix ) ) {
+        u->error = 1;
+        return -1;
+    }
+
+    /* effective rex prefix is the  effective mask for the 
+     * instruction hard-coded in the opcode map.
+     */
+    u->pfx_rex = ( u->pfx_rex & 0x40 ) | 
+                 ( u->pfx_rex & REX_PFX_MASK( u->itab_entry->prefix ) ); 
+
+    /* whether this instruction has a default operand size of 
+     * 64bit, also hardcoded into the opcode map.
+     */
+    u->default64 = P_DEF64( u->itab_entry->prefix ); 
+    /* calculate effective operand size */
+    if ( REX_W( u->pfx_rex ) ) {
+        u->opr_mode = 64;
+    } else if ( u->pfx_opr ) {
+        u->opr_mode = 16;
+    } else {
+        /* unless the default opr size of instruction is 64,
+         * the effective operand size in the absence of rex.w
+         * prefix is 32.
+         */
+        u->opr_mode = ( u->default64 ) ? 64 : 32;
+    }
+
+    /* calculate effective address size */
+    u->adr_mode = (u->pfx_adr) ? 32 : 64;
+  } else if ( u->dis_mode == 32 ) { /* set 32bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+    u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+  } else if ( u->dis_mode == 16 ) { /* set 16bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+    u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+  }
+
+  /* These flags determine which operand to apply the operand size
+   * cast to.
+   */
+  u->c1 = ( P_C1( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c2 = ( P_C2( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c3 = ( P_C3( u->itab_entry->prefix ) ) ? 1 : 0;
+
+  /* set flags for implicit addressing */
+  u->implicit_addr = P_IMPADDR( u->itab_entry->prefix );
+
+  return 0;
+}
+
+static int gen_hex( struct ud *u )
+{
+  unsigned int i;
+  unsigned char *src_ptr = inp_sess( u );
+  char* src_hex;
+
+  /* bail out if in error stat. */
+  if ( u->error ) return -1; 
+  /* output buffer pointe */
+  src_hex = ( char* ) u->insn_hexcode;
+  /* for each byte used to decode instruction */
+  for ( i = 0; i < u->inp_ctr; ++i, ++src_ptr) {
+    snprintf( src_hex, 2, "%02x", *src_ptr & 0xFF );
+    src_hex += 2;
+  }
+  return 0;
+}
+
+/* =============================================================================
+ * ud_decode() - Instruction decoder. Returns the number of bytes decoded.
+ * =============================================================================
+ */
+unsigned int ud_decode( struct ud* u )
+{
+  inp_start(u);
+
+  if ( clear_insn( u ) ) {
+    ; /* error */
+  } else if ( get_prefixes( u ) != 0 ) {
+    ; /* error */
+  } else if ( search_itab( u ) != 0 ) {
+    ; /* error */
+  } else if ( do_mode( u ) != 0 ) {
+    ; /* error */
+  } else if ( disasm_operands( u ) != 0 ) {
+    ; /* error */
+  } else if ( resolve_mnemonic( u ) != 0 ) {
+    ; /* error */
+  }
+
+  /* Handle decode error. */
+  if ( u->error ) {
+    /* clear out the decode data. */
+    clear_insn( u );
+    /* mark the sequence of bytes as invalid. */
+    u->itab_entry = & ie_invalid;
+    u->mnemonic = u->itab_entry->mnemonic;
+  } 
+
+  u->insn_offset = u->pc; /* set offset of instruction */
+  u->insn_fill = 0;   /* set translation buffer index to 0 */
+  u->pc += u->inp_ctr;    /* move program counter by bytes decoded */
+  gen_hex( u );       /* generate hex code */
+
+  /* return number of bytes disassembled. */
+  return u->inp_ctr;
+}
+
+/* vim:cindent
+ * vim:ts=4
+ * vim:sw=4
+ * vim:expandtab
+ */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/decode.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,273 @@
+#ifndef UD_DECODE_H
+#define UD_DECODE_H
+
+#define MAX_INSN_LENGTH 15
+
+/* register classes */
+#define T_NONE  0
+#define T_GPR   1
+#define T_MMX   2
+#define T_CRG   3
+#define T_DBG   4
+#define T_SEG   5
+#define T_XMM   6
+
+/* itab prefix bits */
+#define P_none          ( 0 )
+#define P_c1            ( 1 << 0 )
+#define P_C1(n)         ( ( n >> 0 ) & 1 )
+#define P_rexb          ( 1 << 1 )
+#define P_REXB(n)       ( ( n >> 1 ) & 1 )
+#define P_depM          ( 1 << 2 )
+#define P_DEPM(n)       ( ( n >> 2 ) & 1 )
+#define P_c3            ( 1 << 3 )
+#define P_C3(n)         ( ( n >> 3 ) & 1 )
+#define P_inv64         ( 1 << 4 )
+#define P_INV64(n)      ( ( n >> 4 ) & 1 )
+#define P_rexw          ( 1 << 5 )
+#define P_REXW(n)       ( ( n >> 5 ) & 1 )
+#define P_c2            ( 1 << 6 )
+#define P_C2(n)         ( ( n >> 6 ) & 1 )
+#define P_def64         ( 1 << 7 )
+#define P_DEF64(n)      ( ( n >> 7 ) & 1 )
+#define P_rexr          ( 1 << 8 )
+#define P_REXR(n)       ( ( n >> 8 ) & 1 )
+#define P_oso           ( 1 << 9 )
+#define P_OSO(n)        ( ( n >> 9 ) & 1 )
+#define P_aso           ( 1 << 10 )
+#define P_ASO(n)        ( ( n >> 10 ) & 1 )
+#define P_rexx          ( 1 << 11 )
+#define P_REXX(n)       ( ( n >> 11 ) & 1 )
+#define P_ImpAddr       ( 1 << 12 )
+#define P_IMPADDR(n)    ( ( n >> 12 ) & 1 )
+
+/* rex prefix bits */
+#define REX_W(r)        ( ( 0xF & ( r ) )  >> 3 )
+#define REX_R(r)        ( ( 0x7 & ( r ) )  >> 2 )
+#define REX_X(r)        ( ( 0x3 & ( r ) )  >> 1 )
+#define REX_B(r)        ( ( 0x1 & ( r ) )  >> 0 )
+#define REX_PFX_MASK(n) ( ( P_REXW(n) << 3 ) | \
+                          ( P_REXR(n) << 2 ) | \
+                          ( P_REXX(n) << 1 ) | \
+                          ( P_REXB(n) << 0 ) )
+
+/* scable-index-base bits */
+#define SIB_S(b)        ( ( b ) >> 6 )
+#define SIB_I(b)        ( ( ( b ) >> 3 ) & 7 )
+#define SIB_B(b)        ( ( b ) & 7 )
+
+/* modrm bits */
+#define MODRM_REG(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_NNN(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_MOD(b)    ( ( ( b ) >> 6 ) & 3 )
+#define MODRM_RM(b)     ( ( b ) & 7 )
+
+/* operand type constants -- order is important! */
+
+enum ud_operand_code {
+    OP_NONE,
+
+    OP_A,      OP_E,      OP_M,       OP_G,       
+    OP_I,
+
+    OP_AL,     OP_CL,     OP_DL,      OP_BL,
+    OP_AH,     OP_CH,     OP_DH,      OP_BH,
+
+    OP_ALr8b,  OP_CLr9b,  OP_DLr10b,  OP_BLr11b,
+    OP_AHr12b, OP_CHr13b, OP_DHr14b,  OP_BHr15b,
+
+    OP_AX,     OP_CX,     OP_DX,      OP_BX,
+    OP_SI,     OP_DI,     OP_SP,      OP_BP,
+
+    OP_rAX,    OP_rCX,    OP_rDX,     OP_rBX,  
+    OP_rSP,    OP_rBP,    OP_rSI,     OP_rDI,
+
+    OP_rAXr8,  OP_rCXr9,  OP_rDXr10,  OP_rBXr11,  
+    OP_rSPr12, OP_rBPr13, OP_rSIr14,  OP_rDIr15,
+
+    OP_eAX,    OP_eCX,    OP_eDX,     OP_eBX,
+    OP_eSP,    OP_eBP,    OP_eSI,     OP_eDI,
+
+    OP_ES,     OP_CS,     OP_SS,      OP_DS,  
+    OP_FS,     OP_GS,
+
+    OP_ST0,    OP_ST1,    OP_ST2,     OP_ST3,
+    OP_ST4,    OP_ST5,    OP_ST6,     OP_ST7,
+
+    OP_J,      OP_S,      OP_O,          
+    OP_I1,     OP_I3, 
+
+    OP_V,      OP_W,      OP_Q,       OP_P, 
+
+    OP_R,      OP_C,  OP_D,       OP_VR,  OP_PR
+};
+
+
+/* operand size constants */
+
+enum ud_operand_size {
+    SZ_NA  = 0,
+    SZ_Z   = 1,
+    SZ_V   = 2,
+    SZ_P   = 3,
+    SZ_WP  = 4,
+    SZ_DP  = 5,
+    SZ_MDQ = 6,
+    SZ_RDQ = 7,
+
+    /* the following values are used as is,
+     * and thus hard-coded. changing them 
+     * will break internals 
+     */
+    SZ_B   = 8,
+    SZ_W   = 16,
+    SZ_D   = 32,
+    SZ_Q   = 64,
+    SZ_T   = 80,
+};
+
+/* itab entry operand definitions */
+
+#define O_rSPr12  { OP_rSPr12,   SZ_NA    }
+#define O_BL      { OP_BL,       SZ_NA    }
+#define O_BH      { OP_BH,       SZ_NA    }
+#define O_BP      { OP_BP,       SZ_NA    }
+#define O_AHr12b  { OP_AHr12b,   SZ_NA    }
+#define O_BX      { OP_BX,       SZ_NA    }
+#define O_Jz      { OP_J,        SZ_Z     }
+#define O_Jv      { OP_J,        SZ_V     }
+#define O_Jb      { OP_J,        SZ_B     }
+#define O_rSIr14  { OP_rSIr14,   SZ_NA    }
+#define O_GS      { OP_GS,       SZ_NA    }
+#define O_D       { OP_D,        SZ_NA    }
+#define O_rBPr13  { OP_rBPr13,   SZ_NA    }
+#define O_Ob      { OP_O,        SZ_B     }
+#define O_P       { OP_P,        SZ_NA    }
+#define O_Ow      { OP_O,        SZ_W     }
+#define O_Ov      { OP_O,        SZ_V     }
+#define O_Gw      { OP_G,        SZ_W     }
+#define O_Gv      { OP_G,        SZ_V     }
+#define O_rDX     { OP_rDX,      SZ_NA    }
+#define O_Gx      { OP_G,        SZ_MDQ   }
+#define O_Gd      { OP_G,        SZ_D     }
+#define O_Gb      { OP_G,        SZ_B     }
+#define O_rBXr11  { OP_rBXr11,   SZ_NA    }
+#define O_rDI     { OP_rDI,      SZ_NA    }
+#define O_rSI     { OP_rSI,      SZ_NA    }
+#define O_ALr8b   { OP_ALr8b,    SZ_NA    }
+#define O_eDI     { OP_eDI,      SZ_NA    }
+#define O_Gz      { OP_G,        SZ_Z     }
+#define O_eDX     { OP_eDX,      SZ_NA    }
+#define O_DHr14b  { OP_DHr14b,   SZ_NA    }
+#define O_rSP     { OP_rSP,      SZ_NA    }
+#define O_PR      { OP_PR,       SZ_NA    }
+#define O_NONE    { OP_NONE,     SZ_NA    }
+#define O_rCX     { OP_rCX,      SZ_NA    }
+#define O_jWP     { OP_J,        SZ_WP    }
+#define O_rDXr10  { OP_rDXr10,   SZ_NA    }
+#define O_Md      { OP_M,        SZ_D     }
+#define O_C       { OP_C,        SZ_NA    }
+#define O_G       { OP_G,        SZ_NA    }
+#define O_Mb      { OP_M,        SZ_B     }
+#define O_Mt      { OP_M,        SZ_T     }
+#define O_S       { OP_S,        SZ_NA    }
+#define O_Mq      { OP_M,        SZ_Q     }
+#define O_W       { OP_W,        SZ_NA    }
+#define O_ES      { OP_ES,       SZ_NA    }
+#define O_rBX     { OP_rBX,      SZ_NA    }
+#define O_Ed      { OP_E,        SZ_D     }
+#define O_DLr10b  { OP_DLr10b,   SZ_NA    }
+#define O_Mw      { OP_M,        SZ_W     }
+#define O_Eb      { OP_E,        SZ_B     }
+#define O_Ex      { OP_E,        SZ_MDQ   }
+#define O_Ez      { OP_E,        SZ_Z     }
+#define O_Ew      { OP_E,        SZ_W     }
+#define O_Ev      { OP_E,        SZ_V     }
+#define O_Ep      { OP_E,        SZ_P     }
+#define O_FS      { OP_FS,       SZ_NA    }
+#define O_Ms      { OP_M,        SZ_W     }
+#define O_rAXr8   { OP_rAXr8,    SZ_NA    }
+#define O_eBP     { OP_eBP,      SZ_NA    }
+#define O_Isb     { OP_I,        SZ_SB    }
+#define O_eBX     { OP_eBX,      SZ_NA    }
+#define O_rCXr9   { OP_rCXr9,    SZ_NA    }
+#define O_jDP     { OP_J,        SZ_DP    }
+#define O_CH      { OP_CH,       SZ_NA    }
+#define O_CL      { OP_CL,       SZ_NA    }
+#define O_R       { OP_R,        SZ_RDQ   }
+#define O_V       { OP_V,        SZ_NA    }
+#define O_CS      { OP_CS,       SZ_NA    }
+#define O_CHr13b  { OP_CHr13b,   SZ_NA    }
+#define O_eCX     { OP_eCX,      SZ_NA    }
+#define O_eSP     { OP_eSP,      SZ_NA    }
+#define O_SS      { OP_SS,       SZ_NA    }
+#define O_SP      { OP_SP,       SZ_NA    }
+#define O_BLr11b  { OP_BLr11b,   SZ_NA    }
+#define O_SI      { OP_SI,       SZ_NA    }
+#define O_eSI     { OP_eSI,      SZ_NA    }
+#define O_DL      { OP_DL,       SZ_NA    }
+#define O_DH      { OP_DH,       SZ_NA    }
+#define O_DI      { OP_DI,       SZ_NA    }
+#define O_DX      { OP_DX,       SZ_NA    }
+#define O_rBP     { OP_rBP,      SZ_NA    }
+#define O_Gvw     { OP_G,        SZ_MDQ   }
+#define O_I1      { OP_I1,       SZ_NA    }
+#define O_I3      { OP_I3,       SZ_NA    }
+#define O_DS      { OP_DS,       SZ_NA    }
+#define O_ST4     { OP_ST4,      SZ_NA    }
+#define O_ST5     { OP_ST5,      SZ_NA    }
+#define O_ST6     { OP_ST6,      SZ_NA    }
+#define O_ST7     { OP_ST7,      SZ_NA    }
+#define O_ST0     { OP_ST0,      SZ_NA    }
+#define O_ST1     { OP_ST1,      SZ_NA    }
+#define O_ST2     { OP_ST2,      SZ_NA    }
+#define O_ST3     { OP_ST3,      SZ_NA    }
+#define O_E       { OP_E,        SZ_NA    }
+#define O_AH      { OP_AH,       SZ_NA    }
+#define O_M       { OP_M,        SZ_NA    }
+#define O_AL      { OP_AL,       SZ_NA    }
+#define O_CLr9b   { OP_CLr9b,    SZ_NA    }
+#define O_Q       { OP_Q,        SZ_NA    }
+#define O_eAX     { OP_eAX,      SZ_NA    }
+#define O_VR      { OP_VR,       SZ_NA    }
+#define O_AX      { OP_AX,       SZ_NA    }
+#define O_rAX     { OP_rAX,      SZ_NA    }
+#define O_Iz      { OP_I,        SZ_Z     }
+#define O_rDIr15  { OP_rDIr15,   SZ_NA    }
+#define O_Iw      { OP_I,        SZ_W     }
+#define O_Iv      { OP_I,        SZ_V     }
+#define O_Ap      { OP_A,        SZ_P     }
+#define O_CX      { OP_CX,       SZ_NA    }
+#define O_Ib      { OP_I,        SZ_B     }
+#define O_BHr15b  { OP_BHr15b,   SZ_NA    }
+
+
+/* A single operand of an entry in the instruction table. 
+ * (internal use only)
+ */
+struct ud_itab_entry_operand 
+{
+  enum ud_operand_code type;
+  enum ud_operand_size size;
+};
+
+
+/* A single entry in an instruction table. 
+ *(internal use only)
+ */
+struct ud_itab_entry 
+{
+  enum ud_mnemonic_code         mnemonic;
+  struct ud_itab_entry_operand  operand1;
+  struct ud_itab_entry_operand  operand2;
+  struct ud_itab_entry_operand  operand3;
+  uint32_t                      prefix;
+};
+
+#endif /* UD_DECODE_H */
+
+/* vim:cindent
+ * vim:expandtab
+ * vim:ts=4
+ * vim:sw=4
+ */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/extern.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,67 @@
+/* -----------------------------------------------------------------------------
+ * extern.h
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_EXTERN_H
+#define UD_EXTERN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #include <stdio.h> */
+#include "types.h"
+
+/* ============================= PUBLIC API ================================= */
+
+extern void ud_init(struct ud*);
+
+extern void ud_set_mode(struct ud*, uint8_t);
+
+extern void ud_set_pc(struct ud*, uint64_t);
+
+extern void ud_set_input_hook(struct ud*, int (*)(struct ud*));
+
+extern void ud_set_input_buffer(struct ud*, uint8_t*, size_t);
+
+#ifndef __UD_STANDALONE__
+extern void ud_set_input_file(struct ud*, FILE*);
+#endif /* __UD_STANDALONE__ */
+
+extern void ud_set_vendor(struct ud*, unsigned);
+
+extern void ud_set_syntax(struct ud*, void (*)(struct ud*));
+
+extern void ud_input_skip(struct ud*, size_t);
+
+extern int ud_input_end(struct ud*);
+
+extern unsigned int ud_decode(struct ud*);
+
+extern unsigned int ud_disassemble(struct ud*);
+
+extern void ud_translate_intel(struct ud*);
+
+extern void ud_translate_att(struct ud*);
+
+extern char* ud_insn_asm(struct ud* u);
+
+extern uint8_t* ud_insn_ptr(struct ud* u);
+
+extern uint64_t ud_insn_off(struct ud*);
+
+extern char* ud_insn_hex(struct ud*);
+
+extern unsigned int ud_insn_len(struct ud* u);
+
+extern const char* ud_lookup_mnemonic(enum ud_mnemonic_code c);
+
+/* ========================================================================== */
+
+#ifdef __cplusplus
+}
+#endif
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/input.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,226 @@
+/* -----------------------------------------------------------------------------
+ * input.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#include "extern.h"
+#include "types.h"
+#include "input.h"
+
+/* -----------------------------------------------------------------------------
+ * inp_buff_hook() - Hook for buffered inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_buff_hook(struct ud* u)
+{
+  if (u->inp_buff < u->inp_buff_end)
+	return *u->inp_buff++;
+  else	return -1;
+}
+
+#ifndef __UD_STANDALONE__
+/* -----------------------------------------------------------------------------
+ * inp_file_hook() - Hook for FILE inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_file_hook(struct ud* u)
+{
+  return fgetc(u->inp_file);
+}
+#endif /* __UD_STANDALONE__*/
+
+/* =============================================================================
+ * ud_inp_set_hook() - Sets input hook.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_hook(register struct ud* u, int (*hook)(struct ud*))
+{
+  u->inp_hook = hook;
+  inp_init(u);
+}
+
+/* =============================================================================
+ * ud_inp_set_buffer() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_buffer(register struct ud* u, uint8_t* buf, size_t len)
+{
+  u->inp_hook = inp_buff_hook;
+  u->inp_buff = buf;
+  u->inp_buff_end = buf + len;
+  inp_init(u);
+}
+
+#ifndef __UD_STANDALONE__
+/* =============================================================================
+ * ud_input_set_file() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_file(register struct ud* u, FILE* f)
+{
+  u->inp_hook = inp_file_hook;
+  u->inp_file = f;
+  inp_init(u);
+}
+#endif /* __UD_STANDALONE__ */
+
+/* =============================================================================
+ * ud_input_skip() - Skip n input bytes.
+ * =============================================================================
+ */
+extern void 
+ud_input_skip(struct ud* u, size_t n)
+{
+  while (n--) {
+	u->inp_hook(u);
+  }
+}
+
+/* =============================================================================
+ * ud_input_end() - Test for end of input.
+ * =============================================================================
+ */
+extern int 
+ud_input_end(struct ud* u)
+{
+  return (u->inp_curr == u->inp_fill) && u->inp_end;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_next() - Loads and returns the next byte from input.
+ *
+ * inp_curr and inp_fill are pointers to the cache. The program is written based
+ * on the property that they are 8-bits in size, and will eventually wrap around
+ * forming a circular buffer. So, the size of the cache is 256 in size, kind of
+ * unnecessary yet optimized.
+ *
+ * A buffer inp_sess stores the bytes disassembled for a single session.
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t inp_next(struct ud* u) 
+{
+  int c = -1;
+  /* if current pointer is not upto the fill point in the 
+   * input cache.
+   */
+  if ( u->inp_curr != u->inp_fill ) {
+	c = u->inp_cache[ ++u->inp_curr ];
+  /* if !end-of-input, call the input hook and get a byte */
+  } else if ( u->inp_end || ( c = u->inp_hook( u ) ) == -1 ) {
+	/* end-of-input, mark it as an error, since the decoder,
+	 * expected a byte more.
+	 */
+	u->error = 1;
+	/* flag end of input */
+	u->inp_end = 1;
+	return 0;
+  } else {
+	/* increment pointers, we have a new byte.  */
+	u->inp_curr = ++u->inp_fill;
+	/* add the byte to the cache */
+	u->inp_cache[ u->inp_fill ] = c;
+  }
+  /* record bytes input per decode-session. */
+  u->inp_sess[ u->inp_ctr++ ] = c;
+  /* return byte */
+  return ( uint8_t ) c;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_back() - Move back a single byte in the stream.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_back(struct ud* u) 
+{
+  if ( u->inp_ctr > 0 ) {
+	--u->inp_curr;
+	--u->inp_ctr;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_peek() - Peek into the next byte in source. 
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t
+inp_peek(struct ud* u) 
+{
+  uint8_t r = inp_next(u);
+  if ( !u->error ) inp_back(u); /* Don't backup if there was an error */
+  return r;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_move() - Move ahead n input bytes.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_move(struct ud* u, size_t n) 
+{
+  while (n--)
+	inp_next(u);
+}
+
+/*------------------------------------------------------------------------------
+ *  inp_uintN() - return uintN from source.
+ *------------------------------------------------------------------------------
+ */
+extern uint8_t 
+inp_uint8(struct ud* u)
+{
+  return inp_next(u);
+}
+
+extern uint16_t 
+inp_uint16(struct ud* u)
+{
+  uint16_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  return ret | (r << 8);
+}
+
+extern uint32_t 
+inp_uint32(struct ud* u)
+{
+  uint32_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  return ret | (r << 24);
+}
+
+extern uint64_t 
+inp_uint64(struct ud* u)
+{
+  uint64_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  ret = ret | (r << 24);
+  r = inp_next(u);
+  ret = ret | (r << 32);
+  r = inp_next(u);
+  ret = ret | (r << 40);
+  r = inp_next(u);
+  ret = ret | (r << 48);
+  r = inp_next(u);
+  return ret | (r << 56);
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/input.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,49 @@
+/* -----------------------------------------------------------------------------
+ * input.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_INPUT_H
+#define UD_INPUT_H
+
+#include "types.h"
+
+uint8_t inp_next(struct ud*);
+uint8_t inp_peek(struct ud*);
+uint8_t inp_uint8(struct ud*);
+uint16_t inp_uint16(struct ud*);
+uint32_t inp_uint32(struct ud*);
+uint64_t inp_uint64(struct ud*);
+void inp_move(struct ud*, size_t);
+void inp_back(struct ud*);
+
+/* inp_init() - Initializes the input system. */
+#define inp_init(u) \
+do { \
+  u->inp_curr = 0; \
+  u->inp_fill = 0; \
+  u->inp_ctr  = 0; \
+  u->inp_end  = 0; \
+} while (0)
+
+/* inp_start() - Should be called before each de-code operation. */
+#define inp_start(u) u->inp_ctr = 0
+
+/* inp_back() - Resets the current pointer to its position before the current
+ * instruction disassembly was started.
+ */
+#define inp_reset(u) \
+do { \
+  u->inp_curr -= u->inp_ctr; \
+  u->inp_ctr = 0; \
+} while (0)
+
+/* inp_sess() - Returns the pointer to current session. */
+#define inp_sess(u) (u->inp_sess)
+
+/* inp_cur() - Returns the current input byte. */
+#define inp_curr(u) ((u)->inp_cache[(u)->inp_curr])
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/itab.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3668 @@
+
+/* itab.c -- auto generated by opgen.py, do not edit. */
+
+#include "types.h"
+#include "decode.h"
+#include "itab.h"
+
+const char * ud_mnemonics_str[] = {
+  "3dnow",
+  "aaa",
+  "aad",
+  "aam",
+  "aas",
+  "adc",
+  "add",
+  "addpd",
+  "addps",
+  "addsd",
+  "addss",
+  "addsubpd",
+  "addsubps",
+  "and",
+  "andpd",
+  "andps",
+  "andnpd",
+  "andnps",
+  "arpl",
+  "movsxd",
+  "bound",
+  "bsf",
+  "bsr",
+  "bswap",
+  "bt",
+  "btc",
+  "btr",
+  "bts",
+  "call",
+  "cbw",
+  "cwde",
+  "cdqe",
+  "clc",
+  "cld",
+  "clflush",
+  "clgi",
+  "cli",
+  "clts",
+  "cmc",
+  "cmovo",
+  "cmovno",
+  "cmovb",
+  "cmovae",
+  "cmovz",
+  "cmovnz",
+  "cmovbe",
+  "cmova",
+  "cmovs",
+  "cmovns",
+  "cmovp",
+  "cmovnp",
+  "cmovl",
+  "cmovge",
+  "cmovle",
+  "cmovg",
+  "cmp",
+  "cmppd",
+  "cmpps",
+  "cmpsb",
+  "cmpsw",
+  "cmpsd",
+  "cmpsq",
+  "cmpss",
+  "cmpxchg",
+  "cmpxchg8b",
+  "comisd",
+  "comiss",
+  "cpuid",
+  "cvtdq2pd",
+  "cvtdq2ps",
+  "cvtpd2dq",
+  "cvtpd2pi",
+  "cvtpd2ps",
+  "cvtpi2ps",
+  "cvtpi2pd",
+  "cvtps2dq",
+  "cvtps2pi",
+  "cvtps2pd",
+  "cvtsd2si",
+  "cvtsd2ss",
+  "cvtsi2ss",
+  "cvtss2si",
+  "cvtss2sd",
+  "cvttpd2pi",
+  "cvttpd2dq",
+  "cvttps2dq",
+  "cvttps2pi",
+  "cvttsd2si",
+  "cvtsi2sd",
+  "cvttss2si",
+  "cwd",
+  "cdq",
+  "cqo",
+  "daa",
+  "das",
+  "dec",
+  "div",
+  "divpd",
+  "divps",
+  "divsd",
+  "divss",
+  "emms",
+  "enter",
+  "f2xm1",
+  "fabs",
+  "fadd",
+  "faddp",
+  "fbld",
+  "fbstp",
+  "fchs",
+  "fclex",
+  "fcmovb",
+  "fcmove",
+  "fcmovbe",
+  "fcmovu",
+  "fcmovnb",
+  "fcmovne",
+  "fcmovnbe",
+  "fcmovnu",
+  "fucomi",
+  "fcom",
+  "fcom2",
+  "fcomp3",
+  "fcomi",
+  "fucomip",
+  "fcomip",
+  "fcomp",
+  "fcomp5",
+  "fcompp",
+  "fcos",
+  "fdecstp",
+  "fdiv",
+  "fdivp",
+  "fdivr",
+  "fdivrp",
+  "femms",
+  "ffree",
+  "ffreep",
+  "ficom",
+  "ficomp",
+  "fild",
+  "fncstp",
+  "fninit",
+  "fiadd",
+  "fidivr",
+  "fidiv",
+  "fisub",
+  "fisubr",
+  "fist",
+  "fistp",
+  "fisttp",
+  "fld",
+  "fld1",
+  "fldl2t",
+  "fldl2e",
+  "fldlpi",
+  "fldlg2",
+  "fldln2",
+  "fldz",
+  "fldcw",
+  "fldenv",
+  "fmul",
+  "fmulp",
+  "fimul",
+  "fnop",
+  "fpatan",
+  "fprem",
+  "fprem1",
+  "fptan",
+  "frndint",
+  "frstor",
+  "fnsave",
+  "fscale",
+  "fsin",
+  "fsincos",
+  "fsqrt",
+  "fstp",
+  "fstp1",
+  "fstp8",
+  "fstp9",
+  "fst",
+  "fnstcw",
+  "fnstenv",
+  "fnstsw",
+  "fsub",
+  "fsubp",
+  "fsubr",
+  "fsubrp",
+  "ftst",
+  "fucom",
+  "fucomp",
+  "fucompp",
+  "fxam",
+  "fxch",
+  "fxch4",
+  "fxch7",
+  "fxrstor",
+  "fxsave",
+  "fpxtract",
+  "fyl2x",
+  "fyl2xp1",
+  "haddpd",
+  "haddps",
+  "hlt",
+  "hsubpd",
+  "hsubps",
+  "idiv",
+  "in",
+  "imul",
+  "inc",
+  "insb",
+  "insw",
+  "insd",
+  "int1",
+  "int3",
+  "int",
+  "into",
+  "invd",
+  "invlpg",
+  "invlpga",
+  "iretw",
+  "iretd",
+  "iretq",
+  "jo",
+  "jno",
+  "jb",
+  "jae",
+  "jz",
+  "jnz",
+  "jbe",
+  "ja",
+  "js",
+  "jns",
+  "jp",
+  "jnp",
+  "jl",
+  "jge",
+  "jle",
+  "jg",
+  "jcxz",
+  "jecxz",
+  "jrcxz",
+  "jmp",
+  "lahf",
+  "lar",
+  "lddqu",
+  "ldmxcsr",
+  "lds",
+  "lea",
+  "les",
+  "lfs",
+  "lgs",
+  "lidt",
+  "lss",
+  "leave",
+  "lfence",
+  "lgdt",
+  "lldt",
+  "lmsw",
+  "lock",
+  "lodsb",
+  "lodsw",
+  "lodsd",
+  "lodsq",
+  "loopnz",
+  "loope",
+  "loop",
+  "lsl",
+  "ltr",
+  "maskmovq",
+  "maxpd",
+  "maxps",
+  "maxsd",
+  "maxss",
+  "mfence",
+  "minpd",
+  "minps",
+  "minsd",
+  "minss",
+  "monitor",
+  "mov",
+  "movapd",
+  "movaps",
+  "movd",
+  "movddup",
+  "movdqa",
+  "movdqu",
+  "movdq2q",
+  "movhpd",
+  "movhps",
+  "movlhps",
+  "movlpd",
+  "movlps",
+  "movhlps",
+  "movmskpd",
+  "movmskps",
+  "movntdq",
+  "movnti",
+  "movntpd",
+  "movntps",
+  "movntq",
+  "movq",
+  "movqa",
+  "movq2dq",
+  "movsb",
+  "movsw",
+  "movsd",
+  "movsq",
+  "movsldup",
+  "movshdup",
+  "movss",
+  "movsx",
+  "movupd",
+  "movups",
+  "movzx",
+  "mul",
+  "mulpd",
+  "mulps",
+  "mulsd",
+  "mulss",
+  "mwait",
+  "neg",
+  "nop",
+  "not",
+  "or",
+  "orpd",
+  "orps",
+  "out",
+  "outsb",
+  "outsw",
+  "outsd",
+  "outsq",
+  "packsswb",
+  "packssdw",
+  "packuswb",
+  "paddb",
+  "paddw",
+  "paddq",
+  "paddsb",
+  "paddsw",
+  "paddusb",
+  "paddusw",
+  "pand",
+  "pandn",
+  "pause",
+  "pavgb",
+  "pavgw",
+  "pcmpeqb",
+  "pcmpeqw",
+  "pcmpeqd",
+  "pcmpgtb",
+  "pcmpgtw",
+  "pcmpgtd",
+  "pextrw",
+  "pinsrw",
+  "pmaddwd",
+  "pmaxsw",
+  "pmaxub",
+  "pminsw",
+  "pminub",
+  "pmovmskb",
+  "pmulhuw",
+  "pmulhw",
+  "pmullw",
+  "pmuludq",
+  "pop",
+  "popa",
+  "popad",
+  "popfw",
+  "popfd",
+  "popfq",
+  "por",
+  "prefetch",
+  "prefetchnta",
+  "prefetcht0",
+  "prefetcht1",
+  "prefetcht2",
+  "psadbw",
+  "pshufd",
+  "pshufhw",
+  "pshuflw",
+  "pshufw",
+  "pslldq",
+  "psllw",
+  "pslld",
+  "psllq",
+  "psraw",
+  "psrad",
+  "psrlw",
+  "psrld",
+  "psrlq",
+  "psrldq",
+  "psubb",
+  "psubw",
+  "psubd",
+  "psubq",
+  "psubsb",
+  "psubsw",
+  "psubusb",
+  "psubusw",
+  "punpckhbw",
+  "punpckhwd",
+  "punpckhdq",
+  "punpckhqdq",
+  "punpcklbw",
+  "punpcklwd",
+  "punpckldq",
+  "punpcklqdq",
+  "pi2fw",
+  "pi2fd",
+  "pf2iw",
+  "pf2id",
+  "pfnacc",
+  "pfpnacc",
+  "pfcmpge",
+  "pfmin",
+  "pfrcp",
+  "pfrsqrt",
+  "pfsub",
+  "pfadd",
+  "pfcmpgt",
+  "pfmax",
+  "pfrcpit1",
+  "pfrspit1",
+  "pfsubr",
+  "pfacc",
+  "pfcmpeq",
+  "pfmul",
+  "pfrcpit2",
+  "pmulhrw",
+  "pswapd",
+  "pavgusb",
+  "push",
+  "pusha",
+  "pushad",
+  "pushfw",
+  "pushfd",
+  "pushfq",
+  "pxor",
+  "rcl",
+  "rcr",
+  "rol",
+  "ror",
+  "rcpps",
+  "rcpss",
+  "rdmsr",
+  "rdpmc",
+  "rdtsc",
+  "rdtscp",
+  "repne",
+  "rep",
+  "ret",
+  "retf",
+  "rsm",
+  "rsqrtps",
+  "rsqrtss",
+  "sahf",
+  "sal",
+  "salc",
+  "sar",
+  "shl",
+  "shr",
+  "sbb",
+  "scasb",
+  "scasw",
+  "scasd",
+  "scasq",
+  "seto",
+  "setno",
+  "setb",
+  "setnb",
+  "setz",
+  "setnz",
+  "setbe",
+  "seta",
+  "sets",
+  "setns",
+  "setp",
+  "setnp",
+  "setl",
+  "setge",
+  "setle",
+  "setg",
+  "sfence",
+  "sgdt",
+  "shld",
+  "shrd",
+  "shufpd",
+  "shufps",
+  "sidt",
+  "sldt",
+  "smsw",
+  "sqrtps",
+  "sqrtpd",
+  "sqrtsd",
+  "sqrtss",
+  "stc",
+  "std",
+  "stgi",
+  "sti",
+  "skinit",
+  "stmxcsr",
+  "stosb",
+  "stosw",
+  "stosd",
+  "stosq",
+  "str",
+  "sub",
+  "subpd",
+  "subps",
+  "subsd",
+  "subss",
+  "swapgs",
+  "syscall",
+  "sysenter",
+  "sysexit",
+  "sysret",
+  "test",
+  "ucomisd",
+  "ucomiss",
+  "ud2",
+  "unpckhpd",
+  "unpckhps",
+  "unpcklps",
+  "unpcklpd",
+  "verr",
+  "verw",
+  "vmcall",
+  "vmclear",
+  "vmxon",
+  "vmptrld",
+  "vmptrst",
+  "vmresume",
+  "vmxoff",
+  "vmrun",
+  "vmmcall",
+  "vmload",
+  "vmsave",
+  "wait",
+  "wbinvd",
+  "wrmsr",
+  "xadd",
+  "xchg",
+  "xlatb",
+  "xor",
+  "xorpd",
+  "xorps",
+  "db",
+  "invalid",
+};
+
+
+
+static struct ud_itab_entry itab__0f[256] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_00__REG },
+  /* 01 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG },
+  /* 02 */  { UD_Ilar,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ilsl,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Isyscall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iclts,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isysret,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Iinvd,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Iwbinvd,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iud2,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_0D__REG },
+  /* 0E */  { UD_Ifemms,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovups,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovups,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_18__REG },
+  /* 19 */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1D */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1E */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1F */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 20 */  { UD_Imov,         O_R,     O_C,     O_NONE,  P_rexr },
+  /* 21 */  { UD_Imov,         O_R,     O_D,     O_NONE,  P_rexr },
+  /* 22 */  { UD_Imov,         O_C,     O_R,     O_NONE,  P_rexr },
+  /* 23 */  { UD_Imov,         O_D,     O_R,     O_NONE,  P_rexr },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovaps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovaps,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2ps,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntps,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttps2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtps2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomiss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomiss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iwrmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Irdtsc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Irdmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Irdpmc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Isysenter,    O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 35 */  { UD_Isysexit,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Icmovo,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 41 */  { UD_Icmovno,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 42 */  { UD_Icmovb,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 43 */  { UD_Icmovae,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 44 */  { UD_Icmovz,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 45 */  { UD_Icmovnz,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 46 */  { UD_Icmovbe,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 47 */  { UD_Icmova,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 48 */  { UD_Icmovs,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 49 */  { UD_Icmovns,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4A */  { UD_Icmovp,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4B */  { UD_Icmovnp,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4C */  { UD_Icmovl,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4D */  { UD_Icmovge,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4E */  { UD_Icmovle,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4F */  { UD_Icmovg,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 50 */  { UD_Imovmskps,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtps,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iandps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorps,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtps2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtdq2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Imovd,        O_P,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovq,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufw,      O_P,     O_Q,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iemms,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_P,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovq,        O_Q,     O_P,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Ijo,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 81 */  { UD_Ijno,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 82 */  { UD_Ijb,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 83 */  { UD_Ijae,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 84 */  { UD_Ijz,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 85 */  { UD_Ijnz,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 86 */  { UD_Ijbe,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 87 */  { UD_Ija,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 88 */  { UD_Ijs,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 89 */  { UD_Ijns,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8A */  { UD_Ijp,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8B */  { UD_Ijnp,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8C */  { UD_Ijl,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8D */  { UD_Ijge,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8E */  { UD_Ijle,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8F */  { UD_Ijg,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 90 */  { UD_Iseto,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 91 */  { UD_Isetno,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 92 */  { UD_Isetb,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 93 */  { UD_Isetnb,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 94 */  { UD_Isetz,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 95 */  { UD_Isetnz,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 96 */  { UD_Isetbe,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 97 */  { UD_Iseta,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 98 */  { UD_Isets,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 99 */  { UD_Isetns,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9A */  { UD_Isetp,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9B */  { UD_Isetnp,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9C */  { UD_Isetl,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9D */  { UD_Isetge,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9E */  { UD_Isetle,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9F */  { UD_Isetg,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* A0 */  { UD_Ipush,        O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A1 */  { UD_Ipop,         O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A2 */  { UD_Icpuid,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A3 */  { UD_Ibt,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A4 */  { UD_Ishld,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A5 */  { UD_Ishld,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Ipush,        O_GS,    O_NONE,  O_NONE,  P_none },
+  /* A9 */  { UD_Ipop,         O_GS,    O_NONE,  O_NONE,  P_none },
+  /* AA */  { UD_Irsm,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AB */  { UD_Ibts,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AC */  { UD_Ishrd,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AD */  { UD_Ishrd,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG },
+  /* AF */  { UD_Iimul,        O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B0 */  { UD_Icmpxchg,     O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* B1 */  { UD_Icmpxchg,     O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B2 */  { UD_Ilss,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B3 */  { UD_Ibtr,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B4 */  { UD_Ilfs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B5 */  { UD_Ilgs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B6 */  { UD_Imovzx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B7 */  { UD_Imovzx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_BA__REG },
+  /* BB */  { UD_Ibtc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BC */  { UD_Ibsf,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BD */  { UD_Ibsr,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BE */  { UD_Imovsx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BF */  { UD_Imovsx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpps,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Imovnti,      O_M,     O_Gvw,   O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C4 */  { UD_Ipinsrw,      O_P,     O_Ew,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_PR,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C6 */  { UD_Ishufps,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG },
+  /* C8 */  { UD_Ibswap,       O_rAXr8, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* C9 */  { UD_Ibswap,       O_rCXr9, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* CA */  { UD_Ibswap,       O_rDXr10, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CB */  { UD_Ibswap,       O_rBXr11, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CC */  { UD_Ibswap,       O_rSPr12, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CD */  { UD_Ibswap,       O_rBPr13, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CE */  { UD_Ibswap,       O_rSIr14, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CF */  { UD_Ibswap,       O_rDIr15, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Ipsrlw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_PR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipaddusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipaddusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Imovntq,      O_M,     O_P,     O_NONE,  P_none },
+  /* E8 */  { UD_Ipsubsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_00__reg[8] = {
+  /* 00 */  { UD_Isldt,        O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Istr,         O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Illdt,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iltr,         O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iverr,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iverw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg[8] = {
+  /* 00 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD },
+  /* 01 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD },
+  /* 02 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_02__MOD },
+  /* 03 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD },
+  /* 04 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_04__MOD },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod[2] = {
+  /* 00 */  { UD_Isgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmcall,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmresume,    O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxoff,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod[2] = {
+  /* 00 */  { UD_Isidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imonitor,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imwait,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_02__mod[2] = {
+  /* 00 */  { UD_Ilgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod[2] = {
+  /* 00 */  { UD_Ilidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR },
+  /* 06 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor[2] = {
+  /* 00 */  { UD_Ivmrun,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Ivmmcall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor[2] = {
+  /* 00 */  { UD_Ivmload,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Ivmsave,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Istgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor[2] = {
+  /* 00 */  { UD_Iclgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor[2] = {
+  /* 00 */  { UD_Iskinit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvlpga,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_04__mod[2] = {
+  /* 00 */  { UD_Ismsw,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Ilmsw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iinvlpg,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iswapgs,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Irdtscp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_0d__reg[8] = {
+  /* 00 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_18__reg[8] = {
+  /* 00 */  { UD_Iprefetchnta, O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetcht0,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetcht1,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetcht2,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ildmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Istmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iclflush,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ba__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ibt,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ibts,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ibtr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ibtc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Icmpxchg8b,   O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrld,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrst,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Ifabs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_If2xm1,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte[256] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iadd,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadd,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iadd,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iadd,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iadd,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 06 */  { UD_Ipush,        O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 07 */  { UD_Ipop,         O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 08 */  { UD_Ior,          O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 09 */  { UD_Ior,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0A */  { UD_Ior,          O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 0B */  { UD_Ior,          O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0C */  { UD_Ior,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 0D */  { UD_Ior,          O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 0E */  { UD_Ipush,        O_CS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iadc,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Iadc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Iadc,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iadc,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iadc,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 15 */  { UD_Iadc,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 16 */  { UD_Ipush,        O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 17 */  { UD_Ipop,         O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 18 */  { UD_Isbb,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 19 */  { UD_Isbb,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Isbb,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Isbb,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Isbb,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 1D */  { UD_Isbb,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 1E */  { UD_Ipush,        O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 1F */  { UD_Ipop,         O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 20 */  { UD_Iand,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 21 */  { UD_Iand,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 22 */  { UD_Iand,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 23 */  { UD_Iand,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 24 */  { UD_Iand,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 25 */  { UD_Iand,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Idaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 28 */  { UD_Isub,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Isub,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Isub,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Isub,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Isub,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 2D */  { UD_Isub,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Idas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 30 */  { UD_Ixor,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 31 */  { UD_Ixor,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 32 */  { UD_Ixor,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 33 */  { UD_Ixor,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 34 */  { UD_Ixor,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 35 */  { UD_Ixor,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iaaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 38 */  { UD_Icmp,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 39 */  { UD_Icmp,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3A */  { UD_Icmp,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 3B */  { UD_Icmp,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3C */  { UD_Icmp,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 3D */  { UD_Icmp,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iaas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 40 */  { UD_Iinc,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 41 */  { UD_Iinc,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 42 */  { UD_Iinc,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 43 */  { UD_Iinc,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 44 */  { UD_Iinc,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 45 */  { UD_Iinc,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 46 */  { UD_Iinc,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 47 */  { UD_Iinc,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 48 */  { UD_Idec,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 49 */  { UD_Idec,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 4A */  { UD_Idec,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 4B */  { UD_Idec,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 4C */  { UD_Idec,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 4D */  { UD_Idec,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 4E */  { UD_Idec,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 4F */  { UD_Idec,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 50 */  { UD_Ipush,        O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 51 */  { UD_Ipush,        O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 52 */  { UD_Ipush,        O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 53 */  { UD_Ipush,        O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 54 */  { UD_Ipush,        O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 55 */  { UD_Ipush,        O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 56 */  { UD_Ipush,        O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 57 */  { UD_Ipush,        O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 58 */  { UD_Ipop,         O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 59 */  { UD_Ipop,         O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 5A */  { UD_Ipop,         O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5B */  { UD_Ipop,         O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5C */  { UD_Ipop,         O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5D */  { UD_Ipop,         O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5E */  { UD_Ipop,         O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5F */  { UD_Ipop,         O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 60 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_60__OSIZE },
+  /* 61 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_61__OSIZE },
+  /* 62 */  { UD_Ibound,       O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* 63 */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_63__MODE },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Ipush,        O_Iz,    O_NONE,  O_NONE,  P_c1|P_oso },
+  /* 69 */  { UD_Iimul,        O_Gv,    O_Ev,    O_Iz,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipush,        O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* 6B */  { UD_Iimul,        O_Gv,    O_Ev,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinsb,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6D */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6D__OSIZE },
+  /* 6E */  { UD_Ioutsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6F */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6F__OSIZE },
+  /* 70 */  { UD_Ijo,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 71 */  { UD_Ijno,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 72 */  { UD_Ijb,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 73 */  { UD_Ijae,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 74 */  { UD_Ijz,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 75 */  { UD_Ijnz,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 76 */  { UD_Ijbe,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 77 */  { UD_Ija,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Ijs,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 79 */  { UD_Ijns,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7A */  { UD_Ijp,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7B */  { UD_Ijnp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7C */  { UD_Ijl,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7D */  { UD_Ijge,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7E */  { UD_Ijle,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7F */  { UD_Ijg,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 80 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_80__REG },
+  /* 81 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_81__REG },
+  /* 82 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_82__REG },
+  /* 83 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_83__REG },
+  /* 84 */  { UD_Itest,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 85 */  { UD_Itest,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 86 */  { UD_Ixchg,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 87 */  { UD_Ixchg,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 88 */  { UD_Imov,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 89 */  { UD_Imov,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8A */  { UD_Imov,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 8B */  { UD_Imov,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8C */  { UD_Imov,         O_Ev,    O_S,     O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8D */  { UD_Ilea,         O_Gv,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8E */  { UD_Imov,         O_S,     O_Ev,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8F */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_8F__REG },
+  /* 90 */  { UD_Ixchg,        O_rAXr8, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 91 */  { UD_Ixchg,        O_rCXr9, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 92 */  { UD_Ixchg,        O_rDXr10, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 93 */  { UD_Ixchg,        O_rBXr11, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 94 */  { UD_Ixchg,        O_rSPr12, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 95 */  { UD_Ixchg,        O_rBPr13, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 96 */  { UD_Ixchg,        O_rSIr14, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 97 */  { UD_Ixchg,        O_rDIr15, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 98 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_98__OSIZE },
+  /* 99 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_99__OSIZE },
+  /* 9A */  { UD_Icall,        O_Ap,    O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 9B */  { UD_Iwait,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9C */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE },
+  /* 9D */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE },
+  /* 9E */  { UD_Isahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9F */  { UD_Ilahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A0 */  { UD_Imov,         O_AL,    O_Ob,    O_NONE,  P_none },
+  /* A1 */  { UD_Imov,         O_rAX,   O_Ov,    O_NONE,  P_aso|P_oso|P_rexw },
+  /* A2 */  { UD_Imov,         O_Ob,    O_AL,    O_NONE,  P_none },
+  /* A3 */  { UD_Imov,         O_Ov,    O_rAX,   O_NONE,  P_aso|P_oso|P_rexw },
+  /* A4 */  { UD_Imovsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* A5 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A5__OSIZE },
+  /* A6 */  { UD_Icmpsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A7 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A7__OSIZE },
+  /* A8 */  { UD_Itest,        O_AL,    O_Ib,    O_NONE,  P_none },
+  /* A9 */  { UD_Itest,        O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* AA */  { UD_Istosb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AB */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AB__OSIZE },
+  /* AC */  { UD_Ilodsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AD */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AD__OSIZE },
+  /* AE */  { UD_Iscasb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AF__OSIZE },
+  /* B0 */  { UD_Imov,         O_ALr8b, O_Ib,    O_NONE,  P_rexb },
+  /* B1 */  { UD_Imov,         O_CLr9b, O_Ib,    O_NONE,  P_rexb },
+  /* B2 */  { UD_Imov,         O_DLr10b, O_Ib,    O_NONE, P_rexb },
+  /* B3 */  { UD_Imov,         O_BLr11b, O_Ib,    O_NONE, P_rexb },
+  /* B4 */  { UD_Imov,         O_AHr12b, O_Ib,    O_NONE, P_rexb },
+  /* B5 */  { UD_Imov,         O_CHr13b, O_Ib,    O_NONE, P_rexb },
+  /* B6 */  { UD_Imov,         O_DHr14b, O_Ib,    O_NONE, P_rexb },
+  /* B7 */  { UD_Imov,         O_BHr15b, O_Ib,    O_NONE, P_rexb },
+  /* B8 */  { UD_Imov,         O_rAXr8, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* B9 */  { UD_Imov,         O_rCXr9, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* BA */  { UD_Imov,         O_rDXr10, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BB */  { UD_Imov,         O_rBXr11, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BC */  { UD_Imov,         O_rSPr12, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BD */  { UD_Imov,         O_rBPr13, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BE */  { UD_Imov,         O_rSIr14, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BF */  { UD_Imov,         O_rDIr15, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* C0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C0__REG },
+  /* C1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C1__REG },
+  /* C2 */  { UD_Iret,         O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* C3 */  { UD_Iret,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* C4 */  { UD_Iles,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C5 */  { UD_Ilds,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C6__REG },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C7__REG },
+  /* C8 */  { UD_Ienter,       O_Iw,    O_Ib,    O_NONE,  P_def64|P_depM|P_none },
+  /* C9 */  { UD_Ileave,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CA */  { UD_Iretf,        O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* CB */  { UD_Iretf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CC */  { UD_Iint3,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CD */  { UD_Iint,         O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* CE */  { UD_Iinto,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* CF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_CF__OSIZE },
+  /* D0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D0__REG },
+  /* D1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D1__REG },
+  /* D2 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D2__REG },
+  /* D3 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D3__REG },
+  /* D4 */  { UD_Iaam,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D5 */  { UD_Iaad,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D6 */  { UD_Isalc,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D7 */  { UD_Ixlatb,       O_NONE,  O_NONE,  O_NONE,  P_rexw },
+  /* D8 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD },
+  /* D9 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD },
+  /* DA */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD },
+  /* DB */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD },
+  /* DC */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD },
+  /* DD */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD },
+  /* DE */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD },
+  /* DF */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD },
+  /* E0 */  { UD_Iloopnz,      O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E1 */  { UD_Iloope,       O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E2 */  { UD_Iloop,        O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E3 */  { UD_Igrp_asize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_E3__ASIZE },
+  /* E4 */  { UD_Iin,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* E5 */  { UD_Iin,          O_eAX,   O_Ib,    O_NONE,  P_oso },
+  /* E6 */  { UD_Iout,         O_Ib,    O_AL,    O_NONE,  P_none },
+  /* E7 */  { UD_Iout,         O_Ib,    O_eAX,   O_NONE,  P_oso },
+  /* E8 */  { UD_Icall,        O_Jz,    O_NONE,  O_NONE,  P_def64|P_oso },
+  /* E9 */  { UD_Ijmp,         O_Jz,    O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* EA */  { UD_Ijmp,         O_Ap,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* EB */  { UD_Ijmp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* EC */  { UD_Iin,          O_AL,    O_DX,    O_NONE,  P_none },
+  /* ED */  { UD_Iin,          O_eAX,   O_DX,    O_NONE,  P_oso },
+  /* EE */  { UD_Iout,         O_DX,    O_AL,    O_NONE,  P_none },
+  /* EF */  { UD_Iout,         O_DX,    O_eAX,   O_NONE,  P_oso },
+  /* F0 */  { UD_Ilock,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F1 */  { UD_Iint1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F2 */  { UD_Irepne,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F3 */  { UD_Irep,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F4 */  { UD_Ihlt,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F5 */  { UD_Icmc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F6__REG },
+  /* F7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F7__REG },
+  /* F8 */  { UD_Iclc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F9 */  { UD_Istc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FA */  { UD_Icli,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FB */  { UD_Isti,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FC */  { UD_Icld,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FD */  { UD_Istd,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FE__REG },
+  /* FF */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FF__REG },
+};
+
+static struct ud_itab_entry itab__1byte__op_60__osize[3] = {
+  /* 00 */  { UD_Ipusha,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipushad,      O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_61__osize[3] = {
+  /* 00 */  { UD_Ipopa,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipopad,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_63__mode[3] = {
+  /* 00 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 01 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 02 */  { UD_Imovsxd,      O_Gv,    O_Ed,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexx|P_rexr|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_6d__osize[3] = {
+  /* 00 */  { UD_Iinsw,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Iinsd,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_6f__osize[3] = {
+  /* 00 */  { UD_Ioutsw,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Ioutsd,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Ioutsq,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_80__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_81__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_82__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_83__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_8f__reg[8] = {
+  /* 00 */  { UD_Ipop,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_98__osize[3] = {
+  /* 00 */  { UD_Icbw,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icwde,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icdqe,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_99__osize[3] = {
+  /* 00 */  { UD_Icwd,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icdq,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icqo,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipushfq,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipopfq,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_a5__osize[3] = {
+  /* 00 */  { UD_Imovsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Imovsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Imovsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_a7__osize[3] = {
+  /* 00 */  { UD_Icmpsw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icmpsd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icmpsq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ab__osize[3] = {
+  /* 00 */  { UD_Istosw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Istosd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Istosq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ad__osize[3] = {
+  /* 00 */  { UD_Ilodsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Ilodsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Ilodsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AE__MOD__OP_00__REG },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifxsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifxrstor,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_af__osize[3] = {
+  /* 00 */  { UD_Iscasw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iscasd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iscasq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_c0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c6__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_c7__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_cf__osize[3] = {
+  /* 00 */  { UD_Iiretw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iiretd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iiretq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_d0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d2__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d3__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsub,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsub,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsub,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsub,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsub,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsub,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsub,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdiv,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdiv,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdiv,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdiv,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdiv,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdiv,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdiv,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ifst,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifldenv,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifldcw,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifnstenv,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstcw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifld,         O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifld,         O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifld,         O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifld,         O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifld,         O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifld,         O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifld,         O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifld,         O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifnop,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Ifstp1,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp1,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp1,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp1,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp1,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp1,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp1,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp1,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifchs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iftst,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifxam,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifld1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifldl2t,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifldl2e,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifldlpi,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifldlg2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifldln2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifldz,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Ifyl2x,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Ifptan,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Ifpatan,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Ifpxtract,    O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 35 */  { UD_Ifprem1,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Ifdecstp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 37 */  { UD_Ifncstp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 38 */  { UD_Ifprem,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 39 */  { UD_Ifyl2xp1,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3A */  { UD_Ifsqrt,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3B */  { UD_Ifsincos,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3C */  { UD_Ifrndint,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3D */  { UD_Ifscale,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3E */  { UD_Ifsin,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3F */  { UD_Ifcos,        O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovb,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovb,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovb,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovb,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovb,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovb,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovb,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovb,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmove,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmove,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmove,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmove,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmove,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmove,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmove,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmove,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovbe,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovbe,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovbe,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovbe,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovbe,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovbe,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovbe,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovbe,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovu,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovu,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovu,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovu,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovu,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovu,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovu,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovu,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Ifucompp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Ifld,         O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Ifstp,        O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovnb,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovnb,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovnb,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovnb,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovnb,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovnb,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovnb,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovnb,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmovne,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmovne,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmovne,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmovne,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmovne,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmovne,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmovne,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmovne,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovnbe,    O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovnbe,    O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovnbe,    O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovnbe,    O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovnbe,    O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovnbe,    O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovnbe,    O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovnbe,    O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovnu,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovnu,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovnu,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovnu,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovnu,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovnu,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovnu,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovnu,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Ifclex,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifninit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomi,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomi,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomi,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomi,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomi,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomi,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomi,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomi,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomi,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomi,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomi,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomi,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomi,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomi,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomi,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomi,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom2,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom2,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom2,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom2,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom2,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom2,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom2,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom2,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp3,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp3,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp3,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp3,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp3,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp3,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp3,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp3,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsub,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsub,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsub,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsub,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsub,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsub,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsub,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdiv,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdiv,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdiv,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdiv,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdiv,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdiv,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdiv,        O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifst,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifrstor,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ifnsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstsw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffree,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffree,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffree,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffree,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffree,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffree,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffree,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffree,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch4,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch4,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch4,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch4,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch4,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch4,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch4,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch4,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifst,         O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifst,         O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifst,         O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifst,         O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifst,         O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifst,         O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifst,         O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifst,         O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp,        O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp,        O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp,        O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp,        O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp,        O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp,        O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp,        O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp,        O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifucom,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Ifucom,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Ifucom,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifucom,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Ifucom,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifucom,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Ifucom,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 27 */  { UD_Ifucom,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 28 */  { UD_Ifucomp,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomp,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomp,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomp,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomp,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomp,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomp,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomp,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifaddp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifaddp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifaddp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifaddp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifaddp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifaddp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifaddp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifaddp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmulp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmulp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmulp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmulp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmulp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmulp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmulp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmulp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcomp5,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcomp5,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcomp5,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcomp5,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcomp5,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcomp5,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcomp5,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcomp5,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Ifcompp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Ifsubrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifbld,        O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifild,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifbstp,       O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifistp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffreep,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffreep,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffreep,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffreep,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffreep,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffreep,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffreep,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffreep,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch7,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch7,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch7,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch7,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch7,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch7,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch7,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch7,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifstp8,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifstp8,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifstp8,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifstp8,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifstp8,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifstp8,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifstp8,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifstp8,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp9,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp9,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp9,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp9,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp9,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp9,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp9,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp9,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifnstsw,      O_AX,    O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomip,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomip,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomip,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomip,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomip,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomip,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomip,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomip,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomip,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomip,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomip,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomip,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomip,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomip,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomip,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomip,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_e3__asize[3] = {
+  /* 00 */  { UD_Ijcxz,        O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 01 */  { UD_Ijecxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 02 */  { UD_Ijrcxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+};
+
+static struct ud_itab_entry itab__1byte__op_f6__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_f7__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_fe__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ff__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Icall,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Icall,        O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ijmp,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ijmp,         O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ipush,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__3dnow[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 59 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovupd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovupd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovapd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovapd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2pd,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntpd,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttpd2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtpd2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomisd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomisd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Imovmskpd,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iandpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorpd,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtpd2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtps2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Ipunpcklqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6D */  { UD_Ipunpckhqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6E */  { UD_Imovd,        O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovqa,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_V,     O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqa,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmppd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Ipinsrw,      O_V,     O_Ew,    O_Ib,    P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_VR,    O_Ib,    P_aso|P_rexr|P_rexb },
+  /* C6 */  { UD_Ishufpd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Ipsrlw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Imovq,        O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_VR,    O_NONE,  P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Icvttpd2dq,   O_V,     O_W,     O_NONE,  P_none },
+  /* E7 */  { UD_Imovntdq,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E8 */  { UD_Ipsubsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Ipsrldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Ipslldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmclear,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_ssef2__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovsd,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovddup,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2sd,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttsd2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtsd2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtsd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtsd2ss,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Isubsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Ipshuflw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpsd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovdq2q,     O_P,     O_VR,    O_NONE,  P_aso|P_rexb },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtpd2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Ilddqu,       O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovss,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovsldup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Imovshdup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2ss,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttss2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtss2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtss2sd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvttps2dq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Imovdqu,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufhw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovq,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqu,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpss,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovq2dq,     O_V,     O_PR,    O_NONE,  P_aso },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtdq2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxon,       O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+/* the order of this table matches enum ud_itab_index */
+struct ud_itab_entry * ud_itab_list[] = {
+  itab__0f,
+  itab__0f__op_00__reg,
+  itab__0f__op_01__reg,
+  itab__0f__op_01__reg__op_00__mod,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_01__mod,
+  itab__0f__op_01__reg__op_01__mod__op_01__rm,
+  itab__0f__op_01__reg__op_02__mod,
+  itab__0f__op_01__reg__op_03__mod,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor,
+  itab__0f__op_01__reg__op_04__mod,
+  itab__0f__op_01__reg__op_06__mod,
+  itab__0f__op_01__reg__op_07__mod,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_0d__reg,
+  itab__0f__op_18__reg,
+  itab__0f__op_71__reg,
+  itab__0f__op_72__reg,
+  itab__0f__op_73__reg,
+  itab__0f__op_ae__reg,
+  itab__0f__op_ae__reg__op_05__mod,
+  itab__0f__op_ae__reg__op_05__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_06__mod,
+  itab__0f__op_ae__reg__op_06__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_07__mod,
+  itab__0f__op_ae__reg__op_07__mod__op_01__rm,
+  itab__0f__op_ba__reg,
+  itab__0f__op_c7__reg,
+  itab__0f__op_c7__reg__op_00__vendor,
+  itab__0f__op_c7__reg__op_07__vendor,
+  itab__0f__op_d9__mod,
+  itab__0f__op_d9__mod__op_01__x87,
+  itab__1byte,
+  itab__1byte__op_60__osize,
+  itab__1byte__op_61__osize,
+  itab__1byte__op_63__mode,
+  itab__1byte__op_6d__osize,
+  itab__1byte__op_6f__osize,
+  itab__1byte__op_80__reg,
+  itab__1byte__op_81__reg,
+  itab__1byte__op_82__reg,
+  itab__1byte__op_83__reg,
+  itab__1byte__op_8f__reg,
+  itab__1byte__op_98__osize,
+  itab__1byte__op_99__osize,
+  itab__1byte__op_9c__mode,
+  itab__1byte__op_9c__mode__op_00__osize,
+  itab__1byte__op_9c__mode__op_01__osize,
+  itab__1byte__op_9d__mode,
+  itab__1byte__op_9d__mode__op_00__osize,
+  itab__1byte__op_9d__mode__op_01__osize,
+  itab__1byte__op_a5__osize,
+  itab__1byte__op_a7__osize,
+  itab__1byte__op_ab__osize,
+  itab__1byte__op_ad__osize,
+  itab__1byte__op_ae__mod,
+  itab__1byte__op_ae__mod__op_00__reg,
+  itab__1byte__op_af__osize,
+  itab__1byte__op_c0__reg,
+  itab__1byte__op_c1__reg,
+  itab__1byte__op_c6__reg,
+  itab__1byte__op_c7__reg,
+  itab__1byte__op_cf__osize,
+  itab__1byte__op_d0__reg,
+  itab__1byte__op_d1__reg,
+  itab__1byte__op_d2__reg,
+  itab__1byte__op_d3__reg,
+  itab__1byte__op_d8__mod,
+  itab__1byte__op_d8__mod__op_00__reg,
+  itab__1byte__op_d8__mod__op_01__x87,
+  itab__1byte__op_d9__mod,
+  itab__1byte__op_d9__mod__op_00__reg,
+  itab__1byte__op_d9__mod__op_01__x87,
+  itab__1byte__op_da__mod,
+  itab__1byte__op_da__mod__op_00__reg,
+  itab__1byte__op_da__mod__op_01__x87,
+  itab__1byte__op_db__mod,
+  itab__1byte__op_db__mod__op_00__reg,
+  itab__1byte__op_db__mod__op_01__x87,
+  itab__1byte__op_dc__mod,
+  itab__1byte__op_dc__mod__op_00__reg,
+  itab__1byte__op_dc__mod__op_01__x87,
+  itab__1byte__op_dd__mod,
+  itab__1byte__op_dd__mod__op_00__reg,
+  itab__1byte__op_dd__mod__op_01__x87,
+  itab__1byte__op_de__mod,
+  itab__1byte__op_de__mod__op_00__reg,
+  itab__1byte__op_de__mod__op_01__x87,
+  itab__1byte__op_df__mod,
+  itab__1byte__op_df__mod__op_00__reg,
+  itab__1byte__op_df__mod__op_01__x87,
+  itab__1byte__op_e3__asize,
+  itab__1byte__op_f6__reg,
+  itab__1byte__op_f7__reg,
+  itab__1byte__op_fe__reg,
+  itab__1byte__op_ff__reg,
+  itab__3dnow,
+  itab__pfx_sse66__0f,
+  itab__pfx_sse66__0f__op_71__reg,
+  itab__pfx_sse66__0f__op_72__reg,
+  itab__pfx_sse66__0f__op_73__reg,
+  itab__pfx_sse66__0f__op_c7__reg,
+  itab__pfx_sse66__0f__op_c7__reg__op_00__vendor,
+  itab__pfx_ssef2__0f,
+  itab__pfx_ssef3__0f,
+  itab__pfx_ssef3__0f__op_c7__reg,
+  itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor,
+};
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/itab.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,719 @@
+
+/* itab.h -- auto generated by opgen.py, do not edit. */
+
+#ifndef UD_ITAB_H
+#define UD_ITAB_H
+
+
+
+enum ud_itab_vendor_index {
+  ITAB__VENDOR_INDX__AMD,
+  ITAB__VENDOR_INDX__INTEL,
+};
+
+
+enum ud_itab_mode_index {
+  ITAB__MODE_INDX__16,
+  ITAB__MODE_INDX__32,
+  ITAB__MODE_INDX__64
+};
+
+
+enum ud_itab_mod_index {
+  ITAB__MOD_INDX__NOT_11,
+  ITAB__MOD_INDX__11
+};
+
+
+enum ud_itab_index {
+  ITAB__0F,
+  ITAB__0F__OP_00__REG,
+  ITAB__0F__OP_01__REG,
+  ITAB__0F__OP_01__REG__OP_00__MOD,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_01__MOD,
+  ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_02__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR,
+  ITAB__0F__OP_01__REG__OP_04__MOD,
+  ITAB__0F__OP_01__REG__OP_06__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_0D__REG,
+  ITAB__0F__OP_18__REG,
+  ITAB__0F__OP_71__REG,
+  ITAB__0F__OP_72__REG,
+  ITAB__0F__OP_73__REG,
+  ITAB__0F__OP_AE__REG,
+  ITAB__0F__OP_AE__REG__OP_05__MOD,
+  ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_06__MOD,
+  ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_07__MOD,
+  ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_BA__REG,
+  ITAB__0F__OP_C7__REG,
+  ITAB__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__0F__OP_C7__REG__OP_07__VENDOR,
+  ITAB__0F__OP_D9__MOD,
+  ITAB__0F__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE,
+  ITAB__1BYTE__OP_60__OSIZE,
+  ITAB__1BYTE__OP_61__OSIZE,
+  ITAB__1BYTE__OP_63__MODE,
+  ITAB__1BYTE__OP_6D__OSIZE,
+  ITAB__1BYTE__OP_6F__OSIZE,
+  ITAB__1BYTE__OP_80__REG,
+  ITAB__1BYTE__OP_81__REG,
+  ITAB__1BYTE__OP_82__REG,
+  ITAB__1BYTE__OP_83__REG,
+  ITAB__1BYTE__OP_8F__REG,
+  ITAB__1BYTE__OP_98__OSIZE,
+  ITAB__1BYTE__OP_99__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE,
+  ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE,
+  ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_A5__OSIZE,
+  ITAB__1BYTE__OP_A7__OSIZE,
+  ITAB__1BYTE__OP_AB__OSIZE,
+  ITAB__1BYTE__OP_AD__OSIZE,
+  ITAB__1BYTE__OP_AE__MOD,
+  ITAB__1BYTE__OP_AE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_AF__OSIZE,
+  ITAB__1BYTE__OP_C0__REG,
+  ITAB__1BYTE__OP_C1__REG,
+  ITAB__1BYTE__OP_C6__REG,
+  ITAB__1BYTE__OP_C7__REG,
+  ITAB__1BYTE__OP_CF__OSIZE,
+  ITAB__1BYTE__OP_D0__REG,
+  ITAB__1BYTE__OP_D1__REG,
+  ITAB__1BYTE__OP_D2__REG,
+  ITAB__1BYTE__OP_D3__REG,
+  ITAB__1BYTE__OP_D8__MOD,
+  ITAB__1BYTE__OP_D8__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D8__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_D9__MOD,
+  ITAB__1BYTE__OP_D9__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DA__MOD,
+  ITAB__1BYTE__OP_DA__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DA__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DB__MOD,
+  ITAB__1BYTE__OP_DB__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DB__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DC__MOD,
+  ITAB__1BYTE__OP_DC__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DC__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DD__MOD,
+  ITAB__1BYTE__OP_DD__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DD__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DE__MOD,
+  ITAB__1BYTE__OP_DE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DE__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DF__MOD,
+  ITAB__1BYTE__OP_DF__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DF__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_E3__ASIZE,
+  ITAB__1BYTE__OP_F6__REG,
+  ITAB__1BYTE__OP_F7__REG,
+  ITAB__1BYTE__OP_FE__REG,
+  ITAB__1BYTE__OP_FF__REG,
+  ITAB__3DNOW,
+  ITAB__PFX_SSE66__0F,
+  ITAB__PFX_SSE66__0F__OP_71__REG,
+  ITAB__PFX_SSE66__0F__OP_72__REG,
+  ITAB__PFX_SSE66__0F__OP_73__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__PFX_SSEF2__0F,
+  ITAB__PFX_SSEF3__0F,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR,
+};
+
+
+enum ud_mnemonic_code {
+  UD_I3dnow,
+  UD_Iaaa,
+  UD_Iaad,
+  UD_Iaam,
+  UD_Iaas,
+  UD_Iadc,
+  UD_Iadd,
+  UD_Iaddpd,
+  UD_Iaddps,
+  UD_Iaddsd,
+  UD_Iaddss,
+  UD_Iaddsubpd,
+  UD_Iaddsubps,
+  UD_Iand,
+  UD_Iandpd,
+  UD_Iandps,
+  UD_Iandnpd,
+  UD_Iandnps,
+  UD_Iarpl,
+  UD_Imovsxd,
+  UD_Ibound,
+  UD_Ibsf,
+  UD_Ibsr,
+  UD_Ibswap,
+  UD_Ibt,
+  UD_Ibtc,
+  UD_Ibtr,
+  UD_Ibts,
+  UD_Icall,
+  UD_Icbw,
+  UD_Icwde,
+  UD_Icdqe,
+  UD_Iclc,
+  UD_Icld,
+  UD_Iclflush,
+  UD_Iclgi,
+  UD_Icli,
+  UD_Iclts,
+  UD_Icmc,
+  UD_Icmovo,
+  UD_Icmovno,
+  UD_Icmovb,
+  UD_Icmovae,
+  UD_Icmovz,
+  UD_Icmovnz,
+  UD_Icmovbe,
+  UD_Icmova,
+  UD_Icmovs,
+  UD_Icmovns,
+  UD_Icmovp,
+  UD_Icmovnp,
+  UD_Icmovl,
+  UD_Icmovge,
+  UD_Icmovle,
+  UD_Icmovg,
+  UD_Icmp,
+  UD_Icmppd,
+  UD_Icmpps,
+  UD_Icmpsb,
+  UD_Icmpsw,
+  UD_Icmpsd,
+  UD_Icmpsq,
+  UD_Icmpss,
+  UD_Icmpxchg,
+  UD_Icmpxchg8b,
+  UD_Icomisd,
+  UD_Icomiss,
+  UD_Icpuid,
+  UD_Icvtdq2pd,
+  UD_Icvtdq2ps,
+  UD_Icvtpd2dq,
+  UD_Icvtpd2pi,
+  UD_Icvtpd2ps,
+  UD_Icvtpi2ps,
+  UD_Icvtpi2pd,
+  UD_Icvtps2dq,
+  UD_Icvtps2pi,
+  UD_Icvtps2pd,
+  UD_Icvtsd2si,
+  UD_Icvtsd2ss,
+  UD_Icvtsi2ss,
+  UD_Icvtss2si,
+  UD_Icvtss2sd,
+  UD_Icvttpd2pi,
+  UD_Icvttpd2dq,
+  UD_Icvttps2dq,
+  UD_Icvttps2pi,
+  UD_Icvttsd2si,
+  UD_Icvtsi2sd,
+  UD_Icvttss2si,
+  UD_Icwd,
+  UD_Icdq,
+  UD_Icqo,
+  UD_Idaa,
+  UD_Idas,
+  UD_Idec,
+  UD_Idiv,
+  UD_Idivpd,
+  UD_Idivps,
+  UD_Idivsd,
+  UD_Idivss,
+  UD_Iemms,
+  UD_Ienter,
+  UD_If2xm1,
+  UD_Ifabs,
+  UD_Ifadd,
+  UD_Ifaddp,
+  UD_Ifbld,
+  UD_Ifbstp,
+  UD_Ifchs,
+  UD_Ifclex,
+  UD_Ifcmovb,
+  UD_Ifcmove,
+  UD_Ifcmovbe,
+  UD_Ifcmovu,
+  UD_Ifcmovnb,
+  UD_Ifcmovne,
+  UD_Ifcmovnbe,
+  UD_Ifcmovnu,
+  UD_Ifucomi,
+  UD_Ifcom,
+  UD_Ifcom2,
+  UD_Ifcomp3,
+  UD_Ifcomi,
+  UD_Ifucomip,
+  UD_Ifcomip,
+  UD_Ifcomp,
+  UD_Ifcomp5,
+  UD_Ifcompp,
+  UD_Ifcos,
+  UD_Ifdecstp,
+  UD_Ifdiv,
+  UD_Ifdivp,
+  UD_Ifdivr,
+  UD_Ifdivrp,
+  UD_Ifemms,
+  UD_Iffree,
+  UD_Iffreep,
+  UD_Ificom,
+  UD_Ificomp,
+  UD_Ifild,
+  UD_Ifncstp,
+  UD_Ifninit,
+  UD_Ifiadd,
+  UD_Ifidivr,
+  UD_Ifidiv,
+  UD_Ifisub,
+  UD_Ifisubr,
+  UD_Ifist,
+  UD_Ifistp,
+  UD_Ifisttp,
+  UD_Ifld,
+  UD_Ifld1,
+  UD_Ifldl2t,
+  UD_Ifldl2e,
+  UD_Ifldlpi,
+  UD_Ifldlg2,
+  UD_Ifldln2,
+  UD_Ifldz,
+  UD_Ifldcw,
+  UD_Ifldenv,
+  UD_Ifmul,
+  UD_Ifmulp,
+  UD_Ifimul,
+  UD_Ifnop,
+  UD_Ifpatan,
+  UD_Ifprem,
+  UD_Ifprem1,
+  UD_Ifptan,
+  UD_Ifrndint,
+  UD_Ifrstor,
+  UD_Ifnsave,
+  UD_Ifscale,
+  UD_Ifsin,
+  UD_Ifsincos,
+  UD_Ifsqrt,
+  UD_Ifstp,
+  UD_Ifstp1,
+  UD_Ifstp8,
+  UD_Ifstp9,
+  UD_Ifst,
+  UD_Ifnstcw,
+  UD_Ifnstenv,
+  UD_Ifnstsw,
+  UD_Ifsub,
+  UD_Ifsubp,
+  UD_Ifsubr,
+  UD_Ifsubrp,
+  UD_Iftst,
+  UD_Ifucom,
+  UD_Ifucomp,
+  UD_Ifucompp,
+  UD_Ifxam,
+  UD_Ifxch,
+  UD_Ifxch4,
+  UD_Ifxch7,
+  UD_Ifxrstor,
+  UD_Ifxsave,
+  UD_Ifpxtract,
+  UD_Ifyl2x,
+  UD_Ifyl2xp1,
+  UD_Ihaddpd,
+  UD_Ihaddps,
+  UD_Ihlt,
+  UD_Ihsubpd,
+  UD_Ihsubps,
+  UD_Iidiv,
+  UD_Iin,
+  UD_Iimul,
+  UD_Iinc,
+  UD_Iinsb,
+  UD_Iinsw,
+  UD_Iinsd,
+  UD_Iint1,
+  UD_Iint3,
+  UD_Iint,
+  UD_Iinto,
+  UD_Iinvd,
+  UD_Iinvlpg,
+  UD_Iinvlpga,
+  UD_Iiretw,
+  UD_Iiretd,
+  UD_Iiretq,
+  UD_Ijo,
+  UD_Ijno,
+  UD_Ijb,
+  UD_Ijae,
+  UD_Ijz,
+  UD_Ijnz,
+  UD_Ijbe,
+  UD_Ija,
+  UD_Ijs,
+  UD_Ijns,
+  UD_Ijp,
+  UD_Ijnp,
+  UD_Ijl,
+  UD_Ijge,
+  UD_Ijle,
+  UD_Ijg,
+  UD_Ijcxz,
+  UD_Ijecxz,
+  UD_Ijrcxz,
+  UD_Ijmp,
+  UD_Ilahf,
+  UD_Ilar,
+  UD_Ilddqu,
+  UD_Ildmxcsr,
+  UD_Ilds,
+  UD_Ilea,
+  UD_Iles,
+  UD_Ilfs,
+  UD_Ilgs,
+  UD_Ilidt,
+  UD_Ilss,
+  UD_Ileave,
+  UD_Ilfence,
+  UD_Ilgdt,
+  UD_Illdt,
+  UD_Ilmsw,
+  UD_Ilock,
+  UD_Ilodsb,
+  UD_Ilodsw,
+  UD_Ilodsd,
+  UD_Ilodsq,
+  UD_Iloopnz,
+  UD_Iloope,
+  UD_Iloop,
+  UD_Ilsl,
+  UD_Iltr,
+  UD_Imaskmovq,
+  UD_Imaxpd,
+  UD_Imaxps,
+  UD_Imaxsd,
+  UD_Imaxss,
+  UD_Imfence,
+  UD_Iminpd,
+  UD_Iminps,
+  UD_Iminsd,
+  UD_Iminss,
+  UD_Imonitor,
+  UD_Imov,
+  UD_Imovapd,
+  UD_Imovaps,
+  UD_Imovd,
+  UD_Imovddup,
+  UD_Imovdqa,
+  UD_Imovdqu,
+  UD_Imovdq2q,
+  UD_Imovhpd,
+  UD_Imovhps,
+  UD_Imovlhps,
+  UD_Imovlpd,
+  UD_Imovlps,
+  UD_Imovhlps,
+  UD_Imovmskpd,
+  UD_Imovmskps,
+  UD_Imovntdq,
+  UD_Imovnti,
+  UD_Imovntpd,
+  UD_Imovntps,
+  UD_Imovntq,
+  UD_Imovq,
+  UD_Imovqa,
+  UD_Imovq2dq,
+  UD_Imovsb,
+  UD_Imovsw,
+  UD_Imovsd,
+  UD_Imovsq,
+  UD_Imovsldup,
+  UD_Imovshdup,
+  UD_Imovss,
+  UD_Imovsx,
+  UD_Imovupd,
+  UD_Imovups,
+  UD_Imovzx,
+  UD_Imul,
+  UD_Imulpd,
+  UD_Imulps,
+  UD_Imulsd,
+  UD_Imulss,
+  UD_Imwait,
+  UD_Ineg,
+  UD_Inop,
+  UD_Inot,
+  UD_Ior,
+  UD_Iorpd,
+  UD_Iorps,
+  UD_Iout,
+  UD_Ioutsb,
+  UD_Ioutsw,
+  UD_Ioutsd,
+  UD_Ioutsq,
+  UD_Ipacksswb,
+  UD_Ipackssdw,
+  UD_Ipackuswb,
+  UD_Ipaddb,
+  UD_Ipaddw,
+  UD_Ipaddq,
+  UD_Ipaddsb,
+  UD_Ipaddsw,
+  UD_Ipaddusb,
+  UD_Ipaddusw,
+  UD_Ipand,
+  UD_Ipandn,
+  UD_Ipause,
+  UD_Ipavgb,
+  UD_Ipavgw,
+  UD_Ipcmpeqb,
+  UD_Ipcmpeqw,
+  UD_Ipcmpeqd,
+  UD_Ipcmpgtb,
+  UD_Ipcmpgtw,
+  UD_Ipcmpgtd,
+  UD_Ipextrw,
+  UD_Ipinsrw,
+  UD_Ipmaddwd,
+  UD_Ipmaxsw,
+  UD_Ipmaxub,
+  UD_Ipminsw,
+  UD_Ipminub,
+  UD_Ipmovmskb,
+  UD_Ipmulhuw,
+  UD_Ipmulhw,
+  UD_Ipmullw,
+  UD_Ipmuludq,
+  UD_Ipop,
+  UD_Ipopa,
+  UD_Ipopad,
+  UD_Ipopfw,
+  UD_Ipopfd,
+  UD_Ipopfq,
+  UD_Ipor,
+  UD_Iprefetch,
+  UD_Iprefetchnta,
+  UD_Iprefetcht0,
+  UD_Iprefetcht1,
+  UD_Iprefetcht2,
+  UD_Ipsadbw,
+  UD_Ipshufd,
+  UD_Ipshufhw,
+  UD_Ipshuflw,
+  UD_Ipshufw,
+  UD_Ipslldq,
+  UD_Ipsllw,
+  UD_Ipslld,
+  UD_Ipsllq,
+  UD_Ipsraw,
+  UD_Ipsrad,
+  UD_Ipsrlw,
+  UD_Ipsrld,
+  UD_Ipsrlq,
+  UD_Ipsrldq,
+  UD_Ipsubb,
+  UD_Ipsubw,
+  UD_Ipsubd,
+  UD_Ipsubq,
+  UD_Ipsubsb,
+  UD_Ipsubsw,
+  UD_Ipsubusb,
+  UD_Ipsubusw,
+  UD_Ipunpckhbw,
+  UD_Ipunpckhwd,
+  UD_Ipunpckhdq,
+  UD_Ipunpckhqdq,
+  UD_Ipunpcklbw,
+  UD_Ipunpcklwd,
+  UD_Ipunpckldq,
+  UD_Ipunpcklqdq,
+  UD_Ipi2fw,
+  UD_Ipi2fd,
+  UD_Ipf2iw,
+  UD_Ipf2id,
+  UD_Ipfnacc,
+  UD_Ipfpnacc,
+  UD_Ipfcmpge,
+  UD_Ipfmin,
+  UD_Ipfrcp,
+  UD_Ipfrsqrt,
+  UD_Ipfsub,
+  UD_Ipfadd,
+  UD_Ipfcmpgt,
+  UD_Ipfmax,
+  UD_Ipfrcpit1,
+  UD_Ipfrspit1,
+  UD_Ipfsubr,
+  UD_Ipfacc,
+  UD_Ipfcmpeq,
+  UD_Ipfmul,
+  UD_Ipfrcpit2,
+  UD_Ipmulhrw,
+  UD_Ipswapd,
+  UD_Ipavgusb,
+  UD_Ipush,
+  UD_Ipusha,
+  UD_Ipushad,
+  UD_Ipushfw,
+  UD_Ipushfd,
+  UD_Ipushfq,
+  UD_Ipxor,
+  UD_Ircl,
+  UD_Ircr,
+  UD_Irol,
+  UD_Iror,
+  UD_Ircpps,
+  UD_Ircpss,
+  UD_Irdmsr,
+  UD_Irdpmc,
+  UD_Irdtsc,
+  UD_Irdtscp,
+  UD_Irepne,
+  UD_Irep,
+  UD_Iret,
+  UD_Iretf,
+  UD_Irsm,
+  UD_Irsqrtps,
+  UD_Irsqrtss,
+  UD_Isahf,
+  UD_Isal,
+  UD_Isalc,
+  UD_Isar,
+  UD_Ishl,
+  UD_Ishr,
+  UD_Isbb,
+  UD_Iscasb,
+  UD_Iscasw,
+  UD_Iscasd,
+  UD_Iscasq,
+  UD_Iseto,
+  UD_Isetno,
+  UD_Isetb,
+  UD_Isetnb,
+  UD_Isetz,
+  UD_Isetnz,
+  UD_Isetbe,
+  UD_Iseta,
+  UD_Isets,
+  UD_Isetns,
+  UD_Isetp,
+  UD_Isetnp,
+  UD_Isetl,
+  UD_Isetge,
+  UD_Isetle,
+  UD_Isetg,
+  UD_Isfence,
+  UD_Isgdt,
+  UD_Ishld,
+  UD_Ishrd,
+  UD_Ishufpd,
+  UD_Ishufps,
+  UD_Isidt,
+  UD_Isldt,
+  UD_Ismsw,
+  UD_Isqrtps,
+  UD_Isqrtpd,
+  UD_Isqrtsd,
+  UD_Isqrtss,
+  UD_Istc,
+  UD_Istd,
+  UD_Istgi,
+  UD_Isti,
+  UD_Iskinit,
+  UD_Istmxcsr,
+  UD_Istosb,
+  UD_Istosw,
+  UD_Istosd,
+  UD_Istosq,
+  UD_Istr,
+  UD_Isub,
+  UD_Isubpd,
+  UD_Isubps,
+  UD_Isubsd,
+  UD_Isubss,
+  UD_Iswapgs,
+  UD_Isyscall,
+  UD_Isysenter,
+  UD_Isysexit,
+  UD_Isysret,
+  UD_Itest,
+  UD_Iucomisd,
+  UD_Iucomiss,
+  UD_Iud2,
+  UD_Iunpckhpd,
+  UD_Iunpckhps,
+  UD_Iunpcklps,
+  UD_Iunpcklpd,
+  UD_Iverr,
+  UD_Iverw,
+  UD_Ivmcall,
+  UD_Ivmclear,
+  UD_Ivmxon,
+  UD_Ivmptrld,
+  UD_Ivmptrst,
+  UD_Ivmresume,
+  UD_Ivmxoff,
+  UD_Ivmrun,
+  UD_Ivmmcall,
+  UD_Ivmload,
+  UD_Ivmsave,
+  UD_Iwait,
+  UD_Iwbinvd,
+  UD_Iwrmsr,
+  UD_Ixadd,
+  UD_Ixchg,
+  UD_Ixlatb,
+  UD_Ixor,
+  UD_Ixorpd,
+  UD_Ixorps,
+  UD_Idb,
+  UD_Iinvalid,
+  UD_Id3vil,
+  UD_Ina,
+  UD_Igrp_reg,
+  UD_Igrp_rm,
+  UD_Igrp_vendor,
+  UD_Igrp_x87,
+  UD_Igrp_mode,
+  UD_Igrp_osize,
+  UD_Igrp_asize,
+  UD_Igrp_mod,
+  UD_Inone,
+};
+
+
+
+extern const char* ud_mnemonics_str[];;
+extern struct ud_itab_entry* ud_itab_list[];
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/kdb_dis.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include <xen/compile.h>                /* for XEN_SUBVERSION */
+#include "../../include/kdbinc.h"
+#include "extern.h"
+
+static void (*dis_syntax)(ud_t*) = UD_SYN_ATT; /* default dis-assembly syntax */
+
+static struct {                         /* info for kdb_read_byte_for_ud() */
+    kdbva_t kud_instr_addr;
+    domid_t kud_domid;
+} kdb_ud_rd_info;
+
+/* called via function ptr by ud when disassembling. 
+ * kdb info passed via kdb_ud_rd_info{} 
+ */
+static int
+kdb_read_byte_for_ud(struct ud *udp)
+{
+    kdbbyt_t bytebuf;
+    domid_t domid = kdb_ud_rd_info.kud_domid;
+    kdbva_t addr = kdb_ud_rd_info.kud_instr_addr;
+
+    if (kdb_read_mem(addr, &bytebuf, 1, domid) == 1) {
+        kdb_ud_rd_info.kud_instr_addr++;
+        KDBGP1("udrd:addr:%lx domid:%d byt:%x\n", addr, domid, bytebuf);
+        return bytebuf;
+    }
+    KDBGP1("udrd:addr:%lx domid:%d err\n", addr, domid);
+    return UD_EOI;
+}
+
+/* 
+ * given a domid, convert addr to symbol and print it 
+ * Eg: ffff828c801235e2: idle_loop+52                  jmp  idle_loop+55
+ *    Called twice here for idle_loop. In first case, nl is null, 
+ *    in the second case nl == '\n'
+ */
+void
+kdb_prnt_addr2sym(domid_t domid, kdbva_t addr, char *nl)
+{
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1], pbuf[150], prefix[8];
+    char *p = buf;
+
+    prefix[0]='\0';
+    if (domid != DOMID_IDLE) {
+        snprintf(prefix, 8, "%x:", domid);
+        p = kdb_guest_addr2sym(addr, domid, &offs);
+    } else
+        symbols_lookup(addr, &sz, &offs, buf);
+
+    snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
+    if (*nl != '\n')
+        kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
+    else
+        kdbp("%s%s", pbuf, nl);
+
+}
+
+static int
+kdb_jump_instr(enum ud_mnemonic_code mnemonic)
+{
+    return (mnemonic >= UD_Ijo && mnemonic <= UD_Ijmp);
+}
+
+/*
+ * print one instr: function so that we can print offsets of jmp etc.. as
+ *  symbol+offset instead of just address
+ */
+static void
+kdb_print_one_instr(struct ud *udp, domid_t domid)
+{
+    signed long val = 0;
+    ud_type_t type = udp->operand[0].type;
+
+    if ((udp->mnemonic == UD_Icall || kdb_jump_instr(udp->mnemonic)) &&
+        type == UD_OP_JIMM) {
+        
+        int sz = udp->operand[0].size;
+        char *p, ibuf[40], *q = ibuf;
+        kdbva_t addr;
+
+        if (sz == 8) val = udp->operand[0].lval.sbyte;
+        else if (sz == 16) val = udp->operand[0].lval.sword;
+        else if (sz == 32) val = udp->operand[0].lval.sdword;
+        else if (sz == 64) val = udp->operand[0].lval.sqword;
+        else kdbp("kdb_print_one_instr: Inval sz:z%d\n", sz);
+
+        addr = udp->pc + val;
+        for(p=ud_insn_asm(udp); (*q=*p) && *p!=' '; p++,q++);
+        *q='\0';
+        kdbp(" %-4s ", ibuf);    /* space before for long func names */
+        kdb_prnt_addr2sym(domid, addr, "\n");
+    } else
+        kdbp(" %-24s\n", ud_insn_asm(udp));
+#if 0
+    kdbp("mnemonic:z%d ", udp->mnemonic);
+    if (type == UD_OP_CONST) kdbp("type is const\n");
+    else if (type == UD_OP_JIMM) kdbp("type is JIMM\n");
+    else if (type == UD_OP_IMM) kdbp("type is IMM\n");
+    else if (type == UD_OP_PTR) kdbp("type is PTR\n");
+#endif
+}
+
+static void
+kdb_setup_ud(struct ud *udp, kdbva_t addr, domid_t domid)
+{
+    int bitness = kdb_guest_bitness(domid);
+    uint vendor = (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ?
+                                           UD_VENDOR_AMD : UD_VENDOR_INTEL;
+
+    KDBGP1("setup_ud:domid:%d bitness:%d addr:%lx\n", domid, bitness, addr);
+    ud_init(udp);
+    ud_set_mode(udp, kdb_guest_bitness(domid));
+    ud_set_syntax(udp, dis_syntax); 
+    ud_set_vendor(udp, vendor);           /* HVM: vmx/svm different instrs*/
+    ud_set_pc(udp, addr);                 /* for numbers printed on left */
+    ud_set_input_hook(udp, kdb_read_byte_for_ud);
+    kdb_ud_rd_info.kud_instr_addr = addr;
+    kdb_ud_rd_info.kud_domid = domid;
+}
+
+/*
+ * given an addr, print given number of instructions.
+ * Returns: address of next instruction in the stream
+ */
+kdbva_t
+kdb_print_instr(kdbva_t addr, long num, domid_t domid)
+{
+    struct ud ud_s;
+
+    KDBGP1("print_instr:addr:0x%lx num:%ld domid:%x\n", addr, num, domid);
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    while(num--) {
+        if (ud_disassemble(&ud_s)) {
+            uint64_t pc = ud_insn_off(&ud_s);
+            /* kdbp("%08x: ",(int)pc); */
+            kdbp("%016lx: ", pc);
+            kdb_prnt_addr2sym(domid, pc, "");
+            kdb_print_one_instr(&ud_s, domid);
+        } else
+            kdbp("KDB:Couldn't disassemble PC:0x%lx\n", addr);
+            /* for stack reads, don't always display error */
+    }
+    KDBGP1("print_instr:kudaddr:0x%lx\n", kdb_ud_rd_info.kud_instr_addr);
+    return kdb_ud_rd_info.kud_instr_addr;
+}
+
+void
+kdb_display_pc(struct cpu_user_regs *regs)
+{   
+    domid_t domid;
+    struct cpu_user_regs regs1 = *regs;
+    domid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+
+    regs1.KDBIP = regs->KDBIP;
+    kdb_print_instr(regs1.KDBIP, 1, domid);
+}
+
+/* check if the instr at the addr is call instruction
+ * RETURNS: size of the instr if it's a call instr, else 0
+ */
+int
+kdb_check_call_instr(domid_t domid, kdbva_t addr)
+{
+    struct ud ud_s;
+    int sz;
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    if ((sz=ud_disassemble(&ud_s)) && ud_s.mnemonic == UD_Icall)
+        return (sz);
+    return 0;
+}
+
+/* toggle ATT and Intel syntaxes */
+void
+kdb_toggle_dis_syntax(void)
+{
+    if (dis_syntax == UD_SYN_INTEL) {
+        dis_syntax = UD_SYN_ATT;
+        kdbp("dis syntax now set to ATT (Gas)\n");
+    } else {
+        dis_syntax = UD_SYN_INTEL;
+        kdbp("dis syntax now set to Intel (NASM)\n");
+    }
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn-att.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-att.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,211 @@
+/* -----------------------------------------------------------------------------
+ * syn-att.c
+ *
+ * Copyright (c) 2004, 2005, 2006 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case 16 : case 32 :
+		mkasm(u, "*");   break;
+	default: break;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+gen_operand(struct ud* u, struct ud_operand* op)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, "%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM:
+		if (u->br_far) opr_cast(u, op);
+		if (u->pfx_seg)
+			mkasm(u, "%%%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", (-op->lval.sbyte) & 0xff);
+			else	mkasm(u, "0x%x", op->lval.sbyte);
+		} 
+		else if (op->offset == 16) 
+			mkasm(u, "0x%x", op->lval.uword);
+		else if (op->offset == 32) 
+			mkasm(u, "0x%lx", op->lval.udword);
+		else if (op->offset == 64) 
+			mkasm(u, "0x" FMT64 "x", op->lval.uqword);
+
+		if (op->base)
+			mkasm(u, "(%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		if (op->index) {
+			if (op->base)
+				mkasm(u, ",");
+			else mkasm(u, "(");
+			mkasm(u, "%%%s", ud_reg_tab[op->index - UD_R_AL]);
+		}
+		if (op->scale)
+			mkasm(u, ",%d", op->scale);
+		if (op->base || op->index)
+			mkasm(u, ")");
+		break;
+
+	case UD_OP_IMM:
+		switch (op->size) {
+			case  8: mkasm(u, "$0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "$0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "$0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "$0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "$0x%x, $0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "$0x%x, $0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+			
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to AT&T syntax 
+ * =============================================================================
+ */
+extern void 
+ud_translate_att(struct ud *u)
+{
+  int size = 0;
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+  	mkasm(u,  "lock ");
+  if (u->pfx_rep)
+	mkasm(u,  "rep ");
+  if (u->pfx_repne)
+		mkasm(u,  "repne ");
+
+  /* special instructions */
+  switch (u->mnemonic) {
+	case UD_Iretf: 
+		mkasm(u, "lret "); 
+		break;
+	case UD_Idb:
+		mkasm(u, ".byte 0x%x", u->operand[0].lval.ubyte);
+		return;
+	case UD_Ijmp:
+	case UD_Icall:
+		if (u->br_far) mkasm(u,  "l");
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+		break;
+	case UD_Ibound:
+	case UD_Ienter:
+		if (u->operand[0].type != UD_NONE)
+			gen_operand(u, &u->operand[0]);
+		if (u->operand[1].type != UD_NONE) {
+			mkasm(u, ",");
+			gen_operand(u, &u->operand[1]);
+		}
+		return;
+	default:
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+  }
+
+  if (u->c1)
+	size = u->operand[0].size;
+  else if (u->c2)
+	size = u->operand[1].size;
+  else if (u->c3)
+	size = u->operand[2].size;
+
+  if (size == 8)
+	mkasm(u, "b");
+  else if (size == 16)
+	mkasm(u, "w");
+  else if (size == 64)
+ 	mkasm(u, "q");
+
+  mkasm(u, " ");
+
+  if (u->operand[2].type != UD_NONE) {
+	gen_operand(u, &u->operand[2]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[1].type != UD_NONE) {
+	gen_operand(u, &u->operand[1]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[0].type != UD_NONE)
+	gen_operand(u, &u->operand[0]);
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn-intel.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-intel.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,208 @@
+/* -----------------------------------------------------------------------------
+ * syn-intel.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case  8: mkasm(u, "byte " ); break;
+	case 16: mkasm(u, "word " ); break;
+	case 32: mkasm(u, "dword "); break;
+	case 64: mkasm(u, "qword "); break;
+	case 80: mkasm(u, "tword "); break;
+	default: break;
+  }
+  if (u->br_far)
+	mkasm(u, "far "); 
+  else if (u->br_near)
+	mkasm(u, "near ");
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void gen_operand(struct ud* u, struct ud_operand* op, int syn_cast)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM: {
+
+		int op_f = 0;
+
+		if (syn_cast) 
+			opr_cast(u, op);
+
+		mkasm(u, "[");
+
+		if (u->pfx_seg)
+			mkasm(u, "%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+		if (op->base) {
+			mkasm(u, "%s", ud_reg_tab[op->base - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->index) {
+			if (op_f)
+				mkasm(u, "+");
+			mkasm(u, "%s", ud_reg_tab[op->index - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->scale)
+			mkasm(u, "*%d", op->scale);
+
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", -op->lval.sbyte);
+			else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sbyte);
+		}
+		else if (op->offset == 16)
+			mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.uword);
+		else if (op->offset == 32) {
+			if (u->adr_mode == 64) {
+				if (op->lval.sdword < 0)
+					mkasm(u, "-0x%x", -op->lval.sdword);
+				else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sdword);
+			} 
+			else	mkasm(u, "%s0x%lx", (op_f) ? "+" : "", op->lval.udword);
+		}
+		else if (op->offset == 64) 
+			mkasm(u, "%s0x" FMT64 "x", (op_f) ? "+" : "", op->lval.uqword);
+
+		mkasm(u, "]");
+		break;
+	}
+			
+	case UD_OP_IMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8: mkasm(u, "0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "word 0x%x:0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "dword 0x%x:0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+
+	case UD_OP_CONST:
+		if (syn_cast) opr_cast(u, op);
+		mkasm(u, "%d", op->lval.udword);
+		break;
+
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to intel syntax 
+ * =============================================================================
+ */
+extern void ud_translate_intel(struct ud* u)
+{
+  /* -- prefixes -- */
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+	mkasm(u, "lock ");
+  if (u->pfx_rep)
+	mkasm(u, "rep ");
+  if (u->pfx_repne)
+	mkasm(u, "repne ");
+  if (u->implicit_addr && u->pfx_seg)
+	mkasm(u, "%s ", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+  /* print the instruction mnemonic */
+  mkasm(u, "%s ", ud_lookup_mnemonic(u->mnemonic));
+
+  /* operand 1 */
+  if (u->operand[0].type != UD_NONE) {
+	gen_operand(u, &u->operand[0], u->c1);
+  }
+  /* operand 2 */
+  if (u->operand[1].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[1], u->c2);
+  }
+
+  /* operand 3 */
+  if (u->operand[2].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[2], u->c3);
+  }
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,61 @@
+/* -----------------------------------------------------------------------------
+ * syn.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+/* -----------------------------------------------------------------------------
+ * Intel Register Table - Order Matters (types.h)!
+ * -----------------------------------------------------------------------------
+ */
+const char* ud_reg_tab[] = 
+{
+  "al",		"cl",		"dl",		"bl",
+  "ah",		"ch",		"dh",		"bh",
+  "spl",	"bpl",		"sil",		"dil",
+  "r8b",	"r9b",		"r10b",		"r11b",
+  "r12b",	"r13b",		"r14b",		"r15b",
+
+  "ax",		"cx",		"dx",		"bx",
+  "sp",		"bp",		"si",		"di",
+  "r8w",	"r9w",		"r10w",		"r11w",
+  "r12w",	"r13W"	,	"r14w",		"r15w",
+	
+  "eax",	"ecx",		"edx",		"ebx",
+  "esp",	"ebp",		"esi",		"edi",
+  "r8d",	"r9d",		"r10d",		"r11d",
+  "r12d",	"r13d",		"r14d",		"r15d",
+	
+  "rax",	"rcx",		"rdx",		"rbx",
+  "rsp",	"rbp",		"rsi",		"rdi",
+  "r8",		"r9",		"r10",		"r11",
+  "r12",	"r13",		"r14",		"r15",
+
+  "es",		"cs",		"ss",		"ds",
+  "fs",		"gs",	
+
+  "cr0",	"cr1",		"cr2",		"cr3",
+  "cr4",	"cr5",		"cr6",		"cr7",
+  "cr8",	"cr9",		"cr10",		"cr11",
+  "cr12",	"cr13",		"cr14",		"cr15",
+	
+  "dr0",	"dr1",		"dr2",		"dr3",
+  "dr4",	"dr5",		"dr6",		"dr7",
+  "dr8",	"dr9",		"dr10",		"dr11",
+  "dr12",	"dr13",		"dr14",		"dr15",
+
+  "mm0",	"mm1",		"mm2",		"mm3",
+  "mm4",	"mm5",		"mm6",		"mm7",
+
+  "st0",	"st1",		"st2",		"st3",
+  "st4",	"st5",		"st6",		"st7", 
+
+  "xmm0",	"xmm1",		"xmm2",		"xmm3",
+  "xmm4",	"xmm5",		"xmm6",		"xmm7",
+  "xmm8",	"xmm9",		"xmm10",	"xmm11",
+  "xmm12",	"xmm13",	"xmm14",	"xmm15",
+
+  "rip"
+};
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,27 @@
+/* -----------------------------------------------------------------------------
+ * syn.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_SYN_H
+#define UD_SYN_H
+
+#if 0
+#include <stdio.h>
+#include <stdarg.h>
+#endif
+#include "types.h"
+
+extern const char* ud_reg_tab[];
+
+static void mkasm(struct ud* u, const char* fmt, ...)
+{
+  va_list ap;
+  va_start(ap, fmt);
+  u->insn_fill += vsnprintf((char*) u->insn_buffer + u->insn_fill, 64, fmt, ap);
+  va_end(ap);
+}
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/types.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/types.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,186 @@
+/* -----------------------------------------------------------------------------
+ * types.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_TYPES_H
+#define UD_TYPES_H
+
+
+#include "../../include/kdbinc.h"
+
+#define FMT64 "%ll"
+#include "itab.h"
+
+/* -----------------------------------------------------------------------------
+ * All possible "types" of objects in udis86. Order is Important!
+ * -----------------------------------------------------------------------------
+ */
+enum ud_type
+{
+  UD_NONE,
+
+  /* 8 bit GPRs */
+  UD_R_AL,	UD_R_CL,	UD_R_DL,	UD_R_BL,
+  UD_R_AH,	UD_R_CH,	UD_R_DH,	UD_R_BH,
+  UD_R_SPL,	UD_R_BPL,	UD_R_SIL,	UD_R_DIL,
+  UD_R_R8B,	UD_R_R9B,	UD_R_R10B,	UD_R_R11B,
+  UD_R_R12B,	UD_R_R13B,	UD_R_R14B,	UD_R_R15B,
+
+  /* 16 bit GPRs */
+  UD_R_AX,	UD_R_CX,	UD_R_DX,	UD_R_BX,
+  UD_R_SP,	UD_R_BP,	UD_R_SI,	UD_R_DI,
+  UD_R_R8W,	UD_R_R9W,	UD_R_R10W,	UD_R_R11W,
+  UD_R_R12W,	UD_R_R13W,	UD_R_R14W,	UD_R_R15W,
+	
+  /* 32 bit GPRs */
+  UD_R_EAX,	UD_R_ECX,	UD_R_EDX,	UD_R_EBX,
+  UD_R_ESP,	UD_R_EBP,	UD_R_ESI,	UD_R_EDI,
+  UD_R_R8D,	UD_R_R9D,	UD_R_R10D,	UD_R_R11D,
+  UD_R_R12D,	UD_R_R13D,	UD_R_R14D,	UD_R_R15D,
+	
+  /* 64 bit GPRs */
+  UD_R_RAX,	UD_R_RCX,	UD_R_RDX,	UD_R_RBX,
+  UD_R_RSP,	UD_R_RBP,	UD_R_RSI,	UD_R_RDI,
+  UD_R_R8,	UD_R_R9,	UD_R_R10,	UD_R_R11,
+  UD_R_R12,	UD_R_R13,	UD_R_R14,	UD_R_R15,
+
+  /* segment registers */
+  UD_R_ES,	UD_R_CS,	UD_R_SS,	UD_R_DS,
+  UD_R_FS,	UD_R_GS,	
+
+  /* control registers*/
+  UD_R_CR0,	UD_R_CR1,	UD_R_CR2,	UD_R_CR3,
+  UD_R_CR4,	UD_R_CR5,	UD_R_CR6,	UD_R_CR7,
+  UD_R_CR8,	UD_R_CR9,	UD_R_CR10,	UD_R_CR11,
+  UD_R_CR12,	UD_R_CR13,	UD_R_CR14,	UD_R_CR15,
+	
+  /* debug registers */
+  UD_R_DR0,	UD_R_DR1,	UD_R_DR2,	UD_R_DR3,
+  UD_R_DR4,	UD_R_DR5,	UD_R_DR6,	UD_R_DR7,
+  UD_R_DR8,	UD_R_DR9,	UD_R_DR10,	UD_R_DR11,
+  UD_R_DR12,	UD_R_DR13,	UD_R_DR14,	UD_R_DR15,
+
+  /* mmx registers */
+  UD_R_MM0,	UD_R_MM1,	UD_R_MM2,	UD_R_MM3,
+  UD_R_MM4,	UD_R_MM5,	UD_R_MM6,	UD_R_MM7,
+
+  /* x87 registers */
+  UD_R_ST0,	UD_R_ST1,	UD_R_ST2,	UD_R_ST3,
+  UD_R_ST4,	UD_R_ST5,	UD_R_ST6,	UD_R_ST7, 
+
+  /* extended multimedia registers */
+  UD_R_XMM0,	UD_R_XMM1,	UD_R_XMM2,	UD_R_XMM3,
+  UD_R_XMM4,	UD_R_XMM5,	UD_R_XMM6,	UD_R_XMM7,
+  UD_R_XMM8,	UD_R_XMM9,	UD_R_XMM10,	UD_R_XMM11,
+  UD_R_XMM12,	UD_R_XMM13,	UD_R_XMM14,	UD_R_XMM15,
+
+  UD_R_RIP,
+
+  /* Operand Types */
+  UD_OP_REG,	UD_OP_MEM,	UD_OP_PTR,	UD_OP_IMM,	
+  UD_OP_JIMM,	UD_OP_CONST
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud_operand - Disassembled instruction Operand.
+ * -----------------------------------------------------------------------------
+ */
+struct ud_operand 
+{
+  enum ud_type		type;
+  uint8_t		size;
+  union {
+	int8_t		sbyte;
+	uint8_t		ubyte;
+	int16_t		sword;
+	uint16_t	uword;
+	int32_t		sdword;
+	uint32_t	udword;
+	int64_t		sqword;
+	uint64_t	uqword;
+
+	struct {
+		uint16_t seg;
+		uint32_t off;
+	} ptr;
+  } lval;
+
+  enum ud_type		base;
+  enum ud_type		index;
+  uint8_t		offset;
+  uint8_t		scale;	
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud - The udis86 object.
+ * -----------------------------------------------------------------------------
+ */
+struct ud
+{
+  int 			(*inp_hook) (struct ud*);
+  uint8_t		inp_curr;
+  uint8_t		inp_fill;
+  uint8_t		inp_ctr;
+  uint8_t*		inp_buff;
+  uint8_t*		inp_buff_end;
+  uint8_t		inp_end;
+  void			(*translator)(struct ud*);
+  uint64_t		insn_offset;
+  char			insn_hexcode[32];
+  char			insn_buffer[64];
+  unsigned int		insn_fill;
+  uint8_t		dis_mode;
+  uint64_t		pc;
+  uint8_t		vendor;
+  struct map_entry*	mapen;
+  enum ud_mnemonic_code	mnemonic;
+  struct ud_operand	operand[3];
+  uint8_t		error;
+  uint8_t	 	pfx_rex;
+  uint8_t 		pfx_seg;
+  uint8_t 		pfx_opr;
+  uint8_t 		pfx_adr;
+  uint8_t 		pfx_lock;
+  uint8_t 		pfx_rep;
+  uint8_t 		pfx_repe;
+  uint8_t 		pfx_repne;
+  uint8_t 		pfx_insn;
+  uint8_t		default64;
+  uint8_t		opr_mode;
+  uint8_t		adr_mode;
+  uint8_t		br_far;
+  uint8_t		br_near;
+  uint8_t		implicit_addr;
+  uint8_t		c1;
+  uint8_t		c2;
+  uint8_t		c3;
+  uint8_t 		inp_cache[256];
+  uint8_t		inp_sess[64];
+  struct ud_itab_entry * itab_entry;
+};
+
+/* -----------------------------------------------------------------------------
+ * Type-definitions
+ * -----------------------------------------------------------------------------
+ */
+typedef enum ud_type 		ud_type_t;
+typedef enum ud_mnemonic_code	ud_mnemonic_code_t;
+
+typedef struct ud 		ud_t;
+typedef struct ud_operand 	ud_operand_t;
+
+#define UD_SYN_INTEL		ud_translate_intel
+#define UD_SYN_ATT		ud_translate_att
+#define UD_EOI			-1
+#define UD_INP_CACHE_SZ		32
+#define UD_VENDOR_AMD		0
+#define UD_VENDOR_INTEL		1
+
+#define bail_out(ud,error_code) longjmp( (ud)->bailout, error_code )
+#define try_decode(ud) if ( setjmp( (ud)->bailout ) == 0 )
+#define catch_error() else
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/udis86.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/udis86.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,156 @@
+/* -----------------------------------------------------------------------------
+ * udis86.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#endif
+
+#include "input.h"
+#include "extern.h"
+
+/* =============================================================================
+ * ud_init() - Initializes ud_t object.
+ * =============================================================================
+ */
+extern void 
+ud_init(struct ud* u)
+{
+  memset((void*)u, 0, sizeof(struct ud));
+  ud_set_mode(u, 16);
+  u->mnemonic = UD_Iinvalid;
+  ud_set_pc(u, 0);
+#ifndef __UD_STANDALONE__
+  ud_set_input_file(u, stdin);
+#endif /* __UD_STANDALONE__ */
+}
+
+/* =============================================================================
+ * ud_disassemble() - disassembles one instruction and returns the number of 
+ * bytes disassembled. A zero means end of disassembly.
+ * =============================================================================
+ */
+extern unsigned int
+ud_disassemble(struct ud* u)
+{
+  if (ud_input_end(u))
+	return 0;
+
+ 
+  u->insn_buffer[0] = u->insn_hexcode[0] = 0;
+
+ 
+  if (ud_decode(u) == 0)
+	return 0;
+  if (u->translator)
+	u->translator(u);
+  return ud_insn_len(u);
+}
+
+/* =============================================================================
+ * ud_set_mode() - Set Disassemly Mode.
+ * =============================================================================
+ */
+extern void 
+ud_set_mode(struct ud* u, uint8_t m)
+{
+  switch(m) {
+	case 16:
+	case 32:
+	case 64: u->dis_mode = m ; return;
+	default: u->dis_mode = 16; return;
+  }
+}
+
+/* =============================================================================
+ * ud_set_vendor() - Set vendor.
+ * =============================================================================
+ */
+extern void 
+ud_set_vendor(struct ud* u, unsigned v)
+{
+  switch(v) {
+	case UD_VENDOR_INTEL:
+		u->vendor = v;
+		break;
+	default:
+		u->vendor = UD_VENDOR_AMD;
+  }
+}
+
+/* =============================================================================
+ * ud_set_pc() - Sets code origin. 
+ * =============================================================================
+ */
+extern void 
+ud_set_pc(struct ud* u, uint64_t o)
+{
+  u->pc = o;
+}
+
+/* =============================================================================
+ * ud_set_syntax() - Sets the output syntax.
+ * =============================================================================
+ */
+extern void 
+ud_set_syntax(struct ud* u, void (*t)(struct ud*))
+{
+  u->translator = t;
+}
+
+/* =============================================================================
+ * ud_insn() - returns the disassembled instruction
+ * =============================================================================
+ */
+extern char* 
+ud_insn_asm(struct ud* u) 
+{
+  return u->insn_buffer;
+}
+
+/* =============================================================================
+ * ud_insn_offset() - Returns the offset.
+ * =============================================================================
+ */
+extern uint64_t
+ud_insn_off(struct ud* u) 
+{
+  return u->insn_offset;
+}
+
+
+/* =============================================================================
+ * ud_insn_hex() - Returns hex form of disassembled instruction.
+ * =============================================================================
+ */
+extern char* 
+ud_insn_hex(struct ud* u) 
+{
+  return u->insn_hexcode;
+}
+
+/* =============================================================================
+ * ud_insn_ptr() - Returns code disassembled.
+ * =============================================================================
+ */
+extern uint8_t* 
+ud_insn_ptr(struct ud* u) 
+{
+  return u->inp_sess;
+}
+
+/* =============================================================================
+ * ud_insn_len() - Returns the count of bytes disassembled.
+ * =============================================================================
+ */
+extern unsigned int 
+ud_insn_len(struct ud* u) 
+{
+  return u->inp_ctr;
+}

--MP_/X3qA/jwEscosmMB+TVJPo3b
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MP_/X3qA/jwEscosmMB+TVJPo3b--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePsG-0003mC-UC; Tue, 12 Jun 2012 12:07:04 +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 1SeAVN-0003b3-ON
	for Xen-devel@lists.xensource.com; Mon, 11 Jun 2012 19:42:27 +0000
Received: from [85.158.143.35:16653] by server-1.bemta-4.messagelabs.com id
	08/28-24392-02A46DF4; Mon, 11 Jun 2012 19:42:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339443740!11390857!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4Mjc3OQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12310 invoked from network); 11 Jun 2012 19:42:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jun 2012 19:42:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5BJgH5l004676
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 11 Jun 2012 19:42:18 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
	q5BJgG3o011857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 11 Jun 2012 19:42:16 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
	q5BJgF4F018174; Mon, 11 Jun 2012 14:42:15 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Jun 2012 12:42:14 -0700
Date: Mon, 11 Jun 2012 12:42:13 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Cyclonus J <cyclonusj@gmail.com>
Message-ID: <20120611124213.18e2c7fb@mantra.us.oracle.com>
In-Reply-To: <CAOzbF4cp8M4eYCkJgnsyxLREOOMiHUfc0ftacNnMuX5ZB6SBCA@mail.gmail.com>
References: <CAOzbF4cp8M4eYCkJgnsyxLREOOMiHUfc0ftacNnMuX5ZB6SBCA@mail.gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="MP_/X3qA/jwEscosmMB+TVJPo3b"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Tue, 12 Jun 2012 12:07:02 +0000
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen debugger support for newer version of 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

--MP_/X3qA/jwEscosmMB+TVJPo3b
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sat, 9 Jun 2012 01:56:32 -0700
Cyclonus J <cyclonusj@gmail.com> wrote:

> Hi Mukesh,
> 
> I am currently dealing some device driver issues with Xen 4.1.2 and
> would like to try out your great Xen debugger, but it looks like that
> your Xen debugger only supports 4.1.0-rc3 and the last update is
> almost one year ago.
> 
> So my question is what would be your plan to support Xen debugger for
> future Xen releases? And if there is a plan, may I help you?
> 
> Thanks,
> CJ

I've been just maintaining it here. I add/update as needed for my
debugging. I am attaching patch that should apply cleanly to unstable
c/s 25467. You should be able to back it up to 4.1.2 with minor
changes, like header/struct changes, (so fixup printk's), etc. Give
it a shot. This is the latest. If you have difficulty, I can send you
4.1.2 version, but I'd need to update it a bit. 

Hope that helps,
Mukesh



--MP_/X3qA/jwEscosmMB+TVJPo3b
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=kdb.patch

diff -r 32034d1914a6 -r e4b01842b71c xen/Makefile
--- a/xen/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -61,6 +61,7 @@ _clean: delete-unfresh-files
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C kdb clean
 	rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET)-syms *~ core
 	rm -f include/asm-*/asm-offsets.h
 	[ -d tools/figlet ] && rm -f .banner*
@@ -129,7 +130,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h
 	  echo ""; \
 	  echo "#endif") <$< >$@
 
-SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers
+SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers kdb
 define all_sources
     ( find include/asm-$(TARGET_ARCH) -name '*.h' -print; \
       find include -name 'asm-*' -prune -o -name '*.h' -print; \
diff -r 32034d1914a6 -r e4b01842b71c xen/Rules.mk
--- a/xen/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Rules.mk	Fri Jun 08 10:56:24 2012 -0700
@@ -10,6 +10,7 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto           ?= n
+kdb           ?= n
 
 include $(XEN_ROOT)/Config.mk
 
@@ -40,6 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/d
 ALL_OBJS-y               += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(kdb)          += $(BASEDIR)/kdb/built_in.o
 
 CFLAGS-y                += -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
@@ -53,6 +55,7 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFIL
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(kdb)           += -DXEN_KDB_CONFIG
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y                += -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/svm/entry.S
--- a/xen/arch/x86/hvm/svm/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -59,12 +59,23 @@ ENTRY(svm_asm_do_resume)
         get_current(bx)
         CLGI
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         testl $~0,(r(dx),r(ax),1)
         jnz  .Lsvm_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0, VCPU_nsvm_hap_enabled(r(bx))
 UNLIKELY_START(nz, nsvm_hap)
         mov  VCPU_nhvm_p2m(r(bx)),r(ax)
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2170,6 +2170,10 @@ void svm_vmexit_handler(struct cpu_user_
         break;
 
     case VMEXIT_EXCEPTION_DB:
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+	    break;
+#endif
         if ( !v->domain->debugger_attached )
             goto exit_and_crash;
         domain_pause_for_debugger();
@@ -2182,6 +2186,10 @@ void svm_vmexit_handler(struct cpu_user_
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
         __update_guest_eip(regs, inst_len);
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_int3, regs))
+            break;
+#endif
         current->arch.gdbsx_vcpu_event = TRAP_int3;
         domain_pause_for_debugger();
         break;
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Fri Jun 08 10:56:24 2012 -0700
@@ -315,6 +315,36 @@ void setup_vmcb_dump(void)
     register_keyhandler('v', &vmcb_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+/* did == 0 : display for all HVM domains. domid 0 is never HVM.
+ *  * vid == -1 : display for all HVM VCPUs
+ *   */
+void kdb_dump_vmcb(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain (dp) {
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+            kdbp("  VMCB [domid: %d  vcpu:%d]:\n", dp->domain_id, vp->vcpu_id);
+            svm_vmcb_dump("kdb", vp->arch.hvm_svm.vmcb);
+            kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    rcu_read_unlock(&domlist_read_lock);
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/vmx/entry.S
--- a/xen/arch/x86/hvm/vmx/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -124,12 +124,23 @@ vmx_asm_do_vmentry:
         get_current(bx)
         cli
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         cmpl $0,(r(dx),r(ax),1)
         jnz  .Lvmx_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0xff,VCPU_vmx_emulate(r(bx))
         jnz .Lvmx_goto_emulator
         testb $0xff,VCPU_vmx_realmode(r(bx))
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Fri Jun 08 10:56:24 2012 -0700
@@ -1117,6 +1117,13 @@ void vmx_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
+#if defined(XEN_KDB_CONFIG)
+    if (kdb_dr7)
+        __vmwrite(GUEST_DR7, kdb_dr7);
+    else
+        __vmwrite(GUEST_DR7, 0);
+#endif
+
     debug_state = v->domain->debugger_attached
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_INT3]
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP];
@@ -1326,6 +1333,220 @@ void setup_vmcs_dump(void)
     register_keyhandler('v', &vmcs_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+#define GUEST_EFER      0x2806   /* see page 23-20 */
+#define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+
+/* it's a shame we can't use vmcs_dump_vcpu(), but it does vmx_vmcs_enter which
+ * will IPI other CPUs. also, print a subset relevant to software debugging */
+static void noinline kdb_print_vmcs(struct vcpu *vp)
+{
+    struct cpu_user_regs *regs = &vp->arch.user_regs;
+    unsigned long long x;
+
+    kdbp("*** Guest State ***\n");
+    kdbp("CR0: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR0),
+         (unsigned long long)vmr(CR0_READ_SHADOW), 
+         (unsigned long long)vmr(CR0_GUEST_HOST_MASK));
+    kdbp("CR4: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR4),
+         (unsigned long long)vmr(CR4_READ_SHADOW), 
+         (unsigned long long)vmr(CR4_GUEST_HOST_MASK));
+    kdbp("CR3: actual=0x%016llx, target_count=%d\n",
+         (unsigned long long)vmr(GUEST_CR3),
+         (int)vmr(CR3_TARGET_COUNT));
+    kdbp("     target0=%016llx, target1=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE0),
+         (unsigned long long)vmr(CR3_TARGET_VALUE1));
+    kdbp("     target2=%016llx, target3=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE2),
+         (unsigned long long)vmr(CR3_TARGET_VALUE3));
+    kdbp("RSP = 0x%016llx (0x%016llx)  RIP = 0x%016llx (0x%016llx)\n", 
+         (unsigned long long)vmr(GUEST_RSP),
+         (unsigned long long)regs->esp,
+         (unsigned long long)vmr(GUEST_RIP),
+         (unsigned long long)regs->eip);
+    kdbp("RFLAGS=0x%016llx (0x%016llx)  DR7 = 0x%016llx\n", 
+         (unsigned long long)vmr(GUEST_RFLAGS),
+         (unsigned long long)regs->eflags,
+         (unsigned long long)vmr(GUEST_DR7));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+         (unsigned long long)vmr(GUEST_SYSENTER_ESP),
+         (int)vmr(GUEST_SYSENTER_CS),
+         (unsigned long long)vmr(GUEST_SYSENTER_EIP));
+    vmx_dump_sel("CS", GUEST_CS_SELECTOR);
+    vmx_dump_sel("DS", GUEST_DS_SELECTOR);
+    vmx_dump_sel("SS", GUEST_SS_SELECTOR);
+    vmx_dump_sel("ES", GUEST_ES_SELECTOR);
+    vmx_dump_sel("FS", GUEST_FS_SELECTOR);
+    vmx_dump_sel("GS", GUEST_GS_SELECTOR);
+    vmx_dump_sel2("GDTR", GUEST_GDTR_LIMIT);
+    vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
+    vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
+    vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
+    kdbp("Guest PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
+    x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
+    x |= (uint32_t)vmr(TSC_OFFSET);
+    kdbp("TSC Offset = %016llx\n", x);
+    x  = (unsigned long long)vmr(GUEST_IA32_DEBUGCTL_HIGH) << 32;
+    x |= (uint32_t)vmr(GUEST_IA32_DEBUGCTL);
+    kdbp("DebugCtl=%016llx DebugExceptions=%016llx\n", x,
+           (unsigned long long)vmr(GUEST_PENDING_DBG_EXCEPTIONS));
+    kdbp("Interruptibility=%04x ActivityState=%04x\n",
+           (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
+           (int)vmr(GUEST_ACTIVITY_STATE));
+
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
+    kdbp("\n*** Host State ***\n");
+    kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
+           (unsigned long long)vmr(HOST_RSP),
+           (unsigned long long)vmr(HOST_RIP));
+    kdbp("CS=%04x DS=%04x ES=%04x FS=%04x GS=%04x SS=%04x TR=%04x\n",
+           (uint16_t)vmr(HOST_CS_SELECTOR),
+           (uint16_t)vmr(HOST_DS_SELECTOR),
+           (uint16_t)vmr(HOST_ES_SELECTOR),
+           (uint16_t)vmr(HOST_FS_SELECTOR),
+           (uint16_t)vmr(HOST_GS_SELECTOR),
+           (uint16_t)vmr(HOST_SS_SELECTOR),
+           (uint16_t)vmr(HOST_TR_SELECTOR));
+    kdbp("FSBase=%016llx GSBase=%016llx TRBase=%016llx\n",
+           (unsigned long long)vmr(HOST_FS_BASE),
+           (unsigned long long)vmr(HOST_GS_BASE),
+           (unsigned long long)vmr(HOST_TR_BASE));
+    kdbp("GDTBase=%016llx IDTBase=%016llx\n",
+           (unsigned long long)vmr(HOST_GDTR_BASE),
+           (unsigned long long)vmr(HOST_IDTR_BASE));
+    kdbp("CR0=%016llx CR3=%016llx CR4=%016llx\n",
+           (unsigned long long)vmr(HOST_CR0),
+           (unsigned long long)vmr(HOST_CR3),
+           (unsigned long long)vmr(HOST_CR4));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+           (unsigned long long)vmr(HOST_SYSENTER_ESP),
+           (int)vmr(HOST_SYSENTER_CS),
+           (unsigned long long)vmr(HOST_SYSENTER_EIP));
+    kdbp("Host PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(HOST_PAT_HIGH), (uint32_t)vmr(HOST_PAT));
+
+    kdbp("\n*** Control State ***\n");
+    kdbp("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n",
+           (uint32_t)vmr(PIN_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(CPU_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(SECONDARY_VM_EXEC_CONTROL));
+    kdbp("EntryControls=%08x ExitControls=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_CONTROLS),
+           (uint32_t)vmr(VM_EXIT_CONTROLS));
+    kdbp("ExceptionBitmap=%08x\n",
+           (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
+    kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_INTR_INFO),
+           (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("VMExit: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_EXIT_INTR_INFO),
+           (uint32_t)vmr(VM_EXIT_INTR_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("        reason=%08x qualification=%08x\n",
+           (uint32_t)vmr(VM_EXIT_REASON),
+           (uint32_t)vmr(EXIT_QUALIFICATION));
+    kdbp("IDTVectoring: info=%08x errcode=%08x\n",
+           (uint32_t)vmr(IDT_VECTORING_INFO),
+           (uint32_t)vmr(IDT_VECTORING_ERROR_CODE));
+    kdbp("TPR Threshold = 0x%02x\n",
+           (uint32_t)vmr(TPR_THRESHOLD));
+    kdbp("EPT pointer = 0x%08x%08x\n",
+           (uint32_t)vmr(EPT_POINTER_HIGH), (uint32_t)vmr(EPT_POINTER));
+    kdbp("Virtual processor ID = 0x%04x\n",
+           (uint32_t)vmr(VIRTUAL_PROCESSOR_ID));
+    kdbp("=================================================================\n");
+}
+
+/* Flush VMCS on this cpu if it needs to: 
+ *   - Upon leaving kdb, the HVM cpu will resume in vmx_vmexit_handler() and 
+ *     do __vmreads. So, the VMCS pointer can't be left cleared.
+ *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
+ *     vmlaunch must be done and not vmresume. This means, we must clear 
+ *     arch_vmx->launched.
+ */
+void kdb_curr_cpu_flush_vmcs(void)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    int ccpu = smp_processor_id();
+    struct vmcs_struct *cvp = this_cpu(current_vmcs);
+
+    if (this_cpu(current_vmcs) == NULL)
+        return;             /* no HVM active on this CPU */
+
+    kdbp("KDB:[%d] curvmcs:%lx/%lx\n", ccpu, cvp, virt_to_maddr(cvp));
+
+    /* looks like we got one. unfortunately, current_vmcs points to vmcs 
+     * and not VCPU, so we gotta search the entire list... */
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        for_each_vcpu (dp, vp) {
+            if ( vp->arch.hvm_vmx.vmcs == cvp ) {
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched = 0;
+                this_cpu(current_vmcs) = NULL;
+                kdbp("KDB:[%d] %d:%d current_vmcs:%lx flushed\n", 
+		     ccpu, dp->domain_id, vp->vcpu_id, cvp, virt_to_maddr(cvp));
+            }
+        }
+    }
+}
+
+/*
+ * domid == 0 : display for all HVM domains  (dom0 is never an HVM domain)
+ * vcpu id == -1 : display all vcpuids
+ * PreCondition: all HVM cpus (including current cpu) have flushed VMCS
+ */
+void kdb_dump_vmcs(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    struct vmcs_struct  *vmcsp;
+    u64 addr = -1;
+
+    ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
+    __vmptrst(&addr);
+
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+	    vmcsp = vp->arch.hvm_vmx.vmcs;
+            kdbp("VMCS %lx/%lx [domid:%d (%p)  vcpu:%d (%p)]:\n", vmcsp,
+	         virt_to_maddr(vmcsp), dp->domain_id, dp, vp->vcpu_id, vp);
+            __vmptrld(virt_to_maddr(vmcsp));
+            kdb_print_vmcs(vp);
+            __vmpclear(virt_to_maddr(vmcsp));
+            vp->arch.hvm_vmx.launched = 0;
+        }
+        kdbp("\n");
+    }
+    /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
+    if (addr && addr != (u64)-1)
+        __vmptrld(addr);
+}
+#endif
 
 /*
  * Local variables:
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2183,11 +2183,14 @@ static void vmx_failed_vmentry(unsigned 
         printk("reason not known yet!");
         break;
     }
-
+#if defined(XEN_KDB_CONFIG)
+    kdbp("\n************* VMCS Area **************\n");
+    kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
-
+#endif
     domain_crash(curr->domain);
 }
 
@@ -2415,6 +2418,12 @@ void vmx_vmexit_handler(struct cpu_user_
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
+
+#if defined(XEN_KDB_CONFIG)
+            /* TRAP_debug: IP points correctly to next instr */
+            if (kdb_handle_trap_entry(vector, regs))
+                break;
+#endif
             domain_pause_for_debugger();
             break;
         case TRAP_int3: 
@@ -2423,6 +2432,13 @@ void vmx_vmexit_handler(struct cpu_user_
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
+#if defined(XEN_KDB_CONFIG)
+                /* vmcs.IP points to bp, kdb expects bp+1. Hence after the above
+                 * update_guest_eip which updates to bp+1. works for gdbsx too 
+                 */
+                if (kdb_handle_trap_entry(vector, regs))
+                    break;
+#endif
                 current->arch.gdbsx_vcpu_event = TRAP_int3;
                 domain_pause_for_debugger();
                 break;
@@ -2707,6 +2723,10 @@ void vmx_vmexit_handler(struct cpu_user_
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
+#if defined(XEN_KDB_CONFIG)
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+            break;
+#endif
         if ( v->arch.hvm_vcpu.single_step ) {
           hvm_memory_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/irq.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2305,3 +2305,29 @@ bool_t hvm_domain_use_pirq(const struct 
     return is_hvm_domain(d) && pirq &&
            pirq->arch.hvm.emuirq != IRQ_UNBOUND; 
 }
+
+#ifdef XEN_KDB_CONFIG
+void kdb_prnt_guest_mapped_irqs(void)
+{
+    int irq, j;
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    kdbp("irq  vec  aff  type  domid:mapped-pirq pairs  (all in decimal)\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+        irq_guest_action_t *actp = (irq_guest_action_t *)dp->action;
+
+        if (!dp->handler ||dp->handler==&no_irq_type || !(dp->status&IRQ_GUEST))
+            continue;
+
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %3d %3s %-13s ", irq, archp->vector, affstr,
+             dp->handler->typename);
+        for (j=0; j < actp->nr_guests; j++)
+            kdbp("%03d:%04d ", actp->guest[j]->domain_id,
+                 domain_irq_to_pirq(actp->guest[j], irq));
+        kdbp("\n");
+    }
+}
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/setup.c	Fri Jun 08 10:56:24 2012 -0700
@@ -47,6 +47,13 @@
 #include <xen/cpu.h>
 #include <asm/nmi.h>
 
+#ifdef XEN_KDB_CONFIG
+#include <asm/debugger.h>
+
+int opt_earlykdb=0;
+boolean_param("earlykdb", opt_earlykdb);
+#endif
+
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
 boolean_param("nosmp", opt_nosmp);
@@ -1242,6 +1249,11 @@ void __init __start_xen(unsigned long mb
 
     trap_init();
 
+#ifdef XEN_KDB_CONFIG
+    kdb_init();
+    if (opt_earlykdb)
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+#endif
     rcu_init();
     
     early_time_init();
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/smp.c
--- a/xen/arch/x86/smp.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/smp.c	Fri Jun 08 10:56:24 2012 -0700
@@ -273,7 +273,7 @@ void smp_send_event_check_mask(const cpu
  * Structure and data for smp_call_function()/on_selected_cpus().
  */
 
-static void __smp_call_function_interrupt(void);
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs);
 static DEFINE_SPINLOCK(call_lock);
 static struct call_data_struct {
     void (*func) (void *info);
@@ -321,7 +321,7 @@ void on_selected_cpus(
     if ( cpumask_test_cpu(smp_processor_id(), &call_data.selected) )
     {
         local_irq_disable();
-        __smp_call_function_interrupt();
+        __smp_call_function_interrupt(NULL);
         local_irq_enable();
     }
 
@@ -390,7 +390,7 @@ void event_check_interrupt(struct cpu_us
     this_cpu(irq_count)++;
 }
 
-static void __smp_call_function_interrupt(void)
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs)
 {
     void (*func)(void *info) = call_data.func;
     void *info = call_data.info;
@@ -411,6 +411,11 @@ static void __smp_call_function_interrup
     {
         mb();
         cpumask_clear_cpu(cpu, &call_data.selected);
+#ifdef XEN_KDB_CONFIG
+        if (info && !strcmp(info, "XENKDB")) {           /* called from kdb */
+                (*(void (*)(struct cpu_user_regs *, void *))func)(regs, info);
+        } else
+#endif
         (*func)(info);
     }
 
@@ -421,5 +426,5 @@ void call_function_interrupt(struct cpu_
 {
     ack_APIC_irq();
     perfc_incr(ipis);
-    __smp_call_function_interrupt();
+    __smp_call_function_interrupt(regs);
 }
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/time.c	Fri Jun 08 10:56:24 2012 -0700
@@ -2007,6 +2007,46 @@ static int __init setup_dump_softtsc(voi
 }
 __initcall(setup_dump_softtsc);
 
+#ifdef XEN_KDB_CONFIG
+void kdb_time_resume(int update_domains)
+{
+        s_time_t now;
+        int ccpu = smp_processor_id();
+        struct cpu_time *t = &this_cpu(cpu_time);
+
+        if (!plt_src.read_counter)            /* not initialized for earlykdb */
+                return;
+
+        if (update_domains) {
+                plt_stamp = plt_src.read_counter();
+                platform_timer_stamp = plt_stamp64;
+                platform_time_calibration();
+                do_settime(get_cmos_time(), 0, read_platform_stime());
+        }
+        if (local_irq_is_enabled())
+                kdbp("kdb BUG: enabled in time_resume(). ccpu:%d\n", ccpu);
+
+        rdtscll(t->local_tsc_stamp);
+        now = read_platform_stime();
+        t->stime_master_stamp = now;
+        t->stime_local_stamp  = now;
+
+        update_vcpu_system_time(current);
+
+        if (update_domains)
+                set_timer(&calibration_timer, NOW() + EPOCH);
+}
+
+void kdb_dump_time_pcpu(void)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        kdbp("[%d]: cpu_time: %016lx\n", cpu, &per_cpu(cpu_time, cpu));
+        kdbp("[%d]: cpu_calibration: %016lx\n", cpu, 
+             &per_cpu(cpu_calibration, cpu));
+    }
+}
+#endif
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/traps.c	Fri Jun 08 10:56:24 2012 -0700
@@ -225,7 +225,7 @@ static void show_trace(struct cpu_user_r
 
 #else
 
-static void show_trace(struct cpu_user_regs *regs)
+void show_trace(struct cpu_user_regs *regs)
 {
     unsigned long *frame, next, addr, low, high;
 
@@ -3326,6 +3326,10 @@ void do_nmi(struct cpu_user_regs *regs)
     if ( nmi_callback(regs, cpu) )
         return;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_enabled && kdb_handle_trap_entry(TRAP_nmi, regs))
+        return;
+#endif
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
 
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/x86_64/compat/entry.S
--- a/xen/arch/x86/x86_64/compat/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/compat/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -95,6 +95,10 @@ compat_skip_clobber:
 /* %rbx: struct vcpu */
 ENTRY(compat_test_all_events)
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG
+        testl $1, kdb_session_begun(%rip)
+        jnz   compat_restore_all_guest
+#endif
 /*compat_test_softirqs:*/
         movl  VCPU_processor(%rbx),%eax
         shlq  $IRQSTAT_shift,%rax
diff -r 32034d1914a6 -r e4b01842b71c xen/arch/x86/x86_64/entry.S
--- a/xen/arch/x86/x86_64/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/entry.S	Fri Jun 08 10:56:24 2012 -0700
@@ -184,6 +184,10 @@ skip_clobber:
 /* %rbx: struct vcpu */
 test_all_events:
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG                   /* 64bit dom0 will resume here */
+        testl $1, kdb_session_begun(%rip)
+        jnz   restore_all_guest
+#endif
 /*test_softirqs:*/  
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
@@ -546,6 +550,13 @@ ENTRY(debug)
 
 ENTRY(int3)
         pushq $0
+#ifdef XEN_KDB_CONFIG
+        pushq %rax
+        GET_CPUINFO_FIELD(CPUINFO_processor_id, %rax)
+        movq  (%rax), %rax
+        lock  bts %rax, kdb_cpu_traps(%rip)
+        popq  %rax
+#endif
         movl  $TRAP_int3,4(%rsp)
         jmp   handle_exception
 
diff -r 32034d1914a6 -r e4b01842b71c xen/common/domain.c
--- a/xen/common/domain.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/domain.c	Fri Jun 08 10:56:24 2012 -0700
@@ -530,6 +530,14 @@ void domain_shutdown(struct domain *d, u
 {
     struct vcpu *v;
 
+#ifdef XEN_KDB_CONFIG
+    if (reason == SHUTDOWN_crash) {
+        if ( IS_PRIV(d) )
+            kdb_trap_immed(KDB_TRAP_FATAL);
+        else
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+    }
+#endif
     spin_lock(&d->shutdown_lock);
 
     if ( d->shutdown_code == -1 )
@@ -624,7 +632,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* send VIRQ_DEBUGGER to guest only if gdbsx_vcpu_event is not active */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r 32034d1914a6 -r e4b01842b71c xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/sched_credit.c	Fri Jun 08 10:56:24 2012 -0700
@@ -1475,6 +1475,33 @@ csched_dump_vcpu(struct csched_vcpu *svc
     printk("\n");
 }
 
+#ifdef XEN_KDB_CONFIG
+static void kdb_csched_dump(int cpu)
+{
+    struct csched_pcpu *pcpup = CSCHED_PCPU(cpu);
+    struct vcpu *scurrvp = (CSCHED_VCPU(current))->vcpu;
+    struct list_head *tmp, *runq = RUNQ(cpu);
+
+    kdbp("    csched_pcpu: %p\n", pcpup);
+    kdbp("    curr csched:%p {vcpu:%p id:%d domid:%d}\n", (current)->sched_priv,
+         scurrvp, scurrvp->vcpu_id, scurrvp->domain->domain_id);
+    kdbp("    runq:\n");
+
+    /* next is top of struct, so screw stupid, ugly hard to follow macros */
+    if (offsetof(struct csched_vcpu, runq_elem.next) != 0) {
+        kdbp("next is not first in struct csched_vcpu. please fixme\n");
+        return;        /* otherwise for loop will crash */
+    }
+    for (tmp = runq->next; tmp != runq; tmp = tmp->next) {
+
+        struct csched_vcpu *csp = (struct csched_vcpu *)tmp;
+        struct vcpu *vp = csp->vcpu;
+        kdbp("      csp:%p pri:%02d vcpu: {p:%p id:%d domid:%d}\n", csp,
+             csp->pri, vp, vp->vcpu_id, vp->domain->domain_id);
+    };
+}
+#endif
+
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
@@ -1484,6 +1511,10 @@ csched_dump_pcpu(const struct scheduler 
     int loop;
 #define cpustr keyhandler_scratch
 
+#ifdef XEN_KDB_CONFIG
+    kdb_csched_dump(cpu);
+    return;
+#endif
     spc = CSCHED_PCPU(cpu);
     runq = &spc->runq;
 
diff -r 32034d1914a6 -r e4b01842b71c xen/common/schedule.c
--- a/xen/common/schedule.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/schedule.c	Fri Jun 08 10:56:24 2012 -0700
@@ -1454,6 +1454,25 @@ void wait(void)
     schedule();
 }
 
+#ifdef XEN_KDB_CONFIG
+void kdb_print_sched_info(void)
+{
+    int cpu;
+
+    kdbp("Scheduler: name:%s opt_name:%s id:%d\n", ops.name, ops.opt_name,
+         ops.sched_id);
+    kdbp("per cpu schedule_data:\n");
+    for_each_online_cpu(cpu) {
+        struct schedule_data *p =  &per_cpu(schedule_data, cpu);
+        kdbp("  cpu:%d  &(per cpu)schedule_data:%p\n", cpu, p);
+        kdbp("         curr:%p sched_priv:%p\n", p->curr, p->sched_priv);
+        kdbp("\n");
+        ops.dump_cpu_state(&ops, cpu);
+        kdbp("\n");
+    }
+}
+#endif
+
 #ifdef CONFIG_COMPAT
 #include "compat/schedule.c"
 #endif
diff -r 32034d1914a6 -r e4b01842b71c xen/common/symbols.c
--- a/xen/common/symbols.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/symbols.c	Fri Jun 08 10:56:24 2012 -0700
@@ -168,3 +168,21 @@ void __print_symbol(const char *fmt, uns
 
     spin_unlock_irqrestore(&lock, flags);
 }
+
+#ifdef XEN_KDB_CONFIG
+/*
+ *  * Given a symbol, return its address 
+ *   */
+unsigned long address_lookup(char *symp)
+{
+    int i, off = 0;
+    char namebuf[KSYM_NAME_LEN+1];
+
+    for (i=0; i < symbols_num_syms; i++) {
+        off = symbols_expand_symbol(off, namebuf);
+        if (strcmp(namebuf, symp) == 0)                  /* found it */
+            return symbols_address(i);
+    }
+    return 0;
+}
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/common/timer.c
--- a/xen/common/timer.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/timer.c	Fri Jun 08 10:56:24 2012 -0700
@@ -643,6 +643,48 @@ void __init timer_init(void)
     register_keyhandler('a', &dump_timerq_keyhandler);
 }
 
+#ifdef XEN_KDB_CONFIG
+#include <xen/symbols.h>
+void kdb_dump_timer_queues(void)
+{
+    struct timer  *t;
+    struct timers *ts;
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1];
+    int cpu, j;
+    u64 tsc;
+
+    for_each_online_cpu( cpu )
+    {
+        ts = &per_cpu(timers, cpu);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
+
+        /* timers in the heap */
+        for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
+            t = ts->heap[j];
+            kdbp("  %d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+        /* timers on the link list */
+        for ( t = ts->list, j = 0; t != NULL; t = t->list_next, j++ ) {
+            kdbp(" L%d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+    }
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 -r e4b01842b71c xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/char/console.c	Fri Jun 08 10:56:24 2012 -0700
@@ -295,6 +295,21 @@ static void serial_rx(char c, struct cpu
 {
     static int switch_code_count = 0;
 
+#ifdef XEN_KDB_CONFIG
+    /* if ctrl-\ pressed and kdb handles it, return */
+    if (kdb_enabled && c == 0x1c) {
+        if (!kdb_session_begun) {
+            if (kdb_keyboard(regs))
+                return;
+        } else {
+            kdbp("Sorry... kdb session already active.. please try again..\n");
+            return;
+        }
+    }
+    if (kdb_session_begun)      /* kdb should already be polling */
+        return;                 /* swallow chars so they don't buffer in dom0 */
+#endif
+
     if ( switch_code && (c == switch_code) )
     {
         /* We eat CTRL-<switch_char> in groups of 3 to switch console input. */
@@ -710,6 +725,18 @@ void console_end_sync(void)
     atomic_dec(&print_everything);
 }
 
+#ifdef XEN_KDB_CONFIG
+void console_putc(char c)
+{
+    serial_putc(sercon_handle, c);
+}
+
+int console_getc(void)
+{
+    return serial_getc(sercon_handle);
+}
+#endif
+
 /*
  * printk rate limiting, lifted from Linux.
  *
diff -r 32034d1914a6 -r e4b01842b71c xen/include/asm-x86/debugger.h
--- a/xen/include/asm-x86/debugger.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/asm-x86/debugger.h	Fri Jun 08 10:56:24 2012 -0700
@@ -39,7 +39,11 @@
 #define DEBUGGER_trap_fatal(_v, _r) \
     if ( debugger_trap_fatal(_v, _r) ) return;
 
-#if defined(CRASH_DEBUG)
+#if defined(XEN_KDB_CONFIG)
+#define debugger_trap_immediate() kdb_trap_immed(KDB_TRAP_NONFATAL)
+#define debugger_trap_fatal(_v, _r) kdb_trap_fatal(_v, _r)
+
+#elif defined(CRASH_DEBUG)
 
 #include <xen/gdbstub.h>
 
@@ -70,6 +74,10 @@ static inline int debugger_trap_entry(
 {
     struct vcpu *v = current;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_handle_trap_entry(vector, regs))
+        return 1;
+#endif
     if ( guest_kernel_mode(v, regs) && v->domain->debugger_attached &&
          ((vector == TRAP_int3) || (vector == TRAP_debug)) )
     {
diff -r 32034d1914a6 -r e4b01842b71c xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/lib.h	Fri Jun 08 10:56:24 2012 -0700
@@ -116,4 +116,7 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+#ifdef XEN_KDB_CONFIG
+#include "../../kdb/include/kdb_extern.h"
+#endif
 #endif /* __LIB_H__ */
diff -r 32034d1914a6 -r e4b01842b71c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/sched.h	Fri Jun 08 10:56:24 2012 -0700
@@ -576,11 +576,14 @@ extern void (*dead_idle) (void);
 unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
-
+#ifdef XEN_KDB_CONFIG
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,5 @@
+
+obj-y		+= kdbmain.o kdb_cmds.o kdb_io.o 
+
+subdir-y += x86 guest
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/README	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,243 @@
+
+Welcome to kdb for xen, a hypervisor built in debugger.
+
+FEATURES:
+   - set breakpoints in hypervisor
+   - examine virt/machine memory, registers, domains, vcpus, etc...
+   - single step, single step till jump/call, step over call to next
+     instruction after the call.
+   - examine memory of a PV/HVM guest. 
+   - set breakpoints, single step, etc... for a PV guest.
+   - breaking into the debugger will freeze the system, all CPUs will pause,
+     no interrupts are acknowledged in the debugger. (Hence, the wall clock
+     will drift)
+   - single step will step only that cpu.
+   - earlykdb: break into kdb very early during boot. Put "earlykdb" on the
+               xen command line in grub.conf.
+   - generic tracing functions (see below) for quick tracing to debug timing
+     related problems. To use:
+        o set KDBTRCMAX to max num of recs in circular trc buffer in kdbmain.c
+	o call kdb_trc() from anywhere in xen
+	o turn tracing on by setting kdb_trcon in kdbmain.c or trcon command.
+	o trcp in kdb will give hints to dump trace recs. Use dd to see buffer
+	o trcz will zero out the entire buffer if needed.
+
+NOTE:
+   - since almost all numbers are in hex, 0x is not prefixed. Instead, decimal
+     numbers are preceded by $, as in $17 (sorry, one gets used to it). Note,
+     vcpu num, cpu num, domid are always displayed in decimal, without $.
+   - watchdog must be disabled to use kdb
+
+ISSUES:
+   - Currently, debug hypervisor is not supported. Make sure NDEBUG is defined
+     or compile with debug=n
+   - "timer went backwards" messages on dom0, but kdb/hyp should be fine.
+     I usually do "echo 2 > /proc/sys/kernel/printk" when using kdb.
+   - 32bit hypervisor may hang. Tested on 64bit hypervisor only.
+    
+
+TO BUILD:
+ - do >make kdb=y
+
+HOW TO USE:
+  1. A serial line is needed to use the debugger. Set up a serial line
+     from the source machine to target victim. Make sure the serial line
+     is working properly by displaying login prompt and loging in etc....
+
+  2. Add following to grub.conf:
+        kernel /xen.kdb console=com1,vga com1=57600,8n1 dom0_mem=542M
+
+        (57600 or whatever used in step 1 above)
+
+  3. Boot the hypervisor built with the debugger. 
+
+  4. ctrl-\ (ctrl and backslash) will break into the debugger. If the system is
+     badly hung, pressing NMI would also break into it. However, once kdb is
+     entered via NMI, normal execution can't continue.
+
+  5. type 'h' for list of commands.
+
+  6. Command line editing is limited to backspace. ctrl-c to start a new cmd.
+
+
+
+GUEST debug:
+  - type sym in the debugger
+  - for REL4, grep kallsyms_names, kallsyms_addresses, and kallsyms_num_syms
+    in the guest System.map* file. Run sym again with domid and the three
+    values on the command line.
+  - Now basic symbols can be used for guest debug. Note, if the binary is not
+    built with symbols, only function names are available, but not global vars.
+
+    Eg: sym 0 c0696084 c068a590 c0696080 c06b43e8 c06b4740
+        will set symbols for dom 0. Then :
+
+        [4]xkdb> bp some_function 0
+
+	wills set bp at some_function in dom 0
+
+	[3]xkdb> dw c068a590 32 0 : display 32 bytes of dom0 memory
+
+
+Tips:
+  - In "[0]xkdb>"  : 0 is the cpu number in decimal
+  - In
+      00000000c042645c: 0:do_timer+17                  push %ebp
+    0:do_timer : 0 is the domid in hex
+    offset +17 is in hex.
+
+    absense of 0: would indicate it's a hypervisor function
+
+  - commands starting with kdb (kdb*) are for kdb debug only.
+
+
+Finally,
+ - think hex.
+ - bug/problem: enter kdbdbg, reproduce, and send me the output.
+   If the output is not enough, I may ask to run kdbdbg twice, then collect
+   output.
+
+
+Thanks,
+Mukesh Rathor
+Oracle Corporatin, 
+Redwood Shores, CA 94065
+
+--------------------------------------------------------------------------------
+COMMAND DESCRIPTION:
+
+info:  Print basic info like version, compile flags, etc..
+
+cur:  print current domain id and vcpu id
+
+f: display current stack. If a vcpu ptr is given, then print stack for that
+   VCPU by using its IP and SP.
+
+fg: display stack for a guest given domid, SP and IP.
+
+dw: display words of memory. 'num' of bytes is optional, but if displaying guest
+    memory, then is required.
+
+dd: same as above, but display doublewords.
+
+dwm: same as above but the address is machine address instead of virtual.
+
+ddm: same as above, but display doublewords.
+
+dr: display registers. if 'sp' is specified then print few extra registers.
+
+drg: display guest context saved on stack bottom.
+
+dis: disassemble instructions. If disassembling for guest, then 'num' must
+     be specified. 'num' is number of instrs to display.
+
+dism: toggle disassembly mode between Intel and ATT/GAS.
+
+mw: modify word in memory given virtual address. 'domid' may be specified if
+    modifying guest memory. value is assumed in hex even without 0x.
+
+md: same as above but modify doubleword.
+
+mr: modify register. value is assumd hex.
+
+bc: clear given or all breakpoints
+
+bp: display breakpoints or set a breakpoint. Domid may be specified to set a bp
+    in guest. kdb functions may not be specified if debugging kdb.
+    Example:
+      xkdb> bp acpi_processor_idle  : will set bp in xen
+      xkdb> bp default_idle 0 :   will set bp in domid 0
+      xkdb> bp idle_cpu 9 :   will set bp in domid 9
+
+     Conditions may be specified for a bp: lhs == rhs or lhs != rhs
+     where : lhs is register like 'r6', 'rax', etc...  or memory location
+             rhs is hex value with or without leading 0x.
+     Thus,
+      xkdb> bp acpi_processor_idle rdi == c000 
+      xkdb> bp 0xffffffff80062ebc 0 rsi == ffff880021edbc98 : will break into
+            kdb at 0xffffffff80062ebc in dom0 when rsi is ffff880021edbc98 
+
+btp: break point trace. Upon bp, print some info and continue without stopping.
+   Ex: btp idle_cpu 7 rax rbx 0x20ef5a5 r9
+
+   will print: rax, rbx, *(long *)0x20ef5a5, r9 upon hitting idle_cpu() and 
+               continue.
+
+wp: set a watchpoint at a virtual address which can belong to hypervisor or
+    any guest. Do not specify wp in kdb path if debugging kdb.
+
+wc: clear given or all watchpoints.
+
+ni: single step, stepping over function calls.
+
+ss: single step. Be carefull when in interrupt handlers or context switches.
+    
+ssb: single step to branch. Use with care.
+
+go: leave kdb and continue.
+
+cpu: go back to orig cpu when entering kdb. If 'cpu number' given, then switch 
+     to that cpu. If 'all' then show status of all cpus.
+
+nmi: Only available in hung/crash state. Send NMI to a cpu that may be hung.
+
+sym: Initialize a symbol table for debugging a guest. Look into the System.map
+     file of guest for certain symbol values and provide them here.
+
+vcpuh: Given vcpu ptr, display hvm_vcpu struct.
+
+vcpu: Display current vcpu struct. If 'vcpu-ptr' given, display that vcpu.
+
+dom: display current domain. If 'domid' then display that domid. If 'all', then
+     display all domains.
+
+sched: show schedular info and run queues.
+
+mmu: print basic mmu info
+
+p2m: convert a gpfn to mfn given a domid. value in hex even without 0x.
+
+m2p: convert mfn to pfn. value in hex even without 0x.
+
+dpage: display struct page given a mfn or struct page ptr. Since, no info is 
+       kept on page type, we display all possible page types.
+
+dtrq: display timer queues.
+
+didt: dump IDT table.
+
+dgt: dump GDT table.
+
+dirq: display IRQ bindings.
+
+dvmc: display all or given dom/vcpu VMCS or VMCB.
+
+trcon: turn tracing on. Trace hooks must be added in xen and kdb function
+       called directly from there.
+
+trcoff: turn tracing off.
+
+trcz: zero trace buffer.
+
+trcp: give hints to print the circular trace buffer, like current active ptr.
+
+usr1: allows to add any arbitraty command quickly.
+
+--------------------------------------------------------------------------------
+/*
+ * Copyright (C) 2008 Oracle.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/guest/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y           := kdb_guest.o
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/guest/kdb_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/kdb_guest.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,342 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+/* information for symbols for a guest (includeing dom 0 ) is saved here */
+struct gst_syminfo {           /* guest symbols info */
+    int   domid;               /* which domain */
+    int   bitness;             /* 32 or 64 */
+    void *addrtblp;            /* ptr to (32/64)addresses tbl */
+    u8   *toktbl;              /* ptr to kallsyms_token_table */
+    u16  *tokidxtbl;           /* ptr to kallsyms_token_index */
+    u8   *kallsyms_names;      /* ptr to kallsyms_names */
+    long  kallsyms_num_syms;   /* ptr to kallsyms_num_syms */
+    kdbva_t  stext;            /* value of _stext in guest */
+    kdbva_t  etext;            /* value of _etext in guest */
+    kdbva_t  sinittext;        /* value of _sinittext in guest */
+    kdbva_t  einittext;        /* value of _einittext in guest */
+};
+
+#define MAX_CACHE 16                              /* cache upto 16 guests */
+struct gst_syminfo gst_syminfoa[MAX_CACHE];       /* guest symbol info array */
+
+static struct gst_syminfo *
+kdb_get_syminfo_slot(void)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].addrtblp == NULL)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+static struct gst_syminfo *
+kdb_domid2syminfop(domid_t domid)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].domid == domid)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+/* check if an address looks like text address in guest */
+int
+kdb_is_addr_guest_text(kdbva_t addr, int domid)
+{
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    if (!gp || !gp->stext || !gp->etext)
+        return 0;
+    KDBGP1("guestaddr: addr:%lx domid:%d\n", addr, domid);
+
+    return ( (addr >= gp->stext && addr <= gp->etext) ||
+             (addr >= gp->sinittext && addr <= gp->einittext) );
+}
+
+/*
+ * returns: value of kallsyms_addresses[idx];
+ */
+static kdbva_t
+kdb_rd_guest_addrtbl(struct gst_syminfo *gp, int idx)
+{
+    kdbva_t addr, retaddr=0;
+    int num = gp->bitness/8;       /* whether 4 byte or 8 byte ptrs */
+    domid_t id = gp->domid;
+
+    addr = (kdbva_t)(((char *)gp->addrtblp) + idx * num);
+    KDBGP1("rdguestaddrtbl:addr:%lx idx:%d\n", addr, idx);
+
+    if (kdb_read_mem(addr, (kdbbyt_t *)&retaddr,num,id) != num) {
+        kdbp("Can't read addrtbl domid:%d at:%lx\n", id, addr);
+        return 0;
+    }
+    KDBGP1("rdguestaddrtbl:exit:retaddr:%lx\n", retaddr);
+    return retaddr;
+}
+
+/* Based on el5 kallsyms.c file. */
+static unsigned int 
+kdb_expand_el5_sym(struct gst_syminfo *gp, unsigned int off, char *result)
+{   
+    int len, skipped_first = 0;
+    u8 u8idx, *tptr, *datap;
+    domid_t domid = gp->domid;
+
+    *result = '\0';
+
+    /* get the compressed symbol length from the first symbol byte */
+    datap = gp->kallsyms_names + off;
+    len = 0;
+    if ((kdb_read_mem((kdbva_t)datap, (kdbbyt_t *)&len, 1, domid)) != 1) {
+        KDBGP("failed to read guest memory\n");
+        return 0;
+    }
+    datap++;
+
+    /* update the offset to return the offset for the next symbol on
+     * the compressed stream */
+    off += len + 1;
+
+    /* for every byte on the compressed symbol data, copy the table
+     * entry for that byte */
+    while(len) {
+        u16 u16idx, *u16p;
+        if (kdb_read_mem((kdbva_t)datap,(kdbbyt_t *)&u8idx,1,domid)!=1){
+            kdbp("memory (u8idx) read error:%p\n",gp->tokidxtbl);
+            return 0;
+        }
+        u16p = u8idx + gp->tokidxtbl;
+        if (kdb_read_mem((kdbva_t)u16p,(kdbbyt_t *)&u16idx,2,domid)!=2){
+            kdbp("tokidxtbl read error:%p\n", u16p);
+            return 0;
+        }
+        tptr = gp->toktbl + u16idx;
+        datap++;
+        len--;
+
+        while ((kdb_read_mem((kdbva_t)tptr, (kdbbyt_t *)&u8idx, 1, domid)==1) &&
+               u8idx) {
+
+            if(skipped_first) {
+                *result = u8idx;
+                result++;
+            } else
+                skipped_first = 1;
+            tptr++;
+        }
+    }
+    *result = '\0';
+    return off;          /* return to offset to the next symbol */
+}
+
+#define EL4_NMLEN 127
+/* so much pain, so not sure of it's worth .. :).. */
+static kdbva_t
+kdb_expand_el4_sym(struct gst_syminfo *gp, int low, char *result, char *symp)
+{   
+    int i, j;
+    u8 *nmp = gp->kallsyms_names;       /* guest address space */
+    kdbbyt_t byte, prefix;
+    domid_t id = gp->domid;
+    kdbva_t addr;
+
+    KDBGP1("Eel4sym:nmp:%p maxidx:$%d sym:%s\n", nmp, low, symp);
+    for (i=0; i <= low; i++) {
+        /* unsigned prefix = *name++; */
+        if (kdb_read_mem((kdbva_t)nmp, &prefix, 1, id) != 1) {
+            kdbp("failed to read:%p domid:%x\n", nmp, id);
+            return 0;
+        }
+        KDBGP2("el4:i:%d prefix:%x\n", i, prefix);
+        nmp++;
+        /* strncpy(namebuf + prefix, name, KSYM_NAME_LEN - prefix); */
+        addr = (long)result + prefix;
+        for (j=0; j < EL4_NMLEN-prefix; j++) {
+            if (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) != 1) {
+                kdbp("failed read:%p domid:%x\n", nmp, id);
+                return 0;
+            }
+            KDBGP2("el4:j:%d byte:%x\n", j, byte);
+            *(kdbbyt_t *)addr = byte;
+            addr++; nmp++;
+            if (byte == '\0')
+                break;
+        }
+        KDBGP2("el4sym:i:%d res:%s\n", i, result);
+        if (symp && strcmp(result, symp) == 0)
+            return(kdb_rd_guest_addrtbl(gp, i));
+
+        /* kallsyms.c: name += strlen(name) + 1; */
+        if (j == EL4_NMLEN-prefix && byte != '\0')
+            while (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) && byte != '\0')
+                nmp++;
+    }
+    KDBGP1("Xel4sym: na-ga-da\n");
+    return 0;
+}
+
+static unsigned int
+kdb_get_el5_symoffset(struct gst_syminfo *gp, long pos)
+{
+    int i;
+    u8 data, *namep;
+    domid_t domid = gp->domid;
+
+    namep = gp->kallsyms_names;
+    for (i=0; i < pos; i++) {
+        if (kdb_read_mem((kdbva_t)namep, &data, 1, domid) != 1) {
+            kdbp("Can't read id:$%d mem:%p\n", domid, namep);
+            return 0;
+        }
+        namep = namep + data + 1;
+    }
+    return namep - gp->kallsyms_names;
+}
+
+/*
+ * for a given guest domid (domid >= 0 && < KDB_HYPDOMID), convert addr to
+ * symbol. offset is set to  addr - symbolstart
+ */
+char *
+kdb_guest_addr2sym(unsigned long addr, domid_t domid, ulong *offsp)
+{
+    static char namebuf[KSYM_NAME_LEN+1];
+    unsigned long low, high, mid;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    *offsp = 0;
+    if(!gp || gp->kallsyms_num_syms == 0)
+        return " ??? ";
+
+    namebuf[0] = namebuf[KSYM_NAME_LEN] = '\0';
+    if (1) {
+        /* do a binary search on the sorted kallsyms_addresses array */
+        low = 0;
+        high = gp->kallsyms_num_syms;
+
+        while (high-low > 1) {
+            mid = (low + high) / 2;
+            if (kdb_rd_guest_addrtbl(gp, mid) <= addr) 
+                low = mid;
+            else 
+                high = mid;
+        }
+        /* Grab name */
+        if (gp->toktbl) {
+            int symoff = kdb_get_el5_symoffset(gp,low);
+            kdb_expand_el5_sym(gp, symoff, namebuf);
+        } else
+            kdb_expand_el4_sym(gp, low, namebuf, NULL);
+        *offsp = addr - kdb_rd_guest_addrtbl(gp, low);
+        return namebuf;
+    }
+    return " ???? ";
+}
+
+
+/* 
+ * save guest (dom0 and others) symbols info : domid and following addresses:
+ *     &kallsyms_names &kallsyms_addresses &kallsyms_num_syms \
+ *     &kallsyms_token_table &kallsyms_token_index
+ */
+void
+kdb_sav_dom_syminfo(domid_t domid, long namesp, long addrap, long nump,
+                    long toktblp, long tokidxp)
+{
+    int bytes;
+    long val = 0;    /* must be set to zero for 32 on 64 cases */
+    struct gst_syminfo *gp = kdb_get_syminfo_slot();
+
+    if (gp == NULL) {
+        kdbp("kdb:kdb_sav_dom_syminfo():Table full.. symbols not saved\n");
+        return;
+    }
+    memset(gp, 0, sizeof(*gp));
+
+    gp->domid = domid;
+    gp->bitness = kdb_guest_bitness(domid);
+    gp->addrtblp = (void *)addrap;
+    gp->kallsyms_names = (u8 *)namesp;
+    gp->toktbl = (u8 *)toktblp;
+    gp->tokidxtbl = (u16 *)tokidxp;
+
+    KDBGP("domid:%x bitness:$%d numsyms:$%ld arrayp:%p\n", domid,
+          gp->bitness, gp->kallsyms_num_syms, gp->addrtblp);
+
+    bytes = gp->bitness/8;
+    if (kdb_read_mem(nump, (kdbbyt_t *)&val, bytes, domid) != bytes) {
+
+        kdbp("Unable to read number of symbols from:%lx\n", nump);
+        memset(gp, 0, sizeof(*gp));
+        return;
+    } else
+        kdbp("Number of symbols:$%ld\n", val);
+
+    gp->kallsyms_num_syms = val;
+
+    bytes = (gp->bitness/8) * gp->kallsyms_num_syms;
+    gp->stext = kdb_guest_sym2addr("_stext", domid);
+    gp->etext = kdb_guest_sym2addr("_etext", domid);
+    if (!gp->stext || !gp->etext)
+        kdbp("Warn: Can't find stext/etext\n");
+
+    if (gp->toktbl && gp->tokidxtbl) {
+        gp->sinittext = kdb_guest_sym2addr("_sinittext", domid);
+        gp->einittext = kdb_guest_sym2addr("_einittext", domid);
+        if (!gp->sinittext || !gp->einittext) {
+            kdbp("Warn: Can't find sinittext/einittext\n");
+    } 
+    }
+    KDBGP1("stxt:%lx etxt:%lx sitxt:%lx eitxt:%lx\n", gp->stext, gp->etext,
+           gp->sinittext, gp->einittext);
+    kdbp("Succesfully saved symbol info\n");
+}
+
+/*
+ * given a symbol string for a guest/domid, return its address
+ */
+kdbva_t
+kdb_guest_sym2addr(char *symp, domid_t domid)
+{
+    char namebuf[KSYM_NAME_LEN+1];
+    int i, off=0;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    KDBGP("sym2a: sym:%s domid:%x numsyms:%ld\n", symp, domid,
+          gp ? gp->kallsyms_num_syms: -1);
+
+    if (!gp)
+        return 0;
+
+    if (gp->toktbl == 0 || gp->tokidxtbl == 0)
+        return(kdb_expand_el4_sym(gp, gp->kallsyms_num_syms, namebuf, symp));
+
+    for (i=0; i < gp->kallsyms_num_syms; i++) {
+        off = kdb_expand_el5_sym(gp, off, namebuf);
+        KDBGP1("i:%d namebuf:%s\n", i, namebuf);
+        if (strcmp(namebuf, symp) == 0) {
+            return(kdb_rd_guest_addrtbl(gp, i));
+        }
+    }
+    KDBGP("sym2a:exit:na-ga-da\n");
+    return 0;
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdb_extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdb_extern.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDB_EXTERN_H
+#define _KDB_EXTERN_H
+
+#define KDB_TRAP_FATAL     1    /* trap is fatal. can't resume from kdb */
+#define KDB_TRAP_NONFATAL  2    /* can resume from kdb */
+#define KDB_TRAP_KDBSTACK  3    /* to debug kdb itself. dump kdb stack */
+
+/* following can be called from anywhere in xen to debug */
+extern void kdb_trap_immed(int);
+extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
+extern void kdbp(const char *fmt, ...);
+
+typedef unsigned long kdbva_t;
+typedef unsigned char kdbbyt_t;
+typedef unsigned long kdbma_t;
+
+extern unsigned long kdb_dr7;
+
+
+extern volatile int kdb_session_begun;
+extern volatile int kdb_enabled;
+extern void kdb_init(void);
+extern int kdb_keyboard(struct cpu_user_regs *);
+extern void kdb_ssni_reenter(struct cpu_user_regs *);
+extern int kdb_handle_trap_entry(int, struct cpu_user_regs *);
+extern int kdb_trap_fatal(int, struct cpu_user_regs *);  /* fatal with regs */
+extern void kdb_dump_vmcs(uint16_t did, int vid);
+void kdb_dump_vmcb(uint16_t did, int vid);
+extern void kdb_dump_time_pcpu(void);
+
+
+#define VMPTRST_OPCODE  ".byte 0x0f,0xc7\n"     /* reg/opcode: /7 */
+#define MODRM_EAX_07    ".byte 0x38\n"          /* [EAX], with reg/opcode: /7 */
+static inline void __vmptrst(u64 *addr)
+{
+    asm volatile ( VMPTRST_OPCODE
+                   MODRM_EAX_07
+                   :
+                   : "a" (addr)
+                   : "memory");
+}
+
+extern void mukchk(unsigned long);
+#define is_hvm_or_hyb_domain is_hvm_domain
+#define is_hvm_or_hyb_vcpu is_hvm_vcpu
+
+
+#endif  /* _KDB_EXTERN_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdbdefs.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbdefs.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBDEFS_H
+#define _KDBDEFS_H
+
+/* reason we are entering kdbmain (bp == breakpoint) */
+typedef enum {
+    KDB_REASON_KEYBOARD=1,  /* Keyboard entry - always 1 */
+    KDB_REASON_BPEXCP,      /* #BP excp: sw bp (INT3) */
+    KDB_REASON_DBEXCP,      /* #DB excp: TF flag or HW bp */
+    KDB_REASON_PAUSE_IPI,   /* received pause IPI from another CPU */
+} kdb_reason_t;
+
+
+/* cpu state: past, present, and future */
+typedef enum {
+    KDB_CPU_INVAL=0,     /* invalid value. not in or leaving kdb */
+    KDB_CPU_QUIT,        /* main cpu does GO. all others do QUIT */
+    KDB_CPU_PAUSE,       /* cpu is paused */
+    KDB_CPU_DISABLE,     /* disable interrupts */
+    KDB_CPU_SHOWPC,      /* all cpus must display their pc */
+    KDB_CPU_DO_VMEXIT,   /* all cpus must do vmcs vmexit. intel only */
+    KDB_CPU_MAIN_KDB,    /* cpu in kdb main command loop */
+    KDB_CPU_GO,          /* user entered go for this cpu */
+    KDB_CPU_SS,          /* single step for this cpu */
+    KDB_CPU_NI,          /* go to next instr after the call instr */
+    KDB_CPU_INSTALL_BP,  /* delayed install of sw bp(s) by this cpu */
+} kdb_cpu_cmd_t;
+
+/* ============= kdb commands ============================================= */
+
+typedef kdb_cpu_cmd_t (*kdb_func_t)(int, const char **, struct cpu_user_regs *);
+typedef kdb_cpu_cmd_t (*kdb_usgf_t)(void);
+
+typedef enum {
+    KDB_REPEAT_NONE = 0,    /* Do not repeat this command */
+    KDB_REPEAT_NO_ARGS,     /* Repeat the command without arguments */
+    KDB_REPEAT_WITH_ARGS,   /* Repeat the command including its arguments */
+} kdb_repeat_t;
+
+typedef struct _kdbtab {
+    char        *kdb_cmd_name;        /* Command name */
+    kdb_func_t   kdb_cmd_func;        /* ptr to function to execute command */
+    kdb_usgf_t   kdb_cmd_usgf;        /* usage function ptr */
+    int          kdb_cmd_crash_avail; /* available in sys fatal/crash state */
+    kdb_repeat_t kdb_cmd_repeat;      /* Does command auto repeat on enter? */
+} kdbtab_t;
+
+
+/* ============= types and stuff ========================================= */
+#define BFD_INVAL (~0UL)            /* invalid bfd_vma */
+
+#if defined(__x86_64__)
+  #define KDBIP rip
+  #define KDBSP rsp
+#else
+  #define KDBIP eip
+  #define KDBSP esp
+#endif
+
+/* ============= macros ================================================== */
+extern volatile int kdbdbg;
+#define KDBGP(...) {(kdbdbg) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP3(...) {0;};
+
+#define KDBMIN(x,y) (((x)<(y))?(x):(y))
+
+#endif  /* !_KDBDEFS_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdbinc.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbinc.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBINC_H
+#define _KDBINC_H
+
+#include <xen/compile.h>
+#include <xen/config.h>
+#include <xen/version.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/mm.h>
+#include <xen/event.h>
+#include <xen/time.h>
+#include <xen/console.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/rangeset.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/delay.h>
+#include <xen/shutdown.h>
+#include <xen/percpu.h>
+#include <xen/multicall.h>
+#include <xen/rcupdate.h>
+#include <xen/ctype.h>
+#include <xen/symbols.h>
+#include <xen/shutdown.h>
+#include <xen/serial.h>
+#include <xen/grant_table.h>
+#include <asm/debugger.h>
+#include <asm/shared.h>
+#include <asm/apicdef.h>
+
+#include <asm/nmi.h>
+#include <asm/p2m.h>
+#include <asm/debugreg.h>
+#include <public/sched.h>
+#include <public/vcpu.h>
+#ifdef _XEN_LATEST
+#include <xsm/xsm.h>
+#endif
+
+#include <asm/hvm/vmx/vmx.h>
+
+#include "kdb_extern.h"
+#include "kdbdefs.h"
+#include "kdbproto.h"
+
+#endif /* !_KDBINC_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/include/kdbproto.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbproto.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBPROTO_H
+#define _KDBPROTO_H
+
+/* hypervisor interfaces use by kdb or kdb interfaces in xen files */
+extern void console_putc(char);
+extern int console_getc(void);
+extern void show_trace(struct cpu_user_regs *);
+extern void kdb_dump_timer_queues(void);
+extern void kdb_time_resume(int);
+extern void kdb_print_sched_info(void);
+extern void kdb_curr_cpu_flush_vmcs(void);
+extern unsigned long address_lookup(char *);
+extern void kdb_prnt_guest_mapped_irqs(void);
+
+/* kdb globals */
+extern kdbtab_t *kdb_cmd_tbl;
+extern char kdb_prompt[32];
+extern volatile int kdb_sys_crash;
+extern volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+extern volatile int kdb_trcon;
+
+/* kdb interfaces */
+extern void __init kdb_io_init(void);
+extern void kdb_init_cmdtab(void);
+extern void kdb_do_cmds(struct cpu_user_regs *);
+extern int kdb_check_sw_bkpts(struct cpu_user_regs *);
+extern int kdb_check_watchpoints(struct cpu_user_regs *);
+extern void kdb_do_watchpoints(kdbva_t, int, int);
+extern void kdb_install_watchpoints(void);
+extern void kdb_clear_wps(int);
+extern kdbma_t kdb_rd_dbgreg(int);
+
+
+
+extern char *kdb_get_cmdline(char *);
+extern void kdb_clear_prev_cmd(void);
+extern void kdb_toggle_dis_syntax(void);
+extern int kdb_check_call_instr(domid_t, kdbva_t);
+extern void kdb_display_pc(struct cpu_user_regs *);
+extern kdbva_t kdb_print_instr(kdbva_t, long, domid_t);
+extern int kdb_read_mmem(kdbva_t, kdbbyt_t *, int);
+extern int kdb_read_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+extern int kdb_write_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+
+extern void kdb_install_all_swbp(void);
+extern void kdb_uninstall_all_swbp(void);
+extern int kdb_swbp_exists(void);
+extern void kdb_flush_swbp_table(void);
+extern int kdb_is_addr_guest_text(kdbva_t, int);
+extern kdbva_t kdb_guest_sym2addr(char *, domid_t);
+extern char *kdb_guest_addr2sym(unsigned long, domid_t, ulong *);
+extern void kdb_prnt_addr2sym(domid_t, kdbva_t, char *);
+extern void kdb_sav_dom_syminfo(domid_t, long, long, long, long, long);
+extern int kdb_guest_bitness(domid_t);
+extern void kdb_nmi_pause_cpus(cpumask_t);
+
+extern void kdb_trczero(void);
+void kdb_trcp(void);
+
+
+
+#endif /* !_KDBPROTO_H */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/kdb_cmds.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_cmds.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3769 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+#if defined(__x86_64__)
+    #define KDBF64 "%lx"
+    #define KDBFL "%016lx"         /* print long all digits */
+#else
+    #define KDBF64 "%llx"
+    #define KDBFL "%08lx"
+#endif
+
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    #define KDB_LKDEF(l) ((l).raw.lock)
+    #define KDB_PGLLE(t) ((t).tail)    /* page list last element ^%$#@ */
+#else
+    #define KDB_LKDEF(l) ((l).lock)
+    #define KDB_PGLLE(t) ((t).prev)    /* page list last element ^%$#@ */
+#endif
+
+#define KDB_CMD_HISTORY_COUNT   32
+#define CMD_BUFLEN              200     /* kdb_printf: max printline == 256 */
+
+#define KDBMAXSBP 16                    /* max number of software breakpoints */
+#define KDB_MAXARGC 16                  /* max args in a kdb command */
+#define KDB_MAXBTP  8                   /* max display args in btp */
+
+/* condition is: 'r6 == 0x123f' or '0xffffffff82800000 != deadbeef'  */
+struct kdb_bpcond {
+    kdbbyt_t bp_cond_status;       /* 0 == off, 1 == register, 2 == memory */
+    kdbbyt_t bp_cond_type;         /* 0 == bad, 1 == equal, 2 == not equal */
+    ulong    bp_cond_lhs;          /* lhs of condition: reg offset or mem loc */
+    ulong    bp_cond_rhs;          /* right hand side of condition */
+};
+
+/* software breakpoint structure */
+struct kdb_sbrkpt {
+    kdbva_t  bp_addr;              /* address the bp is set at */
+    domid_t  bp_domid;             /* which domain the bp belongs to */
+    kdbbyt_t bp_originst;          /* save orig instr/s here */
+    kdbbyt_t bp_deleted;           /* delete pending on this bp */
+    kdbbyt_t bp_ni;                /* set for KDB_CPU_NI */
+    kdbbyt_t bp_just_added;        /* added in the current kdb session */
+    kdbbyt_t bp_type;              /* 0 = normal, 1 == cond,  2 == btp */
+    union {
+        struct kdb_bpcond bp_cond;
+        ulong *bp_btp;
+    } u;
+};
+
+/* don't use kmalloc in kdb which hijacks all cpus */
+static ulong kdb_btp_argsa[KDBMAXSBP][KDB_MAXBTP];
+static ulong *kdb_btp_ap[KDBMAXSBP];
+
+static struct kdb_reg_nmofs {
+    char *reg_nm;
+    int reg_offs;
+} kdb_reg_nm_offs[] =  {
+       { "rax", offsetof(struct cpu_user_regs, rax) },
+       { "rbx", offsetof(struct cpu_user_regs, rbx) },
+       { "rcx", offsetof(struct cpu_user_regs, rcx) },
+       { "rdx", offsetof(struct cpu_user_regs, rdx) },
+       { "rsi", offsetof(struct cpu_user_regs, rsi) },
+       { "rdi", offsetof(struct cpu_user_regs, rdi) },
+       { "rbp", offsetof(struct cpu_user_regs, rbp) },
+       { "rsp", offsetof(struct cpu_user_regs, rsp) },
+       { "r8",  offsetof(struct cpu_user_regs, r8) },
+       { "r9",  offsetof(struct cpu_user_regs, r9) },
+       { "r10", offsetof(struct cpu_user_regs, r10) },
+       { "r11", offsetof(struct cpu_user_regs, r11) },
+       { "r12", offsetof(struct cpu_user_regs, r12) },
+       { "r13", offsetof(struct cpu_user_regs, r13) },
+       { "r14", offsetof(struct cpu_user_regs, r14) },
+       { "r15", offsetof(struct cpu_user_regs, r15) },
+       { "rflags", offsetof(struct cpu_user_regs, rflags) } };
+
+static const int KDBBPSZ=1;                   /* size of KDB_BPINST is 1 byte*/
+static kdbbyt_t kdb_bpinst = 0xcc;            /* breakpoint instr: INT3 */
+static struct kdb_sbrkpt kdb_sbpa[KDBMAXSBP]; /* soft brkpt array/table */
+static kdbtab_t *tbp;
+
+static int kdb_set_bp(domid_t, kdbva_t, int, ulong *, char*, char*, char*);
+static void kdb_print_uregs(struct cpu_user_regs *);
+
+
+/* ===================== cmdline functions  ================================ */
+
+/* lp points to a string of only alpha numeric chars terminated by '\n'.
+ * Parse the string into argv pointers, and RETURN argc
+ * Eg:  if lp --> "dr  sp\n" :  argv[0]=="dr\0"  argv[1]=="sp\0"  argc==2
+ */
+static int
+kdb_parse_cmdline(char *lp, const char **argv)
+{
+    int i=0;
+
+    for (; *lp == ' '; lp++);      /* note: isspace() skips '\n' also */
+    while ( *lp != '\n' ) {
+        if (i == KDB_MAXARGC) {
+            printk("kdb: max args exceeded\n");
+            break;
+        }
+        argv[i++] = lp;
+        for (; *lp != ' ' && *lp != '\n'; lp++);
+        if (*lp != '\n')
+            *lp++ = '\0';
+        for (; *lp == ' '; lp++);
+    }
+    *lp = '\0';
+    return i;
+}
+
+void
+kdb_clear_prev_cmd()             /* so previous command is not repeated */
+{
+    tbp = NULL;
+}
+
+void
+kdb_do_cmds(struct cpu_user_regs *regs)
+{
+    char *cmdlinep;
+    const char *argv[KDB_MAXARGC];
+    int argc = 0, curcpu = smp_processor_id();
+    kdb_cpu_cmd_t result = KDB_CPU_MAIN_KDB;
+
+    snprintf(kdb_prompt, sizeof(kdb_prompt), "[%d]xkdb> ", curcpu);
+
+    while (result == KDB_CPU_MAIN_KDB) {
+        cmdlinep = kdb_get_cmdline(kdb_prompt);
+        if (*cmdlinep == '\n') {
+            if (tbp==NULL || tbp->kdb_cmd_func==NULL)
+                continue;
+            else
+                argc = -1;    /* repeat prev command */
+        } else {
+            argc = kdb_parse_cmdline(cmdlinep, argv);
+            for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_func; tbp++)  {
+                if (strcmp(argv[0], tbp->kdb_cmd_name)==0) 
+                    break;
+            }
+        }
+        if (kdb_sys_crash && tbp->kdb_cmd_func && !tbp->kdb_cmd_crash_avail) {
+            kdbp("cmd not available in fatal/crashed state....\n");
+            continue;
+        }
+        if (tbp->kdb_cmd_func) {
+            result = (*tbp->kdb_cmd_func)(argc, argv, regs);
+            if (tbp->kdb_cmd_repeat == KDB_REPEAT_NONE)
+                tbp = NULL;
+        } else
+            kdbp("kdb: Unknown cmd: %s\n", cmdlinep);
+    }
+    kdb_cpu_cmd[curcpu] = result;
+    return;
+}
+
+/* ===================== Util functions  ==================================== */
+
+int
+kdb_vcpu_valid(struct vcpu *in_vp)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    for(dp=domain_list; in_vp && dp; dp=dp->next_in_list)
+        for_each_vcpu(dp, vp)
+            if (in_vp == vp)
+                return 1;
+    return 0;     /* not found */
+}
+
+/*
+ * Given a symbol, find it's address
+ */
+static kdbva_t
+kdb_sym2addr(const char *p, domid_t domid)
+{
+    kdbva_t addr;
+
+    KDBGP1("sym2addr: p:%s domid:%d\n", p, domid);
+    if (domid == DOMID_IDLE)
+        addr = address_lookup((char *)p);
+    else
+        addr = (kdbva_t)kdb_guest_sym2addr((char *)p, domid);
+    KDBGP1("sym2addr: exit: addr returned:0x%lx\n", addr);
+    return addr;
+}
+
+/*
+ * convert ascii to int decimal (base 10). 
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2deci(const char *strp, int *intp)
+{
+    const char *endp;
+
+    KDBGP2("str2deci: str:%s\n", strp);
+    if (!isdigit(*strp))
+        return 0;
+    *intp = (int)simple_strtoul(strp, &endp, 10);
+    if (endp != strp+strlen(strp))
+        return 0;
+    KDBGP2("str2deci: intval:$%d\n", *intp);
+    return 1;
+}
+/*
+ * convert ascii to long. NOTE: base is 16
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2ulong(const char *strp, ulong *longp)
+{
+    ulong val;
+    const char *endp;
+
+    KDBGP2("str2long: str:%s\n", strp);
+    if (!isxdigit(*strp))
+        return 0;
+    val = (long)simple_strtoul(strp, &endp, 16);   /* handles leading 0x */
+    if (endp != strp+strlen(strp))
+        return 0;
+    if (longp)
+        *longp = val;
+    KDBGP2("str2long: val:0x%lx\n", val);
+    return 1;
+}
+/*
+ * convert a symbol or ascii address to hex address
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2addr(const char *strp, kdbva_t *addrp, domid_t id)
+{
+    kdbva_t addr;
+    const char *endp;
+
+    /* assume it's an address */
+    KDBGP2("str2addr: str:%s id:%d\n", strp, id);
+    addr = (kdbva_t)simple_strtoul(strp, &endp, 16); /*handles leading 0x */
+    if (endp != strp+strlen(strp))
+        if ( !(addr=kdb_sym2addr(strp, id)) )
+            return 0;
+    *addrp = addr;
+    KDBGP2("str2addr: addr:0x%lx\n", addr);
+    return 1;
+}
+
+/* Given domid, return ptr to struct domain 
+ * IF domid == DOMID_IDLE return ptr to idle_domain 
+ * IF domid == valid domain, return ptr to domain struct
+ * else domid is bad and return NULL
+ */
+static struct domain *
+kdb_domid2ptr(domid_t domid)
+{
+    struct domain *dp;
+
+    /* get_domain_by_id() ret NULL for both DOMID_IDLE and bad domids */
+    if (domid == DOMID_IDLE)
+        dp = idle_vcpu[smp_processor_id()]->domain;
+    else 
+        dp = get_domain_by_id(domid);   /* NULL now means bad domid */
+    return dp;
+}
+
+/*
+ * Returns:  0: failed. invalid domid or string, *idp not changed.
+ */
+static int
+kdb_str2domid(const char *domstr, domid_t *idp, int perr)
+{
+    int id;
+    if (!kdb_str2deci(domstr, &id) || !kdb_domid2ptr((domid_t)id)) {
+        if (perr)
+            kdbp("Invalid domid:%s\n", domstr);
+        return 0;
+    }
+    *idp = (domid_t)id;
+    return 1;
+}
+
+static struct domain *
+kdb_strdomid2ptr(const char *domstr, int perror)
+{
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
+}
+
+/* return a guest bitness: 32 or 64 */
+int
+kdb_guest_bitness(domid_t domid)
+{
+    const int HYPSZ = sizeof(long) * 8;
+    struct domain *dp = kdb_domid2ptr(domid);
+    int retval; 
+
+    if (is_idle_domain(dp))
+        retval = HYPSZ;
+    else if (is_hvm_or_hyb_domain(dp))
+        retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
+    else 
+        retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
+    KDBGP1("gbitness: domid:%d dp:%p bitness:%d\n", domid, dp, retval);
+    return retval;
+}
+
+/* kdb_print_spin_lock(&xyz_lock, "xyz_lock:", "\n"); */
+static void
+kdb_print_spin_lock(char *strp, spinlock_t *lkp, char *nlp)
+{
+    kdbp("%s %04hx %d %d%s", strp, KDB_LKDEF(*lkp), lkp->recurse_cpu,
+         lkp->recurse_cnt, nlp);
+}
+
+/* check if register string is valid. if yes, return offset to the register
+ * in cpu_user_regs, else return -1 */
+static int
+kdb_valid_reg(const char *nmp) 
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (strcmp(kdb_reg_nm_offs[i].reg_nm, nmp) == 0)
+            return kdb_reg_nm_offs[i].reg_offs;
+    return -1;
+}
+
+/* given offset of register, return register name string. if offset is invalid
+ * return NULL */
+static char *kdb_regoffs_to_name(int offs)
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (kdb_reg_nm_offs[i].reg_offs == offs)
+            return kdb_reg_nm_offs[i].reg_nm;
+    return NULL;
+}
+
+/* ===================== util struct funcs ================================= */
+static void
+kdb_prnt_timer(struct timer *tp)
+{
+#if XEN_SUBVERSION == 0 
+    kdbp(" expires:%016lx expires_end:%016lx cpu:%d status:%x\n", tp->expires, 
+         tp->expires_end, tp->cpu, tp->status);
+#else
+    kdbp(" expires:%016lx cpu:%d status:%x\n", tp->expires, tp->cpu,tp->status);
+#endif
+    kdbp(" function data:%p ptr:%p ", tp->data, tp->function);
+    kdb_prnt_addr2sym(DOMID_IDLE, (kdbva_t)tp->function, "\n");
+}
+
+static void 
+kdb_prnt_periodic_time(struct periodic_time *ptp)
+{
+    kdbp(" next:%p prev:%p\n", ptp->list.next, ptp->list.prev);
+    kdbp(" on_list:%d one_shot:%d dont_freeze:%d irq_issued:%d src:%x irq:%x\n",
+         ptp->on_list, ptp->one_shot, ptp->do_not_freeze, ptp->irq_issued,
+         ptp->source, ptp->irq);
+    kdbp(" vcpu:%p pending_intr_nr:%08x period:%016lx\n", ptp->vcpu,
+         ptp->pending_intr_nr, ptp->period);
+    kdbp(" scheduled:%016lx last_plt_gtime:%016lx\n", ptp->scheduled,
+         ptp->last_plt_gtime);
+    kdbp(" \n          timer info:\n");
+    kdb_prnt_timer(&ptp->timer);
+    kdbp("\n");
+}
+
+/* ===================== cmd functions  ==================================== */
+
+/*
+ * FUNCTION: Disassemble instructions
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dis(void)
+{
+    kdbp("dis [addr|sym][num][domid] : Disassemble instrs\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dis(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int num = 8;                           /* display 8 instr by default */
+    static kdbva_t addr = BFD_INVAL;
+    static domid_t domid;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dis();
+
+    if (argc != -1)      /* not a command repeat */
+        domid = guest_mode(regs) ?  current->domain->domain_id : DOMID_IDLE;
+
+    if (argc >= 4 && !kdb_str2domid(argv[3], &domid, 1)) { 
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc >= 3 && !kdb_str2deci(argv[2], &num)) {
+        kdbp("kdb:Invalid num\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc > 1 && !kdb_str2addr(argv[1], &addr, domid)) {
+        kdbp("kdb:Invalid addr/sym\n");
+        kdbp("(num has to be specified if providing domid)\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc == 1)                    /* not command repeat */
+        addr = regs->KDBIP;           /* PC is the default */
+    else if (addr == BFD_INVAL) {
+        kdbp("kdb:Invalid addr/sym\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    addr = kdb_print_instr(addr, num, domid);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* FUNCTION: kdb_cmdf_dism() Toggle disassembly syntax from Intel to ATT/GAS */
+static kdb_cpu_cmd_t
+kdb_usgf_dism(void)
+{
+    kdbp("dism: toggle disassembly mode between ATT/GAS and INTEL\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dism(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dism();
+
+    kdb_toggle_dis_syntax();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+_kdb_show_guest_stack(domid_t domid, kdbva_t ipaddr, kdbva_t spaddr)
+{
+    kdbva_t val;
+    int num=0, max=0, rd = kdb_guest_bitness(domid)/8;
+
+    kdb_print_instr(ipaddr, 1, domid);
+    KDBGP("_guest_stack:sp:%lx domid:%d rd:$%d\n", spaddr, domid, rd);
+    val = 0;                          /* must zero, in case guest is 32bit */
+    while((kdb_read_mem(spaddr,(kdbbyt_t *)&val,rd,domid)==rd) && num < 16){
+        KDBGP1("gstk:addr:%lx val:%lx\n", spaddr, val);
+        if (kdb_is_addr_guest_text(val, domid)) {
+            kdb_print_instr(val, 1, domid);
+            num++;
+        }
+        if (max++ > 10000)            /* don't walk down the stack forever */
+            break;                    /* 10k is chosen randomly */
+        spaddr += rd;
+    }
+}
+
+/* Read guest memory and display address that looks like text. */
+static void
+kdb_show_guest_stack(struct cpu_user_regs *regs, struct vcpu *vcpup)
+{
+    kdbva_t ipaddr=regs->KDBIP, spaddr = regs->KDBSP;
+    domid_t domid = vcpup->domain->domain_id;
+
+    ASSERT(domid != DOMID_IDLE);
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+}
+
+/* display stack. if vcpu ptr given, then display stack for that. Otherwise,
+ * use current regs */
+static kdb_cpu_cmd_t
+kdb_usgf_f(void)
+{
+    kdbp("f [vcpu-ptr]: dump current/vcpu stack\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_f(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_f();
+
+    if (argc > 1 ) {
+        struct vcpu *vp;
+        if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp)) {
+            kdbp("kdb: Bad VCPU ptr:%s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdb_show_guest_stack(&vp->arch.user_regs, vp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs))
+        kdb_show_guest_stack(regs, current);
+    else
+        show_trace(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an spaddr and domid for guest, dump stack */
+static kdb_cpu_cmd_t
+kdb_usgf_fg(void)
+{
+    kdbp("fg domid RIP ESP: dump guest stack given domid, RIP, and ESP\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_fg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid;
+    kdbva_t ipaddr, spaddr;
+
+    if (argc != 4) 
+        return kdb_usgf_fg();
+
+    if (kdb_str2domid(argv[1], &domid, 1)==0) {
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[2], &ipaddr)==0) {
+        kdbp("Bad ipaddr:%s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[3], &spaddr)==0) {
+        kdbp("Bad spaddr:%s\n", argv[3]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display kdb stack. for debugging kdb itself */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbf(void)
+{
+    kdbp("kdbf: display kdb stack. for debugging kdb only\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_kdbf(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbf();
+
+    kdb_trap_immed(KDB_TRAP_KDBSTACK);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* worker function to display memory. Request could be for any guest, domid.
+ * Also address could be machine or virtual */
+static void
+_kdb_display_mem(kdbva_t *addrp, int *lenp, int wordsz, int domid, int is_maddr)
+{
+    #define DDBUFSZ 4096
+
+    kdbbyt_t buf[DDBUFSZ], *bp;
+    int numrd, bytes;
+    int len = *lenp;
+    kdbva_t addr = *addrp;
+
+    /* round len down to wordsz boundry because on intel endian, printing
+     * characters is not prudent, (long and ints can't be interpreted 
+     * easily) */
+    len &= ~(wordsz-1);
+    len = KDBMIN(DDBUFSZ, len);
+    len = len ? len : wordsz;
+
+    KDBGP("dmem:addr:%lx buf:%p len:$%d domid:%d sz:$%d maddr:%d\n", addr,
+          buf, len, domid, wordsz, is_maddr);
+    if (is_maddr)
+        numrd=kdb_read_mmem((kdbma_t)addr, buf, len);
+    else
+        numrd=kdb_read_mem(addr, buf, len, domid);
+    if (numrd != len)
+        kdbp("Memory read error. Bytes read:$%d\n", numrd);
+
+    for (bp = buf; numrd > 0;) {
+        kdbp("%016lx: ", addr); 
+
+        /* display 16 bytes per line */
+        for (bytes=0; bytes < 16 && numrd > 0; bytes += wordsz) {
+            if (numrd >= wordsz) {
+                if (wordsz == 8)
+                    kdbp(" %016lx", *(long *)bp);
+                else
+                    kdbp(" %08x", *(int *)bp);
+                bp += wordsz;
+                numrd -= wordsz;
+                addr += wordsz;
+            }
+        }
+        kdbp("\n");
+        continue;
+    }
+    *lenp = len;
+    *addrp = addr;
+}
+
+/* display machine mem, ie, the given address is machine address */
+static kdb_cpu_cmd_t 
+kdb_display_mmem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbma_t maddr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&maddr, &len, wordsz, id, 1);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                                     /* default read len */
+
+    if (!kdb_str2ulong(argv[1], &maddr)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_display_mem(&maddr, &len, wordsz, 0, 1);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dwm(void)
+{
+    kdbp("dwm:  maddr|sym [num] : dump memory word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dwm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 4, kdb_usgf_dwm);
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ddm(void)
+{
+    kdbp("ddm:  maddr|sym [num] : dump double word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ddm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 8, kdb_usgf_ddm);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory : word or doubleword
+ *           wordsz : bytes in word. 4 or 8
+ *
+ *           We display upto BUFSZ bytes. User can just press enter for more.
+ *           addr is always in hex with or without leading 0x
+ */
+static kdb_cpu_cmd_t 
+kdb_display_mem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbva_t addr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&addr, &len, wordsz, id, 0);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    id = DOMID_IDLE;                /* not a command repeat, reset dom id */
+    if (argc >= 4) { 
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                       /* default read len */
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    _kdb_display_mem(&addr, &len, wordsz, id, 0);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dw(void)
+{
+    kdbp("dw vaddr|sym [num][domid] : dump mem word. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 4, kdb_usgf_dw);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dd(void)
+{
+    kdbp("dd vaddr|sym [num][domid] : dump dword. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dd(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 8, kdb_usgf_dd);
+}
+
+/* 
+ * FUNCTION: Modify Memory Word 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mw(void)
+{
+    kdbp("mw vaddr|sym val [domid] : modify memory word in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_mw();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val, 4, id) != 4)
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_md(void)
+{
+    kdbp("md vaddr|sym val [domid] : modify memory dword in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_md(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_md();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) {
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val,sizeof(val),id) != sizeof(val))
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct  Xgt_desc_struct {
+    unsigned short size;
+    unsigned long address __attribute__((packed));
+};
+
+void
+kdb_show_special_regs(struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    unsigned short tr;                 /* Task Register segment selector */
+    __u64 efer;
+
+    kdbp("\nSpecial Registers:\n");
+    __asm__ __volatile__ ("sidt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("IDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+    __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("GDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+
+    kdbp("cr0: %016lx  cr2: %016lx\n", read_cr0(), read_cr2());
+    kdbp("cr3: %016lx  cr4: %016lx\n", read_cr3(), read_cr4());
+    __asm__ __volatile__ ("str (%0) \n":: "a"(&tr) : "memory");
+    kdbp("TR: %x\n", tr);
+
+    rdmsrl(MSR_EFER, efer);    /* IA32_EFER */
+    kdbp("efer:"KDBF64" LMA(IA-32e mode):%d SCE(syscall/sysret):%d\n",
+         efer, ((efer&EFER_LMA) != 0), ((efer&EFER_SCE) != 0));
+
+    kdbp("DR0: %016lx  DR1:%016lx  DR2:%016lx\n", kdb_rd_dbgreg(0),
+         kdb_rd_dbgreg(1), kdb_rd_dbgreg(2)); 
+    kdbp("DR3: %016lx  DR6:%016lx  DR7:%016lx\n", kdb_rd_dbgreg(3),
+         kdb_rd_dbgreg(6), kdb_rd_dbgreg(7)); 
+}
+
+/* 
+ * FUNCTION: Dispaly Registers. If "sp" argument, then display additional regs
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dr(void)
+{
+    kdbp("dr [sp]: display registers. sp to display special regs also\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dr();
+
+    KDBGP1("regs:%p .rsp:%lx .rip:%lx\n", regs, regs->rsp, regs->rip);
+    show_registers(regs);
+    if (argc > 1 && !strcmp(argv[1], "sp")) 
+        kdb_show_special_regs(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* show registers on stack bottom where guest context is. same as dr if
+ * not running in guest mode */
+static kdb_cpu_cmd_t
+kdb_usgf_drg(void)
+{
+    kdbp("drg: display active guest registers at stack bottom\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_drg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_drg();
+
+    kdbp("\tNote: ds/es/fs/gs etc.. are not saved from the cpu\n");
+    kdb_print_uregs(guest_cpu_user_regs());
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Register
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mr(void)
+{
+    kdbp("mr reg val : Modify Register. val assumed in hex\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int regoffs;
+    ulong val;
+
+    if (argc != 3 || !kdb_str2ulong(argv[2], &val)) {
+        return kdb_usgf_mr();
+    }
+    argp = argv[1];
+
+#if defined(__x86_64__)
+    if ((regoffs=kdb_valid_reg(argp)) != -1)
+        *((uint64_t *)((char *)regs+regoffs)) = val;
+#else
+    if (!strcmp(argp, "eax"))
+        regs->eax = val;
+    else if (!strcmp(argp, "ebx"))
+        regs->ebx = val;
+    else if (!strcmp(argp, "ecx"))
+        regs->ecx = val;
+    else if (!strcmp(argp, "edx"))
+        regs->edx = val;
+    else if (!strcmp(argp, "esi"))
+        regs->esi = val;
+    else if (!strcmp(argp, "edi"))
+        regs->edi = val;
+    else if (!strcmp(argp, "ebp"))
+        regs->ebp = val;
+    else if (!strcmp(argp, "esp"))
+        regs->esp = val;
+    else if (!strcmp(argp, "eflags") || !strcmp(argp, "rflags"))
+        regs->eflags = val;
+#endif
+    else
+        kdbp("Error. Bad register : %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Single Step
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ss(void)
+{
+    kdbp("ss: single step\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ss(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    #define KDB_HALT_INSTR 0xf4
+
+    kdbbyt_t byte;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ss();
+
+    KDBGP("enter kdb_cmdf_ss \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_read_mem(regs->KDBIP, &byte, 1, id) == 1) {
+        if (byte == KDB_HALT_INSTR) {
+            kdbp("kdb: jumping over halt instruction\n");
+            regs->KDBIP++;
+        }
+    } else {
+        kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
+        current->arch.hvm_vcpu.single_step = 1;
+    } else
+        regs->eflags |= X86_EFLAGS_TF;
+
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Next Instruction, step over the call instr to the next instr
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ni(void)
+{
+    kdbp("ni: single step, stepping over function calls\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ni(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int sz, i;
+    domid_t id=guest_mode(regs) ? current->domain->domain_id:DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ni();
+
+    KDBGP("enter kdb_cmdf_ni \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if ((sz=kdb_check_call_instr(id, regs->KDBIP)) == 0)  /* !call instr */
+        return kdb_cmdf_ss(argc, argv, regs);         /* just do ss */
+
+    if ((i=kdb_set_bp(id, regs->KDBIP+sz, 1,0,0,0,0)) >= KDBMAXSBP) /* failed */
+        return KDB_CPU_MAIN_KDB;
+
+    kdb_sbpa[i].bp_ni = 1;
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+        current->arch.hvm_vcpu.single_step = 0;
+    else
+        regs->eflags &= ~X86_EFLAGS_TF;
+
+    return KDB_CPU_NI;
+}
+
+static void
+kdb_btf_enable(void)
+{
+    u64 debugctl;
+    rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 0x2);
+}
+
+/* 
+ * FUNCTION: Single Step to branch. Doesn't seem to work very well.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ssb(void)
+{
+    kdbp("ssb: singe step to branch\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ssb(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ssb();
+
+    KDBGP("MUK: enter kdb_cmdf_ssb\n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (is_hvm_or_hyb_vcpu(current)) 
+        current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
+
+    regs->eflags |= X86_EFLAGS_TF;
+    kdb_btf_enable();
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Continue Execution. TF must be cleared here as this could run on 
+ *           any cpu. Hence not OK to do it from kdb_end_session.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_go(void)
+{
+    kdbp("go: leave kdb and continue execution\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_go(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_go();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    return KDB_CPU_GO;
+}
+
+/* All cpus must display their current context */
+static kdb_cpu_cmd_t 
+kdb_cpu_status_all(int ccpu, struct cpu_user_regs *regs)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)   /* hung cpu */
+                continue;
+            kdb_cpu_cmd[cpu] = KDB_CPU_SHOWPC;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_SHOWPC);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * display/switch CPU. 
+ *  Argument:
+ *     none:   just go back to initial cpu
+ *     cpunum: switch to given vpu
+ *     "all":  show one line status of all cpus
+ */
+extern volatile int kdb_init_cpu;
+static kdb_cpu_cmd_t
+kdb_usgf_cpu(void)
+{
+    kdbp("cpu [all|num]: none will switch back to initial cpu\n");
+    kdbp("               cpunum to switch to the vcpu. all to show status\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_cpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+    int ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cpu();
+
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all"))
+            return kdb_cpu_status_all(ccpu, regs);
+
+            cpu = (int)simple_strtoul(argv[1], NULL, 0); /* handles 0x */
+            if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && 
+                cpu_online(cpu) && kdb_cpu_cmd[cpu] == KDB_CPU_PAUSE)
+            {
+                kdbp("Switching to cpu:%d\n", cpu);
+                kdb_cpu_cmd[cpu] = KDB_CPU_MAIN_KDB;
+
+                /* clear any single step on the current cpu */
+                regs->eflags &= ~X86_EFLAGS_TF;
+                return KDB_CPU_PAUSE;
+            } else {
+                if (cpu != ccpu)
+                    kdbp("Unable to switch to cpu:%d\n", cpu);
+                else {
+                    kdb_display_pc(regs);
+                }
+                return KDB_CPU_MAIN_KDB;
+            }
+    }
+    /* no arg means back to initial cpu */
+    if (!kdb_sys_crash && ccpu != kdb_init_cpu) {
+        if (kdb_cpu_cmd[kdb_init_cpu] == KDB_CPU_PAUSE) {
+            regs->eflags &= ~X86_EFLAGS_TF;
+            kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_MAIN_KDB;
+            return KDB_CPU_PAUSE;
+        } else
+            kdbp("Unable to switch to: %d\n", kdb_init_cpu);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* send NMI to all or given CPU. Must be crashed/fatal state */
+static kdb_cpu_cmd_t
+kdb_usgf_nmi(void)
+{
+    kdbp("nmi cpu#|all: send nmi cpu/s. must reboot when done with kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_nmi(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    cpumask_t cpumask;
+    int ccpu = smp_processor_id();
+
+    if (argc <= 1 || (argc > 1 && *argv[1] == '?'))
+        return kdb_usgf_nmi();
+
+    if (!kdb_sys_crash) {
+        kdbp("kdb: nmi cmd available in crashed state only\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!strcmp(argv[1], "all"))
+        cpumask = cpu_online_map;
+    else {
+        int cpu = (int)simple_strtoul(argv[1], NULL, 0);
+        if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && cpu_online(cpu))
+            cpumask = *cpumask_of(cpu);
+        else {
+            kdbp("KDB nmi: invalid cpu %s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    kdb_nmi_pause_cpus(cpumask);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_percpu(void)
+{
+    kdbp("percpu: display per cpu pointers\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_percpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_percpu();
+    kdb_dump_time_pcpu();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ========================= Breakpoints ==================================== */
+
+static void
+kdb_prnt_bp_cond(int bpnum)
+{
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {
+        kdbp("     ( %s %c%c %lx )\n", 
+             kdb_regoffs_to_name(bpcp->bp_cond_lhs),
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    } else {
+        kdbp("     ( %lx %c%c %lx )\n", bpcp->bp_cond_lhs,
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    }
+}
+
+static void
+kdb_prnt_bp_extra(int bpnum)
+{
+    if (kdb_sbpa[bpnum].bp_type == 2) {
+        ulong i, arg, *btp = kdb_sbpa[bpnum].u.bp_btp;
+        
+        kdbp("   will trace ");
+        for (i=0; i < KDB_MAXBTP && btp[i]; i++)
+            if ((arg=btp[i]) < sizeof (struct cpu_user_regs)) {
+                kdbp(" %s ", kdb_regoffs_to_name(arg));
+            } else {
+                kdbp(" %lx ", arg);
+            }
+        kdbp("\n");
+
+    } else if (kdb_sbpa[bpnum].bp_type == 1)
+        kdb_prnt_bp_cond(bpnum);
+}
+
+/*
+ * List software breakpoints
+ */
+static kdb_cpu_cmd_t
+kdb_display_sbkpts(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted) {
+            struct domain *dp = kdb_domid2ptr(kdb_sbpa[i].bp_domid);
+
+            if (dp == NULL || dp->is_dying) {
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                continue;
+            }
+            kdbp("[%d]: domid:%d 0x%lx   ", i, 
+                 kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr);
+            kdb_prnt_addr2sym(kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr,"\n");
+            kdb_prnt_bp_extra(i);
+        }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Check if any breakpoints that we need to install (delayed install)
+ * Returns: 1 if yes, 0 if none.
+ */
+int
+kdb_swbp_exists(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+/*
+ * Check if any breakpoints were deleted this kdb session
+ * Returns: 0 if none, 1 if yes
+ */
+static int
+kdb_swbp_deleted(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+
+/*
+ * Flush deleted sw breakpoints
+ */
+void
+kdb_flush_swbp_table(void)
+{
+    int i;
+    KDBGP("ccpu:%d flush_swbp_table: deleted:%x\n", smp_processor_id(), 
+          kdb_swbp_deleted());
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted) {
+            KDBGP("flush:[%x] addr:0x%lx\n",i,kdb_sbpa[i].bp_addr);
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        }
+}
+
+/*
+ * Delete/Clear a sw breakpoint
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bc(void)
+{
+    kdbp("bc $num|all : clear given or all breakpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, bpnum = -1, delall = 0;
+    const char *argp;
+
+    if (argc != 2 || *argv[1] == '?')
+        return kdb_usgf_bc();
+
+    if (!kdb_swbp_exists()) {
+        kdbp("No breakpoints are set\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        delall = 1;
+    else if (!kdb_str2deci(argp, &bpnum) || bpnum < 0 || bpnum > KDBMAXSBP) {
+        kdbp("Invalid bpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (delall && kdb_sbpa[i].bp_addr) {
+            kdbp("Deleted breakpoint [%x] addr:0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            continue;
+        }
+        if (bpnum != -1 && bpnum == i) {
+            kdbp("Deleted breakpoint [%x] at 0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            break;
+        }
+    }
+    if (i >= KDBMAXSBP && !delall)
+        kdbp("Unable to delete breakpoint: %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Install a breakpoint in the given array entry
+ * Returns: 0 : failed to install
+ *          1 : installed successfully
+ */
+static int
+kdb_install_swbp(int idx)                   /* which entry in the bp array */
+{
+    kdbva_t addr = kdb_sbpa[idx].bp_addr;
+    domid_t domid = kdb_sbpa[idx].bp_domid;
+    kdbbyt_t *p = &kdb_sbpa[idx].bp_originst;
+    struct domain *dp = kdb_domid2ptr(domid);
+
+    if (dp == NULL || dp->is_dying) {
+        memset(&kdb_sbpa[idx], 0, sizeof(kdb_sbpa[idx]));
+        kdbp("Removed bp %d addr:%p domid:%d\n", idx, addr, domid);
+        return 0;
+    }
+
+    if (kdb_read_mem(addr, p, KDBBPSZ, domid) != KDBBPSZ){
+        kdbp("Failed(R) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    if (kdb_write_mem(addr, &kdb_bpinst, KDBBPSZ, domid) != KDBBPSZ) {
+        kdbp("Failed(W) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    KDBGP("install_swbp: installed bp:%x at:0x%lx ccpu:%x domid:%d\n",
+          idx, kdb_sbpa[idx].bp_addr, smp_processor_id(), domid);
+    return 1;
+}
+
+/*
+ * Install all the software breakpoints
+ */
+void
+kdb_install_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_deleted && kdb_sbpa[i].bp_addr)
+            kdb_install_swbp(i);
+}
+
+static void
+kdb_uninstall_a_swbp(int i)
+{
+    kdbva_t addr = kdb_sbpa[i].bp_addr;
+    kdbbyt_t originst = kdb_sbpa[i].bp_originst;
+    domid_t id = kdb_sbpa[i].bp_domid;
+
+    kdb_sbpa[i].bp_just_added = 0;
+    if (!addr)
+        return;
+    if (kdb_write_mem(addr, &originst, KDBBPSZ, id) != KDBBPSZ) {
+        kdbp("Failed to uninstall breakpoint %x at:0x%lx domid:%d\n",
+             i, kdb_sbpa[i].bp_addr, id);
+    }
+}
+
+/*
+ * Uninstall all the software breakpoints at beginning of kdb session
+ */
+void
+kdb_uninstall_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++) 
+        kdb_uninstall_a_swbp(i);
+    KDBGP("ccpu:%d uninstalled all bps\n", smp_processor_id());
+}
+
+/* RETURNS: rc == 2: condition was not met,  rc == 3: condition was met */
+static int
+kdb_check_bp_condition(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong res = 0, lhsval=0;
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {             /* register condition */
+        uint64_t *rp = (uint64_t *)((char *)regs + bpcp->bp_cond_lhs);
+        lhsval = *rp;
+    } else if (bpcp->bp_cond_status == 2) {      /* memaddr condition */
+        ulong addr = bpcp->bp_cond_lhs;
+        int num = sizeof(lhsval);
+
+        if (kdb_read_mem(addr, (kdbbyt_t *)&lhsval, num, domid) != num) {
+            kdbp("kdb: unable to read %d bytes at %lx\n", num, addr);
+            return 3;
+        }
+    }
+    if (bpcp->bp_cond_type == 1)                 /* lhs == rhs */
+        res = (lhsval == bpcp->bp_cond_rhs);
+    else                                         /* lhs != rhs */
+        res = (lhsval != bpcp->bp_cond_rhs);
+
+    if (!res)
+        kdbp("KDB: [%d]Ignoring bp:%d condition not met. val:%lx\n", 
+              smp_processor_id(), bpnum, lhsval); 
+
+    KDBGP1("bpnum:%d domid:%d cond: %d %d %lx %lx res:%d\n", bpnum, domid, 
+           bpcp->bp_cond_status, bpcp->bp_cond_type, bpcp->bp_cond_lhs, 
+           bpcp->bp_cond_rhs, res);
+
+    return (res ? 3 : 2);
+}
+
+static void
+kdb_prnt_btp_info(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong i, arg, val, num, *btp = kdb_sbpa[bpnum].u.bp_btp;
+
+    kdb_prnt_addr2sym(domid, regs->KDBIP, "\n");
+    num = kdb_guest_bitness(domid)/8;
+    for (i=0; i < KDB_MAXBTP && (arg=btp[i]); i++) {
+        if (arg < sizeof (struct cpu_user_regs)) {
+            uint64_t *rp = (uint64_t *)((char *)regs + arg);
+            kdbp(" %s: %016lx ", kdb_regoffs_to_name(arg), *rp);
+        } else {
+            if (kdb_read_mem(arg, (kdbbyt_t *)&val, num, domid) != num)
+                kdbp("kdb: unable to read %d bytes at %lx\n", num, arg);
+            if (num == 8)
+                kdbp(" %016lx:%016lx ", arg, val);
+            else
+                kdbp(" %08lx:%08lx ", arg, val);
+        }
+    }
+    kdbp("\n");
+    KDBGP1("bpnum:%d domid:%d btp:%p num:%d\n", bpnum, domid, btp, num);
+}
+
+/*
+ * Check if the BP trap belongs to us. 
+ * Return: 0 : not one of ours. IP not changed. (leave kdb)
+ *         1 : one of ours but deleted. IP decremented. (leave kdb)
+ *         2 : one of ours but condition not met, or btp. IP decremented.(leave)
+ *         3 : one of ours and active. IP decremented. (stay in kdb)
+ */
+int 
+kdb_check_sw_bkpts(struct cpu_user_regs *regs)
+{
+    int i, rc=0;
+    domid_t curid;
+
+    curid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    for(i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_domid == curid  && 
+            kdb_sbpa[i].bp_addr == (regs->KDBIP- KDBBPSZ)) {
+
+            regs->KDBIP -= KDBBPSZ;
+            rc = 3;
+
+            if (kdb_sbpa[i].bp_ni) {
+                kdb_uninstall_a_swbp(i);
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            } else if (kdb_sbpa[i].bp_deleted) {
+                rc = 1;
+            } else if (kdb_sbpa[i].bp_type == 1) {
+                rc = kdb_check_bp_condition(i, regs, curid);
+            } else if (kdb_sbpa[i].bp_type == 2) {
+                kdb_prnt_btp_info(i, regs, curid);
+                rc = 2;
+            }
+            KDBGP1("ccpu:%d rc:%d curid:%d domid:%d addr:%lx\n", 
+                   smp_processor_id(), rc, curid, kdb_sbpa[i].bp_domid, 
+                   kdb_sbpa[i].bp_addr);
+            break;
+        }
+    }
+    return (rc);
+}
+
+/* Eg: r6 == 0x123EDF  or 0xFFFF2034 != 0xDEADBEEF
+ * regoffs: -1 means lhs is not reg. else offset of reg in cpu_user_regs
+ * addr: memory location if lhs is not register, eg, 0xFFFF2034
+ * condp : points to != or ==
+ * rhsval : right hand side value
+ */
+static void
+kdb_set_bp_cond(int bpnum, int regoffs, ulong addr, char *condp, ulong rhsval)
+{
+    if (bpnum >= KDBMAXSBP) {
+        kdbp("BUG: %s got invalid bpnum\n", __FUNCTION__);
+        return;
+    }
+    if (regoffs != -1) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 1;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = regoffs;
+    } else if (addr != 0) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 2;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = addr;
+    } else {
+        kdbp("error: invalid call to kdb_set_bp_cond\n");
+        return;
+    }
+    kdb_sbpa[bpnum].u.bp_cond.bp_cond_rhs = rhsval;
+
+    if (*condp == '!')
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 2;
+    else
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 1;
+}
+
+/* install breakpt at given addr. 
+ * ni: bp for next instr 
+ * btpa: ptr to args for btp for printing when bp is hit
+ * lhsp/condp/rhsp: point to strings of condition
+ *
+ * RETURNS: the index in array where installed. KDBMAXSBP if error 
+ */
+static int
+kdb_set_bp(domid_t domid, kdbva_t addr, int ni, ulong *btpa, char *lhsp, 
+           char *condp, char *rhsp)
+{
+    int i, pre_existing = 0, regoffs = -1;
+    ulong memloc=0, rhsval=0, tmpul;
+
+    if (btpa && (lhsp || rhsp || condp)) {
+        kdbp("internal error. btpa and (lhsp || rhsp || condp) set\n");
+        return KDBMAXSBP;
+    }
+    if (lhsp && ((regoffs=kdb_valid_reg(lhsp)) == -1)  &&
+        kdb_str2ulong(lhsp, &memloc) &&
+        kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0) {
+
+        kdbp("error: invalid argument: %s\n", lhsp);
+        return KDBMAXSBP;
+    }
+    if (rhsp && ! kdb_str2ulong(rhsp, &rhsval)) {
+        kdbp("error: invalid argument: %s\n", rhsp);
+        return KDBMAXSBP;
+    }
+
+    /* see if bp already set */
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_addr==addr && kdb_sbpa[i].bp_domid==domid) {
+
+            if (kdb_sbpa[i].bp_deleted) {
+                /* just re-set this bp again */
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                pre_existing = 1;
+            } else {
+                kdbp("Breakpoint already set \n");
+                return KDBMAXSBP;
+            }
+        }
+    }
+    /* see if any room left for another breakpoint */
+    for (i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_addr)
+            break;
+    if (i >= KDBMAXSBP) {
+        kdbp("ERROR: Breakpoint table full....\n");
+        return i;
+    }
+    kdb_sbpa[i].bp_addr = addr;
+    kdb_sbpa[i].bp_domid = domid;
+    if (btpa) {
+        kdb_sbpa[i].bp_type = 2;
+        kdb_sbpa[i].u.bp_btp = btpa;
+    } else if (regoffs != -1 || memloc) {
+        kdb_sbpa[i].bp_type = 1;
+        kdb_set_bp_cond(i, regoffs, memloc, condp, rhsval);
+    } else
+        kdb_sbpa[i].bp_type = 0;
+
+    if (kdb_install_swbp(i)) {                  /* make sure it can be done */
+        if (ni)
+            return i;
+
+        kdb_uninstall_a_swbp(i);                /* dont' show user INT3 */
+        if (!pre_existing)               /* make sure no is cpu sitting on it */
+            kdb_sbpa[i].bp_just_added = 1;
+
+        kdbp("bp %d set for domid:%d at: 0x%lx ", i, kdb_sbpa[i].bp_domid, 
+             kdb_sbpa[i].bp_addr);
+        kdb_prnt_addr2sym(domid, addr, "\n");
+        kdb_prnt_bp_extra(i);
+    } else {
+        kdbp("ERROR:Can't install bp: 0x%lx domid:%d\n", addr, domid);
+        if (pre_existing)     /* in case a cpu is sitting on this bp in traps */
+            kdb_sbpa[i].bp_deleted = 1;
+        else
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        return KDBMAXSBP;
+    }
+    /* make sure swbp reporting is enabled in the vmcb/vmcs */
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        struct domain *dp = kdb_domid2ptr(domid);
+        dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
+        KDBGP("debugger_attached set. domid:%d\n", domid);
+    }
+    return i;
+}
+
+/* 
+ * Set/List Software Breakpoint/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bp(void)
+{
+    kdbp("bp [addr|sym][domid][condition]: display or set a breakpoint\n");
+    kdbp("  where cond is like: r6 == 0x123F or rax != DEADBEEF or \n");
+    kdbp("       ffff82c48038fe58 == 321E or 0xffff82c48038fe58 != 0\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9");
+    kdbp(" r10 r11 r12 r13 r14 r15 rflags\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    int idx = -1;
+    domid_t domid = DOMID_IDLE;
+    char *domidstrp, *lhsp=NULL, *condp=NULL, *rhsp=NULL;
+
+    if ((argc > 1 && *argv[1] == '?') || argc == 4 || argc > 6)
+        return kdb_usgf_bp();
+
+    if (argc < 2 || kdb_sys_crash)         /* list all set breakpoints */
+        return kdb_display_sbkpts();
+
+    /* valid argc either: 2 3 5 or 6 
+     * 'bp idle_loop r6 == 0xc000' OR 'bp idle_loop 3 r9 != 0xdeadbeef' */
+    idx = (argc == 5) ? 2 : ((argc == 6) ? 3 : idx);
+    if (argc >= 5 ) {
+        lhsp = (char *)argv[idx];
+        condp = (char *)argv[idx+1];
+        rhsp = (char *)argv[idx+2];
+
+        if (!kdb_str2ulong(rhsp, NULL) || *(condp+1) != '=' || 
+            (*condp != '=' && *condp != '!')) {
+
+            return kdb_usgf_bp();
+        }
+    }
+    domidstrp = (argc == 3 || argc == 6 ) ? (char *)argv[2] : NULL;
+    if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
+        return kdb_usgf_bp();
+    }
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        kdbp("HVM domain not supported yet for conditional bp\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    /* make sure xen addr is in xen text, otherwise bp set in 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_set_bp(domid, addr, 0, NULL, lhsp, condp, rhsp);     /* 0 is ni flag */
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* trace breakpoint, meaning, upon bp trace/print some info and continue */
+
+static kdb_cpu_cmd_t
+kdb_usgf_btp(void)
+{
+    kdbp("btp addr|sym [domid] reg|domid-mem-addr... : breakpoint trace\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9 ");
+    kdbp("r10 r11 r12 r13 r14 r15 rflags\n");
+    kdbp("  Eg. btp idle_cpu 7 rax rbx 0x20ef5a5 r9\n");
+    kdbp("      will print rax, rbx, *(long *)0x20ef5a5, r9 and continue\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_btp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, btpidx, numrd, argsidx, regoffs = -1;
+    kdbva_t addr, memloc=0;
+    domid_t domid = DOMID_IDLE;
+    ulong *btpa, tmpul;
+
+    if ((argc > 1 && *argv[1] == '?') || argc < 3)
+        return kdb_usgf_btp();
+
+    argsidx = 2;                   /* assume 3rd arg is not domid */
+    if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
+
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+            kdbp("HVM domains are not currently supprted\n");
+            return KDB_CPU_MAIN_KDB;
+        } else
+            argsidx = 3;               /* 3rd arg is a domid */
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    /* make sure xen addr is in xen text, otherwise will trace 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    numrd = kdb_guest_bitness(domid)/8;
+    if (kdb_read_mem(addr, (kdbbyt_t *)&tmpul, numrd, domid) != numrd) {
+        kdbp("Unable to read mem from %s (%lx)\n", argv[1], addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    for (btpidx=0; btpidx < KDBMAXSBP && kdb_btp_ap[btpidx]; btpidx++);
+    if (btpidx >= KDBMAXSBP) {
+        kdbp("error: table full. delete few breakpoints\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    btpa = kdb_btp_argsa[btpidx];
+    memset(btpa, 0, sizeof(kdb_btp_argsa[0]));
+
+    for (i=0; argv[argsidx]; i++, argsidx++) {
+
+        if (((regoffs=kdb_valid_reg(argv[argsidx])) == -1)  &&
+            kdb_str2ulong(argv[argsidx], &memloc) &&
+            (memloc < sizeof (struct cpu_user_regs) ||
+            kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0)){
+
+            kdbp("error: invalid argument: %s\n", argv[argsidx]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        if (i >= KDB_MAXBTP) {
+            kdbp("error: cannot specify more than %d args\n", KDB_MAXBTP);
+            return KDB_CPU_MAIN_KDB;
+        }
+        btpa[i] = (regoffs == -1) ? memloc : regoffs;
+    }
+
+    i = kdb_set_bp(domid, addr, 0, btpa, 0, 0, 0);     /* 0 is ni flag */
+    if (i < KDBMAXSBP)
+        kdb_btp_ap[btpidx] = kdb_btp_argsa[btpidx];
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * Set/List watchpoints, ie, hardware breakpoint/s, in hypervisor
+ *   Usage: wp [sym|addr] [w|i]   w == write only data watchpoint
+ *                                i == IO watchpoint (read/write)
+ *
+ *   Eg:  wp        : list all watchpoints set
+ *        wp addr   : set a read/write wp at given addr
+ *        wp addr w : set a write only wp at given addr
+ *        wp addr i : set an IO wp at given addr (16bits port #)
+ *
+ *  TBD: allow to be set on particular cpu
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_wp(void)
+{
+    kdbp("wp [addr|sym][w|i]: display or set watchpoint. writeonly or IO\n");
+    kdbp("\tnote: watchpoint is triggered after the instruction executes\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    domid_t domid = DOMID_IDLE;
+    int rw = 3, len = 4;       /* for now just default to 4 bytes len */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_wp();
+
+    if (argc <= 1 || kdb_sys_crash) {       /* list all set watchpoints */
+        kdb_do_watchpoints(0, 0, 0);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2) {
+        if (!strcmp(argv[2], "w"))
+            rw = 1;
+        else if (!strcmp(argv[2], "i"))
+            rw = 2;
+        else {
+            return kdb_usgf_wp();
+        }
+    }
+    kdb_do_watchpoints(addr, rw, len);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_wc(void)
+{
+    kdbp("wc $num|all : clear given or all watchpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int wpnum;              /* wp num to delete. -1 for all */
+
+    if (argc != 2 || *argv[1] == '?') 
+        return kdb_usgf_wc();
+
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        wpnum = -1;
+    else if (!kdb_str2deci(argp, &wpnum)) {
+        kdbp("Invalid wpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_clear_wps(wpnum);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display struct hvm_vcpu{} in struct vcpu.arch{} */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpuh(void)
+{
+    kdbp("vcpuh vcpu-ptr : display hvm_vcpu struct\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpuh(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *vp;
+    struct hvm_vcpu *hvp;
+    struct hvm_io_op *ioop;
+    struct vlapic *vlp;
+
+    if (argc < 2 || *argv[1] == '?') 
+        return kdb_usgf_vcpuh();
+
+    if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
+        !is_hvm_or_hyb_vcpu(vp)) {
+
+        kdbp("kdb: Bad VCPU: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    hvp = &vp->arch.hvm_vcpu;
+    vlp = &hvp->vlapic;
+    kdbp("vcpu:%lx id:%d domid:%d\n", vp, vp->vcpu_id, vp->domain->domain_id);
+
+    ioop = NULL;   /* compiler warning */
+    kdbp("&hvm_vcpu:%lx  guest_efer:"KDBFL"\n", hvp, hvp->guest_efer);
+    kdbp("  guest_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->guest_cr[0],
+         hvp->guest_cr[1],hvp->guest_cr[2]);
+    kdbp("            [3]:"KDBFL" [4]:"KDBFL"\n", hvp->guest_cr[3],
+         hvp->guest_cr[4]);
+    kdbp("  hw_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->hw_cr[0],
+         hvp->hw_cr[1], hvp->hw_cr[2]);
+    kdbp("          [3]:"KDBFL" [4]:"KDBFL"\n", hvp->hw_cr[3], hvp->hw_cr[4]);
+
+    kdbp("  VLAPIC: base msr:"KDBF64" dis:%x tmrdiv:%x\n", 
+         vlp->hw.apic_base_msr, vlp->hw.disabled, vlp->hw.timer_divisor);
+    kdbp("          regs:%p regs_page:%p\n", vlp->regs, vlp->regs_page);
+    kdbp("          periodic time:\n"); 
+    kdb_prnt_periodic_time(&vlp->pt);
+
+    kdbp("  xen_port:%x flag_dr_dirty:%x dbg_st_latch:%x\n", hvp->xen_port,
+         hvp->flag_dr_dirty, hvp->debug_state_latch);
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+
+        struct arch_vmx_struct *vxp = &hvp->u.vmx;
+        kdbp("  &vmx: %p vmcs:%lx active_cpu:%x launched:%x\n", vxp, vxp->vmcs, 
+             vxp->active_cpu, vxp->launched);
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("    exec_ctrl:%x vpid:$%d\n", vxp->exec_control, vxp->vpid);
+#endif
+        kdbp("    host_cr0: "KDBFL" vmx: {realm:%x emulate:%x}\n",
+             vxp->host_cr0, vxp->vmx_realmode, vxp->vmx_emulate);
+
+#ifdef __x86_64__
+        kdbp("    &msr_state:%p\n", &vxp->msr_state);
+#endif
+    } else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+        struct arch_svm_struct *svp = &hvp->u.svm;
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("  &svm: vmcb:%lx pa:"KDBF64" asid:"KDBF64"\n", svp, svp->vmcb,
+             svp->vmcb_pa, svp->asid_generation);
+#endif
+        kdbp("    msrpm:%p lnch_core:%x vmcb_sync:%x\n", svp->msrpm, 
+             svp->launch_core, svp->vmcb_in_sync);
+    }
+    kdbp("  cachemode:%x io: {state: %x data: "KDBFL"}\n", hvp->cache_mode,
+         hvp->hvm_io.io_state, hvp->hvm_io.io_data);
+    kdbp("  mmio: {gva: "KDBFL" gpfn: "KDBFL"}\n", hvp->hvm_io.mmio_gva,
+         hvp->hvm_io.mmio_gpfn);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* also look into arch_get_info_guest() to get context */
+static void
+kdb_print_uregs(struct cpu_user_regs *regs)
+{
+#ifdef __x86_64__
+    kdbp("      rflags: %016lx   rip: %016lx\n", regs->rflags, regs->rip);
+    kdbp("         rax: %016lx   rbx: %016lx   rcx: %016lx\n",
+         regs->rax, regs->rbx, regs->rcx);
+    kdbp("         rdx: %016lx   rsi: %016lx   rdi: %016lx\n",
+         regs->rdx, regs->rsi, regs->rdi);
+    kdbp("         rbp: %016lx   rsp: %016lx    r8: %016lx\n",
+         regs->rbp, regs->rsp, regs->r8);
+    kdbp("          r9:  %016lx  r10: %016lx   r11: %016lx\n",
+         regs->r9,  regs->r10, regs->r11);
+    kdbp("         r12: %016lx   r13: %016lx   r14: %016lx\n",
+         regs->r12, regs->r13, regs->r14);
+    kdbp("         r15: %016lx\n", regs->r15);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+         "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%08lx entryvec:%08lx upcall_mask:%lx\n",
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#else
+    kdbp("      eflags: %016lx eip: 016lx\n", regs->eflags, regs->eip);
+    kdbp("      eax: %08x   ebx: %08x   ecx: %08x   edx: %08x\n",
+         regs->eax, regs->ebx, regs->ecx, regs->edx);
+    kdbp("      esi: %08x   edi: %08x   ebp: %08x   esp: %08x\n",
+         regs->esi, regs->edi, regs->ebp, regs->esp);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+     "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%04lx entryvec:%04lx upcall_mask:%lx\n", 
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#endif
+}
+
+#if XEN_SUBVERSION < 3             /* xen 3.1.x or xen 3.2.x */
+#ifdef CONFIG_COMPAT
+    #undef vcpu_info
+    #define vcpu_info(v, field)             \
+    (*(!has_32bit_shinfo((v)->domain) ?                                       \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->native.field : \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->compat.field))
+
+    #undef __shared_info
+    #define __shared_info(d, s, field)                      \
+    (*(!has_32bit_shinfo(d) ?                           \
+       (typeof(&(s)->compat.field))&(s)->native.field : \
+       (typeof(&(s)->compat.field))&(s)->compat.field))
+#endif
+#endif
+
+static void kdb_display_pv_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct pv_vcpu *gp = &vp->arch.pv_vcpu;
+
+    kdbp("      GDT_VIRT_START(vcpu): %lx\n", GDT_VIRT_START(vp));
+    kdbp("      GDT: entries:0x%lx  frames:\n", gp->gdt_ents);
+    for (i=0; i < 16; i=i+4) 
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->gdt_frames[i], 
+             gp->gdt_frames[i+1], gp->gdt_frames[i+2],gp->gdt_frames[i+3]);
+    
+    kdbp("      trap_ctxt:%lx kernel_ss:%lx kernel_sp:%lx\n", gp->trap_ctxt,
+         gp->kernel_ss, gp->kernel_sp);
+    kdbp("      ctrlregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->ctrlreg[i], 
+             gp->ctrlreg[i+1], gp->ctrlreg[i+2], gp->ctrlreg[i+3]);
+#ifdef __x86_64__
+    kdbp("      callback:   event: %016lx   failsafe: %016lx\n", 
+         gp->event_callback_eip, gp->failsafe_callback_eip);
+    kdbp("      base: fs:0x%lx gskern:0x%lx gsuser:0x%lx\n", 
+         gp->fs_base, gp->gs_base_kernel, gp->gs_base_user);
+#else
+    kdbp("      callback:   event: %08lx:%08lx   failsafe: %08lx:%08lx\n", 
+         gp->event_callback_cs, gp->event_callback_eip, 
+         gp->failsafe_callback_cs, gp->failsafe_callback_eip);
+#endif
+    kdbp("    vcpu_info_mfn: %lx  iopl: %x\n", gp->vcpu_info_mfn, gp->iopl);
+    kdbp("\n");
+}
+
+/* Display one VCPU info */
+static void
+kdb_display_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct arch_vcpu *avp = &vp->arch;
+    struct paging_vcpu *pvp = &vp->arch.paging;
+    int domid = vp->domain->domain_id;
+
+    kdbp("\nVCPU:  vcpu-id:%d  vcpu-ptr:%p ", vp->vcpu_id, vp);
+    kdbp("  processor:%d domid:%d  domp:%p\n", vp->processor, domid,vp->domain);
+
+    if (domid == DOMID_IDLE) {
+        kdbp("    IDLE vcpu.\n");
+        return;
+    }
+    kdbp("  pause: flags:0x%016lx count:%x\n", vp->pause_flags, 
+         vp->pause_count.counter);
+    kdbp("  vcpu: initdone:%d running:%d\n", 
+         vp->is_initialised, vp->is_running);
+    kdbp("  mcepend:%d nmipend:%d shut: def:%d paused:%d\n", 
+         vp->mce_pending,  vp->nmi_pending, vp->defer_shutdown, 
+         vp->paused_for_shutdown);
+    kdbp("  &vcpu_info:%p : evtchn_upc_pend:%x _mask:%x\n",
+         vp->vcpu_info, vcpu_info(vp, evtchn_upcall_pending),
+         vcpu_info(vp, evtchn_upcall_mask));
+    kdbp("  evt_pend_sel:%lx poll_evtchn:%x ", 
+         *(unsigned long *)&vcpu_info(vp, evtchn_pending_sel), vp->poll_evtchn);
+    kdb_print_spin_lock("virq_lock:", &vp->virq_lock, "\n");
+    for (i=0; i < NR_VIRQS; i++)
+        if (vp->virq_to_evtchn[i] != 0)
+            kdbp("      virq:$%d port:$%d\n", i, vp->virq_to_evtchn[i]);
+
+    kdbp("  next:%p periodic: period:0x%lx last_event:0x%lx\n", 
+         vp->next_in_list, vp->periodic_period, vp->periodic_last_event);
+    kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:%p sched_priv:0x%p\n",
+         vp->cpu_affinity, vp->vcpu_dirty_cpumask, vp->sched_priv);
+    kdbp("  &runstate: %p state: %x (eg. RUNSTATE_running) guestptr:%p\n", 
+         &vp->runstate, vp->runstate.state, runstate_guest(vp));
+    kdbp("\n");
+    kdbp("  arch info: (%p)\n", &vp->arch);
+    kdbp("    guest_context: VGCF_ flags:%lx", 
+         vp->arch.vgc_flags); /* VGCF_in_kernel */
+    if (is_hvm_or_hyb_vcpu(vp))
+        kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
+    kdbp("\n");
+    kdb_print_uregs(&vp->arch.user_regs);
+    kdbp("      debugregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", avp->debugreg[i], 
+             avp->debugreg[i+1], avp->debugreg[i+2], avp->debugreg[i+3]);
+    kdb_display_pv_vcpu(vp);
+
+    kdbp("    TF_flags: %016lx  guest_table: %016lx cr3:%016lx\n", 
+         vp->arch.flags, vp->arch.guest_table.pfn, avp->cr3); 
+    kdbp("    paging: \n");
+    kdbp("      vtlb:%p\n", &pvp->vtlb);
+    kdbp("      &pg_mode:%p gstlevels:%d &shadow:%p shlevels:%d\n",
+         pvp->mode, pvp->mode->guest_levels, &pvp->mode->shadow,
+         pvp->mode->shadow.shadow_levels);
+    kdbp("      shadow_vcpu:\n");
+    kdbp("        guest_vtable:%p last em_mfn:"KDBFL"\n",
+         pvp->shadow.guest_vtable, pvp->shadow.last_emulated_mfn);
+#if CONFIG_PAGING_LEVELS >= 3
+    kdbp("         l3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.l3table[3].l3, pvp->shadow.l3table[2].l3, 
+     pvp->shadow.l3table[1].l3, pvp->shadow.l3table[0].l3);
+    kdbp("        gl3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.gl3e[3].l3, pvp->shadow.gl3e[2].l3, 
+     pvp->shadow.gl3e[1].l3, pvp->shadow.gl3e[0].l3);
+#endif
+    kdbp("  gdbsx_vcpu_event:%x\n", vp->arch.gdbsx_vcpu_event);
+}
+
+/* 
+ * FUNCTION: Dispaly (current) VCPU/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpu(void)
+{
+    kdbp("vcpu [vcpu-ptr] : display current/vcpu-ptr vcpu info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *v = current;
+
+    if (argc > 2 || (argc > 1 && *argv[1] == '?'))
+        kdb_usgf_vcpu();
+    else if (argc <= 1)
+        kdb_display_vcpu(v);
+    else if (kdb_str2ulong(argv[1], (ulong *)&v) && kdb_vcpu_valid(v))
+        kdb_display_vcpu(v);
+    else 
+        kdbp("Invalid usage/argument:%s v:%lx\n", argv[1], (long)v);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* from paging_dump_domain_info() */
+static void kdb_pr_dom_pg_modes(struct domain *d)
+{
+    if (paging_mode_enabled(d)) {
+        kdbp(" paging mode enabled");
+        if ( paging_mode_shadow(d) )
+            kdbp(" shadow(PG_SH_enable)");
+        if ( paging_mode_hap(d) )
+            kdbp(" hap(PG_HAP_enable) ");
+        if ( paging_mode_refcounts(d) )
+            kdbp(" refcounts(PG_refcounts) ");
+        if ( paging_mode_log_dirty(d) )
+            kdbp(" log_dirty(PG_log_dirty) ");
+        if ( paging_mode_translate(d) )
+            kdbp(" translate(PG_translate) ");
+        if ( paging_mode_external(d) )
+            kdbp(" external(PG_external) ");
+    } else
+        kdbp(" disabled");
+    kdbp("\n");
+}
+
+/* print event channels info for a given domain 
+ * NOTE: very confusing, port and event channel refer to the same thing. evtchn
+ * is arry of pointers to a bucket of pointers to 128 struct evtchn{}. while
+ * 64bit xen can handle 4096 max channels, a 32bit guest is limited to 1024 */
+static void noinline kdb_print_dom_eventinfo(struct domain *dp)
+{
+    uint chn;
+
+    kdbp("\n");
+    kdbp("  Evt: MAX_EVTCHNS:$%d ptr:%p pollmsk:%08lx ",
+         MAX_EVTCHNS(dp), dp->evtchn, dp->poll_mask[0]);
+    kdb_print_spin_lock("lk:", &dp->event_lock, "\n");
+    kdbp("    &evtchn_pending:%p &evtchn_mask:%p\n", 
+         shared_info(dp, evtchn_pending), shared_info(dp, evtchn_mask));
+
+    kdbp("   Channels info: (everything is in decimal):\n");
+    for (chn=0; chn < MAX_EVTCHNS(dp); chn++ ) {
+        struct evtchn *bktp = dp->evtchn[chn/EVTCHNS_PER_BUCKET];
+        struct evtchn *chnp = &bktp[chn & (EVTCHNS_PER_BUCKET-1)];
+        char pbit = test_bit(chn, &shared_info(dp, evtchn_pending)) ? 'Y' : 'N';
+        char mbit = test_bit(chn, &shared_info(dp, evtchn_mask)) ? 'Y' : 'N';
+
+        if (bktp==NULL || chnp->state==ECS_FREE)
+            continue;
+
+        kdbp("    chn:%4u st:%d _xen=%d _vcpu_id:%2d ", chn, chnp->state,
+             chnp->xen_consumer, chnp->notify_vcpu_id);
+        if (chnp->state == ECS_UNBOUND)
+            kdbp(" rem-domid:%d", chnp->u.unbound.remote_domid);
+        else if (chnp->state == ECS_INTERDOMAIN)
+            kdbp(" rem-port:%d rem-dom:%d", chnp->u.interdomain.remote_port,
+                 chnp->u.interdomain.remote_dom->domain_id);
+        else if (chnp->state == ECS_PIRQ)
+            kdbp(" pirq:%d", chnp->u.pirq);
+        else if (chnp->state == ECS_VIRQ)
+            kdbp(" virq:%d", chnp->u.virq);
+
+        kdbp("  pend:%c mask:%c\n", pbit, mbit);
+    }
+#if 0
+    kdbp("pirq to evtchn mapping (pirq:evtchn) (all decimal):\n");
+    for (i=0; i < dp->nr_pirqs; i ++)
+        if (dp->pirq_to_evtchn[i])
+            kdbp("(%d:%d) ", i, dp->pirq_to_evtchn[i]);
+    kdbp("\n");
+#endif
+}
+
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    struct hvm_domain *hvp = &dp->arch.hvm_domain;
+
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+    if (hvp == NULL)
+        return;
+
+    if (hvp->irq.callback_via_type == HVMIRQ_callback_vector)
+        kdbp("    HVMIRQ_callback_vector: %x\n", hvp->irq.callback_via.vector);
+
+    if (!is_hvm_domain(dp))
+        return;
+
+    kdbp("    HVM PARAMS (all in hex):\n");
+    kdbp("\tioreq.page:%lx ioreq.va:%lx\n", hvp->ioreq.page, hvp->ioreq.va);
+    kdbp("\tbuf_ioreq.page:%lx ioreq.va:%lx\n", hvp->buf_ioreq.page, 
+         hvp->buf_ioreq.va);
+    kdbp("\tHVM_PARAM_CALLBACK_IRQ: %x\n", hvp->params[HVM_PARAM_CALLBACK_IRQ]);
+    kdbp("\tHVM_PARAM_STORE_PFN: %x\n", hvp->params[HVM_PARAM_STORE_PFN]);
+    kdbp("\tHVM_PARAM_STORE_EVTCHN: %x\n", hvp->params[HVM_PARAM_STORE_EVTCHN]);
+    kdbp("\tHVM_PARAM_PAE_ENABLED: %x\n", hvp->params[HVM_PARAM_PAE_ENABLED]);
+    kdbp("\tHVM_PARAM_IOREQ_PFN: %x\n", hvp->params[HVM_PARAM_IOREQ_PFN]);
+    kdbp("\tHVM_PARAM_BUFIOREQ_PFN: %x\n", hvp->params[HVM_PARAM_BUFIOREQ_PFN]);
+    kdbp("\tHVM_PARAM_VIRIDIAN: %x\n", hvp->params[HVM_PARAM_VIRIDIAN]);
+    kdbp("\tHVM_PARAM_TIMER_MODE: %x\n", hvp->params[HVM_PARAM_TIMER_MODE]);
+    kdbp("\tHVM_PARAM_HPET_ENABLED: %x\n", hvp->params[HVM_PARAM_HPET_ENABLED]);
+    kdbp("\tHVM_PARAM_IDENT_PT: %x\n", hvp->params[HVM_PARAM_IDENT_PT]);
+    kdbp("\tHVM_PARAM_DM_DOMAIN: %x\n", hvp->params[HVM_PARAM_DM_DOMAIN]);
+    kdbp("\tHVM_PARAM_ACPI_S_STATE: %x\n", hvp->params[HVM_PARAM_ACPI_S_STATE]);
+    kdbp("\tHVM_PARAM_VM86_TSS: %x\n", hvp->params[HVM_PARAM_VM86_TSS]);
+    kdbp("\tHVM_PARAM_VPT_ALIGN: %x\n", hvp->params[HVM_PARAM_VPT_ALIGN]);
+    kdbp("\tHVM_PARAM_CONSOLE_PFN: %x\n", hvp->params[HVM_PARAM_CONSOLE_PFN]);
+    kdbp("\tHVM_PARAM_CONSOLE_EVTCHN: %x\n", 
+         hvp->params[HVM_PARAM_CONSOLE_EVTCHN]);
+    kdbp("\tHVM_PARAM_ACPI_IOPORTS_LOCATION: %x\n", 
+         hvp->params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+    kdbp("\tHVM_PARAM_MEMORY_EVENT_SINGLE_STEP: %x\n", 
+         hvp->params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP]);
+}
+static void kdb_print_rangesets(struct domain *dp)
+{
+    int locked = spin_is_locked(&dp->rangesets_lock);
+
+    if (locked)
+        spin_unlock(&dp->rangesets_lock);
+    rangeset_domain_printk(dp);
+    if (locked)
+        spin_lock(&dp->rangesets_lock);
+}
+
+static void kdb_pr_vtsc_info(struct arch_domain *ap)
+{
+    kdbp("    VTSC info: tsc_mode:%x  vtsc:%x  vtsc_last:%016lx\n", 
+         ap->tsc_mode, ap->vtsc, ap->vtsc_last);
+    kdbp("        vtsc_offset:%016lx tsc_khz:%08lx incarnation:%x\n", 
+         ap->vtsc_offset, ap->vtsc_offset, ap->incarnation);
+    kdbp("        vtsc_kerncount:%016lx _usercount:%016lx\n",
+         ap->vtsc_kerncount, ap->vtsc_usercount);
+}
+
+/* display one domain info */
+static void
+kdb_display_dom(struct domain *dp)
+{
+    struct vcpu *vp;
+    int printed = 0;
+    struct grant_table *gp = dp->grant_table;
+    struct arch_domain *ap = &dp->arch;
+
+    kdbp("\nDOMAIN :    domid:0x%04x ptr:0x%p\n", dp->domain_id, dp);
+    if (dp->domain_id == DOMID_IDLE) {
+        kdbp("    IDLE domain.\n");
+        return;
+    }
+    if (dp->is_dying) {
+        kdbp("    domain is DYING.\n");
+        return;
+    }
+#if 0
+    kdb_print_spin_lock("  pgalk:", &dp->page_alloc_lock, "\n");
+    kdbp("  pglist:  0x%p 0x%p\n", dp->page_list.next,KDB_PGLLE(dp->page_list));
+    kdbp("  xpglist: 0x%p 0x%p\n", dp->xenpage_list.next, 
+         KDB_PGLLE(dp->xenpage_list));
+    kdbp("  next:0x%p hashnext:0x%p\n", 
+         dp->next_in_list, dp->next_in_hashbucket);
+#endif
+    kdbp("  PAGES: tot:0x%08x max:0x%08x xenheap:0x%08x\n", 
+         dp->tot_pages, dp->max_pages, dp->xenheap_pages);
+
+    kdb_print_rangesets(dp);
+    kdb_print_dom_eventinfo(dp);
+    kdbp("\n");
+    kdbp("  Grant table: gp:0x%p\n", gp);
+    if (gp) {
+        kdbp("    nr_frames:0x%08x shpp:0x%p active:0x%p\n",
+             gp->nr_grant_frames, gp->shared_raw, gp->active);
+        kdbp("    maptrk:0x%p maphd:0x%08x maplmt:0x%08x\n", 
+             gp->maptrack, gp->maptrack_head, gp->maptrack_limit);
+        kdbp("    mapcnt:");
+        kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
+    }
+    kdbp("  hvm:%d priv:%d need_iommu:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_privileged, dp->need_iommu,
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
+    kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
+    kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
+         dp->is_shut_down, dp->shutdown_code);
+    kdbp("  pausecnt:0x%08x vm_assist:0x"KDBFL" refcnt:0x%08x\n",
+         dp->pause_count.counter, dp->vm_assist, dp->refcnt.counter);
+    kdbp("  &domain_dirty_cpumask:%p\n", &dp->domain_dirty_cpumask); 
+
+    kdbp("  shared == vcpu_info[]: %p\n",  dp->shared_info); 
+    kdbp("    arch_shared: maxpfn: %lx pfn-mfn-frame-ll mfn: %lx\n", 
+         arch_get_max_pfn(dp), arch_get_pfn_to_mfn_frame_list_list(dp));
+    kdbp("\n");
+    kdbp("  arch_domain at : %p\n", ap);
+
+#ifdef CONFIG_X86_64
+    kdbp("    pt_pages:0x%p ", ap->mm_perdomain_pt_pages);
+    kdbp("    l2:0x%p l3:0x%p\n", ap->mm_perdomain_l2, ap->mm_perdomain_l3);
+#else
+    kdbp("    pt:0x%p ", ap->mm_perdomain_pt);
+#endif
+#ifdef CONFIG_X86_32
+    kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
+#endif
+    kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
+    kdb_pr_dom_pg_modes(dp);
+    kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
+         KDB_PGLLE(ap->p2m->pages));
+    kdbp("       max_mapped_pfn:"KDBFL, ap->p2m->max_mapped_pfn);
+#if XEN_SUBVERSION > 0 && XEN_VERSION == 4              /* xen 4.1 and above */
+    kdbp("  phys_table:%p\n", ap->p2m->phys_table.pfn);
+#else
+    kdbp("  phys_table.pfn:"KDBFL"\n", ap->phys_table.pfn);
+#endif
+    kdbp("    physaddr_bitsz:%d 32bit_pv:%d has_32bit_shinfo:%d\n", 
+         ap->physaddr_bitsize, ap->is_32bit_pv, ap->has_32bit_shinfo);
+    kdb_pr_vtsc_info(ap);
+    kdbp("  sched:0x%p  &handle:0x%p\n", dp->sched_priv, &dp->handle);
+    kdbp("  vcpu ptrs:\n   ");
+    for_each_vcpu(dp, vp) {
+        kdbp(" %d:%p", vp->vcpu_id, vp);
+        if (++printed % 4 == 0) kdbp("\n   ");
+    }
+    kdbp("\n");
+}
+
+/* 
+ * FUNCTION: Dispaly (current) domain/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dom(void)
+{
+    kdbp("dom [all|domid]: Display current/all/given domain/s\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dom(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int id;
+    struct domain *dp = current->domain;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dom();
+
+    if (argc > 1) {
+        for(dp=domain_list; dp; dp=dp->next_in_list)
+            if (kdb_str2deci(argv[1], &id) && dp->domain_id==id)
+                kdb_display_dom(dp);
+            else if (!strcmp(argv[1], "all")) 
+                kdb_display_dom(dp);
+    } else {
+        kdbp("Displaying current domain :\n");
+        kdb_display_dom(dp);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dirq(void)
+{
+    kdbp("dirq : dump irq bindings\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dirq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long irq, sz, offs, addr;
+    char buf[KSYM_NAME_LEN+1];
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dirq();
+
+#if XEN_VERSION < 4 && XEN_SUBVERSION < 5           /* xen 3.4.x or below */
+    kdbp("idx/irq#/status: all are in decimal\n");
+    kdbp("idx  irq#  status   action(handler name devid)\n");
+    for (irq=0; irq < NR_VECTORS; irq++) {
+        irq_desc_t  *dp = &irq_desc[irq];
+        if (!dp->action)
+            continue;
+        addr = (unsigned long)dp->action->handler;
+        kdbp("[%3ld]:irq:%3d st:%3d f:%s devnm:%s devid:0x%p\n",
+             i, vector_to_irq(irq), dp->status, (dp->status & IRQ_GUEST) ? 
+                            "GUEST IRQ" : symbols_lookup(addr, &sz, &offs, buf),
+             dp->action->name, dp->action->dev_id);
+    }
+#else
+    kdbp("irq_desc[]:%p nr_irqs: $%d nr_irqs_gsi: $%d\n", irq_desc, nr_irqs, 
+          nr_irqs_gsi);
+    kdbp("irq/vec#/status: in decimal. affinity in hex, not bitmap\n");
+    kdbp("irq-- vec sta function----------- name---- type--------- ");
+    kdbp("aff devid------------\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        void *devidp;
+        const char *symp, *nmp;
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+
+        if (!dp->handler || dp->handler==&no_irq_type || dp->status & IRQ_GUEST)
+            continue;
+
+        addr = dp->action ? (unsigned long)dp->action->handler : 0;
+        symp = addr ? symbols_lookup(addr, &sz, &offs, buf) : "n/a ";
+        nmp = addr ? dp->action->name : "n/a ";
+        devidp = addr ? dp->action->dev_id : NULL;
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %03d %03d %-19s %-8s %-13s %3s 0x%p\n", irq, archp->vector,
+             dp->status, symp, nmp, dp->handler->typename, affstr, devidp);
+    }
+    kdb_prnt_guest_mapped_irqs();
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+kdb_prnt_vec_irq_table(int cpu)
+{
+    int i,j, *tbl = per_cpu(vector_irq, cpu);
+
+    kdbp("CPU %d : ", cpu);
+    for (i=0, j=0; i < NR_VECTORS; i++)
+        if (tbl[i] != -1) {
+            kdbp("(%3d:%3d) ", i, tbl[i]);
+            if (!(++j % 5))
+                kdbp("\n        ");
+        }
+    kdbp("\n");
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dvit(void)
+{
+    kdbp("dvit [cpu|all]: dump (per cpu)vector irq table\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvit(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu, ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvit();
+    
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all")) 
+            cpu = -1;
+        else if (!kdb_str2deci(argv[1], &cpu)) {
+            kdbp("Invalid cpu:%d\n", cpu);
+            return kdb_usgf_dvit();
+        }
+    } else
+        cpu = ccpu;
+
+    kdbp("Per CPU vector irq table pairs (vector:irq) (all decimals):\n");
+    if (cpu != -1) 
+        kdb_prnt_vec_irq_table(cpu);
+    else
+        for_each_online_cpu(cpu) 
+            kdb_prnt_vec_irq_table(cpu);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* do vmexit on all cpu's so intel VMCS can be dumped */
+static kdb_cpu_cmd_t 
+kdb_all_cpu_flush_vmcs(void)
+{
+    int cpu, ccpu = smp_processor_id();
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdb_curr_cpu_flush_vmcs();
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE){  /* hung cpu */
+                kdbp("Skipping (hung?) cpu %d\n", cpu);
+                continue;
+            }
+            kdb_cpu_cmd[cpu] = KDB_CPU_DO_VMEXIT;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_DO_VMEXIT);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display VMCS or VMCB */
+static kdb_cpu_cmd_t
+kdb_usgf_dvmc(void)
+{
+    kdbp("dvmc [domid][vcpuid] : Dump vmcs/vmcb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvmc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid = 0;  /* unsigned type don't like -1 */
+    int vcpuid = -1;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvmc();
+
+    if (argc > 1) { 
+        if (!kdb_str2domid(argv[1], &domid, 1))
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2 && !kdb_str2deci(argv[2], &vcpuid)) {
+        kdbp("Bad vcpuid: 0x%x\n", vcpuid);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        kdb_all_cpu_flush_vmcs();
+        kdb_dump_vmcs(domid, (int)vcpuid);
+    } else {
+        kdb_dump_vmcb(domid, (int)vcpuid);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_mmio(void)
+{
+    kdbp("mmio: dump mmio related info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmio(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmio();
+
+    kdbp("r/o mmio ranges:\n");
+    rangeset_printk(mmio_ro_ranges);
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump timer/timers queues */
+static kdb_cpu_cmd_t
+kdb_usgf_dtrq(void)
+{
+    kdbp("dtrq: dump timer queues on all cpus\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dtrq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dtrq();
+
+    kdb_dump_timer_queues();
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct idte {
+    uint16_t offs0_15;
+    uint16_t selector;
+    uint16_t meta;
+    uint16_t offs16_31;
+    uint32_t offs32_63;
+    uint32_t resvd;
+};
+
+#ifdef __x86_64__
+static void
+kdb_print_idte(int num, struct idte *idtp) 
+{
+    uint16_t mta = idtp->meta;
+    char dpl = ((mta & 0x6000) >> 13);
+    char present = ((mta &0x8000) >> 15);
+    int tval = ((mta &0x300) >> 8);
+    char *type = (tval == 1) ? "Task" : ((tval== 2) ? "Intr" : "Trap");
+    domid_t domid = idtp->selector==__HYPERVISOR_CS64 ? DOMID_IDLE :
+                    current->domain->domain_id;
+    uint64_t addr = idtp->offs0_15 | ((uint64_t)idtp->offs16_31 << 16) | 
+                    ((uint64_t)idtp->offs32_63 << 32);
+
+    kdbp("[%03d]: %s %x  %x %04x:%016lx ", num, type, dpl, present,
+         idtp->selector, addr); 
+    kdb_prnt_addr2sym(domid, addr, "\n");
+}
+
+/* Dump 64bit idt table currently on this cpu. Intel Vol 3 section 5.14.1 */
+static kdb_cpu_cmd_t
+kdb_usgf_didt(void)
+{
+    kdbp("didt : dump IDT table on the current cpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i;
+    struct idte *idtp = (struct idte *)idt_tables[smp_processor_id()];
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_didt();
+
+    kdbp("IDT at:%p\n", idtp);
+    kdbp("idt#  Type DPL P addr (all hex except idt#)\n", idtp);
+    for (i=0; i < 256; i++, idtp++) 
+        kdb_print_idte(i, idtp);
+    return KDB_CPU_MAIN_KDB;
+}
+#else
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbp("kdb: Please implement me in 32bit hypervisor\n");
+    return KDB_CPU_MAIN_KDB;
+}
+#endif
+
+struct gdte {             /* same for TSS and LDT */
+    ulong limit0:16;
+    ulong base0:24;       /* linear address base, not pa */
+    ulong acctype:4;      /* Type: access rights */
+    ulong S:1;            /* S: 0 = system, 1 = code/data */
+    ulong DPL:2;          /* DPL */
+    ulong P:1;            /* P: Segment Present */
+    ulong limit1:4;
+    ulong AVL:1;          /* AVL: avail for use by system software */
+    ulong L:1;            /* L: 64bit code segment */
+    ulong DB:1;           /* D/B */
+    ulong G:1;            /* G: granularity */
+    ulong base1:8;        /* linear address base, not pa */
+};
+
+union gdte_u {
+    struct gdte gdte;
+    u64 gval;
+};
+
+struct call_gdte {
+    unsigned short offs0:16;
+    unsigned short sel:16;
+    unsigned short misc0:16;
+    unsigned short offs1:16;
+};
+
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
+union sgdte_u {
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
+    u64 sgval;
+};
+
+/* return binary form of a hex in string : max 4 chars 0000 to 1111 */
+static char *kdb_ret_acctype(uint acctype)
+{
+    static char buf[16];
+    char *p = buf;
+    int i;
+
+    if (acctype > 0xf) {
+        buf[0] = buf[1] = buf[2] = buf[3] = '?';
+        buf[5] = '\n';
+        return buf;
+    }
+    for (i=0; i < 4; i++, p++, acctype=acctype>>1)
+        *p = (acctype & 0x1) ? '1' : '0';
+
+    return buf;
+}
+
+/* Display GDT table. IA-32e mode is assumded. */
+/* first display non system descriptors then display system descriptors */
+static kdb_cpu_cmd_t
+kdb_usgf_dgdt(void)
+{
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
+         "given vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dgdt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    union gdte_u u1;
+    ulong start_addr, end_addr, taddr=0;
+    domid_t domid = DOMID_IDLE;
+    int idx;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dgdt();
+
+    if (argc > 1) {
+        if (argc != 3)
+            return kdb_usgf_dgdt();
+
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
+        } else {
+            kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
+            return kdb_usgf_dgdt();
+        }
+    } else {
+        __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
+    }
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
+    kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
+         "--Base Addr ----  Limit\n");
+    kdbp("                              Type\n");
+
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+            continue;
+
+        if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
+            continue;               /* what an effin x86 mess */
+
+        idx = (taddr - start_addr) / 8;
+        if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
+            taddr += sizeof(ulong);
+            continue;
+        }
+        kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
+             u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
+             (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
+             u1.gdte.limit0 | (u1.gdte.limit1<<16));
+    }
+
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
+        uint acctype;
+        u64 upper, addr64=0;
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
+            u1.gval == 0 || u1.gdte.S == 1) {
+            continue;
+        }
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+            kdbp("Could not read upper 8 bytes of system desc\n");
+            upper = 0;
+        }
+        acctype = u1.gdte.acctype;
+        if (acctype != 2 && acctype != 9 && acctype != 11 && acctype !=12 &&
+            acctype != 14 && acctype != 15)
+            continue;
+
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
+
+        /* Vol 3A: table: 3-2  page: 3-19 */
+        if (acctype == 2) {
+            kdbp("LDT gate (0010)\n");
+        }
+        else if (acctype == 9) {
+            kdbp("TSS avail gate(1001)\n");
+        }
+        else if (acctype == 11) {
+            kdbp("TSS busy gate(1011)\n");
+        }
+        else if (acctype == 12) {
+            kdbp("CALL gate (1100)\n");
+        }
+        else if (acctype == 14) {
+            kdbp("IDT gate (1110)\n");
+        }
+        else if (acctype == 15) {
+            kdbp("Trap gate (1111)\n"); 
+        }
+
+        if (acctype == 2 || acctype == 9 || acctype == 11) {
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display scheduler basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_sched(void)
+{
+    kdbp("sched: show schedular info and run queues\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sched(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_sched();
+
+    kdb_print_sched_info();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display MMU basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_mmu(void)
+{
+    kdbp("mmu: print basic MMU info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmu();
+
+    kdbp("MMU Info:\n");
+    kdbp("total  pages: %lx\n", total_pages);
+    kdbp("max page/mfn: %lx\n", max_page);
+    kdbp("frame_table:  %p\n", frame_table);
+    kdbp("DIRECTMAP_VIRT_START:  %lx\n", DIRECTMAP_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_START: %lx\n", HYPERVISOR_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_END:   %lx\n", HYPERVISOR_VIRT_END);
+    kdbp("RO_MPT_VIRT_START:     %lx\n", RO_MPT_VIRT_START);
+    kdbp("PERDOMAIN_VIRT_START:  %lx\n", PERDOMAIN_VIRT_START);
+    kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
+    kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
+         (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
+
+    kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
+    kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
+    kdbp("LAST_RESERVED_GDT_ENTRY: %lx\n", (ulong)LAST_RESERVED_GDT_ENTRY);
+    kdbp("  Per cpu non-compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(gdt_table, cpu));
+    }
+    kdbp("  Per cpu compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
+    }
+    kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
+#ifdef USER_MAPPINGS_ARE_GLOBAL
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
+#else
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
+#endif
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* for HVM/HYB guests, go thru EPT. For PV guest we need to go to the btree. 
+ * btree: pfn_to_mfn_frame_list_list is root that points (has mfns of) upto 16
+ * pages (call 'em l2 nodes) that contain mfns of guest p2m table pages 
+ * NOTE: num of entries in a p2m page is same as num of entries in l2 node */
+static noinline ulong
+kdb_gpfn2mfn(struct domain *dp, ulong gpfn, p2m_type_t *typep) 
+{
+    int idx;
+
+    if ( !paging_mode_translate(dp) ) {
+        mfn_t *mfn_va, mfn = arch_get_pfn_to_mfn_frame_list_list(dp);
+        int g_longsz = kdb_guest_bitness(dp->domain_id)/8;
+        int entries_per_pg = PAGE_SIZE/g_longsz;
+        const int shift = get_count_order(entries_per_pg);
+
+	if ( !mfn_valid(mfn) ) {
+	    kdbp("Invalid frame_list_list mfn:%lx for non-xlate guest\n", mfn);
+	    return INVALID_MFN;
+	}
+
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn >> 2*shift;     /* index in root page/node */
+        if (idx > 15) {
+            kdbp("gpfn:%lx idx:%x not in frame list limit of z16\n", gpfn, idx);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        if (mfn==0) {
+            kdbp("No mfn for idx:%d for gpfn:%lx in root pg\n", idx, gpfn);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn_va = map_domain_page(mfn);
+        KDBGP1("p2m: idx:%x fll:%lx mfn of 2nd lvl page:%lx\n", idx,
+               arch_get_pfn_to_mfn_frame_list_list(dp), mfn);
+
+        idx = (gpfn>>shift) & ((1<<shift)-1);     /* idx in l2 node */
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+        if (mfn == 0) {
+            kdbp("No mfn entry at:%x in 2nd lvl pg for gpfn:%lx\n", idx, gpfn);
+            return INVALID_MFN;
+        }
+        KDBGP1("p2m: idx:%x  mfn of p2m page:%lx\n", idx, mfn); 
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn & ((1<<shift)-1);
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+
+	*typep = -1;
+        return mfn;
+    } else
+        return get_gfn_query(dp, gpfn, typep);
+
+    return INVALID_MFN;
+}
+
+/* given a pfn, find it's mfn */
+static kdb_cpu_cmd_t
+kdb_usgf_p2m(void)
+{
+    kdbp("p2m domid 0xgpfn : gpfn to mfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_p2m(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gpfn, mfn;
+    p2m_type_t p2mtype;
+
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
+        !kdb_str2ulong(argv[2], &gpfn)) {
+
+        return kdb_usgf_p2m();
+    }
+    mfn = kdb_gpfn2mfn(dp, gpfn, &p2mtype);
+    if ( paging_mode_translate(dp) )
+        kdbp("p2m[%lx] == %lx type:%d/0x%x\n", gpfn, mfn, p2mtype, p2mtype);
+    else 
+        kdbp("p2m[%lx] == %lx type:N/A(PV)\n", gpfn, mfn);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an mfn, lookup pfn in the MPT */
+static kdb_cpu_cmd_t
+kdb_usgf_m2p(void)
+{
+    kdbp("m2p 0xmfn: mfn to pfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_m2p(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    mfn_t mfn;
+    if (argc > 1 && kdb_str2ulong(argv[1], &mfn))
+        if (mfn_valid(mfn))
+            kdbp("mpt[%x] == %lx\n", mfn, machine_to_phys_mapping[mfn]);
+        else
+            kdbp("Invalid mfn:%lx\n", mfn);
+    else
+        kdb_usgf_m2p();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void 
+kdb_pr_pg_pgt_flds(unsigned long type_info)
+{
+    switch (type_info & PGT_type_mask) {
+        case (PGT_l1_page_table):
+            kdbp("    page is PGT_l1_page_table\n");
+            break;
+        case PGT_l2_page_table:
+            kdbp("    page is PGT_l2_page_table\n");
+            break;
+        case PGT_l3_page_table:
+            kdbp("    page is PGT_l3_page_table\n");
+            break;
+        case PGT_l4_page_table:
+            kdbp("    page is PGT_l4_page_table\n");
+            break;
+        case PGT_seg_desc_page:
+            kdbp("    page is seg desc page\n");
+            break;
+        case PGT_writable_page:
+            kdbp("    page is writable page\n");
+            break;
+        case PGT_shared_page:
+            kdbp("    page is shared page\n");
+            break;
+    }
+    if (type_info & PGT_pinned)
+        kdbp("    page is pinned\n");
+    if (type_info & PGT_validated)
+        kdbp("    page is validated\n");
+    if (type_info & PGT_pae_xen_l2)
+        kdbp("    page is PGT_pae_xen_l2\n");
+    if (type_info & PGT_partial)
+        kdbp("    page is PGT_partial\n");
+    if (type_info & PGT_locked)
+        kdbp("    page is PGT_locked\n");
+}
+
+static void
+kdb_pr_pg_pgc_flds(unsigned long count_info)
+{
+    if (count_info & PGC_allocated)
+        kdbp("  PGC_allocated");
+    if (count_info & PGC_xen_heap)
+        kdbp("  PGC_xen_heap");
+    if (count_info & PGC_page_table)
+        kdbp("  PGC_page_table");
+    if (count_info & PGC_broken)
+        kdbp("  PGC_broken");
+#if XEN_VERSION < 4                                 /* xen 3.x.x */
+    if (count_info & PGC_offlining)
+        kdbp("  PGC_offlining");
+    if (count_info & PGC_offlined)
+        kdbp("  PGC_offlined");
+#else
+    if (count_info & PGC_state_inuse)
+        kdbp("  PGC_inuse");
+    if (count_info & PGC_state_offlining)
+        kdbp("  PGC_state_offlining");
+    if (count_info & PGC_state_offlined)
+        kdbp("  PGC_state_offlined");
+    if (count_info & PGC_state_free)
+        kdbp("  PGC_state_free");
+#endif
+    kdbp("\n");
+}
+
+/* print struct page_info{} given ptr to it or an mfn
+ * NOTE: that given an mfn there seems no way of knowing how it's used, so
+ *       here we just print all info and let user decide what's applicable */
+static kdb_cpu_cmd_t
+kdb_usgf_dpage(void)
+{
+    kdbp("dpage mfn|page-ptr : Display struct page\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dpage(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long val;
+    struct page_info *pgp;
+    struct domain *dp;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dpage();
+
+    if ((kdb_str2ulong(argv[1], &val) == 0)      ||
+        (val <  (ulong)frame_table && !mfn_valid(val))) {
+
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdbp("Page Info:\n");
+    if (val <= (ulong)frame_table) {       /* arg is mfn */
+        pgp = mfn_to_page(val);
+        kdbp("  mfn: %lx page_info:%p\n", val, pgp);
+    } else {
+        pgp = (struct page_info *)val; /* arg is struct page{} */
+        if (pgp < frame_table || pgp >= frame_table+max_page) {
+            kdbp("Invalid page ptr. below/beyond max_page\n");
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdbp("  mfn: %lx page_info:%p\n", page_to_mfn(pgp), pgp);
+    } 
+    kdbp("  count_info: %016lx  (refcnt: %x)\n", pgp->count_info,
+         pgp->count_info & PGC_count_mask);
+#if XEN_VERSION > 3 || XEN_SUBVERSION > 3             /* xen 3.4.x or later */
+    kdb_pr_pg_pgc_flds(pgp->count_info);
+
+    kdbp("In use info:\n");
+    kdbp("  type_info:%016lx\n", pgp->u.inuse.type_info);
+    kdb_pr_pg_pgt_flds(pgp->u.inuse.type_info);
+    dp = page_get_owner(pgp);
+    kdbp("  domid:%d (pickled:%lx)\n", dp ? dp->domain_id : -1, 
+         pgp->v.inuse._domain);
+
+    kdbp("Shadow Info:\n");
+    kdbp("  type:%x pinned:%x count:%x\n", pgp->u.sh.type, pgp->u.sh.pinned,
+         pgp->u.sh.count);
+    kdbp("  back:%lx  shadow_flags:%x  next_shadow:%lx\n", pgp->v.sh.back,
+         pgp->shadow_flags, pgp->next_shadow);
+
+    kdbp("Free Info\n");
+    kdbp("  need_tlbflush:%d order:%d tlbflush_timestamp:%x\n",
+         pgp->u.free.need_tlbflush, pgp->v.free.order, 
+         pgp->tlbflush_timestamp);
+#else
+    if (pgp->count_info & PGC_allocated)            /* page allocated */
+        kdbp("  PGC_allocated");
+    if (pgp->count_info & PGC_page_table)           /* page table page */
+        kdbp("  PGC_page_table");
+    kdbp("\n");
+    kdbp("  page is %s xen heap page\n", is_xen_heap_page(pgp) ? "a":"NOT");
+    kdbp("  cacheattr:%x\n", (pgp->count_info>>PGC_cacheattr_base) & 7);
+    if (pgp->count_info & PGC_count_mask) {         /* page in use */
+        dp = pgp->u.inuse._domain;         /* pickled domain */
+        kdbp("  page is in use\n");
+        kdbp("    domid: %d  (pickled dom:%x)\n", 
+             dp ? (unpickle_domptr(dp))->domain_id : -1, dp);
+        kdbp("    type_info: %lx\n", pgp->u.inuse.type_info);
+        kdb_prt_pg_type(pgp->u.inuse.type_info);
+    } else {                                         /* page is free */
+        kdbp("  page is free\n");
+        kdbp("    order: %x\n", pgp->u.free.order);
+        kdbp("    cpumask: %lx\n", pgp->u.free.cpumask.bits);
+    }
+    kdbp("  tlbflush/shadow_flags: %lx\n", pgp->shadow_flags);
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display asked msr value */
+static kdb_cpu_cmd_t
+kdb_usgf_dmsr(void)
+{
+    kdbp("dmsr address : Display msr value\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dmsr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long addr, val;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dmsr();
+
+    if ((kdb_str2ulong(argv[1], &addr) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    rdmsrl(addr, val);
+    kdbp("msr: %lx  val:%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_cpuid(void)
+{
+    kdbp("cpuid eax : Display cpuid value returned in rax\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_cpuid(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long rax=0, rbx=0, rcx=0, rdx=0;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_cpuid();
+
+    if ((kdb_str2ulong(argv[1], &rax) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+#if 0
+    __asm__ __volatile__ (
+            /* "pushl %%rax  \n" */
+
+            "movl %0, %%rax  \n"
+            "cpuid           \n" 
+            : "=&a" (rax), "=b" (rbx), "=c" (rcx), "=d" (rdx)
+            : "0" (rax)
+            : "rax", "rbx", "rcx", "rdx", "memory");
+#endif
+    cpuid(rax, &rax, &rbx, &rcx, &rdx);
+    kdbp("rax: %016lx  rbx:%016lx rcx:%016lx rdx:%016lx\n", rax, rbx,
+         rcx, rdx);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_wept(void)
+{
+    kdbp("wept domid gfn: walk ept table for given domid and gfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_wept(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gfn;
+
+    if ((argc > 1 && *argv[1] == '?') || argc != 3)
+        return kdb_usgf_wept();
+    if ((dp=kdb_strdomid2ptr(argv[1], 1)) && kdb_str2ulong(argv[2], &gfn))
+        ept_walk_table(dp, gfn);
+    else
+        kdb_usgf_wept();
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Save symbols info for a guest, dom0 or other...
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_sym(void)
+{
+   kdbp("sym domid &kallsyms_names &kallsyms_addresses &kallsyms_num_syms\n");
+   kdbp("\t [&kallsyms_token_table] [&kallsyms_token_index]\n");
+   kdbp("\ttoken _table and _index MUST be specified for el5\n");
+   return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sym(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong namesp, addrap, nump, toktblp, tokidxp;
+    domid_t domid;
+
+    if (argc < 5) {
+        return kdb_usgf_sym();
+    }
+    toktblp = tokidxp = 0;     /* optional parameters */
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &namesp)   &&
+        kdb_str2ulong(argv[3], &addrap)   &&
+        kdb_str2ulong(argv[4], &nump)     && 
+        (argc==5 || (argc==7 && kdb_str2ulong(argv[5], &toktblp) &&
+                                kdb_str2ulong(argv[6], &tokidxp)))) {
+
+        kdb_sav_dom_syminfo(domid, namesp, addrap,nump,toktblp,tokidxp);
+    } else
+        kdb_usgf_sym();
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* mods is the dumb ass &modules. modules is struct {nxt, prev}, and not ptr */
+static void
+kdb_dump_linux_modules(domid_t domid, ulong mods, uint nxtoffs, uint nmoffs, 
+                       uint coreoffs)
+{
+    const int bufsz = 56;
+    char buf[bufsz];
+    uint64_t addr, addrval, *nxtptr, *modptr;
+    uint i, num = 8;
+
+    if (kdb_guest_bitness(domid) == 32)
+        num = 4;
+
+    /* first read modules{}.next ptr */
+    if (kdb_read_mem(mods, (kdbbyt_t *)&nxtptr, num, domid) != num) {
+        kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+        return;
+    }
+
+    KDBGP("mods:%p nxtptr:%p nmoffs:%x coreoffs:%x\n", (void *)mods, nxtptr,
+          nmoffs, coreoffs);
+
+    while ((uint64_t)nxtptr != mods) {
+
+        modptr = (uint64_t *) ((ulong)nxtptr - nxtoffs);
+
+        addr = (ulong)modptr + coreoffs;
+        if (kdb_read_mem(addr, (kdbbyt_t *)&addrval, num, domid) != num) {
+            kdbp("ERROR: Could not read mod addr at :%p\n", (void *)addr);
+            return;
+        }
+
+        KDBGP("modptr:%p addr:%p\n", modptr, (void *)addr);
+        addr = (ulong)modptr + nmoffs;
+        i=0;
+        do {
+            if (kdb_read_mem(addr, (kdbbyt_t *)&buf[i], 1, domid) != 1) {
+                kdbp("ERROR:Could not read name ch at addr:%p\n", (void *)addr);
+                return;
+            }
+            addr++;
+        } while (buf[i] && i++ < bufsz);
+        buf[bufsz-1] = '\0';
+
+        kdbp("%016lx %016lx %s\n", modptr, addrval, buf);
+
+        if (kdb_read_mem((ulong)nxtptr, (kdbbyt_t *)&nxtptr, num, domid)!=num) {
+            kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+            return;
+        }
+        KDBGP("nxtptr:%p addr:%p\n", nxtptr, (void *)addr);
+    } 
+}
+
+/* Display modules loaded in linux guest */
+static kdb_cpu_cmd_t
+kdb_usgf_mod(void)
+{
+   kdbp("mod domid &modules next-offs name-offs module_core-offs\n");
+   kdbp("\twhere next-offs: &((struct module *)0)->list.next\n");
+   kdbp("\tname-offs: &((struct module *)0)->name etc..\n");
+   kdbp("\tDisplays all loaded modules in the linux guest\n");
+   kdbp("\tEg: mod 0 ffffffff80302780 8 0x18 0x178\n");
+
+   return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_cmdf_mod(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong mods, nxtoffs, nmoffs, coreoffs;
+    domid_t domid;
+
+    if (argc < 6) {
+        return kdb_usgf_mod();
+    }
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &mods)     &&
+        kdb_str2ulong(argv[3], &nxtoffs)  &&
+        kdb_str2ulong(argv[4], &nmoffs)   &&
+        kdb_str2ulong(argv[5], &coreoffs)) {
+
+        kdbp("modptr address name\n");
+        kdb_dump_linux_modules(domid, mods, nxtoffs, nmoffs, coreoffs);
+    } else
+        kdb_usgf_mod();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* toggle kdb debug trace level */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbdbg(void)
+{
+    kdbp("kdbdbg : trace info to debug kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_kdbdbg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbdbg();
+
+    kdbdbg = (kdbdbg==3) ? 0 : (kdbdbg+1);
+    kdbp("kdbdbg set to:%d\n", kdbdbg);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_reboot(void)
+{
+    kdbp("reboot: reboot system\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_reboot(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_reboot();
+
+    machine_restart(500);
+    return KDB_CPU_MAIN_KDB;              /* not reached */
+}
+
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcon(void)
+{
+    kdbp("trcon: turn user added kdb tracing on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcon(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcon();
+
+    kdb_trcon = 1;
+    kdbp("kdb tracing is now on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcoff(void)
+{
+    kdbp("trcoff: turn user added kdb tracing off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcoff(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcoff();
+
+    kdb_trcon = 0;
+    kdbp("kdb tracing is now off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcz(void)
+{
+    kdbp("trcz : zero entire trace buffer\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcz(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcz();
+
+    kdb_trczero();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcp(void)
+{
+    kdbp("trcp : give hints to dump trace buffer via dw/dd command\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcp();
+
+    kdb_trcp();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* print some basic info, constants, etc.. */
+static kdb_cpu_cmd_t
+kdb_usgf_info(void)
+{
+    kdbp("info : display basic info, constants, etc..\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_info(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    struct cpuinfo_x86 *bcdp;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_info();
+
+    kdbp("Version: %d.%d.%s (%s@%s) %s\n", xen_major_version(), 
+         xen_minor_version(), xen_extra_version(), xen_compile_by(), 
+         xen_compile_domain(), xen_compile_date());
+    kdbp("__XEN_LATEST_INTERFACE_VERSION__ : 0x%x\n", 
+         __XEN_LATEST_INTERFACE_VERSION__);
+    kdbp("__XEN_INTERFACE_VERSION__: 0x%x\n", __XEN_INTERFACE_VERSION__);
+
+    bcdp = &boot_cpu_data;
+    kdbp("CPU: (all decimal)");
+        if (bcdp->x86_vendor == X86_VENDOR_AMD)
+            kdbp(" AMD");
+        else
+            kdbp(" INTEL");
+        kdbp(" family:%d model:%d\n", bcdp->x86, bcdp->x86_model);
+        kdbp("     vendor_id:%16s model_id:%64s\n", bcdp->x86_vendor_id,
+             bcdp->x86_model_id);
+        kdbp("     cpuidlvl:%d cache:sz:%d align:%d\n", bcdp->cpuid_level,
+             bcdp->x86_cache_size, bcdp->x86_cache_alignment);
+        kdbp("     power:%d cores: max:%d booted:%d siblings:%d apicid:%d\n",
+             bcdp->x86_power, bcdp->x86_max_cores, bcdp->booted_cores,
+             bcdp->x86_num_siblings, bcdp->apicid);
+        kdbp("     ");
+        if (cpu_has_apic)
+            kdbp("_apic");
+        if (cpu_has_sep)
+            kdbp("|_sep");
+        if (cpu_has_xmm3)
+            kdbp("|_xmm3");
+        if (cpu_has_ht)
+            kdbp("|_ht");
+        if (cpu_has_nx)
+            kdbp("|_nx");
+        if (cpu_has_clflush)
+            kdbp("|_clflush");
+        if (cpu_has_page1gb)
+            kdbp("|_page1gb");
+        if (cpu_has_ffxsr)
+            kdbp("|_ffxsr");
+        if (cpu_has_x2apic)
+            kdbp("|_x2apic");
+    kdbp("\n\n");
+    kdbp("CC:");
+#if defined(CONFIG_X86_64)
+        kdbp(" CONFIG_X86_64");
+#endif
+#if defined(CONFIG_COMPAT)
+        kdbp(" CONFIG_COMPAT");
+#endif
+#if defined(CONFIG_PAGING_ASSISTANCE)
+        kdbp(" CONFIG_PAGING_ASSISTANCE");
+#endif
+    kdbp("\n");
+    kdbp("cpu has following features:\n");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ? 
+         "X86_FEATURE_TSC_RELIABLE" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_CONSTANT_TSC)? "X86_FEATURE_CONSTANT_TSC":"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ? "X86_FEATURE_NONSTOP_TSC" :"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_RDTSCP) ?  "X86_FEATURE_RDTSCP" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_FXSR) ?  "X86_FEATURE_FXSR" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_CPUID_FAULTING) ?  
+         "X86_FEATURE_CPUID_FAULTING" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_PAGE1GB) ?  "X86_FEATURE_PAGE1GB" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_MWAIT) ?  "X86_FEATURE_MWAIT" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_X2APIC) ?  "X86_FEATURE_X2APIC":"");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_XSAVE) ?  "X86_FEATURE_XSAVE":"");
+    kdbp("\n");
+
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
+    kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
+    kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
+
+    kdbp("\nDomains and their vcpus:\n");
+    for_each_domain(dp) {
+        struct vcpu *vp;
+        int printed=0;
+        kdbp("  Domain: {id:%d 0x%x   ptr:%p%s}  VCPUs:\n", 
+             dp->domain_id, dp->domain_id, dp, dp->is_dying ? " DYING":"");
+        for(vp=dp->vcpu[0]; vp; vp = vp->next_in_list) {
+            kdbp("  {id:%d p:%p runstate:%d}", vp->vcpu_id, vp, 
+                 vp->runstate.state);
+            if (++printed % 2 == 0) kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_cur(void)
+{
+    kdbp("cur : display current domid and vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Checking for guest_mode() not feasible here. if dom0->hcall->bp in xen, 
+ * then g_m() will show xen, but vcpu is still dom0. hence just look at 
+ * current only */
+static kdb_cpu_cmd_t
+kdb_cmdf_cur(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t id = current->domain->domain_id;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cur();
+
+    kdbp("domid: %d{%p} %s vcpu:%d {%p} ", id, current->domain,
+         (id==DOMID_IDLE) ? "(IDLE)" : "", current->vcpu_id, current);
+
+    /* if (id != DOMID_IDLE) { */
+        if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+            u64 addr = -1;
+            __vmptrst(&addr);
+            kdbp(" VMCS:"KDBFL, addr);
+        }
+    /* } */
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* stub to quickly and easily add a new command */
+static kdb_cpu_cmd_t
+kdb_usgf_usr1(void)
+{
+    kdbp("usr1: add any arbitrary cmd using this in kdb_cmds.c\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_usr1(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_h(void)
+{
+    kdbp("h: display all commands. See kdb/README for more info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_h(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbtab_t *tbp;
+
+    kdbp(" - ccpu is current cpu \n");
+    kdbp(" - following are always in decimal:\n");
+    kdbp("     vcpu num, cpu num, domid\n");
+    kdbp(" - otherwise, almost all numbers are in hex (0x not needed)\n");
+    kdbp(" - output: $17 means decimal 17\n");
+    kdbp(" - domid 7fff($32767) refers to hypervisor\n");
+    kdbp(" - if no domid before function name, then it's hypervisor\n");
+    kdbp(" - earlykdb in xen grub line to break into kdb during boot\n");
+    kdbp(" - command ? will show the command usage\n");
+    kdbp("\n");
+
+    for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_usgf; tbp++)
+        (*tbp->kdb_cmd_usgf)();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ===================== cmd table initialization ========================== */
+void __init
+kdb_init_cmdtab(void)
+{
+  static kdbtab_t _kdb_cmd_table[] = {
+
+    {"info", kdb_cmdf_info, kdb_usgf_info, 1, KDB_REPEAT_NONE},
+    {"cur",  kdb_cmdf_cur, kdb_usgf_cur, 1, KDB_REPEAT_NONE},
+
+    {"f",  kdb_cmdf_f,  kdb_usgf_f,  1, KDB_REPEAT_NONE},
+    {"fg", kdb_cmdf_fg, kdb_usgf_fg, 1, KDB_REPEAT_NONE},
+
+    {"dw",  kdb_cmdf_dw,  kdb_usgf_dw,  1, KDB_REPEAT_NO_ARGS},
+    {"dd",  kdb_cmdf_dd,  kdb_usgf_dd,  1, KDB_REPEAT_NO_ARGS},
+    {"dwm", kdb_cmdf_dwm, kdb_usgf_dwm, 1, KDB_REPEAT_NO_ARGS},
+    {"ddm", kdb_cmdf_ddm, kdb_usgf_ddm, 1, KDB_REPEAT_NO_ARGS},
+    {"dr",  kdb_cmdf_dr,  kdb_usgf_dr,  1, KDB_REPEAT_NONE},
+    {"drg", kdb_cmdf_drg, kdb_usgf_drg, 1, KDB_REPEAT_NONE},
+
+    {"dis", kdb_cmdf_dis,  kdb_usgf_dis,  1, KDB_REPEAT_NO_ARGS},
+    {"dism",kdb_cmdf_dism, kdb_usgf_dism, 1, KDB_REPEAT_NO_ARGS},
+
+    {"mw", kdb_cmdf_mw, kdb_usgf_mw, 1, KDB_REPEAT_NONE},
+    {"md", kdb_cmdf_md, kdb_usgf_md, 1, KDB_REPEAT_NONE},
+    {"mr", kdb_cmdf_mr, kdb_usgf_mr, 1, KDB_REPEAT_NONE},
+
+    {"bc", kdb_cmdf_bc, kdb_usgf_bc, 0, KDB_REPEAT_NONE},
+    {"bp", kdb_cmdf_bp, kdb_usgf_bp, 1, KDB_REPEAT_NONE},
+    {"btp", kdb_cmdf_btp, kdb_usgf_btp, 1, KDB_REPEAT_NONE},
+
+    {"wp", kdb_cmdf_wp, kdb_usgf_wp, 1, KDB_REPEAT_NONE},
+    {"wc", kdb_cmdf_wc, kdb_usgf_wc, 0, KDB_REPEAT_NONE},
+
+    {"ni", kdb_cmdf_ni, kdb_usgf_ni, 0, KDB_REPEAT_NO_ARGS},
+    {"ss", kdb_cmdf_ss, kdb_usgf_ss, 1, KDB_REPEAT_NO_ARGS},
+    {"ssb",kdb_cmdf_ssb,kdb_usgf_ssb,0, KDB_REPEAT_NO_ARGS},
+    {"go", kdb_cmdf_go, kdb_usgf_go, 0, KDB_REPEAT_NONE},
+
+    {"cpu",kdb_cmdf_cpu, kdb_usgf_cpu, 1, KDB_REPEAT_NONE},
+    {"nmi",kdb_cmdf_nmi, kdb_usgf_nmi, 1, KDB_REPEAT_NONE},
+    {"percpu",kdb_cmdf_percpu, kdb_usgf_percpu, 1, KDB_REPEAT_NONE},
+
+    {"sym",  kdb_cmdf_sym,   kdb_usgf_sym,   1, KDB_REPEAT_NONE},
+    {"mod",  kdb_cmdf_mod,   kdb_usgf_mod,   1, KDB_REPEAT_NONE},
+
+    {"vcpuh",kdb_cmdf_vcpuh, kdb_usgf_vcpuh, 1, KDB_REPEAT_NONE},
+    {"vcpu", kdb_cmdf_vcpu,  kdb_usgf_vcpu,  1, KDB_REPEAT_NONE},
+    {"dom",  kdb_cmdf_dom,   kdb_usgf_dom,   1, KDB_REPEAT_NONE},
+
+    {"sched", kdb_cmdf_sched, kdb_usgf_sched, 1, KDB_REPEAT_NONE},
+    {"mmu",   kdb_cmdf_mmu,   kdb_usgf_mmu,   1, KDB_REPEAT_NONE},
+    {"p2m",   kdb_cmdf_p2m,   kdb_usgf_p2m,   1, KDB_REPEAT_NONE},
+    {"m2p",   kdb_cmdf_m2p,   kdb_usgf_m2p,   1, KDB_REPEAT_NONE},
+    {"dpage", kdb_cmdf_dpage, kdb_usgf_dpage, 1, KDB_REPEAT_NONE},
+    {"dmsr",  kdb_cmdf_dmsr,  kdb_usgf_dmsr, 1, KDB_REPEAT_NONE},
+    {"cpuid",  kdb_cmdf_cpuid,  kdb_usgf_cpuid, 1, KDB_REPEAT_NONE},
+    {"wept",  kdb_cmdf_wept,  kdb_usgf_wept, 1, KDB_REPEAT_NONE},
+
+    {"dtrq", kdb_cmdf_dtrq,  kdb_usgf_dtrq, 1, KDB_REPEAT_NONE},
+    {"didt", kdb_cmdf_didt,  kdb_usgf_didt, 1, KDB_REPEAT_NONE},
+    {"dgdt", kdb_cmdf_dgdt,  kdb_usgf_dgdt, 1, KDB_REPEAT_NONE},
+    {"dirq", kdb_cmdf_dirq,  kdb_usgf_dirq, 1, KDB_REPEAT_NONE},
+    {"dvit", kdb_cmdf_dvit,  kdb_usgf_dvit, 1, KDB_REPEAT_NONE},
+    {"dvmc", kdb_cmdf_dvmc,  kdb_usgf_dvmc, 1, KDB_REPEAT_NONE},
+    {"mmio", kdb_cmdf_mmio,  kdb_usgf_mmio, 1, KDB_REPEAT_NONE},
+
+    /* tracing related commands */
+    {"trcon", kdb_cmdf_trcon,  kdb_usgf_trcon,  0, KDB_REPEAT_NONE},
+    {"trcoff",kdb_cmdf_trcoff, kdb_usgf_trcoff, 0, KDB_REPEAT_NONE},
+    {"trcz",  kdb_cmdf_trcz,   kdb_usgf_trcz,   0, KDB_REPEAT_NONE},
+    {"trcp",  kdb_cmdf_trcp,   kdb_usgf_trcp,   1, KDB_REPEAT_NONE},
+
+    {"usr1",  kdb_cmdf_usr1,   kdb_usgf_usr1,   1, KDB_REPEAT_NONE},
+    {"kdbf",  kdb_cmdf_kdbf,   kdb_usgf_kdbf,   1, KDB_REPEAT_NONE},
+    {"kdbdbg",kdb_cmdf_kdbdbg, kdb_usgf_kdbdbg, 1, KDB_REPEAT_NONE},
+    {"reboot",kdb_cmdf_reboot, kdb_usgf_reboot, 1, KDB_REPEAT_NONE},
+    {"h",     kdb_cmdf_h,      kdb_usgf_h,      1, KDB_REPEAT_NONE},
+
+    {"", NULL, NULL, 0, 0},
+  };
+    kdb_cmd_tbl = _kdb_cmd_table;
+    return;
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/kdb_io.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_io.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+#include "include/kdbinc.h"
+
+#define K_BACKSPACE  0x8                   /* ctrl-H */
+#define K_BACKSPACE1 0x7f                  /* ctrl-? */
+#define K_UNDERSCORE 0x5f
+#define K_CMD_BUFSZ  160
+#define K_CMD_MAXI   (K_CMD_BUFSZ - 1)     /* max index in buffer */
+
+#if 0        /* make a history array some day */
+#define K_UP_ARROW                         /* sequence : 1b 5b 41 ie, '\e[A' */
+#define K_DN_ARROW                         /* sequence : 1b 5b 42 ie, '\e[B' */
+#define K_NUM_HIST   32
+static int cursor;
+static char cmds_a[NUM_HIST][K_CMD_BUFSZ];
+#endif
+
+static char cmds_a[K_CMD_BUFSZ];
+
+
+static int
+kdb_key_valid(int key)
+{
+    /* note: isspace() is more than ' ', hence we don't use it here */
+    if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
+            return 1;
+    return 0;
+}
+
+/* display kdb prompt and read command from the console 
+ * RETURNS: a '\n' terminated command buffer */
+char *
+kdb_get_cmdline(char *prompt)
+{
+    #define K_BELL     0x7
+    #define K_CTRL_C   0x3
+
+    int key, i=0;
+
+    kdbp(prompt);
+    memset(cmds_a, 0, K_CMD_BUFSZ);
+    cmds_a[K_CMD_BUFSZ-1] = '\n';
+
+    do {
+        key = console_getc();
+        if (key == '\r') 
+            key = '\n';
+        if (key == K_BACKSPACE1) 
+            key = K_BACKSPACE;
+
+        if (key == K_CTRL_C || (i==K_CMD_MAXI && key != '\n')) {
+            console_putc('\n');
+            if (i >= K_CMD_MAXI) {
+                kdbp("KDB: cmd buffer overflow\n");
+                console_putc(K_BELL);
+            }
+            memset(cmds_a, 0, K_CMD_BUFSZ);
+            i = 0;
+            kdbp(prompt);
+            continue;
+        }
+        if (!kdb_key_valid(key)) {
+            console_putc(K_BELL);
+            continue;
+        }
+        if (key == K_BACKSPACE) {
+            if (i==0) {
+                console_putc(K_BELL);
+                continue;
+            } else 
+                cmds_a[--i] = '\0';
+                console_putc(K_BACKSPACE);
+                console_putc(' ');        /* erase character */
+        } else
+            cmds_a[i++] = key;
+
+        console_putc(key);
+
+    } while (key != '\n');
+
+    return cmds_a;
+}
+
+/*
+ * printk takes a lock, an NMI could come in after that, and another cpu may 
+ * spin. also, the console lock is forced unlock, so panic is been seen on 
+ * 8 way. hence, no printk() calls.
+ */
+static volatile int kdbp_gate = 0;
+void
+kdbp(const char *fmt, ...)
+{
+    static char buf[1024];
+    va_list args;
+    char *p;
+    int i=0;
+
+    while ((__cmpxchg(&kdbp_gate, 0,1, sizeof(kdbp_gate)) != 0) && i++<1000)
+        mdelay(10);
+
+    va_start(args, fmt);
+    (void)vsnprintf(buf, sizeof(buf), fmt, args);
+    va_end(args);
+
+    for (p=buf; *p != '\0'; p++)
+        console_putc(*p);
+    kdbp_gate = 0;
+}
+
+
+/*
+ * copy/read machine memory. 
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mmem(kdbma_t maddr, kdbbyt_t *dbuf, int len)
+{
+    ulong remain, orig=len;
+
+    while (len > 0) {
+        ulong pagecnt = min_t(long, PAGE_SIZE-(maddr&~PAGE_MASK), len);
+        char *va = map_domain_page(maddr >> PAGE_SHIFT);
+
+        va = va + (maddr & (PAGE_SIZE-1));        /* add page offset */
+        remain = __copy_from_user(dbuf, (void *)va, pagecnt);
+        KDBGP1("maddr:%x va:%p len:%x pagecnt:%x rem:%x\n", 
+               maddr, va, len, pagecnt, remain);
+        unmap_domain_page(va);
+        len = len  - (pagecnt - remain);
+        if (remain != 0)
+            break;
+        maddr += pagecnt;
+        dbuf += pagecnt;
+    }
+    return orig - len;
+}
+
+
+/*
+ * copy/read guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mem(kdbva_t saddr, kdbbyt_t *dbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(saddr, dbuf, len, domid, 0, 0));
+}
+
+/*
+ * write guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes written
+ */
+int
+kdb_write_mem(kdbva_t daddr, kdbbyt_t *sbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(daddr, sbuf, len, domid, 1, 0));
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/kdbmain.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdbmain.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+static int kdbmain(kdb_reason_t, struct cpu_user_regs *);
+static int kdbmain_fatal(struct cpu_user_regs *, int);
+static const char *kdb_gettrapname(int);
+
+/* ======================== GLOBAL VARIABLES =============================== */
+/* All global variables used by KDB must be defined here only. Module specific
+ * static variables must be declared in respective modules.
+ */
+kdbtab_t *kdb_cmd_tbl;
+char kdb_prompt[32];
+
+volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+cpumask_t kdb_cpu_traps;           /* bit per cpu to tell which cpus hit int3 */
+
+#ifndef NDEBUG
+    #error KDB is not supported on debug xen. Turn debug off
+#endif
+
+volatile int kdb_init_cpu = -1;           /* initial kdb cpu */
+volatile int kdb_session_begun = 0;       /* active kdb session? */
+volatile int kdb_enabled = 1;             /* kdb enabled currently? */
+volatile int kdb_sys_crash = 0;           /* are we in crashed state? */
+volatile int kdbdbg = 0;                  /* to debug kdb itself */
+
+static volatile int kdb_trap_immed_reason = 0;   /* reason for immed trap */
+
+static cpumask_t kdb_fatal_cpumask;       /* which cpus in fatal path */
+
+/* return index of first bit set in val. if val is 0, retval is undefined */
+static inline unsigned int kdb_firstbit(unsigned long val)
+{
+    __asm__ ( "bsf %1,%0" : "=r" (val) : "r" (val), "0" (BITS_PER_LONG) );
+    return (unsigned int)val;
+}
+
+void noinline mukchk(unsigned long ul)
+{
+}
+
+static void 
+kdb_dbg_prnt_ctrps(char *label, int ccpu)
+{
+    int i;
+    if (!kdbdbg)
+        return;
+
+    if (label || *label)
+        kdbp("%s ", label);
+    if (ccpu != -1)
+        kdbp("ccpu:%d ", ccpu);
+    kdbp("cputrps:");
+    for (i=sizeof(kdb_cpu_traps)/sizeof(kdb_cpu_traps.bits[0]) - 1; i >=0; i--)
+        kdbp(" %lx", kdb_cpu_traps.bits[i]);
+    kdbp("\n");
+}
+
+/* 
+ * Hold this cpu. Don't disable until all CPUs in kdb to avoid IPI deadlock 
+ */
+static void
+kdb_hold_this_cpu(int ccpu, struct cpu_user_regs *regs)
+{
+    KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+    do {
+        for(; kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE; cpu_relax());
+        KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DISABLE) {
+            local_irq_disable();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DO_VMEXIT) {
+            kdb_curr_cpu_flush_vmcs();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_SHOWPC) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+    } while (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE);     /* No goto, eh! */
+    KDBGP1("un hold: ccpu:%d cmd:%d\n", ccpu, kdb_cpu_cmd[ccpu]);
+}
+
+/*
+ * Pause this cpu while one CPU does main kdb processing. If that CPU does
+ * a "cpu switch" to this cpu, this cpu will become the main kdb cpu. If the
+ * user next does single step of some sort, this function will be exited,
+ * and this cpu will come back into kdb via kdb_handle_trap_entry function.
+ */
+static void 
+kdb_pause_this_cpu(struct cpu_user_regs *regs, void *unused)
+{
+    kdbmain(KDB_REASON_PAUSE_IPI, regs);
+}
+
+/* pause other cpus via an IPI. Note, disabled CPUs can't receive IPIs until
+ * enabled */
+static void
+kdb_smp_pause_cpus(void)
+{
+    int cpu, wait_count = 0;
+    int ccpu = smp_processor_id();      /* current cpu */
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL) {
+            kdbp("KDB: won't pause cpu:%d, cmd[cpu]=%d\n",cpu,kdb_cpu_cmd[cpu]);
+            cpumask_clear_cpu(cpu, &cpumask);
+        }
+    KDBGP("ccpu:%d will pause cpus. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    on_selected_cpus(&cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0);
+#else
+    on_selected_cpus(cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0, 0);
+#endif
+    mdelay(300);                     /* wait a bit for other CPUs to stop */
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+                bummer = 1;
+        if (!bummer)
+            break;
+        kdbp("ccpu:%d trying to stop other cpus...\n", ccpu);
+        mdelay(100);  /* wait 100 ms */
+    };
+    for_each_cpu(cpu, &cpumask)          /* now check who is with us */
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+            kdbp("Bummer cpu %d not paused. ccpu:%d\n", cpu,ccpu);
+        else {
+            kdb_cpu_cmd[cpu] = KDB_CPU_DISABLE;  /* tell it to disable ints */
+            while (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE);
+        }
+}
+
+/* 
+ * Do once per kdb session:  A kdb session lasts from 
+ *    keybord/HWBP/SWBP till KDB_CPU_INSTALL_BP is done. Within a session,
+ *    user may do several cpu switches, single step, next instr,  etc..
+ *
+ * DO: 1. pause other cpus if they are not already. they would already be 
+ *        if we are in single step mode
+ *     2. watchdog_disable() 
+ *     3. uninstall all sw breakpoints so that user doesn't see them
+ */
+static void
+kdb_begin_session(void)
+{
+    if (!kdb_session_begun) {
+        kdb_session_begun = 1;
+        kdb_smp_pause_cpus();
+        local_irq_disable();
+        watchdog_disable();
+        kdb_uninstall_all_swbp();
+    }
+}
+
+int noinline mukid(void)
+{
+    return smp_processor_id();
+}
+
+static void
+kdb_smp_unpause_cpus(int ccpu)
+{
+    int cpu;
+
+    int wait_count = 0;
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+
+    KDBGP("kdb_smp_unpause_other_cpus(). ccpu:%d\n", ccpu);
+    for_each_cpu(cpu, &cpumask)
+        kdb_cpu_cmd[cpu] = KDB_CPU_QUIT;
+
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+                bummer = 1;
+            if (!bummer)
+                break;
+            mdelay(90);  /* wait 90 ms, 50 too short on large systems */
+    };
+    /* now make sure they are all in there */
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+            kdbp("KDB: cpu %d still paused (cmd==%d). ccpu:%d\n",
+                 cpu, kdb_cpu_cmd[cpu], ccpu);
+}
+
+/*
+ * End of KDB session. 
+ *   This is called at the very end. In case of multiple cpus hitting BPs
+ *   and sitting on a trap handlers, the last cpu to exit will call this.
+ *   - isnstall all sw breakpoints, and purge deleted ones from table.
+ *   - clear TF here also in case go is entered on a different cpu after switch
+ */
+static void
+kdb_end_session(int ccpu, struct cpu_user_regs *regs)
+{
+    ASSERT(!cpumask_empty(&kdb_cpu_traps));
+    ASSERT(kdb_session_begun);
+    kdb_install_all_swbp();
+    kdb_flush_swbp_table();
+    kdb_install_watchpoints();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    kdb_time_resume(1);
+    kdb_session_begun = 0;      /* before unpause for kdb_install_watchpoints */
+    kdb_smp_unpause_cpus(ccpu);
+    watchdog_enable();
+    KDBGP("end_session:ccpu:%d\n", ccpu);
+}
+volatile int mukwpprnt;
+unsigned long mukaddr1 = 0xffffffff81243ae7, mukaddr2 = 0xffffffff8100986e;
+/* 
+ * check if we entered kdb because of DB trap. If yes, then check if
+ * we caused it or someone else.
+ * RETURNS: 0 : not one of ours. hypervisor must handle it. 
+ *          1 : #DB for delayed sw bp install. 
+ *          2 : this cpu must stay in kdb.
+ */
+static noinline int
+kdb_check_dbtrap(kdb_reason_t *reasp, int ss_mode, struct cpu_user_regs *regs) 
+{
+    int rc = 2;
+    int ccpu = smp_processor_id();
+
+    /* DB excp caused by hw breakpoint or the TF flag. The TF flag is set
+     * by us for ss mode or to install breakpoints. In ss mode, none of the
+     * breakpoints are installed. Check to make sure we intended BP INSTALL
+     * so we don't do it on a spurious DB trap.
+     * check for kdb_cpu_traps here also, because each cpu sitting on a trap
+     * must execute the instruction without the BP before passing control
+     * to next cpu in kdb_cpu_traps.
+     */
+    if (*reasp == KDB_REASON_DBEXCP && !ss_mode) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP) {
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                *reasp = KDB_REASON_PAUSE_IPI;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
+                kdb_init_cpu = -1;
+            } else {
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            }
+        } else if (! kdb_check_watchpoints(regs)) {
+            rc = 0;                        /* hyp must handle it */
+        } else {
+            if (regs->rip==mukaddr1 || regs->rip==mukaddr2)
+            {
+                if (mukwpprnt)
+                    kdbp("MUK: ignoring wp:%lx\n", regs->rip);
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            } 
+        }
+    }
+    return rc;
+}
+
+/* 
+ * Misc processing on kdb entry like displaying PC, adjust IP for sw bp.... 
+ */
+static void
+kdb_main_entry_misc(kdb_reason_t reason, struct cpu_user_regs *regs, 
+                    int ccpu, int ss_mode, int enabled)
+{
+    if (reason == KDB_REASON_KEYBOARD)
+        kdbp("\nEnter kdb (cpu:%d reason:%d vcpu=%d domid:%d"
+             " eflg:0x%lx irqs:%d)\n", ccpu, reason, current->vcpu_id, 
+             current->domain->domain_id, regs->eflags, enabled);
+    else if (ss_mode)
+        KDBGP1("KDBG: KDB single step mode. ccpu:%d\n", ccpu);
+
+    if (reason == KDB_REASON_BPEXCP && !ss_mode) 
+        kdbp("Breakpoint on cpu %d at 0x%lx\n", ccpu, regs->KDBIP);
+
+    /* display the current PC and instruction at it */
+    if (reason != KDB_REASON_PAUSE_IPI)
+        kdb_display_pc(regs);
+    console_start_sync();
+}
+
+/* 
+ * The MAIN kdb function. All cpus go thru this. IRQ is enabled on entry because
+ * a cpu could hit a bp set in disabled code.
+ * IPI: Even the main cpu must enable in case another CPU is trying to IPI us.
+ *      That way, it would IPI us, then get out and be ready for our pause IPI.
+ * IRQs: The reason irqs enable/disable is scattered is because on a typical
+ *       system IPIs are constantly going on amongs CPUs in a set of any size. 
+ *       As a result,  to avoid deadlock, cpus have to loop enabled, until a 
+ *       quorum is established and the session has begun.
+ * Step: Intel Vol3B 18.3.1.4 : An external interrupt may be serviced upon
+ *       single step. Since, the likely ext timer_interrupt and 
+ *       apic_timer_interrupt dont' mess with time data structs, we are prob OK
+ *       leaving enabled.
+ * Time: Very messy. Most platform timers are readonly, so we can't stop time
+ *       in the debugger. We take the only resort, let the TSC and plt run as
+ *       normal, upon leaving, "attempt" to bring everybody to current time.
+ * kdbcputraps: bit per cpu. each cpu sets it bit in entry.S. The bit is 
+ *              reliable because upon traps, Ints are disabled. the bit is set
+ *              before Ints are enabled.
+ *
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+static int
+kdbmain(kdb_reason_t reason, struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();                /* current cpu */
+    int rc = 1, cmd = kdb_cpu_cmd[ccpu];
+    int ss_mode = (cmd == KDB_CPU_SS || cmd == KDB_CPU_NI);
+    int delayed_install = (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP);
+    int enabled = local_irq_is_enabled();
+
+    KDBGP("kdbmain:ccpu:%d rsn:%d eflgs:0x%lx cmd:%d initc:%d irqs:%d "
+          "regs:%lx IP:%lx ", ccpu, reason, regs->eflags, cmd, 
+          kdb_init_cpu, enabled, regs, regs->KDBIP);
+    kdb_dbg_prnt_ctrps("", -1);
+
+    if (!ss_mode && !delayed_install)    /* initial kdb enter */
+        local_irq_enable();              /* so we can receive IPI */
+
+    if (!ss_mode && ccpu != kdb_init_cpu && reason != KDB_REASON_PAUSE_IPI){
+        int sz = sizeof(kdb_init_cpu);
+        while (__cmpxchg(&kdb_init_cpu, -1, ccpu, sz) != -1)
+            for(; kdb_init_cpu != -1; cpu_relax());
+    }
+    if (kdb_session_begun)
+        local_irq_disable();             /* kdb always runs disabled */
+
+    if (reason == KDB_REASON_BPEXCP) {             /* INT 3 */
+        cpumask_clear_cpu(ccpu, &kdb_cpu_traps);   /* remove ourself */
+        rc = kdb_check_sw_bkpts(regs);
+        if (rc == 0) {               /* not one of ours. leave kdb */
+            kdb_init_cpu = -1;
+            goto out;
+        } else if (rc == 1) {        /* one of ours but deleted */
+            if (cpumask_empty(&kdb_cpu_traps)) {
+                kdb_end_session(ccpu,regs);     
+                kdb_init_cpu = -1;
+                goto out;
+            } else {                 
+                /* release another trap cpu, and put ourself in a pause mode */
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d cmd:%d rsn:%d atrpcpu:%d initcpu:%d\n", ccpu, 
+                      kdb_cpu_cmd[ccpu], reason, a_trap_cpu, kdb_init_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                reason = KDB_REASON_PAUSE_IPI;
+                kdb_init_cpu = -1;
+            }
+        } else if (rc == 2) {        /* one of ours but condition not met */
+                kdb_begin_session();
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+        }
+    }
+
+    /* following will take care of KDB_CPU_INSTALL_BP, and also release
+     * kdb_init_cpu. it should not be done twice */
+    if ((rc=kdb_check_dbtrap(&reason, ss_mode, regs)) == 0 || rc == 1) {
+        kdb_init_cpu = -1;       /* leaving kdb */
+        goto out;                /* rc properly set to 0 or 1 */
+    }
+    if (reason != KDB_REASON_PAUSE_IPI) {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+    } else
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB && !ss_mode)
+        kdb_begin_session(); 
+
+    kdb_main_entry_misc(reason, regs, ccpu, ss_mode, enabled);
+    /* note, one or more cpu switches may occur in between */
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+            if (ccpu != kdb_init_cpu) {
+                kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_GO;
+                kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+                continue;               /* for the pause guy */
+            }
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                /* execute current instruction without 0xcc */
+                kdb_dbg_prnt_ctrps("nempty:", ccpu);
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            }
+        }
+        if (kdb_cpu_cmd[ccpu] != KDB_CPU_PAUSE  && 
+            kdb_cpu_cmd[ccpu] != KDB_CPU_MAIN_KDB)
+                break;
+    }
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+        ASSERT(cpumask_empty(&kdb_cpu_traps));
+        if (kdb_swbp_exists()) {
+            if (reason == KDB_REASON_BPEXCP) {
+                /* do delayed install */
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            } 
+        }
+        kdb_end_session(ccpu, regs);
+        kdb_init_cpu = -1;
+    }
+out:
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_QUIT) {
+        KDBGP("ccpu:%d _quit IP: %lx\n", ccpu, regs->KDBIP);
+        if (! kdb_session_begun)
+            kdb_install_watchpoints();
+        kdb_time_resume(0);
+        kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    }
+
+    /* for ss and delayed install, TF is set. not much in EXT INT handlers*/
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_NI)
+        kdb_time_resume(1);
+    if (enabled)
+        local_irq_enable();
+
+    KDBGP("kdbmain:X:ccpu:%d rc:%d cmd:%d eflg:0x%lx initc:%d sesn:%d " 
+          "cs:%x irqs:%d ", ccpu, rc, kdb_cpu_cmd[ccpu], regs->eflags, 
+          kdb_init_cpu, kdb_session_begun, regs->cs, local_irq_is_enabled());
+    kdb_dbg_prnt_ctrps("", -1);
+    return (rc ? 1 : 0);
+}
+
+/* 
+ * kdb entry function when coming in via a keyboard
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+int
+kdb_keyboard(struct cpu_user_regs *regs)
+{
+    return kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+
+#if 0
+/*
+ * this function called when kdb session active and user presses ctrl\ again.
+ * the assumption is that the user typed ni/ss cmd, and it never got back into
+ * kdb, or the user is impatient. Either case, we just fake it that the SS did
+ * finish. Since, all other kdb cpus must be holding disabled, the interrupt
+ * would be on the CPU that did the ss/ni cmd
+ */
+void
+kdb_ssni_reenter(struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();
+    int ccmd = kdb_cpu_cmd[ccpu];
+
+    if(ccmd == KDB_CPU_SS || ccmd == KDB_CPU_INSTALL_BP)
+        kdbmain(KDB_REASON_DBEXCP, regs); 
+    else 
+        kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+#endif
+
+/* 
+ * All traps are routed thru here. We care about BP (#3) trap (INT 3) and
+ * the DB trap(#1) only. 
+ * returns: 0 kdb has nothing do with this trap
+ *          1 kdb handled this trap 
+ */
+int
+kdb_handle_trap_entry(int vector, struct cpu_user_regs *regs)
+{
+    int rc = 0;
+    int ccpu = smp_processor_id();
+
+    if (vector == TRAP_int3) {
+        rc = kdbmain(KDB_REASON_BPEXCP, regs);
+
+    } else if (vector == TRAP_debug) {
+        KDBGP("ccpu:%d trapdbg reas:%d\n", ccpu, kdb_trap_immed_reason);
+
+        if (kdb_trap_immed_reason == KDB_TRAP_FATAL) { 
+            KDBGP("kdbtrp:fatal ccpu:%d vec:%d\n", ccpu, vector);
+            rc = kdbmain_fatal(regs, vector);
+            BUG();                             /* no return */
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_KDBSTACK) {
+            kdb_trap_immed_reason = 0;         /* show kdb stack */
+            show_registers(regs);
+            show_stack(regs);
+            regs->eflags &= ~X86_EFLAGS_TF;
+            rc = 1;
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_NONFATAL) {
+            kdb_trap_immed_reason = 0;
+            rc = kdb_keyboard(regs);
+        } else {                         /* ss/ni/delayed install... */
+            if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                current->arch.hvm_vcpu.single_step = 0;
+            rc = kdbmain(KDB_REASON_DBEXCP, regs); 
+        }
+
+    } else if (vector == TRAP_nmi) {                   /* external nmi */
+        /* when nmi is pressed, it could go to one or more or all cpus
+         * depending on the hardware. Also, for now assume it's fatal */
+        KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
+        rc = kdbmain_fatal(regs, TRAP_nmi);
+    } 
+    return rc;
+}
+
+int
+kdb_trap_fatal(int vector, struct cpu_user_regs *regs)
+{
+    kdbmain_fatal(regs, vector);
+    return 0;
+}
+
+/* From smp_send_nmi_allbutself() in crash.c which is static */
+void
+kdb_nmi_pause_cpus(cpumask_t cpumask)
+{
+    int ccpu = smp_processor_id();
+    mdelay(200);
+    cpumask_complement(&cpumask, &cpumask);              /* flip bit map */
+    cpumask_and(&cpumask, &cpumask, &cpu_online_map);    /* remove extra bits */
+    cpumask_clear_cpu(ccpu, &cpumask);/* absolutely make sure we're not on it */
+
+    KDBGP("ccpu:%d nmi pause. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+    if ( !cpumask_empty(&cpumask) )
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+        send_IPI_mask(&cpumask, APIC_DM_NMI);
+#else
+        send_IPI_mask(cpumask, APIC_DM_NMI);
+#endif
+    mdelay(200);
+    KDBGP("ccpu:%d nmi pause done...\n", ccpu);
+}
+
+/* 
+ * Separate function from kdbmain to keep both within sanity levels.
+ */
+DEFINE_SPINLOCK(kdb_fatal_lk);
+static int
+kdbmain_fatal(struct cpu_user_regs *regs, int vector)
+{
+    int ccpu = smp_processor_id();
+
+    console_start_sync();
+
+    KDBGP("mainf:ccpu:%d vec:%d irq:%d\n", ccpu, vector,local_irq_is_enabled());
+    cpumask_set_cpu(ccpu, &kdb_fatal_cpumask);        /* uses LOCK_PREFIX */
+
+    if (spin_trylock(&kdb_fatal_lk)) {
+
+        kdbp("*** kdb (Fatal Error on cpu:%d vec:%d %s):\n", ccpu,
+             vector, kdb_gettrapname(vector));
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+        kdb_display_pc(regs);
+
+        watchdog_disable();     /* important */
+        kdb_sys_crash = 1;
+        kdb_session_begun = 0;  /* incase session already active */
+        local_irq_enable();
+        kdb_nmi_pause_cpus(kdb_fatal_cpumask);
+
+        kdb_clear_prev_cmd();   /* buffered CRs will repeat prev cmd */
+        kdb_session_begun = 1;  /* for kdb_hold_this_cpu() */
+        local_irq_disable();
+    } else {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+    }
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+#if 0
+        /* dump is the only way to exit in crashed state */
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DUMP)
+            kdb_do_dump(regs);
+#endif
+    }
+    return 0;
+}
+
+/* Mostly called in fatal cases. earlykdb calls non-fatal.
+ * kdb_trap_immed_reason is global, so allow only one cpu at a time. Also,
+ * multiple cpu may be crashing at the same time. We enable because if there
+ * is a bad hang, at least ctrl-\ will break into kdb. Also, we don't call
+ * call kdb_keyboard directly becaue we don't have the register context.
+ */
+DEFINE_SPINLOCK(kdb_immed_lk);
+void
+kdb_trap_immed(int reason)            /* fatal, non-fatal, kdb stack etc... */
+{
+    int ccpu = smp_processor_id();
+    int disabled = !local_irq_is_enabled();
+
+    KDBGP("trapimm:ccpu:%d reas:%d\n", ccpu, reason);
+    local_irq_enable();
+    spin_lock(&kdb_immed_lk);
+    kdb_trap_immed_reason = reason;
+    barrier();
+    __asm__ __volatile__ ( "int $1" );
+    kdb_trap_immed_reason = 0;
+
+    spin_unlock(&kdb_immed_lk);
+    if (disabled)
+        local_irq_disable();
+}
+
+/* called very early during init, even before all CPUs are brought online */
+void 
+kdb_init(void)
+{
+        kdb_init_cmdtab();      /* Initialize Command Table */
+}
+
+static const char *
+kdb_gettrapname(int trapno)
+{
+    char *ret;
+    switch (trapno) {
+        case  0:  ret = "Divide Error"; break;
+        case  2:  ret = "NMI Interrupt"; break;
+        case  3:  ret = "Int 3 Trap"; break;
+        case  4:  ret = "Overflow Error"; break;
+        case  6:  ret = "Invalid Opcode"; break;
+        case  8:  ret = "Double Fault"; break;
+        case 10:  ret = "Invalid TSS"; break;
+        case 11:  ret = "Segment Not Present"; break;
+        case 12:  ret = "Stack-Segment Fault"; break;
+        case 13:  ret = "General Protection"; break;
+        case 14:  ret = "Page Fault"; break;
+        case 17:  ret = "Alignment Check"; break;
+        default: ret = " ????? ";
+    }
+    return ret;
+}
+
+
+/* ====================== Generic tracing subsystem ======================== */
+
+#define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
+                           * is 32 bytes */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
+
+typedef struct {
+    union {
+        struct { uint d0; uint cpu_trcid; } s0;
+        uint64_t l0;
+    }u;
+    uint64_t l1, l2, l3; 
+} trc_rec_t;
+
+static volatile unsigned int trcidx;    /* points to where new entry will go */
+static trc_rec_t trca[KDBTRCMAX];       /* trace array */
+
+/* atomically: add i to *p, return prev value of *p (ie, val before add) */
+static int
+kdb_fetch_and_add(int i, uint *p)
+{
+    asm volatile("lock xaddl %0, %1;" : "=r"(i) : "m"(*p), "0"(i));
+    return i;
+}
+
+/* zero out the entire buffer */
+void 
+kdb_trczero(void)
+{
+    for (trcidx = KDBTRCMAX-1; trcidx; trcidx--) {
+        memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    }
+    memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    kdbp("kdb trace buffer has been zeroed\n");
+}
+
+/* add trace entry: eg.: kdbtrc(0xe0f099, intdata, vcpu, domain, 0)
+ *    where:  0xe0f099 : 24bits max trcid, lower 8 bits are set to cpuid */
+void
+kdbtrc(uint trcid, uint int_d0, uint64_t d1_64, uint64_t d2_64, uint64_t d3_64)
+{
+    uint idx;
+
+    if (!kdb_trcon)
+        return;
+
+    idx = kdb_fetch_and_add(1, (uint*)&trcidx);
+    idx = idx % KDBTRCMAX;
+
+#if 0
+    trca[idx].u.s0.cpu_trcid = (smp_processor_id()<<24) | trcid;
+#endif
+    trca[idx].u.s0.cpu_trcid = (trcid<<8) | smp_processor_id();
+    trca[idx].u.s0.d0 = int_d0;
+    trca[idx].l1 = d1_64;
+    trca[idx].l2 = d2_64;
+    trca[idx].l3 = d3_64;
+}
+
+/* give hints so user can print trc buffer via the dd command. last has the
+ * most recent entry */
+void
+kdb_trcp(void)
+{
+    int i = trcidx % KDBTRCMAX;
+
+    i = (i==0) ? KDBTRCMAX-1 : i-1;
+    kdbp("trcbuf:    [0]: %016lx [MAX-1]: %016lx\n", &trca[0],
+         &trca[KDBTRCMAX-1]);
+    kdbp(" [most recent]: %016lx   trcidx: 0x%x\n", &trca[i], trcidx);
+}
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y    := kdb_wp.o
+subdir-y += udis86-1.7
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/kdb_wp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/kdb_wp.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,310 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+#if 0
+#define DR6_BT  0x00008000
+#define DR6_BS  0x00004000
+#define DR6_BD  0x00002000
+#endif
+#define DR6_B3  0x00000008
+#define DR6_B2  0x00000004
+#define DR6_B1  0x00000002
+#define DR6_B0  0x00000001
+
+#define KDB_MAXWP 4                          /* DR0 thru DR3 */
+
+struct kdb_wp {
+    kdbma_t  wp_addr;
+    int      wp_rwflag;
+    int      wp_len;
+    int      wp_deleted;                     /* pending delete */
+};
+static struct kdb_wp kdb_wpa[KDB_MAXWP];
+
+/* following because vmcs has it's own dr7. when vmcs runs, it messes up the
+ * native dr7 so we need to save/restore it */
+unsigned long kdb_dr7;
+
+
+/* Set G0-G3 bits in DR7. this does global enable of the corresponding wp */
+static void
+kdb_set_gx_in_dr7(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p | 0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p | 0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p | 0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p | 0x80;
+}
+
+/* Set LEN0 - LEN3 pair bits in DR7 (len should be 1 2 4 or 8) */
+static void
+kdb_set_len_in_dr7(int regno, kdbma_t *dr7p, int len)
+{
+    int lenbits = (len == 8) ? 2 : len-1;
+
+    *dr7p &= ~(0x3 << (18 + 4*regno));
+    *dr7p |= ((ulong)(lenbits & 0x3) << (18 + 4*regno));
+}
+
+static void
+kdb_set_dr7_rw(int regno, kdbma_t *dr7p, int rw)
+{
+    *dr7p &= ~(0x3 << (16 + 4*regno));
+    *dr7p |= ((ulong)(rw & 0x3)) << (16 + 4*regno);
+}
+
+/* get value of a debug register: DR0-DR3 DR6 DR7. other values return 0 */
+kdbma_t
+kdb_rd_dbgreg(int regnum)
+{
+    kdbma_t contents = 0;
+
+    if (regnum == 0)
+        __asm__ ("movq %%db0,%0\n\t":"=r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %%db1,%0\n\t":"=r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %%db2,%0\n\t":"=r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %%db3,%0\n\t":"=r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %%db6,%0\n\t":"=r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %%db7,%0\n\t":"=r"(contents));
+
+    return contents;
+}
+
+static void
+kdb_wr_dbgreg(int regnum, kdbma_t contents)
+{
+    if (regnum == 0)
+        __asm__ ("movq %0,%%db0\n\t"::"r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %0,%%db1\n\t"::"r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %0,%%db2\n\t"::"r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %0,%%db3\n\t"::"r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %0,%%db6\n\t"::"r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %0,%%db7\n\t"::"r"(contents));
+}
+
+static void
+kdb_print_wp_info(char *strp, int idx)
+{
+    kdbp("%s[%d]:%016lx len:%d ", strp, idx, kdb_wpa[idx].wp_addr,
+         kdb_wpa[idx].wp_len);
+    if (kdb_wpa[idx].wp_rwflag == 1)
+        kdbp("on data write only\n");
+    else if (kdb_wpa[idx].wp_rwflag == 2)
+        kdbp("on IO read/write\n");
+    else 
+        kdbp("on data read/write\n");
+}
+
+/*
+ * Returns : 0 if not one of ours
+ *           1 if one of ours
+ */
+int
+kdb_check_watchpoints(struct cpu_user_regs *regs)
+{
+    int wpnum;
+    kdbma_t dr6 = kdb_rd_dbgreg(6);
+
+    KDBGP1("check_wp: IP:%lx EFLAGS:%lx\n", regs->rip, regs->rflags);
+    if (dr6 & DR6_B0)
+        wpnum = 0;
+    else if (dr6 & DR6_B1)
+        wpnum = 1;
+    else if (dr6 & DR6_B2)
+        wpnum = 2;
+    else if (dr6 & DR6_B3)
+        wpnum = 3;
+    else
+        return 0;
+
+    kdb_print_wp_info("Watchpoint ", wpnum);
+    return 1;
+}
+
+/* set a watchpoint at a given address 
+ * PreCondition: addr != 0 */
+static void
+kdb_set_wp(kdbva_t addr, int rwflag, int len)
+{
+    int regno;
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        if (kdb_wpa[regno].wp_addr == addr && !kdb_wpa[regno].wp_deleted) {
+            kdbp("Watchpoint already set\n");
+            return;
+        }
+        if (kdb_wpa[regno].wp_deleted)
+            memset(&kdb_wpa[regno], 0, sizeof(kdb_wpa[regno]));
+    }
+    for (regno=0; regno < KDB_MAXWP && kdb_wpa[regno].wp_addr; regno++);
+    if (regno >= KDB_MAXWP) {
+        kdbp("watchpoint table full. limit:%d\n", KDB_MAXWP);
+        return;
+    }
+    kdb_wpa[regno].wp_addr = addr;
+    kdb_wpa[regno].wp_rwflag = rwflag;
+    kdb_wpa[regno].wp_len = len;
+    kdb_print_wp_info("Watchpoint set ", regno);
+}
+
+/* write reg DR0-3 with address. Update corresponding bits in DR7 */
+static void
+kdb_install_watchpoint(int regno, kdbma_t *dr7p)
+{
+    kdb_set_gx_in_dr7(regno, dr7p);
+    kdb_set_len_in_dr7(regno, dr7p, kdb_wpa[regno].wp_len); 
+    kdb_set_dr7_rw(regno, dr7p, kdb_wpa[regno].wp_rwflag);
+    kdb_wr_dbgreg(regno, kdb_wpa[regno].wp_addr);
+
+    KDBGP1("ccpu:%d installed wp. addr:%lx rw:%x len:%x dr7:%016lx\n",
+           smp_processor_id(), kdb_wpa[regno].wp_addr, 
+           kdb_wpa[regno].wp_rwflag, kdb_wpa[regno].wp_len, *dr7p);
+}
+
+/* clear G0-G3 bits in DR7 for given DR0-3 */
+static void
+kdb_clear_dr7_gx(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p & ~0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p & ~0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p & ~0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p & ~0x80;
+}
+
+/* update dr7 once, as it's slow to update debug regs and cpu's will still be 
+ * paused when leaving kdb.
+ *
+ * Just leave DR0-3 clobbered but remove bits from DR7 to disable wp 
+ */
+void
+kdb_install_watchpoints(void)
+{
+    int regno;
+    kdbma_t dr7 = kdb_rd_dbgreg(7);
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        /* do not clear wp_deleted here as all cpus must clear wps */
+        if (kdb_wpa[regno].wp_deleted) {
+            kdb_clear_dr7_gx(regno, &dr7);
+            continue;
+        }
+        if (kdb_wpa[regno].wp_addr)
+            kdb_install_watchpoint(regno, &dr7);
+    }
+    /* always clear DR6 when leaving */
+    kdb_wr_dbgreg(6, 0);
+    kdb_wr_dbgreg(7, dr7);
+
+    if (dr7 & DR7_ACTIVE_MASK)
+        kdb_dr7 = dr7;
+    else
+        kdb_dr7 = 0;
+#if 0
+    for(dp=domain_list; dp; dp=dp->next_in_list) {
+        struct vcpu *vp;
+        for_each_vcpu(dp, vp) {
+            for (regno=0; regno < KDB_MAXWP; regno++)
+                vp->arch.guest_context.debugreg[regno] = kdb_wpa[regno].wp_addr;
+
+            vp->arch.guest_context.debugreg[6] = 0;
+            vp->arch.guest_context.debugreg[7] = dr7;
+            KDBGP("kdb_install_watchpoints(): v:%p dr7:%lx\n", vp, dr7);
+            /* hvm_set_info_guest(vp);: Can't because can't vmcs_enter in kdb */
+        }
+    }
+#endif
+}
+
+/* clear watchpoint/s. wpnum == -1 to clear all watchpoints */
+void
+kdb_clear_wps(int wpnum)
+{
+    int i;
+
+    if (wpnum >= KDB_MAXWP) {
+        kdbp("Invalid wpnum %d\n", wpnum);
+        return;
+    }
+    if (wpnum >=0) {
+        if (kdb_wpa[wpnum].wp_addr) {
+            kdb_wpa[wpnum].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", wpnum);
+        } else
+            kdbp("watchpoint %d not set\n", wpnum);
+        return;
+    }
+    for (i=0; i < KDB_MAXWP; i++) {
+        if (kdb_wpa[i].wp_addr) {
+            kdb_wpa[i].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", i);
+        }
+    }
+}
+
+/* display any watchpoints that are set */
+static void
+kdb_display_wps(void)
+{
+    int i;
+    for (i=0; i < KDB_MAXWP; i++)
+        if (kdb_wpa[i].wp_addr && !kdb_wpa[i].wp_deleted) 
+            kdb_print_wp_info("", i);
+}
+
+/* 
+ * Display or Set hardware breakpoints, ie, watchpoints:
+ *   - Upto 4 are allowed
+ *   
+ *  rw_flag should be one of: 
+ *     01 == break on data write only
+ *     10 == break on IO read/write
+ *     11 == Break on data reads or writes
+ *
+ *  len should be one of : 1 2 4 8 
+ */
+void
+kdb_do_watchpoints(kdbva_t addr, int rw_flag, int len)
+{
+    if (addr == 0) {
+        kdb_display_wps();        /* display set watchpoints */
+        return;
+    }
+    kdb_set_wp(addr, rw_flag, len);
+    return;
+}
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/LICENSE
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/LICENSE	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,22 @@
+Copyright (c) 2002, 2003, 2004, 2005, 2006 <vivek@sig9.com>
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, 
+are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice, 
+      this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright notice, 
+      this list of conditions and the following disclaimer in the documentation 
+      and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/Makefile	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,5 @@
+
+CFLAGS		+= -D__UD_STANDALONE__
+obj-y		:= decode.o input.o itab.o kdb_dis.o syn-att.o syn.o \
+                   syn-intel.o udis86.o
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/README	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,10 @@
+
+http://udis86.sourceforge.net/
+udis86-1.6 : 
+  - cd libudis86
+  - cp *c to here
+  - cp *h to here
+   
+Mukesh Rathor
+04/30/2008
+
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/decode.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,1197 @@
+/* -----------------------------------------------------------------------------
+ * decode.c
+ *
+ * Copyright (c) 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <assert.h>
+#include <string.h>
+#endif
+
+#include "types.h"
+#include "itab.h"
+#include "input.h"
+#include "decode.h"
+
+/* The max number of prefixes to an instruction */
+#define MAX_PREFIXES    15
+
+static struct ud_itab_entry ie_invalid = { UD_Iinvalid, O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_pause   = { UD_Ipause,   O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_nop     = { UD_Inop,     O_NONE, O_NONE, O_NONE, P_none };
+
+
+/* Looks up mnemonic code in the mnemonic string table
+ * Returns NULL if the mnemonic code is invalid
+ */
+const char * ud_lookup_mnemonic( enum ud_mnemonic_code c )
+{
+    if ( c < UD_Id3vil )
+        return ud_mnemonics_str[ c ];
+    return NULL;
+}
+
+
+/* Extracts instruction prefixes.
+ */
+static int get_prefixes( struct ud* u )
+{
+    unsigned int have_pfx = 1;
+    unsigned int i;
+    uint8_t curr;
+
+    /* if in error state, bail out */
+    if ( u->error ) 
+        return -1; 
+
+    /* keep going as long as there are prefixes available */
+    for ( i = 0; have_pfx ; ++i ) {
+
+        /* Get next byte. */
+        inp_next(u); 
+        if ( u->error ) 
+            return -1;
+        curr = inp_curr( u );
+
+        /* rex prefixes in 64bit mode */
+        if ( u->dis_mode == 64 && ( curr & 0xF0 ) == 0x40 ) {
+            u->pfx_rex = curr;  
+        } else {
+            switch ( curr )  
+            {
+            case 0x2E : 
+                u->pfx_seg = UD_R_CS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x36 :     
+                u->pfx_seg = UD_R_SS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x3E : 
+                u->pfx_seg = UD_R_DS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x26 : 
+                u->pfx_seg = UD_R_ES; 
+                u->pfx_rex = 0;
+                break;
+            case 0x64 : 
+                u->pfx_seg = UD_R_FS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x65 : 
+                u->pfx_seg = UD_R_GS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x67 : /* adress-size override prefix */ 
+                u->pfx_adr = 0x67;
+                u->pfx_rex = 0;
+                break;
+            case 0xF0 : 
+                u->pfx_lock = 0xF0;
+                u->pfx_rex  = 0;
+                break;
+            case 0x66: 
+                /* the 0x66 sse prefix is only effective if no other sse prefix
+                 * has already been specified.
+                 */
+                if ( !u->pfx_insn ) u->pfx_insn = 0x66;
+                u->pfx_opr = 0x66;           
+                u->pfx_rex = 0;
+                break;
+            case 0xF2:
+                u->pfx_insn  = 0xF2;
+                u->pfx_repne = 0xF2; 
+                u->pfx_rex   = 0;
+                break;
+            case 0xF3:
+                u->pfx_insn = 0xF3;
+                u->pfx_rep  = 0xF3; 
+                u->pfx_repe = 0xF3; 
+                u->pfx_rex  = 0;
+                break;
+            default : 
+                /* No more prefixes */
+                have_pfx = 0;
+                break;
+            }
+        }
+
+        /* check if we reached max instruction length */
+        if ( i + 1 == MAX_INSN_LENGTH ) {
+            u->error = 1;
+            break;
+        }
+    }
+
+    /* return status */
+    if ( u->error ) 
+        return -1; 
+
+    /* rewind back one byte in stream, since the above loop 
+     * stops with a non-prefix byte. 
+     */
+    inp_back(u);
+
+    /* speculatively determine the effective operand mode,
+     * based on the prefixes and the current disassembly
+     * mode. This may be inaccurate, but useful for mode
+     * dependent decoding.
+     */
+    if ( u->dis_mode == 64 ) {
+        u->opr_mode = REX_W( u->pfx_rex ) ? 64 : ( ( u->pfx_opr ) ? 16 : 32 ) ;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 64;
+    } else if ( u->dis_mode == 32 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+        u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+    } else if ( u->dis_mode == 16 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+    }
+
+    return 0;
+}
+
+
+/* Searches the instruction tables for the right entry.
+ */
+static int search_itab( struct ud * u )
+{
+    struct ud_itab_entry * e = NULL;
+    enum ud_itab_index table;
+    uint8_t peek;
+    uint8_t did_peek = 0;
+    uint8_t curr; 
+    uint8_t index;
+
+    /* if in state of error, return */
+    if ( u->error ) 
+        return -1;
+
+    /* get first byte of opcode. */
+    inp_next(u); 
+    if ( u->error ) 
+        return -1;
+    curr = inp_curr(u); 
+
+    /* resolve xchg, nop, pause crazyness */
+    if ( 0x90 == curr ) {
+        if ( !( u->dis_mode == 64 && REX_B( u->pfx_rex ) ) ) {
+            if ( u->pfx_rep ) {
+                u->pfx_rep = 0;
+                e = & ie_pause;
+            } else {
+                e = & ie_nop;
+            }
+            goto found_entry;
+        }
+    }
+
+    /* get top-level table */
+    if ( 0x0F == curr ) {
+        table = ITAB__0F;
+        curr  = inp_next(u);
+        if ( u->error )
+            return -1;
+
+        /* 2byte opcodes can be modified by 0x66, F3, and F2 prefixes */
+        if ( 0x66 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSE66__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSE66__0F;
+                u->pfx_opr = 0;
+            }
+        } else if ( 0xF2 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF2__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF2__0F; 
+                u->pfx_repne = 0;
+            }
+        } else if ( 0xF3 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF3__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF3__0F;
+                u->pfx_repe = 0;
+                u->pfx_rep  = 0;
+            }
+        }
+    /* pick an instruction from the 1byte table */
+    } else {
+        table = ITAB__1BYTE; 
+    }
+
+    index = curr;
+
+search:
+
+    e = & ud_itab_list[ table ][ index ];
+
+    /* if mnemonic constant is a standard instruction constant
+     * our search is over.
+     */
+    
+    if ( e->mnemonic < UD_Id3vil ) {
+        if ( e->mnemonic == UD_Iinvalid ) {
+            if ( did_peek ) {
+                inp_next( u ); if ( u->error ) return -1;
+            }
+            goto found_entry;
+        }
+        goto found_entry;
+    }
+
+    table = e->prefix;
+
+    switch ( e->mnemonic )
+    {
+    case UD_Igrp_reg:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_REG( peek );
+        break;
+
+    case UD_Igrp_mod:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_MOD( peek );
+        if ( index == 3 )
+           index = ITAB__MOD_INDX__11;
+        else 
+           index = ITAB__MOD_INDX__NOT_11; 
+        break;
+
+    case UD_Igrp_rm:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = MODRM_RM( curr );
+        break;
+
+    case UD_Igrp_x87:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = curr - 0xC0;
+        break;
+
+    case UD_Igrp_osize:
+        if ( u->opr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->opr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+ 
+    case UD_Igrp_asize:
+        if ( u->adr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->adr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;               
+
+    case UD_Igrp_mode:
+        if ( u->dis_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->dis_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+
+    case UD_Igrp_vendor:
+        if ( u->vendor == UD_VENDOR_INTEL ) 
+            index = ITAB__VENDOR_INDX__INTEL; 
+        else if ( u->vendor == UD_VENDOR_AMD )
+            index = ITAB__VENDOR_INDX__AMD;
+        else {
+            kdbp("KDB:search_itab(): unrecognized vendor id\n");
+            return -1;
+        }
+        break;
+
+    case UD_Id3vil:
+        kdbp("KDB:search_itab(): invalid instr mnemonic constant Id3vil\n");
+        return -1;
+
+    default:
+        kdbp("KDB:search_itab(): invalid instruction mnemonic constant\n");
+        return -1;
+    }
+
+    goto search;
+
+found_entry:
+
+    u->itab_entry = e;
+    u->mnemonic = u->itab_entry->mnemonic;
+
+    return 0;
+}
+
+
+static unsigned int resolve_operand_size( const struct ud * u, unsigned int s )
+{
+    switch ( s ) 
+    {
+    case SZ_V:
+        return ( u->opr_mode );
+    case SZ_Z:  
+        return ( u->opr_mode == 16 ) ? 16 : 32;
+    case SZ_P:  
+        return ( u->opr_mode == 16 ) ? SZ_WP : SZ_DP;
+    case SZ_MDQ:
+        return ( u->opr_mode == 16 ) ? 32 : u->opr_mode;
+    case SZ_RDQ:
+        return ( u->dis_mode == 64 ) ? 64 : 32;
+    default:
+        return s;
+    }
+}
+
+
+static int resolve_mnemonic( struct ud* u )
+{
+  /* far/near flags */
+  u->br_far = 0;
+  u->br_near = 0;
+  /* readjust operand sizes for call/jmp instrcutions */
+  if ( u->mnemonic == UD_Icall || u->mnemonic == UD_Ijmp ) {
+    /* WP: 16bit pointer */
+    if ( u->operand[ 0 ].size == SZ_WP ) {
+        u->operand[ 0 ].size = 16;
+        u->br_far = 1;
+        u->br_near= 0;
+    /* DP: 32bit pointer */
+    } else if ( u->operand[ 0 ].size == SZ_DP ) {
+        u->operand[ 0 ].size = 32;
+        u->br_far = 1;
+        u->br_near= 0;
+    } else {
+        u->br_far = 0;
+        u->br_near= 1;
+    }
+  /* resolve 3dnow weirdness. */
+  } else if ( u->mnemonic == UD_I3dnow ) {
+    u->mnemonic = ud_itab_list[ ITAB__3DNOW ][ inp_curr( u )  ].mnemonic;
+  }
+  /* SWAPGS is only valid in 64bits mode */
+  if ( u->mnemonic == UD_Iswapgs && u->dis_mode != 64 ) {
+    u->error = 1;
+    return -1;
+  }
+
+  return 0;
+}
+
+
+/* -----------------------------------------------------------------------------
+ * decode_a()- Decodes operands of the type seg:offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_a(struct ud* u, struct ud_operand *op)
+{
+  if (u->opr_mode == 16) {  
+    /* seg16:off16 */
+    op->type = UD_OP_PTR;
+    op->size = 32;
+    op->lval.ptr.off = inp_uint16(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  } else {
+    /* seg16:off32 */
+    op->type = UD_OP_PTR;
+    op->size = 48;
+    op->lval.ptr.off = inp_uint32(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_gpr() - Returns decoded General Purpose Register 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+decode_gpr(register struct ud* u, unsigned int s, unsigned char rm)
+{
+  s = resolve_operand_size(u, s);
+        
+  switch (s) {
+    case 64:
+        return UD_R_RAX + rm;
+    case SZ_DP:
+    case 32:
+        return UD_R_EAX + rm;
+    case SZ_WP:
+    case 16:
+        return UD_R_AX  + rm;
+    case  8:
+        if (u->dis_mode == 64 && u->pfx_rex) {
+            if (rm >= 4)
+                return UD_R_SPL + (rm-4);
+            return UD_R_AL + rm;
+        } else return UD_R_AL + rm;
+    default:
+        return 0;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr64() - 64bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr64(struct ud* u, enum ud_operand_code gpr_op)
+{
+  if (gpr_op >= OP_rAXr8 && gpr_op <= OP_rDIr15)
+    gpr_op = (gpr_op - OP_rAXr8) | (REX_B(u->pfx_rex) << 3);          
+  else  gpr_op = (gpr_op - OP_rAX);
+
+  if (u->opr_mode == 16)
+    return gpr_op + UD_R_AX;
+  if (u->dis_mode == 32 || 
+    (u->opr_mode == 32 && ! (REX_W(u->pfx_rex) || u->default64))) {
+    return gpr_op + UD_R_EAX;
+  }
+
+  return gpr_op + UD_R_RAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr32 () - 32bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr32(struct ud* u, enum ud_operand_code gpr_op)
+{
+  gpr_op = gpr_op - OP_eAX;
+
+  if (u->opr_mode == 16) 
+    return gpr_op + UD_R_AX;
+
+  return gpr_op +  UD_R_EAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_reg() - Resolves the register type 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_reg(struct ud* u, unsigned int type, unsigned char i)
+{
+  switch (type) {
+    case T_MMX :    return UD_R_MM0  + (i & 7);
+    case T_XMM :    return UD_R_XMM0 + i;
+    case T_CRG :    return UD_R_CR0  + i;
+    case T_DBG :    return UD_R_DR0  + i;
+    case T_SEG :    return UD_R_ES   + (i & 7);
+    case T_NONE:
+    default:    return UD_NONE;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_imm() - Decodes Immediate values.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_imm(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  op->size = resolve_operand_size(u, s);
+  op->type = UD_OP_IMM;
+
+  switch (op->size) {
+    case  8: op->lval.sbyte = inp_uint8(u);   break;
+    case 16: op->lval.uword = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: return;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_modrm() - Decodes ModRM Byte
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_modrm(struct ud* u, struct ud_operand *op, unsigned int s, 
+         unsigned char rm_type, struct ud_operand *opreg, 
+         unsigned char reg_size, unsigned char reg_type)
+{
+  unsigned char mod, rm, reg;
+
+  inp_next(u);
+
+  /* get mod, r/m and reg fields */
+  mod = MODRM_MOD(inp_curr(u));
+  rm  = (REX_B(u->pfx_rex) << 3) | MODRM_RM(inp_curr(u));
+  reg = (REX_R(u->pfx_rex) << 3) | MODRM_REG(inp_curr(u));
+
+  op->size = resolve_operand_size(u, s);
+
+  /* if mod is 11b, then the UD_R_m specifies a gpr/mmx/sse/control/debug */
+  if (mod == 3) {
+    op->type = UD_OP_REG;
+    if (rm_type ==  T_GPR)
+        op->base = decode_gpr(u, op->size, rm);
+    else    op->base = resolve_reg(u, rm_type, (REX_B(u->pfx_rex) << 3) | (rm&7));
+  } 
+  /* else its memory addressing */  
+  else {
+    op->type = UD_OP_MEM;
+
+    /* 64bit addressing */
+    if (u->adr_mode == 64) {
+
+        op->base = UD_R_RAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && (rm & 7) == 5) {           
+            op->base = UD_R_RIP;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+            
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_RAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_RAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            /* special conditions for base reference */
+            if (op->index == UD_R_RSP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            if (op->base == UD_R_RBP || op->base == UD_R_R13) {
+                if (mod == 0) 
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 32-Bit addressing mode */
+    else if (u->adr_mode == 32) {
+
+        /* get base */
+        op->base = UD_R_EAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && rm == 5) {
+            op->base = UD_NONE;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_EAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_EAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            if (op->index == UD_R_ESP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            /* special condition for base reference */
+            if (op->base == UD_R_EBP) {
+                if (mod == 0)
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 16bit addressing mode */
+    else  {
+        switch (rm) {
+            case 0: op->base = UD_R_BX; op->index = UD_R_SI; break;
+            case 1: op->base = UD_R_BX; op->index = UD_R_DI; break;
+            case 2: op->base = UD_R_BP; op->index = UD_R_SI; break;
+            case 3: op->base = UD_R_BP; op->index = UD_R_DI; break;
+            case 4: op->base = UD_R_SI; break;
+            case 5: op->base = UD_R_DI; break;
+            case 6: op->base = UD_R_BP; break;
+            case 7: op->base = UD_R_BX; break;
+        }
+
+        if (mod == 0 && rm == 6) {
+            op->offset= 16;
+            op->base = UD_NONE;
+        }
+        else if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2) 
+            op->offset = 16;
+    }
+  }  
+
+  /* extract offset, if any */
+  switch(op->offset) {
+    case 8 : op->lval.ubyte  = inp_uint8(u);  break;
+    case 16: op->lval.uword  = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: break;
+  }
+
+  /* resolve register encoded in reg field */
+  if (opreg) {
+    opreg->type = UD_OP_REG;
+    opreg->size = resolve_operand_size(u, reg_size);
+    if (reg_type == T_GPR) 
+        opreg->base = decode_gpr(u, opreg->size, reg);
+    else opreg->base = resolve_reg(u, reg_type, reg);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_o() - Decodes offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_o(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  switch (u->adr_mode) {
+    case 64:
+        op->offset = 64; 
+        op->lval.uqword = inp_uint64(u); 
+        break;
+    case 32:
+        op->offset = 32; 
+        op->lval.udword = inp_uint32(u); 
+        break;
+    case 16:
+        op->offset = 16; 
+        op->lval.uword  = inp_uint16(u); 
+        break;
+    default:
+        return;
+  }
+  op->type = UD_OP_MEM;
+  op->size = resolve_operand_size(u, s);
+}
+
+/* -----------------------------------------------------------------------------
+ * disasm_operands() - Disassembles Operands.
+ * -----------------------------------------------------------------------------
+ */
+static int disasm_operands(register struct ud* u)
+{
+
+
+  /* mopXt = map entry, operand X, type; */
+  enum ud_operand_code mop1t = u->itab_entry->operand1.type;
+  enum ud_operand_code mop2t = u->itab_entry->operand2.type;
+  enum ud_operand_code mop3t = u->itab_entry->operand3.type;
+
+  /* mopXs = map entry, operand X, size */
+  unsigned int mop1s = u->itab_entry->operand1.size;
+  unsigned int mop2s = u->itab_entry->operand2.size;
+  unsigned int mop3s = u->itab_entry->operand3.size;
+
+  /* iop = instruction operand */
+  register struct ud_operand* iop = u->operand;
+    
+  switch(mop1t) {
+    
+    case OP_A :
+        decode_a(u, &(iop[0]));
+        break;
+    
+    /* M[b] ... */
+    case OP_M :
+        if (MODRM_MOD(inp_peek(u)) == 3)
+            u->error= 1;
+    /* E, G/P/V/I/CL/1/S */
+    case OP_E :
+        if (mop2t == OP_G) {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+            else if (mop3t == OP_CL) {
+                iop[2].type = UD_OP_REG;
+                iop[2].base = UD_R_CL;
+                iop[2].size = 8;
+            }
+        }
+        else if (mop2t == OP_P)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_MMX);
+        else if (mop2t == OP_V)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_XMM);
+        else if (mop2t == OP_S)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_SEG);
+        else {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, NULL, 0, T_NONE);
+            if (mop2t == OP_CL) {
+                iop[1].type = UD_OP_REG;
+                iop[1].base = UD_R_CL;
+                iop[1].size = 8;
+            } else if (mop2t == OP_I1) {
+                iop[1].type = UD_OP_CONST;
+                u->operand[1].lval.udword = 1;
+            } else if (mop2t == OP_I) {
+                decode_imm(u, mop2s, &(iop[1]));
+            }
+        }
+        break;
+
+    /* G, E/PR[,I]/VR */
+    case OP_G :
+        if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_W)
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        break;
+
+    /* AL..BH, I/O/DX */
+    case OP_AL : case OP_CL : case OP_DL : case OP_BL :
+    case OP_AH : case OP_CH : case OP_DH : case OP_BH :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AL + (mop1t - OP_AL);
+        iop[0].size = 8;
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        }
+        else if (mop2t == OP_O)
+            decode_o(u, mop2s, &(iop[1]));
+        break;
+
+    /* rAX[r8]..rDI[r15], I/rAX..rDI/O */
+    case OP_rAXr8 : case OP_rCXr9 : case OP_rDXr10 : case OP_rBXr11 :
+    case OP_rSPr12: case OP_rBPr13: case OP_rSIr14 : case OP_rDIr15 :
+    case OP_rAX : case OP_rCX : case OP_rDX : case OP_rBX :
+    case OP_rSP : case OP_rBP : case OP_rSI : case OP_rDI :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr64(u, mop1t);
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t >= OP_rAX && mop2t <= OP_rDI) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = resolve_gpr64(u, mop2t);
+        }
+        else if (mop2t == OP_O) {
+            decode_o(u, mop2s, &(iop[1]));  
+            iop[0].size = resolve_operand_size(u, mop2s);
+        }
+        break;
+
+    /* AL[r8b]..BH[r15b], I */
+    case OP_ALr8b : case OP_CLr9b : case OP_DLr10b : case OP_BLr11b :
+    case OP_AHr12b: case OP_CHr13b: case OP_DHr14b : case OP_BHr15b :
+    {
+        ud_type_t gpr = (mop1t - OP_ALr8b) + UD_R_AL + 
+                        (REX_B(u->pfx_rex) << 3);
+        if (UD_R_AH <= gpr && u->pfx_rex)
+            gpr = gpr + 4;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = gpr;
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+    }
+
+    /* eAX..eDX, DX/I */
+    case OP_eAX : case OP_eCX : case OP_eDX : case OP_eBX :
+    case OP_eSP : case OP_eBP : case OP_eSI : case OP_eDI :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr32(u, mop1t);
+        if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        } else if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+
+    /* ES..GS */
+    case OP_ES : case OP_CS : case OP_DS :
+    case OP_SS : case OP_FS : case OP_GS :
+
+        /* in 64bits mode, only fs and gs are allowed */
+        if (u->dis_mode == 64)
+            if (mop1t != OP_FS && mop1t != OP_GS)
+                u->error= 1;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t - OP_ES) + UD_R_ES;
+        iop[0].size = 16;
+
+        break;
+
+    /* J */
+    case OP_J :
+        decode_imm(u, mop1s, &(iop[0]));        
+        iop[0].type = UD_OP_JIMM;
+        break ;
+
+    /* PR, I */
+    case OP_PR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* VR, I */
+    case OP_VR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* P, Q[,I]/W/E[,I],VR */
+    case OP_P :
+        if (mop2t == OP_Q) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_W) {
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        }
+        break;
+
+    /* R, C/D */
+    case OP_R :
+        if (mop2t == OP_C)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_CRG);
+        else if (mop2t == OP_D)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_DBG);
+        break;
+
+    /* C, R */
+    case OP_C :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_CRG);
+        break;
+
+    /* D, R */
+    case OP_D :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_DBG);
+        break;
+
+    /* Q, P */
+    case OP_Q :
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, &(iop[1]), mop2s, T_MMX);
+        break;
+
+    /* S, E */
+    case OP_S :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_SEG);
+        break;
+
+    /* W, V */
+    case OP_W :
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, &(iop[1]), mop2s, T_XMM);
+        break;
+
+    /* V, W[,I]/Q/M/E */
+    case OP_V :
+        if (mop2t == OP_W) {
+            /* special cases for movlps and movhps */
+            if (MODRM_MOD(inp_peek(u)) == 3) {
+                if (u->mnemonic == UD_Imovlps)
+                    u->mnemonic = UD_Imovhlps;
+                else
+                if (u->mnemonic == UD_Imovhps)
+                    u->mnemonic = UD_Imovlhps;
+            }
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_XMM);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_Q)
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        else if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        }
+        break;
+
+    /* DX, eAX/AL */
+    case OP_DX :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_DX;
+        iop[0].size = 16;
+
+        if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        } else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 8;
+        }
+
+        break;
+
+    /* I, I/AL/eAX */
+    case OP_I :
+        decode_imm(u, mop1s, &(iop[0]));
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 16;
+        } else if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        }
+        break;
+
+    /* O, AL/eAX */
+    case OP_O :
+        decode_o(u, mop1s, &(iop[0]));
+        iop[1].type = UD_OP_REG;
+        iop[1].size = resolve_operand_size(u, mop1s);
+        if (mop2t == OP_AL)
+            iop[1].base = UD_R_AL;
+        else if (mop2t == OP_eAX)
+            iop[1].base = resolve_gpr32(u, mop2t);
+        else if (mop2t == OP_rAX)
+            iop[1].base = resolve_gpr64(u, mop2t);      
+        break;
+
+    /* 3 */
+    case OP_I3 :
+        iop[0].type = UD_OP_CONST;
+        iop[0].lval.sbyte = 3;
+        break;
+
+    /* ST(n), ST(n) */
+    case OP_ST0 : case OP_ST1 : case OP_ST2 : case OP_ST3 :
+    case OP_ST4 : case OP_ST5 : case OP_ST6 : case OP_ST7 :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t-OP_ST0) + UD_R_ST0;
+        iop[0].size = 0;
+
+        if (mop2t >= OP_ST0 && mop2t <= OP_ST7) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = (mop2t-OP_ST0) + UD_R_ST0;
+            iop[1].size = 0;
+        }
+        break;
+
+    /* AX */
+    case OP_AX:
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AX;
+        iop[0].size = 16;
+        break;
+
+    /* none */
+    default :
+        iop[0].type = iop[1].type = iop[2].type = UD_NONE;
+  }
+
+  return 0;
+}
+
+/* -----------------------------------------------------------------------------
+ * clear_insn() - clear instruction pointer 
+ * -----------------------------------------------------------------------------
+ */
+static int clear_insn(register struct ud* u)
+{
+  u->error     = 0;
+  u->pfx_seg   = 0;
+  u->pfx_opr   = 0;
+  u->pfx_adr   = 0;
+  u->pfx_lock  = 0;
+  u->pfx_repne = 0;
+  u->pfx_rep   = 0;
+  u->pfx_repe  = 0;
+  u->pfx_seg   = 0;
+  u->pfx_rex   = 0;
+  u->pfx_insn  = 0;
+  u->mnemonic  = UD_Inone;
+  u->itab_entry = NULL;
+
+  memset( &u->operand[ 0 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 1 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 2 ], 0, sizeof( struct ud_operand ) );
+ 
+  return 0;
+}
+
+static int do_mode( struct ud* u )
+{
+  /* if in error state, bail out */
+  if ( u->error ) return -1; 
+
+  /* propagate perfix effects */
+  if ( u->dis_mode == 64 ) {  /* set 64bit-mode flags */
+
+    /* Check validity of  instruction m64 */
+    if ( P_INV64( u->itab_entry->prefix ) ) {
+        u->error = 1;
+        return -1;
+    }
+
+    /* effective rex prefix is the  effective mask for the 
+     * instruction hard-coded in the opcode map.
+     */
+    u->pfx_rex = ( u->pfx_rex & 0x40 ) | 
+                 ( u->pfx_rex & REX_PFX_MASK( u->itab_entry->prefix ) ); 
+
+    /* whether this instruction has a default operand size of 
+     * 64bit, also hardcoded into the opcode map.
+     */
+    u->default64 = P_DEF64( u->itab_entry->prefix ); 
+    /* calculate effective operand size */
+    if ( REX_W( u->pfx_rex ) ) {
+        u->opr_mode = 64;
+    } else if ( u->pfx_opr ) {
+        u->opr_mode = 16;
+    } else {
+        /* unless the default opr size of instruction is 64,
+         * the effective operand size in the absence of rex.w
+         * prefix is 32.
+         */
+        u->opr_mode = ( u->default64 ) ? 64 : 32;
+    }
+
+    /* calculate effective address size */
+    u->adr_mode = (u->pfx_adr) ? 32 : 64;
+  } else if ( u->dis_mode == 32 ) { /* set 32bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+    u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+  } else if ( u->dis_mode == 16 ) { /* set 16bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+    u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+  }
+
+  /* These flags determine which operand to apply the operand size
+   * cast to.
+   */
+  u->c1 = ( P_C1( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c2 = ( P_C2( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c3 = ( P_C3( u->itab_entry->prefix ) ) ? 1 : 0;
+
+  /* set flags for implicit addressing */
+  u->implicit_addr = P_IMPADDR( u->itab_entry->prefix );
+
+  return 0;
+}
+
+static int gen_hex( struct ud *u )
+{
+  unsigned int i;
+  unsigned char *src_ptr = inp_sess( u );
+  char* src_hex;
+
+  /* bail out if in error stat. */
+  if ( u->error ) return -1; 
+  /* output buffer pointe */
+  src_hex = ( char* ) u->insn_hexcode;
+  /* for each byte used to decode instruction */
+  for ( i = 0; i < u->inp_ctr; ++i, ++src_ptr) {
+    snprintf( src_hex, 2, "%02x", *src_ptr & 0xFF );
+    src_hex += 2;
+  }
+  return 0;
+}
+
+/* =============================================================================
+ * ud_decode() - Instruction decoder. Returns the number of bytes decoded.
+ * =============================================================================
+ */
+unsigned int ud_decode( struct ud* u )
+{
+  inp_start(u);
+
+  if ( clear_insn( u ) ) {
+    ; /* error */
+  } else if ( get_prefixes( u ) != 0 ) {
+    ; /* error */
+  } else if ( search_itab( u ) != 0 ) {
+    ; /* error */
+  } else if ( do_mode( u ) != 0 ) {
+    ; /* error */
+  } else if ( disasm_operands( u ) != 0 ) {
+    ; /* error */
+  } else if ( resolve_mnemonic( u ) != 0 ) {
+    ; /* error */
+  }
+
+  /* Handle decode error. */
+  if ( u->error ) {
+    /* clear out the decode data. */
+    clear_insn( u );
+    /* mark the sequence of bytes as invalid. */
+    u->itab_entry = & ie_invalid;
+    u->mnemonic = u->itab_entry->mnemonic;
+  } 
+
+  u->insn_offset = u->pc; /* set offset of instruction */
+  u->insn_fill = 0;   /* set translation buffer index to 0 */
+  u->pc += u->inp_ctr;    /* move program counter by bytes decoded */
+  gen_hex( u );       /* generate hex code */
+
+  /* return number of bytes disassembled. */
+  return u->inp_ctr;
+}
+
+/* vim:cindent
+ * vim:ts=4
+ * vim:sw=4
+ * vim:expandtab
+ */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/decode.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,273 @@
+#ifndef UD_DECODE_H
+#define UD_DECODE_H
+
+#define MAX_INSN_LENGTH 15
+
+/* register classes */
+#define T_NONE  0
+#define T_GPR   1
+#define T_MMX   2
+#define T_CRG   3
+#define T_DBG   4
+#define T_SEG   5
+#define T_XMM   6
+
+/* itab prefix bits */
+#define P_none          ( 0 )
+#define P_c1            ( 1 << 0 )
+#define P_C1(n)         ( ( n >> 0 ) & 1 )
+#define P_rexb          ( 1 << 1 )
+#define P_REXB(n)       ( ( n >> 1 ) & 1 )
+#define P_depM          ( 1 << 2 )
+#define P_DEPM(n)       ( ( n >> 2 ) & 1 )
+#define P_c3            ( 1 << 3 )
+#define P_C3(n)         ( ( n >> 3 ) & 1 )
+#define P_inv64         ( 1 << 4 )
+#define P_INV64(n)      ( ( n >> 4 ) & 1 )
+#define P_rexw          ( 1 << 5 )
+#define P_REXW(n)       ( ( n >> 5 ) & 1 )
+#define P_c2            ( 1 << 6 )
+#define P_C2(n)         ( ( n >> 6 ) & 1 )
+#define P_def64         ( 1 << 7 )
+#define P_DEF64(n)      ( ( n >> 7 ) & 1 )
+#define P_rexr          ( 1 << 8 )
+#define P_REXR(n)       ( ( n >> 8 ) & 1 )
+#define P_oso           ( 1 << 9 )
+#define P_OSO(n)        ( ( n >> 9 ) & 1 )
+#define P_aso           ( 1 << 10 )
+#define P_ASO(n)        ( ( n >> 10 ) & 1 )
+#define P_rexx          ( 1 << 11 )
+#define P_REXX(n)       ( ( n >> 11 ) & 1 )
+#define P_ImpAddr       ( 1 << 12 )
+#define P_IMPADDR(n)    ( ( n >> 12 ) & 1 )
+
+/* rex prefix bits */
+#define REX_W(r)        ( ( 0xF & ( r ) )  >> 3 )
+#define REX_R(r)        ( ( 0x7 & ( r ) )  >> 2 )
+#define REX_X(r)        ( ( 0x3 & ( r ) )  >> 1 )
+#define REX_B(r)        ( ( 0x1 & ( r ) )  >> 0 )
+#define REX_PFX_MASK(n) ( ( P_REXW(n) << 3 ) | \
+                          ( P_REXR(n) << 2 ) | \
+                          ( P_REXX(n) << 1 ) | \
+                          ( P_REXB(n) << 0 ) )
+
+/* scable-index-base bits */
+#define SIB_S(b)        ( ( b ) >> 6 )
+#define SIB_I(b)        ( ( ( b ) >> 3 ) & 7 )
+#define SIB_B(b)        ( ( b ) & 7 )
+
+/* modrm bits */
+#define MODRM_REG(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_NNN(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_MOD(b)    ( ( ( b ) >> 6 ) & 3 )
+#define MODRM_RM(b)     ( ( b ) & 7 )
+
+/* operand type constants -- order is important! */
+
+enum ud_operand_code {
+    OP_NONE,
+
+    OP_A,      OP_E,      OP_M,       OP_G,       
+    OP_I,
+
+    OP_AL,     OP_CL,     OP_DL,      OP_BL,
+    OP_AH,     OP_CH,     OP_DH,      OP_BH,
+
+    OP_ALr8b,  OP_CLr9b,  OP_DLr10b,  OP_BLr11b,
+    OP_AHr12b, OP_CHr13b, OP_DHr14b,  OP_BHr15b,
+
+    OP_AX,     OP_CX,     OP_DX,      OP_BX,
+    OP_SI,     OP_DI,     OP_SP,      OP_BP,
+
+    OP_rAX,    OP_rCX,    OP_rDX,     OP_rBX,  
+    OP_rSP,    OP_rBP,    OP_rSI,     OP_rDI,
+
+    OP_rAXr8,  OP_rCXr9,  OP_rDXr10,  OP_rBXr11,  
+    OP_rSPr12, OP_rBPr13, OP_rSIr14,  OP_rDIr15,
+
+    OP_eAX,    OP_eCX,    OP_eDX,     OP_eBX,
+    OP_eSP,    OP_eBP,    OP_eSI,     OP_eDI,
+
+    OP_ES,     OP_CS,     OP_SS,      OP_DS,  
+    OP_FS,     OP_GS,
+
+    OP_ST0,    OP_ST1,    OP_ST2,     OP_ST3,
+    OP_ST4,    OP_ST5,    OP_ST6,     OP_ST7,
+
+    OP_J,      OP_S,      OP_O,          
+    OP_I1,     OP_I3, 
+
+    OP_V,      OP_W,      OP_Q,       OP_P, 
+
+    OP_R,      OP_C,  OP_D,       OP_VR,  OP_PR
+};
+
+
+/* operand size constants */
+
+enum ud_operand_size {
+    SZ_NA  = 0,
+    SZ_Z   = 1,
+    SZ_V   = 2,
+    SZ_P   = 3,
+    SZ_WP  = 4,
+    SZ_DP  = 5,
+    SZ_MDQ = 6,
+    SZ_RDQ = 7,
+
+    /* the following values are used as is,
+     * and thus hard-coded. changing them 
+     * will break internals 
+     */
+    SZ_B   = 8,
+    SZ_W   = 16,
+    SZ_D   = 32,
+    SZ_Q   = 64,
+    SZ_T   = 80,
+};
+
+/* itab entry operand definitions */
+
+#define O_rSPr12  { OP_rSPr12,   SZ_NA    }
+#define O_BL      { OP_BL,       SZ_NA    }
+#define O_BH      { OP_BH,       SZ_NA    }
+#define O_BP      { OP_BP,       SZ_NA    }
+#define O_AHr12b  { OP_AHr12b,   SZ_NA    }
+#define O_BX      { OP_BX,       SZ_NA    }
+#define O_Jz      { OP_J,        SZ_Z     }
+#define O_Jv      { OP_J,        SZ_V     }
+#define O_Jb      { OP_J,        SZ_B     }
+#define O_rSIr14  { OP_rSIr14,   SZ_NA    }
+#define O_GS      { OP_GS,       SZ_NA    }
+#define O_D       { OP_D,        SZ_NA    }
+#define O_rBPr13  { OP_rBPr13,   SZ_NA    }
+#define O_Ob      { OP_O,        SZ_B     }
+#define O_P       { OP_P,        SZ_NA    }
+#define O_Ow      { OP_O,        SZ_W     }
+#define O_Ov      { OP_O,        SZ_V     }
+#define O_Gw      { OP_G,        SZ_W     }
+#define O_Gv      { OP_G,        SZ_V     }
+#define O_rDX     { OP_rDX,      SZ_NA    }
+#define O_Gx      { OP_G,        SZ_MDQ   }
+#define O_Gd      { OP_G,        SZ_D     }
+#define O_Gb      { OP_G,        SZ_B     }
+#define O_rBXr11  { OP_rBXr11,   SZ_NA    }
+#define O_rDI     { OP_rDI,      SZ_NA    }
+#define O_rSI     { OP_rSI,      SZ_NA    }
+#define O_ALr8b   { OP_ALr8b,    SZ_NA    }
+#define O_eDI     { OP_eDI,      SZ_NA    }
+#define O_Gz      { OP_G,        SZ_Z     }
+#define O_eDX     { OP_eDX,      SZ_NA    }
+#define O_DHr14b  { OP_DHr14b,   SZ_NA    }
+#define O_rSP     { OP_rSP,      SZ_NA    }
+#define O_PR      { OP_PR,       SZ_NA    }
+#define O_NONE    { OP_NONE,     SZ_NA    }
+#define O_rCX     { OP_rCX,      SZ_NA    }
+#define O_jWP     { OP_J,        SZ_WP    }
+#define O_rDXr10  { OP_rDXr10,   SZ_NA    }
+#define O_Md      { OP_M,        SZ_D     }
+#define O_C       { OP_C,        SZ_NA    }
+#define O_G       { OP_G,        SZ_NA    }
+#define O_Mb      { OP_M,        SZ_B     }
+#define O_Mt      { OP_M,        SZ_T     }
+#define O_S       { OP_S,        SZ_NA    }
+#define O_Mq      { OP_M,        SZ_Q     }
+#define O_W       { OP_W,        SZ_NA    }
+#define O_ES      { OP_ES,       SZ_NA    }
+#define O_rBX     { OP_rBX,      SZ_NA    }
+#define O_Ed      { OP_E,        SZ_D     }
+#define O_DLr10b  { OP_DLr10b,   SZ_NA    }
+#define O_Mw      { OP_M,        SZ_W     }
+#define O_Eb      { OP_E,        SZ_B     }
+#define O_Ex      { OP_E,        SZ_MDQ   }
+#define O_Ez      { OP_E,        SZ_Z     }
+#define O_Ew      { OP_E,        SZ_W     }
+#define O_Ev      { OP_E,        SZ_V     }
+#define O_Ep      { OP_E,        SZ_P     }
+#define O_FS      { OP_FS,       SZ_NA    }
+#define O_Ms      { OP_M,        SZ_W     }
+#define O_rAXr8   { OP_rAXr8,    SZ_NA    }
+#define O_eBP     { OP_eBP,      SZ_NA    }
+#define O_Isb     { OP_I,        SZ_SB    }
+#define O_eBX     { OP_eBX,      SZ_NA    }
+#define O_rCXr9   { OP_rCXr9,    SZ_NA    }
+#define O_jDP     { OP_J,        SZ_DP    }
+#define O_CH      { OP_CH,       SZ_NA    }
+#define O_CL      { OP_CL,       SZ_NA    }
+#define O_R       { OP_R,        SZ_RDQ   }
+#define O_V       { OP_V,        SZ_NA    }
+#define O_CS      { OP_CS,       SZ_NA    }
+#define O_CHr13b  { OP_CHr13b,   SZ_NA    }
+#define O_eCX     { OP_eCX,      SZ_NA    }
+#define O_eSP     { OP_eSP,      SZ_NA    }
+#define O_SS      { OP_SS,       SZ_NA    }
+#define O_SP      { OP_SP,       SZ_NA    }
+#define O_BLr11b  { OP_BLr11b,   SZ_NA    }
+#define O_SI      { OP_SI,       SZ_NA    }
+#define O_eSI     { OP_eSI,      SZ_NA    }
+#define O_DL      { OP_DL,       SZ_NA    }
+#define O_DH      { OP_DH,       SZ_NA    }
+#define O_DI      { OP_DI,       SZ_NA    }
+#define O_DX      { OP_DX,       SZ_NA    }
+#define O_rBP     { OP_rBP,      SZ_NA    }
+#define O_Gvw     { OP_G,        SZ_MDQ   }
+#define O_I1      { OP_I1,       SZ_NA    }
+#define O_I3      { OP_I3,       SZ_NA    }
+#define O_DS      { OP_DS,       SZ_NA    }
+#define O_ST4     { OP_ST4,      SZ_NA    }
+#define O_ST5     { OP_ST5,      SZ_NA    }
+#define O_ST6     { OP_ST6,      SZ_NA    }
+#define O_ST7     { OP_ST7,      SZ_NA    }
+#define O_ST0     { OP_ST0,      SZ_NA    }
+#define O_ST1     { OP_ST1,      SZ_NA    }
+#define O_ST2     { OP_ST2,      SZ_NA    }
+#define O_ST3     { OP_ST3,      SZ_NA    }
+#define O_E       { OP_E,        SZ_NA    }
+#define O_AH      { OP_AH,       SZ_NA    }
+#define O_M       { OP_M,        SZ_NA    }
+#define O_AL      { OP_AL,       SZ_NA    }
+#define O_CLr9b   { OP_CLr9b,    SZ_NA    }
+#define O_Q       { OP_Q,        SZ_NA    }
+#define O_eAX     { OP_eAX,      SZ_NA    }
+#define O_VR      { OP_VR,       SZ_NA    }
+#define O_AX      { OP_AX,       SZ_NA    }
+#define O_rAX     { OP_rAX,      SZ_NA    }
+#define O_Iz      { OP_I,        SZ_Z     }
+#define O_rDIr15  { OP_rDIr15,   SZ_NA    }
+#define O_Iw      { OP_I,        SZ_W     }
+#define O_Iv      { OP_I,        SZ_V     }
+#define O_Ap      { OP_A,        SZ_P     }
+#define O_CX      { OP_CX,       SZ_NA    }
+#define O_Ib      { OP_I,        SZ_B     }
+#define O_BHr15b  { OP_BHr15b,   SZ_NA    }
+
+
+/* A single operand of an entry in the instruction table. 
+ * (internal use only)
+ */
+struct ud_itab_entry_operand 
+{
+  enum ud_operand_code type;
+  enum ud_operand_size size;
+};
+
+
+/* A single entry in an instruction table. 
+ *(internal use only)
+ */
+struct ud_itab_entry 
+{
+  enum ud_mnemonic_code         mnemonic;
+  struct ud_itab_entry_operand  operand1;
+  struct ud_itab_entry_operand  operand2;
+  struct ud_itab_entry_operand  operand3;
+  uint32_t                      prefix;
+};
+
+#endif /* UD_DECODE_H */
+
+/* vim:cindent
+ * vim:expandtab
+ * vim:ts=4
+ * vim:sw=4
+ */
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/extern.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,67 @@
+/* -----------------------------------------------------------------------------
+ * extern.h
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_EXTERN_H
+#define UD_EXTERN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #include <stdio.h> */
+#include "types.h"
+
+/* ============================= PUBLIC API ================================= */
+
+extern void ud_init(struct ud*);
+
+extern void ud_set_mode(struct ud*, uint8_t);
+
+extern void ud_set_pc(struct ud*, uint64_t);
+
+extern void ud_set_input_hook(struct ud*, int (*)(struct ud*));
+
+extern void ud_set_input_buffer(struct ud*, uint8_t*, size_t);
+
+#ifndef __UD_STANDALONE__
+extern void ud_set_input_file(struct ud*, FILE*);
+#endif /* __UD_STANDALONE__ */
+
+extern void ud_set_vendor(struct ud*, unsigned);
+
+extern void ud_set_syntax(struct ud*, void (*)(struct ud*));
+
+extern void ud_input_skip(struct ud*, size_t);
+
+extern int ud_input_end(struct ud*);
+
+extern unsigned int ud_decode(struct ud*);
+
+extern unsigned int ud_disassemble(struct ud*);
+
+extern void ud_translate_intel(struct ud*);
+
+extern void ud_translate_att(struct ud*);
+
+extern char* ud_insn_asm(struct ud* u);
+
+extern uint8_t* ud_insn_ptr(struct ud* u);
+
+extern uint64_t ud_insn_off(struct ud*);
+
+extern char* ud_insn_hex(struct ud*);
+
+extern unsigned int ud_insn_len(struct ud* u);
+
+extern const char* ud_lookup_mnemonic(enum ud_mnemonic_code c);
+
+/* ========================================================================== */
+
+#ifdef __cplusplus
+}
+#endif
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/input.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,226 @@
+/* -----------------------------------------------------------------------------
+ * input.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#include "extern.h"
+#include "types.h"
+#include "input.h"
+
+/* -----------------------------------------------------------------------------
+ * inp_buff_hook() - Hook for buffered inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_buff_hook(struct ud* u)
+{
+  if (u->inp_buff < u->inp_buff_end)
+	return *u->inp_buff++;
+  else	return -1;
+}
+
+#ifndef __UD_STANDALONE__
+/* -----------------------------------------------------------------------------
+ * inp_file_hook() - Hook for FILE inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_file_hook(struct ud* u)
+{
+  return fgetc(u->inp_file);
+}
+#endif /* __UD_STANDALONE__*/
+
+/* =============================================================================
+ * ud_inp_set_hook() - Sets input hook.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_hook(register struct ud* u, int (*hook)(struct ud*))
+{
+  u->inp_hook = hook;
+  inp_init(u);
+}
+
+/* =============================================================================
+ * ud_inp_set_buffer() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_buffer(register struct ud* u, uint8_t* buf, size_t len)
+{
+  u->inp_hook = inp_buff_hook;
+  u->inp_buff = buf;
+  u->inp_buff_end = buf + len;
+  inp_init(u);
+}
+
+#ifndef __UD_STANDALONE__
+/* =============================================================================
+ * ud_input_set_file() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_file(register struct ud* u, FILE* f)
+{
+  u->inp_hook = inp_file_hook;
+  u->inp_file = f;
+  inp_init(u);
+}
+#endif /* __UD_STANDALONE__ */
+
+/* =============================================================================
+ * ud_input_skip() - Skip n input bytes.
+ * =============================================================================
+ */
+extern void 
+ud_input_skip(struct ud* u, size_t n)
+{
+  while (n--) {
+	u->inp_hook(u);
+  }
+}
+
+/* =============================================================================
+ * ud_input_end() - Test for end of input.
+ * =============================================================================
+ */
+extern int 
+ud_input_end(struct ud* u)
+{
+  return (u->inp_curr == u->inp_fill) && u->inp_end;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_next() - Loads and returns the next byte from input.
+ *
+ * inp_curr and inp_fill are pointers to the cache. The program is written based
+ * on the property that they are 8-bits in size, and will eventually wrap around
+ * forming a circular buffer. So, the size of the cache is 256 in size, kind of
+ * unnecessary yet optimized.
+ *
+ * A buffer inp_sess stores the bytes disassembled for a single session.
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t inp_next(struct ud* u) 
+{
+  int c = -1;
+  /* if current pointer is not upto the fill point in the 
+   * input cache.
+   */
+  if ( u->inp_curr != u->inp_fill ) {
+	c = u->inp_cache[ ++u->inp_curr ];
+  /* if !end-of-input, call the input hook and get a byte */
+  } else if ( u->inp_end || ( c = u->inp_hook( u ) ) == -1 ) {
+	/* end-of-input, mark it as an error, since the decoder,
+	 * expected a byte more.
+	 */
+	u->error = 1;
+	/* flag end of input */
+	u->inp_end = 1;
+	return 0;
+  } else {
+	/* increment pointers, we have a new byte.  */
+	u->inp_curr = ++u->inp_fill;
+	/* add the byte to the cache */
+	u->inp_cache[ u->inp_fill ] = c;
+  }
+  /* record bytes input per decode-session. */
+  u->inp_sess[ u->inp_ctr++ ] = c;
+  /* return byte */
+  return ( uint8_t ) c;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_back() - Move back a single byte in the stream.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_back(struct ud* u) 
+{
+  if ( u->inp_ctr > 0 ) {
+	--u->inp_curr;
+	--u->inp_ctr;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_peek() - Peek into the next byte in source. 
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t
+inp_peek(struct ud* u) 
+{
+  uint8_t r = inp_next(u);
+  if ( !u->error ) inp_back(u); /* Don't backup if there was an error */
+  return r;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_move() - Move ahead n input bytes.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_move(struct ud* u, size_t n) 
+{
+  while (n--)
+	inp_next(u);
+}
+
+/*------------------------------------------------------------------------------
+ *  inp_uintN() - return uintN from source.
+ *------------------------------------------------------------------------------
+ */
+extern uint8_t 
+inp_uint8(struct ud* u)
+{
+  return inp_next(u);
+}
+
+extern uint16_t 
+inp_uint16(struct ud* u)
+{
+  uint16_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  return ret | (r << 8);
+}
+
+extern uint32_t 
+inp_uint32(struct ud* u)
+{
+  uint32_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  return ret | (r << 24);
+}
+
+extern uint64_t 
+inp_uint64(struct ud* u)
+{
+  uint64_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  ret = ret | (r << 24);
+  r = inp_next(u);
+  ret = ret | (r << 32);
+  r = inp_next(u);
+  ret = ret | (r << 40);
+  r = inp_next(u);
+  ret = ret | (r << 48);
+  r = inp_next(u);
+  return ret | (r << 56);
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/input.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,49 @@
+/* -----------------------------------------------------------------------------
+ * input.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_INPUT_H
+#define UD_INPUT_H
+
+#include "types.h"
+
+uint8_t inp_next(struct ud*);
+uint8_t inp_peek(struct ud*);
+uint8_t inp_uint8(struct ud*);
+uint16_t inp_uint16(struct ud*);
+uint32_t inp_uint32(struct ud*);
+uint64_t inp_uint64(struct ud*);
+void inp_move(struct ud*, size_t);
+void inp_back(struct ud*);
+
+/* inp_init() - Initializes the input system. */
+#define inp_init(u) \
+do { \
+  u->inp_curr = 0; \
+  u->inp_fill = 0; \
+  u->inp_ctr  = 0; \
+  u->inp_end  = 0; \
+} while (0)
+
+/* inp_start() - Should be called before each de-code operation. */
+#define inp_start(u) u->inp_ctr = 0
+
+/* inp_back() - Resets the current pointer to its position before the current
+ * instruction disassembly was started.
+ */
+#define inp_reset(u) \
+do { \
+  u->inp_curr -= u->inp_ctr; \
+  u->inp_ctr = 0; \
+} while (0)
+
+/* inp_sess() - Returns the pointer to current session. */
+#define inp_sess(u) (u->inp_sess)
+
+/* inp_cur() - Returns the current input byte. */
+#define inp_curr(u) ((u)->inp_cache[(u)->inp_curr])
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/itab.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,3668 @@
+
+/* itab.c -- auto generated by opgen.py, do not edit. */
+
+#include "types.h"
+#include "decode.h"
+#include "itab.h"
+
+const char * ud_mnemonics_str[] = {
+  "3dnow",
+  "aaa",
+  "aad",
+  "aam",
+  "aas",
+  "adc",
+  "add",
+  "addpd",
+  "addps",
+  "addsd",
+  "addss",
+  "addsubpd",
+  "addsubps",
+  "and",
+  "andpd",
+  "andps",
+  "andnpd",
+  "andnps",
+  "arpl",
+  "movsxd",
+  "bound",
+  "bsf",
+  "bsr",
+  "bswap",
+  "bt",
+  "btc",
+  "btr",
+  "bts",
+  "call",
+  "cbw",
+  "cwde",
+  "cdqe",
+  "clc",
+  "cld",
+  "clflush",
+  "clgi",
+  "cli",
+  "clts",
+  "cmc",
+  "cmovo",
+  "cmovno",
+  "cmovb",
+  "cmovae",
+  "cmovz",
+  "cmovnz",
+  "cmovbe",
+  "cmova",
+  "cmovs",
+  "cmovns",
+  "cmovp",
+  "cmovnp",
+  "cmovl",
+  "cmovge",
+  "cmovle",
+  "cmovg",
+  "cmp",
+  "cmppd",
+  "cmpps",
+  "cmpsb",
+  "cmpsw",
+  "cmpsd",
+  "cmpsq",
+  "cmpss",
+  "cmpxchg",
+  "cmpxchg8b",
+  "comisd",
+  "comiss",
+  "cpuid",
+  "cvtdq2pd",
+  "cvtdq2ps",
+  "cvtpd2dq",
+  "cvtpd2pi",
+  "cvtpd2ps",
+  "cvtpi2ps",
+  "cvtpi2pd",
+  "cvtps2dq",
+  "cvtps2pi",
+  "cvtps2pd",
+  "cvtsd2si",
+  "cvtsd2ss",
+  "cvtsi2ss",
+  "cvtss2si",
+  "cvtss2sd",
+  "cvttpd2pi",
+  "cvttpd2dq",
+  "cvttps2dq",
+  "cvttps2pi",
+  "cvttsd2si",
+  "cvtsi2sd",
+  "cvttss2si",
+  "cwd",
+  "cdq",
+  "cqo",
+  "daa",
+  "das",
+  "dec",
+  "div",
+  "divpd",
+  "divps",
+  "divsd",
+  "divss",
+  "emms",
+  "enter",
+  "f2xm1",
+  "fabs",
+  "fadd",
+  "faddp",
+  "fbld",
+  "fbstp",
+  "fchs",
+  "fclex",
+  "fcmovb",
+  "fcmove",
+  "fcmovbe",
+  "fcmovu",
+  "fcmovnb",
+  "fcmovne",
+  "fcmovnbe",
+  "fcmovnu",
+  "fucomi",
+  "fcom",
+  "fcom2",
+  "fcomp3",
+  "fcomi",
+  "fucomip",
+  "fcomip",
+  "fcomp",
+  "fcomp5",
+  "fcompp",
+  "fcos",
+  "fdecstp",
+  "fdiv",
+  "fdivp",
+  "fdivr",
+  "fdivrp",
+  "femms",
+  "ffree",
+  "ffreep",
+  "ficom",
+  "ficomp",
+  "fild",
+  "fncstp",
+  "fninit",
+  "fiadd",
+  "fidivr",
+  "fidiv",
+  "fisub",
+  "fisubr",
+  "fist",
+  "fistp",
+  "fisttp",
+  "fld",
+  "fld1",
+  "fldl2t",
+  "fldl2e",
+  "fldlpi",
+  "fldlg2",
+  "fldln2",
+  "fldz",
+  "fldcw",
+  "fldenv",
+  "fmul",
+  "fmulp",
+  "fimul",
+  "fnop",
+  "fpatan",
+  "fprem",
+  "fprem1",
+  "fptan",
+  "frndint",
+  "frstor",
+  "fnsave",
+  "fscale",
+  "fsin",
+  "fsincos",
+  "fsqrt",
+  "fstp",
+  "fstp1",
+  "fstp8",
+  "fstp9",
+  "fst",
+  "fnstcw",
+  "fnstenv",
+  "fnstsw",
+  "fsub",
+  "fsubp",
+  "fsubr",
+  "fsubrp",
+  "ftst",
+  "fucom",
+  "fucomp",
+  "fucompp",
+  "fxam",
+  "fxch",
+  "fxch4",
+  "fxch7",
+  "fxrstor",
+  "fxsave",
+  "fpxtract",
+  "fyl2x",
+  "fyl2xp1",
+  "haddpd",
+  "haddps",
+  "hlt",
+  "hsubpd",
+  "hsubps",
+  "idiv",
+  "in",
+  "imul",
+  "inc",
+  "insb",
+  "insw",
+  "insd",
+  "int1",
+  "int3",
+  "int",
+  "into",
+  "invd",
+  "invlpg",
+  "invlpga",
+  "iretw",
+  "iretd",
+  "iretq",
+  "jo",
+  "jno",
+  "jb",
+  "jae",
+  "jz",
+  "jnz",
+  "jbe",
+  "ja",
+  "js",
+  "jns",
+  "jp",
+  "jnp",
+  "jl",
+  "jge",
+  "jle",
+  "jg",
+  "jcxz",
+  "jecxz",
+  "jrcxz",
+  "jmp",
+  "lahf",
+  "lar",
+  "lddqu",
+  "ldmxcsr",
+  "lds",
+  "lea",
+  "les",
+  "lfs",
+  "lgs",
+  "lidt",
+  "lss",
+  "leave",
+  "lfence",
+  "lgdt",
+  "lldt",
+  "lmsw",
+  "lock",
+  "lodsb",
+  "lodsw",
+  "lodsd",
+  "lodsq",
+  "loopnz",
+  "loope",
+  "loop",
+  "lsl",
+  "ltr",
+  "maskmovq",
+  "maxpd",
+  "maxps",
+  "maxsd",
+  "maxss",
+  "mfence",
+  "minpd",
+  "minps",
+  "minsd",
+  "minss",
+  "monitor",
+  "mov",
+  "movapd",
+  "movaps",
+  "movd",
+  "movddup",
+  "movdqa",
+  "movdqu",
+  "movdq2q",
+  "movhpd",
+  "movhps",
+  "movlhps",
+  "movlpd",
+  "movlps",
+  "movhlps",
+  "movmskpd",
+  "movmskps",
+  "movntdq",
+  "movnti",
+  "movntpd",
+  "movntps",
+  "movntq",
+  "movq",
+  "movqa",
+  "movq2dq",
+  "movsb",
+  "movsw",
+  "movsd",
+  "movsq",
+  "movsldup",
+  "movshdup",
+  "movss",
+  "movsx",
+  "movupd",
+  "movups",
+  "movzx",
+  "mul",
+  "mulpd",
+  "mulps",
+  "mulsd",
+  "mulss",
+  "mwait",
+  "neg",
+  "nop",
+  "not",
+  "or",
+  "orpd",
+  "orps",
+  "out",
+  "outsb",
+  "outsw",
+  "outsd",
+  "outsq",
+  "packsswb",
+  "packssdw",
+  "packuswb",
+  "paddb",
+  "paddw",
+  "paddq",
+  "paddsb",
+  "paddsw",
+  "paddusb",
+  "paddusw",
+  "pand",
+  "pandn",
+  "pause",
+  "pavgb",
+  "pavgw",
+  "pcmpeqb",
+  "pcmpeqw",
+  "pcmpeqd",
+  "pcmpgtb",
+  "pcmpgtw",
+  "pcmpgtd",
+  "pextrw",
+  "pinsrw",
+  "pmaddwd",
+  "pmaxsw",
+  "pmaxub",
+  "pminsw",
+  "pminub",
+  "pmovmskb",
+  "pmulhuw",
+  "pmulhw",
+  "pmullw",
+  "pmuludq",
+  "pop",
+  "popa",
+  "popad",
+  "popfw",
+  "popfd",
+  "popfq",
+  "por",
+  "prefetch",
+  "prefetchnta",
+  "prefetcht0",
+  "prefetcht1",
+  "prefetcht2",
+  "psadbw",
+  "pshufd",
+  "pshufhw",
+  "pshuflw",
+  "pshufw",
+  "pslldq",
+  "psllw",
+  "pslld",
+  "psllq",
+  "psraw",
+  "psrad",
+  "psrlw",
+  "psrld",
+  "psrlq",
+  "psrldq",
+  "psubb",
+  "psubw",
+  "psubd",
+  "psubq",
+  "psubsb",
+  "psubsw",
+  "psubusb",
+  "psubusw",
+  "punpckhbw",
+  "punpckhwd",
+  "punpckhdq",
+  "punpckhqdq",
+  "punpcklbw",
+  "punpcklwd",
+  "punpckldq",
+  "punpcklqdq",
+  "pi2fw",
+  "pi2fd",
+  "pf2iw",
+  "pf2id",
+  "pfnacc",
+  "pfpnacc",
+  "pfcmpge",
+  "pfmin",
+  "pfrcp",
+  "pfrsqrt",
+  "pfsub",
+  "pfadd",
+  "pfcmpgt",
+  "pfmax",
+  "pfrcpit1",
+  "pfrspit1",
+  "pfsubr",
+  "pfacc",
+  "pfcmpeq",
+  "pfmul",
+  "pfrcpit2",
+  "pmulhrw",
+  "pswapd",
+  "pavgusb",
+  "push",
+  "pusha",
+  "pushad",
+  "pushfw",
+  "pushfd",
+  "pushfq",
+  "pxor",
+  "rcl",
+  "rcr",
+  "rol",
+  "ror",
+  "rcpps",
+  "rcpss",
+  "rdmsr",
+  "rdpmc",
+  "rdtsc",
+  "rdtscp",
+  "repne",
+  "rep",
+  "ret",
+  "retf",
+  "rsm",
+  "rsqrtps",
+  "rsqrtss",
+  "sahf",
+  "sal",
+  "salc",
+  "sar",
+  "shl",
+  "shr",
+  "sbb",
+  "scasb",
+  "scasw",
+  "scasd",
+  "scasq",
+  "seto",
+  "setno",
+  "setb",
+  "setnb",
+  "setz",
+  "setnz",
+  "setbe",
+  "seta",
+  "sets",
+  "setns",
+  "setp",
+  "setnp",
+  "setl",
+  "setge",
+  "setle",
+  "setg",
+  "sfence",
+  "sgdt",
+  "shld",
+  "shrd",
+  "shufpd",
+  "shufps",
+  "sidt",
+  "sldt",
+  "smsw",
+  "sqrtps",
+  "sqrtpd",
+  "sqrtsd",
+  "sqrtss",
+  "stc",
+  "std",
+  "stgi",
+  "sti",
+  "skinit",
+  "stmxcsr",
+  "stosb",
+  "stosw",
+  "stosd",
+  "stosq",
+  "str",
+  "sub",
+  "subpd",
+  "subps",
+  "subsd",
+  "subss",
+  "swapgs",
+  "syscall",
+  "sysenter",
+  "sysexit",
+  "sysret",
+  "test",
+  "ucomisd",
+  "ucomiss",
+  "ud2",
+  "unpckhpd",
+  "unpckhps",
+  "unpcklps",
+  "unpcklpd",
+  "verr",
+  "verw",
+  "vmcall",
+  "vmclear",
+  "vmxon",
+  "vmptrld",
+  "vmptrst",
+  "vmresume",
+  "vmxoff",
+  "vmrun",
+  "vmmcall",
+  "vmload",
+  "vmsave",
+  "wait",
+  "wbinvd",
+  "wrmsr",
+  "xadd",
+  "xchg",
+  "xlatb",
+  "xor",
+  "xorpd",
+  "xorps",
+  "db",
+  "invalid",
+};
+
+
+
+static struct ud_itab_entry itab__0f[256] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_00__REG },
+  /* 01 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG },
+  /* 02 */  { UD_Ilar,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ilsl,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Isyscall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iclts,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isysret,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Iinvd,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Iwbinvd,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iud2,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_0D__REG },
+  /* 0E */  { UD_Ifemms,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovups,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovups,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_18__REG },
+  /* 19 */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1D */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1E */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1F */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 20 */  { UD_Imov,         O_R,     O_C,     O_NONE,  P_rexr },
+  /* 21 */  { UD_Imov,         O_R,     O_D,     O_NONE,  P_rexr },
+  /* 22 */  { UD_Imov,         O_C,     O_R,     O_NONE,  P_rexr },
+  /* 23 */  { UD_Imov,         O_D,     O_R,     O_NONE,  P_rexr },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovaps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovaps,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2ps,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntps,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttps2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtps2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomiss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomiss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iwrmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Irdtsc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Irdmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Irdpmc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Isysenter,    O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 35 */  { UD_Isysexit,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Icmovo,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 41 */  { UD_Icmovno,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 42 */  { UD_Icmovb,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 43 */  { UD_Icmovae,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 44 */  { UD_Icmovz,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 45 */  { UD_Icmovnz,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 46 */  { UD_Icmovbe,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 47 */  { UD_Icmova,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 48 */  { UD_Icmovs,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 49 */  { UD_Icmovns,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4A */  { UD_Icmovp,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4B */  { UD_Icmovnp,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4C */  { UD_Icmovl,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4D */  { UD_Icmovge,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4E */  { UD_Icmovle,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4F */  { UD_Icmovg,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 50 */  { UD_Imovmskps,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtps,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iandps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorps,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtps2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtdq2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Imovd,        O_P,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovq,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufw,      O_P,     O_Q,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iemms,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_P,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovq,        O_Q,     O_P,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Ijo,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 81 */  { UD_Ijno,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 82 */  { UD_Ijb,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 83 */  { UD_Ijae,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 84 */  { UD_Ijz,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 85 */  { UD_Ijnz,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 86 */  { UD_Ijbe,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 87 */  { UD_Ija,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 88 */  { UD_Ijs,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 89 */  { UD_Ijns,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8A */  { UD_Ijp,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8B */  { UD_Ijnp,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8C */  { UD_Ijl,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8D */  { UD_Ijge,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8E */  { UD_Ijle,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8F */  { UD_Ijg,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 90 */  { UD_Iseto,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 91 */  { UD_Isetno,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 92 */  { UD_Isetb,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 93 */  { UD_Isetnb,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 94 */  { UD_Isetz,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 95 */  { UD_Isetnz,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 96 */  { UD_Isetbe,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 97 */  { UD_Iseta,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 98 */  { UD_Isets,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 99 */  { UD_Isetns,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9A */  { UD_Isetp,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9B */  { UD_Isetnp,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9C */  { UD_Isetl,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9D */  { UD_Isetge,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9E */  { UD_Isetle,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9F */  { UD_Isetg,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* A0 */  { UD_Ipush,        O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A1 */  { UD_Ipop,         O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A2 */  { UD_Icpuid,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A3 */  { UD_Ibt,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A4 */  { UD_Ishld,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A5 */  { UD_Ishld,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Ipush,        O_GS,    O_NONE,  O_NONE,  P_none },
+  /* A9 */  { UD_Ipop,         O_GS,    O_NONE,  O_NONE,  P_none },
+  /* AA */  { UD_Irsm,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AB */  { UD_Ibts,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AC */  { UD_Ishrd,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AD */  { UD_Ishrd,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG },
+  /* AF */  { UD_Iimul,        O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B0 */  { UD_Icmpxchg,     O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* B1 */  { UD_Icmpxchg,     O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B2 */  { UD_Ilss,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B3 */  { UD_Ibtr,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B4 */  { UD_Ilfs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B5 */  { UD_Ilgs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B6 */  { UD_Imovzx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B7 */  { UD_Imovzx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_BA__REG },
+  /* BB */  { UD_Ibtc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BC */  { UD_Ibsf,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BD */  { UD_Ibsr,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BE */  { UD_Imovsx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BF */  { UD_Imovsx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpps,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Imovnti,      O_M,     O_Gvw,   O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C4 */  { UD_Ipinsrw,      O_P,     O_Ew,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_PR,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C6 */  { UD_Ishufps,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG },
+  /* C8 */  { UD_Ibswap,       O_rAXr8, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* C9 */  { UD_Ibswap,       O_rCXr9, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* CA */  { UD_Ibswap,       O_rDXr10, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CB */  { UD_Ibswap,       O_rBXr11, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CC */  { UD_Ibswap,       O_rSPr12, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CD */  { UD_Ibswap,       O_rBPr13, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CE */  { UD_Ibswap,       O_rSIr14, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CF */  { UD_Ibswap,       O_rDIr15, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Ipsrlw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_PR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipaddusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipaddusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Imovntq,      O_M,     O_P,     O_NONE,  P_none },
+  /* E8 */  { UD_Ipsubsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_00__reg[8] = {
+  /* 00 */  { UD_Isldt,        O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Istr,         O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Illdt,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iltr,         O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iverr,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iverw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg[8] = {
+  /* 00 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD },
+  /* 01 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD },
+  /* 02 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_02__MOD },
+  /* 03 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD },
+  /* 04 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_04__MOD },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod[2] = {
+  /* 00 */  { UD_Isgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmcall,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmresume,    O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxoff,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod[2] = {
+  /* 00 */  { UD_Isidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imonitor,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imwait,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_02__mod[2] = {
+  /* 00 */  { UD_Ilgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod[2] = {
+  /* 00 */  { UD_Ilidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR },
+  /* 06 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor[2] = {
+  /* 00 */  { UD_Ivmrun,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Ivmmcall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor[2] = {
+  /* 00 */  { UD_Ivmload,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Ivmsave,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Istgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor[2] = {
+  /* 00 */  { UD_Iclgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor[2] = {
+  /* 00 */  { UD_Iskinit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvlpga,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_04__mod[2] = {
+  /* 00 */  { UD_Ismsw,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Ilmsw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iinvlpg,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iswapgs,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Irdtscp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_0d__reg[8] = {
+  /* 00 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_18__reg[8] = {
+  /* 00 */  { UD_Iprefetchnta, O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetcht0,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetcht1,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetcht2,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ildmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Istmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iclflush,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ba__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ibt,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ibts,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ibtr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ibtc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Icmpxchg8b,   O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrld,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrst,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Ifabs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_If2xm1,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte[256] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iadd,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadd,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iadd,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iadd,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iadd,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 06 */  { UD_Ipush,        O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 07 */  { UD_Ipop,         O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 08 */  { UD_Ior,          O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 09 */  { UD_Ior,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0A */  { UD_Ior,          O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 0B */  { UD_Ior,          O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0C */  { UD_Ior,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 0D */  { UD_Ior,          O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 0E */  { UD_Ipush,        O_CS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iadc,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Iadc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Iadc,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iadc,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iadc,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 15 */  { UD_Iadc,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 16 */  { UD_Ipush,        O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 17 */  { UD_Ipop,         O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 18 */  { UD_Isbb,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 19 */  { UD_Isbb,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Isbb,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Isbb,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Isbb,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 1D */  { UD_Isbb,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 1E */  { UD_Ipush,        O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 1F */  { UD_Ipop,         O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 20 */  { UD_Iand,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 21 */  { UD_Iand,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 22 */  { UD_Iand,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 23 */  { UD_Iand,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 24 */  { UD_Iand,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 25 */  { UD_Iand,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Idaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 28 */  { UD_Isub,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Isub,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Isub,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Isub,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Isub,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 2D */  { UD_Isub,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Idas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 30 */  { UD_Ixor,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 31 */  { UD_Ixor,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 32 */  { UD_Ixor,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 33 */  { UD_Ixor,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 34 */  { UD_Ixor,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 35 */  { UD_Ixor,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iaaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 38 */  { UD_Icmp,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 39 */  { UD_Icmp,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3A */  { UD_Icmp,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 3B */  { UD_Icmp,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3C */  { UD_Icmp,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 3D */  { UD_Icmp,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iaas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 40 */  { UD_Iinc,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 41 */  { UD_Iinc,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 42 */  { UD_Iinc,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 43 */  { UD_Iinc,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 44 */  { UD_Iinc,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 45 */  { UD_Iinc,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 46 */  { UD_Iinc,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 47 */  { UD_Iinc,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 48 */  { UD_Idec,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 49 */  { UD_Idec,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 4A */  { UD_Idec,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 4B */  { UD_Idec,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 4C */  { UD_Idec,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 4D */  { UD_Idec,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 4E */  { UD_Idec,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 4F */  { UD_Idec,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 50 */  { UD_Ipush,        O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 51 */  { UD_Ipush,        O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 52 */  { UD_Ipush,        O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 53 */  { UD_Ipush,        O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 54 */  { UD_Ipush,        O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 55 */  { UD_Ipush,        O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 56 */  { UD_Ipush,        O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 57 */  { UD_Ipush,        O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 58 */  { UD_Ipop,         O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 59 */  { UD_Ipop,         O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 5A */  { UD_Ipop,         O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5B */  { UD_Ipop,         O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5C */  { UD_Ipop,         O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5D */  { UD_Ipop,         O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5E */  { UD_Ipop,         O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5F */  { UD_Ipop,         O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 60 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_60__OSIZE },
+  /* 61 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_61__OSIZE },
+  /* 62 */  { UD_Ibound,       O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* 63 */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_63__MODE },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Ipush,        O_Iz,    O_NONE,  O_NONE,  P_c1|P_oso },
+  /* 69 */  { UD_Iimul,        O_Gv,    O_Ev,    O_Iz,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipush,        O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* 6B */  { UD_Iimul,        O_Gv,    O_Ev,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinsb,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6D */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6D__OSIZE },
+  /* 6E */  { UD_Ioutsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6F */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6F__OSIZE },
+  /* 70 */  { UD_Ijo,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 71 */  { UD_Ijno,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 72 */  { UD_Ijb,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 73 */  { UD_Ijae,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 74 */  { UD_Ijz,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 75 */  { UD_Ijnz,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 76 */  { UD_Ijbe,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 77 */  { UD_Ija,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Ijs,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 79 */  { UD_Ijns,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7A */  { UD_Ijp,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7B */  { UD_Ijnp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7C */  { UD_Ijl,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7D */  { UD_Ijge,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7E */  { UD_Ijle,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7F */  { UD_Ijg,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 80 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_80__REG },
+  /* 81 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_81__REG },
+  /* 82 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_82__REG },
+  /* 83 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_83__REG },
+  /* 84 */  { UD_Itest,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 85 */  { UD_Itest,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 86 */  { UD_Ixchg,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 87 */  { UD_Ixchg,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 88 */  { UD_Imov,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 89 */  { UD_Imov,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8A */  { UD_Imov,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 8B */  { UD_Imov,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8C */  { UD_Imov,         O_Ev,    O_S,     O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8D */  { UD_Ilea,         O_Gv,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8E */  { UD_Imov,         O_S,     O_Ev,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8F */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_8F__REG },
+  /* 90 */  { UD_Ixchg,        O_rAXr8, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 91 */  { UD_Ixchg,        O_rCXr9, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 92 */  { UD_Ixchg,        O_rDXr10, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 93 */  { UD_Ixchg,        O_rBXr11, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 94 */  { UD_Ixchg,        O_rSPr12, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 95 */  { UD_Ixchg,        O_rBPr13, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 96 */  { UD_Ixchg,        O_rSIr14, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 97 */  { UD_Ixchg,        O_rDIr15, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 98 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_98__OSIZE },
+  /* 99 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_99__OSIZE },
+  /* 9A */  { UD_Icall,        O_Ap,    O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 9B */  { UD_Iwait,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9C */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE },
+  /* 9D */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE },
+  /* 9E */  { UD_Isahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9F */  { UD_Ilahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A0 */  { UD_Imov,         O_AL,    O_Ob,    O_NONE,  P_none },
+  /* A1 */  { UD_Imov,         O_rAX,   O_Ov,    O_NONE,  P_aso|P_oso|P_rexw },
+  /* A2 */  { UD_Imov,         O_Ob,    O_AL,    O_NONE,  P_none },
+  /* A3 */  { UD_Imov,         O_Ov,    O_rAX,   O_NONE,  P_aso|P_oso|P_rexw },
+  /* A4 */  { UD_Imovsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* A5 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A5__OSIZE },
+  /* A6 */  { UD_Icmpsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A7 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A7__OSIZE },
+  /* A8 */  { UD_Itest,        O_AL,    O_Ib,    O_NONE,  P_none },
+  /* A9 */  { UD_Itest,        O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* AA */  { UD_Istosb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AB */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AB__OSIZE },
+  /* AC */  { UD_Ilodsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AD */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AD__OSIZE },
+  /* AE */  { UD_Iscasb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AF__OSIZE },
+  /* B0 */  { UD_Imov,         O_ALr8b, O_Ib,    O_NONE,  P_rexb },
+  /* B1 */  { UD_Imov,         O_CLr9b, O_Ib,    O_NONE,  P_rexb },
+  /* B2 */  { UD_Imov,         O_DLr10b, O_Ib,    O_NONE, P_rexb },
+  /* B3 */  { UD_Imov,         O_BLr11b, O_Ib,    O_NONE, P_rexb },
+  /* B4 */  { UD_Imov,         O_AHr12b, O_Ib,    O_NONE, P_rexb },
+  /* B5 */  { UD_Imov,         O_CHr13b, O_Ib,    O_NONE, P_rexb },
+  /* B6 */  { UD_Imov,         O_DHr14b, O_Ib,    O_NONE, P_rexb },
+  /* B7 */  { UD_Imov,         O_BHr15b, O_Ib,    O_NONE, P_rexb },
+  /* B8 */  { UD_Imov,         O_rAXr8, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* B9 */  { UD_Imov,         O_rCXr9, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* BA */  { UD_Imov,         O_rDXr10, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BB */  { UD_Imov,         O_rBXr11, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BC */  { UD_Imov,         O_rSPr12, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BD */  { UD_Imov,         O_rBPr13, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BE */  { UD_Imov,         O_rSIr14, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BF */  { UD_Imov,         O_rDIr15, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* C0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C0__REG },
+  /* C1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C1__REG },
+  /* C2 */  { UD_Iret,         O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* C3 */  { UD_Iret,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* C4 */  { UD_Iles,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C5 */  { UD_Ilds,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C6__REG },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C7__REG },
+  /* C8 */  { UD_Ienter,       O_Iw,    O_Ib,    O_NONE,  P_def64|P_depM|P_none },
+  /* C9 */  { UD_Ileave,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CA */  { UD_Iretf,        O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* CB */  { UD_Iretf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CC */  { UD_Iint3,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CD */  { UD_Iint,         O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* CE */  { UD_Iinto,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* CF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_CF__OSIZE },
+  /* D0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D0__REG },
+  /* D1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D1__REG },
+  /* D2 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D2__REG },
+  /* D3 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D3__REG },
+  /* D4 */  { UD_Iaam,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D5 */  { UD_Iaad,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D6 */  { UD_Isalc,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D7 */  { UD_Ixlatb,       O_NONE,  O_NONE,  O_NONE,  P_rexw },
+  /* D8 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD },
+  /* D9 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD },
+  /* DA */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD },
+  /* DB */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD },
+  /* DC */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD },
+  /* DD */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD },
+  /* DE */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD },
+  /* DF */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD },
+  /* E0 */  { UD_Iloopnz,      O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E1 */  { UD_Iloope,       O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E2 */  { UD_Iloop,        O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E3 */  { UD_Igrp_asize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_E3__ASIZE },
+  /* E4 */  { UD_Iin,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* E5 */  { UD_Iin,          O_eAX,   O_Ib,    O_NONE,  P_oso },
+  /* E6 */  { UD_Iout,         O_Ib,    O_AL,    O_NONE,  P_none },
+  /* E7 */  { UD_Iout,         O_Ib,    O_eAX,   O_NONE,  P_oso },
+  /* E8 */  { UD_Icall,        O_Jz,    O_NONE,  O_NONE,  P_def64|P_oso },
+  /* E9 */  { UD_Ijmp,         O_Jz,    O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* EA */  { UD_Ijmp,         O_Ap,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* EB */  { UD_Ijmp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* EC */  { UD_Iin,          O_AL,    O_DX,    O_NONE,  P_none },
+  /* ED */  { UD_Iin,          O_eAX,   O_DX,    O_NONE,  P_oso },
+  /* EE */  { UD_Iout,         O_DX,    O_AL,    O_NONE,  P_none },
+  /* EF */  { UD_Iout,         O_DX,    O_eAX,   O_NONE,  P_oso },
+  /* F0 */  { UD_Ilock,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F1 */  { UD_Iint1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F2 */  { UD_Irepne,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F3 */  { UD_Irep,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F4 */  { UD_Ihlt,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F5 */  { UD_Icmc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F6__REG },
+  /* F7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F7__REG },
+  /* F8 */  { UD_Iclc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F9 */  { UD_Istc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FA */  { UD_Icli,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FB */  { UD_Isti,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FC */  { UD_Icld,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FD */  { UD_Istd,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FE__REG },
+  /* FF */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FF__REG },
+};
+
+static struct ud_itab_entry itab__1byte__op_60__osize[3] = {
+  /* 00 */  { UD_Ipusha,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipushad,      O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_61__osize[3] = {
+  /* 00 */  { UD_Ipopa,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipopad,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_63__mode[3] = {
+  /* 00 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 01 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 02 */  { UD_Imovsxd,      O_Gv,    O_Ed,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexx|P_rexr|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_6d__osize[3] = {
+  /* 00 */  { UD_Iinsw,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Iinsd,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_6f__osize[3] = {
+  /* 00 */  { UD_Ioutsw,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Ioutsd,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Ioutsq,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_80__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_81__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_82__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_83__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_8f__reg[8] = {
+  /* 00 */  { UD_Ipop,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_98__osize[3] = {
+  /* 00 */  { UD_Icbw,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icwde,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icdqe,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_99__osize[3] = {
+  /* 00 */  { UD_Icwd,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icdq,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icqo,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipushfq,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipopfq,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_a5__osize[3] = {
+  /* 00 */  { UD_Imovsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Imovsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Imovsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_a7__osize[3] = {
+  /* 00 */  { UD_Icmpsw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icmpsd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icmpsq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ab__osize[3] = {
+  /* 00 */  { UD_Istosw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Istosd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Istosq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ad__osize[3] = {
+  /* 00 */  { UD_Ilodsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Ilodsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Ilodsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AE__MOD__OP_00__REG },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifxsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifxrstor,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_af__osize[3] = {
+  /* 00 */  { UD_Iscasw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iscasd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iscasq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_c0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c6__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_c7__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_cf__osize[3] = {
+  /* 00 */  { UD_Iiretw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iiretd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iiretq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_d0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d2__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d3__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsub,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsub,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsub,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsub,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsub,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsub,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsub,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdiv,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdiv,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdiv,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdiv,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdiv,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdiv,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdiv,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ifst,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifldenv,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifldcw,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifnstenv,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstcw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifld,         O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifld,         O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifld,         O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifld,         O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifld,         O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifld,         O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifld,         O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifld,         O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifnop,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Ifstp1,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp1,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp1,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp1,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp1,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp1,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp1,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp1,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifchs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iftst,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifxam,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifld1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifldl2t,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifldl2e,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifldlpi,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifldlg2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifldln2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifldz,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Ifyl2x,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Ifptan,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Ifpatan,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Ifpxtract,    O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 35 */  { UD_Ifprem1,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Ifdecstp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 37 */  { UD_Ifncstp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 38 */  { UD_Ifprem,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 39 */  { UD_Ifyl2xp1,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3A */  { UD_Ifsqrt,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3B */  { UD_Ifsincos,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3C */  { UD_Ifrndint,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3D */  { UD_Ifscale,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3E */  { UD_Ifsin,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3F */  { UD_Ifcos,        O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovb,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovb,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovb,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovb,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovb,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovb,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovb,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovb,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmove,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmove,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmove,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmove,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmove,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmove,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmove,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmove,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovbe,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovbe,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovbe,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovbe,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovbe,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovbe,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovbe,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovbe,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovu,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovu,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovu,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovu,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovu,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovu,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovu,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovu,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Ifucompp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Ifld,         O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Ifstp,        O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovnb,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovnb,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovnb,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovnb,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovnb,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovnb,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovnb,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovnb,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmovne,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmovne,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmovne,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmovne,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmovne,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmovne,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmovne,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmovne,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovnbe,    O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovnbe,    O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovnbe,    O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovnbe,    O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovnbe,    O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovnbe,    O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovnbe,    O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovnbe,    O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovnu,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovnu,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovnu,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovnu,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovnu,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovnu,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovnu,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovnu,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Ifclex,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifninit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomi,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomi,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomi,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomi,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomi,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomi,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomi,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomi,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomi,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomi,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomi,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomi,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomi,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomi,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomi,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomi,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom2,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom2,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom2,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom2,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom2,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom2,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom2,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom2,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp3,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp3,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp3,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp3,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp3,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp3,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp3,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp3,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsub,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsub,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsub,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsub,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsub,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsub,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsub,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdiv,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdiv,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdiv,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdiv,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdiv,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdiv,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdiv,        O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifst,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifrstor,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ifnsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstsw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffree,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffree,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffree,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffree,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffree,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffree,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffree,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffree,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch4,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch4,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch4,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch4,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch4,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch4,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch4,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch4,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifst,         O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifst,         O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifst,         O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifst,         O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifst,         O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifst,         O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifst,         O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifst,         O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp,        O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp,        O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp,        O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp,        O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp,        O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp,        O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp,        O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp,        O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifucom,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Ifucom,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Ifucom,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifucom,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Ifucom,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifucom,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Ifucom,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 27 */  { UD_Ifucom,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 28 */  { UD_Ifucomp,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomp,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomp,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomp,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomp,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomp,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomp,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomp,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifaddp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifaddp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifaddp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifaddp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifaddp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifaddp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifaddp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifaddp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmulp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmulp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmulp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmulp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmulp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmulp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmulp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmulp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcomp5,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcomp5,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcomp5,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcomp5,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcomp5,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcomp5,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcomp5,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcomp5,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Ifcompp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Ifsubrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifbld,        O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifild,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifbstp,       O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifistp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffreep,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffreep,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffreep,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffreep,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffreep,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffreep,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffreep,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffreep,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch7,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch7,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch7,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch7,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch7,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch7,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch7,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch7,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifstp8,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifstp8,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifstp8,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifstp8,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifstp8,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifstp8,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifstp8,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifstp8,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp9,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp9,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp9,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp9,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp9,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp9,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp9,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp9,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifnstsw,      O_AX,    O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomip,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomip,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomip,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomip,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomip,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomip,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomip,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomip,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomip,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomip,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomip,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomip,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomip,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomip,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomip,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomip,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_e3__asize[3] = {
+  /* 00 */  { UD_Ijcxz,        O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 01 */  { UD_Ijecxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 02 */  { UD_Ijrcxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+};
+
+static struct ud_itab_entry itab__1byte__op_f6__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_f7__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_fe__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ff__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Icall,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Icall,        O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ijmp,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ijmp,         O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ipush,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__3dnow[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 59 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovupd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovupd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovapd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovapd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2pd,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntpd,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttpd2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtpd2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomisd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomisd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Imovmskpd,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iandpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorpd,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtpd2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtps2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Ipunpcklqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6D */  { UD_Ipunpckhqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6E */  { UD_Imovd,        O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovqa,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_V,     O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqa,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmppd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Ipinsrw,      O_V,     O_Ew,    O_Ib,    P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_VR,    O_Ib,    P_aso|P_rexr|P_rexb },
+  /* C6 */  { UD_Ishufpd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Ipsrlw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Imovq,        O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_VR,    O_NONE,  P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Icvttpd2dq,   O_V,     O_W,     O_NONE,  P_none },
+  /* E7 */  { UD_Imovntdq,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E8 */  { UD_Ipsubsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Ipsrldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Ipslldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmclear,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_ssef2__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovsd,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovddup,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2sd,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttsd2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtsd2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtsd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtsd2ss,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Isubsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Ipshuflw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpsd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovdq2q,     O_P,     O_VR,    O_NONE,  P_aso|P_rexb },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtpd2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Ilddqu,       O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovss,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovsldup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Imovshdup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2ss,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttss2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtss2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtss2sd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvttps2dq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Imovdqu,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufhw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovq,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqu,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpss,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovq2dq,     O_V,     O_PR,    O_NONE,  P_aso },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtdq2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxon,       O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+/* the order of this table matches enum ud_itab_index */
+struct ud_itab_entry * ud_itab_list[] = {
+  itab__0f,
+  itab__0f__op_00__reg,
+  itab__0f__op_01__reg,
+  itab__0f__op_01__reg__op_00__mod,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_01__mod,
+  itab__0f__op_01__reg__op_01__mod__op_01__rm,
+  itab__0f__op_01__reg__op_02__mod,
+  itab__0f__op_01__reg__op_03__mod,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor,
+  itab__0f__op_01__reg__op_04__mod,
+  itab__0f__op_01__reg__op_06__mod,
+  itab__0f__op_01__reg__op_07__mod,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_0d__reg,
+  itab__0f__op_18__reg,
+  itab__0f__op_71__reg,
+  itab__0f__op_72__reg,
+  itab__0f__op_73__reg,
+  itab__0f__op_ae__reg,
+  itab__0f__op_ae__reg__op_05__mod,
+  itab__0f__op_ae__reg__op_05__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_06__mod,
+  itab__0f__op_ae__reg__op_06__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_07__mod,
+  itab__0f__op_ae__reg__op_07__mod__op_01__rm,
+  itab__0f__op_ba__reg,
+  itab__0f__op_c7__reg,
+  itab__0f__op_c7__reg__op_00__vendor,
+  itab__0f__op_c7__reg__op_07__vendor,
+  itab__0f__op_d9__mod,
+  itab__0f__op_d9__mod__op_01__x87,
+  itab__1byte,
+  itab__1byte__op_60__osize,
+  itab__1byte__op_61__osize,
+  itab__1byte__op_63__mode,
+  itab__1byte__op_6d__osize,
+  itab__1byte__op_6f__osize,
+  itab__1byte__op_80__reg,
+  itab__1byte__op_81__reg,
+  itab__1byte__op_82__reg,
+  itab__1byte__op_83__reg,
+  itab__1byte__op_8f__reg,
+  itab__1byte__op_98__osize,
+  itab__1byte__op_99__osize,
+  itab__1byte__op_9c__mode,
+  itab__1byte__op_9c__mode__op_00__osize,
+  itab__1byte__op_9c__mode__op_01__osize,
+  itab__1byte__op_9d__mode,
+  itab__1byte__op_9d__mode__op_00__osize,
+  itab__1byte__op_9d__mode__op_01__osize,
+  itab__1byte__op_a5__osize,
+  itab__1byte__op_a7__osize,
+  itab__1byte__op_ab__osize,
+  itab__1byte__op_ad__osize,
+  itab__1byte__op_ae__mod,
+  itab__1byte__op_ae__mod__op_00__reg,
+  itab__1byte__op_af__osize,
+  itab__1byte__op_c0__reg,
+  itab__1byte__op_c1__reg,
+  itab__1byte__op_c6__reg,
+  itab__1byte__op_c7__reg,
+  itab__1byte__op_cf__osize,
+  itab__1byte__op_d0__reg,
+  itab__1byte__op_d1__reg,
+  itab__1byte__op_d2__reg,
+  itab__1byte__op_d3__reg,
+  itab__1byte__op_d8__mod,
+  itab__1byte__op_d8__mod__op_00__reg,
+  itab__1byte__op_d8__mod__op_01__x87,
+  itab__1byte__op_d9__mod,
+  itab__1byte__op_d9__mod__op_00__reg,
+  itab__1byte__op_d9__mod__op_01__x87,
+  itab__1byte__op_da__mod,
+  itab__1byte__op_da__mod__op_00__reg,
+  itab__1byte__op_da__mod__op_01__x87,
+  itab__1byte__op_db__mod,
+  itab__1byte__op_db__mod__op_00__reg,
+  itab__1byte__op_db__mod__op_01__x87,
+  itab__1byte__op_dc__mod,
+  itab__1byte__op_dc__mod__op_00__reg,
+  itab__1byte__op_dc__mod__op_01__x87,
+  itab__1byte__op_dd__mod,
+  itab__1byte__op_dd__mod__op_00__reg,
+  itab__1byte__op_dd__mod__op_01__x87,
+  itab__1byte__op_de__mod,
+  itab__1byte__op_de__mod__op_00__reg,
+  itab__1byte__op_de__mod__op_01__x87,
+  itab__1byte__op_df__mod,
+  itab__1byte__op_df__mod__op_00__reg,
+  itab__1byte__op_df__mod__op_01__x87,
+  itab__1byte__op_e3__asize,
+  itab__1byte__op_f6__reg,
+  itab__1byte__op_f7__reg,
+  itab__1byte__op_fe__reg,
+  itab__1byte__op_ff__reg,
+  itab__3dnow,
+  itab__pfx_sse66__0f,
+  itab__pfx_sse66__0f__op_71__reg,
+  itab__pfx_sse66__0f__op_72__reg,
+  itab__pfx_sse66__0f__op_73__reg,
+  itab__pfx_sse66__0f__op_c7__reg,
+  itab__pfx_sse66__0f__op_c7__reg__op_00__vendor,
+  itab__pfx_ssef2__0f,
+  itab__pfx_ssef3__0f,
+  itab__pfx_ssef3__0f__op_c7__reg,
+  itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor,
+};
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/itab.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,719 @@
+
+/* itab.h -- auto generated by opgen.py, do not edit. */
+
+#ifndef UD_ITAB_H
+#define UD_ITAB_H
+
+
+
+enum ud_itab_vendor_index {
+  ITAB__VENDOR_INDX__AMD,
+  ITAB__VENDOR_INDX__INTEL,
+};
+
+
+enum ud_itab_mode_index {
+  ITAB__MODE_INDX__16,
+  ITAB__MODE_INDX__32,
+  ITAB__MODE_INDX__64
+};
+
+
+enum ud_itab_mod_index {
+  ITAB__MOD_INDX__NOT_11,
+  ITAB__MOD_INDX__11
+};
+
+
+enum ud_itab_index {
+  ITAB__0F,
+  ITAB__0F__OP_00__REG,
+  ITAB__0F__OP_01__REG,
+  ITAB__0F__OP_01__REG__OP_00__MOD,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_01__MOD,
+  ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_02__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR,
+  ITAB__0F__OP_01__REG__OP_04__MOD,
+  ITAB__0F__OP_01__REG__OP_06__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_0D__REG,
+  ITAB__0F__OP_18__REG,
+  ITAB__0F__OP_71__REG,
+  ITAB__0F__OP_72__REG,
+  ITAB__0F__OP_73__REG,
+  ITAB__0F__OP_AE__REG,
+  ITAB__0F__OP_AE__REG__OP_05__MOD,
+  ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_06__MOD,
+  ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_07__MOD,
+  ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_BA__REG,
+  ITAB__0F__OP_C7__REG,
+  ITAB__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__0F__OP_C7__REG__OP_07__VENDOR,
+  ITAB__0F__OP_D9__MOD,
+  ITAB__0F__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE,
+  ITAB__1BYTE__OP_60__OSIZE,
+  ITAB__1BYTE__OP_61__OSIZE,
+  ITAB__1BYTE__OP_63__MODE,
+  ITAB__1BYTE__OP_6D__OSIZE,
+  ITAB__1BYTE__OP_6F__OSIZE,
+  ITAB__1BYTE__OP_80__REG,
+  ITAB__1BYTE__OP_81__REG,
+  ITAB__1BYTE__OP_82__REG,
+  ITAB__1BYTE__OP_83__REG,
+  ITAB__1BYTE__OP_8F__REG,
+  ITAB__1BYTE__OP_98__OSIZE,
+  ITAB__1BYTE__OP_99__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE,
+  ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE,
+  ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_A5__OSIZE,
+  ITAB__1BYTE__OP_A7__OSIZE,
+  ITAB__1BYTE__OP_AB__OSIZE,
+  ITAB__1BYTE__OP_AD__OSIZE,
+  ITAB__1BYTE__OP_AE__MOD,
+  ITAB__1BYTE__OP_AE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_AF__OSIZE,
+  ITAB__1BYTE__OP_C0__REG,
+  ITAB__1BYTE__OP_C1__REG,
+  ITAB__1BYTE__OP_C6__REG,
+  ITAB__1BYTE__OP_C7__REG,
+  ITAB__1BYTE__OP_CF__OSIZE,
+  ITAB__1BYTE__OP_D0__REG,
+  ITAB__1BYTE__OP_D1__REG,
+  ITAB__1BYTE__OP_D2__REG,
+  ITAB__1BYTE__OP_D3__REG,
+  ITAB__1BYTE__OP_D8__MOD,
+  ITAB__1BYTE__OP_D8__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D8__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_D9__MOD,
+  ITAB__1BYTE__OP_D9__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DA__MOD,
+  ITAB__1BYTE__OP_DA__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DA__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DB__MOD,
+  ITAB__1BYTE__OP_DB__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DB__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DC__MOD,
+  ITAB__1BYTE__OP_DC__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DC__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DD__MOD,
+  ITAB__1BYTE__OP_DD__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DD__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DE__MOD,
+  ITAB__1BYTE__OP_DE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DE__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DF__MOD,
+  ITAB__1BYTE__OP_DF__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DF__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_E3__ASIZE,
+  ITAB__1BYTE__OP_F6__REG,
+  ITAB__1BYTE__OP_F7__REG,
+  ITAB__1BYTE__OP_FE__REG,
+  ITAB__1BYTE__OP_FF__REG,
+  ITAB__3DNOW,
+  ITAB__PFX_SSE66__0F,
+  ITAB__PFX_SSE66__0F__OP_71__REG,
+  ITAB__PFX_SSE66__0F__OP_72__REG,
+  ITAB__PFX_SSE66__0F__OP_73__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__PFX_SSEF2__0F,
+  ITAB__PFX_SSEF3__0F,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR,
+};
+
+
+enum ud_mnemonic_code {
+  UD_I3dnow,
+  UD_Iaaa,
+  UD_Iaad,
+  UD_Iaam,
+  UD_Iaas,
+  UD_Iadc,
+  UD_Iadd,
+  UD_Iaddpd,
+  UD_Iaddps,
+  UD_Iaddsd,
+  UD_Iaddss,
+  UD_Iaddsubpd,
+  UD_Iaddsubps,
+  UD_Iand,
+  UD_Iandpd,
+  UD_Iandps,
+  UD_Iandnpd,
+  UD_Iandnps,
+  UD_Iarpl,
+  UD_Imovsxd,
+  UD_Ibound,
+  UD_Ibsf,
+  UD_Ibsr,
+  UD_Ibswap,
+  UD_Ibt,
+  UD_Ibtc,
+  UD_Ibtr,
+  UD_Ibts,
+  UD_Icall,
+  UD_Icbw,
+  UD_Icwde,
+  UD_Icdqe,
+  UD_Iclc,
+  UD_Icld,
+  UD_Iclflush,
+  UD_Iclgi,
+  UD_Icli,
+  UD_Iclts,
+  UD_Icmc,
+  UD_Icmovo,
+  UD_Icmovno,
+  UD_Icmovb,
+  UD_Icmovae,
+  UD_Icmovz,
+  UD_Icmovnz,
+  UD_Icmovbe,
+  UD_Icmova,
+  UD_Icmovs,
+  UD_Icmovns,
+  UD_Icmovp,
+  UD_Icmovnp,
+  UD_Icmovl,
+  UD_Icmovge,
+  UD_Icmovle,
+  UD_Icmovg,
+  UD_Icmp,
+  UD_Icmppd,
+  UD_Icmpps,
+  UD_Icmpsb,
+  UD_Icmpsw,
+  UD_Icmpsd,
+  UD_Icmpsq,
+  UD_Icmpss,
+  UD_Icmpxchg,
+  UD_Icmpxchg8b,
+  UD_Icomisd,
+  UD_Icomiss,
+  UD_Icpuid,
+  UD_Icvtdq2pd,
+  UD_Icvtdq2ps,
+  UD_Icvtpd2dq,
+  UD_Icvtpd2pi,
+  UD_Icvtpd2ps,
+  UD_Icvtpi2ps,
+  UD_Icvtpi2pd,
+  UD_Icvtps2dq,
+  UD_Icvtps2pi,
+  UD_Icvtps2pd,
+  UD_Icvtsd2si,
+  UD_Icvtsd2ss,
+  UD_Icvtsi2ss,
+  UD_Icvtss2si,
+  UD_Icvtss2sd,
+  UD_Icvttpd2pi,
+  UD_Icvttpd2dq,
+  UD_Icvttps2dq,
+  UD_Icvttps2pi,
+  UD_Icvttsd2si,
+  UD_Icvtsi2sd,
+  UD_Icvttss2si,
+  UD_Icwd,
+  UD_Icdq,
+  UD_Icqo,
+  UD_Idaa,
+  UD_Idas,
+  UD_Idec,
+  UD_Idiv,
+  UD_Idivpd,
+  UD_Idivps,
+  UD_Idivsd,
+  UD_Idivss,
+  UD_Iemms,
+  UD_Ienter,
+  UD_If2xm1,
+  UD_Ifabs,
+  UD_Ifadd,
+  UD_Ifaddp,
+  UD_Ifbld,
+  UD_Ifbstp,
+  UD_Ifchs,
+  UD_Ifclex,
+  UD_Ifcmovb,
+  UD_Ifcmove,
+  UD_Ifcmovbe,
+  UD_Ifcmovu,
+  UD_Ifcmovnb,
+  UD_Ifcmovne,
+  UD_Ifcmovnbe,
+  UD_Ifcmovnu,
+  UD_Ifucomi,
+  UD_Ifcom,
+  UD_Ifcom2,
+  UD_Ifcomp3,
+  UD_Ifcomi,
+  UD_Ifucomip,
+  UD_Ifcomip,
+  UD_Ifcomp,
+  UD_Ifcomp5,
+  UD_Ifcompp,
+  UD_Ifcos,
+  UD_Ifdecstp,
+  UD_Ifdiv,
+  UD_Ifdivp,
+  UD_Ifdivr,
+  UD_Ifdivrp,
+  UD_Ifemms,
+  UD_Iffree,
+  UD_Iffreep,
+  UD_Ificom,
+  UD_Ificomp,
+  UD_Ifild,
+  UD_Ifncstp,
+  UD_Ifninit,
+  UD_Ifiadd,
+  UD_Ifidivr,
+  UD_Ifidiv,
+  UD_Ifisub,
+  UD_Ifisubr,
+  UD_Ifist,
+  UD_Ifistp,
+  UD_Ifisttp,
+  UD_Ifld,
+  UD_Ifld1,
+  UD_Ifldl2t,
+  UD_Ifldl2e,
+  UD_Ifldlpi,
+  UD_Ifldlg2,
+  UD_Ifldln2,
+  UD_Ifldz,
+  UD_Ifldcw,
+  UD_Ifldenv,
+  UD_Ifmul,
+  UD_Ifmulp,
+  UD_Ifimul,
+  UD_Ifnop,
+  UD_Ifpatan,
+  UD_Ifprem,
+  UD_Ifprem1,
+  UD_Ifptan,
+  UD_Ifrndint,
+  UD_Ifrstor,
+  UD_Ifnsave,
+  UD_Ifscale,
+  UD_Ifsin,
+  UD_Ifsincos,
+  UD_Ifsqrt,
+  UD_Ifstp,
+  UD_Ifstp1,
+  UD_Ifstp8,
+  UD_Ifstp9,
+  UD_Ifst,
+  UD_Ifnstcw,
+  UD_Ifnstenv,
+  UD_Ifnstsw,
+  UD_Ifsub,
+  UD_Ifsubp,
+  UD_Ifsubr,
+  UD_Ifsubrp,
+  UD_Iftst,
+  UD_Ifucom,
+  UD_Ifucomp,
+  UD_Ifucompp,
+  UD_Ifxam,
+  UD_Ifxch,
+  UD_Ifxch4,
+  UD_Ifxch7,
+  UD_Ifxrstor,
+  UD_Ifxsave,
+  UD_Ifpxtract,
+  UD_Ifyl2x,
+  UD_Ifyl2xp1,
+  UD_Ihaddpd,
+  UD_Ihaddps,
+  UD_Ihlt,
+  UD_Ihsubpd,
+  UD_Ihsubps,
+  UD_Iidiv,
+  UD_Iin,
+  UD_Iimul,
+  UD_Iinc,
+  UD_Iinsb,
+  UD_Iinsw,
+  UD_Iinsd,
+  UD_Iint1,
+  UD_Iint3,
+  UD_Iint,
+  UD_Iinto,
+  UD_Iinvd,
+  UD_Iinvlpg,
+  UD_Iinvlpga,
+  UD_Iiretw,
+  UD_Iiretd,
+  UD_Iiretq,
+  UD_Ijo,
+  UD_Ijno,
+  UD_Ijb,
+  UD_Ijae,
+  UD_Ijz,
+  UD_Ijnz,
+  UD_Ijbe,
+  UD_Ija,
+  UD_Ijs,
+  UD_Ijns,
+  UD_Ijp,
+  UD_Ijnp,
+  UD_Ijl,
+  UD_Ijge,
+  UD_Ijle,
+  UD_Ijg,
+  UD_Ijcxz,
+  UD_Ijecxz,
+  UD_Ijrcxz,
+  UD_Ijmp,
+  UD_Ilahf,
+  UD_Ilar,
+  UD_Ilddqu,
+  UD_Ildmxcsr,
+  UD_Ilds,
+  UD_Ilea,
+  UD_Iles,
+  UD_Ilfs,
+  UD_Ilgs,
+  UD_Ilidt,
+  UD_Ilss,
+  UD_Ileave,
+  UD_Ilfence,
+  UD_Ilgdt,
+  UD_Illdt,
+  UD_Ilmsw,
+  UD_Ilock,
+  UD_Ilodsb,
+  UD_Ilodsw,
+  UD_Ilodsd,
+  UD_Ilodsq,
+  UD_Iloopnz,
+  UD_Iloope,
+  UD_Iloop,
+  UD_Ilsl,
+  UD_Iltr,
+  UD_Imaskmovq,
+  UD_Imaxpd,
+  UD_Imaxps,
+  UD_Imaxsd,
+  UD_Imaxss,
+  UD_Imfence,
+  UD_Iminpd,
+  UD_Iminps,
+  UD_Iminsd,
+  UD_Iminss,
+  UD_Imonitor,
+  UD_Imov,
+  UD_Imovapd,
+  UD_Imovaps,
+  UD_Imovd,
+  UD_Imovddup,
+  UD_Imovdqa,
+  UD_Imovdqu,
+  UD_Imovdq2q,
+  UD_Imovhpd,
+  UD_Imovhps,
+  UD_Imovlhps,
+  UD_Imovlpd,
+  UD_Imovlps,
+  UD_Imovhlps,
+  UD_Imovmskpd,
+  UD_Imovmskps,
+  UD_Imovntdq,
+  UD_Imovnti,
+  UD_Imovntpd,
+  UD_Imovntps,
+  UD_Imovntq,
+  UD_Imovq,
+  UD_Imovqa,
+  UD_Imovq2dq,
+  UD_Imovsb,
+  UD_Imovsw,
+  UD_Imovsd,
+  UD_Imovsq,
+  UD_Imovsldup,
+  UD_Imovshdup,
+  UD_Imovss,
+  UD_Imovsx,
+  UD_Imovupd,
+  UD_Imovups,
+  UD_Imovzx,
+  UD_Imul,
+  UD_Imulpd,
+  UD_Imulps,
+  UD_Imulsd,
+  UD_Imulss,
+  UD_Imwait,
+  UD_Ineg,
+  UD_Inop,
+  UD_Inot,
+  UD_Ior,
+  UD_Iorpd,
+  UD_Iorps,
+  UD_Iout,
+  UD_Ioutsb,
+  UD_Ioutsw,
+  UD_Ioutsd,
+  UD_Ioutsq,
+  UD_Ipacksswb,
+  UD_Ipackssdw,
+  UD_Ipackuswb,
+  UD_Ipaddb,
+  UD_Ipaddw,
+  UD_Ipaddq,
+  UD_Ipaddsb,
+  UD_Ipaddsw,
+  UD_Ipaddusb,
+  UD_Ipaddusw,
+  UD_Ipand,
+  UD_Ipandn,
+  UD_Ipause,
+  UD_Ipavgb,
+  UD_Ipavgw,
+  UD_Ipcmpeqb,
+  UD_Ipcmpeqw,
+  UD_Ipcmpeqd,
+  UD_Ipcmpgtb,
+  UD_Ipcmpgtw,
+  UD_Ipcmpgtd,
+  UD_Ipextrw,
+  UD_Ipinsrw,
+  UD_Ipmaddwd,
+  UD_Ipmaxsw,
+  UD_Ipmaxub,
+  UD_Ipminsw,
+  UD_Ipminub,
+  UD_Ipmovmskb,
+  UD_Ipmulhuw,
+  UD_Ipmulhw,
+  UD_Ipmullw,
+  UD_Ipmuludq,
+  UD_Ipop,
+  UD_Ipopa,
+  UD_Ipopad,
+  UD_Ipopfw,
+  UD_Ipopfd,
+  UD_Ipopfq,
+  UD_Ipor,
+  UD_Iprefetch,
+  UD_Iprefetchnta,
+  UD_Iprefetcht0,
+  UD_Iprefetcht1,
+  UD_Iprefetcht2,
+  UD_Ipsadbw,
+  UD_Ipshufd,
+  UD_Ipshufhw,
+  UD_Ipshuflw,
+  UD_Ipshufw,
+  UD_Ipslldq,
+  UD_Ipsllw,
+  UD_Ipslld,
+  UD_Ipsllq,
+  UD_Ipsraw,
+  UD_Ipsrad,
+  UD_Ipsrlw,
+  UD_Ipsrld,
+  UD_Ipsrlq,
+  UD_Ipsrldq,
+  UD_Ipsubb,
+  UD_Ipsubw,
+  UD_Ipsubd,
+  UD_Ipsubq,
+  UD_Ipsubsb,
+  UD_Ipsubsw,
+  UD_Ipsubusb,
+  UD_Ipsubusw,
+  UD_Ipunpckhbw,
+  UD_Ipunpckhwd,
+  UD_Ipunpckhdq,
+  UD_Ipunpckhqdq,
+  UD_Ipunpcklbw,
+  UD_Ipunpcklwd,
+  UD_Ipunpckldq,
+  UD_Ipunpcklqdq,
+  UD_Ipi2fw,
+  UD_Ipi2fd,
+  UD_Ipf2iw,
+  UD_Ipf2id,
+  UD_Ipfnacc,
+  UD_Ipfpnacc,
+  UD_Ipfcmpge,
+  UD_Ipfmin,
+  UD_Ipfrcp,
+  UD_Ipfrsqrt,
+  UD_Ipfsub,
+  UD_Ipfadd,
+  UD_Ipfcmpgt,
+  UD_Ipfmax,
+  UD_Ipfrcpit1,
+  UD_Ipfrspit1,
+  UD_Ipfsubr,
+  UD_Ipfacc,
+  UD_Ipfcmpeq,
+  UD_Ipfmul,
+  UD_Ipfrcpit2,
+  UD_Ipmulhrw,
+  UD_Ipswapd,
+  UD_Ipavgusb,
+  UD_Ipush,
+  UD_Ipusha,
+  UD_Ipushad,
+  UD_Ipushfw,
+  UD_Ipushfd,
+  UD_Ipushfq,
+  UD_Ipxor,
+  UD_Ircl,
+  UD_Ircr,
+  UD_Irol,
+  UD_Iror,
+  UD_Ircpps,
+  UD_Ircpss,
+  UD_Irdmsr,
+  UD_Irdpmc,
+  UD_Irdtsc,
+  UD_Irdtscp,
+  UD_Irepne,
+  UD_Irep,
+  UD_Iret,
+  UD_Iretf,
+  UD_Irsm,
+  UD_Irsqrtps,
+  UD_Irsqrtss,
+  UD_Isahf,
+  UD_Isal,
+  UD_Isalc,
+  UD_Isar,
+  UD_Ishl,
+  UD_Ishr,
+  UD_Isbb,
+  UD_Iscasb,
+  UD_Iscasw,
+  UD_Iscasd,
+  UD_Iscasq,
+  UD_Iseto,
+  UD_Isetno,
+  UD_Isetb,
+  UD_Isetnb,
+  UD_Isetz,
+  UD_Isetnz,
+  UD_Isetbe,
+  UD_Iseta,
+  UD_Isets,
+  UD_Isetns,
+  UD_Isetp,
+  UD_Isetnp,
+  UD_Isetl,
+  UD_Isetge,
+  UD_Isetle,
+  UD_Isetg,
+  UD_Isfence,
+  UD_Isgdt,
+  UD_Ishld,
+  UD_Ishrd,
+  UD_Ishufpd,
+  UD_Ishufps,
+  UD_Isidt,
+  UD_Isldt,
+  UD_Ismsw,
+  UD_Isqrtps,
+  UD_Isqrtpd,
+  UD_Isqrtsd,
+  UD_Isqrtss,
+  UD_Istc,
+  UD_Istd,
+  UD_Istgi,
+  UD_Isti,
+  UD_Iskinit,
+  UD_Istmxcsr,
+  UD_Istosb,
+  UD_Istosw,
+  UD_Istosd,
+  UD_Istosq,
+  UD_Istr,
+  UD_Isub,
+  UD_Isubpd,
+  UD_Isubps,
+  UD_Isubsd,
+  UD_Isubss,
+  UD_Iswapgs,
+  UD_Isyscall,
+  UD_Isysenter,
+  UD_Isysexit,
+  UD_Isysret,
+  UD_Itest,
+  UD_Iucomisd,
+  UD_Iucomiss,
+  UD_Iud2,
+  UD_Iunpckhpd,
+  UD_Iunpckhps,
+  UD_Iunpcklps,
+  UD_Iunpcklpd,
+  UD_Iverr,
+  UD_Iverw,
+  UD_Ivmcall,
+  UD_Ivmclear,
+  UD_Ivmxon,
+  UD_Ivmptrld,
+  UD_Ivmptrst,
+  UD_Ivmresume,
+  UD_Ivmxoff,
+  UD_Ivmrun,
+  UD_Ivmmcall,
+  UD_Ivmload,
+  UD_Ivmsave,
+  UD_Iwait,
+  UD_Iwbinvd,
+  UD_Iwrmsr,
+  UD_Ixadd,
+  UD_Ixchg,
+  UD_Ixlatb,
+  UD_Ixor,
+  UD_Ixorpd,
+  UD_Ixorps,
+  UD_Idb,
+  UD_Iinvalid,
+  UD_Id3vil,
+  UD_Ina,
+  UD_Igrp_reg,
+  UD_Igrp_rm,
+  UD_Igrp_vendor,
+  UD_Igrp_x87,
+  UD_Igrp_mode,
+  UD_Igrp_osize,
+  UD_Igrp_asize,
+  UD_Igrp_mod,
+  UD_Inone,
+};
+
+
+
+extern const char* ud_mnemonics_str[];;
+extern struct ud_itab_entry* ud_itab_list[];
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/kdb_dis.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include <xen/compile.h>                /* for XEN_SUBVERSION */
+#include "../../include/kdbinc.h"
+#include "extern.h"
+
+static void (*dis_syntax)(ud_t*) = UD_SYN_ATT; /* default dis-assembly syntax */
+
+static struct {                         /* info for kdb_read_byte_for_ud() */
+    kdbva_t kud_instr_addr;
+    domid_t kud_domid;
+} kdb_ud_rd_info;
+
+/* called via function ptr by ud when disassembling. 
+ * kdb info passed via kdb_ud_rd_info{} 
+ */
+static int
+kdb_read_byte_for_ud(struct ud *udp)
+{
+    kdbbyt_t bytebuf;
+    domid_t domid = kdb_ud_rd_info.kud_domid;
+    kdbva_t addr = kdb_ud_rd_info.kud_instr_addr;
+
+    if (kdb_read_mem(addr, &bytebuf, 1, domid) == 1) {
+        kdb_ud_rd_info.kud_instr_addr++;
+        KDBGP1("udrd:addr:%lx domid:%d byt:%x\n", addr, domid, bytebuf);
+        return bytebuf;
+    }
+    KDBGP1("udrd:addr:%lx domid:%d err\n", addr, domid);
+    return UD_EOI;
+}
+
+/* 
+ * given a domid, convert addr to symbol and print it 
+ * Eg: ffff828c801235e2: idle_loop+52                  jmp  idle_loop+55
+ *    Called twice here for idle_loop. In first case, nl is null, 
+ *    in the second case nl == '\n'
+ */
+void
+kdb_prnt_addr2sym(domid_t domid, kdbva_t addr, char *nl)
+{
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1], pbuf[150], prefix[8];
+    char *p = buf;
+
+    prefix[0]='\0';
+    if (domid != DOMID_IDLE) {
+        snprintf(prefix, 8, "%x:", domid);
+        p = kdb_guest_addr2sym(addr, domid, &offs);
+    } else
+        symbols_lookup(addr, &sz, &offs, buf);
+
+    snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
+    if (*nl != '\n')
+        kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
+    else
+        kdbp("%s%s", pbuf, nl);
+
+}
+
+static int
+kdb_jump_instr(enum ud_mnemonic_code mnemonic)
+{
+    return (mnemonic >= UD_Ijo && mnemonic <= UD_Ijmp);
+}
+
+/*
+ * print one instr: function so that we can print offsets of jmp etc.. as
+ *  symbol+offset instead of just address
+ */
+static void
+kdb_print_one_instr(struct ud *udp, domid_t domid)
+{
+    signed long val = 0;
+    ud_type_t type = udp->operand[0].type;
+
+    if ((udp->mnemonic == UD_Icall || kdb_jump_instr(udp->mnemonic)) &&
+        type == UD_OP_JIMM) {
+        
+        int sz = udp->operand[0].size;
+        char *p, ibuf[40], *q = ibuf;
+        kdbva_t addr;
+
+        if (sz == 8) val = udp->operand[0].lval.sbyte;
+        else if (sz == 16) val = udp->operand[0].lval.sword;
+        else if (sz == 32) val = udp->operand[0].lval.sdword;
+        else if (sz == 64) val = udp->operand[0].lval.sqword;
+        else kdbp("kdb_print_one_instr: Inval sz:z%d\n", sz);
+
+        addr = udp->pc + val;
+        for(p=ud_insn_asm(udp); (*q=*p) && *p!=' '; p++,q++);
+        *q='\0';
+        kdbp(" %-4s ", ibuf);    /* space before for long func names */
+        kdb_prnt_addr2sym(domid, addr, "\n");
+    } else
+        kdbp(" %-24s\n", ud_insn_asm(udp));
+#if 0
+    kdbp("mnemonic:z%d ", udp->mnemonic);
+    if (type == UD_OP_CONST) kdbp("type is const\n");
+    else if (type == UD_OP_JIMM) kdbp("type is JIMM\n");
+    else if (type == UD_OP_IMM) kdbp("type is IMM\n");
+    else if (type == UD_OP_PTR) kdbp("type is PTR\n");
+#endif
+}
+
+static void
+kdb_setup_ud(struct ud *udp, kdbva_t addr, domid_t domid)
+{
+    int bitness = kdb_guest_bitness(domid);
+    uint vendor = (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ?
+                                           UD_VENDOR_AMD : UD_VENDOR_INTEL;
+
+    KDBGP1("setup_ud:domid:%d bitness:%d addr:%lx\n", domid, bitness, addr);
+    ud_init(udp);
+    ud_set_mode(udp, kdb_guest_bitness(domid));
+    ud_set_syntax(udp, dis_syntax); 
+    ud_set_vendor(udp, vendor);           /* HVM: vmx/svm different instrs*/
+    ud_set_pc(udp, addr);                 /* for numbers printed on left */
+    ud_set_input_hook(udp, kdb_read_byte_for_ud);
+    kdb_ud_rd_info.kud_instr_addr = addr;
+    kdb_ud_rd_info.kud_domid = domid;
+}
+
+/*
+ * given an addr, print given number of instructions.
+ * Returns: address of next instruction in the stream
+ */
+kdbva_t
+kdb_print_instr(kdbva_t addr, long num, domid_t domid)
+{
+    struct ud ud_s;
+
+    KDBGP1("print_instr:addr:0x%lx num:%ld domid:%x\n", addr, num, domid);
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    while(num--) {
+        if (ud_disassemble(&ud_s)) {
+            uint64_t pc = ud_insn_off(&ud_s);
+            /* kdbp("%08x: ",(int)pc); */
+            kdbp("%016lx: ", pc);
+            kdb_prnt_addr2sym(domid, pc, "");
+            kdb_print_one_instr(&ud_s, domid);
+        } else
+            kdbp("KDB:Couldn't disassemble PC:0x%lx\n", addr);
+            /* for stack reads, don't always display error */
+    }
+    KDBGP1("print_instr:kudaddr:0x%lx\n", kdb_ud_rd_info.kud_instr_addr);
+    return kdb_ud_rd_info.kud_instr_addr;
+}
+
+void
+kdb_display_pc(struct cpu_user_regs *regs)
+{   
+    domid_t domid;
+    struct cpu_user_regs regs1 = *regs;
+    domid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+
+    regs1.KDBIP = regs->KDBIP;
+    kdb_print_instr(regs1.KDBIP, 1, domid);
+}
+
+/* check if the instr at the addr is call instruction
+ * RETURNS: size of the instr if it's a call instr, else 0
+ */
+int
+kdb_check_call_instr(domid_t domid, kdbva_t addr)
+{
+    struct ud ud_s;
+    int sz;
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    if ((sz=ud_disassemble(&ud_s)) && ud_s.mnemonic == UD_Icall)
+        return (sz);
+    return 0;
+}
+
+/* toggle ATT and Intel syntaxes */
+void
+kdb_toggle_dis_syntax(void)
+{
+    if (dis_syntax == UD_SYN_INTEL) {
+        dis_syntax = UD_SYN_ATT;
+        kdbp("dis syntax now set to ATT (Gas)\n");
+    } else {
+        dis_syntax = UD_SYN_INTEL;
+        kdbp("dis syntax now set to Intel (NASM)\n");
+    }
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn-att.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-att.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,211 @@
+/* -----------------------------------------------------------------------------
+ * syn-att.c
+ *
+ * Copyright (c) 2004, 2005, 2006 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case 16 : case 32 :
+		mkasm(u, "*");   break;
+	default: break;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+gen_operand(struct ud* u, struct ud_operand* op)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, "%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM:
+		if (u->br_far) opr_cast(u, op);
+		if (u->pfx_seg)
+			mkasm(u, "%%%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", (-op->lval.sbyte) & 0xff);
+			else	mkasm(u, "0x%x", op->lval.sbyte);
+		} 
+		else if (op->offset == 16) 
+			mkasm(u, "0x%x", op->lval.uword);
+		else if (op->offset == 32) 
+			mkasm(u, "0x%lx", op->lval.udword);
+		else if (op->offset == 64) 
+			mkasm(u, "0x" FMT64 "x", op->lval.uqword);
+
+		if (op->base)
+			mkasm(u, "(%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		if (op->index) {
+			if (op->base)
+				mkasm(u, ",");
+			else mkasm(u, "(");
+			mkasm(u, "%%%s", ud_reg_tab[op->index - UD_R_AL]);
+		}
+		if (op->scale)
+			mkasm(u, ",%d", op->scale);
+		if (op->base || op->index)
+			mkasm(u, ")");
+		break;
+
+	case UD_OP_IMM:
+		switch (op->size) {
+			case  8: mkasm(u, "$0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "$0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "$0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "$0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "$0x%x, $0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "$0x%x, $0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+			
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to AT&T syntax 
+ * =============================================================================
+ */
+extern void 
+ud_translate_att(struct ud *u)
+{
+  int size = 0;
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+  	mkasm(u,  "lock ");
+  if (u->pfx_rep)
+	mkasm(u,  "rep ");
+  if (u->pfx_repne)
+		mkasm(u,  "repne ");
+
+  /* special instructions */
+  switch (u->mnemonic) {
+	case UD_Iretf: 
+		mkasm(u, "lret "); 
+		break;
+	case UD_Idb:
+		mkasm(u, ".byte 0x%x", u->operand[0].lval.ubyte);
+		return;
+	case UD_Ijmp:
+	case UD_Icall:
+		if (u->br_far) mkasm(u,  "l");
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+		break;
+	case UD_Ibound:
+	case UD_Ienter:
+		if (u->operand[0].type != UD_NONE)
+			gen_operand(u, &u->operand[0]);
+		if (u->operand[1].type != UD_NONE) {
+			mkasm(u, ",");
+			gen_operand(u, &u->operand[1]);
+		}
+		return;
+	default:
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+  }
+
+  if (u->c1)
+	size = u->operand[0].size;
+  else if (u->c2)
+	size = u->operand[1].size;
+  else if (u->c3)
+	size = u->operand[2].size;
+
+  if (size == 8)
+	mkasm(u, "b");
+  else if (size == 16)
+	mkasm(u, "w");
+  else if (size == 64)
+ 	mkasm(u, "q");
+
+  mkasm(u, " ");
+
+  if (u->operand[2].type != UD_NONE) {
+	gen_operand(u, &u->operand[2]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[1].type != UD_NONE) {
+	gen_operand(u, &u->operand[1]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[0].type != UD_NONE)
+	gen_operand(u, &u->operand[0]);
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn-intel.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-intel.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,208 @@
+/* -----------------------------------------------------------------------------
+ * syn-intel.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case  8: mkasm(u, "byte " ); break;
+	case 16: mkasm(u, "word " ); break;
+	case 32: mkasm(u, "dword "); break;
+	case 64: mkasm(u, "qword "); break;
+	case 80: mkasm(u, "tword "); break;
+	default: break;
+  }
+  if (u->br_far)
+	mkasm(u, "far "); 
+  else if (u->br_near)
+	mkasm(u, "near ");
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void gen_operand(struct ud* u, struct ud_operand* op, int syn_cast)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM: {
+
+		int op_f = 0;
+
+		if (syn_cast) 
+			opr_cast(u, op);
+
+		mkasm(u, "[");
+
+		if (u->pfx_seg)
+			mkasm(u, "%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+		if (op->base) {
+			mkasm(u, "%s", ud_reg_tab[op->base - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->index) {
+			if (op_f)
+				mkasm(u, "+");
+			mkasm(u, "%s", ud_reg_tab[op->index - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->scale)
+			mkasm(u, "*%d", op->scale);
+
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", -op->lval.sbyte);
+			else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sbyte);
+		}
+		else if (op->offset == 16)
+			mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.uword);
+		else if (op->offset == 32) {
+			if (u->adr_mode == 64) {
+				if (op->lval.sdword < 0)
+					mkasm(u, "-0x%x", -op->lval.sdword);
+				else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sdword);
+			} 
+			else	mkasm(u, "%s0x%lx", (op_f) ? "+" : "", op->lval.udword);
+		}
+		else if (op->offset == 64) 
+			mkasm(u, "%s0x" FMT64 "x", (op_f) ? "+" : "", op->lval.uqword);
+
+		mkasm(u, "]");
+		break;
+	}
+			
+	case UD_OP_IMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8: mkasm(u, "0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "word 0x%x:0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "dword 0x%x:0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+
+	case UD_OP_CONST:
+		if (syn_cast) opr_cast(u, op);
+		mkasm(u, "%d", op->lval.udword);
+		break;
+
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to intel syntax 
+ * =============================================================================
+ */
+extern void ud_translate_intel(struct ud* u)
+{
+  /* -- prefixes -- */
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+	mkasm(u, "lock ");
+  if (u->pfx_rep)
+	mkasm(u, "rep ");
+  if (u->pfx_repne)
+	mkasm(u, "repne ");
+  if (u->implicit_addr && u->pfx_seg)
+	mkasm(u, "%s ", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+  /* print the instruction mnemonic */
+  mkasm(u, "%s ", ud_lookup_mnemonic(u->mnemonic));
+
+  /* operand 1 */
+  if (u->operand[0].type != UD_NONE) {
+	gen_operand(u, &u->operand[0], u->c1);
+  }
+  /* operand 2 */
+  if (u->operand[1].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[1], u->c2);
+  }
+
+  /* operand 3 */
+  if (u->operand[2].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[2], u->c3);
+  }
+}
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,61 @@
+/* -----------------------------------------------------------------------------
+ * syn.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+/* -----------------------------------------------------------------------------
+ * Intel Register Table - Order Matters (types.h)!
+ * -----------------------------------------------------------------------------
+ */
+const char* ud_reg_tab[] = 
+{
+  "al",		"cl",		"dl",		"bl",
+  "ah",		"ch",		"dh",		"bh",
+  "spl",	"bpl",		"sil",		"dil",
+  "r8b",	"r9b",		"r10b",		"r11b",
+  "r12b",	"r13b",		"r14b",		"r15b",
+
+  "ax",		"cx",		"dx",		"bx",
+  "sp",		"bp",		"si",		"di",
+  "r8w",	"r9w",		"r10w",		"r11w",
+  "r12w",	"r13W"	,	"r14w",		"r15w",
+	
+  "eax",	"ecx",		"edx",		"ebx",
+  "esp",	"ebp",		"esi",		"edi",
+  "r8d",	"r9d",		"r10d",		"r11d",
+  "r12d",	"r13d",		"r14d",		"r15d",
+	
+  "rax",	"rcx",		"rdx",		"rbx",
+  "rsp",	"rbp",		"rsi",		"rdi",
+  "r8",		"r9",		"r10",		"r11",
+  "r12",	"r13",		"r14",		"r15",
+
+  "es",		"cs",		"ss",		"ds",
+  "fs",		"gs",	
+
+  "cr0",	"cr1",		"cr2",		"cr3",
+  "cr4",	"cr5",		"cr6",		"cr7",
+  "cr8",	"cr9",		"cr10",		"cr11",
+  "cr12",	"cr13",		"cr14",		"cr15",
+	
+  "dr0",	"dr1",		"dr2",		"dr3",
+  "dr4",	"dr5",		"dr6",		"dr7",
+  "dr8",	"dr9",		"dr10",		"dr11",
+  "dr12",	"dr13",		"dr14",		"dr15",
+
+  "mm0",	"mm1",		"mm2",		"mm3",
+  "mm4",	"mm5",		"mm6",		"mm7",
+
+  "st0",	"st1",		"st2",		"st3",
+  "st4",	"st5",		"st6",		"st7", 
+
+  "xmm0",	"xmm1",		"xmm2",		"xmm3",
+  "xmm4",	"xmm5",		"xmm6",		"xmm7",
+  "xmm8",	"xmm9",		"xmm10",	"xmm11",
+  "xmm12",	"xmm13",	"xmm14",	"xmm15",
+
+  "rip"
+};
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/syn.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,27 @@
+/* -----------------------------------------------------------------------------
+ * syn.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_SYN_H
+#define UD_SYN_H
+
+#if 0
+#include <stdio.h>
+#include <stdarg.h>
+#endif
+#include "types.h"
+
+extern const char* ud_reg_tab[];
+
+static void mkasm(struct ud* u, const char* fmt, ...)
+{
+  va_list ap;
+  va_start(ap, fmt);
+  u->insn_fill += vsnprintf((char*) u->insn_buffer + u->insn_fill, 64, fmt, ap);
+  va_end(ap);
+}
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/types.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/types.h	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,186 @@
+/* -----------------------------------------------------------------------------
+ * types.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_TYPES_H
+#define UD_TYPES_H
+
+
+#include "../../include/kdbinc.h"
+
+#define FMT64 "%ll"
+#include "itab.h"
+
+/* -----------------------------------------------------------------------------
+ * All possible "types" of objects in udis86. Order is Important!
+ * -----------------------------------------------------------------------------
+ */
+enum ud_type
+{
+  UD_NONE,
+
+  /* 8 bit GPRs */
+  UD_R_AL,	UD_R_CL,	UD_R_DL,	UD_R_BL,
+  UD_R_AH,	UD_R_CH,	UD_R_DH,	UD_R_BH,
+  UD_R_SPL,	UD_R_BPL,	UD_R_SIL,	UD_R_DIL,
+  UD_R_R8B,	UD_R_R9B,	UD_R_R10B,	UD_R_R11B,
+  UD_R_R12B,	UD_R_R13B,	UD_R_R14B,	UD_R_R15B,
+
+  /* 16 bit GPRs */
+  UD_R_AX,	UD_R_CX,	UD_R_DX,	UD_R_BX,
+  UD_R_SP,	UD_R_BP,	UD_R_SI,	UD_R_DI,
+  UD_R_R8W,	UD_R_R9W,	UD_R_R10W,	UD_R_R11W,
+  UD_R_R12W,	UD_R_R13W,	UD_R_R14W,	UD_R_R15W,
+	
+  /* 32 bit GPRs */
+  UD_R_EAX,	UD_R_ECX,	UD_R_EDX,	UD_R_EBX,
+  UD_R_ESP,	UD_R_EBP,	UD_R_ESI,	UD_R_EDI,
+  UD_R_R8D,	UD_R_R9D,	UD_R_R10D,	UD_R_R11D,
+  UD_R_R12D,	UD_R_R13D,	UD_R_R14D,	UD_R_R15D,
+	
+  /* 64 bit GPRs */
+  UD_R_RAX,	UD_R_RCX,	UD_R_RDX,	UD_R_RBX,
+  UD_R_RSP,	UD_R_RBP,	UD_R_RSI,	UD_R_RDI,
+  UD_R_R8,	UD_R_R9,	UD_R_R10,	UD_R_R11,
+  UD_R_R12,	UD_R_R13,	UD_R_R14,	UD_R_R15,
+
+  /* segment registers */
+  UD_R_ES,	UD_R_CS,	UD_R_SS,	UD_R_DS,
+  UD_R_FS,	UD_R_GS,	
+
+  /* control registers*/
+  UD_R_CR0,	UD_R_CR1,	UD_R_CR2,	UD_R_CR3,
+  UD_R_CR4,	UD_R_CR5,	UD_R_CR6,	UD_R_CR7,
+  UD_R_CR8,	UD_R_CR9,	UD_R_CR10,	UD_R_CR11,
+  UD_R_CR12,	UD_R_CR13,	UD_R_CR14,	UD_R_CR15,
+	
+  /* debug registers */
+  UD_R_DR0,	UD_R_DR1,	UD_R_DR2,	UD_R_DR3,
+  UD_R_DR4,	UD_R_DR5,	UD_R_DR6,	UD_R_DR7,
+  UD_R_DR8,	UD_R_DR9,	UD_R_DR10,	UD_R_DR11,
+  UD_R_DR12,	UD_R_DR13,	UD_R_DR14,	UD_R_DR15,
+
+  /* mmx registers */
+  UD_R_MM0,	UD_R_MM1,	UD_R_MM2,	UD_R_MM3,
+  UD_R_MM4,	UD_R_MM5,	UD_R_MM6,	UD_R_MM7,
+
+  /* x87 registers */
+  UD_R_ST0,	UD_R_ST1,	UD_R_ST2,	UD_R_ST3,
+  UD_R_ST4,	UD_R_ST5,	UD_R_ST6,	UD_R_ST7, 
+
+  /* extended multimedia registers */
+  UD_R_XMM0,	UD_R_XMM1,	UD_R_XMM2,	UD_R_XMM3,
+  UD_R_XMM4,	UD_R_XMM5,	UD_R_XMM6,	UD_R_XMM7,
+  UD_R_XMM8,	UD_R_XMM9,	UD_R_XMM10,	UD_R_XMM11,
+  UD_R_XMM12,	UD_R_XMM13,	UD_R_XMM14,	UD_R_XMM15,
+
+  UD_R_RIP,
+
+  /* Operand Types */
+  UD_OP_REG,	UD_OP_MEM,	UD_OP_PTR,	UD_OP_IMM,	
+  UD_OP_JIMM,	UD_OP_CONST
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud_operand - Disassembled instruction Operand.
+ * -----------------------------------------------------------------------------
+ */
+struct ud_operand 
+{
+  enum ud_type		type;
+  uint8_t		size;
+  union {
+	int8_t		sbyte;
+	uint8_t		ubyte;
+	int16_t		sword;
+	uint16_t	uword;
+	int32_t		sdword;
+	uint32_t	udword;
+	int64_t		sqword;
+	uint64_t	uqword;
+
+	struct {
+		uint16_t seg;
+		uint32_t off;
+	} ptr;
+  } lval;
+
+  enum ud_type		base;
+  enum ud_type		index;
+  uint8_t		offset;
+  uint8_t		scale;	
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud - The udis86 object.
+ * -----------------------------------------------------------------------------
+ */
+struct ud
+{
+  int 			(*inp_hook) (struct ud*);
+  uint8_t		inp_curr;
+  uint8_t		inp_fill;
+  uint8_t		inp_ctr;
+  uint8_t*		inp_buff;
+  uint8_t*		inp_buff_end;
+  uint8_t		inp_end;
+  void			(*translator)(struct ud*);
+  uint64_t		insn_offset;
+  char			insn_hexcode[32];
+  char			insn_buffer[64];
+  unsigned int		insn_fill;
+  uint8_t		dis_mode;
+  uint64_t		pc;
+  uint8_t		vendor;
+  struct map_entry*	mapen;
+  enum ud_mnemonic_code	mnemonic;
+  struct ud_operand	operand[3];
+  uint8_t		error;
+  uint8_t	 	pfx_rex;
+  uint8_t 		pfx_seg;
+  uint8_t 		pfx_opr;
+  uint8_t 		pfx_adr;
+  uint8_t 		pfx_lock;
+  uint8_t 		pfx_rep;
+  uint8_t 		pfx_repe;
+  uint8_t 		pfx_repne;
+  uint8_t 		pfx_insn;
+  uint8_t		default64;
+  uint8_t		opr_mode;
+  uint8_t		adr_mode;
+  uint8_t		br_far;
+  uint8_t		br_near;
+  uint8_t		implicit_addr;
+  uint8_t		c1;
+  uint8_t		c2;
+  uint8_t		c3;
+  uint8_t 		inp_cache[256];
+  uint8_t		inp_sess[64];
+  struct ud_itab_entry * itab_entry;
+};
+
+/* -----------------------------------------------------------------------------
+ * Type-definitions
+ * -----------------------------------------------------------------------------
+ */
+typedef enum ud_type 		ud_type_t;
+typedef enum ud_mnemonic_code	ud_mnemonic_code_t;
+
+typedef struct ud 		ud_t;
+typedef struct ud_operand 	ud_operand_t;
+
+#define UD_SYN_INTEL		ud_translate_intel
+#define UD_SYN_ATT		ud_translate_att
+#define UD_EOI			-1
+#define UD_INP_CACHE_SZ		32
+#define UD_VENDOR_AMD		0
+#define UD_VENDOR_INTEL		1
+
+#define bail_out(ud,error_code) longjmp( (ud)->bailout, error_code )
+#define try_decode(ud) if ( setjmp( (ud)->bailout ) == 0 )
+#define catch_error() else
+
+#endif
diff -r 32034d1914a6 -r e4b01842b71c xen/kdb/x86/udis86-1.7/udis86.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/udis86.c	Fri Jun 08 10:56:24 2012 -0700
@@ -0,0 +1,156 @@
+/* -----------------------------------------------------------------------------
+ * udis86.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#endif
+
+#include "input.h"
+#include "extern.h"
+
+/* =============================================================================
+ * ud_init() - Initializes ud_t object.
+ * =============================================================================
+ */
+extern void 
+ud_init(struct ud* u)
+{
+  memset((void*)u, 0, sizeof(struct ud));
+  ud_set_mode(u, 16);
+  u->mnemonic = UD_Iinvalid;
+  ud_set_pc(u, 0);
+#ifndef __UD_STANDALONE__
+  ud_set_input_file(u, stdin);
+#endif /* __UD_STANDALONE__ */
+}
+
+/* =============================================================================
+ * ud_disassemble() - disassembles one instruction and returns the number of 
+ * bytes disassembled. A zero means end of disassembly.
+ * =============================================================================
+ */
+extern unsigned int
+ud_disassemble(struct ud* u)
+{
+  if (ud_input_end(u))
+	return 0;
+
+ 
+  u->insn_buffer[0] = u->insn_hexcode[0] = 0;
+
+ 
+  if (ud_decode(u) == 0)
+	return 0;
+  if (u->translator)
+	u->translator(u);
+  return ud_insn_len(u);
+}
+
+/* =============================================================================
+ * ud_set_mode() - Set Disassemly Mode.
+ * =============================================================================
+ */
+extern void 
+ud_set_mode(struct ud* u, uint8_t m)
+{
+  switch(m) {
+	case 16:
+	case 32:
+	case 64: u->dis_mode = m ; return;
+	default: u->dis_mode = 16; return;
+  }
+}
+
+/* =============================================================================
+ * ud_set_vendor() - Set vendor.
+ * =============================================================================
+ */
+extern void 
+ud_set_vendor(struct ud* u, unsigned v)
+{
+  switch(v) {
+	case UD_VENDOR_INTEL:
+		u->vendor = v;
+		break;
+	default:
+		u->vendor = UD_VENDOR_AMD;
+  }
+}
+
+/* =============================================================================
+ * ud_set_pc() - Sets code origin. 
+ * =============================================================================
+ */
+extern void 
+ud_set_pc(struct ud* u, uint64_t o)
+{
+  u->pc = o;
+}
+
+/* =============================================================================
+ * ud_set_syntax() - Sets the output syntax.
+ * =============================================================================
+ */
+extern void 
+ud_set_syntax(struct ud* u, void (*t)(struct ud*))
+{
+  u->translator = t;
+}
+
+/* =============================================================================
+ * ud_insn() - returns the disassembled instruction
+ * =============================================================================
+ */
+extern char* 
+ud_insn_asm(struct ud* u) 
+{
+  return u->insn_buffer;
+}
+
+/* =============================================================================
+ * ud_insn_offset() - Returns the offset.
+ * =============================================================================
+ */
+extern uint64_t
+ud_insn_off(struct ud* u) 
+{
+  return u->insn_offset;
+}
+
+
+/* =============================================================================
+ * ud_insn_hex() - Returns hex form of disassembled instruction.
+ * =============================================================================
+ */
+extern char* 
+ud_insn_hex(struct ud* u) 
+{
+  return u->insn_hexcode;
+}
+
+/* =============================================================================
+ * ud_insn_ptr() - Returns code disassembled.
+ * =============================================================================
+ */
+extern uint8_t* 
+ud_insn_ptr(struct ud* u) 
+{
+  return u->inp_sess;
+}
+
+/* =============================================================================
+ * ud_insn_len() - Returns the count of bytes disassembled.
+ * =============================================================================
+ */
+extern unsigned int 
+ud_insn_len(struct ud* u) 
+{
+  return u->inp_ctr;
+}

--MP_/X3qA/jwEscosmMB+TVJPo3b
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MP_/X3qA/jwEscosmMB+TVJPo3b--


From xen-devel-bounces@lists.xen.org Tue Jun 12 12:12:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePxX-0005Pw-BF; Tue, 12 Jun 2012 12:12:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SePxW-0005Pf-38
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:12:30 +0000
Received: from [85.158.143.99:33048] by server-2.bemta-4.messagelabs.com id
	1B/08-17938-D2237DF4; Tue, 12 Jun 2012 12:12:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339503148!32127100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18139 invoked from network); 12 Jun 2012 12:12:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:12:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:12:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePx8-0006Vl-Fa	for xen-devel@lists.xen.org;
	Tue, 12 Jun 2012 12:12:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePx8-0005VU-EH	for
	xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:12:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20439.12822.424318.955833@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:12:06 +0100
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Security vulnerability process - lessons learned
	discussion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the past weeks the Xen.org security team have been involved
with the preparation, predisclosure and publication of Xen Security
Advisories 7, 8 and 9.

During this exercise we found that there were a number of difficulties
with the current security vulnerability process.  These include both
the need for some straightforward procedural improvements, and some
more thorny questions of policy.

We also wish to make the community aware of some of the key decisions
we were faced with during the predisclosure period, and explain what
we as the Xen.org team did and why.

Some members of the predisclosure list, and some community members who
appear to have heard about a problem via some kind of leaks, have also
expressed the view to us that there are elements of the process that
they feel could be improved.

However, many users - particularly those not on the predisclosure list
- will be busy right now upgrading systems to cope with these
vulnerabilities.  We do not expect that community members will want to
divert their resources from front-line security response to
longer-term process improvements, and it is important that everyone
gets a chance to participate properly in policy discussions without
being overly distracted.

We therefore intend to postpone starting this discussion ourselves for
around a week, until the 19th of June.  We would respectfully request
that other community members do likewise.

Starting on the Tuesday 19th of June we expect to have a full and
frank conversation and we look forward to engaging fully with the Xen
community.

The existing established consensus decisionmaking approach of the Xen
project will of course be used to agree any changes to the
vulnerability response process document.

Thanks,
Ian.
(on behalf of the Xen.org security response team)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:12:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SePxX-0005Pw-BF; Tue, 12 Jun 2012 12:12:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SePxW-0005Pf-38
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:12:30 +0000
Received: from [85.158.143.99:33048] by server-2.bemta-4.messagelabs.com id
	1B/08-17938-D2237DF4; Tue, 12 Jun 2012 12:12:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339503148!32127100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18139 invoked from network); 12 Jun 2012 12:12:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="12966718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:12:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 12 Jun 2012 13:12:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SePx8-0006Vl-Fa	for xen-devel@lists.xen.org;
	Tue, 12 Jun 2012 12:12:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SePx8-0005VU-EH	for
	xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:12:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20439.12822.424318.955833@mariner.uk.xensource.com>
Date: Tue, 12 Jun 2012 13:12:06 +0100
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Security vulnerability process - lessons learned
	discussion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the past weeks the Xen.org security team have been involved
with the preparation, predisclosure and publication of Xen Security
Advisories 7, 8 and 9.

During this exercise we found that there were a number of difficulties
with the current security vulnerability process.  These include both
the need for some straightforward procedural improvements, and some
more thorny questions of policy.

We also wish to make the community aware of some of the key decisions
we were faced with during the predisclosure period, and explain what
we as the Xen.org team did and why.

Some members of the predisclosure list, and some community members who
appear to have heard about a problem via some kind of leaks, have also
expressed the view to us that there are elements of the process that
they feel could be improved.

However, many users - particularly those not on the predisclosure list
- will be busy right now upgrading systems to cope with these
vulnerabilities.  We do not expect that community members will want to
divert their resources from front-line security response to
longer-term process improvements, and it is important that everyone
gets a chance to participate properly in policy discussions without
being overly distracted.

We therefore intend to postpone starting this discussion ourselves for
around a week, until the 19th of June.  We would respectfully request
that other community members do likewise.

Starting on the Tuesday 19th of June we expect to have a full and
frank conversation and we look forward to engaging fully with the Xen
community.

The existing established consensus decisionmaking approach of the Xen
project will of course be used to agree any changes to the
vulnerability response process document.

Thanks,
Ian.
(on behalf of the Xen.org security response team)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:15:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeQ09-0005xU-45; Tue, 12 Jun 2012 12:15:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1SeQ08-0005xI-97
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:15:12 +0000
Received: from [85.158.139.83:3766] by server-9.bemta-5.messagelabs.com id
	2A/98-29678-FC237DF4; Tue, 12 Jun 2012 12:15:11 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339503310!25980493!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6178 invoked from network); 12 Jun 2012 12:15:10 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jun 2012 12:15:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=nYnflzHkPODYJ/cvFDyyBY9TeAY4059B+hPwdaY9K7k=; 
	b=hhaoWDfgOtftvAUK5fVUXm8REykHRhxGZX4qkBGcqXMEe2NzhVhj7YmWyZjmKec2NThBjwrTe5ksSRIRCaFB/1Z0aA2p77kENoCieCaHhAZ+qLw5P9Z3DoFVt6jewqI8;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1SeQ06-0008KS-7B
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:15:10 +0000
Date: Tue, 12 Jun 2012 12:15:10 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xen.org
Message-ID: <20120612121510.GQ11695@bitfolk.com>
References: <20439.12248.291249.667993@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20439.12248.291249.667993@mariner.uk.xensource.com>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Tue,
	12 Jun 2012 12:15:10 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd2.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] Xen Security Advisory 7 (CVE-2012-0217) - PV
 privilege escalation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

A quick question with regard to XSA-7:

On Tue, Jun 12, 2012 at 01:02:32PM +0100, Xen.org security team wrote:
> MITIGATION
> ==========
> 
> This issue can be mitigated by running HVM (fully-virtualised)
> or 32 bit PV guests only.

Assuming 64-bit hypervisor and dom0, with PV guests booted using
pygrub, is there any way to restrict guests to 32-bit only?

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:15:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeQ09-0005xU-45; Tue, 12 Jun 2012 12:15:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1SeQ08-0005xI-97
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:15:12 +0000
Received: from [85.158.139.83:3766] by server-9.bemta-5.messagelabs.com id
	2A/98-29678-FC237DF4; Tue, 12 Jun 2012 12:15:11 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339503310!25980493!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6178 invoked from network); 12 Jun 2012 12:15:10 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jun 2012 12:15:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=nYnflzHkPODYJ/cvFDyyBY9TeAY4059B+hPwdaY9K7k=; 
	b=hhaoWDfgOtftvAUK5fVUXm8REykHRhxGZX4qkBGcqXMEe2NzhVhj7YmWyZjmKec2NThBjwrTe5ksSRIRCaFB/1Z0aA2p77kENoCieCaHhAZ+qLw5P9Z3DoFVt6jewqI8;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1SeQ06-0008KS-7B
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:15:10 +0000
Date: Tue, 12 Jun 2012 12:15:10 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xen.org
Message-ID: <20120612121510.GQ11695@bitfolk.com>
References: <20439.12248.291249.667993@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20439.12248.291249.667993@mariner.uk.xensource.com>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Tue,
	12 Jun 2012 12:15:10 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd2.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] Xen Security Advisory 7 (CVE-2012-0217) - PV
 privilege escalation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

A quick question with regard to XSA-7:

On Tue, Jun 12, 2012 at 01:02:32PM +0100, Xen.org security team wrote:
> MITIGATION
> ==========
> 
> This issue can be mitigated by running HVM (fully-virtualised)
> or 32 bit PV guests only.

Assuming 64-bit hypervisor and dom0, with PV guests booted using
pygrub, is there any way to restrict guests to 32-bit only?

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SeQR2-00078Y-FO; Tue, 12 Jun 2012 12:43:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SeQR0-00078T-A1
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:42:58 +0000
Received: from [85.158.143.35:55293] by server-1.bemta-4.messagelabs.com id
	6C/69-24392-15937DF4; Tue, 12 Jun 2012 12:42:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339504968!10386527!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgzMTY5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15934 invoked from network); 12 Jun 2012 12:42:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jun 2012 12:42:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5CCgeXl015348
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Jun 2012 12:42:41 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
	q5CCgdbc020227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Jun 2012 12:42:39 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
	q5CCgcbS031801; Tue, 12 Jun 2012 07:42:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Jun 2012 05:42:38 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 001A14029A; Tue, 12 Jun 2012 08:35:24 -0400 (EDT)
Date: Tue, 12 Jun 2012 08:35:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@kernel.dk, linux-kernel@vger.kernel.org, jaxboe@fusionio.com
Message-ID: <20120612123524.GA559@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: xen-devel@lists.xensource.com, wdauchy@gmail.com, jbeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.5 for 3.5-rc2..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jens,

Please pull:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.5

it has two critical fixes to deal with 32/64 guest/host combinations
when sending DISCARD commands. They weren't properly sent resulting
in the guest crashing (https://bugzilla.redhat.com/show_bug.cgi?id=824641)
The fix is in the backend (blkback) and the frontend has some extra
WARN_ON added to diagnose similar issues like this in the future.

Or if you prefer - I can stick those two patches in my tree and
send them to Linus in my git pull this Friday with your Ack-ed by tag.

Thanks!

Konrad Rzeszutek Wilk (2):
      xen/blkback: Copy id field when doing BLKIF_DISCARD.
      xen/blkfront: Add WARN to deal with misbehaving backends.

 drivers/block/xen-blkback/common.h |    2 +
 drivers/block/xen-blkfront.c       |   58 ++++++++++++++++++++++++++++-------
 2 files changed, 48 insertions(+), 12 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SeQR2-00078Y-FO; Tue, 12 Jun 2012 12:43:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SeQR0-00078T-A1
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:42:58 +0000
Received: from [85.158.143.35:55293] by server-1.bemta-4.messagelabs.com id
	6C/69-24392-15937DF4; Tue, 12 Jun 2012 12:42:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1339504968!10386527!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTgzMTY5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15934 invoked from network); 12 Jun 2012 12:42:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jun 2012 12:42:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5CCgeXl015348
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Jun 2012 12:42:41 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
	q5CCgdbc020227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Jun 2012 12:42:39 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
	q5CCgcbS031801; Tue, 12 Jun 2012 07:42:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Jun 2012 05:42:38 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 001A14029A; Tue, 12 Jun 2012 08:35:24 -0400 (EDT)
Date: Tue, 12 Jun 2012 08:35:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@kernel.dk, linux-kernel@vger.kernel.org, jaxboe@fusionio.com
Message-ID: <20120612123524.GA559@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: xen-devel@lists.xensource.com, wdauchy@gmail.com, jbeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.5 for 3.5-rc2..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jens,

Please pull:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.5

it has two critical fixes to deal with 32/64 guest/host combinations
when sending DISCARD commands. They weren't properly sent resulting
in the guest crashing (https://bugzilla.redhat.com/show_bug.cgi?id=824641)
The fix is in the backend (blkback) and the frontend has some extra
WARN_ON added to diagnose similar issues like this in the future.

Or if you prefer - I can stick those two patches in my tree and
send them to Linus in my git pull this Friday with your Ack-ed by tag.

Thanks!

Konrad Rzeszutek Wilk (2):
      xen/blkback: Copy id field when doing BLKIF_DISCARD.
      xen/blkfront: Add WARN to deal with misbehaving backends.

 drivers/block/xen-blkback/common.h |    2 +
 drivers/block/xen-blkfront.c       |   58 ++++++++++++++++++++++++++++-------
 2 files changed, 48 insertions(+), 12 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:48:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SeQVd-0007JT-5d; Tue, 12 Jun 2012 12:47:45 +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 1SeQVb-0007JN-IS
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:47:43 +0000
Received: from [85.158.143.99:18045] by server-1.bemta-4.messagelabs.com id
	33/D1-24392-E6A37DF4; Tue, 12 Jun 2012 12:47:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339505261!22813900!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4NTM0Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29861 invoked from network); 12 Jun 2012 12:47:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 12:47:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5CClTbW013405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Jun 2012 12:47:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5CClSCJ012598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Jun 2012 12:47:29 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
	q5CClSwZ024824; Tue, 12 Jun 2012 07:47:28 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Jun 2012 05:47:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 39B8E4029A; Tue, 12 Jun 2012 08:40:15 -0400 (EDT)
Date: Tue, 12 Jun 2012 08:40:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120612124015.GB559@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: schedule a workqueue to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 12, 2012 at 07:51:03AM +0000, Liu, Jinsong wrote:
> >From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Tue, 12 Jun 2012 23:11:16 +0800
> Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic context
> 
> copy_to_user might sleep and print a stack trace if it is executed
> in an atomic spinlock context.
> 
> This patch schedule a workqueue for IRQ handler to poll the data,
> and use mutex instead of spinlock, so copy_to_user sleep in atomic
> context would not occur.

Ah much better. Usually one also includes the report of what the
stack trace was. So I've added that in.

> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  drivers/xen/mcelog.c |   18 +++++++++++-------
>  1 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> index 72e87d2..804aa3c 100644
> --- a/drivers/xen/mcelog.c
> +++ b/drivers/xen/mcelog.c
> @@ -55,7 +55,7 @@ static struct mc_info g_mi;
>  static struct mcinfo_logical_cpu *g_physinfo;
>  static uint32_t ncpus;
>  
> -static DEFINE_SPINLOCK(mcelog_lock);
> +static DEFINE_MUTEX(mcelog_lock);
>  
>  static struct xen_mce_log xen_mcelog = {
>  	.signature	= XEN_MCE_LOG_SIGNATURE,
> @@ -106,7 +106,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  	unsigned num;
>  	int i, err;
>  
> -	spin_lock(&mcelog_lock);
> +	mutex_lock(&mcelog_lock);
>  
>  	num = xen_mcelog.next;
>  
> @@ -130,7 +130,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  		err = -EFAULT;
>  
>  out:
> -	spin_unlock(&mcelog_lock);
> +	mutex_unlock(&mcelog_lock);
>  
>  	return err ? err : buf - ubuf;
>  }
> @@ -310,12 +310,11 @@ static int mc_queue_handle(uint32_t flags)
>  }
>  
>  /* virq handler for machine check error info*/
> -static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
> +static void xen_mce_work_fn(struct work_struct *work)
>  {
>  	int err;
> -	unsigned long tmp;
>  
> -	spin_lock_irqsave(&mcelog_lock, tmp);
> +	mutex_lock(&mcelog_lock);
>  
>  	/* urgent mc_info */
>  	err = mc_queue_handle(XEN_MC_URGENT);
> @@ -330,8 +329,13 @@ static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
>  		pr_err(XEN_MCELOG
>  		       "Failed to handle nonurgent mc_info queue.\n");
>  
> -	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +	mutex_unlock(&mcelog_lock);
> +}
> +static DECLARE_WORK(xen_mce_work, xen_mce_work_fn);
>  
> +static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_mce_work);
>  	return IRQ_HANDLED;
>  }
>  
> -- 
> 1.7.1


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:48:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SeQVd-0007JT-5d; Tue, 12 Jun 2012 12:47:45 +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 1SeQVb-0007JN-IS
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 12:47:43 +0000
Received: from [85.158.143.99:18045] by server-1.bemta-4.messagelabs.com id
	33/D1-24392-E6A37DF4; Tue, 12 Jun 2012 12:47:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339505261!22813900!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4NTM0Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29861 invoked from network); 12 Jun 2012 12:47:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 12:47:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5CClTbW013405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Jun 2012 12:47:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5CClSCJ012598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Jun 2012 12:47:29 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
	q5CClSwZ024824; Tue, 12 Jun 2012 07:47:28 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Jun 2012 05:47:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 39B8E4029A; Tue, 12 Jun 2012 08:40:15 -0400 (EDT)
Date: Tue, 12 Jun 2012 08:40:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120612124015.GB559@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	Borislav Petkov <bp@amd64.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: schedule a workqueue to avoid
 sleep in atomic context
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 12, 2012 at 07:51:03AM +0000, Liu, Jinsong wrote:
> >From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Tue, 12 Jun 2012 23:11:16 +0800
> Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic context
> 
> copy_to_user might sleep and print a stack trace if it is executed
> in an atomic spinlock context.
> 
> This patch schedule a workqueue for IRQ handler to poll the data,
> and use mutex instead of spinlock, so copy_to_user sleep in atomic
> context would not occur.

Ah much better. Usually one also includes the report of what the
stack trace was. So I've added that in.

> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  drivers/xen/mcelog.c |   18 +++++++++++-------
>  1 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
> index 72e87d2..804aa3c 100644
> --- a/drivers/xen/mcelog.c
> +++ b/drivers/xen/mcelog.c
> @@ -55,7 +55,7 @@ static struct mc_info g_mi;
>  static struct mcinfo_logical_cpu *g_physinfo;
>  static uint32_t ncpus;
>  
> -static DEFINE_SPINLOCK(mcelog_lock);
> +static DEFINE_MUTEX(mcelog_lock);
>  
>  static struct xen_mce_log xen_mcelog = {
>  	.signature	= XEN_MCE_LOG_SIGNATURE,
> @@ -106,7 +106,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  	unsigned num;
>  	int i, err;
>  
> -	spin_lock(&mcelog_lock);
> +	mutex_lock(&mcelog_lock);
>  
>  	num = xen_mcelog.next;
>  
> @@ -130,7 +130,7 @@ static ssize_t xen_mce_chrdev_read(struct file *filp, char __user *ubuf,
>  		err = -EFAULT;
>  
>  out:
> -	spin_unlock(&mcelog_lock);
> +	mutex_unlock(&mcelog_lock);
>  
>  	return err ? err : buf - ubuf;
>  }
> @@ -310,12 +310,11 @@ static int mc_queue_handle(uint32_t flags)
>  }
>  
>  /* virq handler for machine check error info*/
> -static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
> +static void xen_mce_work_fn(struct work_struct *work)
>  {
>  	int err;
> -	unsigned long tmp;
>  
> -	spin_lock_irqsave(&mcelog_lock, tmp);
> +	mutex_lock(&mcelog_lock);
>  
>  	/* urgent mc_info */
>  	err = mc_queue_handle(XEN_MC_URGENT);
> @@ -330,8 +329,13 @@ static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
>  		pr_err(XEN_MCELOG
>  		       "Failed to handle nonurgent mc_info queue.\n");
>  
> -	spin_unlock_irqrestore(&mcelog_lock, tmp);
> +	mutex_unlock(&mcelog_lock);
> +}
> +static DECLARE_WORK(xen_mce_work, xen_mce_work_fn);
>  
> +static irqreturn_t xen_mce_interrupt(int irq, void *dev_id)
> +{
> +	schedule_work(&xen_mce_work);
>  	return IRQ_HANDLED;
>  }
>  
> -- 
> 1.7.1


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:48:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SeQWU-0007Mv-J6; Tue, 12 Jun 2012 12:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeQWT-0007Mi-Fj
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:48:37 +0000
Received: from [85.158.143.99:23988] by server-2.bemta-4.messagelabs.com id
	C3/FA-17938-4AA37DF4; Tue, 12 Jun 2012 12:48:36 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339505315!27182887!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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 12 Jun 2012 12:48:36 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 12:48:36 -0000
Received: (qmail 3175 invoked from network); 12 Jun 2012 15:48:31 +0300
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.3.14894, Dats: 204434,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Enabled,
	Score: 0(0)], APM: [Enabled, Score: 500, Flags:
	NN_S_TWO_WORDS_LOWERCASE_NMD; NN_LEGIT_MAILING_LIST_TO], SGN:
	[Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled,
	Hits: none, MD5: 38d2d3c6498bb87415a4779b7e9719e0.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v0.0; ], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.42574
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com;
	b=oqc2oaquXploGmohkRFMICmjBP/ntHbrdrY6E8Ci/XrEgfX56Vzf+0lPE5OqBMtCPtl1oMnE1QeMgIytsRyeOxg05JUJZcypCsgd1hOvHPr4f/zgxjHS6q+SSfjZv1vY+kmH/NN3L8GmhAEWt//J85YCKO65fKZc/g7bXVjkCWQ=
	; 
Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115)
	by mail.bitdefender.com with SMTP; 12 Jun 2012 15:48:30 +0300
Date: Tue, 12 Jun 2012 15:48:28 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
Organization: Home
Mime-Version: 1.0
Subject: [Xen-devel] memory introspection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SGksCgpJIHdvdWxkIGxpa2UgdG8gcmVvcGVuIGEgZGlzY3Vzc2lvbiB3aGljaCB0b29rIHBsYWNl
IHNvbWUgdGltZSBhZ28KaGVyZToKCmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwv
eGVuLWludHJvc3BlY3QvMjAwOC0xMS9tc2cwMDAwMS5odG1sCgpidXQgd2l0aCBhIGZvY3VzIG9u
IGluLWh2IGludHJvc3BlY3Rpb24sIHRoYXQgaXM6IHRoZSBlbmdpbmUgZG9pbmcgdGhlCmludHJv
c3BlY3Rpb24gbGl2ZXMgaW4gdGhlIHNhbWUgcmluZyAvIG1lbW9yeS1zcGFjZSBhcyB0aGUgaHlw
ZXJ2aXNvcgppdHNlbGYuCgpUaGUgdGVjaG5vbG9neSBJIHBsYW4gdG8gdXNlIGlzIHByb3ByaWV0
YXJ5IGFuZCB3aXRoIGFuIGFscmVhZHkgZGVmaW5lZAppbnRlcmZhY2UsIHNvIEknbSBsb29raW5n
IGF0IGFkZGluZyBzb21lIGdsdWUgY29kZSB0byBYZW4gaW4gb3JkZXIgdG8KbWFrZSB0aGUgdHdv
IHVuZGVyc3RhbmQgZWFjaCBvdGhlci4gVGhlIHJlYXNvbiB0aGUgZW5naW5lIG5lZWRzIHRvCnJl
c2lkZSBpbiB0aGUgc2FtZSBzcGFjZSBhcyB0aGUgaHYgaXMgdGhhdCBpdCB3YW50cyB0byBjbG9z
ZWx5IG1vbml0b3IKY2VydGFpbiBtZW1vcnkgYW5kIHJlZ2lzdGVyIGNoYW5nZXMgaW4gb3JkZXIg
dG8gaWRlbnRpZnkgcG9zc2libGUKcm9vdGtpdHMsIGNoYW5nZXMgd2hpY2ggKGRlcGVuZGluZyBv
biB0aGUgT1MpIGNhbiBvY2N1ciBpbiBhIGxlZ2l0aW1hdGUKd2F5IG1hbnkgbWFueSB0aW1lcyBw
ZXIgc2Vjb25kLgoKQmVmb3JlIEkgZ28gaW50byBtb3JlIGRldGFpbCBJIHdvdWxkIGxpa2UgdG8g
a25vdyBpZiwgZnJvbSBhIGxlZ2FsCnBvaW50IG9mIHZpZXcsIHRoZXJlJ3MgYW55IHdheSB0byBo
YXZlIGEgY2xvc2VkIHNvdXJjZSBjb21wb25lbnQgdXNpbmcKdGhlIHByaXZhdGUgWGVuIEFQSSAo
dGhlIG9uZXMgaGFuZGxpbmcgZXhjZXB0aW9ucywgcmVnaXN0ZXIgY2hhbmdlcyBldGMuCmZvciBk
b21VLXMpLCBvciBpZiBhIGdsdWUgY29kZSBsaWNlbnNlZCBhcyBMR1BMIHdvdWxkIGJlIGVub3Vn
aCB0bwpicmlkZ2UgdGhlIEdQTC1wcm9wcmlldGFyeSBnYXAuCgpJJ2QgYmUgaGFwcHkgdG8gaGVs
cCBpZiB0aGUgZ2x1ZSBjb2RlIHdlcmUgdG8gZXZvbHZlIGludG8gYW4gQVBJIGluIGl0cwpvd24g
cmlnaHQgd2hpY2ggb3RoZXIgY29tcGFuaWVzIGNhbiB1c2UuCgpUaGFuayB5b3UsCgotLSAKTWlo
YWkgRG9uyJt1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 12:48:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 12: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 1SeQWU-0007Mv-J6; Tue, 12 Jun 2012 12:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeQWT-0007Mi-Fj
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:48:37 +0000
Received: from [85.158.143.99:23988] by server-2.bemta-4.messagelabs.com id
	C3/FA-17938-4AA37DF4; Tue, 12 Jun 2012 12:48:36 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339505315!27182887!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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 12 Jun 2012 12:48:36 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 12:48:36 -0000
Received: (qmail 3175 invoked from network); 12 Jun 2012 15:48:31 +0300
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.3.14894, Dats: 204434,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Enabled,
	Score: 0(0)], APM: [Enabled, Score: 500, Flags:
	NN_S_TWO_WORDS_LOWERCASE_NMD; NN_LEGIT_MAILING_LIST_TO], SGN:
	[Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled,
	Hits: none, MD5: 38d2d3c6498bb87415a4779b7e9719e0.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v0.0; ], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.42574
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com;
	b=oqc2oaquXploGmohkRFMICmjBP/ntHbrdrY6E8Ci/XrEgfX56Vzf+0lPE5OqBMtCPtl1oMnE1QeMgIytsRyeOxg05JUJZcypCsgd1hOvHPr4f/zgxjHS6q+SSfjZv1vY+kmH/NN3L8GmhAEWt//J85YCKO65fKZc/g7bXVjkCWQ=
	; 
Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115)
	by mail.bitdefender.com with SMTP; 12 Jun 2012 15:48:30 +0300
Date: Tue, 12 Jun 2012 15:48:28 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
Organization: Home
Mime-Version: 1.0
Subject: [Xen-devel] memory introspection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SGksCgpJIHdvdWxkIGxpa2UgdG8gcmVvcGVuIGEgZGlzY3Vzc2lvbiB3aGljaCB0b29rIHBsYWNl
IHNvbWUgdGltZSBhZ28KaGVyZToKCmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwv
eGVuLWludHJvc3BlY3QvMjAwOC0xMS9tc2cwMDAwMS5odG1sCgpidXQgd2l0aCBhIGZvY3VzIG9u
IGluLWh2IGludHJvc3BlY3Rpb24sIHRoYXQgaXM6IHRoZSBlbmdpbmUgZG9pbmcgdGhlCmludHJv
c3BlY3Rpb24gbGl2ZXMgaW4gdGhlIHNhbWUgcmluZyAvIG1lbW9yeS1zcGFjZSBhcyB0aGUgaHlw
ZXJ2aXNvcgppdHNlbGYuCgpUaGUgdGVjaG5vbG9neSBJIHBsYW4gdG8gdXNlIGlzIHByb3ByaWV0
YXJ5IGFuZCB3aXRoIGFuIGFscmVhZHkgZGVmaW5lZAppbnRlcmZhY2UsIHNvIEknbSBsb29raW5n
IGF0IGFkZGluZyBzb21lIGdsdWUgY29kZSB0byBYZW4gaW4gb3JkZXIgdG8KbWFrZSB0aGUgdHdv
IHVuZGVyc3RhbmQgZWFjaCBvdGhlci4gVGhlIHJlYXNvbiB0aGUgZW5naW5lIG5lZWRzIHRvCnJl
c2lkZSBpbiB0aGUgc2FtZSBzcGFjZSBhcyB0aGUgaHYgaXMgdGhhdCBpdCB3YW50cyB0byBjbG9z
ZWx5IG1vbml0b3IKY2VydGFpbiBtZW1vcnkgYW5kIHJlZ2lzdGVyIGNoYW5nZXMgaW4gb3JkZXIg
dG8gaWRlbnRpZnkgcG9zc2libGUKcm9vdGtpdHMsIGNoYW5nZXMgd2hpY2ggKGRlcGVuZGluZyBv
biB0aGUgT1MpIGNhbiBvY2N1ciBpbiBhIGxlZ2l0aW1hdGUKd2F5IG1hbnkgbWFueSB0aW1lcyBw
ZXIgc2Vjb25kLgoKQmVmb3JlIEkgZ28gaW50byBtb3JlIGRldGFpbCBJIHdvdWxkIGxpa2UgdG8g
a25vdyBpZiwgZnJvbSBhIGxlZ2FsCnBvaW50IG9mIHZpZXcsIHRoZXJlJ3MgYW55IHdheSB0byBo
YXZlIGEgY2xvc2VkIHNvdXJjZSBjb21wb25lbnQgdXNpbmcKdGhlIHByaXZhdGUgWGVuIEFQSSAo
dGhlIG9uZXMgaGFuZGxpbmcgZXhjZXB0aW9ucywgcmVnaXN0ZXIgY2hhbmdlcyBldGMuCmZvciBk
b21VLXMpLCBvciBpZiBhIGdsdWUgY29kZSBsaWNlbnNlZCBhcyBMR1BMIHdvdWxkIGJlIGVub3Vn
aCB0bwpicmlkZ2UgdGhlIEdQTC1wcm9wcmlldGFyeSBnYXAuCgpJJ2QgYmUgaGFwcHkgdG8gaGVs
cCBpZiB0aGUgZ2x1ZSBjb2RlIHdlcmUgdG8gZXZvbHZlIGludG8gYW4gQVBJIGluIGl0cwpvd24g
cmlnaHQgd2hpY2ggb3RoZXIgY29tcGFuaWVzIGNhbiB1c2UuCgpUaGFuayB5b3UsCgotLSAKTWlo
YWkgRG9uyJt1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 13:01:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 13:01: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 1SeQiN-0007eM-SN; Tue, 12 Jun 2012 13:00: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 1SeQiM-0007eH-Dv
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:00:54 +0000
Received: from [85.158.143.35:18511] by server-1.bemta-4.messagelabs.com id
	53/32-24392-58D37DF4; Tue, 12 Jun 2012 13:00:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339506048!5479591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31497 invoked from network); 12 Jun 2012 13:00:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 13:00:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12967928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 13:00:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 14:00:47 +0100
Message-ID: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 12 Jun 2012 14:00:46 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

QSBiaXQgbGF0ZSB0aGlzIHdlZWssIGR1ZSB0byBteSBiZWluZyBvbiB2YWNhdGlvbi4gSSdtIG9u
IHZhY2F0aW9uCm5leHQgdHdvIE1vbmRheSBhcyB3ZWxsIHNvIGl0IHdpbGwgYmUgbGF0ZSB0aGVu
IHRvby4KClBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hp
dmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhlIHRpbWUgbGluZSBp
cyBhcyBmb2xsb3dzOgoKMTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoy
IEFwcmlsICAgICAgICAgLS0gRmVhdHVyZSBGcmVlemUKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJdCdzIFJlYWR5IC0t
IEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCBy
ZWxlYXNlCgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVyIHRoZSByZWxlYXNlIHBs
YW4gYSBzdHJvbmcgY2FzZSB3aWxsCm5vdyBoYXZlIHRvIGJlIG1hZGUgYXMgdG8gd2h5IG5ldyBp
dGVtcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3QsCmVzcGVjaWFsbHkgYXMgYSBibG9ja2Vy
LCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpJZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBi
dWdzIHdoaWNoIG11c3Qvc2hvdWxkIGJlIGZpeGVkIGZvciA0LjIgdGhlbgpwbGVhc2UgcmVwbHkg
dG8gdGhpcyB0aHJlYWQgKG90aGVyd2lzZSBJIG1heSBub3QgcmVtZW1iZXIgdG8gcGljayB0aGVt
CnVwIG5leHQgd2VlaykKCk90aGVyIHRoYW4gdGhhdCBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRl
ciB0aGUgZnJlZXplIHRvIGJlIGluIGZ1bGwKZWZmZWN0IGFuZCB0aGUgYmFyIHRvIGVudHJ5IHRv
IDQuMiB0byBiZSB2ZXJ5IGhpZ2guCgpoeXBlcnZpc29yLCBibG9ja2VyczoKCiAgICAqIE5vbmUK
IAp0b29scywgYmxvY2tlcnM6CgogICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxp
a2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKICAgICAgd2hpY2ggZG93bnN0cmVhbSdzIGNh
biBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgogICAgICB0aGlzIGFy
ZToKCiAgICAgICAgKiBMSUJYTF9OSUNfVFlQRSBlbnVtIG5hbWVzIGFyZSBjb25mdXNpbmcuCgog
ICAgICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKCiAgICAgICAg
ICAgICogbGlieGxfZG9tYWluX3N1c3BlbmQuIE1vdmUgeGNfZG9tYWluX3NhdmUvcmVzdG9yZSBp
bnRvIGEKICAgICAgICAgICAgICBzZXBhcmF0ZSBwcm9jZXNzIChJYW5KLCBwYXRjaGVzIHBvc3Rl
ZCkuCgogICAgICAgICAgICAqIGxpYnhsX2RldmljZV97ZGlzayxuaWMsdmtiLGFkZCxwY2l9X2Fk
ZCAoYW5kCiAgICAgICAgICAgICAgcmVtb3ZlKS4gKFJvZ2VyLCBwYXRjaGVzIHBvc3RlZCBmb3Ig
ZGlzayAmIG5pYywgdmtiCiAgICAgICAgICAgICAgdHJpdmlhbCwgbm90IGxvb2tlZCBhdCBwY2kg
eWV0KQoKICAgICAgICAqIHVzZSBsaWJ4bF9jcHVtYXAgZm9yIGJfaW5mby5hdmFpbF9jcHVzIGlu
c3RlYWQgb2YgYW4gaW50LAogICAgICAgICAgdGhpcyJhbGxvd3Mgc2V0dGluZyBtb3JlIHRoYW4g
MzEgQ1BVUyAoWWFuZyBaIFpoYW5nLCBwYXRjaGVzCiAgICAgICAgICBwb3N0ZWQpCgogICAgICAg
ICogdXNlIGFuIGVudW0gZm9yIFZHQSBpbnRlcmZhY2UgdHlwZSAoZS5nLiBDaXJydXMsCiAgICAg
ICAgICBTdGRWR0EpLiBBbGxvd3MgZm9yIFFYTCBzdXBwb3J0IChpbiA0LjMpLiAoWmhvdSBQZW5n
LAogICAgICAgICAgcGF0Y2hlcyBwb3N0ZWQpCgogICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGgg
eG06CgogICAgICAgICogW0JVR10gY2Fubm90IGNyZWF0ZSBhbiBlbXB0eSBDRC1ST00gZHJpdmUg
b24gSFZNIGd1ZXN0LAogICAgICAgICAgcmVwb3J0ZWQgYnkgRmFiaW8gRmFudG9uaSBpbiA8NEY5
NjcyREQuMjA4MDkwMkB0aXNjYWxpLml0PgoKICAgICAgICAqIGRvZXMgbm90IGF1dG9tYXRpY2Fs
bHkgdHJ5IHRvIHNlbGVjdCBhIChzZXQgb2YpIG5vZGUocykgb24KICAgICAgICAgIHdoaWNoIHRv
IGNyZWF0ZSBhIFZNIGFuZCBwaW4gaXRzIHZjcHVzIHRoZXJlLiAoRGFyaW8KICAgICAgICAgIEZh
Z2dpb2xpLCBwYXRjaGVzIHJlcG9zdGVkLCB1bmRlciByZXZpZXcpCgogICAgKiBNb3JlIGZvcm1h
bGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgogICAgICB0
cmVlLiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQgLXJjMSB0
bwogICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwuCgogICAgKiBjYWxsaW5nIGhvdHBsdWcg
c2NyaXB0cyBmcm9tIHhsIChMaW51eCBhbmQgTmV0QlNEKSAoUm9nZXIgUGF1CiAgICAgIE1vbm7D
qSwgcGF0Y2hlcyBwb3N0ZWQpCgogICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dz
IG9uIGZyb20gaG90cGx1ZyBzY3JpcHQgKFJvZ2VyCiAgICAgIFBhdSBNb25uw6ksICJqdXN0IGJl
IGEgbWF0dGVyIG9mIHJlbW92aW5nIGFuICJpZiIiKQoKICAgICogQWRqdXN0bWVudHMgbmVlZGVk
IGZvciBxZGlzayBiYWNrZW5kIHRvIHdvcmsgb24gbm9uLXB2b3BzIExpbnV4LgogICAgICAicWVt
dS94ZW5kaXNrOiBzZXQgbWF4aW11bSBudW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4g
QmV1bGljaCkKCiAgICAqIENvbmZpcm0gdGhhdCBtaWdyYXRpb24gZnJvbSBYZW4gNC4xIC0+IDQu
MiB3b3Jrcy4uLgoKICAgICogW0JVR10gQnVpbGQgZmFpbHVyZSBkdWUgdG8gZ2NjIC1Xc3dpdGNo
IG9uIHNvbWUgZGlzdHJvcwogICAgICB2cy4gTElCWExfRE9NQUlOX1RZUEUuIChEYXJpbyBGYWdn
aW9saSwgRE9ORSkKCmh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKCiAgICAqIFBvRCBwZXJmb3Jt
YW5jZSBpbXByb3ZlbWVudHMgKEdlb3JnZSBEdW5sYXAsIHBhdGNoZXMgcG9zdGVkKQoKdG9vbHMs
IG5pY2UgdG8gaGF2ZToKCiAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAg
KiBBY2NlcHQgInhsIGNyIC9kZXYvbnVsbCBwYXJhbT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29u
ZmlnCiAgICAgICAgICBvbiB0aGUgY29tbWFuZCBsaW5lIChXLiBNaWNoYWVsIFBldHVsbG8sIHBh
dGNoIHBvc3RlZCkKCiAgICAqIGxpYnhsOiBBZGQgQVBJIHRvIHJldHJpZXZlIGRvbWFpbiBjb25z
b2xlIHR0eSAoQmFtdm9yIEppYW4KICAgICAgWmhhbmcsIERPTkUpCgogICAgKiBsaWJ4bCBzdGFi
bGUgQVBJCgogICAgICAgICogbGlieGxfd2FpdF9mb3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9m
b3JfbWVtb3J5X3RhcmdldC4KICAgICAgICAgIEludGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwg
cmVsYXRlZCB0bwogICAgICAgICAgbG9ja2luZy9zZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNy
ZWF0ZS4gSWFuSiB0byBhZGQgbm90ZQogICAgICAgICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVp
bmcgc3Vic3RhbmRhcmQgYnV0IG90aGVyd2lzZSBkZWZlcgogICAgICAgICAgdG8gNC4zLgoKICAg
ICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAg
ICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQogICAgICAgICAgICAg
IGRpc2tfe2FkZCxyZW1vdmV9IGRvbmUuIFRoaXMgaXMgYmFzaWNhbGx5IGEgaGVscGVyCiAgICAg
ICAgICAgICAgZnVuY3Rpb24gYW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRl
ZCBpbgogICAgICAgICAgICAgIHRlcm1zIG9mIHRoZSBsaWJ4bF9kaXNrXyogaW50ZXJmYWNlcy4g
SWYgdGhpcyBpcyBub3QKICAgICAgICAgICAgICBkb25lIGluIHRpbWUgd2Ugc2hvdWxkIGRvY3Vt
ZW50IGFzIGEgc3Vic3RhbmRhcmQKICAgICAgICAgICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3Vi
amVjdCB0byBjaGFuZ2UgcG9zdCA0LjIuCgogICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBw
YXRjaCBmb3IgcWVtdS11cHN0cmVhbQogICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0Ogog
ICAgICBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1
L21zZzAwMjUwLmh0bWwKICAgICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lm
eWluZyB2aWRlb21lbSBzaXplIGZvciB0aGUKICAgICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2Eu
ICAoYnV0IHRoaXMgd29ya3Mgd2l0aAogICAgICBxZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNp
IEvDpHJra8OkaW5lbikKCiAgICAqIHFlbXUtdXBzdHJlYW0gZm9yIE5ldEJTRCAoUm9nZXIpCgog
ICAgKiBbQlVHXSBsb25nIHN0b3AgZHVyaW5nIHRoZSBndWVzdCBib290IHByb2Nlc3Mgd2l0aCBx
Y293IGltYWdlLAogICAgICByZXBvcnRlZCBieSBJbnRlbDogaHR0cDovL2J1Z3ppbGxhLnhlbi5v
cmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjEKCiAgICAqIFtCVUddIHZjcHUtc2V0IGRv
ZXNuJ3QgdGFrZSBlZmZlY3Qgb24gZ3Vlc3QsIHJlcG9ydGVkIGJ5IEludGVsOgogICAgICBodHRw
Oi8vYnVnemlsbGEueGVuLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MTgyMgoKICAgICog
TG9hZCBibGt0YXAgZHJpdmVyIGZyb20geGVuY29tbW9ucyBpbml0c2NyaXB0IGlmIGF2YWlsYWJs
ZSwgdGhyZWFkIGF0OgogICAgICA8ZGI2MTRlOTJmYWY3NDNlMjBiM2YuMTMzNzA5Njk3N0Brb2Rv
Mj4uIFRvIGJlIGZpeGVkIG1vcmUKICAgICAgcHJvcGVybHkgaW4gNC4zCgoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 13:01:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 13:01: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 1SeQiN-0007eM-SN; Tue, 12 Jun 2012 13:00: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 1SeQiM-0007eH-Dv
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:00:54 +0000
Received: from [85.158.143.35:18511] by server-1.bemta-4.messagelabs.com id
	53/32-24392-58D37DF4; Tue, 12 Jun 2012 13:00:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339506048!5479591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31497 invoked from network); 12 Jun 2012 13:00:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 13:00:48 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12967928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 13:00:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 14:00:47 +0100
Message-ID: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 12 Jun 2012 14:00:46 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

QSBiaXQgbGF0ZSB0aGlzIHdlZWssIGR1ZSB0byBteSBiZWluZyBvbiB2YWNhdGlvbi4gSSdtIG9u
IHZhY2F0aW9uCm5leHQgdHdvIE1vbmRheSBhcyB3ZWxsIHNvIGl0IHdpbGwgYmUgbGF0ZSB0aGVu
IHRvby4KClBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hp
dmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhlIHRpbWUgbGluZSBp
cyBhcyBmb2xsb3dzOgoKMTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoy
IEFwcmlsICAgICAgICAgLS0gRmVhdHVyZSBGcmVlemUKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJdCdzIFJlYWR5IC0t
IEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCBy
ZWxlYXNlCgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVyIHRoZSByZWxlYXNlIHBs
YW4gYSBzdHJvbmcgY2FzZSB3aWxsCm5vdyBoYXZlIHRvIGJlIG1hZGUgYXMgdG8gd2h5IG5ldyBp
dGVtcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3QsCmVzcGVjaWFsbHkgYXMgYSBibG9ja2Vy
LCByYXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpJZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBi
dWdzIHdoaWNoIG11c3Qvc2hvdWxkIGJlIGZpeGVkIGZvciA0LjIgdGhlbgpwbGVhc2UgcmVwbHkg
dG8gdGhpcyB0aHJlYWQgKG90aGVyd2lzZSBJIG1heSBub3QgcmVtZW1iZXIgdG8gcGljayB0aGVt
CnVwIG5leHQgd2VlaykKCk90aGVyIHRoYW4gdGhhdCBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRl
ciB0aGUgZnJlZXplIHRvIGJlIGluIGZ1bGwKZWZmZWN0IGFuZCB0aGUgYmFyIHRvIGVudHJ5IHRv
IDQuMiB0byBiZSB2ZXJ5IGhpZ2guCgpoeXBlcnZpc29yLCBibG9ja2VyczoKCiAgICAqIE5vbmUK
IAp0b29scywgYmxvY2tlcnM6CgogICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxp
a2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKICAgICAgd2hpY2ggZG93bnN0cmVhbSdzIGNh
biBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgogICAgICB0aGlzIGFy
ZToKCiAgICAgICAgKiBMSUJYTF9OSUNfVFlQRSBlbnVtIG5hbWVzIGFyZSBjb25mdXNpbmcuCgog
ICAgICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKCiAgICAgICAg
ICAgICogbGlieGxfZG9tYWluX3N1c3BlbmQuIE1vdmUgeGNfZG9tYWluX3NhdmUvcmVzdG9yZSBp
bnRvIGEKICAgICAgICAgICAgICBzZXBhcmF0ZSBwcm9jZXNzIChJYW5KLCBwYXRjaGVzIHBvc3Rl
ZCkuCgogICAgICAgICAgICAqIGxpYnhsX2RldmljZV97ZGlzayxuaWMsdmtiLGFkZCxwY2l9X2Fk
ZCAoYW5kCiAgICAgICAgICAgICAgcmVtb3ZlKS4gKFJvZ2VyLCBwYXRjaGVzIHBvc3RlZCBmb3Ig
ZGlzayAmIG5pYywgdmtiCiAgICAgICAgICAgICAgdHJpdmlhbCwgbm90IGxvb2tlZCBhdCBwY2kg
eWV0KQoKICAgICAgICAqIHVzZSBsaWJ4bF9jcHVtYXAgZm9yIGJfaW5mby5hdmFpbF9jcHVzIGlu
c3RlYWQgb2YgYW4gaW50LAogICAgICAgICAgdGhpcyJhbGxvd3Mgc2V0dGluZyBtb3JlIHRoYW4g
MzEgQ1BVUyAoWWFuZyBaIFpoYW5nLCBwYXRjaGVzCiAgICAgICAgICBwb3N0ZWQpCgogICAgICAg
ICogdXNlIGFuIGVudW0gZm9yIFZHQSBpbnRlcmZhY2UgdHlwZSAoZS5nLiBDaXJydXMsCiAgICAg
ICAgICBTdGRWR0EpLiBBbGxvd3MgZm9yIFFYTCBzdXBwb3J0IChpbiA0LjMpLiAoWmhvdSBQZW5n
LAogICAgICAgICAgcGF0Y2hlcyBwb3N0ZWQpCgogICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGgg
eG06CgogICAgICAgICogW0JVR10gY2Fubm90IGNyZWF0ZSBhbiBlbXB0eSBDRC1ST00gZHJpdmUg
b24gSFZNIGd1ZXN0LAogICAgICAgICAgcmVwb3J0ZWQgYnkgRmFiaW8gRmFudG9uaSBpbiA8NEY5
NjcyREQuMjA4MDkwMkB0aXNjYWxpLml0PgoKICAgICAgICAqIGRvZXMgbm90IGF1dG9tYXRpY2Fs
bHkgdHJ5IHRvIHNlbGVjdCBhIChzZXQgb2YpIG5vZGUocykgb24KICAgICAgICAgIHdoaWNoIHRv
IGNyZWF0ZSBhIFZNIGFuZCBwaW4gaXRzIHZjcHVzIHRoZXJlLiAoRGFyaW8KICAgICAgICAgIEZh
Z2dpb2xpLCBwYXRjaGVzIHJlcG9zdGVkLCB1bmRlciByZXZpZXcpCgogICAgKiBNb3JlIGZvcm1h
bGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgogICAgICB0
cmVlLiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQgLXJjMSB0
bwogICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwuCgogICAgKiBjYWxsaW5nIGhvdHBsdWcg
c2NyaXB0cyBmcm9tIHhsIChMaW51eCBhbmQgTmV0QlNEKSAoUm9nZXIgUGF1CiAgICAgIE1vbm7D
qSwgcGF0Y2hlcyBwb3N0ZWQpCgogICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dz
IG9uIGZyb20gaG90cGx1ZyBzY3JpcHQgKFJvZ2VyCiAgICAgIFBhdSBNb25uw6ksICJqdXN0IGJl
IGEgbWF0dGVyIG9mIHJlbW92aW5nIGFuICJpZiIiKQoKICAgICogQWRqdXN0bWVudHMgbmVlZGVk
IGZvciBxZGlzayBiYWNrZW5kIHRvIHdvcmsgb24gbm9uLXB2b3BzIExpbnV4LgogICAgICAicWVt
dS94ZW5kaXNrOiBzZXQgbWF4aW11bSBudW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4g
QmV1bGljaCkKCiAgICAqIENvbmZpcm0gdGhhdCBtaWdyYXRpb24gZnJvbSBYZW4gNC4xIC0+IDQu
MiB3b3Jrcy4uLgoKICAgICogW0JVR10gQnVpbGQgZmFpbHVyZSBkdWUgdG8gZ2NjIC1Xc3dpdGNo
IG9uIHNvbWUgZGlzdHJvcwogICAgICB2cy4gTElCWExfRE9NQUlOX1RZUEUuIChEYXJpbyBGYWdn
aW9saSwgRE9ORSkKCmh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKCiAgICAqIFBvRCBwZXJmb3Jt
YW5jZSBpbXByb3ZlbWVudHMgKEdlb3JnZSBEdW5sYXAsIHBhdGNoZXMgcG9zdGVkKQoKdG9vbHMs
IG5pY2UgdG8gaGF2ZToKCiAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAg
KiBBY2NlcHQgInhsIGNyIC9kZXYvbnVsbCBwYXJhbT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29u
ZmlnCiAgICAgICAgICBvbiB0aGUgY29tbWFuZCBsaW5lIChXLiBNaWNoYWVsIFBldHVsbG8sIHBh
dGNoIHBvc3RlZCkKCiAgICAqIGxpYnhsOiBBZGQgQVBJIHRvIHJldHJpZXZlIGRvbWFpbiBjb25z
b2xlIHR0eSAoQmFtdm9yIEppYW4KICAgICAgWmhhbmcsIERPTkUpCgogICAgKiBsaWJ4bCBzdGFi
bGUgQVBJCgogICAgICAgICogbGlieGxfd2FpdF9mb3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9m
b3JfbWVtb3J5X3RhcmdldC4KICAgICAgICAgIEludGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwg
cmVsYXRlZCB0bwogICAgICAgICAgbG9ja2luZy9zZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNy
ZWF0ZS4gSWFuSiB0byBhZGQgbm90ZQogICAgICAgICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVp
bmcgc3Vic3RhbmRhcmQgYnV0IG90aGVyd2lzZSBkZWZlcgogICAgICAgICAgdG8gNC4zLgoKICAg
ICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAg
ICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxkIGJlIGVhc3kgb25jZQogICAgICAgICAgICAg
IGRpc2tfe2FkZCxyZW1vdmV9IGRvbmUuIFRoaXMgaXMgYmFzaWNhbGx5IGEgaGVscGVyCiAgICAg
ICAgICAgICAgZnVuY3Rpb24gYW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRl
ZCBpbgogICAgICAgICAgICAgIHRlcm1zIG9mIHRoZSBsaWJ4bF9kaXNrXyogaW50ZXJmYWNlcy4g
SWYgdGhpcyBpcyBub3QKICAgICAgICAgICAgICBkb25lIGluIHRpbWUgd2Ugc2hvdWxkIGRvY3Vt
ZW50IGFzIGEgc3Vic3RhbmRhcmQKICAgICAgICAgICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3Vi
amVjdCB0byBjaGFuZ2UgcG9zdCA0LjIuCgogICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBw
YXRjaCBmb3IgcWVtdS11cHN0cmVhbQogICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0Ogog
ICAgICBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1
L21zZzAwMjUwLmh0bWwKICAgICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lm
eWluZyB2aWRlb21lbSBzaXplIGZvciB0aGUKICAgICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2Eu
ICAoYnV0IHRoaXMgd29ya3Mgd2l0aAogICAgICBxZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNp
IEvDpHJra8OkaW5lbikKCiAgICAqIHFlbXUtdXBzdHJlYW0gZm9yIE5ldEJTRCAoUm9nZXIpCgog
ICAgKiBbQlVHXSBsb25nIHN0b3AgZHVyaW5nIHRoZSBndWVzdCBib290IHByb2Nlc3Mgd2l0aCBx
Y293IGltYWdlLAogICAgICByZXBvcnRlZCBieSBJbnRlbDogaHR0cDovL2J1Z3ppbGxhLnhlbi5v
cmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjEKCiAgICAqIFtCVUddIHZjcHUtc2V0IGRv
ZXNuJ3QgdGFrZSBlZmZlY3Qgb24gZ3Vlc3QsIHJlcG9ydGVkIGJ5IEludGVsOgogICAgICBodHRw
Oi8vYnVnemlsbGEueGVuLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MTgyMgoKICAgICog
TG9hZCBibGt0YXAgZHJpdmVyIGZyb20geGVuY29tbW9ucyBpbml0c2NyaXB0IGlmIGF2YWlsYWJs
ZSwgdGhyZWFkIGF0OgogICAgICA8ZGI2MTRlOTJmYWY3NDNlMjBiM2YuMTMzNzA5Njk3N0Brb2Rv
Mj4uIFRvIGJlIGZpeGVkIG1vcmUKICAgICAgcHJvcGVybHkgaW4gNC4zCgoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 13:31:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 13:31: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 1SeRBc-00081g-VW; Tue, 12 Jun 2012 13:31:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SeRBb-00081b-MH
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:31:07 +0000
Received: from [85.158.139.83:32450] by server-9.bemta-5.messagelabs.com id
	52/32-29678-A9447DF4; Tue, 12 Jun 2012 13:31:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339507854!32345136!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23444 invoked from network); 12 Jun 2012 13:30:56 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jun 2012 13:30:56 -0000
Received: from mail175-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 13:29:52 +0000
Received: from mail175-tx2 (localhost [127.0.0.1])	by
	mail175-tx2-R.bigfish.com (Postfix) with ESMTP id 4747C602BB	for
	<xen-devel@lists.xen.org>; Tue, 12 Jun 2012 13:29:52 +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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25he5bhf0ah34h)
Received: from mail175-tx2 (localhost.localdomain [127.0.0.1]) by mail175-tx2
	(MessageSwitch) id 1339507789742502_21516;
	Tue, 12 Jun 2012 13:29:49 +0000 (UTC)
Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.236])	by
	mail175-tx2.bigfish.com (Postfix) with ESMTP id AFE3612003F	for
	<xen-devel@lists.xen.org>; Tue, 12 Jun 2012 13:29:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 13:29:48 +0000
X-WSS-ID: 0M5IAUX-02-9UN-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 2CF19C80E3	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012
	08:30:32 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 12 Jun 2012 08:38:52 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 12 Jun 2012 08:30:34 -0500
Received: from donner.osrc.amd.com (165.204.15.15) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012
	09:30:33 -0400
Message-ID: <4FD74504.8090407@amd.com>
Date: Tue, 12 Jun 2012 15:32:52 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------090001020108050401000304"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: fix performance decrease with asid
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090001020108050401000304
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Do not clear asid cleanbit unconditionally. This shaves
off 100 cycles from the VMRUN instruction.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------090001020108050401000304
Content-Type: text/plain; charset="us-ascii"; name="xen_asid.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_asid.diff"
Content-Description: xen_asid.diff

diff -r 1f466caea5b7 xen/arch/x86/hvm/svm/asid.c
--- a/xen/arch/x86/hvm/svm/asid.c	Fri Jun 08 15:24:29 2012 +0200
+++ b/xen/arch/x86/hvm/svm/asid.c	Tue Jun 12 15:12:48 2012 +0200
@@ -63,7 +63,8 @@ void svm_asid_handle_vmrun(void)
         return;
     }
 
-    vmcb_set_guest_asid(vmcb, p_asid->asid);
+    if (vmcb_get_guest_asid(vmcb) != p_asid->asid)
+        vmcb_set_guest_asid(vmcb, p_asid->asid);
     vmcb->tlb_control = need_flush;
 }
 

--------------090001020108050401000304
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090001020108050401000304--


From xen-devel-bounces@lists.xen.org Tue Jun 12 13:31:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 13:31: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 1SeRBc-00081g-VW; Tue, 12 Jun 2012 13:31:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SeRBb-00081b-MH
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:31:07 +0000
Received: from [85.158.139.83:32450] by server-9.bemta-5.messagelabs.com id
	52/32-29678-A9447DF4; Tue, 12 Jun 2012 13:31:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339507854!32345136!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23444 invoked from network); 12 Jun 2012 13:30:56 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jun 2012 13:30:56 -0000
Received: from mail175-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 13:29:52 +0000
Received: from mail175-tx2 (localhost [127.0.0.1])	by
	mail175-tx2-R.bigfish.com (Postfix) with ESMTP id 4747C602BB	for
	<xen-devel@lists.xen.org>; Tue, 12 Jun 2012 13:29:52 +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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25he5bhf0ah34h)
Received: from mail175-tx2 (localhost.localdomain [127.0.0.1]) by mail175-tx2
	(MessageSwitch) id 1339507789742502_21516;
	Tue, 12 Jun 2012 13:29:49 +0000 (UTC)
Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.236])	by
	mail175-tx2.bigfish.com (Postfix) with ESMTP id AFE3612003F	for
	<xen-devel@lists.xen.org>; Tue, 12 Jun 2012 13:29:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 13:29:48 +0000
X-WSS-ID: 0M5IAUX-02-9UN-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 2CF19C80E3	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012
	08:30:32 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 12 Jun 2012 08:38:52 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 12 Jun 2012 08:30:34 -0500
Received: from donner.osrc.amd.com (165.204.15.15) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012
	09:30:33 -0400
Message-ID: <4FD74504.8090407@amd.com>
Date: Tue, 12 Jun 2012 15:32:52 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------090001020108050401000304"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: fix performance decrease with asid
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090001020108050401000304
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Do not clear asid cleanbit unconditionally. This shaves
off 100 cycles from the VMRUN instruction.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------090001020108050401000304
Content-Type: text/plain; charset="us-ascii"; name="xen_asid.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_asid.diff"
Content-Description: xen_asid.diff

diff -r 1f466caea5b7 xen/arch/x86/hvm/svm/asid.c
--- a/xen/arch/x86/hvm/svm/asid.c	Fri Jun 08 15:24:29 2012 +0200
+++ b/xen/arch/x86/hvm/svm/asid.c	Tue Jun 12 15:12:48 2012 +0200
@@ -63,7 +63,8 @@ void svm_asid_handle_vmrun(void)
         return;
     }
 
-    vmcb_set_guest_asid(vmcb, p_asid->asid);
+    if (vmcb_get_guest_asid(vmcb) != p_asid->asid)
+        vmcb_set_guest_asid(vmcb, p_asid->asid);
     vmcb->tlb_control = need_flush;
 }
 

--------------090001020108050401000304
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090001020108050401000304--


From xen-devel-bounces@lists.xen.org Tue Jun 12 13:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 13:57: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 1SeRaM-0008L2-BI; Tue, 12 Jun 2012 13:56:42 +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 1SeRaL-0008Kx-Kn
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:56:41 +0000
Received: from [85.158.138.51:2529] by server-8.bemta-3.messagelabs.com id
	FF/B3-22118-89A47DF4; Tue, 12 Jun 2012 13:56:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339509399!29237670!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6787 invoked from network); 12 Jun 2012 13:56:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 13:56:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 14:56:39 +0100
Message-Id: <4FD766E2020000780008974F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 14:57:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> tools, blockers:
> 
>     * Adjustments needed for qdisk backend to work on non-pvops Linux.
>       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)

Patch was posted and is in upstream qemu, just needs pulling back
into our two clones.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 13:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 13:57: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 1SeRaM-0008L2-BI; Tue, 12 Jun 2012 13:56:42 +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 1SeRaL-0008Kx-Kn
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 13:56:41 +0000
Received: from [85.158.138.51:2529] by server-8.bemta-3.messagelabs.com id
	FF/B3-22118-89A47DF4; Tue, 12 Jun 2012 13:56:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339509399!29237670!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6787 invoked from network); 12 Jun 2012 13:56:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 13:56:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 14:56:39 +0100
Message-Id: <4FD766E2020000780008974F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 14:57:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> tools, blockers:
> 
>     * Adjustments needed for qdisk backend to work on non-pvops Linux.
>       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)

Patch was posted and is in upstream qemu, just needs pulling back
into our two clones.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 14:06:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 14:06: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 1SeRj5-0000AD-BD; Tue, 12 Jun 2012 14:05: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 1SeRj4-0000A8-Ds
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:05:42 +0000
Received: from [85.158.139.83:24941] by server-11.bemta-5.messagelabs.com id
	55/9F-25194-5BC47DF4; Tue, 12 Jun 2012 14:05:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339509940!33257669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20914 invoked from network); 12 Jun 2012 14:05:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:05:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12970147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 14:05:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 15:05:36 +0100
Message-ID: <1339509935.24104.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 12 Jun 2012 15:05:35 +0100
In-Reply-To: <4FD766E2020000780008974F@nat28.tlf.novell.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > tools, blockers:
> > 
> >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> 
> Patch was posted and is in upstream qemu, just needs pulling back
> into our two clones.

Thanks. CCing Stefano to be sure he knows 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 Jun 12 14:06:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 14:06: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 1SeRj5-0000AD-BD; Tue, 12 Jun 2012 14:05: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 1SeRj4-0000A8-Ds
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:05:42 +0000
Received: from [85.158.139.83:24941] by server-11.bemta-5.messagelabs.com id
	55/9F-25194-5BC47DF4; Tue, 12 Jun 2012 14:05:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339509940!33257669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20914 invoked from network); 12 Jun 2012 14:05:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:05:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12970147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 14:05:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 15:05:36 +0100
Message-ID: <1339509935.24104.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 12 Jun 2012 15:05:35 +0100
In-Reply-To: <4FD766E2020000780008974F@nat28.tlf.novell.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > tools, blockers:
> > 
> >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> 
> Patch was posted and is in upstream qemu, just needs pulling back
> into our two clones.

Thanks. CCing Stefano to be sure he knows 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 Jun 12 14:07:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 14:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeRko-0000Er-Qz; Tue, 12 Jun 2012 14:07: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 1SeRkn-0000El-9Z
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:07:29 +0000
Received: from [193.109.254.147:46087] by server-5.bemta-14.messagelabs.com id
	56/28-31398-02D47DF4; Tue, 12 Jun 2012 14:07:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339509982!9318817!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19300 invoked from network); 12 Jun 2012 14:06:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:06:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12970178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 14:06:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 15:06:22 +0100
Message-ID: <1339509981.24104.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Tue, 12 Jun 2012 15:06:21 +0100
In-Reply-To: <20120612121510.GQ11695@bitfolk.com>
References: <20439.12248.291249.667993@mariner.uk.xensource.com>
	<20120612121510.GQ11695@bitfolk.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen Security Advisory 7 (CVE-2012-0217) - PV
 privilege escalation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-12 at 13:15 +0100, Andy Smith wrote:
> Hello,
> 
> A quick question with regard to XSA-7:
> 
> On Tue, Jun 12, 2012 at 01:02:32PM +0100, Xen.org security team wrote:
> > MITIGATION
> > ==========
> > 
> > This issue can be mitigated by running HVM (fully-virtualised)
> > or 32 bit PV guests only.
> 
> Assuming 64-bit hypervisor and dom0, with PV guests booted using
> pygrub, is there any way to restrict guests to 32-bit only?

Nothing which has been implemented but a couple of ideas which spring to
my mind, in no particular order:

      * A wrapper around pygrub to vet the kernel which it has
        extracted. I think this is a case of checking the machine type
        specified in the kernel's ELF header (and that it really is ELF
        etc etc).
      * Patch tools/libxc/xc_dom_x86.c to remove the
        xc_dom_register_arch_hooks call for xc_dom_64.
      * Use XSM to deny XEN_DOMCTL_set_address_size (I'm not sure how
        this stuff works).

Realistically the only robust way (i.e. the one which you could be most
sure of doing it's job properly with the least possibility of a sneakily
constructed kernel getting around the validation routines etc.) would be
to do it in the hypervisor, at which point you might as well just apply
the 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 Jun 12 14:07:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 14:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeRko-0000Er-Qz; Tue, 12 Jun 2012 14:07: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 1SeRkn-0000El-9Z
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:07:29 +0000
Received: from [193.109.254.147:46087] by server-5.bemta-14.messagelabs.com id
	56/28-31398-02D47DF4; Tue, 12 Jun 2012 14:07:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339509982!9318817!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19300 invoked from network); 12 Jun 2012 14:06:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:06:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12970178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 14:06:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 15:06:22 +0100
Message-ID: <1339509981.24104.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andy Smith <andy@strugglers.net>
Date: Tue, 12 Jun 2012 15:06:21 +0100
In-Reply-To: <20120612121510.GQ11695@bitfolk.com>
References: <20439.12248.291249.667993@mariner.uk.xensource.com>
	<20120612121510.GQ11695@bitfolk.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen Security Advisory 7 (CVE-2012-0217) - PV
 privilege escalation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-12 at 13:15 +0100, Andy Smith wrote:
> Hello,
> 
> A quick question with regard to XSA-7:
> 
> On Tue, Jun 12, 2012 at 01:02:32PM +0100, Xen.org security team wrote:
> > MITIGATION
> > ==========
> > 
> > This issue can be mitigated by running HVM (fully-virtualised)
> > or 32 bit PV guests only.
> 
> Assuming 64-bit hypervisor and dom0, with PV guests booted using
> pygrub, is there any way to restrict guests to 32-bit only?

Nothing which has been implemented but a couple of ideas which spring to
my mind, in no particular order:

      * A wrapper around pygrub to vet the kernel which it has
        extracted. I think this is a case of checking the machine type
        specified in the kernel's ELF header (and that it really is ELF
        etc etc).
      * Patch tools/libxc/xc_dom_x86.c to remove the
        xc_dom_register_arch_hooks call for xc_dom_64.
      * Use XSM to deny XEN_DOMCTL_set_address_size (I'm not sure how
        this stuff works).

Realistically the only robust way (i.e. the one which you could be most
sure of doing it's job properly with the least possibility of a sneakily
constructed kernel getting around the validation routines etc.) would be
to do it in the hypervisor, at which point you might as well just apply
the 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 Jun 12 14:09:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 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 1SeRmm-0000Lb-GL; Tue, 12 Jun 2012 14:09:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1SeRml-0000LU-F5
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:09:31 +0000
Received: from [85.158.139.83:7301] by server-7.bemta-5.messagelabs.com id
	48/8F-19648-A9D47DF4; Tue, 12 Jun 2012 14:09:30 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339510168!33543133!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8013 invoked from network); 12 Jun 2012 14:09:29 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:09:29 -0000
Received: by yenm4 with SMTP id m4so3976931yen.32
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 07:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=0raORvY6+OGo7vYYiyF1GSauyX00a+WQos1Seh6ENng=;
	b=oSa3+fa3AqJ3LpBwswLbqzrjGxCxkrP5bYnvvFO5lgIVJTpEibsJOwyyd9I5KFzEiH
	KiUUn7bZVbtVf5lqV28awDVRkHQrQELmGn5KLRJphBb7bo+/WN43jWvvk1DtaSUMeyA5
	XNSsFvIvNI9IQ1TjyviK/XxbtTQWlQ95s9aArFxnTFsjXWmYRn24+/Jyn7lSgc4g5Ffo
	z/q8I7HjXPp1XXEhg4CeSfihyimqbRAzhpQSnK18K0cfVCWJv+XacIXn33cjD5Zq4ZK1
	w/icx1YkY0OUrytT9aecOm4W9R+lvoAdYeAIcz8XsTFmZlFWUG0Ntks73B0JMUKonllf
	ZKtg==
Received: by 10.236.143.35 with SMTP id k23mr27307204yhj.72.1339510168220;
	Tue, 12 Jun 2012 07:09:28 -0700 (PDT)
Received: from home.desunote.ru ([2a00:11d8:1201:0:962b:18:e716:fb97])
	by mx.google.com with ESMTPS id z19sm27138441anh.22.2012.06.12.07.09.26
	(version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 07:09:27 -0700 (PDT)
Message-ID: <4FD74D9A.8080807@gmail.com>
Date: Tue, 12 Jun 2012 18:09:30 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
In-Reply-To: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
Subject: Re: [Xen-devel] memory introspection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SSB0aGluayBjcmVhdGluZyBhIGh5cGVydmlzb3ItbGV2ZWwgR1BMIGNvbXBvbmVudCB3aXRoIHNv
bWUga2luZCBBUEkgYW5kIAp1c2luZyBpdCBieSBwcm9wcmlldGFyeSBkb20wLWxldmVsIHV0aWxp
dHkgaXMgZmluZSBzb2x1dGlvbi4gRXNwZWNpYWxseSwgCmlmIHlvdSBtYWtlIGl0IHNvbWVob3cg
dXNhYmxlIGZvciBhbGwgb3RoZXIgd29ybGQgYnkgZGVmaW5pbmcgZ29vZCBBUEkuCgpPbiAxMi4w
Ni4yMDEyIDE2OjQ4LCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4gSGksCj4KPiBJIHdvdWxkIGxpa2Ug
dG8gcmVvcGVuIGEgZGlzY3Vzc2lvbiB3aGljaCB0b29rIHBsYWNlIHNvbWUgdGltZSBhZ28KPiBo
ZXJlOgo+Cj4gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4taW50cm9zcGVj
dC8yMDA4LTExL21zZzAwMDAxLmh0bWwKPgo+IGJ1dCB3aXRoIGEgZm9jdXMgb24gaW4taHYgaW50
cm9zcGVjdGlvbiwgdGhhdCBpczogdGhlIGVuZ2luZSBkb2luZyB0aGUKPiBpbnRyb3NwZWN0aW9u
IGxpdmVzIGluIHRoZSBzYW1lIHJpbmcgLyBtZW1vcnktc3BhY2UgYXMgdGhlIGh5cGVydmlzb3IK
PiBpdHNlbGYuCj4KPiBUaGUgdGVjaG5vbG9neSBJIHBsYW4gdG8gdXNlIGlzIHByb3ByaWV0YXJ5
IGFuZCB3aXRoIGFuIGFscmVhZHkgZGVmaW5lZAo+IGludGVyZmFjZSwgc28gSSdtIGxvb2tpbmcg
YXQgYWRkaW5nIHNvbWUgZ2x1ZSBjb2RlIHRvIFhlbiBpbiBvcmRlciB0bwo+IG1ha2UgdGhlIHR3
byB1bmRlcnN0YW5kIGVhY2ggb3RoZXIuIFRoZSByZWFzb24gdGhlIGVuZ2luZSBuZWVkcyB0bwo+
IHJlc2lkZSBpbiB0aGUgc2FtZSBzcGFjZSBhcyB0aGUgaHYgaXMgdGhhdCBpdCB3YW50cyB0byBj
bG9zZWx5IG1vbml0b3IKPiBjZXJ0YWluIG1lbW9yeSBhbmQgcmVnaXN0ZXIgY2hhbmdlcyBpbiBv
cmRlciB0byBpZGVudGlmeSBwb3NzaWJsZQo+IHJvb3RraXRzLCBjaGFuZ2VzIHdoaWNoIChkZXBl
bmRpbmcgb24gdGhlIE9TKSBjYW4gb2NjdXIgaW4gYSBsZWdpdGltYXRlCj4gd2F5IG1hbnkgbWFu
eSB0aW1lcyBwZXIgc2Vjb25kLgo+Cj4gQmVmb3JlIEkgZ28gaW50byBtb3JlIGRldGFpbCBJIHdv
dWxkIGxpa2UgdG8ga25vdyBpZiwgZnJvbSBhIGxlZ2FsCj4gcG9pbnQgb2YgdmlldywgdGhlcmUn
cyBhbnkgd2F5IHRvIGhhdmUgYSBjbG9zZWQgc291cmNlIGNvbXBvbmVudCB1c2luZwo+IHRoZSBw
cml2YXRlIFhlbiBBUEkgKHRoZSBvbmVzIGhhbmRsaW5nIGV4Y2VwdGlvbnMsIHJlZ2lzdGVyIGNo
YW5nZXMgZXRjLgo+IGZvciBkb21VLXMpLCBvciBpZiBhIGdsdWUgY29kZSBsaWNlbnNlZCBhcyBM
R1BMIHdvdWxkIGJlIGVub3VnaCB0bwo+IGJyaWRnZSB0aGUgR1BMLXByb3ByaWV0YXJ5IGdhcC4K
Pgo+IEknZCBiZSBoYXBweSB0byBoZWxwIGlmIHRoZSBnbHVlIGNvZGUgd2VyZSB0byBldm9sdmUg
aW50byBhbiBBUEkgaW4gaXRzCj4gb3duIHJpZ2h0IHdoaWNoIG90aGVyIGNvbXBhbmllcyBjYW4g
dXNlLgo+Cj4gVGhhbmsgeW91LAo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 14:09:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 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 1SeRmm-0000Lb-GL; Tue, 12 Jun 2012 14:09:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1SeRml-0000LU-F5
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:09:31 +0000
Received: from [85.158.139.83:7301] by server-7.bemta-5.messagelabs.com id
	48/8F-19648-A9D47DF4; Tue, 12 Jun 2012 14:09:30 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339510168!33543133!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8013 invoked from network); 12 Jun 2012 14:09:29 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:09:29 -0000
Received: by yenm4 with SMTP id m4so3976931yen.32
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 07:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=0raORvY6+OGo7vYYiyF1GSauyX00a+WQos1Seh6ENng=;
	b=oSa3+fa3AqJ3LpBwswLbqzrjGxCxkrP5bYnvvFO5lgIVJTpEibsJOwyyd9I5KFzEiH
	KiUUn7bZVbtVf5lqV28awDVRkHQrQELmGn5KLRJphBb7bo+/WN43jWvvk1DtaSUMeyA5
	XNSsFvIvNI9IQ1TjyviK/XxbtTQWlQ95s9aArFxnTFsjXWmYRn24+/Jyn7lSgc4g5Ffo
	z/q8I7HjXPp1XXEhg4CeSfihyimqbRAzhpQSnK18K0cfVCWJv+XacIXn33cjD5Zq4ZK1
	w/icx1YkY0OUrytT9aecOm4W9R+lvoAdYeAIcz8XsTFmZlFWUG0Ntks73B0JMUKonllf
	ZKtg==
Received: by 10.236.143.35 with SMTP id k23mr27307204yhj.72.1339510168220;
	Tue, 12 Jun 2012 07:09:28 -0700 (PDT)
Received: from home.desunote.ru ([2a00:11d8:1201:0:962b:18:e716:fb97])
	by mx.google.com with ESMTPS id z19sm27138441anh.22.2012.06.12.07.09.26
	(version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 07:09:27 -0700 (PDT)
Message-ID: <4FD74D9A.8080807@gmail.com>
Date: Tue, 12 Jun 2012 18:09:30 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
In-Reply-To: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
Subject: Re: [Xen-devel] memory introspection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SSB0aGluayBjcmVhdGluZyBhIGh5cGVydmlzb3ItbGV2ZWwgR1BMIGNvbXBvbmVudCB3aXRoIHNv
bWUga2luZCBBUEkgYW5kIAp1c2luZyBpdCBieSBwcm9wcmlldGFyeSBkb20wLWxldmVsIHV0aWxp
dHkgaXMgZmluZSBzb2x1dGlvbi4gRXNwZWNpYWxseSwgCmlmIHlvdSBtYWtlIGl0IHNvbWVob3cg
dXNhYmxlIGZvciBhbGwgb3RoZXIgd29ybGQgYnkgZGVmaW5pbmcgZ29vZCBBUEkuCgpPbiAxMi4w
Ni4yMDEyIDE2OjQ4LCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4gSGksCj4KPiBJIHdvdWxkIGxpa2Ug
dG8gcmVvcGVuIGEgZGlzY3Vzc2lvbiB3aGljaCB0b29rIHBsYWNlIHNvbWUgdGltZSBhZ28KPiBo
ZXJlOgo+Cj4gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4taW50cm9zcGVj
dC8yMDA4LTExL21zZzAwMDAxLmh0bWwKPgo+IGJ1dCB3aXRoIGEgZm9jdXMgb24gaW4taHYgaW50
cm9zcGVjdGlvbiwgdGhhdCBpczogdGhlIGVuZ2luZSBkb2luZyB0aGUKPiBpbnRyb3NwZWN0aW9u
IGxpdmVzIGluIHRoZSBzYW1lIHJpbmcgLyBtZW1vcnktc3BhY2UgYXMgdGhlIGh5cGVydmlzb3IK
PiBpdHNlbGYuCj4KPiBUaGUgdGVjaG5vbG9neSBJIHBsYW4gdG8gdXNlIGlzIHByb3ByaWV0YXJ5
IGFuZCB3aXRoIGFuIGFscmVhZHkgZGVmaW5lZAo+IGludGVyZmFjZSwgc28gSSdtIGxvb2tpbmcg
YXQgYWRkaW5nIHNvbWUgZ2x1ZSBjb2RlIHRvIFhlbiBpbiBvcmRlciB0bwo+IG1ha2UgdGhlIHR3
byB1bmRlcnN0YW5kIGVhY2ggb3RoZXIuIFRoZSByZWFzb24gdGhlIGVuZ2luZSBuZWVkcyB0bwo+
IHJlc2lkZSBpbiB0aGUgc2FtZSBzcGFjZSBhcyB0aGUgaHYgaXMgdGhhdCBpdCB3YW50cyB0byBj
bG9zZWx5IG1vbml0b3IKPiBjZXJ0YWluIG1lbW9yeSBhbmQgcmVnaXN0ZXIgY2hhbmdlcyBpbiBv
cmRlciB0byBpZGVudGlmeSBwb3NzaWJsZQo+IHJvb3RraXRzLCBjaGFuZ2VzIHdoaWNoIChkZXBl
bmRpbmcgb24gdGhlIE9TKSBjYW4gb2NjdXIgaW4gYSBsZWdpdGltYXRlCj4gd2F5IG1hbnkgbWFu
eSB0aW1lcyBwZXIgc2Vjb25kLgo+Cj4gQmVmb3JlIEkgZ28gaW50byBtb3JlIGRldGFpbCBJIHdv
dWxkIGxpa2UgdG8ga25vdyBpZiwgZnJvbSBhIGxlZ2FsCj4gcG9pbnQgb2YgdmlldywgdGhlcmUn
cyBhbnkgd2F5IHRvIGhhdmUgYSBjbG9zZWQgc291cmNlIGNvbXBvbmVudCB1c2luZwo+IHRoZSBw
cml2YXRlIFhlbiBBUEkgKHRoZSBvbmVzIGhhbmRsaW5nIGV4Y2VwdGlvbnMsIHJlZ2lzdGVyIGNo
YW5nZXMgZXRjLgo+IGZvciBkb21VLXMpLCBvciBpZiBhIGdsdWUgY29kZSBsaWNlbnNlZCBhcyBM
R1BMIHdvdWxkIGJlIGVub3VnaCB0bwo+IGJyaWRnZSB0aGUgR1BMLXByb3ByaWV0YXJ5IGdhcC4K
Pgo+IEknZCBiZSBoYXBweSB0byBoZWxwIGlmIHRoZSBnbHVlIGNvZGUgd2VyZSB0byBldm9sdmUg
aW50byBhbiBBUEkgaW4gaXRzCj4gb3duIHJpZ2h0IHdoaWNoIG90aGVyIGNvbXBhbmllcyBjYW4g
dXNlLgo+Cj4gVGhhbmsgeW91LAo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 14:58:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 14:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeSYB-00014Y-NL; Tue, 12 Jun 2012 14:58: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 1SeSYA-00014T-N1
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:58:30 +0000
Received: from [85.158.139.83:43442] by server-2.bemta-5.messagelabs.com id
	5A/DE-04598-51957DF4; Tue, 12 Jun 2012 14:58:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339513109!26018180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15290 invoked from network); 12 Jun 2012 14:58:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:58:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972061"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 14:58:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 15:58:28 +0100
Message-ID: <1339513107.24104.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 15:58:27 +0100
In-Reply-To: <20434.2955.317215.979906@mariner.uk.xensource.com>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
	<20434.2955.317215.979906@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 15:26 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> > On 08/06/12 12:10, Ian Jackson wrote:
> > > Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> > >> As it happens in the implementation of `xl sched-sedf -d ...', some
> > >> consistency checking is needed for the scheduling parameters when
> > >> they come from the config file.
> > > Thanks, I am happy with this from a libxl point of view.  I would like
> > > to see an ack from George from a scheduler point of view.
> > I think Dario knows more about what sedf wants than I do; and since it 
> > only does anything when the domain is using sedf, I think it's fine.
> > 
> > So FWIW:
> > 
> > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> Great, thanks.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Was it deliberate that you took this one but not the other patch from
this series of two, namely "libxl: propagete down the error from
libxl_domain_sched_params_set"?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 14:58:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 14:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeSYB-00014Y-NL; Tue, 12 Jun 2012 14:58: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 1SeSYA-00014T-N1
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 14:58:30 +0000
Received: from [85.158.139.83:43442] by server-2.bemta-5.messagelabs.com id
	5A/DE-04598-51957DF4; Tue, 12 Jun 2012 14:58:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339513109!26018180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15290 invoked from network); 12 Jun 2012 14:58:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 14:58:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972061"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 14:58:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 15:58:28 +0100
Message-ID: <1339513107.24104.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 15:58:27 +0100
In-Reply-To: <20434.2955.317215.979906@mariner.uk.xensource.com>
References: <patchbomb.1339146487@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
	<20434.2955.317215.979906@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 15:26 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> > On 08/06/12 12:10, Ian Jackson wrote:
> > > Dario Faggioli writes ("[PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> > >> As it happens in the implementation of `xl sched-sedf -d ...', some
> > >> consistency checking is needed for the scheduling parameters when
> > >> they come from the config file.
> > > Thanks, I am happy with this from a libxl point of view.  I would like
> > > to see an ack from George from a scheduler point of view.
> > I think Dario knows more about what sedf wants than I do; and since it 
> > only does anything when the domain is using sedf, I think it's fine.
> > 
> > So FWIW:
> > 
> > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> Great, thanks.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Was it deliberate that you took this one but not the other patch from
this series of two, namely "libxl: propagete down the error from
libxl_domain_sched_params_set"?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSde-0001KG-Ft; Tue, 12 Jun 2012 15:04:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1SeSdc-0001K5-LG
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 15:04:08 +0000
Received: from [85.158.138.51:32757] by server-2.bemta-3.messagelabs.com id
	15/60-16299-76A57DF4; Tue, 12 Jun 2012 15:04:07 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339513445!28081124!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6476 invoked from network); 12 Jun 2012 15:04:07 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jun 2012 15:04:07 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1SeSdZ-0007MH-5m
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 08:04:05 -0700
Date: Tue, 12 Jun 2012 08:04:05 -0700 (PDT)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1339513445172-5709428.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] 3.4.1 suspend / hibernate  resume not working.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys, 
i've read, a few threads ago, that suspend/resume should work on 3.4
kernels. 
Actually it doesn't work for me, the system goes on suspend, keeping
monitors on and power led blinking, but it never resumes, I always have to
brutally shutdown it. CONFIG_XEN_ACPI_PROCESSOR is set. 
Same thing it always did with previouses kernels. 
It works flawlessy if I start the system without the xen hypervisor. 
I was wondering, is there anyway to debug this? Any hints? Am I missing
something? 

I attach my dmesg log and xl info output. 

Ubuntu 12.04 
Linux thebeast 3.4.1-030401-generic #201206041411 SMP Mon Jun 4 18:12:24 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux 
host                   : thebeast 
release                : 3.4.1-030401-generic 
version                : #201206041411 SMP Mon Jun 4 18:12:24 UTC 2012 
machine                : x86_64 
nr_cpus                : 4 
max_cpu_id             : 3 
nr_nodes               : 1 
cores_per_socket       : 4 
threads_per_core       : 1 
cpu_mhz                : 3292 
hw_caps                :
bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000 
virt_caps              : hvm hvm_directio 
total_memory           : 8081 
free_memory            : 996 
sharing_freed_memory   : 0 
sharing_used_memory    : 0 
free_cpus              : 0 
xen_major              : 4 
xen_minor              : 2 
xen_extra              : -unstable 
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          : Thu Jun 07 19:46:57 2012 +0100 25467:32034d1914a6 
xen_commandline        : placeholder 
cc_compiler            : gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
cc_compile_by          : ivobacco 
cc_compile_domain      : 
cc_compile_date        : Fri Jun  8 02:54:27 CEST 2012 
xend_config_format     : 4 

http://xen.1045712.n5.nabble.com/file/n5709428/dmesg dmesg 

--
View this message in context: http://xen.1045712.n5.nabble.com/3-4-1-suspend-hibernate-resume-not-working-tp5709428.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 Jun 12 15:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSde-0001KG-Ft; Tue, 12 Jun 2012 15:04:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1SeSdc-0001K5-LG
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 15:04:08 +0000
Received: from [85.158.138.51:32757] by server-2.bemta-3.messagelabs.com id
	15/60-16299-76A57DF4; Tue, 12 Jun 2012 15:04:07 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339513445!28081124!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6476 invoked from network); 12 Jun 2012 15:04:07 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jun 2012 15:04:07 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1SeSdZ-0007MH-5m
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 08:04:05 -0700
Date: Tue, 12 Jun 2012 08:04:05 -0700 (PDT)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1339513445172-5709428.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] 3.4.1 suspend / hibernate  resume not working.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys, 
i've read, a few threads ago, that suspend/resume should work on 3.4
kernels. 
Actually it doesn't work for me, the system goes on suspend, keeping
monitors on and power led blinking, but it never resumes, I always have to
brutally shutdown it. CONFIG_XEN_ACPI_PROCESSOR is set. 
Same thing it always did with previouses kernels. 
It works flawlessy if I start the system without the xen hypervisor. 
I was wondering, is there anyway to debug this? Any hints? Am I missing
something? 

I attach my dmesg log and xl info output. 

Ubuntu 12.04 
Linux thebeast 3.4.1-030401-generic #201206041411 SMP Mon Jun 4 18:12:24 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux 
host                   : thebeast 
release                : 3.4.1-030401-generic 
version                : #201206041411 SMP Mon Jun 4 18:12:24 UTC 2012 
machine                : x86_64 
nr_cpus                : 4 
max_cpu_id             : 3 
nr_nodes               : 1 
cores_per_socket       : 4 
threads_per_core       : 1 
cpu_mhz                : 3292 
hw_caps                :
bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000 
virt_caps              : hvm hvm_directio 
total_memory           : 8081 
free_memory            : 996 
sharing_freed_memory   : 0 
sharing_used_memory    : 0 
free_cpus              : 0 
xen_major              : 4 
xen_minor              : 2 
xen_extra              : -unstable 
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          : Thu Jun 07 19:46:57 2012 +0100 25467:32034d1914a6 
xen_commandline        : placeholder 
cc_compiler            : gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
cc_compile_by          : ivobacco 
cc_compile_domain      : 
cc_compile_date        : Fri Jun  8 02:54:27 CEST 2012 
xend_config_format     : 4 

http://xen.1045712.n5.nabble.com/file/n5709428/dmesg dmesg 

--
View this message in context: http://xen.1045712.n5.nabble.com/3-4-1-suspend-hibernate-resume-not-working-tp5709428.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 Jun 12 15:06:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:06: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 1SeSfJ-0001Sx-Ro; Tue, 12 Jun 2012 15:05:53 +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 1SeSfI-0001Rp-DH
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:52 +0000
Received: from [85.158.143.99:65310] by server-3.bemta-4.messagelabs.com id
	AC/C4-05808-FCA57DF4; Tue, 12 Jun 2012 15:05:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339513545!22841493!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5179 invoked from network); 12 Jun 2012 15:05:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772980"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-BZ;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:21 +0100
Message-ID: <1339513523-1699-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V12 7/9] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_pt.c             |   10 +
 hw/xen_pt.h             |    2 +
 hw/xen_pt_config_init.c | 1387 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1399 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index c4c5dc3..6fad7ff 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -676,6 +676,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (xen_pt_config_init(s)) {
+        XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         XEN_PT_LOG(d, "no pin interrupt\n");
@@ -774,6 +781,9 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    xen_pt_config_delete(s);
+
     xen_pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index f029841..4bb8cb6 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -62,6 +62,8 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_ALLF 0xFFFFFFFF
 #define XEN_PT_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 64d22e8..1d97876 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1,11 +1,1398 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pt.h"
 
+#define XEN_PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define XEN_PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int xen_pt_hide_dev_cap(const XenHostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * xen_pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_SFP_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grps, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int xen_pt_common_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int xen_pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+
+/* Write register functions */
+
+static int xen_pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint8_t *val, uint8_t dev_value,
+                                 uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *val, uint16_t dev_value,
+                                 uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint32_t *val, uint32_t dev_value,
+                                 uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int xen_pt_vendor_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.vendor_id;
+    return 0;
+}
+static int xen_pt_device_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.device_id;
+    return 0;
+}
+static int xen_pt_status_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = xen_pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                       XenPTRegInfo *reg, uint32_t real_offset,
+                                       uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int xen_pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = xen_pt_pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int xen_pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *val, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*val & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define XEN_PT_BAR_MEM_RO_MASK    0x0000000F  /* BAR ReadOnly mask(Memory) */
+#define XEN_PT_BAR_MEM_EMU_MASK   0xFFFFFFF0  /* BAR emul mask(Memory) */
+#define XEN_PT_BAR_IO_RO_MASK     0x00000003  /* BAR ReadOnly mask(I/O) */
+#define XEN_PT_BAR_IO_EMU_MASK    0xFFFFFFFC  /* BAR emul mask(I/O) */
+
+static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
+                                         XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int type = s->real_device.io_regions[index - 1].type;
+
+        if ((type & XEN_HOST_PCI_REGION_TYPE_MEM)
+            && (type & XEN_HOST_PCI_REGION_TYPE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != XEN_PT_BAR_FLAG_UPPER) {
+                return XEN_PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return XEN_PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device.io_regions[index].type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return XEN_PT_BAR_FLAG_IO;
+    } else {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
+{
+    if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int xen_pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = xen_pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED) {
+        reg_field = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device.io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *val, uint32_t dev_value,
+                                uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = xen_pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (XEN_PT_BAR_ALLF & ~bar_ro_mask)) {
+                XEN_PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                            "Ignore mapping. "
+                            "(offset: 0x%02x, high address: 0x%08x)\n",
+                            reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                        XenPTReg *cfg_entry, uint32_t *val,
+                                        uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = xen_pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_header0[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_vendor_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_device_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_cmd_reg_read,
+        .u.w.write  = xen_pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = xen_pt_status_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = xen_pt_header_type_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_irqpin_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int xen_pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int xen_pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = XEN_PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_devctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint16_t *val,
+                                  uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pm[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_pmcsr_reg_read,
+        .u.w.write  = xen_pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int xen_pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                    const XenPTRegGroupInfo *grp_reg,
+                                    uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int xen_pt_vendor_size_init(XenPCIPassthroughState *s,
+                                   const XenPTRegGroupInfo *grp_reg,
+                                   uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        XEN_PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_header0,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_pm,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_vpd,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_vendor_size_init,
+        .emu_regs = xen_pt_emu_reg_vendor,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_pcie_size_init,
+        .emu_regs = xen_pt_emu_reg_pcie,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (xen_pt_emu_reg_grps[i].grp_id == cap_id) {
+                if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (xen_host_pci_get_byte(&s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (xen_host_pci_get_byte(&s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (xen_host_pci_get_byte(&s->real_device,
+                                  pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int xen_pt_config_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == XEN_PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int xen_pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grps);
+
+    for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, xen_pt_emu_reg_grps[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = xen_pt_emu_reg_grps + i;
+        if (xen_pt_emu_reg_grps[i].size_init) {
+            /* get register group size */
+            rc = xen_pt_emu_reg_grps[i].size_init(s, reg_grp_entry->reg_grp,
+                                                  reg_grp_offset,
+                                                  &reg_grp_entry->size);
+            if (rc < 0) {
+                xen_pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+            if (xen_pt_emu_reg_grps[i].emu_regs) {
+                int j = 0;
+                XenPTRegInfo *regs = xen_pt_emu_reg_grps[i].emu_regs;
+                /* initialize capability register */
+                for (j = 0; regs->size != 0; j++, regs++) {
+                    /* initialize capability register */
+                    rc = xen_pt_config_reg_init(s, reg_grp_entry, regs);
+                    if (rc < 0) {
+                        xen_pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void xen_pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:06: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 1SeSfJ-0001Sx-Ro; Tue, 12 Jun 2012 15:05:53 +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 1SeSfI-0001Rp-DH
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:52 +0000
Received: from [85.158.143.99:65310] by server-3.bemta-4.messagelabs.com id
	AC/C4-05808-FCA57DF4; Tue, 12 Jun 2012 15:05:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339513545!22841493!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5179 invoked from network); 12 Jun 2012 15:05:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772980"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-BZ;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:21 +0100
Message-ID: <1339513523-1699-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V12 7/9] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_pt.c             |   10 +
 hw/xen_pt.h             |    2 +
 hw/xen_pt_config_init.c | 1387 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1399 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index c4c5dc3..6fad7ff 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -676,6 +676,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (xen_pt_config_init(s)) {
+        XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         XEN_PT_LOG(d, "no pin interrupt\n");
@@ -774,6 +781,9 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    xen_pt_config_delete(s);
+
     xen_pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index f029841..4bb8cb6 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -62,6 +62,8 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_ALLF 0xFFFFFFFF
 #define XEN_PT_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 64d22e8..1d97876 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1,11 +1,1398 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pt.h"
 
+#define XEN_PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define XEN_PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int xen_pt_hide_dev_cap(const XenHostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * xen_pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_SFP_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grps, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int xen_pt_common_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int xen_pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+
+/* Write register functions */
+
+static int xen_pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint8_t *val, uint8_t dev_value,
+                                 uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *val, uint16_t dev_value,
+                                 uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint32_t *val, uint32_t dev_value,
+                                 uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int xen_pt_vendor_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.vendor_id;
+    return 0;
+}
+static int xen_pt_device_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.device_id;
+    return 0;
+}
+static int xen_pt_status_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = xen_pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                       XenPTRegInfo *reg, uint32_t real_offset,
+                                       uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int xen_pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = xen_pt_pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int xen_pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *val, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*val & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define XEN_PT_BAR_MEM_RO_MASK    0x0000000F  /* BAR ReadOnly mask(Memory) */
+#define XEN_PT_BAR_MEM_EMU_MASK   0xFFFFFFF0  /* BAR emul mask(Memory) */
+#define XEN_PT_BAR_IO_RO_MASK     0x00000003  /* BAR ReadOnly mask(I/O) */
+#define XEN_PT_BAR_IO_EMU_MASK    0xFFFFFFFC  /* BAR emul mask(I/O) */
+
+static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
+                                         XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int type = s->real_device.io_regions[index - 1].type;
+
+        if ((type & XEN_HOST_PCI_REGION_TYPE_MEM)
+            && (type & XEN_HOST_PCI_REGION_TYPE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != XEN_PT_BAR_FLAG_UPPER) {
+                return XEN_PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return XEN_PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device.io_regions[index].type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return XEN_PT_BAR_FLAG_IO;
+    } else {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
+{
+    if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int xen_pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = xen_pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED) {
+        reg_field = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device.io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *val, uint32_t dev_value,
+                                uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = xen_pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (XEN_PT_BAR_ALLF & ~bar_ro_mask)) {
+                XEN_PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                            "Ignore mapping. "
+                            "(offset: 0x%02x, high address: 0x%08x)\n",
+                            reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                        XenPTReg *cfg_entry, uint32_t *val,
+                                        uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = xen_pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_header0[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_vendor_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_device_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_cmd_reg_read,
+        .u.w.write  = xen_pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = xen_pt_status_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = xen_pt_header_type_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_irqpin_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int xen_pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int xen_pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = XEN_PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_devctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint16_t *val,
+                                  uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pm[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_pmcsr_reg_read,
+        .u.w.write  = xen_pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int xen_pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                    const XenPTRegGroupInfo *grp_reg,
+                                    uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int xen_pt_vendor_size_init(XenPCIPassthroughState *s,
+                                   const XenPTRegGroupInfo *grp_reg,
+                                   uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        XEN_PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_header0,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_pm,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_vpd,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_vendor_size_init,
+        .emu_regs = xen_pt_emu_reg_vendor,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_pcie_size_init,
+        .emu_regs = xen_pt_emu_reg_pcie,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (xen_pt_emu_reg_grps[i].grp_id == cap_id) {
+                if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (xen_host_pci_get_byte(&s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (xen_host_pci_get_byte(&s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (xen_host_pci_get_byte(&s->real_device,
+                                  pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int xen_pt_config_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == XEN_PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int xen_pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grps);
+
+    for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, xen_pt_emu_reg_grps[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = xen_pt_emu_reg_grps + i;
+        if (xen_pt_emu_reg_grps[i].size_init) {
+            /* get register group size */
+            rc = xen_pt_emu_reg_grps[i].size_init(s, reg_grp_entry->reg_grp,
+                                                  reg_grp_offset,
+                                                  &reg_grp_entry->size);
+            if (rc < 0) {
+                xen_pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+            if (xen_pt_emu_reg_grps[i].emu_regs) {
+                int j = 0;
+                XenPTRegInfo *regs = xen_pt_emu_reg_grps[i].emu_regs;
+                /* initialize capability register */
+                for (j = 0; regs->size != 0; j++, regs++) {
+                    /* initialize capability register */
+                    rc = xen_pt_config_reg_init(s, reg_grp_entry, regs);
+                    if (rc < 0) {
+                        xen_pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void xen_pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfG-0001R5-KY; Tue, 12 Jun 2012 15:05:50 +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 1SeSfE-0001P1-KD
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:49 +0000
Received: from [85.158.138.51:43131] by server-11.bemta-3.messagelabs.com id
	04/F0-28329-CCA57DF4; Tue, 12 Jun 2012 15:05:48 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8181 invoked from network); 12 Jun 2012 15:05:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438609"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-An;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:20 +0100
Message-ID: <1339513523-1699-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V12 6/9] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    1 +
 hw/xen_common.h         |    3 +
 hw/xen_pt.c             |  815 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt.h             |  248 ++++++++++++++
 hw/xen_pt_config_init.c |   11 +
 xen-all.c               |   12 +
 6 files changed, 1090 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index b719d8e..e361a92 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,6 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_common.h b/hw/xen_common.h
index fe7f227..03b0bb1 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -150,4 +150,7 @@ static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
 
 void destroy_hvm_domain(bool reboot);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
new file mode 100644
index 0000000..c4c5dc3
--- /dev/null
+++ b/hw/xen_pt.c
@@ -0,0 +1,815 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement xen_pt_mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(xen_pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "range.h"
+
+#define XEN_PT_NR_IRQS (256)
+static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%d] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int xen_pt_pci_config_access_check(PCIDevice *d, uint32_t addr, int len)
+{
+    /* check offset range */
+    if (addr >= 0xFF) {
+        XEN_PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access length. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (addr & (len - 1)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access size "
+                   "alignment. (addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xen_pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t xen_pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = xen_host_pci_get_block(&s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void xen_pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                    uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = xen_pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < XEN_PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED)) {
+        XEN_PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                    "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            XEN_PT_WARN(d, "Access to 0-Hardwired register. "
+                        "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = xen_host_pci_get_block(&s->real_device, addr,
+                                (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to xen_host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = xen_host_pci_set_block(&s->real_device, addr,
+                                    (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            XEN_PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t xen_pt_bar_read(void *o, target_phys_addr_t addr,
+                                unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    XEN_PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+    return 0;
+}
+static void xen_pt_bar_write(void *o, target_phys_addr_t addr, uint64_t val,
+                             unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as xen_pt_bar_read function */
+    XEN_PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = xen_pt_bar_read,
+    .write = xen_pt_bar_write,
+};
+
+static int xen_pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    XenHostPCIDevice *d = &s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+            }
+        }
+
+        memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                              "xen-pci-pt-bar", r->size);
+        pci_register_bar(&s->dev, i, type, &s->bar[i]);
+
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64" type: %#x)\n",
+                   i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (xen_host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            xen_host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        XEN_PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    XenHostPCIDevice *d = &s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int xen_pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+/*
+ * This function checks if an io_region overlaps an io_region from another
+ * device.  The io_region to check is provided with (addr, size and type)
+ * A callback can be provided and will be called for every region that is
+ * overlapped.
+ * The return value indicates if the region is overlappsed */
+struct CheckBarArgs {
+    XenPCIPassthroughState *s;
+    pcibus_t addr;
+    pcibus_t size;
+    uint8_t type;
+    bool rc;
+};
+static void xen_pt_check_bar_overlap(PCIBus *bus, PCIDevice *d, void *opaque)
+{
+    struct CheckBarArgs *arg = opaque;
+    XenPCIPassthroughState *s = arg->s;
+    uint8_t type = arg->type;
+    int i;
+
+    if (d->devfn == s->dev.devfn) {
+        return;
+    }
+
+    /* xxx: This ignores bridges. */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        const PCIIORegion *r = &d->io_regions[i];
+
+        if (!r->size) {
+            continue;
+        }
+        if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+            != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+            continue;
+        }
+
+        if (ranges_overlap(arg->addr, arg->size, r->addr, r->size)) {
+            XEN_PT_WARN(&s->dev,
+                        "Overlapped to device [%02x:%02x.%d] Region: %i"
+                        " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+                        pci_bus_num(bus), PCI_SLOT(d->devfn),
+                        PCI_FUNC(d->devfn), i, r->addr, r->size);
+            arg->rc = true;
+        }
+    }
+}
+
+static void xen_pt_region_update(XenPCIPassthroughState *s,
+                                 MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+    struct CheckBarArgs args = {
+        .s = s,
+        .addr = sec->offset_within_address_space,
+        .size = sec->size,
+        .rc = false,
+    };
+
+    bar = xen_pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    args.type = d->io_regions[bar].type;
+    pci_for_each_device(d->bus, pci_bus_num(d->bus),
+                        xen_pt_check_bar_overlap, &args);
+    if (args.rc) {
+        XEN_PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                    ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                    bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      XEN_PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(size + XC_PAGE_SIZE - 1),
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void xen_pt_begin(MemoryListener *l)
+{
+}
+
+static void xen_pt_commit(MemoryListener *l)
+{
+}
+
+static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, true);
+}
+
+static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, false);
+}
+
+static void xen_pt_region_nop(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_fns(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_global_fns(MemoryListener *l)
+{
+}
+
+static void xen_pt_eventfd_fns(MemoryListener *l, MemoryRegionSection *s,
+                               bool match_data, uint64_t data, int fd)
+{
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .begin = xen_pt_begin,
+    .commit = xen_pt_commit,
+    .region_add = xen_pt_region_add,
+    .region_nop = xen_pt_region_nop,
+    .region_del = xen_pt_region_del,
+    .log_start = xen_pt_log_fns,
+    .log_stop = xen_pt_log_fns,
+    .log_sync = xen_pt_log_fns,
+    .log_global_start = xen_pt_log_global_fns,
+    .log_global_stop = xen_pt_log_global_fns,
+    .eventfd_add = xen_pt_eventfd_fns,
+    .eventfd_del = xen_pt_eventfd_fns,
+    .priority = 10,
+};
+
+/* init */
+
+static int xen_pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        XEN_PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    XEN_PT_LOG(d, "Assigning real physical device %02x:%02x.%d"
+               " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    rc = xen_host_pci_device_get(&s->real_device, dom, bus, slot, func);
+    if (rc) {
+        XEN_PT_ERR(d, "Failed to \"open\" the real pci device. rc: %i\n", rc);
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device.is_virtfn;
+    if (s->is_virtfn) {
+        XEN_PT_LOG(d, "%04x:%02x:%02x.%d is a SR-IOV Virtual Function\n",
+                   s->real_device.domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (xen_host_pci_get_block(&s->real_device, 0, d->config,
+                               PCI_CONFIG_SPACE_SIZE) == -1) {
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    xen_pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        XEN_PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    machine_irq = s->real_device.irq;
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+                   machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        xen_host_pci_set_word(&s->real_device,
+                              PCI_COMMAND,
+                              pci_get_word(s->dev.config + PCI_COMMAND)
+                              | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        xen_pt_mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = xen_pt_pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                       e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
+                                  *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                                  | PCI_COMMAND_INTX_DISABLE);
+            xen_pt_mapped_machine_irq[machine_irq]--;
+
+            if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                               " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener, NULL);
+    XEN_PT_LOG(d, "Real physical device %02x:%02x.%d registered successfuly!\n",
+               bus, slot, func);
+
+    return 0;
+}
+
+static int xen_pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = xen_pt_pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
+                       " (machine irq: %i, rc: %d)"
+                       " But bravely continuing on..\n",
+                       'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        xen_pt_mapped_machine_irq[machine_irq]--;
+
+        if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                XEN_PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                           " But bravely continuing on..\n",
+                           machine_irq, rc);
+            }
+        }
+    }
+
+    xen_pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    xen_host_pci_device_put(&s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_pt_initfn;
+    k->exit = xen_pt_unregister_device;
+    k->config_read = xen_pt_pci_read_config;
+    k->config_write = xen_pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
new file mode 100644
index 0000000..f029841
--- /dev/null
+++ b/hw/xen_pt.h
@@ -0,0 +1,248 @@
+#ifndef XEN_PT_H
+#define XEN_PT_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "xen-host-pci-device.h"
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
+
+#ifdef XEN_PT_LOGGING_ENABLED
+#  define XEN_PT_LOG(d, _f, _a...)  xen_pt_log(d, "%s: " _f, __func__, ##_a)
+#  define XEN_PT_WARN(d, _f, _a...) \
+    xen_pt_log(d, "%s: Warning: "_f, __func__, ##_a)
+#else
+#  define XEN_PT_LOG(d, _f, _a...)
+#  define XEN_PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef XEN_PT_DEBUG_PCI_CONFIG_ACCESS
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len) \
+    xen_pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+               __func__, addr, val, len)
+#else
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define XEN_PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*xen_pt_conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*xen_pt_conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*xen_pt_conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define XEN_PT_BAR_ALLF 0xFFFFFFFF
+#define XEN_PT_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
+    XEN_PT_GRP_TYPE_EMU,            /* emul reg group */
+} XenPTRegisterGroupType;
+
+typedef enum {
+    XEN_PT_BAR_FLAG_MEM = 0,        /* Memory type BAR */
+    XEN_PT_BAR_FLAG_IO,             /* I/O type BAR */
+    XEN_PT_BAR_FLAG_UPPER,          /* upper 64bit BAR */
+    XEN_PT_BAR_FLAG_UNUSED,         /* unused BAR */
+} XenPTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    XenPTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    xen_pt_conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            xen_pt_conf_dword_write write;
+            xen_pt_conf_dword_read read;
+        } dw;
+        struct {
+            xen_pt_conf_word_write write;
+            xen_pt_conf_word_read read;
+        } w;
+        struct {
+            xen_pt_conf_byte_write write;
+            xen_pt_conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*xen_pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    XenPTRegisterGroupType grp_type;
+    uint8_t grp_size;
+    xen_pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_regs;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define XEN_PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    XenHostPCIDevice real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grps;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int xen_pt_config_init(XenPCIPassthroughState *s);
+void xen_pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int xen_pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t xen_pt_get_emul_size(XenPTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == XEN_PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, xen_pt_pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t xen_pt_pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    xen_host_pci_get_byte(&s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = xen_pt_pci_read_intx(s);
+
+    XEN_PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        XEN_PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+                   " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
new file mode 100644
index 0000000..64d22e8
--- /dev/null
+++ b/hw/xen_pt_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pt.h"
+
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5220cc..59f2323 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1191,3 +1191,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfG-0001R5-KY; Tue, 12 Jun 2012 15:05:50 +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 1SeSfE-0001P1-KD
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:49 +0000
Received: from [85.158.138.51:43131] by server-11.bemta-3.messagelabs.com id
	04/F0-28329-CCA57DF4; Tue, 12 Jun 2012 15:05:48 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8181 invoked from network); 12 Jun 2012 15:05:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438609"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-An;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:20 +0100
Message-ID: <1339513523-1699-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V12 6/9] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    1 +
 hw/xen_common.h         |    3 +
 hw/xen_pt.c             |  815 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt.h             |  248 ++++++++++++++
 hw/xen_pt_config_init.c |   11 +
 xen-all.c               |   12 +
 6 files changed, 1090 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index b719d8e..e361a92 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,6 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_common.h b/hw/xen_common.h
index fe7f227..03b0bb1 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -150,4 +150,7 @@ static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
 
 void destroy_hvm_domain(bool reboot);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
new file mode 100644
index 0000000..c4c5dc3
--- /dev/null
+++ b/hw/xen_pt.c
@@ -0,0 +1,815 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement xen_pt_mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(xen_pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "range.h"
+
+#define XEN_PT_NR_IRQS (256)
+static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%d] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int xen_pt_pci_config_access_check(PCIDevice *d, uint32_t addr, int len)
+{
+    /* check offset range */
+    if (addr >= 0xFF) {
+        XEN_PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access length. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (addr & (len - 1)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access size "
+                   "alignment. (addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xen_pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t xen_pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = xen_host_pci_get_block(&s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void xen_pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                    uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = xen_pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < XEN_PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED)) {
+        XEN_PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                    "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            XEN_PT_WARN(d, "Access to 0-Hardwired register. "
+                        "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = xen_host_pci_get_block(&s->real_device, addr,
+                                (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to xen_host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = xen_host_pci_set_block(&s->real_device, addr,
+                                    (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            XEN_PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t xen_pt_bar_read(void *o, target_phys_addr_t addr,
+                                unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    XEN_PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+    return 0;
+}
+static void xen_pt_bar_write(void *o, target_phys_addr_t addr, uint64_t val,
+                             unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as xen_pt_bar_read function */
+    XEN_PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = xen_pt_bar_read,
+    .write = xen_pt_bar_write,
+};
+
+static int xen_pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    XenHostPCIDevice *d = &s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+            }
+        }
+
+        memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                              "xen-pci-pt-bar", r->size);
+        pci_register_bar(&s->dev, i, type, &s->bar[i]);
+
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64" type: %#x)\n",
+                   i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (xen_host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            xen_host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        XEN_PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    XenHostPCIDevice *d = &s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int xen_pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+/*
+ * This function checks if an io_region overlaps an io_region from another
+ * device.  The io_region to check is provided with (addr, size and type)
+ * A callback can be provided and will be called for every region that is
+ * overlapped.
+ * The return value indicates if the region is overlappsed */
+struct CheckBarArgs {
+    XenPCIPassthroughState *s;
+    pcibus_t addr;
+    pcibus_t size;
+    uint8_t type;
+    bool rc;
+};
+static void xen_pt_check_bar_overlap(PCIBus *bus, PCIDevice *d, void *opaque)
+{
+    struct CheckBarArgs *arg = opaque;
+    XenPCIPassthroughState *s = arg->s;
+    uint8_t type = arg->type;
+    int i;
+
+    if (d->devfn == s->dev.devfn) {
+        return;
+    }
+
+    /* xxx: This ignores bridges. */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        const PCIIORegion *r = &d->io_regions[i];
+
+        if (!r->size) {
+            continue;
+        }
+        if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+            != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+            continue;
+        }
+
+        if (ranges_overlap(arg->addr, arg->size, r->addr, r->size)) {
+            XEN_PT_WARN(&s->dev,
+                        "Overlapped to device [%02x:%02x.%d] Region: %i"
+                        " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+                        pci_bus_num(bus), PCI_SLOT(d->devfn),
+                        PCI_FUNC(d->devfn), i, r->addr, r->size);
+            arg->rc = true;
+        }
+    }
+}
+
+static void xen_pt_region_update(XenPCIPassthroughState *s,
+                                 MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+    struct CheckBarArgs args = {
+        .s = s,
+        .addr = sec->offset_within_address_space,
+        .size = sec->size,
+        .rc = false,
+    };
+
+    bar = xen_pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    args.type = d->io_regions[bar].type;
+    pci_for_each_device(d->bus, pci_bus_num(d->bus),
+                        xen_pt_check_bar_overlap, &args);
+    if (args.rc) {
+        XEN_PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                    ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                    bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      XEN_PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(size + XC_PAGE_SIZE - 1),
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void xen_pt_begin(MemoryListener *l)
+{
+}
+
+static void xen_pt_commit(MemoryListener *l)
+{
+}
+
+static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, true);
+}
+
+static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, false);
+}
+
+static void xen_pt_region_nop(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_fns(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_global_fns(MemoryListener *l)
+{
+}
+
+static void xen_pt_eventfd_fns(MemoryListener *l, MemoryRegionSection *s,
+                               bool match_data, uint64_t data, int fd)
+{
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .begin = xen_pt_begin,
+    .commit = xen_pt_commit,
+    .region_add = xen_pt_region_add,
+    .region_nop = xen_pt_region_nop,
+    .region_del = xen_pt_region_del,
+    .log_start = xen_pt_log_fns,
+    .log_stop = xen_pt_log_fns,
+    .log_sync = xen_pt_log_fns,
+    .log_global_start = xen_pt_log_global_fns,
+    .log_global_stop = xen_pt_log_global_fns,
+    .eventfd_add = xen_pt_eventfd_fns,
+    .eventfd_del = xen_pt_eventfd_fns,
+    .priority = 10,
+};
+
+/* init */
+
+static int xen_pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        XEN_PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    XEN_PT_LOG(d, "Assigning real physical device %02x:%02x.%d"
+               " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    rc = xen_host_pci_device_get(&s->real_device, dom, bus, slot, func);
+    if (rc) {
+        XEN_PT_ERR(d, "Failed to \"open\" the real pci device. rc: %i\n", rc);
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device.is_virtfn;
+    if (s->is_virtfn) {
+        XEN_PT_LOG(d, "%04x:%02x:%02x.%d is a SR-IOV Virtual Function\n",
+                   s->real_device.domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (xen_host_pci_get_block(&s->real_device, 0, d->config,
+                               PCI_CONFIG_SPACE_SIZE) == -1) {
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    xen_pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        XEN_PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    machine_irq = s->real_device.irq;
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+                   machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        xen_host_pci_set_word(&s->real_device,
+                              PCI_COMMAND,
+                              pci_get_word(s->dev.config + PCI_COMMAND)
+                              | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        xen_pt_mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = xen_pt_pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                       e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
+                                  *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                                  | PCI_COMMAND_INTX_DISABLE);
+            xen_pt_mapped_machine_irq[machine_irq]--;
+
+            if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                               " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener, NULL);
+    XEN_PT_LOG(d, "Real physical device %02x:%02x.%d registered successfuly!\n",
+               bus, slot, func);
+
+    return 0;
+}
+
+static int xen_pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = xen_pt_pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
+                       " (machine irq: %i, rc: %d)"
+                       " But bravely continuing on..\n",
+                       'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        xen_pt_mapped_machine_irq[machine_irq]--;
+
+        if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                XEN_PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                           " But bravely continuing on..\n",
+                           machine_irq, rc);
+            }
+        }
+    }
+
+    xen_pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    xen_host_pci_device_put(&s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_pt_initfn;
+    k->exit = xen_pt_unregister_device;
+    k->config_read = xen_pt_pci_read_config;
+    k->config_write = xen_pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
new file mode 100644
index 0000000..f029841
--- /dev/null
+++ b/hw/xen_pt.h
@@ -0,0 +1,248 @@
+#ifndef XEN_PT_H
+#define XEN_PT_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "xen-host-pci-device.h"
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
+
+#ifdef XEN_PT_LOGGING_ENABLED
+#  define XEN_PT_LOG(d, _f, _a...)  xen_pt_log(d, "%s: " _f, __func__, ##_a)
+#  define XEN_PT_WARN(d, _f, _a...) \
+    xen_pt_log(d, "%s: Warning: "_f, __func__, ##_a)
+#else
+#  define XEN_PT_LOG(d, _f, _a...)
+#  define XEN_PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef XEN_PT_DEBUG_PCI_CONFIG_ACCESS
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len) \
+    xen_pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+               __func__, addr, val, len)
+#else
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define XEN_PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*xen_pt_conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*xen_pt_conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*xen_pt_conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define XEN_PT_BAR_ALLF 0xFFFFFFFF
+#define XEN_PT_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
+    XEN_PT_GRP_TYPE_EMU,            /* emul reg group */
+} XenPTRegisterGroupType;
+
+typedef enum {
+    XEN_PT_BAR_FLAG_MEM = 0,        /* Memory type BAR */
+    XEN_PT_BAR_FLAG_IO,             /* I/O type BAR */
+    XEN_PT_BAR_FLAG_UPPER,          /* upper 64bit BAR */
+    XEN_PT_BAR_FLAG_UNUSED,         /* unused BAR */
+} XenPTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    XenPTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    xen_pt_conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            xen_pt_conf_dword_write write;
+            xen_pt_conf_dword_read read;
+        } dw;
+        struct {
+            xen_pt_conf_word_write write;
+            xen_pt_conf_word_read read;
+        } w;
+        struct {
+            xen_pt_conf_byte_write write;
+            xen_pt_conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*xen_pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    XenPTRegisterGroupType grp_type;
+    uint8_t grp_size;
+    xen_pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_regs;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define XEN_PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    XenHostPCIDevice real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grps;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int xen_pt_config_init(XenPCIPassthroughState *s);
+void xen_pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int xen_pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t xen_pt_get_emul_size(XenPTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == XEN_PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, xen_pt_pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t xen_pt_pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    xen_host_pci_get_byte(&s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = xen_pt_pci_read_intx(s);
+
+    XEN_PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        XEN_PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+                   " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
new file mode 100644
index 0000000..64d22e8
--- /dev/null
+++ b/hw/xen_pt_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pt.h"
+
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5220cc..59f2323 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1191,3 +1191,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfD-0001Pi-Oh; Tue, 12 Jun 2012 15:05:47 +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 1SeSfC-0001P1-K0
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:46 +0000
Received: from [85.158.138.51:56991] by server-11.bemta-3.messagelabs.com id
	ED/C0-28329-9CA57DF4; Tue, 12 Jun 2012 15:05:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8053 invoked from network); 12 Jun 2012 15:05:45 -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;
	12 Jun 2012 15:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438604"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-6Y;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:15 +0100
Message-ID: <1339513523-1699-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are using this in our quirk lookup provided by patch
titled: Introduce Xen PCI Passthrough, PCI config space helpers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..649e6b3 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfD-0001Pi-Oh; Tue, 12 Jun 2012 15:05:47 +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 1SeSfC-0001P1-K0
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:46 +0000
Received: from [85.158.138.51:56991] by server-11.bemta-3.messagelabs.com id
	ED/C0-28329-9CA57DF4; Tue, 12 Jun 2012 15:05:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8053 invoked from network); 12 Jun 2012 15:05:45 -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;
	12 Jun 2012 15:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438604"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-6Y;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:15 +0100
Message-ID: <1339513523-1699-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are using this in our quirk lookup provided by patch
titled: Introduce Xen PCI Passthrough, PCI config space helpers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..649e6b3 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfF-0001QX-P7; Tue, 12 Jun 2012 15:05:49 +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 1SeSfD-0001P5-MO
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:47 +0000
Received: from [85.158.138.51:42931] by server-5.bemta-3.messagelabs.com id
	CF/AC-03598-ACA57DF4; Tue, 12 Jun 2012 15:05:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8116 invoked from network); 12 Jun 2012 15:05:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438605"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-9V;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:18 +0100
Message-ID: <1339513523-1699-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 4/9] pci.c: Add opaque argument to
	pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The purpose is to have a more generic pci_for_each_device by passing an extra
argument to the function called on every device.

This patch will be used in a next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci.c          |   11 +++++++----
 hw/pci.h          |    4 +++-
 hw/xen_platform.c |    8 ++++----
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index c1ebdde..eec106a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
 };
 
 static void pci_for_each_device_under_bus(PCIBus *bus,
-                                          void (*fn)(PCIBus *b, PCIDevice *d))
+                                          void (*fn)(PCIBus *b, PCIDevice *d,
+                                                     void *opaque),
+                                          void *opaque)
 {
     PCIDevice *d;
     int devfn;
@@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
     for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
         d = bus->devices[devfn];
         if (d) {
-            fn(bus, d);
+            fn(bus, d, opaque);
         }
     }
 }
 
 void pci_for_each_device(PCIBus *bus, int bus_num,
-                         void (*fn)(PCIBus *b, PCIDevice *d))
+                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
+                         void *opaque)
 {
     bus = pci_find_bus_nr(bus, bus_num);
 
     if (bus) {
-        pci_for_each_device_under_bus(bus, fn);
+        pci_for_each_device_under_bus(bus, fn, opaque);
     }
 }
 
diff --git a/hw/pci.h b/hw/pci.h
index c3cacce..ecf37fd 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
 PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
                                const char *default_devaddr);
 int pci_bus_num(PCIBus *s);
-void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
+void pci_for_each_device(PCIBus *bus, int bus_num,
+                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
+                         void *opaque);
 PCIBus *pci_find_root_bus(int domain);
 int pci_find_domain(const PCIBus *bus);
 PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0214f37..c1fe984 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 #define UNPLUG_ALL_NICS 2
 #define UNPLUG_AUX_IDE_DISKS 4
 
-static void unplug_nic(PCIBus *b, PCIDevice *d)
+static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_NETWORK_ETHERNET) {
@@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_nics(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_nic);
+    pci_for_each_device(bus, 0, unplug_nic, NULL);
 }
 
-static void unplug_disks(PCIBus *b, PCIDevice *d)
+static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_STORAGE_IDE) {
@@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_disks(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_disks);
+    pci_for_each_device(bus, 0, unplug_disks, NULL);
 }
 
 static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfF-0001QX-P7; Tue, 12 Jun 2012 15:05:49 +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 1SeSfD-0001P5-MO
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:47 +0000
Received: from [85.158.138.51:42931] by server-5.bemta-3.messagelabs.com id
	CF/AC-03598-ACA57DF4; Tue, 12 Jun 2012 15:05:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8116 invoked from network); 12 Jun 2012 15:05:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438605"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-9V;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:18 +0100
Message-ID: <1339513523-1699-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 4/9] pci.c: Add opaque argument to
	pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The purpose is to have a more generic pci_for_each_device by passing an extra
argument to the function called on every device.

This patch will be used in a next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci.c          |   11 +++++++----
 hw/pci.h          |    4 +++-
 hw/xen_platform.c |    8 ++++----
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index c1ebdde..eec106a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
 };
 
 static void pci_for_each_device_under_bus(PCIBus *bus,
-                                          void (*fn)(PCIBus *b, PCIDevice *d))
+                                          void (*fn)(PCIBus *b, PCIDevice *d,
+                                                     void *opaque),
+                                          void *opaque)
 {
     PCIDevice *d;
     int devfn;
@@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
     for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
         d = bus->devices[devfn];
         if (d) {
-            fn(bus, d);
+            fn(bus, d, opaque);
         }
     }
 }
 
 void pci_for_each_device(PCIBus *bus, int bus_num,
-                         void (*fn)(PCIBus *b, PCIDevice *d))
+                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
+                         void *opaque)
 {
     bus = pci_find_bus_nr(bus, bus_num);
 
     if (bus) {
-        pci_for_each_device_under_bus(bus, fn);
+        pci_for_each_device_under_bus(bus, fn, opaque);
     }
 }
 
diff --git a/hw/pci.h b/hw/pci.h
index c3cacce..ecf37fd 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
 PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
                                const char *default_devaddr);
 int pci_bus_num(PCIBus *s);
-void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
+void pci_for_each_device(PCIBus *bus, int bus_num,
+                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
+                         void *opaque);
 PCIBus *pci_find_root_bus(int domain);
 int pci_find_domain(const PCIBus *bus);
 PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0214f37..c1fe984 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 #define UNPLUG_ALL_NICS 2
 #define UNPLUG_AUX_IDE_DISKS 4
 
-static void unplug_nic(PCIBus *b, PCIDevice *d)
+static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_NETWORK_ETHERNET) {
@@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_nics(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_nic);
+    pci_for_each_device(bus, 0, unplug_nic, NULL);
 }
 
-static void unplug_disks(PCIBus *b, PCIDevice *d)
+static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_STORAGE_IDE) {
@@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_disks(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_disks);
+    pci_for_each_device(bus, 0, unplug_disks, NULL);
 }
 
 static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfI-0001Rz-8N; Tue, 12 Jun 2012 15:05:52 +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 1SeSfG-0001Qc-Fr
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:50 +0000
Received: from [85.158.138.51:57387] by server-2.bemta-3.messagelabs.com id
	FC/F3-16299-DCA57DF4; Tue, 12 Jun 2012 15:05:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339513546!24031982!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8262 invoked from network); 12 Jun 2012 15:05:47 -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;
	12 Jun 2012 15:05:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438610"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-D0;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:23 +0100
Message-ID: <1339513523-1699-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Shan Haitao <haitao.shan@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V12 9/9] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    2 +-
 hw/xen_pt.c             |   31 +++-
 hw/xen_pt.h             |   51 ++++
 hw/xen_pt_config_init.c |  471 +++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c         |  620 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 1173 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen_pt_msi.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index e361a92..d364c37 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,7 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 6fad7ff..458b8cc 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(xen_pt_msi_setup, xen_pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(xen_pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -534,7 +548,15 @@ static void xen_pt_region_update(XenPCIPassthroughState *s,
     };
 
     bar = xen_pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = xen_pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -767,6 +789,13 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        xen_pt_msi_disable(s);
+    }
+    if (s->msix) {
+        xen_pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         xen_pt_mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 4bb8cb6..6b59564 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -160,6 +160,36 @@ typedef struct XenPTRegGroup {
 
 
 #define XEN_PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -172,6 +202,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -247,4 +280,22 @@ static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int xen_pt_msi_setup(XenPCIPassthroughState *s);
+int xen_pt_msi_update(XenPCIPassthroughState *d);
+void xen_pt_msi_disable(XenPCIPassthroughState *s);
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void xen_pt_msix_delete(XenPCIPassthroughState *s);
+int xen_pt_msix_update(XenPCIPassthroughState *s);
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void xen_pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 1d97876..00eb3d9 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1022,6 +1022,410 @@ static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool xen_pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int xen_pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        XEN_PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msgctrl_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t raw_val;
+
+    /* Currently no support for multi-vector */
+    if (*val & PCI_MSI_FLAGS_QSIZE) {
+        XEN_PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *val);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    raw_val = *val;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (raw_val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            XEN_PT_LOG(&s->dev, "setup MSI\n");
+            if (xen_pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (xen_pt_msi_update(s)) {
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *val &= ~PCI_MSI_FLAGS_ENABLE;
+    *val |= raw_val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int xen_pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = XEN_PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int xen_pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (xen_pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = XEN_PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int xen_pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int xen_pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        XEN_PT_ERR(&s->dev,
+                   "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!xen_pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        XEN_PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msi[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = xen_pt_msgctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgaddr64_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int xen_pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        XEN_PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                     XenPTReg *cfg_entry, uint16_t *val,
+                                     uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*val & PCI_MSIX_FLAGS_ENABLE)
+        && !(*val & PCI_MSIX_FLAGS_MASKALL)) {
+        xen_pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        XEN_PT_LOG(&s->dev, "%s MSI-X\n",
+                   s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msix[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = xen_pt_msixctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1115,6 +1519,49 @@ static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int xen_pt_msi_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int xen_pt_msix_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = xen_pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid xen_pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
     /* Header Type0 reg group */
@@ -1155,6 +1602,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .grp_size   = 0x04,
         .size_init  = xen_pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_msi_size_init,
+        .emu_regs = xen_pt_emu_reg_msi,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1199,6 +1654,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_pcie_size_init,
         .emu_regs = xen_pt_emu_reg_pcie,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = xen_pt_msix_size_init,
+        .emu_regs = xen_pt_emu_reg_msix,
+    },
     {
         .grp_size = 0,
     },
@@ -1384,6 +1847,14 @@ void xen_pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        xen_pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pt_msi.c b/hw/xen_pt_msi.c
new file mode 100644
index 0000000..2299cc7
--- /dev/null
+++ b/hw/xen_pt_msi.c
@@ -0,0 +1,620 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "apic-msidef.h"
+
+
+#define XEN_PT_AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define XEN_PT_GFLAGS_SHIFT_DEST_ID        0
+#define XEN_PT_GFLAGS_SHIFT_RH             8
+#define XEN_PT_GFLAGS_SHIFT_DM             9
+#define XEN_PT_GFLAGSSHIFT_DELIV_MODE     12
+#define XEN_PT_GFLAGSSHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
+        | (dm << XEN_PT_GFLAGS_SHIFT_DM)
+        | (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
+        | (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    xen_host_pci_get_word(&s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    xen_host_pci_set_word(&s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                          uint64_t addr,
+                          uint32_t data,
+                          int *ppirq,
+                          bool is_msix,
+                          int msix_entry,
+                          bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = XEN_PT_UNASSIGNED_PIRQ;
+        } else {
+            XEN_PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                       " (vec: %#x, entry: %#x)\n",
+                       *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, XEN_PT_AUTO_ASSIGN,
+                                     ppirq, PCI_DEVFN(s->real_device.dev,
+                                                      s->real_device.func),
+                                     s->real_device.bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            XEN_PT_ERR(&s->dev,
+                       "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                       is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
+               " (entry: %#x)\n",
+               is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        XEN_PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+                   is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                       is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            XEN_PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                       is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    XEN_PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+                   is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int xen_pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        XEN_PT_ERR(&s->dev,
+                   "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        XEN_PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    XEN_PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int xen_pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void xen_pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    xen_pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int xen_pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        xen_pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void xen_pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = XEN_PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != XEN_PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n",
+                           entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return xen_pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
+                       " already enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            xen_pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    XenHostPCIDevice *hd = &s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = xen_host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        XEN_PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device.io_regions[bar_index].base_addr;
+    XEN_PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    XEN_PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+               table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    XEN_PT_LOG(d, "mapping physical MSI-X table to %p\n",
+               msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void xen_pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        XEN_PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+                   msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfI-0001Rz-8N; Tue, 12 Jun 2012 15:05:52 +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 1SeSfG-0001Qc-Fr
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:50 +0000
Received: from [85.158.138.51:57387] by server-2.bemta-3.messagelabs.com id
	FC/F3-16299-DCA57DF4; Tue, 12 Jun 2012 15:05:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339513546!24031982!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8262 invoked from network); 12 Jun 2012 15:05:47 -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;
	12 Jun 2012 15:05:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438610"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:43 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-D0;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:23 +0100
Message-ID: <1339513523-1699-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Shan Haitao <haitao.shan@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V12 9/9] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    2 +-
 hw/xen_pt.c             |   31 +++-
 hw/xen_pt.h             |   51 ++++
 hw/xen_pt_config_init.c |  471 +++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c         |  620 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 1173 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen_pt_msi.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index e361a92..d364c37 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,7 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 6fad7ff..458b8cc 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(xen_pt_msi_setup, xen_pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(xen_pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -534,7 +548,15 @@ static void xen_pt_region_update(XenPCIPassthroughState *s,
     };
 
     bar = xen_pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = xen_pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -767,6 +789,13 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        xen_pt_msi_disable(s);
+    }
+    if (s->msix) {
+        xen_pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         xen_pt_mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 4bb8cb6..6b59564 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -160,6 +160,36 @@ typedef struct XenPTRegGroup {
 
 
 #define XEN_PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -172,6 +202,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -247,4 +280,22 @@ static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int xen_pt_msi_setup(XenPCIPassthroughState *s);
+int xen_pt_msi_update(XenPCIPassthroughState *d);
+void xen_pt_msi_disable(XenPCIPassthroughState *s);
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void xen_pt_msix_delete(XenPCIPassthroughState *s);
+int xen_pt_msix_update(XenPCIPassthroughState *s);
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void xen_pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 1d97876..00eb3d9 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1022,6 +1022,410 @@ static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool xen_pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int xen_pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        XEN_PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msgctrl_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t raw_val;
+
+    /* Currently no support for multi-vector */
+    if (*val & PCI_MSI_FLAGS_QSIZE) {
+        XEN_PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *val);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    raw_val = *val;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (raw_val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            XEN_PT_LOG(&s->dev, "setup MSI\n");
+            if (xen_pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (xen_pt_msi_update(s)) {
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *val &= ~PCI_MSI_FLAGS_ENABLE;
+    *val |= raw_val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int xen_pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = XEN_PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int xen_pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (xen_pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = XEN_PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int xen_pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int xen_pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        XEN_PT_ERR(&s->dev,
+                   "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!xen_pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        XEN_PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msi[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = xen_pt_msgctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgaddr64_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int xen_pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        XEN_PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                     XenPTReg *cfg_entry, uint16_t *val,
+                                     uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*val & PCI_MSIX_FLAGS_ENABLE)
+        && !(*val & PCI_MSIX_FLAGS_MASKALL)) {
+        xen_pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        XEN_PT_LOG(&s->dev, "%s MSI-X\n",
+                   s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msix[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = xen_pt_msixctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1115,6 +1519,49 @@ static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int xen_pt_msi_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int xen_pt_msix_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = xen_pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid xen_pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
     /* Header Type0 reg group */
@@ -1155,6 +1602,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .grp_size   = 0x04,
         .size_init  = xen_pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_msi_size_init,
+        .emu_regs = xen_pt_emu_reg_msi,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1199,6 +1654,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_pcie_size_init,
         .emu_regs = xen_pt_emu_reg_pcie,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = xen_pt_msix_size_init,
+        .emu_regs = xen_pt_emu_reg_msix,
+    },
     {
         .grp_size = 0,
     },
@@ -1384,6 +1847,14 @@ void xen_pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        xen_pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pt_msi.c b/hw/xen_pt_msi.c
new file mode 100644
index 0000000..2299cc7
--- /dev/null
+++ b/hw/xen_pt_msi.c
@@ -0,0 +1,620 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "apic-msidef.h"
+
+
+#define XEN_PT_AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define XEN_PT_GFLAGS_SHIFT_DEST_ID        0
+#define XEN_PT_GFLAGS_SHIFT_RH             8
+#define XEN_PT_GFLAGS_SHIFT_DM             9
+#define XEN_PT_GFLAGSSHIFT_DELIV_MODE     12
+#define XEN_PT_GFLAGSSHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
+        | (dm << XEN_PT_GFLAGS_SHIFT_DM)
+        | (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
+        | (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    xen_host_pci_get_word(&s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    xen_host_pci_set_word(&s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                          uint64_t addr,
+                          uint32_t data,
+                          int *ppirq,
+                          bool is_msix,
+                          int msix_entry,
+                          bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = XEN_PT_UNASSIGNED_PIRQ;
+        } else {
+            XEN_PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                       " (vec: %#x, entry: %#x)\n",
+                       *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, XEN_PT_AUTO_ASSIGN,
+                                     ppirq, PCI_DEVFN(s->real_device.dev,
+                                                      s->real_device.func),
+                                     s->real_device.bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            XEN_PT_ERR(&s->dev,
+                       "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                       is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
+               " (entry: %#x)\n",
+               is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        XEN_PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+                   is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                       is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            XEN_PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                       is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    XEN_PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+                   is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int xen_pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        XEN_PT_ERR(&s->dev,
+                   "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        XEN_PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    XEN_PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int xen_pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void xen_pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    xen_pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int xen_pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        xen_pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void xen_pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = XEN_PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != XEN_PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n",
+                           entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return xen_pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
+                       " already enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            xen_pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    XenHostPCIDevice *hd = &s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = xen_host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        XEN_PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device.io_regions[bar_index].base_addr;
+    XEN_PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    XEN_PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+               table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    XEN_PT_LOG(d, "mapping physical MSI-X table to %p\n",
+               msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void xen_pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        XEN_PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+                   msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfD-0001PQ-Ax; Tue, 12 Jun 2012 15:05:47 +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 1SeSfC-0001P0-AR
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:46 +0000
Received: from [85.158.138.51:42811] by server-6.bemta-3.messagelabs.com id
	E4/72-05063-9CA57DF4; Tue, 12 Jun 2012 15:05:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7992 invoked from network); 12 Jun 2012 15:05:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438603"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-76;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:16 +0100
Message-ID: <1339513523-1699-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 2/9] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 configure |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index dd0d2b3..d9ecfe5 100755
--- a/configure
+++ b/configure
@@ -137,6 +137,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -685,6 +686,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1032,6 +1037,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1508,6 +1515,25 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes" &&
+    test "$xen_ctrl_version" -ge 340; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      if test "$xen_ctrl_version" -lt 340; then
+        echo "ERROR: This feature does not work with Xen 3.3"
+      fi
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3698,6 +3724,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfD-0001PQ-Ax; Tue, 12 Jun 2012 15:05:47 +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 1SeSfC-0001P0-AR
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:46 +0000
Received: from [85.158.138.51:42811] by server-6.bemta-3.messagelabs.com id
	E4/72-05063-9CA57DF4; Tue, 12 Jun 2012 15:05:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339513543!32172481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7992 invoked from network); 12 Jun 2012 15:05:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438603"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-76;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:16 +0100
Message-ID: <1339513523-1699-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 2/9] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 configure |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index dd0d2b3..d9ecfe5 100755
--- a/configure
+++ b/configure
@@ -137,6 +137,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -685,6 +686,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1032,6 +1037,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1508,6 +1515,25 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes" &&
+    test "$xen_ctrl_version" -ge 340; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      if test "$xen_ctrl_version" -lt 340; then
+        echo "ERROR: This feature does not work with Xen 3.3"
+      fi
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3698,6 +3724,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:06:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeSfG-0001Qo-7B; Tue, 12 Jun 2012 15:05:50 +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 1SeSfE-0001PY-26
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:48 +0000
Received: from [85.158.138.51:43003] by server-9.bemta-3.messagelabs.com id
	59/22-15054-BCA57DF4; Tue, 12 Jun 2012 15:05:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513543!32114831!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30291 invoked from network); 12 Jun 2012 15:05:46 -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;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772979"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-8r;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:17 +0100
Message-ID: <1339513523-1699-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 3/9] Introduce XenHostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/i386/Makefile.objs    |    1 +
 hw/xen-host-pci-device.c |  396 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen-host-pci-device.h |   55 +++++++
 3 files changed, 452 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index d43f1df..b719d8e 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -7,6 +7,7 @@ obj-y += debugcon.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
new file mode 100644
index 0000000..e7ff680
--- /dev/null
+++ b/hw/xen-host-pci-device.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "xen-host-pci-device.h"
+
+#define XEN_HOST_PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+#ifdef XEN_HOST_PCI_DEVICE_DEBUG
+#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
+#else
+#  define XEN_HOST_PCI_LOG(f, a...) (void)0
+#endif
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_MEM_64       0x00100000
+
+static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
+                                   const char *name, char *buf, ssize_t size)
+{
+    int rc;
+
+    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
+                  d->domain, d->bus, d->dev, d->func, name);
+
+    if (rc >= size || rc < 0) {
+        /* The ouput is truncated or an other error is encountered */
+        return -ENODEV;
+    }
+    return 0;
+}
+
+
+/* This size should be enough to read the first 7 lines of a ressource file */
+#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
+static int xen_host_pci_get_resource(XenHostPCIDevice *d)
+{
+    int i, rc, fd;
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+    unsigned long long start, end, flags, size;
+    char *endptr, *s;
+    uint8_t type;
+
+    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    rc = 0;
+
+    s = buf;
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        type = 0;
+
+        start = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        end = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        flags = strtoll(s, &endptr, 16);
+        if (*endptr != '\n' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (flags & IORESOURCE_IO) {
+            type |= XEN_HOST_PCI_REGION_TYPE_IO;
+        }
+        if (flags & IORESOURCE_MEM) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
+        }
+        if (flags & IORESOURCE_PREFETCH) {
+            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
+        }
+        if (flags & IORESOURCE_MEM_64) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].type = type;
+            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.type = type;
+            d->rom.bus_flags = flags & IORESOURCE_BITS;
+        }
+    }
+    if (i != PCI_NUM_REGIONS) {
+        /* Invalid format or input to short */
+        rc = -ENODEV;
+    }
+
+out:
+    close(fd);
+    return rc;
+}
+
+/* This size should be enough to read a long from a file */
+#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 22
+static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
+                                  unsigned int *pvalue, int base)
+{
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
+    int fd, rc;
+    unsigned long value;
+    char *endptr;
+
+    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    value = strtol(buf, &endptr, base);
+    if (endptr == buf || *endptr != '\n') {
+        rc = -1;
+    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
+        rc = -errno;
+    } else {
+        rc = 0;
+        *pvalue = value;
+    }
+out:
+    close(fd);
+    return rc;
+}
+
+static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 16);
+}
+
+static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 10);
+}
+
+static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
+        return false;
+    }
+    return !stat(path, &buf);
+}
+
+static int xen_host_pci_config_open(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    int rc;
+
+    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    d->config_fd = open(path, O_RDWR);
+    if (d->config_fd < 0) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_read(XenHostPCIDevice *d,
+                                    int pos, void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pread(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_write(XenHostPCIDevice *d,
+                                     int pos, const void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pwrite(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
+    if (!rc) {
+        *p = buf;
+    }
+    return rc;
+}
+
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
+    if (!rc) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
+    if (!rc) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_read(d, pos, buf, len);
+}
+
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
+{
+    return xen_host_pci_config_write(d, pos, &data, 1);
+}
+
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return xen_host_pci_config_write(d, pos, &data, 2);
+}
+
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return xen_host_pci_config_write(d, pos, &data, 4);
+}
+
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_write(d, pos, buf, len);
+}
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (xen_host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return -1;
+}
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func)
+{
+    unsigned int v;
+    int rc = 0;
+
+    d->config_fd = -1;
+    d->domain = domain;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    rc = xen_host_pci_config_open(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_resource(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
+    if (rc) {
+        goto error;
+    }
+    d->vendor_id = v;
+    rc = xen_host_pci_get_hex_value(d, "device", &v);
+    if (rc) {
+        goto error;
+    }
+    d->device_id = v;
+    rc = xen_host_pci_get_dec_value(d, "irq", &v);
+    if (rc) {
+        goto error;
+    }
+    d->irq = v;
+    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+
+    return 0;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+    return rc;
+}
+
+void xen_host_pci_device_put(XenHostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+}
diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
new file mode 100644
index 0000000..0079dac
--- /dev/null
+++ b/hw/xen-host-pci-device.h
@@ -0,0 +1,55 @@
+#ifndef XEN_HOST_PCI_DEVICE_H
+#define XEN_HOST_PCI_DEVICE_H
+
+#include "pci.h"
+
+enum {
+    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
+    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
+    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
+    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
+};
+
+typedef struct XenHostPCIIORegion {
+    pcibus_t base_addr;
+    pcibus_t size;
+    uint8_t type;
+    uint8_t bus_flags; /* Bus-specific bits */
+} XenHostPCIIORegion;
+
+typedef struct XenHostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    int irq;
+
+    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    XenHostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} XenHostPCIDevice;
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func);
+void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
+
+#endif /* !XEN_HOST_PCI_DEVICE_H_ */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:06:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeSfG-0001Qo-7B; Tue, 12 Jun 2012 15:05:50 +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 1SeSfE-0001PY-26
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:48 +0000
Received: from [85.158.138.51:43003] by server-9.bemta-3.messagelabs.com id
	59/22-15054-BCA57DF4; Tue, 12 Jun 2012 15:05:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513543!32114831!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30291 invoked from network); 12 Jun 2012 15:05:46 -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;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772979"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-8r;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:17 +0100
Message-ID: <1339513523-1699-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 3/9] Introduce XenHostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/i386/Makefile.objs    |    1 +
 hw/xen-host-pci-device.c |  396 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen-host-pci-device.h |   55 +++++++
 3 files changed, 452 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index d43f1df..b719d8e 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -7,6 +7,7 @@ obj-y += debugcon.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
new file mode 100644
index 0000000..e7ff680
--- /dev/null
+++ b/hw/xen-host-pci-device.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "xen-host-pci-device.h"
+
+#define XEN_HOST_PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+#ifdef XEN_HOST_PCI_DEVICE_DEBUG
+#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
+#else
+#  define XEN_HOST_PCI_LOG(f, a...) (void)0
+#endif
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_MEM_64       0x00100000
+
+static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
+                                   const char *name, char *buf, ssize_t size)
+{
+    int rc;
+
+    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
+                  d->domain, d->bus, d->dev, d->func, name);
+
+    if (rc >= size || rc < 0) {
+        /* The ouput is truncated or an other error is encountered */
+        return -ENODEV;
+    }
+    return 0;
+}
+
+
+/* This size should be enough to read the first 7 lines of a ressource file */
+#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
+static int xen_host_pci_get_resource(XenHostPCIDevice *d)
+{
+    int i, rc, fd;
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+    unsigned long long start, end, flags, size;
+    char *endptr, *s;
+    uint8_t type;
+
+    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    rc = 0;
+
+    s = buf;
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        type = 0;
+
+        start = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        end = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        flags = strtoll(s, &endptr, 16);
+        if (*endptr != '\n' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (flags & IORESOURCE_IO) {
+            type |= XEN_HOST_PCI_REGION_TYPE_IO;
+        }
+        if (flags & IORESOURCE_MEM) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
+        }
+        if (flags & IORESOURCE_PREFETCH) {
+            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
+        }
+        if (flags & IORESOURCE_MEM_64) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].type = type;
+            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.type = type;
+            d->rom.bus_flags = flags & IORESOURCE_BITS;
+        }
+    }
+    if (i != PCI_NUM_REGIONS) {
+        /* Invalid format or input to short */
+        rc = -ENODEV;
+    }
+
+out:
+    close(fd);
+    return rc;
+}
+
+/* This size should be enough to read a long from a file */
+#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 22
+static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
+                                  unsigned int *pvalue, int base)
+{
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
+    int fd, rc;
+    unsigned long value;
+    char *endptr;
+
+    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    value = strtol(buf, &endptr, base);
+    if (endptr == buf || *endptr != '\n') {
+        rc = -1;
+    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
+        rc = -errno;
+    } else {
+        rc = 0;
+        *pvalue = value;
+    }
+out:
+    close(fd);
+    return rc;
+}
+
+static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 16);
+}
+
+static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 10);
+}
+
+static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
+        return false;
+    }
+    return !stat(path, &buf);
+}
+
+static int xen_host_pci_config_open(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    int rc;
+
+    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    d->config_fd = open(path, O_RDWR);
+    if (d->config_fd < 0) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_read(XenHostPCIDevice *d,
+                                    int pos, void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pread(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_write(XenHostPCIDevice *d,
+                                     int pos, const void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pwrite(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
+    if (!rc) {
+        *p = buf;
+    }
+    return rc;
+}
+
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
+    if (!rc) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
+    if (!rc) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_read(d, pos, buf, len);
+}
+
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
+{
+    return xen_host_pci_config_write(d, pos, &data, 1);
+}
+
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return xen_host_pci_config_write(d, pos, &data, 2);
+}
+
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return xen_host_pci_config_write(d, pos, &data, 4);
+}
+
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_write(d, pos, buf, len);
+}
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (xen_host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return -1;
+}
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func)
+{
+    unsigned int v;
+    int rc = 0;
+
+    d->config_fd = -1;
+    d->domain = domain;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    rc = xen_host_pci_config_open(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_resource(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
+    if (rc) {
+        goto error;
+    }
+    d->vendor_id = v;
+    rc = xen_host_pci_get_hex_value(d, "device", &v);
+    if (rc) {
+        goto error;
+    }
+    d->device_id = v;
+    rc = xen_host_pci_get_dec_value(d, "irq", &v);
+    if (rc) {
+        goto error;
+    }
+    d->irq = v;
+    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+
+    return 0;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+    return rc;
+}
+
+void xen_host_pci_device_put(XenHostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+}
diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
new file mode 100644
index 0000000..0079dac
--- /dev/null
+++ b/hw/xen-host-pci-device.h
@@ -0,0 +1,55 @@
+#ifndef XEN_HOST_PCI_DEVICE_H
+#define XEN_HOST_PCI_DEVICE_H
+
+#include "pci.h"
+
+enum {
+    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
+    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
+    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
+    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
+};
+
+typedef struct XenHostPCIIORegion {
+    pcibus_t base_addr;
+    pcibus_t size;
+    uint8_t type;
+    uint8_t bus_flags; /* Bus-specific bits */
+} XenHostPCIIORegion;
+
+typedef struct XenHostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    int irq;
+
+    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    XenHostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} XenHostPCIDevice;
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func);
+void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
+
+#endif /* !XEN_HOST_PCI_DEVICE_H_ */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfC-0001PJ-UU; Tue, 12 Jun 2012 15:05:46 +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 1SeSfC-0001Oy-6j
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:46 +0000
Received: from [85.158.138.51:42798] by server-7.bemta-3.messagelabs.com id
	1E/85-01983-9CA57DF4; Tue, 12 Jun 2012 15:05:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513543!32114831!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30148 invoked from network); 12 Jun 2012 15:05:44 -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;
	12 Jun 2012 15:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772978"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-CM;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:22 +0100
Message-ID: <1339513523-1699-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 8/9] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 31 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..6e2eb71
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,30 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 5fbf01c..60552df 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -23,19 +23,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define SYNC_FROM_VAPIC                 0x1
 #define SYNC_TO_VAPIC                   0x2
 #define SYNC_ISR_IRR_TO_VAPIC           0x4
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfC-0001PJ-UU; Tue, 12 Jun 2012 15:05:46 +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 1SeSfC-0001Oy-6j
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:46 +0000
Received: from [85.158.138.51:42798] by server-7.bemta-3.messagelabs.com id
	1E/85-01983-9CA57DF4; Tue, 12 Jun 2012 15:05:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513543!32114831!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30148 invoked from network); 12 Jun 2012 15:05:44 -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;
	12 Jun 2012 15:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772978"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-CM;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:22 +0100
Message-ID: <1339513523-1699-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 8/9] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 31 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..6e2eb71
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,30 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 5fbf01c..60552df 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -23,19 +23,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define SYNC_FROM_VAPIC                 0x1
 #define SYNC_TO_VAPIC                   0x2
 #define SYNC_ISR_IRR_TO_VAPIC           0x4
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfQ-0001VE-FP; Tue, 12 Jun 2012 15:06:00 +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 1SeSfP-0001Uk-1T
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:59 +0000
Received: from [85.158.143.99:6493] by server-1.bemta-4.messagelabs.com id
	19/AC-24392-6DA57DF4; Tue, 12 Jun 2012 15:05:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339513545!22713083!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23260 invoked from network); 12 Jun 2012 15:05:46 -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;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438607"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-5i;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:14 +0100
Message-ID: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.

Please ack the generic bits so that Stefano can send a pull request: patches 1,
2, 4 and 5.

Thanks,


Changes since the last time:
  - new patch to export pci_parse_devaddr, so it can be used to parse a BDF in
    xen_pt.
    # the other option would be to introduce a new function name in pci.c or to
    # copy/paste the function.
  - few more comment in XenHostPCIDevice about the buffer size used.


Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_SFP_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce XenHostPCIDevice to access a pci device on the host.
  pci.c: Add opaque argument to pci_for_each_device.
  Revert "pci: don't export an internal function"
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

 configure                |   29 +
 hw/apic-msidef.h         |   30 +
 hw/apic.c                |   11 +-
 hw/i386/Makefile.objs    |    2 +
 hw/pci.c                 |   13 +-
 hw/pci.h                 |    6 +-
 hw/pci_ids.h             |    1 +
 hw/xen-host-pci-device.c |  396 ++++++++++
 hw/xen-host-pci-device.h |   55 ++
 hw/xen_common.h          |    3 +
 hw/xen_platform.c        |    8 +-
 hw/xen_pt.c              |  854 +++++++++++++++++++++
 hw/xen_pt.h              |  301 ++++++++
 hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c          |  620 +++++++++++++++
 xen-all.c                |   12 +
 16 files changed, 4190 insertions(+), 20 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c
 create mode 100644 hw/xen_pt_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSfQ-0001VE-FP; Tue, 12 Jun 2012 15:06:00 +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 1SeSfP-0001Uk-1T
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:59 +0000
Received: from [85.158.143.99:6493] by server-1.bemta-4.messagelabs.com id
	19/AC-24392-6DA57DF4; Tue, 12 Jun 2012 15:05:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339513545!22713083!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23260 invoked from network); 12 Jun 2012 15:05:46 -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;
	12 Jun 2012 15:05:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198438607"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:42 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-5i;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:14 +0100
Message-ID: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.

Please ack the generic bits so that Stefano can send a pull request: patches 1,
2, 4 and 5.

Thanks,


Changes since the last time:
  - new patch to export pci_parse_devaddr, so it can be used to parse a BDF in
    xen_pt.
    # the other option would be to introduce a new function name in pci.c or to
    # copy/paste the function.
  - few more comment in XenHostPCIDevice about the buffer size used.


Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_SFP_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce XenHostPCIDevice to access a pci device on the host.
  pci.c: Add opaque argument to pci_for_each_device.
  Revert "pci: don't export an internal function"
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

 configure                |   29 +
 hw/apic-msidef.h         |   30 +
 hw/apic.c                |   11 +-
 hw/i386/Makefile.objs    |    2 +
 hw/pci.c                 |   13 +-
 hw/pci.h                 |    6 +-
 hw/pci_ids.h             |    1 +
 hw/xen-host-pci-device.c |  396 ++++++++++
 hw/xen-host-pci-device.h |   55 ++
 hw/xen_common.h          |    3 +
 hw/xen_platform.c        |    8 +-
 hw/xen_pt.c              |  854 +++++++++++++++++++++
 hw/xen_pt.h              |  301 ++++++++
 hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c          |  620 +++++++++++++++
 xen-all.c                |   12 +
 16 files changed, 4190 insertions(+), 20 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c
 create mode 100644 hw/xen_pt_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:06:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:06: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 1SeSfF-0001QL-B2; Tue, 12 Jun 2012 15:05:49 +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 1SeSfD-0001P5-3H
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:47 +0000
Received: from [85.158.138.51:42910] by server-5.bemta-3.messagelabs.com id
	CB/AC-03598-ACA57DF4; Tue, 12 Jun 2012 15:05:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513543!32114831!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30227 invoked from network); 12 Jun 2012 15:05:45 -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;
	12 Jun 2012 15:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772977"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-A5;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:19 +0100
Message-ID: <1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an internal
	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

This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.

This function is used by a later patch to parse the BDF of the device to
passthrough.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |    2 +-
 hw/pci.h |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index eec106a..5bddf7a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -479,7 +479,7 @@ static void pci_set_default_subsystem_id(PCIDevice *pci_dev)
  * Parse [[<domain>:]<bus>:]<slot>, return -1 on error if funcp == NULL
  *       [[<domain>:]<bus>:]<slot>.<func>, return -1 on error
  */
-static int pci_parse_devaddr(const char *addr, int *domp, int *busp,
+int pci_parse_devaddr(const char *addr, int *domp, int *busp,
                       unsigned int *slotp, unsigned int *funcp)
 {
     const char *p;
diff --git a/hw/pci.h b/hw/pci.h
index ecf37fd..b169c0b 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -321,6 +321,8 @@ PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
 int pci_qdev_find_device(const char *id, PCIDevice **pdev);
 PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr);
 
+int pci_parse_devaddr(const char *addr, int *domp, int *busp,
+                      unsigned int *slotp, unsigned int *funcp);
 int pci_read_devaddr(Monitor *mon, const char *addr, int *domp, int *busp,
                      unsigned *slotp);
 
-- 
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 Jun 12 15:06:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:06: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 1SeSfF-0001QL-B2; Tue, 12 Jun 2012 15:05:49 +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 1SeSfD-0001P5-3H
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:05:47 +0000
Received: from [85.158.138.51:42910] by server-5.bemta-3.messagelabs.com id
	CB/AC-03598-ACA57DF4; Tue, 12 Jun 2012 15:05:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513543!32114831!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA0MTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30227 invoked from network); 12 Jun 2012 15:05:45 -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;
	12 Jun 2012 15:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="27772977"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 11:05:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 11:05:43 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SeSf8-0003OM-A5;
	Tue, 12 Jun 2012 16:05:42 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 12 Jun 2012 16:05:19 +0100
Message-ID: <1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an internal
	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

This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.

This function is used by a later patch to parse the BDF of the device to
passthrough.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |    2 +-
 hw/pci.h |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index eec106a..5bddf7a 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -479,7 +479,7 @@ static void pci_set_default_subsystem_id(PCIDevice *pci_dev)
  * Parse [[<domain>:]<bus>:]<slot>, return -1 on error if funcp == NULL
  *       [[<domain>:]<bus>:]<slot>.<func>, return -1 on error
  */
-static int pci_parse_devaddr(const char *addr, int *domp, int *busp,
+int pci_parse_devaddr(const char *addr, int *domp, int *busp,
                       unsigned int *slotp, unsigned int *funcp)
 {
     const char *p;
diff --git a/hw/pci.h b/hw/pci.h
index ecf37fd..b169c0b 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -321,6 +321,8 @@ PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
 int pci_qdev_find_device(const char *id, PCIDevice **pdev);
 PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr);
 
+int pci_parse_devaddr(const char *addr, int *domp, int *busp,
+                      unsigned int *slotp, unsigned int *funcp);
 int pci_read_devaddr(Monitor *mon, const char *addr, int *domp, int *busp,
                      unsigned *slotp);
 
-- 
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 Jun 12 15:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSmI-0002zr-Kr; Tue, 12 Jun 2012 15:13:06 +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 1SeSmH-0002zm-S9
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 15:13:05 +0000
Received: from [85.158.138.51:41308] by server-9.bemta-3.messagelabs.com id
	2B/A6-15054-08C57DF4; Tue, 12 Jun 2012 15:13:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513984!32116459!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3680 invoked from network); 12 Jun 2012 15:13:04 -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 Jun 2012 15:13:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 16:13:03 +0100
Message-Id: <4FD778C802000078000897EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 16:13:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
In-Reply-To: <4FD72FE4.80009@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.06.12 at 14:02, Wei Wang <wei.wang2@amd.com> wrote:
> I had attached a revised patch, please check it.

While the patch technically looks better now, you didn't eliminate
my objections to the approach you take, nor did you comment on
the proposed alternative.

A fundamental problem is that your IOMMUs show up as a "normal"
PCI devices, breaking the separation between what is being
managed by the hypervisor vs by the Dom0 kernel. (This even
allows something as odd as passing through an IOMMU to a
DomU, which would clearly upset the hypervisor.)

> I found that the following Linux commit triggers this issue. It has been 
> included into 3.4 pv_ops.
> 
> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>    Author: Eric W. Biederman <ebiederm@xmission.com>
>    Date:   Mon Oct 17 11:46:06 2011 -0700
> 
>    PCI: msi: Disable msi interrupts when we initialize a pci device "

Thanks for locating this. As it stands, it is incomplete though
anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
it won't have a means to suppress the "screaming" interrupts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSmI-0002zr-Kr; Tue, 12 Jun 2012 15:13:06 +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 1SeSmH-0002zm-S9
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 15:13:05 +0000
Received: from [85.158.138.51:41308] by server-9.bemta-3.messagelabs.com id
	2B/A6-15054-08C57DF4; Tue, 12 Jun 2012 15:13:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339513984!32116459!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3680 invoked from network); 12 Jun 2012 15:13:04 -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 Jun 2012 15:13:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 16:13:03 +0100
Message-Id: <4FD778C802000078000897EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 16:13:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
In-Reply-To: <4FD72FE4.80009@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.06.12 at 14:02, Wei Wang <wei.wang2@amd.com> wrote:
> I had attached a revised patch, please check it.

While the patch technically looks better now, you didn't eliminate
my objections to the approach you take, nor did you comment on
the proposed alternative.

A fundamental problem is that your IOMMUs show up as a "normal"
PCI devices, breaking the separation between what is being
managed by the hypervisor vs by the Dom0 kernel. (This even
allows something as odd as passing through an IOMMU to a
DomU, which would clearly upset the hypervisor.)

> I found that the following Linux commit triggers this issue. It has been 
> included into 3.4 pv_ops.
> 
> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>    Author: Eric W. Biederman <ebiederm@xmission.com>
>    Date:   Mon Oct 17 11:46:06 2011 -0700
> 
>    PCI: msi: Disable msi interrupts when we initialize a pci device "

Thanks for locating this. As it stands, it is incomplete though
anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
it won't have a means to suppress the "screaming" interrupts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:13:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSmR-00030W-0Q; Tue, 12 Jun 2012 15:13:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeSmP-00030J-FC
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:13:13 +0000
Received: from [85.158.139.83:13773] by server-8.bemta-5.messagelabs.com id
	69/BB-02058-88C57DF4; Tue, 12 Jun 2012 15:13:12 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339513991!31722144!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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9492 invoked from network); 12 Jun 2012 15:13:12 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 15:13:12 -0000
Received: (qmail 16294 invoked from network); 12 Jun 2012 18:13:09 +0300
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.3.14894, Dats: 204453,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Enabled,
	Score: 0(0)], APM: [Enabled, Score: 500, Flags: NN_LEGIT_VALID_REPLY;
	NN_NO_LINK_NMD; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: 2c2273e1a366098cdd993ff75580ac3f.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v0.0; ], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.42574
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com;
	b=UV+ClpYKVWVmFR8zWEBIayT89GBShgCObOWmG6TBZSfgdFk0AF33xjnupY4LYCQlHiE1nDG5/SQuz2Wmnww+1yYe63CsNf+zRiDZZUIGJ6zCI0QTG+HbF5friEr/4RRMPzXMVLqjNhF0plsbwssE9KlzOZ+h8gmfWcf5XJs0xNw=
	; 
Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115)
	by mail.bitdefender.com with SMTP; 12 Jun 2012 18:13:09 +0300
Date: Tue, 12 Jun 2012 18:13:09 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <20120612181309.7cf8514e@mdontu-l.dsd.ro>
In-Reply-To: <4FD74D9A.8080807@gmail.com>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
Organization: Home
Mime-Version: 1.0
Subject: Re: [Xen-devel] memory introspection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAxMiBKdW4gMjAxMiAxODowOTozMCArMDQwMCBHZW9yZ2UgU2h1a2xpbiB3cm90ZToK
PiBJIHRoaW5rIGNyZWF0aW5nIGEgaHlwZXJ2aXNvci1sZXZlbCBHUEwgY29tcG9uZW50IHdpdGgg
c29tZSBraW5kIEFQSQo+IGFuZCB1c2luZyBpdCBieSBwcm9wcmlldGFyeSBkb20wLWxldmVsIHV0
aWxpdHkgaXMgZmluZSBzb2x1dGlvbi4KPiBFc3BlY2lhbGx5LCBpZiB5b3UgbWFrZSBpdCBzb21l
aG93IHVzYWJsZSBmb3IgYWxsIG90aGVyIHdvcmxkIGJ5Cj4gZGVmaW5pbmcgZ29vZCBBUEkuCj4g
CgpMZXQgbWUgb2ZmZXIgc29tZSBtb3JlIGRldGFpbHMgdG8gbWFrZSBzdXJlIHRoZSBpbWFnZSBv
ZiB3aGF0IEknbSBkb2luZwppcyBhcyBjbGVhciBhcyBwb3NzaWJsZTogdGhlIHRlY2hub2xvZ3kg
d2hpY2ggZm9jdXNlcyBvbiByb290a2l0CmRldGVjdGlvbiBieSBtb25pdG9yaW5nIHJlZ2lzdGVy
cyBhbmQgbWVtb3J5IGFjY2Vzc2VzIGlzIGVuY2Fwc3VsYXRlZAppbnRvIGEgUEUgc2hhcmVkIGxp
YnJhcnkgKERMTCkuIEl0J3MgZGVzaWduZWQgdG8gYmUgdXNlZCB3aXRoIG11bHRpcGxlCmh5cGVy
dmlzb3JzLiBUaGlzIGlzIHRoZSBjbG9zZWQgc291cmNlIGJsb2IuIEJlY2F1c2Ugb2YgaXRzIGxp
Y2Vuc2luZwphbmQgYmluYXJ5IGZvcm1hdCBpdCBjYW5ub3QgYmUgbGlua2VkIGRpcmVjdGx5IGlu
dG8gWGVuLCBzbyBpdCBuZWVkcwp0byBiZSAiaW5qZWN0ZWQiIChhcyBpZiBpdCB3ZXJlIGEgbW9k
dWxlKS4gU28gd2hhdCBJJ20gcGxhbm5pbmcgdG8gZG8KaXM6CgogICAgMS4gYWRkIGEgY29tcG9u
ZW50IHdoaWNoIHByb3ZpZGVzIGEgZ2VuZXJpYyBBUEkgdGhhdCBjYW4gYmUgdXNlZCBieQogICAg
ICAgbWVtb3J5IGludHJvc3BlY3Rpb24gdGVjaG5vbG9naWVzOwogICAgMi4gYWRkIGEgY3VzdG9t
IGNvbXBvbmVudCB3aGljaCBrbm93cyBob3cgdG8gbGluayBpbiBvdXIKICAgICAgIGludHJvc3Bl
Y3Rpb24gZW5naW5lIChsb2FkIGEgUEUsIHJlc29sdmUgcmVsb2NhdGlvbnMgZXRjLikKClRoZXkg
d2lsbCBib3RoIGJlIGxpY2Vuc2VkIHVuZGVyIEdQTC4gVGhlIHNlY29uZCBvbmUsIGhvd2V2ZXIs
IHdpbGwgbm90CmJlIHRvbyB1c2VmdWwgdG8gYSBsb3Qgb2YgcGVvcGxlLiBJdCBkb2Vzbid0IHJl
YWxseSBmaXQgaW4gWGVuIGFzIGl0CmlzLCBpdCB3b3VsZCBpZiBYZW4gaGFkIHN1cHBvcnQgZm9y
IG1vZHVsZXMgKHNvIHBlb3BsZSBjYW4gb3B0IGl0IG91dCkuCkkgY2FuIHByb2JhYmx5IHByZS1w
YXRjaCB0aGUgUEUgYW5kIHByb2R1Y2UgYW4gaW1hZ2Ugd2hpY2ggY2FuIGJlCmxvYWRlZCBhdCBh
IGZpeGVkIGFkZHJlc3MgdG9vIC4uLgoKTm93LCBmcm9tIGRvbTAgYW4gdXNlciBzcGFjZSB0b29s
IHdvdWxkIHRhbGsgd2l0aCB0aGUgIzIgY29tcG9uZW50IGFuZAppbmplY3QgdGhlIGludHJvc3Bl
Y3Rpb24gZW5naW5lIGludG8gdGhlIEhWLiBUaGlzIGlzIHdoZXJlIHRoZSBsZWdhbApzaXR1YXRp
b24gYXJpc2VzOiB3aGVuIHRoZSB3aG9sZSB0aGluZyBzdGFydHMgZnVuY3Rpb25pbmcsIHRoZXJl
IHdpbGwKZWZmZWN0aXZlbHkgYmUgYSBub24tZnJlZSBwaWVjZSBvZiBjb2RlIHRhbGtpbmcgd2l0
aCBhIEdQTCBvbmUgX3dpdGhpbgp0aGUgaHlwZXJ2aXNvcl8gKG5vdCBodiA8PiBkb20wKS4gSG93
IGZyb3duZWQgdXBvbiBpcyB0aGF0PyA6LSkKClVtbW0sIGFzIEknbSB3cml0aW5nIHRoaXMgSSBn
ZXQgYWxsIGtpbmRzIG9mIGlkZWFzOiBJIGNvdWxkIHByb2JhYmx5CmNvbnZlcnQgdGhlIFBFIHRv
IEVMRiBhbmQgYWRkIHByaW1pdGl2ZSBtb2R1bGUgbG9hZGluZyBzdXBwb3J0IHRvIFhlbi4KVGhl
IG1vZHVsZSBpdHNlbGYsIGhvd2V2ZXIsIHdpbGwgbm90IGJlIEdQTC4KCi0tIApNaWhhaSBEb27I
m3UKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:13:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSmR-00030W-0Q; Tue, 12 Jun 2012 15:13:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeSmP-00030J-FC
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:13:13 +0000
Received: from [85.158.139.83:13773] by server-8.bemta-5.messagelabs.com id
	69/BB-02058-88C57DF4; Tue, 12 Jun 2012 15:13:12 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339513991!31722144!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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9492 invoked from network); 12 Jun 2012 15:13:12 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 15:13:12 -0000
Received: (qmail 16294 invoked from network); 12 Jun 2012 18:13:09 +0300
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.3.14894, Dats: 204453,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Enabled,
	Score: 0(0)], APM: [Enabled, Score: 500, Flags: NN_LEGIT_VALID_REPLY;
	NN_NO_LINK_NMD; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: 2c2273e1a366098cdd993ff75580ac3f.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v0.0; ], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.42574
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com;
	b=UV+ClpYKVWVmFR8zWEBIayT89GBShgCObOWmG6TBZSfgdFk0AF33xjnupY4LYCQlHiE1nDG5/SQuz2Wmnww+1yYe63CsNf+zRiDZZUIGJ6zCI0QTG+HbF5friEr/4RRMPzXMVLqjNhF0plsbwssE9KlzOZ+h8gmfWcf5XJs0xNw=
	; 
Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115)
	by mail.bitdefender.com with SMTP; 12 Jun 2012 18:13:09 +0300
Date: Tue, 12 Jun 2012 18:13:09 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <20120612181309.7cf8514e@mdontu-l.dsd.ro>
In-Reply-To: <4FD74D9A.8080807@gmail.com>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
Organization: Home
Mime-Version: 1.0
Subject: Re: [Xen-devel] memory introspection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAxMiBKdW4gMjAxMiAxODowOTozMCArMDQwMCBHZW9yZ2UgU2h1a2xpbiB3cm90ZToK
PiBJIHRoaW5rIGNyZWF0aW5nIGEgaHlwZXJ2aXNvci1sZXZlbCBHUEwgY29tcG9uZW50IHdpdGgg
c29tZSBraW5kIEFQSQo+IGFuZCB1c2luZyBpdCBieSBwcm9wcmlldGFyeSBkb20wLWxldmVsIHV0
aWxpdHkgaXMgZmluZSBzb2x1dGlvbi4KPiBFc3BlY2lhbGx5LCBpZiB5b3UgbWFrZSBpdCBzb21l
aG93IHVzYWJsZSBmb3IgYWxsIG90aGVyIHdvcmxkIGJ5Cj4gZGVmaW5pbmcgZ29vZCBBUEkuCj4g
CgpMZXQgbWUgb2ZmZXIgc29tZSBtb3JlIGRldGFpbHMgdG8gbWFrZSBzdXJlIHRoZSBpbWFnZSBv
ZiB3aGF0IEknbSBkb2luZwppcyBhcyBjbGVhciBhcyBwb3NzaWJsZTogdGhlIHRlY2hub2xvZ3kg
d2hpY2ggZm9jdXNlcyBvbiByb290a2l0CmRldGVjdGlvbiBieSBtb25pdG9yaW5nIHJlZ2lzdGVy
cyBhbmQgbWVtb3J5IGFjY2Vzc2VzIGlzIGVuY2Fwc3VsYXRlZAppbnRvIGEgUEUgc2hhcmVkIGxp
YnJhcnkgKERMTCkuIEl0J3MgZGVzaWduZWQgdG8gYmUgdXNlZCB3aXRoIG11bHRpcGxlCmh5cGVy
dmlzb3JzLiBUaGlzIGlzIHRoZSBjbG9zZWQgc291cmNlIGJsb2IuIEJlY2F1c2Ugb2YgaXRzIGxp
Y2Vuc2luZwphbmQgYmluYXJ5IGZvcm1hdCBpdCBjYW5ub3QgYmUgbGlua2VkIGRpcmVjdGx5IGlu
dG8gWGVuLCBzbyBpdCBuZWVkcwp0byBiZSAiaW5qZWN0ZWQiIChhcyBpZiBpdCB3ZXJlIGEgbW9k
dWxlKS4gU28gd2hhdCBJJ20gcGxhbm5pbmcgdG8gZG8KaXM6CgogICAgMS4gYWRkIGEgY29tcG9u
ZW50IHdoaWNoIHByb3ZpZGVzIGEgZ2VuZXJpYyBBUEkgdGhhdCBjYW4gYmUgdXNlZCBieQogICAg
ICAgbWVtb3J5IGludHJvc3BlY3Rpb24gdGVjaG5vbG9naWVzOwogICAgMi4gYWRkIGEgY3VzdG9t
IGNvbXBvbmVudCB3aGljaCBrbm93cyBob3cgdG8gbGluayBpbiBvdXIKICAgICAgIGludHJvc3Bl
Y3Rpb24gZW5naW5lIChsb2FkIGEgUEUsIHJlc29sdmUgcmVsb2NhdGlvbnMgZXRjLikKClRoZXkg
d2lsbCBib3RoIGJlIGxpY2Vuc2VkIHVuZGVyIEdQTC4gVGhlIHNlY29uZCBvbmUsIGhvd2V2ZXIs
IHdpbGwgbm90CmJlIHRvbyB1c2VmdWwgdG8gYSBsb3Qgb2YgcGVvcGxlLiBJdCBkb2Vzbid0IHJl
YWxseSBmaXQgaW4gWGVuIGFzIGl0CmlzLCBpdCB3b3VsZCBpZiBYZW4gaGFkIHN1cHBvcnQgZm9y
IG1vZHVsZXMgKHNvIHBlb3BsZSBjYW4gb3B0IGl0IG91dCkuCkkgY2FuIHByb2JhYmx5IHByZS1w
YXRjaCB0aGUgUEUgYW5kIHByb2R1Y2UgYW4gaW1hZ2Ugd2hpY2ggY2FuIGJlCmxvYWRlZCBhdCBh
IGZpeGVkIGFkZHJlc3MgdG9vIC4uLgoKTm93LCBmcm9tIGRvbTAgYW4gdXNlciBzcGFjZSB0b29s
IHdvdWxkIHRhbGsgd2l0aCB0aGUgIzIgY29tcG9uZW50IGFuZAppbmplY3QgdGhlIGludHJvc3Bl
Y3Rpb24gZW5naW5lIGludG8gdGhlIEhWLiBUaGlzIGlzIHdoZXJlIHRoZSBsZWdhbApzaXR1YXRp
b24gYXJpc2VzOiB3aGVuIHRoZSB3aG9sZSB0aGluZyBzdGFydHMgZnVuY3Rpb25pbmcsIHRoZXJl
IHdpbGwKZWZmZWN0aXZlbHkgYmUgYSBub24tZnJlZSBwaWVjZSBvZiBjb2RlIHRhbGtpbmcgd2l0
aCBhIEdQTCBvbmUgX3dpdGhpbgp0aGUgaHlwZXJ2aXNvcl8gKG5vdCBodiA8PiBkb20wKS4gSG93
IGZyb3duZWQgdXBvbiBpcyB0aGF0PyA6LSkKClVtbW0sIGFzIEknbSB3cml0aW5nIHRoaXMgSSBn
ZXQgYWxsIGtpbmRzIG9mIGlkZWFzOiBJIGNvdWxkIHByb2JhYmx5CmNvbnZlcnQgdGhlIFBFIHRv
IEVMRiBhbmQgYWRkIHByaW1pdGl2ZSBtb2R1bGUgbG9hZGluZyBzdXBwb3J0IHRvIFhlbi4KVGhl
IG1vZHVsZSBpdHNlbGYsIGhvd2V2ZXIsIHdpbGwgbm90IGJlIEdQTC4KCi0tIApNaWhhaSBEb27I
m3UKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSnb-000377-FS; Tue, 12 Jun 2012 15:14: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 1SeSnZ-00036t-Jp
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 15:14:25 +0000
Received: from [85.158.139.83:25699] by server-3.bemta-5.messagelabs.com id
	9B/44-03367-0DC57DF4; Tue, 12 Jun 2012 15:14:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339514064!28972964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29224 invoked from network); 12 Jun 2012 15:14:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:14:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:14:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:14:23 +0100
Message-ID: <1339514061.24104.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 12 Jun 2012 16:14:21 +0100
In-Reply-To: <d5280420afc9c1e52d8e.1339430192@probook.site>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339429861 -7200
> # Node ID d5280420afc9c1e52d8e8bf35bb36512120e0556
> # Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
> docs: install documentation which is referenced in man pages
> 
> Currently the various man pages refer to some other documentation files
> in the source tree. For example, xl.cfg.5 refers to
> docs/misc/xl-disk-configuration.txt, which in turn refers to
> docs/misc/vbd-interface.txt.
> 
> Since these files are not packaged, the provided documentation appears
> incomplete. Fix this by installing the additional files into DOCDIR and
> also adjust the contents of the man pages and affected documentation
> files to contain the full path of DOCDIR.
> 
> xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> xl-network-configuration. Adjust to new DOCDIR location.

The reason for omitting the extension is that it can be .html or .txt
depending on the context which the link is given in.

> Simplify the pod2man call, merge two sed calls into a single one.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r a70b35deb2b5 -r d5280420afc9 docs/Makefile
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -21,6 +21,10 @@ DOC_TXT         := $(patsubst %.txt,txt/
>  		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
>  		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
>  
> +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> +			misc/xl-disk-configuration.txt \
> +			misc/vbd-interface.txt \
> +			misc/xl-network-configuration.markdown

Any reason not to install the whole of $(DOC_TXT) instead of just this
subset?

>  clean:
> @@ -89,6 +97,9 @@ install: all
>  	cp -dR man1 $(DESTDIR)$(MANDIR)
>  	cp -dR man5 $(DESTDIR)$(MANDIR)
>  	[ ! -d html ] || cp -dR html $(DESTDIR)$(DOCDIR)
> +	for i in $(DOC_MAN_REFS) ; do \
> +		sed 's|@DOCDIR@|$(DOCDIR)|g' $$i > $(DESTDIR)$(DOCDIR)/`basename $$i` ; \
> +		done
>  
>  html/index.html: $(DOC_HTML) ./gen-html-index INDEX
>  	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
> diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -255,13 +255,13 @@ devices which the guest will contain.
>  
>  Specifies the disks (both emulated disks and Xen virtual block
>  devices) which are to be provided to the guest, and what objects on
> -the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
> +the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
>  
>  =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
>  
>  Specifies the networking provision (both emulated network adapters,
>  and Xen virtual interfaces) to provided to the guest.  See
> -F<docs/misc/xl-network-configuration.markdown>.
> +F<@DOCDIR@/xl-network-configuration.markdown>.

I'm slightly concerned about what all this will mean for the HTML
generated docs, in particular the ones hosted at
http://xenbits.xen.org/docs/unstable/. Currently they aren't actual
working links there but they do at least reference the real path in the
source tree.

At the very least it would be simpler to deal with this if the misc part
of the path was retainined, both in these references and in the actual
install location (e.g. @DOCDIR@/misc).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSnb-000377-FS; Tue, 12 Jun 2012 15:14: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 1SeSnZ-00036t-Jp
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 15:14:25 +0000
Received: from [85.158.139.83:25699] by server-3.bemta-5.messagelabs.com id
	9B/44-03367-0DC57DF4; Tue, 12 Jun 2012 15:14:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339514064!28972964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29224 invoked from network); 12 Jun 2012 15:14:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:14:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:14:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:14:23 +0100
Message-ID: <1339514061.24104.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 12 Jun 2012 16:14:21 +0100
In-Reply-To: <d5280420afc9c1e52d8e.1339430192@probook.site>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339429861 -7200
> # Node ID d5280420afc9c1e52d8e8bf35bb36512120e0556
> # Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
> docs: install documentation which is referenced in man pages
> 
> Currently the various man pages refer to some other documentation files
> in the source tree. For example, xl.cfg.5 refers to
> docs/misc/xl-disk-configuration.txt, which in turn refers to
> docs/misc/vbd-interface.txt.
> 
> Since these files are not packaged, the provided documentation appears
> incomplete. Fix this by installing the additional files into DOCDIR and
> also adjust the contents of the man pages and affected documentation
> files to contain the full path of DOCDIR.
> 
> xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> xl-network-configuration. Adjust to new DOCDIR location.

The reason for omitting the extension is that it can be .html or .txt
depending on the context which the link is given in.

> Simplify the pod2man call, merge two sed calls into a single one.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r a70b35deb2b5 -r d5280420afc9 docs/Makefile
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -21,6 +21,10 @@ DOC_TXT         := $(patsubst %.txt,txt/
>  		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
>  		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
>  
> +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> +			misc/xl-disk-configuration.txt \
> +			misc/vbd-interface.txt \
> +			misc/xl-network-configuration.markdown

Any reason not to install the whole of $(DOC_TXT) instead of just this
subset?

>  clean:
> @@ -89,6 +97,9 @@ install: all
>  	cp -dR man1 $(DESTDIR)$(MANDIR)
>  	cp -dR man5 $(DESTDIR)$(MANDIR)
>  	[ ! -d html ] || cp -dR html $(DESTDIR)$(DOCDIR)
> +	for i in $(DOC_MAN_REFS) ; do \
> +		sed 's|@DOCDIR@|$(DOCDIR)|g' $$i > $(DESTDIR)$(DOCDIR)/`basename $$i` ; \
> +		done
>  
>  html/index.html: $(DOC_HTML) ./gen-html-index INDEX
>  	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
> diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -255,13 +255,13 @@ devices which the guest will contain.
>  
>  Specifies the disks (both emulated disks and Xen virtual block
>  devices) which are to be provided to the guest, and what objects on
> -the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
> +the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
>  
>  =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
>  
>  Specifies the networking provision (both emulated network adapters,
>  and Xen virtual interfaces) to provided to the guest.  See
> -F<docs/misc/xl-network-configuration.markdown>.
> +F<@DOCDIR@/xl-network-configuration.markdown>.

I'm slightly concerned about what all this will mean for the HTML
generated docs, in particular the ones hosted at
http://xenbits.xen.org/docs/unstable/. Currently they aren't actual
working links there but they do at least reference the real path in the
source tree.

At the very least it would be simpler to deal with this if the misc part
of the path was retainined, both in these references and in the actual
install location (e.g. @DOCDIR@/misc).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:15:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:15: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 1SeSoO-0003Cj-Tq; Tue, 12 Jun 2012 15:15: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 1SeSoM-0003CL-Mc
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:15:14 +0000
Received: from [85.158.143.99:10319] by server-1.bemta-4.messagelabs.com id
	72/5C-24392-20D57DF4; Tue, 12 Jun 2012 15:15:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339514110!25941195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8899 invoked from network); 12 Jun 2012 15:15:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:15:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:15:10 +0100
Message-ID: <1339514108.24104.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 16:15:08 +0100
In-Reply-To: <1339176870-32652-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/19] libxc: xc_domain_restore,
 make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Update the one provider of this callback, in libxl.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Changes in v3:
>  * No longer introduce function pointer typedefs into the libxc API.

Thanks!

> ---
>  tools/libxc/xenguest.h  |    2 +-
>  tools/libxl/libxl_dom.c |    4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 91d53f7..707e31c 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>  /* callbacks provided by xc_domain_restore */
>  struct restore_callbacks {
>      /* callback to restore toolstack specific data */
> -    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> +    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
>              uint32_t size, void* data);
>  
>      /* to be provided as the last argument to each callback function */
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 10f8c1f..677db1d 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -467,13 +467,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>              domid, phys_offset, node);
>  }
>  
> -static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>          uint32_t size, void *data)
>  {
>      libxl__gc *gc = (libxl__gc *) data;
>      libxl_ctx *ctx = gc->owner;
>      int i, ret;
> -    uint8_t *ptr = buf;
> +    const uint8_t *ptr = buf;
>      uint32_t count = 0, version = 0;
>      struct libxl__physmap_info* pi;
>      char *xs_path;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:15:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:15: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 1SeSoO-0003Cj-Tq; Tue, 12 Jun 2012 15:15: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 1SeSoM-0003CL-Mc
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:15:14 +0000
Received: from [85.158.143.99:10319] by server-1.bemta-4.messagelabs.com id
	72/5C-24392-20D57DF4; Tue, 12 Jun 2012 15:15:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339514110!25941195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8899 invoked from network); 12 Jun 2012 15:15:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:15:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:15:10 +0100
Message-ID: <1339514108.24104.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 16:15:08 +0100
In-Reply-To: <1339176870-32652-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/19] libxc: xc_domain_restore,
 make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Update the one provider of this callback, in libxl.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Changes in v3:
>  * No longer introduce function pointer typedefs into the libxc API.

Thanks!

> ---
>  tools/libxc/xenguest.h  |    2 +-
>  tools/libxl/libxl_dom.c |    4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 91d53f7..707e31c 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>  /* callbacks provided by xc_domain_restore */
>  struct restore_callbacks {
>      /* callback to restore toolstack specific data */
> -    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> +    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
>              uint32_t size, void* data);
>  
>      /* to be provided as the last argument to each callback function */
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 10f8c1f..677db1d 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -467,13 +467,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>              domid, phys_offset, node);
>  }
>  
> -static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>          uint32_t size, void *data)
>  {
>      libxl__gc *gc = (libxl__gc *) data;
>      libxl_ctx *ctx = gc->owner;
>      int i, ret;
> -    uint8_t *ptr = buf;
> +    const uint8_t *ptr = buf;
>      uint32_t count = 0, version = 0;
>      struct libxl__physmap_info* pi;
>      char *xs_path;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:15:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSoi-0003G5-AI; Tue, 12 Jun 2012 15:15:36 +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 1SeSoh-0003Fv-D1
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:15:35 +0000
Received: from [85.158.138.51:60183] by server-9.bemta-3.messagelabs.com id
	1B/BD-15054-61D57DF4; Tue, 12 Jun 2012 15:15:34 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339514133!24034170!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIyNjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27379 invoked from network); 12 Jun 2012 15:15:33 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Jun 2012 15:15:33 -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 q5CFFRNk026310
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Jun 2012 11:15:28 -0400
Received: from redhat.com (unused-13-123.tlv.redhat.com [10.35.13.123] (may be
	forged))
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q5CFFPWB005534; Tue, 12 Jun 2012 11:15:26 -0400
Date: Tue, 12 Jun 2012 18:15:57 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120612151557.GA10691@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> 
> This function is used by a later patch to parse the BDF of the device to
> passthrough.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

You probably want to parse the host address?  You don't want to copy the
bugs in pci_parse_devaddr - write your own that has sane semantics
for host. E.g. you need to support ARI etc.

> ---
>  hw/pci.c |    2 +-
>  hw/pci.h |    2 ++
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index eec106a..5bddf7a 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -479,7 +479,7 @@ static void pci_set_default_subsystem_id(PCIDevice *pci_dev)
>   * Parse [[<domain>:]<bus>:]<slot>, return -1 on error if funcp == NULL
>   *       [[<domain>:]<bus>:]<slot>.<func>, return -1 on error
>   */
> -static int pci_parse_devaddr(const char *addr, int *domp, int *busp,
> +int pci_parse_devaddr(const char *addr, int *domp, int *busp,
>                        unsigned int *slotp, unsigned int *funcp)
>  {
>      const char *p;
> diff --git a/hw/pci.h b/hw/pci.h
> index ecf37fd..b169c0b 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -321,6 +321,8 @@ PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
>  int pci_qdev_find_device(const char *id, PCIDevice **pdev);
>  PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr);
>  
> +int pci_parse_devaddr(const char *addr, int *domp, int *busp,
> +                      unsigned int *slotp, unsigned int *funcp);
>  int pci_read_devaddr(Monitor *mon, const char *addr, int *domp, int *busp,
>                       unsigned *slotp);
>  
> -- 
> 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 Jun 12 15:15:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeSoi-0003G5-AI; Tue, 12 Jun 2012 15:15:36 +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 1SeSoh-0003Fv-D1
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:15:35 +0000
Received: from [85.158.138.51:60183] by server-9.bemta-3.messagelabs.com id
	1B/BD-15054-61D57DF4; Tue, 12 Jun 2012 15:15:34 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339514133!24034170!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIyNjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27379 invoked from network); 12 Jun 2012 15:15:33 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Jun 2012 15:15:33 -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 q5CFFRNk026310
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Jun 2012 11:15:28 -0400
Received: from redhat.com (unused-13-123.tlv.redhat.com [10.35.13.123] (may be
	forged))
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q5CFFPWB005534; Tue, 12 Jun 2012 11:15:26 -0400
Date: Tue, 12 Jun 2012 18:15:57 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120612151557.GA10691@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> 
> This function is used by a later patch to parse the BDF of the device to
> passthrough.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

You probably want to parse the host address?  You don't want to copy the
bugs in pci_parse_devaddr - write your own that has sane semantics
for host. E.g. you need to support ARI etc.

> ---
>  hw/pci.c |    2 +-
>  hw/pci.h |    2 ++
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index eec106a..5bddf7a 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -479,7 +479,7 @@ static void pci_set_default_subsystem_id(PCIDevice *pci_dev)
>   * Parse [[<domain>:]<bus>:]<slot>, return -1 on error if funcp == NULL
>   *       [[<domain>:]<bus>:]<slot>.<func>, return -1 on error
>   */
> -static int pci_parse_devaddr(const char *addr, int *domp, int *busp,
> +int pci_parse_devaddr(const char *addr, int *domp, int *busp,
>                        unsigned int *slotp, unsigned int *funcp)
>  {
>      const char *p;
> diff --git a/hw/pci.h b/hw/pci.h
> index ecf37fd..b169c0b 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -321,6 +321,8 @@ PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
>  int pci_qdev_find_device(const char *id, PCIDevice **pdev);
>  PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr);
>  
> +int pci_parse_devaddr(const char *addr, int *domp, int *busp,
> +                      unsigned int *slotp, unsigned int *funcp);
>  int pci_read_devaddr(Monitor *mon, const char *addr, int *domp, int *busp,
>                       unsigned *slotp);
>  
> -- 
> 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 Jun 12 15:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeSxW-0003hG-Bm; Tue, 12 Jun 2012 15:24:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SeSxV-0003hB-6y
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:24:41 +0000
Received: from [85.158.138.51:11419] by server-9.bemta-3.messagelabs.com id
	53/18-15054-83F57DF4; Tue, 12 Jun 2012 15:24:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339514679!29259078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29415 invoked from network); 12 Jun 2012 15:24:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:24:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:24:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:24:38 +0100
Message-ID: <1339514677.24104.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 16:24:37 +0100
In-Reply-To: <1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/19] libxl: domain save: rename variables
 etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Preparatory work for making domain suspend asynchronous:
[...]
> No functional change whatsoever.

Given that and a quick skim of the changes:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although in general I find it easier to review patches which contain
only one particular class of "mostly automatic" cleanup (e.g. renames
separate from "pointerization" separate from local variable removal
etc).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeSxW-0003hG-Bm; Tue, 12 Jun 2012 15:24:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SeSxV-0003hB-6y
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:24:41 +0000
Received: from [85.158.138.51:11419] by server-9.bemta-3.messagelabs.com id
	53/18-15054-83F57DF4; Tue, 12 Jun 2012 15:24:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339514679!29259078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29415 invoked from network); 12 Jun 2012 15:24:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:24:39 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12972999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:24:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:24:38 +0100
Message-ID: <1339514677.24104.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 16:24:37 +0100
In-Reply-To: <1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/19] libxl: domain save: rename variables
 etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Preparatory work for making domain suspend asynchronous:
[...]
> No functional change whatsoever.

Given that and a quick skim of the changes:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although in general I find it easier to review patches which contain
only one particular class of "mostly automatic" cleanup (e.g. renames
separate from "pointerization" separate from local variable removal
etc).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:40:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeTCK-0004Eq-M6; Tue, 12 Jun 2012 15:40: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 1SeTCI-0004El-Ro
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:39:59 +0000
Received: from [85.158.143.99:39922] by server-3.bemta-4.messagelabs.com id
	E1/DE-05808-DC267DF4; Tue, 12 Jun 2012 15:39:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339515597!27227144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22149 invoked from network); 12 Jun 2012 15:39:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:39:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12973398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:39:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:39:56 +0100
Message-ID: <1339515595.24104.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mihai =?UTF-8?Q?Don=C8=9Bu?= <mihai.dontu@gmail.com>
Date: Tue, 12 Jun 2012 16:39:55 +0100
In-Reply-To: <20120612181309.7cf8514e@mdontu-l.dsd.ro>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com> <20120612181309.7cf8514e@mdontu-l.dsd.ro>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Hypervisor loadable modules and GPL licensing issues
 (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SSBoYXZlIHJldGl0bGVkIHRoaXMgdGhyZWFkIHN1Y2ggdGhhdCBpdCBjYXRjaGVzIHRoZSBhdHRl
bnRpb24gd2hpY2ggaXQKZGVzZXJ2ZXMuCgpPbiBUdWUsIDIwMTItMDYtMTIgYXQgMTY6MTMgKzAx
MDAsIE1paGFpIERvbsibdSB3cm90ZToKPiBPbiBUdWUsIDEyIEp1biAyMDEyIDE4OjA5OjMwICsw
NDAwIEdlb3JnZSBTaHVrbGluIHdyb3RlOgo+ID4gSSB0aGluayBjcmVhdGluZyBhIGh5cGVydmlz
b3ItbGV2ZWwgR1BMIGNvbXBvbmVudCB3aXRoIHNvbWUga2luZCBBUEkKPiA+IGFuZCB1c2luZyBp
dCBieSBwcm9wcmlldGFyeSBkb20wLWxldmVsIHV0aWxpdHkgaXMgZmluZSBzb2x1dGlvbi4KPiA+
IEVzcGVjaWFsbHksIGlmIHlvdSBtYWtlIGl0IHNvbWVob3cgdXNhYmxlIGZvciBhbGwgb3RoZXIg
d29ybGQgYnkKPiA+IGRlZmluaW5nIGdvb2QgQVBJLgo+ID4gCj4gCj4gTGV0IG1lIG9mZmVyIHNv
bWUgbW9yZSBkZXRhaWxzIHRvIG1ha2Ugc3VyZSB0aGUgaW1hZ2Ugb2Ygd2hhdCBJJ20gZG9pbmcK
PiBpcyBhcyBjbGVhciBhcyBwb3NzaWJsZTogdGhlIHRlY2hub2xvZ3kgd2hpY2ggZm9jdXNlcyBv
biByb290a2l0Cj4gZGV0ZWN0aW9uIGJ5IG1vbml0b3JpbmcgcmVnaXN0ZXJzIGFuZCBtZW1vcnkg
YWNjZXNzZXMgaXMgZW5jYXBzdWxhdGVkCj4gaW50byBhIFBFIHNoYXJlZCBsaWJyYXJ5IChETEwp
LiBJdCdzIGRlc2lnbmVkIHRvIGJlIHVzZWQgd2l0aCBtdWx0aXBsZQo+IGh5cGVydmlzb3JzLiBU
aGlzIGlzIHRoZSBjbG9zZWQgc291cmNlIGJsb2IuIEJlY2F1c2Ugb2YgaXRzIGxpY2Vuc2luZwo+
IGFuZCBiaW5hcnkgZm9ybWF0IGl0IGNhbm5vdCBiZSBsaW5rZWQgZGlyZWN0bHkgaW50byBYZW4s
IHNvIGl0IG5lZWRzCj4gdG8gYmUgImluamVjdGVkIiAoYXMgaWYgaXQgd2VyZSBhIG1vZHVsZSku
IFNvIHdoYXQgSSdtIHBsYW5uaW5nIHRvIGRvCj4gaXM6Cj4gCj4gICAgIDEuIGFkZCBhIGNvbXBv
bmVudCB3aGljaCBwcm92aWRlcyBhIGdlbmVyaWMgQVBJIHRoYXQgY2FuIGJlIHVzZWQgYnkKPiAg
ICAgICAgbWVtb3J5IGludHJvc3BlY3Rpb24gdGVjaG5vbG9naWVzOwo+ICAgICAyLiBhZGQgYSBj
dXN0b20gY29tcG9uZW50IHdoaWNoIGtub3dzIGhvdyB0byBsaW5rIGluIG91cgo+ICAgICAgICBp
bnRyb3NwZWN0aW9uIGVuZ2luZSAobG9hZCBhIFBFLCByZXNvbHZlIHJlbG9jYXRpb25zIGV0Yy4p
Cj4gCj4gVGhleSB3aWxsIGJvdGggYmUgbGljZW5zZWQgdW5kZXIgR1BMLiBUaGUgc2Vjb25kIG9u
ZSwgaG93ZXZlciwgd2lsbCBub3QKPiBiZSB0b28gdXNlZnVsIHRvIGEgbG90IG9mIHBlb3BsZS4g
SXQgZG9lc24ndCByZWFsbHkgZml0IGluIFhlbiBhcyBpdAo+IGlzLCBpdCB3b3VsZCBpZiBYZW4g
aGFkIHN1cHBvcnQgZm9yIG1vZHVsZXMgKHNvIHBlb3BsZSBjYW4gb3B0IGl0IG91dCkuCj4gSSBj
YW4gcHJvYmFibHkgcHJlLXBhdGNoIHRoZSBQRSBhbmQgcHJvZHVjZSBhbiBpbWFnZSB3aGljaCBj
YW4gYmUKPiBsb2FkZWQgYXQgYSBmaXhlZCBhZGRyZXNzIHRvbyAuLi4KPiAKPiBOb3csIGZyb20g
ZG9tMCBhbiB1c2VyIHNwYWNlIHRvb2wgd291bGQgdGFsayB3aXRoIHRoZSAjMiBjb21wb25lbnQg
YW5kCj4gaW5qZWN0IHRoZSBpbnRyb3NwZWN0aW9uIGVuZ2luZSBpbnRvIHRoZSBIVi4gVGhpcyBp
cyB3aGVyZSB0aGUgbGVnYWwKPiBzaXR1YXRpb24gYXJpc2VzOiB3aGVuIHRoZSB3aG9sZSB0aGlu
ZyBzdGFydHMgZnVuY3Rpb25pbmcsIHRoZXJlIHdpbGwKPiBlZmZlY3RpdmVseSBiZSBhIG5vbi1m
cmVlIHBpZWNlIG9mIGNvZGUgdGFsa2luZyB3aXRoIGEgR1BMIG9uZSBfd2l0aGluCj4gdGhlIGh5
cGVydmlzb3JfIChub3QgaHYgPD4gZG9tMCkuIEhvdyBmcm93bmVkIHVwb24gaXMgdGhhdD8gOi0p
CgpJIGRvbid0IHRoaW5rIHdlIHBhcnRpY3VsYXJseSB3YW50L25lZWQgYSBtb2R1bGUgbG9hZGVy
IGluIHRoZQpoeXBlcnZpc29yLCByZWdhcmRsZXNzIG9mIHRoZSBsaWNlbnNlIG9mIHRoZSBjb2Rl
IHdoaWNoIGl0IGlzIHVzZWQgdG8KbG9hZC4KClRoZSBsZWdhbGl0eSBvZiBsb2FkaW5nIHlvdXIg
bm9uLUdQTC1jb21wYXRpYmxlIGJsb2IgaW50byB0aGUgaHlwZXJ2aXNvcgppcyBhIHF1ZXN0aW9u
IHdoaWNoIG9ubHkgYSBsYXd5ZXIgY2FuIGFuc3dlci4gWW91IHNob3VsZCBub3QgdGFrZSBsZWdh
bAphZHZpc2UgZnJvbSB0aGlzIG1haWxpbmcgbGlzdC4KCk15IHBlcnNvbmFsIG9waW5pb24gaXMg
dGhhdCBpdCB3b3VsZCBub3QgYmUgYWNjZXB0YWJsZSB0byBsb2FkIG5vbi1HUEwKY29tcGF0aWJs
ZSBjb2RlIGludG8gdGhlIGh5cGVydmlzb3IgdmlhIGFueSBtZWNoYW5pc20sIGl0IGlzIGhhcmQg
dG8gc2VlCmhvdyBhbnkgbG9hZGFibGUgbW9kdWxlIHdvdWxkIG5vdCBiZSBhIGRlcml2ZWQgd29y
ayBvZiB0aGUgaHlwZXJ2aXNvcgphbmQgdGhlcmVmb3JlIHN1YmplY3QgdG8gdGhlIHRlcm1zIG9m
IHRoZSBHUEwuCgpJYW4uCgo+IFVtbW0sIGFzIEknbSB3cml0aW5nIHRoaXMgSSBnZXQgYWxsIGtp
bmRzIG9mIGlkZWFzOiBJIGNvdWxkIHByb2JhYmx5Cj4gY29udmVydCB0aGUgUEUgdG8gRUxGIGFu
ZCBhZGQgcHJpbWl0aXZlIG1vZHVsZSBsb2FkaW5nIHN1cHBvcnQgdG8gWGVuLgo+IFRoZSBtb2R1
bGUgaXRzZWxmLCBob3dldmVyLCB3aWxsIG5vdCBiZSBHUEwuCj4gCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:40:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15: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 1SeTCK-0004Eq-M6; Tue, 12 Jun 2012 15:40: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 1SeTCI-0004El-Ro
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:39:59 +0000
Received: from [85.158.143.99:39922] by server-3.bemta-4.messagelabs.com id
	E1/DE-05808-DC267DF4; Tue, 12 Jun 2012 15:39:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339515597!27227144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22149 invoked from network); 12 Jun 2012 15:39:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:39:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12973398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:39:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:39:56 +0100
Message-ID: <1339515595.24104.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mihai =?UTF-8?Q?Don=C8=9Bu?= <mihai.dontu@gmail.com>
Date: Tue, 12 Jun 2012 16:39:55 +0100
In-Reply-To: <20120612181309.7cf8514e@mdontu-l.dsd.ro>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com> <20120612181309.7cf8514e@mdontu-l.dsd.ro>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Hypervisor loadable modules and GPL licensing issues
 (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SSBoYXZlIHJldGl0bGVkIHRoaXMgdGhyZWFkIHN1Y2ggdGhhdCBpdCBjYXRjaGVzIHRoZSBhdHRl
bnRpb24gd2hpY2ggaXQKZGVzZXJ2ZXMuCgpPbiBUdWUsIDIwMTItMDYtMTIgYXQgMTY6MTMgKzAx
MDAsIE1paGFpIERvbsibdSB3cm90ZToKPiBPbiBUdWUsIDEyIEp1biAyMDEyIDE4OjA5OjMwICsw
NDAwIEdlb3JnZSBTaHVrbGluIHdyb3RlOgo+ID4gSSB0aGluayBjcmVhdGluZyBhIGh5cGVydmlz
b3ItbGV2ZWwgR1BMIGNvbXBvbmVudCB3aXRoIHNvbWUga2luZCBBUEkKPiA+IGFuZCB1c2luZyBp
dCBieSBwcm9wcmlldGFyeSBkb20wLWxldmVsIHV0aWxpdHkgaXMgZmluZSBzb2x1dGlvbi4KPiA+
IEVzcGVjaWFsbHksIGlmIHlvdSBtYWtlIGl0IHNvbWVob3cgdXNhYmxlIGZvciBhbGwgb3RoZXIg
d29ybGQgYnkKPiA+IGRlZmluaW5nIGdvb2QgQVBJLgo+ID4gCj4gCj4gTGV0IG1lIG9mZmVyIHNv
bWUgbW9yZSBkZXRhaWxzIHRvIG1ha2Ugc3VyZSB0aGUgaW1hZ2Ugb2Ygd2hhdCBJJ20gZG9pbmcK
PiBpcyBhcyBjbGVhciBhcyBwb3NzaWJsZTogdGhlIHRlY2hub2xvZ3kgd2hpY2ggZm9jdXNlcyBv
biByb290a2l0Cj4gZGV0ZWN0aW9uIGJ5IG1vbml0b3JpbmcgcmVnaXN0ZXJzIGFuZCBtZW1vcnkg
YWNjZXNzZXMgaXMgZW5jYXBzdWxhdGVkCj4gaW50byBhIFBFIHNoYXJlZCBsaWJyYXJ5IChETEwp
LiBJdCdzIGRlc2lnbmVkIHRvIGJlIHVzZWQgd2l0aCBtdWx0aXBsZQo+IGh5cGVydmlzb3JzLiBU
aGlzIGlzIHRoZSBjbG9zZWQgc291cmNlIGJsb2IuIEJlY2F1c2Ugb2YgaXRzIGxpY2Vuc2luZwo+
IGFuZCBiaW5hcnkgZm9ybWF0IGl0IGNhbm5vdCBiZSBsaW5rZWQgZGlyZWN0bHkgaW50byBYZW4s
IHNvIGl0IG5lZWRzCj4gdG8gYmUgImluamVjdGVkIiAoYXMgaWYgaXQgd2VyZSBhIG1vZHVsZSku
IFNvIHdoYXQgSSdtIHBsYW5uaW5nIHRvIGRvCj4gaXM6Cj4gCj4gICAgIDEuIGFkZCBhIGNvbXBv
bmVudCB3aGljaCBwcm92aWRlcyBhIGdlbmVyaWMgQVBJIHRoYXQgY2FuIGJlIHVzZWQgYnkKPiAg
ICAgICAgbWVtb3J5IGludHJvc3BlY3Rpb24gdGVjaG5vbG9naWVzOwo+ICAgICAyLiBhZGQgYSBj
dXN0b20gY29tcG9uZW50IHdoaWNoIGtub3dzIGhvdyB0byBsaW5rIGluIG91cgo+ICAgICAgICBp
bnRyb3NwZWN0aW9uIGVuZ2luZSAobG9hZCBhIFBFLCByZXNvbHZlIHJlbG9jYXRpb25zIGV0Yy4p
Cj4gCj4gVGhleSB3aWxsIGJvdGggYmUgbGljZW5zZWQgdW5kZXIgR1BMLiBUaGUgc2Vjb25kIG9u
ZSwgaG93ZXZlciwgd2lsbCBub3QKPiBiZSB0b28gdXNlZnVsIHRvIGEgbG90IG9mIHBlb3BsZS4g
SXQgZG9lc24ndCByZWFsbHkgZml0IGluIFhlbiBhcyBpdAo+IGlzLCBpdCB3b3VsZCBpZiBYZW4g
aGFkIHN1cHBvcnQgZm9yIG1vZHVsZXMgKHNvIHBlb3BsZSBjYW4gb3B0IGl0IG91dCkuCj4gSSBj
YW4gcHJvYmFibHkgcHJlLXBhdGNoIHRoZSBQRSBhbmQgcHJvZHVjZSBhbiBpbWFnZSB3aGljaCBj
YW4gYmUKPiBsb2FkZWQgYXQgYSBmaXhlZCBhZGRyZXNzIHRvbyAuLi4KPiAKPiBOb3csIGZyb20g
ZG9tMCBhbiB1c2VyIHNwYWNlIHRvb2wgd291bGQgdGFsayB3aXRoIHRoZSAjMiBjb21wb25lbnQg
YW5kCj4gaW5qZWN0IHRoZSBpbnRyb3NwZWN0aW9uIGVuZ2luZSBpbnRvIHRoZSBIVi4gVGhpcyBp
cyB3aGVyZSB0aGUgbGVnYWwKPiBzaXR1YXRpb24gYXJpc2VzOiB3aGVuIHRoZSB3aG9sZSB0aGlu
ZyBzdGFydHMgZnVuY3Rpb25pbmcsIHRoZXJlIHdpbGwKPiBlZmZlY3RpdmVseSBiZSBhIG5vbi1m
cmVlIHBpZWNlIG9mIGNvZGUgdGFsa2luZyB3aXRoIGEgR1BMIG9uZSBfd2l0aGluCj4gdGhlIGh5
cGVydmlzb3JfIChub3QgaHYgPD4gZG9tMCkuIEhvdyBmcm93bmVkIHVwb24gaXMgdGhhdD8gOi0p
CgpJIGRvbid0IHRoaW5rIHdlIHBhcnRpY3VsYXJseSB3YW50L25lZWQgYSBtb2R1bGUgbG9hZGVy
IGluIHRoZQpoeXBlcnZpc29yLCByZWdhcmRsZXNzIG9mIHRoZSBsaWNlbnNlIG9mIHRoZSBjb2Rl
IHdoaWNoIGl0IGlzIHVzZWQgdG8KbG9hZC4KClRoZSBsZWdhbGl0eSBvZiBsb2FkaW5nIHlvdXIg
bm9uLUdQTC1jb21wYXRpYmxlIGJsb2IgaW50byB0aGUgaHlwZXJ2aXNvcgppcyBhIHF1ZXN0aW9u
IHdoaWNoIG9ubHkgYSBsYXd5ZXIgY2FuIGFuc3dlci4gWW91IHNob3VsZCBub3QgdGFrZSBsZWdh
bAphZHZpc2UgZnJvbSB0aGlzIG1haWxpbmcgbGlzdC4KCk15IHBlcnNvbmFsIG9waW5pb24gaXMg
dGhhdCBpdCB3b3VsZCBub3QgYmUgYWNjZXB0YWJsZSB0byBsb2FkIG5vbi1HUEwKY29tcGF0aWJs
ZSBjb2RlIGludG8gdGhlIGh5cGVydmlzb3IgdmlhIGFueSBtZWNoYW5pc20sIGl0IGlzIGhhcmQg
dG8gc2VlCmhvdyBhbnkgbG9hZGFibGUgbW9kdWxlIHdvdWxkIG5vdCBiZSBhIGRlcml2ZWQgd29y
ayBvZiB0aGUgaHlwZXJ2aXNvcgphbmQgdGhlcmVmb3JlIHN1YmplY3QgdG8gdGhlIHRlcm1zIG9m
IHRoZSBHUEwuCgpJYW4uCgo+IFVtbW0sIGFzIEknbSB3cml0aW5nIHRoaXMgSSBnZXQgYWxsIGtp
bmRzIG9mIGlkZWFzOiBJIGNvdWxkIHByb2JhYmx5Cj4gY29udmVydCB0aGUgUEUgdG8gRUxGIGFu
ZCBhZGQgcHJpbWl0aXZlIG1vZHVsZSBsb2FkaW5nIHN1cHBvcnQgdG8gWGVuLgo+IFRoZSBtb2R1
bGUgaXRzZWxmLCBob3dldmVyLCB3aWxsIG5vdCBiZSBHUEwuCj4gCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:49:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:49: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 1SeTLc-0004We-OM; Tue, 12 Jun 2012 15:49: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 1SeTLb-0004WZ-3O
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:49:35 +0000
Received: from [85.158.138.51:61887] by server-9.bemta-3.messagelabs.com id
	95/F5-15054-E0567DF4; Tue, 12 Jun 2012 15:49:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339516173!32215667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31285 invoked from network); 12 Jun 2012 15:49:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12973627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:49:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:49:32 +0100
Message-ID: <1339516171.24104.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 16:49:31 +0100
In-Reply-To: <1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle,
 preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> We are going to arrange that libxl, instead of calling
> xc_domain_restore, calls a stub function which forks and execs a
> helper program, so that restore can be asynchronous rather than
> blocking the whole toolstack.
> 
> This stub function will be called libxl__xc_domain_restore.
> 
> However, its prospective call site is unsuitable for a function which
> needs to make a callback, and is buried in two nested single-call-site
> functions which are logically part of the domain creation procedure.
> 
> So we first abolish those single-call-site functions, integrate their
> contents into domain creation in their proper temporal order, and
> break out libxl__xc_domain_restore ready for its reimplementation.
> 
> No functional change - just the following reorganisation:
> 
> * Abolish libxl__domain_restore_common, as it had only one caller.
>   Move its contents into (what was) domain_restore.
> 
> * There is a new stage function domcreate_rebuild_done containing what
>   used to be the bulk of domcreate_bootloader_done, since
>   domcreate_bootloader_done now simply starts the restore (or does the
>   rebuild) and arranges to call the next stage.
> 
> * Move the contents of domain_restore into its correct place in the
>   domain creation sequence.  We put it inside
>   domcreate_bootloader_done, which now either calls

"either" but no "or"? I suppose the or case is call
domcreate_rebuild_done directly?

>   libxl__xc_domain_restore which will call the new function
>   domcreate_rebuild_done.
> 
> * Various general-purpose local variables (`i' etc.) and convenience
>   alias variables need to be shuffled about accordingly.
> 
> * Consequently libxl__toolstack_restore needs to gain external linkage
>   as it is now in a different file to its user.
> 
> * Move the xc_domain_save callbacks struct from the stack into
>   libxl__domain_create_state.
> 
> In general the moved code remains almost identical.  Two returns in
> what used to be libxl__domain_restore_common have been changed to set
> the return value and "goto out", and the call sites for the abolished
> and new functions have been adjusted.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I confirmed at a high level that the same blocks of code exist and are
called in the same overall order, but I didn't do a line by line
comparison of the blocks in question, assuming they really are mostly
motion and adjustments for the new context.

> 
> Changes in v2:
>  * Also move the save callbacks
> ---
>  tools/libxl/Makefile             |    1 +
>  tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
>  tools/libxl/libxl_dom.c          |   45 +-------
>  tools/libxl/libxl_internal.h     |   19 +++-
>  tools/libxl/libxl_save_callout.c |   37 ++++++
>  5 files changed, 206 insertions(+), 140 deletions(-)
>  create mode 100644 tools/libxl/libxl_save_callout.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index e7d5cc2..1d8b80a 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o \
>                         libxl_json.o libxl_aoutils.o \
> +                       libxl_save_callout.o \
>                         libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 4456ae8..4439367 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -21,7 +21,6 @@
>  #include "libxl_arch.h"
> 
>  #include <xc_dom.h>
> -#include <xenguest.h>
> 
>  void libxl_domain_config_init(libxl_domain_config *d_config)
>  {
> @@ -317,89 +316,6 @@ out:
>      return ret;
>  }
> 
> -static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
> -                          uint32_t domid, int fd,
> -                          libxl__domain_build_state *state)
> -{
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
> -    char **vments = NULL, **localents = NULL;
> -    struct timeval start_time;
> -    int i, ret, esave, flags;
> -
> -    ret = libxl__build_pre(gc, domid, info, state);
> -    if (ret)
> -        goto out;
> -
> -    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
> -    if (ret)
> -        goto out;
> -
> -    gettimeofday(&start_time, NULL);
> -
> -    switch (info->type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> -        vments = libxl__calloc(gc, 7, sizeof(char *));
> -        vments[0] = "rtc/timeoffset";
> -        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
> -        vments[2] = "image/ostype";
> -        vments[3] = "hvm";
> -        vments[4] = "start_time";
> -        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> -        break;
> -    case LIBXL_DOMAIN_TYPE_PV:
> -        vments = libxl__calloc(gc, 11, sizeof(char *));
> -        i = 0;
> -        vments[i++] = "image/ostype";
> -        vments[i++] = "linux";
> -        vments[i++] = "image/kernel";
> -        vments[i++] = (char *) state->pv_kernel.path;
> -        vments[i++] = "start_time";
> -        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> -        if (state->pv_ramdisk.path) {
> -            vments[i++] = "image/ramdisk";
> -            vments[i++] = (char *) state->pv_ramdisk.path;
> -        }
> -        if (state->pv_cmdline) {
> -            vments[i++] = "image/cmdline";
> -            vments[i++] = (char *) state->pv_cmdline;
> -        }
> -        break;
> -    default:
> -        ret = ERROR_INVAL;
> -        goto out;
> -    }
> -    ret = libxl__build_post(gc, domid, info, state, vments, localents);
> -    if (ret)
> -        goto out;
> -
> -    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        ret = asprintf(&state->saved_state,
> -                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
> -        ret = (ret < 0) ? ERROR_FAIL : 0;
> -    }
> -
> -out:
> -    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
> -        libxl__file_reference_unmap(&state->pv_kernel);
> -        libxl__file_reference_unmap(&state->pv_ramdisk);
> -    }
> -
> -    esave = errno;
> -
> -    flags = fcntl(fd, F_GETFL);
> -    if (flags == -1) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
> -    } else {
> -        flags &= ~O_NONBLOCK;
> -        if (fcntl(fd, F_SETFL, flags) == -1)
> -            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
> -                         " back to blocking mode");
> -    }
> -
> -    errno = esave;
> -    return ret;
> -}
> -
>  int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
>                         uint32_t *domid)
>  {
> @@ -580,10 +496,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
>  static void domcreate_bootloader_done(libxl__egc *egc,
>                                        libxl__bootloader_state *bl,
>                                        int rc);
> -
>  static void domcreate_console_available(libxl__egc *egc,
>                                          libxl__domain_create_state *dcs);
> 
> +static void domcreate_rebuild_done(libxl__egc *egc,
> +                                   libxl__domain_create_state *dcs,
> +                                   int ret);
> +
>  /* Our own function to clean up and call the user's callback.
>   * The final call in the sequence. */
>  static void domcreate_complete(libxl__egc *egc,
> @@ -671,20 +590,20 @@ static void domcreate_console_available(libxl__egc *egc,
> 
>  static void domcreate_bootloader_done(libxl__egc *egc,
>                                        libxl__bootloader_state *bl,
> -                                      int ret)
> +                                      int rc)
>  {
>      libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
>      STATE_AO_GC(bl->ao);
> -    int i;
> 
>      /* convenience aliases */
>      const uint32_t domid = dcs->guest_domid;
>      libxl_domain_config *const d_config = dcs->guest_config;
> +    libxl_domain_build_info *const info = &d_config->b_info;
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> -    libxl_ctx *const ctx = CTX;
> +    struct restore_callbacks *const callbacks = &dcs->callbacks;
> 
> -    if (ret) goto error_out;
> +    if (rc) domcreate_rebuild_done(egc, dcs, rc);
> 
>      /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
>       * been initialised by the bootloader already.
> @@ -700,12 +619,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>      dcs->dmss.dm.callback = domcreate_devmodel_started;
>      dcs->dmss.callback = domcreate_devmodel_started;
> 
> -    if ( restore_fd >= 0 ) {
> -        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
> +    if ( restore_fd < 0 ) {
> +        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
> +        domcreate_rebuild_done(egc, dcs, rc);
> +        return;
> +    }
> +
> +    /* Restore */
> +
> +    rc = libxl__build_pre(gc, domid, info, state);
> +    if (rc)
> +        goto out;
> +
> +    /* read signature */
> +    int hvm, pae, superpages;
> +    int no_incr_generationid;
> +    switch (info->type) {
> +    case LIBXL_DOMAIN_TYPE_HVM:
> +        hvm = 1;
> +        superpages = 1;
> +        pae = libxl_defbool_val(info->u.hvm.pae);
> +        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
> +        callbacks->toolstack_restore = libxl__toolstack_restore;
> +        callbacks->data = gc;
> +        break;
> +    case LIBXL_DOMAIN_TYPE_PV:
> +        hvm = 0;
> +        superpages = 0;
> +        pae = 1;
> +        no_incr_generationid = 0;
> +        break;
> +    default:
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +    libxl__xc_domain_restore(egc, dcs,
> +                             hvm, pae, superpages, no_incr_generationid);
> +    return;
> +
> + out:
> +    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
> +}
> +
> +void libxl__xc_domain_restore_done(libxl__egc *egc,
> +                                   libxl__domain_create_state *dcs,
> +                                   int ret, int retval, int errnoval)
> +{
> +    STATE_AO_GC(dcs->ao);
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char **vments = NULL, **localents = NULL;
> +    struct timeval start_time;
> +    int i, esave, flags;
> +
> +    /* convenience aliases */
> +    const uint32_t domid = dcs->guest_domid;
> +    libxl_domain_config *const d_config = dcs->guest_config;
> +    libxl_domain_build_info *const info = &d_config->b_info;
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +    const int fd = dcs->restore_fd;
> +
> +    if (ret)
> +        goto out;
> +
> +    if (retval) {
> +        LOGEV(ERROR, errnoval, "restoring domain");
> +        ret = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    gettimeofday(&start_time, NULL);
> +
> +    switch (info->type) {
> +    case LIBXL_DOMAIN_TYPE_HVM:
> +        vments = libxl__calloc(gc, 7, sizeof(char *));
> +        vments[0] = "rtc/timeoffset";
> +        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
> +        vments[2] = "image/ostype";
> +        vments[3] = "hvm";
> +        vments[4] = "start_time";
> +        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> +        break;
> +    case LIBXL_DOMAIN_TYPE_PV:
> +        vments = libxl__calloc(gc, 11, sizeof(char *));
> +        i = 0;
> +        vments[i++] = "image/ostype";
> +        vments[i++] = "linux";
> +        vments[i++] = "image/kernel";
> +        vments[i++] = (char *) state->pv_kernel.path;
> +        vments[i++] = "start_time";
> +        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> +        if (state->pv_ramdisk.path) {
> +            vments[i++] = "image/ramdisk";
> +            vments[i++] = (char *) state->pv_ramdisk.path;
> +        }
> +        if (state->pv_cmdline) {
> +            vments[i++] = "image/cmdline";
> +            vments[i++] = (char *) state->pv_cmdline;
> +        }
> +        break;
> +    default:
> +        ret = ERROR_INVAL;
> +        goto out;
> +    }
> +    ret = libxl__build_post(gc, domid, info, state, vments, localents);
> +    if (ret)
> +        goto out;
> +
> +    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> +        ret = asprintf(&state->saved_state,
> +                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
> +        ret = (ret < 0) ? ERROR_FAIL : 0;
> +    }
> +
> +out:
> +    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
> +        libxl__file_reference_unmap(&state->pv_kernel);
> +        libxl__file_reference_unmap(&state->pv_ramdisk);
> +    }
> +
> +    esave = errno;
> +
> +    flags = fcntl(fd, F_GETFL);
> +    if (flags == -1) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
>      } else {
> -        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
> +        flags &= ~O_NONBLOCK;
> +        if (fcntl(fd, F_SETFL, flags) == -1)
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
> +                         " back to blocking mode");
>      }
> 
> +    errno = esave;
> +    domcreate_rebuild_done(egc, dcs, ret);
> +}
> +
> +static void domcreate_rebuild_done(libxl__egc *egc,
> +                                   libxl__domain_create_state *dcs,
> +                                   int ret)
> +{
> +    STATE_AO_GC(dcs->ao);
> +    int i;
> +
> +    /* convenience aliases */
> +    const uint32_t domid = dcs->guest_domid;
> +    libxl_domain_config *const d_config = dcs->guest_config;
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +    libxl_ctx *const ctx = CTX;
> +
>      if (ret) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
>          ret = ERROR_FAIL;
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index e90030d..1d4e809 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -19,7 +19,6 @@
> 
>  #include <xenctrl.h>
>  #include <xc_dom.h>
> -#include <xenguest.h>
> 
>  #include <xen/hvm/hvm_info_table.h>
> 
> @@ -467,7 +466,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>              domid, phys_offset, node);
>  }
> 
> -static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> +int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>          uint32_t size, void *data)
>  {
>      libxl__gc *gc = data;
> @@ -522,48 +521,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>      return 0;
>  }
> 
> -int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
> -                                 libxl_domain_build_info *info,
> -                                 libxl__domain_build_state *state,
> -                                 int fd)
> -{
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
> -    /* read signature */
> -    int rc;
> -    int hvm, pae, superpages;
> -    struct restore_callbacks callbacks[1];
> -    int no_incr_generationid;
> -    switch (info->type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> -        hvm = 1;
> -        superpages = 1;
> -        pae = libxl_defbool_val(info->u.hvm.pae);
> -        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
> -        callbacks->toolstack_restore = libxl__toolstack_restore;
> -        callbacks->data = gc;
> -        break;
> -    case LIBXL_DOMAIN_TYPE_PV:
> -        hvm = 0;
> -        superpages = 0;
> -        pae = 1;
> -        no_incr_generationid = 0;
> -        break;
> -    default:
> -        return ERROR_INVAL;
> -    }
> -    rc = xc_domain_restore(ctx->xch, fd, domid,
> -                           state->store_port, &state->store_mfn,
> -                           state->store_domid, state->console_port,
> -                           &state->console_mfn, state->console_domid,
> -                           hvm, pae, superpages, no_incr_generationid,
> -                           &state->vm_generationid_addr, callbacks);
> -    if ( rc ) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
> -        return ERROR_FAIL;
> -    }
> -    return 0;
> -}
> -
>  static int libxl__domain_suspend_common_switch_qemu_logdirty
>                                 (int domid, unsigned int enable, void *data)
>  {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index f22bf94..28478ea 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -46,6 +46,7 @@
> 
>  #include <xenstore.h>
>  #include <xenctrl.h>
> +#include <xenguest.h>
> 
>  #include "xentoollog.h"
> 
> @@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>                                   const char *old_name, const char *new_name,
>                                   xs_transaction_t trans);
> 
> -_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
> -                                         libxl_domain_build_info *info,
> -                                         libxl__domain_build_state *state,
> -                                         int fd);
> +_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> +                                     uint32_t size, void *data);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
> @@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
>      libxl__stub_dm_spawn_state dmss;
>          /* If we're not doing stubdom, we use only dmss.dm,
>           * for the non-stubdom device model. */
> +    struct restore_callbacks callbacks;
>  };
> 
>  /*----- Domain suspend (save) functions -----*/
> @@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                           int live, int debug,
>                                           const libxl_domain_remus_info *r_info);
> 
> +/* calls libxl__xc_domain_restore_done when done */
> +_hidden void libxl__xc_domain_restore(libxl__egc *egc,
> +                                      libxl__domain_create_state *dcs,
> +                                      int hvm, int pae, int superpages,
> +                                      int no_incr_generationid);
> +/* If rc==0 then retval is the return value from xc_domain_save
> + * and errnoval is the errno value it provided.
> + * If rc!=0, retval and errnoval are undefined. */
> +_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
> +                                           libxl__domain_create_state *dcs,
> +                                           int rc, int retval, int errnoval);
> 
> 
>  /*
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> new file mode 100644
> index 0000000..2f8db9f
> --- /dev/null
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_osdeps.h"
> +
> +#include "libxl_internal.h"
> +
> +void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
> +                              int hvm, int pae, int superpages,
> +                              int no_incr_generationid)
> +{
> +    STATE_AO_GC(dcs->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = dcs->guest_domid;
> +    const int restore_fd = dcs->restore_fd;
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +
> +    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
> +                              state->store_port, &state->store_mfn,
> +                              state->store_domid, state->console_port,
> +                              &state->console_mfn, state->console_domid,
> +                              hvm, pae, superpages, no_incr_generationid,
> +                              &state->vm_generationid_addr, &dcs->callbacks);
> +    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
> +}
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 15:49:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 15:49: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 1SeTLc-0004We-OM; Tue, 12 Jun 2012 15:49: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 1SeTLb-0004WZ-3O
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 15:49:35 +0000
Received: from [85.158.138.51:61887] by server-9.bemta-3.messagelabs.com id
	95/F5-15054-E0567DF4; Tue, 12 Jun 2012 15:49:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339516173!32215667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31285 invoked from network); 12 Jun 2012 15:49:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 15:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12973627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 15:49:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 16:49:32 +0100
Message-ID: <1339516171.24104.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 16:49:31 +0100
In-Reply-To: <1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle,
 preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> We are going to arrange that libxl, instead of calling
> xc_domain_restore, calls a stub function which forks and execs a
> helper program, so that restore can be asynchronous rather than
> blocking the whole toolstack.
> 
> This stub function will be called libxl__xc_domain_restore.
> 
> However, its prospective call site is unsuitable for a function which
> needs to make a callback, and is buried in two nested single-call-site
> functions which are logically part of the domain creation procedure.
> 
> So we first abolish those single-call-site functions, integrate their
> contents into domain creation in their proper temporal order, and
> break out libxl__xc_domain_restore ready for its reimplementation.
> 
> No functional change - just the following reorganisation:
> 
> * Abolish libxl__domain_restore_common, as it had only one caller.
>   Move its contents into (what was) domain_restore.
> 
> * There is a new stage function domcreate_rebuild_done containing what
>   used to be the bulk of domcreate_bootloader_done, since
>   domcreate_bootloader_done now simply starts the restore (or does the
>   rebuild) and arranges to call the next stage.
> 
> * Move the contents of domain_restore into its correct place in the
>   domain creation sequence.  We put it inside
>   domcreate_bootloader_done, which now either calls

"either" but no "or"? I suppose the or case is call
domcreate_rebuild_done directly?

>   libxl__xc_domain_restore which will call the new function
>   domcreate_rebuild_done.
> 
> * Various general-purpose local variables (`i' etc.) and convenience
>   alias variables need to be shuffled about accordingly.
> 
> * Consequently libxl__toolstack_restore needs to gain external linkage
>   as it is now in a different file to its user.
> 
> * Move the xc_domain_save callbacks struct from the stack into
>   libxl__domain_create_state.
> 
> In general the moved code remains almost identical.  Two returns in
> what used to be libxl__domain_restore_common have been changed to set
> the return value and "goto out", and the call sites for the abolished
> and new functions have been adjusted.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I confirmed at a high level that the same blocks of code exist and are
called in the same overall order, but I didn't do a line by line
comparison of the blocks in question, assuming they really are mostly
motion and adjustments for the new context.

> 
> Changes in v2:
>  * Also move the save callbacks
> ---
>  tools/libxl/Makefile             |    1 +
>  tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
>  tools/libxl/libxl_dom.c          |   45 +-------
>  tools/libxl/libxl_internal.h     |   19 +++-
>  tools/libxl/libxl_save_callout.c |   37 ++++++
>  5 files changed, 206 insertions(+), 140 deletions(-)
>  create mode 100644 tools/libxl/libxl_save_callout.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index e7d5cc2..1d8b80a 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o \
>                         libxl_json.o libxl_aoutils.o \
> +                       libxl_save_callout.o \
>                         libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 4456ae8..4439367 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -21,7 +21,6 @@
>  #include "libxl_arch.h"
> 
>  #include <xc_dom.h>
> -#include <xenguest.h>
> 
>  void libxl_domain_config_init(libxl_domain_config *d_config)
>  {
> @@ -317,89 +316,6 @@ out:
>      return ret;
>  }
> 
> -static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
> -                          uint32_t domid, int fd,
> -                          libxl__domain_build_state *state)
> -{
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
> -    char **vments = NULL, **localents = NULL;
> -    struct timeval start_time;
> -    int i, ret, esave, flags;
> -
> -    ret = libxl__build_pre(gc, domid, info, state);
> -    if (ret)
> -        goto out;
> -
> -    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
> -    if (ret)
> -        goto out;
> -
> -    gettimeofday(&start_time, NULL);
> -
> -    switch (info->type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> -        vments = libxl__calloc(gc, 7, sizeof(char *));
> -        vments[0] = "rtc/timeoffset";
> -        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
> -        vments[2] = "image/ostype";
> -        vments[3] = "hvm";
> -        vments[4] = "start_time";
> -        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> -        break;
> -    case LIBXL_DOMAIN_TYPE_PV:
> -        vments = libxl__calloc(gc, 11, sizeof(char *));
> -        i = 0;
> -        vments[i++] = "image/ostype";
> -        vments[i++] = "linux";
> -        vments[i++] = "image/kernel";
> -        vments[i++] = (char *) state->pv_kernel.path;
> -        vments[i++] = "start_time";
> -        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> -        if (state->pv_ramdisk.path) {
> -            vments[i++] = "image/ramdisk";
> -            vments[i++] = (char *) state->pv_ramdisk.path;
> -        }
> -        if (state->pv_cmdline) {
> -            vments[i++] = "image/cmdline";
> -            vments[i++] = (char *) state->pv_cmdline;
> -        }
> -        break;
> -    default:
> -        ret = ERROR_INVAL;
> -        goto out;
> -    }
> -    ret = libxl__build_post(gc, domid, info, state, vments, localents);
> -    if (ret)
> -        goto out;
> -
> -    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        ret = asprintf(&state->saved_state,
> -                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
> -        ret = (ret < 0) ? ERROR_FAIL : 0;
> -    }
> -
> -out:
> -    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
> -        libxl__file_reference_unmap(&state->pv_kernel);
> -        libxl__file_reference_unmap(&state->pv_ramdisk);
> -    }
> -
> -    esave = errno;
> -
> -    flags = fcntl(fd, F_GETFL);
> -    if (flags == -1) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
> -    } else {
> -        flags &= ~O_NONBLOCK;
> -        if (fcntl(fd, F_SETFL, flags) == -1)
> -            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
> -                         " back to blocking mode");
> -    }
> -
> -    errno = esave;
> -    return ret;
> -}
> -
>  int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
>                         uint32_t *domid)
>  {
> @@ -580,10 +496,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
>  static void domcreate_bootloader_done(libxl__egc *egc,
>                                        libxl__bootloader_state *bl,
>                                        int rc);
> -
>  static void domcreate_console_available(libxl__egc *egc,
>                                          libxl__domain_create_state *dcs);
> 
> +static void domcreate_rebuild_done(libxl__egc *egc,
> +                                   libxl__domain_create_state *dcs,
> +                                   int ret);
> +
>  /* Our own function to clean up and call the user's callback.
>   * The final call in the sequence. */
>  static void domcreate_complete(libxl__egc *egc,
> @@ -671,20 +590,20 @@ static void domcreate_console_available(libxl__egc *egc,
> 
>  static void domcreate_bootloader_done(libxl__egc *egc,
>                                        libxl__bootloader_state *bl,
> -                                      int ret)
> +                                      int rc)
>  {
>      libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
>      STATE_AO_GC(bl->ao);
> -    int i;
> 
>      /* convenience aliases */
>      const uint32_t domid = dcs->guest_domid;
>      libxl_domain_config *const d_config = dcs->guest_config;
> +    libxl_domain_build_info *const info = &d_config->b_info;
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> -    libxl_ctx *const ctx = CTX;
> +    struct restore_callbacks *const callbacks = &dcs->callbacks;
> 
> -    if (ret) goto error_out;
> +    if (rc) domcreate_rebuild_done(egc, dcs, rc);
> 
>      /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
>       * been initialised by the bootloader already.
> @@ -700,12 +619,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>      dcs->dmss.dm.callback = domcreate_devmodel_started;
>      dcs->dmss.callback = domcreate_devmodel_started;
> 
> -    if ( restore_fd >= 0 ) {
> -        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
> +    if ( restore_fd < 0 ) {
> +        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
> +        domcreate_rebuild_done(egc, dcs, rc);
> +        return;
> +    }
> +
> +    /* Restore */
> +
> +    rc = libxl__build_pre(gc, domid, info, state);
> +    if (rc)
> +        goto out;
> +
> +    /* read signature */
> +    int hvm, pae, superpages;
> +    int no_incr_generationid;
> +    switch (info->type) {
> +    case LIBXL_DOMAIN_TYPE_HVM:
> +        hvm = 1;
> +        superpages = 1;
> +        pae = libxl_defbool_val(info->u.hvm.pae);
> +        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
> +        callbacks->toolstack_restore = libxl__toolstack_restore;
> +        callbacks->data = gc;
> +        break;
> +    case LIBXL_DOMAIN_TYPE_PV:
> +        hvm = 0;
> +        superpages = 0;
> +        pae = 1;
> +        no_incr_generationid = 0;
> +        break;
> +    default:
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +    libxl__xc_domain_restore(egc, dcs,
> +                             hvm, pae, superpages, no_incr_generationid);
> +    return;
> +
> + out:
> +    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
> +}
> +
> +void libxl__xc_domain_restore_done(libxl__egc *egc,
> +                                   libxl__domain_create_state *dcs,
> +                                   int ret, int retval, int errnoval)
> +{
> +    STATE_AO_GC(dcs->ao);
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char **vments = NULL, **localents = NULL;
> +    struct timeval start_time;
> +    int i, esave, flags;
> +
> +    /* convenience aliases */
> +    const uint32_t domid = dcs->guest_domid;
> +    libxl_domain_config *const d_config = dcs->guest_config;
> +    libxl_domain_build_info *const info = &d_config->b_info;
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +    const int fd = dcs->restore_fd;
> +
> +    if (ret)
> +        goto out;
> +
> +    if (retval) {
> +        LOGEV(ERROR, errnoval, "restoring domain");
> +        ret = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    gettimeofday(&start_time, NULL);
> +
> +    switch (info->type) {
> +    case LIBXL_DOMAIN_TYPE_HVM:
> +        vments = libxl__calloc(gc, 7, sizeof(char *));
> +        vments[0] = "rtc/timeoffset";
> +        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
> +        vments[2] = "image/ostype";
> +        vments[3] = "hvm";
> +        vments[4] = "start_time";
> +        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> +        break;
> +    case LIBXL_DOMAIN_TYPE_PV:
> +        vments = libxl__calloc(gc, 11, sizeof(char *));
> +        i = 0;
> +        vments[i++] = "image/ostype";
> +        vments[i++] = "linux";
> +        vments[i++] = "image/kernel";
> +        vments[i++] = (char *) state->pv_kernel.path;
> +        vments[i++] = "start_time";
> +        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
> +        if (state->pv_ramdisk.path) {
> +            vments[i++] = "image/ramdisk";
> +            vments[i++] = (char *) state->pv_ramdisk.path;
> +        }
> +        if (state->pv_cmdline) {
> +            vments[i++] = "image/cmdline";
> +            vments[i++] = (char *) state->pv_cmdline;
> +        }
> +        break;
> +    default:
> +        ret = ERROR_INVAL;
> +        goto out;
> +    }
> +    ret = libxl__build_post(gc, domid, info, state, vments, localents);
> +    if (ret)
> +        goto out;
> +
> +    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
> +        ret = asprintf(&state->saved_state,
> +                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
> +        ret = (ret < 0) ? ERROR_FAIL : 0;
> +    }
> +
> +out:
> +    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
> +        libxl__file_reference_unmap(&state->pv_kernel);
> +        libxl__file_reference_unmap(&state->pv_ramdisk);
> +    }
> +
> +    esave = errno;
> +
> +    flags = fcntl(fd, F_GETFL);
> +    if (flags == -1) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
>      } else {
> -        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
> +        flags &= ~O_NONBLOCK;
> +        if (fcntl(fd, F_SETFL, flags) == -1)
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
> +                         " back to blocking mode");
>      }
> 
> +    errno = esave;
> +    domcreate_rebuild_done(egc, dcs, ret);
> +}
> +
> +static void domcreate_rebuild_done(libxl__egc *egc,
> +                                   libxl__domain_create_state *dcs,
> +                                   int ret)
> +{
> +    STATE_AO_GC(dcs->ao);
> +    int i;
> +
> +    /* convenience aliases */
> +    const uint32_t domid = dcs->guest_domid;
> +    libxl_domain_config *const d_config = dcs->guest_config;
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +    libxl_ctx *const ctx = CTX;
> +
>      if (ret) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
>          ret = ERROR_FAIL;
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index e90030d..1d4e809 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -19,7 +19,6 @@
> 
>  #include <xenctrl.h>
>  #include <xc_dom.h>
> -#include <xenguest.h>
> 
>  #include <xen/hvm/hvm_info_table.h>
> 
> @@ -467,7 +466,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>              domid, phys_offset, node);
>  }
> 
> -static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> +int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>          uint32_t size, void *data)
>  {
>      libxl__gc *gc = data;
> @@ -522,48 +521,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>      return 0;
>  }
> 
> -int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
> -                                 libxl_domain_build_info *info,
> -                                 libxl__domain_build_state *state,
> -                                 int fd)
> -{
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
> -    /* read signature */
> -    int rc;
> -    int hvm, pae, superpages;
> -    struct restore_callbacks callbacks[1];
> -    int no_incr_generationid;
> -    switch (info->type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> -        hvm = 1;
> -        superpages = 1;
> -        pae = libxl_defbool_val(info->u.hvm.pae);
> -        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
> -        callbacks->toolstack_restore = libxl__toolstack_restore;
> -        callbacks->data = gc;
> -        break;
> -    case LIBXL_DOMAIN_TYPE_PV:
> -        hvm = 0;
> -        superpages = 0;
> -        pae = 1;
> -        no_incr_generationid = 0;
> -        break;
> -    default:
> -        return ERROR_INVAL;
> -    }
> -    rc = xc_domain_restore(ctx->xch, fd, domid,
> -                           state->store_port, &state->store_mfn,
> -                           state->store_domid, state->console_port,
> -                           &state->console_mfn, state->console_domid,
> -                           hvm, pae, superpages, no_incr_generationid,
> -                           &state->vm_generationid_addr, callbacks);
> -    if ( rc ) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
> -        return ERROR_FAIL;
> -    }
> -    return 0;
> -}
> -
>  static int libxl__domain_suspend_common_switch_qemu_logdirty
>                                 (int domid, unsigned int enable, void *data)
>  {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index f22bf94..28478ea 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -46,6 +46,7 @@
> 
>  #include <xenstore.h>
>  #include <xenctrl.h>
> +#include <xenguest.h>
> 
>  #include "xentoollog.h"
> 
> @@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>                                   const char *old_name, const char *new_name,
>                                   xs_transaction_t trans);
> 
> -_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
> -                                         libxl_domain_build_info *info,
> -                                         libxl__domain_build_state *state,
> -                                         int fd);
> +_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> +                                     uint32_t size, void *data);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
> @@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
>      libxl__stub_dm_spawn_state dmss;
>          /* If we're not doing stubdom, we use only dmss.dm,
>           * for the non-stubdom device model. */
> +    struct restore_callbacks callbacks;
>  };
> 
>  /*----- Domain suspend (save) functions -----*/
> @@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                           int live, int debug,
>                                           const libxl_domain_remus_info *r_info);
> 
> +/* calls libxl__xc_domain_restore_done when done */
> +_hidden void libxl__xc_domain_restore(libxl__egc *egc,
> +                                      libxl__domain_create_state *dcs,
> +                                      int hvm, int pae, int superpages,
> +                                      int no_incr_generationid);
> +/* If rc==0 then retval is the return value from xc_domain_save
> + * and errnoval is the errno value it provided.
> + * If rc!=0, retval and errnoval are undefined. */
> +_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
> +                                           libxl__domain_create_state *dcs,
> +                                           int rc, int retval, int errnoval);
> 
> 
>  /*
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> new file mode 100644
> index 0000000..2f8db9f
> --- /dev/null
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_osdeps.h"
> +
> +#include "libxl_internal.h"
> +
> +void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
> +                              int hvm, int pae, int superpages,
> +                              int no_incr_generationid)
> +{
> +    STATE_AO_GC(dcs->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = dcs->guest_domid;
> +    const int restore_fd = dcs->restore_fd;
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +
> +    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
> +                              state->store_port, &state->store_mfn,
> +                              state->store_domid, state->console_port,
> +                              &state->console_mfn, state->console_domid,
> +                              hvm, pae, superpages, no_incr_generationid,
> +                              &state->vm_generationid_addr, &dcs->callbacks);
> +    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
> +}
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeTe1-0005Yd-Pp; Tue, 12 Jun 2012 16:08:37 +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 1SeTe0-0005YS-EI
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 16:08:36 +0000
Received: from [85.158.143.35:17342] by server-3.bemta-4.messagelabs.com id
	C8/BC-05808-38967DF4; Tue, 12 Jun 2012 16:08:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339517313!5519127!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20181 invoked from network); 12 Jun 2012 16:08:35 -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;
	12 Jun 2012 16:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198451662"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:08:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 12:08:23 -0400
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 1SeTdm-000563-Fm;
	Tue, 12 Jun 2012 17:08:22 +0100
Message-ID: <4FD76976.2020203@citrix.com>
Date: Tue, 12 Jun 2012 17:08:22 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
In-Reply-To: <4FD778C802000078000897EF@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Wei Wang <wei.wang2@amd.com>, Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/06/12 16:13, Jan Beulich wrote:
>>>> On 12.06.12 at 14:02, Wei Wang <wei.wang2@amd.com> wrote:
>> I had attached a revised patch, please check it.
> While the patch technically looks better now, you didn't eliminate
> my objections to the approach you take, nor did you comment on
> the proposed alternative.
>
> A fundamental problem is that your IOMMUs show up as a "normal"
> PCI devices, breaking the separation between what is being
> managed by the hypervisor vs by the Dom0 kernel. (This even
> allows something as odd as passing through an IOMMU to a
> DomU, which would clearly upset the hypervisor.)
>
>> I found that the following Linux commit triggers this issue. It has been 
>> included into 3.4 pv_ops.
>>
>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>    Author: Eric W. Biederman <ebiederm@xmission.com>
>>    Date:   Mon Oct 17 11:46:06 2011 -0700
>>
>>    PCI: msi: Disable msi interrupts when we initialize a pci device "
> Thanks for locating this. As it stands, it is incomplete though
> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
> it won't have a means to suppress the "screaming" interrupts.
>
> Jan

I feel that the correct solution would be for Xen to hide the PCI
devices from dom0.  Xen already hides the DMAR ACPI table (by turning it
to an XMAR table), and this would be the logical way to proceed now that
IOMMU internals are appearing as PCI devices.

( A similar issue comes into play now that newer generations of CPUs are
exposing CPU internals as PCI devices )

~Andrew

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeTe1-0005Yd-Pp; Tue, 12 Jun 2012 16:08:37 +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 1SeTe0-0005YS-EI
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 16:08:36 +0000
Received: from [85.158.143.35:17342] by server-3.bemta-4.messagelabs.com id
	C8/BC-05808-38967DF4; Tue, 12 Jun 2012 16:08:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339517313!5519127!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk0MDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20181 invoked from network); 12 Jun 2012 16:08:35 -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;
	12 Jun 2012 16:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="198451662"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 12:08:23 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 12:08:23 -0400
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 1SeTdm-000563-Fm;
	Tue, 12 Jun 2012 17:08:22 +0100
Message-ID: <4FD76976.2020203@citrix.com>
Date: Tue, 12 Jun 2012 17:08:22 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
In-Reply-To: <4FD778C802000078000897EF@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Wei Wang <wei.wang2@amd.com>, Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/06/12 16:13, Jan Beulich wrote:
>>>> On 12.06.12 at 14:02, Wei Wang <wei.wang2@amd.com> wrote:
>> I had attached a revised patch, please check it.
> While the patch technically looks better now, you didn't eliminate
> my objections to the approach you take, nor did you comment on
> the proposed alternative.
>
> A fundamental problem is that your IOMMUs show up as a "normal"
> PCI devices, breaking the separation between what is being
> managed by the hypervisor vs by the Dom0 kernel. (This even
> allows something as odd as passing through an IOMMU to a
> DomU, which would clearly upset the hypervisor.)
>
>> I found that the following Linux commit triggers this issue. It has been 
>> included into 3.4 pv_ops.
>>
>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>    Author: Eric W. Biederman <ebiederm@xmission.com>
>>    Date:   Mon Oct 17 11:46:06 2011 -0700
>>
>>    PCI: msi: Disable msi interrupts when we initialize a pci device "
> Thanks for locating this. As it stands, it is incomplete though
> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
> it won't have a means to suppress the "screaming" interrupts.
>
> Jan

I feel that the correct solution would be for Xen to hide the PCI
devices from dom0.  Xen already hides the DMAR ACPI table (by turning it
to an XMAR table), and this would be the logical way to proceed now that
IOMMU internals are appearing as PCI devices.

( A similar issue comes into play now that newer generations of CPUs are
exposing CPU internals as PCI devices )

~Andrew

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:30:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:30: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 1SeTyl-000627-8c; Tue, 12 Jun 2012 16:30:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SeTyj-000621-8S
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 16:30:01 +0000
Received: from [85.158.138.51:9616] by server-12.bemta-3.messagelabs.com id
	79/F5-24185-88E67DF4; Tue, 12 Jun 2012 16:30:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339518599!32188960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26827 invoked from network); 12 Jun 2012 16:29:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 16:29:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12974871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 16:29:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 17:29:42 +0100
Message-ID: <1339518581.24104.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 12 Jun 2012 17:29:41 +0100
In-Reply-To: <alpine.DEB.2.02.1206121121440.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
	<20437.63222.655663.76990@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206121121440.14957@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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 Tue, 2012-06-12 at 11:30 +0100, Stefano Stabellini wrote:
> On Mon, 11 Jun 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > > So what is the default configuration ?
> > > 
> > > The default is on.
[...]
> virtfs is not enabled unless you pass specific arguments to QEMU,
> which we do not.

OK, so it doesn't really default to on as you said above. Rather the
feature is compiled in but disabled by default. This is much safer.

> Besides saying that an open source technology X is dangerous because it
> has been developed by a different community than ours, without giving
> any technical reasons for it, is just spreading FUD.
[...]

I do think we need to consider the impact of (perhaps unintentionally)
enabling things which may cause interactions which the relevant upstream
and/or we may not have anticipated. 

We especially need to consider this in the case where a new thing is
enabled by default -- which is no longer believed to be the case with
virtfs but imagine for example if virtfs were on by default then the
admin might need to take steps to lock down the directory which it
exported to the guest by default or something. That might come as a
surprise if the admin didn't actually ask for virtfs and has know idea
that it even exists.

Since virtfs is actually off by default I don't think we have much to
worry about.

> > And this is relevant because we're now using upstream qemu 1.0 by
> > default for some guests.
> 
> Only in PV guests, for which this discussion is not relevant.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:30:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:30: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 1SeTyl-000627-8c; Tue, 12 Jun 2012 16:30:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SeTyj-000621-8S
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 16:30:01 +0000
Received: from [85.158.138.51:9616] by server-12.bemta-3.messagelabs.com id
	79/F5-24185-88E67DF4; Tue, 12 Jun 2012 16:30:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339518599!32188960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26827 invoked from network); 12 Jun 2012 16:29:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 16:29:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12974871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 16:29:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 17:29:42 +0100
Message-ID: <1339518581.24104.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 12 Jun 2012 17:29:41 +0100
In-Reply-To: <alpine.DEB.2.02.1206121121440.14957@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206061152550.6030@kaball.uk.xensource.com>
	<20432.58433.896128.959563@mariner.uk.xensource.com>
	<20432.59018.420423.884384@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081116080.14957@kaball.uk.xensource.com>
	<20433.56825.315554.351483@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206081217550.14957@kaball.uk.xensource.com>
	<20433.57755.274531.968750@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206111042520.14957@kaball.uk.xensource.com>
	<20437.63222.655663.76990@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1206121121440.14957@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] disable virtfs compilation by default in
 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 Tue, 2012-06-12 at 11:30 +0100, Stefano Stabellini wrote:
> On Mon, 11 Jun 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] disable virtfs compilation by default in upstream QEMU"):
> > > On Fri, 8 Jun 2012, Ian Jackson wrote:
> > > > So what is the default configuration ?
> > > 
> > > The default is on.
[...]
> virtfs is not enabled unless you pass specific arguments to QEMU,
> which we do not.

OK, so it doesn't really default to on as you said above. Rather the
feature is compiled in but disabled by default. This is much safer.

> Besides saying that an open source technology X is dangerous because it
> has been developed by a different community than ours, without giving
> any technical reasons for it, is just spreading FUD.
[...]

I do think we need to consider the impact of (perhaps unintentionally)
enabling things which may cause interactions which the relevant upstream
and/or we may not have anticipated. 

We especially need to consider this in the case where a new thing is
enabled by default -- which is no longer believed to be the case with
virtfs but imagine for example if virtfs were on by default then the
admin might need to take steps to lock down the directory which it
exported to the guest by default or something. That might come as a
surprise if the admin didn't actually ask for virtfs and has know idea
that it even exists.

Since virtfs is actually off by default I don't think we have much to
worry about.

> > And this is relevant because we're now using upstream qemu 1.0 by
> > default for some guests.
> 
> Only in PV guests, for which this discussion is not relevant.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:30:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeTym-00062I-Kk; Tue, 12 Jun 2012 16:30:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeTyl-000626-BT
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:30:03 +0000
Received: from [85.158.143.35:26102] by server-1.bemta-4.messagelabs.com id
	39/BC-24392-A8E67DF4; Tue, 12 Jun 2012 16:30:02 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339518601!4057169!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3108 invoked from network); 12 Jun 2012 16:30:01 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 16:30:01 -0000
Received: (qmail 7040 invoked from network); 12 Jun 2012 19:29:59 +0300
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.3.14894, Dats: 204463,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Enabled,
	Score: 0(0)], APM: [Enabled, Score: 500, Flags: NN_LEGIT_VALID_REPLY;
	NN_NO_LINK_NMD; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO;
	NN_LEGIT_ML_MAIL_LIST_ADN], SGN: [Enabled], URL: [Enabled], URI DNSBL:
	[Disabled], SQMD: [Enabled, Hits: none, MD5:
	703b2fd5a455880af8d00ebcd2d993ee.fuzzy.fzrbl.org], RTDA: [Enabled,
	Hit: No, Details: v0.0; ], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.42575
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com;
	b=eA/23Q6EqeV7HUBLGgTRZtY9QZnVF98yVaDhcBTIyjFBG6/YRNeHczk6uT3hnxQYrG6LAWnHkTunPmus8wLzvJrXuyM3kfKRcxgpFT7KiGhPDNXhyuwXs3xxOYpLuexQWZy1tFkbMYuoz7Coig7+drLYGdc7oNgaNOg8/JapubI=
	; 
Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115)
	by mail.bitdefender.com with SMTP; 12 Jun 2012 19:29:59 +0300
Date: Tue, 12 Jun 2012 19:29:59 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <20120612192959.563946f2@mdontu-l.dsd.ro>
In-Reply-To: <1339515595.24104.95.camel@zakaz.uk.xensource.com>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
Organization: Home
Mime-Version: 1.0
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAxMiBKdW4gMjAxMiAxNjozOTo1NSArMDEwMCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
SSBkb24ndCB0aGluayB3ZSBwYXJ0aWN1bGFybHkgd2FudC9uZWVkIGEgbW9kdWxlIGxvYWRlciBp
biB0aGUKPiBoeXBlcnZpc29yLCByZWdhcmRsZXNzIG9mIHRoZSBsaWNlbnNlIG9mIHRoZSBjb2Rl
IHdoaWNoIGl0IGlzIHVzZWQgdG8KPiBsb2FkLgo+IAoKSSBzZWUuIE9LLiBJIHdpbGwgbm90IGlu
c2lzdCBvbiB0aGlzLgoKPiBUaGUgbGVnYWxpdHkgb2YgbG9hZGluZyB5b3VyIG5vbi1HUEwtY29t
cGF0aWJsZSBibG9iIGludG8gdGhlCj4gaHlwZXJ2aXNvciBpcyBhIHF1ZXN0aW9uIHdoaWNoIG9u
bHkgYSBsYXd5ZXIgY2FuIGFuc3dlci4gWW91IHNob3VsZAo+IG5vdCB0YWtlIGxlZ2FsIGFkdmlz
ZSBmcm9tIHRoaXMgbWFpbGluZyBsaXN0Lgo+IAo+IE15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhh
dCBpdCB3b3VsZCBub3QgYmUgYWNjZXB0YWJsZSB0byBsb2FkIG5vbi1HUEwKPiBjb21wYXRpYmxl
IGNvZGUgaW50byB0aGUgaHlwZXJ2aXNvciB2aWEgYW55IG1lY2hhbmlzbSwgaXQgaXMgaGFyZCB0
bwo+IHNlZSBob3cgYW55IGxvYWRhYmxlIG1vZHVsZSB3b3VsZCBub3QgYmUgYSBkZXJpdmVkIHdv
cmsgb2YgdGhlCj4gaHlwZXJ2aXNvciBhbmQgdGhlcmVmb3JlIHN1YmplY3QgdG8gdGhlIHRlcm1z
IG9mIHRoZSBHUEwuCj4gCgpUYWtpbmcgR1BMIGFzIGlzIHdvdWxkIGhhdmUgYW5zd2VyZWQgbXkg
aW5pdGlhbCBxdWVzdGlvbiBxdWlja2x5LCBidXQKc29tZSBwcm9qZWN0cyAoc3VjaCBhcyB0aGUg
TGludXgga2VybmVsKSBoYXZlIG9wdGVkIHRvIGFkZCBleHBsaWNpdApsaWNlbnNpbmcgZXhjZXB0
aW9ucyBmb3IgY2VydGFpbiBmdW5jdGlvbnMuIFRoaXMgaXMgd2hhdCBhbGxvd2VkIE5WSURJQQph
bmQgQVRJIChBTUQpIHRvIHByb3ZpZGUgZHJpdmVycyBmb3IgdGhlaXIgZ3JhcGhpYyBjYXJkcyBv
biBMaW51eC4KClVuZm9ydHVuYXRlbHkgdGhlIG5hdHVyZSBvZiByb290a2l0IHRhcmdldGVkIG1l
bW9yeSBpbnRyb3NwZWN0aW9uCnJlcXVpcmVzIHRoYXQgaXQgd29ya3MgdmVyeSBjbG9zZSB0byB0
aGUgaHYuIEkgd291bGQndmUgbG92ZWQgdG8gaGF2ZQppdCBpbiBkb20wIChiYXNlZCBvbiBWTUl0
b29scyBvciBzb21lIGV4dGVuc2lvbiBvZiBpdCkgYnV0IEkgZm9yZXNlZSBhCmxvdCBvZiB0cmFu
c2l0aW9ucyBmcm9tIGh2IC0+IGRvbTAgYW5kIGJhY2suIEVub3VnaCB0byBzbG93IGV2ZXJ5dGhp
bmcKZG93biB0byB1bmJlYXJhYmxlIHNwZWVkcy4KCi0tIApNaWhhaSBEb27Im3UKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:30:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeTym-00062I-Kk; Tue, 12 Jun 2012 16:30:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeTyl-000626-BT
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:30:03 +0000
Received: from [85.158.143.35:26102] by server-1.bemta-4.messagelabs.com id
	39/BC-24392-A8E67DF4; Tue, 12 Jun 2012 16:30:02 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339518601!4057169!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3108 invoked from network); 12 Jun 2012 16:30:01 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 16:30:01 -0000
Received: (qmail 7040 invoked from network); 12 Jun 2012 19:29:59 +0300
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.3.14894, Dats: 204463,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Enabled,
	Score: 0(0)], APM: [Enabled, Score: 500, Flags: NN_LEGIT_VALID_REPLY;
	NN_NO_LINK_NMD; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO;
	NN_LEGIT_ML_MAIL_LIST_ADN], SGN: [Enabled], URL: [Enabled], URI DNSBL:
	[Disabled], SQMD: [Enabled, Hits: none, MD5:
	703b2fd5a455880af8d00ebcd2d993ee.fuzzy.fzrbl.org], RTDA: [Enabled,
	Hit: No, Details: v0.0; ], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.42575
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com;
	b=eA/23Q6EqeV7HUBLGgTRZtY9QZnVF98yVaDhcBTIyjFBG6/YRNeHczk6uT3hnxQYrG6LAWnHkTunPmus8wLzvJrXuyM3kfKRcxgpFT7KiGhPDNXhyuwXs3xxOYpLuexQWZy1tFkbMYuoz7Coig7+drLYGdc7oNgaNOg8/JapubI=
	; 
Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115)
	by mail.bitdefender.com with SMTP; 12 Jun 2012 19:29:59 +0300
Date: Tue, 12 Jun 2012 19:29:59 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <20120612192959.563946f2@mdontu-l.dsd.ro>
In-Reply-To: <1339515595.24104.95.camel@zakaz.uk.xensource.com>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
Organization: Home
Mime-Version: 1.0
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAxMiBKdW4gMjAxMiAxNjozOTo1NSArMDEwMCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
SSBkb24ndCB0aGluayB3ZSBwYXJ0aWN1bGFybHkgd2FudC9uZWVkIGEgbW9kdWxlIGxvYWRlciBp
biB0aGUKPiBoeXBlcnZpc29yLCByZWdhcmRsZXNzIG9mIHRoZSBsaWNlbnNlIG9mIHRoZSBjb2Rl
IHdoaWNoIGl0IGlzIHVzZWQgdG8KPiBsb2FkLgo+IAoKSSBzZWUuIE9LLiBJIHdpbGwgbm90IGlu
c2lzdCBvbiB0aGlzLgoKPiBUaGUgbGVnYWxpdHkgb2YgbG9hZGluZyB5b3VyIG5vbi1HUEwtY29t
cGF0aWJsZSBibG9iIGludG8gdGhlCj4gaHlwZXJ2aXNvciBpcyBhIHF1ZXN0aW9uIHdoaWNoIG9u
bHkgYSBsYXd5ZXIgY2FuIGFuc3dlci4gWW91IHNob3VsZAo+IG5vdCB0YWtlIGxlZ2FsIGFkdmlz
ZSBmcm9tIHRoaXMgbWFpbGluZyBsaXN0Lgo+IAo+IE15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhh
dCBpdCB3b3VsZCBub3QgYmUgYWNjZXB0YWJsZSB0byBsb2FkIG5vbi1HUEwKPiBjb21wYXRpYmxl
IGNvZGUgaW50byB0aGUgaHlwZXJ2aXNvciB2aWEgYW55IG1lY2hhbmlzbSwgaXQgaXMgaGFyZCB0
bwo+IHNlZSBob3cgYW55IGxvYWRhYmxlIG1vZHVsZSB3b3VsZCBub3QgYmUgYSBkZXJpdmVkIHdv
cmsgb2YgdGhlCj4gaHlwZXJ2aXNvciBhbmQgdGhlcmVmb3JlIHN1YmplY3QgdG8gdGhlIHRlcm1z
IG9mIHRoZSBHUEwuCj4gCgpUYWtpbmcgR1BMIGFzIGlzIHdvdWxkIGhhdmUgYW5zd2VyZWQgbXkg
aW5pdGlhbCBxdWVzdGlvbiBxdWlja2x5LCBidXQKc29tZSBwcm9qZWN0cyAoc3VjaCBhcyB0aGUg
TGludXgga2VybmVsKSBoYXZlIG9wdGVkIHRvIGFkZCBleHBsaWNpdApsaWNlbnNpbmcgZXhjZXB0
aW9ucyBmb3IgY2VydGFpbiBmdW5jdGlvbnMuIFRoaXMgaXMgd2hhdCBhbGxvd2VkIE5WSURJQQph
bmQgQVRJIChBTUQpIHRvIHByb3ZpZGUgZHJpdmVycyBmb3IgdGhlaXIgZ3JhcGhpYyBjYXJkcyBv
biBMaW51eC4KClVuZm9ydHVuYXRlbHkgdGhlIG5hdHVyZSBvZiByb290a2l0IHRhcmdldGVkIG1l
bW9yeSBpbnRyb3NwZWN0aW9uCnJlcXVpcmVzIHRoYXQgaXQgd29ya3MgdmVyeSBjbG9zZSB0byB0
aGUgaHYuIEkgd291bGQndmUgbG92ZWQgdG8gaGF2ZQppdCBpbiBkb20wIChiYXNlZCBvbiBWTUl0
b29scyBvciBzb21lIGV4dGVuc2lvbiBvZiBpdCkgYnV0IEkgZm9yZXNlZSBhCmxvdCBvZiB0cmFu
c2l0aW9ucyBmcm9tIGh2IC0+IGRvbTAgYW5kIGJhY2suIEVub3VnaCB0byBzbG93IGV2ZXJ5dGhp
bmcKZG93biB0byB1bmJlYXJhYmxlIHNwZWVkcy4KCi0tIApNaWhhaSBEb27Im3UKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:43:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:43: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 1SeUBS-0006hX-Iv; Tue, 12 Jun 2012 16:43:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SeUBQ-0006hO-TB
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 16:43:09 +0000
Received: from [85.158.143.35:9471] by server-2.bemta-4.messagelabs.com id
	BD/D5-17938-C9177DF4; Tue, 12 Jun 2012 16:43:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339519387!13427249!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6533 invoked from network); 12 Jun 2012 16:43:07 -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; 12 Jun 2012 16:43:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 17:43:06 +0100
Message-Id: <4FD78DE6020000780008986D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 17:43:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
In-Reply-To: <4FD76976.2020203@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.06.12 at 18:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 12/06/12 16:13, Jan Beulich wrote:
>>>>> On 12.06.12 at 14:02, Wei Wang <wei.wang2@amd.com> wrote:
>>> I had attached a revised patch, please check it.
>> While the patch technically looks better now, you didn't eliminate
>> my objections to the approach you take, nor did you comment on
>> the proposed alternative.
>>
>> A fundamental problem is that your IOMMUs show up as a "normal"
>> PCI devices, breaking the separation between what is being
>> managed by the hypervisor vs by the Dom0 kernel. (This even
>> allows something as odd as passing through an IOMMU to a
>> DomU, which would clearly upset the hypervisor.)
>>
>>> I found that the following Linux commit triggers this issue. It has been 
>>> included into 3.4 pv_ops.
>>>
>>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>>    Author: Eric W. Biederman <ebiederm@xmission.com>
>>>    Date:   Mon Oct 17 11:46:06 2011 -0700
>>>
>>>    PCI: msi: Disable msi interrupts when we initialize a pci device "
>> Thanks for locating this. As it stands, it is incomplete though
>> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
>> it won't have a means to suppress the "screaming" interrupts.
> 
> I feel that the correct solution would be for Xen to hide the PCI
> devices from dom0.  Xen already hides the DMAR ACPI table (by turning it
> to an XMAR table), and this would be the logical way to proceed now that
> IOMMU internals are appearing as PCI devices.

That is precisely what I suggested in my response to the first
version of this patch, and I'd also volunteer to look into putting
together a first draft implementation if we sort of agree that
this is the way to go.

> ( A similar issue comes into play now that newer generations of CPUs are
> exposing CPU internals as PCI devices )

Indeed, good point. Might be a little tricky though to determine
which one(s) they are, and still avoid conflicting with things like
the EDAC drivers in Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:43:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:43: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 1SeUBS-0006hX-Iv; Tue, 12 Jun 2012 16:43:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SeUBQ-0006hO-TB
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 16:43:09 +0000
Received: from [85.158.143.35:9471] by server-2.bemta-4.messagelabs.com id
	BD/D5-17938-C9177DF4; Tue, 12 Jun 2012 16:43:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339519387!13427249!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6533 invoked from network); 12 Jun 2012 16:43:07 -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; 12 Jun 2012 16:43:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Jun 2012 17:43:06 +0100
Message-Id: <4FD78DE6020000780008986D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 12 Jun 2012 17:43:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
In-Reply-To: <4FD76976.2020203@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.06.12 at 18:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 12/06/12 16:13, Jan Beulich wrote:
>>>>> On 12.06.12 at 14:02, Wei Wang <wei.wang2@amd.com> wrote:
>>> I had attached a revised patch, please check it.
>> While the patch technically looks better now, you didn't eliminate
>> my objections to the approach you take, nor did you comment on
>> the proposed alternative.
>>
>> A fundamental problem is that your IOMMUs show up as a "normal"
>> PCI devices, breaking the separation between what is being
>> managed by the hypervisor vs by the Dom0 kernel. (This even
>> allows something as odd as passing through an IOMMU to a
>> DomU, which would clearly upset the hypervisor.)
>>
>>> I found that the following Linux commit triggers this issue. It has been 
>>> included into 3.4 pv_ops.
>>>
>>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>>    Author: Eric W. Biederman <ebiederm@xmission.com>
>>>    Date:   Mon Oct 17 11:46:06 2011 -0700
>>>
>>>    PCI: msi: Disable msi interrupts when we initialize a pci device "
>> Thanks for locating this. As it stands, it is incomplete though
>> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
>> it won't have a means to suppress the "screaming" interrupts.
> 
> I feel that the correct solution would be for Xen to hide the PCI
> devices from dom0.  Xen already hides the DMAR ACPI table (by turning it
> to an XMAR table), and this would be the logical way to proceed now that
> IOMMU internals are appearing as PCI devices.

That is precisely what I suggested in my response to the first
version of this patch, and I'd also volunteer to look into putting
together a first draft implementation if we sort of agree that
this is the way to go.

> ( A similar issue comes into play now that newer generations of CPUs are
> exposing CPU internals as PCI devices )

Indeed, good point. Might be a little tricky though to determine
which one(s) they are, and still avoid conflicting with things like
the EDAC drivers in Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:48:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16: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 1SeUGU-0006rX-AZ; Tue, 12 Jun 2012 16:48: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 1SeUGS-0006rO-Qo
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:48:21 +0000
Received: from [85.158.143.99:47944] by server-2.bemta-4.messagelabs.com id
	E3/3B-17938-4D277DF4; Tue, 12 Jun 2012 16:48:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339519699!29129434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23569 invoked from network); 12 Jun 2012 16:48:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 16:48:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12975339"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 16:48:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 17:48:19 +0100
Message-ID: <1339519697.24104.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mihai =?UTF-8?Q?Don=C8=9Bu?= <mihai.dontu@gmail.com>
Date: Tue, 12 Jun 2012 17:48:17 +0100
In-Reply-To: <20120612192959.563946f2@mdontu-l.dsd.ro>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
	<20120612192959.563946f2@mdontu-l.dsd.ro>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAyMDEyLTA2LTEyIGF0IDE3OjI5ICswMTAwLCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4g
T24gVHVlLCAxMiBKdW4gMjAxMiAxNjozOTo1NSArMDEwMCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
PiBJIGRvbid0IHRoaW5rIHdlIHBhcnRpY3VsYXJseSB3YW50L25lZWQgYSBtb2R1bGUgbG9hZGVy
IGluIHRoZQo+ID4gaHlwZXJ2aXNvciwgcmVnYXJkbGVzcyBvZiB0aGUgbGljZW5zZSBvZiB0aGUg
Y29kZSB3aGljaCBpdCBpcyB1c2VkIHRvCj4gPiBsb2FkLgo+ID4gCj4gCj4gSSBzZWUuIE9LLiBJ
IHdpbGwgbm90IGluc2lzdCBvbiB0aGlzLgo+IAo+ID4gVGhlIGxlZ2FsaXR5IG9mIGxvYWRpbmcg
eW91ciBub24tR1BMLWNvbXBhdGlibGUgYmxvYiBpbnRvIHRoZQo+ID4gaHlwZXJ2aXNvciBpcyBh
IHF1ZXN0aW9uIHdoaWNoIG9ubHkgYSBsYXd5ZXIgY2FuIGFuc3dlci4gWW91IHNob3VsZAo+ID4g
bm90IHRha2UgbGVnYWwgYWR2aXNlIGZyb20gdGhpcyBtYWlsaW5nIGxpc3QuCj4gPiAKPiA+IE15
IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCBpdCB3b3VsZCBub3QgYmUgYWNjZXB0YWJsZSB0byBs
b2FkIG5vbi1HUEwKPiA+IGNvbXBhdGlibGUgY29kZSBpbnRvIHRoZSBoeXBlcnZpc29yIHZpYSBh
bnkgbWVjaGFuaXNtLCBpdCBpcyBoYXJkIHRvCj4gPiBzZWUgaG93IGFueSBsb2FkYWJsZSBtb2R1
bGUgd291bGQgbm90IGJlIGEgZGVyaXZlZCB3b3JrIG9mIHRoZQo+ID4gaHlwZXJ2aXNvciBhbmQg
dGhlcmVmb3JlIHN1YmplY3QgdG8gdGhlIHRlcm1zIG9mIHRoZSBHUEwuCj4gPiAKPiAKPiBUYWtp
bmcgR1BMIGFzIGlzIHdvdWxkIGhhdmUgYW5zd2VyZWQgbXkgaW5pdGlhbCBxdWVzdGlvbiBxdWlj
a2x5LCBidXQKPiBzb21lIHByb2plY3RzIChzdWNoIGFzIHRoZSBMaW51eCBrZXJuZWwpIGhhdmUg
b3B0ZWQgdG8gYWRkIGV4cGxpY2l0Cj4gbGljZW5zaW5nIGV4Y2VwdGlvbnMgZm9yIGNlcnRhaW4g
ZnVuY3Rpb25zLiBUaGlzIGlzIHdoYXQgYWxsb3dlZCBOVklESUEKPiBhbmQgQVRJIChBTUQpIHRv
IHByb3ZpZGUgZHJpdmVycyBmb3IgdGhlaXIgZ3JhcGhpYyBjYXJkcyBvbiBMaW51eC4KCk5vLCBp
dCBpc24ndC4gVGhlcmUgaXMgbm8gc3VjaCBsaWNlbnNpbmcgZXhjZXB0aW9uIGluIHRoZSBMaW51
eCBrZXJuZWwKZm9yIHRoZXNlIGRyaXZlcnMgKGlmIHlvdSB0aGluayB0aGVyZSBpcyB0aGVuIHBs
ZWFzZSBwb2ludCB0byB0aGUKc3BlY2lmaWMgbGljZW5zaW5nIHRlcm1zKS4KClRoaXMgaXMgbXVy
a3kgdGVycml0b3J5IGFuZCB0aGVyZSBhcmUgY2VydGFpbmx5IHBlb3BsZSBpbiB0aGUgTGludXgK
ZGV2ZWxvcG1lbnQgY29tbXVuaXR5IHdobyBiZWxpZXZlIHRoYXQgdGhlc2UgZHJpdmVycyBhcmUg
YWxzbyBpbgp2aW9sYXRpb24gb2YgdGhlIEdQTCBhbmQgaGF2ZSBwdWJsaWNseSBzdGF0ZWQgdGhp
cyBvbiBtYW55IG9jY2FzaW9ucy4KCkFnYWluOiBZb3UgbmVlZCB0byBiZSB0YWxraW5nIHRvIHlv
dXIgbGF3eWVyLCBub3QgdXMuCgpJYW4uCgo+IFVuZm9ydHVuYXRlbHkgdGhlIG5hdHVyZSBvZiBy
b290a2l0IHRhcmdldGVkIG1lbW9yeSBpbnRyb3NwZWN0aW9uCj4gcmVxdWlyZXMgdGhhdCBpdCB3
b3JrcyB2ZXJ5IGNsb3NlIHRvIHRoZSBodi4gSSB3b3VsZCd2ZSBsb3ZlZCB0byBoYXZlCj4gaXQg
aW4gZG9tMCAoYmFzZWQgb24gVk1JdG9vbHMgb3Igc29tZSBleHRlbnNpb24gb2YgaXQpIGJ1dCBJ
IGZvcmVzZWUgYQo+IGxvdCBvZiB0cmFuc2l0aW9ucyBmcm9tIGh2IC0+IGRvbTAgYW5kIGJhY2su
IEVub3VnaCB0byBzbG93IGV2ZXJ5dGhpbmcKPiBkb3duIHRvIHVuYmVhcmFibGUgc3BlZWRzLgo+
IAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:48:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16: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 1SeUGU-0006rX-AZ; Tue, 12 Jun 2012 16:48: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 1SeUGS-0006rO-Qo
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:48:21 +0000
Received: from [85.158.143.99:47944] by server-2.bemta-4.messagelabs.com id
	E3/3B-17938-4D277DF4; Tue, 12 Jun 2012 16:48:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339519699!29129434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23569 invoked from network); 12 Jun 2012 16:48:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 16:48:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12975339"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 16:48:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 17:48:19 +0100
Message-ID: <1339519697.24104.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mihai =?UTF-8?Q?Don=C8=9Bu?= <mihai.dontu@gmail.com>
Date: Tue, 12 Jun 2012 17:48:17 +0100
In-Reply-To: <20120612192959.563946f2@mdontu-l.dsd.ro>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
	<20120612192959.563946f2@mdontu-l.dsd.ro>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAyMDEyLTA2LTEyIGF0IDE3OjI5ICswMTAwLCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4g
T24gVHVlLCAxMiBKdW4gMjAxMiAxNjozOTo1NSArMDEwMCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
PiBJIGRvbid0IHRoaW5rIHdlIHBhcnRpY3VsYXJseSB3YW50L25lZWQgYSBtb2R1bGUgbG9hZGVy
IGluIHRoZQo+ID4gaHlwZXJ2aXNvciwgcmVnYXJkbGVzcyBvZiB0aGUgbGljZW5zZSBvZiB0aGUg
Y29kZSB3aGljaCBpdCBpcyB1c2VkIHRvCj4gPiBsb2FkLgo+ID4gCj4gCj4gSSBzZWUuIE9LLiBJ
IHdpbGwgbm90IGluc2lzdCBvbiB0aGlzLgo+IAo+ID4gVGhlIGxlZ2FsaXR5IG9mIGxvYWRpbmcg
eW91ciBub24tR1BMLWNvbXBhdGlibGUgYmxvYiBpbnRvIHRoZQo+ID4gaHlwZXJ2aXNvciBpcyBh
IHF1ZXN0aW9uIHdoaWNoIG9ubHkgYSBsYXd5ZXIgY2FuIGFuc3dlci4gWW91IHNob3VsZAo+ID4g
bm90IHRha2UgbGVnYWwgYWR2aXNlIGZyb20gdGhpcyBtYWlsaW5nIGxpc3QuCj4gPiAKPiA+IE15
IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCBpdCB3b3VsZCBub3QgYmUgYWNjZXB0YWJsZSB0byBs
b2FkIG5vbi1HUEwKPiA+IGNvbXBhdGlibGUgY29kZSBpbnRvIHRoZSBoeXBlcnZpc29yIHZpYSBh
bnkgbWVjaGFuaXNtLCBpdCBpcyBoYXJkIHRvCj4gPiBzZWUgaG93IGFueSBsb2FkYWJsZSBtb2R1
bGUgd291bGQgbm90IGJlIGEgZGVyaXZlZCB3b3JrIG9mIHRoZQo+ID4gaHlwZXJ2aXNvciBhbmQg
dGhlcmVmb3JlIHN1YmplY3QgdG8gdGhlIHRlcm1zIG9mIHRoZSBHUEwuCj4gPiAKPiAKPiBUYWtp
bmcgR1BMIGFzIGlzIHdvdWxkIGhhdmUgYW5zd2VyZWQgbXkgaW5pdGlhbCBxdWVzdGlvbiBxdWlj
a2x5LCBidXQKPiBzb21lIHByb2plY3RzIChzdWNoIGFzIHRoZSBMaW51eCBrZXJuZWwpIGhhdmUg
b3B0ZWQgdG8gYWRkIGV4cGxpY2l0Cj4gbGljZW5zaW5nIGV4Y2VwdGlvbnMgZm9yIGNlcnRhaW4g
ZnVuY3Rpb25zLiBUaGlzIGlzIHdoYXQgYWxsb3dlZCBOVklESUEKPiBhbmQgQVRJIChBTUQpIHRv
IHByb3ZpZGUgZHJpdmVycyBmb3IgdGhlaXIgZ3JhcGhpYyBjYXJkcyBvbiBMaW51eC4KCk5vLCBp
dCBpc24ndC4gVGhlcmUgaXMgbm8gc3VjaCBsaWNlbnNpbmcgZXhjZXB0aW9uIGluIHRoZSBMaW51
eCBrZXJuZWwKZm9yIHRoZXNlIGRyaXZlcnMgKGlmIHlvdSB0aGluayB0aGVyZSBpcyB0aGVuIHBs
ZWFzZSBwb2ludCB0byB0aGUKc3BlY2lmaWMgbGljZW5zaW5nIHRlcm1zKS4KClRoaXMgaXMgbXVy
a3kgdGVycml0b3J5IGFuZCB0aGVyZSBhcmUgY2VydGFpbmx5IHBlb3BsZSBpbiB0aGUgTGludXgK
ZGV2ZWxvcG1lbnQgY29tbXVuaXR5IHdobyBiZWxpZXZlIHRoYXQgdGhlc2UgZHJpdmVycyBhcmUg
YWxzbyBpbgp2aW9sYXRpb24gb2YgdGhlIEdQTCBhbmQgaGF2ZSBwdWJsaWNseSBzdGF0ZWQgdGhp
cyBvbiBtYW55IG9jY2FzaW9ucy4KCkFnYWluOiBZb3UgbmVlZCB0byBiZSB0YWxraW5nIHRvIHlv
dXIgbGF3eWVyLCBub3QgdXMuCgpJYW4uCgo+IFVuZm9ydHVuYXRlbHkgdGhlIG5hdHVyZSBvZiBy
b290a2l0IHRhcmdldGVkIG1lbW9yeSBpbnRyb3NwZWN0aW9uCj4gcmVxdWlyZXMgdGhhdCBpdCB3
b3JrcyB2ZXJ5IGNsb3NlIHRvIHRoZSBodi4gSSB3b3VsZCd2ZSBsb3ZlZCB0byBoYXZlCj4gaXQg
aW4gZG9tMCAoYmFzZWQgb24gVk1JdG9vbHMgb3Igc29tZSBleHRlbnNpb24gb2YgaXQpIGJ1dCBJ
IGZvcmVzZWUgYQo+IGxvdCBvZiB0cmFuc2l0aW9ucyBmcm9tIGh2IC0+IGRvbTAgYW5kIGJhY2su
IEVub3VnaCB0byBzbG93IGV2ZXJ5dGhpbmcKPiBkb3duIHRvIHVuYmVhcmFibGUgc3BlZWRzLgo+
IAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:51:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:51: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 1SeUJf-0006yB-UV; Tue, 12 Jun 2012 16:51: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 1SeUJe-0006y3-4z
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:51:38 +0000
Received: from [193.109.254.147:32350] by server-7.bemta-14.messagelabs.com id
	FB/4F-29165-99377DF4; Tue, 12 Jun 2012 16:51:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339519895!2553109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8725 invoked from network); 12 Jun 2012 16:51:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 16:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12975435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 16:51:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 17:51:34 +0100
Message-ID: <1339519893.24104.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 17:51:33 +0100
In-Reply-To: <1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Change the internal and external APIs for domain save (suspend) to be
> capable of asynchronous operation.  The implementation remains
> synchronous.  The interfaces surrounding device model saving are still
> synchronous.
> 
> Public API changes:
> 
>  * libxl_domain_save takes an ao_how.
> 
>  * libxl_domain_remus_start takes an ao_how.  If the
>    libxl_domain_remus_info is NULL, we abort rather than returning an
>    error.
> 
>  * The `suspend_callback' function passed to libxl_domain_save is
>    never called by the existing implementation in libxl.  Abolish it.

Furthermore xl never passes one in either.
[...]

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

A few minor comments below, but otherwise looks good to me.

[...]
> 
> +static void remus_crashed_cb(libxl__egc *egc,
> +                             libxl__domain_suspend_state *dss, int rc)

I'm not sure "crashed" is quite right here, it's finished for whatever
reason which may not necessarily be a crash (going forward it should
rarely be a crash, I think). It's "stopped" or "done" or something.

> [...]

> +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
> +                         const libxl_asyncop_how *ao_how)
> +{
> +    AO_CREATE(ctx, domid, ao_how);
> +    int rc;
> +
>      libxl_domain_type type = libxl__domain_type(gc, domid);
> -    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
> -    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
> -    int rc = 0;
> +    if (type < 0) {
> +        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);

libxl__domain_type now logs for you.

> +        rc = ERROR_FAIL;
> +        goto out_err;
> +    }
> 
> -    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
> -                                      /* No Remus */ NULL);
> +    libxl__domain_suspend_state *dss;
> +    GCNEW(dss);
> 
> -    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
> -        rc = libxl__domain_save_device_model(gc, domid, fd);
> -    GC_FREE;
> -    return rc;
> +    dss->ao = ao;
> +    dss->callback = domain_suspend_cb;
> +
> +    dss->domid = domid;
> +    dss->fd = fd;
> +    dss->type = type;
> +    dss->live = flags & LIBXL_SUSPEND_LIVE;
> +    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
> +
> +    libxl__domain_suspend(egc, dss);
> +    return AO_INPROGRESS;
> +
> + out_err:
> +    return AO_ABORT(rc);
>  }
> 
>  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
[...]
> @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> 
>  /*----- Domain suspend (save) functions -----*/
> 
> -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> -                                         libxl_domain_type type,
> -                                         int live, int debug,
> -                                         const libxl_domain_remus_info *r_info);
> +/* calls callback when done */

Which callback? dss->callback I guess.

> +_hidden void libxl__domain_suspend(libxl__egc *egc,
> +                                   libxl__domain_suspend_state *dss);
> +
> +
> +/* calls libxl__xc_domain_suspend_done when done */
> +_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
> +                                   unsigned long vm_generationid_addr);
> +/* If rc==0 then retval is the return value from xc_domain_save
> + * and errnoval is the errno value it provided.
> + * If rc!=0, retval and errnoval are undefined. */
> +_hidden void libxl__xc_domain_save_done(libxl__egc*,
> +                                        libxl__domain_suspend_state*,
> +                                        int rc, int retval, int errnoval);
> +
> +_hidden int libxl__domain_suspend_common_callback(void *data);
> +_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
> +                               (int domid, unsigned int enable, void *data);
> +_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +        uint32_t *len, void *data);
> +
> 
>  /* calls libxl__xc_domain_restore_done when done */
>  _hidden void libxl__xc_domain_restore(libxl__egc *egc,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:51:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16:51: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 1SeUJf-0006yB-UV; Tue, 12 Jun 2012 16:51: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 1SeUJe-0006y3-4z
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:51:38 +0000
Received: from [193.109.254.147:32350] by server-7.bemta-14.messagelabs.com id
	FB/4F-29165-99377DF4; Tue, 12 Jun 2012 16:51:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339519895!2553109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8725 invoked from network); 12 Jun 2012 16:51:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 16:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="12975435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jun 2012 16:51:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 12 Jun 2012 17:51:34 +0100
Message-ID: <1339519893.24104.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 12 Jun 2012 17:51:33 +0100
In-Reply-To: <1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Change the internal and external APIs for domain save (suspend) to be
> capable of asynchronous operation.  The implementation remains
> synchronous.  The interfaces surrounding device model saving are still
> synchronous.
> 
> Public API changes:
> 
>  * libxl_domain_save takes an ao_how.
> 
>  * libxl_domain_remus_start takes an ao_how.  If the
>    libxl_domain_remus_info is NULL, we abort rather than returning an
>    error.
> 
>  * The `suspend_callback' function passed to libxl_domain_save is
>    never called by the existing implementation in libxl.  Abolish it.

Furthermore xl never passes one in either.
[...]

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

A few minor comments below, but otherwise looks good to me.

[...]
> 
> +static void remus_crashed_cb(libxl__egc *egc,
> +                             libxl__domain_suspend_state *dss, int rc)

I'm not sure "crashed" is quite right here, it's finished for whatever
reason which may not necessarily be a crash (going forward it should
rarely be a crash, I think). It's "stopped" or "done" or something.

> [...]

> +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
> +                         const libxl_asyncop_how *ao_how)
> +{
> +    AO_CREATE(ctx, domid, ao_how);
> +    int rc;
> +
>      libxl_domain_type type = libxl__domain_type(gc, domid);
> -    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
> -    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
> -    int rc = 0;
> +    if (type < 0) {
> +        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);

libxl__domain_type now logs for you.

> +        rc = ERROR_FAIL;
> +        goto out_err;
> +    }
> 
> -    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
> -                                      /* No Remus */ NULL);
> +    libxl__domain_suspend_state *dss;
> +    GCNEW(dss);
> 
> -    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
> -        rc = libxl__domain_save_device_model(gc, domid, fd);
> -    GC_FREE;
> -    return rc;
> +    dss->ao = ao;
> +    dss->callback = domain_suspend_cb;
> +
> +    dss->domid = domid;
> +    dss->fd = fd;
> +    dss->type = type;
> +    dss->live = flags & LIBXL_SUSPEND_LIVE;
> +    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
> +
> +    libxl__domain_suspend(egc, dss);
> +    return AO_INPROGRESS;
> +
> + out_err:
> +    return AO_ABORT(rc);
>  }
> 
>  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
[...]
> @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> 
>  /*----- Domain suspend (save) functions -----*/
> 
> -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> -                                         libxl_domain_type type,
> -                                         int live, int debug,
> -                                         const libxl_domain_remus_info *r_info);
> +/* calls callback when done */

Which callback? dss->callback I guess.

> +_hidden void libxl__domain_suspend(libxl__egc *egc,
> +                                   libxl__domain_suspend_state *dss);
> +
> +
> +/* calls libxl__xc_domain_suspend_done when done */
> +_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
> +                                   unsigned long vm_generationid_addr);
> +/* If rc==0 then retval is the return value from xc_domain_save
> + * and errnoval is the errno value it provided.
> + * If rc!=0, retval and errnoval are undefined. */
> +_hidden void libxl__xc_domain_save_done(libxl__egc*,
> +                                        libxl__domain_suspend_state*,
> +                                        int rc, int retval, int errnoval);
> +
> +_hidden int libxl__domain_suspend_common_callback(void *data);
> +_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
> +                               (int domid, unsigned int enable, void *data);
> +_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +        uint32_t *len, void *data);
> +
> 
>  /* calls libxl__xc_domain_restore_done when done */
>  _hidden void libxl__xc_domain_restore(libxl__egc *egc,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:53:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16: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 1SeUKv-000753-1q; Tue, 12 Jun 2012 16:52:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1SeUKt-00074m-NY
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:52:55 +0000
Received: from [85.158.138.51:14320] by server-1.bemta-3.messagelabs.com id
	8F/96-01327-6E377DF4; Tue, 12 Jun 2012 16:52:54 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339519973!32134751!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13510 invoked from network); 12 Jun 2012 16:52:54 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 16:52:54 -0000
Received: from pyramind.ukuu.org.uk (earthlight.etchedpixels.co.uk
	[81.2.110.250])
	by lxorguk.ukuu.org.uk (8.14.5/8.14.1) with ESMTP id q5CHMQW4028370;
	Tue, 12 Jun 2012 18:22:32 +0100
Received: from pyramind.ukuu.org.uk (localhost [127.0.0.1])
	by pyramind.ukuu.org.uk (8.14.5/8.14.5) with ESMTP id q5CGub0G015566;
	Tue, 12 Jun 2012 17:56:37 +0100
Date: Tue, 12 Jun 2012 17:56:37 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Mihai =?utf-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
Message-ID: <20120612175637.57297898@pyramind.ukuu.org.uk>
In-Reply-To: <20120612192959.563946f2@mdontu-l.dsd.ro>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
	<20120612192959.563946f2@mdontu-l.dsd.ro>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Taking GPL as is would have answered my initial question quickly, but
> some projects (such as the Linux kernel) have opted to add explicit
> licensing exceptions for certain functions. This is what allowed NVIDIA
> and ATI (AMD) to provide drivers for their graphic cards on Linux.

We have not done so. You are misinformed. Whether the Nvidia or ATI code
is legal is and remains a matter for a court to decide as and if someone
ever decides to take it there.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 16:53:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 16: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 1SeUKv-000753-1q; Tue, 12 Jun 2012 16:52:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1SeUKt-00074m-NY
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 16:52:55 +0000
Received: from [85.158.138.51:14320] by server-1.bemta-3.messagelabs.com id
	8F/96-01327-6E377DF4; Tue, 12 Jun 2012 16:52:54 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339519973!32134751!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13510 invoked from network); 12 Jun 2012 16:52:54 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jun 2012 16:52:54 -0000
Received: from pyramind.ukuu.org.uk (earthlight.etchedpixels.co.uk
	[81.2.110.250])
	by lxorguk.ukuu.org.uk (8.14.5/8.14.1) with ESMTP id q5CHMQW4028370;
	Tue, 12 Jun 2012 18:22:32 +0100
Received: from pyramind.ukuu.org.uk (localhost [127.0.0.1])
	by pyramind.ukuu.org.uk (8.14.5/8.14.5) with ESMTP id q5CGub0G015566;
	Tue, 12 Jun 2012 17:56:37 +0100
Date: Tue, 12 Jun 2012 17:56:37 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Mihai =?utf-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
Message-ID: <20120612175637.57297898@pyramind.ukuu.org.uk>
In-Reply-To: <20120612192959.563946f2@mdontu-l.dsd.ro>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
	<20120612192959.563946f2@mdontu-l.dsd.ro>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Taking GPL as is would have answered my initial question quickly, but
> some projects (such as the Linux kernel) have opted to add explicit
> licensing exceptions for certain functions. This is what allowed NVIDIA
> and ATI (AMD) to provide drivers for their graphic cards on Linux.

We have not done so. You are misinformed. Whether the Nvidia or ATI code
is legal is and remains a matter for a court to decide as and if someone
ever decides to take it there.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 18:33:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 18:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeVti-0000Q9-Hr; Tue, 12 Jun 2012 18:32:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeVth-0000Pk-Br
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 18:32:57 +0000
Received: from [85.158.143.99:36493] by server-1.bemta-4.messagelabs.com id
	A5/9C-24392-85B87DF4; Tue, 12 Jun 2012 18:32:56 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339525975!30184132!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22113 invoked from network); 12 Jun 2012 18:32:56 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 18:32:56 -0000
Received: by bkwj10 with SMTP id j10so5672357bkw.32
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 11:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:in-reply-to:references
	:organization:mime-version:content-type:content-transfer-encoding;
	bh=72kMJUEeUowQ+ZBQefHkNNn02yTBZs1cnAUCkpwYdBU=;
	b=UXs9wu5NPvlrNOtzNMJNEyj6BMpx2Yg1xQHPMfaq3w/zHCX8axR990GacqD3QdalRV
	W8FNa6cwKNUPwFgljxP/LIcGOtVPqWmJ64XVr7R3dzJj3j9L/WNfB84mEFayN1IfX6HL
	koIqv3+2rymsZDm4N9boYfGchUumW83BX9n1MNWhmyea0QMRiyXU7MWKJB32cVDx4+jD
	FvhT2w8I89Jq3P6ZUWHQ1qkCFurLXSyHwyloVNRPuErvYR5K/asjUsIJirdjKg6PAJVZ
	HN8UzKJNMZRhN42K4vFeu0Y8WrxG7WA/S/dAM7VuBZJJpO3zpimucq1YwzlyWxoL6FZ2
	YMNw==
Received: by 10.204.156.24 with SMTP id u24mr11880850bkw.75.1339525975533;
	Tue, 12 Jun 2012 11:32:55 -0700 (PDT)
Received: from mdontu-l.dsd.ro ([86.104.62.126])
	by mx.google.com with ESMTPS id gm18sm178196bkc.7.2012.06.12.11.32.52
	(version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 11:32:52 -0700 (PDT)
Date: Tue, 12 Jun 2012 21:32:51 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120612213251.1be889ce@mdontu-l.dsd.ro>
In-Reply-To: <1339519697.24104.114.camel@zakaz.uk.xensource.com>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
	<20120612192959.563946f2@mdontu-l.dsd.ro>
	<1339519697.24104.114.camel@zakaz.uk.xensource.com>
Organization: Home
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAxMiBKdW4gMjAxMiAxNzo0ODoxNyArMDEwMCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
PiBUYWtpbmcgR1BMIGFzIGlzIHdvdWxkIGhhdmUgYW5zd2VyZWQgbXkgaW5pdGlhbCBxdWVzdGlv
biBxdWlja2x5LAo+ID4gYnV0IHNvbWUgcHJvamVjdHMgKHN1Y2ggYXMgdGhlIExpbnV4IGtlcm5l
bCkgaGF2ZSBvcHRlZCB0byBhZGQKPiA+IGV4cGxpY2l0IGxpY2Vuc2luZyBleGNlcHRpb25zIGZv
ciBjZXJ0YWluIGZ1bmN0aW9ucy4gVGhpcyBpcyB3aGF0Cj4gPiBhbGxvd2VkIE5WSURJQSBhbmQg
QVRJIChBTUQpIHRvIHByb3ZpZGUgZHJpdmVycyBmb3IgdGhlaXIgZ3JhcGhpYwo+ID4gY2FyZHMg
b24gTGludXguCj4gCj4gTm8sIGl0IGlzbid0LiBUaGVyZSBpcyBubyBzdWNoIGxpY2Vuc2luZyBl
eGNlcHRpb24gaW4gdGhlIExpbnV4IGtlcm5lbAo+IGZvciB0aGVzZSBkcml2ZXJzIChpZiB5b3Ug
dGhpbmsgdGhlcmUgaXMgdGhlbiBwbGVhc2UgcG9pbnQgdG8gdGhlCj4gc3BlY2lmaWMgbGljZW5z
aW5nIHRlcm1zKS4KPiAKPiBUaGlzIGlzIG11cmt5IHRlcnJpdG9yeSBhbmQgdGhlcmUgYXJlIGNl
cnRhaW5seSBwZW9wbGUgaW4gdGhlIExpbnV4Cj4gZGV2ZWxvcG1lbnQgY29tbXVuaXR5IHdobyBi
ZWxpZXZlIHRoYXQgdGhlc2UgZHJpdmVycyBhcmUgYWxzbyBpbgo+IHZpb2xhdGlvbiBvZiB0aGUg
R1BMIGFuZCBoYXZlIHB1YmxpY2x5IHN0YXRlZCB0aGlzIG9uIG1hbnkgb2NjYXNpb25zLgo+IAo+
IEFnYWluOiBZb3UgbmVlZCB0byBiZSB0YWxraW5nIHRvIHlvdXIgbGF3eWVyLCBub3QgdXMuCj4g
CgpPSy4gSSB3aWxsIG5vdCBwdXJzdWUgdGhpcyBpc3N1ZSBhbnltb3JlLCBhdCBsZWFzdCBub3Qg
dW50aWwgSSBnZXQgc29tZQpsZWdhbCBhZHZpY2UuCgpXaGF0IG1ha2VzIG1lIHdvbmRlciBub3cg
KGFuZCBJIGhvcGUgSSBkb24ndCBjb21lIGFjcm9zcyBhcyBhbm5veWluZ2x5CnBlcnNpc3RlbnQp
IGlzIHdoeSBhbGwgdGhlIGVmZm9ydCBpbiB0aGUgTGludXgga2VybmVsIHRvIGNhdGVnb3JpemUK
ZXhwb3J0ZWQgc3ltYm9scyB3aXRoIEVYUE9SVF9TWU1CT0xfR1BMKCkgYW5kIEVYUE9SVF9TWU1C
T0woKS4gSGVyZSdzIGEKcmVjZW50IHRocmVhZCB0aGF0IGJyb3VnaHQgaXQgaW50byBkaXNjdXNz
aW9uOgpodHRwczovL2xrbWwub3JnL2xrbWwvMjAxMi8xLzE3LzQ3OCAuCgotLSAKTWloYWkgRG9u
yJt1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 18:33:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 18:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeVti-0000Q9-Hr; Tue, 12 Jun 2012 18:32:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihai.dontu@gmail.com>) id 1SeVth-0000Pk-Br
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 18:32:57 +0000
Received: from [85.158.143.99:36493] by server-1.bemta-4.messagelabs.com id
	A5/9C-24392-85B87DF4; Tue, 12 Jun 2012 18:32:56 +0000
X-Env-Sender: mihai.dontu@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339525975!30184132!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22113 invoked from network); 12 Jun 2012 18:32:56 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 18:32:56 -0000
Received: by bkwj10 with SMTP id j10so5672357bkw.32
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 11:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:in-reply-to:references
	:organization:mime-version:content-type:content-transfer-encoding;
	bh=72kMJUEeUowQ+ZBQefHkNNn02yTBZs1cnAUCkpwYdBU=;
	b=UXs9wu5NPvlrNOtzNMJNEyj6BMpx2Yg1xQHPMfaq3w/zHCX8axR990GacqD3QdalRV
	W8FNa6cwKNUPwFgljxP/LIcGOtVPqWmJ64XVr7R3dzJj3j9L/WNfB84mEFayN1IfX6HL
	koIqv3+2rymsZDm4N9boYfGchUumW83BX9n1MNWhmyea0QMRiyXU7MWKJB32cVDx4+jD
	FvhT2w8I89Jq3P6ZUWHQ1qkCFurLXSyHwyloVNRPuErvYR5K/asjUsIJirdjKg6PAJVZ
	HN8UzKJNMZRhN42K4vFeu0Y8WrxG7WA/S/dAM7VuBZJJpO3zpimucq1YwzlyWxoL6FZ2
	YMNw==
Received: by 10.204.156.24 with SMTP id u24mr11880850bkw.75.1339525975533;
	Tue, 12 Jun 2012 11:32:55 -0700 (PDT)
Received: from mdontu-l.dsd.ro ([86.104.62.126])
	by mx.google.com with ESMTPS id gm18sm178196bkc.7.2012.06.12.11.32.52
	(version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 11:32:52 -0700 (PDT)
Date: Tue, 12 Jun 2012 21:32:51 +0300
From: Mihai =?UTF-8?B?RG9uyJt1?= <mihai.dontu@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120612213251.1be889ce@mdontu-l.dsd.ro>
In-Reply-To: <1339519697.24104.114.camel@zakaz.uk.xensource.com>
References: <20120612154828.4cdae7bc@mdontu-l.dsd.ro>
	<4FD74D9A.8080807@gmail.com>
	<20120612181309.7cf8514e@mdontu-l.dsd.ro>
	<1339515595.24104.95.camel@zakaz.uk.xensource.com>
	<20120612192959.563946f2@mdontu-l.dsd.ro>
	<1339519697.24104.114.camel@zakaz.uk.xensource.com>
Organization: Home
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Hypervisor loadable modules and GPL licensing
 issues (Was: Re: memory introspection)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAxMiBKdW4gMjAxMiAxNzo0ODoxNyArMDEwMCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
PiBUYWtpbmcgR1BMIGFzIGlzIHdvdWxkIGhhdmUgYW5zd2VyZWQgbXkgaW5pdGlhbCBxdWVzdGlv
biBxdWlja2x5LAo+ID4gYnV0IHNvbWUgcHJvamVjdHMgKHN1Y2ggYXMgdGhlIExpbnV4IGtlcm5l
bCkgaGF2ZSBvcHRlZCB0byBhZGQKPiA+IGV4cGxpY2l0IGxpY2Vuc2luZyBleGNlcHRpb25zIGZv
ciBjZXJ0YWluIGZ1bmN0aW9ucy4gVGhpcyBpcyB3aGF0Cj4gPiBhbGxvd2VkIE5WSURJQSBhbmQg
QVRJIChBTUQpIHRvIHByb3ZpZGUgZHJpdmVycyBmb3IgdGhlaXIgZ3JhcGhpYwo+ID4gY2FyZHMg
b24gTGludXguCj4gCj4gTm8sIGl0IGlzbid0LiBUaGVyZSBpcyBubyBzdWNoIGxpY2Vuc2luZyBl
eGNlcHRpb24gaW4gdGhlIExpbnV4IGtlcm5lbAo+IGZvciB0aGVzZSBkcml2ZXJzIChpZiB5b3Ug
dGhpbmsgdGhlcmUgaXMgdGhlbiBwbGVhc2UgcG9pbnQgdG8gdGhlCj4gc3BlY2lmaWMgbGljZW5z
aW5nIHRlcm1zKS4KPiAKPiBUaGlzIGlzIG11cmt5IHRlcnJpdG9yeSBhbmQgdGhlcmUgYXJlIGNl
cnRhaW5seSBwZW9wbGUgaW4gdGhlIExpbnV4Cj4gZGV2ZWxvcG1lbnQgY29tbXVuaXR5IHdobyBi
ZWxpZXZlIHRoYXQgdGhlc2UgZHJpdmVycyBhcmUgYWxzbyBpbgo+IHZpb2xhdGlvbiBvZiB0aGUg
R1BMIGFuZCBoYXZlIHB1YmxpY2x5IHN0YXRlZCB0aGlzIG9uIG1hbnkgb2NjYXNpb25zLgo+IAo+
IEFnYWluOiBZb3UgbmVlZCB0byBiZSB0YWxraW5nIHRvIHlvdXIgbGF3eWVyLCBub3QgdXMuCj4g
CgpPSy4gSSB3aWxsIG5vdCBwdXJzdWUgdGhpcyBpc3N1ZSBhbnltb3JlLCBhdCBsZWFzdCBub3Qg
dW50aWwgSSBnZXQgc29tZQpsZWdhbCBhZHZpY2UuCgpXaGF0IG1ha2VzIG1lIHdvbmRlciBub3cg
KGFuZCBJIGhvcGUgSSBkb24ndCBjb21lIGFjcm9zcyBhcyBhbm5veWluZ2x5CnBlcnNpc3RlbnQp
IGlzIHdoeSBhbGwgdGhlIGVmZm9ydCBpbiB0aGUgTGludXgga2VybmVsIHRvIGNhdGVnb3JpemUK
ZXhwb3J0ZWQgc3ltYm9scyB3aXRoIEVYUE9SVF9TWU1CT0xfR1BMKCkgYW5kIEVYUE9SVF9TWU1C
T0woKS4gSGVyZSdzIGEKcmVjZW50IHRocmVhZCB0aGF0IGJyb3VnaHQgaXQgaW50byBkaXNjdXNz
aW9uOgpodHRwczovL2xrbWwub3JnL2xrbWwvMjAxMi8xLzE3LzQ3OCAuCgotLSAKTWloYWkgRG9u
yJt1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Jun 12 22:03:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 22:03: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 1SeZAu-0001Xl-2s; Tue, 12 Jun 2012 22:02:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SeZAs-0001Xg-86
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 22:02:54 +0000
Received: from [85.158.143.99:62689] by server-2.bemta-4.messagelabs.com id
	01/1A-17938-C8CB7DF4; Tue, 12 Jun 2012 22:02:52 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339538571!31975656!1
X-Originating-IP: [213.199.154.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10235 invoked from network); 12 Jun 2012 22:02:51 -0000
Received: from db3ehsobe004.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.142)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jun 2012 22:02:51 -0000
Received: from mail54-db3-R.bigfish.com (10.3.81.227) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 22:01:48 +0000
Received: from mail54-db3 (localhost [127.0.0.1])	by mail54-db3-R.bigfish.com
	(Postfix) with ESMTP id 92A90805D6;
	Tue, 12 Jun 2012 22:01:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 7
X-BigFish: VPS7(z5c5ozzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3
	(MessageSwitch) id 1339538507187117_964; Tue, 12 Jun 2012 22:01:47 +0000
	(UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.240])	by
	mail54-db3.bigfish.com (Postfix) with ESMTP id 2BCA920019;
	Tue, 12 Jun 2012 22:01:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 22:01:46 +0000
X-WSS-ID: 0M5IYKN-01-7YW-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2513610280AD;	Tue, 12 Jun 2012 17:02:46 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 12 Jun 2012 17:11:06 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 12 Jun 2012 17:02:46 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012
	18:02:45 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E254D49C145; Tue, 12 Jun 2012
	23:02:44 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id D1E4F2D2032; Wed,
	13 Jun 2012 00:02:44 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 9477c6d78eb19422b59d235a67c3923346a3d60b
Message-ID: <9477c6d78eb19422b59d.1339538538@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Wed, 13 Jun 2012 00:02:18 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keir@xen.org>, <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] x86,
	cpufreq: Change powernow's CPB status immediately
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339538170 -7200
# Node ID 9477c6d78eb19422b59d235a67c3923346a3d60b
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
x86, cpufreq: Change powernow's CPB status immediately

When command to modify turbo mode (CPB on AMD processors) comes
in the actual change happens later, when P-state transition is
requested. There is no time limit on when this transition will
occur and therefore change in CPB state may take long time from
the moment when command to toggle it is issued.

This patch makes CPB mode change happen immediately when request
is made.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r 9477c6d78eb1 xen/arch/x86/acpi/cpufreq/powernow.c
--- a/xen/arch/x86/acpi/cpufreq/powernow.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c	Tue Jun 12 23:56:10 2012 +0200
@@ -68,16 +68,42 @@ static void transition_pstate(void *drvc
     struct drv_cmd *cmd;
     cmd = (struct drv_cmd *) drvcmd;
 
-    if (cmd->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
+
+    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static void update_cpb(void *data)
+{
+    struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
+
+    if (policy->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
         uint64_t msr_content;
+ 
         rdmsrl(MSR_K8_HWCR, msr_content);
-        if (cmd->turbo == CPUFREQ_TURBO_ENABLED)
+
+        if (policy->turbo == CPUFREQ_TURBO_ENABLED)
             msr_content &= ~MSR_HWCR_CPBDIS_MASK;
         else
             msr_content |= MSR_HWCR_CPBDIS_MASK; 
+
         wrmsrl(MSR_K8_HWCR, msr_content);
     }
-    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static int powernow_cpufreq_update (int cpuid,
+				     struct cpufreq_policy *policy)
+{
+    cpumask_t cpumask;
+
+    if (!cpumask_test_cpu(cpuid, &cpu_online_map))
+        return -EINVAL;
+
+    cpumask_clear(&cpumask);
+    cpumask_set_cpu(cpuid, &cpumask);
+
+    on_selected_cpus(&cpumask, update_cpb, policy, 1);
+
+    return 0;
 }
 
 static int powernow_cpufreq_target(struct cpufreq_policy *policy,
@@ -300,7 +326,8 @@ static struct cpufreq_driver powernow_cp
     .verify = powernow_cpufreq_verify,
     .target = powernow_cpufreq_target,
     .init   = powernow_cpufreq_cpu_init,
-    .exit   = powernow_cpufreq_cpu_exit
+    .exit   = powernow_cpufreq_cpu_exit,
+    .update = powernow_cpufreq_update
 };
 
 unsigned int __init powernow_register_driver()
diff -r 32034d1914a6 -r 9477c6d78eb1 xen/drivers/acpi/pmstat.c
--- a/xen/drivers/acpi/pmstat.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/acpi/pmstat.c	Tue Jun 12 23:56:10 2012 +0200
@@ -494,13 +494,13 @@ int do_pm_op(struct xen_sysctl_pm_op *op
 
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
-        cpufreq_enable_turbo(op->cpuid);
+        ret = cpufreq_enable_turbo(op->cpuid);
         break;
     }
 
     case XEN_SYSCTL_pm_op_disable_turbo:
     {
-        cpufreq_disable_turbo(op->cpuid);
+        ret = cpufreq_disable_turbo(op->cpuid);
         break;
     }
 
diff -r 32034d1914a6 -r 9477c6d78eb1 xen/drivers/cpufreq/utility.c
--- a/xen/drivers/cpufreq/utility.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/cpufreq/utility.c	Tue Jun 12 23:56:10 2012 +0200
@@ -390,22 +390,44 @@ int cpufreq_driver_getavg(unsigned int c
     return policy->cur;
 }
 
-void cpufreq_enable_turbo(int cpuid)
+int cpufreq_enable_turbo(int cpuid)
 {
     struct cpufreq_policy *policy;
+    int ret = 0;
 
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
+    if (policy && policy->turbo == CPUFREQ_TURBO_DISABLED)
+    {
         policy->turbo = CPUFREQ_TURBO_ENABLED;
+        if (cpufreq_driver->update)
+        {
+            ret = cpufreq_driver->update(cpuid, policy);
+            if (ret)
+                policy->turbo = CPUFREQ_TURBO_DISABLED;
+        }
+    }
+
+    return ret;
 }
 
-void cpufreq_disable_turbo(int cpuid)
+int cpufreq_disable_turbo(int cpuid)
 {
     struct cpufreq_policy *policy;
+    int ret = 0;
 
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
+    if (policy && policy->turbo == CPUFREQ_TURBO_ENABLED)
+    {
         policy->turbo = CPUFREQ_TURBO_DISABLED;
+        if (cpufreq_driver->update)
+        {
+            ret = cpufreq_driver->update(cpuid, policy);
+            if (ret)
+                policy->turbo = CPUFREQ_TURBO_ENABLED;
+        }
+    }
+
+    return ret;
 }
 
 int cpufreq_get_turbo_status(int cpuid)
diff -r 32034d1914a6 -r 9477c6d78eb1 xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/acpi/cpufreq/cpufreq.h	Tue Jun 12 23:56:10 2012 +0200
@@ -124,8 +124,8 @@ extern int cpufreq_driver_getavg(unsigne
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
-extern void cpufreq_enable_turbo(int cpuid);
-extern void cpufreq_disable_turbo(int cpuid);
+extern int cpufreq_enable_turbo(int cpuid);
+extern int cpufreq_disable_turbo(int cpuid);
 extern int cpufreq_get_turbo_status(int cpuid);
 
 static __inline__ int 
@@ -146,6 +146,7 @@ struct cpufreq_driver {
     char   name[CPUFREQ_NAME_LEN];
     int    (*init)(struct cpufreq_policy *policy);
     int    (*verify)(struct cpufreq_policy *policy);
+    int    (*update)(int cpuid, struct cpufreq_policy *policy);
     int    (*target)(struct cpufreq_policy *policy,
                      unsigned int target_freq,
                      unsigned int relation);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 12 22:03:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Jun 2012 22:03: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 1SeZAu-0001Xl-2s; Tue, 12 Jun 2012 22:02:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SeZAs-0001Xg-86
	for xen-devel@lists.xensource.com; Tue, 12 Jun 2012 22:02:54 +0000
Received: from [85.158.143.99:62689] by server-2.bemta-4.messagelabs.com id
	01/1A-17938-C8CB7DF4; Tue, 12 Jun 2012 22:02:52 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339538571!31975656!1
X-Originating-IP: [213.199.154.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10235 invoked from network); 12 Jun 2012 22:02:51 -0000
Received: from db3ehsobe004.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.142)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jun 2012 22:02:51 -0000
Received: from mail54-db3-R.bigfish.com (10.3.81.227) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 22:01:48 +0000
Received: from mail54-db3 (localhost [127.0.0.1])	by mail54-db3-R.bigfish.com
	(Postfix) with ESMTP id 92A90805D6;
	Tue, 12 Jun 2012 22:01:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 7
X-BigFish: VPS7(z5c5ozzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3
	(MessageSwitch) id 1339538507187117_964; Tue, 12 Jun 2012 22:01:47 +0000
	(UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.240])	by
	mail54-db3.bigfish.com (Postfix) with ESMTP id 2BCA920019;
	Tue, 12 Jun 2012 22:01:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server id
	14.1.225.23; Tue, 12 Jun 2012 22:01:46 +0000
X-WSS-ID: 0M5IYKN-01-7YW-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2513610280AD;	Tue, 12 Jun 2012 17:02:46 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 12 Jun 2012 17:11:06 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 12 Jun 2012 17:02:46 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012
	18:02:45 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E254D49C145; Tue, 12 Jun 2012
	23:02:44 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id D1E4F2D2032; Wed,
	13 Jun 2012 00:02:44 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 9477c6d78eb19422b59d235a67c3923346a3d60b
Message-ID: <9477c6d78eb19422b59d.1339538538@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Wed, 13 Jun 2012 00:02:18 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keir@xen.org>, <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] x86,
	cpufreq: Change powernow's CPB status immediately
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339538170 -7200
# Node ID 9477c6d78eb19422b59d235a67c3923346a3d60b
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
x86, cpufreq: Change powernow's CPB status immediately

When command to modify turbo mode (CPB on AMD processors) comes
in the actual change happens later, when P-state transition is
requested. There is no time limit on when this transition will
occur and therefore change in CPB state may take long time from
the moment when command to toggle it is issued.

This patch makes CPB mode change happen immediately when request
is made.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r 9477c6d78eb1 xen/arch/x86/acpi/cpufreq/powernow.c
--- a/xen/arch/x86/acpi/cpufreq/powernow.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c	Tue Jun 12 23:56:10 2012 +0200
@@ -68,16 +68,42 @@ static void transition_pstate(void *drvc
     struct drv_cmd *cmd;
     cmd = (struct drv_cmd *) drvcmd;
 
-    if (cmd->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
+
+    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static void update_cpb(void *data)
+{
+    struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
+
+    if (policy->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
         uint64_t msr_content;
+ 
         rdmsrl(MSR_K8_HWCR, msr_content);
-        if (cmd->turbo == CPUFREQ_TURBO_ENABLED)
+
+        if (policy->turbo == CPUFREQ_TURBO_ENABLED)
             msr_content &= ~MSR_HWCR_CPBDIS_MASK;
         else
             msr_content |= MSR_HWCR_CPBDIS_MASK; 
+
         wrmsrl(MSR_K8_HWCR, msr_content);
     }
-    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static int powernow_cpufreq_update (int cpuid,
+				     struct cpufreq_policy *policy)
+{
+    cpumask_t cpumask;
+
+    if (!cpumask_test_cpu(cpuid, &cpu_online_map))
+        return -EINVAL;
+
+    cpumask_clear(&cpumask);
+    cpumask_set_cpu(cpuid, &cpumask);
+
+    on_selected_cpus(&cpumask, update_cpb, policy, 1);
+
+    return 0;
 }
 
 static int powernow_cpufreq_target(struct cpufreq_policy *policy,
@@ -300,7 +326,8 @@ static struct cpufreq_driver powernow_cp
     .verify = powernow_cpufreq_verify,
     .target = powernow_cpufreq_target,
     .init   = powernow_cpufreq_cpu_init,
-    .exit   = powernow_cpufreq_cpu_exit
+    .exit   = powernow_cpufreq_cpu_exit,
+    .update = powernow_cpufreq_update
 };
 
 unsigned int __init powernow_register_driver()
diff -r 32034d1914a6 -r 9477c6d78eb1 xen/drivers/acpi/pmstat.c
--- a/xen/drivers/acpi/pmstat.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/acpi/pmstat.c	Tue Jun 12 23:56:10 2012 +0200
@@ -494,13 +494,13 @@ int do_pm_op(struct xen_sysctl_pm_op *op
 
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
-        cpufreq_enable_turbo(op->cpuid);
+        ret = cpufreq_enable_turbo(op->cpuid);
         break;
     }
 
     case XEN_SYSCTL_pm_op_disable_turbo:
     {
-        cpufreq_disable_turbo(op->cpuid);
+        ret = cpufreq_disable_turbo(op->cpuid);
         break;
     }
 
diff -r 32034d1914a6 -r 9477c6d78eb1 xen/drivers/cpufreq/utility.c
--- a/xen/drivers/cpufreq/utility.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/cpufreq/utility.c	Tue Jun 12 23:56:10 2012 +0200
@@ -390,22 +390,44 @@ int cpufreq_driver_getavg(unsigned int c
     return policy->cur;
 }
 
-void cpufreq_enable_turbo(int cpuid)
+int cpufreq_enable_turbo(int cpuid)
 {
     struct cpufreq_policy *policy;
+    int ret = 0;
 
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
+    if (policy && policy->turbo == CPUFREQ_TURBO_DISABLED)
+    {
         policy->turbo = CPUFREQ_TURBO_ENABLED;
+        if (cpufreq_driver->update)
+        {
+            ret = cpufreq_driver->update(cpuid, policy);
+            if (ret)
+                policy->turbo = CPUFREQ_TURBO_DISABLED;
+        }
+    }
+
+    return ret;
 }
 
-void cpufreq_disable_turbo(int cpuid)
+int cpufreq_disable_turbo(int cpuid)
 {
     struct cpufreq_policy *policy;
+    int ret = 0;
 
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
+    if (policy && policy->turbo == CPUFREQ_TURBO_ENABLED)
+    {
         policy->turbo = CPUFREQ_TURBO_DISABLED;
+        if (cpufreq_driver->update)
+        {
+            ret = cpufreq_driver->update(cpuid, policy);
+            if (ret)
+                policy->turbo = CPUFREQ_TURBO_ENABLED;
+        }
+    }
+
+    return ret;
 }
 
 int cpufreq_get_turbo_status(int cpuid)
diff -r 32034d1914a6 -r 9477c6d78eb1 xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/acpi/cpufreq/cpufreq.h	Tue Jun 12 23:56:10 2012 +0200
@@ -124,8 +124,8 @@ extern int cpufreq_driver_getavg(unsigne
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
-extern void cpufreq_enable_turbo(int cpuid);
-extern void cpufreq_disable_turbo(int cpuid);
+extern int cpufreq_enable_turbo(int cpuid);
+extern int cpufreq_disable_turbo(int cpuid);
 extern int cpufreq_get_turbo_status(int cpuid);
 
 static __inline__ int 
@@ -146,6 +146,7 @@ struct cpufreq_driver {
     char   name[CPUFREQ_NAME_LEN];
     int    (*init)(struct cpufreq_policy *policy);
     int    (*verify)(struct cpufreq_policy *policy);
+    int    (*update)(int cpuid, struct cpufreq_policy *policy);
     int    (*target)(struct cpufreq_policy *policy,
                      unsigned int target_freq,
                      unsigned int relation);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 02:26:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 02: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 1SedHb-0007PQ-Ac; Wed, 13 Jun 2012 02:26:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SedHY-0007PL-PP
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 02:26:05 +0000
Received: from [193.109.254.147:2133] by server-10.bemta-14.messagelabs.com id
	90/52-25709-B3AF7DF4; Wed, 13 Jun 2012 02:26:03 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339554362!8611721!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3ODE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13481 invoked from network); 13 Jun 2012 02:26:03 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 02:26:03 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 00F7C20B2E;
	Tue, 12 Jun 2012 22:26:01 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Tue, 12 Jun 2012 22:26:02 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=G+
	ER8qQ2umJ4lGG+gWxxkTXJRIU=; b=B4pOk7ChfRlR9xVKnLm/Ai4skO7Qynk+Jr
	8ZGVih2RMfunxkTm96Xl1J34duPYyxj4dA6YzWryuD8b8ASXCDDyJNUtKoFkfX20
	l8uQJqtELLTXYb0Zpx3wk+mOkmBl8v6D/ktIvBEaV+UX9wPHBimTEAyhaDdVAlCt
	oibhnuLIo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=G+ER
	8qQ2umJ4lGG+gWxxkTXJRIU=; b=buy3fMKDnaR510DKCd69AoESRh/zwczxtrjN
	uxQZLal4nwvta1cxacCHiW9gSWs2Moz//up3Tf7w+6jJHRvgyaQVONF877jLKF3E
	xtmK2ZcDYQKQy19vmblfx3ULN7sG0HnnS5ABXK+QGEI1QcCR5K/3RWXEz2xpExmP
	StIWKyo=
X-Sasl-enc: +nYxaRMdGAMBz/e9WdauXrYlaTNKiq/jACeAHYQxVmwC 1339554361
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 4AFD58E00CB;
	Tue, 12 Jun 2012 22:26:01 -0400 (EDT)
Message-ID: <4FD7FA32.2010006@invisiblethingslab.com>
Date: Wed, 13 Jun 2012 04:25:54 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Kouya Shimura <kouya@jp.fujitsu.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
	<87hauhvx5x.fsf@jp.fujitsu.com>
In-Reply-To: <87hauhvx5x.fsf@jp.fujitsu.com>
X-Enigmail-Version: 1.4.1
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3586592641735229152=="
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)
--===============3586592641735229152==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigB23037EAE21C4DA682E045B6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB23037EAE21C4DA682E045B6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12.06.2012 08:53, Kouya Shimura wrote:
> Hi,
>=20
> The owner support is introduced in c/s 8175, not by me.
> Anyway, something is wrong with your execution trace.
>=20
>> + '[' 6 -gt 5 ']'
>> + sleep 1
> <<< Why claim_lock() returns here???
>> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000=
aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
>> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bb=
ab7a9/Vi
>=20
> I don't know what is a problem and whether your patch resolves the issu=
e or not.

I can confirm this problem, I've faced it some time ago:
http://lists.xen.org/archives/html/xen-devel/2011-07/msg00182.html

> It would be better to replace locking.sh with the RHEL5 implementation
> which uses 'flock' rather than to fix it.

I agree. Currently I've workarounded it by adding flock in udev rule whic=
h run
this script, but working locking.sh will be much nicer.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigB23037EAE21C4DA682E045B6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP1/ozAAoJENuP0xzK19csPRkH/Ra4s34ouMHG9YQ9eNDxjii5
xCM1i9OR1m69uY6tuJl5zY2Wvx0UDPnujGrSFLqZw/A84yI9CzjVskkWIXzaq+FA
ZxZFjHW9tDT4ubmz2rBKNYvd2+oFyiGB3/0zkBefjI6pY0R6lSlVKluOOxL8JDXl
e4KHvVKk4YijBuAGNm9e81rh3y/IDomUZMl0Stv2QgW3cMLmaiIWhU1t1slp+r0z
S34nE6zmae1B/5o4GhWNKC34QxwzA7zkEwsC/eXbW39uUrT8eC7cwGWH7iI0MHn1
etrP1pSRcn8YIzQBWbZGJ/BGViBzv1+ZqVs4ef+fhgjeFtuG0nMT/rMLXJ3L/V4=
=zXeH
-----END PGP SIGNATURE-----

--------------enigB23037EAE21C4DA682E045B6--


--===============3586592641735229152==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3586592641735229152==--


From xen-devel-bounces@lists.xen.org Wed Jun 13 02:26:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 02: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 1SedHb-0007PQ-Ac; Wed, 13 Jun 2012 02:26:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SedHY-0007PL-PP
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 02:26:05 +0000
Received: from [193.109.254.147:2133] by server-10.bemta-14.messagelabs.com id
	90/52-25709-B3AF7DF4; Wed, 13 Jun 2012 02:26:03 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339554362!8611721!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3ODE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13481 invoked from network); 13 Jun 2012 02:26:03 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 02:26:03 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 00F7C20B2E;
	Tue, 12 Jun 2012 22:26:01 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Tue, 12 Jun 2012 22:26:02 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=G+
	ER8qQ2umJ4lGG+gWxxkTXJRIU=; b=B4pOk7ChfRlR9xVKnLm/Ai4skO7Qynk+Jr
	8ZGVih2RMfunxkTm96Xl1J34duPYyxj4dA6YzWryuD8b8ASXCDDyJNUtKoFkfX20
	l8uQJqtELLTXYb0Zpx3wk+mOkmBl8v6D/ktIvBEaV+UX9wPHBimTEAyhaDdVAlCt
	oibhnuLIo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=G+ER
	8qQ2umJ4lGG+gWxxkTXJRIU=; b=buy3fMKDnaR510DKCd69AoESRh/zwczxtrjN
	uxQZLal4nwvta1cxacCHiW9gSWs2Moz//up3Tf7w+6jJHRvgyaQVONF877jLKF3E
	xtmK2ZcDYQKQy19vmblfx3ULN7sG0HnnS5ABXK+QGEI1QcCR5K/3RWXEz2xpExmP
	StIWKyo=
X-Sasl-enc: +nYxaRMdGAMBz/e9WdauXrYlaTNKiq/jACeAHYQxVmwC 1339554361
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 4AFD58E00CB;
	Tue, 12 Jun 2012 22:26:01 -0400 (EDT)
Message-ID: <4FD7FA32.2010006@invisiblethingslab.com>
Date: Wed, 13 Jun 2012 04:25:54 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Kouya Shimura <kouya@jp.fujitsu.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
	<87hauhvx5x.fsf@jp.fujitsu.com>
In-Reply-To: <87hauhvx5x.fsf@jp.fujitsu.com>
X-Enigmail-Version: 1.4.1
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3586592641735229152=="
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)
--===============3586592641735229152==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigB23037EAE21C4DA682E045B6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB23037EAE21C4DA682E045B6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12.06.2012 08:53, Kouya Shimura wrote:
> Hi,
>=20
> The owner support is introduced in c/s 8175, not by me.
> Anyway, something is wrong with your execution trace.
>=20
>> + '[' 6 -gt 5 ']'
>> + sleep 1
> <<< Why claim_lock() returns here???
>> + do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000=
aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
>> + losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bb=
ab7a9/Vi
>=20
> I don't know what is a problem and whether your patch resolves the issu=
e or not.

I can confirm this problem, I've faced it some time ago:
http://lists.xen.org/archives/html/xen-devel/2011-07/msg00182.html

> It would be better to replace locking.sh with the RHEL5 implementation
> which uses 'flock' rather than to fix it.

I agree. Currently I've workarounded it by adding flock in udev rule whic=
h run
this script, but working locking.sh will be much nicer.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigB23037EAE21C4DA682E045B6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP1/ozAAoJENuP0xzK19csPRkH/Ra4s34ouMHG9YQ9eNDxjii5
xCM1i9OR1m69uY6tuJl5zY2Wvx0UDPnujGrSFLqZw/A84yI9CzjVskkWIXzaq+FA
ZxZFjHW9tDT4ubmz2rBKNYvd2+oFyiGB3/0zkBefjI6pY0R6lSlVKluOOxL8JDXl
e4KHvVKk4YijBuAGNm9e81rh3y/IDomUZMl0Stv2QgW3cMLmaiIWhU1t1slp+r0z
S34nE6zmae1B/5o4GhWNKC34QxwzA7zkEwsC/eXbW39uUrT8eC7cwGWH7iI0MHn1
etrP1pSRcn8YIzQBWbZGJ/BGViBzv1+ZqVs4ef+fhgjeFtuG0nMT/rMLXJ3L/V4=
=zXeH
-----END PGP SIGNATURE-----

--------------enigB23037EAE21C4DA682E045B6--


--===============3586592641735229152==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3586592641735229152==--


From xen-devel-bounces@lists.xen.org Wed Jun 13 07:00:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 07: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 1SehYc-0001NS-2w; Wed, 13 Jun 2012 06:59:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SehYa-0001NN-Hu
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 06:59:56 +0000
Received: from [85.158.139.83:51354] by server-1.bemta-5.messagelabs.com id
	32/47-19721-B6A38DF4; Wed, 13 Jun 2012 06:59:55 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339570792!27384657!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30440 invoked from network); 13 Jun 2012 06:59:53 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-182.messagelabs.com with SMTP;
	13 Jun 2012 06:59:53 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78843245; Wed, 13 Jun 2012 08:59:52 +0200
Message-ID: <1339570785.4705.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 13 Jun 2012 08:59:45 +0200
In-Reply-To: <1339491730.24104.6.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7869236085360857873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7869236085360857873==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-fHAEcfhSCN2mjTRBDqju"


--=-fHAEcfhSCN2mjTRBDqju
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-12 at 10:02 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 16:14 +0100, Dario Faggioli wrote:
> > On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > > git-commit --author will do this for you and I think git-send-email
> > > will then generate appropriate output.
> > >=20
> > Oh, thanks... Do you happen to know what a mercurial equivalent for thi=
s
> > could be? :-P
>=20
> Ian J answered for the general commit case but in case you are
> interested for the mq case you can put a comment at the top of the patch
> (before the changelog) with the same form as what "hg export" gives you.
> e.g.:
>         # HG changeset patch
>         # User Ian Campbell <ian.campbell@citrix.com>
>=20
I am, indeed, interested in patchqueues... So thanks to both of you. :-)

> This makes qpush do the right thing (IIRC, I didn't try it just now...).
>=20
I see. It seems `hg qrefresh' also takes a -u argument which is doing
the trick.

Anyway, thanks again,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-fHAEcfhSCN2mjTRBDqju
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/YOmIACgkQk4XaBE3IOsQD1wCgkFU+2SwOi6QsQEG9mrUH/aoi
vlUAoICv6yP7h0I/YeLEgC5MovJI0tgM
=S9wz
-----END PGP SIGNATURE-----

--=-fHAEcfhSCN2mjTRBDqju--



--===============7869236085360857873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7869236085360857873==--



From xen-devel-bounces@lists.xen.org Wed Jun 13 07:00:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 07: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 1SehYc-0001NS-2w; Wed, 13 Jun 2012 06:59:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SehYa-0001NN-Hu
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 06:59:56 +0000
Received: from [85.158.139.83:51354] by server-1.bemta-5.messagelabs.com id
	32/47-19721-B6A38DF4; Wed, 13 Jun 2012 06:59:55 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339570792!27384657!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30440 invoked from network); 13 Jun 2012 06:59:53 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-182.messagelabs.com with SMTP;
	13 Jun 2012 06:59:53 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78843245; Wed, 13 Jun 2012 08:59:52 +0200
Message-ID: <1339570785.4705.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 13 Jun 2012 08:59:45 +0200
In-Reply-To: <1339491730.24104.6.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7869236085360857873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7869236085360857873==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-fHAEcfhSCN2mjTRBDqju"


--=-fHAEcfhSCN2mjTRBDqju
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-12 at 10:02 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 16:14 +0100, Dario Faggioli wrote:
> > On Fri, 2012-06-08 at 15:03 +0100, Ian Jackson wrote:
> > > git-commit --author will do this for you and I think git-send-email
> > > will then generate appropriate output.
> > >=20
> > Oh, thanks... Do you happen to know what a mercurial equivalent for thi=
s
> > could be? :-P
>=20
> Ian J answered for the general commit case but in case you are
> interested for the mq case you can put a comment at the top of the patch
> (before the changelog) with the same form as what "hg export" gives you.
> e.g.:
>         # HG changeset patch
>         # User Ian Campbell <ian.campbell@citrix.com>
>=20
I am, indeed, interested in patchqueues... So thanks to both of you. :-)

> This makes qpush do the right thing (IIRC, I didn't try it just now...).
>=20
I see. It seems `hg qrefresh' also takes a -u argument which is doing
the trick.

Anyway, thanks again,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-fHAEcfhSCN2mjTRBDqju
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/YOmIACgkQk4XaBE3IOsQD1wCgkFU+2SwOi6QsQEG9mrUH/aoi
vlUAoICv6yP7h0I/YeLEgC5MovJI0tgM
=S9wz
-----END PGP SIGNATURE-----

--=-fHAEcfhSCN2mjTRBDqju--



--===============7869236085360857873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7869236085360857873==--



From xen-devel-bounces@lists.xen.org Wed Jun 13 07:59:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 07:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeiTv-0001rv-Hf; Wed, 13 Jun 2012 07:59:11 +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 1SeiTu-0001rq-4N
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 07:59:10 +0000
Received: from [85.158.143.35:50913] by server-1.bemta-4.messagelabs.com id
	9F/EE-24392-D4848DF4; Wed, 13 Jun 2012 07:59:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339574338!14239432!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDcxMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDcxMDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11333 invoked from network); 13 Jun 2012 07:59:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 07:59:01 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jored mo38) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j0719ao5D5nioy ;
	Wed, 13 Jun 2012 09:58:56 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id AD57B18638; Wed, 13 Jun 2012 09:58:54 +0200 (CEST)
Date: Wed, 13 Jun 2012 09:58:54 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120613075853.GA22553@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339514061.24104.81.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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 Tue, Jun 12, Ian Campbell wrote:

> On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > xl-network-configuration. Adjust to new DOCDIR location.
> 
> The reason for omitting the extension is that it can be .html or .txt
> depending on the context which the link is given in.

How is that link ' F<xl-network-configuration>' supposed to be filled?
I think F refers to a local filename.


> > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > +			misc/xl-disk-configuration.txt \
> > +			misc/vbd-interface.txt \
> > +			misc/xl-network-configuration.markdown
> 
> Any reason not to install the whole of $(DOC_TXT) instead of just this
> subset?

Most of it looks like developer documentation to me. In the end
kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
installed in addition to the files above.

> > diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -255,13 +255,13 @@ devices which the guest will contain.
> >  
> >  Specifies the disks (both emulated disks and Xen virtual block
> >  devices) which are to be provided to the guest, and what objects on
> > -the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
> > +the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
> >  
> >  =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
> >  
> >  Specifies the networking provision (both emulated network adapters,
> >  and Xen virtual interfaces) to provided to the guest.  See
> > -F<docs/misc/xl-network-configuration.markdown>.
> > +F<@DOCDIR@/xl-network-configuration.markdown>.
> 
> I'm slightly concerned about what all this will mean for the HTML
> generated docs, in particular the ones hosted at
> http://xenbits.xen.org/docs/unstable/. Currently they aren't actual
> working links there but they do at least reference the real path in the
> source tree.

I think the tool which generates the html files could be smarter and
turn the string 'F<@DOCDIR@' into a html link.

> At the very least it would be simpler to deal with this if the misc part
> of the path was retainined, both in these references and in the actual
> install location (e.g. @DOCDIR@/misc).

I will change that part and put it into a /misc directory.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 07:59:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 07:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeiTv-0001rv-Hf; Wed, 13 Jun 2012 07:59:11 +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 1SeiTu-0001rq-4N
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 07:59:10 +0000
Received: from [85.158.143.35:50913] by server-1.bemta-4.messagelabs.com id
	9F/EE-24392-D4848DF4; Wed, 13 Jun 2012 07:59:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339574338!14239432!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDcxMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDcxMDc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11333 invoked from network); 13 Jun 2012 07:59:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 07:59:01 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jored mo38) (RZmta 29.10 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j0719ao5D5nioy ;
	Wed, 13 Jun 2012 09:58:56 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id AD57B18638; Wed, 13 Jun 2012 09:58:54 +0200 (CEST)
Date: Wed, 13 Jun 2012 09:58:54 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120613075853.GA22553@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339514061.24104.81.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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 Tue, Jun 12, Ian Campbell wrote:

> On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > xl-network-configuration. Adjust to new DOCDIR location.
> 
> The reason for omitting the extension is that it can be .html or .txt
> depending on the context which the link is given in.

How is that link ' F<xl-network-configuration>' supposed to be filled?
I think F refers to a local filename.


> > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > +			misc/xl-disk-configuration.txt \
> > +			misc/vbd-interface.txt \
> > +			misc/xl-network-configuration.markdown
> 
> Any reason not to install the whole of $(DOC_TXT) instead of just this
> subset?

Most of it looks like developer documentation to me. In the end
kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
installed in addition to the files above.

> > diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -255,13 +255,13 @@ devices which the guest will contain.
> >  
> >  Specifies the disks (both emulated disks and Xen virtual block
> >  devices) which are to be provided to the guest, and what objects on
> > -the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
> > +the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
> >  
> >  =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
> >  
> >  Specifies the networking provision (both emulated network adapters,
> >  and Xen virtual interfaces) to provided to the guest.  See
> > -F<docs/misc/xl-network-configuration.markdown>.
> > +F<@DOCDIR@/xl-network-configuration.markdown>.
> 
> I'm slightly concerned about what all this will mean for the HTML
> generated docs, in particular the ones hosted at
> http://xenbits.xen.org/docs/unstable/. Currently they aren't actual
> working links there but they do at least reference the real path in the
> source tree.

I think the tool which generates the html files could be smarter and
turn the string 'F<@DOCDIR@' into a html link.

> At the very least it would be simpler to deal with this if the misc part
> of the path was retainined, both in these references and in the actual
> install location (e.g. @DOCDIR@/misc).

I will change that part and put it into a /misc directory.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWs-0002UZ-Ex; Wed, 13 Jun 2012 08:02:14 +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 1SeiWq-0002Ty-Ld
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:12 +0000
Received: from [193.109.254.147:43285] by server-11.bemta-14.messagelabs.com
	id 07/43-02727-30948DF4; Wed, 13 Jun 2012 08:02:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339574531!9507631!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25576 invoked from network); 13 Jun 2012 08:02:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:02:11 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo96) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J07c90o5D7VLOX ;
	Wed, 13 Jun 2012 10:02:10 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 057BE1863A;
	Wed, 13 Jun 2012 10:02:08 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 306676f2c25b58e2cc094017f53910cb0c9ea9a9
Message-Id: <306676f2c25b58e2cc09.1339574507@probook.site>
In-Reply-To: <patchbomb.1339574504@probook.site>
References: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:47 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill PACKAGE_TARNAME
	in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1339574441 -7200
# Node ID 306676f2c25b58e2cc094017f53910cb0c9ea9a9
# Parent  57679d60e43077004757aede949e41b5e297e028
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
preserve the currently used path, which ends with /xen, specify a value
for PACKAGE_TARNAME. Without this change the path would end with
/xen-hypervisor.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 57679d60e430 -r 306676f2c25b tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -3,7 +3,7 @@
 
 AC_PREREQ([2.67])
 AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
-    [xen-devel@lists.xensource.com])
+    [xen-devel@lists.xensource.com], [xen], [http://www.xen.org/])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
 AC_CONFIG_FILES([../config/Tools.mk])
 AC_CONFIG_HEADERS([config.h])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWs-0002UZ-Ex; Wed, 13 Jun 2012 08:02:14 +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 1SeiWq-0002Ty-Ld
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:12 +0000
Received: from [193.109.254.147:43285] by server-11.bemta-14.messagelabs.com
	id 07/43-02727-30948DF4; Wed, 13 Jun 2012 08:02:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339574531!9507631!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25576 invoked from network); 13 Jun 2012 08:02:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:02:11 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo96) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J07c90o5D7VLOX ;
	Wed, 13 Jun 2012 10:02:10 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 057BE1863A;
	Wed, 13 Jun 2012 10:02:08 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 306676f2c25b58e2cc094017f53910cb0c9ea9a9
Message-Id: <306676f2c25b58e2cc09.1339574507@probook.site>
In-Reply-To: <patchbomb.1339574504@probook.site>
References: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:47 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill PACKAGE_TARNAME
	in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1339574441 -7200
# Node ID 306676f2c25b58e2cc094017f53910cb0c9ea9a9
# Parent  57679d60e43077004757aede949e41b5e297e028
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
preserve the currently used path, which ends with /xen, specify a value
for PACKAGE_TARNAME. Without this change the path would end with
/xen-hypervisor.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 57679d60e430 -r 306676f2c25b tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -3,7 +3,7 @@
 
 AC_PREREQ([2.67])
 AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
-    [xen-devel@lists.xensource.com])
+    [xen-devel@lists.xensource.com], [xen], [http://www.xen.org/])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
 AC_CONFIG_FILES([../config/Tools.mk])
 AC_CONFIG_HEADERS([config.h])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWs-0002UR-2j; Wed, 13 Jun 2012 08:02:14 +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 1SeiWq-0002Tq-3x
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:12 +0000
Received: from [85.158.143.99:17406] by server-2.bemta-4.messagelabs.com id
	C5/C9-17938-30948DF4; Wed, 13 Jun 2012 08:02:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339574530!25553926!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8205 invoked from network); 13 Jun 2012 08:02:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:02:10 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jorabe mo22) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R004c8o5D5lqdT ;
	Wed, 13 Jun 2012 10:02:09 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C60EF18638;
	Wed, 13 Jun 2012 10:02:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ea554d05821b95a7e96e4a25cbf953c5abe35aeb
Message-Id: <ea554d05821b95a7e96e.1339574505@probook.site>
In-Reply-To: <patchbomb.1339574504@probook.site>
References: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:45 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version check
	for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339572293 -7200
# Node ID ea554d05821b95a7e96e4a25cbf953c5abe35aeb
# Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
tools/configure.ac: add version check for glib2

xen-unstable fails to build in a SLES10SP4 environment since a long time
because the included version of glib is slightly older than the required
glib version. According to the docs glib version 2.12 includes base64
support, but SLES10 is shipped with glib 2.8.6:

qemu-timer-common.o: In function `init_get_clock':
/usr/src/packages/BUILD/xen-4.2.25432/non-dbg/tools/qemu-xen-dir/qemu-timer-common.c:57:
undefined reference to `clock_gettime'
qga/guest-agent-commands.o: In function `qmp_guest_file_write':
qga/guest-agent-commands.c:249: undefined reference to `g_base64_decode'
qga/guest-agent-commands.o: In function `qmp_guest_file_read':
qga/guest-agent-commands.c:224: undefined reference to `g_base64_encode'
collect2: ld returned 1 exit status
make[3]: *** [qemu-ga] Error 1

Add a version check to configure to require at least glib 2.12 to build
qemu-upstream.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a70b35deb2b5 -r ea554d05821b tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -115,7 +115,7 @@ AX_PATH_PROG_OR_FAIL([BCC], [bcc])
 AX_PATH_PROG_OR_FAIL([IASL], [iasl])
 AX_CHECK_UUID
 AX_CHECK_CURSES
-PKG_CHECK_MODULES(glib, glib-2.0)
+PKG_CHECK_MODULES(glib, [glib-2.0 >= 2.12])
 
 # Check library path
 AX_DEFAULT_LIB

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWs-0002UR-2j; Wed, 13 Jun 2012 08:02:14 +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 1SeiWq-0002Tq-3x
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:12 +0000
Received: from [85.158.143.99:17406] by server-2.bemta-4.messagelabs.com id
	C5/C9-17938-30948DF4; Wed, 13 Jun 2012 08:02:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339574530!25553926!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8205 invoked from network); 13 Jun 2012 08:02:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:02:10 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jorabe mo22) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R004c8o5D5lqdT ;
	Wed, 13 Jun 2012 10:02:09 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C60EF18638;
	Wed, 13 Jun 2012 10:02:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ea554d05821b95a7e96e4a25cbf953c5abe35aeb
Message-Id: <ea554d05821b95a7e96e.1339574505@probook.site>
In-Reply-To: <patchbomb.1339574504@probook.site>
References: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:45 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version check
	for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339572293 -7200
# Node ID ea554d05821b95a7e96e4a25cbf953c5abe35aeb
# Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
tools/configure.ac: add version check for glib2

xen-unstable fails to build in a SLES10SP4 environment since a long time
because the included version of glib is slightly older than the required
glib version. According to the docs glib version 2.12 includes base64
support, but SLES10 is shipped with glib 2.8.6:

qemu-timer-common.o: In function `init_get_clock':
/usr/src/packages/BUILD/xen-4.2.25432/non-dbg/tools/qemu-xen-dir/qemu-timer-common.c:57:
undefined reference to `clock_gettime'
qga/guest-agent-commands.o: In function `qmp_guest_file_write':
qga/guest-agent-commands.c:249: undefined reference to `g_base64_decode'
qga/guest-agent-commands.o: In function `qmp_guest_file_read':
qga/guest-agent-commands.c:224: undefined reference to `g_base64_encode'
collect2: ld returned 1 exit status
make[3]: *** [qemu-ga] Error 1

Add a version check to configure to require at least glib 2.12 to build
qemu-upstream.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a70b35deb2b5 -r ea554d05821b tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -115,7 +115,7 @@ AX_PATH_PROG_OR_FAIL([BCC], [bcc])
 AX_PATH_PROG_OR_FAIL([IASL], [iasl])
 AX_CHECK_UUID
 AX_CHECK_CURSES
-PKG_CHECK_MODULES(glib, glib-2.0)
+PKG_CHECK_MODULES(glib, [glib-2.0 >= 2.12])
 
 # Check library path
 AX_DEFAULT_LIB

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWr-0002UJ-NV; Wed, 13 Jun 2012 08:02:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SeiWp-0002Tq-O1
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:11 +0000
Received: from [85.158.143.99:39125] by server-2.bemta-4.messagelabs.com id
	22/C9-17938-20948DF4; Wed, 13 Jun 2012 08:02:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339574530!31686043!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc0NDA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc0NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16285 invoked from network); 13 Jun 2012 08:02:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 08:02:10 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo86) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id F00b95o5D7TXfq ;
	Wed, 13 Jun 2012 10:02:09 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D43618637;
	Wed, 13 Jun 2012 10:02:07 +0200 (CEST)
MIME-Version: 1.0
Message-Id: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:44 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] tools/configure.ac 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


Changes:
tools/configure.ac: add version check for glib2
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

 tools/configure.ac   |    4 ++--
 tools/m4/pthread.m4  |    4 ++--
 tools/m4/ptyfuncs.m4 |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWs-0002Ur-WF; Wed, 13 Jun 2012 08:02:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SeiWr-0002U3-06
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:13 +0000
Received: from [85.158.143.35:52232] by server-1.bemta-4.messagelabs.com id
	81/25-24392-40948DF4; Wed, 13 Jun 2012 08:02:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339574531!5093258!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 564 invoked from network); 13 Jun 2012 08:02:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:02:11 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo75) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c075e9o5D7UQk8 ;
	Wed, 13 Jun 2012 10:02:10 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E6C7118639;
	Wed, 13 Jun 2012 10:02:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 57679d60e43077004757aede949e41b5e297e028
Message-Id: <57679d60e43077004757.1339574506@probook.site>
In-Reply-To: <patchbomb.1339574504@probook.site>
References: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] tools/m4: add AC_LANG_SOURCE to fix
	autoconf warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339574439 -7200
# Node ID 57679d60e43077004757aede949e41b5e297e028
# Parent  ea554d05821b95a7e96e4a25cbf953c5abe35aeb
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings

I see these warnings with autoconf 2.68, add AC_LANG_SOURCE as suggested
by upstream documentation.

...
 # bash autogen.sh
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level


Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ea554d05821b -r 57679d60e430 tools/m4/pthread.m4
--- a/tools/m4/pthread.m4
+++ b/tools/m4/pthread.m4
@@ -24,13 +24,13 @@ AC_DEFUN([AX_CHECK_PTHREAD],[
         AX_PTHREAD_CV2VARS
         AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
         AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
-        AC_LINK_IFELSE([
+        AC_LINK_IFELSE([AC_LANG_SOURCE([
 #include <pthread.h>
 int main(void) {
   pthread_atfork(0,0,0);
   pthread_create(0,0,0,0);
 }
-],[],[ax_cv_pthread_flags=failed])
+])],[],[ax_cv_pthread_flags=failed])
         AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
     ])
     if test "x$ax_cv_pthread_flags" = xfailed; then
diff -r ea554d05821b -r 57679d60e430 tools/m4/ptyfuncs.m4
--- a/tools/m4/ptyfuncs.m4
+++ b/tools/m4/ptyfuncs.m4
@@ -9,7 +9,7 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [
             fi
             AX_SAVEVAR_SAVE(LIBS)
             LIBS="$LIBS $ax_cv_ptyfuncs_libs"
-            AC_LINK_IFELSE([
+            AC_LINK_IFELSE([AC_LANG_SOURCE([
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
 #endif
@@ -17,7 +17,7 @@ int main(void) {
   openpty(0,0,0,0,0);
   login_tty(0);
 }
-],[
+])],[
                 break
             ],[])
             AX_SAVEVAR_RESTORE(LIBS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWr-0002UJ-NV; Wed, 13 Jun 2012 08:02:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SeiWp-0002Tq-O1
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:11 +0000
Received: from [85.158.143.99:39125] by server-2.bemta-4.messagelabs.com id
	22/C9-17938-20948DF4; Wed, 13 Jun 2012 08:02:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1339574530!31686043!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc0NDA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc0NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16285 invoked from network); 13 Jun 2012 08:02:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 08:02:10 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo86) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id F00b95o5D7TXfq ;
	Wed, 13 Jun 2012 10:02:09 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D43618637;
	Wed, 13 Jun 2012 10:02:07 +0200 (CEST)
MIME-Version: 1.0
Message-Id: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:44 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] tools/configure.ac 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


Changes:
tools/configure.ac: add version check for glib2
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

 tools/configure.ac   |    4 ++--
 tools/m4/pthread.m4  |    4 ++--
 tools/m4/ptyfuncs.m4 |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:02: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 1SeiWs-0002Ur-WF; Wed, 13 Jun 2012 08:02:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1SeiWr-0002U3-06
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:02:13 +0000
Received: from [85.158.143.35:52232] by server-1.bemta-4.messagelabs.com id
	81/25-24392-40948DF4; Wed, 13 Jun 2012 08:02:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339574531!5093258!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2NzU=\n,UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 564 invoked from network); 13 Jun 2012 08:02:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:02:11 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (joses mo75) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c075e9o5D7UQk8 ;
	Wed, 13 Jun 2012 10:02:10 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E6C7118639;
	Wed, 13 Jun 2012 10:02:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 57679d60e43077004757aede949e41b5e297e028
Message-Id: <57679d60e43077004757.1339574506@probook.site>
In-Reply-To: <patchbomb.1339574504@probook.site>
References: <patchbomb.1339574504@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 10:01:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] tools/m4: add AC_LANG_SOURCE to fix
	autoconf warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339574439 -7200
# Node ID 57679d60e43077004757aede949e41b5e297e028
# Parent  ea554d05821b95a7e96e4a25cbf953c5abe35aeb
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings

I see these warnings with autoconf 2.68, add AC_LANG_SOURCE as suggested
by upstream documentation.

...
 # bash autogen.sh
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level


Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ea554d05821b -r 57679d60e430 tools/m4/pthread.m4
--- a/tools/m4/pthread.m4
+++ b/tools/m4/pthread.m4
@@ -24,13 +24,13 @@ AC_DEFUN([AX_CHECK_PTHREAD],[
         AX_PTHREAD_CV2VARS
         AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
         AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
-        AC_LINK_IFELSE([
+        AC_LINK_IFELSE([AC_LANG_SOURCE([
 #include <pthread.h>
 int main(void) {
   pthread_atfork(0,0,0);
   pthread_create(0,0,0,0);
 }
-],[],[ax_cv_pthread_flags=failed])
+])],[],[ax_cv_pthread_flags=failed])
         AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
     ])
     if test "x$ax_cv_pthread_flags" = xfailed; then
diff -r ea554d05821b -r 57679d60e430 tools/m4/ptyfuncs.m4
--- a/tools/m4/ptyfuncs.m4
+++ b/tools/m4/ptyfuncs.m4
@@ -9,7 +9,7 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [
             fi
             AX_SAVEVAR_SAVE(LIBS)
             LIBS="$LIBS $ax_cv_ptyfuncs_libs"
-            AC_LINK_IFELSE([
+            AC_LINK_IFELSE([AC_LANG_SOURCE([
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
 #endif
@@ -17,7 +17,7 @@ int main(void) {
   openpty(0,0,0,0,0);
   login_tty(0);
 }
-],[
+])],[
                 break
             ],[])
             AX_SAVEVAR_RESTORE(LIBS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:07:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08: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 1SeibG-0003Dt-NN; Wed, 13 Jun 2012 08:06: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 1SeibF-0003Df-Q8
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:06:45 +0000
Received: from [85.158.143.35:8705] by server-1.bemta-4.messagelabs.com id
	5D/BD-24392-51A48DF4; Wed, 13 Jun 2012 08:06:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339574803!13514228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19287 invoked from network); 13 Jun 2012 08:06:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:06:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12987516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:06:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:06:19 +0100
Message-ID: <1339574778.24104.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 13 Jun 2012 09:06:18 +0100
In-Reply-To: <20120613075853.GA22553@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
	<20120613075853.GA22553@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, 2012-06-13 at 08:58 +0100, Olaf Hering wrote:
> On Tue, Jun 12, Ian Campbell wrote:
> 
> > On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > > xl-network-configuration. Adjust to new DOCDIR location.
> > 
> > The reason for omitting the extension is that it can be .html or .txt
> > depending on the context which the link is given in.
> 
> How is that link ' F<xl-network-configuration>' supposed to be filled?
> I think F refers to a local filename.

F<..> just means "format as a filename i.e. italics", it doesn't turn
into an actual link even in html. I should have said "reference" rather
than "link" I think.

> > > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > > +			misc/xl-disk-configuration.txt \
> > > +			misc/vbd-interface.txt \
> > > +			misc/xl-network-configuration.markdown
> > 
> > Any reason not to install the whole of $(DOC_TXT) instead of just this
> > subset?
> 
> Most of it looks like developer documentation to me. In the end
> kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
> installed in addition to the files above.

Perhaps we should be splitting the misc dir up into user and dev etc?

> 
> > > diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
> > > --- a/docs/man/xl.cfg.pod.5
> > > +++ b/docs/man/xl.cfg.pod.5
> > > @@ -255,13 +255,13 @@ devices which the guest will contain.
> > >  
> > >  Specifies the disks (both emulated disks and Xen virtual block
> > >  devices) which are to be provided to the guest, and what objects on
> > > -the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
> > > +the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
> > >  
> > >  =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
> > >  
> > >  Specifies the networking provision (both emulated network adapters,
> > >  and Xen virtual interfaces) to provided to the guest.  See
> > > -F<docs/misc/xl-network-configuration.markdown>.
> > > +F<@DOCDIR@/xl-network-configuration.markdown>.
> > 
> > I'm slightly concerned about what all this will mean for the HTML
> > generated docs, in particular the ones hosted at
> > http://xenbits.xen.org/docs/unstable/. Currently they aren't actual
> > working links there but they do at least reference the real path in the
> > source tree.
> 
> I think the tool which generates the html files could be smarter and
> turn the string 'F<@DOCDIR@' into a html link.
> 
> > At the very least it would be simpler to deal with this if the misc part
> > of the path was retainined, both in these references and in the actual
> > install location (e.g. @DOCDIR@/misc).
> 
> I will change that part and put it into a /misc directory.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:07:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08: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 1SeibG-0003Dt-NN; Wed, 13 Jun 2012 08:06: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 1SeibF-0003Df-Q8
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:06:45 +0000
Received: from [85.158.143.35:8705] by server-1.bemta-4.messagelabs.com id
	5D/BD-24392-51A48DF4; Wed, 13 Jun 2012 08:06:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339574803!13514228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19287 invoked from network); 13 Jun 2012 08:06:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:06:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12987516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:06:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:06:19 +0100
Message-ID: <1339574778.24104.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 13 Jun 2012 09:06:18 +0100
In-Reply-To: <20120613075853.GA22553@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
	<20120613075853.GA22553@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, 2012-06-13 at 08:58 +0100, Olaf Hering wrote:
> On Tue, Jun 12, Ian Campbell wrote:
> 
> > On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > > xl-network-configuration. Adjust to new DOCDIR location.
> > 
> > The reason for omitting the extension is that it can be .html or .txt
> > depending on the context which the link is given in.
> 
> How is that link ' F<xl-network-configuration>' supposed to be filled?
> I think F refers to a local filename.

F<..> just means "format as a filename i.e. italics", it doesn't turn
into an actual link even in html. I should have said "reference" rather
than "link" I think.

> > > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > > +			misc/xl-disk-configuration.txt \
> > > +			misc/vbd-interface.txt \
> > > +			misc/xl-network-configuration.markdown
> > 
> > Any reason not to install the whole of $(DOC_TXT) instead of just this
> > subset?
> 
> Most of it looks like developer documentation to me. In the end
> kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
> installed in addition to the files above.

Perhaps we should be splitting the misc dir up into user and dev etc?

> 
> > > diff -r a70b35deb2b5 -r d5280420afc9 docs/man/xl.cfg.pod.5
> > > --- a/docs/man/xl.cfg.pod.5
> > > +++ b/docs/man/xl.cfg.pod.5
> > > @@ -255,13 +255,13 @@ devices which the guest will contain.
> > >  
> > >  Specifies the disks (both emulated disks and Xen virtual block
> > >  devices) which are to be provided to the guest, and what objects on
> > > -the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
> > > +the they should map to.  See F<@DOCDIR@/xl-disk-configuration.txt>.
> > >  
> > >  =item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
> > >  
> > >  Specifies the networking provision (both emulated network adapters,
> > >  and Xen virtual interfaces) to provided to the guest.  See
> > > -F<docs/misc/xl-network-configuration.markdown>.
> > > +F<@DOCDIR@/xl-network-configuration.markdown>.
> > 
> > I'm slightly concerned about what all this will mean for the HTML
> > generated docs, in particular the ones hosted at
> > http://xenbits.xen.org/docs/unstable/. Currently they aren't actual
> > working links there but they do at least reference the real path in the
> > source tree.
> 
> I think the tool which generates the html files could be smarter and
> turn the string 'F<@DOCDIR@' into a html link.
> 
> > At the very least it would be simpler to deal with this if the misc part
> > of the path was retainined, both in these references and in the actual
> > install location (e.g. @DOCDIR@/misc).
> 
> I will change that part and put it into a /misc directory.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:07:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08: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 1SeibL-0003Ed-3a; Wed, 13 Jun 2012 08:06:51 +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 1SeibJ-0003EF-8X
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:06:49 +0000
Received: from [85.158.143.35:8961] by server-2.bemta-4.messagelabs.com id
	8D/90-17938-81A48DF4; Wed, 13 Jun 2012 08:06:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339574755!14794220!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk0ODI2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30083 invoked from network); 13 Jun 2012 08:05:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-21.messagelabs.com with SMTP;
	13 Jun 2012 08:05:56 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 13 Jun 2012 01:05:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="111531469"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Jun 2012 01:05:55 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 13 Jun 2012 01:05:54 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Wed, 13 Jun 2012 16:05:52 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
Thread-Index: Ac1JO1lUOYFQl4PoQNeTRPYYZQub0Q==
Date: Wed, 13 Jun 2012 08:05:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522B51C@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_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen vMCE bugfix: inject vMCE# to all vcpus

In our test for win8 guest mce, we find a bug in that no matter what SRAO/S=
RAR
error xen inject to win8 guest, it always reboot.

The root cause is, current Xen vMCE logic inject vMCE# only to vcpu0, this =
is
not correct for Intel MCE (Under Intel arch, h/w generate MCE# to all CPUs)=
.

This patch fix vMCE injection bug, injecting vMCE# to all vcpus.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 19c15f3dfe1f xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Tue Jun 05 03:18:00 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Wed Jun 13 23:40:45 2012 +0800
@@ -167,7 +167,6 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
         uint64_t gstatus);
-int inject_vmce(struct domain *d);
 int vmce_domain_inject(struct mcinfo_bank *bank, struct domain *d, struct =
mcinfo_global *global);
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
diff -r 19c15f3dfe1f xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Jun 05 03:18:00 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Jun 13 23:40:45 2012 +0800
@@ -638,6 +638,32 @@
     return rec;
 }
=20
+static int inject_vmce(struct domain *d)
+{
+    struct vcpu *v;
+
+    /* inject vMCE to all vcpus */
+    for_each_vcpu(d, v)
+    {
+        if ( !test_and_set_bool(v->mce_pending) &&
+            ((d->is_hvm) ? 1 :
+            guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) )
+        {
+            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            vcpu_kick(v);
+        }
+        else
+        {
+            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
 static void intel_memerr_dhandler(
              struct mca_binfo *binfo,
              enum mce_result *result,
@@ -718,11 +744,8 @@
=20
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d) < 0 )
-                {
-                    mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
-                      " failed\n", d->domain_id);
                     goto vmce_failed;
-                }
+
                 /* Impacted domain go on with domain's recovery job
                  * if the domain has its own MCA handler.
                  * For xen, it has contained the error and finished
diff -r 19c15f3dfe1f xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Jun 05 03:18:00 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Jun 13 23:40:45 2012 +0800
@@ -389,53 +389,6 @@
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
                           vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
=20
-int inject_vmce(struct domain *d)
-{
-    int cpu =3D smp_processor_id();
-
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
-    {
-        if ( d->is_hvm )
-        {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
-                       d->domain_id);
-            vcpu_kick(d->vcpu[0]);
-        }
-        else
-        {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to PV DOM%d\n",
-                       d->domain_id);
-            if ( guest_has_trap_callback(d, 0, TRAP_machine_check) )
-            {
-                cpumask_copy(d->vcpu[0]->cpu_affinity_tmp,
-                             d->vcpu[0]->cpu_affinity);
-                mce_printk(MCE_VERBOSE, "MCE: CPU%d set affinity, old %d\n=
",
-                           cpu, d->vcpu[0]->processor);
-                vcpu_set_affinity(d->vcpu[0], cpumask_of(cpu));
-                vcpu_kick(d->vcpu[0]);
-            }
-            else
-            {
-                mce_printk(MCE_VERBOSE,
-                           "MCE: Kill PV guest with No MCE handler\n");
-                domain_crash(d);
-            }
-        }
-    }
-    else
-    {
-        /* new vMCE comes while first one has not been injected yet,
-         * in this case, inject fail. [We can't lose this vMCE for
-         * the mce node's consistency].
-         */
-        mce_printk(MCE_QUIET, "There's a pending vMCE waiting to be inject=
ed "
-                   " to this DOM%d!\n", d->domain_id);
-        return -1;
-    }
-    return 0;
-}
-
 /* This node list records errors impacting a domain. when one
  * MCE# happens, one error bank impacts a domain. This error node
  * will be inserted to the tail of the per_dom data for vMCE# MSR=

--_002_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="vmce-injection-bugfix.patch"
Content-Description: vmce-injection-bugfix.patch
Content-Disposition: attachment; filename="vmce-injection-bugfix.patch";
	size=4630; creation-date="Wed, 13 Jun 2012 08:00:59 GMT";
	modification-date="Wed, 13 Jun 2012 15:53:10 GMT"
Content-Transfer-Encoding: base64

WGVuIHZNQ0UgYnVnZml4OiBpbmplY3Qgdk1DRSMgdG8gYWxsIHZjcHVzCgpJbiBvdXIgdGVzdCBm
b3Igd2luOCBndWVzdCBtY2UsIHdlIGZpbmQgYSBidWcgaW4gdGhhdCBubyBtYXR0ZXIgd2hhdCBT
UkFPL1NSQVIKZXJyb3IgeGVuIGluamVjdCB0byB3aW44IGd1ZXN0LCBpdCBhbHdheXMgcmVib290
LgoKVGhlIHJvb3QgY2F1c2UgaXMsIGN1cnJlbnQgWGVuIHZNQ0UgbG9naWMgaW5qZWN0IHZNQ0Uj
IG9ubHkgdG8gdmNwdTAsIHRoaXMgaXMKbm90IGNvcnJlY3QgZm9yIEludGVsIE1DRSAoVW5kZXIg
SW50ZWwgYXJjaCwgaC93IGdlbmVyYXRlIE1DRSMgdG8gYWxsIENQVXMpLgoKVGhpcyBwYXRjaCBm
aXggdk1DRSBpbmplY3Rpb24gYnVnLCBpbmplY3Rpbmcgdk1DRSMgdG8gYWxsIHZjcHVzLgoKU2ln
bmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1y
IDE5YzE1ZjNkZmUxZiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAotLS0gYS94ZW4vYXJj
aC94ODYvY3B1L21jaGVjay9tY2UuaAlUdWUgSnVuIDA1IDAzOjE4OjAwIDIwMTIgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJV2VkIEp1biAxMyAyMzo0MDo0NSAyMDEy
ICswODAwCkBAIC0xNjcsNyArMTY3LDYgQEAKIAogaW50IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBt
Y2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgdWludDY0X3Qg
Z3N0YXR1cyk7Ci1pbnQgaW5qZWN0X3ZtY2Uoc3RydWN0IGRvbWFpbiAqZCk7CiBpbnQgdm1jZV9k
b21haW5faW5qZWN0KHN0cnVjdCBtY2luZm9fYmFuayAqYmFuaywgc3RydWN0IGRvbWFpbiAqZCwg
c3RydWN0IG1jaW5mb19nbG9iYWwgKmdsb2JhbCk7CiAKIGV4dGVybiBpbnQgdm1jZV9pbml0KHN0
cnVjdCBjcHVpbmZvX3g4NiAqYyk7CmRpZmYgLXIgMTljMTVmM2RmZTFmIHhlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9p
bnRlbC5jCVR1ZSBKdW4gMDUgMDM6MTg6MDAgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay9tY2VfaW50ZWwuYwlXZWQgSnVuIDEzIDIzOjQwOjQ1IDIwMTIgKzA4MDAKQEAg
LTYzOCw2ICs2MzgsMzIgQEAKICAgICByZXR1cm4gcmVjOwogfQogCitzdGF0aWMgaW50IGluamVj
dF92bWNlKHN0cnVjdCBkb21haW4gKmQpCit7CisgICAgc3RydWN0IHZjcHUgKnY7CisKKyAgICAv
KiBpbmplY3Qgdk1DRSB0byBhbGwgdmNwdXMgKi8KKyAgICBmb3JfZWFjaF92Y3B1KGQsIHYpCisg
ICAgeworICAgICAgICBpZiAoICF0ZXN0X2FuZF9zZXRfYm9vbCh2LT5tY2VfcGVuZGluZykgJiYK
KyAgICAgICAgICAgICgoZC0+aXNfaHZtKSA/IDEgOgorICAgICAgICAgICAgZ3Vlc3RfaGFzX3Ry
YXBfY2FsbGJhY2soZCwgdi0+dmNwdV9pZCwgVFJBUF9tYWNoaW5lX2NoZWNrKSkgKQorICAgICAg
ICB7CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qgdk1D
RSB0byBkb20lZCB2Y3B1JWRcbiIsCisgICAgICAgICAgICAgICAgICAgICAgIGQtPmRvbWFpbl9p
ZCwgdi0+dmNwdV9pZCk7CisgICAgICAgICAgICB2Y3B1X2tpY2sodik7CisgICAgICAgIH0KKyAg
ICAgICAgZWxzZQorICAgICAgICB7CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwg
IkZhaWwgdG8gaW5qZWN0IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAgICAgICAg
ICAgICAgICBkLT5kb21haW5faWQsIHYtPnZjcHVfaWQpOworICAgICAgICAgICAgcmV0dXJuIC0x
OworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9CisKIHN0YXRpYyB2b2lkIGlu
dGVsX21lbWVycl9kaGFuZGxlcigKICAgICAgICAgICAgICBzdHJ1Y3QgbWNhX2JpbmZvICpiaW5m
bywKICAgICAgICAgICAgICBlbnVtIG1jZV9yZXN1bHQgKnJlc3VsdCwKQEAgLTcxOCwxMSArNzQ0
LDggQEAKIAogICAgICAgICAgICAgICAgIC8qIFdlIHdpbGwgaW5qZWN0IHZNQ0UgdG8gRE9NVSov
CiAgICAgICAgICAgICAgICAgaWYgKCBpbmplY3Rfdm1jZShkKSA8IDAgKQotICAgICAgICAgICAg
ICAgIHsKLSAgICAgICAgICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJpbmplY3Qg
dk1DRSB0byBET00lZCIKLSAgICAgICAgICAgICAgICAgICAgICAiIGZhaWxlZFxuIiwgZC0+ZG9t
YWluX2lkKTsKICAgICAgICAgICAgICAgICAgICAgZ290byB2bWNlX2ZhaWxlZDsKLSAgICAgICAg
ICAgICAgICB9CisKICAgICAgICAgICAgICAgICAvKiBJbXBhY3RlZCBkb21haW4gZ28gb24gd2l0
aCBkb21haW4ncyByZWNvdmVyeSBqb2IKICAgICAgICAgICAgICAgICAgKiBpZiB0aGUgZG9tYWlu
IGhhcyBpdHMgb3duIE1DQSBoYW5kbGVyLgogICAgICAgICAgICAgICAgICAqIEZvciB4ZW4sIGl0
IGhhcyBjb250YWluZWQgdGhlIGVycm9yIGFuZCBmaW5pc2hlZApkaWZmIC1yIDE5YzE1ZjNkZmUx
ZiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9t
Y2hlY2svdm1jZS5jCVR1ZSBKdW4gMDUgMDM6MTg6MDAgMjAxMiArMDgwMAorKysgYi94ZW4vYXJj
aC94ODYvY3B1L21jaGVjay92bWNlLmMJV2VkIEp1biAxMyAyMzo0MDo0NSAyMDEyICswODAwCkBA
IC0zODksNTMgKzM4OSw2IEBACiBIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFZNQ0VfVkNQVSwg
dm1jZV9zYXZlX3ZjcHVfY3R4dCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1jZV9sb2Fk
X3ZjcHVfY3R4dCwgMSwgSFZNU1JfUEVSX1ZDUFUpOwogCi1pbnQgaW5qZWN0X3ZtY2Uoc3RydWN0
IGRvbWFpbiAqZCkKLXsKLSAgICBpbnQgY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgpOwotCi0gICAg
LyogUFYgZ3Vlc3QgYW5kIEhWTSBndWVzdCBoYXZlIGRpZmZlcmVudCB2TUNFIyBpbmplY3Rpb24g
bWV0aG9kcy4gKi8KLSAgICBpZiAoICF0ZXN0X2FuZF9zZXRfYm9vbChkLT52Y3B1WzBdLT5tY2Vf
cGVuZGluZykgKQotICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQotICAgICAgICB7Ci0g
ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qgdk1DRSB0byBI
Vk0gRE9NICVkXG4iLAotICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAg
ICAgICAgICAgdmNwdV9raWNrKGQtPnZjcHVbMF0pOwotICAgICAgICB9Ci0gICAgICAgIGVsc2UK
LSAgICAgICAgewotICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5q
ZWN0IHZNQ0UgdG8gUFYgRE9NJWRcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgIGQtPmRvbWFp
bl9pZCk7Ci0gICAgICAgICAgICBpZiAoIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQsIDAsIFRS
QVBfbWFjaGluZV9jaGVjaykgKQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAgIGNwdW1h
c2tfY29weShkLT52Y3B1WzBdLT5jcHVfYWZmaW5pdHlfdG1wLAotICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBkLT52Y3B1WzBdLT5jcHVfYWZmaW5pdHkpOwotICAgICAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IENQVSVkIHNldCBhZmZpbml0eSwgb2xkICVkXG4i
LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgY3B1LCBkLT52Y3B1WzBdLT5wcm9jZXNzb3Ip
OwotICAgICAgICAgICAgICAgIHZjcHVfc2V0X2FmZmluaXR5KGQtPnZjcHVbMF0sIGNwdW1hc2tf
b2YoY3B1KSk7Ci0gICAgICAgICAgICAgICAgdmNwdV9raWNrKGQtPnZjcHVbMF0pOwotICAgICAg
ICAgICAgfQotICAgICAgICAgICAgZWxzZQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAg
IG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNF
OiBLaWxsIFBWIGd1ZXN0IHdpdGggTm8gTUNFIGhhbmRsZXJcbiIpOwotICAgICAgICAgICAgICAg
IGRvbWFpbl9jcmFzaChkKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgfQotICAgIH0KLSAgICBl
bHNlCi0gICAgewotICAgICAgICAvKiBuZXcgdk1DRSBjb21lcyB3aGlsZSBmaXJzdCBvbmUgaGFz
IG5vdCBiZWVuIGluamVjdGVkIHlldCwKLSAgICAgICAgICogaW4gdGhpcyBjYXNlLCBpbmplY3Qg
ZmFpbC4gW1dlIGNhbid0IGxvc2UgdGhpcyB2TUNFIGZvcgotICAgICAgICAgKiB0aGUgbWNlIG5v
ZGUncyBjb25zaXN0ZW5jeV0uCi0gICAgICAgICAqLwotICAgICAgICBtY2VfcHJpbnRrKE1DRV9R
VUlFVCwgIlRoZXJlJ3MgYSBwZW5kaW5nIHZNQ0Ugd2FpdGluZyB0byBiZSBpbmplY3RlZCAiCi0g
ICAgICAgICAgICAgICAgICAgIiB0byB0aGlzIERPTSVkIVxuIiwgZC0+ZG9tYWluX2lkKTsKLSAg
ICAgICAgcmV0dXJuIC0xOwotICAgIH0KLSAgICByZXR1cm4gMDsKLX0KLQogLyogVGhpcyBub2Rl
IGxpc3QgcmVjb3JkcyBlcnJvcnMgaW1wYWN0aW5nIGEgZG9tYWluLiB3aGVuIG9uZQogICogTUNF
IyBoYXBwZW5zLCBvbmUgZXJyb3IgYmFuayBpbXBhY3RzIGEgZG9tYWluLiBUaGlzIGVycm9yIG5v
ZGUKICAqIHdpbGwgYmUgaW5zZXJ0ZWQgdG8gdGhlIHRhaWwgb2YgdGhlIHBlcl9kb20gZGF0YSBm
b3Igdk1DRSMgTVNSCg==

--_002_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Jun 13 08:07:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08: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 1SeibL-0003Ed-3a; Wed, 13 Jun 2012 08:06:51 +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 1SeibJ-0003EF-8X
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:06:49 +0000
Received: from [85.158.143.35:8961] by server-2.bemta-4.messagelabs.com id
	8D/90-17938-81A48DF4; Wed, 13 Jun 2012 08:06:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339574755!14794220!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk0ODI2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30083 invoked from network); 13 Jun 2012 08:05:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-21.messagelabs.com with SMTP;
	13 Jun 2012 08:05:56 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 13 Jun 2012 01:05:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="111531469"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Jun 2012 01:05:55 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 13 Jun 2012 01:05:54 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Wed, 13 Jun 2012 16:05:52 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
Thread-Index: Ac1JO1lUOYFQl4PoQNeTRPYYZQub0Q==
Date: Wed, 13 Jun 2012 08:05:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522B51C@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_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen vMCE bugfix: inject vMCE# to all vcpus

In our test for win8 guest mce, we find a bug in that no matter what SRAO/S=
RAR
error xen inject to win8 guest, it always reboot.

The root cause is, current Xen vMCE logic inject vMCE# only to vcpu0, this =
is
not correct for Intel MCE (Under Intel arch, h/w generate MCE# to all CPUs)=
.

This patch fix vMCE injection bug, injecting vMCE# to all vcpus.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 19c15f3dfe1f xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Tue Jun 05 03:18:00 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Wed Jun 13 23:40:45 2012 +0800
@@ -167,7 +167,6 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
         uint64_t gstatus);
-int inject_vmce(struct domain *d);
 int vmce_domain_inject(struct mcinfo_bank *bank, struct domain *d, struct =
mcinfo_global *global);
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
diff -r 19c15f3dfe1f xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Jun 05 03:18:00 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Jun 13 23:40:45 2012 +0800
@@ -638,6 +638,32 @@
     return rec;
 }
=20
+static int inject_vmce(struct domain *d)
+{
+    struct vcpu *v;
+
+    /* inject vMCE to all vcpus */
+    for_each_vcpu(d, v)
+    {
+        if ( !test_and_set_bool(v->mce_pending) &&
+            ((d->is_hvm) ? 1 :
+            guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) )
+        {
+            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            vcpu_kick(v);
+        }
+        else
+        {
+            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
 static void intel_memerr_dhandler(
              struct mca_binfo *binfo,
              enum mce_result *result,
@@ -718,11 +744,8 @@
=20
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d) < 0 )
-                {
-                    mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
-                      " failed\n", d->domain_id);
                     goto vmce_failed;
-                }
+
                 /* Impacted domain go on with domain's recovery job
                  * if the domain has its own MCA handler.
                  * For xen, it has contained the error and finished
diff -r 19c15f3dfe1f xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Jun 05 03:18:00 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Jun 13 23:40:45 2012 +0800
@@ -389,53 +389,6 @@
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
                           vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
=20
-int inject_vmce(struct domain *d)
-{
-    int cpu =3D smp_processor_id();
-
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
-    {
-        if ( d->is_hvm )
-        {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
-                       d->domain_id);
-            vcpu_kick(d->vcpu[0]);
-        }
-        else
-        {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to PV DOM%d\n",
-                       d->domain_id);
-            if ( guest_has_trap_callback(d, 0, TRAP_machine_check) )
-            {
-                cpumask_copy(d->vcpu[0]->cpu_affinity_tmp,
-                             d->vcpu[0]->cpu_affinity);
-                mce_printk(MCE_VERBOSE, "MCE: CPU%d set affinity, old %d\n=
",
-                           cpu, d->vcpu[0]->processor);
-                vcpu_set_affinity(d->vcpu[0], cpumask_of(cpu));
-                vcpu_kick(d->vcpu[0]);
-            }
-            else
-            {
-                mce_printk(MCE_VERBOSE,
-                           "MCE: Kill PV guest with No MCE handler\n");
-                domain_crash(d);
-            }
-        }
-    }
-    else
-    {
-        /* new vMCE comes while first one has not been injected yet,
-         * in this case, inject fail. [We can't lose this vMCE for
-         * the mce node's consistency].
-         */
-        mce_printk(MCE_QUIET, "There's a pending vMCE waiting to be inject=
ed "
-                   " to this DOM%d!\n", d->domain_id);
-        return -1;
-    }
-    return 0;
-}
-
 /* This node list records errors impacting a domain. when one
  * MCE# happens, one error bank impacts a domain. This error node
  * will be inserted to the tail of the per_dom data for vMCE# MSR=

--_002_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="vmce-injection-bugfix.patch"
Content-Description: vmce-injection-bugfix.patch
Content-Disposition: attachment; filename="vmce-injection-bugfix.patch";
	size=4630; creation-date="Wed, 13 Jun 2012 08:00:59 GMT";
	modification-date="Wed, 13 Jun 2012 15:53:10 GMT"
Content-Transfer-Encoding: base64

WGVuIHZNQ0UgYnVnZml4OiBpbmplY3Qgdk1DRSMgdG8gYWxsIHZjcHVzCgpJbiBvdXIgdGVzdCBm
b3Igd2luOCBndWVzdCBtY2UsIHdlIGZpbmQgYSBidWcgaW4gdGhhdCBubyBtYXR0ZXIgd2hhdCBT
UkFPL1NSQVIKZXJyb3IgeGVuIGluamVjdCB0byB3aW44IGd1ZXN0LCBpdCBhbHdheXMgcmVib290
LgoKVGhlIHJvb3QgY2F1c2UgaXMsIGN1cnJlbnQgWGVuIHZNQ0UgbG9naWMgaW5qZWN0IHZNQ0Uj
IG9ubHkgdG8gdmNwdTAsIHRoaXMgaXMKbm90IGNvcnJlY3QgZm9yIEludGVsIE1DRSAoVW5kZXIg
SW50ZWwgYXJjaCwgaC93IGdlbmVyYXRlIE1DRSMgdG8gYWxsIENQVXMpLgoKVGhpcyBwYXRjaCBm
aXggdk1DRSBpbmplY3Rpb24gYnVnLCBpbmplY3Rpbmcgdk1DRSMgdG8gYWxsIHZjcHVzLgoKU2ln
bmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1y
IDE5YzE1ZjNkZmUxZiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAotLS0gYS94ZW4vYXJj
aC94ODYvY3B1L21jaGVjay9tY2UuaAlUdWUgSnVuIDA1IDAzOjE4OjAwIDIwMTIgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJV2VkIEp1biAxMyAyMzo0MDo0NSAyMDEy
ICswODAwCkBAIC0xNjcsNyArMTY3LDYgQEAKIAogaW50IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBt
Y2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgdWludDY0X3Qg
Z3N0YXR1cyk7Ci1pbnQgaW5qZWN0X3ZtY2Uoc3RydWN0IGRvbWFpbiAqZCk7CiBpbnQgdm1jZV9k
b21haW5faW5qZWN0KHN0cnVjdCBtY2luZm9fYmFuayAqYmFuaywgc3RydWN0IGRvbWFpbiAqZCwg
c3RydWN0IG1jaW5mb19nbG9iYWwgKmdsb2JhbCk7CiAKIGV4dGVybiBpbnQgdm1jZV9pbml0KHN0
cnVjdCBjcHVpbmZvX3g4NiAqYyk7CmRpZmYgLXIgMTljMTVmM2RmZTFmIHhlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9p
bnRlbC5jCVR1ZSBKdW4gMDUgMDM6MTg6MDAgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay9tY2VfaW50ZWwuYwlXZWQgSnVuIDEzIDIzOjQwOjQ1IDIwMTIgKzA4MDAKQEAg
LTYzOCw2ICs2MzgsMzIgQEAKICAgICByZXR1cm4gcmVjOwogfQogCitzdGF0aWMgaW50IGluamVj
dF92bWNlKHN0cnVjdCBkb21haW4gKmQpCit7CisgICAgc3RydWN0IHZjcHUgKnY7CisKKyAgICAv
KiBpbmplY3Qgdk1DRSB0byBhbGwgdmNwdXMgKi8KKyAgICBmb3JfZWFjaF92Y3B1KGQsIHYpCisg
ICAgeworICAgICAgICBpZiAoICF0ZXN0X2FuZF9zZXRfYm9vbCh2LT5tY2VfcGVuZGluZykgJiYK
KyAgICAgICAgICAgICgoZC0+aXNfaHZtKSA/IDEgOgorICAgICAgICAgICAgZ3Vlc3RfaGFzX3Ry
YXBfY2FsbGJhY2soZCwgdi0+dmNwdV9pZCwgVFJBUF9tYWNoaW5lX2NoZWNrKSkgKQorICAgICAg
ICB7CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qgdk1D
RSB0byBkb20lZCB2Y3B1JWRcbiIsCisgICAgICAgICAgICAgICAgICAgICAgIGQtPmRvbWFpbl9p
ZCwgdi0+dmNwdV9pZCk7CisgICAgICAgICAgICB2Y3B1X2tpY2sodik7CisgICAgICAgIH0KKyAg
ICAgICAgZWxzZQorICAgICAgICB7CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwg
IkZhaWwgdG8gaW5qZWN0IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAgICAgICAg
ICAgICAgICBkLT5kb21haW5faWQsIHYtPnZjcHVfaWQpOworICAgICAgICAgICAgcmV0dXJuIC0x
OworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9CisKIHN0YXRpYyB2b2lkIGlu
dGVsX21lbWVycl9kaGFuZGxlcigKICAgICAgICAgICAgICBzdHJ1Y3QgbWNhX2JpbmZvICpiaW5m
bywKICAgICAgICAgICAgICBlbnVtIG1jZV9yZXN1bHQgKnJlc3VsdCwKQEAgLTcxOCwxMSArNzQ0
LDggQEAKIAogICAgICAgICAgICAgICAgIC8qIFdlIHdpbGwgaW5qZWN0IHZNQ0UgdG8gRE9NVSov
CiAgICAgICAgICAgICAgICAgaWYgKCBpbmplY3Rfdm1jZShkKSA8IDAgKQotICAgICAgICAgICAg
ICAgIHsKLSAgICAgICAgICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJpbmplY3Qg
dk1DRSB0byBET00lZCIKLSAgICAgICAgICAgICAgICAgICAgICAiIGZhaWxlZFxuIiwgZC0+ZG9t
YWluX2lkKTsKICAgICAgICAgICAgICAgICAgICAgZ290byB2bWNlX2ZhaWxlZDsKLSAgICAgICAg
ICAgICAgICB9CisKICAgICAgICAgICAgICAgICAvKiBJbXBhY3RlZCBkb21haW4gZ28gb24gd2l0
aCBkb21haW4ncyByZWNvdmVyeSBqb2IKICAgICAgICAgICAgICAgICAgKiBpZiB0aGUgZG9tYWlu
IGhhcyBpdHMgb3duIE1DQSBoYW5kbGVyLgogICAgICAgICAgICAgICAgICAqIEZvciB4ZW4sIGl0
IGhhcyBjb250YWluZWQgdGhlIGVycm9yIGFuZCBmaW5pc2hlZApkaWZmIC1yIDE5YzE1ZjNkZmUx
ZiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9t
Y2hlY2svdm1jZS5jCVR1ZSBKdW4gMDUgMDM6MTg6MDAgMjAxMiArMDgwMAorKysgYi94ZW4vYXJj
aC94ODYvY3B1L21jaGVjay92bWNlLmMJV2VkIEp1biAxMyAyMzo0MDo0NSAyMDEyICswODAwCkBA
IC0zODksNTMgKzM4OSw2IEBACiBIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFZNQ0VfVkNQVSwg
dm1jZV9zYXZlX3ZjcHVfY3R4dCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1jZV9sb2Fk
X3ZjcHVfY3R4dCwgMSwgSFZNU1JfUEVSX1ZDUFUpOwogCi1pbnQgaW5qZWN0X3ZtY2Uoc3RydWN0
IGRvbWFpbiAqZCkKLXsKLSAgICBpbnQgY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgpOwotCi0gICAg
LyogUFYgZ3Vlc3QgYW5kIEhWTSBndWVzdCBoYXZlIGRpZmZlcmVudCB2TUNFIyBpbmplY3Rpb24g
bWV0aG9kcy4gKi8KLSAgICBpZiAoICF0ZXN0X2FuZF9zZXRfYm9vbChkLT52Y3B1WzBdLT5tY2Vf
cGVuZGluZykgKQotICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQotICAgICAgICB7Ci0g
ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qgdk1DRSB0byBI
Vk0gRE9NICVkXG4iLAotICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAg
ICAgICAgICAgdmNwdV9raWNrKGQtPnZjcHVbMF0pOwotICAgICAgICB9Ci0gICAgICAgIGVsc2UK
LSAgICAgICAgewotICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5q
ZWN0IHZNQ0UgdG8gUFYgRE9NJWRcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgIGQtPmRvbWFp
bl9pZCk7Ci0gICAgICAgICAgICBpZiAoIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQsIDAsIFRS
QVBfbWFjaGluZV9jaGVjaykgKQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAgIGNwdW1h
c2tfY29weShkLT52Y3B1WzBdLT5jcHVfYWZmaW5pdHlfdG1wLAotICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBkLT52Y3B1WzBdLT5jcHVfYWZmaW5pdHkpOwotICAgICAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IENQVSVkIHNldCBhZmZpbml0eSwgb2xkICVkXG4i
LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgY3B1LCBkLT52Y3B1WzBdLT5wcm9jZXNzb3Ip
OwotICAgICAgICAgICAgICAgIHZjcHVfc2V0X2FmZmluaXR5KGQtPnZjcHVbMF0sIGNwdW1hc2tf
b2YoY3B1KSk7Ci0gICAgICAgICAgICAgICAgdmNwdV9raWNrKGQtPnZjcHVbMF0pOwotICAgICAg
ICAgICAgfQotICAgICAgICAgICAgZWxzZQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAg
IG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNF
OiBLaWxsIFBWIGd1ZXN0IHdpdGggTm8gTUNFIGhhbmRsZXJcbiIpOwotICAgICAgICAgICAgICAg
IGRvbWFpbl9jcmFzaChkKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgfQotICAgIH0KLSAgICBl
bHNlCi0gICAgewotICAgICAgICAvKiBuZXcgdk1DRSBjb21lcyB3aGlsZSBmaXJzdCBvbmUgaGFz
IG5vdCBiZWVuIGluamVjdGVkIHlldCwKLSAgICAgICAgICogaW4gdGhpcyBjYXNlLCBpbmplY3Qg
ZmFpbC4gW1dlIGNhbid0IGxvc2UgdGhpcyB2TUNFIGZvcgotICAgICAgICAgKiB0aGUgbWNlIG5v
ZGUncyBjb25zaXN0ZW5jeV0uCi0gICAgICAgICAqLwotICAgICAgICBtY2VfcHJpbnRrKE1DRV9R
VUlFVCwgIlRoZXJlJ3MgYSBwZW5kaW5nIHZNQ0Ugd2FpdGluZyB0byBiZSBpbmplY3RlZCAiCi0g
ICAgICAgICAgICAgICAgICAgIiB0byB0aGlzIERPTSVkIVxuIiwgZC0+ZG9tYWluX2lkKTsKLSAg
ICAgICAgcmV0dXJuIC0xOwotICAgIH0KLSAgICByZXR1cm4gMDsKLX0KLQogLyogVGhpcyBub2Rl
IGxpc3QgcmVjb3JkcyBlcnJvcnMgaW1wYWN0aW5nIGEgZG9tYWluLiB3aGVuIG9uZQogICogTUNF
IyBoYXBwZW5zLCBvbmUgZXJyb3IgYmFuayBpbXBhY3RzIGEgZG9tYWluLiBUaGlzIGVycm9yIG5v
ZGUKICAqIHdpbGwgYmUgaW5zZXJ0ZWQgdG8gdGhlIHRhaWwgb2YgdGhlIHBlcl9kb20gZGF0YSBm
b3Igdk1DRSMgTVNSCg==

--_002_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233522B51CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Jun 13 08:12:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:12: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 1SeigG-0003iE-Hs; Wed, 13 Jun 2012 08:11: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 1SeigF-0003hx-0a
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:11:55 +0000
Received: from [85.158.139.83:30331] by server-7.bemta-5.messagelabs.com id
	F8/95-19648-94B48DF4; Wed, 13 Jun 2012 08:11:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339575113!26870414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11623 invoked from network); 13 Jun 2012 08:11:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:11:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12987663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:11:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:11:52 +0100
Message-ID: <1339575111.24104.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 13 Jun 2012 09:11:51 +0100
In-Reply-To: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-11 at 14:59 +0100, Zhigang Wang wrote:
> This patch removes the ownner support and fixed this issue per my test.

I think the changelog here needs to go into a bit more detail about why
it is correct to remove the owner support. e.g. why is it no longer
needed or why is it bogus. Also why does removing it fix the issue?
Please describe the logic behind the change not just its impact on your
test case.

> Kouya: would you please help to confirm this fix is correct?
> 
> Anyone has encountered this issue please help to test.
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> 
> diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
> @@ -48,32 +48,14 @@ sigerr() {
>  _claim_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(_lock_owner "$lockdir")
>    local retries=0
>  
>    while [ $retries -lt $LOCK_RETRIES ]
>    do
> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> -      _update_lock_info "$lockdir" && return
> -
> -    local new_owner=$(_lock_owner "$lockdir")
> -    if [ "$new_owner" != "$owner" ]
> -    then
> -      owner="$new_owner"
> -      retries=0
> -    else
> -      local pid=$(echo $owner | cut -d : -f 1)
> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> -      then
> -        _release_lock $lockdir
> -      fi
> -    fi
> -
> +    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
>      if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>      then
>        sleep $LOCK_SLEEPTIME
> -    else
> -      sleep 0
>      fi
>      retries=$(($retries + 1))
>    done
> @@ -91,20 +73,7 @@ _release_lock()
>  _steal_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> -  log err "Forced to steal lock on $lockdir from $owner!"
> +  log err "Forced to steal lock on $lockdir!"
>    _release_lock "$lockdir"
>    _claim_lock "$lockdir"
>  }
> -
> -
> -_lock_owner()
> -{
> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> -}
> -
> -
> -_update_lock_info()
> -{
> -  echo "$$: $0" >"$1/owner"
> -}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 13 08:12:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:12: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 1SeigG-0003iE-Hs; Wed, 13 Jun 2012 08:11: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 1SeigF-0003hx-0a
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:11:55 +0000
Received: from [85.158.139.83:30331] by server-7.bemta-5.messagelabs.com id
	F8/95-19648-94B48DF4; Wed, 13 Jun 2012 08:11:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339575113!26870414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11623 invoked from network); 13 Jun 2012 08:11:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:11:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12987663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:11:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:11:52 +0100
Message-ID: <1339575111.24104.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 13 Jun 2012 09:11:51 +0100
In-Reply-To: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-11 at 14:59 +0100, Zhigang Wang wrote:
> This patch removes the ownner support and fixed this issue per my test.

I think the changelog here needs to go into a bit more detail about why
it is correct to remove the owner support. e.g. why is it no longer
needed or why is it bogus. Also why does removing it fix the issue?
Please describe the logic behind the change not just its impact on your
test case.

> Kouya: would you please help to confirm this fix is correct?
> 
> Anyone has encountered this issue please help to test.
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> 
> diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
> @@ -48,32 +48,14 @@ sigerr() {
>  _claim_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(_lock_owner "$lockdir")
>    local retries=0
>  
>    while [ $retries -lt $LOCK_RETRIES ]
>    do
> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> -      _update_lock_info "$lockdir" && return
> -
> -    local new_owner=$(_lock_owner "$lockdir")
> -    if [ "$new_owner" != "$owner" ]
> -    then
> -      owner="$new_owner"
> -      retries=0
> -    else
> -      local pid=$(echo $owner | cut -d : -f 1)
> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> -      then
> -        _release_lock $lockdir
> -      fi
> -    fi
> -
> +    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
>      if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>      then
>        sleep $LOCK_SLEEPTIME
> -    else
> -      sleep 0
>      fi
>      retries=$(($retries + 1))
>    done
> @@ -91,20 +73,7 @@ _release_lock()
>  _steal_lock()
>  {
>    local lockdir="$1"
> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> -  log err "Forced to steal lock on $lockdir from $owner!"
> +  log err "Forced to steal lock on $lockdir!"
>    _release_lock "$lockdir"
>    _claim_lock "$lockdir"
>  }
> -
> -
> -_lock_owner()
> -{
> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> -}
> -
> -
> -_update_lock_info()
> -{
> -  echo "$$: $0" >"$1/owner"
> -}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 13 08:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08: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 1SeiiP-00041e-TE; Wed, 13 Jun 2012 08:14:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SeiiO-00041C-HN
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:14:08 +0000
Received: from [85.158.143.99:43498] by server-1.bemta-4.messagelabs.com id
	A6/6B-24392-FCB48DF4; Wed, 13 Jun 2012 08:14:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339575247!25058761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30913 invoked from network); 13 Jun 2012 08:14:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12987726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:14:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:14:07 +0100
Message-ID: <1339575245.24104.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 13 Jun 2012 09:14:05 +0100
In-Reply-To: <ea554d05821b95a7e96e.1339574505@probook.site>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 09:01 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339572293 -7200
> # Node ID ea554d05821b95a7e96e4a25cbf953c5abe35aeb
> # Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
> tools/configure.ac: add version check for glib2
> 
> xen-unstable fails to build in a SLES10SP4 environment since a long time
> because the included version of glib is slightly older than the required
> glib version. According to the docs glib version 2.12 includes base64
> support, but SLES10 is shipped with glib 2.8.6:
> 
> qemu-timer-common.o: In function `init_get_clock':
> /usr/src/packages/BUILD/xen-4.2.25432/non-dbg/tools/qemu-xen-dir/qemu-timer-common.c:57:
> undefined reference to `clock_gettime'
> qga/guest-agent-commands.o: In function `qmp_guest_file_write':
> qga/guest-agent-commands.c:249: undefined reference to `g_base64_decode'
> qga/guest-agent-commands.o: In function `qmp_guest_file_read':
> qga/guest-agent-commands.c:224: undefined reference to `g_base64_encode'
> collect2: ld returned 1 exit status
> make[3]: *** [qemu-ga] Error 1
> 
> Add a version check to configure to require at least glib 2.12 to build
> qemu-upstream.

Does this cause configure to fail or does it cause us to just not build
qemu-upstream? I think the former (which is fine with me) but your last
sentence suggests that latter.

> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r a70b35deb2b5 -r ea554d05821b tools/configure.ac
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -115,7 +115,7 @@ AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>  AX_PATH_PROG_OR_FAIL([IASL], [iasl])
>  AX_CHECK_UUID
>  AX_CHECK_CURSES
> -PKG_CHECK_MODULES(glib, glib-2.0)
> +PKG_CHECK_MODULES(glib, [glib-2.0 >= 2.12])
>  
>  # Check library path
>  AX_DEFAULT_LIB
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 13 08:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08: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 1SeiiP-00041e-TE; Wed, 13 Jun 2012 08:14:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SeiiO-00041C-HN
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:14:08 +0000
Received: from [85.158.143.99:43498] by server-1.bemta-4.messagelabs.com id
	A6/6B-24392-FCB48DF4; Wed, 13 Jun 2012 08:14:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339575247!25058761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30913 invoked from network); 13 Jun 2012 08:14:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12987726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:14:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:14:07 +0100
Message-ID: <1339575245.24104.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 13 Jun 2012 09:14:05 +0100
In-Reply-To: <ea554d05821b95a7e96e.1339574505@probook.site>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 09:01 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339572293 -7200
> # Node ID ea554d05821b95a7e96e4a25cbf953c5abe35aeb
> # Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
> tools/configure.ac: add version check for glib2
> 
> xen-unstable fails to build in a SLES10SP4 environment since a long time
> because the included version of glib is slightly older than the required
> glib version. According to the docs glib version 2.12 includes base64
> support, but SLES10 is shipped with glib 2.8.6:
> 
> qemu-timer-common.o: In function `init_get_clock':
> /usr/src/packages/BUILD/xen-4.2.25432/non-dbg/tools/qemu-xen-dir/qemu-timer-common.c:57:
> undefined reference to `clock_gettime'
> qga/guest-agent-commands.o: In function `qmp_guest_file_write':
> qga/guest-agent-commands.c:249: undefined reference to `g_base64_decode'
> qga/guest-agent-commands.o: In function `qmp_guest_file_read':
> qga/guest-agent-commands.c:224: undefined reference to `g_base64_encode'
> collect2: ld returned 1 exit status
> make[3]: *** [qemu-ga] Error 1
> 
> Add a version check to configure to require at least glib 2.12 to build
> qemu-upstream.

Does this cause configure to fail or does it cause us to just not build
qemu-upstream? I think the former (which is fine with me) but your last
sentence suggests that latter.

> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r a70b35deb2b5 -r ea554d05821b tools/configure.ac
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -115,7 +115,7 @@ AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>  AX_PATH_PROG_OR_FAIL([IASL], [iasl])
>  AX_CHECK_UUID
>  AX_CHECK_CURSES
> -PKG_CHECK_MODULES(glib, glib-2.0)
> +PKG_CHECK_MODULES(glib, [glib-2.0 >= 2.12])
>  
>  # Check library path
>  AX_DEFAULT_LIB
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 13 08:17:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeilL-0004NN-G7; Wed, 13 Jun 2012 08:17:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SeilK-0004N6-F2
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:17:10 +0000
Received: from [193.109.254.147:49102] by server-3.bemta-14.messagelabs.com id
	72/FF-05653-58C48DF4; Wed, 13 Jun 2012 08:17:09 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339575427!8651287!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4NjYzOA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31056 invoked from network); 13 Jun 2012 08:17:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:17:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5D8H1fb016257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 08:17:02 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
	q5D8H0bA028321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 08:17:00 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
	q5D8GxlI011048; Wed, 13 Jun 2012 03:16:59 -0500
Received: from localhost.localdomain (/10.159.216.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 01:16:59 -0700
Message-ID: <4FD84C79.1000707@oracle.com>
Date: Wed, 13 Jun 2012 04:16:57 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
	<1339575111.24104.125.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339575111.24104.125.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/13/2012 04:11 AM, Ian Campbell wrote:
> On Mon, 2012-06-11 at 14:59 +0100, Zhigang Wang wrote:
>> This patch removes the ownner support and fixed this issue per my test.
> I think the changelog here needs to go into a bit more detail about why
> it is correct to remove the owner support. e.g. why is it no longer
> needed or why is it bogus. Also why does removing it fix the issue?
> Please describe the logic behind the change not just its impact on your
> test case.
Thanks Kouya for the info about Red Hat implement. I also like the flock
implement better.

My plan is to withdraw this patch and test Red Hat implement and if it works
fine, then I will submit the Red Hat patch (as far as it's GPL).

Thanks,

Zhigang
>
>> Kouya: would you please help to confirm this fix is correct?
>>
>> Anyone has encountered this issue please help to test.
>>
>> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
>> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
>>
>> diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
>> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
>> +++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
>> @@ -48,32 +48,14 @@ sigerr() {
>>  _claim_lock()
>>  {
>>    local lockdir="$1"
>> -  local owner=$(_lock_owner "$lockdir")
>>    local retries=0
>>  
>>    while [ $retries -lt $LOCK_RETRIES ]
>>    do
>> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
>> -      _update_lock_info "$lockdir" && return
>> -
>> -    local new_owner=$(_lock_owner "$lockdir")
>> -    if [ "$new_owner" != "$owner" ]
>> -    then
>> -      owner="$new_owner"
>> -      retries=0
>> -    else
>> -      local pid=$(echo $owner | cut -d : -f 1)
>> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
>> -      then
>> -        _release_lock $lockdir
>> -      fi
>> -    fi
>> -
>> +    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
>>      if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>>      then
>>        sleep $LOCK_SLEEPTIME
>> -    else
>> -      sleep 0
>>      fi
>>      retries=$(($retries + 1))
>>    done
>> @@ -91,20 +73,7 @@ _release_lock()
>>  _steal_lock()
>>  {
>>    local lockdir="$1"
>> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
>> -  log err "Forced to steal lock on $lockdir from $owner!"
>> +  log err "Forced to steal lock on $lockdir!"
>>    _release_lock "$lockdir"
>>    _claim_lock "$lockdir"
>>  }
>> -
>> -
>> -_lock_owner()
>> -{
>> -  cat "$1/owner" 2>/dev/null || echo "unknown"
>> -}
>> -
>> -
>> -_update_lock_info()
>> -{
>> -  echo "$$: $0" >"$1/owner"
>> -}
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Jun 13 08:17:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeilL-0004NN-G7; Wed, 13 Jun 2012 08:17:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SeilK-0004N6-F2
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:17:10 +0000
Received: from [193.109.254.147:49102] by server-3.bemta-14.messagelabs.com id
	72/FF-05653-58C48DF4; Wed, 13 Jun 2012 08:17:09 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339575427!8651287!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4NjYzOA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31056 invoked from network); 13 Jun 2012 08:17:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 08:17:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5D8H1fb016257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 08:17:02 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
	q5D8H0bA028321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 08:17:00 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
	q5D8GxlI011048; Wed, 13 Jun 2012 03:16:59 -0500
Received: from localhost.localdomain (/10.159.216.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 01:16:59 -0700
Message-ID: <4FD84C79.1000707@oracle.com>
Date: Wed, 13 Jun 2012 04:16:57 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
References: <eb72d7090b5956490b2f.1339423172@zhigang.us.oracle.com>
	<1339575111.24104.125.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339575111.24104.125.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/13/2012 04:11 AM, Ian Campbell wrote:
> On Mon, 2012-06-11 at 14:59 +0100, Zhigang Wang wrote:
>> This patch removes the ownner support and fixed this issue per my test.
> I think the changelog here needs to go into a bit more detail about why
> it is correct to remove the owner support. e.g. why is it no longer
> needed or why is it bogus. Also why does removing it fix the issue?
> Please describe the logic behind the change not just its impact on your
> test case.
Thanks Kouya for the info about Red Hat implement. I also like the flock
implement better.

My plan is to withdraw this patch and test Red Hat implement and if it works
fine, then I will submit the Red Hat patch (as far as it's GPL).

Thanks,

Zhigang
>
>> Kouya: would you please help to confirm this fix is correct?
>>
>> Anyone has encountered this issue please help to test.
>>
>> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
>> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
>>
>> diff -r 32034d1914a6 -r eb72d7090b59 tools/hotplug/Linux/locking.sh
>> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
>> +++ b/tools/hotplug/Linux/locking.sh	Mon Jun 11 09:29:43 2012 -0400
>> @@ -48,32 +48,14 @@ sigerr() {
>>  _claim_lock()
>>  {
>>    local lockdir="$1"
>> -  local owner=$(_lock_owner "$lockdir")
>>    local retries=0
>>  
>>    while [ $retries -lt $LOCK_RETRIES ]
>>    do
>> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
>> -      _update_lock_info "$lockdir" && return
>> -
>> -    local new_owner=$(_lock_owner "$lockdir")
>> -    if [ "$new_owner" != "$owner" ]
>> -    then
>> -      owner="$new_owner"
>> -      retries=0
>> -    else
>> -      local pid=$(echo $owner | cut -d : -f 1)
>> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
>> -      then
>> -        _release_lock $lockdir
>> -      fi
>> -    fi
>> -
>> +    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR && return
>>      if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>>      then
>>        sleep $LOCK_SLEEPTIME
>> -    else
>> -      sleep 0
>>      fi
>>      retries=$(($retries + 1))
>>    done
>> @@ -91,20 +73,7 @@ _release_lock()
>>  _steal_lock()
>>  {
>>    local lockdir="$1"
>> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
>> -  log err "Forced to steal lock on $lockdir from $owner!"
>> +  log err "Forced to steal lock on $lockdir!"
>>    _release_lock "$lockdir"
>>    _claim_lock "$lockdir"
>>  }
>> -
>> -
>> -_lock_owner()
>> -{
>> -  cat "$1/owner" 2>/dev/null || echo "unknown"
>> -}
>> -
>> -
>> -_update_lock_info()
>> -{
>> -  echo "$$: $0" >"$1/owner"
>> -}
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Jun 13 08:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejK9-0006DZ-8Z; Wed, 13 Jun 2012 08:53:09 +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 1SejK6-0006DU-R4
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:53:07 +0000
Received: from [85.158.138.51:24781] by server-11.bemta-3.messagelabs.com id
	94/67-28329-2F458DF4; Wed, 13 Jun 2012 08:53:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339577585!18465366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17173 invoked from network); 13 Jun 2012 08:53:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 08:53:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 09:53:04 +0100
Message-Id: <4FD8713B0200007800089A77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 09:53:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Xen vMCE bugfix: inject vMCE# to all vcpus
> 
> In our test for win8 guest mce, we find a bug in that no matter what 
> SRAO/SRAR
> error xen inject to win8 guest, it always reboot.
> 
> The root cause is, current Xen vMCE logic inject vMCE# only to vcpu0, this 
> is
> not correct for Intel MCE (Under Intel arch, h/w generate MCE# to all CPUs).
> 
> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.

I see no correlation between the fix (and its description) and the
problem at hand: Why would Win8 reboot if it doesn't receive a
particular MCE on all CPUs? Isn't that model specific behavior?

Furthermore I doubt that an MCE on one socket indeed causes
MCE-s on all other sockets, not to speak of distinct NUMA nodes
(it would already surprise me if MCE-s got broadcast across cores
within a socket, unless they are caused by a resource shared
across cores).

> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Jun 05 03:18:00 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Jun 13 23:40:45 2012 +0800
> @@ -638,6 +638,32 @@
>      return rec;
>  }
>  
> +static int inject_vmce(struct domain *d)

Is it really necessary to move this vendor independent function
into a vendor specific source file?

> +{
> +    struct vcpu *v;
> +
> +    /* inject vMCE to all vcpus */
> +    for_each_vcpu(d, v)
> +    {
> +        if ( !test_and_set_bool(v->mce_pending) &&
> +            ((d->is_hvm) ? 1 :
> +            guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) )

Quite strange a way to say

            (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check))

> +        {
> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d vcpu%d\n",
> +                       d->domain_id, v->vcpu_id);
> +            vcpu_kick(v);
> +        }
> +        else
> +        {
> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
> +                       d->domain_id, v->vcpu_id);
> +            return -1;

Why do you bail here? This is particularly bad if v->mce_pending
was already set on some vCPU (as that could simply mean the guest
just didn't get around to handle the vMCE yet).

> +        }
> +    }
> +
> +    return 0;
> +}
> +
>  static void intel_memerr_dhandler(
>               struct mca_binfo *binfo,
>               enum mce_result *result,

Also, how does this whole change interact with vmce_{rd,wr}msr()?
The struct bank_entry instances live on a per-domain list, so the
vMCE being delivered to all vCPU-s means they will all race for the
single entry (and might erroneously access others, particularly in
vmce_wrmsr()'s MCG_STATUS handling).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejK9-0006DZ-8Z; Wed, 13 Jun 2012 08:53:09 +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 1SejK6-0006DU-R4
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:53:07 +0000
Received: from [85.158.138.51:24781] by server-11.bemta-3.messagelabs.com id
	94/67-28329-2F458DF4; Wed, 13 Jun 2012 08:53:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339577585!18465366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17173 invoked from network); 13 Jun 2012 08:53:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 08:53:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 09:53:04 +0100
Message-Id: <4FD8713B0200007800089A77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 09:53:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Xen vMCE bugfix: inject vMCE# to all vcpus
> 
> In our test for win8 guest mce, we find a bug in that no matter what 
> SRAO/SRAR
> error xen inject to win8 guest, it always reboot.
> 
> The root cause is, current Xen vMCE logic inject vMCE# only to vcpu0, this 
> is
> not correct for Intel MCE (Under Intel arch, h/w generate MCE# to all CPUs).
> 
> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.

I see no correlation between the fix (and its description) and the
problem at hand: Why would Win8 reboot if it doesn't receive a
particular MCE on all CPUs? Isn't that model specific behavior?

Furthermore I doubt that an MCE on one socket indeed causes
MCE-s on all other sockets, not to speak of distinct NUMA nodes
(it would already surprise me if MCE-s got broadcast across cores
within a socket, unless they are caused by a resource shared
across cores).

> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Jun 05 03:18:00 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Jun 13 23:40:45 2012 +0800
> @@ -638,6 +638,32 @@
>      return rec;
>  }
>  
> +static int inject_vmce(struct domain *d)

Is it really necessary to move this vendor independent function
into a vendor specific source file?

> +{
> +    struct vcpu *v;
> +
> +    /* inject vMCE to all vcpus */
> +    for_each_vcpu(d, v)
> +    {
> +        if ( !test_and_set_bool(v->mce_pending) &&
> +            ((d->is_hvm) ? 1 :
> +            guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) )

Quite strange a way to say

            (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check))

> +        {
> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d vcpu%d\n",
> +                       d->domain_id, v->vcpu_id);
> +            vcpu_kick(v);
> +        }
> +        else
> +        {
> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
> +                       d->domain_id, v->vcpu_id);
> +            return -1;

Why do you bail here? This is particularly bad if v->mce_pending
was already set on some vCPU (as that could simply mean the guest
just didn't get around to handle the vMCE yet).

> +        }
> +    }
> +
> +    return 0;
> +}
> +
>  static void intel_memerr_dhandler(
>               struct mca_binfo *binfo,
>               enum mce_result *result,

Also, how does this whole change interact with vmce_{rd,wr}msr()?
The struct bank_entry instances live on a per-domain list, so the
vMCE being delivered to all vCPU-s means they will all race for the
single entry (and might erroneously access others, particularly in
vmce_wrmsr()'s MCG_STATUS handling).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejO1-0006Km-Tq; Wed, 13 Jun 2012 08:57:09 +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 1SejO1-0006Kd-1s
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:57:09 +0000
Received: from [85.158.138.51:58605] by server-5.bemta-3.messagelabs.com id
	C0/08-03598-4E558DF4; Wed, 13 Jun 2012 08:57:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339577827!21026585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20298 invoked from network); 13 Jun 2012 08:57:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988849"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:56:52 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 09:56:52 +0100
Message-ID: <4FD855D7.8070501@citrix.com>
Date: Wed, 13 Jun 2012 09:56:55 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339575245.24104.127.camel@zakaz.uk.xensource.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFdlZCwgMjAxMi0wNi0xMyBhdCAwOTowMSArMDEwMCwg
T2xhZiBIZXJpbmcgd3JvdGU6Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBPbGFm
IEhlcmluZzxvbGFmQGFlcGZsZS5kZT4KPj4gIyBEYXRlIDEzMzk1NzIyOTMgLTcyMDAKPj4gIyBO
b2RlIElEIGVhNTU0ZDA1ODIxYjk1YTdlOTZlNGEyNWNiZjk1M2M1YWJlMzVhZWIKPj4gIyBQYXJl
bnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIxYmIyYzcwNDk4ODUKPj4gdG9vbHMvY29u
ZmlndXJlLmFjOiBhZGQgdmVyc2lvbiBjaGVjayBmb3IgZ2xpYjIKPj4KPj4geGVuLXVuc3RhYmxl
IGZhaWxzIHRvIGJ1aWxkIGluIGEgU0xFUzEwU1A0IGVudmlyb25tZW50IHNpbmNlIGEgbG9uZyB0
aW1lCj4+IGJlY2F1c2UgdGhlIGluY2x1ZGVkIHZlcnNpb24gb2YgZ2xpYiBpcyBzbGlnaHRseSBv
bGRlciB0aGFuIHRoZSByZXF1aXJlZAo+PiBnbGliIHZlcnNpb24uIEFjY29yZGluZyB0byB0aGUg
ZG9jcyBnbGliIHZlcnNpb24gMi4xMiBpbmNsdWRlcyBiYXNlNjQKPj4gc3VwcG9ydCwgYnV0IFNM
RVMxMCBpcyBzaGlwcGVkIHdpdGggZ2xpYiAyLjguNjoKPj4KPj4gcWVtdS10aW1lci1jb21tb24u
bzogSW4gZnVuY3Rpb24gYGluaXRfZ2V0X2Nsb2NrJzoKPj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJ
TEQveGVuLTQuMi4yNTQzMi9ub24tZGJnL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLWNv
bW1vbi5jOjU3Ogo+PiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjbG9ja19nZXR0aW1lJwo+PiBx
Z2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMubzogSW4gZnVuY3Rpb24gYHFtcF9ndWVzdF9maWxlX3dy
aXRlJzoKPj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6MjQ5OiB1bmRlZmluZWQgcmVmZXJl
bmNlIHRvIGBnX2Jhc2U2NF9kZWNvZGUnCj4+IHFnYS9ndWVzdC1hZ2VudC1jb21tYW5kcy5vOiBJ
biBmdW5jdGlvbiBgcW1wX2d1ZXN0X2ZpbGVfcmVhZCc6Cj4+IHFnYS9ndWVzdC1hZ2VudC1jb21t
YW5kcy5jOjIyNDogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ19iYXNlNjRfZW5jb2RlJwo+PiBj
b2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+PiBtYWtlWzNdOiAqKiogW3FlbXUt
Z2FdIEVycm9yIDEKPj4KPj4gQWRkIGEgdmVyc2lvbiBjaGVjayB0byBjb25maWd1cmUgdG8gcmVx
dWlyZSBhdCBsZWFzdCBnbGliIDIuMTIgdG8gYnVpbGQKPj4gcWVtdS11cHN0cmVhbS4KPgo+IERv
ZXMgdGhpcyBjYXVzZSBjb25maWd1cmUgdG8gZmFpbCBvciBkb2VzIGl0IGNhdXNlIHVzIHRvIGp1
c3Qgbm90IGJ1aWxkCj4gcWVtdS11cHN0cmVhbT8gSSB0aGluayB0aGUgZm9ybWVyICh3aGljaCBp
cyBmaW5lIHdpdGggbWUpIGJ1dCB5b3VyIGxhc3QKPiBzZW50ZW5jZSBzdWdnZXN0cyB0aGF0IGxh
dHRlci4KCiBGcm9tIG15IHVuZGVyc3RhbmRpbmcgaXQgY2F1c2VzIFFlbXUgYnVpbGQgdG8gZmFp
bCwgc2luY2Ugb3VyIHZlcnNpb24gCm9mIFFlbXUgY29uZmlndXJlIHNjcmlwdCBkb2Vzbid0IGNo
ZWNrIGZvciBnbGliIHZlcnNpb24uCgpUaGUgZm9sbG93aW5nIGNvbW1pdCBzaG91bGQgYmUgYmFj
a3BvcnRlZCB0byBvdXIgUWVtdSB0cmVlIGFsc28gCmE1MmQyOGFmYjRlODI1YTViMjg4MTUzNzBh
MjY4OTA0YTRjNmRjMTEuCgo+PiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZzxvbGFmQGFlcGZs
ZS5kZT4KCkFueXdheSwgc2luY2Ugd2UgY2hlY2sgZm9yIGdsaWIgYWxyZWFkeSwgSSB0aGluayB0
aGlzIHNob3VsZCBiZSBhcHBsaWVkLCAKc28gYXQgbGVhc3Qgd2UgY2hlY2sgZm9yIHRoZSByZXF1
aXJlZCB2ZXJzaW9uCgpBY2tlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+CgpQbGVhc2UgcmVydW4gYXV0b2NvbmYgYWZ0ZXIgYXBwbHlpbmcgdGhpcy4KCj4+Cj4+
IGRpZmYgLXIgYTcwYjM1ZGViMmI1IC1yIGVhNTU0ZDA1ODIxYiB0b29scy9jb25maWd1cmUuYWMK
Pj4gLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCj4+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwo+
PiBAQCAtMTE1LDcgKzExNSw3IEBAIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtCQ0NdLCBbYmNjXSkK
Pj4gICBBWF9QQVRIX1BST0dfT1JfRkFJTChbSUFTTF0sIFtpYXNsXSkKPj4gICBBWF9DSEVDS19V
VUlECj4+ICAgQVhfQ0hFQ0tfQ1VSU0VTCj4+IC1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGli
LTIuMCkKPj4gK1BLR19DSEVDS19NT0RVTEVTKGdsaWIsIFtnbGliLTIuMD49IDIuMTJdKQo+Pgo+
PiAgICMgQ2hlY2sgbGlicmFyeSBwYXRoCj4+ICAgQVhfREVGQVVMVF9MSUIKPj4KPj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1h
aWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+PiBodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwKPgo+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9y
ZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejO1-0006Km-Tq; Wed, 13 Jun 2012 08:57:09 +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 1SejO1-0006Kd-1s
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:57:09 +0000
Received: from [85.158.138.51:58605] by server-5.bemta-3.messagelabs.com id
	C0/08-03598-4E558DF4; Wed, 13 Jun 2012 08:57:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339577827!21026585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20298 invoked from network); 13 Jun 2012 08:57:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988849"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:56:52 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 09:56:52 +0100
Message-ID: <4FD855D7.8070501@citrix.com>
Date: Wed, 13 Jun 2012 09:56:55 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339575245.24104.127.camel@zakaz.uk.xensource.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFdlZCwgMjAxMi0wNi0xMyBhdCAwOTowMSArMDEwMCwg
T2xhZiBIZXJpbmcgd3JvdGU6Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBPbGFm
IEhlcmluZzxvbGFmQGFlcGZsZS5kZT4KPj4gIyBEYXRlIDEzMzk1NzIyOTMgLTcyMDAKPj4gIyBO
b2RlIElEIGVhNTU0ZDA1ODIxYjk1YTdlOTZlNGEyNWNiZjk1M2M1YWJlMzVhZWIKPj4gIyBQYXJl
bnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIxYmIyYzcwNDk4ODUKPj4gdG9vbHMvY29u
ZmlndXJlLmFjOiBhZGQgdmVyc2lvbiBjaGVjayBmb3IgZ2xpYjIKPj4KPj4geGVuLXVuc3RhYmxl
IGZhaWxzIHRvIGJ1aWxkIGluIGEgU0xFUzEwU1A0IGVudmlyb25tZW50IHNpbmNlIGEgbG9uZyB0
aW1lCj4+IGJlY2F1c2UgdGhlIGluY2x1ZGVkIHZlcnNpb24gb2YgZ2xpYiBpcyBzbGlnaHRseSBv
bGRlciB0aGFuIHRoZSByZXF1aXJlZAo+PiBnbGliIHZlcnNpb24uIEFjY29yZGluZyB0byB0aGUg
ZG9jcyBnbGliIHZlcnNpb24gMi4xMiBpbmNsdWRlcyBiYXNlNjQKPj4gc3VwcG9ydCwgYnV0IFNM
RVMxMCBpcyBzaGlwcGVkIHdpdGggZ2xpYiAyLjguNjoKPj4KPj4gcWVtdS10aW1lci1jb21tb24u
bzogSW4gZnVuY3Rpb24gYGluaXRfZ2V0X2Nsb2NrJzoKPj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJ
TEQveGVuLTQuMi4yNTQzMi9ub24tZGJnL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLWNv
bW1vbi5jOjU3Ogo+PiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjbG9ja19nZXR0aW1lJwo+PiBx
Z2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMubzogSW4gZnVuY3Rpb24gYHFtcF9ndWVzdF9maWxlX3dy
aXRlJzoKPj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6MjQ5OiB1bmRlZmluZWQgcmVmZXJl
bmNlIHRvIGBnX2Jhc2U2NF9kZWNvZGUnCj4+IHFnYS9ndWVzdC1hZ2VudC1jb21tYW5kcy5vOiBJ
biBmdW5jdGlvbiBgcW1wX2d1ZXN0X2ZpbGVfcmVhZCc6Cj4+IHFnYS9ndWVzdC1hZ2VudC1jb21t
YW5kcy5jOjIyNDogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ19iYXNlNjRfZW5jb2RlJwo+PiBj
b2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+PiBtYWtlWzNdOiAqKiogW3FlbXUt
Z2FdIEVycm9yIDEKPj4KPj4gQWRkIGEgdmVyc2lvbiBjaGVjayB0byBjb25maWd1cmUgdG8gcmVx
dWlyZSBhdCBsZWFzdCBnbGliIDIuMTIgdG8gYnVpbGQKPj4gcWVtdS11cHN0cmVhbS4KPgo+IERv
ZXMgdGhpcyBjYXVzZSBjb25maWd1cmUgdG8gZmFpbCBvciBkb2VzIGl0IGNhdXNlIHVzIHRvIGp1
c3Qgbm90IGJ1aWxkCj4gcWVtdS11cHN0cmVhbT8gSSB0aGluayB0aGUgZm9ybWVyICh3aGljaCBp
cyBmaW5lIHdpdGggbWUpIGJ1dCB5b3VyIGxhc3QKPiBzZW50ZW5jZSBzdWdnZXN0cyB0aGF0IGxh
dHRlci4KCiBGcm9tIG15IHVuZGVyc3RhbmRpbmcgaXQgY2F1c2VzIFFlbXUgYnVpbGQgdG8gZmFp
bCwgc2luY2Ugb3VyIHZlcnNpb24gCm9mIFFlbXUgY29uZmlndXJlIHNjcmlwdCBkb2Vzbid0IGNo
ZWNrIGZvciBnbGliIHZlcnNpb24uCgpUaGUgZm9sbG93aW5nIGNvbW1pdCBzaG91bGQgYmUgYmFj
a3BvcnRlZCB0byBvdXIgUWVtdSB0cmVlIGFsc28gCmE1MmQyOGFmYjRlODI1YTViMjg4MTUzNzBh
MjY4OTA0YTRjNmRjMTEuCgo+PiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZzxvbGFmQGFlcGZs
ZS5kZT4KCkFueXdheSwgc2luY2Ugd2UgY2hlY2sgZm9yIGdsaWIgYWxyZWFkeSwgSSB0aGluayB0
aGlzIHNob3VsZCBiZSBhcHBsaWVkLCAKc28gYXQgbGVhc3Qgd2UgY2hlY2sgZm9yIHRoZSByZXF1
aXJlZCB2ZXJzaW9uCgpBY2tlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+CgpQbGVhc2UgcmVydW4gYXV0b2NvbmYgYWZ0ZXIgYXBwbHlpbmcgdGhpcy4KCj4+Cj4+
IGRpZmYgLXIgYTcwYjM1ZGViMmI1IC1yIGVhNTU0ZDA1ODIxYiB0b29scy9jb25maWd1cmUuYWMK
Pj4gLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCj4+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwo+
PiBAQCAtMTE1LDcgKzExNSw3IEBAIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtCQ0NdLCBbYmNjXSkK
Pj4gICBBWF9QQVRIX1BST0dfT1JfRkFJTChbSUFTTF0sIFtpYXNsXSkKPj4gICBBWF9DSEVDS19V
VUlECj4+ICAgQVhfQ0hFQ0tfQ1VSU0VTCj4+IC1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGli
LTIuMCkKPj4gK1BLR19DSEVDS19NT0RVTEVTKGdsaWIsIFtnbGliLTIuMD49IDIuMTJdKQo+Pgo+
PiAgICMgQ2hlY2sgbGlicmFyeSBwYXRoCj4+ICAgQVhfREVGQVVMVF9MSUIKPj4KPj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1h
aWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+PiBodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwKPgo+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9y
ZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:58:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejPO-0006PT-D5; Wed, 13 Jun 2012 08:58: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 1SejPM-0006PI-Tu
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:58:33 +0000
Received: from [85.158.143.99:12198] by server-1.bemta-4.messagelabs.com id
	37/32-24392-83658DF4; Wed, 13 Jun 2012 08:58:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339577911!32580510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18720 invoked from network); 13 Jun 2012 08:58:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:58:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:58:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:58:31 +0100
Message-ID: <1339577910.24104.148.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 13 Jun 2012 09:58:30 +0100
In-Reply-To: <4FD855D7.8070501@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
	<4FD855D7.8070501@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTEzIGF0IDA5OjU2ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gV2VkLCAyMDEyLTA2LTEzIGF0IDA5OjAxICsw
MTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMg
VXNlciBPbGFmIEhlcmluZzxvbGFmQGFlcGZsZS5kZT4KPiA+PiAjIERhdGUgMTMzOTU3MjI5MyAt
NzIwMAo+ID4+ICMgTm9kZSBJRCBlYTU1NGQwNTgyMWI5NWE3ZTk2ZTRhMjVjYmY5NTNjNWFiZTM1
YWViCj4gPj4gIyBQYXJlbnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIxYmIyYzcwNDk4
ODUKPiA+PiB0b29scy9jb25maWd1cmUuYWM6IGFkZCB2ZXJzaW9uIGNoZWNrIGZvciBnbGliMgo+
ID4+Cj4gPj4geGVuLXVuc3RhYmxlIGZhaWxzIHRvIGJ1aWxkIGluIGEgU0xFUzEwU1A0IGVudmly
b25tZW50IHNpbmNlIGEgbG9uZyB0aW1lCj4gPj4gYmVjYXVzZSB0aGUgaW5jbHVkZWQgdmVyc2lv
biBvZiBnbGliIGlzIHNsaWdodGx5IG9sZGVyIHRoYW4gdGhlIHJlcXVpcmVkCj4gPj4gZ2xpYiB2
ZXJzaW9uLiBBY2NvcmRpbmcgdG8gdGhlIGRvY3MgZ2xpYiB2ZXJzaW9uIDIuMTIgaW5jbHVkZXMg
YmFzZTY0Cj4gPj4gc3VwcG9ydCwgYnV0IFNMRVMxMCBpcyBzaGlwcGVkIHdpdGggZ2xpYiAyLjgu
NjoKPiA+Pgo+ID4+IHFlbXUtdGltZXItY29tbW9uLm86IEluIGZ1bmN0aW9uIGBpbml0X2dldF9j
bG9jayc6Cj4gPj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJTEQveGVuLTQuMi4yNTQzMi9ub24tZGJn
L3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLWNvbW1vbi5jOjU3Ogo+ID4+IHVuZGVmaW5l
ZCByZWZlcmVuY2UgdG8gYGNsb2NrX2dldHRpbWUnCj4gPj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1h
bmRzLm86IEluIGZ1bmN0aW9uIGBxbXBfZ3Vlc3RfZmlsZV93cml0ZSc6Cj4gPj4gcWdhL2d1ZXN0
LWFnZW50LWNvbW1hbmRzLmM6MjQ5OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9k
ZWNvZGUnCj4gPj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0aW9uIGBxbXBf
Z3Vlc3RfZmlsZV9yZWFkJzoKPiA+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyMjQ6IHVu
ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdfYmFzZTY0X2VuY29kZScKPiA+PiBjb2xsZWN0MjogbGQg
cmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+ID4+IG1ha2VbM106ICoqKiBbcWVtdS1nYV0gRXJyb3Ig
MQo+ID4+Cj4gPj4gQWRkIGEgdmVyc2lvbiBjaGVjayB0byBjb25maWd1cmUgdG8gcmVxdWlyZSBh
dCBsZWFzdCBnbGliIDIuMTIgdG8gYnVpbGQKPiA+PiBxZW11LXVwc3RyZWFtLgo+ID4KPiA+IERv
ZXMgdGhpcyBjYXVzZSBjb25maWd1cmUgdG8gZmFpbCBvciBkb2VzIGl0IGNhdXNlIHVzIHRvIGp1
c3Qgbm90IGJ1aWxkCj4gPiBxZW11LXVwc3RyZWFtPyBJIHRoaW5rIHRoZSBmb3JtZXIgKHdoaWNo
IGlzIGZpbmUgd2l0aCBtZSkgYnV0IHlvdXIgbGFzdAo+ID4gc2VudGVuY2Ugc3VnZ2VzdHMgdGhh
dCBsYXR0ZXIuCj4gCj4gIEZyb20gbXkgdW5kZXJzdGFuZGluZyBpdCBjYXVzZXMgUWVtdSBidWls
ZCB0byBmYWlsLCBzaW5jZSBvdXIgdmVyc2lvbiAKPiBvZiBRZW11IGNvbmZpZ3VyZSBzY3JpcHQg
ZG9lc24ndCBjaGVjayBmb3IgZ2xpYiB2ZXJzaW9uLgoKQnV0IHRoaXMgcGF0Y2ggbWFrZXMgaXQg
ZG8gdGhhdCBjaGVjaywgcmlnaHQ/Cgo+IAo+IFRoZSBmb2xsb3dpbmcgY29tbWl0IHNob3VsZCBi
ZSBiYWNrcG9ydGVkIHRvIG91ciBRZW11IHRyZWUgYWxzbyAKPiBhNTJkMjhhZmI0ZTgyNWE1YjI4
ODE1MzcwYTI2ODkwNGE0YzZkYzExLgo+IAo+ID4+IFNpZ25lZC1vZmYtYnk6IE9sYWYgSGVyaW5n
PG9sYWZAYWVwZmxlLmRlPgo+IAo+IEFueXdheSwgc2luY2Ugd2UgY2hlY2sgZm9yIGdsaWIgYWxy
ZWFkeSwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBhcHBsaWVkLCAKPiBzbyBhdCBsZWFzdCB3ZSBj
aGVjayBmb3IgdGhlIHJlcXVpcmVkIHZlcnNpb24KPiAKPiBBY2tlZC1ieTogUm9nZXIgUGF1IE1v
bm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gCj4gUGxlYXNlIHJlcnVuIGF1dG9jb25mIGFm
dGVyIGFwcGx5aW5nIHRoaXMuCj4gCj4gPj4KPiA+PiBkaWZmIC1yIGE3MGIzNWRlYjJiNSAtciBl
YTU1NGQwNTgyMWIgdG9vbHMvY29uZmlndXJlLmFjCj4gPj4gLS0tIGEvdG9vbHMvY29uZmlndXJl
LmFjCj4gPj4gKysrIGIvdG9vbHMvY29uZmlndXJlLmFjCj4gPj4gQEAgLTExNSw3ICsxMTUsNyBA
QCBBWF9QQVRIX1BST0dfT1JfRkFJTChbQkNDXSwgW2JjY10pCj4gPj4gICBBWF9QQVRIX1BST0df
T1JfRkFJTChbSUFTTF0sIFtpYXNsXSkKPiA+PiAgIEFYX0NIRUNLX1VVSUQKPiA+PiAgIEFYX0NI
RUNLX0NVUlNFUwo+ID4+IC1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKPiA+PiAr
UEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwgW2dsaWItMi4wPj0gMi4xMl0pCj4gPj4KPiA+PiAgICMg
Q2hlY2sgbGlicmFyeSBwYXRoCj4gPj4gICBBWF9ERUZBVUxUX0xJQgo+ID4+Cj4gPj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+PiBYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Cj4gPj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiA+PiBodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwKPiA+Cj4gPgo+IAoKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 13 08:58:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 08:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejPO-0006PT-D5; Wed, 13 Jun 2012 08:58: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 1SejPM-0006PI-Tu
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:58:33 +0000
Received: from [85.158.143.99:12198] by server-1.bemta-4.messagelabs.com id
	37/32-24392-83658DF4; Wed, 13 Jun 2012 08:58:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339577911!32580510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18720 invoked from network); 13 Jun 2012 08:58:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:58:31 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:58:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:58:31 +0100
Message-ID: <1339577910.24104.148.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 13 Jun 2012 09:58:30 +0100
In-Reply-To: <4FD855D7.8070501@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
	<4FD855D7.8070501@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTEzIGF0IDA5OjU2ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gV2VkLCAyMDEyLTA2LTEzIGF0IDA5OjAxICsw
MTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMg
VXNlciBPbGFmIEhlcmluZzxvbGFmQGFlcGZsZS5kZT4KPiA+PiAjIERhdGUgMTMzOTU3MjI5MyAt
NzIwMAo+ID4+ICMgTm9kZSBJRCBlYTU1NGQwNTgyMWI5NWE3ZTk2ZTRhMjVjYmY5NTNjNWFiZTM1
YWViCj4gPj4gIyBQYXJlbnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIxYmIyYzcwNDk4
ODUKPiA+PiB0b29scy9jb25maWd1cmUuYWM6IGFkZCB2ZXJzaW9uIGNoZWNrIGZvciBnbGliMgo+
ID4+Cj4gPj4geGVuLXVuc3RhYmxlIGZhaWxzIHRvIGJ1aWxkIGluIGEgU0xFUzEwU1A0IGVudmly
b25tZW50IHNpbmNlIGEgbG9uZyB0aW1lCj4gPj4gYmVjYXVzZSB0aGUgaW5jbHVkZWQgdmVyc2lv
biBvZiBnbGliIGlzIHNsaWdodGx5IG9sZGVyIHRoYW4gdGhlIHJlcXVpcmVkCj4gPj4gZ2xpYiB2
ZXJzaW9uLiBBY2NvcmRpbmcgdG8gdGhlIGRvY3MgZ2xpYiB2ZXJzaW9uIDIuMTIgaW5jbHVkZXMg
YmFzZTY0Cj4gPj4gc3VwcG9ydCwgYnV0IFNMRVMxMCBpcyBzaGlwcGVkIHdpdGggZ2xpYiAyLjgu
NjoKPiA+Pgo+ID4+IHFlbXUtdGltZXItY29tbW9uLm86IEluIGZ1bmN0aW9uIGBpbml0X2dldF9j
bG9jayc6Cj4gPj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJTEQveGVuLTQuMi4yNTQzMi9ub24tZGJn
L3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLWNvbW1vbi5jOjU3Ogo+ID4+IHVuZGVmaW5l
ZCByZWZlcmVuY2UgdG8gYGNsb2NrX2dldHRpbWUnCj4gPj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1h
bmRzLm86IEluIGZ1bmN0aW9uIGBxbXBfZ3Vlc3RfZmlsZV93cml0ZSc6Cj4gPj4gcWdhL2d1ZXN0
LWFnZW50LWNvbW1hbmRzLmM6MjQ5OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9k
ZWNvZGUnCj4gPj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0aW9uIGBxbXBf
Z3Vlc3RfZmlsZV9yZWFkJzoKPiA+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyMjQ6IHVu
ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdfYmFzZTY0X2VuY29kZScKPiA+PiBjb2xsZWN0MjogbGQg
cmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+ID4+IG1ha2VbM106ICoqKiBbcWVtdS1nYV0gRXJyb3Ig
MQo+ID4+Cj4gPj4gQWRkIGEgdmVyc2lvbiBjaGVjayB0byBjb25maWd1cmUgdG8gcmVxdWlyZSBh
dCBsZWFzdCBnbGliIDIuMTIgdG8gYnVpbGQKPiA+PiBxZW11LXVwc3RyZWFtLgo+ID4KPiA+IERv
ZXMgdGhpcyBjYXVzZSBjb25maWd1cmUgdG8gZmFpbCBvciBkb2VzIGl0IGNhdXNlIHVzIHRvIGp1
c3Qgbm90IGJ1aWxkCj4gPiBxZW11LXVwc3RyZWFtPyBJIHRoaW5rIHRoZSBmb3JtZXIgKHdoaWNo
IGlzIGZpbmUgd2l0aCBtZSkgYnV0IHlvdXIgbGFzdAo+ID4gc2VudGVuY2Ugc3VnZ2VzdHMgdGhh
dCBsYXR0ZXIuCj4gCj4gIEZyb20gbXkgdW5kZXJzdGFuZGluZyBpdCBjYXVzZXMgUWVtdSBidWls
ZCB0byBmYWlsLCBzaW5jZSBvdXIgdmVyc2lvbiAKPiBvZiBRZW11IGNvbmZpZ3VyZSBzY3JpcHQg
ZG9lc24ndCBjaGVjayBmb3IgZ2xpYiB2ZXJzaW9uLgoKQnV0IHRoaXMgcGF0Y2ggbWFrZXMgaXQg
ZG8gdGhhdCBjaGVjaywgcmlnaHQ/Cgo+IAo+IFRoZSBmb2xsb3dpbmcgY29tbWl0IHNob3VsZCBi
ZSBiYWNrcG9ydGVkIHRvIG91ciBRZW11IHRyZWUgYWxzbyAKPiBhNTJkMjhhZmI0ZTgyNWE1YjI4
ODE1MzcwYTI2ODkwNGE0YzZkYzExLgo+IAo+ID4+IFNpZ25lZC1vZmYtYnk6IE9sYWYgSGVyaW5n
PG9sYWZAYWVwZmxlLmRlPgo+IAo+IEFueXdheSwgc2luY2Ugd2UgY2hlY2sgZm9yIGdsaWIgYWxy
ZWFkeSwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBhcHBsaWVkLCAKPiBzbyBhdCBsZWFzdCB3ZSBj
aGVjayBmb3IgdGhlIHJlcXVpcmVkIHZlcnNpb24KPiAKPiBBY2tlZC1ieTogUm9nZXIgUGF1IE1v
bm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gCj4gUGxlYXNlIHJlcnVuIGF1dG9jb25mIGFm
dGVyIGFwcGx5aW5nIHRoaXMuCj4gCj4gPj4KPiA+PiBkaWZmIC1yIGE3MGIzNWRlYjJiNSAtciBl
YTU1NGQwNTgyMWIgdG9vbHMvY29uZmlndXJlLmFjCj4gPj4gLS0tIGEvdG9vbHMvY29uZmlndXJl
LmFjCj4gPj4gKysrIGIvdG9vbHMvY29uZmlndXJlLmFjCj4gPj4gQEAgLTExNSw3ICsxMTUsNyBA
QCBBWF9QQVRIX1BST0dfT1JfRkFJTChbQkNDXSwgW2JjY10pCj4gPj4gICBBWF9QQVRIX1BST0df
T1JfRkFJTChbSUFTTF0sIFtpYXNsXSkKPiA+PiAgIEFYX0NIRUNLX1VVSUQKPiA+PiAgIEFYX0NI
RUNLX0NVUlNFUwo+ID4+IC1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKPiA+PiAr
UEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwgW2dsaWItMi4wPj0gMi4xMl0pCj4gPj4KPiA+PiAgICMg
Q2hlY2sgbGlicmFyeSBwYXRoCj4gPj4gICBBWF9ERUZBVUxUX0xJQgo+ID4+Cj4gPj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+PiBYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Cj4gPj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiA+PiBodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwKPiA+Cj4gPgo+IAoKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejQb-0006VL-Sy; Wed, 13 Jun 2012 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 <roger.pau@citrix.com>) id 1SejQZ-0006V4-Lo
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:59:47 +0000
Received: from [85.158.138.51:4600] by server-8.bemta-3.messagelabs.com id
	33/A4-22118-28658DF4; Wed, 13 Jun 2012 08:59:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339577978!8689114!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15073 invoked from network); 13 Jun 2012 08:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988925"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:59:28 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 09:59:27 +0100
Message-ID: <4FD85672.60108@citrix.com>
Date: Wed, 13 Jun 2012 09:59:30 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <patchbomb.1339574504@probook.site>
	<306676f2c25b58e2cc09.1339574507@probook.site>
In-Reply-To: <306676f2c25b58e2cc09.1339574507@probook.site>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill
	PACKAGE_TARNAME in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Hering wrote:
> # HG changeset patch
> # User Olaf Hering<olaf@aepfle.de>
> # Date 1339574441 -7200
> # Node ID 306676f2c25b58e2cc094017f53910cb0c9ea9a9
> # Parent  57679d60e43077004757aede949e41b5e297e028
> tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
>
> Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
> preserve the currently used path, which ends with /xen, specify a value
> for PACKAGE_TARNAME. Without this change the path would end with
> /xen-hypervisor.
>
> Signed-off-by: Olaf Hering<olaf@aepfle.de>
>
> diff -r 57679d60e430 -r 306676f2c25b tools/configure.ac
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -3,7 +3,7 @@
>
>   AC_PREREQ([2.67])
>   AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
> -    [xen-devel@lists.xensource.com])
> +    [xen-devel@lists.xensource.com], [xen], [http://www.xen.org/])

Since you already change the line, could you also change the ML address 
to xen@lists.xen.org?

>   AC_CONFIG_SRCDIR([libxl/libxl.c])
>   AC_CONFIG_FILES([../config/Tools.mk])
>   AC_CONFIG_HEADERS([config.h])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejQb-0006VL-Sy; Wed, 13 Jun 2012 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 <roger.pau@citrix.com>) id 1SejQZ-0006V4-Lo
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 08:59:47 +0000
Received: from [85.158.138.51:4600] by server-8.bemta-3.messagelabs.com id
	33/A4-22118-28658DF4; Wed, 13 Jun 2012 08:59:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339577978!8689114!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15073 invoked from network); 13 Jun 2012 08:59:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988925"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:59:28 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 09:59:27 +0100
Message-ID: <4FD85672.60108@citrix.com>
Date: Wed, 13 Jun 2012 09:59:30 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <patchbomb.1339574504@probook.site>
	<306676f2c25b58e2cc09.1339574507@probook.site>
In-Reply-To: <306676f2c25b58e2cc09.1339574507@probook.site>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill
	PACKAGE_TARNAME in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Hering wrote:
> # HG changeset patch
> # User Olaf Hering<olaf@aepfle.de>
> # Date 1339574441 -7200
> # Node ID 306676f2c25b58e2cc094017f53910cb0c9ea9a9
> # Parent  57679d60e43077004757aede949e41b5e297e028
> tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
>
> Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
> preserve the currently used path, which ends with /xen, specify a value
> for PACKAGE_TARNAME. Without this change the path would end with
> /xen-hypervisor.
>
> Signed-off-by: Olaf Hering<olaf@aepfle.de>
>
> diff -r 57679d60e430 -r 306676f2c25b tools/configure.ac
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -3,7 +3,7 @@
>
>   AC_PREREQ([2.67])
>   AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
> -    [xen-devel@lists.xensource.com])
> +    [xen-devel@lists.xensource.com], [xen], [http://www.xen.org/])

Since you already change the line, could you also change the ML address 
to xen@lists.xen.org?

>   AC_CONFIG_SRCDIR([libxl/libxl.c])
>   AC_CONFIG_FILES([../config/Tools.mk])
>   AC_CONFIG_HEADERS([config.h])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejQe-0006Vi-9P; Wed, 13 Jun 2012 08:59:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SejQd-0006VK-C0
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:59:51 +0000
Received: from [193.109.254.147:42641] by server-9.bemta-14.messagelabs.com id
	2F/A6-27072-58658DF4; Wed, 13 Jun 2012 08:59:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339577988!9555707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8306 invoked from network); 13 Jun 2012 08:59:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:59:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:59:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:59:48 +0100
Message-ID: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 09:59:46 +0100
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> This is v3 of my series to asyncify save/restore, rebased to current
> tip, retested, and with all comments addressed.

There's quite a lot of combinations which need testing here (PV, HVM,
HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?

I tried a simple localhost migrate of a PV guest and:
        # xl -vvv migrate d32-1 localhost
        migration target: Ready to receive domain.
        Saving to migration stream new xl format (info 0x0/0x0/3541)
        libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x8069720: create: how=(nil) callback=(nil) poller=0x80696c8
        Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/3541)
         Savefile contains xl domain config
        libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=2 toolstack data size=8
        libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x8069720: inprogress: poller=0x80696c8, flags=i
        libxl-save-helper: debug: starting save: Success
        xc: detail: Had 0 unexplained entries in p2m table
        xc: Saving memory: iter 0 (last sent 0 skipped 0): 0/131072    0%
        
at which point it appears to just stop.

        # strace -p 2872 # /usr/lib/xen/bin/libxl-save-helper --save-domain 8 2 0 0 1 0 0 12 8 72
        Process 2872 attached - interrupt to quit
        write(8, 0xb5d31000, 1974272^C <unfinished ...>
        Process 2872 detached
        # strace -p 2866 # /usr/lib/xen/bin/libxl-save-helper --restore-domain 0 3 1 0 2 0 0 1 0 0 0
        Process 2866 attached - interrupt to quit
        read(0, ^C <unfinished ...>
        # strace -p 4070 # xl -vvv migrate d32-1 localhost
        Process 4070 attached - interrupt to quit
        restart_syscall(<... resuming interrupted call ...>
        # strace -p 4074 # xl migrate-receive
        Process 4074 attached - interrupt to quit
        restart_syscall(<... resuming interrupted call ...>

So the saver seems to be blocked writing to fd 8, which is argv[1] == io_fd.

Also FWIW:
        # xl list
        Name                                        ID   Mem VCPUs	State	Time(s)
        Domain-0                                     0   511     4     r-----      24.5
        d32-1                                        2   128     4     -b----       0.4
        d32-1--incoming                              3     0     0     --p---       0.0

/var/log/xen/xl-d32-1.log is just "Waiting for domain d32-1 (domid 9) to
die [pid 4045]" (nb: this was a newer attempt than the ones above, to be
sure I was looking at the right log, so the domid's don't match, 9 ==
d32-1 not the incoming one). There is no xl log for the incoming domain.

Also it'd be worth pinging/CCing Shriram next time to get him to sanity
test the Remus cases too.

I'm in the middle of reviewing #5/19 (the meat), I'll keep going
although I doubt I'll spot the cause of this...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:00:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SejQe-0006Vi-9P; Wed, 13 Jun 2012 08:59:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SejQd-0006VK-C0
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 08:59:51 +0000
Received: from [193.109.254.147:42641] by server-9.bemta-14.messagelabs.com id
	2F/A6-27072-58658DF4; Wed, 13 Jun 2012 08:59:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1339577988!9555707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8306 invoked from network); 13 Jun 2012 08:59:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 08:59:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:59:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 09:59:48 +0100
Message-ID: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 09:59:46 +0100
In-Reply-To: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> This is v3 of my series to asyncify save/restore, rebased to current
> tip, retested, and with all comments addressed.

There's quite a lot of combinations which need testing here (PV, HVM,
HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?

I tried a simple localhost migrate of a PV guest and:
        # xl -vvv migrate d32-1 localhost
        migration target: Ready to receive domain.
        Saving to migration stream new xl format (info 0x0/0x0/3541)
        libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x8069720: create: how=(nil) callback=(nil) poller=0x80696c8
        Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/3541)
         Savefile contains xl domain config
        libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=2 toolstack data size=8
        libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x8069720: inprogress: poller=0x80696c8, flags=i
        libxl-save-helper: debug: starting save: Success
        xc: detail: Had 0 unexplained entries in p2m table
        xc: Saving memory: iter 0 (last sent 0 skipped 0): 0/131072    0%
        
at which point it appears to just stop.

        # strace -p 2872 # /usr/lib/xen/bin/libxl-save-helper --save-domain 8 2 0 0 1 0 0 12 8 72
        Process 2872 attached - interrupt to quit
        write(8, 0xb5d31000, 1974272^C <unfinished ...>
        Process 2872 detached
        # strace -p 2866 # /usr/lib/xen/bin/libxl-save-helper --restore-domain 0 3 1 0 2 0 0 1 0 0 0
        Process 2866 attached - interrupt to quit
        read(0, ^C <unfinished ...>
        # strace -p 4070 # xl -vvv migrate d32-1 localhost
        Process 4070 attached - interrupt to quit
        restart_syscall(<... resuming interrupted call ...>
        # strace -p 4074 # xl migrate-receive
        Process 4074 attached - interrupt to quit
        restart_syscall(<... resuming interrupted call ...>

So the saver seems to be blocked writing to fd 8, which is argv[1] == io_fd.

Also FWIW:
        # xl list
        Name                                        ID   Mem VCPUs	State	Time(s)
        Domain-0                                     0   511     4     r-----      24.5
        d32-1                                        2   128     4     -b----       0.4
        d32-1--incoming                              3     0     0     --p---       0.0

/var/log/xen/xl-d32-1.log is just "Waiting for domain d32-1 (domid 9) to
die [pid 4045]" (nb: this was a newer attempt than the ones above, to be
sure I was looking at the right log, so the domid's don't match, 9 ==
d32-1 not the incoming one). There is no xl log for the incoming domain.

Also it'd be worth pinging/CCing Shriram next time to get him to sanity
test the Remus cases too.

I'm in the middle of reviewing #5/19 (the meat), I'll keep going
although I doubt I'll spot the cause of this...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09: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 1SejSo-0006pa-0C; Wed, 13 Jun 2012 09:02:06 +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 1SejSm-0006pD-OL
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:02:04 +0000
Received: from [85.158.138.51:42994] by server-4.bemta-3.messagelabs.com id
	DC/58-13598-B0758DF4; Wed, 13 Jun 2012 09:02:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339578123!27427987!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18736 invoked from network); 13 Jun 2012 09:02:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:02:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 09:01:41 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 10:01:40 +0100
Message-ID: <4FD856F7.7040201@citrix.com>
Date: Wed, 13 Jun 2012 10:01:43 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
	<4FD855D7.8070501@citrix.com>
	<1339577910.24104.148.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339577910.24104.148.camel@zakaz.uk.xensource.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFdlZCwgMjAxMi0wNi0xMyBhdCAwOTo1NiArMDEwMCwg
Um9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4+PiBPbiBXZWQs
IDIwMTItMDYtMTMgYXQgMDk6MDEgKzAxMDAsIE9sYWYgSGVyaW5nIHdyb3RlOgo+Pj4+ICMgSEcg
Y2hhbmdlc2V0IHBhdGNoCj4+Pj4gIyBVc2VyIE9sYWYgSGVyaW5nPG9sYWZAYWVwZmxlLmRlPgo+
Pj4+ICMgRGF0ZSAxMzM5NTcyMjkzIC03MjAwCj4+Pj4gIyBOb2RlIElEIGVhNTU0ZDA1ODIxYjk1
YTdlOTZlNGEyNWNiZjk1M2M1YWJlMzVhZWIKPj4+PiAjIFBhcmVudCAgYTcwYjM1ZGViMmI1NTky
Y2MxYjIzNjM4NjBmMjFiYjJjNzA0OTg4NQo+Pj4+IHRvb2xzL2NvbmZpZ3VyZS5hYzogYWRkIHZl
cnNpb24gY2hlY2sgZm9yIGdsaWIyCj4+Pj4KPj4+PiB4ZW4tdW5zdGFibGUgZmFpbHMgdG8gYnVp
bGQgaW4gYSBTTEVTMTBTUDQgZW52aXJvbm1lbnQgc2luY2UgYSBsb25nIHRpbWUKPj4+PiBiZWNh
dXNlIHRoZSBpbmNsdWRlZCB2ZXJzaW9uIG9mIGdsaWIgaXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0
aGUgcmVxdWlyZWQKPj4+PiBnbGliIHZlcnNpb24uIEFjY29yZGluZyB0byB0aGUgZG9jcyBnbGli
IHZlcnNpb24gMi4xMiBpbmNsdWRlcyBiYXNlNjQKPj4+PiBzdXBwb3J0LCBidXQgU0xFUzEwIGlz
IHNoaXBwZWQgd2l0aCBnbGliIDIuOC42Ogo+Pj4+Cj4+Pj4gcWVtdS10aW1lci1jb21tb24ubzog
SW4gZnVuY3Rpb24gYGluaXRfZ2V0X2Nsb2NrJzoKPj4+PiAvdXNyL3NyYy9wYWNrYWdlcy9CVUlM
RC94ZW4tNC4yLjI1NDMyL25vbi1kYmcvdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXItY29t
bW9uLmM6NTc6Cj4+Pj4gdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgY2xvY2tfZ2V0dGltZScKPj4+
PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMubzogSW4gZnVuY3Rpb24gYHFtcF9ndWVzdF9maWxl
X3dyaXRlJzoKPj4+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyNDk6IHVuZGVmaW5lZCBy
ZWZlcmVuY2UgdG8gYGdfYmFzZTY0X2RlY29kZScKPj4+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFu
ZHMubzogSW4gZnVuY3Rpb24gYHFtcF9ndWVzdF9maWxlX3JlYWQnOgo+Pj4+IHFnYS9ndWVzdC1h
Z2VudC1jb21tYW5kcy5jOjIyNDogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ19iYXNlNjRfZW5j
b2RlJwo+Pj4+IGNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4+Pj4gbWFrZVsz
XTogKioqIFtxZW11LWdhXSBFcnJvciAxCj4+Pj4KPj4+PiBBZGQgYSB2ZXJzaW9uIGNoZWNrIHRv
IGNvbmZpZ3VyZSB0byByZXF1aXJlIGF0IGxlYXN0IGdsaWIgMi4xMiB0byBidWlsZAo+Pj4+IHFl
bXUtdXBzdHJlYW0uCj4+PiBEb2VzIHRoaXMgY2F1c2UgY29uZmlndXJlIHRvIGZhaWwgb3IgZG9l
cyBpdCBjYXVzZSB1cyB0byBqdXN0IG5vdCBidWlsZAo+Pj4gcWVtdS11cHN0cmVhbT8gSSB0aGlu
ayB0aGUgZm9ybWVyICh3aGljaCBpcyBmaW5lIHdpdGggbWUpIGJ1dCB5b3VyIGxhc3QKPj4+IHNl
bnRlbmNlIHN1Z2dlc3RzIHRoYXQgbGF0dGVyLgo+PiAgICBGcm9tIG15IHVuZGVyc3RhbmRpbmcg
aXQgY2F1c2VzIFFlbXUgYnVpbGQgdG8gZmFpbCwgc2luY2Ugb3VyIHZlcnNpb24KPj4gb2YgUWVt
dSBjb25maWd1cmUgc2NyaXB0IGRvZXNuJ3QgY2hlY2sgZm9yIGdsaWIgdmVyc2lvbi4KPgo+IEJ1
dCB0aGlzIHBhdGNoIG1ha2VzIGl0IGRvIHRoYXQgY2hlY2ssIHJpZ2h0PwoKWWVzLCB3ZSBjdXJy
ZW50bHkgY2hlY2sgZm9yIGdsaWIsIGJ1dCB3ZSBkb24ndCByZXF1aXJlIGFueSBzcGVjaWZpYyAK
dmVyc2lvbi4gVGhpcyBwYXRjaCBzZXRzIHRoZSBuZWNlc3NhcnkgZ2xpYiB2ZXJzaW9uIGZvciBR
ZW11LXVwc3RyZWFtIApjb21waWxhdGlvbiB0byBzdWNjZWVkIGFzIGEgcmVxdWlyZW1lbnQgZm9y
IG91ciBjb25maWd1cmUgc2NyaXB0LgoKPgo+PiBUaGUgZm9sbG93aW5nIGNvbW1pdCBzaG91bGQg
YmUgYmFja3BvcnRlZCB0byBvdXIgUWVtdSB0cmVlIGFsc28KPj4gYTUyZDI4YWZiNGU4MjVhNWIy
ODgxNTM3MGEyNjg5MDRhNGM2ZGMxMS4KPj4KPj4+PiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmlu
ZzxvbGFmQGFlcGZsZS5kZT4KPj4gQW55d2F5LCBzaW5jZSB3ZSBjaGVjayBmb3IgZ2xpYiBhbHJl
YWR5LCBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGFwcGxpZWQsCj4+IHNvIGF0IGxlYXN0IHdlIGNo
ZWNrIGZvciB0aGUgcmVxdWlyZWQgdmVyc2lvbgo+Pgo+PiBBY2tlZC1ieTogUm9nZXIgUGF1IE1v
bm7DqTxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4KPj4gUGxlYXNlIHJlcnVuIGF1dG9jb25mIGFm
dGVyIGFwcGx5aW5nIHRoaXMuCj4+Cj4+Pj4gZGlmZiAtciBhNzBiMzVkZWIyYjUgLXIgZWE1NTRk
MDU4MjFiIHRvb2xzL2NvbmZpZ3VyZS5hYwo+Pj4+IC0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYwo+
Pj4+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwo+Pj4+IEBAIC0xMTUsNyArMTE1LDcgQEAgQVhf
UEFUSF9QUk9HX09SX0ZBSUwoW0JDQ10sIFtiY2NdKQo+Pj4+ICAgIEFYX1BBVEhfUFJPR19PUl9G
QUlMKFtJQVNMXSwgW2lhc2xdKQo+Pj4+ICAgIEFYX0NIRUNLX1VVSUQKPj4+PiAgICBBWF9DSEVD
S19DVVJTRVMKPj4+PiAtUEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwgZ2xpYi0yLjApCj4+Pj4gK1BL
R19DSEVDS19NT0RVTEVTKGdsaWIsIFtnbGliLTIuMD49IDIuMTJdKQo+Pj4+Cj4+Pj4gICAgIyBD
aGVjayBsaWJyYXJ5IHBhdGgKPj4+PiAgICBBWF9ERUZBVUxUX0xJQgo+Pj4+Cj4+Pj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+PiBYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Cj4+Pj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPj4+PiBodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwKPj4+Cj4KPgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09: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 1SejSo-0006pa-0C; Wed, 13 Jun 2012 09:02:06 +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 1SejSm-0006pD-OL
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:02:04 +0000
Received: from [85.158.138.51:42994] by server-4.bemta-3.messagelabs.com id
	DC/58-13598-B0758DF4; Wed, 13 Jun 2012 09:02:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339578123!27427987!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18736 invoked from network); 13 Jun 2012 09:02:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:02:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12988989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 09:01:41 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 10:01:40 +0100
Message-ID: <4FD856F7.7040201@citrix.com>
Date: Wed, 13 Jun 2012 10:01:43 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
	<4FD855D7.8070501@citrix.com>
	<1339577910.24104.148.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339577910.24104.148.camel@zakaz.uk.xensource.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFdlZCwgMjAxMi0wNi0xMyBhdCAwOTo1NiArMDEwMCwg
Um9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4+PiBPbiBXZWQs
IDIwMTItMDYtMTMgYXQgMDk6MDEgKzAxMDAsIE9sYWYgSGVyaW5nIHdyb3RlOgo+Pj4+ICMgSEcg
Y2hhbmdlc2V0IHBhdGNoCj4+Pj4gIyBVc2VyIE9sYWYgSGVyaW5nPG9sYWZAYWVwZmxlLmRlPgo+
Pj4+ICMgRGF0ZSAxMzM5NTcyMjkzIC03MjAwCj4+Pj4gIyBOb2RlIElEIGVhNTU0ZDA1ODIxYjk1
YTdlOTZlNGEyNWNiZjk1M2M1YWJlMzVhZWIKPj4+PiAjIFBhcmVudCAgYTcwYjM1ZGViMmI1NTky
Y2MxYjIzNjM4NjBmMjFiYjJjNzA0OTg4NQo+Pj4+IHRvb2xzL2NvbmZpZ3VyZS5hYzogYWRkIHZl
cnNpb24gY2hlY2sgZm9yIGdsaWIyCj4+Pj4KPj4+PiB4ZW4tdW5zdGFibGUgZmFpbHMgdG8gYnVp
bGQgaW4gYSBTTEVTMTBTUDQgZW52aXJvbm1lbnQgc2luY2UgYSBsb25nIHRpbWUKPj4+PiBiZWNh
dXNlIHRoZSBpbmNsdWRlZCB2ZXJzaW9uIG9mIGdsaWIgaXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0
aGUgcmVxdWlyZWQKPj4+PiBnbGliIHZlcnNpb24uIEFjY29yZGluZyB0byB0aGUgZG9jcyBnbGli
IHZlcnNpb24gMi4xMiBpbmNsdWRlcyBiYXNlNjQKPj4+PiBzdXBwb3J0LCBidXQgU0xFUzEwIGlz
IHNoaXBwZWQgd2l0aCBnbGliIDIuOC42Ogo+Pj4+Cj4+Pj4gcWVtdS10aW1lci1jb21tb24ubzog
SW4gZnVuY3Rpb24gYGluaXRfZ2V0X2Nsb2NrJzoKPj4+PiAvdXNyL3NyYy9wYWNrYWdlcy9CVUlM
RC94ZW4tNC4yLjI1NDMyL25vbi1kYmcvdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXItY29t
bW9uLmM6NTc6Cj4+Pj4gdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgY2xvY2tfZ2V0dGltZScKPj4+
PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMubzogSW4gZnVuY3Rpb24gYHFtcF9ndWVzdF9maWxl
X3dyaXRlJzoKPj4+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyNDk6IHVuZGVmaW5lZCBy
ZWZlcmVuY2UgdG8gYGdfYmFzZTY0X2RlY29kZScKPj4+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFu
ZHMubzogSW4gZnVuY3Rpb24gYHFtcF9ndWVzdF9maWxlX3JlYWQnOgo+Pj4+IHFnYS9ndWVzdC1h
Z2VudC1jb21tYW5kcy5jOjIyNDogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ19iYXNlNjRfZW5j
b2RlJwo+Pj4+IGNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4+Pj4gbWFrZVsz
XTogKioqIFtxZW11LWdhXSBFcnJvciAxCj4+Pj4KPj4+PiBBZGQgYSB2ZXJzaW9uIGNoZWNrIHRv
IGNvbmZpZ3VyZSB0byByZXF1aXJlIGF0IGxlYXN0IGdsaWIgMi4xMiB0byBidWlsZAo+Pj4+IHFl
bXUtdXBzdHJlYW0uCj4+PiBEb2VzIHRoaXMgY2F1c2UgY29uZmlndXJlIHRvIGZhaWwgb3IgZG9l
cyBpdCBjYXVzZSB1cyB0byBqdXN0IG5vdCBidWlsZAo+Pj4gcWVtdS11cHN0cmVhbT8gSSB0aGlu
ayB0aGUgZm9ybWVyICh3aGljaCBpcyBmaW5lIHdpdGggbWUpIGJ1dCB5b3VyIGxhc3QKPj4+IHNl
bnRlbmNlIHN1Z2dlc3RzIHRoYXQgbGF0dGVyLgo+PiAgICBGcm9tIG15IHVuZGVyc3RhbmRpbmcg
aXQgY2F1c2VzIFFlbXUgYnVpbGQgdG8gZmFpbCwgc2luY2Ugb3VyIHZlcnNpb24KPj4gb2YgUWVt
dSBjb25maWd1cmUgc2NyaXB0IGRvZXNuJ3QgY2hlY2sgZm9yIGdsaWIgdmVyc2lvbi4KPgo+IEJ1
dCB0aGlzIHBhdGNoIG1ha2VzIGl0IGRvIHRoYXQgY2hlY2ssIHJpZ2h0PwoKWWVzLCB3ZSBjdXJy
ZW50bHkgY2hlY2sgZm9yIGdsaWIsIGJ1dCB3ZSBkb24ndCByZXF1aXJlIGFueSBzcGVjaWZpYyAK
dmVyc2lvbi4gVGhpcyBwYXRjaCBzZXRzIHRoZSBuZWNlc3NhcnkgZ2xpYiB2ZXJzaW9uIGZvciBR
ZW11LXVwc3RyZWFtIApjb21waWxhdGlvbiB0byBzdWNjZWVkIGFzIGEgcmVxdWlyZW1lbnQgZm9y
IG91ciBjb25maWd1cmUgc2NyaXB0LgoKPgo+PiBUaGUgZm9sbG93aW5nIGNvbW1pdCBzaG91bGQg
YmUgYmFja3BvcnRlZCB0byBvdXIgUWVtdSB0cmVlIGFsc28KPj4gYTUyZDI4YWZiNGU4MjVhNWIy
ODgxNTM3MGEyNjg5MDRhNGM2ZGMxMS4KPj4KPj4+PiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmlu
ZzxvbGFmQGFlcGZsZS5kZT4KPj4gQW55d2F5LCBzaW5jZSB3ZSBjaGVjayBmb3IgZ2xpYiBhbHJl
YWR5LCBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGFwcGxpZWQsCj4+IHNvIGF0IGxlYXN0IHdlIGNo
ZWNrIGZvciB0aGUgcmVxdWlyZWQgdmVyc2lvbgo+Pgo+PiBBY2tlZC1ieTogUm9nZXIgUGF1IE1v
bm7DqTxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4KPj4gUGxlYXNlIHJlcnVuIGF1dG9jb25mIGFm
dGVyIGFwcGx5aW5nIHRoaXMuCj4+Cj4+Pj4gZGlmZiAtciBhNzBiMzVkZWIyYjUgLXIgZWE1NTRk
MDU4MjFiIHRvb2xzL2NvbmZpZ3VyZS5hYwo+Pj4+IC0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYwo+
Pj4+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwo+Pj4+IEBAIC0xMTUsNyArMTE1LDcgQEAgQVhf
UEFUSF9QUk9HX09SX0ZBSUwoW0JDQ10sIFtiY2NdKQo+Pj4+ICAgIEFYX1BBVEhfUFJPR19PUl9G
QUlMKFtJQVNMXSwgW2lhc2xdKQo+Pj4+ICAgIEFYX0NIRUNLX1VVSUQKPj4+PiAgICBBWF9DSEVD
S19DVVJTRVMKPj4+PiAtUEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwgZ2xpYi0yLjApCj4+Pj4gK1BL
R19DSEVDS19NT0RVTEVTKGdsaWIsIFtnbGliLTIuMD49IDIuMTJdKQo+Pj4+Cj4+Pj4gICAgIyBD
aGVjayBsaWJyYXJ5IHBhdGgKPj4+PiAgICBBWF9ERUZBVUxUX0xJQgo+Pj4+Cj4+Pj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+PiBYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Cj4+Pj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPj4+PiBodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwKPj4+Cj4KPgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:02:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:02: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 1SejSu-0006qQ-Da; Wed, 13 Jun 2012 09:02:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SejSs-0006q3-0I
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:02:10 +0000
Received: from [85.158.139.83:19044] by server-10.bemta-5.messagelabs.com id
	65/AB-23803-11758DF4; Wed, 13 Jun 2012 09:02:09 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339578127!16156571!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23658 invoked from network); 13 Jun 2012 09:02:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:02:08 -0000
Received: by yenq11 with SMTP id q11so401570yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 02:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=ss4lz/OtryjgNRTUfB7cpbUn51QaOEIBNivj1GKw/Js=;
	b=Lq7MmAUCrR8rcaH9fzwpG1G4Qk6lcZCjbvMbPvtVCK5fSg1kgCTkeQ903oSixKHKu6
	hXTtj/bXhmQA1Gd4OK6dEZV3ptYln7aufiil8doaJ1/lPZsn4TVqE7MgMwAHieG3/QPo
	3r3c+5yA/8nrt1NzJCJedD1SaVzDDuzdd+PtUZdOSduydxkFvmXoQ3a2LJA8zgSaU4iV
	zPdVmUrx+Kd2BvyiUFKhrbGISYHb8wleowqcVmq76if0Z5dZT4upM3pbElAQxE0uhkkA
	jBAS5FEZ0y2rdS2E11GC9cBhzkWsyacLz1BHoJ9GUejhjd1b/cERFR+AoJS7mYXRCI4W
	H7tA==
MIME-Version: 1.0
Received: by 10.60.169.174 with SMTP id af14mr23652982oec.13.1339578126845;
	Wed, 13 Jun 2012 02:02:06 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 13 Jun 2012 02:02:06 -0700 (PDT)
In-Reply-To: <4FD5DCF7.2070103@tiscali.it>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
Date: Wed, 13 Jun 2012 17:02:06 +0800
Message-ID: <CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: fantonifabio@tiscali.it
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni <fantonifabio@tiscali.it> wr=
ote:
> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>
>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> =A0wrote:
>>>
>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>
>>>> Sorry for late reply, I am not on this mail these days because of my
>>>> work.
>>>>
>>>> I further test qxl-vga and I think I figure out the problem in some
>>>> extend.
>>>>
>>>> If using qxl device, the default memory size of vga is 64M.
>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>
>>>> The exact reason is xc_domain_populate_physmap_exact fails, because
>>>> xen-hypervisor
>>>> fail,
>>>> it's because of =A0 alloc_domheap_pages(d, a->extent_order, a->memflag=
s)
>>>> fails in hypervisor.
>>>>
>>>> I am not very familiar with xen's memory management, Does 64M exceed
>>>> xen's heap space in this context?
>>>
>>> XL sets an upper bound of memory that can be allocated to the VM in
>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>> My guess is that a 64MB allocation would go over that limit.
>>> You could try increasing the limit manually changing the
>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
>>> videoram=3D64 in the VM config file.
>>
>> Your guess is absolutely right!
>>
>> But set videoram=3D128 or
>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>
>> Then I successfuly install qxl driver in win-hvm and QXL can work
>> properly.
>>
>> I will send some patch to add qxl support to libxl.
>
> I tried your 3 patches taken from the mailing list, it works but doesn't
> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg doesn't
> start and on windows 7 I have heavy performance problem (unusable).

Could you find qxl vga card  (named "Red Hat QXL GPU") in your
windows hvm's device manager to make sure your qxl is working?

My testing hvm-guest is Win XP.

I played "Harry Potter" in my LAN smoothly, qxl gives
great enhancement .

Although I don't test win7 and linux, I think it should work for them.
> I tried also with qemu 1.1.0 but nothing change.

I am not sure qemu 1.1.0 accept all the patches for xen.

Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git

It is build and installed by default, you should enable spice support.
spice can be enabled like below:

+++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
        --bindir=3D$(LIBEXEC) \
        --datadir=3D$(SHAREDIR)/qemu-xen \
        --disable-kvm \
+       --enable-spice \

> Does it work correctly for you? If so can I have some detail of your
> configurations please?

My vm.cfg:

name =3D 'xpPro_spice'
firmware_override =3D '/usr/lib/xen/boot/hvmloader'
builder =3D 'hvm'
memory =3D '1024'
device_model_version =3D 'qemu-xen'
device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:97:C=
B:0E:7D']
sdl=3D0
vnc=3D0
vncviewer=3D0
serial =3D 'pty'
vcpus=3D1
usbdevice=3D'tablet'
#spice
spice=3D1
qxl=3D1
#qxlram=3D64
#qxlvram=3D64
spiceport=3D6000
spicehost=3D'192.168.1.187'
spicedisable_ticketing =3D 1
spiceagent_mouse =3D 0 # (1|0)

> For audio support this is needed too: (tested and working)
> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu
> invocation and env QEMU_AUDIO_DRV=3Dspice
> Can you add audio support on libxl please?

I think audio support can be considered after qxl accpted.
>
>


-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:02:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:02: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 1SejSu-0006qQ-Da; Wed, 13 Jun 2012 09:02:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SejSs-0006q3-0I
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:02:10 +0000
Received: from [85.158.139.83:19044] by server-10.bemta-5.messagelabs.com id
	65/AB-23803-11758DF4; Wed, 13 Jun 2012 09:02:09 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339578127!16156571!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23658 invoked from network); 13 Jun 2012 09:02:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:02:08 -0000
Received: by yenq11 with SMTP id q11so401570yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 02:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=ss4lz/OtryjgNRTUfB7cpbUn51QaOEIBNivj1GKw/Js=;
	b=Lq7MmAUCrR8rcaH9fzwpG1G4Qk6lcZCjbvMbPvtVCK5fSg1kgCTkeQ903oSixKHKu6
	hXTtj/bXhmQA1Gd4OK6dEZV3ptYln7aufiil8doaJ1/lPZsn4TVqE7MgMwAHieG3/QPo
	3r3c+5yA/8nrt1NzJCJedD1SaVzDDuzdd+PtUZdOSduydxkFvmXoQ3a2LJA8zgSaU4iV
	zPdVmUrx+Kd2BvyiUFKhrbGISYHb8wleowqcVmq76if0Z5dZT4upM3pbElAQxE0uhkkA
	jBAS5FEZ0y2rdS2E11GC9cBhzkWsyacLz1BHoJ9GUejhjd1b/cERFR+AoJS7mYXRCI4W
	H7tA==
MIME-Version: 1.0
Received: by 10.60.169.174 with SMTP id af14mr23652982oec.13.1339578126845;
	Wed, 13 Jun 2012 02:02:06 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 13 Jun 2012 02:02:06 -0700 (PDT)
In-Reply-To: <4FD5DCF7.2070103@tiscali.it>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
Date: Wed, 13 Jun 2012 17:02:06 +0800
Message-ID: <CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: fantonifabio@tiscali.it
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni <fantonifabio@tiscali.it> wr=
ote:
> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>
>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> =A0wrote:
>>>
>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>
>>>> Sorry for late reply, I am not on this mail these days because of my
>>>> work.
>>>>
>>>> I further test qxl-vga and I think I figure out the problem in some
>>>> extend.
>>>>
>>>> If using qxl device, the default memory size of vga is 64M.
>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>
>>>> The exact reason is xc_domain_populate_physmap_exact fails, because
>>>> xen-hypervisor
>>>> fail,
>>>> it's because of =A0 alloc_domheap_pages(d, a->extent_order, a->memflag=
s)
>>>> fails in hypervisor.
>>>>
>>>> I am not very familiar with xen's memory management, Does 64M exceed
>>>> xen's heap space in this context?
>>>
>>> XL sets an upper bound of memory that can be allocated to the VM in
>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>> My guess is that a 64MB allocation would go over that limit.
>>> You could try increasing the limit manually changing the
>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
>>> videoram=3D64 in the VM config file.
>>
>> Your guess is absolutely right!
>>
>> But set videoram=3D128 or
>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>
>> Then I successfuly install qxl driver in win-hvm and QXL can work
>> properly.
>>
>> I will send some patch to add qxl support to libxl.
>
> I tried your 3 patches taken from the mailing list, it works but doesn't
> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg doesn't
> start and on windows 7 I have heavy performance problem (unusable).

Could you find qxl vga card  (named "Red Hat QXL GPU") in your
windows hvm's device manager to make sure your qxl is working?

My testing hvm-guest is Win XP.

I played "Harry Potter" in my LAN smoothly, qxl gives
great enhancement .

Although I don't test win7 and linux, I think it should work for them.
> I tried also with qemu 1.1.0 but nothing change.

I am not sure qemu 1.1.0 accept all the patches for xen.

Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git

It is build and installed by default, you should enable spice support.
spice can be enabled like below:

+++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
        --bindir=3D$(LIBEXEC) \
        --datadir=3D$(SHAREDIR)/qemu-xen \
        --disable-kvm \
+       --enable-spice \

> Does it work correctly for you? If so can I have some detail of your
> configurations please?

My vm.cfg:

name =3D 'xpPro_spice'
firmware_override =3D '/usr/lib/xen/boot/hvmloader'
builder =3D 'hvm'
memory =3D '1024'
device_model_version =3D 'qemu-xen'
device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:97:C=
B:0E:7D']
sdl=3D0
vnc=3D0
vncviewer=3D0
serial =3D 'pty'
vcpus=3D1
usbdevice=3D'tablet'
#spice
spice=3D1
qxl=3D1
#qxlram=3D64
#qxlvram=3D64
spiceport=3D6000
spicehost=3D'192.168.1.187'
spicedisable_ticketing =3D 1
spiceagent_mouse =3D 0 # (1|0)

> For audio support this is needed too: (tested and working)
> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu
> invocation and env QEMU_AUDIO_DRV=3Dspice
> Can you add audio support on libxl please?

I think audio support can be considered after qxl accpted.
>
>


-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:20:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09: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 1SejkW-0007P7-54; Wed, 13 Jun 2012 09:20:24 +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 1SejkV-0007P2-9l
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 09:20:23 +0000
Received: from [85.158.143.99:62394] by server-3.bemta-4.messagelabs.com id
	03/5C-05808-65B58DF4; Wed, 13 Jun 2012 09:20:22 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339579219!32585116!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24045 invoked from network); 13 Jun 2012 09:20:20 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:20:20 -0000
Received: by wgbed3 with SMTP id ed3so249004wgb.32
	for <xen-devel@lists.xen.org>; Wed, 13 Jun 2012 02:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=5W7eA+2ZNyJeEWJ2LDPzI+hNiNbaCTl8XF/3G7AESH8=;
	b=eTNZq58kFCfygOe2Vb4uPMUNs8J1ZgER/m5XcJEYePqIGVuJ54tThxJGznjzR84WnS
	EYETq1BWw+/2sKG5ZARbKFZ8KPcHXhMHKm1tE55kHFma0cKB9Gd4l1aHbd9f55TAJdfn
	cIVlaZIhtIRUtXbH4Ctt9lXgHAyEB7i8Zw+GIyFVsEhkSgzBwXfg6tJa1feHayPpiNdF
	WgXQp2dylDLA9cwP2bCodkX6F93YzlvKZst9NFpKV/MMyLjsHUL4isOHJ1/UfpsnplHX
	eS/Ea2wulgJp1IwMrqgZrYZDWsNZl8pfPuDTnLJ2o1Z+cInimAaYZBaNtaaZAdM97emD
	1Vjw==
Received: by 10.216.211.209 with SMTP id w59mr10112847weo.160.1339579219256;
	Wed, 13 Jun 2012 02:20:19 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id q6sm11208866wiy.0.2012.06.13.02.20.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 13 Jun 2012 02:20:18 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 9bc16d50da5ef351552635a767d043f5498a8407
Message-Id: <9bc16d50da5ef3515526.1339579210@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 13 Jun 2012 11:20:10 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix a typo in the GCREALLOC_ARRAY 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

Causing a build failure when trying to use it:

xxx: error: expected ';' before ')' token
xxx: error: expected statement before ')' token

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
 #define GCREALLOC_ARRAY(var, nmemb)                                     \
     (assert(nmemb > 0),                                                 \
      assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
-     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
 
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:20:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09: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 1SejkW-0007P7-54; Wed, 13 Jun 2012 09:20:24 +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 1SejkV-0007P2-9l
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 09:20:23 +0000
Received: from [85.158.143.99:62394] by server-3.bemta-4.messagelabs.com id
	03/5C-05808-65B58DF4; Wed, 13 Jun 2012 09:20:22 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339579219!32585116!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24045 invoked from network); 13 Jun 2012 09:20:20 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:20:20 -0000
Received: by wgbed3 with SMTP id ed3so249004wgb.32
	for <xen-devel@lists.xen.org>; Wed, 13 Jun 2012 02:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=5W7eA+2ZNyJeEWJ2LDPzI+hNiNbaCTl8XF/3G7AESH8=;
	b=eTNZq58kFCfygOe2Vb4uPMUNs8J1ZgER/m5XcJEYePqIGVuJ54tThxJGznjzR84WnS
	EYETq1BWw+/2sKG5ZARbKFZ8KPcHXhMHKm1tE55kHFma0cKB9Gd4l1aHbd9f55TAJdfn
	cIVlaZIhtIRUtXbH4Ctt9lXgHAyEB7i8Zw+GIyFVsEhkSgzBwXfg6tJa1feHayPpiNdF
	WgXQp2dylDLA9cwP2bCodkX6F93YzlvKZst9NFpKV/MMyLjsHUL4isOHJ1/UfpsnplHX
	eS/Ea2wulgJp1IwMrqgZrYZDWsNZl8pfPuDTnLJ2o1Z+cInimAaYZBaNtaaZAdM97emD
	1Vjw==
Received: by 10.216.211.209 with SMTP id w59mr10112847weo.160.1339579219256;
	Wed, 13 Jun 2012 02:20:19 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id q6sm11208866wiy.0.2012.06.13.02.20.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 13 Jun 2012 02:20:18 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 9bc16d50da5ef351552635a767d043f5498a8407
Message-Id: <9bc16d50da5ef3515526.1339579210@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 13 Jun 2012 11:20:10 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix a typo in the GCREALLOC_ARRAY 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

Causing a build failure when trying to use it:

xxx: error: expected ';' before ')' token
xxx: error: expected statement before ')' token

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
 #define GCREALLOC_ARRAY(var, nmemb)                                     \
     (assert(nmemb > 0),                                                 \
      assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
-     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
 
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:37:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sek1D-0007ev-SD; Wed, 13 Jun 2012 09:37: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 1Sek1C-0007eq-Js
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 09:37:38 +0000
Received: from [85.158.139.83:14069] by server-11.bemta-5.messagelabs.com id
	4B/89-25194-16F58DF4; Wed, 13 Jun 2012 09:37:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339580256!27350366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16000 invoked from network); 13 Jun 2012 09:37:37 -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; 13 Jun 2012 09:37:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 10:37:36 +0100
Message-Id: <4FD87BAA0200007800089AA9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 10:38:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <9477c6d78eb19422b59d.1339538538@wotan.osrc.amd.com>
In-Reply-To: <9477c6d78eb19422b59d.1339538538@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86,
 cpufreq: Change powernow's CPB status immediately
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 00:02, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> +static int powernow_cpufreq_update (int cpuid,
> +				     struct cpufreq_policy *policy)
> +{
> +    cpumask_t cpumask;
> +
> +    if (!cpumask_test_cpu(cpuid, &cpu_online_map))
> +        return -EINVAL;
> +
> +    cpumask_clear(&cpumask);
> +    cpumask_set_cpu(cpuid, &cpumask);
> +
> +    on_selected_cpus(&cpumask, update_cpb, policy, 1);

Please of cpumask_of(cpuid) here, eliminating the need for a
cpumask_t local variable.

> +
> +    return 0;
>  }
>  
>  static int powernow_cpufreq_target(struct cpufreq_policy *policy,
> --- a/xen/drivers/cpufreq/utility.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/xen/drivers/cpufreq/utility.c	Tue Jun 12 23:56:10 2012 +0200
> @@ -390,22 +390,44 @@ int cpufreq_driver_getavg(unsigned int c
>      return policy->cur;
>  }
>  
> -void cpufreq_enable_turbo(int cpuid)
> +int cpufreq_enable_turbo(int cpuid)
>  {
>      struct cpufreq_policy *policy;
> +    int ret = 0;
>  
>      policy = per_cpu(cpufreq_cpu_policy, cpuid);
> -    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
> +    if (policy && policy->turbo == CPUFREQ_TURBO_DISABLED)
> +    {
>          policy->turbo = CPUFREQ_TURBO_ENABLED;
> +        if (cpufreq_driver->update)
> +        {
> +            ret = cpufreq_driver->update(cpuid, policy);
> +            if (ret)
> +                policy->turbo = CPUFREQ_TURBO_DISABLED;
> +        }
> +    }
> +
> +    return ret;

If you introduce an error indicator here and below, shouldn't
CPUFREQ_TURBO_UNSUPPORTED also result in e.g. -EOPNOTSUPP
(and perhaps the policy == NULL case produce -EACCESS)?

Jan

>  }
>  
> -void cpufreq_disable_turbo(int cpuid)
> +int cpufreq_disable_turbo(int cpuid)
>  {
>      struct cpufreq_policy *policy;
> +    int ret = 0;
>  
>      policy = per_cpu(cpufreq_cpu_policy, cpuid);
> -    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
> +    if (policy && policy->turbo == CPUFREQ_TURBO_ENABLED)
> +    {
>          policy->turbo = CPUFREQ_TURBO_DISABLED;
> +        if (cpufreq_driver->update)
> +        {
> +            ret = cpufreq_driver->update(cpuid, policy);
> +            if (ret)
> +                policy->turbo = CPUFREQ_TURBO_ENABLED;
> +        }
> +    }
> +
> +    return ret;
>  }
>  
>  int cpufreq_get_turbo_status(int cpuid)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:37:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sek1D-0007ev-SD; Wed, 13 Jun 2012 09:37: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 1Sek1C-0007eq-Js
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 09:37:38 +0000
Received: from [85.158.139.83:14069] by server-11.bemta-5.messagelabs.com id
	4B/89-25194-16F58DF4; Wed, 13 Jun 2012 09:37:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339580256!27350366!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16000 invoked from network); 13 Jun 2012 09:37:37 -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; 13 Jun 2012 09:37:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 10:37:36 +0100
Message-Id: <4FD87BAA0200007800089AA9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 10:38:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <9477c6d78eb19422b59d.1339538538@wotan.osrc.amd.com>
In-Reply-To: <9477c6d78eb19422b59d.1339538538@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86,
 cpufreq: Change powernow's CPB status immediately
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 00:02, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> +static int powernow_cpufreq_update (int cpuid,
> +				     struct cpufreq_policy *policy)
> +{
> +    cpumask_t cpumask;
> +
> +    if (!cpumask_test_cpu(cpuid, &cpu_online_map))
> +        return -EINVAL;
> +
> +    cpumask_clear(&cpumask);
> +    cpumask_set_cpu(cpuid, &cpumask);
> +
> +    on_selected_cpus(&cpumask, update_cpb, policy, 1);

Please of cpumask_of(cpuid) here, eliminating the need for a
cpumask_t local variable.

> +
> +    return 0;
>  }
>  
>  static int powernow_cpufreq_target(struct cpufreq_policy *policy,
> --- a/xen/drivers/cpufreq/utility.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/xen/drivers/cpufreq/utility.c	Tue Jun 12 23:56:10 2012 +0200
> @@ -390,22 +390,44 @@ int cpufreq_driver_getavg(unsigned int c
>      return policy->cur;
>  }
>  
> -void cpufreq_enable_turbo(int cpuid)
> +int cpufreq_enable_turbo(int cpuid)
>  {
>      struct cpufreq_policy *policy;
> +    int ret = 0;
>  
>      policy = per_cpu(cpufreq_cpu_policy, cpuid);
> -    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
> +    if (policy && policy->turbo == CPUFREQ_TURBO_DISABLED)
> +    {
>          policy->turbo = CPUFREQ_TURBO_ENABLED;
> +        if (cpufreq_driver->update)
> +        {
> +            ret = cpufreq_driver->update(cpuid, policy);
> +            if (ret)
> +                policy->turbo = CPUFREQ_TURBO_DISABLED;
> +        }
> +    }
> +
> +    return ret;

If you introduce an error indicator here and below, shouldn't
CPUFREQ_TURBO_UNSUPPORTED also result in e.g. -EOPNOTSUPP
(and perhaps the policy == NULL case produce -EACCESS)?

Jan

>  }
>  
> -void cpufreq_disable_turbo(int cpuid)
> +int cpufreq_disable_turbo(int cpuid)
>  {
>      struct cpufreq_policy *policy;
> +    int ret = 0;
>  
>      policy = per_cpu(cpufreq_cpu_policy, cpuid);
> -    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
> +    if (policy && policy->turbo == CPUFREQ_TURBO_ENABLED)
> +    {
>          policy->turbo = CPUFREQ_TURBO_DISABLED;
> +        if (cpufreq_driver->update)
> +        {
> +            ret = cpufreq_driver->update(cpuid, policy);
> +            if (ret)
> +                policy->turbo = CPUFREQ_TURBO_ENABLED;
> +        }
> +    }
> +
> +    return ret;
>  }
>  
>  int cpufreq_get_turbo_status(int cpuid)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09: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 1Sek1x-0007hC-9S; Wed, 13 Jun 2012 09:38:25 +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 1Sek1v-0007h4-3w
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:38:23 +0000
Received: from [85.158.139.83:27158] by server-1.bemta-5.messagelabs.com id
	21/19-19721-E8F58DF4; Wed, 13 Jun 2012 09:38:22 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339580301!23481751!1
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13354 invoked from network); 13 Jun 2012 09:38:21 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-7.tower-182.messagelabs.com with SMTP;
	13 Jun 2012 09:38:21 -0000
Received: from [192.168.178.50] (79.54.146.106) by smtp209.alice.it
	(8.6.023.02) id 4EF08A6313B2DD8F; Wed, 13 Jun 2012 11:38:16 +0200
Message-ID: <4FD85F83.3080207@tiscali.it>
Date: Wed, 13 Jun 2012 11:38:11 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ZhouPeng <zpengxen@gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
In-Reply-To: <CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
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="===============2861525767067229441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2861525767067229441==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010406010503050507040204"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms010406010503050507040204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/06/2012 11:02, ZhouPeng ha scritto:
> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.it>=
  wrote:
>> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>>
>>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com>    wrote:
>>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>> Sorry for late reply, I am not on this mail these days because of m=
y
>>>>> work.
>>>>>
>>>>> I further test qxl-vga and I think I figure out the problem in some=

>>>>> extend.
>>>>>
>>>>> If using qxl device, the default memory size of vga is 64M.
>>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>>
>>>>> The exact reason is xc_domain_populate_physmap_exact fails, because=

>>>>> xen-hypervisor
>>>>> fail,
>>>>> it's because of   alloc_domheap_pages(d, a->extent_order, a->memfla=
gs)
>>>>> fails in hypervisor.
>>>>>
>>>>> I am not very familiar with xen's memory management, Does 64M excee=
d
>>>>> xen's heap space in this context?
>>>> XL sets an upper bound of memory that can be allocated to the VM in
>>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>>> My guess is that a 64MB allocation would go over that limit.
>>>> You could try increasing the limit manually changing the
>>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setti=
ng
>>>> videoram=3D64 in the VM config file.
>>> Your guess is absolutely right!
>>>
>>> But set videoram=3D128 or
>>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>>
>>> Then I successfuly install qxl driver in win-hvm and QXL can work
>>> properly.
>>>
>>> I will send some patch to add qxl support to libxl.
>> I tried your 3 patches taken from the mailing list, it works but doesn=
't
>> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg doe=
sn't
>> start and on windows 7 I have heavy performance problem (unusable).
> Could you find qxl vga card  (named "Red Hat QXL GPU") in your
> windows hvm's device manager to make sure your qxl is working?
>
> My testing hvm-guest is Win XP.
>
> I played "Harry Potter" in my LAN smoothly, qxl gives
> great enhancement .
>
> Although I don't test win7 and linux, I think it should work for them.
>> I tried also with qemu 1.1.0 but nothing change.
> I am not sure qemu 1.1.0 accept all the patches for xen.
>
> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.gi=
t
>
> It is build and installed by default, you should enable spice support.
> spice can be enabled like below:
>
> +++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>          --bindir=3D$(LIBEXEC) \
>          --datadir=3D$(SHAREDIR)/qemu-xen \
>          --disable-kvm \
> +       --enable-spice \
>
>> Does it work correctly for you? If so can I have some detail of your
>> configurations please?
> My vm.cfg:
>
> name =3D 'xpPro_spice'
> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
> builder =3D 'hvm'
> memory =3D '1024'
> device_model_version =3D 'qemu-xen'
> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:=
97:CB:0E:7D']
> sdl=3D0
> vnc=3D0
> vncviewer=3D0
> serial =3D 'pty'
> vcpus=3D1
> usbdevice=3D'tablet'
> #spice
> spice=3D1
> qxl=3D1
> #qxlram=3D64
> #qxlvram=3D64
> spiceport=3D6000
> spicehost=3D'192.168.1.187'
> spicedisable_ticketing =3D 1
> spiceagent_mouse =3D 0 # (1|0)
>
>> For audio support this is needed too: (tested and working)
>> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on=
 qemu
>> invocation and env QEMU_AUDIO_DRV=3Dspice
>> Can you add audio support on libxl please?
> I think audio support can be considered after qxl accpted.
>>
>
Thanks for reply, qxl driver is installed, windows see qxl video card,=20
already compiled qemu with spice with patch I send months ago, already=20
tried git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
Unfortunately the results are always the same.
Here a quick recording:
Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv
Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
Are not new but the result of the last test is the same.
I hope I can help you understand the problem.
If you need more information ask.


--------------ms010406010503050507040204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYxMzA5MzgxMVowIwYJKoZIhvcNAQkEMRYEFJaN6tZbQyrJOtgc3KNsEhlk
3qJnMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBTiYBPiC0dwqdrPzaMdHyqiUCaUPjGe6V/Ofl8sId7
V1IuONGIfBc0Uel6SH+B/cEc+8DG4S+5Hwwui4Vuibk/xEjgGc+ZaV0TepLnaoQFwe9NsJK5
Izg4xb2Ux7bSXMKfc64PhMHol/+VWhCGDh/20LwEgPIQK8bclei2Ff57NY0RrvN3V+zw1yyR
nB7HJACXCkKjMIOacszKHW2cT3K2sI0wMrIhA7xRW6zLaUMTtfzA+qQp5ZnHITgewqbS2w0K
cRjF+OEYpjevV2xn/fZmKa9WQzA4IgI5jw4aIXISF2rsqCRgdOnjuCEZK3GjQdVYVq6J2hqm
TDLN4dnvsLBZAAAAAAAA
--------------ms010406010503050507040204--


--===============2861525767067229441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2861525767067229441==--


From xen-devel-bounces@lists.xen.org Wed Jun 13 09:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09: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 1Sek1x-0007hC-9S; Wed, 13 Jun 2012 09:38:25 +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 1Sek1v-0007h4-3w
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:38:23 +0000
Received: from [85.158.139.83:27158] by server-1.bemta-5.messagelabs.com id
	21/19-19721-E8F58DF4; Wed, 13 Jun 2012 09:38:22 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339580301!23481751!1
X-Originating-IP: [82.57.200.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13354 invoked from network); 13 Jun 2012 09:38:21 -0000
Received: from smtp209.alice.it (HELO smtp209.alice.it) (82.57.200.105)
	by server-7.tower-182.messagelabs.com with SMTP;
	13 Jun 2012 09:38:21 -0000
Received: from [192.168.178.50] (79.54.146.106) by smtp209.alice.it
	(8.6.023.02) id 4EF08A6313B2DD8F; Wed, 13 Jun 2012 11:38:16 +0200
Message-ID: <4FD85F83.3080207@tiscali.it>
Date: Wed, 13 Jun 2012 11:38:11 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ZhouPeng <zpengxen@gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
In-Reply-To: <CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
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="===============2861525767067229441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2861525767067229441==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010406010503050507040204"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms010406010503050507040204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/06/2012 11:02, ZhouPeng ha scritto:
> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.it>=
  wrote:
>> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>>
>>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>>> <stefano.stabellini@eu.citrix.com>    wrote:
>>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>> Sorry for late reply, I am not on this mail these days because of m=
y
>>>>> work.
>>>>>
>>>>> I further test qxl-vga and I think I figure out the problem in some=

>>>>> extend.
>>>>>
>>>>> If using qxl device, the default memory size of vga is 64M.
>>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>>
>>>>> The exact reason is xc_domain_populate_physmap_exact fails, because=

>>>>> xen-hypervisor
>>>>> fail,
>>>>> it's because of   alloc_domheap_pages(d, a->extent_order, a->memfla=
gs)
>>>>> fails in hypervisor.
>>>>>
>>>>> I am not very familiar with xen's memory management, Does 64M excee=
d
>>>>> xen's heap space in this context?
>>>> XL sets an upper bound of memory that can be allocated to the VM in
>>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>>> My guess is that a 64MB allocation would go over that limit.
>>>> You could try increasing the limit manually changing the
>>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setti=
ng
>>>> videoram=3D64 in the VM config file.
>>> Your guess is absolutely right!
>>>
>>> But set videoram=3D128 or
>>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>>
>>> Then I successfuly install qxl driver in win-hvm and QXL can work
>>> properly.
>>>
>>> I will send some patch to add qxl support to libxl.
>> I tried your 3 patches taken from the mailing list, it works but doesn=
't
>> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg doe=
sn't
>> start and on windows 7 I have heavy performance problem (unusable).
> Could you find qxl vga card  (named "Red Hat QXL GPU") in your
> windows hvm's device manager to make sure your qxl is working?
>
> My testing hvm-guest is Win XP.
>
> I played "Harry Potter" in my LAN smoothly, qxl gives
> great enhancement .
>
> Although I don't test win7 and linux, I think it should work for them.
>> I tried also with qemu 1.1.0 but nothing change.
> I am not sure qemu 1.1.0 accept all the patches for xen.
>
> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.gi=
t
>
> It is build and installed by default, you should enable spice support.
> spice can be enabled like below:
>
> +++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>          --bindir=3D$(LIBEXEC) \
>          --datadir=3D$(SHAREDIR)/qemu-xen \
>          --disable-kvm \
> +       --enable-spice \
>
>> Does it work correctly for you? If so can I have some detail of your
>> configurations please?
> My vm.cfg:
>
> name =3D 'xpPro_spice'
> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
> builder =3D 'hvm'
> memory =3D '1024'
> device_model_version =3D 'qemu-xen'
> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:=
97:CB:0E:7D']
> sdl=3D0
> vnc=3D0
> vncviewer=3D0
> serial =3D 'pty'
> vcpus=3D1
> usbdevice=3D'tablet'
> #spice
> spice=3D1
> qxl=3D1
> #qxlram=3D64
> #qxlvram=3D64
> spiceport=3D6000
> spicehost=3D'192.168.1.187'
> spicedisable_ticketing =3D 1
> spiceagent_mouse =3D 0 # (1|0)
>
>> For audio support this is needed too: (tested and working)
>> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on=
 qemu
>> invocation and env QEMU_AUDIO_DRV=3Dspice
>> Can you add audio support on libxl please?
> I think audio support can be considered after qxl accpted.
>>
>
Thanks for reply, qxl driver is installed, windows see qxl video card,=20
already compiled qemu with spice with patch I send months ago, already=20
tried git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
Unfortunately the results are always the same.
Here a quick recording:
Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv
Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
Are not new but the result of the last test is the same.
I hope I can help you understand the problem.
If you need more information ask.


--------------ms010406010503050507040204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYxMzA5MzgxMVowIwYJKoZIhvcNAQkEMRYEFJaN6tZbQyrJOtgc3KNsEhlk
3qJnMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBTiYBPiC0dwqdrPzaMdHyqiUCaUPjGe6V/Ofl8sId7
V1IuONGIfBc0Uel6SH+B/cEc+8DG4S+5Hwwui4Vuibk/xEjgGc+ZaV0TepLnaoQFwe9NsJK5
Izg4xb2Ux7bSXMKfc64PhMHol/+VWhCGDh/20LwEgPIQK8bclei2Ff57NY0RrvN3V+zw1yyR
nB7HJACXCkKjMIOacszKHW2cT3K2sI0wMrIhA7xRW6zLaUMTtfzA+qQp5ZnHITgewqbS2w0K
cRjF+OEYpjevV2xn/fZmKa9WQzA4IgI5jw4aIXISF2rsqCRgdOnjuCEZK3GjQdVYVq6J2hqm
TDLN4dnvsLBZAAAAAAAA
--------------ms010406010503050507040204--


--===============2861525767067229441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2861525767067229441==--


From xen-devel-bounces@lists.xen.org Wed Jun 13 09:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sek5k-00086R-Nl; Wed, 13 Jun 2012 09:42: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 1Sek5j-00086H-7y
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:42:19 +0000
Received: from [193.109.254.147:5040] by server-3.bemta-14.messagelabs.com id
	54/40-05653-A7068DF4; Wed, 13 Jun 2012 09:42:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339580537!8670478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15633 invoked from network); 13 Jun 2012 09:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12990203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 09:41:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 10:41:44 +0100
Message-ID: <1339580503.24104.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 13 Jun 2012 10:41:43 +0100
In-Reply-To: <4FD856F7.7040201@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
	<4FD855D7.8070501@citrix.com>
	<1339577910.24104.148.camel@zakaz.uk.xensource.com>
	<4FD856F7.7040201@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTEzIGF0IDEwOjAxICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gV2VkLCAyMDEyLTA2LTEzIGF0IDA5OjU2ICsw
MTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+
PiBPbiBXZWQsIDIwMTItMDYtMTMgYXQgMDk6MDEgKzAxMDAsIE9sYWYgSGVyaW5nIHdyb3RlOgo+
ID4+Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+Pj4+ICMgVXNlciBPbGFmIEhlcmluZzxvbGFm
QGFlcGZsZS5kZT4KPiA+Pj4+ICMgRGF0ZSAxMzM5NTcyMjkzIC03MjAwCj4gPj4+PiAjIE5vZGUg
SUQgZWE1NTRkMDU4MjFiOTVhN2U5NmU0YTI1Y2JmOTUzYzVhYmUzNWFlYgo+ID4+Pj4gIyBQYXJl
bnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIxYmIyYzcwNDk4ODUKPiA+Pj4+IHRvb2xz
L2NvbmZpZ3VyZS5hYzogYWRkIHZlcnNpb24gY2hlY2sgZm9yIGdsaWIyCj4gPj4+Pgo+ID4+Pj4g
eGVuLXVuc3RhYmxlIGZhaWxzIHRvIGJ1aWxkIGluIGEgU0xFUzEwU1A0IGVudmlyb25tZW50IHNp
bmNlIGEgbG9uZyB0aW1lCj4gPj4+PiBiZWNhdXNlIHRoZSBpbmNsdWRlZCB2ZXJzaW9uIG9mIGds
aWIgaXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0aGUgcmVxdWlyZWQKPiA+Pj4+IGdsaWIgdmVyc2lv
bi4gQWNjb3JkaW5nIHRvIHRoZSBkb2NzIGdsaWIgdmVyc2lvbiAyLjEyIGluY2x1ZGVzIGJhc2U2
NAo+ID4+Pj4gc3VwcG9ydCwgYnV0IFNMRVMxMCBpcyBzaGlwcGVkIHdpdGggZ2xpYiAyLjguNjoK
PiA+Pj4+Cj4gPj4+PiBxZW11LXRpbWVyLWNvbW1vbi5vOiBJbiBmdW5jdGlvbiBgaW5pdF9nZXRf
Y2xvY2snOgo+ID4+Pj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJTEQveGVuLTQuMi4yNTQzMi9ub24t
ZGJnL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLWNvbW1vbi5jOjU3Ogo+ID4+Pj4gdW5k
ZWZpbmVkIHJlZmVyZW5jZSB0byBgY2xvY2tfZ2V0dGltZScKPiA+Pj4+IHFnYS9ndWVzdC1hZ2Vu
dC1jb21tYW5kcy5vOiBJbiBmdW5jdGlvbiBgcW1wX2d1ZXN0X2ZpbGVfd3JpdGUnOgo+ID4+Pj4g
cWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6MjQ5OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBn
X2Jhc2U2NF9kZWNvZGUnCj4gPj4+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMubzogSW4gZnVu
Y3Rpb24gYHFtcF9ndWVzdF9maWxlX3JlYWQnOgo+ID4+Pj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1h
bmRzLmM6MjI0OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9lbmNvZGUnCj4gPj4+
PiBjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+ID4+Pj4gbWFrZVszXTogKioq
IFtxZW11LWdhXSBFcnJvciAxCj4gPj4+Pgo+ID4+Pj4gQWRkIGEgdmVyc2lvbiBjaGVjayB0byBj
b25maWd1cmUgdG8gcmVxdWlyZSBhdCBsZWFzdCBnbGliIDIuMTIgdG8gYnVpbGQKPiA+Pj4+IHFl
bXUtdXBzdHJlYW0uCj4gPj4+IERvZXMgdGhpcyBjYXVzZSBjb25maWd1cmUgdG8gZmFpbCBvciBk
b2VzIGl0IGNhdXNlIHVzIHRvIGp1c3Qgbm90IGJ1aWxkCj4gPj4+IHFlbXUtdXBzdHJlYW0/IEkg
dGhpbmsgdGhlIGZvcm1lciAod2hpY2ggaXMgZmluZSB3aXRoIG1lKSBidXQgeW91ciBsYXN0Cj4g
Pj4+IHNlbnRlbmNlIHN1Z2dlc3RzIHRoYXQgbGF0dGVyLgo+ID4+ICAgIEZyb20gbXkgdW5kZXJz
dGFuZGluZyBpdCBjYXVzZXMgUWVtdSBidWlsZCB0byBmYWlsLCBzaW5jZSBvdXIgdmVyc2lvbgo+
ID4+IG9mIFFlbXUgY29uZmlndXJlIHNjcmlwdCBkb2Vzbid0IGNoZWNrIGZvciBnbGliIHZlcnNp
b24uCj4gPgo+ID4gQnV0IHRoaXMgcGF0Y2ggbWFrZXMgaXQgZG8gdGhhdCBjaGVjaywgcmlnaHQ/
Cj4gCj4gWWVzLCB3ZSBjdXJyZW50bHkgY2hlY2sgZm9yIGdsaWIsIGJ1dCB3ZSBkb24ndCByZXF1
aXJlIGFueSBzcGVjaWZpYyAKPiB2ZXJzaW9uLiBUaGlzIHBhdGNoIHNldHMgdGhlIG5lY2Vzc2Fy
eSBnbGliIHZlcnNpb24gZm9yIFFlbXUtdXBzdHJlYW0gCj4gY29tcGlsYXRpb24gdG8gc3VjY2Vl
ZCBhcyBhIHJlcXVpcmVtZW50IGZvciBvdXIgY29uZmlndXJlIHNjcmlwdC4KClJpZ2h0LiBCeSAi
dGhpcyIgaW4gbXkgb3JpZ2luYWwgcXVlc3Rpb24gSSB3YXMgYXNraW5nIGFib3V0IHRoZSBjaGFu
Z2UKbm90IHRoZSBvcmlnaW5hbCBmYWlsdXJlLCBzb3JyeSB0aGF0IHdhcyBwcm9iYWJseSBub3Qg
b2J2aW91cy4gSU9XIHRoZQpiZWhhdmlvdXIgYWZ0ZXIgdGhpcyBwYXRjaCBpcyB0aGF0IG91ciBj
b25maWd1cmUgd2lsbCBub3cgZmFpbC4KCj4gCj4gPgo+ID4+IFRoZSBmb2xsb3dpbmcgY29tbWl0
IHNob3VsZCBiZSBiYWNrcG9ydGVkIHRvIG91ciBRZW11IHRyZWUgYWxzbwo+ID4+IGE1MmQyOGFm
YjRlODI1YTViMjg4MTUzNzBhMjY4OTA0YTRjNmRjMTEuCj4gPj4KPiA+Pj4+IFNpZ25lZC1vZmYt
Ynk6IE9sYWYgSGVyaW5nPG9sYWZAYWVwZmxlLmRlPgo+ID4+IEFueXdheSwgc2luY2Ugd2UgY2hl
Y2sgZm9yIGdsaWIgYWxyZWFkeSwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBhcHBsaWVkLAo+ID4+
IHNvIGF0IGxlYXN0IHdlIGNoZWNrIGZvciB0aGUgcmVxdWlyZWQgdmVyc2lvbgo+ID4+Cj4gPj4g
QWNrZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gPj4KPiA+
PiBQbGVhc2UgcmVydW4gYXV0b2NvbmYgYWZ0ZXIgYXBwbHlpbmcgdGhpcy4KPiA+Pgo+ID4+Pj4g
ZGlmZiAtciBhNzBiMzVkZWIyYjUgLXIgZWE1NTRkMDU4MjFiIHRvb2xzL2NvbmZpZ3VyZS5hYwo+
ID4+Pj4gLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCj4gPj4+PiArKysgYi90b29scy9jb25maWd1
cmUuYWMKPiA+Pj4+IEBAIC0xMTUsNyArMTE1LDcgQEAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JD
Q10sIFtiY2NdKQo+ID4+Pj4gICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lBU0xdLCBbaWFzbF0p
Cj4gPj4+PiAgICBBWF9DSEVDS19VVUlECj4gPj4+PiAgICBBWF9DSEVDS19DVVJTRVMKPiA+Pj4+
IC1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKPiA+Pj4+ICtQS0dfQ0hFQ0tfTU9E
VUxFUyhnbGliLCBbZ2xpYi0yLjA+PSAyLjEyXSkKPiA+Pj4+Cj4gPj4+PiAgICAjIENoZWNrIGxp
YnJhcnkgcGF0aAo+ID4+Pj4gICAgQVhfREVGQVVMVF9MSUIKPiA+Pj4+Cj4gPj4+PiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4+Pj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+ID4+Pj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiA+Pj4+IGh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+ID4+Pgo+ID4KPiA+Cj4gCgoKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Wed Jun 13 09:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 09:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sek5k-00086R-Nl; Wed, 13 Jun 2012 09:42: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 1Sek5j-00086H-7y
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 09:42:19 +0000
Received: from [193.109.254.147:5040] by server-3.bemta-14.messagelabs.com id
	54/40-05653-A7068DF4; Wed, 13 Jun 2012 09:42:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339580537!8670478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15633 invoked from network); 13 Jun 2012 09:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 09:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12990203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 09:41:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 10:41:44 +0100
Message-ID: <1339580503.24104.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 13 Jun 2012 10:41:43 +0100
In-Reply-To: <4FD856F7.7040201@citrix.com>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
	<4FD855D7.8070501@citrix.com>
	<1339577910.24104.148.camel@zakaz.uk.xensource.com>
	<4FD856F7.7040201@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTEzIGF0IDEwOjAxICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gV2VkLCAyMDEyLTA2LTEzIGF0IDA5OjU2ICsw
MTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+
PiBPbiBXZWQsIDIwMTItMDYtMTMgYXQgMDk6MDEgKzAxMDAsIE9sYWYgSGVyaW5nIHdyb3RlOgo+
ID4+Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+Pj4+ICMgVXNlciBPbGFmIEhlcmluZzxvbGFm
QGFlcGZsZS5kZT4KPiA+Pj4+ICMgRGF0ZSAxMzM5NTcyMjkzIC03MjAwCj4gPj4+PiAjIE5vZGUg
SUQgZWE1NTRkMDU4MjFiOTVhN2U5NmU0YTI1Y2JmOTUzYzVhYmUzNWFlYgo+ID4+Pj4gIyBQYXJl
bnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIxYmIyYzcwNDk4ODUKPiA+Pj4+IHRvb2xz
L2NvbmZpZ3VyZS5hYzogYWRkIHZlcnNpb24gY2hlY2sgZm9yIGdsaWIyCj4gPj4+Pgo+ID4+Pj4g
eGVuLXVuc3RhYmxlIGZhaWxzIHRvIGJ1aWxkIGluIGEgU0xFUzEwU1A0IGVudmlyb25tZW50IHNp
bmNlIGEgbG9uZyB0aW1lCj4gPj4+PiBiZWNhdXNlIHRoZSBpbmNsdWRlZCB2ZXJzaW9uIG9mIGds
aWIgaXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0aGUgcmVxdWlyZWQKPiA+Pj4+IGdsaWIgdmVyc2lv
bi4gQWNjb3JkaW5nIHRvIHRoZSBkb2NzIGdsaWIgdmVyc2lvbiAyLjEyIGluY2x1ZGVzIGJhc2U2
NAo+ID4+Pj4gc3VwcG9ydCwgYnV0IFNMRVMxMCBpcyBzaGlwcGVkIHdpdGggZ2xpYiAyLjguNjoK
PiA+Pj4+Cj4gPj4+PiBxZW11LXRpbWVyLWNvbW1vbi5vOiBJbiBmdW5jdGlvbiBgaW5pdF9nZXRf
Y2xvY2snOgo+ID4+Pj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJTEQveGVuLTQuMi4yNTQzMi9ub24t
ZGJnL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLWNvbW1vbi5jOjU3Ogo+ID4+Pj4gdW5k
ZWZpbmVkIHJlZmVyZW5jZSB0byBgY2xvY2tfZ2V0dGltZScKPiA+Pj4+IHFnYS9ndWVzdC1hZ2Vu
dC1jb21tYW5kcy5vOiBJbiBmdW5jdGlvbiBgcW1wX2d1ZXN0X2ZpbGVfd3JpdGUnOgo+ID4+Pj4g
cWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6MjQ5OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBn
X2Jhc2U2NF9kZWNvZGUnCj4gPj4+PiBxZ2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMubzogSW4gZnVu
Y3Rpb24gYHFtcF9ndWVzdF9maWxlX3JlYWQnOgo+ID4+Pj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1h
bmRzLmM6MjI0OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9lbmNvZGUnCj4gPj4+
PiBjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+ID4+Pj4gbWFrZVszXTogKioq
IFtxZW11LWdhXSBFcnJvciAxCj4gPj4+Pgo+ID4+Pj4gQWRkIGEgdmVyc2lvbiBjaGVjayB0byBj
b25maWd1cmUgdG8gcmVxdWlyZSBhdCBsZWFzdCBnbGliIDIuMTIgdG8gYnVpbGQKPiA+Pj4+IHFl
bXUtdXBzdHJlYW0uCj4gPj4+IERvZXMgdGhpcyBjYXVzZSBjb25maWd1cmUgdG8gZmFpbCBvciBk
b2VzIGl0IGNhdXNlIHVzIHRvIGp1c3Qgbm90IGJ1aWxkCj4gPj4+IHFlbXUtdXBzdHJlYW0/IEkg
dGhpbmsgdGhlIGZvcm1lciAod2hpY2ggaXMgZmluZSB3aXRoIG1lKSBidXQgeW91ciBsYXN0Cj4g
Pj4+IHNlbnRlbmNlIHN1Z2dlc3RzIHRoYXQgbGF0dGVyLgo+ID4+ICAgIEZyb20gbXkgdW5kZXJz
dGFuZGluZyBpdCBjYXVzZXMgUWVtdSBidWlsZCB0byBmYWlsLCBzaW5jZSBvdXIgdmVyc2lvbgo+
ID4+IG9mIFFlbXUgY29uZmlndXJlIHNjcmlwdCBkb2Vzbid0IGNoZWNrIGZvciBnbGliIHZlcnNp
b24uCj4gPgo+ID4gQnV0IHRoaXMgcGF0Y2ggbWFrZXMgaXQgZG8gdGhhdCBjaGVjaywgcmlnaHQ/
Cj4gCj4gWWVzLCB3ZSBjdXJyZW50bHkgY2hlY2sgZm9yIGdsaWIsIGJ1dCB3ZSBkb24ndCByZXF1
aXJlIGFueSBzcGVjaWZpYyAKPiB2ZXJzaW9uLiBUaGlzIHBhdGNoIHNldHMgdGhlIG5lY2Vzc2Fy
eSBnbGliIHZlcnNpb24gZm9yIFFlbXUtdXBzdHJlYW0gCj4gY29tcGlsYXRpb24gdG8gc3VjY2Vl
ZCBhcyBhIHJlcXVpcmVtZW50IGZvciBvdXIgY29uZmlndXJlIHNjcmlwdC4KClJpZ2h0LiBCeSAi
dGhpcyIgaW4gbXkgb3JpZ2luYWwgcXVlc3Rpb24gSSB3YXMgYXNraW5nIGFib3V0IHRoZSBjaGFu
Z2UKbm90IHRoZSBvcmlnaW5hbCBmYWlsdXJlLCBzb3JyeSB0aGF0IHdhcyBwcm9iYWJseSBub3Qg
b2J2aW91cy4gSU9XIHRoZQpiZWhhdmlvdXIgYWZ0ZXIgdGhpcyBwYXRjaCBpcyB0aGF0IG91ciBj
b25maWd1cmUgd2lsbCBub3cgZmFpbC4KCj4gCj4gPgo+ID4+IFRoZSBmb2xsb3dpbmcgY29tbWl0
IHNob3VsZCBiZSBiYWNrcG9ydGVkIHRvIG91ciBRZW11IHRyZWUgYWxzbwo+ID4+IGE1MmQyOGFm
YjRlODI1YTViMjg4MTUzNzBhMjY4OTA0YTRjNmRjMTEuCj4gPj4KPiA+Pj4+IFNpZ25lZC1vZmYt
Ynk6IE9sYWYgSGVyaW5nPG9sYWZAYWVwZmxlLmRlPgo+ID4+IEFueXdheSwgc2luY2Ugd2UgY2hl
Y2sgZm9yIGdsaWIgYWxyZWFkeSwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBhcHBsaWVkLAo+ID4+
IHNvIGF0IGxlYXN0IHdlIGNoZWNrIGZvciB0aGUgcmVxdWlyZWQgdmVyc2lvbgo+ID4+Cj4gPj4g
QWNrZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gPj4KPiA+
PiBQbGVhc2UgcmVydW4gYXV0b2NvbmYgYWZ0ZXIgYXBwbHlpbmcgdGhpcy4KPiA+Pgo+ID4+Pj4g
ZGlmZiAtciBhNzBiMzVkZWIyYjUgLXIgZWE1NTRkMDU4MjFiIHRvb2xzL2NvbmZpZ3VyZS5hYwo+
ID4+Pj4gLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCj4gPj4+PiArKysgYi90b29scy9jb25maWd1
cmUuYWMKPiA+Pj4+IEBAIC0xMTUsNyArMTE1LDcgQEAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JD
Q10sIFtiY2NdKQo+ID4+Pj4gICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lBU0xdLCBbaWFzbF0p
Cj4gPj4+PiAgICBBWF9DSEVDS19VVUlECj4gPj4+PiAgICBBWF9DSEVDS19DVVJTRVMKPiA+Pj4+
IC1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKPiA+Pj4+ICtQS0dfQ0hFQ0tfTU9E
VUxFUyhnbGliLCBbZ2xpYi0yLjA+PSAyLjEyXSkKPiA+Pj4+Cj4gPj4+PiAgICAjIENoZWNrIGxp
YnJhcnkgcGF0aAo+ID4+Pj4gICAgQVhfREVGQVVMVF9MSUIKPiA+Pj4+Cj4gPj4+PiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4+Pj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+ID4+Pj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiA+Pj4+IGh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+ID4+Pgo+ID4KPiA+Cj4gCgoKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:02:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SekOa-0008WK-Hy; Wed, 13 Jun 2012 10:01: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 1SekOY-0008WF-2o
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:01:46 +0000
Received: from [85.158.143.99:5185] by server-2.bemta-4.messagelabs.com id
	45/A8-17938-90568DF4; Wed, 13 Jun 2012 10:01:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339581704!32594757!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10823 invoked from network); 13 Jun 2012 10:01:44 -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; 13 Jun 2012 10:01:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 11:01:43 +0100
Message-Id: <4FD881530200007800089ACB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 11:02:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB9972323.0__="
Subject: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses to
 be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartB9972323.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than deferring the detection of these to the point where they
get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
to be raised by IRET, which invokes the guest's [fragile] fail-safe
callback), don't even allow such to be set.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -736,6 +736,14 @@ int arch_set_info_guest(
     {
         if ( !compat )
         {
+#ifdef __x86_64__
+            if ( !is_canonical_address(c.nat->user_regs.eip) ||
+                 !is_canonical_address(c.nat->event_callback_eip) ||
+                 !is_canonical_address(c.nat->syscall_callback_eip) ||
+                 !is_canonical_address(c.nat->failsafe_callback_eip) )
+                return -EINVAL;
+#endif
+
             fixup_guest_stack_selector(d, c.nat->user_regs.ss);
             fixup_guest_stack_selector(d, c.nat->kernel_ss);
             fixup_guest_code_selector(d, c.nat->user_regs.cs);
@@ -745,7 +753,11 @@ int arch_set_info_guest(
 #endif
=20
             for ( i =3D 0; i < 256; i++ )
+            {
+                if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
+                    return -EINVAL;
                 fixup_guest_code_selector(d, c.nat->trap_ctxt[i].cs);
+            }
=20
             /* LDT safety checks. */
             if ( ((c.nat->ldt_base & (PAGE_SIZE-1)) !=3D 0) ||
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1033,6 +1033,9 @@ long arch_do_domctl(
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
             {
+                if ( !is_canonical_address(evc->sysenter_callback_eip) ||
+                     !is_canonical_address(evc->syscall32_callback_eip) )
+                    goto ext_vcpucontext_out;
                 fixup_guest_code_selector(d, evc->sysenter_callback_cs);
                 v->arch.pv_vcpu.sysenter_callback_cs      =3D
                     evc->sysenter_callback_cs;
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3581,6 +3581,9 @@ long register_guest_nmi_callback(unsigne
     struct domain *d =3D v->domain;
     struct trap_info *t =3D &v->arch.pv_vcpu.trap_ctxt[TRAP_nmi];
=20
+    if ( !is_canonical_address(address) )
+        return -EINVAL;
+
     t->vector  =3D TRAP_nmi;
     t->flags   =3D 0;
     t->cs      =3D (is_pv_32on64_domain(d) ?
@@ -3708,6 +3711,9 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
         if ( cur.address =3D=3D 0 )
             break;
=20
+        if ( !is_canonical_address(cur.address) )
+            return -EINVAL;
+
         fixup_guest_code_selector(curr->domain, cur.cs);
=20
         memcpy(&dst[cur.vector], &cur, sizeof(cur));




--=__PartB9972323.0__=
Content-Type: text/plain; name="x86_64-canonical-checks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-canonical-checks.patch"

x86-64: don't allow non-canonical addresses to be set for any callback=0A=
=0ARather than deferring the detection of these to the point where =
they=0Aget actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a =
#GP=0Ato be raised by IRET, which invokes the guest's [fragile] =
fail-safe=0Acallback), don't even allow such to be set.=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@@ -736,6 +736,14 @@ int arch_set_info_guest(=0A =
    {=0A         if ( !compat )=0A         {=0A+#ifdef __x86_64__=0A+      =
      if ( !is_canonical_address(c.nat->user_regs.eip) ||=0A+              =
   !is_canonical_address(c.nat->event_callback_eip) ||=0A+                 =
!is_canonical_address(c.nat->syscall_callback_eip) ||=0A+                 =
!is_canonical_address(c.nat->failsafe_callback_eip) )=0A+                =
return -EINVAL;=0A+#endif=0A+=0A             fixup_guest_stack_selector(d, =
c.nat->user_regs.ss);=0A             fixup_guest_stack_selector(d, =
c.nat->kernel_ss);=0A             fixup_guest_code_selector(d, c.nat->user_=
regs.cs);=0A@@ -745,7 +753,11 @@ int arch_set_info_guest(=0A #endif=0A =0A =
            for ( i =3D 0; i < 256; i++ )=0A+            {=0A+             =
   if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )=0A+           =
         return -EINVAL;=0A                 fixup_guest_code_selector(d, =
c.nat->trap_ctxt[i].cs);=0A+            }=0A =0A             /* LDT safety =
checks. */=0A             if ( ((c.nat->ldt_base & (PAGE_SIZE-1)) !=3D 0) =
||=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/domctl.c=0A@@ =
-1033,6 +1033,9 @@ long arch_do_domctl(=0A #ifdef __x86_64__=0A            =
 if ( !is_hvm_domain(d) )=0A             {=0A+                if ( =
!is_canonical_address(evc->sysenter_callback_eip) ||=0A+                   =
  !is_canonical_address(evc->syscall32_callback_eip) )=0A+                 =
   goto ext_vcpucontext_out;=0A                 fixup_guest_code_selector(d=
, evc->sysenter_callback_cs);=0A                 v->arch.pv_vcpu.sysenter_c=
allback_cs      =3D=0A                     evc->sysenter_callback_cs;=0A---=
 a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3581,6 +3581,9 =
@@ long register_guest_nmi_callback(unsigne=0A     struct domain *d =3D =
v->domain;=0A     struct trap_info *t =3D &v->arch.pv_vcpu.trap_ctxt[TRAP_n=
mi];=0A =0A+    if ( !is_canonical_address(address) )=0A+        return =
-EINVAL;=0A+=0A     t->vector  =3D TRAP_nmi;=0A     t->flags   =3D 0;=0A   =
  t->cs      =3D (is_pv_32on64_domain(d) ?=0A@@ -3708,6 +3711,9 @@ long =
do_set_trap_table(XEN_GUEST_HANDLE(=0A         if ( cur.address =3D=3D 0 =
)=0A             break;=0A =0A+        if ( !is_canonical_address(cur.addre=
ss) )=0A+            return -EINVAL;=0A+=0A         fixup_guest_code_select=
or(curr->domain, cur.cs);=0A =0A         memcpy(&dst[cur.vector], &cur, =
sizeof(cur));=0A
--=__PartB9972323.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

--=__PartB9972323.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 13 10:02:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SekOa-0008WK-Hy; Wed, 13 Jun 2012 10:01: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 1SekOY-0008WF-2o
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:01:46 +0000
Received: from [85.158.143.99:5185] by server-2.bemta-4.messagelabs.com id
	45/A8-17938-90568DF4; Wed, 13 Jun 2012 10:01:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339581704!32594757!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10823 invoked from network); 13 Jun 2012 10:01:44 -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; 13 Jun 2012 10:01:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 11:01:43 +0100
Message-Id: <4FD881530200007800089ACB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 11:02:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB9972323.0__="
Subject: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses to
 be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartB9972323.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than deferring the detection of these to the point where they
get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
to be raised by IRET, which invokes the guest's [fragile] fail-safe
callback), don't even allow such to be set.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -736,6 +736,14 @@ int arch_set_info_guest(
     {
         if ( !compat )
         {
+#ifdef __x86_64__
+            if ( !is_canonical_address(c.nat->user_regs.eip) ||
+                 !is_canonical_address(c.nat->event_callback_eip) ||
+                 !is_canonical_address(c.nat->syscall_callback_eip) ||
+                 !is_canonical_address(c.nat->failsafe_callback_eip) )
+                return -EINVAL;
+#endif
+
             fixup_guest_stack_selector(d, c.nat->user_regs.ss);
             fixup_guest_stack_selector(d, c.nat->kernel_ss);
             fixup_guest_code_selector(d, c.nat->user_regs.cs);
@@ -745,7 +753,11 @@ int arch_set_info_guest(
 #endif
=20
             for ( i =3D 0; i < 256; i++ )
+            {
+                if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
+                    return -EINVAL;
                 fixup_guest_code_selector(d, c.nat->trap_ctxt[i].cs);
+            }
=20
             /* LDT safety checks. */
             if ( ((c.nat->ldt_base & (PAGE_SIZE-1)) !=3D 0) ||
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1033,6 +1033,9 @@ long arch_do_domctl(
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
             {
+                if ( !is_canonical_address(evc->sysenter_callback_eip) ||
+                     !is_canonical_address(evc->syscall32_callback_eip) )
+                    goto ext_vcpucontext_out;
                 fixup_guest_code_selector(d, evc->sysenter_callback_cs);
                 v->arch.pv_vcpu.sysenter_callback_cs      =3D
                     evc->sysenter_callback_cs;
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3581,6 +3581,9 @@ long register_guest_nmi_callback(unsigne
     struct domain *d =3D v->domain;
     struct trap_info *t =3D &v->arch.pv_vcpu.trap_ctxt[TRAP_nmi];
=20
+    if ( !is_canonical_address(address) )
+        return -EINVAL;
+
     t->vector  =3D TRAP_nmi;
     t->flags   =3D 0;
     t->cs      =3D (is_pv_32on64_domain(d) ?
@@ -3708,6 +3711,9 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
         if ( cur.address =3D=3D 0 )
             break;
=20
+        if ( !is_canonical_address(cur.address) )
+            return -EINVAL;
+
         fixup_guest_code_selector(curr->domain, cur.cs);
=20
         memcpy(&dst[cur.vector], &cur, sizeof(cur));




--=__PartB9972323.0__=
Content-Type: text/plain; name="x86_64-canonical-checks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-canonical-checks.patch"

x86-64: don't allow non-canonical addresses to be set for any callback=0A=
=0ARather than deferring the detection of these to the point where =
they=0Aget actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a =
#GP=0Ato be raised by IRET, which invokes the guest's [fragile] =
fail-safe=0Acallback), don't even allow such to be set.=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@@ -736,6 +736,14 @@ int arch_set_info_guest(=0A =
    {=0A         if ( !compat )=0A         {=0A+#ifdef __x86_64__=0A+      =
      if ( !is_canonical_address(c.nat->user_regs.eip) ||=0A+              =
   !is_canonical_address(c.nat->event_callback_eip) ||=0A+                 =
!is_canonical_address(c.nat->syscall_callback_eip) ||=0A+                 =
!is_canonical_address(c.nat->failsafe_callback_eip) )=0A+                =
return -EINVAL;=0A+#endif=0A+=0A             fixup_guest_stack_selector(d, =
c.nat->user_regs.ss);=0A             fixup_guest_stack_selector(d, =
c.nat->kernel_ss);=0A             fixup_guest_code_selector(d, c.nat->user_=
regs.cs);=0A@@ -745,7 +753,11 @@ int arch_set_info_guest(=0A #endif=0A =0A =
            for ( i =3D 0; i < 256; i++ )=0A+            {=0A+             =
   if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )=0A+           =
         return -EINVAL;=0A                 fixup_guest_code_selector(d, =
c.nat->trap_ctxt[i].cs);=0A+            }=0A =0A             /* LDT safety =
checks. */=0A             if ( ((c.nat->ldt_base & (PAGE_SIZE-1)) !=3D 0) =
||=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/domctl.c=0A@@ =
-1033,6 +1033,9 @@ long arch_do_domctl(=0A #ifdef __x86_64__=0A            =
 if ( !is_hvm_domain(d) )=0A             {=0A+                if ( =
!is_canonical_address(evc->sysenter_callback_eip) ||=0A+                   =
  !is_canonical_address(evc->syscall32_callback_eip) )=0A+                 =
   goto ext_vcpucontext_out;=0A                 fixup_guest_code_selector(d=
, evc->sysenter_callback_cs);=0A                 v->arch.pv_vcpu.sysenter_c=
allback_cs      =3D=0A                     evc->sysenter_callback_cs;=0A---=
 a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3581,6 +3581,9 =
@@ long register_guest_nmi_callback(unsigne=0A     struct domain *d =3D =
v->domain;=0A     struct trap_info *t =3D &v->arch.pv_vcpu.trap_ctxt[TRAP_n=
mi];=0A =0A+    if ( !is_canonical_address(address) )=0A+        return =
-EINVAL;=0A+=0A     t->vector  =3D TRAP_nmi;=0A     t->flags   =3D 0;=0A   =
  t->cs      =3D (is_pv_32on64_domain(d) ?=0A@@ -3708,6 +3711,9 @@ long =
do_set_trap_table(XEN_GUEST_HANDLE(=0A         if ( cur.address =3D=3D 0 =
)=0A             break;=0A =0A+        if ( !is_canonical_address(cur.addre=
ss) )=0A+            return -EINVAL;=0A+=0A         fixup_guest_code_select=
or(curr->domain, cur.cs);=0A =0A         memcpy(&dst[cur.vector], &cur, =
sizeof(cur));=0A
--=__PartB9972323.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

--=__PartB9972323.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 13 10:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1SekQU-0000BB-1X; Wed, 13 Jun 2012 10:03:46 +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 1SekQT-0000Ar-4V
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:03:45 +0000
Received: from [85.158.143.99:32715] by server-3.bemta-4.messagelabs.com id
	11/C9-05808-08568DF4; Wed, 13 Jun 2012 10:03:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339581823!32595229!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19396 invoked from network); 13 Jun 2012 10:03:43 -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; 13 Jun 2012 10:03:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 11:03:43 +0100
Message-Id: <4FD881CB0200007800089ADB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 11:04:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part210FBBBB.0__="
Subject: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part210FBBBB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Our product management wasn't happy with the "solution" for XSA-9, and
demanded that customer systems must continue to boot. Rather than
having our and perhaps other distros carry non-trivial patches, allow
for more fine grained control (panic on boot, deny guest creation, or
merely warn) by means of a single line change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -32,8 +32,11 @@
 static char opt_famrev[14];
 string_param("cpuid_mask_cpu", opt_famrev);
=20
-static bool_t opt_allow_unsafe;
+#ifdef __x86_64__
+/* 1 =3D allow, 0 =3D don't allow guest creation, -1 =3D don't allow boot =
*/
+s8 __read_mostly opt_allow_unsafe =3D -1;
 boolean_param("allow_unsafe", opt_allow_unsafe);
+#endif
=20
 static inline void wrmsr_amd(unsigned int index, unsigned int lo,=20
 		unsigned int hi)
@@ -496,10 +499,19 @@ static void __devinit init_amd(struct cp
 		clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
=20
 #ifdef __x86_64__
-	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)
+	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
+		opt_allow_unsafe =3D 1;
+	else if (opt_allow_unsafe < 0)
 		panic("Xen will not boot on this CPU for security =
reasons.\n"
 		      "Pass \"allow_unsafe\" if you're trusting all your"
 		      " (PV) guest kernels.\n");
+	else if (!opt_allow_unsafe && c =3D=3D &boot_cpu_data)
+		printk(KERN_WARNING
+		       "*** Xen will not allow creation of DomU-s on"
+		       " this CPU for security reasons. ***\n"
+		       KERN_WARNING
+		       "*** Pass \"allow_unsafe\" if you're trusting"
+		       " all your (PV) guest kernels. ***\n");
=20
 	/* AMD CPUs do not support SYSENTER outside of legacy mode. */
 	clear_bit(X86_FEATURE_SEP, c->x86_capability);
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -55,6 +55,7 @@
 #include <asm/traps.h>
 #include <asm/nmi.h>
 #include <asm/mce.h>
+#include <asm/amd.h>
 #include <xen/numa.h>
 #include <xen/iommu.h>
 #ifdef CONFIG_COMPAT
@@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,
=20
 #else /* __x86_64__ */
=20
+    if ( d->domain_id && !is_idle_domain(d) &&
+         cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )
+    {
+        if ( !opt_allow_unsafe )
+        {
+            printk(XENLOG_G_ERR "Xen does not allow DomU creation on this =
CPU"
+                   " for security reasons.\n");
+            return -EPERM;
+        }
+        printk(XENLOG_G_WARNING
+               "Dom%d may compromise security on this CPU.\n",
+               d->domain_id);
+    }
+
     BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_pt_pages)
                  !=3D PAGE_SIZE);
     pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -147,6 +147,8 @@ struct cpuinfo_x86;
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
=20
 #ifdef __x86_64__
+extern s8 opt_allow_unsafe;
+
 void fam10h_check_enable_mmcfg(void);
 void check_enable_amd_mmconf_dmi(void);
 #endif




--=__Part210FBBBB.0__=
Content-Type: text/plain; name="x86_64-allow-unsafe-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-allow-unsafe-adjust.patch"

x86-64: refine the XSA-9 fix=0A=0AOur product management wasn't happy with =
the "solution" for XSA-9, and=0Ademanded that customer systems must =
continue to boot. Rather than=0Ahaving our and perhaps other distros carry =
non-trivial patches, allow=0Afor more fine grained control (panic on boot, =
deny guest creation, or=0Amerely warn) by means of a single line change.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/c=
pu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ -32,8 +32,11 @@=0A static =
char opt_famrev[14];=0A string_param("cpuid_mask_cpu", opt_famrev);=0A =
=0A-static bool_t opt_allow_unsafe;=0A+#ifdef __x86_64__=0A+/* 1 =3D =
allow, 0 =3D don't allow guest creation, -1 =3D don't allow boot */=0A+s8 =
__read_mostly opt_allow_unsafe =3D -1;=0A boolean_param("allow_unsafe", =
opt_allow_unsafe);=0A+#endif=0A =0A static inline void wrmsr_amd(unsigned =
int index, unsigned int lo, =0A 		unsigned int hi)=0A@@ =
-496,10 +499,19 @@ static void __devinit init_amd(struct cp=0A 		=
clear_bit(X86_FEATURE_MWAIT, c->x86_capability);=0A =0A #ifdef __x86_64__=
=0A-	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)=
=0A+	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))=0A+		=
opt_allow_unsafe =3D 1;=0A+	else if (opt_allow_unsafe < 0)=0A 		=
panic("Xen will not boot on this CPU for security reasons.\n"=0A 		=
      "Pass \"allow_unsafe\" if you're trusting all your"=0A 		   =
   " (PV) guest kernels.\n");=0A+	else if (!opt_allow_unsafe && c =
=3D=3D &boot_cpu_data)=0A+		printk(KERN_WARNING=0A+		   =
    "*** Xen will not allow creation of DomU-s on"=0A+		       " =
this CPU for security reasons. ***\n"=0A+		       KERN_WARNING=
=0A+		       "*** Pass \"allow_unsafe\" if you're trusting"=0A+	=
	       " all your (PV) guest kernels. ***\n");=0A =0A 	/* AMD =
CPUs do not support SYSENTER outside of legacy mode. */=0A 	clear_bit(X=
86_FEATURE_SEP, c->x86_capability);=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -55,6 +55,7 @@=0A #include <asm/traps.h>=0A =
#include <asm/nmi.h>=0A #include <asm/mce.h>=0A+#include <asm/amd.h>=0A =
#include <xen/numa.h>=0A #include <xen/iommu.h>=0A #ifdef CONFIG_COMPAT=0A@=
@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,=0A =0A #else =
/* __x86_64__ */=0A =0A+    if ( d->domain_id && !is_idle_domain(d) &&=0A+ =
        cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )=0A+    =
{=0A+        if ( !opt_allow_unsafe )=0A+        {=0A+            =
printk(XENLOG_G_ERR "Xen does not allow DomU creation on this CPU"=0A+     =
              " for security reasons.\n");=0A+            return -EPERM;=0A=
+        }=0A+        printk(XENLOG_G_WARNING=0A+               "Dom%d may =
compromise security on this CPU.\n",=0A+               d->domain_id);=0A+  =
  }=0A+=0A     BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_=
pt_pages)=0A                  !=3D PAGE_SIZE);=0A     pg =3D alloc_domheap_=
page(NULL, MEMF_node(domain_to_node(d)));=0A--- a/xen/include/asm-x86/amd.h=
=0A+++ b/xen/include/asm-x86/amd.h=0A@@ -147,6 +147,8 @@ struct cpuinfo_x86=
;=0A int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);=0A =0A =
#ifdef __x86_64__=0A+extern s8 opt_allow_unsafe;=0A+=0A void fam10h_check_e=
nable_mmcfg(void);=0A void check_enable_amd_mmconf_dmi(void);=0A #endif=0A
--=__Part210FBBBB.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

--=__Part210FBBBB.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 13 10:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1SekQU-0000BB-1X; Wed, 13 Jun 2012 10:03:46 +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 1SekQT-0000Ar-4V
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:03:45 +0000
Received: from [85.158.143.99:32715] by server-3.bemta-4.messagelabs.com id
	11/C9-05808-08568DF4; Wed, 13 Jun 2012 10:03:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339581823!32595229!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19396 invoked from network); 13 Jun 2012 10:03:43 -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; 13 Jun 2012 10:03:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 11:03:43 +0100
Message-Id: <4FD881CB0200007800089ADB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 11:04:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part210FBBBB.0__="
Subject: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part210FBBBB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Our product management wasn't happy with the "solution" for XSA-9, and
demanded that customer systems must continue to boot. Rather than
having our and perhaps other distros carry non-trivial patches, allow
for more fine grained control (panic on boot, deny guest creation, or
merely warn) by means of a single line change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -32,8 +32,11 @@
 static char opt_famrev[14];
 string_param("cpuid_mask_cpu", opt_famrev);
=20
-static bool_t opt_allow_unsafe;
+#ifdef __x86_64__
+/* 1 =3D allow, 0 =3D don't allow guest creation, -1 =3D don't allow boot =
*/
+s8 __read_mostly opt_allow_unsafe =3D -1;
 boolean_param("allow_unsafe", opt_allow_unsafe);
+#endif
=20
 static inline void wrmsr_amd(unsigned int index, unsigned int lo,=20
 		unsigned int hi)
@@ -496,10 +499,19 @@ static void __devinit init_amd(struct cp
 		clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
=20
 #ifdef __x86_64__
-	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)
+	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
+		opt_allow_unsafe =3D 1;
+	else if (opt_allow_unsafe < 0)
 		panic("Xen will not boot on this CPU for security =
reasons.\n"
 		      "Pass \"allow_unsafe\" if you're trusting all your"
 		      " (PV) guest kernels.\n");
+	else if (!opt_allow_unsafe && c =3D=3D &boot_cpu_data)
+		printk(KERN_WARNING
+		       "*** Xen will not allow creation of DomU-s on"
+		       " this CPU for security reasons. ***\n"
+		       KERN_WARNING
+		       "*** Pass \"allow_unsafe\" if you're trusting"
+		       " all your (PV) guest kernels. ***\n");
=20
 	/* AMD CPUs do not support SYSENTER outside of legacy mode. */
 	clear_bit(X86_FEATURE_SEP, c->x86_capability);
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -55,6 +55,7 @@
 #include <asm/traps.h>
 #include <asm/nmi.h>
 #include <asm/mce.h>
+#include <asm/amd.h>
 #include <xen/numa.h>
 #include <xen/iommu.h>
 #ifdef CONFIG_COMPAT
@@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,
=20
 #else /* __x86_64__ */
=20
+    if ( d->domain_id && !is_idle_domain(d) &&
+         cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )
+    {
+        if ( !opt_allow_unsafe )
+        {
+            printk(XENLOG_G_ERR "Xen does not allow DomU creation on this =
CPU"
+                   " for security reasons.\n");
+            return -EPERM;
+        }
+        printk(XENLOG_G_WARNING
+               "Dom%d may compromise security on this CPU.\n",
+               d->domain_id);
+    }
+
     BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_pt_pages)
                  !=3D PAGE_SIZE);
     pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -147,6 +147,8 @@ struct cpuinfo_x86;
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
=20
 #ifdef __x86_64__
+extern s8 opt_allow_unsafe;
+
 void fam10h_check_enable_mmcfg(void);
 void check_enable_amd_mmconf_dmi(void);
 #endif




--=__Part210FBBBB.0__=
Content-Type: text/plain; name="x86_64-allow-unsafe-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-allow-unsafe-adjust.patch"

x86-64: refine the XSA-9 fix=0A=0AOur product management wasn't happy with =
the "solution" for XSA-9, and=0Ademanded that customer systems must =
continue to boot. Rather than=0Ahaving our and perhaps other distros carry =
non-trivial patches, allow=0Afor more fine grained control (panic on boot, =
deny guest creation, or=0Amerely warn) by means of a single line change.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/c=
pu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ -32,8 +32,11 @@=0A static =
char opt_famrev[14];=0A string_param("cpuid_mask_cpu", opt_famrev);=0A =
=0A-static bool_t opt_allow_unsafe;=0A+#ifdef __x86_64__=0A+/* 1 =3D =
allow, 0 =3D don't allow guest creation, -1 =3D don't allow boot */=0A+s8 =
__read_mostly opt_allow_unsafe =3D -1;=0A boolean_param("allow_unsafe", =
opt_allow_unsafe);=0A+#endif=0A =0A static inline void wrmsr_amd(unsigned =
int index, unsigned int lo, =0A 		unsigned int hi)=0A@@ =
-496,10 +499,19 @@ static void __devinit init_amd(struct cp=0A 		=
clear_bit(X86_FEATURE_MWAIT, c->x86_capability);=0A =0A #ifdef __x86_64__=
=0A-	if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)=
=0A+	if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))=0A+		=
opt_allow_unsafe =3D 1;=0A+	else if (opt_allow_unsafe < 0)=0A 		=
panic("Xen will not boot on this CPU for security reasons.\n"=0A 		=
      "Pass \"allow_unsafe\" if you're trusting all your"=0A 		   =
   " (PV) guest kernels.\n");=0A+	else if (!opt_allow_unsafe && c =
=3D=3D &boot_cpu_data)=0A+		printk(KERN_WARNING=0A+		   =
    "*** Xen will not allow creation of DomU-s on"=0A+		       " =
this CPU for security reasons. ***\n"=0A+		       KERN_WARNING=
=0A+		       "*** Pass \"allow_unsafe\" if you're trusting"=0A+	=
	       " all your (PV) guest kernels. ***\n");=0A =0A 	/* AMD =
CPUs do not support SYSENTER outside of legacy mode. */=0A 	clear_bit(X=
86_FEATURE_SEP, c->x86_capability);=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -55,6 +55,7 @@=0A #include <asm/traps.h>=0A =
#include <asm/nmi.h>=0A #include <asm/mce.h>=0A+#include <asm/amd.h>=0A =
#include <xen/numa.h>=0A #include <xen/iommu.h>=0A #ifdef CONFIG_COMPAT=0A@=
@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,=0A =0A #else =
/* __x86_64__ */=0A =0A+    if ( d->domain_id && !is_idle_domain(d) &&=0A+ =
        cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )=0A+    =
{=0A+        if ( !opt_allow_unsafe )=0A+        {=0A+            =
printk(XENLOG_G_ERR "Xen does not allow DomU creation on this CPU"=0A+     =
              " for security reasons.\n");=0A+            return -EPERM;=0A=
+        }=0A+        printk(XENLOG_G_WARNING=0A+               "Dom%d may =
compromise security on this CPU.\n",=0A+               d->domain_id);=0A+  =
  }=0A+=0A     BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_=
pt_pages)=0A                  !=3D PAGE_SIZE);=0A     pg =3D alloc_domheap_=
page(NULL, MEMF_node(domain_to_node(d)));=0A--- a/xen/include/asm-x86/amd.h=
=0A+++ b/xen/include/asm-x86/amd.h=0A@@ -147,6 +147,8 @@ struct cpuinfo_x86=
;=0A int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);=0A =0A =
#ifdef __x86_64__=0A+extern s8 opt_allow_unsafe;=0A+=0A void fam10h_check_e=
nable_mmcfg(void);=0A void check_enable_amd_mmconf_dmi(void);=0A #endif=0A
--=__Part210FBBBB.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

--=__Part210FBBBB.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 13 10:22:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:22: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 1SekiZ-0000ic-M5; Wed, 13 Jun 2012 10:22: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 1SekiX-0000iM-De
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 10:22:25 +0000
Received: from [193.109.254.147:10105] by server-5.bemta-14.messagelabs.com id
	92/CA-31398-0E968DF4; Wed, 13 Jun 2012 10:22:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339582941!9469374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA4NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4713 invoked from network); 13 Jun 2012 10:22:22 -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;
	13 Jun 2012 10:22:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330923600"; d="scan'208";a="27891525"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 06:21:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 06:21:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SekhF-0007S6-Fw;
	Wed, 13 Jun 2012 11:21:05 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 13 Jun 2012 11:20:45 +0100
Message-ID: <1339582845-25659-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] x86/mm: remove arch-specific
	pmdp_get_and_clear() 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

From: David Vrabel <david.vrabel@citrix.com>

Similar to the removal of the x86 specific ptep_get_and_clear(), do
the same for pmdp_get_and_clear().  The reasoning for this is the
same.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/pgtable-2level.h |    9 ---------
 arch/x86/include/asm/pgtable-3level.h |   23 -----------------------
 arch/x86/include/asm/pgtable.h        |   17 -----------------
 arch/x86/include/asm/pgtable_64.h     |   13 -------------
 4 files changed, 0 insertions(+), 62 deletions(-)

diff --git a/arch/x86/include/asm/pgtable-2level.h b/arch/x86/include/asm/pgtable-2level.h
index be7c20e..9b08339 100644
--- a/arch/x86/include/asm/pgtable-2level.h
+++ b/arch/x86/include/asm/pgtable-2level.h
@@ -37,15 +37,6 @@ static inline void native_pte_clear(struct mm_struct *mm,
 	*xp = native_make_pte(0);
 }
 
-#ifdef CONFIG_SMP
-static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
-{
-	return __pmd(xchg((pmdval_t *)xp, 0));
-}
-#else
-#define native_pmdp_get_and_clear(xp) native_local_pmdp_get_and_clear(xp)
-#endif
-
 /*
  * Bits _PAGE_BIT_PRESENT, _PAGE_BIT_FILE and _PAGE_BIT_PROTNONE are taken,
  * split up the 29 bits of offset into this range:
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index 42101e9..f081699 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -133,29 +133,6 @@ static inline void pud_clear(pud_t *pudp)
 	 */
 }
 
-#ifdef CONFIG_SMP
-union split_pmd {
-	struct {
-		u32 pmd_low;
-		u32 pmd_high;
-	};
-	pmd_t pmd;
-};
-static inline pmd_t native_pmdp_get_and_clear(pmd_t *pmdp)
-{
-	union split_pmd res, *orig = (union split_pmd *)pmdp;
-
-	/* xchg acts as a barrier before setting of the high bits */
-	res.pmd_low = xchg(&orig->pmd_low, 0);
-	res.pmd_high = orig->pmd_high;
-	orig->pmd_high = 0;
-
-	return res.pmd;
-}
-#else
-#define native_pmdp_get_and_clear(xp) native_local_pmdp_get_and_clear(xp)
-#endif
-
 /*
  * Bits 0, 6 and 7 are taken in the low part of the pte,
  * put the 32 bits of offset into the high part.
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 4413bed..34f576c 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -598,14 +598,6 @@ static inline int pgd_none(pgd_t pgd)
 
 extern int direct_gbpages;
 
-static inline pmd_t native_local_pmdp_get_and_clear(pmd_t *pmdp)
-{
-	pmd_t res = *pmdp;
-
-	native_pmd_clear(pmdp);
-	return res;
-}
-
 static inline void native_set_pte_at(struct mm_struct *mm, unsigned long addr,
 				     pte_t *ptep , pte_t pte)
 {
@@ -694,15 +686,6 @@ static inline int pmd_write(pmd_t pmd)
 	return pmd_flags(pmd) & _PAGE_RW;
 }
 
-#define __HAVE_ARCH_PMDP_GET_AND_CLEAR
-static inline pmd_t pmdp_get_and_clear(struct mm_struct *mm, unsigned long addr,
-				       pmd_t *pmdp)
-{
-	pmd_t pmd = native_pmdp_get_and_clear(pmdp);
-	pmd_update(mm, addr, pmdp);
-	return pmd;
-}
-
 #define __HAVE_ARCH_PMDP_SET_WRPROTECT
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
 				      unsigned long addr, pmd_t *pmdp)
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index cc12d27..92eb013 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -69,19 +69,6 @@ static inline void native_pmd_clear(pmd_t *pmd)
 	native_set_pmd(pmd, native_make_pmd(0));
 }
 
-static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
-{
-#ifdef CONFIG_SMP
-	return native_make_pmd(xchg(&xp->pmd, 0));
-#else
-	/* native_local_pmdp_get_and_clear,
-	   but duplicated because of cyclic dependency */
-	pmd_t ret = *xp;
-	native_pmd_clear(xp);
-	return ret;
-#endif
-}
-
 static inline void native_set_pud(pud_t *pudp, pud_t pud)
 {
 	*pudp = pud;
-- 
1.7.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 Jun 13 10:22:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:22: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 1SekiZ-0000ic-M5; Wed, 13 Jun 2012 10:22: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 1SekiX-0000iM-De
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 10:22:25 +0000
Received: from [193.109.254.147:10105] by server-5.bemta-14.messagelabs.com id
	92/CA-31398-0E968DF4; Wed, 13 Jun 2012 10:22:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339582941!9469374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA4NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4713 invoked from network); 13 Jun 2012 10:22:22 -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;
	13 Jun 2012 10:22:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330923600"; d="scan'208";a="27891525"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 06:21:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 06:21:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SekhF-0007S6-Fw;
	Wed, 13 Jun 2012 11:21:05 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 13 Jun 2012 11:20:45 +0100
Message-ID: <1339582845-25659-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] x86/mm: remove arch-specific
	pmdp_get_and_clear() 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

From: David Vrabel <david.vrabel@citrix.com>

Similar to the removal of the x86 specific ptep_get_and_clear(), do
the same for pmdp_get_and_clear().  The reasoning for this is the
same.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/pgtable-2level.h |    9 ---------
 arch/x86/include/asm/pgtable-3level.h |   23 -----------------------
 arch/x86/include/asm/pgtable.h        |   17 -----------------
 arch/x86/include/asm/pgtable_64.h     |   13 -------------
 4 files changed, 0 insertions(+), 62 deletions(-)

diff --git a/arch/x86/include/asm/pgtable-2level.h b/arch/x86/include/asm/pgtable-2level.h
index be7c20e..9b08339 100644
--- a/arch/x86/include/asm/pgtable-2level.h
+++ b/arch/x86/include/asm/pgtable-2level.h
@@ -37,15 +37,6 @@ static inline void native_pte_clear(struct mm_struct *mm,
 	*xp = native_make_pte(0);
 }
 
-#ifdef CONFIG_SMP
-static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
-{
-	return __pmd(xchg((pmdval_t *)xp, 0));
-}
-#else
-#define native_pmdp_get_and_clear(xp) native_local_pmdp_get_and_clear(xp)
-#endif
-
 /*
  * Bits _PAGE_BIT_PRESENT, _PAGE_BIT_FILE and _PAGE_BIT_PROTNONE are taken,
  * split up the 29 bits of offset into this range:
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index 42101e9..f081699 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -133,29 +133,6 @@ static inline void pud_clear(pud_t *pudp)
 	 */
 }
 
-#ifdef CONFIG_SMP
-union split_pmd {
-	struct {
-		u32 pmd_low;
-		u32 pmd_high;
-	};
-	pmd_t pmd;
-};
-static inline pmd_t native_pmdp_get_and_clear(pmd_t *pmdp)
-{
-	union split_pmd res, *orig = (union split_pmd *)pmdp;
-
-	/* xchg acts as a barrier before setting of the high bits */
-	res.pmd_low = xchg(&orig->pmd_low, 0);
-	res.pmd_high = orig->pmd_high;
-	orig->pmd_high = 0;
-
-	return res.pmd;
-}
-#else
-#define native_pmdp_get_and_clear(xp) native_local_pmdp_get_and_clear(xp)
-#endif
-
 /*
  * Bits 0, 6 and 7 are taken in the low part of the pte,
  * put the 32 bits of offset into the high part.
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 4413bed..34f576c 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -598,14 +598,6 @@ static inline int pgd_none(pgd_t pgd)
 
 extern int direct_gbpages;
 
-static inline pmd_t native_local_pmdp_get_and_clear(pmd_t *pmdp)
-{
-	pmd_t res = *pmdp;
-
-	native_pmd_clear(pmdp);
-	return res;
-}
-
 static inline void native_set_pte_at(struct mm_struct *mm, unsigned long addr,
 				     pte_t *ptep , pte_t pte)
 {
@@ -694,15 +686,6 @@ static inline int pmd_write(pmd_t pmd)
 	return pmd_flags(pmd) & _PAGE_RW;
 }
 
-#define __HAVE_ARCH_PMDP_GET_AND_CLEAR
-static inline pmd_t pmdp_get_and_clear(struct mm_struct *mm, unsigned long addr,
-				       pmd_t *pmdp)
-{
-	pmd_t pmd = native_pmdp_get_and_clear(pmdp);
-	pmd_update(mm, addr, pmdp);
-	return pmd;
-}
-
 #define __HAVE_ARCH_PMDP_SET_WRPROTECT
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
 				      unsigned long addr, pmd_t *pmdp)
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index cc12d27..92eb013 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -69,19 +69,6 @@ static inline void native_pmd_clear(pmd_t *pmd)
 	native_set_pmd(pmd, native_make_pmd(0));
 }
 
-static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
-{
-#ifdef CONFIG_SMP
-	return native_make_pmd(xchg(&xp->pmd, 0));
-#else
-	/* native_local_pmdp_get_and_clear,
-	   but duplicated because of cyclic dependency */
-	pmd_t ret = *xp;
-	native_pmd_clear(xp);
-	return ret;
-#endif
-}
-
 static inline void native_set_pud(pud_t *pudp, pud_t pud)
 {
 	*pudp = pud;
-- 
1.7.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 Jun 13 10:22:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:22: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 1Sekia-0000ij-67; Wed, 13 Jun 2012 10:22: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 1SekiY-0000iS-MR
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 10:22:26 +0000
Received: from [193.109.254.147:45770] by server-6.bemta-14.messagelabs.com id
	DA/1C-02426-2E968DF4; Wed, 13 Jun 2012 10:22:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339582941!9469374!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA4NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4800 invoked from network); 13 Jun 2012 10:22:24 -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;
	13 Jun 2012 10:22:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330923600"; d="scan'208";a="27891526"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 06:21:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 06:21:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SekhF-0007S6-Dr;
	Wed, 13 Jun 2012 11:21:05 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 13 Jun 2012 11:20:44 +0100
Message-ID: <1339582845-25659-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
	ptep_get_and_clear() 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

From: David Vrabel <david.vrabel@citrix.com>

x86 provides a ptep_get_and_clear() function instead of using the
generic implementation so it can atomically get and clear the PTE.

It is not clear why x86 has this requirement.  PTE updates are done
while the appropriate PTE lock are held, so presumably, it is an
attempt to ensure that the accessed and dirty bits of the PTE are
saved even if they have been updated by the hardware due to a
concurrent access on another CPU.

However, the atomic exchange is not sufficient for saving the dirty
bit as if there is a TLB entry for this page on another CPU then the
dirty bit may be written by that processor after the PTE is cleared
but before the TLB entry is flushed.  It is also not clear from the
Intel SDM[1] if the processor's read of the PTE and the write to set
the accessed bit are atomic or not.

With this patch the get/clear becomes a read of the PTE and call to
pte_clear() which allows the clears to be batched by some
paravirtualized guests (such as Xen guests).  This can lead to
significant performance improvements in munmap().  e.g., for Xen, a
trap-and-emulate[2] for every page becomes a hypercall for every 31
pages.

There should be no change in the performance on native or for KVM
guests.  There may be a performance regression with lguest guests as
an optimization for avoiding calling pte_update() when doing a full
teardown of an mm is removed.

As a consequence there is a slight increase of the window where a set
(by the processor) of the accessed or dirty bit may be lost.  This
shouldn't change the behaviour of user space in any meaningful way.
Any user space application accessing a mmap()'d region that is being
munmap()'d or mremap()'d is already going to have unpredicatable
behaviour -- the access may succeed, it may fault, or the write to the
mapped file may be lost.

[1] Intel Software Developer's Manual Vol 3A section 4.8 says nothing
on this.

[2] For 32-bit guests, two traps are required for every page to update
both halves of the PTE.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/pgtable-2level.h |    9 --------
 arch/x86/include/asm/pgtable-3level.h |   16 --------------
 arch/x86/include/asm/pgtable.h        |   37 ---------------------------------
 arch/x86/include/asm/pgtable_64.h     |   13 -----------
 4 files changed, 0 insertions(+), 75 deletions(-)

diff --git a/arch/x86/include/asm/pgtable-2level.h b/arch/x86/include/asm/pgtable-2level.h
index 98391db..be7c20e 100644
--- a/arch/x86/include/asm/pgtable-2level.h
+++ b/arch/x86/include/asm/pgtable-2level.h
@@ -38,15 +38,6 @@ static inline void native_pte_clear(struct mm_struct *mm,
 }
 
 #ifdef CONFIG_SMP
-static inline pte_t native_ptep_get_and_clear(pte_t *xp)
-{
-	return __pte(xchg(&xp->pte_low, 0));
-}
-#else
-#define native_ptep_get_and_clear(xp) native_local_ptep_get_and_clear(xp)
-#endif
-
-#ifdef CONFIG_SMP
 static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
 {
 	return __pmd(xchg((pmdval_t *)xp, 0));
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..42101e9 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -134,22 +134,6 @@ static inline void pud_clear(pud_t *pudp)
 }
 
 #ifdef CONFIG_SMP
-static inline pte_t native_ptep_get_and_clear(pte_t *ptep)
-{
-	pte_t res;
-
-	/* xchg acts as a barrier before the setting of the high bits */
-	res.pte_low = xchg(&ptep->pte_low, 0);
-	res.pte_high = ptep->pte_high;
-	ptep->pte_high = 0;
-
-	return res;
-}
-#else
-#define native_ptep_get_and_clear(xp) native_local_ptep_get_and_clear(xp)
-#endif
-
-#ifdef CONFIG_SMP
 union split_pmd {
 	struct {
 		u32 pmd_low;
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 49afb3f..4413bed 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -598,16 +598,6 @@ static inline int pgd_none(pgd_t pgd)
 
 extern int direct_gbpages;
 
-/* local pte updates need not use xchg for locking */
-static inline pte_t native_local_ptep_get_and_clear(pte_t *ptep)
-{
-	pte_t res = *ptep;
-
-	/* Pure native function needs no input for mm, addr */
-	native_pte_clear(NULL, 0, ptep);
-	return res;
-}
-
 static inline pmd_t native_local_pmdp_get_and_clear(pmd_t *pmdp)
 {
 	pmd_t res = *pmdp;
@@ -668,33 +658,6 @@ extern int ptep_test_and_clear_young(struct vm_area_struct *vma,
 extern int ptep_clear_flush_young(struct vm_area_struct *vma,
 				  unsigned long address, pte_t *ptep);
 
-#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
-static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
-				       pte_t *ptep)
-{
-	pte_t pte = native_ptep_get_and_clear(ptep);
-	pte_update(mm, addr, ptep);
-	return pte;
-}
-
-#define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL
-static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
-					    unsigned long addr, pte_t *ptep,
-					    int full)
-{
-	pte_t pte;
-	if (full) {
-		/*
-		 * Full address destruction in progress; paravirt does not
-		 * care about updates and native needs no locking
-		 */
-		pte = native_local_ptep_get_and_clear(ptep);
-	} else {
-		pte = ptep_get_and_clear(mm, addr, ptep);
-	}
-	return pte;
-}
-
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 static inline void ptep_set_wrprotect(struct mm_struct *mm,
 				      unsigned long addr, pte_t *ptep)
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index 975f709..cc12d27 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -69,19 +69,6 @@ static inline void native_pmd_clear(pmd_t *pmd)
 	native_set_pmd(pmd, native_make_pmd(0));
 }
 
-static inline pte_t native_ptep_get_and_clear(pte_t *xp)
-{
-#ifdef CONFIG_SMP
-	return native_make_pte(xchg(&xp->pte, 0));
-#else
-	/* native_local_ptep_get_and_clear,
-	   but duplicated because of cyclic dependency */
-	pte_t ret = *xp;
-	native_pte_clear(NULL, 0, xp);
-	return ret;
-#endif
-}
-
 static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
 {
 #ifdef CONFIG_SMP
-- 
1.7.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 Jun 13 10:22:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:22: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 1Sekia-0000ij-67; Wed, 13 Jun 2012 10:22: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 1SekiY-0000iS-MR
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 10:22:26 +0000
Received: from [193.109.254.147:45770] by server-6.bemta-14.messagelabs.com id
	DA/1C-02426-2E968DF4; Wed, 13 Jun 2012 10:22:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339582941!9469374!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA4NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4800 invoked from network); 13 Jun 2012 10:22:24 -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;
	13 Jun 2012 10:22:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330923600"; d="scan'208";a="27891526"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 06:21:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 06:21:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SekhF-0007S6-Dr;
	Wed, 13 Jun 2012 11:21:05 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 13 Jun 2012 11:20:44 +0100
Message-ID: <1339582845-25659-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
	ptep_get_and_clear() 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

From: David Vrabel <david.vrabel@citrix.com>

x86 provides a ptep_get_and_clear() function instead of using the
generic implementation so it can atomically get and clear the PTE.

It is not clear why x86 has this requirement.  PTE updates are done
while the appropriate PTE lock are held, so presumably, it is an
attempt to ensure that the accessed and dirty bits of the PTE are
saved even if they have been updated by the hardware due to a
concurrent access on another CPU.

However, the atomic exchange is not sufficient for saving the dirty
bit as if there is a TLB entry for this page on another CPU then the
dirty bit may be written by that processor after the PTE is cleared
but before the TLB entry is flushed.  It is also not clear from the
Intel SDM[1] if the processor's read of the PTE and the write to set
the accessed bit are atomic or not.

With this patch the get/clear becomes a read of the PTE and call to
pte_clear() which allows the clears to be batched by some
paravirtualized guests (such as Xen guests).  This can lead to
significant performance improvements in munmap().  e.g., for Xen, a
trap-and-emulate[2] for every page becomes a hypercall for every 31
pages.

There should be no change in the performance on native or for KVM
guests.  There may be a performance regression with lguest guests as
an optimization for avoiding calling pte_update() when doing a full
teardown of an mm is removed.

As a consequence there is a slight increase of the window where a set
(by the processor) of the accessed or dirty bit may be lost.  This
shouldn't change the behaviour of user space in any meaningful way.
Any user space application accessing a mmap()'d region that is being
munmap()'d or mremap()'d is already going to have unpredicatable
behaviour -- the access may succeed, it may fault, or the write to the
mapped file may be lost.

[1] Intel Software Developer's Manual Vol 3A section 4.8 says nothing
on this.

[2] For 32-bit guests, two traps are required for every page to update
both halves of the PTE.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/include/asm/pgtable-2level.h |    9 --------
 arch/x86/include/asm/pgtable-3level.h |   16 --------------
 arch/x86/include/asm/pgtable.h        |   37 ---------------------------------
 arch/x86/include/asm/pgtable_64.h     |   13 -----------
 4 files changed, 0 insertions(+), 75 deletions(-)

diff --git a/arch/x86/include/asm/pgtable-2level.h b/arch/x86/include/asm/pgtable-2level.h
index 98391db..be7c20e 100644
--- a/arch/x86/include/asm/pgtable-2level.h
+++ b/arch/x86/include/asm/pgtable-2level.h
@@ -38,15 +38,6 @@ static inline void native_pte_clear(struct mm_struct *mm,
 }
 
 #ifdef CONFIG_SMP
-static inline pte_t native_ptep_get_and_clear(pte_t *xp)
-{
-	return __pte(xchg(&xp->pte_low, 0));
-}
-#else
-#define native_ptep_get_and_clear(xp) native_local_ptep_get_and_clear(xp)
-#endif
-
-#ifdef CONFIG_SMP
 static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
 {
 	return __pmd(xchg((pmdval_t *)xp, 0));
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..42101e9 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -134,22 +134,6 @@ static inline void pud_clear(pud_t *pudp)
 }
 
 #ifdef CONFIG_SMP
-static inline pte_t native_ptep_get_and_clear(pte_t *ptep)
-{
-	pte_t res;
-
-	/* xchg acts as a barrier before the setting of the high bits */
-	res.pte_low = xchg(&ptep->pte_low, 0);
-	res.pte_high = ptep->pte_high;
-	ptep->pte_high = 0;
-
-	return res;
-}
-#else
-#define native_ptep_get_and_clear(xp) native_local_ptep_get_and_clear(xp)
-#endif
-
-#ifdef CONFIG_SMP
 union split_pmd {
 	struct {
 		u32 pmd_low;
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 49afb3f..4413bed 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -598,16 +598,6 @@ static inline int pgd_none(pgd_t pgd)
 
 extern int direct_gbpages;
 
-/* local pte updates need not use xchg for locking */
-static inline pte_t native_local_ptep_get_and_clear(pte_t *ptep)
-{
-	pte_t res = *ptep;
-
-	/* Pure native function needs no input for mm, addr */
-	native_pte_clear(NULL, 0, ptep);
-	return res;
-}
-
 static inline pmd_t native_local_pmdp_get_and_clear(pmd_t *pmdp)
 {
 	pmd_t res = *pmdp;
@@ -668,33 +658,6 @@ extern int ptep_test_and_clear_young(struct vm_area_struct *vma,
 extern int ptep_clear_flush_young(struct vm_area_struct *vma,
 				  unsigned long address, pte_t *ptep);
 
-#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
-static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
-				       pte_t *ptep)
-{
-	pte_t pte = native_ptep_get_and_clear(ptep);
-	pte_update(mm, addr, ptep);
-	return pte;
-}
-
-#define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL
-static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
-					    unsigned long addr, pte_t *ptep,
-					    int full)
-{
-	pte_t pte;
-	if (full) {
-		/*
-		 * Full address destruction in progress; paravirt does not
-		 * care about updates and native needs no locking
-		 */
-		pte = native_local_ptep_get_and_clear(ptep);
-	} else {
-		pte = ptep_get_and_clear(mm, addr, ptep);
-	}
-	return pte;
-}
-
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 static inline void ptep_set_wrprotect(struct mm_struct *mm,
 				      unsigned long addr, pte_t *ptep)
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index 975f709..cc12d27 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -69,19 +69,6 @@ static inline void native_pmd_clear(pmd_t *pmd)
 	native_set_pmd(pmd, native_make_pmd(0));
 }
 
-static inline pte_t native_ptep_get_and_clear(pte_t *xp)
-{
-#ifdef CONFIG_SMP
-	return native_make_pte(xchg(&xp->pte, 0));
-#else
-	/* native_local_ptep_get_and_clear,
-	   but duplicated because of cyclic dependency */
-	pte_t ret = *xp;
-	native_pte_clear(NULL, 0, xp);
-	return ret;
-#endif
-}
-
 static inline pmd_t native_pmdp_get_and_clear(pmd_t *xp)
 {
 #ifdef CONFIG_SMP
-- 
1.7.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 Jun 13 10:22:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1Sekia-0000ir-Pl; Wed, 13 Jun 2012 10:22: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 1SekiZ-0000iT-3f
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 10:22:27 +0000
Received: from [193.109.254.147:10229] by server-2.bemta-14.messagelabs.com id
	89/33-27740-2E968DF4; Wed, 13 Jun 2012 10:22:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339582944!9475977!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24871 invoked from network); 13 Jun 2012 10:22:25 -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;
	13 Jun 2012 10:22:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330923600"; d="scan'208";a="198566593"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 06:21:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 06:21:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SekhF-0007S6-Co;
	Wed, 13 Jun 2012 11:21:05 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 13 Jun 2012 11:20:43 +0100
Message-ID: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
	get-and-clear 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

This series removes the x86-specific implementation of
ptep_get_and_clear() and pmdp_get_and_clear().

The principal reason for this is it allows Xen paravitualized guests
to batch the PTE clears which is a significant performance
optimization of munmap() and mremap() -- the number of entries into
the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
guests) for munmap().

There may be minimal gains on native and KVM guests due to the removal
of the locked xchg.

Removal of arch-specific functions where generic ones are suitable
seems to be a generally useful thing to me.

The full reasoning for why this is safe is included in the commit
message of patch 1 but to summarize.  The atomic get-and-clear does
not guarantee that the latest dirty/accessed bits are returned as TLB
as there is a still a window after the get-and-clear and before the
TLB flush that the bits may be updated on other processors.  So, user
space applications accessing pages that are being unmapped or remapped
already have unpredictable behaviour.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:22:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1Sekia-0000ir-Pl; Wed, 13 Jun 2012 10:22: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 1SekiZ-0000iT-3f
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 10:22:27 +0000
Received: from [193.109.254.147:10229] by server-2.bemta-14.messagelabs.com id
	89/33-27740-2E968DF4; Wed, 13 Jun 2012 10:22:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339582944!9475977!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24871 invoked from network); 13 Jun 2012 10:22:25 -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;
	13 Jun 2012 10:22:25 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330923600"; d="scan'208";a="198566593"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 06:21:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 06:21:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1SekhF-0007S6-Co;
	Wed, 13 Jun 2012 11:21:05 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 13 Jun 2012 11:20:43 +0100
Message-ID: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
	get-and-clear 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

This series removes the x86-specific implementation of
ptep_get_and_clear() and pmdp_get_and_clear().

The principal reason for this is it allows Xen paravitualized guests
to batch the PTE clears which is a significant performance
optimization of munmap() and mremap() -- the number of entries into
the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
guests) for munmap().

There may be minimal gains on native and KVM guests due to the removal
of the locked xchg.

Removal of arch-specific functions where generic ones are suitable
seems to be a generally useful thing to me.

The full reasoning for why this is safe is included in the commit
message of patch 1 but to summarize.  The atomic get-and-clear does
not guarantee that the latest dirty/accessed bits are returned as TLB
as there is a still a window after the get-and-clear and before the
TLB flush that the bits may be updated on other processors.  So, user
space applications accessing pages that are being unmapped or remapped
already have unpredictable behaviour.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:23:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1Sekiz-0000nh-DI; Wed, 13 Jun 2012 10:22: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 1Sekiy-0000nR-KC
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:22:52 +0000
Received: from [85.158.143.35:58755] by server-3.bemta-4.messagelabs.com id
	A5/7F-05808-BF968DF4; Wed, 13 Jun 2012 10:22:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339582971!16048496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14276 invoked from network); 13 Jun 2012 10:22:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12991418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:22:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:22:50 +0100
Message-ID: <1339582969.24104.175.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 11:22:49 +0100
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > This is v3 of my series to asyncify save/restore, rebased to current
> > tip, retested, and with all comments addressed.
> 
> There's quite a lot of combinations which need testing here (PV, HVM,
> HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> 
> I tried a simple localhost migrate of a PV guest and:
>         # xl -vvv migrate d32-1 localhost
>         migration target: Ready to receive domain.
>         Saving to migration stream new xl format (info 0x0/0x0/3541)
>         libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x8069720: create: how=(nil) callback=(nil) poller=0x80696c8
>         Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/3541)
>          Savefile contains xl domain config
>         libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=2 toolstack data size=8
>         libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x8069720: inprogress: poller=0x80696c8, flags=i
>         libxl-save-helper: debug: starting save: Success
>         xc: detail: Had 0 unexplained entries in p2m table
>         xc: Saving memory: iter 0 (last sent 0 skipped 0): 0/131072    0%
>         
> at which point it appears to just stop.
> 
>         # strace -p 2872 # /usr/lib/xen/bin/libxl-save-helper --save-domain 8 2 0 0 1 0 0 12 8 72
>         Process 2872 attached - interrupt to quit
>         write(8, 0xb5d31000, 1974272^C <unfinished ...>
>         Process 2872 detached
>         # strace -p 2866 # /usr/lib/xen/bin/libxl-save-helper --restore-domain 0 3 1 0 2 0 0 1 0 0 0

The first zero here is restore_fd, I think. But I read in the comment in
the helper:
        > + * The helper talks on stdin and stdout, in binary in machine
        > + * endianness.  The helper speaks first, and only when it has a
        > + * callback to make.  It writes a 16-bit number being the message
        > + * length, and then the message body.

So restore_fd == stdin => running two protocols over the same fd?

>         Process 2866 attached - interrupt to quit
>         read(0, ^C <unfinished ...>
>         # strace -p 4070 # xl -vvv migrate d32-1 localhost
>         Process 4070 attached - interrupt to quit
>         restart_syscall(<... resuming interrupted call ...>
>         # strace -p 4074 # xl migrate-receive
>         Process 4074 attached - interrupt to quit
>         restart_syscall(<... resuming interrupted call ...>
> 
> So the saver seems to be blocked writing to fd 8, which is argv[1] == io_fd.
> 
> Also FWIW:
>         # xl list
>         Name                                        ID   Mem VCPUs	State	Time(s)
>         Domain-0                                     0   511     4     r-----      24.5
>         d32-1                                        2   128     4     -b----       0.4
>         d32-1--incoming                              3     0     0     --p---       0.0
> 
> /var/log/xen/xl-d32-1.log is just "Waiting for domain d32-1 (domid 9) to
> die [pid 4045]" (nb: this was a newer attempt than the ones above, to be
> sure I was looking at the right log, so the domid's don't match, 9 ==
> d32-1 not the incoming one). There is no xl log for the incoming domain.
> 
> Also it'd be worth pinging/CCing Shriram next time to get him to sanity
> test the Remus cases too.
> 
> I'm in the middle of reviewing #5/19 (the meat), I'll keep going
> although I doubt I'll spot the cause of 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 Wed Jun 13 10:23:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1Sekiz-0000nh-DI; Wed, 13 Jun 2012 10:22: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 1Sekiy-0000nR-KC
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:22:52 +0000
Received: from [85.158.143.35:58755] by server-3.bemta-4.messagelabs.com id
	A5/7F-05808-BF968DF4; Wed, 13 Jun 2012 10:22:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339582971!16048496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14276 invoked from network); 13 Jun 2012 10:22:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12991418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:22:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:22:50 +0100
Message-ID: <1339582969.24104.175.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 11:22:49 +0100
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > This is v3 of my series to asyncify save/restore, rebased to current
> > tip, retested, and with all comments addressed.
> 
> There's quite a lot of combinations which need testing here (PV, HVM,
> HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> 
> I tried a simple localhost migrate of a PV guest and:
>         # xl -vvv migrate d32-1 localhost
>         migration target: Ready to receive domain.
>         Saving to migration stream new xl format (info 0x0/0x0/3541)
>         libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x8069720: create: how=(nil) callback=(nil) poller=0x80696c8
>         Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/3541)
>          Savefile contains xl domain config
>         libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=2 toolstack data size=8
>         libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x8069720: inprogress: poller=0x80696c8, flags=i
>         libxl-save-helper: debug: starting save: Success
>         xc: detail: Had 0 unexplained entries in p2m table
>         xc: Saving memory: iter 0 (last sent 0 skipped 0): 0/131072    0%
>         
> at which point it appears to just stop.
> 
>         # strace -p 2872 # /usr/lib/xen/bin/libxl-save-helper --save-domain 8 2 0 0 1 0 0 12 8 72
>         Process 2872 attached - interrupt to quit
>         write(8, 0xb5d31000, 1974272^C <unfinished ...>
>         Process 2872 detached
>         # strace -p 2866 # /usr/lib/xen/bin/libxl-save-helper --restore-domain 0 3 1 0 2 0 0 1 0 0 0

The first zero here is restore_fd, I think. But I read in the comment in
the helper:
        > + * The helper talks on stdin and stdout, in binary in machine
        > + * endianness.  The helper speaks first, and only when it has a
        > + * callback to make.  It writes a 16-bit number being the message
        > + * length, and then the message body.

So restore_fd == stdin => running two protocols over the same fd?

>         Process 2866 attached - interrupt to quit
>         read(0, ^C <unfinished ...>
>         # strace -p 4070 # xl -vvv migrate d32-1 localhost
>         Process 4070 attached - interrupt to quit
>         restart_syscall(<... resuming interrupted call ...>
>         # strace -p 4074 # xl migrate-receive
>         Process 4074 attached - interrupt to quit
>         restart_syscall(<... resuming interrupted call ...>
> 
> So the saver seems to be blocked writing to fd 8, which is argv[1] == io_fd.
> 
> Also FWIW:
>         # xl list
>         Name                                        ID   Mem VCPUs	State	Time(s)
>         Domain-0                                     0   511     4     r-----      24.5
>         d32-1                                        2   128     4     -b----       0.4
>         d32-1--incoming                              3     0     0     --p---       0.0
> 
> /var/log/xen/xl-d32-1.log is just "Waiting for domain d32-1 (domid 9) to
> die [pid 4045]" (nb: this was a newer attempt than the ones above, to be
> sure I was looking at the right log, so the domid's don't match, 9 ==
> d32-1 not the incoming one). There is no xl log for the incoming domain.
> 
> Also it'd be worth pinging/CCing Shriram next time to get him to sanity
> test the Remus cases too.
> 
> I'm in the middle of reviewing #5/19 (the meat), I'll keep going
> although I doubt I'll spot the cause of 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 Wed Jun 13 10:31:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1Sekqf-0001MV-CT; Wed, 13 Jun 2012 10:30: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 1Sekqe-0001MN-CL
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:30:48 +0000
Received: from [193.109.254.147:6172] by server-2.bemta-14.messagelabs.com id
	BF/8C-27740-4DB68DF4; Wed, 13 Jun 2012 10:30:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339583443!2670613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7872 invoked from network); 13 Jun 2012 10:30:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:30:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12991629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:30:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:30:43 +0100
Message-ID: <1339583442.24104.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 11:30:42 +0100
In-Reply-To: <1339582969.24104.175.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 11:22 +0100, Ian Campbell wrote:
> On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > > This is v3 of my series to asyncify save/restore, rebased to current
> > > tip, retested, and with all comments addressed.
> > 
> > There's quite a lot of combinations which need testing here (PV, HVM,
> > HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> > 
> > I tried a simple localhost migrate of a PV guest and:
> >         # xl -vvv migrate d32-1 localhost
> >         migration target: Ready to receive domain.
> >         Saving to migration stream new xl format (info 0x0/0x0/3541)
> >         libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x8069720: create: how=(nil) callback=(nil) poller=0x80696c8
> >         Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/3541)
> >          Savefile contains xl domain config
> >         libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=2 toolstack data size=8
> >         libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x8069720: inprogress: poller=0x80696c8, flags=i
> >         libxl-save-helper: debug: starting save: Success
> >         xc: detail: Had 0 unexplained entries in p2m table
> >         xc: Saving memory: iter 0 (last sent 0 skipped 0): 0/131072    0%
> >         
> > at which point it appears to just stop.
> > 
> >         # strace -p 2872 # /usr/lib/xen/bin/libxl-save-helper --save-domain 8 2 0 0 1 0 0 12 8 72
> >         Process 2872 attached - interrupt to quit
> >         write(8, 0xb5d31000, 1974272^C <unfinished ...>
> >         Process 2872 detached
> >         # strace -p 2866 # /usr/lib/xen/bin/libxl-save-helper --restore-domain 0 3 1 0 2 0 0 1 0 0 0
> 
> The first zero here is restore_fd, I think. But I read in the comment in
> the helper:
>         > + * The helper talks on stdin and stdout, in binary in machine
>         > + * endianness.  The helper speaks first, and only when it has a
>         > + * callback to make.  It writes a 16-bit number being the message
>         > + * length, and then the message body.
> 
> So restore_fd == stdin => running two protocols over the same fd?

Oh, right, migrate-receive takes the migration fd on stdin doesn't it,
so that's where it comes from. I still suspect it is wrong. Might need
to dup the input onto a safe fd?

BTW, since I've been ctrl-c'ing "xl migrate" a bunch I noticed that we
seem to leak an "xl migrate-receive" and the restore side helper
process. Probably pre-existing but I thought it worth mentioning.

> 
> >         Process 2866 attached - interrupt to quit
> >         read(0, ^C <unfinished ...>
> >         # strace -p 4070 # xl -vvv migrate d32-1 localhost
> >         Process 4070 attached - interrupt to quit
> >         restart_syscall(<... resuming interrupted call ...>
> >         # strace -p 4074 # xl migrate-receive
> >         Process 4074 attached - interrupt to quit
> >         restart_syscall(<... resuming interrupted call ...>
> > 
> > So the saver seems to be blocked writing to fd 8, which is argv[1] == io_fd.
> > 
> > Also FWIW:
> >         # xl list
> >         Name                                        ID   Mem VCPUs	State	Time(s)
> >         Domain-0                                     0   511     4     r-----      24.5
> >         d32-1                                        2   128     4     -b----       0.4
> >         d32-1--incoming                              3     0     0     --p---       0.0
> > 
> > /var/log/xen/xl-d32-1.log is just "Waiting for domain d32-1 (domid 9) to
> > die [pid 4045]" (nb: this was a newer attempt than the ones above, to be
> > sure I was looking at the right log, so the domid's don't match, 9 ==
> > d32-1 not the incoming one). There is no xl log for the incoming domain.
> > 
> > Also it'd be worth pinging/CCing Shriram next time to get him to sanity
> > test the Remus cases too.
> > 
> > I'm in the middle of reviewing #5/19 (the meat), I'll keep going
> > although I doubt I'll spot the cause of 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:31:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1Sekqf-0001MV-CT; Wed, 13 Jun 2012 10:30: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 1Sekqe-0001MN-CL
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:30:48 +0000
Received: from [193.109.254.147:6172] by server-2.bemta-14.messagelabs.com id
	BF/8C-27740-4DB68DF4; Wed, 13 Jun 2012 10:30:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1339583443!2670613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7872 invoked from network); 13 Jun 2012 10:30:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:30:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12991629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:30:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:30:43 +0100
Message-ID: <1339583442.24104.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 11:30:42 +0100
In-Reply-To: <1339582969.24104.175.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 11:22 +0100, Ian Campbell wrote:
> On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > > This is v3 of my series to asyncify save/restore, rebased to current
> > > tip, retested, and with all comments addressed.
> > 
> > There's quite a lot of combinations which need testing here (PV, HVM,
> > HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> > 
> > I tried a simple localhost migrate of a PV guest and:
> >         # xl -vvv migrate d32-1 localhost
> >         migration target: Ready to receive domain.
> >         Saving to migration stream new xl format (info 0x0/0x0/3541)
> >         libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x8069720: create: how=(nil) callback=(nil) poller=0x80696c8
> >         Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/3541)
> >          Savefile contains xl domain config
> >         libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=2 toolstack data size=8
> >         libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x8069720: inprogress: poller=0x80696c8, flags=i
> >         libxl-save-helper: debug: starting save: Success
> >         xc: detail: Had 0 unexplained entries in p2m table
> >         xc: Saving memory: iter 0 (last sent 0 skipped 0): 0/131072    0%
> >         
> > at which point it appears to just stop.
> > 
> >         # strace -p 2872 # /usr/lib/xen/bin/libxl-save-helper --save-domain 8 2 0 0 1 0 0 12 8 72
> >         Process 2872 attached - interrupt to quit
> >         write(8, 0xb5d31000, 1974272^C <unfinished ...>
> >         Process 2872 detached
> >         # strace -p 2866 # /usr/lib/xen/bin/libxl-save-helper --restore-domain 0 3 1 0 2 0 0 1 0 0 0
> 
> The first zero here is restore_fd, I think. But I read in the comment in
> the helper:
>         > + * The helper talks on stdin and stdout, in binary in machine
>         > + * endianness.  The helper speaks first, and only when it has a
>         > + * callback to make.  It writes a 16-bit number being the message
>         > + * length, and then the message body.
> 
> So restore_fd == stdin => running two protocols over the same fd?

Oh, right, migrate-receive takes the migration fd on stdin doesn't it,
so that's where it comes from. I still suspect it is wrong. Might need
to dup the input onto a safe fd?

BTW, since I've been ctrl-c'ing "xl migrate" a bunch I noticed that we
seem to leak an "xl migrate-receive" and the restore side helper
process. Probably pre-existing but I thought it worth mentioning.

> 
> >         Process 2866 attached - interrupt to quit
> >         read(0, ^C <unfinished ...>
> >         # strace -p 4070 # xl -vvv migrate d32-1 localhost
> >         Process 4070 attached - interrupt to quit
> >         restart_syscall(<... resuming interrupted call ...>
> >         # strace -p 4074 # xl migrate-receive
> >         Process 4074 attached - interrupt to quit
> >         restart_syscall(<... resuming interrupted call ...>
> > 
> > So the saver seems to be blocked writing to fd 8, which is argv[1] == io_fd.
> > 
> > Also FWIW:
> >         # xl list
> >         Name                                        ID   Mem VCPUs	State	Time(s)
> >         Domain-0                                     0   511     4     r-----      24.5
> >         d32-1                                        2   128     4     -b----       0.4
> >         d32-1--incoming                              3     0     0     --p---       0.0
> > 
> > /var/log/xen/xl-d32-1.log is just "Waiting for domain d32-1 (domid 9) to
> > die [pid 4045]" (nb: this was a newer attempt than the ones above, to be
> > sure I was looking at the right log, so the domid's don't match, 9 ==
> > d32-1 not the incoming one). There is no xl log for the incoming domain.
> > 
> > Also it'd be worth pinging/CCing Shriram next time to get him to sanity
> > test the Remus cases too.
> > 
> > I'm in the middle of reviewing #5/19 (the meat), I'll keep going
> > although I doubt I'll spot the cause of 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Seky9-0001Zi-AS; Wed, 13 Jun 2012 10:38: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 1Seky7-0001Zd-Ev
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:38:31 +0000
Received: from [85.158.139.83:35355] by server-9.bemta-5.messagelabs.com id
	37/90-01069-6AD68DF4; Wed, 13 Jun 2012 10:38:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339583909!27362940!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 13 Jun 2012 10:38:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12991926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:38:29 +0100
Message-ID: <1339583907.24104.182.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 11:38:27 +0100
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > This is v3 of my series to asyncify save/restore, rebased to current
> > tip, retested, and with all comments addressed.
> 
> There's quite a lot of combinations which need testing here (PV, HVM,
> HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> 
> I tried a simple localhost migrate of a PV guest and:

As a separate issue in "xl -vvv save d32-1 /scratch/SAVE" I no longer
see the progress messages (xxx% complete etc). I saw something which
looked like support for logging progress messages so I was a bit
surprised...

The complete output is

        # xl -vvv save d32-1 /scratch/SAVE
        Saving to /scratch/SAVE new xl format (info 0x0/0x0/3541)
        libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x80696c8: create: how=(nil) callback=(nil) poller=0x8069708
        libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=14 toolstack data size=8
        libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x80696c8: inprogress: poller=0x8069708, flags=i
        libxl-save-helper: debug: starting save: Success
        libxl: debug: libxl_dom.c:798:libxl__domain_suspend_common_callback: issuing PV suspend request via XenBus control node
        libxl: debug: libxl_dom.c:802:libxl__domain_suspend_common_callback: wait for the guest to acknowledge suspend request
        libxl: debug: libxl_dom.c:849:libxl__domain_suspend_common_callback: guest acknowledged suspend request
        libxl: debug: libxl_dom.c:853:libxl__domain_suspend_common_callback: wait for the guest to suspend
        libxl: debug: libxl_dom.c:867:libxl__domain_suspend_common_callback: guest has suspended
        xc: detail: Had 0 unexplained entries in p2m table
        xc: debug: outbuf_write: 4194304 > 4177904@12599312
        xc: debug: outbuf_write: 2527232 > 2514932@14262284
        xc: debug: outbuf_write: 4194304 > 1650672@15126544
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 3424256 > 3411956@13365260
        xc: debug: outbuf_write: 753664 > 753648@16023568
        xc: detail: delta 90669ms, dom0 2%, target 0%, sent 11Mb/s, dirtied 0Mb/s 0 pages
        xc: detail: Total pages sent= 32768 (0.25x)
        xc: detail: (of which 0 were fixups)
        xc: detail: All memory is saved
        xc: detail: Save exit rc=0
        libxl-save-helper: debug: complete r=0: Success
        libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x80696c8: complete, rc=0
        libxl: debug: libxl_event.c:1406:libxl__ao__destroy: ao 0x80696c8: destroy
        libxl: debug: libxl_dm.c:1139:libxl__destroy_device_model: Device Model signaled

Restore worked BTW but was a bit spammy with:
        xc: debug: batch 1024

(maybe not your fault...)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Seky9-0001Zi-AS; Wed, 13 Jun 2012 10:38: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 1Seky7-0001Zd-Ev
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:38:31 +0000
Received: from [85.158.139.83:35355] by server-9.bemta-5.messagelabs.com id
	37/90-01069-6AD68DF4; Wed, 13 Jun 2012 10:38:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339583909!27362940!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 13 Jun 2012 10:38:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:38:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12991926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:38:29 +0100
Message-ID: <1339583907.24104.182.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 11:38:27 +0100
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > This is v3 of my series to asyncify save/restore, rebased to current
> > tip, retested, and with all comments addressed.
> 
> There's quite a lot of combinations which need testing here (PV, HVM,
> HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> 
> I tried a simple localhost migrate of a PV guest and:

As a separate issue in "xl -vvv save d32-1 /scratch/SAVE" I no longer
see the progress messages (xxx% complete etc). I saw something which
looked like support for logging progress messages so I was a bit
surprised...

The complete output is

        # xl -vvv save d32-1 /scratch/SAVE
        Saving to /scratch/SAVE new xl format (info 0x0/0x0/3541)
        libxl: debug: libxl.c:722:libxl_domain_suspend: ao 0x80696c8: create: how=(nil) callback=(nil) poller=0x8069708
        libxl: debug: libxl_dom.c:969:libxl__toolstack_save: domain=14 toolstack data size=8
        libxl: debug: libxl.c:745:libxl_domain_suspend: ao 0x80696c8: inprogress: poller=0x8069708, flags=i
        libxl-save-helper: debug: starting save: Success
        libxl: debug: libxl_dom.c:798:libxl__domain_suspend_common_callback: issuing PV suspend request via XenBus control node
        libxl: debug: libxl_dom.c:802:libxl__domain_suspend_common_callback: wait for the guest to acknowledge suspend request
        libxl: debug: libxl_dom.c:849:libxl__domain_suspend_common_callback: guest acknowledged suspend request
        libxl: debug: libxl_dom.c:853:libxl__domain_suspend_common_callback: wait for the guest to suspend
        libxl: debug: libxl_dom.c:867:libxl__domain_suspend_common_callback: guest has suspended
        xc: detail: Had 0 unexplained entries in p2m table
        xc: debug: outbuf_write: 4194304 > 4177904@12599312
        xc: debug: outbuf_write: 2527232 > 2514932@14262284
        xc: debug: outbuf_write: 4194304 > 1650672@15126544
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 4194304 > 4182004@12595212
        xc: debug: outbuf_write: 3424256 > 3411956@13365260
        xc: debug: outbuf_write: 753664 > 753648@16023568
        xc: detail: delta 90669ms, dom0 2%, target 0%, sent 11Mb/s, dirtied 0Mb/s 0 pages
        xc: detail: Total pages sent= 32768 (0.25x)
        xc: detail: (of which 0 were fixups)
        xc: detail: All memory is saved
        xc: detail: Save exit rc=0
        libxl-save-helper: debug: complete r=0: Success
        libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x80696c8: complete, rc=0
        libxl: debug: libxl_event.c:1406:libxl__ao__destroy: ao 0x80696c8: destroy
        libxl: debug: libxl_dm.c:1139:libxl__destroy_device_model: Device Model signaled

Restore worked BTW but was a bit spammy with:
        xc: debug: batch 1024

(maybe not your fault...)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sel7t-0001jO-Hw; Wed, 13 Jun 2012 10:48:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Sel7t-0001jJ-58
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:48:37 +0000
Received: from [85.158.143.99:44769] by server-2.bemta-4.messagelabs.com id
	8E/D0-17938-40078DF4; Wed, 13 Jun 2012 10:48:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339584515!27346436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22878 invoked from network); 13 Jun 2012 10:48:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:48:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 11:48:35 +0100
Date: Wed, 13 Jun 2012 11:48:13 +0100
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: <1339509935.24104.66.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 12 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > tools, blockers:
> > > 
> > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> > >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> > 
> > Patch was posted and is in upstream qemu, just needs pulling back
> > into our two clones.
> 
> Thanks. CCing Stefano to be sure he knows that...

qemu-upstream-unstable has been updated, Ian is responsible for
qemu-xen-unstable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sel7t-0001jO-Hw; Wed, 13 Jun 2012 10:48:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Sel7t-0001jJ-58
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:48:37 +0000
Received: from [85.158.143.99:44769] by server-2.bemta-4.messagelabs.com id
	8E/D0-17938-40078DF4; Wed, 13 Jun 2012 10:48:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339584515!27346436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22878 invoked from network); 13 Jun 2012 10:48:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:48:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 11:48:35 +0100
Date: Wed, 13 Jun 2012 11:48:13 +0100
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: <1339509935.24104.66.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 12 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > tools, blockers:
> > > 
> > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> > >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> > 
> > Patch was posted and is in upstream qemu, just needs pulling back
> > into our two clones.
> 
> Thanks. CCing Stefano to be sure he knows that...

qemu-upstream-unstable has been updated, Ian is responsible for
qemu-xen-unstable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:49:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sel8H-0001kw-VN; Wed, 13 Jun 2012 10:49:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sel8G-0001ko-Ig
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:49:00 +0000
Received: from [193.109.254.147:65406] by server-10.bemta-14.messagelabs.com
	id 3C/C8-25709-B1078DF4; Wed, 13 Jun 2012 10:48:59 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339584539!8684660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8727 invoked from network); 13 Jun 2012 10:48:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:48:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:48:59 +0000
Received: from boiler.cam.xci-test.com (10.80.248.209) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:48:59 +0100
Received: from jeangu by boiler.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sel8E-0008D7-OG;
	Wed, 13 Jun 2012 11:48:58 +0100
Date: Wed, 13 Jun 2012 11:48:58 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120613104858.GC23207@boiler.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607153657.GX70339@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 07/06 04:36, Tim Deegan wrote:
> At 12:40 +0100 on 07 Jun (1339072831), Tim Deegan wrote:
> > Hi, 
> > 
> > Thanks for this.
> > 
> > Overall, it looks like Xen is doing a few things here:
> >  - nameservice for registering services and finding endpoints;
> >  - ring manipulation arithmetic;
> >  - copying data; and
> >  - notifying endpoints. 
> > 
> > The shared-ring logic was able to do all of these, with a few drawbacks:
> >  - The xenstore handshake stuff is really grotty;
> >  - grant maps can cause zombie domains; and
> >  - it doesn't do many-to-one multicast.
> 
> We've just had a discussion of this in person, and from my notes the two
> things that stand out are:
> 
>  - yes, you want to do many-to-one multiplexing, in particular to 
>    avoid the server needing a ring for every client; and
>  - one reason not to use Xenstore is that there is only one Xenstore
>    page per VM and it may not be possible to safely share it with other
>    users (in particular between a BIOS/EFI user and the main OS).
> 
> The Xenstore point is understandable, and probably something that ought
> to be fixed anyway -- we have seen people run into similar problems with
> BIOS drivers for blkfront and netfront.
> 
> Using one ring for all clients raises the question of access control and
> admission control -- in particular how do you avoid DoS from
> badly-behaved clients?
> 
> And, given your concerns about sharing an OS with an uncooperative
> Xenstore client, how do you handle sharing the OS with a badly behaved
> v4v client?
> 
> If we _do_ need one ring with multiple writers, and therefore Xen needs
> to arbitrate writes, there's still room for the policy-based parts
> (controlling connection setup, for example) to live outside the
> hypervisor, openvswitch-style.
> 

Thanks for summary Tim.

Today the acl check in V4V (not part of the current patch serie) is done
for every copy by Xen. Moving the policy control outside of Xen would mean that
you still need to have a copy of the acls in Xen and the worst
thing that can happen is for the copy to get out of sync.

What do you think would be the next step going forward?

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:49:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sel8H-0001kw-VN; Wed, 13 Jun 2012 10:49:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1Sel8G-0001ko-Ig
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:49:00 +0000
Received: from [193.109.254.147:65406] by server-10.bemta-14.messagelabs.com
	id 3C/C8-25709-B1078DF4; Wed, 13 Jun 2012 10:48:59 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339584539!8684660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8727 invoked from network); 13 Jun 2012 10:48:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:48:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:48:59 +0000
Received: from boiler.cam.xci-test.com (10.80.248.209) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 11:48:59 +0100
Received: from jeangu by boiler.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>)	id 1Sel8E-0008D7-OG;
	Wed, 13 Jun 2012 11:48:58 +0100
Date: Wed, 13 Jun 2012 11:48:58 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120613104858.GC23207@boiler.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120607153657.GX70339@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 07/06 04:36, Tim Deegan wrote:
> At 12:40 +0100 on 07 Jun (1339072831), Tim Deegan wrote:
> > Hi, 
> > 
> > Thanks for this.
> > 
> > Overall, it looks like Xen is doing a few things here:
> >  - nameservice for registering services and finding endpoints;
> >  - ring manipulation arithmetic;
> >  - copying data; and
> >  - notifying endpoints. 
> > 
> > The shared-ring logic was able to do all of these, with a few drawbacks:
> >  - The xenstore handshake stuff is really grotty;
> >  - grant maps can cause zombie domains; and
> >  - it doesn't do many-to-one multicast.
> 
> We've just had a discussion of this in person, and from my notes the two
> things that stand out are:
> 
>  - yes, you want to do many-to-one multiplexing, in particular to 
>    avoid the server needing a ring for every client; and
>  - one reason not to use Xenstore is that there is only one Xenstore
>    page per VM and it may not be possible to safely share it with other
>    users (in particular between a BIOS/EFI user and the main OS).
> 
> The Xenstore point is understandable, and probably something that ought
> to be fixed anyway -- we have seen people run into similar problems with
> BIOS drivers for blkfront and netfront.
> 
> Using one ring for all clients raises the question of access control and
> admission control -- in particular how do you avoid DoS from
> badly-behaved clients?
> 
> And, given your concerns about sharing an OS with an uncooperative
> Xenstore client, how do you handle sharing the OS with a badly behaved
> v4v client?
> 
> If we _do_ need one ring with multiple writers, and therefore Xen needs
> to arbitrate writes, there's still room for the policy-based parts
> (controlling connection setup, for example) to live outside the
> hypervisor, openvswitch-style.
> 

Thanks for summary Tim.

Today the acl check in V4V (not part of the current patch serie) is done
for every copy by Xen. Moving the policy control outside of Xen would mean that
you still need to have a copy of the acls in Xen and the worst
thing that can happen is for the copy to get out of sync.

What do you think would be the next step going forward?

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:50:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sel9H-0001rk-Ij; Wed, 13 Jun 2012 10:50:03 +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 1Sel9F-0001rQ-Q8
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:50:02 +0000
Received: from [85.158.139.83:35653] by server-5.bemta-5.messagelabs.com id
	9C/BB-02722-85078DF4; Wed, 13 Jun 2012 10:50:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339584599!20222540!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxODc2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23131 invoked from network); 13 Jun 2012 10:50:00 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	13 Jun 2012 10:50:00 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 13 Jun 2012 03:49:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="111596761"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Jun 2012 03:49:59 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 13 Jun 2012 03:49:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Wed, 13 Jun 2012 18:49:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
Thread-Index: AQHNSUILOYFQl4PoQNeTRPYYZQub0Zb3/xCg
Date: Wed, 13 Jun 2012 10:49:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
	<4FD8713B0200007800089A77@nat28.tlf.novell.com>
In-Reply-To: <4FD8713B0200007800089A77@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: Keir Fraser <keir@xen.org>, "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 13.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Xen vMCE bugfix: inject vMCE# to all vcpus
>> 
>> In our test for win8 guest mce, we find a bug in that no matter what
>> SRAO/SRAR error xen inject to win8 guest, it always reboot.
>> 
>> The root cause is, current Xen vMCE logic inject vMCE# only to
>> vcpu0, this is not correct for Intel MCE (Under Intel arch, h/w
>> generate MCE# to all CPUs). 
>> 
>> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.
> 
> I see no correlation between the fix (and its description) and the
> problem at hand: Why would Win8 reboot if it doesn't receive a
> particular MCE on all CPUs? Isn't that model specific behavior?

It's not model specific. For Intel processor, MCE# is broadcast to all logical processors on the system on which the UCR errors are supported (refer Intel SDM 15.9.3.1 & 15.9.3.2). So for vMCE injection under Intel arch, it's a bug if inject vMCE# only to vcpu0.

As for why win8 reboot, I guess it need wait all cpus enter mce handler and then go ahead. If timeout fail, it will reboot. I have no win8 code, I can only infer so, and test result prove this point.
(It's reasonable of win8 doing so, as Intel's SDM suggestion, due to the potentially shared machine check MSR resources among the logical processors on the same package/core, the MCE handler may be required to synchronize with the other processors that received a machine check error and serialize access to the machine check registers when analyzing, logging and clearing the information in the machine check registers)

> 
> Furthermore I doubt that an MCE on one socket indeed causes
> MCE-s on all other sockets, not to speak of distinct NUMA nodes
> (it would already surprise me if MCE-s got broadcast across cores
> within a socket, unless they are caused by a resource shared
> across cores).

Somehow I agree. But at least currently from Intel SDM, architecturally it would broadcast.

> 
>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Jun 05 03:18:00 2012
>> +0800 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Jun 13 23:40:45
>>      2012 +0800 @@ -638,6 +638,32 @@ return rec;
>>  }
>> 
>> +static int inject_vmce(struct domain *d)
> 
> Is it really necessary to move this vendor independent function
> into a vendor specific source file?

For AMD, I'm not quite sure if inject vMCE to all vcpus is proper for its arch. I remember AMD use nmi/ single MCE#/ broadcast MCE# in their different platforms.

BTW, currently in Xen mce logic, inject_vmce() is only used by Intel mce, so I put it into Intel mce logic to avoid potential issue. Intel mce and AMD mce differs in some points (including MCE# injection), so we'd better not spool together. Only if we are totally sure some logic is safe to co-used by Intel and AMD will we put it into common mce code.

> 
>> +{
>> +    struct vcpu *v;
>> +
>> +    /* inject vMCE to all vcpus */
>> +    for_each_vcpu(d, v)
>> +    {
>> +        if ( !test_and_set_bool(v->mce_pending) &&
>> +            ((d->is_hvm) ? 1 :
>> +            guest_has_trap_callback(d, v->vcpu_id,
>> TRAP_machine_check)) ) 
> 
> Quite strange a way to say
> 
>             (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id,
> TRAP_machine_check)) 

For hvm it's OK to just set v->mce_pending. While for pv it need also check if guest callback has been registered.

> 
>> +        {
>> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d
>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>> +            vcpu_kick(v);
>> +        }
>> +        else
>> +        {
>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>> +            return -1;
> 
> Why do you bail here? This is particularly bad if v->mce_pending
> was already set on some vCPU (as that could simply mean the guest
> just didn't get around to handle the vMCE yet).

the case v->mce_pending already set while new vmce come will result in domain crash.
I don't think guest can still handle this case, e.g. under baremetal if 2nd mce occur while 1st mce have not been handled os will reboot directly.

> 
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>  static void intel_memerr_dhandler(
>>               struct mca_binfo *binfo,
>>               enum mce_result *result,
> 
> Also, how does this whole change interact with vmce_{rd,wr}msr()?
> The struct bank_entry instances live on a per-domain list, so the
> vMCE being delivered to all vCPU-s means they will all race for the
> single entry (and might erroneously access others, particularly in
> vmce_wrmsr()'s MCG_STATUS handling).

Yes, I agree.
However, recently we have done vMCE re-design work (ongoing some internal review) and would present sooner. In new approach, MSRs are per-vcpu instead of per-domain.  MSRs race issue (and the effort to make it clean) would be pointless then. So at this butfix patch, I only touch vMCE# injection itself.

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 Jun 13 10:50:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sel9H-0001rk-Ij; Wed, 13 Jun 2012 10:50:03 +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 1Sel9F-0001rQ-Q8
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:50:02 +0000
Received: from [85.158.139.83:35653] by server-5.bemta-5.messagelabs.com id
	9C/BB-02722-85078DF4; Wed, 13 Jun 2012 10:50:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339584599!20222540!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxODc2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23131 invoked from network); 13 Jun 2012 10:50:00 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	13 Jun 2012 10:50:00 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 13 Jun 2012 03:49:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="111596761"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Jun 2012 03:49:59 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 13 Jun 2012 03:49:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Wed, 13 Jun 2012 18:49:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
Thread-Index: AQHNSUILOYFQl4PoQNeTRPYYZQub0Zb3/xCg
Date: Wed, 13 Jun 2012 10:49:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
	<4FD8713B0200007800089A77@nat28.tlf.novell.com>
In-Reply-To: <4FD8713B0200007800089A77@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: Keir Fraser <keir@xen.org>, "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 13.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Xen vMCE bugfix: inject vMCE# to all vcpus
>> 
>> In our test for win8 guest mce, we find a bug in that no matter what
>> SRAO/SRAR error xen inject to win8 guest, it always reboot.
>> 
>> The root cause is, current Xen vMCE logic inject vMCE# only to
>> vcpu0, this is not correct for Intel MCE (Under Intel arch, h/w
>> generate MCE# to all CPUs). 
>> 
>> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.
> 
> I see no correlation between the fix (and its description) and the
> problem at hand: Why would Win8 reboot if it doesn't receive a
> particular MCE on all CPUs? Isn't that model specific behavior?

It's not model specific. For Intel processor, MCE# is broadcast to all logical processors on the system on which the UCR errors are supported (refer Intel SDM 15.9.3.1 & 15.9.3.2). So for vMCE injection under Intel arch, it's a bug if inject vMCE# only to vcpu0.

As for why win8 reboot, I guess it need wait all cpus enter mce handler and then go ahead. If timeout fail, it will reboot. I have no win8 code, I can only infer so, and test result prove this point.
(It's reasonable of win8 doing so, as Intel's SDM suggestion, due to the potentially shared machine check MSR resources among the logical processors on the same package/core, the MCE handler may be required to synchronize with the other processors that received a machine check error and serialize access to the machine check registers when analyzing, logging and clearing the information in the machine check registers)

> 
> Furthermore I doubt that an MCE on one socket indeed causes
> MCE-s on all other sockets, not to speak of distinct NUMA nodes
> (it would already surprise me if MCE-s got broadcast across cores
> within a socket, unless they are caused by a resource shared
> across cores).

Somehow I agree. But at least currently from Intel SDM, architecturally it would broadcast.

> 
>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Jun 05 03:18:00 2012
>> +0800 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Jun 13 23:40:45
>>      2012 +0800 @@ -638,6 +638,32 @@ return rec;
>>  }
>> 
>> +static int inject_vmce(struct domain *d)
> 
> Is it really necessary to move this vendor independent function
> into a vendor specific source file?

For AMD, I'm not quite sure if inject vMCE to all vcpus is proper for its arch. I remember AMD use nmi/ single MCE#/ broadcast MCE# in their different platforms.

BTW, currently in Xen mce logic, inject_vmce() is only used by Intel mce, so I put it into Intel mce logic to avoid potential issue. Intel mce and AMD mce differs in some points (including MCE# injection), so we'd better not spool together. Only if we are totally sure some logic is safe to co-used by Intel and AMD will we put it into common mce code.

> 
>> +{
>> +    struct vcpu *v;
>> +
>> +    /* inject vMCE to all vcpus */
>> +    for_each_vcpu(d, v)
>> +    {
>> +        if ( !test_and_set_bool(v->mce_pending) &&
>> +            ((d->is_hvm) ? 1 :
>> +            guest_has_trap_callback(d, v->vcpu_id,
>> TRAP_machine_check)) ) 
> 
> Quite strange a way to say
> 
>             (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id,
> TRAP_machine_check)) 

For hvm it's OK to just set v->mce_pending. While for pv it need also check if guest callback has been registered.

> 
>> +        {
>> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d
>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>> +            vcpu_kick(v);
>> +        }
>> +        else
>> +        {
>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>> +            return -1;
> 
> Why do you bail here? This is particularly bad if v->mce_pending
> was already set on some vCPU (as that could simply mean the guest
> just didn't get around to handle the vMCE yet).

the case v->mce_pending already set while new vmce come will result in domain crash.
I don't think guest can still handle this case, e.g. under baremetal if 2nd mce occur while 1st mce have not been handled os will reboot directly.

> 
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>  static void intel_memerr_dhandler(
>>               struct mca_binfo *binfo,
>>               enum mce_result *result,
> 
> Also, how does this whole change interact with vmce_{rd,wr}msr()?
> The struct bank_entry instances live on a per-domain list, so the
> vMCE being delivered to all vCPU-s means they will all race for the
> single entry (and might erroneously access others, particularly in
> vmce_wrmsr()'s MCG_STATUS handling).

Yes, I agree.
However, recently we have done vMCE re-design work (ongoing some internal review) and would present sooner. In new approach, MSRs are per-vcpu instead of per-domain.  MSRs race issue (and the effort to make it clean) would be pointless then. So at this butfix patch, I only touch vMCE# injection itself.

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 Jun 13 10:51:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:51:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SelAh-00020Q-1P; Wed, 13 Jun 2012 10:51:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1SelAg-00020H-6c
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:51:30 +0000
Received: from [193.109.254.147:3421] by server-10.bemta-14.messagelabs.com id
	D8/7C-25709-1B078DF4; Wed, 13 Jun 2012 10:51:29 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339584685!9482518!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6354 invoked from network); 13 Jun 2012 10:51:27 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:51:27 -0000
Received: by yenm4 with SMTP id m4so425362yen.32
	for <xen-devel@lists.xen.org>; Wed, 13 Jun 2012 03:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=YfggYpOBKlD5QjUcLONvMWCrW9TTQPZkCbwlrtlZyKU=;
	b=J/buh3RTAFK4XhpjO7NfvQAgiihd0Yws/RHD2lOIYSAhHl6K/yQ5Gt5S3s4ryLaIAS
	IczOGOCcU6b77dmUeYhJ1VUpzTJtYmHcSzRhB2jyKE3vMd3+gLLHMpBAAFNvEE+c9zNi
	YOjFPxVIO0no+onor06PEoDJ8m411nVGPVGe3Y5Wbl5eYhtkT76pWO3DULiEiE8N46GW
	m47zWQ2Azrgwu/iyO74RNSh0+sZQEom8ZLFYUimexzxrBQ9j7WDuorv5m0aqs7O0dXH7
	V3FgohHlltH2/+pr7xK9oYrKXKp1c0qfYLFgMUfc2rZzSi5bVenFEsnKm9cMMO4eb1Z4
	m0NQ==
Received: by 10.236.176.232 with SMTP id b68mr27937826yhm.102.1339584685078;
	Wed, 13 Jun 2012 03:51:25 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id w61sm8321394yhi.5.2012.06.13.03.51.23
	(version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 03:51:24 -0700 (PDT)
Message-ID: <4FD870A8.6030606@cantab.net>
Date: Wed, 13 Jun 2012 11:51:20 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD881530200007800089ACB@nat28.tlf.novell.com>
In-Reply-To: <4FD881530200007800089ACB@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
 to be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/06/12 11:02, Jan Beulich wrote:
> Rather than deferring the detection of these to the point where they
> get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
> to be raised by IRET, which invokes the guest's [fragile] fail-safe
> callback), don't even allow such to be set.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -736,6 +736,14 @@ int arch_set_info_guest(
>      {
>          if ( !compat )
>          {
> +#ifdef __x86_64__
> +            if ( !is_canonical_address(c.nat->user_regs.eip) ||
> +                 !is_canonical_address(c.nat->event_callback_eip) ||
> +                 !is_canonical_address(c.nat->syscall_callback_eip) ||
> +                 !is_canonical_address(c.nat->failsafe_callback_eip) )
> +                return -EINVAL;
> +#endif
> +

Would it be better to have

#ifndef __x86_64__
#  define is_canonical_address(a) 1
#endif

somewhere?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:51:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10:51:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SelAh-00020Q-1P; Wed, 13 Jun 2012 10:51:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1SelAg-00020H-6c
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:51:30 +0000
Received: from [193.109.254.147:3421] by server-10.bemta-14.messagelabs.com id
	D8/7C-25709-1B078DF4; Wed, 13 Jun 2012 10:51:29 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339584685!9482518!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6354 invoked from network); 13 Jun 2012 10:51:27 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:51:27 -0000
Received: by yenm4 with SMTP id m4so425362yen.32
	for <xen-devel@lists.xen.org>; Wed, 13 Jun 2012 03:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=YfggYpOBKlD5QjUcLONvMWCrW9TTQPZkCbwlrtlZyKU=;
	b=J/buh3RTAFK4XhpjO7NfvQAgiihd0Yws/RHD2lOIYSAhHl6K/yQ5Gt5S3s4ryLaIAS
	IczOGOCcU6b77dmUeYhJ1VUpzTJtYmHcSzRhB2jyKE3vMd3+gLLHMpBAAFNvEE+c9zNi
	YOjFPxVIO0no+onor06PEoDJ8m411nVGPVGe3Y5Wbl5eYhtkT76pWO3DULiEiE8N46GW
	m47zWQ2Azrgwu/iyO74RNSh0+sZQEom8ZLFYUimexzxrBQ9j7WDuorv5m0aqs7O0dXH7
	V3FgohHlltH2/+pr7xK9oYrKXKp1c0qfYLFgMUfc2rZzSi5bVenFEsnKm9cMMO4eb1Z4
	m0NQ==
Received: by 10.236.176.232 with SMTP id b68mr27937826yhm.102.1339584685078;
	Wed, 13 Jun 2012 03:51:25 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id w61sm8321394yhi.5.2012.06.13.03.51.23
	(version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 03:51:24 -0700 (PDT)
Message-ID: <4FD870A8.6030606@cantab.net>
Date: Wed, 13 Jun 2012 11:51:20 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD881530200007800089ACB@nat28.tlf.novell.com>
In-Reply-To: <4FD881530200007800089ACB@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
 to be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/06/12 11:02, Jan Beulich wrote:
> Rather than deferring the detection of these to the point where they
> get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
> to be raised by IRET, which invokes the guest's [fragile] fail-safe
> callback), don't even allow such to be set.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -736,6 +736,14 @@ int arch_set_info_guest(
>      {
>          if ( !compat )
>          {
> +#ifdef __x86_64__
> +            if ( !is_canonical_address(c.nat->user_regs.eip) ||
> +                 !is_canonical_address(c.nat->event_callback_eip) ||
> +                 !is_canonical_address(c.nat->syscall_callback_eip) ||
> +                 !is_canonical_address(c.nat->failsafe_callback_eip) )
> +                return -EINVAL;
> +#endif
> +

Would it be better to have

#ifndef __x86_64__
#  define is_canonical_address(a) 1
#endif

somewhere?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1SelGm-0002K4-SB; Wed, 13 Jun 2012 10:57: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 1SelGl-0002Jx-Mh
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:57:47 +0000
Received: from [85.158.143.35:14294] by server-2.bemta-4.messagelabs.com id
	67/42-17938-B2278DF4; Wed, 13 Jun 2012 10:57:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339585066!14280910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1099 invoked from network); 13 Jun 2012 10:57:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:57:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:56:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 11:56:56 +0100
Date: Wed, 13 Jun 2012 11:56:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120612151557.GA10691@redhat.com>
Message-ID: <alpine.DEB.2.02.1206131154030.14957@kaball.uk.xensource.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
 internal 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 Tue, 12 Jun 2012, Michael S. Tsirkin wrote:
> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> > This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> > 
> > This function is used by a later patch to parse the BDF of the device to
> > passthrough.
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> You probably want to parse the host address?  You don't want to copy the
> bugs in pci_parse_devaddr - write your own that has sane semantics
> for host. E.g. you need to support ARI etc.

Aside from this minor comment, do you have any objections to this series?

It has been outstanding for 9 months now, and the last few versions have
been without any major changes.
Considering that a new QEMU release cycle has just opened, I think that
now would be the perfect time to get the series in.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 10:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 10: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 1SelGm-0002K4-SB; Wed, 13 Jun 2012 10:57: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 1SelGl-0002Jx-Mh
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 10:57:47 +0000
Received: from [85.158.143.35:14294] by server-2.bemta-4.messagelabs.com id
	67/42-17938-B2278DF4; Wed, 13 Jun 2012 10:57:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339585066!14280910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1099 invoked from network); 13 Jun 2012 10:57:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 10:57:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 10:56:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 11:56:56 +0100
Date: Wed, 13 Jun 2012 11:56:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120612151557.GA10691@redhat.com>
Message-ID: <alpine.DEB.2.02.1206131154030.14957@kaball.uk.xensource.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
 internal 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 Tue, 12 Jun 2012, Michael S. Tsirkin wrote:
> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> > This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> > 
> > This function is used by a later patch to parse the BDF of the device to
> > passthrough.
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> You probably want to parse the host address?  You don't want to copy the
> bugs in pci_parse_devaddr - write your own that has sane semantics
> for host. E.g. you need to support ARI etc.

Aside from this minor comment, do you have any objections to this series?

It has been outstanding for 9 months now, and the last few versions have
been without any major changes.
Considering that a new QEMU release cycle has just opened, I think that
now would be the perfect time to get the series in.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:05:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1SelNn-0002ZN-On; Wed, 13 Jun 2012 11: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.Campbell@citrix.com>) id 1SelNl-0002ZI-JY
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:05:02 +0000
Received: from [85.158.138.51:15202] by server-6.bemta-3.messagelabs.com id
	34/01-05063-CD378DF4; Wed, 13 Jun 2012 11:05:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339585499!8721370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29958 invoked from network); 13 Jun 2012 11:05:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:04:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 12:04:59 +0100
Message-ID: <1339585498.24104.190.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 12:04:58 +0100
In-Reply-To: <1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> libxenctrl expects to be able to simply run the save or restore
> operation synchronously.  This won't work well in a process which is
> trying to handle multiple domains.
> 
> The options are:
> 
>  - Block such a whole process (eg, the whole of libvirt) while
>    migration completes (or until it fails).
> 
>  - Create a thread to run xc_domain_save and xc_domain_restore on.
>    This is quite unpalatable.  Multithreaded programming is error
>    prone enough without generating threads in libraries, particularly
>    if the thread does some very complex operation.
> 
>  - Fork and run the operation in the child without execing.  This is
>    no good because we would need to negotiate with the caller about
>    fds we would inherit (and we might be a very large process).
> 
>  - Fork and exec a helper.
> 
> Of these options the latter is the most palatable.
> 
> Consequently:
> 
>  * A new helper program libxl-save-helper (which does both save and
>    restore).  It will be installed in /usr/lib/xen/bin.  It does not
>    link against libxl, only libxc, and its error handling does not
>    need to be very advanced.  It does contain a plumbing through of
>    the logging interface into the callback stream.
> 
>  * A small ad-hoc protocol between the helper and libxl which allows
>    log messages and the libxc callbacks to be passed up and down.
>    Protocol doc comment is in libxl_save_helper.c.
> 
>  * To avoid a lot of tedium the marshalling boilerplate (stubs for the
>    helper and the callback decoder for libxl) is generated with a
>    small perl script.
> 
>  * Implement new functionality to spawn the helper, monitor its
>    output, provide responses, and check on its exit status.
> 
>  * The functions libxl__xc_domain_restore_done and
>    libxl__xc_domain_save_done now turn out to want be called in the
>    same place.  So make their state argument a void* so that the two
>    functions are type compatible.
> 
> The domain save path still writes the qemu savefile synchronously.
> This will need to be fixed in a subsequent patch.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Changes in v3:
>  * Suppress errno value in debug message when helper reports successful
>    completion.
>  * Significant consequential changes to cope with changes to
>    earlier patches in the series.
> 
> Changes in v2:
>  * Helper path can be overridden by an environment variable for testing.
>  * Add a couple of debug logging messages re toolstack data.
>  * Fixes from testing.
>  * Helper protocol message lengths (and numbers) are 16-bit which
>    more clearly avoids piling lots of junk on the stack.
>  * Merged with remus changes.
>  * Callback implementations in libxl now called via pointers
>    so remus can have its own callbacks.
>  * Better namespace prefixes on autogenerated names etc.
>  * Autogenerator can generate debugging printfs too.
> ---
[...]
> diff --git a/.hgignore b/.hgignore
> index 27d8f79..05304ea 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -180,9 +180,11 @@
>  ^tools/libxl/_.*\.c$
>  ^tools/libxl/libxlu_cfg_y\.output$
>  ^tools/libxl/xl$
> +^tools/libxl/libxl-save-helper$
>  ^tools/libxl/testidl$
>  ^tools/libxl/testidl\.c$
>  ^tools/libxl/tmp\..*$
> +^tools/libxl/.*\.new$

Our naming scheme for these sorts of temporary files is  rather in
consistent (including an existing use of .new), oh well...

[...]

> +SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
> +$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
> +
>  testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
>  testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
>         $(PYTHON) gentest.py libxl_types.idl testidl.c.new
> @@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
>         perl $^ --prefix=libxl >$@.new
>         $(call move-if-changed,$@.new,$@)
> 
> +_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
> +_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
> +               libxl_save_msgs_gen.pl
> +       $(PERL) -w $< $@ >$@.new
> +       $(call move-if-changed,$@.new,$@)
> +
>  libxl.h: _libxl_types.h
>  libxl_json.h: _libxl_types_json.h
>  libxl_internal.h: _libxl_types_internal.h _paths.h
> @@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
> 
> +libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
> +       $(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)

The changelog says that libxl-save-helper doesn't link libxenlight but
it is declared as a dependency here and CFLAGS_libxenlight is included
in SAVE_HELPER_OBJS' CFLAGS above.

> +
>  testidl: testidl.o libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
[...]
> @@ -170,6 +184,7 @@ install: all
>         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
>         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
>         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)

This needs an INSTALL_DIR for $(DESTDIR)$(PRIVATE_BINDIR) to support
"make -C tools/libxl DESTDIR=xxx install" else:
        install: cannot create regular file `/tmp/tmplKa0Y7/usr/lib/xen/bin': No such file or directory

>         $(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
>         ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
>         ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index b48452c..fea0c94 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -465,16 +465,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>  }
> 
>  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> -        uint32_t size, void *data)
> +                             uint32_t size, void *user)
>  {
> -    libxl__gc *gc = data;
> -    libxl_ctx *ctx = gc->owner;
> +    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;

Any reason you didn't s/ctx/CTX/ in one of your preparatory patches?

>      int i, ret;
>      const uint8_t *ptr = buf;
>      uint32_t count = 0, version = 0;
>      struct libxl__physmap_info* pi;
>      char *xs_path;

[...]
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> index 1b481ab..a39f434 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -16,6 +16,19 @@
> 
>  #include "libxl_internal.h"
> 
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int data_fd,
> +                       const unsigned long *argnums, int num_argnums);
> +
> +static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status);
> +static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
> +
> +/*----- entrypoints -----*/
> +
>  void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>                                int hvm, int pae, int superpages,
>                                int no_incr_generationid)
> @@ -27,22 +40,319 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> 
> -    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
> -                              state->store_port, &state->store_mfn,
> -                              state->store_domid, state->console_port,
> -                              &state->console_mfn, state->console_domid,
> -                              hvm, pae, superpages, no_incr_generationid,
> -                              &state->vm_generationid_addr, &dcs->callbacks);
> -    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
> +        (&dcs->shs.callbacks.restore.a);
> +
> +    const unsigned long argnums[] = {
> +        restore_fd, domid,
> +        state->store_port,
> +        state->store_domid, state->console_port,
> +        state->console_domid,
> +        hvm, pae, superpages, no_incr_generationid,
> +        cbflags,
> +    };
> +
> +    dcs->shs.ao = ao;
> +    dcs->shs.domid = domid;
> +    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
> +    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
> +    dcs->shs.caller_state = dcs;
> +    dcs->shs.need_results = 1;
> +    dcs->shs.toolstack_data_file = 0;
> +
> +    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd,
> +               argnums, ARRAY_SIZE(argnums));
>  }
> 
>  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
>                             unsigned long vm_generationid_addr)
>  {
>      STATE_AO_GC(dss->ao);
> -    int r;
> +    int r, rc;
> +    uint32_t toolstack_data_len;
> +
> +    /* Resources we need to free */
> +    uint8_t *toolstack_data_buf = 0;
> +
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> +        (&dss->shs.callbacks.save.a);
> +
> +    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
> +                              &toolstack_data_len, dss);

This seems to be called twice? I'm looking at the source after the full
series is applied and I see
        dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
in libxl__domain_suspend as well as this call here.

The callback one seems to be otherwise unused.

> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int data_fd,
> +                       const unsigned long *argnums, int num_argnums)
> +{
> +    STATE_AO_GC(shs->ao);
> +    const char *args[3 + num_argnums];
> +    const char **arg = args;
> +    int i, rc;
> +
> +    /* Resources we must free */
> +    libxl__carefd *childs_pipes[2] = { 0,0 };
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    shs->rc = 0;
> +    shs->completed = 0;
> +    shs->pipes[0] = shs->pipes[1] = 0;
> +    libxl__ev_fd_init(&shs->readable);
> +    libxl__ev_child_init(&shs->child);
> +
> +    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                " stdin pipe", domid);
> +    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                 " stdout pipe", domid);
> +
> +    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
> +    *arg++ = mode_arg;
> +    for (i=0; i<num_argnums; i++)
> +        *arg++ = GCSPRINTF("%lu", argnums[i]);
> +    *arg++ = 0;
> +    assert(arg == args + ARRAY_SIZE(args));
> +
> +    libxl__carefd_begin();
> +    for (i=0; i<2; i++) {
> +        int fds[2];
> +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> +        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
> +        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);

Using !i here is clever, but I had to deploy a pen to be sure the
assignments were all correct.

Open coding this simple loop would also give you the opportunity the
have comments like "/* This is the helper processes's stdout */" etc in
the appropriate place to aid in comprehension when checking the correct
end of each pipe goes in the right place.

> +    }
> +    libxl__carefd_unlock();
> +
> +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> +    if (!pid) {
> +        libxl_fd_set_cloexec(CTX, data_fd, 0);
> +        libxl__exec(gc,
> +                    libxl__carefd_fd(childs_pipes[0]),
> +                    libxl__carefd_fd(childs_pipes[1]),
> +                    -1,
> +                    args[0], (char**)args, 0);
> +    }
> +
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +
> +    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
> +                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
> +    if (rc) goto out;
> +    return;
> +
> + out:
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +    helper_failed(egc, shs, rc);;
> +}
> +
> +static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
> +                          int rc)
> +{
> +    STATE_AO_GC(shs->ao);
> +
> +    if (!shs->rc)
> +        shs->rc = rc;
> +
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +
> +    if (!libxl__ev_child_inuse(&shs->child)) {
> +        helper_done(egc, shs);
> +        return;
> +    }
> +
> +    int r = kill(shs->child.pid, SIGKILL);
> +    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
> +                (unsigned long)shs->child.pid);
> +}
> +
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
> +    STATE_AO_GC(shs->ao);
> +    int rc, errnoval;
> +
> +    if (revents & POLLPRI) {
> +        LOG(ERROR, "%s signaled POLLERR", shs->stdout_what);

                          signalled ?

(it's not impossible that my spell checker is wrong, google seem to
think both are ok)

The if says POLLPRI but the log says POLLERR?

> +        rc = ERROR_FAIL;
> + out:
> +        /* this is here because otherwise we bypass the decl of msg[] */

I don't get this comment, why can't "out:" be in the normal place after
the non-error return?

> +        helper_failed(egc, shs, rc);
> +        return;
> +    }
> +
> +    uint16_t msglen;
> +    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
> +                                  shs->stdout_what, "ipc msg header");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    unsigned char msg[msglen];
> +    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
> +                                  shs->stdout_what, "ipc msg body");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    shs->egc = egc;
> +    shs->recv_callback(msg, msglen, shs);
> +    shs->egc = 0;
> +    return;
> +}
> +
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
> +    STATE_AO_GC(shs->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    const char *what =
> +        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
> +
> +    if (status) {
> +        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (shs->need_results) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without providing results",what);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (!shs->completed) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without signaling completion",what);

                                            signalling again, same caveat


> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    helper_done(egc, shs);
> +    return;
> +}
[...]
> +/*----- generic helpers for the autogenerated code -----*/
[...]
> diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
> new file mode 100644
> index 0000000..d29f1f7
> --- /dev/null
> +++ b/tools/libxl/libxl_save_helper.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.

LGPL, or perhaps GPL since this is a helper?

(I suppose the same argument could be made for xl itself)

[...]
> +/*----- helper functions called by autogenerated stubs -----*/
> +
> +unsigned char * helper_allocbuf(int len, void *user)
> +{
> +    return xmalloc(len);
> +}
> +
> +static void transmit(const unsigned char *msg, int len, void *user)
> +{
> +    while (len) {
> +        int r = write(1, msg, len);
> +        if (r<0) { perror("write"); exit(-1); }
> +        assert(r >= 0);
> +        assert(r <= len);
> +        len -= r;
> +        msg += r;
> +    }
> +}
> +
> +void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
> +{
> +    assert(len_in < 64*1024);
> +    uint16_t len = len_in;
> +    transmit((const void*)&len, sizeof(len), user);
> +    transmit(msg_freed, len, user);
> +    free(msg_freed);
> +}
> +
> +int helper_getreply(void *user)
> +{
> +    int v;
> +    int r = read_exactly(0, &v, sizeof(v));
> +    if (r<=0) exit(-2);

You use -1 a lot but here you use -2, are we supposed to be able to
infer something from the specific error code?

> +    return v;
> +}
> +
> +/*----- other callbacks -----*/
> +
> +static int toolstack_save_fd;
> +static uint32_t toolstack_save_len;
[...]
> diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> new file mode 100755
> index 0000000..cd0837e
> --- /dev/null
> +++ b/tools/libxl/libxl_save_msgs_gen.pl
> @@ -0,0 +1,393 @@
> +#!/usr/bin/perl -w
> +
> +use warnings;
> +use strict;
> +use POSIX;
> +
> +our $debug = 0; # produce copius debugging output at run-time?

                             copious

(which is probably the most useful feedback you are going to get from me
on a Perl script ;-))

> +
> +our @msgs = (
> +    # flags:
> +    #   s  - applicable to save
> +    #   r  - applicable to restore
> +    #   c  - function pointer in callbacks struct rather than fixed function
> +    #   x  - function pointer is in struct {save,restore}_callbacks
> +    #         and its null-ness needs to be passed through to the helper's xc
> +    #   W  - needs a return value; callback is synchronous
> +    [  1, 'sr',     "log",                   [qw(uint32_t level
> +                                                 uint32_t errnoval
> +                                                 STRING context
> +                                                 STRING formatted)] ],
> +    [  2, 'sr',     "progress",              [qw(STRING context
> +                                                 STRING doing_what),
> +                                                'unsigned long', 'done',
> +                                                'unsigned long', 'total'] ],
> +    [  3, 'scxW',   "suspend", [] ],
> +    [  4, 'scxW',   "postcopy", [] ],
> +    [  5, 'scxW',   "checkpoint", [] ],
> +    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
> +                                              unsigned enable)] ],
> +    #                toolstack_save          done entirely `by hand'
> +    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
> +                                                BLOCK tsdata)] ],
> +    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
> +                                              'unsigned long', 'console_mfn',
> +                                              'unsigned long', 'genidad'] ],
> +    [  9, 'srW',    "complete",              [qw(int retval
> +                                                 int errnoval)] ],
> +);
> +
> +#----------------------------------------
> +
> +our %cbs;
> +our %func;
> +our %func_ah;
> +our @outfuncs;
> +our %out_decls;
> +our %out_body;
> +our %msgnum_used;
> +
> +die unless @ARGV==1;
> +die if $ARGV[0] =~ m/^-/;
> +
> +our ($intendedout) = @ARGV;
> +
> +$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
> +my ($want_ah, $ch) = ($1, $2);
> +
> +my $declprefix = '';
> +
> +foreach my $ah (qw(callout helper)) {
> +    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
[...]
> +END
[...]
> +END
[...]
> +END

I think I can infer what this does, but wow ;-)

> +}
[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:05:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1SelNn-0002ZN-On; Wed, 13 Jun 2012 11: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.Campbell@citrix.com>) id 1SelNl-0002ZI-JY
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:05:02 +0000
Received: from [85.158.138.51:15202] by server-6.bemta-3.messagelabs.com id
	34/01-05063-CD378DF4; Wed, 13 Jun 2012 11:05:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339585499!8721370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29958 invoked from network); 13 Jun 2012 11:05:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:04:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 12:04:59 +0100
Message-ID: <1339585498.24104.190.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 12:04:58 +0100
In-Reply-To: <1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> libxenctrl expects to be able to simply run the save or restore
> operation synchronously.  This won't work well in a process which is
> trying to handle multiple domains.
> 
> The options are:
> 
>  - Block such a whole process (eg, the whole of libvirt) while
>    migration completes (or until it fails).
> 
>  - Create a thread to run xc_domain_save and xc_domain_restore on.
>    This is quite unpalatable.  Multithreaded programming is error
>    prone enough without generating threads in libraries, particularly
>    if the thread does some very complex operation.
> 
>  - Fork and run the operation in the child without execing.  This is
>    no good because we would need to negotiate with the caller about
>    fds we would inherit (and we might be a very large process).
> 
>  - Fork and exec a helper.
> 
> Of these options the latter is the most palatable.
> 
> Consequently:
> 
>  * A new helper program libxl-save-helper (which does both save and
>    restore).  It will be installed in /usr/lib/xen/bin.  It does not
>    link against libxl, only libxc, and its error handling does not
>    need to be very advanced.  It does contain a plumbing through of
>    the logging interface into the callback stream.
> 
>  * A small ad-hoc protocol between the helper and libxl which allows
>    log messages and the libxc callbacks to be passed up and down.
>    Protocol doc comment is in libxl_save_helper.c.
> 
>  * To avoid a lot of tedium the marshalling boilerplate (stubs for the
>    helper and the callback decoder for libxl) is generated with a
>    small perl script.
> 
>  * Implement new functionality to spawn the helper, monitor its
>    output, provide responses, and check on its exit status.
> 
>  * The functions libxl__xc_domain_restore_done and
>    libxl__xc_domain_save_done now turn out to want be called in the
>    same place.  So make their state argument a void* so that the two
>    functions are type compatible.
> 
> The domain save path still writes the qemu savefile synchronously.
> This will need to be fixed in a subsequent patch.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Changes in v3:
>  * Suppress errno value in debug message when helper reports successful
>    completion.
>  * Significant consequential changes to cope with changes to
>    earlier patches in the series.
> 
> Changes in v2:
>  * Helper path can be overridden by an environment variable for testing.
>  * Add a couple of debug logging messages re toolstack data.
>  * Fixes from testing.
>  * Helper protocol message lengths (and numbers) are 16-bit which
>    more clearly avoids piling lots of junk on the stack.
>  * Merged with remus changes.
>  * Callback implementations in libxl now called via pointers
>    so remus can have its own callbacks.
>  * Better namespace prefixes on autogenerated names etc.
>  * Autogenerator can generate debugging printfs too.
> ---
[...]
> diff --git a/.hgignore b/.hgignore
> index 27d8f79..05304ea 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -180,9 +180,11 @@
>  ^tools/libxl/_.*\.c$
>  ^tools/libxl/libxlu_cfg_y\.output$
>  ^tools/libxl/xl$
> +^tools/libxl/libxl-save-helper$
>  ^tools/libxl/testidl$
>  ^tools/libxl/testidl\.c$
>  ^tools/libxl/tmp\..*$
> +^tools/libxl/.*\.new$

Our naming scheme for these sorts of temporary files is  rather in
consistent (including an existing use of .new), oh well...

[...]

> +SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
> +$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
> +
>  testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
>  testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
>         $(PYTHON) gentest.py libxl_types.idl testidl.c.new
> @@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
>         perl $^ --prefix=libxl >$@.new
>         $(call move-if-changed,$@.new,$@)
> 
> +_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
> +_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
> +               libxl_save_msgs_gen.pl
> +       $(PERL) -w $< $@ >$@.new
> +       $(call move-if-changed,$@.new,$@)
> +
>  libxl.h: _libxl_types.h
>  libxl_json.h: _libxl_types_json.h
>  libxl_internal.h: _libxl_types_internal.h _paths.h
> @@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
> 
> +libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
> +       $(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)

The changelog says that libxl-save-helper doesn't link libxenlight but
it is declared as a dependency here and CFLAGS_libxenlight is included
in SAVE_HELPER_OBJS' CFLAGS above.

> +
>  testidl: testidl.o libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
[...]
> @@ -170,6 +184,7 @@ install: all
>         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
>         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
>         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)

This needs an INSTALL_DIR for $(DESTDIR)$(PRIVATE_BINDIR) to support
"make -C tools/libxl DESTDIR=xxx install" else:
        install: cannot create regular file `/tmp/tmplKa0Y7/usr/lib/xen/bin': No such file or directory

>         $(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
>         ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
>         ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index b48452c..fea0c94 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -465,16 +465,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>  }
> 
>  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> -        uint32_t size, void *data)
> +                             uint32_t size, void *user)
>  {
> -    libxl__gc *gc = data;
> -    libxl_ctx *ctx = gc->owner;
> +    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;

Any reason you didn't s/ctx/CTX/ in one of your preparatory patches?

>      int i, ret;
>      const uint8_t *ptr = buf;
>      uint32_t count = 0, version = 0;
>      struct libxl__physmap_info* pi;
>      char *xs_path;

[...]
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> index 1b481ab..a39f434 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -16,6 +16,19 @@
> 
>  #include "libxl_internal.h"
> 
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int data_fd,
> +                       const unsigned long *argnums, int num_argnums);
> +
> +static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status);
> +static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
> +
> +/*----- entrypoints -----*/
> +
>  void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>                                int hvm, int pae, int superpages,
>                                int no_incr_generationid)
> @@ -27,22 +40,319 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> 
> -    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
> -                              state->store_port, &state->store_mfn,
> -                              state->store_domid, state->console_port,
> -                              &state->console_mfn, state->console_domid,
> -                              hvm, pae, superpages, no_incr_generationid,
> -                              &state->vm_generationid_addr, &dcs->callbacks);
> -    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
> +        (&dcs->shs.callbacks.restore.a);
> +
> +    const unsigned long argnums[] = {
> +        restore_fd, domid,
> +        state->store_port,
> +        state->store_domid, state->console_port,
> +        state->console_domid,
> +        hvm, pae, superpages, no_incr_generationid,
> +        cbflags,
> +    };
> +
> +    dcs->shs.ao = ao;
> +    dcs->shs.domid = domid;
> +    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
> +    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
> +    dcs->shs.caller_state = dcs;
> +    dcs->shs.need_results = 1;
> +    dcs->shs.toolstack_data_file = 0;
> +
> +    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd,
> +               argnums, ARRAY_SIZE(argnums));
>  }
> 
>  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
>                             unsigned long vm_generationid_addr)
>  {
>      STATE_AO_GC(dss->ao);
> -    int r;
> +    int r, rc;
> +    uint32_t toolstack_data_len;
> +
> +    /* Resources we need to free */
> +    uint8_t *toolstack_data_buf = 0;
> +
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> +        (&dss->shs.callbacks.save.a);
> +
> +    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
> +                              &toolstack_data_len, dss);

This seems to be called twice? I'm looking at the source after the full
series is applied and I see
        dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
in libxl__domain_suspend as well as this call here.

The callback one seems to be otherwise unused.

> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int data_fd,
> +                       const unsigned long *argnums, int num_argnums)
> +{
> +    STATE_AO_GC(shs->ao);
> +    const char *args[3 + num_argnums];
> +    const char **arg = args;
> +    int i, rc;
> +
> +    /* Resources we must free */
> +    libxl__carefd *childs_pipes[2] = { 0,0 };
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    shs->rc = 0;
> +    shs->completed = 0;
> +    shs->pipes[0] = shs->pipes[1] = 0;
> +    libxl__ev_fd_init(&shs->readable);
> +    libxl__ev_child_init(&shs->child);
> +
> +    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                " stdin pipe", domid);
> +    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                 " stdout pipe", domid);
> +
> +    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
> +    *arg++ = mode_arg;
> +    for (i=0; i<num_argnums; i++)
> +        *arg++ = GCSPRINTF("%lu", argnums[i]);
> +    *arg++ = 0;
> +    assert(arg == args + ARRAY_SIZE(args));
> +
> +    libxl__carefd_begin();
> +    for (i=0; i<2; i++) {
> +        int fds[2];
> +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> +        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
> +        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);

Using !i here is clever, but I had to deploy a pen to be sure the
assignments were all correct.

Open coding this simple loop would also give you the opportunity the
have comments like "/* This is the helper processes's stdout */" etc in
the appropriate place to aid in comprehension when checking the correct
end of each pipe goes in the right place.

> +    }
> +    libxl__carefd_unlock();
> +
> +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> +    if (!pid) {
> +        libxl_fd_set_cloexec(CTX, data_fd, 0);
> +        libxl__exec(gc,
> +                    libxl__carefd_fd(childs_pipes[0]),
> +                    libxl__carefd_fd(childs_pipes[1]),
> +                    -1,
> +                    args[0], (char**)args, 0);
> +    }
> +
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +
> +    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
> +                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
> +    if (rc) goto out;
> +    return;
> +
> + out:
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +    helper_failed(egc, shs, rc);;
> +}
> +
> +static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
> +                          int rc)
> +{
> +    STATE_AO_GC(shs->ao);
> +
> +    if (!shs->rc)
> +        shs->rc = rc;
> +
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +
> +    if (!libxl__ev_child_inuse(&shs->child)) {
> +        helper_done(egc, shs);
> +        return;
> +    }
> +
> +    int r = kill(shs->child.pid, SIGKILL);
> +    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
> +                (unsigned long)shs->child.pid);
> +}
> +
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
> +    STATE_AO_GC(shs->ao);
> +    int rc, errnoval;
> +
> +    if (revents & POLLPRI) {
> +        LOG(ERROR, "%s signaled POLLERR", shs->stdout_what);

                          signalled ?

(it's not impossible that my spell checker is wrong, google seem to
think both are ok)

The if says POLLPRI but the log says POLLERR?

> +        rc = ERROR_FAIL;
> + out:
> +        /* this is here because otherwise we bypass the decl of msg[] */

I don't get this comment, why can't "out:" be in the normal place after
the non-error return?

> +        helper_failed(egc, shs, rc);
> +        return;
> +    }
> +
> +    uint16_t msglen;
> +    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
> +                                  shs->stdout_what, "ipc msg header");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    unsigned char msg[msglen];
> +    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
> +                                  shs->stdout_what, "ipc msg body");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    shs->egc = egc;
> +    shs->recv_callback(msg, msglen, shs);
> +    shs->egc = 0;
> +    return;
> +}
> +
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
> +    STATE_AO_GC(shs->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    const char *what =
> +        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
> +
> +    if (status) {
> +        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (shs->need_results) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without providing results",what);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (!shs->completed) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without signaling completion",what);

                                            signalling again, same caveat


> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    helper_done(egc, shs);
> +    return;
> +}
[...]
> +/*----- generic helpers for the autogenerated code -----*/
[...]
> diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
> new file mode 100644
> index 0000000..d29f1f7
> --- /dev/null
> +++ b/tools/libxl/libxl_save_helper.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.

LGPL, or perhaps GPL since this is a helper?

(I suppose the same argument could be made for xl itself)

[...]
> +/*----- helper functions called by autogenerated stubs -----*/
> +
> +unsigned char * helper_allocbuf(int len, void *user)
> +{
> +    return xmalloc(len);
> +}
> +
> +static void transmit(const unsigned char *msg, int len, void *user)
> +{
> +    while (len) {
> +        int r = write(1, msg, len);
> +        if (r<0) { perror("write"); exit(-1); }
> +        assert(r >= 0);
> +        assert(r <= len);
> +        len -= r;
> +        msg += r;
> +    }
> +}
> +
> +void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
> +{
> +    assert(len_in < 64*1024);
> +    uint16_t len = len_in;
> +    transmit((const void*)&len, sizeof(len), user);
> +    transmit(msg_freed, len, user);
> +    free(msg_freed);
> +}
> +
> +int helper_getreply(void *user)
> +{
> +    int v;
> +    int r = read_exactly(0, &v, sizeof(v));
> +    if (r<=0) exit(-2);

You use -1 a lot but here you use -2, are we supposed to be able to
infer something from the specific error code?

> +    return v;
> +}
> +
> +/*----- other callbacks -----*/
> +
> +static int toolstack_save_fd;
> +static uint32_t toolstack_save_len;
[...]
> diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> new file mode 100755
> index 0000000..cd0837e
> --- /dev/null
> +++ b/tools/libxl/libxl_save_msgs_gen.pl
> @@ -0,0 +1,393 @@
> +#!/usr/bin/perl -w
> +
> +use warnings;
> +use strict;
> +use POSIX;
> +
> +our $debug = 0; # produce copius debugging output at run-time?

                             copious

(which is probably the most useful feedback you are going to get from me
on a Perl script ;-))

> +
> +our @msgs = (
> +    # flags:
> +    #   s  - applicable to save
> +    #   r  - applicable to restore
> +    #   c  - function pointer in callbacks struct rather than fixed function
> +    #   x  - function pointer is in struct {save,restore}_callbacks
> +    #         and its null-ness needs to be passed through to the helper's xc
> +    #   W  - needs a return value; callback is synchronous
> +    [  1, 'sr',     "log",                   [qw(uint32_t level
> +                                                 uint32_t errnoval
> +                                                 STRING context
> +                                                 STRING formatted)] ],
> +    [  2, 'sr',     "progress",              [qw(STRING context
> +                                                 STRING doing_what),
> +                                                'unsigned long', 'done',
> +                                                'unsigned long', 'total'] ],
> +    [  3, 'scxW',   "suspend", [] ],
> +    [  4, 'scxW',   "postcopy", [] ],
> +    [  5, 'scxW',   "checkpoint", [] ],
> +    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
> +                                              unsigned enable)] ],
> +    #                toolstack_save          done entirely `by hand'
> +    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
> +                                                BLOCK tsdata)] ],
> +    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
> +                                              'unsigned long', 'console_mfn',
> +                                              'unsigned long', 'genidad'] ],
> +    [  9, 'srW',    "complete",              [qw(int retval
> +                                                 int errnoval)] ],
> +);
> +
> +#----------------------------------------
> +
> +our %cbs;
> +our %func;
> +our %func_ah;
> +our @outfuncs;
> +our %out_decls;
> +our %out_body;
> +our %msgnum_used;
> +
> +die unless @ARGV==1;
> +die if $ARGV[0] =~ m/^-/;
> +
> +our ($intendedout) = @ARGV;
> +
> +$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
> +my ($want_ah, $ch) = ($1, $2);
> +
> +my $declprefix = '';
> +
> +foreach my $ah (qw(callout helper)) {
> +    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
[...]
> +END
[...]
> +END
[...]
> +END

I think I can infer what this does, but wow ;-)

> +}
[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:06:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1SelOr-0002eR-OL; Wed, 13 Jun 2012 11:06:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SelOq-0002eC-5u
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:06:08 +0000
Received: from [85.158.143.99:36955] by server-2.bemta-4.messagelabs.com id
	F0/E2-17938-F1478DF4; Wed, 13 Jun 2012 11:06:07 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339585565!27297901!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22018 invoked from network); 13 Jun 2012 11:06:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Jun 2012 11:06:06 -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 q5DB611A026477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 07:06:01 -0400
Received: from redhat.com (vpn-203-147.tlv.redhat.com [10.35.203.147])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5DB5wqA005481; Wed, 13 Jun 2012 07:05:59 -0400
Date: Wed, 13 Jun 2012 14:06:34 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120613110633.GC18001@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com>
	<alpine.DEB.2.02.1206131154030.14957@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206131154030.14957@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Wed, Jun 13, 2012 at 11:56:34AM +0100, Stefano Stabellini wrote:
> On Tue, 12 Jun 2012, Michael S. Tsirkin wrote:
> > On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> > > This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> > > 
> > > This function is used by a later patch to parse the BDF of the device to
> > > passthrough.
> > > 
> > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > You probably want to parse the host address?  You don't want to copy the
> > bugs in pci_parse_devaddr - write your own that has sane semantics
> > for host. E.g. you need to support ARI etc.
> 
> Aside from this minor comment, do you have any objections to this series?

Aside from this, there are minor pci core changes and these are all
fine.
I can't say I looked at the device itself too deeply
but seems mergeable.

> It has been outstanding for 9 months now, and the last few versions have
> been without any major changes.
> Considering that a new QEMU release cycle has just opened, I think that
> now would be the perfect time to get the series in.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:06:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1SelOr-0002eR-OL; Wed, 13 Jun 2012 11:06:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SelOq-0002eC-5u
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:06:08 +0000
Received: from [85.158.143.99:36955] by server-2.bemta-4.messagelabs.com id
	F0/E2-17938-F1478DF4; Wed, 13 Jun 2012 11:06:07 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339585565!27297901!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22018 invoked from network); 13 Jun 2012 11:06:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Jun 2012 11:06:06 -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 q5DB611A026477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 07:06:01 -0400
Received: from redhat.com (vpn-203-147.tlv.redhat.com [10.35.203.147])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5DB5wqA005481; Wed, 13 Jun 2012 07:05:59 -0400
Date: Wed, 13 Jun 2012 14:06:34 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120613110633.GC18001@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com>
	<alpine.DEB.2.02.1206131154030.14957@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206131154030.14957@kaball.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Wed, Jun 13, 2012 at 11:56:34AM +0100, Stefano Stabellini wrote:
> On Tue, 12 Jun 2012, Michael S. Tsirkin wrote:
> > On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> > > This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> > > 
> > > This function is used by a later patch to parse the BDF of the device to
> > > passthrough.
> > > 
> > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > You probably want to parse the host address?  You don't want to copy the
> > bugs in pci_parse_devaddr - write your own that has sane semantics
> > for host. E.g. you need to support ARI etc.
> 
> Aside from this minor comment, do you have any objections to this series?

Aside from this, there are minor pci core changes and these are all
fine.
I can't say I looked at the device itself too deeply
but seems mergeable.

> It has been outstanding for 9 months now, and the last few versions have
> been without any major changes.
> Considering that a new QEMU release cycle has just opened, I think that
> now would be the perfect time to get the series in.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SelXz-0002tu-QN; Wed, 13 Jun 2012 11:15:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SelXx-0002tp-Oy
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:15:34 +0000
Received: from [193.109.254.147:48030] by server-1.bemta-14.messagelabs.com id
	58/91-08067-55678DF4; Wed, 13 Jun 2012 11:15:33 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339586131!7098565!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gNDM0MTQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27447 invoked from network); 13 Jun 2012 11:15:32 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 11:15:32 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q5DBFOw9021844;
	Wed, 13 Jun 2012 13:15:24 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DBFNa7008879;
	Wed, 13 Jun 2012 13:15:23 +0200
Message-ID: <4FD8764B.9060003@siemens.com>
Date: Wed, 13 Jun 2012 13:15:23 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com>
In-Reply-To: <20120612151557.GA10691@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-12 17:15, Michael S. Tsirkin wrote:
> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>
>> This function is used by a later patch to parse the BDF of the device to
>> passthrough.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> You probably want to parse the host address?  You don't want to copy the
> bugs in pci_parse_devaddr - write your own that has sane semantics
> for host. E.g. you need to support ARI etc.

We should really consolidate over one parser for Xen, KVM device
assignment and VFIO. It looks like they all have very similar requirements.

For those how didn't follow the discussion, see patches 10-13 in
http://thread.gmane.org/gmane.comp.emulators.qemu/153728.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SelXz-0002tu-QN; Wed, 13 Jun 2012 11:15:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SelXx-0002tp-Oy
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:15:34 +0000
Received: from [193.109.254.147:48030] by server-1.bemta-14.messagelabs.com id
	58/91-08067-55678DF4; Wed, 13 Jun 2012 11:15:33 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339586131!7098565!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gNDM0MTQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27447 invoked from network); 13 Jun 2012 11:15:32 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 11:15:32 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q5DBFOw9021844;
	Wed, 13 Jun 2012 13:15:24 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DBFNa7008879;
	Wed, 13 Jun 2012 13:15:23 +0200
Message-ID: <4FD8764B.9060003@siemens.com>
Date: Wed, 13 Jun 2012 13:15:23 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com>
In-Reply-To: <20120612151557.GA10691@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-12 17:15, Michael S. Tsirkin wrote:
> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>
>> This function is used by a later patch to parse the BDF of the device to
>> passthrough.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> You probably want to parse the host address?  You don't want to copy the
> bugs in pci_parse_devaddr - write your own that has sane semantics
> for host. E.g. you need to support ARI etc.

We should really consolidate over one parser for Xen, KVM device
assignment and VFIO. It looks like they all have very similar requirements.

For those how didn't follow the discussion, see patches 10-13 in
http://thread.gmane.org/gmane.comp.emulators.qemu/153728.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:16:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:16: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 1SelYY-0002vj-7K; Wed, 13 Jun 2012 11:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SelYW-0002vY-Vm
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:16:09 +0000
Received: from [85.158.143.35:27339] by server-3.bemta-4.messagelabs.com id
	8D/D6-05808-87678DF4; Wed, 13 Jun 2012 11:16:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339586160!12900091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7044 invoked from network); 13 Jun 2012 11:16:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:16:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 12:16:00 +0100
Message-ID: <1339586159.24104.193.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 12:15:59 +0100
In-Reply-To: <1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/19] libxl: provide libxl__xs_*_checked
 and libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> These useful utility functions make dealing with xenstore a little
> less painful.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(minor observation and a typo below)

[...]
> +/* On success, *result_out came from the gc.
> + * On error, *result_out is undefined.
> + * ENOENT counts as success but sets *result_out=0
> + */
> +int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
> +                           const char *path, const char **result_out);
> +
> +/* Does not include a trailing null.
> + * May usefully be combined with GCSPRINTF if the format string
> + * behaviour of libxl__xs_write is desirable. */
> +int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
> +                            const char *path, const char *string);

I suppose in the future we might consider merging this with
libxl__xs_write -- there's no reason not to always log a failed write,
is there?

> +
> +/* ENOENT is not an error (even if the parent directories don't exist) */
> +int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
> +
> +/* Transaction functions, best used together.
> + * The caller should initialise *t to 0 (XBT_NULL) before calling start.
> + * Each function leaves *t!=0 iff the transaction needs cleaning up.
> + *
> + * libxl__xs_transaction_commit returns:
> + *   <0  failure - a libxl error code
> + *   +1  commit conflict; transaction has been destroyed and caller
> + *        must go round again (call _start again and retry)
> + *    0  commited successfully

           committed

> + */
> +int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
> +int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
> +void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
> +
> +
> +

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:16:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:16: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 1SelYY-0002vj-7K; Wed, 13 Jun 2012 11:16:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SelYW-0002vY-Vm
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:16:09 +0000
Received: from [85.158.143.35:27339] by server-3.bemta-4.messagelabs.com id
	8D/D6-05808-87678DF4; Wed, 13 Jun 2012 11:16:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339586160!12900091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7044 invoked from network); 13 Jun 2012 11:16:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12992899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:16:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 12:16:00 +0100
Message-ID: <1339586159.24104.193.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 12:15:59 +0100
In-Reply-To: <1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/19] libxl: provide libxl__xs_*_checked
 and libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> These useful utility functions make dealing with xenstore a little
> less painful.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(minor observation and a typo below)

[...]
> +/* On success, *result_out came from the gc.
> + * On error, *result_out is undefined.
> + * ENOENT counts as success but sets *result_out=0
> + */
> +int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
> +                           const char *path, const char **result_out);
> +
> +/* Does not include a trailing null.
> + * May usefully be combined with GCSPRINTF if the format string
> + * behaviour of libxl__xs_write is desirable. */
> +int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
> +                            const char *path, const char *string);

I suppose in the future we might consider merging this with
libxl__xs_write -- there's no reason not to always log a failed write,
is there?

> +
> +/* ENOENT is not an error (even if the parent directories don't exist) */
> +int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
> +
> +/* Transaction functions, best used together.
> + * The caller should initialise *t to 0 (XBT_NULL) before calling start.
> + * Each function leaves *t!=0 iff the transaction needs cleaning up.
> + *
> + * libxl__xs_transaction_commit returns:
> + *   <0  failure - a libxl error code
> + *   +1  commit conflict; transaction has been destroyed and caller
> + *        must go round again (call _start again and retry)
> + *    0  commited successfully

           committed

> + */
> +int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
> +int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
> +void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
> +
> +
> +

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:20:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1SelcR-00039B-SE; Wed, 13 Jun 2012 11:20: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 1SelcQ-00038z-Qm
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:20:11 +0000
Received: from [85.158.139.83:62869] by server-3.bemta-5.messagelabs.com id
	01/CC-03367-A6778DF4; Wed, 13 Jun 2012 11:20:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339586408!16187485!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30466 invoked from network); 13 Jun 2012 11:20:09 -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; 13 Jun 2012 11:20:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 12:20:08 +0100
Message-Id: <4FD893B20200007800089B82@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 12:20:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <dvrabel@cantab.net>
References: <4FD881530200007800089ACB@nat28.tlf.novell.com>
	<4FD870A8.6030606@cantab.net>
In-Reply-To: <4FD870A8.6030606@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
 to be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.06.12 at 12:51, David Vrabel <dvrabel@cantab.net> wrote:
> On 13/06/12 11:02, Jan Beulich wrote:
>> Rather than deferring the detection of these to the point where they
>> get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
>> to be raised by IRET, which invokes the guest's [fragile] fail-safe
>> callback), don't even allow such to be set.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -736,6 +736,14 @@ int arch_set_info_guest(
>>      {
>>          if ( !compat )
>>          {
>> +#ifdef __x86_64__
>> +            if ( !is_canonical_address(c.nat->user_regs.eip) ||
>> +                 !is_canonical_address(c.nat->event_callback_eip) ||
>> +                 !is_canonical_address(c.nat->syscall_callback_eip) ||
>> +                 !is_canonical_address(c.nat->failsafe_callback_eip) )
>> +                return -EINVAL;
>> +#endif
>> +
> 
> Would it be better to have
> 
> #ifndef __x86_64__
> #  define is_canonical_address(a) 1
> #endif
> 
> somewhere?

That one we have (otherwise other changes in this patch would
cause build failures), the problem here is that ->syscall_callback
doesn't exist for the 32-bit interface. And rater than just putting
that on line into a conditional, I preferred to frame the whole
addition.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:20:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1SelcR-00039B-SE; Wed, 13 Jun 2012 11:20: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 1SelcQ-00038z-Qm
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:20:11 +0000
Received: from [85.158.139.83:62869] by server-3.bemta-5.messagelabs.com id
	01/CC-03367-A6778DF4; Wed, 13 Jun 2012 11:20:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339586408!16187485!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30466 invoked from network); 13 Jun 2012 11:20:09 -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; 13 Jun 2012 11:20:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 12:20:08 +0100
Message-Id: <4FD893B20200007800089B82@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 12:20:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <dvrabel@cantab.net>
References: <4FD881530200007800089ACB@nat28.tlf.novell.com>
	<4FD870A8.6030606@cantab.net>
In-Reply-To: <4FD870A8.6030606@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
 to be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.06.12 at 12:51, David Vrabel <dvrabel@cantab.net> wrote:
> On 13/06/12 11:02, Jan Beulich wrote:
>> Rather than deferring the detection of these to the point where they
>> get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
>> to be raised by IRET, which invokes the guest's [fragile] fail-safe
>> callback), don't even allow such to be set.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -736,6 +736,14 @@ int arch_set_info_guest(
>>      {
>>          if ( !compat )
>>          {
>> +#ifdef __x86_64__
>> +            if ( !is_canonical_address(c.nat->user_regs.eip) ||
>> +                 !is_canonical_address(c.nat->event_callback_eip) ||
>> +                 !is_canonical_address(c.nat->syscall_callback_eip) ||
>> +                 !is_canonical_address(c.nat->failsafe_callback_eip) )
>> +                return -EINVAL;
>> +#endif
>> +
> 
> Would it be better to have
> 
> #ifndef __x86_64__
> #  define is_canonical_address(a) 1
> #endif
> 
> somewhere?

That one we have (otherwise other changes in this patch would
cause build failures), the problem here is that ->syscall_callback
doesn't exist for the 32-bit interface. And rater than just putting
that on line into a conditional, I preferred to frame the whole
addition.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:22:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1Selek-0003Go-D7; Wed, 13 Jun 2012 11:22:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Selei-0003Gj-Mv
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:22:32 +0000
Received: from [85.158.143.35:16648] by server-1.bemta-4.messagelabs.com id
	F6/76-24392-8F778DF4; Wed, 13 Jun 2012 11:22:32 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339586549!13559134!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22681 invoked from network); 13 Jun 2012 11:22:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	13 Jun 2012 11:22:30 -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 q5DBMPek030474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 07:22:25 -0400
Received: from redhat.com (vpn-203-147.tlv.redhat.com [10.35.203.147])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q5DBMLHR003255; Wed, 13 Jun 2012 07:22:22 -0400
Date: Wed, 13 Jun 2012 14:22:57 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Message-ID: <20120613112257.GF18001@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD8764B.9060003@siemens.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Wed, Jun 13, 2012 at 01:15:23PM +0200, Jan Kiszka wrote:
> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
> > On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> >> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> >>
> >> This function is used by a later patch to parse the BDF of the device to
> >> passthrough.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > You probably want to parse the host address?  You don't want to copy the
> > bugs in pci_parse_devaddr - write your own that has sane semantics
> > for host. E.g. you need to support ARI etc.
> 
> We should really consolidate over one parser for Xen, KVM device
> assignment and VFIO. It looks like they all have very similar requirements.

Also rename pci_parse_devaddr to pci_parse_legacy_devaddr
to stress it's not something others should reuse.

> For those how didn't follow the discussion, see patches 10-13 in
> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:22:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1Selek-0003Go-D7; Wed, 13 Jun 2012 11:22:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Selei-0003Gj-Mv
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:22:32 +0000
Received: from [85.158.143.35:16648] by server-1.bemta-4.messagelabs.com id
	F6/76-24392-8F778DF4; Wed, 13 Jun 2012 11:22:32 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339586549!13559134!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22681 invoked from network); 13 Jun 2012 11:22:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	13 Jun 2012 11:22:30 -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 q5DBMPek030474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 07:22:25 -0400
Received: from redhat.com (vpn-203-147.tlv.redhat.com [10.35.203.147])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q5DBMLHR003255; Wed, 13 Jun 2012 07:22:22 -0400
Date: Wed, 13 Jun 2012 14:22:57 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Message-ID: <20120613112257.GF18001@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD8764B.9060003@siemens.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Wed, Jun 13, 2012 at 01:15:23PM +0200, Jan Kiszka wrote:
> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
> > On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> >> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> >>
> >> This function is used by a later patch to parse the BDF of the device to
> >> passthrough.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > You probably want to parse the host address?  You don't want to copy the
> > bugs in pci_parse_devaddr - write your own that has sane semantics
> > for host. E.g. you need to support ARI etc.
> 
> We should really consolidate over one parser for Xen, KVM device
> assignment and VFIO. It looks like they all have very similar requirements.

Also rename pci_parse_devaddr to pci_parse_legacy_devaddr
to stress it's not something others should reuse.

> For those how didn't follow the discussion, see patches 10-13 in
> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:23:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1Self8-0003Ic-Pj; Wed, 13 Jun 2012 11:22: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 1Self6-0003IK-NG
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:22:56 +0000
Received: from [85.158.139.83:44336] by server-9.bemta-5.messagelabs.com id
	EC/1E-01069-F0878DF4; Wed, 13 Jun 2012 11:22:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339586575!23504555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28121 invoked from network); 13 Jun 2012 11:22:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12993074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:22:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 12:22:24 +0100
Date: Wed, 13 Jun 2012 12:22:03 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4FD8764B.9060003@siemens.com>
Message-ID: <alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
 internal 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 Wed, 13 Jun 2012, Jan Kiszka wrote:
> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
> > On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> >> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> >>
> >> This function is used by a later patch to parse the BDF of the device to
> >> passthrough.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > You probably want to parse the host address?  You don't want to copy the
> > bugs in pci_parse_devaddr - write your own that has sane semantics
> > for host. E.g. you need to support ARI etc.
> 
> We should really consolidate over one parser for Xen, KVM device
> assignment and VFIO. It looks like they all have very similar requirements.
> 
> For those how didn't follow the discussion, see patches 10-13 in
> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.

I agree, actually it looks like patch 10 and 11 would be enough.

Maybe you could extract them and send them out separately?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:23:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1Self8-0003Ic-Pj; Wed, 13 Jun 2012 11:22: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 1Self6-0003IK-NG
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:22:56 +0000
Received: from [85.158.139.83:44336] by server-9.bemta-5.messagelabs.com id
	EC/1E-01069-F0878DF4; Wed, 13 Jun 2012 11:22:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339586575!23504555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28121 invoked from network); 13 Jun 2012 11:22:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12993074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:22:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 12:22:24 +0100
Date: Wed, 13 Jun 2012 12:22:03 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4FD8764B.9060003@siemens.com>
Message-ID: <alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
 internal 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 Wed, 13 Jun 2012, Jan Kiszka wrote:
> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
> > On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> >> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> >>
> >> This function is used by a later patch to parse the BDF of the device to
> >> passthrough.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > You probably want to parse the host address?  You don't want to copy the
> > bugs in pci_parse_devaddr - write your own that has sane semantics
> > for host. E.g. you need to support ARI etc.
> 
> We should really consolidate over one parser for Xen, KVM device
> assignment and VFIO. It looks like they all have very similar requirements.
> 
> For those how didn't follow the discussion, see patches 10-13 in
> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.

I agree, actually it looks like patch 10 and 11 would be enough.

Maybe you could extract them and send them out separately?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Selk1-0003aw-GH; Wed, 13 Jun 2012 11:28:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Selk0-0003ar-Ja
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:28:00 +0000
Received: from [85.158.143.35:19960] by server-1.bemta-4.messagelabs.com id
	C9/FF-24392-F3978DF4; Wed, 13 Jun 2012 11:27:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339586879!12901250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31935 invoked from network); 13 Jun 2012 11:27:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:27:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12993222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:27:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 12:27:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Seljr-0005un-7g; Wed, 13 Jun 2012 11:27:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Seljr-0003Hn-2z;
	Wed, 13 Jun 2012 12:27:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20440.31030.964902.468871@mariner.uk.xensource.com>
Date: Wed, 13 Jun 2012 12:27:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339583907.24104.182.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> > There's quite a lot of combinations which need testing here (PV, HVM,
> > HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?

I haven't tried stub dm or new qemu.  I have tried save/restore of
both PV and HVM.  I have also done localhost migration - although
perhaps not as often or in as many combinations.

> > I tried a simple localhost migrate of a PV guest and:
> 
> As a separate issue in "xl -vvv save d32-1 /scratch/SAVE" I no longer
> see the progress messages (xxx% complete etc). I saw something which
> looked like support for logging progress messages so I was a bit
> surprised...

I'll look into this.  I think you're right about the fd bug too.
I don't know why this didn't go wrong for me.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Selk1-0003aw-GH; Wed, 13 Jun 2012 11:28:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Selk0-0003ar-Ja
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:28:00 +0000
Received: from [85.158.143.35:19960] by server-1.bemta-4.messagelabs.com id
	C9/FF-24392-F3978DF4; Wed, 13 Jun 2012 11:27:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339586879!12901250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31935 invoked from network); 13 Jun 2012 11:27:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:27:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,762,1330905600"; d="scan'208";a="12993222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:27:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 13 Jun 2012 12:27:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Seljr-0005un-7g; Wed, 13 Jun 2012 11:27:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Seljr-0003Hn-2z;
	Wed, 13 Jun 2012 12:27:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20440.31030.964902.468871@mariner.uk.xensource.com>
Date: Wed, 13 Jun 2012 12:27:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339583907.24104.182.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> On Wed, 2012-06-13 at 09:59 +0100, Ian Campbell wrote:
> > There's quite a lot of combinations which need testing here (PV, HVM,
> > HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?

I haven't tried stub dm or new qemu.  I have tried save/restore of
both PV and HVM.  I have also done localhost migration - although
perhaps not as often or in as many combinations.

> > I tried a simple localhost migrate of a PV guest and:
> 
> As a separate issue in "xl -vvv save d32-1 /scratch/SAVE" I no longer
> see the progress messages (xxx% complete etc). I saw something which
> looked like support for logging progress messages so I was a bit
> surprised...

I'll look into this.  I think you're right about the fd bug too.
I don't know why this didn't go wrong for me.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Selw9-0003qr-Ae; Wed, 13 Jun 2012 11:40:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1Selw7-0003qQ-4z
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 11:40:31 +0000
Received: from [193.109.254.147:51117] by server-11.bemta-14.messagelabs.com
	id 76/C3-02727-E2C78DF4; Wed, 13 Jun 2012 11:40:30 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339587609!9493382!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10309 invoked from network); 13 Jun 2012 11:40:10 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:40:10 -0000
Received: by obfk16 with SMTP id k16so1087904obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 04:40:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=P9G92i2/Ghk9c513OSJOWi0jxrKyDlILmoOt43o20sk=;
	b=JYgfR2aKreRga+v/DepLbceRPq6Tf5+UERpBHrTCravD75+//GJsD0Y5ZTvn6uT1CP
	u9zBTDdSBl6WA29yhkkVKZg5i2gnMpGN3Tp0ZnGDVfyJ3VSP2V1labcnZd4LVGQvnflR
	0/AaeJtQMUyrj0Scl2PZOSsfxKM3MbFF1X9SVtvCaWLq3tx1pSyY6iSp9PnB8fzMUdhr
	KMYLMi/63BT02hZHBffpB9DlLFZBanpqHnzEVb6T/rSaBpC/EG2ETtt86w+h2aseqxKG
	fHdMAG1N9jgrlWiOXr8VCeK3GaayEu1EPDaU7dHbqyNwv9yxcREx6OHortEDEmVC94fr
	9vlQ==
MIME-Version: 1.0
Received: by 10.182.47.105 with SMTP id c9mr24820263obn.49.1339587608641; Wed,
	13 Jun 2012 04:40:08 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 13 Jun 2012 04:40:08 -0700 (PDT)
In-Reply-To: <4FD85F83.3080207@tiscali.it>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
	<4FD85F83.3080207@tiscali.it>
Date: Wed, 13 Jun 2012 19:40:08 +0800
Message-ID: <CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: fantonifabio@tiscali.it
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni <fantonifabio@tiscali.it> wr=
ote:
> Il 13/06/2012 11:02, ZhouPeng ha scritto:
>
>> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.it>
>> =A0wrote:
>>>
>>> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>>>
>>>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>>>> <stefano.stabellini@eu.citrix.com> =A0 =A0wrote:
>>>>>
>>>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>>>
>>>>>> Sorry for late reply, I am not on this mail these days because of my
>>>>>> work.
>>>>>>
>>>>>> I further test qxl-vga and I think I figure out the problem in some
>>>>>> extend.
>>>>>>
>>>>>> If using qxl device, the default memory size of vga is 64M.
>>>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>>>
>>>>>> The exact reason is xc_domain_populate_physmap_exact fails, because
>>>>>> xen-hypervisor
>>>>>> fail,
>>>>>> it's because of =A0 alloc_domheap_pages(d, a->extent_order, a->memfl=
ags)
>>>>>> fails in hypervisor.
>>>>>>
>>>>>> I am not very familiar with xen's memory management, Does 64M exceed
>>>>>> xen's heap space in this context?
>>>>>
>>>>> XL sets an upper bound of memory that can be allocated to the VM in
>>>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>>>> My guess is that a 64MB allocation would go over that limit.
>>>>> You could try increasing the limit manually changing the
>>>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
>>>>> videoram=3D64 in the VM config file.
>>>>
>>>> Your guess is absolutely right!
>>>>
>>>> But set videoram=3D128 or
>>>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>>>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>>>
>>>> Then I successfuly install qxl driver in win-hvm and QXL can work
>>>> properly.
>>>>
>>>> I will send some patch to add qxl support to libxl.
>>>
>>> I tried your 3 patches taken from the mailing list, it works but doesn't
>>> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
>>> doesn't
>>> start and on windows 7 I have heavy performance problem (unusable).
>>
>> Could you find qxl vga card =A0(named "Red Hat QXL GPU") in your
>> windows hvm's device manager to make sure your qxl is working?
>>
>> My testing hvm-guest is Win XP.
>>
>> I played "Harry Potter" in my LAN smoothly, qxl gives
>> great enhancement .
>>
>> Although I don't test win7 and linux, I think it should work for them.
>>>
>>> I tried also with qemu 1.1.0 but nothing change.
>>
>> I am not sure qemu 1.1.0 accept all the patches for xen.
>>
>> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git
>>
>> It is build and installed by default, you should enable spice support.
>> spice can be enabled like below:
>>
>> +++ b/tools/Makefile =A0 =A0Sat May 26 12:31:01 2012 +0800
>> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>> =A0 =A0 =A0 =A0 --bindir=3D$(LIBEXEC) \
>> =A0 =A0 =A0 =A0 --datadir=3D$(SHAREDIR)/qemu-xen \
>> =A0 =A0 =A0 =A0 --disable-kvm \
>> + =A0 =A0 =A0 --enable-spice \
>>
>>> Does it work correctly for you? If so can I have some detail of your
>>> configurations please?
>>
>> My vm.cfg:
>>
>> name =3D 'xpPro_spice'
>> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
>> builder =3D 'hvm'
>> memory =3D '1024'
>> device_model_version =3D 'qemu-xen'
>> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
>> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
>> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:9=
7:CB:0E:7D']
>> sdl=3D0
>> vnc=3D0
>> vncviewer=3D0
>> serial =3D 'pty'
>> vcpus=3D1
>> usbdevice=3D'tablet'
>> #spice
>> spice=3D1
>> qxl=3D1
>> #qxlram=3D64
>> #qxlvram=3D64
>> spiceport=3D6000
>> spicehost=3D'192.168.1.187'
>> spicedisable_ticketing =3D 1
>> spiceagent_mouse =3D 0 # (1|0)
>>
>>> For audio support this is needed too: (tested and working)
>>> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on =
qemu
>>> invocation and env QEMU_AUDIO_DRV=3Dspice
>>> Can you add audio support on libxl please?
>>
>> I think audio support can be considered after qxl accpted.
>>>
>>>
>>
> Thanks for reply, qxl driver is installed, windows see qxl video card,
> already compiled qemu with spice with patch I send months ago, already tr=
ied
> git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
> Unfortunately the results are always the same.
> Here a quick recording:
> Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv

oh...  it shows spice+qxl running on Xen get
significant performance reduction compared with KVM ...

> Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
> Are not new but the result of the last test is the same.
> I hope I can help you understand the problem.
> If you need more information ask.

-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Selw9-0003qr-Ae; Wed, 13 Jun 2012 11:40:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1Selw7-0003qQ-4z
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 11:40:31 +0000
Received: from [193.109.254.147:51117] by server-11.bemta-14.messagelabs.com
	id 76/C3-02727-E2C78DF4; Wed, 13 Jun 2012 11:40:30 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339587609!9493382!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10309 invoked from network); 13 Jun 2012 11:40:10 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 11:40:10 -0000
Received: by obfk16 with SMTP id k16so1087904obf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 04:40:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=P9G92i2/Ghk9c513OSJOWi0jxrKyDlILmoOt43o20sk=;
	b=JYgfR2aKreRga+v/DepLbceRPq6Tf5+UERpBHrTCravD75+//GJsD0Y5ZTvn6uT1CP
	u9zBTDdSBl6WA29yhkkVKZg5i2gnMpGN3Tp0ZnGDVfyJ3VSP2V1labcnZd4LVGQvnflR
	0/AaeJtQMUyrj0Scl2PZOSsfxKM3MbFF1X9SVtvCaWLq3tx1pSyY6iSp9PnB8fzMUdhr
	KMYLMi/63BT02hZHBffpB9DlLFZBanpqHnzEVb6T/rSaBpC/EG2ETtt86w+h2aseqxKG
	fHdMAG1N9jgrlWiOXr8VCeK3GaayEu1EPDaU7dHbqyNwv9yxcREx6OHortEDEmVC94fr
	9vlQ==
MIME-Version: 1.0
Received: by 10.182.47.105 with SMTP id c9mr24820263obn.49.1339587608641; Wed,
	13 Jun 2012 04:40:08 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 13 Jun 2012 04:40:08 -0700 (PDT)
In-Reply-To: <4FD85F83.3080207@tiscali.it>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335454757.28015.160.camel@zakaz.uk.xensource.com>
	<CAAh7U5Op9Lb3tsgaZHqSLyP_F6zWw09oeArAO+eo1-DMRDf0xw@mail.gmail.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
	<4FD85F83.3080207@tiscali.it>
Date: Wed, 13 Jun 2012 19:40:08 +0800
Message-ID: <CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: fantonifabio@tiscali.it
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni <fantonifabio@tiscali.it> wr=
ote:
> Il 13/06/2012 11:02, ZhouPeng ha scritto:
>
>> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.it>
>> =A0wrote:
>>>
>>> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>>>
>>>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>>>> <stefano.stabellini@eu.citrix.com> =A0 =A0wrote:
>>>>>
>>>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>>>
>>>>>> Sorry for late reply, I am not on this mail these days because of my
>>>>>> work.
>>>>>>
>>>>>> I further test qxl-vga and I think I figure out the problem in some
>>>>>> extend.
>>>>>>
>>>>>> If using qxl device, the default memory size of vga is 64M.
>>>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>>>
>>>>>> The exact reason is xc_domain_populate_physmap_exact fails, because
>>>>>> xen-hypervisor
>>>>>> fail,
>>>>>> it's because of =A0 alloc_domheap_pages(d, a->extent_order, a->memfl=
ags)
>>>>>> fails in hypervisor.
>>>>>>
>>>>>> I am not very familiar with xen's memory management, Does 64M exceed
>>>>>> xen's heap space in this context?
>>>>>
>>>>> XL sets an upper bound of memory that can be allocated to the VM in
>>>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>>>> My guess is that a 64MB allocation would go over that limit.
>>>>> You could try increasing the limit manually changing the
>>>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
>>>>> videoram=3D64 in the VM config file.
>>>>
>>>> Your guess is absolutely right!
>>>>
>>>> But set videoram=3D128 or
>>>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>>>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>>>
>>>> Then I successfuly install qxl driver in win-hvm and QXL can work
>>>> properly.
>>>>
>>>> I will send some patch to add qxl support to libxl.
>>>
>>> I tried your 3 patches taken from the mailing list, it works but doesn't
>>> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
>>> doesn't
>>> start and on windows 7 I have heavy performance problem (unusable).
>>
>> Could you find qxl vga card =A0(named "Red Hat QXL GPU") in your
>> windows hvm's device manager to make sure your qxl is working?
>>
>> My testing hvm-guest is Win XP.
>>
>> I played "Harry Potter" in my LAN smoothly, qxl gives
>> great enhancement .
>>
>> Although I don't test win7 and linux, I think it should work for them.
>>>
>>> I tried also with qemu 1.1.0 but nothing change.
>>
>> I am not sure qemu 1.1.0 accept all the patches for xen.
>>
>> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git
>>
>> It is build and installed by default, you should enable spice support.
>> spice can be enabled like below:
>>
>> +++ b/tools/Makefile =A0 =A0Sat May 26 12:31:01 2012 +0800
>> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>> =A0 =A0 =A0 =A0 --bindir=3D$(LIBEXEC) \
>> =A0 =A0 =A0 =A0 --datadir=3D$(SHAREDIR)/qemu-xen \
>> =A0 =A0 =A0 =A0 --disable-kvm \
>> + =A0 =A0 =A0 --enable-spice \
>>
>>> Does it work correctly for you? If so can I have some detail of your
>>> configurations please?
>>
>> My vm.cfg:
>>
>> name =3D 'xpPro_spice'
>> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
>> builder =3D 'hvm'
>> memory =3D '1024'
>> device_model_version =3D 'qemu-xen'
>> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
>> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
>> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:9=
7:CB:0E:7D']
>> sdl=3D0
>> vnc=3D0
>> vncviewer=3D0
>> serial =3D 'pty'
>> vcpus=3D1
>> usbdevice=3D'tablet'
>> #spice
>> spice=3D1
>> qxl=3D1
>> #qxlram=3D64
>> #qxlvram=3D64
>> spiceport=3D6000
>> spicehost=3D'192.168.1.187'
>> spicedisable_ticketing =3D 1
>> spiceagent_mouse =3D 0 # (1|0)
>>
>>> For audio support this is needed too: (tested and working)
>>> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on =
qemu
>>> invocation and env QEMU_AUDIO_DRV=3Dspice
>>> Can you add audio support on libxl please?
>>
>> I think audio support can be considered after qxl accpted.
>>>
>>>
>>
> Thanks for reply, qxl driver is installed, windows see qxl video card,
> already compiled qemu with spice with patch I send months ago, already tr=
ied
> git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
> Unfortunately the results are always the same.
> Here a quick recording:
> Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv

oh...  it shows spice+qxl running on Xen get
significant performance reduction compared with KVM ...

> Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
> Are not new but the result of the last test is the same.
> I hope I can help you understand the problem.
> If you need more information ask.

-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:40:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1Selw7-0003qV-PM; Wed, 13 Jun 2012 11:40: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 1Selw6-0003qL-CT
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:40:30 +0000
Received: from [85.158.143.99:2421] by server-1.bemta-4.messagelabs.com id
	35/B6-24392-D2C78DF4; Wed, 13 Jun 2012 11:40:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339587628!27365173!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5025 invoked from network); 13 Jun 2012 11:40:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 11:40:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 12:40:27 +0100
Message-Id: <4FD898770200007800089BE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 12:41:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
	<4FD8713B0200007800089A77@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 12:49, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 13.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> Xen vMCE bugfix: inject vMCE# to all vcpus
>>> 
>>> In our test for win8 guest mce, we find a bug in that no matter what
>>> SRAO/SRAR error xen inject to win8 guest, it always reboot.
>>> 
>>> The root cause is, current Xen vMCE logic inject vMCE# only to
>>> vcpu0, this is not correct for Intel MCE (Under Intel arch, h/w
>>> generate MCE# to all CPUs). 
>>> 
>>> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.
>> 
>> I see no correlation between the fix (and its description) and the
>> problem at hand: Why would Win8 reboot if it doesn't receive a
>> particular MCE on all CPUs? Isn't that model specific behavior?
> 
> It's not model specific. For Intel processor, MCE# is broadcast to all 
> logical processors on the system on which the UCR errors are supported (refer 
> Intel SDM 15.9.3.1 & 15.9.3.2). So for vMCE injection under Intel arch, it's a 
> bug if inject vMCE# only to vcpu0.

This is for a certain group of errors, but I can't find any statement
that this is general architectural behavior.

>> Furthermore I doubt that an MCE on one socket indeed causes
>> MCE-s on all other sockets, not to speak of distinct NUMA nodes
>> (it would already surprise me if MCE-s got broadcast across cores
>> within a socket, unless they are caused by a resource shared
>> across cores).
> 
> Somehow I agree. But at least currently from Intel SDM, architecturally it 
> would broadcast.

I can't even see how this would work reliably across packages or
nodes: Suppose two entities each encounter a UCR - they would
each signal the other one, and the handling of this signal would
need to be synchronized with the handling of the local UCR
(irrespective of the order in which the events arrive).

>>> +        if ( !test_and_set_bool(v->mce_pending) &&
>>> +            ((d->is_hvm) ? 1 :
>>> +            guest_has_trap_callback(d, v->vcpu_id,
>>> TRAP_machine_check)) ) 
>> 
>> Quite strange a way to say
>> 
>>             (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id,
>> TRAP_machine_check)) 
> 
> For hvm it's OK to just set v->mce_pending. While for pv it need also check if 
> guest callback has been registered.

Sure. I was just asking why you use a conditional operator when
the simpler || would do.

>>> +        {
>>> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d
>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>> +            vcpu_kick(v);
>>> +        }
>>> +        else
>>> +        {
>>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>> +            return -1;
>> 
>> Why do you bail here? This is particularly bad if v->mce_pending
>> was already set on some vCPU (as that could simply mean the guest
>> just didn't get around to handle the vMCE yet).
> 
> the case v->mce_pending already set while new vmce come will result in domain 
> crash.
> I don't think guest can still handle this case, e.g. under baremetal if 2nd 
> mce occur while 1st mce have not been handled os will reboot directly.

Sorry, no. This goes back to the questionable nature of the
broadcasting above - if a CPU encounters a UCR itself and gets
signaled of a remote CPU having encountered one, it should be
able to cope. Otherwise the risk of (pointless!) system death
would increase with the number of CPUs.

>> Also, how does this whole change interact with vmce_{rd,wr}msr()?
>> The struct bank_entry instances live on a per-domain list, so the
>> vMCE being delivered to all vCPU-s means they will all race for the
>> single entry (and might erroneously access others, particularly in
>> vmce_wrmsr()'s MCG_STATUS handling).
> 
> Yes, I agree.
> However, recently we have done vMCE re-design work (ongoing some internal 
> review) and would present sooner. In new approach, MSRs are per-vcpu instead 
> of per-domain.  MSRs race issue (and the effort to make it clean) would be 
> pointless then. So at this butfix patch, I only touch vMCE# injection itself.

I understand that you want the simpler version as bug fix, but
you didn't answer whether it was at all verified that the single
per-domain entry logic would actually cope with the broadcast
delivery logic you're adding here. I'm afraid the per-vCPU entry
logic is a prerequisite to this change (in whatever form it may end
up going in).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:40:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11: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 1Selw7-0003qV-PM; Wed, 13 Jun 2012 11:40: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 1Selw6-0003qL-CT
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:40:30 +0000
Received: from [85.158.143.99:2421] by server-1.bemta-4.messagelabs.com id
	35/B6-24392-D2C78DF4; Wed, 13 Jun 2012 11:40:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339587628!27365173!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5025 invoked from network); 13 Jun 2012 11:40:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 11:40:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Jun 2012 12:40:27 +0100
Message-Id: <4FD898770200007800089BE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 13 Jun 2012 12:41:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
	<4FD8713B0200007800089A77@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 12:49, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 13.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> Xen vMCE bugfix: inject vMCE# to all vcpus
>>> 
>>> In our test for win8 guest mce, we find a bug in that no matter what
>>> SRAO/SRAR error xen inject to win8 guest, it always reboot.
>>> 
>>> The root cause is, current Xen vMCE logic inject vMCE# only to
>>> vcpu0, this is not correct for Intel MCE (Under Intel arch, h/w
>>> generate MCE# to all CPUs). 
>>> 
>>> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.
>> 
>> I see no correlation between the fix (and its description) and the
>> problem at hand: Why would Win8 reboot if it doesn't receive a
>> particular MCE on all CPUs? Isn't that model specific behavior?
> 
> It's not model specific. For Intel processor, MCE# is broadcast to all 
> logical processors on the system on which the UCR errors are supported (refer 
> Intel SDM 15.9.3.1 & 15.9.3.2). So for vMCE injection under Intel arch, it's a 
> bug if inject vMCE# only to vcpu0.

This is for a certain group of errors, but I can't find any statement
that this is general architectural behavior.

>> Furthermore I doubt that an MCE on one socket indeed causes
>> MCE-s on all other sockets, not to speak of distinct NUMA nodes
>> (it would already surprise me if MCE-s got broadcast across cores
>> within a socket, unless they are caused by a resource shared
>> across cores).
> 
> Somehow I agree. But at least currently from Intel SDM, architecturally it 
> would broadcast.

I can't even see how this would work reliably across packages or
nodes: Suppose two entities each encounter a UCR - they would
each signal the other one, and the handling of this signal would
need to be synchronized with the handling of the local UCR
(irrespective of the order in which the events arrive).

>>> +        if ( !test_and_set_bool(v->mce_pending) &&
>>> +            ((d->is_hvm) ? 1 :
>>> +            guest_has_trap_callback(d, v->vcpu_id,
>>> TRAP_machine_check)) ) 
>> 
>> Quite strange a way to say
>> 
>>             (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id,
>> TRAP_machine_check)) 
> 
> For hvm it's OK to just set v->mce_pending. While for pv it need also check if 
> guest callback has been registered.

Sure. I was just asking why you use a conditional operator when
the simpler || would do.

>>> +        {
>>> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d
>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>> +            vcpu_kick(v);
>>> +        }
>>> +        else
>>> +        {
>>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>> +            return -1;
>> 
>> Why do you bail here? This is particularly bad if v->mce_pending
>> was already set on some vCPU (as that could simply mean the guest
>> just didn't get around to handle the vMCE yet).
> 
> the case v->mce_pending already set while new vmce come will result in domain 
> crash.
> I don't think guest can still handle this case, e.g. under baremetal if 2nd 
> mce occur while 1st mce have not been handled os will reboot directly.

Sorry, no. This goes back to the questionable nature of the
broadcasting above - if a CPU encounters a UCR itself and gets
signaled of a remote CPU having encountered one, it should be
able to cope. Otherwise the risk of (pointless!) system death
would increase with the number of CPUs.

>> Also, how does this whole change interact with vmce_{rd,wr}msr()?
>> The struct bank_entry instances live on a per-domain list, so the
>> vMCE being delivered to all vCPU-s means they will all race for the
>> single entry (and might erroneously access others, particularly in
>> vmce_wrmsr()'s MCG_STATUS handling).
> 
> Yes, I agree.
> However, recently we have done vMCE re-design work (ongoing some internal 
> review) and would present sooner. In new approach, MSRs are per-vcpu instead 
> of per-domain.  MSRs race issue (and the effort to make it clean) would be 
> pointless then. So at this butfix patch, I only touch vMCE# injection itself.

I understand that you want the simpler version as bug fix, but
you didn't answer whether it was at all verified that the single
per-domain entry logic would actually cope with the broadcast
delivery logic you're adding here. I'm afraid the per-vCPU entry
logic is a prerequisite to this change (in whatever form it may end
up going in).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:44:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:44: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 1Sem00-000460-2m; Wed, 13 Jun 2012 11:44: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 1Selzy-00045p-FT
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:44:30 +0000
Received: from [85.158.143.99:52882] by server-3.bemta-4.messagelabs.com id
	F4/FA-05808-D1D78DF4; Wed, 13 Jun 2012 11:44:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339587869!22858048!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31754 invoked from network); 13 Jun 2012 11:44:29 -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; 13 Jun 2012 11:44:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Selzv-00068h-Ul; Wed, 13 Jun 2012 11:44:27 +0000
Date: Wed, 13 Jun 2012 12:44:27 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120613114427.GA21809@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120613104858.GC23207@boiler.cam.xci-test.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 11:48 +0100 on 13 Jun (1339588138), Jean Guyader wrote:
> On 07/06 04:36, Tim Deegan wrote:
> > Using one ring for all clients raises the question of access control and
> > admission control -- in particular how do you avoid DoS from
> > badly-behaved clients?
> > 
> > And, given your concerns about sharing an OS with an uncooperative
> > Xenstore client, how do you handle sharing the OS with a badly behaved
> > v4v client?
> > 
> > If we _do_ need one ring with multiple writers, and therefore Xen needs
> > to arbitrate writes, there's still room for the policy-based parts
> > (controlling connection setup, for example) to live outside the
> > hypervisor, openvswitch-style.
> 
> Today the acl check in V4V (not part of the current patch serie) is
> done for every copy by Xen.

OK; can you describe roughly how it works?  Is it a whitelist of good
domains, or a blacklist of bad?  Does it just do access control or is
there rate limiting?  Can it detect and block badly-behaved clients,
or is that something you do in the server?

Have you given any thought to my second question -- if you can't rely on
the existing xenstore code, are there problems with sharing a VM with
other v4v drivers?  My intuition is that at least it would not be so
bad, since non-malicious drivers ought to be able to coexist, but I'd
like to know your opinion.

> Moving the policy control outside of Xen
> would mean that you still need to have a copy of the acls in Xen and
> the worst thing that can happen is for the copy to get out of sync.

What I meant by openvswitch-style is to have a single low-level ACL in
the hypervisor (maybe as a whitelist of known good connections) and
fault all unusual behaviour (new domain appears, &c) to the more complex
policy engine in user-space.

Really it depends on what kind of policy you want to be able to express.
If a simple yes/no whitelist is good enough (and always will be) then it
may as well live in the hypervisor and we can skip the 'defer to
userspace' part.

> What do you think would be the next step going forward?

Hopefully, to get some feedback from other people (specifically Ian, Ian
and Stefano but anyone else too!) and decide what, if anything, ought to
be changed about the design.

My feedback has mostly been about the hypervisor side of things -- I'm
sure the tools maintainers have some ideas about how this should be
merged with libvchan, to avoid having two separate comms interfaces.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:44:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:44: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 1Sem00-000460-2m; Wed, 13 Jun 2012 11:44: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 1Selzy-00045p-FT
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:44:30 +0000
Received: from [85.158.143.99:52882] by server-3.bemta-4.messagelabs.com id
	F4/FA-05808-D1D78DF4; Wed, 13 Jun 2012 11:44:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339587869!22858048!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31754 invoked from network); 13 Jun 2012 11:44:29 -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; 13 Jun 2012 11:44:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Selzv-00068h-Ul; Wed, 13 Jun 2012 11:44:27 +0000
Date: Wed, 13 Jun 2012 12:44:27 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120613114427.GA21809@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120613104858.GC23207@boiler.cam.xci-test.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 11:48 +0100 on 13 Jun (1339588138), Jean Guyader wrote:
> On 07/06 04:36, Tim Deegan wrote:
> > Using one ring for all clients raises the question of access control and
> > admission control -- in particular how do you avoid DoS from
> > badly-behaved clients?
> > 
> > And, given your concerns about sharing an OS with an uncooperative
> > Xenstore client, how do you handle sharing the OS with a badly behaved
> > v4v client?
> > 
> > If we _do_ need one ring with multiple writers, and therefore Xen needs
> > to arbitrate writes, there's still room for the policy-based parts
> > (controlling connection setup, for example) to live outside the
> > hypervisor, openvswitch-style.
> 
> Today the acl check in V4V (not part of the current patch serie) is
> done for every copy by Xen.

OK; can you describe roughly how it works?  Is it a whitelist of good
domains, or a blacklist of bad?  Does it just do access control or is
there rate limiting?  Can it detect and block badly-behaved clients,
or is that something you do in the server?

Have you given any thought to my second question -- if you can't rely on
the existing xenstore code, are there problems with sharing a VM with
other v4v drivers?  My intuition is that at least it would not be so
bad, since non-malicious drivers ought to be able to coexist, but I'd
like to know your opinion.

> Moving the policy control outside of Xen
> would mean that you still need to have a copy of the acls in Xen and
> the worst thing that can happen is for the copy to get out of sync.

What I meant by openvswitch-style is to have a single low-level ACL in
the hypervisor (maybe as a whitelist of known good connections) and
fault all unusual behaviour (new domain appears, &c) to the more complex
policy engine in user-space.

Really it depends on what kind of policy you want to be able to express.
If a simple yes/no whitelist is good enough (and always will be) then it
may as well live in the hypervisor and we can skip the 'defer to
userspace' part.

> What do you think would be the next step going forward?

Hopefully, to get some feedback from other people (specifically Ian, Ian
and Stefano but anyone else too!) and decide what, if anything, ought to
be changed about the design.

My feedback has mostly been about the hypervisor side of things -- I'm
sure the tools maintainers have some ideas about how this should be
merged with libvchan, to avoid having two separate comms interfaces.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:48:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:48: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 1Sem3i-0004Gp-NR; Wed, 13 Jun 2012 11:48:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Sem3h-0004Gi-Kq
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:48:21 +0000
Received: from [85.158.139.83:61094] by server-3.bemta-5.messagelabs.com id
	5E/45-03367-40E78DF4; Wed, 13 Jun 2012 11:48:20 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339588100!27459178!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gNDM0MTQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14605 invoked from network); 13 Jun 2012 11:48:20 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 11:48:20 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q5DBmFDa007680;
	Wed, 13 Jun 2012 13:48:15 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DBmEu8004492;
	Wed, 13 Jun 2012 13:48:15 +0200
Message-ID: <4FD87DFE.3080904@siemens.com>
Date: Wed, 13 Jun 2012 13:48:14 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<20120613112257.GF18001@redhat.com>
In-Reply-To: <20120613112257.GF18001@redhat.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-13 13:22, Michael S. Tsirkin wrote:
> On Wed, Jun 13, 2012 at 01:15:23PM +0200, Jan Kiszka wrote:
>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>
>>>> This function is used by a later patch to parse the BDF of the device to
>>>> passthrough.
>>>>
>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>
>>> You probably want to parse the host address?  You don't want to copy the
>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>> for host. E.g. you need to support ARI etc.
>>
>> We should really consolidate over one parser for Xen, KVM device
>> assignment and VFIO. It looks like they all have very similar requirements.
> 
> Also rename pci_parse_devaddr to pci_parse_legacy_devaddr
> to stress it's not something others should reuse.

That depends on what pci_parse_devaddr will do in the end. If it will
become as general as my qemu_parse_pci_devaddr, "legacy" would be
inappropriate.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 11:48:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 11:48: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 1Sem3i-0004Gp-NR; Wed, 13 Jun 2012 11:48:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Sem3h-0004Gi-Kq
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 11:48:21 +0000
Received: from [85.158.139.83:61094] by server-3.bemta-5.messagelabs.com id
	5E/45-03367-40E78DF4; Wed, 13 Jun 2012 11:48:20 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339588100!27459178!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gNDM0MTQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14605 invoked from network); 13 Jun 2012 11:48:20 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 11:48:20 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q5DBmFDa007680;
	Wed, 13 Jun 2012 13:48:15 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DBmEu8004492;
	Wed, 13 Jun 2012 13:48:15 +0200
Message-ID: <4FD87DFE.3080904@siemens.com>
Date: Wed, 13 Jun 2012 13:48:14 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<20120613112257.GF18001@redhat.com>
In-Reply-To: <20120613112257.GF18001@redhat.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-13 13:22, Michael S. Tsirkin wrote:
> On Wed, Jun 13, 2012 at 01:15:23PM +0200, Jan Kiszka wrote:
>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>
>>>> This function is used by a later patch to parse the BDF of the device to
>>>> passthrough.
>>>>
>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>
>>> You probably want to parse the host address?  You don't want to copy the
>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>> for host. E.g. you need to support ARI etc.
>>
>> We should really consolidate over one parser for Xen, KVM device
>> assignment and VFIO. It looks like they all have very similar requirements.
> 
> Also rename pci_parse_devaddr to pci_parse_legacy_devaddr
> to stress it's not something others should reuse.

That depends on what pci_parse_devaddr will do in the end. If it will
become as general as my qemu_parse_pci_devaddr, "legacy" would be
inappropriate.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1SemFR-0004X4-Tb; Wed, 13 Jun 2012 12:00:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SemFP-0004Wj-PZ
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:00:28 +0000
Received: from [85.158.139.83:60608] by server-11.bemta-5.messagelabs.com id
	50/F5-20400-BD088DF4; Wed, 13 Jun 2012 12:00:27 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339588826!23512169!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDQyNjc2Mw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17074 invoked from network); 13 Jun 2012 12:00:26 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:00:26 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q5DC0JWH029643;
	Wed, 13 Jun 2012 14:00:20 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DC0Jkc004341;
	Wed, 13 Jun 2012 14:00:19 +0200
Message-ID: <4FD880D3.8090203@siemens.com>
Date: Wed, 13 Jun 2012 14:00:19 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-13 13:22, Stefano Stabellini wrote:
> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>
>>>> This function is used by a later patch to parse the BDF of the device to
>>>> passthrough.
>>>>
>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>
>>> You probably want to parse the host address?  You don't want to copy the
>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>> for host. E.g. you need to support ARI etc.
>>
>> We should really consolidate over one parser for Xen, KVM device
>> assignment and VFIO. It looks like they all have very similar requirements.
>>
>> For those how didn't follow the discussion, see patches 10-13 in
>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
> 
> I agree, actually it looks like patch 10 and 11 would be enough.
> 
> Maybe you could extract them and send them out separately?

They are still under discussion and waiting for some QOM refactorings to
be merged.

Will you be able to use an address parser via some device property?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1SemFR-0004X4-Tb; Wed, 13 Jun 2012 12:00:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SemFP-0004Wj-PZ
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:00:28 +0000
Received: from [85.158.139.83:60608] by server-11.bemta-5.messagelabs.com id
	50/F5-20400-BD088DF4; Wed, 13 Jun 2012 12:00:27 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339588826!23512169!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDQyNjc2Mw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17074 invoked from network); 13 Jun 2012 12:00:26 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:00:26 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q5DC0JWH029643;
	Wed, 13 Jun 2012 14:00:20 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DC0Jkc004341;
	Wed, 13 Jun 2012 14:00:19 +0200
Message-ID: <4FD880D3.8090203@siemens.com>
Date: Wed, 13 Jun 2012 14:00:19 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-13 13:22, Stefano Stabellini wrote:
> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>
>>>> This function is used by a later patch to parse the BDF of the device to
>>>> passthrough.
>>>>
>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>>>
>>> You probably want to parse the host address?  You don't want to copy the
>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>> for host. E.g. you need to support ARI etc.
>>
>> We should really consolidate over one parser for Xen, KVM device
>> assignment and VFIO. It looks like they all have very similar requirements.
>>
>> For those how didn't follow the discussion, see patches 10-13 in
>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
> 
> I agree, actually it looks like patch 10 and 11 would be enough.
> 
> Maybe you could extract them and send them out separately?

They are still under discussion and waiting for some QOM refactorings to
be merged.

Will you be able to use an address parser via some device property?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:22:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:22: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 1Semaf-00050o-UC; Wed, 13 Jun 2012 12:22:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1Semae-00050j-OW
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:22:24 +0000
Received: from [85.158.143.99:10440] by server-2.bemta-4.messagelabs.com id
	59/6A-17938-00688DF4; Wed, 13 Jun 2012 12:22:24 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339590139!32317977!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5120 invoked from network); 13 Jun 2012 12:22:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:22:23 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 107399290E;
	Wed, 13 Jun 2012 14:22:18 +0200 (CEST)
Message-ID: <4FD885F4.1060201@suse.de>
Date: Wed, 13 Jun 2012 14:22:12 +0200
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:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com>
In-Reply-To: <4FD880D3.8090203@siemens.com>
X-Enigmail-Version: 1.5pre
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V12 5/9] Revert "pci: don't
 export an internal 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 13.06.2012 14:00, schrieb Jan Kiszka:
> On 2012-06-13 13:22, Stefano Stabellini wrote:
>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>> We should really consolidate over one parser for Xen, KVM device
>>> assignment and VFIO. It looks like they all have very similar requireme=
nts.
>>>
>>> For those how didn't follow the discussion, see patches 10-13 in
>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>
>> I agree, actually it looks like patch 10 and 11 would be enough.
>>
>> Maybe you could extract them and send them out separately?
> =

> They are still under discussion and waiting for some QOM refactorings to
> be merged.

The first qom-next PULL is already merged into qemu.git (you should've
been cc'ed) and I'm actually waiting for you to rebase and send out a v2
and/or to let me know what your/mst's merge time frame is so that we can
coordinate the next PULLs.
Currently the semantics discussion looks like we won't merge Paolo's
qdev-properties.c movement, so the preview I posted is all that one of
us will have to rebase (on).

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 Wed Jun 13 12:22:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:22: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 1Semaf-00050o-UC; Wed, 13 Jun 2012 12:22:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1Semae-00050j-OW
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:22:24 +0000
Received: from [85.158.143.99:10440] by server-2.bemta-4.messagelabs.com id
	59/6A-17938-00688DF4; Wed, 13 Jun 2012 12:22:24 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339590139!32317977!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5120 invoked from network); 13 Jun 2012 12:22:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:22:23 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 107399290E;
	Wed, 13 Jun 2012 14:22:18 +0200 (CEST)
Message-ID: <4FD885F4.1060201@suse.de>
Date: Wed, 13 Jun 2012 14:22:12 +0200
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:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com>
In-Reply-To: <4FD880D3.8090203@siemens.com>
X-Enigmail-Version: 1.5pre
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V12 5/9] Revert "pci: don't
 export an internal 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 13.06.2012 14:00, schrieb Jan Kiszka:
> On 2012-06-13 13:22, Stefano Stabellini wrote:
>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>> We should really consolidate over one parser for Xen, KVM device
>>> assignment and VFIO. It looks like they all have very similar requireme=
nts.
>>>
>>> For those how didn't follow the discussion, see patches 10-13 in
>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>
>> I agree, actually it looks like patch 10 and 11 would be enough.
>>
>> Maybe you could extract them and send them out separately?
> =

> They are still under discussion and waiting for some QOM refactorings to
> be merged.

The first qom-next PULL is already merged into qemu.git (you should've
been cc'ed) and I'm actually waiting for you to rebase and send out a v2
and/or to let me know what your/mst's merge time frame is so that we can
coordinate the next PULLs.
Currently the semantics discussion looks like we won't merge Paolo's
qdev-properties.c movement, so the preview I posted is all that one of
us will have to rebase (on).

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 Wed Jun 13 12:41:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1Semsr-0005H0-R2; Wed, 13 Jun 2012 12:41:13 +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 1Semsq-0005Gs-A7
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:41:12 +0000
Received: from [85.158.138.51:3573] by server-11.bemta-3.messagelabs.com id
	14/ED-28329-76A88DF4; Wed, 13 Jun 2012 12:41:11 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339591269!27395703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31611 invoked from network); 13 Jun 2012 12:41:10 -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;
	13 Jun 2012 12:41:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330923600"; d="scan'208";a="198580629"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:40:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 08:40:20 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1Sems0-0003D2-6z;
	Wed, 13 Jun 2012 13:40:20 +0100
Message-ID: <4FD88A33.1080304@citrix.com>
Date: Wed, 13 Jun 2012 13:40:19 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com>
In-Reply-To: <4FD880D3.8090203@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 13/06/12 13:00, Jan Kiszka wrote:
> On 2012-06-13 13:22, Stefano Stabellini wrote:
>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>>
>>>>> This function is used by a later patch to parse the BDF of the device to
>>>>> passthrough.
>>>>>
>>>>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
>>>>
>>>> You probably want to parse the host address?  You don't want to copy the
>>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>>> for host. E.g. you need to support ARI etc.
>>>
>>> We should really consolidate over one parser for Xen, KVM device
>>> assignment and VFIO. It looks like they all have very similar requirements.
>>>
>>> For those how didn't follow the discussion, see patches 10-13 in
>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>
>> I agree, actually it looks like patch 10 and 11 would be enough.
>>
>> Maybe you could extract them and send them out separately?
>
> They are still under discussion and waiting for some QOM refactorings to
> be merged.
>
> Will you be able to use an address parser via some device property?

Yes. Actually, the address is already a device property.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:41:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1Semsr-0005H0-R2; Wed, 13 Jun 2012 12:41:13 +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 1Semsq-0005Gs-A7
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:41:12 +0000
Received: from [85.158.138.51:3573] by server-11.bemta-3.messagelabs.com id
	14/ED-28329-76A88DF4; Wed, 13 Jun 2012 12:41:11 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339591269!27395703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31611 invoked from network); 13 Jun 2012 12:41:10 -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;
	13 Jun 2012 12:41:10 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330923600"; d="scan'208";a="198580629"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 08:40:20 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 08:40:20 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1Sems0-0003D2-6z;
	Wed, 13 Jun 2012 13:40:20 +0100
Message-ID: <4FD88A33.1080304@citrix.com>
Date: Wed, 13 Jun 2012 13:40:19 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com>
In-Reply-To: <4FD880D3.8090203@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 13/06/12 13:00, Jan Kiszka wrote:
> On 2012-06-13 13:22, Stefano Stabellini wrote:
>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>>
>>>>> This function is used by a later patch to parse the BDF of the device to
>>>>> passthrough.
>>>>>
>>>>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
>>>>
>>>> You probably want to parse the host address?  You don't want to copy the
>>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>>> for host. E.g. you need to support ARI etc.
>>>
>>> We should really consolidate over one parser for Xen, KVM device
>>> assignment and VFIO. It looks like they all have very similar requirements.
>>>
>>> For those how didn't follow the discussion, see patches 10-13 in
>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>
>> I agree, actually it looks like patch 10 and 11 would be enough.
>>
>> Maybe you could extract them and send them out separately?
>
> They are still under discussion and waiting for some QOM refactorings to
> be merged.
>
> Will you be able to use an address parser via some device property?

Yes. Actually, the address is already a device property.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:43:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1SemuN-0005Kt-Dn; Wed, 13 Jun 2012 12:42:47 +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 1SemuL-0005Kg-U6
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:42:46 +0000
Received: from [85.158.143.99:25235] by server-1.bemta-4.messagelabs.com id
	AB/43-24392-5CA88DF4; Wed, 13 Jun 2012 12:42:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339591363!27317416!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk1NDIw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5515 invoked from network); 13 Jun 2012 12:42:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Jun 2012 12:42:44 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 13 Jun 2012 05:37:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="155767397"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 13 Jun 2012 05:37:42 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 13 Jun 2012 05:37:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Wed, 13 Jun 2012 20:37:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
Thread-Index: AQHNSVltOYFQl4PoQNeTRPYYZQub0Zb4J+FA
Date: Wed, 13 Jun 2012 12:37:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522F152@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
	<4FD8713B0200007800089A77@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
	<4FD898770200007800089BE1@nat28.tlf.novell.com>
In-Reply-To: <4FD898770200007800089BE1@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: Keir Fraser <keir@xen.org>, "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 13.06.12 at 12:49, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 13.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Xen vMCE bugfix: inject vMCE# to all vcpus
>>>> 
>>>> In our test for win8 guest mce, we find a bug in that no matter
>>>> what SRAO/SRAR error xen inject to win8 guest, it always reboot.
>>>> 
>>>> The root cause is, current Xen vMCE logic inject vMCE# only to
>>>> vcpu0, this is not correct for Intel MCE (Under Intel arch, h/w
>>>> generate MCE# to all CPUs). 
>>>> 
>>>> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.
>>> 
>>> I see no correlation between the fix (and its description) and the
>>> problem at hand: Why would Win8 reboot if it doesn't receive a
>>> particular MCE on all CPUs? Isn't that model specific behavior?
>> 
>> It's not model specific. For Intel processor, MCE# is broadcast to
>> all logical processors on the system on which the UCR errors are
>> supported (refer Intel SDM 15.9.3.1 & 15.9.3.2). So for vMCE
>> injection under Intel arch, it's a bug if inject vMCE# only to vcpu0.
> 
> This is for a certain group of errors, but I can't find any statement
> that this is general architectural behavior.

Xen mce only inject SRAO/SRAR error to guest, which both belong to UCR error.
For other error like CE and UCNA, hypervisor just virq to dom0 mcelog for logging.

> 
>>> Furthermore I doubt that an MCE on one socket indeed causes
>>> MCE-s on all other sockets, not to speak of distinct NUMA nodes
>>> (it would already surprise me if MCE-s got broadcast across cores
>>> within a socket, unless they are caused by a resource shared
>>> across cores).
>> 
>> Somehow I agree. But at least currently from Intel SDM,
>> architecturally it would broadcast.
> 
> I can't even see how this would work reliably across packages or
> nodes: Suppose two entities each encounter a UCR - they would
> each signal the other one, and the handling of this signal would
> need to be synchronized with the handling of the local UCR
> (irrespective of the order in which the events arrive).

I don't think h/w story being so, though I in fact don't have all details.

Basically, processor is just a 'report point' (via bank) to indicate what error occur. For example, error (mostly) generated at memory and transfer through footpoints e.g. memory --> memory controller --> QPI --> cache controller --> ... --> ... --> cpu core. It's not one processor signaling the other cpu. A mca mechanism monitor different units decide when and what error reported, and notify all processors (that's what broadcast mean).

> 
>>>> +        if ( !test_and_set_bool(v->mce_pending) &&
>>>> +            ((d->is_hvm) ? 1 :
>>>> +            guest_has_trap_callback(d, v->vcpu_id,
>>>> TRAP_machine_check)) )
>>> 
>>> Quite strange a way to say
>>> 
>>>             (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id,
>>> TRAP_machine_check))
>> 
>> For hvm it's OK to just set v->mce_pending. While for pv it need
>> also check if guest callback has been registered.
> 
> Sure. I was just asking why you use a conditional operator when
> the simpler || would do.

Ah I see. It's better.

> 
>>>> +        {
>>>> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d
>>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id); +   
>>>> vcpu_kick(v); +        }
>>>> +        else
>>>> +        {
>>>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>>> +            return -1;
>>> 
>>> Why do you bail here? This is particularly bad if v->mce_pending
>>> was already set on some vCPU (as that could simply mean the guest
>>> just didn't get around to handle the vMCE yet).
>> 
>> the case v->mce_pending already set while new vmce come will result
>> in domain crash. I don't think guest can still handle this case,
>> e.g. under baremetal if 2nd mce occur while 1st mce have not been
>> handled os will reboot directly. 
> 
> Sorry, no. This goes back to the questionable nature of the
> broadcasting above - if a CPU encounters a UCR itself and gets
> signaled of a remote CPU having encountered one, it should be
> able to cope. Otherwise the risk of (pointless!) system death
> would increase with the number of CPUs.
> 
>>> Also, how does this whole change interact with vmce_{rd,wr}msr()?
>>> The struct bank_entry instances live on a per-domain list, so the
>>> vMCE being delivered to all vCPU-s means they will all race for the
>>> single entry (and might erroneously access others, particularly in
>>> vmce_wrmsr()'s MCG_STATUS handling).
>> 
>> Yes, I agree.
>> However, recently we have done vMCE re-design work (ongoing some
>> internal review) and would present sooner. In new approach, MSRs are
>> per-vcpu instead of per-domain.  MSRs race issue (and the effort to
>> make it clean) would be pointless then. So at this butfix patch, I
>> only touch vMCE# injection itself. 
> 
> I understand that you want the simpler version as bug fix, but
> you didn't answer whether it was at all verified that the single
> per-domain entry logic would actually cope with the broadcast
> delivery logic you're adding here. I'm afraid the per-vCPU entry
> logic is a prerequisite to this change (in whatever form it may end
> up going in).
> 
> Jan

Agree, let's hold it. After we present new vMCE approach, we can do it at that time, and no race issue then.

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 Jun 13 12:43:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1SemuN-0005Kt-Dn; Wed, 13 Jun 2012 12:42:47 +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 1SemuL-0005Kg-U6
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:42:46 +0000
Received: from [85.158.143.99:25235] by server-1.bemta-4.messagelabs.com id
	AB/43-24392-5CA88DF4; Wed, 13 Jun 2012 12:42:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339591363!27317416!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk1NDIw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5515 invoked from network); 13 Jun 2012 12:42:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Jun 2012 12:42:44 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 13 Jun 2012 05:37:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="155767397"
Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193])
	by azsmga001.ch.intel.com with ESMTP; 13 Jun 2012 05:37:42 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 13 Jun 2012 05:37:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Wed, 13 Jun 2012 20:37:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
Thread-Index: AQHNSVltOYFQl4PoQNeTRPYYZQub0Zb4J+FA
Date: Wed, 13 Jun 2012 12:37:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233522F152@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233522B51C@SHSMSX101.ccr.corp.intel.com>
	<4FD8713B0200007800089A77@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233522ECA7@SHSMSX101.ccr.corp.intel.com>
	<4FD898770200007800089BE1@nat28.tlf.novell.com>
In-Reply-To: <4FD898770200007800089BE1@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: Keir Fraser <keir@xen.org>, "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	"Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen vMCE bugfix: inject vMCE# to all vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 13.06.12 at 12:49, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 13.06.12 at 10:05, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Xen vMCE bugfix: inject vMCE# to all vcpus
>>>> 
>>>> In our test for win8 guest mce, we find a bug in that no matter
>>>> what SRAO/SRAR error xen inject to win8 guest, it always reboot.
>>>> 
>>>> The root cause is, current Xen vMCE logic inject vMCE# only to
>>>> vcpu0, this is not correct for Intel MCE (Under Intel arch, h/w
>>>> generate MCE# to all CPUs). 
>>>> 
>>>> This patch fix vMCE injection bug, injecting vMCE# to all vcpus.
>>> 
>>> I see no correlation between the fix (and its description) and the
>>> problem at hand: Why would Win8 reboot if it doesn't receive a
>>> particular MCE on all CPUs? Isn't that model specific behavior?
>> 
>> It's not model specific. For Intel processor, MCE# is broadcast to
>> all logical processors on the system on which the UCR errors are
>> supported (refer Intel SDM 15.9.3.1 & 15.9.3.2). So for vMCE
>> injection under Intel arch, it's a bug if inject vMCE# only to vcpu0.
> 
> This is for a certain group of errors, but I can't find any statement
> that this is general architectural behavior.

Xen mce only inject SRAO/SRAR error to guest, which both belong to UCR error.
For other error like CE and UCNA, hypervisor just virq to dom0 mcelog for logging.

> 
>>> Furthermore I doubt that an MCE on one socket indeed causes
>>> MCE-s on all other sockets, not to speak of distinct NUMA nodes
>>> (it would already surprise me if MCE-s got broadcast across cores
>>> within a socket, unless they are caused by a resource shared
>>> across cores).
>> 
>> Somehow I agree. But at least currently from Intel SDM,
>> architecturally it would broadcast.
> 
> I can't even see how this would work reliably across packages or
> nodes: Suppose two entities each encounter a UCR - they would
> each signal the other one, and the handling of this signal would
> need to be synchronized with the handling of the local UCR
> (irrespective of the order in which the events arrive).

I don't think h/w story being so, though I in fact don't have all details.

Basically, processor is just a 'report point' (via bank) to indicate what error occur. For example, error (mostly) generated at memory and transfer through footpoints e.g. memory --> memory controller --> QPI --> cache controller --> ... --> ... --> cpu core. It's not one processor signaling the other cpu. A mca mechanism monitor different units decide when and what error reported, and notify all processors (that's what broadcast mean).

> 
>>>> +        if ( !test_and_set_bool(v->mce_pending) &&
>>>> +            ((d->is_hvm) ? 1 :
>>>> +            guest_has_trap_callback(d, v->vcpu_id,
>>>> TRAP_machine_check)) )
>>> 
>>> Quite strange a way to say
>>> 
>>>             (d->is_hvm || guest_has_trap_callback(d, v->vcpu_id,
>>> TRAP_machine_check))
>> 
>> For hvm it's OK to just set v->mce_pending. While for pv it need
>> also check if guest callback has been registered.
> 
> Sure. I was just asking why you use a conditional operator when
> the simpler || would do.

Ah I see. It's better.

> 
>>>> +        {
>>>> +            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d
>>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id); +   
>>>> vcpu_kick(v); +        }
>>>> +        else
>>>> +        {
>>>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>>> +            return -1;
>>> 
>>> Why do you bail here? This is particularly bad if v->mce_pending
>>> was already set on some vCPU (as that could simply mean the guest
>>> just didn't get around to handle the vMCE yet).
>> 
>> the case v->mce_pending already set while new vmce come will result
>> in domain crash. I don't think guest can still handle this case,
>> e.g. under baremetal if 2nd mce occur while 1st mce have not been
>> handled os will reboot directly. 
> 
> Sorry, no. This goes back to the questionable nature of the
> broadcasting above - if a CPU encounters a UCR itself and gets
> signaled of a remote CPU having encountered one, it should be
> able to cope. Otherwise the risk of (pointless!) system death
> would increase with the number of CPUs.
> 
>>> Also, how does this whole change interact with vmce_{rd,wr}msr()?
>>> The struct bank_entry instances live on a per-domain list, so the
>>> vMCE being delivered to all vCPU-s means they will all race for the
>>> single entry (and might erroneously access others, particularly in
>>> vmce_wrmsr()'s MCG_STATUS handling).
>> 
>> Yes, I agree.
>> However, recently we have done vMCE re-design work (ongoing some
>> internal review) and would present sooner. In new approach, MSRs are
>> per-vcpu instead of per-domain.  MSRs race issue (and the effort to
>> make it clean) would be pointless then. So at this butfix patch, I
>> only touch vMCE# injection itself. 
> 
> I understand that you want the simpler version as bug fix, but
> you didn't answer whether it was at all verified that the single
> per-domain entry logic would actually cope with the broadcast
> delivery logic you're adding here. I'm afraid the per-vCPU entry
> logic is a prerequisite to this change (in whatever form it may end
> up going in).
> 
> Jan

Agree, let's hold it. After we present new vMCE approach, we can do it at that time, and no race issue then.

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 Jun 13 12:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1Semzs-0005X8-72; Wed, 13 Jun 2012 12:48:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Semzq-0005X2-Ly
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:48:26 +0000
Received: from [85.158.143.99:64305] by server-3.bemta-4.messagelabs.com id
	0B/9F-05808-91C88DF4; Wed, 13 Jun 2012 12:48:25 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339591705!32088050!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDQyNjc2Mw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10188 invoked from network); 13 Jun 2012 12:48:25 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:48:25 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmGCO030939;
	Wed, 13 Jun 2012 14:48:16 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmDcj007658;
	Wed, 13 Jun 2012 14:48:13 +0200
Message-ID: <4FD88C0D.10304@siemens.com>
Date: Wed, 13 Jun 2012 14:48:13 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
In-Reply-To: <4FD88A33.1080304@citrix.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-13 14:40, Anthony PERARD wrote:
> On 13/06/12 13:00, Jan Kiszka wrote:
>> On 2012-06-13 13:22, Stefano Stabellini wrote:
>>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>>>
>>>>>> This function is used by a later patch to parse the BDF of the device to
>>>>>> passthrough.
>>>>>>
>>>>>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
>>>>>
>>>>> You probably want to parse the host address?  You don't want to copy the
>>>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>>>> for host. E.g. you need to support ARI etc.
>>>>
>>>> We should really consolidate over one parser for Xen, KVM device
>>>> assignment and VFIO. It looks like they all have very similar requirements.
>>>>
>>>> For those how didn't follow the discussion, see patches 10-13 in
>>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>>
>>> I agree, actually it looks like patch 10 and 11 would be enough.
>>>
>>> Maybe you could extract them and send them out separately?
>>
>> They are still under discussion and waiting for some QOM refactorings to
>> be merged.
>>
>> Will you be able to use an address parser via some device property?
> 
> Yes. Actually, the address is already a device property.
> 

Great. Then we should try to come up with a common pci-host-devaddr
property everyone can use.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1Semzs-0005X8-72; Wed, 13 Jun 2012 12:48:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Semzq-0005X2-Ly
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:48:26 +0000
Received: from [85.158.143.99:64305] by server-3.bemta-4.messagelabs.com id
	0B/9F-05808-91C88DF4; Wed, 13 Jun 2012 12:48:25 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339591705!32088050!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDQyNjc2Mw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10188 invoked from network); 13 Jun 2012 12:48:25 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:48:25 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmGCO030939;
	Wed, 13 Jun 2012 14:48:16 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmDcj007658;
	Wed, 13 Jun 2012 14:48:13 +0200
Message-ID: <4FD88C0D.10304@siemens.com>
Date: Wed, 13 Jun 2012 14:48:13 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
In-Reply-To: <4FD88A33.1080304@citrix.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-13 14:40, Anthony PERARD wrote:
> On 13/06/12 13:00, Jan Kiszka wrote:
>> On 2012-06-13 13:22, Stefano Stabellini wrote:
>>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>>> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
>>>>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
>>>>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
>>>>>>
>>>>>> This function is used by a later patch to parse the BDF of the device to
>>>>>> passthrough.
>>>>>>
>>>>>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
>>>>>
>>>>> You probably want to parse the host address?  You don't want to copy the
>>>>> bugs in pci_parse_devaddr - write your own that has sane semantics
>>>>> for host. E.g. you need to support ARI etc.
>>>>
>>>> We should really consolidate over one parser for Xen, KVM device
>>>> assignment and VFIO. It looks like they all have very similar requirements.
>>>>
>>>> For those how didn't follow the discussion, see patches 10-13 in
>>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>>
>>> I agree, actually it looks like patch 10 and 11 would be enough.
>>>
>>> Maybe you could extract them and send them out separately?
>>
>> They are still under discussion and waiting for some QOM refactorings to
>> be merged.
>>
>> Will you be able to use an address parser via some device property?
> 
> Yes. Actually, the address is already a device property.
> 

Great. Then we should try to come up with a common pci-host-devaddr
property everyone can use.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:49:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1Sen0U-0005Yz-KZ; Wed, 13 Jun 2012 12:49:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Sen0T-0005Yq-A0
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:49:05 +0000
Received: from [85.158.143.99:9803] by server-3.bemta-4.messagelabs.com id
	D8/A0-05808-04C88DF4; Wed, 13 Jun 2012 12:49:04 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339591743!32323552!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDQzMzMzNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11282 invoked from network); 13 Jun 2012 12:49:04 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:49:04 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmxCD002351;
	Wed, 13 Jun 2012 14:48:59 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmxZa009207;
	Wed, 13 Jun 2012 14:48:59 +0200
Message-ID: <4FD88C3B.7030401@siemens.com>
Date: Wed, 13 Jun 2012 14:48:59 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD885F4.1060201@suse.de>
In-Reply-To: <4FD885F4.1060201@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V12 5/9] Revert "pci: don't
 export an internal 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-06-13 14:22, Andreas F=E4rber wrote:
> Am 13.06.2012 14:00, schrieb Jan Kiszka:
>> On 2012-06-13 13:22, Stefano Stabellini wrote:
>>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>>> We should really consolidate over one parser for Xen, KVM device
>>>> assignment and VFIO. It looks like they all have very similar requirem=
ents.
>>>>
>>>> For those how didn't follow the discussion, see patches 10-13 in
>>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>>
>>> I agree, actually it looks like patch 10 and 11 would be enough.
>>>
>>> Maybe you could extract them and send them out separately?
>>
>> They are still under discussion and waiting for some QOM refactorings to
>> be merged.
> =

> The first qom-next PULL is already merged into qemu.git (you should've
> been cc'ed) and I'm actually waiting for you to rebase and send out a v2
> and/or to let me know what your/mst's merge time frame is so that we can
> coordinate the next PULLs.
> Currently the semantics discussion looks like we won't merge Paolo's
> qdev-properties.c movement, so the preview I posted is all that one of
> us will have to rebase (on).

Thanks for the update! I didn't follow the latest details due to local
overload.

I would say, give us one or two days to define how v2 of that pci
address property should look like. If we cannot agree, you should bypass
with your next step.

Jan

-- =

Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:49:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1Sen0U-0005Yz-KZ; Wed, 13 Jun 2012 12:49:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Sen0T-0005Yq-A0
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:49:05 +0000
Received: from [85.158.143.99:9803] by server-3.bemta-4.messagelabs.com id
	D8/A0-05808-04C88DF4; Wed, 13 Jun 2012 12:49:04 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339591743!32323552!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDQzMzMzNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11282 invoked from network); 13 Jun 2012 12:49:04 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 12:49:04 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmxCD002351;
	Wed, 13 Jun 2012 14:48:59 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5DCmxZa009207;
	Wed, 13 Jun 2012 14:48:59 +0200
Message-ID: <4FD88C3B.7030401@siemens.com>
Date: Wed, 13 Jun 2012 14:48:59 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD885F4.1060201@suse.de>
In-Reply-To: <4FD885F4.1060201@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V12 5/9] Revert "pci: don't
 export an internal 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-06-13 14:22, Andreas F=E4rber wrote:
> Am 13.06.2012 14:00, schrieb Jan Kiszka:
>> On 2012-06-13 13:22, Stefano Stabellini wrote:
>>> On Wed, 13 Jun 2012, Jan Kiszka wrote:
>>>> We should really consolidate over one parser for Xen, KVM device
>>>> assignment and VFIO. It looks like they all have very similar requirem=
ents.
>>>>
>>>> For those how didn't follow the discussion, see patches 10-13 in
>>>> http://thread.gmane.org/gmane.comp.emulators.qemu/153728.
>>>
>>> I agree, actually it looks like patch 10 and 11 would be enough.
>>>
>>> Maybe you could extract them and send them out separately?
>>
>> They are still under discussion and waiting for some QOM refactorings to
>> be merged.
> =

> The first qom-next PULL is already merged into qemu.git (you should've
> been cc'ed) and I'm actually waiting for you to rebase and send out a v2
> and/or to let me know what your/mst's merge time frame is so that we can
> coordinate the next PULLs.
> Currently the semantics discussion looks like we won't merge Paolo's
> qdev-properties.c movement, so the preview I posted is all that one of
> us will have to rebase (on).

Thanks for the update! I didn't follow the latest details due to local
overload.

I would say, give us one or two days to define how v2 of that pci
address property should look like. If we cannot agree, you should bypass
with your next step.

Jan

-- =

Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:53:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:53: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 1Sen4O-0005oQ-Cm; Wed, 13 Jun 2012 12:53: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 1Sen4M-0005oE-RG
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:53:07 +0000
Received: from [85.158.138.51:57724] by server-2.bemta-3.messagelabs.com id
	F2/EC-16299-D2D88DF4; Wed, 13 Jun 2012 12:53:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339591980!23390807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19537 invoked from network); 13 Jun 2012 12:53:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:52:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:52:36 +0100
Message-ID: <1339591954.24104.200.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:52:34 +0100
In-Reply-To: <1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
 logdirty command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> The current migration code in libxl instructs qemu to start or stop
> logdirty, but it does not wait for an acknowledgement from qemu before
> continuing.  This might lead to memory corruption (!)
> 
> Fix this by waiting for qemu to acknowledge the command.
> 
> Unfortunately the necessary ao arrangements for waiting for this
> command are unique because qemu has a special protocol for this
> particular operation.
> 
> Also, this change means that the switch_qemu_logdirty callback
> implementation in libxl can no longer synchronously produce its return
> value, as it now needs to wait for xenstore.  So we tell the
> marshalling code generator that it is a message which does not need a
> reply.  This turns the callback function called by the marshaller into
> one which returns void; the callback function arranges to later
> explicitly sends the reply to the helper, when the xs watch triggers
> and the appropriate value is read from xenstore.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c            |  176 +++++++++++++++++++++++++++++++++---
>  tools/libxl/libxl_internal.h       |   18 ++++-
>  tools/libxl/libxl_save_callout.c   |    8 ++
>  tools/libxl/libxl_save_msgs_gen.pl |    7 +-
>  4 files changed, 193 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index a597627..d5ac79f 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -528,30 +528,180 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>  static void domain_suspend_done(libxl__egc *egc,
>                          libxl__domain_suspend_state *dss, int rc);
> 
> -/*----- callbacks, called by xc_domain_save -----*/
> +/*----- complicated callback, called by xc_domain_save -----*/
> +
> +/*
> + * We implement the other end of protocol for controlling qemu-dm's
> + * logdirty.  There is no documentation for this protocol, but our
> + * counterparty's implementation is in
> + * qemu-xen-traditional.git:xenstore.c in the function
> + * xenstore_process_logdirty_event
> + */
> +
> +static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
> +                                    const struct timeval *requested_abs);
> +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
> +                            const char *watch_path, const char *event_path);
> +static void switch_logdirty_done(libxl__egc *egc,
> +                                 libxl__domain_suspend_state *dss, int ok);
> 
> -int libxl__domain_suspend_common_switch_qemu_logdirty
> +static void logdirty_init(libxl__logdirty_switch *lds)
> +{
> +    lds->cmd_path = 0;
> +    libxl__ev_xswatch_init(&lds->watch);
> +    libxl__ev_time_init(&lds->timeout);

I meant to mention this once before when reviewing some patch or other
but I'm not sure I actually did, so at the risk of repeating myself:

This watch with timeout pattern seems to be reasonably common (in fact,
I'm not sure we have any watches without a timeout). It might be a
candidate for a specific helper routine in the future?

[...]
> +static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
> +                                    const struct timeval *requested_abs)
> +{
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
> +    STATE_AO_GC(dss->ao);
> +    LOG(ERROR,"logdirty switch: wait for device model timed out");
> +    switch_logdirty_done(egc,dss,0);
>  }
> 
> +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
> +                            const char *watch_path, const char *event_path)
> +{
> +    libxl__domain_suspend_state *dss =
> +        CONTAINER_OF(watch, *dss, logdirty.watch);
> +    libxl__logdirty_switch *lds = &dss->logdirty;
> +    STATE_AO_GC(dss->ao);
> +    const char *got;
> +    xs_transaction_t t = 0;
> +    int rc;
> +
> +    for (;;) {
> +        rc = libxl__xs_transaction_start(gc, &t);
> +        if (rc) goto out;
> +
> +        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
> +        if (rc) goto out;
> +
> +        if (!got) {
> +            rc = +1;
> +            goto out;
> +        }
> +
> +        if (strcmp(got, lds->cmd)) {
> +            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
> +                " (xenstore paths `%s' / `%s')", lds->cmd, got,
> +                lds->cmd_path, lds->ret_path);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +
> +        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
> +        if (rc) goto out;
> +
> +        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
> +        if (rc) goto out;
> +
> +        rc = libxl__xs_transaction_commit(gc, &t);
> +        if (!rc) break;
> +        if (rc<0) goto out;
> +    }
> +
> + out:
> +    /* rc < 0: error
> +     * rc == 0: ok, we are done
> +     * rc == +1: need to keep waiting
> +     */
> +    libxl__xs_transaction_abort(gc, &t);
> +
> +    if (!rc) {
> +        switch_logdirty_done(egc,dss,1);
> +    } else if (rc < 0) {
> +        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);

Is it only "response read failed" which can cause us to end up here,
looks like the read, rm etc could do it?

Anyway, I've got no substantive comments so:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> +        switch_logdirty_done(egc,dss,0);
> +    }
> +}
[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:53:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:53: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 1Sen4O-0005oQ-Cm; Wed, 13 Jun 2012 12:53: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 1Sen4M-0005oE-RG
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:53:07 +0000
Received: from [85.158.138.51:57724] by server-2.bemta-3.messagelabs.com id
	F2/EC-16299-D2D88DF4; Wed, 13 Jun 2012 12:53:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339591980!23390807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19537 invoked from network); 13 Jun 2012 12:53:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:52:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:52:36 +0100
Message-ID: <1339591954.24104.200.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:52:34 +0100
In-Reply-To: <1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
 logdirty command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> The current migration code in libxl instructs qemu to start or stop
> logdirty, but it does not wait for an acknowledgement from qemu before
> continuing.  This might lead to memory corruption (!)
> 
> Fix this by waiting for qemu to acknowledge the command.
> 
> Unfortunately the necessary ao arrangements for waiting for this
> command are unique because qemu has a special protocol for this
> particular operation.
> 
> Also, this change means that the switch_qemu_logdirty callback
> implementation in libxl can no longer synchronously produce its return
> value, as it now needs to wait for xenstore.  So we tell the
> marshalling code generator that it is a message which does not need a
> reply.  This turns the callback function called by the marshaller into
> one which returns void; the callback function arranges to later
> explicitly sends the reply to the helper, when the xs watch triggers
> and the appropriate value is read from xenstore.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c            |  176 +++++++++++++++++++++++++++++++++---
>  tools/libxl/libxl_internal.h       |   18 ++++-
>  tools/libxl/libxl_save_callout.c   |    8 ++
>  tools/libxl/libxl_save_msgs_gen.pl |    7 +-
>  4 files changed, 193 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index a597627..d5ac79f 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -528,30 +528,180 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>  static void domain_suspend_done(libxl__egc *egc,
>                          libxl__domain_suspend_state *dss, int rc);
> 
> -/*----- callbacks, called by xc_domain_save -----*/
> +/*----- complicated callback, called by xc_domain_save -----*/
> +
> +/*
> + * We implement the other end of protocol for controlling qemu-dm's
> + * logdirty.  There is no documentation for this protocol, but our
> + * counterparty's implementation is in
> + * qemu-xen-traditional.git:xenstore.c in the function
> + * xenstore_process_logdirty_event
> + */
> +
> +static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
> +                                    const struct timeval *requested_abs);
> +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
> +                            const char *watch_path, const char *event_path);
> +static void switch_logdirty_done(libxl__egc *egc,
> +                                 libxl__domain_suspend_state *dss, int ok);
> 
> -int libxl__domain_suspend_common_switch_qemu_logdirty
> +static void logdirty_init(libxl__logdirty_switch *lds)
> +{
> +    lds->cmd_path = 0;
> +    libxl__ev_xswatch_init(&lds->watch);
> +    libxl__ev_time_init(&lds->timeout);

I meant to mention this once before when reviewing some patch or other
but I'm not sure I actually did, so at the risk of repeating myself:

This watch with timeout pattern seems to be reasonably common (in fact,
I'm not sure we have any watches without a timeout). It might be a
candidate for a specific helper routine in the future?

[...]
> +static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
> +                                    const struct timeval *requested_abs)
> +{
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
> +    STATE_AO_GC(dss->ao);
> +    LOG(ERROR,"logdirty switch: wait for device model timed out");
> +    switch_logdirty_done(egc,dss,0);
>  }
> 
> +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
> +                            const char *watch_path, const char *event_path)
> +{
> +    libxl__domain_suspend_state *dss =
> +        CONTAINER_OF(watch, *dss, logdirty.watch);
> +    libxl__logdirty_switch *lds = &dss->logdirty;
> +    STATE_AO_GC(dss->ao);
> +    const char *got;
> +    xs_transaction_t t = 0;
> +    int rc;
> +
> +    for (;;) {
> +        rc = libxl__xs_transaction_start(gc, &t);
> +        if (rc) goto out;
> +
> +        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
> +        if (rc) goto out;
> +
> +        if (!got) {
> +            rc = +1;
> +            goto out;
> +        }
> +
> +        if (strcmp(got, lds->cmd)) {
> +            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
> +                " (xenstore paths `%s' / `%s')", lds->cmd, got,
> +                lds->cmd_path, lds->ret_path);
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +
> +        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
> +        if (rc) goto out;
> +
> +        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
> +        if (rc) goto out;
> +
> +        rc = libxl__xs_transaction_commit(gc, &t);
> +        if (!rc) break;
> +        if (rc<0) goto out;
> +    }
> +
> + out:
> +    /* rc < 0: error
> +     * rc == 0: ok, we are done
> +     * rc == +1: need to keep waiting
> +     */
> +    libxl__xs_transaction_abort(gc, &t);
> +
> +    if (!rc) {
> +        switch_logdirty_done(egc,dss,1);
> +    } else if (rc < 0) {
> +        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);

Is it only "response read failed" which can cause us to end up here,
looks like the read, rm etc could do it?

Anyway, I've got no substantive comments so:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> +        switch_logdirty_done(egc,dss,0);
> +    }
> +}
[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:53:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sen4c-0005qN-U1; Wed, 13 Jun 2012 12:53: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 1Sen4b-0005qC-NL
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:53:21 +0000
Received: from [85.158.138.51:33392] by server-1.bemta-3.messagelabs.com id
	8C/89-01327-04D88DF4; Wed, 13 Jun 2012 12:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339592000!21084932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 721 invoked from network); 13 Jun 2012 12:53:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:53:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:53:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:53:20 +0100
Message-ID: <1339591998.24104.201.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:53:18 +0100
In-Reply-To: <1339176870-32652-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/19] libxl: datacopier: provide "prefix
 data" facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> This will be used to write the qemu data banner to the save/migration
> stream.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:53:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sen4c-0005qN-U1; Wed, 13 Jun 2012 12:53: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 1Sen4b-0005qC-NL
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:53:21 +0000
Received: from [85.158.138.51:33392] by server-1.bemta-3.messagelabs.com id
	8C/89-01327-04D88DF4; Wed, 13 Jun 2012 12:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339592000!21084932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 721 invoked from network); 13 Jun 2012 12:53:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:53:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:53:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:53:20 +0100
Message-ID: <1339591998.24104.201.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:53:18 +0100
In-Reply-To: <1339176870-32652-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/19] libxl: datacopier: provide "prefix
 data" facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> This will be used to write the qemu data banner to the save/migration
> stream.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:54:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:54: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 1Sen5c-0005xQ-Bo; Wed, 13 Jun 2012 12:54:24 +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 1Sen5a-0005xE-Sh
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 12:54:22 +0000
Received: from [85.158.143.99:8363] by server-3.bemta-4.messagelabs.com id
	C3/1A-05808-E7D88DF4; Wed, 13 Jun 2012 12:54:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339592061!27372424!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2536 invoked from network); 13 Jun 2012 12:54:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 12:54:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo62) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v00282o5DAl6eT ;
	Wed, 13 Jun 2012 14:54:20 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 7FAF218638; Wed, 13 Jun 2012 14:54:18 +0200 (CEST)
Date: Wed, 13 Jun 2012 14:54:18 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120613125418.GA27889@aepfle.de>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339575245.24104.127.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 13, Ian Campbell wrote:

> On Wed, 2012-06-13 at 09:01 +0100, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1339572293 -7200
> > # Node ID ea554d05821b95a7e96e4a25cbf953c5abe35aeb
> > # Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
> > tools/configure.ac: add version check for glib2
> > 
> > xen-unstable fails to build in a SLES10SP4 environment since a long time
> > because the included version of glib is slightly older than the required
> > glib version. According to the docs glib version 2.12 includes base64
> > support, but SLES10 is shipped with glib 2.8.6:
> > 
> > qemu-timer-common.o: In function `init_get_clock':
> > /usr/src/packages/BUILD/xen-4.2.25432/non-dbg/tools/qemu-xen-dir/qemu-timer-common.c:57:
> > undefined reference to `clock_gettime'
> > qga/guest-agent-commands.o: In function `qmp_guest_file_write':
> > qga/guest-agent-commands.c:249: undefined reference to `g_base64_decode'
> > qga/guest-agent-commands.o: In function `qmp_guest_file_read':
> > qga/guest-agent-commands.c:224: undefined reference to `g_base64_encode'
> > collect2: ld returned 1 exit status
> > make[3]: *** [qemu-ga] Error 1
> > 
> > Add a version check to configure to require at least glib 2.12 to build
> > qemu-upstream.
> 
> Does this cause configure to fail or does it cause us to just not build
> qemu-upstream? I think the former (which is fine with me) but your last
> sentence suggests that latter.

I will resend with this change:

Add a version check to toplevel configure to require at least glib 2.12.
This makes sure configure can detect the condition early instead of
failing later in the middle of tools build when qemu-upstream errors
out.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:54:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:54: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 1Sen5c-0005xQ-Bo; Wed, 13 Jun 2012 12:54:24 +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 1Sen5a-0005xE-Sh
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 12:54:22 +0000
Received: from [85.158.143.99:8363] by server-3.bemta-4.messagelabs.com id
	C3/1A-05808-E7D88DF4; Wed, 13 Jun 2012 12:54:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339592061!27372424!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2536 invoked from network); 13 Jun 2012 12:54:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 12:54:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo62) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v00282o5DAl6eT ;
	Wed, 13 Jun 2012 14:54:20 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 7FAF218638; Wed, 13 Jun 2012 14:54:18 +0200 (CEST)
Date: Wed, 13 Jun 2012 14:54:18 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120613125418.GA27889@aepfle.de>
References: <patchbomb.1339574504@probook.site>
	<ea554d05821b95a7e96e.1339574505@probook.site>
	<1339575245.24104.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339575245.24104.127.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 13, Ian Campbell wrote:

> On Wed, 2012-06-13 at 09:01 +0100, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1339572293 -7200
> > # Node ID ea554d05821b95a7e96e4a25cbf953c5abe35aeb
> > # Parent  a70b35deb2b5592cc1b2363860f21bb2c7049885
> > tools/configure.ac: add version check for glib2
> > 
> > xen-unstable fails to build in a SLES10SP4 environment since a long time
> > because the included version of glib is slightly older than the required
> > glib version. According to the docs glib version 2.12 includes base64
> > support, but SLES10 is shipped with glib 2.8.6:
> > 
> > qemu-timer-common.o: In function `init_get_clock':
> > /usr/src/packages/BUILD/xen-4.2.25432/non-dbg/tools/qemu-xen-dir/qemu-timer-common.c:57:
> > undefined reference to `clock_gettime'
> > qga/guest-agent-commands.o: In function `qmp_guest_file_write':
> > qga/guest-agent-commands.c:249: undefined reference to `g_base64_decode'
> > qga/guest-agent-commands.o: In function `qmp_guest_file_read':
> > qga/guest-agent-commands.c:224: undefined reference to `g_base64_encode'
> > collect2: ld returned 1 exit status
> > make[3]: *** [qemu-ga] Error 1
> > 
> > Add a version check to configure to require at least glib 2.12 to build
> > qemu-upstream.
> 
> Does this cause configure to fail or does it cause us to just not build
> qemu-upstream? I think the former (which is fine with me) but your last
> sentence suggests that latter.

I will resend with this change:

Add a version check to toplevel configure to require at least glib 2.12.
This makes sure configure can detect the condition early instead of
failing later in the middle of tools build when qemu-upstream errors
out.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:57: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 1Sen7l-00069u-Sw; Wed, 13 Jun 2012 12:56: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 1Sen7k-00069k-Tp
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:56:37 +0000
Received: from [85.158.143.35:58066] by server-2.bemta-4.messagelabs.com id
	D7/55-17938-40E88DF4; Wed, 13 Jun 2012 12:56:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339592195!14859434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23062 invoked from network); 13 Jun 2012 12:56:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:56:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:56:35 +0100
Message-ID: <1339592194.24104.202.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:56:34 +0100
In-Reply-To: <1339176870-32652-11-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-11-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/19] libxl: prepare for asynchronous
 writing of qemu save 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 Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> * Combine the various calls to libxl__device_model_savefile into one
>   at the start of libxl__domain_suspend, storing the result in the
>   dss.  Consequently a few functions take a dss instead of some or all
>   of their other arguments.
> 
> * Make libxl__domain_save_device_model's API into an asynchronous
>   style which takes a callback.  The function is, however, still
>   synchronous; it will be made actually async in the next patch.
> 
> * Consequently make libxl__remus_domain_checkpoint_callback into an
>   asynchronous callback.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
>  tools/libxl/libxl_internal.h       |   18 ++++++++++--
>  tools/libxl/libxl_save_msgs_gen.pl |    2 +-
>  3 files changed, 55 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index d5ac79f..3a53f97 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -702,11 +702,13 @@ static void switch_logdirty_done(libxl__egc *egc,
>  
>  /*----- callbacks, called by xc_domain_save -----*/
>  
> -int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +int libxl__domain_suspend_device_model(libxl__gc *gc,
> +                                       libxl__domain_suspend_state *dss)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int ret = 0;
> -    const char *filename = libxl__device_model_savefile(gc, domid);
> +    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: {
> @@ -875,7 +877,7 @@ int libxl__domain_suspend_common_callback(void *user)
>  
>   guest_suspended:
>      if (dss->hvm) {
> -        ret = libxl__domain_suspend_device_model(gc, dss->domid);
> +        ret = libxl__domain_suspend_device_model(gc, dss);
>          if (ret) {
>              LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
>              return 0;
> @@ -990,19 +992,32 @@ static int libxl__remus_domain_resume_callback(void *data)
>      return 1;
>  }
>  
> -static int libxl__remus_domain_checkpoint_callback(void *data)
> +/*----- remus asynchronous checkpoint callback -----*/
> +
> +static void remus_checkpoint_dm_saved(libxl__egc *egc,
> +                                      libxl__domain_suspend_state *dss, int rc);
> +
> +static void libxl__remus_domain_checkpoint_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> +    libxl__egc *egc = dss->shs.egc;
>      STATE_AO_GC(dss->ao);
>  
>      /* This would go into tailbuf. */
> -    if (dss->hvm &&
> -        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
> -        return 0;
> +    if (dss->hvm) {
> +        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
> +    } else {
> +        remus_checkpoint_dm_saved(egc, dss, 0);
> +    }
> +}
>  
> +static void remus_checkpoint_dm_saved(libxl__egc *egc,
> +                                      libxl__domain_suspend_state *dss, int rc)
> +{
>      /* TODO: Wait for disk and memory ack, release network buffer */
> +    /* TODO: make this asynchronous */
>      usleep(dss->interval * 1000);
> -    return 1;
> +    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
>  }
>  
>  /*----- main code for suspending, in order of execution -----*/
> @@ -1052,6 +1067,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>  
>      dss->suspend_eventchn = -1;
>      dss->guest_responded = 0;
> +    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
>  
>      if (r_info != NULL) {
>          dss->interval = r_info->interval;
> @@ -1101,7 +1117,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
>  
>      /* Convenience aliases */
>      const libxl_domain_type type = dss->type;
> -    const uint32_t domid = dss->domid;
>  
>      if (rc)
>          goto out;
> @@ -1119,11 +1134,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
>      }
>  
>      if (type == LIBXL_DOMAIN_TYPE_HVM) {
> -        rc = libxl__domain_suspend_device_model(gc, domid);
> +        rc = libxl__domain_suspend_device_model(gc, dss);
>          if (rc) goto out;
>          
> -        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
> -        if (rc) goto out;
> +        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
> +        return;
>      }
>  
>      rc = 0;
> @@ -1132,14 +1147,22 @@ out:
>      domain_suspend_done(egc, dss, rc);
>  }
>  
> -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
> +void libxl__domain_save_device_model(libxl__egc *egc,
> +                                     libxl__domain_suspend_state *dss,
> +                                     libxl__save_device_model_cb *callback)
>  {
> +    STATE_AO_GC(dss->ao);
>      int rc, fd2 = -1, c;
>      char buf[1024];
> -    const char *filename = libxl__device_model_savefile(gc, domid);
>      struct stat st;
>      uint32_t qemu_state_len;
>  
> +    dss->save_dm_callback = callback;
> +
> +    /* Convenience aliases */
> +    const char *const filename = dss->dm_savefile;
> +    const int fd = dss->fd;
> +
>      if (stat(filename, &st) < 0)
>      {
>          LOG(ERROR, "Unable to stat qemu save file\n");
> @@ -1181,7 +1204,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>  out:
>      if (fd2 >= 0) close(fd2);
>      unlink(filename);
> -    return rc;
> +
> +    dss->save_dm_callback(egc, dss, rc);
>  }
>  
>  static void domain_suspend_done(libxl__egc *egc,
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 7e0ab11..c7fe9e9 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>  
>  _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>                                       uint32_t size, void *data);
> -_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
> -_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
> -_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
> +
>  _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
>  
>  _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
> @@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
>  
>  typedef void libxl__domain_suspend_cb(libxl__egc*,
>                                        libxl__domain_suspend_state*, int rc);
> +typedef void libxl__save_device_model_cb(libxl__egc*,
> +                                         libxl__domain_suspend_state*, int rc);
>  
>  typedef struct libxl__logdirty_switch {
>      const char *cmd;
> @@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
>      int hvm;
>      int xcflags;
>      int guest_responded;
> +    const char *dm_savefile;
>      int interval; /* checkpoint interval (for Remus) */
>      libxl__save_helper_state shs;
>      libxl__logdirty_switch logdirty;
> +    /* private for libxl__domain_save_device_model */
> +    libxl__save_device_model_cb *save_dm_callback;
>  };
>  
> 
> @@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
>  _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
>                                             int rc, int retval, int errnoval);
>  
> +/* Each time the dm needs to be saved, we must call suspend and then save */
> +_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
> +                                           libxl__domain_suspend_state *dss);
> +_hidden void libxl__domain_save_device_model(libxl__egc *egc,
> +                                     libxl__domain_suspend_state *dss,
> +                                     libxl__save_device_model_cb *callback);
> +
> +_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
> +
>  
>  /*
>   * Convenience macros.
> diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> index 8832c46..3ac6f80 100755
> --- a/tools/libxl/libxl_save_msgs_gen.pl
> +++ b/tools/libxl/libxl_save_msgs_gen.pl
> @@ -25,7 +25,7 @@ our @msgs = (
>                                                  'unsigned long', 'total'] ],
>      [  3, 'scxW',   "suspend", [] ],         
>      [  4, 'scxW',   "postcopy", [] ],        
> -    [  5, 'scxW',   "checkpoint", [] ],      
> +    [  5, 'scxA',   "checkpoint", [] ],      
>      [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
>                                                unsigned enable)] ],
>      #                toolstack_save          done entirely `by hand'



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12:57: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 1Sen7l-00069u-Sw; Wed, 13 Jun 2012 12:56: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 1Sen7k-00069k-Tp
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:56:37 +0000
Received: from [85.158.143.35:58066] by server-2.bemta-4.messagelabs.com id
	D7/55-17938-40E88DF4; Wed, 13 Jun 2012 12:56:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339592195!14859434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23062 invoked from network); 13 Jun 2012 12:56:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:56:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:56:35 +0100
Message-ID: <1339592194.24104.202.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:56:34 +0100
In-Reply-To: <1339176870-32652-11-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-11-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/19] libxl: prepare for asynchronous
 writing of qemu save 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 Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> * Combine the various calls to libxl__device_model_savefile into one
>   at the start of libxl__domain_suspend, storing the result in the
>   dss.  Consequently a few functions take a dss instead of some or all
>   of their other arguments.
> 
> * Make libxl__domain_save_device_model's API into an asynchronous
>   style which takes a callback.  The function is, however, still
>   synchronous; it will be made actually async in the next patch.
> 
> * Consequently make libxl__remus_domain_checkpoint_callback into an
>   asynchronous callback.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
>  tools/libxl/libxl_internal.h       |   18 ++++++++++--
>  tools/libxl/libxl_save_msgs_gen.pl |    2 +-
>  3 files changed, 55 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index d5ac79f..3a53f97 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -702,11 +702,13 @@ static void switch_logdirty_done(libxl__egc *egc,
>  
>  /*----- callbacks, called by xc_domain_save -----*/
>  
> -int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +int libxl__domain_suspend_device_model(libxl__gc *gc,
> +                                       libxl__domain_suspend_state *dss)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int ret = 0;
> -    const char *filename = libxl__device_model_savefile(gc, domid);
> +    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: {
> @@ -875,7 +877,7 @@ int libxl__domain_suspend_common_callback(void *user)
>  
>   guest_suspended:
>      if (dss->hvm) {
> -        ret = libxl__domain_suspend_device_model(gc, dss->domid);
> +        ret = libxl__domain_suspend_device_model(gc, dss);
>          if (ret) {
>              LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
>              return 0;
> @@ -990,19 +992,32 @@ static int libxl__remus_domain_resume_callback(void *data)
>      return 1;
>  }
>  
> -static int libxl__remus_domain_checkpoint_callback(void *data)
> +/*----- remus asynchronous checkpoint callback -----*/
> +
> +static void remus_checkpoint_dm_saved(libxl__egc *egc,
> +                                      libxl__domain_suspend_state *dss, int rc);
> +
> +static void libxl__remus_domain_checkpoint_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> +    libxl__egc *egc = dss->shs.egc;
>      STATE_AO_GC(dss->ao);
>  
>      /* This would go into tailbuf. */
> -    if (dss->hvm &&
> -        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
> -        return 0;
> +    if (dss->hvm) {
> +        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
> +    } else {
> +        remus_checkpoint_dm_saved(egc, dss, 0);
> +    }
> +}
>  
> +static void remus_checkpoint_dm_saved(libxl__egc *egc,
> +                                      libxl__domain_suspend_state *dss, int rc)
> +{
>      /* TODO: Wait for disk and memory ack, release network buffer */
> +    /* TODO: make this asynchronous */
>      usleep(dss->interval * 1000);
> -    return 1;
> +    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
>  }
>  
>  /*----- main code for suspending, in order of execution -----*/
> @@ -1052,6 +1067,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>  
>      dss->suspend_eventchn = -1;
>      dss->guest_responded = 0;
> +    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
>  
>      if (r_info != NULL) {
>          dss->interval = r_info->interval;
> @@ -1101,7 +1117,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
>  
>      /* Convenience aliases */
>      const libxl_domain_type type = dss->type;
> -    const uint32_t domid = dss->domid;
>  
>      if (rc)
>          goto out;
> @@ -1119,11 +1134,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
>      }
>  
>      if (type == LIBXL_DOMAIN_TYPE_HVM) {
> -        rc = libxl__domain_suspend_device_model(gc, domid);
> +        rc = libxl__domain_suspend_device_model(gc, dss);
>          if (rc) goto out;
>          
> -        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
> -        if (rc) goto out;
> +        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
> +        return;
>      }
>  
>      rc = 0;
> @@ -1132,14 +1147,22 @@ out:
>      domain_suspend_done(egc, dss, rc);
>  }
>  
> -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
> +void libxl__domain_save_device_model(libxl__egc *egc,
> +                                     libxl__domain_suspend_state *dss,
> +                                     libxl__save_device_model_cb *callback)
>  {
> +    STATE_AO_GC(dss->ao);
>      int rc, fd2 = -1, c;
>      char buf[1024];
> -    const char *filename = libxl__device_model_savefile(gc, domid);
>      struct stat st;
>      uint32_t qemu_state_len;
>  
> +    dss->save_dm_callback = callback;
> +
> +    /* Convenience aliases */
> +    const char *const filename = dss->dm_savefile;
> +    const int fd = dss->fd;
> +
>      if (stat(filename, &st) < 0)
>      {
>          LOG(ERROR, "Unable to stat qemu save file\n");
> @@ -1181,7 +1204,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>  out:
>      if (fd2 >= 0) close(fd2);
>      unlink(filename);
> -    return rc;
> +
> +    dss->save_dm_callback(egc, dss, rc);
>  }
>  
>  static void domain_suspend_done(libxl__egc *egc,
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 7e0ab11..c7fe9e9 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>  
>  _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>                                       uint32_t size, void *data);
> -_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
> -_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
> -_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
> +
>  _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
>  
>  _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
> @@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
>  
>  typedef void libxl__domain_suspend_cb(libxl__egc*,
>                                        libxl__domain_suspend_state*, int rc);
> +typedef void libxl__save_device_model_cb(libxl__egc*,
> +                                         libxl__domain_suspend_state*, int rc);
>  
>  typedef struct libxl__logdirty_switch {
>      const char *cmd;
> @@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
>      int hvm;
>      int xcflags;
>      int guest_responded;
> +    const char *dm_savefile;
>      int interval; /* checkpoint interval (for Remus) */
>      libxl__save_helper_state shs;
>      libxl__logdirty_switch logdirty;
> +    /* private for libxl__domain_save_device_model */
> +    libxl__save_device_model_cb *save_dm_callback;
>  };
>  
> 
> @@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
>  _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
>                                             int rc, int retval, int errnoval);
>  
> +/* Each time the dm needs to be saved, we must call suspend and then save */
> +_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
> +                                           libxl__domain_suspend_state *dss);
> +_hidden void libxl__domain_save_device_model(libxl__egc *egc,
> +                                     libxl__domain_suspend_state *dss,
> +                                     libxl__save_device_model_cb *callback);
> +
> +_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
> +
>  
>  /*
>   * Convenience macros.
> diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> index 8832c46..3ac6f80 100755
> --- a/tools/libxl/libxl_save_msgs_gen.pl
> +++ b/tools/libxl/libxl_save_msgs_gen.pl
> @@ -25,7 +25,7 @@ our @msgs = (
>                                                  'unsigned long', 'total'] ],
>      [  3, 'scxW',   "suspend", [] ],         
>      [  4, 'scxW',   "postcopy", [] ],        
> -    [  5, 'scxW',   "checkpoint", [] ],      
> +    [  5, 'scxA',   "checkpoint", [] ],      
>      [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
>                                                unsigned enable)] ],
>      #                toolstack_save          done entirely `by hand'



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:59:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1SenAK-0006Mn-Fa; Wed, 13 Jun 2012 12:59:16 +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 1SenAI-0006Me-R6
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:59:14 +0000
Received: from [193.109.254.147:48502] by server-10.bemta-14.messagelabs.com
	id 53/DB-25709-2AE88DF4; Wed, 13 Jun 2012 12:59:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339592353!9502045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31020 invoked from network); 13 Jun 2012 12:59:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:59:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:59:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:59:13 +0100
Message-ID: <1339592351.24104.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:59:11 +0100
In-Reply-To: <1339176870-32652-12-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-12-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/19] libxl: Make
 libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 12:59:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 12: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 1SenAK-0006Mn-Fa; Wed, 13 Jun 2012 12:59:16 +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 1SenAI-0006Me-R6
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:59:14 +0000
Received: from [193.109.254.147:48502] by server-10.bemta-14.messagelabs.com
	id 53/DB-25709-2AE88DF4; Wed, 13 Jun 2012 12:59:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339592353!9502045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31020 invoked from network); 13 Jun 2012 12:59:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:59:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:59:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:59:13 +0100
Message-ID: <1339592351.24104.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:59:11 +0100
In-Reply-To: <1339176870-32652-12-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-12-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/19] libxl: Make
 libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:00:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:00: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 1SenB0-0006QL-Sz; Wed, 13 Jun 2012 12:59:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SenAz-0006Q2-Pc
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:59:58 +0000
Received: from [193.109.254.147:50557] by server-7.bemta-14.messagelabs.com id
	09/2A-29165-DCE88DF4; Wed, 13 Jun 2012 12:59:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339592396!1847989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10034 invoked from network); 13 Jun 2012 12:59:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:59:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:59:56 +0100
Message-ID: <1339592394.24104.204.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:59:54 +0100
In-Reply-To: <1339176870-32652-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 12/19] libxl: Add a gc to
 libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> In the next patch we are going to change the definition of NOGC to
> require a local variable libxl__gc *gc.
> 
> libxl_get_cpu_topology doesn't have one but does use NOGC.
> Fix this by:
>  - introducing an `out' label
>  - replacing the only call to `return' with a suitable assignment
>    to ret and a `goto out'.
>  - adding uses of GC_INIT and GC_FREE.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7de026b..2a31528 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3202,6 +3202,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
>  
>  libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
>  {
> +    GC_INIT(ctx);
>      xc_topologyinfo_t tinfo;
>      DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
>      DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
> @@ -3214,7 +3215,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
>      if (max_cpus == 0)
>      {
>          LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
> -        return NULL;
> +        ret = NULL;
> +        goto out;
>      }
>  
>      coremap = xc_hypercall_buffer_alloc
> @@ -3259,6 +3261,8 @@ fail:
>  
>      if (ret)
>          *nr = max_cpus;
> + out:
> +    GC_FREE;
>      return ret;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:00:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:00: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 1SenB0-0006QL-Sz; Wed, 13 Jun 2012 12:59:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SenAz-0006Q2-Pc
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 12:59:58 +0000
Received: from [193.109.254.147:50557] by server-7.bemta-14.messagelabs.com id
	09/2A-29165-DCE88DF4; Wed, 13 Jun 2012 12:59:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339592396!1847989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10034 invoked from network); 13 Jun 2012 12:59:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 12:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12995808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:59:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 13:59:56 +0100
Message-ID: <1339592394.24104.204.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 13:59:54 +0100
In-Reply-To: <1339176870-32652-13-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-13-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 12/19] libxl: Add a gc to
 libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> In the next patch we are going to change the definition of NOGC to
> require a local variable libxl__gc *gc.
> 
> libxl_get_cpu_topology doesn't have one but does use NOGC.
> Fix this by:
>  - introducing an `out' label
>  - replacing the only call to `return' with a suitable assignment
>    to ret and a `goto out'.
>  - adding uses of GC_INIT and GC_FREE.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7de026b..2a31528 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3202,6 +3202,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
>  
>  libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
>  {
> +    GC_INIT(ctx);
>      xc_topologyinfo_t tinfo;
>      DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
>      DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
> @@ -3214,7 +3215,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
>      if (max_cpus == 0)
>      {
>          LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
> -        return NULL;
> +        ret = NULL;
> +        goto out;
>      }
>  
>      coremap = xc_hypercall_buffer_alloc
> @@ -3259,6 +3261,8 @@ fail:
>  
>      if (ret)
>          *nr = max_cpus;
> + out:
> +    GC_FREE;
>      return ret;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:09:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenJH-0006nr-Rb; Wed, 13 Jun 2012 13:08: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 1SenJF-0006nm-KQ
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:08:29 +0000
Received: from [85.158.138.51:61560] by server-10.bemta-3.messagelabs.com id
	F7/1E-06494-CC098DF4; Wed, 13 Jun 2012 13:08:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339592907!27434919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10964 invoked from network); 13 Jun 2012 13:08:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:08:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:08:27 +0100
Message-ID: <1339592906.24104.208.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:08:26 +0100
In-Reply-To: <1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
 gc_opt==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 Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Since it used to be legal to pass gc_opt==NULL, and there are various
> patches floating about and under developmetn which do so, add a

                                   development

> compiler annotation which makes the build fail when that is done.
> 
> This turns a runtime crash into a build failure, and should ensure
> that we don't accidentally commit a broken combination of patches.
> 
> This is something of an annoying approach because it adds a macro
> invocation to the RHS of every declaration of a function taking a
> gc_opt.  So it should be reverted after Xen 4.2rc1.

This patch will itself break the build until a subsequent patch, won't
it? Shuffle it afterwards?

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Wherever it ends up in the sequence:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   21 +++++++++++++--------
>  1 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index e69482c..8635764 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>   * psuedo-gc.
>   */
>  /* register ptr in gc for free on exit from outermost libxl callframe. */
> -_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
> +
> +#define NN1 __attribute__((nonnull(1)))
> + /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
> +  * warn about this if any slip through. */
> +
> +_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
>  /* if this is the outermost libxl callframe then free all pointers in @gc */
>  _hidden void libxl__free_all(libxl__gc *gc);
>  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
> -_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
> +_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
>  /* allocate and zero memory for an array of @nmemb members of @size each.
>   * (similar to a gc'd calloc(3)). */
> -_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
> +_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
>  /* change the size of the memory block pointed to by @ptr to @new_size bytes.
>   * unlike other allocation functions here any additional space between the
>   * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
> -_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
> +_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
>  /* print @fmt into an allocated string large enoughto contain the result.
>   * (similar to gc'd asprintf(3)). */
> -_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
> +_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
>  /* duplicate the string @c (similar to a gc'd strdup(3)). */
> -_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
> +_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
>  /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
> -_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
> +_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
>  /* strip the last path component from @s and return as a newly allocated
>   * string. (similar to a gc'd dirname(3)). */
> -_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
> +_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
>  
>  /* Each of these logs errors and returns a libxl error code.
>   * They do not mind if path is already removed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:09:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenJH-0006nr-Rb; Wed, 13 Jun 2012 13:08: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 1SenJF-0006nm-KQ
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:08:29 +0000
Received: from [85.158.138.51:61560] by server-10.bemta-3.messagelabs.com id
	F7/1E-06494-CC098DF4; Wed, 13 Jun 2012 13:08:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339592907!27434919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10964 invoked from network); 13 Jun 2012 13:08:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:08:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:08:27 +0100
Message-ID: <1339592906.24104.208.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:08:26 +0100
In-Reply-To: <1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
 gc_opt==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 Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> Since it used to be legal to pass gc_opt==NULL, and there are various
> patches floating about and under developmetn which do so, add a

                                   development

> compiler annotation which makes the build fail when that is done.
> 
> This turns a runtime crash into a build failure, and should ensure
> that we don't accidentally commit a broken combination of patches.
> 
> This is something of an annoying approach because it adds a macro
> invocation to the RHS of every declaration of a function taking a
> gc_opt.  So it should be reverted after Xen 4.2rc1.

This patch will itself break the build until a subsequent patch, won't
it? Shuffle it afterwards?

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Wherever it ends up in the sequence:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   21 +++++++++++++--------
>  1 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index e69482c..8635764 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>   * psuedo-gc.
>   */
>  /* register ptr in gc for free on exit from outermost libxl callframe. */
> -_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
> +
> +#define NN1 __attribute__((nonnull(1)))
> + /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
> +  * warn about this if any slip through. */
> +
> +_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
>  /* if this is the outermost libxl callframe then free all pointers in @gc */
>  _hidden void libxl__free_all(libxl__gc *gc);
>  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
> -_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
> +_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
>  /* allocate and zero memory for an array of @nmemb members of @size each.
>   * (similar to a gc'd calloc(3)). */
> -_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
> +_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
>  /* change the size of the memory block pointed to by @ptr to @new_size bytes.
>   * unlike other allocation functions here any additional space between the
>   * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
> -_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
> +_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
>  /* print @fmt into an allocated string large enoughto contain the result.
>   * (similar to gc'd asprintf(3)). */
> -_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
> +_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
>  /* duplicate the string @c (similar to a gc'd strdup(3)). */
> -_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
> +_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
>  /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
> -_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
> +_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
>  /* strip the last path component from @s and return as a newly allocated
>   * string. (similar to a gc'd dirname(3)). */
> -_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
> +_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
>  
>  /* Each of these logs errors and returns a libxl error code.
>   * They do not mind if path is already removed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenJu-0006qR-DJ; Wed, 13 Jun 2012 13:09: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 1SenJt-0006qE-87
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:09:09 +0000
Received: from [85.158.138.51:16333] by server-9.bemta-3.messagelabs.com id
	32/88-15054-4F098DF4; Wed, 13 Jun 2012 13:09:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339592947!27402536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11509 invoked from network); 13 Jun 2012 13:09:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:09:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:09:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:09:07 +0100
Message-ID: <1339592945.24104.209.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:09:05 +0100
In-Reply-To: <1339592906.24104.208.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
	<1339592906.24104.208.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
 gc_opt==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 Wed, 2012-06-13 at 14:08 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Since it used to be legal to pass gc_opt==NULL, and there are various
> > patches floating about and under developmetn which do so, add a
> 
>                                    development
> 
> > compiler annotation which makes the build fail when that is done.
> > 
> > This turns a runtime crash into a build failure, and should ensure
> > that we don't accidentally commit a broken combination of patches.
> > 
> > This is something of an annoying approach because it adds a macro
> > invocation to the RHS of every declaration of a function taking a
> > gc_opt.  So it should be reverted after Xen 4.2rc1.
> 
> This patch will itself break the build until a subsequent patch, won't
> it? Shuffle it afterwards?

Nevermind, I accidentally skipped #13...

> 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Wherever it ends up in the sequence:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > ---
> >  tools/libxl/libxl_internal.h |   21 +++++++++++++--------
> >  1 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index e69482c..8635764 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
> >   * psuedo-gc.
> >   */
> >  /* register ptr in gc for free on exit from outermost libxl callframe. */
> > -_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
> > +
> > +#define NN1 __attribute__((nonnull(1)))
> > + /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
> > +  * warn about this if any slip through. */
> > +
> > +_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
> >  /* if this is the outermost libxl callframe then free all pointers in @gc */
> >  _hidden void libxl__free_all(libxl__gc *gc);
> >  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
> > -_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
> > +_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
> >  /* allocate and zero memory for an array of @nmemb members of @size each.
> >   * (similar to a gc'd calloc(3)). */
> > -_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
> > +_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
> >  /* change the size of the memory block pointed to by @ptr to @new_size bytes.
> >   * unlike other allocation functions here any additional space between the
> >   * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
> > -_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
> > +_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
> >  /* print @fmt into an allocated string large enoughto contain the result.
> >   * (similar to gc'd asprintf(3)). */
> > -_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
> > +_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
> >  /* duplicate the string @c (similar to a gc'd strdup(3)). */
> > -_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
> > +_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
> >  /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
> > -_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
> > +_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
> >  /* strip the last path component from @s and return as a newly allocated
> >   * string. (similar to a gc'd dirname(3)). */
> > -_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
> > +_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
> >  
> >  /* Each of these logs errors and returns a libxl error code.
> >   * They do not mind if path is already removed.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:09:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenJu-0006qR-DJ; Wed, 13 Jun 2012 13:09: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 1SenJt-0006qE-87
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:09:09 +0000
Received: from [85.158.138.51:16333] by server-9.bemta-3.messagelabs.com id
	32/88-15054-4F098DF4; Wed, 13 Jun 2012 13:09:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339592947!27402536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11509 invoked from network); 13 Jun 2012 13:09:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:09:07 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:09:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:09:07 +0100
Message-ID: <1339592945.24104.209.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:09:05 +0100
In-Reply-To: <1339592906.24104.208.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
	<1339592906.24104.208.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
 gc_opt==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 Wed, 2012-06-13 at 14:08 +0100, Ian Campbell wrote:
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Since it used to be legal to pass gc_opt==NULL, and there are various
> > patches floating about and under developmetn which do so, add a
> 
>                                    development
> 
> > compiler annotation which makes the build fail when that is done.
> > 
> > This turns a runtime crash into a build failure, and should ensure
> > that we don't accidentally commit a broken combination of patches.
> > 
> > This is something of an annoying approach because it adds a macro
> > invocation to the RHS of every declaration of a function taking a
> > gc_opt.  So it should be reverted after Xen 4.2rc1.
> 
> This patch will itself break the build until a subsequent patch, won't
> it? Shuffle it afterwards?

Nevermind, I accidentally skipped #13...

> 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Wherever it ends up in the sequence:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > ---
> >  tools/libxl/libxl_internal.h |   21 +++++++++++++--------
> >  1 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index e69482c..8635764 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
> >   * psuedo-gc.
> >   */
> >  /* register ptr in gc for free on exit from outermost libxl callframe. */
> > -_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
> > +
> > +#define NN1 __attribute__((nonnull(1)))
> > + /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
> > +  * warn about this if any slip through. */
> > +
> > +_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
> >  /* if this is the outermost libxl callframe then free all pointers in @gc */
> >  _hidden void libxl__free_all(libxl__gc *gc);
> >  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
> > -_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
> > +_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
> >  /* allocate and zero memory for an array of @nmemb members of @size each.
> >   * (similar to a gc'd calloc(3)). */
> > -_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
> > +_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
> >  /* change the size of the memory block pointed to by @ptr to @new_size bytes.
> >   * unlike other allocation functions here any additional space between the
> >   * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
> > -_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
> > +_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
> >  /* print @fmt into an allocated string large enoughto contain the result.
> >   * (similar to gc'd asprintf(3)). */
> > -_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
> > +_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
> >  /* duplicate the string @c (similar to a gc'd strdup(3)). */
> > -_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
> > +_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
> >  /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
> > -_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
> > +_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
> >  /* strip the last path component from @s and return as a newly allocated
> >   * string. (similar to a gc'd dirname(3)). */
> > -_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
> > +_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
> >  
> >  /* Each of these logs errors and returns a libxl error code.
> >   * They do not mind if path is already removed.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenM0-00071e-AV; Wed, 13 Jun 2012 13:11:20 +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 1SenLy-000717-3m
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:18 +0000
Received: from [85.158.143.99:27257] by server-2.bemta-4.messagelabs.com id
	40/02-17938-57198DF4; Wed, 13 Jun 2012 13:11:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339593074!29274308!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24935 invoked from network); 13 Jun 2012 13:11:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 13:11:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jored mo87) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U0706ao5DD3dpR ;
	Wed, 13 Jun 2012 15:11:13 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0CA5218639;
	Wed, 13 Jun 2012 15:11:11 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 59762b446ab4e6d9a851a91d1457c11f6c828d49
Message-Id: <59762b446ab4e6d9a851.1339593049@probook.site>
In-Reply-To: <patchbomb.1339593047@probook.site>
References: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:49 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] tools/m4: add AC_LANG_SOURCE to fix
	autoconf warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339593008 -7200
# Node ID 59762b446ab4e6d9a851a91d1457c11f6c828d49
# Parent  0dfe08c91739527eb454d5e4957635cb8b90e1e1
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings

I see these warnings with autoconf 2.68, add AC_LANG_SOURCE as suggested
by upstream documentation.

...
 # bash autogen.sh
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level


Please rerun autoconf after applying this.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/pthread.m4
--- a/tools/m4/pthread.m4
+++ b/tools/m4/pthread.m4
@@ -24,13 +24,13 @@ AC_DEFUN([AX_CHECK_PTHREAD],[
         AX_PTHREAD_CV2VARS
         AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
         AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
-        AC_LINK_IFELSE([
+        AC_LINK_IFELSE([AC_LANG_SOURCE([
 #include <pthread.h>
 int main(void) {
   pthread_atfork(0,0,0);
   pthread_create(0,0,0,0);
 }
-],[],[ax_cv_pthread_flags=failed])
+])],[],[ax_cv_pthread_flags=failed])
         AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
     ])
     if test "x$ax_cv_pthread_flags" = xfailed; then
diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/ptyfuncs.m4
--- a/tools/m4/ptyfuncs.m4
+++ b/tools/m4/ptyfuncs.m4
@@ -9,7 +9,7 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [
             fi
             AX_SAVEVAR_SAVE(LIBS)
             LIBS="$LIBS $ax_cv_ptyfuncs_libs"
-            AC_LINK_IFELSE([
+            AC_LINK_IFELSE([AC_LANG_SOURCE([
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
 #endif
@@ -17,7 +17,7 @@ int main(void) {
   openpty(0,0,0,0,0);
   login_tty(0);
 }
-],[
+])],[
                 break
             ],[])
             AX_SAVEVAR_RESTORE(LIBS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenM0-00071e-AV; Wed, 13 Jun 2012 13:11:20 +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 1SenLy-000717-3m
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:18 +0000
Received: from [85.158.143.99:27257] by server-2.bemta-4.messagelabs.com id
	40/02-17938-57198DF4; Wed, 13 Jun 2012 13:11:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339593074!29274308!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,UPPERCASE_25_50
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24935 invoked from network); 13 Jun 2012 13:11:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 13:11:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jored mo87) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U0706ao5DD3dpR ;
	Wed, 13 Jun 2012 15:11:13 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0CA5218639;
	Wed, 13 Jun 2012 15:11:11 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 59762b446ab4e6d9a851a91d1457c11f6c828d49
Message-Id: <59762b446ab4e6d9a851.1339593049@probook.site>
In-Reply-To: <patchbomb.1339593047@probook.site>
References: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:49 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] tools/m4: add AC_LANG_SOURCE to fix
	autoconf warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339593008 -7200
# Node ID 59762b446ab4e6d9a851a91d1457c11f6c828d49
# Parent  0dfe08c91739527eb454d5e4957635cb8b90e1e1
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings

I see these warnings with autoconf 2.68, add AC_LANG_SOURCE as suggested
by upstream documentation.

...
 # bash autogen.sh
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level
configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
configure.ac:141: the top level
configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
configure.ac:142: the top level


Please rerun autoconf after applying this.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/pthread.m4
--- a/tools/m4/pthread.m4
+++ b/tools/m4/pthread.m4
@@ -24,13 +24,13 @@ AC_DEFUN([AX_CHECK_PTHREAD],[
         AX_PTHREAD_CV2VARS
         AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
         AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
-        AC_LINK_IFELSE([
+        AC_LINK_IFELSE([AC_LANG_SOURCE([
 #include <pthread.h>
 int main(void) {
   pthread_atfork(0,0,0);
   pthread_create(0,0,0,0);
 }
-],[],[ax_cv_pthread_flags=failed])
+])],[],[ax_cv_pthread_flags=failed])
         AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
     ])
     if test "x$ax_cv_pthread_flags" = xfailed; then
diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/ptyfuncs.m4
--- a/tools/m4/ptyfuncs.m4
+++ b/tools/m4/ptyfuncs.m4
@@ -9,7 +9,7 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [
             fi
             AX_SAVEVAR_SAVE(LIBS)
             LIBS="$LIBS $ax_cv_ptyfuncs_libs"
-            AC_LINK_IFELSE([
+            AC_LINK_IFELSE([AC_LANG_SOURCE([
 #ifdef INCLUDE_LIBUTIL_H
 #include INCLUDE_LIBUTIL_H
 #endif
@@ -17,7 +17,7 @@ int main(void) {
   openpty(0,0,0,0,0);
   login_tty(0);
 }
-],[
+])],[
                 break
             ],[])
             AX_SAVEVAR_RESTORE(LIBS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenM0-00071n-Mi; Wed, 13 Jun 2012 13:11:20 +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 1SenLy-00071E-Kf
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:18 +0000
Received: from [193.109.254.147:38842] by server-3.bemta-14.messagelabs.com id
	A5/34-05653-57198DF4; Wed, 13 Jun 2012 13:11:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339593074!9504843!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 13 Jun 2012 13:11:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 13:11:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo43) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Q07a8fo5DCoRje ;
	Wed, 13 Jun 2012 15:11:12 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E8A3D18638;
	Wed, 13 Jun 2012 15:11:10 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 0dfe08c91739527eb454d5e4957635cb8b90e1e1
Message-Id: <0dfe08c91739527eb454.1339593048@probook.site>
In-Reply-To: <patchbomb.1339593047@probook.site>
References: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:48 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version check
	for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIE9sYWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT4K
IyBEYXRlIDEzMzk1OTMwMDAgLTcyMDAKIyBOb2RlIElEIDBkZmUwOGM5MTczOTUyN2ViNDU0ZDVl
NDk1NzYzNWNiOGI5MGUxZTEKIyBQYXJlbnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIx
YmIyYzcwNDk4ODUKdG9vbHMvY29uZmlndXJlLmFjOiBhZGQgdmVyc2lvbiBjaGVjayBmb3IgZ2xp
YjIKCnhlbi11bnN0YWJsZSBmYWlscyB0byBidWlsZCBpbiBhIFNMRVMxMFNQNCBlbnZpcm9ubWVu
dCBzaW5jZSBhIGxvbmcgdGltZQpiZWNhdXNlIHRoZSBpbmNsdWRlZCB2ZXJzaW9uIG9mIGdsaWIg
aXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0aGUgcmVxdWlyZWQKZ2xpYiB2ZXJzaW9uLiBBY2NvcmRp
bmcgdG8gdGhlIGdsaWIgZG9jcyB2ZXJzaW9uIDIuMTIgaW5jbHVkZXMgYmFzZTY0CnN1cHBvcnQs
IGJ1dCBTTEVTMTAgaXMgc2hpcHBlZCB3aXRoIGdsaWIgMi44LjY6CgpxZW11LXRpbWVyLWNvbW1v
bi5vOiBJbiBmdW5jdGlvbiBgaW5pdF9nZXRfY2xvY2snOgovdXNyL3NyYy9wYWNrYWdlcy9CVUlM
RC94ZW4tNC4yLjI1NDMyL25vbi1kYmcvdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXItY29t
bW9uLmM6NTc6CnVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNsb2NrX2dldHRpbWUnCnFnYS9ndWVz
dC1hZ2VudC1jb21tYW5kcy5vOiBJbiBmdW5jdGlvbiBgcW1wX2d1ZXN0X2ZpbGVfd3JpdGUnOgpx
Z2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyNDk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdf
YmFzZTY0X2RlY29kZScKcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0aW9uIGBx
bXBfZ3Vlc3RfZmlsZV9yZWFkJzoKcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6MjI0OiB1bmRl
ZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9lbmNvZGUnCmNvbGxlY3QyOiBsZCByZXR1cm5l
ZCAxIGV4aXQgc3RhdHVzCm1ha2VbM106ICoqKiBbcWVtdS1nYV0gRXJyb3IgMQoKQWRkIGEgdmVy
c2lvbiBjaGVjayB0byB0b3BsZXZlbCBjb25maWd1cmUgdG8gcmVxdWlyZSBhdCBsZWFzdCBnbGli
IDIuMTIuClRoaXMgbWFrZXMgc3VyZSBjb25maWd1cmUgY2FuIGRldGVjdCB0aGUgY29uZGl0aW9u
IGVhcmx5IGluc3RlYWQgb2YKZmFpbGluZyBsYXRlciBpbiB0aGUgbWlkZGxlIG9mIHRvb2xzIGJ1
aWxkIHdoZW4gcWVtdS11cHN0cmVhbSBlcnJvcnMKb3V0LgoKUGxlYXNlIHJlcnVuIGF1dG9jb25m
IGFmdGVyIGFwcGx5aW5nIHRoaXMuCgpTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBh
ZXBmbGUuZGU+CkFja2VkLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNv
bT4KCmRpZmYgLXIgYTcwYjM1ZGViMmI1IC1yIDBkZmUwOGM5MTczOSB0b29scy9jb25maWd1cmUu
YWMKLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwpAQCAt
MTE1LDcgKzExNSw3IEBAIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtCQ0NdLCBbYmNjXSkKIEFYX1BB
VEhfUFJPR19PUl9GQUlMKFtJQVNMXSwgW2lhc2xdKQogQVhfQ0hFQ0tfVVVJRAogQVhfQ0hFQ0tf
Q1VSU0VTCi1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKK1BLR19DSEVDS19NT0RV
TEVTKGdsaWIsIFtnbGliLTIuMCA+PSAyLjEyXSkKIAogIyBDaGVjayBsaWJyYXJ5IHBhdGgKIEFY
X0RFRkFVTFRfTElCCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenM0-00071n-Mi; Wed, 13 Jun 2012 13:11:20 +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 1SenLy-00071E-Kf
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:18 +0000
Received: from [193.109.254.147:38842] by server-3.bemta-14.messagelabs.com id
	A5/34-05653-57198DF4; Wed, 13 Jun 2012 13:11:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339593074!9504843!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 13 Jun 2012 13:11:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 13:11:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo43) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Q07a8fo5DCoRje ;
	Wed, 13 Jun 2012 15:11:12 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E8A3D18638;
	Wed, 13 Jun 2012 15:11:10 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 0dfe08c91739527eb454d5e4957635cb8b90e1e1
Message-Id: <0dfe08c91739527eb454.1339593048@probook.site>
In-Reply-To: <patchbomb.1339593047@probook.site>
References: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:48 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version check
	for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIE9sYWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT4K
IyBEYXRlIDEzMzk1OTMwMDAgLTcyMDAKIyBOb2RlIElEIDBkZmUwOGM5MTczOTUyN2ViNDU0ZDVl
NDk1NzYzNWNiOGI5MGUxZTEKIyBQYXJlbnQgIGE3MGIzNWRlYjJiNTU5MmNjMWIyMzYzODYwZjIx
YmIyYzcwNDk4ODUKdG9vbHMvY29uZmlndXJlLmFjOiBhZGQgdmVyc2lvbiBjaGVjayBmb3IgZ2xp
YjIKCnhlbi11bnN0YWJsZSBmYWlscyB0byBidWlsZCBpbiBhIFNMRVMxMFNQNCBlbnZpcm9ubWVu
dCBzaW5jZSBhIGxvbmcgdGltZQpiZWNhdXNlIHRoZSBpbmNsdWRlZCB2ZXJzaW9uIG9mIGdsaWIg
aXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0aGUgcmVxdWlyZWQKZ2xpYiB2ZXJzaW9uLiBBY2NvcmRp
bmcgdG8gdGhlIGdsaWIgZG9jcyB2ZXJzaW9uIDIuMTIgaW5jbHVkZXMgYmFzZTY0CnN1cHBvcnQs
IGJ1dCBTTEVTMTAgaXMgc2hpcHBlZCB3aXRoIGdsaWIgMi44LjY6CgpxZW11LXRpbWVyLWNvbW1v
bi5vOiBJbiBmdW5jdGlvbiBgaW5pdF9nZXRfY2xvY2snOgovdXNyL3NyYy9wYWNrYWdlcy9CVUlM
RC94ZW4tNC4yLjI1NDMyL25vbi1kYmcvdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXItY29t
bW9uLmM6NTc6CnVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNsb2NrX2dldHRpbWUnCnFnYS9ndWVz
dC1hZ2VudC1jb21tYW5kcy5vOiBJbiBmdW5jdGlvbiBgcW1wX2d1ZXN0X2ZpbGVfd3JpdGUnOgpx
Z2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyNDk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdf
YmFzZTY0X2RlY29kZScKcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0aW9uIGBx
bXBfZ3Vlc3RfZmlsZV9yZWFkJzoKcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6MjI0OiB1bmRl
ZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9lbmNvZGUnCmNvbGxlY3QyOiBsZCByZXR1cm5l
ZCAxIGV4aXQgc3RhdHVzCm1ha2VbM106ICoqKiBbcWVtdS1nYV0gRXJyb3IgMQoKQWRkIGEgdmVy
c2lvbiBjaGVjayB0byB0b3BsZXZlbCBjb25maWd1cmUgdG8gcmVxdWlyZSBhdCBsZWFzdCBnbGli
IDIuMTIuClRoaXMgbWFrZXMgc3VyZSBjb25maWd1cmUgY2FuIGRldGVjdCB0aGUgY29uZGl0aW9u
IGVhcmx5IGluc3RlYWQgb2YKZmFpbGluZyBsYXRlciBpbiB0aGUgbWlkZGxlIG9mIHRvb2xzIGJ1
aWxkIHdoZW4gcWVtdS11cHN0cmVhbSBlcnJvcnMKb3V0LgoKUGxlYXNlIHJlcnVuIGF1dG9jb25m
IGFmdGVyIGFwcGx5aW5nIHRoaXMuCgpTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBh
ZXBmbGUuZGU+CkFja2VkLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNv
bT4KCmRpZmYgLXIgYTcwYjM1ZGViMmI1IC1yIDBkZmUwOGM5MTczOSB0b29scy9jb25maWd1cmUu
YWMKLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwpAQCAt
MTE1LDcgKzExNSw3IEBAIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtCQ0NdLCBbYmNjXSkKIEFYX1BB
VEhfUFJPR19PUl9GQUlMKFtJQVNMXSwgW2lhc2xdKQogQVhfQ0hFQ0tfVVVJRAogQVhfQ0hFQ0tf
Q1VSU0VTCi1QS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKK1BLR19DSEVDS19NT0RV
TEVTKGdsaWIsIFtnbGliLTIuMCA+PSAyLjEyXSkKIAogIyBDaGVjayBsaWJyYXJ5IHBhdGgKIEFY
X0RFRkFVTFRfTElCCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13: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 1SenM2-00072G-3v; Wed, 13 Jun 2012 13:11:22 +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 1SenM0-00071c-O6
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:20 +0000
Received: from [85.158.139.83:36330] by server-5.bemta-5.messagelabs.com id
	5B/E8-02722-77198DF4; Wed, 13 Jun 2012 13:11:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339593074!26937879!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31125 invoked from network); 13 Jun 2012 13:11:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 13:11:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo39) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q079fbo5DCKxMn ;
	Wed, 13 Jun 2012 15:11:13 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C33C218637;
	Wed, 13 Jun 2012 15:11:10 +0200 (CEST)
MIME-Version: 1.0
Message-Id: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:47 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] [v2] tools/configure.ac 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


Changes:
tools/configure.ac: add version check for glib2
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

 tools/configure.ac   |    4 ++--
 tools/m4/pthread.m4  |    4 ++--
 tools/m4/ptyfuncs.m4 |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13: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 1SenM2-00072G-3v; Wed, 13 Jun 2012 13:11:22 +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 1SenM0-00071c-O6
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:20 +0000
Received: from [85.158.139.83:36330] by server-5.bemta-5.messagelabs.com id
	5B/E8-02722-77198DF4; Wed, 13 Jun 2012 13:11:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339593074!26937879!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31125 invoked from network); 13 Jun 2012 13:11:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 13:11:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo39) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q079fbo5DCKxMn ;
	Wed, 13 Jun 2012 15:11:13 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C33C218637;
	Wed, 13 Jun 2012 15:11:10 +0200 (CEST)
MIME-Version: 1.0
Message-Id: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:47 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] [v2] tools/configure.ac 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


Changes:
tools/configure.ac: add version check for glib2
tools/m4: add AC_LANG_SOURCE to fix autoconf warnings
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

 tools/configure.ac   |    4 ++--
 tools/m4/pthread.m4  |    4 ++--
 tools/m4/ptyfuncs.m4 |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenLx-000719-UF; Wed, 13 Jun 2012 13:11:17 +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 1SenLw-00070w-EC
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:16 +0000
Received: from [85.158.143.35:14896] by server-1.bemta-4.messagelabs.com id
	8B/57-24392-37198DF4; Wed, 13 Jun 2012 13:11:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339593074!12924372!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21554 invoked from network); 13 Jun 2012 13:11:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 13:11:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jored mo3) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g054c1o5DAdfFI ;
	Wed, 13 Jun 2012 15:11:14 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 1FFAF1863A;
	Wed, 13 Jun 2012 15:11:11 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 752a11d976972b3dca886e16f7e07572cf7b3129
Message-Id: <752a11d976972b3dca88.1339593050@probook.site>
In-Reply-To: <patchbomb.1339593047@probook.site>
References: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:50 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill PACKAGE_TARNAME
	in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1339593017 -7200
# Node ID 752a11d976972b3dca886e16f7e07572cf7b3129
# Parent  59762b446ab4e6d9a851a91d1457c11f6c828d49
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
preserve the currently used path, which ends with /xen, specify a value
for PACKAGE_TARNAME. Without this change the path would end with
/xen-hypervisor.

Also adjust mail adress to xen-devel@lists.xen.org.

Please rerun autoconf after applying this.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 59762b446ab4 -r 752a11d97697 tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -3,7 +3,7 @@
 
 AC_PREREQ([2.67])
 AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
-    [xen-devel@lists.xensource.com])
+    [xen-devel@lists.xen.org], [xen], [http://www.xen.org/])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
 AC_CONFIG_FILES([../config/Tools.mk])
 AC_CONFIG_HEADERS([config.h])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:11:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenLx-000719-UF; Wed, 13 Jun 2012 13:11:17 +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 1SenLw-00070w-EC
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:11:16 +0000
Received: from [85.158.143.35:14896] by server-1.bemta-4.messagelabs.com id
	8B/57-24392-37198DF4; Wed, 13 Jun 2012 13:11:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339593074!12924372!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzY0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21554 invoked from network); 13 Jun 2012 13:11:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 13:11:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jored mo3) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g054c1o5DAdfFI ;
	Wed, 13 Jun 2012 15:11:14 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 1FFAF1863A;
	Wed, 13 Jun 2012 15:11:11 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 752a11d976972b3dca886e16f7e07572cf7b3129
Message-Id: <752a11d976972b3dca88.1339593050@probook.site>
In-Reply-To: <patchbomb.1339593047@probook.site>
References: <patchbomb.1339593047@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 15:10:50 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill PACKAGE_TARNAME
	in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1339593017 -7200
# Node ID 752a11d976972b3dca886e16f7e07572cf7b3129
# Parent  59762b446ab4e6d9a851a91d1457c11f6c828d49
tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT

Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
preserve the currently used path, which ends with /xen, specify a value
for PACKAGE_TARNAME. Without this change the path would end with
/xen-hypervisor.

Also adjust mail adress to xen-devel@lists.xen.org.

Please rerun autoconf after applying this.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 59762b446ab4 -r 752a11d97697 tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -3,7 +3,7 @@
 
 AC_PREREQ([2.67])
 AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
-    [xen-devel@lists.xensource.com])
+    [xen-devel@lists.xen.org], [xen], [http://www.xen.org/])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
 AC_CONFIG_FILES([../config/Tools.mk])
 AC_CONFIG_HEADERS([config.h])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13: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 1SenMI-000766-Jo; Wed, 13 Jun 2012 13:11: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 1SenMG-00075E-H2
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:11:36 +0000
Received: from [85.158.139.83:40380] by server-5.bemta-5.messagelabs.com id
	F0/89-02722-68198DF4; Wed, 13 Jun 2012 13:11:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339593093!20252513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1917 invoked from network); 13 Jun 2012 13:11:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:11:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:11:33 +0100
Message-ID: <1339593091.24104.210.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:11:31 +0100
In-Reply-To: <1339176870-32652-14-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-14-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Bamvor Jian Zhang <bjzhang@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 13/19] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> In 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
> allocation functions was introduced.  However, the arrangements there
> were not correct as committed, because the error handling and logging
> depends on getting a ctx from the gc - so an allocation error would in
> fact result in libxl dereferencing NULL.
> 
> Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
> is marked out specially by having alloc_maxsize==-1, which is
> otherwise invalid.
> 
> Functions which need to actually look into the gc use the new test
> function gc_is_real (whose purpose is mainly clarity of the code) to
> check whether the gc is the dummy one, and do nothing if it is.  And
> we provide a helper macro NOGC which uses the in-scope real gc to find
> the ctx and hence the dummy gc (and which replaces the previous
> #define NOGC NULL).
> 
> Change all callers which pass 0 or NULL to an allocation function to
> use NOGC or &ctx->nogc_gc, as applicable in the context.
> 
> We add a comment near the definition of LIBXL_INIT_GC pointing out
> that it isn't any more the only place a libxl__gc struct is
> initialised, for the benefit of anyone changing the contents of gc's
> in the future.
> 
> Also, actually document that libxl__ptr_add is legal with ptr==NULL,
> and change a couple of calls not to check for NULL argument.
> 
> Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Bamvor Jian Zhang <bjzhang@suse.com>

Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> ---
>  tools/libxl/libxl.c          |    3 +++
>  tools/libxl/libxl_aoutils.c  |    3 ++-
>  tools/libxl/libxl_create.c   |    2 +-
>  tools/libxl/libxl_event.c    |    5 +++--
>  tools/libxl/libxl_exec.c     |    2 +-
>  tools/libxl/libxl_fork.c     |    2 +-
>  tools/libxl/libxl_internal.c |   11 +++++++++--
>  tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
>  tools/libxl/libxl_utils.c    |    6 ++----
>  tools/libxl/libxl_xshelp.c   |    7 ++-----
>  10 files changed, 47 insertions(+), 31 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2a31528..a257902 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>  
>      /* First initialise pointers etc. (cannot fail) */
>  
> +    ctx->nogc_gc.alloc_maxsize = -1;
> +    ctx->nogc_gc.owner = ctx;
> +
>      LIBXL_TAILQ_INIT(&ctx->occurred);
>  
>      ctx->osevent_hooks = 0;
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index 7f8d6d3..99972a2 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
> @@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
>  void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
>                                    const void *data, size_t len)
>  {
> +    EGC_GC;
>      libxl__datacopier_buf *buf;
>      /*
>       * It is safe for this to be called immediately after _start, as
> @@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
>  
>      assert(len < dc->maxsz - dc->used);
>  
> -    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
> +    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
>      buf->used = len;
>      memcpy(buf->buf, data, len);
>  
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 00705d8..ab000bc 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -108,7 +108,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>      }
>  
>      if (b_info->blkdev_start == NULL)
> -        b_info->blkdev_start = libxl__strdup(0, "xvda");
> +        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
>  
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          if (!b_info->u.hvm.bios)
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 565d2c2..eb23a93 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>          if (poller->fd_rindices_allocd < maxfd) {
>              assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
>              poller->fd_rindices =
> -                libxl__realloc(0, poller->fd_rindices,
> +                libxl__realloc(NOGC, poller->fd_rindices,
>                                 maxfd * sizeof(*poller->fd_rindices));
>              memset(poller->fd_rindices + poller->fd_rindices_allocd,
>                     0,
> @@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
>  libxl_event *libxl__event_new(libxl__egc *egc,
>                                libxl_event_type type, uint32_t domid)
>  {
> +    EGC_GC;
>      libxl_event *ev;
>  
> -    ev = libxl__zalloc(0,sizeof(*ev));
> +    ev = libxl__zalloc(NOGC,sizeof(*ev));
>      ev->type = type;
>      ev->domid = domid;
>  
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index 082bf44..cfa379c 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
>      int status, rc;
>  
>      libxl__spawn_init(ss);
> -    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
> +    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
>      libxl__ev_child_init(&ss->ssd->mid);
>  
>      rc = libxl__ev_time_register_rel(gc, &ss->timeout,
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> index 9ff99e0..044ddad 100644
> --- a/tools/libxl/libxl_fork.c
> +++ b/tools/libxl/libxl_fork.c
> @@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
>      libxl__carefd *cf = 0;
>  
>      libxl_fd_set_cloexec(ctx, fd, 1);
> -    cf = libxl__zalloc(NULL, sizeof(*cf));
> +    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
>      cf->fd = fd;
>      LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
>      return cf;
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index 8139520..fbff7d0 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
>  #undef L
>  }
>  
> +static int gc_is_real(const libxl__gc *gc)
> +{
> +    return gc->alloc_maxsize >= 0;
> +}
> +
>  void libxl__ptr_add(libxl__gc *gc, void *ptr)
>  {
>      int i;
>  
> -    if (!gc)
> +    if (!gc_is_real(gc))
>          return;
>  
>      if (!ptr)
> @@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
>      void *ptr;
>      int i;
>  
> +    assert(gc_is_real(gc));
> +
>      for (i = 0; i < gc->alloc_maxsize; i++) {
>          ptr = gc->alloc_ptrs[i];
>          gc->alloc_ptrs[i] = NULL;
> @@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
>  
>      if (ptr == NULL) {
>          libxl__ptr_add(gc, new_ptr);
> -    } else if (new_ptr != ptr && gc != NULL) {
> +    } else if (new_ptr != ptr && gc_is_real(gc)) {
>          for (i = 0; i < gc->alloc_maxsize; i++) {
>              if (gc->alloc_ptrs[i] == ptr) {
>                  gc->alloc_ptrs[i] = new_ptr;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index f90814a..e69482c 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -277,10 +277,18 @@ struct libxl__poller {
>      int wakeup_pipe[2]; /* 0 means no fd allocated */
>  };
>  
> +struct libxl__gc {
> +    /* mini-GC */
> +    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
> +    void **alloc_ptrs;
> +    libxl_ctx *owner;
> +};
> +
>  struct libxl__ctx {
>      xentoollog_logger *lg;
>      xc_interface *xch;
>      struct xs_handle *xsh;
> +    libxl__gc nogc_gc;
>  
>      const libxl_event_hooks *event_hooks;
>      void *event_hooks_user;
> @@ -356,13 +364,6 @@ typedef struct {
>  
>  #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
>  
> -struct libxl__gc {
> -    /* mini-GC */
> -    int alloc_maxsize;
> -    void **alloc_ptrs;
> -    libxl_ctx *owner;
> -};
> -
>  struct libxl__egc {
>      /* For event-generating functions only.
>       * The egc and its gc may be accessed only on the creating thread. */
> @@ -420,6 +421,7 @@ struct libxl__ao {
>          (gc).alloc_ptrs = 0;                    \
>          (gc).owner = (ctx);                     \
>      } while(0)
> +    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
>  
>  static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>  {
> @@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>   * All pointers returned by these functions are registered for garbage
>   * collection on exit from the outermost libxl callframe.
>   *
> - * However, where the argument is stated to be "gc_opt", NULL may be
> - * passed instead, in which case no garbage collection will occur; the
> - * pointer must later be freed with free().  This is for memory
> - * allocations of types (b) and (c).
> + * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
> + * may be passed instead, in which case no garbage collection will
> + * occur; the pointer must later be freed with free().  (Passing NULL
> + * for gc_opt is not permitted.)  This is for memory allocations of
> + * types (b) and (c).  The convenience macro NOGC should be used where
> + * possible.
> + *
> + * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
> + * explicitly declare that it's OK.  Use with nonconsenting functions
> + * may result in leaks of those functions' internal allocations on the
> + * psuedo-gc.
>   */
> -/* register @ptr in @gc for free on exit from outermost libxl callframe. */
> -_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
> +/* register ptr in gc for free on exit from outermost libxl callframe. */
> +_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
>  /* if this is the outermost libxl callframe then free all pointers in @gc */
>  _hidden void libxl__free_all(libxl__gc *gc);
>  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
> @@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
>  #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
>  #define GC_FREE       libxl__free_all(gc)
>  #define CTX           libxl__gc_owner(gc)
> -#define NOGC          NULL
> +#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
>  
>  /* Allocation macros all of which use the gc. */
>  
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 67ef82c..08c7dac 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
>  char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
>  {
>      char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
> -    if ( s )
> -        libxl__ptr_add(gc, s);
> +    libxl__ptr_add(gc, s);
>      return s;
>  }
>  
> @@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
>  char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
>  {
>      char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
> -    if ( s )
> -        libxl__ptr_add(gc, s);
> +    libxl__ptr_add(gc, s);
>      return s;
>  }
>  
> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index 993f527..7fdf164 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
>      char *ptr;
>  
>      ptr = xs_read(ctx->xsh, t, path, NULL);
> -    if (ptr != NULL) {
> -        libxl__ptr_add(gc, ptr);
> -        return ptr;
> -    }
> -    return 0;
> +    libxl__ptr_add(gc, ptr);
> +    return ptr;
>  }
>  
>  char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13: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 1SenMI-000766-Jo; Wed, 13 Jun 2012 13:11: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 1SenMG-00075E-H2
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:11:36 +0000
Received: from [85.158.139.83:40380] by server-5.bemta-5.messagelabs.com id
	F0/89-02722-68198DF4; Wed, 13 Jun 2012 13:11:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339593093!20252513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1917 invoked from network); 13 Jun 2012 13:11:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:11:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:11:33 +0100
Message-ID: <1339593091.24104.210.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:11:31 +0100
In-Reply-To: <1339176870-32652-14-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-14-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Bamvor Jian Zhang <bjzhang@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 13/19] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> In 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
> allocation functions was introduced.  However, the arrangements there
> were not correct as committed, because the error handling and logging
> depends on getting a ctx from the gc - so an allocation error would in
> fact result in libxl dereferencing NULL.
> 
> Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
> is marked out specially by having alloc_maxsize==-1, which is
> otherwise invalid.
> 
> Functions which need to actually look into the gc use the new test
> function gc_is_real (whose purpose is mainly clarity of the code) to
> check whether the gc is the dummy one, and do nothing if it is.  And
> we provide a helper macro NOGC which uses the in-scope real gc to find
> the ctx and hence the dummy gc (and which replaces the previous
> #define NOGC NULL).
> 
> Change all callers which pass 0 or NULL to an allocation function to
> use NOGC or &ctx->nogc_gc, as applicable in the context.
> 
> We add a comment near the definition of LIBXL_INIT_GC pointing out
> that it isn't any more the only place a libxl__gc struct is
> initialised, for the benefit of anyone changing the contents of gc's
> in the future.
> 
> Also, actually document that libxl__ptr_add is legal with ptr==NULL,
> and change a couple of calls not to check for NULL argument.
> 
> Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Bamvor Jian Zhang <bjzhang@suse.com>

Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> ---
>  tools/libxl/libxl.c          |    3 +++
>  tools/libxl/libxl_aoutils.c  |    3 ++-
>  tools/libxl/libxl_create.c   |    2 +-
>  tools/libxl/libxl_event.c    |    5 +++--
>  tools/libxl/libxl_exec.c     |    2 +-
>  tools/libxl/libxl_fork.c     |    2 +-
>  tools/libxl/libxl_internal.c |   11 +++++++++--
>  tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
>  tools/libxl/libxl_utils.c    |    6 ++----
>  tools/libxl/libxl_xshelp.c   |    7 ++-----
>  10 files changed, 47 insertions(+), 31 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2a31528..a257902 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>  
>      /* First initialise pointers etc. (cannot fail) */
>  
> +    ctx->nogc_gc.alloc_maxsize = -1;
> +    ctx->nogc_gc.owner = ctx;
> +
>      LIBXL_TAILQ_INIT(&ctx->occurred);
>  
>      ctx->osevent_hooks = 0;
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index 7f8d6d3..99972a2 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
> @@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
>  void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
>                                    const void *data, size_t len)
>  {
> +    EGC_GC;
>      libxl__datacopier_buf *buf;
>      /*
>       * It is safe for this to be called immediately after _start, as
> @@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
>  
>      assert(len < dc->maxsz - dc->used);
>  
> -    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
> +    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
>      buf->used = len;
>      memcpy(buf->buf, data, len);
>  
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 00705d8..ab000bc 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -108,7 +108,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>      }
>  
>      if (b_info->blkdev_start == NULL)
> -        b_info->blkdev_start = libxl__strdup(0, "xvda");
> +        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
>  
>      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>          if (!b_info->u.hvm.bios)
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 565d2c2..eb23a93 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
>          if (poller->fd_rindices_allocd < maxfd) {
>              assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
>              poller->fd_rindices =
> -                libxl__realloc(0, poller->fd_rindices,
> +                libxl__realloc(NOGC, poller->fd_rindices,
>                                 maxfd * sizeof(*poller->fd_rindices));
>              memset(poller->fd_rindices + poller->fd_rindices_allocd,
>                     0,
> @@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
>  libxl_event *libxl__event_new(libxl__egc *egc,
>                                libxl_event_type type, uint32_t domid)
>  {
> +    EGC_GC;
>      libxl_event *ev;
>  
> -    ev = libxl__zalloc(0,sizeof(*ev));
> +    ev = libxl__zalloc(NOGC,sizeof(*ev));
>      ev->type = type;
>      ev->domid = domid;
>  
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index 082bf44..cfa379c 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
>      int status, rc;
>  
>      libxl__spawn_init(ss);
> -    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
> +    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
>      libxl__ev_child_init(&ss->ssd->mid);
>  
>      rc = libxl__ev_time_register_rel(gc, &ss->timeout,
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> index 9ff99e0..044ddad 100644
> --- a/tools/libxl/libxl_fork.c
> +++ b/tools/libxl/libxl_fork.c
> @@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
>      libxl__carefd *cf = 0;
>  
>      libxl_fd_set_cloexec(ctx, fd, 1);
> -    cf = libxl__zalloc(NULL, sizeof(*cf));
> +    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
>      cf->fd = fd;
>      LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
>      return cf;
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index 8139520..fbff7d0 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
>  #undef L
>  }
>  
> +static int gc_is_real(const libxl__gc *gc)
> +{
> +    return gc->alloc_maxsize >= 0;
> +}
> +
>  void libxl__ptr_add(libxl__gc *gc, void *ptr)
>  {
>      int i;
>  
> -    if (!gc)
> +    if (!gc_is_real(gc))
>          return;
>  
>      if (!ptr)
> @@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
>      void *ptr;
>      int i;
>  
> +    assert(gc_is_real(gc));
> +
>      for (i = 0; i < gc->alloc_maxsize; i++) {
>          ptr = gc->alloc_ptrs[i];
>          gc->alloc_ptrs[i] = NULL;
> @@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
>  
>      if (ptr == NULL) {
>          libxl__ptr_add(gc, new_ptr);
> -    } else if (new_ptr != ptr && gc != NULL) {
> +    } else if (new_ptr != ptr && gc_is_real(gc)) {
>          for (i = 0; i < gc->alloc_maxsize; i++) {
>              if (gc->alloc_ptrs[i] == ptr) {
>                  gc->alloc_ptrs[i] = new_ptr;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index f90814a..e69482c 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -277,10 +277,18 @@ struct libxl__poller {
>      int wakeup_pipe[2]; /* 0 means no fd allocated */
>  };
>  
> +struct libxl__gc {
> +    /* mini-GC */
> +    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
> +    void **alloc_ptrs;
> +    libxl_ctx *owner;
> +};
> +
>  struct libxl__ctx {
>      xentoollog_logger *lg;
>      xc_interface *xch;
>      struct xs_handle *xsh;
> +    libxl__gc nogc_gc;
>  
>      const libxl_event_hooks *event_hooks;
>      void *event_hooks_user;
> @@ -356,13 +364,6 @@ typedef struct {
>  
>  #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
>  
> -struct libxl__gc {
> -    /* mini-GC */
> -    int alloc_maxsize;
> -    void **alloc_ptrs;
> -    libxl_ctx *owner;
> -};
> -
>  struct libxl__egc {
>      /* For event-generating functions only.
>       * The egc and its gc may be accessed only on the creating thread. */
> @@ -420,6 +421,7 @@ struct libxl__ao {
>          (gc).alloc_ptrs = 0;                    \
>          (gc).owner = (ctx);                     \
>      } while(0)
> +    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
>  
>  static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>  {
> @@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
>   * All pointers returned by these functions are registered for garbage
>   * collection on exit from the outermost libxl callframe.
>   *
> - * However, where the argument is stated to be "gc_opt", NULL may be
> - * passed instead, in which case no garbage collection will occur; the
> - * pointer must later be freed with free().  This is for memory
> - * allocations of types (b) and (c).
> + * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
> + * may be passed instead, in which case no garbage collection will
> + * occur; the pointer must later be freed with free().  (Passing NULL
> + * for gc_opt is not permitted.)  This is for memory allocations of
> + * types (b) and (c).  The convenience macro NOGC should be used where
> + * possible.
> + *
> + * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
> + * explicitly declare that it's OK.  Use with nonconsenting functions
> + * may result in leaks of those functions' internal allocations on the
> + * psuedo-gc.
>   */
> -/* register @ptr in @gc for free on exit from outermost libxl callframe. */
> -_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
> +/* register ptr in gc for free on exit from outermost libxl callframe. */
> +_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
>  /* if this is the outermost libxl callframe then free all pointers in @gc */
>  _hidden void libxl__free_all(libxl__gc *gc);
>  /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
> @@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
>  #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
>  #define GC_FREE       libxl__free_all(gc)
>  #define CTX           libxl__gc_owner(gc)
> -#define NOGC          NULL
> +#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
>  
>  /* Allocation macros all of which use the gc. */
>  
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 67ef82c..08c7dac 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
>  char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
>  {
>      char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
> -    if ( s )
> -        libxl__ptr_add(gc, s);
> +    libxl__ptr_add(gc, s);
>      return s;
>  }
>  
> @@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
>  char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
>  {
>      char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
> -    if ( s )
> -        libxl__ptr_add(gc, s);
> +    libxl__ptr_add(gc, s);
>      return s;
>  }
>  
> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index 993f527..7fdf164 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
>      char *ptr;
>  
>      ptr = xs_read(ctx->xsh, t, path, NULL);
> -    if (ptr != NULL) {
> -        libxl__ptr_add(gc, ptr);
> -        return ptr;
> -    }
> -    return 0;
> +    libxl__ptr_add(gc, ptr);
> +    return ptr;
>  }
>  
>  char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:14:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenOX-0007af-BB; Wed, 13 Jun 2012 13:13:57 +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 1SenOW-0007aP-AM
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:13:56 +0000
Received: from [85.158.139.83:6345] by server-10.bemta-5.messagelabs.com id
	87/D1-02190-31298DF4; Wed, 13 Jun 2012 13:13:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339593234!23207889!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21664 invoked from network); 13 Jun 2012 13:13:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 13:13:55 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo60) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x001f4o5DC7eSH ;
	Wed, 13 Jun 2012 15:13:54 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 845DD18638; Wed, 13 Jun 2012 15:13:52 +0200 (CEST)
Date: Wed, 13 Jun 2012 15:13:52 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120613131352.GA1275@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
	<20120613075853.GA22553@aepfle.de>
	<1339574778.24104.122.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339574778.24104.122.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, Jun 13, Ian Campbell wrote:

> On Wed, 2012-06-13 at 08:58 +0100, Olaf Hering wrote:
> > On Tue, Jun 12, Ian Campbell wrote:
> > 
> > > On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > > > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > > > xl-network-configuration. Adjust to new DOCDIR location.
> > > 
> > > The reason for omitting the extension is that it can be .html or .txt
> > > depending on the context which the link is given in.
> > 
> > How is that link ' F<xl-network-configuration>' supposed to be filled?
> > I think F refers to a local filename.
> 
> F<..> just means "format as a filename i.e. italics", it doesn't turn
> into an actual link even in html. I should have said "reference" rather
> than "link" I think.

So how should I handle that part then? Leaving it alone for the time
being? That would be fine with me.

> > > > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > > > +			misc/xl-disk-configuration.txt \
> > > > +			misc/vbd-interface.txt \
> > > > +			misc/xl-network-configuration.markdown
> > > 
> > > Any reason not to install the whole of $(DOC_TXT) instead of just this
> > > subset?
> > 
> > Most of it looks like developer documentation to me. In the end
> > kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
> > installed in addition to the files above.
> 
> Perhaps we should be splitting the misc dir up into user and dev etc?

I think that will just cause unneeded churn. The list of user
documentation files can be maintained in Makefile variable such as
DOCS_TO_INSTALL.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:14:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenOX-0007af-BB; Wed, 13 Jun 2012 13:13:57 +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 1SenOW-0007aP-AM
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:13:56 +0000
Received: from [85.158.139.83:6345] by server-10.bemta-5.messagelabs.com id
	87/D1-02190-31298DF4; Wed, 13 Jun 2012 13:13:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339593234!23207889!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21664 invoked from network); 13 Jun 2012 13:13:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 13:13:55 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo60) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x001f4o5DC7eSH ;
	Wed, 13 Jun 2012 15:13:54 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 845DD18638; Wed, 13 Jun 2012 15:13:52 +0200 (CEST)
Date: Wed, 13 Jun 2012 15:13:52 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120613131352.GA1275@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
	<20120613075853.GA22553@aepfle.de>
	<1339574778.24104.122.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339574778.24104.122.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, Jun 13, Ian Campbell wrote:

> On Wed, 2012-06-13 at 08:58 +0100, Olaf Hering wrote:
> > On Tue, Jun 12, Ian Campbell wrote:
> > 
> > > On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > > > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > > > xl-network-configuration. Adjust to new DOCDIR location.
> > > 
> > > The reason for omitting the extension is that it can be .html or .txt
> > > depending on the context which the link is given in.
> > 
> > How is that link ' F<xl-network-configuration>' supposed to be filled?
> > I think F refers to a local filename.
> 
> F<..> just means "format as a filename i.e. italics", it doesn't turn
> into an actual link even in html. I should have said "reference" rather
> than "link" I think.

So how should I handle that part then? Leaving it alone for the time
being? That would be fine with me.

> > > > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > > > +			misc/xl-disk-configuration.txt \
> > > > +			misc/vbd-interface.txt \
> > > > +			misc/xl-network-configuration.markdown
> > > 
> > > Any reason not to install the whole of $(DOC_TXT) instead of just this
> > > subset?
> > 
> > Most of it looks like developer documentation to me. In the end
> > kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
> > installed in addition to the files above.
> 
> Perhaps we should be splitting the misc dir up into user and dev etc?

I think that will just cause unneeded churn. The list of user
documentation files can be maintained in Makefile variable such as
DOCS_TO_INSTALL.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:16:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenQ8-0007qG-Rl; Wed, 13 Jun 2012 13:15:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SenQ7-0007q5-Ho
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:15:35 +0000
Received: from [85.158.143.99:22737] by server-3.bemta-4.messagelabs.com id
	AE/74-05808-67298DF4; Wed, 13 Jun 2012 13:15:34 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339593331!23003471!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23161 invoked from network); 13 Jun 2012 13:15:33 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Jun 2012 13:15:33 -0000
Received: from mail99-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Wed, 13 Jun 2012 13:14:26 +0000
Received: from mail99-va3 (localhost [127.0.0.1])	by mail99-va3-R.bigfish.com
	(Postfix) with ESMTP id 4BDB43801D1;
	Wed, 13 Jun 2012 13:14:26 +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: 7
X-BigFish: VPS7(z5c5ozzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail99-va3 (localhost.localdomain [127.0.0.1]) by mail99-va3
	(MessageSwitch) id 1339593264644215_16090;
	Wed, 13 Jun 2012 13:14:24 +0000 (UTC)
Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.252])	by
	mail99-va3.bigfish.com (Postfix) with ESMTP id 90A332E004A;
	Wed, 13 Jun 2012 13:14:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server id
	14.1.225.23; Wed, 13 Jun 2012 13:14:21 +0000
X-WSS-ID: 0M5K4TM-02-5H1-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 20C67C80DA;	Wed, 13 Jun 2012 08:15:21 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 13 Jun 2012 08:23:44 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 13 Jun 2012 08:15:19 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012
	09:15:18 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0575649C1FF; Wed, 13 Jun 2012
	14:15:18 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id E6FD42D2032; Wed,
	13 Jun 2012 15:15:17 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 08cf5548d5ccc2995661fb25047906094a6b3deb
Message-ID: <08cf5548d5ccc2995661.1339593302@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Wed, 13 Jun 2012 15:15:02 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keir@xen.org>, <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] x86,
	cpufreq: Change powernow's CPB status immediately
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339592992 -7200
# Node ID 08cf5548d5ccc2995661fb25047906094a6b3deb
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
x86, cpufreq: Change powernow's CPB status immediately

When command to modify turbo mode (CPB on AMD processors) comes
in the actual change happens later, when P-state transition is
requested. There is no time limit on when this transition will
occur and therefore change in CPB state may take long time from
the moment when command to toggle it is issued.

This patch makes CPB mode change happen immediately when request
is made.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r 08cf5548d5cc xen/arch/x86/acpi/cpufreq/powernow.c
--- a/xen/arch/x86/acpi/cpufreq/powernow.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c	Wed Jun 13 15:09:52 2012 +0200
@@ -68,16 +68,37 @@ static void transition_pstate(void *drvc
     struct drv_cmd *cmd;
     cmd = (struct drv_cmd *) drvcmd;
 
-    if (cmd->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
+
+    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static void update_cpb(void *data)
+{
+    struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
+
+    if (policy->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
         uint64_t msr_content;
+ 
         rdmsrl(MSR_K8_HWCR, msr_content);
-        if (cmd->turbo == CPUFREQ_TURBO_ENABLED)
+
+        if (policy->turbo == CPUFREQ_TURBO_ENABLED)
             msr_content &= ~MSR_HWCR_CPBDIS_MASK;
         else
             msr_content |= MSR_HWCR_CPBDIS_MASK; 
+
         wrmsrl(MSR_K8_HWCR, msr_content);
     }
-    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static int powernow_cpufreq_update (int cpuid,
+				     struct cpufreq_policy *policy)
+{
+    if (!cpumask_test_cpu(cpuid, &cpu_online_map))
+        return -EINVAL;
+
+    on_selected_cpus(cpumask_of(cpuid), update_cpb, policy, 1);
+
+    return 0;
 }
 
 static int powernow_cpufreq_target(struct cpufreq_policy *policy,
@@ -300,7 +321,8 @@ static struct cpufreq_driver powernow_cp
     .verify = powernow_cpufreq_verify,
     .target = powernow_cpufreq_target,
     .init   = powernow_cpufreq_cpu_init,
-    .exit   = powernow_cpufreq_cpu_exit
+    .exit   = powernow_cpufreq_cpu_exit,
+    .update = powernow_cpufreq_update
 };
 
 unsigned int __init powernow_register_driver()
diff -r 32034d1914a6 -r 08cf5548d5cc xen/drivers/acpi/pmstat.c
--- a/xen/drivers/acpi/pmstat.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/acpi/pmstat.c	Wed Jun 13 15:09:52 2012 +0200
@@ -494,13 +494,13 @@ int do_pm_op(struct xen_sysctl_pm_op *op
 
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
-        cpufreq_enable_turbo(op->cpuid);
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
         break;
     }
 
     case XEN_SYSCTL_pm_op_disable_turbo:
     {
-        cpufreq_disable_turbo(op->cpuid);
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
         break;
     }
 
diff -r 32034d1914a6 -r 08cf5548d5cc xen/drivers/cpufreq/utility.c
--- a/xen/drivers/cpufreq/utility.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/cpufreq/utility.c	Wed Jun 13 15:09:52 2012 +0200
@@ -390,23 +390,38 @@ int cpufreq_driver_getavg(unsigned int c
     return policy->cur;
 }
 
-void cpufreq_enable_turbo(int cpuid)
+int cpufreq_update_turbo(int cpuid, int new_state)
 {
     struct cpufreq_policy *policy;
+    int curr_state;
+    int ret = 0;
+
+    if (new_state != CPUFREQ_TURBO_ENABLED &&
+        new_state != CPUFREQ_TURBO_DISABLED)
+        return -EINVAL;
 
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
-        policy->turbo = CPUFREQ_TURBO_ENABLED;
+    if (!policy)
+        return -EACCES;
+
+    if (policy->turbo == CPUFREQ_TURBO_UNSUPPORTED)
+        return -EOPNOTSUPP;
+
+    curr_state = policy->turbo;
+    if (curr_state == new_state)
+        return 0;
+
+    policy->turbo = new_state;
+    if (cpufreq_driver->update)
+    {
+        ret = cpufreq_driver->update(cpuid, policy);
+        if (ret)
+            policy->turbo = curr_state;
+    }
+
+    return ret;
 }
 
-void cpufreq_disable_turbo(int cpuid)
-{
-    struct cpufreq_policy *policy;
-
-    policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
-        policy->turbo = CPUFREQ_TURBO_DISABLED;
-}
 
 int cpufreq_get_turbo_status(int cpuid)
 {
diff -r 32034d1914a6 -r 08cf5548d5cc xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/acpi/cpufreq/cpufreq.h	Wed Jun 13 15:09:52 2012 +0200
@@ -124,8 +124,7 @@ extern int cpufreq_driver_getavg(unsigne
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
-extern void cpufreq_enable_turbo(int cpuid);
-extern void cpufreq_disable_turbo(int cpuid);
+extern int cpufreq_update_turbo(int cpuid, int new_state);
 extern int cpufreq_get_turbo_status(int cpuid);
 
 static __inline__ int 
@@ -146,6 +145,7 @@ struct cpufreq_driver {
     char   name[CPUFREQ_NAME_LEN];
     int    (*init)(struct cpufreq_policy *policy);
     int    (*verify)(struct cpufreq_policy *policy);
+    int    (*update)(int cpuid, struct cpufreq_policy *policy);
     int    (*target)(struct cpufreq_policy *policy,
                      unsigned int target_freq,
                      unsigned int relation);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:16:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SenQ8-0007qG-Rl; Wed, 13 Jun 2012 13:15:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1SenQ7-0007q5-Ho
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 13:15:35 +0000
Received: from [85.158.143.99:22737] by server-3.bemta-4.messagelabs.com id
	AE/74-05808-67298DF4; Wed, 13 Jun 2012 13:15:34 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339593331!23003471!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23161 invoked from network); 13 Jun 2012 13:15:33 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Jun 2012 13:15:33 -0000
Received: from mail99-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Wed, 13 Jun 2012 13:14:26 +0000
Received: from mail99-va3 (localhost [127.0.0.1])	by mail99-va3-R.bigfish.com
	(Postfix) with ESMTP id 4BDB43801D1;
	Wed, 13 Jun 2012 13:14:26 +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: 7
X-BigFish: VPS7(z5c5ozzz1202hzz8275bhz2dh668h839h944hd24hf0ah)
Received: from mail99-va3 (localhost.localdomain [127.0.0.1]) by mail99-va3
	(MessageSwitch) id 1339593264644215_16090;
	Wed, 13 Jun 2012 13:14:24 +0000 (UTC)
Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.252])	by
	mail99-va3.bigfish.com (Postfix) with ESMTP id 90A332E004A;
	Wed, 13 Jun 2012 13:14:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server id
	14.1.225.23; Wed, 13 Jun 2012 13:14:21 +0000
X-WSS-ID: 0M5K4TM-02-5H1-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 20C67C80DA;	Wed, 13 Jun 2012 08:15:21 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 13 Jun 2012 08:23:44 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 13 Jun 2012 08:15:19 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012
	09:15:18 -0400
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0575649C1FF; Wed, 13 Jun 2012
	14:15:18 +0100 (BST)
Received: by wotan.amd.com (Postfix, from userid 41729)	id E6FD42D2032; Wed,
	13 Jun 2012 15:15:17 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 08cf5548d5ccc2995661fb25047906094a6b3deb
Message-ID: <08cf5548d5ccc2995661.1339593302@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Wed, 13 Jun 2012 15:15:02 +0200
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keir@xen.org>, <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] x86,
	cpufreq: Change powernow's CPB status immediately
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1339592992 -7200
# Node ID 08cf5548d5ccc2995661fb25047906094a6b3deb
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
x86, cpufreq: Change powernow's CPB status immediately

When command to modify turbo mode (CPB on AMD processors) comes
in the actual change happens later, when P-state transition is
requested. There is no time limit on when this transition will
occur and therefore change in CPB state may take long time from
the moment when command to toggle it is issued.

This patch makes CPB mode change happen immediately when request
is made.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 32034d1914a6 -r 08cf5548d5cc xen/arch/x86/acpi/cpufreq/powernow.c
--- a/xen/arch/x86/acpi/cpufreq/powernow.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c	Wed Jun 13 15:09:52 2012 +0200
@@ -68,16 +68,37 @@ static void transition_pstate(void *drvc
     struct drv_cmd *cmd;
     cmd = (struct drv_cmd *) drvcmd;
 
-    if (cmd->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
+
+    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static void update_cpb(void *data)
+{
+    struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
+
+    if (policy->turbo != CPUFREQ_TURBO_UNSUPPORTED) {
         uint64_t msr_content;
+ 
         rdmsrl(MSR_K8_HWCR, msr_content);
-        if (cmd->turbo == CPUFREQ_TURBO_ENABLED)
+
+        if (policy->turbo == CPUFREQ_TURBO_ENABLED)
             msr_content &= ~MSR_HWCR_CPBDIS_MASK;
         else
             msr_content |= MSR_HWCR_CPBDIS_MASK; 
+
         wrmsrl(MSR_K8_HWCR, msr_content);
     }
-    wrmsrl(MSR_PSTATE_CTRL, cmd->val);
+}
+
+static int powernow_cpufreq_update (int cpuid,
+				     struct cpufreq_policy *policy)
+{
+    if (!cpumask_test_cpu(cpuid, &cpu_online_map))
+        return -EINVAL;
+
+    on_selected_cpus(cpumask_of(cpuid), update_cpb, policy, 1);
+
+    return 0;
 }
 
 static int powernow_cpufreq_target(struct cpufreq_policy *policy,
@@ -300,7 +321,8 @@ static struct cpufreq_driver powernow_cp
     .verify = powernow_cpufreq_verify,
     .target = powernow_cpufreq_target,
     .init   = powernow_cpufreq_cpu_init,
-    .exit   = powernow_cpufreq_cpu_exit
+    .exit   = powernow_cpufreq_cpu_exit,
+    .update = powernow_cpufreq_update
 };
 
 unsigned int __init powernow_register_driver()
diff -r 32034d1914a6 -r 08cf5548d5cc xen/drivers/acpi/pmstat.c
--- a/xen/drivers/acpi/pmstat.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/acpi/pmstat.c	Wed Jun 13 15:09:52 2012 +0200
@@ -494,13 +494,13 @@ int do_pm_op(struct xen_sysctl_pm_op *op
 
     case XEN_SYSCTL_pm_op_enable_turbo:
     {
-        cpufreq_enable_turbo(op->cpuid);
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
         break;
     }
 
     case XEN_SYSCTL_pm_op_disable_turbo:
     {
-        cpufreq_disable_turbo(op->cpuid);
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
         break;
     }
 
diff -r 32034d1914a6 -r 08cf5548d5cc xen/drivers/cpufreq/utility.c
--- a/xen/drivers/cpufreq/utility.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/cpufreq/utility.c	Wed Jun 13 15:09:52 2012 +0200
@@ -390,23 +390,38 @@ int cpufreq_driver_getavg(unsigned int c
     return policy->cur;
 }
 
-void cpufreq_enable_turbo(int cpuid)
+int cpufreq_update_turbo(int cpuid, int new_state)
 {
     struct cpufreq_policy *policy;
+    int curr_state;
+    int ret = 0;
+
+    if (new_state != CPUFREQ_TURBO_ENABLED &&
+        new_state != CPUFREQ_TURBO_DISABLED)
+        return -EINVAL;
 
     policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
-        policy->turbo = CPUFREQ_TURBO_ENABLED;
+    if (!policy)
+        return -EACCES;
+
+    if (policy->turbo == CPUFREQ_TURBO_UNSUPPORTED)
+        return -EOPNOTSUPP;
+
+    curr_state = policy->turbo;
+    if (curr_state == new_state)
+        return 0;
+
+    policy->turbo = new_state;
+    if (cpufreq_driver->update)
+    {
+        ret = cpufreq_driver->update(cpuid, policy);
+        if (ret)
+            policy->turbo = curr_state;
+    }
+
+    return ret;
 }
 
-void cpufreq_disable_turbo(int cpuid)
-{
-    struct cpufreq_policy *policy;
-
-    policy = per_cpu(cpufreq_cpu_policy, cpuid);
-    if (policy && policy->turbo != CPUFREQ_TURBO_UNSUPPORTED)
-        policy->turbo = CPUFREQ_TURBO_DISABLED;
-}
 
 int cpufreq_get_turbo_status(int cpuid)
 {
diff -r 32034d1914a6 -r 08cf5548d5cc xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/acpi/cpufreq/cpufreq.h	Wed Jun 13 15:09:52 2012 +0200
@@ -124,8 +124,7 @@ extern int cpufreq_driver_getavg(unsigne
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
-extern void cpufreq_enable_turbo(int cpuid);
-extern void cpufreq_disable_turbo(int cpuid);
+extern int cpufreq_update_turbo(int cpuid, int new_state);
 extern int cpufreq_get_turbo_status(int cpuid);
 
 static __inline__ int 
@@ -146,6 +145,7 @@ struct cpufreq_driver {
     char   name[CPUFREQ_NAME_LEN];
     int    (*init)(struct cpufreq_policy *policy);
     int    (*verify)(struct cpufreq_policy *policy);
+    int    (*update)(int cpuid, struct cpufreq_policy *policy);
     int    (*target)(struct cpufreq_policy *policy,
                      unsigned int target_freq,
                      unsigned int relation);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:25:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:25: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 1SenZI-00088X-Kt; Wed, 13 Jun 2012 13:25: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 1SenZH-00088M-1w
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:25:03 +0000
Received: from [193.109.254.147:50533] by server-2.bemta-14.messagelabs.com id
	B8/D4-27740-EA498DF4; Wed, 13 Jun 2012 13:25:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339593901!3892479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17738 invoked from network); 13 Jun 2012 13:25:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:25:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:25:01 +0100
Message-ID: <1339593900.24104.214.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:25:00 +0100
In-Reply-To: <1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle
 children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> libxl__spawn_spawn would, when libxl__spawn_detach was called, make
> the spawn become idle immediately.  However it still has a child
> process which needs to be waited for: the `detachable' spawned
> child.
> 
> This is wrong because the ultimate in-libxl caller may return to the
> application, with a child process still forked but not reaped libxl
> contrary to the documented behaviour of libxl.
> 
> Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
> which is asynchronous.  The detachable spawned children are abolished;
> instead, we defer calling back to the in-libxl user until the middle
> child has been reaped.
> 
> Also, remove erroneous comment suggesting that `death' callback
> parameter to libxl__ev_child_fork may be NULL.  It may not, and there
> are no callers which pass NULL.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(couple of tiny queries below)

[...]
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index cfa379c..bb85682 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -238,15 +238,16 @@ err:
>  /*
>   * Full set of possible states of a libxl__spawn_state and its _detachable:
>   *
> - *               ss->        ss->        ss->    | ssd->       ssd->
> - *               timeout     xswatch     ssd     |  mid         ss
> - *  - Undefined   undef       undef       no     |  -           -
> - *  - Idle        Idle        Idle        no     |  -           -
> - *  - Active      Active      Active      yes    |  Active      yes
> - *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
> - *  - Detached    -           -           -      |  Active      no
> + *                   detaching failed  mid     timeout      xswatch
> + *  - Undefined         undef   undef   -        undef        undef
> + *  - Idle              any     any     Idle     Idle         Idle
> + *  - Attached OK       0       0       Active   Active       Active
> + *  - Attached Failed   0       1       Active   Idle         Idle
> + *  - Detaching         1       maybe   Active   Idle         Idle
> + *  - Partial           any     any     Idle     Active/Idle  Active/Idle
>   *
> - * When in state Detached, the middle process has been sent a SIGKILL.
> + * When in states Detaching or Attached Failed, the middle process has
> + * been sent a SIGKILL.
>   */
> 
>  /* Event callbacks. */
> @@ -257,19 +258,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
>  static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
>                                 pid_t pid, int status);
> 
> -/* Precondition: Partial.  Results: Detached. */
> +/* Precondition: Partial.  Results: Idle. */
>  static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
> 
> -/* Precondition: Partial; caller has logged failure reason.
> - * Results: Caller notified of failure;
> - *  after return, ss may be completely invalid as caller may reuse it */
> -static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
> +/* Precondition: Attached or Detaching; caller has logged failure reason.
> + * Results: Detaching, or Attached Failing */

Is it Failing or Failed? You use Failed elsewhere.

[...]
> @@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
>   *
>   * Higher-level double-fork and separate detach eg as for device models
>   *
> - * Each libxl__spawn_state is in one of the conventional states
> - *    Undefined, Idle, Active
> + * Each libxl__spawn_state is in one of these states
> + *    Undefined, Idle, Attached, Detaching

"Attached OK" and "Attached Failed" as described above aren't really
full states, just sub-states?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:25:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13:25: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 1SenZI-00088X-Kt; Wed, 13 Jun 2012 13:25: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 1SenZH-00088M-1w
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:25:03 +0000
Received: from [193.109.254.147:50533] by server-2.bemta-14.messagelabs.com id
	B8/D4-27740-EA498DF4; Wed, 13 Jun 2012 13:25:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339593901!3892479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17738 invoked from network); 13 Jun 2012 13:25:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12996996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:25:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:25:01 +0100
Message-ID: <1339593900.24104.214.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:25:00 +0100
In-Reply-To: <1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle
 children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> libxl__spawn_spawn would, when libxl__spawn_detach was called, make
> the spawn become idle immediately.  However it still has a child
> process which needs to be waited for: the `detachable' spawned
> child.
> 
> This is wrong because the ultimate in-libxl caller may return to the
> application, with a child process still forked but not reaped libxl
> contrary to the documented behaviour of libxl.
> 
> Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
> which is asynchronous.  The detachable spawned children are abolished;
> instead, we defer calling back to the in-libxl user until the middle
> child has been reaped.
> 
> Also, remove erroneous comment suggesting that `death' callback
> parameter to libxl__ev_child_fork may be NULL.  It may not, and there
> are no callers which pass NULL.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(couple of tiny queries below)

[...]
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index cfa379c..bb85682 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -238,15 +238,16 @@ err:
>  /*
>   * Full set of possible states of a libxl__spawn_state and its _detachable:
>   *
> - *               ss->        ss->        ss->    | ssd->       ssd->
> - *               timeout     xswatch     ssd     |  mid         ss
> - *  - Undefined   undef       undef       no     |  -           -
> - *  - Idle        Idle        Idle        no     |  -           -
> - *  - Active      Active      Active      yes    |  Active      yes
> - *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
> - *  - Detached    -           -           -      |  Active      no
> + *                   detaching failed  mid     timeout      xswatch
> + *  - Undefined         undef   undef   -        undef        undef
> + *  - Idle              any     any     Idle     Idle         Idle
> + *  - Attached OK       0       0       Active   Active       Active
> + *  - Attached Failed   0       1       Active   Idle         Idle
> + *  - Detaching         1       maybe   Active   Idle         Idle
> + *  - Partial           any     any     Idle     Active/Idle  Active/Idle
>   *
> - * When in state Detached, the middle process has been sent a SIGKILL.
> + * When in states Detaching or Attached Failed, the middle process has
> + * been sent a SIGKILL.
>   */
> 
>  /* Event callbacks. */
> @@ -257,19 +258,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
>  static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
>                                 pid_t pid, int status);
> 
> -/* Precondition: Partial.  Results: Detached. */
> +/* Precondition: Partial.  Results: Idle. */
>  static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
> 
> -/* Precondition: Partial; caller has logged failure reason.
> - * Results: Caller notified of failure;
> - *  after return, ss may be completely invalid as caller may reuse it */
> -static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
> +/* Precondition: Attached or Detaching; caller has logged failure reason.
> + * Results: Detaching, or Attached Failing */

Is it Failing or Failed? You use Failed elsewhere.

[...]
> @@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
>   *
>   * Higher-level double-fork and separate detach eg as for device models
>   *
> - * Each libxl__spawn_state is in one of the conventional states
> - *    Undefined, Idle, Active
> + * Each libxl__spawn_state is in one of these states
> + *    Undefined, Idle, Attached, Detaching

"Attached OK" and "Attached Failed" as described above aren't really
full states, just sub-states?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 13:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13: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 1SenoV-0000Vf-Oc; Wed, 13 Jun 2012 13:40: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 1SenoU-0000Va-Op
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:40:46 +0000
Received: from [85.158.139.83:10573] by server-4.bemta-5.messagelabs.com id
	BB/DA-27831-D5898DF4; Wed, 13 Jun 2012 13:40:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339594844!27485865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19376 invoked from network); 13 Jun 2012 13:40:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12997692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:40:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:40:44 +0100
Message-ID: <1339594843.24104.218.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:40:43 +0100
In-Reply-To: <1338993031.32319.107.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
	<1338993031.32319.107.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 15:30 +0100, Ian Campbell wrote:
> > there is no need to introduce p2m_lookup in the same patch you do these
> > unrelated printk adjustments, correct?
> > 
> 
> Right, I think I've just put them in the wrong patch by mistake, I'll
> figure out what I meant to do ...

These ended up in my combined replacement for patches #2 and #3 which
was posted in <1339086867.18523.36.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 Jun 13 13:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 13: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 1SenoV-0000Vf-Oc; Wed, 13 Jun 2012 13:40: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 1SenoU-0000Va-Op
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 13:40:46 +0000
Received: from [85.158.139.83:10573] by server-4.bemta-5.messagelabs.com id
	BB/DA-27831-D5898DF4; Wed, 13 Jun 2012 13:40:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339594844!27485865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19376 invoked from network); 13 Jun 2012 13:40:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 13:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="12997692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 13:40:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 14:40:44 +0100
Message-ID: <1339594843.24104.218.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 13 Jun 2012 14:40:43 +0100
In-Reply-To: <1338993031.32319.107.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061452530.6030@kaball.uk.xensource.com>
	<1338993031.32319.107.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 15:30 +0100, Ian Campbell wrote:
> > there is no need to introduce p2m_lookup in the same patch you do these
> > unrelated printk adjustments, correct?
> > 
> 
> Right, I think I've just put them in the wrong patch by mistake, I'll
> figure out what I meant to do ...

These ended up in my combined replacement for patches #2 and #3 which
was posted in <1339086867.18523.36.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 Jun 13 14:03:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Seo9c-00012t-Om; Wed, 13 Jun 2012 14:02:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasonbstubbs@gmail.com>) id 1SePwt-0005FY-2N
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:11:51 +0000
Received: from [85.158.139.83:8149] by server-12.bemta-5.messagelabs.com id
	BF/9D-18374-60237DF4; Tue, 12 Jun 2012 12:11:50 +0000
X-Env-Sender: jasonbstubbs@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339503108!29249280!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6865 invoked from network); 12 Jun 2012 12:11:49 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:11:49 -0000
Received: by dadv2 with SMTP id v2so7125932dad.32
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 05:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=J+ynWQcwhUHk4S6GmkwVF4lnn1pej6Nm8Xf+hpUZ5hk=;
	b=csQ7E38jnicTOws/saRW5O7+8RJ8ec69HxMf3v9u2yjIzb2XJipkKFewv13bduGlxZ
	HNgVBaOqq8JHwFah4ZJ1Gi4GA/1fbRo+nLYcS78t8GDa0jWIjzOXFZAi4aQTryZ4ngDu
	EvVXyEcRjZR70WEfSlSr8wuxR7wN/70NbircQpJTndA206uaB42xO0JpHHAtzYh0jcxh
	GihR34N1EzYMN27Ks+vJ2+TXJD+dUYE5oveJbIEUXoI7XYA6BN1pHonUhzOLeA824Lmf
	JJGDP9hOrZNZFpN1oClvzHalY1XQUIhg9tsE3RPw62aUMrYqRI4WtjJ+0bbuj/Ux6/NA
	tHiA==
Received: by 10.68.201.9 with SMTP id jw9mr3465181pbc.28.1339503107477;
	Tue, 12 Jun 2012 05:11:47 -0700 (PDT)
Received: from Jasons-MacBook-Pro.local
	(ppp59-167-188-156.static.internode.on.net. [59.167.188.156])
	by mx.google.com with ESMTPS id qn1sm1852818pbc.9.2012.06.12.05.11.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 12 Jun 2012 05:11:43 -0700 (PDT)
Message-ID: <4FD731F9.8070509@gmail.com>
Date: Tue, 12 Jun 2012 22:11:37 +1000
From: Jason Stubbs <jasonbstubbs@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: Dave Chinner <david@fromorbit.com>
References: <4FD1918A.2060908@gmail.com> <20120612035737.GL22848@dastard>
In-Reply-To: <20120612035737.GL22848@dastard>
X-Mailman-Approved-At: Wed, 13 Jun 2012 14:02:34 +0000
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PROBLEM: Possible race between  xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-6-12 13:57 , Dave Chinner wrote:
> Nothing
> wrong with MD, LVM, or XFS. The problem is either that EBS never
> completed the IO, or Xen swallowed it and it never made to it to the
> guest OS. Either way, it does not appear to be a problem in the
> higher levels of the linux storage stack.

Thanks Dave for looking into this.

I'll be sure to give Amazon ample opportunity to diagnose things from
there side should the issue occur again and hopefully there won't be
any more people reporting extraneous issues.

--
Regards,
Jason Stubbs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 14:03:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Seo9c-00012t-Om; Wed, 13 Jun 2012 14:02:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasonbstubbs@gmail.com>) id 1SePwt-0005FY-2N
	for xen-devel@lists.xen.org; Tue, 12 Jun 2012 12:11:51 +0000
Received: from [85.158.139.83:8149] by server-12.bemta-5.messagelabs.com id
	BF/9D-18374-60237DF4; Tue, 12 Jun 2012 12:11:50 +0000
X-Env-Sender: jasonbstubbs@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339503108!29249280!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6865 invoked from network); 12 Jun 2012 12:11:49 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jun 2012 12:11:49 -0000
Received: by dadv2 with SMTP id v2so7125932dad.32
	for <xen-devel@lists.xen.org>; Tue, 12 Jun 2012 05:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=J+ynWQcwhUHk4S6GmkwVF4lnn1pej6Nm8Xf+hpUZ5hk=;
	b=csQ7E38jnicTOws/saRW5O7+8RJ8ec69HxMf3v9u2yjIzb2XJipkKFewv13bduGlxZ
	HNgVBaOqq8JHwFah4ZJ1Gi4GA/1fbRo+nLYcS78t8GDa0jWIjzOXFZAi4aQTryZ4ngDu
	EvVXyEcRjZR70WEfSlSr8wuxR7wN/70NbircQpJTndA206uaB42xO0JpHHAtzYh0jcxh
	GihR34N1EzYMN27Ks+vJ2+TXJD+dUYE5oveJbIEUXoI7XYA6BN1pHonUhzOLeA824Lmf
	JJGDP9hOrZNZFpN1oClvzHalY1XQUIhg9tsE3RPw62aUMrYqRI4WtjJ+0bbuj/Ux6/NA
	tHiA==
Received: by 10.68.201.9 with SMTP id jw9mr3465181pbc.28.1339503107477;
	Tue, 12 Jun 2012 05:11:47 -0700 (PDT)
Received: from Jasons-MacBook-Pro.local
	(ppp59-167-188-156.static.internode.on.net. [59.167.188.156])
	by mx.google.com with ESMTPS id qn1sm1852818pbc.9.2012.06.12.05.11.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 12 Jun 2012 05:11:43 -0700 (PDT)
Message-ID: <4FD731F9.8070509@gmail.com>
Date: Tue, 12 Jun 2012 22:11:37 +1000
From: Jason Stubbs <jasonbstubbs@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: Dave Chinner <david@fromorbit.com>
References: <4FD1918A.2060908@gmail.com> <20120612035737.GL22848@dastard>
In-Reply-To: <20120612035737.GL22848@dastard>
X-Mailman-Approved-At: Wed, 13 Jun 2012 14:02:34 +0000
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PROBLEM: Possible race between  xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-6-12 13:57 , Dave Chinner wrote:
> Nothing
> wrong with MD, LVM, or XFS. The problem is either that EBS never
> completed the IO, or Xen swallowed it and it never made to it to the
> guest OS. Either way, it does not appear to be a problem in the
> higher levels of the linux storage stack.

Thanks Dave for looking into this.

I'll be sure to give Amazon ample opportunity to diagnose things from
there side should the issue occur again and hopefully there won't be
any more people reporting extraneous issues.

--
Regards,
Jason Stubbs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 14:04:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14: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 1SeoAg-0001I8-7z; Wed, 13 Jun 2012 14:03:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SeoAe-0001Hj-MJ
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 14:03:40 +0000
Received: from [85.158.143.99:22504] by server-1.bemta-4.messagelabs.com id
	73/9D-24392-CBD98DF4; Wed, 13 Jun 2012 14:03:40 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339596218!32340320!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1664 invoked from network); 13 Jun 2012 14:03:39 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	13 Jun 2012 14:03:39 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5DE3XKs027301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 10:03:33 -0400
Received: from redhat.com (vpn-203-147.tlv.redhat.com [10.35.203.147])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5DE3UOr025571; Wed, 13 Jun 2012 10:03:31 -0400
Date: Wed, 13 Jun 2012 17:04:06 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Message-ID: <20120613140405.GA20359@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<20120613112257.GF18001@redhat.com> <4FD87DFE.3080904@siemens.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD87DFE.3080904@siemens.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Wed, Jun 13, 2012 at 01:48:14PM +0200, Jan Kiszka wrote:
> On 2012-06-13 13:22, Michael S. Tsirkin wrote:
> > On Wed, Jun 13, 2012 at 01:15:23PM +0200, Jan Kiszka wrote:
> >> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
> >>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> >>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> >>>>
> >>>> This function is used by a later patch to parse the BDF of the device to
> >>>> passthrough.
> >>>>
> >>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >>>
> >>> You probably want to parse the host address?  You don't want to copy the
> >>> bugs in pci_parse_devaddr - write your own that has sane semantics
> >>> for host. E.g. you need to support ARI etc.
> >>
> >> We should really consolidate over one parser for Xen, KVM device
> >> assignment and VFIO. It looks like they all have very similar requirements.
> > 
> > Also rename pci_parse_devaddr to pci_parse_legacy_devaddr
> > to stress it's not something others should reuse.
> 
> That depends on what pci_parse_devaddr will do in the end. If it will
> become as general as my qemu_parse_pci_devaddr, "legacy" would be
> inappropriate.
> 
> Jan

I'd rather keep it separate than adding OPT_LEGACY.

> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 14:04:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14: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 1SeoAg-0001I8-7z; Wed, 13 Jun 2012 14:03:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SeoAe-0001Hj-MJ
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 14:03:40 +0000
Received: from [85.158.143.99:22504] by server-1.bemta-4.messagelabs.com id
	73/9D-24392-CBD98DF4; Wed, 13 Jun 2012 14:03:40 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339596218!32340320!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1664 invoked from network); 13 Jun 2012 14:03:39 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	13 Jun 2012 14:03:39 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5DE3XKs027301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 10:03:33 -0400
Received: from redhat.com (vpn-203-147.tlv.redhat.com [10.35.203.147])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5DE3UOr025571; Wed, 13 Jun 2012 10:03:31 -0400
Date: Wed, 13 Jun 2012 17:04:06 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Message-ID: <20120613140405.GA20359@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<20120613112257.GF18001@redhat.com> <4FD87DFE.3080904@siemens.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD87DFE.3080904@siemens.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 Wed, Jun 13, 2012 at 01:48:14PM +0200, Jan Kiszka wrote:
> On 2012-06-13 13:22, Michael S. Tsirkin wrote:
> > On Wed, Jun 13, 2012 at 01:15:23PM +0200, Jan Kiszka wrote:
> >> On 2012-06-12 17:15, Michael S. Tsirkin wrote:
> >>> On Tue, Jun 12, 2012 at 04:05:19PM +0100, Anthony PERARD wrote:
> >>>> This reverts commit 94a09e2c846374a96719cda2b4e1312d8c4b08a7.
> >>>>
> >>>> This function is used by a later patch to parse the BDF of the device to
> >>>> passthrough.
> >>>>
> >>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >>>
> >>> You probably want to parse the host address?  You don't want to copy the
> >>> bugs in pci_parse_devaddr - write your own that has sane semantics
> >>> for host. E.g. you need to support ARI etc.
> >>
> >> We should really consolidate over one parser for Xen, KVM device
> >> assignment and VFIO. It looks like they all have very similar requirements.
> > 
> > Also rename pci_parse_devaddr to pci_parse_legacy_devaddr
> > to stress it's not something others should reuse.
> 
> That depends on what pci_parse_devaddr will do in the end. If it will
> become as general as my qemu_parse_pci_devaddr, "legacy" would be
> inappropriate.
> 
> Jan

I'd rather keep it separate than adding OPT_LEGACY.

> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 14:12:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeoIC-000241-1R; Wed, 13 Jun 2012 14:11: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 1SeoIA-00023p-LT
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 14:11:26 +0000
Received: from [85.158.138.51:57918] by server-12.bemta-3.messagelabs.com id
	41/28-24185-D8F98DF4; Wed, 13 Jun 2012 14:11:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339596683!27504389!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4ODAxNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23053 invoked from network); 13 Jun 2012 14:11:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 14:11:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DEBITt025490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 14:11:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5DEBHDY016696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 14:11:18 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
	q5DEBG8H004032; Wed, 13 Jun 2012 09:11:17 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 07:11:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30F92402D7; Wed, 13 Jun 2012 10:04:04 -0400 (EDT)
Date: Wed, 13 Jun 2012 10:04:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120613140404.GH5979@phenom.dumpdata.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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, Jun 13, 2012 at 11:20:43AM +0100, David Vrabel wrote:
> This series removes the x86-specific implementation of
> ptep_get_and_clear() and pmdp_get_and_clear().
> 
> The principal reason for this is it allows Xen paravitualized guests
> to batch the PTE clears which is a significant performance
> optimization of munmap() and mremap() -- the number of entries into
> the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
> guests) for munmap().
> 
> There may be minimal gains on native and KVM guests due to the removal
> of the locked xchg.

What about lguest?
> 
> Removal of arch-specific functions where generic ones are suitable
> seems to be a generally useful thing to me.
> 
> The full reasoning for why this is safe is included in the commit
> message of patch 1 but to summarize.  The atomic get-and-clear does
> not guarantee that the latest dirty/accessed bits are returned as TLB
> as there is a still a window after the get-and-clear and before the
> TLB flush that the bits may be updated on other processors.  So, user
> space applications accessing pages that are being unmapped or remapped
> already have unpredictable behaviour.
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 14:12:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SeoIC-000241-1R; Wed, 13 Jun 2012 14:11: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 1SeoIA-00023p-LT
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 14:11:26 +0000
Received: from [85.158.138.51:57918] by server-12.bemta-3.messagelabs.com id
	41/28-24185-D8F98DF4; Wed, 13 Jun 2012 14:11:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339596683!27504389!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4ODAxNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23053 invoked from network); 13 Jun 2012 14:11:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 14:11:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DEBITt025490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 14:11:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5DEBHDY016696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 14:11:18 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
	q5DEBG8H004032; Wed, 13 Jun 2012 09:11:17 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 07:11:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30F92402D7; Wed, 13 Jun 2012 10:04:04 -0400 (EDT)
Date: Wed, 13 Jun 2012 10:04:04 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120613140404.GH5979@phenom.dumpdata.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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, Jun 13, 2012 at 11:20:43AM +0100, David Vrabel wrote:
> This series removes the x86-specific implementation of
> ptep_get_and_clear() and pmdp_get_and_clear().
> 
> The principal reason for this is it allows Xen paravitualized guests
> to batch the PTE clears which is a significant performance
> optimization of munmap() and mremap() -- the number of entries into
> the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
> guests) for munmap().
> 
> There may be minimal gains on native and KVM guests due to the removal
> of the locked xchg.

What about lguest?
> 
> Removal of arch-specific functions where generic ones are suitable
> seems to be a generally useful thing to me.
> 
> The full reasoning for why this is safe is included in the commit
> message of patch 1 but to summarize.  The atomic get-and-clear does
> not guarantee that the latest dirty/accessed bits are returned as TLB
> as there is a still a window after the get-and-clear and before the
> TLB flush that the bits may be updated on other processors.  So, user
> space applications accessing pages that are being unmapped or remapped
> already have unpredictable behaviour.
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 14:42:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14: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 1SeolQ-0002uq-74; Wed, 13 Jun 2012 14:41:40 +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 1SeolN-0002uf-QL
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 14:41:38 +0000
Received: from [85.158.138.51:54852] by server-10.bemta-3.messagelabs.com id
	D2/48-06494-0A6A8DF4; Wed, 13 Jun 2012 14:41:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339598496!27511490!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9809 invoked from network); 13 Jun 2012 14:41:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 14:41:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo54) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N07effo5DCXeIr
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 16:41:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 729A118637
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 16:41:33 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
Message-Id: <3a8cd926cd23170cd9d2.1339598492@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 16:41:32 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339598410 -7200
# Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
# Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
tools: use --docdir option from configure

Use configure to set the docdir location. Up to now it was a Makefile
variable which had to be specified with each make invocation.
Move the DODCIR define from Config.mk to config/Tools.mk.
Adjust some Makefiles which use DOCDIR to source also config/Tools.mk.

Special care needs to be taken with qemu-xen-traditional. Internally it
uses the variable datadir to set the path to keymaps and ROM files. It
also makes use of tools/Rules.mk, which in turn sources config/Tools.mk.
This overwrites the initial value of datadir and keymaps and ROM files
will be installed into a wrong location. Fix this by specifying datadir
as make option.

datadir itself needs to be present in config/Tools.mk.in, without it
autoconf will print warnings and the newly added variables such as
@docdir@ will not be expanded properly.

This patch does not move SHAREDIR and MANDIR from Config.mk to
config/Tools.mk because qemu-xen-traditional is not prepared for that.
It has ${prefix}/share hardcoded. This has to be adressed in a separate
change.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -45,7 +45,6 @@ include $(XEN_ROOT)/config/$(XEN_OS).mk
 include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
 
 SHAREDIR    ?= $(PREFIX)/share
-DOCDIR      ?= $(SHAREDIR)/doc/xen
 MANDIR      ?= $(SHAREDIR)/man
 BASH_COMPLETION_DIR ?= $(CONFIG_DIR)/bash_completion.d
 
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 config/Tools.mk.in
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -1,6 +1,11 @@
 # Prefix and install folder
 PREFIX              := @prefix@
+prefix              := @prefix@
 LIBLEAFDIR_x86_64   := @LIB_PATH@
+PACKAGE_TARNAME     := @PACKAGE_TARNAME@
+datarootdir         := @datarootdir@
+datadir             := @datadir@
+DOCDIR              := @docdir@
 
 # A debug build of tools?
 debug               := @debug@
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/Makefile
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -2,6 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/..
 include $(XEN_ROOT)/Config.mk
+-include $(XEN_ROOT)/config/Tools.mk
 include $(XEN_ROOT)/docs/Docs.mk
 
 VERSION		= xen-unstable
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/xen-api/Makefile
--- a/docs/xen-api/Makefile
+++ b/docs/xen-api/Makefile
@@ -2,6 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
+-include $(XEN_ROOT)/config/Tools.mk
 include $(XEN_ROOT)/docs/Docs.mk
 
 
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -6,6 +6,7 @@ export XEN_OS=MiniOS
 export stubdom=y
 export debug=y
 include $(XEN_ROOT)/Config.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 #ZLIB_URL?=http://www.zlib.net
 ZLIB_URL=$(XEN_EXTFILES_URL)
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -123,7 +123,8 @@ subdir-all-qemu-xen-traditional-dir: qem
 		$(buildmakevars2shellvars); \
 		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
-		$(MAKE) all
+		$(MAKE) all \
+			datadir="$(SHAREDIR)/xen/qemu"
 
 subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 	set -e; \
@@ -132,11 +133,14 @@ subdir-install-qemu-xen-traditional-dir:
 		$(QEMU_ROOT)/xen-setup \
 		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
 		$(IOEMU_CONFIGURE_CROSS); \
-		$(MAKE) install
+		$(MAKE) install \
+			datadir="$(SHAREDIR)/xen/qemu"
 
 subdir-clean-qemu-xen-traditional-dir:
 	set -e; if test -d qemu-xen-traditional-dir/.; then \
-		$(MAKE) -C qemu-xen-traditional-dir clean; \
+		$(MAKE) -C qemu-xen-traditional-dir clean \
+			datadir="$(SHAREDIR)/xen/qemu" \
+		; \
 	fi
 
 .PHONY: qemu-xen-dir-force-update

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 14:42:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 14: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 1SeolQ-0002uq-74; Wed, 13 Jun 2012 14:41:40 +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 1SeolN-0002uf-QL
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 14:41:38 +0000
Received: from [85.158.138.51:54852] by server-10.bemta-3.messagelabs.com id
	D2/48-06494-0A6A8DF4; Wed, 13 Jun 2012 14:41:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339598496!27511490!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDc4Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9809 invoked from network); 13 Jun 2012 14:41:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 14:41:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (josoe mo54) (RZmta 29.12 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N07effo5DCXeIr
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 16:41:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 729A118637
	for <xen-devel@lists.xensource.com>;
	Wed, 13 Jun 2012 16:41:33 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
Message-Id: <3a8cd926cd23170cd9d2.1339598492@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 13 Jun 2012 16:41:32 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1339598410 -7200
# Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
# Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
tools: use --docdir option from configure

Use configure to set the docdir location. Up to now it was a Makefile
variable which had to be specified with each make invocation.
Move the DODCIR define from Config.mk to config/Tools.mk.
Adjust some Makefiles which use DOCDIR to source also config/Tools.mk.

Special care needs to be taken with qemu-xen-traditional. Internally it
uses the variable datadir to set the path to keymaps and ROM files. It
also makes use of tools/Rules.mk, which in turn sources config/Tools.mk.
This overwrites the initial value of datadir and keymaps and ROM files
will be installed into a wrong location. Fix this by specifying datadir
as make option.

datadir itself needs to be present in config/Tools.mk.in, without it
autoconf will print warnings and the newly added variables such as
@docdir@ will not be expanded properly.

This patch does not move SHAREDIR and MANDIR from Config.mk to
config/Tools.mk because qemu-xen-traditional is not prepared for that.
It has ${prefix}/share hardcoded. This has to be adressed in a separate
change.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -45,7 +45,6 @@ include $(XEN_ROOT)/config/$(XEN_OS).mk
 include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
 
 SHAREDIR    ?= $(PREFIX)/share
-DOCDIR      ?= $(SHAREDIR)/doc/xen
 MANDIR      ?= $(SHAREDIR)/man
 BASH_COMPLETION_DIR ?= $(CONFIG_DIR)/bash_completion.d
 
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 config/Tools.mk.in
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -1,6 +1,11 @@
 # Prefix and install folder
 PREFIX              := @prefix@
+prefix              := @prefix@
 LIBLEAFDIR_x86_64   := @LIB_PATH@
+PACKAGE_TARNAME     := @PACKAGE_TARNAME@
+datarootdir         := @datarootdir@
+datadir             := @datadir@
+DOCDIR              := @docdir@
 
 # A debug build of tools?
 debug               := @debug@
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/Makefile
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -2,6 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/..
 include $(XEN_ROOT)/Config.mk
+-include $(XEN_ROOT)/config/Tools.mk
 include $(XEN_ROOT)/docs/Docs.mk
 
 VERSION		= xen-unstable
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/xen-api/Makefile
--- a/docs/xen-api/Makefile
+++ b/docs/xen-api/Makefile
@@ -2,6 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
+-include $(XEN_ROOT)/config/Tools.mk
 include $(XEN_ROOT)/docs/Docs.mk
 
 
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -6,6 +6,7 @@ export XEN_OS=MiniOS
 export stubdom=y
 export debug=y
 include $(XEN_ROOT)/Config.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 #ZLIB_URL?=http://www.zlib.net
 ZLIB_URL=$(XEN_EXTFILES_URL)
diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -123,7 +123,8 @@ subdir-all-qemu-xen-traditional-dir: qem
 		$(buildmakevars2shellvars); \
 		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
-		$(MAKE) all
+		$(MAKE) all \
+			datadir="$(SHAREDIR)/xen/qemu"
 
 subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 	set -e; \
@@ -132,11 +133,14 @@ subdir-install-qemu-xen-traditional-dir:
 		$(QEMU_ROOT)/xen-setup \
 		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
 		$(IOEMU_CONFIGURE_CROSS); \
-		$(MAKE) install
+		$(MAKE) install \
+			datadir="$(SHAREDIR)/xen/qemu"
 
 subdir-clean-qemu-xen-traditional-dir:
 	set -e; if test -d qemu-xen-traditional-dir/.; then \
-		$(MAKE) -C qemu-xen-traditional-dir clean; \
+		$(MAKE) -C qemu-xen-traditional-dir clean \
+			datadir="$(SHAREDIR)/xen/qemu" \
+		; \
 	fi
 
 .PHONY: qemu-xen-dir-force-update

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 15:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15: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 1Sep3e-0003QG-Tu; Wed, 13 Jun 2012 15:00:30 +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 1Sep3d-0003QB-Fb
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 15:00:29 +0000
Received: from [85.158.139.83:33109] by server-11.bemta-5.messagelabs.com id
	5F/F0-20400-C0BA8DF4; Wed, 13 Jun 2012 15:00:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339599626!27489247!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA4NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2102 invoked from network); 13 Jun 2012 15:00:27 -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;
	13 Jun 2012 15:00:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330923600"; d="scan'208";a="27928637"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:00:25 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012
	11:00:25 -0400
Message-ID: <4FD8AB07.7080004@citrix.com>
Date: Wed, 13 Jun 2012 16:00:23 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
In-Reply-To: <20120613140404.GH5979@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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 13/06/12 15:04, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 13, 2012 at 11:20:43AM +0100, David Vrabel wrote:
>> This series removes the x86-specific implementation of
>> ptep_get_and_clear() and pmdp_get_and_clear().
>>
>> The principal reason for this is it allows Xen paravitualized guests
>> to batch the PTE clears which is a significant performance
>> optimization of munmap() and mremap() -- the number of entries into
>> the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
>> guests) for munmap().
>>
>> There may be minimal gains on native and KVM guests due to the removal
>> of the locked xchg.
> 
> What about lguest?

As I note in the description of patch 1:

"There may be a performance regression with lguest guests as
an optimization for avoiding calling pte_update() when doing a full
teardown of an mm is removed."

I don't know how much this performance regression would be or if the
performance of lguest guests is something people care about.

We could have an x86-specific ptep_get_and_clear_full() which looks like:

pte_t ptep_get_and_clear_full(
	struct mm_struct *mm, unsigned long addr, pte_t *ptep,
	int full)
{
	pte_t pte = *ptep;

	pte_clear(mm, address, ptep);
	if (!full)
		pte_update(mm, addr, ptep);

	return pte;
}

Which would have all the performance benefits of the proposed patch
without the performance regression with lguest.

David

>>
>> Removal of arch-specific functions where generic ones are suitable
>> seems to be a generally useful thing to me.
>>
>> The full reasoning for why this is safe is included in the commit
>> message of patch 1 but to summarize.  The atomic get-and-clear does
>> not guarantee that the latest dirty/accessed bits are returned as TLB
>> as there is a still a window after the get-and-clear and before the
>> TLB flush that the bits may be updated on other processors.  So, user
>> space applications accessing pages that are being unmapped or remapped
>> already have unpredictable behaviour.
>>
>> David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 15:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15: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 1Sep3e-0003QG-Tu; Wed, 13 Jun 2012 15:00:30 +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 1Sep3d-0003QB-Fb
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 15:00:29 +0000
Received: from [85.158.139.83:33109] by server-11.bemta-5.messagelabs.com id
	5F/F0-20400-C0BA8DF4; Wed, 13 Jun 2012 15:00:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339599626!27489247!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTA4NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2102 invoked from network); 13 Jun 2012 15:00:27 -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;
	13 Jun 2012 15:00:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330923600"; d="scan'208";a="27928637"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 11:00:25 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012
	11:00:25 -0400
Message-ID: <4FD8AB07.7080004@citrix.com>
Date: Wed, 13 Jun 2012 16:00:23 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
In-Reply-To: <20120613140404.GH5979@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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 13/06/12 15:04, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 13, 2012 at 11:20:43AM +0100, David Vrabel wrote:
>> This series removes the x86-specific implementation of
>> ptep_get_and_clear() and pmdp_get_and_clear().
>>
>> The principal reason for this is it allows Xen paravitualized guests
>> to batch the PTE clears which is a significant performance
>> optimization of munmap() and mremap() -- the number of entries into
>> the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
>> guests) for munmap().
>>
>> There may be minimal gains on native and KVM guests due to the removal
>> of the locked xchg.
> 
> What about lguest?

As I note in the description of patch 1:

"There may be a performance regression with lguest guests as
an optimization for avoiding calling pte_update() when doing a full
teardown of an mm is removed."

I don't know how much this performance regression would be or if the
performance of lguest guests is something people care about.

We could have an x86-specific ptep_get_and_clear_full() which looks like:

pte_t ptep_get_and_clear_full(
	struct mm_struct *mm, unsigned long addr, pte_t *ptep,
	int full)
{
	pte_t pte = *ptep;

	pte_clear(mm, address, ptep);
	if (!full)
		pte_update(mm, addr, ptep);

	return pte;
}

Which would have all the performance benefits of the proposed patch
without the performance regression with lguest.

David

>>
>> Removal of arch-specific functions where generic ones are suitable
>> seems to be a generally useful thing to me.
>>
>> The full reasoning for why this is safe is included in the commit
>> message of patch 1 but to summarize.  The atomic get-and-clear does
>> not guarantee that the latest dirty/accessed bits are returned as TLB
>> as there is a still a window after the get-and-clear and before the
>> TLB flush that the bits may be updated on other processors.  So, user
>> space applications accessing pages that are being unmapped or remapped
>> already have unpredictable behaviour.
>>
>> David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 15:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15:14: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 1SepGR-0003m2-Cz; Wed, 13 Jun 2012 15:13: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 1SepGP-0003lx-Vy
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 15:13:42 +0000
Received: from [193.109.254.147:22299] by server-3.bemta-14.messagelabs.com id
	10/0D-05653-42EA8DF4; Wed, 13 Jun 2012 15:13:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339600419!2701575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13865 invoked from network); 13 Jun 2012 15:13:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 15:13:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="13000875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 15:13:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 16:13:38 +0100
Message-ID: <1339600416.24104.228.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 13 Jun 2012 16:13:36 +0100
In-Reply-To: <20120607090334.GC70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<20120607090334.GC70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 10:03 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565180), Ian Campbell wrote:
> > +/*
> > + * Lookup the MFN corresponding to a domain's PFN.
> > + *
> > + * There are no processor functions to do a stage 2 only lookup therefore we
> > + * do a a software walk.
> > + */
> > +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> > +{
> > +    struct p2m_domain *p2m = &d->arch.p2m;
> > +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> > +    paddr_t maddr = INVALID_PADDR;
> > +
> > +    spin_lock(&p2m->lock);
> > +
> > +    first = __map_domain_page(p2m->first_level);
> > +    if ( !first[first_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !first[first_table_offset(paddr)].p2m.table )
> > +    {
> > +        pte = first[first_table_offset(paddr)];
> > +        goto done;
> > +    }
> 
> This would be neater as: 
>        pte = first[first_table_offset(paddr)];
>        if ( !pte.p2m.valid || !pte.p2m.table )
>            goto done;
> 
> and test for pte.valid at 'done'.

Yes, that looks nice, although you still need a bit of a quirk for the
third level table bit. Patch below.

> It would be nice to do the three levels in a loop as well, but the weird
> way the table bit behaves in third-level entries might make that more
> confusing than the straight-line version.

This also has the same issue as with *_table_offset as the other similar
functions discussed earlier.

8<-----------------------------------------------------------

>From 347855d863303720cbf5ceb0f1e067660108d3f1 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 13 Apr 2012 16:24:58 +0100
Subject: [PATCH] arm: implement p2m lookup

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c        |   45 +++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h |    3 +++
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6df5b62..145d9fe 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -32,6 +32,51 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+/*
+ * Lookup the MFN corresponding to a domain's PFN.
+ *
+ * There are no processor functions to do a stage 2 only lookup therefore we
+ * do a a software walk.
+ */
+paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
+    paddr_t maddr = INVALID_PADDR;
+
+    spin_lock(&p2m->lock);
+
+    first = __map_domain_page(p2m->first_level);
+
+    pte = first[first_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
+    pte = second[second_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
+    pte = third[third_table_offset(paddr)];
+
+    /* This bit must be one in the level 3 entry */
+    if ( !pte.p2m.table )
+        pte.bits = 0;
+
+done:
+    if ( pte.p2m.valid )
+        maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return maddr;
+}
+
 int guest_physmap_mark_populate_on_demand(struct domain *d,
                                           unsigned long gfn,
                                           unsigned int order)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 349923a..1afd5cb 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
 /* */
 void p2m_load_VTTBR(struct domain *d);
 
+/* */
+paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
+
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
-- 
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 Wed Jun 13 15:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15:14: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 1SepGR-0003m2-Cz; Wed, 13 Jun 2012 15:13: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 1SepGP-0003lx-Vy
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 15:13:42 +0000
Received: from [193.109.254.147:22299] by server-3.bemta-14.messagelabs.com id
	10/0D-05653-42EA8DF4; Wed, 13 Jun 2012 15:13:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339600419!2701575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13865 invoked from network); 13 Jun 2012 15:13:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 15:13:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="13000875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 15:13:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 16:13:38 +0100
Message-ID: <1339600416.24104.228.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 13 Jun 2012 16:13:36 +0100
In-Reply-To: <20120607090334.GC70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<20120607090334.GC70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 10:03 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565180), Ian Campbell wrote:
> > +/*
> > + * Lookup the MFN corresponding to a domain's PFN.
> > + *
> > + * There are no processor functions to do a stage 2 only lookup therefore we
> > + * do a a software walk.
> > + */
> > +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> > +{
> > +    struct p2m_domain *p2m = &d->arch.p2m;
> > +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> > +    paddr_t maddr = INVALID_PADDR;
> > +
> > +    spin_lock(&p2m->lock);
> > +
> > +    first = __map_domain_page(p2m->first_level);
> > +    if ( !first[first_table_offset(paddr)].p2m.valid )
> > +        goto done_err;
> > +    if ( !first[first_table_offset(paddr)].p2m.table )
> > +    {
> > +        pte = first[first_table_offset(paddr)];
> > +        goto done;
> > +    }
> 
> This would be neater as: 
>        pte = first[first_table_offset(paddr)];
>        if ( !pte.p2m.valid || !pte.p2m.table )
>            goto done;
> 
> and test for pte.valid at 'done'.

Yes, that looks nice, although you still need a bit of a quirk for the
third level table bit. Patch below.

> It would be nice to do the three levels in a loop as well, but the weird
> way the table bit behaves in third-level entries might make that more
> confusing than the straight-line version.

This also has the same issue as with *_table_offset as the other similar
functions discussed earlier.

8<-----------------------------------------------------------

>From 347855d863303720cbf5ceb0f1e067660108d3f1 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 13 Apr 2012 16:24:58 +0100
Subject: [PATCH] arm: implement p2m lookup

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c        |   45 +++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h |    3 +++
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6df5b62..145d9fe 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -32,6 +32,51 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+/*
+ * Lookup the MFN corresponding to a domain's PFN.
+ *
+ * There are no processor functions to do a stage 2 only lookup therefore we
+ * do a a software walk.
+ */
+paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
+    paddr_t maddr = INVALID_PADDR;
+
+    spin_lock(&p2m->lock);
+
+    first = __map_domain_page(p2m->first_level);
+
+    pte = first[first_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);
+    pte = second[second_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);
+    pte = third[third_table_offset(paddr)];
+
+    /* This bit must be one in the level 3 entry */
+    if ( !pte.p2m.table )
+        pte.bits = 0;
+
+done:
+    if ( pte.p2m.valid )
+        maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return maddr;
+}
+
 int guest_physmap_mark_populate_on_demand(struct domain *d,
                                           unsigned long gfn,
                                           unsigned int order)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 349923a..1afd5cb 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
 /* */
 void p2m_load_VTTBR(struct domain *d);
 
+/* */
+paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
+
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
-- 
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 Wed Jun 13 15:19:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15:19: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 1SepLX-00040e-PM; Wed, 13 Jun 2012 15:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SepLW-00040S-4D
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 15:18:58 +0000
Received: from [193.109.254.147:30084] by server-7.bemta-14.messagelabs.com id
	B5/36-29165-16FA8DF4; Wed, 13 Jun 2012 15:18:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339600736!9582585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11186 invoked from network); 13 Jun 2012 15:18:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 15:18:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="13001146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 15:18:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 16:18:56 +0100
Message-ID: <1339600735.24104.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Wed, 13 Jun 2012 16:18:55 +0100
In-Reply-To: <1339068947.18523.10.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
	<20120607090808.GD70339@ocelot.phlegethon.org>
	<1339068947.18523.10.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-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 16/38] arm: Add simple cpu_{sibling,
 core}_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

Keir, Jan: Any objection/ack for the generic part of this commit?

> 8<------------------------------------------------------
> 
> From e980ca1ec9bf92b2f1255ac5222b1da1292f9f72 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 14 May 2012 12:25:31 +0100
> Subject: [PATCH] arm: Add simple cpu_{sibling,core}_mask
> 
> This needs to be done for all cpus. The allocations require smp_prepare_cpus
> to be called a bit later on.
> 
> In a previous version of this patch these maps were being zeroed (instead of
> setting the CPU itself in them). This in turn causes cpumask_first to return
> NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
> read off the end of its cnt array. Add a couple of asserts to catch this in
> the future.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/dummy.S   |    2 --
>  xen/arch/arm/setup.c   |    4 ++--
>  xen/arch/arm/smpboot.c |   21 +++++++++++++++++++++
>  xen/common/domctl.c    |    2 ++
>  4 files changed, 25 insertions(+), 4 deletions(-)
[...]
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9f1a9ad..c1acd1d 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
>       */
>      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>      cpu = cpumask_first(&cpu_exclude_map);
> +    ASSERT(cpu < nr_cpus);
>      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>          cpu = cpumask_next(cpu, &cpu_exclude_map);
>      for_each_cpu(i, online)
>      {
> +        ASSERT(i < nr_cpus);
>          if ( cpumask_test_cpu(i, &cpu_exclude_map) )
>              continue;
>          if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 15:19:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15:19: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 1SepLX-00040e-PM; Wed, 13 Jun 2012 15:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SepLW-00040S-4D
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 15:18:58 +0000
Received: from [193.109.254.147:30084] by server-7.bemta-14.messagelabs.com id
	B5/36-29165-16FA8DF4; Wed, 13 Jun 2012 15:18:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339600736!9582585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11186 invoked from network); 13 Jun 2012 15:18:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 15:18:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="13001146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 15:18:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 16:18:56 +0100
Message-ID: <1339600735.24104.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Wed, 13 Jun 2012 16:18:55 +0100
In-Reply-To: <1339068947.18523.10.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-16-git-send-email-ian.campbell@citrix.com>
	<20120607090808.GD70339@ocelot.phlegethon.org>
	<1339068947.18523.10.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-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 16/38] arm: Add simple cpu_{sibling,
 core}_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

Keir, Jan: Any objection/ack for the generic part of this commit?

> 8<------------------------------------------------------
> 
> From e980ca1ec9bf92b2f1255ac5222b1da1292f9f72 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 14 May 2012 12:25:31 +0100
> Subject: [PATCH] arm: Add simple cpu_{sibling,core}_mask
> 
> This needs to be done for all cpus. The allocations require smp_prepare_cpus
> to be called a bit later on.
> 
> In a previous version of this patch these maps were being zeroed (instead of
> setting the CPU itself in them). This in turn causes cpumask_first to return
> NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
> read off the end of its cnt array. Add a couple of asserts to catch this in
> the future.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/dummy.S   |    2 --
>  xen/arch/arm/setup.c   |    4 ++--
>  xen/arch/arm/smpboot.c |   21 +++++++++++++++++++++
>  xen/common/domctl.c    |    2 ++
>  4 files changed, 25 insertions(+), 4 deletions(-)
[...]
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9f1a9ad..c1acd1d 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
>       */
>      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>      cpu = cpumask_first(&cpu_exclude_map);
> +    ASSERT(cpu < nr_cpus);
>      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>          cpu = cpumask_next(cpu, &cpu_exclude_map);
>      for_each_cpu(i, online)
>      {
> +        ASSERT(i < nr_cpus);
>          if ( cpumask_test_cpu(i, &cpu_exclude_map) )
>              continue;
>          if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 15:33:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15: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 1SepZj-0004hZ-0q; Wed, 13 Jun 2012 15:33: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 1SepZh-0004hS-H2
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 15:33:37 +0000
Received: from [193.109.254.147:33195] by server-12.bemta-14.messagelabs.com
	id 9E/A2-12998-0D2B8DF4; Wed, 13 Jun 2012 15:33:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339601615!3919496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25227 invoked from network); 13 Jun 2012 15:33:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 15:33:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,765,1330905600"; d="scan'208";a="13001555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 15:33:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 16:33:05 +0100
Message-ID: <1339601583.24104.237.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Jun 2012 16:33:03 +0100
In-Reply-To: <alpine.DEB.2.02.1206061725020.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-17-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061725020.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/38] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 17:27 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/p2m.c         |   15 ++++++++-------
> >  xen/include/asm-arm/page.h |    6 ++++--
> >  2 files changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 9b40e93..46c6f17 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -148,7 +148,7 @@ static int p2m_create_entry(struct domain *d,
> >      clear_page(p);
> >      unmap_domain_page(p);
> >  
> > -    pte = mfn_to_p2m_entry(page_to_mfn(page));
> > +    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
> >  
> >      write_pte(entry, pte);
> >  
> 
> This works because p2m_create_entry is always called to create first or
> second level entries only.
> Maybe we should rename p2m_create_entry to p2m_create_table_entry for
> clarity? Or add a comment?

I think p2m_create_table would be a fine name for this function. I've
also added a comment.

8<------------------------------

>From 33d7d69b95ed016542631e2daca55d5cd9969627 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 12:30:04 +0100
Subject: [PATCH] arm: allow p2m to be created with specific MATTR.

Rename p2m_create_entry to p2m_create_table since it can now only be used to
insert non-leaf entries into the page table.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c         |   22 ++++++++++++----------
 xen/include/asm-arm/page.h |    6 ++++--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 145d9fe..b411fe7 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
     return -ENOSYS;
 }
 
-static int p2m_create_entry(struct domain *d,
+/* Allocate a new page table page and hook it in via the given entry */
+static int p2m_create_table(struct domain *d,
                             lpae_t *entry)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -140,7 +142,7 @@ static int create_p2m_entries(struct domain *d,
     {
         if ( !first[first_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L1 failed\n");
                 goto out;
@@ -159,7 +161,7 @@ static int create_p2m_entries(struct domain *d,
 
         if ( !second[second_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L2 failed\n");
                 goto out;
@@ -198,11 +200,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 183ba5f..2783c30 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -46,6 +46,8 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -187,7 +189,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -196,7 +198,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Wed Jun 13 15:33:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 15: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 1SepZj-0004hZ-0q; Wed, 13 Jun 2012 15:33: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 1SepZh-0004hS-H2
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 15:33:37 +0000
Received: from [193.109.254.147:33195] by server-12.bemta-14.messagelabs.com
	id 9E/A2-12998-0D2B8DF4; Wed, 13 Jun 2012 15:33:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339601615!3919496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25227 invoked from network); 13 Jun 2012 15:33:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 15:33:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,765,1330905600"; d="scan'208";a="13001555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 15:33:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 16:33:05 +0100
Message-ID: <1339601583.24104.237.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Jun 2012 16:33:03 +0100
In-Reply-To: <alpine.DEB.2.02.1206061725020.6030@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-17-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061725020.6030@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/38] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 17:27 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/p2m.c         |   15 ++++++++-------
> >  xen/include/asm-arm/page.h |    6 ++++--
> >  2 files changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 9b40e93..46c6f17 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -148,7 +148,7 @@ static int p2m_create_entry(struct domain *d,
> >      clear_page(p);
> >      unmap_domain_page(p);
> >  
> > -    pte = mfn_to_p2m_entry(page_to_mfn(page));
> > +    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
> >  
> >      write_pte(entry, pte);
> >  
> 
> This works because p2m_create_entry is always called to create first or
> second level entries only.
> Maybe we should rename p2m_create_entry to p2m_create_table_entry for
> clarity? Or add a comment?

I think p2m_create_table would be a fine name for this function. I've
also added a comment.

8<------------------------------

>From 33d7d69b95ed016542631e2daca55d5cd9969627 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 12:30:04 +0100
Subject: [PATCH] arm: allow p2m to be created with specific MATTR.

Rename p2m_create_entry to p2m_create_table since it can now only be used to
insert non-leaf entries into the page table.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c         |   22 ++++++++++++----------
 xen/include/asm-arm/page.h |    6 ++++--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 145d9fe..b411fe7 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
     return -ENOSYS;
 }
 
-static int p2m_create_entry(struct domain *d,
+/* Allocate a new page table page and hook it in via the given entry */
+static int p2m_create_table(struct domain *d,
                             lpae_t *entry)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -140,7 +142,7 @@ static int create_p2m_entries(struct domain *d,
     {
         if ( !first[first_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L1 failed\n");
                 goto out;
@@ -159,7 +161,7 @@ static int create_p2m_entries(struct domain *d,
 
         if ( !second[second_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L2 failed\n");
                 goto out;
@@ -198,11 +200,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 183ba5f..2783c30 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -46,6 +46,8 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -187,7 +189,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -196,7 +198,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Wed Jun 13 16:11:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 16: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 1Seq9d-0005eu-OU; Wed, 13 Jun 2012 16:10:45 +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 1Seq9c-0005ep-ED
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 16:10:44 +0000
Received: from [85.158.138.51:59054] by server-2.bemta-3.messagelabs.com id
	AD/7C-16299-38BB8DF4; Wed, 13 Jun 2012 16:10:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339603841!27529389!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2814 invoked from network); 13 Jun 2012 16:10:42 -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;
	13 Jun 2012 16:10:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,765,1330923600"; d="scan'208";a="198616871"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:10:41 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012
	12:10:40 -0400
Message-ID: <4FD8BB7F.8020105@citrix.com>
Date: Wed, 13 Jun 2012 17:10:39 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
	<20120610102347.GA14968@andromeda.dapyr.net>
	<4FD5C70F.20707@citrix.com>
	<20120611122950.GA15622@andromeda.dapyr.net>
In-Reply-To: <20120611122950.GA15622@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
 xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 13:29, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 11, 2012 at 11:23:11AM +0100, David Vrabel wrote:
>> On 10/06/12 11:23, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
>>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>>
>>>>> In xen_set_pte() if batching is unavailable (because the caller is in
>>>>> an interrupt context such as handling a page fault) it would fall back
>>>>> to using native_set_pte() and trapping and emulating the PTE write.
>>>>>
>>>>> On 32-bit guests this requires two traps for each PTE write (one for
>>>>> each dword of the PTE).  Instead, do one mmu_update hypercall
>>>>> directly.
>>>>
>>>> OK.
>>>>>
>>>>> This significantly improves page fault performance in 32-bit PV
>>>>> guests.
>>>>
>>>> Nice!
>>>
>>> With this patch I keep on getting this (which is v3.5-rc2 plus my
>>> patches in stable/for-linus-3.5 and yours):
>> [...]
>>> (XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
>>> (XEN) mm.c:3460:d0 Could not get page for normal update
>>
>> Are you talking about these?  I've not seen them.  Do you know when they
>> happen?
> 
> During the bootup. I hadn't really done much investigation - but reverting
> your patch (so v3.5-rc2+stable/for-linus-3.5 minus your patch) makes these
> errors go away.

Trying to update the PTE at:

pte: v: ffffffffff4f8000, p: 7f4f8000, m: fffffffffffff000

It seems we cannot get the MFN for the page containing this PTE.  It
appears not to be in the p2m which is understandable as the PFN here is
outside of available RAM (this PFN is marked as UNUSABLE in the e820 map).

It's really not clear how this has ever worked.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 16:11:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 16: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 1Seq9d-0005eu-OU; Wed, 13 Jun 2012 16:10:45 +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 1Seq9c-0005ep-ED
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 16:10:44 +0000
Received: from [85.158.138.51:59054] by server-2.bemta-3.messagelabs.com id
	AD/7C-16299-38BB8DF4; Wed, 13 Jun 2012 16:10:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339603841!27529389!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTk4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2814 invoked from network); 13 Jun 2012 16:10:42 -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;
	13 Jun 2012 16:10:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,765,1330923600"; d="scan'208";a="198616871"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 12:10:41 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012
	12:10:40 -0400
Message-ID: <4FD8BB7F.8020105@citrix.com>
Date: Wed, 13 Jun 2012 17:10:39 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1338563694-21915-1-git-send-email-david.vrabel@citrix.com>
	<20120605160746.GB24031@phenom.dumpdata.com>
	<20120610102347.GA14968@andromeda.dapyr.net>
	<4FD5C70F.20707@citrix.com>
	<20120611122950.GA15622@andromeda.dapyr.net>
In-Reply-To: <20120611122950.GA15622@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/mm: do direct hypercall in
 xen_set_pte() if batching is unavailable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 13:29, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 11, 2012 at 11:23:11AM +0100, David Vrabel wrote:
>> On 10/06/12 11:23, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Jun 05, 2012 at 12:07:46PM -0400, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Jun 01, 2012 at 04:14:54PM +0100, David Vrabel wrote:
>>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>>
>>>>> In xen_set_pte() if batching is unavailable (because the caller is in
>>>>> an interrupt context such as handling a page fault) it would fall back
>>>>> to using native_set_pte() and trapping and emulating the PTE write.
>>>>>
>>>>> On 32-bit guests this requires two traps for each PTE write (one for
>>>>> each dword of the PTE).  Instead, do one mmu_update hypercall
>>>>> directly.
>>>>
>>>> OK.
>>>>>
>>>>> This significantly improves page fault performance in 32-bit PV
>>>>> guests.
>>>>
>>>> Nice!
>>>
>>> With this patch I keep on getting this (which is v3.5-rc2 plus my
>>> patches in stable/for-linus-3.5 and yours):
>> [...]
>>> (XEN) mm.c:659:d0 Could not get page ref for pfn fffffffffffff
>>> (XEN) mm.c:3460:d0 Could not get page for normal update
>>
>> Are you talking about these?  I've not seen them.  Do you know when they
>> happen?
> 
> During the bootup. I hadn't really done much investigation - but reverting
> your patch (so v3.5-rc2+stable/for-linus-3.5 minus your patch) makes these
> errors go away.

Trying to update the PTE at:

pte: v: ffffffffff4f8000, p: 7f4f8000, m: fffffffffffff000

It seems we cannot get the MFN for the page containing this PTE.  It
appears not to be in the p2m which is understandable as the PFN here is
outside of available RAM (this PFN is marked as UNUSABLE in the e820 map).

It's really not clear how this has ever worked.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 16:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 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 1SeqBT-0005jC-8S; Wed, 13 Jun 2012 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 <konrad.wilk@oracle.com>) id 1SeqBS-0005j5-EI
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 16:12:38 +0000
Received: from [85.158.138.51:10575] by server-6.bemta-3.messagelabs.com id
	10/B1-05063-5FBB8DF4; Wed, 13 Jun 2012 16:12:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339603955!27379075!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4ODAxNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16031 invoked from network); 13 Jun 2012 16:12:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 16:12:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DGCTD0010573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 16:12:30 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
	q5DGCQRR012333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 16:12:26 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
	q5DGCPPa004387; Wed, 13 Jun 2012 11:12:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 09:12:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8BC59402D7; Wed, 13 Jun 2012 12:05:11 -0400 (EDT)
Date: Wed, 13 Jun 2012 12:05:11 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: mlin@ss.pku.edu.cn, marcus.granado@citrix.com,
	xen-devel@lists.xensource.com
Message-ID: <20120613160511.GA30723@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: Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] Prototype perf work.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey Lin,

I trust that your presentation at the LinuxCon Japan went great!
Before the conference I recall we had a discussion on how you
were thinking to continue on doing the perf prototype work.

What day/time would works best to do an IRC meeting?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 16:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 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 1SeqBT-0005jC-8S; Wed, 13 Jun 2012 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 <konrad.wilk@oracle.com>) id 1SeqBS-0005j5-EI
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 16:12:38 +0000
Received: from [85.158.138.51:10575] by server-6.bemta-3.messagelabs.com id
	10/B1-05063-5FBB8DF4; Wed, 13 Jun 2012 16:12:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339603955!27379075!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU4ODAxNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16031 invoked from network); 13 Jun 2012 16:12:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 16:12:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DGCTD0010573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 16:12:30 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
	q5DGCQRR012333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 16:12:26 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
	q5DGCPPa004387; Wed, 13 Jun 2012 11:12:25 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 09:12:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8BC59402D7; Wed, 13 Jun 2012 12:05:11 -0400 (EDT)
Date: Wed, 13 Jun 2012 12:05:11 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: mlin@ss.pku.edu.cn, marcus.granado@citrix.com,
	xen-devel@lists.xensource.com
Message-ID: <20120613160511.GA30723@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: Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] Prototype perf work.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey Lin,

I trust that your presentation at the LinuxCon Japan went great!
Before the conference I recall we had a discussion on how you
were thinking to continue on doing the perf prototype work.

What day/time would works best to do an IRC meeting?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 16:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 16:49: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 1Seqka-00065E-9Y; Wed, 13 Jun 2012 16:48:56 +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 1SeqkY-000659-V7
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 16:48:55 +0000
Received: from [193.109.254.147:18037] by server-2.bemta-14.messagelabs.com id
	E1/C2-27740-674C8DF4; Wed, 13 Jun 2012 16:48:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339606133!7163729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14159 invoked from network); 13 Jun 2012 16:48:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 16:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,765,1330905600"; d="scan'208";a="13003323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 16:48:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 17:48:15 +0100
Message-ID: <1339606093.11149.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 17:48:13 +0100
In-Reply-To: <20438.8212.973369.347692@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<20438.8212.973369.347692@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE
 process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-11 at 17:43 +0100, Ian Jackson wrote:
> Here's another patch which needs to go on top of my async save/restore
> series.
> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE
> 
> * Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
>   handlng.  At every call site, replace it with an open-coded call to

   handling

>   libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.
> 
> * This involves adding an `out:' to libxl_domain_unpause.
> 
> * In libxl_domain_destroy and do_pci_add, do not `default: abort();'
>   if the domain type cannot be found.  Instead switch on
>   LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
>   handling.
> 
> * In libxl__primary_console_find, remove a spurious default clause
>   from the domain type switch.
> 
> * In libxl_domain_suspend (as reorganised) error check, check for
>   LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 16:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 16:49: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 1Seqka-00065E-9Y; Wed, 13 Jun 2012 16:48:56 +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 1SeqkY-000659-V7
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 16:48:55 +0000
Received: from [193.109.254.147:18037] by server-2.bemta-14.messagelabs.com id
	E1/C2-27740-674C8DF4; Wed, 13 Jun 2012 16:48:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339606133!7163729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14159 invoked from network); 13 Jun 2012 16:48:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jun 2012 16:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,765,1330905600"; d="scan'208";a="13003323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jun 2012 16:48:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 13 Jun 2012 17:48:15 +0100
Message-ID: <1339606093.11149.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Jun 2012 17:48:13 +0100
In-Reply-To: <20438.8212.973369.347692@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<20438.8212.973369.347692@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE
 process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-11 at 17:43 +0100, Ian Jackson wrote:
> Here's another patch which needs to go on top of my async save/restore
> series.
> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: further fixups re LIBXL_DOMAIN_TYPE
> 
> * Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
>   handlng.  At every call site, replace it with an open-coded call to

   handling

>   libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.
> 
> * This involves adding an `out:' to libxl_domain_unpause.
> 
> * In libxl_domain_destroy and do_pci_add, do not `default: abort();'
>   if the domain type cannot be found.  Instead switch on
>   LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
>   handling.
> 
> * In libxl__primary_console_find, remove a spurious default clause
>   from the domain type switch.
> 
> * In libxl_domain_suspend (as reorganised) error check, check for
>   LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 17:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 17: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 1Seqyy-0006LP-Rh; Wed, 13 Jun 2012 17:03:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Seqyx-0006LJ-Lh
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 17:03:48 +0000
Received: from [85.158.138.51:16483] by server-10.bemta-3.messagelabs.com id
	6A/95-06494-2F7C8DF4; Wed, 13 Jun 2012 17:03:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339607024!8799576!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21330 invoked from network); 13 Jun 2012 17:03:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 17:03:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DH2ja8024367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 17:02:46 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
	q5DH2hiU013980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 17:02:44 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
	q5DH2gB1005359; Wed, 13 Jun 2012 12:02:43 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 10:02:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2ACC9402D7; Wed, 13 Jun 2012 12:55:30 -0400 (EDT)
Date: Wed, 13 Jun 2012 12:55:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20120613165529.GA10986@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120511194138.GA30099@phenom.dumpdata.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@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <jbeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> > =

> > =A0
> > don't want to be pushy, as I have no real issue. I simply use the Xenif=
ied kernel or take the double load. =

> > =

> > But I think this mistery is still open. My last status was that the lat=
est patch you produced resulted in a BUG, =

> =

> Yes, that is right. Thank you for reminding me.
> > =

> > so we still have not checked whether our theory is correct.
> =

> No we haven't. And I should be have no trouble reproducing this. I can ju=
st write
> a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please
try it out? It has the #define DEBUG 1 set so it should print a lot of
stuff when the DVB module loads. If it crashes please send me the full log.

Thanks.
>From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
 [v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |  187 +++++++++++++++++++++++++++++++++++++++++++++=
++-
 include/xen/xen-ops.h |    2 +
 mm/vmalloc.c          |   18 +++++-
 3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3a73785..960d206 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 =

 #include <trace/events/xen.h>
 =

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */
 #define MAX_CONTIG_ORDER 9 /* 2MB */
 static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 =

 #define VOID_PTE (mfn_pte(0, __pgprot(0)))
 static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
@@ -2075,6 +2077,42 @@ static void xen_zap_pfn_range(unsigned long vaddr, u=
nsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n =3D 0;
+	struct multicall_space mcs;
+	struct page *page;
+
+	xen_mc_batch();
+	for (i =3D 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+#define DEBUG 1
+		if (in_frames) {
+#ifdef DEBUG
+			printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+				__func__, i, page_to_pfn(page),
+				pfn_to_mfn(page_to_pfn(page)), page_address(page));
+#endif
+			in_frames[i] =3D pfn_to_mfn(page_to_pfn(page));
+		}
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_=
PTE, 0);
+		set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] =3D page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+	return n;
+}
 =

 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to
@@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long v=
addr, int order,
 =

 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn, /* in_frame if we failed*/
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit =3D 1ULL << order;
+	for (i =3D 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+		if (mfns)
+			mfn =3D mfns[i];
+		else
+			mfn =3D first_mfn + i;
+
+		if (i < (limit - 1))
+			flags =3D 0;
+		else {
+			if (order =3D=3D 0)
+				flags =3D UVMF_INVLPG | UVMF_ALL;
+			else
+				flags =3D UVMF_TLB_FLUSH | UVMF_ALL;
+		}
+#ifdef DEBUG
+		printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+			__func__, i, page_to_pfn(page), mfn, page_address(page));
+#endif
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 =

 /*
  * Perform the hypercall to exchange a region of our pfns to point to
@@ -2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_=
in, unsigned int order_in,
 {
 	long rc;
 	int success;
-
+#ifdef DEBUG
+	int i;
+#endif
 	struct xen_memory_exchange exchange =3D {
 		.in =3D {
 			.nr_extents   =3D extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents=
_in, unsigned int order_in,
 =

 	rc =3D HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
 	success =3D (exchange.nr_exchanged =3D=3D extents_in);
-
+#ifdef DEBUG
+	for (i =3D 0; i <  exchange.nr_exchanged; i++) {
+		printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n",  __func__,pfns_in[i=
], mfns_out[i]);
+	}
+#endif
 	BUG_ON(!success && ((exchange.nr_exchanged !=3D 0) || (rc =3D=3D 0)));
 	BUG_ON(success && (rc !=3D 0));
 =

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vsta=
rt, unsigned int order)
 	xen_zap_pfn_range(vstart, order, NULL, out_frames);
 =

 	/* 3. Do the exchange for non-contiguous MFNs. */
-	success =3D xen_exchange_memory(1, order, &in_frame, 1UL << order,
-					0, out_frames, 0);
+	success =3D xen_exchange_memory(1, order, &in_frame,
+				      1UL << order, 0, out_frames, 0);
 =

 	/* 4. Map new pages in place of old pages. */
 	if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vst=
art, unsigned int order)
 }
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames =3D discontig_frames, *out_frames =3D limited_fr=
ames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n =3D 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map =3D kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map =3D &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i =3D 0; i < (1ULL << order); i++) {
+		void *vaddr;
+		page =3D &pages[i];
+
+		vaddr =3D page_address(page);
+#ifdef DEBUG
+		printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n", __fun=
c__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr)));
+#endif
+		if (address_bits) {
+			if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map !=3D &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n =3D xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, l=
imit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success =3D xen_exchange_memory(n, 0 /* this is always called per page */=
, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map !=3D &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)
 {
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 =

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 =

 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long=
 end)
@@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size =3D (nr_pages * sizeof(struct page *));
 =

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] =3D page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages =3D i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 =

 	if (map_vm_area(area, prot, &pages))
-- =

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 Jun 13 17:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 17: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 1Seqyy-0006LP-Rh; Wed, 13 Jun 2012 17:03:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Seqyx-0006LJ-Lh
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 17:03:48 +0000
Received: from [85.158.138.51:16483] by server-10.bemta-3.messagelabs.com id
	6A/95-06494-2F7C8DF4; Wed, 13 Jun 2012 17:03:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339607024!8799576!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21330 invoked from network); 13 Jun 2012 17:03:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 17:03:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DH2ja8024367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 17:02:46 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
	q5DH2hiU013980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 17:02:44 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
	q5DH2gB1005359; Wed, 13 Jun 2012 12:02:43 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 10:02:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2ACC9402D7; Wed, 13 Jun 2012 12:55:30 -0400 (EDT)
Date: Wed, 13 Jun 2012 12:55:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20120613165529.GA10986@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120511194138.GA30099@phenom.dumpdata.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@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <jbeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> > =

> > =A0
> > don't want to be pushy, as I have no real issue. I simply use the Xenif=
ied kernel or take the double load. =

> > =

> > But I think this mistery is still open. My last status was that the lat=
est patch you produced resulted in a BUG, =

> =

> Yes, that is right. Thank you for reminding me.
> > =

> > so we still have not checked whether our theory is correct.
> =

> No we haven't. And I should be have no trouble reproducing this. I can ju=
st write
> a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please
try it out? It has the #define DEBUG 1 set so it should print a lot of
stuff when the DVB module loads. If it crashes please send me the full log.

Thanks.
>From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
 [v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |  187 +++++++++++++++++++++++++++++++++++++++++++++=
++-
 include/xen/xen-ops.h |    2 +
 mm/vmalloc.c          |   18 +++++-
 3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3a73785..960d206 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 =

 #include <trace/events/xen.h>
 =

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */
 #define MAX_CONTIG_ORDER 9 /* 2MB */
 static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 =

 #define VOID_PTE (mfn_pte(0, __pgprot(0)))
 static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
@@ -2075,6 +2077,42 @@ static void xen_zap_pfn_range(unsigned long vaddr, u=
nsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n =3D 0;
+	struct multicall_space mcs;
+	struct page *page;
+
+	xen_mc_batch();
+	for (i =3D 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+#define DEBUG 1
+		if (in_frames) {
+#ifdef DEBUG
+			printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+				__func__, i, page_to_pfn(page),
+				pfn_to_mfn(page_to_pfn(page)), page_address(page));
+#endif
+			in_frames[i] =3D pfn_to_mfn(page_to_pfn(page));
+		}
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_=
PTE, 0);
+		set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] =3D page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+	return n;
+}
 =

 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to
@@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long v=
addr, int order,
 =

 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn, /* in_frame if we failed*/
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit =3D 1ULL << order;
+	for (i =3D 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+		if (mfns)
+			mfn =3D mfns[i];
+		else
+			mfn =3D first_mfn + i;
+
+		if (i < (limit - 1))
+			flags =3D 0;
+		else {
+			if (order =3D=3D 0)
+				flags =3D UVMF_INVLPG | UVMF_ALL;
+			else
+				flags =3D UVMF_TLB_FLUSH | UVMF_ALL;
+		}
+#ifdef DEBUG
+		printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+			__func__, i, page_to_pfn(page), mfn, page_address(page));
+#endif
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 =

 /*
  * Perform the hypercall to exchange a region of our pfns to point to
@@ -2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_=
in, unsigned int order_in,
 {
 	long rc;
 	int success;
-
+#ifdef DEBUG
+	int i;
+#endif
 	struct xen_memory_exchange exchange =3D {
 		.in =3D {
 			.nr_extents   =3D extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents=
_in, unsigned int order_in,
 =

 	rc =3D HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
 	success =3D (exchange.nr_exchanged =3D=3D extents_in);
-
+#ifdef DEBUG
+	for (i =3D 0; i <  exchange.nr_exchanged; i++) {
+		printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n",  __func__,pfns_in[i=
], mfns_out[i]);
+	}
+#endif
 	BUG_ON(!success && ((exchange.nr_exchanged !=3D 0) || (rc =3D=3D 0)));
 	BUG_ON(success && (rc !=3D 0));
 =

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vsta=
rt, unsigned int order)
 	xen_zap_pfn_range(vstart, order, NULL, out_frames);
 =

 	/* 3. Do the exchange for non-contiguous MFNs. */
-	success =3D xen_exchange_memory(1, order, &in_frame, 1UL << order,
-					0, out_frames, 0);
+	success =3D xen_exchange_memory(1, order, &in_frame,
+				      1UL << order, 0, out_frames, 0);
 =

 	/* 4. Map new pages in place of old pages. */
 	if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vst=
art, unsigned int order)
 }
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames =3D discontig_frames, *out_frames =3D limited_fr=
ames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n =3D 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map =3D kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map =3D &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i =3D 0; i < (1ULL << order); i++) {
+		void *vaddr;
+		page =3D &pages[i];
+
+		vaddr =3D page_address(page);
+#ifdef DEBUG
+		printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n", __fun=
c__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr)));
+#endif
+		if (address_bits) {
+			if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map !=3D &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n =3D xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, l=
imit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success =3D xen_exchange_memory(n, 0 /* this is always called per page */=
, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map !=3D &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)
 {
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 =

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 =

 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long=
 end)
@@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size =3D (nr_pages * sizeof(struct page *));
 =

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] =3D page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages =3D i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 =

 	if (map_vm_area(area, prot, &pages))
-- =

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 Jun 13 17:28:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 17:28: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 1SerLr-0006XQ-0W; Wed, 13 Jun 2012 17:27:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SerLp-0006XL-8v
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 17:27:25 +0000
Received: from [85.158.139.83:31520] by server-9.bemta-5.messagelabs.com id
	33/D4-01069-C7DC8DF4; Wed, 13 Jun 2012 17:27:24 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339608442!23574660!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7235 invoked from network); 13 Jun 2012 17:27:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 17:27:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DHRIeK017282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 17:27:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5DHRHn5005066
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 17:27:18 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
	q5DHRHX9026595; Wed, 13 Jun 2012 12:27:17 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 10:27:17 -0700
MIME-Version: 1.0
X-Mercurial-Node: 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
Message-Id: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Wed, 13 Jun 2012 13:29:15 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1339608534 14400
# Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools/hotplug: fix locking

The current locking implementation would allow two processes get the lock
simultaneously:

++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 5 -gt 5 ']'
+ sleep 0
+ retries=6
+ '[' 6 -lt 100 ']'
+ mkdir /var/run/xen-hotplug/block
++ _lock_owner /var/run/xen-hotplug/block
++ cat /var/run/xen-hotplug/block/owner
+ local 'new_owner=16741: /etc/xen/scripts/block'
+ '[' '16741: /etc/xen/scripts/block' '!=' '16741: /etc/xen/scripts/block' ']'
++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 6 -gt 5 ']'
+ sleep 1
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ xenstore_write backend/vbd/33/51920/node /dev/loop27
+ _xenstore_write backend/vbd/33/51920/node /dev/loop27
+ log debug 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
ioctl: LOOP_SET_FD: Device or resource busy
+ xenstore-write backend/vbd/33/51920/node /dev/loop27
+ fatal losetup -r /dev/loop27 '/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img failed'

This patch is ported from Red Hat Enterprise Linux 5.8.

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Kouya Shimura <kouya@jp.fujitsu.com>

diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
@@ -1,5 +1,6 @@
 #
 # Copyright (c) 2005 XenSource Ltd.
+# Copyright (c) 2007 Red Hat
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of version 2.1 of the GNU Lesser General Public
@@ -19,92 +20,30 @@
 # Serialisation
 #
 
-LOCK_SLEEPTIME=1
-LOCK_SPINNING_RETRIES=5
-LOCK_RETRIES=100
 LOCK_BASEDIR=/var/run/xen-hotplug
 
+_setlockfd()
+{
+    local i
+    for ((i = 0; i < ${#_lockdict}; i++))
+    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
+    done
+    _lockdict[$i]="$1"
+    let _lockfd=200+i
+}
+
 
 claim_lock()
 {
-  local lockdir="$LOCK_BASEDIR/$1"
-  mkdir -p "$LOCK_BASEDIR"
-  _claim_lock "$lockdir"
+    mkdir -p "$LOCK_BASEDIR"
+    _setlockfd $1
+    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
+    flock -x $_lockfd
 }
 
 
 release_lock()
 {
-  _release_lock "$LOCK_BASEDIR/$1"
+    _setlockfd $1
+    flock -u $_lockfd
 }
-
-
-# This function will be redefined in xen-hotplug-common.sh.
-sigerr() {
-  exit 1
-}
-
-
-_claim_lock()
-{
-  local lockdir="$1"
-  local owner=$(_lock_owner "$lockdir")
-  local retries=0
-
-  while [ $retries -lt $LOCK_RETRIES ]
-  do
-    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
-      _update_lock_info "$lockdir" && return
-
-    local new_owner=$(_lock_owner "$lockdir")
-    if [ "$new_owner" != "$owner" ]
-    then
-      owner="$new_owner"
-      retries=0
-    else
-      local pid=$(echo $owner | cut -d : -f 1)
-      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
-      then
-        _release_lock $lockdir
-      fi
-    fi
-
-    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
-    then
-      sleep $LOCK_SLEEPTIME
-    else
-      sleep 0
-    fi
-    retries=$(($retries + 1))
-  done
-  _steal_lock "$lockdir"
-}
-
-
-_release_lock()
-{
-  trap sigerr ERR
-  rm -rf "$1" 2>/dev/null || true
-}
-
-
-_steal_lock()
-{
-  local lockdir="$1"
-  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
-  log err "Forced to steal lock on $lockdir from $owner!"
-  _release_lock "$lockdir"
-  _claim_lock "$lockdir"
-}
-
-
-_lock_owner()
-{
-  cat "$1/owner" 2>/dev/null || echo "unknown"
-}
-
-
-_update_lock_info()
-{
-  echo "$$: $0" >"$1/owner"
-}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 17:28:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 17:28: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 1SerLr-0006XQ-0W; Wed, 13 Jun 2012 17:27:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1SerLp-0006XL-8v
	for xen-devel@lists.xen.org; Wed, 13 Jun 2012 17:27:25 +0000
Received: from [85.158.139.83:31520] by server-9.bemta-5.messagelabs.com id
	33/D4-01069-C7DC8DF4; Wed, 13 Jun 2012 17:27:24 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339608442!23574660!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7235 invoked from network); 13 Jun 2012 17:27:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 17:27:23 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DHRIeK017282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 17:27:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5DHRHn5005066
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 17:27:18 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
	q5DHRHX9026595; Wed, 13 Jun 2012 12:27:17 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 10:27:17 -0700
MIME-Version: 1.0
X-Mercurial-Node: 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
Message-Id: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Wed, 13 Jun 2012 13:29:15 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1339608534 14400
# Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
# Parent  32034d1914a607d7b6f1f060352b4cac973600f8
tools/hotplug: fix locking

The current locking implementation would allow two processes get the lock
simultaneously:

++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 5 -gt 5 ']'
+ sleep 0
+ retries=6
+ '[' 6 -lt 100 ']'
+ mkdir /var/run/xen-hotplug/block
++ _lock_owner /var/run/xen-hotplug/block
++ cat /var/run/xen-hotplug/block/owner
+ local 'new_owner=16741: /etc/xen/scripts/block'
+ '[' '16741: /etc/xen/scripts/block' '!=' '16741: /etc/xen/scripts/block' ']'
++ echo 16741: /etc/xen/scripts/block
++ cut -d : -f 1
+ local pid=16741
+ '[' -n 16741 -a 16741 '!=' unknown -a '!' -f /proc/16741/status ']'
+ '[' 6 -gt 5 ']'
+ sleep 1
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb00001200002b0ef651033c8381.img
+ do_or_die losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ losetup -r /dev/loop27 /OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img
+ xenstore_write backend/vbd/33/51920/node /dev/loop27
+ _xenstore_write backend/vbd/33/51920/node /dev/loop27
+ log debug 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/33/51920/node' '/dev/loop27 to xenstore.'
ioctl: LOOP_SET_FD: Device or resource busy
+ xenstore-write backend/vbd/33/51920/node /dev/loop27
+ fatal losetup -r /dev/loop27 '/OVS/Repositories/0004fb00000300000aac184a9bbab7a9/VirtualDisks/0004fb0000120000143173990458f2a7.img failed'

This patch is ported from Red Hat Enterprise Linux 5.8.

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: Kouya Shimura <kouya@jp.fujitsu.com>

diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
@@ -1,5 +1,6 @@
 #
 # Copyright (c) 2005 XenSource Ltd.
+# Copyright (c) 2007 Red Hat
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of version 2.1 of the GNU Lesser General Public
@@ -19,92 +20,30 @@
 # Serialisation
 #
 
-LOCK_SLEEPTIME=1
-LOCK_SPINNING_RETRIES=5
-LOCK_RETRIES=100
 LOCK_BASEDIR=/var/run/xen-hotplug
 
+_setlockfd()
+{
+    local i
+    for ((i = 0; i < ${#_lockdict}; i++))
+    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
+    done
+    _lockdict[$i]="$1"
+    let _lockfd=200+i
+}
+
 
 claim_lock()
 {
-  local lockdir="$LOCK_BASEDIR/$1"
-  mkdir -p "$LOCK_BASEDIR"
-  _claim_lock "$lockdir"
+    mkdir -p "$LOCK_BASEDIR"
+    _setlockfd $1
+    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
+    flock -x $_lockfd
 }
 
 
 release_lock()
 {
-  _release_lock "$LOCK_BASEDIR/$1"
+    _setlockfd $1
+    flock -u $_lockfd
 }
-
-
-# This function will be redefined in xen-hotplug-common.sh.
-sigerr() {
-  exit 1
-}
-
-
-_claim_lock()
-{
-  local lockdir="$1"
-  local owner=$(_lock_owner "$lockdir")
-  local retries=0
-
-  while [ $retries -lt $LOCK_RETRIES ]
-  do
-    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
-      _update_lock_info "$lockdir" && return
-
-    local new_owner=$(_lock_owner "$lockdir")
-    if [ "$new_owner" != "$owner" ]
-    then
-      owner="$new_owner"
-      retries=0
-    else
-      local pid=$(echo $owner | cut -d : -f 1)
-      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
-      then
-        _release_lock $lockdir
-      fi
-    fi
-
-    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
-    then
-      sleep $LOCK_SLEEPTIME
-    else
-      sleep 0
-    fi
-    retries=$(($retries + 1))
-  done
-  _steal_lock "$lockdir"
-}
-
-
-_release_lock()
-{
-  trap sigerr ERR
-  rm -rf "$1" 2>/dev/null || true
-}
-
-
-_steal_lock()
-{
-  local lockdir="$1"
-  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
-  log err "Forced to steal lock on $lockdir from $owner!"
-  _release_lock "$lockdir"
-  _claim_lock "$lockdir"
-}
-
-
-_lock_owner()
-{
-  cat "$1/owner" 2>/dev/null || echo "unknown"
-}
-
-
-_update_lock_info()
-{
-  echo "$$: $0" >"$1/owner"
-}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 18:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 18:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SesMe-000754-7w; Wed, 13 Jun 2012 18:32: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 1SesMc-00074z-Uv
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 18:32:19 +0000
Received: from [193.109.254.147:60027] by server-7.bemta-14.messagelabs.com id
	CB/B0-29165-2BCD8DF4; Wed, 13 Jun 2012 18:32:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339612335!7175146!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30553 invoked from network); 13 Jun 2012 18:32:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 18:32:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DIWCck016936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 18:32:13 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
	q5DIWB49009185
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 18:32:12 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
	q5DIWBMD003738; Wed, 13 Jun 2012 13:32:11 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 11:32:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1BD79402D7; Wed, 13 Jun 2012 14:24:59 -0400 (EDT)
Date: Wed, 13 Jun 2012 14:24:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120613182458.GA5813@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120612124015.GB559@phenom.dumpdata.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, linux-kernel@vger.kernel.org
Subject: [Xen-devel] xen/mce - mcelog at 100% 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

On Tue, Jun 12, 2012 at 08:40:15AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 12, 2012 at 07:51:03AM +0000, Liu, Jinsong wrote:
> > >From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00 2001
> > From: Liu, Jinsong <jinsong.liu@intel.com>
> > Date: Tue, 12 Jun 2012 23:11:16 +0800
> > Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic context
> > 
> > copy_to_user might sleep and print a stack trace if it is executed
> > in an atomic spinlock context.
> > 
> > This patch schedule a workqueue for IRQ handler to poll the data,
> > and use mutex instead of spinlock, so copy_to_user sleep in atomic
> > context would not occur.
> 
> Ah much better. Usually one also includes the report of what the
> stack trace was. So I've added that in.

So another bug which is that mcelog is spinning at 100% CPU (and only
under Xen).

It seems to be doing:

ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8) = 1 ([{fd=3, revents=POLLIN}])
read(3, "", 2816)                       = 0
ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8) = 1 ([{fd=3, revents=POLLIN}])
read(3, "", 2816) 

constantly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 18:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 18:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SesMe-000754-7w; Wed, 13 Jun 2012 18:32: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 1SesMc-00074z-Uv
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 18:32:19 +0000
Received: from [193.109.254.147:60027] by server-7.bemta-14.messagelabs.com id
	CB/B0-29165-2BCD8DF4; Wed, 13 Jun 2012 18:32:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339612335!7175146!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30553 invoked from network); 13 Jun 2012 18:32:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 18:32:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DIWCck016936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 18:32:13 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
	q5DIWB49009185
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 18:32:12 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
	q5DIWBMD003738; Wed, 13 Jun 2012 13:32:11 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 11:32:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1BD79402D7; Wed, 13 Jun 2012 14:24:59 -0400 (EDT)
Date: Wed, 13 Jun 2012 14:24:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120613182458.GA5813@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120612124015.GB559@phenom.dumpdata.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, linux-kernel@vger.kernel.org
Subject: [Xen-devel] xen/mce - mcelog at 100% 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

On Tue, Jun 12, 2012 at 08:40:15AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 12, 2012 at 07:51:03AM +0000, Liu, Jinsong wrote:
> > >From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00 2001
> > From: Liu, Jinsong <jinsong.liu@intel.com>
> > Date: Tue, 12 Jun 2012 23:11:16 +0800
> > Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in atomic context
> > 
> > copy_to_user might sleep and print a stack trace if it is executed
> > in an atomic spinlock context.
> > 
> > This patch schedule a workqueue for IRQ handler to poll the data,
> > and use mutex instead of spinlock, so copy_to_user sleep in atomic
> > context would not occur.
> 
> Ah much better. Usually one also includes the report of what the
> stack trace was. So I've added that in.

So another bug which is that mcelog is spinning at 100% CPU (and only
under Xen).

It seems to be doing:

ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8) = 1 ([{fd=3, revents=POLLIN}])
read(3, "", 2816)                       = 0
ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8) = 1 ([{fd=3, revents=POLLIN}])
read(3, "", 2816) 

constantly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 19:20:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 19: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 1Set69-0007Va-8a; Wed, 13 Jun 2012 19:19:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <axboe@kernel.dk>) id 1Set68-0007VV-1w
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 19:19:20 +0000
Received: from [85.158.143.35:59909] by server-3.bemta-4.messagelabs.com id
	52/FD-05808-7B7E8DF4; Wed, 13 Jun 2012 19:19:19 +0000
X-Env-Sender: axboe@kernel.dk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339615158!12981014!1
X-Originating-IP: [85.118.1.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15739 invoked from network); 13 Jun 2012 19:19:18 -0000
Received: from unknown (HELO casper.infradead.org) (85.118.1.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 19:19:18 -0000
Received: from brick.kernel.dk ([87.104.106.3] helo=kernel.dk)
	by casper.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1Set62-0003Q6-Oe; Wed, 13 Jun 2012 19:19:14 +0000
Received: by kernel.dk (Postfix, from userid 1000)
	id 0FFDC484001; Wed, 13 Jun 2012 21:19:13 +0200 (CEST)
Date: Wed, 13 Jun 2012 21:19:13 +0200
From: Jens Axboe <jaxboe@fusionio.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120613191913.GD8230@kernel.dk>
References: <20120612123524.GA559@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120612123524.GA559@phenom.dumpdata.com>
Cc: jbeulich@suse.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, stefano.stabellini@eu.citrix.com,
	wdauchy@gmail.com
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.5 for 3.5-rc2..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 12 2012, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> Please pull:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.5
> 
> it has two critical fixes to deal with 32/64 guest/host combinations
> when sending DISCARD commands. They weren't properly sent resulting
> in the guest crashing (https://bugzilla.redhat.com/show_bug.cgi?id=824641)
> The fix is in the backend (blkback) and the frontend has some extra
> WARN_ON added to diagnose similar issues like this in the future.
> 
> Or if you prefer - I can stick those two patches in my tree and
> send them to Linus in my git pull this Friday with your Ack-ed by tag.

Thanks Konrad, pulled.

-- 
Jens Axboe


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 19:20:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 19: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 1Set69-0007Va-8a; Wed, 13 Jun 2012 19:19:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <axboe@kernel.dk>) id 1Set68-0007VV-1w
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 19:19:20 +0000
Received: from [85.158.143.35:59909] by server-3.bemta-4.messagelabs.com id
	52/FD-05808-7B7E8DF4; Wed, 13 Jun 2012 19:19:19 +0000
X-Env-Sender: axboe@kernel.dk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339615158!12981014!1
X-Originating-IP: [85.118.1.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15739 invoked from network); 13 Jun 2012 19:19:18 -0000
Received: from unknown (HELO casper.infradead.org) (85.118.1.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jun 2012 19:19:18 -0000
Received: from brick.kernel.dk ([87.104.106.3] helo=kernel.dk)
	by casper.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1Set62-0003Q6-Oe; Wed, 13 Jun 2012 19:19:14 +0000
Received: by kernel.dk (Postfix, from userid 1000)
	id 0FFDC484001; Wed, 13 Jun 2012 21:19:13 +0200 (CEST)
Date: Wed, 13 Jun 2012 21:19:13 +0200
From: Jens Axboe <jaxboe@fusionio.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120613191913.GD8230@kernel.dk>
References: <20120612123524.GA559@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120612123524.GA559@phenom.dumpdata.com>
Cc: jbeulich@suse.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, stefano.stabellini@eu.citrix.com,
	wdauchy@gmail.com
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.5 for 3.5-rc2..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 12 2012, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> Please pull:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.5
> 
> it has two critical fixes to deal with 32/64 guest/host combinations
> when sending DISCARD commands. They weren't properly sent resulting
> in the guest crashing (https://bugzilla.redhat.com/show_bug.cgi?id=824641)
> The fix is in the backend (blkback) and the frontend has some extra
> WARN_ON added to diagnose similar issues like this in the future.
> 
> Or if you prefer - I can stick those two patches in my tree and
> send them to Linus in my git pull this Friday with your Ack-ed by tag.

Thanks Konrad, pulled.

-- 
Jens Axboe


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 13 19:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 19: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 1SetWk-0008DO-LS; Wed, 13 Jun 2012 19:46: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 1SetWj-0008DJ-6b
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 19:46:49 +0000
Received: from [85.158.138.51:24882] by server-1.bemta-3.messagelabs.com id
	FE/AE-01327-82EE8DF4; Wed, 13 Jun 2012 19:46:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339616806!27404687!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 13 Jun 2012 19:46:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 19:46:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DJkejD029315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 19:46: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
	q5DJke1u020082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 19:46:40 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
	q5DJkdBV025197; Wed, 13 Jun 2012 14:46:39 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 12:46:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 028FD402D7; Wed, 13 Jun 2012 15:39:26 -0400 (EDT)
Date: Wed, 13 Jun 2012 15:39:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120613193926.GA21706@phenom.dumpdata.com>
References: <1337795840-10061-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1337795840-10061-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2] xen: mark local pages as FOREIGN in the
	m2p_override
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, May 23, 2012 at 06:57:20PM +0100, Stefano Stabellini wrote:
> When the frontend and the backend reside on the same domain, even if we
> add pages to the m2p_override, these pages will never be returned by
> mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
> always fail, so the pfn of the frontend will be returned instead
> (resulting in a deadlock because the frontend pages are already locked).

If I recall you were suppose to attach the stack trace here
and also explain a bit about how the lock happens (like a call-tree).

> 
> However m2p_add_override can easily find out whether another pfn
> corresponding to the mfn exists in the m2p, and can set the FOREIGN bit
> in the p2m, making sure that mfn_to_pfn returns the pfn of the backend.
> 
> This allows the backend to perform direct_IO on these pages, but as a
> side effect prevents the frontend from using get_user_pages_fast on
> them while they are being shared with the backend.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/x86/xen/p2m.c |   36 ++++++++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 1b267e7..00a0385 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -686,6 +686,7 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>  	unsigned long uninitialized_var(address);
>  	unsigned level;
>  	pte_t *ptep = NULL;
> +	int ret = 0;
>  
>  	pfn = page_to_pfn(page);
>  	if (!PageHighMem(page)) {
> @@ -721,6 +722,24 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>  	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
>  	spin_unlock_irqrestore(&m2p_override_lock, flags);
>  
> +	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
> +	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
> +	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
> +	 * pfn from the m2p_override (the backend pfn) instead.
> +	 * We need to do this because the pages shared by the frontend
> +	 * (xen-blkfront) can be already locked (lock_page, called by
> +	 * do_read_cache_page); when the userspace backend tries to use them
> +	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
> +	 * do_blockdev_direct_IO is going to try to lock the same pages
> +	 * again resulting in a deadlock.
> +	 * As a side effect get_user_pages_fast might not be safe on the
> +	 * frontend pages while they are being shared with the backend,
> +	 * because mfn_to_pfn (that ends up being called by GUPF) will
> +	 * return the backend pfn rather than the frontend pfn. */
> +	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
> +	if (ret == 0 && get_phys_to_machine(pfn) == mfn)
> +		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(m2p_add_override);
> @@ -732,6 +751,7 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>  	unsigned long uninitialized_var(address);
>  	unsigned level;
>  	pte_t *ptep = NULL;
> +	int ret = 0;
>  
>  	pfn = page_to_pfn(page);
>  	mfn = get_phys_to_machine(pfn);
> @@ -801,6 +821,22 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>  	} else
>  		set_phys_to_machine(pfn, page->index);
>  
> +	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
> +	 * somewhere in this domain, even before being added to the
> +	 * m2p_override (see comment above in m2p_add_override).
> +	 * If there are no other entries in the m2p_override corresponding
> +	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
> +	 * the original pfn (the one shared by the frontend): the backend
> +	 * cannot do any IO on this page anymore because it has been
> +	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
> +	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
> +	 * pfn again. */
> +	mfn &= ~FOREIGN_FRAME_BIT;
> +	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
> +	if (ret == 0 && get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
> +			m2p_find_override(mfn) == NULL)
> +		set_phys_to_machine(pfn, mfn);
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(m2p_remove_override);
> -- 
> 1.7.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 Jun 13 19:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Jun 2012 19: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 1SetWk-0008DO-LS; Wed, 13 Jun 2012 19:46: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 1SetWj-0008DJ-6b
	for xen-devel@lists.xensource.com; Wed, 13 Jun 2012 19:46:49 +0000
Received: from [85.158.138.51:24882] by server-1.bemta-3.messagelabs.com id
	FE/AE-01327-82EE8DF4; Wed, 13 Jun 2012 19:46:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339616806!27404687!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg1ODMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 13 Jun 2012 19:46:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jun 2012 19:46:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5DJkejD029315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Jun 2012 19:46: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
	q5DJke1u020082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Jun 2012 19:46:40 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
	q5DJkdBV025197; Wed, 13 Jun 2012 14:46:39 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Jun 2012 12:46:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 028FD402D7; Wed, 13 Jun 2012 15:39:26 -0400 (EDT)
Date: Wed, 13 Jun 2012 15:39:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120613193926.GA21706@phenom.dumpdata.com>
References: <1337795840-10061-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1337795840-10061-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2] xen: mark local pages as FOREIGN in the
	m2p_override
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, May 23, 2012 at 06:57:20PM +0100, Stefano Stabellini wrote:
> When the frontend and the backend reside on the same domain, even if we
> add pages to the m2p_override, these pages will never be returned by
> mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
> always fail, so the pfn of the frontend will be returned instead
> (resulting in a deadlock because the frontend pages are already locked).

If I recall you were suppose to attach the stack trace here
and also explain a bit about how the lock happens (like a call-tree).

> 
> However m2p_add_override can easily find out whether another pfn
> corresponding to the mfn exists in the m2p, and can set the FOREIGN bit
> in the p2m, making sure that mfn_to_pfn returns the pfn of the backend.
> 
> This allows the backend to perform direct_IO on these pages, but as a
> side effect prevents the frontend from using get_user_pages_fast on
> them while they are being shared with the backend.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/x86/xen/p2m.c |   36 ++++++++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 1b267e7..00a0385 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -686,6 +686,7 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>  	unsigned long uninitialized_var(address);
>  	unsigned level;
>  	pte_t *ptep = NULL;
> +	int ret = 0;
>  
>  	pfn = page_to_pfn(page);
>  	if (!PageHighMem(page)) {
> @@ -721,6 +722,24 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>  	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
>  	spin_unlock_irqrestore(&m2p_override_lock, flags);
>  
> +	/* p2m(m2p(mfn)) == mfn: the mfn is already present somewhere in
> +	 * this domain. Set the FOREIGN_FRAME_BIT in the p2m for the other
> +	 * pfn so that the following mfn_to_pfn(mfn) calls will return the
> +	 * pfn from the m2p_override (the backend pfn) instead.
> +	 * We need to do this because the pages shared by the frontend
> +	 * (xen-blkfront) can be already locked (lock_page, called by
> +	 * do_read_cache_page); when the userspace backend tries to use them
> +	 * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
> +	 * do_blockdev_direct_IO is going to try to lock the same pages
> +	 * again resulting in a deadlock.
> +	 * As a side effect get_user_pages_fast might not be safe on the
> +	 * frontend pages while they are being shared with the backend,
> +	 * because mfn_to_pfn (that ends up being called by GUPF) will
> +	 * return the backend pfn rather than the frontend pfn. */
> +	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
> +	if (ret == 0 && get_phys_to_machine(pfn) == mfn)
> +		set_phys_to_machine(pfn, FOREIGN_FRAME(mfn));
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(m2p_add_override);
> @@ -732,6 +751,7 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>  	unsigned long uninitialized_var(address);
>  	unsigned level;
>  	pte_t *ptep = NULL;
> +	int ret = 0;
>  
>  	pfn = page_to_pfn(page);
>  	mfn = get_phys_to_machine(pfn);
> @@ -801,6 +821,22 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>  	} else
>  		set_phys_to_machine(pfn, page->index);
>  
> +	/* p2m(m2p(mfn)) == FOREIGN_FRAME(mfn): the mfn is already present
> +	 * somewhere in this domain, even before being added to the
> +	 * m2p_override (see comment above in m2p_add_override).
> +	 * If there are no other entries in the m2p_override corresponding
> +	 * to this mfn, then remove the FOREIGN_FRAME_BIT from the p2m for
> +	 * the original pfn (the one shared by the frontend): the backend
> +	 * cannot do any IO on this page anymore because it has been
> +	 * unshared. Removing the FOREIGN_FRAME_BIT from the p2m entry of
> +	 * the original pfn causes mfn_to_pfn(mfn) to return the frontend
> +	 * pfn again. */
> +	mfn &= ~FOREIGN_FRAME_BIT;
> +	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
> +	if (ret == 0 && get_phys_to_machine(pfn) == FOREIGN_FRAME(mfn) &&
> +			m2p_find_override(mfn) == NULL)
> +		set_phys_to_machine(pfn, mfn);
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(m2p_remove_override);
> -- 
> 1.7.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 Jun 14 00:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 00:20: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 1SexmF-0004yD-6c; Thu, 14 Jun 2012 00:19:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SexmD-0004y6-Hk
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 00:19:05 +0000
Received: from [85.158.143.99:61169] by server-3.bemta-4.messagelabs.com id
	6A/3D-05808-8FD29DF4; Thu, 14 Jun 2012 00:19:04 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339633142!32410553!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE4Nzc1OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4567 invoked from network); 14 Jun 2012 00:19:04 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 00:19:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1339633144; x=1371169144;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=lsrKEzSnYHIrNG/0QxOd+e6hZMDYuUHkUBjQadZ7Zlo=;
	b=E7kK9LkxBEzeXVFXTKUtTpb//KkMHwiXynRtpUleZk42T5hx7c0d1Tx1
	w0Vb/Sq66FWjWcFmoS9qRINgT+D6yw==;
X-IronPort-AV: E=Sophos;i="4.77,407,1336348800"; d="scan'208";a="750577256"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jun 2012 00:19:01 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-14-48.sea19.amazon.com [10.50.14.48])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5E0IwFX014184; Thu, 14 Jun 2012 00:18:58 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 13 Jun 2012 17:18:55 -0700
Date: Wed, 13 Jun 2012 17:18:55 -0700
From: Matt Wilson <msw@amazon.com>
To: Jason Stubbs <jasonbstubbs@gmail.com>
Message-ID: <20120614001855.GA2136@US-SEA-R8XVZTX>
References: <4FD1918A.2060908@gmail.com> <20120612035737.GL22848@dastard>
	<4FD731F9.8070509@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD731F9.8070509@gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Dave Chinner <david@fromorbit.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] PROBLEM: Possible race between xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 12, 2012 at 05:11:37AM -0700, Jason Stubbs wrote:
> On 2012-6-12 13:57 , Dave Chinner wrote:
> > Nothing
> > wrong with MD, LVM, or XFS. The problem is either that EBS never
> > completed the IO, or Xen swallowed it and it never made to it to the
> > guest OS. Either way, it does not appear to be a problem in the
> > higher levels of the linux storage stack.
> 
> Thanks Dave for looking into this.
> 
> I'll be sure to give Amazon ample opportunity to diagnose things from
> there side should the issue occur again and hopefully there won't be
> any more people reporting extraneous issues.

Hi Jason,

If you're able to reproduce this hang, I'm sure that we can get to the
root of the problem quite quickly. Short of that, if you can provide a
running instance that is exhibiting the problem we can do some
live-system debugging. It is much more difficult to determine root
cause and verify fixes without reproduction instructions.

Given the kernel version you reported in your traces, I can at least
rule out one known bug that caused blkfront to wait forever for an IO
to complete: 
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=dffe2e1

The kernel version you're using using includes the follow-on change to
use fasteoi:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=3588fe2

I'm sorry that I can't be more of more immediate help. If you
encounter the problem again, please contact developer support.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 00:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 00:20: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 1SexmF-0004yD-6c; Thu, 14 Jun 2012 00:19:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SexmD-0004y6-Hk
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 00:19:05 +0000
Received: from [85.158.143.99:61169] by server-3.bemta-4.messagelabs.com id
	6A/3D-05808-8FD29DF4; Thu, 14 Jun 2012 00:19:04 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339633142!32410553!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE4Nzc1OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4567 invoked from network); 14 Jun 2012 00:19:04 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 00:19:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1339633144; x=1371169144;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=lsrKEzSnYHIrNG/0QxOd+e6hZMDYuUHkUBjQadZ7Zlo=;
	b=E7kK9LkxBEzeXVFXTKUtTpb//KkMHwiXynRtpUleZk42T5hx7c0d1Tx1
	w0Vb/Sq66FWjWcFmoS9qRINgT+D6yw==;
X-IronPort-AV: E=Sophos;i="4.77,407,1336348800"; d="scan'208";a="750577256"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jun 2012 00:19:01 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-14-48.sea19.amazon.com [10.50.14.48])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5E0IwFX014184; Thu, 14 Jun 2012 00:18:58 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 13 Jun 2012 17:18:55 -0700
Date: Wed, 13 Jun 2012 17:18:55 -0700
From: Matt Wilson <msw@amazon.com>
To: Jason Stubbs <jasonbstubbs@gmail.com>
Message-ID: <20120614001855.GA2136@US-SEA-R8XVZTX>
References: <4FD1918A.2060908@gmail.com> <20120612035737.GL22848@dastard>
	<4FD731F9.8070509@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD731F9.8070509@gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Dave Chinner <david@fromorbit.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] PROBLEM: Possible race between xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 12, 2012 at 05:11:37AM -0700, Jason Stubbs wrote:
> On 2012-6-12 13:57 , Dave Chinner wrote:
> > Nothing
> > wrong with MD, LVM, or XFS. The problem is either that EBS never
> > completed the IO, or Xen swallowed it and it never made to it to the
> > guest OS. Either way, it does not appear to be a problem in the
> > higher levels of the linux storage stack.
> 
> Thanks Dave for looking into this.
> 
> I'll be sure to give Amazon ample opportunity to diagnose things from
> there side should the issue occur again and hopefully there won't be
> any more people reporting extraneous issues.

Hi Jason,

If you're able to reproduce this hang, I'm sure that we can get to the
root of the problem quite quickly. Short of that, if you can provide a
running instance that is exhibiting the problem we can do some
live-system debugging. It is much more difficult to determine root
cause and verify fixes without reproduction instructions.

Given the kernel version you reported in your traces, I can at least
rule out one known bug that caused blkfront to wait forever for an IO
to complete: 
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=dffe2e1

The kernel version you're using using includes the follow-on change to
use fasteoi:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=3588fe2

I'm sorry that I can't be more of more immediate help. If you
encounter the problem again, please contact developer support.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 00:58:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 00: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 1SeyNA-0005LS-8u; Thu, 14 Jun 2012 00:57:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasonbstubbs@gmail.com>) id 1SeyN8-0005LK-3N
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 00:57:14 +0000
Received: from [85.158.143.35:39881] by server-2.bemta-4.messagelabs.com id
	09/15-17938-9E639DF4; Thu, 14 Jun 2012 00:57:13 +0000
X-Env-Sender: jasonbstubbs@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339635431!4299067!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7386 invoked from network); 14 Jun 2012 00:57:12 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 00:57:12 -0000
Received: by pbbro12 with SMTP id ro12so3242492pbb.32
	for <xen-devel@lists.xen.org>; Wed, 13 Jun 2012 17:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=74BBjbAmVV/VejJ1S7MHFAvkDgjIm/HMylfieqKpg8U=;
	b=SKdLJq8Wya/Zwb2dXwU3USwVq+U7KpTVeKUEVuUNuDiq3R4WM+1UUKmEZP+QxUQb14
	vCe7xJnGytbT+EaAjMfnjnr0JqrILWqX5l4O07kj4t1iBcWgWFvLYJuID0fZZcR85ylG
	BkqjyQuU8oLtb6nYFzchrUKni1ozhEIh5VP1o0ySbzlepAif5RPGoucSI2mAO/6sp0PS
	ku+LJv1QiJ7yB0oVaLfUUCUoU80NcMEQjFcfNFUHy+Wq+Kvp5+9reELfSizv7LW9Til7
	ksA+Vq4peT8GbgJHprvHBRwKorh5Bk0MhXYqlQnnJACIBz4MiiFs2RflbbNVmpEids6K
	bE9A==
Received: by 10.68.203.66 with SMTP id ko2mr2028036pbc.84.1339635430614;
	Wed, 13 Jun 2012 17:57:10 -0700 (PDT)
Received: from Jasons-MacBook-Pro.local
	(ppp59-167-188-156.static.internode.on.net. [59.167.188.156])
	by mx.google.com with ESMTPS id ua6sm7530211pbc.20.2012.06.13.17.57.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 13 Jun 2012 17:57:09 -0700 (PDT)
Message-ID: <4FD936E4.6070904@gmail.com>
Date: Thu, 14 Jun 2012 10:57:08 +1000
From: Jason Stubbs <jasonbstubbs@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <4FD1918A.2060908@gmail.com> <20120612035737.GL22848@dastard>
	<4FD731F9.8070509@gmail.com> <20120614001855.GA2136@US-SEA-R8XVZTX>
In-Reply-To: <20120614001855.GA2136@US-SEA-R8XVZTX>
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] PROBLEM: Possible race between xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-6-14 10:18 , Matt Wilson wrote:
> On Tue, Jun 12, 2012 at 05:11:37AM -0700, Jason Stubbs wrote:
>> I'll be sure to give Amazon ample opportunity to diagnose things from
>> there side should the issue occur again and hopefully there won't be
>> any more people reporting extraneous issues.
> 
> If you're able to reproduce this hang, I'm sure that we can get to the
> root of the problem quite quickly. Short of that, if you can provide a
> running instance that is exhibiting the problem we can do some
> live-system debugging. It is much more difficult to determine root
> cause and verify fixes without reproduction instructions.

We've got about 50 instances using the same disk layout, but have only
been running these new instances for a couple of months. We've been
using EC2 and EBS for three years now though, which is why I thought
it was likely something to do with the disk layout of the new instances.
Thinking that, my first concern was to get the instance working again
to keep the service running smoothly.

Come to think of it though, I think I might have had this issue once
before with EBS. Still, that makes two occurrences in somewhere around
70 years combined uptime, so it was either a one off or a very rare
corner case.

Either way, I think all that can be done is to wait for it to happen
again, at which time I'll take it out of production, leave it running
and set up a new instance for production instead.

> Given the kernel version you reported in your traces, I can at least
> rule out one known bug that caused blkfront to wait forever for an IO
> to complete: 
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=dffe2e1
> 
> The kernel version you're using using includes the follow-on change to
> use fasteoi:
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=3588fe2

Yep, this is exactly the sort of corner case I though it might be.
I've confirmed that this change against the sources for the kernel
I'm using, though.

> I'm sorry that I can't be more of more immediate help. If you
> encounter the problem again, please contact developer support.

No problem. We have a support contract and I did go there first, but
the response was basically that nothing can be done without the instance
running. I supplied the traces, but it wasn't clear whether they'd
actually been investigated or not, hence I chose to report here. 
In hindsight, I realize I should have kept the instance running, but
I don't tend to think so clearly when it's the middle of the night. ;)

As for not being able to solve the problem, I don't mind at all. I just
wanted to make sure that an adequate attempt had been made to solve the
problem. We "architect for failure" as much as possible, so the problem
in itself is not such a big deal. Thanks for looking into it!

--
Regards,
Jason Stubbs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 00:58:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 00: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 1SeyNA-0005LS-8u; Thu, 14 Jun 2012 00:57:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jasonbstubbs@gmail.com>) id 1SeyN8-0005LK-3N
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 00:57:14 +0000
Received: from [85.158.143.35:39881] by server-2.bemta-4.messagelabs.com id
	09/15-17938-9E639DF4; Thu, 14 Jun 2012 00:57:13 +0000
X-Env-Sender: jasonbstubbs@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339635431!4299067!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7386 invoked from network); 14 Jun 2012 00:57:12 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 00:57:12 -0000
Received: by pbbro12 with SMTP id ro12so3242492pbb.32
	for <xen-devel@lists.xen.org>; Wed, 13 Jun 2012 17:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=74BBjbAmVV/VejJ1S7MHFAvkDgjIm/HMylfieqKpg8U=;
	b=SKdLJq8Wya/Zwb2dXwU3USwVq+U7KpTVeKUEVuUNuDiq3R4WM+1UUKmEZP+QxUQb14
	vCe7xJnGytbT+EaAjMfnjnr0JqrILWqX5l4O07kj4t1iBcWgWFvLYJuID0fZZcR85ylG
	BkqjyQuU8oLtb6nYFzchrUKni1ozhEIh5VP1o0ySbzlepAif5RPGoucSI2mAO/6sp0PS
	ku+LJv1QiJ7yB0oVaLfUUCUoU80NcMEQjFcfNFUHy+Wq+Kvp5+9reELfSizv7LW9Til7
	ksA+Vq4peT8GbgJHprvHBRwKorh5Bk0MhXYqlQnnJACIBz4MiiFs2RflbbNVmpEids6K
	bE9A==
Received: by 10.68.203.66 with SMTP id ko2mr2028036pbc.84.1339635430614;
	Wed, 13 Jun 2012 17:57:10 -0700 (PDT)
Received: from Jasons-MacBook-Pro.local
	(ppp59-167-188-156.static.internode.on.net. [59.167.188.156])
	by mx.google.com with ESMTPS id ua6sm7530211pbc.20.2012.06.13.17.57.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 13 Jun 2012 17:57:09 -0700 (PDT)
Message-ID: <4FD936E4.6070904@gmail.com>
Date: Thu, 14 Jun 2012 10:57:08 +1000
From: Jason Stubbs <jasonbstubbs@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <4FD1918A.2060908@gmail.com> <20120612035737.GL22848@dastard>
	<4FD731F9.8070509@gmail.com> <20120614001855.GA2136@US-SEA-R8XVZTX>
In-Reply-To: <20120614001855.GA2136@US-SEA-R8XVZTX>
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] PROBLEM: Possible race between xen, md,
	dm and/or xfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-6-14 10:18 , Matt Wilson wrote:
> On Tue, Jun 12, 2012 at 05:11:37AM -0700, Jason Stubbs wrote:
>> I'll be sure to give Amazon ample opportunity to diagnose things from
>> there side should the issue occur again and hopefully there won't be
>> any more people reporting extraneous issues.
> 
> If you're able to reproduce this hang, I'm sure that we can get to the
> root of the problem quite quickly. Short of that, if you can provide a
> running instance that is exhibiting the problem we can do some
> live-system debugging. It is much more difficult to determine root
> cause and verify fixes without reproduction instructions.

We've got about 50 instances using the same disk layout, but have only
been running these new instances for a couple of months. We've been
using EC2 and EBS for three years now though, which is why I thought
it was likely something to do with the disk layout of the new instances.
Thinking that, my first concern was to get the instance working again
to keep the service running smoothly.

Come to think of it though, I think I might have had this issue once
before with EBS. Still, that makes two occurrences in somewhere around
70 years combined uptime, so it was either a one off or a very rare
corner case.

Either way, I think all that can be done is to wait for it to happen
again, at which time I'll take it out of production, leave it running
and set up a new instance for production instead.

> Given the kernel version you reported in your traces, I can at least
> rule out one known bug that caused blkfront to wait forever for an IO
> to complete: 
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=dffe2e1
> 
> The kernel version you're using using includes the follow-on change to
> use fasteoi:
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=3588fe2

Yep, this is exactly the sort of corner case I though it might be.
I've confirmed that this change against the sources for the kernel
I'm using, though.

> I'm sorry that I can't be more of more immediate help. If you
> encounter the problem again, please contact developer support.

No problem. We have a support contract and I did go there first, but
the response was basically that nothing can be done without the instance
running. I supplied the traces, but it wasn't clear whether they'd
actually been investigated or not, hence I chose to report here. 
In hindsight, I realize I should have kept the instance running, but
I don't tend to think so clearly when it's the middle of the night. ;)

As for not being able to solve the problem, I don't mind at all. I just
wanted to make sure that an adequate attempt had been made to solve the
problem. We "architect for failure" as much as possible, so the problem
in itself is not such a big deal. Thanks for looking into it!

--
Regards,
Jason Stubbs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 07:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 07: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 1Sf49C-0004IJ-PZ; Thu, 14 Jun 2012 07:07: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 1Sf49B-0004IB-3V
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 07:07:13 +0000
Received: from [85.158.139.83:64178] by server-12.bemta-5.messagelabs.com id
	D5/91-12933-0AD89DF4; Thu, 14 Jun 2012 07:07:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339657631!23723210!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6024 invoked from network); 14 Jun 2012 07:07:12 -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 Jun 2012 07:07:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 08:07:10 +0100
Message-Id: <4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 08:07:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
In-Reply-To: <20120613165529.GA10986@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  	struct page **pages;
>  	unsigned int nr_pages, array_size, i;
>  	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> -
> +	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> +	if (xen_pv_domain()) {
> +		if (dma_mask == (__GFP_DMA | __GFP_DMA32))

As said in an earlier reply - without having any place that would
ever set both flags at once, this whole conditional is meaningless.
In our code - which I suppose is where you cloned this from - we
set GFP_VMALLOC32 to such a value for 32-bit kernels (which
otherwise would merely use GFP_KERNEL, and hence not trigger
the code calling xen_limit_pages_to_max_mfn()). I don't recall
though whether Carsten's problem was on a 32- or 64-bit kernel.

Jan

> +			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> +	}
>  	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
>  	array_size = (nr_pages * sizeof(struct page *));
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 07:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 07: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 1Sf49C-0004IJ-PZ; Thu, 14 Jun 2012 07:07: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 1Sf49B-0004IB-3V
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 07:07:13 +0000
Received: from [85.158.139.83:64178] by server-12.bemta-5.messagelabs.com id
	D5/91-12933-0AD89DF4; Thu, 14 Jun 2012 07:07:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339657631!23723210!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6024 invoked from network); 14 Jun 2012 07:07:12 -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 Jun 2012 07:07:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 08:07:10 +0100
Message-Id: <4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 08:07:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
In-Reply-To: <20120613165529.GA10986@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  	struct page **pages;
>  	unsigned int nr_pages, array_size, i;
>  	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> -
> +	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> +	if (xen_pv_domain()) {
> +		if (dma_mask == (__GFP_DMA | __GFP_DMA32))

As said in an earlier reply - without having any place that would
ever set both flags at once, this whole conditional is meaningless.
In our code - which I suppose is where you cloned this from - we
set GFP_VMALLOC32 to such a value for 32-bit kernels (which
otherwise would merely use GFP_KERNEL, and hence not trigger
the code calling xen_limit_pages_to_max_mfn()). I don't recall
though whether Carsten's problem was on a 32- or 64-bit kernel.

Jan

> +			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> +	}
>  	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
>  	array_size = (nr_pages * sizeof(struct page *));
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 08:42:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08: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 1Sf5dG-00062W-Ca; Thu, 14 Jun 2012 08:42:22 +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 1Sf5dE-00062R-QU
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 08:42:21 +0000
Received: from [85.158.138.51:32117] by server-7.bemta-3.messagelabs.com id
	8B/B4-10113-BE3A9DF4; Thu, 14 Jun 2012 08:42:19 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1339663338!19423709!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15788 invoked from network); 14 Jun 2012 08:42:19 -0000
Received: from mail-gh0-f171.google.com (HELO mail-gh0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 08:42:19 -0000
Received: by ghy10 with SMTP id 10so1538808ghy.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 01:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=35D+no+av+SVLc12oHbHNxyGkxKpKlRpNoXUJoFkjKU=;
	b=BD+U/adF+Hj1PQvmtWpgrFvUJN0wqPnDPo8UPU7hFhF/Ed88GQN1pEP3X2ruECfva4
	OHBU0dcAOiZPsYI6JQDpHoOujbkbGBgHPrlKFLM8oGQ/uawhq+pV2jTrhhFUZzez4Zaw
	rhSrEfQgrrvgMile+CwRfAQdun91Mt3zLCFPpQRt/iEpyvTs2mmmlDJK+4jSgT7NHjbC
	OOyYynNxz/GeI2VD9HqJzSEj6/cvd2FTUxInL17YsFXl43fKLPlK7/vInsMRpTOicJFD
	NOcjQ7Uk5LP6vtGutj1VYWxF1UBJocVvUwAlTi5N9QHkZ8YwPD35eb7/B4LBu+Kwkfyk
	R4dw==
Received: by 10.236.187.2 with SMTP id x2mr1315205yhm.42.1339663114625;
	Thu, 14 Jun 2012 01:38:34 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id w61sm18507649yhi.5.2012.06.14.01.38.32
	(version=SSLv3 cipher=OTHER); Thu, 14 Jun 2012 01:38:34 -0700 (PDT)
Message-ID: <4FD9A307.9030203@cantab.net>
Date: Thu, 14 Jun 2012 09:38:31 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
In-Reply-To: <20120613165529.GA10986@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>, Jan Beulich <jbeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 17:55, Konrad Rzeszutek Wilk wrote:
> 
> +	/* 3. Do the exchange for non-contiguous MFNs. */
> +	success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
> +				      n, 0, out_frames, address_bits);

vmalloc() does not require physically contiguous MFNs.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 08:42:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08: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 1Sf5dG-00062W-Ca; Thu, 14 Jun 2012 08:42:22 +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 1Sf5dE-00062R-QU
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 08:42:21 +0000
Received: from [85.158.138.51:32117] by server-7.bemta-3.messagelabs.com id
	8B/B4-10113-BE3A9DF4; Thu, 14 Jun 2012 08:42:19 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1339663338!19423709!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15788 invoked from network); 14 Jun 2012 08:42:19 -0000
Received: from mail-gh0-f171.google.com (HELO mail-gh0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 08:42:19 -0000
Received: by ghy10 with SMTP id 10so1538808ghy.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 01:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=35D+no+av+SVLc12oHbHNxyGkxKpKlRpNoXUJoFkjKU=;
	b=BD+U/adF+Hj1PQvmtWpgrFvUJN0wqPnDPo8UPU7hFhF/Ed88GQN1pEP3X2ruECfva4
	OHBU0dcAOiZPsYI6JQDpHoOujbkbGBgHPrlKFLM8oGQ/uawhq+pV2jTrhhFUZzez4Zaw
	rhSrEfQgrrvgMile+CwRfAQdun91Mt3zLCFPpQRt/iEpyvTs2mmmlDJK+4jSgT7NHjbC
	OOyYynNxz/GeI2VD9HqJzSEj6/cvd2FTUxInL17YsFXl43fKLPlK7/vInsMRpTOicJFD
	NOcjQ7Uk5LP6vtGutj1VYWxF1UBJocVvUwAlTi5N9QHkZ8YwPD35eb7/B4LBu+Kwkfyk
	R4dw==
Received: by 10.236.187.2 with SMTP id x2mr1315205yhm.42.1339663114625;
	Thu, 14 Jun 2012 01:38:34 -0700 (PDT)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id w61sm18507649yhi.5.2012.06.14.01.38.32
	(version=SSLv3 cipher=OTHER); Thu, 14 Jun 2012 01:38:34 -0700 (PDT)
Message-ID: <4FD9A307.9030203@cantab.net>
Date: Thu, 14 Jun 2012 09:38:31 +0100
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
In-Reply-To: <20120613165529.GA10986@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>, Jan Beulich <jbeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 17:55, Konrad Rzeszutek Wilk wrote:
> 
> +	/* 3. Do the exchange for non-contiguous MFNs. */
> +	success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
> +				      n, 0, out_frames, address_bits);

vmalloc() does not require physically contiguous MFNs.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 08:48:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08: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 1Sf5iK-0006CB-CA; Thu, 14 Jun 2012 08:47: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 1Sf5iJ-0006C3-8S
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 08:47:35 +0000
Received: from [85.158.143.99:7078] by server-2.bemta-4.messagelabs.com id
	FF/28-17938-625A9DF4; Thu, 14 Jun 2012 08:47:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339663653!22068412!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5699 invoked from network); 14 Jun 2012 08:47:33 -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 Jun 2012 08:47:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf5iG-000Ldh-Su; Thu, 14 Jun 2012 08:47:32 +0000
Date: Thu, 14 Jun 2012 09:47:32 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120614084732.GA82539@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<20120607090334.GC70339@ocelot.phlegethon.org>
	<1339600416.24104.228.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339600416.24104.228.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:13 +0100 on 13 Jun (1339604016), Ian Campbell wrote:
> Yes, that looks nice, although you still need a bit of a quirk for the
> third level table bit. Patch below.

Much nicer.   One more round of nits below if you feel keen; in any case,
Acked-by: Tim Deegan <tim@xen.org>

> +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> +    paddr_t maddr = INVALID_PADDR;
> +
> +    spin_lock(&p2m->lock);
> +
> +    first = __map_domain_page(p2m->first_level);
> +
> +    pte = first[first_table_offset(paddr)];
> +    if ( !pte.p2m.valid || !pte.p2m.table )
> +        goto done;
> +
> +    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);

second = map_domain_page(pte.p2m.base); ?

> +    pte = second[second_table_offset(paddr)];
> +    if ( !pte.p2m.valid || !pte.p2m.table )
> +        goto done;
> +
> +    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);

likewise, third = map_domain_page(pte.p2m.base); ?

> +    pte = third[third_table_offset(paddr)];
> +
> +    /* This bit must be one in the level 3 entry */
> +    if ( !pte.p2m.table )
> +        pte.bits = 0;
> +
> +done:
> +    if ( pte.p2m.valid )
> +        maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
> +
> +    if (third) unmap_domain_page(third);
> +    if (second) unmap_domain_page(second);
> +    if (first) unmap_domain_page(first);
> +
> +    spin_unlock(&p2m->lock);
> +
> +    return maddr;
> +}
> +
>  int guest_physmap_mark_populate_on_demand(struct domain *d,
>                                            unsigned long gfn,
>                                            unsigned int order)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 349923a..1afd5cb 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
>  /* */
>  void p2m_load_VTTBR(struct domain *d);
>  
> +/* */

 /* Look up the MFN corresponding to a domain's PFN. */

> +paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
> +
>  /* Setup p2m RAM mapping for domain d from start-end. */
>  int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>  /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
> -- 
> 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 Thu Jun 14 08:48:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08: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 1Sf5iK-0006CB-CA; Thu, 14 Jun 2012 08:47: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 1Sf5iJ-0006C3-8S
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 08:47:35 +0000
Received: from [85.158.143.99:7078] by server-2.bemta-4.messagelabs.com id
	FF/28-17938-625A9DF4; Thu, 14 Jun 2012 08:47:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339663653!22068412!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5699 invoked from network); 14 Jun 2012 08:47:33 -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 Jun 2012 08:47:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf5iG-000Ldh-Su; Thu, 14 Jun 2012 08:47:32 +0000
Date: Thu, 14 Jun 2012 09:47:32 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120614084732.GA82539@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<20120607090334.GC70339@ocelot.phlegethon.org>
	<1339600416.24104.228.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339600416.24104.228.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:13 +0100 on 13 Jun (1339604016), Ian Campbell wrote:
> Yes, that looks nice, although you still need a bit of a quirk for the
> third level table bit. Patch below.

Much nicer.   One more round of nits below if you feel keen; in any case,
Acked-by: Tim Deegan <tim@xen.org>

> +paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
> +{
> +    struct p2m_domain *p2m = &d->arch.p2m;
> +    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
> +    paddr_t maddr = INVALID_PADDR;
> +
> +    spin_lock(&p2m->lock);
> +
> +    first = __map_domain_page(p2m->first_level);
> +
> +    pte = first[first_table_offset(paddr)];
> +    if ( !pte.p2m.valid || !pte.p2m.table )
> +        goto done;
> +
> +    second = map_domain_page(first[first_table_offset(paddr)].p2m.base);

second = map_domain_page(pte.p2m.base); ?

> +    pte = second[second_table_offset(paddr)];
> +    if ( !pte.p2m.valid || !pte.p2m.table )
> +        goto done;
> +
> +    third = map_domain_page(second[second_table_offset(paddr)].p2m.base);

likewise, third = map_domain_page(pte.p2m.base); ?

> +    pte = third[third_table_offset(paddr)];
> +
> +    /* This bit must be one in the level 3 entry */
> +    if ( !pte.p2m.table )
> +        pte.bits = 0;
> +
> +done:
> +    if ( pte.p2m.valid )
> +        maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
> +
> +    if (third) unmap_domain_page(third);
> +    if (second) unmap_domain_page(second);
> +    if (first) unmap_domain_page(first);
> +
> +    spin_unlock(&p2m->lock);
> +
> +    return maddr;
> +}
> +
>  int guest_physmap_mark_populate_on_demand(struct domain *d,
>                                            unsigned long gfn,
>                                            unsigned int order)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 349923a..1afd5cb 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
>  /* */
>  void p2m_load_VTTBR(struct domain *d);
>  
> +/* */

 /* Look up the MFN corresponding to a domain's PFN. */

> +paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
> +
>  /* Setup p2m RAM mapping for domain d from start-end. */
>  int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>  /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
> -- 
> 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 Thu Jun 14 08:53:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf5nK-0006Kt-3Y; Thu, 14 Jun 2012 08:52:46 +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 1Sf5nI-0006Kn-80
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 08:52:44 +0000
Received: from [85.158.143.99:47978] by server-2.bemta-4.messagelabs.com id
	CB/72-17938-B56A9DF4; Thu, 14 Jun 2012 08:52:43 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339663962!19790175!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10524 invoked from network); 14 Jun 2012 08:52:43 -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; 14 Jun 2012 08:52:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf5nD-000Lhj-5Y; Thu, 14 Jun 2012 08:52:39 +0000
Date: Thu, 14 Jun 2012 09:52:39 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <dunlapg@umich.edu>
Message-ID: <20120614085239.GB82539@ocelot.phlegethon.org>
References: <patchbomb.1304690477@elijah>
	<be5d93d38f283329dea1.1304690478@elijah> <4DC40841.9020108@amd.com>
	<20110506150028.GF24068@whitby.uk.xensource.com>
	<4DC40B7A.4010605@amd.com>
	<BANLkTinsZO5ZObUDtEVoTU_SWzW8c6scuQ@mail.gmail.com>
	<20110509082716.GG24068@whitby.uk.xensource.com>
	<CAFLBxZbBpSoAQrRsZD_xg7poii2xsCBafC3b1bFe+eubg_2Oxw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbBpSoAQrRsZD_xg7poii2xsCBafC3b1bFe+eubg_2Oxw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4] p2m: Keep statistics on order of p2m
	entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:52 +0100 on 08 Jun (1339156322), George Dunlap wrote:
> On Mon, May 9, 2011 at 9:27 AM, Tim Deegan <Tim.Deegan@citrix.com> wrote:
> > At 16:34 +0100 on 06 May (1304699686), George Dunlap wrote:
> >> This patch is actually not necessary for the series -- just for the
> >> verification that it worked. =A0I could drop this patch so we can
> >> discuss it, and send the other three by themselves (since they seem
> >> pretty uncontroversial).
> >
> > I think that's best. =A0I'll be looking at reference-counting p2m entri=
es
> > soon, I hope, and I'll add some bookkeeping when I do. =A0I suspect I c=
an
> > isolate it into a single place then.\
> =

> Tim, I realize this is over a year ago now, but did you ever end up
> adding this bookkeeping?  I'm trying to port this patch again...

No, I never did. :(

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 08:53:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf5nK-0006Kt-3Y; Thu, 14 Jun 2012 08:52:46 +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 1Sf5nI-0006Kn-80
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 08:52:44 +0000
Received: from [85.158.143.99:47978] by server-2.bemta-4.messagelabs.com id
	CB/72-17938-B56A9DF4; Thu, 14 Jun 2012 08:52:43 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339663962!19790175!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10524 invoked from network); 14 Jun 2012 08:52:43 -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; 14 Jun 2012 08:52:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf5nD-000Lhj-5Y; Thu, 14 Jun 2012 08:52:39 +0000
Date: Thu, 14 Jun 2012 09:52:39 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <dunlapg@umich.edu>
Message-ID: <20120614085239.GB82539@ocelot.phlegethon.org>
References: <patchbomb.1304690477@elijah>
	<be5d93d38f283329dea1.1304690478@elijah> <4DC40841.9020108@amd.com>
	<20110506150028.GF24068@whitby.uk.xensource.com>
	<4DC40B7A.4010605@amd.com>
	<BANLkTinsZO5ZObUDtEVoTU_SWzW8c6scuQ@mail.gmail.com>
	<20110509082716.GG24068@whitby.uk.xensource.com>
	<CAFLBxZbBpSoAQrRsZD_xg7poii2xsCBafC3b1bFe+eubg_2Oxw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbBpSoAQrRsZD_xg7poii2xsCBafC3b1bFe+eubg_2Oxw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4] p2m: Keep statistics on order of p2m
	entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:52 +0100 on 08 Jun (1339156322), George Dunlap wrote:
> On Mon, May 9, 2011 at 9:27 AM, Tim Deegan <Tim.Deegan@citrix.com> wrote:
> > At 16:34 +0100 on 06 May (1304699686), George Dunlap wrote:
> >> This patch is actually not necessary for the series -- just for the
> >> verification that it worked. =A0I could drop this patch so we can
> >> discuss it, and send the other three by themselves (since they seem
> >> pretty uncontroversial).
> >
> > I think that's best. =A0I'll be looking at reference-counting p2m entri=
es
> > soon, I hope, and I'll add some bookkeeping when I do. =A0I suspect I c=
an
> > isolate it into a single place then.\
> =

> Tim, I realize this is over a year ago now, but did you ever end up
> adding this bookkeeping?  I'm trying to port this patch again...

No, I never did. :(

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 08:56:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08: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 1Sf5qr-0006Si-No; Thu, 14 Jun 2012 08:56:25 +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 1Sf5qp-0006SY-Nc
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 08:56:23 +0000
Received: from [85.158.143.35:12544] by server-3.bemta-4.messagelabs.com id
	3E/FB-05808-737A9DF4; Thu, 14 Jun 2012 08:56:23 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339664181!4785794!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM1Njcw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8169 invoked from network); 14 Jun 2012 08:56:21 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-21.messagelabs.com with SMTP;
	14 Jun 2012 08:56:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 14 Jun 2012 01:56:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="157477088"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 14 Jun 2012 01:56:17 -0700
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; Thu, 14 Jun 2012 01:56:13 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Thu, 14 Jun 2012 16:56:11 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: xen/mce - mcelog at 100% cpu
Thread-Index: AQHNSZLddQXy2gd5YkW4phd9182UzZb5g2gw
Date: Thu, 14 Jun 2012 08:56:11 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233523183E@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
	<20120613182458.GA5813@phenom.dumpdata.com>
In-Reply-To: <20120613182458.GA5813@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] xen/mce - mcelog at 100% 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

Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 12, 2012 at 08:40:15AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, Jun 12, 2012 at 07:51:03AM +0000, Liu, Jinsong wrote:
>>>> From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00
>>>> 2001 
>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>> Date: Tue, 12 Jun 2012 23:11:16 +0800
>>> Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in
>>> atomic context 
>>> 
>>> copy_to_user might sleep and print a stack trace if it is executed
>>> in an atomic spinlock context.
>>> 
>>> This patch schedule a workqueue for IRQ handler to poll the data,
>>> and use mutex instead of spinlock, so copy_to_user sleep in atomic
>>> context would not occur.
>> 
>> Ah much better. Usually one also includes the report of what the
>> stack trace was. So I've added that in.
> 
> So another bug which is that mcelog is spinning at 100% CPU (and only
> under Xen).
> 
> It seems to be doing:
> 
> ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8)
> = 1 ([{fd=3, revents=POLLIN}]) read(3, "", 2816)                     
> = 0 
> ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8)
> = 1 ([{fd=3, revents=POLLIN}]) read(3, "", 2816)
> 
> constantly.

I will debug it. I have try at my platform, but fail to reproduce it. (You still use the config you send me last time, right?)
Would you tell me your step?

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 Jun 14 08:56:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 08: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 1Sf5qr-0006Si-No; Thu, 14 Jun 2012 08:56:25 +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 1Sf5qp-0006SY-Nc
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 08:56:23 +0000
Received: from [85.158.143.35:12544] by server-3.bemta-4.messagelabs.com id
	3E/FB-05808-737A9DF4; Thu, 14 Jun 2012 08:56:23 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339664181!4785794!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM1Njcw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8169 invoked from network); 14 Jun 2012 08:56:21 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-21.messagelabs.com with SMTP;
	14 Jun 2012 08:56:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 14 Jun 2012 01:56:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="157477088"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 14 Jun 2012 01:56:17 -0700
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; Thu, 14 Jun 2012 01:56:13 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.56]) with mapi id
	14.01.0355.002; Thu, 14 Jun 2012 16:56:11 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: xen/mce - mcelog at 100% cpu
Thread-Index: AQHNSZLddQXy2gd5YkW4phd9182UzZb5g2gw
Date: Thu, 14 Jun 2012 08:56:11 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233523183E@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
	<20120613182458.GA5813@phenom.dumpdata.com>
In-Reply-To: <20120613182458.GA5813@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] xen/mce - mcelog at 100% 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

Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 12, 2012 at 08:40:15AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, Jun 12, 2012 at 07:51:03AM +0000, Liu, Jinsong wrote:
>>>> From aa2ce7440f16002266dc8464f749992d0c8ac0e5 Mon Sep 17 00:00:00
>>>> 2001 
>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>> Date: Tue, 12 Jun 2012 23:11:16 +0800
>>> Subject: [PATCH] xen/mce: schedule a workqueue to avoid sleep in
>>> atomic context 
>>> 
>>> copy_to_user might sleep and print a stack trace if it is executed
>>> in an atomic spinlock context.
>>> 
>>> This patch schedule a workqueue for IRQ handler to poll the data,
>>> and use mutex instead of spinlock, so copy_to_user sleep in atomic
>>> context would not occur.
>> 
>> Ah much better. Usually one also includes the report of what the
>> stack trace was. So I've added that in.
> 
> So another bug which is that mcelog is spinning at 100% CPU (and only
> under Xen).
> 
> It seems to be doing:
> 
> ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8)
> = 1 ([{fd=3, revents=POLLIN}]) read(3, "", 2816)                     
> = 0 
> ppoll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, NULL, [], 8)
> = 1 ([{fd=3, revents=POLLIN}]) read(3, "", 2816)
> 
> constantly.

I will debug it. I have try at my platform, but fail to reproduce it. (You still use the config you send me last time, right?)
Would you tell me your step?

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 Jun 14 09:07:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf61b-0006k1-Vr; Thu, 14 Jun 2012 09:07:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf61a-0006jw-KD
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 09:07:30 +0000
Received: from [193.109.254.147:42057] by server-8.bemta-14.messagelabs.com id
	BF/F3-27132-1D9A9DF4; Thu, 14 Jun 2012 09:07:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339664848!8857623!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7691 invoked from network); 14 Jun 2012 09:07:28 -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; 14 Jun 2012 09:07:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf61V-000Lt8-Nf; Thu, 14 Jun 2012 09:07:25 +0000
Date: Thu, 14 Jun 2012 10:07:25 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614090725.GC82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
	<4FD205E80200007800088C36@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD205E80200007800088C36@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
	pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:02 +0100 on 08 Jun (1339160536), Jan Beulich wrote:
> >>> On 08.06.12 at 13:45, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > --- a/xen/include/asm-x86/p2m.h
> > +++ b/xen/include/asm-x86/p2m.h
> > @@ -287,6 +287,9 @@ struct p2m_domain {
> >          unsigned         reclaim_super; /* Last gpfn of a scan */
> >          unsigned         reclaim_single; /* Last gpfn of a scan */
> >          unsigned         max_guest;    /* gpfn of max guest demand-populate */
> > +#define POD_HISTORY_MAX 128
> > +        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */

This is the gpfns of the last 128 order-9 superpages populated, right?
Also, this line is >80 columns - I think I saw a few others in this series. 

> unsigned long?
> 
> Also, wouldn't it be better to allocate this table dynamically, at
> once allowing its size to scale with the number of vCPU-s in the
> guest?

You could even make it a small per-vcpu array, assuming that the parallel 
scrubbing will be symmetric across vcpus.

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 Jun 14 09:07:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf61b-0006k1-Vr; Thu, 14 Jun 2012 09:07:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf61a-0006jw-KD
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 09:07:30 +0000
Received: from [193.109.254.147:42057] by server-8.bemta-14.messagelabs.com id
	BF/F3-27132-1D9A9DF4; Thu, 14 Jun 2012 09:07:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339664848!8857623!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7691 invoked from network); 14 Jun 2012 09:07:28 -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; 14 Jun 2012 09:07:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf61V-000Lt8-Nf; Thu, 14 Jun 2012 09:07:25 +0000
Date: Thu, 14 Jun 2012 10:07:25 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614090725.GC82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
	<4FD205E80200007800088C36@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD205E80200007800088C36@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
	pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:02 +0100 on 08 Jun (1339160536), Jan Beulich wrote:
> >>> On 08.06.12 at 13:45, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > --- a/xen/include/asm-x86/p2m.h
> > +++ b/xen/include/asm-x86/p2m.h
> > @@ -287,6 +287,9 @@ struct p2m_domain {
> >          unsigned         reclaim_super; /* Last gpfn of a scan */
> >          unsigned         reclaim_single; /* Last gpfn of a scan */
> >          unsigned         max_guest;    /* gpfn of max guest demand-populate */
> > +#define POD_HISTORY_MAX 128
> > +        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */

This is the gpfns of the last 128 order-9 superpages populated, right?
Also, this line is >80 columns - I think I saw a few others in this series. 

> unsigned long?
> 
> Also, wouldn't it be better to allocate this table dynamically, at
> once allowing its size to scale with the number of vCPU-s in the
> guest?

You could even make it a small per-vcpu array, assuming that the parallel 
scrubbing will be symmetric across vcpus.

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 Jun 14 09:11:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09: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 1Sf65W-0006rA-KT; Thu, 14 Jun 2012 09:11:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf65V-0006qz-4Q
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 09:11:33 +0000
Received: from [85.158.139.83:62902] by server-2.bemta-5.messagelabs.com id
	F0/AB-04598-4CAA9DF4; Thu, 14 Jun 2012 09:11:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339665091!27609160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7605 invoked from network); 14 Jun 2012 09:11:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 09:11:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf65T-000MKp-3S; Thu, 14 Jun 2012 09:11:31 +0000
Date: Thu, 14 Jun 2012 10:11:31 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614091131.GD82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6e760eb25dac400f4873.1339155933@exile>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
	pod: Only sweep in an emergency, and only for 4k pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
> +    if ( p2m->pod.count == 0 )
> +        goto out_of_memory;
>  
>      /* Keep track of the highest gfn demand-populated by a guest fault */
>      if ( gfn > p2m->pod.max_guest )
>          p2m->pod.max_guest = gfn;
>  
> -    if ( p2m->pod.count == 0 )
> -        goto out_of_memory;
> -

Is this code motion just noise?  Since out_of_memory crasheds the guest,
I assume so.

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 Jun 14 09:11:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09: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 1Sf65W-0006rA-KT; Thu, 14 Jun 2012 09:11:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf65V-0006qz-4Q
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 09:11:33 +0000
Received: from [85.158.139.83:62902] by server-2.bemta-5.messagelabs.com id
	F0/AB-04598-4CAA9DF4; Thu, 14 Jun 2012 09:11:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339665091!27609160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7605 invoked from network); 14 Jun 2012 09:11:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 09:11:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf65T-000MKp-3S; Thu, 14 Jun 2012 09:11:31 +0000
Date: Thu, 14 Jun 2012 10:11:31 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614091131.GD82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6e760eb25dac400f4873.1339155933@exile>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
	pod: Only sweep in an emergency, and only for 4k pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
> +    if ( p2m->pod.count == 0 )
> +        goto out_of_memory;
>  
>      /* Keep track of the highest gfn demand-populated by a guest fault */
>      if ( gfn > p2m->pod.max_guest )
>          p2m->pod.max_guest = gfn;
>  
> -    if ( p2m->pod.count == 0 )
> -        goto out_of_memory;
> -

Is this code motion just noise?  Since out_of_memory crasheds the guest,
I assume so.

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 Jun 14 09:12:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09: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 1Sf66M-0006v1-4m; Thu, 14 Jun 2012 09:12:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf66K-0006uu-VM
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 09:12:25 +0000
Received: from [85.158.139.83:58090] by server-6.bemta-5.messagelabs.com id
	05/AC-11348-8FAA9DF4; Thu, 14 Jun 2012 09:12:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339665143!27084157!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1388 invoked from network); 14 Jun 2012 09:12:23 -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; 14 Jun 2012 09:12:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf66J-000MLb-6Z; Thu, 14 Jun 2012 09:12:23 +0000
Date: Thu, 14 Jun 2012 10:12:23 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614091223.GE82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1339155931@exile>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2 RFC] Rework populate-on-demand
	sweeping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:45 +0000 on 08 Jun (1339155931), George Dunlap wrote:
> I haven't done more than compile-test it at this point, so please just
> review ideas and "is this 4.2 material".  If I get positive feedback,
> I'll do more testing and re-submit.

Yes, AFAIC this is 4.2 material. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 09:12:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09: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 1Sf66M-0006v1-4m; Thu, 14 Jun 2012 09:12:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf66K-0006uu-VM
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 09:12:25 +0000
Received: from [85.158.139.83:58090] by server-6.bemta-5.messagelabs.com id
	05/AC-11348-8FAA9DF4; Thu, 14 Jun 2012 09:12:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339665143!27084157!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1388 invoked from network); 14 Jun 2012 09:12:23 -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; 14 Jun 2012 09:12:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf66J-000MLb-6Z; Thu, 14 Jun 2012 09:12:23 +0000
Date: Thu, 14 Jun 2012 10:12:23 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614091223.GE82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1339155931@exile>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2 RFC] Rework populate-on-demand
	sweeping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:45 +0000 on 08 Jun (1339155931), George Dunlap wrote:
> I haven't done more than compile-test it at this point, so please just
> review ideas and "is this 4.2 material".  If I get positive feedback,
> I'll do more testing and re-submit.

Yes, AFAIC this is 4.2 material. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 09:30:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09:30: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 1Sf6NS-0007WB-Vn; Thu, 14 Jun 2012 09:30:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1Sf6NQ-0007W4-PD
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 09:30:04 +0000
Received: from [85.158.143.99:51211] by server-2.bemta-4.messagelabs.com id
	C4/5E-17938-C1FA9DF4; Thu, 14 Jun 2012 09:30:04 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339666202!17559418!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 14 Jun 2012 09:30:03 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 09:30:03 -0000
Received: by yhoo21 with SMTP id o21so1513229yho.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 02:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=keCkwPjjVhkd5KIyMRoHsAjcElW95tvhc5EijSA8/Fk=;
	b=wF1QCjL3VvnU2AaqrtP2+PZ2OeeNpt/dV0sl2ysukAju7dtvIpJM9caB1F7SShIfN9
	qniSOqMzN+3cVGDO5h2U+xhmgEB0M6glm8tuByRzlja96NwTdj3acHceljjN90TYOpfz
	zpNGCvv4lhwC4bpwG3S/mC+lzn9ybsJEX5jT8eu/GqIhCrwSvKhFP202pVsqUCWnvDLp
	ror5Y7m3XpyI+JswhSwNSd6JXaS+h4aIrdzCnS6l31GB5JS3av0eszIY0NYHmstd1/JW
	4S8O8rhFBT3hTC5pDCmTg4haIR7XV06uGAM4lonpyJRPO/auzkTV+fxNsXU5gj95mTBM
	RdvA==
MIME-Version: 1.0
Received: by 10.60.19.196 with SMTP id h4mr955369oee.56.1339666201958; Thu, 14
	Jun 2012 02:30:01 -0700 (PDT)
Received: by 10.182.53.65 with HTTP; Thu, 14 Jun 2012 02:30:01 -0700 (PDT)
Date: Thu, 14 Jun 2012 17:30:01 +0800
Message-ID: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen dire-map 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hell all,
I am doing some research work on protecting Xen's data structures. I
know there is a direct-map area(about 12M), in which we can get  the
physical address of the data structure from its virtual address.  My
question is : are the stack and the heap of Xen both located in this
direct-map area? Since I need protect stack and heap data, so it is
easy to identify their physical addresses if they are both in this
area. Thanks.
-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 09:30:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09:30: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 1Sf6NS-0007WB-Vn; Thu, 14 Jun 2012 09:30:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1Sf6NQ-0007W4-PD
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 09:30:04 +0000
Received: from [85.158.143.99:51211] by server-2.bemta-4.messagelabs.com id
	C4/5E-17938-C1FA9DF4; Thu, 14 Jun 2012 09:30:04 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339666202!17559418!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 14 Jun 2012 09:30:03 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 09:30:03 -0000
Received: by yhoo21 with SMTP id o21so1513229yho.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 02:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=keCkwPjjVhkd5KIyMRoHsAjcElW95tvhc5EijSA8/Fk=;
	b=wF1QCjL3VvnU2AaqrtP2+PZ2OeeNpt/dV0sl2ysukAju7dtvIpJM9caB1F7SShIfN9
	qniSOqMzN+3cVGDO5h2U+xhmgEB0M6glm8tuByRzlja96NwTdj3acHceljjN90TYOpfz
	zpNGCvv4lhwC4bpwG3S/mC+lzn9ybsJEX5jT8eu/GqIhCrwSvKhFP202pVsqUCWnvDLp
	ror5Y7m3XpyI+JswhSwNSd6JXaS+h4aIrdzCnS6l31GB5JS3av0eszIY0NYHmstd1/JW
	4S8O8rhFBT3hTC5pDCmTg4haIR7XV06uGAM4lonpyJRPO/auzkTV+fxNsXU5gj95mTBM
	RdvA==
MIME-Version: 1.0
Received: by 10.60.19.196 with SMTP id h4mr955369oee.56.1339666201958; Thu, 14
	Jun 2012 02:30:01 -0700 (PDT)
Received: by 10.182.53.65 with HTTP; Thu, 14 Jun 2012 02:30:01 -0700 (PDT)
Date: Thu, 14 Jun 2012 17:30:01 +0800
Message-ID: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen dire-map 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hell all,
I am doing some research work on protecting Xen's data structures. I
know there is a direct-map area(about 12M), in which we can get  the
physical address of the data structure from its virtual address.  My
question is : are the stack and the heap of Xen both located in this
direct-map area? Since I need protect stack and heap data, so it is
easy to identify their physical addresses if they are both in this
area. Thanks.
-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 09:58:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf6on-0000Lg-CV; Thu, 14 Jun 2012 09:58: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 1Sf6ol-0000LZ-Jr
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 09:58:19 +0000
Received: from [193.109.254.147:8862] by server-3.bemta-14.messagelabs.com id
	F7/72-05653-AB5B9DF4; Thu, 14 Jun 2012 09:58:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339667897!9555078!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1767 invoked from network); 14 Jun 2012 09:58:18 -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 Jun 2012 09:58:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf6oi-000N4p-RD; Thu, 14 Jun 2012 09:58:16 +0000
Date: Thu, 14 Jun 2012 10:58:16 +0100
From: Tim Deegan <tim@xen.org>
To: Baozeng <sploving1@gmail.com>
Message-ID: <20120614095816.GF82539@ocelot.phlegethon.org>
References: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen dire-map 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

At 17:30 +0800 on 14 Jun (1339695001), Baozeng wrote:
> Hell all,
> 
> I am doing some research work on protecting Xen's data structures.
> I know there is a direct-map area(about 12M), in which we can get  the
> physical address of the data structure from its virtual address.  My
> question is : are the stack and the heap of Xen both located in this
> direct-map area?

On 32-bit x86, anything allocated with alloc_xenheap_* or xmalloc() is
in that area (and that includes Xen's stacks).  Anything allocated with
alloc_domheap_* is not.  Also the frametable and M2P are mapped
separately.  The details are in include/asm-x86/config.h.

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 Jun 14 09:58:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 09:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf6on-0000Lg-CV; Thu, 14 Jun 2012 09:58: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 1Sf6ol-0000LZ-Jr
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 09:58:19 +0000
Received: from [193.109.254.147:8862] by server-3.bemta-14.messagelabs.com id
	F7/72-05653-AB5B9DF4; Thu, 14 Jun 2012 09:58:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339667897!9555078!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1767 invoked from network); 14 Jun 2012 09:58:18 -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 Jun 2012 09:58:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf6oi-000N4p-RD; Thu, 14 Jun 2012 09:58:16 +0000
Date: Thu, 14 Jun 2012 10:58:16 +0100
From: Tim Deegan <tim@xen.org>
To: Baozeng <sploving1@gmail.com>
Message-ID: <20120614095816.GF82539@ocelot.phlegethon.org>
References: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen dire-map 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

At 17:30 +0800 on 14 Jun (1339695001), Baozeng wrote:
> Hell all,
> 
> I am doing some research work on protecting Xen's data structures.
> I know there is a direct-map area(about 12M), in which we can get  the
> physical address of the data structure from its virtual address.  My
> question is : are the stack and the heap of Xen both located in this
> direct-map area?

On 32-bit x86, anything allocated with alloc_xenheap_* or xmalloc() is
in that area (and that includes Xen's stacks).  Anything allocated with
alloc_domheap_* is not.  Also the frametable and M2P are mapped
separately.  The details are in include/asm-x86/config.h.

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 Jun 14 10:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7A3-000139-3m; Thu, 14 Jun 2012 10:20:19 +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 1Sf7A1-000134-B8
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 10:20:17 +0000
Received: from [193.109.254.147:5700] by server-8.bemta-14.messagelabs.com id
	53/50-27132-0EAB9DF4; Thu, 14 Jun 2012 10:20:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339669213!9669155!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31018 invoked from network); 14 Jun 2012 10:20:13 -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 Jun 2012 10:20:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf748-000NGM-Sy; Thu, 14 Jun 2012 10:14:12 +0000
Date: Thu, 14 Jun 2012 11:14:12 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614101412.GG82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1339156490@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 RFC] Populate-on-demand: Check pages
	being returned by the balloon 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

At 12:54 +0100 on 08 Jun (1339160090), George Dunlap wrote:
> Populate-on-demand: Check pages being returned by the balloon driver
> 
> This patch series is the second result of my work last summer on
> decreasing fragmentation of superpages in a guests' p2m when using
> populate-on-demand.
> 
> This patch series is against 4.1; I'm posting it to get feedback on
> the viability of getting a ported version of this patch into 4.2.
> 
> As with the previous series, the patces against 4.1 have been
> extensively in the XenServer testing framework and have been in use by
> XenServer customers for over 9 months now.  But the p2m code has
> changed extensively in that time, so one could argue that the testing
> doesn't give us the same degree of confidence in the patches against
> 4.2 as against 4.1.

I think there's a reasonable chance of getting this in for 4.2 -- any
errors should at least be isolated in the PoD parts. :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7A3-000139-3m; Thu, 14 Jun 2012 10:20:19 +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 1Sf7A1-000134-B8
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 10:20:17 +0000
Received: from [193.109.254.147:5700] by server-8.bemta-14.messagelabs.com id
	53/50-27132-0EAB9DF4; Thu, 14 Jun 2012 10:20:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339669213!9669155!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31018 invoked from network); 14 Jun 2012 10:20:13 -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 Jun 2012 10:20:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf748-000NGM-Sy; Thu, 14 Jun 2012 10:14:12 +0000
Date: Thu, 14 Jun 2012 11:14:12 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614101412.GG82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1339156490@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 RFC] Populate-on-demand: Check pages
	being returned by the balloon 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

At 12:54 +0100 on 08 Jun (1339160090), George Dunlap wrote:
> Populate-on-demand: Check pages being returned by the balloon driver
> 
> This patch series is the second result of my work last summer on
> decreasing fragmentation of superpages in a guests' p2m when using
> populate-on-demand.
> 
> This patch series is against 4.1; I'm posting it to get feedback on
> the viability of getting a ported version of this patch into 4.2.
> 
> As with the previous series, the patces against 4.1 have been
> extensively in the XenServer testing framework and have been in use by
> XenServer customers for over 9 months now.  But the p2m code has
> changed extensively in that time, so one could argue that the testing
> doesn't give us the same degree of confidence in the patches against
> 4.2 as against 4.1.

I think there's a reasonable chance of getting this in for 4.2 -- any
errors should at least be isolated in the PoD parts. :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:21:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10:21: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 1Sf7B1-00016Z-6P; Thu, 14 Jun 2012 10:21: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 1Sf7B0-00016M-A7
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 10:21:18 +0000
Received: from [85.158.143.99:4826] by server-1.bemta-4.messagelabs.com id
	FB/6E-24392-D1BB9DF4; Thu, 14 Jun 2012 10:21:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339669276!22019402!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10187 invoked from network); 14 Jun 2012 10:21:16 -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 Jun 2012 10:21:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf7Ay-000NLa-5N; Thu, 14 Jun 2012 10:21:16 +0000
Date: Thu, 14 Jun 2012 11:21:16 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614102116.GH82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <672e9628f27845d24a3f.1339156491@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 +0100 on 08 Jun (1339160091), George Dunlap wrote:
> Return the p2m level of the entry which filled this request.
> Intended to be used to see if pages returned by the balloon
> driver are part of a superpage, and reclaim them if so.

This looks broadly correct, but it's a bit invasive.  If there's any way
to rework patch 2 not to need it that would be helpful.  It looks like
the main use is for detecting and removing superpage PoD entries; maybe
that could be done with a sweep like you have in the non-PoD case?

One niggle: returning level=5 on error is non-obvious, and it doesn't
look like your code in patch 2 uses that.

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 Jun 14 10:21:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10:21: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 1Sf7B1-00016Z-6P; Thu, 14 Jun 2012 10:21: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 1Sf7B0-00016M-A7
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 10:21:18 +0000
Received: from [85.158.143.99:4826] by server-1.bemta-4.messagelabs.com id
	FB/6E-24392-D1BB9DF4; Thu, 14 Jun 2012 10:21:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339669276!22019402!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10187 invoked from network); 14 Jun 2012 10:21:16 -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 Jun 2012 10:21:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf7Ay-000NLa-5N; Thu, 14 Jun 2012 10:21:16 +0000
Date: Thu, 14 Jun 2012 11:21:16 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614102116.GH82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <672e9628f27845d24a3f.1339156491@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 +0100 on 08 Jun (1339160091), George Dunlap wrote:
> Return the p2m level of the entry which filled this request.
> Intended to be used to see if pages returned by the balloon
> driver are part of a superpage, and reclaim them if so.

This looks broadly correct, but it's a bit invasive.  If there's any way
to rework patch 2 not to need it that would be helpful.  It looks like
the main use is for detecting and removing superpage PoD entries; maybe
that could be done with a sweep like you have in the non-PoD case?

One niggle: returning level=5 on error is non-obvious, and it doesn't
look like your code in patch 2 uses that.

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 Jun 14 10:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7Gv-0001be-4N; Thu, 14 Jun 2012 10:27:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sf7Gt-0001bV-G0
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:27:23 +0000
Received: from [85.158.138.51:41417] by server-9.bemta-3.messagelabs.com id
	8A/A3-10419-A8CB9DF4; Thu, 14 Jun 2012 10:27:22 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339669641!27690683!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16438 invoked from network); 14 Jun 2012 10:27:21 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-5.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 10:27:21 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id DD67A5A0007
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 11:27:20 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id xr+uWlD8YAdQ for <xen-devel@lists.xen.org>;
	Thu, 14 Jun 2012 11:27:16 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	925CA5A0005
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 11:27:16 +0100 (BST)
Message-ID: <4FD9BC88.1050001@abpni.co.uk>
Date: Thu, 14 Jun 2012 11:27:20 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Everyone,

According to this CVE:

http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html

The patch has been added to xen-3.4-testing.hg. However, when I look here:

http://xenbits.xen.org/hg/xen-3.4-testing.hg/

I don't see any recent commits.

Am I missing something? I feel it is very important that these patches 
make its way into this branch, and tagged as 3.4.5 ASAP :)

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7Gv-0001be-4N; Thu, 14 Jun 2012 10:27:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sf7Gt-0001bV-G0
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:27:23 +0000
Received: from [85.158.138.51:41417] by server-9.bemta-3.messagelabs.com id
	8A/A3-10419-A8CB9DF4; Thu, 14 Jun 2012 10:27:22 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339669641!27690683!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16438 invoked from network); 14 Jun 2012 10:27:21 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-5.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 10:27:21 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id DD67A5A0007
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 11:27:20 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id xr+uWlD8YAdQ for <xen-devel@lists.xen.org>;
	Thu, 14 Jun 2012 11:27:16 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	925CA5A0005
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 11:27:16 +0100 (BST)
Message-ID: <4FD9BC88.1050001@abpni.co.uk>
Date: Thu, 14 Jun 2012 11:27:20 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Everyone,

According to this CVE:

http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html

The patch has been added to xen-3.4-testing.hg. However, when I look here:

http://xenbits.xen.org/hg/xen-3.4-testing.hg/

I don't see any recent commits.

Am I missing something? I feel it is very important that these patches 
make its way into this branch, and tagged as 3.4.5 ASAP :)

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:28:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7Hh-0001gD-Mb; Thu, 14 Jun 2012 10:28: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 1Sf7Hf-0001fr-R4
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 10:28:12 +0000
Received: from [193.109.254.147:4720] by server-4.bemta-14.messagelabs.com id
	BE/C8-27598-ABCB9DF4; Thu, 14 Jun 2012 10:28:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339669689!9715096!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29950 invoked from network); 14 Jun 2012 10:28:10 -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; 14 Jun 2012 10:28:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf7Hc-000NRj-55; Thu, 14 Jun 2012 10:28:08 +0000
Date: Thu, 14 Jun 2012 11:28:08 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614102808.GI82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8264589787b484b7f903.1339156492@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
	pod: Check zero-check pages returned by the balloon 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

At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
> +        else if( p2m_is_ram(t) )
> +        {
> +            if ( steal_for_cache )
> +            {
> +                struct page_info *page;
> +                
> +                ASSERT(mfn_valid(mfn));

I think this assertion is broken by the paging code, which adds
paged-out pages to the RAM types.  One fix is to undo that change and
have p2m_is_ram() only be true for present pages, but I think for 4.2 it
would be less disruptive to test here for the paged-out and paging
types.

Cc'ing Andres on the larger question -- do you think we can have
p2m_is_ram() imply mfn_valid() again?  I'm not sure whether it will make
things cleaner (or at least move the burden of handling paged-out memory
into the paging code) or add more boilerplate to paths where the paging
will be handled after a check for p2m_os_ram().  What do you think?

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 Jun 14 10:28:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7Hh-0001gD-Mb; Thu, 14 Jun 2012 10:28: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 1Sf7Hf-0001fr-R4
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 10:28:12 +0000
Received: from [193.109.254.147:4720] by server-4.bemta-14.messagelabs.com id
	BE/C8-27598-ABCB9DF4; Thu, 14 Jun 2012 10:28:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339669689!9715096!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29950 invoked from network); 14 Jun 2012 10:28:10 -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; 14 Jun 2012 10:28:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf7Hc-000NRj-55; Thu, 14 Jun 2012 10:28:08 +0000
Date: Thu, 14 Jun 2012 11:28:08 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614102808.GI82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8264589787b484b7f903.1339156492@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
	pod: Check zero-check pages returned by the balloon 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

At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
> +        else if( p2m_is_ram(t) )
> +        {
> +            if ( steal_for_cache )
> +            {
> +                struct page_info *page;
> +                
> +                ASSERT(mfn_valid(mfn));

I think this assertion is broken by the paging code, which adds
paged-out pages to the RAM types.  One fix is to undo that change and
have p2m_is_ram() only be true for present pages, but I think for 4.2 it
would be less disruptive to test here for the paged-out and paging
types.

Cc'ing Andres on the larger question -- do you think we can have
p2m_is_ram() imply mfn_valid() again?  I'm not sure whether it will make
things cleaner (or at least move the burden of handling paged-out memory
into the paging code) or add more boilerplate to paths where the paging
will be handled after a check for p2m_os_ram().  What do you think?

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 Jun 14 10:37:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7Qm-0002d8-WA; Thu, 14 Jun 2012 10:37:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sf7Qm-0002d0-2R
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:37:36 +0000
Received: from [85.158.143.99:18019] by server-3.bemta-4.messagelabs.com id
	CA/63-05808-FEEB9DF4; Thu, 14 Jun 2012 10:37:35 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339670254!19815189!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26126 invoked from network); 14 Jun 2012 10:37:34 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-11.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 10:37:34 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id 71B2E5A0007
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 11:37:34 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id mEE1mwDUdQyk for <xen-devel@lists.xen.org>;
	Thu, 14 Jun 2012 11:37:32 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	CFBB55A0005; Thu, 14 Jun 2012 11:37:30 +0100 (BST)
Message-ID: <4FD9BEEE.6020504@abpni.co.uk>
Date: Thu, 14 Jun 2012 11:37:34 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, keith.coleman@n2servers.com
References: <4F4D650E.3010909@abpni.co.uk>
	<1330509198.4270.19.camel@zakaz.uk.xensource.com>
	<CAH4C7zH9_e6ObQH46iuQd8Ms4OJUBGcYDV5PR2GG5_UxD17sEQ@mail.gmail.com>
In-Reply-To: <CAH4C7zH9_e6ObQH46iuQd8Ms4OJUBGcYDV5PR2GG5_UxD17sEQ@mail.gmail.com>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/03/2012 11:40, Keith Coleman wrote:
> On Wed, Feb 29, 2012 at 4:53 AM, Ian Campbell<Ian.Campbell@citrix.com>  wrote:
>> On Tue, 2012-02-28 at 23:36 +0000, Jonathan Tripathy wrote:
>>> Hi Keith,
> Jonathan,
>
> Thank you for bringing up these issues. I will resolve them.
>
>> On a related note it would be very useful if
>> http://wiki.xen.org/wiki/Security_Announcements could be updated when
>> security fixes corresponding to Xen.org security vulnerability
>> disclosures are added to the 3.4 branch. Keith, can you do that? If not
>> then if you drop me a line each time I'll take care of it for you.
>>
> Certainly!
>
>
> --
> Keith Coleman
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Hi Keith,

Is there any update regarding the issue of backporting a few patches, as 
per my post from February? The CVEs in question are:

CVE-2011-2901
CVE-2011-1898
CVE-2012-0029
CVE-2011-1166

I'm also guessing that 3.4.5 will be released very soon, due to the 
recent CVEs (http://lists.xen.org/archives/html/xen-announce/2012-06/) ?

I appreciate your time

Many Thanks

Jonathan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:37:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10: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 1Sf7Qm-0002d8-WA; Thu, 14 Jun 2012 10:37:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sf7Qm-0002d0-2R
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:37:36 +0000
Received: from [85.158.143.99:18019] by server-3.bemta-4.messagelabs.com id
	CA/63-05808-FEEB9DF4; Thu, 14 Jun 2012 10:37:35 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339670254!19815189!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26126 invoked from network); 14 Jun 2012 10:37:34 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-11.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 10:37:34 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id 71B2E5A0007
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 11:37:34 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id mEE1mwDUdQyk for <xen-devel@lists.xen.org>;
	Thu, 14 Jun 2012 11:37:32 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	CFBB55A0005; Thu, 14 Jun 2012 11:37:30 +0100 (BST)
Message-ID: <4FD9BEEE.6020504@abpni.co.uk>
Date: Thu, 14 Jun 2012 11:37:34 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, keith.coleman@n2servers.com
References: <4F4D650E.3010909@abpni.co.uk>
	<1330509198.4270.19.camel@zakaz.uk.xensource.com>
	<CAH4C7zH9_e6ObQH46iuQd8Ms4OJUBGcYDV5PR2GG5_UxD17sEQ@mail.gmail.com>
In-Reply-To: <CAH4C7zH9_e6ObQH46iuQd8Ms4OJUBGcYDV5PR2GG5_UxD17sEQ@mail.gmail.com>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/03/2012 11:40, Keith Coleman wrote:
> On Wed, Feb 29, 2012 at 4:53 AM, Ian Campbell<Ian.Campbell@citrix.com>  wrote:
>> On Tue, 2012-02-28 at 23:36 +0000, Jonathan Tripathy wrote:
>>> Hi Keith,
> Jonathan,
>
> Thank you for bringing up these issues. I will resolve them.
>
>> On a related note it would be very useful if
>> http://wiki.xen.org/wiki/Security_Announcements could be updated when
>> security fixes corresponding to Xen.org security vulnerability
>> disclosures are added to the 3.4 branch. Keith, can you do that? If not
>> then if you drop me a line each time I'll take care of it for you.
>>
> Certainly!
>
>
> --
> Keith Coleman
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Hi Keith,

Is there any update regarding the issue of backporting a few patches, as 
per my post from February? The CVEs in question are:

CVE-2011-2901
CVE-2011-1898
CVE-2012-0029
CVE-2011-1166

I'm also guessing that 3.4.5 will be released very soon, due to the 
recent CVEs (http://lists.xen.org/archives/html/xen-announce/2012-06/) ?

I appreciate your time

Many Thanks

Jonathan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:55:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1Sf7iA-0002yz-KC; Thu, 14 Jun 2012 10:55:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Sf7i8-0002yu-Lp
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:55:33 +0000
Received: from [193.109.254.147:10613] by server-7.bemta-14.messagelabs.com id
	19/A8-29165-323C9DF4; Thu, 14 Jun 2012 10:55:31 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339671329!9676512!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4958 invoked from network); 14 Jun 2012 10:55:30 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 10:55:30 -0000
Received: by qaeb19 with SMTP id b19so4379619qae.11
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 03:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=ufjUFj8L/C4G9sjQ1AA32JQHVsbtETcGMdjTGcJw3qY=;
	b=qmbUswnCwRpVql/I16M06OTCp/NOvzmTE7P5RVWkAt88Gl+Xj5b5o751oBTcP/mtGl
	3quLL5U/xeN0EIyvesCLcWTcitpYGQU0df57rAXCvXEMoeWh3wEzFUOYhXe2TLV02CPJ
	3n9/L2aV0YHDComRYD0SHMTMzElXR8MXQ3GbrGDJsOQlXtKTJ+A1MKipbMx9ekmJS5db
	jfC533/6iFUWxM8ecTb3wT55n4Mkd14dMlN8HByCObCSD6FBDmlT40byksvVRNblC74W
	Q2QmrJp83DUnXR+XqULCNZSdL+XzAi+jI9AlMZGkDd8+ra6o4xZ7l48yOK2dpitK7jPU
	3GEw==
Received: by 10.229.137.7 with SMTP id u7mr610830qct.109.1339671329154; Thu,
	14 Jun 2012 03:55:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.100.71 with HTTP; Thu, 14 Jun 2012 03:55:08 -0700 (PDT)
In-Reply-To: <20120613114427.GA21809@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 14 Jun 2012 11:55:08 +0100
Message-ID: <CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13 June 2012 12:44, Tim Deegan <tim@xen.org> wrote:
> At 11:48 +0100 on 13 Jun (1339588138), Jean Guyader wrote:
>> On 07/06 04:36, Tim Deegan wrote:
>> > Using one ring for all clients raises the question of access control a=
nd
>> > admission control -- in particular how do you avoid DoS from
>> > badly-behaved clients?
>> >
>> > And, given your concerns about sharing an OS with an uncooperative
>> > Xenstore client, how do you handle sharing the OS with a badly behaved
>> > v4v client?
>> >
>> > If we _do_ need one ring with multiple writers, and therefore Xen needs
>> > to arbitrate writes, there's still room for the policy-based parts
>> > (controlling connection setup, for example) to live outside the
>> > hypervisor, openvswitch-style.
>>
>> Today the acl check in V4V (not part of the current patch serie) is
>> done for every copy by Xen.
>
> OK; can you describe roughly how it works? =A0Is it a whitelist of good
> domains, or a blacklist of bad? =A0Does it just do access control or is
> there rate limiting? =A0Can it detect and block badly-behaved clients,
> or is that something you do in the server?
>

In xen we keep of list of simple acls. Here is the usage of the userspace
tools that controls it. This is a straight forward implementation of the ru=
le
API.

Usage: viptables command [rule]
Commands :
  --append	-A			Append rule
  --insert	-I <n>			Insert rule before rule <n>
  --list	-L			List rules
  --delete	-D[<n>]			Delete rule <n> or the following rule
  --flush	-F			Flush rules
  --help	-h			Help
Rule options:
  --dom-in	-d <n>			Client domid
  --dom-out	-e <n>			Server domid
  --port-in	-p <n>			Client port
  --port-out	-q <n>			Server port
  --jump	-j {ACCEPT|REJECT}	What to do


> Have you given any thought to my second question -- if you can't rely on
> the existing xenstore code, are there problems with sharing a VM with
> other v4v drivers? =A0My intuition is that at least it would not be so
> bad, since non-malicious drivers ought to be able to coexist, but I'd
> like to know your opinion.
>

Are you talking about having different version of V4V driver running
in the same VM?
I don't think that is a problem they both interact with Xen via
hypercall directly so
if they follow the v4v hypercall interface it's all fine.

>> Moving the policy control outside of Xen
>> would mean that you still need to have a copy of the acls in Xen and
>> the worst thing that can happen is for the copy to get out of sync.
>
> What I meant by openvswitch-style is to have a single low-level ACL in
> the hypervisor (maybe as a whitelist of known good connections) and
> fault all unusual behaviour (new domain appears, &c) to the more complex
> policy engine in user-space.
>

Yes sure.

> Really it depends on what kind of policy you want to be able to express.
> If a simple yes/no whitelist is good enough (and always will be) then it
> may as well live in the hypervisor and we can skip the 'defer to
> userspace' part.
>
>> What do you think would be the next step going forward?
>
> Hopefully, to get some feedback from other people (specifically Ian, Ian
> and Stefano but anyone else too!) and decide what, if anything, ought to
> be changed about the design.
>
> My feedback has mostly been about the hypervisor side of things -- I'm
> sure the tools maintainers have some ideas about how this should be
> merged with libvchan, to avoid having two separate comms interfaces.
>

Ok. Thanks for your feedback.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:55:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1Sf7iA-0002yz-KC; Thu, 14 Jun 2012 10:55:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1Sf7i8-0002yu-Lp
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:55:33 +0000
Received: from [193.109.254.147:10613] by server-7.bemta-14.messagelabs.com id
	19/A8-29165-323C9DF4; Thu, 14 Jun 2012 10:55:31 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339671329!9676512!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4958 invoked from network); 14 Jun 2012 10:55:30 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 10:55:30 -0000
Received: by qaeb19 with SMTP id b19so4379619qae.11
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 03:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=ufjUFj8L/C4G9sjQ1AA32JQHVsbtETcGMdjTGcJw3qY=;
	b=qmbUswnCwRpVql/I16M06OTCp/NOvzmTE7P5RVWkAt88Gl+Xj5b5o751oBTcP/mtGl
	3quLL5U/xeN0EIyvesCLcWTcitpYGQU0df57rAXCvXEMoeWh3wEzFUOYhXe2TLV02CPJ
	3n9/L2aV0YHDComRYD0SHMTMzElXR8MXQ3GbrGDJsOQlXtKTJ+A1MKipbMx9ekmJS5db
	jfC533/6iFUWxM8ecTb3wT55n4Mkd14dMlN8HByCObCSD6FBDmlT40byksvVRNblC74W
	Q2QmrJp83DUnXR+XqULCNZSdL+XzAi+jI9AlMZGkDd8+ra6o4xZ7l48yOK2dpitK7jPU
	3GEw==
Received: by 10.229.137.7 with SMTP id u7mr610830qct.109.1339671329154; Thu,
	14 Jun 2012 03:55:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.100.71 with HTTP; Thu, 14 Jun 2012 03:55:08 -0700 (PDT)
In-Reply-To: <20120613114427.GA21809@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 14 Jun 2012 11:55:08 +0100
Message-ID: <CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13 June 2012 12:44, Tim Deegan <tim@xen.org> wrote:
> At 11:48 +0100 on 13 Jun (1339588138), Jean Guyader wrote:
>> On 07/06 04:36, Tim Deegan wrote:
>> > Using one ring for all clients raises the question of access control a=
nd
>> > admission control -- in particular how do you avoid DoS from
>> > badly-behaved clients?
>> >
>> > And, given your concerns about sharing an OS with an uncooperative
>> > Xenstore client, how do you handle sharing the OS with a badly behaved
>> > v4v client?
>> >
>> > If we _do_ need one ring with multiple writers, and therefore Xen needs
>> > to arbitrate writes, there's still room for the policy-based parts
>> > (controlling connection setup, for example) to live outside the
>> > hypervisor, openvswitch-style.
>>
>> Today the acl check in V4V (not part of the current patch serie) is
>> done for every copy by Xen.
>
> OK; can you describe roughly how it works? =A0Is it a whitelist of good
> domains, or a blacklist of bad? =A0Does it just do access control or is
> there rate limiting? =A0Can it detect and block badly-behaved clients,
> or is that something you do in the server?
>

In xen we keep of list of simple acls. Here is the usage of the userspace
tools that controls it. This is a straight forward implementation of the ru=
le
API.

Usage: viptables command [rule]
Commands :
  --append	-A			Append rule
  --insert	-I <n>			Insert rule before rule <n>
  --list	-L			List rules
  --delete	-D[<n>]			Delete rule <n> or the following rule
  --flush	-F			Flush rules
  --help	-h			Help
Rule options:
  --dom-in	-d <n>			Client domid
  --dom-out	-e <n>			Server domid
  --port-in	-p <n>			Client port
  --port-out	-q <n>			Server port
  --jump	-j {ACCEPT|REJECT}	What to do


> Have you given any thought to my second question -- if you can't rely on
> the existing xenstore code, are there problems with sharing a VM with
> other v4v drivers? =A0My intuition is that at least it would not be so
> bad, since non-malicious drivers ought to be able to coexist, but I'd
> like to know your opinion.
>

Are you talking about having different version of V4V driver running
in the same VM?
I don't think that is a problem they both interact with Xen via
hypercall directly so
if they follow the v4v hypercall interface it's all fine.

>> Moving the policy control outside of Xen
>> would mean that you still need to have a copy of the acls in Xen and
>> the worst thing that can happen is for the copy to get out of sync.
>
> What I meant by openvswitch-style is to have a single low-level ACL in
> the hypervisor (maybe as a whitelist of known good connections) and
> fault all unusual behaviour (new domain appears, &c) to the more complex
> policy engine in user-space.
>

Yes sure.

> Really it depends on what kind of policy you want to be able to express.
> If a simple yes/no whitelist is good enough (and always will be) then it
> may as well live in the hypervisor and we can skip the 'defer to
> userspace' part.
>
>> What do you think would be the next step going forward?
>
> Hopefully, to get some feedback from other people (specifically Ian, Ian
> and Stefano but anyone else too!) and decide what, if anything, ought to
> be changed about the design.
>
> My feedback has mostly been about the hypervisor side of things -- I'm
> sure the tools maintainers have some ideas about how this should be
> merged with libvchan, to avoid having two separate comms interfaces.
>

Ok. Thanks for your feedback.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf7iq-000317-1Y; Thu, 14 Jun 2012 10:56:16 +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 1Sf7io-00030w-Sd
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:56:14 +0000
Received: from [85.158.138.51:39170] by server-2.bemta-3.messagelabs.com id
	EF/C7-31533-E43C9DF4; Thu, 14 Jun 2012 10:56:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339671373!21273373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10919 invoked from network); 14 Jun 2012 10:56:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 10:56:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,769,1330905600"; d="scan'208";a="13019105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:56:13 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 11:56:12 +0100
Message-ID: <4FD9C352.7080606@citrix.com>
Date: Thu, 14 Jun 2012 11:56:18 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
References: <4FD9BC88.1050001@abpni.co.uk>
In-Reply-To: <4FD9BC88.1050001@abpni.co.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jonathan Tripathy wrote:
> Hi Everyone,
>
> According to this CVE:
>
> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
>
> The patch has been added to xen-3.4-testing.hg. However, when I look here:
>
> http://xenbits.xen.org/hg/xen-3.4-testing.hg/

It's still in staging:

http://xenbits.xen.org/hg/staging/xen-3.4-testing.hg/

>
> I don't see any recent commits.
>
> Am I missing something? I feel it is very important that these patches
> make its way into this branch, and tagged as 3.4.5 ASAP :)

Not sure why they haven't made it to the repos. I'm Ccing Ian Jackson 
about this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 10:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 10:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf7iq-000317-1Y; Thu, 14 Jun 2012 10:56:16 +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 1Sf7io-00030w-Sd
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 10:56:14 +0000
Received: from [85.158.138.51:39170] by server-2.bemta-3.messagelabs.com id
	EF/C7-31533-E43C9DF4; Thu, 14 Jun 2012 10:56:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339671373!21273373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10919 invoked from network); 14 Jun 2012 10:56:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 10:56:13 -0000
X-IronPort-AV: E=Sophos;i="4.75,769,1330905600"; d="scan'208";a="13019105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:56:13 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 11:56:12 +0100
Message-ID: <4FD9C352.7080606@citrix.com>
Date: Thu, 14 Jun 2012 11:56:18 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
References: <4FD9BC88.1050001@abpni.co.uk>
In-Reply-To: <4FD9BC88.1050001@abpni.co.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jonathan Tripathy wrote:
> Hi Everyone,
>
> According to this CVE:
>
> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
>
> The patch has been added to xen-3.4-testing.hg. However, when I look here:
>
> http://xenbits.xen.org/hg/xen-3.4-testing.hg/

It's still in staging:

http://xenbits.xen.org/hg/staging/xen-3.4-testing.hg/

>
> I don't see any recent commits.
>
> Am I missing something? I feel it is very important that these patches
> make its way into this branch, and tagged as 3.4.5 ASAP :)

Not sure why they haven't made it to the repos. I'm Ccing Ian Jackson 
about this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 11:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 11:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf7vE-0003Lv-BQ; Thu, 14 Jun 2012 11:09:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sf7vD-0003Lq-EB
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 11:09:03 +0000
Received: from [85.158.139.83:4556] by server-8.bemta-5.messagelabs.com id
	B9/5E-10278-E46C9DF4; Thu, 14 Jun 2012 11:09:02 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339672141!27568534!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21738 invoked from network); 14 Jun 2012 11:09:01 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-15.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 11:09:01 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id 791635A0007
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 12:09:01 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id tJ-U5VLyrYIZ for <xen-devel@lists.xen.org>;
	Thu, 14 Jun 2012 12:08:59 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	263CE5A0005
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 12:08:58 +0100 (BST)
Message-ID: <4FD9C64F.7010604@abpni.co.uk>
Date: Thu, 14 Jun 2012 12:09:03 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD9BC88.1050001@abpni.co.uk> <4FD9C352.7080606@citrix.com>
In-Reply-To: <4FD9C352.7080606@citrix.com>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 14/06/2012 11:56, Roger Pau Monne wrote:
> Jonathan Tripathy wrote:
>> Hi Everyone,
>>
>> According to this CVE:
>>
>> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
>>
>> The patch has been added to xen-3.4-testing.hg. However, when I look 
>> here:
>>
>> http://xenbits.xen.org/hg/xen-3.4-testing.hg/
>
> It's still in staging:
>
> http://xenbits.xen.org/hg/staging/xen-3.4-testing.hg/
>
>>
>> I don't see any recent commits.
>>
>> Am I missing something? I feel it is very important that these patches
>> make its way into this branch, and tagged as 3.4.5 ASAP :)
>
> Not sure why they haven't made it to the repos. I'm Ccing Ian Jackson 
> about this.
>
>
Let's also not forget the following CVEs which don't seem to be 
backported yet:

CVE-2011-2901
CVE-2011-1898
CVE-2012-0029
CVE-2011-1166

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 11:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 11:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf7vE-0003Lv-BQ; Thu, 14 Jun 2012 11:09:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sf7vD-0003Lq-EB
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 11:09:03 +0000
Received: from [85.158.139.83:4556] by server-8.bemta-5.messagelabs.com id
	B9/5E-10278-E46C9DF4; Thu, 14 Jun 2012 11:09:02 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339672141!27568534!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21738 invoked from network); 14 Jun 2012 11:09:01 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-15.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 11:09:01 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id 791635A0007
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 12:09:01 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id tJ-U5VLyrYIZ for <xen-devel@lists.xen.org>;
	Thu, 14 Jun 2012 12:08:59 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	263CE5A0005
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 12:08:58 +0100 (BST)
Message-ID: <4FD9C64F.7010604@abpni.co.uk>
Date: Thu, 14 Jun 2012 12:09:03 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <4FD9BC88.1050001@abpni.co.uk> <4FD9C352.7080606@citrix.com>
In-Reply-To: <4FD9C352.7080606@citrix.com>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 14/06/2012 11:56, Roger Pau Monne wrote:
> Jonathan Tripathy wrote:
>> Hi Everyone,
>>
>> According to this CVE:
>>
>> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
>>
>> The patch has been added to xen-3.4-testing.hg. However, when I look 
>> here:
>>
>> http://xenbits.xen.org/hg/xen-3.4-testing.hg/
>
> It's still in staging:
>
> http://xenbits.xen.org/hg/staging/xen-3.4-testing.hg/
>
>>
>> I don't see any recent commits.
>>
>> Am I missing something? I feel it is very important that these patches
>> make its way into this branch, and tagged as 3.4.5 ASAP :)
>
> Not sure why they haven't made it to the repos. I'm Ccing Ian Jackson 
> about this.
>
>
Let's also not forget the following CVEs which don't seem to be 
backported yet:

CVE-2011-2901
CVE-2011-1898
CVE-2012-0029
CVE-2011-1166

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 11:14:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1Sf802-0003Vv-2S; Thu, 14 Jun 2012 11:14: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 1Sf800-0003Vm-CY
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 11:14:00 +0000
Received: from [85.158.143.35:3052] by server-1.bemta-4.messagelabs.com id
	C9/87-24392-777C9DF4; Thu, 14 Jun 2012 11:13:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339672438!12262603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22820 invoked from network); 14 Jun 2012 11:13:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 11:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,769,1330905600"; d="scan'208";a="13019556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 11:13:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 12:13:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sf7zy-0005Jv-F6; Thu, 14 Jun 2012 11:13:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sf7zy-0004Fj-Aw;
	Thu, 14 Jun 2012 12:13:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.51062.325245.658793@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 12:13:58 +0100
To: Roger Pau Monne <roger.pau@citrix.com>, Keith Coleman
	<keith.coleman@n2servers.com>
In-Reply-To: <4FD9C352.7080606@citrix.com>
References: <4FD9BC88.1050001@abpni.co.uk>
	<4FD9C352.7080606@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jonathan Tripathy <jonnyt@abpni.co.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] Recent CVE"):
> Jonathan Tripathy wrote:
> > Hi Everyone,
> >
> > According to this CVE:
> >
> > http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
> >
> > The patch has been added to xen-3.4-testing.hg. However, when I look here:
> >
> > http://xenbits.xen.org/hg/xen-3.4-testing.hg/
> 
> It's still in staging:
> 
> http://xenbits.xen.org/hg/staging/xen-3.4-testing.hg/
...
> Not sure why they haven't made it to the repos. I'm Ccing Ian Jackson 
> about this.

The 3.4 tree doesn't have an automatic push from staging to main.
(The testing software we are using postdates 3.4.)

Looking at the repos, it seems that Keith has been using the main
tree, not staging.  But I pushed the security changes to staging.

Keith, can you say what should be done now ?  I think the best thing
would probably be to hg merge staging into main; there are only those
two security fix commits in staging.

And then we should probably delete the staging tree entirely.

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 Jun 14 11:14:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1Sf802-0003Vv-2S; Thu, 14 Jun 2012 11:14: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 1Sf800-0003Vm-CY
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 11:14:00 +0000
Received: from [85.158.143.35:3052] by server-1.bemta-4.messagelabs.com id
	C9/87-24392-777C9DF4; Thu, 14 Jun 2012 11:13:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339672438!12262603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22820 invoked from network); 14 Jun 2012 11:13:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 11:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.75,769,1330905600"; d="scan'208";a="13019556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 11:13:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 12:13:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sf7zy-0005Jv-F6; Thu, 14 Jun 2012 11:13:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sf7zy-0004Fj-Aw;
	Thu, 14 Jun 2012 12:13:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.51062.325245.658793@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 12:13:58 +0100
To: Roger Pau Monne <roger.pau@citrix.com>, Keith Coleman
	<keith.coleman@n2servers.com>
In-Reply-To: <4FD9C352.7080606@citrix.com>
References: <4FD9BC88.1050001@abpni.co.uk>
	<4FD9C352.7080606@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jonathan Tripathy <jonnyt@abpni.co.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] Recent CVE"):
> Jonathan Tripathy wrote:
> > Hi Everyone,
> >
> > According to this CVE:
> >
> > http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
> >
> > The patch has been added to xen-3.4-testing.hg. However, when I look here:
> >
> > http://xenbits.xen.org/hg/xen-3.4-testing.hg/
> 
> It's still in staging:
> 
> http://xenbits.xen.org/hg/staging/xen-3.4-testing.hg/
...
> Not sure why they haven't made it to the repos. I'm Ccing Ian Jackson 
> about this.

The 3.4 tree doesn't have an automatic push from staging to main.
(The testing software we are using postdates 3.4.)

Looking at the repos, it seems that Keith has been using the main
tree, not staging.  But I pushed the security changes to staging.

Keith, can you say what should be done now ?  I think the best thing
would probably be to hg merge staging into main; there are only those
two security fix commits in staging.

And then we should probably delete the staging tree entirely.

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 Jun 14 11:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 11: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 1Sf8TI-0003nV-J5; Thu, 14 Jun 2012 11:44: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 1Sf8TH-0003nQ-9W
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 11:44:15 +0000
Received: from [85.158.139.83:45439] by server-4.bemta-5.messagelabs.com id
	CC/30-27831-E8EC9DF4; Thu, 14 Jun 2012 11:44:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339674253!27696271!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25187 invoked from network); 14 Jun 2012 11:44: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; 14 Jun 2012 11:44:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 12:44:13 +0100
Message-Id: <4FD9EAD90200007800089EBE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 12:44:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4FD9BC88.1050001@abpni.co.uk> <4FD9C352.7080606@citrix.com>
	<20441.51062.325245.658793@mariner.uk.xensource.com>
In-Reply-To: <20441.51062.325245.658793@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keith Coleman <keith.coleman@n2servers.com>,
	Jonathan Tripathy <jonnyt@abpni.co.uk>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:13, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> And then we should probably delete the staging tree entirely.

Along with all other 3.* staging ones perhaps...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 11:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 11: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 1Sf8TI-0003nV-J5; Thu, 14 Jun 2012 11:44: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 1Sf8TH-0003nQ-9W
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 11:44:15 +0000
Received: from [85.158.139.83:45439] by server-4.bemta-5.messagelabs.com id
	CC/30-27831-E8EC9DF4; Thu, 14 Jun 2012 11:44:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339674253!27696271!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25187 invoked from network); 14 Jun 2012 11:44: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; 14 Jun 2012 11:44:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 12:44:13 +0100
Message-Id: <4FD9EAD90200007800089EBE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 12:44:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4FD9BC88.1050001@abpni.co.uk> <4FD9C352.7080606@citrix.com>
	<20441.51062.325245.658793@mariner.uk.xensource.com>
In-Reply-To: <20441.51062.325245.658793@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keith Coleman <keith.coleman@n2servers.com>,
	Jonathan Tripathy <jonnyt@abpni.co.uk>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:13, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> And then we should probably delete the staging tree entirely.

Along with all other 3.* staging ones perhaps...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:14:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf8vb-0004IT-DL; Thu, 14 Jun 2012 12:13:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Sf8vZ-0004IN-LZ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:13:29 +0000
Received: from [85.158.143.35:45338] by server-2.bemta-4.messagelabs.com id
	04/F4-17938-865D9DF4; Thu, 14 Jun 2012 12:13:28 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339676007!16271761!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23023 invoked from network); 14 Jun 2012 12:13:28 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Jun 2012 12:13:28 -0000
Received: from mail119-va3-R.bigfish.com (10.7.14.235) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 12:12:19 +0000
Received: from mail119-va3 (localhost [127.0.0.1])	by
	mail119-va3-R.bigfish.com (Postfix) with ESMTP id 73240320543;
	Thu, 14 Jun 2012 12:12:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI148cI1432I1447Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail119-va3 (localhost.localdomain [127.0.0.1]) by mail119-va3
	(MessageSwitch) id 1339675936501592_31405;
	Thu, 14 Jun 2012 12:12:16 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.253])	by
	mail119-va3.bigfish.com (Postfix) with ESMTP id 6F22940044;
	Thu, 14 Jun 2012 12:12:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 12:12:12 +0000
X-WSS-ID: 0M5LWM5-01-1JM-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A22C10280B6;	Thu, 14 Jun 2012 07:13:17 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 14 Jun 2012 07:21:43 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 14 Jun 2012 07:13:17 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	08:13:17 -0400
Received: from [165.204.15.183] (caesium.osrc.amd.com [165.204.15.183])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9C38849C69D; Thu, 14 Jun 2012
	13:13:15 +0100 (BST)
Message-ID: <4FD9D559.9050206@amd.com>
Date: Thu, 14 Jun 2012 14:13:13 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
In-Reply-To: <4FD78DE6020000780008986D@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled 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

Am 12.06.2012 18:43, schrieb Jan Beulich:
>>>> On 12.06.12 at 18:08, Andrew Cooper<andrew.cooper3@citrix.com>  wrote:
>> On 12/06/12 16:13, Jan Beulich wrote:
>>>>>> On 12.06.12 at 14:02, Wei Wang<wei.wang2@amd.com>  wrote:
>>>> I had attached a revised patch, please check it.
>>> While the patch technically looks better now, you didn't eliminate
>>> my objections to the approach you take, nor did you comment on
>>> the proposed alternative.
>>>
>>> A fundamental problem is that your IOMMUs show up as a "normal"
>>> PCI devices, breaking the separation between what is being
>>> managed by the hypervisor vs by the Dom0 kernel. (This even
>>> allows something as odd as passing through an IOMMU to a
>>> DomU, which would clearly upset the hypervisor.)
>>>
>>>> I found that the following Linux commit triggers this issue. It has been
>>>> included into 3.4 pv_ops.
>>>>
>>>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>>>     Author: Eric W. Biederman<ebiederm@xmission.com>
>>>>     Date:   Mon Oct 17 11:46:06 2011 -0700
>>>>
>>>>     PCI: msi: Disable msi interrupts when we initialize a pci device "
>>> Thanks for locating this. As it stands, it is incomplete though
>>> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
>>> it won't have a means to suppress the "screaming" interrupts.
>>
>> I feel that the correct solution would be for Xen to hide the PCI
>> devices from dom0.  Xen already hides the DMAR ACPI table (by turning it
>> to an XMAR table), and this would be the logical way to proceed now that
>> IOMMU internals are appearing as PCI devices.

That sounds absolutely good to me. thanks for the suggestion.

> That is precisely what I suggested in my response to the first
> version of this patch, and I'd also volunteer to look into putting
> together a first draft implementation if we sort of agree that
> this is the way to go.

Cool! thanks for doing that. Looking forward to it in Xen 4.2 since 
iommu msi is really broken with recent Linux dom0...

Thanks
Wei


>> ( A similar issue comes into play now that newer generations of CPUs are
>> exposing CPU internals as PCI devices )
>
> Indeed, good point. Might be a little tricky though to determine
> which one(s) they are, and still avoid conflicting with things like
> the EDAC drivers in Dom0.
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:14:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf8vb-0004IT-DL; Thu, 14 Jun 2012 12:13:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Sf8vZ-0004IN-LZ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:13:29 +0000
Received: from [85.158.143.35:45338] by server-2.bemta-4.messagelabs.com id
	04/F4-17938-865D9DF4; Thu, 14 Jun 2012 12:13:28 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339676007!16271761!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23023 invoked from network); 14 Jun 2012 12:13:28 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Jun 2012 12:13:28 -0000
Received: from mail119-va3-R.bigfish.com (10.7.14.235) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 12:12:19 +0000
Received: from mail119-va3 (localhost [127.0.0.1])	by
	mail119-va3-R.bigfish.com (Postfix) with ESMTP id 73240320543;
	Thu, 14 Jun 2012 12:12:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI148cI1432I1447Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail119-va3 (localhost.localdomain [127.0.0.1]) by mail119-va3
	(MessageSwitch) id 1339675936501592_31405;
	Thu, 14 Jun 2012 12:12:16 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.253])	by
	mail119-va3.bigfish.com (Postfix) with ESMTP id 6F22940044;
	Thu, 14 Jun 2012 12:12:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 12:12:12 +0000
X-WSS-ID: 0M5LWM5-01-1JM-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A22C10280B6;	Thu, 14 Jun 2012 07:13:17 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 14 Jun 2012 07:21:43 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 14 Jun 2012 07:13:17 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	08:13:17 -0400
Received: from [165.204.15.183] (caesium.osrc.amd.com [165.204.15.183])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9C38849C69D; Thu, 14 Jun 2012
	13:13:15 +0100 (BST)
Message-ID: <4FD9D559.9050206@amd.com>
Date: Thu, 14 Jun 2012 14:13:13 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
In-Reply-To: <4FD78DE6020000780008986D@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled 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

Am 12.06.2012 18:43, schrieb Jan Beulich:
>>>> On 12.06.12 at 18:08, Andrew Cooper<andrew.cooper3@citrix.com>  wrote:
>> On 12/06/12 16:13, Jan Beulich wrote:
>>>>>> On 12.06.12 at 14:02, Wei Wang<wei.wang2@amd.com>  wrote:
>>>> I had attached a revised patch, please check it.
>>> While the patch technically looks better now, you didn't eliminate
>>> my objections to the approach you take, nor did you comment on
>>> the proposed alternative.
>>>
>>> A fundamental problem is that your IOMMUs show up as a "normal"
>>> PCI devices, breaking the separation between what is being
>>> managed by the hypervisor vs by the Dom0 kernel. (This even
>>> allows something as odd as passing through an IOMMU to a
>>> DomU, which would clearly upset the hypervisor.)
>>>
>>>> I found that the following Linux commit triggers this issue. It has been
>>>> included into 3.4 pv_ops.
>>>>
>>>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>>>     Author: Eric W. Biederman<ebiederm@xmission.com>
>>>>     Date:   Mon Oct 17 11:46:06 2011 -0700
>>>>
>>>>     PCI: msi: Disable msi interrupts when we initialize a pci device "
>>> Thanks for locating this. As it stands, it is incomplete though
>>> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
>>> it won't have a means to suppress the "screaming" interrupts.
>>
>> I feel that the correct solution would be for Xen to hide the PCI
>> devices from dom0.  Xen already hides the DMAR ACPI table (by turning it
>> to an XMAR table), and this would be the logical way to proceed now that
>> IOMMU internals are appearing as PCI devices.

That sounds absolutely good to me. thanks for the suggestion.

> That is precisely what I suggested in my response to the first
> version of this patch, and I'd also volunteer to look into putting
> together a first draft implementation if we sort of agree that
> this is the way to go.

Cool! thanks for doing that. Looking forward to it in Xen 4.2 since 
iommu msi is really broken with recent Linux dom0...

Thanks
Wei


>> ( A similar issue comes into play now that newer generations of CPUs are
>> exposing CPU internals as PCI devices )
>
> Indeed, good point. Might be a little tricky though to determine
> which one(s) they are, and still avoid conflicting with things like
> the EDAC drivers in Dom0.
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf92h-0004Tz-Va; Thu, 14 Jun 2012 12:20:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1Sf92g-0004Tq-Qw
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:20:50 +0000
Received: from [85.158.143.35:30257] by server-2.bemta-4.messagelabs.com id
	88/11-17938-227D9DF4; Thu, 14 Jun 2012 12:20:50 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339676445!15054211!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 341 invoked from network); 14 Jun 2012 12:20:46 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:20:46 -0000
Received: by lbok6 with SMTP id k6so2476650lbo.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 05:20:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=Go59IlkVV8GRopTDQVrtFuhUepgIoYMdX0jQFFHJm9M=;
	b=clb/B6F0BxUF+/E02RuV8Q7jWEuWrqH10bs4lDkJhYhZyF8i+xiXamz787gfR3DkU8
	AAbNT4K3GjerEyMsnUfKaOWMxE6GTcqk15rHK5cnrYtk34/ceKbZXZ/yxjp97mkrN305
	Oo4CCZ9aTUUF0GCRi6OmQojuxJwHsHEj7ONnqA8PnwI94DBRU+ipj+8HuPb5LovzdLUm
	qRHzmpxX9p6qNEl5BfrBVf690dWYJ0TkoRPAFDCzIGGmEeKAO0lkdnme8cUhalQI6Ucz
	1NnHbxsGwMSLWNc/jxe207a/Q5FxAERTgbIsKPc9etERECJPxufGZVak7vK3/bY6Uvgl
	V9pQ==
MIME-Version: 1.0
Received: by 10.112.17.227 with SMTP id r3mr927516lbd.41.1339676445145; Thu,
	14 Jun 2012 05:20:45 -0700 (PDT)
Received: by 10.112.42.67 with HTTP; Thu, 14 Jun 2012 05:20:45 -0700 (PDT)
X-Originating-IP: [71.56.71.211]
In-Reply-To: <4FD9EAD90200007800089EBE@nat28.tlf.novell.com>
References: <4FD9BC88.1050001@abpni.co.uk> <4FD9C352.7080606@citrix.com>
	<20441.51062.325245.658793@mariner.uk.xensource.com>
	<4FD9EAD90200007800089EBE@nat28.tlf.novell.com>
Date: Thu, 14 Jun 2012 08:20:45 -0400
Message-ID: <CAH4C7zFz2566V3W0M7J4C_mS9Kacv3FjEr0BMgx8o738__VdbA@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQmewKRH1fmofUmkfoX/6iltCJKPlSMRmSEZGqPkhUSmynO0SqOcmOy/448KTXVcwwEy4juv
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Tripathy <jonnyt@abpni.co.uk>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 7:44 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 14.06.12 at 13:13, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> And then we should probably delete the staging tree entirely.
>
> Along with all other 3.* staging ones perhaps...
>

The changes have now been pushed to the main tree. I agree that we
should remove the 3.* staging trees.


--
Keith Coleman

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf92h-0004Tz-Va; Thu, 14 Jun 2012 12:20:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1Sf92g-0004Tq-Qw
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:20:50 +0000
Received: from [85.158.143.35:30257] by server-2.bemta-4.messagelabs.com id
	88/11-17938-227D9DF4; Thu, 14 Jun 2012 12:20:50 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339676445!15054211!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 341 invoked from network); 14 Jun 2012 12:20:46 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:20:46 -0000
Received: by lbok6 with SMTP id k6so2476650lbo.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 05:20:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=Go59IlkVV8GRopTDQVrtFuhUepgIoYMdX0jQFFHJm9M=;
	b=clb/B6F0BxUF+/E02RuV8Q7jWEuWrqH10bs4lDkJhYhZyF8i+xiXamz787gfR3DkU8
	AAbNT4K3GjerEyMsnUfKaOWMxE6GTcqk15rHK5cnrYtk34/ceKbZXZ/yxjp97mkrN305
	Oo4CCZ9aTUUF0GCRi6OmQojuxJwHsHEj7ONnqA8PnwI94DBRU+ipj+8HuPb5LovzdLUm
	qRHzmpxX9p6qNEl5BfrBVf690dWYJ0TkoRPAFDCzIGGmEeKAO0lkdnme8cUhalQI6Ucz
	1NnHbxsGwMSLWNc/jxe207a/Q5FxAERTgbIsKPc9etERECJPxufGZVak7vK3/bY6Uvgl
	V9pQ==
MIME-Version: 1.0
Received: by 10.112.17.227 with SMTP id r3mr927516lbd.41.1339676445145; Thu,
	14 Jun 2012 05:20:45 -0700 (PDT)
Received: by 10.112.42.67 with HTTP; Thu, 14 Jun 2012 05:20:45 -0700 (PDT)
X-Originating-IP: [71.56.71.211]
In-Reply-To: <4FD9EAD90200007800089EBE@nat28.tlf.novell.com>
References: <4FD9BC88.1050001@abpni.co.uk> <4FD9C352.7080606@citrix.com>
	<20441.51062.325245.658793@mariner.uk.xensource.com>
	<4FD9EAD90200007800089EBE@nat28.tlf.novell.com>
Date: Thu, 14 Jun 2012 08:20:45 -0400
Message-ID: <CAH4C7zFz2566V3W0M7J4C_mS9Kacv3FjEr0BMgx8o738__VdbA@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQmewKRH1fmofUmkfoX/6iltCJKPlSMRmSEZGqPkhUSmynO0SqOcmOy/448KTXVcwwEy4juv
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Tripathy <jonnyt@abpni.co.uk>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Recent CVE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 7:44 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 14.06.12 at 13:13, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> And then we should probably delete the staging tree entirely.
>
> Along with all other 3.* staging ones perhaps...
>

The changes have now been pushed to the main tree. I agree that we
should remove the 3.* staging trees.


--
Keith Coleman

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93B-0004Y2-R4; Thu, 14 Jun 2012 12:21: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 1Sf93A-0004XJ-3O
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:20 +0000
Received: from [85.158.139.83:24941] by server-5.bemta-5.messagelabs.com id
	B9/F5-02722-F37D9DF4; Thu, 14 Jun 2012 12:21:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 728 invoked from network); 14 Jun 2012 12:21:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067774"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-LO;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:09 +0100
Message-ID: <1339676475-33265-8-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 07/13] libxl: convert libxl_device_nic_add to
	an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch converts libxl_device_nic_add to an ao operation that
waits for device backend to reach state XenbusStateInitWait and then
marks the operation as completed. This is not really useful now, but
will be used by latter patches that will launch hotplug scripts after
we reached the desired xenbus state.

Calls to libxl_device_nic_add have also been moved to occur after the
device model has been launched, so when hotplug scripts are called
from this functions the interfaces already exists.

As usual, libxl_device_nic_add callers have been modified, and the
internal function libxl__device_disk_add has been used if the call was
inside an already running ao.

Changes since v5:

 * Updated to use the new ao_devices struct.

 * Renamed ao_device in nic_add to aodev.

Changes since v4:

 * Used the macro defined in previous patch to define the generic
   callback to wait for nics to be connected.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c          |   39 ++++++++++++++++++++++++++------
 tools/libxl/libxl.h          |    3 +-
 tools/libxl/libxl_create.c   |   50 +++++++++++++++++++++++++++++++++++------
 tools/libxl/libxl_device.c   |    9 ++++---
 tools/libxl/libxl_dm.c       |   37 ++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |   18 +++++++++++++++
 tools/libxl/xl_cmdimpl.c     |    2 +-
 7 files changed, 133 insertions(+), 25 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 5f09740..2d7a7e4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2314,12 +2314,27 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__ao_device *aodev;
+
+    GCNEW(aodev);
+    libxl__prepare_ao_device(ao, aodev);
+    aodev->callback = device_addrm_aocomplete;
+    libxl__device_nic_add(egc, domid, nic, aodev);
+
+    return AO_INPROGRESS;
+}
+
+void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_nic *nic, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
     flexarray_t *front;
     flexarray_t *back;
-    libxl__device device;
+    libxl__device *device;
     char *dompath, **l;
     unsigned int nb, rc;
 
@@ -2350,7 +2365,8 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         }
     }
 
-    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    GCNEW(device);
+    rc = libxl__device_from_nic(gc, domid, nic, device);
     if ( rc != 0 ) goto out_free;
 
     flexarray_append(back, "frontend-id");
@@ -2391,6 +2407,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
     flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__strdup(gc,
+                                     libxl_nic_type_to_string(nic->nictype)));
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
@@ -2401,18 +2420,22 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, XBT_NULL, &device,
+    libxl__device_generic_add(gc, XBT_NULL, device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    aodev->dev = device;
+    aodev->action = DEVICE_CONNECT;
+    libxl__initiate_device_connection(egc, aodev);
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    aodev->rc = rc;
+    if (rc) aodev->callback(egc, aodev);
+    return;
 }
 
 static void libxl__device_nic_from_xs_be(libxl__gc *gc,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index de06f65..324f056 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -672,7 +672,8 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 53ecc0d..274f5d4 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -584,6 +584,9 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
                                 int rc);
 
+static void domcreate_attach_pci(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                 int rc);
+
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
@@ -752,13 +755,11 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
     }
 
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "cannot add nic %d to domain: %d", i, ret);
-            ret = ERROR_FAIL;
-            goto error_out;
-        }
+        /* We have to init the nic here, because we still haven't
+         * called libxl_device_nic_add at this point, but qemu needs
+         * the nic information to be complete.
+         */
+        libxl__device_nic_setdefault(gc, &d_config->vifs[i]);
     }
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -831,7 +832,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss.dm);
     STATE_AO_GC(dmss->spawn.ao);
-    int i;
     libxl_ctx *ctx = CTX;
     int domid = dcs->guest_domid;
 
@@ -851,6 +851,40 @@ static void domcreate_devmodel_started(libxl__egc *egc,
         }
     }
 
+    /* Plug nic interfaces */
+    if (d_config->num_vifs > 0) {
+        /* Attach nics */
+        dcs->aodevs.size = d_config->num_vifs;
+        libxl__add_nics(egc, ao, domid, d_config, &dcs->aodevs,
+                        domcreate_attach_pci);
+        return;
+    }
+
+    domcreate_attach_pci(egc, &dcs->aodevs, 0);
+    return;
+
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_attach_pci(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                 int rc)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(aodevs, *dcs, aodevs);
+    STATE_AO_GC(dcs->ao);
+    int i, ret = 0;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (rc) {
+        LOG(ERROR, "unable to add nic devices");
+        goto error_out;
+    }
+
     for (i = 0; i < d_config->num_pcidevs; i++)
         libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1);
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d34ed5..f7217aa 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -454,8 +454,8 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
 #define libxl__device_disk_add(egc, domid, disk, aodev)                       \
         libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
 
-#define DEFINE_DEVICES_ADD(type)                                              \
-    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
+#define DEFINE_DEVICES_ADD(type, name)                                        \
+    void libxl__add_##name##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
                               libxl_domain_config *d_config,                  \
                               libxl__ao_devices *aodevs,                      \
                               libxl__devices_callback *callback)              \
@@ -469,12 +469,13 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
                                                                               \
         for (i = 0; i < aodevs->size; i++) {                                  \
             aodevs->array[i].callback = libxl__ao_devices_callback;           \
-            libxl__device_##type##_add(egc, domid, &d_config->type##s[i],     \
+            libxl__device_##name##_add(egc, domid, &d_config->type##s[i],     \
                                        &aodevs->array[i]);                    \
         }                                                                     \
     }
 
-DEFINE_DEVICES_ADD(disk)
+DEFINE_DEVICES_ADD(disk, disk)
+DEFINE_DEVICES_ADD(vif, nic)
 
 #undef libxl__device_disk_add
 #undef DEFINE_DEVICES_ADD
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b7979cb..5631f12 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -680,6 +680,10 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
 static void spawn_stub_launch_dm(libxl__egc *egc,
                                  libxl__ao_devices *aodevs, int rc);
 
+static void stubdom_pvqemu_cb(libxl__egc *egc,
+                              libxl__ao_devices *aodevs,
+                              int rc);
+
 static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
                                            libxl__destroy_domid_state *dis,
                                            int rc);
@@ -844,9 +848,11 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
      }
 
     for (i = 0; i < dm_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
-        if (ret)
-            goto out;
+         /* We have to init the nic here, because we still haven't
+         * called libxl_device_nic_add at this point, but qemu needs
+         * the nic information to be complete.
+         */
+        libxl__device_nic_setdefault(gc, &dm_config->vifs[i]);
     }
     ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
@@ -923,9 +929,34 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
         CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
     STATE_AO_GC(sdss->dm.spawn.ao);
     uint32_t dm_domid = sdss->pvqemu.guest_domid;
+    libxl_domain_config *d_config = stubdom_dmss->guest_config;
 
     if (rc) goto out;
 
+    if (d_config->num_vifs > 0) {
+        sdss->aodevs.size = d_config->num_vifs;
+        libxl__add_nics(egc, ao, dm_domid, d_config, &sdss->aodevs,
+                        stubdom_pvqemu_cb);
+        return;
+    }
+
+out:
+    stubdom_pvqemu_cb(egc, &sdss->aodevs, rc);
+}
+
+static void stubdom_pvqemu_cb(libxl__egc *egc,
+                              libxl__ao_devices *aodevs,
+                              int rc)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(aodevs, *sdss, aodevs);
+    STATE_AO_GC(sdss->dm.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) {
+        LOGE(ERROR, "error connecting nics devices");
+        goto out;
+    }
+
     rc = libxl_domain_unpause(CTX, dm_domid);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 937ab08..1d4726b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1761,6 +1761,11 @@ _hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
                                     libxl_device_disk *disk,
                                     libxl__ao_device *aodev);
 
+/* AO operation to connect a nic device */
+_hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__ao_device *aodev);
+
 /* Waits for the passed device to reach state XenbusStateInitWait.
  * This is not really useful by itself, but is important when executing
  * hotplug scripts, since we need to be sure the device is in the correct
@@ -2034,6 +2039,19 @@ void libxl__add_disks(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
                       libxl__ao_devices *aodevs,
                       libxl__devices_callback *callback);
 
+/* Helper function to add a bunch of nics. This should be used when
+ * the caller is inside an async op. "devices" will be prepared by this
+ * function, so there's no need to call _prepare before calling this
+ * function.
+ *
+ * The "callback" will be called for each device, and the user is responsible
+ * for calling libxl__ao_device_check_last on the callback.
+ */
+void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+                     libxl_domain_config *d_config,
+                     libxl__ao_devices *aodevs,
+                     libxl__devices_callback *callback);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a40643d..404c9c2 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5185,7 +5185,7 @@ int main_networkattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93B-0004Y2-R4; Thu, 14 Jun 2012 12:21: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 1Sf93A-0004XJ-3O
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:20 +0000
Received: from [85.158.139.83:24941] by server-5.bemta-5.messagelabs.com id
	B9/F5-02722-F37D9DF4; Thu, 14 Jun 2012 12:21:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 728 invoked from network); 14 Jun 2012 12:21:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067774"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-LO;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:09 +0100
Message-ID: <1339676475-33265-8-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 07/13] libxl: convert libxl_device_nic_add to
	an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch converts libxl_device_nic_add to an ao operation that
waits for device backend to reach state XenbusStateInitWait and then
marks the operation as completed. This is not really useful now, but
will be used by latter patches that will launch hotplug scripts after
we reached the desired xenbus state.

Calls to libxl_device_nic_add have also been moved to occur after the
device model has been launched, so when hotplug scripts are called
from this functions the interfaces already exists.

As usual, libxl_device_nic_add callers have been modified, and the
internal function libxl__device_disk_add has been used if the call was
inside an already running ao.

Changes since v5:

 * Updated to use the new ao_devices struct.

 * Renamed ao_device in nic_add to aodev.

Changes since v4:

 * Used the macro defined in previous patch to define the generic
   callback to wait for nics to be connected.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c          |   39 ++++++++++++++++++++++++++------
 tools/libxl/libxl.h          |    3 +-
 tools/libxl/libxl_create.c   |   50 +++++++++++++++++++++++++++++++++++------
 tools/libxl/libxl_device.c   |    9 ++++---
 tools/libxl/libxl_dm.c       |   37 ++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |   18 +++++++++++++++
 tools/libxl/xl_cmdimpl.c     |    2 +-
 7 files changed, 133 insertions(+), 25 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 5f09740..2d7a7e4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2314,12 +2314,27 @@ static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__ao_device *aodev;
+
+    GCNEW(aodev);
+    libxl__prepare_ao_device(ao, aodev);
+    aodev->callback = device_addrm_aocomplete;
+    libxl__device_nic_add(egc, domid, nic, aodev);
+
+    return AO_INPROGRESS;
+}
+
+void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_nic *nic, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
     flexarray_t *front;
     flexarray_t *back;
-    libxl__device device;
+    libxl__device *device;
     char *dompath, **l;
     unsigned int nb, rc;
 
@@ -2350,7 +2365,8 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
         }
     }
 
-    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    GCNEW(device);
+    rc = libxl__device_from_nic(gc, domid, nic, device);
     if ( rc != 0 ) goto out_free;
 
     flexarray_append(back, "frontend-id");
@@ -2391,6 +2407,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__strdup(gc, nic->bridge));
     flexarray_append(back, "handle");
     flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid));
+    flexarray_append(back, "type");
+    flexarray_append(back, libxl__strdup(gc,
+                                     libxl_nic_type_to_string(nic->nictype)));
 
     flexarray_append(front, "backend-id");
     flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid));
@@ -2401,18 +2420,22 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
     flexarray_append(front, "mac");
     flexarray_append(front, libxl__sprintf(gc,
                                     LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
-    libxl__device_generic_add(gc, XBT_NULL, &device,
+    libxl__device_generic_add(gc, XBT_NULL, device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    aodev->dev = device;
+    aodev->action = DEVICE_CONNECT;
+    libxl__initiate_device_connection(egc, aodev);
+
     rc = 0;
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    GC_FREE;
-    return rc;
+    aodev->rc = rc;
+    if (rc) aodev->callback(egc, aodev);
+    return;
 }
 
 static void libxl__device_nic_from_xs_be(libxl__gc *gc,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index de06f65..324f056 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -672,7 +672,8 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic,
+                         const libxl_asyncop_how *ao_how);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 53ecc0d..274f5d4 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -584,6 +584,9 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
                                 int rc);
 
+static void domcreate_attach_pci(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                 int rc);
+
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
@@ -752,13 +755,11 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
     }
 
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "cannot add nic %d to domain: %d", i, ret);
-            ret = ERROR_FAIL;
-            goto error_out;
-        }
+        /* We have to init the nic here, because we still haven't
+         * called libxl_device_nic_add at this point, but qemu needs
+         * the nic information to be complete.
+         */
+        libxl__device_nic_setdefault(gc, &d_config->vifs[i]);
     }
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -831,7 +832,6 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss.dm);
     STATE_AO_GC(dmss->spawn.ao);
-    int i;
     libxl_ctx *ctx = CTX;
     int domid = dcs->guest_domid;
 
@@ -851,6 +851,40 @@ static void domcreate_devmodel_started(libxl__egc *egc,
         }
     }
 
+    /* Plug nic interfaces */
+    if (d_config->num_vifs > 0) {
+        /* Attach nics */
+        dcs->aodevs.size = d_config->num_vifs;
+        libxl__add_nics(egc, ao, domid, d_config, &dcs->aodevs,
+                        domcreate_attach_pci);
+        return;
+    }
+
+    domcreate_attach_pci(egc, &dcs->aodevs, 0);
+    return;
+
+error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_attach_pci(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                 int rc)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(aodevs, *dcs, aodevs);
+    STATE_AO_GC(dcs->ao);
+    int i, ret = 0;
+    libxl_ctx *ctx = CTX;
+    int domid = dcs->guest_domid;
+
+    /* convenience aliases */
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (rc) {
+        LOG(ERROR, "unable to add nic devices");
+        goto error_out;
+    }
+
     for (i = 0; i < d_config->num_pcidevs; i++)
         libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1);
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d34ed5..f7217aa 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -454,8 +454,8 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
 #define libxl__device_disk_add(egc, domid, disk, aodev)                       \
         libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
 
-#define DEFINE_DEVICES_ADD(type)                                              \
-    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
+#define DEFINE_DEVICES_ADD(type, name)                                        \
+    void libxl__add_##name##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
                               libxl_domain_config *d_config,                  \
                               libxl__ao_devices *aodevs,                      \
                               libxl__devices_callback *callback)              \
@@ -469,12 +469,13 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
                                                                               \
         for (i = 0; i < aodevs->size; i++) {                                  \
             aodevs->array[i].callback = libxl__ao_devices_callback;           \
-            libxl__device_##type##_add(egc, domid, &d_config->type##s[i],     \
+            libxl__device_##name##_add(egc, domid, &d_config->type##s[i],     \
                                        &aodevs->array[i]);                    \
         }                                                                     \
     }
 
-DEFINE_DEVICES_ADD(disk)
+DEFINE_DEVICES_ADD(disk, disk)
+DEFINE_DEVICES_ADD(vif, nic)
 
 #undef libxl__device_disk_add
 #undef DEFINE_DEVICES_ADD
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b7979cb..5631f12 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -680,6 +680,10 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
 static void spawn_stub_launch_dm(libxl__egc *egc,
                                  libxl__ao_devices *aodevs, int rc);
 
+static void stubdom_pvqemu_cb(libxl__egc *egc,
+                              libxl__ao_devices *aodevs,
+                              int rc);
+
 static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
                                            libxl__destroy_domid_state *dis,
                                            int rc);
@@ -844,9 +848,11 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
      }
 
     for (i = 0; i < dm_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
-        if (ret)
-            goto out;
+         /* We have to init the nic here, because we still haven't
+         * called libxl_device_nic_add at this point, but qemu needs
+         * the nic information to be complete.
+         */
+        libxl__device_nic_setdefault(gc, &dm_config->vifs[i]);
     }
     ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
@@ -923,9 +929,34 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
         CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
     STATE_AO_GC(sdss->dm.spawn.ao);
     uint32_t dm_domid = sdss->pvqemu.guest_domid;
+    libxl_domain_config *d_config = stubdom_dmss->guest_config;
 
     if (rc) goto out;
 
+    if (d_config->num_vifs > 0) {
+        sdss->aodevs.size = d_config->num_vifs;
+        libxl__add_nics(egc, ao, dm_domid, d_config, &sdss->aodevs,
+                        stubdom_pvqemu_cb);
+        return;
+    }
+
+out:
+    stubdom_pvqemu_cb(egc, &sdss->aodevs, rc);
+}
+
+static void stubdom_pvqemu_cb(libxl__egc *egc,
+                              libxl__ao_devices *aodevs,
+                              int rc)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(aodevs, *sdss, aodevs);
+    STATE_AO_GC(sdss->dm.spawn.ao);
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) {
+        LOGE(ERROR, "error connecting nics devices");
+        goto out;
+    }
+
     rc = libxl_domain_unpause(CTX, dm_domid);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 937ab08..1d4726b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1761,6 +1761,11 @@ _hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
                                     libxl_device_disk *disk,
                                     libxl__ao_device *aodev);
 
+/* AO operation to connect a nic device */
+_hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_nic *nic,
+                                   libxl__ao_device *aodev);
+
 /* Waits for the passed device to reach state XenbusStateInitWait.
  * This is not really useful by itself, but is important when executing
  * hotplug scripts, since we need to be sure the device is in the correct
@@ -2034,6 +2039,19 @@ void libxl__add_disks(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
                       libxl__ao_devices *aodevs,
                       libxl__devices_callback *callback);
 
+/* Helper function to add a bunch of nics. This should be used when
+ * the caller is inside an async op. "devices" will be prepared by this
+ * function, so there's no need to call _prepare before calling this
+ * function.
+ *
+ * The "callback" will be called for each device, and the user is responsible
+ * for calling libxl__ao_device_check_last on the callback.
+ */
+void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+                     libxl_domain_config *d_config,
+                     libxl__ao_devices *aodevs,
+                     libxl__devices_callback *callback);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a40643d..404c9c2 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5185,7 +5185,7 @@ int main_networkattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_add(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93D-0004Z2-BI; Thu, 14 Jun 2012 12:21:23 +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 1Sf93B-0004Xd-B9
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:21 +0000
Received: from [85.158.138.51:59219] by server-9.bemta-3.messagelabs.com id
	6D/A4-10419-047D9DF4; Thu, 14 Jun 2012 12:21:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339676478!27639891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20980 invoked from network); 14 Jun 2012 12:21:19 -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;
	14 Jun 2012 12:21:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067772"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Ix;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:07 +0100
Message-ID: <1339676475-33265-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 05/13] libxl: convert
	libxl__device_disk_local_attach to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be needed in future patches, when libxl__device_disk_add
becomes async also. Create a new status structure that defines the
local attach of a disk device and use it in
libxl__device_disk_local_attach.

This is done in this patch to split the changes introduced when
libxl__device_disk_add becomes async.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |   91 +++++++++++++++++++++++++++----------
 tools/libxl/libxl_bootloader.c |   97 ++++++++++++++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h   |   42 ++++++++++++-----
 3 files changed, 181 insertions(+), 49 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3ad1931..43affd1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2027,20 +2027,20 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,
     return NULL;
 }
 
-char * libxl__device_disk_local_attach(libxl__gc *gc,
-        const libxl_device_disk *in_disk,
-        libxl_device_disk *disk,
-        const char *blkdev_start)
+void libxl__device_disk_local_attach(libxl__egc *egc,
+                                     libxl__disk_local_state *dls)
 {
-    libxl_ctx *ctx = gc->owner;
+    STATE_AO_GC(dls->ao);
+    libxl_ctx *ctx = CTX;
     char *dev = NULL, *be_path = NULL;
-    char *ret = NULL;
     int rc, xs_ret;
     libxl__device device;
     xs_transaction_t t = XBT_NULL;
+    const libxl_device_disk *in_disk = dls->in_disk;
+    libxl_device_disk *disk = &dls->disk;
+    const char *blkdev_start = dls->blkdev_start;
 
-    if (in_disk->pdev_path == NULL)
-        return NULL;
+    assert(in_disk->pdev_path);
 
     memcpy(disk, in_disk, sizeof(libxl_device_disk));
     disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path);
@@ -2076,6 +2076,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
             default:
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                            "unrecognized disk format: %d", disk->format);
+                rc = ERROR_FAIL;
                 break;
             }
             break;
@@ -2085,15 +2086,18 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
                     t = xs_transaction_start(ctx->xsh);
                     if (t == XBT_NULL) {
                         LOG(ERROR, "failed to start a xenstore transaction");
+                        rc = ERROR_FAIL;
                         goto out;
                     }
                     disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t);
                     if (disk->vdev == NULL) {
                         LOG(ERROR, "libxl__alloc_vdev failed");
+                        rc = ERROR_FAIL;
                         goto out;
                     }
-                    if (libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID,
-                                t, disk)) {
+                    rc = libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID,
+                                                t, disk);
+                    if (rc) {
                         LOG(ERROR, "libxl_device_disk_add failed");
                         goto out;
                     }
@@ -2102,6 +2106,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
                 t = XBT_NULL;
                 if (xs_ret == 0) {
                     LOGE(ERROR, "xenstore transaction failed");
+                    rc = ERROR_FAIL;
                     goto out;
                 }
                 dev = GCSPRINTF("/dev/%s", disk->vdev);
@@ -2113,6 +2118,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
                 "type: %d", disk->backend);
+            rc = ERROR_FAIL;
             break;
     }
 
@@ -2126,42 +2132,79 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
             goto out;
     }
     if (dev != NULL)
-        ret = strdup(dev);
-    return ret;
+        dls->diskpath = strdup(dev);
+
+    dls->callback(egc, dls, 0);
+    return;
 
  out:
+    assert(rc);
     if (t != XBT_NULL)
         xs_transaction_end(ctx->xsh, t, 1);
-    else
-        libxl__device_disk_local_detach(gc, disk);
-    return NULL;
+    dls->callback(egc, dls, rc);
 }
 
-int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
+/* Callbacks for local detach */
+
+static void local_device_detach_cb(libxl__egc *egc, libxl__ao_device *aodev);
+
+void libxl__device_disk_local_detach(libxl__egc *egc,
+                                     libxl__disk_local_state *dls)
 {
+    STATE_AO_GC(dls->ao);
     int rc = 0;
+    libxl_device_disk *disk = &dls->disk;
+    libxl__device *device;
+    libxl__ao_device *aodev = &dls->aodev;
 
     switch (disk->backend) {
         case LIBXL_DISK_BACKEND_QDISK:
             if (disk->vdev != NULL) {
-                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
-                        disk, 0);
-                /* fixme-ao */
-                rc = libxl_device_disk_destroy(gc->owner,
-                        LIBXL_TOOLSTACK_DOMID, disk, 0);
+                GCNEW(device);
+                rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID,
+                                             disk, device);
+                if (rc != 0) goto out;
+
+                libxl__prepare_ao_device(ao, aodev);
+                aodev->action = DEVICE_DISCONNECT;
+                aodev->dev = device;
+                aodev->callback = local_device_detach_cb;
+                aodev->force = 0;
+                libxl__initiate_device_remove(egc, aodev);
             }
-            break;
+            return;
         default:
             /*
              * Nothing to do for PHYSTYPE_PHY.
              * For other device types assume that the blktap2 process is
              * needed by the soon to be started domain and do nothing.
              */
-            break;
+            dls->callback(egc, dls, rc);
+            return;
     }
 
+out:
+    assert(rc);
+    dls->callback(egc, dls, rc);
+    return;
+}
 
-    return rc;
+static void local_device_detach_cb(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    libxl__disk_local_state *dls = CONTAINER_OF(aodev, *dls, aodev);
+
+    if (aodev->rc) {
+        LOGE(ERROR, "unable to %s %s with id %u",
+                    aodev->action == DEVICE_CONNECT ? "add" : "remove",
+                    libxl__device_kind_to_string(aodev->dev->kind),
+                    aodev->dev->devid);
+        goto out;
+    }
+
+out:
+    dls->callback(egc, dls, aodev->rc);
+    return;
 }
 
 /******************************************************************************/
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 7ebc0df..182a975 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -224,11 +224,6 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
     if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
     if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    if (bl->diskpath) {
-        libxl__device_disk_local_detach(gc, &bl->localdisk);
-        free(bl->diskpath);
-        bl->diskpath = 0;
-    }
     libxl__domaindeathcheck_stop(gc,&bl->deathcheck);
     libxl__datacopier_kill(&bl->keystrokes);
     libxl__datacopier_kill(&bl->display);
@@ -249,10 +244,40 @@ static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
     bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
 }
 
+/* Callbacks */
+
+static void bootloader_fisnihed_cb(libxl__egc *egc,
+                                   libxl__disk_local_state *dls,
+                                   int rc);
+
 static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
                                 int rc)
 {
     bootloader_cleanup(egc, bl);
+
+    if (bl->diskpath) {
+        bl->dls.callback = bootloader_fisnihed_cb;
+        libxl__device_disk_local_detach(egc, &bl->dls);
+        return;
+    }
+
+    bl->callback(egc, bl, rc);
+}
+
+static void bootloader_fisnihed_cb(libxl__egc *egc,
+                                   libxl__disk_local_state *dls,
+                                   int rc)
+{
+    STATE_AO_GC(dls->ao);
+    libxl__bootloader_state *bl = CONTAINER_OF(dls, *bl, dls);
+
+    free(bl->diskpath);
+    bl->diskpath = 0;
+
+    if (rc) {
+        LOG(ERROR, "unable to detach locally attached disk");
+    }
+
     bl->callback(egc, bl, rc);
 }
 
@@ -275,6 +300,16 @@ static void bootloader_abort(libxl__egc *egc,
 
 /*----- main flow of control -----*/
 
+/* Callbacks */
+
+static void bootloader_disk_attached_cb(libxl__egc *egc,
+                                        libxl__disk_local_state *dls,
+                                        int rc);
+
+static void bootloader_disk_failed_cb(libxl__egc *egc,
+                                      libxl__disk_local_state *dls,
+                                      int rc);
+
 void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
@@ -282,7 +317,6 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
     uint32_t domid = bl->domid;
     char *logfile_tmp = NULL;
     int rc, r;
-    const char *bootloader;
 
     libxl__bootloader_init(bl);
 
@@ -344,13 +378,38 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
         goto out;
     }
 
-    bl->diskpath = libxl__device_disk_local_attach(gc, bl->disk, &bl->localdisk,
-            info->blkdev_start);
-    if (!bl->diskpath) {
-        rc = ERROR_FAIL;
-        goto out;
+    bl->dls.ao = ao;
+    bl->dls.in_disk = bl->disk;
+    bl->dls.blkdev_start = info->blkdev_start;
+    bl->dls.callback = bootloader_disk_attached_cb;
+    libxl__device_disk_local_attach(egc, &bl->dls);
+    return;
+
+ out:
+    assert(rc);
+ out_ok:
+    free(logfile_tmp);
+    bootloader_callback(egc, bl, rc);
+}
+
+static void bootloader_disk_attached_cb(libxl__egc *egc,
+                                        libxl__disk_local_state *dls,
+                                        int rc)
+{
+    STATE_AO_GC(dls->ao);
+    libxl__bootloader_state *bl = CONTAINER_OF(dls, *bl, dls);
+    const libxl_domain_build_info *info = bl->info;
+    const char *bootloader;
+
+    if (rc) {
+        LOG(ERROR, "failed to attach local disk for bootloader execution");
+        dls->callback = bootloader_disk_failed_cb;
+        libxl__device_disk_local_detach(egc, dls);
+        return;
     }
 
+    bl->diskpath = bl->dls.diskpath;
+
     LOG(DEBUG, "Config bootloader value: %s", info->u.pv.bootloader);
 
     if ( !strcmp(info->u.pv.bootloader, "/usr/bin/pygrub") )
@@ -389,11 +448,23 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
  out:
     assert(rc);
- out_ok:
-    free(logfile_tmp);
     bootloader_callback(egc, bl, rc);
 }
 
+static void bootloader_disk_failed_cb(libxl__egc *egc,
+                                      libxl__disk_local_state *dls,
+                                      int rc)
+{
+    STATE_AO_GC(dls->ao);
+    libxl__bootloader_state *bl = CONTAINER_OF(dls, *bl, dls);
+
+    if (rc) {
+        LOG(ERROR, "failed to detach locally attached disk");
+    }
+
+    bootloader_callback(egc, bl, ERROR_FAIL);
+}
+
 static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
 {
     libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0000d6b..85c21b4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1245,17 +1245,6 @@ _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
 _hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
         xs_transaction_t t, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
-        const libxl_device_disk *in_disk,
-        libxl_device_disk *new_disk,
-        const char *blkdev_start);
-_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
-        libxl_device_disk *disk);
-
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
@@ -1775,6 +1764,35 @@ struct libxl__ao_devices {
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*----- local disk attach: attach a disk locally to run the bootloader -----*/
+
+typedef struct libxl__disk_local_state libxl__disk_local_state;
+typedef void libxl__disk_local_state_callback(libxl__egc*,
+                                              libxl__disk_local_state*,
+                                              int rc);
+
+struct libxl__disk_local_state {
+    /* filled by the user */
+    libxl__ao *ao;
+    const libxl_device_disk *in_disk;
+    libxl_device_disk disk;
+    const char *blkdev_start;
+    libxl__disk_local_state_callback *callback;
+    /* filled by libxl__device_disk_local_attach */
+    char *diskpath;
+    /* private for implementation of local detach */
+    libxl__ao_device aodev;
+};
+
+/*
+ * Make a disk available in this (the control) domain. Calls dls->callback
+ * when finished.
+ */
+_hidden void libxl__device_disk_local_attach(libxl__egc *egc,
+                                             libxl__disk_local_state *dls);
+_hidden void libxl__device_disk_local_detach(libxl__egc *egc,
+                                             libxl__disk_local_state *dls);
+
 /*----- datacopier: copies data from one fd to another -----*/
 
 typedef struct libxl__datacopier_state libxl__datacopier_state;
@@ -1872,7 +1890,7 @@ struct libxl__bootloader_state {
      * the caller using libxl__device_disk_local_detach, but only
      * after the domain's kernel and initramfs have been loaded into
      * memory and the file references disposed of. */
-    libxl_device_disk localdisk;
+    libxl__disk_local_state dls;
     uint32_t domid;
     /* outputs:
      *  - caller must initialise kernel and ramdisk to point to file
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93D-0004Z2-BI; Thu, 14 Jun 2012 12:21:23 +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 1Sf93B-0004Xd-B9
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:21 +0000
Received: from [85.158.138.51:59219] by server-9.bemta-3.messagelabs.com id
	6D/A4-10419-047D9DF4; Thu, 14 Jun 2012 12:21:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339676478!27639891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20980 invoked from network); 14 Jun 2012 12:21:19 -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;
	14 Jun 2012 12:21:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067772"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Ix;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:07 +0100
Message-ID: <1339676475-33265-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 05/13] libxl: convert
	libxl__device_disk_local_attach to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be needed in future patches, when libxl__device_disk_add
becomes async also. Create a new status structure that defines the
local attach of a disk device and use it in
libxl__device_disk_local_attach.

This is done in this patch to split the changes introduced when
libxl__device_disk_add becomes async.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c            |   91 +++++++++++++++++++++++++++----------
 tools/libxl/libxl_bootloader.c |   97 ++++++++++++++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h   |   42 ++++++++++++-----
 3 files changed, 181 insertions(+), 49 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3ad1931..43affd1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2027,20 +2027,20 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,
     return NULL;
 }
 
-char * libxl__device_disk_local_attach(libxl__gc *gc,
-        const libxl_device_disk *in_disk,
-        libxl_device_disk *disk,
-        const char *blkdev_start)
+void libxl__device_disk_local_attach(libxl__egc *egc,
+                                     libxl__disk_local_state *dls)
 {
-    libxl_ctx *ctx = gc->owner;
+    STATE_AO_GC(dls->ao);
+    libxl_ctx *ctx = CTX;
     char *dev = NULL, *be_path = NULL;
-    char *ret = NULL;
     int rc, xs_ret;
     libxl__device device;
     xs_transaction_t t = XBT_NULL;
+    const libxl_device_disk *in_disk = dls->in_disk;
+    libxl_device_disk *disk = &dls->disk;
+    const char *blkdev_start = dls->blkdev_start;
 
-    if (in_disk->pdev_path == NULL)
-        return NULL;
+    assert(in_disk->pdev_path);
 
     memcpy(disk, in_disk, sizeof(libxl_device_disk));
     disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path);
@@ -2076,6 +2076,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
             default:
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                            "unrecognized disk format: %d", disk->format);
+                rc = ERROR_FAIL;
                 break;
             }
             break;
@@ -2085,15 +2086,18 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
                     t = xs_transaction_start(ctx->xsh);
                     if (t == XBT_NULL) {
                         LOG(ERROR, "failed to start a xenstore transaction");
+                        rc = ERROR_FAIL;
                         goto out;
                     }
                     disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t);
                     if (disk->vdev == NULL) {
                         LOG(ERROR, "libxl__alloc_vdev failed");
+                        rc = ERROR_FAIL;
                         goto out;
                     }
-                    if (libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID,
-                                t, disk)) {
+                    rc = libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID,
+                                                t, disk);
+                    if (rc) {
                         LOG(ERROR, "libxl_device_disk_add failed");
                         goto out;
                     }
@@ -2102,6 +2106,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
                 t = XBT_NULL;
                 if (xs_ret == 0) {
                     LOGE(ERROR, "xenstore transaction failed");
+                    rc = ERROR_FAIL;
                     goto out;
                 }
                 dev = GCSPRINTF("/dev/%s", disk->vdev);
@@ -2113,6 +2118,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
                 "type: %d", disk->backend);
+            rc = ERROR_FAIL;
             break;
     }
 
@@ -2126,42 +2132,79 @@ char * libxl__device_disk_local_attach(libxl__gc *gc,
             goto out;
     }
     if (dev != NULL)
-        ret = strdup(dev);
-    return ret;
+        dls->diskpath = strdup(dev);
+
+    dls->callback(egc, dls, 0);
+    return;
 
  out:
+    assert(rc);
     if (t != XBT_NULL)
         xs_transaction_end(ctx->xsh, t, 1);
-    else
-        libxl__device_disk_local_detach(gc, disk);
-    return NULL;
+    dls->callback(egc, dls, rc);
 }
 
-int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
+/* Callbacks for local detach */
+
+static void local_device_detach_cb(libxl__egc *egc, libxl__ao_device *aodev);
+
+void libxl__device_disk_local_detach(libxl__egc *egc,
+                                     libxl__disk_local_state *dls)
 {
+    STATE_AO_GC(dls->ao);
     int rc = 0;
+    libxl_device_disk *disk = &dls->disk;
+    libxl__device *device;
+    libxl__ao_device *aodev = &dls->aodev;
 
     switch (disk->backend) {
         case LIBXL_DISK_BACKEND_QDISK:
             if (disk->vdev != NULL) {
-                libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
-                        disk, 0);
-                /* fixme-ao */
-                rc = libxl_device_disk_destroy(gc->owner,
-                        LIBXL_TOOLSTACK_DOMID, disk, 0);
+                GCNEW(device);
+                rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID,
+                                             disk, device);
+                if (rc != 0) goto out;
+
+                libxl__prepare_ao_device(ao, aodev);
+                aodev->action = DEVICE_DISCONNECT;
+                aodev->dev = device;
+                aodev->callback = local_device_detach_cb;
+                aodev->force = 0;
+                libxl__initiate_device_remove(egc, aodev);
             }
-            break;
+            return;
         default:
             /*
              * Nothing to do for PHYSTYPE_PHY.
              * For other device types assume that the blktap2 process is
              * needed by the soon to be started domain and do nothing.
              */
-            break;
+            dls->callback(egc, dls, rc);
+            return;
     }
 
+out:
+    assert(rc);
+    dls->callback(egc, dls, rc);
+    return;
+}
 
-    return rc;
+static void local_device_detach_cb(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    libxl__disk_local_state *dls = CONTAINER_OF(aodev, *dls, aodev);
+
+    if (aodev->rc) {
+        LOGE(ERROR, "unable to %s %s with id %u",
+                    aodev->action == DEVICE_CONNECT ? "add" : "remove",
+                    libxl__device_kind_to_string(aodev->dev->kind),
+                    aodev->dev->devid);
+        goto out;
+    }
+
+out:
+    dls->callback(egc, dls, aodev->rc);
+    return;
 }
 
 /******************************************************************************/
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 7ebc0df..182a975 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -224,11 +224,6 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl)
     if (bl->outputpath) libxl__remove_file(gc, bl->outputpath);
     if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir);
 
-    if (bl->diskpath) {
-        libxl__device_disk_local_detach(gc, &bl->localdisk);
-        free(bl->diskpath);
-        bl->diskpath = 0;
-    }
     libxl__domaindeathcheck_stop(gc,&bl->deathcheck);
     libxl__datacopier_kill(&bl->keystrokes);
     libxl__datacopier_kill(&bl->display);
@@ -249,10 +244,40 @@ static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl)
     bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid);
 }
 
+/* Callbacks */
+
+static void bootloader_fisnihed_cb(libxl__egc *egc,
+                                   libxl__disk_local_state *dls,
+                                   int rc);
+
 static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
                                 int rc)
 {
     bootloader_cleanup(egc, bl);
+
+    if (bl->diskpath) {
+        bl->dls.callback = bootloader_fisnihed_cb;
+        libxl__device_disk_local_detach(egc, &bl->dls);
+        return;
+    }
+
+    bl->callback(egc, bl, rc);
+}
+
+static void bootloader_fisnihed_cb(libxl__egc *egc,
+                                   libxl__disk_local_state *dls,
+                                   int rc)
+{
+    STATE_AO_GC(dls->ao);
+    libxl__bootloader_state *bl = CONTAINER_OF(dls, *bl, dls);
+
+    free(bl->diskpath);
+    bl->diskpath = 0;
+
+    if (rc) {
+        LOG(ERROR, "unable to detach locally attached disk");
+    }
+
     bl->callback(egc, bl, rc);
 }
 
@@ -275,6 +300,16 @@ static void bootloader_abort(libxl__egc *egc,
 
 /*----- main flow of control -----*/
 
+/* Callbacks */
+
+static void bootloader_disk_attached_cb(libxl__egc *egc,
+                                        libxl__disk_local_state *dls,
+                                        int rc);
+
+static void bootloader_disk_failed_cb(libxl__egc *egc,
+                                      libxl__disk_local_state *dls,
+                                      int rc);
+
 void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 {
     STATE_AO_GC(bl->ao);
@@ -282,7 +317,6 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
     uint32_t domid = bl->domid;
     char *logfile_tmp = NULL;
     int rc, r;
-    const char *bootloader;
 
     libxl__bootloader_init(bl);
 
@@ -344,13 +378,38 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
         goto out;
     }
 
-    bl->diskpath = libxl__device_disk_local_attach(gc, bl->disk, &bl->localdisk,
-            info->blkdev_start);
-    if (!bl->diskpath) {
-        rc = ERROR_FAIL;
-        goto out;
+    bl->dls.ao = ao;
+    bl->dls.in_disk = bl->disk;
+    bl->dls.blkdev_start = info->blkdev_start;
+    bl->dls.callback = bootloader_disk_attached_cb;
+    libxl__device_disk_local_attach(egc, &bl->dls);
+    return;
+
+ out:
+    assert(rc);
+ out_ok:
+    free(logfile_tmp);
+    bootloader_callback(egc, bl, rc);
+}
+
+static void bootloader_disk_attached_cb(libxl__egc *egc,
+                                        libxl__disk_local_state *dls,
+                                        int rc)
+{
+    STATE_AO_GC(dls->ao);
+    libxl__bootloader_state *bl = CONTAINER_OF(dls, *bl, dls);
+    const libxl_domain_build_info *info = bl->info;
+    const char *bootloader;
+
+    if (rc) {
+        LOG(ERROR, "failed to attach local disk for bootloader execution");
+        dls->callback = bootloader_disk_failed_cb;
+        libxl__device_disk_local_detach(egc, dls);
+        return;
     }
 
+    bl->diskpath = bl->dls.diskpath;
+
     LOG(DEBUG, "Config bootloader value: %s", info->u.pv.bootloader);
 
     if ( !strcmp(info->u.pv.bootloader, "/usr/bin/pygrub") )
@@ -389,11 +448,23 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl)
 
  out:
     assert(rc);
- out_ok:
-    free(logfile_tmp);
     bootloader_callback(egc, bl, rc);
 }
 
+static void bootloader_disk_failed_cb(libxl__egc *egc,
+                                      libxl__disk_local_state *dls,
+                                      int rc)
+{
+    STATE_AO_GC(dls->ao);
+    libxl__bootloader_state *bl = CONTAINER_OF(dls, *bl, dls);
+
+    if (rc) {
+        LOG(ERROR, "failed to detach locally attached disk");
+    }
+
+    bootloader_callback(egc, bl, ERROR_FAIL);
+}
+
 static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op)
 {
     libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0000d6b..85c21b4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1245,17 +1245,6 @@ _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
 _hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
         xs_transaction_t t, libxl_device_disk *disk);
 
-/*
- * Make a disk available in this (the control) domain. Returns path to
- * a device.
- */
-_hidden char * libxl__device_disk_local_attach(libxl__gc *gc,
-        const libxl_device_disk *in_disk,
-        libxl_device_disk *new_disk,
-        const char *blkdev_start);
-_hidden int libxl__device_disk_local_detach(libxl__gc *gc,
-        libxl_device_disk *disk);
-
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
 struct libxl__xen_console_reader {
@@ -1775,6 +1764,35 @@ struct libxl__ao_devices {
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*----- local disk attach: attach a disk locally to run the bootloader -----*/
+
+typedef struct libxl__disk_local_state libxl__disk_local_state;
+typedef void libxl__disk_local_state_callback(libxl__egc*,
+                                              libxl__disk_local_state*,
+                                              int rc);
+
+struct libxl__disk_local_state {
+    /* filled by the user */
+    libxl__ao *ao;
+    const libxl_device_disk *in_disk;
+    libxl_device_disk disk;
+    const char *blkdev_start;
+    libxl__disk_local_state_callback *callback;
+    /* filled by libxl__device_disk_local_attach */
+    char *diskpath;
+    /* private for implementation of local detach */
+    libxl__ao_device aodev;
+};
+
+/*
+ * Make a disk available in this (the control) domain. Calls dls->callback
+ * when finished.
+ */
+_hidden void libxl__device_disk_local_attach(libxl__egc *egc,
+                                             libxl__disk_local_state *dls);
+_hidden void libxl__device_disk_local_detach(libxl__egc *egc,
+                                             libxl__disk_local_state *dls);
+
 /*----- datacopier: copies data from one fd to another -----*/
 
 typedef struct libxl__datacopier_state libxl__datacopier_state;
@@ -1872,7 +1890,7 @@ struct libxl__bootloader_state {
      * the caller using libxl__device_disk_local_detach, but only
      * after the domain's kernel and initramfs have been loaded into
      * memory and the file references disposed of. */
-    libxl_device_disk localdisk;
+    libxl__disk_local_state dls;
     uint32_t domid;
     /* outputs:
      *  - caller must initialise kernel and ramdisk to point to file
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf93A-0004XR-Do; Thu, 14 Jun 2012 12:21:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Sf939-0004X9-3B
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:19 +0000
Received: from [85.158.139.83:24805] by server-3.bemta-5.messagelabs.com id
	3B/4F-03367-E37D9DF4; Thu, 14 Jun 2012 12:21:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 658 invoked from network); 14 Jun 2012 12:21:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067770"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Np;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:11 +0100
Message-ID: <1339676475-33265-10-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 09/13] libxl: rename _IOEMU nic type to
	VIF_IOEMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change will avoid the confusion caused by the fact that IOEMU
means both PV and TAP network interfaces.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c         |    4 ++--
 tools/libxl/libxl_dm.c      |    8 ++++----
 tools/libxl/libxl_types.idl |    2 +-
 tools/libxl/xl_cmdimpl.c    |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2d7a7e4..20c1340 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2296,7 +2296,7 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
                                   libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
-        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+        nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
     return 0;
 }
 
@@ -2606,7 +2606,7 @@ const char *libxl__device_nic_devname(libxl__gc *gc,
     switch (type) {
     case LIBXL_NIC_TYPE_VIF:
         return GCSPRINTF("vif%u.%d", domid, devid);
-    case LIBXL_NIC_TYPE_IOEMU:
+    case LIBXL_NIC_TYPE_VIF_IOEMU:
         return GCSPRINTF("vif%u.%d" TAP_DEVICE_SUFFIX, domid, devid);
     default:
         abort();
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5631f12..45a1a7f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -206,12 +206,12 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                               NULL);
         }
         for (i = 0; i < num_vifs; i++) {
-            if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
+            if (vifs[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 const char *ifname = libxl__device_nic_devname(gc,
                                                 domid, vifs[i].devid,
-                                                LIBXL_NIC_TYPE_IOEMU);
+                                                LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_vappend(dm_args,
                                   "-net",
                                   GCSPRINTF(
@@ -452,12 +452,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                          b_info->max_vcpus));
         }
         for (i = 0; i < num_vifs; i++) {
-            if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
+            if (vifs[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 const char *ifname = libxl__device_nic_devname(gc,
                                                 guest_domid, vifs[i].devid,
-                                                LIBXL_NIC_TYPE_IOEMU);
+                                                LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
                    libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 1ede19e..80394e1 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -60,7 +60,7 @@ libxl_disk_backend = Enumeration("disk_backend", [
     ])
 
 libxl_nic_type = Enumeration("nic_type", [
-    (1, "IOEMU"),
+    (1, "VIF_IOEMU"),
     (2, "VIF"),
     ])
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index fd980b1..66b9d38 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -971,7 +971,7 @@ static void parse_config_data(const char *config_source,
                     nic->bridge = strdup(p2 + 1);
                 } else if (!strcmp(p, "type")) {
                     if (!strcmp(p2 + 1, "ioemu"))
-                        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+                        nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
                     else
                         nic->nictype = LIBXL_NIC_TYPE_VIF;
                 } else if (!strcmp(p, "ip")) {
@@ -5137,7 +5137,7 @@ int main_networkattach(int argc, char **argv)
             if (!strcmp("vif", oparg)) {
                 nic.nictype = LIBXL_NIC_TYPE_VIF;
             } else if (!strcmp("ioemu", oparg)) {
-                nic.nictype = LIBXL_NIC_TYPE_IOEMU;
+                nic.nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
             } else {
                 fprintf(stderr, "Invalid parameter `type'.\n");
                 return 1;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf93A-0004XR-Do; Thu, 14 Jun 2012 12:21:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Sf939-0004X9-3B
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:19 +0000
Received: from [85.158.139.83:24805] by server-3.bemta-5.messagelabs.com id
	3B/4F-03367-E37D9DF4; Thu, 14 Jun 2012 12:21:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 658 invoked from network); 14 Jun 2012 12:21:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067770"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Np;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:11 +0100
Message-ID: <1339676475-33265-10-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 09/13] libxl: rename _IOEMU nic type to
	VIF_IOEMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change will avoid the confusion caused by the fact that IOEMU
means both PV and TAP network interfaces.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c         |    4 ++--
 tools/libxl/libxl_dm.c      |    8 ++++----
 tools/libxl/libxl_types.idl |    2 +-
 tools/libxl/xl_cmdimpl.c    |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2d7a7e4..20c1340 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2296,7 +2296,7 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
                                   libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
-        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+        nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
     return 0;
 }
 
@@ -2606,7 +2606,7 @@ const char *libxl__device_nic_devname(libxl__gc *gc,
     switch (type) {
     case LIBXL_NIC_TYPE_VIF:
         return GCSPRINTF("vif%u.%d", domid, devid);
-    case LIBXL_NIC_TYPE_IOEMU:
+    case LIBXL_NIC_TYPE_VIF_IOEMU:
         return GCSPRINTF("vif%u.%d" TAP_DEVICE_SUFFIX, domid, devid);
     default:
         abort();
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5631f12..45a1a7f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -206,12 +206,12 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                               NULL);
         }
         for (i = 0; i < num_vifs; i++) {
-            if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
+            if (vifs[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 const char *ifname = libxl__device_nic_devname(gc,
                                                 domid, vifs[i].devid,
-                                                LIBXL_NIC_TYPE_IOEMU);
+                                                LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_vappend(dm_args,
                                   "-net",
                                   GCSPRINTF(
@@ -452,12 +452,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                                          b_info->max_vcpus));
         }
         for (i = 0; i < num_vifs; i++) {
-            if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
+            if (vifs[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU) {
                 char *smac = libxl__sprintf(gc,
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 const char *ifname = libxl__device_nic_devname(gc,
                                                 guest_domid, vifs[i].devid,
-                                                LIBXL_NIC_TYPE_IOEMU);
+                                                LIBXL_NIC_TYPE_VIF_IOEMU);
                 flexarray_append(dm_args, "-device");
                 flexarray_append(dm_args,
                    libxl__sprintf(gc, "%s,id=nic%d,netdev=net%d,mac=%s",
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 1ede19e..80394e1 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -60,7 +60,7 @@ libxl_disk_backend = Enumeration("disk_backend", [
     ])
 
 libxl_nic_type = Enumeration("nic_type", [
-    (1, "IOEMU"),
+    (1, "VIF_IOEMU"),
     (2, "VIF"),
     ])
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index fd980b1..66b9d38 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -971,7 +971,7 @@ static void parse_config_data(const char *config_source,
                     nic->bridge = strdup(p2 + 1);
                 } else if (!strcmp(p, "type")) {
                     if (!strcmp(p2 + 1, "ioemu"))
-                        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+                        nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
                     else
                         nic->nictype = LIBXL_NIC_TYPE_VIF;
                 } else if (!strcmp(p, "ip")) {
@@ -5137,7 +5137,7 @@ int main_networkattach(int argc, char **argv)
             if (!strcmp("vif", oparg)) {
                 nic.nictype = LIBXL_NIC_TYPE_VIF;
             } else if (!strcmp("ioemu", oparg)) {
-                nic.nictype = LIBXL_NIC_TYPE_IOEMU;
+                nic.nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
             } else {
                 fprintf(stderr, "Invalid parameter `type'.\n");
                 return 1;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf93M-0004eV-0P; Thu, 14 Jun 2012 12:21:32 +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 1Sf93K-0004dP-Ng
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:31 +0000
Received: from [193.109.254.147:46334] by server-4.bemta-14.messagelabs.com id
	72/0B-27598-947D9DF4; Thu, 14 Jun 2012 12:21:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339676472!4077734!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13181 invoked from network); 14 Jun 2012 12:21:16 -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;
	14 Jun 2012 12:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067769"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-IQ;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:06 +0100
Message-ID: <1339676475-33265-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 04/13] libxl: move bootloader data strucutres
	and 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

Move bootloader and related data after all the device stuff, since
libxl__bootloader_state will depend on libxl__ao_device (to perform
the local attach of a device).

This is pure code motion.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_internal.h |  166 +++++++++++++++++++++---------------------
 1 files changed, 83 insertions(+), 83 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8478606..0000d6b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1692,6 +1692,89 @@ _hidden const char *libxl__xen_script_dir_path(void);
 _hidden const char *libxl__lock_dir_path(void);
 _hidden const char *libxl__run_dir_path(void);
 
+/*----- device addition/removal -----*/
+
+/* Action to perform (either connect or disconnect) */
+typedef enum {
+    DEVICE_CONNECT,
+    DEVICE_DISCONNECT
+} libxl__device_action;
+
+typedef struct libxl__ao_device libxl__ao_device;
+typedef struct libxl__ao_devices libxl__ao_devices;
+typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
+
+/* This functions sets the necessary libxl__ao_device struct values to use
+ * safely inside functions. It marks the operation as "active"
+ * since we need to be sure that all device status structs are set
+ * to active before start queueing events, or we might call
+ * ao_complete before all devices had finished
+ *
+ * libxl__initiate_device_{remove/addition} should not be called without
+ * calling libxl__prepare_ao_device first, since it initializes the private
+ * fields of the struct libxl__ao_device to what this functions expect.
+ *
+ * Once _prepare has been called on a libxl__ao_device, it is safe to just
+ * discard this struct, there's no need to call any destroy function.
+ * _prepare can also be called multiple times with the same libxl__ao_device.
+ */
+_hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
+
+/* Prepare a bunch of devices for addition/removal. Every ao_device in
+ * ao_devices is set to 'active', and the ao_device 'base' filed is set to
+ * the one pointed by aodevs.
+ */
+_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
+                                       libxl__ao_devices *aodevs);
+
+/* Generic callback to use when adding/removing several devices, this will
+ * check if the given aodev is the last one, and call the callback in the
+ * parent libxl__ao_devices struct, passing the appropiate error if found.
+ */
+_hidden void libxl__ao_devices_callback(libxl__egc *egc,
+                                        libxl__ao_device *aodev);
+
+struct libxl__ao_device {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl__device_action action;
+    libxl__device *dev;
+    int force;
+    libxl__device_callback *callback;
+    /* private for implementation */
+    int active;
+    int rc;
+    libxl__ev_devstate backend_ds;
+    /* Used internally to have a reference to the upper libxl__ao_devices
+     * struct when present */
+    libxl__ao_devices *aodevs;
+};
+
+/* Helper struct to simply the plug/unplug of multiple devices at the same
+ * time.
+ *
+ * This structure holds several devices, and the callback is only called
+ * when all the devices inside of the array have finished.
+ */
+typedef void libxl__devices_callback(libxl__egc*, libxl__ao_devices*, int rc);
+struct libxl__ao_devices {
+    libxl__ao_device *array;
+    int size;
+    libxl__devices_callback *callback;
+};
+
+/* Arranges that dev will be removed to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done (or an error happens), the callback in
+ * aodev->callback will be called.
+ *
+ * The libxl__ao_device passed to this function should be
+ * prepared using libxl__prepare_ao_device prior to calling
+ * this function.
+ */
+_hidden void libxl__initiate_device_remove(libxl__egc *egc,
+                                           libxl__ao_device *aodev);
+
 /*----- datacopier: copies data from one fd to another -----*/
 
 typedef struct libxl__datacopier_state libxl__datacopier_state;
@@ -1818,89 +1901,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
-/*----- device addition/removal -----*/
-
-/* Action to perform (either connect or disconnect) */
-typedef enum {
-    DEVICE_CONNECT,
-    DEVICE_DISCONNECT
-} libxl__device_action;
-
-typedef struct libxl__ao_device libxl__ao_device;
-typedef struct libxl__ao_devices libxl__ao_devices;
-typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
-
-/* This functions sets the necessary libxl__ao_device struct values to use
- * safely inside functions. It marks the operation as "active"
- * since we need to be sure that all device status structs are set
- * to active before start queueing events, or we might call
- * ao_complete before all devices had finished
- *
- * libxl__initiate_device_{remove/addition} should not be called without
- * calling libxl__prepare_ao_device first, since it initializes the private
- * fields of the struct libxl__ao_device to what this functions expect.
- *
- * Once _prepare has been called on a libxl__ao_device, it is safe to just
- * discard this struct, there's no need to call any destroy function.
- * _prepare can also be called multiple times with the same libxl__ao_device.
- */
-_hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
-
-/* Prepare a bunch of devices for addition/removal. Every ao_device in
- * ao_devices is set to 'active', and the ao_device 'base' filed is set to
- * the one pointed by aodevs.
- */
-_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
-                                       libxl__ao_devices *aodevs);
-
-/* Generic callback to use when adding/removing several devices, this will
- * check if the given aodev is the last one, and call the callback in the
- * parent libxl__ao_devices struct, passing the appropiate error if found.
- */
-_hidden void libxl__ao_devices_callback(libxl__egc *egc,
-                                        libxl__ao_device *aodev);
-
-struct libxl__ao_device {
-    /* filled in by user */
-    libxl__ao *ao;
-    libxl__device_action action;
-    libxl__device *dev;
-    int force;
-    libxl__device_callback *callback;
-    /* private for implementation */
-    int active;
-    int rc;
-    libxl__ev_devstate backend_ds;
-    /* Used internally to have a reference to the upper libxl__ao_devices
-     * struct when present */
-    libxl__ao_devices *aodevs;
-};
-
-/* Helper struct to simply the plug/unplug of multiple devices at the same
- * time.
- *
- * This structure holds several devices, and the callback is only called
- * when all the devices inside of the array have finished.
- */
-typedef void libxl__devices_callback(libxl__egc*, libxl__ao_devices*, int rc);
-struct libxl__ao_devices {
-    libxl__ao_device *array;
-    int size;
-    libxl__devices_callback *callback;
-};
-
-/* Arranges that dev will be removed to the guest, and the
- * hotplug scripts will be executed (if necessary). When
- * this is done (or an error happens), the callback in
- * aodev->callback will be called.
- *
- * The libxl__ao_device passed to this function should be
- * prepared using libxl__prepare_ao_device prior to calling
- * this function.
- */
-_hidden void libxl__initiate_device_remove(libxl__egc *egc,
-                                           libxl__ao_device *aodev);
-
 /*----- Domain destruction -----*/
 
 /* Domain destruction has been split into two functions:
-- 
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 Jun 14 12:21:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf93M-0004eV-0P; Thu, 14 Jun 2012 12:21:32 +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 1Sf93K-0004dP-Ng
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:31 +0000
Received: from [193.109.254.147:46334] by server-4.bemta-14.messagelabs.com id
	72/0B-27598-947D9DF4; Thu, 14 Jun 2012 12:21:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339676472!4077734!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13181 invoked from network); 14 Jun 2012 12:21:16 -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;
	14 Jun 2012 12:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067769"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-IQ;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:06 +0100
Message-ID: <1339676475-33265-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 04/13] libxl: move bootloader data strucutres
	and 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

Move bootloader and related data after all the device stuff, since
libxl__bootloader_state will depend on libxl__ao_device (to perform
the local attach of a device).

This is pure code motion.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_internal.h |  166 +++++++++++++++++++++---------------------
 1 files changed, 83 insertions(+), 83 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8478606..0000d6b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1692,6 +1692,89 @@ _hidden const char *libxl__xen_script_dir_path(void);
 _hidden const char *libxl__lock_dir_path(void);
 _hidden const char *libxl__run_dir_path(void);
 
+/*----- device addition/removal -----*/
+
+/* Action to perform (either connect or disconnect) */
+typedef enum {
+    DEVICE_CONNECT,
+    DEVICE_DISCONNECT
+} libxl__device_action;
+
+typedef struct libxl__ao_device libxl__ao_device;
+typedef struct libxl__ao_devices libxl__ao_devices;
+typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
+
+/* This functions sets the necessary libxl__ao_device struct values to use
+ * safely inside functions. It marks the operation as "active"
+ * since we need to be sure that all device status structs are set
+ * to active before start queueing events, or we might call
+ * ao_complete before all devices had finished
+ *
+ * libxl__initiate_device_{remove/addition} should not be called without
+ * calling libxl__prepare_ao_device first, since it initializes the private
+ * fields of the struct libxl__ao_device to what this functions expect.
+ *
+ * Once _prepare has been called on a libxl__ao_device, it is safe to just
+ * discard this struct, there's no need to call any destroy function.
+ * _prepare can also be called multiple times with the same libxl__ao_device.
+ */
+_hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
+
+/* Prepare a bunch of devices for addition/removal. Every ao_device in
+ * ao_devices is set to 'active', and the ao_device 'base' filed is set to
+ * the one pointed by aodevs.
+ */
+_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
+                                       libxl__ao_devices *aodevs);
+
+/* Generic callback to use when adding/removing several devices, this will
+ * check if the given aodev is the last one, and call the callback in the
+ * parent libxl__ao_devices struct, passing the appropiate error if found.
+ */
+_hidden void libxl__ao_devices_callback(libxl__egc *egc,
+                                        libxl__ao_device *aodev);
+
+struct libxl__ao_device {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl__device_action action;
+    libxl__device *dev;
+    int force;
+    libxl__device_callback *callback;
+    /* private for implementation */
+    int active;
+    int rc;
+    libxl__ev_devstate backend_ds;
+    /* Used internally to have a reference to the upper libxl__ao_devices
+     * struct when present */
+    libxl__ao_devices *aodevs;
+};
+
+/* Helper struct to simply the plug/unplug of multiple devices at the same
+ * time.
+ *
+ * This structure holds several devices, and the callback is only called
+ * when all the devices inside of the array have finished.
+ */
+typedef void libxl__devices_callback(libxl__egc*, libxl__ao_devices*, int rc);
+struct libxl__ao_devices {
+    libxl__ao_device *array;
+    int size;
+    libxl__devices_callback *callback;
+};
+
+/* Arranges that dev will be removed to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done (or an error happens), the callback in
+ * aodev->callback will be called.
+ *
+ * The libxl__ao_device passed to this function should be
+ * prepared using libxl__prepare_ao_device prior to calling
+ * this function.
+ */
+_hidden void libxl__initiate_device_remove(libxl__egc *egc,
+                                           libxl__ao_device *aodev);
+
 /*----- datacopier: copies data from one fd to another -----*/
 
 typedef struct libxl__datacopier_state libxl__datacopier_state;
@@ -1818,89 +1901,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
-/*----- device addition/removal -----*/
-
-/* Action to perform (either connect or disconnect) */
-typedef enum {
-    DEVICE_CONNECT,
-    DEVICE_DISCONNECT
-} libxl__device_action;
-
-typedef struct libxl__ao_device libxl__ao_device;
-typedef struct libxl__ao_devices libxl__ao_devices;
-typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
-
-/* This functions sets the necessary libxl__ao_device struct values to use
- * safely inside functions. It marks the operation as "active"
- * since we need to be sure that all device status structs are set
- * to active before start queueing events, or we might call
- * ao_complete before all devices had finished
- *
- * libxl__initiate_device_{remove/addition} should not be called without
- * calling libxl__prepare_ao_device first, since it initializes the private
- * fields of the struct libxl__ao_device to what this functions expect.
- *
- * Once _prepare has been called on a libxl__ao_device, it is safe to just
- * discard this struct, there's no need to call any destroy function.
- * _prepare can also be called multiple times with the same libxl__ao_device.
- */
-_hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
-
-/* Prepare a bunch of devices for addition/removal. Every ao_device in
- * ao_devices is set to 'active', and the ao_device 'base' filed is set to
- * the one pointed by aodevs.
- */
-_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
-                                       libxl__ao_devices *aodevs);
-
-/* Generic callback to use when adding/removing several devices, this will
- * check if the given aodev is the last one, and call the callback in the
- * parent libxl__ao_devices struct, passing the appropiate error if found.
- */
-_hidden void libxl__ao_devices_callback(libxl__egc *egc,
-                                        libxl__ao_device *aodev);
-
-struct libxl__ao_device {
-    /* filled in by user */
-    libxl__ao *ao;
-    libxl__device_action action;
-    libxl__device *dev;
-    int force;
-    libxl__device_callback *callback;
-    /* private for implementation */
-    int active;
-    int rc;
-    libxl__ev_devstate backend_ds;
-    /* Used internally to have a reference to the upper libxl__ao_devices
-     * struct when present */
-    libxl__ao_devices *aodevs;
-};
-
-/* Helper struct to simply the plug/unplug of multiple devices at the same
- * time.
- *
- * This structure holds several devices, and the callback is only called
- * when all the devices inside of the array have finished.
- */
-typedef void libxl__devices_callback(libxl__egc*, libxl__ao_devices*, int rc);
-struct libxl__ao_devices {
-    libxl__ao_device *array;
-    int size;
-    libxl__devices_callback *callback;
-};
-
-/* Arranges that dev will be removed to the guest, and the
- * hotplug scripts will be executed (if necessary). When
- * this is done (or an error happens), the callback in
- * aodev->callback will be called.
- *
- * The libxl__ao_device passed to this function should be
- * prepared using libxl__prepare_ao_device prior to calling
- * this function.
- */
-_hidden void libxl__initiate_device_remove(libxl__egc *egc,
-                                           libxl__ao_device *aodev);
-
 /*----- Domain destruction -----*/
 
 /* Domain destruction has been split into two functions:
-- 
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 Jun 14 12:21:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf93M-0004ep-Cq; Thu, 14 Jun 2012 12:21:32 +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 1Sf93K-0004dN-J8
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:30 +0000
Received: from [193.109.254.147:46330] by server-10.bemta-14.messagelabs.com
	id 42/46-25709-947D9DF4; Thu, 14 Jun 2012 12:21:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339676472!4077734!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13333 invoked from network); 14 Jun 2012 12:21:17 -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;
	14 Jun 2012 12:21:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067771"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-NH;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:10 +0100
Message-ID: <1339676475-33265-9-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 08/13] libxl: add option to choose who
	executes hotplug scripts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 and option to xl.conf file to decide if hotplug scripts are
executed from the toolstack (xl) or from udev as it used to be in the
past.

This option is only introduced in this patch, but it has no effect
since the code to call hotplug scripts from libxl is introduced in a
latter patch.

This choice will be saved in "libxl/disable_udev", as specified in the
DISABLE_UDEV_PATH constant.

Changes since v2:

 * Change atoi(...) to !!atoi(...) to prevent returning negative
   values from xenstore (which will be handled as errors).

 * Check for errors on the return value of libxl__hotplug_settings.

Changes since v1:

 * Used an auxiliary function to check for the current setting.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5       |    8 ++++++++
 tools/examples/xl.conf       |    5 +++++
 tools/libxl/libxl_create.c   |   36 +++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |   19 +++++++++++++++++++
 tools/libxl/libxl_internal.h |    3 +++
 tools/libxl/libxl_types.idl  |    1 +
 tools/libxl/xl.c             |    4 ++++
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |    1 +
 9 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 149430c..23932be 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,14 @@ default.
 
 Default: C<1>
 
+=item B<run_hotplug_scripts=BOOLEAN>
+
+If disabled hotplug scripts will be called from udev, as it used to
+be in the previous releases. With the default option, hotplug scripts
+will be launched by xl directly.
+
+Default: C<1>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index ebf057c..28ab796 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -15,3 +15,8 @@
 
 # first block device to be used for temporary VM disk mounts
 #blkdev_start="xvda"
+
+# default option to run hotplug scripts from xl
+# if disabled the old behaviour will be used, and hotplug scripts will be
+# launched by udev.
+#run_hotplug_scripts=1
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 274f5d4..d47d1ea 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -404,7 +404,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags, ret, rc;
+    int flags, ret, rc, nb_vm;
     char *uuid_string;
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
@@ -525,6 +525,40 @@ retry_transaction:
             libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path),
                         rwperm, ARRAY_SIZE(rwperm));
 
+    if (libxl_list_vm(ctx, &nb_vm) < 0) {
+        LOG(ERROR, "cannot get number of running guests");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    int hotplug_setting = libxl__hotplug_settings(gc, t);
+    if (hotplug_setting < 0) {
+        LOG(ERROR, "unable to get current hotplug scripts execution setting");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (libxl_defbool_val(info->run_hotplug_scripts) != hotplug_setting &&
+        (nb_vm - 1)) {
+        LOG(ERROR, "cannot change hotplug execution option once set, "
+                    "please shutdown all guests before changing it");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (libxl_defbool_val(info->run_hotplug_scripts)) {
+        rc = libxl__xs_write(gc, t, DISABLE_UDEV_PATH, "1");
+        if (rc) {
+            LOGE(ERROR, "unable to write %s = 1", DISABLE_UDEV_PATH);
+            goto out;
+        }
+    } else {
+        rc = xs_rm(ctx->xsh, t, DISABLE_UDEV_PATH);
+        if (rc) {
+            LOGE(ERROR, "unable to delete %s", DISABLE_UDEV_PATH);
+            goto out;
+        }
+    }
+
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
 
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..bc56f21 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -346,6 +346,25 @@ libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
     return value;
 }
 
+int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t)
+{
+    int rc = 0;
+    char *val;
+
+    val = libxl__xs_read(gc, t, DISABLE_UDEV_PATH);
+    if (!val && errno != ENOENT) {
+        LOGE(ERROR, "cannot read %s from xenstore", DISABLE_UDEV_PATH);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!val) val = "0";
+
+    rc = !!atoi(val);
+
+out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d4726b..1350ba9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -88,6 +88,7 @@
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
 #define TAP_DEVICE_SUFFIX "-emu"
+#define DISABLE_UDEV_PATH "libxl/disable_udev"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -1415,6 +1416,8 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+/* Check how executes hotplug script currently */
+int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t);
 
 /*
  * Calling context and GC for event-generating functions:
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b727abb..1ede19e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -221,6 +221,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
+    ("run_hotplug_scripts",libxl_defbool),
     ], dir=DIR_IN)
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a5ada03..460a6df 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -39,6 +39,7 @@ int dryrun_only;
 int force_execution;
 int autoballoon = 1;
 char *blkdev_start;
+libxl_defbool run_hotplug_scripts;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -70,6 +71,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    libxl_defbool_setdefault(&run_hotplug_scripts, true);
+    xlu_cfg_get_defbool(config, "run_hotplug_scripts", &run_hotplug_scripts, 0);
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 59556b5..fddaecb 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -140,6 +140,7 @@ int xl_child_pid(xlchildnum); /* returns 0 if child struct is not in use */
 
 /* global options */
 extern int autoballoon;
+extern libxl_defbool run_hotplug_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 404c9c2..fd980b1 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -594,6 +594,7 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    c_info->run_hotplug_scripts = run_hotplug_scripts;
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
     if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
-- 
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 Jun 14 12:21:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf93M-0004ep-Cq; Thu, 14 Jun 2012 12:21:32 +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 1Sf93K-0004dN-J8
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:30 +0000
Received: from [193.109.254.147:46330] by server-10.bemta-14.messagelabs.com
	id 42/46-25709-947D9DF4; Thu, 14 Jun 2012 12:21:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339676472!4077734!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13333 invoked from network); 14 Jun 2012 12:21:17 -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;
	14 Jun 2012 12:21:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067771"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-NH;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:10 +0100
Message-ID: <1339676475-33265-9-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 08/13] libxl: add option to choose who
	executes hotplug scripts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 and option to xl.conf file to decide if hotplug scripts are
executed from the toolstack (xl) or from udev as it used to be in the
past.

This option is only introduced in this patch, but it has no effect
since the code to call hotplug scripts from libxl is introduced in a
latter patch.

This choice will be saved in "libxl/disable_udev", as specified in the
DISABLE_UDEV_PATH constant.

Changes since v2:

 * Change atoi(...) to !!atoi(...) to prevent returning negative
   values from xenstore (which will be handled as errors).

 * Check for errors on the return value of libxl__hotplug_settings.

Changes since v1:

 * Used an auxiliary function to check for the current setting.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/man/xl.conf.pod.5       |    8 ++++++++
 tools/examples/xl.conf       |    5 +++++
 tools/libxl/libxl_create.c   |   36 +++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |   19 +++++++++++++++++++
 tools/libxl/libxl_internal.h |    3 +++
 tools/libxl/libxl_types.idl  |    1 +
 tools/libxl/xl.c             |    4 ++++
 tools/libxl/xl.h             |    1 +
 tools/libxl/xl_cmdimpl.c     |    1 +
 9 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 149430c..23932be 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -55,6 +55,14 @@ default.
 
 Default: C<1>
 
+=item B<run_hotplug_scripts=BOOLEAN>
+
+If disabled hotplug scripts will be called from udev, as it used to
+be in the previous releases. With the default option, hotplug scripts
+will be launched by xl directly.
+
+Default: C<1>
+
 =item B<lockfile="PATH">
 
 Sets the path to the lock file used by xl to serialise certain
diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index ebf057c..28ab796 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -15,3 +15,8 @@
 
 # first block device to be used for temporary VM disk mounts
 #blkdev_start="xvda"
+
+# default option to run hotplug scripts from xl
+# if disabled the old behaviour will be used, and hotplug scripts will be
+# launched by udev.
+#run_hotplug_scripts=1
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 274f5d4..d47d1ea 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -404,7 +404,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags, ret, rc;
+    int flags, ret, rc, nb_vm;
     char *uuid_string;
     char *dom_path, *vm_path, *libxl_path;
     struct xs_permissions roperm[2];
@@ -525,6 +525,40 @@ retry_transaction:
             libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path),
                         rwperm, ARRAY_SIZE(rwperm));
 
+    if (libxl_list_vm(ctx, &nb_vm) < 0) {
+        LOG(ERROR, "cannot get number of running guests");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    int hotplug_setting = libxl__hotplug_settings(gc, t);
+    if (hotplug_setting < 0) {
+        LOG(ERROR, "unable to get current hotplug scripts execution setting");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (libxl_defbool_val(info->run_hotplug_scripts) != hotplug_setting &&
+        (nb_vm - 1)) {
+        LOG(ERROR, "cannot change hotplug execution option once set, "
+                    "please shutdown all guests before changing it");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (libxl_defbool_val(info->run_hotplug_scripts)) {
+        rc = libxl__xs_write(gc, t, DISABLE_UDEV_PATH, "1");
+        if (rc) {
+            LOGE(ERROR, "unable to write %s = 1", DISABLE_UDEV_PATH);
+            goto out;
+        }
+    } else {
+        rc = xs_rm(ctx->xsh, t, DISABLE_UDEV_PATH);
+        if (rc) {
+            LOGE(ERROR, "unable to delete %s", DISABLE_UDEV_PATH);
+            goto out;
+        }
+    }
+
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path), uuid_string, strlen(uuid_string));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));
 
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..bc56f21 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -346,6 +346,25 @@ libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
     return value;
 }
 
+int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t)
+{
+    int rc = 0;
+    char *val;
+
+    val = libxl__xs_read(gc, t, DISABLE_UDEV_PATH);
+    if (!val && errno != ENOENT) {
+        LOGE(ERROR, "cannot read %s from xenstore", DISABLE_UDEV_PATH);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (!val) val = "0";
+
+    rc = !!atoi(val);
+
+out:
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d4726b..1350ba9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -88,6 +88,7 @@
 #define STUBDOM_CONSOLE_SERIAL 3
 #define STUBDOM_SPECIAL_CONSOLES 3
 #define TAP_DEVICE_SUFFIX "-emu"
+#define DISABLE_UDEV_PATH "libxl/disable_udev"
 
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
@@ -1415,6 +1416,8 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+/* Check how executes hotplug script currently */
+int libxl__hotplug_settings(libxl__gc *gc, xs_transaction_t t);
 
 /*
  * Calling context and GC for event-generating functions:
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b727abb..1ede19e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -221,6 +221,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
+    ("run_hotplug_scripts",libxl_defbool),
     ], dir=DIR_IN)
 
 MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index a5ada03..460a6df 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -39,6 +39,7 @@ int dryrun_only;
 int force_execution;
 int autoballoon = 1;
 char *blkdev_start;
+libxl_defbool run_hotplug_scripts;
 char *lockfile;
 char *default_vifscript = NULL;
 char *default_bridge = NULL;
@@ -70,6 +71,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
+    libxl_defbool_setdefault(&run_hotplug_scripts, true);
+    xlu_cfg_get_defbool(config, "run_hotplug_scripts", &run_hotplug_scripts, 0);
+
     if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 59556b5..fddaecb 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -140,6 +140,7 @@ int xl_child_pid(xlchildnum); /* returns 0 if child struct is not in use */
 
 /* global options */
 extern int autoballoon;
+extern libxl_defbool run_hotplug_scripts;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 404c9c2..fd980b1 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -594,6 +594,7 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    c_info->run_hotplug_scripts = run_hotplug_scripts;
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
     if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
-- 
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 Jun 14 12:21:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf93C-0004Yn-VI; Thu, 14 Jun 2012 12:21:22 +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 1Sf93B-0004Xk-H9
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:21 +0000
Received: from [193.109.254.147:41323] by server-3.bemta-14.messagelabs.com id
	94/9D-05653-047D9DF4; Thu, 14 Jun 2012 12:21:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339676472!4077734!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13072 invoked from network); 14 Jun 2012 12:21:14 -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;
	14 Jun 2012 12:21:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067768"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-HG;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:04 +0100
Message-ID: <1339676475-33265-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 02/13] libxl: move device model creation
	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

Move prototypes regarding device model creation, since they will
depend on domain destruction in future patches.

This patch is pure code motion.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_internal.h |   75 ++++++++++++++++++++---------------------
 1 files changed, 37 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7ed6456..8612fe4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1095,44 +1095,6 @@ static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
 _hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
                                     pid_t innerchild);
 
-/*----- device model creation -----*/
-
-/* First layer; wraps libxl__spawn_spawn. */
-
-typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
-
-typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
-                                int rc /* if !0, error was logged */);
-
-struct libxl__dm_spawn_state {
-    /* mixed - spawn.ao must be initialised by user; rest is private: */
-    libxl__spawn_state spawn;
-    /* filled in by user, must remain valid: */
-    uint32_t guest_domid; /* domain being served */
-    libxl_domain_config *guest_config;
-    libxl__domain_build_state *build_state; /* relates to guest_domid */
-    libxl__dm_spawn_cb *callback;
-};
-
-_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
-
-/* Stubdom device models. */
-
-typedef struct {
-    /* Mixed - user must fill in public parts EXCEPT callback,
-     * which may be undefined on entry.  (See above for details) */
-    libxl__dm_spawn_state dm; /* the stub domain device model */
-    /* filled in by user, must remain valid: */
-    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
-    /* private to libxl__spawn_stub_dm: */
-    libxl_domain_config dm_config;
-    libxl__domain_build_state dm_state;
-    libxl__dm_spawn_state pvqemu;
-} libxl__stub_dm_spawn_state;
-
-_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
-
-
 /*
  * libxl__wait_for_offspring - Wait for child state
  * gc: allocation pool
@@ -1908,6 +1870,43 @@ struct libxl__ao_device {
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - spawn.ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdom device models. */
+
+typedef struct {
+    /* Mixed - user must fill in public parts EXCEPT callback,
+     * which may be undefined on entry.  (See above for details) */
+    libxl__dm_spawn_state dm; /* the stub domain device model */
+    /* filled in by user, must remain valid: */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
+    /* private to libxl__spawn_stub_dm: */
+    libxl_domain_config dm_config;
+    libxl__domain_build_state dm_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stub_dm_spawn_state;
+
+_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
+
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
-- 
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 Jun 14 12:21:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf93C-0004Yn-VI; Thu, 14 Jun 2012 12:21:22 +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 1Sf93B-0004Xk-H9
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:21 +0000
Received: from [193.109.254.147:41323] by server-3.bemta-14.messagelabs.com id
	94/9D-05653-047D9DF4; Thu, 14 Jun 2012 12:21:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339676472!4077734!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13072 invoked from network); 14 Jun 2012 12:21:14 -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;
	14 Jun 2012 12:21:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067768"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-HG;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:04 +0100
Message-ID: <1339676475-33265-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 02/13] libxl: move device model creation
	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

Move prototypes regarding device model creation, since they will
depend on domain destruction in future patches.

This patch is pure code motion.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_internal.h |   75 ++++++++++++++++++++---------------------
 1 files changed, 37 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7ed6456..8612fe4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1095,44 +1095,6 @@ static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
 _hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
                                     pid_t innerchild);
 
-/*----- device model creation -----*/
-
-/* First layer; wraps libxl__spawn_spawn. */
-
-typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
-
-typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
-                                int rc /* if !0, error was logged */);
-
-struct libxl__dm_spawn_state {
-    /* mixed - spawn.ao must be initialised by user; rest is private: */
-    libxl__spawn_state spawn;
-    /* filled in by user, must remain valid: */
-    uint32_t guest_domid; /* domain being served */
-    libxl_domain_config *guest_config;
-    libxl__domain_build_state *build_state; /* relates to guest_domid */
-    libxl__dm_spawn_cb *callback;
-};
-
-_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
-
-/* Stubdom device models. */
-
-typedef struct {
-    /* Mixed - user must fill in public parts EXCEPT callback,
-     * which may be undefined on entry.  (See above for details) */
-    libxl__dm_spawn_state dm; /* the stub domain device model */
-    /* filled in by user, must remain valid: */
-    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
-    /* private to libxl__spawn_stub_dm: */
-    libxl_domain_config dm_config;
-    libxl__domain_build_state dm_state;
-    libxl__dm_spawn_state pvqemu;
-} libxl__stub_dm_spawn_state;
-
-_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
-
-
 /*
  * libxl__wait_for_offspring - Wait for child state
  * gc: allocation pool
@@ -1908,6 +1870,43 @@ struct libxl__ao_device {
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*----- device model creation -----*/
+
+/* First layer; wraps libxl__spawn_spawn. */
+
+typedef struct libxl__dm_spawn_state libxl__dm_spawn_state;
+
+typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*,
+                                int rc /* if !0, error was logged */);
+
+struct libxl__dm_spawn_state {
+    /* mixed - spawn.ao must be initialised by user; rest is private: */
+    libxl__spawn_state spawn;
+    /* filled in by user, must remain valid: */
+    uint32_t guest_domid; /* domain being served */
+    libxl_domain_config *guest_config;
+    libxl__domain_build_state *build_state; /* relates to guest_domid */
+    libxl__dm_spawn_cb *callback;
+};
+
+_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
+
+/* Stubdom device models. */
+
+typedef struct {
+    /* Mixed - user must fill in public parts EXCEPT callback,
+     * which may be undefined on entry.  (See above for details) */
+    libxl__dm_spawn_state dm; /* the stub domain device model */
+    /* filled in by user, must remain valid: */
+    libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */
+    /* private to libxl__spawn_stub_dm: */
+    libxl_domain_config dm_config;
+    libxl__domain_build_state dm_state;
+    libxl__dm_spawn_state pvqemu;
+} libxl__stub_dm_spawn_state;
+
+_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
+
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
-- 
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 Jun 14 12:21:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93C-0004YV-Hb; Thu, 14 Jun 2012 12:21:22 +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 1Sf93B-0004Xc-4D
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:21 +0000
Received: from [85.158.139.83:25111] by server-6.bemta-5.messagelabs.com id
	00/84-11348-047D9DF4; Thu, 14 Jun 2012 12:21:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 806 invoked from network); 14 Jun 2012 12:21:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067775"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Fw;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:03 +0100
Message-ID: <1339676475-33265-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 01/13] libxl: change ao_device_remove to
	ao_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

Introduce a new structure to track state of device backends, that will
be used in following patches on this series.

This structure if used for both device creation and device
destruction and removes libxl__ao_device_remove.

Changes since v5:

 * Added a common exit point for device addition/destruction that
   removes backend and frontend entries (on destruction).

 * Posponed the introduction of the base and active fields in the
   ao_device struct.

 * Don't call libxl__ev_devstate_init, since _wait will do it.

 * Removed "action being performed" comment.

Changes sinve v4:

 * Added a more detailed comment in _prepare and _initiate header.

 * Removed an unnecessary state check from
   libxl_initiate_device_remove.

Changes since v2:

 * Remove unnecessary comments in libxl__ao_device.

 * Change libxl__device_cb to device_addrm_aocomplete.

 * Rename aorm parameter in device_addrm_aocomplete to aodev.

 * Use a macro to define {nic,disk,vkb,vfb}_{remove,destroy}
   functions.

 * Rename libxl__init_ao_device to libxl__prepare_ao_device and add a
   comment explaining why we need to set active to 1.

 * Replace al uses of aorm with aodev.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c          |  214 ++++++++++++++----------------------------
 tools/libxl/libxl.h          |   15 ++-
 tools/libxl/libxl_device.c   |  136 ++++++++++++++++++---------
 tools/libxl/libxl_internal.h |   58 ++++++++++--
 tools/libxl/xl_cmdimpl.c     |    2 +-
 5 files changed, 226 insertions(+), 199 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..8f5b334 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1432,6 +1432,26 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 
 /******************************************************************************/
 
+/* generic callback for devices that only need to set ao_complete */
+static void device_addrm_aocomplete(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+
+    if (aodev->rc) {
+        LOGE(ERROR, "unable to %s %s with id %u",
+                    aodev->action == DEVICE_CONNECT ? "add" : "remove",
+                    libxl__device_kind_to_string(aodev->dev->kind),
+                    aodev->dev->devid);
+        goto out;
+    }
+
+out:
+    libxl__ao_complete(egc, ao, aodev->rc);
+    return;
+}
+
+/******************************************************************************/
+
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
     int rc;
@@ -1609,42 +1629,6 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     return rc;
 }
 
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
-                              libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
-
 static void libxl__device_disk_from_xs_be(libxl__gc *gc,
                                           const char *be_path,
                                           libxl_device_disk *disk)
@@ -2009,8 +1993,9 @@ int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
             if (disk->vdev != NULL) {
                 libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
                         disk, 0);
+                /* fixme-ao */
                 rc = libxl_device_disk_destroy(gc->owner,
-                        LIBXL_TOOLSTACK_DOMID, disk);
+                        LIBXL_TOOLSTACK_DOMID, disk, 0);
             }
             break;
         default:
@@ -2178,42 +2163,6 @@ out:
     return rc;
 }
 
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_nic(gc, domid, nic, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_device_nic *nic)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_nic(gc, domid, nic, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
-
 static void libxl__device_nic_from_xs_be(libxl__gc *gc,
                                          const char *be_path,
                                          libxl_device_nic *nic)
@@ -2540,42 +2489,6 @@ out:
     return rc;
 }
 
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_device_vkb *vkb)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
-
 /******************************************************************************/
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
@@ -2673,41 +2586,56 @@ out:
     return rc;
 }
 
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_device_vfb *vfb)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
-    if (rc != 0) goto out;
+/******************************************************************************/
 
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
+/* Macro for defining device remove/destroy functions in a compact way */
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)                    \
+    int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,           \
+        uint32_t domid, libxl_device_##type *type,                      \
+        const libxl_asyncop_how *ao_how)                                \
+    {                                                                   \
+        AO_CREATE(ctx, domid, ao_how);                                  \
+        libxl__device *device;                                          \
+        libxl__ao_device *aodev;                                        \
+        int rc;                                                         \
+                                                                        \
+        GCNEW(device);                                                  \
+        rc = libxl__device_from_##type(gc, domid, type, device);        \
+        if (rc != 0) goto out;                                          \
+                                                                        \
+        GCNEW(aodev);                                                   \
+        libxl__prepare_ao_device(ao, aodev);                            \
+        aodev->action = DEVICE_DISCONNECT;                              \
+        aodev->dev = device;                                            \
+        aodev->callback = device_addrm_aocomplete;                      \
+        aodev->force = f;                                               \
+        libxl__initiate_device_remove(egc, aodev);                      \
+                                                                        \
+    out:                                                                \
+        if (rc) return AO_ABORT(rc);                                    \
+        return AO_INPROGRESS;                                           \
+    }
+
+/* Define all remove/destroy functions and undef the macro */
+
+/* disk */
+DEFINE_DEVICE_REMOVE(disk, remove, 0)
+DEFINE_DEVICE_REMOVE(disk, destroy, 1)
+
+/* nic */
+DEFINE_DEVICE_REMOVE(nic, remove, 0)
+DEFINE_DEVICE_REMOVE(nic, destroy, 1)
+
+/* vkb */
+DEFINE_DEVICE_REMOVE(vkb, remove, 0)
+DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
+
+/* vfb */
+
+DEFINE_DEVICE_REMOVE(vfb, remove, 0)
+DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
+
+#undef DEFINE_DEVICE_REMOVE
 
 /******************************************************************************/
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..bb3beaf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -655,7 +655,8 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
-                              libxl_device_disk *disk);
+                              libxl_device_disk *disk,
+                              const libxl_asyncop_how *ao_how);
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
@@ -672,7 +673,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
-int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_nic *nic,
+                             const libxl_asyncop_how *ao_how);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
@@ -683,14 +686,18 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
                             const libxl_asyncop_how *ao_how);
-int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_vkb *vkb,
+                             const libxl_asyncop_how *ao_how);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
                             const libxl_asyncop_how *ao_how);
-int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_vfb *vfb,
+                             const libxl_asyncop_how *ao_how);
 
 /* PCI Passthrough */
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 3da60e1..8ba1915 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -361,11 +361,13 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+/* Device AO operations */
 
-typedef struct {
-    libxl__ao *ao;
-    libxl__ev_devstate ds;
-} libxl__ao_device_remove;
+void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev)
+{
+    aodev->ao = ao;
+    aodev->rc = 0;
+}
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
@@ -441,34 +443,29 @@ out:
 
 /* Callbacks for device related operations */
 
-static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc);
 
-static void device_remove_cleanup(libxl__gc *gc,
-                                  libxl__ao_device_remove *aorm);
+static void device_backend_cleanup(libxl__gc *gc,
+                                   libxl__ao_device *aodev);
+
+static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev);
 
-int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
-                                  libxl__device *dev)
+void libxl__initiate_device_remove(libxl__egc *egc,
+                                   libxl__ao_device *aodev)
 {
-    AO_GC;
+    STATE_AO_GC(aodev->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
-    char *be_path = libxl__device_backend_path(gc, dev);
+    xs_transaction_t t = 0;
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
-    libxl__ao_device_remove *aorm = 0;
-
-    if (!state)
-        goto out_ok;
-    if (atoi(state) != 4) {
-        libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out_ok;
-    }
 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
+    if (aodev->force)
+        libxl__xs_path_cleanup(gc, t,
+                               libxl__device_frontend_path(gc, aodev->dev));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -479,42 +476,93 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    aorm = libxl__zalloc(gc, sizeof(*aorm));
-    aorm->ao = ao;
-    libxl__ev_devstate_init(&aorm->ds);
-
-    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+    rc = libxl__ev_devstate_wait(gc, &aodev->backend_ds,
+                                 device_backend_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out_fail;
+    if (rc) {
+        LOG(ERROR, "unable to remove device %s", be_path);
+        goto out_fail;
+    }
 
-    return 0;
+    return;
 
  out_fail:
     assert(rc);
-    device_remove_cleanup(gc, aorm);
-    return rc;
-
- out_ok:
-    libxl__ao_complete(egc, ao, 0);
-    return 0;
+    aodev->rc = rc;
+    device_xsentries_remove(egc, aodev);
+    return;
 }
 
-static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
-    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
-    libxl__gc *gc = &aorm->ao->gc;
-    libxl__ao_complete(egc, aorm->ao, rc);
-    device_remove_cleanup(gc, aorm);
+    libxl__ao_device *aodev = CONTAINER_OF(ds, *aodev, backend_ds);
+    STATE_AO_GC(aodev->ao);
+
+    device_backend_cleanup(gc, aodev);
+
+    if (rc == ERROR_TIMEDOUT && aodev->action == DEVICE_DISCONNECT &&
+        !aodev->force) {
+        aodev->force = 1;
+        libxl__initiate_device_remove(egc, aodev);
+        return;
+    }
+
+    /* Some devices (vkbd) fail to disconnect properly,
+     * but we shouldn't alarm the user if it's during
+     * domain destruction.
+     */
+    if (rc && aodev->action == DEVICE_CONNECT) {
+        LOG(ERROR, "unable to connect device with path %s",
+                   libxl__device_backend_path(gc, aodev->dev));
+        goto out;
+    } else if (rc) {
+        LOG(DEBUG, "unable to disconnect device with path %s",
+                   libxl__device_backend_path(gc, aodev->dev));
+        goto out;
+    }
+
+out:
+    aodev->rc = rc;
+    device_xsentries_remove(egc, aodev);
+    return;
 }
 
-static void device_remove_cleanup(libxl__gc *gc,
-                                  libxl__ao_device_remove *aorm) {
-    if (!aorm) return;
-    libxl__ev_devstate_cancel(gc, &aorm->ds);
+static void device_backend_cleanup(libxl__gc *gc, libxl__ao_device *aodev)
+{
+    if (!aodev) return;
+    libxl__ev_devstate_cancel(gc, &aodev->backend_ds);
+}
+
+static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
+    char *fe_path = libxl__device_frontend_path(gc, aodev->dev);
+    xs_transaction_t t = 0;
+    int ret = 0;
+
+    if (aodev->action == DEVICE_DISCONNECT) {
+        do {
+            t = xs_transaction_start(CTX->xsh);
+            libxl__xs_path_cleanup(gc, t, fe_path);
+            libxl__xs_path_cleanup(gc, t, be_path);
+            ret = !xs_transaction_end(CTX->xsh, t, 0);
+        } while (ret && errno == EAGAIN);
+
+        if (ret) {
+            LOGE(ERROR, "unable to finish transaction");
+            aodev->rc = ERROR_FAIL;
+        }
+    }
+
+    aodev->callback(egc, aodev);
+    return;
 }
 
 int libxl__wait_for_device_model(libxl__gc *gc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..7ed6456 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -853,13 +853,6 @@ _hidden const char *libxl__device_nic_devname(libxl__gc *gc,
                                               uint32_t devid,
                                               libxl_nic_type type);
 
-/* Arranges that dev will be removed from its guest.  When
- * this is done, the ao will be completed.  An error
- * return from libxl__initiate_device_remove means that the ao
- * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
-                                          libxl__device *dev);
-
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
@@ -1864,6 +1857,57 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
+/*----- device addition/removal -----*/
+
+/* Action to perform (either connect or disconnect) */
+typedef enum {
+    DEVICE_CONNECT,
+    DEVICE_DISCONNECT
+} libxl__device_action;
+
+typedef struct libxl__ao_device libxl__ao_device;
+typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
+
+/* This functions sets the necessary libxl__ao_device struct values to use
+ * safely inside functions. It marks the operation as "active"
+ * since we need to be sure that all device status structs are set
+ * to active before start queueing events, or we might call
+ * ao_complete before all devices had finished
+ *
+ * libxl__initiate_device_{remove/addition} should not be called without
+ * calling libxl__prepare_ao_device first, since it initializes the private
+ * fields of the struct libxl__ao_device to what this functions expect.
+ *
+ * Once _prepare has been called on a libxl__ao_device, it is safe to just
+ * discard this struct, there's no need to call any destroy function.
+ * _prepare can also be called multiple times with the same libxl__ao_device.
+ */
+_hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
+
+struct libxl__ao_device {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl__device_action action;
+    libxl__device *dev;
+    int force;
+    libxl__device_callback *callback;
+    /* private for implementation */
+    int rc;
+    libxl__ev_devstate backend_ds;
+};
+
+/* Arranges that dev will be removed to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done (or an error happens), the callback in
+ * aodev->callback will be called.
+ *
+ * The libxl__ao_device passed to this function should be
+ * prepared using libxl__prepare_ao_device prior to calling
+ * this function.
+ */
+_hidden void libxl__initiate_device_remove(libxl__egc *egc,
+                                           libxl__ao_device *aodev);
+
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index afa0af6..2ddcdc5 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5357,7 +5357,7 @@ int main_blockdetach(int argc, char **argv)
     if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     } else
-        libxl_device_disk_destroy(ctx, domid, &disk);
+        libxl_device_disk_destroy(ctx, domid, &disk, 0);
     return 0;
 }
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93C-0004YV-Hb; Thu, 14 Jun 2012 12:21:22 +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 1Sf93B-0004Xc-4D
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:21 +0000
Received: from [85.158.139.83:25111] by server-6.bemta-5.messagelabs.com id
	00/84-11348-047D9DF4; Thu, 14 Jun 2012 12:21:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 806 invoked from network); 14 Jun 2012 12:21:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067775"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Fw;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:03 +0100
Message-ID: <1339676475-33265-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 01/13] libxl: change ao_device_remove to
	ao_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

Introduce a new structure to track state of device backends, that will
be used in following patches on this series.

This structure if used for both device creation and device
destruction and removes libxl__ao_device_remove.

Changes since v5:

 * Added a common exit point for device addition/destruction that
   removes backend and frontend entries (on destruction).

 * Posponed the introduction of the base and active fields in the
   ao_device struct.

 * Don't call libxl__ev_devstate_init, since _wait will do it.

 * Removed "action being performed" comment.

Changes sinve v4:

 * Added a more detailed comment in _prepare and _initiate header.

 * Removed an unnecessary state check from
   libxl_initiate_device_remove.

Changes since v2:

 * Remove unnecessary comments in libxl__ao_device.

 * Change libxl__device_cb to device_addrm_aocomplete.

 * Rename aorm parameter in device_addrm_aocomplete to aodev.

 * Use a macro to define {nic,disk,vkb,vfb}_{remove,destroy}
   functions.

 * Rename libxl__init_ao_device to libxl__prepare_ao_device and add a
   comment explaining why we need to set active to 1.

 * Replace al uses of aorm with aodev.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c          |  214 ++++++++++++++----------------------------
 tools/libxl/libxl.h          |   15 ++-
 tools/libxl/libxl_device.c   |  136 ++++++++++++++++++---------
 tools/libxl/libxl_internal.h |   58 ++++++++++--
 tools/libxl/xl_cmdimpl.c     |    2 +-
 5 files changed, 226 insertions(+), 199 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..8f5b334 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1432,6 +1432,26 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass)
 
 /******************************************************************************/
 
+/* generic callback for devices that only need to set ao_complete */
+static void device_addrm_aocomplete(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+
+    if (aodev->rc) {
+        LOGE(ERROR, "unable to %s %s with id %u",
+                    aodev->action == DEVICE_CONNECT ? "add" : "remove",
+                    libxl__device_kind_to_string(aodev->dev->kind),
+                    aodev->dev->devid);
+        goto out;
+    }
+
+out:
+    libxl__ao_complete(egc, ao, aodev->rc);
+    return;
+}
+
+/******************************************************************************/
+
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
     int rc;
@@ -1609,42 +1629,6 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis
     return rc;
 }
 
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
-                              libxl_device_disk *disk)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
-
 static void libxl__device_disk_from_xs_be(libxl__gc *gc,
                                           const char *be_path,
                                           libxl_device_disk *disk)
@@ -2009,8 +1993,9 @@ int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk)
             if (disk->vdev != NULL) {
                 libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID,
                         disk, 0);
+                /* fixme-ao */
                 rc = libxl_device_disk_destroy(gc->owner,
-                        LIBXL_TOOLSTACK_DOMID, disk);
+                        LIBXL_TOOLSTACK_DOMID, disk, 0);
             }
             break;
         default:
@@ -2178,42 +2163,6 @@ out:
     return rc;
 }
 
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_nic(gc, domid, nic, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_device_nic *nic)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_nic(gc, domid, nic, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
-
 static void libxl__device_nic_from_xs_be(libxl__gc *gc,
                                          const char *be_path,
                                          libxl_device_nic *nic)
@@ -2540,42 +2489,6 @@ out:
     return rc;
 }
 
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_device_vkb *vkb)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vkb(gc, domid, vkb, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
-
 /******************************************************************************/
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
@@ -2673,41 +2586,56 @@ out:
     return rc;
 }
 
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how)
-{
-    AO_CREATE(ctx, domid, ao_how);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
-    if (rc != 0) goto out;
-
-    rc = libxl__initiate_device_remove(egc, ao, &device);
-    if (rc) goto out;
-
-    return AO_INPROGRESS;
-
-out:
-    return AO_ABORT(rc);
-}
-
-int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_device_vfb *vfb)
-{
-    GC_INIT(ctx);
-    libxl__device device;
-    int rc;
-
-    rc = libxl__device_from_vfb(gc, domid, vfb, &device);
-    if (rc != 0) goto out;
+/******************************************************************************/
 
-    rc = libxl__device_destroy(gc, &device);
-out:
-    GC_FREE;
-    return rc;
-}
+/* Macro for defining device remove/destroy functions in a compact way */
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)                    \
+    int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,           \
+        uint32_t domid, libxl_device_##type *type,                      \
+        const libxl_asyncop_how *ao_how)                                \
+    {                                                                   \
+        AO_CREATE(ctx, domid, ao_how);                                  \
+        libxl__device *device;                                          \
+        libxl__ao_device *aodev;                                        \
+        int rc;                                                         \
+                                                                        \
+        GCNEW(device);                                                  \
+        rc = libxl__device_from_##type(gc, domid, type, device);        \
+        if (rc != 0) goto out;                                          \
+                                                                        \
+        GCNEW(aodev);                                                   \
+        libxl__prepare_ao_device(ao, aodev);                            \
+        aodev->action = DEVICE_DISCONNECT;                              \
+        aodev->dev = device;                                            \
+        aodev->callback = device_addrm_aocomplete;                      \
+        aodev->force = f;                                               \
+        libxl__initiate_device_remove(egc, aodev);                      \
+                                                                        \
+    out:                                                                \
+        if (rc) return AO_ABORT(rc);                                    \
+        return AO_INPROGRESS;                                           \
+    }
+
+/* Define all remove/destroy functions and undef the macro */
+
+/* disk */
+DEFINE_DEVICE_REMOVE(disk, remove, 0)
+DEFINE_DEVICE_REMOVE(disk, destroy, 1)
+
+/* nic */
+DEFINE_DEVICE_REMOVE(nic, remove, 0)
+DEFINE_DEVICE_REMOVE(nic, destroy, 1)
+
+/* vkb */
+DEFINE_DEVICE_REMOVE(vkb, remove, 0)
+DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
+
+/* vfb */
+
+DEFINE_DEVICE_REMOVE(vfb, remove, 0)
+DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
+
+#undef DEFINE_DEVICE_REMOVE
 
 /******************************************************************************/
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..bb3beaf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -655,7 +655,8 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
-                              libxl_device_disk *disk);
+                              libxl_device_disk *disk,
+                              const libxl_asyncop_how *ao_how);
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
@@ -672,7 +673,9 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
                             const libxl_asyncop_how *ao_how);
-int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_nic *nic,
+                             const libxl_asyncop_how *ao_how);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
@@ -683,14 +686,18 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
                             const libxl_asyncop_how *ao_how);
-int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_vkb *vkb,
+                             const libxl_asyncop_how *ao_how);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
                             const libxl_asyncop_how *ao_how);
-int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_vfb *vfb,
+                             const libxl_asyncop_how *ao_how);
 
 /* PCI Passthrough */
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 3da60e1..8ba1915 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -361,11 +361,13 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
+/* Device AO operations */
 
-typedef struct {
-    libxl__ao *ao;
-    libxl__ev_devstate ds;
-} libxl__ao_device_remove;
+void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev)
+{
+    aodev->ao = ao;
+    aodev->rc = 0;
+}
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
@@ -441,34 +443,29 @@ out:
 
 /* Callbacks for device related operations */
 
-static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc);
 
-static void device_remove_cleanup(libxl__gc *gc,
-                                  libxl__ao_device_remove *aorm);
+static void device_backend_cleanup(libxl__gc *gc,
+                                   libxl__ao_device *aodev);
+
+static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev);
 
-int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
-                                  libxl__device *dev)
+void libxl__initiate_device_remove(libxl__egc *egc,
+                                   libxl__ao_device *aodev)
 {
-    AO_GC;
+    STATE_AO_GC(aodev->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    xs_transaction_t t;
-    char *be_path = libxl__device_backend_path(gc, dev);
+    xs_transaction_t t = 0;
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
-    libxl__ao_device_remove *aorm = 0;
-
-    if (!state)
-        goto out_ok;
-    if (atoi(state) != 4) {
-        libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out_ok;
-    }
 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
+    if (aodev->force)
+        libxl__xs_path_cleanup(gc, t,
+                               libxl__device_frontend_path(gc, aodev->dev));
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
@@ -479,42 +476,93 @@ retry_transaction:
             goto out_fail;
         }
     }
+    /* mark transaction as ended, to prevent double closing it on out_ok */
+    t = 0;
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    aorm = libxl__zalloc(gc, sizeof(*aorm));
-    aorm->ao = ao;
-    libxl__ev_devstate_init(&aorm->ds);
-
-    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+    rc = libxl__ev_devstate_wait(gc, &aodev->backend_ds,
+                                 device_backend_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out_fail;
+    if (rc) {
+        LOG(ERROR, "unable to remove device %s", be_path);
+        goto out_fail;
+    }
 
-    return 0;
+    return;
 
  out_fail:
     assert(rc);
-    device_remove_cleanup(gc, aorm);
-    return rc;
-
- out_ok:
-    libxl__ao_complete(egc, ao, 0);
-    return 0;
+    aodev->rc = rc;
+    device_xsentries_remove(egc, aodev);
+    return;
 }
 
-static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
                                    int rc) {
-    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
-    libxl__gc *gc = &aorm->ao->gc;
-    libxl__ao_complete(egc, aorm->ao, rc);
-    device_remove_cleanup(gc, aorm);
+    libxl__ao_device *aodev = CONTAINER_OF(ds, *aodev, backend_ds);
+    STATE_AO_GC(aodev->ao);
+
+    device_backend_cleanup(gc, aodev);
+
+    if (rc == ERROR_TIMEDOUT && aodev->action == DEVICE_DISCONNECT &&
+        !aodev->force) {
+        aodev->force = 1;
+        libxl__initiate_device_remove(egc, aodev);
+        return;
+    }
+
+    /* Some devices (vkbd) fail to disconnect properly,
+     * but we shouldn't alarm the user if it's during
+     * domain destruction.
+     */
+    if (rc && aodev->action == DEVICE_CONNECT) {
+        LOG(ERROR, "unable to connect device with path %s",
+                   libxl__device_backend_path(gc, aodev->dev));
+        goto out;
+    } else if (rc) {
+        LOG(DEBUG, "unable to disconnect device with path %s",
+                   libxl__device_backend_path(gc, aodev->dev));
+        goto out;
+    }
+
+out:
+    aodev->rc = rc;
+    device_xsentries_remove(egc, aodev);
+    return;
 }
 
-static void device_remove_cleanup(libxl__gc *gc,
-                                  libxl__ao_device_remove *aorm) {
-    if (!aorm) return;
-    libxl__ev_devstate_cancel(gc, &aorm->ds);
+static void device_backend_cleanup(libxl__gc *gc, libxl__ao_device *aodev)
+{
+    if (!aodev) return;
+    libxl__ev_devstate_cancel(gc, &aodev->backend_ds);
+}
+
+static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
+    char *fe_path = libxl__device_frontend_path(gc, aodev->dev);
+    xs_transaction_t t = 0;
+    int ret = 0;
+
+    if (aodev->action == DEVICE_DISCONNECT) {
+        do {
+            t = xs_transaction_start(CTX->xsh);
+            libxl__xs_path_cleanup(gc, t, fe_path);
+            libxl__xs_path_cleanup(gc, t, be_path);
+            ret = !xs_transaction_end(CTX->xsh, t, 0);
+        } while (ret && errno == EAGAIN);
+
+        if (ret) {
+            LOGE(ERROR, "unable to finish transaction");
+            aodev->rc = ERROR_FAIL;
+        }
+    }
+
+    aodev->callback(egc, aodev);
+    return;
 }
 
 int libxl__wait_for_device_model(libxl__gc *gc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..7ed6456 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -853,13 +853,6 @@ _hidden const char *libxl__device_nic_devname(libxl__gc *gc,
                                               uint32_t devid,
                                               libxl_nic_type type);
 
-/* Arranges that dev will be removed from its guest.  When
- * this is done, the ao will be completed.  An error
- * return from libxl__initiate_device_remove means that the ao
- * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
-                                          libxl__device *dev);
-
 /*
  * libxl__ev_devstate - waits a given time for a device to
  * reach a given state.  Follows the libxl_ev_* conventions.
@@ -1864,6 +1857,57 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl);
  * If callback is passed rc==0, will have updated st->info appropriately */
 _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st);
 
+/*----- device addition/removal -----*/
+
+/* Action to perform (either connect or disconnect) */
+typedef enum {
+    DEVICE_CONNECT,
+    DEVICE_DISCONNECT
+} libxl__device_action;
+
+typedef struct libxl__ao_device libxl__ao_device;
+typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
+
+/* This functions sets the necessary libxl__ao_device struct values to use
+ * safely inside functions. It marks the operation as "active"
+ * since we need to be sure that all device status structs are set
+ * to active before start queueing events, or we might call
+ * ao_complete before all devices had finished
+ *
+ * libxl__initiate_device_{remove/addition} should not be called without
+ * calling libxl__prepare_ao_device first, since it initializes the private
+ * fields of the struct libxl__ao_device to what this functions expect.
+ *
+ * Once _prepare has been called on a libxl__ao_device, it is safe to just
+ * discard this struct, there's no need to call any destroy function.
+ * _prepare can also be called multiple times with the same libxl__ao_device.
+ */
+_hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
+
+struct libxl__ao_device {
+    /* filled in by user */
+    libxl__ao *ao;
+    libxl__device_action action;
+    libxl__device *dev;
+    int force;
+    libxl__device_callback *callback;
+    /* private for implementation */
+    int rc;
+    libxl__ev_devstate backend_ds;
+};
+
+/* Arranges that dev will be removed to the guest, and the
+ * hotplug scripts will be executed (if necessary). When
+ * this is done (or an error happens), the callback in
+ * aodev->callback will be called.
+ *
+ * The libxl__ao_device passed to this function should be
+ * prepared using libxl__prepare_ao_device prior to calling
+ * this function.
+ */
+_hidden void libxl__initiate_device_remove(libxl__egc *egc,
+                                           libxl__ao_device *aodev);
+
 /*----- Domain creation -----*/
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index afa0af6..2ddcdc5 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5357,7 +5357,7 @@ int main_blockdetach(int argc, char **argv)
     if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     } else
-        libxl_device_disk_destroy(ctx, domid, &disk);
+        libxl_device_disk_destroy(ctx, domid, &disk, 0);
     return 0;
 }
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93E-0004Zn-RJ; Thu, 14 Jun 2012 12:21:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Sf93C-0004Xs-3W
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:22 +0000
Received: from [85.158.139.83:63413] by server-10.bemta-5.messagelabs.com id
	EB/69-02190-147D9DF4; Thu, 14 Jun 2012 12:21:21 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 918 invoked from network); 14 Jun 2012 12:21:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067776"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Ko;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:08 +0100
Message-ID: <1339676475-33265-7-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 06/13] libxl: convert libxl_device_disk_add
	to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 converts libxl_device_disk_add to an ao operation that
waits for device backend to reach state XenbusStateInitWait and then
marks the operation as completed. This is not really useful now, but
will be used by latter patches that will launch hotplug scripts after
we reached the desired xenbus state.

As usual, libxl_device_disk_add callers have been modified, and the
internal function libxl__device_disk_add has been used if the call was
inside an already running ao.

Changes since v5:

 * Change the disk addition to use the new ao_devices structure.

 * Change name and comment of _initiate_device_add to
   _initiate_device_connect.

Changes since v4:

 * Added more comments about libxl__device_disk_add and
   libxl__add_disks.

 * Removed stray hunk in Makefile.

 * Fixed _prepare call libxl__add_disks (separate into a different
   loop).

 * Moved some code to check if disks have finished to a macro that
   generates a custom function, which will also be used for vif
   interfaces.

Changes since v2:

 * Remove state read from libxl__initiate_device_add

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c          |  166 ++++++++++++++++++++++++++++--------------
 tools/libxl/libxl.h          |    4 +-
 tools/libxl/libxl_create.c   |   40 ++++++++--
 tools/libxl/libxl_device.c   |   69 +++++++++++++++++
 tools/libxl/libxl_dm.c       |   60 +++++++++++----
 tools/libxl/libxl_internal.h |   43 ++++++++++-
 tools/libxl/xl_cmdimpl.c     |    2 +-
 7 files changed, 301 insertions(+), 83 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 43affd1..5f09740 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1655,13 +1655,16 @@ int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
-        xs_transaction_t t, libxl_device_disk *disk)
+void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
+                            xs_transaction_t t,
+                            libxl_device_disk *disk,
+                            libxl__ao_device *aodev)
 {
+    STATE_AO_GC(aodev->ao);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
-    libxl__device device;
+    libxl__device *device;
     int major, minor, rc;
     libxl_ctx *ctx = gc->owner;
 
@@ -1686,7 +1689,8 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
         goto out_free;
     }
 
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    GCNEW(device);
+    rc = libxl__device_from_disk(gc, domid, disk, device);
     if (rc != 0) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
                " virtual disk identifier %s", disk->vdev);
@@ -1704,7 +1708,7 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
             dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
@@ -1725,7 +1729,7 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
             flexarray_append(back, "params");
             flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                           libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            assert(device->backend_kind == LIBXL__DEVICE_KIND_QDISK);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
@@ -1757,29 +1761,42 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", device->devid));
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, t, &device,
+    libxl__device_generic_add(gc, t, device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    aodev->dev = device;
+    aodev->action = DEVICE_CONNECT;
+    libxl__initiate_device_connection(egc, aodev);
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    return rc;
+    aodev->rc = rc;
+    if (rc) aodev->callback(egc, aodev);
+    return;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc = libxl__device_disk_add(gc, domid, XBT_NULL, disk);
-    GC_FREE;
-    return rc;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__ao_device *aodev;
+
+    GCNEW(aodev);
+    libxl__prepare_ao_device(ao, aodev);
+    aodev->callback = device_addrm_aocomplete;
+    libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev);
+
+    return AO_INPROGRESS;
 }
 
 static void libxl__device_disk_from_xs_be(libxl__gc *gc,
@@ -1982,11 +1999,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    /* fixme-ao */
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        /* fixme-ao */
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -2027,15 +2046,17 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,
     return NULL;
 }
 
+/* Callbacks */
+
+static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev);
+
 void libxl__device_disk_local_attach(libxl__egc *egc,
                                      libxl__disk_local_state *dls)
 {
     STATE_AO_GC(dls->ao);
     libxl_ctx *ctx = CTX;
-    char *dev = NULL, *be_path = NULL;
-    int rc, xs_ret;
-    libxl__device device;
-    xs_transaction_t t = XBT_NULL;
+    char *dev = NULL;
+    int rc;
     const libxl_device_disk *in_disk = dls->in_disk;
     libxl_device_disk *disk = &dls->disk;
     const char *blkdev_start = dls->blkdev_start;
@@ -2082,34 +2103,24 @@ void libxl__device_disk_local_attach(libxl__egc *egc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                do {
-                    t = xs_transaction_start(ctx->xsh);
-                    if (t == XBT_NULL) {
-                        LOG(ERROR, "failed to start a xenstore transaction");
-                        rc = ERROR_FAIL;
-                        goto out;
-                    }
-                    disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t);
-                    if (disk->vdev == NULL) {
-                        LOG(ERROR, "libxl__alloc_vdev failed");
-                        rc = ERROR_FAIL;
-                        goto out;
-                    }
-                    rc = libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID,
-                                                t, disk);
-                    if (rc) {
-                        LOG(ERROR, "libxl_device_disk_add failed");
-                        goto out;
-                    }
-                    xs_ret = xs_transaction_end(ctx->xsh, t, 0);
-                } while (xs_ret == 0 && errno == EAGAIN);
-                t = XBT_NULL;
-                if (xs_ret == 0) {
-                    LOGE(ERROR, "xenstore transaction failed");
+                dls->t = xs_transaction_start(ctx->xsh);
+                if (dls->t == XBT_NULL) {
+                    LOG(ERROR, "failed to start a xenstore transaction");
+                    rc = ERROR_FAIL;
+                    goto out;
+                }
+                disk->vdev = libxl__alloc_vdev(gc, blkdev_start, dls->t);
+                if (disk->vdev == NULL) {
+                    LOG(ERROR, "libxl__alloc_vdev failed");
                     rc = ERROR_FAIL;
                     goto out;
                 }
-                dev = GCSPRINTF("/dev/%s", disk->vdev);
+
+                libxl__prepare_ao_device(ao, &dls->aodev);
+                dls->aodev.callback = local_device_attach_cb;
+                libxl__device_disk_add(egc, LIBXL_TOOLSTACK_DOMID,
+                                       dls->t, disk, &dls->aodev);
+                return;
             } else {
                 dev = disk->pdev_path;
             }
@@ -2122,15 +2133,60 @@ void libxl__device_disk_local_attach(libxl__egc *egc,
             break;
     }
 
-    if (disk->vdev != NULL) {
-        rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
-        if (rc < 0)
-            goto out;
-        be_path = libxl__device_backend_path(gc, &device);
-        rc = libxl__wait_for_backend(gc, be_path, "4");
-        if (rc < 0)
-            goto out;
+    if (dev != NULL)
+        dls->diskpath = strdup(dev);
+
+    dls->callback(egc, dls, 0);
+    return;
+
+ out:
+    assert(rc);
+    if (dls->t != XBT_NULL)
+        xs_transaction_end(ctx->xsh, dls->t, 1);
+    dls->callback(egc, dls, rc);
+}
+
+static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    libxl__disk_local_state *dls = CONTAINER_OF(aodev, *dls, aodev);
+    libxl_ctx *ctx = CTX;
+    char *dev = NULL, *be_path = NULL;
+    int rc, xs_ret;
+    libxl__device device;
+    libxl_device_disk *disk = &dls->disk;
+
+    rc = aodev->rc;
+    if (rc) {
+        LOGE(ERROR, "unable to %s %s with id %u",
+                    aodev->action == DEVICE_CONNECT ? "add" : "remove",
+                    libxl__device_kind_to_string(aodev->dev->kind),
+                    aodev->dev->devid);
+        goto out;
+    }
+
+    xs_ret = xs_transaction_end(ctx->xsh, dls->t, 0);
+    if (xs_ret == 0 && errno == EAGAIN) {
+        libxl__device_disk_local_attach(egc, dls);
+        return;
+    }
+    dls->t = XBT_NULL;
+    if (xs_ret == 0) {
+        LOGE(ERROR, "xenstore transaction failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
+    dev = GCSPRINTF("/dev/%s", disk->vdev);
+    LOG(DEBUG, "locally attaching qdisk %s", dev);
+
+    rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
+    if (rc < 0)
+        goto out;
+    be_path = libxl__device_backend_path(gc, &device);
+    rc = libxl__wait_for_backend(gc, be_path, "4");
+    if (rc < 0)
+        goto out;
+
     if (dev != NULL)
         dls->diskpath = strdup(dev);
 
@@ -2139,8 +2195,8 @@ void libxl__device_disk_local_attach(libxl__egc *egc,
 
  out:
     assert(rc);
-    if (t != XBT_NULL)
-        xs_transaction_end(ctx->xsh, t, 1);
+    if (dls->t != XBT_NULL)
+        xs_transaction_end(ctx->xsh, dls->t, 1);
     dls->callback(egc, dls, rc);
 }
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1967e66..de06f65 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -651,7 +651,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a47bef7..53ecc0d 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -581,6 +581,9 @@ static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                int rc);
+
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
@@ -681,7 +684,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
@@ -720,15 +722,35 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 
     store_libxl_entry(gc, domid, &d_config->b_info);
 
-    for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "cannot add disk %d to domain: %d", i, ret);
-            ret = ERROR_FAIL;
-            goto error_out;
-        }
+    dcs->aodevs.size = d_config->num_disks;
+    libxl__add_disks(egc, ao, domid, d_config, &dcs->aodevs,
+                     domcreate_launch_dm);
+
+    return;
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                int rc)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(aodevs, *dcs, aodevs);
+    STATE_AO_GC(dcs->ao);
+    int i, ret = 0;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
+    if (rc) {
+        LOG(ERROR, "unable to add disk devices");
+        goto error_out;
     }
+
     for (i = 0; i < d_config->num_vifs; i++) {
         ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
         if (ret) {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 9243806..5d34ed5 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -442,6 +442,45 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
     return;
 }
 
+/******************************************************************************/
+
+/* Macro for defining the functions that will add a bunch of disks when
+ * inside an async op.
+ *
+ * This macro is added to prevent repetition of code.
+ */
+
+/* Capatibility macro, since disk_add now takes a xs transaction parameter */
+#define libxl__device_disk_add(egc, domid, disk, aodev)                       \
+        libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
+
+#define DEFINE_DEVICES_ADD(type)                                              \
+    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
+                              libxl_domain_config *d_config,                  \
+                              libxl__ao_devices *aodevs,                      \
+                              libxl__devices_callback *callback)              \
+    {                                                                         \
+        AO_GC;                                                                \
+        int i;                                                                \
+        aodevs->size = d_config->num_##type##s;                               \
+        aodevs->callback = callback;                                          \
+        libxl__prepare_ao_devices(ao, aodevs);                                \
+        aodevs->callback = callback;                                          \
+                                                                              \
+        for (i = 0; i < aodevs->size; i++) {                                  \
+            aodevs->array[i].callback = libxl__ao_devices_callback;           \
+            libxl__device_##type##_add(egc, domid, &d_config->type##s[i],     \
+                                       &aodevs->array[i]);                    \
+        }                                                                     \
+    }
+
+DEFINE_DEVICES_ADD(disk)
+
+#undef libxl__device_disk_add
+#undef DEFINE_DEVICES_ADD
+
+/******************************************************************************/
+
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -554,6 +593,36 @@ static void device_backend_cleanup(libxl__gc *gc,
 
 static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev);
 
+void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    int rc = 0;
+
+    if (aodev->dev->backend_kind == LIBXL__DEVICE_KIND_QDISK) {
+        aodev->callback(egc, aodev);
+        return;
+    }
+
+    rc = libxl__ev_devstate_wait(gc, &aodev->backend_ds,
+                                 device_backend_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LOGE(ERROR, "unable to initialize device %s", be_path);
+        goto out_fail;
+    }
+
+    return;
+
+out_fail:
+    assert(rc);
+    aodev->rc = rc;
+    device_xsentries_remove(egc, aodev);
+    return;
+}
+
 void libxl__initiate_device_remove(libxl__egc *egc,
                                    libxl__ao_device *aodev)
 {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index e5d666a..b7979cb 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -677,6 +677,9 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
                                 libxl__dm_spawn_state *stubdom_dmss,
                                 int rc);
 
+static void spawn_stub_launch_dm(libxl__egc *egc,
+                                 libxl__ao_devices *aodevs, int rc);
+
 static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
                                            libxl__destroy_domid_state *dis,
                                            int rc);
@@ -685,8 +688,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 {
     STATE_AO_GC(sdss->dm.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
-    libxl__device_console *console;
+    int ret;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
     char **args;
@@ -805,22 +807,53 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
-        if (ret)
-            goto out_free;
-    }
+    sdss->aodevs.size = dm_config->num_disks;
+    libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->aodevs,
+                     spawn_stub_launch_dm);
+
+    free(args);
+    return;
+
+out_free:
+    free(args);
+out:
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
+}
+
+static void spawn_stub_launch_dm(libxl__egc *egc,
+                                 libxl__ao_devices *aodevs, int rc)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(aodevs, *sdss, aodevs);
+    STATE_AO_GC(sdss->dm.spawn.ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret = 0;
+    libxl__device_console *console;
+
+    /* convenience aliases */
+    libxl_domain_config *const dm_config = &sdss->dm_config;
+    libxl_domain_config *const guest_config = sdss->dm.guest_config;
+    const int guest_domid = sdss->dm.guest_domid;
+    libxl__domain_build_state *const d_state = sdss->dm.build_state;
+    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) {
+        LOG(ERROR, "error connecting disk devices");
+        goto out;
+     }
+
     for (i = 0; i < dm_config->num_vifs; i++) {
         ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
-            goto out_free;
+            goto out;
     }
     ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
-        goto out_free;
+        goto out;
     ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
-        goto out_free;
+        goto out;
 
     if (guest_config->b_info.u.hvm.serial)
         num_console++;
@@ -828,7 +861,7 @@ retry_transaction:
     console = libxl__calloc(gc, num_console, sizeof(libxl__device_console));
     if (!console) {
         ret = ERROR_NOMEM;
-        goto out_free;
+        goto out;
     }
 
     for (i = 0; i < num_console; i++) {
@@ -864,7 +897,7 @@ retry_transaction:
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
                         i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
-            goto out_free;
+            goto out;
     }
 
     sdss->pvqemu.spawn.ao = ao;
@@ -875,11 +908,8 @@ retry_transaction:
 
     libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    free(args);
     return;
 
-out_free:
-    free(args);
 out:
     assert(ret);
     spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 85c21b4..937ab08 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal.h"
 #include "_libxl_types_internal_json.h"
 
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DESTROY_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
@@ -1242,8 +1243,6 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
                                    libxl_device_disk *disk,
                                    libxl__device *device);
-_hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
-        xs_transaction_t t, libxl_device_disk *disk);
 
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
@@ -1752,6 +1751,27 @@ struct libxl__ao_devices {
     libxl__devices_callback *callback;
 };
 
+/* AO operation to connect a disk device, called by
+ * libxl_device_disk_add and libxl__add_disks. This function calls
+ * libxl__initiate_device_connection to wait for the device to
+ * finish the connection (might involve executing hotplug scripts).
+ */
+_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
+                                    xs_transaction_t t,
+                                    libxl_device_disk *disk,
+                                    libxl__ao_device *aodev);
+
+/* Waits for the passed device to reach state XenbusStateInitWait.
+ * This is not really useful by itself, but is important when executing
+ * hotplug scripts, since we need to be sure the device is in the correct
+ * state before executing them.
+ *
+ * Once finished, aodev->callback will be executed.
+ */
+_hidden void libxl__initiate_device_connection(libxl__egc*,
+                                               libxl__ao_device *aodev);
+
+
 /* Arranges that dev will be removed to the guest, and the
  * hotplug scripts will be executed (if necessary). When
  * this is done (or an error happens), the callback in
@@ -1782,6 +1802,8 @@ struct libxl__disk_local_state {
     char *diskpath;
     /* private for implementation of local detach */
     libxl__ao_device aodev;
+    /* private for implementation of local attach */
+    xs_transaction_t t;
 };
 
 /*
@@ -1999,6 +2021,19 @@ _hidden void libxl__destroy_domid(libxl__egc *egc,
 _hidden void libxl__devices_destroy(libxl__egc *egc,
                                     libxl__devices_remove_state *drs);
 
+/* Helper function to add a bunch of disks. This should be used when
+ * the caller is inside an async op. "devices" will be prepared by this
+ * function, so there's no need to call _prepare before calling this
+ * function.
+ *
+ * The "callback" will be called for each device, and the user is responsible
+ * for calling libxl__ao_device_check_last on the callback.
+ */
+void libxl__add_disks(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+                      libxl_domain_config *d_config,
+                      libxl__ao_devices *aodevs,
+                      libxl__devices_callback *callback);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
@@ -2033,6 +2068,8 @@ typedef struct {
     libxl__domain_build_state dm_state;
     libxl__dm_spawn_state pvqemu;
     libxl__destroy_domid_state dis;
+    /* used to store the state of devices being connected */
+    libxl__ao_devices aodevs;
 } libxl__stub_dm_spawn_state;
 
 _hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
@@ -2061,6 +2098,8 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
     /* necessary if the domain creation failed and we have to destroy it */
     libxl__domain_destroy_state dds;
+    /* used to store the state of devices being connected */
+    libxl__ao_devices aodevs;
 };
 
 /*
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5ba65c2..a40643d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5296,7 +5296,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93E-0004Zn-RJ; Thu, 14 Jun 2012 12:21:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Sf93C-0004Xs-3W
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:22 +0000
Received: from [85.158.139.83:63413] by server-10.bemta-5.messagelabs.com id
	EB/69-02190-147D9DF4; Thu, 14 Jun 2012 12:21:21 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339676476!27668594!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 918 invoked from network); 14 Jun 2012 12:21:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067776"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Ko;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:08 +0100
Message-ID: <1339676475-33265-7-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 06/13] libxl: convert libxl_device_disk_add
	to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 converts libxl_device_disk_add to an ao operation that
waits for device backend to reach state XenbusStateInitWait and then
marks the operation as completed. This is not really useful now, but
will be used by latter patches that will launch hotplug scripts after
we reached the desired xenbus state.

As usual, libxl_device_disk_add callers have been modified, and the
internal function libxl__device_disk_add has been used if the call was
inside an already running ao.

Changes since v5:

 * Change the disk addition to use the new ao_devices structure.

 * Change name and comment of _initiate_device_add to
   _initiate_device_connect.

Changes since v4:

 * Added more comments about libxl__device_disk_add and
   libxl__add_disks.

 * Removed stray hunk in Makefile.

 * Fixed _prepare call libxl__add_disks (separate into a different
   loop).

 * Moved some code to check if disks have finished to a macro that
   generates a custom function, which will also be used for vif
   interfaces.

Changes since v2:

 * Remove state read from libxl__initiate_device_add

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c          |  166 ++++++++++++++++++++++++++++--------------
 tools/libxl/libxl.h          |    4 +-
 tools/libxl/libxl_create.c   |   40 ++++++++--
 tools/libxl/libxl_device.c   |   69 +++++++++++++++++
 tools/libxl/libxl_dm.c       |   60 +++++++++++----
 tools/libxl/libxl_internal.h |   43 ++++++++++-
 tools/libxl/xl_cmdimpl.c     |    2 +-
 7 files changed, 301 insertions(+), 83 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 43affd1..5f09740 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1655,13 +1655,16 @@ int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
-        xs_transaction_t t, libxl_device_disk *disk)
+void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
+                            xs_transaction_t t,
+                            libxl_device_disk *disk,
+                            libxl__ao_device *aodev)
 {
+    STATE_AO_GC(aodev->ao);
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
-    libxl__device device;
+    libxl__device *device;
     int major, minor, rc;
     libxl_ctx *ctx = gc->owner;
 
@@ -1686,7 +1689,8 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
         goto out_free;
     }
 
-    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    GCNEW(device);
+    rc = libxl__device_from_disk(gc, domid, disk, device);
     if (rc != 0) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported"
                " virtual disk identifier %s", disk->vdev);
@@ -1704,7 +1708,7 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
+            assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
             dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
@@ -1725,7 +1729,7 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
             flexarray_append(back, "params");
             flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                           libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
-            assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK);
+            assert(device->backend_kind == LIBXL__DEVICE_KIND_QDISK);
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
@@ -1757,29 +1761,42 @@ int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
     flexarray_append(front, "state");
     flexarray_append(front, libxl__sprintf(gc, "%d", 1));
     flexarray_append(front, "virtual-device");
-    flexarray_append(front, libxl__sprintf(gc, "%d", device.devid));
+    flexarray_append(front, libxl__sprintf(gc, "%d", device->devid));
     flexarray_append(front, "device-type");
     flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk");
 
-    libxl__device_generic_add(gc, t, &device,
+    libxl__device_generic_add(gc, t, device,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    aodev->dev = device;
+    aodev->action = DEVICE_CONNECT;
+    libxl__initiate_device_connection(egc, aodev);
+
     rc = 0;
 
 out_free:
     flexarray_free(back);
     flexarray_free(front);
 out:
-    return rc;
+    aodev->rc = rc;
+    if (rc) aodev->callback(egc, aodev);
+    return;
 }
 
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    int rc = libxl__device_disk_add(gc, domid, XBT_NULL, disk);
-    GC_FREE;
-    return rc;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__ao_device *aodev;
+
+    GCNEW(aodev);
+    libxl__prepare_ao_device(ao, aodev);
+    aodev->callback = device_addrm_aocomplete;
+    libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev);
+
+    return AO_INPROGRESS;
 }
 
 static void libxl__device_disk_from_xs_be(libxl__gc *gc,
@@ -1982,11 +1999,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
     ret = 0;
 
     libxl_device_disk_remove(ctx, domid, disks + i, 0);
-    libxl_device_disk_add(ctx, domid, disk);
+    /* fixme-ao */
+    libxl_device_disk_add(ctx, domid, disk, 0);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
         libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        /* fixme-ao */
+        libxl_device_disk_add(ctx, stubdomid, disk, 0);
     }
 out:
     for (i = 0; i < num; i++)
@@ -2027,15 +2046,17 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,
     return NULL;
 }
 
+/* Callbacks */
+
+static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev);
+
 void libxl__device_disk_local_attach(libxl__egc *egc,
                                      libxl__disk_local_state *dls)
 {
     STATE_AO_GC(dls->ao);
     libxl_ctx *ctx = CTX;
-    char *dev = NULL, *be_path = NULL;
-    int rc, xs_ret;
-    libxl__device device;
-    xs_transaction_t t = XBT_NULL;
+    char *dev = NULL;
+    int rc;
     const libxl_device_disk *in_disk = dls->in_disk;
     libxl_device_disk *disk = &dls->disk;
     const char *blkdev_start = dls->blkdev_start;
@@ -2082,34 +2103,24 @@ void libxl__device_disk_local_attach(libxl__egc *egc,
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                do {
-                    t = xs_transaction_start(ctx->xsh);
-                    if (t == XBT_NULL) {
-                        LOG(ERROR, "failed to start a xenstore transaction");
-                        rc = ERROR_FAIL;
-                        goto out;
-                    }
-                    disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t);
-                    if (disk->vdev == NULL) {
-                        LOG(ERROR, "libxl__alloc_vdev failed");
-                        rc = ERROR_FAIL;
-                        goto out;
-                    }
-                    rc = libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID,
-                                                t, disk);
-                    if (rc) {
-                        LOG(ERROR, "libxl_device_disk_add failed");
-                        goto out;
-                    }
-                    xs_ret = xs_transaction_end(ctx->xsh, t, 0);
-                } while (xs_ret == 0 && errno == EAGAIN);
-                t = XBT_NULL;
-                if (xs_ret == 0) {
-                    LOGE(ERROR, "xenstore transaction failed");
+                dls->t = xs_transaction_start(ctx->xsh);
+                if (dls->t == XBT_NULL) {
+                    LOG(ERROR, "failed to start a xenstore transaction");
+                    rc = ERROR_FAIL;
+                    goto out;
+                }
+                disk->vdev = libxl__alloc_vdev(gc, blkdev_start, dls->t);
+                if (disk->vdev == NULL) {
+                    LOG(ERROR, "libxl__alloc_vdev failed");
                     rc = ERROR_FAIL;
                     goto out;
                 }
-                dev = GCSPRINTF("/dev/%s", disk->vdev);
+
+                libxl__prepare_ao_device(ao, &dls->aodev);
+                dls->aodev.callback = local_device_attach_cb;
+                libxl__device_disk_add(egc, LIBXL_TOOLSTACK_DOMID,
+                                       dls->t, disk, &dls->aodev);
+                return;
             } else {
                 dev = disk->pdev_path;
             }
@@ -2122,15 +2133,60 @@ void libxl__device_disk_local_attach(libxl__egc *egc,
             break;
     }
 
-    if (disk->vdev != NULL) {
-        rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
-        if (rc < 0)
-            goto out;
-        be_path = libxl__device_backend_path(gc, &device);
-        rc = libxl__wait_for_backend(gc, be_path, "4");
-        if (rc < 0)
-            goto out;
+    if (dev != NULL)
+        dls->diskpath = strdup(dev);
+
+    dls->callback(egc, dls, 0);
+    return;
+
+ out:
+    assert(rc);
+    if (dls->t != XBT_NULL)
+        xs_transaction_end(ctx->xsh, dls->t, 1);
+    dls->callback(egc, dls, rc);
+}
+
+static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    libxl__disk_local_state *dls = CONTAINER_OF(aodev, *dls, aodev);
+    libxl_ctx *ctx = CTX;
+    char *dev = NULL, *be_path = NULL;
+    int rc, xs_ret;
+    libxl__device device;
+    libxl_device_disk *disk = &dls->disk;
+
+    rc = aodev->rc;
+    if (rc) {
+        LOGE(ERROR, "unable to %s %s with id %u",
+                    aodev->action == DEVICE_CONNECT ? "add" : "remove",
+                    libxl__device_kind_to_string(aodev->dev->kind),
+                    aodev->dev->devid);
+        goto out;
+    }
+
+    xs_ret = xs_transaction_end(ctx->xsh, dls->t, 0);
+    if (xs_ret == 0 && errno == EAGAIN) {
+        libxl__device_disk_local_attach(egc, dls);
+        return;
+    }
+    dls->t = XBT_NULL;
+    if (xs_ret == 0) {
+        LOGE(ERROR, "xenstore transaction failed");
+        rc = ERROR_FAIL;
+        goto out;
     }
+    dev = GCSPRINTF("/dev/%s", disk->vdev);
+    LOG(DEBUG, "locally attaching qdisk %s", dev);
+
+    rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
+    if (rc < 0)
+        goto out;
+    be_path = libxl__device_backend_path(gc, &device);
+    rc = libxl__wait_for_backend(gc, be_path, "4");
+    if (rc < 0)
+        goto out;
+
     if (dev != NULL)
         dls->diskpath = strdup(dev);
 
@@ -2139,8 +2195,8 @@ void libxl__device_disk_local_attach(libxl__egc *egc,
 
  out:
     assert(rc);
-    if (t != XBT_NULL)
-        xs_transaction_end(ctx->xsh, t, 1);
+    if (dls->t != XBT_NULL)
+        xs_transaction_end(ctx->xsh, dls->t, 1);
     dls->callback(egc, dls, rc);
 }
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1967e66..de06f65 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -651,7 +651,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
  */
 
 /* Disks */
-int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
+                          libxl_device_disk *disk,
+                          const libxl_asyncop_how *ao_how);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
                              const libxl_asyncop_how *ao_how);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a47bef7..53ecc0d 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -581,6 +581,9 @@ static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
 
+static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                int rc);
+
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
@@ -681,7 +684,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
@@ -720,15 +722,35 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 
     store_libxl_entry(gc, domid, &d_config->b_info);
 
-    for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
-        if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "cannot add disk %d to domain: %d", i, ret);
-            ret = ERROR_FAIL;
-            goto error_out;
-        }
+    dcs->aodevs.size = d_config->num_disks;
+    libxl__add_disks(egc, ao, domid, d_config, &dcs->aodevs,
+                     domcreate_launch_dm);
+
+    return;
+
+ error_out:
+    assert(ret);
+    domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_launch_dm(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                int rc)
+{
+    libxl__domain_create_state *dcs = CONTAINER_OF(aodevs, *dcs, aodevs);
+    STATE_AO_GC(dcs->ao);
+    int i, ret = 0;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
+    if (rc) {
+        LOG(ERROR, "unable to add disk devices");
+        goto error_out;
     }
+
     for (i = 0; i < d_config->num_vifs; i++) {
         ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
         if (ret) {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 9243806..5d34ed5 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -442,6 +442,45 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
     return;
 }
 
+/******************************************************************************/
+
+/* Macro for defining the functions that will add a bunch of disks when
+ * inside an async op.
+ *
+ * This macro is added to prevent repetition of code.
+ */
+
+/* Capatibility macro, since disk_add now takes a xs transaction parameter */
+#define libxl__device_disk_add(egc, domid, disk, aodev)                       \
+        libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
+
+#define DEFINE_DEVICES_ADD(type)                                              \
+    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
+                              libxl_domain_config *d_config,                  \
+                              libxl__ao_devices *aodevs,                      \
+                              libxl__devices_callback *callback)              \
+    {                                                                         \
+        AO_GC;                                                                \
+        int i;                                                                \
+        aodevs->size = d_config->num_##type##s;                               \
+        aodevs->callback = callback;                                          \
+        libxl__prepare_ao_devices(ao, aodevs);                                \
+        aodevs->callback = callback;                                          \
+                                                                              \
+        for (i = 0; i < aodevs->size; i++) {                                  \
+            aodevs->array[i].callback = libxl__ao_devices_callback;           \
+            libxl__device_##type##_add(egc, domid, &d_config->type##s[i],     \
+                                       &aodevs->array[i]);                    \
+        }                                                                     \
+    }
+
+DEFINE_DEVICES_ADD(disk)
+
+#undef libxl__device_disk_add
+#undef DEFINE_DEVICES_ADD
+
+/******************************************************************************/
+
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -554,6 +593,36 @@ static void device_backend_cleanup(libxl__gc *gc,
 
 static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev);
 
+void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
+    int rc = 0;
+
+    if (aodev->dev->backend_kind == LIBXL__DEVICE_KIND_QDISK) {
+        aodev->callback(egc, aodev);
+        return;
+    }
+
+    rc = libxl__ev_devstate_wait(gc, &aodev->backend_ds,
+                                 device_backend_callback,
+                                 state_path, XenbusStateInitWait,
+                                 LIBXL_INIT_TIMEOUT * 1000);
+    if (rc) {
+        LOGE(ERROR, "unable to initialize device %s", be_path);
+        goto out_fail;
+    }
+
+    return;
+
+out_fail:
+    assert(rc);
+    aodev->rc = rc;
+    device_xsentries_remove(egc, aodev);
+    return;
+}
+
 void libxl__initiate_device_remove(libxl__egc *egc,
                                    libxl__ao_device *aodev)
 {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index e5d666a..b7979cb 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -677,6 +677,9 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
                                 libxl__dm_spawn_state *stubdom_dmss,
                                 int rc);
 
+static void spawn_stub_launch_dm(libxl__egc *egc,
+                                 libxl__ao_devices *aodevs, int rc);
+
 static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
                                            libxl__destroy_domid_state *dis,
                                            int rc);
@@ -685,8 +688,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 {
     STATE_AO_GC(sdss->dm.spawn.ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
-    libxl__device_console *console;
+    int ret;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
     char **args;
@@ -805,22 +807,53 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < dm_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]);
-        if (ret)
-            goto out_free;
-    }
+    sdss->aodevs.size = dm_config->num_disks;
+    libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->aodevs,
+                     spawn_stub_launch_dm);
+
+    free(args);
+    return;
+
+out_free:
+    free(args);
+out:
+    assert(ret);
+    spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
+}
+
+static void spawn_stub_launch_dm(libxl__egc *egc,
+                                 libxl__ao_devices *aodevs, int rc)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(aodevs, *sdss, aodevs);
+    STATE_AO_GC(sdss->dm.spawn.ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret = 0;
+    libxl__device_console *console;
+
+    /* convenience aliases */
+    libxl_domain_config *const dm_config = &sdss->dm_config;
+    libxl_domain_config *const guest_config = sdss->dm.guest_config;
+    const int guest_domid = sdss->dm.guest_domid;
+    libxl__domain_build_state *const d_state = sdss->dm.build_state;
+    libxl__domain_build_state *const stubdom_state = &sdss->dm_state;
+    uint32_t dm_domid = sdss->pvqemu.guest_domid;
+
+    if (rc) {
+        LOG(ERROR, "error connecting disk devices");
+        goto out;
+     }
+
     for (i = 0; i < dm_config->num_vifs; i++) {
         ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]);
         if (ret)
-            goto out_free;
+            goto out;
     }
     ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
-        goto out_free;
+        goto out;
     ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]);
     if (ret)
-        goto out_free;
+        goto out;
 
     if (guest_config->b_info.u.hvm.serial)
         num_console++;
@@ -828,7 +861,7 @@ retry_transaction:
     console = libxl__calloc(gc, num_console, sizeof(libxl__device_console));
     if (!console) {
         ret = ERROR_NOMEM;
-        goto out_free;
+        goto out;
     }
 
     for (i = 0; i < num_console; i++) {
@@ -864,7 +897,7 @@ retry_transaction:
         ret = libxl__device_console_add(gc, dm_domid, &console[i],
                         i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL);
         if (ret)
-            goto out_free;
+            goto out;
     }
 
     sdss->pvqemu.spawn.ao = ao;
@@ -875,11 +908,8 @@ retry_transaction:
 
     libxl__spawn_local_dm(egc, &sdss->pvqemu);
 
-    free(args);
     return;
 
-out_free:
-    free(args);
 out:
     assert(ret);
     spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 85c21b4..937ab08 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -70,6 +70,7 @@
 #include "_libxl_types_internal.h"
 #include "_libxl_types_internal_json.h"
 
+#define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DESTROY_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
@@ -1242,8 +1243,6 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path);
 _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
                                    libxl_device_disk *disk,
                                    libxl__device *device);
-_hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid,
-        xs_transaction_t t, libxl_device_disk *disk);
 
 _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid);
 
@@ -1752,6 +1751,27 @@ struct libxl__ao_devices {
     libxl__devices_callback *callback;
 };
 
+/* AO operation to connect a disk device, called by
+ * libxl_device_disk_add and libxl__add_disks. This function calls
+ * libxl__initiate_device_connection to wait for the device to
+ * finish the connection (might involve executing hotplug scripts).
+ */
+_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
+                                    xs_transaction_t t,
+                                    libxl_device_disk *disk,
+                                    libxl__ao_device *aodev);
+
+/* Waits for the passed device to reach state XenbusStateInitWait.
+ * This is not really useful by itself, but is important when executing
+ * hotplug scripts, since we need to be sure the device is in the correct
+ * state before executing them.
+ *
+ * Once finished, aodev->callback will be executed.
+ */
+_hidden void libxl__initiate_device_connection(libxl__egc*,
+                                               libxl__ao_device *aodev);
+
+
 /* Arranges that dev will be removed to the guest, and the
  * hotplug scripts will be executed (if necessary). When
  * this is done (or an error happens), the callback in
@@ -1782,6 +1802,8 @@ struct libxl__disk_local_state {
     char *diskpath;
     /* private for implementation of local detach */
     libxl__ao_device aodev;
+    /* private for implementation of local attach */
+    xs_transaction_t t;
 };
 
 /*
@@ -1999,6 +2021,19 @@ _hidden void libxl__destroy_domid(libxl__egc *egc,
 _hidden void libxl__devices_destroy(libxl__egc *egc,
                                     libxl__devices_remove_state *drs);
 
+/* Helper function to add a bunch of disks. This should be used when
+ * the caller is inside an async op. "devices" will be prepared by this
+ * function, so there's no need to call _prepare before calling this
+ * function.
+ *
+ * The "callback" will be called for each device, and the user is responsible
+ * for calling libxl__ao_device_check_last on the callback.
+ */
+void libxl__add_disks(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+                      libxl_domain_config *d_config,
+                      libxl__ao_devices *aodevs,
+                      libxl__devices_callback *callback);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
@@ -2033,6 +2068,8 @@ typedef struct {
     libxl__domain_build_state dm_state;
     libxl__dm_spawn_state pvqemu;
     libxl__destroy_domid_state dis;
+    /* used to store the state of devices being connected */
+    libxl__ao_devices aodevs;
 } libxl__stub_dm_spawn_state;
 
 _hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
@@ -2061,6 +2098,8 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
     /* necessary if the domain creation failed and we have to destroy it */
     libxl__domain_destroy_state dds;
+    /* used to store the state of devices being connected */
+    libxl__ao_devices aodevs;
 };
 
 /*
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5ba65c2..a40643d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5296,7 +5296,7 @@ int main_blockattach(int argc, char **argv)
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93F-0004a9-8g; Thu, 14 Jun 2012 12:21:25 +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 1Sf93C-0004Y9-FE
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:23 +0000
Received: from [85.158.138.51:14517] by server-10.bemta-3.messagelabs.com id
	9F/7F-01753-147D9DF4; Thu, 14 Jun 2012 12:21:21 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339676478!27639891!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21048 invoked from network); 14 Jun 2012 12:21:20 -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;
	14 Jun 2012 12:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067777"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Hl;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:05 +0100
Message-ID: <1339676475-33265-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 03/13] libxl: convert libxl_domain_destroy to
	an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change introduces some new structures, and breaks the mutual
dependency that libxl_domain_destroy and libxl__destroy_device_model
had. This is done by checking if the domid passed to
libxl_domain_destroy has a stubdom, and then having the bulk of the
destroy machinery in a separate function (libxl__destroy_domid) that
doesn't check for stubdom presence, since we check for it in the upper
level function. The reason behind this change is the need to use
structures for ao operations, and it was impossible to have two
different self-referencing structs.

All uses of libxl_domain_destroy have been changed, and either
replaced by the new libxl_domain_destroy ao function or by the
internal libxl__domain_destroy that can be used inside an already
running ao.

Changes since v5:

 * Introduced a new struct, called libxl__ao_devices that will be used
   to simplify the addition/removal of multiple devices at the same
   time.

 * With this function we can use a generic callback for ao_device,
   libxl__ao_devices_callback, that will check if the device is the
   last one and call ao_devices->callback appropiately.

Changes since v4:

 * Fixed spelling mistakes.

 * Always use "force = 1" in device destruction in
   libxl__destroy_domid function.

 * Changed name of domain destroy callbacks to include "destroy".

 * Changed the use of rc to catch syscall errors.

 * Use libxl__remove_file instead of unlink.

 * Changed variable name of number of devices returned by
   libxl__xs_directory.

 * Simplify libxl__ao_device_check_last return.

 * Correctly propagate error returned from libxl__num_devices.

 * Add a comment about the use of libxl__device_destroy to destroy the
   console.

 * Fixed some uses of LIBXL__LOG.

Changes since v3:

 * Fixed python bindings.

Changes since v2:

 * Remove printfs.

 * Replace aorm with aodev.

 * Define an auxiliary libxl__ao_device *aodev to avoid using the long
   expression: drs->aorm[numdev]...

 * Added a common callback for both domain and stubdomain destruction
   that checks if both domains are finished and handles errors
   correctly.

 * Change libxl__ao_device_check_last logic a bit and add a comment
   describing how does it work.

 * Fixed spelling mistakes.

 * Use a do-while for xs transaction in device_remove_callback.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c               |  167 +++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl.h               |    3 +-
 tools/libxl/libxl_create.c        |   29 ++++++-
 tools/libxl/libxl_device.c        |  152 +++++++++++++++++++++++++++++----
 tools/libxl/libxl_dm.c            |   83 +++++++++---------
 tools/libxl/libxl_internal.h      |  116 +++++++++++++++++++++++++-
 tools/libxl/xl_cmdimpl.c          |   12 ++--
 tools/python/xen/lowlevel/xl/xl.c |    2 +-
 8 files changed, 483 insertions(+), 81 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8f5b334..3ad1931 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1146,11 +1146,133 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+/* Callbacks for libxl_domain_destroy */
+
+static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
+                              int rc);
+
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_destroy_state *dds;
+
+    GCNEW(dds);
+    dds->ao = ao;
+    dds->domid = domid;
+    dds->callback = domain_destroy_cb;
+    libxl__domain_destroy(egc, dds);
+
+    return AO_INPROGRESS;
+}
+
+static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
+                              int rc)
+{
+    STATE_AO_GC(dds->ao);
+
+    if (rc)
+        LOG(ERROR, "destruction of domain %u failed", dds->domid);
+
+    libxl__ao_complete(egc, ao, rc);
+}
+
+/* Callbacks for libxl__domain_destroy */
+
+static void stubdom_destroy_callback(libxl__egc *egc,
+                                     libxl__destroy_domid_state *dis,
+                                     int rc);
+
+static void domain_destroy_callback(libxl__egc *egc,
+                                    libxl__destroy_domid_state *dis,
+                                    int rc);
+
+static void destroy_finish_check(libxl__egc *egc,
+                                 libxl__domain_destroy_state *dds);
+
+void libxl__domain_destroy(libxl__egc *egc, libxl__domain_destroy_state *dds)
+{
+    STATE_AO_GC(dds->ao);
+    uint32_t stubdomid = libxl_get_stubdom_id(CTX, dds->domid);
+
+    if (stubdomid) {
+        dds->stubdom.ao = ao;
+        dds->stubdom.domid = stubdomid;
+        dds->stubdom.callback = stubdom_destroy_callback;
+        libxl__destroy_domid(egc, &dds->stubdom);
+    } else {
+        dds->stubdom_finished = 1;
+    }
+
+    dds->domain.ao = ao;
+    dds->domain.domid = dds->domid;
+    dds->domain.callback = domain_destroy_callback;
+    libxl__destroy_domid(egc, &dds->domain);
+}
+
+static void stubdom_destroy_callback(libxl__egc *egc,
+                                     libxl__destroy_domid_state *dis,
+                                     int rc)
+{
+    STATE_AO_GC(dis->ao);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, stubdom);
+    const char *savefile;
+
+    if (rc) {
+        LOG(ERROR, "unable to destroy stubdom with domid %u", dis->domid);
+        dds->rc = rc;
+    }
+
+    dds->stubdom_finished = 1;
+    savefile = libxl__device_model_savefile(gc, dis->domid);
+    rc = libxl__remove_file(gc, savefile);
+    /*
+     * On suspend libxl__domain_save_device_model will have already
+     * unlinked the save file.
+     */
+    if (rc) {
+        LOG(ERROR, "failed to remove device-model savefile %s", savefile);
+    }
+
+    destroy_finish_check(egc, dds);
+}
+
+static void domain_destroy_callback(libxl__egc *egc,
+                                    libxl__destroy_domid_state *dis,
+                                    int rc)
+{
+    STATE_AO_GC(dis->ao);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
+
+    if (rc) {
+        LOG(ERROR, "unable to destroy guest with domid %u", dis->domid);
+        dds->rc = rc;
+    }
+
+    dds->domain_finished = 1;
+    destroy_finish_check(egc, dds);
+}
+
+static void destroy_finish_check(libxl__egc *egc,
+                                 libxl__domain_destroy_state *dds)
+{
+    if (!(dds->domain_finished && dds->stubdom_finished))
+        return;
+
+    dds->callback(egc, dds, dds->rc);
+}
+
+/* Callbacks for libxl__destroy_domid */
+static void devices_destroy_cb(libxl__egc *egc,
+                               libxl__devices_remove_state *drs,
+                               int rc);
+
+void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
+{
+    STATE_AO_GC(dis->ao);
+    libxl_ctx *ctx = CTX;
+    uint32_t domid = dis->domid;
     char *dom_path;
-    char *vm_path;
     char *pid;
     int rc, dm_present;
 
@@ -1161,7 +1283,7 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
     case ERROR_INVAL:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid);
     default:
-        return rc;
+        goto out;
     }
 
     switch (libxl__domain_type(gc, domid)) {
@@ -1194,7 +1316,37 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    dis->drs.ao = ao;
+    dis->drs.domid = domid;
+    dis->drs.callback = devices_destroy_cb;
+    dis->drs.force = 1;
+    libxl__devices_destroy(egc, &dis->drs);
+    return;
+
+out:
+    assert(rc);
+    dis->callback(egc, dis, rc);
+    return;
+}
+
+static void devices_destroy_cb(libxl__egc *egc,
+                               libxl__devices_remove_state *drs,
+                               int rc)
+{
+    STATE_AO_GC(drs->ao);
+    libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
+    libxl_ctx *ctx = CTX;
+    uint32_t domid = dis->domid;
+    char *dom_path;
+    char *vm_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (rc < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1217,9 +1369,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    dis->callback(egc, dis, rc);
+    return;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index bb3beaf..1967e66 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -526,7 +526,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4456ae8..a47bef7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -590,6 +590,12 @@ static void domcreate_complete(libxl__egc *egc,
                                libxl__domain_create_state *dcs,
                                int rc);
 
+/* If creation is not successful, this callback will be executed
+ * when domain destruction is finished */
+static void domcreate_destruction_cb(libxl__egc *egc,
+                                     libxl__domain_destroy_state *dds,
+                                     int rc);
+
 static void initiate_domain_create(libxl__egc *egc,
                                    libxl__domain_create_state *dcs)
 {
@@ -855,16 +861,31 @@ static void domcreate_complete(libxl__egc *egc,
 
     if (rc) {
         if (dcs->guest_domid) {
-            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
-            if (rc2)
-                LOG(ERROR, "unable to destroy domain %d following"
-                    " failed creation", dcs->guest_domid);
+            dcs->dds.ao = ao;
+            dcs->dds.domid = dcs->guest_domid;
+            dcs->dds.callback = domcreate_destruction_cb;
+            libxl__domain_destroy(egc, &dcs->dds);
+            return;
         }
         dcs->guest_domid = -1;
     }
     dcs->callback(egc, dcs, rc, dcs->guest_domid);
 }
 
+static void domcreate_destruction_cb(libxl__egc *egc,
+                                     libxl__domain_destroy_state *dds,
+                                     int rc)
+{
+    STATE_AO_GC(dds->ao);
+    libxl__domain_create_state *dcs = CONTAINER_OF(dds, *dcs, dds);
+
+    if (rc)
+        LOG(ERROR, "unable to destroy domain %u following failed creation",
+                   dds->domid);
+
+    dcs->callback(egc, dcs, ERROR_FAIL, dcs->guest_domid);
+}
+
 /*----- application-facing domain creation interface -----*/
 
 typedef struct {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8ba1915..9243806 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,6 +58,48 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+static int libxl__num_devices(libxl__gc *gc, uint32_t domid)
+{
+    char *path;
+    unsigned int num_kinds, num_devs;
+    char **kinds = NULL, **devs = NULL;
+    int i, j, rc = 0;
+    libxl__device dev;
+    libxl__device_kind kind;
+    int numdevs = 0;
+
+    path = GCSPRINTF("/local/domain/%d/device", domid);
+    kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
+    if (!kinds) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "unable to get xenstore device listing %s", path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        num_kinds = 0;
+    }
+    for (i = 0; i < num_kinds; i++) {
+        if (libxl__device_kind_from_string(kinds[i], &kind))
+            continue;
+
+        path = GCSPRINTF("/local/domain/%d/device/%s", domid, kinds[i]);
+        devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs);
+        if (!devs)
+            continue;
+        for (j = 0; j < num_devs; j++) {
+            path = GCSPRINTF("/local/domain/%d/device/%s/%s/backend",
+                             domid, kinds[i], devs[j]);
+            path = libxl__xs_read(gc, XBT_NULL, path);
+            if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
+                numdevs++;
+            }
+        }
+    }
+out:
+    if (rc) return rc;
+    return numdevs;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
         libxl__device *device, char **bents, char **fents)
 {
@@ -367,6 +409,37 @@ void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev)
 {
     aodev->ao = ao;
     aodev->rc = 0;
+    aodev->active = 1;
+}
+
+void libxl__prepare_ao_devices(libxl__ao *ao, libxl__ao_devices *aodevs)
+{
+    AO_GC;
+
+    GCNEW_ARRAY(aodevs->array, aodevs->size);
+    for (int i = 0; i < aodevs->size; i++) {
+        aodevs->array[i].aodevs = aodevs;
+        libxl__prepare_ao_device(ao, &aodevs->array[i]);
+    }
+}
+
+void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    libxl__ao_devices *aodevs = aodev->aodevs;
+    int i, error = 0;
+
+    aodev->active = 0;
+    for (i = 0; i < aodevs->size; i++) {
+        if (aodevs->array[i].active)
+            return;
+
+        if (aodevs->array[i].rc)
+            error = aodevs->array[i].rc;
+    }
+
+    aodevs->callback(egc, aodevs, error);
+    return;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
@@ -383,16 +456,35 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+/* Callback for device destruction */
+
+static void devices_remove_callback(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                    int rc);
+
+void libxl__devices_destroy(libxl__egc *egc, libxl__devices_remove_state *drs)
 {
+    STATE_AO_GC(drs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    uint32_t domid = drs->domid;
     char *path;
-    unsigned int num_kinds, num_devs;
+    unsigned int num_kinds, num_dev_xsentries;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
-    libxl__device dev;
+    int i, j, numdev = 0, rc = 0;
+    libxl__device *dev;
+    libxl__ao_devices *aodevs = &drs->aodevs;
+    libxl__ao_device *aodev;
     libxl__device_kind kind;
 
+    aodevs->size = libxl__num_devices(gc, drs->domid);
+    if (aodevs->size < 0) {
+        LOG(ERROR, "unable to get number of devices for domain %u", drs->domid);
+        rc = aodevs->size;
+        goto out;
+    }
+
+    libxl__prepare_ao_devices(drs->ao, aodevs);
+    aodevs->callback = devices_remove_callback;
+
     path = libxl__sprintf(gc, "/local/domain/%d/device", domid);
     kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
     if (!kinds) {
@@ -408,19 +500,25 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
             continue;
 
         path = libxl__sprintf(gc, "/local/domain/%d/device/%s", domid, kinds[i]);
-        devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs);
+        devs = libxl__xs_directory(gc, XBT_NULL, path, &num_dev_xsentries);
         if (!devs)
             continue;
-        for (j = 0; j < num_devs; j++) {
+        for (j = 0; j < num_dev_xsentries; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
             path = libxl__xs_read(gc, XBT_NULL, path);
-            if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
-                dev.domid = domid;
-                dev.kind = kind;
-                dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+            GCNEW(dev);
+            if (path && libxl__parse_backend_path(gc, path, dev) == 0) {
+                aodev = &aodevs->array[numdev];
+                dev->domid = domid;
+                dev->kind = kind;
+                dev->devid = atoi(devs[j]);
+                aodev->action = DEVICE_DISCONNECT;
+                aodev->dev = dev;
+                aodev->callback = libxl__ao_devices_callback;
+                aodev->force = drs->force;
+                libxl__initiate_device_remove(egc, aodev);
+                numdev++;
             }
         }
     }
@@ -428,17 +526,22 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
     path = libxl__xs_read(gc, XBT_NULL, path);
+    GCNEW(dev);
     if (path && strcmp(path, "") &&
-        libxl__parse_backend_path(gc, path, &dev) == 0) {
-        dev.domid = domid;
-        dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
-        dev.devid = 0;
-
-        libxl__device_destroy(gc, &dev);
+        libxl__parse_backend_path(gc, path, dev) == 0) {
+        dev->domid = domid;
+        dev->kind = LIBXL__DEVICE_KIND_CONSOLE;
+        dev->devid = 0;
+
+        /* Currently console devices can be destroyed synchronously by just
+         * removing xenstore entries, this is what libxl__device_destroy does.
+         */
+        libxl__device_destroy(gc, dev);
     }
 
 out:
-    return 0;
+    if (!numdev) drs->callback(egc, drs, rc);
+    return;
 }
 
 /* Callbacks for device related operations */
@@ -524,6 +627,7 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     } else if (rc) {
         LOG(DEBUG, "unable to disconnect device with path %s",
                    libxl__device_backend_path(gc, aodev->dev));
+        rc = 0;
         goto out;
     }
 
@@ -565,6 +669,16 @@ static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
     return;
 }
 
+static void devices_remove_callback(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                    int rc)
+{
+    libxl__devices_remove_state *drs = CONTAINER_OF(aodevs, *drs, aodevs);
+    STATE_AO_GC(drs->ao);
+
+    drs->callback(egc, drs, rc);
+    return;
+}
+
 int libxl__wait_for_device_model(libxl__gc *gc,
                                  uint32_t domid, char *state,
                                  libxl__spawn_starting *spawning,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..e5d666a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -677,6 +677,10 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
                                 libxl__dm_spawn_state *stubdom_dmss,
                                 int rc);
 
+static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
+                                           libxl__destroy_domid_state *dis,
+                                           int rc);
+
 void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 {
     STATE_AO_GC(sdss->dm.spawn.ao);
@@ -897,12 +901,31 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
 
  out:
     if (rc) {
-        if (dm_domid)
-            libxl_domain_destroy(CTX, dm_domid);
+        if (dm_domid) {
+            sdss->dis.ao = ao;
+            sdss->dis.domid = dm_domid;
+            sdss->dis.callback = spaw_stubdom_pvqemu_destroy_cb;
+            libxl__destroy_domid(egc, &sdss->dis);
+            return;
+        }
     }
     sdss->callback(egc, &sdss->dm, rc);
 }
 
+static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
+                                           libxl__destroy_domid_state *dis,
+                                           int rc)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(dis, *sdss, dis);
+    STATE_AO_GC(sdss->dis.ao);
+
+    if (rc)
+        LOG(ERROR, "destruction of domain %u after failed creation failed",
+                   sdss->pvqemu.guest_domid);
+
+    sdss->callback(egc, &sdss->dm, rc);
+}
+
 /* callbacks passed to libxl__spawn_spawn */
 static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
@@ -1095,48 +1118,24 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
     int ret;
 
     pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
-    if (!pid) {
-        int stubdomid = libxl_get_stubdom_id(ctx, domid);
-        const char *savefile;
-
-        if (!stubdomid) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid");
-            ret = ERROR_INVAL;
-            goto out;
-        }
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
-        if (ret)
-            goto out;
-
-        savefile = libxl__device_model_savefile(gc, domid);
-        ret = unlink(savefile);
-        /*
-         * On suspend libxl__domain_save_device_model will have already
-         * unlinked the save file.
-         */
-        if (ret && errno == ENOENT) ret = 0;
-        if (ret) {
-            LIBXL__LOG_ERRNO(ctx, XTL_ERROR,
-                             "failed to remove device-model savefile %s\n",
-                             savefile);
-            goto out;
-        }
+    if (!pid || !atoi(pid)) {
+        LOG(ERROR, "could not find device-model's pid for dom %u", domid);
+        ret = ERROR_FAIL;
+        goto out;
+    }
+    ret = kill(atoi(pid), SIGHUP);
+    if (ret < 0 && errno == ESRCH) {
+        LOG(ERROR, "Device Model already exited");
+        ret = 0;
+    } else if (ret == 0) {
+        LOG(DEBUG, "Device Model signaled");
+        ret = 0;
     } else {
-        ret = kill(atoi(pid), SIGHUP);
-        if (ret < 0 && errno == ESRCH) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model already exited");
-            ret = 0;
-        } else if (ret == 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model signaled");
-            ret = 0;
-        } else {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to kill Device Model [%d]",
-                    atoi(pid));
-            ret = ERROR_FAIL;
-            goto out;
-        }
+        LOGE(ERROR, "failed to kill Device Model [%d]", atoi(pid));
+        ret = ERROR_FAIL;
+        goto out;
     }
+
     xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid));
     xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid));
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8612fe4..8478606 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -822,7 +822,6 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -1828,6 +1827,7 @@ typedef enum {
 } libxl__device_action;
 
 typedef struct libxl__ao_device libxl__ao_device;
+typedef struct libxl__ao_devices libxl__ao_devices;
 typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
 
 /* This functions sets the necessary libxl__ao_device struct values to use
@@ -1846,6 +1846,20 @@ typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
  */
 _hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
 
+/* Prepare a bunch of devices for addition/removal. Every ao_device in
+ * ao_devices is set to 'active', and the ao_device 'base' filed is set to
+ * the one pointed by aodevs.
+ */
+_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
+                                       libxl__ao_devices *aodevs);
+
+/* Generic callback to use when adding/removing several devices, this will
+ * check if the given aodev is the last one, and call the callback in the
+ * parent libxl__ao_devices struct, passing the appropiate error if found.
+ */
+_hidden void libxl__ao_devices_callback(libxl__egc *egc,
+                                        libxl__ao_device *aodev);
+
 struct libxl__ao_device {
     /* filled in by user */
     libxl__ao *ao;
@@ -1854,8 +1868,25 @@ struct libxl__ao_device {
     int force;
     libxl__device_callback *callback;
     /* private for implementation */
+    int active;
     int rc;
     libxl__ev_devstate backend_ds;
+    /* Used internally to have a reference to the upper libxl__ao_devices
+     * struct when present */
+    libxl__ao_devices *aodevs;
+};
+
+/* Helper struct to simply the plug/unplug of multiple devices at the same
+ * time.
+ *
+ * This structure holds several devices, and the callback is only called
+ * when all the devices inside of the array have finished.
+ */
+typedef void libxl__devices_callback(libxl__egc*, libxl__ao_devices*, int rc);
+struct libxl__ao_devices {
+    libxl__ao_device *array;
+    int size;
+    libxl__devices_callback *callback;
 };
 
 /* Arranges that dev will be removed to the guest, and the
@@ -1870,6 +1901,86 @@ struct libxl__ao_device {
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*----- Domain destruction -----*/
+
+/* Domain destruction has been split into two functions:
+ *
+ * libxl__domain_destroy is the main destroy function, which detects
+ * stubdoms and calls libxl__destroy_domid on the domain and its
+ * stubdom if present, creating a different libxl__destroy_domid_state
+ * for each one of them.
+ *
+ * libxl__destroy_domid actually destroys the domain, but it
+ * doesn't check for stubdomains, since that would involve
+ * recursion, which we want to avoid.
+ */
+
+typedef struct libxl__domain_destroy_state libxl__domain_destroy_state;
+typedef struct libxl__destroy_domid_state libxl__destroy_domid_state;
+typedef struct libxl__devices_remove_state libxl__devices_remove_state;
+
+typedef void libxl__domain_destroy_cb(libxl__egc *egc,
+                                      libxl__domain_destroy_state *dds,
+                                      int rc);
+
+typedef void libxl__domid_destroy_cb(libxl__egc *egc,
+                                     libxl__destroy_domid_state *dis,
+                                     int rc);
+
+typedef void libxl__devices_remove_callback(libxl__egc *egc,
+                                            libxl__devices_remove_state *drs,
+                                            int rc);
+
+struct libxl__devices_remove_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    uint32_t domid;
+    libxl__devices_remove_callback *callback;
+    int force; /* libxl_device_TYPE_destroy rather than _remove */
+    /* private */
+    libxl__ao_devices aodevs;
+    int num_devices;
+};
+
+struct libxl__destroy_domid_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    uint32_t domid;
+    libxl__domid_destroy_cb *callback;
+    /* private to implementation */
+    libxl__devices_remove_state drs;
+};
+
+struct libxl__domain_destroy_state {
+    /* filled by the user */
+    libxl__ao *ao;
+    uint32_t domid;
+    libxl__domain_destroy_cb *callback;
+    /* Private */
+    int rc;
+    uint32_t stubdomid;
+    libxl__destroy_domid_state stubdom;
+    int stubdom_finished;
+    libxl__destroy_domid_state domain;
+    int domain_finished;
+};
+
+/*
+ * Entry point for domain destruction
+ * This function checks for stubdom presence and then calls
+ * libxl__destroy_domid on the passed domain and its stubdom if found.
+ */
+_hidden void libxl__domain_destroy(libxl__egc *egc,
+                                   libxl__domain_destroy_state *dds);
+
+/* Used to destroy a domain with the passed id (it doesn't check for stubs) */
+_hidden void libxl__destroy_domid(libxl__egc *egc,
+                                  libxl__destroy_domid_state *dis);
+
+/* Entry point for devices destruction */
+_hidden void libxl__devices_destroy(libxl__egc *egc,
+                                    libxl__devices_remove_state *drs);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
@@ -1903,6 +2014,7 @@ typedef struct {
     libxl_domain_config dm_config;
     libxl__domain_build_state dm_state;
     libxl__dm_spawn_state pvqemu;
+    libxl__destroy_domid_state dis;
 } libxl__stub_dm_spawn_state;
 
 _hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
@@ -1929,6 +2041,8 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    /* necessary if the domain creation failed and we have to destroy it */
+    libxl__domain_destroy_state dds;
 };
 
 /*
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2ddcdc5..5ba65c2 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1388,7 +1388,7 @@ static int handle_domain_death(uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1986,7 +1986,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2549,7 +2549,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2823,7 +2823,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_resume(ctx, domid, 1);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -3083,7 +3083,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -3236,7 +3236,7 @@ static void migrate_receive(int debug, int daemonize, int monitor,
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 1db777d..4ff3120 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -437,7 +437,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
     int domid;
     if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, 0) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93F-0004a9-8g; Thu, 14 Jun 2012 12:21:25 +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 1Sf93C-0004Y9-FE
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:23 +0000
Received: from [85.158.138.51:14517] by server-10.bemta-3.messagelabs.com id
	9F/7F-01753-147D9DF4; Thu, 14 Jun 2012 12:21:21 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339676478!27639891!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21048 invoked from network); 14 Jun 2012 12:21:20 -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;
	14 Jun 2012 12:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28067777"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Hl;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:05 +0100
Message-ID: <1339676475-33265-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 03/13] libxl: convert libxl_domain_destroy to
	an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 change introduces some new structures, and breaks the mutual
dependency that libxl_domain_destroy and libxl__destroy_device_model
had. This is done by checking if the domid passed to
libxl_domain_destroy has a stubdom, and then having the bulk of the
destroy machinery in a separate function (libxl__destroy_domid) that
doesn't check for stubdom presence, since we check for it in the upper
level function. The reason behind this change is the need to use
structures for ao operations, and it was impossible to have two
different self-referencing structs.

All uses of libxl_domain_destroy have been changed, and either
replaced by the new libxl_domain_destroy ao function or by the
internal libxl__domain_destroy that can be used inside an already
running ao.

Changes since v5:

 * Introduced a new struct, called libxl__ao_devices that will be used
   to simplify the addition/removal of multiple devices at the same
   time.

 * With this function we can use a generic callback for ao_device,
   libxl__ao_devices_callback, that will check if the device is the
   last one and call ao_devices->callback appropiately.

Changes since v4:

 * Fixed spelling mistakes.

 * Always use "force = 1" in device destruction in
   libxl__destroy_domid function.

 * Changed name of domain destroy callbacks to include "destroy".

 * Changed the use of rc to catch syscall errors.

 * Use libxl__remove_file instead of unlink.

 * Changed variable name of number of devices returned by
   libxl__xs_directory.

 * Simplify libxl__ao_device_check_last return.

 * Correctly propagate error returned from libxl__num_devices.

 * Add a comment about the use of libxl__device_destroy to destroy the
   console.

 * Fixed some uses of LIBXL__LOG.

Changes since v3:

 * Fixed python bindings.

Changes since v2:

 * Remove printfs.

 * Replace aorm with aodev.

 * Define an auxiliary libxl__ao_device *aodev to avoid using the long
   expression: drs->aorm[numdev]...

 * Added a common callback for both domain and stubdomain destruction
   that checks if both domains are finished and handles errors
   correctly.

 * Change libxl__ao_device_check_last logic a bit and add a comment
   describing how does it work.

 * Fixed spelling mistakes.

 * Use a do-while for xs transaction in device_remove_callback.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c               |  167 +++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl.h               |    3 +-
 tools/libxl/libxl_create.c        |   29 ++++++-
 tools/libxl/libxl_device.c        |  152 +++++++++++++++++++++++++++++----
 tools/libxl/libxl_dm.c            |   83 +++++++++---------
 tools/libxl/libxl_internal.h      |  116 +++++++++++++++++++++++++-
 tools/libxl/xl_cmdimpl.c          |   12 ++--
 tools/python/xen/lowlevel/xl/xl.c |    2 +-
 8 files changed, 483 insertions(+), 81 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8f5b334..3ad1931 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1146,11 +1146,133 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
     GC_FREE;
 }    
 
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
+/* Callbacks for libxl_domain_destroy */
+
+static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
+                              int rc);
+
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_destroy_state *dds;
+
+    GCNEW(dds);
+    dds->ao = ao;
+    dds->domid = domid;
+    dds->callback = domain_destroy_cb;
+    libxl__domain_destroy(egc, dds);
+
+    return AO_INPROGRESS;
+}
+
+static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
+                              int rc)
+{
+    STATE_AO_GC(dds->ao);
+
+    if (rc)
+        LOG(ERROR, "destruction of domain %u failed", dds->domid);
+
+    libxl__ao_complete(egc, ao, rc);
+}
+
+/* Callbacks for libxl__domain_destroy */
+
+static void stubdom_destroy_callback(libxl__egc *egc,
+                                     libxl__destroy_domid_state *dis,
+                                     int rc);
+
+static void domain_destroy_callback(libxl__egc *egc,
+                                    libxl__destroy_domid_state *dis,
+                                    int rc);
+
+static void destroy_finish_check(libxl__egc *egc,
+                                 libxl__domain_destroy_state *dds);
+
+void libxl__domain_destroy(libxl__egc *egc, libxl__domain_destroy_state *dds)
+{
+    STATE_AO_GC(dds->ao);
+    uint32_t stubdomid = libxl_get_stubdom_id(CTX, dds->domid);
+
+    if (stubdomid) {
+        dds->stubdom.ao = ao;
+        dds->stubdom.domid = stubdomid;
+        dds->stubdom.callback = stubdom_destroy_callback;
+        libxl__destroy_domid(egc, &dds->stubdom);
+    } else {
+        dds->stubdom_finished = 1;
+    }
+
+    dds->domain.ao = ao;
+    dds->domain.domid = dds->domid;
+    dds->domain.callback = domain_destroy_callback;
+    libxl__destroy_domid(egc, &dds->domain);
+}
+
+static void stubdom_destroy_callback(libxl__egc *egc,
+                                     libxl__destroy_domid_state *dis,
+                                     int rc)
+{
+    STATE_AO_GC(dis->ao);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, stubdom);
+    const char *savefile;
+
+    if (rc) {
+        LOG(ERROR, "unable to destroy stubdom with domid %u", dis->domid);
+        dds->rc = rc;
+    }
+
+    dds->stubdom_finished = 1;
+    savefile = libxl__device_model_savefile(gc, dis->domid);
+    rc = libxl__remove_file(gc, savefile);
+    /*
+     * On suspend libxl__domain_save_device_model will have already
+     * unlinked the save file.
+     */
+    if (rc) {
+        LOG(ERROR, "failed to remove device-model savefile %s", savefile);
+    }
+
+    destroy_finish_check(egc, dds);
+}
+
+static void domain_destroy_callback(libxl__egc *egc,
+                                    libxl__destroy_domid_state *dis,
+                                    int rc)
+{
+    STATE_AO_GC(dis->ao);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
+
+    if (rc) {
+        LOG(ERROR, "unable to destroy guest with domid %u", dis->domid);
+        dds->rc = rc;
+    }
+
+    dds->domain_finished = 1;
+    destroy_finish_check(egc, dds);
+}
+
+static void destroy_finish_check(libxl__egc *egc,
+                                 libxl__domain_destroy_state *dds)
+{
+    if (!(dds->domain_finished && dds->stubdom_finished))
+        return;
+
+    dds->callback(egc, dds, dds->rc);
+}
+
+/* Callbacks for libxl__destroy_domid */
+static void devices_destroy_cb(libxl__egc *egc,
+                               libxl__devices_remove_state *drs,
+                               int rc);
+
+void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
+{
+    STATE_AO_GC(dis->ao);
+    libxl_ctx *ctx = CTX;
+    uint32_t domid = dis->domid;
     char *dom_path;
-    char *vm_path;
     char *pid;
     int rc, dm_present;
 
@@ -1161,7 +1283,7 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
     case ERROR_INVAL:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid);
     default:
-        return rc;
+        goto out;
     }
 
     switch (libxl__domain_type(gc, domid)) {
@@ -1194,7 +1316,37 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
+    dis->drs.ao = ao;
+    dis->drs.domid = domid;
+    dis->drs.callback = devices_destroy_cb;
+    dis->drs.force = 1;
+    libxl__devices_destroy(egc, &dis->drs);
+    return;
+
+out:
+    assert(rc);
+    dis->callback(egc, dis, rc);
+    return;
+}
+
+static void devices_destroy_cb(libxl__egc *egc,
+                               libxl__devices_remove_state *drs,
+                               int rc)
+{
+    STATE_AO_GC(drs->ao);
+    libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
+    libxl_ctx *ctx = CTX;
+    uint32_t domid = dis->domid;
+    char *dom_path;
+    char *vm_path;
+
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (rc < 0)
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
                    "libxl__devices_destroy failed for %d", domid);
 
@@ -1217,9 +1369,10 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         goto out;
     }
     rc = 0;
+
 out:
-    GC_FREE;
-    return rc;
+    dis->callback(egc, dis, rc);
+    return;
 }
 
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index bb3beaf..1967e66 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -526,7 +526,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
-int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
+                         const libxl_asyncop_how *ao_how);
 int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid);
 
 /* get max. number of cpus supported by hypervisor */
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4456ae8..a47bef7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -590,6 +590,12 @@ static void domcreate_complete(libxl__egc *egc,
                                libxl__domain_create_state *dcs,
                                int rc);
 
+/* If creation is not successful, this callback will be executed
+ * when domain destruction is finished */
+static void domcreate_destruction_cb(libxl__egc *egc,
+                                     libxl__domain_destroy_state *dds,
+                                     int rc);
+
 static void initiate_domain_create(libxl__egc *egc,
                                    libxl__domain_create_state *dcs)
 {
@@ -855,16 +861,31 @@ static void domcreate_complete(libxl__egc *egc,
 
     if (rc) {
         if (dcs->guest_domid) {
-            int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid);
-            if (rc2)
-                LOG(ERROR, "unable to destroy domain %d following"
-                    " failed creation", dcs->guest_domid);
+            dcs->dds.ao = ao;
+            dcs->dds.domid = dcs->guest_domid;
+            dcs->dds.callback = domcreate_destruction_cb;
+            libxl__domain_destroy(egc, &dcs->dds);
+            return;
         }
         dcs->guest_domid = -1;
     }
     dcs->callback(egc, dcs, rc, dcs->guest_domid);
 }
 
+static void domcreate_destruction_cb(libxl__egc *egc,
+                                     libxl__domain_destroy_state *dds,
+                                     int rc)
+{
+    STATE_AO_GC(dds->ao);
+    libxl__domain_create_state *dcs = CONTAINER_OF(dds, *dcs, dds);
+
+    if (rc)
+        LOG(ERROR, "unable to destroy domain %u following failed creation",
+                   dds->domid);
+
+    dcs->callback(egc, dcs, ERROR_FAIL, dcs->guest_domid);
+}
+
 /*----- application-facing domain creation interface -----*/
 
 typedef struct {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8ba1915..9243806 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -58,6 +58,48 @@ int libxl__parse_backend_path(libxl__gc *gc,
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+static int libxl__num_devices(libxl__gc *gc, uint32_t domid)
+{
+    char *path;
+    unsigned int num_kinds, num_devs;
+    char **kinds = NULL, **devs = NULL;
+    int i, j, rc = 0;
+    libxl__device dev;
+    libxl__device_kind kind;
+    int numdevs = 0;
+
+    path = GCSPRINTF("/local/domain/%d/device", domid);
+    kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
+    if (!kinds) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "unable to get xenstore device listing %s", path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        num_kinds = 0;
+    }
+    for (i = 0; i < num_kinds; i++) {
+        if (libxl__device_kind_from_string(kinds[i], &kind))
+            continue;
+
+        path = GCSPRINTF("/local/domain/%d/device/%s", domid, kinds[i]);
+        devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs);
+        if (!devs)
+            continue;
+        for (j = 0; j < num_devs; j++) {
+            path = GCSPRINTF("/local/domain/%d/device/%s/%s/backend",
+                             domid, kinds[i], devs[j]);
+            path = libxl__xs_read(gc, XBT_NULL, path);
+            if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
+                numdevs++;
+            }
+        }
+    }
+out:
+    if (rc) return rc;
+    return numdevs;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
         libxl__device *device, char **bents, char **fents)
 {
@@ -367,6 +409,37 @@ void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev)
 {
     aodev->ao = ao;
     aodev->rc = 0;
+    aodev->active = 1;
+}
+
+void libxl__prepare_ao_devices(libxl__ao *ao, libxl__ao_devices *aodevs)
+{
+    AO_GC;
+
+    GCNEW_ARRAY(aodevs->array, aodevs->size);
+    for (int i = 0; i < aodevs->size; i++) {
+        aodevs->array[i].aodevs = aodevs;
+        libxl__prepare_ao_device(ao, &aodevs->array[i]);
+    }
+}
+
+void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    libxl__ao_devices *aodevs = aodev->aodevs;
+    int i, error = 0;
+
+    aodev->active = 0;
+    for (i = 0; i < aodevs->size; i++) {
+        if (aodevs->array[i].active)
+            return;
+
+        if (aodevs->array[i].rc)
+            error = aodevs->array[i].rc;
+    }
+
+    aodevs->callback(egc, aodevs, error);
+    return;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
@@ -383,16 +456,35 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
     return 0;
 }
 
-int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
+/* Callback for device destruction */
+
+static void devices_remove_callback(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                    int rc);
+
+void libxl__devices_destroy(libxl__egc *egc, libxl__devices_remove_state *drs)
 {
+    STATE_AO_GC(drs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    uint32_t domid = drs->domid;
     char *path;
-    unsigned int num_kinds, num_devs;
+    unsigned int num_kinds, num_dev_xsentries;
     char **kinds = NULL, **devs = NULL;
-    int i, j;
-    libxl__device dev;
+    int i, j, numdev = 0, rc = 0;
+    libxl__device *dev;
+    libxl__ao_devices *aodevs = &drs->aodevs;
+    libxl__ao_device *aodev;
     libxl__device_kind kind;
 
+    aodevs->size = libxl__num_devices(gc, drs->domid);
+    if (aodevs->size < 0) {
+        LOG(ERROR, "unable to get number of devices for domain %u", drs->domid);
+        rc = aodevs->size;
+        goto out;
+    }
+
+    libxl__prepare_ao_devices(drs->ao, aodevs);
+    aodevs->callback = devices_remove_callback;
+
     path = libxl__sprintf(gc, "/local/domain/%d/device", domid);
     kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds);
     if (!kinds) {
@@ -408,19 +500,25 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
             continue;
 
         path = libxl__sprintf(gc, "/local/domain/%d/device/%s", domid, kinds[i]);
-        devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs);
+        devs = libxl__xs_directory(gc, XBT_NULL, path, &num_dev_xsentries);
         if (!devs)
             continue;
-        for (j = 0; j < num_devs; j++) {
+        for (j = 0; j < num_dev_xsentries; j++) {
             path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend",
                                   domid, kinds[i], devs[j]);
             path = libxl__xs_read(gc, XBT_NULL, path);
-            if (path && libxl__parse_backend_path(gc, path, &dev) == 0) {
-                dev.domid = domid;
-                dev.kind = kind;
-                dev.devid = atoi(devs[j]);
-
-                libxl__device_destroy(gc, &dev);
+            GCNEW(dev);
+            if (path && libxl__parse_backend_path(gc, path, dev) == 0) {
+                aodev = &aodevs->array[numdev];
+                dev->domid = domid;
+                dev->kind = kind;
+                dev->devid = atoi(devs[j]);
+                aodev->action = DEVICE_DISCONNECT;
+                aodev->dev = dev;
+                aodev->callback = libxl__ao_devices_callback;
+                aodev->force = drs->force;
+                libxl__initiate_device_remove(egc, aodev);
+                numdev++;
             }
         }
     }
@@ -428,17 +526,22 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
     /* console 0 frontend directory is not under /local/domain/<domid>/device */
     path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid);
     path = libxl__xs_read(gc, XBT_NULL, path);
+    GCNEW(dev);
     if (path && strcmp(path, "") &&
-        libxl__parse_backend_path(gc, path, &dev) == 0) {
-        dev.domid = domid;
-        dev.kind = LIBXL__DEVICE_KIND_CONSOLE;
-        dev.devid = 0;
-
-        libxl__device_destroy(gc, &dev);
+        libxl__parse_backend_path(gc, path, dev) == 0) {
+        dev->domid = domid;
+        dev->kind = LIBXL__DEVICE_KIND_CONSOLE;
+        dev->devid = 0;
+
+        /* Currently console devices can be destroyed synchronously by just
+         * removing xenstore entries, this is what libxl__device_destroy does.
+         */
+        libxl__device_destroy(gc, dev);
     }
 
 out:
-    return 0;
+    if (!numdev) drs->callback(egc, drs, rc);
+    return;
 }
 
 /* Callbacks for device related operations */
@@ -524,6 +627,7 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     } else if (rc) {
         LOG(DEBUG, "unable to disconnect device with path %s",
                    libxl__device_backend_path(gc, aodev->dev));
+        rc = 0;
         goto out;
     }
 
@@ -565,6 +669,16 @@ static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
     return;
 }
 
+static void devices_remove_callback(libxl__egc *egc, libxl__ao_devices *aodevs,
+                                    int rc)
+{
+    libxl__devices_remove_state *drs = CONTAINER_OF(aodevs, *drs, aodevs);
+    STATE_AO_GC(drs->ao);
+
+    drs->callback(egc, drs, rc);
+    return;
+}
+
 int libxl__wait_for_device_model(libxl__gc *gc,
                                  uint32_t domid, char *state,
                                  libxl__spawn_starting *spawning,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..e5d666a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -677,6 +677,10 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
                                 libxl__dm_spawn_state *stubdom_dmss,
                                 int rc);
 
+static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
+                                           libxl__destroy_domid_state *dis,
+                                           int rc);
+
 void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
 {
     STATE_AO_GC(sdss->dm.spawn.ao);
@@ -897,12 +901,31 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
 
  out:
     if (rc) {
-        if (dm_domid)
-            libxl_domain_destroy(CTX, dm_domid);
+        if (dm_domid) {
+            sdss->dis.ao = ao;
+            sdss->dis.domid = dm_domid;
+            sdss->dis.callback = spaw_stubdom_pvqemu_destroy_cb;
+            libxl__destroy_domid(egc, &sdss->dis);
+            return;
+        }
     }
     sdss->callback(egc, &sdss->dm, rc);
 }
 
+static void spaw_stubdom_pvqemu_destroy_cb(libxl__egc *egc,
+                                           libxl__destroy_domid_state *dis,
+                                           int rc)
+{
+    libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(dis, *sdss, dis);
+    STATE_AO_GC(sdss->dis.ao);
+
+    if (rc)
+        LOG(ERROR, "destruction of domain %u after failed creation failed",
+                   sdss->pvqemu.guest_domid);
+
+    sdss->callback(egc, &sdss->dm, rc);
+}
+
 /* callbacks passed to libxl__spawn_spawn */
 static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
@@ -1095,48 +1118,24 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
     int ret;
 
     pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
-    if (!pid) {
-        int stubdomid = libxl_get_stubdom_id(ctx, domid);
-        const char *savefile;
-
-        if (!stubdomid) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid");
-            ret = ERROR_INVAL;
-            goto out;
-        }
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid);
-        ret = libxl_domain_destroy(ctx, stubdomid);
-        if (ret)
-            goto out;
-
-        savefile = libxl__device_model_savefile(gc, domid);
-        ret = unlink(savefile);
-        /*
-         * On suspend libxl__domain_save_device_model will have already
-         * unlinked the save file.
-         */
-        if (ret && errno == ENOENT) ret = 0;
-        if (ret) {
-            LIBXL__LOG_ERRNO(ctx, XTL_ERROR,
-                             "failed to remove device-model savefile %s\n",
-                             savefile);
-            goto out;
-        }
+    if (!pid || !atoi(pid)) {
+        LOG(ERROR, "could not find device-model's pid for dom %u", domid);
+        ret = ERROR_FAIL;
+        goto out;
+    }
+    ret = kill(atoi(pid), SIGHUP);
+    if (ret < 0 && errno == ESRCH) {
+        LOG(ERROR, "Device Model already exited");
+        ret = 0;
+    } else if (ret == 0) {
+        LOG(DEBUG, "Device Model signaled");
+        ret = 0;
     } else {
-        ret = kill(atoi(pid), SIGHUP);
-        if (ret < 0 && errno == ESRCH) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model already exited");
-            ret = 0;
-        } else if (ret == 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model signaled");
-            ret = 0;
-        } else {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to kill Device Model [%d]",
-                    atoi(pid));
-            ret = ERROR_FAIL;
-            goto out;
-        }
+        LOGE(ERROR, "failed to kill Device Model [%d]", atoi(pid));
+        ret = ERROR_FAIL;
+        goto out;
     }
+
     xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid));
     xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid));
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8612fe4..8478606 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -822,7 +822,6 @@ _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
-_hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
 /*
@@ -1828,6 +1827,7 @@ typedef enum {
 } libxl__device_action;
 
 typedef struct libxl__ao_device libxl__ao_device;
+typedef struct libxl__ao_devices libxl__ao_devices;
 typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
 
 /* This functions sets the necessary libxl__ao_device struct values to use
@@ -1846,6 +1846,20 @@ typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*);
  */
 _hidden void libxl__prepare_ao_device(libxl__ao *ao, libxl__ao_device *aodev);
 
+/* Prepare a bunch of devices for addition/removal. Every ao_device in
+ * ao_devices is set to 'active', and the ao_device 'base' filed is set to
+ * the one pointed by aodevs.
+ */
+_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
+                                       libxl__ao_devices *aodevs);
+
+/* Generic callback to use when adding/removing several devices, this will
+ * check if the given aodev is the last one, and call the callback in the
+ * parent libxl__ao_devices struct, passing the appropiate error if found.
+ */
+_hidden void libxl__ao_devices_callback(libxl__egc *egc,
+                                        libxl__ao_device *aodev);
+
 struct libxl__ao_device {
     /* filled in by user */
     libxl__ao *ao;
@@ -1854,8 +1868,25 @@ struct libxl__ao_device {
     int force;
     libxl__device_callback *callback;
     /* private for implementation */
+    int active;
     int rc;
     libxl__ev_devstate backend_ds;
+    /* Used internally to have a reference to the upper libxl__ao_devices
+     * struct when present */
+    libxl__ao_devices *aodevs;
+};
+
+/* Helper struct to simply the plug/unplug of multiple devices at the same
+ * time.
+ *
+ * This structure holds several devices, and the callback is only called
+ * when all the devices inside of the array have finished.
+ */
+typedef void libxl__devices_callback(libxl__egc*, libxl__ao_devices*, int rc);
+struct libxl__ao_devices {
+    libxl__ao_device *array;
+    int size;
+    libxl__devices_callback *callback;
 };
 
 /* Arranges that dev will be removed to the guest, and the
@@ -1870,6 +1901,86 @@ struct libxl__ao_device {
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*----- Domain destruction -----*/
+
+/* Domain destruction has been split into two functions:
+ *
+ * libxl__domain_destroy is the main destroy function, which detects
+ * stubdoms and calls libxl__destroy_domid on the domain and its
+ * stubdom if present, creating a different libxl__destroy_domid_state
+ * for each one of them.
+ *
+ * libxl__destroy_domid actually destroys the domain, but it
+ * doesn't check for stubdomains, since that would involve
+ * recursion, which we want to avoid.
+ */
+
+typedef struct libxl__domain_destroy_state libxl__domain_destroy_state;
+typedef struct libxl__destroy_domid_state libxl__destroy_domid_state;
+typedef struct libxl__devices_remove_state libxl__devices_remove_state;
+
+typedef void libxl__domain_destroy_cb(libxl__egc *egc,
+                                      libxl__domain_destroy_state *dds,
+                                      int rc);
+
+typedef void libxl__domid_destroy_cb(libxl__egc *egc,
+                                     libxl__destroy_domid_state *dis,
+                                     int rc);
+
+typedef void libxl__devices_remove_callback(libxl__egc *egc,
+                                            libxl__devices_remove_state *drs,
+                                            int rc);
+
+struct libxl__devices_remove_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    uint32_t domid;
+    libxl__devices_remove_callback *callback;
+    int force; /* libxl_device_TYPE_destroy rather than _remove */
+    /* private */
+    libxl__ao_devices aodevs;
+    int num_devices;
+};
+
+struct libxl__destroy_domid_state {
+    /* filled in by user */
+    libxl__ao *ao;
+    uint32_t domid;
+    libxl__domid_destroy_cb *callback;
+    /* private to implementation */
+    libxl__devices_remove_state drs;
+};
+
+struct libxl__domain_destroy_state {
+    /* filled by the user */
+    libxl__ao *ao;
+    uint32_t domid;
+    libxl__domain_destroy_cb *callback;
+    /* Private */
+    int rc;
+    uint32_t stubdomid;
+    libxl__destroy_domid_state stubdom;
+    int stubdom_finished;
+    libxl__destroy_domid_state domain;
+    int domain_finished;
+};
+
+/*
+ * Entry point for domain destruction
+ * This function checks for stubdom presence and then calls
+ * libxl__destroy_domid on the passed domain and its stubdom if found.
+ */
+_hidden void libxl__domain_destroy(libxl__egc *egc,
+                                   libxl__domain_destroy_state *dds);
+
+/* Used to destroy a domain with the passed id (it doesn't check for stubs) */
+_hidden void libxl__destroy_domid(libxl__egc *egc,
+                                  libxl__destroy_domid_state *dis);
+
+/* Entry point for devices destruction */
+_hidden void libxl__devices_destroy(libxl__egc *egc,
+                                    libxl__devices_remove_state *drs);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
@@ -1903,6 +2014,7 @@ typedef struct {
     libxl_domain_config dm_config;
     libxl__domain_build_state dm_state;
     libxl__dm_spawn_state pvqemu;
+    libxl__destroy_domid_state dis;
 } libxl__stub_dm_spawn_state;
 
 _hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*);
@@ -1929,6 +2041,8 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    /* necessary if the domain creation failed and we have to destroy it */
+    libxl__domain_destroy_state dds;
 };
 
 /*
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2ddcdc5..5ba65c2 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1388,7 +1388,7 @@ static int handle_domain_death(uint32_t domid,
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1986,7 +1986,7 @@ start:
 error_out:
     release_lock();
     if (libxl_domid_valid_guest(domid))
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
 out:
     if (logfile != 2)
@@ -2549,7 +2549,7 @@ static void destroy_domain(const char *p)
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
     }
-    rc = libxl_domain_destroy(ctx, domid);
+    rc = libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
@@ -2823,7 +2823,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
     if (checkpoint)
         libxl_domain_resume(ctx, domid, 1);
     else
-        libxl_domain_destroy(ctx, domid);
+        libxl_domain_destroy(ctx, domid, 0);
 
     exit(0);
 }
@@ -3083,7 +3083,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     }
 
     fprintf(stderr, "migration sender: Target reports successful startup.\n");
-    libxl_domain_destroy(ctx, domid); /* bang! */
+    libxl_domain_destroy(ctx, domid, 0); /* bang! */
     fprintf(stderr, "Migration successful.\n");
     exit(0);
 
@@ -3236,7 +3236,7 @@ static void migrate_receive(int debug, int daemonize, int monitor,
     if (rc) {
         fprintf(stderr, "migration target: Failure, destroying our copy.\n");
 
-        rc2 = libxl_domain_destroy(ctx, domid);
+        rc2 = libxl_domain_destroy(ctx, domid, 0);
         if (rc2) {
             fprintf(stderr, "migration target: Failed to destroy our copy"
                     " (code %d).\n", rc2);
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 1db777d..4ff3120 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -437,7 +437,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args)
     int domid;
     if ( !PyArg_ParseTuple(args, "i", &domid) )
         return NULL;
-    if ( libxl_domain_destroy(self->ctx, domid) ) {
+    if ( libxl_domain_destroy(self->ctx, domid, 0) ) {
         PyErr_SetString(xl_error_obj, "cannot destroy domain");
         return NULL;
     }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93X-0004nP-Qs; Thu, 14 Jun 2012 12:21:43 +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 1Sf93W-0004mF-M8
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:42 +0000
Received: from [85.158.139.83:4066] by server-12.bemta-5.messagelabs.com id
	22/13-12933-557D9DF4; Thu, 14 Jun 2012 12:21:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339676500!23398350!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13713 invoked from network); 14 Jun 2012 12:21:41 -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;
	14 Jun 2012 12:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198739836"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Dy	for xen-devel@lists.xen.org;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:02 +0100
Message-ID: <1339676475-33265-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 v6 00/13] execute hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series have been splitted in several patches, to make them easier
to review. Also the amount of changes introduced is quite important,
since apart from all the hotplug necessary functions and
modifications, libxl_domain_destroy has been converted to an async op.
This was necessary in order to have async operations during device
removal.

Also, as an important change, disk and nics are added at different
points for HVM and device model based guests, since we need the disk
in order to start Qemu, but the nic hotplug scripts should be called
at a later point, when Qemu has created the corresponding tap device.

This version includes two new relevant changes:

 * Rename IOEMU nic type to VIF_IOEMU (patch 9).

 * Conversion of libxl__device_disk_local_attach to an async 
   operation (patch 5).

Acked:

[PATCH v6 02/13] libxl: move device model creation prototypes
[PATCH v6 03/13] libxl: convert libxl_domain_destroy to an async op
[PATCH v6 08/13] libxl: add option to choose who executes hotplug
[PATCH v6 11/13] libxl: use libxl__xs_path_cleanup on device_destroy

Pending:

[PATCH v6 01/13] libxl: change ao_device_remove to ao_device
[PATCH v6 04/13] libxl: move bootloader data strucutres and
[PATCH v6 05/13] libxl: convert libxl__device_disk_local_attach to
[PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op
[PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async
[PATCH v6 09/13] libxl: rename _IOEMU nic type to VIF_IOEMU
[PATCH v6 10/13] libxl: set nic type to VIF by default
[PATCH v6 12/13] libxl: call hotplug scripts for disk devices from
[PATCH v6 13/13] libxl: call hotplug scripts for nic devices from

Thanks for reviewing, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:21: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 1Sf93X-0004nP-Qs; Thu, 14 Jun 2012 12:21:43 +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 1Sf93W-0004mF-M8
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:21:42 +0000
Received: from [85.158.139.83:4066] by server-12.bemta-5.messagelabs.com id
	22/13-12933-557D9DF4; Thu, 14 Jun 2012 12:21:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339676500!23398350!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13713 invoked from network); 14 Jun 2012 12:21:41 -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;
	14 Jun 2012 12:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198739836"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:21:11 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:21:12 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Dy	for xen-devel@lists.xen.org;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:02 +0100
Message-ID: <1339676475-33265-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 v6 00/13] execute hotplug scripts from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series have been splitted in several patches, to make them easier
to review. Also the amount of changes introduced is quite important,
since apart from all the hotplug necessary functions and
modifications, libxl_domain_destroy has been converted to an async op.
This was necessary in order to have async operations during device
removal.

Also, as an important change, disk and nics are added at different
points for HVM and device model based guests, since we need the disk
in order to start Qemu, but the nic hotplug scripts should be called
at a later point, when Qemu has created the corresponding tap device.

This version includes two new relevant changes:

 * Rename IOEMU nic type to VIF_IOEMU (patch 9).

 * Conversion of libxl__device_disk_local_attach to an async 
   operation (patch 5).

Acked:

[PATCH v6 02/13] libxl: move device model creation prototypes
[PATCH v6 03/13] libxl: convert libxl_domain_destroy to an async op
[PATCH v6 08/13] libxl: add option to choose who executes hotplug
[PATCH v6 11/13] libxl: use libxl__xs_path_cleanup on device_destroy

Pending:

[PATCH v6 01/13] libxl: change ao_device_remove to ao_device
[PATCH v6 04/13] libxl: move bootloader data strucutres and
[PATCH v6 05/13] libxl: convert libxl__device_disk_local_attach to
[PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op
[PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async
[PATCH v6 09/13] libxl: rename _IOEMU nic type to VIF_IOEMU
[PATCH v6 10/13] libxl: set nic type to VIF by default
[PATCH v6 12/13] libxl: call hotplug scripts for disk devices from
[PATCH v6 13/13] libxl: call hotplug scripts for nic devices from

Thanks for reviewing, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:43: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 1Sf9O8-0006sM-Oe; Thu, 14 Jun 2012 12:43:00 +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 1Sf9O6-0006sF-U7
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:42:59 +0000
Received: from [85.158.138.51:45569] by server-9.bemta-3.messagelabs.com id
	03/0E-10419-25CD9DF4; Thu, 14 Jun 2012 12:42:58 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339677776!27697623!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20295 invoked from network); 14 Jun 2012 12:42:57 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:42:57 -0000
Received: by qcsp15 with SMTP id p15so1342770qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 05:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=HxCt894YvqgAz/n6PUeA2dAA4sNxbyezhApZfLca/nM=;
	b=qX3JxKBQhBuYYp/JS5jSx3OSuExD3KOwaE71eB6VAP6XhFU4SD39wP6i5u2E6hDuDw
	LbHY2VLXNe7tvxuO3XpcTRKjult0ZHxIP4JzmkmLx+r1qXXkn6crZHfMEr9azZWQV/p9
	WRw4jfXa5JUdPMgpo/e5TYc8TbDMFQ5mHX4uG8hQ0rs9J+OGltF3hAM5UBwodh92ESVO
	VXJTi5qKpbZy3us8RFxbHIczwdXlU5vqW//cZDaku//WkeyrE4ULX+HlH3mPdatvWcjR
	s3ja2YlznDP3ctjFYWc0iA8NuoRttB+a1P8jLk6vxLyXuVdjtT7DVubuc+rmPoAAeN8y
	xcRg==
MIME-Version: 1.0
Received: by 10.229.134.206 with SMTP id k14mr821852qct.25.1339677776025; Thu,
	14 Jun 2012 05:42:56 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 14 Jun 2012 05:42:55 -0700 (PDT)
In-Reply-To: <20120614091131.GD82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
	<20120614091131.GD82539@ocelot.phlegethon.org>
Date: Thu, 14 Jun 2012 13:42:55 +0100
X-Google-Sender-Auth: nxPZGUT0VC9BbldNarnpB_kuae0
Message-ID: <CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
 pod: Only sweep in an emergency, and only for 4k 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="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, Jun 14, 2012 at 10:11 AM, Tim Deegan <tim@xen.org> wrote:
> At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
>> + =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> + =A0 =A0 =A0 =A0goto out_of_memory;
>>
>> =A0 =A0 =A0/* Keep track of the highest gfn demand-populated by a guest =
fault */
>> =A0 =A0 =A0if ( gfn > p2m->pod.max_guest )
>> =A0 =A0 =A0 =A0 =A0p2m->pod.max_guest =3D gfn;
>>
>> - =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> - =A0 =A0 =A0 =A0goto out_of_memory;
>> -
>
> Is this code motion just noise? =A0Since out_of_memory crasheds the guest,
> I assume so.

It will have no practical effect, other than improving the efficiency
of crashing a guest by a few cycles, if that's what you're asking.
It's more about taste: it just seemed silly to make an assignment and
*then* see if you were going to crash. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:43: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 1Sf9O8-0006sM-Oe; Thu, 14 Jun 2012 12:43:00 +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 1Sf9O6-0006sF-U7
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:42:59 +0000
Received: from [85.158.138.51:45569] by server-9.bemta-3.messagelabs.com id
	03/0E-10419-25CD9DF4; Thu, 14 Jun 2012 12:42:58 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339677776!27697623!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20295 invoked from network); 14 Jun 2012 12:42:57 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 12:42:57 -0000
Received: by qcsp15 with SMTP id p15so1342770qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 05:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=HxCt894YvqgAz/n6PUeA2dAA4sNxbyezhApZfLca/nM=;
	b=qX3JxKBQhBuYYp/JS5jSx3OSuExD3KOwaE71eB6VAP6XhFU4SD39wP6i5u2E6hDuDw
	LbHY2VLXNe7tvxuO3XpcTRKjult0ZHxIP4JzmkmLx+r1qXXkn6crZHfMEr9azZWQV/p9
	WRw4jfXa5JUdPMgpo/e5TYc8TbDMFQ5mHX4uG8hQ0rs9J+OGltF3hAM5UBwodh92ESVO
	VXJTi5qKpbZy3us8RFxbHIczwdXlU5vqW//cZDaku//WkeyrE4ULX+HlH3mPdatvWcjR
	s3ja2YlznDP3ctjFYWc0iA8NuoRttB+a1P8jLk6vxLyXuVdjtT7DVubuc+rmPoAAeN8y
	xcRg==
MIME-Version: 1.0
Received: by 10.229.134.206 with SMTP id k14mr821852qct.25.1339677776025; Thu,
	14 Jun 2012 05:42:56 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 14 Jun 2012 05:42:55 -0700 (PDT)
In-Reply-To: <20120614091131.GD82539@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
	<20120614091131.GD82539@ocelot.phlegethon.org>
Date: Thu, 14 Jun 2012 13:42:55 +0100
X-Google-Sender-Auth: nxPZGUT0VC9BbldNarnpB_kuae0
Message-ID: <CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
 pod: Only sweep in an emergency, and only for 4k 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="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, Jun 14, 2012 at 10:11 AM, Tim Deegan <tim@xen.org> wrote:
> At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
>> + =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> + =A0 =A0 =A0 =A0goto out_of_memory;
>>
>> =A0 =A0 =A0/* Keep track of the highest gfn demand-populated by a guest =
fault */
>> =A0 =A0 =A0if ( gfn > p2m->pod.max_guest )
>> =A0 =A0 =A0 =A0 =A0p2m->pod.max_guest =3D gfn;
>>
>> - =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> - =A0 =A0 =A0 =A0goto out_of_memory;
>> -
>
> Is this code motion just noise? =A0Since out_of_memory crasheds the guest,
> I assume so.

It will have no practical effect, other than improving the efficiency
of crashing a guest by a few cycles, if that's what you're asking.
It's more about taste: it just seemed silly to make an assignment and
*then* see if you were going to crash. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9Qv-00070T-MM; Thu, 14 Jun 2012 12:45:53 +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 1Sf9Qu-000702-Jn
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:53 +0000
Received: from [85.158.138.51:20511] by server-8.bemta-3.messagelabs.com id
	60/E6-06157-FFCD9DF4; Thu, 14 Jun 2012 12:45:51 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339677948!27723273!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23568 invoked from network); 14 Jun 2012 12:45:50 -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;
	14 Jun 2012 12:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28070414"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:48 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-QZ;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:14 +0100
Message-ID: <1339676475-33265-13-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 12/13] libxl: call hotplug scripts for disk
	devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since most of the needed work is already done in previous patches,
this patch only contains the necessary code to call hotplug scripts
for disk devices, that should be called when the device is added or
removed from a guest.

We will chain the launch of the disk hotplug scripts after the
device_backend_callback callback, or directly from
libxl__initiate_device_{add,remove} if the device is already in the
desired state.

Changes since v5:

 * Added common exit point using the device_hotplug_done function.

 * Changed the "what" field in ao_device to "const char *".

Changes since v4:

 * Init args and env to NULL.

 * Correctly propagate errors from libxl__get_hotplug_script_info.

 * Replaced if in libxl__ev_child_inuse with asserts.

 * Renamed fork_cb to child_death_cb.

 * Move deregistration of device_hotplug_timeout_cb to the top of the
   function.

 * Removed "pid" field from libxl__ao_device struct.

 * Moved arraysize declaration.

 * Fixed diff complain about no newline at the end of libxl_netbsd.c.

Changes since v2:

 * Added array size check with assert.

 * Added NetBSD code (so compilation is not broken).

 * Removed a check for null in device_hotplug_timeout_cb.

Changes since v1:

 * Moved all the event related code that was inside libxl_linux.c into
   libxl_device.c, so the flow of the device addition/removal event is
   all in the same file.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules     |    6 +-
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
 tools/libxl/libxl.c                       |   10 ++
 tools/libxl/libxl_device.c                |  129 +++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h              |   19 ++++
 tools/libxl/libxl_linux.c                 |  100 ++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c                |    8 ++
 7 files changed, 270 insertions(+), 8 deletions(-)

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 405387f..d55ff11 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..4a7bc73 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts from udev if the domain
+# has been launched from libxl
+if [ -n "${UDEV_CALL}" ] && \
+   xenstore-read "libxl/disable_udev" >/dev/null 2>&1; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 44c8442..0205b11 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1708,6 +1708,11 @@ void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, GCSPRINTF("%s/%s",
+                                             libxl__xen_script_dir_path(),
+                                             "block"));
+
             assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1723,6 +1728,11 @@ void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, GCSPRINTF("%s/%s",
+                                             libxl__xen_script_dir_path(),
+                                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index ca51577..fcbead6 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -602,7 +602,16 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
 static void device_backend_cleanup(libxl__gc *gc,
                                    libxl__ao_device *aodev);
 
-static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev);
+static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev);
+
+static void device_hotplug_timeout_cb(libxl__egc *egc, libxl__ev_time *ev,
+                                      const struct timeval *requested_abs);
+
+static void device_hotplug_child_death_cb(libxl__egc *egc,
+                                          libxl__ev_child *child,
+                                          pid_t pid, int status);
+
+static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev);
 
 void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
 {
@@ -630,7 +639,7 @@ void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
 out_fail:
     assert(rc);
     aodev->rc = rc;
-    device_xsentries_remove(egc, aodev);
+    device_hotplug_child_death_cb(egc, &aodev->child, 0, 0);
     return;
 }
 
@@ -678,7 +687,7 @@ retry_transaction:
  out_fail:
     assert(rc);
     aodev->rc = rc;
-    device_xsentries_remove(egc, aodev);
+    device_hotplug_child_death_cb(egc, &aodev->child, 0, 0);
     return;
 }
 
@@ -696,6 +705,11 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
         return;
     }
 
+    /* We init this here because we might call device_hotplug_done
+     * without actually calling any hotplug script */
+    libxl__ev_child_init(&aodev->child);
+    libxl__ev_time_init(&aodev->ev);
+
     /* Some devices (vkbd) fail to disconnect properly,
      * but we shouldn't alarm the user if it's during
      * domain destruction.
@@ -711,9 +725,12 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
         goto out;
     }
 
+    device_hotplug(egc, aodev);
+    return;
+
 out:
     aodev->rc = rc;
-    device_xsentries_remove(egc, aodev);
+    device_hotplug_done(egc, aodev);
     return;
 }
 
@@ -723,7 +740,104 @@ static void device_backend_cleanup(libxl__gc *gc, libxl__ao_device *aodev)
     libxl__ev_devstate_cancel(gc, &aodev->backend_ds);
 }
 
-static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
+static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
+    char **args = NULL, **env = NULL;
+    int rc = 0;
+    int hotplug;
+    pid_t pid;
+
+    /* Check if we have to execute hotplug scripts for this device
+     * and return the necessary args/env vars for execution */
+    hotplug = libxl__get_hotplug_script_info(gc, aodev->dev, &args, &env,
+                                             aodev->action);
+    switch (hotplug) {
+    case 0:
+        /* no hotplug script to execute */
+        goto out;
+    case 1:
+        /* execute hotplug script */
+        break;
+    default:
+        /* everything else is an error */
+        LOG(ERROR, "unable to get args/env to execute hotplug script for "
+                   "device %s", libxl__device_backend_path(gc, aodev->dev));
+        rc = hotplug;
+        goto out;
+    }
+
+    /* Set hotplug timeout */
+    rc = libxl__ev_time_register_rel(gc, &aodev->ev, device_hotplug_timeout_cb,
+                                     LIBXL_HOTPLUG_TIMEOUT * 1000);
+    if (rc) {
+        LOG(ERROR, "unable to register timeout for hotplug device %s", be_path);
+        goto out;
+    }
+
+    aodev->what = GCSPRINTF("%s %s", args[0], args[1]);
+    LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
+
+    /* fork and execute hotplug script */
+    pid = libxl__ev_child_fork(gc, &aodev->child, device_hotplug_child_death_cb);
+    if (pid == -1) {
+        LOG(ERROR, "unable to fork");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        libxl__exec(gc, -1, -1, -1, args[0], args, env);
+        /* notreached */
+        abort();
+    }
+
+    assert(libxl__ev_child_inuse(&aodev->child));
+
+    return;
+
+out:
+    aodev->rc = rc;
+    device_hotplug_done(egc, aodev);
+    return;
+}
+
+static void device_hotplug_timeout_cb(libxl__egc *egc, libxl__ev_time *ev,
+                                      const struct timeval *requested_abs)
+{
+    libxl__ao_device *aodev = CONTAINER_OF(ev, *aodev, ev);
+    STATE_AO_GC(aodev->ao);
+
+    assert(libxl__ev_child_inuse(&aodev->child));
+    LOG(DEBUG, "killing hotplug script %s because of timeout", aodev->what);
+    if (kill(aodev->child.pid, SIGKILL)) {
+        LOGEV(ERROR, errno, "unable to kill hotplug script %s [%ld]",
+                            aodev->what, (unsigned long)aodev->child.pid);
+    }
+
+    return;
+}
+
+static void device_hotplug_child_death_cb(libxl__egc *egc,
+                                          libxl__ev_child *child,
+                                          pid_t pid, int status)
+{
+    libxl__ao_device *aodev = CONTAINER_OF(child, *aodev, child);
+    STATE_AO_GC(aodev->ao);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, aodev->rc ? LIBXL__LOG_ERROR
+                                                     : LIBXL__LOG_WARNING,
+                                      aodev->what, pid, status);
+        aodev->rc = ERROR_FAIL;
+    }
+
+    device_hotplug_done(egc, aodev);
+}
+
+static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
 {
     STATE_AO_GC(aodev->ao);
     char *be_path = libxl__device_backend_path(gc, aodev->dev);
@@ -731,6 +845,11 @@ static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
     xs_transaction_t t = 0;
     int ret = 0;
 
+    /* Clean events and check reentrancy */
+    libxl__ev_time_deregister(gc, &aodev->ev);
+    assert(!libxl__ev_child_inuse(&aodev->child));
+
+    /* Clean xenstore if it's a disconnection */
     if (aodev->action == DEVICE_DISCONNECT) {
         do {
             t = xs_transaction_start(CTX->xsh);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1350ba9..a2e375a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -72,6 +72,7 @@
 
 #define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_HOTPLUG_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -1739,6 +1740,10 @@ struct libxl__ao_device {
     /* Used internally to have a reference to the upper libxl__ao_devices
      * struct when present */
     libxl__ao_devices *aodevs;
+    /* device hotplug execution */
+    const char *what;
+    libxl__ev_time ev;
+    libxl__ev_child child;
 };
 
 /* Helper struct to simply the plug/unplug of multiple devices at the same
@@ -1792,6 +1797,20 @@ _hidden void libxl__initiate_device_connection(libxl__egc*,
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*
+ * libxl__get_hotplug_script_info returns the args and env that should
+ * be passed to the hotplug script for the requested device.
+ *
+ * Since a device might not need to execute any hotplug script, this function
+ * can return the following values:
+ * < 0: Error
+ * 0: No need to execute hotplug script
+ * 1: Execute hotplug script
+ */
+_hidden int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
+                                           char ***args, char ***env,
+                                           libxl__device_action action);
+
 /*----- local disk attach: attach a disk locally to run the bootloader -----*/
 
 typedef struct libxl__disk_local_state libxl__disk_local_state;
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 0169b2f..8883e45 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -77,3 +77,103 @@ char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
                 "%d", minor & (nr_parts - 1));
     return ret;
 }
+
+/* Hotplug scripts helpers */
+
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    const char *type = libxl__device_kind_to_string(dev->backend_kind);
+    char **env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            GCSPRINTF("%s/%s", be_path, "script"));
+    if (!script) {
+        LOGEV(ERROR, errno, "unable to read script from %s", be_path);
+        return NULL;
+    }
+
+    const int arraysize = 9;
+    GCNEW_ARRAY(env, arraysize);
+    env[nr++] = "script";
+    env[nr++] = script;
+    env[nr++] = "XENBUS_TYPE";
+    env[nr++] = libxl__strdup(gc, type);
+    env[nr++] = "XENBUS_PATH";
+    env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
+    env[nr++] = "XENBUS_BASE_PATH";
+    env[nr++] = "backend";
+    env[nr++] = NULL;
+    assert(nr == arraysize);
+
+    return env;
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               char ***args, char ***env,
+                               libxl__device_action action)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    int nr = 0, rc = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            GCSPRINTF("%s/%s", be_path, "script"));
+    if (!script) {
+        LOGEV(ERROR, errno, "unable to read script from %s", be_path);
+        rc = ERROR_FAIL;
+        goto error;
+    }
+
+    *env = get_hotplug_env(gc, dev);
+    if (!*env) {
+        rc = ERROR_FAIL;
+        goto error;
+    }
+
+    const int arraysize = 3;
+    GCNEW_ARRAY(*args, arraysize);
+    (*args)[nr++] = script;
+    (*args)[nr++] = action == DEVICE_CONNECT ? "add" : "remove";
+    (*args)[nr++] = NULL;
+    assert(nr == arraysize);
+
+    rc = 0;
+
+error:
+    return rc;
+}
+
+int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
+                                   char ***args, char ***env,
+                                   libxl__device_action action)
+{
+    char *disable_udev = libxl__xs_read(gc, XBT_NULL, DISABLE_UDEV_PATH);
+    int rc;
+
+    /* Check if we have to run hotplug scripts */
+    if (!disable_udev) {
+        rc = 0;
+        goto out;
+    }
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, args, env, action);
+        if (!rc) rc = 1;
+        break;
+    default:
+        /* If no need to execute any hotplug scripts,
+         * call the callback manually
+         */
+        rc = 0;
+        break;
+    }
+
+out:
+    return rc;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index dbf5f71..a2f8d3f 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -30,3 +30,11 @@ char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
     /* TODO */
     return NULL;
 }
+
+/* Hotplug scripts caller functions */
+int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
+                                   char ***args, char ***env,
+                                   libxl__device_action action)
+{
+    return 0;
+}
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9Qv-00070T-MM; Thu, 14 Jun 2012 12:45:53 +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 1Sf9Qu-000702-Jn
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:53 +0000
Received: from [85.158.138.51:20511] by server-8.bemta-3.messagelabs.com id
	60/E6-06157-FFCD9DF4; Thu, 14 Jun 2012 12:45:51 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339677948!27723273!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23568 invoked from network); 14 Jun 2012 12:45:50 -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;
	14 Jun 2012 12:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28070414"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:48 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-QZ;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:14 +0100
Message-ID: <1339676475-33265-13-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 12/13] libxl: call hotplug scripts for disk
	devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since most of the needed work is already done in previous patches,
this patch only contains the necessary code to call hotplug scripts
for disk devices, that should be called when the device is added or
removed from a guest.

We will chain the launch of the disk hotplug scripts after the
device_backend_callback callback, or directly from
libxl__initiate_device_{add,remove} if the device is already in the
desired state.

Changes since v5:

 * Added common exit point using the device_hotplug_done function.

 * Changed the "what" field in ao_device to "const char *".

Changes since v4:

 * Init args and env to NULL.

 * Correctly propagate errors from libxl__get_hotplug_script_info.

 * Replaced if in libxl__ev_child_inuse with asserts.

 * Renamed fork_cb to child_death_cb.

 * Move deregistration of device_hotplug_timeout_cb to the top of the
   function.

 * Removed "pid" field from libxl__ao_device struct.

 * Moved arraysize declaration.

 * Fixed diff complain about no newline at the end of libxl_netbsd.c.

Changes since v2:

 * Added array size check with assert.

 * Added NetBSD code (so compilation is not broken).

 * Removed a check for null in device_hotplug_timeout_cb.

Changes since v1:

 * Moved all the event related code that was inside libxl_linux.c into
   libxl_device.c, so the flow of the device addition/removal event is
   all in the same file.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules     |    6 +-
 tools/hotplug/Linux/xen-hotplug-common.sh |    6 ++
 tools/libxl/libxl.c                       |   10 ++
 tools/libxl/libxl_device.c                |  129 +++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h              |   19 ++++
 tools/libxl/libxl_linux.c                 |  100 ++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c                |    8 ++
 7 files changed, 270 insertions(+), 8 deletions(-)

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 405387f..d55ff11 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh
index 8f6557d..4a7bc73 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh
@@ -15,6 +15,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
 
+# Hack to prevent the execution of hotplug scripts from udev if the domain
+# has been launched from libxl
+if [ -n "${UDEV_CALL}" ] && \
+   xenstore-read "libxl/disable_udev" >/dev/null 2>&1; then
+    exit 0
+fi
 
 dir=$(dirname "$0")
 . "$dir/hotplugpath.sh"
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 44c8442..0205b11 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1708,6 +1708,11 @@ void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, GCSPRINTF("%s/%s",
+                                             libxl__xen_script_dir_path(),
+                                             "block"));
+
             assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1723,6 +1728,11 @@ void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
 
+            flexarray_append(back, "script");
+            flexarray_append(back, GCSPRINTF("%s/%s",
+                                             libxl__xen_script_dir_path(),
+                                             "blktap"));
+
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
         case LIBXL_DISK_BACKEND_QDISK:
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index ca51577..fcbead6 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -602,7 +602,16 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
 static void device_backend_cleanup(libxl__gc *gc,
                                    libxl__ao_device *aodev);
 
-static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev);
+static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev);
+
+static void device_hotplug_timeout_cb(libxl__egc *egc, libxl__ev_time *ev,
+                                      const struct timeval *requested_abs);
+
+static void device_hotplug_child_death_cb(libxl__egc *egc,
+                                          libxl__ev_child *child,
+                                          pid_t pid, int status);
+
+static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev);
 
 void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
 {
@@ -630,7 +639,7 @@ void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
 out_fail:
     assert(rc);
     aodev->rc = rc;
-    device_xsentries_remove(egc, aodev);
+    device_hotplug_child_death_cb(egc, &aodev->child, 0, 0);
     return;
 }
 
@@ -678,7 +687,7 @@ retry_transaction:
  out_fail:
     assert(rc);
     aodev->rc = rc;
-    device_xsentries_remove(egc, aodev);
+    device_hotplug_child_death_cb(egc, &aodev->child, 0, 0);
     return;
 }
 
@@ -696,6 +705,11 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
         return;
     }
 
+    /* We init this here because we might call device_hotplug_done
+     * without actually calling any hotplug script */
+    libxl__ev_child_init(&aodev->child);
+    libxl__ev_time_init(&aodev->ev);
+
     /* Some devices (vkbd) fail to disconnect properly,
      * but we shouldn't alarm the user if it's during
      * domain destruction.
@@ -711,9 +725,12 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
         goto out;
     }
 
+    device_hotplug(egc, aodev);
+    return;
+
 out:
     aodev->rc = rc;
-    device_xsentries_remove(egc, aodev);
+    device_hotplug_done(egc, aodev);
     return;
 }
 
@@ -723,7 +740,104 @@ static void device_backend_cleanup(libxl__gc *gc, libxl__ao_device *aodev)
     libxl__ev_devstate_cancel(gc, &aodev->backend_ds);
 }
 
-static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
+static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    char *be_path = libxl__device_backend_path(gc, aodev->dev);
+    char **args = NULL, **env = NULL;
+    int rc = 0;
+    int hotplug;
+    pid_t pid;
+
+    /* Check if we have to execute hotplug scripts for this device
+     * and return the necessary args/env vars for execution */
+    hotplug = libxl__get_hotplug_script_info(gc, aodev->dev, &args, &env,
+                                             aodev->action);
+    switch (hotplug) {
+    case 0:
+        /* no hotplug script to execute */
+        goto out;
+    case 1:
+        /* execute hotplug script */
+        break;
+    default:
+        /* everything else is an error */
+        LOG(ERROR, "unable to get args/env to execute hotplug script for "
+                   "device %s", libxl__device_backend_path(gc, aodev->dev));
+        rc = hotplug;
+        goto out;
+    }
+
+    /* Set hotplug timeout */
+    rc = libxl__ev_time_register_rel(gc, &aodev->ev, device_hotplug_timeout_cb,
+                                     LIBXL_HOTPLUG_TIMEOUT * 1000);
+    if (rc) {
+        LOG(ERROR, "unable to register timeout for hotplug device %s", be_path);
+        goto out;
+    }
+
+    aodev->what = GCSPRINTF("%s %s", args[0], args[1]);
+    LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
+
+    /* fork and execute hotplug script */
+    pid = libxl__ev_child_fork(gc, &aodev->child, device_hotplug_child_death_cb);
+    if (pid == -1) {
+        LOG(ERROR, "unable to fork");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* child */
+        libxl__exec(gc, -1, -1, -1, args[0], args, env);
+        /* notreached */
+        abort();
+    }
+
+    assert(libxl__ev_child_inuse(&aodev->child));
+
+    return;
+
+out:
+    aodev->rc = rc;
+    device_hotplug_done(egc, aodev);
+    return;
+}
+
+static void device_hotplug_timeout_cb(libxl__egc *egc, libxl__ev_time *ev,
+                                      const struct timeval *requested_abs)
+{
+    libxl__ao_device *aodev = CONTAINER_OF(ev, *aodev, ev);
+    STATE_AO_GC(aodev->ao);
+
+    assert(libxl__ev_child_inuse(&aodev->child));
+    LOG(DEBUG, "killing hotplug script %s because of timeout", aodev->what);
+    if (kill(aodev->child.pid, SIGKILL)) {
+        LOGEV(ERROR, errno, "unable to kill hotplug script %s [%ld]",
+                            aodev->what, (unsigned long)aodev->child.pid);
+    }
+
+    return;
+}
+
+static void device_hotplug_child_death_cb(libxl__egc *egc,
+                                          libxl__ev_child *child,
+                                          pid_t pid, int status)
+{
+    libxl__ao_device *aodev = CONTAINER_OF(child, *aodev, child);
+    STATE_AO_GC(aodev->ao);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, aodev->rc ? LIBXL__LOG_ERROR
+                                                     : LIBXL__LOG_WARNING,
+                                      aodev->what, pid, status);
+        aodev->rc = ERROR_FAIL;
+    }
+
+    device_hotplug_done(egc, aodev);
+}
+
+static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
 {
     STATE_AO_GC(aodev->ao);
     char *be_path = libxl__device_backend_path(gc, aodev->dev);
@@ -731,6 +845,11 @@ static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
     xs_transaction_t t = 0;
     int ret = 0;
 
+    /* Clean events and check reentrancy */
+    libxl__ev_time_deregister(gc, &aodev->ev);
+    assert(!libxl__ev_child_inuse(&aodev->child));
+
+    /* Clean xenstore if it's a disconnection */
     if (aodev->action == DEVICE_DISCONNECT) {
         do {
             t = xs_transaction_start(CTX->xsh);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1350ba9..a2e375a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -72,6 +72,7 @@
 
 #define LIBXL_INIT_TIMEOUT 10
 #define LIBXL_DESTROY_TIMEOUT 10
+#define LIBXL_HOTPLUG_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
@@ -1739,6 +1740,10 @@ struct libxl__ao_device {
     /* Used internally to have a reference to the upper libxl__ao_devices
      * struct when present */
     libxl__ao_devices *aodevs;
+    /* device hotplug execution */
+    const char *what;
+    libxl__ev_time ev;
+    libxl__ev_child child;
 };
 
 /* Helper struct to simply the plug/unplug of multiple devices at the same
@@ -1792,6 +1797,20 @@ _hidden void libxl__initiate_device_connection(libxl__egc*,
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,
                                            libxl__ao_device *aodev);
 
+/*
+ * libxl__get_hotplug_script_info returns the args and env that should
+ * be passed to the hotplug script for the requested device.
+ *
+ * Since a device might not need to execute any hotplug script, this function
+ * can return the following values:
+ * < 0: Error
+ * 0: No need to execute hotplug script
+ * 1: Execute hotplug script
+ */
+_hidden int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
+                                           char ***args, char ***env,
+                                           libxl__device_action action);
+
 /*----- local disk attach: attach a disk locally to run the bootloader -----*/
 
 typedef struct libxl__disk_local_state libxl__disk_local_state;
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 0169b2f..8883e45 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -77,3 +77,103 @@ char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
                 "%d", minor & (nr_parts - 1));
     return ret;
 }
+
+/* Hotplug scripts helpers */
+
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    const char *type = libxl__device_kind_to_string(dev->backend_kind);
+    char **env;
+    int nr = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            GCSPRINTF("%s/%s", be_path, "script"));
+    if (!script) {
+        LOGEV(ERROR, errno, "unable to read script from %s", be_path);
+        return NULL;
+    }
+
+    const int arraysize = 9;
+    GCNEW_ARRAY(env, arraysize);
+    env[nr++] = "script";
+    env[nr++] = script;
+    env[nr++] = "XENBUS_TYPE";
+    env[nr++] = libxl__strdup(gc, type);
+    env[nr++] = "XENBUS_PATH";
+    env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
+    env[nr++] = "XENBUS_BASE_PATH";
+    env[nr++] = "backend";
+    env[nr++] = NULL;
+    assert(nr == arraysize);
+
+    return env;
+}
+
+/* Hotplug scripts caller functions */
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                               char ***args, char ***env,
+                               libxl__device_action action)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    int nr = 0, rc = 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            GCSPRINTF("%s/%s", be_path, "script"));
+    if (!script) {
+        LOGEV(ERROR, errno, "unable to read script from %s", be_path);
+        rc = ERROR_FAIL;
+        goto error;
+    }
+
+    *env = get_hotplug_env(gc, dev);
+    if (!*env) {
+        rc = ERROR_FAIL;
+        goto error;
+    }
+
+    const int arraysize = 3;
+    GCNEW_ARRAY(*args, arraysize);
+    (*args)[nr++] = script;
+    (*args)[nr++] = action == DEVICE_CONNECT ? "add" : "remove";
+    (*args)[nr++] = NULL;
+    assert(nr == arraysize);
+
+    rc = 0;
+
+error:
+    return rc;
+}
+
+int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
+                                   char ***args, char ***env,
+                                   libxl__device_action action)
+{
+    char *disable_udev = libxl__xs_read(gc, XBT_NULL, DISABLE_UDEV_PATH);
+    int rc;
+
+    /* Check if we have to run hotplug scripts */
+    if (!disable_udev) {
+        rc = 0;
+        goto out;
+    }
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, args, env, action);
+        if (!rc) rc = 1;
+        break;
+    default:
+        /* If no need to execute any hotplug scripts,
+         * call the callback manually
+         */
+        rc = 0;
+        break;
+    }
+
+out:
+    return rc;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index dbf5f71..a2f8d3f 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -30,3 +30,11 @@ char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
     /* TODO */
     return NULL;
 }
+
+/* Hotplug scripts caller functions */
+int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
+                                   char ***args, char ***env,
+                                   libxl__device_action action)
+{
+    return 0;
+}
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9Qv-00070M-Au; Thu, 14 Jun 2012 12:45:53 +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 1Sf9Qt-000700-Mh
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:52 +0000
Received: from [85.158.138.51:20437] by server-11.bemta-3.messagelabs.com id
	CD/8F-02904-EFCD9DF4; Thu, 14 Jun 2012 12:45:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339677948!27723273!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23538 invoked from network); 14 Jun 2012 12:45:49 -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;
	14 Jun 2012 12:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28070413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:47 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-ST;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:15 +0100
Message-ID: <1339676475-33265-14-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 13/13] libxl: call hotplug scripts for nic
	devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since most of the needed work is already done in previous patches,
this patch only contains the necessary code to call hotplug scripts
for nic devices, that should be called when the device is added or
removed from a guest.

Added another parameter to libxl__get_hotplug_script_info, that is
used to know the number of times hotplug scripts have been called for
that device. This is currently used by IOEMU nics on Linux.

Changes since v4:

 * Add num_exec to NetBSD dummy function.

 * Better comment in the prototype of libxl__get_hotplug_script_info.

 * Remove nasty use of goto.

 * Keep calling device_hotplug until libxl__get_hotplug_script_info
   returns <= 0. This is used by TAP nics which also have a VIF
   interface (PV_IOEMU).

Changes since v2:

 * Change libxl__nic_type to return the value in a parameter passed by
   the caller.

 * Rename vif_execute to num_exec, to represent the number of times
   hotplug scripts have been called for that device.

Changes since v1:

 * Move event code to libxl_device.c (as in previous patch).

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules |    6 +-
 tools/libxl/libxl_device.c            |   50 ++++++++++++++++--
 tools/libxl/libxl_internal.h          |   14 +++++-
 tools/libxl/libxl_linux.c             |   92 +++++++++++++++++++++++++++++++-
 tools/libxl/libxl_netbsd.c            |    3 +-
 5 files changed, 152 insertions(+), 13 deletions(-)

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index d55ff11..c591a3f 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scr
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index fcbead6..7988090 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -100,6 +100,29 @@ out:
     return numdevs;
 }
 
+int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
+{
+    char *snictype, *be_path;
+    int rc = 0;
+
+    be_path = libxl__device_backend_path(gc, dev);
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                              GCSPRINTF("%s/%s", be_path, "type"));
+    if (!snictype) {
+        LOGE(ERROR, "unable to read nictype from %s", be_path);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    rc = libxl_nic_type_from_string(snictype, nictype);
+    if (rc) {
+        LOGE(ERROR, "unable to parse nictype from %s", be_path);
+        goto out;
+    }
+
+out:
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
         libxl__device *device, char **bents, char **fents)
 {
@@ -613,6 +636,8 @@ static void device_hotplug_child_death_cb(libxl__egc *egc,
 
 static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev);
 
+static void device_hotplug_clean(libxl__gc *gc, libxl__ao_device *aodev);
+
 void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
 {
     STATE_AO_GC(aodev->ao);
@@ -752,7 +777,8 @@ static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev)
     /* Check if we have to execute hotplug scripts for this device
      * and return the necessary args/env vars for execution */
     hotplug = libxl__get_hotplug_script_info(gc, aodev->dev, &args, &env,
-                                             aodev->action);
+                                             aodev->action,
+                                             aodev->num_exec);
     switch (hotplug) {
     case 0:
         /* no hotplug script to execute */
@@ -834,7 +860,16 @@ static void device_hotplug_child_death_cb(libxl__egc *egc,
         aodev->rc = ERROR_FAIL;
     }
 
-    device_hotplug_done(egc, aodev);
+    device_hotplug_clean(gc, aodev);
+
+    /* Increase num_exec and call hotplug scripts again if necessary
+     * If no more executions are needed, device_hotplug will call
+     * device_hotplug_done breaking the loop.
+     */
+    aodev->num_exec++;
+    device_hotplug(egc, aodev);
+
+    return;
 }
 
 static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
@@ -845,9 +880,7 @@ static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
     xs_transaction_t t = 0;
     int ret = 0;
 
-    /* Clean events and check reentrancy */
-    libxl__ev_time_deregister(gc, &aodev->ev);
-    assert(!libxl__ev_child_inuse(&aodev->child));
+    device_hotplug_clean(gc, aodev);
 
     /* Clean xenstore if it's a disconnection */
     if (aodev->action == DEVICE_DISCONNECT) {
@@ -868,6 +901,13 @@ static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
     return;
 }
 
+static void device_hotplug_clean(libxl__gc *gc, libxl__ao_device *aodev)
+{
+    /* Clean events and check reentrancy */
+    libxl__ev_time_deregister(gc, &aodev->ev);
+    assert(!libxl__ev_child_inuse(&aodev->child));
+}
+
 static void devices_remove_callback(libxl__egc *egc, libxl__ao_devices *aodevs,
                                     int rc)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a2e375a..a353291 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -826,6 +826,8 @@ _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
+_hidden int libxl__nic_type(libxl__gc *gc, libxl__device *dev,
+                            libxl_nic_type *nictype);
 
 /*
  * For each aggregate type which can be used as an input we provide:
@@ -1742,6 +1744,7 @@ struct libxl__ao_device {
     libxl__ao_devices *aodevs;
     /* device hotplug execution */
     const char *what;
+    int num_exec;
     libxl__ev_time ev;
     libxl__ev_child child;
 };
@@ -1806,10 +1809,19 @@ _hidden void libxl__initiate_device_remove(libxl__egc *egc,
  * < 0: Error
  * 0: No need to execute hotplug script
  * 1: Execute hotplug script
+ *
+ * The last parameter, "num_exec" refeers to the number of times hotplug
+ * scripts have been called for this device.
+ *
+ * The main body of libxl will, for each device, keep calling
+ * libxl__get_hotplug_script_info, with incrementing values of
+ * num_exec, and executing the resulting script accordingly,
+ * until libxl__get_hotplug_script_info returns<=0.
  */
 _hidden int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
                                            char ***args, char ***env,
-                                           libxl__device_action action);
+                                           libxl__device_action action,
+                                           int num_exec);
 
 /*----- local disk attach: attach a disk locally to run the bootloader -----*/
 
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 8883e45..4877eb5 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -87,6 +87,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
     const char *type = libxl__device_kind_to_string(dev->backend_kind);
     char **env;
     int nr = 0;
+    libxl_nic_type nictype;
 
     script = libxl__xs_read(gc, XBT_NULL,
                             GCSPRINTF("%s/%s", be_path, "script"));
@@ -95,7 +96,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    const int arraysize = 9;
+    const int arraysize = 13;
     GCNEW_ARRAY(env, arraysize);
     env[nr++] = "script";
     env[nr++] = script;
@@ -105,14 +106,86 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
     env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
     env[nr++] = "XENBUS_BASE_PATH";
     env[nr++] = "backend";
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        if (libxl__nic_type(gc, dev, &nictype)) {
+            LOG(ERROR, "unable to get nictype");
+            return NULL;
+        }
+        switch (nictype) {
+        case LIBXL_NIC_TYPE_VIF_IOEMU:
+            env[nr++] = "INTERFACE";
+            env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc,
+                                                      dev->domid, dev->devid,
+                                                      LIBXL_NIC_TYPE_VIF_IOEMU));
+        case LIBXL_NIC_TYPE_VIF:
+            env[nr++] = "vif";
+            env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc,
+                                                      dev->domid, dev->devid,
+                                                      LIBXL_NIC_TYPE_VIF));
+            break;
+        default:
+            return NULL;
+        }
+    }
+
     env[nr++] = NULL;
-    assert(nr == arraysize);
+    assert(nr <= arraysize);
 
     return env;
 }
 
 /* Hotplug scripts caller functions */
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                               char ***args, char ***env,
+                               libxl__device_action action, int num_exec)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+
+    script = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/%s", be_path,
+                                                             "script"));
+    if (!script) {
+        LOGE(ERROR, "unable to read script from %s", be_path);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl__nic_type(gc, dev, &nictype);
+    if (rc) {
+        LOG(ERROR, "error when fetching nic type");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    *env = get_hotplug_env(gc, dev);
+    if (!env) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    const int arraysize = 4;
+    GCNEW_ARRAY(*args, arraysize);
+    (*args)[nr++] = script;
+
+    if (nictype == LIBXL_NIC_TYPE_VIF_IOEMU && num_exec) {
+        (*args)[nr++] = action == DEVICE_CONNECT ? "add" : "remove";
+        (*args)[nr++] = libxl__strdup(gc, "type_if=tap");
+        (*args)[nr++] = NULL;
+    } else {
+        (*args)[nr++] = action == DEVICE_CONNECT ? "online" : "offline";
+        (*args)[nr++] = libxl__strdup(gc, "type_if=vif");
+        (*args)[nr++] = NULL;
+    }
+    assert(nr == arraysize);
+    rc = 0;
+
+out:
+    return rc;
+}
+
 static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
                                char ***args, char ***env,
                                libxl__device_action action)
@@ -150,7 +223,8 @@ error:
 
 int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
                                    char ***args, char ***env,
-                                   libxl__device_action action)
+                                   libxl__device_action action,
+                                   int num_exec)
 {
     char *disable_udev = libxl__xs_read(gc, XBT_NULL, DISABLE_UDEV_PATH);
     int rc;
@@ -163,9 +237,21 @@ int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
 
     switch (dev->backend_kind) {
     case LIBXL__DEVICE_KIND_VBD:
+        if (num_exec != 0) {
+            rc = 0;
+            goto out;
+        }
         rc = libxl__hotplug_disk(gc, dev, args, env, action);
         if (!rc) rc = 1;
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        if (num_exec > 1) {
+            rc = 0;
+            goto out;
+        }
+        rc = libxl__hotplug_nic(gc, dev, args, env, action, num_exec);
+        if (!rc) rc = 1;
+        break;
     default:
         /* If no need to execute any hotplug scripts,
          * call the callback manually
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index a2f8d3f..28cdf21 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -34,7 +34,8 @@ char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
 /* Hotplug scripts caller functions */
 int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
                                    char ***args, char ***env,
-                                   libxl__device_action action)
+                                   libxl__device_action action,
+                                   int num_exec)
 {
     return 0;
 }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9Qv-00070M-Au; Thu, 14 Jun 2012 12:45:53 +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 1Sf9Qt-000700-Mh
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:52 +0000
Received: from [85.158.138.51:20437] by server-11.bemta-3.messagelabs.com id
	CD/8F-02904-EFCD9DF4; Thu, 14 Jun 2012 12:45:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339677948!27723273!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23538 invoked from network); 14 Jun 2012 12:45:49 -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;
	14 Jun 2012 12:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28070413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:47 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-ST;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:15 +0100
Message-ID: <1339676475-33265-14-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 13/13] libxl: call hotplug scripts for nic
	devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since most of the needed work is already done in previous patches,
this patch only contains the necessary code to call hotplug scripts
for nic devices, that should be called when the device is added or
removed from a guest.

Added another parameter to libxl__get_hotplug_script_info, that is
used to know the number of times hotplug scripts have been called for
that device. This is currently used by IOEMU nics on Linux.

Changes since v4:

 * Add num_exec to NetBSD dummy function.

 * Better comment in the prototype of libxl__get_hotplug_script_info.

 * Remove nasty use of goto.

 * Keep calling device_hotplug until libxl__get_hotplug_script_info
   returns <= 0. This is used by TAP nics which also have a VIF
   interface (PV_IOEMU).

Changes since v2:

 * Change libxl__nic_type to return the value in a parameter passed by
   the caller.

 * Rename vif_execute to num_exec, to represent the number of times
   hotplug scripts have been called for that device.

Changes since v1:

 * Move event code to libxl_device.c (as in previous patch).

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/hotplug/Linux/xen-backend.rules |    6 +-
 tools/libxl/libxl_device.c            |   50 ++++++++++++++++--
 tools/libxl/libxl_internal.h          |   14 +++++-
 tools/libxl/libxl_linux.c             |   92 +++++++++++++++++++++++++++++++-
 tools/libxl/libxl_netbsd.c            |    3 +-
 5 files changed, 152 insertions(+), 13 deletions(-)

diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index d55ff11..c591a3f 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scr
 SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
 SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index fcbead6..7988090 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -100,6 +100,29 @@ out:
     return numdevs;
 }
 
+int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
+{
+    char *snictype, *be_path;
+    int rc = 0;
+
+    be_path = libxl__device_backend_path(gc, dev);
+    snictype = libxl__xs_read(gc, XBT_NULL,
+                              GCSPRINTF("%s/%s", be_path, "type"));
+    if (!snictype) {
+        LOGE(ERROR, "unable to read nictype from %s", be_path);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    rc = libxl_nic_type_from_string(snictype, nictype);
+    if (rc) {
+        LOGE(ERROR, "unable to parse nictype from %s", be_path);
+        goto out;
+    }
+
+out:
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
         libxl__device *device, char **bents, char **fents)
 {
@@ -613,6 +636,8 @@ static void device_hotplug_child_death_cb(libxl__egc *egc,
 
 static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev);
 
+static void device_hotplug_clean(libxl__gc *gc, libxl__ao_device *aodev);
+
 void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
 {
     STATE_AO_GC(aodev->ao);
@@ -752,7 +777,8 @@ static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev)
     /* Check if we have to execute hotplug scripts for this device
      * and return the necessary args/env vars for execution */
     hotplug = libxl__get_hotplug_script_info(gc, aodev->dev, &args, &env,
-                                             aodev->action);
+                                             aodev->action,
+                                             aodev->num_exec);
     switch (hotplug) {
     case 0:
         /* no hotplug script to execute */
@@ -834,7 +860,16 @@ static void device_hotplug_child_death_cb(libxl__egc *egc,
         aodev->rc = ERROR_FAIL;
     }
 
-    device_hotplug_done(egc, aodev);
+    device_hotplug_clean(gc, aodev);
+
+    /* Increase num_exec and call hotplug scripts again if necessary
+     * If no more executions are needed, device_hotplug will call
+     * device_hotplug_done breaking the loop.
+     */
+    aodev->num_exec++;
+    device_hotplug(egc, aodev);
+
+    return;
 }
 
 static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
@@ -845,9 +880,7 @@ static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
     xs_transaction_t t = 0;
     int ret = 0;
 
-    /* Clean events and check reentrancy */
-    libxl__ev_time_deregister(gc, &aodev->ev);
-    assert(!libxl__ev_child_inuse(&aodev->child));
+    device_hotplug_clean(gc, aodev);
 
     /* Clean xenstore if it's a disconnection */
     if (aodev->action == DEVICE_DISCONNECT) {
@@ -868,6 +901,13 @@ static void device_hotplug_done(libxl__egc *egc, libxl__ao_device *aodev)
     return;
 }
 
+static void device_hotplug_clean(libxl__gc *gc, libxl__ao_device *aodev)
+{
+    /* Clean events and check reentrancy */
+    libxl__ev_time_deregister(gc, &aodev->ev);
+    assert(!libxl__ev_child_inuse(&aodev->child));
+}
+
 static void devices_remove_callback(libxl__egc *egc, libxl__ao_devices *aodevs,
                                     int rc)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a2e375a..a353291 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -826,6 +826,8 @@ _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
+_hidden int libxl__nic_type(libxl__gc *gc, libxl__device *dev,
+                            libxl_nic_type *nictype);
 
 /*
  * For each aggregate type which can be used as an input we provide:
@@ -1742,6 +1744,7 @@ struct libxl__ao_device {
     libxl__ao_devices *aodevs;
     /* device hotplug execution */
     const char *what;
+    int num_exec;
     libxl__ev_time ev;
     libxl__ev_child child;
 };
@@ -1806,10 +1809,19 @@ _hidden void libxl__initiate_device_remove(libxl__egc *egc,
  * < 0: Error
  * 0: No need to execute hotplug script
  * 1: Execute hotplug script
+ *
+ * The last parameter, "num_exec" refeers to the number of times hotplug
+ * scripts have been called for this device.
+ *
+ * The main body of libxl will, for each device, keep calling
+ * libxl__get_hotplug_script_info, with incrementing values of
+ * num_exec, and executing the resulting script accordingly,
+ * until libxl__get_hotplug_script_info returns<=0.
  */
 _hidden int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
                                            char ***args, char ***env,
-                                           libxl__device_action action);
+                                           libxl__device_action action,
+                                           int num_exec);
 
 /*----- local disk attach: attach a disk locally to run the bootloader -----*/
 
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 8883e45..4877eb5 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -87,6 +87,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
     const char *type = libxl__device_kind_to_string(dev->backend_kind);
     char **env;
     int nr = 0;
+    libxl_nic_type nictype;
 
     script = libxl__xs_read(gc, XBT_NULL,
                             GCSPRINTF("%s/%s", be_path, "script"));
@@ -95,7 +96,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
         return NULL;
     }
 
-    const int arraysize = 9;
+    const int arraysize = 13;
     GCNEW_ARRAY(env, arraysize);
     env[nr++] = "script";
     env[nr++] = script;
@@ -105,14 +106,86 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
     env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
     env[nr++] = "XENBUS_BASE_PATH";
     env[nr++] = "backend";
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        if (libxl__nic_type(gc, dev, &nictype)) {
+            LOG(ERROR, "unable to get nictype");
+            return NULL;
+        }
+        switch (nictype) {
+        case LIBXL_NIC_TYPE_VIF_IOEMU:
+            env[nr++] = "INTERFACE";
+            env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc,
+                                                      dev->domid, dev->devid,
+                                                      LIBXL_NIC_TYPE_VIF_IOEMU));
+        case LIBXL_NIC_TYPE_VIF:
+            env[nr++] = "vif";
+            env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc,
+                                                      dev->domid, dev->devid,
+                                                      LIBXL_NIC_TYPE_VIF));
+            break;
+        default:
+            return NULL;
+        }
+    }
+
     env[nr++] = NULL;
-    assert(nr == arraysize);
+    assert(nr <= arraysize);
 
     return env;
 }
 
 /* Hotplug scripts caller functions */
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                               char ***args, char ***env,
+                               libxl__device_action action, int num_exec)
+{
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script;
+    int nr = 0, rc = 0;
+    libxl_nic_type nictype;
+
+    script = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/%s", be_path,
+                                                             "script"));
+    if (!script) {
+        LOGE(ERROR, "unable to read script from %s", be_path);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl__nic_type(gc, dev, &nictype);
+    if (rc) {
+        LOG(ERROR, "error when fetching nic type");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    *env = get_hotplug_env(gc, dev);
+    if (!env) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    const int arraysize = 4;
+    GCNEW_ARRAY(*args, arraysize);
+    (*args)[nr++] = script;
+
+    if (nictype == LIBXL_NIC_TYPE_VIF_IOEMU && num_exec) {
+        (*args)[nr++] = action == DEVICE_CONNECT ? "add" : "remove";
+        (*args)[nr++] = libxl__strdup(gc, "type_if=tap");
+        (*args)[nr++] = NULL;
+    } else {
+        (*args)[nr++] = action == DEVICE_CONNECT ? "online" : "offline";
+        (*args)[nr++] = libxl__strdup(gc, "type_if=vif");
+        (*args)[nr++] = NULL;
+    }
+    assert(nr == arraysize);
+    rc = 0;
+
+out:
+    return rc;
+}
+
 static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
                                char ***args, char ***env,
                                libxl__device_action action)
@@ -150,7 +223,8 @@ error:
 
 int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
                                    char ***args, char ***env,
-                                   libxl__device_action action)
+                                   libxl__device_action action,
+                                   int num_exec)
 {
     char *disable_udev = libxl__xs_read(gc, XBT_NULL, DISABLE_UDEV_PATH);
     int rc;
@@ -163,9 +237,21 @@ int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
 
     switch (dev->backend_kind) {
     case LIBXL__DEVICE_KIND_VBD:
+        if (num_exec != 0) {
+            rc = 0;
+            goto out;
+        }
         rc = libxl__hotplug_disk(gc, dev, args, env, action);
         if (!rc) rc = 1;
         break;
+    case LIBXL__DEVICE_KIND_VIF:
+        if (num_exec > 1) {
+            rc = 0;
+            goto out;
+        }
+        rc = libxl__hotplug_nic(gc, dev, args, env, action, num_exec);
+        if (!rc) rc = 1;
+        break;
     default:
         /* If no need to execute any hotplug scripts,
          * call the callback manually
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index a2f8d3f..28cdf21 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -34,7 +34,8 @@ char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
 /* Hotplug scripts caller functions */
 int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
                                    char ***args, char ***env,
-                                   libxl__device_action action)
+                                   libxl__device_action action,
+                                   int num_exec)
 {
     return 0;
 }
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:46:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9Qw-00070p-80; Thu, 14 Jun 2012 12:45:54 +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 1Sf9Qv-000707-0P
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:53 +0000
Received: from [85.158.138.51:17980] by server-6.bemta-3.messagelabs.com id
	77/12-11602-00DD9DF4; Thu, 14 Jun 2012 12:45:52 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339677948!27723273!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 14 Jun 2012 12:45:51 -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;
	14 Jun 2012 12:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28070418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:50 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-OL;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:12 +0100
Message-ID: <1339676475-33265-11-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

Set the default value for nic interfaces to VIF, since it used to be
IOEMU, even for PV guests.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 20c1340..44c8442 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2296,7 +2296,7 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
                                   libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
-        nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
+        nic->nictype = LIBXL_NIC_TYPE_VIF;
     return 0;
 }
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:46:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9Qw-00070p-80; Thu, 14 Jun 2012 12:45:54 +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 1Sf9Qv-000707-0P
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:53 +0000
Received: from [85.158.138.51:17980] by server-6.bemta-3.messagelabs.com id
	77/12-11602-00DD9DF4; Thu, 14 Jun 2012 12:45:52 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339677948!27723273!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 14 Jun 2012 12:45:51 -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;
	14 Jun 2012 12:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28070418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:50 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-OL;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:12 +0100
Message-ID: <1339676475-33265-11-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

Set the default value for nic interfaces to VIF, since it used to be
IOEMU, even for PV guests.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 20c1340..44c8442 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2296,7 +2296,7 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
                                   libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
     if (!nic->nictype)
-        nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
+        nic->nictype = LIBXL_NIC_TYPE_VIF;
     return 0;
 }
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 12:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf9Qx-00071O-M8; Thu, 14 Jun 2012 12:45:55 +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 1Sf9Qv-00070B-HI
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:53 +0000
Received: from [85.158.143.99:18437] by server-3.bemta-4.messagelabs.com id
	B5/25-05808-00DD9DF4; Thu, 14 Jun 2012 12:45:52 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339677950!22050695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4480 invoked from network); 14 Jun 2012 12:45:51 -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;
	14 Jun 2012 12:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198742578"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:49 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Q4;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:13 +0100
Message-ID: <1339676475-33265-12-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 11/13] libxl: use libxl__xs_path_cleanup on
	device_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

Since the hotplug script that was in charge of cleaning the backend is
no longer launched, we need to clean the backend by ourselves, so use
libxl__xs_path_cleanup instead of xs_rm.

Changes sinve v2:

 * Changed the goto construction to a do-while loop.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index f7217aa..ca51577 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -484,16 +484,26 @@ DEFINE_DEVICES_ADD(vif, nic)
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    xs_transaction_t t = 0;
+    int rc = 0;
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    do {
+        t = xs_transaction_start(CTX->xsh);
+        libxl__xs_path_cleanup(gc, t, fe_path);
+        libxl__xs_path_cleanup(gc, t, be_path);
+        rc = !xs_transaction_end(CTX->xsh, t, 0);
+    } while (rc && errno == EAGAIN);
+    if (rc) {
+        LOGE(ERROR, "unable to finish transaction");
+        goto out;
+    }
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    return 0;
+out:
+    return rc;
 }
 
 /* Callback for device destruction */
-- 
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 Jun 14 12:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf9Qx-00071O-M8; Thu, 14 Jun 2012 12:45:55 +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 1Sf9Qv-00070B-HI
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 12:45:53 +0000
Received: from [85.158.143.99:18437] by server-3.bemta-4.messagelabs.com id
	B5/25-05808-00DD9DF4; Thu, 14 Jun 2012 12:45:52 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1339677950!22050695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4480 invoked from network); 14 Jun 2012 12:45:51 -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;
	14 Jun 2012 12:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198742578"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 08:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 08:45:49 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1Sf931-0006As-Q4;
	Thu, 14 Jun 2012 13:21:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Jun 2012 13:21:13 +0100
Message-ID: <1339676475-33265-12-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v6 11/13] libxl: use libxl__xs_path_cleanup on
	device_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

Since the hotplug script that was in charge of cleaning the backend is
no longer launched, we need to clean the backend by ourselves, so use
libxl__xs_path_cleanup instead of xs_rm.

Changes sinve v2:

 * Changed the goto construction to a do-while loop.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index f7217aa..ca51577 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -484,16 +484,26 @@ DEFINE_DEVICES_ADD(vif, nic)
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    xs_transaction_t t = 0;
+    int rc = 0;
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    do {
+        t = xs_transaction_start(CTX->xsh);
+        libxl__xs_path_cleanup(gc, t, fe_path);
+        libxl__xs_path_cleanup(gc, t, be_path);
+        rc = !xs_transaction_end(CTX->xsh, t, 0);
+    } while (rc && errno == EAGAIN);
+    if (rc) {
+        LOGE(ERROR, "unable to finish transaction");
+        goto out;
+    }
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    return 0;
+out:
+    return rc;
 }
 
 /* Callback for device destruction */
-- 
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 Jun 14 12:56:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9b6-0007vC-F2; Thu, 14 Jun 2012 12:56:24 +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 1Sf9b5-0007v5-4r
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:56:23 +0000
Received: from [85.158.139.83:9488] by server-7.bemta-5.messagelabs.com id
	FC/AA-28276-67FD9DF4; Thu, 14 Jun 2012 12:56:22 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339678580!27955504!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg1MzQ0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9124 invoked from network); 14 Jun 2012 12:56:21 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 12:56:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 14 Jun 2012 05:55:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="scan'208,223";a="157563078"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 14 Jun 2012 05:55:52 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 14 Jun 2012 05:55:51 -0700
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, 14 Jun 2012 05:55:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Thu, 14 Jun 2012 20:55:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: add .poll method for mcelog device driver
Thread-Index: AQHNSZLddQXy2gd5YkW4phd9182UzZb5g2gwgABBt3A=
Date: Thu, 14 Jun 2012 12:55:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352321AB@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
	<20120613182458.GA5813@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_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/mce: add .poll method for mcelog device
	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

--_002_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>=20
>> So another bug which is that mcelog is spinning at 100% CPU (and
>> only under Xen).=20
>>=20
>> It seems to be doing:
>>=20
>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, [=
], 8)
>> =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>> =3D 0
>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, [=
], 8)
>> =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>>=20
>> constantly.
>=20
> I will debug it. I have try at my platform, but fail to reproduce it.
> (You still use the config you send me last time, right?) Would you
> tell me your step?=20
>=20
> Thanks,
> Jinsong

Have a look at it, it caused by NULL .poll method.
Attached is the patch to fix this bug, but I cannot reproduce the bug at my=
 platform, so would you please help me to test it at your side?

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From fb664590ce4198539d96b6bc245c5d70cc079129 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 15 Jun 2012 04:16:52 +0800
Subject: [PATCH] xen/mce: add .poll method for mcelog device driver

If a driver leaves its poll method NULL, the device is assumed to
be both readable and writable without blocking.

This patch add .poll method to xen mcelog device driver, so that
when mcelog use system calls like ppoll or select, it would be
blocked when no data available, and avoid spinning at CPU.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 804aa3c..c0b39c9 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -41,6 +41,7 @@
 #include <linux/miscdevice.h>
 #include <linux/uaccess.h>
 #include <linux/capability.h>
+#include <linux/poll.h>
=20
 #include <xen/interface/xen.h>
 #include <xen/events.h>
@@ -135,6 +136,14 @@ out:
 	return err ? err : buf - ubuf;
 }
=20
+static unsigned int xen_mce_chrdev_poll(struct file *file, poll_table *wai=
t)
+{
+	if (xen_mcelog.next)
+		return POLLIN | POLLRDNORM;
+
+	return 0;
+}
+
 static long xen_mce_chrdev_ioctl(struct file *f, unsigned int cmd,
 				unsigned long arg)
 {
@@ -166,6 +175,7 @@ static const struct file_operations xen_mce_chrdev_ops =
=3D {
 	.open			=3D xen_mce_chrdev_open,
 	.release		=3D xen_mce_chrdev_release,
 	.read			=3D xen_mce_chrdev_read,
+	.poll			=3D xen_mce_chrdev_poll,
 	.unlocked_ioctl		=3D xen_mce_chrdev_ioctl,
 	.llseek			=3D no_llseek,
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch"
Content-Description: 0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch";
	size=1677; creation-date="Thu, 14 Jun 2012 12:49:08 GMT";
	modification-date="Thu, 14 Jun 2012 20:35:18 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmYjY2NDU5MGNlNDE5ODUzOWQ5NmI2YmMyNDVjNWQ3MGNjMDc5MTI5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxNSBKdW4gMjAxMiAwNDoxNjo1MiArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IGFkZCAucG9sbCBtZXRob2QgZm9yIG1jZWxvZyBkZXZpY2UgZHJpdmVyCgpJZiBhIGRy
aXZlciBsZWF2ZXMgaXRzIHBvbGwgbWV0aG9kIE5VTEwsIHRoZSBkZXZpY2UgaXMgYXNzdW1lZCB0
bwpiZSBib3RoIHJlYWRhYmxlIGFuZCB3cml0YWJsZSB3aXRob3V0IGJsb2NraW5nLgoKVGhpcyBw
YXRjaCBhZGQgLnBvbGwgbWV0aG9kIHRvIHhlbiBtY2Vsb2cgZGV2aWNlIGRyaXZlciwgc28gdGhh
dAp3aGVuIG1jZWxvZyB1c2Ugc3lzdGVtIGNhbGxzIGxpa2UgcHBvbGwgb3Igc2VsZWN0LCBpdCB3
b3VsZCBiZQpibG9ja2VkIHdoZW4gbm8gZGF0YSBhdmFpbGFibGUsIGFuZCBhdm9pZCBzcGlubmlu
ZyBhdCBDUFUuCgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2ls
a0BvcmFjbGUuY29tPgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KLS0tCiBkcml2ZXJzL3hlbi9tY2Vsb2cuYyB8ICAgMTAgKysrKysrKysrKwogMSBm
aWxlcyBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKaW5kZXggODA0
YWEzYy4uYzBiMzljOSAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vbWNlbG9nLmMKKysrIGIvZHJp
dmVycy94ZW4vbWNlbG9nLmMKQEAgLTQxLDYgKzQxLDcgQEAKICNpbmNsdWRlIDxsaW51eC9taXNj
ZGV2aWNlLmg+CiAjaW5jbHVkZSA8bGludXgvdWFjY2Vzcy5oPgogI2luY2x1ZGUgPGxpbnV4L2Nh
cGFiaWxpdHkuaD4KKyNpbmNsdWRlIDxsaW51eC9wb2xsLmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50
ZXJmYWNlL3hlbi5oPgogI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KQEAgLTEzNSw2ICsxMzYsMTQg
QEAgb3V0OgogCXJldHVybiBlcnIgPyBlcnIgOiBidWYgLSB1YnVmOwogfQogCitzdGF0aWMgdW5z
aWduZWQgaW50IHhlbl9tY2VfY2hyZGV2X3BvbGwoc3RydWN0IGZpbGUgKmZpbGUsIHBvbGxfdGFi
bGUgKndhaXQpCit7CisJaWYgKHhlbl9tY2Vsb2cubmV4dCkKKwkJcmV0dXJuIFBPTExJTiB8IFBP
TExSRE5PUk07CisKKwlyZXR1cm4gMDsKK30KKwogc3RhdGljIGxvbmcgeGVuX21jZV9jaHJkZXZf
aW9jdGwoc3RydWN0IGZpbGUgKmYsIHVuc2lnbmVkIGludCBjbWQsCiAJCQkJdW5zaWduZWQgbG9u
ZyBhcmcpCiB7CkBAIC0xNjYsNiArMTc1LDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBmaWxlX29w
ZXJhdGlvbnMgeGVuX21jZV9jaHJkZXZfb3BzID0gewogCS5vcGVuCQkJPSB4ZW5fbWNlX2NocmRl
dl9vcGVuLAogCS5yZWxlYXNlCQk9IHhlbl9tY2VfY2hyZGV2X3JlbGVhc2UsCiAJLnJlYWQJCQk9
IHhlbl9tY2VfY2hyZGV2X3JlYWQsCisJLnBvbGwJCQk9IHhlbl9tY2VfY2hyZGV2X3BvbGwsCiAJ
LnVubG9ja2VkX2lvY3RsCQk9IHhlbl9tY2VfY2hyZGV2X2lvY3RsLAogCS5sbHNlZWsJCQk9IG5v
X2xsc2VlaywKIH07Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Jun 14 12:56:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12: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 1Sf9b6-0007vC-F2; Thu, 14 Jun 2012 12:56:24 +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 1Sf9b5-0007v5-4r
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:56:23 +0000
Received: from [85.158.139.83:9488] by server-7.bemta-5.messagelabs.com id
	FC/AA-28276-67FD9DF4; Thu, 14 Jun 2012 12:56:22 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339678580!27955504!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg1MzQ0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9124 invoked from network); 14 Jun 2012 12:56:21 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 12:56:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 14 Jun 2012 05:55:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="scan'208,223";a="157563078"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 14 Jun 2012 05:55:52 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 14 Jun 2012 05:55:51 -0700
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, 14 Jun 2012 05:55:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Thu, 14 Jun 2012 20:55:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: add .poll method for mcelog device driver
Thread-Index: AQHNSZLddQXy2gd5YkW4phd9182UzZb5g2gwgABBt3A=
Date: Thu, 14 Jun 2012 12:55:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352321AB@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
	<20120613182458.GA5813@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_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/mce: add .poll method for mcelog device
	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

--_002_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>=20
>> So another bug which is that mcelog is spinning at 100% CPU (and
>> only under Xen).=20
>>=20
>> It seems to be doing:
>>=20
>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, [=
], 8)
>> =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>> =3D 0
>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, [=
], 8)
>> =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>>=20
>> constantly.
>=20
> I will debug it. I have try at my platform, but fail to reproduce it.
> (You still use the config you send me last time, right?) Would you
> tell me your step?=20
>=20
> Thanks,
> Jinsong

Have a look at it, it caused by NULL .poll method.
Attached is the patch to fix this bug, but I cannot reproduce the bug at my=
 platform, so would you please help me to test it at your side?

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From fb664590ce4198539d96b6bc245c5d70cc079129 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 15 Jun 2012 04:16:52 +0800
Subject: [PATCH] xen/mce: add .poll method for mcelog device driver

If a driver leaves its poll method NULL, the device is assumed to
be both readable and writable without blocking.

This patch add .poll method to xen mcelog device driver, so that
when mcelog use system calls like ppoll or select, it would be
blocked when no data available, and avoid spinning at CPU.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 804aa3c..c0b39c9 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -41,6 +41,7 @@
 #include <linux/miscdevice.h>
 #include <linux/uaccess.h>
 #include <linux/capability.h>
+#include <linux/poll.h>
=20
 #include <xen/interface/xen.h>
 #include <xen/events.h>
@@ -135,6 +136,14 @@ out:
 	return err ? err : buf - ubuf;
 }
=20
+static unsigned int xen_mce_chrdev_poll(struct file *file, poll_table *wai=
t)
+{
+	if (xen_mcelog.next)
+		return POLLIN | POLLRDNORM;
+
+	return 0;
+}
+
 static long xen_mce_chrdev_ioctl(struct file *f, unsigned int cmd,
 				unsigned long arg)
 {
@@ -166,6 +175,7 @@ static const struct file_operations xen_mce_chrdev_ops =
=3D {
 	.open			=3D xen_mce_chrdev_open,
 	.release		=3D xen_mce_chrdev_release,
 	.read			=3D xen_mce_chrdev_read,
+	.poll			=3D xen_mce_chrdev_poll,
 	.unlocked_ioctl		=3D xen_mce_chrdev_ioctl,
 	.llseek			=3D no_llseek,
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch"
Content-Description: 0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch";
	size=1677; creation-date="Thu, 14 Jun 2012 12:49:08 GMT";
	modification-date="Thu, 14 Jun 2012 20:35:18 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmYjY2NDU5MGNlNDE5ODUzOWQ5NmI2YmMyNDVjNWQ3MGNjMDc5MTI5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxNSBKdW4gMjAxMiAwNDoxNjo1MiArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IGFkZCAucG9sbCBtZXRob2QgZm9yIG1jZWxvZyBkZXZpY2UgZHJpdmVyCgpJZiBhIGRy
aXZlciBsZWF2ZXMgaXRzIHBvbGwgbWV0aG9kIE5VTEwsIHRoZSBkZXZpY2UgaXMgYXNzdW1lZCB0
bwpiZSBib3RoIHJlYWRhYmxlIGFuZCB3cml0YWJsZSB3aXRob3V0IGJsb2NraW5nLgoKVGhpcyBw
YXRjaCBhZGQgLnBvbGwgbWV0aG9kIHRvIHhlbiBtY2Vsb2cgZGV2aWNlIGRyaXZlciwgc28gdGhh
dAp3aGVuIG1jZWxvZyB1c2Ugc3lzdGVtIGNhbGxzIGxpa2UgcHBvbGwgb3Igc2VsZWN0LCBpdCB3
b3VsZCBiZQpibG9ja2VkIHdoZW4gbm8gZGF0YSBhdmFpbGFibGUsIGFuZCBhdm9pZCBzcGlubmlu
ZyBhdCBDUFUuCgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2ls
a0BvcmFjbGUuY29tPgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KLS0tCiBkcml2ZXJzL3hlbi9tY2Vsb2cuYyB8ICAgMTAgKysrKysrKysrKwogMSBm
aWxlcyBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL21jZWxvZy5jIGIvZHJpdmVycy94ZW4vbWNlbG9nLmMKaW5kZXggODA0
YWEzYy4uYzBiMzljOSAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vbWNlbG9nLmMKKysrIGIvZHJp
dmVycy94ZW4vbWNlbG9nLmMKQEAgLTQxLDYgKzQxLDcgQEAKICNpbmNsdWRlIDxsaW51eC9taXNj
ZGV2aWNlLmg+CiAjaW5jbHVkZSA8bGludXgvdWFjY2Vzcy5oPgogI2luY2x1ZGUgPGxpbnV4L2Nh
cGFiaWxpdHkuaD4KKyNpbmNsdWRlIDxsaW51eC9wb2xsLmg+CiAKICNpbmNsdWRlIDx4ZW4vaW50
ZXJmYWNlL3hlbi5oPgogI2luY2x1ZGUgPHhlbi9ldmVudHMuaD4KQEAgLTEzNSw2ICsxMzYsMTQg
QEAgb3V0OgogCXJldHVybiBlcnIgPyBlcnIgOiBidWYgLSB1YnVmOwogfQogCitzdGF0aWMgdW5z
aWduZWQgaW50IHhlbl9tY2VfY2hyZGV2X3BvbGwoc3RydWN0IGZpbGUgKmZpbGUsIHBvbGxfdGFi
bGUgKndhaXQpCit7CisJaWYgKHhlbl9tY2Vsb2cubmV4dCkKKwkJcmV0dXJuIFBPTExJTiB8IFBP
TExSRE5PUk07CisKKwlyZXR1cm4gMDsKK30KKwogc3RhdGljIGxvbmcgeGVuX21jZV9jaHJkZXZf
aW9jdGwoc3RydWN0IGZpbGUgKmYsIHVuc2lnbmVkIGludCBjbWQsCiAJCQkJdW5zaWduZWQgbG9u
ZyBhcmcpCiB7CkBAIC0xNjYsNiArMTc1LDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBmaWxlX29w
ZXJhdGlvbnMgeGVuX21jZV9jaHJkZXZfb3BzID0gewogCS5vcGVuCQkJPSB4ZW5fbWNlX2NocmRl
dl9vcGVuLAogCS5yZWxlYXNlCQk9IHhlbl9tY2VfY2hyZGV2X3JlbGVhc2UsCiAJLnJlYWQJCQk9
IHhlbl9tY2VfY2hyZGV2X3JlYWQsCisJLnBvbGwJCQk9IHhlbl9tY2VfY2hyZGV2X3BvbGwsCiAJ
LnVubG9ja2VkX2lvY3RsCQk9IHhlbl9tY2VfY2hyZGV2X2lvY3RsLAogCS5sbHNlZWsJCQk9IG5v
X2xsc2VlaywKIH07Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923352321ABSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Jun 14 12:57:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:57: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 1Sf9cR-00081s-3l; Thu, 14 Jun 2012 12:57:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Sf9cP-00081g-Qr
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:57:46 +0000
Received: from [85.158.138.51:59164] by server-12.bemta-3.messagelabs.com id
	77/C0-30206-4CFD9DF4; Thu, 14 Jun 2012 12:57:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339678659!27550521!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMjY2MTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13709 invoked from network); 14 Jun 2012 12:57:39 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 12:57:39 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8D865604076;
	Thu, 14 Jun 2012 05:57:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sPIFXqZPStPdGYX2/napuBcTS1hVdDiT/obnQF6PLnB7
	HCW3c/tft9f8PN04LLqOLc/GAob2aC2mwH1FQckdfgQMYy81E1frUOzsUd+nrY1x
	1MUQ9MwseAlN5AljHqsa//gdmOSNVl5FtO9kkMr0zznZuAfwCa2Gsodp/2LGbQc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=2kcaUAfm1wTyzw+QwpfYvO7yPIM=; b=EdTRtG2j
	wQW7X/FhpY8lkifhXnW8Zy+Ppj0r6a10zH0DlQvGtlOtyJj5S6uDDnAm4/zocRF8
	8C49KBLA467CQVLtrk7Z5qdKT9bOyL/9N48zOTzFQTPI/vuIzcIrgPIQWiTNPMdA
	zOX7DW9cuUJcx4yXhED26g0B3Ngi/TnNIPM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 423AC604061; 
	Thu, 14 Jun 2012 05:57:38 -0700 (PDT)
Received: from 69.165.148.193 (proxying for 69.165.148.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 14 Jun 2012 05:57:38 -0700
Message-ID: <d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120614102808.GI82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
Date: Thu, 14 Jun 2012 05:57:38 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
 pod: Check zero-check pages returned by the balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
>> +        else if( p2m_is_ram(t) )
>> +        {
>> +            if ( steal_for_cache )
>> +            {
>> +                struct page_info *page;
>> +
>> +                ASSERT(mfn_valid(mfn));
>
> I think this assertion is broken by the paging code, which adds
> paged-out pages to the RAM types.  One fix is to undo that change and
> have p2m_is_ram() only be true for present pages, but I think for 4.2 it
> would be less disruptive to test here for the paged-out and paging
> types.
>
> Cc'ing Andres on the larger question -- do you think we can have
> p2m_is_ram() imply mfn_valid() again?  I'm not sure whether it will make
> things cleaner (or at least move the burden of handling paged-out memory
> into the paging code) or add more boilerplate to paths where the paging
> will be handled after a check for p2m_os_ram().  What do you think?
>

Imho, pages in any of the states of the paging state machine, are ram.
They are not mmio, grants or whatever. They just happen to be absent at
the moment.

This is not an immediately useful response because its corollary entails
that PoD pages are also ram.

There are a few possible ways around this. One problem is that
p2m_ram_paging_in may or may not have a backing mfn, so we can't just
check the p2mt, and that is frankly annoying (plenty of wth conditionals
in the p2m code relate to this). We could disambiguate with two states,
e.g.:
 p2m_ram_paging_in_absent
 p2m_ram_paging_present
 p2m_is_paging_in(p2mt) returns true for both -> use in most cases where
p2m_ram_paging_in is used right now
 p2m_is_ram_present(p2mt) returns true for p2m_ram_rw, log dirty, shared,
paging_out and paging_in present -> used in cases like above
 p2m_is_ram(p2mt) includes ram_present and pod and paging_in_absent ->
used in broader cases

That looks like a fairly dangerous changeset. But the more comprehensive
solution. The path of least resistance is obviously to just fix George's
current patches.

btw, George, couple of #if 0's and //'s on your "Check zero-check pages
returned by the balloon driver" patch. Those are going out before tree
inclusion, I assume?

Thanks
Andres


) Then most checks for p2m_ram_paging, s/
> 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 Jun 14 12:57:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 12:57: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 1Sf9cR-00081s-3l; Thu, 14 Jun 2012 12:57:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Sf9cP-00081g-Qr
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:57:46 +0000
Received: from [85.158.138.51:59164] by server-12.bemta-3.messagelabs.com id
	77/C0-30206-4CFD9DF4; Thu, 14 Jun 2012 12:57:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1339678659!27550521!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMjY2MTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13709 invoked from network); 14 Jun 2012 12:57:39 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 12:57:39 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8D865604076;
	Thu, 14 Jun 2012 05:57:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sPIFXqZPStPdGYX2/napuBcTS1hVdDiT/obnQF6PLnB7
	HCW3c/tft9f8PN04LLqOLc/GAob2aC2mwH1FQckdfgQMYy81E1frUOzsUd+nrY1x
	1MUQ9MwseAlN5AljHqsa//gdmOSNVl5FtO9kkMr0zznZuAfwCa2Gsodp/2LGbQc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=2kcaUAfm1wTyzw+QwpfYvO7yPIM=; b=EdTRtG2j
	wQW7X/FhpY8lkifhXnW8Zy+Ppj0r6a10zH0DlQvGtlOtyJj5S6uDDnAm4/zocRF8
	8C49KBLA467CQVLtrk7Z5qdKT9bOyL/9N48zOTzFQTPI/vuIzcIrgPIQWiTNPMdA
	zOX7DW9cuUJcx4yXhED26g0B3Ngi/TnNIPM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 423AC604061; 
	Thu, 14 Jun 2012 05:57:38 -0700 (PDT)
Received: from 69.165.148.193 (proxying for 69.165.148.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 14 Jun 2012 05:57:38 -0700
Message-ID: <d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120614102808.GI82539@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
Date: Thu, 14 Jun 2012 05:57:38 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
 pod: Check zero-check pages returned by the balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
>> +        else if( p2m_is_ram(t) )
>> +        {
>> +            if ( steal_for_cache )
>> +            {
>> +                struct page_info *page;
>> +
>> +                ASSERT(mfn_valid(mfn));
>
> I think this assertion is broken by the paging code, which adds
> paged-out pages to the RAM types.  One fix is to undo that change and
> have p2m_is_ram() only be true for present pages, but I think for 4.2 it
> would be less disruptive to test here for the paged-out and paging
> types.
>
> Cc'ing Andres on the larger question -- do you think we can have
> p2m_is_ram() imply mfn_valid() again?  I'm not sure whether it will make
> things cleaner (or at least move the burden of handling paged-out memory
> into the paging code) or add more boilerplate to paths where the paging
> will be handled after a check for p2m_os_ram().  What do you think?
>

Imho, pages in any of the states of the paging state machine, are ram.
They are not mmio, grants or whatever. They just happen to be absent at
the moment.

This is not an immediately useful response because its corollary entails
that PoD pages are also ram.

There are a few possible ways around this. One problem is that
p2m_ram_paging_in may or may not have a backing mfn, so we can't just
check the p2mt, and that is frankly annoying (plenty of wth conditionals
in the p2m code relate to this). We could disambiguate with two states,
e.g.:
 p2m_ram_paging_in_absent
 p2m_ram_paging_present
 p2m_is_paging_in(p2mt) returns true for both -> use in most cases where
p2m_ram_paging_in is used right now
 p2m_is_ram_present(p2mt) returns true for p2m_ram_rw, log dirty, shared,
paging_out and paging_in present -> used in cases like above
 p2m_is_ram(p2mt) includes ram_present and pod and paging_in_absent ->
used in broader cases

That looks like a fairly dangerous changeset. But the more comprehensive
solution. The path of least resistance is obviously to just fix George's
current patches.

btw, George, couple of #if 0's and //'s on your "Check zero-check pages
returned by the balloon driver" patch. Those are going out before tree
inclusion, I assume?

Thanks
Andres


) Then most checks for p2m_ram_paging, s/
> 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 Jun 14 13:14:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1Sf9s7-00005V-0t; Thu, 14 Jun 2012 13:13:59 +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 1Sf9s5-00005O-Ji
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:13:57 +0000
Received: from [85.158.143.99:41917] by server-2.bemta-4.messagelabs.com id
	B7/FE-17938-493E9DF4; Thu, 14 Jun 2012 13:13:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339679635!27047657!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5063 invoked from network); 14 Jun 2012 13:13:56 -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; 14 Jun 2012 13:13:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf9s3-000PPi-HX; Thu, 14 Jun 2012 13:13:55 +0000
Date: Thu, 14 Jun 2012 14:13:55 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120614131355.GB90181@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
	<20120614091131.GD82539@ocelot.phlegethon.org>
	<CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
	pod: Only sweep in an emergency, and only for 4k 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:42 +0100 on 14 Jun (1339681375), George Dunlap wrote:
> On Thu, Jun 14, 2012 at 10:11 AM, Tim Deegan <tim@xen.org> wrote:
> > At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
> >> + =A0 =A0if ( p2m->pod.count =3D=3D 0 )
> >> + =A0 =A0 =A0 =A0goto out_of_memory;
> >>
> >> =A0 =A0 =A0/* Keep track of the highest gfn demand-populated by a gues=
t fault */
> >> =A0 =A0 =A0if ( gfn > p2m->pod.max_guest )
> >> =A0 =A0 =A0 =A0 =A0p2m->pod.max_guest =3D gfn;
> >>
> >> - =A0 =A0if ( p2m->pod.count =3D=3D 0 )
> >> - =A0 =A0 =A0 =A0goto out_of_memory;
> >> -
> >
> > Is this code motion just noise? =A0Since out_of_memory crasheds the gue=
st,
> > I assume so.
> =

> It will have no practical effect, other than improving the efficiency
> of crashing a guest by a few cycles, if that's what you're asking.
> It's more about taste: it just seemed silly to make an assignment and
> *then* see if you were going to crash. :-)

Well, yes. :)  I don't think it quite falls under the description of the
patch, though.  Can you split it out as a cleanup 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 Jun 14 13:14:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1Sf9s7-00005V-0t; Thu, 14 Jun 2012 13:13:59 +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 1Sf9s5-00005O-Ji
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:13:57 +0000
Received: from [85.158.143.99:41917] by server-2.bemta-4.messagelabs.com id
	B7/FE-17938-493E9DF4; Thu, 14 Jun 2012 13:13:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1339679635!27047657!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5063 invoked from network); 14 Jun 2012 13:13:56 -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; 14 Jun 2012 13:13:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf9s3-000PPi-HX; Thu, 14 Jun 2012 13:13:55 +0000
Date: Thu, 14 Jun 2012 14:13:55 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120614131355.GB90181@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
	<20120614091131.GD82539@ocelot.phlegethon.org>
	<CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
	pod: Only sweep in an emergency, and only for 4k 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:42 +0100 on 14 Jun (1339681375), George Dunlap wrote:
> On Thu, Jun 14, 2012 at 10:11 AM, Tim Deegan <tim@xen.org> wrote:
> > At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
> >> + =A0 =A0if ( p2m->pod.count =3D=3D 0 )
> >> + =A0 =A0 =A0 =A0goto out_of_memory;
> >>
> >> =A0 =A0 =A0/* Keep track of the highest gfn demand-populated by a gues=
t fault */
> >> =A0 =A0 =A0if ( gfn > p2m->pod.max_guest )
> >> =A0 =A0 =A0 =A0 =A0p2m->pod.max_guest =3D gfn;
> >>
> >> - =A0 =A0if ( p2m->pod.count =3D=3D 0 )
> >> - =A0 =A0 =A0 =A0goto out_of_memory;
> >> -
> >
> > Is this code motion just noise? =A0Since out_of_memory crasheds the gue=
st,
> > I assume so.
> =

> It will have no practical effect, other than improving the efficiency
> of crashing a guest by a few cycles, if that's what you're asking.
> It's more about taste: it just seemed silly to make an assignment and
> *then* see if you were going to crash. :-)

Well, yes. :)  I don't think it quite falls under the description of the
patch, though.  Can you split it out as a cleanup 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 Jun 14 13:19:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1Sf9xR-0000GG-P4; Thu, 14 Jun 2012 13:19:29 +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 1Sf9xQ-0000GB-Rt
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:19:28 +0000
Received: from [193.109.254.147:52664] by server-12.bemta-14.messagelabs.com
	id 8C/CB-12998-0E4E9DF4; Thu, 14 Jun 2012 13:19:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339679967!9705061!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk4MTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk4MTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25534 invoked from network); 14 Jun 2012 13:19:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 13:19:27 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14])
	by smtp.strato.de (jored mo71) (RZmta 29.13 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g07e40o5EAV43e ;
	Thu, 14 Jun 2012 15:19:25 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id DA6D218638; Thu, 14 Jun 2012 15:19:23 +0200 (CEST)
Date: Thu, 14 Jun 2012 15:19:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120614131923.GA9349@aepfle.de>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614102808.GI82539@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
 pod: Check zero-check pages returned by the balloon 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, Jun 14, Tim Deegan wrote:

> At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
> > +        else if( p2m_is_ram(t) )
> > +        {
> > +            if ( steal_for_cache )
> > +            {
> > +                struct page_info *page;
> > +                
> > +                ASSERT(mfn_valid(mfn));
> 
> I think this assertion is broken by the paging code, which adds
> paged-out pages to the RAM types.  One fix is to undo that change and
> have p2m_is_ram() only be true for present pages, but I think for 4.2 it
> would be less disruptive to test here for the paged-out and paging
> types.

I assume the posted hunk is in PoD code, for 4.2 it should be fine
because paging cant be enabled if PoD is already enabled.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:19:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1Sf9xR-0000GG-P4; Thu, 14 Jun 2012 13:19:29 +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 1Sf9xQ-0000GB-Rt
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:19:28 +0000
Received: from [193.109.254.147:52664] by server-12.bemta-14.messagelabs.com
	id 8C/CB-12998-0E4E9DF4; Thu, 14 Jun 2012 13:19:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339679967!9705061!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk4MTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk4MTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25534 invoked from network); 14 Jun 2012 13:19:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 13:19:27 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69z6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-14.vodafone-net.de [80.226.24.14])
	by smtp.strato.de (jored mo71) (RZmta 29.13 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g07e40o5EAV43e ;
	Thu, 14 Jun 2012 15:19:25 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id DA6D218638; Thu, 14 Jun 2012 15:19:23 +0200 (CEST)
Date: Thu, 14 Jun 2012 15:19:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120614131923.GA9349@aepfle.de>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614102808.GI82539@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
 pod: Check zero-check pages returned by the balloon 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, Jun 14, Tim Deegan wrote:

> At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
> > +        else if( p2m_is_ram(t) )
> > +        {
> > +            if ( steal_for_cache )
> > +            {
> > +                struct page_info *page;
> > +                
> > +                ASSERT(mfn_valid(mfn));
> 
> I think this assertion is broken by the paging code, which adds
> paged-out pages to the RAM types.  One fix is to undo that change and
> have p2m_is_ram() only be true for present pages, but I think for 4.2 it
> would be less disruptive to test here for the paged-out and paging
> types.

I assume the posted hunk is in PoD code, for 4.2 it should be fine
because paging cant be enabled if PoD is already enabled.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1Sf9yD-0000JP-9H; Thu, 14 Jun 2012 13:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf9yB-0000JA-Ow
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:20:15 +0000
Received: from [85.158.143.35:52585] by server-3.bemta-4.messagelabs.com id
	F0/17-05808-F05E9DF4; Thu, 14 Jun 2012 13:20:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339680013!14512743!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6249 invoked from network); 14 Jun 2012 13:20:14 -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; 14 Jun 2012 13:20:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf9xB-000PUQ-W2; Thu, 14 Jun 2012 13:19:13 +0000
Date: Thu, 14 Jun 2012 14:19:13 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120614131913.GC90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
	<d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
	pod: Check zero-check pages returned by the balloon 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

At 05:57 -0700 on 14 Jun (1339653458), Andres Lagar-Cavilla wrote:
> Imho, pages in any of the states of the paging state machine, are ram.
> They are not mmio, grants or whatever. They just happen to be absent at
> the moment.
> 
> This is not an immediately useful response because its corollary entails
> that PoD pages are also ram.

I'm OK with that interpretation, as long as we decide it one way or the
other and make sure that all users are correct. :)

> There are a few possible ways around this. One problem is that
> p2m_ram_paging_in may or may not have a backing mfn, so we can't just
> check the p2mt, and that is frankly annoying (plenty of wth conditionals
> in the p2m code relate to this). We could disambiguate with two states,
> e.g.:
>  p2m_ram_paging_in_absent
>  p2m_ram_paging_present
>  p2m_is_paging_in(p2mt) returns true for both -> use in most cases where
> p2m_ram_paging_in is used right now

That sounds like a good idea; for after 4.2 though. 

>  p2m_is_ram_present(p2mt) returns true for p2m_ram_rw, log dirty, shared,
> paging_out and paging_in present -> used in cases like above
>  p2m_is_ram(p2mt) includes ram_present and pod and paging_in_absent ->
> used in broader cases
> 
> That looks like a fairly dangerous changeset. But the more comprehensive
> solution. The path of least resistance is obviously to just fix George's
> current patches.

Agreed.  I was really asking how you'd like to approach this after 4.2 has
branched.

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 Jun 14 13:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1Sf9yD-0000JP-9H; Thu, 14 Jun 2012 13:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sf9yB-0000JA-Ow
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:20:15 +0000
Received: from [85.158.143.35:52585] by server-3.bemta-4.messagelabs.com id
	F0/17-05808-F05E9DF4; Thu, 14 Jun 2012 13:20:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339680013!14512743!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6249 invoked from network); 14 Jun 2012 13:20:14 -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; 14 Jun 2012 13:20:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf9xB-000PUQ-W2; Thu, 14 Jun 2012 13:19:13 +0000
Date: Thu, 14 Jun 2012 14:19:13 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120614131913.GC90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
	<d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d449dac2eeb7dbf04d71c9b4492b5d8d.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
	pod: Check zero-check pages returned by the balloon 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

At 05:57 -0700 on 14 Jun (1339653458), Andres Lagar-Cavilla wrote:
> Imho, pages in any of the states of the paging state machine, are ram.
> They are not mmio, grants or whatever. They just happen to be absent at
> the moment.
> 
> This is not an immediately useful response because its corollary entails
> that PoD pages are also ram.

I'm OK with that interpretation, as long as we decide it one way or the
other and make sure that all users are correct. :)

> There are a few possible ways around this. One problem is that
> p2m_ram_paging_in may or may not have a backing mfn, so we can't just
> check the p2mt, and that is frankly annoying (plenty of wth conditionals
> in the p2m code relate to this). We could disambiguate with two states,
> e.g.:
>  p2m_ram_paging_in_absent
>  p2m_ram_paging_present
>  p2m_is_paging_in(p2mt) returns true for both -> use in most cases where
> p2m_ram_paging_in is used right now

That sounds like a good idea; for after 4.2 though. 

>  p2m_is_ram_present(p2mt) returns true for p2m_ram_rw, log dirty, shared,
> paging_out and paging_in present -> used in cases like above
>  p2m_is_ram(p2mt) includes ram_present and pod and paging_in_absent ->
> used in broader cases
> 
> That looks like a fairly dangerous changeset. But the more comprehensive
> solution. The path of least resistance is obviously to just fix George's
> current patches.

Agreed.  I was really asking how you'd like to approach this after 4.2 has
branched.

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 Jun 14 13:21:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf9zL-0000QF-Nc; Thu, 14 Jun 2012 13:21: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 1Sf9zL-0000Q7-C5
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:21:27 +0000
Received: from [85.158.143.35:2613] by server-2.bemta-4.messagelabs.com id
	F6/9C-17938-655E9DF4; Thu, 14 Jun 2012 13:21:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339680057!5882566!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31285 invoked from network); 14 Jun 2012 13:21:07 -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 Jun 2012 13:21:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf9yq-000PW4-Ie; Thu, 14 Jun 2012 13:20:56 +0000
Date: Thu, 14 Jun 2012 14:20:56 +0100
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120614132056.GD90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
	<20120614131923.GA9349@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614131923.GA9349@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
	pod: Check zero-check pages returned by the balloon 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

At 15:19 +0200 on 14 Jun (1339687163), Olaf Hering wrote:
> On Thu, Jun 14, Tim Deegan wrote:
> 
> > At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
> > > +        else if( p2m_is_ram(t) )
> > > +        {
> > > +            if ( steal_for_cache )
> > > +            {
> > > +                struct page_info *page;
> > > +                
> > > +                ASSERT(mfn_valid(mfn));
> > 
> > I think this assertion is broken by the paging code, which adds
> > paged-out pages to the RAM types.  One fix is to undo that change and
> > have p2m_is_ram() only be true for present pages, but I think for 4.2 it
> > would be less disruptive to test here for the paged-out and paging
> > types.
> 
> I assume the posted hunk is in PoD code, for 4.2 it should be fine
> because paging cant be enabled if PoD is already enabled.

Good point.  OK, we can ignore it for now and sort it all out after 4.2

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:21:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sf9zL-0000QF-Nc; Thu, 14 Jun 2012 13:21: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 1Sf9zL-0000Q7-C5
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:21:27 +0000
Received: from [85.158.143.35:2613] by server-2.bemta-4.messagelabs.com id
	F6/9C-17938-655E9DF4; Thu, 14 Jun 2012 13:21:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339680057!5882566!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31285 invoked from network); 14 Jun 2012 13:21:07 -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 Jun 2012 13:21:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sf9yq-000PW4-Ie; Thu, 14 Jun 2012 13:20:56 +0000
Date: Thu, 14 Jun 2012 14:20:56 +0100
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120614132056.GD90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<8264589787b484b7f903.1339156492@elijah>
	<20120614102808.GI82539@ocelot.phlegethon.org>
	<20120614131923.GA9349@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614131923.GA9349@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <george.dunlap@eu.citrix.com>, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 RFC] xen,
	pod: Check zero-check pages returned by the balloon 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

At 15:19 +0200 on 14 Jun (1339687163), Olaf Hering wrote:
> On Thu, Jun 14, Tim Deegan wrote:
> 
> > At 12:54 +0100 on 08 Jun (1339160092), George Dunlap wrote:
> > > +        else if( p2m_is_ram(t) )
> > > +        {
> > > +            if ( steal_for_cache )
> > > +            {
> > > +                struct page_info *page;
> > > +                
> > > +                ASSERT(mfn_valid(mfn));
> > 
> > I think this assertion is broken by the paging code, which adds
> > paged-out pages to the RAM types.  One fix is to undo that change and
> > have p2m_is_ram() only be true for present pages, but I think for 4.2 it
> > would be less disruptive to test here for the paged-out and paging
> > types.
> 
> I assume the posted hunk is in PoD code, for 4.2 it should be fine
> because paging cant be enabled if PoD is already enabled.

Good point.  OK, we can ignore it for now and sort it all out after 4.2

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:32:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1SfAA8-0000iD-GH; Thu, 14 Jun 2012 13:32:36 +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 1SfAA7-0000i8-1n
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:32:35 +0000
Received: from [85.158.143.99:59214] by server-1.bemta-4.messagelabs.com id
	77/BE-24392-2F7E9DF4; Thu, 14 Jun 2012 13:32:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339680752!27405862!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3000 invoked from network); 14 Jun 2012 13:32:33 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 13:32:33 -0000
Received: by qcsp15 with SMTP id p15so1382863qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 06:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=+kymv9Mm1EK00eSygh4i6Rx5IjGO9rcbqRkKFe/xc9I=;
	b=lvmoC6WL/hJ4Nm+Iva70T+PU1MltSkoZXGVm8bKbkTpwOhS3qn7oXI+fChUlJL5Bf5
	A0H4F3uG80JSUXuh98U3QqxNzXZ43YXZNpr9MWeZrCiA9Pl4lXTuuqYIjx/yipM92l5Z
	U1ZRVDwBYVF5sYpxyIVh+R5dST34tXKw5agjwQHTjYvhN1jclyYo2Y5ZRhYiOnmMltFT
	PIkSupIFFcD5aDCbe1gxSzFf+X/D9z7YyK5bcO9SB5zonP1uzN5oXb8m4Ef89EIXr7UI
	oaN21Hhnw2rjY85RBlmSrg1Ssyb1BF5h6R96K/6FDjlXNTa6x3c/LjDhOuOsEhZdH8/X
	n0TA==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr4283186qae.26.1339680752451; Thu,
	14 Jun 2012 06:32:32 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 14 Jun 2012 06:32:32 -0700 (PDT)
In-Reply-To: <20120614131355.GB90181@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
	<20120614091131.GD82539@ocelot.phlegethon.org>
	<CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
	<20120614131355.GB90181@ocelot.phlegethon.org>
Date: Thu, 14 Jun 2012 14:32:32 +0100
X-Google-Sender-Auth: YGeYY0wxStRkVv4fM2OvoBqmnbU
Message-ID: <CAFLBxZabsZ1xSUaP1ukXFFKBgLHEG36w=kTxh-t+Et5TEAuj_Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
 pod: Only sweep in an emergency, and only for 4k 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[re-including xen-devel in the cc]]

On Thu, Jun 14, 2012 at 2:13 PM, Tim Deegan <tim@xen.org> wrote:
> At 13:42 +0100 on 14 Jun (1339681375), George Dunlap wrote:
>> On Thu, Jun 14, 2012 at 10:11 AM, Tim Deegan <tim@xen.org> wrote:
>> > At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
>> >> + =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> >> + =A0 =A0 =A0 =A0goto out_of_memory;
>> >>
>> >> =A0 =A0 =A0/* Keep track of the highest gfn demand-populated by a gue=
st fault */
>> >> =A0 =A0 =A0if ( gfn > p2m->pod.max_guest )
>> >> =A0 =A0 =A0 =A0 =A0p2m->pod.max_guest =3D gfn;
>> >>
>> >> - =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> >> - =A0 =A0 =A0 =A0goto out_of_memory;
>> >> -
>> >
>> > Is this code motion just noise? =A0Since out_of_memory crasheds the gu=
est,
>> > I assume so.
>>
>> It will have no practical effect, other than improving the efficiency
>> of crashing a guest by a few cycles, if that's what you're asking.
>> It's more about taste: it just seemed silly to make an assignment and
>> *then* see if you were going to crash. :-)
>
> Well, yes. :) =A0I don't think it quite falls under the description of the
> patch, though. =A0Can you split it out as a cleanup patch?

If that's what you meant, you should have said so. :-)  I shall do so
for the next series.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:32:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13: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 1SfAA8-0000iD-GH; Thu, 14 Jun 2012 13:32:36 +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 1SfAA7-0000i8-1n
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:32:35 +0000
Received: from [85.158.143.99:59214] by server-1.bemta-4.messagelabs.com id
	77/BE-24392-2F7E9DF4; Thu, 14 Jun 2012 13:32:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339680752!27405862!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3000 invoked from network); 14 Jun 2012 13:32:33 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 13:32:33 -0000
Received: by qcsp15 with SMTP id p15so1382863qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 06:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=+kymv9Mm1EK00eSygh4i6Rx5IjGO9rcbqRkKFe/xc9I=;
	b=lvmoC6WL/hJ4Nm+Iva70T+PU1MltSkoZXGVm8bKbkTpwOhS3qn7oXI+fChUlJL5Bf5
	A0H4F3uG80JSUXuh98U3QqxNzXZ43YXZNpr9MWeZrCiA9Pl4lXTuuqYIjx/yipM92l5Z
	U1ZRVDwBYVF5sYpxyIVh+R5dST34tXKw5agjwQHTjYvhN1jclyYo2Y5ZRhYiOnmMltFT
	PIkSupIFFcD5aDCbe1gxSzFf+X/D9z7YyK5bcO9SB5zonP1uzN5oXb8m4Ef89EIXr7UI
	oaN21Hhnw2rjY85RBlmSrg1Ssyb1BF5h6R96K/6FDjlXNTa6x3c/LjDhOuOsEhZdH8/X
	n0TA==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr4283186qae.26.1339680752451; Thu,
	14 Jun 2012 06:32:32 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 14 Jun 2012 06:32:32 -0700 (PDT)
In-Reply-To: <20120614131355.GB90181@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<6e760eb25dac400f4873.1339155933@exile>
	<20120614091131.GD82539@ocelot.phlegethon.org>
	<CAFLBxZZnqH0m5Pki8VFnH=2tVRnsJH=V=-tEa3PeRVSJ-_f1VA@mail.gmail.com>
	<20120614131355.GB90181@ocelot.phlegethon.org>
Date: Thu, 14 Jun 2012 14:32:32 +0100
X-Google-Sender-Auth: YGeYY0wxStRkVv4fM2OvoBqmnbU
Message-ID: <CAFLBxZabsZ1xSUaP1ukXFFKBgLHEG36w=kTxh-t+Et5TEAuj_Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 2 RFC] xen,
 pod: Only sweep in an emergency, and only for 4k 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[re-including xen-devel in the cc]]

On Thu, Jun 14, 2012 at 2:13 PM, Tim Deegan <tim@xen.org> wrote:
> At 13:42 +0100 on 14 Jun (1339681375), George Dunlap wrote:
>> On Thu, Jun 14, 2012 at 10:11 AM, Tim Deegan <tim@xen.org> wrote:
>> > At 11:45 +0000 on 08 Jun (1339155933), George Dunlap wrote:
>> >> + =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> >> + =A0 =A0 =A0 =A0goto out_of_memory;
>> >>
>> >> =A0 =A0 =A0/* Keep track of the highest gfn demand-populated by a gue=
st fault */
>> >> =A0 =A0 =A0if ( gfn > p2m->pod.max_guest )
>> >> =A0 =A0 =A0 =A0 =A0p2m->pod.max_guest =3D gfn;
>> >>
>> >> - =A0 =A0if ( p2m->pod.count =3D=3D 0 )
>> >> - =A0 =A0 =A0 =A0goto out_of_memory;
>> >> -
>> >
>> > Is this code motion just noise? =A0Since out_of_memory crasheds the gu=
est,
>> > I assume so.
>>
>> It will have no practical effect, other than improving the efficiency
>> of crashing a guest by a few cycles, if that's what you're asking.
>> It's more about taste: it just seemed silly to make an assignment and
>> *then* see if you were going to crash. :-)
>
> Well, yes. :) =A0I don't think it quite falls under the description of the
> patch, though. =A0Can you split it out as a cleanup patch?

If that's what you meant, you should have said so. :-)  I shall do so
for the next series.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:45:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13:45: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 1SfAMF-0000tw-TT; Thu, 14 Jun 2012 13:45: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 1SfAME-0000tr-5u
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:45:06 +0000
Received: from [193.109.254.147:22208] by server-10.bemta-14.messagelabs.com
	id 90/6F-25709-1EAE9DF4; Thu, 14 Jun 2012 13:45:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339681504!7333335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22929 invoked from network); 14 Jun 2012 13:45:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 13:45:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13023184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:45:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 14:45:04 +0100
Date: Thu, 14 Jun 2012 14:44:40 +0100
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: <20120613193926.GA21706@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1206141223240.14957@kaball.uk.xensource.com>
References: <1337795840-10061-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120613193926.GA21706@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen: mark local pages as FOREIGN in the
 m2p_override
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 13 Jun 2012, Konrad Rzeszutek Wilk wrote:
> On Wed, May 23, 2012 at 06:57:20PM +0100, Stefano Stabellini wrote:
> > When the frontend and the backend reside on the same domain, even if we
> > add pages to the m2p_override, these pages will never be returned by
> > mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
> > always fail, so the pfn of the frontend will be returned instead
> > (resulting in a deadlock because the frontend pages are already locked).
> 
> If I recall you were suppose to attach the stack trace here
> and also explain a bit about how the lock happens (like a call-tree).

This is the stack trace:

[ 7440.396076] INFO: task qemu-system-i38:1085 blocked for more than 120 seconds.
[ 7440.396089] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7440.396096] qemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000
[ 7440.396105]  ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0
[ 7440.396115]  ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0
[ 7440.396124]  ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0
[ 7440.396134] Call Trace:
[ 7440.396146]  [<ffffffff81101ee0>] ? __lock_page+0x70/0x70
[ 7440.396155]  [<ffffffff81a0fdd9>] schedule+0x29/0x70
[ 7440.396160]  [<ffffffff81a0fe80>] io_schedule+0x60/0x80
[ 7440.396166]  [<ffffffff81101eee>] sleep_on_page+0xe/0x20
[ 7440.396172]  [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0
[ 7440.396179]  [<ffffffff81101ed7>] __lock_page+0x67/0x70
[ 7440.396207]  [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40
[ 7440.396215]  [<ffffffff811867e6>] ? bio_add_page+0x36/0x40
[ 7440.396222]  [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60
[ 7440.396228]  [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70
[ 7440.396235]  [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0
[ 7440.396244]  [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
[ 7440.396251]  [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60
[ 7440.396258]  [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
[ 7440.396265]  [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390
[ 7440.396271]  [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
[ 7440.396278]  [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0
[ 7440.396285]  [<ffffffff81104027>] generic_file_aio_read+0x737/0x780
[ 7440.396293]  [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0
[ 7440.396300]  [<ffffffff811038f0>] ? find_get_pages+0x150/0x150
[ 7440.396308]  [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0
[ 7440.396315]  [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90
[ 7440.396320]  [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0
[ 7440.396326]  [<ffffffff811998b8>] do_io_submit+0x708/0xb90
[ 7440.396333]  [<ffffffff81199d50>] sys_io_submit+0x10/0x20
[ 7440.396340]  [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b



The explanation is in the comment within the code:

+        * We need to do this because the pages shared by the frontend
+        * (xen-blkfront) can be already locked (lock_page, called by
+        * do_read_cache_page); when the userspace backend tries to use them
+        * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
+        * do_blockdev_direct_IO is going to try to lock the same pages
+        * again resulting in a deadlock.


A simplified call graph looks like this:

pygrub                          QEMU
-----------------------------------------------
do_read_cache_page              io_submit
  |                              |
lock_page                       ext3_direct_IO
                                 |
                                bio_add_page
                                 |
                                lock_page




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:45:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13:45: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 1SfAMF-0000tw-TT; Thu, 14 Jun 2012 13:45: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 1SfAME-0000tr-5u
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:45:06 +0000
Received: from [193.109.254.147:22208] by server-10.bemta-14.messagelabs.com
	id 90/6F-25709-1EAE9DF4; Thu, 14 Jun 2012 13:45:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339681504!7333335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22929 invoked from network); 14 Jun 2012 13:45:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 13:45:04 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13023184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:45:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 14:45:04 +0100
Date: Thu, 14 Jun 2012 14:44:40 +0100
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: <20120613193926.GA21706@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1206141223240.14957@kaball.uk.xensource.com>
References: <1337795840-10061-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120613193926.GA21706@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen: mark local pages as FOREIGN in the
 m2p_override
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 13 Jun 2012, Konrad Rzeszutek Wilk wrote:
> On Wed, May 23, 2012 at 06:57:20PM +0100, Stefano Stabellini wrote:
> > When the frontend and the backend reside on the same domain, even if we
> > add pages to the m2p_override, these pages will never be returned by
> > mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
> > always fail, so the pfn of the frontend will be returned instead
> > (resulting in a deadlock because the frontend pages are already locked).
> 
> If I recall you were suppose to attach the stack trace here
> and also explain a bit about how the lock happens (like a call-tree).

This is the stack trace:

[ 7440.396076] INFO: task qemu-system-i38:1085 blocked for more than 120 seconds.
[ 7440.396089] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7440.396096] qemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000
[ 7440.396105]  ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0
[ 7440.396115]  ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0
[ 7440.396124]  ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0
[ 7440.396134] Call Trace:
[ 7440.396146]  [<ffffffff81101ee0>] ? __lock_page+0x70/0x70
[ 7440.396155]  [<ffffffff81a0fdd9>] schedule+0x29/0x70
[ 7440.396160]  [<ffffffff81a0fe80>] io_schedule+0x60/0x80
[ 7440.396166]  [<ffffffff81101eee>] sleep_on_page+0xe/0x20
[ 7440.396172]  [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0
[ 7440.396179]  [<ffffffff81101ed7>] __lock_page+0x67/0x70
[ 7440.396207]  [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40
[ 7440.396215]  [<ffffffff811867e6>] ? bio_add_page+0x36/0x40
[ 7440.396222]  [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60
[ 7440.396228]  [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70
[ 7440.396235]  [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0
[ 7440.396244]  [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
[ 7440.396251]  [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60
[ 7440.396258]  [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
[ 7440.396265]  [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390
[ 7440.396271]  [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
[ 7440.396278]  [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0
[ 7440.396285]  [<ffffffff81104027>] generic_file_aio_read+0x737/0x780
[ 7440.396293]  [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0
[ 7440.396300]  [<ffffffff811038f0>] ? find_get_pages+0x150/0x150
[ 7440.396308]  [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0
[ 7440.396315]  [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90
[ 7440.396320]  [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0
[ 7440.396326]  [<ffffffff811998b8>] do_io_submit+0x708/0xb90
[ 7440.396333]  [<ffffffff81199d50>] sys_io_submit+0x10/0x20
[ 7440.396340]  [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b



The explanation is in the comment within the code:

+        * We need to do this because the pages shared by the frontend
+        * (xen-blkfront) can be already locked (lock_page, called by
+        * do_read_cache_page); when the userspace backend tries to use them
+        * with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
+        * do_blockdev_direct_IO is going to try to lock the same pages
+        * again resulting in a deadlock.


A simplified call graph looks like this:

pygrub                          QEMU
-----------------------------------------------
do_read_cache_page              io_submit
  |                              |
lock_page                       ext3_direct_IO
                                 |
                                bio_add_page
                                 |
                                lock_page




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 13:51:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13:51: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 1SfASO-00015B-GX; Thu, 14 Jun 2012 13:51:28 +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 1SfASM-000156-E1
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:51:26 +0000
Received: from [85.158.143.35:14561] by server-2.bemta-4.messagelabs.com id
	1D/E5-17938-D5CE9DF4; Thu, 14 Jun 2012 13:51:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339681882!15074832!1
X-Originating-IP: [82.57.200.104]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27885 invoked from network); 14 Jun 2012 13:51:22 -0000
Received: from smtp208.alice.it (HELO smtp208.alice.it) (82.57.200.104)
	by server-13.tower-21.messagelabs.com with SMTP;
	14 Jun 2012 13:51:22 -0000
Received: from [192.168.178.50] (79.54.146.106) by smtp208.alice.it
	(8.6.023.02) id 4F056E851274EB5E; Thu, 14 Jun 2012 15:51:13 +0200
Message-ID: <4FD9EC4B.7090808@tiscali.it>
Date: Thu, 14 Jun 2012 15:51:07 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ZhouPeng <zpengxen@gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
	<4FD85F83.3080207@tiscali.it>
	<CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
In-Reply-To: <CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
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="===============0808294309665709548=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============0808294309665709548==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080008050201020608020108"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms080008050201020608020108
Content-Type: multipart/alternative;
 boundary="------------040604090805070908070808"

This is a multi-part message in MIME format.
--------------040604090805070908070808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/06/2012 13:40, ZhouPeng ha scritto:
> On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni<fantonifabio@tiscali.it>=
  wrote:
>> Il 13/06/2012 11:02, ZhouPeng ha scritto:
>>
>>> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.i=
t>
>>>   wrote:
>>>> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>>>>
>>>>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>>>>> <stefano.stabellini@eu.citrix.com>      wrote:
>>>>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>>>> Sorry for late reply, I am not on this mail these days because of=
 my
>>>>>>> work.
>>>>>>>
>>>>>>> I further test qxl-vga and I think I figure out the problem in so=
me
>>>>>>> extend.
>>>>>>>
>>>>>>> If using qxl device, the default memory size of vga is 64M.
>>>>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>>>>
>>>>>>> The exact reason is xc_domain_populate_physmap_exact fails, becau=
se
>>>>>>> xen-hypervisor
>>>>>>> fail,
>>>>>>> it's because of   alloc_domheap_pages(d, a->extent_order, a->memf=
lags)
>>>>>>> fails in hypervisor.
>>>>>>>
>>>>>>> I am not very familiar with xen's memory management, Does 64M exc=
eed
>>>>>>> xen's heap space in this context?
>>>>>> XL sets an upper bound of memory that can be allocated to the VM i=
n
>>>>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>>>>> My guess is that a 64MB allocation would go over that limit.
>>>>>> You could try increasing the limit manually changing the
>>>>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try set=
ting
>>>>>> videoram=3D64 in the VM config file.
>>>>> Your guess is absolutely right!
>>>>>
>>>>> But set videoram=3D128 or
>>>>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>>>>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>>>>
>>>>> Then I successfuly install qxl driver in win-hvm and QXL can work
>>>>> properly.
>>>>>
>>>>> I will send some patch to add qxl support to libxl.
>>>> I tried your 3 patches taken from the mailing list, it works but doe=
sn't
>>>> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
>>>> doesn't
>>>> start and on windows 7 I have heavy performance problem (unusable).
>>> Could you find qxl vga card  (named "Red Hat QXL GPU") in your
>>> windows hvm's device manager to make sure your qxl is working?
>>>
>>> My testing hvm-guest is Win XP.
>>>
>>> I played "Harry Potter" in my LAN smoothly, qxl gives
>>> great enhancement .
>>>
>>> Although I don't test win7 and linux, I think it should work for them=
=2E
>>>> I tried also with qemu 1.1.0 but nothing change.
>>> I am not sure qemu 1.1.0 accept all the patches for xen.
>>>
>>> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.=
git
>>>
>>> It is build and installed by default, you should enable spice support=
=2E
>>> spice can be enabled like below:
>>>
>>> +++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
>>> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>>>          --bindir=3D$(LIBEXEC) \
>>>          --datadir=3D$(SHAREDIR)/qemu-xen \
>>>          --disable-kvm \
>>> +       --enable-spice \
>>>
>>>> Does it work correctly for you? If so can I have some detail of your=

>>>> configurations please?
>>> My vm.cfg:
>>>
>>> name =3D 'xpPro_spice'
>>> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
>>> builder =3D 'hvm'
>>> memory =3D '1024'
>>> device_model_version =3D 'qemu-xen'
>>> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
>>> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
>>> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:2=
1:97:CB:0E:7D']
>>> sdl=3D0
>>> vnc=3D0
>>> vncviewer=3D0
>>> serial =3D 'pty'
>>> vcpus=3D1
>>> usbdevice=3D'tablet'
>>> #spice
>>> spice=3D1
>>> qxl=3D1
>>> #qxlram=3D64
>>> #qxlvram=3D64
>>> spiceport=3D6000
>>> spicehost=3D'192.168.1.187'
>>> spicedisable_ticketing =3D 1
>>> spiceagent_mouse =3D 0 # (1|0)
>>>
>>>> For audio support this is needed too: (tested and working)
>>>> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 =
on qemu
>>>> invocation and env QEMU_AUDIO_DRV=3Dspice
>>>> Can you add audio support on libxl please?
>>> I think audio support can be considered after qxl accpted.
>>>>
>> Thanks for reply, qxl driver is installed, windows see qxl video card,=

>> already compiled qemu with spice with patch I send months ago, already=
 tried
>> git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
>> Unfortunately the results are always the same.
>> Here a quick recording:
>> Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv
> oh...  it shows spice+qxl running on Xen get
> significant performance reduction compared with KVM ...
>
>> Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
>> Are not new but the result of the last test is the same.
>> I hope I can help you understand the problem.
>> If you need more information ask.
We are trying to reproduce your results but failed so far.
Can you give me details about the dom0 used for your tests please?
For example here are details about my testing dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version =

3.2.18-1, package blktap-dkms and all dependency packages for xen 4.2,=20
spice and usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=3D64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg
vi config/StdGNU.mk # Workaround for Wheezy with multiarch support,=20
there are parts that use LIBDIR set here instead of the one in configure =

(libdir)
LIBLEAFDIR_x86_64 ?=3D lib
vi Config.mk
PYTHON_PREFIX_ARG =3D
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
- libxc: do not "panic" if a kernel is not a bzImage.
- tools/hotplug/Linux/init.d/: added other xen kernel modules on=20
xencommons start
- 3 patches for add qxl support
-------------------------
=2E/configure --enable-qemuu-spice --enable-qemuu-usbredir=20
--enable-qemuu-debug
-------------------------
make deb

Is qxl someway affected by physical video card of dom0?
Have you installed spice-guest-tools-0.1.exe=20
<http://spice-space.org/download/binaries/spice-guest-tools-0.1.exe>=20
from spice site, if no what do you use for qxl driver?
Have you also installed gplpv driver or not?
Thanks for any reply.

--------------040604090805070908070808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DISO-8859-1"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    Il 13/06/2012 13:40, ZhouPeng ha scritto:
    <blockquote
cite=3D"mid:CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmai=
l.com"
      type=3D"cite">
      <pre wrap=3D"">On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni <a cl=
ass=3D"moz-txt-link-rfc2396E" href=3D"mailto:fantonifabio@tiscali.it">&lt=
;fantonifabio@tiscali.it&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Il 13/06/2012 11:02, ZhouPeng ha scritto:

</pre>
        <blockquote type=3D"cite">
          <pre wrap=3D"">On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<a=
 class=3D"moz-txt-link-rfc2396E" href=3D"mailto:fantonifabio@tiscali.it">=
&lt;fantonifabio@tiscali.it&gt;</a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre wrap=3D"">&nbsp;wrote:
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">
Il 24/05/2012 13:28, ZhouPeng ha scritto:

</pre>
            <blockquote type=3D"cite">
              <pre wrap=3D"">On Thu, May 24, 2012 at 6:13 PM, Stefano Sta=
bellini
<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:stefano.stabellini@eu.c=
itrix.com">&lt;stefano.stabellini@eu.citrix.com&gt;</a> &nbsp; &nbsp;wrot=
e:
</pre>
              <blockquote type=3D"cite">
                <pre wrap=3D"">
On Thu, 24 May 2012, ZhouPeng wrote:
</pre>
                <blockquote type=3D"cite">
                  <pre wrap=3D"">
Sorry for late reply, I am not on this mail these days because of my
work.

I further test qxl-vga and I think I figure out the problem in some
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <blockquote type=3D"cite">
              <blockquote type=3D"cite">
                <blockquote type=3D"cite">
                  <pre wrap=3D"">extend.

If using qxl device, the default memory size of vga is 64M.
Which will cause xen_ram_alloc(qemu/xen-all.c) fails.

The exact reason is xc_domain_populate_physmap_exact fails, because
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <blockquote type=3D"cite">
              <blockquote type=3D"cite">
                <blockquote type=3D"cite">
                  <pre wrap=3D"">xen-hypervisor
fail,
it's because of &nbsp; alloc_domheap_pages(d, a-&gt;extent_order, a-&gt;m=
emflags)
fails in hypervisor.

I am not very familiar with xen's memory management, Does 64M exceed
xen's heap space in this context?
</pre>
                </blockquote>
                <pre wrap=3D"">
XL sets an upper bound of memory that can be allocated to the VM in
libxl__build_pre, calling xc_domain_setmaxmem.
My guess is that a 64MB allocation would go over that limit.
You could try increasing the limit manually changing the
xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
videoram=3D64 in the VM config file.
</pre>
              </blockquote>
              <pre wrap=3D"">
Your guess is absolutely right!

But set videoram=3D128 or
xc_domain_setmaxmem(ctx-&gt;xch, domid, info-&gt;target_memkb +
LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);

Then I successfuly install qxl driver in win-hvm and QXL can work
properly.

I will send some patch to add qxl support to libxl.
</pre>
            </blockquote>
            <pre wrap=3D"">
I tried your 3 patches taken from the mailing list, it works but doesn't
solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
doesn't
start and on windows 7 I have heavy performance problem (unusable).
</pre>
          </blockquote>
          <pre wrap=3D"">
Could you find qxl vga card &nbsp;(named "Red Hat QXL GPU") in your
windows hvm's device manager to make sure your qxl is working?

My testing hvm-guest is Win XP.

I played "Harry Potter" in my LAN smoothly, qxl gives
great enhancement .

Although I don't test win7 and linux, I think it should work for them.
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">
I tried also with qemu 1.1.0 but nothing change.
</pre>
          </blockquote>
          <pre wrap=3D"">
I am not sure qemu 1.1.0 accept all the patches for xen.

Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git

It is build and installed by default, you should enable spice support.
spice can be enabled like below:

+++ b/tools/Makefile &nbsp; &nbsp;Sat May 26 12:31:01 2012 +0800
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
&nbsp; &nbsp; &nbsp; &nbsp; --bindir=3D$(LIBEXEC) \
&nbsp; &nbsp; &nbsp; &nbsp; --datadir=3D$(SHAREDIR)/qemu-xen \
&nbsp; &nbsp; &nbsp; &nbsp; --disable-kvm \
+ &nbsp; &nbsp; &nbsp; --enable-spice \

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">Does it work correctly for you? If so can I ha=
ve some detail of your
configurations please?
</pre>
          </blockquote>
          <pre wrap=3D"">
My vm.cfg:

name =3D 'xpPro_spice'
firmware_override =3D '/usr/lib/xen/boot/hvmloader'
builder =3D 'hvm'
memory =3D '1024'
device_model_version =3D 'qemu-xen'
device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
disk =3D [ '<a class=3D"moz-txt-link-freetext" href=3D"file:/path-to-img/=
xpPro.img,ioemu:hda,w">file:/path-to-img/xpPro.img,ioemu:hda,w</a>' ]
vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:97=
:CB:0E:7D']
sdl=3D0
vnc=3D0
vncviewer=3D0
serial =3D 'pty'
vcpus=3D1
usbdevice=3D'tablet'
#spice
spice=3D1
qxl=3D1
#qxlram=3D64
#qxlvram=3D64
spiceport=3D6000
spicehost=3D'192.168.1.187'
spicedisable_ticketing =3D 1
spiceagent_mouse =3D 0 # (1|0)

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">For audio support this is needed too: (tested =
and working)
-device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu
invocation and env QEMU_AUDIO_DRV=3Dspice
Can you add audio support on libxl please?
</pre>
          </blockquote>
          <pre wrap=3D"">
I think audio support can be considered after qxl accpted.
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">

</pre>
          </blockquote>
          <pre wrap=3D"">
</pre>
        </blockquote>
        <pre wrap=3D"">Thanks for reply, qxl driver is installed, windows=
 see qxl video card,
already compiled qemu with spice with patch I send months ago, already tr=
ied
git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
Unfortunately the results are always the same.
Here a quick recording:
Windows 7 test: <a class=3D"moz-txt-link-freetext" href=3D"http://fantu.i=
t/vari/spiceqxldebug1.mkv">http://fantu.it/vari/spiceqxldebug1.mkv</a>
</pre>
      </blockquote>
      <pre wrap=3D"">
oh...  it shows spice+qxl running on Xen get
significant performance reduction compared with KVM ...

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Debian wheezy test: <a class=3D"moz-txt-link-freet=
ext" href=3D"http://fantu.it/vari/spiceqxldebug2.mkv">http://fantu.it/var=
i/spiceqxldebug2.mkv</a>
Are not new but the result of the last test is the same.
I hope I can help you understand the problem.
If you need more information ask.
</pre>
      </blockquote>
      <pre wrap=3D"">
</pre>
    </blockquote>
    We are trying to reproduce your results but failed so far.<br>
    Can you give me details about the dom0 used for your tests please?<br=
>
    For example here are details about my testing dom0:<br>
    Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64
    version 3.2.18-1, package blktap-dkms and all dependency packages
    for xen 4.2, spice and usb redirection.
    <br>
    -------------------------
    <br>
    /etc/modules
    <br>
    ------------
    <br>
    loop max_loop=3D64
    <br>
    xenfs
    <br>
    xen-evtchn
    <br>
    blktap
    <br>
    -------------------------
    <br>
    hg clone <a href=3D"http://xenbits.xen.org/xen-unstable.hg"
      target=3D"_top" rel=3D"nofollow" link=3D"external">http://xenbits.x=
en.org/xen-unstable.hg</a>
    <br>
    vi config/StdGNU.mk # Workaround for Wheezy with multiarch support,
    there are parts that use LIBDIR set here instead of the one in
    configure (libdir)
    <br>
    LIBLEAFDIR_x86_64 ?=3D lib
    <br>
    vi Config.mk
    <br>
    PYTHON_PREFIX_ARG =3D
    <br>
    -------------------------
    <br>
    Added some patches:
    <br>
    - autoconf: add variable for pass arbitrary options to qemu upstream
    v3
    <br>
    - tools: Improve make deb
    <br>
    - libxc: do not "panic" if a kernel is not a bzImage.
    <br>
    - tools/hotplug/Linux/init.d/: added other xen kernel modules on
    xencommons start<br>
    - 3 patches for add qxl support<br>
    -------------------------
    <br>
    ./configure --enable-qemuu-spice --enable-qemuu-usbredir
    --enable-qemuu-debug
    <br>
    -------------------------
    <br>
    make deb<br>
    <br>
    Is qxl someway affected by physical video card of dom0?<br>
    Have you installed <a
href=3D"http://spice-space.org/download/binaries/spice-guest-tools-0.1.ex=
e">spice-guest-tools-0.1.exe</a>
    from spice site, if no what do you use for qxl driver?<br>
    Have you also installed gplpv driver or not?<br>
    Thanks for any reply.<br>
  </body>
</html>

--------------040604090805070908070808--

--------------ms080008050201020608020108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYxNDEzNTEwN1owIwYJKoZIhvcNAQkEMRYEFKkgXDXvPHgbRdgD6hRFJ1rO
yKYlMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBctkEOR5tWAr+2NQvHl3UfeEPSzk6C+Rh5x60wGnxk
IrBC7bT4XB870zssT3afr2swRWzv+nBsUXR0kIZCJ/xJFefqsxeTDqPuix/XpzuK6rDfYs8d
n0OfnRLniAH+hcAqiyKyfKI7eXlgvPTN9lf0tWXktIqrfMLwvpTRGJRFDemgOwdJqv0Dd6TK
IVEM3e7ixdsym3/D0R4JofD1V0bHKuxdrMtdQBkc6sXQSEi3e14kq1oup5MsWCaBH7XEhS9S
EfauBSGdfwCpaBb8pmwZvSSh64IhLtpQspKEcHKBKujM4OqEaIfOYZSpyMlJo9Z1QSVui0ha
UsHOsP/yL9iHAAAAAAAA
--------------ms080008050201020608020108--


--===============0808294309665709548==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0808294309665709548==--


From xen-devel-bounces@lists.xen.org Thu Jun 14 13:51:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 13:51: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 1SfASO-00015B-GX; Thu, 14 Jun 2012 13:51:28 +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 1SfASM-000156-E1
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:51:26 +0000
Received: from [85.158.143.35:14561] by server-2.bemta-4.messagelabs.com id
	1D/E5-17938-D5CE9DF4; Thu, 14 Jun 2012 13:51:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339681882!15074832!1
X-Originating-IP: [82.57.200.104]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27885 invoked from network); 14 Jun 2012 13:51:22 -0000
Received: from smtp208.alice.it (HELO smtp208.alice.it) (82.57.200.104)
	by server-13.tower-21.messagelabs.com with SMTP;
	14 Jun 2012 13:51:22 -0000
Received: from [192.168.178.50] (79.54.146.106) by smtp208.alice.it
	(8.6.023.02) id 4F056E851274EB5E; Thu, 14 Jun 2012 15:51:13 +0200
Message-ID: <4FD9EC4B.7090808@tiscali.it>
Date: Thu, 14 Jun 2012 15:51:07 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ZhouPeng <zpengxen@gmail.com>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
	<4FD85F83.3080207@tiscali.it>
	<CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
In-Reply-To: <CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
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="===============0808294309665709548=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============0808294309665709548==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080008050201020608020108"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms080008050201020608020108
Content-Type: multipart/alternative;
 boundary="------------040604090805070908070808"

This is a multi-part message in MIME format.
--------------040604090805070908070808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/06/2012 13:40, ZhouPeng ha scritto:
> On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni<fantonifabio@tiscali.it>=
  wrote:
>> Il 13/06/2012 11:02, ZhouPeng ha scritto:
>>
>>> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.i=
t>
>>>   wrote:
>>>> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>>>>
>>>>> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
>>>>> <stefano.stabellini@eu.citrix.com>      wrote:
>>>>>> On Thu, 24 May 2012, ZhouPeng wrote:
>>>>>>> Sorry for late reply, I am not on this mail these days because of=
 my
>>>>>>> work.
>>>>>>>
>>>>>>> I further test qxl-vga and I think I figure out the problem in so=
me
>>>>>>> extend.
>>>>>>>
>>>>>>> If using qxl device, the default memory size of vga is 64M.
>>>>>>> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>>>>>>>
>>>>>>> The exact reason is xc_domain_populate_physmap_exact fails, becau=
se
>>>>>>> xen-hypervisor
>>>>>>> fail,
>>>>>>> it's because of   alloc_domheap_pages(d, a->extent_order, a->memf=
lags)
>>>>>>> fails in hypervisor.
>>>>>>>
>>>>>>> I am not very familiar with xen's memory management, Does 64M exc=
eed
>>>>>>> xen's heap space in this context?
>>>>>> XL sets an upper bound of memory that can be allocated to the VM i=
n
>>>>>> libxl__build_pre, calling xc_domain_setmaxmem.
>>>>>> My guess is that a 64MB allocation would go over that limit.
>>>>>> You could try increasing the limit manually changing the
>>>>>> xc_domain_setmaxmem call in libxl__build_pre, or you could try set=
ting
>>>>>> videoram=3D64 in the VM config file.
>>>>> Your guess is absolutely right!
>>>>>
>>>>> But set videoram=3D128 or
>>>>> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
>>>>> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>>>>>
>>>>> Then I successfuly install qxl driver in win-hvm and QXL can work
>>>>> properly.
>>>>>
>>>>> I will send some patch to add qxl support to libxl.
>>>> I tried your 3 patches taken from the mailing list, it works but doe=
sn't
>>>> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
>>>> doesn't
>>>> start and on windows 7 I have heavy performance problem (unusable).
>>> Could you find qxl vga card  (named "Red Hat QXL GPU") in your
>>> windows hvm's device manager to make sure your qxl is working?
>>>
>>> My testing hvm-guest is Win XP.
>>>
>>> I played "Harry Potter" in my LAN smoothly, qxl gives
>>> great enhancement .
>>>
>>> Although I don't test win7 and linux, I think it should work for them=
=2E
>>>> I tried also with qemu 1.1.0 but nothing change.
>>> I am not sure qemu 1.1.0 accept all the patches for xen.
>>>
>>> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.=
git
>>>
>>> It is build and installed by default, you should enable spice support=
=2E
>>> spice can be enabled like below:
>>>
>>> +++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
>>> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
>>>          --bindir=3D$(LIBEXEC) \
>>>          --datadir=3D$(SHAREDIR)/qemu-xen \
>>>          --disable-kvm \
>>> +       --enable-spice \
>>>
>>>> Does it work correctly for you? If so can I have some detail of your=

>>>> configurations please?
>>> My vm.cfg:
>>>
>>> name =3D 'xpPro_spice'
>>> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
>>> builder =3D 'hvm'
>>> memory =3D '1024'
>>> device_model_version =3D 'qemu-xen'
>>> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
>>> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
>>> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:2=
1:97:CB:0E:7D']
>>> sdl=3D0
>>> vnc=3D0
>>> vncviewer=3D0
>>> serial =3D 'pty'
>>> vcpus=3D1
>>> usbdevice=3D'tablet'
>>> #spice
>>> spice=3D1
>>> qxl=3D1
>>> #qxlram=3D64
>>> #qxlvram=3D64
>>> spiceport=3D6000
>>> spicehost=3D'192.168.1.187'
>>> spicedisable_ticketing =3D 1
>>> spiceagent_mouse =3D 0 # (1|0)
>>>
>>>> For audio support this is needed too: (tested and working)
>>>> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 =
on qemu
>>>> invocation and env QEMU_AUDIO_DRV=3Dspice
>>>> Can you add audio support on libxl please?
>>> I think audio support can be considered after qxl accpted.
>>>>
>> Thanks for reply, qxl driver is installed, windows see qxl video card,=

>> already compiled qemu with spice with patch I send months ago, already=
 tried
>> git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
>> Unfortunately the results are always the same.
>> Here a quick recording:
>> Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv
> oh...  it shows spice+qxl running on Xen get
> significant performance reduction compared with KVM ...
>
>> Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
>> Are not new but the result of the last test is the same.
>> I hope I can help you understand the problem.
>> If you need more information ask.
We are trying to reproduce your results but failed so far.
Can you give me details about the dom0 used for your tests please?
For example here are details about my testing dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version =

3.2.18-1, package blktap-dkms and all dependency packages for xen 4.2,=20
spice and usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=3D64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg
vi config/StdGNU.mk # Workaround for Wheezy with multiarch support,=20
there are parts that use LIBDIR set here instead of the one in configure =

(libdir)
LIBLEAFDIR_x86_64 ?=3D lib
vi Config.mk
PYTHON_PREFIX_ARG =3D
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
- libxc: do not "panic" if a kernel is not a bzImage.
- tools/hotplug/Linux/init.d/: added other xen kernel modules on=20
xencommons start
- 3 patches for add qxl support
-------------------------
=2E/configure --enable-qemuu-spice --enable-qemuu-usbredir=20
--enable-qemuu-debug
-------------------------
make deb

Is qxl someway affected by physical video card of dom0?
Have you installed spice-guest-tools-0.1.exe=20
<http://spice-space.org/download/binaries/spice-guest-tools-0.1.exe>=20
from spice site, if no what do you use for qxl driver?
Have you also installed gplpv driver or not?
Thanks for any reply.

--------------040604090805070908070808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DISO-8859-1"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    Il 13/06/2012 13:40, ZhouPeng ha scritto:
    <blockquote
cite=3D"mid:CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmai=
l.com"
      type=3D"cite">
      <pre wrap=3D"">On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni <a cl=
ass=3D"moz-txt-link-rfc2396E" href=3D"mailto:fantonifabio@tiscali.it">&lt=
;fantonifabio@tiscali.it&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Il 13/06/2012 11:02, ZhouPeng ha scritto:

</pre>
        <blockquote type=3D"cite">
          <pre wrap=3D"">On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<a=
 class=3D"moz-txt-link-rfc2396E" href=3D"mailto:fantonifabio@tiscali.it">=
&lt;fantonifabio@tiscali.it&gt;</a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre wrap=3D"">&nbsp;wrote:
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">
Il 24/05/2012 13:28, ZhouPeng ha scritto:

</pre>
            <blockquote type=3D"cite">
              <pre wrap=3D"">On Thu, May 24, 2012 at 6:13 PM, Stefano Sta=
bellini
<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:stefano.stabellini@eu.c=
itrix.com">&lt;stefano.stabellini@eu.citrix.com&gt;</a> &nbsp; &nbsp;wrot=
e:
</pre>
              <blockquote type=3D"cite">
                <pre wrap=3D"">
On Thu, 24 May 2012, ZhouPeng wrote:
</pre>
                <blockquote type=3D"cite">
                  <pre wrap=3D"">
Sorry for late reply, I am not on this mail these days because of my
work.

I further test qxl-vga and I think I figure out the problem in some
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <blockquote type=3D"cite">
              <blockquote type=3D"cite">
                <blockquote type=3D"cite">
                  <pre wrap=3D"">extend.

If using qxl device, the default memory size of vga is 64M.
Which will cause xen_ram_alloc(qemu/xen-all.c) fails.

The exact reason is xc_domain_populate_physmap_exact fails, because
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <blockquote type=3D"cite">
              <blockquote type=3D"cite">
                <blockquote type=3D"cite">
                  <pre wrap=3D"">xen-hypervisor
fail,
it's because of &nbsp; alloc_domheap_pages(d, a-&gt;extent_order, a-&gt;m=
emflags)
fails in hypervisor.

I am not very familiar with xen's memory management, Does 64M exceed
xen's heap space in this context?
</pre>
                </blockquote>
                <pre wrap=3D"">
XL sets an upper bound of memory that can be allocated to the VM in
libxl__build_pre, calling xc_domain_setmaxmem.
My guess is that a 64MB allocation would go over that limit.
You could try increasing the limit manually changing the
xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
videoram=3D64 in the VM config file.
</pre>
              </blockquote>
              <pre wrap=3D"">
Your guess is absolutely right!

But set videoram=3D128 or
xc_domain_setmaxmem(ctx-&gt;xch, domid, info-&gt;target_memkb +
LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);

Then I successfuly install qxl driver in win-hvm and QXL can work
properly.

I will send some patch to add qxl support to libxl.
</pre>
            </blockquote>
            <pre wrap=3D"">
I tried your 3 patches taken from the mailing list, it works but doesn't
solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
doesn't
start and on windows 7 I have heavy performance problem (unusable).
</pre>
          </blockquote>
          <pre wrap=3D"">
Could you find qxl vga card &nbsp;(named "Red Hat QXL GPU") in your
windows hvm's device manager to make sure your qxl is working?

My testing hvm-guest is Win XP.

I played "Harry Potter" in my LAN smoothly, qxl gives
great enhancement .

Although I don't test win7 and linux, I think it should work for them.
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">
I tried also with qemu 1.1.0 but nothing change.
</pre>
          </blockquote>
          <pre wrap=3D"">
I am not sure qemu 1.1.0 accept all the patches for xen.

Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git

It is build and installed by default, you should enable spice support.
spice can be enabled like below:

+++ b/tools/Makefile &nbsp; &nbsp;Sat May 26 12:31:01 2012 +0800
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
&nbsp; &nbsp; &nbsp; &nbsp; --bindir=3D$(LIBEXEC) \
&nbsp; &nbsp; &nbsp; &nbsp; --datadir=3D$(SHAREDIR)/qemu-xen \
&nbsp; &nbsp; &nbsp; &nbsp; --disable-kvm \
+ &nbsp; &nbsp; &nbsp; --enable-spice \

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">Does it work correctly for you? If so can I ha=
ve some detail of your
configurations please?
</pre>
          </blockquote>
          <pre wrap=3D"">
My vm.cfg:

name =3D 'xpPro_spice'
firmware_override =3D '/usr/lib/xen/boot/hvmloader'
builder =3D 'hvm'
memory =3D '1024'
device_model_version =3D 'qemu-xen'
device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
disk =3D [ '<a class=3D"moz-txt-link-freetext" href=3D"file:/path-to-img/=
xpPro.img,ioemu:hda,w">file:/path-to-img/xpPro.img,ioemu:hda,w</a>' ]
vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:97=
:CB:0E:7D']
sdl=3D0
vnc=3D0
vncviewer=3D0
serial =3D 'pty'
vcpus=3D1
usbdevice=3D'tablet'
#spice
spice=3D1
qxl=3D1
#qxlram=3D64
#qxlvram=3D64
spiceport=3D6000
spicehost=3D'192.168.1.187'
spicedisable_ticketing =3D 1
spiceagent_mouse =3D 0 # (1|0)

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">For audio support this is needed too: (tested =
and working)
-device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu
invocation and env QEMU_AUDIO_DRV=3Dspice
Can you add audio support on libxl please?
</pre>
          </blockquote>
          <pre wrap=3D"">
I think audio support can be considered after qxl accpted.
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">

</pre>
          </blockquote>
          <pre wrap=3D"">
</pre>
        </blockquote>
        <pre wrap=3D"">Thanks for reply, qxl driver is installed, windows=
 see qxl video card,
already compiled qemu with spice with patch I send months ago, already tr=
ied
git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
Unfortunately the results are always the same.
Here a quick recording:
Windows 7 test: <a class=3D"moz-txt-link-freetext" href=3D"http://fantu.i=
t/vari/spiceqxldebug1.mkv">http://fantu.it/vari/spiceqxldebug1.mkv</a>
</pre>
      </blockquote>
      <pre wrap=3D"">
oh...  it shows spice+qxl running on Xen get
significant performance reduction compared with KVM ...

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Debian wheezy test: <a class=3D"moz-txt-link-freet=
ext" href=3D"http://fantu.it/vari/spiceqxldebug2.mkv">http://fantu.it/var=
i/spiceqxldebug2.mkv</a>
Are not new but the result of the last test is the same.
I hope I can help you understand the problem.
If you need more information ask.
</pre>
      </blockquote>
      <pre wrap=3D"">
</pre>
    </blockquote>
    We are trying to reproduce your results but failed so far.<br>
    Can you give me details about the dom0 used for your tests please?<br=
>
    For example here are details about my testing dom0:<br>
    Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64
    version 3.2.18-1, package blktap-dkms and all dependency packages
    for xen 4.2, spice and usb redirection.
    <br>
    -------------------------
    <br>
    /etc/modules
    <br>
    ------------
    <br>
    loop max_loop=3D64
    <br>
    xenfs
    <br>
    xen-evtchn
    <br>
    blktap
    <br>
    -------------------------
    <br>
    hg clone <a href=3D"http://xenbits.xen.org/xen-unstable.hg"
      target=3D"_top" rel=3D"nofollow" link=3D"external">http://xenbits.x=
en.org/xen-unstable.hg</a>
    <br>
    vi config/StdGNU.mk # Workaround for Wheezy with multiarch support,
    there are parts that use LIBDIR set here instead of the one in
    configure (libdir)
    <br>
    LIBLEAFDIR_x86_64 ?=3D lib
    <br>
    vi Config.mk
    <br>
    PYTHON_PREFIX_ARG =3D
    <br>
    -------------------------
    <br>
    Added some patches:
    <br>
    - autoconf: add variable for pass arbitrary options to qemu upstream
    v3
    <br>
    - tools: Improve make deb
    <br>
    - libxc: do not "panic" if a kernel is not a bzImage.
    <br>
    - tools/hotplug/Linux/init.d/: added other xen kernel modules on
    xencommons start<br>
    - 3 patches for add qxl support<br>
    -------------------------
    <br>
    ./configure --enable-qemuu-spice --enable-qemuu-usbredir
    --enable-qemuu-debug
    <br>
    -------------------------
    <br>
    make deb<br>
    <br>
    Is qxl someway affected by physical video card of dom0?<br>
    Have you installed <a
href=3D"http://spice-space.org/download/binaries/spice-guest-tools-0.1.ex=
e">spice-guest-tools-0.1.exe</a>
    from spice site, if no what do you use for qxl driver?<br>
    Have you also installed gplpv driver or not?<br>
    Thanks for any reply.<br>
  </body>
</html>

--------------040604090805070908070808--

--------------ms080008050201020608020108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYxNDEzNTEwN1owIwYJKoZIhvcNAQkEMRYEFKkgXDXvPHgbRdgD6hRFJ1rO
yKYlMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBctkEOR5tWAr+2NQvHl3UfeEPSzk6C+Rh5x60wGnxk
IrBC7bT4XB870zssT3afr2swRWzv+nBsUXR0kIZCJ/xJFefqsxeTDqPuix/XpzuK6rDfYs8d
n0OfnRLniAH+hcAqiyKyfKI7eXlgvPTN9lf0tWXktIqrfMLwvpTRGJRFDemgOwdJqv0Dd6TK
IVEM3e7ixdsym3/D0R4JofD1V0bHKuxdrMtdQBkc6sXQSEi3e14kq1oup5MsWCaBH7XEhS9S
EfauBSGdfwCpaBb8pmwZvSSh64IhLtpQspKEcHKBKujM4OqEaIfOYZSpyMlJo9Z1QSVui0ha
UsHOsP/yL9iHAAAAAAAA
--------------ms080008050201020608020108--


--===============0808294309665709548==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0808294309665709548==--


From xen-devel-bounces@lists.xen.org Thu Jun 14 14:01:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfAc5-0001Mf-OK; Thu, 14 Jun 2012 14:01:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfAc4-0001Ma-7R
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:01:28 +0000
Received: from [85.158.143.99:24617] by server-2.bemta-4.messagelabs.com id
	5D/B9-17938-7BEE9DF4; Thu, 14 Jun 2012 14:01:27 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339682485!17760419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18343 invoked from network); 14 Jun 2012 14:01:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:01:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13023597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:01:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 15:01:25 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfAc1-0006L8-8b;
	Thu, 14 Jun 2012 14:01:25 +0000
Received: by spongy (Postfix, from userid 2023)	id 4E8B034062B; Thu, 14 Jun
	2012 15:01:25 +0100 (BST)
Date: Thu, 14 Jun 2012 15:01:25 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120614140125.GA22025@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
	<CAFLBxZZ2G5zLe9ty1BXiGP5YGmUBSmqNP8OW4bpkY2euazLRhg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZ2G5zLe9ty1BXiGP5YGmUBSmqNP8OW4bpkY2euazLRhg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 01/06 02:24, George Dunlap wrote:
> On Fri, Jun 1, 2012 at 1:41 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
> >
> > Is there a particular reason this series got resent with no apparent
> > change (and also none mentioned in the description here or in the
> > individual patches)? All of the comments sent yesterday still apply,
> > and I continue to consider patches 1-4 as unnecessary/broken.
> 
> The date on the second set of e-mails is 15 minutes before the
> original series.  I presume this means that Jean sent the series but
> it got held up for some reason, so sent it again 15 minutes later; and
> the second series made it through but the first was held up until
> today.
> 
> Never attribute to malice that which can be attributed to computer error. :-)
> 

George is absolutely spot on, this is exactly what happen.

Sorry about that :(

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:01:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfAc5-0001Mf-OK; Thu, 14 Jun 2012 14:01:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfAc4-0001Ma-7R
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:01:28 +0000
Received: from [85.158.143.99:24617] by server-2.bemta-4.messagelabs.com id
	5D/B9-17938-7BEE9DF4; Thu, 14 Jun 2012 14:01:27 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1339682485!17760419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18343 invoked from network); 14 Jun 2012 14:01:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:01:26 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13023597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:01:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 15:01:25 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfAc1-0006L8-8b;
	Thu, 14 Jun 2012 14:01:25 +0000
Received: by spongy (Postfix, from userid 2023)	id 4E8B034062B; Thu, 14 Jun
	2012 15:01:25 +0100 (BST)
Date: Thu, 14 Jun 2012 15:01:25 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120614140125.GA22025@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<4FC8D4B30200007800087D1D@nat28.tlf.novell.com>
	<CAFLBxZZ2G5zLe9ty1BXiGP5YGmUBSmqNP8OW4bpkY2euazLRhg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZ2G5zLe9ty1BXiGP5YGmUBSmqNP8OW4bpkY2euazLRhg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 01/06 02:24, George Dunlap wrote:
> On Fri, Jun 1, 2012 at 1:41 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
> >
> > Is there a particular reason this series got resent with no apparent
> > change (and also none mentioned in the description here or in the
> > individual patches)? All of the comments sent yesterday still apply,
> > and I continue to consider patches 1-4 as unnecessary/broken.
> 
> The date on the second set of e-mails is 15 minutes before the
> original series.  I presume this means that Jean sent the series but
> it got held up for some reason, so sent it again 15 minutes later; and
> the second series made it through but the first was held up until
> today.
> 
> Never attribute to malice that which can be attributed to computer error. :-)
> 

George is absolutely spot on, this is exactly what happen.

Sorry about that :(

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfAig-0001bm-Jn; Thu, 14 Jun 2012 14:08:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfAif-0001bf-Ts
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:08:18 +0000
Received: from [85.158.139.83:64685] by server-1.bemta-5.messagelabs.com id
	D9/A6-19721-150F9DF4; Thu, 14 Jun 2012 14:08:17 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339682896!27972540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5596 invoked from network); 14 Jun 2012 14:08:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:08:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13023844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:08:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 15:08:16 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfAid-0006Nh-S2;
	Thu, 14 Jun 2012 14:08:15 +0000
Received: by spongy (Postfix, from userid 2023)	id E347B34062B; Thu, 14 Jun
	2012 15:08:15 +0100 (BST)
Date: Thu, 14 Jun 2012 15:08:15 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614140815.GB22025@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FC7AEBD020000780008774C@nat28.tlf.novell.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] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05 04:47, Jan Beulich wrote:
> >>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
> >--- a/xen/include/asm-x86/guest_access.h
> >+++ b/xen/include/asm-x86/guest_access.h
> >@@ -47,7 +47,7 @@
> > 
> > /* Cast a guest handle to the specified type of handle. */
> > #define guest_handle_cast(hnd, type) ({         \
> >-    type *_x = (hnd).p;                         \
> >+    type *_x = (type *)(hnd).p;                 \
> 
> 
> You would have to explain how this is safe: Without the cast, we
> get compiler warnings (and hence build failures due to -Werror)
> if "type *" and typeof((hnd).p) are incompatible. Adding an
> explicit cast removes that intentional check.
> 

I can't realy explain how this is safe because I agree it make
this function less safe.

Maybe I should put here the reason that led me to do something
like that. Here is what I'm trying to do:

        XEN_GUEST_HANDLE (uint8_t) slop_hnd =
                guest_handle_cast (pfn_list_hnd, uint8_t);
        guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
        pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);

I need to cast to uint8_t first to get the add_offset to behave
correctly. Maybe what I need would need a new macro that would
do those two operations.

What would be the proper way to doing something like this?

Thanks,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfAig-0001bm-Jn; Thu, 14 Jun 2012 14:08:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfAif-0001bf-Ts
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:08:18 +0000
Received: from [85.158.139.83:64685] by server-1.bemta-5.messagelabs.com id
	D9/A6-19721-150F9DF4; Thu, 14 Jun 2012 14:08:17 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1339682896!27972540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5596 invoked from network); 14 Jun 2012 14:08:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:08:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13023844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:08:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 15:08:16 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfAid-0006Nh-S2;
	Thu, 14 Jun 2012 14:08:15 +0000
Received: by spongy (Postfix, from userid 2023)	id E347B34062B; Thu, 14 Jun
	2012 15:08:15 +0100 (BST)
Date: Thu, 14 Jun 2012 15:08:15 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614140815.GB22025@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FC7AEBD020000780008774C@nat28.tlf.novell.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] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05 04:47, Jan Beulich wrote:
> >>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
> >--- a/xen/include/asm-x86/guest_access.h
> >+++ b/xen/include/asm-x86/guest_access.h
> >@@ -47,7 +47,7 @@
> > 
> > /* Cast a guest handle to the specified type of handle. */
> > #define guest_handle_cast(hnd, type) ({         \
> >-    type *_x = (hnd).p;                         \
> >+    type *_x = (type *)(hnd).p;                 \
> 
> 
> You would have to explain how this is safe: Without the cast, we
> get compiler warnings (and hence build failures due to -Werror)
> if "type *" and typeof((hnd).p) are incompatible. Adding an
> explicit cast removes that intentional check.
> 

I can't realy explain how this is safe because I agree it make
this function less safe.

Maybe I should put here the reason that led me to do something
like that. Here is what I'm trying to do:

        XEN_GUEST_HANDLE (uint8_t) slop_hnd =
                guest_handle_cast (pfn_list_hnd, uint8_t);
        guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
        pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);

I need to cast to uint8_t first to get the add_offset to behave
correctly. Maybe what I need would need a new macro that would
do those two operations.

What would be the proper way to doing something like this?

Thanks,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfArk-0001nB-Q1; Thu, 14 Jun 2012 14:17: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 1SfArj-0001n6-AZ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 14:17:39 +0000
Received: from [85.158.139.83:46277] by server-9.bemta-5.messagelabs.com id
	67/0E-01069-182F9DF4; Thu, 14 Jun 2012 14:17:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339683457!27611036!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12004 invoked from network); 14 Jun 2012 14:17:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 14:17:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 15:17:37 +0100
Message-Id: <4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 15:18:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
In-Reply-To: <4FD9D559.9050206@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.06.12 at 14:13, Wei Wang <wei.wang2@amd.com> wrote:
> Am 12.06.2012 18:43, schrieb Jan Beulich:
>> That is precisely what I suggested in my response to the first
>> version of this patch, and I'd also volunteer to look into putting
>> together a first draft implementation if we sort of agree that
>> this is the way to go.
> 
> Cool! thanks for doing that. Looking forward to it in Xen 4.2 since 
> iommu msi is really broken with recent Linux dom0...

That's unlikely to be for 4.2 - it's going to have a reasonable risk
of regressions, and functionality like that I don't think is nice to
rush into a feature frozen tree, the more that it provides a
workaround for the combination of questionable design and an
improper kernel side fix.

Have you at all considered getting this fixed on the kernel side?
As I don't have direct access to any AMD IOMMU capable
system - can one, other than by enumerating the respective
PCI IDs or reading ACPI tables, reasonably easily identify the
devices in question (e.g. via vendor/class/sub-class or some
such)? That might permit skipping those in the offending kernel
code...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfArk-0001nB-Q1; Thu, 14 Jun 2012 14:17: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 1SfArj-0001n6-AZ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 14:17:39 +0000
Received: from [85.158.139.83:46277] by server-9.bemta-5.messagelabs.com id
	67/0E-01069-182F9DF4; Thu, 14 Jun 2012 14:17:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339683457!27611036!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12004 invoked from network); 14 Jun 2012 14:17:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 14:17:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 15:17:37 +0100
Message-Id: <4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 15:18:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
In-Reply-To: <4FD9D559.9050206@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.06.12 at 14:13, Wei Wang <wei.wang2@amd.com> wrote:
> Am 12.06.2012 18:43, schrieb Jan Beulich:
>> That is precisely what I suggested in my response to the first
>> version of this patch, and I'd also volunteer to look into putting
>> together a first draft implementation if we sort of agree that
>> this is the way to go.
> 
> Cool! thanks for doing that. Looking forward to it in Xen 4.2 since 
> iommu msi is really broken with recent Linux dom0...

That's unlikely to be for 4.2 - it's going to have a reasonable risk
of regressions, and functionality like that I don't think is nice to
rush into a feature frozen tree, the more that it provides a
workaround for the combination of questionable design and an
improper kernel side fix.

Have you at all considered getting this fixed on the kernel side?
As I don't have direct access to any AMD IOMMU capable
system - can one, other than by enumerating the respective
PCI IDs or reading ACPI tables, reasonably easily identify the
devices in question (e.g. via vendor/class/sub-class or some
such)? That might permit skipping those in the offending kernel
code...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:23:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfAwe-0001vG-IL; Thu, 14 Jun 2012 14:22: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 1SfAwc-0001vA-D5
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:22:42 +0000
Received: from [85.158.139.83:41756] by server-2.bemta-5.messagelabs.com id
	A0/76-04598-1B3F9DF4; Thu, 14 Jun 2012 14:22:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339683760!20352806!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31044 invoked from network); 14 Jun 2012 14:22:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 14:22:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 15:22:41 +0100
Message-Id: <4FDA0FFB0200007800089FFE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 15:23:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
In-Reply-To: <20120614140815.GB22025@spongy>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:08, Jean Guyader <jean.guyader@citrix.com> wrote:
> On 31/05 04:47, Jan Beulich wrote:
>> >>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
>> >--- a/xen/include/asm-x86/guest_access.h
>> >+++ b/xen/include/asm-x86/guest_access.h
>> >@@ -47,7 +47,7 @@
>> > 
>> > /* Cast a guest handle to the specified type of handle. */
>> > #define guest_handle_cast(hnd, type) ({         \
>> >-    type *_x = (hnd).p;                         \
>> >+    type *_x = (type *)(hnd).p;                 \
>> 
>> 
>> You would have to explain how this is safe: Without the cast, we
>> get compiler warnings (and hence build failures due to -Werror)
>> if "type *" and typeof((hnd).p) are incompatible. Adding an
>> explicit cast removes that intentional check.
>> 
> 
> I can't realy explain how this is safe because I agree it make
> this function less safe.
> 
> Maybe I should put here the reason that led me to do something
> like that. Here is what I'm trying to do:
> 
>         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>                 guest_handle_cast (pfn_list_hnd, uint8_t);
>         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
>         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> 
> I need to cast to uint8_t first to get the add_offset to behave
> correctly. Maybe what I need would need a new macro that would
> do those two operations.
> 
> What would be the proper way to doing something like this?

Depends on what pfn_list_hnd's type is. Maybe going through
XEN_GUEST_HANDLE(void) would do (perhaps you could even
replace uint8_t with void in your code above, making use of
gcc's extension allowing void pointer arithmetic).

If that doesn't help, maybe you could post a complete example,
compilable with your modification, and I could look into making
this work with what is there already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:23:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfAwe-0001vG-IL; Thu, 14 Jun 2012 14:22: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 1SfAwc-0001vA-D5
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:22:42 +0000
Received: from [85.158.139.83:41756] by server-2.bemta-5.messagelabs.com id
	A0/76-04598-1B3F9DF4; Thu, 14 Jun 2012 14:22:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1339683760!20352806!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31044 invoked from network); 14 Jun 2012 14:22:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 14:22:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 15:22:41 +0100
Message-Id: <4FDA0FFB0200007800089FFE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 15:23:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
In-Reply-To: <20120614140815.GB22025@spongy>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:08, Jean Guyader <jean.guyader@citrix.com> wrote:
> On 31/05 04:47, Jan Beulich wrote:
>> >>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
>> >--- a/xen/include/asm-x86/guest_access.h
>> >+++ b/xen/include/asm-x86/guest_access.h
>> >@@ -47,7 +47,7 @@
>> > 
>> > /* Cast a guest handle to the specified type of handle. */
>> > #define guest_handle_cast(hnd, type) ({         \
>> >-    type *_x = (hnd).p;                         \
>> >+    type *_x = (type *)(hnd).p;                 \
>> 
>> 
>> You would have to explain how this is safe: Without the cast, we
>> get compiler warnings (and hence build failures due to -Werror)
>> if "type *" and typeof((hnd).p) are incompatible. Adding an
>> explicit cast removes that intentional check.
>> 
> 
> I can't realy explain how this is safe because I agree it make
> this function less safe.
> 
> Maybe I should put here the reason that led me to do something
> like that. Here is what I'm trying to do:
> 
>         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>                 guest_handle_cast (pfn_list_hnd, uint8_t);
>         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
>         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> 
> I need to cast to uint8_t first to get the add_offset to behave
> correctly. Maybe what I need would need a new macro that would
> do those two operations.
> 
> What would be the proper way to doing something like this?

Depends on what pfn_list_hnd's type is. Maybe going through
XEN_GUEST_HANDLE(void) would do (perhaps you could even
replace uint8_t with void in your code above, making use of
gcc's extension allowing void pointer arithmetic).

If that doesn't help, maybe you could post a complete example,
compilable with your modification, and I could look into making
this work with what is there already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:26:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfB09-00022T-6M; Thu, 14 Jun 2012 14:26:21 +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 1SfB07-00022M-UX
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:26:20 +0000
Received: from [85.158.138.51:14805] by server-7.bemta-3.messagelabs.com id
	67/47-10113-A84F9DF4; Thu, 14 Jun 2012 14:26:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339683978!27747800!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29637 invoked from network); 14 Jun 2012 14:26:18 -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 Jun 2012 14:26:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfB02-0000KY-A2; Thu, 14 Jun 2012 14:26:14 +0000
Date: Thu, 14 Jun 2012 15:26:14 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614142614.GE90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614140815.GB22025@spongy>
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 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> On 31/05 04:47, Jan Beulich wrote:
> > >>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
> > >--- a/xen/include/asm-x86/guest_access.h
> > >+++ b/xen/include/asm-x86/guest_access.h
> > >@@ -47,7 +47,7 @@
> > > 
> > > /* Cast a guest handle to the specified type of handle. */
> > > #define guest_handle_cast(hnd, type) ({         \
> > >-    type *_x = (hnd).p;                         \
> > >+    type *_x = (type *)(hnd).p;                 \
> > 
> > 
> > You would have to explain how this is safe: Without the cast, we
> > get compiler warnings (and hence build failures due to -Werror)
> > if "type *" and typeof((hnd).p) are incompatible. Adding an
> > explicit cast removes that intentional check.
> > 
> 
> I can't realy explain how this is safe because I agree it make
> this function less safe.
> 
> Maybe I should put here the reason that led me to do something
> like that. Here is what I'm trying to do:
> 
>         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>                 guest_handle_cast (pfn_list_hnd, uint8_t);
>         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
>         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> 
> I need to cast to uint8_t first to get the add_offset to behave
> correctly. Maybe what I need would need a new macro that would
> do those two operations.
> 
> What would be the proper way to doing something like this?

You could avoid it altogether by dropping struct v4v_ring_data, and
passing a v4v_pfn_t array directly with the 'npage' as a separate
hypercall argument.  AFAICS struct v4v_ring_data has no other useful
fields.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:26:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfB09-00022T-6M; Thu, 14 Jun 2012 14:26:21 +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 1SfB07-00022M-UX
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:26:20 +0000
Received: from [85.158.138.51:14805] by server-7.bemta-3.messagelabs.com id
	67/47-10113-A84F9DF4; Thu, 14 Jun 2012 14:26:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1339683978!27747800!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29637 invoked from network); 14 Jun 2012 14:26:18 -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 Jun 2012 14:26:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfB02-0000KY-A2; Thu, 14 Jun 2012 14:26:14 +0000
Date: Thu, 14 Jun 2012 15:26:14 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614142614.GE90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614140815.GB22025@spongy>
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 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> On 31/05 04:47, Jan Beulich wrote:
> > >>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@citrix.com> wrote:
> > >--- a/xen/include/asm-x86/guest_access.h
> > >+++ b/xen/include/asm-x86/guest_access.h
> > >@@ -47,7 +47,7 @@
> > > 
> > > /* Cast a guest handle to the specified type of handle. */
> > > #define guest_handle_cast(hnd, type) ({         \
> > >-    type *_x = (hnd).p;                         \
> > >+    type *_x = (type *)(hnd).p;                 \
> > 
> > 
> > You would have to explain how this is safe: Without the cast, we
> > get compiler warnings (and hence build failures due to -Werror)
> > if "type *" and typeof((hnd).p) are incompatible. Adding an
> > explicit cast removes that intentional check.
> > 
> 
> I can't realy explain how this is safe because I agree it make
> this function less safe.
> 
> Maybe I should put here the reason that led me to do something
> like that. Here is what I'm trying to do:
> 
>         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>                 guest_handle_cast (pfn_list_hnd, uint8_t);
>         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
>         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> 
> I need to cast to uint8_t first to get the add_offset to behave
> correctly. Maybe what I need would need a new macro that would
> do those two operations.
> 
> What would be the proper way to doing something like this?

You could avoid it altogether by dropping struct v4v_ring_data, and
passing a v4v_pfn_t array directly with the 'npage' as a separate
hypercall argument.  AFAICS struct v4v_ring_data has no other useful
fields.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:28:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:28: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 1SfB1f-00028I-MU; Thu, 14 Jun 2012 14:27: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 1SfB1e-00028B-It
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:27:54 +0000
Received: from [85.158.143.35:22679] by server-3.bemta-4.messagelabs.com id
	59/7C-05808-9E4F9DF4; Thu, 14 Jun 2012 14:27:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339684073!5289066!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19038 invoked from network); 14 Jun 2012 14:27:53 -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 Jun 2012 14:27:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfB1b-0000Ls-3s; Thu, 14 Jun 2012 14:27:51 +0000
Date: Thu, 14 Jun 2012 15:27:51 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614142751.GF90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614142614.GE90181@ocelot.phlegethon.org>
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 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > Maybe I should put here the reason that led me to do something
> > like that. Here is what I'm trying to do:
> > 
> >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > 
> > I need to cast to uint8_t first to get the add_offset to behave
> > correctly. Maybe what I need would need a new macro that would
> > do those two operations.
> > 
> > What would be the proper way to doing something like this?
> 
> You could avoid it altogether by dropping struct v4v_ring_data, and
> passing a v4v_pfn_t array directly with the 'npage' as a separate
> hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> fields.

Excuse me, I meant struct v4v_pfn_list_t.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:28:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:28: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 1SfB1f-00028I-MU; Thu, 14 Jun 2012 14:27: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 1SfB1e-00028B-It
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:27:54 +0000
Received: from [85.158.143.35:22679] by server-3.bemta-4.messagelabs.com id
	59/7C-05808-9E4F9DF4; Thu, 14 Jun 2012 14:27:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339684073!5289066!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19038 invoked from network); 14 Jun 2012 14:27:53 -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 Jun 2012 14:27:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfB1b-0000Ls-3s; Thu, 14 Jun 2012 14:27:51 +0000
Date: Thu, 14 Jun 2012 15:27:51 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614142751.GF90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614142614.GE90181@ocelot.phlegethon.org>
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 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > Maybe I should put here the reason that led me to do something
> > like that. Here is what I'm trying to do:
> > 
> >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > 
> > I need to cast to uint8_t first to get the add_offset to behave
> > correctly. Maybe what I need would need a new macro that would
> > do those two operations.
> > 
> > What would be the proper way to doing something like this?
> 
> You could avoid it altogether by dropping struct v4v_ring_data, and
> passing a v4v_pfn_t array directly with the 'npage' as a separate
> hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> fields.

Excuse me, I meant struct v4v_pfn_list_t.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfB4s-0002Ji-9W; Thu, 14 Jun 2012 14:31:14 +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 1SfB4r-0002Jb-0E
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:31:13 +0000
Received: from [85.158.143.35:42822] by server-1.bemta-4.messagelabs.com id
	72/6E-24392-0B5F9DF4; Thu, 14 Jun 2012 14:31:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339684267!5898058!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31251 invoked from network); 14 Jun 2012 14:31:09 -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 Jun 2012 14:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28086556"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:31:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 10:31:06 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SfB0Y-0001QA-LF;
	Thu, 14 Jun 2012 15:26:46 +0100
Message-ID: <4FD9F42E.2060707@eu.citrix.com>
Date: Thu, 14 Jun 2012 15:24:46 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
	<4FD205E80200007800088C36@nat28.tlf.novell.com>
	<20120614090725.GC82539@ocelot.phlegethon.org>
In-Reply-To: <20120614090725.GC82539@ocelot.phlegethon.org>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 14/06/12 10:07, Tim Deegan wrote:
>
>
> At 13:02 +0100 on 08 Jun (1339160536), Jan Beulich wrote:
>>>>> On 08.06.12 at 13:45, George Dunlap<george.dunlap@eu.citrix.com>  wrote:
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -287,6 +287,9 @@ struct p2m_domain {
>>>           unsigned         reclaim_super; /* Last gpfn of a scan */
>>>           unsigned         reclaim_single; /* Last gpfn of a scan */
>>>           unsigned         max_guest;    /* gpfn of max guest demand-populate */
>>> +#define POD_HISTORY_MAX 128
>>> +        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */
> This is the gpfns of the last 128 order-9 superpages populated, right?
Ah, yes -- just order 9.
> Also, this line is>80 columns - I think I saw a few others in this series.
I'll go through and check, thanks.
>
>> unsigned long?
>>
>> Also, wouldn't it be better to allocate this table dynamically, at
>> once allowing its size to scale with the number of vCPU-s in the
>> guest?
> You could even make it a small per-vcpu array, assuming that the parallel
> scrubbing will be symmetric across vcpus.
I can't remember exactly what I found here (this was last summer I was 
doing the tests); it may be that Windows creates a bunch of tasks which 
may migrate to various cpus.  If that were the case, a global list would 
be better than per-vcpu lists.

The problem with dynamically scaling the list is that I don't have a 
heuristic to hand for how to scale it.

In both cases, it's not unlikely that making a change without testing 
will significantly reduce the effectiveness of the patch.  Would you 
rather hold off and wait until I can get a chance to run my benchmarks 
again (which may miss the 4.2 cycle), or accept a tidied-up version of 
this patch first, and hope to get a revised method (using dynamic 
scaling or per-vcpu arrays) in before 4.2, but for sure by 4.3?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfB4s-0002Ji-9W; Thu, 14 Jun 2012 14:31:14 +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 1SfB4r-0002Jb-0E
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:31:13 +0000
Received: from [85.158.143.35:42822] by server-1.bemta-4.messagelabs.com id
	72/6E-24392-0B5F9DF4; Thu, 14 Jun 2012 14:31:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339684267!5898058!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31251 invoked from network); 14 Jun 2012 14:31:09 -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 Jun 2012 14:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28086556"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:31:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 10:31:06 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SfB0Y-0001QA-LF;
	Thu, 14 Jun 2012 15:26:46 +0100
Message-ID: <4FD9F42E.2060707@eu.citrix.com>
Date: Thu, 14 Jun 2012 15:24:46 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
	<4FD205E80200007800088C36@nat28.tlf.novell.com>
	<20120614090725.GC82539@ocelot.phlegethon.org>
In-Reply-To: <20120614090725.GC82539@ocelot.phlegethon.org>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 14/06/12 10:07, Tim Deegan wrote:
>
>
> At 13:02 +0100 on 08 Jun (1339160536), Jan Beulich wrote:
>>>>> On 08.06.12 at 13:45, George Dunlap<george.dunlap@eu.citrix.com>  wrote:
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -287,6 +287,9 @@ struct p2m_domain {
>>>           unsigned         reclaim_super; /* Last gpfn of a scan */
>>>           unsigned         reclaim_single; /* Last gpfn of a scan */
>>>           unsigned         max_guest;    /* gpfn of max guest demand-populate */
>>> +#define POD_HISTORY_MAX 128
>>> +        unsigned         last_populated[POD_HISTORY_MAX]; /* gpfn of last guest page demand-populated */
> This is the gpfns of the last 128 order-9 superpages populated, right?
Ah, yes -- just order 9.
> Also, this line is>80 columns - I think I saw a few others in this series.
I'll go through and check, thanks.
>
>> unsigned long?
>>
>> Also, wouldn't it be better to allocate this table dynamically, at
>> once allowing its size to scale with the number of vCPU-s in the
>> guest?
> You could even make it a small per-vcpu array, assuming that the parallel
> scrubbing will be symmetric across vcpus.
I can't remember exactly what I found here (this was last summer I was 
doing the tests); it may be that Windows creates a bunch of tasks which 
may migrate to various cpus.  If that were the case, a global list would 
be better than per-vcpu lists.

The problem with dynamically scaling the list is that I don't have a 
heuristic to hand for how to scale it.

In both cases, it's not unlikely that making a change without testing 
will significantly reduce the effectiveness of the patch.  Would you 
rather hold off and wait until I can get a chance to run my benchmarks 
again (which may miss the 4.2 cycle), or accept a tidied-up version of 
this patch first, and hope to get a revised method (using dynamic 
scaling or per-vcpu arrays) in before 4.2, but for sure by 4.3?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:39:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:39: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 1SfBCj-0002Vp-9a; Thu, 14 Jun 2012 14:39:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfBCh-0002Vi-Uu
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:39:20 +0000
Received: from [85.158.139.83:36740] by server-11.bemta-5.messagelabs.com id
	10/08-20400-797F9DF4; Thu, 14 Jun 2012 14:39:19 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339684756!27616176!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19696 invoked from network); 14 Jun 2012 14:39:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:39:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198762086"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:39:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 10:39:05 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfBCT-000220-FC;
	Thu, 14 Jun 2012 15:39:05 +0100
Message-ID: <4FD9F789.5070300@citrix.com>
Date: Thu, 14 Jun 2012 15:39:05 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com>
In-Reply-To: <4FD88C0D.10304@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 13/06/12 13:48, Jan Kiszka wrote:
>>> >>  Will you be able to use an address parser via some device property?
>> >
>> >  Yes. Actually, the address is already a device property.
>> >
> Great. Then we should try to come up with a common pci-host-devaddr
> property everyone can use.

Is this patch would be a good common property?

It's probably close to the patch you send earlier Jan.

If it's good, I'll resend my passthrough patch series with this patch.


diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index b7b5597..9c7a271 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
      .max   = 65024,
  };

+/* --- pci host address --- */
+
+static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    char buffer[4 + 2 + 2 + 2 + 1];
+    char *p = buffer;
+
+    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
+             addr->domain, addr->bus, addr->slot, addr->function);
+
+    visit_type_str(v, &p, name, errp);
+}
+
+/*
+ * Parse [<domain>:]<bus>:<slot>.<func>
+ *   if <domain> is not supplied, it's assumed to be 0.
+ */
+static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    Error *local_err = NULL;
+    char *str, *p;
+    char *e;
+    unsigned long val;
+    unsigned long dom = 0, bus = 0;
+    unsigned int slot = 0, func = 0;
+
+    if (dev->state != DEV_STATE_CREATED) {
+        error_set(errp, QERR_PERMISSION_DENIED);
+        return;
+    }
+
+    visit_type_str(v, &str, name, &local_err);
+    if (local_err) {
+        error_propagate(errp, local_err);
+        return;
+    }
+
+    p = str;
+    val = strtoul(p, &e, 16);
+    if (e == p || *e != ':')
+        goto inval;
+    bus = val;
+
+    p = e + 1;
+    val = strtoul(p, &e, 16);
+    if (e == p)
+        goto inval;
+    if (*e == ':') {
+        dom = bus;
+        bus = val;
+        p = e + 1;
+        val = strtoul(p, &e, 16);
+        if (e == p)
+            goto inval;
+    }
+    slot = val;
+
+    if (*e != '.')
+        goto inval;
+    p = e + 1;
+    val = strtoul(p, &e, 10);
+    if (e == p)
+        goto inval;
+    func = val;
+
+    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7)
+        goto inval;
+
+    if (*e)
+        goto inval;
+
+    addr->domain = dom;
+    addr->bus = bus;
+    addr->slot = slot;
+    addr->function = func;
+
+    g_free(str);
+    return;
+
+inval:
+    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+    g_free(str);
+}
+
+PropertyInfo qdev_prop_pci_host_devaddr = {
+    .name = "pci-host-devaddr",
+    .get = get_pci_host_devaddr,
+    .set = set_pci_host_devaddr,
+};
+
  /* --- public helpers --- */

  static Property *qdev_prop_walk(Property *props, const char *name)
diff --git a/hw/qdev.h b/hw/qdev.h
index 4e90119..9a54ebe 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -225,6 +225,7 @@ extern PropertyInfo qdev_prop_netdev;
  extern PropertyInfo qdev_prop_vlan;
  extern PropertyInfo qdev_prop_pci_devfn;
  extern PropertyInfo qdev_prop_blocksize;
+extern PropertyInfo qdev_prop_pci_host_devaddr;

  #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
          .name      = (_name),                                    \
@@ -288,6 +289,8 @@ extern PropertyInfo qdev_prop_blocksize;
                          LostTickPolicy)
  #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
      DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
+#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
+    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, 
PCIHostDeviceAddress)

  #define DEFINE_PROP_END_OF_LIST()               \
      {}
diff --git a/qemu-common.h b/qemu-common.h
index 91e0562..0d6e51c 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
      LOST_TICK_MAX
  } LostTickPolicy;

+typedef struct PCIHostDeviceAddress {
+    unsigned int domain;
+    unsigned int bus;
+    unsigned int slot;
+    unsigned int function;
+} PCIHostDeviceAddress;
+
  void tcg_exec_init(unsigned long tb_size);
  bool tcg_enabled(void);


-- 
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 Jun 14 14:39:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14:39: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 1SfBCj-0002Vp-9a; Thu, 14 Jun 2012 14:39:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfBCh-0002Vi-Uu
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:39:20 +0000
Received: from [85.158.139.83:36740] by server-11.bemta-5.messagelabs.com id
	10/08-20400-797F9DF4; Thu, 14 Jun 2012 14:39:19 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339684756!27616176!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19696 invoked from network); 14 Jun 2012 14:39:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:39:18 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198762086"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:39:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 10:39:05 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfBCT-000220-FC;
	Thu, 14 Jun 2012 15:39:05 +0100
Message-ID: <4FD9F789.5070300@citrix.com>
Date: Thu, 14 Jun 2012 15:39:05 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com>
In-Reply-To: <4FD88C0D.10304@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Xen Devel <xen-devel@lists.xen.org>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 13/06/12 13:48, Jan Kiszka wrote:
>>> >>  Will you be able to use an address parser via some device property?
>> >
>> >  Yes. Actually, the address is already a device property.
>> >
> Great. Then we should try to come up with a common pci-host-devaddr
> property everyone can use.

Is this patch would be a good common property?

It's probably close to the patch you send earlier Jan.

If it's good, I'll resend my passthrough patch series with this patch.


diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index b7b5597..9c7a271 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
      .max   = 65024,
  };

+/* --- pci host address --- */
+
+static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    char buffer[4 + 2 + 2 + 2 + 1];
+    char *p = buffer;
+
+    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
+             addr->domain, addr->bus, addr->slot, addr->function);
+
+    visit_type_str(v, &p, name, errp);
+}
+
+/*
+ * Parse [<domain>:]<bus>:<slot>.<func>
+ *   if <domain> is not supplied, it's assumed to be 0.
+ */
+static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    Error *local_err = NULL;
+    char *str, *p;
+    char *e;
+    unsigned long val;
+    unsigned long dom = 0, bus = 0;
+    unsigned int slot = 0, func = 0;
+
+    if (dev->state != DEV_STATE_CREATED) {
+        error_set(errp, QERR_PERMISSION_DENIED);
+        return;
+    }
+
+    visit_type_str(v, &str, name, &local_err);
+    if (local_err) {
+        error_propagate(errp, local_err);
+        return;
+    }
+
+    p = str;
+    val = strtoul(p, &e, 16);
+    if (e == p || *e != ':')
+        goto inval;
+    bus = val;
+
+    p = e + 1;
+    val = strtoul(p, &e, 16);
+    if (e == p)
+        goto inval;
+    if (*e == ':') {
+        dom = bus;
+        bus = val;
+        p = e + 1;
+        val = strtoul(p, &e, 16);
+        if (e == p)
+            goto inval;
+    }
+    slot = val;
+
+    if (*e != '.')
+        goto inval;
+    p = e + 1;
+    val = strtoul(p, &e, 10);
+    if (e == p)
+        goto inval;
+    func = val;
+
+    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7)
+        goto inval;
+
+    if (*e)
+        goto inval;
+
+    addr->domain = dom;
+    addr->bus = bus;
+    addr->slot = slot;
+    addr->function = func;
+
+    g_free(str);
+    return;
+
+inval:
+    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+    g_free(str);
+}
+
+PropertyInfo qdev_prop_pci_host_devaddr = {
+    .name = "pci-host-devaddr",
+    .get = get_pci_host_devaddr,
+    .set = set_pci_host_devaddr,
+};
+
  /* --- public helpers --- */

  static Property *qdev_prop_walk(Property *props, const char *name)
diff --git a/hw/qdev.h b/hw/qdev.h
index 4e90119..9a54ebe 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -225,6 +225,7 @@ extern PropertyInfo qdev_prop_netdev;
  extern PropertyInfo qdev_prop_vlan;
  extern PropertyInfo qdev_prop_pci_devfn;
  extern PropertyInfo qdev_prop_blocksize;
+extern PropertyInfo qdev_prop_pci_host_devaddr;

  #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
          .name      = (_name),                                    \
@@ -288,6 +289,8 @@ extern PropertyInfo qdev_prop_blocksize;
                          LostTickPolicy)
  #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
      DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
+#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
+    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, 
PCIHostDeviceAddress)

  #define DEFINE_PROP_END_OF_LIST()               \
      {}
diff --git a/qemu-common.h b/qemu-common.h
index 91e0562..0d6e51c 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
      LOST_TICK_MAX
  } LostTickPolicy;

+typedef struct PCIHostDeviceAddress {
+    unsigned int domain;
+    unsigned int bus;
+    unsigned int slot;
+    unsigned int function;
+} PCIHostDeviceAddress;
+
  void tcg_exec_init(unsigned long tb_size);
  bool tcg_enabled(void);


-- 
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 Jun 14 14:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfBDY-0002bi-N7; Thu, 14 Jun 2012 14:40:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfBDX-0002ZK-JG
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:40:11 +0000
Received: from [85.158.143.35:40259] by server-2.bemta-4.messagelabs.com id
	8F/C0-17938-BC7F9DF4; Thu, 14 Jun 2012 14:40:11 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339684809!4436241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11043 invoked from network); 14 Jun 2012 14:40:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13025510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:40:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 15:40:09 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfBDU-0006ZS-P4;
	Thu, 14 Jun 2012 14:40:08 +0000
Received: by spongy (Postfix, from userid 2023)	id D48BA34062B; Thu, 14 Jun
	2012 15:40:08 +0100 (BST)
Date: Thu, 14 Jun 2012 15:40:08 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120614144008.GA24063@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614142751.GF90181@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06 03:27, Tim Deegan wrote:
> At 15:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> > At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > > Maybe I should put here the reason that led me to do something
> > > like that. Here is what I'm trying to do:
> > > 
> > >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> > >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> > >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> > >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > > 
> > > I need to cast to uint8_t first to get the add_offset to behave
> > > correctly. Maybe what I need would need a new macro that would
> > > do those two operations.
> > > 
> > > What would be the proper way to doing something like this?
> > 
> > You could avoid it altogether by dropping struct v4v_ring_data, and
> > passing a v4v_pfn_t array directly with the 'npage' as a separate
> > hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> > fields.
> 
> Excuse me, I meant struct v4v_pfn_list_t.
> 

You probably mean both, because we doing the same thing with
v4v_ring_data_t and v4v_ring_data_ent_t.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfBDY-0002bi-N7; Thu, 14 Jun 2012 14:40:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfBDX-0002ZK-JG
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:40:11 +0000
Received: from [85.158.143.35:40259] by server-2.bemta-4.messagelabs.com id
	8F/C0-17938-BC7F9DF4; Thu, 14 Jun 2012 14:40:11 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339684809!4436241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11043 invoked from network); 14 Jun 2012 14:40:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 14:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13025510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:40:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 15:40:09 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfBDU-0006ZS-P4;
	Thu, 14 Jun 2012 14:40:08 +0000
Received: by spongy (Postfix, from userid 2023)	id D48BA34062B; Thu, 14 Jun
	2012 15:40:08 +0100 (BST)
Date: Thu, 14 Jun 2012 15:40:08 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120614144008.GA24063@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614142751.GF90181@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06 03:27, Tim Deegan wrote:
> At 15:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> > At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > > Maybe I should put here the reason that led me to do something
> > > like that. Here is what I'm trying to do:
> > > 
> > >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> > >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> > >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> > >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > > 
> > > I need to cast to uint8_t first to get the add_offset to behave
> > > correctly. Maybe what I need would need a new macro that would
> > > do those two operations.
> > > 
> > > What would be the proper way to doing something like this?
> > 
> > You could avoid it altogether by dropping struct v4v_ring_data, and
> > passing a v4v_pfn_t array directly with the 'npage' as a separate
> > hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> > fields.
> 
> Excuse me, I meant struct v4v_pfn_list_t.
> 

You probably mean both, because we doing the same thing with
v4v_ring_data_t and v4v_ring_data_ent_t.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:52:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfBPT-0003CN-Qw; Thu, 14 Jun 2012 14:52:31 +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 1SfBPS-0003CE-BQ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 14:52:30 +0000
Received: from [85.158.138.51:46445] by server-5.bemta-3.messagelabs.com id
	48/9D-01572-8AAF9DF4; Thu, 14 Jun 2012 14:52:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339685541!27675693!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29116 invoked from network); 14 Jun 2012 14:52:23 -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;
	14 Jun 2012 14:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28090039"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:52:21 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	10:52:20 -0400
Message-ID: <4FD9FAA3.6090303@citrix.com>
Date: Thu, 14 Jun 2012 15:52:19 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "H. Peter
	Anvin" <hpa@zytor.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if
 they haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 18:01, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> When switching tasks in a Xen PV guest, avoid updating the TLS
> descriptors if they haven't changed.  This improves the speed of
> context switches by almost 10% as much of the time the descriptors are
> the same or only one is different.
> 
> The descriptors written into the GDT by Xen are modified from the
> values passed in the update_descriptor hypercall so we keep shadow
> copies of the three TLS descriptors to compare against.
> 
> lmbench3 test     Before  After  Improvement
> --------------------------------------------
> lat_ctx -s 32 24   7.19    6.52  9%
> lat_pipe          12.56   11.66  7%
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
> in desc_struct as deprecated but there seems to be no suitable
> alternatives.

ping?  Any opinion on this patch from the x86 side?  If it's okay can we
get an ack so Konrad can take the patch via his tree.

Thanks.

David

> ---
>  arch/x86/xen/enlighten.c |   30 +++++++++++++++++++++++++++---
>  1 files changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e74df95..18e14af 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -124,6 +124,19 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
>   */
>  static int have_vcpu_info_placement = 1;
>  
> +struct tls_descs {
> +	struct desc_struct desc[3];
> +};
> +
> +/*
> + * Updating the 3 TLS descriptors in the GDT on every task switch is
> + * surprisingly expensive so we avoid updating them if they haven't
> + * changed.  Since Xen writes different descriptors than the one
> + * passed in the update_descriptor hypercall we keep shadow copies to
> + * compare against.
> + */
> +static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
> +
>  static void clamp_max_cpus(void)
>  {
>  #ifdef CONFIG_SMP
> @@ -535,9 +548,20 @@ static void __init xen_load_gdt_boot(const struct desc_ptr *dtr)
>  static void load_TLS_descriptor(struct thread_struct *t,
>  				unsigned int cpu, unsigned int i)
>  {
> -	struct desc_struct *gdt = get_cpu_gdt_table(cpu);
> -	xmaddr_t maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
> -	struct multicall_space mc = __xen_mc_entry(0);
> +	struct desc_struct *shadow = &per_cpu(shadow_tls_desc, cpu).desc[i];
> +	struct desc_struct *gdt;
> +	xmaddr_t maddr;
> +	struct multicall_space mc;
> +
> +	if (shadow->a == t->tls_array[i].a && shadow->b == t->tls_array[i].b)
> +		return;
> +
> +	shadow->a = t->tls_array[i].a;
> +	shadow->b = t->tls_array[i].b;
> +
> +	gdt = get_cpu_gdt_table(cpu);
> +	maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
> +	mc = __xen_mc_entry(0);
>  
>  	MULTI_update_descriptor(mc.mc, maddr.maddr, t->tls_array[i]);
>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:52:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfBPT-0003CN-Qw; Thu, 14 Jun 2012 14:52:31 +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 1SfBPS-0003CE-BQ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 14:52:30 +0000
Received: from [85.158.138.51:46445] by server-5.bemta-3.messagelabs.com id
	48/9D-01572-8AAF9DF4; Thu, 14 Jun 2012 14:52:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339685541!27675693!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29116 invoked from network); 14 Jun 2012 14:52:23 -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;
	14 Jun 2012 14:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28090039"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 10:52:21 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	10:52:20 -0400
Message-ID: <4FD9FAA3.6090303@citrix.com>
Date: Thu, 14 Jun 2012 15:52:19 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "H. Peter
	Anvin" <hpa@zytor.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if
 they haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 18:01, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> When switching tasks in a Xen PV guest, avoid updating the TLS
> descriptors if they haven't changed.  This improves the speed of
> context switches by almost 10% as much of the time the descriptors are
> the same or only one is different.
> 
> The descriptors written into the GDT by Xen are modified from the
> values passed in the update_descriptor hypercall so we keep shadow
> copies of the three TLS descriptors to compare against.
> 
> lmbench3 test     Before  After  Improvement
> --------------------------------------------
> lat_ctx -s 32 24   7.19    6.52  9%
> lat_pipe          12.56   11.66  7%
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
> in desc_struct as deprecated but there seems to be no suitable
> alternatives.

ping?  Any opinion on this patch from the x86 side?  If it's okay can we
get an ack so Konrad can take the patch via his tree.

Thanks.

David

> ---
>  arch/x86/xen/enlighten.c |   30 +++++++++++++++++++++++++++---
>  1 files changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e74df95..18e14af 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -124,6 +124,19 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
>   */
>  static int have_vcpu_info_placement = 1;
>  
> +struct tls_descs {
> +	struct desc_struct desc[3];
> +};
> +
> +/*
> + * Updating the 3 TLS descriptors in the GDT on every task switch is
> + * surprisingly expensive so we avoid updating them if they haven't
> + * changed.  Since Xen writes different descriptors than the one
> + * passed in the update_descriptor hypercall we keep shadow copies to
> + * compare against.
> + */
> +static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
> +
>  static void clamp_max_cpus(void)
>  {
>  #ifdef CONFIG_SMP
> @@ -535,9 +548,20 @@ static void __init xen_load_gdt_boot(const struct desc_ptr *dtr)
>  static void load_TLS_descriptor(struct thread_struct *t,
>  				unsigned int cpu, unsigned int i)
>  {
> -	struct desc_struct *gdt = get_cpu_gdt_table(cpu);
> -	xmaddr_t maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
> -	struct multicall_space mc = __xen_mc_entry(0);
> +	struct desc_struct *shadow = &per_cpu(shadow_tls_desc, cpu).desc[i];
> +	struct desc_struct *gdt;
> +	xmaddr_t maddr;
> +	struct multicall_space mc;
> +
> +	if (shadow->a == t->tls_array[i].a && shadow->b == t->tls_array[i].b)
> +		return;
> +
> +	shadow->a = t->tls_array[i].a;
> +	shadow->b = t->tls_array[i].b;
> +
> +	gdt = get_cpu_gdt_table(cpu);
> +	maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]);
> +	mc = __xen_mc_entry(0);
>  
>  	MULTI_update_descriptor(mc.mc, maddr.maddr, t->tls_array[i]);
>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 14:56:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfBT3-0003L7-Ef; Thu, 14 Jun 2012 14:56: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 1SfBT1-0003Kw-K9
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:56:11 +0000
Received: from [85.158.139.83:4048] by server-11.bemta-5.messagelabs.com id
	79/F1-20400-A8BF9DF4; Thu, 14 Jun 2012 14:56:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339685769!27016931!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24055 invoked from network); 14 Jun 2012 14:56:10 -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 Jun 2012 14:56:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfBSy-0000hJ-KP; Thu, 14 Jun 2012 14:56:08 +0000
Date: Thu, 14 Jun 2012 15:56:08 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <20120614145608.GG90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> Are you talking about having different version of V4V driver running
> in the same VM?

Yes.

> I don't think that is a problem they both interact with Xen via
> hypercall directly so if they follow the v4v hypercall interface it's
> all fine.

AFAICS if they both try to register the same port then one of them will
silently get its ring discarded.  And if they both try to communicate
with the same remote port their entries on the pending lists will get
merged (which is probably not too bad).  I think the possibility for
confusion depends on how you use the service.  Still, it seems better
than the xenstore case, 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 Jun 14 14:56:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 14: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 1SfBT3-0003L7-Ef; Thu, 14 Jun 2012 14:56: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 1SfBT1-0003Kw-K9
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 14:56:11 +0000
Received: from [85.158.139.83:4048] by server-11.bemta-5.messagelabs.com id
	79/F1-20400-A8BF9DF4; Thu, 14 Jun 2012 14:56:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1339685769!27016931!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24055 invoked from network); 14 Jun 2012 14:56:10 -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 Jun 2012 14:56:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfBSy-0000hJ-KP; Thu, 14 Jun 2012 14:56:08 +0000
Date: Thu, 14 Jun 2012 15:56:08 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <20120614145608.GG90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> Are you talking about having different version of V4V driver running
> in the same VM?

Yes.

> I don't think that is a problem they both interact with Xen via
> hypercall directly so if they follow the v4v hypercall interface it's
> all fine.

AFAICS if they both try to register the same port then one of them will
silently get its ring discarded.  And if they both try to communicate
with the same remote port their entries on the pending lists will get
merged (which is probably not too bad).  I think the possibility for
confusion depends on how you use the service.  Still, it seems better
than the xenstore case, 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 Jun 14 15:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBa7-0003b2-BB; Thu, 14 Jun 2012 15:03:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SfBa6-0003ax-1j
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:03:30 +0000
Received: from [85.158.143.99:4455] by server-3.bemta-4.messagelabs.com id
	31/7C-05808-04DF9DF4; Thu, 14 Jun 2012 15:03:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339686206!24033487!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32495 invoked from network); 14 Jun 2012 15:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28092048"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 11:03:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 11:03:25 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SfBZf-0002iu-Ct;
	Thu, 14 Jun 2012 16:03:03 +0100
Message-ID: <4FD9FCAF.4050002@eu.citrix.com>
Date: Thu, 14 Jun 2012 16:01:03 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
In-Reply-To: <20120614102116.GH82539@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
 p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 14/06/12 11:21, Tim Deegan wrote:
> At 12:54 +0100 on 08 Jun (1339160091), George Dunlap wrote:
>> Return the p2m level of the entry which filled this request.
>> Intended to be used to see if pages returned by the balloon
>> driver are part of a superpage, and reclaim them if so.
> This looks broadly correct, but it's a bit invasive.  If there's any way
> to rework patch 2 not to need it that would be helpful.  It looks like
> the main use is for detecting and removing superpage PoD entries; maybe
> that could be done with a sweep like you have in the non-PoD case?
You mean the non-balloon case?  I forget why I thought that was a bad 
idea, exactly.  Let me think about that.
> One niggle: returning level=5 on error is non-obvious, and it doesn't
> look like your code in patch 2 uses that.
Were you thinking -1 or something like that?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBa7-0003b2-BB; Thu, 14 Jun 2012 15:03:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1SfBa6-0003ax-1j
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:03:30 +0000
Received: from [85.158.143.99:4455] by server-3.bemta-4.messagelabs.com id
	31/7C-05808-04DF9DF4; Thu, 14 Jun 2012 15:03:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339686206!24033487!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32495 invoked from network); 14 Jun 2012 15:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28092048"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 11:03:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 11:03:25 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SfBZf-0002iu-Ct;
	Thu, 14 Jun 2012 16:03:03 +0100
Message-ID: <4FD9FCAF.4050002@eu.citrix.com>
Date: Thu, 14 Jun 2012 16:01:03 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
In-Reply-To: <20120614102116.GH82539@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
 p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 14/06/12 11:21, Tim Deegan wrote:
> At 12:54 +0100 on 08 Jun (1339160091), George Dunlap wrote:
>> Return the p2m level of the entry which filled this request.
>> Intended to be used to see if pages returned by the balloon
>> driver are part of a superpage, and reclaim them if so.
> This looks broadly correct, but it's a bit invasive.  If there's any way
> to rework patch 2 not to need it that would be helpful.  It looks like
> the main use is for detecting and removing superpage PoD entries; maybe
> that could be done with a sweep like you have in the non-PoD case?
You mean the non-balloon case?  I forget why I thought that was a bad 
idea, exactly.  Let me think about that.
> One niggle: returning level=5 on error is non-obvious, and it doesn't
> look like your code in patch 2 uses that.
Were you thinking -1 or something like that?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:07:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1SfBdj-0003h9-VX; Thu, 14 Jun 2012 15:07:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfBdj-0003h3-2y
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:07:15 +0000
Received: from [193.109.254.147:16426] by server-9.bemta-14.messagelabs.com id
	69/DD-27072-22EF9DF4; Thu, 14 Jun 2012 15:07:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339686387!9624662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16608 invoked from network); 14 Jun 2012 15:06:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:06:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:06:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:06:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBcw-0006kQ-LT; Thu, 14 Jun 2012 15:06:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBcw-0000m7-JE;
	Thu, 14 Jun 2012 16:06:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.65010.579595.138598@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:06:26 +0100
To: Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1339513107.24104.75.camel@zakaz.uk.xensource.com>,
	<0b8bf8724ee035adf384.1339146488@Solace>
References: <patchbomb.1339146487@Solace>
	<0b8bf8724ee035adf384.1339146488@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
	<20434.2955.317215.979906@mariner.uk.xensource.com>
	<1339513107.24104.75.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters [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] [PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> Was it deliberate that you took this one but not the other patch from
> this series of two, namely "libxl: propagete down the error from
> libxl_domain_sched_params_set"?

No, sorry.

Dario Faggioli writes ("[Xen-devel] [PATCH 1 of 2 v3] libxl: propagete down the error from libxl_domain_sched_params_set"):
> So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:07:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1SfBdj-0003h9-VX; Thu, 14 Jun 2012 15:07:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfBdj-0003h3-2y
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:07:15 +0000
Received: from [193.109.254.147:16426] by server-9.bemta-14.messagelabs.com id
	69/DD-27072-22EF9DF4; Thu, 14 Jun 2012 15:07:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339686387!9624662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16608 invoked from network); 14 Jun 2012 15:06:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:06:28 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:06:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:06:27 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBcw-0006kQ-LT; Thu, 14 Jun 2012 15:06:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBcw-0000m7-JE;
	Thu, 14 Jun 2012 16:06:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.65010.579595.138598@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:06:26 +0100
To: Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1339513107.24104.75.camel@zakaz.uk.xensource.com>,
	<0b8bf8724ee035adf384.1339146488@Solace>
References: <patchbomb.1339146487@Solace>
	<0b8bf8724ee035adf384.1339146488@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
	<20434.2955.317215.979906@mariner.uk.xensource.com>
	<1339513107.24104.75.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters [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] [PATCH 2 of 2 v3] xl: check for meaningful combination of sedf config file parameters"):
> Was it deliberate that you took this one but not the other patch from
> this series of two, namely "libxl: propagete down the error from
> libxl_domain_sched_params_set"?

No, sorry.

Dario Faggioli writes ("[Xen-devel] [PATCH 1 of 2 v3] libxl: propagete down the error from libxl_domain_sched_params_set"):
> So that the caller (e.g., libxl__build_post() ) knows and can deal with it.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBg5-0003oB-Gg; Thu, 14 Jun 2012 15:09:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfBg3-0003o3-R2
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:09:40 +0000
Received: from [85.158.143.99:5387] by server-1.bemta-4.messagelabs.com id
	B5/7F-24392-3BEF9DF4; Thu, 14 Jun 2012 15:09:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339686578!22124612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6657 invoked from network); 14 Jun 2012 15:09:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:09:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:09:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:09:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBff-0006lJ-TZ; Thu, 14 Jun 2012 15:09:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBff-0000qL-R7;
	Thu, 14 Jun 2012 16:09:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.65179.818633.507704@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:09:15 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339514677.24104.84.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
	<1339514677.24104.84.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/19] libxl: domain save: rename variables
 etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/19] libxl: domain save: rename variables etc."):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Preparatory work for making domain suspend asynchronous:
> [...]
> > No functional change whatsoever.
> 
> Given that and a quick skim of the changes:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> Although in general I find it easier to review patches which contain
> only one particular class of "mostly automatic" cleanup (e.g. renames
> separate from "pointerization" separate from local variable removal
> etc).

OK, I will split it up more next time I do something like this.  I
thought I already had rather too many pre- and post-patches, but I'm
happy to make more of them in future.

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 Jun 14 15:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBg5-0003oB-Gg; Thu, 14 Jun 2012 15:09:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfBg3-0003o3-R2
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:09:40 +0000
Received: from [85.158.143.99:5387] by server-1.bemta-4.messagelabs.com id
	B5/7F-24392-3BEF9DF4; Thu, 14 Jun 2012 15:09:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339686578!22124612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6657 invoked from network); 14 Jun 2012 15:09:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:09:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:09:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:09:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBff-0006lJ-TZ; Thu, 14 Jun 2012 15:09:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBff-0000qL-R7;
	Thu, 14 Jun 2012 16:09:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.65179.818633.507704@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:09:15 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339514677.24104.84.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-3-git-send-email-ian.jackson@eu.citrix.com>
	<1339514677.24104.84.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/19] libxl: domain save: rename variables
 etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/19] libxl: domain save: rename variables etc."):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Preparatory work for making domain suspend asynchronous:
> [...]
> > No functional change whatsoever.
> 
> Given that and a quick skim of the changes:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> Although in general I find it easier to review patches which contain
> only one particular class of "mostly automatic" cleanup (e.g. renames
> separate from "pointerization" separate from local variable removal
> etc).

OK, I will split it up more next time I do something like this.  I
thought I already had rather too many pre- and post-patches, but I'm
happy to make more of them in future.

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 Jun 14 15:11:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:11: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 1SfBhQ-0003tm-VY; Thu, 14 Jun 2012 15:11:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfBhP-0003tb-H6
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:11:03 +0000
Received: from [85.158.143.35:55437] by server-3.bemta-4.messagelabs.com id
	D3/D9-05808-60FF9DF4; Thu, 14 Jun 2012 15:11:02 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339686644!5298163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2415 invoked from network); 14 Jun 2012 15:10:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:10:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:10:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:10:44 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfBh5-0006lv-VP;
	Thu, 14 Jun 2012 15:10:44 +0000
Received: by spongy (Postfix, from userid 2023)	id 1962234062B; Thu, 14 Jun
	2012 16:10:44 +0100 (BST)
Date: Thu, 14 Jun 2012 16:10:44 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120614151043.GB24063@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614145608.GG90181@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 14/06 03:56, Tim Deegan wrote:
> At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > Are you talking about having different version of V4V driver running
> > in the same VM?
> 
> Yes.
> 
> > I don't think that is a problem they both interact with Xen via
> > hypercall directly so if they follow the v4v hypercall interface it's
> > all fine.
> 
> AFAICS if they both try to register the same port then one of them will
> silently get its ring discarded.  And if they both try to communicate
> with the same remote port their entries on the pending lists will get
> merged (which is probably not too bad).  I think the possibility for
> confusion depends on how you use the service.  Still, it seems better
> than the xenstore case, anyway. :)
> 

Not silently, register_ring will return an error.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:11:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:11: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 1SfBhQ-0003tm-VY; Thu, 14 Jun 2012 15:11:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfBhP-0003tb-H6
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:11:03 +0000
Received: from [85.158.143.35:55437] by server-3.bemta-4.messagelabs.com id
	D3/D9-05808-60FF9DF4; Thu, 14 Jun 2012 15:11:02 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339686644!5298163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2415 invoked from network); 14 Jun 2012 15:10:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:10:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:10:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:10:44 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfBh5-0006lv-VP;
	Thu, 14 Jun 2012 15:10:44 +0000
Received: by spongy (Postfix, from userid 2023)	id 1962234062B; Thu, 14 Jun
	2012 16:10:44 +0100 (BST)
Date: Thu, 14 Jun 2012 16:10:44 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120614151043.GB24063@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614145608.GG90181@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 14/06 03:56, Tim Deegan wrote:
> At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > Are you talking about having different version of V4V driver running
> > in the same VM?
> 
> Yes.
> 
> > I don't think that is a problem they both interact with Xen via
> > hypercall directly so if they follow the v4v hypercall interface it's
> > all fine.
> 
> AFAICS if they both try to register the same port then one of them will
> silently get its ring discarded.  And if they both try to communicate
> with the same remote port their entries on the pending lists will get
> merged (which is probably not too bad).  I think the possibility for
> confusion depends on how you use the service.  Still, it seems better
> than the xenstore case, anyway. :)
> 

Not silently, register_ring will return an error.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBiK-000402-E8; Thu, 14 Jun 2012 15:12: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 1SfBiJ-0003zm-8G
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:11:59 +0000
Received: from [85.158.143.35:55798] by server-2.bemta-4.messagelabs.com id
	40/56-17938-E3FF9DF4; Thu, 14 Jun 2012 15:11:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339686716!4870583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6664 invoked from network); 14 Jun 2012 15:11:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:11:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:11:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:11:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBiF-0006mQ-K4; Thu, 14 Jun 2012 15:11:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBiF-0000tF-JD;
	Thu, 14 Jun 2012 16:11:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.65339.580452.922455@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:11:55 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339516171.24104.98.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
	<1339516171.24104.98.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle,
 preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle, preparing for ao"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > We are going to arrange that libxl, instead of calling
> > xc_domain_restore, calls a stub function which forks and execs a
> > helper program, so that restore can be asynchronous rather than
> > blocking the whole toolstack.
...
> > * Move the contents of domain_restore into its correct place in the
> >   domain creation sequence.  We put it inside
> >   domcreate_bootloader_done, which now either calls
> 
> "either" but no "or"? I suppose the or case is call
> domcreate_rebuild_done directly?

Yes.  I have completed this sentence.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> I confirmed at a high level that the same blocks of code exist and are
> called in the same overall order, but I didn't do a line by line
> comparison of the blocks in question, assuming they really are mostly
> motion and adjustments for the new context.

Right.  I did some semi-mechanical checks to confirm that assertion,
after the last round of hideous merge conflict doom.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBiK-000402-E8; Thu, 14 Jun 2012 15:12: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 1SfBiJ-0003zm-8G
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:11:59 +0000
Received: from [85.158.143.35:55798] by server-2.bemta-4.messagelabs.com id
	40/56-17938-E3FF9DF4; Thu, 14 Jun 2012 15:11:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339686716!4870583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6664 invoked from network); 14 Jun 2012 15:11:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:11:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13026594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:11:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:11:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBiF-0006mQ-K4; Thu, 14 Jun 2012 15:11:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBiF-0000tF-JD;
	Thu, 14 Jun 2012 16:11:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20441.65339.580452.922455@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:11:55 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339516171.24104.98.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-4-git-send-email-ian.jackson@eu.citrix.com>
	<1339516171.24104.98.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle,
 preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/19] libxl: domain restore: reshuffle, preparing for ao"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > We are going to arrange that libxl, instead of calling
> > xc_domain_restore, calls a stub function which forks and execs a
> > helper program, so that restore can be asynchronous rather than
> > blocking the whole toolstack.
...
> > * Move the contents of domain_restore into its correct place in the
> >   domain creation sequence.  We put it inside
> >   domcreate_bootloader_done, which now either calls
> 
> "either" but no "or"? I suppose the or case is call
> domcreate_rebuild_done directly?

Yes.  I have completed this sentence.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> I confirmed at a high level that the same blocks of code exist and are
> called in the same overall order, but I didn't do a line by line
> comparison of the blocks in question, assuming they really are mostly
> motion and adjustments for the new context.

Right.  I did some semi-mechanical checks to confirm that assertion,
after the last round of hideous merge conflict doom.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:14:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBkH-0004BW-VP; Thu, 14 Jun 2012 15:14:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SfBkG-0004BM-TP
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:14:01 +0000
Received: from [85.158.143.99:36637] by server-3.bemta-4.messagelabs.com id
	26/CE-05808-8BFF9DF4; Thu, 14 Jun 2012 15:14:00 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339686839!27425869!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16606 invoked from network); 14 Jun 2012 15:13:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 15:13:59 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78884585; Thu, 14 Jun 2012 17:13:58 +0200
Message-ID: <1339686831.4705.30.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 14 Jun 2012 17:13:51 +0200
In-Reply-To: <20441.65010.579595.138598@mariner.uk.xensource.com>
References: <patchbomb.1339146487@Solace>
	<0b8bf8724ee035adf384.1339146488@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
	<20434.2955.317215.979906@mariner.uk.xensource.com>
	<1339513107.24104.75.camel@zakaz.uk.xensource.com>
	<20441.65010.579595.138598@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4495378895002114099=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4495378895002114099==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-eIYamL7wd88xWl9gD6i0"


--=-eIYamL7wd88xWl9gD6i0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-14 at 16:06 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for mea=
ningful combination of sedf config file parameters"):
> > Was it deliberate that you took this one but not the other patch from
> > this series of two, namely "libxl: propagete down the error from
> > libxl_domain_sched_params_set"?
>=20
> No, sorry.
>=20
> Dario Faggioli writes ("[Xen-devel] [PATCH 1 of 2 v3] libxl: propagete do=
wn the error from libxl_domain_sched_params_set"):
> > So that the caller (e.g., libxl__build_post() ) knows and can deal with=
 it.
>=20
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
Cool. Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-eIYamL7wd88xWl9gD6i0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/Z/68ACgkQk4XaBE3IOsTfIwCfe9mPCeflOHY9YfXyVwbV8IqT
4ScAoIcpcwpVfz4pV4DGoJy2Ua0SYVss
=6Vep
-----END PGP SIGNATURE-----

--=-eIYamL7wd88xWl9gD6i0--



--===============4495378895002114099==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4495378895002114099==--



From xen-devel-bounces@lists.xen.org Thu Jun 14 15:14:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBkH-0004BW-VP; Thu, 14 Jun 2012 15:14:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SfBkG-0004BM-TP
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:14:01 +0000
Received: from [85.158.143.99:36637] by server-3.bemta-4.messagelabs.com id
	26/CE-05808-8BFF9DF4; Thu, 14 Jun 2012 15:14:00 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339686839!27425869!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16606 invoked from network); 14 Jun 2012 15:13:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 15:13:59 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78884585; Thu, 14 Jun 2012 17:13:58 +0200
Message-ID: <1339686831.4705.30.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 14 Jun 2012 17:13:51 +0200
In-Reply-To: <20441.65010.579595.138598@mariner.uk.xensource.com>
References: <patchbomb.1339146487@Solace>
	<0b8bf8724ee035adf384.1339146488@Solace>
	<e0c4a09877d727255103.1339146489@Solace>
	<20433.56754.133034.440704@mariner.uk.xensource.com>
	<4FD1DDDC.6020405@eu.citrix.com>
	<20434.2955.317215.979906@mariner.uk.xensource.com>
	<1339513107.24104.75.camel@zakaz.uk.xensource.com>
	<20441.65010.579595.138598@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for meaningful
 combination of sedf config file parameters [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4495378895002114099=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4495378895002114099==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-eIYamL7wd88xWl9gD6i0"


--=-eIYamL7wd88xWl9gD6i0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-14 at 16:06 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 2 v3] xl: check for mea=
ningful combination of sedf config file parameters"):
> > Was it deliberate that you took this one but not the other patch from
> > this series of two, namely "libxl: propagete down the error from
> > libxl_domain_sched_params_set"?
>=20
> No, sorry.
>=20
> Dario Faggioli writes ("[Xen-devel] [PATCH 1 of 2 v3] libxl: propagete do=
wn the error from libxl_domain_sched_params_set"):
> > So that the caller (e.g., libxl__build_post() ) knows and can deal with=
 it.
>=20
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
Cool. Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-eIYamL7wd88xWl9gD6i0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/Z/68ACgkQk4XaBE3IOsTfIwCfe9mPCeflOHY9YfXyVwbV8IqT
4ScAoIcpcwpVfz4pV4DGoJy2Ua0SYVss
=6Vep
-----END PGP SIGNATURE-----

--=-eIYamL7wd88xWl9gD6i0--



--===============4495378895002114099==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4495378895002114099==--



From xen-devel-bounces@lists.xen.org Thu Jun 14 15:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBmN-0004Ps-LV; Thu, 14 Jun 2012 15:16:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SfBmM-0004PI-4Y
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:16:10 +0000
Received: from [193.109.254.147:45822] by server-2.bemta-14.messagelabs.com id
	1B/7E-27740-9300ADF4; Thu, 14 Jun 2012 15:16:09 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339686965!8941046!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7665 invoked from network); 14 Jun 2012 15:16:06 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Jun 2012 15:16:06 -0000
Received: from mail15-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 15:14:57 +0000
Received: from mail15-tx2 (localhost [127.0.0.1])	by mail15-tx2-R.bigfish.com
	(Postfix) with ESMTP id CBEC71E03A8;
	Thu, 14 Jun 2012 15:14:56 +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(zz98dI148cI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail15-tx2 (localhost.localdomain [127.0.0.1]) by mail15-tx2
	(MessageSwitch) id 1339686894703215_15994;
	Thu, 14 Jun 2012 15:14:54 +0000 (UTC)
Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.248])	by
	mail15-tx2.bigfish.com (Postfix) with ESMTP id 9DB9046005A;
	Thu, 14 Jun 2012 15:14:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 15:14:52 +0000
X-WSS-ID: 0M5M52K-02-13U-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 2095CC80EC;	Thu, 14 Jun 2012 10:15:55 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 14 Jun 2012 10:24:23 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 14 Jun 2012 10:15:57 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	11:15:56 -0400
Received: from [165.204.15.183] (caesium.osrc.amd.com [165.204.15.183])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 23CA749C69D; Thu, 14 Jun 2012
	16:15:55 +0100 (BST)
Message-ID: <4FDA0028.3090609@amd.com>
Date: Thu, 14 Jun 2012 17:15:52 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
In-Reply-To: <4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Hurwitz, Sherry" <sherry.hurwitz@amd.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
 disabled 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

Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>> On 14.06.12 at 14:13, Wei Wang<wei.wang2@amd.com>  wrote:
>> Am 12.06.2012 18:43, schrieb Jan Beulich:
>>> That is precisely what I suggested in my response to the first
>>> version of this patch, and I'd also volunteer to look into putting
>>> together a first draft implementation if we sort of agree that
>>> this is the way to go.
>>
>> Cool! thanks for doing that. Looking forward to it in Xen 4.2 since
>> iommu msi is really broken with recent Linux dom0...
>
> That's unlikely to be for 4.2 - it's going to have a reasonable risk
> of regressions, and functionality like that I don't think is nice to
> rush into a feature frozen tree, the more that it provides a
> workaround for the combination of questionable design and an
> improper kernel side fix.

Yes, it looks like improper to me also, but it would also be nice to 
have something Xen to handle this situation. Maybe we should not trust 
guest os, even dom0 some times...

> Have you at all considered getting this fixed on the kernel side?
> As I don't have direct access to any AMD IOMMU capable
> system - can one, other than by enumerating the respective
> PCI IDs or reading ACPI tables, reasonably easily identify the
> devices in question (e.g. via vendor/class/sub-class or some
> such)? That might permit skipping those in the offending kernel
> code...

AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
should be enough to identify amd iommu device. I could send you a kernel 
patch for review using this approach. I would believe that fixing this 
issue in 4.2, no matter how, is really important for amd iommu.

Thanks,
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 Jun 14 15:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfBmN-0004Ps-LV; Thu, 14 Jun 2012 15:16:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1SfBmM-0004PI-4Y
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:16:10 +0000
Received: from [193.109.254.147:45822] by server-2.bemta-14.messagelabs.com id
	1B/7E-27740-9300ADF4; Thu, 14 Jun 2012 15:16:09 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339686965!8941046!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7665 invoked from network); 14 Jun 2012 15:16:06 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Jun 2012 15:16:06 -0000
Received: from mail15-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 15:14:57 +0000
Received: from mail15-tx2 (localhost [127.0.0.1])	by mail15-tx2-R.bigfish.com
	(Postfix) with ESMTP id CBEC71E03A8;
	Thu, 14 Jun 2012 15:14:56 +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(zz98dI148cI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail15-tx2 (localhost.localdomain [127.0.0.1]) by mail15-tx2
	(MessageSwitch) id 1339686894703215_15994;
	Thu, 14 Jun 2012 15:14:54 +0000 (UTC)
Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.248])	by
	mail15-tx2.bigfish.com (Postfix) with ESMTP id 9DB9046005A;
	Thu, 14 Jun 2012 15:14:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server id
	14.1.225.23; Thu, 14 Jun 2012 15:14:52 +0000
X-WSS-ID: 0M5M52K-02-13U-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 2095CC80EC;	Thu, 14 Jun 2012 10:15:55 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 14 Jun 2012 10:24:23 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 14 Jun 2012 10:15:57 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	11:15:56 -0400
Received: from [165.204.15.183] (caesium.osrc.amd.com [165.204.15.183])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 23CA749C69D; Thu, 14 Jun 2012
	16:15:55 +0100 (BST)
Message-ID: <4FDA0028.3090609@amd.com>
Date: Thu, 14 Jun 2012 17:15:52 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
In-Reply-To: <4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Hurwitz, Sherry" <sherry.hurwitz@amd.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
 disabled 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

Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>> On 14.06.12 at 14:13, Wei Wang<wei.wang2@amd.com>  wrote:
>> Am 12.06.2012 18:43, schrieb Jan Beulich:
>>> That is precisely what I suggested in my response to the first
>>> version of this patch, and I'd also volunteer to look into putting
>>> together a first draft implementation if we sort of agree that
>>> this is the way to go.
>>
>> Cool! thanks for doing that. Looking forward to it in Xen 4.2 since
>> iommu msi is really broken with recent Linux dom0...
>
> That's unlikely to be for 4.2 - it's going to have a reasonable risk
> of regressions, and functionality like that I don't think is nice to
> rush into a feature frozen tree, the more that it provides a
> workaround for the combination of questionable design and an
> improper kernel side fix.

Yes, it looks like improper to me also, but it would also be nice to 
have something Xen to handle this situation. Maybe we should not trust 
guest os, even dom0 some times...

> Have you at all considered getting this fixed on the kernel side?
> As I don't have direct access to any AMD IOMMU capable
> system - can one, other than by enumerating the respective
> PCI IDs or reading ACPI tables, reasonably easily identify the
> devices in question (e.g. via vendor/class/sub-class or some
> such)? That might permit skipping those in the offending kernel
> code...

AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
should be enough to identify amd iommu device. I could send you a kernel 
patch for review using this approach. I would believe that fixing this 
issue in 4.2, no matter how, is really important for amd iommu.

Thanks,
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 Jun 14 15:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfBrt-0004g1-G0; Thu, 14 Jun 2012 15:21:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SfBrq-0004fv-LY
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:21:52 +0000
Received: from [85.158.143.35:19879] by server-2.bemta-4.messagelabs.com id
	16/F5-17938-D810ADF4; Thu, 14 Jun 2012 15:21:49 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339687306!14540392!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDQzNDQ4OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9480 invoked from network); 14 Jun 2012 15:21:47 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 15:21:47 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q5EFLgcQ020617;
	Thu, 14 Jun 2012 17:21:42 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5EFLfoF011211;
	Thu, 14 Jun 2012 17:21:41 +0200
Message-ID: <4FDA0185.5050903@siemens.com>
Date: Thu, 14 Jun 2012 17:21:41 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
In-Reply-To: <4FD9F789.5070300@citrix.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-14 16:39, Anthony PERARD wrote:
> On 13/06/12 13:48, Jan Kiszka wrote:
>>>>>>  Will you be able to use an address parser via some device property?
>>>>
>>>>  Yes. Actually, the address is already a device property.
>>>>
>> Great. Then we should try to come up with a common pci-host-devaddr
>> property everyone can use.
> 
> Is this patch would be a good common property?
> 
> It's probably close to the patch you send earlier Jan.
> 
> If it's good, I'll resend my passthrough patch series with this patch.

Looks generally OK to me, let's try to move forward with this. Please
fix the coding style issues before sending.

> 
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index b7b5597..9c7a271 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
>       .max   = 65024,
>   };
> 
> +/* --- pci host address --- */
> +
> +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    char buffer[4 + 2 + 2 + 2 + 1];

Buffer is too small.

> +    char *p = buffer;
> +
> +    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
> +             addr->domain, addr->bus, addr->slot, addr->function);
> +
> +    visit_type_str(v, &p, name, errp);
> +}
> +
> +/*
> + * Parse [<domain>:]<bus>:<slot>.<func>
> + *   if <domain> is not supplied, it's assumed to be 0.
> + */
> +static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    Error *local_err = NULL;
> +    char *str, *p;
> +    char *e;
> +    unsigned long val;
> +    unsigned long dom = 0, bus = 0;
> +    unsigned int slot = 0, func = 0;
> +
> +    if (dev->state != DEV_STATE_CREATED) {
> +        error_set(errp, QERR_PERMISSION_DENIED);
> +        return;
> +    }
> +
> +    visit_type_str(v, &str, name, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        return;
> +    }
> +
> +    p = str;
> +    val = strtoul(p, &e, 16);
> +    if (e == p || *e != ':')
> +        goto inval;
> +    bus = val;
> +
> +    p = e + 1;
> +    val = strtoul(p, &e, 16);
> +    if (e == p)
> +        goto inval;
> +    if (*e == ':') {
> +        dom = bus;
> +        bus = val;
> +        p = e + 1;
> +        val = strtoul(p, &e, 16);
> +        if (e == p)
> +            goto inval;
> +    }
> +    slot = val;
> +
> +    if (*e != '.')
> +        goto inval;
> +    p = e + 1;
> +    val = strtoul(p, &e, 10);
> +    if (e == p)
> +        goto inval;
> +    func = val;
> +
> +    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7)
> +        goto inval;
> +
> +    if (*e)
> +        goto inval;
> +
> +    addr->domain = dom;
> +    addr->bus = bus;
> +    addr->slot = slot;
> +    addr->function = func;
> +
> +    g_free(str);
> +    return;
> +
> +inval:
> +    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +    g_free(str);
> +}
> +
> +PropertyInfo qdev_prop_pci_host_devaddr = {
> +    .name = "pci-host-devaddr",
> +    .get = get_pci_host_devaddr,
> +    .set = set_pci_host_devaddr,
> +};
> +
>   /* --- public helpers --- */
> 
>   static Property *qdev_prop_walk(Property *props, const char *name)
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 4e90119..9a54ebe 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -225,6 +225,7 @@ extern PropertyInfo qdev_prop_netdev;
>   extern PropertyInfo qdev_prop_vlan;
>   extern PropertyInfo qdev_prop_pci_devfn;
>   extern PropertyInfo qdev_prop_blocksize;
> +extern PropertyInfo qdev_prop_pci_host_devaddr;
> 
>   #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
>           .name      = (_name),                                    \
> @@ -288,6 +289,8 @@ extern PropertyInfo qdev_prop_blocksize;
>                           LostTickPolicy)
>   #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
>       DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
> +#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
> +    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, 
> PCIHostDeviceAddress)
> 
>   #define DEFINE_PROP_END_OF_LIST()               \
>       {}
> diff --git a/qemu-common.h b/qemu-common.h
> index 91e0562..0d6e51c 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
>       LOST_TICK_MAX
>   } LostTickPolicy;
> 
> +typedef struct PCIHostDeviceAddress {
> +    unsigned int domain;
> +    unsigned int bus;
> +    unsigned int slot;
> +    unsigned int function;
> +} PCIHostDeviceAddress;
> +
>   void tcg_exec_init(unsigned long tb_size);
>   bool tcg_enabled(void);
> 
> 

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfBrt-0004g1-G0; Thu, 14 Jun 2012 15:21:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1SfBrq-0004fv-LY
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:21:52 +0000
Received: from [85.158.143.35:19879] by server-2.bemta-4.messagelabs.com id
	16/F5-17938-D810ADF4; Thu, 14 Jun 2012 15:21:49 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1339687306!14540392!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDQzNDQ4OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9480 invoked from network); 14 Jun 2012 15:21:47 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 15:21:47 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q5EFLgcQ020617;
	Thu, 14 Jun 2012 17:21:42 +0200
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5EFLfoF011211;
	Thu, 14 Jun 2012 17:21:41 +0200
Message-ID: <4FDA0185.5050903@siemens.com>
Date: Thu, 14 Jun 2012 17:21:41 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
In-Reply-To: <4FD9F789.5070300@citrix.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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 2012-06-14 16:39, Anthony PERARD wrote:
> On 13/06/12 13:48, Jan Kiszka wrote:
>>>>>>  Will you be able to use an address parser via some device property?
>>>>
>>>>  Yes. Actually, the address is already a device property.
>>>>
>> Great. Then we should try to come up with a common pci-host-devaddr
>> property everyone can use.
> 
> Is this patch would be a good common property?
> 
> It's probably close to the patch you send earlier Jan.
> 
> If it's good, I'll resend my passthrough patch series with this patch.

Looks generally OK to me, let's try to move forward with this. Please
fix the coding style issues before sending.

> 
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index b7b5597..9c7a271 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
>       .max   = 65024,
>   };
> 
> +/* --- pci host address --- */
> +
> +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    char buffer[4 + 2 + 2 + 2 + 1];

Buffer is too small.

> +    char *p = buffer;
> +
> +    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
> +             addr->domain, addr->bus, addr->slot, addr->function);
> +
> +    visit_type_str(v, &p, name, errp);
> +}
> +
> +/*
> + * Parse [<domain>:]<bus>:<slot>.<func>
> + *   if <domain> is not supplied, it's assumed to be 0.
> + */
> +static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    Error *local_err = NULL;
> +    char *str, *p;
> +    char *e;
> +    unsigned long val;
> +    unsigned long dom = 0, bus = 0;
> +    unsigned int slot = 0, func = 0;
> +
> +    if (dev->state != DEV_STATE_CREATED) {
> +        error_set(errp, QERR_PERMISSION_DENIED);
> +        return;
> +    }
> +
> +    visit_type_str(v, &str, name, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        return;
> +    }
> +
> +    p = str;
> +    val = strtoul(p, &e, 16);
> +    if (e == p || *e != ':')
> +        goto inval;
> +    bus = val;
> +
> +    p = e + 1;
> +    val = strtoul(p, &e, 16);
> +    if (e == p)
> +        goto inval;
> +    if (*e == ':') {
> +        dom = bus;
> +        bus = val;
> +        p = e + 1;
> +        val = strtoul(p, &e, 16);
> +        if (e == p)
> +            goto inval;
> +    }
> +    slot = val;
> +
> +    if (*e != '.')
> +        goto inval;
> +    p = e + 1;
> +    val = strtoul(p, &e, 10);
> +    if (e == p)
> +        goto inval;
> +    func = val;
> +
> +    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7)
> +        goto inval;
> +
> +    if (*e)
> +        goto inval;
> +
> +    addr->domain = dom;
> +    addr->bus = bus;
> +    addr->slot = slot;
> +    addr->function = func;
> +
> +    g_free(str);
> +    return;
> +
> +inval:
> +    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +    g_free(str);
> +}
> +
> +PropertyInfo qdev_prop_pci_host_devaddr = {
> +    .name = "pci-host-devaddr",
> +    .get = get_pci_host_devaddr,
> +    .set = set_pci_host_devaddr,
> +};
> +
>   /* --- public helpers --- */
> 
>   static Property *qdev_prop_walk(Property *props, const char *name)
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 4e90119..9a54ebe 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -225,6 +225,7 @@ extern PropertyInfo qdev_prop_netdev;
>   extern PropertyInfo qdev_prop_vlan;
>   extern PropertyInfo qdev_prop_pci_devfn;
>   extern PropertyInfo qdev_prop_blocksize;
> +extern PropertyInfo qdev_prop_pci_host_devaddr;
> 
>   #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
>           .name      = (_name),                                    \
> @@ -288,6 +289,8 @@ extern PropertyInfo qdev_prop_blocksize;
>                           LostTickPolicy)
>   #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
>       DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
> +#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
> +    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, 
> PCIHostDeviceAddress)
> 
>   #define DEFINE_PROP_END_OF_LIST()               \
>       {}
> diff --git a/qemu-common.h b/qemu-common.h
> index 91e0562..0d6e51c 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
>       LOST_TICK_MAX
>   } LostTickPolicy;
> 
> +typedef struct PCIHostDeviceAddress {
> +    unsigned int domain;
> +    unsigned int bus;
> +    unsigned int slot;
> +    unsigned int function;
> +} PCIHostDeviceAddress;
> +
>   void tcg_exec_init(unsigned long tb_size);
>   bool tcg_enabled(void);
> 
> 

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:26:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:26:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfBwZ-0004of-70; Thu, 14 Jun 2012 15:26:43 +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 1SfBwY-0004oX-7M
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:26:42 +0000
Received: from [85.158.143.99:52509] by server-1.bemta-4.messagelabs.com id
	52/4B-24392-1B20ADF4; Thu, 14 Jun 2012 15:26:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339687601!20368913!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24113 invoked from network); 14 Jun 2012 15:26:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 15:26:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 16:26:41 +0100
Message-Id: <4FDA1EFD020000780008A0B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 16:27:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
In-Reply-To: <4FDA0028.3090609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
> Am 14.06.2012 16:18, schrieb Jan Beulich:
>> Have you at all considered getting this fixed on the kernel side?
>> As I don't have direct access to any AMD IOMMU capable
>> system - can one, other than by enumerating the respective
>> PCI IDs or reading ACPI tables, reasonably easily identify the
>> devices in question (e.g. via vendor/class/sub-class or some
>> such)? That might permit skipping those in the offending kernel
>> code...
> 
> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
> should be enough to identify amd iommu device. I could send you a kernel 
> patch for review using this approach.

Yes, please.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:26:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:26:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfBwZ-0004of-70; Thu, 14 Jun 2012 15:26:43 +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 1SfBwY-0004oX-7M
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:26:42 +0000
Received: from [85.158.143.99:52509] by server-1.bemta-4.messagelabs.com id
	52/4B-24392-1B20ADF4; Thu, 14 Jun 2012 15:26:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339687601!20368913!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24113 invoked from network); 14 Jun 2012 15:26:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 15:26:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 16:26:41 +0100
Message-Id: <4FDA1EFD020000780008A0B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 16:27:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
In-Reply-To: <4FDA0028.3090609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
> Am 14.06.2012 16:18, schrieb Jan Beulich:
>> Have you at all considered getting this fixed on the kernel side?
>> As I don't have direct access to any AMD IOMMU capable
>> system - can one, other than by enumerating the respective
>> PCI IDs or reading ACPI tables, reasonably easily identify the
>> devices in question (e.g. via vendor/class/sub-class or some
>> such)? That might permit skipping those in the offending kernel
>> code...
> 
> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
> should be enough to identify amd iommu device. I could send you a kernel 
> patch for review using this approach.

Yes, please.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:27:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:27: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 1SfBwr-0004qG-Jg; Thu, 14 Jun 2012 15:27:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfBwp-0004pz-TL
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:27:00 +0000
Received: from [85.158.143.35:28308] by server-1.bemta-4.messagelabs.com id
	CB/AB-24392-3C20ADF4; Thu, 14 Jun 2012 15:26:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339687618!11958934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14642 invoked from network); 14 Jun 2012 15:26:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:26:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:26:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBwo-0006sN-9n; Thu, 14 Jun 2012 15:26:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBwo-0003p1-78;
	Thu, 14 Jun 2012 16:26:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.706.194448.288137@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:26:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339519893.24104.115.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Change the internal and external APIs for domain save (suspend) to be
> > capable of asynchronous operation.  The implementation remains
> > synchronous.  The interfaces surrounding device model saving are still
> > synchronous.
...
> >  * The `suspend_callback' function passed to libxl_domain_save is
> >    never called by the existing implementation in libxl.  Abolish it.
> 
> Furthermore xl never passes one in either.

Right.  I will update the commit message to note this too.

> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> A few minor comments below, but otherwise looks good to me.

Thanks...

> > +static void remus_crashed_cb(libxl__egc *egc,
> > +                             libxl__domain_suspend_state *dss, int rc)
> 
> I'm not sure "crashed" is quite right here, it's finished for whatever
> reason which may not necessarily be a crash (going forward it should
> rarely be a crash, I think). It's "stopped" or "done" or something.

How about "remus_target_gone_cb" ?

> > +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
> > +                         const libxl_asyncop_how *ao_how)

> > +    if (type < 0) {
> > +        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);
> 
> libxl__domain_type now logs for you.

I will bring forward the relevant hunk from my domain type final
fixups patch.

> >  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
> [...]
> > @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> > 
> >  /*----- Domain suspend (save) functions -----*/
> > 
> > -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> > -                                         libxl_domain_type type,
> > -                                         int live, int debug,
> > -                                         const libxl_domain_remus_info *r_info);
> > +/* calls callback when done */
> 
> Which callback? dss->callback I guess.

What a confusing way to quote this.  You're referring to this function
of course:

> > +_hidden void libxl__domain_suspend(libxl__egc *egc,
> > +                                   libxl__domain_suspend_state *dss);

Gripe gripe these comments before functions are inducing you to
top-post !

Anyway, yes.  I will clarify this comment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:27:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:27: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 1SfBwr-0004qG-Jg; Thu, 14 Jun 2012 15:27:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfBwp-0004pz-TL
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:27:00 +0000
Received: from [85.158.143.35:28308] by server-1.bemta-4.messagelabs.com id
	CB/AB-24392-3C20ADF4; Thu, 14 Jun 2012 15:26:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1339687618!11958934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14642 invoked from network); 14 Jun 2012 15:26:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:26:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:26:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfBwo-0006sN-9n; Thu, 14 Jun 2012 15:26:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfBwo-0003p1-78;
	Thu, 14 Jun 2012 16:26:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.706.194448.288137@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:26:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339519893.24104.115.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Change the internal and external APIs for domain save (suspend) to be
> > capable of asynchronous operation.  The implementation remains
> > synchronous.  The interfaces surrounding device model saving are still
> > synchronous.
...
> >  * The `suspend_callback' function passed to libxl_domain_save is
> >    never called by the existing implementation in libxl.  Abolish it.
> 
> Furthermore xl never passes one in either.

Right.  I will update the commit message to note this too.

> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> A few minor comments below, but otherwise looks good to me.

Thanks...

> > +static void remus_crashed_cb(libxl__egc *egc,
> > +                             libxl__domain_suspend_state *dss, int rc)
> 
> I'm not sure "crashed" is quite right here, it's finished for whatever
> reason which may not necessarily be a crash (going forward it should
> rarely be a crash, I think). It's "stopped" or "done" or something.

How about "remus_target_gone_cb" ?

> > +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
> > +                         const libxl_asyncop_how *ao_how)

> > +    if (type < 0) {
> > +        LOG(ERROR,"domain %"PRIu32": unable to determine domain type", domid);
> 
> libxl__domain_type now logs for you.

I will bring forward the relevant hunk from my domain type final
fixups patch.

> >  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
> [...]
> > @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> > 
> >  /*----- Domain suspend (save) functions -----*/
> > 
> > -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> > -                                         libxl_domain_type type,
> > -                                         int live, int debug,
> > -                                         const libxl_domain_remus_info *r_info);
> > +/* calls callback when done */
> 
> Which callback? dss->callback I guess.

What a confusing way to quote this.  You're referring to this function
of course:

> > +_hidden void libxl__domain_suspend(libxl__egc *egc,
> > +                                   libxl__domain_suspend_state *dss);

Gripe gripe these comments before functions are inducing you to
top-post !

Anyway, yes.  I will clarify this comment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:31:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfC1H-00059J-DR; Thu, 14 Jun 2012 15:31:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfC1G-00059C-MW
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:31:34 +0000
Received: from [85.158.139.83:62744] by server-6.bemta-5.messagelabs.com id
	EB/FD-11348-5D30ADF4; Thu, 14 Jun 2012 15:31:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339687892!27709313!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16678 invoked from network); 14 Jun 2012 15:31:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:31:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:31:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:31:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfC1E-0006u3-KU; Thu, 14 Jun 2012 15:31:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfC1E-0003pR-JN;
	Thu, 14 Jun 2012 16:31:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.980.581076.579624@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:31:32 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>,
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>,
	<1339583442.24104.178.camel@zakaz.uk.xensource.com>,
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>,
	<20440.31030.964902.468871@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>
	<20440.31030.964902.468871@mariner.uk.xensource.com>
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>
	<1339583442.24104.178.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process [and 4 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

To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
FCC: ~/mail/Outbound
--text follows this line--
Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > This is v3 of my series to asyncify save/restore, rebased to current
> > tip, retested, and with all comments addressed.
> 
> There's quite a lot of combinations which need testing here (PV, HVM,
> HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> 
> I tried a simple localhost migrate of a PV guest and:

Thanks for looking at all this and for testing it.  I thought I had
tested localhost migration, but my shell history reveals, now that it
is pointed out to me, that in my tests the migration receiver process
had been running the old version of libxl.

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> The first zero here is restore_fd, I think. But I read in the comment in
> the helper:
>         > + * The helper talks on stdin and stdout, in binary in machine
>         > + * endianness.  The helper speaks first, and only when it has a
>         > + * callback to make.  It writes a 16-bit number being the message
>         > + * length, and then the message body.
> 
> So restore_fd == stdin => running two protocols over the same fd?

This is indeed why it's not working.  I have repro'd the failure and
my tree now has a fix in it.

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> Oh, right, migrate-receive takes the migration fd on stdin doesn't it,
> so that's where it comes from. I still suspect it is wrong. Might need
> to dup the input onto a safe fd?

Indeed.

> BTW, since I've been ctrl-c'ing "xl migrate" a bunch I noticed that we
> seem to leak an "xl migrate-receive" and the restore side helper
> process. Probably pre-existing but I thought it worth mentioning.

I'll look into this.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:31:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfC1H-00059J-DR; Thu, 14 Jun 2012 15:31:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfC1G-00059C-MW
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:31:34 +0000
Received: from [85.158.139.83:62744] by server-6.bemta-5.messagelabs.com id
	EB/FD-11348-5D30ADF4; Thu, 14 Jun 2012 15:31:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339687892!27709313!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16678 invoked from network); 14 Jun 2012 15:31:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:31:33 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:31:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:31:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfC1E-0006u3-KU; Thu, 14 Jun 2012 15:31:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfC1E-0003pR-JN;
	Thu, 14 Jun 2012 16:31:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.980.581076.579624@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:31:32 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>,
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>,
	<1339583442.24104.178.camel@zakaz.uk.xensource.com>,
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>,
	<20440.31030.964902.468871@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>
	<20440.31030.964902.468871@mariner.uk.xensource.com>
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>
	<1339583442.24104.178.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process [and 4 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

To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
In-Reply-To: <1339577986.24104.149.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
FCC: ~/mail/Outbound
--text follows this line--
Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > This is v3 of my series to asyncify save/restore, rebased to current
> > tip, retested, and with all comments addressed.
> 
> There's quite a lot of combinations which need testing here (PV, HVM,
> HVM w/ stub dm, old vs new qemu etc etc), which of those have you tried?
> 
> I tried a simple localhost migrate of a PV guest and:

Thanks for looking at all this and for testing it.  I thought I had
tested localhost migration, but my shell history reveals, now that it
is pointed out to me, that in my tests the migration receiver process
had been running the old version of libxl.

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> The first zero here is restore_fd, I think. But I read in the comment in
> the helper:
>         > + * The helper talks on stdin and stdout, in binary in machine
>         > + * endianness.  The helper speaks first, and only when it has a
>         > + * callback to make.  It writes a 16-bit number being the message
>         > + * length, and then the message body.
> 
> So restore_fd == stdin => running two protocols over the same fd?

This is indeed why it's not working.  I have repro'd the failure and
my tree now has a fix in it.

Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> Oh, right, migrate-receive takes the migration fd on stdin doesn't it,
> so that's where it comes from. I still suspect it is wrong. Might need
> to dup the input onto a safe fd?

Indeed.

> BTW, since I've been ctrl-c'ing "xl migrate" a bunch I noticed that we
> seem to leak an "xl migrate-receive" and the restore side helper
> process. Probably pre-existing but I thought it worth mentioning.

I'll look into this.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:31:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:31: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 1SfC1K-00059j-Pi; Thu, 14 Jun 2012 15:31:38 +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 1SfC1J-00059W-Ka
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:31:37 +0000
Received: from [85.158.138.51:42638] by server-4.bemta-3.messagelabs.com id
	23/3B-17105-8D30ADF4; Thu, 14 Jun 2012 15:31:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339687895!27650072!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6680 invoked from network); 14 Jun 2012 15:31:35 -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; 14 Jun 2012 15:31:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfC1H-000193-4y; Thu, 14 Jun 2012 15:31:35 +0000
Date: Thu, 14 Jun 2012 16:31:35 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614153135.GH90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
	<4FD9FCAF.4050002@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9FCAF.4050002@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 +0100 on 14 Jun (1339689663), George Dunlap wrote:
> On 14/06/12 11:21, Tim Deegan wrote:
> >At 12:54 +0100 on 08 Jun (1339160091), George Dunlap wrote:
> >>Return the p2m level of the entry which filled this request.
> >>Intended to be used to see if pages returned by the balloon
> >>driver are part of a superpage, and reclaim them if so.
> >This looks broadly correct, but it's a bit invasive.  If there's any way
> >to rework patch 2 not to need it that would be helpful.  It looks like
> >the main use is for detecting and removing superpage PoD entries; maybe
> >that could be done with a sweep like you have in the non-PoD case?
> You mean the non-balloon case?  I forget why I thought that was a bad 
> idea, exactly.  Let me think about that.
> >One niggle: returning level=5 on error is non-obvious, and it doesn't
> >look like your code in patch 2 uses that.
> Were you thinking -1 or something like that?

Actually, looking at it again, and at the way the value is used by its
caller, maybe 5 is OK (though it looks like it will return 6 in the EPT
code).  So assuming this patch doesn't go away, I'd be OK with just a
comment explaining 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 Jun 14 15:31:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:31: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 1SfC1K-00059j-Pi; Thu, 14 Jun 2012 15:31:38 +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 1SfC1J-00059W-Ka
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:31:37 +0000
Received: from [85.158.138.51:42638] by server-4.bemta-3.messagelabs.com id
	23/3B-17105-8D30ADF4; Thu, 14 Jun 2012 15:31:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339687895!27650072!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6680 invoked from network); 14 Jun 2012 15:31:35 -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; 14 Jun 2012 15:31:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfC1H-000193-4y; Thu, 14 Jun 2012 15:31:35 +0000
Date: Thu, 14 Jun 2012 16:31:35 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614153135.GH90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
	<4FD9FCAF.4050002@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9FCAF.4050002@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 +0100 on 14 Jun (1339689663), George Dunlap wrote:
> On 14/06/12 11:21, Tim Deegan wrote:
> >At 12:54 +0100 on 08 Jun (1339160091), George Dunlap wrote:
> >>Return the p2m level of the entry which filled this request.
> >>Intended to be used to see if pages returned by the balloon
> >>driver are part of a superpage, and reclaim them if so.
> >This looks broadly correct, but it's a bit invasive.  If there's any way
> >to rework patch 2 not to need it that would be helpful.  It looks like
> >the main use is for detecting and removing superpage PoD entries; maybe
> >that could be done with a sweep like you have in the non-PoD case?
> You mean the non-balloon case?  I forget why I thought that was a bad 
> idea, exactly.  Let me think about that.
> >One niggle: returning level=5 on error is non-obvious, and it doesn't
> >look like your code in patch 2 uses that.
> Were you thinking -1 or something like that?

Actually, looking at it again, and at the way the value is used by its
caller, maybe 5 is OK (though it looks like it will return 6 in the EPT
code).  So assuming this patch doesn't go away, I'd be OK with just a
comment explaining 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 Jun 14 15:36:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:36: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 1SfC5Y-0005Rs-Jm; Thu, 14 Jun 2012 15:36:00 +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 1SfC5W-0005Rh-R6
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:35:59 +0000
Received: from [85.158.143.35:16785] by server-3.bemta-4.messagelabs.com id
	AA/82-05808-ED40ADF4; Thu, 14 Jun 2012 15:35:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339688157!12318638!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12265 invoked from network); 14 Jun 2012 15:35:57 -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 Jun 2012 15:35:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfC5U-0001Cu-H0; Thu, 14 Jun 2012 15:35:56 +0000
Date: Thu, 14 Jun 2012 16:35:56 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614153556.GI90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614151043.GB24063@spongy>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> On 14/06 03:56, Tim Deegan wrote:
> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > Are you talking about having different version of V4V driver running
> > > in the same VM?
> > 
> > Yes.
> > 
> > > I don't think that is a problem they both interact with Xen via
> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > all fine.
> > 
> > AFAICS if they both try to register the same port then one of them will
> > silently get its ring discarded.  And if they both try to communicate
> > with the same remote port their entries on the pending lists will get
> > merged (which is probably not too bad).  I think the possibility for
> > confusion depends on how you use the service.  Still, it seems better
> > than the xenstore case, anyway. :)
> > 
> 
> Not silently, register_ring will return an error.

Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
list.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:36:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:36: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 1SfC5Y-0005Rs-Jm; Thu, 14 Jun 2012 15:36:00 +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 1SfC5W-0005Rh-R6
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:35:59 +0000
Received: from [85.158.143.35:16785] by server-3.bemta-4.messagelabs.com id
	AA/82-05808-ED40ADF4; Thu, 14 Jun 2012 15:35:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339688157!12318638!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12265 invoked from network); 14 Jun 2012 15:35:57 -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 Jun 2012 15:35:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfC5U-0001Cu-H0; Thu, 14 Jun 2012 15:35:56 +0000
Date: Thu, 14 Jun 2012 16:35:56 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614153556.GI90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614151043.GB24063@spongy>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> On 14/06 03:56, Tim Deegan wrote:
> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > Are you talking about having different version of V4V driver running
> > > in the same VM?
> > 
> > Yes.
> > 
> > > I don't think that is a problem they both interact with Xen via
> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > all fine.
> > 
> > AFAICS if they both try to register the same port then one of them will
> > silently get its ring discarded.  And if they both try to communicate
> > with the same remote port their entries on the pending lists will get
> > merged (which is probably not too bad).  I think the possibility for
> > confusion depends on how you use the service.  Still, it seems better
> > than the xenstore case, anyway. :)
> > 
> 
> Not silently, register_ring will return an error.

Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
list.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:37:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:37: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 1SfC6T-0005Wd-1n; Thu, 14 Jun 2012 15:36: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 1SfC6R-0005WS-UK
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:36:56 +0000
Received: from [85.158.138.51:19732] by server-8.bemta-3.messagelabs.com id
	D2/47-06157-2150ADF4; Thu, 14 Jun 2012 15:36:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339688209!21338143!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21256 invoked from network); 14 Jun 2012 15:36:49 -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 Jun 2012 15:36:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfC6K-0001Dn-Oy; Thu, 14 Jun 2012 15:36:48 +0000
Date: Thu, 14 Jun 2012 16:36:48 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614153648.GJ90181@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
	<4FD205E80200007800088C36@nat28.tlf.novell.com>
	<20120614090725.GC82539@ocelot.phlegethon.org>
	<4FD9F42E.2060707@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9F42E.2060707@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
	pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:24 +0100 on 14 Jun (1339687486), George Dunlap wrote:
> >>Also, wouldn't it be better to allocate this table dynamically, at
> >>once allowing its size to scale with the number of vCPU-s in the
> >>guest?
> >You could even make it a small per-vcpu array, assuming that the parallel
> >scrubbing will be symmetric across vcpus.
> I can't remember exactly what I found here (this was last summer I was 
> doing the tests); it may be that Windows creates a bunch of tasks which 
> may migrate to various cpus.  If that were the case, a global list would 
> be better than per-vcpu lists.
> 
> The problem with dynamically scaling the list is that I don't have a 
> heuristic to hand for how to scale it.
> 
> In both cases, it's not unlikely that making a change without testing 
> will significantly reduce the effectiveness of the patch.  Would you 
> rather hold off and wait until I can get a chance to run my benchmarks 
> again (which may miss the 4.2 cycle), or accept a tidied-up version of 
> this patch first, and hope to get a revised method (using dynamic 
> scaling or per-vcpu arrays) in before 4.2, but for sure by 4.3?

I'd be happy with the fixed size 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 Jun 14 15:37:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:37: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 1SfC6T-0005Wd-1n; Thu, 14 Jun 2012 15:36: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 1SfC6R-0005WS-UK
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:36:56 +0000
Received: from [85.158.138.51:19732] by server-8.bemta-3.messagelabs.com id
	D2/47-06157-2150ADF4; Thu, 14 Jun 2012 15:36:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339688209!21338143!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21256 invoked from network); 14 Jun 2012 15:36:49 -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 Jun 2012 15:36:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfC6K-0001Dn-Oy; Thu, 14 Jun 2012 15:36:48 +0000
Date: Thu, 14 Jun 2012 16:36:48 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120614153648.GJ90181@ocelot.phlegethon.org>
References: <patchbomb.1339155931@exile>
	<4145b32d0c43d7d46650.1339155932@exile>
	<4FD205E80200007800088C36@nat28.tlf.novell.com>
	<20120614090725.GC82539@ocelot.phlegethon.org>
	<4FD9F42E.2060707@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9F42E.2060707@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 RFC] xen,
	pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:24 +0100 on 14 Jun (1339687486), George Dunlap wrote:
> >>Also, wouldn't it be better to allocate this table dynamically, at
> >>once allowing its size to scale with the number of vCPU-s in the
> >>guest?
> >You could even make it a small per-vcpu array, assuming that the parallel
> >scrubbing will be symmetric across vcpus.
> I can't remember exactly what I found here (this was last summer I was 
> doing the tests); it may be that Windows creates a bunch of tasks which 
> may migrate to various cpus.  If that were the case, a global list would 
> be better than per-vcpu lists.
> 
> The problem with dynamically scaling the list is that I don't have a 
> heuristic to hand for how to scale it.
> 
> In both cases, it's not unlikely that making a change without testing 
> will significantly reduce the effectiveness of the patch.  Would you 
> rather hold off and wait until I can get a chance to run my benchmarks 
> again (which may miss the 4.2 cycle), or accept a tidied-up version of 
> this patch first, and hope to get a revised method (using dynamic 
> scaling or per-vcpu arrays) in before 4.2, but for sure by 4.3?

I'd be happy with the fixed size 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 Jun 14 15:39:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:39: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 1SfC94-0005h7-Jx; Thu, 14 Jun 2012 15:39:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfC92-0005gv-Qh
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:39:37 +0000
Received: from [85.158.143.99:50966] by server-2.bemta-4.messagelabs.com id
	03/41-17938-8B50ADF4; Thu, 14 Jun 2012 15:39:36 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339688375!26841938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19497 invoked from network); 14 Jun 2012 15:39:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:39:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:39:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:39:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfC8f-0006wy-9x;
	Thu, 14 Jun 2012 15:39:13 +0000
Received: by spongy (Postfix, from userid 2023)	id 70A4C34062B; Thu, 14 Jun
	2012 16:39:13 +0100 (BST)
Date: Thu, 14 Jun 2012 16:39:13 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Message-ID: <20120614153913.GC24063@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614144008.GA24063@spongy>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06 03:40, Jean Guyader wrote:
> On 14/06 03:27, Tim Deegan wrote:
> > At 15:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> > > At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > > > Maybe I should put here the reason that led me to do something
> > > > like that. Here is what I'm trying to do:
> > > > 
> > > >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> > > >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> > > >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> > > >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > > > 
> > > > I need to cast to uint8_t first to get the add_offset to behave
> > > > correctly. Maybe what I need would need a new macro that would
> > > > do those two operations.
> > > > 
> > > > What would be the proper way to doing something like this?
> > > 
> > > You could avoid it altogether by dropping struct v4v_ring_data, and
> > > passing a v4v_pfn_t array directly with the 'npage' as a separate
> > > hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> > > fields.
> > 
> > Excuse me, I meant struct v4v_pfn_list_t.
> > 
> 
> You probably mean both, because we doing the same thing with
> v4v_ring_data_t and v4v_ring_data_ent_t.
> 

Actually I don't want to get rid of the v4v_ring_data_t struct.

The idea being this struct is that we might want to extend it in the future
so having a wrapper arround with a magic is important to detect which
version of the struct is being used.

Here are the structs:

typedef struct v4v_ring_data_ent                                                                      
{                                                                                                     
    struct v4v_addr ring;                                                                             
    uint16_t flags;                                                                                   
    uint16_t pad0;                                                                                    
    uint32_t space_required;                                                                          
    uint32_t max_message_size;                                                                        
} v4v_ring_data_ent_t;                                                                                
DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                                                        
                                                                                                      
typedef struct v4v_ring_data                                                                          
{                                                                                                     
    uint64_t magic;                                                                                   
    uint32_t nent;                                                                                    
    uint32_t padding;                                                                                 
    uint64_t reserved[4];                                                                             
    v4v_ring_data_ent_t ring[0];                                                                      
} v4v_ring_data_t;                                                                                    
DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);

I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I would
like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.

Here is the code that I use for doing that (with explicte cast in guest_handle_cast):
    XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
    XEN_GUEST_HANDLE (uint8_t) slop_hnd =
        guest_handle_cast (ring_data_hnd, uint8_t);
    guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
    ring_data_ent_hnd =
        guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
    ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);

Thanks for your help.
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:39:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:39: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 1SfC94-0005h7-Jx; Thu, 14 Jun 2012 15:39:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfC92-0005gv-Qh
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:39:37 +0000
Received: from [85.158.143.99:50966] by server-2.bemta-4.messagelabs.com id
	03/41-17938-8B50ADF4; Thu, 14 Jun 2012 15:39:36 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339688375!26841938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19497 invoked from network); 14 Jun 2012 15:39:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:39:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:39:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:39:13 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SfC8f-0006wy-9x;
	Thu, 14 Jun 2012 15:39:13 +0000
Received: by spongy (Postfix, from userid 2023)	id 70A4C34062B; Thu, 14 Jun
	2012 16:39:13 +0100 (BST)
Date: Thu, 14 Jun 2012 16:39:13 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Message-ID: <20120614153913.GC24063@spongy>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614144008.GA24063@spongy>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06 03:40, Jean Guyader wrote:
> On 14/06 03:27, Tim Deegan wrote:
> > At 15:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> > > At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > > > Maybe I should put here the reason that led me to do something
> > > > like that. Here is what I'm trying to do:
> > > > 
> > > >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> > > >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> > > >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> > > >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > > > 
> > > > I need to cast to uint8_t first to get the add_offset to behave
> > > > correctly. Maybe what I need would need a new macro that would
> > > > do those two operations.
> > > > 
> > > > What would be the proper way to doing something like this?
> > > 
> > > You could avoid it altogether by dropping struct v4v_ring_data, and
> > > passing a v4v_pfn_t array directly with the 'npage' as a separate
> > > hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> > > fields.
> > 
> > Excuse me, I meant struct v4v_pfn_list_t.
> > 
> 
> You probably mean both, because we doing the same thing with
> v4v_ring_data_t and v4v_ring_data_ent_t.
> 

Actually I don't want to get rid of the v4v_ring_data_t struct.

The idea being this struct is that we might want to extend it in the future
so having a wrapper arround with a magic is important to detect which
version of the struct is being used.

Here are the structs:

typedef struct v4v_ring_data_ent                                                                      
{                                                                                                     
    struct v4v_addr ring;                                                                             
    uint16_t flags;                                                                                   
    uint16_t pad0;                                                                                    
    uint32_t space_required;                                                                          
    uint32_t max_message_size;                                                                        
} v4v_ring_data_ent_t;                                                                                
DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                                                        
                                                                                                      
typedef struct v4v_ring_data                                                                          
{                                                                                                     
    uint64_t magic;                                                                                   
    uint32_t nent;                                                                                    
    uint32_t padding;                                                                                 
    uint64_t reserved[4];                                                                             
    v4v_ring_data_ent_t ring[0];                                                                      
} v4v_ring_data_t;                                                                                    
DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);

I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I would
like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.

Here is the code that I use for doing that (with explicte cast in guest_handle_cast):
    XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
    XEN_GUEST_HANDLE (uint8_t) slop_hnd =
        guest_handle_cast (ring_data_hnd, uint8_t);
    guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
    ring_data_ent_hnd =
        guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
    ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);

Thanks for your help.
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:39:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:39: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 1SfC99-0005hm-0F; Thu, 14 Jun 2012 15:39:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfC97-0005hS-Na
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:39:41 +0000
Received: from [85.158.143.99:7872] by server-3.bemta-4.messagelabs.com id
	F6/F7-05808-DB50ADF4; Thu, 14 Jun 2012 15:39:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339688375!26841938!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19758 invoked from network); 14 Jun 2012 15:39:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:39:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:39:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfC93-0006x9-Ch; Thu, 14 Jun 2012 15:39:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfC93-0003q0-AS;
	Thu, 14 Jun 2012 16:39:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.1465.307401.362448@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:39:37 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
In-Reply-To: <20442.980.581076.579624@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>
	<20440.31030.964902.468871@mariner.uk.xensource.com>
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>
	<1339583442.24104.178.camel@zakaz.uk.xensource.com>
	<20442.980.581076.579624@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process [and 4 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 v3 00/18] libxl: domain save/restore: run in a separate process [and 4 more messages]"):
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>

Uh, sorry about the duplicated header.

> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> > BTW, since I've been ctrl-c'ing "xl migrate" a bunch I noticed that we
> > seem to leak an "xl migrate-receive" and the restore side helper
> > process. Probably pre-existing but I thought it worth mentioning.
> 
> I'll look into this.

This seems better now, at the tip of my series, at least.  If I ctrl-c
xl migrate running via ssh then all the receiver processes, and the
relevant domain, seem to get cleaned up.

If I do xl migrate not running via ssh, eg
   xl migrate -s '' debian.guest.osstest 'xl migrate-recieve'
then both the sender and receiver get my ^C so we leak the domain.  I
think that's the expected behaviour.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:39:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:39: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 1SfC99-0005hm-0F; Thu, 14 Jun 2012 15:39:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfC97-0005hS-Na
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:39:41 +0000
Received: from [85.158.143.99:7872] by server-3.bemta-4.messagelabs.com id
	F6/F7-05808-DB50ADF4; Thu, 14 Jun 2012 15:39:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1339688375!26841938!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19758 invoked from network); 14 Jun 2012 15:39:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:39:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:39:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfC93-0006x9-Ch; Thu, 14 Jun 2012 15:39:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfC93-0003q0-AS;
	Thu, 14 Jun 2012 16:39:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.1465.307401.362448@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:39:37 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
In-Reply-To: <20442.980.581076.579624@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339577986.24104.149.camel@zakaz.uk.xensource.com>
	<1339583907.24104.182.camel@zakaz.uk.xensource.com>
	<20440.31030.964902.468871@mariner.uk.xensource.com>
	<1339582969.24104.175.camel@zakaz.uk.xensource.com>
	<1339583442.24104.178.camel@zakaz.uk.xensource.com>
	<20442.980.581076.579624@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process [and 4 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 v3 00/18] libxl: domain save/restore: run in a separate process [and 4 more messages]"):
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>

Uh, sorry about the duplicated header.

> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a separate process"):
> > BTW, since I've been ctrl-c'ing "xl migrate" a bunch I noticed that we
> > seem to leak an "xl migrate-receive" and the restore side helper
> > process. Probably pre-existing but I thought it worth mentioning.
> 
> I'll look into this.

This seems better now, at the tip of my series, at least.  If I ctrl-c
xl migrate running via ssh then all the receiver processes, and the
relevant domain, seem to get cleaned up.

If I do xl migrate not running via ssh, eg
   xl migrate -s '' debian.guest.osstest 'xl migrate-recieve'
then both the sender and receiver get my ^C so we leak the domain.  I
think that's the expected behaviour.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:48:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfCH6-00067i-UX; Thu, 14 Jun 2012 15:47:56 +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 1SfCH5-00067d-Gd
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:47:55 +0000
Received: from [193.109.254.147:34165] by server-5.bemta-14.messagelabs.com id
	A6/00-31398-AA70ADF4; Thu, 14 Jun 2012 15:47:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339688874!7359792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10270 invoked from network); 14 Jun 2012 15:47:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:47:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:47:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:47:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfCH3-000705-NE; Thu, 14 Jun 2012 15:47:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfCH3-0003t4-M2;
	Thu, 14 Jun 2012 16:47:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.1961.665575.42873@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:47:53 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339591954.24104.200.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
	<1339591954.24104.200.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
 logdirty 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge logdirty command"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > The current migration code in libxl instructs qemu to start or stop
> > logdirty, but it does not wait for an acknowledgement from qemu before
> > continuing.  This might lead to memory corruption (!)
...
> > +static void logdirty_init(libxl__logdirty_switch *lds)
> > +{
> > +    lds->cmd_path = 0;
> > +    libxl__ev_xswatch_init(&lds->watch);
> > +    libxl__ev_time_init(&lds->timeout);
> 
> I meant to mention this once before when reviewing some patch or other
> but I'm not sure I actually did, so at the risk of repeating myself:
> 
> This watch with timeout pattern seems to be reasonably common (in fact,
> I'm not sure we have any watches without a timeout). It might be a
> candidate for a specific helper routine in the future?

Perhaps.  We should think about this.  I'm not sure it's necessary
now.  The benefit might be relatively small, as the callback function
would more complicated.  Perhaps we should integrate the single xs
read which most of these callers also have.

> > +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
> > +                            const char *watch_path, const char *event_path)
> > +{
...
> > + out:
> > +    /* rc < 0: error
> > +     * rc == 0: ok, we are done
> > +     * rc == +1: need to keep waiting
> > +     */
> > +    libxl__xs_transaction_abort(gc, &t);
> > +
> > +    if (!rc) {
> > +        switch_logdirty_done(egc,dss,1);
> > +    } else if (rc < 0) {
> > +        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);
> 
> Is it only "response read failed" which can cause us to end up here,
> looks like the read, rm etc could do it?

Oh yes.  I should fix that message.  (All of these paths have already
logged something already, but another message probably doesn't hurt.)

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 Jun 14 15:48:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfCH6-00067i-UX; Thu, 14 Jun 2012 15:47:56 +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 1SfCH5-00067d-Gd
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:47:55 +0000
Received: from [193.109.254.147:34165] by server-5.bemta-14.messagelabs.com id
	A6/00-31398-AA70ADF4; Thu, 14 Jun 2012 15:47:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1339688874!7359792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10270 invoked from network); 14 Jun 2012 15:47:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:47:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13027711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 15:47:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 16:47:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfCH3-000705-NE; Thu, 14 Jun 2012 15:47:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfCH3-0003t4-M2;
	Thu, 14 Jun 2012 16:47:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.1961.665575.42873@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 16:47:53 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339591954.24104.200.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
	<1339591954.24104.200.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
 logdirty 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge logdirty command"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > The current migration code in libxl instructs qemu to start or stop
> > logdirty, but it does not wait for an acknowledgement from qemu before
> > continuing.  This might lead to memory corruption (!)
...
> > +static void logdirty_init(libxl__logdirty_switch *lds)
> > +{
> > +    lds->cmd_path = 0;
> > +    libxl__ev_xswatch_init(&lds->watch);
> > +    libxl__ev_time_init(&lds->timeout);
> 
> I meant to mention this once before when reviewing some patch or other
> but I'm not sure I actually did, so at the risk of repeating myself:
> 
> This watch with timeout pattern seems to be reasonably common (in fact,
> I'm not sure we have any watches without a timeout). It might be a
> candidate for a specific helper routine in the future?

Perhaps.  We should think about this.  I'm not sure it's necessary
now.  The benefit might be relatively small, as the callback function
would more complicated.  Perhaps we should integrate the single xs
read which most of these callers also have.

> > +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
> > +                            const char *watch_path, const char *event_path)
> > +{
...
> > + out:
> > +    /* rc < 0: error
> > +     * rc == 0: ok, we are done
> > +     * rc == +1: need to keep waiting
> > +     */
> > +    libxl__xs_transaction_abort(gc, &t);
> > +
> > +    if (!rc) {
> > +        switch_logdirty_done(egc,dss,1);
> > +    } else if (rc < 0) {
> > +        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);
> 
> Is it only "response read failed" which can cause us to end up here,
> looks like the read, rm etc could do it?

Oh yes.  I should fix that message.  (All of these paths have already
logged something already, but another message probably doesn't hurt.)

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 Jun 14 15:51:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfCK3-0006Dl-HI; Thu, 14 Jun 2012 15:50:59 +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 1SfCK2-0006Dg-6W
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:50:58 +0000
Received: from [85.158.143.35:34833] by server-3.bemta-4.messagelabs.com id
	4E/F8-05808-1680ADF4; Thu, 14 Jun 2012 15:50:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339689056!16318369!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28781 invoked from network); 14 Jun 2012 15:50:56 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 15:50:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfCJx-0001PY-G7; Thu, 14 Jun 2012 15:50:53 +0000
Date: Thu, 14 Jun 2012 16:50:53 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614155053.GK90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614153913.GC24063@spongy>
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 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0100 on 14 Jun (1339691953), Jean Guyader wrote:
> On 14/06 03:40, Jean Guyader wrote:
> > On 14/06 03:27, Tim Deegan wrote:
> > > At 15:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> > > > At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > > > > Maybe I should put here the reason that led me to do something
> > > > > like that. Here is what I'm trying to do:
> > > > > 
> > > > >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> > > > >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> > > > >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> > > > >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > > > > 
> > > > > I need to cast to uint8_t first to get the add_offset to behave
> > > > > correctly. Maybe what I need would need a new macro that would
> > > > > do those two operations.
> > > > > 
> > > > > What would be the proper way to doing something like this?
> > > > 
> > > > You could avoid it altogether by dropping struct v4v_ring_data, and
> > > > passing a v4v_pfn_t array directly with the 'npage' as a separate
> > > > hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> > > > fields.
> > > 
> > > Excuse me, I meant struct v4v_pfn_list_t.
> > > 
> > 
> > You probably mean both, because we doing the same thing with
> > v4v_ring_data_t and v4v_ring_data_ent_t.
> > 
> 
> Actually I don't want to get rid of the v4v_ring_data_t struct.
> 
> The idea being this struct is that we might want to extend it in the future
> so having a wrapper arround with a magic is important to detect which
> version of the struct is being used.

Do you have concrete ideas for how you might want to extend the header,
or is this just generic futureproofing?

Since each of these structs is only used for one command you can
allocate new command numbers if you need to add more arguments later.
That's worked well enough for other hypercalls in the past.

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 Jun 14 15:51:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfCK3-0006Dl-HI; Thu, 14 Jun 2012 15:50:59 +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 1SfCK2-0006Dg-6W
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:50:58 +0000
Received: from [85.158.143.35:34833] by server-3.bemta-4.messagelabs.com id
	4E/F8-05808-1680ADF4; Thu, 14 Jun 2012 15:50:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1339689056!16318369!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28781 invoked from network); 14 Jun 2012 15:50:56 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 15:50:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfCJx-0001PY-G7; Thu, 14 Jun 2012 15:50:53 +0000
Date: Thu, 14 Jun 2012 16:50:53 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120614155053.GK90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614153913.GC24063@spongy>
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 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0100 on 14 Jun (1339691953), Jean Guyader wrote:
> On 14/06 03:40, Jean Guyader wrote:
> > On 14/06 03:27, Tim Deegan wrote:
> > > At 15:26 +0100 on 14 Jun (1339687574), Tim Deegan wrote:
> > > > At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> > > > > Maybe I should put here the reason that led me to do something
> > > > > like that. Here is what I'm trying to do:
> > > > > 
> > > > >         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> > > > >                 guest_handle_cast (pfn_list_hnd, uint8_t);
> > > > >         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
> > > > >         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> > > > > 
> > > > > I need to cast to uint8_t first to get the add_offset to behave
> > > > > correctly. Maybe what I need would need a new macro that would
> > > > > do those two operations.
> > > > > 
> > > > > What would be the proper way to doing something like this?
> > > > 
> > > > You could avoid it altogether by dropping struct v4v_ring_data, and
> > > > passing a v4v_pfn_t array directly with the 'npage' as a separate
> > > > hypercall argument.  AFAICS struct v4v_ring_data has no other useful
> > > > fields.
> > > 
> > > Excuse me, I meant struct v4v_pfn_list_t.
> > > 
> > 
> > You probably mean both, because we doing the same thing with
> > v4v_ring_data_t and v4v_ring_data_ent_t.
> > 
> 
> Actually I don't want to get rid of the v4v_ring_data_t struct.
> 
> The idea being this struct is that we might want to extend it in the future
> so having a wrapper arround with a magic is important to detect which
> version of the struct is being used.

Do you have concrete ideas for how you might want to extend the header,
or is this just generic futureproofing?

Since each of these structs is only used for one command you can
allocate new command numbers if you need to add more arguments later.
That's worked well enough for other hypercalls in the past.

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 Jun 14 15:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfCRu-0006QY-HX; Thu, 14 Jun 2012 15:59:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfCRt-0006QT-0B
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:59:05 +0000
Received: from [193.109.254.147:54630] by server-4.bemta-14.messagelabs.com id
	DC/7F-27598-84A0ADF4; Thu, 14 Jun 2012 15:59:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339689542!2601616!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5289 invoked from network); 14 Jun 2012 15:59:03 -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;
	14 Jun 2012 15:59:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198776131"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 11:59:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 11:59:01 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfCRp-0004Kb-FE;
	Thu, 14 Jun 2012 16:59:01 +0100
Message-ID: <4FDA0A45.8030503@citrix.com>
Date: Thu, 14 Jun 2012 16:59:01 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
	<20120614153014.GB18618@redhat.com>
In-Reply-To: <20120614153014.GB18618@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 14/06/12 16:30, Michael S. Tsirkin wrote:
>> >  Is this patch would be a good common property?
>> >
>> >  It's probably close to the patch you send earlier Jan.
>> >
>> >  If it's good, I'll resend my passthrough patch series with this patch.
>> >
>> >
>> >  diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
>> >  index b7b5597..9c7a271 100644
>> >  --- a/hw/qdev-properties.c
>> >  +++ b/hw/qdev-properties.c
>> >  @@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
>> >        .max   = 65024,
>> >    };
>> >
>> >  +/* --- pci host address --- */
>> >  +
>> >  +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
>> >  +                                 const char *name, Error **errp)
>> >  +{
>> >  +    DeviceState *dev = DEVICE(obj);
>> >  +    Property *prop = opaque;
>> >  +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
>> >  +    char buffer[4 + 2 + 2 + 2 + 1];
> One trick is this:
>      char buffer[] = "XXXX:XX:XX.X";

I love this trick, even if it use a bit of space in the binary, I think. 
I will use it.

> And comparing with the above, your buffer looks too short, doesn't it?

Yes, I think I forgot to count the ':'s and '.'.

>> >  +    char *p = buffer;
>> >  +
>> >  +    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
>> >  +             addr->domain, addr->bus, addr->slot, addr->function);
> A good idea might be to check the return code. assert(ret<= sizeof buf).

I will.

Thanks,

-- 
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 Jun 14 15:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15: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 1SfCRu-0006QY-HX; Thu, 14 Jun 2012 15:59:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfCRt-0006QT-0B
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:59:05 +0000
Received: from [193.109.254.147:54630] by server-4.bemta-14.messagelabs.com id
	DC/7F-27598-84A0ADF4; Thu, 14 Jun 2012 15:59:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339689542!2601616!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5289 invoked from network); 14 Jun 2012 15:59:03 -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;
	14 Jun 2012 15:59:03 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198776131"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 11:59:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 11:59:01 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfCRp-0004Kb-FE;
	Thu, 14 Jun 2012 16:59:01 +0100
Message-ID: <4FDA0A45.8030503@citrix.com>
Date: Thu, 14 Jun 2012 16:59:01 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Michael S. Tsirkin" <mst@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
	<20120614153014.GB18618@redhat.com>
In-Reply-To: <20120614153014.GB18618@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 14/06/12 16:30, Michael S. Tsirkin wrote:
>> >  Is this patch would be a good common property?
>> >
>> >  It's probably close to the patch you send earlier Jan.
>> >
>> >  If it's good, I'll resend my passthrough patch series with this patch.
>> >
>> >
>> >  diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
>> >  index b7b5597..9c7a271 100644
>> >  --- a/hw/qdev-properties.c
>> >  +++ b/hw/qdev-properties.c
>> >  @@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
>> >        .max   = 65024,
>> >    };
>> >
>> >  +/* --- pci host address --- */
>> >  +
>> >  +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
>> >  +                                 const char *name, Error **errp)
>> >  +{
>> >  +    DeviceState *dev = DEVICE(obj);
>> >  +    Property *prop = opaque;
>> >  +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
>> >  +    char buffer[4 + 2 + 2 + 2 + 1];
> One trick is this:
>      char buffer[] = "XXXX:XX:XX.X";

I love this trick, even if it use a bit of space in the binary, I think. 
I will use it.

> And comparing with the above, your buffer looks too short, doesn't it?

Yes, I think I forgot to count the ':'s and '.'.

>> >  +    char *p = buffer;
>> >  +
>> >  +    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
>> >  +             addr->domain, addr->bus, addr->slot, addr->function);
> A good idea might be to check the return code. assert(ret<= sizeof buf).

I will.

Thanks,

-- 
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 Jun 14 15:59:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:59: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 1SfCSF-0006SA-2R; Thu, 14 Jun 2012 15:59: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 1SfCSE-0006S2-4A
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:59:26 +0000
Received: from [85.158.138.51:54491] by server-12.bemta-3.messagelabs.com id
	C0/72-30206-D5A0ADF4; Thu, 14 Jun 2012 15:59:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339689564!18781411!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16073 invoked from network); 14 Jun 2012 15:59:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 15:59:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 16:59:25 +0100
Message-Id: <4FDA26A8020000780008A100@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 17:00:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
In-Reply-To: <20120614153913.GC24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
> Here are the structs:
> 
> typedef struct v4v_ring_data_ent                                             
> {                                                                            
>     struct v4v_addr ring;                                                    
>     uint16_t flags;                                                          
>     uint16_t pad0;                                                           
>     uint32_t space_required;                                                 
>     uint32_t max_message_size;                                               
> } v4v_ring_data_ent_t;                                                       
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                               
>                                                                              
> typedef struct v4v_ring_data                                                 
> {                                                                            
>     uint64_t magic;                                                          
>     uint32_t nent;                                                           
>     uint32_t padding;                                                        
>     uint64_t reserved[4];                                                    
>     v4v_ring_data_ent_t ring[0];                                             
> } v4v_ring_data_t;                                                           
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> 
> I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I 
> would like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.
> 
> Here is the code that I use for doing that (with explicte cast in 
> guest_handle_cast):
>     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
>     XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>         guest_handle_cast (ring_data_hnd, uint8_t);
>     guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
>     ring_data_ent_hnd =
>         guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
>     ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);

So you really don't want to add anything (as not being type-safe),
but instead want to get a guest handle representation for accessing
the ring[0] member. That is, I'd introduce a guest_handle_for_field()
for this purpose. Let me see whether I can put something together
for you early next week.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:59:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:59: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 1SfCSF-0006SA-2R; Thu, 14 Jun 2012 15:59: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 1SfCSE-0006S2-4A
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:59:26 +0000
Received: from [85.158.138.51:54491] by server-12.bemta-3.messagelabs.com id
	C0/72-30206-D5A0ADF4; Thu, 14 Jun 2012 15:59:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339689564!18781411!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16073 invoked from network); 14 Jun 2012 15:59:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 15:59:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Jun 2012 16:59:25 +0100
Message-Id: <4FDA26A8020000780008A100@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 14 Jun 2012 17:00:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
In-Reply-To: <20120614153913.GC24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
> Here are the structs:
> 
> typedef struct v4v_ring_data_ent                                             
> {                                                                            
>     struct v4v_addr ring;                                                    
>     uint16_t flags;                                                          
>     uint16_t pad0;                                                           
>     uint32_t space_required;                                                 
>     uint32_t max_message_size;                                               
> } v4v_ring_data_ent_t;                                                       
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                               
>                                                                              
> typedef struct v4v_ring_data                                                 
> {                                                                            
>     uint64_t magic;                                                          
>     uint32_t nent;                                                           
>     uint32_t padding;                                                        
>     uint64_t reserved[4];                                                    
>     v4v_ring_data_ent_t ring[0];                                             
> } v4v_ring_data_t;                                                           
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> 
> I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I 
> would like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.
> 
> Here is the code that I use for doing that (with explicte cast in 
> guest_handle_cast):
>     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
>     XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>         guest_handle_cast (ring_data_hnd, uint8_t);
>     guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
>     ring_data_ent_hnd =
>         guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
>     ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);

So you really don't want to add anything (as not being type-safe),
but instead want to get a guest handle representation for accessing
the ring[0] member. That is, I'd introduce a guest_handle_for_field()
for this purpose. Let me see whether I can put something together
for you early next week.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 15:59:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfCSL-0006T5-Fm; Thu, 14 Jun 2012 15:59:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1SfCSK-0006Sm-2w
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:59:32 +0000
Received: from [85.158.143.99:43851] by server-1.bemta-4.messagelabs.com id
	A0/6B-24392-36A0ADF4; Thu, 14 Jun 2012 15:59:31 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339689570!27388887!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2991 invoked from network); 14 Jun 2012 15:59:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:59:30 -0000
Received: by werf3 with SMTP id f3so1726906wer.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 08:59:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=geSHNt1p9c51iRaPxcvJLs9IpvmT7Fg5GzQC7OKs3rY=;
	b=eGH3Rn0ZLDgwlF6RiEP14Huc7YQniFLdmij6Ek2/sun33GPK3hLOWUjSAzCq77m4St
	tjs2LBnXEaZYo4NTHdI1uT/6ccYhmWc3+cUd+WiRB6L3yHy7p8AImS1JL5Bjik/1ldkf
	Kgro9R9lGartrJTZzKqFyxaFlfKjQazQ07P++OIZ420dmujV7jdQRYVWJldocQHvmO0e
	/l/C1KqWSrMVn5IXRJAE1468mpXIVWmbJ2A3RjaoueP/rCQpXDMkXowD9ze82KrPYl6m
	b4afBLT+EG94LAaEA94iH+s4jgXQIi+cI08UZNmL3a9BgnaGWhaT+EJfraHgrile4b+u
	BFqQ==
MIME-Version: 1.0
Received: by 10.216.226.233 with SMTP id b83mr1238099weq.204.1339689570252;
	Thu, 14 Jun 2012 08:59:30 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Thu, 14 Jun 2012 08:59:30 -0700 (PDT)
In-Reply-To: <1339491940.24104.8.camel@zakaz.uk.xensource.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
	<CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
	<1339491940.24104.8.camel@zakaz.uk.xensource.com>
Date: Thu, 14 Jun 2012 08:59:30 -0700
Message-ID: <CAE+SDMwQSaDnatuj3uh9Se_E9LbzO8KKX5MNabwHVW2MkDGqFw@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0245373102767356042=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0245373102767356042==
Content-Type: multipart/alternative; boundary=0016e6dee8faf1b67c04c270c89f

--0016e6dee8faf1b67c04c270c89f
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jun 12, 2012 at 2:05 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Fri, 2012-06-08 at 19:15 +0100, Zeinab Alebouyeh wrote:
>
> > Because currently I'm not in lab I don't know my hypervisor is 32b or
> > 64 bit.
> > I'm working in a security project. for improve security of
> > applications running in virtualized environment. I want to use the
> > security instruction of AMD SVM named SKINIT.
> > because this instruction must run in ring0, I add a hypercall in xen
> > and write my codes in my hypercall function.
> > The skinit instruction takes the physical address of a block as an
> > input operand( in the eax register) and establish a secure execution
> > environment for a software component(block)
> > I have a label in my hypercall function that is the start of my block.
> > In order to use skinit I want grab the physical address of my label to
> > save in eax register.
>
> Rather than use a label in the current function for this magic block you
> should use a separate function, either in a .S or a .c file. Then you
> can simply use &function_name to get the address and you don't run the
> risk of accidentally falling through into the special code from the
> non-skinit context etc.
>
> Ian.
>
> Thanks for your guidance,
you means that if I use a function, &function_name gives me the physical
address of function or the virtual address of function?

--0016e6dee8faf1b67c04c270c89f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Jun 12, 2012 at 2:05 AM, Ian Cam=
pbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" targ=
et=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:1px #ccc solid=
;padding-left:1ex">
<div class=3D"im">On Fri, 2012-06-08 at 19:15 +0100, Zeinab Alebouyeh wrote=
:<br>
<br>
&gt; Because currently I&#39;m not in lab I don&#39;t know my hypervisor is=
 32b or<br>
&gt; 64 bit.<br>
&gt; I&#39;m working in a security project. for improve security of<br>
&gt; applications running in virtualized environment. I want to use the<br>
&gt; security instruction of AMD SVM named SKINIT.<br>
&gt; because this instruction must run in ring0, I add a hypercall in xen<b=
r>
&gt; and write my codes in my hypercall function.<br>
&gt; The skinit instruction takes the physical address of a block as an<br>
&gt; input operand( in the eax register) and establish a secure execution<b=
r>
&gt; environment for a software component(block)<br>
&gt; I have a label in my hypercall function that is the start of my block.=
<br>
&gt; In order to use skinit I want grab the physical address of my label to=
<br>
&gt; save in eax register.<br>
<br>
</div>Rather than use a label in the current function for this magic block =
you<br>
should use a separate function, either in a .S or a .c file. Then you<br>
can simply use &amp;function_name to get the address and you don&#39;t run =
the<br>
risk of accidentally falling through into the special code from the<br>
non-skinit context etc.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div>Thanks for your guidance,<br>you means tha=
t if I use a function, &amp;function_name gives me the physical address of =
function or the virtual address of function?<br>

--0016e6dee8faf1b67c04c270c89f--


--===============0245373102767356042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0245373102767356042==--


From xen-devel-bounces@lists.xen.org Thu Jun 14 15:59:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 15:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfCSL-0006T5-Fm; Thu, 14 Jun 2012 15:59:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <z.alebouyeh@gmail.com>) id 1SfCSK-0006Sm-2w
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 15:59:32 +0000
Received: from [85.158.143.99:43851] by server-1.bemta-4.messagelabs.com id
	A0/6B-24392-36A0ADF4; Thu, 14 Jun 2012 15:59:31 +0000
X-Env-Sender: z.alebouyeh@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339689570!27388887!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2991 invoked from network); 14 Jun 2012 15:59:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 15:59:30 -0000
Received: by werf3 with SMTP id f3so1726906wer.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 08:59:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=geSHNt1p9c51iRaPxcvJLs9IpvmT7Fg5GzQC7OKs3rY=;
	b=eGH3Rn0ZLDgwlF6RiEP14Huc7YQniFLdmij6Ek2/sun33GPK3hLOWUjSAzCq77m4St
	tjs2LBnXEaZYo4NTHdI1uT/6ccYhmWc3+cUd+WiRB6L3yHy7p8AImS1JL5Bjik/1ldkf
	Kgro9R9lGartrJTZzKqFyxaFlfKjQazQ07P++OIZ420dmujV7jdQRYVWJldocQHvmO0e
	/l/C1KqWSrMVn5IXRJAE1468mpXIVWmbJ2A3RjaoueP/rCQpXDMkXowD9ze82KrPYl6m
	b4afBLT+EG94LAaEA94iH+s4jgXQIi+cI08UZNmL3a9BgnaGWhaT+EJfraHgrile4b+u
	BFqQ==
MIME-Version: 1.0
Received: by 10.216.226.233 with SMTP id b83mr1238099weq.204.1339689570252;
	Thu, 14 Jun 2012 08:59:30 -0700 (PDT)
Received: by 10.223.70.144 with HTTP; Thu, 14 Jun 2012 08:59:30 -0700 (PDT)
In-Reply-To: <1339491940.24104.8.camel@zakaz.uk.xensource.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
	<CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
	<1339491940.24104.8.camel@zakaz.uk.xensource.com>
Date: Thu, 14 Jun 2012 08:59:30 -0700
Message-ID: <CAE+SDMwQSaDnatuj3uh9Se_E9LbzO8KKX5MNabwHVW2MkDGqFw@mail.gmail.com>
From: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0245373102767356042=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0245373102767356042==
Content-Type: multipart/alternative; boundary=0016e6dee8faf1b67c04c270c89f

--0016e6dee8faf1b67c04c270c89f
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jun 12, 2012 at 2:05 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Fri, 2012-06-08 at 19:15 +0100, Zeinab Alebouyeh wrote:
>
> > Because currently I'm not in lab I don't know my hypervisor is 32b or
> > 64 bit.
> > I'm working in a security project. for improve security of
> > applications running in virtualized environment. I want to use the
> > security instruction of AMD SVM named SKINIT.
> > because this instruction must run in ring0, I add a hypercall in xen
> > and write my codes in my hypercall function.
> > The skinit instruction takes the physical address of a block as an
> > input operand( in the eax register) and establish a secure execution
> > environment for a software component(block)
> > I have a label in my hypercall function that is the start of my block.
> > In order to use skinit I want grab the physical address of my label to
> > save in eax register.
>
> Rather than use a label in the current function for this magic block you
> should use a separate function, either in a .S or a .c file. Then you
> can simply use &function_name to get the address and you don't run the
> risk of accidentally falling through into the special code from the
> non-skinit context etc.
>
> Ian.
>
> Thanks for your guidance,
you means that if I use a function, &function_name gives me the physical
address of function or the virtual address of function?

--0016e6dee8faf1b67c04c270c89f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Jun 12, 2012 at 2:05 AM, Ian Cam=
pbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" targ=
et=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:1px #ccc solid=
;padding-left:1ex">
<div class=3D"im">On Fri, 2012-06-08 at 19:15 +0100, Zeinab Alebouyeh wrote=
:<br>
<br>
&gt; Because currently I&#39;m not in lab I don&#39;t know my hypervisor is=
 32b or<br>
&gt; 64 bit.<br>
&gt; I&#39;m working in a security project. for improve security of<br>
&gt; applications running in virtualized environment. I want to use the<br>
&gt; security instruction of AMD SVM named SKINIT.<br>
&gt; because this instruction must run in ring0, I add a hypercall in xen<b=
r>
&gt; and write my codes in my hypercall function.<br>
&gt; The skinit instruction takes the physical address of a block as an<br>
&gt; input operand( in the eax register) and establish a secure execution<b=
r>
&gt; environment for a software component(block)<br>
&gt; I have a label in my hypercall function that is the start of my block.=
<br>
&gt; In order to use skinit I want grab the physical address of my label to=
<br>
&gt; save in eax register.<br>
<br>
</div>Rather than use a label in the current function for this magic block =
you<br>
should use a separate function, either in a .S or a .c file. Then you<br>
can simply use &amp;function_name to get the address and you don&#39;t run =
the<br>
risk of accidentally falling through into the special code from the<br>
non-skinit context etc.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div>Thanks for your guidance,<br>you means tha=
t if I use a function, &amp;function_name gives me the physical address of =
function or the virtual address of function?<br>

--0016e6dee8faf1b67c04c270c89f--


--===============0245373102767356042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0245373102767356042==--


From xen-devel-bounces@lists.xen.org Thu Jun 14 16:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1SfCUR-00077u-1r; Thu, 14 Jun 2012 16:01:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfCUP-00077l-OF
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:01:41 +0000
Received: from [85.158.139.83:39482] by server-12.bemta-5.messagelabs.com id
	DA/4E-25233-4EA0ADF4; Thu, 14 Jun 2012 16:01:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339689699!27714708!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26317 invoked from network); 14 Jun 2012 16:01:40 -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;
	14 Jun 2012 16:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28101800"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 12:01:38 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 12:01:38 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfCUL-0004Oi-W7;
	Thu, 14 Jun 2012 17:01:38 +0100
Message-ID: <4FDA0AE1.4010602@citrix.com>
Date: Thu, 14 Jun 2012 17:01:37 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
	<4FDA0185.5050903@siemens.com>
In-Reply-To: <4FDA0185.5050903@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 14/06/12 16:21, Jan Kiszka wrote:
>> Is this patch would be a good common property?
>>
>> It's probably close to the patch you send earlier Jan.
>>
>> If it's good, I'll resend my passthrough patch series with this patch.
> Looks generally OK to me, let's try to move forward with this. Please
> fix the coding style issues before sending.

I fix the patch a resend the series.

Thanks,

-- 
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 Jun 14 16:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 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 1SfCUR-00077u-1r; Thu, 14 Jun 2012 16:01:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfCUP-00077l-OF
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:01:41 +0000
Received: from [85.158.139.83:39482] by server-12.bemta-5.messagelabs.com id
	DA/4E-25233-4EA0ADF4; Thu, 14 Jun 2012 16:01:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339689699!27714708!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26317 invoked from network); 14 Jun 2012 16:01:40 -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;
	14 Jun 2012 16:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28101800"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 12:01:38 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 12:01:38 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfCUL-0004Oi-W7;
	Thu, 14 Jun 2012 17:01:38 +0100
Message-ID: <4FDA0AE1.4010602@citrix.com>
Date: Thu, 14 Jun 2012 17:01:37 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
	<4FDA0185.5050903@siemens.com>
In-Reply-To: <4FDA0185.5050903@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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-Transfer-Encoding: 7bit
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 14/06/12 16:21, Jan Kiszka wrote:
>> Is this patch would be a good common property?
>>
>> It's probably close to the patch you send earlier Jan.
>>
>> If it's good, I'll resend my passthrough patch series with this patch.
> Looks generally OK to me, let's try to move forward with this. Please
> fix the coding style issues before sending.

I fix the patch a resend the series.

Thanks,

-- 
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 Jun 14 16:37:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfD2S-0007ih-9H; Thu, 14 Jun 2012 16:36:52 +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 1SfD2R-0007ic-Eu
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:36:51 +0000
Received: from [193.109.254.147:35317] by server-11.bemta-14.messagelabs.com
	id 6B/25-02727-2231ADF4; Thu, 14 Jun 2012 16:36:50 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339691809!2916690!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18983 invoked from network); 14 Jun 2012 16:36:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	14 Jun 2012 16:36:49 -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 q5EFTgxG022087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 11:29:42 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EFTcJA014087; Thu, 14 Jun 2012 11:29:40 -0400
Date: Thu, 14 Jun 2012 18:30:15 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614153014.GB18618@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9F789.5070300@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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, Jun 14, 2012 at 03:39:05PM +0100, Anthony PERARD wrote:
> On 13/06/12 13:48, Jan Kiszka wrote:
> >>>>>  Will you be able to use an address parser via some device property?
> >>>
> >>>  Yes. Actually, the address is already a device property.
> >>>
> >Great. Then we should try to come up with a common pci-host-devaddr
> >property everyone can use.
> 
> Is this patch would be a good common property?
> 
> It's probably close to the patch you send earlier Jan.
> 
> If it's good, I'll resend my passthrough patch series with this patch.
> 
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index b7b5597..9c7a271 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
>      .max   = 65024,
>  };
> 
> +/* --- pci host address --- */
> +
> +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    char buffer[4 + 2 + 2 + 2 + 1];

One trick is this:
    char buffer[] = "XXXX:XX:XX.X";

And comparing with the above, your buffer looks too short, doesn't it?


> +    char *p = buffer;
> +
> +    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
> +             addr->domain, addr->bus, addr->slot, addr->function);

A good idea might be to check the return code. assert(ret <= sizeof buf).

> +
> +    visit_type_str(v, &p, name, errp);
> +}
> +
> +/*
> + * Parse [<domain>:]<bus>:<slot>.<func>
> + *   if <domain> is not supplied, it's assumed to be 0.
> + */
> +static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    Error *local_err = NULL;
> +    char *str, *p;
> +    char *e;
> +    unsigned long val;
> +    unsigned long dom = 0, bus = 0;
> +    unsigned int slot = 0, func = 0;
> +
> +    if (dev->state != DEV_STATE_CREATED) {
> +        error_set(errp, QERR_PERMISSION_DENIED);
> +        return;
> +    }
> +
> +    visit_type_str(v, &str, name, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        return;
> +    }
> +
> +    p = str;
> +    val = strtoul(p, &e, 16);
> +    if (e == p || *e != ':')
> +        goto inval;
> +    bus = val;
> +
> +    p = e + 1;
> +    val = strtoul(p, &e, 16);
> +    if (e == p)
> +        goto inval;
> +    if (*e == ':') {
> +        dom = bus;
> +        bus = val;
> +        p = e + 1;
> +        val = strtoul(p, &e, 16);
> +        if (e == p)
> +            goto inval;
> +    }
> +    slot = val;
> +
> +    if (*e != '.')
> +        goto inval;
> +    p = e + 1;
> +    val = strtoul(p, &e, 10);
> +    if (e == p)
> +        goto inval;
> +    func = val;
> +
> +    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7)
> +        goto inval;
> +
> +    if (*e)
> +        goto inval;
> +
> +    addr->domain = dom;
> +    addr->bus = bus;
> +    addr->slot = slot;
> +    addr->function = func;
> +
> +    g_free(str);
> +    return;
> +
> +inval:
> +    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +    g_free(str);
> +}
> +
> +PropertyInfo qdev_prop_pci_host_devaddr = {
> +    .name = "pci-host-devaddr",
> +    .get = get_pci_host_devaddr,
> +    .set = set_pci_host_devaddr,
> +};
> +
>  /* --- public helpers --- */
> 
>  static Property *qdev_prop_walk(Property *props, const char *name)
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 4e90119..9a54ebe 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -225,6 +225,7 @@ extern PropertyInfo qdev_prop_netdev;
>  extern PropertyInfo qdev_prop_vlan;
>  extern PropertyInfo qdev_prop_pci_devfn;
>  extern PropertyInfo qdev_prop_blocksize;
> +extern PropertyInfo qdev_prop_pci_host_devaddr;
> 
>  #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
>          .name      = (_name),                                    \
> @@ -288,6 +289,8 @@ extern PropertyInfo qdev_prop_blocksize;
>                          LostTickPolicy)
>  #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
>      DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
> +#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
> +    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr,
> PCIHostDeviceAddress)
> 
>  #define DEFINE_PROP_END_OF_LIST()               \
>      {}
> diff --git a/qemu-common.h b/qemu-common.h
> index 91e0562..0d6e51c 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
>      LOST_TICK_MAX
>  } LostTickPolicy;
> 
> +typedef struct PCIHostDeviceAddress {
> +    unsigned int domain;
> +    unsigned int bus;
> +    unsigned int slot;
> +    unsigned int function;
> +} PCIHostDeviceAddress;
> +
>  void tcg_exec_init(unsigned long tb_size);
>  bool tcg_enabled(void);
> 
> 
> -- 
> 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 Jun 14 16:37:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfD2S-0007ih-9H; Thu, 14 Jun 2012 16:36:52 +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 1SfD2R-0007ic-Eu
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:36:51 +0000
Received: from [193.109.254.147:35317] by server-11.bemta-14.messagelabs.com
	id 6B/25-02727-2231ADF4; Thu, 14 Jun 2012 16:36:50 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339691809!2916690!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18983 invoked from network); 14 Jun 2012 16:36:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	14 Jun 2012 16:36:49 -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 q5EFTgxG022087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 11:29:42 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EFTcJA014087; Thu, 14 Jun 2012 11:29:40 -0400
Date: Thu, 14 Jun 2012 18:30:15 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614153014.GB18618@redhat.com>
References: <1339513523-1699-1-git-send-email-anthony.perard@citrix.com>
	<1339513523-1699-6-git-send-email-anthony.perard@citrix.com>
	<20120612151557.GA10691@redhat.com> <4FD8764B.9060003@siemens.com>
	<alpine.DEB.2.02.1206131219010.14957@kaball.uk.xensource.com>
	<4FD880D3.8090203@siemens.com> <4FD88A33.1080304@citrix.com>
	<4FD88C0D.10304@siemens.com> <4FD9F789.5070300@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9F789.5070300@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V12 5/9] Revert "pci: don't export an
	internal 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, Jun 14, 2012 at 03:39:05PM +0100, Anthony PERARD wrote:
> On 13/06/12 13:48, Jan Kiszka wrote:
> >>>>>  Will you be able to use an address parser via some device property?
> >>>
> >>>  Yes. Actually, the address is already a device property.
> >>>
> >Great. Then we should try to come up with a common pci-host-devaddr
> >property everyone can use.
> 
> Is this patch would be a good common property?
> 
> It's probably close to the patch you send earlier Jan.
> 
> If it's good, I'll resend my passthrough patch series with this patch.
> 
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index b7b5597..9c7a271 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -928,6 +928,104 @@ PropertyInfo qdev_prop_blocksize = {
>      .max   = 65024,
>  };
> 
> +/* --- pci host address --- */
> +
> +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    char buffer[4 + 2 + 2 + 2 + 1];

One trick is this:
    char buffer[] = "XXXX:XX:XX.X";

And comparing with the above, your buffer looks too short, doesn't it?


> +    char *p = buffer;
> +
> +    snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
> +             addr->domain, addr->bus, addr->slot, addr->function);

A good idea might be to check the return code. assert(ret <= sizeof buf).

> +
> +    visit_type_str(v, &p, name, errp);
> +}
> +
> +/*
> + * Parse [<domain>:]<bus>:<slot>.<func>
> + *   if <domain> is not supplied, it's assumed to be 0.
> + */
> +static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    Error *local_err = NULL;
> +    char *str, *p;
> +    char *e;
> +    unsigned long val;
> +    unsigned long dom = 0, bus = 0;
> +    unsigned int slot = 0, func = 0;
> +
> +    if (dev->state != DEV_STATE_CREATED) {
> +        error_set(errp, QERR_PERMISSION_DENIED);
> +        return;
> +    }
> +
> +    visit_type_str(v, &str, name, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        return;
> +    }
> +
> +    p = str;
> +    val = strtoul(p, &e, 16);
> +    if (e == p || *e != ':')
> +        goto inval;
> +    bus = val;
> +
> +    p = e + 1;
> +    val = strtoul(p, &e, 16);
> +    if (e == p)
> +        goto inval;
> +    if (*e == ':') {
> +        dom = bus;
> +        bus = val;
> +        p = e + 1;
> +        val = strtoul(p, &e, 16);
> +        if (e == p)
> +            goto inval;
> +    }
> +    slot = val;
> +
> +    if (*e != '.')
> +        goto inval;
> +    p = e + 1;
> +    val = strtoul(p, &e, 10);
> +    if (e == p)
> +        goto inval;
> +    func = val;
> +
> +    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7)
> +        goto inval;
> +
> +    if (*e)
> +        goto inval;
> +
> +    addr->domain = dom;
> +    addr->bus = bus;
> +    addr->slot = slot;
> +    addr->function = func;
> +
> +    g_free(str);
> +    return;
> +
> +inval:
> +    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +    g_free(str);
> +}
> +
> +PropertyInfo qdev_prop_pci_host_devaddr = {
> +    .name = "pci-host-devaddr",
> +    .get = get_pci_host_devaddr,
> +    .set = set_pci_host_devaddr,
> +};
> +
>  /* --- public helpers --- */
> 
>  static Property *qdev_prop_walk(Property *props, const char *name)
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 4e90119..9a54ebe 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -225,6 +225,7 @@ extern PropertyInfo qdev_prop_netdev;
>  extern PropertyInfo qdev_prop_vlan;
>  extern PropertyInfo qdev_prop_pci_devfn;
>  extern PropertyInfo qdev_prop_blocksize;
> +extern PropertyInfo qdev_prop_pci_host_devaddr;
> 
>  #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
>          .name      = (_name),                                    \
> @@ -288,6 +289,8 @@ extern PropertyInfo qdev_prop_blocksize;
>                          LostTickPolicy)
>  #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
>      DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
> +#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
> +    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr,
> PCIHostDeviceAddress)
> 
>  #define DEFINE_PROP_END_OF_LIST()               \
>      {}
> diff --git a/qemu-common.h b/qemu-common.h
> index 91e0562..0d6e51c 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
>      LOST_TICK_MAX
>  } LostTickPolicy;
> 
> +typedef struct PCIHostDeviceAddress {
> +    unsigned int domain;
> +    unsigned int bus;
> +    unsigned int slot;
> +    unsigned int function;
> +} PCIHostDeviceAddress;
> +
>  void tcg_exec_init(unsigned long tb_size);
>  bool tcg_enabled(void);
> 
> 
> -- 
> 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 Jun 14 16:39:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16:39: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 1SfD4c-0007ol-Qh; Thu, 14 Jun 2012 16:39:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SfD4a-0007oY-QE
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 16:39:05 +0000
Received: from [85.158.138.51:48599] by server-9.bemta-3.messagelabs.com id
	0E/11-10419-7A31ADF4; Thu, 14 Jun 2012 16:39:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339691942!21348754!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27353 invoked from network); 14 Jun 2012 16:39:03 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:39:03 -0000
Received: by qcsp15 with SMTP id p15so1544026qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 09:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=LfmE84IfHW+bm7aF59wd9AonUlVQ/Dz7m2xjxm4UrT8=;
	b=WjcuIRMSjo6ekuzx4TbcfVnm7sT3SFTM72sUadMnd+717QGlFh86NDEE9E74VtWnhD
	ZclOpdTHov2eeu2ndQTJM4OAAjVI/+y0yCFar92jaUiEaUseYDiCp8CTGQ4+6yyBeyqR
	JD5OQjKzIE54SsRy89BMmoHh37OC3O2uIhgQWbJqpYC83iKxbfjNbyF1ZjF4qBA8WgHy
	iHf2XAw0BS3zYIOp3iOXmu+bl1ASVpgwXg3OM8K7hyqNR8nyb01dwAaPGzCSV/Z0seYG
	aFlYHUcr2NelhRHLjjuUZUyueh/A2dElX3jXCGBGo9d/XVLQNfS/W/NvrDswPnhZQlLz
	5QZw==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr5478933qae.26.1339691941950; Thu,
	14 Jun 2012 09:39:01 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 14 Jun 2012 09:39:01 -0700 (PDT)
In-Reply-To: <4FD9FCAF.4050002@eu.citrix.com>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
	<4FD9FCAF.4050002@eu.citrix.com>
Date: Thu, 14 Jun 2012 17:39:01 +0100
X-Google-Sender-Auth: A0GEOz6Edx-tTYqTrsPxreBb_Mo
Message-ID: <CAFLBxZZUJpQ7B0+TwxBFSyLSVLr2kJLnBc-9OH6SgpQWJMPKug@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
 p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 14, 2012 at 4:01 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 14/06/12 11:21, Tim Deegan wrote:
>>
>> At 12:54 +0100 on 08 Jun (1339160091), George Dunlap wrote:
>>>
>>> Return the p2m level of the entry which filled this request.
>>> Intended to be used to see if pages returned by the balloon
>>> driver are part of a superpage, and reclaim them if so.
>>
>> This looks broadly correct, but it's a bit invasive. =A0If there's any w=
ay
>> to rework patch 2 not to need it that would be helpful. =A0It looks like
>> the main use is for detecting and removing superpage PoD entries; maybe
>> that could be done with a sweep like you have in the non-PoD case?
>
> You mean the non-balloon case? =A0I forget why I thought that was a bad i=
dea,
> exactly. =A0Let me think about that.

I think I basically didn't want to have to do the full check of each
of the 512 individual entries of the p2m in the case that it wasn't,
in fact, a superpage; but I think in the common case it should either
be a full superpage, or the check at the beginning of
p2m_pod_zero_check_superpage() should fail out relatively early.  So
we could probably get away without it.

Why don't I re-write patch 2 of this series to not require patch 1,
and include it in my other series.  If there's a performance gain to
be had by avoiding the check, we can discuss that post-4.2.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:39:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16:39: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 1SfD4c-0007ol-Qh; Thu, 14 Jun 2012 16:39:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SfD4a-0007oY-QE
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 16:39:05 +0000
Received: from [85.158.138.51:48599] by server-9.bemta-3.messagelabs.com id
	0E/11-10419-7A31ADF4; Thu, 14 Jun 2012 16:39:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339691942!21348754!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27353 invoked from network); 14 Jun 2012 16:39:03 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:39:03 -0000
Received: by qcsp15 with SMTP id p15so1544026qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Jun 2012 09:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=LfmE84IfHW+bm7aF59wd9AonUlVQ/Dz7m2xjxm4UrT8=;
	b=WjcuIRMSjo6ekuzx4TbcfVnm7sT3SFTM72sUadMnd+717QGlFh86NDEE9E74VtWnhD
	ZclOpdTHov2eeu2ndQTJM4OAAjVI/+y0yCFar92jaUiEaUseYDiCp8CTGQ4+6yyBeyqR
	JD5OQjKzIE54SsRy89BMmoHh37OC3O2uIhgQWbJqpYC83iKxbfjNbyF1ZjF4qBA8WgHy
	iHf2XAw0BS3zYIOp3iOXmu+bl1ASVpgwXg3OM8K7hyqNR8nyb01dwAaPGzCSV/Z0seYG
	aFlYHUcr2NelhRHLjjuUZUyueh/A2dElX3jXCGBGo9d/XVLQNfS/W/NvrDswPnhZQlLz
	5QZw==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr5478933qae.26.1339691941950; Thu,
	14 Jun 2012 09:39:01 -0700 (PDT)
Received: by 10.229.47.140 with HTTP; Thu, 14 Jun 2012 09:39:01 -0700 (PDT)
In-Reply-To: <4FD9FCAF.4050002@eu.citrix.com>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
	<4FD9FCAF.4050002@eu.citrix.com>
Date: Thu, 14 Jun 2012 17:39:01 +0100
X-Google-Sender-Auth: A0GEOz6Edx-tTYqTrsPxreBb_Mo
Message-ID: <CAFLBxZZUJpQ7B0+TwxBFSyLSVLr2kJLnBc-9OH6SgpQWJMPKug@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
 p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 14, 2012 at 4:01 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 14/06/12 11:21, Tim Deegan wrote:
>>
>> At 12:54 +0100 on 08 Jun (1339160091), George Dunlap wrote:
>>>
>>> Return the p2m level of the entry which filled this request.
>>> Intended to be used to see if pages returned by the balloon
>>> driver are part of a superpage, and reclaim them if so.
>>
>> This looks broadly correct, but it's a bit invasive. =A0If there's any w=
ay
>> to rework patch 2 not to need it that would be helpful. =A0It looks like
>> the main use is for detecting and removing superpage PoD entries; maybe
>> that could be done with a sweep like you have in the non-PoD case?
>
> You mean the non-balloon case? =A0I forget why I thought that was a bad i=
dea,
> exactly. =A0Let me think about that.

I think I basically didn't want to have to do the full check of each
of the 512 individual entries of the p2m in the case that it wasn't,
in fact, a superpage; but I think in the common case it should either
be a full superpage, or the check at the beginning of
p2m_pod_zero_check_superpage() should fail out relatively early.  So
we could probably get away without it.

Why don't I re-write patch 2 of this series to not require patch 1,
and include it in my other series.  If there's a performance gain to
be had by avoiding the check, we can discuss that post-4.2.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfDE7-0008Rg-T6; Thu, 14 Jun 2012 16:48: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 1SfDE6-0008Rb-G5
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:48:54 +0000
Received: from [85.158.143.35:65379] by server-3.bemta-4.messagelabs.com id
	F4/62-05808-5F51ADF4; Thu, 14 Jun 2012 16:48:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339692525!5922841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 14 Jun 2012 16:48:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13029571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 16:48:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 17:48:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDDw-0007MB-N3; Thu, 14 Jun 2012 16:48:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDDw-0006sa-Ki;
	Thu, 14 Jun 2012 17:48:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.5612.626430.387995@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 17:48:44 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339585498.24104.190.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
	<1339585498.24104.190.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a separate process"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > libxenctrl expects to be able to simply run the save or restore
> > operation synchronously.  This won't work well in a process which is
> > trying to handle multiple domains.
...
> > diff --git a/.hgignore b/.hgignore
> > index 27d8f79..05304ea 100644

> >  ^tools/libxl/tmp\..*$
> > +^tools/libxl/.*\.new$
> 
> Our naming scheme for these sorts of temporary files is  rather in
> consistent (including an existing use of .new), oh well...

Hmm, yes.  I took my cue from libxl_list.h, which is immediately before
_libxl_save_msgs_helper.[ch] in the Makefile.

> > +libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
> > +       $(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> 
> The changelog says that libxl-save-helper doesn't link libxenlight but
> it is declared as a dependency here and CFLAGS_libxenlight is included
> in SAVE_HELPER_OBJS' CFLAGS above.

This is a mistake in the Makefile, which I have fixed.

> >  testidl: testidl.o libxlutil.so libxenlight.so
> >         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> [...]
> > @@ -170,6 +184,7 @@ install: all
> >         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
> >         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
> >         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> > +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
> 
> This needs an INSTALL_DIR for $(DESTDIR)$(PRIVATE_BINDIR) to support
> "make -C tools/libxl DESTDIR=xxx install" else:
>         install: cannot create regular file `/tmp/tmplKa0Y7/usr/lib/xen/bin': No such file or directory

OK.  I guess I never do that and it's a bit of a mystery why one
would without having done a more general install before, but it's
clearly a correct change.

> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index b48452c..fea0c94 100644
...
> >  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> > -        uint32_t size, void *data)
...
> > +    libxl_ctx *ctx = CTX;
> 
> Any reason you didn't s/ctx/CTX/ in one of your preparatory patches?

I didn't want to do that unless it was necessary.  There was already
enough else going on.  I don't think having a ctx rather than using
CTX is wrong, although it is slightly less in the modern idiom.

> >  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
> >                             unsigned long vm_generationid_addr)
> >  {
> >      STATE_AO_GC(dss->ao);
> > -    int r;
> > +    int r, rc;
> > +    uint32_t toolstack_data_len;
> > +
> > +    /* Resources we need to free */
> > +    uint8_t *toolstack_data_buf = 0;
> > +
> > +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> > +        (&dss->shs.callbacks.save.a);
> > +
> > +    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
> > +                              &toolstack_data_len, dss);
> 
> This seems to be called twice? I'm looking at the source after the full
> series is applied and I see
>         dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
> in libxl__domain_suspend as well as this call here.

But in fact dss->shs.callbacks.save.toolstack_save is never used
anywhere in that version.  The bug is that libxl__xc_domain_save
should call the callback function (if it is non-null), not call
libxl__toolstack_save directly.

> The callback one seems to be otherwise unused.

Exactly.

I have fixed this:

  * libxl__xc_domain_save uses supplied callback function pointer,
    rather than calling libxl__toolstack_save directly;
    toolstack data save callback is only supplied to libxc if
    in-libxl caller supplied a callback.

> > +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> > +                       const char *mode_arg, int data_fd,
> > +                       const unsigned long *argnums, int num_argnums)
> > +{
...
> > +    libxl__carefd_begin();
> > +    for (i=0; i<2; i++) {
> > +        int fds[2];
> > +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> > +        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
> > +        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);
> 
> Using !i here is clever, but I had to deploy a pen to be sure the
> assignments were all correct.
> 
> Open coding this simple loop would also give you the opportunity the
> have comments like "/* This is the helper processes's stdout */" etc in
> the appropriate place to aid in comprehension when checking the correct
> end of each pipe goes in the right place.

Perhaps the right answer is to use a better variable name than `i'.
I wrote it out longhand and it looked like this:

    libxl__carefd_begin();
    int fds[2];

    /* child's stdin */
    if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
    childs_pipes[0] = libxl__carefd_record(CTX, fds[0]);
    shs->pipes[0] = libxl__carefd_record(CTX, fds[1]);

    /* child's stdout */
    if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
    childs_pipes[1] = libxl__carefd_record(CTX, fds[1]);
    shs->pipes[1] = libxl__carefd_record(CTX, fds[0]);

    libxl__carefd_unlock();

which is a great way to obscure the subtle differences between the two
stanzas.  How about:

    libxl__carefd_begin();
    int childfd;
    for (childfd=0; childfd<2; childfd++) {
        /* Setting up the pipe for the child's fd childfd */
        int fds[2];
        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
    }
    libxl__carefd_unlock();

?

> > +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> > +                                   int fd, short events, short revents)
> > +{
> > +    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
> > +    STATE_AO_GC(shs->ao);
> > +    int rc, errnoval;
> > +
> > +    if (revents & POLLPRI) {
> > +        LOG(ERROR, "%s signaled POLLERR", shs->stdout_what);
> 
>                           signalled ?
> 
> (it's not impossible that my spell checker is wrong, google seem to
> think both are ok)

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html

uses "signaled".

> The if says POLLPRI but the log says POLLERR?

This should check and log both.

> > +        rc = ERROR_FAIL;
> > + out:
> > +        /* this is here because otherwise we bypass the decl of msg[] */
> 
> I don't get this comment, why can't "out:" be in the normal place after
> the non-error return?

Because it is not legal to "goto" within the scope of a variable whose
size is not a constant.  The alternative would be to introduce a block
scope starting before `unsigned char msg[msglen]' and ending after
`return'.

Arguably msg[msglen] is asking too much (up to 64K) of the caller's
stack.  Should I change it ?

> > +    if (!shs->completed) {
> > +        if (!shs->rc)
> > +            LOG(ERROR,"%s exited without signaling completion",what);
> 
>                                             signalling again, same caveat

I'll go with what SuS says.

> > --- /dev/null
> > +++ b/tools/libxl/libxl_save_helper.c
> > @@ -0,0 +1,279 @@
> > +/*
> > + * Copyright (C) 2012      Citrix Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU Lesser General Public License as published
> > + * by the Free Software Foundation; version 2.1 only. with the special
> > + * exception on linking described in file LICENSE.
> 
> LGPL, or perhaps GPL since this is a helper?
> 
> (I suppose the same argument could be made for xl itself)

I can see no reason to deviate from the licence of the rest of libxl.
If nothing else, code may move between the helper and libxl proper.

> > +int helper_getreply(void *user)
> > +{
> > +    int v;
> > +    int r = read_exactly(0, &v, sizeof(v));
> > +    if (r<=0) exit(-2);
> 
> You use -1 a lot but here you use -2, are we supposed to be able to
> infer something from the specific error code?

Not really.  I used -1 for general system call failures.  This
particular situation might include a protocol error by the parent,
though, so I thought I'd distinguish it.  That way if you get a
message saying the helper exited with a nonzero exit status foobar you
get slightly more information.

I could make this more formal and be more consistent with these exit
statuses, or alternatively I could abolish it.  I don't think it's
critical - nothing turns on this exit status.

> > diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> > new file mode 100755
> > index 0000000..cd0837e
> > --- /dev/null
> > +++ b/tools/libxl/libxl_save_msgs_gen.pl
> > @@ -0,0 +1,393 @@
> > +#!/usr/bin/perl -w
> > +
> > +use warnings;
> > +use strict;
> > +use POSIX;
> > +
> > +our $debug = 0; # produce copius debugging output at run-time?
> 
>                              copious
> 
> (which is probably the most useful feedback you are going to get from me
> on a Perl script ;-))

Fixed.

> > +foreach my $ah (qw(callout helper)) {
> > +    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
> [...]
> > +END
> [...]
> > +END
> [...]
> > +END
> 
> I think I can infer what this does, but wow ;-)

Following a suggestion from Mark Wooding I have changed this to:

          <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
  #include "libxl_osdeps.h"

  #include <assert.h>
  #include <string.h>
  #include <stdint.h>
  #include <limits.h>
  END_BOTH

  #include "libxl_internal.h"

  END_CALLOUT

  #include "_libxl_save_msgs_${ah}.h"
  #include <xenctrl.h>
  #include <xenguest.h>

  END_HELPER

which I think is much clearer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfDE7-0008Rg-T6; Thu, 14 Jun 2012 16:48: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 1SfDE6-0008Rb-G5
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:48:54 +0000
Received: from [85.158.143.35:65379] by server-3.bemta-4.messagelabs.com id
	F4/62-05808-5F51ADF4; Thu, 14 Jun 2012 16:48:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339692525!5922841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 14 Jun 2012 16:48:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13029571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 16:48:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 17:48:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDDw-0007MB-N3; Thu, 14 Jun 2012 16:48:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDDw-0006sa-Ki;
	Thu, 14 Jun 2012 17:48:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.5612.626430.387995@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 17:48:44 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339585498.24104.190.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
	<1339585498.24104.190.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a separate process"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > libxenctrl expects to be able to simply run the save or restore
> > operation synchronously.  This won't work well in a process which is
> > trying to handle multiple domains.
...
> > diff --git a/.hgignore b/.hgignore
> > index 27d8f79..05304ea 100644

> >  ^tools/libxl/tmp\..*$
> > +^tools/libxl/.*\.new$
> 
> Our naming scheme for these sorts of temporary files is  rather in
> consistent (including an existing use of .new), oh well...

Hmm, yes.  I took my cue from libxl_list.h, which is immediately before
_libxl_save_msgs_helper.[ch] in the Makefile.

> > +libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
> > +       $(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> 
> The changelog says that libxl-save-helper doesn't link libxenlight but
> it is declared as a dependency here and CFLAGS_libxenlight is included
> in SAVE_HELPER_OBJS' CFLAGS above.

This is a mistake in the Makefile, which I have fixed.

> >  testidl: testidl.o libxlutil.so libxenlight.so
> >         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> [...]
> > @@ -170,6 +184,7 @@ install: all
> >         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
> >         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
> >         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> > +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
> 
> This needs an INSTALL_DIR for $(DESTDIR)$(PRIVATE_BINDIR) to support
> "make -C tools/libxl DESTDIR=xxx install" else:
>         install: cannot create regular file `/tmp/tmplKa0Y7/usr/lib/xen/bin': No such file or directory

OK.  I guess I never do that and it's a bit of a mystery why one
would without having done a more general install before, but it's
clearly a correct change.

> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index b48452c..fea0c94 100644
...
> >  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> > -        uint32_t size, void *data)
...
> > +    libxl_ctx *ctx = CTX;
> 
> Any reason you didn't s/ctx/CTX/ in one of your preparatory patches?

I didn't want to do that unless it was necessary.  There was already
enough else going on.  I don't think having a ctx rather than using
CTX is wrong, although it is slightly less in the modern idiom.

> >  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
> >                             unsigned long vm_generationid_addr)
> >  {
> >      STATE_AO_GC(dss->ao);
> > -    int r;
> > +    int r, rc;
> > +    uint32_t toolstack_data_len;
> > +
> > +    /* Resources we need to free */
> > +    uint8_t *toolstack_data_buf = 0;
> > +
> > +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> > +        (&dss->shs.callbacks.save.a);
> > +
> > +    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
> > +                              &toolstack_data_len, dss);
> 
> This seems to be called twice? I'm looking at the source after the full
> series is applied and I see
>         dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
> in libxl__domain_suspend as well as this call here.

But in fact dss->shs.callbacks.save.toolstack_save is never used
anywhere in that version.  The bug is that libxl__xc_domain_save
should call the callback function (if it is non-null), not call
libxl__toolstack_save directly.

> The callback one seems to be otherwise unused.

Exactly.

I have fixed this:

  * libxl__xc_domain_save uses supplied callback function pointer,
    rather than calling libxl__toolstack_save directly;
    toolstack data save callback is only supplied to libxc if
    in-libxl caller supplied a callback.

> > +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> > +                       const char *mode_arg, int data_fd,
> > +                       const unsigned long *argnums, int num_argnums)
> > +{
...
> > +    libxl__carefd_begin();
> > +    for (i=0; i<2; i++) {
> > +        int fds[2];
> > +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> > +        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
> > +        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);
> 
> Using !i here is clever, but I had to deploy a pen to be sure the
> assignments were all correct.
> 
> Open coding this simple loop would also give you the opportunity the
> have comments like "/* This is the helper processes's stdout */" etc in
> the appropriate place to aid in comprehension when checking the correct
> end of each pipe goes in the right place.

Perhaps the right answer is to use a better variable name than `i'.
I wrote it out longhand and it looked like this:

    libxl__carefd_begin();
    int fds[2];

    /* child's stdin */
    if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
    childs_pipes[0] = libxl__carefd_record(CTX, fds[0]);
    shs->pipes[0] = libxl__carefd_record(CTX, fds[1]);

    /* child's stdout */
    if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
    childs_pipes[1] = libxl__carefd_record(CTX, fds[1]);
    shs->pipes[1] = libxl__carefd_record(CTX, fds[0]);

    libxl__carefd_unlock();

which is a great way to obscure the subtle differences between the two
stanzas.  How about:

    libxl__carefd_begin();
    int childfd;
    for (childfd=0; childfd<2; childfd++) {
        /* Setting up the pipe for the child's fd childfd */
        int fds[2];
        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
    }
    libxl__carefd_unlock();

?

> > +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> > +                                   int fd, short events, short revents)
> > +{
> > +    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
> > +    STATE_AO_GC(shs->ao);
> > +    int rc, errnoval;
> > +
> > +    if (revents & POLLPRI) {
> > +        LOG(ERROR, "%s signaled POLLERR", shs->stdout_what);
> 
>                           signalled ?
> 
> (it's not impossible that my spell checker is wrong, google seem to
> think both are ok)

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html

uses "signaled".

> The if says POLLPRI but the log says POLLERR?

This should check and log both.

> > +        rc = ERROR_FAIL;
> > + out:
> > +        /* this is here because otherwise we bypass the decl of msg[] */
> 
> I don't get this comment, why can't "out:" be in the normal place after
> the non-error return?

Because it is not legal to "goto" within the scope of a variable whose
size is not a constant.  The alternative would be to introduce a block
scope starting before `unsigned char msg[msglen]' and ending after
`return'.

Arguably msg[msglen] is asking too much (up to 64K) of the caller's
stack.  Should I change it ?

> > +    if (!shs->completed) {
> > +        if (!shs->rc)
> > +            LOG(ERROR,"%s exited without signaling completion",what);
> 
>                                             signalling again, same caveat

I'll go with what SuS says.

> > --- /dev/null
> > +++ b/tools/libxl/libxl_save_helper.c
> > @@ -0,0 +1,279 @@
> > +/*
> > + * Copyright (C) 2012      Citrix Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU Lesser General Public License as published
> > + * by the Free Software Foundation; version 2.1 only. with the special
> > + * exception on linking described in file LICENSE.
> 
> LGPL, or perhaps GPL since this is a helper?
> 
> (I suppose the same argument could be made for xl itself)

I can see no reason to deviate from the licence of the rest of libxl.
If nothing else, code may move between the helper and libxl proper.

> > +int helper_getreply(void *user)
> > +{
> > +    int v;
> > +    int r = read_exactly(0, &v, sizeof(v));
> > +    if (r<=0) exit(-2);
> 
> You use -1 a lot but here you use -2, are we supposed to be able to
> infer something from the specific error code?

Not really.  I used -1 for general system call failures.  This
particular situation might include a protocol error by the parent,
though, so I thought I'd distinguish it.  That way if you get a
message saying the helper exited with a nonzero exit status foobar you
get slightly more information.

I could make this more formal and be more consistent with these exit
statuses, or alternatively I could abolish it.  I don't think it's
critical - nothing turns on this exit status.

> > diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> > new file mode 100755
> > index 0000000..cd0837e
> > --- /dev/null
> > +++ b/tools/libxl/libxl_save_msgs_gen.pl
> > @@ -0,0 +1,393 @@
> > +#!/usr/bin/perl -w
> > +
> > +use warnings;
> > +use strict;
> > +use POSIX;
> > +
> > +our $debug = 0; # produce copius debugging output at run-time?
> 
>                              copious
> 
> (which is probably the most useful feedback you are going to get from me
> on a Perl script ;-))

Fixed.

> > +foreach my $ah (qw(callout helper)) {
> > +    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
> [...]
> > +END
> [...]
> > +END
> [...]
> > +END
> 
> I think I can infer what this does, but wow ;-)

Following a suggestion from Mark Wooding I have changed this to:

          <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
  #include "libxl_osdeps.h"

  #include <assert.h>
  #include <string.h>
  #include <stdint.h>
  #include <limits.h>
  END_BOTH

  #include "libxl_internal.h"

  END_CALLOUT

  #include "_libxl_save_msgs_${ah}.h"
  #include <xenctrl.h>
  #include <xenguest.h>

  END_HELPER

which I think is much clearer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfDLw-0000Bf-1T; Thu, 14 Jun 2012 16:57:00 +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 1SfDLu-0000Ba-8i
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 16:56:58 +0000
Received: from [85.158.138.51:44342] by server-12.bemta-3.messagelabs.com id
	BE/36-30206-9D71ADF4; Thu, 14 Jun 2012 16:56:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1339693015!19536272!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg4Mzky\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20176 invoked from network); 14 Jun 2012 16:56:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 16:56:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EGupt7014344
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 16:56:51 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
	q5EGuoHJ000897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 16:56:50 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
	q5EGunhU023725; Thu, 14 Jun 2012 11:56:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 09:56:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 437DA40290; Thu, 14 Jun 2012 12:49:26 -0400 (EDT)
Date: Thu, 14 Jun 2012 12:49:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120614164926.GC333@phenom.dumpdata.com>
References: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
	<4FD9FAA3.6090303@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9FAA3.6090303@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if
 they haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 03:52:19PM +0100, David Vrabel wrote:
> On 07/06/12 18:01, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > When switching tasks in a Xen PV guest, avoid updating the TLS
> > descriptors if they haven't changed.  This improves the speed of
> > context switches by almost 10% as much of the time the descriptors are
> > the same or only one is different.
> > 
> > The descriptors written into the GDT by Xen are modified from the
> > values passed in the update_descriptor hypercall so we keep shadow
> > copies of the three TLS descriptors to compare against.
> > 
> > lmbench3 test     Before  After  Improvement
> > --------------------------------------------
> > lat_ctx -s 32 24   7.19    6.52  9%
> > lat_pipe          12.56   11.66  7%
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > ---
> > I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
> > in desc_struct as deprecated but there seems to be no suitable
> > alternatives.
> 
> ping?  Any opinion on this patch from the x86 side?  If it's okay can we
> get an ack so Konrad can take the patch via his tree.

It breaks my all my bootup tests - so NACK until at least that is fixed.
I think I sent you the whole serial log - is there something else that would help
narrow it down?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfDLw-0000Bf-1T; Thu, 14 Jun 2012 16:57:00 +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 1SfDLu-0000Ba-8i
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 16:56:58 +0000
Received: from [85.158.138.51:44342] by server-12.bemta-3.messagelabs.com id
	BE/36-30206-9D71ADF4; Thu, 14 Jun 2012 16:56:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1339693015!19536272!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg4Mzky\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20176 invoked from network); 14 Jun 2012 16:56:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 16:56:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EGupt7014344
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 16:56:51 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
	q5EGuoHJ000897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 16:56:50 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
	q5EGunhU023725; Thu, 14 Jun 2012 11:56:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 09:56:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 437DA40290; Thu, 14 Jun 2012 12:49:26 -0400 (EDT)
Date: Thu, 14 Jun 2012 12:49:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120614164926.GC333@phenom.dumpdata.com>
References: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
	<4FD9FAA3.6090303@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9FAA3.6090303@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if
 they haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 03:52:19PM +0100, David Vrabel wrote:
> On 07/06/12 18:01, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > When switching tasks in a Xen PV guest, avoid updating the TLS
> > descriptors if they haven't changed.  This improves the speed of
> > context switches by almost 10% as much of the time the descriptors are
> > the same or only one is different.
> > 
> > The descriptors written into the GDT by Xen are modified from the
> > values passed in the update_descriptor hypercall so we keep shadow
> > copies of the three TLS descriptors to compare against.
> > 
> > lmbench3 test     Before  After  Improvement
> > --------------------------------------------
> > lat_ctx -s 32 24   7.19    6.52  9%
> > lat_pipe          12.56   11.66  7%
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > ---
> > I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
> > in desc_struct as deprecated but there seems to be no suitable
> > alternatives.
> 
> ping?  Any opinion on this patch from the x86 side?  If it's okay can we
> get an ack so Konrad can take the patch via his tree.

It breaks my all my bootup tests - so NACK until at least that is fixed.
I think I sent you the whole serial log - is there something else that would help
narrow it down?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfDNJ-0000Hm-Gj; Thu, 14 Jun 2012 16:58: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 1SfDNI-0000Hf-Gk
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:58:24 +0000
Received: from [193.109.254.147:61427] by server-2.bemta-14.messagelabs.com id
	55/1D-27740-F281ADF4; Thu, 14 Jun 2012 16:58:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339693103!2092284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20079 invoked from network); 14 Jun 2012 16:58:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13029742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 16:53:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 17:53:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDIN-0007Nt-UV; Thu, 14 Jun 2012 16:53:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDIN-000715-TJ;
	Thu, 14 Jun 2012 17:53:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.5887.893166.341739@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 17:53:19 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339586159.24104.193.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
	<1339586159.24104.193.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/19] libxl: provide libxl__xs_*_checked
 and libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 07/19] libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > These useful utility functions make dealing with xenstore a little
> > less painful.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> (minor observation and a typo below)
...
> > +int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
> > +                            const char *path, const char *string);
> 
> I suppose in the future we might consider merging this with
> libxl__xs_write -- there's no reason not to always log a failed write,
> is there?

Maybe.  It might fail due to EPERM and there might be another strategy
the caller might have available.  Although this is rare enough that
perhaps such callers should use raw xs calls.

Arguably the same applies to read.

> > + *    0  commited successfully
> 
>            committed

Fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16: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 1SfDNJ-0000Hm-Gj; Thu, 14 Jun 2012 16:58: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 1SfDNI-0000Hf-Gk
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:58:24 +0000
Received: from [193.109.254.147:61427] by server-2.bemta-14.messagelabs.com id
	55/1D-27740-F281ADF4; Thu, 14 Jun 2012 16:58:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339693103!2092284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20079 invoked from network); 14 Jun 2012 16:58:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13029742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 16:53:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 17:53:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDIN-0007Nt-UV; Thu, 14 Jun 2012 16:53:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDIN-000715-TJ;
	Thu, 14 Jun 2012 17:53:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.5887.893166.341739@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 17:53:19 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339586159.24104.193.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-8-git-send-email-ian.jackson@eu.citrix.com>
	<1339586159.24104.193.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/19] libxl: provide libxl__xs_*_checked
 and libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 07/19] libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > These useful utility functions make dealing with xenstore a little
> > less painful.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> (minor observation and a typo below)
...
> > +int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
> > +                            const char *path, const char *string);
> 
> I suppose in the future we might consider merging this with
> libxl__xs_write -- there's no reason not to always log a failed write,
> is there?

Maybe.  It might fail due to EPERM and there might be another strategy
the caller might have available.  Although this is rare enough that
perhaps such callers should use raw xs calls.

Arguably the same applies to read.

> > + *    0  commited successfully
> 
>            committed

Fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:59:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16:59: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 1SfDO8-0000Lg-2T; Thu, 14 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SfDO6-0000LN-I6
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:59:14 +0000
Received: from [85.158.138.51:29477] by server-5.bemta-3.messagelabs.com id
	23/81-01572-1681ADF4; Thu, 14 Jun 2012 16:59:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339693152!18790720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1756 invoked from network); 14 Jun 2012 16:59:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:59:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13029833"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 16:58:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 17:58:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDNo-0007Pu-3o; Thu, 14 Jun 2012 16:58:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDNo-0007hN-2V;
	Thu, 14 Jun 2012 17:58:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.6224.62770.422932@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 17:58:56 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339592945.24104.209.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
	<1339592906.24104.208.camel@zakaz.uk.xensource.com>
	<1339592945.24104.209.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
 gc_opt==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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about gc_opt==NULL"):
> On Wed, 2012-06-13 at 14:08 +0100, Ian Campbell wrote:
> > This patch will itself break the build until a subsequent patch, won't
> > it? Shuffle it afterwards?
> 
> Nevermind, I accidentally skipped #13...

:-).

> > > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > Wherever it ends up in the sequence:
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 16:59:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 16:59: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 1SfDO8-0000Lg-2T; Thu, 14 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SfDO6-0000LN-I6
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 16:59:14 +0000
Received: from [85.158.138.51:29477] by server-5.bemta-3.messagelabs.com id
	23/81-01572-1681ADF4; Thu, 14 Jun 2012 16:59:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1339693152!18790720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1756 invoked from network); 14 Jun 2012 16:59:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 16:59:12 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13029833"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 16:58:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 17:58:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDNo-0007Pu-3o; Thu, 14 Jun 2012 16:58:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDNo-0007hN-2V;
	Thu, 14 Jun 2012 17:58:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.6224.62770.422932@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 17:58:56 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339592945.24104.209.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-15-git-send-email-ian.jackson@eu.citrix.com>
	<1339592906.24104.208.camel@zakaz.uk.xensource.com>
	<1339592945.24104.209.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about
 gc_opt==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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14/19] libxl: Get compiler to warn about gc_opt==NULL"):
> On Wed, 2012-06-13 at 14:08 +0100, Ian Campbell wrote:
> > This patch will itself break the build until a subsequent patch, won't
> > it? Shuffle it afterwards?
> 
> Nevermind, I accidentally skipped #13...

:-).

> > > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > Wherever it ends up in the sequence:
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17: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 1SfDPQ-0000Vk-Hq; Thu, 14 Jun 2012 17:00:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SfDPO-0000VP-M6
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 17:00:34 +0000
Received: from [85.158.143.99:3297] by server-2.bemta-4.messagelabs.com id
	5F/61-17938-2B81ADF4; Thu, 14 Jun 2012 17:00:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339693230!22167481!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10583 invoked from network); 14 Jun 2012 17:00:33 -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 Jun 2012 17:00:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfDPJ-0002FG-Ez; Thu, 14 Jun 2012 17:00:29 +0000
Date: Thu, 14 Jun 2012 18:00:29 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120614170029.GM90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
	<4FD9FCAF.4050002@eu.citrix.com>
	<CAFLBxZZUJpQ7B0+TwxBFSyLSVLr2kJLnBc-9OH6SgpQWJMPKug@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZUJpQ7B0+TwxBFSyLSVLr2kJLnBc-9OH6SgpQWJMPKug@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:39 +0100 on 14 Jun (1339695541), George Dunlap wrote:
> On Thu, Jun 14, 2012 at 4:01 PM, George Dunlap
> <george.dunlap@eu.citrix.com> wrote:
> > On 14/06/12 11:21, Tim Deegan wrote:
> >> This looks broadly correct, but it's a bit invasive. =A0If there's any=
 way
> >> to rework patch 2 not to need it that would be helpful. =A0It looks li=
ke
> >> the main use is for detecting and removing superpage PoD entries; maybe
> >> that could be done with a sweep like you have in the non-PoD case?
> >
> > You mean the non-balloon case? =A0I forget why I thought that was a bad=
 idea,
> > exactly. =A0Let me think about that.
> =

> I think I basically didn't want to have to do the full check of each
> of the 512 individual entries of the p2m in the case that it wasn't,
> in fact, a superpage; but I think in the common case it should either
> be a full superpage, or the check at the beginning of
> p2m_pod_zero_check_superpage() should fail out relatively early.  So
> we could probably get away without it.
> =

> Why don't I re-write patch 2 of this series to not require patch 1,
> and include it in my other series.  If there's a performance gain to
> be had by avoiding the check, we can discuss that post-4.2.

That sounds ideal.  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 Jun 14 17:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17: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 1SfDPQ-0000Vk-Hq; Thu, 14 Jun 2012 17:00:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SfDPO-0000VP-M6
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 17:00:34 +0000
Received: from [85.158.143.99:3297] by server-2.bemta-4.messagelabs.com id
	5F/61-17938-2B81ADF4; Thu, 14 Jun 2012 17:00:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339693230!22167481!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10583 invoked from network); 14 Jun 2012 17:00:33 -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 Jun 2012 17:00:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfDPJ-0002FG-Ez; Thu, 14 Jun 2012 17:00:29 +0000
Date: Thu, 14 Jun 2012 18:00:29 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120614170029.GM90181@ocelot.phlegethon.org>
References: <patchbomb.1339156490@elijah>
	<672e9628f27845d24a3f.1339156491@elijah>
	<20120614102116.GH82539@ocelot.phlegethon.org>
	<4FD9FCAF.4050002@eu.citrix.com>
	<CAFLBxZZUJpQ7B0+TwxBFSyLSVLr2kJLnBc-9OH6SgpQWJMPKug@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZUJpQ7B0+TwxBFSyLSVLr2kJLnBc-9OH6SgpQWJMPKug@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4 RFC] xen,
	p2m: get_entry returns level of entry as well
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:39 +0100 on 14 Jun (1339695541), George Dunlap wrote:
> On Thu, Jun 14, 2012 at 4:01 PM, George Dunlap
> <george.dunlap@eu.citrix.com> wrote:
> > On 14/06/12 11:21, Tim Deegan wrote:
> >> This looks broadly correct, but it's a bit invasive. =A0If there's any=
 way
> >> to rework patch 2 not to need it that would be helpful. =A0It looks li=
ke
> >> the main use is for detecting and removing superpage PoD entries; maybe
> >> that could be done with a sweep like you have in the non-PoD case?
> >
> > You mean the non-balloon case? =A0I forget why I thought that was a bad=
 idea,
> > exactly. =A0Let me think about that.
> =

> I think I basically didn't want to have to do the full check of each
> of the 512 individual entries of the p2m in the case that it wasn't,
> in fact, a superpage; but I think in the common case it should either
> be a full superpage, or the check at the beginning of
> p2m_pod_zero_check_superpage() should fail out relatively early.  So
> we could probably get away without it.
> =

> Why don't I re-write patch 2 of this series to not require patch 1,
> and include it in my other series.  If there's a performance gain to
> be had by avoiding the check, we can discuss that post-4.2.

That sounds ideal.  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 Jun 14 17:08:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17: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 1SfDX8-0000wH-IM; Thu, 14 Jun 2012 17:08:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfDX7-0000wC-Nr
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:08:33 +0000
Received: from [85.158.139.83:32024] by server-12.bemta-5.messagelabs.com id
	DB/40-25233-09A1ADF4; Thu, 14 Jun 2012 17:08:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339693712!27184205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29465 invoked from network); 14 Jun 2012 17:08:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 17:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13030250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 17:08:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 18:08:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDX5-0007TY-JA; Thu, 14 Jun 2012 17:08:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDX5-0000R5-Hw;
	Thu, 14 Jun 2012 18:08:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.6799.539691.291793@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 18:08:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339593900.24104.214.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
	<1339593900.24104.214.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle
 children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle children"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Also, remove erroneous comment suggesting that `death' callback
> > parameter to libxl__ev_child_fork may be NULL.  It may not, and there
> > are no callers which pass NULL.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> > -static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
> > +/* Precondition: Attached or Detaching; caller has logged failure reason.
> > + * Results: Detaching, or Attached Failing */
> 
> Is it Failing or Failed? You use Failed elsewhere.

`Failed' will do.  Fixed.

> [...]
> > @@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
> >   *
> >   * Higher-level double-fork and separate detach eg as for device models
> >   *
> > - * Each libxl__spawn_state is in one of the conventional states
> > - *    Undefined, Idle, Active
> > + * Each libxl__spawn_state is in one of these states
> > + *    Undefined, Idle, Attached, Detaching
> 
> "Attached OK" and "Attached Failed" as described above aren't really
> full states, just sub-states?

Yes.  I have clarified this:

 * The difference between Attached OK and Attached Failed is not
 * directly visible to callers - callers see these two the same,
 * although of course Attached OK will hopefully eventually result in
 * a call to detached_cb, whereas Attached Failed will end up
 * in a call to failure_cb.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:08:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17: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 1SfDX8-0000wH-IM; Thu, 14 Jun 2012 17:08:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfDX7-0000wC-Nr
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:08:33 +0000
Received: from [85.158.139.83:32024] by server-12.bemta-5.messagelabs.com id
	DB/40-25233-09A1ADF4; Thu, 14 Jun 2012 17:08:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339693712!27184205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29465 invoked from network); 14 Jun 2012 17:08:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 17:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="13030250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 17:08:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 14 Jun 2012 18:08:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfDX5-0007TY-JA; Thu, 14 Jun 2012 17:08:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfDX5-0000R5-Hw;
	Thu, 14 Jun 2012 18:08:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20442.6799.539691.291793@mariner.uk.xensource.com>
Date: Thu, 14 Jun 2012 18:08:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1339593900.24104.214.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-18-git-send-email-ian.jackson@eu.citrix.com>
	<1339593900.24104.214.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle
 children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle children"):
> On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > Also, remove erroneous comment suggesting that `death' callback
> > parameter to libxl__ev_child_fork may be NULL.  It may not, and there
> > are no callers which pass NULL.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> > -static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
> > +/* Precondition: Attached or Detaching; caller has logged failure reason.
> > + * Results: Detaching, or Attached Failing */
> 
> Is it Failing or Failed? You use Failed elsewhere.

`Failed' will do.  Fixed.

> [...]
> > @@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
> >   *
> >   * Higher-level double-fork and separate detach eg as for device models
> >   *
> > - * Each libxl__spawn_state is in one of the conventional states
> > - *    Undefined, Idle, Active
> > + * Each libxl__spawn_state is in one of these states
> > + *    Undefined, Idle, Attached, Detaching
> 
> "Attached OK" and "Attached Failed" as described above aren't really
> full states, just sub-states?

Yes.  I have clarified this:

 * The difference between Attached OK and Attached Failed is not
 * directly visible to callers - callers see these two the same,
 * although of course Attached OK will hopefully eventually result in
 * a call to detached_cb, whereas Attached Failed will end up
 * in a call to failure_cb.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgC-0001AH-Ux; Thu, 14 Jun 2012 17:17:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDgA-00018F-Ub
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:55 +0000
Received: from [85.158.139.83:61995] by server-8.bemta-5.messagelabs.com id
	58/F0-10278-2CC1ADF4; Thu, 14 Jun 2012 17:17:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339694270!27726737!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2153 invoked from network); 14 Jun 2012 17:17:52 -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 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787504"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Rk;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:46 +0100
Message-ID: <1339693309-15192-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 6/9] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    1 +
 hw/xen_common.h         |    3 +
 hw/xen_pt.c             |  812 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt.h             |  248 +++++++++++++++
 hw/xen_pt_config_init.c |   11 +
 xen-all.c               |   12 +
 6 files changed, 1087 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index b719d8e..e361a92 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,6 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_common.h b/hw/xen_common.h
index fe7f227..03b0bb1 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -150,4 +150,7 @@ static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
 
 void destroy_hvm_domain(bool reboot);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
new file mode 100644
index 0000000..63a5c80
--- /dev/null
+++ b/hw/xen_pt.c
@@ -0,0 +1,812 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement xen_pt_mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(xen_pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "range.h"
+
+#define XEN_PT_NR_IRQS (256)
+static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%d] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int xen_pt_pci_config_access_check(PCIDevice *d, uint32_t addr, int len)
+{
+    /* check offset range */
+    if (addr >= 0xFF) {
+        XEN_PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access length. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (addr & (len - 1)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access size "
+                   "alignment. (addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xen_pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t xen_pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = xen_host_pci_get_block(&s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void xen_pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                    uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = xen_pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < XEN_PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED)) {
+        XEN_PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                    "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            XEN_PT_WARN(d, "Access to 0-Hardwired register. "
+                        "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = xen_host_pci_get_block(&s->real_device, addr,
+                                (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to xen_host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = xen_host_pci_set_block(&s->real_device, addr,
+                                    (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            XEN_PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t xen_pt_bar_read(void *o, target_phys_addr_t addr,
+                                unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    XEN_PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+    return 0;
+}
+static void xen_pt_bar_write(void *o, target_phys_addr_t addr, uint64_t val,
+                             unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as xen_pt_bar_read function */
+    XEN_PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = xen_pt_bar_read,
+    .write = xen_pt_bar_write,
+};
+
+static int xen_pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    XenHostPCIDevice *d = &s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+            }
+        }
+
+        memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                              "xen-pci-pt-bar", r->size);
+        pci_register_bar(&s->dev, i, type, &s->bar[i]);
+
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64" type: %#x)\n",
+                   i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (xen_host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            xen_host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        XEN_PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    XenHostPCIDevice *d = &s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int xen_pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+/*
+ * This function checks if an io_region overlaps an io_region from another
+ * device.  The io_region to check is provided with (addr, size and type)
+ * A callback can be provided and will be called for every region that is
+ * overlapped.
+ * The return value indicates if the region is overlappsed */
+struct CheckBarArgs {
+    XenPCIPassthroughState *s;
+    pcibus_t addr;
+    pcibus_t size;
+    uint8_t type;
+    bool rc;
+};
+static void xen_pt_check_bar_overlap(PCIBus *bus, PCIDevice *d, void *opaque)
+{
+    struct CheckBarArgs *arg = opaque;
+    XenPCIPassthroughState *s = arg->s;
+    uint8_t type = arg->type;
+    int i;
+
+    if (d->devfn == s->dev.devfn) {
+        return;
+    }
+
+    /* xxx: This ignores bridges. */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        const PCIIORegion *r = &d->io_regions[i];
+
+        if (!r->size) {
+            continue;
+        }
+        if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+            != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+            continue;
+        }
+
+        if (ranges_overlap(arg->addr, arg->size, r->addr, r->size)) {
+            XEN_PT_WARN(&s->dev,
+                        "Overlapped to device [%02x:%02x.%d] Region: %i"
+                        " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+                        pci_bus_num(bus), PCI_SLOT(d->devfn),
+                        PCI_FUNC(d->devfn), i, r->addr, r->size);
+            arg->rc = true;
+        }
+    }
+}
+
+static void xen_pt_region_update(XenPCIPassthroughState *s,
+                                 MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+    struct CheckBarArgs args = {
+        .s = s,
+        .addr = sec->offset_within_address_space,
+        .size = sec->size,
+        .rc = false,
+    };
+
+    bar = xen_pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    args.type = d->io_regions[bar].type;
+    pci_for_each_device(d->bus, pci_bus_num(d->bus),
+                        xen_pt_check_bar_overlap, &args);
+    if (args.rc) {
+        XEN_PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                    ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                    bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      XEN_PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(size + XC_PAGE_SIZE - 1),
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void xen_pt_begin(MemoryListener *l)
+{
+}
+
+static void xen_pt_commit(MemoryListener *l)
+{
+}
+
+static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, true);
+}
+
+static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, false);
+}
+
+static void xen_pt_region_nop(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_fns(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_global_fns(MemoryListener *l)
+{
+}
+
+static void xen_pt_eventfd_fns(MemoryListener *l, MemoryRegionSection *s,
+                               bool match_data, uint64_t data, int fd)
+{
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .begin = xen_pt_begin,
+    .commit = xen_pt_commit,
+    .region_add = xen_pt_region_add,
+    .region_nop = xen_pt_region_nop,
+    .region_del = xen_pt_region_del,
+    .log_start = xen_pt_log_fns,
+    .log_stop = xen_pt_log_fns,
+    .log_sync = xen_pt_log_fns,
+    .log_global_start = xen_pt_log_global_fns,
+    .log_global_stop = xen_pt_log_global_fns,
+    .eventfd_add = xen_pt_eventfd_fns,
+    .eventfd_del = xen_pt_eventfd_fns,
+    .priority = 10,
+};
+
+/* init */
+
+static int xen_pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    /* register real device */
+    XEN_PT_LOG(d, "Assigning real physical device %02x:%02x.%d"
+               " to devfn %#x\n",
+               s->hostaddr.bus, s->hostaddr.slot, s->hostaddr.function,
+               s->dev.devfn);
+
+    rc = xen_host_pci_device_get(&s->real_device,
+                                 s->hostaddr.domain, s->hostaddr.bus,
+                                 s->hostaddr.slot, s->hostaddr.function);
+    if (rc) {
+        XEN_PT_ERR(d, "Failed to \"open\" the real pci device. rc: %i\n", rc);
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device.is_virtfn;
+    if (s->is_virtfn) {
+        XEN_PT_LOG(d, "%04x:%02x:%02x.%d is a SR-IOV Virtual Function\n",
+                   s->real_device.domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (xen_host_pci_get_block(&s->real_device, 0, d->config,
+                               PCI_CONFIG_SPACE_SIZE) == -1) {
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    xen_pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        XEN_PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    machine_irq = s->real_device.irq;
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+                   machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        xen_host_pci_set_word(&s->real_device,
+                              PCI_COMMAND,
+                              pci_get_word(s->dev.config + PCI_COMMAND)
+                              | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        xen_pt_mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = xen_pt_pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                       e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
+                                  *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                                  | PCI_COMMAND_INTX_DISABLE);
+            xen_pt_mapped_machine_irq[machine_irq]--;
+
+            if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                               " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener, NULL);
+    XEN_PT_LOG(d, "Real physical device %02x:%02x.%d registered successfuly!\n",
+               bus, slot, func);
+
+    return 0;
+}
+
+static int xen_pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = xen_pt_pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
+                       " (machine irq: %i, rc: %d)"
+                       " But bravely continuing on..\n",
+                       'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        xen_pt_mapped_machine_irq[machine_irq]--;
+
+        if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                XEN_PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                           " But bravely continuing on..\n",
+                           machine_irq, rc);
+            }
+        }
+    }
+
+    xen_pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    xen_host_pci_device_put(&s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_PCI_HOST_DEVADDR("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_pt_initfn;
+    k->exit = xen_pt_unregister_device;
+    k->config_read = xen_pt_pci_read_config;
+    k->config_write = xen_pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
new file mode 100644
index 0000000..36001a7
--- /dev/null
+++ b/hw/xen_pt.h
@@ -0,0 +1,248 @@
+#ifndef XEN_PT_H
+#define XEN_PT_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "xen-host-pci-device.h"
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
+
+#ifdef XEN_PT_LOGGING_ENABLED
+#  define XEN_PT_LOG(d, _f, _a...)  xen_pt_log(d, "%s: " _f, __func__, ##_a)
+#  define XEN_PT_WARN(d, _f, _a...) \
+    xen_pt_log(d, "%s: Warning: "_f, __func__, ##_a)
+#else
+#  define XEN_PT_LOG(d, _f, _a...)
+#  define XEN_PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef XEN_PT_DEBUG_PCI_CONFIG_ACCESS
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len) \
+    xen_pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+               __func__, addr, val, len)
+#else
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define XEN_PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*xen_pt_conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*xen_pt_conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*xen_pt_conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define XEN_PT_BAR_ALLF 0xFFFFFFFF
+#define XEN_PT_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
+    XEN_PT_GRP_TYPE_EMU,            /* emul reg group */
+} XenPTRegisterGroupType;
+
+typedef enum {
+    XEN_PT_BAR_FLAG_MEM = 0,        /* Memory type BAR */
+    XEN_PT_BAR_FLAG_IO,             /* I/O type BAR */
+    XEN_PT_BAR_FLAG_UPPER,          /* upper 64bit BAR */
+    XEN_PT_BAR_FLAG_UNUSED,         /* unused BAR */
+} XenPTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    XenPTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    xen_pt_conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            xen_pt_conf_dword_write write;
+            xen_pt_conf_dword_read read;
+        } dw;
+        struct {
+            xen_pt_conf_word_write write;
+            xen_pt_conf_word_read read;
+        } w;
+        struct {
+            xen_pt_conf_byte_write write;
+            xen_pt_conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*xen_pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    XenPTRegisterGroupType grp_type;
+    uint8_t grp_size;
+    xen_pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_regs;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define XEN_PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    PCIHostDeviceAddress hostaddr;
+    bool is_virtfn;
+    XenHostPCIDevice real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grps;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int xen_pt_config_init(XenPCIPassthroughState *s);
+void xen_pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int xen_pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t xen_pt_get_emul_size(XenPTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == XEN_PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, xen_pt_pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t xen_pt_pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    xen_host_pci_get_byte(&s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = xen_pt_pci_read_intx(s);
+
+    XEN_PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        XEN_PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+                   " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
new file mode 100644
index 0000000..64d22e8
--- /dev/null
+++ b/hw/xen_pt_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pt.h"
+
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5220cc..59f2323 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1191,3 +1191,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgA-00018X-R5; Thu, 14 Jun 2012 17:17:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg9-00017E-5n
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:53 +0000
Received: from [193.109.254.147:53247] by server-10.bemta-14.messagelabs.com
	id CA/EF-25709-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31357 invoked from network); 14 Jun 2012 17:17:52 -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;
	14 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113174"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Mp;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:41 +0100
Message-ID: <1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are using this in our quirk lookup provided by patch
titled: Introduce Xen PCI Passthrough, PCI config space helpers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..649e6b3 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgC-0001AH-Ux; Thu, 14 Jun 2012 17:17:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDgA-00018F-Ub
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:55 +0000
Received: from [85.158.139.83:61995] by server-8.bemta-5.messagelabs.com id
	58/F0-10278-2CC1ADF4; Thu, 14 Jun 2012 17:17:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339694270!27726737!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2153 invoked from network); 14 Jun 2012 17:17:52 -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 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787504"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Rk;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:46 +0100
Message-ID: <1339693309-15192-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 6/9] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    1 +
 hw/xen_common.h         |    3 +
 hw/xen_pt.c             |  812 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt.h             |  248 +++++++++++++++
 hw/xen_pt_config_init.c |   11 +
 xen-all.c               |   12 +
 6 files changed, 1087 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index b719d8e..e361a92 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,6 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_common.h b/hw/xen_common.h
index fe7f227..03b0bb1 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -150,4 +150,7 @@ static inline int xen_xc_hvm_inject_msi(XenXC xen_xc, domid_t dom,
 
 void destroy_hvm_domain(bool reboot);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
new file mode 100644
index 0000000..63a5c80
--- /dev/null
+++ b/hw/xen_pt.c
@@ -0,0 +1,812 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement xen_pt_mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(xen_pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "range.h"
+
+#define XEN_PT_NR_IRQS (256)
+static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%d] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int xen_pt_pci_config_access_check(PCIDevice *d, uint32_t addr, int len)
+{
+    /* check offset range */
+    if (addr >= 0xFF) {
+        XEN_PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access length. "
+                   "(addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (addr & (len - 1)) {
+        XEN_PT_ERR(d, "Failed to access register with invalid access size "
+                   "alignment. (addr: 0x%02x, len: %d)\n", addr, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xen_pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t xen_pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = xen_host_pci_get_block(&s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void xen_pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                    uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (xen_pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    XEN_PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = xen_pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < XEN_PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED)) {
+        XEN_PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                    "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = xen_pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            XEN_PT_WARN(d, "Access to 0-Hardwired register. "
+                        "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = xen_host_pci_get_block(&s->real_device, addr,
+                                (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        XEN_PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to xen_host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = xen_host_pci_set_block(&s->real_device, addr,
+                                    (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            XEN_PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t xen_pt_bar_read(void *o, target_phys_addr_t addr,
+                                unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    XEN_PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+    return 0;
+}
+static void xen_pt_bar_write(void *o, target_phys_addr_t addr, uint64_t val,
+                             unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as xen_pt_bar_read function */
+    XEN_PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n",
+               addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = xen_pt_bar_read,
+    .write = xen_pt_bar_write,
+};
+
+static int xen_pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    XenHostPCIDevice *d = &s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_ROM_SLOT; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+            }
+        }
+
+        memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                              "xen-pci-pt-bar", r->size);
+        pci_register_bar(&s->dev, i, type, &s->bar[i]);
+
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64" type: %#x)\n",
+                   i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (xen_host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            xen_host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        XEN_PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    XenHostPCIDevice *d = &s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        XenHostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int xen_pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+/*
+ * This function checks if an io_region overlaps an io_region from another
+ * device.  The io_region to check is provided with (addr, size and type)
+ * A callback can be provided and will be called for every region that is
+ * overlapped.
+ * The return value indicates if the region is overlappsed */
+struct CheckBarArgs {
+    XenPCIPassthroughState *s;
+    pcibus_t addr;
+    pcibus_t size;
+    uint8_t type;
+    bool rc;
+};
+static void xen_pt_check_bar_overlap(PCIBus *bus, PCIDevice *d, void *opaque)
+{
+    struct CheckBarArgs *arg = opaque;
+    XenPCIPassthroughState *s = arg->s;
+    uint8_t type = arg->type;
+    int i;
+
+    if (d->devfn == s->dev.devfn) {
+        return;
+    }
+
+    /* xxx: This ignores bridges. */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        const PCIIORegion *r = &d->io_regions[i];
+
+        if (!r->size) {
+            continue;
+        }
+        if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+            != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+            continue;
+        }
+
+        if (ranges_overlap(arg->addr, arg->size, r->addr, r->size)) {
+            XEN_PT_WARN(&s->dev,
+                        "Overlapped to device [%02x:%02x.%d] Region: %i"
+                        " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+                        pci_bus_num(bus), PCI_SLOT(d->devfn),
+                        PCI_FUNC(d->devfn), i, r->addr, r->size);
+            arg->rc = true;
+        }
+    }
+}
+
+static void xen_pt_region_update(XenPCIPassthroughState *s,
+                                 MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+    struct CheckBarArgs args = {
+        .s = s,
+        .addr = sec->offset_within_address_space,
+        .size = sec->size,
+        .rc = false,
+    };
+
+    bar = xen_pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    args.type = d->io_regions[bar].type;
+    pci_for_each_device(d->bus, pci_bus_num(d->bus),
+                        xen_pt_check_bar_overlap, &args);
+    if (args.rc) {
+        XEN_PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                    ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                    bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      XEN_PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      XEN_PFN(size + XC_PAGE_SIZE - 1),
+                                      op);
+        if (rc) {
+            XEN_PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                       adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void xen_pt_begin(MemoryListener *l)
+{
+}
+
+static void xen_pt_commit(MemoryListener *l)
+{
+}
+
+static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, true);
+}
+
+static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    xen_pt_region_update(s, sec, false);
+}
+
+static void xen_pt_region_nop(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_fns(MemoryListener *l, MemoryRegionSection *s)
+{
+}
+
+static void xen_pt_log_global_fns(MemoryListener *l)
+{
+}
+
+static void xen_pt_eventfd_fns(MemoryListener *l, MemoryRegionSection *s,
+                               bool match_data, uint64_t data, int fd)
+{
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .begin = xen_pt_begin,
+    .commit = xen_pt_commit,
+    .region_add = xen_pt_region_add,
+    .region_nop = xen_pt_region_nop,
+    .region_del = xen_pt_region_del,
+    .log_start = xen_pt_log_fns,
+    .log_stop = xen_pt_log_fns,
+    .log_sync = xen_pt_log_fns,
+    .log_global_start = xen_pt_log_global_fns,
+    .log_global_stop = xen_pt_log_global_fns,
+    .eventfd_add = xen_pt_eventfd_fns,
+    .eventfd_del = xen_pt_eventfd_fns,
+    .priority = 10,
+};
+
+/* init */
+
+static int xen_pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    /* register real device */
+    XEN_PT_LOG(d, "Assigning real physical device %02x:%02x.%d"
+               " to devfn %#x\n",
+               s->hostaddr.bus, s->hostaddr.slot, s->hostaddr.function,
+               s->dev.devfn);
+
+    rc = xen_host_pci_device_get(&s->real_device,
+                                 s->hostaddr.domain, s->hostaddr.bus,
+                                 s->hostaddr.slot, s->hostaddr.function);
+    if (rc) {
+        XEN_PT_ERR(d, "Failed to \"open\" the real pci device. rc: %i\n", rc);
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device.is_virtfn;
+    if (s->is_virtfn) {
+        XEN_PT_LOG(d, "%04x:%02x:%02x.%d is a SR-IOV Virtual Function\n",
+                   s->real_device.domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (xen_host_pci_get_block(&s->real_device, 0, d->config,
+                               PCI_CONFIG_SPACE_SIZE) == -1) {
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    xen_pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        XEN_PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    machine_irq = s->real_device.irq;
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        XEN_PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+                   machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        xen_host_pci_set_word(&s->real_device,
+                              PCI_COMMAND,
+                              pci_get_word(s->dev.config + PCI_COMMAND)
+                              | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        xen_pt_mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = xen_pt_pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                       e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
+                                  *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                                  | PCI_COMMAND_INTX_DISABLE);
+            xen_pt_mapped_machine_irq[machine_irq]--;
+
+            if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    XEN_PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                               " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener, NULL);
+    XEN_PT_LOG(d, "Real physical device %02x:%02x.%d registered successfuly!\n",
+               bus, slot, func);
+
+    return 0;
+}
+
+static int xen_pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = xen_pt_pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
+                       " (machine irq: %i, rc: %d)"
+                       " But bravely continuing on..\n",
+                       'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        xen_pt_mapped_machine_irq[machine_irq]--;
+
+        if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                XEN_PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                           " But bravely continuing on..\n",
+                           machine_irq, rc);
+            }
+        }
+    }
+
+    xen_pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    xen_host_pci_device_put(&s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_PCI_HOST_DEVADDR("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_pt_initfn;
+    k->exit = xen_pt_unregister_device;
+    k->config_read = xen_pt_pci_read_config;
+    k->config_write = xen_pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
new file mode 100644
index 0000000..36001a7
--- /dev/null
+++ b/hw/xen_pt.h
@@ -0,0 +1,248 @@
+#ifndef XEN_PT_H
+#define XEN_PT_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "xen-host-pci-device.h"
+
+void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
+
+#ifdef XEN_PT_LOGGING_ENABLED
+#  define XEN_PT_LOG(d, _f, _a...)  xen_pt_log(d, "%s: " _f, __func__, ##_a)
+#  define XEN_PT_WARN(d, _f, _a...) \
+    xen_pt_log(d, "%s: Warning: "_f, __func__, ##_a)
+#else
+#  define XEN_PT_LOG(d, _f, _a...)
+#  define XEN_PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef XEN_PT_DEBUG_PCI_CONFIG_ACCESS
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len) \
+    xen_pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+               __func__, addr, val, len)
+#else
+#  define XEN_PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define XEN_PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*xen_pt_conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*xen_pt_conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*xen_pt_conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*xen_pt_conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*xen_pt_conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define XEN_PT_BAR_ALLF 0xFFFFFFFF
+#define XEN_PT_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
+    XEN_PT_GRP_TYPE_EMU,            /* emul reg group */
+} XenPTRegisterGroupType;
+
+typedef enum {
+    XEN_PT_BAR_FLAG_MEM = 0,        /* Memory type BAR */
+    XEN_PT_BAR_FLAG_IO,             /* I/O type BAR */
+    XEN_PT_BAR_FLAG_UPPER,          /* upper 64bit BAR */
+    XEN_PT_BAR_FLAG_UNUSED,         /* unused BAR */
+} XenPTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    XenPTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    xen_pt_conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            xen_pt_conf_dword_write write;
+            xen_pt_conf_dword_read read;
+        } dw;
+        struct {
+            xen_pt_conf_word_write write;
+            xen_pt_conf_word_read read;
+        } w;
+        struct {
+            xen_pt_conf_byte_write write;
+            xen_pt_conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*xen_pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    XenPTRegisterGroupType grp_type;
+    uint8_t grp_size;
+    xen_pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_regs;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define XEN_PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    PCIHostDeviceAddress hostaddr;
+    bool is_virtfn;
+    XenHostPCIDevice real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grps;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int xen_pt_config_init(XenPCIPassthroughState *s);
+void xen_pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int xen_pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t xen_pt_get_emul_size(XenPTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == XEN_PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, xen_pt_pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t xen_pt_pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    xen_host_pci_get_byte(&s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = xen_pt_pci_read_intx(s);
+
+    XEN_PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        XEN_PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+                   " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
new file mode 100644
index 0000000..64d22e8
--- /dev/null
+++ b/hw/xen_pt_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pt.h"
+
+XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5220cc..59f2323 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1191,3 +1191,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgA-00018X-R5; Thu, 14 Jun 2012 17:17:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg9-00017E-5n
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:53 +0000
Received: from [193.109.254.147:53247] by server-10.bemta-14.messagelabs.com
	id CA/EF-25709-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31357 invoked from network); 14 Jun 2012 17:17:52 -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;
	14 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113174"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Mp;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:41 +0100
Message-ID: <1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are using this in our quirk lookup provided by patch
titled: Introduce Xen PCI Passthrough, PCI config space helpers.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..649e6b3 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgA-000182-3k; Thu, 14 Jun 2012 17:17:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg8-00017A-O2
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:52 +0000
Received: from [193.109.254.147:58321] by server-6.bemta-14.messagelabs.com id
	47/15-02426-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 14 Jun 2012 17:17:51 -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;
	14 Jun 2012 17:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113171"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-NS;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:42 +0100
Message-ID: <1339693309-15192-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 2/9] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 configure |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index c2366ee..d734a03 100755
--- a/configure
+++ b/configure
@@ -137,6 +137,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -685,6 +686,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1032,6 +1037,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1508,6 +1515,25 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes" &&
+    test "$xen_ctrl_version" -ge 340; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      if test "$xen_ctrl_version" -lt 340; then
+        echo "ERROR: This feature does not work with Xen 3.3"
+      fi
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3699,6 +3725,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgC-00019t-HL; Thu, 14 Jun 2012 17:17:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDgA-00017D-R1
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:55 +0000
Received: from [85.158.143.35:52169] by server-1.bemta-4.messagelabs.com id
	16/CF-24392-2CC1ADF4; Thu, 14 Jun 2012 17:17:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339694268!4890212!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6176 invoked from network); 14 Jun 2012 17:17:52 -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;
	14 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Sl;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:47 +0100
Message-ID: <1339693309-15192-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 7/9] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_pt.c             |   10 +
 hw/xen_pt.h             |    2 +
 hw/xen_pt_config_init.c | 1387 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1399 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 63a5c80..92ad0fa 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -673,6 +673,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (xen_pt_config_init(s)) {
+        XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         XEN_PT_LOG(d, "no pin interrupt\n");
@@ -771,6 +778,9 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    xen_pt_config_delete(s);
+
     xen_pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 36001a7..4b76073 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -62,6 +62,8 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_ALLF 0xFFFFFFFF
 #define XEN_PT_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 64d22e8..1d97876 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1,11 +1,1398 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pt.h"
 
+#define XEN_PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define XEN_PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int xen_pt_hide_dev_cap(const XenHostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * xen_pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_SFP_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grps, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int xen_pt_common_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int xen_pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+
+/* Write register functions */
+
+static int xen_pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint8_t *val, uint8_t dev_value,
+                                 uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *val, uint16_t dev_value,
+                                 uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint32_t *val, uint32_t dev_value,
+                                 uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int xen_pt_vendor_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.vendor_id;
+    return 0;
+}
+static int xen_pt_device_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.device_id;
+    return 0;
+}
+static int xen_pt_status_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = xen_pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                       XenPTRegInfo *reg, uint32_t real_offset,
+                                       uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int xen_pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = xen_pt_pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int xen_pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *val, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*val & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define XEN_PT_BAR_MEM_RO_MASK    0x0000000F  /* BAR ReadOnly mask(Memory) */
+#define XEN_PT_BAR_MEM_EMU_MASK   0xFFFFFFF0  /* BAR emul mask(Memory) */
+#define XEN_PT_BAR_IO_RO_MASK     0x00000003  /* BAR ReadOnly mask(I/O) */
+#define XEN_PT_BAR_IO_EMU_MASK    0xFFFFFFFC  /* BAR emul mask(I/O) */
+
+static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
+                                         XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int type = s->real_device.io_regions[index - 1].type;
+
+        if ((type & XEN_HOST_PCI_REGION_TYPE_MEM)
+            && (type & XEN_HOST_PCI_REGION_TYPE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != XEN_PT_BAR_FLAG_UPPER) {
+                return XEN_PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return XEN_PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device.io_regions[index].type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return XEN_PT_BAR_FLAG_IO;
+    } else {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
+{
+    if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int xen_pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = xen_pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED) {
+        reg_field = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device.io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *val, uint32_t dev_value,
+                                uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = xen_pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (XEN_PT_BAR_ALLF & ~bar_ro_mask)) {
+                XEN_PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                            "Ignore mapping. "
+                            "(offset: 0x%02x, high address: 0x%08x)\n",
+                            reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                        XenPTReg *cfg_entry, uint32_t *val,
+                                        uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = xen_pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_header0[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_vendor_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_device_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_cmd_reg_read,
+        .u.w.write  = xen_pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = xen_pt_status_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = xen_pt_header_type_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_irqpin_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int xen_pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int xen_pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = XEN_PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_devctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint16_t *val,
+                                  uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pm[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_pmcsr_reg_read,
+        .u.w.write  = xen_pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int xen_pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                    const XenPTRegGroupInfo *grp_reg,
+                                    uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int xen_pt_vendor_size_init(XenPCIPassthroughState *s,
+                                   const XenPTRegGroupInfo *grp_reg,
+                                   uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        XEN_PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_header0,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_pm,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_vpd,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_vendor_size_init,
+        .emu_regs = xen_pt_emu_reg_vendor,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_pcie_size_init,
+        .emu_regs = xen_pt_emu_reg_pcie,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (xen_pt_emu_reg_grps[i].grp_id == cap_id) {
+                if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (xen_host_pci_get_byte(&s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (xen_host_pci_get_byte(&s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (xen_host_pci_get_byte(&s->real_device,
+                                  pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int xen_pt_config_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == XEN_PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int xen_pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grps);
+
+    for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, xen_pt_emu_reg_grps[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = xen_pt_emu_reg_grps + i;
+        if (xen_pt_emu_reg_grps[i].size_init) {
+            /* get register group size */
+            rc = xen_pt_emu_reg_grps[i].size_init(s, reg_grp_entry->reg_grp,
+                                                  reg_grp_offset,
+                                                  &reg_grp_entry->size);
+            if (rc < 0) {
+                xen_pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+            if (xen_pt_emu_reg_grps[i].emu_regs) {
+                int j = 0;
+                XenPTRegInfo *regs = xen_pt_emu_reg_grps[i].emu_regs;
+                /* initialize capability register */
+                for (j = 0; regs->size != 0; j++, regs++) {
+                    /* initialize capability register */
+                    rc = xen_pt_config_reg_init(s, reg_grp_entry, regs);
+                    if (rc < 0) {
+                        xen_pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void xen_pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgA-00018K-Fb; Thu, 14 Jun 2012 17:17:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg9-00017D-0s
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:53 +0000
Received: from [85.158.143.35:4287] by server-1.bemta-4.messagelabs.com id
	A0/CF-24392-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339694270!4462538!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 661 invoked from network); 14 Jun 2012 17:17:51 -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 Jun 2012 17:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113173"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-MB;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:40 +0100
Message-ID: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.

Changes since the last version:
  - New patch that introduce a new qdev-property pci-host-devaddr.
  => the "export pci_parse_devaddr" patch is not anymore usefull.

Thanks,


Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_SFP_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce XenHostPCIDevice to access a pci device on the host.
  pci.c: Add opaque argument to pci_for_each_device.
  qdev-properties: Introduce pci-host-devaddr.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

 configure                |   29 +
 hw/apic-msidef.h         |   30 +
 hw/apic.c                |   11 +-
 hw/i386/Makefile.objs    |    2 +
 hw/pci.c                 |   11 +-
 hw/pci.h                 |    4 +-
 hw/pci_ids.h             |    1 +
 hw/qdev-properties.c     |  107 +++
 hw/qdev.h                |    3 +
 hw/xen-host-pci-device.c |  396 ++++++++++
 hw/xen-host-pci-device.h |   55 ++
 hw/xen_common.h          |    3 +
 hw/xen_platform.c        |    8 +-
 hw/xen_pt.c              |  851 +++++++++++++++++++++
 hw/xen_pt.h              |  301 ++++++++
 hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c          |  620 +++++++++++++++
 qemu-common.h            |    7 +
 xen-all.c                |   12 +
 19 files changed, 4301 insertions(+), 19 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c
 create mode 100644 hw/xen_pt_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgA-000182-3k; Thu, 14 Jun 2012 17:17:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg8-00017A-O2
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:52 +0000
Received: from [193.109.254.147:58321] by server-6.bemta-14.messagelabs.com id
	47/15-02426-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 14 Jun 2012 17:17:51 -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;
	14 Jun 2012 17:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113171"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-NS;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:42 +0100
Message-ID: <1339693309-15192-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 2/9] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 configure |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index c2366ee..d734a03 100755
--- a/configure
+++ b/configure
@@ -137,6 +137,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -685,6 +686,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1032,6 +1037,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1508,6 +1515,25 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes" &&
+    test "$xen_ctrl_version" -ge 340; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      if test "$xen_ctrl_version" -lt 340; then
+        echo "ERROR: This feature does not work with Xen 3.3"
+      fi
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3699,6 +3725,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgC-00019t-HL; Thu, 14 Jun 2012 17:17:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDgA-00017D-R1
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:55 +0000
Received: from [85.158.143.35:52169] by server-1.bemta-4.messagelabs.com id
	16/CF-24392-2CC1ADF4; Thu, 14 Jun 2012 17:17:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339694268!4890212!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6176 invoked from network); 14 Jun 2012 17:17:52 -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;
	14 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Sl;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:47 +0100
Message-ID: <1339693309-15192-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Xen Devel <xen-devel@lists.xen.org>, Guy Zana <guy@neocleus.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 7/9] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen_pt.c             |   10 +
 hw/xen_pt.h             |    2 +
 hw/xen_pt_config_init.c | 1387 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1399 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 63a5c80..92ad0fa 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -673,6 +673,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (xen_pt_config_init(s)) {
+        XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         XEN_PT_LOG(d, "no pin interrupt\n");
@@ -771,6 +778,9 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    xen_pt_config_delete(s);
+
     xen_pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 36001a7..4b76073 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -62,6 +62,8 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_ALLF 0xFFFFFFFF
 #define XEN_PT_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 64d22e8..1d97876 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1,11 +1,1398 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pt.h"
 
+#define XEN_PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define XEN_PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int xen_pt_hide_dev_cap(const XenHostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * xen_pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_SFP_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *xen_pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grps, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *xen_pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int xen_pt_common_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int xen_pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+
+/* Write register functions */
+
+static int xen_pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint8_t *val, uint8_t dev_value,
+                                 uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *val, uint16_t dev_value,
+                                 uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+static int xen_pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint32_t *val, uint32_t dev_value,
+                                 uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int xen_pt_vendor_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.vendor_id;
+    return 0;
+}
+static int xen_pt_device_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = s->real_device.device_id;
+    return 0;
+}
+static int xen_pt_status_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = xen_pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = xen_pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                       XenPTRegInfo *reg, uint32_t real_offset,
+                                       uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int xen_pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegInfo *reg, uint32_t real_offset,
+                                  uint32_t *data)
+{
+    *data = xen_pt_pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int xen_pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *val, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*val & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define XEN_PT_BAR_MEM_RO_MASK    0x0000000F  /* BAR ReadOnly mask(Memory) */
+#define XEN_PT_BAR_MEM_EMU_MASK   0xFFFFFFF0  /* BAR emul mask(Memory) */
+#define XEN_PT_BAR_IO_RO_MASK     0x00000003  /* BAR ReadOnly mask(I/O) */
+#define XEN_PT_BAR_IO_EMU_MASK    0xFFFFFFFC  /* BAR emul mask(I/O) */
+
+static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
+                                         XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int type = s->real_device.io_regions[index - 1].type;
+
+        if ((type & XEN_HOST_PCI_REGION_TYPE_MEM)
+            && (type & XEN_HOST_PCI_REGION_TYPE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != XEN_PT_BAR_FLAG_UPPER) {
+                return XEN_PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return XEN_PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device.io_regions[index].type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return XEN_PT_BAR_FLAG_IO;
+    } else {
+        return XEN_PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
+{
+    if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->bus_flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int xen_pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                               uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = xen_pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == XEN_PT_BAR_FLAG_UNUSED) {
+        reg_field = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int xen_pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device.io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t *val, uint32_t dev_value,
+                                uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = xen_pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        XEN_PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = xen_pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        bar_emu_mask = XEN_PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        bar_emu_mask = XEN_PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case XEN_PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (XEN_PT_BAR_ALLF & ~bar_ro_mask)) {
+                XEN_PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                            "Ignore mapping. "
+                            "(offset: 0x%02x, high address: 0x%08x)\n",
+                            reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                        XenPTReg *cfg_entry, uint32_t *val,
+                                        uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = xen_pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_header0[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_vendor_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_device_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_cmd_reg_read,
+        .u.w.write  = xen_pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = xen_pt_status_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = xen_pt_header_type_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_common_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_irqpin_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_bar_reg_read,
+        .u.dw.write = xen_pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = xen_pt_bar_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int xen_pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int xen_pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = XEN_PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = XEN_PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_devctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = xen_pt_linkctrl2_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                 uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint16_t *val,
+                                  uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_pm[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = xen_pt_common_reg_init,
+        .u.w.read   = xen_pt_pmcsr_reg_read,
+        .u.w.write  = xen_pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int xen_pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                    const XenPTRegGroupInfo *grp_reg,
+                                    uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int xen_pt_vendor_size_init(XenPCIPassthroughState *s,
+                                   const XenPTRegGroupInfo *grp_reg,
+                                   uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+            /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            XEN_PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        XEN_PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_header0,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_pm,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs = xen_pt_emu_reg_vpd,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_vendor_size_init,
+        .emu_regs = xen_pt_emu_reg_vendor,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = xen_pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_pcie_size_init,
+        .emu_regs = xen_pt_emu_reg_pcie,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (xen_pt_emu_reg_grps[i].grp_id == cap_id) {
+                if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (xen_host_pci_get_byte(&s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (xen_host_pci_get_byte(&s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (xen_host_pci_get_byte(&s->real_device,
+                                  pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int xen_pt_config_reg_init(XenPCIPassthroughState *s,
+                                  XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == XEN_PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int xen_pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grps);
+
+    for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+            if (xen_pt_hide_dev_cap(&s->real_device,
+                                    xen_pt_emu_reg_grps[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, xen_pt_emu_reg_grps[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = xen_pt_emu_reg_grps + i;
+        if (xen_pt_emu_reg_grps[i].size_init) {
+            /* get register group size */
+            rc = xen_pt_emu_reg_grps[i].size_init(s, reg_grp_entry->reg_grp,
+                                                  reg_grp_offset,
+                                                  &reg_grp_entry->size);
+            if (rc < 0) {
+                xen_pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU) {
+            if (xen_pt_emu_reg_grps[i].emu_regs) {
+                int j = 0;
+                XenPTRegInfo *regs = xen_pt_emu_reg_grps[i].emu_regs;
+                /* initialize capability register */
+                for (j = 0; regs->size != 0; j++, regs++) {
+                    /* initialize capability register */
+                    rc = xen_pt_config_reg_init(s, reg_grp_entry, regs);
+                    if (rc < 0) {
+                        xen_pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void xen_pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgA-00018K-Fb; Thu, 14 Jun 2012 17:17:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg9-00017D-0s
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:53 +0000
Received: from [85.158.143.35:4287] by server-1.bemta-4.messagelabs.com id
	A0/CF-24392-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339694270!4462538!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 661 invoked from network); 14 Jun 2012 17:17:51 -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 Jun 2012 17:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113173"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-MB;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:40 +0100
Message-ID: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.

Changes since the last version:
  - New patch that introduce a new qdev-property pci-host-devaddr.
  => the "export pci_parse_devaddr" patch is not anymore usefull.

Thanks,


Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_SFP_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce XenHostPCIDevice to access a pci device on the host.
  pci.c: Add opaque argument to pci_for_each_device.
  qdev-properties: Introduce pci-host-devaddr.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

 configure                |   29 +
 hw/apic-msidef.h         |   30 +
 hw/apic.c                |   11 +-
 hw/i386/Makefile.objs    |    2 +
 hw/pci.c                 |   11 +-
 hw/pci.h                 |    4 +-
 hw/pci_ids.h             |    1 +
 hw/qdev-properties.c     |  107 +++
 hw/qdev.h                |    3 +
 hw/xen-host-pci-device.c |  396 ++++++++++
 hw/xen-host-pci-device.h |   55 ++
 hw/xen_common.h          |    3 +
 hw/xen_platform.c        |    8 +-
 hw/xen_pt.c              |  851 +++++++++++++++++++++
 hw/xen_pt.h              |  301 ++++++++
 hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c          |  620 +++++++++++++++
 qemu-common.h            |    7 +
 xen-all.c                |   12 +
 19 files changed, 4301 insertions(+), 19 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h
 create mode 100644 hw/xen_pt.c
 create mode 100644 hw/xen_pt.h
 create mode 100644 hw/xen_pt_config_init.c
 create mode 100644 hw/xen_pt_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDg9-00017i-Hz; Thu, 14 Jun 2012 17:17:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg7-00016z-VQ
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:52 +0000
Received: from [193.109.254.147:9178] by server-11.bemta-14.messagelabs.com id
	FE/86-02727-FBC1ADF4; Thu, 14 Jun 2012 17:17:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31172 invoked from network); 14 Jun 2012 17:17:50 -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;
	14 Jun 2012 17:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113170"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-R0;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:45 +0100
Message-ID: <1339693309-15192-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 5/9] qdev-properties: Introduce
	pci-host-devaddr.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 property will be used to specify a host pci device address.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/qdev-properties.c |  107 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h            |    3 +
 qemu-common.h        |    7 +++
 3 files changed, 117 insertions(+), 0 deletions(-)

diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 9ae3187..43e1964 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -899,6 +899,113 @@ PropertyInfo qdev_prop_blocksize = {
     .set   = set_blocksize,
 };
 
+/* --- pci host address --- */
+
+static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    char buffer[] = "xxxx:xx:xx.x";
+    char *p = buffer;
+    int rc = 0;
+
+    rc = snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
+                  addr->domain, addr->bus, addr->slot, addr->function);
+    assert(rc == sizeof(buffer) - 1);
+
+    visit_type_str(v, &p, name, errp);
+}
+
+/*
+ * Parse [<domain>:]<bus>:<slot>.<func>
+ *   if <domain> is not supplied, it's assumed to be 0.
+ */
+static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    Error *local_err = NULL;
+    char *str, *p;
+    char *e;
+    unsigned long val;
+    unsigned long dom = 0, bus = 0;
+    unsigned int slot = 0, func = 0;
+
+    if (dev->state != DEV_STATE_CREATED) {
+        error_set(errp, QERR_PERMISSION_DENIED);
+        return;
+    }
+
+    visit_type_str(v, &str, name, &local_err);
+    if (local_err) {
+        error_propagate(errp, local_err);
+        return;
+    }
+
+    p = str;
+    val = strtoul(p, &e, 16);
+    if (e == p || *e != ':') {
+        goto inval;
+    }
+    bus = val;
+
+    p = e + 1;
+    val = strtoul(p, &e, 16);
+    if (e == p) {
+        goto inval;
+    }
+    if (*e == ':') {
+        dom = bus;
+        bus = val;
+        p = e + 1;
+        val = strtoul(p, &e, 16);
+        if (e == p) {
+            goto inval;
+        }
+    }
+    slot = val;
+
+    if (*e != '.') {
+        goto inval;
+    }
+    p = e + 1;
+    val = strtoul(p, &e, 10);
+    if (e == p) {
+        goto inval;
+    }
+    func = val;
+
+    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7) {
+        goto inval;
+    }
+
+    if (*e) {
+        goto inval;
+    }
+
+    addr->domain = dom;
+    addr->bus = bus;
+    addr->slot = slot;
+    addr->function = func;
+
+    g_free(str);
+    return;
+
+inval:
+    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+    g_free(str);
+}
+
+PropertyInfo qdev_prop_pci_host_devaddr = {
+    .name = "pci-host-devaddr",
+    .get = get_pci_host_devaddr,
+    .set = set_pci_host_devaddr,
+};
+
 /* --- public helpers --- */
 
 static Property *qdev_prop_walk(Property *props, const char *name)
diff --git a/hw/qdev.h b/hw/qdev.h
index 5386b16..8746f84 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -223,6 +223,7 @@ extern PropertyInfo qdev_prop_netdev;
 extern PropertyInfo qdev_prop_vlan;
 extern PropertyInfo qdev_prop_pci_devfn;
 extern PropertyInfo qdev_prop_blocksize;
+extern PropertyInfo qdev_prop_pci_host_devaddr;
 
 #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
         .name      = (_name),                                    \
@@ -286,6 +287,8 @@ extern PropertyInfo qdev_prop_blocksize;
                         LostTickPolicy)
 #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
     DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
+#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
+    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
 
 #define DEFINE_PROP_END_OF_LIST()               \
     {}
diff --git a/qemu-common.h b/qemu-common.h
index 91e0562..0d6e51c 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
     LOST_TICK_MAX
 } LostTickPolicy;
 
+typedef struct PCIHostDeviceAddress {
+    unsigned int domain;
+    unsigned int bus;
+    unsigned int slot;
+    unsigned int function;
+} PCIHostDeviceAddress;
+
 void tcg_exec_init(unsigned long tb_size);
 bool tcg_enabled(void);
 
-- 
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 Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDg8-00017F-OJ; Thu, 14 Jun 2012 17:17:52 +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 1SfDg7-00016s-6Z
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:51 +0000
Received: from [85.158.143.35:4235] by server-3.bemta-4.messagelabs.com id
	6A/CA-05808-EBC1ADF4; Thu, 14 Jun 2012 17:17:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339694268!4890212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6118 invoked from network); 14 Jun 2012 17:17:49 -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;
	14 Jun 2012 17:17:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787491"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Td;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:48 +0100
Message-ID: <1339693309-15192-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 8/9] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 31 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..6e2eb71
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,30 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 5fbf01c..60552df 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -23,19 +23,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define SYNC_FROM_VAPIC                 0x1
 #define SYNC_TO_VAPIC                   0x2
 #define SYNC_ISR_IRR_TO_VAPIC           0x4
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgB-00018q-9k; Thu, 14 Jun 2012 17:17:55 +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 1SfDg9-00017D-G5
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:53 +0000
Received: from [85.158.143.35:4289] by server-1.bemta-4.messagelabs.com id
	C0/CF-24392-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339694268!4890212!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6141 invoked from network); 14 Jun 2012 17:17:51 -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;
	14 Jun 2012 17:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-PS;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:43 +0100
Message-ID: <1339693309-15192-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 3/9] Introduce XenHostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/i386/Makefile.objs    |    1 +
 hw/xen-host-pci-device.c |  396 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen-host-pci-device.h |   55 +++++++
 3 files changed, 452 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index d43f1df..b719d8e 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -7,6 +7,7 @@ obj-y += debugcon.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
new file mode 100644
index 0000000..e7ff680
--- /dev/null
+++ b/hw/xen-host-pci-device.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "xen-host-pci-device.h"
+
+#define XEN_HOST_PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+#ifdef XEN_HOST_PCI_DEVICE_DEBUG
+#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
+#else
+#  define XEN_HOST_PCI_LOG(f, a...) (void)0
+#endif
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_MEM_64       0x00100000
+
+static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
+                                   const char *name, char *buf, ssize_t size)
+{
+    int rc;
+
+    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
+                  d->domain, d->bus, d->dev, d->func, name);
+
+    if (rc >= size || rc < 0) {
+        /* The ouput is truncated or an other error is encountered */
+        return -ENODEV;
+    }
+    return 0;
+}
+
+
+/* This size should be enough to read the first 7 lines of a ressource file */
+#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
+static int xen_host_pci_get_resource(XenHostPCIDevice *d)
+{
+    int i, rc, fd;
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+    unsigned long long start, end, flags, size;
+    char *endptr, *s;
+    uint8_t type;
+
+    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    rc = 0;
+
+    s = buf;
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        type = 0;
+
+        start = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        end = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        flags = strtoll(s, &endptr, 16);
+        if (*endptr != '\n' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (flags & IORESOURCE_IO) {
+            type |= XEN_HOST_PCI_REGION_TYPE_IO;
+        }
+        if (flags & IORESOURCE_MEM) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
+        }
+        if (flags & IORESOURCE_PREFETCH) {
+            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
+        }
+        if (flags & IORESOURCE_MEM_64) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].type = type;
+            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.type = type;
+            d->rom.bus_flags = flags & IORESOURCE_BITS;
+        }
+    }
+    if (i != PCI_NUM_REGIONS) {
+        /* Invalid format or input to short */
+        rc = -ENODEV;
+    }
+
+out:
+    close(fd);
+    return rc;
+}
+
+/* This size should be enough to read a long from a file */
+#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 22
+static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
+                                  unsigned int *pvalue, int base)
+{
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
+    int fd, rc;
+    unsigned long value;
+    char *endptr;
+
+    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    value = strtol(buf, &endptr, base);
+    if (endptr == buf || *endptr != '\n') {
+        rc = -1;
+    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
+        rc = -errno;
+    } else {
+        rc = 0;
+        *pvalue = value;
+    }
+out:
+    close(fd);
+    return rc;
+}
+
+static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 16);
+}
+
+static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 10);
+}
+
+static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
+        return false;
+    }
+    return !stat(path, &buf);
+}
+
+static int xen_host_pci_config_open(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    int rc;
+
+    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    d->config_fd = open(path, O_RDWR);
+    if (d->config_fd < 0) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_read(XenHostPCIDevice *d,
+                                    int pos, void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pread(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_write(XenHostPCIDevice *d,
+                                     int pos, const void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pwrite(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
+    if (!rc) {
+        *p = buf;
+    }
+    return rc;
+}
+
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
+    if (!rc) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
+    if (!rc) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_read(d, pos, buf, len);
+}
+
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
+{
+    return xen_host_pci_config_write(d, pos, &data, 1);
+}
+
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return xen_host_pci_config_write(d, pos, &data, 2);
+}
+
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return xen_host_pci_config_write(d, pos, &data, 4);
+}
+
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_write(d, pos, buf, len);
+}
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (xen_host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return -1;
+}
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func)
+{
+    unsigned int v;
+    int rc = 0;
+
+    d->config_fd = -1;
+    d->domain = domain;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    rc = xen_host_pci_config_open(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_resource(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
+    if (rc) {
+        goto error;
+    }
+    d->vendor_id = v;
+    rc = xen_host_pci_get_hex_value(d, "device", &v);
+    if (rc) {
+        goto error;
+    }
+    d->device_id = v;
+    rc = xen_host_pci_get_dec_value(d, "irq", &v);
+    if (rc) {
+        goto error;
+    }
+    d->irq = v;
+    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+
+    return 0;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+    return rc;
+}
+
+void xen_host_pci_device_put(XenHostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+}
diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
new file mode 100644
index 0000000..0079dac
--- /dev/null
+++ b/hw/xen-host-pci-device.h
@@ -0,0 +1,55 @@
+#ifndef XEN_HOST_PCI_DEVICE_H
+#define XEN_HOST_PCI_DEVICE_H
+
+#include "pci.h"
+
+enum {
+    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
+    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
+    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
+    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
+};
+
+typedef struct XenHostPCIIORegion {
+    pcibus_t base_addr;
+    pcibus_t size;
+    uint8_t type;
+    uint8_t bus_flags; /* Bus-specific bits */
+} XenHostPCIIORegion;
+
+typedef struct XenHostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    int irq;
+
+    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    XenHostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} XenHostPCIDevice;
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func);
+void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
+
+#endif /* !XEN_HOST_PCI_DEVICE_H_ */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDg9-00017Q-4A; Thu, 14 Jun 2012 17:17:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg7-00016t-Ah
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:51 +0000
Received: from [193.109.254.147:9138] by server-12.bemta-14.messagelabs.com id
	0F/FF-12998-EBC1ADF4; Thu, 14 Jun 2012 17:17:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31120 invoked from network); 14 Jun 2012 17:17:50 -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;
	14 Jun 2012 17:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113169"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-QM;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:44 +0100
Message-ID: <1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 4/9] pci.c: Add opaque argument to
	pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The purpose is to have a more generic pci_for_each_device by passing an extra
argument to the function called on every device.

This patch will be used in a next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci.c          |   11 +++++++----
 hw/pci.h          |    4 +++-
 hw/xen_platform.c |    8 ++++----
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 127b7ac..d6537e3 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
 };
 
 static void pci_for_each_device_under_bus(PCIBus *bus,
-                                          void (*fn)(PCIBus *b, PCIDevice *d))
+                                          void (*fn)(PCIBus *b, PCIDevice *d,
+                                                     void *opaque),
+                                          void *opaque)
 {
     PCIDevice *d;
     int devfn;
@@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
     for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
         d = bus->devices[devfn];
         if (d) {
-            fn(bus, d);
+            fn(bus, d, opaque);
         }
     }
 }
 
 void pci_for_each_device(PCIBus *bus, int bus_num,
-                         void (*fn)(PCIBus *b, PCIDevice *d))
+                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
+                         void *opaque)
 {
     bus = pci_find_bus_nr(bus, bus_num);
 
     if (bus) {
-        pci_for_each_device_under_bus(bus, fn);
+        pci_for_each_device_under_bus(bus, fn, opaque);
     }
 }
 
diff --git a/hw/pci.h b/hw/pci.h
index 7f223c0..95b608c 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
 PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
                                const char *default_devaddr);
 int pci_bus_num(PCIBus *s);
-void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
+void pci_for_each_device(PCIBus *bus, int bus_num,
+                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
+                         void *opaque);
 PCIBus *pci_find_root_bus(int domain);
 int pci_find_domain(const PCIBus *bus);
 PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0214f37..c1fe984 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 #define UNPLUG_ALL_NICS 2
 #define UNPLUG_AUX_IDE_DISKS 4
 
-static void unplug_nic(PCIBus *b, PCIDevice *d)
+static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_NETWORK_ETHERNET) {
@@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_nics(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_nic);
+    pci_for_each_device(bus, 0, unplug_nic, NULL);
 }
 
-static void unplug_disks(PCIBus *b, PCIDevice *d)
+static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_STORAGE_IDE) {
@@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_disks(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_disks);
+    pci_for_each_device(bus, 0, unplug_disks, NULL);
 }
 
 static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDg8-00017F-OJ; Thu, 14 Jun 2012 17:17:52 +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 1SfDg7-00016s-6Z
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:51 +0000
Received: from [85.158.143.35:4235] by server-3.bemta-4.messagelabs.com id
	6A/CA-05808-EBC1ADF4; Thu, 14 Jun 2012 17:17:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339694268!4890212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6118 invoked from network); 14 Jun 2012 17:17:49 -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;
	14 Jun 2012 17:17:49 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787491"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-Td;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:48 +0100
Message-ID: <1339693309-15192-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 8/9] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 31 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..6e2eb71
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,30 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 5fbf01c..60552df 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -23,19 +23,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define SYNC_FROM_VAPIC                 0x1
 #define SYNC_TO_VAPIC                   0x2
 #define SYNC_ISR_IRR_TO_VAPIC           0x4
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDg9-00017i-Hz; Thu, 14 Jun 2012 17:17:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg7-00016z-VQ
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:52 +0000
Received: from [193.109.254.147:9178] by server-11.bemta-14.messagelabs.com id
	FE/86-02727-FBC1ADF4; Thu, 14 Jun 2012 17:17:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31172 invoked from network); 14 Jun 2012 17:17:50 -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;
	14 Jun 2012 17:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113170"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-R0;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:45 +0100
Message-ID: <1339693309-15192-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 5/9] qdev-properties: Introduce
	pci-host-devaddr.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 property will be used to specify a host pci device address.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/qdev-properties.c |  107 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h            |    3 +
 qemu-common.h        |    7 +++
 3 files changed, 117 insertions(+), 0 deletions(-)

diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 9ae3187..43e1964 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -899,6 +899,113 @@ PropertyInfo qdev_prop_blocksize = {
     .set   = set_blocksize,
 };
 
+/* --- pci host address --- */
+
+static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    char buffer[] = "xxxx:xx:xx.x";
+    char *p = buffer;
+    int rc = 0;
+
+    rc = snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
+                  addr->domain, addr->bus, addr->slot, addr->function);
+    assert(rc == sizeof(buffer) - 1);
+
+    visit_type_str(v, &p, name, errp);
+}
+
+/*
+ * Parse [<domain>:]<bus>:<slot>.<func>
+ *   if <domain> is not supplied, it's assumed to be 0.
+ */
+static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
+                                 const char *name, Error **errp)
+{
+    DeviceState *dev = DEVICE(obj);
+    Property *prop = opaque;
+    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
+    Error *local_err = NULL;
+    char *str, *p;
+    char *e;
+    unsigned long val;
+    unsigned long dom = 0, bus = 0;
+    unsigned int slot = 0, func = 0;
+
+    if (dev->state != DEV_STATE_CREATED) {
+        error_set(errp, QERR_PERMISSION_DENIED);
+        return;
+    }
+
+    visit_type_str(v, &str, name, &local_err);
+    if (local_err) {
+        error_propagate(errp, local_err);
+        return;
+    }
+
+    p = str;
+    val = strtoul(p, &e, 16);
+    if (e == p || *e != ':') {
+        goto inval;
+    }
+    bus = val;
+
+    p = e + 1;
+    val = strtoul(p, &e, 16);
+    if (e == p) {
+        goto inval;
+    }
+    if (*e == ':') {
+        dom = bus;
+        bus = val;
+        p = e + 1;
+        val = strtoul(p, &e, 16);
+        if (e == p) {
+            goto inval;
+        }
+    }
+    slot = val;
+
+    if (*e != '.') {
+        goto inval;
+    }
+    p = e + 1;
+    val = strtoul(p, &e, 10);
+    if (e == p) {
+        goto inval;
+    }
+    func = val;
+
+    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7) {
+        goto inval;
+    }
+
+    if (*e) {
+        goto inval;
+    }
+
+    addr->domain = dom;
+    addr->bus = bus;
+    addr->slot = slot;
+    addr->function = func;
+
+    g_free(str);
+    return;
+
+inval:
+    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
+    g_free(str);
+}
+
+PropertyInfo qdev_prop_pci_host_devaddr = {
+    .name = "pci-host-devaddr",
+    .get = get_pci_host_devaddr,
+    .set = set_pci_host_devaddr,
+};
+
 /* --- public helpers --- */
 
 static Property *qdev_prop_walk(Property *props, const char *name)
diff --git a/hw/qdev.h b/hw/qdev.h
index 5386b16..8746f84 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -223,6 +223,7 @@ extern PropertyInfo qdev_prop_netdev;
 extern PropertyInfo qdev_prop_vlan;
 extern PropertyInfo qdev_prop_pci_devfn;
 extern PropertyInfo qdev_prop_blocksize;
+extern PropertyInfo qdev_prop_pci_host_devaddr;
 
 #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
         .name      = (_name),                                    \
@@ -286,6 +287,8 @@ extern PropertyInfo qdev_prop_blocksize;
                         LostTickPolicy)
 #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
     DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
+#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
+    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
 
 #define DEFINE_PROP_END_OF_LIST()               \
     {}
diff --git a/qemu-common.h b/qemu-common.h
index 91e0562..0d6e51c 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
     LOST_TICK_MAX
 } LostTickPolicy;
 
+typedef struct PCIHostDeviceAddress {
+    unsigned int domain;
+    unsigned int bus;
+    unsigned int slot;
+    unsigned int function;
+} PCIHostDeviceAddress;
+
 void tcg_exec_init(unsigned long tb_size);
 bool tcg_enabled(void);
 
-- 
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 Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgB-00018q-9k; Thu, 14 Jun 2012 17:17:55 +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 1SfDg9-00017D-G5
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:53 +0000
Received: from [85.158.143.35:4289] by server-1.bemta-4.messagelabs.com id
	C0/CF-24392-0CC1ADF4; Thu, 14 Jun 2012 17:17:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1339694268!4890212!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjAxOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6141 invoked from network); 14 Jun 2012 17:17:51 -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;
	14 Jun 2012 17:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="198787495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-PS;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:43 +0100
Message-ID: <1339693309-15192-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 3/9] Introduce XenHostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/i386/Makefile.objs    |    1 +
 hw/xen-host-pci-device.c |  396 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/xen-host-pci-device.h |   55 +++++++
 3 files changed, 452 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen-host-pci-device.c
 create mode 100644 hw/xen-host-pci-device.h

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index d43f1df..b719d8e 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -7,6 +7,7 @@ obj-y += debugcon.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
new file mode 100644
index 0000000..e7ff680
--- /dev/null
+++ b/hw/xen-host-pci-device.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "xen-host-pci-device.h"
+
+#define XEN_HOST_PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+#ifdef XEN_HOST_PCI_DEVICE_DEBUG
+#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
+#else
+#  define XEN_HOST_PCI_LOG(f, a...) (void)0
+#endif
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_MEM_64       0x00100000
+
+static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
+                                   const char *name, char *buf, ssize_t size)
+{
+    int rc;
+
+    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
+                  d->domain, d->bus, d->dev, d->func, name);
+
+    if (rc >= size || rc < 0) {
+        /* The ouput is truncated or an other error is encountered */
+        return -ENODEV;
+    }
+    return 0;
+}
+
+
+/* This size should be enough to read the first 7 lines of a ressource file */
+#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
+static int xen_host_pci_get_resource(XenHostPCIDevice *d)
+{
+    int i, rc, fd;
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+    unsigned long long start, end, flags, size;
+    char *endptr, *s;
+    uint8_t type;
+
+    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    rc = 0;
+
+    s = buf;
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        type = 0;
+
+        start = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        end = strtoll(s, &endptr, 16);
+        if (*endptr != ' ' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+        flags = strtoll(s, &endptr, 16);
+        if (*endptr != '\n' || s == endptr) {
+            break;
+        }
+        s = endptr + 1;
+
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (flags & IORESOURCE_IO) {
+            type |= XEN_HOST_PCI_REGION_TYPE_IO;
+        }
+        if (flags & IORESOURCE_MEM) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
+        }
+        if (flags & IORESOURCE_PREFETCH) {
+            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
+        }
+        if (flags & IORESOURCE_MEM_64) {
+            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].type = type;
+            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.type = type;
+            d->rom.bus_flags = flags & IORESOURCE_BITS;
+        }
+    }
+    if (i != PCI_NUM_REGIONS) {
+        /* Invalid format or input to short */
+        rc = -ENODEV;
+    }
+
+out:
+    close(fd);
+    return rc;
+}
+
+/* This size should be enough to read a long from a file */
+#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 22
+static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
+                                  unsigned int *pvalue, int base)
+{
+    char path[PATH_MAX];
+    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
+    int fd, rc;
+    unsigned long value;
+    char *endptr;
+
+    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    fd = open(path, O_RDONLY);
+    if (fd == -1) {
+        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    do {
+        rc = read(fd, &buf, sizeof (buf) - 1);
+        if (rc < 0 && errno != EINTR) {
+            rc = -errno;
+            goto out;
+        }
+    } while (rc < 0);
+    buf[rc] = 0;
+    value = strtol(buf, &endptr, base);
+    if (endptr == buf || *endptr != '\n') {
+        rc = -1;
+    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
+        rc = -errno;
+    } else {
+        rc = 0;
+        *pvalue = value;
+    }
+out:
+    close(fd);
+    return rc;
+}
+
+static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 16);
+}
+
+static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
+                                             const char *name,
+                                             unsigned int *pvalue)
+{
+    return xen_host_pci_get_value(d, name, pvalue, 10);
+}
+
+static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
+        return false;
+    }
+    return !stat(path, &buf);
+}
+
+static int xen_host_pci_config_open(XenHostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    int rc;
+
+    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
+    if (rc) {
+        return rc;
+    }
+    d->config_fd = open(path, O_RDWR);
+    if (d->config_fd < 0) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_read(XenHostPCIDevice *d,
+                                    int pos, void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pread(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+static int xen_host_pci_config_write(XenHostPCIDevice *d,
+                                     int pos, const void *buf, int len)
+{
+    int rc;
+
+    do {
+        rc = pwrite(d->config_fd, buf, len, pos);
+    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+    if (rc != len) {
+        return -errno;
+    }
+    return 0;
+}
+
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
+    if (!rc) {
+        *p = buf;
+    }
+    return rc;
+}
+
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
+    if (!rc) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
+    if (!rc) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_read(d, pos, buf, len);
+}
+
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
+{
+    return xen_host_pci_config_write(d, pos, &data, 1);
+}
+
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return xen_host_pci_config_write(d, pos, &data, 2);
+}
+
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return xen_host_pci_config_write(d, pos, &data, 4);
+}
+
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return xen_host_pci_config_write(d, pos, buf, len);
+}
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (xen_host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return -1;
+}
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func)
+{
+    unsigned int v;
+    int rc = 0;
+
+    d->config_fd = -1;
+    d->domain = domain;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    rc = xen_host_pci_config_open(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_resource(d);
+    if (rc) {
+        goto error;
+    }
+    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
+    if (rc) {
+        goto error;
+    }
+    d->vendor_id = v;
+    rc = xen_host_pci_get_hex_value(d, "device", &v);
+    if (rc) {
+        goto error;
+    }
+    d->device_id = v;
+    rc = xen_host_pci_get_dec_value(d, "irq", &v);
+    if (rc) {
+        goto error;
+    }
+    d->irq = v;
+    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+
+    return 0;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+    return rc;
+}
+
+void xen_host_pci_device_put(XenHostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+        d->config_fd = -1;
+    }
+}
diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
new file mode 100644
index 0000000..0079dac
--- /dev/null
+++ b/hw/xen-host-pci-device.h
@@ -0,0 +1,55 @@
+#ifndef XEN_HOST_PCI_DEVICE_H
+#define XEN_HOST_PCI_DEVICE_H
+
+#include "pci.h"
+
+enum {
+    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
+    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
+    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
+    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
+};
+
+typedef struct XenHostPCIIORegion {
+    pcibus_t base_addr;
+    pcibus_t size;
+    uint8_t type;
+    uint8_t bus_flags; /* Bus-specific bits */
+} XenHostPCIIORegion;
+
+typedef struct XenHostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    int irq;
+
+    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    XenHostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} XenHostPCIDevice;
+
+int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
+                            uint8_t bus, uint8_t dev, uint8_t func);
+void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
+
+int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
+int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
+int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
+int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
+int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
+int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
+int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
+                           int len);
+
+int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
+
+#endif /* !XEN_HOST_PCI_DEVICE_H_ */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDg9-00017Q-4A; Thu, 14 Jun 2012 17:17:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfDg7-00016t-Ah
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:51 +0000
Received: from [193.109.254.147:9138] by server-12.bemta-14.messagelabs.com id
	0F/FF-12998-EBC1ADF4; Thu, 14 Jun 2012 17:17:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1339694268!9646223!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31120 invoked from network); 14 Jun 2012 17:17:50 -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;
	14 Jun 2012 17:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113169"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-QM;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:44 +0100
Message-ID: <1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 4/9] pci.c: Add opaque argument to
	pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The purpose is to have a more generic pci_for_each_device by passing an extra
argument to the function called on every device.

This patch will be used in a next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pci.c          |   11 +++++++----
 hw/pci.h          |    4 +++-
 hw/xen_platform.c |    8 ++++----
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 127b7ac..d6537e3 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
 };
 
 static void pci_for_each_device_under_bus(PCIBus *bus,
-                                          void (*fn)(PCIBus *b, PCIDevice *d))
+                                          void (*fn)(PCIBus *b, PCIDevice *d,
+                                                     void *opaque),
+                                          void *opaque)
 {
     PCIDevice *d;
     int devfn;
@@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
     for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
         d = bus->devices[devfn];
         if (d) {
-            fn(bus, d);
+            fn(bus, d, opaque);
         }
     }
 }
 
 void pci_for_each_device(PCIBus *bus, int bus_num,
-                         void (*fn)(PCIBus *b, PCIDevice *d))
+                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
+                         void *opaque)
 {
     bus = pci_find_bus_nr(bus, bus_num);
 
     if (bus) {
-        pci_for_each_device_under_bus(bus, fn);
+        pci_for_each_device_under_bus(bus, fn, opaque);
     }
 }
 
diff --git a/hw/pci.h b/hw/pci.h
index 7f223c0..95b608c 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
 PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
                                const char *default_devaddr);
 int pci_bus_num(PCIBus *s);
-void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
+void pci_for_each_device(PCIBus *bus, int bus_num,
+                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
+                         void *opaque);
 PCIBus *pci_find_root_bus(int domain);
 int pci_find_domain(const PCIBus *bus);
 PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0214f37..c1fe984 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 #define UNPLUG_ALL_NICS 2
 #define UNPLUG_AUX_IDE_DISKS 4
 
-static void unplug_nic(PCIBus *b, PCIDevice *d)
+static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_NETWORK_ETHERNET) {
@@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_nics(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_nic);
+    pci_for_each_device(bus, 0, unplug_nic, NULL);
 }
 
-static void unplug_disks(PCIBus *b, PCIDevice *d)
+static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
             PCI_CLASS_STORAGE_IDE) {
@@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
 
 static void pci_unplug_disks(PCIBus *bus)
 {
-    pci_for_each_device(bus, 0, unplug_disks);
+    pci_for_each_device(bus, 0, unplug_disks, NULL);
 }
 
 static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgB-00019C-Mp; Thu, 14 Jun 2012 17:17:55 +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 1SfDgA-00017D-7I
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:54 +0000
Received: from [85.158.143.35:52168] by server-1.bemta-4.messagelabs.com id
	F5/CF-24392-1CC1ADF4; Thu, 14 Jun 2012 17:17:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339694270!4462538!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 671 invoked from network); 14 Jun 2012 17:17:52 -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 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113176"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-UU;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:49 +0100
Message-ID: <1339693309-15192-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Shan Haitao <haitao.shan@intel.com>, Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 9/9] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    2 +-
 hw/xen_pt.c             |   31 +++-
 hw/xen_pt.h             |   51 ++++
 hw/xen_pt_config_init.c |  471 +++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c         |  620 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 1173 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen_pt_msi.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index e361a92..d364c37 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,7 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 92ad0fa..3b6d186 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(xen_pt_msi_setup, xen_pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(xen_pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -534,7 +548,15 @@ static void xen_pt_region_update(XenPCIPassthroughState *s,
     };
 
     bar = xen_pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = xen_pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -764,6 +786,13 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        xen_pt_msi_disable(s);
+    }
+    if (s->msix) {
+        xen_pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         xen_pt_mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 4b76073..41904ec 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -160,6 +160,36 @@ typedef struct XenPTRegGroup {
 
 
 #define XEN_PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -172,6 +202,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -247,4 +280,22 @@ static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int xen_pt_msi_setup(XenPCIPassthroughState *s);
+int xen_pt_msi_update(XenPCIPassthroughState *d);
+void xen_pt_msi_disable(XenPCIPassthroughState *s);
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void xen_pt_msix_delete(XenPCIPassthroughState *s);
+int xen_pt_msix_update(XenPCIPassthroughState *s);
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void xen_pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 1d97876..00eb3d9 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1022,6 +1022,410 @@ static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool xen_pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int xen_pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        XEN_PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msgctrl_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t raw_val;
+
+    /* Currently no support for multi-vector */
+    if (*val & PCI_MSI_FLAGS_QSIZE) {
+        XEN_PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *val);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    raw_val = *val;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (raw_val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            XEN_PT_LOG(&s->dev, "setup MSI\n");
+            if (xen_pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (xen_pt_msi_update(s)) {
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *val &= ~PCI_MSI_FLAGS_ENABLE;
+    *val |= raw_val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int xen_pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = XEN_PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int xen_pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (xen_pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = XEN_PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int xen_pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int xen_pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        XEN_PT_ERR(&s->dev,
+                   "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!xen_pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        XEN_PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msi[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = xen_pt_msgctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgaddr64_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int xen_pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        XEN_PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                     XenPTReg *cfg_entry, uint16_t *val,
+                                     uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*val & PCI_MSIX_FLAGS_ENABLE)
+        && !(*val & PCI_MSIX_FLAGS_MASKALL)) {
+        xen_pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        XEN_PT_LOG(&s->dev, "%s MSI-X\n",
+                   s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msix[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = xen_pt_msixctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1115,6 +1519,49 @@ static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int xen_pt_msi_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int xen_pt_msix_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = xen_pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid xen_pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
     /* Header Type0 reg group */
@@ -1155,6 +1602,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .grp_size   = 0x04,
         .size_init  = xen_pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_msi_size_init,
+        .emu_regs = xen_pt_emu_reg_msi,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1199,6 +1654,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_pcie_size_init,
         .emu_regs = xen_pt_emu_reg_pcie,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = xen_pt_msix_size_init,
+        .emu_regs = xen_pt_emu_reg_msix,
+    },
     {
         .grp_size = 0,
     },
@@ -1384,6 +1847,14 @@ void xen_pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        xen_pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pt_msi.c b/hw/xen_pt_msi.c
new file mode 100644
index 0000000..2299cc7
--- /dev/null
+++ b/hw/xen_pt_msi.c
@@ -0,0 +1,620 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "apic-msidef.h"
+
+
+#define XEN_PT_AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define XEN_PT_GFLAGS_SHIFT_DEST_ID        0
+#define XEN_PT_GFLAGS_SHIFT_RH             8
+#define XEN_PT_GFLAGS_SHIFT_DM             9
+#define XEN_PT_GFLAGSSHIFT_DELIV_MODE     12
+#define XEN_PT_GFLAGSSHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
+        | (dm << XEN_PT_GFLAGS_SHIFT_DM)
+        | (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
+        | (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    xen_host_pci_get_word(&s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    xen_host_pci_set_word(&s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                          uint64_t addr,
+                          uint32_t data,
+                          int *ppirq,
+                          bool is_msix,
+                          int msix_entry,
+                          bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = XEN_PT_UNASSIGNED_PIRQ;
+        } else {
+            XEN_PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                       " (vec: %#x, entry: %#x)\n",
+                       *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, XEN_PT_AUTO_ASSIGN,
+                                     ppirq, PCI_DEVFN(s->real_device.dev,
+                                                      s->real_device.func),
+                                     s->real_device.bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            XEN_PT_ERR(&s->dev,
+                       "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                       is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
+               " (entry: %#x)\n",
+               is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        XEN_PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+                   is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                       is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            XEN_PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                       is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    XEN_PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+                   is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int xen_pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        XEN_PT_ERR(&s->dev,
+                   "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        XEN_PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    XEN_PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int xen_pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void xen_pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    xen_pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int xen_pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        xen_pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void xen_pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = XEN_PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != XEN_PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n",
+                           entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return xen_pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
+                       " already enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            xen_pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    XenHostPCIDevice *hd = &s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = xen_host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        XEN_PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device.io_regions[bar_index].base_addr;
+    XEN_PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    XEN_PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+               table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    XEN_PT_LOG(d, "mapping physical MSI-X table to %p\n",
+               msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void xen_pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        XEN_PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+                   msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:18:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDgB-00019C-Mp; Thu, 14 Jun 2012 17:17:55 +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 1SfDgA-00017D-7I
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 17:17:54 +0000
Received: from [85.158.143.35:52168] by server-1.bemta-4.messagelabs.com id
	F5/CF-24392-1CC1ADF4; Thu, 14 Jun 2012 17:17:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1339694270!4462538!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 671 invoked from network); 14 Jun 2012 17:17:52 -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 Jun 2012 17:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28113176"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 13:17:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 13:17:47 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfDUe-0006Jk-UU;
	Thu, 14 Jun 2012 18:06:00 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 14 Jun 2012 18:01:49 +0100
Message-ID: <1339693309-15192-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Shan Haitao <haitao.shan@intel.com>, Xen Devel <xen-devel@lists.xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V13 9/9] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/i386/Makefile.objs   |    2 +-
 hw/xen_pt.c             |   31 +++-
 hw/xen_pt.h             |   51 ++++
 hw/xen_pt_config_init.c |  471 +++++++++++++++++++++++++++++++++++
 hw/xen_pt_msi.c         |  620 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 1173 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen_pt_msi.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index e361a92..d364c37 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -8,7 +8,7 @@ obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 92ad0fa..3b6d186 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(xen_pt_msi_setup, xen_pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(xen_pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -534,7 +548,15 @@ static void xen_pt_region_update(XenPCIPassthroughState *s,
     };
 
     bar = xen_pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = xen_pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -764,6 +786,13 @@ static int xen_pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        xen_pt_msi_disable(s);
+    }
+    if (s->msix) {
+        xen_pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         xen_pt_mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 4b76073..41904ec 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -160,6 +160,36 @@ typedef struct XenPTRegGroup {
 
 
 #define XEN_PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -172,6 +202,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -247,4 +280,22 @@ static inline uint8_t xen_pt_pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int xen_pt_msi_setup(XenPCIPassthroughState *s);
+int xen_pt_msi_update(XenPCIPassthroughState *d);
+void xen_pt_msi_disable(XenPCIPassthroughState *s);
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void xen_pt_msix_delete(XenPCIPassthroughState *s);
+int xen_pt_msix_update(XenPCIPassthroughState *s);
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void xen_pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !XEN_PT_H */
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 1d97876..00eb3d9 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -1022,6 +1022,410 @@ static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool xen_pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int xen_pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        XEN_PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msgctrl_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t raw_val;
+
+    /* Currently no support for multi-vector */
+    if (*val & PCI_MSI_FLAGS_QSIZE) {
+        XEN_PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *val);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    raw_val = *val;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (raw_val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            XEN_PT_LOG(&s->dev, "setup MSI\n");
+            if (xen_pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (xen_pt_msi_update(s)) {
+                *val &= ~PCI_MSI_FLAGS_ENABLE;
+                XEN_PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *val &= ~PCI_MSI_FLAGS_ENABLE;
+    *val |= raw_val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int xen_pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                     XenPTRegInfo *reg, uint32_t real_offset,
+                                     uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = XEN_PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int xen_pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (xen_pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = XEN_PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int xen_pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int xen_pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry, uint32_t *val,
+                                      uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        XEN_PT_ERR(&s->dev,
+                   "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint16_t *val,
+                                    uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!xen_pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        XEN_PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            xen_pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msi[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = xen_pt_msgctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_common_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgaddr64_reg_init,
+        .u.dw.read  = xen_pt_long_reg_read,
+        .u.dw.write = xen_pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = xen_pt_msgdata_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int xen_pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                    XenPTRegInfo *reg, uint32_t real_offset,
+                                    uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        XEN_PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        xen_host_pci_set_word(&s->real_device, real_offset,
+                              reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                     XenPTReg *cfg_entry, uint16_t *val,
+                                     uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*val & PCI_MSIX_FLAGS_ENABLE)
+        && !(*val & PCI_MSIX_FLAGS_MASKALL)) {
+        xen_pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        XEN_PT_LOG(&s->dev, "%s MSI-X\n",
+                   s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo xen_pt_emu_reg_msix[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = xen_pt_ptr_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = xen_pt_msixctrl_reg_init,
+        .u.w.read   = xen_pt_word_reg_read,
+        .u.w.write  = xen_pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1115,6 +1519,49 @@ static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int xen_pt_msi_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int xen_pt_msix_size_init(XenPCIPassthroughState *s,
+                                 const XenPTRegGroupInfo *grp_reg,
+                                 uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = xen_pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        XEN_PT_ERR(&s->dev, "Internal error: Invalid xen_pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
     /* Header Type0 reg group */
@@ -1155,6 +1602,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .grp_size   = 0x04,
         .size_init  = xen_pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = xen_pt_msi_size_init,
+        .emu_regs = xen_pt_emu_reg_msi,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1199,6 +1654,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_pcie_size_init,
         .emu_regs = xen_pt_emu_reg_pcie,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = xen_pt_msix_size_init,
+        .emu_regs = xen_pt_emu_reg_msix,
+    },
     {
         .grp_size = 0,
     },
@@ -1384,6 +1847,14 @@ void xen_pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        xen_pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grps, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pt_msi.c b/hw/xen_pt_msi.c
new file mode 100644
index 0000000..2299cc7
--- /dev/null
+++ b/hw/xen_pt_msi.c
@@ -0,0 +1,620 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pt.h"
+#include "apic-msidef.h"
+
+
+#define XEN_PT_AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define XEN_PT_GFLAGS_SHIFT_DEST_ID        0
+#define XEN_PT_GFLAGS_SHIFT_RH             8
+#define XEN_PT_GFLAGS_SHIFT_DM             9
+#define XEN_PT_GFLAGSSHIFT_DELIV_MODE     12
+#define XEN_PT_GFLAGSSHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
+        | (dm << XEN_PT_GFLAGS_SHIFT_DM)
+        | (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
+        | (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    xen_host_pci_get_word(&s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    xen_host_pci_set_word(&s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                          uint64_t addr,
+                          uint32_t data,
+                          int *ppirq,
+                          bool is_msix,
+                          int msix_entry,
+                          bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = XEN_PT_UNASSIGNED_PIRQ;
+        } else {
+            XEN_PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                       " (vec: %#x, entry: %#x)\n",
+                       *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, XEN_PT_AUTO_ASSIGN,
+                                     ppirq, PCI_DEVFN(s->real_device.dev,
+                                                      s->real_device.func),
+                                     s->real_device.bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            XEN_PT_ERR(&s->dev,
+                       "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                       is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
+               " (entry: %#x)\n",
+               is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        XEN_PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+                   is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                       is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            XEN_PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                       is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    XEN_PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        XEN_PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+                   is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int xen_pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = XEN_PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        XEN_PT_ERR(&s->dev,
+                   "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        XEN_PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    XEN_PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int xen_pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void xen_pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    xen_pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = XEN_PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    XEN_PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == XEN_PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int xen_pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        xen_pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void xen_pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = XEN_PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int xen_pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != XEN_PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n",
+                           entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return xen_pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
+                       " already enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            xen_pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    XenHostPCIDevice *hd = &s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = xen_host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        XEN_PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = XEN_PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device.io_regions[bar_index].base_addr;
+    XEN_PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    XEN_PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+               table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        XEN_PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    XEN_PT_LOG(d, "mapping physical MSI-X table to %p\n",
+               msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void xen_pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        XEN_PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+                   msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 17:19:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDhY-0001vQ-PQ; Thu, 14 Jun 2012 17:19:20 +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 1SfDhX-0001uL-8C
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 17:19:19 +0000
Received: from [85.158.139.83:8331] by server-10.bemta-5.messagelabs.com id
	23/B9-02190-61D1ADF4; Thu, 14 Jun 2012 17:19:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339694356!27761777!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM1ODc1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16535 invoked from network); 14 Jun 2012 17:19:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 17:19:17 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 14 Jun 2012 10:19:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="scan'208,223";a="157667828"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 14 Jun 2012 10:19:15 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 14 Jun 2012 10:19:15 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Fri, 15 Jun 2012 01:19:13 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: add .poll method for mcelog device driver
Thread-Index: AQHNSZLddQXy2gd5YkW4phd9182UzZb5g2gwgABBt3CAAEm98A==
Date: Thu, 14 Jun 2012 17:19:13 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335233036@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
	<20120613182458.GA5813@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_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: add .poll method for mcelog device
	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

--_002_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Liu, Jinsong wrote:
>>> So another bug which is that mcelog is spinning at 100% CPU (and
>>> only under Xen).=20
>>>=20
>>> It seems to be doing:
>>>=20
>>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, =
[],
>>> 8) =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>>> =3D 0
>>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, =
[],
>>> 8) =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>>>=20
>>> constantly.
>>=20
>> I will debug it. I have try at my platform, but fail to reproduce it.
>> (You still use the config you send me last time, right?) Would you
>> tell me your step?=20
>>=20
>> Thanks,
>> Jinsong
>=20
> Have a look at it, it caused by NULL .poll method.
> Attached is the patch to fix this bug, but I cannot reproduce the bug
> at my platform, so would you please help me to test it at your side?=20
>=20

Ah I know how you trigger the bug - you run mcelog as daemon ... then spinn=
ing at CPU.
I update my patch as attached, and test at my platform OK now.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From 771bf5835a1ed9e439c7da289cb3a72ee8c9bd02 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 15 Jun 2012 09:03:39 +0800
Subject: [PATCH] xen/mce: add .poll method for mcelog device driver

If a driver leaves its poll method NULL, the device is assumed to
be both readable and writable without blocking.

This patch add .poll method to xen mcelog device driver, so that
when mcelog use system calls like ppoll or select, it would be
blocked when no data available, and avoid spinning at CPU.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 804aa3c..8feee08 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -41,6 +41,8 @@
 #include <linux/miscdevice.h>
 #include <linux/uaccess.h>
 #include <linux/capability.h>
+#include <linux/poll.h>
+#include <linux/sched.h>
=20
 #include <xen/interface/xen.h>
 #include <xen/events.h>
@@ -67,6 +69,8 @@ static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
 static int xen_mce_chrdev_open_count;	/* #times opened */
 static int xen_mce_chrdev_open_exclu;	/* already open exclusive? */
=20
+static DECLARE_WAIT_QUEUE_HEAD(xen_mce_chrdev_wait);
+
 static int xen_mce_chrdev_open(struct inode *inode, struct file *file)
 {
 	spin_lock(&xen_mce_chrdev_state_lock);
@@ -135,6 +139,16 @@ out:
 	return err ? err : buf - ubuf;
 }
=20
+static unsigned int xen_mce_chrdev_poll(struct file *file, poll_table *wai=
t)
+{
+	poll_wait(file, &xen_mce_chrdev_wait, wait);
+
+	if (xen_mcelog.next)
+		return POLLIN | POLLRDNORM;
+
+	return 0;
+}
+
 static long xen_mce_chrdev_ioctl(struct file *f, unsigned int cmd,
 				unsigned long arg)
 {
@@ -166,6 +180,7 @@ static const struct file_operations xen_mce_chrdev_ops =
=3D {
 	.open			=3D xen_mce_chrdev_open,
 	.release		=3D xen_mce_chrdev_release,
 	.read			=3D xen_mce_chrdev_read,
+	.poll			=3D xen_mce_chrdev_poll,
 	.unlocked_ioctl		=3D xen_mce_chrdev_ioctl,
 	.llseek			=3D no_llseek,
 };
@@ -329,6 +344,9 @@ static void xen_mce_work_fn(struct work_struct *work)
 		pr_err(XEN_MCELOG
 		       "Failed to handle nonurgent mc_info queue.\n");
=20
+	/* wake processes polling /dev/mcelog */
+	wake_up_interruptible(&xen_mce_chrdev_wait);
+
 	mutex_unlock(&mcelog_lock);
 }
 static DECLARE_WORK(xen_mce_work, xen_mce_work_fn);
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch"
Content-Description: 0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch";
	size=2464; creation-date="Thu, 14 Jun 2012 17:13:03 GMT";
	modification-date="Fri, 15 Jun 2012 01:06:00 GMT"
Content-Transfer-Encoding: base64

RnJvbSA3NzFiZjU4MzVhMWVkOWU0MzljN2RhMjg5Y2IzYTcyZWU4YzliZDAyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxNSBKdW4gMjAxMiAwOTowMzozOSArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IGFkZCAucG9sbCBtZXRob2QgZm9yIG1jZWxvZyBkZXZpY2UgZHJpdmVyCgpJZiBhIGRy
aXZlciBsZWF2ZXMgaXRzIHBvbGwgbWV0aG9kIE5VTEwsIHRoZSBkZXZpY2UgaXMgYXNzdW1lZCB0
bwpiZSBib3RoIHJlYWRhYmxlIGFuZCB3cml0YWJsZSB3aXRob3V0IGJsb2NraW5nLgoKVGhpcyBw
YXRjaCBhZGQgLnBvbGwgbWV0aG9kIHRvIHhlbiBtY2Vsb2cgZGV2aWNlIGRyaXZlciwgc28gdGhh
dAp3aGVuIG1jZWxvZyB1c2Ugc3lzdGVtIGNhbGxzIGxpa2UgcHBvbGwgb3Igc2VsZWN0LCBpdCB3
b3VsZCBiZQpibG9ja2VkIHdoZW4gbm8gZGF0YSBhdmFpbGFibGUsIGFuZCBhdm9pZCBzcGlubmlu
ZyBhdCBDUFUuCgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2ls
a0BvcmFjbGUuY29tPgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KLS0tCiBkcml2ZXJzL3hlbi9tY2Vsb2cuYyB8ICAgMTggKysrKysrKysrKysrKysr
KysrCiAxIGZpbGVzIGNoYW5nZWQsIDE4IGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vbWNlbG9nLmMgYi9kcml2ZXJzL3hlbi9tY2Vsb2cuYwpp
bmRleCA4MDRhYTNjLi44ZmVlZTA4IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9tY2Vsb2cuYwor
KysgYi9kcml2ZXJzL3hlbi9tY2Vsb2cuYwpAQCAtNDEsNiArNDEsOCBAQAogI2luY2x1ZGUgPGxp
bnV4L21pc2NkZXZpY2UuaD4KICNpbmNsdWRlIDxsaW51eC91YWNjZXNzLmg+CiAjaW5jbHVkZSA8
bGludXgvY2FwYWJpbGl0eS5oPgorI2luY2x1ZGUgPGxpbnV4L3BvbGwuaD4KKyNpbmNsdWRlIDxs
aW51eC9zY2hlZC5oPgogCiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS94ZW4uaD4KICNpbmNsdWRl
IDx4ZW4vZXZlbnRzLmg+CkBAIC02Nyw2ICs2OSw4IEBAIHN0YXRpYyBERUZJTkVfU1BJTkxPQ0so
eGVuX21jZV9jaHJkZXZfc3RhdGVfbG9jayk7CiBzdGF0aWMgaW50IHhlbl9tY2VfY2hyZGV2X29w
ZW5fY291bnQ7CS8qICN0aW1lcyBvcGVuZWQgKi8KIHN0YXRpYyBpbnQgeGVuX21jZV9jaHJkZXZf
b3Blbl9leGNsdTsJLyogYWxyZWFkeSBvcGVuIGV4Y2x1c2l2ZT8gKi8KIAorc3RhdGljIERFQ0xB
UkVfV0FJVF9RVUVVRV9IRUFEKHhlbl9tY2VfY2hyZGV2X3dhaXQpOworCiBzdGF0aWMgaW50IHhl
bl9tY2VfY2hyZGV2X29wZW4oc3RydWN0IGlub2RlICppbm9kZSwgc3RydWN0IGZpbGUgKmZpbGUp
CiB7CiAJc3Bpbl9sb2NrKCZ4ZW5fbWNlX2NocmRldl9zdGF0ZV9sb2NrKTsKQEAgLTEzNSw2ICsx
MzksMTYgQEAgb3V0OgogCXJldHVybiBlcnIgPyBlcnIgOiBidWYgLSB1YnVmOwogfQogCitzdGF0
aWMgdW5zaWduZWQgaW50IHhlbl9tY2VfY2hyZGV2X3BvbGwoc3RydWN0IGZpbGUgKmZpbGUsIHBv
bGxfdGFibGUgKndhaXQpCit7CisJcG9sbF93YWl0KGZpbGUsICZ4ZW5fbWNlX2NocmRldl93YWl0
LCB3YWl0KTsKKworCWlmICh4ZW5fbWNlbG9nLm5leHQpCisJCXJldHVybiBQT0xMSU4gfCBQT0xM
UkROT1JNOworCisJcmV0dXJuIDA7Cit9CisKIHN0YXRpYyBsb25nIHhlbl9tY2VfY2hyZGV2X2lv
Y3RsKHN0cnVjdCBmaWxlICpmLCB1bnNpZ25lZCBpbnQgY21kLAogCQkJCXVuc2lnbmVkIGxvbmcg
YXJnKQogewpAQCAtMTY2LDYgKzE4MCw3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZmlsZV9vcGVy
YXRpb25zIHhlbl9tY2VfY2hyZGV2X29wcyA9IHsKIAkub3BlbgkJCT0geGVuX21jZV9jaHJkZXZf
b3BlbiwKIAkucmVsZWFzZQkJPSB4ZW5fbWNlX2NocmRldl9yZWxlYXNlLAogCS5yZWFkCQkJPSB4
ZW5fbWNlX2NocmRldl9yZWFkLAorCS5wb2xsCQkJPSB4ZW5fbWNlX2NocmRldl9wb2xsLAogCS51
bmxvY2tlZF9pb2N0bAkJPSB4ZW5fbWNlX2NocmRldl9pb2N0bCwKIAkubGxzZWVrCQkJPSBub19s
bHNlZWssCiB9OwpAQCAtMzI5LDYgKzM0NCw5IEBAIHN0YXRpYyB2b2lkIHhlbl9tY2Vfd29ya19m
bihzdHJ1Y3Qgd29ya19zdHJ1Y3QgKndvcmspCiAJCXByX2VycihYRU5fTUNFTE9HCiAJCSAgICAg
ICAiRmFpbGVkIHRvIGhhbmRsZSBub251cmdlbnQgbWNfaW5mbyBxdWV1ZS5cbiIpOwogCisJLyog
d2FrZSBwcm9jZXNzZXMgcG9sbGluZyAvZGV2L21jZWxvZyAqLworCXdha2VfdXBfaW50ZXJydXB0
aWJsZSgmeGVuX21jZV9jaHJkZXZfd2FpdCk7CisKIAltdXRleF91bmxvY2soJm1jZWxvZ19sb2Nr
KTsKIH0KIHN0YXRpYyBERUNMQVJFX1dPUksoeGVuX21jZV93b3JrLCB4ZW5fbWNlX3dvcmtfZm4p
OwotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Jun 14 17:19:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 17:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfDhY-0001vQ-PQ; Thu, 14 Jun 2012 17:19:20 +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 1SfDhX-0001uL-8C
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 17:19:19 +0000
Received: from [85.158.139.83:8331] by server-10.bemta-5.messagelabs.com id
	23/B9-02190-61D1ADF4; Thu, 14 Jun 2012 17:19:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339694356!27761777!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM1ODc1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16535 invoked from network); 14 Jun 2012 17:19:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 17:19:17 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 14 Jun 2012 10:19:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="scan'208,223";a="157667828"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 14 Jun 2012 10:19:15 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 14 Jun 2012 10:19:15 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.90]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id
	14.01.0355.002; Fri, 15 Jun 2012 01:19:13 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen/mce: add .poll method for mcelog device driver
Thread-Index: AQHNSZLddQXy2gd5YkW4phd9182UzZb5g2gwgABBt3CAAEm98A==
Date: Thu, 14 Jun 2012 17:19:13 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335233036@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335228748@SHSMSX101.ccr.corp.intel.com>
	<20120612124015.GB559@phenom.dumpdata.com>
	<20120613182458.GA5813@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_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/mce: add .poll method for mcelog device
	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

--_002_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Liu, Jinsong wrote:
>>> So another bug which is that mcelog is spinning at 100% CPU (and
>>> only under Xen).=20
>>>=20
>>> It seems to be doing:
>>>=20
>>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, =
[],
>>> 8) =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>>> =3D 0
>>> ppoll([{fd=3D4, events=3DPOLLIN}, {fd=3D3, events=3DPOLLIN}], 2, NULL, =
[],
>>> 8) =3D 1 ([{fd=3D3, revents=3DPOLLIN}]) read(3, "", 2816)
>>>=20
>>> constantly.
>>=20
>> I will debug it. I have try at my platform, but fail to reproduce it.
>> (You still use the config you send me last time, right?) Would you
>> tell me your step?=20
>>=20
>> Thanks,
>> Jinsong
>=20
> Have a look at it, it caused by NULL .poll method.
> Attached is the patch to fix this bug, but I cannot reproduce the bug
> at my platform, so would you please help me to test it at your side?=20
>=20

Ah I know how you trigger the bug - you run mcelog as daemon ... then spinn=
ing at CPU.
I update my patch as attached, and test at my platform OK now.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From 771bf5835a1ed9e439c7da289cb3a72ee8c9bd02 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 15 Jun 2012 09:03:39 +0800
Subject: [PATCH] xen/mce: add .poll method for mcelog device driver

If a driver leaves its poll method NULL, the device is assumed to
be both readable and writable without blocking.

This patch add .poll method to xen mcelog device driver, so that
when mcelog use system calls like ppoll or select, it would be
blocked when no data available, and avoid spinning at CPU.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/mcelog.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c
index 804aa3c..8feee08 100644
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -41,6 +41,8 @@
 #include <linux/miscdevice.h>
 #include <linux/uaccess.h>
 #include <linux/capability.h>
+#include <linux/poll.h>
+#include <linux/sched.h>
=20
 #include <xen/interface/xen.h>
 #include <xen/events.h>
@@ -67,6 +69,8 @@ static DEFINE_SPINLOCK(xen_mce_chrdev_state_lock);
 static int xen_mce_chrdev_open_count;	/* #times opened */
 static int xen_mce_chrdev_open_exclu;	/* already open exclusive? */
=20
+static DECLARE_WAIT_QUEUE_HEAD(xen_mce_chrdev_wait);
+
 static int xen_mce_chrdev_open(struct inode *inode, struct file *file)
 {
 	spin_lock(&xen_mce_chrdev_state_lock);
@@ -135,6 +139,16 @@ out:
 	return err ? err : buf - ubuf;
 }
=20
+static unsigned int xen_mce_chrdev_poll(struct file *file, poll_table *wai=
t)
+{
+	poll_wait(file, &xen_mce_chrdev_wait, wait);
+
+	if (xen_mcelog.next)
+		return POLLIN | POLLRDNORM;
+
+	return 0;
+}
+
 static long xen_mce_chrdev_ioctl(struct file *f, unsigned int cmd,
 				unsigned long arg)
 {
@@ -166,6 +180,7 @@ static const struct file_operations xen_mce_chrdev_ops =
=3D {
 	.open			=3D xen_mce_chrdev_open,
 	.release		=3D xen_mce_chrdev_release,
 	.read			=3D xen_mce_chrdev_read,
+	.poll			=3D xen_mce_chrdev_poll,
 	.unlocked_ioctl		=3D xen_mce_chrdev_ioctl,
 	.llseek			=3D no_llseek,
 };
@@ -329,6 +344,9 @@ static void xen_mce_work_fn(struct work_struct *work)
 		pr_err(XEN_MCELOG
 		       "Failed to handle nonurgent mc_info queue.\n");
=20
+	/* wake processes polling /dev/mcelog */
+	wake_up_interruptible(&xen_mce_chrdev_wait);
+
 	mutex_unlock(&mcelog_lock);
 }
 static DECLARE_WORK(xen_mce_work, xen_mce_work_fn);
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch"
Content-Description: 0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch
Content-Disposition: attachment;
	filename="0001-xen-mce-add-.poll-method-for-mcelog-device-driver.patch";
	size=2464; creation-date="Thu, 14 Jun 2012 17:13:03 GMT";
	modification-date="Fri, 15 Jun 2012 01:06:00 GMT"
Content-Transfer-Encoding: base64

RnJvbSA3NzFiZjU4MzVhMWVkOWU0MzljN2RhMjg5Y2IzYTcyZWU4YzliZDAyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxNSBKdW4gMjAxMiAwOTowMzozOSArMDgwMApTdWJqZWN0OiBbUEFUQ0hdIHhl
bi9tY2U6IGFkZCAucG9sbCBtZXRob2QgZm9yIG1jZWxvZyBkZXZpY2UgZHJpdmVyCgpJZiBhIGRy
aXZlciBsZWF2ZXMgaXRzIHBvbGwgbWV0aG9kIE5VTEwsIHRoZSBkZXZpY2UgaXMgYXNzdW1lZCB0
bwpiZSBib3RoIHJlYWRhYmxlIGFuZCB3cml0YWJsZSB3aXRob3V0IGJsb2NraW5nLgoKVGhpcyBw
YXRjaCBhZGQgLnBvbGwgbWV0aG9kIHRvIHhlbiBtY2Vsb2cgZGV2aWNlIGRyaXZlciwgc28gdGhh
dAp3aGVuIG1jZWxvZyB1c2Ugc3lzdGVtIGNhbGxzIGxpa2UgcHBvbGwgb3Igc2VsZWN0LCBpdCB3
b3VsZCBiZQpibG9ja2VkIHdoZW4gbm8gZGF0YSBhdmFpbGFibGUsIGFuZCBhdm9pZCBzcGlubmlu
ZyBhdCBDUFUuCgpSZXBvcnRlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2ls
a0BvcmFjbGUuY29tPgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KLS0tCiBkcml2ZXJzL3hlbi9tY2Vsb2cuYyB8ICAgMTggKysrKysrKysrKysrKysr
KysrCiAxIGZpbGVzIGNoYW5nZWQsIDE4IGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vbWNlbG9nLmMgYi9kcml2ZXJzL3hlbi9tY2Vsb2cuYwpp
bmRleCA4MDRhYTNjLi44ZmVlZTA4IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9tY2Vsb2cuYwor
KysgYi9kcml2ZXJzL3hlbi9tY2Vsb2cuYwpAQCAtNDEsNiArNDEsOCBAQAogI2luY2x1ZGUgPGxp
bnV4L21pc2NkZXZpY2UuaD4KICNpbmNsdWRlIDxsaW51eC91YWNjZXNzLmg+CiAjaW5jbHVkZSA8
bGludXgvY2FwYWJpbGl0eS5oPgorI2luY2x1ZGUgPGxpbnV4L3BvbGwuaD4KKyNpbmNsdWRlIDxs
aW51eC9zY2hlZC5oPgogCiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS94ZW4uaD4KICNpbmNsdWRl
IDx4ZW4vZXZlbnRzLmg+CkBAIC02Nyw2ICs2OSw4IEBAIHN0YXRpYyBERUZJTkVfU1BJTkxPQ0so
eGVuX21jZV9jaHJkZXZfc3RhdGVfbG9jayk7CiBzdGF0aWMgaW50IHhlbl9tY2VfY2hyZGV2X29w
ZW5fY291bnQ7CS8qICN0aW1lcyBvcGVuZWQgKi8KIHN0YXRpYyBpbnQgeGVuX21jZV9jaHJkZXZf
b3Blbl9leGNsdTsJLyogYWxyZWFkeSBvcGVuIGV4Y2x1c2l2ZT8gKi8KIAorc3RhdGljIERFQ0xB
UkVfV0FJVF9RVUVVRV9IRUFEKHhlbl9tY2VfY2hyZGV2X3dhaXQpOworCiBzdGF0aWMgaW50IHhl
bl9tY2VfY2hyZGV2X29wZW4oc3RydWN0IGlub2RlICppbm9kZSwgc3RydWN0IGZpbGUgKmZpbGUp
CiB7CiAJc3Bpbl9sb2NrKCZ4ZW5fbWNlX2NocmRldl9zdGF0ZV9sb2NrKTsKQEAgLTEzNSw2ICsx
MzksMTYgQEAgb3V0OgogCXJldHVybiBlcnIgPyBlcnIgOiBidWYgLSB1YnVmOwogfQogCitzdGF0
aWMgdW5zaWduZWQgaW50IHhlbl9tY2VfY2hyZGV2X3BvbGwoc3RydWN0IGZpbGUgKmZpbGUsIHBv
bGxfdGFibGUgKndhaXQpCit7CisJcG9sbF93YWl0KGZpbGUsICZ4ZW5fbWNlX2NocmRldl93YWl0
LCB3YWl0KTsKKworCWlmICh4ZW5fbWNlbG9nLm5leHQpCisJCXJldHVybiBQT0xMSU4gfCBQT0xM
UkROT1JNOworCisJcmV0dXJuIDA7Cit9CisKIHN0YXRpYyBsb25nIHhlbl9tY2VfY2hyZGV2X2lv
Y3RsKHN0cnVjdCBmaWxlICpmLCB1bnNpZ25lZCBpbnQgY21kLAogCQkJCXVuc2lnbmVkIGxvbmcg
YXJnKQogewpAQCAtMTY2LDYgKzE4MCw3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZmlsZV9vcGVy
YXRpb25zIHhlbl9tY2VfY2hyZGV2X29wcyA9IHsKIAkub3BlbgkJCT0geGVuX21jZV9jaHJkZXZf
b3BlbiwKIAkucmVsZWFzZQkJPSB4ZW5fbWNlX2NocmRldl9yZWxlYXNlLAogCS5yZWFkCQkJPSB4
ZW5fbWNlX2NocmRldl9yZWFkLAorCS5wb2xsCQkJPSB4ZW5fbWNlX2NocmRldl9wb2xsLAogCS51
bmxvY2tlZF9pb2N0bAkJPSB4ZW5fbWNlX2NocmRldl9pb2N0bCwKIAkubGxzZWVrCQkJPSBub19s
bHNlZWssCiB9OwpAQCAtMzI5LDYgKzM0NCw5IEBAIHN0YXRpYyB2b2lkIHhlbl9tY2Vfd29ya19m
bihzdHJ1Y3Qgd29ya19zdHJ1Y3QgKndvcmspCiAJCXByX2VycihYRU5fTUNFTE9HCiAJCSAgICAg
ICAiRmFpbGVkIHRvIGhhbmRsZSBub251cmdlbnQgbWNfaW5mbyBxdWV1ZS5cbiIpOwogCisJLyog
d2FrZSBwcm9jZXNzZXMgcG9sbGluZyAvZGV2L21jZWxvZyAqLworCXdha2VfdXBfaW50ZXJydXB0
aWJsZSgmeGVuX21jZV9jaHJkZXZfd2FpdCk7CisKIAltdXRleF91bmxvY2soJm1jZWxvZ19sb2Nr
KTsKIH0KIHN0YXRpYyBERUNMQVJFX1dPUksoeGVuX21jZV93b3JrLCB4ZW5fbWNlX3dvcmtfZm4p
OwotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335233036SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Jun 14 18:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:06: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 1SfEQO-00039d-RK; Thu, 14 Jun 2012 18:05: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 1SfEQN-00039V-DR
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:05:39 +0000
Received: from [85.158.139.83:54944] by server-8.bemta-5.messagelabs.com id
	F3/C1-10278-2F72ADF4; Thu, 14 Jun 2012 18:05:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339697135!27734075!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16561 invoked from network); 14 Jun 2012 18:05:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 18:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28120282"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:05:35 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	14:05:35 -0400
Message-ID: <4FDA27ED.1080404@citrix.com>
Date: Thu, 14 Jun 2012 19:05:33 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
	<4FD9FAA3.6090303@citrix.com>
	<20120614164926.GC333@phenom.dumpdata.com>
In-Reply-To: <20120614164926.GC333@phenom.dumpdata.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if
 they haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 17:49, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 14, 2012 at 03:52:19PM +0100, David Vrabel wrote:
>> On 07/06/12 18:01, David Vrabel wrote:
>>> From: David Vrabel <david.vrabel@citrix.com>
>>>
>>> When switching tasks in a Xen PV guest, avoid updating the TLS
>>> descriptors if they haven't changed.  This improves the speed of
>>> context switches by almost 10% as much of the time the descriptors are
>>> the same or only one is different.
>>>
>>> The descriptors written into the GDT by Xen are modified from the
>>> values passed in the update_descriptor hypercall so we keep shadow
>>> copies of the three TLS descriptors to compare against.
>>>
>>> lmbench3 test     Before  After  Improvement
>>> --------------------------------------------
>>> lat_ctx -s 32 24   7.19    6.52  9%
>>> lat_pipe          12.56   11.66  7%
>>>
>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>> ---
>>> I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
>>> in desc_struct as deprecated but there seems to be no suitable
>>> alternatives.
>>
>> ping?  Any opinion on this patch from the x86 side?  If it's okay can we
>> get an ack so Konrad can take the patch via his tree.
> 
> It breaks my all my bootup tests - so NACK until at least that is fixed.
> I think I sent you the whole serial log - is there something else that would help
> narrow it down?

You're mixing up this patch with "xen/mm: do direct hypercall in
xen_set_pte() if batching is unavailable" which is broken on 64-bit and
I am looking into it.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:06: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 1SfEQO-00039d-RK; Thu, 14 Jun 2012 18:05: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 1SfEQN-00039V-DR
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:05:39 +0000
Received: from [85.158.139.83:54944] by server-8.bemta-5.messagelabs.com id
	F3/C1-10278-2F72ADF4; Thu, 14 Jun 2012 18:05:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339697135!27734075!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTEyNjA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16561 invoked from network); 14 Jun 2012 18:05:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 18:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="28120282"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 14:05:35 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 14 Jun 2012
	14:05:35 -0400
Message-ID: <4FDA27ED.1080404@citrix.com>
Date: Thu, 14 Jun 2012 19:05:33 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1339088494-23528-1-git-send-email-david.vrabel@citrix.com>
	<4FD9FAA3.6090303@citrix.com>
	<20120614164926.GC333@phenom.dumpdata.com>
In-Reply-To: <20120614164926.GC333@phenom.dumpdata.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: avoid updating TLS descriptors if
 they haven't changed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/12 17:49, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 14, 2012 at 03:52:19PM +0100, David Vrabel wrote:
>> On 07/06/12 18:01, David Vrabel wrote:
>>> From: David Vrabel <david.vrabel@citrix.com>
>>>
>>> When switching tasks in a Xen PV guest, avoid updating the TLS
>>> descriptors if they haven't changed.  This improves the speed of
>>> context switches by almost 10% as much of the time the descriptors are
>>> the same or only one is different.
>>>
>>> The descriptors written into the GDT by Xen are modified from the
>>> values passed in the update_descriptor hypercall so we keep shadow
>>> copies of the three TLS descriptors to compare against.
>>>
>>> lmbench3 test     Before  After  Improvement
>>> --------------------------------------------
>>> lat_ctx -s 32 24   7.19    6.52  9%
>>> lat_pipe          12.56   11.66  7%
>>>
>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>> ---
>>> I note that the comment in asm/desc_defs.h says the 'a' and 'b' fields
>>> in desc_struct as deprecated but there seems to be no suitable
>>> alternatives.
>>
>> ping?  Any opinion on this patch from the x86 side?  If it's okay can we
>> get an ack so Konrad can take the patch via his tree.
> 
> It breaks my all my bootup tests - so NACK until at least that is fixed.
> I think I sent you the whole serial log - is there something else that would help
> narrow it down?

You're mixing up this patch with "xen/mm: do direct hypercall in
xen_set_pte() if batching is unavailable" which is broken on 64-bit and
I am looking into it.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18: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 1SfEuU-0003WH-FP; Thu, 14 Jun 2012 18:36:46 +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 1SfEuT-0003WC-Bb
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:36:45 +0000
Received: from [85.158.139.83:30349] by server-10.bemta-5.messagelabs.com id
	ED/B1-02190-C3F2ADF4; Thu, 14 Jun 2012 18:36:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339699002!27773844!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20698 invoked from network); 14 Jun 2012 18:36:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:36:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EIaccd019765
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 18:36:38 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
	q5EIabPn019190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 18:36:37 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
	q5EIabED011865; Thu, 14 Jun 2012 13:36:37 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 11:36:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 41A7D40297; Thu, 14 Jun 2012 14:29:13 -0400 (EDT)
Date: Thu, 14 Jun 2012 14:29:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, rusty@rustcorp.com.au
Message-ID: <20120614182913.GA21956@phenom.dumpdata.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
	<4FD8AB07.7080004@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD8AB07.7080004@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" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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, Jun 13, 2012 at 04:00:23PM +0100, David Vrabel wrote:
> On 13/06/12 15:04, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 13, 2012 at 11:20:43AM +0100, David Vrabel wrote:
> >> This series removes the x86-specific implementation of
> >> ptep_get_and_clear() and pmdp_get_and_clear().
> >>
> >> The principal reason for this is it allows Xen paravitualized guests
> >> to batch the PTE clears which is a significant performance
> >> optimization of munmap() and mremap() -- the number of entries into
> >> the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
> >> guests) for munmap().
> >>
> >> There may be minimal gains on native and KVM guests due to the removal
> >> of the locked xchg.
> > 
> > What about lguest?
> 
> As I note in the description of patch 1:
> 
> "There may be a performance regression with lguest guests as
> an optimization for avoiding calling pte_update() when doing a full
> teardown of an mm is removed."
> 
> I don't know how much this performance regression would be or if the
> performance of lguest guests is something people care about.
> 
> We could have an x86-specific ptep_get_and_clear_full() which looks like:
> 
> pte_t ptep_get_and_clear_full(
> 	struct mm_struct *mm, unsigned long addr, pte_t *ptep,
> 	int full)
> {
> 	pte_t pte = *ptep;
> 
> 	pte_clear(mm, address, ptep);
> 	if (!full)
> 		pte_update(mm, addr, ptep);
> 
> 	return pte;
> }
> 
> Which would have all the performance benefits of the proposed patch
> without the performance regression with lguest.

Lets rope Rusty in this since he is the maintainer of lguest.
> 
> David
> 
> >>
> >> Removal of arch-specific functions where generic ones are suitable
> >> seems to be a generally useful thing to me.
> >>
> >> The full reasoning for why this is safe is included in the commit
> >> message of patch 1 but to summarize.  The atomic get-and-clear does
> >> not guarantee that the latest dirty/accessed bits are returned as TLB
> >> as there is a still a window after the get-and-clear and before the
> >> TLB flush that the bits may be updated on other processors.  So, user
> >> space applications accessing pages that are being unmapped or remapped
> >> already have unpredictable behaviour.
> >>
> >> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18: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 1SfEuU-0003WH-FP; Thu, 14 Jun 2012 18:36:46 +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 1SfEuT-0003WC-Bb
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:36:45 +0000
Received: from [85.158.139.83:30349] by server-10.bemta-5.messagelabs.com id
	ED/B1-02190-C3F2ADF4; Thu, 14 Jun 2012 18:36:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339699002!27773844!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20698 invoked from network); 14 Jun 2012 18:36:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:36:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EIaccd019765
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 18:36:38 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
	q5EIabPn019190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 18:36:37 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
	q5EIabED011865; Thu, 14 Jun 2012 13:36:37 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 11:36:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 41A7D40297; Thu, 14 Jun 2012 14:29:13 -0400 (EDT)
Date: Thu, 14 Jun 2012 14:29:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, rusty@rustcorp.com.au
Message-ID: <20120614182913.GA21956@phenom.dumpdata.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
	<4FD8AB07.7080004@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD8AB07.7080004@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" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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, Jun 13, 2012 at 04:00:23PM +0100, David Vrabel wrote:
> On 13/06/12 15:04, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 13, 2012 at 11:20:43AM +0100, David Vrabel wrote:
> >> This series removes the x86-specific implementation of
> >> ptep_get_and_clear() and pmdp_get_and_clear().
> >>
> >> The principal reason for this is it allows Xen paravitualized guests
> >> to batch the PTE clears which is a significant performance
> >> optimization of munmap() and mremap() -- the number of entries into
> >> the hypervisor is reduced by about a factor of about 30 (60 in 32-bit
> >> guests) for munmap().
> >>
> >> There may be minimal gains on native and KVM guests due to the removal
> >> of the locked xchg.
> > 
> > What about lguest?
> 
> As I note in the description of patch 1:
> 
> "There may be a performance regression with lguest guests as
> an optimization for avoiding calling pte_update() when doing a full
> teardown of an mm is removed."
> 
> I don't know how much this performance regression would be or if the
> performance of lguest guests is something people care about.
> 
> We could have an x86-specific ptep_get_and_clear_full() which looks like:
> 
> pte_t ptep_get_and_clear_full(
> 	struct mm_struct *mm, unsigned long addr, pte_t *ptep,
> 	int full)
> {
> 	pte_t pte = *ptep;
> 
> 	pte_clear(mm, address, ptep);
> 	if (!full)
> 		pte_update(mm, addr, ptep);
> 
> 	return pte;
> }
> 
> Which would have all the performance benefits of the proposed patch
> without the performance regression with lguest.

Lets rope Rusty in this since he is the maintainer of lguest.
> 
> David
> 
> >>
> >> Removal of arch-specific functions where generic ones are suitable
> >> seems to be a generally useful thing to me.
> >>
> >> The full reasoning for why this is safe is included in the commit
> >> message of patch 1 but to summarize.  The atomic get-and-clear does
> >> not guarantee that the latest dirty/accessed bits are returned as TLB
> >> as there is a still a window after the get-and-clear and before the
> >> TLB flush that the bits may be updated on other processors.  So, user
> >> space applications accessing pages that are being unmapped or remapped
> >> already have unpredictable behaviour.
> >>
> >> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18: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 1SfEvp-0003Zz-Uk; Thu, 14 Jun 2012 18:38:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1SfEvn-0003Zj-OW
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:38:08 +0000
Received: from [85.158.138.51:14618] by server-4.bemta-3.messagelabs.com id
	9C/5A-17105-E8F2ADF4; Thu, 14 Jun 2012 18:38:06 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339699085!27679828!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8628 invoked from network); 14 Jun 2012 18:38:05 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:38:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=dHkCHzi/hwp64uy9CO78q/LuDQzszLdNx66M3ks24uI=; b=CoDaCRf
	aLci67+mS/aN0o5oIzbIRhJ7/5ZwFc8L5xp9ERO7DfJKUEekRj522AD4OYF5bmfH
	IZqDAWrj5Am0rX48KHSd2RZ2UBR/CfKtUbdWdA+54EMdJ0EAX+bSFfKT2RmakT/7
	oplDNEPLdtH/l7+0aPYXJlJuPwLkDKWoXb0o=
Received: (qmail 17156 invoked from network); 14 Jun 2012 20:38:04 +0200
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.60.25)
	by mail.zeus06.de with ESMTPA; 14 Jun 2012 20:38:04 +0200
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E1E112CA8F;
	Thu, 14 Jun 2012 20:40:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id D9DjEShpqc1N; Thu, 14 Jun 2012 20:40:20 +0200 (CEST)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E95832CA8E;
	Thu, 14 Jun 2012 20:40:19 +0200 (CEST)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 14 Jun 2012 20:40:19 +0200
Mime-Version: 1.0
In-Reply-To: <20120613165529.GA10986@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.6-32752
Thread-Index: Ac1KXM9out/ATiayTmSe2spo1XMpMg==
Message-Id: <zarafa.4fda3013.1340.11e86b0675d17248@uhura.space.zz>
Cc: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad, against which kernel version did you produce this patch? It will no=
t succeed
with 3.4.2 at least, will look up some older version now...

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.or=
g] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Mittwoch, 13. Juni 2012 18:55
An: Carsten Schiers
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> > =

> > =A0
> > don't want to be pushy, as I have no real issue. I simply use the Xenif=
ied kernel or take the double load. =

> > =

> > But I think this mistery is still open. My last status was that the =

> > latest patch you produced resulted in a BUG,
> =

> Yes, that is right. Thank you for reminding me.
> > =

> > so we still have not checked whether our theory is correct.
> =

> No we haven't. And I should be have no trouble reproducing this. I can =

> just write a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please try it out=
? It has the #define DEBUG 1 set so it should print a lot of stuff when the=
 DVB module loads. If it crashes please send me the full log.

Thanks.
>From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
 [v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |  187 +++++++++++++++++++++++++++++++++++++++++++++=
++-
 include/xen/xen-ops.h |    2 +
 mm/vmalloc.c          |   18 +++++-
 3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3a73785..960d206=
 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 =

 #include <trace/events/xen.h>
 =

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */  #define MAX_CONTIG_ORDER 9 /* 2M=
B */  static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 =

 #define VOID_PTE (mfn_pte(0, __pgprot(0)))  static void xen_zap_pfn_range(=
unsigned long vaddr, unsigned int order, @@ -2075,6 +2077,42 @@ static void=
 xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n =3D 0;
+	struct multicall_space mcs;
+	struct page *page;
+
+	xen_mc_batch();
+	for (i =3D 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+#define DEBUG 1
+		if (in_frames) {
+#ifdef DEBUG
+			printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+				__func__, i, page_to_pfn(page),
+				pfn_to_mfn(page_to_pfn(page)), page_address(page)); #endif
+			in_frames[i] =3D pfn_to_mfn(page_to_pfn(page));
+		}
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_=
PTE, 0);
+		set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] =3D page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+	return n;
+}
 =

 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to @=
@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long va=
ddr, int order,
 =

 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn, /* in_frame if we failed*/
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit =3D 1ULL << order;
+	for (i =3D 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+		if (mfns)
+			mfn =3D mfns[i];
+		else
+			mfn =3D first_mfn + i;
+
+		if (i < (limit - 1))
+			flags =3D 0;
+		else {
+			if (order =3D=3D 0)
+				flags =3D UVMF_INVLPG | UVMF_ALL;
+			else
+				flags =3D UVMF_TLB_FLUSH | UVMF_ALL;
+		}
+#ifdef DEBUG
+		printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+			__func__, i, page_to_pfn(page), mfn, page_address(page)); #endif
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 =

 /*
  * Perform the hypercall to exchange a region of our pfns to point to @@ -=
2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_in, =
unsigned int order_in,  {
 	long rc;
 	int success;
-
+#ifdef DEBUG
+	int i;
+#endif
 	struct xen_memory_exchange exchange =3D {
 		.in =3D {
 			.nr_extents   =3D extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents=
_in, unsigned int order_in,
 =

 	rc =3D HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
 	success =3D (exchange.nr_exchanged =3D=3D extents_in);
-
+#ifdef DEBUG
+	for (i =3D 0; i <  exchange.nr_exchanged; i++) {
+		printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n",  __func__,pfns_in[i=
], mfns_out[i]);
+	}
+#endif
 	BUG_ON(!success && ((exchange.nr_exchanged !=3D 0) || (rc =3D=3D 0)));
 	BUG_ON(success && (rc !=3D 0));
 =

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vsta=
rt, unsigned int order)
 	xen_zap_pfn_range(vstart, order, NULL, out_frames);
 =

 	/* 3. Do the exchange for non-contiguous MFNs. */
-	success =3D xen_exchange_memory(1, order, &in_frame, 1UL << order,
-					0, out_frames, 0);
+	success =3D xen_exchange_memory(1, order, &in_frame,
+				      1UL << order, 0, out_frames, 0);
 =

 	/* 4. Map new pages in place of old pages. */
 	if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vst=
art, unsigned int order)  }  EXPORT_SYMBOL_GPL(xen_destroy_contiguous_regio=
n);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames =3D discontig_frames, *out_frames =3D limited_fr=
ames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n =3D 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map =3D kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map =3D &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i =3D 0; i < (1ULL << order); i++) {
+		void *vaddr;
+		page =3D &pages[i];
+
+		vaddr =3D page_address(page);
+#ifdef DEBUG
+		printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n", =

+__func__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr)))=
; #endif
+		if (address_bits) {
+			if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map !=3D &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n =3D xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, =

+limit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success =3D xen_exchange_memory(n, 0 /* this is always called per page */=
, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map !=3D &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)  { diff --git a/includ=
e/xen/xen-ops.h b/include/xen/xen-ops.h index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 =

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 =

 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long=
 end) @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_str=
uct *area, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size =3D (nr_pages * sizeof(struct page *));
 =

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] =3D page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages =3D i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 =

 	if (map_vm_area(area, prot, &pages))
--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5067 - Ausgabedatum: 13.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18: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 1SfEvp-0003Zz-Uk; Thu, 14 Jun 2012 18:38:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1SfEvn-0003Zj-OW
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:38:08 +0000
Received: from [85.158.138.51:14618] by server-4.bemta-3.messagelabs.com id
	9C/5A-17105-E8F2ADF4; Thu, 14 Jun 2012 18:38:06 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1339699085!27679828!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8628 invoked from network); 14 Jun 2012 18:38:05 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:38:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=dHkCHzi/hwp64uy9CO78q/LuDQzszLdNx66M3ks24uI=; b=CoDaCRf
	aLci67+mS/aN0o5oIzbIRhJ7/5ZwFc8L5xp9ERO7DfJKUEekRj522AD4OYF5bmfH
	IZqDAWrj5Am0rX48KHSd2RZ2UBR/CfKtUbdWdA+54EMdJ0EAX+bSFfKT2RmakT/7
	oplDNEPLdtH/l7+0aPYXJlJuPwLkDKWoXb0o=
Received: (qmail 17156 invoked from network); 14 Jun 2012 20:38:04 +0200
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.60.25)
	by mail.zeus06.de with ESMTPA; 14 Jun 2012 20:38:04 +0200
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E1E112CA8F;
	Thu, 14 Jun 2012 20:40:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id D9DjEShpqc1N; Thu, 14 Jun 2012 20:40:20 +0200 (CEST)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E95832CA8E;
	Thu, 14 Jun 2012 20:40:19 +0200 (CEST)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 14 Jun 2012 20:40:19 +0200
Mime-Version: 1.0
In-Reply-To: <20120613165529.GA10986@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.6-32752
Thread-Index: Ac1KXM9out/ATiayTmSe2spo1XMpMg==
Message-Id: <zarafa.4fda3013.1340.11e86b0675d17248@uhura.space.zz>
Cc: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad, against which kernel version did you produce this patch? It will no=
t succeed
with 3.4.2 at least, will look up some older version now...

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.or=
g] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Mittwoch, 13. Juni 2012 18:55
An: Carsten Schiers
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> > =

> > =A0
> > don't want to be pushy, as I have no real issue. I simply use the Xenif=
ied kernel or take the double load. =

> > =

> > But I think this mistery is still open. My last status was that the =

> > latest patch you produced resulted in a BUG,
> =

> Yes, that is right. Thank you for reminding me.
> > =

> > so we still have not checked whether our theory is correct.
> =

> No we haven't. And I should be have no trouble reproducing this. I can =

> just write a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please try it out=
? It has the #define DEBUG 1 set so it should print a lot of stuff when the=
 DVB module loads. If it crashes please send me the full log.

Thanks.
>From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
 [v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |  187 +++++++++++++++++++++++++++++++++++++++++++++=
++-
 include/xen/xen-ops.h |    2 +
 mm/vmalloc.c          |   18 +++++-
 3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3a73785..960d206=
 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 =

 #include <trace/events/xen.h>
 =

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */  #define MAX_CONTIG_ORDER 9 /* 2M=
B */  static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 =

 #define VOID_PTE (mfn_pte(0, __pgprot(0)))  static void xen_zap_pfn_range(=
unsigned long vaddr, unsigned int order, @@ -2075,6 +2077,42 @@ static void=
 xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n =3D 0;
+	struct multicall_space mcs;
+	struct page *page;
+
+	xen_mc_batch();
+	for (i =3D 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+#define DEBUG 1
+		if (in_frames) {
+#ifdef DEBUG
+			printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+				__func__, i, page_to_pfn(page),
+				pfn_to_mfn(page_to_pfn(page)), page_address(page)); #endif
+			in_frames[i] =3D pfn_to_mfn(page_to_pfn(page));
+		}
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_=
PTE, 0);
+		set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] =3D page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+	return n;
+}
 =

 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to @=
@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long va=
ddr, int order,
 =

 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn, /* in_frame if we failed*/
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit =3D 1ULL << order;
+	for (i =3D 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+		if (mfns)
+			mfn =3D mfns[i];
+		else
+			mfn =3D first_mfn + i;
+
+		if (i < (limit - 1))
+			flags =3D 0;
+		else {
+			if (order =3D=3D 0)
+				flags =3D UVMF_INVLPG | UVMF_ALL;
+			else
+				flags =3D UVMF_TLB_FLUSH | UVMF_ALL;
+		}
+#ifdef DEBUG
+		printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+			__func__, i, page_to_pfn(page), mfn, page_address(page)); #endif
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 =

 /*
  * Perform the hypercall to exchange a region of our pfns to point to @@ -=
2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_in, =
unsigned int order_in,  {
 	long rc;
 	int success;
-
+#ifdef DEBUG
+	int i;
+#endif
 	struct xen_memory_exchange exchange =3D {
 		.in =3D {
 			.nr_extents   =3D extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents=
_in, unsigned int order_in,
 =

 	rc =3D HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
 	success =3D (exchange.nr_exchanged =3D=3D extents_in);
-
+#ifdef DEBUG
+	for (i =3D 0; i <  exchange.nr_exchanged; i++) {
+		printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n",  __func__,pfns_in[i=
], mfns_out[i]);
+	}
+#endif
 	BUG_ON(!success && ((exchange.nr_exchanged !=3D 0) || (rc =3D=3D 0)));
 	BUG_ON(success && (rc !=3D 0));
 =

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vsta=
rt, unsigned int order)
 	xen_zap_pfn_range(vstart, order, NULL, out_frames);
 =

 	/* 3. Do the exchange for non-contiguous MFNs. */
-	success =3D xen_exchange_memory(1, order, &in_frame, 1UL << order,
-					0, out_frames, 0);
+	success =3D xen_exchange_memory(1, order, &in_frame,
+				      1UL << order, 0, out_frames, 0);
 =

 	/* 4. Map new pages in place of old pages. */
 	if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vst=
art, unsigned int order)  }  EXPORT_SYMBOL_GPL(xen_destroy_contiguous_regio=
n);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames =3D discontig_frames, *out_frames =3D limited_fr=
ames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n =3D 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map =3D kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map =3D &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i =3D 0; i < (1ULL << order); i++) {
+		void *vaddr;
+		page =3D &pages[i];
+
+		vaddr =3D page_address(page);
+#ifdef DEBUG
+		printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n", =

+__func__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr)))=
; #endif
+		if (address_bits) {
+			if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map !=3D &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n =3D xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, =

+limit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success =3D xen_exchange_memory(n, 0 /* this is always called per page */=
, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map !=3D &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)  { diff --git a/includ=
e/xen/xen-ops.h b/include/xen/xen-ops.h index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 =

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 =

 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long=
 end) @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_str=
uct *area, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size =3D (nr_pages * sizeof(struct page *));
 =

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] =3D page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages =3D i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 =

 	if (map_vm_area(area, prot, &pages))
--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5067 - Ausgabedatum: 13.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:41:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:41: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 1SfEyt-0003mA-F8; Thu, 14 Jun 2012 18:41:19 +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 1SfEyr-0003li-LL
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:17 +0000
Received: from [193.109.254.147:56178] by server-8.bemta-14.messagelabs.com id
	AA/06-27132-C403ADF4; Thu, 14 Jun 2012 18:41:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339699274!2108088!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29486 invoked from network); 14 Jun 2012 18:41:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:41:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EIeRI8024645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 18:40:28 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
	q5EIeRxi025058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 18:40:27 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
	q5EIeR63014332; Thu, 14 Jun 2012 13:40:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 11:40:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 81E0940297; Thu, 14 Jun 2012 14:33:03 -0400 (EDT)
Date: Thu, 14 Jun 2012 14:33:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614183303.GD21956@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
	<4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 08:07:55AM +0100, Jan Beulich wrote:
> >>> On 13.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> >  	struct page **pages;
> >  	unsigned int nr_pages, array_size, i;
> >  	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> > -
> > +	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> > +	if (xen_pv_domain()) {
> > +		if (dma_mask == (__GFP_DMA | __GFP_DMA32))
> 
> As said in an earlier reply - without having any place that would
> ever set both flags at once, this whole conditional is meaningless.
> In our code - which I suppose is where you cloned this from - we

Yup.
> set GFP_VMALLOC32 to such a value for 32-bit kernels (which
> otherwise would merely use GFP_KERNEL, and hence not trigger

Ah, let me double check. Thanks for looking out for this.

> the code calling xen_limit_pages_to_max_mfn()). I don't recall
> though whether Carsten's problem was on a 32- or 64-bit kernel.
> 
> Jan
> 
> > +			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> > +	}
> >  	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> >  	array_size = (nr_pages * sizeof(struct page *));
> >  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:41:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:41: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 1SfEyt-0003mA-F8; Thu, 14 Jun 2012 18:41:19 +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 1SfEyr-0003li-LL
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:17 +0000
Received: from [193.109.254.147:56178] by server-8.bemta-14.messagelabs.com id
	AA/06-27132-C403ADF4; Thu, 14 Jun 2012 18:41:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339699274!2108088!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29486 invoked from network); 14 Jun 2012 18:41:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:41:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EIeRI8024645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 18:40:28 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
	q5EIeRxi025058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 18:40:27 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
	q5EIeR63014332; Thu, 14 Jun 2012 13:40:27 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 11:40:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 81E0940297; Thu, 14 Jun 2012 14:33:03 -0400 (EDT)
Date: Thu, 14 Jun 2012 14:33:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614183303.GD21956@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
	<4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 08:07:55AM +0100, Jan Beulich wrote:
> >>> On 13.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> >  	struct page **pages;
> >  	unsigned int nr_pages, array_size, i;
> >  	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> > -
> > +	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> > +	if (xen_pv_domain()) {
> > +		if (dma_mask == (__GFP_DMA | __GFP_DMA32))
> 
> As said in an earlier reply - without having any place that would
> ever set both flags at once, this whole conditional is meaningless.
> In our code - which I suppose is where you cloned this from - we

Yup.
> set GFP_VMALLOC32 to such a value for 32-bit kernels (which
> otherwise would merely use GFP_KERNEL, and hence not trigger

Ah, let me double check. Thanks for looking out for this.

> the code calling xen_limit_pages_to_max_mfn()). I don't recall
> though whether Carsten's problem was on a 32- or 64-bit kernel.
> 
> Jan
> 
> > +			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> > +	}
> >  	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> >  	array_size = (nr_pages * sizeof(struct page *));
> >  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:41:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:41: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 1SfEyr-0003lj-2O; Thu, 14 Jun 2012 18:41:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1SfEyq-0003lS-2l
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:16 +0000
Received: from [85.158.138.51:6637] by server-9.bemta-3.messagelabs.com id
	B4/58-10419-B403ADF4; Thu, 14 Jun 2012 18:41:15 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339699274!19625974!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20569 invoked from network); 14 Jun 2012 18:41:14 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:41:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=sYlA2b+i+aeU9BkDC3mI9CJYO+hmhmMiSvSMBdQtoXc=; b=KNV5KZ/
	6+CgmyJ+4C8kGPDGxvS3sR25XdNTwUB2F+zcwr0lIgPOnVrnDsyM7fS/AgY+NKBt
	A035YxKc6X1H5wbT7tumtOzm9JfAT39Lsso+I/ItNqO2IjWHby22q+ZIMdP1Y43i
	FVx1yzr8Vf/tQJbfK7kJ65fLZJy/r033bKKA=
Received: (qmail 17636 invoked from network); 14 Jun 2012 20:41:14 +0200
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.60.25)
	by mail.zeus06.de with ESMTPA; 14 Jun 2012 20:41:14 +0200
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id BDA102CA8F;
	Thu, 14 Jun 2012 20:43:32 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 26QJerYGMCs0; Thu, 14 Jun 2012 20:43:31 +0200 (CEST)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 07AFF2CA8E;
	Thu, 14 Jun 2012 20:43:31 +0200 (CEST)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Jan_Beulich?= <JBeulich@suse.com>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 14 Jun 2012 20:43:30 +0200
Mime-Version: 1.0
In-Reply-To: <4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.6-32752
Thread-Index: Ac1KXUFobeq5todPQM2uksRMZ572BQ==
Message-Id: <zarafa.4fda30d2.13dd.700a1a6a7ccf80cc@uhura.space.zz>
Cc: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's a 64 Bit kernel...

-----Urspr=FCngliche Nachricht-----
Von: Jan Beulich [mailto:JBeulich@suse.com] =

Gesendet: Donnerstag, 14. Juni 2012 09:08
An: Konrad Rzeszutek Wilk
Cc: Konrad Rzeszutek Wilk; Sander Eikelenboom; xen-devel; Carsten Schiers
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

>>> On 13.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wr=
ote:
> @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct =
*area, gfp_t gfp_mask,
>  	struct page **pages;
>  	unsigned int nr_pages, array_size, i;
>  	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> -
> +	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
> +	if (xen_pv_domain()) {
> +		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))

As said in an earlier reply - without having any place that would ever set =
both flags at once, this whole conditional is meaningless.
In our code - which I suppose is where you cloned this from - we set GFP_VM=
ALLOC32 to such a value for 32-bit kernels (which otherwise would merely us=
e GFP_KERNEL, and hence not trigger the code calling xen_limit_pages_to_max=
_mfn()). I don't recall though whether Carsten's problem was on a 32- or 64=
-bit kernel.

Jan

> +			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
> +	}
>  	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
>  	array_size =3D (nr_pages * sizeof(struct page *));
>  =




-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5069 - Ausgabedatum: 14.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:41:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:41: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 1SfEyr-0003lj-2O; Thu, 14 Jun 2012 18:41:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1SfEyq-0003lS-2l
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:16 +0000
Received: from [85.158.138.51:6637] by server-9.bemta-3.messagelabs.com id
	B4/58-10419-B403ADF4; Thu, 14 Jun 2012 18:41:15 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339699274!19625974!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20569 invoked from network); 14 Jun 2012 18:41:14 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:41:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=sYlA2b+i+aeU9BkDC3mI9CJYO+hmhmMiSvSMBdQtoXc=; b=KNV5KZ/
	6+CgmyJ+4C8kGPDGxvS3sR25XdNTwUB2F+zcwr0lIgPOnVrnDsyM7fS/AgY+NKBt
	A035YxKc6X1H5wbT7tumtOzm9JfAT39Lsso+I/ItNqO2IjWHby22q+ZIMdP1Y43i
	FVx1yzr8Vf/tQJbfK7kJ65fLZJy/r033bKKA=
Received: (qmail 17636 invoked from network); 14 Jun 2012 20:41:14 +0200
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.60.25)
	by mail.zeus06.de with ESMTPA; 14 Jun 2012 20:41:14 +0200
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id BDA102CA8F;
	Thu, 14 Jun 2012 20:43:32 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 26QJerYGMCs0; Thu, 14 Jun 2012 20:43:31 +0200 (CEST)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 07AFF2CA8E;
	Thu, 14 Jun 2012 20:43:31 +0200 (CEST)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Jan_Beulich?= <JBeulich@suse.com>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 14 Jun 2012 20:43:30 +0200
Mime-Version: 1.0
In-Reply-To: <4FD9A9EB0200007800089E02@nat28.tlf.novell.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.6-32752
Thread-Index: Ac1KXUFobeq5todPQM2uksRMZ572BQ==
Message-Id: <zarafa.4fda30d2.13dd.700a1a6a7ccf80cc@uhura.space.zz>
Cc: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's a 64 Bit kernel...

-----Urspr=FCngliche Nachricht-----
Von: Jan Beulich [mailto:JBeulich@suse.com] =

Gesendet: Donnerstag, 14. Juni 2012 09:08
An: Konrad Rzeszutek Wilk
Cc: Konrad Rzeszutek Wilk; Sander Eikelenboom; xen-devel; Carsten Schiers
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

>>> On 13.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wr=
ote:
> @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct =
*area, gfp_t gfp_mask,
>  	struct page **pages;
>  	unsigned int nr_pages, array_size, i;
>  	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> -
> +	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
> +	if (xen_pv_domain()) {
> +		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))

As said in an earlier reply - without having any place that would ever set =
both flags at once, this whole conditional is meaningless.
In our code - which I suppose is where you cloned this from - we set GFP_VM=
ALLOC32 to such a value for 32-bit kernels (which otherwise would merely us=
e GFP_KERNEL, and hence not trigger the code calling xen_limit_pages_to_max=
_mfn()). I don't recall though whether Carsten's problem was on a 32- or 64=
-bit kernel.

Jan

> +			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
> +	}
>  	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
>  	array_size =3D (nr_pages * sizeof(struct page *));
>  =




-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5069 - Ausgabedatum: 14.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:41:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:41: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 1SfEyp-0003lT-MT; Thu, 14 Jun 2012 18:41:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SfEyn-0003lJ-Ok
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:13 +0000
Received: from [85.158.139.83:61781] by server-9.bemta-5.messagelabs.com id
	2D/40-01069-9403ADF4; Thu, 14 Jun 2012 18:41:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339699271!23468321!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28136 invoked from network); 14 Jun 2012 18:41:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 18:41:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EIdHcU022868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 18:39:18 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
	q5EIdGLB000435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 18:39:17 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
	q5EIdGWu030374; Thu, 14 Jun 2012 13:39:16 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 11:39:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8C82A40297; Thu, 14 Jun 2012 14:31:52 -0400 (EDT)
Date: Thu, 14 Jun 2012 14:31:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20120614183152.GC21956@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
	<4FD9A307.9030203@cantab.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9A307.9030203@cantab.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>, Jan Beulich <jbeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 09:38:31AM +0100, David Vrabel wrote:
> On 13/06/12 17:55, Konrad Rzeszutek Wilk wrote:
> > 
> > +	/* 3. Do the exchange for non-contiguous MFNs. */
> > +	success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
> > +				      n, 0, out_frames, address_bits);
> 
> vmalloc() does not require physically contiguous MFNs.

<nods> It doesn't matter that much in this context as the vmalloc
calls this per-page - so it is only one page that is swizzled.

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:41:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18:41: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 1SfEyp-0003lT-MT; Thu, 14 Jun 2012 18:41:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SfEyn-0003lJ-Ok
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:13 +0000
Received: from [85.158.139.83:61781] by server-9.bemta-5.messagelabs.com id
	2D/40-01069-9403ADF4; Thu, 14 Jun 2012 18:41:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339699271!23468321!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28136 invoked from network); 14 Jun 2012 18:41:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Jun 2012 18:41:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EIdHcU022868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 18:39:18 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
	q5EIdGLB000435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 18:39:17 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
	q5EIdGWu030374; Thu, 14 Jun 2012 13:39:16 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 11:39:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8C82A40297; Thu, 14 Jun 2012 14:31:52 -0400 (EDT)
Date: Thu, 14 Jun 2012 14:31:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20120614183152.GC21956@phenom.dumpdata.com>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
	<zarafa.4facde3c.0774.52df3a5311f718f3@uhura.space.zz>
	<20120511194138.GA30099@phenom.dumpdata.com>
	<20120613165529.GA10986@phenom.dumpdata.com>
	<4FD9A307.9030203@cantab.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FD9A307.9030203@cantab.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>, Jan Beulich <jbeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 09:38:31AM +0100, David Vrabel wrote:
> On 13/06/12 17:55, Konrad Rzeszutek Wilk wrote:
> > 
> > +	/* 3. Do the exchange for non-contiguous MFNs. */
> > +	success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
> > +				      n, 0, out_frames, address_bits);
> 
> vmalloc() does not require physically contiguous MFNs.

<nods> It doesn't matter that much in this context as the vmalloc
calls this per-page - so it is only one page that is swizzled.

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 18:41:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18: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 1SfEz1-0003nX-Rs; Thu, 14 Jun 2012 18:41:27 +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 1SfEz0-0003nB-AQ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:26 +0000
Received: from [193.109.254.147:60191] by server-12.bemta-14.messagelabs.com
	id 6D/B0-12998-5503ADF4; Thu, 14 Jun 2012 18:41:25 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339699283!9765393!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3099 invoked from network); 14 Jun 2012 18:41:24 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:41:24 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q5EIfGMg004824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 11:41:17 -0700
Message-ID: <4FDA304C.4050306@zytor.com>
Date: Thu, 14 Jun 2012 11:41:16 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
	<4FD8AB07.7080004@citrix.com>
	<20120614182913.GA21956@phenom.dumpdata.com>
In-Reply-To: <20120614182913.GA21956@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>, rusty@rustcorp.com.au,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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 06/14/2012 11:29 AM, Konrad Rzeszutek Wilk wrote:
> 
> Lets rope Rusty in this since he is the maintainer of lguest.
>

Also, let's have realistic expectations for lguest.

I don't want to break lguest just for sh*ts and giggles, but if lguest
is in the way of making forward progress for other things, it would have
to have a very strong case to not be sacrificed.

	-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 Jun 14 18:41:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 18: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 1SfEz1-0003nX-Rs; Thu, 14 Jun 2012 18:41:27 +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 1SfEz0-0003nB-AQ
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 18:41:26 +0000
Received: from [193.109.254.147:60191] by server-12.bemta-14.messagelabs.com
	id 6D/B0-12998-5503ADF4; Thu, 14 Jun 2012 18:41:25 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339699283!9765393!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3099 invoked from network); 14 Jun 2012 18:41:24 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 18:41:24 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q5EIfGMg004824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 11:41:17 -0700
Message-ID: <4FDA304C.4050306@zytor.com>
Date: Thu, 14 Jun 2012 11:41:16 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
	<4FD8AB07.7080004@citrix.com>
	<20120614182913.GA21956@phenom.dumpdata.com>
In-Reply-To: <20120614182913.GA21956@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"x86@kernel.org" <x86@kernel.org>, rusty@rustcorp.com.au,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
 get-and-clear 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 06/14/2012 11:29 AM, Konrad Rzeszutek Wilk wrote:
> 
> Lets rope Rusty in this since he is the maintainer of lguest.
>

Also, let's have realistic expectations for lguest.

I don't want to break lguest just for sh*ts and giggles, but if lguest
is in the way of making forward progress for other things, it would have
to have a very strong case to not be sacrificed.

	-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 Jun 14 19:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfFUs-0004V0-Cl; Thu, 14 Jun 2012 19:14:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1SfFUq-0004Ub-4D
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 19:14:20 +0000
Received: from [193.109.254.147:58493] by server-8.bemta-14.messagelabs.com id
	0B/06-27132-B083ADF4; Thu, 14 Jun 2012 19:14:19 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339701258!2113436!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 14 Jun 2012 19:14:18 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 19:14:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=C19JyTZiiBP5yWsPrvgcEr8YJMbztS4lThZbBvVZEKc=; b=lSgv0jV
	5tP5tCdn86PlCZNpexEPVaK2lOgsOTTwSW8svKkBc0HxOxMtZj0LDAkiQVV1WTTj
	GnvyIX8Hdh6uHB9+fj2Ece5T3M5FWx3W2eMCtuxUCI1iBMr8BfaCybvZZKUqYUqu
	au5e/f1TyU6DUvyAJMzF4+26ZaUk9lCAmDMk=
Received: (qmail 23399 invoked from network); 14 Jun 2012 21:14:16 +0200
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.60.25)
	by mail.zeus06.de with ESMTPA; 14 Jun 2012 21:14:16 +0200
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 599D02CA8F;
	Thu, 14 Jun 2012 21:16:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 7nRNZrk67fze; Thu, 14 Jun 2012 21:16:31 +0200 (CEST)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 3ADF62CA8E;
	Thu, 14 Jun 2012 21:16:31 +0200 (CEST)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 14 Jun 2012 21:16:31 +0200
Mime-Version: 1.0
In-Reply-To: <zarafa.4fda3013.1340.11e86b0675d17248@uhura.space.zz>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.6-32752
Thread-Index: Ac1KXM9out/ATiayTmSe2spo1XMpMgABPxHA
Message-Id: <zarafa.4fda388f.1828.7c9d64e81fb43d1c@uhura.space.zz>
Cc: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK, found the problem in the patch file, baking 3.4.2...BR, Carsten.

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.or=
g] Im Auftrag von Carsten Schiers
Gesendet: Donnerstag, 14. Juni 2012 20:40
An: Konrad Rzeszutek Wilk
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

Konrad, against which kernel version did you produce this patch? It will no=
t succeed with 3.4.2 at least, will look up some older version now...

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.or=
g] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Mittwoch, 13. Juni 2012 18:55
An: Carsten Schiers
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> > =

> > =A0
> > don't want to be pushy, as I have no real issue. I simply use the Xenif=
ied kernel or take the double load. =

> > =

> > But I think this mistery is still open. My last status was that the =

> > latest patch you produced resulted in a BUG,
> =

> Yes, that is right. Thank you for reminding me.
> > =

> > so we still have not checked whether our theory is correct.
> =

> No we haven't. And I should be have no trouble reproducing this. I can =

> just write a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please try it out=
? It has the #define DEBUG 1 set so it should print a lot of stuff when the=
 DVB module loads. If it crashes please send me the full log.

Thanks.
>From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
 [v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |  187 +++++++++++++++++++++++++++++++++++++++++++++=
++-
 include/xen/xen-ops.h |    2 +
 mm/vmalloc.c          |   18 +++++-
 3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3a73785..960d206=
 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 =

 #include <trace/events/xen.h>
 =

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */  #define MAX_CONTIG_ORDER 9 /* 2M=
B */  static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 =

 #define VOID_PTE (mfn_pte(0, __pgprot(0)))  static void xen_zap_pfn_range(=
unsigned long vaddr, unsigned int order, @@ -2075,6 +2077,42 @@ static void=
 xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n =3D 0;
+	struct multicall_space mcs;
+	struct page *page;
+
+	xen_mc_batch();
+	for (i =3D 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+#define DEBUG 1
+		if (in_frames) {
+#ifdef DEBUG
+			printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+				__func__, i, page_to_pfn(page),
+				pfn_to_mfn(page_to_pfn(page)), page_address(page)); #endif
+			in_frames[i] =3D pfn_to_mfn(page_to_pfn(page));
+		}
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_=
PTE, 0);
+		set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] =3D page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+	return n;
+}
 =

 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to @=
@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long va=
ddr, int order,
 =

 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn, /* in_frame if we failed*/
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit =3D 1ULL << order;
+	for (i =3D 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+		if (mfns)
+			mfn =3D mfns[i];
+		else
+			mfn =3D first_mfn + i;
+
+		if (i < (limit - 1))
+			flags =3D 0;
+		else {
+			if (order =3D=3D 0)
+				flags =3D UVMF_INVLPG | UVMF_ALL;
+			else
+				flags =3D UVMF_TLB_FLUSH | UVMF_ALL;
+		}
+#ifdef DEBUG
+		printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+			__func__, i, page_to_pfn(page), mfn, page_address(page)); #endif
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 =

 /*
  * Perform the hypercall to exchange a region of our pfns to point to @@ -=
2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_in, =
unsigned int order_in,  {
 	long rc;
 	int success;
-
+#ifdef DEBUG
+	int i;
+#endif
 	struct xen_memory_exchange exchange =3D {
 		.in =3D {
 			.nr_extents   =3D extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents=
_in, unsigned int order_in,
 =

 	rc =3D HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
 	success =3D (exchange.nr_exchanged =3D=3D extents_in);
-
+#ifdef DEBUG
+	for (i =3D 0; i <  exchange.nr_exchanged; i++) {
+		printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n",  __func__,pfns_in[i=
], mfns_out[i]);
+	}
+#endif
 	BUG_ON(!success && ((exchange.nr_exchanged !=3D 0) || (rc =3D=3D 0)));
 	BUG_ON(success && (rc !=3D 0));
 =

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vsta=
rt, unsigned int order)
 	xen_zap_pfn_range(vstart, order, NULL, out_frames);
 =

 	/* 3. Do the exchange for non-contiguous MFNs. */
-	success =3D xen_exchange_memory(1, order, &in_frame, 1UL << order,
-					0, out_frames, 0);
+	success =3D xen_exchange_memory(1, order, &in_frame,
+				      1UL << order, 0, out_frames, 0);
 =

 	/* 4. Map new pages in place of old pages. */
 	if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vst=
art, unsigned int order)  }  EXPORT_SYMBOL_GPL(xen_destroy_contiguous_regio=
n);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames =3D discontig_frames, *out_frames =3D limited_fr=
ames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n =3D 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map =3D kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map =3D &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i =3D 0; i < (1ULL << order); i++) {
+		void *vaddr;
+		page =3D &pages[i];
+
+		vaddr =3D page_address(page);
+#ifdef DEBUG
+		printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n", =

+__func__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr)))=
; #endif
+		if (address_bits) {
+			if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map !=3D &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n =3D xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, =

+limit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success =3D xen_exchange_memory(n, 0 /* this is always called per page */=
, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map !=3D &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)  { diff --git a/includ=
e/xen/xen-ops.h b/include/xen/xen-ops.h index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 =

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 =

 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long=
 end) @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_str=
uct *area, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size =3D (nr_pages * sizeof(struct page *));
 =

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] =3D page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages =3D i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 =

 	if (map_vm_area(area, prot, &pages))
--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5067 - Ausgabedatum: 13.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5069 - Ausgabedatum: 14.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfFUs-0004V0-Cl; Thu, 14 Jun 2012 19:14:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1SfFUq-0004Ub-4D
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 19:14:20 +0000
Received: from [193.109.254.147:58493] by server-8.bemta-14.messagelabs.com id
	0B/06-27132-B083ADF4; Thu, 14 Jun 2012 19:14:19 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1339701258!2113436!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.2 required=7.0 tests=FROM_EXCESS_QP,
	MIME_QP_LONG_LINE,SUBJECT_EXCESS_QP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 14 Jun 2012 19:14:18 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 19:14:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=C19JyTZiiBP5yWsPrvgcEr8YJMbztS4lThZbBvVZEKc=; b=lSgv0jV
	5tP5tCdn86PlCZNpexEPVaK2lOgsOTTwSW8svKkBc0HxOxMtZj0LDAkiQVV1WTTj
	GnvyIX8Hdh6uHB9+fj2Ece5T3M5FWx3W2eMCtuxUCI1iBMr8BfaCybvZZKUqYUqu
	au5e/f1TyU6DUvyAJMzF4+26ZaUk9lCAmDMk=
Received: (qmail 23399 invoked from network); 14 Jun 2012 21:14:16 +0200
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.60.25)
	by mail.zeus06.de with ESMTPA; 14 Jun 2012 21:14:16 +0200
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 599D02CA8F;
	Thu, 14 Jun 2012 21:16:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 7nRNZrk67fze; Thu, 14 Jun 2012 21:16:31 +0200 (CEST)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 3ADF62CA8E;
	Thu, 14 Jun 2012 21:16:31 +0200 (CEST)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Thu, 14 Jun 2012 21:16:31 +0200
Mime-Version: 1.0
In-Reply-To: <zarafa.4fda3013.1340.11e86b0675d17248@uhura.space.zz>
References: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.6-32752
Thread-Index: Ac1KXM9out/ATiayTmSe2spo1XMpMgABPxHA
Message-Id: <zarafa.4fda388f.1828.7c9d64e81fb43d1c@uhura.space.zz>
Cc: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK, found the problem in the patch file, baking 3.4.2...BR, Carsten.

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.or=
g] Im Auftrag von Carsten Schiers
Gesendet: Donnerstag, 14. Juni 2012 20:40
An: Konrad Rzeszutek Wilk
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

Konrad, against which kernel version did you produce this patch? It will no=
t succeed with 3.4.2 at least, will look up some older version now...

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.or=
g] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Mittwoch, 13. Juni 2012 18:55
An: Carsten Schiers
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> > =

> > =A0
> > don't want to be pushy, as I have no real issue. I simply use the Xenif=
ied kernel or take the double load. =

> > =

> > But I think this mistery is still open. My last status was that the =

> > latest patch you produced resulted in a BUG,
> =

> Yes, that is right. Thank you for reminding me.
> > =

> > so we still have not checked whether our theory is correct.
> =

> No we haven't. And I should be have no trouble reproducing this. I can =

> just write a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please try it out=
? It has the #define DEBUG 1 set so it should print a lot of stuff when the=
 DVB module loads. If it crashes please send me the full log.

Thanks.
>From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
 [v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |  187 +++++++++++++++++++++++++++++++++++++++++++++=
++-
 include/xen/xen-ops.h |    2 +
 mm/vmalloc.c          |   18 +++++-
 3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3a73785..960d206=
 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 =

 #include <trace/events/xen.h>
 =

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */  #define MAX_CONTIG_ORDER 9 /* 2M=
B */  static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 =

 #define VOID_PTE (mfn_pte(0, __pgprot(0)))  static void xen_zap_pfn_range(=
unsigned long vaddr, unsigned int order, @@ -2075,6 +2077,42 @@ static void=
 xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n =3D 0;
+	struct multicall_space mcs;
+	struct page *page;
+
+	xen_mc_batch();
+	for (i =3D 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+#define DEBUG 1
+		if (in_frames) {
+#ifdef DEBUG
+			printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+				__func__, i, page_to_pfn(page),
+				pfn_to_mfn(page_to_pfn(page)), page_address(page)); #endif
+			in_frames[i] =3D pfn_to_mfn(page_to_pfn(page));
+		}
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_=
PTE, 0);
+		set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] =3D page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+	return n;
+}
 =

 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to @=
@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long va=
ddr, int order,
 =

 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn, /* in_frame if we failed*/
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit =3D 1ULL << order;
+	for (i =3D 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+
+		page =3D &pages[i];
+		mcs =3D __xen_mc_entry(0);
+		if (mfns)
+			mfn =3D mfns[i];
+		else
+			mfn =3D first_mfn + i;
+
+		if (i < (limit - 1))
+			flags =3D 0;
+		else {
+			if (order =3D=3D 0)
+				flags =3D UVMF_INVLPG | UVMF_ALL;
+			else
+				flags =3D UVMF_TLB_FLUSH | UVMF_ALL;
+		}
+#ifdef DEBUG
+		printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+			__func__, i, page_to_pfn(page), mfn, page_address(page)); #endif
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 =

 /*
  * Perform the hypercall to exchange a region of our pfns to point to @@ -=
2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_in, =
unsigned int order_in,  {
 	long rc;
 	int success;
-
+#ifdef DEBUG
+	int i;
+#endif
 	struct xen_memory_exchange exchange =3D {
 		.in =3D {
 			.nr_extents   =3D extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents=
_in, unsigned int order_in,
 =

 	rc =3D HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
 	success =3D (exchange.nr_exchanged =3D=3D extents_in);
-
+#ifdef DEBUG
+	for (i =3D 0; i <  exchange.nr_exchanged; i++) {
+		printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n",  __func__,pfns_in[i=
], mfns_out[i]);
+	}
+#endif
 	BUG_ON(!success && ((exchange.nr_exchanged !=3D 0) || (rc =3D=3D 0)));
 	BUG_ON(success && (rc !=3D 0));
 =

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vsta=
rt, unsigned int order)
 	xen_zap_pfn_range(vstart, order, NULL, out_frames);
 =

 	/* 3. Do the exchange for non-contiguous MFNs. */
-	success =3D xen_exchange_memory(1, order, &in_frame, 1UL << order,
-					0, out_frames, 0);
+	success =3D xen_exchange_memory(1, order, &in_frame,
+				      1UL << order, 0, out_frames, 0);
 =

 	/* 4. Map new pages in place of old pages. */
 	if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vst=
art, unsigned int order)  }  EXPORT_SYMBOL_GPL(xen_destroy_contiguous_regio=
n);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames =3D discontig_frames, *out_frames =3D limited_fr=
ames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n =3D 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map =3D kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map =3D &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i =3D 0; i < (1ULL << order); i++) {
+		void *vaddr;
+		page =3D &pages[i];
+
+		vaddr =3D page_address(page);
+#ifdef DEBUG
+		printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n", =

+__func__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr)))=
; #endif
+		if (address_bits) {
+			if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map !=3D &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n =3D xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, =

+limit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success =3D xen_exchange_memory(n, 0 /* this is always called per page */=
, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map !=3D &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)  { diff --git a/includ=
e/xen/xen-ops.h b/include/xen/xen-ops.h index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 =

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 =

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 =

 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long=
 end) @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_str=
uct *area, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask =3D gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &=3D ~(__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size =3D (nr_pages * sizeof(struct page *));
 =

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *a=
rea, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] =3D page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages =3D i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 =

 	if (map_vm_area(area, prot, &pages))
--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5067 - Ausgabedatum: 13.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG =FCberpr=FCft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5069 - Ausgabedatum: 14.06.2012 =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfFr4-0005Ci-Jv; Thu, 14 Jun 2012 19:37:18 +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 1SfFr3-0005Cd-8P
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:37:17 +0000
Received: from [193.109.254.147:23308] by server-8.bemta-14.messagelabs.com id
	0D/80-27132-C6D3ADF4; Thu, 14 Jun 2012 19:37:16 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339702635!9848027!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17184 invoked from network); 14 Jun 2012 19:37:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	14 Jun 2012 19:37:15 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5EJb8kr010518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:37:09 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJb5hk030026; Thu, 14 Jun 2012 15:37:06 -0400
Date: Thu, 14 Jun 2012 22:37:41 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614193741.GC19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:41PM +0100, Anthony PERARD wrote:
> We are using this in our quirk lookup provided by patch
> titled: Introduce Xen PCI Passthrough, PCI config space helpers.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/pci_ids.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_ids.h b/hw/pci_ids.h
> index e8235a7..649e6b3 100644
> --- a/hw/pci_ids.h
> +++ b/hw/pci_ids.h
> @@ -118,6 +118,7 @@
>  #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
> +#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
>  
>  #define PCI_VENDOR_ID_XEN               0x5853
>  #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:37:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfFr4-0005Ci-Jv; Thu, 14 Jun 2012 19:37:18 +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 1SfFr3-0005Cd-8P
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:37:17 +0000
Received: from [193.109.254.147:23308] by server-8.bemta-14.messagelabs.com id
	0D/80-27132-C6D3ADF4; Thu, 14 Jun 2012 19:37:16 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1339702635!9848027!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17184 invoked from network); 14 Jun 2012 19:37:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	14 Jun 2012 19:37:15 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5EJb8kr010518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:37:09 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJb5hk030026; Thu, 14 Jun 2012 15:37:06 -0400
Date: Thu, 14 Jun 2012 22:37:41 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614193741.GC19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:41PM +0100, Anthony PERARD wrote:
> We are using this in our quirk lookup provided by patch
> titled: Introduce Xen PCI Passthrough, PCI config space helpers.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/pci_ids.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_ids.h b/hw/pci_ids.h
> index e8235a7..649e6b3 100644
> --- a/hw/pci_ids.h
> +++ b/hw/pci_ids.h
> @@ -118,6 +118,7 @@
>  #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
> +#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
>  
>  #define PCI_VENDOR_ID_XEN               0x5853
>  #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:38:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFre-0005EP-0y; Thu, 14 Jun 2012 19:37:54 +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 1SfFrd-0005EI-49
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:37:53 +0000
Received: from [85.158.138.51:6723] by server-8.bemta-3.messagelabs.com id
	C2/9A-06157-09D3ADF4; Thu, 14 Jun 2012 19:37:52 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339702671!19634392!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16312 invoked from network); 14 Jun 2012 19:37:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 19:37:51 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5EJbmYl007597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:37:48 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJbjse030182; Thu, 14 Jun 2012 15:37:46 -0400
Date: Thu, 14 Jun 2012 22:38:22 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614193821.GD19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 4/9] pci.c: Add opaque argument to
 pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:44PM +0100, Anthony PERARD wrote:
> The purpose is to have a more generic pci_for_each_device by passing an extra
> argument to the function called on every device.
> 
> This patch will be used in a next patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/pci.c          |   11 +++++++----
>  hw/pci.h          |    4 +++-
>  hw/xen_platform.c |    8 ++++----
>  3 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 127b7ac..d6537e3 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
>  };
>  
>  static void pci_for_each_device_under_bus(PCIBus *bus,
> -                                          void (*fn)(PCIBus *b, PCIDevice *d))
> +                                          void (*fn)(PCIBus *b, PCIDevice *d,
> +                                                     void *opaque),
> +                                          void *opaque)
>  {
>      PCIDevice *d;
>      int devfn;
> @@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
>      for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
>          d = bus->devices[devfn];
>          if (d) {
> -            fn(bus, d);
> +            fn(bus, d, opaque);
>          }
>      }
>  }
>  
>  void pci_for_each_device(PCIBus *bus, int bus_num,
> -                         void (*fn)(PCIBus *b, PCIDevice *d))
> +                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
> +                         void *opaque)
>  {
>      bus = pci_find_bus_nr(bus, bus_num);
>  
>      if (bus) {
> -        pci_for_each_device_under_bus(bus, fn);
> +        pci_for_each_device_under_bus(bus, fn, opaque);
>      }
>  }
>  
> diff --git a/hw/pci.h b/hw/pci.h
> index 7f223c0..95b608c 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
>  PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
>                                 const char *default_devaddr);
>  int pci_bus_num(PCIBus *s);
> -void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
> +void pci_for_each_device(PCIBus *bus, int bus_num,
> +                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
> +                         void *opaque);
>  PCIBus *pci_find_root_bus(int domain);
>  int pci_find_domain(const PCIBus *bus);
>  PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0214f37..c1fe984 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
>  #define UNPLUG_ALL_NICS 2
>  #define UNPLUG_AUX_IDE_DISKS 4
>  
> -static void unplug_nic(PCIBus *b, PCIDevice *d)
> +static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_NETWORK_ETHERNET) {
> @@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_nics(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_nic);
> +    pci_for_each_device(bus, 0, unplug_nic, NULL);
>  }
>  
> -static void unplug_disks(PCIBus *b, PCIDevice *d)
> +static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_STORAGE_IDE) {
> @@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_disks(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_disks);
> +    pci_for_each_device(bus, 0, unplug_disks, NULL);
>  }
>  
>  static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:38:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFre-0005EP-0y; Thu, 14 Jun 2012 19:37:54 +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 1SfFrd-0005EI-49
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:37:53 +0000
Received: from [85.158.138.51:6723] by server-8.bemta-3.messagelabs.com id
	C2/9A-06157-09D3ADF4; Thu, 14 Jun 2012 19:37:52 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339702671!19634392!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16312 invoked from network); 14 Jun 2012 19:37:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 19:37:51 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5EJbmYl007597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:37:48 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJbjse030182; Thu, 14 Jun 2012 15:37:46 -0400
Date: Thu, 14 Jun 2012 22:38:22 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614193821.GD19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 4/9] pci.c: Add opaque argument to
 pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:44PM +0100, Anthony PERARD wrote:
> The purpose is to have a more generic pci_for_each_device by passing an extra
> argument to the function called on every device.
> 
> This patch will be used in a next patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/pci.c          |   11 +++++++----
>  hw/pci.h          |    4 +++-
>  hw/xen_platform.c |    8 ++++----
>  3 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 127b7ac..d6537e3 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
>  };
>  
>  static void pci_for_each_device_under_bus(PCIBus *bus,
> -                                          void (*fn)(PCIBus *b, PCIDevice *d))
> +                                          void (*fn)(PCIBus *b, PCIDevice *d,
> +                                                     void *opaque),
> +                                          void *opaque)
>  {
>      PCIDevice *d;
>      int devfn;
> @@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
>      for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
>          d = bus->devices[devfn];
>          if (d) {
> -            fn(bus, d);
> +            fn(bus, d, opaque);
>          }
>      }
>  }
>  
>  void pci_for_each_device(PCIBus *bus, int bus_num,
> -                         void (*fn)(PCIBus *b, PCIDevice *d))
> +                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
> +                         void *opaque)
>  {
>      bus = pci_find_bus_nr(bus, bus_num);
>  
>      if (bus) {
> -        pci_for_each_device_under_bus(bus, fn);
> +        pci_for_each_device_under_bus(bus, fn, opaque);
>      }
>  }
>  
> diff --git a/hw/pci.h b/hw/pci.h
> index 7f223c0..95b608c 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
>  PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
>                                 const char *default_devaddr);
>  int pci_bus_num(PCIBus *s);
> -void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
> +void pci_for_each_device(PCIBus *bus, int bus_num,
> +                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
> +                         void *opaque);
>  PCIBus *pci_find_root_bus(int domain);
>  int pci_find_domain(const PCIBus *bus);
>  PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0214f37..c1fe984 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
>  #define UNPLUG_ALL_NICS 2
>  #define UNPLUG_AUX_IDE_DISKS 4
>  
> -static void unplug_nic(PCIBus *b, PCIDevice *d)
> +static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_NETWORK_ETHERNET) {
> @@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_nics(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_nic);
> +    pci_for_each_device(bus, 0, unplug_nic, NULL);
>  }
>  
> -static void unplug_disks(PCIBus *b, PCIDevice *d)
> +static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_STORAGE_IDE) {
> @@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_disks(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_disks);
> +    pci_for_each_device(bus, 0, unplug_disks, NULL);
>  }
>  
>  static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:39:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFsq-0005Kw-Fh; Thu, 14 Jun 2012 19:39:08 +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 1SfFso-0005Ke-CZ
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:39:06 +0000
Received: from [85.158.138.51:12864] by server-11.bemta-3.messagelabs.com id
	E2/13-02904-9DD3ADF4; Thu, 14 Jun 2012 19:39:05 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339702744!9037896!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8938 invoked from network); 14 Jun 2012 19:39:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 19:39:04 -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 q5EJd1Iq022263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:39:01 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q5EJcxFw005801; Thu, 14 Jun 2012 15:38:59 -0400
Date: Thu, 14 Jun 2012 22:39:35 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614193935.GE19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-6-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-6-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 5/9] qdev-properties: Introduce
	pci-host-devaddr.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:45PM +0100, Anthony PERARD wrote:
> This new property will be used to specify a host pci device address.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/qdev-properties.c |  107 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  hw/qdev.h            |    3 +
>  qemu-common.h        |    7 +++
>  3 files changed, 117 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index 9ae3187..43e1964 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -899,6 +899,113 @@ PropertyInfo qdev_prop_blocksize = {
>      .set   = set_blocksize,
>  };
>  
> +/* --- pci host address --- */
> +
> +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    char buffer[] = "xxxx:xx:xx.x";
> +    char *p = buffer;
> +    int rc = 0;
> +
> +    rc = snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
> +                  addr->domain, addr->bus, addr->slot, addr->function);
> +    assert(rc == sizeof(buffer) - 1);
> +
> +    visit_type_str(v, &p, name, errp);
> +}
> +
> +/*
> + * Parse [<domain>:]<bus>:<slot>.<func>
> + *   if <domain> is not supplied, it's assumed to be 0.
> + */
> +static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    Error *local_err = NULL;
> +    char *str, *p;
> +    char *e;
> +    unsigned long val;
> +    unsigned long dom = 0, bus = 0;
> +    unsigned int slot = 0, func = 0;
> +
> +    if (dev->state != DEV_STATE_CREATED) {
> +        error_set(errp, QERR_PERMISSION_DENIED);
> +        return;
> +    }
> +
> +    visit_type_str(v, &str, name, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        return;
> +    }
> +
> +    p = str;
> +    val = strtoul(p, &e, 16);
> +    if (e == p || *e != ':') {
> +        goto inval;
> +    }
> +    bus = val;
> +
> +    p = e + 1;
> +    val = strtoul(p, &e, 16);
> +    if (e == p) {
> +        goto inval;
> +    }
> +    if (*e == ':') {
> +        dom = bus;
> +        bus = val;
> +        p = e + 1;
> +        val = strtoul(p, &e, 16);
> +        if (e == p) {
> +            goto inval;
> +        }
> +    }
> +    slot = val;
> +
> +    if (*e != '.') {
> +        goto inval;
> +    }
> +    p = e + 1;
> +    val = strtoul(p, &e, 10);
> +    if (e == p) {
> +        goto inval;
> +    }
> +    func = val;
> +
> +    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7) {
> +        goto inval;
> +    }
> +
> +    if (*e) {
> +        goto inval;
> +    }
> +
> +    addr->domain = dom;
> +    addr->bus = bus;
> +    addr->slot = slot;
> +    addr->function = func;
> +
> +    g_free(str);
> +    return;
> +
> +inval:
> +    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +    g_free(str);
> +}
> +
> +PropertyInfo qdev_prop_pci_host_devaddr = {
> +    .name = "pci-host-devaddr",
> +    .get = get_pci_host_devaddr,
> +    .set = set_pci_host_devaddr,
> +};
> +
>  /* --- public helpers --- */
>  
>  static Property *qdev_prop_walk(Property *props, const char *name)
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 5386b16..8746f84 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -223,6 +223,7 @@ extern PropertyInfo qdev_prop_netdev;
>  extern PropertyInfo qdev_prop_vlan;
>  extern PropertyInfo qdev_prop_pci_devfn;
>  extern PropertyInfo qdev_prop_blocksize;
> +extern PropertyInfo qdev_prop_pci_host_devaddr;
>  
>  #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
>          .name      = (_name),                                    \
> @@ -286,6 +287,8 @@ extern PropertyInfo qdev_prop_blocksize;
>                          LostTickPolicy)
>  #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
>      DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
> +#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
> +    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
>  
>  #define DEFINE_PROP_END_OF_LIST()               \
>      {}
> diff --git a/qemu-common.h b/qemu-common.h
> index 91e0562..0d6e51c 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
>      LOST_TICK_MAX
>  } LostTickPolicy;
>  
> +typedef struct PCIHostDeviceAddress {
> +    unsigned int domain;
> +    unsigned int bus;
> +    unsigned int slot;
> +    unsigned int function;
> +} PCIHostDeviceAddress;
> +
>  void tcg_exec_init(unsigned long tb_size);
>  bool tcg_enabled(void);
>  
> -- 
> 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 Jun 14 19:39:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFsq-0005Kw-Fh; Thu, 14 Jun 2012 19:39:08 +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 1SfFso-0005Ke-CZ
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:39:06 +0000
Received: from [85.158.138.51:12864] by server-11.bemta-3.messagelabs.com id
	E2/13-02904-9DD3ADF4; Thu, 14 Jun 2012 19:39:05 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1339702744!9037896!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8938 invoked from network); 14 Jun 2012 19:39:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	14 Jun 2012 19:39:04 -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 q5EJd1Iq022263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:39:01 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q5EJcxFw005801; Thu, 14 Jun 2012 15:38:59 -0400
Date: Thu, 14 Jun 2012 22:39:35 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614193935.GE19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-6-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-6-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 5/9] qdev-properties: Introduce
	pci-host-devaddr.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:45PM +0100, Anthony PERARD wrote:
> This new property will be used to specify a host pci device address.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/qdev-properties.c |  107 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  hw/qdev.h            |    3 +
>  qemu-common.h        |    7 +++
>  3 files changed, 117 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index 9ae3187..43e1964 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -899,6 +899,113 @@ PropertyInfo qdev_prop_blocksize = {
>      .set   = set_blocksize,
>  };
>  
> +/* --- pci host address --- */
> +
> +static void get_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    char buffer[] = "xxxx:xx:xx.x";
> +    char *p = buffer;
> +    int rc = 0;
> +
> +    rc = snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
> +                  addr->domain, addr->bus, addr->slot, addr->function);
> +    assert(rc == sizeof(buffer) - 1);
> +
> +    visit_type_str(v, &p, name, errp);
> +}
> +
> +/*
> + * Parse [<domain>:]<bus>:<slot>.<func>
> + *   if <domain> is not supplied, it's assumed to be 0.
> + */
> +static void set_pci_host_devaddr(Object *obj, Visitor *v, void *opaque,
> +                                 const char *name, Error **errp)
> +{
> +    DeviceState *dev = DEVICE(obj);
> +    Property *prop = opaque;
> +    PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
> +    Error *local_err = NULL;
> +    char *str, *p;
> +    char *e;
> +    unsigned long val;
> +    unsigned long dom = 0, bus = 0;
> +    unsigned int slot = 0, func = 0;
> +
> +    if (dev->state != DEV_STATE_CREATED) {
> +        error_set(errp, QERR_PERMISSION_DENIED);
> +        return;
> +    }
> +
> +    visit_type_str(v, &str, name, &local_err);
> +    if (local_err) {
> +        error_propagate(errp, local_err);
> +        return;
> +    }
> +
> +    p = str;
> +    val = strtoul(p, &e, 16);
> +    if (e == p || *e != ':') {
> +        goto inval;
> +    }
> +    bus = val;
> +
> +    p = e + 1;
> +    val = strtoul(p, &e, 16);
> +    if (e == p) {
> +        goto inval;
> +    }
> +    if (*e == ':') {
> +        dom = bus;
> +        bus = val;
> +        p = e + 1;
> +        val = strtoul(p, &e, 16);
> +        if (e == p) {
> +            goto inval;
> +        }
> +    }
> +    slot = val;
> +
> +    if (*e != '.') {
> +        goto inval;
> +    }
> +    p = e + 1;
> +    val = strtoul(p, &e, 10);
> +    if (e == p) {
> +        goto inval;
> +    }
> +    func = val;
> +
> +    if (dom > 0xffff || bus > 0xff || slot > 0x1f || func > 7) {
> +        goto inval;
> +    }
> +
> +    if (*e) {
> +        goto inval;
> +    }
> +
> +    addr->domain = dom;
> +    addr->bus = bus;
> +    addr->slot = slot;
> +    addr->function = func;
> +
> +    g_free(str);
> +    return;
> +
> +inval:
> +    error_set_from_qdev_prop_error(errp, EINVAL, dev, prop, str);
> +    g_free(str);
> +}
> +
> +PropertyInfo qdev_prop_pci_host_devaddr = {
> +    .name = "pci-host-devaddr",
> +    .get = get_pci_host_devaddr,
> +    .set = set_pci_host_devaddr,
> +};
> +
>  /* --- public helpers --- */
>  
>  static Property *qdev_prop_walk(Property *props, const char *name)
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 5386b16..8746f84 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -223,6 +223,7 @@ extern PropertyInfo qdev_prop_netdev;
>  extern PropertyInfo qdev_prop_vlan;
>  extern PropertyInfo qdev_prop_pci_devfn;
>  extern PropertyInfo qdev_prop_blocksize;
> +extern PropertyInfo qdev_prop_pci_host_devaddr;
>  
>  #define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
>          .name      = (_name),                                    \
> @@ -286,6 +287,8 @@ extern PropertyInfo qdev_prop_blocksize;
>                          LostTickPolicy)
>  #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f, _d) \
>      DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_blocksize, uint16_t)
> +#define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
> +    DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
>  
>  #define DEFINE_PROP_END_OF_LIST()               \
>      {}
> diff --git a/qemu-common.h b/qemu-common.h
> index 91e0562..0d6e51c 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -274,6 +274,13 @@ typedef enum LostTickPolicy {
>      LOST_TICK_MAX
>  } LostTickPolicy;
>  
> +typedef struct PCIHostDeviceAddress {
> +    unsigned int domain;
> +    unsigned int bus;
> +    unsigned int slot;
> +    unsigned int function;
> +} PCIHostDeviceAddress;
> +
>  void tcg_exec_init(unsigned long tb_size);
>  bool tcg_enabled(void);
>  
> -- 
> 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 Jun 14 19:39:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFtI-0005Nn-Rw; Thu, 14 Jun 2012 19:39:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SfFtI-0005Na-BH
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:39:36 +0000
Received: from [85.158.139.83:18769] by server-9.bemta-5.messagelabs.com id
	E0/61-01069-7FD3ADF4; Thu, 14 Jun 2012 19:39:35 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339702774!23874210!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19143 invoked from network); 14 Jun 2012 19:39:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 19:39:34 -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 q5EJdVmf022395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:39:31 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJdT8A029155; Thu, 14 Jun 2012 15:39:29 -0400
Date: Thu, 14 Jun 2012 22:40:05 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614194005.GF19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-9-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-9-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 8/9] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:48PM +0100, Anthony PERARD wrote:
> This patch move the msi definition from apic.c to apic-msidef.h. So it can be
> used also by other .c files.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
>  hw/apic.c        |   11 +----------
>  2 files changed, 31 insertions(+), 10 deletions(-)
>  create mode 100644 hw/apic-msidef.h
> 
> diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
> new file mode 100644
> index 0000000..6e2eb71
> --- /dev/null
> +++ b/hw/apic-msidef.h
> @@ -0,0 +1,30 @@
> +#ifndef HW_APIC_MSIDEF_H
> +#define HW_APIC_MSIDEF_H
> +
> +/*
> + * Intel APIC constants: from include/asm/msidef.h
> + */
> +
> +/*
> + * Shifts for MSI data
> + */
> +
> +#define MSI_DATA_VECTOR_SHIFT           0
> +#define  MSI_DATA_VECTOR_MASK           0x000000ff
> +
> +#define MSI_DATA_DELIVERY_MODE_SHIFT    8
> +#define MSI_DATA_LEVEL_SHIFT            14
> +#define MSI_DATA_TRIGGER_SHIFT          15
> +
> +/*
> + * Shift/mask fields for msi address
> + */
> +
> +#define MSI_ADDR_DEST_MODE_SHIFT        2
> +
> +#define MSI_ADDR_REDIRECTION_SHIFT      3
> +
> +#define MSI_ADDR_DEST_ID_SHIFT          12
> +#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
> +
> +#endif /* HW_APIC_MSIDEF_H */
> diff --git a/hw/apic.c b/hw/apic.c
> index 5fbf01c..60552df 100644
> --- a/hw/apic.c
> +++ b/hw/apic.c
> @@ -23,19 +23,10 @@
>  #include "host-utils.h"
>  #include "trace.h"
>  #include "pc.h"
> +#include "apic-msidef.h"
>  
>  #define MAX_APIC_WORDS 8
>  
> -/* Intel APIC constants: from include/asm/msidef.h */
> -#define MSI_DATA_VECTOR_SHIFT		0
> -#define MSI_DATA_VECTOR_MASK		0x000000ff
> -#define MSI_DATA_DELIVERY_MODE_SHIFT	8
> -#define MSI_DATA_TRIGGER_SHIFT		15
> -#define MSI_DATA_LEVEL_SHIFT		14
> -#define MSI_ADDR_DEST_MODE_SHIFT	2
> -#define MSI_ADDR_DEST_ID_SHIFT		12
> -#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
> -
>  #define SYNC_FROM_VAPIC                 0x1
>  #define SYNC_TO_VAPIC                   0x2
>  #define SYNC_ISR_IRR_TO_VAPIC           0x4
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:39:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFtI-0005Nn-Rw; Thu, 14 Jun 2012 19:39:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SfFtI-0005Na-BH
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:39:36 +0000
Received: from [85.158.139.83:18769] by server-9.bemta-5.messagelabs.com id
	E0/61-01069-7FD3ADF4; Thu, 14 Jun 2012 19:39:35 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1339702774!23874210!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19143 invoked from network); 14 Jun 2012 19:39:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 19:39:34 -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 q5EJdVmf022395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:39:31 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJdT8A029155; Thu, 14 Jun 2012 15:39:29 -0400
Date: Thu, 14 Jun 2012 22:40:05 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614194005.GF19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-9-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-9-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 8/9] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:48PM +0100, Anthony PERARD wrote:
> This patch move the msi definition from apic.c to apic-msidef.h. So it can be
> used also by other .c files.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  hw/apic-msidef.h |   30 ++++++++++++++++++++++++++++++
>  hw/apic.c        |   11 +----------
>  2 files changed, 31 insertions(+), 10 deletions(-)
>  create mode 100644 hw/apic-msidef.h
> 
> diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
> new file mode 100644
> index 0000000..6e2eb71
> --- /dev/null
> +++ b/hw/apic-msidef.h
> @@ -0,0 +1,30 @@
> +#ifndef HW_APIC_MSIDEF_H
> +#define HW_APIC_MSIDEF_H
> +
> +/*
> + * Intel APIC constants: from include/asm/msidef.h
> + */
> +
> +/*
> + * Shifts for MSI data
> + */
> +
> +#define MSI_DATA_VECTOR_SHIFT           0
> +#define  MSI_DATA_VECTOR_MASK           0x000000ff
> +
> +#define MSI_DATA_DELIVERY_MODE_SHIFT    8
> +#define MSI_DATA_LEVEL_SHIFT            14
> +#define MSI_DATA_TRIGGER_SHIFT          15
> +
> +/*
> + * Shift/mask fields for msi address
> + */
> +
> +#define MSI_ADDR_DEST_MODE_SHIFT        2
> +
> +#define MSI_ADDR_REDIRECTION_SHIFT      3
> +
> +#define MSI_ADDR_DEST_ID_SHIFT          12
> +#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
> +
> +#endif /* HW_APIC_MSIDEF_H */
> diff --git a/hw/apic.c b/hw/apic.c
> index 5fbf01c..60552df 100644
> --- a/hw/apic.c
> +++ b/hw/apic.c
> @@ -23,19 +23,10 @@
>  #include "host-utils.h"
>  #include "trace.h"
>  #include "pc.h"
> +#include "apic-msidef.h"
>  
>  #define MAX_APIC_WORDS 8
>  
> -/* Intel APIC constants: from include/asm/msidef.h */
> -#define MSI_DATA_VECTOR_SHIFT		0
> -#define MSI_DATA_VECTOR_MASK		0x000000ff
> -#define MSI_DATA_DELIVERY_MODE_SHIFT	8
> -#define MSI_DATA_TRIGGER_SHIFT		15
> -#define MSI_DATA_LEVEL_SHIFT		14
> -#define MSI_ADDR_DEST_MODE_SHIFT	2
> -#define MSI_ADDR_DEST_ID_SHIFT		12
> -#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
> -
>  #define SYNC_FROM_VAPIC                 0x1
>  #define SYNC_TO_VAPIC                   0x2
>  #define SYNC_ISR_IRR_TO_VAPIC           0x4
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:41:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFug-0005Xm-Bn; Thu, 14 Jun 2012 19:41:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SfFuf-0005XY-3m
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:41:01 +0000
Received: from [85.158.139.83:51519] by server-4.bemta-5.messagelabs.com id
	07/AC-27831-C4E3ADF4; Thu, 14 Jun 2012 19:41:00 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339702858!27664345!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8303 invoked from network); 14 Jun 2012 19:40:59 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 19:40:59 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5EJeu84003214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:40:56 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJernq030981; Thu, 14 Jun 2012 15:40:54 -0400
Date: Thu, 14 Jun 2012 22:41:30 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614194129.GG19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:40PM +0100, Anthony PERARD wrote:
> Hi all,
> 
> This patch series introduces the PCI passthrough for Xen.
> 
> Changes since the last version:
>   - New patch that introduce a new qdev-property pci-host-devaddr.
>   => the "export pci_parse_devaddr" patch is not anymore usefull.
> 
> Thanks,

I reviewed some patches and Acked. Won't have the time to
review the rest of the series short term.
If you need me to merge some of these patches myself
pls let me know.

> Allen Kay (2):
>   Introduce Xen PCI Passthrough, qdevice (1/3)
>   Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
> 
> Anthony PERARD (6):
>   pci_ids: Add INTEL_82599_SFP_VF id.
>   configure: Introduce --enable-xen-pci-passthrough.
>   Introduce XenHostPCIDevice to access a pci device on the host.
>   pci.c: Add opaque argument to pci_for_each_device.
>   qdev-properties: Introduce pci-host-devaddr.
>   Introduce apic-msidef.h
> 
> Jiang Yunhong (1):
>   Introduce Xen PCI Passthrough, MSI (3/3)
> 
>  configure                |   29 +
>  hw/apic-msidef.h         |   30 +
>  hw/apic.c                |   11 +-
>  hw/i386/Makefile.objs    |    2 +
>  hw/pci.c                 |   11 +-
>  hw/pci.h                 |    4 +-
>  hw/pci_ids.h             |    1 +
>  hw/qdev-properties.c     |  107 +++
>  hw/qdev.h                |    3 +
>  hw/xen-host-pci-device.c |  396 ++++++++++
>  hw/xen-host-pci-device.h |   55 ++
>  hw/xen_common.h          |    3 +
>  hw/xen_platform.c        |    8 +-
>  hw/xen_pt.c              |  851 +++++++++++++++++++++
>  hw/xen_pt.h              |  301 ++++++++
>  hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
>  hw/xen_pt_msi.c          |  620 +++++++++++++++
>  qemu-common.h            |    7 +
>  xen-all.c                |   12 +
>  19 files changed, 4301 insertions(+), 19 deletions(-)
>  create mode 100644 hw/apic-msidef.h
>  create mode 100644 hw/xen-host-pci-device.c
>  create mode 100644 hw/xen-host-pci-device.h
>  create mode 100644 hw/xen_pt.c
>  create mode 100644 hw/xen_pt.h
>  create mode 100644 hw/xen_pt_config_init.c
>  create mode 100644 hw/xen_pt_msi.c
> 
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 19:41:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 19: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 1SfFug-0005Xm-Bn; Thu, 14 Jun 2012 19:41:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1SfFuf-0005XY-3m
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 19:41:01 +0000
Received: from [85.158.139.83:51519] by server-4.bemta-5.messagelabs.com id
	07/AC-27831-C4E3ADF4; Thu, 14 Jun 2012 19:41:00 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339702858!27664345!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5Mjk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8303 invoked from network); 14 Jun 2012 19:40:59 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	14 Jun 2012 19:40:59 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5EJeu84003214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 15:40:56 -0400
Received: from redhat.com (vpn1-4-217.ams2.redhat.com [10.36.4.217])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q5EJernq030981; Thu, 14 Jun 2012 15:40:54 -0400
Date: Thu, 14 Jun 2012 22:41:30 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614194129.GG19807@redhat.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:40PM +0100, Anthony PERARD wrote:
> Hi all,
> 
> This patch series introduces the PCI passthrough for Xen.
> 
> Changes since the last version:
>   - New patch that introduce a new qdev-property pci-host-devaddr.
>   => the "export pci_parse_devaddr" patch is not anymore usefull.
> 
> Thanks,

I reviewed some patches and Acked. Won't have the time to
review the rest of the series short term.
If you need me to merge some of these patches myself
pls let me know.

> Allen Kay (2):
>   Introduce Xen PCI Passthrough, qdevice (1/3)
>   Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
> 
> Anthony PERARD (6):
>   pci_ids: Add INTEL_82599_SFP_VF id.
>   configure: Introduce --enable-xen-pci-passthrough.
>   Introduce XenHostPCIDevice to access a pci device on the host.
>   pci.c: Add opaque argument to pci_for_each_device.
>   qdev-properties: Introduce pci-host-devaddr.
>   Introduce apic-msidef.h
> 
> Jiang Yunhong (1):
>   Introduce Xen PCI Passthrough, MSI (3/3)
> 
>  configure                |   29 +
>  hw/apic-msidef.h         |   30 +
>  hw/apic.c                |   11 +-
>  hw/i386/Makefile.objs    |    2 +
>  hw/pci.c                 |   11 +-
>  hw/pci.h                 |    4 +-
>  hw/pci_ids.h             |    1 +
>  hw/qdev-properties.c     |  107 +++
>  hw/qdev.h                |    3 +
>  hw/xen-host-pci-device.c |  396 ++++++++++
>  hw/xen-host-pci-device.h |   55 ++
>  hw/xen_common.h          |    3 +
>  hw/xen_platform.c        |    8 +-
>  hw/xen_pt.c              |  851 +++++++++++++++++++++
>  hw/xen_pt.h              |  301 ++++++++
>  hw/xen_pt_config_init.c  | 1869 ++++++++++++++++++++++++++++++++++++++++++++++
>  hw/xen_pt_msi.c          |  620 +++++++++++++++
>  qemu-common.h            |    7 +
>  xen-all.c                |   12 +
>  19 files changed, 4301 insertions(+), 19 deletions(-)
>  create mode 100644 hw/apic-msidef.h
>  create mode 100644 hw/xen-host-pci-device.c
>  create mode 100644 hw/xen-host-pci-device.h
>  create mode 100644 hw/xen_pt.c
>  create mode 100644 hw/xen_pt.h
>  create mode 100644 hw/xen_pt_config_init.c
>  create mode 100644 hw/xen_pt_msi.c
> 
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:00:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20: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 1SfGDV-0005ym-4x; Thu, 14 Jun 2012 20:00:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SfGDT-0005yh-Ns
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:00:27 +0000
Received: from [85.158.139.83:30556] by server-9.bemta-5.messagelabs.com id
	AC/85-01069-AD24ADF4; Thu, 14 Jun 2012 20:00:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339704024!27735108!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5043 invoked from network); 14 Jun 2012 20:00:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:00:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EK0G44028998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:00:18 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
	q5EK0DLP025597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:00:14 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
	q5EK0CtW001809; Thu, 14 Jun 2012 15:00:12 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:00:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B36E040297; Thu, 14 Jun 2012 15:52:48 -0400 (EDT)
Date: Thu, 14 Jun 2012 15:52:48 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614195248.GA2175@phenom.dumpdata.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:41PM +0100, Anthony PERARD wrote:
> We are using this in our quirk lookup provided by patch
> titled: Introduce Xen PCI Passthrough, PCI config space helpers.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/pci_ids.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_ids.h b/hw/pci_ids.h
> index e8235a7..649e6b3 100644
> --- a/hw/pci_ids.h
> +++ b/hw/pci_ids.h
> @@ -118,6 +118,7 @@
>  #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
> +#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
>  
>  #define PCI_VENDOR_ID_XEN               0x5853
>  #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:00:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20: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 1SfGDV-0005ym-4x; Thu, 14 Jun 2012 20:00:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SfGDT-0005yh-Ns
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:00:27 +0000
Received: from [85.158.139.83:30556] by server-9.bemta-5.messagelabs.com id
	AC/85-01069-AD24ADF4; Thu, 14 Jun 2012 20:00:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1339704024!27735108!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5043 invoked from network); 14 Jun 2012 20:00:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:00:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EK0G44028998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:00:18 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
	q5EK0DLP025597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:00:14 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
	q5EK0CtW001809; Thu, 14 Jun 2012 15:00:12 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:00:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B36E040297; Thu, 14 Jun 2012 15:52:48 -0400 (EDT)
Date: Thu, 14 Jun 2012 15:52:48 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614195248.GA2175@phenom.dumpdata.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-2-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 1/9] pci_ids: Add INTEL_82599_SFP_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:41PM +0100, Anthony PERARD wrote:
> We are using this in our quirk lookup provided by patch
> titled: Introduce Xen PCI Passthrough, PCI config space helpers.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/pci_ids.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_ids.h b/hw/pci_ids.h
> index e8235a7..649e6b3 100644
> --- a/hw/pci_ids.h
> +++ b/hw/pci_ids.h
> @@ -118,6 +118,7 @@
>  #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
>  #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
> +#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
>  
>  #define PCI_VENDOR_ID_XEN               0x5853
>  #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:01:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20: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 1SfGEV-00062F-O4; Thu, 14 Jun 2012 20:01: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 1SfGEU-000625-K7
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:01:31 +0000
Received: from [193.109.254.147:33929] by server-4.bemta-14.messagelabs.com id
	B5/95-27598-9134ADF4; Thu, 14 Jun 2012 20:01:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339704087!8985422!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17734 invoked from network); 14 Jun 2012 20:01:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:01:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EK1MDr001883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:01:23 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
	q5EK1Lel000073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:01:21 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
	q5EK1KvT002648; Thu, 14 Jun 2012 15:01:20 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:01:20 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CE6F940297; Thu, 14 Jun 2012 15:53:56 -0400 (EDT)
Date: Thu, 14 Jun 2012 15:53:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614195356.GB2175@phenom.dumpdata.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 3/9] Introduce XenHostPCIDevice to
 access a pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:43PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/i386/Makefile.objs    |    1 +
>  hw/xen-host-pci-device.c |  396 ++++++++++++++++++++++++++++++++++++++++++++++
>  hw/xen-host-pci-device.h |   55 +++++++
>  3 files changed, 452 insertions(+), 0 deletions(-)
>  create mode 100644 hw/xen-host-pci-device.c
>  create mode 100644 hw/xen-host-pci-device.h
> 
> diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
> index d43f1df..b719d8e 100644
> --- a/hw/i386/Makefile.objs
> +++ b/hw/i386/Makefile.objs
> @@ -7,6 +7,7 @@ obj-y += debugcon.o multiboot.o
>  obj-y += pc_piix.o
>  obj-y += pc_sysfw.o
>  obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
> +obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>  obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
>  obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
>  
> diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
> new file mode 100644
> index 0000000..e7ff680
> --- /dev/null
> +++ b/hw/xen-host-pci-device.c
> @@ -0,0 +1,396 @@
> +/*
> + * Copyright (C) 2011       Citrix Ltd.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu-common.h"
> +#include "xen-host-pci-device.h"
> +
> +#define XEN_HOST_PCI_MAX_EXT_CAP \
> +    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
> +
> +#ifdef XEN_HOST_PCI_DEVICE_DEBUG
> +#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
> +#else
> +#  define XEN_HOST_PCI_LOG(f, a...) (void)0
> +#endif
> +
> +/*
> + * from linux/ioport.h
> + * IO resources have these defined flags.
> + */
> +#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
> +
> +#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
> +#define IORESOURCE_IO           0x00000100
> +#define IORESOURCE_MEM          0x00000200
> +
> +#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
> +#define IORESOURCE_MEM_64       0x00100000
> +
> +static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
> +                                   const char *name, char *buf, ssize_t size)
> +{
> +    int rc;
> +
> +    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
> +                  d->domain, d->bus, d->dev, d->func, name);
> +
> +    if (rc >= size || rc < 0) {
> +        /* The ouput is truncated or an other error is encountered */
> +        return -ENODEV;
> +    }
> +    return 0;
> +}
> +
> +
> +/* This size should be enough to read the first 7 lines of a ressource file */
> +#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
> +static int xen_host_pci_get_resource(XenHostPCIDevice *d)
> +{
> +    int i, rc, fd;
> +    char path[PATH_MAX];
> +    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
> +    unsigned long long start, end, flags, size;
> +    char *endptr, *s;
> +    uint8_t type;
> +
> +    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
> +    if (rc) {
> +        return rc;
> +    }
> +    fd = open(path, O_RDONLY);
> +    if (fd == -1) {
> +        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -errno;
> +    }
> +
> +    do {
> +        rc = read(fd, &buf, sizeof (buf) - 1);
> +        if (rc < 0 && errno != EINTR) {
> +            rc = -errno;
> +            goto out;
> +        }
> +    } while (rc < 0);
> +    buf[rc] = 0;
> +    rc = 0;
> +
> +    s = buf;
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        type = 0;
> +
> +        start = strtoll(s, &endptr, 16);
> +        if (*endptr != ' ' || s == endptr) {
> +            break;
> +        }
> +        s = endptr + 1;
> +        end = strtoll(s, &endptr, 16);
> +        if (*endptr != ' ' || s == endptr) {
> +            break;
> +        }
> +        s = endptr + 1;
> +        flags = strtoll(s, &endptr, 16);
> +        if (*endptr != '\n' || s == endptr) {
> +            break;
> +        }
> +        s = endptr + 1;
> +
> +        if (start) {
> +            size = end - start + 1;
> +        } else {
> +            size = 0;
> +        }
> +
> +        if (flags & IORESOURCE_IO) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_IO;
> +        }
> +        if (flags & IORESOURCE_MEM) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
> +        }
> +        if (flags & IORESOURCE_PREFETCH) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
> +        }
> +        if (flags & IORESOURCE_MEM_64) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
> +        }
> +
> +        if (i < PCI_ROM_SLOT) {
> +            d->io_regions[i].base_addr = start;
> +            d->io_regions[i].size = size;
> +            d->io_regions[i].type = type;
> +            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
> +        } else {
> +            d->rom.base_addr = start;
> +            d->rom.size = size;
> +            d->rom.type = type;
> +            d->rom.bus_flags = flags & IORESOURCE_BITS;
> +        }
> +    }
> +    if (i != PCI_NUM_REGIONS) {
> +        /* Invalid format or input to short */
> +        rc = -ENODEV;
> +    }
> +
> +out:
> +    close(fd);
> +    return rc;
> +}
> +
> +/* This size should be enough to read a long from a file */
> +#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 22
> +static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
> +                                  unsigned int *pvalue, int base)
> +{
> +    char path[PATH_MAX];
> +    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
> +    int fd, rc;
> +    unsigned long value;
> +    char *endptr;
> +
> +    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
> +    if (rc) {
> +        return rc;
> +    }
> +    fd = open(path, O_RDONLY);
> +    if (fd == -1) {
> +        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -errno;
> +    }
> +    do {
> +        rc = read(fd, &buf, sizeof (buf) - 1);
> +        if (rc < 0 && errno != EINTR) {
> +            rc = -errno;
> +            goto out;
> +        }
> +    } while (rc < 0);
> +    buf[rc] = 0;
> +    value = strtol(buf, &endptr, base);
> +    if (endptr == buf || *endptr != '\n') {
> +        rc = -1;
> +    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
> +        rc = -errno;
> +    } else {
> +        rc = 0;
> +        *pvalue = value;
> +    }
> +out:
> +    close(fd);
> +    return rc;
> +}
> +
> +static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
> +                                             const char *name,
> +                                             unsigned int *pvalue)
> +{
> +    return xen_host_pci_get_value(d, name, pvalue, 16);
> +}
> +
> +static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
> +                                             const char *name,
> +                                             unsigned int *pvalue)
> +{
> +    return xen_host_pci_get_value(d, name, pvalue, 10);
> +}
> +
> +static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
> +{
> +    char path[PATH_MAX];
> +    struct stat buf;
> +
> +    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
> +        return false;
> +    }
> +    return !stat(path, &buf);
> +}
> +
> +static int xen_host_pci_config_open(XenHostPCIDevice *d)
> +{
> +    char path[PATH_MAX];
> +    int rc;
> +
> +    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
> +    if (rc) {
> +        return rc;
> +    }
> +    d->config_fd = open(path, O_RDWR);
> +    if (d->config_fd < 0) {
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +static int xen_host_pci_config_read(XenHostPCIDevice *d,
> +                                    int pos, void *buf, int len)
> +{
> +    int rc;
> +
> +    do {
> +        rc = pread(d->config_fd, buf, len, pos);
> +    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> +    if (rc != len) {
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +static int xen_host_pci_config_write(XenHostPCIDevice *d,
> +                                     int pos, const void *buf, int len)
> +{
> +    int rc;
> +
> +    do {
> +        rc = pwrite(d->config_fd, buf, len, pos);
> +    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> +    if (rc != len) {
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +
> +int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
> +{
> +    uint8_t buf;
> +    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
> +    if (!rc) {
> +        *p = buf;
> +    }
> +    return rc;
> +}
> +
> +int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
> +{
> +    uint16_t buf;
> +    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
> +    if (!rc) {
> +        *p = le16_to_cpu(buf);
> +    }
> +    return rc;
> +}
> +
> +int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
> +{
> +    uint32_t buf;
> +    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
> +    if (!rc) {
> +        *p = le32_to_cpu(buf);
> +    }
> +    return rc;
> +}
> +
> +int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> +{
> +    return xen_host_pci_config_read(d, pos, buf, len);
> +}
> +
> +int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
> +{
> +    return xen_host_pci_config_write(d, pos, &data, 1);
> +}
> +
> +int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
> +{
> +    data = cpu_to_le16(data);
> +    return xen_host_pci_config_write(d, pos, &data, 2);
> +}
> +
> +int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
> +{
> +    data = cpu_to_le32(data);
> +    return xen_host_pci_config_write(d, pos, &data, 4);
> +}
> +
> +int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> +{
> +    return xen_host_pci_config_write(d, pos, buf, len);
> +}
> +
> +int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
> +{
> +    uint32_t header = 0;
> +    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
> +    int pos = PCI_CONFIG_SPACE_SIZE;
> +
> +    do {
> +        if (xen_host_pci_get_long(d, pos, &header)) {
> +            break;
> +        }
> +        /*
> +         * If we have no capabilities, this is indicated by cap ID,
> +         * cap version and next pointer all being 0.
> +         */
> +        if (header == 0) {
> +            break;
> +        }
> +
> +        if (PCI_EXT_CAP_ID(header) == cap) {
> +            return pos;
> +        }
> +
> +        pos = PCI_EXT_CAP_NEXT(header);
> +        if (pos < PCI_CONFIG_SPACE_SIZE) {
> +            break;
> +        }
> +
> +        max_cap--;
> +    } while (max_cap > 0);
> +
> +    return -1;
> +}
> +
> +int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
> +                            uint8_t bus, uint8_t dev, uint8_t func)
> +{
> +    unsigned int v;
> +    int rc = 0;
> +
> +    d->config_fd = -1;
> +    d->domain = domain;
> +    d->bus = bus;
> +    d->dev = dev;
> +    d->func = func;
> +
> +    rc = xen_host_pci_config_open(d);
> +    if (rc) {
> +        goto error;
> +    }
> +    rc = xen_host_pci_get_resource(d);
> +    if (rc) {
> +        goto error;
> +    }
> +    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->vendor_id = v;
> +    rc = xen_host_pci_get_hex_value(d, "device", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->device_id = v;
> +    rc = xen_host_pci_get_dec_value(d, "irq", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->irq = v;
> +    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
> +
> +    return 0;
> +error:
> +    if (d->config_fd >= 0) {
> +        close(d->config_fd);
> +        d->config_fd = -1;
> +    }
> +    return rc;
> +}
> +
> +void xen_host_pci_device_put(XenHostPCIDevice *d)
> +{
> +    if (d->config_fd >= 0) {
> +        close(d->config_fd);
> +        d->config_fd = -1;
> +    }
> +}
> diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
> new file mode 100644
> index 0000000..0079dac
> --- /dev/null
> +++ b/hw/xen-host-pci-device.h
> @@ -0,0 +1,55 @@
> +#ifndef XEN_HOST_PCI_DEVICE_H
> +#define XEN_HOST_PCI_DEVICE_H
> +
> +#include "pci.h"
> +
> +enum {
> +    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
> +    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
> +    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
> +    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
> +};
> +
> +typedef struct XenHostPCIIORegion {
> +    pcibus_t base_addr;
> +    pcibus_t size;
> +    uint8_t type;
> +    uint8_t bus_flags; /* Bus-specific bits */
> +} XenHostPCIIORegion;
> +
> +typedef struct XenHostPCIDevice {
> +    uint16_t domain;
> +    uint8_t bus;
> +    uint8_t dev;
> +    uint8_t func;
> +
> +    uint16_t vendor_id;
> +    uint16_t device_id;
> +    int irq;
> +
> +    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
> +    XenHostPCIIORegion rom;
> +
> +    bool is_virtfn;
> +
> +    int config_fd;
> +} XenHostPCIDevice;
> +
> +int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
> +                            uint8_t bus, uint8_t dev, uint8_t func);
> +void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
> +
> +int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
> +int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
> +int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
> +int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> +                           int len);
> +int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
> +int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
> +int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
> +int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> +                           int len);
> +
> +int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
> +
> +#endif /* !XEN_HOST_PCI_DEVICE_H_ */
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:01:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20: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 1SfGEV-00062F-O4; Thu, 14 Jun 2012 20:01: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 1SfGEU-000625-K7
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:01:31 +0000
Received: from [193.109.254.147:33929] by server-4.bemta-14.messagelabs.com id
	B5/95-27598-9134ADF4; Thu, 14 Jun 2012 20:01:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1339704087!8985422!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17734 invoked from network); 14 Jun 2012 20:01:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:01:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EK1MDr001883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:01:23 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
	q5EK1Lel000073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:01:21 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
	q5EK1KvT002648; Thu, 14 Jun 2012 15:01:20 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:01:20 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CE6F940297; Thu, 14 Jun 2012 15:53:56 -0400 (EDT)
Date: Thu, 14 Jun 2012 15:53:56 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614195356.GB2175@phenom.dumpdata.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 3/9] Introduce XenHostPCIDevice to
 access a pci device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:43PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/i386/Makefile.objs    |    1 +
>  hw/xen-host-pci-device.c |  396 ++++++++++++++++++++++++++++++++++++++++++++++
>  hw/xen-host-pci-device.h |   55 +++++++
>  3 files changed, 452 insertions(+), 0 deletions(-)
>  create mode 100644 hw/xen-host-pci-device.c
>  create mode 100644 hw/xen-host-pci-device.h
> 
> diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
> index d43f1df..b719d8e 100644
> --- a/hw/i386/Makefile.objs
> +++ b/hw/i386/Makefile.objs
> @@ -7,6 +7,7 @@ obj-y += debugcon.o multiboot.o
>  obj-y += pc_piix.o
>  obj-y += pc_sysfw.o
>  obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
> +obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>  obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
>  obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
>  
> diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
> new file mode 100644
> index 0000000..e7ff680
> --- /dev/null
> +++ b/hw/xen-host-pci-device.c
> @@ -0,0 +1,396 @@
> +/*
> + * Copyright (C) 2011       Citrix Ltd.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu-common.h"
> +#include "xen-host-pci-device.h"
> +
> +#define XEN_HOST_PCI_MAX_EXT_CAP \
> +    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
> +
> +#ifdef XEN_HOST_PCI_DEVICE_DEBUG
> +#  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
> +#else
> +#  define XEN_HOST_PCI_LOG(f, a...) (void)0
> +#endif
> +
> +/*
> + * from linux/ioport.h
> + * IO resources have these defined flags.
> + */
> +#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
> +
> +#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
> +#define IORESOURCE_IO           0x00000100
> +#define IORESOURCE_MEM          0x00000200
> +
> +#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
> +#define IORESOURCE_MEM_64       0x00100000
> +
> +static int xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
> +                                   const char *name, char *buf, ssize_t size)
> +{
> +    int rc;
> +
> +    rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
> +                  d->domain, d->bus, d->dev, d->func, name);
> +
> +    if (rc >= size || rc < 0) {
> +        /* The ouput is truncated or an other error is encountered */
> +        return -ENODEV;
> +    }
> +    return 0;
> +}
> +
> +
> +/* This size should be enough to read the first 7 lines of a ressource file */
> +#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
> +static int xen_host_pci_get_resource(XenHostPCIDevice *d)
> +{
> +    int i, rc, fd;
> +    char path[PATH_MAX];
> +    char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
> +    unsigned long long start, end, flags, size;
> +    char *endptr, *s;
> +    uint8_t type;
> +
> +    rc = xen_host_pci_sysfs_path(d, "resource", path, sizeof (path));
> +    if (rc) {
> +        return rc;
> +    }
> +    fd = open(path, O_RDONLY);
> +    if (fd == -1) {
> +        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -errno;
> +    }
> +
> +    do {
> +        rc = read(fd, &buf, sizeof (buf) - 1);
> +        if (rc < 0 && errno != EINTR) {
> +            rc = -errno;
> +            goto out;
> +        }
> +    } while (rc < 0);
> +    buf[rc] = 0;
> +    rc = 0;
> +
> +    s = buf;
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        type = 0;
> +
> +        start = strtoll(s, &endptr, 16);
> +        if (*endptr != ' ' || s == endptr) {
> +            break;
> +        }
> +        s = endptr + 1;
> +        end = strtoll(s, &endptr, 16);
> +        if (*endptr != ' ' || s == endptr) {
> +            break;
> +        }
> +        s = endptr + 1;
> +        flags = strtoll(s, &endptr, 16);
> +        if (*endptr != '\n' || s == endptr) {
> +            break;
> +        }
> +        s = endptr + 1;
> +
> +        if (start) {
> +            size = end - start + 1;
> +        } else {
> +            size = 0;
> +        }
> +
> +        if (flags & IORESOURCE_IO) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_IO;
> +        }
> +        if (flags & IORESOURCE_MEM) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_MEM;
> +        }
> +        if (flags & IORESOURCE_PREFETCH) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_PREFETCH;
> +        }
> +        if (flags & IORESOURCE_MEM_64) {
> +            type |= XEN_HOST_PCI_REGION_TYPE_MEM_64;
> +        }
> +
> +        if (i < PCI_ROM_SLOT) {
> +            d->io_regions[i].base_addr = start;
> +            d->io_regions[i].size = size;
> +            d->io_regions[i].type = type;
> +            d->io_regions[i].bus_flags = flags & IORESOURCE_BITS;
> +        } else {
> +            d->rom.base_addr = start;
> +            d->rom.size = size;
> +            d->rom.type = type;
> +            d->rom.bus_flags = flags & IORESOURCE_BITS;
> +        }
> +    }
> +    if (i != PCI_NUM_REGIONS) {
> +        /* Invalid format or input to short */
> +        rc = -ENODEV;
> +    }
> +
> +out:
> +    close(fd);
> +    return rc;
> +}
> +
> +/* This size should be enough to read a long from a file */
> +#define XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE 22
> +static int xen_host_pci_get_value(XenHostPCIDevice *d, const char *name,
> +                                  unsigned int *pvalue, int base)
> +{
> +    char path[PATH_MAX];
> +    char buf[XEN_HOST_PCI_GET_VALUE_BUFFER_SIZE];
> +    int fd, rc;
> +    unsigned long value;
> +    char *endptr;
> +
> +    rc = xen_host_pci_sysfs_path(d, name, path, sizeof (path));
> +    if (rc) {
> +        return rc;
> +    }
> +    fd = open(path, O_RDONLY);
> +    if (fd == -1) {
> +        XEN_HOST_PCI_LOG("Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -errno;
> +    }
> +    do {
> +        rc = read(fd, &buf, sizeof (buf) - 1);
> +        if (rc < 0 && errno != EINTR) {
> +            rc = -errno;
> +            goto out;
> +        }
> +    } while (rc < 0);
> +    buf[rc] = 0;
> +    value = strtol(buf, &endptr, base);
> +    if (endptr == buf || *endptr != '\n') {
> +        rc = -1;
> +    } else if ((value == LONG_MIN || value == LONG_MAX) && errno == ERANGE) {
> +        rc = -errno;
> +    } else {
> +        rc = 0;
> +        *pvalue = value;
> +    }
> +out:
> +    close(fd);
> +    return rc;
> +}
> +
> +static inline int xen_host_pci_get_hex_value(XenHostPCIDevice *d,
> +                                             const char *name,
> +                                             unsigned int *pvalue)
> +{
> +    return xen_host_pci_get_value(d, name, pvalue, 16);
> +}
> +
> +static inline int xen_host_pci_get_dec_value(XenHostPCIDevice *d,
> +                                             const char *name,
> +                                             unsigned int *pvalue)
> +{
> +    return xen_host_pci_get_value(d, name, pvalue, 10);
> +}
> +
> +static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
> +{
> +    char path[PATH_MAX];
> +    struct stat buf;
> +
> +    if (xen_host_pci_sysfs_path(d, "physfn", path, sizeof (path))) {
> +        return false;
> +    }
> +    return !stat(path, &buf);
> +}
> +
> +static int xen_host_pci_config_open(XenHostPCIDevice *d)
> +{
> +    char path[PATH_MAX];
> +    int rc;
> +
> +    rc = xen_host_pci_sysfs_path(d, "config", path, sizeof (path));
> +    if (rc) {
> +        return rc;
> +    }
> +    d->config_fd = open(path, O_RDWR);
> +    if (d->config_fd < 0) {
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +static int xen_host_pci_config_read(XenHostPCIDevice *d,
> +                                    int pos, void *buf, int len)
> +{
> +    int rc;
> +
> +    do {
> +        rc = pread(d->config_fd, buf, len, pos);
> +    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> +    if (rc != len) {
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +static int xen_host_pci_config_write(XenHostPCIDevice *d,
> +                                     int pos, const void *buf, int len)
> +{
> +    int rc;
> +
> +    do {
> +        rc = pwrite(d->config_fd, buf, len, pos);
> +    } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> +    if (rc != len) {
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +
> +int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p)
> +{
> +    uint8_t buf;
> +    int rc = xen_host_pci_config_read(d, pos, &buf, 1);
> +    if (!rc) {
> +        *p = buf;
> +    }
> +    return rc;
> +}
> +
> +int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p)
> +{
> +    uint16_t buf;
> +    int rc = xen_host_pci_config_read(d, pos, &buf, 2);
> +    if (!rc) {
> +        *p = le16_to_cpu(buf);
> +    }
> +    return rc;
> +}
> +
> +int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p)
> +{
> +    uint32_t buf;
> +    int rc = xen_host_pci_config_read(d, pos, &buf, 4);
> +    if (!rc) {
> +        *p = le32_to_cpu(buf);
> +    }
> +    return rc;
> +}
> +
> +int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> +{
> +    return xen_host_pci_config_read(d, pos, buf, len);
> +}
> +
> +int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data)
> +{
> +    return xen_host_pci_config_write(d, pos, &data, 1);
> +}
> +
> +int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data)
> +{
> +    data = cpu_to_le16(data);
> +    return xen_host_pci_config_write(d, pos, &data, 2);
> +}
> +
> +int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data)
> +{
> +    data = cpu_to_le32(data);
> +    return xen_host_pci_config_write(d, pos, &data, 4);
> +}
> +
> +int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> +{
> +    return xen_host_pci_config_write(d, pos, buf, len);
> +}
> +
> +int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
> +{
> +    uint32_t header = 0;
> +    int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
> +    int pos = PCI_CONFIG_SPACE_SIZE;
> +
> +    do {
> +        if (xen_host_pci_get_long(d, pos, &header)) {
> +            break;
> +        }
> +        /*
> +         * If we have no capabilities, this is indicated by cap ID,
> +         * cap version and next pointer all being 0.
> +         */
> +        if (header == 0) {
> +            break;
> +        }
> +
> +        if (PCI_EXT_CAP_ID(header) == cap) {
> +            return pos;
> +        }
> +
> +        pos = PCI_EXT_CAP_NEXT(header);
> +        if (pos < PCI_CONFIG_SPACE_SIZE) {
> +            break;
> +        }
> +
> +        max_cap--;
> +    } while (max_cap > 0);
> +
> +    return -1;
> +}
> +
> +int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
> +                            uint8_t bus, uint8_t dev, uint8_t func)
> +{
> +    unsigned int v;
> +    int rc = 0;
> +
> +    d->config_fd = -1;
> +    d->domain = domain;
> +    d->bus = bus;
> +    d->dev = dev;
> +    d->func = func;
> +
> +    rc = xen_host_pci_config_open(d);
> +    if (rc) {
> +        goto error;
> +    }
> +    rc = xen_host_pci_get_resource(d);
> +    if (rc) {
> +        goto error;
> +    }
> +    rc = xen_host_pci_get_hex_value(d, "vendor", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->vendor_id = v;
> +    rc = xen_host_pci_get_hex_value(d, "device", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->device_id = v;
> +    rc = xen_host_pci_get_dec_value(d, "irq", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->irq = v;
> +    d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
> +
> +    return 0;
> +error:
> +    if (d->config_fd >= 0) {
> +        close(d->config_fd);
> +        d->config_fd = -1;
> +    }
> +    return rc;
> +}
> +
> +void xen_host_pci_device_put(XenHostPCIDevice *d)
> +{
> +    if (d->config_fd >= 0) {
> +        close(d->config_fd);
> +        d->config_fd = -1;
> +    }
> +}
> diff --git a/hw/xen-host-pci-device.h b/hw/xen-host-pci-device.h
> new file mode 100644
> index 0000000..0079dac
> --- /dev/null
> +++ b/hw/xen-host-pci-device.h
> @@ -0,0 +1,55 @@
> +#ifndef XEN_HOST_PCI_DEVICE_H
> +#define XEN_HOST_PCI_DEVICE_H
> +
> +#include "pci.h"
> +
> +enum {
> +    XEN_HOST_PCI_REGION_TYPE_IO = 1 << 1,
> +    XEN_HOST_PCI_REGION_TYPE_MEM = 1 << 2,
> +    XEN_HOST_PCI_REGION_TYPE_PREFETCH = 1 << 3,
> +    XEN_HOST_PCI_REGION_TYPE_MEM_64 = 1 << 4,
> +};
> +
> +typedef struct XenHostPCIIORegion {
> +    pcibus_t base_addr;
> +    pcibus_t size;
> +    uint8_t type;
> +    uint8_t bus_flags; /* Bus-specific bits */
> +} XenHostPCIIORegion;
> +
> +typedef struct XenHostPCIDevice {
> +    uint16_t domain;
> +    uint8_t bus;
> +    uint8_t dev;
> +    uint8_t func;
> +
> +    uint16_t vendor_id;
> +    uint16_t device_id;
> +    int irq;
> +
> +    XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
> +    XenHostPCIIORegion rom;
> +
> +    bool is_virtfn;
> +
> +    int config_fd;
> +} XenHostPCIDevice;
> +
> +int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
> +                            uint8_t bus, uint8_t dev, uint8_t func);
> +void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
> +
> +int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
> +int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
> +int xen_host_pci_get_long(XenHostPCIDevice *d, int pos, uint32_t *p);
> +int xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> +                           int len);
> +int xen_host_pci_set_byte(XenHostPCIDevice *d, int pos, uint8_t data);
> +int xen_host_pci_set_word(XenHostPCIDevice *d, int pos, uint16_t data);
> +int xen_host_pci_set_long(XenHostPCIDevice *d, int pos, uint32_t data);
> +int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> +                           int len);
> +
> +int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *s, uint32_t cap);
> +
> +#endif /* !XEN_HOST_PCI_DEVICE_H_ */
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:02:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20: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 1SfGEv-00064J-5l; Thu, 14 Jun 2012 20:01:57 +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 1SfGEt-000645-J7
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:01:55 +0000
Received: from [85.158.138.51:38924] by server-8.bemta-3.messagelabs.com id
	28/3B-06157-2334ADF4; Thu, 14 Jun 2012 20:01:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339704112!27778707!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23686 invoked from network); 14 Jun 2012 20:01:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:01:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EK1kgP002186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:01:47 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
	q5EK1joj000892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:01:46 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
	q5EK1jBw019469; Thu, 14 Jun 2012 15:01:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:01:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9492040297; Thu, 14 Jun 2012 15:54:21 -0400 (EDT)
Date: Thu, 14 Jun 2012 15:54:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614195421.GC2175@phenom.dumpdata.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 4/9] pci.c: Add opaque argument to
 pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:44PM +0100, Anthony PERARD wrote:
> The purpose is to have a more generic pci_for_each_device by passing an extra
> argument to the function called on every device.
> 
> This patch will be used in a next patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/pci.c          |   11 +++++++----
>  hw/pci.h          |    4 +++-
>  hw/xen_platform.c |    8 ++++----
>  3 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 127b7ac..d6537e3 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
>  };
>  
>  static void pci_for_each_device_under_bus(PCIBus *bus,
> -                                          void (*fn)(PCIBus *b, PCIDevice *d))
> +                                          void (*fn)(PCIBus *b, PCIDevice *d,
> +                                                     void *opaque),
> +                                          void *opaque)
>  {
>      PCIDevice *d;
>      int devfn;
> @@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
>      for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
>          d = bus->devices[devfn];
>          if (d) {
> -            fn(bus, d);
> +            fn(bus, d, opaque);
>          }
>      }
>  }
>  
>  void pci_for_each_device(PCIBus *bus, int bus_num,
> -                         void (*fn)(PCIBus *b, PCIDevice *d))
> +                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
> +                         void *opaque)
>  {
>      bus = pci_find_bus_nr(bus, bus_num);
>  
>      if (bus) {
> -        pci_for_each_device_under_bus(bus, fn);
> +        pci_for_each_device_under_bus(bus, fn, opaque);
>      }
>  }
>  
> diff --git a/hw/pci.h b/hw/pci.h
> index 7f223c0..95b608c 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
>  PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
>                                 const char *default_devaddr);
>  int pci_bus_num(PCIBus *s);
> -void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
> +void pci_for_each_device(PCIBus *bus, int bus_num,
> +                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
> +                         void *opaque);
>  PCIBus *pci_find_root_bus(int domain);
>  int pci_find_domain(const PCIBus *bus);
>  PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0214f37..c1fe984 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
>  #define UNPLUG_ALL_NICS 2
>  #define UNPLUG_AUX_IDE_DISKS 4
>  
> -static void unplug_nic(PCIBus *b, PCIDevice *d)
> +static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_NETWORK_ETHERNET) {
> @@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_nics(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_nic);
> +    pci_for_each_device(bus, 0, unplug_nic, NULL);
>  }
>  
> -static void unplug_disks(PCIBus *b, PCIDevice *d)
> +static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_STORAGE_IDE) {
> @@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_disks(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_disks);
> +    pci_for_each_device(bus, 0, unplug_disks, NULL);
>  }
>  
>  static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:02:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20: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 1SfGEv-00064J-5l; Thu, 14 Jun 2012 20:01:57 +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 1SfGEt-000645-J7
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:01:55 +0000
Received: from [85.158.138.51:38924] by server-8.bemta-3.messagelabs.com id
	28/3B-06157-2334ADF4; Thu, 14 Jun 2012 20:01:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339704112!27778707!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MDU3NA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23686 invoked from network); 14 Jun 2012 20:01:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:01:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EK1kgP002186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:01:47 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
	q5EK1joj000892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:01:46 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
	q5EK1jBw019469; Thu, 14 Jun 2012 15:01:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:01:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9492040297; Thu, 14 Jun 2012 15:54:21 -0400 (EDT)
Date: Thu, 14 Jun 2012 15:54:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120614195421.GC2175@phenom.dumpdata.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1339693309-15192-5-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V13 4/9] pci.c: Add opaque argument to
 pci_for_each_device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 06:01:44PM +0100, Anthony PERARD wrote:
> The purpose is to have a more generic pci_for_each_device by passing an extra
> argument to the function called on every device.
> 
> This patch will be used in a next patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  hw/pci.c          |   11 +++++++----
>  hw/pci.h          |    4 +++-
>  hw/xen_platform.c |    8 ++++----
>  3 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 127b7ac..d6537e3 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1127,7 +1127,9 @@ static const pci_class_desc pci_class_descriptions[] =
>  };
>  
>  static void pci_for_each_device_under_bus(PCIBus *bus,
> -                                          void (*fn)(PCIBus *b, PCIDevice *d))
> +                                          void (*fn)(PCIBus *b, PCIDevice *d,
> +                                                     void *opaque),
> +                                          void *opaque)
>  {
>      PCIDevice *d;
>      int devfn;
> @@ -1135,18 +1137,19 @@ static void pci_for_each_device_under_bus(PCIBus *bus,
>      for(devfn = 0; devfn < ARRAY_SIZE(bus->devices); devfn++) {
>          d = bus->devices[devfn];
>          if (d) {
> -            fn(bus, d);
> +            fn(bus, d, opaque);
>          }
>      }
>  }
>  
>  void pci_for_each_device(PCIBus *bus, int bus_num,
> -                         void (*fn)(PCIBus *b, PCIDevice *d))
> +                         void (*fn)(PCIBus *b, PCIDevice *d, void *opaque),
> +                         void *opaque)
>  {
>      bus = pci_find_bus_nr(bus, bus_num);
>  
>      if (bus) {
> -        pci_for_each_device_under_bus(bus, fn);
> +        pci_for_each_device_under_bus(bus, fn, opaque);
>      }
>  }
>  
> diff --git a/hw/pci.h b/hw/pci.h
> index 7f223c0..95b608c 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -312,7 +312,9 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model,
>  PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model,
>                                 const char *default_devaddr);
>  int pci_bus_num(PCIBus *s);
> -void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d));
> +void pci_for_each_device(PCIBus *bus, int bus_num,
> +                         void (*fn)(PCIBus *bus, PCIDevice *d, void *opaque),
> +                         void *opaque);
>  PCIBus *pci_find_root_bus(int domain);
>  int pci_find_domain(const PCIBus *bus);
>  PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn);
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0214f37..c1fe984 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -83,7 +83,7 @@ static void log_writeb(PCIXenPlatformState *s, char val)
>  #define UNPLUG_ALL_NICS 2
>  #define UNPLUG_AUX_IDE_DISKS 4
>  
> -static void unplug_nic(PCIBus *b, PCIDevice *d)
> +static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_NETWORK_ETHERNET) {
> @@ -96,10 +96,10 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_nics(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_nic);
> +    pci_for_each_device(bus, 0, unplug_nic, NULL);
>  }
>  
> -static void unplug_disks(PCIBus *b, PCIDevice *d)
> +static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
>  {
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>              PCI_CLASS_STORAGE_IDE) {
> @@ -109,7 +109,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d)
>  
>  static void pci_unplug_disks(PCIBus *bus)
>  {
> -    pci_for_each_device(bus, 0, unplug_disks);
> +    pci_for_each_device(bus, 0, unplug_disks, NULL);
>  }
>  
>  static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfGiK-0006Wm-U1; Thu, 14 Jun 2012 20:32:20 +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 1SfGiJ-0006Wh-Bi
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 20:32:19 +0000
Received: from [85.158.143.99:11540] by server-2.bemta-4.messagelabs.com id
	A9/51-17938-25A4ADF4; Thu, 14 Jun 2012 20:32:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339705936!17658000!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg4Mzky\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15252 invoked from network); 14 Jun 2012 20:32:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:32:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EKWEbd031246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:32:15 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
	q5EKWDbL021619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:32:14 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
	q5EKWD0A006682; Thu, 14 Jun 2012 15:32:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:32:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9415640297; Thu, 14 Jun 2012 16:24:49 -0400 (EDT)
Date: Thu, 14 Jun 2012 16:24:49 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20120614202449.GA24693@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: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.5-rc2-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: 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 pull my tag:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.5-rc2-tag

which has accumulated some good bug-fixes. The tag itself has the description - which
I am copying here:

Five bug-fixes:
 - When booting as PVHVM we would try to use PV console - but would not validate
   the parameters causing us to crash during restore b/c we re-use the wrong event
   channel.
 - When booting on machines with SR-IOV PCI bridge we didn't check for the bridge
   and tried to use it.
 - Under AMD machines would advertise the APERFMPERF resulting in needless amount
   of MSRs from the guest.
 - A global value (xen_released_pages) was not subtracted at bootup when pages
   were added back in. This resulted in the balloon worker having the wrong
   account of how many pages were truly released.
 - Fix dead-lock when xen-blkfront is run in the same domain as xen-blkback.


Please pull!

Andre Przywara (1):
      xen/setup: filter APERFMPERF cpuid feature out

Konrad Rzeszutek Wilk (5):
      xen/hvc: Collapse error logic.
      xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN
      xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness.
      xen/events: Add WARN_ON when quick lookup found invalid type.
      xen/balloon: Subtract from xen_released_pages the count that is populated.

Stefano Stabellini (1):
      xen: mark local pages as FOREIGN in the m2p_override

Zhang, Yang Z (1):
      xen/pci: Check for PCI bridge before using it.

 arch/x86/xen/enlighten.c  |    8 ++++++++
 arch/x86/xen/p2m.c        |   36 ++++++++++++++++++++++++++++++++++++
 arch/x86/xen/setup.c      |    3 ++-
 drivers/tty/hvc/hvc_xen.c |   31 +++++++++++++++++--------------
 drivers/xen/events.c      |    9 +++++++++
 drivers/xen/pci.c         |    2 +-
 6 files changed, 73 insertions(+), 16 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfGiK-0006Wm-U1; Thu, 14 Jun 2012 20:32:20 +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 1SfGiJ-0006Wh-Bi
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 20:32:19 +0000
Received: from [85.158.143.99:11540] by server-2.bemta-4.messagelabs.com id
	A9/51-17938-25A4ADF4; Thu, 14 Jun 2012 20:32:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339705936!17658000!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg4Mzky\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15252 invoked from network); 14 Jun 2012 20:32:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:32:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5EKWEbd031246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Jun 2012 20:32:15 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
	q5EKWDbL021619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Jun 2012 20:32:14 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
	q5EKWD0A006682; Thu, 14 Jun 2012 15:32:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 13:32:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9415640297; Thu, 14 Jun 2012 16:24:49 -0400 (EDT)
Date: Thu, 14 Jun 2012 16:24:49 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20120614202449.GA24693@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: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.5-rc2-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: 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 pull my tag:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.5-rc2-tag

which has accumulated some good bug-fixes. The tag itself has the description - which
I am copying here:

Five bug-fixes:
 - When booting as PVHVM we would try to use PV console - but would not validate
   the parameters causing us to crash during restore b/c we re-use the wrong event
   channel.
 - When booting on machines with SR-IOV PCI bridge we didn't check for the bridge
   and tried to use it.
 - Under AMD machines would advertise the APERFMPERF resulting in needless amount
   of MSRs from the guest.
 - A global value (xen_released_pages) was not subtracted at bootup when pages
   were added back in. This resulted in the balloon worker having the wrong
   account of how many pages were truly released.
 - Fix dead-lock when xen-blkfront is run in the same domain as xen-blkback.


Please pull!

Andre Przywara (1):
      xen/setup: filter APERFMPERF cpuid feature out

Konrad Rzeszutek Wilk (5):
      xen/hvc: Collapse error logic.
      xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN
      xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness.
      xen/events: Add WARN_ON when quick lookup found invalid type.
      xen/balloon: Subtract from xen_released_pages the count that is populated.

Stefano Stabellini (1):
      xen: mark local pages as FOREIGN in the m2p_override

Zhang, Yang Z (1):
      xen/pci: Check for PCI bridge before using it.

 arch/x86/xen/enlighten.c  |    8 ++++++++
 arch/x86/xen/p2m.c        |   36 ++++++++++++++++++++++++++++++++++++
 arch/x86/xen/setup.c      |    3 ++-
 drivers/tty/hvc/hvc_xen.c |   31 +++++++++++++++++--------------
 drivers/xen/events.c      |    9 +++++++++
 drivers/xen/pci.c         |    2 +-
 6 files changed, 73 insertions(+), 16 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 20:44:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfGtm-0006k0-8w; Thu, 14 Jun 2012 20:44:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SfGtk-0006jv-89
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:44:08 +0000
Received: from [85.158.139.83:60111] by server-6.bemta-5.messagelabs.com id
	EB/10-11348-71D4ADF4; Thu, 14 Jun 2012 20:44:07 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339706645!27789453!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjE4MTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32761 invoked from network); 14 Jun 2012 20:44:06 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:44:06 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6344221980
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 16:44:05 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Thu, 14 Jun 2012 16:44:05 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=mesmtp; bh=FX4NR
	Jgli4CKEF/Ee7I4mjlLOVQ=; b=CmoMmKlkr1gxeWarJAvobmY01+5XmWlruljVF
	vK9Dye4elc/9e+H6KyByOejwX3CadIwoMS43Hl9T1h3I8B8UMf2X7KtS/U4TprED
	aa6wqTSqc9gVnValnNvQvnzbZrrLjZ8uRUYReV9Rbef+DD6oA3J/GPl46xm74OSW
	h7EBxI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=smtpout; bh=FX4N
	RJgli4CKEF/Ee7I4mjlLOVQ=; b=OzWtwjV/sLOblElJTT02lr+QL1mM095GaYdB
	0ZDy1SgeyM3f9/Q3n6aJpdS04YsyrBGVP4pITJpbBMHUIn1KKlexPiDCl7Ao/2+w
	aX777EigGaWTP/vdEkX3H1b7YGAWZmupn4SB+2ju3OHbWwf/fSOeW9sh/UuO5xMD
	loAKpU0=
X-Sasl-enc: k6uDeTAV/873eNJmP0E+0JVLbrBTEbha2FXYho1ITiGR 1339706645
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 03E948E020D
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 16:44:04 -0400 (EDT)
Message-ID: <4FD9D8A0.1060504@invisiblethingslab.com>
Date: Thu, 14 Jun 2012 14:27:12 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FD1F9E8.20508@invisiblethingslab.com>
In-Reply-To: <4FD1F9E8.20508@invisiblethingslab.com>
X-Enigmail-Version: 1.4.1
Subject: Re: [Xen-devel] block backend 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: multipart/mixed; boundary="===============2254790533967183525=="
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)
--===============2254790533967183525==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig5921C7AAF3C6B88F38892638"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5921C7AAF3C6B88F38892638
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 08.06.2012 15:11, Marek Marczykowski wrote:
> Hey,
>=20
> I've faced strange problem with block devices. When trying to read some=
 file
> (from read-only ext3), everything looks good, except that file content =
is
> corrupted! But this can be coincidence (that "failed" reads doesn't hit=

> filesystem metadata).
> fsck in dom0 on filesystem image returns no errors.
> fsck (with -nf flags) in domU on the device causes the kernel to output=

> "blkfront: flush disk cache: empty write xvdd op failed", "blkfront: xv=
dd:
> barrier or flush: disable". And returns no filesystem errors. From that=
 point,
> file reads return correct file content. For most cases dropping block c=
ache
> (echo 3 > /proc/sys/vm/drop_caches) or remounting device also "fixes" t=
he problem.
>=20
> On RW device (with different size, filesystem and content), domU kernel=

> complains about EXT4 errors.
> Doesn't observed such strange issues on device-mapper backed devices.
>=20
> On 3.2.7 it worked, problem observed on 3.3.5 and 3.4 in dom0, regardle=
ss of
> domU kernel (tried 3.2.7, 3.3.5, 3.4.0).
>=20
> I've suspected feature-flush-cache/feature-barrier, but when disabled i=
ts
> advertise in blkback code, problem still occurs.
>=20
> Some details:
> dom0: 3.4.0-1.pvops.qubes.x86_64 (vanilla 3.4 + Konrad's patches for AC=
PI S3)
> domU: 3.3.5-1.pvops.qubes.x86_64 (vanilla 3.3.5 + Konrad's patches for =
ACPI S3)

(...)
Still the case on 3.4.1 with applied patches from Konrad's for-jens-3.5 b=
ranch.
I've compared file contents and it differs in (multiply of) 1024 bytes - =
the
same as filesystem block size. And only if block wasn't in pagecache in d=
om0.
When I flush VM pagecache (echo 1 > /proc/.../drop_caches) after trying t=
o
read some files (actually md5sum -c), but not dom0 pagecache - problem
vanished. But if I clean also dom0 pagecache - problem returns.

Any clues welcomed...

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig5921C7AAF3C6B88F38892638
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP2dihAAoJENuP0xzK19csfaoH/0Ml1lyBHNoYMbwdtXhNgvfE
VccjdwSj4hlNSLuv1nO+lma9LgPh2cgkKhKKj//Exie3ijHJnCxqpkezWTnmYvh9
fu5GzAyrp3k+lV8e62fenOQ2nGWoEQWERlu7iDRj/RL+rmzAzpbiUpGpciANyFXB
z6lzd12/1ciV8JZcKgeY4nOCR49kJic6NnfVusDGqia9VLn+l5ej3aoM231wzJwg
yVnXWM+ysXKZeEe33QciRdKyhWWkDXGxTen+rbpTdFz5M529DCjn/RSAM6lh6bBF
QBCaUkw6u6ve0fGx+FGuuP3ZoA7MweVaZb6rBizIj+JID1ZwHl4DiyhomffXsM4=
=0N32
-----END PGP SIGNATURE-----

--------------enig5921C7AAF3C6B88F38892638--


--===============2254790533967183525==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2254790533967183525==--


From xen-devel-bounces@lists.xen.org Thu Jun 14 20:44:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 20:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfGtm-0006k0-8w; Thu, 14 Jun 2012 20:44:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SfGtk-0006jv-89
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:44:08 +0000
Received: from [85.158.139.83:60111] by server-6.bemta-5.messagelabs.com id
	EB/10-11348-71D4ADF4; Thu, 14 Jun 2012 20:44:07 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339706645!27789453!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjE4MTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32761 invoked from network); 14 Jun 2012 20:44:06 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jun 2012 20:44:06 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6344221980
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 16:44:05 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Thu, 14 Jun 2012 16:44:05 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=mesmtp; bh=FX4NR
	Jgli4CKEF/Ee7I4mjlLOVQ=; b=CmoMmKlkr1gxeWarJAvobmY01+5XmWlruljVF
	vK9Dye4elc/9e+H6KyByOejwX3CadIwoMS43Hl9T1h3I8B8UMf2X7KtS/U4TprED
	aa6wqTSqc9gVnValnNvQvnzbZrrLjZ8uRUYReV9Rbef+DD6oA3J/GPl46xm74OSW
	h7EBxI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=smtpout; bh=FX4N
	RJgli4CKEF/Ee7I4mjlLOVQ=; b=OzWtwjV/sLOblElJTT02lr+QL1mM095GaYdB
	0ZDy1SgeyM3f9/Q3n6aJpdS04YsyrBGVP4pITJpbBMHUIn1KKlexPiDCl7Ao/2+w
	aX777EigGaWTP/vdEkX3H1b7YGAWZmupn4SB+2ju3OHbWwf/fSOeW9sh/UuO5xMD
	loAKpU0=
X-Sasl-enc: k6uDeTAV/873eNJmP0E+0JVLbrBTEbha2FXYho1ITiGR 1339706645
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 03E948E020D
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 16:44:04 -0400 (EDT)
Message-ID: <4FD9D8A0.1060504@invisiblethingslab.com>
Date: Thu, 14 Jun 2012 14:27:12 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FD1F9E8.20508@invisiblethingslab.com>
In-Reply-To: <4FD1F9E8.20508@invisiblethingslab.com>
X-Enigmail-Version: 1.4.1
Subject: Re: [Xen-devel] block backend 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: multipart/mixed; boundary="===============2254790533967183525=="
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)
--===============2254790533967183525==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig5921C7AAF3C6B88F38892638"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5921C7AAF3C6B88F38892638
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 08.06.2012 15:11, Marek Marczykowski wrote:
> Hey,
>=20
> I've faced strange problem with block devices. When trying to read some=
 file
> (from read-only ext3), everything looks good, except that file content =
is
> corrupted! But this can be coincidence (that "failed" reads doesn't hit=

> filesystem metadata).
> fsck in dom0 on filesystem image returns no errors.
> fsck (with -nf flags) in domU on the device causes the kernel to output=

> "blkfront: flush disk cache: empty write xvdd op failed", "blkfront: xv=
dd:
> barrier or flush: disable". And returns no filesystem errors. From that=
 point,
> file reads return correct file content. For most cases dropping block c=
ache
> (echo 3 > /proc/sys/vm/drop_caches) or remounting device also "fixes" t=
he problem.
>=20
> On RW device (with different size, filesystem and content), domU kernel=

> complains about EXT4 errors.
> Doesn't observed such strange issues on device-mapper backed devices.
>=20
> On 3.2.7 it worked, problem observed on 3.3.5 and 3.4 in dom0, regardle=
ss of
> domU kernel (tried 3.2.7, 3.3.5, 3.4.0).
>=20
> I've suspected feature-flush-cache/feature-barrier, but when disabled i=
ts
> advertise in blkback code, problem still occurs.
>=20
> Some details:
> dom0: 3.4.0-1.pvops.qubes.x86_64 (vanilla 3.4 + Konrad's patches for AC=
PI S3)
> domU: 3.3.5-1.pvops.qubes.x86_64 (vanilla 3.3.5 + Konrad's patches for =
ACPI S3)

(...)
Still the case on 3.4.1 with applied patches from Konrad's for-jens-3.5 b=
ranch.
I've compared file contents and it differs in (multiply of) 1024 bytes - =
the
same as filesystem block size. And only if block wasn't in pagecache in d=
om0.
When I flush VM pagecache (echo 1 > /proc/.../drop_caches) after trying t=
o
read some files (actually md5sum -c), but not dom0 pagecache - problem
vanished. But if I clean also dom0 pagecache - problem returns.

Any clues welcomed...

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig5921C7AAF3C6B88F38892638
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP2dihAAoJENuP0xzK19csfaoH/0Ml1lyBHNoYMbwdtXhNgvfE
VccjdwSj4hlNSLuv1nO+lma9LgPh2cgkKhKKj//Exie3ijHJnCxqpkezWTnmYvh9
fu5GzAyrp3k+lV8e62fenOQ2nGWoEQWERlu7iDRj/RL+rmzAzpbiUpGpciANyFXB
z6lzd12/1ciV8JZcKgeY4nOCR49kJic6NnfVusDGqia9VLn+l5ej3aoM231wzJwg
yVnXWM+ysXKZeEe33QciRdKyhWWkDXGxTen+rbpTdFz5M529DCjn/RSAM6lh6bBF
QBCaUkw6u6ve0fGx+FGuuP3ZoA7MweVaZb6rBizIj+JID1ZwHl4DiyhomffXsM4=
=0N32
-----END PGP SIGNATURE-----

--------------enig5921C7AAF3C6B88F38892638--


--===============2254790533967183525==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2254790533967183525==--


From xen-devel-bounces@lists.xen.org Thu Jun 14 21:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 21: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 1SfHNP-00072n-29; Thu, 14 Jun 2012 21:14:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SfHNM-00072i-Uq
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 21:14:45 +0000
Received: from [193.109.254.147:62878] by server-5.bemta-14.messagelabs.com id
	D2/5C-31398-4445ADF4; Thu, 14 Jun 2012 21:14:44 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339708482!9828844!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6322 invoked from network); 14 Jun 2012 21:14:43 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 21:14:43 -0000
Received: by qcsc20 with SMTP id c20so1564879qcs.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 14:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=PooDa+aPCmtUWTS6cKVKgQKN9BsD8LwnZPrmARAQp5M=;
	b=IYI/nm1LzuJ/bmlHuTshRSOKTlz48K/zbKlUxlVpsI8icVQymPqH1Edc/TJhVj4S/n
	folfmN5xKQY3isZg6EYg5sQ5LBBaUDYJx7SkSBiyjX5ZRoJCu5RC2LVZVrjKfgpn6emX
	6SvfoNsv3vol0ngk+iAGpUU/zw6Au/ywekzourbnB0t2IAvD4FaUPe1rFmy91cnnK7Zi
	By8KEAAUB1I7ULUye4a6Idqv4s+b+gsiz+z0KqL3K2PC34QhNjl5YNqrS525wGh6PZt8
	kgcSgcVd39+xa3jNriJ0ir61aMZ4WnhRm3Qw4Rmoz7hnkbVxsGN0L2akKCEfl3TsrpJN
	McAw==
Received: by 10.229.106.226 with SMTP id y34mr1756892qco.70.1339708482080;
	Thu, 14 Jun 2012 14:14:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.100.71 with HTTP; Thu, 14 Jun 2012 14:14:21 -0700 (PDT)
In-Reply-To: <20120614153556.GI90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 14 Jun 2012 22:14:21 +0100
Message-ID: <CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
>> On 14/06 03:56, Tim Deegan wrote:
>> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
>> > > Are you talking about having different version of V4V driver running
>> > > in the same VM?
>> >
>> > Yes.
>> >
>> > > I don't think that is a problem they both interact with Xen via
>> > > hypercall directly so if they follow the v4v hypercall interface it's
>> > > all fine.
>> >
>> > AFAICS if they both try to register the same port then one of them will
>> > silently get its ring discarded. =A0And if they both try to communicate
>> > with the same remote port their entries on the pending lists will get
>> > merged (which is probably not too bad). =A0I think the possibility for
>> > confusion depends on how you use the service. =A0Still, it seems better
>> > than the xenstore case, anyway. :)
>> >
>>
>> Not silently, register_ring will return an error.
>
> Will it? =A0It looks to me like v4v_ring_add just clobbers the old MFN
> list.
>

Ha yes. It does that now but I think it should return an error
informing up the stack that a ring has already been registered.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 21:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 21: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 1SfHNP-00072n-29; Thu, 14 Jun 2012 21:14:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SfHNM-00072i-Uq
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 21:14:45 +0000
Received: from [193.109.254.147:62878] by server-5.bemta-14.messagelabs.com id
	D2/5C-31398-4445ADF4; Thu, 14 Jun 2012 21:14:44 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1339708482!9828844!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6322 invoked from network); 14 Jun 2012 21:14:43 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 21:14:43 -0000
Received: by qcsc20 with SMTP id c20so1564879qcs.32
	for <xen-devel@lists.xen.org>; Thu, 14 Jun 2012 14:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=PooDa+aPCmtUWTS6cKVKgQKN9BsD8LwnZPrmARAQp5M=;
	b=IYI/nm1LzuJ/bmlHuTshRSOKTlz48K/zbKlUxlVpsI8icVQymPqH1Edc/TJhVj4S/n
	folfmN5xKQY3isZg6EYg5sQ5LBBaUDYJx7SkSBiyjX5ZRoJCu5RC2LVZVrjKfgpn6emX
	6SvfoNsv3vol0ngk+iAGpUU/zw6Au/ywekzourbnB0t2IAvD4FaUPe1rFmy91cnnK7Zi
	By8KEAAUB1I7ULUye4a6Idqv4s+b+gsiz+z0KqL3K2PC34QhNjl5YNqrS525wGh6PZt8
	kgcSgcVd39+xa3jNriJ0ir61aMZ4WnhRm3Qw4Rmoz7hnkbVxsGN0L2akKCEfl3TsrpJN
	McAw==
Received: by 10.229.106.226 with SMTP id y34mr1756892qco.70.1339708482080;
	Thu, 14 Jun 2012 14:14:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.100.71 with HTTP; Thu, 14 Jun 2012 14:14:21 -0700 (PDT)
In-Reply-To: <20120614153556.GI90181@ocelot.phlegethon.org>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338558477.17466.121.camel@zakaz.uk.xensource.com>
	<20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 14 Jun 2012 22:14:21 +0100
Message-ID: <CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
>> On 14/06 03:56, Tim Deegan wrote:
>> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
>> > > Are you talking about having different version of V4V driver running
>> > > in the same VM?
>> >
>> > Yes.
>> >
>> > > I don't think that is a problem they both interact with Xen via
>> > > hypercall directly so if they follow the v4v hypercall interface it's
>> > > all fine.
>> >
>> > AFAICS if they both try to register the same port then one of them will
>> > silently get its ring discarded. =A0And if they both try to communicate
>> > with the same remote port their entries on the pending lists will get
>> > merged (which is probably not too bad). =A0I think the possibility for
>> > confusion depends on how you use the service. =A0Still, it seems better
>> > than the xenstore case, anyway. :)
>> >
>>
>> Not silently, register_ring will return an error.
>
> Will it? =A0It looks to me like v4v_ring_add just clobbers the old MFN
> list.
>

Ha yes. It does that now but I think it should return an error
informing up the stack that a ring has already been registered.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 21:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 21:20: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 1SfHSF-0007Af-Pj; Thu, 14 Jun 2012 21:19:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfHSE-0007AW-FL
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 21:19:46 +0000
Received: from [85.158.143.99:28046] by server-2.bemta-4.messagelabs.com id
	A3/97-17938-1755ADF4; Thu, 14 Jun 2012 21:19:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339708784!21046757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10113 invoked from network); 14 Jun 2012 21:19:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 21:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,773,1330905600"; d="scan'208";a="13032439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 21:19:44 +0000
Received: from boiler.cam.xci-test.com (10.80.248.209) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 22:19:44 +0100
Received: from jeangu by boiler.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>)	id 1SfHSC-00020B-8c;
	Thu, 14 Jun 2012 22:19:44 +0100
Date: Thu, 14 Jun 2012 22:19:44 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614211943.GC27011@boiler.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
	<4FDA26A8020000780008A100@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FDA26A8020000780008A100@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06 05:00, Jan Beulich wrote:
> >>> On 14.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
> > Here are the structs:
> > 
> > typedef struct v4v_ring_data_ent                                             
> > {                                                                            
> >     struct v4v_addr ring;                                                    
> >     uint16_t flags;                                                          
> >     uint16_t pad0;                                                           
> >     uint32_t space_required;                                                 
> >     uint32_t max_message_size;                                               
> > } v4v_ring_data_ent_t;                                                       
> > DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                               
> >                                                                              
> > typedef struct v4v_ring_data                                                 
> > {                                                                            
> >     uint64_t magic;                                                          
> >     uint32_t nent;                                                           
> >     uint32_t padding;                                                        
> >     uint64_t reserved[4];                                                    
> >     v4v_ring_data_ent_t ring[0];                                             
> > } v4v_ring_data_t;                                                           
> > DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> > 
> > I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I 
> > would like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.
> > 
> > Here is the code that I use for doing that (with explicte cast in 
> > guest_handle_cast):
> >     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
> >     XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> >         guest_handle_cast (ring_data_hnd, uint8_t);
> >     guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
> >     ring_data_ent_hnd =
> >         guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
> >     ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);
> 
> So you really don't want to add anything (as not being type-safe),
> but instead want to get a guest handle representation for accessing
> the ring[0] member. That is, I'd introduce a guest_handle_for_field()
> for this purpose. Let me see whether I can put something together
> for you early next week.
> 

Thanks but I'll follow Tim's advice and get rid of the wrapper
structure. I still think having some macro to get a handle from
a field can be quite useful in general.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 14 21:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Jun 2012 21:20: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 1SfHSF-0007Af-Pj; Thu, 14 Jun 2012 21:19:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SfHSE-0007AW-FL
	for xen-devel@lists.xen.org; Thu, 14 Jun 2012 21:19:46 +0000
Received: from [85.158.143.99:28046] by server-2.bemta-4.messagelabs.com id
	A3/97-17938-1755ADF4; Thu, 14 Jun 2012 21:19:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1339708784!21046757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI4MjE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10113 invoked from network); 14 Jun 2012 21:19:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 21:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,773,1330905600"; d="scan'208";a="13032439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jun 2012 21:19:44 +0000
Received: from boiler.cam.xci-test.com (10.80.248.209) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 14 Jun 2012 22:19:44 +0100
Received: from jeangu by boiler.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>)	id 1SfHSC-00020B-8c;
	Thu, 14 Jun 2012 22:19:44 +0100
Date: Thu, 14 Jun 2012 22:19:44 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120614211943.GC27011@boiler.cam.xci-test.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
	<4FDA26A8020000780008A100@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FDA26A8020000780008A100@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06 05:00, Jan Beulich wrote:
> >>> On 14.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
> > Here are the structs:
> > 
> > typedef struct v4v_ring_data_ent                                             
> > {                                                                            
> >     struct v4v_addr ring;                                                    
> >     uint16_t flags;                                                          
> >     uint16_t pad0;                                                           
> >     uint32_t space_required;                                                 
> >     uint32_t max_message_size;                                               
> > } v4v_ring_data_ent_t;                                                       
> > DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                               
> >                                                                              
> > typedef struct v4v_ring_data                                                 
> > {                                                                            
> >     uint64_t magic;                                                          
> >     uint32_t nent;                                                           
> >     uint32_t padding;                                                        
> >     uint64_t reserved[4];                                                    
> >     v4v_ring_data_ent_t ring[0];                                             
> > } v4v_ring_data_t;                                                           
> > DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> > 
> > I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I 
> > would like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.
> > 
> > Here is the code that I use for doing that (with explicte cast in 
> > guest_handle_cast):
> >     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
> >     XEN_GUEST_HANDLE (uint8_t) slop_hnd =
> >         guest_handle_cast (ring_data_hnd, uint8_t);
> >     guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
> >     ring_data_ent_hnd =
> >         guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
> >     ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);
> 
> So you really don't want to add anything (as not being type-safe),
> but instead want to get a guest handle representation for accessing
> the ring[0] member. That is, I'd introduce a guest_handle_for_field()
> for this purpose. Let me see whether I can put something together
> for you early next week.
> 

Thanks but I'll follow Tim's advice and get rid of the wrapper
structure. I still think having some macro to get a handle from
a field can be quite useful in general.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 01:44:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 01: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 1SfLZp-0005QI-DJ; Fri, 15 Jun 2012 01:43:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SfLZn-0005QD-Mo
	for Xen-devel@lists.xensource.com; Fri, 15 Jun 2012 01:43:51 +0000
Received: from [85.158.138.51:54688] by server-7.bemta-3.messagelabs.com id
	3F/8B-10113-6539ADF4; Fri, 15 Jun 2012 01:43:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339724628!19663153!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg5NjIw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10191 invoked from network); 15 Jun 2012 01:43:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 01:43:50 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5F1hg8I013041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 01:43:42 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
	q5F1hfDP008737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Jun 2012 01:43:41 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q5F1hfPT027032; Thu, 14 Jun 2012 20:43:41 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 18:43:41 -0700
Date: Thu, 14 Jun 2012 18:43:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120614184338.43fb879b@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 guys,

During my refresh to latest linux, I noticed, direct mapping of all
non-RAM pages in xen_set_identity_and_release(). I currently don't map
all at front, but as needed looking at the PAGE_IO bit in the pte. One
result of that is minor change to common code macro:

        __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)


To avoid this change, and keep all my changes limited to xen files only,
I thought I could just map the entire non-ram pages up front too. But
I am concerned the EPT may grow too large? Specially, when we get to 
*really* large NUMA boxes. What do you guys think? Should I worry about
it?

thanks
Mukesh

E820 on my small box:
Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000bf30cfff] usable
Xen: [mem 0x00000000bf30d000-0x00000000bf38cfff] ACPI NVS
Xen: [mem 0x00000000bf38d000-0x00000000bf3a2fff] reserved
Xen: [mem 0x00000000bf3a3000-0x00000000bf3a3fff] ACPI NVS
Xen: [mem 0x00000000bf3a4000-0x00000000bf3b4fff] reserved
Xen: [mem 0x00000000bf3b5000-0x00000000bf3b7fff] ACPI NVS
Xen: [mem 0x00000000bf3b8000-0x00000000bf3defff] reserved
Xen: [mem 0x00000000bf3df000-0x00000000bf3dffff] usable
Xen: [mem 0x00000000bf3e0000-0x00000000bf3e0fff] ACPI NVS
Xen: [mem 0x00000000bf3e1000-0x00000000bf415fff] reserved
Xen: [mem 0x00000000bf416000-0x00000000bf41ffff] ACPI data
Xen: [mem 0x00000000bf420000-0x00000000bf420fff] ACPI NVS
Xen: [mem 0x00000000bf421000-0x00000000bf422fff] ACPI data
Xen: [mem 0x00000000bf423000-0x00000000bf42afff] ACPI NVS
Xen: [mem 0x00000000bf42b000-0x00000000bf453fff] reserved
Xen: [mem 0x00000000bf454000-0x00000000bf656fff] ACPI NVS
Xen: [mem 0x00000000bf657000-0x00000000bf7fffff] usable
Xen: [mem 0x00000000c0000000-0x00000000cfffffff] reserved
Xen: [mem 0x00000000fec00000-0x00000000fec02fff] reserved
Xen: [mem 0x00000000fec90000-0x00000000fec90fff] reserved
Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Xen: [mem 0x0000000100000000-0x00000002bfffffff] usable



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 01:44:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 01: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 1SfLZp-0005QI-DJ; Fri, 15 Jun 2012 01:43:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1SfLZn-0005QD-Mo
	for Xen-devel@lists.xensource.com; Fri, 15 Jun 2012 01:43:51 +0000
Received: from [85.158.138.51:54688] by server-7.bemta-3.messagelabs.com id
	3F/8B-10113-6539ADF4; Fri, 15 Jun 2012 01:43:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1339724628!19663153!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTg5NjIw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10191 invoked from network); 15 Jun 2012 01:43:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 01:43:50 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5F1hg8I013041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 01:43:42 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
	q5F1hfDP008737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Jun 2012 01:43:41 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q5F1hfPT027032; Thu, 14 Jun 2012 20:43:41 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Jun 2012 18:43:41 -0700
Date: Thu, 14 Jun 2012 18:43:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120614184338.43fb879b@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 guys,

During my refresh to latest linux, I noticed, direct mapping of all
non-RAM pages in xen_set_identity_and_release(). I currently don't map
all at front, but as needed looking at the PAGE_IO bit in the pte. One
result of that is minor change to common code macro:

        __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)


To avoid this change, and keep all my changes limited to xen files only,
I thought I could just map the entire non-ram pages up front too. But
I am concerned the EPT may grow too large? Specially, when we get to 
*really* large NUMA boxes. What do you guys think? Should I worry about
it?

thanks
Mukesh

E820 on my small box:
Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000bf30cfff] usable
Xen: [mem 0x00000000bf30d000-0x00000000bf38cfff] ACPI NVS
Xen: [mem 0x00000000bf38d000-0x00000000bf3a2fff] reserved
Xen: [mem 0x00000000bf3a3000-0x00000000bf3a3fff] ACPI NVS
Xen: [mem 0x00000000bf3a4000-0x00000000bf3b4fff] reserved
Xen: [mem 0x00000000bf3b5000-0x00000000bf3b7fff] ACPI NVS
Xen: [mem 0x00000000bf3b8000-0x00000000bf3defff] reserved
Xen: [mem 0x00000000bf3df000-0x00000000bf3dffff] usable
Xen: [mem 0x00000000bf3e0000-0x00000000bf3e0fff] ACPI NVS
Xen: [mem 0x00000000bf3e1000-0x00000000bf415fff] reserved
Xen: [mem 0x00000000bf416000-0x00000000bf41ffff] ACPI data
Xen: [mem 0x00000000bf420000-0x00000000bf420fff] ACPI NVS
Xen: [mem 0x00000000bf421000-0x00000000bf422fff] ACPI data
Xen: [mem 0x00000000bf423000-0x00000000bf42afff] ACPI NVS
Xen: [mem 0x00000000bf42b000-0x00000000bf453fff] reserved
Xen: [mem 0x00000000bf454000-0x00000000bf656fff] ACPI NVS
Xen: [mem 0x00000000bf657000-0x00000000bf7fffff] usable
Xen: [mem 0x00000000c0000000-0x00000000cfffffff] reserved
Xen: [mem 0x00000000fec00000-0x00000000fec02fff] reserved
Xen: [mem 0x00000000fec90000-0x00000000fec90fff] reserved
Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Xen: [mem 0x0000000100000000-0x00000002bfffffff] usable



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 07:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 07:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfQlE-0007jT-2m; Fri, 15 Jun 2012 07:16:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1SfQlC-0007jO-2x
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 07:15:58 +0000
Received: from [193.109.254.147:44996] by server-12.bemta-14.messagelabs.com
	id DB/D1-12998-D21EADF4; Fri, 15 Jun 2012 07:15:57 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339744554!3000105!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15099 invoked from network); 15 Jun 2012 07:15:55 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 07:15:55 -0000
Received: by ggnp1 with SMTP id p1so2393662ggn.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 00:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=8K5DUn+QiUqPWAfmjA+6qb69mRN9d1kclhnCep0ezMg=;
	b=nxcQRodLnTIsw+55Jx1kqz/4EUah5ilpOuExAvhq13ebVOwCbfhmrKARW5sy+Ru7Es
	rc3dLlmKiS7PtgBhDMGdXoaJ8D/ctVITtmN4pN1BVcBBQTlKPiGvFgH4QEvrBwUZOK2P
	B13kcexQ6xel2e5S+2Mmz60jhhg+StcB7qjFvv28ypvfLXlfk//YHdd9TCgMidV6WJ+5
	SK8hVrrCCSxhvKWdRZ8FQ+Uc1th0jKGyvu5AOmKBGXaaAVHyXG9E7JDpTftLucfqtOpt
	DBzUZ87I0OXK9KAK8AaRpJXWpgUU6LXgnWE3mFsLa5RvGlEyOSIubdNe6uUsOGw+gJo2
	zoig==
MIME-Version: 1.0
Received: by 10.60.29.137 with SMTP id k9mr4776064oeh.23.1339744554164; Fri,
	15 Jun 2012 00:15:54 -0700 (PDT)
Received: by 10.182.53.65 with HTTP; Fri, 15 Jun 2012 00:15:54 -0700 (PDT)
In-Reply-To: <20120614095816.GF82539@ocelot.phlegethon.org>
References: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
	<20120614095816.GF82539@ocelot.phlegethon.org>
Date: Fri, 15 Jun 2012 15:15:54 +0800
Message-ID: <CAP=GMUHOrzSpRiU52P45vs0FcRcEBAcwSsNVA-TXj0JMq=Z7TA@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen dire-map 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/6/14 Tim Deegan <tim@xen.org>:
> At 17:30 +0800 on 14 Jun (1339695001), Baozeng wrote:
>> Hell all,
>>
>> I am doing some research work on protecting Xen's data structures.
>> I know there is a direct-map area(about 12M), in which we can get =A0the
>> physical address of the data structure from its virtual address. =A0My
>> question is : are the stack and the heap of Xen both located in this
>> direct-map area?
>
> On 32-bit x86, anything allocated with alloc_xenheap_* or xmalloc() is
> in that area (and that includes Xen's stacks). =A0Anything allocated with
> alloc_domheap_* is not. =A0Also the frametable and M2P are mapped
> separately. =A0The details are in include/asm-x86/config.h.
>
I see. I want to monitor Xen's data structures in a trusted VM(dom0).
One challenge is how to make dom0 can read Xen's data structure (just
read, do not need to write). Since Xen has more privilege, dom0 cannot
read its data directly.  Can we set up appropriate hypervisor-page
tables for dom0 that map Xen's relevant physical (or virtual) memory
areas? How to do that? Do we need modify Xen's code? or just the
dom0's code?
> Cheers,
>
> Tim.



-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 07:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 07:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfQlE-0007jT-2m; Fri, 15 Jun 2012 07:16:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1SfQlC-0007jO-2x
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 07:15:58 +0000
Received: from [193.109.254.147:44996] by server-12.bemta-14.messagelabs.com
	id DB/D1-12998-D21EADF4; Fri, 15 Jun 2012 07:15:57 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1339744554!3000105!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15099 invoked from network); 15 Jun 2012 07:15:55 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 07:15:55 -0000
Received: by ggnp1 with SMTP id p1so2393662ggn.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 00:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=8K5DUn+QiUqPWAfmjA+6qb69mRN9d1kclhnCep0ezMg=;
	b=nxcQRodLnTIsw+55Jx1kqz/4EUah5ilpOuExAvhq13ebVOwCbfhmrKARW5sy+Ru7Es
	rc3dLlmKiS7PtgBhDMGdXoaJ8D/ctVITtmN4pN1BVcBBQTlKPiGvFgH4QEvrBwUZOK2P
	B13kcexQ6xel2e5S+2Mmz60jhhg+StcB7qjFvv28ypvfLXlfk//YHdd9TCgMidV6WJ+5
	SK8hVrrCCSxhvKWdRZ8FQ+Uc1th0jKGyvu5AOmKBGXaaAVHyXG9E7JDpTftLucfqtOpt
	DBzUZ87I0OXK9KAK8AaRpJXWpgUU6LXgnWE3mFsLa5RvGlEyOSIubdNe6uUsOGw+gJo2
	zoig==
MIME-Version: 1.0
Received: by 10.60.29.137 with SMTP id k9mr4776064oeh.23.1339744554164; Fri,
	15 Jun 2012 00:15:54 -0700 (PDT)
Received: by 10.182.53.65 with HTTP; Fri, 15 Jun 2012 00:15:54 -0700 (PDT)
In-Reply-To: <20120614095816.GF82539@ocelot.phlegethon.org>
References: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
	<20120614095816.GF82539@ocelot.phlegethon.org>
Date: Fri, 15 Jun 2012 15:15:54 +0800
Message-ID: <CAP=GMUHOrzSpRiU52P45vs0FcRcEBAcwSsNVA-TXj0JMq=Z7TA@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen dire-map 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/6/14 Tim Deegan <tim@xen.org>:
> At 17:30 +0800 on 14 Jun (1339695001), Baozeng wrote:
>> Hell all,
>>
>> I am doing some research work on protecting Xen's data structures.
>> I know there is a direct-map area(about 12M), in which we can get =A0the
>> physical address of the data structure from its virtual address. =A0My
>> question is : are the stack and the heap of Xen both located in this
>> direct-map area?
>
> On 32-bit x86, anything allocated with alloc_xenheap_* or xmalloc() is
> in that area (and that includes Xen's stacks). =A0Anything allocated with
> alloc_domheap_* is not. =A0Also the frametable and M2P are mapped
> separately. =A0The details are in include/asm-x86/config.h.
>
I see. I want to monitor Xen's data structures in a trusted VM(dom0).
One challenge is how to make dom0 can read Xen's data structure (just
read, do not need to write). Since Xen has more privilege, dom0 cannot
read its data directly.  Can we set up appropriate hypervisor-page
tables for dom0 that map Xen's relevant physical (or virtual) memory
areas? How to do that? Do we need modify Xen's code? or just the
dom0's code?
> Cheers,
>
> Tim.



-- =

=A0=A0=A0=A0 Best Regards,
=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0=A0 Baozeng Ding
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSTG,NFS,ISCAS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 07:37:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 07:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfR5T-0007uM-2f; Fri, 15 Jun 2012 07:36:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SfR5S-0007uH-0B
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 07:36:54 +0000
Received: from [85.158.143.99:9151] by server-1.bemta-4.messagelabs.com id
	82/F9-24392-516EADF4; Fri, 15 Jun 2012 07:36:53 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339745810!16277579!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3348 invoked from network); 15 Jun 2012 07:36:52 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 07:36:52 -0000
Received: by obfk16 with SMTP id k16so5253606obf.30
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Jun 2012 00:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=r6VX3ksx4b14lb53aS/czZz3deDmkNINGbwDTxGlT90=;
	b=yvov8t/zaAwU6KkgZ+7Vc6zXGmNbUkg8wJ44+OW1InF3vXtNsfUT5G69mF8qPyl3eA
	TWakJlo6+XjpSRbKAMtHu1xio/hX8g0aLChASDTJYlMfQxg1E2/rWpq6WlMy4aQuZ0SK
	+RfOThGuZ7n7YHkxOjZH/52UQfmKO7UfzQSfnjpqsRMdbhuGbiAEV9AjkLPjVOSvtm7M
	Gq0Z4f6ZlYDzBFPdSnfRvH//yIePmno5o9j/4n0LMPEASaN6ULDaAstWxcx5uMlL3Tdg
	yDCFUP4Ab0JlvbWDXeuF7USvh6UmW7iwQrgbA0NCzVE0Xyqc6Is1OJ6dL9u+ecWA1sJI
	gHiA==
MIME-Version: 1.0
Received: by 10.182.13.74 with SMTP id f10mr4754420obc.36.1339745810415; Fri,
	15 Jun 2012 00:36:50 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Fri, 15 Jun 2012 00:36:50 -0700 (PDT)
In-Reply-To: <4FD9EC4B.7090808@tiscali.it>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
	<4FD85F83.3080207@tiscali.it>
	<CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
	<4FD9EC4B.7090808@tiscali.it>
Date: Fri, 15 Jun 2012 15:36:50 +0800
Message-ID: <CAAh7U5NRSbWxcZJ=Gr30aKN3T0KuvpdYYOKA3UYQMxkA8P5Usw@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: fantonifabio@tiscali.it
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 9:51 PM, Fabio Fantoni <fantonifabio@tiscali.it> wr=
ote:
> Il 13/06/2012 13:40, ZhouPeng ha scritto:
>
> On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni <fantonifabio@tiscali.it>
> wrote:
>
> Il 13/06/2012 11:02, ZhouPeng ha scritto:
>
> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.it>
>
> =A0wrote:
>
> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>
> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> =A0 =A0wrote:
>
> On Thu, 24 May 2012, ZhouPeng wrote:
>
> Sorry for late reply, I am not on this mail these days because of my
> work.
>
> I further test qxl-vga and I think I figure out the problem in some
>
> extend.
>
> If using qxl device, the default memory size of vga is 64M.
> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>
> The exact reason is xc_domain_populate_physmap_exact fails, because
>
> xen-hypervisor
> fail,
> it's because of =A0 alloc_domheap_pages(d, a->extent_order, a->memflags)
> fails in hypervisor.
>
> I am not very familiar with xen's memory management, Does 64M exceed
> xen's heap space in this context?
>
> XL sets an upper bound of memory that can be allocated to the VM in
> libxl__build_pre, calling xc_domain_setmaxmem.
> My guess is that a 64MB allocation would go over that limit.
> You could try increasing the limit manually changing the
> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
> videoram=3D64 in the VM config file.
>
> Your guess is absolutely right!
>
> But set videoram=3D128 or
> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>
> Then I successfuly install qxl driver in win-hvm and QXL can work
> properly.
>
> I will send some patch to add qxl support to libxl.
>
> I tried your 3 patches taken from the mailing list, it works but doesn't
> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
> doesn't
> start and on windows 7 I have heavy performance problem (unusable).
>
> Could you find qxl vga card =A0(named "Red Hat QXL GPU") in your
> windows hvm's device manager to make sure your qxl is working?
>
> My testing hvm-guest is Win XP.
>
> I played "Harry Potter" in my LAN smoothly, qxl gives
> great enhancement .
>
> Although I don't test win7 and linux, I think it should work for them.
>
> I tried also with qemu 1.1.0 but nothing change.
>
> I am not sure qemu 1.1.0 accept all the patches for xen.
>
> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git
>
> It is build and installed by default, you should enable spice support.
> spice can be enabled like below:
>
> +++ b/tools/Makefile =A0 =A0Sat May 26 12:31:01 2012 +0800
> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
> =A0 =A0 =A0 =A0 --bindir=3D$(LIBEXEC) \
> =A0 =A0 =A0 =A0 --datadir=3D$(SHAREDIR)/qemu-xen \
> =A0 =A0 =A0 =A0 --disable-kvm \
> + =A0 =A0 =A0 --enable-spice \
>
> Does it work correctly for you? If so can I have some detail of your
> configurations please?
>
> My vm.cfg:
>
> name =3D 'xpPro_spice'
> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
> builder =3D 'hvm'
> memory =3D '1024'
> device_model_version =3D 'qemu-xen'
> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:97=
:CB:0E:7D']
> sdl=3D0
> vnc=3D0
> vncviewer=3D0
> serial =3D 'pty'
> vcpus=3D1
> usbdevice=3D'tablet'
> #spice
> spice=3D1
> qxl=3D1
> #qxlram=3D64
> #qxlvram=3D64
> spiceport=3D6000
> spicehost=3D'192.168.1.187'
> spicedisable_ticketing =3D 1
> spiceagent_mouse =3D 0 # (1|0)
>
> For audio support this is needed too: (tested and working)
> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu
> invocation and env QEMU_AUDIO_DRV=3Dspice
> Can you add audio support on libxl please?
>
> I think audio support can be considered after qxl accpted.
>
> Thanks for reply, qxl driver is installed, windows see qxl video card,
> already compiled qemu with spice with patch I send months ago, already tr=
ied
> git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
> Unfortunately the results are always the same.
> Here a quick recording:
> Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv
>
> oh...  it shows spice+qxl running on Xen get
> significant performance reduction compared with KVM ...
>
> Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
> Are not new but the result of the last test is the same.
> I hope I can help you understand the problem.
> If you need more information ask.
>
> We are trying to reproduce your results but failed so far.

>From your video spiceqxldebug1.mkv, I think you have reproduced it with win=
7?
And your mouse interaction in win7 shows performance is significantly
reduced compared
with qxl on kvm greatly. How about view a video from remote spice client?

On my WinXP testing, the mouse interaction is better than
your win7 test (but not as good as in kvm too), and I view a movie(Harry Po=
tter)
from remote spice client (spice client on winxp), it's smooth.

Any way, qxl improve the performance, but it is not as good as running
on kvm from my
experence (no quantitative test). I don't know the reason yet. I just
guess it should
exist in qemu-xen or hypervisor.

I think you have reproduced.

My environment is simple, use the default.
---------------------
hg clone http://xenbits.xen.org/xen-unstable.hg

Dom0 kernel: (You can get it by KERNELS ?=3D linux-2.6-pvops in Linux.mk
automatically)
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
select a branch, I select xen/master (version 2.6.32.36):
$ git branch
  master
* xen/master

qemu (build by default)

git://xenbits.xen.org/qemu-upstream-unstable.git
$ git branch
* dummy
  master

+++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
        --bindir=3D$(LIBEXEC) \
        --datadir=3D$(SHAREDIR)/qemu-xen \
        --disable-kvm \
+       --enable-spice \

SPICE 0.7.1 is build from source code before.

Host is fc8-64bit, but dom0 kernel is replaced as described before.

> Can you give me details about the dom0 used for your tests please?
> For example here are details about my testing dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.18-1, package blktap-dkms and all dependency packages for xen 4.2, sp=
ice
> and usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=3D64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg
> vi config/StdGNU.mk # Workaround for Wheezy with multiarch support, there
> are parts that use LIBDIR set here instead of the one in configure (libdi=
r)
> LIBLEAFDIR_x86_64 ?=3D lib
> vi Config.mk
> PYTHON_PREFIX_ARG =3D
> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> - libxc: do not "panic" if a kernel is not a bzImage.
> - tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommo=
ns
> start
> - 3 patches for add qxl support
>
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
>
> Is qxl someway affected by physical video card of dom0?

I don't think so, because mainly rendered by client but not host.
> Have you installed spice-guest-tools-0.1.exe from spice site, if no what =
do
> you use for qxl driver?

spice-guest-tools-0.1.exe
> Have you also installed gplpv driver or not?

No.

No driver installed except from spice-guest-tools-0.1.exe.
> Thanks for any reply.

-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 07:37:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 07:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfR5T-0007uM-2f; Fri, 15 Jun 2012 07:36:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SfR5S-0007uH-0B
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 07:36:54 +0000
Received: from [85.158.143.99:9151] by server-1.bemta-4.messagelabs.com id
	82/F9-24392-516EADF4; Fri, 15 Jun 2012 07:36:53 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339745810!16277579!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3348 invoked from network); 15 Jun 2012 07:36:52 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 07:36:52 -0000
Received: by obfk16 with SMTP id k16so5253606obf.30
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Jun 2012 00:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=r6VX3ksx4b14lb53aS/czZz3deDmkNINGbwDTxGlT90=;
	b=yvov8t/zaAwU6KkgZ+7Vc6zXGmNbUkg8wJ44+OW1InF3vXtNsfUT5G69mF8qPyl3eA
	TWakJlo6+XjpSRbKAMtHu1xio/hX8g0aLChASDTJYlMfQxg1E2/rWpq6WlMy4aQuZ0SK
	+RfOThGuZ7n7YHkxOjZH/52UQfmKO7UfzQSfnjpqsRMdbhuGbiAEV9AjkLPjVOSvtm7M
	Gq0Z4f6ZlYDzBFPdSnfRvH//yIePmno5o9j/4n0LMPEASaN6ULDaAstWxcx5uMlL3Tdg
	yDCFUP4Ab0JlvbWDXeuF7USvh6UmW7iwQrgbA0NCzVE0Xyqc6Is1OJ6dL9u+ecWA1sJI
	gHiA==
MIME-Version: 1.0
Received: by 10.182.13.74 with SMTP id f10mr4754420obc.36.1339745810415; Fri,
	15 Jun 2012 00:36:50 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Fri, 15 Jun 2012 00:36:50 -0700 (PDT)
In-Reply-To: <4FD9EC4B.7090808@tiscali.it>
References: <1335453835300-5667919.post@n5.nabble.com>
	<1335946863612-5679908.post@n5.nabble.com>
	<CAAh7U5PTDDmebJaNwNvcDr86hWdnJ-=5j0gYAN1Q9hAL=mrfkA@mail.gmail.com>
	<alpine.DEB.2.00.1205031343410.26786@kaball-desktop>
	<CAAh7U5PB5AeniU38J2f_bWPUOkdiyCJYnxNb4+nJPUV1iQ=czg@mail.gmail.com>
	<alpine.DEB.2.00.1205031404550.26786@kaball-desktop>
	<CAAh7U5MD-whxLu7YoCx7LQgP3wH8Un3mstC9210959nP781U8w@mail.gmail.com>
	<alpine.DEB.2.00.1205031456120.26786@kaball-desktop>
	<CAAh7U5Mh24DcQAH2ae4Z3_u39es-Nv8E02A8m3nxT1U1pv9Bwg@mail.gmail.com>
	<1336120233.26385.10.camel@dagon.hellion.org.uk>
	<CAAh7U5NMuzk77mHw936p+hGiH9=84Ouq8_Y-6dizZNbT9yUp-Q@mail.gmail.com>
	<alpine.DEB.2.00.1205241108560.26786@kaball-desktop>
	<CAAh7U5O3HMmRbUVEY1iUUt3wvU=a1ZyoAC5vzYg5su9+Y_ALwg@mail.gmail.com>
	<4FD5DCF7.2070103@tiscali.it>
	<CAAh7U5P-cdS0C+oVnCkY_QgS1n1Qxb56u9dgQCbpE4oS0ZnBsg@mail.gmail.com>
	<4FD85F83.3080207@tiscali.it>
	<CAAh7U5MmDkGdyNF2V5XAJ4C48nkiH_aA0Zv50GO9RSwW1VKOJg@mail.gmail.com>
	<4FD9EC4B.7090808@tiscali.it>
Date: Fri, 15 Jun 2012 15:36:50 +0800
Message-ID: <CAAh7U5NRSbWxcZJ=Gr30aKN3T0KuvpdYYOKA3UYQMxkA8P5Usw@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: fantonifabio@tiscali.it
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Unable to get QXL vga working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 9:51 PM, Fabio Fantoni <fantonifabio@tiscali.it> wr=
ote:
> Il 13/06/2012 13:40, ZhouPeng ha scritto:
>
> On Wed, Jun 13, 2012 at 5:38 PM, Fabio Fantoni <fantonifabio@tiscali.it>
> wrote:
>
> Il 13/06/2012 11:02, ZhouPeng ha scritto:
>
> On Mon, Jun 11, 2012 at 7:56 PM, Fabio Fantoni<fantonifabio@tiscali.it>
>
> =A0wrote:
>
> Il 24/05/2012 13:28, ZhouPeng ha scritto:
>
> On Thu, May 24, 2012 at 6:13 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> =A0 =A0wrote:
>
> On Thu, 24 May 2012, ZhouPeng wrote:
>
> Sorry for late reply, I am not on this mail these days because of my
> work.
>
> I further test qxl-vga and I think I figure out the problem in some
>
> extend.
>
> If using qxl device, the default memory size of vga is 64M.
> Which will cause xen_ram_alloc(qemu/xen-all.c) fails.
>
> The exact reason is xc_domain_populate_physmap_exact fails, because
>
> xen-hypervisor
> fail,
> it's because of =A0 alloc_domheap_pages(d, a->extent_order, a->memflags)
> fails in hypervisor.
>
> I am not very familiar with xen's memory management, Does 64M exceed
> xen's heap space in this context?
>
> XL sets an upper bound of memory that can be allocated to the VM in
> libxl__build_pre, calling xc_domain_setmaxmem.
> My guess is that a 64MB allocation would go over that limit.
> You could try increasing the limit manually changing the
> xc_domain_setmaxmem call in libxl__build_pre, or you could try setting
> videoram=3D64 in the VM config file.
>
> Your guess is absolutely right!
>
> But set videoram=3D128 or
> xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT + 2 * 64 * 1024);
>
> Then I successfuly install qxl driver in win-hvm and QXL can work
> properly.
>
> I will send some patch to add qxl support to libxl.
>
> I tried your 3 patches taken from the mailing list, it works but doesn't
> solve qxl problems for me, on linux domU (Precise and Wheezy) xorg
> doesn't
> start and on windows 7 I have heavy performance problem (unusable).
>
> Could you find qxl vga card =A0(named "Red Hat QXL GPU") in your
> windows hvm's device manager to make sure your qxl is working?
>
> My testing hvm-guest is Win XP.
>
> I played "Harry Potter" in my LAN smoothly, qxl gives
> great enhancement .
>
> Although I don't test win7 and linux, I think it should work for them.
>
> I tried also with qemu 1.1.0 but nothing change.
>
> I am not sure qemu 1.1.0 accept all the patches for xen.
>
> Could you have a try of git://xenbits.xen.org/qemu-upstream-unstable.git
>
> It is build and installed by default, you should enable spice support.
> spice can be enabled like below:
>
> +++ b/tools/Makefile =A0 =A0Sat May 26 12:31:01 2012 +0800
> @@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
> =A0 =A0 =A0 =A0 --bindir=3D$(LIBEXEC) \
> =A0 =A0 =A0 =A0 --datadir=3D$(SHAREDIR)/qemu-xen \
> =A0 =A0 =A0 =A0 --disable-kvm \
> + =A0 =A0 =A0 --enable-spice \
>
> Does it work correctly for you? If so can I have some detail of your
> configurations please?
>
> My vm.cfg:
>
> name =3D 'xpPro_spice'
> firmware_override =3D '/usr/lib/xen/boot/hvmloader'
> builder =3D 'hvm'
> memory =3D '1024'
> device_model_version =3D 'qemu-xen'
> device_model_override =3D '/usr/lib/xen/bin/qemu-system-i386'
> disk =3D [ 'file:/path-to-img/xpPro.img,ioemu:hda,w' ]
> vif =3D ['ip=3D192.168.1.112, type=3Dioemu, bridge=3Deth0, mac=3D00:21:97=
:CB:0E:7D']
> sdl=3D0
> vnc=3D0
> vncviewer=3D0
> serial =3D 'pty'
> vcpus=3D1
> usbdevice=3D'tablet'
> #spice
> spice=3D1
> qxl=3D1
> #qxlram=3D64
> #qxlvram=3D64
> spiceport=3D6000
> spicehost=3D'192.168.1.187'
> spicedisable_ticketing =3D 1
> spiceagent_mouse =3D 0 # (1|0)
>
> For audio support this is needed too: (tested and working)
> -device intel-hda,id=3Dsound0 -device hda-duplex,id=3Dsound0-codec0 on qe=
mu
> invocation and env QEMU_AUDIO_DRV=3Dspice
> Can you add audio support on libxl please?
>
> I think audio support can be considered after qxl accpted.
>
> Thanks for reply, qxl driver is installed, windows see qxl video card,
> already compiled qemu with spice with patch I send months ago, already tr=
ied
> git://xenbits.xen.org/qemu-upstream-unstable.git before 1.1.
> Unfortunately the results are always the same.
> Here a quick recording:
> Windows 7 test: http://fantu.it/vari/spiceqxldebug1.mkv
>
> oh...  it shows spice+qxl running on Xen get
> significant performance reduction compared with KVM ...
>
> Debian wheezy test: http://fantu.it/vari/spiceqxldebug2.mkv
> Are not new but the result of the last test is the same.
> I hope I can help you understand the problem.
> If you need more information ask.
>
> We are trying to reproduce your results but failed so far.

>From your video spiceqxldebug1.mkv, I think you have reproduced it with win=
7?
And your mouse interaction in win7 shows performance is significantly
reduced compared
with qxl on kvm greatly. How about view a video from remote spice client?

On my WinXP testing, the mouse interaction is better than
your win7 test (but not as good as in kvm too), and I view a movie(Harry Po=
tter)
from remote spice client (spice client on winxp), it's smooth.

Any way, qxl improve the performance, but it is not as good as running
on kvm from my
experence (no quantitative test). I don't know the reason yet. I just
guess it should
exist in qemu-xen or hypervisor.

I think you have reproduced.

My environment is simple, use the default.
---------------------
hg clone http://xenbits.xen.org/xen-unstable.hg

Dom0 kernel: (You can get it by KERNELS ?=3D linux-2.6-pvops in Linux.mk
automatically)
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
select a branch, I select xen/master (version 2.6.32.36):
$ git branch
  master
* xen/master

qemu (build by default)

git://xenbits.xen.org/qemu-upstream-unstable.git
$ git branch
* dummy
  master

+++ b/tools/Makefile    Sat May 26 12:31:01 2012 +0800
@@ -157,6 +157,7 @@ subdir-all-qemu-xen-dir subdir-install-q
        --bindir=3D$(LIBEXEC) \
        --datadir=3D$(SHAREDIR)/qemu-xen \
        --disable-kvm \
+       --enable-spice \

SPICE 0.7.1 is build from source code before.

Host is fc8-64bit, but dom0 kernel is replaced as described before.

> Can you give me details about the dom0 used for your tests please?
> For example here are details about my testing dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.18-1, package blktap-dkms and all dependency packages for xen 4.2, sp=
ice
> and usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=3D64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg
> vi config/StdGNU.mk # Workaround for Wheezy with multiarch support, there
> are parts that use LIBDIR set here instead of the one in configure (libdi=
r)
> LIBLEAFDIR_x86_64 ?=3D lib
> vi Config.mk
> PYTHON_PREFIX_ARG =3D
> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> - libxc: do not "panic" if a kernel is not a bzImage.
> - tools/hotplug/Linux/init.d/: added other xen kernel modules on xencommo=
ns
> start
> - 3 patches for add qxl support
>
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
>
> Is qxl someway affected by physical video card of dom0?

I don't think so, because mainly rendered by client but not host.
> Have you installed spice-guest-tools-0.1.exe from spice site, if no what =
do
> you use for qxl driver?

spice-guest-tools-0.1.exe
> Have you also installed gplpv driver or not?

No.

No driver installed except from spice-guest-tools-0.1.exe.
> Thanks for any reply.

-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 09:42:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 09: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 1SfT1x-0000RO-OO; Fri, 15 Jun 2012 09:41:25 +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 1SfT1w-0000RJ-4l
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 09:41:24 +0000
Received: from [85.158.143.99:57829] by server-3.bemta-4.messagelabs.com id
	F9/D3-05808-3430BDF4; Fri, 15 Jun 2012 09:41:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339753281!20470501!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30577 invoked from network); 15 Jun 2012 09:41:22 -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;
	15 Jun 2012 09:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="28195337"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 05:41:21 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 15 Jun 2012
	05:41:21 -0400
Message-ID: <4FDB033F.8050703@citrix.com>
Date: Fri, 15 Jun 2012 10:41:19 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<1339582845-25659-2-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1339582845-25659-2-git-send-email-david.vrabel@citrix.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"H. Peter Anvin" <hpa@zytor.com>, "x86@kernel.org" <x86@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
 ptep_get_and_clear() 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 13/06/12 11:20, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> x86 provides a ptep_get_and_clear() function instead of using the
> generic implementation so it can atomically get and clear the PTE.
> 
> It is not clear why x86 has this requirement.  PTE updates are done
> while the appropriate PTE lock are held, so presumably, it is an
> attempt to ensure that the accessed and dirty bits of the PTE are
> saved even if they have been updated by the hardware due to a
> concurrent access on another CPU.
> 
> However, the atomic exchange is not sufficient for saving the dirty
> bit as if there is a TLB entry for this page on another CPU then the
> dirty bit may be written by that processor after the PTE is cleared
> but before the TLB entry is flushed.  It is also not clear from the
> Intel SDM[1] if the processor's read of the PTE and the write to set
> the accessed bit are atomic or not.

This reasoning is probably not correct.  When a dirty bit must be
updated in a PTE the processor does a pagetable walk (possibly using any
cached page table structures).  The AMD APM section 5.4.2 states:

"The processor never sets the Accessed bit or the Dirty bit for a not
present page (P = 0)."

and

"If PTE[D] is cleared to 0, software can rely on the fact that the page
has not been written."

Thus this patch would /introduce/ a race where a dirty bit set would be
lost (rather than extending the window where this would happen).

However (and this is a weaker argument), no sensible userspace
application should be accessing pages that are being unmapped or
remapped (since it is unpredictable whether they will fault) so perhaps
this additional unpredictable behaviour is acceptable?

> With this patch the get/clear becomes a read of the PTE and call to
> pte_clear() which allows the clears to be batched by some
> paravirtualized guests (such as Xen guests).  This can lead to
> significant performance improvements in munmap().  e.g., for Xen, a
> trap-and-emulate[2] for every page becomes a hypercall for every 31
> pages.
> 
> There should be no change in the performance on native or for KVM
> guests.  There may be a performance regression with lguest guests as
> an optimization for avoiding calling pte_update() when doing a full
> teardown of an mm is removed.

Having looked further into how lguest works the performance penalty is
likely to not be as bad as I first thought.  pte_clear() does call
pte_update() but these are batched and the batch size seems to be up-to
64 calls so the performance penalty should be pretty minimal.

> [1] Intel Software Developer's Manual Vol 3A section 4.8 says nothing
> on this.
> 
> [2] For 32-bit guests, two traps are required for every page to update
> both halves of the PTE.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 09:42:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 09: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 1SfT1x-0000RO-OO; Fri, 15 Jun 2012 09:41:25 +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 1SfT1w-0000RJ-4l
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 09:41:24 +0000
Received: from [85.158.143.99:57829] by server-3.bemta-4.messagelabs.com id
	F9/D3-05808-3430BDF4; Fri, 15 Jun 2012 09:41:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1339753281!20470501!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30577 invoked from network); 15 Jun 2012 09:41:22 -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;
	15 Jun 2012 09:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="28195337"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 05:41:21 -0400
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 15 Jun 2012
	05:41:21 -0400
Message-ID: <4FDB033F.8050703@citrix.com>
Date: Fri, 15 Jun 2012 10:41:19 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<1339582845-25659-2-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1339582845-25659-2-git-send-email-david.vrabel@citrix.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"H. Peter Anvin" <hpa@zytor.com>, "x86@kernel.org" <x86@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
 ptep_get_and_clear() 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 13/06/12 11:20, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> x86 provides a ptep_get_and_clear() function instead of using the
> generic implementation so it can atomically get and clear the PTE.
> 
> It is not clear why x86 has this requirement.  PTE updates are done
> while the appropriate PTE lock are held, so presumably, it is an
> attempt to ensure that the accessed and dirty bits of the PTE are
> saved even if they have been updated by the hardware due to a
> concurrent access on another CPU.
> 
> However, the atomic exchange is not sufficient for saving the dirty
> bit as if there is a TLB entry for this page on another CPU then the
> dirty bit may be written by that processor after the PTE is cleared
> but before the TLB entry is flushed.  It is also not clear from the
> Intel SDM[1] if the processor's read of the PTE and the write to set
> the accessed bit are atomic or not.

This reasoning is probably not correct.  When a dirty bit must be
updated in a PTE the processor does a pagetable walk (possibly using any
cached page table structures).  The AMD APM section 5.4.2 states:

"The processor never sets the Accessed bit or the Dirty bit for a not
present page (P = 0)."

and

"If PTE[D] is cleared to 0, software can rely on the fact that the page
has not been written."

Thus this patch would /introduce/ a race where a dirty bit set would be
lost (rather than extending the window where this would happen).

However (and this is a weaker argument), no sensible userspace
application should be accessing pages that are being unmapped or
remapped (since it is unpredictable whether they will fault) so perhaps
this additional unpredictable behaviour is acceptable?

> With this patch the get/clear becomes a read of the PTE and call to
> pte_clear() which allows the clears to be batched by some
> paravirtualized guests (such as Xen guests).  This can lead to
> significant performance improvements in munmap().  e.g., for Xen, a
> trap-and-emulate[2] for every page becomes a hypercall for every 31
> pages.
> 
> There should be no change in the performance on native or for KVM
> guests.  There may be a performance regression with lguest guests as
> an optimization for avoiding calling pte_update() when doing a full
> teardown of an mm is removed.

Having looked further into how lguest works the performance penalty is
likely to not be as bad as I first thought.  pte_clear() does call
pte_update() but these are batched and the batch size seems to be up-to
64 calls so the performance penalty should be pretty minimal.

> [1] Intel Software Developer's Manual Vol 3A section 4.8 says nothing
> on this.
> 
> [2] For 32-bit guests, two traps are required for every page to update
> both halves of the PTE.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 10:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 10: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 1SfU5h-0001oV-9I; Fri, 15 Jun 2012 10:49:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SfU5g-0001oN-1f
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 10:49:20 +0000
Received: from [85.158.143.35:32034] by server-3.bemta-4.messagelabs.com id
	13/BF-05808-F231BDF4; Fri, 15 Jun 2012 10:49:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339757358!6026457!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17859 invoked from network); 15 Jun 2012 10:49:18 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 10:49:18 -0000
Received: by eaaa12 with SMTP id a12so1211075eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Jun 2012 03:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/HoJs2dtj7mGwYS+jEhVognAY6yXoaBWmBIQtLEtOSw=;
	b=X7aeGTgZZhZodAYDiVqDZ6NbYQWX4LHdGmmyxnS/dDL9quFt6H3xOjlhd1zwPIWRAJ
	4ZqLApf0G3nZK8j2GhW4CwKY/MIPT8Rv03+0Bw/LVcnaiQjsvBzr3xvIXNU7NwTRmBnd
	r11zs4cPn25Zg0eHe2596Z/qDrbMHuVQ6biHpoXwF1TLAjZRibk0+5toIwN84GgqI6Qj
	SIEQYUz1YoPlehLWEANhXSBKDKzmC3EREq41rXaduKiWN2Tbi9FimB/zYSa2URoufPrT
	iUMixcZDCQHgEaQPPlW3KNXJvPpexVQUgTEvwT9AKcX4I6LotwNYLaYQ9qsJVCiKa+w9
	zK0A==
Received: by 10.14.47.199 with SMTP id t47mr1291415eeb.184.1339757357972;
	Fri, 15 Jun 2012 03:49:17 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id x52sm29445621eea.11.2012.06.15.03.49.15
	(version=SSLv3 cipher=OTHER); Fri, 15 Jun 2012 03:49:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 15 Jun 2012 11:49:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CC00D1B7.35E5B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
	ptep_get_and_clear() function
Thread-Index: Ac1K5H8o2d6Ebjb+NUyoHQ2/vxnmMQ==
In-Reply-To: <4FDB033F.8050703@citrix.com>
Mime-version: 1.0
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
 ptep_get_and_clear() 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 15/06/2012 10:41, "David Vrabel" <david.vrabel@citrix.com> wrote:

> This reasoning is probably not correct.  When a dirty bit must be
> updated in a PTE the processor does a pagetable walk (possibly using any
> cached page table structures).  The AMD APM section 5.4.2 states:
> 
> "The processor never sets the Accessed bit or the Dirty bit for a not
> present page (P = 0)."
> 
> and
> 
> "If PTE[D] is cleared to 0, software can rely on the fact that the page
> has not been written."

Writing of dirty and accessed bits is done as part of the page-table walk on
TLB fill. A/D bits never have writeback caching semantics. It wouldn't be
safe: e.g., on unmap, TLB flushes happen after ptes have been cleared (to
avoid TLB-fill races), but that would mean that A/D updates could be lost
even on non-explicit unmaps (e.g., page out) which is obviously bad.

> Thus this patch would /introduce/ a race where a dirty bit set would be
> lost (rather than extending the window where this would happen).
> 
> However (and this is a weaker argument), no sensible userspace
> application should be accessing pages that are being unmapped or
> remapped (since it is unpredictable whether they will fault) so perhaps
> this additional unpredictable behaviour is acceptable?

If there's a big win to be had through batching, we're better off devising a
hypercall method for capturing the atomic rmw operation as it stands, rather
than subtly messing with semantics.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 10:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 10: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 1SfU5h-0001oV-9I; Fri, 15 Jun 2012 10:49:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SfU5g-0001oN-1f
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 10:49:20 +0000
Received: from [85.158.143.35:32034] by server-3.bemta-4.messagelabs.com id
	13/BF-05808-F231BDF4; Fri, 15 Jun 2012 10:49:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1339757358!6026457!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17859 invoked from network); 15 Jun 2012 10:49:18 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 10:49:18 -0000
Received: by eaaa12 with SMTP id a12so1211075eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Jun 2012 03:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/HoJs2dtj7mGwYS+jEhVognAY6yXoaBWmBIQtLEtOSw=;
	b=X7aeGTgZZhZodAYDiVqDZ6NbYQWX4LHdGmmyxnS/dDL9quFt6H3xOjlhd1zwPIWRAJ
	4ZqLApf0G3nZK8j2GhW4CwKY/MIPT8Rv03+0Bw/LVcnaiQjsvBzr3xvIXNU7NwTRmBnd
	r11zs4cPn25Zg0eHe2596Z/qDrbMHuVQ6biHpoXwF1TLAjZRibk0+5toIwN84GgqI6Qj
	SIEQYUz1YoPlehLWEANhXSBKDKzmC3EREq41rXaduKiWN2Tbi9FimB/zYSa2URoufPrT
	iUMixcZDCQHgEaQPPlW3KNXJvPpexVQUgTEvwT9AKcX4I6LotwNYLaYQ9qsJVCiKa+w9
	zK0A==
Received: by 10.14.47.199 with SMTP id t47mr1291415eeb.184.1339757357972;
	Fri, 15 Jun 2012 03:49:17 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id x52sm29445621eea.11.2012.06.15.03.49.15
	(version=SSLv3 cipher=OTHER); Fri, 15 Jun 2012 03:49:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 15 Jun 2012 11:49:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CC00D1B7.35E5B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
	ptep_get_and_clear() function
Thread-Index: Ac1K5H8o2d6Ebjb+NUyoHQ2/vxnmMQ==
In-Reply-To: <4FDB033F.8050703@citrix.com>
Mime-version: 1.0
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Xen-devel] [PATCH 1/2] x86/mm: remove arch-specific
 ptep_get_and_clear() 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 15/06/2012 10:41, "David Vrabel" <david.vrabel@citrix.com> wrote:

> This reasoning is probably not correct.  When a dirty bit must be
> updated in a PTE the processor does a pagetable walk (possibly using any
> cached page table structures).  The AMD APM section 5.4.2 states:
> 
> "The processor never sets the Accessed bit or the Dirty bit for a not
> present page (P = 0)."
> 
> and
> 
> "If PTE[D] is cleared to 0, software can rely on the fact that the page
> has not been written."

Writing of dirty and accessed bits is done as part of the page-table walk on
TLB fill. A/D bits never have writeback caching semantics. It wouldn't be
safe: e.g., on unmap, TLB flushes happen after ptes have been cleared (to
avoid TLB-fill races), but that would mean that A/D updates could be lost
even on non-explicit unmaps (e.g., page out) which is obviously bad.

> Thus this patch would /introduce/ a race where a dirty bit set would be
> lost (rather than extending the window where this would happen).
> 
> However (and this is a weaker argument), no sensible userspace
> application should be accessing pages that are being unmapped or
> remapped (since it is unpredictable whether they will fault) so perhaps
> this additional unpredictable behaviour is acceptable?

If there's a big win to be had through batching, we're better off devising a
hypercall method for capturing the atomic rmw operation as it stands, rather
than subtly messing with semantics.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:03:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfUIh-0003WU-7w; Fri, 15 Jun 2012 11:02: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 1SfUIf-0003W3-6Y
	for Xen-devel@lists.xensource.com; Fri, 15 Jun 2012 11:02:45 +0000
Received: from [85.158.139.83:5990] by server-5.bemta-5.messagelabs.com id
	6A/4A-02722-4561BDF4; Fri, 15 Jun 2012 11:02:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339758163!27767095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7704 invoked from network); 15 Jun 2012 11:02:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13040698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:02:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:02:43 +0100
Date: Fri, 15 Jun 2012 12:02:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor <mukesh.rathor@oracle.com>
In-Reply-To: <20120614184338.43fb879b@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1206151201150.14957@kaball.uk.xensource.com>
References: <20120614184338.43fb879b@mantra.us.oracle.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Mukesh Rathor wrote:
> Hi guys,
> 
> During my refresh to latest linux, I noticed, direct mapping of all
> non-RAM pages in xen_set_identity_and_release(). I currently don't map
> all at front, but as needed looking at the PAGE_IO bit in the pte. One
> result of that is minor change to common code macro:
> 
>         __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
> to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)
> 
> 
> To avoid this change, and keep all my changes limited to xen files only,
> I thought I could just map the entire non-ram pages up front too. But
> I am concerned the EPT may grow too large? Specially, when we get to 
> *really* large NUMA boxes. What do you guys think? Should I worry about
> it?

I would map them all up front and worry about it later.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:03:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfUIh-0003WU-7w; Fri, 15 Jun 2012 11:02: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 1SfUIf-0003W3-6Y
	for Xen-devel@lists.xensource.com; Fri, 15 Jun 2012 11:02:45 +0000
Received: from [85.158.139.83:5990] by server-5.bemta-5.messagelabs.com id
	6A/4A-02722-4561BDF4; Fri, 15 Jun 2012 11:02:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339758163!27767095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7704 invoked from network); 15 Jun 2012 11:02:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13040698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:02:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:02:43 +0100
Date: Fri, 15 Jun 2012 12:02:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor <mukesh.rathor@oracle.com>
In-Reply-To: <20120614184338.43fb879b@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1206151201150.14957@kaball.uk.xensource.com>
References: <20120614184338.43fb879b@mantra.us.oracle.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Mukesh Rathor wrote:
> Hi guys,
> 
> During my refresh to latest linux, I noticed, direct mapping of all
> non-RAM pages in xen_set_identity_and_release(). I currently don't map
> all at front, but as needed looking at the PAGE_IO bit in the pte. One
> result of that is minor change to common code macro:
> 
>         __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
> to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)
> 
> 
> To avoid this change, and keep all my changes limited to xen files only,
> I thought I could just map the entire non-ram pages up front too. But
> I am concerned the EPT may grow too large? Specially, when we get to 
> *really* large NUMA boxes. What do you guys think? Should I worry about
> it?

I would map them all up front and worry about it later.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:06:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:06: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 1SfUM9-0003wi-Gg; Fri, 15 Jun 2012 11:06: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 1SfUM8-0003wK-3M
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:06:20 +0000
Received: from [85.158.139.83:40292] by server-12.bemta-5.messagelabs.com id
	DE/07-25233-B271BDF4; Fri, 15 Jun 2012 11:06:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339758378!20624477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1647 invoked from network); 15 Jun 2012 11:06:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13040773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:06:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:06:18 +0100
Date: Fri, 15 Jun 2012 12:05:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120614194129.GG19807@redhat.com>
Message-ID: <alpine.DEB.2.02.1206151204140.14957@kaball.uk.xensource.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<20120614194129.GG19807@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH V13 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 14 Jun 2012, Michael S. Tsirkin wrote:
> On Thu, Jun 14, 2012 at 06:01:40PM +0100, Anthony PERARD wrote:
> > Hi all,
> > 
> > This patch series introduces the PCI passthrough for Xen.
> > 
> > Changes since the last version:
> >   - New patch that introduce a new qdev-property pci-host-devaddr.
> >   => the "export pci_parse_devaddr" patch is not anymore usefull.
> > 
> > Thanks,
> 
> I reviewed some patches and Acked. Won't have the time to
> review the rest of the series short term.
> If you need me to merge some of these patches myself
> pls let me know.

Considering that you Acked all the non-Xen patches (apart from the
configure patch), I think I'll just go ahead and submit a pull request
to Anthony myself, if you are OK with it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:06:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:06: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 1SfUM9-0003wi-Gg; Fri, 15 Jun 2012 11:06: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 1SfUM8-0003wK-3M
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:06:20 +0000
Received: from [85.158.139.83:40292] by server-12.bemta-5.messagelabs.com id
	DE/07-25233-B271BDF4; Fri, 15 Jun 2012 11:06:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1339758378!20624477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1647 invoked from network); 15 Jun 2012 11:06:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13040773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:06:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:06:18 +0100
Date: Fri, 15 Jun 2012 12:05:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120614194129.GG19807@redhat.com>
Message-ID: <alpine.DEB.2.02.1206151204140.14957@kaball.uk.xensource.com>
References: <1339693309-15192-1-git-send-email-anthony.perard@citrix.com>
	<20120614194129.GG19807@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH V13 0/9] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 14 Jun 2012, Michael S. Tsirkin wrote:
> On Thu, Jun 14, 2012 at 06:01:40PM +0100, Anthony PERARD wrote:
> > Hi all,
> > 
> > This patch series introduces the PCI passthrough for Xen.
> > 
> > Changes since the last version:
> >   - New patch that introduce a new qdev-property pci-host-devaddr.
> >   => the "export pci_parse_devaddr" patch is not anymore usefull.
> > 
> > Thanks,
> 
> I reviewed some patches and Acked. Won't have the time to
> review the rest of the series short term.
> If you need me to merge some of these patches myself
> pls let me know.

Considering that you Acked all the non-Xen patches (apart from the
configure patch), I think I'll just go ahead and submit a pull request
to Anthony myself, if you are OK with it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:14:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfUTt-0004jT-I6; Fri, 15 Jun 2012 11:14:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SfUTr-0004jJ-Mn
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:14:19 +0000
Received: from [85.158.143.99:11872] by server-2.bemta-4.messagelabs.com id
	BB/1E-17938-B091BDF4; Fri, 15 Jun 2012 11:14:19 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339758857!22245251!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjQ2MjY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5111 invoked from network); 15 Jun 2012 11:14:18 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 11:14:18 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7B9CE21311
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 07:14:17 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute1.internal (MEProxy); Fri, 15 Jun 2012 07:14:17 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=mesmtp; bh=1DJXr
	i/Q71O9ISjme+2ioptN9+8=; b=X3aAFJMP1tTOuHFhSKtpw+fYM2BZzWwPz2ZIU
	pRrKI2p2q6ia4VsH6SwD4nXHKE2LOySw3XP99bGB2i2vw5hg5D5jX7QQWnR1wmuP
	xN4pifLCe5rQVI+rbnQT5sdy3NzCSIAXbr7avGMwbVmo8MvHW7w587bVB87m0hR0
	s4CNpc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=smtpout; bh=1DJX
	ri/Q71O9ISjme+2ioptN9+8=; b=Y0Ix49knQk7dOpI85uaqJnsmU4xqd5vLqDiw
	narmkp9kgykaRHPGDgLyLoh6XKrjlXmSoPgsWhihaDMHjzPDy8dxD2IY5jrA5o2I
	xI7F41m4JkhtLN9oxSrmnvL+eLJOcjghpohrZ1hWJzBX4X2ICPZIWDy294k+NXa9
	ZMxqQhM=
X-Sasl-enc: hSm+zg+M8Q8+88dGTEigEjSHFeW+1unqAMsmlqgqyyFG 1339758857
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 1DB1A8E0170
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 07:14:17 -0400 (EDT)
Message-ID: <4FDB1904.6010303@invisiblethingslab.com>
Date: Fri, 15 Jun 2012 13:14:12 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FD1F9E8.20508@invisiblethingslab.com>
	<4FD9D8A0.1060504@invisiblethingslab.com>
In-Reply-To: <4FD9D8A0.1060504@invisiblethingslab.com>
X-Enigmail-Version: 1.4.1
Subject: Re: [Xen-devel] block backend 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: multipart/mixed; boundary="===============8415861635709727201=="
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)
--===============8415861635709727201==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig14F5AF568E6D184B5C199126"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig14F5AF568E6D184B5C199126
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 14.06.2012 14:27, Marek Marczykowski wrote:
> On 08.06.2012 15:11, Marek Marczykowski wrote:
>> Hey,
>>
>> I've faced strange problem with block devices. When trying to read som=
e file
>> (from read-only ext3), everything looks good, except that file content=
 is
>> corrupted! But this can be coincidence (that "failed" reads doesn't hi=
t
>> filesystem metadata).
>> fsck in dom0 on filesystem image returns no errors.
>> fsck (with -nf flags) in domU on the device causes the kernel to outpu=
t
>> "blkfront: flush disk cache: empty write xvdd op failed", "blkfront: x=
vdd:
>> barrier or flush: disable". And returns no filesystem errors. From tha=
t point,
>> file reads return correct file content. For most cases dropping block =
cache
>> (echo 3 > /proc/sys/vm/drop_caches) or remounting device also "fixes" =
the problem.
>>
>> On RW device (with different size, filesystem and content), domU kerne=
l
>> complains about EXT4 errors.
>> Doesn't observed such strange issues on device-mapper backed devices.
>>
>> On 3.2.7 it worked, problem observed on 3.3.5 and 3.4 in dom0, regardl=
ess of
>> domU kernel (tried 3.2.7, 3.3.5, 3.4.0).
>>
>> I've suspected feature-flush-cache/feature-barrier, but when disabled =
its
>> advertise in blkback code, problem still occurs.
>>
>> Some details:
>> dom0: 3.4.0-1.pvops.qubes.x86_64 (vanilla 3.4 + Konrad's patches for A=
CPI S3)
>> domU: 3.3.5-1.pvops.qubes.x86_64 (vanilla 3.3.5 + Konrad's patches for=
 ACPI S3)
>=20
> (...)
> Still the case on 3.4.1 with applied patches from Konrad's for-jens-3.5=
 branch.
> I've compared file contents and it differs in (multiply of) 1024 bytes =
- the
> same as filesystem block size. And only if block wasn't in pagecache in=
 dom0.
> When I flush VM pagecache (echo 1 > /proc/.../drop_caches) after trying=
 to
> read some files (actually md5sum -c), but not dom0 pagecache - problem
> vanished. But if I clean also dom0 pagecache - problem returns.
>=20
> Any clues welcomed...

Ok, found the reason. It wasn't blkback fault, even on baremetal,
loopback-mounted image had the same problem. It was caused by "0fc9d104
radix-tree: use iterators in find_get_pages* functions" commit somehow be=
tween
3.3 and 3.4. It is already fixed in 3.4.2.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig14F5AF568E6D184B5C199126
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP2xkEAAoJENuP0xzK19cs8YgH/idnTlU5mm1Kn0gwFdXt1h/P
7cIL+zIwyWmgUeYZK0gwDe/0BYdEE5n16lJZ//HKagEgB7gw9cEMl3OGqQAO4eE6
+y+fX2KHsqETCUscNdq44aVyBQQ2EXyundA5JvTWTph2fnyfqd93S29Agu/SHiLP
oPQh2o5WGRX/mYCkb1GpnplMaDjLkhGFpeF75fxekMWc6IzV7hJUnn7IHX6ik9Yw
se9ukC85GUfWWsJ+eC5MbC1Lr+FZ3d5Nk9j1lye65Re4hla/6sexG4nx19oH3xQT
EaFMhSLsmunix3r+GtcNMUB9mGTlhRoiasJH+bipvLxujYCIi3ZRdTm4EpPhQOI=
=gXWX
-----END PGP SIGNATURE-----

--------------enig14F5AF568E6D184B5C199126--


--===============8415861635709727201==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8415861635709727201==--


From xen-devel-bounces@lists.xen.org Fri Jun 15 11:14:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfUTt-0004jT-I6; Fri, 15 Jun 2012 11:14:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1SfUTr-0004jJ-Mn
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:14:19 +0000
Received: from [85.158.143.99:11872] by server-2.bemta-4.messagelabs.com id
	BB/1E-17938-B091BDF4; Fri, 15 Jun 2012 11:14:19 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1339758857!22245251!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjQ2MjY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5111 invoked from network); 15 Jun 2012 11:14:18 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 11:14:18 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7B9CE21311
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 07:14:17 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute1.internal (MEProxy); Fri, 15 Jun 2012 07:14:17 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=mesmtp; bh=1DJXr
	i/Q71O9ISjme+2ioptN9+8=; b=X3aAFJMP1tTOuHFhSKtpw+fYM2BZzWwPz2ZIU
	pRrKI2p2q6ia4VsH6SwD4nXHKE2LOySw3XP99bGB2i2vw5hg5D5jX7QQWnR1wmuP
	xN4pifLCe5rQVI+rbnQT5sdy3NzCSIAXbr7avGMwbVmo8MvHW7w587bVB87m0hR0
	s4CNpc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=smtpout; bh=1DJX
	ri/Q71O9ISjme+2ioptN9+8=; b=Y0Ix49knQk7dOpI85uaqJnsmU4xqd5vLqDiw
	narmkp9kgykaRHPGDgLyLoh6XKrjlXmSoPgsWhihaDMHjzPDy8dxD2IY5jrA5o2I
	xI7F41m4JkhtLN9oxSrmnvL+eLJOcjghpohrZ1hWJzBX4X2ICPZIWDy294k+NXa9
	ZMxqQhM=
X-Sasl-enc: hSm+zg+M8Q8+88dGTEigEjSHFeW+1unqAMsmlqgqyyFG 1339758857
Received: from [10.137.2.11] (unknown [89.67.97.211])
	by mail.messagingengine.com (Postfix) with ESMTPA id 1DB1A8E0170
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 07:14:17 -0400 (EDT)
Message-ID: <4FDB1904.6010303@invisiblethingslab.com>
Date: Fri, 15 Jun 2012 13:14:12 +0200
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FD1F9E8.20508@invisiblethingslab.com>
	<4FD9D8A0.1060504@invisiblethingslab.com>
In-Reply-To: <4FD9D8A0.1060504@invisiblethingslab.com>
X-Enigmail-Version: 1.4.1
Subject: Re: [Xen-devel] block backend 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: multipart/mixed; boundary="===============8415861635709727201=="
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)
--===============8415861635709727201==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig14F5AF568E6D184B5C199126"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig14F5AF568E6D184B5C199126
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 14.06.2012 14:27, Marek Marczykowski wrote:
> On 08.06.2012 15:11, Marek Marczykowski wrote:
>> Hey,
>>
>> I've faced strange problem with block devices. When trying to read som=
e file
>> (from read-only ext3), everything looks good, except that file content=
 is
>> corrupted! But this can be coincidence (that "failed" reads doesn't hi=
t
>> filesystem metadata).
>> fsck in dom0 on filesystem image returns no errors.
>> fsck (with -nf flags) in domU on the device causes the kernel to outpu=
t
>> "blkfront: flush disk cache: empty write xvdd op failed", "blkfront: x=
vdd:
>> barrier or flush: disable". And returns no filesystem errors. From tha=
t point,
>> file reads return correct file content. For most cases dropping block =
cache
>> (echo 3 > /proc/sys/vm/drop_caches) or remounting device also "fixes" =
the problem.
>>
>> On RW device (with different size, filesystem and content), domU kerne=
l
>> complains about EXT4 errors.
>> Doesn't observed such strange issues on device-mapper backed devices.
>>
>> On 3.2.7 it worked, problem observed on 3.3.5 and 3.4 in dom0, regardl=
ess of
>> domU kernel (tried 3.2.7, 3.3.5, 3.4.0).
>>
>> I've suspected feature-flush-cache/feature-barrier, but when disabled =
its
>> advertise in blkback code, problem still occurs.
>>
>> Some details:
>> dom0: 3.4.0-1.pvops.qubes.x86_64 (vanilla 3.4 + Konrad's patches for A=
CPI S3)
>> domU: 3.3.5-1.pvops.qubes.x86_64 (vanilla 3.3.5 + Konrad's patches for=
 ACPI S3)
>=20
> (...)
> Still the case on 3.4.1 with applied patches from Konrad's for-jens-3.5=
 branch.
> I've compared file contents and it differs in (multiply of) 1024 bytes =
- the
> same as filesystem block size. And only if block wasn't in pagecache in=
 dom0.
> When I flush VM pagecache (echo 1 > /proc/.../drop_caches) after trying=
 to
> read some files (actually md5sum -c), but not dom0 pagecache - problem
> vanished. But if I clean also dom0 pagecache - problem returns.
>=20
> Any clues welcomed...

Ok, found the reason. It wasn't blkback fault, even on baremetal,
loopback-mounted image had the same problem. It was caused by "0fc9d104
radix-tree: use iterators in find_get_pages* functions" commit somehow be=
tween
3.3 and 3.4. It is already fixed in 3.4.2.

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig14F5AF568E6D184B5C199126
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP2xkEAAoJENuP0xzK19cs8YgH/idnTlU5mm1Kn0gwFdXt1h/P
7cIL+zIwyWmgUeYZK0gwDe/0BYdEE5n16lJZ//HKagEgB7gw9cEMl3OGqQAO4eE6
+y+fX2KHsqETCUscNdq44aVyBQQ2EXyundA5JvTWTph2fnyfqd93S29Agu/SHiLP
oPQh2o5WGRX/mYCkb1GpnplMaDjLkhGFpeF75fxekMWc6IzV7hJUnn7IHX6ik9Yw
se9ukC85GUfWWsJ+eC5MbC1Lr+FZ3d5Nk9j1lye65Re4hla/6sexG4nx19oH3xQT
EaFMhSLsmunix3r+GtcNMUB9mGTlhRoiasJH+bipvLxujYCIi3ZRdTm4EpPhQOI=
=gXWX
-----END PGP SIGNATURE-----

--------------enig14F5AF568E6D184B5C199126--


--===============8415861635709727201==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8415861635709727201==--


From xen-devel-bounces@lists.xen.org Fri Jun 15 11:17:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:17: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 1SfUWj-0004uJ-4O; Fri, 15 Jun 2012 11:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfUWh-0004u5-PL
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:17:15 +0000
Received: from [85.158.139.83:25755] by server-12.bemta-5.messagelabs.com id
	1C/59-25233-AB91BDF4; Fri, 15 Jun 2012 11:17:14 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339759033!25136596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5882 invoked from network); 15 Jun 2012 11:17:14 -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;
	15 Jun 2012 11:17:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198876403"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 07:17:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 07:17:12 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfUWe-00088W-2t;
	Fri, 15 Jun 2012 12:17:12 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 15 Jun 2012 12:17:08 +0100
Message-ID: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 0/2] xen: Deprecation of <xs.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

Considering that <xs.h> will be deprecated in the next release of Xen, this two
patches clean a bit the inclusion of xs.h and changes it in a single place.

Anthony PERARD (2):
  xen: Reorganize includes of Xen headers.
  xenstore: Use <xenstore.h>

 configure        |    2 +-
 hw/xen_backend.c |    6 ++----
 hw/xen_common.h  |    6 +++++-
 hw/xen_console.c |    5 ++---
 hw/xen_disk.c    |    6 +-----
 hw/xen_nic.c     |    7 ++-----
 hw/xenfb.c       |   13 +++++--------
 7 files changed, 18 insertions(+), 27 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:17:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:17: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 1SfUWj-0004uJ-4O; Fri, 15 Jun 2012 11:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfUWh-0004u5-PL
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:17:15 +0000
Received: from [85.158.139.83:25755] by server-12.bemta-5.messagelabs.com id
	1C/59-25233-AB91BDF4; Fri, 15 Jun 2012 11:17:14 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339759033!25136596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5882 invoked from network); 15 Jun 2012 11:17:14 -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;
	15 Jun 2012 11:17:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198876403"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 07:17:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 07:17:12 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfUWe-00088W-2t;
	Fri, 15 Jun 2012 12:17:12 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 15 Jun 2012 12:17:08 +0100
Message-ID: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 0/2] xen: Deprecation of <xs.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

Considering that <xs.h> will be deprecated in the next release of Xen, this two
patches clean a bit the inclusion of xs.h and changes it in a single place.

Anthony PERARD (2):
  xen: Reorganize includes of Xen headers.
  xenstore: Use <xenstore.h>

 configure        |    2 +-
 hw/xen_backend.c |    6 ++----
 hw/xen_common.h  |    6 +++++-
 hw/xen_console.c |    5 ++---
 hw/xen_disk.c    |    6 +-----
 hw/xen_nic.c     |    7 ++-----
 hw/xenfb.c       |   13 +++++--------
 7 files changed, 18 insertions(+), 27 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfUWj-0004uU-HL; Fri, 15 Jun 2012 11:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfUWi-0004u7-Bu
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:17:16 +0000
Received: from [85.158.139.83:27826] by server-7.bemta-5.messagelabs.com id
	EC/88-28276-BB91BDF4; Fri, 15 Jun 2012 11:17:15 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339759033!25136596!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5927 invoked from network); 15 Jun 2012 11:17:14 -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;
	15 Jun 2012 11:17:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198876404"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 07:17:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 07:17:12 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfUWe-00088W-4m;
	Fri, 15 Jun 2012 12:17:12 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 15 Jun 2012 12:17:09 +0100
Message-ID: <1339759030-32653-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/2] xen: Reorganize includes of Xen 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

Because xs.h will be remove in future release of Xen, this patch removes the
extra includes of this headers.

Also, it removes the extra includes of xenctrl.h and xen/io/xenbus.h as there
already are in xen_common.h.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_backend.c |    6 ++----
 hw/xen_console.c |    5 ++---
 hw/xen_disk.c    |    6 +-----
 hw/xen_nic.c     |    7 ++-----
 hw/xenfb.c       |   13 +++++--------
 5 files changed, 12 insertions(+), 25 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 66cb144..f83a1e1 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -34,15 +34,13 @@
 #include <sys/mman.h>
 #include <sys/signal.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/grant_table.h>
-
 #include "hw.h"
 #include "qemu-char.h"
 #include "qemu-log.h"
 #include "xen_backend.h"
 
+#include <xen/grant_table.h>
+
 /* ------------------------------------------------------------- */
 
 /* public */
diff --git a/hw/xen_console.c b/hw/xen_console.c
index 3794b19..9426d73 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -28,14 +28,13 @@
 #include <termios.h>
 #include <stdarg.h>
 #include <sys/mman.h>
-#include <xs.h>
-#include <xen/io/console.h>
-#include <xenctrl.h>
 
 #include "hw.h"
 #include "qemu-char.h"
 #include "xen_backend.h"
 
+#include <xen/io/console.h>
+
 struct buffer {
     uint8_t *data;
     size_t consumed;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index de7e8a4..48f99c6 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -35,15 +35,11 @@
 #include <sys/mman.h>
 #include <sys/uio.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/io/xenbus.h>
-
 #include "hw.h"
 #include "block_int.h"
 #include "qemu-char.h"
-#include "xen_blkif.h"
 #include "xen_backend.h"
+#include "xen_blkif.h"
 #include "blockdev.h"
 
 /* ------------------------------------------------------------- */
diff --git a/hw/xen_nic.c b/hw/xen_nic.c
index 9a59bda..98db9bb 100644
--- a/hw/xen_nic.c
+++ b/hw/xen_nic.c
@@ -35,11 +35,6 @@
 #include <sys/mman.h>
 #include <sys/wait.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/io/xenbus.h>
-#include <xen/io/netif.h>
-
 #include "hw.h"
 #include "net.h"
 #include "net/checksum.h"
@@ -47,6 +42,8 @@
 #include "qemu-char.h"
 #include "xen_backend.h"
 
+#include <xen/io/netif.h>
+
 /* ------------------------------------------------------------- */
 
 struct XenNetDev {
diff --git a/hw/xenfb.c b/hw/xenfb.c
index 1bcf171..338800a 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -35,19 +35,16 @@
 #include <string.h>
 #include <time.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/event_channel.h>
-#include <xen/io/xenbus.h>
-#include <xen/io/fbif.h>
-#include <xen/io/kbdif.h>
-#include <xen/io/protocols.h>
-
 #include "hw.h"
 #include "console.h"
 #include "qemu-char.h"
 #include "xen_backend.h"
 
+#include <xen/event_channel.h>
+#include <xen/io/fbif.h>
+#include <xen/io/kbdif.h>
+#include <xen/io/protocols.h>
+
 #ifndef BTN_LEFT
 #define BTN_LEFT 0x110 /* from <linux/input.h> */
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfUWj-0004uU-HL; Fri, 15 Jun 2012 11:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfUWi-0004u7-Bu
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:17:16 +0000
Received: from [85.158.139.83:27826] by server-7.bemta-5.messagelabs.com id
	EC/88-28276-BB91BDF4; Fri, 15 Jun 2012 11:17:15 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339759033!25136596!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5927 invoked from network); 15 Jun 2012 11:17:14 -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;
	15 Jun 2012 11:17:14 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198876404"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 07:17:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 07:17:12 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfUWe-00088W-4m;
	Fri, 15 Jun 2012 12:17:12 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 15 Jun 2012 12:17:09 +0100
Message-ID: <1339759030-32653-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/2] xen: Reorganize includes of Xen 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

Because xs.h will be remove in future release of Xen, this patch removes the
extra includes of this headers.

Also, it removes the extra includes of xenctrl.h and xen/io/xenbus.h as there
already are in xen_common.h.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_backend.c |    6 ++----
 hw/xen_console.c |    5 ++---
 hw/xen_disk.c    |    6 +-----
 hw/xen_nic.c     |    7 ++-----
 hw/xenfb.c       |   13 +++++--------
 5 files changed, 12 insertions(+), 25 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 66cb144..f83a1e1 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -34,15 +34,13 @@
 #include <sys/mman.h>
 #include <sys/signal.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/grant_table.h>
-
 #include "hw.h"
 #include "qemu-char.h"
 #include "qemu-log.h"
 #include "xen_backend.h"
 
+#include <xen/grant_table.h>
+
 /* ------------------------------------------------------------- */
 
 /* public */
diff --git a/hw/xen_console.c b/hw/xen_console.c
index 3794b19..9426d73 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -28,14 +28,13 @@
 #include <termios.h>
 #include <stdarg.h>
 #include <sys/mman.h>
-#include <xs.h>
-#include <xen/io/console.h>
-#include <xenctrl.h>
 
 #include "hw.h"
 #include "qemu-char.h"
 #include "xen_backend.h"
 
+#include <xen/io/console.h>
+
 struct buffer {
     uint8_t *data;
     size_t consumed;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index de7e8a4..48f99c6 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -35,15 +35,11 @@
 #include <sys/mman.h>
 #include <sys/uio.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/io/xenbus.h>
-
 #include "hw.h"
 #include "block_int.h"
 #include "qemu-char.h"
-#include "xen_blkif.h"
 #include "xen_backend.h"
+#include "xen_blkif.h"
 #include "blockdev.h"
 
 /* ------------------------------------------------------------- */
diff --git a/hw/xen_nic.c b/hw/xen_nic.c
index 9a59bda..98db9bb 100644
--- a/hw/xen_nic.c
+++ b/hw/xen_nic.c
@@ -35,11 +35,6 @@
 #include <sys/mman.h>
 #include <sys/wait.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/io/xenbus.h>
-#include <xen/io/netif.h>
-
 #include "hw.h"
 #include "net.h"
 #include "net/checksum.h"
@@ -47,6 +42,8 @@
 #include "qemu-char.h"
 #include "xen_backend.h"
 
+#include <xen/io/netif.h>
+
 /* ------------------------------------------------------------- */
 
 struct XenNetDev {
diff --git a/hw/xenfb.c b/hw/xenfb.c
index 1bcf171..338800a 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -35,19 +35,16 @@
 #include <string.h>
 #include <time.h>
 
-#include <xs.h>
-#include <xenctrl.h>
-#include <xen/event_channel.h>
-#include <xen/io/xenbus.h>
-#include <xen/io/fbif.h>
-#include <xen/io/kbdif.h>
-#include <xen/io/protocols.h>
-
 #include "hw.h"
 #include "console.h"
 #include "qemu-char.h"
 #include "xen_backend.h"
 
+#include <xen/event_channel.h>
+#include <xen/io/fbif.h>
+#include <xen/io/kbdif.h>
+#include <xen/io/protocols.h>
+
 #ifndef BTN_LEFT
 #define BTN_LEFT 0x110 /* from <linux/input.h> */
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:17:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfUWl-0004ut-2P; Fri, 15 Jun 2012 11:17:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfUWj-0004uD-44
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:17:17 +0000
Received: from [85.158.139.83:27907] by server-6.bemta-5.messagelabs.com id
	46/50-11348-CB91BDF4; Fri, 15 Jun 2012 11:17:16 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339759033!25136596!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5979 invoked from network); 15 Jun 2012 11:17:15 -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;
	15 Jun 2012 11:17:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198876405"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 07:17:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 07:17:12 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfUWe-00088W-6U;
	Fri, 15 Jun 2012 12:17:12 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 15 Jun 2012 12:17:10 +0100
Message-ID: <1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 2/2] xenstore: Use <xenstore.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

In the next release of Xen (4.2), xs.h became deprecated.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure       |    2 +-
 hw/xen_common.h |    6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index c2366ee..e7f66c9 100755
--- a/configure
+++ b/configure
@@ -1382,7 +1382,7 @@ EOF
   elif (
       cat > $TMPC <<EOF
 #include <xenctrl.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <stdint.h>
 #include <xen/hvm/hvm_info_table.h>
 #if !defined(HVM_MAX_VCPUS)
diff --git a/hw/xen_common.h b/hw/xen_common.h
index fe7f227..cc99204 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -7,7 +7,11 @@
 #include <inttypes.h>
 
 #include <xenctrl.h>
-#include <xs.h>
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
+#  include <xs.h>
+#else
+#  include <xenstore.h>
+#endif
 #include <xen/io/xenbus.h>
 
 #include "hw.h"
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:17:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfUWl-0004ut-2P; Fri, 15 Jun 2012 11:17:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SfUWj-0004uD-44
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:17:17 +0000
Received: from [85.158.139.83:27907] by server-6.bemta-5.messagelabs.com id
	46/50-11348-CB91BDF4; Fri, 15 Jun 2012 11:17:16 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1339759033!25136596!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5979 invoked from network); 15 Jun 2012 11:17:15 -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;
	15 Jun 2012 11:17:15 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198876405"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 07:17:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 07:17:12 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SfUWe-00088W-6U;
	Fri, 15 Jun 2012 12:17:12 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 15 Jun 2012 12:17:10 +0100
Message-ID: <1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 2/2] xenstore: Use <xenstore.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

In the next release of Xen (4.2), xs.h became deprecated.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure       |    2 +-
 hw/xen_common.h |    6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index c2366ee..e7f66c9 100755
--- a/configure
+++ b/configure
@@ -1382,7 +1382,7 @@ EOF
   elif (
       cat > $TMPC <<EOF
 #include <xenctrl.h>
-#include <xs.h>
+#include <xenstore.h>
 #include <stdint.h>
 #include <xen/hvm/hvm_info_table.h>
 #if !defined(HVM_MAX_VCPUS)
diff --git a/hw/xen_common.h b/hw/xen_common.h
index fe7f227..cc99204 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -7,7 +7,11 @@
 #include <inttypes.h>
 
 #include <xenctrl.h>
-#include <xs.h>
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
+#  include <xs.h>
+#else
+#  include <xenstore.h>
+#endif
 #include <xen/io/xenbus.h>
 
 #include "hw.h"
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:54:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV64-0005fH-9Z; Fri, 15 Jun 2012 11:53:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quintela@redhat.com>) id 1SfV62-0005f9-KR
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:53:46 +0000
Received: from [85.158.139.83:4761] by server-10.bemta-5.messagelabs.com id
	C5/E5-02190-9422BDF4; Fri, 15 Jun 2012 11:53:45 +0000
X-Env-Sender: quintela@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339761224!27319987!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTMxNDI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6355 invoked from network); 15 Jun 2012 11:53:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	15 Jun 2012 11:53:45 -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 q5FBrfDs006631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 07:53:41 -0400
Received: from localhost (ovpn-116-54.ams2.redhat.com [10.36.116.54])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q5FBrdNu019456; Fri, 15 Jun 2012 07:53:40 -0400
From: Juan Quintela <quintela@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
	(Anthony PERARD's message of "Fri, 15 Jun 2012 12:17:10 +0100")
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
	<1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux)
Date: Fri, 15 Jun 2012 13:53:30 +0200
Message-ID: <87bokkeqpx.fsf@elfo.mitica>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xenstore: Use <xenstore.h>
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: quintela@redhat.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

Anthony PERARD <anthony.perard@citrix.com> wrote:
> In the next release of Xen (4.2), xs.h became deprecated.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  configure       |    2 +-
>  hw/xen_common.h |    6 +++++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index c2366ee..e7f66c9 100755
> --- a/configure
> +++ b/configure
> @@ -1382,7 +1382,7 @@ EOF
>    elif (
>        cat > $TMPC <<EOF
>  #include <xenctrl.h>
> -#include <xs.h>
> +#include <xenstore.h>
>  #include <stdint.h>
>  #include <xen/hvm/hvm_info_table.h>
>  #if !defined(HVM_MAX_VCPUS)
> diff --git a/hw/xen_common.h b/hw/xen_common.h
> index fe7f227..cc99204 100644
> --- a/hw/xen_common.h
> +++ b/hw/xen_common.h
> @@ -7,7 +7,11 @@
>  #include <inttypes.h>
>  
>  #include <xenctrl.h>
> -#include <xs.h>
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
> +#  include <xs.h>
> +#else
> +#  include <xenstore.h>
> +#endif
>  #include <xen/io/xenbus.h>
>  
>  #include "hw.h"

Shouldn't we need the ifdef also in configure?  On my system xenstore.h
still don't exist.

(master *)$ rpm -qa xen-devel
xen-devel-4.1.2-17.fc17.x86_64
(master *)$ ls /usr/include/xs.h 
/usr/include/xs.h
(master *)$ ls /usr/include/xenstore.h
ls: cannot access /usr/include/xenstore.h: No such file or directory
(master *)$ 


Later, Juan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:54:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV64-0005fH-9Z; Fri, 15 Jun 2012 11:53:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quintela@redhat.com>) id 1SfV62-0005f9-KR
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:53:46 +0000
Received: from [85.158.139.83:4761] by server-10.bemta-5.messagelabs.com id
	C5/E5-02190-9422BDF4; Fri, 15 Jun 2012 11:53:45 +0000
X-Env-Sender: quintela@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339761224!27319987!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTMxNDI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6355 invoked from network); 15 Jun 2012 11:53:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	15 Jun 2012 11:53:45 -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 q5FBrfDs006631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 07:53:41 -0400
Received: from localhost (ovpn-116-54.ams2.redhat.com [10.36.116.54])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q5FBrdNu019456; Fri, 15 Jun 2012 07:53:40 -0400
From: Juan Quintela <quintela@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
	(Anthony PERARD's message of "Fri, 15 Jun 2012 12:17:10 +0100")
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
	<1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux)
Date: Fri, 15 Jun 2012 13:53:30 +0200
Message-ID: <87bokkeqpx.fsf@elfo.mitica>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xenstore: Use <xenstore.h>
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: quintela@redhat.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

Anthony PERARD <anthony.perard@citrix.com> wrote:
> In the next release of Xen (4.2), xs.h became deprecated.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  configure       |    2 +-
>  hw/xen_common.h |    6 +++++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index c2366ee..e7f66c9 100755
> --- a/configure
> +++ b/configure
> @@ -1382,7 +1382,7 @@ EOF
>    elif (
>        cat > $TMPC <<EOF
>  #include <xenctrl.h>
> -#include <xs.h>
> +#include <xenstore.h>
>  #include <stdint.h>
>  #include <xen/hvm/hvm_info_table.h>
>  #if !defined(HVM_MAX_VCPUS)
> diff --git a/hw/xen_common.h b/hw/xen_common.h
> index fe7f227..cc99204 100644
> --- a/hw/xen_common.h
> +++ b/hw/xen_common.h
> @@ -7,7 +7,11 @@
>  #include <inttypes.h>
>  
>  #include <xenctrl.h>
> -#include <xs.h>
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
> +#  include <xs.h>
> +#else
> +#  include <xenstore.h>
> +#endif
>  #include <xen/io/xenbus.h>
>  
>  #include "hw.h"

Shouldn't we need the ifdef also in configure?  On my system xenstore.h
still don't exist.

(master *)$ rpm -qa xen-devel
xen-devel-4.1.2-17.fc17.x86_64
(master *)$ ls /usr/include/xs.h 
/usr/include/xs.h
(master *)$ ls /usr/include/xenstore.h
ls: cannot access /usr/include/xenstore.h: No such file or directory
(master *)$ 


Later, Juan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV79-0005rO-6Y; Fri, 15 Jun 2012 11:54:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV73-0005hg-Jh
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:49 +0000
Received: from [193.109.254.147:9483] by server-8.bemta-14.messagelabs.com id
	48/A6-27132-9822BDF4; Fri, 15 Jun 2012 11:54:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10465 invoked from network); 15 Jun 2012 11:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041891"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6S-0005OO-2Q; Fri, 15 Jun 2012 11:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Z4-Tv;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:06 +0100
Message-ID: <1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce prohibition
	on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/gentypes.py      |    1 -
 tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 5 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index ddc2624..c238ac0 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 10d7115..1a32d9e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 36c75ed..6c859bc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1538,10 +1544,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV72-0005jW-A9; Fri, 15 Jun 2012 11:54:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hh-4o
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:19321] by server-7.bemta-14.messagelabs.com id
	70/2B-29165-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10310 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005NZ-33; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xu-RS;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:48 +0100
Message-ID: <1339761246-27641-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/21] libxl: domain save: rename variables etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Preparatory work for making domain suspend asynchronous:

* Rename `struct suspendinfo' to `libxl__domain_suspend_state'
  and move it to libxl_internal.h.

* Rename variables `si' to `dss'.

* Change the stack-allocated state and callbacks from
    struct suspendinfo si;
    struct save_callbacks callbacks;
    struct restore_callbacks callbacks;
  to
    libxl__domain_suspend_state dss[1];
    struct save_callbacks callbacks[1];
    struct restore_callbacks callbacks[1];
  so that it may be referred to as a pointer variable everywhere.

* Rename the variable `flags' (in libxl__domain_suspend_state) to
  `xcflags', to help distinguish it from the other `flags' which is
  passed in from the calling application in libxl_domain_suspend_info.
  Abolish the local variable in libxl__domain_suspend_common, as it
  can use the one in the dss.

* Move the prototypes of suspend-related functions in libxl_internal.h
  to after the definition of the state struct.

* Replace several ctx variables with gc variables and
  consequently references to ctx with CTX.  Change references
  to `dss->gc' in the functional code to simply `gc'.

* Use LOG* rather than LIBXL__LOG* in a number of places.

* In libxl__domain_save_device_model use `rc' instead of `ret'.

* Introduce and use `gc' and `domid' in
  libxl__domain_suspend_common_callback.

* Wrap some long lines.

* Add an extra pair of parens for clarity in a flag test.

* Remove two pointless casts from void* to a struct*.

No functional change whatsoever.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Abolish local variables `xcflags' and `hvm' in
   libxl__domain_suspend_common; just use dss->xcflags and dss->hvm
   instead and hence do not lose some of the changes to xcflags.

Changes in v2:
 * Make callbacks into arrays (for pointerisation) too.
 * Updated to cope with new remus code.
 * Fixed typo in commit message.
---
 tools/libxl/libxl_dom.c      |  261 ++++++++++++++++++++----------------------
 tools/libxl/libxl_internal.h |   30 ++++-
 2 files changed, 151 insertions(+), 140 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 677db1d..e90030d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -470,7 +470,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
-    libxl__gc *gc = (libxl__gc *) data;
+    libxl__gc *gc = data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
     const uint8_t *ptr = buf;
@@ -531,7 +531,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
-    struct restore_callbacks callbacks;
+    struct restore_callbacks callbacks[1];
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -539,8 +539,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks.toolstack_restore = libxl__toolstack_restore;
-        callbacks.data = gc;
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -556,7 +556,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, &callbacks);
+                           &state->vm_generationid_addr, callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -564,33 +564,23 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-struct suspendinfo {
-    libxl__gc *gc;
-    xc_evtchn *xce; /* event channel handle */
-    int suspend_eventchn;
-    int domid;
-    int hvm;
-    unsigned int flags;
-    int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
-    int interval; /* checkpoint interval (for Remus) */
-};
-
-static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
+static int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     char *path;
     bool rc;
 
-    path = libxl__sprintf(si->gc, "/local/domain/0/device-model/%u/logdirty/cmd", domid);
+    path = libxl__sprintf(gc,
+                   "/local/domain/0/device-model/%u/logdirty/cmd", domid);
     if (!path)
         return 1;
 
     if (enable)
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "enable", strlen("enable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
     else
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "disable", strlen("disable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
 
     return rc ? 0 : 1;
 }
@@ -645,53 +635,56 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
 
 static int libxl__domain_suspend_common_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
     int watchdog;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
 
-    if (si->hvm) {
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->hvm) {
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
     }
 
-    if ((hvm_s_state == 0) && (si->suspend_eventchn >= 0)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via event channel",
-                   si->hvm ? "PVHVM" : "PV");
-        ret = xc_evtchn_notify(si->xce, si->suspend_eventchn);
+    if ((hvm_s_state == 0) && (dss->suspend_eventchn >= 0)) {
+        LOG(DEBUG, "issuing %s suspend request via event channel",
+            dss->hvm ? "PVHVM" : "PV");
+        ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_evtchn_notify failed ret=%d", ret);
+            LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
             return 0;
         }
-        ret = xc_await_suspend(ctx->xch, si->xce, si->suspend_eventchn);
+        ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_await_suspend failed ret=%d", ret);
+            LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
             return 0;
         }
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
         goto guest_suspended;
     }
 
-    if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling xc_domain_shutdown on HVM domain");
-        xc_domain_shutdown(ctx->xch, si->domid, SHUTDOWN_suspend);
+    if (dss->hvm && (!hvm_pvdrv || hvm_s_state)) {
+        LOG(DEBUG, "Calling xc_domain_shutdown on HVM domain");
+        xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
         /* The guest does not (need to) respond to this sort of request. */
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
     } else {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
-                   si->hvm ? "PVHVM" : "PV");
+        LOG(DEBUG, "issuing %s suspend request via XenBus control node",
+            dss->hvm ? "PVHVM" : "PV");
 
-        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
+        libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
+        LOG(DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
             if (!state) state = "";
 
             watchdog--;
@@ -707,17 +700,17 @@ static int libxl__domain_suspend_common_callback(void *data)
          * at the last minute.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, cancelling request");
+            LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
         retry_transaction:
-            t = xs_transaction_start(ctx->xsh);
+            t = xs_transaction_start(CTX->xsh);
 
-            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, t, domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
+                libxl__domain_pvcontrol_write(gc, t, domid, "");
 
-            if (!xs_transaction_end(ctx->xsh, t, 0))
+            if (!xs_transaction_end(CTX->xsh, t, 0))
                 if (errno == EAGAIN)
                     goto retry_transaction;
 
@@ -729,27 +722,29 @@ static int libxl__domain_suspend_common_callback(void *data)
          * case we lost the race while cancelling and should continue.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, request cancelled");
+            LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
             return 0;
         }
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest acknowledged suspend request");
-        si->guest_responded = 1;
+        LOG(DEBUG, "guest acknowledged suspend request");
+        dss->guest_responded = 1;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to suspend");
+    LOG(DEBUG, "wait for the guest to suspend");
     watchdog = 60;
     while (watchdog > 0) {
         xc_domaininfo_t info;
 
         usleep(100000);
-        ret = xc_domain_getinfolist(ctx->xch, si->domid, 1, &info);
-        if (ret == 1 && info.domain == si->domid && info.flags & XEN_DOMINF_shutdown) {
+        ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
+        if (ret == 1 && info.domain == domid &&
+            (info.flags & XEN_DOMINF_shutdown)) {
             int shutdown_reason;
 
-            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
+            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+                & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
+                LOG(DEBUG, "guest has suspended");
                 goto guest_suspended;
             }
         }
@@ -757,15 +752,14 @@ static int libxl__domain_suspend_common_callback(void *data)
         watchdog--;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
+    LOG(ERROR, "guest did not suspend");
     return 0;
 
  guest_suspended:
-    if (si->hvm) {
-        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+    if (dss->hvm) {
+        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
         if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
         }
     }
@@ -783,9 +777,8 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
-    struct suspendinfo *si = (struct suspendinfo *) data;
-    libxl__gc *gc = (libxl__gc *) si->gc;
-    libxl_ctx *ctx = gc->owner;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -814,21 +807,21 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         char *xs_path;
         phys_offset = entries[i];
         if (phys_offset == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            LOG(ERROR, "phys_offset %d is NULL", i);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
@@ -864,11 +857,11 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
 
     /* Resumes the domain and the device model */
-    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+    if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
         return 0;
 
     /* TODO: Deal with disk. Start a new network output buffer */
@@ -877,15 +870,15 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
 
     /* This would go into tailbuf. */
-    if (si->hvm &&
-        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+    if (dss->hvm &&
+        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
-    usleep(si->interval * 1000);
+    usleep(dss->interval * 1000);
     return 1;
 }
 
@@ -894,12 +887,10 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  int live, int debug,
                                  const libxl_domain_remus_info *r_info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags;
     int port;
-    struct save_callbacks callbacks;
-    struct suspendinfo si;
-    int hvm, rc = ERROR_FAIL;
+    struct save_callbacks callbacks[1];
+    libxl__domain_suspend_state dss[1];
+    int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
     switch (type) {
@@ -912,82 +903,81 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
         vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
-        hvm = 1;
+        dss->hvm = 1;
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
         vm_generationid_addr = 0;
-        hvm = 0;
+        dss->hvm = 0;
         break;
     default:
         return ERROR_INVAL;
     }
 
-    memset(&si, 0, sizeof(si));
-    flags = (live) ? XCFLAGS_LIVE : 0
+    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
-          | (hvm) ? XCFLAGS_HVM : 0;
+          | (dss->hvm) ? XCFLAGS_HVM : 0;
+
+    dss->domid = domid;
+    dss->gc = gc;
+    dss->suspend_eventchn = -1;
+    dss->guest_responded = 0;
 
     if (r_info != NULL) {
-        si.interval = r_info->interval;
+        dss->interval = r_info->interval;
         if (r_info->compression)
-            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        si.save_fd = fd;
+            dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        dss->save_fd = fd;
     }
     else
-        si.save_fd = -1;
+        dss->save_fd = -1;
 
-    si.domid = domid;
-    si.flags = flags;
-    si.hvm = hvm;
-    si.gc = gc;
-    si.suspend_eventchn = -1;
-    si.guest_responded = 0;
-
-    si.xce = xc_evtchn_open(NULL, 0);
-    if (si.xce == NULL)
+    dss->xce = xc_evtchn_open(NULL, 0);
+    if (dss->xce == NULL)
         goto out;
     else
     {
-        port = xs_suspend_evtchn_port(si.domid);
+        port = xs_suspend_evtchn_port(dss->domid);
 
         if (port >= 0) {
-            si.suspend_eventchn = xc_suspend_evtchn_init(ctx->xch, si.xce, si.domid, port);
+            dss->suspend_eventchn =
+                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
 
-            if (si.suspend_eventchn < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "Suspend event channel initialization failed");
+            if (dss->suspend_eventchn < 0)
+                LOG(WARN, "Suspend event channel initialization failed");
         }
     }
 
-    memset(&callbacks, 0, sizeof(callbacks));
+    memset(callbacks, 0, sizeof(*callbacks));
     if (r_info != NULL) {
-        callbacks.suspend = libxl__remus_domain_suspend_callback;
-        callbacks.postcopy = libxl__remus_domain_resume_callback;
-        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+        callbacks->suspend = libxl__remus_domain_suspend_callback;
+        callbacks->postcopy = libxl__remus_domain_resume_callback;
+        callbacks->checkpoint = libxl__remus_domain_checkpoint_callback;
     } else
-        callbacks.suspend = libxl__domain_suspend_common_callback;
+        callbacks->suspend = libxl__domain_suspend_common_callback;
 
-    callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks.toolstack_save = libxl__toolstack_save;
-    callbacks.data = &si;
+    callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks->toolstack_save = libxl__toolstack_save;
+    callbacks->data = dss;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-                        hvm, vm_generationid_addr);
+    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
+                        dss->hvm, vm_generationid_addr);
     if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
-                         si.guest_responded ?
+        LOGE(ERROR, "saving domain: %s",
+                         dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
-        if ( !si.guest_responded )
+        if ( !dss->guest_responded )
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
     }
 
-    if (si.suspend_eventchn > 0)
-        xc_suspend_evtchn_release(ctx->xch, si.xce, domid, si.suspend_eventchn);
-    if (si.xce != NULL)
-        xc_evtchn_close(si.xce);
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
 
 out:
     return rc;
@@ -995,8 +985,7 @@ out:
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
+    int rc, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -1004,46 +993,46 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 
     if (stat(filename, &st) < 0)
     {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        ret = ERROR_FAIL;
+        LOG(ERROR, "Unable to stat qemu save file\n");
+        rc = ERROR_FAIL;
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
                               "saved-state file", "qemu signature");
-    if (ret)
+    if (rc)
         goto out;
 
-    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (ret)
+    if (rc)
         goto out;
 
     fd2 = open(filename, O_RDONLY);
     if (fd2 < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        LOGE(ERROR, "Unable to open qemu save file\n");
         goto out;
     }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            ret = errno;
+            rc = errno;
             goto out;
         }
-        ret = libxl_write_exactly(
-            ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (ret)
+        rc = libxl_write_exactly(
+            CTX, fd, buf, c, "saved-state file", "qemu state");
+        if (rc)
             goto out;
     }
-    ret = 0;
+    rc = 0;
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return ret;
+    return rc;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..f22bf94 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -786,10 +786,6 @@ _hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                          libxl_domain_build_info *info,
                                          libxl__domain_build_state *state,
                                          int fd);
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1778,6 +1774,23 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Domain suspend (save) state structure -----*/
+
+typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
+
+struct libxl__domain_suspend_state {
+    libxl__gc *gc;
+    xc_evtchn *xce; /* event channel handle */
+    int suspend_eventchn;
+    int domid;
+    int hvm;
+    unsigned int xcflags;
+    int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
+};
+
+
 /*----- openpty -----*/
 
 /*
@@ -1888,6 +1901,15 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
 };
 
+/*----- Domain suspend (save) functions -----*/
+
+_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
+                                         libxl_domain_type type,
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
+
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV71-0005iR-3s; Fri, 15 Jun 2012 11:54:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV6z-0005ha-NA
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:45 +0000
Received: from [193.109.254.147:36048] by server-9.bemta-14.messagelabs.com id
	78/C6-27072-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10248 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6Q-0005NU-Rl; Fri, 15 Jun 2012 11:54:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xq-Ov;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:47 +0100
Message-ID: <1339761246-27641-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/21] libxc: Do not segfault if (e.g.)
	switch_qemu_logdirty 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

In xc_domain_save the local variable `ob' is initialised to NULL.
There are then various startup actions.  Some of these `goto out' on
failure; for example the call to callbacks->switch_qemu_logdirty on
l.978.  However, out is used both by success and error paths.  So it
attempts (l.2043) to flush the current output buffer.  If ob has not
yet been assigned a non-NULL value, this segfaults.  So make the call
to outbuf_flush conditional on ob.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/xc_domain_save.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index fcc7718..c359649 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -2040,7 +2040,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
     }
 
     /* Flush last write and discard cache for file. */
-    if ( outbuf_flush(xch, ob, io_fd) < 0 ) {
+    if ( ob && outbuf_flush(xch, ob, io_fd) < 0 ) {
         PERROR("Error when flushing output buffer");
         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 Fri Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV71-0005iu-I7; Fri, 15 Jun 2012 11:54:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV6z-0005hb-QB
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:36051] by server-4.bemta-14.messagelabs.com id
	96/F0-27598-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10225 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6Q-0005NR-PG; Fri, 15 Jun 2012 11:54:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xg-KB;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:46 +0100
Message-ID: <1339761246-27641-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/21] libxc: xc_domain_restore,
	make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the one provider of this callback, in libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * No longer introduce function pointer typedefs into the libxc API.
---
 tools/libxc/xenguest.h  |    2 +-
 tools/libxl/libxl_dom.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 91d53f7..707e31c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
     /* callback to restore toolstack specific data */
-    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
             uint32_t size, void* data);
 
     /* to be provided as the last argument to each callback function */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 10f8c1f..677db1d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,13 +467,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = (libxl__gc *) data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
-    uint8_t *ptr = buf;
+    const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
     struct libxl__physmap_info* pi;
     char *xs_path;
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV76-0005nc-JY; Fri, 15 Jun 2012 11:54:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hv-Lt
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [193.109.254.147:9163] by server-2.bemta-14.messagelabs.com id
	B6/A8-27740-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10348 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nb-5a; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Y2-3Q;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:50 +0100
Message-ID: <1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
	asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the internal and external APIs for domain save (suspend) to be
capable of asynchronous operation.  The implementation remains
synchronous.  The interfaces surrounding device model saving are still
synchronous.

Public API changes:

 * libxl_domain_save takes an ao_how.

 * libxl_domain_remus_start takes an ao_how.  If the
   libxl_domain_remus_info is NULL, we abort rather than returning an
   error.

 * The `suspend_callback' function passed to libxl_domain_save is
   never called by the existing implementation in libxl.  Abolish it.

 * libxl_domain_save takes its flags parameter as an argument.
   Thus libxl_domain_suspend_info is abolished.

 * XL_SUSPEND_* flags renamed to LIBXL_SAVE_*.

 * Callers in xl updated.

Internal code restructuring:

 * libxl__domain_suspend_state member types and names rationalised.

 * libxl__domain_suspend renamed from libxl__domain_suspend_common.
   (_common here actually meant "internal function").

 * libxl__domain_suspend takes a libxl__domain_suspend_state, which
   where the parameters to the operation are filled in by the caller.

 * xc_domain_save is now called via libxl__xc_domain_save which can
   itself become asynchronous.

 * Consequently, libxl__domain_suspend is split into two functions at
   the callback boundary; the second half is
   libxl__xc_domain_save_done.

 * libxl__domain_save_device_model is now called by the actual
   implementation rather than by the public wrapper.  It is already in
   its proper place in the domain save execution sequence.  So
   officially make it part of that execution sequence, renaming it to
   domain_save_device_model.

 * Effectively, rewrite the public wrapper functions
   libxl_domain_suspend and libxl_domain_remus_start.

 * Remove a needless #include <xenctrl.h>

 * libxl__domain_suspend aborts on unexpected domain types rather
   than mysteriously returning EINVAL.

 * struct save_callbacks moved from the stack to the dss.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v4:
 * libxl_domain_suspend now handles error from libxl__domain_type
   in the correct way.  (Hunk brought forward from domain type
   fixup patch.)
 * Comment clarifies that libxl__domain_suspend calls dss->callback
   when done.

Changes in v3:
 * Remove `hvm' and `xcflags' args to libxl__xc_domain_save.  Instead,
   just use the values from the dss.

Changes in v2:
 * Move save_callbacks too.
 * Merge with Remus changes.
 * Improvements to commit message.
 * Do not rename libxl_domain_suspend any more.
---
 tools/libxl/libxl.c              |   94 +++++++++++++++++++++---------
 tools/libxl/libxl.h              |   22 ++++----
 tools/libxl/libxl_dom.c          |  121 +++++++++++++++++++++++++++-----------
 tools/libxl/libxl_internal.h     |   45 ++++++++++++---
 tools/libxl/libxl_save_callout.c |   11 ++++
 tools/libxl/xl_cmdimpl.c         |    9 +--
 6 files changed, 214 insertions(+), 88 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..f7fcf1b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
     return ptr;
 }
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc);
+
 /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd)
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    libxl_domain_type type = libxl__domain_type(gc, domid);
-    int rc = 0;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_suspend_state *dss;
+    int rc;
 
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
-        goto remus_fail;
+        goto out;
     }
 
-    if (info == NULL) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "No remus_info structure supplied for domain %d", domid);
-        rc = ERROR_INVAL;
-        goto remus_fail;
-    }
+    GCNEW(dss);
+    dss->ao = ao;
+    dss->callback = remus_crashed_cb;
+    dss->domid = domid;
+    dss->fd = send_fd;
+    /* TODO do something with recv_fd */
+    dss->type = type;
+    dss->live = 1;
+    dss->debug = 0;
+    dss->remus = info;
+
+    assert(info);
 
     /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
 
     /* Point of no return */
-    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
-                                      /* debug */ 0, info);
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out:
+    return AO_ABORT(rc);
+}
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
     /*
      * With Remus, if we reach this point, it means either
      * backup died or some network error occurred preventing us
@@ -683,27 +702,46 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
     /* TBD: Remus cleanup - i.e. detach qdisc, release other
      * resources.
      */
- remus_fail:
-    GC_FREE;
-    return rc;
+    libxl__ao_complete(egc, ao, rc);
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                         uint32_t domid, int fd)
+static void domain_suspend_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
 {
-    GC_INIT(ctx);
+    STATE_AO_GC(dss->ao);
+    libxl__ao_complete(egc,ao,rc);
+
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    int rc;
+
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
-    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
-    int rc = 0;
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out_err;
+    }
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
-                                      /* No Remus */ NULL);
+    libxl__domain_suspend_state *dss;
+    GCNEW(dss);
 
-    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(gc, domid, fd);
-    GC_FREE;
-    return rc;
+    dss->ao = ao;
+    dss->callback = domain_suspend_cb;
+
+    dss->domid = domid;
+    dss->fd = fd;
+    dss->type = type;
+    dss->live = flags & LIBXL_SUSPEND_LIVE;
+    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out_err:
+    return AO_ABORT(rc);
 }
 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..10d7115 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
 
-typedef struct {
-#define XL_SUSPEND_DEBUG 1
-#define XL_SUSPEND_LIVE 2
-    int flags;
-    int (*suspend_callback)(void *, int);
-} libxl_domain_suspend_info;
-
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
@@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
-int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd);
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                          uint32_t domid, int fd);
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_asyncop_how *ao_how);
+#define LIBXL_SUSPEND_DEBUG 1
+#define LIBXL_SUSPEND_LIVE 2
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
  *   must support this.
  */
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
+
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how);
+
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1d4e809..b48452c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -17,13 +17,11 @@
 
 #include <glob.h>
 
-#include <xenctrl.h>
-#include <xc_dom.h>
+#include "libxl_internal.h"
 
+#include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl_internal.h"
-
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -521,11 +519,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-static int libxl__domain_suspend_common_switch_qemu_logdirty
+/*==================== Domain suspend (save) ====================*/
+
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc);
+
+/*----- callbacks, called by xc_domain_save -----*/
+
+int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
 
@@ -590,10 +595,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
@@ -714,7 +719,7 @@ static int libxl__domain_suspend_common_callback(void *data)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss->domid);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -731,11 +736,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -806,6 +811,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
     return 0;
 }
 
+/*----- remus callbacks -----*/
+
 static int libxl__remus_domain_suspend_callback(void *data)
 {
     /* TODO: Issue disk and network checkpoint reqs. */
@@ -815,7 +822,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
 static int libxl__remus_domain_resume_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
     if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
@@ -828,10 +835,11 @@ static int libxl__remus_domain_resume_callback(void *data)
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
     if (dss->hvm &&
-        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
+        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
@@ -839,17 +847,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
     return 1;
 }
 
-int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                 libxl_domain_type type,
-                                 int live, int debug,
-                                 const libxl_domain_remus_info *r_info)
+/*----- main code for suspending, in order of execution -----*/
+
+void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 {
+    STATE_AO_GC(dss->ao);
     int port;
-    struct save_callbacks callbacks[1];
-    libxl__domain_suspend_state dss[1];
     int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+    const libxl_domain_type type = dss->type;
+    const int live = dss->live;
+    const int debug = dss->debug;
+    const libxl_domain_remus_info *const r_info = dss->remus;
+    struct save_callbacks *const callbacks = &dss->callbacks;
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
@@ -868,15 +882,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->hvm = 0;
         break;
     default:
-        return ERROR_INVAL;
+        abort();
     }
 
     dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (dss->hvm) ? XCFLAGS_HVM : 0;
 
-    dss->domid = domid;
-    dss->gc = gc;
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
 
@@ -884,10 +896,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->interval = r_info->interval;
         if (r_info->compression)
             dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        dss->save_fd = fd;
     }
-    else
-        dss->save_fd = -1;
 
     dss->xce = xc_evtchn_open(NULL, 0);
     if (dss->xce == NULL)
@@ -917,10 +926,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     callbacks->toolstack_save = libxl__toolstack_save;
     callbacks->data = dss;
 
-    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
-                        dss->hvm, vm_generationid_addr);
-    if ( rc ) {
-        LOGE(ERROR, "saving domain: %s",
+    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
+    return;
+
+ out:
+    domain_suspend_done(egc, dss, rc);
+}
+
+void libxl__xc_domain_save_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss,
+                                int rc, int retval, int errnoval)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const libxl_domain_type type = dss->type;
+    const uint32_t domid = dss->domid;
+
+    if (rc)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "saving domain: %s",
                          dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
@@ -928,16 +955,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
+        goto out;
     }
 
-    if (dss->suspend_eventchn > 0)
-        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                                  dss->suspend_eventchn);
-    if (dss->xce != NULL)
-        xc_evtchn_close(dss->xce);
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, domid);
+        if (rc) goto out;
+        
+        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
+        if (rc) goto out;
+    }
+
+    rc = 0;
 
 out:
-    return rc;
+    domain_suspend_done(egc, dss, rc);
 }
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
@@ -992,6 +1024,25 @@ out:
     return rc;
 }
 
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
+
+    dss->callback(egc, dss, rc);
+}
+
+/*==================== Miscellaneous ====================*/
+
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
     char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 28478ea..7cf1b04 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
+typedef void libxl__domain_suspend_cb(libxl__egc*,
+                                      libxl__domain_suspend_state*, int rc);
+
 struct libxl__domain_suspend_state {
-    libxl__gc *gc;
+    /* set by caller of libxl__domain_suspend */
+    libxl__ao *ao;
+    libxl__domain_suspend_cb *callback;
+
+    uint32_t domid;
+    int fd;
+    libxl_domain_type type;
+    int live;
+    int debug;
+    const libxl_domain_remus_info *remus;
+    /* private */
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
-    int domid;
     int hvm;
-    unsigned int xcflags;
+    int xcflags;
     int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
     int interval; /* checkpoint interval (for Remus) */
+    struct save_callbacks callbacks;
 };
 
 
@@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
 
 /*----- Domain suspend (save) functions -----*/
 
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
+/* calls dss->callback when done */
+_hidden void libxl__domain_suspend(libxl__egc *egc,
+                                   libxl__domain_suspend_state *dss);
+
+
+/* calls libxl__xc_domain_suspend_done when done */
+_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
+                                   unsigned long vm_generationid_addr);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_save_done(libxl__egc*,
+                                        libxl__domain_suspend_state*,
+                                        int rc, int retval, int errnoval);
+
+_hidden int libxl__domain_suspend_common_callback(void *data);
+_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data);
+_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data);
+
 
 /* calls libxl__xc_domain_restore_done when done */
 _hidden void libxl__xc_domain_restore(libxl__egc *egc,
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 2f8db9f..1b481ab 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               &state->vm_generationid_addr, &dcs->callbacks);
     libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
 }
+
+void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
+                           unsigned long vm_generationid_addr)
+{
+    STATE_AO_GC(dss->ao);
+    int r;
+
+    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
+                       &dss->callbacks, dss->hvm, vm_generationid_addr);
+    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3ea95ef..19daa1c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
+    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
@@ -3008,7 +3008,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     pid_t child = -1;
     int rc;
     int send_fd = -1, recv_fd = -1;
-    libxl_domain_suspend_info suspinfo;
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
@@ -3030,9 +3029,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    memset(&suspinfo, 0, sizeof(suspinfo));
-    suspinfo.flags |= XL_SUSPEND_LIVE;
-    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
+    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -6604,7 +6601,7 @@ int main_remus(int argc, char **argv)
     }
 
     /* Point of no return */
-    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
 
     /* If we are here, it means backup has failed/domain suspend failed.
      * Try to resume the domain and exit gracefully.
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV71-0005iu-I7; Fri, 15 Jun 2012 11:54:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV6z-0005hb-QB
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:36051] by server-4.bemta-14.messagelabs.com id
	96/F0-27598-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10225 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6Q-0005NR-PG; Fri, 15 Jun 2012 11:54:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xg-KB;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:46 +0100
Message-ID: <1339761246-27641-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/21] libxc: xc_domain_restore,
	make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the one provider of this callback, in libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * No longer introduce function pointer typedefs into the libxc API.
---
 tools/libxc/xenguest.h  |    2 +-
 tools/libxl/libxl_dom.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 91d53f7..707e31c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
     /* callback to restore toolstack specific data */
-    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
             uint32_t size, void* data);
 
     /* to be provided as the last argument to each callback function */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 10f8c1f..677db1d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,13 +467,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = (libxl__gc *) data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
-    uint8_t *ptr = buf;
+    const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
     struct libxl__physmap_info* pi;
     char *xs_path;
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV71-0005iR-3s; Fri, 15 Jun 2012 11:54:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV6z-0005ha-NA
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:45 +0000
Received: from [193.109.254.147:36048] by server-9.bemta-14.messagelabs.com id
	78/C6-27072-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10248 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6Q-0005NU-Rl; Fri, 15 Jun 2012 11:54:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xq-Ov;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:47 +0100
Message-ID: <1339761246-27641-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/21] libxc: Do not segfault if (e.g.)
	switch_qemu_logdirty 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

In xc_domain_save the local variable `ob' is initialised to NULL.
There are then various startup actions.  Some of these `goto out' on
failure; for example the call to callbacks->switch_qemu_logdirty on
l.978.  However, out is used both by success and error paths.  So it
attempts (l.2043) to flush the current output buffer.  If ob has not
yet been assigned a non-NULL value, this segfaults.  So make the call
to outbuf_flush conditional on ob.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/xc_domain_save.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index fcc7718..c359649 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -2040,7 +2040,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
     }
 
     /* Flush last write and discard cache for file. */
-    if ( outbuf_flush(xch, ob, io_fd) < 0 ) {
+    if ( ob && outbuf_flush(xch, ob, io_fd) < 0 ) {
         PERROR("Error when flushing output buffer");
         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 Fri Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV72-0005jW-A9; Fri, 15 Jun 2012 11:54:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hh-4o
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:19321] by server-7.bemta-14.messagelabs.com id
	70/2B-29165-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10310 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005NZ-33; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xu-RS;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:48 +0100
Message-ID: <1339761246-27641-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/21] libxl: domain save: rename variables etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Preparatory work for making domain suspend asynchronous:

* Rename `struct suspendinfo' to `libxl__domain_suspend_state'
  and move it to libxl_internal.h.

* Rename variables `si' to `dss'.

* Change the stack-allocated state and callbacks from
    struct suspendinfo si;
    struct save_callbacks callbacks;
    struct restore_callbacks callbacks;
  to
    libxl__domain_suspend_state dss[1];
    struct save_callbacks callbacks[1];
    struct restore_callbacks callbacks[1];
  so that it may be referred to as a pointer variable everywhere.

* Rename the variable `flags' (in libxl__domain_suspend_state) to
  `xcflags', to help distinguish it from the other `flags' which is
  passed in from the calling application in libxl_domain_suspend_info.
  Abolish the local variable in libxl__domain_suspend_common, as it
  can use the one in the dss.

* Move the prototypes of suspend-related functions in libxl_internal.h
  to after the definition of the state struct.

* Replace several ctx variables with gc variables and
  consequently references to ctx with CTX.  Change references
  to `dss->gc' in the functional code to simply `gc'.

* Use LOG* rather than LIBXL__LOG* in a number of places.

* In libxl__domain_save_device_model use `rc' instead of `ret'.

* Introduce and use `gc' and `domid' in
  libxl__domain_suspend_common_callback.

* Wrap some long lines.

* Add an extra pair of parens for clarity in a flag test.

* Remove two pointless casts from void* to a struct*.

No functional change whatsoever.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Abolish local variables `xcflags' and `hvm' in
   libxl__domain_suspend_common; just use dss->xcflags and dss->hvm
   instead and hence do not lose some of the changes to xcflags.

Changes in v2:
 * Make callbacks into arrays (for pointerisation) too.
 * Updated to cope with new remus code.
 * Fixed typo in commit message.
---
 tools/libxl/libxl_dom.c      |  261 ++++++++++++++++++++----------------------
 tools/libxl/libxl_internal.h |   30 ++++-
 2 files changed, 151 insertions(+), 140 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 677db1d..e90030d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -470,7 +470,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
-    libxl__gc *gc = (libxl__gc *) data;
+    libxl__gc *gc = data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
     const uint8_t *ptr = buf;
@@ -531,7 +531,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
-    struct restore_callbacks callbacks;
+    struct restore_callbacks callbacks[1];
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -539,8 +539,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks.toolstack_restore = libxl__toolstack_restore;
-        callbacks.data = gc;
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -556,7 +556,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, &callbacks);
+                           &state->vm_generationid_addr, callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -564,33 +564,23 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-struct suspendinfo {
-    libxl__gc *gc;
-    xc_evtchn *xce; /* event channel handle */
-    int suspend_eventchn;
-    int domid;
-    int hvm;
-    unsigned int flags;
-    int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
-    int interval; /* checkpoint interval (for Remus) */
-};
-
-static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
+static int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     char *path;
     bool rc;
 
-    path = libxl__sprintf(si->gc, "/local/domain/0/device-model/%u/logdirty/cmd", domid);
+    path = libxl__sprintf(gc,
+                   "/local/domain/0/device-model/%u/logdirty/cmd", domid);
     if (!path)
         return 1;
 
     if (enable)
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "enable", strlen("enable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
     else
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "disable", strlen("disable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
 
     return rc ? 0 : 1;
 }
@@ -645,53 +635,56 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
 
 static int libxl__domain_suspend_common_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
     int watchdog;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
 
-    if (si->hvm) {
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->hvm) {
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
     }
 
-    if ((hvm_s_state == 0) && (si->suspend_eventchn >= 0)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via event channel",
-                   si->hvm ? "PVHVM" : "PV");
-        ret = xc_evtchn_notify(si->xce, si->suspend_eventchn);
+    if ((hvm_s_state == 0) && (dss->suspend_eventchn >= 0)) {
+        LOG(DEBUG, "issuing %s suspend request via event channel",
+            dss->hvm ? "PVHVM" : "PV");
+        ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_evtchn_notify failed ret=%d", ret);
+            LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
             return 0;
         }
-        ret = xc_await_suspend(ctx->xch, si->xce, si->suspend_eventchn);
+        ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_await_suspend failed ret=%d", ret);
+            LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
             return 0;
         }
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
         goto guest_suspended;
     }
 
-    if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling xc_domain_shutdown on HVM domain");
-        xc_domain_shutdown(ctx->xch, si->domid, SHUTDOWN_suspend);
+    if (dss->hvm && (!hvm_pvdrv || hvm_s_state)) {
+        LOG(DEBUG, "Calling xc_domain_shutdown on HVM domain");
+        xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
         /* The guest does not (need to) respond to this sort of request. */
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
     } else {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
-                   si->hvm ? "PVHVM" : "PV");
+        LOG(DEBUG, "issuing %s suspend request via XenBus control node",
+            dss->hvm ? "PVHVM" : "PV");
 
-        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
+        libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
+        LOG(DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
             if (!state) state = "";
 
             watchdog--;
@@ -707,17 +700,17 @@ static int libxl__domain_suspend_common_callback(void *data)
          * at the last minute.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, cancelling request");
+            LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
         retry_transaction:
-            t = xs_transaction_start(ctx->xsh);
+            t = xs_transaction_start(CTX->xsh);
 
-            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, t, domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
+                libxl__domain_pvcontrol_write(gc, t, domid, "");
 
-            if (!xs_transaction_end(ctx->xsh, t, 0))
+            if (!xs_transaction_end(CTX->xsh, t, 0))
                 if (errno == EAGAIN)
                     goto retry_transaction;
 
@@ -729,27 +722,29 @@ static int libxl__domain_suspend_common_callback(void *data)
          * case we lost the race while cancelling and should continue.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, request cancelled");
+            LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
             return 0;
         }
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest acknowledged suspend request");
-        si->guest_responded = 1;
+        LOG(DEBUG, "guest acknowledged suspend request");
+        dss->guest_responded = 1;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to suspend");
+    LOG(DEBUG, "wait for the guest to suspend");
     watchdog = 60;
     while (watchdog > 0) {
         xc_domaininfo_t info;
 
         usleep(100000);
-        ret = xc_domain_getinfolist(ctx->xch, si->domid, 1, &info);
-        if (ret == 1 && info.domain == si->domid && info.flags & XEN_DOMINF_shutdown) {
+        ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
+        if (ret == 1 && info.domain == domid &&
+            (info.flags & XEN_DOMINF_shutdown)) {
             int shutdown_reason;
 
-            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
+            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+                & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
+                LOG(DEBUG, "guest has suspended");
                 goto guest_suspended;
             }
         }
@@ -757,15 +752,14 @@ static int libxl__domain_suspend_common_callback(void *data)
         watchdog--;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
+    LOG(ERROR, "guest did not suspend");
     return 0;
 
  guest_suspended:
-    if (si->hvm) {
-        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+    if (dss->hvm) {
+        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
         if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
         }
     }
@@ -783,9 +777,8 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
-    struct suspendinfo *si = (struct suspendinfo *) data;
-    libxl__gc *gc = (libxl__gc *) si->gc;
-    libxl_ctx *ctx = gc->owner;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -814,21 +807,21 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         char *xs_path;
         phys_offset = entries[i];
         if (phys_offset == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            LOG(ERROR, "phys_offset %d is NULL", i);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
@@ -864,11 +857,11 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
 
     /* Resumes the domain and the device model */
-    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+    if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
         return 0;
 
     /* TODO: Deal with disk. Start a new network output buffer */
@@ -877,15 +870,15 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
 
     /* This would go into tailbuf. */
-    if (si->hvm &&
-        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+    if (dss->hvm &&
+        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
-    usleep(si->interval * 1000);
+    usleep(dss->interval * 1000);
     return 1;
 }
 
@@ -894,12 +887,10 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  int live, int debug,
                                  const libxl_domain_remus_info *r_info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags;
     int port;
-    struct save_callbacks callbacks;
-    struct suspendinfo si;
-    int hvm, rc = ERROR_FAIL;
+    struct save_callbacks callbacks[1];
+    libxl__domain_suspend_state dss[1];
+    int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
     switch (type) {
@@ -912,82 +903,81 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
         vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
-        hvm = 1;
+        dss->hvm = 1;
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
         vm_generationid_addr = 0;
-        hvm = 0;
+        dss->hvm = 0;
         break;
     default:
         return ERROR_INVAL;
     }
 
-    memset(&si, 0, sizeof(si));
-    flags = (live) ? XCFLAGS_LIVE : 0
+    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
-          | (hvm) ? XCFLAGS_HVM : 0;
+          | (dss->hvm) ? XCFLAGS_HVM : 0;
+
+    dss->domid = domid;
+    dss->gc = gc;
+    dss->suspend_eventchn = -1;
+    dss->guest_responded = 0;
 
     if (r_info != NULL) {
-        si.interval = r_info->interval;
+        dss->interval = r_info->interval;
         if (r_info->compression)
-            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        si.save_fd = fd;
+            dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        dss->save_fd = fd;
     }
     else
-        si.save_fd = -1;
+        dss->save_fd = -1;
 
-    si.domid = domid;
-    si.flags = flags;
-    si.hvm = hvm;
-    si.gc = gc;
-    si.suspend_eventchn = -1;
-    si.guest_responded = 0;
-
-    si.xce = xc_evtchn_open(NULL, 0);
-    if (si.xce == NULL)
+    dss->xce = xc_evtchn_open(NULL, 0);
+    if (dss->xce == NULL)
         goto out;
     else
     {
-        port = xs_suspend_evtchn_port(si.domid);
+        port = xs_suspend_evtchn_port(dss->domid);
 
         if (port >= 0) {
-            si.suspend_eventchn = xc_suspend_evtchn_init(ctx->xch, si.xce, si.domid, port);
+            dss->suspend_eventchn =
+                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
 
-            if (si.suspend_eventchn < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "Suspend event channel initialization failed");
+            if (dss->suspend_eventchn < 0)
+                LOG(WARN, "Suspend event channel initialization failed");
         }
     }
 
-    memset(&callbacks, 0, sizeof(callbacks));
+    memset(callbacks, 0, sizeof(*callbacks));
     if (r_info != NULL) {
-        callbacks.suspend = libxl__remus_domain_suspend_callback;
-        callbacks.postcopy = libxl__remus_domain_resume_callback;
-        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+        callbacks->suspend = libxl__remus_domain_suspend_callback;
+        callbacks->postcopy = libxl__remus_domain_resume_callback;
+        callbacks->checkpoint = libxl__remus_domain_checkpoint_callback;
     } else
-        callbacks.suspend = libxl__domain_suspend_common_callback;
+        callbacks->suspend = libxl__domain_suspend_common_callback;
 
-    callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks.toolstack_save = libxl__toolstack_save;
-    callbacks.data = &si;
+    callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks->toolstack_save = libxl__toolstack_save;
+    callbacks->data = dss;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-                        hvm, vm_generationid_addr);
+    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
+                        dss->hvm, vm_generationid_addr);
     if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
-                         si.guest_responded ?
+        LOGE(ERROR, "saving domain: %s",
+                         dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
-        if ( !si.guest_responded )
+        if ( !dss->guest_responded )
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
     }
 
-    if (si.suspend_eventchn > 0)
-        xc_suspend_evtchn_release(ctx->xch, si.xce, domid, si.suspend_eventchn);
-    if (si.xce != NULL)
-        xc_evtchn_close(si.xce);
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
 
 out:
     return rc;
@@ -995,8 +985,7 @@ out:
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
+    int rc, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -1004,46 +993,46 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 
     if (stat(filename, &st) < 0)
     {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        ret = ERROR_FAIL;
+        LOG(ERROR, "Unable to stat qemu save file\n");
+        rc = ERROR_FAIL;
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
                               "saved-state file", "qemu signature");
-    if (ret)
+    if (rc)
         goto out;
 
-    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (ret)
+    if (rc)
         goto out;
 
     fd2 = open(filename, O_RDONLY);
     if (fd2 < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        LOGE(ERROR, "Unable to open qemu save file\n");
         goto out;
     }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            ret = errno;
+            rc = errno;
             goto out;
         }
-        ret = libxl_write_exactly(
-            ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (ret)
+        rc = libxl_write_exactly(
+            CTX, fd, buf, c, "saved-state file", "qemu state");
+        if (rc)
             goto out;
     }
-    ret = 0;
+    rc = 0;
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return ret;
+    return rc;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..f22bf94 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -786,10 +786,6 @@ _hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                          libxl_domain_build_info *info,
                                          libxl__domain_build_state *state,
                                          int fd);
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1778,6 +1774,23 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Domain suspend (save) state structure -----*/
+
+typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
+
+struct libxl__domain_suspend_state {
+    libxl__gc *gc;
+    xc_evtchn *xce; /* event channel handle */
+    int suspend_eventchn;
+    int domid;
+    int hvm;
+    unsigned int xcflags;
+    int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
+};
+
+
 /*----- openpty -----*/
 
 /*
@@ -1888,6 +1901,15 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
 };
 
+/*----- Domain suspend (save) functions -----*/
+
+_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
+                                         libxl_domain_type type,
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
+
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV7A-0005sc-06; Fri, 15 Jun 2012 11:54:56 +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 1SfV76-0005mH-23
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:52 +0000
Received: from [193.109.254.147:19701] by server-10.bemta-14.messagelabs.com
	id B0/0A-25709-B822BDF4; Fri, 15 Jun 2012 11:54:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10664 invoked from network); 15 Jun 2012 11:54:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O9-PR; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yr-Nc;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:03 +0100
Message-ID: <1339761246-27641-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/21] libxl: do not leak spawned middle children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn would, when libxl__spawn_detach was called, make
the spawn become idle immediately.  However it still has a child
process which needs to be waited for: the `detachable' spawned
child.

This is wrong because the ultimate in-libxl caller may return to the
application, with a child process still forked but not reaped libxl
contrary to the documented behaviour of libxl.

Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
which is asynchronous.  The detachable spawned children are abolished;
instead, we defer calling back to the in-libxl user until the middle
child has been reaped.

Also, remove erroneous comment suggesting that `death' callback
parameter to libxl__ev_child_fork may be NULL.  It may not, and there
are no callers which pass NULL.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Clarify semantics of sub-states of Attached.
 * Fix reference to `Failing' sub-state in comment to `Failed'.

Changes in v3 of series:
 * Now also remove erroneous comment about NULL fork death callback.
---
 tools/libxl/libxl_dm.c       |   14 ++++-
 tools/libxl/libxl_exec.c     |  130 +++++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h |   43 +++++++-------
 3 files changed, 110 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..b3de145 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -908,6 +908,8 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
 static void device_model_startup_failed(libxl__egc *egc,
                                         libxl__spawn_state *spawn);
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn);
 
 /* our "next step" function, called from those callbacks and elsewhere */
 static void device_model_spawn_outcome(libxl__egc *egc,
@@ -1015,6 +1017,7 @@ retry_transaction:
     spawn->midproc_cb = libxl__spawn_record_pid;
     spawn->confirm_cb = device_model_confirm;
     spawn->failure_cb = device_model_startup_failed;
+    spawn->detached_cb = device_model_detached;
 
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
@@ -1048,9 +1051,7 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
     if (strcmp(xsdata, "running"))
         return;
 
-    libxl__spawn_detach(gc, spawn);
-
-    device_model_spawn_outcome(egc, dmss, 0);
+    libxl__spawn_initiate_detach(gc, spawn);
 }
 
 static void device_model_startup_failed(libxl__egc *egc,
@@ -1060,6 +1061,13 @@ static void device_model_startup_failed(libxl__egc *egc,
     device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
 }
 
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, 0);
+}
+
 static void device_model_spawn_outcome(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index cfa379c..0477386 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -238,15 +238,22 @@ err:
 /*
  * Full set of possible states of a libxl__spawn_state and its _detachable:
  *
- *               ss->        ss->        ss->    | ssd->       ssd->
- *               timeout     xswatch     ssd     |  mid         ss
- *  - Undefined   undef       undef       no     |  -           -
- *  - Idle        Idle        Idle        no     |  -           -
- *  - Active      Active      Active      yes    |  Active      yes
- *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
- *  - Detached    -           -           -      |  Active      no
+ *                   detaching failed  mid     timeout      xswatch          
+ *  - Undefined         undef   undef   -        undef        undef
+ *  - Idle              any     any     Idle     Idle         Idle
+ *  - Attached OK       0       0       Active   Active       Active
+ *  - Attached Failed   0       1       Active   Idle         Idle
+ *  - Detaching         1       maybe   Active   Idle         Idle
+ *  - Partial           any     any     Idle     Active/Idle  Active/Idle
  *
- * When in state Detached, the middle process has been sent a SIGKILL.
+ * When in states Detaching or Attached Failed, the middle process has
+ * been sent a SIGKILL.
+ *
+ * The difference between Attached OK and Attached Failed is not
+ * directly visible to callers - callers see these two the same,
+ * although of course Attached OK will hopefully eventually result in
+ * a call to detached_cb, whereas Attached Failed will end up
+ * in a call to failure_cb.
  */
 
 /* Event callbacks. */
@@ -257,19 +264,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status);
 
-/* Precondition: Partial.  Results: Detached. */
+/* Precondition: Partial.  Results: Idle. */
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-/* Precondition: Partial; caller has logged failure reason.
- * Results: Caller notified of failure;
- *  after return, ss may be completely invalid as caller may reuse it */
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
+/* Precondition: Attached or Detaching; caller has logged failure reason.
+ * Results: Detaching, or Attached Failed */
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss);
 
 void libxl__spawn_init(libxl__spawn_state *ss)
 {
+    libxl__ev_child_init(&ss->mid);
     libxl__ev_time_init(&ss->timeout);
     libxl__ev_xswatch_init(&ss->xswatch);
-    ss->ssd = 0;
 }
 
 int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -280,8 +286,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
-    libxl__ev_child_init(&ss->ssd->mid);
+    ss->failed = ss->detaching = 0;
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
                                      spawn_timeout, ss->timeout_ms);
@@ -291,7 +296,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
                                     spawn_watch_event, ss->xspath);
     if (rc) goto out_err;
 
-    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    pid_t middle = libxl__ev_child_fork(gc, &ss->mid, spawn_middle_death);
     if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
 
     if (middle) {
@@ -344,54 +349,64 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
+    assert(!libxl__ev_child_inuse(&ss->mid));
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+}
+
+static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+/* Precondition: Attached or Detaching, but caller must have just set
+ * at least one of detaching or failed.
+ * Results: Detaching or Attached Failed */
+{
     int r;
 
+    assert(libxl__ev_child_inuse(&ss->mid));
     libxl__ev_time_deregister(gc, &ss->timeout);
     libxl__ev_xswatch_deregister(gc, &ss->xswatch);
 
-    libxl__spawn_state_detachable *ssd = ss->ssd;
-    if (ssd) {
-        if (libxl__ev_child_inuse(&ssd->mid)) {
-            pid_t child = ssd->mid.pid;
-            r = kill(child, SIGKILL);
-            if (r && errno != ESRCH)
-                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
-                     ss->what, (unsigned long)child);
-        }
+    pid_t child = ss->mid.pid;
+    r = kill(child, SIGKILL);
+    if (r && errno != ESRCH)
+        LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+             ss->what, (unsigned long)child);
+}
 
-        /* disconnect the ss and ssd from each other */
-        ssd->ss = 0;
-        ss->ssd = 0;
-    }
+void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    ss->detaching = 1;
+    spawn_detach(gc, ss);
 }
 
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss)
+/* Caller must have logged.  Must be last thing in calling function,
+ * as it may make the callback.  Precondition: Attached or Detaching. */
 {
     EGC_GC;
-    spawn_cleanup(gc, ss);
-    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+    ss->failed = 1;
+    spawn_detach(gc, ss);
 }
 
 static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
                           const struct timeval *requested_abs)
 {
-    /* Before event, was Active; is now Partial. */
+    /* Before event, was Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
     LOG(ERROR, "%s: startup timed out", ss->what);
-    spawn_failed(egc, ss); /* must be last */
+    spawn_fail(egc, ss); /* must be last */
 }
 
 static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
                               const char *watch_path, const char *event_path)
 {
-    /* On entry, is Active. */
+    /* On entry, is Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
     char *p = libxl__xs_read(gc, 0, ss->xspath);
     if (!p && errno != ENOENT) {
         LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
-        spawn_failed(egc, ss); /* must be last */
+        spawn_fail(egc, ss); /* must be last */
         return;
     }
     ss->confirm_cb(egc, ss, p); /* must be last */
@@ -399,20 +414,22 @@ static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
 
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status)
-    /* Before event, was Active or Detached;
-     * is now Active or Detached except that ssd->mid is Idle */
+    /* On entry, is Attached or Detaching */
 {
     EGC_GC;
-    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
-    libxl__spawn_state *ss = ssd->ss;
-
-    if (!WIFEXITED(status)) {
+    libxl__spawn_state *ss = CONTAINER_OF(childw, *ss, mid);
+
+    if ((ss->failed || ss->detaching) &&
+        ((WIFEXITED(status) && WEXITSTATUS(status)==0) ||
+         (WIFSIGNALED(status) && WTERMSIG(status)==SIGKILL))) {
+        /* as expected */
+    } else if (!WIFEXITED(status)) {
+        int loglevel = ss->detaching ? XTL_WARN : XTL_ERROR;
         const char *what =
-            GCSPRINTF("%s intermediate process (startup monitor)",
-                      ss ? ss->what : "(detached)");
-        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+            GCSPRINTF("%s intermediate process (startup monitor)", ss->what);
         libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
-    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        ss->failed = 1;
+    } else {
         if (!status)
             LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
                 " when we were waiting for it to confirm startup",
@@ -430,15 +447,22 @@ static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                 LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
                     " signal number %d", ss->what, (unsigned long)pid, sig);
         }
-        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
-        spawn_failed(egc, ss); /* must be last use of ss */
+        ss->failed = 1;
     }
-    free(ssd);
-}
 
-void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
-{
     spawn_cleanup(gc, ss);
+
+    if (ss->failed && !ss->detaching) {
+        ss->failure_cb(egc, ss); /* must be last */
+        return;
+    }
+    
+    if (ss->failed && ss->detaching)
+        LOG(WARN,"%s underlying machinery seemed to fail,"
+            " but its function seems to have been successful", ss->what);
+
+    assert(ss->detaching);
+    ss->detached_cb(egc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 85f4bc6..9df0db5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -690,8 +690,7 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
  * the libxl event machinery.
  *
  * The parent may signal the child but it must not reap it.  That will
- * be done by the event machinery.  death may be NULL in which case
- * the child is still reaped but its death is ignored.
+ * be done by the event machinery.
  *
  * It is not possible to "deregister" the child death event source.
  * It will generate exactly one event callback; until then the childw
@@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
  *
  * Higher-level double-fork and separate detach eg as for device models
  *
- * Each libxl__spawn_state is in one of the conventional states
- *    Undefined, Idle, Active
+ * Each libxl__spawn_state is in one of these states
+ *    Undefined, Idle, Attached, Detaching
  */
 
 typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
@@ -1040,15 +1039,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
  * intermediate or final child; an error message will have been
  * logged.
  *
- * confirm_cb and failure_cb will not be called reentrantly from
- * within libxl__spawn_spawn.
+ * confirm_cb, failure_cb and detached_cb will not be called
+ * reentrantly from within libxl__spawn_spawn.
  *
  * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
  *  < 0   error, *spawn is now Idle and need not be detached
- *   +1   caller is the parent, *spawn is Active and must eventually be detached
+ *   +1   caller is the parent, *spawn is Attached and must be detached
  *    0   caller is now the inner child, should probably call libxl__exec
  *
  * The spawn state must be Undefined or Idle on entry.
@@ -1056,12 +1055,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
 _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl__spawn_detach - Detaches the daemonic child.
+ * libxl__spawn_request_detach - Detaches the daemonic child.
  *
  * Works by killing the intermediate process from spawn_spawn.
  * After this function returns, failures of either child are no
  * longer reported via failure_cb.
  *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
  * If called before the inner child has been created, this may prevent
  * it from running at all.  Thus this should be called only when the
  * inner child has notified that it is ready.  Normally it will be
@@ -1069,10 +1071,10 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
  *
  * Logs errors.
  *
- * The spawn state must be Active or Idle on entry and will be Idle
+ * The spawn state must be Attached entry and will be Detaching
  * on return.
  */
-_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
+_hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
  * If successful, this should return 0.
@@ -1109,15 +1111,11 @@ typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
 typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
                                      const char *xsdata);
 
-typedef struct {
-    /* Private to the spawn implementation.
-     */
-    /* This separate struct, from malloc, allows us to "detach"
-     * the child and reap it later, when our user has gone
-     * away and freed its libxl__spawn_state */
-    struct libxl__spawn_state *ss;
-    libxl__ev_child mid;
-} libxl__spawn_state_detachable;
+/*
+ * Called when the detach (requested by libxl__spawn_initiate_detach) has
+ * completed.  On entry to the callback the spawn state is Idle.
+ */
+typedef void libxl__spawn_detached_cb(libxl__egc*, libxl__spawn_state*);
 
 struct libxl__spawn_state {
     /* must be filled in by user and remain valid */
@@ -1129,15 +1127,18 @@ struct libxl__spawn_state {
     libxl__spawn_midproc_cb *midproc_cb;
     libxl__spawn_failure_cb *failure_cb;
     libxl__spawn_confirm_cb *confirm_cb;
+    libxl__spawn_detached_cb *detached_cb;
 
     /* remaining fields are private to libxl_spawn_... */
+    int detaching; /* we are in Detaching */
+    int failed; /* might be true whenever we are not Idle */
+    libxl__ev_child mid; /* always in use whenever we are not Idle */
     libxl__ev_time timeout;
     libxl__ev_xswatch xswatch;
-    libxl__spawn_state_detachable *ssd;
 };
 
 static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
-    { return !!ss->ssd; }
+    { return libxl__ev_child_inuse(&ss->mid); }
 
 /*
  * libxl_spawner_record_pid - Record given pid in xenstore
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV76-0005nc-JY; Fri, 15 Jun 2012 11:54:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hv-Lt
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [193.109.254.147:9163] by server-2.bemta-14.messagelabs.com id
	B6/A8-27740-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10348 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nb-5a; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Y2-3Q;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:50 +0100
Message-ID: <1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
	asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the internal and external APIs for domain save (suspend) to be
capable of asynchronous operation.  The implementation remains
synchronous.  The interfaces surrounding device model saving are still
synchronous.

Public API changes:

 * libxl_domain_save takes an ao_how.

 * libxl_domain_remus_start takes an ao_how.  If the
   libxl_domain_remus_info is NULL, we abort rather than returning an
   error.

 * The `suspend_callback' function passed to libxl_domain_save is
   never called by the existing implementation in libxl.  Abolish it.

 * libxl_domain_save takes its flags parameter as an argument.
   Thus libxl_domain_suspend_info is abolished.

 * XL_SUSPEND_* flags renamed to LIBXL_SAVE_*.

 * Callers in xl updated.

Internal code restructuring:

 * libxl__domain_suspend_state member types and names rationalised.

 * libxl__domain_suspend renamed from libxl__domain_suspend_common.
   (_common here actually meant "internal function").

 * libxl__domain_suspend takes a libxl__domain_suspend_state, which
   where the parameters to the operation are filled in by the caller.

 * xc_domain_save is now called via libxl__xc_domain_save which can
   itself become asynchronous.

 * Consequently, libxl__domain_suspend is split into two functions at
   the callback boundary; the second half is
   libxl__xc_domain_save_done.

 * libxl__domain_save_device_model is now called by the actual
   implementation rather than by the public wrapper.  It is already in
   its proper place in the domain save execution sequence.  So
   officially make it part of that execution sequence, renaming it to
   domain_save_device_model.

 * Effectively, rewrite the public wrapper functions
   libxl_domain_suspend and libxl_domain_remus_start.

 * Remove a needless #include <xenctrl.h>

 * libxl__domain_suspend aborts on unexpected domain types rather
   than mysteriously returning EINVAL.

 * struct save_callbacks moved from the stack to the dss.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v4:
 * libxl_domain_suspend now handles error from libxl__domain_type
   in the correct way.  (Hunk brought forward from domain type
   fixup patch.)
 * Comment clarifies that libxl__domain_suspend calls dss->callback
   when done.

Changes in v3:
 * Remove `hvm' and `xcflags' args to libxl__xc_domain_save.  Instead,
   just use the values from the dss.

Changes in v2:
 * Move save_callbacks too.
 * Merge with Remus changes.
 * Improvements to commit message.
 * Do not rename libxl_domain_suspend any more.
---
 tools/libxl/libxl.c              |   94 +++++++++++++++++++++---------
 tools/libxl/libxl.h              |   22 ++++----
 tools/libxl/libxl_dom.c          |  121 +++++++++++++++++++++++++++-----------
 tools/libxl/libxl_internal.h     |   45 ++++++++++++---
 tools/libxl/libxl_save_callout.c |   11 ++++
 tools/libxl/xl_cmdimpl.c         |    9 +--
 6 files changed, 214 insertions(+), 88 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..f7fcf1b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
     return ptr;
 }
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc);
+
 /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd)
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    libxl_domain_type type = libxl__domain_type(gc, domid);
-    int rc = 0;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_suspend_state *dss;
+    int rc;
 
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
-        goto remus_fail;
+        goto out;
     }
 
-    if (info == NULL) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "No remus_info structure supplied for domain %d", domid);
-        rc = ERROR_INVAL;
-        goto remus_fail;
-    }
+    GCNEW(dss);
+    dss->ao = ao;
+    dss->callback = remus_crashed_cb;
+    dss->domid = domid;
+    dss->fd = send_fd;
+    /* TODO do something with recv_fd */
+    dss->type = type;
+    dss->live = 1;
+    dss->debug = 0;
+    dss->remus = info;
+
+    assert(info);
 
     /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
 
     /* Point of no return */
-    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
-                                      /* debug */ 0, info);
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out:
+    return AO_ABORT(rc);
+}
 
+static void remus_crashed_cb(libxl__egc *egc,
+                             libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
     /*
      * With Remus, if we reach this point, it means either
      * backup died or some network error occurred preventing us
@@ -683,27 +702,46 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
     /* TBD: Remus cleanup - i.e. detach qdisc, release other
      * resources.
      */
- remus_fail:
-    GC_FREE;
-    return rc;
+    libxl__ao_complete(egc, ao, rc);
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                         uint32_t domid, int fd)
+static void domain_suspend_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
 {
-    GC_INIT(ctx);
+    STATE_AO_GC(dss->ao);
+    libxl__ao_complete(egc,ao,rc);
+
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    int rc;
+
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
-    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
-    int rc = 0;
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out_err;
+    }
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
-                                      /* No Remus */ NULL);
+    libxl__domain_suspend_state *dss;
+    GCNEW(dss);
 
-    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(gc, domid, fd);
-    GC_FREE;
-    return rc;
+    dss->ao = ao;
+    dss->callback = domain_suspend_cb;
+
+    dss->domid = domid;
+    dss->fd = fd;
+    dss->type = type;
+    dss->live = flags & LIBXL_SUSPEND_LIVE;
+    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out_err:
+    return AO_ABORT(rc);
 }
 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..10d7115 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
 
-typedef struct {
-#define XL_SUSPEND_DEBUG 1
-#define XL_SUSPEND_LIVE 2
-    int flags;
-    int (*suspend_callback)(void *, int);
-} libxl_domain_suspend_info;
-
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
@@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
-int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd);
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                          uint32_t domid, int fd);
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_asyncop_how *ao_how);
+#define LIBXL_SUSPEND_DEBUG 1
+#define LIBXL_SUSPEND_LIVE 2
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
  *   must support this.
  */
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
+
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how);
+
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1d4e809..b48452c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -17,13 +17,11 @@
 
 #include <glob.h>
 
-#include <xenctrl.h>
-#include <xc_dom.h>
+#include "libxl_internal.h"
 
+#include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl_internal.h"
-
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -521,11 +519,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-static int libxl__domain_suspend_common_switch_qemu_logdirty
+/*==================== Domain suspend (save) ====================*/
+
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc);
+
+/*----- callbacks, called by xc_domain_save -----*/
+
+int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
 
@@ -590,10 +595,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
@@ -714,7 +719,7 @@ static int libxl__domain_suspend_common_callback(void *data)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss->domid);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -731,11 +736,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -806,6 +811,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
     return 0;
 }
 
+/*----- remus callbacks -----*/
+
 static int libxl__remus_domain_suspend_callback(void *data)
 {
     /* TODO: Issue disk and network checkpoint reqs. */
@@ -815,7 +822,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
 static int libxl__remus_domain_resume_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
     if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
@@ -828,10 +835,11 @@ static int libxl__remus_domain_resume_callback(void *data)
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
     if (dss->hvm &&
-        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
+        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
@@ -839,17 +847,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
     return 1;
 }
 
-int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                 libxl_domain_type type,
-                                 int live, int debug,
-                                 const libxl_domain_remus_info *r_info)
+/*----- main code for suspending, in order of execution -----*/
+
+void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 {
+    STATE_AO_GC(dss->ao);
     int port;
-    struct save_callbacks callbacks[1];
-    libxl__domain_suspend_state dss[1];
     int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+    const libxl_domain_type type = dss->type;
+    const int live = dss->live;
+    const int debug = dss->debug;
+    const libxl_domain_remus_info *const r_info = dss->remus;
+    struct save_callbacks *const callbacks = &dss->callbacks;
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
@@ -868,15 +882,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->hvm = 0;
         break;
     default:
-        return ERROR_INVAL;
+        abort();
     }
 
     dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (dss->hvm) ? XCFLAGS_HVM : 0;
 
-    dss->domid = domid;
-    dss->gc = gc;
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
 
@@ -884,10 +896,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->interval = r_info->interval;
         if (r_info->compression)
             dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        dss->save_fd = fd;
     }
-    else
-        dss->save_fd = -1;
 
     dss->xce = xc_evtchn_open(NULL, 0);
     if (dss->xce == NULL)
@@ -917,10 +926,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     callbacks->toolstack_save = libxl__toolstack_save;
     callbacks->data = dss;
 
-    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
-                        dss->hvm, vm_generationid_addr);
-    if ( rc ) {
-        LOGE(ERROR, "saving domain: %s",
+    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
+    return;
+
+ out:
+    domain_suspend_done(egc, dss, rc);
+}
+
+void libxl__xc_domain_save_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss,
+                                int rc, int retval, int errnoval)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const libxl_domain_type type = dss->type;
+    const uint32_t domid = dss->domid;
+
+    if (rc)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "saving domain: %s",
                          dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
@@ -928,16 +955,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
+        goto out;
     }
 
-    if (dss->suspend_eventchn > 0)
-        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                                  dss->suspend_eventchn);
-    if (dss->xce != NULL)
-        xc_evtchn_close(dss->xce);
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, domid);
+        if (rc) goto out;
+        
+        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
+        if (rc) goto out;
+    }
+
+    rc = 0;
 
 out:
-    return rc;
+    domain_suspend_done(egc, dss, rc);
 }
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
@@ -992,6 +1024,25 @@ out:
     return rc;
 }
 
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
+
+    dss->callback(egc, dss, rc);
+}
+
+/*==================== Miscellaneous ====================*/
+
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
     char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 28478ea..7cf1b04 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
+typedef void libxl__domain_suspend_cb(libxl__egc*,
+                                      libxl__domain_suspend_state*, int rc);
+
 struct libxl__domain_suspend_state {
-    libxl__gc *gc;
+    /* set by caller of libxl__domain_suspend */
+    libxl__ao *ao;
+    libxl__domain_suspend_cb *callback;
+
+    uint32_t domid;
+    int fd;
+    libxl_domain_type type;
+    int live;
+    int debug;
+    const libxl_domain_remus_info *remus;
+    /* private */
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
-    int domid;
     int hvm;
-    unsigned int xcflags;
+    int xcflags;
     int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
     int interval; /* checkpoint interval (for Remus) */
+    struct save_callbacks callbacks;
 };
 
 
@@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
 
 /*----- Domain suspend (save) functions -----*/
 
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
+/* calls dss->callback when done */
+_hidden void libxl__domain_suspend(libxl__egc *egc,
+                                   libxl__domain_suspend_state *dss);
+
+
+/* calls libxl__xc_domain_suspend_done when done */
+_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
+                                   unsigned long vm_generationid_addr);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_save_done(libxl__egc*,
+                                        libxl__domain_suspend_state*,
+                                        int rc, int retval, int errnoval);
+
+_hidden int libxl__domain_suspend_common_callback(void *data);
+_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data);
+_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data);
+
 
 /* calls libxl__xc_domain_restore_done when done */
 _hidden void libxl__xc_domain_restore(libxl__egc *egc,
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 2f8db9f..1b481ab 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               &state->vm_generationid_addr, &dcs->callbacks);
     libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
 }
+
+void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
+                           unsigned long vm_generationid_addr)
+{
+    STATE_AO_GC(dss->ao);
+    int r;
+
+    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
+                       &dss->callbacks, dss->hvm, vm_generationid_addr);
+    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3ea95ef..19daa1c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
+    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
@@ -3008,7 +3008,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     pid_t child = -1;
     int rc;
     int send_fd = -1, recv_fd = -1;
-    libxl_domain_suspend_info suspinfo;
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
@@ -3030,9 +3029,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    memset(&suspinfo, 0, sizeof(suspinfo));
-    suspinfo.flags |= XL_SUSPEND_LIVE;
-    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
+    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -6604,7 +6601,7 @@ int main_remus(int argc, char **argv)
     }
 
     /* Point of no return */
-    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
 
     /* If we are here, it means backup has failed/domain suspend failed.
      * Try to resume the domain and exit gracefully.
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV79-0005rO-6Y; Fri, 15 Jun 2012 11:54:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV73-0005hg-Jh
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:49 +0000
Received: from [193.109.254.147:9483] by server-8.bemta-14.messagelabs.com id
	48/A6-27132-9822BDF4; Fri, 15 Jun 2012 11:54:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10465 invoked from network); 15 Jun 2012 11:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041891"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6S-0005OO-2Q; Fri, 15 Jun 2012 11:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Z4-Tv;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:06 +0100
Message-ID: <1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce prohibition
	on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/gentypes.py      |    1 -
 tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 5 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index ddc2624..c238ac0 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 10d7115..1a32d9e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 36c75ed..6c859bc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1538,10 +1544,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV7A-0005sc-06; Fri, 15 Jun 2012 11:54:56 +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 1SfV76-0005mH-23
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:52 +0000
Received: from [193.109.254.147:19701] by server-10.bemta-14.messagelabs.com
	id B0/0A-25709-B822BDF4; Fri, 15 Jun 2012 11:54:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10664 invoked from network); 15 Jun 2012 11:54:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O9-PR; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yr-Nc;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:03 +0100
Message-ID: <1339761246-27641-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/21] libxl: do not leak spawned middle children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn would, when libxl__spawn_detach was called, make
the spawn become idle immediately.  However it still has a child
process which needs to be waited for: the `detachable' spawned
child.

This is wrong because the ultimate in-libxl caller may return to the
application, with a child process still forked but not reaped libxl
contrary to the documented behaviour of libxl.

Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
which is asynchronous.  The detachable spawned children are abolished;
instead, we defer calling back to the in-libxl user until the middle
child has been reaped.

Also, remove erroneous comment suggesting that `death' callback
parameter to libxl__ev_child_fork may be NULL.  It may not, and there
are no callers which pass NULL.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Clarify semantics of sub-states of Attached.
 * Fix reference to `Failing' sub-state in comment to `Failed'.

Changes in v3 of series:
 * Now also remove erroneous comment about NULL fork death callback.
---
 tools/libxl/libxl_dm.c       |   14 ++++-
 tools/libxl/libxl_exec.c     |  130 +++++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h |   43 +++++++-------
 3 files changed, 110 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..b3de145 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -908,6 +908,8 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
 static void device_model_startup_failed(libxl__egc *egc,
                                         libxl__spawn_state *spawn);
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn);
 
 /* our "next step" function, called from those callbacks and elsewhere */
 static void device_model_spawn_outcome(libxl__egc *egc,
@@ -1015,6 +1017,7 @@ retry_transaction:
     spawn->midproc_cb = libxl__spawn_record_pid;
     spawn->confirm_cb = device_model_confirm;
     spawn->failure_cb = device_model_startup_failed;
+    spawn->detached_cb = device_model_detached;
 
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
@@ -1048,9 +1051,7 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
     if (strcmp(xsdata, "running"))
         return;
 
-    libxl__spawn_detach(gc, spawn);
-
-    device_model_spawn_outcome(egc, dmss, 0);
+    libxl__spawn_initiate_detach(gc, spawn);
 }
 
 static void device_model_startup_failed(libxl__egc *egc,
@@ -1060,6 +1061,13 @@ static void device_model_startup_failed(libxl__egc *egc,
     device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
 }
 
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, 0);
+}
+
 static void device_model_spawn_outcome(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index cfa379c..0477386 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -238,15 +238,22 @@ err:
 /*
  * Full set of possible states of a libxl__spawn_state and its _detachable:
  *
- *               ss->        ss->        ss->    | ssd->       ssd->
- *               timeout     xswatch     ssd     |  mid         ss
- *  - Undefined   undef       undef       no     |  -           -
- *  - Idle        Idle        Idle        no     |  -           -
- *  - Active      Active      Active      yes    |  Active      yes
- *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
- *  - Detached    -           -           -      |  Active      no
+ *                   detaching failed  mid     timeout      xswatch          
+ *  - Undefined         undef   undef   -        undef        undef
+ *  - Idle              any     any     Idle     Idle         Idle
+ *  - Attached OK       0       0       Active   Active       Active
+ *  - Attached Failed   0       1       Active   Idle         Idle
+ *  - Detaching         1       maybe   Active   Idle         Idle
+ *  - Partial           any     any     Idle     Active/Idle  Active/Idle
  *
- * When in state Detached, the middle process has been sent a SIGKILL.
+ * When in states Detaching or Attached Failed, the middle process has
+ * been sent a SIGKILL.
+ *
+ * The difference between Attached OK and Attached Failed is not
+ * directly visible to callers - callers see these two the same,
+ * although of course Attached OK will hopefully eventually result in
+ * a call to detached_cb, whereas Attached Failed will end up
+ * in a call to failure_cb.
  */
 
 /* Event callbacks. */
@@ -257,19 +264,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status);
 
-/* Precondition: Partial.  Results: Detached. */
+/* Precondition: Partial.  Results: Idle. */
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-/* Precondition: Partial; caller has logged failure reason.
- * Results: Caller notified of failure;
- *  after return, ss may be completely invalid as caller may reuse it */
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
+/* Precondition: Attached or Detaching; caller has logged failure reason.
+ * Results: Detaching, or Attached Failed */
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss);
 
 void libxl__spawn_init(libxl__spawn_state *ss)
 {
+    libxl__ev_child_init(&ss->mid);
     libxl__ev_time_init(&ss->timeout);
     libxl__ev_xswatch_init(&ss->xswatch);
-    ss->ssd = 0;
 }
 
 int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -280,8 +286,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
-    libxl__ev_child_init(&ss->ssd->mid);
+    ss->failed = ss->detaching = 0;
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
                                      spawn_timeout, ss->timeout_ms);
@@ -291,7 +296,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
                                     spawn_watch_event, ss->xspath);
     if (rc) goto out_err;
 
-    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    pid_t middle = libxl__ev_child_fork(gc, &ss->mid, spawn_middle_death);
     if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
 
     if (middle) {
@@ -344,54 +349,64 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
+    assert(!libxl__ev_child_inuse(&ss->mid));
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+}
+
+static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+/* Precondition: Attached or Detaching, but caller must have just set
+ * at least one of detaching or failed.
+ * Results: Detaching or Attached Failed */
+{
     int r;
 
+    assert(libxl__ev_child_inuse(&ss->mid));
     libxl__ev_time_deregister(gc, &ss->timeout);
     libxl__ev_xswatch_deregister(gc, &ss->xswatch);
 
-    libxl__spawn_state_detachable *ssd = ss->ssd;
-    if (ssd) {
-        if (libxl__ev_child_inuse(&ssd->mid)) {
-            pid_t child = ssd->mid.pid;
-            r = kill(child, SIGKILL);
-            if (r && errno != ESRCH)
-                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
-                     ss->what, (unsigned long)child);
-        }
+    pid_t child = ss->mid.pid;
+    r = kill(child, SIGKILL);
+    if (r && errno != ESRCH)
+        LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+             ss->what, (unsigned long)child);
+}
 
-        /* disconnect the ss and ssd from each other */
-        ssd->ss = 0;
-        ss->ssd = 0;
-    }
+void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    ss->detaching = 1;
+    spawn_detach(gc, ss);
 }
 
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss)
+/* Caller must have logged.  Must be last thing in calling function,
+ * as it may make the callback.  Precondition: Attached or Detaching. */
 {
     EGC_GC;
-    spawn_cleanup(gc, ss);
-    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+    ss->failed = 1;
+    spawn_detach(gc, ss);
 }
 
 static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
                           const struct timeval *requested_abs)
 {
-    /* Before event, was Active; is now Partial. */
+    /* Before event, was Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
     LOG(ERROR, "%s: startup timed out", ss->what);
-    spawn_failed(egc, ss); /* must be last */
+    spawn_fail(egc, ss); /* must be last */
 }
 
 static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
                               const char *watch_path, const char *event_path)
 {
-    /* On entry, is Active. */
+    /* On entry, is Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
     char *p = libxl__xs_read(gc, 0, ss->xspath);
     if (!p && errno != ENOENT) {
         LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
-        spawn_failed(egc, ss); /* must be last */
+        spawn_fail(egc, ss); /* must be last */
         return;
     }
     ss->confirm_cb(egc, ss, p); /* must be last */
@@ -399,20 +414,22 @@ static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
 
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status)
-    /* Before event, was Active or Detached;
-     * is now Active or Detached except that ssd->mid is Idle */
+    /* On entry, is Attached or Detaching */
 {
     EGC_GC;
-    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
-    libxl__spawn_state *ss = ssd->ss;
-
-    if (!WIFEXITED(status)) {
+    libxl__spawn_state *ss = CONTAINER_OF(childw, *ss, mid);
+
+    if ((ss->failed || ss->detaching) &&
+        ((WIFEXITED(status) && WEXITSTATUS(status)==0) ||
+         (WIFSIGNALED(status) && WTERMSIG(status)==SIGKILL))) {
+        /* as expected */
+    } else if (!WIFEXITED(status)) {
+        int loglevel = ss->detaching ? XTL_WARN : XTL_ERROR;
         const char *what =
-            GCSPRINTF("%s intermediate process (startup monitor)",
-                      ss ? ss->what : "(detached)");
-        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+            GCSPRINTF("%s intermediate process (startup monitor)", ss->what);
         libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
-    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        ss->failed = 1;
+    } else {
         if (!status)
             LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
                 " when we were waiting for it to confirm startup",
@@ -430,15 +447,22 @@ static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                 LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
                     " signal number %d", ss->what, (unsigned long)pid, sig);
         }
-        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
-        spawn_failed(egc, ss); /* must be last use of ss */
+        ss->failed = 1;
     }
-    free(ssd);
-}
 
-void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
-{
     spawn_cleanup(gc, ss);
+
+    if (ss->failed && !ss->detaching) {
+        ss->failure_cb(egc, ss); /* must be last */
+        return;
+    }
+    
+    if (ss->failed && ss->detaching)
+        LOG(WARN,"%s underlying machinery seemed to fail,"
+            " but its function seems to have been successful", ss->what);
+
+    assert(ss->detaching);
+    ss->detached_cb(egc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 85f4bc6..9df0db5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -690,8 +690,7 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
  * the libxl event machinery.
  *
  * The parent may signal the child but it must not reap it.  That will
- * be done by the event machinery.  death may be NULL in which case
- * the child is still reaped but its death is ignored.
+ * be done by the event machinery.
  *
  * It is not possible to "deregister" the child death event source.
  * It will generate exactly one event callback; until then the childw
@@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
  *
  * Higher-level double-fork and separate detach eg as for device models
  *
- * Each libxl__spawn_state is in one of the conventional states
- *    Undefined, Idle, Active
+ * Each libxl__spawn_state is in one of these states
+ *    Undefined, Idle, Attached, Detaching
  */
 
 typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
@@ -1040,15 +1039,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
  * intermediate or final child; an error message will have been
  * logged.
  *
- * confirm_cb and failure_cb will not be called reentrantly from
- * within libxl__spawn_spawn.
+ * confirm_cb, failure_cb and detached_cb will not be called
+ * reentrantly from within libxl__spawn_spawn.
  *
  * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
  *  < 0   error, *spawn is now Idle and need not be detached
- *   +1   caller is the parent, *spawn is Active and must eventually be detached
+ *   +1   caller is the parent, *spawn is Attached and must be detached
  *    0   caller is now the inner child, should probably call libxl__exec
  *
  * The spawn state must be Undefined or Idle on entry.
@@ -1056,12 +1055,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
 _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl__spawn_detach - Detaches the daemonic child.
+ * libxl__spawn_request_detach - Detaches the daemonic child.
  *
  * Works by killing the intermediate process from spawn_spawn.
  * After this function returns, failures of either child are no
  * longer reported via failure_cb.
  *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
  * If called before the inner child has been created, this may prevent
  * it from running at all.  Thus this should be called only when the
  * inner child has notified that it is ready.  Normally it will be
@@ -1069,10 +1071,10 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
  *
  * Logs errors.
  *
- * The spawn state must be Active or Idle on entry and will be Idle
+ * The spawn state must be Attached entry and will be Detaching
  * on return.
  */
-_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
+_hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
  * If successful, this should return 0.
@@ -1109,15 +1111,11 @@ typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
 typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
                                      const char *xsdata);
 
-typedef struct {
-    /* Private to the spawn implementation.
-     */
-    /* This separate struct, from malloc, allows us to "detach"
-     * the child and reap it later, when our user has gone
-     * away and freed its libxl__spawn_state */
-    struct libxl__spawn_state *ss;
-    libxl__ev_child mid;
-} libxl__spawn_state_detachable;
+/*
+ * Called when the detach (requested by libxl__spawn_initiate_detach) has
+ * completed.  On entry to the callback the spawn state is Idle.
+ */
+typedef void libxl__spawn_detached_cb(libxl__egc*, libxl__spawn_state*);
 
 struct libxl__spawn_state {
     /* must be filled in by user and remain valid */
@@ -1129,15 +1127,18 @@ struct libxl__spawn_state {
     libxl__spawn_midproc_cb *midproc_cb;
     libxl__spawn_failure_cb *failure_cb;
     libxl__spawn_confirm_cb *confirm_cb;
+    libxl__spawn_detached_cb *detached_cb;
 
     /* remaining fields are private to libxl_spawn_... */
+    int detaching; /* we are in Detaching */
+    int failed; /* might be true whenever we are not Idle */
+    libxl__ev_child mid; /* always in use whenever we are not Idle */
     libxl__ev_time timeout;
     libxl__ev_xswatch xswatch;
-    libxl__spawn_state_detachable *ssd;
 };
 
 static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
-    { return !!ss->ssd; }
+    { return libxl__ev_child_inuse(&ss->mid); }
 
 /*
  * libxl_spawner_record_pid - Record given pid in xenstore
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV76-0005mx-6o; Fri, 15 Jun 2012 11:54: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 1SfV71-0005hp-Mb
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:18961] by server-3.bemta-4.messagelabs.com id
	33/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23659 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041882"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nw-Hu; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YY-G4;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:58 +0100
Message-ID: <1339761246-27641-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/21] libxl: Add a gc to libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.

libxl_get_cpu_topology doesn't have one but does use NOGC.
Fix this by:
 - introducing an `out' label
 - replacing the only call to `return' with a suitable assignment
   to ret and a `goto out'.
 - adding uses of GC_INIT and GC_FREE.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7fcf1b..ce990ab 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3201,6 +3201,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
@@ -3213,7 +3214,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
     if (max_cpus == 0)
     {
         LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
-        return NULL;
+        ret = NULL;
+        goto out;
     }
 
     coremap = xc_hypercall_buffer_alloc
@@ -3258,6 +3260,8 @@ fail:
 
     if (ret)
         *nr = max_cpus;
+ out:
+    GC_FREE;
     return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV76-0005mx-6o; Fri, 15 Jun 2012 11:54: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 1SfV71-0005hp-Mb
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:18961] by server-3.bemta-4.messagelabs.com id
	33/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23659 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041882"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nw-Hu; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YY-G4;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:58 +0100
Message-ID: <1339761246-27641-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/21] libxl: Add a gc to libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.

libxl_get_cpu_topology doesn't have one but does use NOGC.
Fix this by:
 - introducing an `out' label
 - replacing the only call to `return' with a suitable assignment
   to ret and a `goto out'.
 - adding uses of GC_INIT and GC_FREE.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7fcf1b..ce990ab 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3201,6 +3201,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
@@ -3213,7 +3214,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
     if (max_cpus == 0)
     {
         LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
-        return NULL;
+        ret = NULL;
+        goto out;
     }
 
     coremap = xc_hypercall_buffer_alloc
@@ -3258,6 +3260,8 @@ fail:
 
     if (ret)
         *nr = max_cpus;
+ out:
+    GC_FREE;
     return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV78-0005pi-3n; Fri, 15 Jun 2012 11:54:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV72-0005hp-Ei
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [85.158.143.99:51510] by server-3.bemta-4.messagelabs.com id
	15/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339761285!24164360!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15698 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Ny-K0; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yc-HW;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:59 +0100
Message-ID: <1339761246-27641-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: [Xen-devel] [PATCH 14/21] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc (and which replaces the previous
#define NOGC NULL).

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ce990ab..d3b017b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 00705d8..ab000bc 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -108,7 +108,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c9b4189..aa150b5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
-#define NOGC          NULL
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 67ef82c..08c7dac 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV77-0005p9-NW; Fri, 15 Jun 2012 11:54: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 1SfV72-0005ha-4g
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [193.109.254.147:36276] by server-9.bemta-14.messagelabs.com id
	F8/D6-27072-7822BDF4; Fri, 15 Jun 2012 11:54:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nk-BE; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YI-98;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:54 +0100
Message-ID: <1339761246-27641-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/21] libxl: wait for qemu to acknowledge
	logdirty 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

The current migration code in libxl instructs qemu to start or stop
logdirty, but it does not wait for an acknowledgement from qemu before
continuing.  This might lead to memory corruption (!)

Fix this by waiting for qemu to acknowledge the command.

Unfortunately the necessary ao arrangements for waiting for this
command are unique because qemu has a special protocol for this
particular operation.

Also, this change means that the switch_qemu_logdirty callback
implementation in libxl can no longer synchronously produce its return
value, as it now needs to wait for xenstore.  So we tell the
marshalling code generator that it is a message which does not need a
reply.  This turns the callback function called by the marshaller into
one which returns void; the callback function arranges to later
explicitly sends the reply to the helper, when the xs watch triggers
and the appropriate value is read from xenstore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Correct the sense of the return value from switch_qemu_logdirty.
 * Fix a somewhat mendacious log message.
---
 tools/libxl/libxl_dom.c            |  177 +++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h       |   18 ++++-
 tools/libxl/libxl_save_callout.c   |    8 ++
 tools/libxl/libxl_save_msgs_gen.pl |    7 +-
 4 files changed, 194 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a597627..4cca846 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -528,30 +528,181 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
 static void domain_suspend_done(libxl__egc *egc,
                         libxl__domain_suspend_state *dss, int rc);
 
-/*----- callbacks, called by xc_domain_save -----*/
+/*----- complicated callback, called by xc_domain_save -----*/
+
+/*
+ * We implement the other end of protocol for controlling qemu-dm's
+ * logdirty.  There is no documentation for this protocol, but our
+ * counterparty's implementation is in
+ * qemu-xen-traditional.git:xenstore.c in the function
+ * xenstore_process_logdirty_event
+ */
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs);
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok);
 
-int libxl__domain_suspend_common_switch_qemu_logdirty
+static void logdirty_init(libxl__logdirty_switch *lds)
+{
+    lds->cmd_path = 0;
+    libxl__ev_xswatch_init(&lds->watch);
+    libxl__ev_time_init(&lds->timeout);
+}
+
+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);
+    libxl__logdirty_switch *lds = &dss->logdirty;
     STATE_AO_GC(dss->ao);
-    char *path;
-    bool rc;
+    int rc;
+    xs_transaction_t t = 0;
+    const char *got;
 
-    path = libxl__sprintf(gc,
+    if (!lds->cmd_path) {
+        lds->cmd_path = GCSPRINTF(
                    "/local/domain/0/device-model/%u/logdirty/cmd", domid);
-    if (!path)
-        return 1;
+        lds->ret_path = GCSPRINTF(
+                   "/local/domain/0/device-model/%u/logdirty/ret", domid);
+    }
+    lds->cmd = enable ? "enable" : "disable";
 
-    if (enable)
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
-    else
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
+    rc = libxl__ev_xswatch_register(gc, &lds->watch,
+                                switch_logdirty_xswatch, lds->ret_path);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_register_rel(gc, &lds->timeout,
+                                switch_logdirty_timeout, 10*1000);
+    if (rc) goto out;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->cmd_path, &got);
+        if (rc) goto out;
+
+        if (got) {
+            const char *got_ret;
+            rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got_ret);
+            if (rc) goto out;
 
-    return rc ? 0 : 1;
+            if (strcmp(got, got_ret)) {
+                LOG(ERROR,"controlling logdirty: qemu was already sent"
+                    " command `%s' (xenstore path `%s') but result is `%s'",
+                    got, lds->cmd_path, got_ret ? got_ret : "<none>");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+            rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+            if (rc) goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_write_checked(gc, t, lds->cmd_path, lds->cmd);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t);
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+    /* OK, wait for some callback */
+    return;
+
+ out:
+    LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+    switch_logdirty_done(egc,dss,-1);
+}
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
+    STATE_AO_GC(dss->ao);
+    LOG(ERROR,"logdirty switch: wait for device model timed out");
+    switch_logdirty_done(egc,dss,-1);
 }
 
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(watch, *dss, logdirty.watch);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+    STATE_AO_GC(dss->ao);
+    const char *got;
+    xs_transaction_t t = 0;
+    int rc;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
+        if (rc) goto out;
+
+        if (!got) {
+            rc = +1;
+            goto out;
+        }
+
+        if (strcmp(got, lds->cmd)) {
+            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
+                " (xenstore paths `%s' / `%s')", lds->cmd, got,
+                lds->cmd_path, lds->ret_path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t); 
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+ out:
+    /* rc < 0: error
+     * rc == 0: ok, we are done
+     * rc == +1: need to keep waiting
+     */
+    libxl__xs_transaction_abort(gc, &t);
+
+    if (!rc) {
+        switch_logdirty_done(egc,dss,0);
+    } else if (rc < 0) {
+        LOG(ERROR,"logdirty switch: failed (rc=%d)",rc);
+        switch_logdirty_done(egc,dss,-1);
+    }
+}
+
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss,
+                                 int broke)
+{
+    STATE_AO_GC(dss->ao);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+
+    libxl__ev_xswatch_deregister(gc, &lds->watch);
+    libxl__ev_time_deregister(gc, &lds->timeout);
+
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, broke);
+}
+
+/*----- callbacks, called by xc_domain_save -----*/
+
 int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -873,6 +1024,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     libxl__srm_save_autogen_callbacks *const callbacks =
         &dss->shs.callbacks.save.a;
 
+    logdirty_init(&dss->logdirty);
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b108d00..05bed01 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1864,6 +1864,14 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
 
+typedef struct libxl__logdirty_switch {
+    const char *cmd;
+    const char *cmd_path;
+    const char *ret_path;
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+} libxl__logdirty_switch;
+
 struct libxl__domain_suspend_state {
     /* set by caller of libxl__domain_suspend */
     libxl__ao *ao;
@@ -1883,6 +1891,7 @@ struct libxl__domain_suspend_state {
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
+    libxl__logdirty_switch logdirty;
 };
 
 
@@ -2013,8 +2022,15 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
+/* Used by asynchronous callbacks: ie ones which xc regards as
+ * returning a value, but which we want to handle asynchronously.
+ * Such functions' actual callback function return void in libxl
+ * When they are ready to indicate completion, they call this. */
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value);
+
 _hidden int libxl__domain_suspend_common_callback(void *data);
-_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+_hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data);
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 007d61c..297854e 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -142,6 +142,14 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
 }
 
 
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value)
+{
+    shs->egc = egc;
+    libxl__srm_callout_sendreply(return_value, shs);
+    shs->egc = 0;
+}
+
 /*----- helper execution -----*/
 
 static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index c45986e..a9ac808 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -14,6 +14,7 @@ our @msgs = (
     #   x  - function pointer is in struct {save,restore}_callbacks
     #         and its null-ness needs to be passed through to the helper's xc
     #   W  - needs a return value; callback is synchronous
+    #   A  - needs a return value; callback is asynchronous
     [  1, 'sr',     "log",                   [qw(uint32_t level
                                                  uint32_t errnoval
                                                  STRING context
@@ -25,7 +26,7 @@ our @msgs = (
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
     [  5, 'scxW',   "checkpoint", [] ],      
-    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+    [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
     [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
@@ -262,7 +263,7 @@ foreach my $msginfo (@msgs) {
         $f_more_sr->("        int r;\n");
     }
 
-    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_helper = $flags =~ m/[WA]/ ? 'int' : 'void';
     my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
     my $c_decl = '(';
     my $c_callback_args = '';
@@ -351,7 +352,7 @@ END_ALWAYS
     assert(len == allocd);
     ${transmit}(buf, len, user);
 ");
-    if ($flags =~ m/W/) {
+    if ($flags =~ m/[WA]/) {
 	f_more("${encode}_$name",
                (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
     int r = ${helper}_getreply(user);
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV78-0005pi-3n; Fri, 15 Jun 2012 11:54:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV72-0005hp-Ei
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [85.158.143.99:51510] by server-3.bemta-4.messagelabs.com id
	15/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339761285!24164360!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15698 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Ny-K0; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yc-HW;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:59 +0100
Message-ID: <1339761246-27641-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: [Xen-devel] [PATCH 14/21] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc (and which replaces the previous
#define NOGC NULL).

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ce990ab..d3b017b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 00705d8..ab000bc 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -108,7 +108,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c9b4189..aa150b5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
-#define NOGC          NULL
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 67ef82c..08c7dac 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
1.7.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 Jun 15 11:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV77-0005p9-NW; Fri, 15 Jun 2012 11:54: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 1SfV72-0005ha-4g
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [193.109.254.147:36276] by server-9.bemta-14.messagelabs.com id
	F8/D6-27072-7822BDF4; Fri, 15 Jun 2012 11:54:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nk-BE; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YI-98;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:54 +0100
Message-ID: <1339761246-27641-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/21] libxl: wait for qemu to acknowledge
	logdirty 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

The current migration code in libxl instructs qemu to start or stop
logdirty, but it does not wait for an acknowledgement from qemu before
continuing.  This might lead to memory corruption (!)

Fix this by waiting for qemu to acknowledge the command.

Unfortunately the necessary ao arrangements for waiting for this
command are unique because qemu has a special protocol for this
particular operation.

Also, this change means that the switch_qemu_logdirty callback
implementation in libxl can no longer synchronously produce its return
value, as it now needs to wait for xenstore.  So we tell the
marshalling code generator that it is a message which does not need a
reply.  This turns the callback function called by the marshaller into
one which returns void; the callback function arranges to later
explicitly sends the reply to the helper, when the xs watch triggers
and the appropriate value is read from xenstore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Correct the sense of the return value from switch_qemu_logdirty.
 * Fix a somewhat mendacious log message.
---
 tools/libxl/libxl_dom.c            |  177 +++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h       |   18 ++++-
 tools/libxl/libxl_save_callout.c   |    8 ++
 tools/libxl/libxl_save_msgs_gen.pl |    7 +-
 4 files changed, 194 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a597627..4cca846 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -528,30 +528,181 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
 static void domain_suspend_done(libxl__egc *egc,
                         libxl__domain_suspend_state *dss, int rc);
 
-/*----- callbacks, called by xc_domain_save -----*/
+/*----- complicated callback, called by xc_domain_save -----*/
+
+/*
+ * We implement the other end of protocol for controlling qemu-dm's
+ * logdirty.  There is no documentation for this protocol, but our
+ * counterparty's implementation is in
+ * qemu-xen-traditional.git:xenstore.c in the function
+ * xenstore_process_logdirty_event
+ */
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs);
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok);
 
-int libxl__domain_suspend_common_switch_qemu_logdirty
+static void logdirty_init(libxl__logdirty_switch *lds)
+{
+    lds->cmd_path = 0;
+    libxl__ev_xswatch_init(&lds->watch);
+    libxl__ev_time_init(&lds->timeout);
+}
+
+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);
+    libxl__logdirty_switch *lds = &dss->logdirty;
     STATE_AO_GC(dss->ao);
-    char *path;
-    bool rc;
+    int rc;
+    xs_transaction_t t = 0;
+    const char *got;
 
-    path = libxl__sprintf(gc,
+    if (!lds->cmd_path) {
+        lds->cmd_path = GCSPRINTF(
                    "/local/domain/0/device-model/%u/logdirty/cmd", domid);
-    if (!path)
-        return 1;
+        lds->ret_path = GCSPRINTF(
+                   "/local/domain/0/device-model/%u/logdirty/ret", domid);
+    }
+    lds->cmd = enable ? "enable" : "disable";
 
-    if (enable)
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
-    else
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
+    rc = libxl__ev_xswatch_register(gc, &lds->watch,
+                                switch_logdirty_xswatch, lds->ret_path);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_register_rel(gc, &lds->timeout,
+                                switch_logdirty_timeout, 10*1000);
+    if (rc) goto out;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->cmd_path, &got);
+        if (rc) goto out;
+
+        if (got) {
+            const char *got_ret;
+            rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got_ret);
+            if (rc) goto out;
 
-    return rc ? 0 : 1;
+            if (strcmp(got, got_ret)) {
+                LOG(ERROR,"controlling logdirty: qemu was already sent"
+                    " command `%s' (xenstore path `%s') but result is `%s'",
+                    got, lds->cmd_path, got_ret ? got_ret : "<none>");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+            rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+            if (rc) goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_write_checked(gc, t, lds->cmd_path, lds->cmd);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t);
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+    /* OK, wait for some callback */
+    return;
+
+ out:
+    LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+    switch_logdirty_done(egc,dss,-1);
+}
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
+    STATE_AO_GC(dss->ao);
+    LOG(ERROR,"logdirty switch: wait for device model timed out");
+    switch_logdirty_done(egc,dss,-1);
 }
 
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(watch, *dss, logdirty.watch);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+    STATE_AO_GC(dss->ao);
+    const char *got;
+    xs_transaction_t t = 0;
+    int rc;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
+        if (rc) goto out;
+
+        if (!got) {
+            rc = +1;
+            goto out;
+        }
+
+        if (strcmp(got, lds->cmd)) {
+            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
+                " (xenstore paths `%s' / `%s')", lds->cmd, got,
+                lds->cmd_path, lds->ret_path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t); 
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+ out:
+    /* rc < 0: error
+     * rc == 0: ok, we are done
+     * rc == +1: need to keep waiting
+     */
+    libxl__xs_transaction_abort(gc, &t);
+
+    if (!rc) {
+        switch_logdirty_done(egc,dss,0);
+    } else if (rc < 0) {
+        LOG(ERROR,"logdirty switch: failed (rc=%d)",rc);
+        switch_logdirty_done(egc,dss,-1);
+    }
+}
+
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss,
+                                 int broke)
+{
+    STATE_AO_GC(dss->ao);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+
+    libxl__ev_xswatch_deregister(gc, &lds->watch);
+    libxl__ev_time_deregister(gc, &lds->timeout);
+
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, broke);
+}
+
+/*----- callbacks, called by xc_domain_save -----*/
+
 int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -873,6 +1024,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     libxl__srm_save_autogen_callbacks *const callbacks =
         &dss->shs.callbacks.save.a;
 
+    logdirty_init(&dss->logdirty);
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b108d00..05bed01 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1864,6 +1864,14 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
 
+typedef struct libxl__logdirty_switch {
+    const char *cmd;
+    const char *cmd_path;
+    const char *ret_path;
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+} libxl__logdirty_switch;
+
 struct libxl__domain_suspend_state {
     /* set by caller of libxl__domain_suspend */
     libxl__ao *ao;
@@ -1883,6 +1891,7 @@ struct libxl__domain_suspend_state {
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
+    libxl__logdirty_switch logdirty;
 };
 
 
@@ -2013,8 +2022,15 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
+/* Used by asynchronous callbacks: ie ones which xc regards as
+ * returning a value, but which we want to handle asynchronously.
+ * Such functions' actual callback function return void in libxl
+ * When they are ready to indicate completion, they call this. */
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value);
+
 _hidden int libxl__domain_suspend_common_callback(void *data);
-_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+_hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data);
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 007d61c..297854e 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -142,6 +142,14 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
 }
 
 
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value)
+{
+    shs->egc = egc;
+    libxl__srm_callout_sendreply(return_value, shs);
+    shs->egc = 0;
+}
+
 /*----- helper execution -----*/
 
 static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index c45986e..a9ac808 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -14,6 +14,7 @@ our @msgs = (
     #   x  - function pointer is in struct {save,restore}_callbacks
     #         and its null-ness needs to be passed through to the helper's xc
     #   W  - needs a return value; callback is synchronous
+    #   A  - needs a return value; callback is asynchronous
     [  1, 'sr',     "log",                   [qw(uint32_t level
                                                  uint32_t errnoval
                                                  STRING context
@@ -25,7 +26,7 @@ our @msgs = (
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
     [  5, 'scxW',   "checkpoint", [] ],      
-    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+    [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
     [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
@@ -262,7 +263,7 @@ foreach my $msginfo (@msgs) {
         $f_more_sr->("        int r;\n");
     }
 
-    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_helper = $flags =~ m/[WA]/ ? 'int' : 'void';
     my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
     my $c_decl = '(';
     my $c_callback_args = '';
@@ -351,7 +352,7 @@ END_ALWAYS
     assert(len == allocd);
     ${transmit}(buf, len, user);
 ");
-    if ($flags =~ m/W/) {
+    if ($flags =~ m/[WA]/) {
 	f_more("${encode}_$name",
                (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
     int r = ${helper}_getreply(user);
-- 
1.7.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 Jun 15 11:55:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV79-0005s2-Im; Fri, 15 Jun 2012 11:54:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV75-0005i3-6g
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:51 +0000
Received: from [193.109.254.147:19669] by server-11.bemta-14.messagelabs.com
	id 2E/02-02727-A822BDF4; Fri, 15 Jun 2012 11:54:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10650 invoked from network); 15 Jun 2012 11:54:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O7-OS; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yk-LE;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:01 +0100
Message-ID: <1339761246-27641-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/21] xl: Handle return value from
	libxl_domain_suspend correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl_domain_suspend returns a libxl error code.  So it must be
wrapped with MUST and not CHK_ERRNO.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 19daa1c..a9125cc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
-- 
1.7.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 Jun 15 11:55:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV79-0005s2-Im; Fri, 15 Jun 2012 11:54:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV75-0005i3-6g
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:51 +0000
Received: from [193.109.254.147:19669] by server-11.bemta-14.messagelabs.com
	id 2E/02-02727-A822BDF4; Fri, 15 Jun 2012 11:54:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10650 invoked from network); 15 Jun 2012 11:54:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O7-OS; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yk-LE;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:01 +0100
Message-ID: <1339761246-27641-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/21] xl: Handle return value from
	libxl_domain_suspend correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl_domain_suspend returns a libxl error code.  So it must be
wrapped with MUST and not CHK_ERRNO.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 19daa1c..a9125cc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
-- 
1.7.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 Jun 15 11:55:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV75-0005mb-R3; Fri, 15 Jun 2012 11:54:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005i6-ID
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.99:51489] by server-1.bemta-4.messagelabs.com id
	14/38-24392-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339761285!24164360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15689 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nq-Fi; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YQ-Ca;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:56 +0100
Message-ID: <1339761246-27641-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/21] libxl: prepare for asynchronous writing
	of qemu save 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

* Combine the various calls to libxl__device_model_savefile into one
  at the start of libxl__domain_suspend, storing the result in the
  dss.  Consequently a few functions take a dss instead of some or all
  of their other arguments.

* Make libxl__domain_save_device_model's API into an asynchronous
  style which takes a callback.  The function is, however, still
  synchronous; it will be made actually async in the next patch.

* Consequently make libxl__remus_domain_checkpoint_callback into an
  asynchronous callback.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h       |   18 ++++++++++--
 tools/libxl/libxl_save_msgs_gen.pl |    2 +-
 3 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4cca846..e104744 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -703,11 +703,13 @@ static void switch_logdirty_done(libxl__egc *egc,
 
 /*----- callbacks, called by xc_domain_save -----*/
 
-int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                       libxl__domain_suspend_state *dss)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
-    const char *filename = libxl__device_model_savefile(gc, domid);
+    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: {
@@ -876,7 +878,7 @@ int libxl__domain_suspend_common_callback(void *user)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -991,19 +993,32 @@ static int libxl__remus_domain_resume_callback(void *data)
     return 1;
 }
 
-static int libxl__remus_domain_checkpoint_callback(void *data)
+/*----- remus asynchronous checkpoint callback -----*/
+
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc);
+
+static void libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
-    if (dss->hvm &&
-        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
-        return 0;
+    if (dss->hvm) {
+        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
+    } else {
+        remus_checkpoint_dm_saved(egc, dss, 0);
+    }
+}
 
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc)
+{
     /* TODO: Wait for disk and memory ack, release network buffer */
+    /* TODO: make this asynchronous */
     usleep(dss->interval * 1000);
-    return 1;
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
 }
 
 /*----- main code for suspending, in order of execution -----*/
@@ -1053,6 +1068,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
+    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
 
     if (r_info != NULL) {
         dss->interval = r_info->interval;
@@ -1102,7 +1118,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
 
     /* Convenience aliases */
     const libxl_domain_type type = dss->type;
-    const uint32_t domid = dss->domid;
 
     if (rc)
         goto out;
@@ -1120,11 +1135,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
     }
 
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
-        rc = libxl__domain_suspend_device_model(gc, domid);
+        rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
         
-        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
-        if (rc) goto out;
+        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
+        return;
     }
 
     rc = 0;
@@ -1133,14 +1148,22 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback)
 {
+    STATE_AO_GC(dss->ao);
     int rc, fd2 = -1, c;
     char buf[1024];
-    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
+    dss->save_dm_callback = callback;
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    const int fd = dss->fd;
+
     if (stat(filename, &st) < 0)
     {
         LOG(ERROR, "Unable to stat qemu save file\n");
@@ -1182,7 +1205,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return rc;
+
+    dss->save_dm_callback(egc, dss, rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8b582e4..e95892a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 
 _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
                                      uint32_t size, void *data);
-_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
+
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
+typedef void libxl__save_device_model_cb(libxl__egc*,
+                                         libxl__domain_suspend_state*, int rc);
 
 typedef struct libxl__logdirty_switch {
     const char *cmd;
@@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
     int hvm;
     int xcflags;
     int guest_responded;
+    const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
     libxl__logdirty_switch logdirty;
+    /* private for libxl__domain_save_device_model */
+    libxl__save_device_model_cb *save_dm_callback;
 };
 
 
@@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
+/* Each time the dm needs to be saved, we must call suspend and then save */
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                           libxl__domain_suspend_state *dss);
+_hidden void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback);
+
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+
 
 /*
  * Convenience macros.
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index a9ac808..ee126c7 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -25,7 +25,7 @@ our @msgs = (
                                                 'unsigned long', 'total'] ],
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
-    [  5, 'scxW',   "checkpoint", [] ],      
+    [  5, 'scxA',   "checkpoint", [] ],      
     [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
-- 
1.7.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 Jun 15 11:55:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV75-0005mb-R3; Fri, 15 Jun 2012 11:54:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005i6-ID
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.99:51489] by server-1.bemta-4.messagelabs.com id
	14/38-24392-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339761285!24164360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15689 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nq-Fi; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YQ-Ca;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:56 +0100
Message-ID: <1339761246-27641-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/21] libxl: prepare for asynchronous writing
	of qemu save 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

* Combine the various calls to libxl__device_model_savefile into one
  at the start of libxl__domain_suspend, storing the result in the
  dss.  Consequently a few functions take a dss instead of some or all
  of their other arguments.

* Make libxl__domain_save_device_model's API into an asynchronous
  style which takes a callback.  The function is, however, still
  synchronous; it will be made actually async in the next patch.

* Consequently make libxl__remus_domain_checkpoint_callback into an
  asynchronous callback.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h       |   18 ++++++++++--
 tools/libxl/libxl_save_msgs_gen.pl |    2 +-
 3 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4cca846..e104744 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -703,11 +703,13 @@ static void switch_logdirty_done(libxl__egc *egc,
 
 /*----- callbacks, called by xc_domain_save -----*/
 
-int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                       libxl__domain_suspend_state *dss)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
-    const char *filename = libxl__device_model_savefile(gc, domid);
+    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: {
@@ -876,7 +878,7 @@ int libxl__domain_suspend_common_callback(void *user)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -991,19 +993,32 @@ static int libxl__remus_domain_resume_callback(void *data)
     return 1;
 }
 
-static int libxl__remus_domain_checkpoint_callback(void *data)
+/*----- remus asynchronous checkpoint callback -----*/
+
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc);
+
+static void libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
-    if (dss->hvm &&
-        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
-        return 0;
+    if (dss->hvm) {
+        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
+    } else {
+        remus_checkpoint_dm_saved(egc, dss, 0);
+    }
+}
 
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc)
+{
     /* TODO: Wait for disk and memory ack, release network buffer */
+    /* TODO: make this asynchronous */
     usleep(dss->interval * 1000);
-    return 1;
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
 }
 
 /*----- main code for suspending, in order of execution -----*/
@@ -1053,6 +1068,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
+    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
 
     if (r_info != NULL) {
         dss->interval = r_info->interval;
@@ -1102,7 +1118,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
 
     /* Convenience aliases */
     const libxl_domain_type type = dss->type;
-    const uint32_t domid = dss->domid;
 
     if (rc)
         goto out;
@@ -1120,11 +1135,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
     }
 
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
-        rc = libxl__domain_suspend_device_model(gc, domid);
+        rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
         
-        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
-        if (rc) goto out;
+        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
+        return;
     }
 
     rc = 0;
@@ -1133,14 +1148,22 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback)
 {
+    STATE_AO_GC(dss->ao);
     int rc, fd2 = -1, c;
     char buf[1024];
-    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
+    dss->save_dm_callback = callback;
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    const int fd = dss->fd;
+
     if (stat(filename, &st) < 0)
     {
         LOG(ERROR, "Unable to stat qemu save file\n");
@@ -1182,7 +1205,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return rc;
+
+    dss->save_dm_callback(egc, dss, rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8b582e4..e95892a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 
 _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
                                      uint32_t size, void *data);
-_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
+
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
+typedef void libxl__save_device_model_cb(libxl__egc*,
+                                         libxl__domain_suspend_state*, int rc);
 
 typedef struct libxl__logdirty_switch {
     const char *cmd;
@@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
     int hvm;
     int xcflags;
     int guest_responded;
+    const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
     libxl__logdirty_switch logdirty;
+    /* private for libxl__domain_save_device_model */
+    libxl__save_device_model_cb *save_dm_callback;
 };
 
 
@@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
+/* Each time the dm needs to be saved, we must call suspend and then save */
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                           libxl__domain_suspend_state *dss);
+_hidden void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback);
+
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+
 
 /*
  * Convenience macros.
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index a9ac808..ee126c7 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -25,7 +25,7 @@ our @msgs = (
                                                 'unsigned long', 'total'] ],
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
-    [  5, 'scxW',   "checkpoint", [] ],      
+    [  5, 'scxA',   "checkpoint", [] ],      
     [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
-- 
1.7.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 Jun 15 11:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV74-0005lJ-Ke; Fri, 15 Jun 2012 11:54: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 1SfV71-0005i4-2u
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:18979] by server-2.bemta-4.messagelabs.com id
	7C/25-17938-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23683 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O0-M4; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yg-JX;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:00 +0100
Message-ID: <1339761246-27641-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/21] libxl: Get compiler to warn about
	gc_opt==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

Since it used to be legal to pass gc_opt==NULL, and there are various
patches floating about and under development which do so, add a
compiler annotation which makes the build fail when that is done.

This turns a runtime crash into a build failure, and should ensure
that we don't accidentally commit a broken combination of patches.

This is something of an annoying approach because it adds a macro
invocation to the RHS of every declaration of a function taking a
gc_opt.  So it should be reverted after Xen 4.2rc1.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index aa150b5..85f4bc6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * psuedo-gc.
  */
 /* register ptr in gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
+
+#define NN1 __attribute__((nonnull(1)))
+ /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
+  * warn about this if any slip through. */
+
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
 
 /* Each of these logs errors and returns a libxl error code.
  * They do not mind if path is already removed.
-- 
1.7.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 Jun 15 11:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV74-0005lJ-Ke; Fri, 15 Jun 2012 11:54: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 1SfV71-0005i4-2u
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:18979] by server-2.bemta-4.messagelabs.com id
	7C/25-17938-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23683 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O0-M4; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yg-JX;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:00 +0100
Message-ID: <1339761246-27641-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/21] libxl: Get compiler to warn about
	gc_opt==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

Since it used to be legal to pass gc_opt==NULL, and there are various
patches floating about and under development which do so, add a
compiler annotation which makes the build fail when that is done.

This turns a runtime crash into a build failure, and should ensure
that we don't accidentally commit a broken combination of patches.

This is something of an annoying approach because it adds a macro
invocation to the RHS of every declaration of a function taking a
gc_opt.  So it should be reverted after Xen 4.2rc1.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index aa150b5..85f4bc6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * psuedo-gc.
  */
 /* register ptr in gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
+
+#define NN1 __attribute__((nonnull(1)))
+ /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
+  * warn about this if any slip through. */
+
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
 
 /* Each of these logs errors and returns a libxl error code.
  * They do not mind if path is already removed.
-- 
1.7.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 Jun 15 11:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV77-0005oc-BW; Fri, 15 Jun 2012 11:54:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV72-0005hp-2Y
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [85.158.143.99:51500] by server-3.bemta-4.messagelabs.com id
	54/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339761285!24164360!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O8-OX; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yo-N5;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:02 +0100
Message-ID: <1339761246-27641-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/21] libxl: do not leak dms->saved_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

This was allocated using asprintf but never freed.  Use GCSPRINTF.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ab000bc..5618293 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -740,9 +740,8 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
         goto out;
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
+        state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
     }
 
 out:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV77-0005oc-BW; Fri, 15 Jun 2012 11:54:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV72-0005hp-2Y
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [85.158.143.99:51500] by server-3.bemta-4.messagelabs.com id
	54/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339761285!24164360!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005O8-OX; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yo-N5;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:02 +0100
Message-ID: <1339761246-27641-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/21] libxl: do not leak dms->saved_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

This was allocated using asprintf but never freed.  Use GCSPRINTF.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ab000bc..5618293 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -740,9 +740,8 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
         goto out;
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
+        state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
     }
 
 out:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 11:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV71-0005j9-Tx; Fri, 15 Jun 2012 11:54:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005ha-6L
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:36112] by server-9.bemta-14.messagelabs.com id
	CC/C6-27072-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10313 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nj-9R; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YE-7J;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:53 +0100
Message-ID: <1339761246-27641-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/21] libxl: provide libxl__xs_*_checked and
	libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 useful utility functions make dealing with xenstore a little
less painful.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Fixed typo `commited' in comment.

Changes in v3:
 * Fixed typo `transacton' in log messages.
---
 tools/libxl/libxl_internal.h |   38 +++++++++++++++++++++
 tools/libxl/libxl_xshelp.c   |   76 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1a7b526..b108d00 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -498,6 +498,44 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*----- "checked" xenstore access functions -----*/
+/* Each of these functions will check that it succeeded; if it
+ * fails it logs and returns ERROR_FAIL.
+ */
+
+/* On success, *result_out came from the gc.
+ * On error, *result_out is undefined.
+ * ENOENT counts as success but sets *result_out=0
+ */
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out);
+
+/* Does not include a trailing null.
+ * May usefully be combined with GCSPRINTF if the format string
+ * behaviour of libxl__xs_write is desirable. */
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string);
+
+/* ENOENT is not an error (even if the parent directories don't exist) */
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
+
+/* Transaction functions, best used together.
+ * The caller should initialise *t to 0 (XBT_NULL) before calling start.
+ * Each function leaves *t!=0 iff the transaction needs cleaning up.
+ *
+ * libxl__xs_transaction_commit returns:
+ *   <0  failure - a libxl error code
+ *   +1  commit conflict; transaction has been destroyed and caller
+ *        must go round again (call _start again and retry)
+ *    0  committed successfully
+ */
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
+
+
+
 /*
  * This is a recursive delete, from top to bottom. What this function does
  * is remove empty folders that contained the deleted entry.
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index c5b5364..993f527 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,82 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out)
+{
+    char *result = libxl__xs_read(gc, t, path);
+    if (!result) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "xenstore read failed: `%s'", path);
+            return ERROR_FAIL;
+        }
+    }
+    *result_out = result;
+    return 0;
+}
+
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string)
+{
+    size_t length = strlen(string);
+    if (!xs_write(CTX->xsh, t, path, string, length)) {
+        LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, string);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path)
+{
+    if (!xs_rm(CTX->xsh, t, path)) {
+        if (errno == ENOENT)
+            return 0;
+
+        LOGE(ERROR, "xenstore rm failed: `%s'", path);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(!*t);
+    *t = xs_transaction_start(CTX->xsh);
+    if (!*t) {
+        LOGE(ERROR, "could not create xenstore transaction");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(*t);
+
+    if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        if (errno == EAGAIN)
+            return +1;
+
+        *t = 0;
+        LOGE(ERROR, "could not commit xenstore transaction");
+        return ERROR_FAIL;
+    }
+
+    *t = 0;
+    return 0;
+}
+
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t)
+{
+    if (!*t)
+        return;
+
+    if (!xs_transaction_end(CTX->xsh, *t, 1))
+        LOGE(ERROR, "could not abort xenstore transaction");
+
+    *t = 0;
+}
+
 int libxl__xs_path_cleanup(libxl__gc *gc, xs_transaction_t t, char *user_path)
 {
     unsigned int nb = 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 Jun 15 11:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV71-0005j9-Tx; Fri, 15 Jun 2012 11:54:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005ha-6L
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:36112] by server-9.bemta-14.messagelabs.com id
	CC/C6-27072-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10313 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nj-9R; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YE-7J;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:53 +0100
Message-ID: <1339761246-27641-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/21] libxl: provide libxl__xs_*_checked and
	libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 useful utility functions make dealing with xenstore a little
less painful.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Fixed typo `commited' in comment.

Changes in v3:
 * Fixed typo `transacton' in log messages.
---
 tools/libxl/libxl_internal.h |   38 +++++++++++++++++++++
 tools/libxl/libxl_xshelp.c   |   76 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1a7b526..b108d00 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -498,6 +498,44 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*----- "checked" xenstore access functions -----*/
+/* Each of these functions will check that it succeeded; if it
+ * fails it logs and returns ERROR_FAIL.
+ */
+
+/* On success, *result_out came from the gc.
+ * On error, *result_out is undefined.
+ * ENOENT counts as success but sets *result_out=0
+ */
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out);
+
+/* Does not include a trailing null.
+ * May usefully be combined with GCSPRINTF if the format string
+ * behaviour of libxl__xs_write is desirable. */
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string);
+
+/* ENOENT is not an error (even if the parent directories don't exist) */
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
+
+/* Transaction functions, best used together.
+ * The caller should initialise *t to 0 (XBT_NULL) before calling start.
+ * Each function leaves *t!=0 iff the transaction needs cleaning up.
+ *
+ * libxl__xs_transaction_commit returns:
+ *   <0  failure - a libxl error code
+ *   +1  commit conflict; transaction has been destroyed and caller
+ *        must go round again (call _start again and retry)
+ *    0  committed successfully
+ */
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
+
+
+
 /*
  * This is a recursive delete, from top to bottom. What this function does
  * is remove empty folders that contained the deleted entry.
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index c5b5364..993f527 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,82 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out)
+{
+    char *result = libxl__xs_read(gc, t, path);
+    if (!result) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "xenstore read failed: `%s'", path);
+            return ERROR_FAIL;
+        }
+    }
+    *result_out = result;
+    return 0;
+}
+
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string)
+{
+    size_t length = strlen(string);
+    if (!xs_write(CTX->xsh, t, path, string, length)) {
+        LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, string);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path)
+{
+    if (!xs_rm(CTX->xsh, t, path)) {
+        if (errno == ENOENT)
+            return 0;
+
+        LOGE(ERROR, "xenstore rm failed: `%s'", path);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(!*t);
+    *t = xs_transaction_start(CTX->xsh);
+    if (!*t) {
+        LOGE(ERROR, "could not create xenstore transaction");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(*t);
+
+    if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        if (errno == EAGAIN)
+            return +1;
+
+        *t = 0;
+        LOGE(ERROR, "could not commit xenstore transaction");
+        return ERROR_FAIL;
+    }
+
+    *t = 0;
+    return 0;
+}
+
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t)
+{
+    if (!*t)
+        return;
+
+    if (!xs_transaction_end(CTX->xsh, *t, 1))
+        LOGE(ERROR, "could not abort xenstore transaction");
+
+    *t = 0;
+}
+
 int libxl__xs_path_cleanup(libxl__gc *gc, xs_transaction_t t, char *user_path)
 {
     unsigned int nb = 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 Jun 15 11:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV73-0005kL-C2; Fri, 15 Jun 2012 11:54:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hg-5d
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:36095] by server-8.bemta-14.messagelabs.com id
	3B/96-27132-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10264 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Na-3r; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Xy-2n;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:49 +0100
Message-ID: <1339761246-27641-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/21] libxl: domain restore: reshuffle,
	preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to arrange that libxl, instead of calling
xc_domain_restore, calls a stub function which forks and execs a
helper program, so that restore can be asynchronous rather than
blocking the whole toolstack.

This stub function will be called libxl__xc_domain_restore.

However, its prospective call site is unsuitable for a function which
needs to make a callback, and is buried in two nested single-call-site
functions which are logically part of the domain creation procedure.

So we first abolish those single-call-site functions, integrate their
contents into domain creation in their proper temporal order, and
break out libxl__xc_domain_restore ready for its reimplementation.

No functional change - just the following reorganisation:

* Abolish libxl__domain_restore_common, as it had only one caller.
  Move its contents into (what was) domain_restore.

* There is a new stage function domcreate_rebuild_done containing what
  used to be the bulk of domcreate_bootloader_done, since
  domcreate_bootloader_done now simply starts the restore (or does the
  rebuild) and arranges to call the next stage.

* Move the contents of domain_restore into its correct place in the
  domain creation sequence.  We put it inside
  domcreate_bootloader_done, which now either calls
  libxl__xc_domain_restore which will call the new function
  domcreate_rebuild_done, or calls domcreate_rebuild_done directly.

* Various general-purpose local variables (`i' etc.) and convenience
  alias variables need to be shuffled about accordingly.

* Consequently libxl__toolstack_restore needs to gain external linkage
  as it is now in a different file to its user.

* Move the xc_domain_save callbacks struct from the stack into
  libxl__domain_create_state.

In general the moved code remains almost identical.  Two returns in
what used to be libxl__domain_restore_common have been changed to set
the return value and "goto out", and the call sites for the abolished
and new functions have been adjusted.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v2:
 * Also move the save callbacks
---
 tools/libxl/Makefile             |    1 +
 tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
 tools/libxl/libxl_dom.c          |   45 +-------
 tools/libxl/libxl_internal.h     |   19 +++-
 tools/libxl/libxl_save_callout.c |   37 ++++++
 5 files changed, 206 insertions(+), 140 deletions(-)
 create mode 100644 tools/libxl/libxl_save_callout.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e7d5cc2..1d8b80a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
+			libxl_save_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4456ae8..4439367 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -21,7 +21,6 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
-#include <xenguest.h>
 
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -317,89 +316,6 @@ out:
     return ret;
 }
 
-static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
-                          uint32_t domid, int fd,
-                          libxl__domain_build_state *state)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    char **vments = NULL, **localents = NULL;
-    struct timeval start_time;
-    int i, ret, esave, flags;
-
-    ret = libxl__build_pre(gc, domid, info, state);
-    if (ret)
-        goto out;
-
-    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
-    if (ret)
-        goto out;
-
-    gettimeofday(&start_time, NULL);
-
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        vments = libxl__calloc(gc, 7, sizeof(char *));
-        vments[0] = "rtc/timeoffset";
-        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
-        vments[2] = "image/ostype";
-        vments[3] = "hvm";
-        vments[4] = "start_time";
-        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        vments = libxl__calloc(gc, 11, sizeof(char *));
-        i = 0;
-        vments[i++] = "image/ostype";
-        vments[i++] = "linux";
-        vments[i++] = "image/kernel";
-        vments[i++] = (char *) state->pv_kernel.path;
-        vments[i++] = "start_time";
-        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        if (state->pv_ramdisk.path) {
-            vments[i++] = "image/ramdisk";
-            vments[i++] = (char *) state->pv_ramdisk.path;
-        }
-        if (state->pv_cmdline) {
-            vments[i++] = "image/cmdline";
-            vments[i++] = (char *) state->pv_cmdline;
-        }
-        break;
-    default:
-        ret = ERROR_INVAL;
-        goto out;
-    }
-    ret = libxl__build_post(gc, domid, info, state, vments, localents);
-    if (ret)
-        goto out;
-
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
-                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
-    }
-
-out:
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
-        libxl__file_reference_unmap(&state->pv_kernel);
-        libxl__file_reference_unmap(&state->pv_ramdisk);
-    }
-
-    esave = errno;
-
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
-    } else {
-        flags &= ~O_NONBLOCK;
-        if (fcntl(fd, F_SETFL, flags) == -1)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
-                         " back to blocking mode");
-    }
-
-    errno = esave;
-    return ret;
-}
-
 int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
@@ -580,10 +496,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
-
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -671,20 +590,20 @@ static void domcreate_console_available(libxl__egc *egc,
 
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
-                                      int ret)
+                                      int rc)
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    libxl_ctx *const ctx = CTX;
+    struct restore_callbacks *const callbacks = &dcs->callbacks;
 
-    if (ret) goto error_out;
+    if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
     /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
      * been initialised by the bootloader already.
@@ -700,12 +619,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
+    if ( restore_fd < 0 ) {
+        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    /* Restore */
+
+    rc = libxl__build_pre(gc, domid, info, state);
+    if (rc)
+        goto out;
+
+    /* read signature */
+    int hvm, pae, superpages;
+    int no_incr_generationid;
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        hvm = 1;
+        superpages = 1;
+        pae = libxl_defbool_val(info->u.hvm.pae);
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        hvm = 0;
+        superpages = 0;
+        pae = 1;
+        no_incr_generationid = 0;
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+    libxl__xc_domain_restore(egc, dcs,
+                             hvm, pae, superpages, no_incr_generationid);
+    return;
+
+ out:
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret, int retval, int errnoval)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char **vments = NULL, **localents = NULL;
+    struct timeval start_time;
+    int i, esave, flags;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    const int fd = dcs->restore_fd;
+
+    if (ret)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "restoring domain");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    gettimeofday(&start_time, NULL);
+
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        vments = libxl__calloc(gc, 7, sizeof(char *));
+        vments[0] = "rtc/timeoffset";
+        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
+        vments[2] = "image/ostype";
+        vments[3] = "hvm";
+        vments[4] = "start_time";
+        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        vments = libxl__calloc(gc, 11, sizeof(char *));
+        i = 0;
+        vments[i++] = "image/ostype";
+        vments[i++] = "linux";
+        vments[i++] = "image/kernel";
+        vments[i++] = (char *) state->pv_kernel.path;
+        vments[i++] = "start_time";
+        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        if (state->pv_ramdisk.path) {
+            vments[i++] = "image/ramdisk";
+            vments[i++] = (char *) state->pv_ramdisk.path;
+        }
+        if (state->pv_cmdline) {
+            vments[i++] = "image/cmdline";
+            vments[i++] = (char *) state->pv_cmdline;
+        }
+        break;
+    default:
+        ret = ERROR_INVAL;
+        goto out;
+    }
+    ret = libxl__build_post(gc, domid, info, state, vments, localents);
+    if (ret)
+        goto out;
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = asprintf(&state->saved_state,
+                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+        ret = (ret < 0) ? ERROR_FAIL : 0;
+    }
+
+out:
+    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+        libxl__file_reference_unmap(&state->pv_kernel);
+        libxl__file_reference_unmap(&state->pv_ramdisk);
+    }
+
+    esave = errno;
+
+    flags = fcntl(fd, F_GETFL);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        flags &= ~O_NONBLOCK;
+        if (fcntl(fd, F_SETFL, flags) == -1)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
+                         " back to blocking mode");
     }
 
+    errno = esave;
+    domcreate_rebuild_done(egc, dcs, ret);
+}
+
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret)
+{
+    STATE_AO_GC(dcs->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
         ret = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e90030d..1d4e809 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -19,7 +19,6 @@
 
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xenguest.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
@@ -467,7 +466,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = data;
@@ -522,48 +521,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                 libxl_domain_build_info *info,
-                                 libxl__domain_build_state *state,
-                                 int fd)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    /* read signature */
-    int rc;
-    int hvm, pae, superpages;
-    struct restore_callbacks callbacks[1];
-    int no_incr_generationid;
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        hvm = 1;
-        superpages = 1;
-        pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        hvm = 0;
-        superpages = 0;
-        pae = 1;
-        no_incr_generationid = 0;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-    rc = xc_domain_restore(ctx->xch, fd, domid,
-                           state->store_port, &state->store_mfn,
-                           state->store_domid, state->console_port,
-                           &state->console_mfn, state->console_domid,
-                           hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, callbacks);
-    if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 static int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f22bf94..28478ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -46,6 +46,7 @@
 
 #include <xenstore.h>
 #include <xenctrl.h>
+#include <xenguest.h>
 
 #include "xentoollog.h"
 
@@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
 
-_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                         libxl_domain_build_info *info,
-                                         libxl__domain_build_state *state,
-                                         int fd);
+_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+                                     uint32_t size, void *data);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    struct restore_callbacks callbacks;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          int live, int debug,
                                          const libxl_domain_remus_info *r_info);
 
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_restore(libxl__egc *egc,
+                                      libxl__domain_create_state *dcs,
+                                      int hvm, int pae, int superpages,
+                                      int no_incr_generationid);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                           libxl__domain_create_state *dcs,
+                                           int rc, int retval, int errnoval);
 
 
 /*
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
new file mode 100644
index 0000000..2f8db9f
--- /dev/null
+++ b/tools/libxl/libxl_save_callout.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h"
+
+#include "libxl_internal.h"
+
+void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
+                              int hvm, int pae, int superpages,
+                              int no_incr_generationid)
+{
+    STATE_AO_GC(dcs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
+                              state->store_port, &state->store_mfn,
+                              state->store_domid, state->console_port,
+                              &state->console_mfn, state->console_domid,
+                              hvm, pae, superpages, no_incr_generationid,
+                              &state->vm_generationid_addr, &dcs->callbacks);
+    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+}
-- 
1.7.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 Jun 15 11:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV76-0005o4-Vn; Fri, 15 Jun 2012 11:54:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005ij-RB
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [193.109.254.147:36228] by server-5.bemta-14.messagelabs.com id
	48/6A-31398-7822BDF4; Fri, 15 Jun 2012 11:54:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10438 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005OF-Ue; Fri, 15 Jun 2012 11:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Z0-RO;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:05 +0100
Message-ID: <1339761246-27641-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/21] libxl: further fixups re LIBXL_DOMAIN_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

* Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
  handlng.  At every call site, replace it with an open-coded call to
  libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.

* This involves adding an `out:' to libxl_domain_unpause.

* In libxl_domain_destroy and do_pci_add, do not `default: abort();'
  if the domain type cannot be found.  Instead switch on
  LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
  handling.

* In libxl__primary_console_find, remove a spurious default clause
  from the domain type switch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v4 of series:
 * Hunk
     In libxl_domain_suspend (as reorganised) error check, check for
     LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
   merged into the earlier patch where the slightly-wrong code was
   introduced.
---
 tools/libxl/libxl.c          |   30 +++++++++++++++++++++++-------
 tools/libxl/libxl_internal.h |    5 +++--
 tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
 3 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d3b017b..cd2dbda 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
         goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_resume_device_model(gc, domid);
         if (rc) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -788,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
@@ -802,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
+ out:
     GC_FREE;
     return rc;
 }
@@ -813,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
     unsigned long pvdriver = 0;
     int ret;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV)
         return 1;
 
     ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
@@ -1213,8 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     dom_path = libxl__xs_get_dompath(gc, domid);
@@ -1362,8 +1380,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
         case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-        default:
-            abort();
         }
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9df0db5..36c75ed 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
 _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
                                     libxl_domain_sched_params *scparams);
-#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
-    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
+
 typedef struct {
     uint32_t store_port;
     uint32_t store_domid;
@@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+/* returns 0 or 1, or a libxl error code */
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+
 _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
                                             xs_transaction_t t, uint32_t domid);
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..81438be 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
     if (!num_devs)
         return libxl__create_pci_backend(gc, domid, pcidev, 1);
 
-    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0)
             return ERROR_FAIL;
     }
@@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
         return ERROR_INVAL;
     num = atoi(num_devs);
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -199,7 +207,7 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
         }
         break;
     }
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        return ERROR_FAIL;
     }
 out:
     if (!libxl_is_stubdom(ctx, domid, 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 Jun 15 11:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV73-0005kL-C2; Fri, 15 Jun 2012 11:54:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hg-5d
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [193.109.254.147:36095] by server-8.bemta-14.messagelabs.com id
	3B/96-27132-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10264 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Na-3r; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Xy-2n;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:49 +0100
Message-ID: <1339761246-27641-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/21] libxl: domain restore: reshuffle,
	preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to arrange that libxl, instead of calling
xc_domain_restore, calls a stub function which forks and execs a
helper program, so that restore can be asynchronous rather than
blocking the whole toolstack.

This stub function will be called libxl__xc_domain_restore.

However, its prospective call site is unsuitable for a function which
needs to make a callback, and is buried in two nested single-call-site
functions which are logically part of the domain creation procedure.

So we first abolish those single-call-site functions, integrate their
contents into domain creation in their proper temporal order, and
break out libxl__xc_domain_restore ready for its reimplementation.

No functional change - just the following reorganisation:

* Abolish libxl__domain_restore_common, as it had only one caller.
  Move its contents into (what was) domain_restore.

* There is a new stage function domcreate_rebuild_done containing what
  used to be the bulk of domcreate_bootloader_done, since
  domcreate_bootloader_done now simply starts the restore (or does the
  rebuild) and arranges to call the next stage.

* Move the contents of domain_restore into its correct place in the
  domain creation sequence.  We put it inside
  domcreate_bootloader_done, which now either calls
  libxl__xc_domain_restore which will call the new function
  domcreate_rebuild_done, or calls domcreate_rebuild_done directly.

* Various general-purpose local variables (`i' etc.) and convenience
  alias variables need to be shuffled about accordingly.

* Consequently libxl__toolstack_restore needs to gain external linkage
  as it is now in a different file to its user.

* Move the xc_domain_save callbacks struct from the stack into
  libxl__domain_create_state.

In general the moved code remains almost identical.  Two returns in
what used to be libxl__domain_restore_common have been changed to set
the return value and "goto out", and the call sites for the abolished
and new functions have been adjusted.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v2:
 * Also move the save callbacks
---
 tools/libxl/Makefile             |    1 +
 tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
 tools/libxl/libxl_dom.c          |   45 +-------
 tools/libxl/libxl_internal.h     |   19 +++-
 tools/libxl/libxl_save_callout.c |   37 ++++++
 5 files changed, 206 insertions(+), 140 deletions(-)
 create mode 100644 tools/libxl/libxl_save_callout.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e7d5cc2..1d8b80a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
+			libxl_save_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4456ae8..4439367 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -21,7 +21,6 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
-#include <xenguest.h>
 
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -317,89 +316,6 @@ out:
     return ret;
 }
 
-static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
-                          uint32_t domid, int fd,
-                          libxl__domain_build_state *state)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    char **vments = NULL, **localents = NULL;
-    struct timeval start_time;
-    int i, ret, esave, flags;
-
-    ret = libxl__build_pre(gc, domid, info, state);
-    if (ret)
-        goto out;
-
-    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
-    if (ret)
-        goto out;
-
-    gettimeofday(&start_time, NULL);
-
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        vments = libxl__calloc(gc, 7, sizeof(char *));
-        vments[0] = "rtc/timeoffset";
-        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
-        vments[2] = "image/ostype";
-        vments[3] = "hvm";
-        vments[4] = "start_time";
-        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        vments = libxl__calloc(gc, 11, sizeof(char *));
-        i = 0;
-        vments[i++] = "image/ostype";
-        vments[i++] = "linux";
-        vments[i++] = "image/kernel";
-        vments[i++] = (char *) state->pv_kernel.path;
-        vments[i++] = "start_time";
-        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        if (state->pv_ramdisk.path) {
-            vments[i++] = "image/ramdisk";
-            vments[i++] = (char *) state->pv_ramdisk.path;
-        }
-        if (state->pv_cmdline) {
-            vments[i++] = "image/cmdline";
-            vments[i++] = (char *) state->pv_cmdline;
-        }
-        break;
-    default:
-        ret = ERROR_INVAL;
-        goto out;
-    }
-    ret = libxl__build_post(gc, domid, info, state, vments, localents);
-    if (ret)
-        goto out;
-
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
-                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
-    }
-
-out:
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
-        libxl__file_reference_unmap(&state->pv_kernel);
-        libxl__file_reference_unmap(&state->pv_ramdisk);
-    }
-
-    esave = errno;
-
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
-    } else {
-        flags &= ~O_NONBLOCK;
-        if (fcntl(fd, F_SETFL, flags) == -1)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
-                         " back to blocking mode");
-    }
-
-    errno = esave;
-    return ret;
-}
-
 int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
@@ -580,10 +496,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
-
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -671,20 +590,20 @@ static void domcreate_console_available(libxl__egc *egc,
 
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
-                                      int ret)
+                                      int rc)
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    libxl_ctx *const ctx = CTX;
+    struct restore_callbacks *const callbacks = &dcs->callbacks;
 
-    if (ret) goto error_out;
+    if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
     /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
      * been initialised by the bootloader already.
@@ -700,12 +619,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
+    if ( restore_fd < 0 ) {
+        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    /* Restore */
+
+    rc = libxl__build_pre(gc, domid, info, state);
+    if (rc)
+        goto out;
+
+    /* read signature */
+    int hvm, pae, superpages;
+    int no_incr_generationid;
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        hvm = 1;
+        superpages = 1;
+        pae = libxl_defbool_val(info->u.hvm.pae);
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        hvm = 0;
+        superpages = 0;
+        pae = 1;
+        no_incr_generationid = 0;
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+    libxl__xc_domain_restore(egc, dcs,
+                             hvm, pae, superpages, no_incr_generationid);
+    return;
+
+ out:
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret, int retval, int errnoval)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char **vments = NULL, **localents = NULL;
+    struct timeval start_time;
+    int i, esave, flags;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    const int fd = dcs->restore_fd;
+
+    if (ret)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "restoring domain");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    gettimeofday(&start_time, NULL);
+
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        vments = libxl__calloc(gc, 7, sizeof(char *));
+        vments[0] = "rtc/timeoffset";
+        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
+        vments[2] = "image/ostype";
+        vments[3] = "hvm";
+        vments[4] = "start_time";
+        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        vments = libxl__calloc(gc, 11, sizeof(char *));
+        i = 0;
+        vments[i++] = "image/ostype";
+        vments[i++] = "linux";
+        vments[i++] = "image/kernel";
+        vments[i++] = (char *) state->pv_kernel.path;
+        vments[i++] = "start_time";
+        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        if (state->pv_ramdisk.path) {
+            vments[i++] = "image/ramdisk";
+            vments[i++] = (char *) state->pv_ramdisk.path;
+        }
+        if (state->pv_cmdline) {
+            vments[i++] = "image/cmdline";
+            vments[i++] = (char *) state->pv_cmdline;
+        }
+        break;
+    default:
+        ret = ERROR_INVAL;
+        goto out;
+    }
+    ret = libxl__build_post(gc, domid, info, state, vments, localents);
+    if (ret)
+        goto out;
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = asprintf(&state->saved_state,
+                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+        ret = (ret < 0) ? ERROR_FAIL : 0;
+    }
+
+out:
+    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+        libxl__file_reference_unmap(&state->pv_kernel);
+        libxl__file_reference_unmap(&state->pv_ramdisk);
+    }
+
+    esave = errno;
+
+    flags = fcntl(fd, F_GETFL);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        flags &= ~O_NONBLOCK;
+        if (fcntl(fd, F_SETFL, flags) == -1)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
+                         " back to blocking mode");
     }
 
+    errno = esave;
+    domcreate_rebuild_done(egc, dcs, ret);
+}
+
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret)
+{
+    STATE_AO_GC(dcs->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
         ret = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e90030d..1d4e809 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -19,7 +19,6 @@
 
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xenguest.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
@@ -467,7 +466,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = data;
@@ -522,48 +521,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                 libxl_domain_build_info *info,
-                                 libxl__domain_build_state *state,
-                                 int fd)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    /* read signature */
-    int rc;
-    int hvm, pae, superpages;
-    struct restore_callbacks callbacks[1];
-    int no_incr_generationid;
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        hvm = 1;
-        superpages = 1;
-        pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        hvm = 0;
-        superpages = 0;
-        pae = 1;
-        no_incr_generationid = 0;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-    rc = xc_domain_restore(ctx->xch, fd, domid,
-                           state->store_port, &state->store_mfn,
-                           state->store_domid, state->console_port,
-                           &state->console_mfn, state->console_domid,
-                           hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, callbacks);
-    if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 static int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f22bf94..28478ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -46,6 +46,7 @@
 
 #include <xenstore.h>
 #include <xenctrl.h>
+#include <xenguest.h>
 
 #include "xentoollog.h"
 
@@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
 
-_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                         libxl_domain_build_info *info,
-                                         libxl__domain_build_state *state,
-                                         int fd);
+_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+                                     uint32_t size, void *data);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    struct restore_callbacks callbacks;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          int live, int debug,
                                          const libxl_domain_remus_info *r_info);
 
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_restore(libxl__egc *egc,
+                                      libxl__domain_create_state *dcs,
+                                      int hvm, int pae, int superpages,
+                                      int no_incr_generationid);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                           libxl__domain_create_state *dcs,
+                                           int rc, int retval, int errnoval);
 
 
 /*
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
new file mode 100644
index 0000000..2f8db9f
--- /dev/null
+++ b/tools/libxl/libxl_save_callout.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h"
+
+#include "libxl_internal.h"
+
+void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
+                              int hvm, int pae, int superpages,
+                              int no_incr_generationid)
+{
+    STATE_AO_GC(dcs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
+                              state->store_port, &state->store_mfn,
+                              state->store_domid, state->console_port,
+                              &state->console_mfn, state->console_domid,
+                              hvm, pae, superpages, no_incr_generationid,
+                              &state->vm_generationid_addr, &dcs->callbacks);
+    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+}
-- 
1.7.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 Jun 15 11:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV75-0005lY-0H; Fri, 15 Jun 2012 11:54:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hp-UZ
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:18959] by server-3.bemta-4.messagelabs.com id
	12/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23627 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nf-6P; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Y6-5E;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:51 +0100
Message-ID: <1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v4:
 * Migration stream fd is handled specially by the run_helper
   function, rather than simply being a numarg.  Specifically:
     - dup it to a safe fd number if necessary.
     - clear cloexec flag fd before execing helper
 * Toolstack data fd argument to run_helper replaced with
   generic preserve_fds array, which get cloexec cleared.
 * libxl__xc_domain_save uses supplied callback function pointer,
   rather than calling libxl__toolstack_save directly;
   toolstack data save callback is only supplied to libxc if
   in-libxl caller supplied a callback.
 * libxl-save-helper is not needlessly linked against libxl.
 * Code which prepares pipes for helper clarified.
 * Deal properly with, and log properly, POLLPRI/POLLERR on
   pipe to save helper.
 * Spelling fix in perl script comment.
 * In message generator, use better names for the ends of serial
   conditional here documents.
 * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.
---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   22 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   36 ++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  366 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  281 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1145 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_save_helper.c
 create mode 100755 tools/libxl/libxl_save_msgs_gen.pl

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..ddc2624 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -169,7 +183,9 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4439367..00705d8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -601,7 +601,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -641,7 +642,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -661,10 +661,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b48452c..fea0c94 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -465,16 +465,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -527,9 +531,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -595,9 +600,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -737,9 +743,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -808,6 +814,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -862,7 +870,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -923,8 +932,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -933,10 +941,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7cf1b04..1a7b526 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..007d61c 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,30 @@
 
 #include "libxl_internal.h"
 
+/* stream_fd is as from the caller (eventually, the application).
+ * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
+ * The actual fd value is not included in the supplied argnums; rather
+ * it will be automatically supplied by run_helper as the 2nd argument.
+ *
+ * preserve_fds are fds that the caller is intending to pass to the
+ * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
+ * An entry may be -1 in which case it will be ignored.
+ */
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg,
+                       int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +51,342 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc, toolstack_data_fd = -1;
+    uint32_t toolstack_data_len = 0;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    if (dss->shs.callbacks.save.toolstack_save) {
+        r = dss->shs.callbacks.save.toolstack_save
+            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        dss->shs.toolstack_data_file = tmpfile();
+        if (!dss->shs.toolstack_data_file) {
+            LOGE(ERROR, "cannot create toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+        r = libxl_write_exactly(CTX, toolstack_data_fd,
+                                toolstack_data_buf, toolstack_data_len,
+                                "toolstack data tmpfile", 0);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        r = lseek(toolstack_data_fd, 0, SEEK_SET);
+        if (r) {
+            LOGE(ERROR, "rewind toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    const unsigned long argnums[] = {
+        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               &toolstack_data_fd, 1,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[4 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    const char **stream_fd_arg = arg++;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    int childfd;
+    for (childfd=0; childfd<2; childfd++) {
+        /* Setting up the pipe for the child's fd childfd */
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
+        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
+        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
+        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        if (stream_fd <= 2) {
+            stream_fd = dup(stream_fd);
+            if (stream_fd < 0) {
+                LOGE(ERROR,"dup migration stream fd");
+                exit(-1);
+            }
+        }
+        libxl_fd_set_cloexec(CTX, stream_fd, 0);
+        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
+
+        for (i=0; i<num_preserve_fds; i++)
+            if (preserve_fds[i] >= 0)
+                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
+
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & (POLLERR|POLLPRI)) {
+        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
+            shs->stdout_what, revents);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..3bdfa28
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,281 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    *buf = xmalloc(toolstack_save_len);
+    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    toolstack_save_fd = -1;
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        if (toolstack_save_fd >= 0)
+            helper_save_callbacks.toolstack_save = toolstack_save_cb;
+
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..c45986e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,397 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copious debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .=
+        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END_BOTH
+
+#include "libxl_internal.h"
+
+END_CALLOUT
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END_HELPER
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END_ALWAYS
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END_DEBUG
+    switch (mtype) {
+
+END_ALWAYS
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END_DEBUG
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END_ALWAYS
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name",
+               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
+    int r = ${helper}_getreply(user);
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END_DEBUG
+    return r;
+END_ALWAYS
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
1.7.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 Jun 15 11:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV75-0005mC-Ex; Fri, 15 Jun 2012 11:54:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005hg-8E
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [193.109.254.147:19405] by server-8.bemta-14.messagelabs.com id
	7E/96-27132-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10388 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nv-GS; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YU-EU;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:57 +0100
Message-ID: <1339761246-27641-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/21] libxl: Make
	libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in series v3:
 * Improve one more a debugging message.
---
 tools/libxl/libxl_dom.c      |  100 +++++++++++++++++++++++++++---------------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e104744..dbae98c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1148,15 +1148,17 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
 void libxl__domain_save_device_model(libxl__egc *egc,
                                      libxl__domain_suspend_state *dss,
                                      libxl__save_device_model_cb *callback)
 {
     STATE_AO_GC(dss->ao);
-    int rc, fd2 = -1, c;
-    char buf[1024];
     struct stat st;
     uint32_t qemu_state_len;
+    int rc;
 
     dss->save_dm_callback = callback;
 
@@ -1164,49 +1166,77 @@ void libxl__domain_save_device_model(libxl__egc *egc,
     const char *const filename = dss->dm_savefile;
     const int fd = dss->fd;
 
-    if (stat(filename, &st) < 0)
+    libxl__datacopier_state *dc = &dss->save_dm_datacopier;
+    memset(dc, 0, sizeof(*dc));
+    dc->readwhat = GCSPRINTF("qemu save file %s", filename);
+    dc->ao = ao;
+    dc->readfd = -1;
+    dc->writefd = fd;
+    dc->maxsz = INT_MAX;
+    dc->copywhat = GCSPRINTF("qemu save file for domain %"PRIu32, dss->domid);
+    dc->writewhat = "save/migration stream";
+    dc->callback = save_device_model_datacopier_done;
+
+    dc->readfd = open(filename, O_RDONLY);
+    if (dc->readfd < 0) {
+        LOGE(ERROR, "unable to open %s", dc->readwhat);
+        goto out;
+    }
+
+    if (fstat(dc->readfd, &st))
     {
-        LOG(ERROR, "Unable to stat qemu save file\n");
-        rc = ERROR_FAIL;
+        LOGE(ERROR, "unable to fstat %s", dc->readwhat);
+        goto out;
+    }
+
+    if (!S_ISREG(st.st_mode)) {
+        LOG(ERROR, "%s is not a plain file!", dc->readwhat);
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "%s is %d bytes", dc->readwhat, qemu_state_len);
 
-    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
-    if (rc)
-        goto out;
+    rc = libxl__datacopier_start(dc);
+    if (rc) goto out;
 
-    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
-                            "saved-state file", "saved-state length");
-    if (rc)
-        goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 QEMU_SIGNATURE, strlen(QEMU_SIGNATURE));
 
-    fd2 = open(filename, O_RDONLY);
-    if (fd2 < 0) {
-        LOGE(ERROR, "Unable to open qemu save file\n");
-        goto out;
-    }
-    while ((c = read(fd2, buf, sizeof(buf))) != 0) {
-        if (c < 0) {
-            if (errno == EINTR)
-                continue;
-            rc = errno;
-            goto out;
-        }
-        rc = libxl_write_exactly(
-            CTX, fd, buf, c, "saved-state file", "qemu state");
-        if (rc)
-            goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 &qemu_state_len, sizeof(qemu_state_len));
+    return;
+
+ out:
+    save_device_model_datacopier_done(egc, dc, -1, 0);
+}
+
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(dc, *dss, save_dm_datacopier);
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    int our_rc = 0;
+    int rc;
+
+    libxl__datacopier_kill(dc);
+
+    if (onwrite || errnoval)
+        our_rc = ERROR_FAIL;
+
+    if (dc->readfd >= 0) {
+        close(dc->readfd);
+        dc->readfd = -1;
     }
-    rc = 0;
-out:
-    if (fd2 >= 0) close(fd2);
-    unlink(filename);
 
-    dss->save_dm_callback(egc, dss, rc);
+    rc = libxl__remove_file(gc, filename);
+    if (!our_rc) our_rc = rc;
+
+    dss->save_dm_callback(egc, dss, our_rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e95892a..c9b4189 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1901,6 +1901,7 @@ struct libxl__domain_suspend_state {
     libxl__logdirty_switch logdirty;
     /* private for libxl__domain_save_device_model */
     libxl__save_device_model_cb *save_dm_callback;
+    libxl__datacopier_state save_dm_datacopier;
 };
 
 
-- 
1.7.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 Jun 15 11:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV76-0005o4-Vn; Fri, 15 Jun 2012 11:54:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005ij-RB
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:48 +0000
Received: from [193.109.254.147:36228] by server-5.bemta-14.messagelabs.com id
	48/6A-31398-7822BDF4; Fri, 15 Jun 2012 11:54:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10438 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005OF-Ue; Fri, 15 Jun 2012 11:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Z0-RO;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:05 +0100
Message-ID: <1339761246-27641-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/21] libxl: further fixups re LIBXL_DOMAIN_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

* Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
  handlng.  At every call site, replace it with an open-coded call to
  libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.

* This involves adding an `out:' to libxl_domain_unpause.

* In libxl_domain_destroy and do_pci_add, do not `default: abort();'
  if the domain type cannot be found.  Instead switch on
  LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
  handling.

* In libxl__primary_console_find, remove a spurious default clause
  from the domain type switch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v4 of series:
 * Hunk
     In libxl_domain_suspend (as reorganised) error check, check for
     LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
   merged into the earlier patch where the slightly-wrong code was
   introduced.
---
 tools/libxl/libxl.c          |   30 +++++++++++++++++++++++-------
 tools/libxl/libxl_internal.h |    5 +++--
 tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
 3 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d3b017b..cd2dbda 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
         goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_resume_device_model(gc, domid);
         if (rc) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -788,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
@@ -802,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
+ out:
     GC_FREE;
     return rc;
 }
@@ -813,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
     unsigned long pvdriver = 0;
     int ret;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV)
         return 1;
 
     ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
@@ -1213,8 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        rc = ERROR_FAIL;
+        goto out;
     }
 
     dom_path = libxl__xs_get_dompath(gc, domid);
@@ -1362,8 +1380,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
         case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-        default:
-            abort();
         }
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9df0db5..36c75ed 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
 _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
                                     libxl_domain_sched_params *scparams);
-#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
-    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
+
 typedef struct {
     uint32_t store_port;
     uint32_t store_domid;
@@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+/* returns 0 or 1, or a libxl error code */
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+
 _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
                                             xs_transaction_t t, uint32_t domid);
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..81438be 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
     if (!num_devs)
         return libxl__create_pci_backend(gc, domid, pcidev, 1);
 
-    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0)
             return ERROR_FAIL;
     }
@@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
         return ERROR_INVAL;
     num = atoi(num_devs);
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -199,7 +207,7 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
         }
         break;
     }
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        return ERROR_FAIL;
     }
 out:
     if (!libxl_is_stubdom(ctx, domid, 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 Jun 15 11:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV75-0005lY-0H; Fri, 15 Jun 2012 11:54:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV70-0005hp-UZ
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:18959] by server-3.bemta-4.messagelabs.com id
	12/D1-05808-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23627 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nf-6P; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Y6-5E;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:51 +0100
Message-ID: <1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Changes in v4:
 * Migration stream fd is handled specially by the run_helper
   function, rather than simply being a numarg.  Specifically:
     - dup it to a safe fd number if necessary.
     - clear cloexec flag fd before execing helper
 * Toolstack data fd argument to run_helper replaced with
   generic preserve_fds array, which get cloexec cleared.
 * libxl__xc_domain_save uses supplied callback function pointer,
   rather than calling libxl__toolstack_save directly;
   toolstack data save callback is only supplied to libxc if
   in-libxl caller supplied a callback.
 * libxl-save-helper is not needlessly linked against libxl.
 * Code which prepares pipes for helper clarified.
 * Deal properly with, and log properly, POLLPRI/POLLERR on
   pipe to save helper.
 * Spelling fix in perl script comment.
 * In message generator, use better names for the ends of serial
   conditional here documents.
 * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.
---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   22 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   36 ++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  366 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  281 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1145 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_save_helper.c
 create mode 100755 tools/libxl/libxl_save_msgs_gen.pl

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..ddc2624 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -169,7 +183,9 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 4439367..00705d8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -601,7 +601,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -641,7 +642,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -661,10 +661,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b48452c..fea0c94 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -465,16 +465,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -527,9 +531,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -595,9 +600,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -737,9 +743,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -808,6 +814,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -862,7 +870,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -923,8 +932,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -933,10 +941,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7cf1b04..1a7b526 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..007d61c 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,30 @@
 
 #include "libxl_internal.h"
 
+/* stream_fd is as from the caller (eventually, the application).
+ * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
+ * The actual fd value is not included in the supplied argnums; rather
+ * it will be automatically supplied by run_helper as the 2nd argument.
+ *
+ * preserve_fds are fds that the caller is intending to pass to the
+ * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
+ * An entry may be -1 in which case it will be ignored.
+ */
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg,
+                       int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +51,342 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc, toolstack_data_fd = -1;
+    uint32_t toolstack_data_len = 0;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    if (dss->shs.callbacks.save.toolstack_save) {
+        r = dss->shs.callbacks.save.toolstack_save
+            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        dss->shs.toolstack_data_file = tmpfile();
+        if (!dss->shs.toolstack_data_file) {
+            LOGE(ERROR, "cannot create toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+        r = libxl_write_exactly(CTX, toolstack_data_fd,
+                                toolstack_data_buf, toolstack_data_len,
+                                "toolstack data tmpfile", 0);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        r = lseek(toolstack_data_fd, 0, SEEK_SET);
+        if (r) {
+            LOGE(ERROR, "rewind toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    const unsigned long argnums[] = {
+        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               &toolstack_data_fd, 1,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[4 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    const char **stream_fd_arg = arg++;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    int childfd;
+    for (childfd=0; childfd<2; childfd++) {
+        /* Setting up the pipe for the child's fd childfd */
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
+        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
+        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
+        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        if (stream_fd <= 2) {
+            stream_fd = dup(stream_fd);
+            if (stream_fd < 0) {
+                LOGE(ERROR,"dup migration stream fd");
+                exit(-1);
+            }
+        }
+        libxl_fd_set_cloexec(CTX, stream_fd, 0);
+        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
+
+        for (i=0; i<num_preserve_fds; i++)
+            if (preserve_fds[i] >= 0)
+                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
+
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & (POLLERR|POLLPRI)) {
+        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
+            shs->stdout_what, revents);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..3bdfa28
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,281 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    *buf = xmalloc(toolstack_save_len);
+    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    toolstack_save_fd = -1;
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        if (toolstack_save_fd >= 0)
+            helper_save_callbacks.toolstack_save = toolstack_save_cb;
+
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..c45986e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,397 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copious debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .=
+        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END_BOTH
+
+#include "libxl_internal.h"
+
+END_CALLOUT
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END_HELPER
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END_ALWAYS
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END_DEBUG
+    switch (mtype) {
+
+END_ALWAYS
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END_DEBUG
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END_ALWAYS
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name",
+               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
+    int r = ${helper}_getreply(user);
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END_DEBUG
+    return r;
+END_ALWAYS
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
1.7.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 Jun 15 11:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV75-0005mC-Ex; Fri, 15 Jun 2012 11:54:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005hg-8E
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [193.109.254.147:19405] by server-8.bemta-14.messagelabs.com id
	7E/96-27132-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10388 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nv-GS; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YU-EU;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:57 +0100
Message-ID: <1339761246-27641-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/21] libxl: Make
	libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in series v3:
 * Improve one more a debugging message.
---
 tools/libxl/libxl_dom.c      |  100 +++++++++++++++++++++++++++---------------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e104744..dbae98c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1148,15 +1148,17 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
 void libxl__domain_save_device_model(libxl__egc *egc,
                                      libxl__domain_suspend_state *dss,
                                      libxl__save_device_model_cb *callback)
 {
     STATE_AO_GC(dss->ao);
-    int rc, fd2 = -1, c;
-    char buf[1024];
     struct stat st;
     uint32_t qemu_state_len;
+    int rc;
 
     dss->save_dm_callback = callback;
 
@@ -1164,49 +1166,77 @@ void libxl__domain_save_device_model(libxl__egc *egc,
     const char *const filename = dss->dm_savefile;
     const int fd = dss->fd;
 
-    if (stat(filename, &st) < 0)
+    libxl__datacopier_state *dc = &dss->save_dm_datacopier;
+    memset(dc, 0, sizeof(*dc));
+    dc->readwhat = GCSPRINTF("qemu save file %s", filename);
+    dc->ao = ao;
+    dc->readfd = -1;
+    dc->writefd = fd;
+    dc->maxsz = INT_MAX;
+    dc->copywhat = GCSPRINTF("qemu save file for domain %"PRIu32, dss->domid);
+    dc->writewhat = "save/migration stream";
+    dc->callback = save_device_model_datacopier_done;
+
+    dc->readfd = open(filename, O_RDONLY);
+    if (dc->readfd < 0) {
+        LOGE(ERROR, "unable to open %s", dc->readwhat);
+        goto out;
+    }
+
+    if (fstat(dc->readfd, &st))
     {
-        LOG(ERROR, "Unable to stat qemu save file\n");
-        rc = ERROR_FAIL;
+        LOGE(ERROR, "unable to fstat %s", dc->readwhat);
+        goto out;
+    }
+
+    if (!S_ISREG(st.st_mode)) {
+        LOG(ERROR, "%s is not a plain file!", dc->readwhat);
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "%s is %d bytes", dc->readwhat, qemu_state_len);
 
-    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
-    if (rc)
-        goto out;
+    rc = libxl__datacopier_start(dc);
+    if (rc) goto out;
 
-    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
-                            "saved-state file", "saved-state length");
-    if (rc)
-        goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 QEMU_SIGNATURE, strlen(QEMU_SIGNATURE));
 
-    fd2 = open(filename, O_RDONLY);
-    if (fd2 < 0) {
-        LOGE(ERROR, "Unable to open qemu save file\n");
-        goto out;
-    }
-    while ((c = read(fd2, buf, sizeof(buf))) != 0) {
-        if (c < 0) {
-            if (errno == EINTR)
-                continue;
-            rc = errno;
-            goto out;
-        }
-        rc = libxl_write_exactly(
-            CTX, fd, buf, c, "saved-state file", "qemu state");
-        if (rc)
-            goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 &qemu_state_len, sizeof(qemu_state_len));
+    return;
+
+ out:
+    save_device_model_datacopier_done(egc, dc, -1, 0);
+}
+
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(dc, *dss, save_dm_datacopier);
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    int our_rc = 0;
+    int rc;
+
+    libxl__datacopier_kill(dc);
+
+    if (onwrite || errnoval)
+        our_rc = ERROR_FAIL;
+
+    if (dc->readfd >= 0) {
+        close(dc->readfd);
+        dc->readfd = -1;
     }
-    rc = 0;
-out:
-    if (fd2 >= 0) close(fd2);
-    unlink(filename);
 
-    dss->save_dm_callback(egc, dss, rc);
+    rc = libxl__remove_file(gc, filename);
+    if (!our_rc) our_rc = rc;
+
+    dss->save_dm_callback(egc, dss, our_rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e95892a..c9b4189 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1901,6 +1901,7 @@ struct libxl__domain_suspend_state {
     libxl__logdirty_switch logdirty;
     /* private for libxl__domain_save_device_model */
     libxl__save_device_model_cb *save_dm_callback;
+    libxl__datacopier_state save_dm_datacopier;
 };
 
 
-- 
1.7.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 Jun 15 11:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV74-0005kz-6z; Fri, 15 Jun 2012 11:54: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 1SfV71-0005i6-34
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:62731] by server-1.bemta-4.messagelabs.com id
	D3/38-24392-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23694 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005OC-Rm; Fri, 15 Jun 2012 11:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yw-P9;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:04 +0100
Message-ID: <1339761246-27641-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/21] libxl: do not leak an event struct on
	ignored ao 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 entry to libxl__ao_progress_report, the caller has allocated an
event.  If the progress report is to be ignored, we need to free it.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index eb23a93..1957505 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1602,6 +1602,7 @@ void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
     ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
+        libxl_event_free(CTX,ev);
         /* ignore */
     } else if (how->callback) {
         libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
-- 
1.7.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 Jun 15 11:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV74-0005kz-6z; Fri, 15 Jun 2012 11:54: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 1SfV71-0005i6-34
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [85.158.143.35:62731] by server-1.bemta-4.messagelabs.com id
	D3/38-24392-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23694 invoked from network); 15 Jun 2012 11:54:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005OC-Rm; Fri, 15 Jun 2012 11:54:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002Yw-P9;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:54:04 +0100
Message-ID: <1339761246-27641-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/21] libxl: do not leak an event struct on
	ignored ao 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 entry to libxl__ao_progress_report, the caller has allocated an
event.  If the progress report is to be ignored, we need to free it.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index eb23a93..1957505 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1602,6 +1602,7 @@ void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
     ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
+        libxl_event_free(CTX,ev);
         /* ignore */
     } else if (how->callback) {
         libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
-- 
1.7.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 Jun 15 11:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV73-0005kX-Oj; Fri, 15 Jun 2012 11:54:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005i3-1H
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [193.109.254.147:36151] by server-11.bemta-14.messagelabs.com
	id 48/F1-02727-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10380 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nn-Cs; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YM-Ad;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:55 +0100
Message-ID: <1339761246-27641-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/21] libxl: datacopier: provide "prefix data"
	facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used to write the qemu data banner to the save/migration
stream.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Clarified and added comments explaining the `immediately'
   constraint and the lack of a reentrancy/threading hazard.
 * Fixed subject line typo.
---
 tools/libxl/libxl_aoutils.c  |   22 ++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index ee0df57..7f8d6d3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -74,6 +74,28 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
     }
 }
 
+void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
+                                  const void *data, size_t len)
+{
+    libxl__datacopier_buf *buf;
+    /*
+     * It is safe for this to be called immediately after _start, as
+     * is documented in the public comment.  _start's caller must have
+     * the ctx locked, so other threads don't get to mess with the
+     * contents, and the fd events cannot happen reentrantly.  So we
+     * are guaranteed to beat the first data from the read fd.
+     */
+
+    assert(len < dc->maxsz - dc->used);
+
+    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf->used = len;
+    memcpy(buf->buf, data, len);
+
+    dc->used += len;
+    LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+}
+
 static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
                                 int fd, short events, short revents) {
     libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 05bed01..8b582e4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1811,6 +1811,12 @@ _hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
 _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
+/* Inserts literal data into the output stream.  The data is copied.
+ * May safely be used only immediately after libxl__datacopier_start
+ * (before the ctx is unlocked).  But may be called multiple times.
+ * NB exceeding maxsz will fail an assertion! */
+_hidden void libxl__datacopier_prefixdata(libxl__egc*, libxl__datacopier_state*,
+                                          const void *data, size_t len);
 
 /*----- Save/restore helper (used by creation and suspend) -----*/
 
-- 
1.7.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 Jun 15 11:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11: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 1SfV73-0005kX-Oj; Fri, 15 Jun 2012 11:54:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SfV71-0005i3-1H
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:47 +0000
Received: from [193.109.254.147:36151] by server-11.bemta-14.messagelabs.com
	id 48/F1-02727-6822BDF4; Fri, 15 Jun 2012 11:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10380 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Nn-Cs; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YM-Ad;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 15 Jun 2012 12:53:55 +0100
Message-ID: <1339761246-27641-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/21] libxl: datacopier: provide "prefix data"
	facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used to write the qemu data banner to the save/migration
stream.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Clarified and added comments explaining the `immediately'
   constraint and the lack of a reentrancy/threading hazard.
 * Fixed subject line typo.
---
 tools/libxl/libxl_aoutils.c  |   22 ++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index ee0df57..7f8d6d3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -74,6 +74,28 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
     }
 }
 
+void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
+                                  const void *data, size_t len)
+{
+    libxl__datacopier_buf *buf;
+    /*
+     * It is safe for this to be called immediately after _start, as
+     * is documented in the public comment.  _start's caller must have
+     * the ctx locked, so other threads don't get to mess with the
+     * contents, and the fd events cannot happen reentrantly.  So we
+     * are guaranteed to beat the first data from the read fd.
+     */
+
+    assert(len < dc->maxsz - dc->used);
+
+    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf->used = len;
+    memcpy(buf->buf, data, len);
+
+    dc->used += len;
+    LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+}
+
 static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
                                 int fd, short events, short revents) {
     libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 05bed01..8b582e4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1811,6 +1811,12 @@ _hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
 _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
+/* Inserts literal data into the output stream.  The data is copied.
+ * May safely be used only immediately after libxl__datacopier_start
+ * (before the ctx is unlocked).  But may be called multiple times.
+ * NB exceeding maxsz will fail an assertion! */
+_hidden void libxl__datacopier_prefixdata(libxl__egc*, libxl__datacopier_state*,
+                                          const void *data, size_t len);
 
 /*----- Save/restore helper (used by creation and suspend) -----*/
 
-- 
1.7.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 Jun 15 11:55:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV70-0005iF-OA; Fri, 15 Jun 2012 11:54:46 +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 1SfV6z-0005hX-Aq
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:45 +0000
Received: from [193.109.254.147:19249] by server-10.bemta-14.messagelabs.com
	id E1/E9-25709-4822BDF4; Fri, 15 Jun 2012 11:54:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10215 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6Q-0005NQ-Nc; Fri, 15 Jun 2012 11:54:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xe-I4;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:45 +0100
Message-ID: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v4 of my series to asyncify save/restore.  All comments have
been addressed.

I have retested this with HVM (RHEL) and PV guests, for both localhost
migration and save/restore.  RHEL seems to have some unreliability
which occurs with the baseline too.  I was not able to test stub dms
at all because when trying to boot my RHEL guest with a stub dm the dm
domain immediately crashed.  (I discovered that my previous tests had
occasionally not been using all of the new code.)

In the list below "A" indicates a patch which has been acked
sufficiently to go in (assuming its dependencies were to go in too).
"*" indicates a new patch in v4 and "+" indicates a patch with
nontrivial changes from v3.

Preparatory fixes:

   A libxc: xc_domain_restore, make toolstack_restore const-correct
 *   libxc: Do not segfault if (e.g.) switch_qemu_logdirty fails

Preparatory reshuffling:

   A libxl: domain save: rename variables etc.
   A libxl: domain restore: reshuffle, preparing for ao
 +   libxl: domain save: API changes for asynchrony

The meat:

 +   libxl: domain save/restore: run in a separate process

Some more fixups:

   A libxl: rename libxl_dom:save_helper to physmap_path
   A libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
 + A libxl: wait for qemu to acknowledge logdirty command

Asyncify writing of qemu save file, too:

   A libxl: datacopier: provide "prefix data" facility
   A libxl: prepare for asynchronous writing of qemu save file
   A libxl: Make libxl__domain_save_device_model asynchronous

Fix gc_opt handling:

   A libxl: Add a gc to libxl_get_cpu_topology
   A libxl: Do not pass NULL as gc_opt; introduce NOGC
   A libxl: Get compiler to warn about gc_opt==NULL

Work on essentially-unrelated bugs:

   A xl: Handle return value from libxl_domain_suspend correctly
   A libxl: do not leak dms->saved_state
   A libxl: do not leak spawned middle children
   A libxl: do not leak an event struct on ignored ao progress
     libxl: further fixups re LIBXL_DOMAIN_TYPE
     libxl: DO NOT APPLY enforce prohibition on internal

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 Jun 15 11:55:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV70-0005iF-OA; Fri, 15 Jun 2012 11:54:46 +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 1SfV6z-0005hX-Aq
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:45 +0000
Received: from [193.109.254.147:19249] by server-10.bemta-14.messagelabs.com
	id E1/E9-25709-4822BDF4; Fri, 15 Jun 2012 11:54:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339761283!2749012!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10215 invoked from network); 15 Jun 2012 11:54:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6Q-0005NQ-Nc; Fri, 15 Jun 2012 11:54:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6Q-0002Xe-I4;
	Fri, 15 Jun 2012 12:54:10 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:45 +0100
Message-ID: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v4 of my series to asyncify save/restore.  All comments have
been addressed.

I have retested this with HVM (RHEL) and PV guests, for both localhost
migration and save/restore.  RHEL seems to have some unreliability
which occurs with the baseline too.  I was not able to test stub dms
at all because when trying to boot my RHEL guest with a stub dm the dm
domain immediately crashed.  (I discovered that my previous tests had
occasionally not been using all of the new code.)

In the list below "A" indicates a patch which has been acked
sufficiently to go in (assuming its dependencies were to go in too).
"*" indicates a new patch in v4 and "+" indicates a patch with
nontrivial changes from v3.

Preparatory fixes:

   A libxc: xc_domain_restore, make toolstack_restore const-correct
 *   libxc: Do not segfault if (e.g.) switch_qemu_logdirty fails

Preparatory reshuffling:

   A libxl: domain save: rename variables etc.
   A libxl: domain restore: reshuffle, preparing for ao
 +   libxl: domain save: API changes for asynchrony

The meat:

 +   libxl: domain save/restore: run in a separate process

Some more fixups:

   A libxl: rename libxl_dom:save_helper to physmap_path
   A libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
 + A libxl: wait for qemu to acknowledge logdirty command

Asyncify writing of qemu save file, too:

   A libxl: datacopier: provide "prefix data" facility
   A libxl: prepare for asynchronous writing of qemu save file
   A libxl: Make libxl__domain_save_device_model asynchronous

Fix gc_opt handling:

   A libxl: Add a gc to libxl_get_cpu_topology
   A libxl: Do not pass NULL as gc_opt; introduce NOGC
   A libxl: Get compiler to warn about gc_opt==NULL

Work on essentially-unrelated bugs:

   A xl: Handle return value from libxl_domain_suspend correctly
   A libxl: do not leak dms->saved_state
   A libxl: do not leak spawned middle children
   A libxl: do not leak an event struct on ignored ao progress
     libxl: further fixups re LIBXL_DOMAIN_TYPE
     libxl: DO NOT APPLY enforce prohibition on internal

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 Jun 15 11:55:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV72-0005jq-PK; Fri, 15 Jun 2012 11:54: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 1SfV70-0005hp-FO
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [85.158.143.35:62710] by server-3.bemta-4.messagelabs.com id
	C0/D1-05808-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23566 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Ng-7i; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YA-5p;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:52 +0100
Message-ID: <1339761246-27641-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/21] libxl: rename libxl_dom:save_helper to
	physmap_path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"save_helper" isn't very descriptive.  Also it is now confusing
because it reads like it might refer to the libxl-save-helper
executable which runs xc_domain_save and xc_domain_restore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fea0c94..a597627 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -734,7 +734,7 @@ int libxl__domain_suspend_common_callback(void *user)
     return 1;
 }
 
-static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
     return libxl__sprintf(gc,
@@ -779,21 +779,21 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        xs_path = physmap_path(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "size");
+        xs_path = physmap_path(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "name");
+        xs_path = physmap_path(gc, domid, phys_offset, "name");
         name = libxl__xs_read(gc, 0, xs_path);
         if (name == NULL)
             namelen = 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 Jun 15 11:55:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 11:55: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 1SfV72-0005jq-PK; Fri, 15 Jun 2012 11:54: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 1SfV70-0005hp-FO
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 11:54:46 +0000
Received: from [85.158.143.35:62710] by server-3.bemta-4.messagelabs.com id
	C0/D1-05808-5822BDF4; Fri, 15 Jun 2012 11:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339761284!15225127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23566 invoked from network); 15 Jun 2012 11:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 11:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13041875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 11:54:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 12:54:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfV6R-0005Ng-7i; Fri, 15 Jun 2012 11:54:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfV6R-0002YA-5p;
	Fri, 15 Jun 2012 12:54:11 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Jun 2012 12:53:52 +0100
Message-ID: <1339761246-27641-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/21] libxl: rename libxl_dom:save_helper to
	physmap_path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"save_helper" isn't very descriptive.  Also it is now confusing
because it reads like it might refer to the libxl-save-helper
executable which runs xc_domain_save and xc_domain_restore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fea0c94..a597627 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -734,7 +734,7 @@ int libxl__domain_suspend_common_callback(void *user)
     return 1;
 }
 
-static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
     return libxl__sprintf(gc,
@@ -779,21 +779,21 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        xs_path = physmap_path(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "size");
+        xs_path = physmap_path(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "name");
+        xs_path = physmap_path(gc, domid, phys_offset, "name");
         name = libxl__xs_read(gc, 0, xs_path);
         if (name == NULL)
             namelen = 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 Jun 15 12:10:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:10: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 1SfVM9-0000pn-RF; Fri, 15 Jun 2012 12:10:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SfVM7-0000pD-SZ
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:10:24 +0000
Received: from [85.158.143.99:6409] by server-1.bemta-4.messagelabs.com id
	A4/54-24392-E262BDF4; Fri, 15 Jun 2012 12:10:22 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339762218!17762001!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11808 invoked from network); 15 Jun 2012 12:10:19 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 12:10:19 -0000
Received: by eekd41 with SMTP id d41so1016046eek.32
	for <multiple recipients>; Fri, 15 Jun 2012 05:10:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=TABeXGUOyv27+yCtmrz7EsWmRZFFHhPZHFQaWlqL5RE=;
	b=r3K3qSPzmKurDK5I1lzHypmVKD1S+5J3GGVjkUp+dTjwNcZWvD56FqaB4lanUZLgwy
	yj7RXFpKMSxM6s3AT/VxW8cyf5ezZqYNSmTQaq6UEuXaSallYqGJPGJfDBViFoTTI0TI
	jbUooIpYWBZzOTMJvwFdwGqbjWUo9evOuW5u+xXxZ9lrgBEoEzJgGpjmSqhAEOJY4AVR
	LzdRkhtDfQ4uCvFSaeWglqp7nXq80/8evFfQBk7VgukZ0W9ZLoXjAkqAbW8M983HwQXa
	J+GGdKvMqsN7G4cmqE/cFk2fu/sp+Pu/nQtVsvQqh1VNV4KOaEpn+6aFeFQMFkbMgpL3
	YOTQ==
Received: by 10.14.96.67 with SMTP id q43mr1398447eef.11.1339762218325;
	Fri, 15 Jun 2012 05:10:18 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id p41sm30253472eef.5.2012.06.15.05.10.17
	(version=SSLv3 cipher=OTHER); Fri, 15 Jun 2012 05:10:17 -0700 (PDT)
Message-ID: <4FDB2628.1000807@xen.org>
Date: Fri, 15 Jun 2012 13:10:16 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org
Subject: [Xen-devel] ACTION REQUIRED: Xen Maintainer,
 Committer and Developer Meeting @ XenSummit NA 2012
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,

a bit more than a month back, we had a discussion and vote on whether we 
should have a Developer meeting alongside or before XenSummit (see 
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01511.html). The 
overwhelming majority voted for a meeting on Sunday afternoon, the 26th 
of August.

I have secured a meeting room from 13:00 to 17:00 at the XenSummit Venue 
and anticipate that we will go out for dinner afterwards. The meeting is 
invite only and we do only have limited space. However, to make things a 
little easier on me could maintainers, committers and contributors which 
will be at XenSummit and want to attend the meeting fill out 
http://xen.org/polls/xen_dev_2012_requestinvite.html

If we do not have enough space (which is quite possible), I will work 
with the committers of Xen.org projects to figure out who will be invited.

I also created a wiki page such that you can start adding topics for 
discussion: see 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/XenSummit_NA_2012 
- You can also propose discussion topics via the form.

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 Jun 15 12:10:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:10: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 1SfVM9-0000pn-RF; Fri, 15 Jun 2012 12:10:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SfVM7-0000pD-SZ
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:10:24 +0000
Received: from [85.158.143.99:6409] by server-1.bemta-4.messagelabs.com id
	A4/54-24392-E262BDF4; Fri, 15 Jun 2012 12:10:22 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1339762218!17762001!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11808 invoked from network); 15 Jun 2012 12:10:19 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 12:10:19 -0000
Received: by eekd41 with SMTP id d41so1016046eek.32
	for <multiple recipients>; Fri, 15 Jun 2012 05:10:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=TABeXGUOyv27+yCtmrz7EsWmRZFFHhPZHFQaWlqL5RE=;
	b=r3K3qSPzmKurDK5I1lzHypmVKD1S+5J3GGVjkUp+dTjwNcZWvD56FqaB4lanUZLgwy
	yj7RXFpKMSxM6s3AT/VxW8cyf5ezZqYNSmTQaq6UEuXaSallYqGJPGJfDBViFoTTI0TI
	jbUooIpYWBZzOTMJvwFdwGqbjWUo9evOuW5u+xXxZ9lrgBEoEzJgGpjmSqhAEOJY4AVR
	LzdRkhtDfQ4uCvFSaeWglqp7nXq80/8evFfQBk7VgukZ0W9ZLoXjAkqAbW8M983HwQXa
	J+GGdKvMqsN7G4cmqE/cFk2fu/sp+Pu/nQtVsvQqh1VNV4KOaEpn+6aFeFQMFkbMgpL3
	YOTQ==
Received: by 10.14.96.67 with SMTP id q43mr1398447eef.11.1339762218325;
	Fri, 15 Jun 2012 05:10:18 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id p41sm30253472eef.5.2012.06.15.05.10.17
	(version=SSLv3 cipher=OTHER); Fri, 15 Jun 2012 05:10:17 -0700 (PDT)
Message-ID: <4FDB2628.1000807@xen.org>
Date: Fri, 15 Jun 2012 13:10:16 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org
Subject: [Xen-devel] ACTION REQUIRED: Xen Maintainer,
 Committer and Developer Meeting @ XenSummit NA 2012
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,

a bit more than a month back, we had a discussion and vote on whether we 
should have a Developer meeting alongside or before XenSummit (see 
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01511.html). The 
overwhelming majority voted for a meeting on Sunday afternoon, the 26th 
of August.

I have secured a meeting room from 13:00 to 17:00 at the XenSummit Venue 
and anticipate that we will go out for dinner afterwards. The meeting is 
invite only and we do only have limited space. However, to make things a 
little easier on me could maintainers, committers and contributors which 
will be at XenSummit and want to attend the meeting fill out 
http://xen.org/polls/xen_dev_2012_requestinvite.html

If we do not have enough space (which is quite possible), I will work 
with the committers of Xen.org projects to figure out who will be invited.

I also created a wiki page such that you can start adding topics for 
discussion: see 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/XenSummit_NA_2012 
- You can also propose discussion topics via the form.

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 Jun 15 12:25:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:25: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 1SfVa7-0001Wp-Bm; Fri, 15 Jun 2012 12:24:51 +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 1SfVa6-0001Wj-3T
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:24:50 +0000
Received: from [85.158.143.35:21915] by server-2.bemta-4.messagelabs.com id
	49/8A-17938-1992BDF4; Fri, 15 Jun 2012 12:24:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339763086!13948655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8296 invoked from network); 15 Jun 2012 12:24:47 -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;
	15 Jun 2012 12:24:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198882425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 08:24:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 08:24:45 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfVa1-0001Jy-FY;
	Fri, 15 Jun 2012 13:24:45 +0100
Message-ID: <4FDB298D.1050702@citrix.com>
Date: Fri, 15 Jun 2012 13:24:45 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "quintela@redhat.com" <quintela@redhat.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
	<1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
	<87bokkeqpx.fsf@elfo.mitica>
In-Reply-To: <87bokkeqpx.fsf@elfo.mitica>
Cc: Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xenstore: Use <xenstore.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-Transfer-Encoding: 7bit
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 15/06/12 12:53, Juan Quintela wrote:
> Anthony PERARD<anthony.perard@citrix.com>  wrote:
>> In the next release of Xen (4.2), xs.h became deprecated.
>>
>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
>> ---
>>   configure       |    2 +-
>>   hw/xen_common.h |    6 +++++-
>>   2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index c2366ee..e7f66c9 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1382,7 +1382,7 @@ EOF
>>     elif (
>>         cat>  $TMPC<<EOF
>>   #include<xenctrl.h>
>> -#include<xs.h>
>> +#include<xenstore.h>
>>   #include<stdint.h>
>>   #include<xen/hvm/hvm_info_table.h>
>>   #if !defined(HVM_MAX_VCPUS)
>> diff --git a/hw/xen_common.h b/hw/xen_common.h
>> index fe7f227..cc99204 100644
>> --- a/hw/xen_common.h
>> +++ b/hw/xen_common.h
>> @@ -7,7 +7,11 @@
>>   #include<inttypes.h>
>>
>>   #include<xenctrl.h>
>> -#include<xs.h>
>> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION<  420
>> +#  include<xs.h>
>> +#else
>> +#  include<xenstore.h>
>> +#endif
>>   #include<xen/io/xenbus.h>
>>
>>   #include "hw.h"
>
> Shouldn't we need the ifdef also in configure?  On my system xenstore.h
> still don't exist.

No, configure does not need it. In the configure, I just change the 
header in the test for the next version of Xen. Also the define is 
defined by configure.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:25:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:25: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 1SfVa7-0001Wp-Bm; Fri, 15 Jun 2012 12:24:51 +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 1SfVa6-0001Wj-3T
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:24:50 +0000
Received: from [85.158.143.35:21915] by server-2.bemta-4.messagelabs.com id
	49/8A-17938-1992BDF4; Fri, 15 Jun 2012 12:24:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1339763086!13948655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA0ODg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8296 invoked from network); 15 Jun 2012 12:24:47 -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;
	15 Jun 2012 12:24:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330923600"; d="scan'208";a="198882425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 08:24:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 15 Jun 2012 08:24:45 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1SfVa1-0001Jy-FY;
	Fri, 15 Jun 2012 13:24:45 +0100
Message-ID: <4FDB298D.1050702@citrix.com>
Date: Fri, 15 Jun 2012 13:24:45 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "quintela@redhat.com" <quintela@redhat.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
	<1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
	<87bokkeqpx.fsf@elfo.mitica>
In-Reply-To: <87bokkeqpx.fsf@elfo.mitica>
Cc: Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xenstore: Use <xenstore.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-Transfer-Encoding: 7bit
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 15/06/12 12:53, Juan Quintela wrote:
> Anthony PERARD<anthony.perard@citrix.com>  wrote:
>> In the next release of Xen (4.2), xs.h became deprecated.
>>
>> Signed-off-by: Anthony PERARD<anthony.perard@citrix.com>
>> ---
>>   configure       |    2 +-
>>   hw/xen_common.h |    6 +++++-
>>   2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index c2366ee..e7f66c9 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1382,7 +1382,7 @@ EOF
>>     elif (
>>         cat>  $TMPC<<EOF
>>   #include<xenctrl.h>
>> -#include<xs.h>
>> +#include<xenstore.h>
>>   #include<stdint.h>
>>   #include<xen/hvm/hvm_info_table.h>
>>   #if !defined(HVM_MAX_VCPUS)
>> diff --git a/hw/xen_common.h b/hw/xen_common.h
>> index fe7f227..cc99204 100644
>> --- a/hw/xen_common.h
>> +++ b/hw/xen_common.h
>> @@ -7,7 +7,11 @@
>>   #include<inttypes.h>
>>
>>   #include<xenctrl.h>
>> -#include<xs.h>
>> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION<  420
>> +#  include<xs.h>
>> +#else
>> +#  include<xenstore.h>
>> +#endif
>>   #include<xen/io/xenbus.h>
>>
>>   #include "hw.h"
>
> Shouldn't we need the ifdef also in configure?  On my system xenstore.h
> still don't exist.

No, configure does not need it. In the configure, I just change the 
header in the test for the next version of Xen. Also the define is 
defined by configure.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:25:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12: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 1SfVaC-0001XF-Nl; Fri, 15 Jun 2012 12:24:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SfVaA-0001X1-Ko
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:24:54 +0000
Received: from [85.158.143.99:57249] by server-1.bemta-4.messagelabs.com id
	F3/BD-24392-6992BDF4; Fri, 15 Jun 2012 12:24:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339763093!27515221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20242 invoked from network); 15 Jun 2012 12:24:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 12:24:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13042596"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 12:24:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 13:24:47 +0100
Date: Fri, 15 Jun 2012 13:24:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Juan Quintela <quintela@redhat.com>
In-Reply-To: <87bokkeqpx.fsf@elfo.mitica>
Message-ID: <alpine.DEB.2.02.1206151323130.14957@kaball.uk.xensource.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
	<1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
	<87bokkeqpx.fsf@elfo.mitica>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xenstore: Use <xenstore.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 Fri, 15 Jun 2012, Juan Quintela wrote:
> Anthony PERARD <anthony.perard@citrix.com> wrote:
> > In the next release of Xen (4.2), xs.h became deprecated.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  configure       |    2 +-
> >  hw/xen_common.h |    6 +++++-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/configure b/configure
> > index c2366ee..e7f66c9 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1382,7 +1382,7 @@ EOF
> >    elif (
> >        cat > $TMPC <<EOF
> >  #include <xenctrl.h>
> > -#include <xs.h>
> > +#include <xenstore.h>
> >  #include <stdint.h>
> >  #include <xen/hvm/hvm_info_table.h>
> >  #if !defined(HVM_MAX_VCPUS)
> > diff --git a/hw/xen_common.h b/hw/xen_common.h
> > index fe7f227..cc99204 100644
> > --- a/hw/xen_common.h
> > +++ b/hw/xen_common.h
> > @@ -7,7 +7,11 @@
> >  #include <inttypes.h>
> >  
> >  #include <xenctrl.h>
> > -#include <xs.h>
> > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
> > +#  include <xs.h>
> > +#else
> > +#  include <xenstore.h>
> > +#endif
> >  #include <xen/io/xenbus.h>
> >  
> >  #include "hw.h"
> 
> Shouldn't we need the ifdef also in configure?  On my system xenstore.h
> still don't exist.
> 
> (master *)$ rpm -qa xen-devel
> xen-devel-4.1.2-17.fc17.x86_64
> (master *)$ ls /usr/include/xs.h 
> /usr/include/xs.h
> (master *)$ ls /usr/include/xenstore.h
> ls: cannot access /usr/include/xenstore.h: No such file or directory
> (master *)$ 

configure is already testing for a number of specific xen versions,
this patch is only changing the xen-unstable test, but all the other
tests for older xen versions still use xs.h.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:25:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12: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 1SfVaC-0001XF-Nl; Fri, 15 Jun 2012 12:24:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SfVaA-0001X1-Ko
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:24:54 +0000
Received: from [85.158.143.99:57249] by server-1.bemta-4.messagelabs.com id
	F3/BD-24392-6992BDF4; Fri, 15 Jun 2012 12:24:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339763093!27515221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20242 invoked from network); 15 Jun 2012 12:24:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 12:24:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13042596"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 12:24:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 13:24:47 +0100
Date: Fri, 15 Jun 2012 13:24:23 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Juan Quintela <quintela@redhat.com>
In-Reply-To: <87bokkeqpx.fsf@elfo.mitica>
Message-ID: <alpine.DEB.2.02.1206151323130.14957@kaball.uk.xensource.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
	<1339759030-32653-3-git-send-email-anthony.perard@citrix.com>
	<87bokkeqpx.fsf@elfo.mitica>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xenstore: Use <xenstore.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 Fri, 15 Jun 2012, Juan Quintela wrote:
> Anthony PERARD <anthony.perard@citrix.com> wrote:
> > In the next release of Xen (4.2), xs.h became deprecated.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  configure       |    2 +-
> >  hw/xen_common.h |    6 +++++-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/configure b/configure
> > index c2366ee..e7f66c9 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1382,7 +1382,7 @@ EOF
> >    elif (
> >        cat > $TMPC <<EOF
> >  #include <xenctrl.h>
> > -#include <xs.h>
> > +#include <xenstore.h>
> >  #include <stdint.h>
> >  #include <xen/hvm/hvm_info_table.h>
> >  #if !defined(HVM_MAX_VCPUS)
> > diff --git a/hw/xen_common.h b/hw/xen_common.h
> > index fe7f227..cc99204 100644
> > --- a/hw/xen_common.h
> > +++ b/hw/xen_common.h
> > @@ -7,7 +7,11 @@
> >  #include <inttypes.h>
> >  
> >  #include <xenctrl.h>
> > -#include <xs.h>
> > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
> > +#  include <xs.h>
> > +#else
> > +#  include <xenstore.h>
> > +#endif
> >  #include <xen/io/xenbus.h>
> >  
> >  #include "hw.h"
> 
> Shouldn't we need the ifdef also in configure?  On my system xenstore.h
> still don't exist.
> 
> (master *)$ rpm -qa xen-devel
> xen-devel-4.1.2-17.fc17.x86_64
> (master *)$ ls /usr/include/xs.h 
> /usr/include/xs.h
> (master *)$ ls /usr/include/xenstore.h
> ls: cannot access /usr/include/xenstore.h: No such file or directory
> (master *)$ 

configure is already testing for a number of specific xen versions,
this patch is only changing the xen-unstable test, but all the other
tests for older xen versions still use xs.h.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:25:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:25: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 1SfVak-0001bs-5h; Fri, 15 Jun 2012 12:25:30 +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 1SfVai-0001bO-8w
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:25:28 +0000
Received: from [85.158.138.51:55132] by server-2.bemta-3.messagelabs.com id
	22/16-31533-7B92BDF4; Fri, 15 Jun 2012 12:25:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339763124!21502645!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9964 invoked from network); 15 Jun 2012 12:25:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 12:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13042616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 12:25:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 13:25:24 +0100
Date: Fri, 15 Jun 2012 13:25:01 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1206151324430.14957@kaball.uk.xensource.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] xen: Deprecation of <xs.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 Fri, 15 Jun 2012, Anthony PERARD wrote:
> Considering that <xs.h> will be deprecated in the next release of Xen, this two
> patches clean a bit the inclusion of xs.h and changes it in a single place.
> 
> Anthony PERARD (2):
>   xen: Reorganize includes of Xen headers.
>   xenstore: Use <xenstore.h>
> 
>  configure        |    2 +-
>  hw/xen_backend.c |    6 ++----
>  hw/xen_common.h  |    6 +++++-
>  hw/xen_console.c |    5 ++---
>  hw/xen_disk.c    |    6 +-----
>  hw/xen_nic.c     |    7 ++-----
>  hw/xenfb.c       |   13 +++++--------
>  7 files changed, 18 insertions(+), 27 deletions(-)

both patches are fine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:25:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:25: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 1SfVak-0001bs-5h; Fri, 15 Jun 2012 12:25:30 +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 1SfVai-0001bO-8w
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 12:25:28 +0000
Received: from [85.158.138.51:55132] by server-2.bemta-3.messagelabs.com id
	22/16-31533-7B92BDF4; Fri, 15 Jun 2012 12:25:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339763124!21502645!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9964 invoked from network); 15 Jun 2012 12:25:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 12:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,776,1330905600"; d="scan'208";a="13042616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 12:25:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 13:25:24 +0100
Date: Fri, 15 Jun 2012 13:25:01 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1206151324430.14957@kaball.uk.xensource.com>
References: <1339759030-32653-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] xen: Deprecation of <xs.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 Fri, 15 Jun 2012, Anthony PERARD wrote:
> Considering that <xs.h> will be deprecated in the next release of Xen, this two
> patches clean a bit the inclusion of xs.h and changes it in a single place.
> 
> Anthony PERARD (2):
>   xen: Reorganize includes of Xen headers.
>   xenstore: Use <xenstore.h>
> 
>  configure        |    2 +-
>  hw/xen_backend.c |    6 ++----
>  hw/xen_common.h  |    6 +++++-
>  hw/xen_console.c |    5 ++---
>  hw/xen_disk.c    |    6 +-----
>  hw/xen_nic.c     |    7 ++-----
>  hw/xenfb.c       |   13 +++++--------
>  7 files changed, 18 insertions(+), 27 deletions(-)

both patches are fine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12: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 1SfVwy-0003NF-6q; Fri, 15 Jun 2012 12:48:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sf9xg-0000HI-46
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:19:44 +0000
Received: from [193.109.254.147:60179] by server-9.bemta-14.messagelabs.com id
	3B/33-27072-FE4E9DF4; Thu, 14 Jun 2012 13:19:43 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339679982!9705137!1
X-Originating-IP: [80.67.29.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMjkuNyA9PiA0NjIwMQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26925 invoked from network); 14 Jun 2012 13:19:42 -0000
Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de)
	(80.67.29.7) by server-2.tower-27.messagelabs.com with SMTP;
	14 Jun 2012 13:19:42 -0000
Received: from [80.67.16.117] (helo=webmailfront01.ispgateway.de)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>) id 1Sf9q0-0007A1-2e
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:11:48 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Thu, 14 Jun 2012 15:11:48 +0200
Date: Thu, 14 Jun 2012 15:11:48 +0200
Message-ID: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
From: ml@consolo.de
To: xen-devel@lists.xensource.com
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

I am currently trying to get kdb working with the current 4.1 XEN release.
I first tried to use debuggers.hg, but could not manage to compile it  
due tho many different errors.

Due to these errors and since the branch of debuggers.hg seems to be  
rather old, I really would like to use kdb with the *current* XEN  
release.

Can anyone hint me how to do this? Is copying the /kdb subfolder and  
recompiling sufficient? I suppose not and that there are additional  
modifications necessary in the Xen system itself? Is there any  
information available how to it?

Thanks a lot for your help
cw


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12: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 1SfVwy-0003NF-6q; Fri, 15 Jun 2012 12:48:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sf9xg-0000HI-46
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 13:19:44 +0000
Received: from [193.109.254.147:60179] by server-9.bemta-14.messagelabs.com id
	3B/33-27072-FE4E9DF4; Thu, 14 Jun 2012 13:19:43 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339679982!9705137!1
X-Originating-IP: [80.67.29.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMjkuNyA9PiA0NjIwMQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26925 invoked from network); 14 Jun 2012 13:19:42 -0000
Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de)
	(80.67.29.7) by server-2.tower-27.messagelabs.com with SMTP;
	14 Jun 2012 13:19:42 -0000
Received: from [80.67.16.117] (helo=webmailfront01.ispgateway.de)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>) id 1Sf9q0-0007A1-2e
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 15:11:48 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Thu, 14 Jun 2012 15:11:48 +0200
Date: Thu, 14 Jun 2012 15:11:48 +0200
Message-ID: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
From: ml@consolo.de
To: xen-devel@lists.xensource.com
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

I am currently trying to get kdb working with the current 4.1 XEN release.
I first tried to use debuggers.hg, but could not manage to compile it  
due tho many different errors.

Due to these errors and since the branch of debuggers.hg seems to be  
rather old, I really would like to use kdb with the *current* XEN  
release.

Can anyone hint me how to do this? Is copying the /kdb subfolder and  
recompiling sufficient? I suppose not and that there are additional  
modifications necessary in the Xen system itself? Is there any  
information available how to it?

Thanks a lot for your help
cw


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfVwx-0003N4-Q8; Fri, 15 Jun 2012 12:48:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sf8oj-0004Gn-Mi
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:06:25 +0000
Received: from [85.158.143.99:48516] by server-2.bemta-4.messagelabs.com id
	EC/A8-17938-0C3D9DF4; Thu, 14 Jun 2012 12:06:24 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339675584!19834903!1
X-Originating-IP: [80.67.31.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMzEuMzcgPT4gNDIxNTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3303 invoked from network); 14 Jun 2012 12:06:24 -0000
Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de)
	(80.67.31.37) by server-11.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 12:06:24 -0000
Received: from [80.67.16.112] (helo=webmailfront01.ispgateway.de)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>) id 1Sf8oh-0007ew-PK
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 14:06:23 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Thu, 14 Jun 2012 14:06:23 +0200
Date: Thu, 14 Jun 2012 14:06:23 +0200
Message-ID: <20120614140623.Horde.hPPyfKGZi1VP2dO-uIDlLAA@webmail.df.eu>
From: ml@consolo.de
To: xen-devel@lists.xensource.com
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

I am currently trying to get kdb working with the current 4.1 XEN release.
I first tried to use debuggers.hg, but could not manage to compile it  
due tho many different errors.

Due to these errors and since the branch of debuggers.hg seems to be  
rather old, I really would like to use kdb with the *current* XEN  
release.

Can anyone hint me how to do this? Is copying the /kdb subfolder and  
recompiling sufficient? I suppose not and that there are additional  
modifications necessary in the Xen system itself? Is there any  
information available how to it?

Thanks a lot for your help
cw


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfVwx-0003N4-Q8; Fri, 15 Jun 2012 12:48:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sf8oj-0004Gn-Mi
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 12:06:25 +0000
Received: from [85.158.143.99:48516] by server-2.bemta-4.messagelabs.com id
	EC/A8-17938-0C3D9DF4; Thu, 14 Jun 2012 12:06:24 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1339675584!19834903!1
X-Originating-IP: [80.67.31.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMzEuMzcgPT4gNDIxNTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3303 invoked from network); 14 Jun 2012 12:06:24 -0000
Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de)
	(80.67.31.37) by server-11.tower-216.messagelabs.com with SMTP;
	14 Jun 2012 12:06:24 -0000
Received: from [80.67.16.112] (helo=webmailfront01.ispgateway.de)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>) id 1Sf8oh-0007ew-PK
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 14:06:23 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Thu, 14 Jun 2012 14:06:23 +0200
Date: Thu, 14 Jun 2012 14:06:23 +0200
Message-ID: <20120614140623.Horde.hPPyfKGZi1VP2dO-uIDlLAA@webmail.df.eu>
From: ml@consolo.de
To: xen-devel@lists.xensource.com
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

I am currently trying to get kdb working with the current 4.1 XEN release.
I first tried to use debuggers.hg, but could not manage to compile it  
due tho many different errors.

Due to these errors and since the branch of debuggers.hg seems to be  
rather old, I really would like to use kdb with the *current* XEN  
release.

Can anyone hint me how to do this? Is copying the /kdb subfolder and  
recompiling sufficient? I suppose not and that there are additional  
modifications necessary in the Xen system itself? Is there any  
information available how to it?

Thanks a lot for your help
cw


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfVwx-0003Mt-DJ; Fri, 15 Jun 2012 12:48:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sf65q-0006sJ-Mr
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 09:11:54 +0000
Received: from [85.158.143.35:22592] by server-3.bemta-4.messagelabs.com id
	F6/D1-05808-9DAA9DF4; Thu, 14 Jun 2012 09:11:53 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339665113!15009588!1
X-Originating-IP: [80.67.31.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMzEuMjYgPT4gNDUwODI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15476 invoked from network); 14 Jun 2012 09:11:53 -0000
Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de)
	(80.67.31.26) by server-13.tower-21.messagelabs.com with SMTP;
	14 Jun 2012 09:11:53 -0000
Received: from [80.67.16.115] (helo=webmailfront01.ispgateway.de)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>) id 1Sf65o-0005xG-Vq
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 11:11:53 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Thu, 14 Jun 2012 11:11:52 +0200
Date: Thu, 14 Jun 2012 11:11:52 +0200
Message-ID: <20120614111152.Horde.9_5GPFNNcXdP2arY5wLm_sA@webmail.df.eu>
From: ml@consolo.de
To: xen-devel@lists.xensource.com
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I am currently trying to get kdb working with the current 4.1 XEN release.
I first tried to use debuggers.hg, but could not manage to compile it  
due tho many different errors.

Due to these errors and since the branch of debuggers.hg seems to be  
rather old, I really would like to use kdb with the *current* XEN  
release.

Can anyone hint me how to do this? Is copying the /kdb subfolder and  
recompiling sufficient? I suppose not and that there are additional  
modifications necessary in the Xen system itself? Is there any  
information available how to it?

Thanks a lot for your help
cw







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfVwx-0003Mt-DJ; Fri, 15 Jun 2012 12:48:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sf65q-0006sJ-Mr
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 09:11:54 +0000
Received: from [85.158.143.35:22592] by server-3.bemta-4.messagelabs.com id
	F6/D1-05808-9DAA9DF4; Thu, 14 Jun 2012 09:11:53 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1339665113!15009588!1
X-Originating-IP: [80.67.31.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMzEuMjYgPT4gNDUwODI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15476 invoked from network); 14 Jun 2012 09:11:53 -0000
Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de)
	(80.67.31.26) by server-13.tower-21.messagelabs.com with SMTP;
	14 Jun 2012 09:11:53 -0000
Received: from [80.67.16.115] (helo=webmailfront01.ispgateway.de)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>) id 1Sf65o-0005xG-Vq
	for xen-devel@lists.xensource.com; Thu, 14 Jun 2012 11:11:53 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Thu, 14 Jun 2012 11:11:52 +0200
Date: Thu, 14 Jun 2012 11:11:52 +0200
Message-ID: <20120614111152.Horde.9_5GPFNNcXdP2arY5wLm_sA@webmail.df.eu>
From: ml@consolo.de
To: xen-devel@lists.xensource.com
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I am currently trying to get kdb working with the current 4.1 XEN release.
I first tried to use debuggers.hg, but could not manage to compile it  
due tho many different errors.

Due to these errors and since the branch of debuggers.hg seems to be  
rather old, I really would like to use kdb with the *current* XEN  
release.

Can anyone hint me how to do this? Is copying the /kdb subfolder and  
recompiling sufficient? I suppose not and that there are additional  
modifications necessary in the Xen system itself? Is there any  
information available how to it?

Thanks a lot for your help
cw







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12: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 1SfVwy-0003NR-KE; Fri, 15 Jun 2012 12:48:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jungle.xuxin@gmail.com>) id 1SfH7l-0006vd-5T
	for Xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:58:37 +0000
Received: from [85.158.143.35:18627] by server-2.bemta-4.messagelabs.com id
	A2/8D-17938-C705ADF4; Thu, 14 Jun 2012 20:58:36 +0000
X-Env-Sender: jungle.xuxin@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339707514!13181796!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27088 invoked from network); 14 Jun 2012 20:58:35 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 20:58:35 -0000
Received: by obbwd20 with SMTP id wd20so3900138obb.32
	for <Xen-devel@lists.xen.org>; Thu, 14 Jun 2012 13:58:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=YX3ESiI5xaO/7QcJBZleoPIOC4xaw9FnGJHSK1eDq4U=;
	b=XZM3N5QNWlUDTqHzdW4S2/3eWUJezSp08rFqehCgWzg9Pw9Ch0F9zAcm18999Ar8fN
	TKP7jinxeIrpBh+WWszBNhvXvOSo2uYwv1/UpQMB6I2H86BFRMYcyO0iw2V46NjTXU/P
	e6jEIOpNMltGCfYQ+OkWVgAPhZBWCM/ZMiIWDdOnLEgjgiBuhOfmV//lcXgu2eSK8SjC
	rNr0MrC3hVuRBi6i2UFfH9X5ufCfXLxyly5/FfHuxxdPs9AmjyX2sw5uNmbOvSvpS4Hf
	JQjjhdZzfhj3/gXIk45B7lkJNsudOiVFgkEifQfmyZfUBJQiPSnglfQA3+rDA+jBp8jh
	jBZw==
MIME-Version: 1.0
Received: by 10.182.53.100 with SMTP id a4mr3425584obp.3.1339707513860; Thu,
	14 Jun 2012 13:58:33 -0700 (PDT)
Received: by 10.182.137.71 with HTTP; Thu, 14 Jun 2012 13:58:33 -0700 (PDT)
Date: Thu, 14 Jun 2012 16:58:33 -0400
Message-ID: <CA+ANA0HStvsP=6=39h2qDP_gQ7vXRNSSa8PPwAO8ac89Ku8ypg@mail.gmail.com>
From: Xin Xu <jungle.xuxin@gmail.com>
To: Xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] pin hypervisor to physical 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: multipart/mixed; boundary="===============4229406698187848956=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4229406698187848956==
Content-Type: multipart/alternative; boundary=f46d0446311e77720904c274f67e

--f46d0446311e77720904c274f67e
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,

I am trying to identify the current running task is belonging to domu, dom0
or hypervisor. So I figured if I can separate domu, dom0 and hypervisor to
different physical CPUs, then I can just look at cpu and then tell the task
belongs to which. I use xm vcpu-pin to pin domu and dom0, but it does not
work for hypervisor. I am just wondering if there is a way to pin
hypervisor to a specific cpu?

I am just trying to better understand how this "pinning" cpu works. If I
pin domu to cpu 0, does that mean all instructions belongs to domu will run
in cpu 0? Does that mean cpu 0 will be exclusively assigned to domu and
will not run any instructions from dom0 and hypervisor? I pin dom0 to cpu
0, and dom1 to cpu1, but i still see instructions running in cpu 2 and 3.
How can I tell what are those instructions in cpu 2 and 3?

Thank you

Xin Xu

--f46d0446311e77720904c274f67e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hi everyone,<br></div><div><br></div><div>I am trying to identify the =
current running task is belonging to domu, dom0 or hypervisor. So I figured=
 if I can separate domu, dom0 and hypervisor to different physical CPUs, th=
en I can just look at cpu and then tell the task belongs to which. I use xm=
 vcpu-pin to pin domu and dom0, but it does not work for hypervisor. I am j=
ust wondering if there is a way to pin hypervisor to a specific cpu?</div>
<div><br></div><div>I am just trying to better understand how this &quot;pi=
nning&quot; cpu works. If I pin domu to cpu 0, does that mean all instructi=
ons belongs to domu will run in cpu 0? Does that mean cpu 0 will be exclusi=
vely assigned to domu and will not run any instructions from dom0 and hyper=
visor? I pin dom0 to cpu 0, and dom1 to cpu1, but i still see instructions =
running in cpu 2 and 3. How can I tell what are those instructions in cpu 2=
 and 3?<br>
</div><div><br></div><div>Thank you</div><div><br></div><div>Xin Xu</div>

--f46d0446311e77720904c274f67e--


--===============4229406698187848956==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4229406698187848956==--


From xen-devel-bounces@lists.xen.org Fri Jun 15 12:51:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 12: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 1SfVwy-0003NR-KE; Fri, 15 Jun 2012 12:48:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jungle.xuxin@gmail.com>) id 1SfH7l-0006vd-5T
	for Xen-devel@lists.xen.org; Thu, 14 Jun 2012 20:58:37 +0000
Received: from [85.158.143.35:18627] by server-2.bemta-4.messagelabs.com id
	A2/8D-17938-C705ADF4; Thu, 14 Jun 2012 20:58:36 +0000
X-Env-Sender: jungle.xuxin@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339707514!13181796!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27088 invoked from network); 14 Jun 2012 20:58:35 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jun 2012 20:58:35 -0000
Received: by obbwd20 with SMTP id wd20so3900138obb.32
	for <Xen-devel@lists.xen.org>; Thu, 14 Jun 2012 13:58:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=YX3ESiI5xaO/7QcJBZleoPIOC4xaw9FnGJHSK1eDq4U=;
	b=XZM3N5QNWlUDTqHzdW4S2/3eWUJezSp08rFqehCgWzg9Pw9Ch0F9zAcm18999Ar8fN
	TKP7jinxeIrpBh+WWszBNhvXvOSo2uYwv1/UpQMB6I2H86BFRMYcyO0iw2V46NjTXU/P
	e6jEIOpNMltGCfYQ+OkWVgAPhZBWCM/ZMiIWDdOnLEgjgiBuhOfmV//lcXgu2eSK8SjC
	rNr0MrC3hVuRBi6i2UFfH9X5ufCfXLxyly5/FfHuxxdPs9AmjyX2sw5uNmbOvSvpS4Hf
	JQjjhdZzfhj3/gXIk45B7lkJNsudOiVFgkEifQfmyZfUBJQiPSnglfQA3+rDA+jBp8jh
	jBZw==
MIME-Version: 1.0
Received: by 10.182.53.100 with SMTP id a4mr3425584obp.3.1339707513860; Thu,
	14 Jun 2012 13:58:33 -0700 (PDT)
Received: by 10.182.137.71 with HTTP; Thu, 14 Jun 2012 13:58:33 -0700 (PDT)
Date: Thu, 14 Jun 2012 16:58:33 -0400
Message-ID: <CA+ANA0HStvsP=6=39h2qDP_gQ7vXRNSSa8PPwAO8ac89Ku8ypg@mail.gmail.com>
From: Xin Xu <jungle.xuxin@gmail.com>
To: Xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 15 Jun 2012 12:48:18 +0000
Subject: [Xen-devel] pin hypervisor to physical 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: multipart/mixed; boundary="===============4229406698187848956=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4229406698187848956==
Content-Type: multipart/alternative; boundary=f46d0446311e77720904c274f67e

--f46d0446311e77720904c274f67e
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,

I am trying to identify the current running task is belonging to domu, dom0
or hypervisor. So I figured if I can separate domu, dom0 and hypervisor to
different physical CPUs, then I can just look at cpu and then tell the task
belongs to which. I use xm vcpu-pin to pin domu and dom0, but it does not
work for hypervisor. I am just wondering if there is a way to pin
hypervisor to a specific cpu?

I am just trying to better understand how this "pinning" cpu works. If I
pin domu to cpu 0, does that mean all instructions belongs to domu will run
in cpu 0? Does that mean cpu 0 will be exclusively assigned to domu and
will not run any instructions from dom0 and hypervisor? I pin dom0 to cpu
0, and dom1 to cpu1, but i still see instructions running in cpu 2 and 3.
How can I tell what are those instructions in cpu 2 and 3?

Thank you

Xin Xu

--f46d0446311e77720904c274f67e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hi everyone,<br></div><div><br></div><div>I am trying to identify the =
current running task is belonging to domu, dom0 or hypervisor. So I figured=
 if I can separate domu, dom0 and hypervisor to different physical CPUs, th=
en I can just look at cpu and then tell the task belongs to which. I use xm=
 vcpu-pin to pin domu and dom0, but it does not work for hypervisor. I am j=
ust wondering if there is a way to pin hypervisor to a specific cpu?</div>
<div><br></div><div>I am just trying to better understand how this &quot;pi=
nning&quot; cpu works. If I pin domu to cpu 0, does that mean all instructi=
ons belongs to domu will run in cpu 0? Does that mean cpu 0 will be exclusi=
vely assigned to domu and will not run any instructions from dom0 and hyper=
visor? I pin dom0 to cpu 0, and dom1 to cpu1, but i still see instructions =
running in cpu 2 and 3. How can I tell what are those instructions in cpu 2=
 and 3?<br>
</div><div><br></div><div>Thank you</div><div><br></div><div>Xin Xu</div>

--f46d0446311e77720904c274f67e--


--===============4229406698187848956==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4229406698187848956==--


From xen-devel-bounces@lists.xen.org Fri Jun 15 13:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 13: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 1SfWOZ-0005ob-UM; Fri, 15 Jun 2012 13:16:59 +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 1SfWOY-0005o6-FN
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 13:16:58 +0000
Received: from [193.109.254.147:11513] by server-9.bemta-14.messagelabs.com id
	CF/4D-27072-2C53BDF4; Fri, 15 Jun 2012 13:16:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339766206!9905616!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14354 invoked from network); 15 Jun 2012 13:16:47 -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; 15 Jun 2012 13:16:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfWOL-000HiQ-UK; Fri, 15 Jun 2012 13:16:45 +0000
Date: Fri, 15 Jun 2012 14:16:45 +0100
From: Tim Deegan <tim@xen.org>
To: Baozeng <sploving1@gmail.com>
Message-ID: <20120615131645.GB49527@ocelot.phlegethon.org>
References: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
	<20120614095816.GF82539@ocelot.phlegethon.org>
	<CAP=GMUHOrzSpRiU52P45vs0FcRcEBAcwSsNVA-TXj0JMq=Z7TA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP=GMUHOrzSpRiU52P45vs0FcRcEBAcwSsNVA-TXj0JMq=Z7TA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen dire-map 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

At 15:15 +0800 on 15 Jun (1339773354), Baozeng wrote:
> I see. I want to monitor Xen's data structures in a trusted VM(dom0).

I don't understand.  Given that Xen controls dom0 entirely, how can it
monitor Xen's datastructures?

> One challenge is how to make dom0 can read Xen's data structure (just
> read, do not need to write). Since Xen has more privilege, dom0 cannot
> read its data directly.  Can we set up appropriate hypervisor-page
> tables for dom0 that map Xen's relevant physical (or virtual) memory
> areas? How to do that? Do we need modify Xen's code? or just the
> dom0's code?

You would need to modify Xen (to allow dom0 to have read-only mappings
of all memory) and dom0 (to understand Xen well enough to follow its
datastructures).  But since a compromised Xen could lie to dom0
about its pagetables, this seems like a very weak kind of security --
especially compared with something like HyperSafe or CloudVisor that
uses a _more_ privileged element to protect the hypervisor.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 13:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 13: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 1SfWOZ-0005ob-UM; Fri, 15 Jun 2012 13:16:59 +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 1SfWOY-0005o6-FN
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 13:16:58 +0000
Received: from [193.109.254.147:11513] by server-9.bemta-14.messagelabs.com id
	CF/4D-27072-2C53BDF4; Fri, 15 Jun 2012 13:16:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339766206!9905616!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14354 invoked from network); 15 Jun 2012 13:16:47 -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; 15 Jun 2012 13:16:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SfWOL-000HiQ-UK; Fri, 15 Jun 2012 13:16:45 +0000
Date: Fri, 15 Jun 2012 14:16:45 +0100
From: Tim Deegan <tim@xen.org>
To: Baozeng <sploving1@gmail.com>
Message-ID: <20120615131645.GB49527@ocelot.phlegethon.org>
References: <CAP=GMUHmHfeE1rDk37HcoHW5ytVHqSaTqyXHt24M9r+q6QDg=g@mail.gmail.com>
	<20120614095816.GF82539@ocelot.phlegethon.org>
	<CAP=GMUHOrzSpRiU52P45vs0FcRcEBAcwSsNVA-TXj0JMq=Z7TA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAP=GMUHOrzSpRiU52P45vs0FcRcEBAcwSsNVA-TXj0JMq=Z7TA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen dire-map 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

At 15:15 +0800 on 15 Jun (1339773354), Baozeng wrote:
> I see. I want to monitor Xen's data structures in a trusted VM(dom0).

I don't understand.  Given that Xen controls dom0 entirely, how can it
monitor Xen's datastructures?

> One challenge is how to make dom0 can read Xen's data structure (just
> read, do not need to write). Since Xen has more privilege, dom0 cannot
> read its data directly.  Can we set up appropriate hypervisor-page
> tables for dom0 that map Xen's relevant physical (or virtual) memory
> areas? How to do that? Do we need modify Xen's code? or just the
> dom0's code?

You would need to modify Xen (to allow dom0 to have read-only mappings
of all memory) and dom0 (to understand Xen well enough to follow its
datastructures).  But since a compromised Xen could lie to dom0
about its pagetables, this seems like a very weak kind of security --
especially compared with something like HyperSafe or CloudVisor that
uses a _more_ privileged element to protect the hypervisor.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 13:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 13: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 1SfWlN-0006sT-Dg; Fri, 15 Jun 2012 13:40: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 1SfWlL-0006sF-UY
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 13:40:32 +0000
Received: from [85.158.139.83:27798] by server-10.bemta-5.messagelabs.com id
	7F/CF-02190-E4B3BDF4; Fri, 15 Jun 2012 13:40:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339767629!27918309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5537 invoked from network); 15 Jun 2012 13:40:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 13:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="13044454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 13:40:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 14:40:28 +0100
Date: Fri, 15 Jun 2012 14:40:13 +0100
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: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Jackson wrote:
> This is v4 of my series to asyncify save/restore.  All comments have
> been addressed.
> 
> I have retested this with HVM (RHEL) and PV guests, for both localhost
> migration and save/restore.  RHEL seems to have some unreliability
> which occurs with the baseline too.  I was not able to test stub dms
> at all because when trying to boot my RHEL guest with a stub dm the dm
> domain immediately crashed.

IanC, didn't you test xen-unstable with stubdoms not too long ago?

In any case we should probably add "working stubdoms" to the blocker list.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 13:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 13: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 1SfWlN-0006sT-Dg; Fri, 15 Jun 2012 13:40: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 1SfWlL-0006sF-UY
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 13:40:32 +0000
Received: from [85.158.139.83:27798] by server-10.bemta-5.messagelabs.com id
	7F/CF-02190-E4B3BDF4; Fri, 15 Jun 2012 13:40:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1339767629!27918309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5537 invoked from network); 15 Jun 2012 13:40:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 13:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="13044454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 13:40:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 14:40:28 +0100
Date: Fri, 15 Jun 2012 14:40:13 +0100
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: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Jackson wrote:
> This is v4 of my series to asyncify save/restore.  All comments have
> been addressed.
> 
> I have retested this with HVM (RHEL) and PV guests, for both localhost
> migration and save/restore.  RHEL seems to have some unreliability
> which occurs with the baseline too.  I was not able to test stub dms
> at all because when trying to boot my RHEL guest with a stub dm the dm
> domain immediately crashed.

IanC, didn't you test xen-unstable with stubdoms not too long ago?

In any case we should probably add "working stubdoms" to the blocker list.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 13:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 13:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfWx1-0007VE-8p; Fri, 15 Jun 2012 13:52:35 +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 1SfWwz-0007Uw-LC
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 13:52:34 +0000
Received: from [85.158.143.99:26264] by server-3.bemta-4.messagelabs.com id
	49/02-05808-02E3BDF4; Fri, 15 Jun 2012 13:52:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339768351!27531320!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28689 invoked from network); 15 Jun 2012 13:52:31 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 13:52:31 -0000
Received: by wibhj6 with SMTP id hj6so509873wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 06:52:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=gFApE18+WffXkPku0qeSWEDFPgu0BiJ4MUrcPcj/tqg=;
	b=ZjsTgvcjhmjnbSG6X9uUiyVxKpaQP0FWwIvdf3L4mSESkEeUJ23+RzHx1Xu8OFsIEa
	EhTeVr3K9A1ddpwAr5SCVSt/0f/eWTHg8fY9O2daDuzF42Y9z4AK3wStOMJxDvHJMLA5
	TSfE7nMk67W4OxIdh4QeSOfdL0Ud8ygePrlhvHeSnXh+uIq0Q0eyJhD47ywAhKwhC9bd
	xV/2EijhtJvWckdET9xZnny4PsVpsj11gryBD0qbCPWdeH/J/am7rSOgcF5H+Cv3vGkD
	kyFN3wfPVba5ocMMA7ID2d+9uk3h6ihDPdqwZKzDoFggnALcHBOCPYrX3ZN9eQQI20yr
	FnEg==
Received: by 10.180.102.228 with SMTP id fr4mr4797493wib.6.1339768351427;
	Fri, 15 Jun 2012 06:52:31 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id eb8sm3201398wib.11.2012.06.15.06.52.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 06:52:29 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6337a90a11ed2ef48442728648c3d828c8ecc640
Message-Id: <6337a90a11ed2ef48442.1339768347@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 15:52:27 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: document the memory ownership of some
	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

Specifying they allocate dynamic memory that needs to be explicitly freed.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -586,8 +586,16 @@ int libxl_primary_console_get_tty(libxl_
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);
 libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
+  /* On success, a list of nb_domain libxl_dominfo elements is
+   * returned. That comes from malloc, thus it is up to the caller
+   * to invoke libxl_dominfo_list_free() on it.
+   */
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
 libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
+  /* On success, a list of nb_pool libxl_cpupoolinfo elements is
+   * returned. That comes from malloc, thus it is up to the caller
+   * to invoke libxl_cpupoolinfo_list_free() on it.
+   */
 void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr);
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
@@ -768,9 +776,18 @@ int libxl_userdata_retrieve(libxl_ctx *c
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
 #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
+  /* On success, the actual machine topology is returned as a
+   * list of nr libxl_cputopology elements. That comes from malloc,
+   * thus it is up to the caller to invoke libxl_cputopology_list_free()
+   * on it.
+   */
 void libxl_cputopology_list_free(libxl_cputopology *, int nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
+  /* On success, a list of nrcpus libxl_vcpuinfo elements is
+   * returned. That comes from malloc, thus it is up to the
+   * caller to invoke libxl_vcpuinfo_list_free() on it.
+   */
 void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
                            libxl_cpumap *cpumap);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 13:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 13:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfWx1-0007VE-8p; Fri, 15 Jun 2012 13:52:35 +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 1SfWwz-0007Uw-LC
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 13:52:34 +0000
Received: from [85.158.143.99:26264] by server-3.bemta-4.messagelabs.com id
	49/02-05808-02E3BDF4; Fri, 15 Jun 2012 13:52:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1339768351!27531320!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28689 invoked from network); 15 Jun 2012 13:52:31 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 13:52:31 -0000
Received: by wibhj6 with SMTP id hj6so509873wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 06:52:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=gFApE18+WffXkPku0qeSWEDFPgu0BiJ4MUrcPcj/tqg=;
	b=ZjsTgvcjhmjnbSG6X9uUiyVxKpaQP0FWwIvdf3L4mSESkEeUJ23+RzHx1Xu8OFsIEa
	EhTeVr3K9A1ddpwAr5SCVSt/0f/eWTHg8fY9O2daDuzF42Y9z4AK3wStOMJxDvHJMLA5
	TSfE7nMk67W4OxIdh4QeSOfdL0Ud8ygePrlhvHeSnXh+uIq0Q0eyJhD47ywAhKwhC9bd
	xV/2EijhtJvWckdET9xZnny4PsVpsj11gryBD0qbCPWdeH/J/am7rSOgcF5H+Cv3vGkD
	kyFN3wfPVba5ocMMA7ID2d+9uk3h6ihDPdqwZKzDoFggnALcHBOCPYrX3ZN9eQQI20yr
	FnEg==
Received: by 10.180.102.228 with SMTP id fr4mr4797493wib.6.1339768351427;
	Fri, 15 Jun 2012 06:52:31 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id eb8sm3201398wib.11.2012.06.15.06.52.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 06:52:29 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6337a90a11ed2ef48442728648c3d828c8ecc640
Message-Id: <6337a90a11ed2ef48442.1339768347@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 15:52:27 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: document the memory ownership of some
	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

Specifying they allocate dynamic memory that needs to be explicitly freed.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -586,8 +586,16 @@ int libxl_primary_console_get_tty(libxl_
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);
 libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
+  /* On success, a list of nb_domain libxl_dominfo elements is
+   * returned. That comes from malloc, thus it is up to the caller
+   * to invoke libxl_dominfo_list_free() on it.
+   */
 void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
 libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
+  /* On success, a list of nb_pool libxl_cpupoolinfo elements is
+   * returned. That comes from malloc, thus it is up to the caller
+   * to invoke libxl_cpupoolinfo_list_free() on it.
+   */
 void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr);
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
@@ -768,9 +776,18 @@ int libxl_userdata_retrieve(libxl_ctx *c
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
 #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
+  /* On success, the actual machine topology is returned as a
+   * list of nr libxl_cputopology elements. That comes from malloc,
+   * thus it is up to the caller to invoke libxl_cputopology_list_free()
+   * on it.
+   */
 void libxl_cputopology_list_free(libxl_cputopology *, int nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
+  /* On success, a list of nrcpus libxl_vcpuinfo elements is
+   * returned. That comes from malloc, thus it is up to the
+   * caller to invoke libxl_vcpuinfo_list_free() on it.
+   */
 void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
                            libxl_cpumap *cpumap);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 14:11:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 14:11: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 1SfXF7-0008MN-W7; Fri, 15 Jun 2012 14:11: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 1SfXF7-0008MI-AT
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 14:11:17 +0000
Received: from [85.158.139.83:5880] by server-12.bemta-5.messagelabs.com id
	DF/96-25233-4824BDF4; Fri, 15 Jun 2012 14:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339769475!23620028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29848 invoked from network); 15 Jun 2012 14:11:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 14:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="13045406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 14:11:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 15:11:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfXF4-0006Eh-SR; Fri, 15 Jun 2012 14:11:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfXF4-0002fq-QR;
	Fri, 15 Jun 2012 15:11:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20443.17026.774916.705627@mariner.uk.xensource.com>
Date: Fri, 15 Jun 2012 15:11:14 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <6337a90a11ed2ef48442.1339768347@Solace>
References: <6337a90a11ed2ef48442.1339768347@Solace>
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] libxl: document the memory ownership of
	some 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

Dario Faggioli writes ("[PATCH] libxl: document the memory ownership of some functions"):
> Specifying they allocate dynamic memory that needs to be explicitly freed.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

But, just a suggestion:

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h

Perhaps it would be worth writing this comment once near the top, eg:

 /* These functions each return (on success) an array of elements,
  * and the length via the int* out parameter.  These arrays and
  * their contents come from malloc, and must be freed with the
  * corresponding libxl_THING_list_free function.
  */

And perhaps change  int *nb_domain  etc. to  int *nb_domain_out.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 14:11:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 14:11: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 1SfXF7-0008MN-W7; Fri, 15 Jun 2012 14:11: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 1SfXF7-0008MI-AT
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 14:11:17 +0000
Received: from [85.158.139.83:5880] by server-12.bemta-5.messagelabs.com id
	DF/96-25233-4824BDF4; Fri, 15 Jun 2012 14:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339769475!23620028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29848 invoked from network); 15 Jun 2012 14:11:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 14:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="13045406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 14:11:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 15:11:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfXF4-0006Eh-SR; Fri, 15 Jun 2012 14:11:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfXF4-0002fq-QR;
	Fri, 15 Jun 2012 15:11:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20443.17026.774916.705627@mariner.uk.xensource.com>
Date: Fri, 15 Jun 2012 15:11:14 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <6337a90a11ed2ef48442.1339768347@Solace>
References: <6337a90a11ed2ef48442.1339768347@Solace>
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] libxl: document the memory ownership of
	some 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

Dario Faggioli writes ("[PATCH] libxl: document the memory ownership of some functions"):
> Specifying they allocate dynamic memory that needs to be explicitly freed.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

But, just a suggestion:

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h

Perhaps it would be worth writing this comment once near the top, eg:

 /* These functions each return (on success) an array of elements,
  * and the length via the int* out parameter.  These arrays and
  * their contents come from malloc, and must be freed with the
  * corresponding libxl_THING_list_free function.
  */

And perhaps change  int *nb_domain  etc. to  int *nb_domain_out.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 15:11:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 15:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfYAq-0001VQ-QM; Fri, 15 Jun 2012 15:10:56 +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 1SfYAp-0001VK-9z
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 15:10:55 +0000
Received: from [193.109.254.147:23820] by server-9.bemta-14.messagelabs.com id
	BF/6A-27072-E705BDF4; Fri, 15 Jun 2012 15:10:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339773053!4310100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9247 invoked from network); 15 Jun 2012 15:10:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 15:10:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="13047494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 15:10:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 16:10:52 +0100
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 1SfYAm-0006aJ-JD;
	Fri, 15 Jun 2012 15:10:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SfYAl-0002Oz-SR;
	Fri, 15 Jun 2012 16:10:52 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13047-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 16:10:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13047: 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 13047 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13047/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 12970
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12970

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 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-amd64-win         16 leak-check/check             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-i386-xl-win7-amd64 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                  a9c0a89c08f2
baseline version:
 xen                  435493696053

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=a9c0a89c08f2
+ . 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 a9c0a89c08f2
+ branch=xen-4.1-testing
+ revision=a9c0a89c08f2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r a9c0a89c08f2 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 15:11:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 15:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfYAq-0001VQ-QM; Fri, 15 Jun 2012 15:10:56 +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 1SfYAp-0001VK-9z
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 15:10:55 +0000
Received: from [193.109.254.147:23820] by server-9.bemta-14.messagelabs.com id
	BF/6A-27072-E705BDF4; Fri, 15 Jun 2012 15:10:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1339773053!4310100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9247 invoked from network); 15 Jun 2012 15:10:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 15:10:53 -0000
X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="13047494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 15:10:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 16:10:52 +0100
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 1SfYAm-0006aJ-JD;
	Fri, 15 Jun 2012 15:10:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SfYAl-0002Oz-SR;
	Fri, 15 Jun 2012 16:10:52 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13047-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 16:10:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13047: 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 13047 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13047/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 12970
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 12970

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 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-amd64-win         16 leak-check/check             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-i386-xl-win7-amd64 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                  a9c0a89c08f2
baseline version:
 xen                  435493696053

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=a9c0a89c08f2
+ . 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 a9c0a89c08f2
+ branch=xen-4.1-testing
+ revision=a9c0a89c08f2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r a9c0a89c08f2 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 15:20:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 15:20: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 1SfYJE-0001nO-26; Fri, 15 Jun 2012 15:19:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SfYJC-0001nJ-Is
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 15:19:34 +0000
Received: from [193.109.254.147:12351] by server-8.bemta-14.messagelabs.com id
	94/B4-27132-5825BDF4; Fri, 15 Jun 2012 15:19:33 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339773573!9930140!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17387 invoked from network); 15 Jun 2012 15:19:33 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	15 Jun 2012 15:19:33 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78914204; Fri, 15 Jun 2012 17:19:32 +0200
Message-ID: <1339773566.4705.37.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 17:19:26 +0200
In-Reply-To: <20443.17026.774916.705627@mariner.uk.xensource.com>
References: <6337a90a11ed2ef48442.1339768347@Solace>
	<20443.17026.774916.705627@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: document the memory ownership of
	some 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: multipart/mixed; boundary="===============4487741690008278174=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4487741690008278174==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-MUmHp1+K3YVypTv9xAnD"


--=-MUmHp1+K3YVypTv9xAnD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-15 at 15:11 +0100, Ian Jackson wrote:
> Perhaps it would be worth writing this comment once near the top, eg:
>=20
>  /* These functions each return (on success) an array of elements,
>   * and the length via the int* out parameter.  These arrays and
>   * their contents come from malloc, and must be freed with the
>   * corresponding libxl_THING_list_free function.
>   */
>=20
> And perhaps change  int *nb_domain  etc. to  int *nb_domain_out.
>=20
I like this, and I'm fine with going for this and respending. Just to be
sure, I'd need to gather all those functions together, moving them from
their current positions in the header... Would that be fine?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-MUmHp1+K3YVypTv9xAnD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/bUn4ACgkQk4XaBE3IOsQWfgCcCno7em7/vbkAIi5abCSoQn1N
u48AnR6kXos52FsEwuDtcOYukT+i/gFH
=sLyK
-----END PGP SIGNATURE-----

--=-MUmHp1+K3YVypTv9xAnD--



--===============4487741690008278174==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4487741690008278174==--



From xen-devel-bounces@lists.xen.org Fri Jun 15 15:20:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 15:20: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 1SfYJE-0001nO-26; Fri, 15 Jun 2012 15:19:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SfYJC-0001nJ-Is
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 15:19:34 +0000
Received: from [193.109.254.147:12351] by server-8.bemta-14.messagelabs.com id
	94/B4-27132-5825BDF4; Fri, 15 Jun 2012 15:19:33 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339773573!9930140!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17387 invoked from network); 15 Jun 2012 15:19:33 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	15 Jun 2012 15:19:33 -0000
Received: from [62.94.183.142] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78914204; Fri, 15 Jun 2012 17:19:32 +0200
Message-ID: <1339773566.4705.37.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 17:19:26 +0200
In-Reply-To: <20443.17026.774916.705627@mariner.uk.xensource.com>
References: <6337a90a11ed2ef48442.1339768347@Solace>
	<20443.17026.774916.705627@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: document the memory ownership of
	some 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: multipart/mixed; boundary="===============4487741690008278174=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4487741690008278174==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-MUmHp1+K3YVypTv9xAnD"


--=-MUmHp1+K3YVypTv9xAnD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-15 at 15:11 +0100, Ian Jackson wrote:
> Perhaps it would be worth writing this comment once near the top, eg:
>=20
>  /* These functions each return (on success) an array of elements,
>   * and the length via the int* out parameter.  These arrays and
>   * their contents come from malloc, and must be freed with the
>   * corresponding libxl_THING_list_free function.
>   */
>=20
> And perhaps change  int *nb_domain  etc. to  int *nb_domain_out.
>=20
I like this, and I'm fine with going for this and respending. Just to be
sure, I'd need to gather all those functions together, moving them from
their current positions in the header... Would that be fine?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-MUmHp1+K3YVypTv9xAnD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/bUn4ACgkQk4XaBE3IOsQWfgCcCno7em7/vbkAIi5abCSoQn1N
u48AnR6kXos52FsEwuDtcOYukT+i/gFH
=sLyK
-----END PGP SIGNATURE-----

--=-MUmHp1+K3YVypTv9xAnD--



--===============4487741690008278174==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4487741690008278174==--



From xen-devel-bounces@lists.xen.org Fri Jun 15 16:03:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 16:03: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 1SfYzU-0003Dl-PD; Fri, 15 Jun 2012 16:03:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SfYzT-0003Dg-4D
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 16:03:15 +0000
Received: from [85.158.143.35:34473] by server-1.bemta-4.messagelabs.com id
	56/91-24392-2CC5BDF4; Fri, 15 Jun 2012 16:03:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339776194!13329680!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14957 invoked from network); 15 Jun 2012 16:03:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	15 Jun 2012 16:03:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Jun 2012 17:03:13 +0100
Message-Id: <4FDB790F020000780008A406@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 15 Jun 2012 17:03:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] fpu_taskswitch adjustment 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

While pv-ops so far doesn't care to eliminate the two trap-and-
emulate CR0 accesses from the asm/xor.h save/restore
operations, the legacy x86-64 kernel uses conditional clts()/stts()
for this purpose. While looking into whether to extend this to the
newly added (in 3.5) AVX operations there I realized that this isn't
fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
kernel_fpu_end() pair (as it will stts() at the end no matter what
the original state of CR0.TS was).

In order to not introduce completely new hypercalls to overcome
this (fpu_taskswitch isn't really extensible on its own), I'm
considering to add a new VM assist, altering the fpu_taskswitch
behavior so that it would return an indicator whether any change
to the virtual CR0.TS was done. That way, the kernel can
implement a true save/restore cycle here.

In order to allow the kernel to run on older hypervisors without
extra conditionals (behaving the same way as it does currently,
i.e. with the incorrect nesting), the return value 0 (which the
hypercall currently always returns) would need to be used to
indicate that the bit got actually flipped (such that on an old
hypervisor an updated kernel would always think that
something needs to be restored).

Would that be an acceptable solution? Can someone think of
other ways to deal with this? (And - is pv-ops interested in
eliminating the two CR0 access emulations in what is supposed
to be a fast path?)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 16:03:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 16:03: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 1SfYzU-0003Dl-PD; Fri, 15 Jun 2012 16:03:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SfYzT-0003Dg-4D
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 16:03:15 +0000
Received: from [85.158.143.35:34473] by server-1.bemta-4.messagelabs.com id
	56/91-24392-2CC5BDF4; Fri, 15 Jun 2012 16:03:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1339776194!13329680!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14957 invoked from network); 15 Jun 2012 16:03:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	15 Jun 2012 16:03:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Jun 2012 17:03:13 +0100
Message-Id: <4FDB790F020000780008A406@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 15 Jun 2012 17:03:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] fpu_taskswitch adjustment 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

While pv-ops so far doesn't care to eliminate the two trap-and-
emulate CR0 accesses from the asm/xor.h save/restore
operations, the legacy x86-64 kernel uses conditional clts()/stts()
for this purpose. While looking into whether to extend this to the
newly added (in 3.5) AVX operations there I realized that this isn't
fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
kernel_fpu_end() pair (as it will stts() at the end no matter what
the original state of CR0.TS was).

In order to not introduce completely new hypercalls to overcome
this (fpu_taskswitch isn't really extensible on its own), I'm
considering to add a new VM assist, altering the fpu_taskswitch
behavior so that it would return an indicator whether any change
to the virtual CR0.TS was done. That way, the kernel can
implement a true save/restore cycle here.

In order to allow the kernel to run on older hypervisors without
extra conditionals (behaving the same way as it does currently,
i.e. with the incorrect nesting), the return value 0 (which the
hypercall currently always returns) would need to be used to
indicate that the bit got actually flipped (such that on an old
hypervisor an updated kernel would always think that
something needs to be restored).

Would that be an acceptable solution? Can someone think of
other ways to deal with this? (And - is pv-ops interested in
eliminating the two CR0 access emulations in what is supposed
to be a fast path?)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 16:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 16: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 1SfZ2S-0003K6-C0; Fri, 15 Jun 2012 16:06:20 +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 1SfZ2Q-0003Ju-Bj
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 16:06:18 +0000
Received: from [85.158.139.83:30976] by server-3.bemta-5.messagelabs.com id
	57/AE-03367-97D5BDF4; Fri, 15 Jun 2012 16:06:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339776375!23954924!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MzA5OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17060 invoked from network); 15 Jun 2012 16:06:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 16:06:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5FG6BWi027459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 16:06:12 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
	q5FG6An2023700
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Jun 2012 16:06:11 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
	q5FG6AXf030578; Fri, 15 Jun 2012 11:06:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Jun 2012 09:06:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2366940297; Fri, 15 Jun 2012 11:58:44 -0400 (EDT)
Date: Fri, 15 Jun 2012 11:58:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ml@consolo.de, Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120615155844.GB20422@phenom.dumpdata.com>
References: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 03:11:48PM +0200, ml@consolo.de wrote:
> 
> Hi,
> 
> I am currently trying to get kdb working with the current 4.1 XEN release.
> I first tried to use debuggers.hg, but could not manage to compile
> it due tho many different errors.

Did you email the author (Mukesh) of debuggers.hg to see if he can help?

> 
> Due to these errors and since the branch of debuggers.hg seems to be
> rather old, I really would like to use kdb with the *current* XEN
> release.
> 
> Can anyone hint me how to do this? Is copying the /kdb subfolder and
> recompiling sufficient? I suppose not and that there are additional
> modifications necessary in the Xen system itself? Is there any
> information available how to it?
> 
> Thanks a lot for your help
> cw
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 15 16:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 16: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 1SfZ2S-0003K6-C0; Fri, 15 Jun 2012 16:06:20 +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 1SfZ2Q-0003Ju-Bj
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 16:06:18 +0000
Received: from [85.158.139.83:30976] by server-3.bemta-5.messagelabs.com id
	57/AE-03367-97D5BDF4; Fri, 15 Jun 2012 16:06:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1339776375!23954924!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MzA5OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17060 invoked from network); 15 Jun 2012 16:06:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 16:06:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5FG6BWi027459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 16:06:12 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
	q5FG6An2023700
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Jun 2012 16:06:11 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
	q5FG6AXf030578; Fri, 15 Jun 2012 11:06:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Jun 2012 09:06:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2366940297; Fri, 15 Jun 2012 11:58:44 -0400 (EDT)
Date: Fri, 15 Jun 2012 11:58:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ml@consolo.de, Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120615155844.GB20422@phenom.dumpdata.com>
References: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 14, 2012 at 03:11:48PM +0200, ml@consolo.de wrote:
> 
> Hi,
> 
> I am currently trying to get kdb working with the current 4.1 XEN release.
> I first tried to use debuggers.hg, but could not manage to compile
> it due tho many different errors.

Did you email the author (Mukesh) of debuggers.hg to see if he can help?

> 
> Due to these errors and since the branch of debuggers.hg seems to be
> rather old, I really would like to use kdb with the *current* XEN
> release.
> 
> Can anyone hint me how to do this? Is copying the /kdb subfolder and
> recompiling sufficient? I suppose not and that there are additional
> modifications necessary in the Xen system itself? Is there any
> information available how to it?
> 
> Thanks a lot for your help
> cw
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 15 16:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 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 1SfZSp-00045h-Hf; Fri, 15 Jun 2012 16:33:35 +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 1SfZSn-00045c-LX
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 16:33:33 +0000
Received: from [193.109.254.147:54198] by server-8.bemta-14.messagelabs.com id
	FF/42-27132-DD36BDF4; Fri, 15 Jun 2012 16:33:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339778011!9934344!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4504 invoked from network); 15 Jun 2012 16:33:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 16:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13049801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 16:33:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 17:33:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfZJ1-00071f-4G; Fri, 15 Jun 2012 16:23:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfZJ1-0002wh-3I;
	Fri, 15 Jun 2012 17:23:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20443.24959.81543.348774@mariner.uk.xensource.com>
Date: Fri, 15 Jun 2012 17:23:27 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339773566.4705.37.camel@Solace>
References: <6337a90a11ed2ef48442.1339768347@Solace>
	<20443.17026.774916.705627@mariner.uk.xensource.com>
	<1339773566.4705.37.camel@Solace>
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] libxl: document the memory ownership of
	some 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

Dario Faggioli writes ("Re: [PATCH] libxl: document the memory ownership of some functions"):
> On Fri, 2012-06-15 at 15:11 +0100, Ian Jackson wrote:
> > Perhaps it would be worth writing this comment once near the top, eg:
> > 
> >  /* These functions each return (on success) an array of elements,
> >   * and the length via the int* out parameter.  These arrays and
> >   * their contents come from malloc, and must be freed with the
> >   * corresponding libxl_THING_list_free function.
> >   */
> > 
> > And perhaps change  int *nb_domain  etc. to  int *nb_domain_out.
> 
> I like this, and I'm fine with going for this and respending. Just to be
> sure, I'd need to gather all those functions together, moving them from
> their current positions in the header... Would that be fine?

Moving the functions is fine if it seems like the new order is
reasonable.  I haven't checked...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 16:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 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 1SfZSp-00045h-Hf; Fri, 15 Jun 2012 16:33:35 +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 1SfZSn-00045c-LX
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 16:33:33 +0000
Received: from [193.109.254.147:54198] by server-8.bemta-14.messagelabs.com id
	FF/42-27132-DD36BDF4; Fri, 15 Jun 2012 16:33:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1339778011!9934344!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4504 invoked from network); 15 Jun 2012 16:33:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 16:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13049801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 16:33:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 17:33:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfZJ1-00071f-4G; Fri, 15 Jun 2012 16:23:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfZJ1-0002wh-3I;
	Fri, 15 Jun 2012 17:23:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20443.24959.81543.348774@mariner.uk.xensource.com>
Date: Fri, 15 Jun 2012 17:23:27 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1339773566.4705.37.camel@Solace>
References: <6337a90a11ed2ef48442.1339768347@Solace>
	<20443.17026.774916.705627@mariner.uk.xensource.com>
	<1339773566.4705.37.camel@Solace>
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] libxl: document the memory ownership of
	some 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

Dario Faggioli writes ("Re: [PATCH] libxl: document the memory ownership of some functions"):
> On Fri, 2012-06-15 at 15:11 +0100, Ian Jackson wrote:
> > Perhaps it would be worth writing this comment once near the top, eg:
> > 
> >  /* These functions each return (on success) an array of elements,
> >   * and the length via the int* out parameter.  These arrays and
> >   * their contents come from malloc, and must be freed with the
> >   * corresponding libxl_THING_list_free function.
> >   */
> > 
> > And perhaps change  int *nb_domain  etc. to  int *nb_domain_out.
> 
> I like this, and I'm fine with going for this and respending. Just to be
> sure, I'd need to gather all those functions together, moving them from
> their current positions in the header... Would that be fine?

Moving the functions is fine if it seems like the new order is
reasonable.  I haven't checked...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 16:49:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 16:49: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 1SfZi9-0004Md-DV; Fri, 15 Jun 2012 16:49: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 1SfZi7-0004MY-Tu
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 16:49:24 +0000
Received: from [85.158.139.83:44885] by server-12.bemta-5.messagelabs.com id
	CB/95-25233-3976BDF4; Fri, 15 Jun 2012 16:49:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339778962!27831033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28871 invoked from network); 15 Jun 2012 16:49:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 16:49:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13050167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 16:49:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 17:49:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfZe9-0007Go-ET; Fri, 15 Jun 2012 16:45:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfZe9-0002xa-Cg;
	Fri, 15 Jun 2012 17:45:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20443.26269.316806.269605@mariner.uk.xensource.com>
Date: Fri, 15 Jun 2012 17:45:17 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-2-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 01/13] libxl: change ao_device_remove to
	ao_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

Roger Pau Monne writes ("[PATCH v6 01/13] libxl: change ao_device_remove to ao_device"):
> Introduce a new structure to track state of device backends, that will
> be used in following patches on this series.
...

Looks good.  I have only one comment:

> +static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
> +{
> +    STATE_AO_GC(aodev->ao);
> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
> +    char *fe_path = libxl__device_frontend_path(gc, aodev->dev);
> +    xs_transaction_t t = 0;
> +    int ret = 0;
> +
> +    if (aodev->action == DEVICE_DISCONNECT) {
> +        do {
> +            t = xs_transaction_start(CTX->xsh);
> +            libxl__xs_path_cleanup(gc, t, fe_path);
> +            libxl__xs_path_cleanup(gc, t, be_path);
> +            ret = !xs_transaction_end(CTX->xsh, t, 0);
> +        } while (ret && errno == EAGAIN);

The error handling here seems a bit lacking.  Perhaps you should
import my "[PATCH 08/21] libxl: provide libxl__xs_*_checked ..." into
your series and use those ?  You can see an example of how they're
used in "[PATCH 09/21] libxl: wait for qemu to acknowledge logdirty
command".

And you need to check the return values from libxl__xs_path_cleanup.

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 Jun 15 16:49:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 16:49: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 1SfZi9-0004Md-DV; Fri, 15 Jun 2012 16:49: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 1SfZi7-0004MY-Tu
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 16:49:24 +0000
Received: from [85.158.139.83:44885] by server-12.bemta-5.messagelabs.com id
	CB/95-25233-3976BDF4; Fri, 15 Jun 2012 16:49:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1339778962!27831033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28871 invoked from network); 15 Jun 2012 16:49:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 16:49:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13050167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 16:49:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 17:49:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SfZe9-0007Go-ET; Fri, 15 Jun 2012 16:45:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SfZe9-0002xa-Cg;
	Fri, 15 Jun 2012 17:45:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20443.26269.316806.269605@mariner.uk.xensource.com>
Date: Fri, 15 Jun 2012 17:45:17 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-2-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 01/13] libxl: change ao_device_remove to
	ao_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

Roger Pau Monne writes ("[PATCH v6 01/13] libxl: change ao_device_remove to ao_device"):
> Introduce a new structure to track state of device backends, that will
> be used in following patches on this series.
...

Looks good.  I have only one comment:

> +static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
> +{
> +    STATE_AO_GC(aodev->ao);
> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
> +    char *fe_path = libxl__device_frontend_path(gc, aodev->dev);
> +    xs_transaction_t t = 0;
> +    int ret = 0;
> +
> +    if (aodev->action == DEVICE_DISCONNECT) {
> +        do {
> +            t = xs_transaction_start(CTX->xsh);
> +            libxl__xs_path_cleanup(gc, t, fe_path);
> +            libxl__xs_path_cleanup(gc, t, be_path);
> +            ret = !xs_transaction_end(CTX->xsh, t, 0);
> +        } while (ret && errno == EAGAIN);

The error handling here seems a bit lacking.  Perhaps you should
import my "[PATCH 08/21] libxl: provide libxl__xs_*_checked ..." into
your series and use those ?  You can see an example of how they're
used in "[PATCH 09/21] libxl: wait for qemu to acknowledge logdirty
command".

And you need to check the return values from libxl__xs_path_cleanup.

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 Jun 15 17:05:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17: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 1SfZxb-0004vS-Hu; Fri, 15 Jun 2012 17:05:23 +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 1SfZxa-0004vM-Ex
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:22 +0000
Received: from [85.158.139.83:57072] by server-2.bemta-5.messagelabs.com id
	1B/4B-04598-15B6BDF4; Fri, 15 Jun 2012 17:05:21 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27428 invoked from network); 15 Jun 2012 17:05:20 -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;
	15 Jun 2012 17:05:20 -0000
Received: by wibhj6 with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=5W7eA+2ZNyJeEWJ2LDPzI+hNiNbaCTl8XF/3G7AESH8=;
	b=j7YmDWLYwqq3xiPXCOI/AZIBXgMCOLUhoHN3+8bPXIeqIhzoUIIv26Y5AXI06/74vP
	Q78bncponnU2C2OumbuP8UBV+bfppT51Drq25BYeg7PiY3uN3JFDySBy5WUnql9g8wIf
	Mts278yl9WOiYc46iaP1+GeAXmG2IWvOOjJWdmAXnlWDhs9qLJ1cR6RkFLYVXY7/ahPZ
	WMbV+GHsI6ms7dHeFPvCjiUx/S1HCR57bANTO2AzJumMWJdHSZA3Xh1NTQcboWerkMu2
	aXr+TJZMGseXVz4M0NJWQUmSkGnlUD1UHN6Zb1D3+JRYS5ufAD8edD30gGPH7ab/SSOV
	ANAQ==
Received: by 10.216.216.226 with SMTP id g76mr3529027wep.221.1339779920280;
	Fri, 15 Jun 2012 10:05:20 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:19 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6c32fcbbd4896a55b73e3da99f84187884f61e64
Message-Id: <6c32fcbbd4896a55b73e.1339779869@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:29 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
	GCREALLOC_ARRAY 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

Causing a build failure when trying to use it:

xxx: error: expected ';' before ')' token
xxx: error: expected statement before ')' token

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
 #define GCREALLOC_ARRAY(var, nmemb)                                     \
     (assert(nmemb > 0),                                                 \
      assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
-     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
 
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17: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 1SfZxd-0004vo-U7; Fri, 15 Jun 2012 17:05:25 +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 1SfZxc-0004vc-PU
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:24 +0000
Received: from [85.158.138.51:61749] by server-10.bemta-3.messagelabs.com id
	63/0F-01753-F4B6BDF4; Fri, 15 Jun 2012 17:05:19 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339779918!27951887!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26984 invoked from network); 15 Jun 2012 17:05:18 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:18 -0000
Received: by werf3 with SMTP id f3so2750411wer.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=KI33SO7TxmuvgECQPqZ59rJamm/jT9M684mi+GVq2QY=;
	b=WboVDOL7nzQ5nkDi9WY125LuPP5HVRTAu4J3ZgckdYRUYPBqw2WskYPlYvras8n5YR
	ZfeEMeBMVN2/RkBhnjQMgYKpduDON5RLVh129j7HVumdhVEoDvSPY5F3E/QS7I24jnYj
	tjSBQlRFBpWYQkneTlxU/OeMvTk5/qhuPvFaeK3yfUVkofymo/yQkAqGP0noRVy1uFE+
	X/bwgEap9YE396mP/i3ZE6RDuGJpGkrjieUQGlumiC0709s12UrIxZcVxmnnO3RSNkbR
	n/5cUYrKAnRwjbCBvCqbDHG463QzGDd3EAHzPkH+7BMmsGnWdL0nEB50Ovmjb8/BdY83
	0cpQ==
Received: by 10.180.91.225 with SMTP id ch1mr5957578wib.18.1339779918004;
	Fri, 15 Jun 2012 10:05:18 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:16 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:28 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 00 of 10 v2] Automatic NUMA placement for xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Everyone,

This is the second take for automaic NUMA placement for Xen 4.2, for the sake
of feature parity with xm/xend.

All the comments v1 received have been addressed. Actually, some bits of the
patchset have been deeply restructured for achieving this. Details in single
changelogs.

Here it is what the series ships:

 1/10 libxl: fix a typo in the GCREALLOC_ARRAY macro

Is just a build fix (already posted separately).

 2/10 libxl: add a new Array type to the IDL
 3/10 libxl,libxc: introduce libxl_get_numainfo()
 4/10 xl: add more NUMA information to `xl info -n'
 5/10 libxl: rename libxl_cpumap to libxl_bitmap
 6/10 libxl: expand the libxl_bitmap API a bit
 7/10 libxl: introduce some node map helpers
 
Introduce the data structures, calls and infrastructure needed for retrieving
all the information about the NUMA-ness of the system and deal with them at the
toolstack level.

 8/10 libxl: enable automatic placement of guests on NUMA nodes
 9/10 libxl: have NUMA placement deal with cpupools

Is the actual, well, 'food' (no, I'm not calling it 'the meat' as I'm
vegetarian!  :-D).

 10/10 Some automatic NUMA placement documentation

Puts some more details about the implementation and the usage of the new
feature directly in the tree.

Thanks a lot and Regards,
Dario

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17: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 1SfZxb-0004vS-Hu; Fri, 15 Jun 2012 17:05:23 +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 1SfZxa-0004vM-Ex
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:22 +0000
Received: from [85.158.139.83:57072] by server-2.bemta-5.messagelabs.com id
	1B/4B-04598-15B6BDF4; Fri, 15 Jun 2012 17:05:21 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27428 invoked from network); 15 Jun 2012 17:05:20 -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;
	15 Jun 2012 17:05:20 -0000
Received: by wibhj6 with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=5W7eA+2ZNyJeEWJ2LDPzI+hNiNbaCTl8XF/3G7AESH8=;
	b=j7YmDWLYwqq3xiPXCOI/AZIBXgMCOLUhoHN3+8bPXIeqIhzoUIIv26Y5AXI06/74vP
	Q78bncponnU2C2OumbuP8UBV+bfppT51Drq25BYeg7PiY3uN3JFDySBy5WUnql9g8wIf
	Mts278yl9WOiYc46iaP1+GeAXmG2IWvOOjJWdmAXnlWDhs9qLJ1cR6RkFLYVXY7/ahPZ
	WMbV+GHsI6ms7dHeFPvCjiUx/S1HCR57bANTO2AzJumMWJdHSZA3Xh1NTQcboWerkMu2
	aXr+TJZMGseXVz4M0NJWQUmSkGnlUD1UHN6Zb1D3+JRYS5ufAD8edD30gGPH7ab/SSOV
	ANAQ==
Received: by 10.216.216.226 with SMTP id g76mr3529027wep.221.1339779920280;
	Fri, 15 Jun 2012 10:05:20 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:19 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6c32fcbbd4896a55b73e3da99f84187884f61e64
Message-Id: <6c32fcbbd4896a55b73e.1339779869@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:29 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
	GCREALLOC_ARRAY 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

Causing a build failure when trying to use it:

xxx: error: expected ';' before ')' token
xxx: error: expected statement before ')' token

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
 #define GCREALLOC_ARRAY(var, nmemb)                                     \
     (assert(nmemb > 0),                                                 \
      assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
-     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
 
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17: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 1SfZxd-0004vo-U7; Fri, 15 Jun 2012 17:05:25 +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 1SfZxc-0004vc-PU
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:24 +0000
Received: from [85.158.138.51:61749] by server-10.bemta-3.messagelabs.com id
	63/0F-01753-F4B6BDF4; Fri, 15 Jun 2012 17:05:19 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339779918!27951887!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26984 invoked from network); 15 Jun 2012 17:05:18 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:18 -0000
Received: by werf3 with SMTP id f3so2750411wer.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=KI33SO7TxmuvgECQPqZ59rJamm/jT9M684mi+GVq2QY=;
	b=WboVDOL7nzQ5nkDi9WY125LuPP5HVRTAu4J3ZgckdYRUYPBqw2WskYPlYvras8n5YR
	ZfeEMeBMVN2/RkBhnjQMgYKpduDON5RLVh129j7HVumdhVEoDvSPY5F3E/QS7I24jnYj
	tjSBQlRFBpWYQkneTlxU/OeMvTk5/qhuPvFaeK3yfUVkofymo/yQkAqGP0noRVy1uFE+
	X/bwgEap9YE396mP/i3ZE6RDuGJpGkrjieUQGlumiC0709s12UrIxZcVxmnnO3RSNkbR
	n/5cUYrKAnRwjbCBvCqbDHG463QzGDd3EAHzPkH+7BMmsGnWdL0nEB50Ovmjb8/BdY83
	0cpQ==
Received: by 10.180.91.225 with SMTP id ch1mr5957578wib.18.1339779918004;
	Fri, 15 Jun 2012 10:05:18 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:16 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:28 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 00 of 10 v2] Automatic NUMA placement for xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Everyone,

This is the second take for automaic NUMA placement for Xen 4.2, for the sake
of feature parity with xm/xend.

All the comments v1 received have been addressed. Actually, some bits of the
patchset have been deeply restructured for achieving this. Details in single
changelogs.

Here it is what the series ships:

 1/10 libxl: fix a typo in the GCREALLOC_ARRAY macro

Is just a build fix (already posted separately).

 2/10 libxl: add a new Array type to the IDL
 3/10 libxl,libxc: introduce libxl_get_numainfo()
 4/10 xl: add more NUMA information to `xl info -n'
 5/10 libxl: rename libxl_cpumap to libxl_bitmap
 6/10 libxl: expand the libxl_bitmap API a bit
 7/10 libxl: introduce some node map helpers
 
Introduce the data structures, calls and infrastructure needed for retrieving
all the information about the NUMA-ness of the system and deal with them at the
toolstack level.

 8/10 libxl: enable automatic placement of guests on NUMA nodes
 9/10 libxl: have NUMA placement deal with cpupools

Is the actual, well, 'food' (no, I'm not calling it 'the meat' as I'm
vegetarian!  :-D).

 10/10 Some automatic NUMA placement documentation

Puts some more details about the implementation and the usage of the new
feature directly in the tree.

Thanks a lot and Regards,
Dario

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17: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 1SfZxf-0004w4-A0; Fri, 15 Jun 2012 17:05:27 +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 1SfZxd-0004vn-Oa
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:26 +0000
Received: from [85.158.143.99:45528] by server-3.bemta-4.messagelabs.com id
	66/91-05808-55B6BDF4; Fri, 15 Jun 2012 17:05:25 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779923!22329884!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21195 invoked from network); 15 Jun 2012 17:05:23 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:23 -0000
Received: by wgbed3 with SMTP id ed3so2260470wgb.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=F7ZfcVyWbb3/NDPvXsza7r5jLP2ORIEWJhOQmqGK2tE=;
	b=iRQxaLNWikNK4H7selUtIIjCR4PDLC1tiKlhq2vLn9dBtt73C/f/yL+jjY1kQGwULU
	bsHEKTqNZ3OPSz9zPz4fodcDu6wNwzYo4EI8ziXSWkJVFu1ILHTHbihZ1+OrCxzu6iRJ
	3i6ZWSl57L2D8+reM8f/4vTSGh9vzMWYZg7lia3+8H+Ho+BwSXFaX09Q3fOav6LIamBK
	gFrflvTyFDLrnJ3evhY4EqJfWTqtY9fvnDhm5Bft4LuKGrUpwEe+SM20cCF5zkoD4dhp
	vrUGd34A7ux+j7IL3R0TIlNrvmokROw0UtQculBZ3GsnuVIGmVXPSY/QM/zNF4VEGDWg
	3Omw==
Received: by 10.180.98.201 with SMTP id ek9mr6008415wib.7.1339779923107;
	Fri, 15 Jun 2012 10:05:23 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:21 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f53f6fe171fc975ff8409e33f929c63c57764494
Message-Id: <f53f6fe171fc975ff840.1339779870@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:30 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02 of 10 v2] libxl: add a new Array type to the
	IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And make all the required infrastructure updates to enable this.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -27,6 +27,18 @@ def gen_rand_init(ty, v, indent = "    "
     s = ""
     if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "%s = rand()%%8;\n" % (parent + ty.lenvar.name)
+        s += "%s = calloc(%s, sizeof(*%s));\n" % \
+            (v, parent + ty.lenvar.name, v)
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += gen_rand_init(ty.elem_type, v+"[i]",
+                           indent + "        ", parent)
+        s += "}\n"
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -11,8 +11,12 @@ def libxl_C_instance_of(ty, instancename
             return libxl_C_type_define(ty)
         else:
             return libxl_C_type_define(ty) + " " + instancename
-    else:
-        return ty.typename + " " + instancename
+
+    s = ""
+    if isinstance(ty, idl.Array):
+        s += libxl_C_instance_of(ty.lenvar.type, ty.lenvar.name) + ";\n"
+
+    return s + ty.typename + " " + instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
@@ -66,6 +70,21 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        if ty.elem_type.dispose_fn is not None:
+            s += "{\n"
+            s += "    int i;\n"
+            s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+            s += libxl_C_type_dispose(ty.elem_type, v+"[i]",
+                                      indent + "        ", parent)
+        if ty.dispose_fn is not None:
+            if ty.elem_type.dispose_fn is not None:
+                s += "    "
+            s += "%s(%s);\n" % (ty.dispose_fn, ty.pass_arg(v, parent is None))
+        if ty.elem_type.dispose_fn is not None:
+            s += "}\n"
     elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -164,7 +183,24 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, idl.Enumeration):
+
+    if isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    s = yajl_gen_array_open(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "    for (i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_gen_json(ty.elem_type, v+"[i]",
+                                   indent + "        ", parent)
+        s += "    }\n"
+        s += "    s = yajl_gen_array_close(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
diff --git a/tools/libxl/idl.py b/tools/libxl/idl.py
--- a/tools/libxl/idl.py
+++ b/tools/libxl/idl.py
@@ -266,6 +266,17 @@ string = Builtin("char *", namespace = N
                  json_fn = "libxl__string_gen_json",
                  autogenerate_json = False)
 
+class Array(Type):
+    """An array of the same type"""
+    def __init__(self, elem_type, lenvar_name, **kwargs):
+        kwargs.setdefault('dispose_fn', 'free')
+        Type.__init__(self, namespace=elem_type.namespace, typename=elem_type.rawname + " *", **kwargs)
+
+        lv_kwargs = dict([(x.lstrip('lenvar_'),y) for (x,y) in kwargs.items() if x.startswith('lenvar_')])
+
+        self.lenvar = Field(integer, lenvar_name, **lv_kwargs)
+        self.elem_type = elem_type
+
 class OrderedDict(dict):
     """A dictionary which remembers insertion order.
 
diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
--- a/tools/libxl/idl.txt
+++ b/tools/libxl/idl.txt
@@ -145,12 +145,24 @@ idl.KeyedUnion
 
  A subclass of idl.Aggregate which represents the C union type
  where the currently valid member of the union can be determined based
- upon another member in the containing type.
+ upon another member in the containing type. An idl.KeyedUnion must
+ always be a member of a containing idl.Aggregate type.
 
- The KeyedUnion.keyvar contains an idl.type the member of the
+ The KeyedUnion.keyvar contains an idl.Type the member of the
  containing type which determines the valid member of the union. The
  must be an instance of the Enumeration type.
 
+idl.Array
+
+  A class representing an array or similar elements. An idl.Array must
+  always be an idl.Field of a containing idl.Aggregate.
+
+  idl.Array.elem_type contains an idl.Type which is the type of all
+  elements of the array.
+
+  idl.Array.len_var contains an idl.Field which is added to the parent
+  idl.Aggregate and will contain the length of the array.
+
 Standard Types
 --------------
 
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -55,7 +55,8 @@ def ocaml_type_of(ty):
             return "int%d" % ty.width
         else:
             return "int"
-
+    elif isinstance(ty,idl.Array):
+        return "%s list" % ocaml_type_of(ty.elem_type)
     elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -4,7 +4,7 @@ import sys,os
 
 import idl
 
-(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_ARRAY, TYPE_AGGREGATE) = range(7)
 
 def py_type(ty):
     if ty == idl.bool:
@@ -18,6 +18,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, idl.Array):
+        return TYPE_ARRAY
     if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
     if ty == idl.string:
@@ -74,7 +76,7 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
         l.append('    return NULL;')
     else:
@@ -105,7 +107,7 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
         l.append('    return -1;')
     else:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17: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 1SfZxf-0004w4-A0; Fri, 15 Jun 2012 17:05:27 +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 1SfZxd-0004vn-Oa
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:26 +0000
Received: from [85.158.143.99:45528] by server-3.bemta-4.messagelabs.com id
	66/91-05808-55B6BDF4; Fri, 15 Jun 2012 17:05:25 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779923!22329884!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21195 invoked from network); 15 Jun 2012 17:05:23 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:23 -0000
Received: by wgbed3 with SMTP id ed3so2260470wgb.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=F7ZfcVyWbb3/NDPvXsza7r5jLP2ORIEWJhOQmqGK2tE=;
	b=iRQxaLNWikNK4H7selUtIIjCR4PDLC1tiKlhq2vLn9dBtt73C/f/yL+jjY1kQGwULU
	bsHEKTqNZ3OPSz9zPz4fodcDu6wNwzYo4EI8ziXSWkJVFu1ILHTHbihZ1+OrCxzu6iRJ
	3i6ZWSl57L2D8+reM8f/4vTSGh9vzMWYZg7lia3+8H+Ho+BwSXFaX09Q3fOav6LIamBK
	gFrflvTyFDLrnJ3evhY4EqJfWTqtY9fvnDhm5Bft4LuKGrUpwEe+SM20cCF5zkoD4dhp
	vrUGd34A7ux+j7IL3R0TIlNrvmokROw0UtQculBZ3GsnuVIGmVXPSY/QM/zNF4VEGDWg
	3Omw==
Received: by 10.180.98.201 with SMTP id ek9mr6008415wib.7.1339779923107;
	Fri, 15 Jun 2012 10:05:23 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:21 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f53f6fe171fc975ff8409e33f929c63c57764494
Message-Id: <f53f6fe171fc975ff840.1339779870@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:30 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02 of 10 v2] libxl: add a new Array type to the
	IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And make all the required infrastructure updates to enable this.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -27,6 +27,18 @@ def gen_rand_init(ty, v, indent = "    "
     s = ""
     if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "%s = rand()%%8;\n" % (parent + ty.lenvar.name)
+        s += "%s = calloc(%s, sizeof(*%s));\n" % \
+            (v, parent + ty.lenvar.name, v)
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += gen_rand_init(ty.elem_type, v+"[i]",
+                           indent + "        ", parent)
+        s += "}\n"
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -11,8 +11,12 @@ def libxl_C_instance_of(ty, instancename
             return libxl_C_type_define(ty)
         else:
             return libxl_C_type_define(ty) + " " + instancename
-    else:
-        return ty.typename + " " + instancename
+
+    s = ""
+    if isinstance(ty, idl.Array):
+        s += libxl_C_instance_of(ty.lenvar.type, ty.lenvar.name) + ";\n"
+
+    return s + ty.typename + " " + instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
@@ -66,6 +70,21 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        if ty.elem_type.dispose_fn is not None:
+            s += "{\n"
+            s += "    int i;\n"
+            s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+            s += libxl_C_type_dispose(ty.elem_type, v+"[i]",
+                                      indent + "        ", parent)
+        if ty.dispose_fn is not None:
+            if ty.elem_type.dispose_fn is not None:
+                s += "    "
+            s += "%s(%s);\n" % (ty.dispose_fn, ty.pass_arg(v, parent is None))
+        if ty.elem_type.dispose_fn is not None:
+            s += "}\n"
     elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -164,7 +183,24 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, idl.Enumeration):
+
+    if isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    s = yajl_gen_array_open(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "    for (i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_gen_json(ty.elem_type, v+"[i]",
+                                   indent + "        ", parent)
+        s += "    }\n"
+        s += "    s = yajl_gen_array_close(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
diff --git a/tools/libxl/idl.py b/tools/libxl/idl.py
--- a/tools/libxl/idl.py
+++ b/tools/libxl/idl.py
@@ -266,6 +266,17 @@ string = Builtin("char *", namespace = N
                  json_fn = "libxl__string_gen_json",
                  autogenerate_json = False)
 
+class Array(Type):
+    """An array of the same type"""
+    def __init__(self, elem_type, lenvar_name, **kwargs):
+        kwargs.setdefault('dispose_fn', 'free')
+        Type.__init__(self, namespace=elem_type.namespace, typename=elem_type.rawname + " *", **kwargs)
+
+        lv_kwargs = dict([(x.lstrip('lenvar_'),y) for (x,y) in kwargs.items() if x.startswith('lenvar_')])
+
+        self.lenvar = Field(integer, lenvar_name, **lv_kwargs)
+        self.elem_type = elem_type
+
 class OrderedDict(dict):
     """A dictionary which remembers insertion order.
 
diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
--- a/tools/libxl/idl.txt
+++ b/tools/libxl/idl.txt
@@ -145,12 +145,24 @@ idl.KeyedUnion
 
  A subclass of idl.Aggregate which represents the C union type
  where the currently valid member of the union can be determined based
- upon another member in the containing type.
+ upon another member in the containing type. An idl.KeyedUnion must
+ always be a member of a containing idl.Aggregate type.
 
- The KeyedUnion.keyvar contains an idl.type the member of the
+ The KeyedUnion.keyvar contains an idl.Type the member of the
  containing type which determines the valid member of the union. The
  must be an instance of the Enumeration type.
 
+idl.Array
+
+  A class representing an array or similar elements. An idl.Array must
+  always be an idl.Field of a containing idl.Aggregate.
+
+  idl.Array.elem_type contains an idl.Type which is the type of all
+  elements of the array.
+
+  idl.Array.len_var contains an idl.Field which is added to the parent
+  idl.Aggregate and will contain the length of the array.
+
 Standard Types
 --------------
 
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -55,7 +55,8 @@ def ocaml_type_of(ty):
             return "int%d" % ty.width
         else:
             return "int"
-
+    elif isinstance(ty,idl.Array):
+        return "%s list" % ocaml_type_of(ty.elem_type)
     elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -4,7 +4,7 @@ import sys,os
 
 import idl
 
-(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_ARRAY, TYPE_AGGREGATE) = range(7)
 
 def py_type(ty):
     if ty == idl.bool:
@@ -18,6 +18,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, idl.Array):
+        return TYPE_ARRAY
     if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
     if ty == idl.string:
@@ -74,7 +76,7 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
         l.append('    return NULL;')
     else:
@@ -105,7 +107,7 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
         l.append('    return -1;')
     else:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxl-0004xU-84; Fri, 15 Jun 2012 17:05:33 +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 1SfZxk-0004wt-21
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:32 +0000
Received: from [85.158.139.83:19732] by server-9.bemta-5.messagelabs.com id
	DD/30-01069-B5B6BDF4; Fri, 15 Jun 2012 17:05:31 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!3
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28020 invoked from network); 15 Jun 2012 17:05:30 -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;
	15 Jun 2012 17:05:30 -0000
Received: by mail-wi0-f173.google.com with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=PnZMeRxuTU1kCiJ/D6003/FZj0ZSqcQrf7J4XBSUaUw=;
	b=VTfIxuCWfRkbl9n35n7gwyyUp1Dwd4a6ZQ4Ha4tGz/RyBXsnwjnqL/74TEovmfMNHu
	XvUmPTBDAzG8fPhSMxtrD8p0Q9vrMvHCg+3c/RQAPi/v6D7uShk7rYbJx3EaYFvI+DNw
	zrCHtwdOg8mSydB8kgo/aD3hk3gSO6pRYghKator5cEU76E5tr9fqvVJhK31x1ScwniG
	k5PD+wV1rB1vy34HwuHYA/DIrKTSuERM3Pyr8nFQTOIYV2sqIeuVo/XVXHjvs78k8b5g
	qWmmBNtQVOhZjhb2kVX6nRXbBB8r57tuG4HKUn2E43mBjFpP4SxR/y+WL9AF4VmrMDpK
	XXiA==
Received: by 10.216.134.145 with SMTP id s17mr3551820wei.22.1339779927755;
	Fri, 15 Jun 2012 10:05:27 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:26 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 0e64330fdbfdd74a6ddffd35dc613ed8a8cb1b86
Message-Id: <0e64330fdbfdd74a6ddf.1339779872@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:32 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04 of 10 v2] xl: add more NUMA information to
	`xl info -n'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 that the user knows how much memory there is on each node and
how far they are from each others.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * integer division replaced by right shift.

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
@@ -4254,6 +4254,36 @@ static void output_physinfo(void)
     return;
 }
 
+static void output_numainfo(void)
+{
+    libxl_numainfo *info;
+    int i, j, nr;
+
+    info = libxl_get_numainfo(ctx, &nr);
+    if (info == NULL) {
+        fprintf(stderr, "libxl_get_numainfo failed.\n");
+        return;
+    }
+
+    printf("numa_info              :\n");
+    printf("node:    memsize    memfree    distances\n");
+
+    for (i = 0; i < nr; i++) {
+        if (info[i].size != LIBXL_NUMAINFO_INVALID_ENTRY) {
+            printf("%4d:    %6"PRIu64"     %6"PRIu64"      %d", i,
+                   info[i].size >> 20, info[i].free >> 20,
+                   info[i].dists[0]);
+            for (j = 1; j < info[i].num_dists; j++)
+                printf(",%d", info[i].dists[j]);
+            printf("\n");
+        }
+    }
+
+    libxl_numainfo_list_free(info, nr);
+
+    return;
+}
+
 static void output_topologyinfo(void)
 {
     libxl_cputopology *info;
@@ -4276,8 +4306,6 @@ static void output_topologyinfo(void)
 
     libxl_cputopology_list_free(info, nr);
 
-    printf("numa_info              : none\n");
-
     return;
 }
 
@@ -4287,8 +4315,10 @@ static void info(int numa)
 
     output_physinfo();
 
-    if (numa)
+    if (numa) {
         output_topologyinfo();
+        output_numainfo();
+    }
 
     output_xeninfo();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxl-0004xU-84; Fri, 15 Jun 2012 17:05:33 +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 1SfZxk-0004wt-21
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:32 +0000
Received: from [85.158.139.83:19732] by server-9.bemta-5.messagelabs.com id
	DD/30-01069-B5B6BDF4; Fri, 15 Jun 2012 17:05:31 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!3
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28020 invoked from network); 15 Jun 2012 17:05:30 -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;
	15 Jun 2012 17:05:30 -0000
Received: by mail-wi0-f173.google.com with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=PnZMeRxuTU1kCiJ/D6003/FZj0ZSqcQrf7J4XBSUaUw=;
	b=VTfIxuCWfRkbl9n35n7gwyyUp1Dwd4a6ZQ4Ha4tGz/RyBXsnwjnqL/74TEovmfMNHu
	XvUmPTBDAzG8fPhSMxtrD8p0Q9vrMvHCg+3c/RQAPi/v6D7uShk7rYbJx3EaYFvI+DNw
	zrCHtwdOg8mSydB8kgo/aD3hk3gSO6pRYghKator5cEU76E5tr9fqvVJhK31x1ScwniG
	k5PD+wV1rB1vy34HwuHYA/DIrKTSuERM3Pyr8nFQTOIYV2sqIeuVo/XVXHjvs78k8b5g
	qWmmBNtQVOhZjhb2kVX6nRXbBB8r57tuG4HKUn2E43mBjFpP4SxR/y+WL9AF4VmrMDpK
	XXiA==
Received: by 10.216.134.145 with SMTP id s17mr3551820wei.22.1339779927755;
	Fri, 15 Jun 2012 10:05:27 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:26 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 0e64330fdbfdd74a6ddffd35dc613ed8a8cb1b86
Message-Id: <0e64330fdbfdd74a6ddf.1339779872@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:32 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04 of 10 v2] xl: add more NUMA information to
	`xl info -n'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 that the user knows how much memory there is on each node and
how far they are from each others.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * integer division replaced by right shift.

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
@@ -4254,6 +4254,36 @@ static void output_physinfo(void)
     return;
 }
 
+static void output_numainfo(void)
+{
+    libxl_numainfo *info;
+    int i, j, nr;
+
+    info = libxl_get_numainfo(ctx, &nr);
+    if (info == NULL) {
+        fprintf(stderr, "libxl_get_numainfo failed.\n");
+        return;
+    }
+
+    printf("numa_info              :\n");
+    printf("node:    memsize    memfree    distances\n");
+
+    for (i = 0; i < nr; i++) {
+        if (info[i].size != LIBXL_NUMAINFO_INVALID_ENTRY) {
+            printf("%4d:    %6"PRIu64"     %6"PRIu64"      %d", i,
+                   info[i].size >> 20, info[i].free >> 20,
+                   info[i].dists[0]);
+            for (j = 1; j < info[i].num_dists; j++)
+                printf(",%d", info[i].dists[j]);
+            printf("\n");
+        }
+    }
+
+    libxl_numainfo_list_free(info, nr);
+
+    return;
+}
+
 static void output_topologyinfo(void)
 {
     libxl_cputopology *info;
@@ -4276,8 +4306,6 @@ static void output_topologyinfo(void)
 
     libxl_cputopology_list_free(info, nr);
 
-    printf("numa_info              : none\n");
-
     return;
 }
 
@@ -4287,8 +4315,10 @@ static void info(int numa)
 
     output_physinfo();
 
-    if (numa)
+    if (numa) {
         output_topologyinfo();
+        output_numainfo();
+    }
 
     output_xeninfo();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxk-0004xA-Md; Fri, 15 Jun 2012 17:05:32 +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 1SfZxi-0004wS-C1
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:30 +0000
Received: from [85.158.139.83:19633] by server-1.bemta-5.messagelabs.com id
	59/1A-19721-95B6BDF4; Fri, 15 Jun 2012 17:05:29 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27933 invoked from network); 15 Jun 2012 17:05:28 -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;
	15 Jun 2012 17:05:28 -0000
Received: by mail-wi0-f173.google.com with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=vkBO31wdSrxmTBwpAEsG0PgyHmFuxRCGkPCuNvpHC94=;
	b=jgYUjbGHVLe6OIRuW3ZDMz/XfX4Wx1Ec2/rrDPe6lLQUuzRrKxHBOzm6lfDNnxqZ3l
	QQB6DxYpd1biD3kLnKYxi/oW9WtWy00JIompZInk1BWMB74B0kJEi2UR8PwZYQ2sJRtx
	//yTnLTgyH6KpFotCLec1QvZkn8WlscWIW9pSQGL8TAxrbvL8a7J59GGbsA3vkRrayJL
	NGynaVxz694aBqlIMVB+Ho2IzLWD1RvxPcGDNHTSSDx1KxgG9t2hJpj1B0pAgdtlF05q
	aU2t+p5d9zlcGfO5d5lSe2G444sjTp2jgLnO2aUBgZobRZZ29yzwSbBZuPG1TjVYWYgC
	m+Ng==
Received: by 10.216.198.65 with SMTP id u43mr3754750wen.170.1339779925506;
	Fri, 15 Jun 2012 10:05:25 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:24 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 16222d05875389899968ac8c75a954e3c2ac8e27
Message-Id: <16222d05875389899968.1339779871@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:31 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make some NUMA node information available to the toolstack. Achieve
this by means of xc_numainfo(), which exposes memory size and amount
of free memory of each node, as well as the relative distances of
each node to all the others.

For properly exposing distances we need the IDL to support arrays.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * malloc converted to libxl__zalloc(NOGC, ...).
 * The patch also accommodates some bits of what was in "libxc,
   libxl: introduce xc_nodemap_t and libxl_nodemap" which was
   removed as well, as full support for node maps at libxc
   level is not needed (yet!).

diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -35,6 +35,20 @@ int xc_get_max_cpus(xc_interface *xch)
     return max_cpus;
 }
 
+int xc_get_max_nodes(xc_interface *xch)
+{
+    static int max_nodes = 0;
+    xc_physinfo_t physinfo;
+
+    if ( max_nodes )
+        return max_nodes;
+
+    if ( !xc_physinfo(xch, &physinfo) )
+        max_nodes = physinfo.max_node_id + 1;
+
+    return max_nodes;
+}
+
 int xc_get_cpumap_size(xc_interface *xch)
 {
     return (xc_get_max_cpus(xch) + 7) / 8;
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -329,6 +329,12 @@ int xc_get_cpumap_size(xc_interface *xch
 /* allocate a cpumap */
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
 
+ /*
+ * NODEMAP handling
+ */
+/* return maximum number of NUMA nodes the hypervisor supports */
+int xc_get_max_nodes(xc_interface *xch);
+
 /*
  * DOMAIN DEBUGGING FUNCTIONS
  */
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3223,6 +3223,71 @@ fail:
     return ret;
 }
 
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
+{
+    xc_numainfo_t ninfo;
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memsize_t, memsize);
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memfree_t, memfree);
+    DECLARE_HYPERCALL_BUFFER(uint32_t, node_dists);
+    libxl_numainfo *ret = NULL;
+    int i, j, max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of NODES");
+        return NULL;
+    }
+
+    memsize = xc_hypercall_buffer_alloc
+        (ctx->xch, memsize, sizeof(*memsize) * max_nodes);
+    memfree = xc_hypercall_buffer_alloc
+        (ctx->xch, memfree, sizeof(*memfree) * max_nodes);
+    node_dists = xc_hypercall_buffer_alloc
+        (ctx->xch, node_dists, sizeof(*node_dists) * max_nodes * max_nodes);
+    if ((memsize == NULL) || (memfree == NULL) || (node_dists == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
+        goto fail;
+    }
+
+    set_xen_guest_handle(ninfo.node_to_memsize, memsize);
+    set_xen_guest_handle(ninfo.node_to_memfree, memfree);
+    set_xen_guest_handle(ninfo.node_to_node_distance, node_dists);
+    ninfo.max_node_index = max_nodes - 1;
+    if (xc_numainfo(ctx->xch, &ninfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting numainfo");
+        goto fail;
+    }
+
+    if (ninfo.max_node_index < max_nodes - 1)
+        max_nodes = ninfo.max_node_index + 1;
+
+    ret = libxl__zalloc(NOGC, sizeof(libxl_numainfo) * max_nodes);
+    for (i = 0; i < max_nodes; i++)
+        ret[i].dists = libxl__zalloc(NULL, sizeof(*node_dists) * max_nodes);
+
+    for (i = 0; i < max_nodes; i++) {
+#define V(mem, i) (mem[i] == INVALID_NUMAINFO_ID) ? \
+    LIBXL_NUMAINFO_INVALID_ENTRY : mem[i]
+        ret[i].size = V(memsize, i);
+        ret[i].free = V(memfree, i);
+        ret[i].num_dists = max_nodes;
+        for (j = 0; j < ret[i].num_dists; j++)
+            ret[i].dists[j] = V(node_dists, i * max_nodes + j);
+#undef V
+    }
+
+fail:
+    xc_hypercall_buffer_free(ctx->xch, memsize);
+    xc_hypercall_buffer_free(ctx->xch, memfree);
+    xc_hypercall_buffer_free(ctx->xch, node_dists);
+
+    if (ret)
+        *nr = max_nodes;
+    return ret;
+}
+
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
 {
     union {
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -532,6 +532,9 @@ int libxl_domain_preserve(libxl_ctx *ctx
 /* get max. number of cpus supported by hypervisor */
 int libxl_get_max_cpus(libxl_ctx *ctx);
 
+/* get max. number of NUMA nodes supported by hypervisor */
+int libxl_get_max_nodes(libxl_ctx *ctx);
+
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
 
@@ -769,6 +772,13 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
 #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
 void libxl_cputopology_list_free(libxl_cputopology *, int nr);
+#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
+  /* On success, a list of nr libxl_numainfo elements is returned.
+   * That is from malloc, thus it is up to the caller to invoke
+   * libxl_cpupoolinfo_list_free() on it.
+   */
+void libxl_numainfo_list_free(libxl_numainfo *, int nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
 void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -423,6 +423,12 @@ libxl_physinfo = Struct("physinfo", [
     ("cap_hvm_directio", bool),
     ], dir=DIR_OUT)
 
+libxl_numainfo = Struct("numainfo", [
+    ("size", uint64),
+    ("free", uint64),
+    ("dists", Array(uint32, "num_dists")),
+    ], dir=DIR_OUT)
+
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
     ("socket", uint32),
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
     return xc_get_max_cpus(ctx->xch);
 }
 
+int libxl_get_max_nodes(libxl_ctx *ctx)
+{
+    return xc_get_max_nodes(ctx->xch);
+}
+
 int libxl__enum_from_string(const libxl_enum_string_table *t,
                             const char *s, int *e)
 {
@@ -551,6 +556,14 @@ int libxl__enum_from_string(const libxl_
     return ERROR_FAIL;
 }
 
+void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_numainfo_dispose(&list[i]);
+    free(list);
+}
+
 void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
 {
     int i;
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
@@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
 
 /* XEN_SYSCTL_numainfo */
+#define INVALID_NUMAINFO_ID (~0U)
 struct xen_sysctl_numainfo {
     /*
      * IN: maximum addressable entry in the caller-provided arrays.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxk-0004xA-Md; Fri, 15 Jun 2012 17:05:32 +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 1SfZxi-0004wS-C1
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:30 +0000
Received: from [85.158.139.83:19633] by server-1.bemta-5.messagelabs.com id
	59/1A-19721-95B6BDF4; Fri, 15 Jun 2012 17:05:29 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27933 invoked from network); 15 Jun 2012 17:05:28 -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;
	15 Jun 2012 17:05:28 -0000
Received: by mail-wi0-f173.google.com with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=vkBO31wdSrxmTBwpAEsG0PgyHmFuxRCGkPCuNvpHC94=;
	b=jgYUjbGHVLe6OIRuW3ZDMz/XfX4Wx1Ec2/rrDPe6lLQUuzRrKxHBOzm6lfDNnxqZ3l
	QQB6DxYpd1biD3kLnKYxi/oW9WtWy00JIompZInk1BWMB74B0kJEi2UR8PwZYQ2sJRtx
	//yTnLTgyH6KpFotCLec1QvZkn8WlscWIW9pSQGL8TAxrbvL8a7J59GGbsA3vkRrayJL
	NGynaVxz694aBqlIMVB+Ho2IzLWD1RvxPcGDNHTSSDx1KxgG9t2hJpj1B0pAgdtlF05q
	aU2t+p5d9zlcGfO5d5lSe2G444sjTp2jgLnO2aUBgZobRZZ29yzwSbBZuPG1TjVYWYgC
	m+Ng==
Received: by 10.216.198.65 with SMTP id u43mr3754750wen.170.1339779925506;
	Fri, 15 Jun 2012 10:05:25 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:24 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 16222d05875389899968ac8c75a954e3c2ac8e27
Message-Id: <16222d05875389899968.1339779871@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:31 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make some NUMA node information available to the toolstack. Achieve
this by means of xc_numainfo(), which exposes memory size and amount
of free memory of each node, as well as the relative distances of
each node to all the others.

For properly exposing distances we need the IDL to support arrays.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * malloc converted to libxl__zalloc(NOGC, ...).
 * The patch also accommodates some bits of what was in "libxc,
   libxl: introduce xc_nodemap_t and libxl_nodemap" which was
   removed as well, as full support for node maps at libxc
   level is not needed (yet!).

diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -35,6 +35,20 @@ int xc_get_max_cpus(xc_interface *xch)
     return max_cpus;
 }
 
+int xc_get_max_nodes(xc_interface *xch)
+{
+    static int max_nodes = 0;
+    xc_physinfo_t physinfo;
+
+    if ( max_nodes )
+        return max_nodes;
+
+    if ( !xc_physinfo(xch, &physinfo) )
+        max_nodes = physinfo.max_node_id + 1;
+
+    return max_nodes;
+}
+
 int xc_get_cpumap_size(xc_interface *xch)
 {
     return (xc_get_max_cpus(xch) + 7) / 8;
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -329,6 +329,12 @@ int xc_get_cpumap_size(xc_interface *xch
 /* allocate a cpumap */
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
 
+ /*
+ * NODEMAP handling
+ */
+/* return maximum number of NUMA nodes the hypervisor supports */
+int xc_get_max_nodes(xc_interface *xch);
+
 /*
  * DOMAIN DEBUGGING FUNCTIONS
  */
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3223,6 +3223,71 @@ fail:
     return ret;
 }
 
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
+{
+    xc_numainfo_t ninfo;
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memsize_t, memsize);
+    DECLARE_HYPERCALL_BUFFER(xc_node_to_memfree_t, memfree);
+    DECLARE_HYPERCALL_BUFFER(uint32_t, node_dists);
+    libxl_numainfo *ret = NULL;
+    int i, j, max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of NODES");
+        return NULL;
+    }
+
+    memsize = xc_hypercall_buffer_alloc
+        (ctx->xch, memsize, sizeof(*memsize) * max_nodes);
+    memfree = xc_hypercall_buffer_alloc
+        (ctx->xch, memfree, sizeof(*memfree) * max_nodes);
+    node_dists = xc_hypercall_buffer_alloc
+        (ctx->xch, node_dists, sizeof(*node_dists) * max_nodes * max_nodes);
+    if ((memsize == NULL) || (memfree == NULL) || (node_dists == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
+        goto fail;
+    }
+
+    set_xen_guest_handle(ninfo.node_to_memsize, memsize);
+    set_xen_guest_handle(ninfo.node_to_memfree, memfree);
+    set_xen_guest_handle(ninfo.node_to_node_distance, node_dists);
+    ninfo.max_node_index = max_nodes - 1;
+    if (xc_numainfo(ctx->xch, &ninfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting numainfo");
+        goto fail;
+    }
+
+    if (ninfo.max_node_index < max_nodes - 1)
+        max_nodes = ninfo.max_node_index + 1;
+
+    ret = libxl__zalloc(NOGC, sizeof(libxl_numainfo) * max_nodes);
+    for (i = 0; i < max_nodes; i++)
+        ret[i].dists = libxl__zalloc(NULL, sizeof(*node_dists) * max_nodes);
+
+    for (i = 0; i < max_nodes; i++) {
+#define V(mem, i) (mem[i] == INVALID_NUMAINFO_ID) ? \
+    LIBXL_NUMAINFO_INVALID_ENTRY : mem[i]
+        ret[i].size = V(memsize, i);
+        ret[i].free = V(memfree, i);
+        ret[i].num_dists = max_nodes;
+        for (j = 0; j < ret[i].num_dists; j++)
+            ret[i].dists[j] = V(node_dists, i * max_nodes + j);
+#undef V
+    }
+
+fail:
+    xc_hypercall_buffer_free(ctx->xch, memsize);
+    xc_hypercall_buffer_free(ctx->xch, memfree);
+    xc_hypercall_buffer_free(ctx->xch, node_dists);
+
+    if (ret)
+        *nr = max_nodes;
+    return ret;
+}
+
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
 {
     union {
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -532,6 +532,9 @@ int libxl_domain_preserve(libxl_ctx *ctx
 /* get max. number of cpus supported by hypervisor */
 int libxl_get_max_cpus(libxl_ctx *ctx);
 
+/* get max. number of NUMA nodes supported by hypervisor */
+int libxl_get_max_nodes(libxl_ctx *ctx);
+
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
 
@@ -769,6 +772,13 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
 #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
 void libxl_cputopology_list_free(libxl_cputopology *, int nr);
+#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
+libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
+  /* On success, a list of nr libxl_numainfo elements is returned.
+   * That is from malloc, thus it is up to the caller to invoke
+   * libxl_cpupoolinfo_list_free() on it.
+   */
+void libxl_numainfo_list_free(libxl_numainfo *, int nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
 void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -423,6 +423,12 @@ libxl_physinfo = Struct("physinfo", [
     ("cap_hvm_directio", bool),
     ], dir=DIR_OUT)
 
+libxl_numainfo = Struct("numainfo", [
+    ("size", uint64),
+    ("free", uint64),
+    ("dists", Array(uint32, "num_dists")),
+    ], dir=DIR_OUT)
+
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
     ("socket", uint32),
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
     return xc_get_max_cpus(ctx->xch);
 }
 
+int libxl_get_max_nodes(libxl_ctx *ctx)
+{
+    return xc_get_max_nodes(ctx->xch);
+}
+
 int libxl__enum_from_string(const libxl_enum_string_table *t,
                             const char *s, int *e)
 {
@@ -551,6 +556,14 @@ int libxl__enum_from_string(const libxl_
     return ERROR_FAIL;
 }
 
+void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_numainfo_dispose(&list[i]);
+    free(list);
+}
+
 void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
 {
     int i;
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
@@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
 
 /* XEN_SYSCTL_numainfo */
+#define INVALID_NUMAINFO_ID (~0U)
 struct xen_sysctl_numainfo {
     /*
      * IN: maximum addressable entry in the caller-provided arrays.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxr-0004zG-FI; Fri, 15 Jun 2012 17:05:39 +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 1SfZxp-0004yP-Nv
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:38 +0000
Received: from [85.158.138.51:19437] by server-2.bemta-3.messagelabs.com id
	44/37-31533-C5B6BDF4; Fri, 15 Jun 2012 17:05:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339779918!27951887!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27363 invoked from network); 15 Jun 2012 17:05:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:30 -0000
Received: by mail-we0-f173.google.com with SMTP id f3so2750411wer.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=ih8CEpvF0zbY2q0rcnmZs6rSQqDfhAo/0moXncwBg6A=;
	b=anyWiy83v9giHB97MJvFc2OrnBxDtF1hI7jM0iaI3tm+lbGoZnevudbQYkOehsJdml
	xgoE0TtOMJoNNHWFhPATnnQOB8DP53Ao5yRECz84LH76634VsT+ahrwrXoGykYVkiLVk
	6UcQZFU8lMEWK1IdcTbRR1ChVVOSI6xG3UMUhccAvWH5cntR1ASyIAH8EO3rkfryf9XZ
	0v1mShGeqtj6vr3n5QVe5174G/XuXbQIsMxGbl1oK6/DDFeRw+Pnxzg4tsh2kqY0GHGu
	YVHyvRPkBDMTcip911qc9QS40SvqnuZQHPMRnaaErGUG+ASUn3TLi5/o+zl9kFhxRp/s
	+Ixg==
Received: by 10.180.83.168 with SMTP id r8mr5949463wiy.22.1339779930621;
	Fri, 15 Jun 2012 10:05:30 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:29 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5d3cbf2e6370d1989bcd69645c44ba10670bb819
Message-Id: <5d3cbf2e6370d1989bcd.1339779873@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:33 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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

And leave to the caller the burden of knowing and remembering what kind
of bitmap each instance of libxl_bitmap is.

This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some other
related interface name substitution, e.g., libxl_for_each_cpu) in a bunch
of files, with no real functional change involved.

A specific allocation helper is introduced, besides libxl_bitmap_alloc().
It is called libxl_cpu_bitmap_alloc() and is meant at substituting the old
libxl_cpumap_alloc(). It is just something easier to use in cases where one
wants to allocate a libxl_bitmap that is going to serve as a cpu map.

This is because we want to be able to deal with both cpu and NUMA node
maps, but we don't want to duplicate all the various helpers and wrappers.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>

Changes from v1:
 * this patch replaces "libxl: abstract libxl_cpumap to just libxl_map"
   as it directly change the name of the old type instead of adding one
   more abstraction layer.

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -20,7 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_bitmap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_string_list"]
 
 def gen_rand_init(ty, v, indent = "    ", parent = None):
@@ -117,16 +117,16 @@ static void rand_bytes(uint8_t *p, size_
         p[i] = rand() % 256;
 }
 
-static void libxl_cpumap_rand_init(libxl_cpumap *cpumap)
+static void libxl_bitmap_rand_init(libxl_bitmap *bitmap)
 {
     int i;
-    cpumap->size = rand() % 16;
-    cpumap->map = calloc(cpumap->size, sizeof(*cpumap->map));
-    libxl_for_each_cpu(i, *cpumap) {
+    bitmap->size = rand() % 16;
+    bitmap->map = calloc(bitmap->size, sizeof(*bitmap->map));
+    libxl_for_each_bit(i, *bitmap) {
         if (rand() % 2)
-            libxl_cpumap_set(cpumap, i);
+            libxl_bitmap_set(bitmap, i);
         else
-            libxl_cpumap_reset(cpumap, i);
+            libxl_bitmap_reset(bitmap, i);
     }
 }
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -570,7 +570,7 @@ static int cpupool_info(libxl__gc *gc,
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap))
+    if (libxl_cpu_bitmap_alloc(CTX, &info->cpumap))
         goto out;
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
 
@@ -3352,7 +3352,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
     }
 
     for (*nb_vcpu = 0; *nb_vcpu <= domaininfo.max_vcpu_id; ++*nb_vcpu, ++ptr) {
-        if (libxl_cpumap_alloc(ctx, &ptr->cpumap)) {
+        if (libxl_cpu_bitmap_alloc(ctx, &ptr->cpumap)) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpumap");
             return NULL;
         }
@@ -3375,7 +3375,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
 }
 
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
-                           libxl_cpumap *cpumap)
+                           libxl_bitmap *cpumap)
 {
     if (xc_vcpu_setaffinity(ctx->xch, domid, vcpuid, cpumap->map)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting vcpu affinity");
@@ -3385,7 +3385,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
 }
 
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
-                               unsigned int max_vcpus, libxl_cpumap *cpumap)
+                               unsigned int max_vcpus, libxl_bitmap *cpumap)
 {
     int i, rc = 0;
 
@@ -3399,7 +3399,7 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
     return rc;
 }
 
-int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
+int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap)
 {
     GC_INIT(ctx);
     libxl_dominfo info;
@@ -3419,7 +3419,7 @@ retry_transaction:
     for (i = 0; i <= info.vcpu_max_id; i++)
         libxl__xs_write(gc, t,
                        libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
-                       "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
+                       "%s", libxl_bitmap_test(cpumap, i) ? "online" : "offline");
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;
@@ -4015,7 +4015,7 @@ int libxl_tmem_freeable(libxl_ctx *ctx)
     return rc;
 }
 
-int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap)
 {
     int ncpus;
 
@@ -4034,7 +4034,7 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
 
 int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
                          libxl_scheduler sched,
-                         libxl_cpumap cpumap, libxl_uuid *uuid,
+                         libxl_bitmap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
     GC_INIT(ctx);
@@ -4057,8 +4057,8 @@ int libxl_cpupool_create(libxl_ctx *ctx,
         return ERROR_FAIL;
     }
 
-    libxl_for_each_cpu(i, cpumap)
-        if (libxl_cpumap_test(&cpumap, i)) {
+    libxl_for_each_bit(i, cpumap)
+        if (libxl_bitmap_test(&cpumap, i)) {
             rc = xc_cpupool_addcpu(ctx->xch, *poolid, i);
             if (rc) {
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
@@ -4093,7 +4093,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     int rc, i;
     xc_cpupoolinfo_t *info;
     xs_transaction_t t;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
@@ -4106,12 +4106,12 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
         goto out;
 
     rc = ERROR_NOMEM;
-    if (libxl_cpumap_alloc(ctx, &cpumap))
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap))
         goto out;
 
     memcpy(cpumap.map, info->cpumap, cpumap.size);
-    libxl_for_each_cpu(i, cpumap)
-        if (libxl_cpumap_test(&cpumap, i)) {
+    libxl_for_each_bit(i, cpumap)
+        if (libxl_bitmap_test(&cpumap, i)) {
             rc = xc_cpupool_removecpu(ctx->xch, poolid, i);
             if (rc) {
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
@@ -4140,7 +4140,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     rc = 0;
 
 out1:
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
 out:
     xc_cpupool_infofree(ctx->xch, info);
     GC_FREE;
@@ -4208,7 +4208,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx 
 {
     int rc = 0;
     int cpu, nr;
-    libxl_cpumap freemap;
+    libxl_bitmap freemap;
     libxl_cputopology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
@@ -4223,7 +4223,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx 
 
     *cpus = 0;
     for (cpu = 0; cpu < nr; cpu++) {
-        if (libxl_cpumap_test(&freemap, cpu) && (topology[cpu].node == node) &&
+        if (libxl_bitmap_test(&freemap, cpu) && (topology[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
@@ -4232,7 +4232,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx 
 
     free(topology);
 out:
-    libxl_cpumap_dispose(&freemap);
+    libxl_bitmap_dispose(&freemap);
     return rc;
 }
 
@@ -4274,7 +4274,7 @@ int libxl_cpupool_cpuremove_node(libxl_c
         if (poolinfo[p].poolid == poolid) {
             for (cpu = 0; cpu < nr_cpus; cpu++) {
                 if ((topology[cpu].node == node) &&
-                    libxl_cpumap_test(&poolinfo[p].cpumap, cpu) &&
+                    libxl_bitmap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
                 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -285,8 +285,8 @@ typedef uint64_t libxl_ev_user;
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
-} libxl_cpumap;
-void libxl_cpumap_dispose(libxl_cpumap *map);
+} libxl_bitmap;
+void libxl_bitmap_dispose(libxl_bitmap *map);
 
 /* libxl_cpuid_policy_list is a dynamic array storing CPUID policies
  * for multiple leafs. It is terminated with an entry holding
@@ -783,10 +783,10 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
                                        int *nb_vcpu, int *nrcpus);
 void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
-                           libxl_cpumap *cpumap);
+                           libxl_bitmap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
-                               unsigned int max_vcpus, libxl_cpumap *cpumap);
-int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
+                               unsigned int max_vcpus, libxl_bitmap *cpumap);
+int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap);
 
 libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
 
@@ -836,10 +836,10 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
                            int auth);
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
-int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
+int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
 int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
                          libxl_scheduler sched,
-                         libxl_cpumap cpumap, libxl_uuid *uuid,
+                         libxl_bitmap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
 int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid);
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
@@ -150,9 +150,9 @@ int libxl__domain_build_info_setdefault(
         b_info->cur_vcpus = 1;
 
     if (!b_info->cpumap.size) {
-        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
+        if (libxl_cpu_bitmap_alloc(CTX, &b_info->cpumap))
             return ERROR_NOMEM;
-        libxl_cpumap_set_any(&b_info->cpumap);
+        libxl_bitmap_set_any(&b_info->cpumap);
     }
 
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -99,8 +99,8 @@ yajl_gen_status libxl_uuid_gen_json(yajl
     return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUID_FMTLEN);
 }
 
-yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand,
-                                      libxl_cpumap *cpumap)
+yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
+                                      libxl_bitmap *cpumap)
 {
     yajl_gen_status s;
     int i;
@@ -108,8 +108,8 @@ yajl_gen_status libxl_cpumap_gen_json(ya
     s = yajl_gen_array_open(hand);
     if (s != yajl_gen_status_ok) goto out;
 
-    libxl_for_each_cpu(i, *cpumap) {
-        if (libxl_cpumap_test(cpumap, i)) {
+    libxl_for_each_bit(i, *cpumap) {
+        if (libxl_bitmap_test(cpumap, i)) {
             s = yajl_gen_integer(hand, i);
             if (s != yajl_gen_status_ok) goto out;
         }
diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -26,7 +26,7 @@ yajl_gen_status libxl_defbool_gen_json(y
 yajl_gen_status libxl_domid_gen_json(yajl_gen hand, libxl_domid *p);
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
 yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
-yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, libxl_bitmap *p);
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                                  libxl_cpuid_policy_list *p);
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -10,7 +10,7 @@ libxl_defbool = Builtin("defbool", passb
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
-libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
+libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE)
 libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
 
 libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
@@ -188,7 +188,7 @@ libxl_cpupoolinfo = Struct("cpupoolinfo"
     ("poolid",      uint32),
     ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
-    ("cpumap",      libxl_cpumap)
+    ("cpumap",      libxl_bitmap)
     ], dir=DIR_OUT)
 
 libxl_vminfo = Struct("vminfo", [
@@ -238,7 +238,7 @@ libxl_domain_sched_params = Struct("doma
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("cpumap",          libxl_cpumap),
+    ("cpumap",          libxl_bitmap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
@@ -399,7 +399,7 @@ libxl_vcpuinfo = Struct("vcpuinfo", [
     ("blocked", bool),
     ("running", bool),
     ("vcpu_time", uint64), # total vcpu time ran (ns)
-    ("cpumap", libxl_cpumap), # current cpu's affinities
+    ("cpumap", libxl_bitmap), # current cpu's affinities
     ], dir=DIR_OUT)
 
 libxl_physinfo = Struct("physinfo", [
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -489,47 +489,42 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }
 
-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits)
 {
-    int max_cpus;
     int sz;
 
-    max_cpus = libxl_get_max_cpus(ctx);
-    if (max_cpus == 0)
-        return ERROR_FAIL;
-
-    sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
+    sz = (n_bits + 7) / 8;
+    bitmap->map = calloc(sz, sizeof(*bitmap->map));
+    if (!bitmap->map)
         return ERROR_NOMEM;
-    cpumap->size = sz;
+    bitmap->size = sz;
     return 0;
 }
 
-void libxl_cpumap_dispose(libxl_cpumap *map)
+void libxl_bitmap_dispose(libxl_bitmap *map)
 {
     free(map->map);
 }
 
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
+int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit)
 {
-    if (cpu >= cpumap->size * 8)
+    if (bit >= bitmap->size * 8)
         return 0;
-    return (cpumap->map[cpu / 8] & (1 << (cpu & 7))) ? 1 : 0;
+    return (bitmap->map[bit / 8] & (1 << (bit & 7))) ? 1 : 0;
 }
 
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu)
+void libxl_bitmap_set(libxl_bitmap *bitmap, int bit)
 {
-    if (cpu >= cpumap->size * 8)
+    if (bit >= bitmap->size * 8)
         return;
-    cpumap->map[cpu / 8] |= 1 << (cpu & 7);
+    bitmap->map[bit / 8] |= 1 << (bit & 7);
 }
 
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu)
+void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit)
 {
-    if (cpu >= cpumap->size * 8)
+    if (bit >= bitmap->size * 8)
         return;
-    cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
+    bitmap->map[bit / 8] &= ~(1 << (bit & 7));
 }
 
 int libxl_get_max_cpus(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -63,25 +63,38 @@ int libxl_devid_to_device_nic(libxl_ctx 
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
-static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
+int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits);
+    /* Allocated bimap is from malloc, libxl_bitmap_dispose() to be
+     * called by the application when done. */
+int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
+void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
+void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);
+static inline void libxl_bitmap_set_any(libxl_bitmap *bitmap)
 {
-    memset(cpumap->map, -1, cpumap->size);
+    memset(bitmap->map, -1, bitmap->size);
 }
-static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
+static inline void libxl_bitmap_set_none(libxl_bitmap *bitmap)
 {
-    memset(cpumap->map, 0, cpumap->size);
+    memset(bitmap->map, 0, bitmap->size);
 }
-static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
+static inline int libxl_bitmap_cpu_valid(const libxl_bitmap *bitmap, int bit)
 {
-    return cpu >= 0 && cpu < (cpumap->size * 8);
+    return bit >= 0 && bit < (bitmap->size * 8);
 }
-#define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
-#define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \
-                                             if (libxl_cpumap_test(&(m), v))
+#define libxl_for_each_bit(var, map) for (var = 0; var < (map).size * 8; var++)
+#define libxl_for_each_set_bit(v, m) for (v = 0; v < (m).size * 8; v++) \
+                                             if (libxl_bitmap_test(&(m), v))
+
+static inline int libxl_cpu_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *cpumap)
+{
+    int max_cpus;
+
+    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus == 0)
+        return ERROR_FAIL;
+
+    return libxl_bitmap_alloc(ctx, cpumap, max_cpus);
+}
 
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
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
@@ -491,19 +491,19 @@ static void split_string_into_string_lis
     free(s);
 }
 
-static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
-{
-    libxl_cpumap exclude_cpumap;
+static int vcpupin_parse(char *cpu, libxl_bitmap *cpumap)
+{
+    libxl_bitmap exclude_cpumap;
     uint32_t cpuida, cpuidb;
     char *endptr, *toka, *tokb, *saveptr = NULL;
     int i, rc = 0, rmcpu;
 
     if (!strcmp(cpu, "all")) {
-        libxl_cpumap_set_any(cpumap);
+        libxl_bitmap_set_any(cpumap);
         return 0;
     }
 
-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &exclude_cpumap)) {
         fprintf(stderr, "Error: Failed to allocate cpumap.\n");
         return ENOMEM;
     }
@@ -533,19 +533,19 @@ static int vcpupin_parse(char *cpu, libx
             }
         }
         while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
-                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
+                         libxl_bitmap_set(&exclude_cpumap, cpuida);
             cpuida++;
         }
     }
 
     /* Clear all the cpus from the removal list */
-    libxl_for_each_set_cpu(i, exclude_cpumap) {
-        libxl_cpumap_reset(cpumap, i);
+    libxl_for_each_set_bit(i, exclude_cpumap) {
+        libxl_bitmap_reset(cpumap, i);
     }
 
 vcpp_out:
-    libxl_cpumap_dispose(&exclude_cpumap);
+    libxl_bitmap_dispose(&exclude_cpumap);
 
     return rc;
 }
@@ -685,7 +685,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;
 
-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpu_bitmap_alloc(ctx, &b_info->cpumap)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -705,14 +705,14 @@ static void parse_config_data(const char
          * the cpumap derived from the list ensures memory is being
          * allocated on the proper nodes anyway.
          */
-        libxl_cpumap_set_none(&b_info->cpumap);
+        libxl_bitmap_set_none(&b_info->cpumap);
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
-            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
+            if (!libxl_bitmap_cpu_valid(&b_info->cpumap, i)) {
                 fprintf(stderr, "cpu %d illegal\n", i);
                 exit(1);
             }
-            libxl_cpumap_set(&b_info->cpumap, i);
+            libxl_bitmap_set(&b_info->cpumap, i);
             if (n_cpus < b_info->max_vcpus)
                 vcpu_to_pcpu[n_cpus] = i;
             n_cpus++;
@@ -721,12 +721,12 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);
 
-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpu_bitmap_alloc(ctx, &b_info->cpumap)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
 
-        libxl_cpumap_set_none(&b_info->cpumap);
+        libxl_bitmap_set_none(&b_info->cpumap);
         if (vcpupin_parse(buf2, &b_info->cpumap))
             exit(1);
         free(buf2);
@@ -1806,26 +1806,26 @@ start:
 
     /* If single vcpu to pcpu mapping was requested, honour it */
     if (vcpu_to_pcpu) {
-        libxl_cpumap vcpu_cpumap;
-
-        libxl_cpumap_alloc(ctx, &vcpu_cpumap);
+        libxl_bitmap vcpu_cpumap;
+
+        libxl_cpu_bitmap_alloc(ctx, &vcpu_cpumap);
         for (i = 0; i < d_config.b_info.max_vcpus; i++) {
 
             if (vcpu_to_pcpu[i] != -1) {
-                libxl_cpumap_set_none(&vcpu_cpumap);
-                libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]);
+                libxl_bitmap_set_none(&vcpu_cpumap);
+                libxl_bitmap_set(&vcpu_cpumap, vcpu_to_pcpu[i]);
             } else {
-                libxl_cpumap_set_any(&vcpu_cpumap);
+                libxl_bitmap_set_any(&vcpu_cpumap);
             }
             if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) {
                 fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i);
-                libxl_cpumap_dispose(&vcpu_cpumap);
+                libxl_bitmap_dispose(&vcpu_cpumap);
                 free(vcpu_to_pcpu);
                 ret = ERROR_FAIL;
                 goto error_out;
             }
         }
-        libxl_cpumap_dispose(&vcpu_cpumap);
+        libxl_bitmap_dispose(&vcpu_cpumap);
         free(vcpu_to_pcpu); vcpu_to_pcpu = NULL;
     }
 
@@ -4063,7 +4063,7 @@ int main_vcpulist(int argc, char **argv)
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
 
     uint32_t vcpuid;
     char *endptr;
@@ -4080,7 +4080,7 @@ static void vcpupin(const char *d, const
 
     find_domain(d);
 
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
 
@@ -4107,7 +4107,7 @@ static void vcpupin(const char *d, const
         libxl_vcpuinfo_list_free(vcpuinfo, nb_vcpu);
     }
   vcpupin_out1:
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
   vcpupin_out:
     ;
 }
@@ -4127,7 +4127,7 @@ static void vcpuset(const char *d, const
 {
     char *endptr;
     unsigned int max_vcpus, i;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
 
     max_vcpus = strtoul(nr_vcpus, &endptr, 10);
     if (nr_vcpus == endptr) {
@@ -4137,17 +4137,17 @@ static void vcpuset(const char *d, const
 
     find_domain(d);
 
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
-        fprintf(stderr, "libxl_cpumap_alloc failed\n");
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
+        fprintf(stderr, "libxl_cpu_bitmap_alloc failed\n");
         return;
     }
     for (i = 0; i < max_vcpus; i++)
-        libxl_cpumap_set(&cpumap, i);
+        libxl_bitmap_set(&cpumap, i);
 
     if (libxl_set_vcpuonline(ctx, domid, &cpumap) < 0)
         fprintf(stderr, "libxl_set_vcpuonline failed domid=%d max_vcpus=%d\n", domid, max_vcpus);
 
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
 }
 
 int main_vcpuset(int argc, char **argv)
@@ -4211,7 +4211,7 @@ static void output_physinfo(void)
     libxl_physinfo info;
     const libxl_version_info *vinfo;
     unsigned int i;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
     int n = 0;
 
     if (libxl_get_physinfo(ctx, &info) != 0) {
@@ -4243,8 +4243,8 @@ static void output_physinfo(void)
         printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
     }
     if (!libxl_get_freecpus(ctx, &cpumap)) {
-        libxl_for_each_cpu(i, cpumap)
-            if (libxl_cpumap_test(&cpumap, i))
+        libxl_for_each_bit(i, cpumap)
+            if (libxl_bitmap_test(&cpumap, i))
                 n++;
         printf("free_cpus              : %d\n", n);
         free(cpumap.map);
@@ -5866,8 +5866,8 @@ int main_cpupoolcreate(int argc, char **
     XLU_ConfigList *cpus;
     XLU_ConfigList *nodes;
     int n_cpus, n_nodes, i, n;
-    libxl_cpumap freemap;
-    libxl_cpumap cpumap;
+    libxl_bitmap freemap;
+    libxl_bitmap cpumap;
     libxl_uuid uuid;
     libxl_cputopology *topology;
     int rc = -ERROR_FAIL; 
@@ -5980,7 +5980,7 @@ int main_cpupoolcreate(int argc, char **
         fprintf(stderr, "libxl_get_freecpus failed\n");
         goto out_cfg;
     }
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         goto out_cfg;
     }
@@ -5997,8 +5997,8 @@ int main_cpupoolcreate(int argc, char **
             n = atoi(buf);
             for (i = 0; i < nr; i++) {
                 if ((topology[i].node == n) &&
-                    libxl_cpumap_test(&freemap, i)) {
-                    libxl_cpumap_set(&cpumap, i);
+                    libxl_bitmap_test(&freemap, i)) {
+                    libxl_bitmap_set(&cpumap, i);
                     n_cpus++;
                 }
             }
@@ -6016,11 +6016,11 @@ int main_cpupoolcreate(int argc, char **
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
             if ((i < 0) || (i >= freemap.size * 8) ||
-                !libxl_cpumap_test(&freemap, i)) {
+                !libxl_bitmap_test(&freemap, i)) {
                 fprintf(stderr, "cpu %d illegal or not free\n", i);
                 goto out_cfg;
             }
-            libxl_cpumap_set(&cpumap, i);
+            libxl_bitmap_set(&cpumap, i);
             n_cpus++;
         }
     } else
@@ -6118,8 +6118,8 @@ int main_cpupoollist(int argc, char **ar
                 printf("%-19s", name);
                 free(name);
                 n = 0;
-                libxl_for_each_cpu(c, poolinfo[p].cpumap)
-                    if (libxl_cpumap_test(&poolinfo[p].cpumap, c)) {
+                libxl_for_each_bit(c, poolinfo[p].cpumap)
+                    if (libxl_bitmap_test(&poolinfo[p].cpumap, c)) {
                         if (n && opt_cpus) printf(",");
                         if (opt_cpus) printf("%d", c);
                         n++;
@@ -6318,7 +6318,7 @@ int main_cpupoolnumasplit(int argc, char
     int n_cpus;
     char name[16];
     libxl_uuid uuid;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
     libxl_cpupoolinfo *poolinfo;
     libxl_cputopology *topology;
     libxl_dominfo info;
@@ -6348,7 +6348,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }
 
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;
@@ -6374,7 +6374,7 @@ int main_cpupoolnumasplit(int argc, char
     for (c = 0; c < n_cpus; c++) {
         if (topology[c].node == node) {
             topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
-            libxl_cpumap_set(&cpumap, n);
+            libxl_bitmap_set(&cpumap, n);
             n++;
         }
     }
@@ -6396,7 +6396,7 @@ int main_cpupoolnumasplit(int argc, char
         fprintf(stderr, "failed to offline vcpus\n");
         goto out;
     }
-    libxl_cpumap_set_none(&cpumap);
+    libxl_bitmap_set_none(&cpumap);
 
     for (c = 0; c < n_cpus; c++) {
         if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
@@ -6434,7 +6434,7 @@ int main_cpupoolnumasplit(int argc, char
 
 out:
     libxl_cputopology_list_free(topology, n_cpus);
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
 
     return ret;
 }
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -231,14 +231,14 @@ int attrib__libxl_cpuid_policy_list_set(
     return -1;
 }
 
-int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr)
+int attrib__libxl_bitmap_set(PyObject *v, libxl_bitmap *pptr)
 {
     int i;
     long cpu;
 
     for (i = 0; i < PyList_Size(v); i++) {
         cpu = PyInt_AsLong(PyList_GetItem(v, i));
-        libxl_cpumap_set(pptr, cpu);
+        libxl_bitmap_set(pptr, cpu);
     }
     return 0;
 }
@@ -293,14 +293,14 @@ PyObject *attrib__libxl_cpuid_policy_lis
     return NULL;
 }
 
-PyObject *attrib__libxl_cpumap_get(libxl_cpumap *pptr)
+PyObject *attrib__libxl_bitmap_get(libxl_bitmap *pptr)
 {
     PyObject *cpulist = NULL;
     int i;
 
     cpulist = PyList_New(0);
-    libxl_for_each_cpu(i, *pptr) {
-        if ( libxl_cpumap_test(pptr, i) ) {
+    libxl_for_each_bit(i, *pptr) {
+        if ( libxl_bitmap_test(pptr, i) ) {
             PyObject* pyint = PyInt_FromLong(i);
 
             PyList_Append(cpulist, pyint);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxr-0004zG-FI; Fri, 15 Jun 2012 17:05:39 +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 1SfZxp-0004yP-Nv
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:38 +0000
Received: from [85.158.138.51:19437] by server-2.bemta-3.messagelabs.com id
	44/37-31533-C5B6BDF4; Fri, 15 Jun 2012 17:05:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339779918!27951887!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27363 invoked from network); 15 Jun 2012 17:05:30 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:30 -0000
Received: by mail-we0-f173.google.com with SMTP id f3so2750411wer.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=ih8CEpvF0zbY2q0rcnmZs6rSQqDfhAo/0moXncwBg6A=;
	b=anyWiy83v9giHB97MJvFc2OrnBxDtF1hI7jM0iaI3tm+lbGoZnevudbQYkOehsJdml
	xgoE0TtOMJoNNHWFhPATnnQOB8DP53Ao5yRECz84LH76634VsT+ahrwrXoGykYVkiLVk
	6UcQZFU8lMEWK1IdcTbRR1ChVVOSI6xG3UMUhccAvWH5cntR1ASyIAH8EO3rkfryf9XZ
	0v1mShGeqtj6vr3n5QVe5174G/XuXbQIsMxGbl1oK6/DDFeRw+Pnxzg4tsh2kqY0GHGu
	YVHyvRPkBDMTcip911qc9QS40SvqnuZQHPMRnaaErGUG+ASUn3TLi5/o+zl9kFhxRp/s
	+Ixg==
Received: by 10.180.83.168 with SMTP id r8mr5949463wiy.22.1339779930621;
	Fri, 15 Jun 2012 10:05:30 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:29 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5d3cbf2e6370d1989bcd69645c44ba10670bb819
Message-Id: <5d3cbf2e6370d1989bcd.1339779873@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:33 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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

And leave to the caller the burden of knowing and remembering what kind
of bitmap each instance of libxl_bitmap is.

This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some other
related interface name substitution, e.g., libxl_for_each_cpu) in a bunch
of files, with no real functional change involved.

A specific allocation helper is introduced, besides libxl_bitmap_alloc().
It is called libxl_cpu_bitmap_alloc() and is meant at substituting the old
libxl_cpumap_alloc(). It is just something easier to use in cases where one
wants to allocate a libxl_bitmap that is going to serve as a cpu map.

This is because we want to be able to deal with both cpu and NUMA node
maps, but we don't want to duplicate all the various helpers and wrappers.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>

Changes from v1:
 * this patch replaces "libxl: abstract libxl_cpumap to just libxl_map"
   as it directly change the name of the old type instead of adding one
   more abstraction layer.

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -20,7 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_bitmap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_string_list"]
 
 def gen_rand_init(ty, v, indent = "    ", parent = None):
@@ -117,16 +117,16 @@ static void rand_bytes(uint8_t *p, size_
         p[i] = rand() % 256;
 }
 
-static void libxl_cpumap_rand_init(libxl_cpumap *cpumap)
+static void libxl_bitmap_rand_init(libxl_bitmap *bitmap)
 {
     int i;
-    cpumap->size = rand() % 16;
-    cpumap->map = calloc(cpumap->size, sizeof(*cpumap->map));
-    libxl_for_each_cpu(i, *cpumap) {
+    bitmap->size = rand() % 16;
+    bitmap->map = calloc(bitmap->size, sizeof(*bitmap->map));
+    libxl_for_each_bit(i, *bitmap) {
         if (rand() % 2)
-            libxl_cpumap_set(cpumap, i);
+            libxl_bitmap_set(bitmap, i);
         else
-            libxl_cpumap_reset(cpumap, i);
+            libxl_bitmap_reset(bitmap, i);
     }
 }
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -570,7 +570,7 @@ static int cpupool_info(libxl__gc *gc,
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap))
+    if (libxl_cpu_bitmap_alloc(CTX, &info->cpumap))
         goto out;
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
 
@@ -3352,7 +3352,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
     }
 
     for (*nb_vcpu = 0; *nb_vcpu <= domaininfo.max_vcpu_id; ++*nb_vcpu, ++ptr) {
-        if (libxl_cpumap_alloc(ctx, &ptr->cpumap)) {
+        if (libxl_cpu_bitmap_alloc(ctx, &ptr->cpumap)) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpumap");
             return NULL;
         }
@@ -3375,7 +3375,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
 }
 
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
-                           libxl_cpumap *cpumap)
+                           libxl_bitmap *cpumap)
 {
     if (xc_vcpu_setaffinity(ctx->xch, domid, vcpuid, cpumap->map)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting vcpu affinity");
@@ -3385,7 +3385,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
 }
 
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
-                               unsigned int max_vcpus, libxl_cpumap *cpumap)
+                               unsigned int max_vcpus, libxl_bitmap *cpumap)
 {
     int i, rc = 0;
 
@@ -3399,7 +3399,7 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
     return rc;
 }
 
-int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
+int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap)
 {
     GC_INIT(ctx);
     libxl_dominfo info;
@@ -3419,7 +3419,7 @@ retry_transaction:
     for (i = 0; i <= info.vcpu_max_id; i++)
         libxl__xs_write(gc, t,
                        libxl__sprintf(gc, "%s/cpu/%u/availability", dompath, i),
-                       "%s", libxl_cpumap_test(cpumap, i) ? "online" : "offline");
+                       "%s", libxl_bitmap_test(cpumap, i) ? "online" : "offline");
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;
@@ -4015,7 +4015,7 @@ int libxl_tmem_freeable(libxl_ctx *ctx)
     return rc;
 }
 
-int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap)
 {
     int ncpus;
 
@@ -4034,7 +4034,7 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
 
 int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
                          libxl_scheduler sched,
-                         libxl_cpumap cpumap, libxl_uuid *uuid,
+                         libxl_bitmap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
     GC_INIT(ctx);
@@ -4057,8 +4057,8 @@ int libxl_cpupool_create(libxl_ctx *ctx,
         return ERROR_FAIL;
     }
 
-    libxl_for_each_cpu(i, cpumap)
-        if (libxl_cpumap_test(&cpumap, i)) {
+    libxl_for_each_bit(i, cpumap)
+        if (libxl_bitmap_test(&cpumap, i)) {
             rc = xc_cpupool_addcpu(ctx->xch, *poolid, i);
             if (rc) {
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
@@ -4093,7 +4093,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     int rc, i;
     xc_cpupoolinfo_t *info;
     xs_transaction_t t;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
 
     info = xc_cpupool_getinfo(ctx->xch, poolid);
     if (info == NULL) {
@@ -4106,12 +4106,12 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
         goto out;
 
     rc = ERROR_NOMEM;
-    if (libxl_cpumap_alloc(ctx, &cpumap))
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap))
         goto out;
 
     memcpy(cpumap.map, info->cpumap, cpumap.size);
-    libxl_for_each_cpu(i, cpumap)
-        if (libxl_cpumap_test(&cpumap, i)) {
+    libxl_for_each_bit(i, cpumap)
+        if (libxl_bitmap_test(&cpumap, i)) {
             rc = xc_cpupool_removecpu(ctx->xch, poolid, i);
             if (rc) {
                 LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
@@ -4140,7 +4140,7 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     rc = 0;
 
 out1:
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
 out:
     xc_cpupool_infofree(ctx->xch, info);
     GC_FREE;
@@ -4208,7 +4208,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx 
 {
     int rc = 0;
     int cpu, nr;
-    libxl_cpumap freemap;
+    libxl_bitmap freemap;
     libxl_cputopology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
@@ -4223,7 +4223,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx 
 
     *cpus = 0;
     for (cpu = 0; cpu < nr; cpu++) {
-        if (libxl_cpumap_test(&freemap, cpu) && (topology[cpu].node == node) &&
+        if (libxl_bitmap_test(&freemap, cpu) && (topology[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
@@ -4232,7 +4232,7 @@ int libxl_cpupool_cpuadd_node(libxl_ctx 
 
     free(topology);
 out:
-    libxl_cpumap_dispose(&freemap);
+    libxl_bitmap_dispose(&freemap);
     return rc;
 }
 
@@ -4274,7 +4274,7 @@ int libxl_cpupool_cpuremove_node(libxl_c
         if (poolinfo[p].poolid == poolid) {
             for (cpu = 0; cpu < nr_cpus; cpu++) {
                 if ((topology[cpu].node == node) &&
-                    libxl_cpumap_test(&poolinfo[p].cpumap, cpu) &&
+                    libxl_bitmap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
                 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -285,8 +285,8 @@ typedef uint64_t libxl_ev_user;
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
-} libxl_cpumap;
-void libxl_cpumap_dispose(libxl_cpumap *map);
+} libxl_bitmap;
+void libxl_bitmap_dispose(libxl_bitmap *map);
 
 /* libxl_cpuid_policy_list is a dynamic array storing CPUID policies
  * for multiple leafs. It is terminated with an entry holding
@@ -783,10 +783,10 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
                                        int *nb_vcpu, int *nrcpus);
 void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
-                           libxl_cpumap *cpumap);
+                           libxl_bitmap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
-                               unsigned int max_vcpus, libxl_cpumap *cpumap);
-int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
+                               unsigned int max_vcpus, libxl_bitmap *cpumap);
+int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap);
 
 libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
 
@@ -836,10 +836,10 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
                            int auth);
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
-int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
+int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
 int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
                          libxl_scheduler sched,
-                         libxl_cpumap cpumap, libxl_uuid *uuid,
+                         libxl_bitmap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
 int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid);
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
@@ -150,9 +150,9 @@ int libxl__domain_build_info_setdefault(
         b_info->cur_vcpus = 1;
 
     if (!b_info->cpumap.size) {
-        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
+        if (libxl_cpu_bitmap_alloc(CTX, &b_info->cpumap))
             return ERROR_NOMEM;
-        libxl_cpumap_set_any(&b_info->cpumap);
+        libxl_bitmap_set_any(&b_info->cpumap);
     }
 
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -99,8 +99,8 @@ yajl_gen_status libxl_uuid_gen_json(yajl
     return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUID_FMTLEN);
 }
 
-yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand,
-                                      libxl_cpumap *cpumap)
+yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
+                                      libxl_bitmap *cpumap)
 {
     yajl_gen_status s;
     int i;
@@ -108,8 +108,8 @@ yajl_gen_status libxl_cpumap_gen_json(ya
     s = yajl_gen_array_open(hand);
     if (s != yajl_gen_status_ok) goto out;
 
-    libxl_for_each_cpu(i, *cpumap) {
-        if (libxl_cpumap_test(cpumap, i)) {
+    libxl_for_each_bit(i, *cpumap) {
+        if (libxl_bitmap_test(cpumap, i)) {
             s = yajl_gen_integer(hand, i);
             if (s != yajl_gen_status_ok) goto out;
         }
diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -26,7 +26,7 @@ yajl_gen_status libxl_defbool_gen_json(y
 yajl_gen_status libxl_domid_gen_json(yajl_gen hand, libxl_domid *p);
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
 yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
-yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, libxl_bitmap *p);
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                                  libxl_cpuid_policy_list *p);
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -10,7 +10,7 @@ libxl_defbool = Builtin("defbool", passb
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
-libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
+libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE)
 libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
 
 libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
@@ -188,7 +188,7 @@ libxl_cpupoolinfo = Struct("cpupoolinfo"
     ("poolid",      uint32),
     ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
-    ("cpumap",      libxl_cpumap)
+    ("cpumap",      libxl_bitmap)
     ], dir=DIR_OUT)
 
 libxl_vminfo = Struct("vminfo", [
@@ -238,7 +238,7 @@ libxl_domain_sched_params = Struct("doma
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("cpumap",          libxl_cpumap),
+    ("cpumap",          libxl_bitmap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
@@ -399,7 +399,7 @@ libxl_vcpuinfo = Struct("vcpuinfo", [
     ("blocked", bool),
     ("running", bool),
     ("vcpu_time", uint64), # total vcpu time ran (ns)
-    ("cpumap", libxl_cpumap), # current cpu's affinities
+    ("cpumap", libxl_bitmap), # current cpu's affinities
     ], dir=DIR_OUT)
 
 libxl_physinfo = Struct("physinfo", [
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -489,47 +489,42 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }
 
-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits)
 {
-    int max_cpus;
     int sz;
 
-    max_cpus = libxl_get_max_cpus(ctx);
-    if (max_cpus == 0)
-        return ERROR_FAIL;
-
-    sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
+    sz = (n_bits + 7) / 8;
+    bitmap->map = calloc(sz, sizeof(*bitmap->map));
+    if (!bitmap->map)
         return ERROR_NOMEM;
-    cpumap->size = sz;
+    bitmap->size = sz;
     return 0;
 }
 
-void libxl_cpumap_dispose(libxl_cpumap *map)
+void libxl_bitmap_dispose(libxl_bitmap *map)
 {
     free(map->map);
 }
 
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
+int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit)
 {
-    if (cpu >= cpumap->size * 8)
+    if (bit >= bitmap->size * 8)
         return 0;
-    return (cpumap->map[cpu / 8] & (1 << (cpu & 7))) ? 1 : 0;
+    return (bitmap->map[bit / 8] & (1 << (bit & 7))) ? 1 : 0;
 }
 
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu)
+void libxl_bitmap_set(libxl_bitmap *bitmap, int bit)
 {
-    if (cpu >= cpumap->size * 8)
+    if (bit >= bitmap->size * 8)
         return;
-    cpumap->map[cpu / 8] |= 1 << (cpu & 7);
+    bitmap->map[bit / 8] |= 1 << (bit & 7);
 }
 
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu)
+void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit)
 {
-    if (cpu >= cpumap->size * 8)
+    if (bit >= bitmap->size * 8)
         return;
-    cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
+    bitmap->map[bit / 8] &= ~(1 << (bit & 7));
 }
 
 int libxl_get_max_cpus(libxl_ctx *ctx)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -63,25 +63,38 @@ int libxl_devid_to_device_nic(libxl_ctx 
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
-void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
-static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
+int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits);
+    /* Allocated bimap is from malloc, libxl_bitmap_dispose() to be
+     * called by the application when done. */
+int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
+void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
+void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);
+static inline void libxl_bitmap_set_any(libxl_bitmap *bitmap)
 {
-    memset(cpumap->map, -1, cpumap->size);
+    memset(bitmap->map, -1, bitmap->size);
 }
-static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
+static inline void libxl_bitmap_set_none(libxl_bitmap *bitmap)
 {
-    memset(cpumap->map, 0, cpumap->size);
+    memset(bitmap->map, 0, bitmap->size);
 }
-static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
+static inline int libxl_bitmap_cpu_valid(const libxl_bitmap *bitmap, int bit)
 {
-    return cpu >= 0 && cpu < (cpumap->size * 8);
+    return bit >= 0 && bit < (bitmap->size * 8);
 }
-#define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
-#define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \
-                                             if (libxl_cpumap_test(&(m), v))
+#define libxl_for_each_bit(var, map) for (var = 0; var < (map).size * 8; var++)
+#define libxl_for_each_set_bit(v, m) for (v = 0; v < (m).size * 8; v++) \
+                                             if (libxl_bitmap_test(&(m), v))
+
+static inline int libxl_cpu_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *cpumap)
+{
+    int max_cpus;
+
+    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus == 0)
+        return ERROR_FAIL;
+
+    return libxl_bitmap_alloc(ctx, cpumap, max_cpus);
+}
 
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
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
@@ -491,19 +491,19 @@ static void split_string_into_string_lis
     free(s);
 }
 
-static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
-{
-    libxl_cpumap exclude_cpumap;
+static int vcpupin_parse(char *cpu, libxl_bitmap *cpumap)
+{
+    libxl_bitmap exclude_cpumap;
     uint32_t cpuida, cpuidb;
     char *endptr, *toka, *tokb, *saveptr = NULL;
     int i, rc = 0, rmcpu;
 
     if (!strcmp(cpu, "all")) {
-        libxl_cpumap_set_any(cpumap);
+        libxl_bitmap_set_any(cpumap);
         return 0;
     }
 
-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &exclude_cpumap)) {
         fprintf(stderr, "Error: Failed to allocate cpumap.\n");
         return ENOMEM;
     }
@@ -533,19 +533,19 @@ static int vcpupin_parse(char *cpu, libx
             }
         }
         while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
-                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
+                         libxl_bitmap_set(&exclude_cpumap, cpuida);
             cpuida++;
         }
     }
 
     /* Clear all the cpus from the removal list */
-    libxl_for_each_set_cpu(i, exclude_cpumap) {
-        libxl_cpumap_reset(cpumap, i);
+    libxl_for_each_set_bit(i, exclude_cpumap) {
+        libxl_bitmap_reset(cpumap, i);
     }
 
 vcpp_out:
-    libxl_cpumap_dispose(&exclude_cpumap);
+    libxl_bitmap_dispose(&exclude_cpumap);
 
     return rc;
 }
@@ -685,7 +685,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;
 
-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpu_bitmap_alloc(ctx, &b_info->cpumap)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -705,14 +705,14 @@ static void parse_config_data(const char
          * the cpumap derived from the list ensures memory is being
          * allocated on the proper nodes anyway.
          */
-        libxl_cpumap_set_none(&b_info->cpumap);
+        libxl_bitmap_set_none(&b_info->cpumap);
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
-            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
+            if (!libxl_bitmap_cpu_valid(&b_info->cpumap, i)) {
                 fprintf(stderr, "cpu %d illegal\n", i);
                 exit(1);
             }
-            libxl_cpumap_set(&b_info->cpumap, i);
+            libxl_bitmap_set(&b_info->cpumap, i);
             if (n_cpus < b_info->max_vcpus)
                 vcpu_to_pcpu[n_cpus] = i;
             n_cpus++;
@@ -721,12 +721,12 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);
 
-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpu_bitmap_alloc(ctx, &b_info->cpumap)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
 
-        libxl_cpumap_set_none(&b_info->cpumap);
+        libxl_bitmap_set_none(&b_info->cpumap);
         if (vcpupin_parse(buf2, &b_info->cpumap))
             exit(1);
         free(buf2);
@@ -1806,26 +1806,26 @@ start:
 
     /* If single vcpu to pcpu mapping was requested, honour it */
     if (vcpu_to_pcpu) {
-        libxl_cpumap vcpu_cpumap;
-
-        libxl_cpumap_alloc(ctx, &vcpu_cpumap);
+        libxl_bitmap vcpu_cpumap;
+
+        libxl_cpu_bitmap_alloc(ctx, &vcpu_cpumap);
         for (i = 0; i < d_config.b_info.max_vcpus; i++) {
 
             if (vcpu_to_pcpu[i] != -1) {
-                libxl_cpumap_set_none(&vcpu_cpumap);
-                libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]);
+                libxl_bitmap_set_none(&vcpu_cpumap);
+                libxl_bitmap_set(&vcpu_cpumap, vcpu_to_pcpu[i]);
             } else {
-                libxl_cpumap_set_any(&vcpu_cpumap);
+                libxl_bitmap_set_any(&vcpu_cpumap);
             }
             if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) {
                 fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i);
-                libxl_cpumap_dispose(&vcpu_cpumap);
+                libxl_bitmap_dispose(&vcpu_cpumap);
                 free(vcpu_to_pcpu);
                 ret = ERROR_FAIL;
                 goto error_out;
             }
         }
-        libxl_cpumap_dispose(&vcpu_cpumap);
+        libxl_bitmap_dispose(&vcpu_cpumap);
         free(vcpu_to_pcpu); vcpu_to_pcpu = NULL;
     }
 
@@ -4063,7 +4063,7 @@ int main_vcpulist(int argc, char **argv)
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
 
     uint32_t vcpuid;
     char *endptr;
@@ -4080,7 +4080,7 @@ static void vcpupin(const char *d, const
 
     find_domain(d);
 
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
 
@@ -4107,7 +4107,7 @@ static void vcpupin(const char *d, const
         libxl_vcpuinfo_list_free(vcpuinfo, nb_vcpu);
     }
   vcpupin_out1:
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
   vcpupin_out:
     ;
 }
@@ -4127,7 +4127,7 @@ static void vcpuset(const char *d, const
 {
     char *endptr;
     unsigned int max_vcpus, i;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
 
     max_vcpus = strtoul(nr_vcpus, &endptr, 10);
     if (nr_vcpus == endptr) {
@@ -4137,17 +4137,17 @@ static void vcpuset(const char *d, const
 
     find_domain(d);
 
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
-        fprintf(stderr, "libxl_cpumap_alloc failed\n");
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
+        fprintf(stderr, "libxl_cpu_bitmap_alloc failed\n");
         return;
     }
     for (i = 0; i < max_vcpus; i++)
-        libxl_cpumap_set(&cpumap, i);
+        libxl_bitmap_set(&cpumap, i);
 
     if (libxl_set_vcpuonline(ctx, domid, &cpumap) < 0)
         fprintf(stderr, "libxl_set_vcpuonline failed domid=%d max_vcpus=%d\n", domid, max_vcpus);
 
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
 }
 
 int main_vcpuset(int argc, char **argv)
@@ -4211,7 +4211,7 @@ static void output_physinfo(void)
     libxl_physinfo info;
     const libxl_version_info *vinfo;
     unsigned int i;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
     int n = 0;
 
     if (libxl_get_physinfo(ctx, &info) != 0) {
@@ -4243,8 +4243,8 @@ static void output_physinfo(void)
         printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
     }
     if (!libxl_get_freecpus(ctx, &cpumap)) {
-        libxl_for_each_cpu(i, cpumap)
-            if (libxl_cpumap_test(&cpumap, i))
+        libxl_for_each_bit(i, cpumap)
+            if (libxl_bitmap_test(&cpumap, i))
                 n++;
         printf("free_cpus              : %d\n", n);
         free(cpumap.map);
@@ -5866,8 +5866,8 @@ int main_cpupoolcreate(int argc, char **
     XLU_ConfigList *cpus;
     XLU_ConfigList *nodes;
     int n_cpus, n_nodes, i, n;
-    libxl_cpumap freemap;
-    libxl_cpumap cpumap;
+    libxl_bitmap freemap;
+    libxl_bitmap cpumap;
     libxl_uuid uuid;
     libxl_cputopology *topology;
     int rc = -ERROR_FAIL; 
@@ -5980,7 +5980,7 @@ int main_cpupoolcreate(int argc, char **
         fprintf(stderr, "libxl_get_freecpus failed\n");
         goto out_cfg;
     }
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         goto out_cfg;
     }
@@ -5997,8 +5997,8 @@ int main_cpupoolcreate(int argc, char **
             n = atoi(buf);
             for (i = 0; i < nr; i++) {
                 if ((topology[i].node == n) &&
-                    libxl_cpumap_test(&freemap, i)) {
-                    libxl_cpumap_set(&cpumap, i);
+                    libxl_bitmap_test(&freemap, i)) {
+                    libxl_bitmap_set(&cpumap, i);
                     n_cpus++;
                 }
             }
@@ -6016,11 +6016,11 @@ int main_cpupoolcreate(int argc, char **
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
             if ((i < 0) || (i >= freemap.size * 8) ||
-                !libxl_cpumap_test(&freemap, i)) {
+                !libxl_bitmap_test(&freemap, i)) {
                 fprintf(stderr, "cpu %d illegal or not free\n", i);
                 goto out_cfg;
             }
-            libxl_cpumap_set(&cpumap, i);
+            libxl_bitmap_set(&cpumap, i);
             n_cpus++;
         }
     } else
@@ -6118,8 +6118,8 @@ int main_cpupoollist(int argc, char **ar
                 printf("%-19s", name);
                 free(name);
                 n = 0;
-                libxl_for_each_cpu(c, poolinfo[p].cpumap)
-                    if (libxl_cpumap_test(&poolinfo[p].cpumap, c)) {
+                libxl_for_each_bit(c, poolinfo[p].cpumap)
+                    if (libxl_bitmap_test(&poolinfo[p].cpumap, c)) {
                         if (n && opt_cpus) printf(",");
                         if (opt_cpus) printf("%d", c);
                         n++;
@@ -6318,7 +6318,7 @@ int main_cpupoolnumasplit(int argc, char
     int n_cpus;
     char name[16];
     libxl_uuid uuid;
-    libxl_cpumap cpumap;
+    libxl_bitmap cpumap;
     libxl_cpupoolinfo *poolinfo;
     libxl_cputopology *topology;
     libxl_dominfo info;
@@ -6348,7 +6348,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }
 
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpu_bitmap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;
@@ -6374,7 +6374,7 @@ int main_cpupoolnumasplit(int argc, char
     for (c = 0; c < n_cpus; c++) {
         if (topology[c].node == node) {
             topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
-            libxl_cpumap_set(&cpumap, n);
+            libxl_bitmap_set(&cpumap, n);
             n++;
         }
     }
@@ -6396,7 +6396,7 @@ int main_cpupoolnumasplit(int argc, char
         fprintf(stderr, "failed to offline vcpus\n");
         goto out;
     }
-    libxl_cpumap_set_none(&cpumap);
+    libxl_bitmap_set_none(&cpumap);
 
     for (c = 0; c < n_cpus; c++) {
         if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
@@ -6434,7 +6434,7 @@ int main_cpupoolnumasplit(int argc, char
 
 out:
     libxl_cputopology_list_free(topology, n_cpus);
-    libxl_cpumap_dispose(&cpumap);
+    libxl_bitmap_dispose(&cpumap);
 
     return ret;
 }
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -231,14 +231,14 @@ int attrib__libxl_cpuid_policy_list_set(
     return -1;
 }
 
-int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr)
+int attrib__libxl_bitmap_set(PyObject *v, libxl_bitmap *pptr)
 {
     int i;
     long cpu;
 
     for (i = 0; i < PyList_Size(v); i++) {
         cpu = PyInt_AsLong(PyList_GetItem(v, i));
-        libxl_cpumap_set(pptr, cpu);
+        libxl_bitmap_set(pptr, cpu);
     }
     return 0;
 }
@@ -293,14 +293,14 @@ PyObject *attrib__libxl_cpuid_policy_lis
     return NULL;
 }
 
-PyObject *attrib__libxl_cpumap_get(libxl_cpumap *pptr)
+PyObject *attrib__libxl_bitmap_get(libxl_bitmap *pptr)
 {
     PyObject *cpulist = NULL;
     int i;
 
     cpulist = PyList_New(0);
-    libxl_for_each_cpu(i, *pptr) {
-        if ( libxl_cpumap_test(pptr, i) ) {
+    libxl_for_each_bit(i, *pptr) {
+        if ( libxl_bitmap_test(pptr, i) ) {
             PyObject* pyint = PyInt_FromLong(i);
 
             PyList_Append(cpulist, pyint);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxr-0004yw-2H; Fri, 15 Jun 2012 17:05:39 +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 1SfZxp-0004yN-H9
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:37 +0000
Received: from [85.158.139.83:61727] by server-1.bemta-5.messagelabs.com id
	E3/3A-19721-06B6BDF4; Fri, 15 Jun 2012 17:05:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339779935!16652905!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9428 invoked from network); 15 Jun 2012 17:05:35 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:35 -0000
Received: by wgbds1 with SMTP id ds1so291010wgb.2
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=C5deKJdceqTpqpX3pI46l1fDaJNVnSSr/rlt1TZxSMI=;
	b=1ImFLtD9kSP6MsAtzNH6PtZI2+OpF6/2PFLVUO+ZOpajxW+s32ATc/NcEIBaSkA+g6
	LCzoijy+cyQoFrjzbu/gL96azPxyd082+zYJES3zmAKfWF0u38/7eliD15yW9Y961VZm
	fYU3Tl6fRETyedhuHRSsVS2MlFpHAemoRVJiezLT/twl6RQsppXkCdsm7Of2imHj/fhS
	fgNOQRsgXWN1v3VJJyhoS2B3GLaokycv4J6Ok3QmiLaCuu3AhpcBX6WUeifUlKGEs5ka
	kZwSeV6pOZd/oAmOqgxImJvGI2WowFcG5M8PZmw+Cb4VNIYNfjp16++3L4FEUSU9wfji
	ulDA==
Received: by 10.180.94.4 with SMTP id cy4mr6031776wib.2.1339779935613;
	Fri, 15 Jun 2012 10:05:35 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: c5707aff782ac5248339c6288684a05f27100937
Message-Id: <c5707aff782ac5248339.1339779875@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:35 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07 of 10 v2] libxl: introduce some node map
	helpers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow for allocating a node specific libxl_bitmap (as it
is for cpu number and maps). Helper unctions to convert a node
map it its coresponding cpu map and vice versa are also
implemented.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * This patch replaces "libxl: introduce libxl_nodemap", as
   the libxl_bitmap type introduced by the previous patch is
   now used for both cpu and node maps, as requested during
   v1 review.

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -556,6 +556,50 @@ void libxl_bitmap_reset(libxl_bitmap *bi
     bitmap->map[bit / 8] &= ~(1 << (bit & 7));
 }
 
+int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
+                            const libxl_bitmap *nodemap,
+                            libxl_bitmap *cpumap)
+{
+    libxl_cputopology *tinfo = NULL;
+    int nr_cpus, i, rc = 0;
+
+    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (tinfo == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    libxl_bitmap_set_none(cpumap);
+    for (i = 0; i < nr_cpus; i++) {
+        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+            libxl_bitmap_set(cpumap, i);
+    }
+ out:
+    libxl_cputopology_list_free(tinfo, nr_cpus);
+    return rc;
+}
+
+int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
+                            const libxl_bitmap *cpumap,
+                            libxl_bitmap *nodemap)
+{
+    libxl_cputopology *tinfo = NULL;
+    int nr_cpus, i, rc = 0;
+
+    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (tinfo == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    libxl_bitmap_set_none(nodemap);
+    libxl_for_each_set_bit(i, *cpumap)
+        libxl_bitmap_set(nodemap, tinfo[i].node);
+ out:
+    libxl_cputopology_list_free(tinfo, nr_cpus);
+    return rc;
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -100,6 +100,27 @@ static inline int libxl_cpu_bitmap_alloc
     return libxl_bitmap_alloc(ctx, cpumap, max_cpus);
 }
 
+static inline int libxl_node_bitmap_alloc(libxl_ctx *ctx,
+                                          libxl_bitmap *nodemap)
+{
+    int max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+        return ERROR_FAIL;
+
+    return libxl_bitmap_alloc(ctx, nodemap, max_nodes);
+}
+
+int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
+                            const libxl_bitmap *nodemap,
+                            libxl_bitmap *cpumap);
+    /* populate cpumap with the cpus spanned by the nodes in nodemap */
+int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
+                            const libxl_bitmap *cpuemap,
+                            libxl_bitmap *nodemap);
+    /* populate nodemap with the nodes of the cpus in cpumap */
+
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxr-0004yw-2H; Fri, 15 Jun 2012 17:05:39 +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 1SfZxp-0004yN-H9
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:37 +0000
Received: from [85.158.139.83:61727] by server-1.bemta-5.messagelabs.com id
	E3/3A-19721-06B6BDF4; Fri, 15 Jun 2012 17:05:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1339779935!16652905!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9428 invoked from network); 15 Jun 2012 17:05:35 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:35 -0000
Received: by wgbds1 with SMTP id ds1so291010wgb.2
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=C5deKJdceqTpqpX3pI46l1fDaJNVnSSr/rlt1TZxSMI=;
	b=1ImFLtD9kSP6MsAtzNH6PtZI2+OpF6/2PFLVUO+ZOpajxW+s32ATc/NcEIBaSkA+g6
	LCzoijy+cyQoFrjzbu/gL96azPxyd082+zYJES3zmAKfWF0u38/7eliD15yW9Y961VZm
	fYU3Tl6fRETyedhuHRSsVS2MlFpHAemoRVJiezLT/twl6RQsppXkCdsm7Of2imHj/fhS
	fgNOQRsgXWN1v3VJJyhoS2B3GLaokycv4J6Ok3QmiLaCuu3AhpcBX6WUeifUlKGEs5ka
	kZwSeV6pOZd/oAmOqgxImJvGI2WowFcG5M8PZmw+Cb4VNIYNfjp16++3L4FEUSU9wfji
	ulDA==
Received: by 10.180.94.4 with SMTP id cy4mr6031776wib.2.1339779935613;
	Fri, 15 Jun 2012 10:05:35 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: c5707aff782ac5248339c6288684a05f27100937
Message-Id: <c5707aff782ac5248339.1339779875@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:35 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07 of 10 v2] libxl: introduce some node map
	helpers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow for allocating a node specific libxl_bitmap (as it
is for cpu number and maps). Helper unctions to convert a node
map it its coresponding cpu map and vice versa are also
implemented.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * This patch replaces "libxl: introduce libxl_nodemap", as
   the libxl_bitmap type introduced by the previous patch is
   now used for both cpu and node maps, as requested during
   v1 review.

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -556,6 +556,50 @@ void libxl_bitmap_reset(libxl_bitmap *bi
     bitmap->map[bit / 8] &= ~(1 << (bit & 7));
 }
 
+int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
+                            const libxl_bitmap *nodemap,
+                            libxl_bitmap *cpumap)
+{
+    libxl_cputopology *tinfo = NULL;
+    int nr_cpus, i, rc = 0;
+
+    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (tinfo == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    libxl_bitmap_set_none(cpumap);
+    for (i = 0; i < nr_cpus; i++) {
+        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+            libxl_bitmap_set(cpumap, i);
+    }
+ out:
+    libxl_cputopology_list_free(tinfo, nr_cpus);
+    return rc;
+}
+
+int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
+                            const libxl_bitmap *cpumap,
+                            libxl_bitmap *nodemap)
+{
+    libxl_cputopology *tinfo = NULL;
+    int nr_cpus, i, rc = 0;
+
+    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (tinfo == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    libxl_bitmap_set_none(nodemap);
+    libxl_for_each_set_bit(i, *cpumap)
+        libxl_bitmap_set(nodemap, tinfo[i].node);
+ out:
+    libxl_cputopology_list_free(tinfo, nr_cpus);
+    return rc;
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -100,6 +100,27 @@ static inline int libxl_cpu_bitmap_alloc
     return libxl_bitmap_alloc(ctx, cpumap, max_cpus);
 }
 
+static inline int libxl_node_bitmap_alloc(libxl_ctx *ctx,
+                                          libxl_bitmap *nodemap)
+{
+    int max_nodes;
+
+    max_nodes = libxl_get_max_nodes(ctx);
+    if (max_nodes == 0)
+        return ERROR_FAIL;
+
+    return libxl_bitmap_alloc(ctx, nodemap, max_nodes);
+}
+
+int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
+                            const libxl_bitmap *nodemap,
+                            libxl_bitmap *cpumap);
+    /* populate cpumap with the cpus spanned by the nodes in nodemap */
+int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
+                            const libxl_bitmap *cpuemap,
+                            libxl_bitmap *nodemap);
+    /* populate nodemap with the nodes of the cpus in cpumap */
+
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxp-0004yV-Lg; Fri, 15 Jun 2012 17:05:37 +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 1SfZxn-0004y2-QZ
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:36 +0000
Received: from [85.158.143.99:49872] by server-3.bemta-4.messagelabs.com id
	BC/B1-05808-F5B6BDF4; Fri, 15 Jun 2012 17:05:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779923!22329884!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21380 invoked from network); 15 Jun 2012 17:05:33 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:33 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2260470wgb.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=IpbtmVwv/yCCxxQhBVck5rEf2pD+SD8ekcjMGK7DbJw=;
	b=MSoz7Zldh9dAcFsWW7pLTEgqVrxh/ldETsN4W1cozgifs8R67CGfnKkdeVLXF68A8U
	5Xk9bzox764J/8Wy3cjpCo3rEOqiFx2CfL4tZwNW8956+nBRpPsHflJvW0L49WqGZMWc
	BGITNzWK9/8NleYmsOYbdgXgX1tDMqgnJEHacpVNKMWQg0pZwxUXK98Hopdqx5PwcUr8
	qY/idtwzvOhXtEjLcgomSGn+T6GP7nj3va82lvuC+FWH5kG67VOqnCuQ42Ym8IGR74IT
	buHUza5repxo70ygkQWxgBB2wrvIEfKV9skskIrL2Ox7LcFTRLtdoE7m2w2Oom3NNCKX
	I/mg==
Received: by 10.180.98.39 with SMTP id ef7mr5942376wib.21.1339779933144;
	Fri, 15 Jun 2012 10:05:33 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:31 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8ef7de2b4328e4f65982663da13820cc9209cf29
Message-Id: <8ef7de2b4328e4f65982.1339779874@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:34 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06 of 10 v2] libxl: expand the libxl_bitmap API
	a 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

By adding copying and *_is_full/*_is_empty facilities.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * now libxl_is_full/empty return 1 if true and 0 if false,
   as logic (and as requested during review).

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -506,6 +506,35 @@ void libxl_bitmap_dispose(libxl_bitmap *
     free(map->map);
 }
 
+void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
+                       const libxl_bitmap *sptr)
+{
+    int sz;
+
+    sz = dptr->size = sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
+int libxl_bitmap_is_full(const libxl_bitmap *bitmap)
+{
+    int i;
+
+    for (i = 0; i < bitmap->size; i++)
+        if (bitmap->map[i] != (uint8_t)-1)
+            return 0;
+   return 1;
+}
+
+int libxl_bitmap_is_empty(const libxl_bitmap *bitmap)
+{
+    int i;
+
+    for (i = 0; i < bitmap->size; i++)
+        if (bitmap->map[i])
+            return 0;
+    return 1;
+}
+
 int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit)
 {
     if (bit >= bitmap->size * 8)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -66,6 +66,10 @@ int libxl_vdev_to_device_disk(libxl_ctx 
 int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits);
     /* Allocated bimap is from malloc, libxl_bitmap_dispose() to be
      * called by the application when done. */
+void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
+                       const libxl_bitmap *sptr);
+int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
+int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
 int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
 void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
 void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05: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 1SfZxp-0004yV-Lg; Fri, 15 Jun 2012 17:05:37 +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 1SfZxn-0004y2-QZ
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:36 +0000
Received: from [85.158.143.99:49872] by server-3.bemta-4.messagelabs.com id
	BC/B1-05808-F5B6BDF4; Fri, 15 Jun 2012 17:05:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779923!22329884!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21380 invoked from network); 15 Jun 2012 17:05:33 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:33 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2260470wgb.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=IpbtmVwv/yCCxxQhBVck5rEf2pD+SD8ekcjMGK7DbJw=;
	b=MSoz7Zldh9dAcFsWW7pLTEgqVrxh/ldETsN4W1cozgifs8R67CGfnKkdeVLXF68A8U
	5Xk9bzox764J/8Wy3cjpCo3rEOqiFx2CfL4tZwNW8956+nBRpPsHflJvW0L49WqGZMWc
	BGITNzWK9/8NleYmsOYbdgXgX1tDMqgnJEHacpVNKMWQg0pZwxUXK98Hopdqx5PwcUr8
	qY/idtwzvOhXtEjLcgomSGn+T6GP7nj3va82lvuC+FWH5kG67VOqnCuQ42Ym8IGR74IT
	buHUza5repxo70ygkQWxgBB2wrvIEfKV9skskIrL2Ox7LcFTRLtdoE7m2w2Oom3NNCKX
	I/mg==
Received: by 10.180.98.39 with SMTP id ef7mr5942376wib.21.1339779933144;
	Fri, 15 Jun 2012 10:05:33 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:31 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 8ef7de2b4328e4f65982663da13820cc9209cf29
Message-Id: <8ef7de2b4328e4f65982.1339779874@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:34 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06 of 10 v2] libxl: expand the libxl_bitmap API
	a 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

By adding copying and *_is_full/*_is_empty facilities.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * now libxl_is_full/empty return 1 if true and 0 if false,
   as logic (and as requested during review).

diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -506,6 +506,35 @@ void libxl_bitmap_dispose(libxl_bitmap *
     free(map->map);
 }
 
+void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
+                       const libxl_bitmap *sptr)
+{
+    int sz;
+
+    sz = dptr->size = sptr->size;
+    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
+}
+
+int libxl_bitmap_is_full(const libxl_bitmap *bitmap)
+{
+    int i;
+
+    for (i = 0; i < bitmap->size; i++)
+        if (bitmap->map[i] != (uint8_t)-1)
+            return 0;
+   return 1;
+}
+
+int libxl_bitmap_is_empty(const libxl_bitmap *bitmap)
+{
+    int i;
+
+    for (i = 0; i < bitmap->size; i++)
+        if (bitmap->map[i])
+            return 0;
+    return 1;
+}
+
 int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit)
 {
     if (bit >= bitmap->size * 8)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -66,6 +66,10 @@ int libxl_vdev_to_device_disk(libxl_ctx 
 int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits);
     /* Allocated bimap is from malloc, libxl_bitmap_dispose() to be
      * called by the application when done. */
+void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
+                       const libxl_bitmap *sptr);
+int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
+int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
 int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
 void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
 void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxw-000531-Mm; Fri, 15 Jun 2012 17:05:44 +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 1SfZxv-000519-GE
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:43 +0000
Received: from [85.158.143.99:50177] by server-2.bemta-4.messagelabs.com id
	41/BA-17938-66B6BDF4; Fri, 15 Jun 2012 17:05:42 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779923!22329884!3
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21590 invoked from network); 15 Jun 2012 17:05:41 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:41 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2260470wgb.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=ZMc5RvwZxXPwPhgxihmfAYMQhQwFguKSXo8HwYloG0E=;
	b=rGiRN6C48ksX0JQc+ekbaF+T/lE0v6ksMVIlBFill77QX7xDubmLqP5n3D53CExQnL
	VotyoiEI5xPxVHOEtx4IQ8g6jf97WP3g66ENB3POK2+ibgeR8skh/nJcPND5bj1jIca/
	93w/Exckhr1XDQniROxrtD9zRvm6CPV0zyDaxpYptpdfzMF4I4HlbrPZ59DGzvRTfpD/
	jRk7zxOgLyzAl+w4ZkC2PfjuJxEkR6BDUe7VKF7IDN39Bqyx3O3ui1zX/cShWnZaoUCO
	lzS2BYz9qY9cug6Krn7XJvb+3PBEoHSMoqR2UfFo3G7b4O864enCy9MOXmNm9B/QIm0R
	N9gw==
Received: by 10.180.93.196 with SMTP id cw4mr5992275wib.11.1339779941595;
	Fri, 15 Jun 2012 10:05:41 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:40 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 93dc34fa681a1391dcf95ddf447d90f4045d5b3a
Message-Id: <93dc34fa681a1391dcf9.1339779877@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:37 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
	with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In such a way that only the cpus belonging to the cpupool of the
domain being placed are considered for the placement itself.

This happens by filtering out all the nodes in which the cpupool has
not any cpu from the placement candidates. After that -- as a cpu pooling
not necessarily happens at NUMA nodes boundaries -- we also make sure
only the actual cpus that are part of the pool are considered when
counting how much processors a placement candidate is able to provide.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
@@ -198,15 +198,27 @@ static void comb_get_nodemap(comb_iter_t
         libxl_bitmap_set(nodemap, it[i]);
 }
 
+/* Retrieve how many nodes a nodemap spans. */
+static int nodemap_to_nr_nodes(const libxl_bitmap *nodemap)
+{
+    int i, nr_nodes = 0;
+
+    libxl_for_each_set_bit(i, *nodemap)
+        nr_nodes++;
+    return nr_nodes;
+}
+
 /* Retrieve the number of cpus that the nodes that are part of the nodemap
- * span. */
+ * span and that are also set in suitable_cpumap. */
 static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
+                                 const libxl_bitmap *suitable_cpumap,
                                  const libxl_bitmap *nodemap)
 {
     int i, nodes_cpus = 0;
 
     for (i = 0; i < nr_cpus; i++) {
-        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+        if (libxl_bitmap_test(suitable_cpumap, i) &&
+            libxl_bitmap_test(nodemap, tinfo[i].node))
             nodes_cpus++;
     }
     return nodes_cpus;
@@ -311,12 +323,13 @@ static int cpus_per_node_count(libxl_cpu
 int libxl__get_numa_candidates(libxl__gc *gc,
                                uint32_t min_free_memkb, int min_cpus,
                                int min_nodes, int max_nodes,
+                               const libxl_bitmap *suitable_cpumap,
                                libxl__numa_candidate *cndts[], int *nr_cndts)
 {
     libxl__numa_candidate *new_cndts = NULL;
     libxl_cputopology *tinfo = NULL;
     libxl_numainfo *ninfo = NULL;
-    libxl_bitmap nodemap;
+    libxl_bitmap suitable_nodemap, nodemap;
     int nr_nodes, nr_cpus;
     int array_size, rc;
 
@@ -340,6 +353,15 @@ int libxl__get_numa_candidates(libxl__gc
     if (rc)
         goto out;
 
+    /* Allocate and prepare the map of the node that can be utilized for
+     * placement, basing on the map of suitable cpus. */
+    rc = libxl_node_bitmap_alloc(CTX, &suitable_nodemap);
+    if (rc)
+        goto out;
+    rc = libxl_cpumap_to_nodemap(CTX, suitable_cpumap, &suitable_nodemap);
+    if (rc)
+        goto out;
+
     /*
      * Round up and down some of the constraints. For instance, the minimum
      * number of cpus a candidate should have must at least be non-negative.
@@ -391,9 +413,14 @@ int libxl__get_numa_candidates(libxl__gc
         for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
              comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
             uint32_t nodes_free_memkb;
-            int nodes_cpus;
+            int i, nodes_cpus;
 
+            /* Get the nodemap for the combination and filter unwnted nodes */
             comb_get_nodemap(comb_iter, &nodemap, min_nodes);
+            libxl_for_each_set_bit(i, nodemap) {
+                if (!libxl_bitmap_test(&suitable_nodemap, i))
+                    libxl_bitmap_reset(&nodemap, i);
+            }
 
             /* If there is not enough memoy in this combination, skip it
              * and go generating the next one... */
@@ -402,7 +429,8 @@ int libxl__get_numa_candidates(libxl__gc
                 continue;
 
             /* And the same applies if this combination is short in cpus */
-            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
+            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, suitable_cpumap,
+                                               &nodemap);
             if (min_cpus > 0 && nodes_cpus < min_cpus)
                 continue;
 
@@ -427,12 +455,13 @@ int libxl__get_numa_candidates(libxl__gc
             new_cndts[*nr_cndts].nr_domains =
                                     nodemap_to_nr_domains(gc, tinfo, &nodemap);
             new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
-            new_cndts[*nr_cndts].nr_nodes = min_nodes;
+            new_cndts[*nr_cndts].nr_nodes = nodemap_to_nr_nodes(&nodemap);
             new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
 
             LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
                        "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
-                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
+                       new_cndts[*nr_cndts].nr_nodes,
+                       new_cndts[*nr_cndts].nr_cpus,
                        new_cndts[*nr_cndts].free_memkb / 1024);
 
             (*nr_cndts)++;
@@ -442,6 +471,7 @@ int libxl__get_numa_candidates(libxl__gc
 
     *cndts = new_cndts;
  out:
+    libxl_bitmap_dispose(&suitable_nodemap);
     libxl_bitmap_dispose(&nodemap);
     libxl_cputopology_list_free(tinfo, nr_cpus);
     libxl_numainfo_list_free(ninfo, nr_nodes);
@@ -485,23 +515,27 @@ static int numa_cmpf(const void *v1, con
 }
 
 /* The actual automatic NUMA placement routine */
-static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
+static int numa_place_domain(libxl__gc *gc, uint32_t domid,
+                             libxl_domain_build_info *info)
 {
     int nr_candidates = 0;
     libxl__numa_candidate *candidates = NULL;
     libxl_bitmap candidate_nodemap;
-    libxl_cpupoolinfo *pinfo;
-    int nr_pools, rc = 0;
+    libxl_cpupoolinfo cpupool_info;
+    int i, cpupool, rc = 0;
     uint32_t memkb;
 
-    /* First of all, if cpupools are in use, better not to mess with them */
-    pinfo = libxl_list_cpupool(CTX, &nr_pools);
-    if (!pinfo)
-        return ERROR_FAIL;
-    if (nr_pools > 1) {
-        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
-        goto out;
-    }
+    /*
+     * Extract the cpumap from the cpupool the domain belong to. In fact,
+     * it only makes sense to consider the cpus/nodes that are in there
+     * for placement.
+     */
+    rc = cpupool = libxl__domain_cpupool(gc, domid);
+    if (rc < 0)
+        return rc;
+    rc = libxl_cpupool_info(CTX, &cpupool_info, cpupool);
+    if (rc)
+        return rc;
 
     rc = libxl_domain_need_memory(CTX, info, &memkb);
     if (rc)
@@ -513,7 +547,8 @@ static int numa_place_domain(libxl__gc *
 
     /* Find all the candidates with enough free memory and at least
      * as much pcpus as the domain has vcpus.  */
-    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
+    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus,
+                                    0, 0, &cpupool_info.cpumap,
                                     &candidates, &nr_candidates);
     if (rc)
         goto out;
@@ -538,13 +573,20 @@ static int numa_place_domain(libxl__gc *
     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);
+    }
+
     LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
                 "%"PRIu32" KB free selected", candidates[0].nr_nodes,
                 candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
 
  out:
     libxl_bitmap_dispose(&candidate_nodemap);
-    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
+    libxl_cpupoolinfo_dispose(&cpupool_info);
     return rc;
 }
 
@@ -567,7 +609,7 @@ int libxl__build_pre(libxl__gc *gc, uint
      * whatever that turns out to be.
      */
     if (libxl_bitmap_is_full(&info->cpumap)) {
-        int rc = numa_place_domain(gc, info);
+        int rc = numa_place_domain(gc, domid, info);
         if (rc)
             return rc;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2094,14 +2094,17 @@ typedef struct {
  * least that amount of free memory and that number of cpus, respectively. If
  * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
  * of cpus won't be checked at all, which means a candidate will always be
- * considered suitable wrt the specific constraint.  cndts is where the list of
- * exactly nr_cndts candidates is returned. Note that, in case no candidates
- * are found at all, the function returns successfully, but with nr_cndts equal
- * to zero.
+ * considered suitable wrt the specific constraint. suitable_cpumap is useful
+ * for specifyin we want only the cpus in that mask to be considered while
+ * generating placement candidates (for example because of cpupools). cndts is
+ * where the list of exactly nr_cndts candidates is returned. Note that, in
+ * case no candidates are found at all, the function returns successfully, but
+ * with nr_cndts equal to zero.
  */
 _hidden int libxl__get_numa_candidates(libxl__gc *gc,
                                 uint32_t min_free_memkb, int min_cpus,
                                 int min_nodes, int max_nodes,
+                                const libxl_bitmap *suitable_cpumap,
                                 libxl__numa_candidate *cndts[], int *nr_cndts);
 
 /* allocation and deallocation for placement candidates */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxw-000531-Mm; Fri, 15 Jun 2012 17:05:44 +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 1SfZxv-000519-GE
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:43 +0000
Received: from [85.158.143.99:50177] by server-2.bemta-4.messagelabs.com id
	41/BA-17938-66B6BDF4; Fri, 15 Jun 2012 17:05:42 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779923!22329884!3
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21590 invoked from network); 15 Jun 2012 17:05:41 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:41 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2260470wgb.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=ZMc5RvwZxXPwPhgxihmfAYMQhQwFguKSXo8HwYloG0E=;
	b=rGiRN6C48ksX0JQc+ekbaF+T/lE0v6ksMVIlBFill77QX7xDubmLqP5n3D53CExQnL
	VotyoiEI5xPxVHOEtx4IQ8g6jf97WP3g66ENB3POK2+ibgeR8skh/nJcPND5bj1jIca/
	93w/Exckhr1XDQniROxrtD9zRvm6CPV0zyDaxpYptpdfzMF4I4HlbrPZ59DGzvRTfpD/
	jRk7zxOgLyzAl+w4ZkC2PfjuJxEkR6BDUe7VKF7IDN39Bqyx3O3ui1zX/cShWnZaoUCO
	lzS2BYz9qY9cug6Krn7XJvb+3PBEoHSMoqR2UfFo3G7b4O864enCy9MOXmNm9B/QIm0R
	N9gw==
Received: by 10.180.93.196 with SMTP id cw4mr5992275wib.11.1339779941595;
	Fri, 15 Jun 2012 10:05:41 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:40 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 93dc34fa681a1391dcf95ddf447d90f4045d5b3a
Message-Id: <93dc34fa681a1391dcf9.1339779877@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:37 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
	with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In such a way that only the cpus belonging to the cpupool of the
domain being placed are considered for the placement itself.

This happens by filtering out all the nodes in which the cpupool has
not any cpu from the placement candidates. After that -- as a cpu pooling
not necessarily happens at NUMA nodes boundaries -- we also make sure
only the actual cpus that are part of the pool are considered when
counting how much processors a placement candidate is able to provide.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
@@ -198,15 +198,27 @@ static void comb_get_nodemap(comb_iter_t
         libxl_bitmap_set(nodemap, it[i]);
 }
 
+/* Retrieve how many nodes a nodemap spans. */
+static int nodemap_to_nr_nodes(const libxl_bitmap *nodemap)
+{
+    int i, nr_nodes = 0;
+
+    libxl_for_each_set_bit(i, *nodemap)
+        nr_nodes++;
+    return nr_nodes;
+}
+
 /* Retrieve the number of cpus that the nodes that are part of the nodemap
- * span. */
+ * span and that are also set in suitable_cpumap. */
 static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
+                                 const libxl_bitmap *suitable_cpumap,
                                  const libxl_bitmap *nodemap)
 {
     int i, nodes_cpus = 0;
 
     for (i = 0; i < nr_cpus; i++) {
-        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+        if (libxl_bitmap_test(suitable_cpumap, i) &&
+            libxl_bitmap_test(nodemap, tinfo[i].node))
             nodes_cpus++;
     }
     return nodes_cpus;
@@ -311,12 +323,13 @@ static int cpus_per_node_count(libxl_cpu
 int libxl__get_numa_candidates(libxl__gc *gc,
                                uint32_t min_free_memkb, int min_cpus,
                                int min_nodes, int max_nodes,
+                               const libxl_bitmap *suitable_cpumap,
                                libxl__numa_candidate *cndts[], int *nr_cndts)
 {
     libxl__numa_candidate *new_cndts = NULL;
     libxl_cputopology *tinfo = NULL;
     libxl_numainfo *ninfo = NULL;
-    libxl_bitmap nodemap;
+    libxl_bitmap suitable_nodemap, nodemap;
     int nr_nodes, nr_cpus;
     int array_size, rc;
 
@@ -340,6 +353,15 @@ int libxl__get_numa_candidates(libxl__gc
     if (rc)
         goto out;
 
+    /* Allocate and prepare the map of the node that can be utilized for
+     * placement, basing on the map of suitable cpus. */
+    rc = libxl_node_bitmap_alloc(CTX, &suitable_nodemap);
+    if (rc)
+        goto out;
+    rc = libxl_cpumap_to_nodemap(CTX, suitable_cpumap, &suitable_nodemap);
+    if (rc)
+        goto out;
+
     /*
      * Round up and down some of the constraints. For instance, the minimum
      * number of cpus a candidate should have must at least be non-negative.
@@ -391,9 +413,14 @@ int libxl__get_numa_candidates(libxl__gc
         for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
              comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
             uint32_t nodes_free_memkb;
-            int nodes_cpus;
+            int i, nodes_cpus;
 
+            /* Get the nodemap for the combination and filter unwnted nodes */
             comb_get_nodemap(comb_iter, &nodemap, min_nodes);
+            libxl_for_each_set_bit(i, nodemap) {
+                if (!libxl_bitmap_test(&suitable_nodemap, i))
+                    libxl_bitmap_reset(&nodemap, i);
+            }
 
             /* If there is not enough memoy in this combination, skip it
              * and go generating the next one... */
@@ -402,7 +429,8 @@ int libxl__get_numa_candidates(libxl__gc
                 continue;
 
             /* And the same applies if this combination is short in cpus */
-            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
+            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, suitable_cpumap,
+                                               &nodemap);
             if (min_cpus > 0 && nodes_cpus < min_cpus)
                 continue;
 
@@ -427,12 +455,13 @@ int libxl__get_numa_candidates(libxl__gc
             new_cndts[*nr_cndts].nr_domains =
                                     nodemap_to_nr_domains(gc, tinfo, &nodemap);
             new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
-            new_cndts[*nr_cndts].nr_nodes = min_nodes;
+            new_cndts[*nr_cndts].nr_nodes = nodemap_to_nr_nodes(&nodemap);
             new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
 
             LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
                        "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
-                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
+                       new_cndts[*nr_cndts].nr_nodes,
+                       new_cndts[*nr_cndts].nr_cpus,
                        new_cndts[*nr_cndts].free_memkb / 1024);
 
             (*nr_cndts)++;
@@ -442,6 +471,7 @@ int libxl__get_numa_candidates(libxl__gc
 
     *cndts = new_cndts;
  out:
+    libxl_bitmap_dispose(&suitable_nodemap);
     libxl_bitmap_dispose(&nodemap);
     libxl_cputopology_list_free(tinfo, nr_cpus);
     libxl_numainfo_list_free(ninfo, nr_nodes);
@@ -485,23 +515,27 @@ static int numa_cmpf(const void *v1, con
 }
 
 /* The actual automatic NUMA placement routine */
-static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
+static int numa_place_domain(libxl__gc *gc, uint32_t domid,
+                             libxl_domain_build_info *info)
 {
     int nr_candidates = 0;
     libxl__numa_candidate *candidates = NULL;
     libxl_bitmap candidate_nodemap;
-    libxl_cpupoolinfo *pinfo;
-    int nr_pools, rc = 0;
+    libxl_cpupoolinfo cpupool_info;
+    int i, cpupool, rc = 0;
     uint32_t memkb;
 
-    /* First of all, if cpupools are in use, better not to mess with them */
-    pinfo = libxl_list_cpupool(CTX, &nr_pools);
-    if (!pinfo)
-        return ERROR_FAIL;
-    if (nr_pools > 1) {
-        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
-        goto out;
-    }
+    /*
+     * Extract the cpumap from the cpupool the domain belong to. In fact,
+     * it only makes sense to consider the cpus/nodes that are in there
+     * for placement.
+     */
+    rc = cpupool = libxl__domain_cpupool(gc, domid);
+    if (rc < 0)
+        return rc;
+    rc = libxl_cpupool_info(CTX, &cpupool_info, cpupool);
+    if (rc)
+        return rc;
 
     rc = libxl_domain_need_memory(CTX, info, &memkb);
     if (rc)
@@ -513,7 +547,8 @@ static int numa_place_domain(libxl__gc *
 
     /* Find all the candidates with enough free memory and at least
      * as much pcpus as the domain has vcpus.  */
-    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
+    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus,
+                                    0, 0, &cpupool_info.cpumap,
                                     &candidates, &nr_candidates);
     if (rc)
         goto out;
@@ -538,13 +573,20 @@ static int numa_place_domain(libxl__gc *
     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);
+    }
+
     LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
                 "%"PRIu32" KB free selected", candidates[0].nr_nodes,
                 candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
 
  out:
     libxl_bitmap_dispose(&candidate_nodemap);
-    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
+    libxl_cpupoolinfo_dispose(&cpupool_info);
     return rc;
 }
 
@@ -567,7 +609,7 @@ int libxl__build_pre(libxl__gc *gc, uint
      * whatever that turns out to be.
      */
     if (libxl_bitmap_is_full(&info->cpumap)) {
-        int rc = numa_place_domain(gc, info);
+        int rc = numa_place_domain(gc, domid, info);
         if (rc)
             return rc;
     }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2094,14 +2094,17 @@ typedef struct {
  * least that amount of free memory and that number of cpus, respectively. If
  * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
  * of cpus won't be checked at all, which means a candidate will always be
- * considered suitable wrt the specific constraint.  cndts is where the list of
- * exactly nr_cndts candidates is returned. Note that, in case no candidates
- * are found at all, the function returns successfully, but with nr_cndts equal
- * to zero.
+ * considered suitable wrt the specific constraint. suitable_cpumap is useful
+ * for specifyin we want only the cpus in that mask to be considered while
+ * generating placement candidates (for example because of cpupools). cndts is
+ * where the list of exactly nr_cndts candidates is returned. Note that, in
+ * case no candidates are found at all, the function returns successfully, but
+ * with nr_cndts equal to zero.
  */
 _hidden int libxl__get_numa_candidates(libxl__gc *gc,
                                 uint32_t min_free_memkb, int min_cpus,
                                 int min_nodes, int max_nodes,
+                                const libxl_bitmap *suitable_cpumap,
                                 libxl__numa_candidate *cndts[], int *nr_cndts);
 
 /* allocation and deallocation for placement candidates */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxv-000518-2g; Fri, 15 Jun 2012 17:05:43 +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 1SfZxt-0004zt-0r
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:41 +0000
Received: from [85.158.138.51:62640] by server-3.bemta-3.messagelabs.com id
	D5/BE-26490-46B6BDF4; Fri, 15 Jun 2012 17:05:40 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339779918!27951887!3
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27579 invoked from network); 15 Jun 2012 17:05:38 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:38 -0000
Received: by mail-we0-f173.google.com with SMTP id f3so2750411wer.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=B9ubDMll59l5+woGmn/QaUX6Jk8+6OZ+VH77l4OcPlI=;
	b=ADupGRSBMsNiwRMrdS9X4mXt/kyd2Q8Zlos5eIclkBy4WoQ7eGHOGBP35Pxf61bxXB
	Hf8jUVVtcJV7qE/4VuBPPpY3GX3DA3PrePA6/K8Pz0C3WOOakvNiNUfd2KBTHhu86K+M
	r7ppL2K0p/5SGJU08FHpu9LnZsw2l/OX5udRJETNeCSOaP4o1cPdVTr4Si3T7MV6Md+r
	Dk/5B/Xi33IpGz1BWlTHl+OiH96NLHezO9WQELzj88WfHh775KRi8qq38odTinwM7vXP
	7e3PWnblrMKCCx6ypkhpkf7mO/4fy3AVkbIwWjm8yK2Xwe5Bk5qJV+ugaSMudJ7ooL5i
	LVmA==
Received: by 10.216.198.162 with SMTP id v34mr3928078wen.75.1339779938491;
	Fri, 15 Jun 2012 10:05:38 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:37 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 81f18379bb3d4d9397d1d111c5edb177258f2f0a
Message-Id: <81f18379bb3d4d9397d1.1339779876@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:36 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic placement
 of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If a domain does not have a VCPU affinity, try to pin it automatically to some
PCPUs. This is done taking into account the NUMA characteristics of the host.
In fact, we look for a combination of host's NUMA nodes with enough free memory
and number of PCPUs for the new domain, and pin it to the VCPUs of those nodes.

Once we know which ones, among all the possible combinations, represents valid
placement candidates for a domain, use some heuistics for deciding which is the
best. For instance, smaller candidates are considered to be better, both from
the domain's point of view (fewer memory spreading among nodes) and from the
system as a whole point of view (fewer memoy fragmentation).  In case of
candidates of equal sizes (i.e., with the same number of nodes), the one with
the greater amount of memory wins, as this is also good for keeping memory
fragmentation under control.

This all happens internally to libxl, and no API for driving the mechanism is
provided for now. This matches what xend already does.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * This patches incorporates the changes from both "libxl, xl: enable automatic
   placement of guests on NUMA nodes" and "libxl, xl: heuristics for reordering
   NUMA placement candidates" from v1.
 * The logic of the algorithm is basically the same as in v1, but the splitting
   of it in the various functions has been completely redesigned from scratch.
 * No public API for placement or candidate generation is now exposed,
   everything happens within libxl, as agreed during v1 review.
 * The relevant documentation have been moved near the actual functions and
   features. Also, the amount and (hopefully!) the quality of the documentation
   has been improved a lot, as requested.
 * All the comments about using the proper libxl facilities and helpers for
   allocations, etc., have been considered and applied.
 * This patch still bails out from NUMA optimizations if it find out cpupools
   are being utilized. It is next patch that makes the two things interact
   properly, as suggested during review.

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -111,8 +111,8 @@ created online and the remainder will be
 
 =item B<cpus="CPU-LIST">
 
-List of which cpus the guest is allowed to use. Default behavior is
-`all cpus`. A C<CPU-LIST> may be specified as follows:
+List of which cpus the guest is allowed to use. By default xl will (via
+libxl) pick some cpus (see below). A C<CPU-LIST> may be specified as follows:
 
 =over 4
 
@@ -132,6 +132,12 @@ run on cpu #3 of the host.
 
 =back
 
+If this option is not specified, libxl automatically tries to place the new
+domain on the host's NUMA nodes (provided the host has more than one NUMA
+node) by pinning it to the cpus of those nodes. An heuristical approach is
+utilized with the goals of maximizing performance for the domain and, at
+the same time, achieving efficient utilization of the host's CPUs and RAM.
+
 =item B<cpu_weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
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
@@ -95,6 +95,459 @@ out:
     return sched;
 }
 
+/*
+ * What follows are helpers for generating all the k-combinations
+ * without repetitions of a set S with n elements in it. Formally
+ * speaking, they are subsets of k distinct elements of S and, if
+ * S is n elements big, the number of k-combinations is equal to
+ * the binomial coefficient (n k), which means we get exactly
+ * n!/(k! * (n - k)!) subsets, all of them with k elements.
+ *
+ * The various subset are geneated one after the other by calling
+ * comb_init() first, and, after that, comb_next()
+ * (n k)-1 times. An iterator is used to store the curent status
+ * of the whole generation operation (i.e., basically, the last
+ * combination that has been generated). As soon as all
+ * combinations have been generated, comb_next() will
+ * start returning 0 instead of 1. It is of course impotant that
+ * the same instance of the iterator and the same values for
+ * n and k are used for each call. If that doesn't happen, the
+ * result is unspecified.
+ *
+ * The algorithm is a well known one, and it produces the
+ * combinations in such a way that they (well, more precisely,
+ * their indexes it the array/map representing the set) come in
+ * lexicogaphic order.
+ *
+ * For example, with n = 5 and k = 3, calling comb_init()
+ * will generate { 0, 1, 2 }, while subsequent valid calls to
+ * comb_next() will produce the following:
+ * { { 0, 1, 2 }, { 0, 1, 3 }, { 0, 1, 4 },
+ *   { 0, 2, 3 }, { 0, 2, 4 }, { 0, 3, 4 },
+ *   { 1, 2, 3 }, { 1, 2, 4 }, { 1, 3, 4 },
+ *   { 2, 3, 4 } }
+ *
+ * This is used by the automatic NUMA placement logic below.
+ */
+typedef int* comb_iter_t;
+
+static int comb_init(libxl__gc *gc, comb_iter_t *it, int n, int k)
+{
+    comb_iter_t new_iter;
+    int i;
+
+    if (n < k)
+        return 0;
+
+    /* First set is always { 0, 1, 2, ..., k-1 } */
+    GCNEW_ARRAY(new_iter, k);
+    for (i = 0; i < k; i++)
+        new_iter[i] = i;
+
+    *it = new_iter;
+    return 1;
+}
+
+static int comb_next(comb_iter_t it, int n, int k)
+{
+    int i;
+
+    /*
+     * The idea here is to find the leftmost element from where
+     * we should start incrementing the indexes of the iterator.
+     * This means looking for the highest index that can be increased
+     * while still producing value smaller than n-1. In the example
+     * above, when dealing with { 0, 1, 4 }, such an element is the
+     * second one, as the third is already equal to 4 (which actually
+     * is n-1).
+     * Once we found from where to start, we increment that element
+     * and overide the right-hand rest of the iterator with its
+     * successors, thus achieving lexicographic ordering.
+     *
+     * Regarding the termination of the generation process, when we
+     * manage in bringing n-k at the very first position of the iterator,
+     * we know that is the last valid combination ( { 2, 3, 4 }, with
+     * n - k = 5 - 2 = 2, in the example above), and thus we start
+     * returning 0 as soon as we cross that border.
+     */
+    for (i = k - 1; it[i] == n - k + i; i--) {
+        if (i <= 0)
+            return 0;
+    }
+    for (it[i]++, i++; i < k; i++)
+        it[i] = it[i - 1] + 1;
+    return 1;
+}
+
+/* NUMA automatic placement (see libxl_internal.h for details) */
+
+/*
+ * This function turns a k-combination iterator into a node map.
+ * This means the bits in the node map corresponding to the indexes
+ * of the given combination are the ones that will be set.
+ * For example, if the iterator represents the combination { 0, 2, 4},
+ * the node map will have bits #0, #2 and #4 set to one and i thus
+ * will point to node 0, node 2 and and node 4.
+ */
+static void comb_get_nodemap(comb_iter_t it, libxl_bitmap *nodemap, int k)
+{
+    int i;
+
+    libxl_bitmap_set_none(nodemap);
+    for (i = 0; i < k; i++)
+        libxl_bitmap_set(nodemap, it[i]);
+}
+
+/* Retrieve the number of cpus that the nodes that are part of the nodemap
+ * span. */
+static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
+                                 const libxl_bitmap *nodemap)
+{
+    int i, nodes_cpus = 0;
+
+    for (i = 0; i < nr_cpus; i++) {
+        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+            nodes_cpus++;
+    }
+    return nodes_cpus;
+}
+
+/* Retrieve the amount of free memory within the nodemap */
+static uint32_t nodemap_to_free_memkb(libxl_numainfo *ninfo,
+                                      libxl_bitmap *nodemap)
+{
+    uint32_t free_memkb = 0;
+    int i;
+
+    libxl_for_each_set_bit(i, *nodemap)
+        free_memkb += ninfo[i].free / 1024;
+
+    return free_memkb;
+}
+
+/* Retrieve the number of domains that can potentially run on the cpus
+ * the nodes that are part of the nodemap. */
+static int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tinfo,
+                                 const libxl_bitmap *nodemap)
+{
+    libxl_dominfo *dinfo = NULL;
+    libxl_bitmap dom_nodemap;
+    int nr_doms, nr_cpus;
+    int nr_domains = 0;
+    int i, j, k;
+
+    dinfo = libxl_list_domain(CTX, &nr_doms);
+    if (dinfo == NULL)
+        return ERROR_FAIL;
+
+    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap) < 0) {
+        nr_domains = ERROR_FAIL;
+        goto out;
+    }
+
+    for (i = 0; i < nr_doms; i++) {
+        libxl_vcpuinfo *vinfo;
+        int nr_vcpus;
+
+        vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_cpus);
+        if (vinfo == NULL)
+            continue;
+
+        libxl_bitmap_set_none(&dom_nodemap);
+        for (j = 0; j < nr_vcpus; j++) {
+            libxl_for_each_set_bit(k, vinfo[j].cpumap)
+                libxl_bitmap_set(&dom_nodemap, tinfo[k].node);
+        }
+
+        libxl_for_each_set_bit(j, dom_nodemap) {
+            if (libxl_bitmap_test(nodemap, j)) {
+                nr_domains++;
+                goto found;
+            }
+        }
+ found:
+        libxl_vcpuinfo_list_free(vinfo, nr_vcpus);
+    }
+
+ out:
+    libxl_bitmap_dispose(&dom_nodemap);
+    libxl_dominfo_list_free(dinfo, nr_doms);
+    return nr_domains;
+}
+
+/*
+ * This function tries to figure out if the host has a consistent number
+ * of cpus along all its NUMA nodes. In fact, if that is the case, we can
+ * calculate the minimum number of nodes needed for a domain by just
+ * dividing its total number of vcpus by this value computed here.
+ * However, we are not allowed to assume that all the nodes have the
+ * same number of cpus. Therefore, in case discrepancies among different
+ * nodes are found, this function just returns 0 and the caller needs
+ * to sort out things in some other way.
+ */
+static int cpus_per_node_count(libxl_cputopology *tinfo, int nr_cpus,
+                               libxl_numainfo *ninfo, int nr_nodes)
+{
+    int cpus_per_node = 0;
+    int j, i;
+
+    /* This makes sense iff # of PCPUs is the same for all nodes */
+    for (j = 0; j < nr_nodes; j++) {
+        int curr_cpus = 0;
+
+        for (i = 0; i < nr_cpus; i++) {
+            if (tinfo[i].node == j)
+                curr_cpus++;
+        }
+        /* So, if the above does not hold, turn the whole thing off! */
+        cpus_per_node = cpus_per_node == 0 ? curr_cpus : cpus_per_node;
+        if (cpus_per_node != curr_cpus)
+            return 0;
+    }
+    return cpus_per_node;
+}
+
+/* Get all the placement candidates satisfying some specific conditions */
+int libxl__get_numa_candidates(libxl__gc *gc,
+                               uint32_t min_free_memkb, int min_cpus,
+                               int min_nodes, int max_nodes,
+                               libxl__numa_candidate *cndts[], int *nr_cndts)
+{
+    libxl__numa_candidate *new_cndts = NULL;
+    libxl_cputopology *tinfo = NULL;
+    libxl_numainfo *ninfo = NULL;
+    libxl_bitmap nodemap;
+    int nr_nodes, nr_cpus;
+    int array_size, rc;
+
+    /* Get platform info and prepare the map for testing the combinations */
+    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
+    if (ninfo == NULL)
+        return ERROR_FAIL;
+    /* If we don't have at least 2 nodes, it is useless to proceed */
+    if (nr_nodes < 2) {
+        rc = 0;
+        goto out;
+    }
+
+    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus);
+    if (tinfo == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_node_bitmap_alloc(CTX, &nodemap);
+    if (rc)
+        goto out;
+
+    /*
+     * Round up and down some of the constraints. For instance, the minimum
+     * number of cpus a candidate should have must at least be non-negative.
+     * Regarding the minimum number of NUMA nodes, if 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
+     * from 1 otherwise). The maximum number of nodes should not exceed the
+     * number of existent NUMA nodes on the host, or the candidate genaration
+     * won't work properly.
+     */
+    min_cpus = min_cpus <= 0 ? 0 : min_cpus;
+    if (min_nodes <= 0) {
+        int cpus_per_node;
+
+        cpus_per_node = cpus_per_node_count(tinfo, nr_cpus, ninfo, nr_nodes);
+        if (cpus_per_node == 0)
+            min_nodes = 1;
+        else
+            min_nodes = (min_cpus + cpus_per_node - 1) / cpus_per_node;
+    }
+    min_nodes = min_nodes > nr_nodes ? nr_nodes : min_nodes;
+    if (max_nodes <= 0)
+        max_nodes = nr_nodes;
+    else
+        max_nodes = max_nodes > nr_nodes ? nr_nodes : max_nodes;
+    if (min_nodes > max_nodes) {
+        rc = ERROR_INVAL;
+        goto out;
+    }
+
+    /* Initialize the local storage for the combinations */
+    *nr_cndts = 0;
+    array_size = nr_nodes;
+    GCNEW_ARRAY(new_cndts, array_size);
+
+    /* Generate all the combinations of any size from min_nodes to
+     * max_nodes (see comb_init() and comb_next()). */
+    while (min_nodes <= max_nodes) {
+        comb_iter_t comb_iter;
+        int comb_ok;
+
+        /*
+	 * And here it is. Each step of this cycle generates a combination of
+	 * nodes as big as min_nodes mandates.  Each of these combinations is
+	 * checked against the constraints provided by the caller (namely,
+	 * amount of free memory and number of cpus) and it becomes an actual
+	 * placement candidate iff it passes the check.
+         */
+        for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
+             comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
+            uint32_t nodes_free_memkb;
+            int nodes_cpus;
+
+            comb_get_nodemap(comb_iter, &nodemap, min_nodes);
+
+            /* If there is not enough memoy in this combination, skip it
+             * and go generating the next one... */
+            nodes_free_memkb = nodemap_to_free_memkb(ninfo, &nodemap);
+            if (min_free_memkb > 0 && nodes_free_memkb < min_free_memkb)
+                continue;
+
+            /* And the same applies if this combination is short in cpus */
+            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
+            if (min_cpus > 0 && nodes_cpus < min_cpus)
+                continue;
+
+            /*
+             * Conditions are met, we can add this combination to the
+             * NUMA placement candidates list. We first make sure there
+             * is enough space in there, and then we initialize the new
+             * candidate element with the node map corresponding to the
+             * combination we are dealing with. Memory allocation for
+             * expanding the array that hosts the list happens in chunks
+             * equal to the number of NUMA nodes in the system (to
+             * avoid allocating memory each and every time we find a
+             * new candidate).
+             */
+            if (*nr_cndts == array_size)
+                array_size += nr_nodes;
+            GCREALLOC_ARRAY(new_cndts, array_size);
+
+            libxl__numa_candidate_alloc(gc, &new_cndts[*nr_cndts]);
+            libxl__numa_candidate_put_nodemap(gc, &new_cndts[*nr_cndts],
+                                              &nodemap);
+            new_cndts[*nr_cndts].nr_domains =
+                                    nodemap_to_nr_domains(gc, tinfo, &nodemap);
+            new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
+            new_cndts[*nr_cndts].nr_nodes = min_nodes;
+            new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
+
+            LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
+                       "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
+                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
+                       new_cndts[*nr_cndts].free_memkb / 1024);
+
+            (*nr_cndts)++;
+        }
+        min_nodes++;
+    }
+
+    *cndts = new_cndts;
+ out:
+    libxl_bitmap_dispose(&nodemap);
+    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_numainfo_list_free(ninfo, nr_nodes);
+    return rc;
+}
+
+void libxl__sort_numa_candidates(libxl__numa_candidate cndts[], int nr_cndts,
+                                 libxl__numa_candidate_cmpf cmpf)
+{
+    /* Reorder candidates (see the comparison function for
+     * the details on the heuristics) */
+    qsort(cndts, nr_cndts, sizeof(cndts[0]), cmpf);
+}
+
+/*
+ * The NUMA placement candidates are reordered according to the following
+ * heuristics:
+ *  - candidates involving fewer nodes come first. In case two (or
+ *    more) candidates span the same number of nodes,
+ *  - candidates with greater amount of free memory come first. In
+ *    case two (or more) candidates differ in their amount of free
+ *    memory by less than 10%,
+ *  - candidates with fewer domains insisting on them at the time of
+ *    this call come first.
+ */
+static int numa_cmpf(const void *v1, const void *v2)
+{
+    const libxl__numa_candidate *c1 = (const libxl__numa_candidate*) v1;
+    const libxl__numa_candidate *c2 = (const libxl__numa_candidate*) v2;
+    double mem_diff = labs(c1->free_memkb - c2->free_memkb);
+    double mem_avg = (c1->free_memkb + c2->free_memkb) / 2.0;
+
+    if (c1->nr_nodes != c2->nr_nodes)
+        return c1->nr_nodes - c2->nr_nodes;
+
+    if ((mem_diff / mem_avg) * 100.0 < 10.0 &&
+        c1->nr_domains != c2->nr_domains)
+        return c1->nr_domains - c2->nr_domains;
+
+    return c2->free_memkb - c1->free_memkb;
+}
+
+/* The actual automatic NUMA placement routine */
+static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
+{
+    int nr_candidates = 0;
+    libxl__numa_candidate *candidates = NULL;
+    libxl_bitmap candidate_nodemap;
+    libxl_cpupoolinfo *pinfo;
+    int nr_pools, rc = 0;
+    uint32_t memkb;
+
+    /* First of all, if cpupools are in use, better not to mess with them */
+    pinfo = libxl_list_cpupool(CTX, &nr_pools);
+    if (!pinfo)
+        return ERROR_FAIL;
+    if (nr_pools > 1) {
+        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
+        goto out;
+    }
+
+    rc = libxl_domain_need_memory(CTX, info, &memkb);
+    if (rc)
+        goto out;
+    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    /* Find all the candidates with enough free memory and at least
+     * as much pcpus as the domain has vcpus.  */
+    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
+                                    &candidates, &nr_candidates);
+    if (rc)
+        goto out;
+
+    LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates);
+
+    /* No suitable placement candidates. We just return without touching the
+     * domain's info->cpumap. It will have affinity with all nodes/cpus. */
+    if (nr_candidates == 0)
+        goto out;
+
+    /* Bring the best candidate in front of the list --> candidates[0] */
+    if (nr_candidates > 1)
+        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);
+
+    /*
+     * At this point, the first candidate in the array is the one we want.
+     * Go for it by mapping its node map to the domain's info->cpumap.
+     */
+    libxl__numa_candidate_get_nodemap(gc, &candidates[0], &candidate_nodemap);
+    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
+    if (rc)
+        goto out;
+
+    LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
+                "%"PRIu32" KB free selected", candidates[0].nr_nodes,
+                candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
+
+ out:
+    libxl_bitmap_dispose(&candidate_nodemap);
+    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
+    return rc;
+}
+
 int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
@@ -104,7 +557,22 @@ int libxl__build_pre(libxl__gc *gc, uint
     uint32_t rtc_timeoffset;
 
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+
+    /*
+     * 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 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,
+     * whatever that turns out to be.
+     */
+    if (libxl_bitmap_is_full(&info->cpumap)) {
+        int rc = numa_place_domain(gc, info);
+        if (rc)
+            return rc;
+    }
     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,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
 #define CTX_LOCK (libxl__ctx_lock(CTX))
 #define CTX_UNLOCK (libxl__ctx_unlock(CTX))
 
+/*
+ * Automatic NUMA placement
+ *
+ * These functions and data structures deal with the initial placement of a
+ * domain onto the host NUMA nodes.
+ *
+ * The key concept here is the one of "numa placement candidate" (or jusr "numa
+ * candidate", "placement candidate" or even "candidate"), which basically is a
+ * set of nodes whose characteristics have been successfully checked against
+ * some specific requirements. More pecisely, a candidate is the nodemap
+ * associated with one of the possible subset of the host NUMA nodes providing
+ * a certain amount of free memory, or a given number of cpus, or even both
+ * (depending in what the caller wants). For convenience of use, some of this
+ * information are stored within the candidate itselfs, instead of always being
+ * dynamically computed. A candidate can consist of just one, up to all the
+ * available nodes on the host (the latter being, of course, not ideal).  For
+ * instance, looking for a numa candidates with 2GB of free memoy means we want
+ * all the possible subsets of the host NUMA nodes with, cumulatively, at least
+ * 2GB of free memory. That could be possible by just using one particular
+ * node, or may require more nodes, depending on the characteristics of the
+ * host, on how many domains have been created already, on how big they are,
+ * etc.
+ *
+ * The intended usage is as follows:
+ *  1. by, fist of all, calling libxl__get_numa_candidates(), and specifying
+ *     the proper constraints to it (e.g., the amount of memory a domain need
+ *     as the minimum amount of free memory fo the candidates) one can build
+ *     up a whole set of suitable placing alternatives for a domain;
+ *  2. after that, one specific candidate should be chosen. That can happen
+ *     by looking at their various characteristics;
+ *  3. the chosen candidate's nodemap should be utilized for computing the
+ *     actual affinity of the domain which, given the curent NUMA support
+ *     in the hypervisor, is what determines the placement of the domain's
+ *     vcpus and memory.
+ *
+ * To make phase 2 even easier, a sorting helper function for the list of
+ * candidates is povided in the form of libxl__sort_numa_candidates(). The only
+ * that is needed is defining a comparison function, containing the chriteria
+ * for deciding, given two candidates, which one is 'better'. Depending on how
+ * the comparison function is defined, the best candidate (where, of course,
+ * best is defined with respect to the heuristics implemented in the comparison
+ * function itself, libxl__numa_candidate_cmpf()) could become the first o the
+ * last element of the list.
+ *
+ * Summarizing, achieving automatic NUMA placement is just a matter of
+ * obtaining the list of suitable placement candidates, perhaps asking for each
+ * of them to provide at least the amount of memory the domain needs. After
+ * that just implement a comparison function by means of the various helpers
+ * retrieving the relevant information about the candidates themselves.
+ * Finally, call the sorting helper function and use the candidate that became
+ * (typically) the first element of the list fo determining the domain's
+ * affinity.
+ */
+
+typedef struct {
+    int nr_cpus, nr_nodes;
+    int nr_domains;
+    uint32_t free_memkb;
+    libxl_bitmap nodemap;
+} libxl__numa_candidate;
+
+/*
+ * This generates the list of NUMA placement candidates satisfying some
+ * specific conditions. If min_nodes and/or max_nodes are not 0, their value is
+ * used to determine the minimum and maximum number of nodes that are allow to
+ * be present in each candidate. If min_nodes and/or max_nodes are 0, the
+ * minimum and maximum number of nodes to be used are automatically selected by
+ * the implementation (and that will likely be just 1 node for the minimum and
+ * the total number of existent nodes for the maximum). Re min_free_memkb and
+ * min_cpu, if not 0, they specify the caller only wants candidates with at
+ * least that amount of free memory and that number of cpus, respectively. If
+ * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
+ * of cpus won't be checked at all, which means a candidate will always be
+ * considered suitable wrt the specific constraint.  cndts is where the list of
+ * exactly nr_cndts candidates is returned. Note that, in case no candidates
+ * are found at all, the function returns successfully, but with nr_cndts equal
+ * to zero.
+ */
+_hidden int libxl__get_numa_candidates(libxl__gc *gc,
+                                uint32_t min_free_memkb, int min_cpus,
+                                int min_nodes, int max_nodes,
+                                libxl__numa_candidate *cndts[], int *nr_cndts);
+
+/* allocation and deallocation for placement candidates */
+static inline int libxl__numa_candidate_alloc(libxl__gc *gc,
+                                              libxl__numa_candidate *cndt)
+{
+    return libxl_node_bitmap_alloc(CTX, &cndt->nodemap);
+}
+static inline void libxl__numa_candidate_dispose(libxl__numa_candidate *cndt)
+{
+    libxl_bitmap_dispose(&cndt->nodemap);
+}
+static inline void libxl__numacandidate_list_free(libxl__numa_candidate *cndts,
+                                                  int nr_cndts)
+{
+    int i;
+
+    for (i = 0; i < nr_cndts; i++)
+        libxl__numa_candidate_dispose(&cndts[i]);
+    free(cndts);
+}
+
+/* retrieve (in nodemap) the node map associated to placement candidate cndt */
+static inline
+void libxl__numa_candidate_get_nodemap(libxl__gc *gc,
+                                       const libxl__numa_candidate *cndt,
+                                       libxl_bitmap *nodemap)
+{
+    libxl_bitmap_copy(CTX, nodemap, &cndt->nodemap);
+}
+/* set the node map of placement candidate cndt to match nodemap */
+static inline
+void libxl__numa_candidate_put_nodemap(libxl__gc *gc,
+                                       libxl__numa_candidate *cndt,
+                                       const libxl_bitmap *nodemap)
+{
+    libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap);
+}
+
+/* signature for the comparison function between two candidates c1 and c2
+ * (the thid parameter is provided to enable thread safety). */
+typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2);
+/* sort the list of candidates in cndts (an array with nr_cndts elements in
+ * it) using cmpf for comparing two candidates. Uses libc's qsort(). */
+_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
+                                         int nr_cndts,
+                                         libxl__numa_candidate_cmpf cmpf);
 
 /*
  * Inserts "elm_new" into the sorted list "head".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxv-000518-2g; Fri, 15 Jun 2012 17:05:43 +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 1SfZxt-0004zt-0r
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:41 +0000
Received: from [85.158.138.51:62640] by server-3.bemta-3.messagelabs.com id
	D5/BE-26490-46B6BDF4; Fri, 15 Jun 2012 17:05:40 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339779918!27951887!3
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27579 invoked from network); 15 Jun 2012 17:05:38 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:05:38 -0000
Received: by mail-we0-f173.google.com with SMTP id f3so2750411wer.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=B9ubDMll59l5+woGmn/QaUX6Jk8+6OZ+VH77l4OcPlI=;
	b=ADupGRSBMsNiwRMrdS9X4mXt/kyd2Q8Zlos5eIclkBy4WoQ7eGHOGBP35Pxf61bxXB
	Hf8jUVVtcJV7qE/4VuBPPpY3GX3DA3PrePA6/K8Pz0C3WOOakvNiNUfd2KBTHhu86K+M
	r7ppL2K0p/5SGJU08FHpu9LnZsw2l/OX5udRJETNeCSOaP4o1cPdVTr4Si3T7MV6Md+r
	Dk/5B/Xi33IpGz1BWlTHl+OiH96NLHezO9WQELzj88WfHh775KRi8qq38odTinwM7vXP
	7e3PWnblrMKCCx6ypkhpkf7mO/4fy3AVkbIwWjm8yK2Xwe5Bk5qJV+ugaSMudJ7ooL5i
	LVmA==
Received: by 10.216.198.162 with SMTP id v34mr3928078wen.75.1339779938491;
	Fri, 15 Jun 2012 10:05:38 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:37 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 81f18379bb3d4d9397d1d111c5edb177258f2f0a
Message-Id: <81f18379bb3d4d9397d1.1339779876@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:36 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic placement
 of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If a domain does not have a VCPU affinity, try to pin it automatically to some
PCPUs. This is done taking into account the NUMA characteristics of the host.
In fact, we look for a combination of host's NUMA nodes with enough free memory
and number of PCPUs for the new domain, and pin it to the VCPUs of those nodes.

Once we know which ones, among all the possible combinations, represents valid
placement candidates for a domain, use some heuistics for deciding which is the
best. For instance, smaller candidates are considered to be better, both from
the domain's point of view (fewer memory spreading among nodes) and from the
system as a whole point of view (fewer memoy fragmentation).  In case of
candidates of equal sizes (i.e., with the same number of nodes), the one with
the greater amount of memory wins, as this is also good for keeping memory
fragmentation under control.

This all happens internally to libxl, and no API for driving the mechanism is
provided for now. This matches what xend already does.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * This patches incorporates the changes from both "libxl, xl: enable automatic
   placement of guests on NUMA nodes" and "libxl, xl: heuristics for reordering
   NUMA placement candidates" from v1.
 * The logic of the algorithm is basically the same as in v1, but the splitting
   of it in the various functions has been completely redesigned from scratch.
 * No public API for placement or candidate generation is now exposed,
   everything happens within libxl, as agreed during v1 review.
 * The relevant documentation have been moved near the actual functions and
   features. Also, the amount and (hopefully!) the quality of the documentation
   has been improved a lot, as requested.
 * All the comments about using the proper libxl facilities and helpers for
   allocations, etc., have been considered and applied.
 * This patch still bails out from NUMA optimizations if it find out cpupools
   are being utilized. It is next patch that makes the two things interact
   properly, as suggested during review.

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -111,8 +111,8 @@ created online and the remainder will be
 
 =item B<cpus="CPU-LIST">
 
-List of which cpus the guest is allowed to use. Default behavior is
-`all cpus`. A C<CPU-LIST> may be specified as follows:
+List of which cpus the guest is allowed to use. By default xl will (via
+libxl) pick some cpus (see below). A C<CPU-LIST> may be specified as follows:
 
 =over 4
 
@@ -132,6 +132,12 @@ run on cpu #3 of the host.
 
 =back
 
+If this option is not specified, libxl automatically tries to place the new
+domain on the host's NUMA nodes (provided the host has more than one NUMA
+node) by pinning it to the cpus of those nodes. An heuristical approach is
+utilized with the goals of maximizing performance for the domain and, at
+the same time, achieving efficient utilization of the host's CPUs and RAM.
+
 =item B<cpu_weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
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
@@ -95,6 +95,459 @@ out:
     return sched;
 }
 
+/*
+ * What follows are helpers for generating all the k-combinations
+ * without repetitions of a set S with n elements in it. Formally
+ * speaking, they are subsets of k distinct elements of S and, if
+ * S is n elements big, the number of k-combinations is equal to
+ * the binomial coefficient (n k), which means we get exactly
+ * n!/(k! * (n - k)!) subsets, all of them with k elements.
+ *
+ * The various subset are geneated one after the other by calling
+ * comb_init() first, and, after that, comb_next()
+ * (n k)-1 times. An iterator is used to store the curent status
+ * of the whole generation operation (i.e., basically, the last
+ * combination that has been generated). As soon as all
+ * combinations have been generated, comb_next() will
+ * start returning 0 instead of 1. It is of course impotant that
+ * the same instance of the iterator and the same values for
+ * n and k are used for each call. If that doesn't happen, the
+ * result is unspecified.
+ *
+ * The algorithm is a well known one, and it produces the
+ * combinations in such a way that they (well, more precisely,
+ * their indexes it the array/map representing the set) come in
+ * lexicogaphic order.
+ *
+ * For example, with n = 5 and k = 3, calling comb_init()
+ * will generate { 0, 1, 2 }, while subsequent valid calls to
+ * comb_next() will produce the following:
+ * { { 0, 1, 2 }, { 0, 1, 3 }, { 0, 1, 4 },
+ *   { 0, 2, 3 }, { 0, 2, 4 }, { 0, 3, 4 },
+ *   { 1, 2, 3 }, { 1, 2, 4 }, { 1, 3, 4 },
+ *   { 2, 3, 4 } }
+ *
+ * This is used by the automatic NUMA placement logic below.
+ */
+typedef int* comb_iter_t;
+
+static int comb_init(libxl__gc *gc, comb_iter_t *it, int n, int k)
+{
+    comb_iter_t new_iter;
+    int i;
+
+    if (n < k)
+        return 0;
+
+    /* First set is always { 0, 1, 2, ..., k-1 } */
+    GCNEW_ARRAY(new_iter, k);
+    for (i = 0; i < k; i++)
+        new_iter[i] = i;
+
+    *it = new_iter;
+    return 1;
+}
+
+static int comb_next(comb_iter_t it, int n, int k)
+{
+    int i;
+
+    /*
+     * The idea here is to find the leftmost element from where
+     * we should start incrementing the indexes of the iterator.
+     * This means looking for the highest index that can be increased
+     * while still producing value smaller than n-1. In the example
+     * above, when dealing with { 0, 1, 4 }, such an element is the
+     * second one, as the third is already equal to 4 (which actually
+     * is n-1).
+     * Once we found from where to start, we increment that element
+     * and overide the right-hand rest of the iterator with its
+     * successors, thus achieving lexicographic ordering.
+     *
+     * Regarding the termination of the generation process, when we
+     * manage in bringing n-k at the very first position of the iterator,
+     * we know that is the last valid combination ( { 2, 3, 4 }, with
+     * n - k = 5 - 2 = 2, in the example above), and thus we start
+     * returning 0 as soon as we cross that border.
+     */
+    for (i = k - 1; it[i] == n - k + i; i--) {
+        if (i <= 0)
+            return 0;
+    }
+    for (it[i]++, i++; i < k; i++)
+        it[i] = it[i - 1] + 1;
+    return 1;
+}
+
+/* NUMA automatic placement (see libxl_internal.h for details) */
+
+/*
+ * This function turns a k-combination iterator into a node map.
+ * This means the bits in the node map corresponding to the indexes
+ * of the given combination are the ones that will be set.
+ * For example, if the iterator represents the combination { 0, 2, 4},
+ * the node map will have bits #0, #2 and #4 set to one and i thus
+ * will point to node 0, node 2 and and node 4.
+ */
+static void comb_get_nodemap(comb_iter_t it, libxl_bitmap *nodemap, int k)
+{
+    int i;
+
+    libxl_bitmap_set_none(nodemap);
+    for (i = 0; i < k; i++)
+        libxl_bitmap_set(nodemap, it[i]);
+}
+
+/* Retrieve the number of cpus that the nodes that are part of the nodemap
+ * span. */
+static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
+                                 const libxl_bitmap *nodemap)
+{
+    int i, nodes_cpus = 0;
+
+    for (i = 0; i < nr_cpus; i++) {
+        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+            nodes_cpus++;
+    }
+    return nodes_cpus;
+}
+
+/* Retrieve the amount of free memory within the nodemap */
+static uint32_t nodemap_to_free_memkb(libxl_numainfo *ninfo,
+                                      libxl_bitmap *nodemap)
+{
+    uint32_t free_memkb = 0;
+    int i;
+
+    libxl_for_each_set_bit(i, *nodemap)
+        free_memkb += ninfo[i].free / 1024;
+
+    return free_memkb;
+}
+
+/* Retrieve the number of domains that can potentially run on the cpus
+ * the nodes that are part of the nodemap. */
+static int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tinfo,
+                                 const libxl_bitmap *nodemap)
+{
+    libxl_dominfo *dinfo = NULL;
+    libxl_bitmap dom_nodemap;
+    int nr_doms, nr_cpus;
+    int nr_domains = 0;
+    int i, j, k;
+
+    dinfo = libxl_list_domain(CTX, &nr_doms);
+    if (dinfo == NULL)
+        return ERROR_FAIL;
+
+    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap) < 0) {
+        nr_domains = ERROR_FAIL;
+        goto out;
+    }
+
+    for (i = 0; i < nr_doms; i++) {
+        libxl_vcpuinfo *vinfo;
+        int nr_vcpus;
+
+        vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_cpus);
+        if (vinfo == NULL)
+            continue;
+
+        libxl_bitmap_set_none(&dom_nodemap);
+        for (j = 0; j < nr_vcpus; j++) {
+            libxl_for_each_set_bit(k, vinfo[j].cpumap)
+                libxl_bitmap_set(&dom_nodemap, tinfo[k].node);
+        }
+
+        libxl_for_each_set_bit(j, dom_nodemap) {
+            if (libxl_bitmap_test(nodemap, j)) {
+                nr_domains++;
+                goto found;
+            }
+        }
+ found:
+        libxl_vcpuinfo_list_free(vinfo, nr_vcpus);
+    }
+
+ out:
+    libxl_bitmap_dispose(&dom_nodemap);
+    libxl_dominfo_list_free(dinfo, nr_doms);
+    return nr_domains;
+}
+
+/*
+ * This function tries to figure out if the host has a consistent number
+ * of cpus along all its NUMA nodes. In fact, if that is the case, we can
+ * calculate the minimum number of nodes needed for a domain by just
+ * dividing its total number of vcpus by this value computed here.
+ * However, we are not allowed to assume that all the nodes have the
+ * same number of cpus. Therefore, in case discrepancies among different
+ * nodes are found, this function just returns 0 and the caller needs
+ * to sort out things in some other way.
+ */
+static int cpus_per_node_count(libxl_cputopology *tinfo, int nr_cpus,
+                               libxl_numainfo *ninfo, int nr_nodes)
+{
+    int cpus_per_node = 0;
+    int j, i;
+
+    /* This makes sense iff # of PCPUs is the same for all nodes */
+    for (j = 0; j < nr_nodes; j++) {
+        int curr_cpus = 0;
+
+        for (i = 0; i < nr_cpus; i++) {
+            if (tinfo[i].node == j)
+                curr_cpus++;
+        }
+        /* So, if the above does not hold, turn the whole thing off! */
+        cpus_per_node = cpus_per_node == 0 ? curr_cpus : cpus_per_node;
+        if (cpus_per_node != curr_cpus)
+            return 0;
+    }
+    return cpus_per_node;
+}
+
+/* Get all the placement candidates satisfying some specific conditions */
+int libxl__get_numa_candidates(libxl__gc *gc,
+                               uint32_t min_free_memkb, int min_cpus,
+                               int min_nodes, int max_nodes,
+                               libxl__numa_candidate *cndts[], int *nr_cndts)
+{
+    libxl__numa_candidate *new_cndts = NULL;
+    libxl_cputopology *tinfo = NULL;
+    libxl_numainfo *ninfo = NULL;
+    libxl_bitmap nodemap;
+    int nr_nodes, nr_cpus;
+    int array_size, rc;
+
+    /* Get platform info and prepare the map for testing the combinations */
+    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
+    if (ninfo == NULL)
+        return ERROR_FAIL;
+    /* If we don't have at least 2 nodes, it is useless to proceed */
+    if (nr_nodes < 2) {
+        rc = 0;
+        goto out;
+    }
+
+    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus);
+    if (tinfo == NULL) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_node_bitmap_alloc(CTX, &nodemap);
+    if (rc)
+        goto out;
+
+    /*
+     * Round up and down some of the constraints. For instance, the minimum
+     * number of cpus a candidate should have must at least be non-negative.
+     * Regarding the minimum number of NUMA nodes, if 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
+     * from 1 otherwise). The maximum number of nodes should not exceed the
+     * number of existent NUMA nodes on the host, or the candidate genaration
+     * won't work properly.
+     */
+    min_cpus = min_cpus <= 0 ? 0 : min_cpus;
+    if (min_nodes <= 0) {
+        int cpus_per_node;
+
+        cpus_per_node = cpus_per_node_count(tinfo, nr_cpus, ninfo, nr_nodes);
+        if (cpus_per_node == 0)
+            min_nodes = 1;
+        else
+            min_nodes = (min_cpus + cpus_per_node - 1) / cpus_per_node;
+    }
+    min_nodes = min_nodes > nr_nodes ? nr_nodes : min_nodes;
+    if (max_nodes <= 0)
+        max_nodes = nr_nodes;
+    else
+        max_nodes = max_nodes > nr_nodes ? nr_nodes : max_nodes;
+    if (min_nodes > max_nodes) {
+        rc = ERROR_INVAL;
+        goto out;
+    }
+
+    /* Initialize the local storage for the combinations */
+    *nr_cndts = 0;
+    array_size = nr_nodes;
+    GCNEW_ARRAY(new_cndts, array_size);
+
+    /* Generate all the combinations of any size from min_nodes to
+     * max_nodes (see comb_init() and comb_next()). */
+    while (min_nodes <= max_nodes) {
+        comb_iter_t comb_iter;
+        int comb_ok;
+
+        /*
+	 * And here it is. Each step of this cycle generates a combination of
+	 * nodes as big as min_nodes mandates.  Each of these combinations is
+	 * checked against the constraints provided by the caller (namely,
+	 * amount of free memory and number of cpus) and it becomes an actual
+	 * placement candidate iff it passes the check.
+         */
+        for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
+             comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
+            uint32_t nodes_free_memkb;
+            int nodes_cpus;
+
+            comb_get_nodemap(comb_iter, &nodemap, min_nodes);
+
+            /* If there is not enough memoy in this combination, skip it
+             * and go generating the next one... */
+            nodes_free_memkb = nodemap_to_free_memkb(ninfo, &nodemap);
+            if (min_free_memkb > 0 && nodes_free_memkb < min_free_memkb)
+                continue;
+
+            /* And the same applies if this combination is short in cpus */
+            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
+            if (min_cpus > 0 && nodes_cpus < min_cpus)
+                continue;
+
+            /*
+             * Conditions are met, we can add this combination to the
+             * NUMA placement candidates list. We first make sure there
+             * is enough space in there, and then we initialize the new
+             * candidate element with the node map corresponding to the
+             * combination we are dealing with. Memory allocation for
+             * expanding the array that hosts the list happens in chunks
+             * equal to the number of NUMA nodes in the system (to
+             * avoid allocating memory each and every time we find a
+             * new candidate).
+             */
+            if (*nr_cndts == array_size)
+                array_size += nr_nodes;
+            GCREALLOC_ARRAY(new_cndts, array_size);
+
+            libxl__numa_candidate_alloc(gc, &new_cndts[*nr_cndts]);
+            libxl__numa_candidate_put_nodemap(gc, &new_cndts[*nr_cndts],
+                                              &nodemap);
+            new_cndts[*nr_cndts].nr_domains =
+                                    nodemap_to_nr_domains(gc, tinfo, &nodemap);
+            new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
+            new_cndts[*nr_cndts].nr_nodes = min_nodes;
+            new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
+
+            LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
+                       "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
+                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
+                       new_cndts[*nr_cndts].free_memkb / 1024);
+
+            (*nr_cndts)++;
+        }
+        min_nodes++;
+    }
+
+    *cndts = new_cndts;
+ out:
+    libxl_bitmap_dispose(&nodemap);
+    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_numainfo_list_free(ninfo, nr_nodes);
+    return rc;
+}
+
+void libxl__sort_numa_candidates(libxl__numa_candidate cndts[], int nr_cndts,
+                                 libxl__numa_candidate_cmpf cmpf)
+{
+    /* Reorder candidates (see the comparison function for
+     * the details on the heuristics) */
+    qsort(cndts, nr_cndts, sizeof(cndts[0]), cmpf);
+}
+
+/*
+ * The NUMA placement candidates are reordered according to the following
+ * heuristics:
+ *  - candidates involving fewer nodes come first. In case two (or
+ *    more) candidates span the same number of nodes,
+ *  - candidates with greater amount of free memory come first. In
+ *    case two (or more) candidates differ in their amount of free
+ *    memory by less than 10%,
+ *  - candidates with fewer domains insisting on them at the time of
+ *    this call come first.
+ */
+static int numa_cmpf(const void *v1, const void *v2)
+{
+    const libxl__numa_candidate *c1 = (const libxl__numa_candidate*) v1;
+    const libxl__numa_candidate *c2 = (const libxl__numa_candidate*) v2;
+    double mem_diff = labs(c1->free_memkb - c2->free_memkb);
+    double mem_avg = (c1->free_memkb + c2->free_memkb) / 2.0;
+
+    if (c1->nr_nodes != c2->nr_nodes)
+        return c1->nr_nodes - c2->nr_nodes;
+
+    if ((mem_diff / mem_avg) * 100.0 < 10.0 &&
+        c1->nr_domains != c2->nr_domains)
+        return c1->nr_domains - c2->nr_domains;
+
+    return c2->free_memkb - c1->free_memkb;
+}
+
+/* The actual automatic NUMA placement routine */
+static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
+{
+    int nr_candidates = 0;
+    libxl__numa_candidate *candidates = NULL;
+    libxl_bitmap candidate_nodemap;
+    libxl_cpupoolinfo *pinfo;
+    int nr_pools, rc = 0;
+    uint32_t memkb;
+
+    /* First of all, if cpupools are in use, better not to mess with them */
+    pinfo = libxl_list_cpupool(CTX, &nr_pools);
+    if (!pinfo)
+        return ERROR_FAIL;
+    if (nr_pools > 1) {
+        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
+        goto out;
+    }
+
+    rc = libxl_domain_need_memory(CTX, info, &memkb);
+    if (rc)
+        goto out;
+    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    /* Find all the candidates with enough free memory and at least
+     * as much pcpus as the domain has vcpus.  */
+    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
+                                    &candidates, &nr_candidates);
+    if (rc)
+        goto out;
+
+    LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates);
+
+    /* No suitable placement candidates. We just return without touching the
+     * domain's info->cpumap. It will have affinity with all nodes/cpus. */
+    if (nr_candidates == 0)
+        goto out;
+
+    /* Bring the best candidate in front of the list --> candidates[0] */
+    if (nr_candidates > 1)
+        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);
+
+    /*
+     * At this point, the first candidate in the array is the one we want.
+     * Go for it by mapping its node map to the domain's info->cpumap.
+     */
+    libxl__numa_candidate_get_nodemap(gc, &candidates[0], &candidate_nodemap);
+    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
+    if (rc)
+        goto out;
+
+    LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
+                "%"PRIu32" KB free selected", candidates[0].nr_nodes,
+                candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
+
+ out:
+    libxl_bitmap_dispose(&candidate_nodemap);
+    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
+    return rc;
+}
+
 int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
@@ -104,7 +557,22 @@ int libxl__build_pre(libxl__gc *gc, uint
     uint32_t rtc_timeoffset;
 
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+
+    /*
+     * 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 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,
+     * whatever that turns out to be.
+     */
+    if (libxl_bitmap_is_full(&info->cpumap)) {
+        int rc = numa_place_domain(gc, info);
+        if (rc)
+            return rc;
+    }
     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,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
 #define CTX_LOCK (libxl__ctx_lock(CTX))
 #define CTX_UNLOCK (libxl__ctx_unlock(CTX))
 
+/*
+ * Automatic NUMA placement
+ *
+ * These functions and data structures deal with the initial placement of a
+ * domain onto the host NUMA nodes.
+ *
+ * The key concept here is the one of "numa placement candidate" (or jusr "numa
+ * candidate", "placement candidate" or even "candidate"), which basically is a
+ * set of nodes whose characteristics have been successfully checked against
+ * some specific requirements. More pecisely, a candidate is the nodemap
+ * associated with one of the possible subset of the host NUMA nodes providing
+ * a certain amount of free memory, or a given number of cpus, or even both
+ * (depending in what the caller wants). For convenience of use, some of this
+ * information are stored within the candidate itselfs, instead of always being
+ * dynamically computed. A candidate can consist of just one, up to all the
+ * available nodes on the host (the latter being, of course, not ideal).  For
+ * instance, looking for a numa candidates with 2GB of free memoy means we want
+ * all the possible subsets of the host NUMA nodes with, cumulatively, at least
+ * 2GB of free memory. That could be possible by just using one particular
+ * node, or may require more nodes, depending on the characteristics of the
+ * host, on how many domains have been created already, on how big they are,
+ * etc.
+ *
+ * The intended usage is as follows:
+ *  1. by, fist of all, calling libxl__get_numa_candidates(), and specifying
+ *     the proper constraints to it (e.g., the amount of memory a domain need
+ *     as the minimum amount of free memory fo the candidates) one can build
+ *     up a whole set of suitable placing alternatives for a domain;
+ *  2. after that, one specific candidate should be chosen. That can happen
+ *     by looking at their various characteristics;
+ *  3. the chosen candidate's nodemap should be utilized for computing the
+ *     actual affinity of the domain which, given the curent NUMA support
+ *     in the hypervisor, is what determines the placement of the domain's
+ *     vcpus and memory.
+ *
+ * To make phase 2 even easier, a sorting helper function for the list of
+ * candidates is povided in the form of libxl__sort_numa_candidates(). The only
+ * that is needed is defining a comparison function, containing the chriteria
+ * for deciding, given two candidates, which one is 'better'. Depending on how
+ * the comparison function is defined, the best candidate (where, of course,
+ * best is defined with respect to the heuristics implemented in the comparison
+ * function itself, libxl__numa_candidate_cmpf()) could become the first o the
+ * last element of the list.
+ *
+ * Summarizing, achieving automatic NUMA placement is just a matter of
+ * obtaining the list of suitable placement candidates, perhaps asking for each
+ * of them to provide at least the amount of memory the domain needs. After
+ * that just implement a comparison function by means of the various helpers
+ * retrieving the relevant information about the candidates themselves.
+ * Finally, call the sorting helper function and use the candidate that became
+ * (typically) the first element of the list fo determining the domain's
+ * affinity.
+ */
+
+typedef struct {
+    int nr_cpus, nr_nodes;
+    int nr_domains;
+    uint32_t free_memkb;
+    libxl_bitmap nodemap;
+} libxl__numa_candidate;
+
+/*
+ * This generates the list of NUMA placement candidates satisfying some
+ * specific conditions. If min_nodes and/or max_nodes are not 0, their value is
+ * used to determine the minimum and maximum number of nodes that are allow to
+ * be present in each candidate. If min_nodes and/or max_nodes are 0, the
+ * minimum and maximum number of nodes to be used are automatically selected by
+ * the implementation (and that will likely be just 1 node for the minimum and
+ * the total number of existent nodes for the maximum). Re min_free_memkb and
+ * min_cpu, if not 0, they specify the caller only wants candidates with at
+ * least that amount of free memory and that number of cpus, respectively. If
+ * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
+ * of cpus won't be checked at all, which means a candidate will always be
+ * considered suitable wrt the specific constraint.  cndts is where the list of
+ * exactly nr_cndts candidates is returned. Note that, in case no candidates
+ * are found at all, the function returns successfully, but with nr_cndts equal
+ * to zero.
+ */
+_hidden int libxl__get_numa_candidates(libxl__gc *gc,
+                                uint32_t min_free_memkb, int min_cpus,
+                                int min_nodes, int max_nodes,
+                                libxl__numa_candidate *cndts[], int *nr_cndts);
+
+/* allocation and deallocation for placement candidates */
+static inline int libxl__numa_candidate_alloc(libxl__gc *gc,
+                                              libxl__numa_candidate *cndt)
+{
+    return libxl_node_bitmap_alloc(CTX, &cndt->nodemap);
+}
+static inline void libxl__numa_candidate_dispose(libxl__numa_candidate *cndt)
+{
+    libxl_bitmap_dispose(&cndt->nodemap);
+}
+static inline void libxl__numacandidate_list_free(libxl__numa_candidate *cndts,
+                                                  int nr_cndts)
+{
+    int i;
+
+    for (i = 0; i < nr_cndts; i++)
+        libxl__numa_candidate_dispose(&cndts[i]);
+    free(cndts);
+}
+
+/* retrieve (in nodemap) the node map associated to placement candidate cndt */
+static inline
+void libxl__numa_candidate_get_nodemap(libxl__gc *gc,
+                                       const libxl__numa_candidate *cndt,
+                                       libxl_bitmap *nodemap)
+{
+    libxl_bitmap_copy(CTX, nodemap, &cndt->nodemap);
+}
+/* set the node map of placement candidate cndt to match nodemap */
+static inline
+void libxl__numa_candidate_put_nodemap(libxl__gc *gc,
+                                       libxl__numa_candidate *cndt,
+                                       const libxl_bitmap *nodemap)
+{
+    libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap);
+}
+
+/* signature for the comparison function between two candidates c1 and c2
+ * (the thid parameter is provided to enable thread safety). */
+typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2);
+/* sort the list of candidates in cndts (an array with nr_cndts elements in
+ * it) using cmpf for comparing two candidates. Uses libc's qsort(). */
+_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
+                                         int nr_cndts,
+                                         libxl__numa_candidate_cmpf cmpf);
 
 /*
  * Inserts "elm_new" into the sorted list "head".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxz-00054Z-3U; Fri, 15 Jun 2012 17:05:47 +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 1SfZxx-00053O-Io
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:45 +0000
Received: from [85.158.139.83:22406] by server-7.bemta-5.messagelabs.com id
	04/D7-28276-86B6BDF4; Fri, 15 Jun 2012 17:05:44 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!4
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28261 invoked from network); 15 Jun 2012 17:05:44 -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;
	15 Jun 2012 17:05:44 -0000
Received: by mail-wi0-f173.google.com with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=lFWxYYXWZ172V9K73Fj19QaxE9NM3CGBIrlw3mFVGbA=;
	b=r9YOGjjk8RCAmrrOgOaYJ/TRVt2vACcBn+EGNpQKeCcT1WczrxNV07I1N6v5Klm5Ip
	u//45xo9gSz9ieaihKQR1jWHKWmRTCedwuGxgnJ/ReyY9vBMdVADRSmQ1UdwBpP3/P59
	AhBkhAcKHWerVyOy8++1EiyNjO6mVghQFq6vIccu48J7KpyjorCm/WH9uOMyMHsuXqLy
	9Vqeq7/5YOF0gEVxNml6V7lFMM48CS1Rhs/WRw+9BTtuW3YeWB9vYqePHZ7LXxdnIRiL
	W4DrvyUUXb9iCU9ZqZcfMtGmbK2/Xplrrp6B/bzYDNLfuwe+XrSw+g0vPdj3qDFFs2u3
	wYlA==
Received: by 10.180.109.197 with SMTP id hu5mr6006366wib.8.1339779943908;
	Fri, 15 Jun 2012 10:05:43 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:42 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 0e566a40afad1e3dc299bed8193a3b9483483d4b
Message-Id: <0e566a40afad1e3dc299.1339779878@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:38 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

About rationale, usage and (some small bits of) API.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * API documentation moved close to the actual functions.

diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
new file mode 100644
--- /dev/null
+++ b/docs/misc/xl-numa-placement.markdown
@@ -0,0 +1,74 @@
+# Guest Automatic NUMA Placement in libxl and xl #
+
+## Rationale ##
+
+The Xen hypervisor deals with Non-Uniform Memory Access (NUMA])
+machines by assigning to its domain a "node affinity", i.e., a set of NUMA
+nodes of the host from which it gets its memory allocated.
+
+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 ##
+
+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).
+
+### Manual Guest Placement with xl ###
+
+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
+affects NUMA placement and memory accesses as the hypervisor constructs
+the node affinity of a VM basing right on its CPU affinity when it is
+created.
+
+This is very simple and effective, but requires the user/system
+administrator to explicitly specify affinities for each and every domain,
+or Xen won't be able to enable guarantee the locality for their memory
+accesses.
+
+### Automatic Guest Placement with xl ###
+
+In case no "cpus=" option is specified in the config file, xl tries
+to figure out on its own on which node(s) the domain could fit best.
+
+First of all, it needs to find a node (or a set of nodes) that have
+enough free memory for accommodating the domain. After that, the actual
+decision on where to put the new guest happens by generating all the
+possible combinations of nodes that satisfies the above and chose among
+them according to the following heuristics:
+
+  *  candidates involving fewer nodes come first. In case two (or more)
+     candidates span the same number of nodes,
+  *  candidates with greater amount of free memory come first. In case
+     two (or more) candidates differ in their amount of free memory by
+     less than 10%,
+  *  candidates with fewer domains already placed on them come first.
+
+Giving preference to small candidates ensures better performance for
+the guest, as it avoid spreading its memory among different nodes.
+Using the nodes that have the biggest amounts of free memory helps
+keeping the memory fragmentation small, from a system wide perspective.
+Finally, in case more candidates fulfil these criteria by the same
+extent, choosing the candidate that is hosting fewer domain helps
+balancing the load on the various nodes.
+
+The last step is figuring out whether the selected candidate contains
+at least as much CPUs as the number of VCPUs of the VM. The current
+solution for the case when this is not verified is just to add some
+more nodes, until the condition turns into being true. When doing
+this, the nodes with the least possible distance from the ones
+already in the nodemap are considered.
+
+## Guest Placement within libxl ##
+
+xl achieves automatic NUMA placement by means of the following API
+calls, provided by libxl.
+
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:05:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SfZxz-00054Z-3U; Fri, 15 Jun 2012 17:05:47 +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 1SfZxx-00053O-Io
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:05:45 +0000
Received: from [85.158.139.83:22406] by server-7.bemta-5.messagelabs.com id
	04/D7-28276-86B6BDF4; Fri, 15 Jun 2012 17:05:44 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1339779920!23648105!4
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28261 invoked from network); 15 Jun 2012 17:05:44 -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;
	15 Jun 2012 17:05:44 -0000
Received: by mail-wi0-f173.google.com with SMTP id hj6so680165wib.14
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:05:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=lFWxYYXWZ172V9K73Fj19QaxE9NM3CGBIrlw3mFVGbA=;
	b=r9YOGjjk8RCAmrrOgOaYJ/TRVt2vACcBn+EGNpQKeCcT1WczrxNV07I1N6v5Klm5Ip
	u//45xo9gSz9ieaihKQR1jWHKWmRTCedwuGxgnJ/ReyY9vBMdVADRSmQ1UdwBpP3/P59
	AhBkhAcKHWerVyOy8++1EiyNjO6mVghQFq6vIccu48J7KpyjorCm/WH9uOMyMHsuXqLy
	9Vqeq7/5YOF0gEVxNml6V7lFMM48CS1Rhs/WRw+9BTtuW3YeWB9vYqePHZ7LXxdnIRiL
	W4DrvyUUXb9iCU9ZqZcfMtGmbK2/Xplrrp6B/bzYDNLfuwe+XrSw+g0vPdj3qDFFs2u3
	wYlA==
Received: by 10.180.109.197 with SMTP id hu5mr6006366wib.8.1339779943908;
	Fri, 15 Jun 2012 10:05:43 -0700 (PDT)
Received: from [127.0.1.1] (ip-183-142.sn1.eutelia.it. [62.94.183.142])
	by mx.google.com with ESMTPS id n6sm7090595wie.7.2012.06.15.10.05.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 15 Jun 2012 10:05:42 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 0e566a40afad1e3dc299bed8193a3b9483483d4b
Message-Id: <0e566a40afad1e3dc299.1339779878@Solace>
In-Reply-To: <patchbomb.1339779868@Solace>
References: <patchbomb.1339779868@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 15 Jun 2012 19:04:38 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

About rationale, usage and (some small bits of) API.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Changes from v1:
 * API documentation moved close to the actual functions.

diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
new file mode 100644
--- /dev/null
+++ b/docs/misc/xl-numa-placement.markdown
@@ -0,0 +1,74 @@
+# Guest Automatic NUMA Placement in libxl and xl #
+
+## Rationale ##
+
+The Xen hypervisor deals with Non-Uniform Memory Access (NUMA])
+machines by assigning to its domain a "node affinity", i.e., a set of NUMA
+nodes of the host from which it gets its memory allocated.
+
+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 ##
+
+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).
+
+### Manual Guest Placement with xl ###
+
+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
+affects NUMA placement and memory accesses as the hypervisor constructs
+the node affinity of a VM basing right on its CPU affinity when it is
+created.
+
+This is very simple and effective, but requires the user/system
+administrator to explicitly specify affinities for each and every domain,
+or Xen won't be able to enable guarantee the locality for their memory
+accesses.
+
+### Automatic Guest Placement with xl ###
+
+In case no "cpus=" option is specified in the config file, xl tries
+to figure out on its own on which node(s) the domain could fit best.
+
+First of all, it needs to find a node (or a set of nodes) that have
+enough free memory for accommodating the domain. After that, the actual
+decision on where to put the new guest happens by generating all the
+possible combinations of nodes that satisfies the above and chose among
+them according to the following heuristics:
+
+  *  candidates involving fewer nodes come first. In case two (or more)
+     candidates span the same number of nodes,
+  *  candidates with greater amount of free memory come first. In case
+     two (or more) candidates differ in their amount of free memory by
+     less than 10%,
+  *  candidates with fewer domains already placed on them come first.
+
+Giving preference to small candidates ensures better performance for
+the guest, as it avoid spreading its memory among different nodes.
+Using the nodes that have the biggest amounts of free memory helps
+keeping the memory fragmentation small, from a system wide perspective.
+Finally, in case more candidates fulfil these criteria by the same
+extent, choosing the candidate that is hosting fewer domain helps
+balancing the load on the various nodes.
+
+The last step is figuring out whether the selected candidate contains
+at least as much CPUs as the number of VCPUs of the VM. The current
+solution for the case when this is not verified is just to add some
+more nodes, until the condition turns into being true. When doing
+this, the nodes with the least possible distance from the ones
+already in the nodemap are considered.
+
+## Guest Placement within libxl ##
+
+xl achieves automatic NUMA placement by means of the following API
+calls, provided by libxl.
+
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 17:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:06: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 1SfZyZ-0005Rz-Ig; Fri, 15 Jun 2012 17:06:23 +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 1SfZyX-0005Qz-FF
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:06:21 +0000
Received: from [85.158.143.99:49201] by server-3.bemta-4.messagelabs.com id
	8E/42-05808-C8B6BDF4; Fri, 15 Jun 2012 17:06:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779980!22329986!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 15 Jun 2012 17:06:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:06:20 -0000
Received: by eekd41 with SMTP id d41so1130504eek.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:06:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=IiBplunTALfVWjG7k3597uxR/lob/lPUVsPrDe7hFao=;
	b=Isqk/slxad/BD5Z+XFfYJoj+1A7O0VNzPh3axIfHXk75qjQG0+Dae8hqz2fmptajek
	KCUzKeXVcz+pyRw+fo9PLM/AkjJLKKF4mveDK29h1HsYxJRpbKhU8OoMJQ9oxw3aK6uq
	vicIduGtXE6GPjtOngOU1MwbOeOM6HyBA9GCqxqaKzJbvngnXEtBiamXX/AS4LtmJiww
	jfVQw3cqBkUtLIQCp0BH87GWig0PnrofwIoi6hCaZQSh4ywL0CpRad+BBQrA5IuuxqKi
	rMCjo01CvKu0WLsdPookGsb/W405BKIhn1S0WvtYfP8kyybqHdSMWr1+V8SwCwf2EAmU
	df0A==
Received: by 10.14.98.68 with SMTP id u44mr1566805eef.85.1339779979886;
	Fri, 15 Jun 2012 10:06:19 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id c42sm33020297eeb.2.2012.06.15.10.06.18
	(version=SSLv3 cipher=OTHER); Fri, 15 Jun 2012 10:06:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 15 Jun 2012 18:06:14 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC012A16.43075%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1LGSuEKVvv/Doy70esNYKw3ANvug==
In-Reply-To: <4FDB790F020000780008A406@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:

> While pv-ops so far doesn't care to eliminate the two trap-and-
> emulate CR0 accesses from the asm/xor.h save/restore
> operations, the legacy x86-64 kernel uses conditional clts()/stts()
> for this purpose. While looking into whether to extend this to the
> newly added (in 3.5) AVX operations there I realized that this isn't
> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
> kernel_fpu_end() pair (as it will stts() at the end no matter what
> the original state of CR0.TS was).
> 
> In order to not introduce completely new hypercalls to overcome
> this (fpu_taskswitch isn't really extensible on its own), I'm
> considering to add a new VM assist, altering the fpu_taskswitch
> behavior so that it would return an indicator whether any change
> to the virtual CR0.TS was done. That way, the kernel can
> implement a true save/restore cycle here.

It should be possible for the guest kernel to track its CR0.TS setting
shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
cleared on #NM.

 -- Keir

> In order to allow the kernel to run on older hypervisors without
> extra conditionals (behaving the same way as it does currently,
> i.e. with the incorrect nesting), the return value 0 (which the
> hypercall currently always returns) would need to be used to
> indicate that the bit got actually flipped (such that on an old
> hypervisor an updated kernel would always think that
> something needs to be restored).
> 
> Would that be an acceptable solution? Can someone think of
> other ways to deal with this? (And - is pv-ops interested in
> eliminating the two CR0 access emulations in what is supposed
> to be a fast path?)
> 
> 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 Fri Jun 15 17:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 17:06: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 1SfZyZ-0005Rz-Ig; Fri, 15 Jun 2012 17:06:23 +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 1SfZyX-0005Qz-FF
	for xen-devel@lists.xen.org; Fri, 15 Jun 2012 17:06:21 +0000
Received: from [85.158.143.99:49201] by server-3.bemta-4.messagelabs.com id
	8E/42-05808-C8B6BDF4; Fri, 15 Jun 2012 17:06:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1339779980!22329986!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 15 Jun 2012 17:06:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 17:06:20 -0000
Received: by eekd41 with SMTP id d41so1130504eek.32
	for <xen-devel@lists.xen.org>; Fri, 15 Jun 2012 10:06:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=IiBplunTALfVWjG7k3597uxR/lob/lPUVsPrDe7hFao=;
	b=Isqk/slxad/BD5Z+XFfYJoj+1A7O0VNzPh3axIfHXk75qjQG0+Dae8hqz2fmptajek
	KCUzKeXVcz+pyRw+fo9PLM/AkjJLKKF4mveDK29h1HsYxJRpbKhU8OoMJQ9oxw3aK6uq
	vicIduGtXE6GPjtOngOU1MwbOeOM6HyBA9GCqxqaKzJbvngnXEtBiamXX/AS4LtmJiww
	jfVQw3cqBkUtLIQCp0BH87GWig0PnrofwIoi6hCaZQSh4ywL0CpRad+BBQrA5IuuxqKi
	rMCjo01CvKu0WLsdPookGsb/W405BKIhn1S0WvtYfP8kyybqHdSMWr1+V8SwCwf2EAmU
	df0A==
Received: by 10.14.98.68 with SMTP id u44mr1566805eef.85.1339779979886;
	Fri, 15 Jun 2012 10:06:19 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id c42sm33020297eeb.2.2012.06.15.10.06.18
	(version=SSLv3 cipher=OTHER); Fri, 15 Jun 2012 10:06:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 15 Jun 2012 18:06:14 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC012A16.43075%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1LGSuEKVvv/Doy70esNYKw3ANvug==
In-Reply-To: <4FDB790F020000780008A406@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:

> While pv-ops so far doesn't care to eliminate the two trap-and-
> emulate CR0 accesses from the asm/xor.h save/restore
> operations, the legacy x86-64 kernel uses conditional clts()/stts()
> for this purpose. While looking into whether to extend this to the
> newly added (in 3.5) AVX operations there I realized that this isn't
> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
> kernel_fpu_end() pair (as it will stts() at the end no matter what
> the original state of CR0.TS was).
> 
> In order to not introduce completely new hypercalls to overcome
> this (fpu_taskswitch isn't really extensible on its own), I'm
> considering to add a new VM assist, altering the fpu_taskswitch
> behavior so that it would return an indicator whether any change
> to the virtual CR0.TS was done. That way, the kernel can
> implement a true save/restore cycle here.

It should be possible for the guest kernel to track its CR0.TS setting
shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
cleared on #NM.

 -- Keir

> In order to allow the kernel to run on older hypervisors without
> extra conditionals (behaving the same way as it does currently,
> i.e. with the incorrect nesting), the return value 0 (which the
> hypercall currently always returns) would need to be used to
> indicate that the bit got actually flipped (such that on an old
> hypervisor an updated kernel would always think that
> something needs to be restored).
> 
> Would that be an acceptable solution? Can someone think of
> other ways to deal with this? (And - is pv-ops interested in
> eliminating the two CR0 access emulations in what is supposed
> to be a fast path?)
> 
> 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 Fri Jun 15 18:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 18: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 1SfbO6-0008CQ-Mn; Fri, 15 Jun 2012 18:36: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 1SfbO4-0008CL-La
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 18:36:49 +0000
Received: from [85.158.143.99:24283] by server-2.bemta-4.messagelabs.com id
	96/2D-17938-0C08BDF4; Fri, 15 Jun 2012 18:36:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339785407!16386480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32005 invoked from network); 15 Jun 2012 18:36:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 18:36:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13052347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 18:36:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 19:36:46 +0100
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 1SfbO2-0008HN-Be;
	Fri, 15 Jun 2012 18:36:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SfbO2-0005ZT-0g;
	Fri, 15 Jun 2012 19:36:46 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13048-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 19:36:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13048: 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 13048 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13048/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13017

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                26a7895e70104811258cf023d06a21f92ab590c6
baseline version:
 linux                6102ace32239ad2174ffbb7d60be8dafee7341a1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=26a7895e70104811258cf023d06a21f92ab590c6
+ . 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 26a7895e70104811258cf023d06a21f92ab590c6
+ branch=linux-3.0
+ revision=26a7895e70104811258cf023d06a21f92ab590c6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 26a7895e70104811258cf023d06a21f92ab590c6:tested/linux-3.0
Counting objects: 1   
Counting objects: 272   
Counting objects: 389, done.
Compressing objects:   2% (1/50)   
Compressing objects:   4% (2/50)   
Compressing objects:   6% (3/50)   
Compressing objects:   8% (4/50)   
Compressing objects:  10% (5/50)   
Compressing objects:  12% (6/50)   
Compressing objects:  14% (7/50)   
Compressing objects:  16% (8/50)   
Compressing objects:  18% (9/50)   
Compressing objects:  20% (10/50)   
Compressing objects:  22% (11/50)   
Compressing objects:  24% (12/50)   
Compressing objects:  26% (13/50)   
Compressing objects:  28% (14/50)   
Compressing objects:  30% (15/50)   
Compressing objects:  32% (16/50)   
Compressing objects:  34% (17/50)   
Compressing objects:  36% (18/50)   
Compressing objects:  38% (19/50)   
Compressing objects:  40% (20/50)   
Compressing objects:  42% (21/50)   
Compressing objects:  44% (22/50)   
Compressing objects:  46% (23/50)   
Compressing objects:  48% (24/50)   
Compressing objects:  50% (25/50)   
Compressing objects:  52% (26/50)   
Compressing objects:  54% (27/50)   
Compressing objects:  56% (28/50)   
Compressing objects:  58% (29/50)   
Compressing objects:  60% (30/50)   
Compressing objects:  62% (31/50)   
Compressing objects:  64% (32/50)   
Compressing objects:  66% (33/50)   
Compressing objects:  68% (34/50)   
Compressing objects:  70% (35/50)   
Compressing objects:  72% (36/50)   
Compressing objects:  74% (37/50)   
Compressing objects:  76% (38/50)   
Compressing objects:  78% (39/50)   
Compressing objects:  80% (40/50)   
Compressing objects:  82% (41/50)   
Compressing objects:  84% (42/50)   
Compressing objects:  86% (43/50)   
Compressing objects:  88% (44/50)   
Compressing objects:  90% (45/50)   
Compressing objects:  92% (46/50)   
Compressing objects:  94% (47/50)   
Compressing objects:  96% (48/50)   
Compressing objects:  98% (49/50)   
Compressing objects: 100% (50/50)   
Compressing objects: 100% (50/50), done.
Writing objects:   0% (1/292)   
Writing objects:   1% (3/292)   
Writing objects:   2% (6/292)   
Writing objects:   3% (9/292)   
Writing objects:   4% (12/292)   
Writing objects:   5% (15/292)   
Writing objects:   6% (18/292)   
Writing objects:   7% (21/292)   
Writing objects:   8% (24/292)   
Writing objects:   9% (28/292)   
Writing objects:  10% (32/292)   
Writing objects:  11% (34/292)   
Writing objects:  12% (36/292)   
Writing objects:  13% (38/292)   
Writing objects:  14% (41/292)   
Writing objects:  15% (44/292)   
Writing objects:  16% (47/292)   
Writing objects:  17% (50/292)   
Writing objects:  18% (53/292)   
Writing objects:  19% (56/292)   
Writing objects:  20% (59/292)   
Writing objects:  21% (62/292)   
Writing objects:  22% (65/292)   
Writing objects:  23% (68/292)   
Writing objects:  24% (71/292)   
Writing objects:  25% (73/292)   
Writing objects:  26% (76/292)   
Writing objects:  27% (79/292)   
Writing objects:  28% (82/292)   
Writing objects:  29% (85/292)   
Writing objects:  30% (88/292)   
Writing objects:  31% (91/292)   
Writing objects:  32% (94/292)   
Writing objects:  33% (97/292)   
Writing objects:  34% (100/292)   
Writing objects:  35% (103/292)   
Writing objects:  36% (106/292)   
Writing objects:  37% (109/292)   
Writing objects:  38% (111/292)   
Writing objects:  39% (114/292)   
Writing objects:  40% (117/292)   
Writing objects:  41% (120/292)   
Writing objects:  42% (123/292)   
Writing objects:  43% (126/292)   
Writing objects:  44% (129/292)   
Writing objects:  45% (132/292)   
Writing objects:  46% (135/292)   
Writing objects:  47% (138/292)   
Writing objects:  48% (141/292)   
Writing objects:  49% (144/292)   
Writing objects:  50% (146/292)   
Writing objects:  51% (149/292)   
Writing objects:  52% (152/292)   
Writing objects:  53% (155/292)   
Writing objects:  54% (158/292)   
Writing objects:  55% (161/292)   
Writing objects:  56% (164/292)   
Writing objects:  57% (167/292)   
Writing objects:  58% (170/292)   
Writing objects:  59% (173/292)   
Writing objects:  60% (176/292)   
Writing objects:  61% (179/292)   
Writing objects:  62% (182/292)   
Writing objects:  63% (184/292)   
Writing objects:  64% (187/292)   
Writing objects:  65% (190/292)   
Writing objects:  66% (193/292)   
Writing objects:  67% (196/292)   
Writing objects:  68% (199/292)   
Writing objects:  69% (202/292)   
Writing objects:  70% (205/292)   
Writing objects:  71% (208/292)   
Writing objects:  72% (211/292)   
Writing objects:  73% (214/292)   
Writing objects:  74% (217/292)   
Writing objects:  75% (219/292)   
Writing objects:  76% (222/292)   
Writing objects:  77% (225/292)   
Writing objects:  78% (228/292)   
Writing objects:  79% (231/292)   
Writing objects:  80% (234/292)   
Writing objects:  81% (237/292)   
Writing objects:  82% (240/292)   
Writing objects:  83% (243/292)   
Writing objects:  84% (246/292)   
Writing objects:  85% (249/292)   
Writing objects:  86% (252/292)   
Writing objects:  87% (255/292)   
Writing objects:  88% (257/292)   
Writing objects:  89% (260/292)   
Writing objects:  90% (263/292)   
Writing objects:  91% (266/292)   
Writing objects:  92% (269/292)   
Writing objects:  93% (272/292)   
Writing objects:  94% (275/292)   
Writing objects:  95% (278/292)   
Writing objects:  96% (281/292)   
Writing objects:  97% (284/292)   
Writing objects:  98% (287/292)   
Writing objects:  99% (290/292)   
Writing objects: 100% (292/292)   
Writing objects: 100% (292/292), 50.76 KiB, done.
Total 292 (delta 241), reused 292 (delta 241)
To xen@xenbits.xensource.com:git/linux-pvops.git
   6102ace..26a7895  26a7895e70104811258cf023d06a21f92ab590c6 -> 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 Fri Jun 15 18:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 18: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 1SfbO6-0008CQ-Mn; Fri, 15 Jun 2012 18:36: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 1SfbO4-0008CL-La
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 18:36:49 +0000
Received: from [85.158.143.99:24283] by server-2.bemta-4.messagelabs.com id
	96/2D-17938-0C08BDF4; Fri, 15 Jun 2012 18:36:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1339785407!16386480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32005 invoked from network); 15 Jun 2012 18:36:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 18:36:47 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13052347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 18:36:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 19:36:46 +0100
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 1SfbO2-0008HN-Be;
	Fri, 15 Jun 2012 18:36:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SfbO2-0005ZT-0g;
	Fri, 15 Jun 2012 19:36:46 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13048-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 19:36:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13048: 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 13048 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13048/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13017

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                26a7895e70104811258cf023d06a21f92ab590c6
baseline version:
 linux                6102ace32239ad2174ffbb7d60be8dafee7341a1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=26a7895e70104811258cf023d06a21f92ab590c6
+ . 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 26a7895e70104811258cf023d06a21f92ab590c6
+ branch=linux-3.0
+ revision=26a7895e70104811258cf023d06a21f92ab590c6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 26a7895e70104811258cf023d06a21f92ab590c6:tested/linux-3.0
Counting objects: 1   
Counting objects: 272   
Counting objects: 389, done.
Compressing objects:   2% (1/50)   
Compressing objects:   4% (2/50)   
Compressing objects:   6% (3/50)   
Compressing objects:   8% (4/50)   
Compressing objects:  10% (5/50)   
Compressing objects:  12% (6/50)   
Compressing objects:  14% (7/50)   
Compressing objects:  16% (8/50)   
Compressing objects:  18% (9/50)   
Compressing objects:  20% (10/50)   
Compressing objects:  22% (11/50)   
Compressing objects:  24% (12/50)   
Compressing objects:  26% (13/50)   
Compressing objects:  28% (14/50)   
Compressing objects:  30% (15/50)   
Compressing objects:  32% (16/50)   
Compressing objects:  34% (17/50)   
Compressing objects:  36% (18/50)   
Compressing objects:  38% (19/50)   
Compressing objects:  40% (20/50)   
Compressing objects:  42% (21/50)   
Compressing objects:  44% (22/50)   
Compressing objects:  46% (23/50)   
Compressing objects:  48% (24/50)   
Compressing objects:  50% (25/50)   
Compressing objects:  52% (26/50)   
Compressing objects:  54% (27/50)   
Compressing objects:  56% (28/50)   
Compressing objects:  58% (29/50)   
Compressing objects:  60% (30/50)   
Compressing objects:  62% (31/50)   
Compressing objects:  64% (32/50)   
Compressing objects:  66% (33/50)   
Compressing objects:  68% (34/50)   
Compressing objects:  70% (35/50)   
Compressing objects:  72% (36/50)   
Compressing objects:  74% (37/50)   
Compressing objects:  76% (38/50)   
Compressing objects:  78% (39/50)   
Compressing objects:  80% (40/50)   
Compressing objects:  82% (41/50)   
Compressing objects:  84% (42/50)   
Compressing objects:  86% (43/50)   
Compressing objects:  88% (44/50)   
Compressing objects:  90% (45/50)   
Compressing objects:  92% (46/50)   
Compressing objects:  94% (47/50)   
Compressing objects:  96% (48/50)   
Compressing objects:  98% (49/50)   
Compressing objects: 100% (50/50)   
Compressing objects: 100% (50/50), done.
Writing objects:   0% (1/292)   
Writing objects:   1% (3/292)   
Writing objects:   2% (6/292)   
Writing objects:   3% (9/292)   
Writing objects:   4% (12/292)   
Writing objects:   5% (15/292)   
Writing objects:   6% (18/292)   
Writing objects:   7% (21/292)   
Writing objects:   8% (24/292)   
Writing objects:   9% (28/292)   
Writing objects:  10% (32/292)   
Writing objects:  11% (34/292)   
Writing objects:  12% (36/292)   
Writing objects:  13% (38/292)   
Writing objects:  14% (41/292)   
Writing objects:  15% (44/292)   
Writing objects:  16% (47/292)   
Writing objects:  17% (50/292)   
Writing objects:  18% (53/292)   
Writing objects:  19% (56/292)   
Writing objects:  20% (59/292)   
Writing objects:  21% (62/292)   
Writing objects:  22% (65/292)   
Writing objects:  23% (68/292)   
Writing objects:  24% (71/292)   
Writing objects:  25% (73/292)   
Writing objects:  26% (76/292)   
Writing objects:  27% (79/292)   
Writing objects:  28% (82/292)   
Writing objects:  29% (85/292)   
Writing objects:  30% (88/292)   
Writing objects:  31% (91/292)   
Writing objects:  32% (94/292)   
Writing objects:  33% (97/292)   
Writing objects:  34% (100/292)   
Writing objects:  35% (103/292)   
Writing objects:  36% (106/292)   
Writing objects:  37% (109/292)   
Writing objects:  38% (111/292)   
Writing objects:  39% (114/292)   
Writing objects:  40% (117/292)   
Writing objects:  41% (120/292)   
Writing objects:  42% (123/292)   
Writing objects:  43% (126/292)   
Writing objects:  44% (129/292)   
Writing objects:  45% (132/292)   
Writing objects:  46% (135/292)   
Writing objects:  47% (138/292)   
Writing objects:  48% (141/292)   
Writing objects:  49% (144/292)   
Writing objects:  50% (146/292)   
Writing objects:  51% (149/292)   
Writing objects:  52% (152/292)   
Writing objects:  53% (155/292)   
Writing objects:  54% (158/292)   
Writing objects:  55% (161/292)   
Writing objects:  56% (164/292)   
Writing objects:  57% (167/292)   
Writing objects:  58% (170/292)   
Writing objects:  59% (173/292)   
Writing objects:  60% (176/292)   
Writing objects:  61% (179/292)   
Writing objects:  62% (182/292)   
Writing objects:  63% (184/292)   
Writing objects:  64% (187/292)   
Writing objects:  65% (190/292)   
Writing objects:  66% (193/292)   
Writing objects:  67% (196/292)   
Writing objects:  68% (199/292)   
Writing objects:  69% (202/292)   
Writing objects:  70% (205/292)   
Writing objects:  71% (208/292)   
Writing objects:  72% (211/292)   
Writing objects:  73% (214/292)   
Writing objects:  74% (217/292)   
Writing objects:  75% (219/292)   
Writing objects:  76% (222/292)   
Writing objects:  77% (225/292)   
Writing objects:  78% (228/292)   
Writing objects:  79% (231/292)   
Writing objects:  80% (234/292)   
Writing objects:  81% (237/292)   
Writing objects:  82% (240/292)   
Writing objects:  83% (243/292)   
Writing objects:  84% (246/292)   
Writing objects:  85% (249/292)   
Writing objects:  86% (252/292)   
Writing objects:  87% (255/292)   
Writing objects:  88% (257/292)   
Writing objects:  89% (260/292)   
Writing objects:  90% (263/292)   
Writing objects:  91% (266/292)   
Writing objects:  92% (269/292)   
Writing objects:  93% (272/292)   
Writing objects:  94% (275/292)   
Writing objects:  95% (278/292)   
Writing objects:  96% (281/292)   
Writing objects:  97% (284/292)   
Writing objects:  98% (287/292)   
Writing objects:  99% (290/292)   
Writing objects: 100% (292/292)   
Writing objects: 100% (292/292), 50.76 KiB, done.
Total 292 (delta 241), reused 292 (delta 241)
To xen@xenbits.xensource.com:git/linux-pvops.git
   6102ace..26a7895  26a7895e70104811258cf023d06a21f92ab590c6 -> 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 Fri Jun 15 19:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 19: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 1SfcJj-0000I5-Vq; Fri, 15 Jun 2012 19:36: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 1SfcJi-0000I0-RX
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 19:36:23 +0000
Received: from [85.158.138.51:24859] by server-2.bemta-3.messagelabs.com id
	48/D0-31533-5BE8BDF4; Fri, 15 Jun 2012 19:36:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339788980!27965328!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24840 invoked from network); 15 Jun 2012 19:36:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 19:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13053589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 19:36:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 20:36:15 +0100
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 1SfcJa-00009N-Nt;
	Fri, 15 Jun 2012 19:36:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SfcJa-0002H3-G4;
	Fri, 15 Jun 2012 20:36:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13049-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 20:36:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13049: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13049 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13049/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 10 guest-saverestore.2 fail REGR. vs. 12957

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10  fail like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 19:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 19: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 1SfcJj-0000I5-Vq; Fri, 15 Jun 2012 19:36: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 1SfcJi-0000I0-RX
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 19:36:23 +0000
Received: from [85.158.138.51:24859] by server-2.bemta-3.messagelabs.com id
	48/D0-31533-5BE8BDF4; Fri, 15 Jun 2012 19:36:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1339788980!27965328!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24840 invoked from network); 15 Jun 2012 19:36:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 19:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,779,1330905600"; d="scan'208";a="13053589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 19:36:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 20:36:15 +0100
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 1SfcJa-00009N-Nt;
	Fri, 15 Jun 2012 19:36:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SfcJa-0002H3-G4;
	Fri, 15 Jun 2012 20:36:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13049-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 20:36:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13049: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13049 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13049/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 10 guest-saverestore.2 fail REGR. vs. 12957

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10  fail like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 22:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 22: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 1SffJC-0002FY-NN; Fri, 15 Jun 2012 22:48: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 1SffJA-0002FT-Hb
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 22:48:00 +0000
Received: from [85.158.139.83:49890] by server-8.bemta-5.messagelabs.com id
	64/AA-10278-E9BBBDF4; Fri, 15 Jun 2012 22:47:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339800477!27941847!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17360 invoked from network); 15 Jun 2012 22:47:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 22:47:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,780,1330905600"; d="scan'208";a="13055228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 22:47:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 23:47:56 +0100
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 1SffJ6-0001A0-5o;
	Fri, 15 Jun 2012 22:47:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SffJ5-0007wl-7B;
	Fri, 15 Jun 2012 23:47:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13050-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 23:47:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13050: 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 13050 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13050/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 12903
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12903

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           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   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-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  e35c8bb53255
baseline version:
 xen                  c6eb61ed6f04

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=e35c8bb53255
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing e35c8bb53255
+ branch=xen-4.0-testing
+ revision=e35c8bb53255
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r e35c8bb53255 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 15 22:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Jun 2012 22: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 1SffJC-0002FY-NN; Fri, 15 Jun 2012 22:48: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 1SffJA-0002FT-Hb
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 22:48:00 +0000
Received: from [85.158.139.83:49890] by server-8.bemta-5.messagelabs.com id
	64/AA-10278-E9BBBDF4; Fri, 15 Jun 2012 22:47:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339800477!27941847!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5ODk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17360 invoked from network); 15 Jun 2012 22:47:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jun 2012 22:47:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,780,1330905600"; d="scan'208";a="13055228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jun 2012 22:47:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 15 Jun 2012 23:47:56 +0100
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 1SffJ6-0001A0-5o;
	Fri, 15 Jun 2012 22:47:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SffJ5-0007wl-7B;
	Fri, 15 Jun 2012 23:47:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13050-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Jun 2012 23:47:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13050: 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 13050 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13050/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 12903
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12903

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           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   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-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  e35c8bb53255
baseline version:
 xen                  c6eb61ed6f04

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=e35c8bb53255
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing e35c8bb53255
+ branch=xen-4.0-testing
+ revision=e35c8bb53255
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r e35c8bb53255 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 05:01:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 05:01: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 1Sfl76-0001WK-87; Sat, 16 Jun 2012 04: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 1Sfl74-0001WF-3h
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 04:59:54 +0000
Received: from [85.158.138.51:47526] by server-6.bemta-3.messagelabs.com id
	42/CC-11602-9C21CDF4; Sat, 16 Jun 2012 04:59:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339822792!27947656!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10388 invoked from network); 16 Jun 2012 04:59:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 04:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,781,1330905600"; d="scan'208";a="13056907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 04:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 05:59:51 +0100
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 1Sfl71-00037D-GG;
	Sat, 16 Jun 2012 04:59:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfl71-00030m-2D;
	Sat, 16 Jun 2012 05:59:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13051-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 05:59:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13051: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13051 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13051/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 05:01:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 05:01: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 1Sfl76-0001WK-87; Sat, 16 Jun 2012 04: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 1Sfl74-0001WF-3h
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 04:59:54 +0000
Received: from [85.158.138.51:47526] by server-6.bemta-3.messagelabs.com id
	42/CC-11602-9C21CDF4; Sat, 16 Jun 2012 04:59:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1339822792!27947656!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10388 invoked from network); 16 Jun 2012 04:59:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 04:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.75,781,1330905600"; d="scan'208";a="13056907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 04:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 05:59:51 +0100
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 1Sfl71-00037D-GG;
	Sat, 16 Jun 2012 04:59:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfl71-00030m-2D;
	Sat, 16 Jun 2012 05:59:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13051-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 05:59:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13051: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13051 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13051/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 05:56:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 05: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 1SflzM-0002Kp-Qw; Sat, 16 Jun 2012 05:56: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 1SflzL-0002Kk-GJ
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 05:55:59 +0000
Received: from [85.158.139.83:49019] by server-5.bemta-5.messagelabs.com id
	68/3C-02722-EEF1CDF4; Sat, 16 Jun 2012 05:55:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339826157!27964654!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25437 invoked from network); 16 Jun 2012 05:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 05:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13057060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 05:55:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 06:55:57 +0100
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 1SflzJ-0003QB-5C;
	Sat, 16 Jun 2012 05:55:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SflzJ-0004HO-3D;
	Sat, 16 Jun 2012 06:55:57 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13052-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 06:55:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13052: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13052 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13052/

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. 12957

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2   fail like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 05:56:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 05: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 1SflzM-0002Kp-Qw; Sat, 16 Jun 2012 05:56: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 1SflzL-0002Kk-GJ
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 05:55:59 +0000
Received: from [85.158.139.83:49019] by server-5.bemta-5.messagelabs.com id
	68/3C-02722-EEF1CDF4; Sat, 16 Jun 2012 05:55:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1339826157!27964654!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25437 invoked from network); 16 Jun 2012 05:55:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 05:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13057060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 05:55:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 06:55:57 +0100
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 1SflzJ-0003QB-5C;
	Sat, 16 Jun 2012 05:55:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SflzJ-0004HO-3D;
	Sat, 16 Jun 2012 06:55:57 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13052-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 06:55:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13052: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13052 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13052/

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. 12957

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2   fail like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 13:09:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 13:09:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sfsjo-0007Po-32; Sat, 16 Jun 2012 13:08:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sfsjm-0007Pj-6Q
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 13:08:22 +0000
Received: from [193.109.254.147:31103] by server-7.bemta-14.messagelabs.com id
	FB/DD-29165-5458CDF4; Sat, 16 Jun 2012 13:08:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339852101!2880715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23718 invoked from network); 16 Jun 2012 13:08:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 13:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13059529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 13:08:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 14:08:20 +0100
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 1Sfsjj-0005oW-RT;
	Sat, 16 Jun 2012 13:08:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfsjj-0000lM-QH;
	Sat, 16 Jun 2012 14:08:19 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13053-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 14:08:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13053: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13053 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13053/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 13:09:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 13:09:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sfsjo-0007Po-32; Sat, 16 Jun 2012 13:08:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sfsjm-0007Pj-6Q
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 13:08:22 +0000
Received: from [193.109.254.147:31103] by server-7.bemta-14.messagelabs.com id
	FB/DD-29165-5458CDF4; Sat, 16 Jun 2012 13:08:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1339852101!2880715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23718 invoked from network); 16 Jun 2012 13:08:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 13:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13059529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 13:08:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 14:08:20 +0100
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 1Sfsjj-0005oW-RT;
	Sat, 16 Jun 2012 13:08:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfsjj-0000lM-QH;
	Sat, 16 Jun 2012 14:08:19 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13053-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 14:08:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13053: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13053 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13053/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 13:58:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 13:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SftW3-0007vI-8e; Sat, 16 Jun 2012 13:58: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 1SftW1-0007vD-8c
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 13:58:13 +0000
Received: from [85.158.138.51:16590] by server-12.bemta-3.messagelabs.com id
	0C/CC-30206-4F09CDF4; Sat, 16 Jun 2012 13:58:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339855091!21636066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24337 invoked from network); 16 Jun 2012 13:58:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 13:58:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13059660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 13:58:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 14:58:11 +0100
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 1SftVy-00064u-Ms;
	Sat, 16 Jun 2012 13:58:10 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SftVy-00080c-MO;
	Sat, 16 Jun 2012 14:58:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13055-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 14:58:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13055: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13055 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13055/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build        fail in 13052 REGR. vs. 12957

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13052

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail blocked in 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13052 like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13052 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 13:58:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 13:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SftW3-0007vI-8e; Sat, 16 Jun 2012 13:58: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 1SftW1-0007vD-8c
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 13:58:13 +0000
Received: from [85.158.138.51:16590] by server-12.bemta-3.messagelabs.com id
	0C/CC-30206-4F09CDF4; Sat, 16 Jun 2012 13:58:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1339855091!21636066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24337 invoked from network); 16 Jun 2012 13:58:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 13:58:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13059660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 13:58:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 14:58:11 +0100
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 1SftVy-00064u-Ms;
	Sat, 16 Jun 2012 13:58:10 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SftVy-00080c-MO;
	Sat, 16 Jun 2012 14:58:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13055-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 14:58:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13055: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13055 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13055/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build        fail in 13052 REGR. vs. 12957

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13052

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail blocked in 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13052 like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13052 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 18:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 18:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sfy0T-0002e0-FP; Sat, 16 Jun 2012 18:45: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 1Sfy0R-0002ds-PG
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 18:45:56 +0000
Received: from [193.109.254.147:49805] by server-8.bemta-14.messagelabs.com id
	DD/D4-27132-364DCDF4; Sat, 16 Jun 2012 18:45:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339872353!10043462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4705 invoked from network); 16 Jun 2012 18:45:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 18:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13060480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 18:45:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 19:45:53 +0100
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 1Sfy0P-0007aQ-I5;
	Sat, 16 Jun 2012 18:45:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfy0P-0001sE-4y;
	Sat, 16 Jun 2012 19:45:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Sfy0P-0001sE-4y@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 19:45:53 +0100
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-amd64-xl-sedf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-sedf
test guest-start

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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9dffb1864f2c
  Bug not present: 34c725807d21


  changeset:   25483:9dffb1864f2c
  tag:         tip
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Thu Jun 14 16:05:42 2012 +0100
      
      libxl: propagate down the error from libxl_domain_sched_params_set
      
      So that the caller (e.g., libxl__build_post() ) knows and can deal with it.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-sedf.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13053 fail [host=woodlouse] / 13032 ok.
Failure / basis pass flights: 13053 / 13032
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-6d8b472233779c2a028a03843603030d2b1aee86 http://xenbits.xen.org/staging/xen-unstable.hg#a70b35deb2b5-9dffb1864f2c
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 17 nodes in revision graph
Searching for test results:
 13027 [host=field-cricket]
 13038 []
 13051 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13045 []
 13026 [host=earwig]
 13032 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13046 []
 13054 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13037 []
 13058 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 bc2f3a848f9a
 13057 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 61dfb3da56b0
 13056 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13060 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13059 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
 13053 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13062 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
 13064 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13065 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
 13066 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Searching for interesting versions
 Result found: flight 13032 (pass), for basis pass
 Result found: flight 13051 (fail), for basis failure
 Repro found: flight 13054 (pass), for basis pass
 Repro found: flight 13056 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
No revisions left to test, checking graph state.
 Result found: flight 13059 (pass), for last pass
 Result found: flight 13060 (fail), for first failure
 Repro found: flight 13062 (pass), for last pass
 Repro found: flight 13064 (fail), for first failure
 Repro found: flight 13065 (pass), for last pass
 Repro found: flight 13066 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9dffb1864f2c
  Bug not present: 34c725807d21

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25483:9dffb1864f2c
  tag:         tip
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Thu Jun 14 16:05:42 2012 +0100
      
      libxl: propagate down the error from libxl_domain_sched_params_set
      
      So that the caller (e.g., libxl__build_post() ) knows and can deal with it.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-sedf.guest-start.{dot,ps,png,html}.
----------------------------------------
13066: tolerable ALL FAIL

flight 13066 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13066/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested


jobs:
 test-amd64-amd64-xl-sedf                                     fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Sat Jun 16 18:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 18:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sfy0T-0002e0-FP; Sat, 16 Jun 2012 18:45: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 1Sfy0R-0002ds-PG
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 18:45:56 +0000
Received: from [193.109.254.147:49805] by server-8.bemta-14.messagelabs.com id
	DD/D4-27132-364DCDF4; Sat, 16 Jun 2012 18:45:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339872353!10043462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4705 invoked from network); 16 Jun 2012 18:45:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 18:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13060480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 18:45:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 19:45:53 +0100
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 1Sfy0P-0007aQ-I5;
	Sat, 16 Jun 2012 18:45:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfy0P-0001sE-4y;
	Sat, 16 Jun 2012 19:45:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Sfy0P-0001sE-4y@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 19:45:53 +0100
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-amd64-xl-sedf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-sedf
test guest-start

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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9dffb1864f2c
  Bug not present: 34c725807d21


  changeset:   25483:9dffb1864f2c
  tag:         tip
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Thu Jun 14 16:05:42 2012 +0100
      
      libxl: propagate down the error from libxl_domain_sched_params_set
      
      So that the caller (e.g., libxl__build_post() ) knows and can deal with it.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-sedf.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13053 fail [host=woodlouse] / 13032 ok.
Failure / basis pass flights: 13053 / 13032
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-6d8b472233779c2a028a03843603030d2b1aee86 http://xenbits.xen.org/staging/xen-unstable.hg#a70b35deb2b5-9dffb1864f2c
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 17 nodes in revision graph
Searching for test results:
 13027 [host=field-cricket]
 13038 []
 13051 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13045 []
 13026 [host=earwig]
 13032 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13046 []
 13054 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13037 []
 13058 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 bc2f3a848f9a
 13057 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 61dfb3da56b0
 13056 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13060 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13059 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
 13053 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13062 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
 13064 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13065 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
 13066 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Searching for interesting versions
 Result found: flight 13032 (pass), for basis pass
 Result found: flight 13051 (fail), for basis failure
 Repro found: flight 13054 (pass), for basis pass
 Repro found: flight 13056 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 34c725807d21
No revisions left to test, checking graph state.
 Result found: flight 13059 (pass), for last pass
 Result found: flight 13060 (fail), for first failure
 Repro found: flight 13062 (pass), for last pass
 Repro found: flight 13064 (fail), for first failure
 Repro found: flight 13065 (pass), for last pass
 Repro found: flight 13066 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9dffb1864f2c
  Bug not present: 34c725807d21

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25483:9dffb1864f2c
  tag:         tip
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Thu Jun 14 16:05:42 2012 +0100
      
      libxl: propagate down the error from libxl_domain_sched_params_set
      
      So that the caller (e.g., libxl__build_post() ) knows and can deal with it.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-sedf.guest-start.{dot,ps,png,html}.
----------------------------------------
13066: tolerable ALL FAIL

flight 13066 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13066/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start             fail baseline untested


jobs:
 test-amd64-amd64-xl-sedf                                     fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Sat Jun 16 18:48:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 18: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 1Sfy2t-0002lR-0Q; Sat, 16 Jun 2012 18:48:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sfy2r-0002lH-Fh
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 18:48:25 +0000
Received: from [193.109.254.147:28823] by server-11.bemta-14.messagelabs.com
	id B7/80-02727-8F4DCDF4; Sat, 16 Jun 2012 18:48:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339872504!10043579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6723 invoked from network); 16 Jun 2012 18:48:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 18:48:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13060490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 18:48:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 19:48:16 +0100
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 1Sfy2i-0007bE-Hi;
	Sat, 16 Jun 2012 18:48:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfy2i-0002DG-FH;
	Sat, 16 Jun 2012 19:48:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13063-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 19:48:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13063: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13063 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13063/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 12957

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-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 18:48:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 18: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 1Sfy2t-0002lR-0Q; Sat, 16 Jun 2012 18:48:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sfy2r-0002lH-Fh
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 18:48:25 +0000
Received: from [193.109.254.147:28823] by server-11.bemta-14.messagelabs.com
	id B7/80-02727-8F4DCDF4; Sat, 16 Jun 2012 18:48:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1339872504!10043579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6723 invoked from network); 16 Jun 2012 18:48:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 18:48:24 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13060490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 18:48:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 19:48:16 +0100
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 1Sfy2i-0007bE-Hi;
	Sat, 16 Jun 2012 18:48:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sfy2i-0002DG-FH;
	Sat, 16 Jun 2012 19:48:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13063-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 19:48:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13063: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13063 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13063/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 12957

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-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 21:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 21: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 1Sg0SM-0004g0-7x; Sat, 16 Jun 2012 21:22:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sg0SK-0004fv-QJ
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 21:22:53 +0000
Received: from [85.158.139.83:43293] by server-11.bemta-5.messagelabs.com id
	FE/07-20400-C29FCDF4; Sat, 16 Jun 2012 21:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339881771!27480642!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14290 invoked from network); 16 Jun 2012 21:22:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 21:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13061128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 21:22:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 22:22:50 +0100
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 1Sg0SI-0008PG-4E;
	Sat, 16 Jun 2012 21:22:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sg0SH-0001UE-Uj;
	Sat, 16 Jun 2012 22:22:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13061-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 22:22:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13061: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13061 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13061/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 21:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 21: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 1Sg0SM-0004g0-7x; Sat, 16 Jun 2012 21:22:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sg0SK-0004fv-QJ
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 21:22:53 +0000
Received: from [85.158.139.83:43293] by server-11.bemta-5.messagelabs.com id
	FE/07-20400-C29FCDF4; Sat, 16 Jun 2012 21:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339881771!27480642!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14290 invoked from network); 16 Jun 2012 21:22:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 21:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="13061128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 21:22:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 16 Jun 2012 22:22:50 +0100
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 1Sg0SI-0008PG-4E;
	Sat, 16 Jun 2012 21:22:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sg0SH-0001UE-Uj;
	Sat, 16 Jun 2012 22:22:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13061-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 16 Jun 2012 22:22:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13061: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13061 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13061/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 23:07:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 23:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sg24u-0006OF-PZ; Sat, 16 Jun 2012 23:06: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 1Sg24t-0006O7-5g
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 23:06:47 +0000
Received: from [85.158.139.83:52516] by server-4.bemta-5.messagelabs.com id
	63/93-27831-6811DDF4; Sat, 16 Jun 2012 23:06:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339888005!27486295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10057 invoked from network); 16 Jun 2012 23:06:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 23:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,784,1330905600"; d="scan'208";a="13061853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 23:06:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 00:06:45 +0100
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 1Sg24q-0000W6-Qu;
	Sat, 16 Jun 2012 23:06:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sg24q-0004xf-5l;
	Sun, 17 Jun 2012 00:06:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13068-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 00:06:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13068: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13068 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13068/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build        fail in 13052 REGR. vs. 12957

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13052

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail blocked in 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13052 like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13052 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 16 23:07:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Jun 2012 23:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sg24u-0006OF-PZ; Sat, 16 Jun 2012 23:06: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 1Sg24t-0006O7-5g
	for xen-devel@lists.xensource.com; Sat, 16 Jun 2012 23:06:47 +0000
Received: from [85.158.139.83:52516] by server-4.bemta-5.messagelabs.com id
	63/93-27831-6811DDF4; Sat, 16 Jun 2012 23:06:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1339888005!27486295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10057 invoked from network); 16 Jun 2012 23:06:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jun 2012 23:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.75,784,1330905600"; d="scan'208";a="13061853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jun 2012 23:06:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 00:06:45 +0100
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 1Sg24q-0000W6-Qu;
	Sat, 16 Jun 2012 23:06:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sg24q-0004xf-5l;
	Sun, 17 Jun 2012 00:06:44 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13068-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 00:06:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13068: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13068 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13068/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build        fail in 13052 REGR. vs. 12957

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13052

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail blocked in 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13052 like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13052 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 00:54:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 00:54: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 1Sg3kq-0008Lt-0T; Sun, 17 Jun 2012 00:54:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sg3kn-0008Lg-LZ
	for xen-devel@lists.xen.org; Sun, 17 Jun 2012 00:54:10 +0000
Received: from [85.158.143.99:13553] by server-2.bemta-4.messagelabs.com id
	C4/99-17938-1BA2DDF4; Sun, 17 Jun 2012 00:54:09 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339894446!24327982!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21504 invoked from network); 17 Jun 2012 00:54:07 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 00:54:07 -0000
Received: by obbwd20 with SMTP id wd20so8248447obb.32
	for <xen-devel@lists.xen.org>; Sat, 16 Jun 2012 17:53:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=pGrmSv1TifYABE3JtN+ARrKus/EY6TxQBm9psS5YEhI=;
	b=R91km5mXbVeKuzKEV+YOrVVqyjvCzPw0PjE6OJUDyncbbtnpLxG0yHUXtGOAMsCcdk
	Q2FxFRbU4vzHeclndJDdw+Xk7j880BalvW8EwPzcB1OyZBFEwD1cUwVlBA9avfzZqvZG
	E+Ti1xyAn/EZHVwaloFg1CJIfbmd3iubr1PdjoBYx0i8+lKibwe7Nn0JW3WoI0Y0cAjZ
	am1RHVgUjw/9H/N4WrIKIpBmNMuSAnI7zeQnwcwQTFx7YWkole9SKf4b1qeeVknWV4T4
	zYTLVRfhGGdPW0AED4u491ybzxa6SATepwZtDfmgUbpS0CFdJPm3gbogfHWN31W9/UrR
	r4eA==
Received: by 10.50.89.198 with SMTP id bq6mr5337470igb.28.1339894386318; Sat,
	16 Jun 2012 17:53:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.66.14 with HTTP; Sat, 16 Jun 2012 17:52:46 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Sun, 17 Jun 2012 02:52:46 +0200
Message-ID: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnrUHnI0SM3Y9gRnvngu6fwWKy2alErX6rGyn6SAryvjz/lNl22xllRmTXU+jjwIXTMkALG
Subject: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
crashes. I've included a serial console log below.

I've used:
Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
apply the AT_EMPTY_PATH patch from
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to
get it to compile.
Linux 3.2.0-25, which is the default kernel in Ubuntu's repository right now.
Ubuntu 12.04 Precise

Booting with the default Xen 4.1 from the Ubuntu repositories works.

Using the kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is
a mainline Linux kernel (and also more recent) works with my compiled
version of Xen 4.2

So,
* Is xen 4.2 not happy with the 3.2 kernel I've used?
* Is this due to something Ubuntu modified in their default kernel?
* Is this an issue with Xen?
* Did I break something?

-----

 __  __            _  _    ____                     _        _     _
 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.2-unstable (root@roce.org) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012
(XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864f2c
(XEN) Bootloader: GRUB 1.99-21ubuntu3.1
(XEN) Command line: placeholder loglvl=all guest_loglvl=all
console_timestamps=1 noreboot com1=115200,8n1,0x3f8,4 console=com1,vga
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 3 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d800 (usable)
(XEN)  000000000009d800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000bd8a7000 (usable)
(XEN)  00000000bd8a7000 - 00000000bde1f000 (reserved)
(XEN)  00000000bde1f000 - 00000000be09f000 (ACPI NVS)
(XEN)  00000000be09f000 - 00000000be0a4000 (ACPI data)
(XEN)  00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
(XEN)  00000000be0e7000 - 00000000beb81000 (usable)
(XEN)  00000000beb81000 - 00000000beff2000 (reserved)
(XEN)  00000000beff2000 - 00000000bf000000 (usable)
(XEN)  00000000bf800000 - 00000000cfa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000042f600000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA    A M I       14 INTL 20051117)
(XEN) ACPI: FACS BE09DF80, 0040
(XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
(XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl     1000 INTL 20091112)
(XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT   1072009 MSFT       97)
(XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA    A M I  1072009 AMI.        5)
(XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl     1000 INTL 20091112)
(XEN) ACPI: SSDT BE08ED88, 09AA (r1  PmRef  Cpu0Ist     3000 INTL 20051117)
(XEN) ACPI: SSDT BE08F738, 0A92 (r1  PmRef    CpuPm     3000 INTL 20051117)
(XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL      SNB         1 INTL        1)
(XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA    A M I  1072009 AMI     10013)
(XEN) System RAM: 16086MB (16473004kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000042f600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fceb0
(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 -
be09df80/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[be09df8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, 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) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3300.138 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) mce_intel.c:1239: 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 f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(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) TSC deadline timer enabled
(XEN) [2012-06-17 00:22:20] Platform timer is 14.318MHz HPET
(XEN) [2012-06-17 00:22:20] Allocated console ring of 32 KiB.
(XEN) [2012-06-17 00:22:20] VMX: Supported advanced features:
(XEN) [2012-06-17 00:22:20]  - APIC MMIO access virtualisation
(XEN) [2012-06-17 00:22:20]  - APIC TPR shadow
(XEN) [2012-06-17 00:22:20]  - Extended Page Tables (EPT)
(XEN) [2012-06-17 00:22:20]  - Virtual-Processor Identifiers (VPID)
(XEN) [2012-06-17 00:22:20]  - Virtual NMI
(XEN) [2012-06-17 00:22:20]  - MSR direct-access bitmap
(XEN) [2012-06-17 00:22:20]  - Unrestricted Guest
(XEN) [2012-06-17 00:22:20] HVM: ASIDs enabled.
(XEN) [2012-06-17 00:22:20] HVM: VMX enabled
(XEN) [2012-06-17 00:22:20] HVM: Hardware Assisted Paging (HAP) detected
(XEN) [2012-06-17 00:22:20] HVM: HAP page sizes: 4kB, 2MB
(XEN) [2012-06-17 00:22:20] Brought up 4 CPUs
(XEN) [2012-06-17 00:22:20] ACPI sleep modes: S3
(XEN) [2012-06-17 00:22:20] mcheck_poll: Machine check polling timer started.
(XEN) [2012-06-17 00:22:20] *** LOADING DOMAIN 0 ***
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1000000
memsz=0xad5000
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1c00000
memsz=0xe50e0
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1ce6000
memsz=0x14480
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1cfb000
memsz=0x364000
(XEN) [2012-06-17 00:22:20] elf_parse_binary: memory: 0x1000000 -> 0x205f000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_OS = "linux"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: ENTRY = 0xffffffff81cfb200
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HYPERCALL_PAGE =
0xffffffff81001000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: FEATURES =
"!writable_page_tables|pae_pgdir_above_4gb"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PAE_MODE = "yes"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: LOADER = "generic"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HV_START_LOW =
0xffff800000000000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) [2012-06-17 00:22:20] elf_xen_addr_calc_check: addresses:
(XEN) [2012-06-17 00:22:20]     virt_base        = 0xffffffff80000000
(XEN) [2012-06-17 00:22:20]     elf_paddr_offset = 0x0
(XEN) [2012-06-17 00:22:20]     virt_offset      = 0xffffffff80000000
(XEN) [2012-06-17 00:22:20]     virt_kstart      = 0xffffffff81000000
(XEN) [2012-06-17 00:22:20]     virt_kend        = 0xffffffff8205f000
(XEN) [2012-06-17 00:22:20]     virt_entry       = 0xffffffff81cfb200
(XEN) [2012-06-17 00:22:20]     p2m_base         = 0xffffffffffffffff
(XEN) [2012-06-17 00:22:20]  Xen  kernel: 64-bit, lsb, compat32
(XEN) [2012-06-17 00:22:20]  Dom0 kernel: 64-bit, PAE, lsb, paddr
0x1000000 -> 0x205f000
(XEN) [2012-06-17 00:22:20] PHYSICAL MEMORY ARRANGEMENT:
(XEN) [2012-06-17 00:22:20]  Dom0 alloc.:
0000000418000000->0000000420000000 (3987995 pages to be allocated)
(XEN) [2012-06-17 00:22:20]  Init. ramdisk: 000000042d02f000->000000042f5ff400
(XEN) [2012-06-17 00:22:20] VIRTUAL MEMORY ARRANGEMENT:
(XEN) [2012-06-17 00:22:20]  Loaded kernel: ffffffff81000000->ffffffff8205f000
(XEN) [2012-06-17 00:22:20]  Init. ramdisk: ffffffff8205f000->ffffffff8462f400
(XEN) [2012-06-17 00:22:20]  Phys-Mach map: ffffffff84630000->ffffffff864eff60
(XEN) [2012-06-17 00:22:20]  Start info:    ffffffff864f0000->ffffffff864f04b4
(XEN) [2012-06-17 00:22:20]  Page tables:   ffffffff864f1000->ffffffff86528000
(XEN) [2012-06-17 00:22:20]  Boot stack:    ffffffff86528000->ffffffff86529000
(XEN) [2012-06-17 00:22:20]  TOTAL:         ffffffff80000000->ffffffff86800000
(XEN) [2012-06-17 00:22:20]  ENTRY ADDRESS: ffffffff81cfb200
(XEN) [2012-06-17 00:22:20] Dom0 has maximum 4 VCPUs
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 0 at
0xffffffff81000000 -> 0xffffffff81ad5000
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 1 at
0xffffffff81c00000 -> 0xffffffff81ce50e0
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 2 at
0xffffffff81ce6000 -> 0xffffffff81cfa480
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 3 at
0xffffffff81cfb000 -> 0xffffffff81dd3000
(XEN) [2012-06-17 00:22:22] Scrubbing Free RAM: .done.
(XEN) [2012-06-17 00:22:22] Initial low memory virq threshold set at
0x4000 pages.
(XEN) [2012-06-17 00:22:22] Std. Loglevel: All
(XEN) [2012-06-17 00:22:22] Guest Loglevel: All
(XEN) [2012-06-17 00:22:22] Xen is relinquishing VGA console.
(XEN) [2012-06-17 00:22:22] *** Serial input -> DOM0 (type 'CTRL-a'
three times to switch input to Xen)
(XEN) [2012-06-17 00:22:22] Freed 244kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.2.0-25-generic (buildd@crested) (gcc
version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #40-Ubuntu SMP We)
[    0.000000] Command line: placeholder
root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
earlyprintk=xen
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] Freeing  9d-100 pfn range: 99 pages freed
[    0.000000] Freeing  20000-20200 pfn range: 512 pages freed
[    0.000000] Freeing  40004-40005 pfn range: 1 pages freed
[    0.000000] Freeing  bd8a7-be0e7 pfn range: 2112 pages freed
[    0.000000] Freeing  beb81-beff2 pfn range: 1137 pages freed
[    0.000000] Freeing  bf000-100000 pfn range: 266240 pages freed
[    0.000000] Released 270101 pages of unused memory
[    0.000000] Set 270101 page(s) to 1-1 mapping
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009d000 (usable)
[    0.000000]  Xen: 000000000009d800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
[    0.000000]  Xen: 0000000020200000 - 0000000040004000 (usable)
[    0.000000]  Xen: 0000000040004000 - 0000000040005000 (reserved)
[    0.000000]  Xen: 0000000040005000 - 00000000bd8a7000 (usable)
[    0.000000]  Xen: 00000000bd8a7000 - 00000000bde1f000 (reserved)
[    0.000000]  Xen: 00000000bde1f000 - 00000000be09f000 (ACPI NVS)
[    0.000000]  Xen: 00000000be09f000 - 00000000be0a4000 (ACPI data)
[    0.000000]  Xen: 00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
[    0.000000]  Xen: 00000000be0e7000 - 00000000beb81000 (usable)
[    0.000000]  Xen: 00000000beb81000 - 00000000beff2000 (reserved)
[    0.000000]  Xen: 00000000beff2000 - 00000000bf000000 (usable)
[    0.000000]  Xen: 00000000bf800000 - 00000000cfa00000 (reserved)
[    0.000000]  Xen: 00000000f8000000 - 00000000fc000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed04000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff000000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 000000042f600000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x42f600 max_arch_pfn = 0x400000000
[    0.000000] x2apic enabled by BIOS, switching to x2apic ops
[    0.000000] last_pfn = 0xbf000 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000fceb0] fceb0
[    0.000000] init_memory_mapping: 0000000000000000-00000000bf000000
[    0.000000] init_memory_mapping: 0000000100000000-000000042f600000
[    0.000000] RAMDISK: 0205f000 - 04630000
[    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 00000000be084080 00084 (v01 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] ACPI: FACP 00000000be08e218 000F4 (v04 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 00000000be0841a0 0A077 (v02 ALASKA    A M I
00000014 INTL 20051117)
[    0.000000] ACPI: FACS 00000000be09df80 00040
[    0.000000] ACPI: APIC 00000000be08e310 00072 (v03 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] ACPI: ASF! 00000000be08e388 000A5 (v32 INTEL       HCG
00000001 TFSM 000F4240)
[    0.000000] ACPI: MCFG 00000000be08e430 0003C (v01 ALASKA    A M I
01072009 MSFT 00000097)
[    0.000000] ACPI: SSDT 00000000be08e470 004A6 (v01 Intel_ AoacTabl
00001000 INTL 20091112)
[    0.000000] ACPI: AAFT 00000000be08e918 000C2 (v01 ALASKA OEMAAFT
01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000be08e9e0 00038 (v01 ALASKA    A M I
01072009 AMI. 00000005)
[    0.000000] ACPI: SSDT 00000000be08ea18 0036D (v01 SataRe SataTabl
00001000 INTL 20091112)
[    0.000000] ACPI: SSDT 00000000be08ed88 009AA (v01  PmRef  Cpu0Ist
00003000 INTL 20051117)
[    0.000000] ACPI: SSDT 00000000be08f738 00A92 (v01  PmRef    CpuPm
00003000 INTL 20051117)
[    0.000000] ACPI: XMAR 00000000be0901d0 000B8 (v01 INTEL      SNB
00000001 INTL 00000001)
[    0.000000] ACPI: BGRT 00000000be090288 0003C (v00 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] Setting APIC routing to cluster x2apic.
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-000000042f600000
[    0.000000] Initmem setup node 0 0000000000000000-000000042f600000
[    0.000000]   NODE_DATA [00000003d7fe7000 - 00000003d7febfff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x0042f600
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[7] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009d
[    0.000000]     0: 0x00000100 -> 0x00020000
[    0.000000]     0: 0x00020200 -> 0x00040004
[    0.000000]     0: 0x00040005 -> 0x000bd8a7
[    0.000000]     0: 0x000be0e7 -> 0x000beb81
[    0.000000]     0: 0x000beff2 -> 0x000bf000
[    0.000000]     0: 0x00100000 -> 0x0042f600
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255
[    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] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 0000000020000000 - 0000000020200000
[    0.000000] PM: Registered nosave memory: 0000000040004000 - 0000000040005000
[    0.000000] PM: Registered nosave memory: 00000000bd8a7000 - 00000000bde1f000
[    0.000000] PM: Registered nosave memory: 00000000bde1f000 - 00000000be09f000
[    0.000000] PM: Registered nosave memory: 00000000be09f000 - 00000000be0a4000
[    0.000000] PM: Registered nosave memory: 00000000be0a4000 - 00000000be0e7000
[    0.000000] PM: Registered nosave memory: 00000000beb81000 - 00000000beff2000
[    0.000000] PM: Registered nosave memory: 00000000bf000000 - 00000000bf800000
[    0.000000] PM: Registered nosave memory: 00000000bf800000 - 00000000cfa00000
[    0.000000] PM: Registered nosave memory: 00000000cfa00000 - 00000000f8000000
[    0.000000] PM: Registered nosave memory: 00000000f8000000 - 00000000fc000000
[    0.000000] PM: Registered nosave memory: 00000000fc000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed00000
[    0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fed04000
[    0.000000] PM: Registered nosave memory: 00000000fed04000 - 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 - 00000000ff000000
[    0.000000] PM: Registered nosave memory: 00000000ff000000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at cfa00000 (gap:
cfa00000:28600000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256
nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8803d7c00000 s83072
r8192 d23424 u524288
[    3.860481] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 4048188
[    3.860484] Policy zone: Normal
[    3.860487] Kernel command line: placeholder
root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
earlyprintk=xen
[    3.860828] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    3.861070] invalid opcode: 0000 [#1] SMP
[    3.861073] CPU 0
[    3.861074] Modules linked in:
[    3.861076]
[    3.861078] Pid: 0, comm: swapper Not tainted 3.2.0-25-generic
#40-Ubuntu To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extre6
[    3.861083] RIP: e030:[<ffffffff8101d82c>]  [<ffffffff8101d82c>]
xstate_enable+0x3c/0x50
[    3.861090] RSP: e02b:ffffffff81c01e58  EFLAGS: 00010046
[    3.861092] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX: 0000000000000000
[    3.861094] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 0000000000002660
[    3.861096] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09: ffffffff81c01e94
[    3.861098] R10: 00000000ffffffff R11: 00000000ffffffff R12: ffffffff81c01e90
[    3.861100] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15: ffff8803d7c0c480
[    3.861104] FS:  0000000000000000(0000) GS:ffff8803d7c00000(0000)
knlGS:0000000000000000
[    3.861107] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    3.861108] CR2: 0000000000000000 CR3: 0000000001c05000 CR4: 0000000000002660
[    3.861111] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    3.861113] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    3.861115] Process swapper (pid: 0, threadinfo ffffffff81c00000,
task ffffffff81c0d020)
[    3.861117] Stack:
[    3.861119]  ffffffff81c01ec8 ffffffff81d04795 ffff8803d7c0b150
ffff8803d7c0b950
[    3.861123]  ffff8803d7c0b150 ffff8803d7c0b950 0000024000000007
0000000000000340
[    3.861127]  0000000000000004 0000000000000008 0000000000000004
0000000000000000
[    3.861131] Call Trace:
[    3.861136]  [<ffffffff81d04795>] xstate_enable_boot_cpu+0xa9/0x174
[    3.861141]  [<ffffffff8163660b>] xsave_init+0x26/0x28
[    3.861143]  [<ffffffff816388d1>] cpu_init+0x2bb/0x2d8
[    3.861146]  [<ffffffff81d00f92>] trap_init+0x169/0x171
[    3.861149]  [<ffffffff81cfba28>] start_kernel+0x1d5/0x3c7
[    3.861153]  [<ffffffff81cfb388>] x86_64_start_reservations+0x132/0x136
[    3.861156]  [<ffffffff81cfef27>] xen_start_kernel+0x5d9/0x5e0
[    3.861157] Code: 00 04 00 ff 14 25 90 76 c1 81 48 89 c7 48 81 cf
00 00 04 00 ff 14 25 98 76 c1 81 48 8b 05 cd 0d dc 00 31 c9 48
[    3.861191] RIP  [<ffffffff8101d82c>] xstate_enable+0x3c/0x50
[    3.861194]  RSP <ffffffff81c01e58

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 00:54:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 00:54: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 1Sg3kq-0008Lt-0T; Sun, 17 Jun 2012 00:54:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sg3kn-0008Lg-LZ
	for xen-devel@lists.xen.org; Sun, 17 Jun 2012 00:54:10 +0000
Received: from [85.158.143.99:13553] by server-2.bemta-4.messagelabs.com id
	C4/99-17938-1BA2DDF4; Sun, 17 Jun 2012 00:54:09 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1339894446!24327982!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21504 invoked from network); 17 Jun 2012 00:54:07 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 00:54:07 -0000
Received: by obbwd20 with SMTP id wd20so8248447obb.32
	for <xen-devel@lists.xen.org>; Sat, 16 Jun 2012 17:53:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=pGrmSv1TifYABE3JtN+ARrKus/EY6TxQBm9psS5YEhI=;
	b=R91km5mXbVeKuzKEV+YOrVVqyjvCzPw0PjE6OJUDyncbbtnpLxG0yHUXtGOAMsCcdk
	Q2FxFRbU4vzHeclndJDdw+Xk7j880BalvW8EwPzcB1OyZBFEwD1cUwVlBA9avfzZqvZG
	E+Ti1xyAn/EZHVwaloFg1CJIfbmd3iubr1PdjoBYx0i8+lKibwe7Nn0JW3WoI0Y0cAjZ
	am1RHVgUjw/9H/N4WrIKIpBmNMuSAnI7zeQnwcwQTFx7YWkole9SKf4b1qeeVknWV4T4
	zYTLVRfhGGdPW0AED4u491ybzxa6SATepwZtDfmgUbpS0CFdJPm3gbogfHWN31W9/UrR
	r4eA==
Received: by 10.50.89.198 with SMTP id bq6mr5337470igb.28.1339894386318; Sat,
	16 Jun 2012 17:53:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.66.14 with HTTP; Sat, 16 Jun 2012 17:52:46 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Sun, 17 Jun 2012 02:52:46 +0200
Message-ID: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnrUHnI0SM3Y9gRnvngu6fwWKy2alErX6rGyn6SAryvjz/lNl22xllRmTXU+jjwIXTMkALG
Subject: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
crashes. I've included a serial console log below.

I've used:
Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
apply the AT_EMPTY_PATH patch from
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to
get it to compile.
Linux 3.2.0-25, which is the default kernel in Ubuntu's repository right now.
Ubuntu 12.04 Precise

Booting with the default Xen 4.1 from the Ubuntu repositories works.

Using the kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is
a mainline Linux kernel (and also more recent) works with my compiled
version of Xen 4.2

So,
* Is xen 4.2 not happy with the 3.2 kernel I've used?
* Is this due to something Ubuntu modified in their default kernel?
* Is this an issue with Xen?
* Did I break something?

-----

 __  __            _  _    ____                     _        _     _
 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.2-unstable (root@roce.org) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012
(XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864f2c
(XEN) Bootloader: GRUB 1.99-21ubuntu3.1
(XEN) Command line: placeholder loglvl=all guest_loglvl=all
console_timestamps=1 noreboot com1=115200,8n1,0x3f8,4 console=com1,vga
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 3 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d800 (usable)
(XEN)  000000000009d800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000bd8a7000 (usable)
(XEN)  00000000bd8a7000 - 00000000bde1f000 (reserved)
(XEN)  00000000bde1f000 - 00000000be09f000 (ACPI NVS)
(XEN)  00000000be09f000 - 00000000be0a4000 (ACPI data)
(XEN)  00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
(XEN)  00000000be0e7000 - 00000000beb81000 (usable)
(XEN)  00000000beb81000 - 00000000beff2000 (reserved)
(XEN)  00000000beff2000 - 00000000bf000000 (usable)
(XEN)  00000000bf800000 - 00000000cfa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000042f600000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA    A M I       14 INTL 20051117)
(XEN) ACPI: FACS BE09DF80, 0040
(XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
(XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl     1000 INTL 20091112)
(XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT   1072009 MSFT       97)
(XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA    A M I  1072009 AMI.        5)
(XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl     1000 INTL 20091112)
(XEN) ACPI: SSDT BE08ED88, 09AA (r1  PmRef  Cpu0Ist     3000 INTL 20051117)
(XEN) ACPI: SSDT BE08F738, 0A92 (r1  PmRef    CpuPm     3000 INTL 20051117)
(XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL      SNB         1 INTL        1)
(XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA    A M I  1072009 AMI     10013)
(XEN) System RAM: 16086MB (16473004kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000042f600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fceb0
(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 -
be09df80/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[be09df8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, 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) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3300.138 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) mce_intel.c:1239: 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 f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(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) TSC deadline timer enabled
(XEN) [2012-06-17 00:22:20] Platform timer is 14.318MHz HPET
(XEN) [2012-06-17 00:22:20] Allocated console ring of 32 KiB.
(XEN) [2012-06-17 00:22:20] VMX: Supported advanced features:
(XEN) [2012-06-17 00:22:20]  - APIC MMIO access virtualisation
(XEN) [2012-06-17 00:22:20]  - APIC TPR shadow
(XEN) [2012-06-17 00:22:20]  - Extended Page Tables (EPT)
(XEN) [2012-06-17 00:22:20]  - Virtual-Processor Identifiers (VPID)
(XEN) [2012-06-17 00:22:20]  - Virtual NMI
(XEN) [2012-06-17 00:22:20]  - MSR direct-access bitmap
(XEN) [2012-06-17 00:22:20]  - Unrestricted Guest
(XEN) [2012-06-17 00:22:20] HVM: ASIDs enabled.
(XEN) [2012-06-17 00:22:20] HVM: VMX enabled
(XEN) [2012-06-17 00:22:20] HVM: Hardware Assisted Paging (HAP) detected
(XEN) [2012-06-17 00:22:20] HVM: HAP page sizes: 4kB, 2MB
(XEN) [2012-06-17 00:22:20] Brought up 4 CPUs
(XEN) [2012-06-17 00:22:20] ACPI sleep modes: S3
(XEN) [2012-06-17 00:22:20] mcheck_poll: Machine check polling timer started.
(XEN) [2012-06-17 00:22:20] *** LOADING DOMAIN 0 ***
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1000000
memsz=0xad5000
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1c00000
memsz=0xe50e0
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1ce6000
memsz=0x14480
(XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1cfb000
memsz=0x364000
(XEN) [2012-06-17 00:22:20] elf_parse_binary: memory: 0x1000000 -> 0x205f000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_OS = "linux"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: ENTRY = 0xffffffff81cfb200
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HYPERCALL_PAGE =
0xffffffff81001000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: FEATURES =
"!writable_page_tables|pae_pgdir_above_4gb"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PAE_MODE = "yes"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: LOADER = "generic"
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HV_START_LOW =
0xffff800000000000
(XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) [2012-06-17 00:22:20] elf_xen_addr_calc_check: addresses:
(XEN) [2012-06-17 00:22:20]     virt_base        = 0xffffffff80000000
(XEN) [2012-06-17 00:22:20]     elf_paddr_offset = 0x0
(XEN) [2012-06-17 00:22:20]     virt_offset      = 0xffffffff80000000
(XEN) [2012-06-17 00:22:20]     virt_kstart      = 0xffffffff81000000
(XEN) [2012-06-17 00:22:20]     virt_kend        = 0xffffffff8205f000
(XEN) [2012-06-17 00:22:20]     virt_entry       = 0xffffffff81cfb200
(XEN) [2012-06-17 00:22:20]     p2m_base         = 0xffffffffffffffff
(XEN) [2012-06-17 00:22:20]  Xen  kernel: 64-bit, lsb, compat32
(XEN) [2012-06-17 00:22:20]  Dom0 kernel: 64-bit, PAE, lsb, paddr
0x1000000 -> 0x205f000
(XEN) [2012-06-17 00:22:20] PHYSICAL MEMORY ARRANGEMENT:
(XEN) [2012-06-17 00:22:20]  Dom0 alloc.:
0000000418000000->0000000420000000 (3987995 pages to be allocated)
(XEN) [2012-06-17 00:22:20]  Init. ramdisk: 000000042d02f000->000000042f5ff400
(XEN) [2012-06-17 00:22:20] VIRTUAL MEMORY ARRANGEMENT:
(XEN) [2012-06-17 00:22:20]  Loaded kernel: ffffffff81000000->ffffffff8205f000
(XEN) [2012-06-17 00:22:20]  Init. ramdisk: ffffffff8205f000->ffffffff8462f400
(XEN) [2012-06-17 00:22:20]  Phys-Mach map: ffffffff84630000->ffffffff864eff60
(XEN) [2012-06-17 00:22:20]  Start info:    ffffffff864f0000->ffffffff864f04b4
(XEN) [2012-06-17 00:22:20]  Page tables:   ffffffff864f1000->ffffffff86528000
(XEN) [2012-06-17 00:22:20]  Boot stack:    ffffffff86528000->ffffffff86529000
(XEN) [2012-06-17 00:22:20]  TOTAL:         ffffffff80000000->ffffffff86800000
(XEN) [2012-06-17 00:22:20]  ENTRY ADDRESS: ffffffff81cfb200
(XEN) [2012-06-17 00:22:20] Dom0 has maximum 4 VCPUs
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 0 at
0xffffffff81000000 -> 0xffffffff81ad5000
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 1 at
0xffffffff81c00000 -> 0xffffffff81ce50e0
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 2 at
0xffffffff81ce6000 -> 0xffffffff81cfa480
(XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 3 at
0xffffffff81cfb000 -> 0xffffffff81dd3000
(XEN) [2012-06-17 00:22:22] Scrubbing Free RAM: .done.
(XEN) [2012-06-17 00:22:22] Initial low memory virq threshold set at
0x4000 pages.
(XEN) [2012-06-17 00:22:22] Std. Loglevel: All
(XEN) [2012-06-17 00:22:22] Guest Loglevel: All
(XEN) [2012-06-17 00:22:22] Xen is relinquishing VGA console.
(XEN) [2012-06-17 00:22:22] *** Serial input -> DOM0 (type 'CTRL-a'
three times to switch input to Xen)
(XEN) [2012-06-17 00:22:22] Freed 244kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.2.0-25-generic (buildd@crested) (gcc
version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #40-Ubuntu SMP We)
[    0.000000] Command line: placeholder
root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
earlyprintk=xen
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] Freeing  9d-100 pfn range: 99 pages freed
[    0.000000] Freeing  20000-20200 pfn range: 512 pages freed
[    0.000000] Freeing  40004-40005 pfn range: 1 pages freed
[    0.000000] Freeing  bd8a7-be0e7 pfn range: 2112 pages freed
[    0.000000] Freeing  beb81-beff2 pfn range: 1137 pages freed
[    0.000000] Freeing  bf000-100000 pfn range: 266240 pages freed
[    0.000000] Released 270101 pages of unused memory
[    0.000000] Set 270101 page(s) to 1-1 mapping
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009d000 (usable)
[    0.000000]  Xen: 000000000009d800 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
[    0.000000]  Xen: 0000000020200000 - 0000000040004000 (usable)
[    0.000000]  Xen: 0000000040004000 - 0000000040005000 (reserved)
[    0.000000]  Xen: 0000000040005000 - 00000000bd8a7000 (usable)
[    0.000000]  Xen: 00000000bd8a7000 - 00000000bde1f000 (reserved)
[    0.000000]  Xen: 00000000bde1f000 - 00000000be09f000 (ACPI NVS)
[    0.000000]  Xen: 00000000be09f000 - 00000000be0a4000 (ACPI data)
[    0.000000]  Xen: 00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
[    0.000000]  Xen: 00000000be0e7000 - 00000000beb81000 (usable)
[    0.000000]  Xen: 00000000beb81000 - 00000000beff2000 (reserved)
[    0.000000]  Xen: 00000000beff2000 - 00000000bf000000 (usable)
[    0.000000]  Xen: 00000000bf800000 - 00000000cfa00000 (reserved)
[    0.000000]  Xen: 00000000f8000000 - 00000000fc000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed04000 (reserved)
[    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ff000000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 000000042f600000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x42f600 max_arch_pfn = 0x400000000
[    0.000000] x2apic enabled by BIOS, switching to x2apic ops
[    0.000000] last_pfn = 0xbf000 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000fceb0] fceb0
[    0.000000] init_memory_mapping: 0000000000000000-00000000bf000000
[    0.000000] init_memory_mapping: 0000000100000000-000000042f600000
[    0.000000] RAMDISK: 0205f000 - 04630000
[    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 00000000be084080 00084 (v01 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] ACPI: FACP 00000000be08e218 000F4 (v04 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 00000000be0841a0 0A077 (v02 ALASKA    A M I
00000014 INTL 20051117)
[    0.000000] ACPI: FACS 00000000be09df80 00040
[    0.000000] ACPI: APIC 00000000be08e310 00072 (v03 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] ACPI: ASF! 00000000be08e388 000A5 (v32 INTEL       HCG
00000001 TFSM 000F4240)
[    0.000000] ACPI: MCFG 00000000be08e430 0003C (v01 ALASKA    A M I
01072009 MSFT 00000097)
[    0.000000] ACPI: SSDT 00000000be08e470 004A6 (v01 Intel_ AoacTabl
00001000 INTL 20091112)
[    0.000000] ACPI: AAFT 00000000be08e918 000C2 (v01 ALASKA OEMAAFT
01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000be08e9e0 00038 (v01 ALASKA    A M I
01072009 AMI. 00000005)
[    0.000000] ACPI: SSDT 00000000be08ea18 0036D (v01 SataRe SataTabl
00001000 INTL 20091112)
[    0.000000] ACPI: SSDT 00000000be08ed88 009AA (v01  PmRef  Cpu0Ist
00003000 INTL 20051117)
[    0.000000] ACPI: SSDT 00000000be08f738 00A92 (v01  PmRef    CpuPm
00003000 INTL 20051117)
[    0.000000] ACPI: XMAR 00000000be0901d0 000B8 (v01 INTEL      SNB
00000001 INTL 00000001)
[    0.000000] ACPI: BGRT 00000000be090288 0003C (v00 ALASKA    A M I
01072009 AMI  00010013)
[    0.000000] Setting APIC routing to cluster x2apic.
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-000000042f600000
[    0.000000] Initmem setup node 0 0000000000000000-000000042f600000
[    0.000000]   NODE_DATA [00000003d7fe7000 - 00000003d7febfff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x0042f600
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[7] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009d
[    0.000000]     0: 0x00000100 -> 0x00020000
[    0.000000]     0: 0x00020200 -> 0x00040004
[    0.000000]     0: 0x00040005 -> 0x000bd8a7
[    0.000000]     0: 0x000be0e7 -> 0x000beb81
[    0.000000]     0: 0x000beff2 -> 0x000bf000
[    0.000000]     0: 0x00100000 -> 0x0042f600
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI 0-255
[    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] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 0000000020000000 - 0000000020200000
[    0.000000] PM: Registered nosave memory: 0000000040004000 - 0000000040005000
[    0.000000] PM: Registered nosave memory: 00000000bd8a7000 - 00000000bde1f000
[    0.000000] PM: Registered nosave memory: 00000000bde1f000 - 00000000be09f000
[    0.000000] PM: Registered nosave memory: 00000000be09f000 - 00000000be0a4000
[    0.000000] PM: Registered nosave memory: 00000000be0a4000 - 00000000be0e7000
[    0.000000] PM: Registered nosave memory: 00000000beb81000 - 00000000beff2000
[    0.000000] PM: Registered nosave memory: 00000000bf000000 - 00000000bf800000
[    0.000000] PM: Registered nosave memory: 00000000bf800000 - 00000000cfa00000
[    0.000000] PM: Registered nosave memory: 00000000cfa00000 - 00000000f8000000
[    0.000000] PM: Registered nosave memory: 00000000f8000000 - 00000000fc000000
[    0.000000] PM: Registered nosave memory: 00000000fc000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed00000
[    0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fed04000
[    0.000000] PM: Registered nosave memory: 00000000fed04000 - 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 - 00000000ff000000
[    0.000000] PM: Registered nosave memory: 00000000ff000000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at cfa00000 (gap:
cfa00000:28600000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256
nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8803d7c00000 s83072
r8192 d23424 u524288
[    3.860481] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 4048188
[    3.860484] Policy zone: Normal
[    3.860487] Kernel command line: placeholder
root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
earlyprintk=xen
[    3.860828] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    3.861070] invalid opcode: 0000 [#1] SMP
[    3.861073] CPU 0
[    3.861074] Modules linked in:
[    3.861076]
[    3.861078] Pid: 0, comm: swapper Not tainted 3.2.0-25-generic
#40-Ubuntu To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extre6
[    3.861083] RIP: e030:[<ffffffff8101d82c>]  [<ffffffff8101d82c>]
xstate_enable+0x3c/0x50
[    3.861090] RSP: e02b:ffffffff81c01e58  EFLAGS: 00010046
[    3.861092] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX: 0000000000000000
[    3.861094] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 0000000000002660
[    3.861096] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09: ffffffff81c01e94
[    3.861098] R10: 00000000ffffffff R11: 00000000ffffffff R12: ffffffff81c01e90
[    3.861100] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15: ffff8803d7c0c480
[    3.861104] FS:  0000000000000000(0000) GS:ffff8803d7c00000(0000)
knlGS:0000000000000000
[    3.861107] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    3.861108] CR2: 0000000000000000 CR3: 0000000001c05000 CR4: 0000000000002660
[    3.861111] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    3.861113] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    3.861115] Process swapper (pid: 0, threadinfo ffffffff81c00000,
task ffffffff81c0d020)
[    3.861117] Stack:
[    3.861119]  ffffffff81c01ec8 ffffffff81d04795 ffff8803d7c0b150
ffff8803d7c0b950
[    3.861123]  ffff8803d7c0b150 ffff8803d7c0b950 0000024000000007
0000000000000340
[    3.861127]  0000000000000004 0000000000000008 0000000000000004
0000000000000000
[    3.861131] Call Trace:
[    3.861136]  [<ffffffff81d04795>] xstate_enable_boot_cpu+0xa9/0x174
[    3.861141]  [<ffffffff8163660b>] xsave_init+0x26/0x28
[    3.861143]  [<ffffffff816388d1>] cpu_init+0x2bb/0x2d8
[    3.861146]  [<ffffffff81d00f92>] trap_init+0x169/0x171
[    3.861149]  [<ffffffff81cfba28>] start_kernel+0x1d5/0x3c7
[    3.861153]  [<ffffffff81cfb388>] x86_64_start_reservations+0x132/0x136
[    3.861156]  [<ffffffff81cfef27>] xen_start_kernel+0x5d9/0x5e0
[    3.861157] Code: 00 04 00 ff 14 25 90 76 c1 81 48 89 c7 48 81 cf
00 00 04 00 ff 14 25 98 76 c1 81 48 8b 05 cd 0d dc 00 31 c9 48
[    3.861191] RIP  [<ffffffff8101d82c>] xstate_enable+0x3c/0x50
[    3.861194]  RSP <ffffffff81c01e58

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 02:45:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 02: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 1Sg5U3-0005Nx-Tm; Sun, 17 Jun 2012 02:44: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 1Sg5U2-0005Ns-G8
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 02:44:58 +0000
Received: from [85.158.143.35:46243] by server-3.bemta-4.messagelabs.com id
	2C/E1-05808-9A44DDF4; Sun, 17 Jun 2012 02:44:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339901097!5609086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13140 invoked from network); 17 Jun 2012 02:44:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 02:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,784,1330905600"; d="scan'208";a="13062520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 02:44:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 03:44:56 +0100
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 1Sg5U0-0001fq-9m;
	Sun, 17 Jun 2012 02:44:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sg5U0-0001Ub-2r;
	Sun, 17 Jun 2012 03:44:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Sg5U0-0001Ub-2r@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 03:44:56 +0100
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-amd64-xl-qemuu-winxpsp3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-qemuu-winxpsp3
test windows-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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6


  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-qemuu-winxpsp3.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13061 fail [host=bush-cricket] / 13025 ok.
Failure / basis pass flights: 13061 / 13025
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-6d8b472233779c2a028a03843603030d2b1aee86 http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-9dffb1864f2c
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 17 nodes in revision graph
Searching for test results:
 11868 fail irrelevant
 11892 fail irrelevant
 11871 fail irrelevant
 11901 fail irrelevant
 11893 fail irrelevant
 11905 fail irrelevant
 11894 fail irrelevant
 11902 fail irrelevant
 11895 fail irrelevant
 11896 fail irrelevant
 11907 fail irrelevant
 11903 fail irrelevant
 11904 fail irrelevant
 11918 []
 11911 fail irrelevant
 11979 fail irrelevant
 12007 []
 11995 []
 11959 fail irrelevant
 11980 fail irrelevant
 11981 fail irrelevant
 11934 fail irrelevant
 11962 fail irrelevant
 11937 fail irrelevant
 11942 []
 11965 fail irrelevant
 11943 fail irrelevant
 11944 fail irrelevant
 11967 fail irrelevant
 11946 fail irrelevant
 11955 fail irrelevant
 11957 fail irrelevant
 11973 []
 11997 []
 11986 fail irrelevant
 11976 fail irrelevant
 11978 fail irrelevant
 11988 []
 12001 fail irrelevant
 11991 []
 12003 fail irrelevant
 12022 fail irrelevant
 12018 []
 12031 fail irrelevant
 12024 fail irrelevant
 12043 fail irrelevant
 12035 fail irrelevant
 12073 fail irrelevant
 12090 fail irrelevant
 12053 fail irrelevant
 12079 fail irrelevant
 12120 fail irrelevant
 12099 fail irrelevant
 12062 fail irrelevant
 12085 fail irrelevant
 12135 fail irrelevant
 12132 fail irrelevant
 12104 fail irrelevant
 12106 fail irrelevant
 12115 fail irrelevant
 12127 []
 12130 fail irrelevant
 12144 fail irrelevant
 12156 fail irrelevant
 12213 fail irrelevant
 12170 fail irrelevant
 12173 []
 12217 fail irrelevant
 12195 fail irrelevant
 12177 fail irrelevant
 12201 fail irrelevant
 12180 fail irrelevant
 12231 fail irrelevant
 12183 fail irrelevant
 12204 fail irrelevant
 12185 fail irrelevant
 12220 fail irrelevant
 12244 fail irrelevant
 12188 fail irrelevant
 12206 fail irrelevant
 12235 fail irrelevant
 12210 fail irrelevant
 12247 fail irrelevant
 12225 fail irrelevant
 12228 fail irrelevant
 12248 fail irrelevant
 12230 fail irrelevant
 12249 fail irrelevant
 12237 fail irrelevant
 12250 fail irrelevant
 12252 fail irrelevant
 12278 fail irrelevant
 12351 fail irrelevant
 12352 fail irrelevant
 12353 []
 12414 []
 12399 fail irrelevant
 12401 fail irrelevant
 12377 []
 12385 fail irrelevant
 12437 fail irrelevant
 12389 fail irrelevant
 12392 []
 12407 fail irrelevant
 12394 fail irrelevant
 12423 fail irrelevant
 12431 fail irrelevant
 12451 []
 12445 []
 12461 fail irrelevant
 12456 fail irrelevant
 12481 fail irrelevant
 12476 fail irrelevant
 12519 fail irrelevant
 12542 fail irrelevant
 12529 fail irrelevant
 12493 fail irrelevant
 12552 fail irrelevant
 12504 fail irrelevant
 12545 fail irrelevant
 12534 fail irrelevant
 12548 fail irrelevant
 12559 fail irrelevant
 12579 fail irrelevant
 12563 fail irrelevant
 12587 fail irrelevant
 12635 fail irrelevant
 12650 []
 12668 fail irrelevant
 12702 fail irrelevant
 12639 fail irrelevant
 12658 []
 12693 fail irrelevant
 12671 fail irrelevant
 12698 fail irrelevant
 12685 fail irrelevant
 12695 fail irrelevant
 12701 fail irrelevant
 12709 fail irrelevant
 12712 fail irrelevant
 12716 pass irrelevant
 12721 pass irrelevant
 12723 pass irrelevant
 12727 pass irrelevant
 12748 pass irrelevant
 12728 pass irrelevant
 12729 pass irrelevant
 12753 pass irrelevant
 12732 pass irrelevant
 12754 pass irrelevant
 12755 pass irrelevant
 12786 pass irrelevant
 12733 pass irrelevant
 12756 pass irrelevant
 12738 pass irrelevant
 12740 pass irrelevant
 12758 pass irrelevant
 12743 pass irrelevant
 12760 pass irrelevant
 12788 pass irrelevant
 12745 pass irrelevant
 12761 pass irrelevant
 12797 pass irrelevant
 12763 pass irrelevant
 12789 pass irrelevant
 12790 pass irrelevant
 12791 pass irrelevant
 12800 pass irrelevant
 12792 pass irrelevant
 12782 pass irrelevant
 12793 pass irrelevant
 12806 pass irrelevant
 12823 pass irrelevant
 12827 pass irrelevant
 12828 []
 12834 pass irrelevant
 12860 pass irrelevant
 12889 pass irrelevant
 12849 pass irrelevant
 12852 pass irrelevant
 12854 pass irrelevant
 12856 pass irrelevant
 12857 pass irrelevant
 12893 pass irrelevant
 12858 pass irrelevant
 12859 pass irrelevant
 12876 pass irrelevant
 12884 pass irrelevant
 12887 pass irrelevant
 12923 pass irrelevant
 12907 pass irrelevant
 12915 pass irrelevant
 12910 pass irrelevant
 12912 pass irrelevant
 12934 pass irrelevant
 12920 pass irrelevant
 12921 pass irrelevant
 12925 pass irrelevant
 12939 pass irrelevant
 12945 pass irrelevant
 12947 pass irrelevant
 12951 pass irrelevant
 13019 pass irrelevant
 12956 pass irrelevant
 12958 pass irrelevant
 13004 pass irrelevant
 13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 12981 pass irrelevant
 12960 pass irrelevant
 12964 pass irrelevant
 13038 []
 12967 pass irrelevant
 12968 pass irrelevant
 12969 pass irrelevant
 12971 pass irrelevant
 12972 pass irrelevant
 13031 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
 12975 pass irrelevant
 12976 pass irrelevant
 12977 pass irrelevant
 12988 pass irrelevant
 12978 pass irrelevant
 13020 pass irrelevant
 12979 pass irrelevant
 12995 pass irrelevant
 12980 pass irrelevant
 12996 pass irrelevant
 13006 pass irrelevant
 12997 pass irrelevant
 12998 pass irrelevant
 13023 pass irrelevant
 13012 pass irrelevant
 13051 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 12999 pass irrelevant
 13013 pass irrelevant
 13002 pass irrelevant
 13033 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13003 pass irrelevant
 13014 pass irrelevant
 13045 []
 13015 pass irrelevant
 13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13016 pass irrelevant
 13034 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13018 pass irrelevant
 13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13028 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13046 []
 13029 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13030 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
 13037 []
 13036 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13053 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13061 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13067 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13070 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13072 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
Searching for interesting versions
 Result found: flight 13024 (pass), for basis pass
 Result found: flight 13051 (fail), for basis failure
 Repro found: flight 13067 (pass), for basis pass
 Repro found: flight 13070 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
No revisions left to test, checking graph state.
 Result found: flight 13024 (pass), for last pass
 Result found: flight 13033 (fail), for first failure
 Repro found: flight 13034 (pass), for last pass
 Repro found: flight 13036 (fail), for first failure
 Repro found: flight 13067 (pass), for last pass
 Repro found: flight 13072 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-qemuu-winxpsp3.windows-install.{dot,ps,png,html}.
----------------------------------------
13072: tolerable ALL FAIL

flight 13072 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13072/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested


jobs:
 test-amd64-amd64-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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 02:45:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 02: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 1Sg5U3-0005Nx-Tm; Sun, 17 Jun 2012 02:44: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 1Sg5U2-0005Ns-G8
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 02:44:58 +0000
Received: from [85.158.143.35:46243] by server-3.bemta-4.messagelabs.com id
	2C/E1-05808-9A44DDF4; Sun, 17 Jun 2012 02:44:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1339901097!5609086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13140 invoked from network); 17 Jun 2012 02:44:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 02:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,784,1330905600"; d="scan'208";a="13062520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 02:44:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 03:44:56 +0100
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 1Sg5U0-0001fq-9m;
	Sun, 17 Jun 2012 02:44:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sg5U0-0001Ub-2r;
	Sun, 17 Jun 2012 03:44:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Sg5U0-0001Ub-2r@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 03:44:56 +0100
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-amd64-xl-qemuu-winxpsp3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-qemuu-winxpsp3
test windows-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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6


  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-qemuu-winxpsp3.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13061 fail [host=bush-cricket] / 13025 ok.
Failure / basis pass flights: 13061 / 13025
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-6d8b472233779c2a028a03843603030d2b1aee86 http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-9dffb1864f2c
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 17 nodes in revision graph
Searching for test results:
 11868 fail irrelevant
 11892 fail irrelevant
 11871 fail irrelevant
 11901 fail irrelevant
 11893 fail irrelevant
 11905 fail irrelevant
 11894 fail irrelevant
 11902 fail irrelevant
 11895 fail irrelevant
 11896 fail irrelevant
 11907 fail irrelevant
 11903 fail irrelevant
 11904 fail irrelevant
 11918 []
 11911 fail irrelevant
 11979 fail irrelevant
 12007 []
 11995 []
 11959 fail irrelevant
 11980 fail irrelevant
 11981 fail irrelevant
 11934 fail irrelevant
 11962 fail irrelevant
 11937 fail irrelevant
 11942 []
 11965 fail irrelevant
 11943 fail irrelevant
 11944 fail irrelevant
 11967 fail irrelevant
 11946 fail irrelevant
 11955 fail irrelevant
 11957 fail irrelevant
 11973 []
 11997 []
 11986 fail irrelevant
 11976 fail irrelevant
 11978 fail irrelevant
 11988 []
 12001 fail irrelevant
 11991 []
 12003 fail irrelevant
 12022 fail irrelevant
 12018 []
 12031 fail irrelevant
 12024 fail irrelevant
 12043 fail irrelevant
 12035 fail irrelevant
 12073 fail irrelevant
 12090 fail irrelevant
 12053 fail irrelevant
 12079 fail irrelevant
 12120 fail irrelevant
 12099 fail irrelevant
 12062 fail irrelevant
 12085 fail irrelevant
 12135 fail irrelevant
 12132 fail irrelevant
 12104 fail irrelevant
 12106 fail irrelevant
 12115 fail irrelevant
 12127 []
 12130 fail irrelevant
 12144 fail irrelevant
 12156 fail irrelevant
 12213 fail irrelevant
 12170 fail irrelevant
 12173 []
 12217 fail irrelevant
 12195 fail irrelevant
 12177 fail irrelevant
 12201 fail irrelevant
 12180 fail irrelevant
 12231 fail irrelevant
 12183 fail irrelevant
 12204 fail irrelevant
 12185 fail irrelevant
 12220 fail irrelevant
 12244 fail irrelevant
 12188 fail irrelevant
 12206 fail irrelevant
 12235 fail irrelevant
 12210 fail irrelevant
 12247 fail irrelevant
 12225 fail irrelevant
 12228 fail irrelevant
 12248 fail irrelevant
 12230 fail irrelevant
 12249 fail irrelevant
 12237 fail irrelevant
 12250 fail irrelevant
 12252 fail irrelevant
 12278 fail irrelevant
 12351 fail irrelevant
 12352 fail irrelevant
 12353 []
 12414 []
 12399 fail irrelevant
 12401 fail irrelevant
 12377 []
 12385 fail irrelevant
 12437 fail irrelevant
 12389 fail irrelevant
 12392 []
 12407 fail irrelevant
 12394 fail irrelevant
 12423 fail irrelevant
 12431 fail irrelevant
 12451 []
 12445 []
 12461 fail irrelevant
 12456 fail irrelevant
 12481 fail irrelevant
 12476 fail irrelevant
 12519 fail irrelevant
 12542 fail irrelevant
 12529 fail irrelevant
 12493 fail irrelevant
 12552 fail irrelevant
 12504 fail irrelevant
 12545 fail irrelevant
 12534 fail irrelevant
 12548 fail irrelevant
 12559 fail irrelevant
 12579 fail irrelevant
 12563 fail irrelevant
 12587 fail irrelevant
 12635 fail irrelevant
 12650 []
 12668 fail irrelevant
 12702 fail irrelevant
 12639 fail irrelevant
 12658 []
 12693 fail irrelevant
 12671 fail irrelevant
 12698 fail irrelevant
 12685 fail irrelevant
 12695 fail irrelevant
 12701 fail irrelevant
 12709 fail irrelevant
 12712 fail irrelevant
 12716 pass irrelevant
 12721 pass irrelevant
 12723 pass irrelevant
 12727 pass irrelevant
 12748 pass irrelevant
 12728 pass irrelevant
 12729 pass irrelevant
 12753 pass irrelevant
 12732 pass irrelevant
 12754 pass irrelevant
 12755 pass irrelevant
 12786 pass irrelevant
 12733 pass irrelevant
 12756 pass irrelevant
 12738 pass irrelevant
 12740 pass irrelevant
 12758 pass irrelevant
 12743 pass irrelevant
 12760 pass irrelevant
 12788 pass irrelevant
 12745 pass irrelevant
 12761 pass irrelevant
 12797 pass irrelevant
 12763 pass irrelevant
 12789 pass irrelevant
 12790 pass irrelevant
 12791 pass irrelevant
 12800 pass irrelevant
 12792 pass irrelevant
 12782 pass irrelevant
 12793 pass irrelevant
 12806 pass irrelevant
 12823 pass irrelevant
 12827 pass irrelevant
 12828 []
 12834 pass irrelevant
 12860 pass irrelevant
 12889 pass irrelevant
 12849 pass irrelevant
 12852 pass irrelevant
 12854 pass irrelevant
 12856 pass irrelevant
 12857 pass irrelevant
 12893 pass irrelevant
 12858 pass irrelevant
 12859 pass irrelevant
 12876 pass irrelevant
 12884 pass irrelevant
 12887 pass irrelevant
 12923 pass irrelevant
 12907 pass irrelevant
 12915 pass irrelevant
 12910 pass irrelevant
 12912 pass irrelevant
 12934 pass irrelevant
 12920 pass irrelevant
 12921 pass irrelevant
 12925 pass irrelevant
 12939 pass irrelevant
 12945 pass irrelevant
 12947 pass irrelevant
 12951 pass irrelevant
 13019 pass irrelevant
 12956 pass irrelevant
 12958 pass irrelevant
 13004 pass irrelevant
 13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 12981 pass irrelevant
 12960 pass irrelevant
 12964 pass irrelevant
 13038 []
 12967 pass irrelevant
 12968 pass irrelevant
 12969 pass irrelevant
 12971 pass irrelevant
 12972 pass irrelevant
 13031 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
 12975 pass irrelevant
 12976 pass irrelevant
 12977 pass irrelevant
 12988 pass irrelevant
 12978 pass irrelevant
 13020 pass irrelevant
 12979 pass irrelevant
 12995 pass irrelevant
 12980 pass irrelevant
 12996 pass irrelevant
 13006 pass irrelevant
 12997 pass irrelevant
 12998 pass irrelevant
 13023 pass irrelevant
 13012 pass irrelevant
 13051 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 12999 pass irrelevant
 13013 pass irrelevant
 13002 pass irrelevant
 13033 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13003 pass irrelevant
 13014 pass irrelevant
 13045 []
 13015 pass irrelevant
 13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13016 pass irrelevant
 13034 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13018 pass irrelevant
 13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13028 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13046 []
 13029 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13030 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
 13037 []
 13036 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13053 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13061 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13067 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13070 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13072 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
Searching for interesting versions
 Result found: flight 13024 (pass), for basis pass
 Result found: flight 13051 (fail), for basis failure
 Repro found: flight 13067 (pass), for basis pass
 Repro found: flight 13070 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
No revisions left to test, checking graph state.
 Result found: flight 13024 (pass), for last pass
 Result found: flight 13033 (fail), for first failure
 Repro found: flight 13034 (pass), for last pass
 Repro found: flight 13036 (fail), for first failure
 Repro found: flight 13067 (pass), for last pass
 Repro found: flight 13072 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-qemuu-winxpsp3.windows-install.{dot,ps,png,html}.
----------------------------------------
13072: tolerable ALL FAIL

flight 13072 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13072/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install   fail baseline untested


jobs:
 test-amd64-amd64-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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 03:05:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 03:05: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 1Sg5mz-0005dS-QB; Sun, 17 Jun 2012 03:04:33 +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 1Sg5mx-0005dN-Rq
	for xen-devel@lists.xen.org; Sun, 17 Jun 2012 03:04:32 +0000
Received: from [85.158.143.35:23117] by server-1.bemta-4.messagelabs.com id
	98/80-24392-F394DDF4; Sun, 17 Jun 2012 03:04:31 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339902267!13463814!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10082 invoked from network); 17 Jun 2012 03:04:28 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 03:04:28 -0000
Received: by qadb33 with SMTP id b33so575226qad.16
	for <xen-devel@lists.xen.org>; Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZB/pZsEFqISJS7paxrd7XLg1vkfvh6qFBCfup8jxDTY=;
	b=E/1DnWGrPbNZN7bWLmigMblJvqoz7j1JlC5SO/ygDl1QeKZC+GFJsPBxy4KyYx/FBt
	QrQpr+Nh5acpGqOYph3887Nh6+def3yPioJLU7M4veP66q2u+0Nfw5FSC5LSxYwq5oY3
	R8C3qh8w0KDKaRqxO9KjgFCP+DZX2wPww6yr2LXmbqluVIvHe7i7RYzUu7pPP9YhyJz4
	dvIW4RTlVgI47uHP2KONInARv2H7qK2xjJX8t40aUKTF38nOllvKo2zMj5GXpYIEzf8Z
	Yhr6vn1/zIPf7fmBSnUqBgNtSF0f5JzKarJkY0itU4N13KIMs8kNKiEE2KgjZStFj0XB
	wqaA==
MIME-Version: 1.0
Received: by 10.224.176.148 with SMTP id be20mr19919326qab.64.1339902266482;
	Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
In-Reply-To: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
References: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
Date: Sat, 16 Jun 2012 20:04:26 -0700
Message-ID: <CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Rolu <rolu@roce.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0413737885644258119=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0413737885644258119==
Content-Type: multipart/alternative; boundary=20cf302d4e32a0a05c04c2a24e7d

--20cf302d4e32a0a05c04c2a24e7d
Content-Type: text/plain; charset=ISO-8859-1

On Jun 16, 2012 5:56 PM, "Rolu" <rolu@roce.org> wrote:
>
> When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
> crashes. I've included a serial console log below.
>
> I've used:
> Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
> apply the AT_EMPTY_PATH patch from
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to
> get it to compile.
> Linux 3.2.0-25, which is the default kernel in Ubuntu's repository right
now.
> Ubuntu 12.04 Precise
>
> Booting with the default Xen 4.1 from the Ubuntu repositories works.
>
> Using the kernel from
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is
> a mainline Linux kernel (and also more recent) works with my compiled
> version of Xen 4.2
>
> So,
> * Is xen 4.2 not happy with the 3.2 kernel I've used?
> * Is this due to something Ubuntu modified in their default kernel?
> * Is this an issue with Xen?
> * Did I break something?

This is an issue with the Ubuntu kernel. Check this thread out:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html

Adding xsave=0 to the Xen kernel line in grub is the workaround.

> -----
>
>  __  __            _  _    ____                     _        _     _
>  \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
>  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
>  /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>
> (XEN) Xen version 4.2-unstable (root@roce.org) (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012
> (XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864f2c
> (XEN) Bootloader: GRUB 1.99-21ubuntu3.1
> (XEN) Command line: placeholder loglvl=all guest_loglvl=all
> console_timestamps=1 noreboot com1=115200,8n1,0x3f8,4 console=com1,vga
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 3 MBR signatures
> (XEN)  Found 3 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009d800 (usable)
> (XEN)  000000000009d800 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040004000 (usable)
> (XEN)  0000000040004000 - 0000000040005000 (reserved)
> (XEN)  0000000040005000 - 00000000bd8a7000 (usable)
> (XEN)  00000000bd8a7000 - 00000000bde1f000 (reserved)
> (XEN)  00000000bde1f000 - 00000000be09f000 (ACPI NVS)
> (XEN)  00000000be09f000 - 00000000be0a4000 (ACPI data)
> (XEN)  00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
> (XEN)  00000000be0e7000 - 00000000beb81000 (usable)
> (XEN)  00000000beb81000 - 00000000beff2000 (reserved)
> (XEN)  00000000beff2000 - 00000000bf000000 (usable)
> (XEN)  00000000bf800000 - 00000000cfa00000 (reserved)
> (XEN)  00000000f8000000 - 00000000fc000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec01000 (reserved)
> (XEN)  00000000fed00000 - 00000000fed04000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ff000000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 000000042f600000 (usable)
> (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
> (XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA    A M I  1072009 AMI
10013)
> (XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA    A M I  1072009 AMI
10013)
> (XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA    A M I       14 INTL
20051117)
> (XEN) ACPI: FACS BE09DF80, 0040
> (XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA    A M I  1072009 AMI
10013)
> (XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL       HCG        1 TFSM
 F4240)
> (XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA    A M I  1072009 MSFT
97)
> (XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl     1000 INTL
20091112)
> (XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT   1072009 MSFT
97)
> (XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA    A M I  1072009 AMI.
 5)
> (XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl     1000 INTL
20091112)
> (XEN) ACPI: SSDT BE08ED88, 09AA (r1  PmRef  Cpu0Ist     3000 INTL
20051117)
> (XEN) ACPI: SSDT BE08F738, 0A92 (r1  PmRef    CpuPm     3000 INTL
20051117)
> (XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL      SNB         1 INTL
 1)
> (XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA    A M I  1072009 AMI
10013)
> (XEN) System RAM: 16086MB (16473004kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-000000042f600000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000fceb0
> (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 -
> be09df80/0000000000000000, using 32
> (XEN) ACPI:                  wakeup_vec[be09df8c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> (XEN) Processor #2 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
> (XEN) Processor #4 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
> (XEN) Processor #6 7:10 APIC version 21
> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 2, 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) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
> (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
> (XEN) Switched to APIC driver x2apic_cluster.
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 3300.138 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
> (XEN) mce_intel.c:1239: 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 f8000000 segment 0000 buses 00 - 3f
> (XEN) PCI: MCFG area at f8000000 reserved in E820
> (XEN) PCI: Using MCFG for segment 0000 bus 00-3f
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation enabled.
> (XEN) Intel VT-d Interrupt Remapping enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.
> (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) TSC deadline timer enabled
> (XEN) [2012-06-17 00:22:20] Platform timer is 14.318MHz HPET
> (XEN) [2012-06-17 00:22:20] Allocated console ring of 32 KiB.
> (XEN) [2012-06-17 00:22:20] VMX: Supported advanced features:
> (XEN) [2012-06-17 00:22:20]  - APIC MMIO access virtualisation
> (XEN) [2012-06-17 00:22:20]  - APIC TPR shadow
> (XEN) [2012-06-17 00:22:20]  - Extended Page Tables (EPT)
> (XEN) [2012-06-17 00:22:20]  - Virtual-Processor Identifiers (VPID)
> (XEN) [2012-06-17 00:22:20]  - Virtual NMI
> (XEN) [2012-06-17 00:22:20]  - MSR direct-access bitmap
> (XEN) [2012-06-17 00:22:20]  - Unrestricted Guest
> (XEN) [2012-06-17 00:22:20] HVM: ASIDs enabled.
> (XEN) [2012-06-17 00:22:20] HVM: VMX enabled
> (XEN) [2012-06-17 00:22:20] HVM: Hardware Assisted Paging (HAP) detected
> (XEN) [2012-06-17 00:22:20] HVM: HAP page sizes: 4kB, 2MB
> (XEN) [2012-06-17 00:22:20] Brought up 4 CPUs
> (XEN) [2012-06-17 00:22:20] ACPI sleep modes: S3
> (XEN) [2012-06-17 00:22:20] mcheck_poll: Machine check polling timer
started.
> (XEN) [2012-06-17 00:22:20] *** LOADING DOMAIN 0 ***
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1000000
> memsz=0xad5000
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1c00000
> memsz=0xe50e0
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1ce6000
> memsz=0x14480
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1cfb000
> memsz=0x364000
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: memory: 0x1000000 ->
0x205f000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_OS = "linux"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_VERSION = "2.6"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: XEN_VERSION = "xen-3.0"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: VIRT_BASE =
0xffffffff80000000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: ENTRY = 0xffffffff81cfb200
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HYPERCALL_PAGE =
> 0xffffffff81001000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: FEATURES =
> "!writable_page_tables|pae_pgdir_above_4gb"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PAE_MODE = "yes"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: LOADER = "generic"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: unknown xen elf note (0xd)
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: SUSPEND_CANCEL = 0x1
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HV_START_LOW =
> 0xffff800000000000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PADDR_OFFSET = 0x0
> (XEN) [2012-06-17 00:22:20] elf_xen_addr_calc_check: addresses:
> (XEN) [2012-06-17 00:22:20]     virt_base        = 0xffffffff80000000
> (XEN) [2012-06-17 00:22:20]     elf_paddr_offset = 0x0
> (XEN) [2012-06-17 00:22:20]     virt_offset      = 0xffffffff80000000
> (XEN) [2012-06-17 00:22:20]     virt_kstart      = 0xffffffff81000000
> (XEN) [2012-06-17 00:22:20]     virt_kend        = 0xffffffff8205f000
> (XEN) [2012-06-17 00:22:20]     virt_entry       = 0xffffffff81cfb200
> (XEN) [2012-06-17 00:22:20]     p2m_base         = 0xffffffffffffffff
> (XEN) [2012-06-17 00:22:20]  Xen  kernel: 64-bit, lsb, compat32
> (XEN) [2012-06-17 00:22:20]  Dom0 kernel: 64-bit, PAE, lsb, paddr
> 0x1000000 -> 0x205f000
> (XEN) [2012-06-17 00:22:20] PHYSICAL MEMORY ARRANGEMENT:
> (XEN) [2012-06-17 00:22:20]  Dom0 alloc.:
> 0000000418000000->0000000420000000 (3987995 pages to be allocated)
> (XEN) [2012-06-17 00:22:20]  Init. ramdisk:
000000042d02f000->000000042f5ff400
> (XEN) [2012-06-17 00:22:20] VIRTUAL MEMORY ARRANGEMENT:
> (XEN) [2012-06-17 00:22:20]  Loaded kernel:
ffffffff81000000->ffffffff8205f000
> (XEN) [2012-06-17 00:22:20]  Init. ramdisk:
ffffffff8205f000->ffffffff8462f400
> (XEN) [2012-06-17 00:22:20]  Phys-Mach map:
ffffffff84630000->ffffffff864eff60
> (XEN) [2012-06-17 00:22:20]  Start info:
 ffffffff864f0000->ffffffff864f04b4
> (XEN) [2012-06-17 00:22:20]  Page tables:
ffffffff864f1000->ffffffff86528000
> (XEN) [2012-06-17 00:22:20]  Boot stack:
 ffffffff86528000->ffffffff86529000
> (XEN) [2012-06-17 00:22:20]  TOTAL:
ffffffff80000000->ffffffff86800000
> (XEN) [2012-06-17 00:22:20]  ENTRY ADDRESS: ffffffff81cfb200
> (XEN) [2012-06-17 00:22:20] Dom0 has maximum 4 VCPUs
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 0 at
> 0xffffffff81000000 -> 0xffffffff81ad5000
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 1 at
> 0xffffffff81c00000 -> 0xffffffff81ce50e0
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 2 at
> 0xffffffff81ce6000 -> 0xffffffff81cfa480
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 3 at
> 0xffffffff81cfb000 -> 0xffffffff81dd3000
> (XEN) [2012-06-17 00:22:22] Scrubbing Free RAM: .done.
> (XEN) [2012-06-17 00:22:22] Initial low memory virq threshold set at
> 0x4000 pages.
> (XEN) [2012-06-17 00:22:22] Std. Loglevel: All
> (XEN) [2012-06-17 00:22:22] Guest Loglevel: All
> (XEN) [2012-06-17 00:22:22] Xen is relinquishing VGA console.
> (XEN) [2012-06-17 00:22:22] *** Serial input -> DOM0 (type 'CTRL-a'
> three times to switch input to Xen)
> (XEN) [2012-06-17 00:22:22] Freed 244kB init memory.
> mapping kernel into physical memory
> Xen: setup ISA identity maps
> about to get started...
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.0-25-generic (buildd@crested) (gcc
> version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #40-Ubuntu SMP We)
> [    0.000000] Command line: placeholder
> root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
> earlyprintk=xen
> [    0.000000] KERNEL supported cpus:
> [    0.000000]   Intel GenuineIntel
> [    0.000000]   AMD AuthenticAMD
> [    0.000000]   Centaur CentaurHauls
> [    0.000000] Freeing  9d-100 pfn range: 99 pages freed
> [    0.000000] Freeing  20000-20200 pfn range: 512 pages freed
> [    0.000000] Freeing  40004-40005 pfn range: 1 pages freed
> [    0.000000] Freeing  bd8a7-be0e7 pfn range: 2112 pages freed
> [    0.000000] Freeing  beb81-beff2 pfn range: 1137 pages freed
> [    0.000000] Freeing  bf000-100000 pfn range: 266240 pages freed
> [    0.000000] Released 270101 pages of unused memory
> [    0.000000] Set 270101 page(s) to 1-1 mapping
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  Xen: 0000000000000000 - 000000000009d000 (usable)
> [    0.000000]  Xen: 000000000009d800 - 0000000000100000 (reserved)
> [    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
> [    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
> [    0.000000]  Xen: 0000000020200000 - 0000000040004000 (usable)
> [    0.000000]  Xen: 0000000040004000 - 0000000040005000 (reserved)
> [    0.000000]  Xen: 0000000040005000 - 00000000bd8a7000 (usable)
> [    0.000000]  Xen: 00000000bd8a7000 - 00000000bde1f000 (reserved)
> [    0.000000]  Xen: 00000000bde1f000 - 00000000be09f000 (ACPI NVS)
> [    0.000000]  Xen: 00000000be09f000 - 00000000be0a4000 (ACPI data)
> [    0.000000]  Xen: 00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
> [    0.000000]  Xen: 00000000be0e7000 - 00000000beb81000 (usable)
> [    0.000000]  Xen: 00000000beb81000 - 00000000beff2000 (reserved)
> [    0.000000]  Xen: 00000000beff2000 - 00000000bf000000 (usable)
> [    0.000000]  Xen: 00000000bf800000 - 00000000cfa00000 (reserved)
> [    0.000000]  Xen: 00000000f8000000 - 00000000fc000000 (reserved)
> [    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
> [    0.000000]  Xen: 00000000fed00000 - 00000000fed04000 (reserved)
> [    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
> [    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  Xen: 00000000ff000000 - 0000000100000000 (reserved)
> [    0.000000]  Xen: 0000000100000000 - 000000042f600000 (usable)
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] DMI 2.7 present.
> [    0.000000] No AGP bridge found
> [    0.000000] last_pfn = 0x42f600 max_arch_pfn = 0x400000000
> [    0.000000] x2apic enabled by BIOS, switching to x2apic ops
> [    0.000000] last_pfn = 0xbf000 max_arch_pfn = 0x400000000
> [    0.000000] found SMP MP-table at [ffff8800000fceb0] fceb0
> [    0.000000] init_memory_mapping: 0000000000000000-00000000bf000000
> [    0.000000] init_memory_mapping: 0000000100000000-000000042f600000
> [    0.000000] RAMDISK: 0205f000 - 04630000
> [    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
> [    0.000000] ACPI: XSDT 00000000be084080 00084 (v01 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] ACPI: FACP 00000000be08e218 000F4 (v04 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] ACPI: DSDT 00000000be0841a0 0A077 (v02 ALASKA    A M I
> 00000014 INTL 20051117)
> [    0.000000] ACPI: FACS 00000000be09df80 00040
> [    0.000000] ACPI: APIC 00000000be08e310 00072 (v03 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] ACPI: ASF! 00000000be08e388 000A5 (v32 INTEL       HCG
> 00000001 TFSM 000F4240)
> [    0.000000] ACPI: MCFG 00000000be08e430 0003C (v01 ALASKA    A M I
> 01072009 MSFT 00000097)
> [    0.000000] ACPI: SSDT 00000000be08e470 004A6 (v01 Intel_ AoacTabl
> 00001000 INTL 20091112)
> [    0.000000] ACPI: AAFT 00000000be08e918 000C2 (v01 ALASKA OEMAAFT
> 01072009 MSFT 00000097)
> [    0.000000] ACPI: HPET 00000000be08e9e0 00038 (v01 ALASKA    A M I
> 01072009 AMI. 00000005)
> [    0.000000] ACPI: SSDT 00000000be08ea18 0036D (v01 SataRe SataTabl
> 00001000 INTL 20091112)
> [    0.000000] ACPI: SSDT 00000000be08ed88 009AA (v01  PmRef  Cpu0Ist
> 00003000 INTL 20051117)
> [    0.000000] ACPI: SSDT 00000000be08f738 00A92 (v01  PmRef    CpuPm
> 00003000 INTL 20051117)
> [    0.000000] ACPI: XMAR 00000000be0901d0 000B8 (v01 INTEL      SNB
> 00000001 INTL 00000001)
> [    0.000000] ACPI: BGRT 00000000be090288 0003C (v00 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] Setting APIC routing to cluster x2apic.
> [    0.000000] No NUMA configuration found
> [    0.000000] Faking a node at 0000000000000000-000000042f600000
> [    0.000000] Initmem setup node 0 0000000000000000-000000042f600000
> [    0.000000]   NODE_DATA [00000003d7fe7000 - 00000003d7febfff]
> [    0.000000] Zone PFN ranges:
> [    0.000000]   DMA      0x00000010 -> 0x00001000
> [    0.000000]   DMA32    0x00001000 -> 0x00100000
> [    0.000000]   Normal   0x00100000 -> 0x0042f600
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] early_node_map[7] active PFN ranges
> [    0.000000]     0: 0x00000010 -> 0x0000009d
> [    0.000000]     0: 0x00000100 -> 0x00020000
> [    0.000000]     0: 0x00020200 -> 0x00040004
> [    0.000000]     0: 0x00040005 -> 0x000bd8a7
> [    0.000000]     0: 0x000be0e7 -> 0x000beb81
> [    0.000000]     0: 0x000beff2 -> 0x000bf000
> [    0.000000]     0: 0x00100000 -> 0x0042f600
> [    0.000000] ACPI: PM-Timer IO Port: 0x408
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
> [    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> [    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI
0-255
> [    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] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> [    0.000000] PM: Registered nosave memory: 000000000009d000 -
000000000009e000
> [    0.000000] PM: Registered nosave memory: 000000000009e000 -
0000000000100000
> [    0.000000] PM: Registered nosave memory: 0000000020000000 -
0000000020200000
> [    0.000000] PM: Registered nosave memory: 0000000040004000 -
0000000040005000
> [    0.000000] PM: Registered nosave memory: 00000000bd8a7000 -
00000000bde1f000
> [    0.000000] PM: Registered nosave memory: 00000000bde1f000 -
00000000be09f000
> [    0.000000] PM: Registered nosave memory: 00000000be09f000 -
00000000be0a4000
> [    0.000000] PM: Registered nosave memory: 00000000be0a4000 -
00000000be0e7000
> [    0.000000] PM: Registered nosave memory: 00000000beb81000 -
00000000beff2000
> [    0.000000] PM: Registered nosave memory: 00000000bf000000 -
00000000bf800000
> [    0.000000] PM: Registered nosave memory: 00000000bf800000 -
00000000cfa00000
> [    0.000000] PM: Registered nosave memory: 00000000cfa00000 -
00000000f8000000
> [    0.000000] PM: Registered nosave memory: 00000000f8000000 -
00000000fc000000
> [    0.000000] PM: Registered nosave memory: 00000000fc000000 -
00000000fec00000
> [    0.000000] PM: Registered nosave memory: 00000000fec00000 -
00000000fec01000
> [    0.000000] PM: Registered nosave memory: 00000000fec01000 -
00000000fed00000
> [    0.000000] PM: Registered nosave memory: 00000000fed00000 -
00000000fed04000
> [    0.000000] PM: Registered nosave memory: 00000000fed04000 -
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 -
00000000ff000000
> [    0.000000] PM: Registered nosave memory: 00000000ff000000 -
0000000100000000
> [    0.000000] Allocating PCI resources starting at cfa00000 (gap:
> cfa00000:28600000)
> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 4.2-unstable (preserve-AD)
> [    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256
> nr_cpu_ids:4 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8803d7c00000 s83072
> r8192 d23424 u524288
> [    3.860481] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 4048188
> [    3.860484] Policy zone: Normal
> [    3.860487] Kernel command line: placeholder
> root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
> earlyprintk=xen
> [    3.860828] PID hash table entries: 4096 (order: 3, 32768 bytes)
> [    3.861070] invalid opcode: 0000 [#1] SMP
> [    3.861073] CPU 0
> [    3.861074] Modules linked in:
> [    3.861076]
> [    3.861078] Pid: 0, comm: swapper Not tainted 3.2.0-25-generic
> #40-Ubuntu To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extre6
> [    3.861083] RIP: e030:[<ffffffff8101d82c>]  [<ffffffff8101d82c>]
> xstate_enable+0x3c/0x50
> [    3.861090] RSP: e02b:ffffffff81c01e58  EFLAGS: 00010046
> [    3.861092] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX:
0000000000000000
> [    3.861094] RDX: 0000000000000000 RSI: 0000000000000007 RDI:
0000000000002660
> [    3.861096] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09:
ffffffff81c01e94
> [    3.861098] R10: 00000000ffffffff R11: 00000000ffffffff R12:
ffffffff81c01e90
> [    3.861100] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15:
ffff8803d7c0c480
> [    3.861104] FS:  0000000000000000(0000) GS:ffff8803d7c00000(0000)
> knlGS:0000000000000000
> [    3.861107] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    3.861108] CR2: 0000000000000000 CR3: 0000000001c05000 CR4:
0000000000002660
> [    3.861111] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
> [    3.861113] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
> [    3.861115] Process swapper (pid: 0, threadinfo ffffffff81c00000,
> task ffffffff81c0d020)
> [    3.861117] Stack:
> [    3.861119]  ffffffff81c01ec8 ffffffff81d04795 ffff8803d7c0b150
> ffff8803d7c0b950
> [    3.861123]  ffff8803d7c0b150 ffff8803d7c0b950 0000024000000007
> 0000000000000340
> [    3.861127]  0000000000000004 0000000000000008 0000000000000004
> 0000000000000000
> [    3.861131] Call Trace:
> [    3.861136]  [<ffffffff81d04795>] xstate_enable_boot_cpu+0xa9/0x174
> [    3.861141]  [<ffffffff8163660b>] xsave_init+0x26/0x28
> [    3.861143]  [<ffffffff816388d1>] cpu_init+0x2bb/0x2d8
> [    3.861146]  [<ffffffff81d00f92>] trap_init+0x169/0x171
> [    3.861149]  [<ffffffff81cfba28>] start_kernel+0x1d5/0x3c7
> [    3.861153]  [<ffffffff81cfb388>] x86_64_start_reservations+0x132/0x136
> [    3.861156]  [<ffffffff81cfef27>] xen_start_kernel+0x5d9/0x5e0
> [    3.861157] Code: 00 04 00 ff 14 25 90 76 c1 81 48 89 c7 48 81 cf
> 00 00 04 00 ff 14 25 98 76 c1 81 48 8b 05 cd 0d dc 00 31 c9 48
> [    3.861191] RIP  [<ffffffff8101d82c>] xstate_enable+0x3c/0x50
> [    3.861194]  RSP <ffffffff81c01e58
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--20cf302d4e32a0a05c04c2a24e7d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Jun 16, 2012 5:56 PM, &quot;Rolu&quot; &lt;<a href=3D"mailto:rolu@roce.o=
rg">rolu@roce.org</a>&gt; wrote:<br>
&gt;<br>
&gt; When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0<br>
&gt; crashes. I&#39;ve included a serial console log below.<br>
&gt;<br>
&gt; I&#39;ve used:<br>
&gt; Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to<br=
>
&gt; apply the AT_EMPTY_PATH patch from<br>
&gt; <a href=3D"http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg034=
60.html">http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html=
</a> to<br>
&gt; get it to compile.<br>
&gt; Linux 3.2.0-25, which is the default kernel in Ubuntu&#39;s repository=
 right now.<br>
&gt; Ubuntu 12.04 Precise<br>
&gt;<br>
&gt; Booting with the default Xen 4.1 from the Ubuntu repositories works.<b=
r>
&gt;<br>
&gt; Using the kernel from<br>
&gt; <a href=3D"http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/=
">http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/</a>, which is=
<br>
&gt; a mainline Linux kernel (and also more recent) works with my compiled<=
br>
&gt; version of Xen 4.2<br>
&gt;<br>
&gt; So,<br>
&gt; * Is xen 4.2 not happy with the 3.2 kernel I&#39;ve used?<br>
&gt; * Is this due to something Ubuntu modified in their default kernel?<br=
>
&gt; * Is this an issue with Xen?<br>
&gt; * Did I break something?</p>
<p>This is an issue with the Ubuntu kernel. Check this thread out:<br>
 <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.h=
tml">http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html</a>=
</p>
<p>Adding xsave=3D0 to the Xen kernel line in grub is the workaround.</p>
<p>&gt; -----<br>
&gt;<br>
&gt; =A0__ =A0__ =A0 =A0 =A0 =A0 =A0 =A0_ =A0_ =A0 =A0____ =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 _ =A0 =A0 =A0 =A0_ =A0 =A0 _<br>
&gt; =A0\ \/ /___ _ __ =A0 | || | =A0|___ \ =A0 =A0_ =A0 _ _ __ =A0___| |_ =
__ _| |__ | | ___<br>
&gt; =A0\ =A0// _ \ &#39;_ \ =A0| || |_ =A0 __) |__| | | | &#39;_ \/ __| __=
/ _` | &#39;_ \| |/ _ \<br>
&gt; =A0/ =A0\ =A0__/ | | | |__ =A0 _| / __/|__| |_| | | | \__ \ || (_| | |=
_) | | =A0__/<br>
&gt; =A0/_/\_\___|_| |_| =A0 =A0|_|(_)_____| =A0 \__,_|_| |_|___/\__\__,_|_=
.__/|_|\___|<br>
&gt;<br>
&gt; (XEN) Xen version 4.2-unstable (<a href=3D"mailto:root@roce.org">root@=
roce.org</a>) (gcc version 4.6.3<br>
&gt; (Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012<br>
&gt; (XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864=
f2c<br>
&gt; (XEN) Bootloader: GRUB 1.99-21ubuntu3.1<br>
&gt; (XEN) Command line: placeholder loglvl=3Dall guest_loglvl=3Dall<br>
&gt; console_timestamps=3D1 noreboot com1=3D115200,8n1,0x3f8,4 console=3Dco=
m1,vga<br>
&gt; (XEN) Video information:<br>
&gt; (XEN) =A0VGA is text mode 80x25, font 8x16<br>
&gt; (XEN) =A0VBE/DDC methods: V2; EDID transfer time: 1 seconds<br>
&gt; (XEN) Disc information:<br>
&gt; (XEN) =A0Found 3 MBR signatures<br>
&gt; (XEN) =A0Found 3 EDD information structures<br>
&gt; (XEN) Xen-e820 RAM map:<br>
&gt; (XEN) =A00000000000000000 - 000000000009d800 (usable)<br>
&gt; (XEN) =A0000000000009d800 - 00000000000a0000 (reserved)<br>
&gt; (XEN) =A000000000000e0000 - 0000000000100000 (reserved)<br>
&gt; (XEN) =A00000000000100000 - 0000000020000000 (usable)<br>
&gt; (XEN) =A00000000020000000 - 0000000020200000 (reserved)<br>
&gt; (XEN) =A00000000020200000 - 0000000040004000 (usable)<br>
&gt; (XEN) =A00000000040004000 - 0000000040005000 (reserved)<br>
&gt; (XEN) =A00000000040005000 - 00000000bd8a7000 (usable)<br>
&gt; (XEN) =A000000000bd8a7000 - 00000000bde1f000 (reserved)<br>
&gt; (XEN) =A000000000bde1f000 - 00000000be09f000 (ACPI NVS)<br>
&gt; (XEN) =A000000000be09f000 - 00000000be0a4000 (ACPI data)<br>
&gt; (XEN) =A000000000be0a4000 - 00000000be0e7000 (ACPI NVS)<br>
&gt; (XEN) =A000000000be0e7000 - 00000000beb81000 (usable)<br>
&gt; (XEN) =A000000000beb81000 - 00000000beff2000 (reserved)<br>
&gt; (XEN) =A000000000beff2000 - 00000000bf000000 (usable)<br>
&gt; (XEN) =A000000000bf800000 - 00000000cfa00000 (reserved)<br>
&gt; (XEN) =A000000000f8000000 - 00000000fc000000 (reserved)<br>
&gt; (XEN) =A000000000fec00000 - 00000000fec01000 (reserved)<br>
&gt; (XEN) =A000000000fed00000 - 00000000fed04000 (reserved)<br>
&gt; (XEN) =A000000000fed1c000 - 00000000fed20000 (reserved)<br>
&gt; (XEN) =A000000000fee00000 - 00000000fee01000 (reserved)<br>
&gt; (XEN) =A000000000ff000000 - 0000000100000000 (reserved)<br>
&gt; (XEN) =A00000000100000000 - 000000042f600000 (usable)<br>
&gt; (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)<br>
&gt; (XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA =A0 =A0A M I =A0 =A0 =A0 14=
 INTL 20051117)<br>
&gt; (XEN) ACPI: FACS BE09DF80, 0040<br>
&gt; (XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL =A0 =A0 =A0 HCG =A0 =A0 =A0=
 =A01 TFSM =A0 =A0F4240)<br>
&gt; (XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA =A0 =A0A M I =A01072009 MSF=
T =A0 =A0 =A0 97)<br>
&gt; (XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl =A0 =A0 1000 INTL =
20091112)<br>
&gt; (XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT =A0 1072009 MSFT =
=A0 =A0 =A0 97)<br>
&gt; (XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA =A0 =A0A M I =A01072009 AMI=
. =A0 =A0 =A0 =A05)<br>
&gt; (XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl =A0 =A0 1000 INTL =
20091112)<br>
&gt; (XEN) ACPI: SSDT BE08ED88, 09AA (r1 =A0PmRef =A0Cpu0Ist =A0 =A0 3000 I=
NTL 20051117)<br>
&gt; (XEN) ACPI: SSDT BE08F738, 0A92 (r1 =A0PmRef =A0 =A0CpuPm =A0 =A0 3000=
 INTL 20051117)<br>
&gt; (XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL =A0 =A0 =A0SNB =A0 =A0 =A0 =
=A0 1 INTL =A0 =A0 =A0 =A01)<br>
&gt; (XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) System RAM: 16086MB (16473004kB)<br>
&gt; (XEN) No NUMA configuration found<br>
&gt; (XEN) Faking a node at 0000000000000000-000000042f600000<br>
&gt; (XEN) Domain heap initialised<br>
&gt; (XEN) found SMP MP-table at 000fceb0<br>
&gt; (XEN) DMI 2.7 present.<br>
&gt; (XEN) Using APIC driver default<br>
&gt; (XEN) ACPI: PM-Timer IO Port: 0x408<br>
&gt; (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]<br>
&gt; (XEN) ACPI: 32/64X FACS address mismatch in FADT -<br>
&gt; be09df80/0000000000000000, using 32<br>
&gt; (XEN) ACPI: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wakeup_vec[be09df8c], v=
ec_size[20]<br>
&gt; (XEN) ACPI: Local APIC address 0xfee00000<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)<br>
&gt; (XEN) Processor #0 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)<br>
&gt; (XEN) Processor #2 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)<br>
&gt; (XEN) Processor #4 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)<br>
&gt; (XEN) Processor #6 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])<br>
&gt; (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])<br>
&gt; (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23<b=
r>
&gt; (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)<br>
&gt; (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)<br>
&gt; (XEN) ACPI: IRQ0 used by override.<br>
&gt; (XEN) ACPI: IRQ2 used by override.<br>
&gt; (XEN) ACPI: IRQ9 used by override.<br>
&gt; (XEN) Enabling APIC mode: =A0Flat. =A0Using 1 I/O APICs<br>
&gt; (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000<br>
&gt; (XEN) Table is not found!<br>
&gt; (XEN) Using ACPI (MADT) for SMP configuration information<br>
&gt; (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)<br>
&gt; (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X<br>
&gt; (XEN) Switched to APIC driver x2apic_cluster.<br>
&gt; (XEN) Using scheduler: SMP Credit Scheduler (credit)<br>
&gt; (XEN) Detected 3300.138 MHz processor.<br>
&gt; (XEN) Initing memory sharing.<br>
&gt; (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7<br>
&gt; (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank=
<br>
&gt; 0 extended MCE MSR 0<br>
&gt; (XEN) Intel machine check reporting enabled<br>
&gt; (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 -=
 3f<br>
&gt; (XEN) PCI: MCFG area at f8000000 reserved in E820<br>
&gt; (XEN) PCI: Using MCFG for segment 0000 bus 00-3f<br>
&gt; (XEN) Intel VT-d Snoop Control not enabled.<br>
&gt; (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.<br>
&gt; (XEN) Intel VT-d Queued Invalidation enabled.<br>
&gt; (XEN) Intel VT-d Interrupt Remapping enabled.<br>
&gt; (XEN) Intel VT-d Shared EPT tables not enabled.<br>
&gt; (XEN) I/O virtualisation enabled<br>
&gt; (XEN) =A0- Dom0 mode: Relaxed<br>
&gt; (XEN) Enabled directed EOI with ioapic_ack_old on!<br>
&gt; (XEN) ENABLING IO-APIC IRQs<br>
&gt; (XEN) =A0-&gt; Using old ACK method<br>
&gt; (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1<b=
r>
&gt; (XEN) TSC deadline timer enabled<br>
&gt; (XEN) [2012-06-17 00:22:20] Platform timer is 14.318MHz HPET<br>
&gt; (XEN) [2012-06-17 00:22:20] Allocated console ring of 32 KiB.<br>
&gt; (XEN) [2012-06-17 00:22:20] VMX: Supported advanced features:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- APIC MMIO access virtualisation<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- APIC TPR shadow<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Extended Page Tables (EPT)<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Virtual-Processor Identifiers (VPID)<=
br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Virtual NMI<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- MSR direct-access bitmap<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Unrestricted Guest<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: ASIDs enabled.<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: VMX enabled<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: Hardware Assisted Paging (HAP) detect=
ed<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: HAP page sizes: 4kB, 2MB<br>
&gt; (XEN) [2012-06-17 00:22:20] Brought up 4 CPUs<br>
&gt; (XEN) [2012-06-17 00:22:20] ACPI sleep modes: S3<br>
&gt; (XEN) [2012-06-17 00:22:20] mcheck_poll: Machine check polling timer s=
tarted.<br>
&gt; (XEN) [2012-06-17 00:22:20] *** LOADING DOMAIN 0 ***<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1000000<=
br>
&gt; memsz=3D0xad5000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1c00000<=
br>
&gt; memsz=3D0xe50e0<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1ce6000<=
br>
&gt; memsz=3D0x14480<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1cfb000<=
br>
&gt; memsz=3D0x364000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: memory: 0x1000000 -&gt; =
0x205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_OS =3D &quot;lin=
ux&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_VERSION =3D &quo=
t;2.6&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: XEN_VERSION =3D &quot;=
xen-3.0&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: VIRT_BASE =3D 0xffffff=
ff80000000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: ENTRY =3D 0xffffffff81=
cfb200<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HYPERCALL_PAGE =3D<br>
&gt; 0xffffffff81001000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: FEATURES =3D<br>
&gt; &quot;!writable_page_tables|pae_pgdir_above_4gb&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PAE_MODE =3D &quot;yes=
&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: LOADER =3D &quot;gener=
ic&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: unknown xen elf note (=
0xd)<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1=
<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HV_START_LOW =3D<br>
&gt; 0xffff800000000000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PADDR_OFFSET =3D 0x0<b=
r>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_addr_calc_check: addresses:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_base =A0 =A0 =A0 =A0=3D 0xfff=
fffff80000000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 elf_paddr_offset =3D 0x0<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_offset =A0 =A0 =A0=3D 0xfffff=
fff80000000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_kstart =A0 =A0 =A0=3D 0xfffff=
fff81000000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_kend =A0 =A0 =A0 =A0=3D 0xfff=
fffff8205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_entry =A0 =A0 =A0 =3D 0xfffff=
fff81cfb200<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 p2m_base =A0 =A0 =A0 =A0 =3D 0xfff=
fffffffffffff<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Xen =A0kernel: 64-bit, lsb, compat32<br=
>
&gt; (XEN) [2012-06-17 00:22:20] =A0Dom0 kernel: 64-bit, PAE, lsb, paddr<br=
>
&gt; 0x1000000 -&gt; 0x205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] PHYSICAL MEMORY ARRANGEMENT:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Dom0 alloc.:<br>
&gt; 0000000418000000-&gt;0000000420000000 (3987995 pages to be allocated)<=
br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Init. ramdisk: 000000042d02f000-&gt;000=
000042f5ff400<br>
&gt; (XEN) [2012-06-17 00:22:20] VIRTUAL MEMORY ARRANGEMENT:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Loaded kernel: ffffffff81000000-&gt;fff=
fffff8205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Init. ramdisk: ffffffff8205f000-&gt;fff=
fffff8462f400<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Phys-Mach map: ffffffff84630000-&gt;fff=
fffff864eff60<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Start info: =A0 =A0ffffffff864f0000-&gt=
;ffffffff864f04b4<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Page tables: =A0 ffffffff864f1000-&gt;f=
fffffff86528000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Boot stack: =A0 =A0ffffffff86528000-&gt=
;ffffffff86529000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000=
-&gt;ffffffff86800000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0ENTRY ADDRESS: ffffffff81cfb200<br>
&gt; (XEN) [2012-06-17 00:22:20] Dom0 has maximum 4 VCPUs<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 0 at<br>
&gt; 0xffffffff81000000 -&gt; 0xffffffff81ad5000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 1 at<br>
&gt; 0xffffffff81c00000 -&gt; 0xffffffff81ce50e0<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 2 at<br>
&gt; 0xffffffff81ce6000 -&gt; 0xffffffff81cfa480<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 3 at<br>
&gt; 0xffffffff81cfb000 -&gt; 0xffffffff81dd3000<br>
&gt; (XEN) [2012-06-17 00:22:22] Scrubbing Free RAM: .done.<br>
&gt; (XEN) [2012-06-17 00:22:22] Initial low memory virq threshold set at<b=
r>
&gt; 0x4000 pages.<br>
&gt; (XEN) [2012-06-17 00:22:22] Std. Loglevel: All<br>
&gt; (XEN) [2012-06-17 00:22:22] Guest Loglevel: All<br>
&gt; (XEN) [2012-06-17 00:22:22] Xen is relinquishing VGA console.<br>
&gt; (XEN) [2012-06-17 00:22:22] *** Serial input -&gt; DOM0 (type &#39;CTR=
L-a&#39;<br>
&gt; three times to switch input to Xen)<br>
&gt; (XEN) [2012-06-17 00:22:22] Freed 244kB init memory.<br>
&gt; mapping kernel into physical memory<br>
&gt; Xen: setup ISA identity maps<br>
&gt; about to get started...<br>
&gt; [ =A0 =A00.000000] Initializing cgroup subsys cpuset<br>
&gt; [ =A0 =A00.000000] Initializing cgroup subsys cpu<br>
&gt; [ =A0 =A00.000000] Linux version 3.2.0-25-generic (buildd@crested) (gc=
c<br>
&gt; version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #40-Ubuntu SMP We)<br>
&gt; [ =A0 =A00.000000] Command line: placeholder<br>
&gt; root=3DUUID=3D74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=3Dhvc0<b=
r>
&gt; earlyprintk=3Dxen<br>
&gt; [ =A0 =A00.000000] KERNEL supported cpus:<br>
&gt; [ =A0 =A00.000000] =A0 Intel GenuineIntel<br>
&gt; [ =A0 =A00.000000] =A0 AMD AuthenticAMD<br>
&gt; [ =A0 =A00.000000] =A0 Centaur CentaurHauls<br>
&gt; [ =A0 =A00.000000] Freeing =A09d-100 pfn range: 99 pages freed<br>
&gt; [ =A0 =A00.000000] Freeing =A020000-20200 pfn range: 512 pages freed<b=
r>
&gt; [ =A0 =A00.000000] Freeing =A040004-40005 pfn range: 1 pages freed<br>
&gt; [ =A0 =A00.000000] Freeing =A0bd8a7-be0e7 pfn range: 2112 pages freed<=
br>
&gt; [ =A0 =A00.000000] Freeing =A0beb81-beff2 pfn range: 1137 pages freed<=
br>
&gt; [ =A0 =A00.000000] Freeing =A0bf000-100000 pfn range: 266240 pages fre=
ed<br>
&gt; [ =A0 =A00.000000] Released 270101 pages of unused memory<br>
&gt; [ =A0 =A00.000000] Set 270101 page(s) to 1-1 mapping<br>
&gt; [ =A0 =A00.000000] BIOS-provided physical RAM map:<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000000000000 - 000000000009d000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 000000000009d800 - 0000000000100000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000000100000 - 0000000020000000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000020000000 - 0000000020200000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000020200000 - 0000000040004000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000040004000 - 0000000040005000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000040005000 - 00000000bd8a7000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000bd8a7000 - 00000000bde1f000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000bde1f000 - 00000000be09f000 (ACPI N=
VS)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000be09f000 - 00000000be0a4000 (ACPI d=
ata)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000be0a4000 - 00000000be0e7000 (ACPI N=
VS)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000be0e7000 - 00000000beb81000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000beb81000 - 00000000beff2000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000beff2000 - 00000000bf000000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000bf800000 - 00000000cfa00000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000f8000000 - 00000000fc000000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fec00000 - 00000000fec01000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fed00000 - 00000000fed04000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fed1c000 - 00000000fed20000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fee00000 - 00000000fee01000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000ff000000 - 0000000100000000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000100000000 - 000000042f600000 (usable=
)<br>
&gt; [ =A0 =A00.000000] bootconsole [xenboot0] enabled<br>
&gt; [ =A0 =A00.000000] NX (Execute Disable) protection: active<br>
&gt; [ =A0 =A00.000000] DMI 2.7 present.<br>
&gt; [ =A0 =A00.000000] No AGP bridge found<br>
&gt; [ =A0 =A00.000000] last_pfn =3D 0x42f600 max_arch_pfn =3D 0x400000000<=
br>
&gt; [ =A0 =A00.000000] x2apic enabled by BIOS, switching to x2apic ops<br>
&gt; [ =A0 =A00.000000] last_pfn =3D 0xbf000 max_arch_pfn =3D 0x400000000<b=
r>
&gt; [ =A0 =A00.000000] found SMP MP-table at [ffff8800000fceb0] fceb0<br>
&gt; [ =A0 =A00.000000] init_memory_mapping: 0000000000000000-00000000bf000=
000<br>
&gt; [ =A0 =A00.000000] init_memory_mapping: 0000000100000000-000000042f600=
000<br>
&gt; [ =A0 =A00.000000] RAMDISK: 0205f000 - 04630000<br>
&gt; [ =A0 =A00.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)<br>
&gt; [ =A0 =A00.000000] ACPI: XSDT 00000000be084080 00084 (v01 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] ACPI: FACP 00000000be08e218 000F4 (v04 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] ACPI: DSDT 00000000be0841a0 0A077 (v02 ALASKA =A0 =
=A0A M I<br>
&gt; 00000014 INTL 20051117)<br>
&gt; [ =A0 =A00.000000] ACPI: FACS 00000000be09df80 00040<br>
&gt; [ =A0 =A00.000000] ACPI: APIC 00000000be08e310 00072 (v03 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] ACPI: ASF! 00000000be08e388 000A5 (v32 INTEL =A0 =
=A0 =A0 HCG<br>
&gt; 00000001 TFSM 000F4240)<br>
&gt; [ =A0 =A00.000000] ACPI: MCFG 00000000be08e430 0003C (v01 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 MSFT 00000097)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08e470 004A6 (v01 Intel_ AoacT=
abl<br>
&gt; 00001000 INTL 20091112)<br>
&gt; [ =A0 =A00.000000] ACPI: AAFT 00000000be08e918 000C2 (v01 ALASKA OEMAA=
FT<br>
&gt; 01072009 MSFT 00000097)<br>
&gt; [ =A0 =A00.000000] ACPI: HPET 00000000be08e9e0 00038 (v01 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI. 00000005)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08ea18 0036D (v01 SataRe SataT=
abl<br>
&gt; 00001000 INTL 20091112)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08ed88 009AA (v01 =A0PmRef =A0=
Cpu0Ist<br>
&gt; 00003000 INTL 20051117)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08f738 00A92 (v01 =A0PmRef =A0=
 =A0CpuPm<br>
&gt; 00003000 INTL 20051117)<br>
&gt; [ =A0 =A00.000000] ACPI: XMAR 00000000be0901d0 000B8 (v01 INTEL =A0 =
=A0 =A0SNB<br>
&gt; 00000001 INTL 00000001)<br>
&gt; [ =A0 =A00.000000] ACPI: BGRT 00000000be090288 0003C (v00 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] Setting APIC routing to cluster x2apic.<br>
&gt; [ =A0 =A00.000000] No NUMA configuration found<br>
&gt; [ =A0 =A00.000000] Faking a node at 0000000000000000-000000042f600000<=
br>
&gt; [ =A0 =A00.000000] Initmem setup node 0 0000000000000000-000000042f600=
000<br>
&gt; [ =A0 =A00.000000] =A0 NODE_DATA [00000003d7fe7000 - 00000003d7febfff]=
<br>
&gt; [ =A0 =A00.000000] Zone PFN ranges:<br>
&gt; [ =A0 =A00.000000] =A0 DMA =A0 =A0 =A00x00000010 -&gt; 0x00001000<br>
&gt; [ =A0 =A00.000000] =A0 DMA32 =A0 =A00x00001000 -&gt; 0x00100000<br>
&gt; [ =A0 =A00.000000] =A0 Normal =A0 0x00100000 -&gt; 0x0042f600<br>
&gt; [ =A0 =A00.000000] Movable zone start PFN for each node<br>
&gt; [ =A0 =A00.000000] early_node_map[7] active PFN ranges<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00000010 -&gt; 0x0000009d<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00000100 -&gt; 0x00020000<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00020200 -&gt; 0x00040004<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00040005 -&gt; 0x000bd8a7<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x000be0e7 -&gt; 0x000beb81<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x000beff2 -&gt; 0x000bf000<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00100000 -&gt; 0x0042f600<br>
&gt; [ =A0 =A00.000000] ACPI: PM-Timer IO Port: 0x408<br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])=
<br>
&gt; [ =A0 =A00.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base=
[0])<br>
&gt; [ =A0 =A00.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec000=
00, GSI 0-255<br>
&gt; [ =A0 =A00.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl=
 dfl)<br>
&gt; [ =A0 =A00.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 hig=
h level)<br>
&gt; [ =A0 =A00.000000] Using ACPI (MADT) for SMP configuration information=
<br>
&gt; [ =A0 =A00.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000<br>
&gt; [ =A0 =A00.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 000000000009d000 - 00=
0000000009e000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 000000000009e000 - 00=
00000000100000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 0000000020000000 - 00=
00000020200000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 0000000040004000 - 00=
00000040005000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bd8a7000 - 00=
000000bde1f000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bde1f000 - 00=
000000be09f000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000be09f000 - 00=
000000be0a4000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000be0a4000 - 00=
000000be0e7000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000beb81000 - 00=
000000beff2000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bf000000 - 00=
000000bf800000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bf800000 - 00=
000000cfa00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000cfa00000 - 00=
000000f8000000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000f8000000 - 00=
000000fc000000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fc000000 - 00=
000000fec00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fec00000 - 00=
000000fec01000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fec01000 - 00=
000000fed00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed00000 - 00=
000000fed04000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed04000 - 00=
000000fed1c000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed1c000 - 00=
000000fed20000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed20000 - 00=
000000fee00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fee00000 - 00=
000000fee01000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fee01000 - 00=
000000ff000000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000ff000000 - 00=
00000100000000<br>
&gt; [ =A0 =A00.000000] Allocating PCI resources starting at cfa00000 (gap:=
<br>
&gt; cfa00000:28600000)<br>
&gt; [ =A0 =A00.000000] Booting paravirtualized kernel on Xen<br>
&gt; [ =A0 =A00.000000] Xen version: 4.2-unstable (preserve-AD)<br>
&gt; [ =A0 =A00.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256<br>
&gt; nr_cpu_ids:4 nr_node_ids:1<br>
&gt; [ =A0 =A00.000000] PERCPU: Embedded 28 pages/cpu @ffff8803d7c00000 s83=
072<br>
&gt; r8192 d23424 u524288<br>
&gt; [ =A0 =A03.860481] Built 1 zonelists in Zone order, mobility grouping =
on.<br>
&gt; Total pages: 4048188<br>
&gt; [ =A0 =A03.860484] Policy zone: Normal<br>
&gt; [ =A0 =A03.860487] Kernel command line: placeholder<br>
&gt; root=3DUUID=3D74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=3Dhvc0<b=
r>
&gt; earlyprintk=3Dxen<br>
&gt; [ =A0 =A03.860828] PID hash table entries: 4096 (order: 3, 32768 bytes=
)<br>
&gt; [ =A0 =A03.861070] invalid opcode: 0000 [#1] SMP<br>
&gt; [ =A0 =A03.861073] CPU 0<br>
&gt; [ =A0 =A03.861074] Modules linked in:<br>
&gt; [ =A0 =A03.861076]<br>
&gt; [ =A0 =A03.861078] Pid: 0, comm: swapper Not tainted 3.2.0-25-generic<=
br>
&gt; #40-Ubuntu To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extre6<br=
>
&gt; [ =A0 =A03.861083] RIP: e030:[&lt;ffffffff8101d82c&gt;] =A0[&lt;ffffff=
ff8101d82c&gt;]<br>
&gt; xstate_enable+0x3c/0x50<br>
&gt; [ =A0 =A03.861090] RSP: e02b:ffffffff81c01e58 =A0EFLAGS: 00010046<br>
&gt; [ =A0 =A03.861092] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX: 00=
00000000000000<br>
&gt; [ =A0 =A03.861094] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 00=
00000000002660<br>
&gt; [ =A0 =A03.861096] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09: ff=
ffffff81c01e94<br>
&gt; [ =A0 =A03.861098] R10: 00000000ffffffff R11: 00000000ffffffff R12: ff=
ffffff81c01e90<br>
&gt; [ =A0 =A03.861100] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15: ff=
ff8803d7c0c480<br>
&gt; [ =A0 =A03.861104] FS: =A00000000000000000(0000) GS:ffff8803d7c00000(0=
000)<br>
&gt; knlGS:0000000000000000<br>
&gt; [ =A0 =A03.861107] CS: =A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b=
<br>
&gt; [ =A0 =A03.861108] CR2: 0000000000000000 CR3: 0000000001c05000 CR4: 00=
00000000002660<br>
&gt; [ =A0 =A03.861111] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00=
00000000000000<br>
&gt; [ =A0 =A03.861113] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00=
00000000000400<br>
&gt; [ =A0 =A03.861115] Process swapper (pid: 0, threadinfo ffffffff81c0000=
0,<br>
&gt; task ffffffff81c0d020)<br>
&gt; [ =A0 =A03.861117] Stack:<br>
&gt; [ =A0 =A03.861119] =A0ffffffff81c01ec8 ffffffff81d04795 ffff8803d7c0b1=
50<br>
&gt; ffff8803d7c0b950<br>
&gt; [ =A0 =A03.861123] =A0ffff8803d7c0b150 ffff8803d7c0b950 00000240000000=
07<br>
&gt; 0000000000000340<br>
&gt; [ =A0 =A03.861127] =A00000000000000004 0000000000000008 00000000000000=
04<br>
&gt; 0000000000000000<br>
&gt; [ =A0 =A03.861131] Call Trace:<br>
&gt; [ =A0 =A03.861136] =A0[&lt;ffffffff81d04795&gt;] xstate_enable_boot_cp=
u+0xa9/0x174<br>
&gt; [ =A0 =A03.861141] =A0[&lt;ffffffff8163660b&gt;] xsave_init+0x26/0x28<=
br>
&gt; [ =A0 =A03.861143] =A0[&lt;ffffffff816388d1&gt;] cpu_init+0x2bb/0x2d8<=
br>
&gt; [ =A0 =A03.861146] =A0[&lt;ffffffff81d00f92&gt;] trap_init+0x169/0x171=
<br>
&gt; [ =A0 =A03.861149] =A0[&lt;ffffffff81cfba28&gt;] start_kernel+0x1d5/0x=
3c7<br>
&gt; [ =A0 =A03.861153] =A0[&lt;ffffffff81cfb388&gt;] x86_64_start_reservat=
ions+0x132/0x136<br>
&gt; [ =A0 =A03.861156] =A0[&lt;ffffffff81cfef27&gt;] xen_start_kernel+0x5d=
9/0x5e0<br>
&gt; [ =A0 =A03.861157] Code: 00 04 00 ff 14 25 90 76 c1 81 48 89 c7 48 81 =
cf<br>
&gt; 00 00 04 00 ff 14 25 98 76 c1 81 48 8b 05 cd 0d dc 00 31 c9 48<br>
&gt; [ =A0 =A03.861191] RIP =A0[&lt;ffffffff8101d82c&gt;] xstate_enable+0x3=
c/0x50<br>
&gt; [ =A0 =A03.861194] =A0RSP &lt;ffffffff81c01e58<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">http://lists.xen.org/xen-de=
vel</a><br>
</p>

--20cf302d4e32a0a05c04c2a24e7d--


--===============0413737885644258119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0413737885644258119==--


From xen-devel-bounces@lists.xen.org Sun Jun 17 03:05:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 03:05: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 1Sg5mz-0005dS-QB; Sun, 17 Jun 2012 03:04:33 +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 1Sg5mx-0005dN-Rq
	for xen-devel@lists.xen.org; Sun, 17 Jun 2012 03:04:32 +0000
Received: from [85.158.143.35:23117] by server-1.bemta-4.messagelabs.com id
	98/80-24392-F394DDF4; Sun, 17 Jun 2012 03:04:31 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339902267!13463814!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10082 invoked from network); 17 Jun 2012 03:04:28 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 03:04:28 -0000
Received: by qadb33 with SMTP id b33so575226qad.16
	for <xen-devel@lists.xen.org>; Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZB/pZsEFqISJS7paxrd7XLg1vkfvh6qFBCfup8jxDTY=;
	b=E/1DnWGrPbNZN7bWLmigMblJvqoz7j1JlC5SO/ygDl1QeKZC+GFJsPBxy4KyYx/FBt
	QrQpr+Nh5acpGqOYph3887Nh6+def3yPioJLU7M4veP66q2u+0Nfw5FSC5LSxYwq5oY3
	R8C3qh8w0KDKaRqxO9KjgFCP+DZX2wPww6yr2LXmbqluVIvHe7i7RYzUu7pPP9YhyJz4
	dvIW4RTlVgI47uHP2KONInARv2H7qK2xjJX8t40aUKTF38nOllvKo2zMj5GXpYIEzf8Z
	Yhr6vn1/zIPf7fmBSnUqBgNtSF0f5JzKarJkY0itU4N13KIMs8kNKiEE2KgjZStFj0XB
	wqaA==
MIME-Version: 1.0
Received: by 10.224.176.148 with SMTP id be20mr19919326qab.64.1339902266482;
	Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Sat, 16 Jun 2012 20:04:26 -0700 (PDT)
In-Reply-To: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
References: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
Date: Sat, 16 Jun 2012 20:04:26 -0700
Message-ID: <CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Rolu <rolu@roce.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0413737885644258119=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0413737885644258119==
Content-Type: multipart/alternative; boundary=20cf302d4e32a0a05c04c2a24e7d

--20cf302d4e32a0a05c04c2a24e7d
Content-Type: text/plain; charset=ISO-8859-1

On Jun 16, 2012 5:56 PM, "Rolu" <rolu@roce.org> wrote:
>
> When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
> crashes. I've included a serial console log below.
>
> I've used:
> Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
> apply the AT_EMPTY_PATH patch from
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to
> get it to compile.
> Linux 3.2.0-25, which is the default kernel in Ubuntu's repository right
now.
> Ubuntu 12.04 Precise
>
> Booting with the default Xen 4.1 from the Ubuntu repositories works.
>
> Using the kernel from
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is
> a mainline Linux kernel (and also more recent) works with my compiled
> version of Xen 4.2
>
> So,
> * Is xen 4.2 not happy with the 3.2 kernel I've used?
> * Is this due to something Ubuntu modified in their default kernel?
> * Is this an issue with Xen?
> * Did I break something?

This is an issue with the Ubuntu kernel. Check this thread out:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html

Adding xsave=0 to the Xen kernel line in grub is the workaround.

> -----
>
>  __  __            _  _    ____                     _        _     _
>  \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
>  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
>  /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>
> (XEN) Xen version 4.2-unstable (root@roce.org) (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012
> (XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864f2c
> (XEN) Bootloader: GRUB 1.99-21ubuntu3.1
> (XEN) Command line: placeholder loglvl=all guest_loglvl=all
> console_timestamps=1 noreboot com1=115200,8n1,0x3f8,4 console=com1,vga
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 3 MBR signatures
> (XEN)  Found 3 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009d800 (usable)
> (XEN)  000000000009d800 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040004000 (usable)
> (XEN)  0000000040004000 - 0000000040005000 (reserved)
> (XEN)  0000000040005000 - 00000000bd8a7000 (usable)
> (XEN)  00000000bd8a7000 - 00000000bde1f000 (reserved)
> (XEN)  00000000bde1f000 - 00000000be09f000 (ACPI NVS)
> (XEN)  00000000be09f000 - 00000000be0a4000 (ACPI data)
> (XEN)  00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
> (XEN)  00000000be0e7000 - 00000000beb81000 (usable)
> (XEN)  00000000beb81000 - 00000000beff2000 (reserved)
> (XEN)  00000000beff2000 - 00000000bf000000 (usable)
> (XEN)  00000000bf800000 - 00000000cfa00000 (reserved)
> (XEN)  00000000f8000000 - 00000000fc000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec01000 (reserved)
> (XEN)  00000000fed00000 - 00000000fed04000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ff000000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 000000042f600000 (usable)
> (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
> (XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA    A M I  1072009 AMI
10013)
> (XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA    A M I  1072009 AMI
10013)
> (XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA    A M I       14 INTL
20051117)
> (XEN) ACPI: FACS BE09DF80, 0040
> (XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA    A M I  1072009 AMI
10013)
> (XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL       HCG        1 TFSM
 F4240)
> (XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA    A M I  1072009 MSFT
97)
> (XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl     1000 INTL
20091112)
> (XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT   1072009 MSFT
97)
> (XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA    A M I  1072009 AMI.
 5)
> (XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl     1000 INTL
20091112)
> (XEN) ACPI: SSDT BE08ED88, 09AA (r1  PmRef  Cpu0Ist     3000 INTL
20051117)
> (XEN) ACPI: SSDT BE08F738, 0A92 (r1  PmRef    CpuPm     3000 INTL
20051117)
> (XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL      SNB         1 INTL
 1)
> (XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA    A M I  1072009 AMI
10013)
> (XEN) System RAM: 16086MB (16473004kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-000000042f600000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000fceb0
> (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 -
> be09df80/0000000000000000, using 32
> (XEN) ACPI:                  wakeup_vec[be09df8c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> (XEN) Processor #2 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
> (XEN) Processor #4 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
> (XEN) Processor #6 7:10 APIC version 21
> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 2, 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) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
> (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
> (XEN) Switched to APIC driver x2apic_cluster.
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 3300.138 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
> (XEN) mce_intel.c:1239: 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 f8000000 segment 0000 buses 00 - 3f
> (XEN) PCI: MCFG area at f8000000 reserved in E820
> (XEN) PCI: Using MCFG for segment 0000 bus 00-3f
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation enabled.
> (XEN) Intel VT-d Interrupt Remapping enabled.
> (XEN) Intel VT-d Shared EPT tables not enabled.
> (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) TSC deadline timer enabled
> (XEN) [2012-06-17 00:22:20] Platform timer is 14.318MHz HPET
> (XEN) [2012-06-17 00:22:20] Allocated console ring of 32 KiB.
> (XEN) [2012-06-17 00:22:20] VMX: Supported advanced features:
> (XEN) [2012-06-17 00:22:20]  - APIC MMIO access virtualisation
> (XEN) [2012-06-17 00:22:20]  - APIC TPR shadow
> (XEN) [2012-06-17 00:22:20]  - Extended Page Tables (EPT)
> (XEN) [2012-06-17 00:22:20]  - Virtual-Processor Identifiers (VPID)
> (XEN) [2012-06-17 00:22:20]  - Virtual NMI
> (XEN) [2012-06-17 00:22:20]  - MSR direct-access bitmap
> (XEN) [2012-06-17 00:22:20]  - Unrestricted Guest
> (XEN) [2012-06-17 00:22:20] HVM: ASIDs enabled.
> (XEN) [2012-06-17 00:22:20] HVM: VMX enabled
> (XEN) [2012-06-17 00:22:20] HVM: Hardware Assisted Paging (HAP) detected
> (XEN) [2012-06-17 00:22:20] HVM: HAP page sizes: 4kB, 2MB
> (XEN) [2012-06-17 00:22:20] Brought up 4 CPUs
> (XEN) [2012-06-17 00:22:20] ACPI sleep modes: S3
> (XEN) [2012-06-17 00:22:20] mcheck_poll: Machine check polling timer
started.
> (XEN) [2012-06-17 00:22:20] *** LOADING DOMAIN 0 ***
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1000000
> memsz=0xad5000
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1c00000
> memsz=0xe50e0
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1ce6000
> memsz=0x14480
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=0x1cfb000
> memsz=0x364000
> (XEN) [2012-06-17 00:22:20] elf_parse_binary: memory: 0x1000000 ->
0x205f000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_OS = "linux"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_VERSION = "2.6"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: XEN_VERSION = "xen-3.0"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: VIRT_BASE =
0xffffffff80000000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: ENTRY = 0xffffffff81cfb200
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HYPERCALL_PAGE =
> 0xffffffff81001000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: FEATURES =
> "!writable_page_tables|pae_pgdir_above_4gb"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PAE_MODE = "yes"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: LOADER = "generic"
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: unknown xen elf note (0xd)
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: SUSPEND_CANCEL = 0x1
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HV_START_LOW =
> 0xffff800000000000
> (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PADDR_OFFSET = 0x0
> (XEN) [2012-06-17 00:22:20] elf_xen_addr_calc_check: addresses:
> (XEN) [2012-06-17 00:22:20]     virt_base        = 0xffffffff80000000
> (XEN) [2012-06-17 00:22:20]     elf_paddr_offset = 0x0
> (XEN) [2012-06-17 00:22:20]     virt_offset      = 0xffffffff80000000
> (XEN) [2012-06-17 00:22:20]     virt_kstart      = 0xffffffff81000000
> (XEN) [2012-06-17 00:22:20]     virt_kend        = 0xffffffff8205f000
> (XEN) [2012-06-17 00:22:20]     virt_entry       = 0xffffffff81cfb200
> (XEN) [2012-06-17 00:22:20]     p2m_base         = 0xffffffffffffffff
> (XEN) [2012-06-17 00:22:20]  Xen  kernel: 64-bit, lsb, compat32
> (XEN) [2012-06-17 00:22:20]  Dom0 kernel: 64-bit, PAE, lsb, paddr
> 0x1000000 -> 0x205f000
> (XEN) [2012-06-17 00:22:20] PHYSICAL MEMORY ARRANGEMENT:
> (XEN) [2012-06-17 00:22:20]  Dom0 alloc.:
> 0000000418000000->0000000420000000 (3987995 pages to be allocated)
> (XEN) [2012-06-17 00:22:20]  Init. ramdisk:
000000042d02f000->000000042f5ff400
> (XEN) [2012-06-17 00:22:20] VIRTUAL MEMORY ARRANGEMENT:
> (XEN) [2012-06-17 00:22:20]  Loaded kernel:
ffffffff81000000->ffffffff8205f000
> (XEN) [2012-06-17 00:22:20]  Init. ramdisk:
ffffffff8205f000->ffffffff8462f400
> (XEN) [2012-06-17 00:22:20]  Phys-Mach map:
ffffffff84630000->ffffffff864eff60
> (XEN) [2012-06-17 00:22:20]  Start info:
 ffffffff864f0000->ffffffff864f04b4
> (XEN) [2012-06-17 00:22:20]  Page tables:
ffffffff864f1000->ffffffff86528000
> (XEN) [2012-06-17 00:22:20]  Boot stack:
 ffffffff86528000->ffffffff86529000
> (XEN) [2012-06-17 00:22:20]  TOTAL:
ffffffff80000000->ffffffff86800000
> (XEN) [2012-06-17 00:22:20]  ENTRY ADDRESS: ffffffff81cfb200
> (XEN) [2012-06-17 00:22:20] Dom0 has maximum 4 VCPUs
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 0 at
> 0xffffffff81000000 -> 0xffffffff81ad5000
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 1 at
> 0xffffffff81c00000 -> 0xffffffff81ce50e0
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 2 at
> 0xffffffff81ce6000 -> 0xffffffff81cfa480
> (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 3 at
> 0xffffffff81cfb000 -> 0xffffffff81dd3000
> (XEN) [2012-06-17 00:22:22] Scrubbing Free RAM: .done.
> (XEN) [2012-06-17 00:22:22] Initial low memory virq threshold set at
> 0x4000 pages.
> (XEN) [2012-06-17 00:22:22] Std. Loglevel: All
> (XEN) [2012-06-17 00:22:22] Guest Loglevel: All
> (XEN) [2012-06-17 00:22:22] Xen is relinquishing VGA console.
> (XEN) [2012-06-17 00:22:22] *** Serial input -> DOM0 (type 'CTRL-a'
> three times to switch input to Xen)
> (XEN) [2012-06-17 00:22:22] Freed 244kB init memory.
> mapping kernel into physical memory
> Xen: setup ISA identity maps
> about to get started...
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.0-25-generic (buildd@crested) (gcc
> version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #40-Ubuntu SMP We)
> [    0.000000] Command line: placeholder
> root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
> earlyprintk=xen
> [    0.000000] KERNEL supported cpus:
> [    0.000000]   Intel GenuineIntel
> [    0.000000]   AMD AuthenticAMD
> [    0.000000]   Centaur CentaurHauls
> [    0.000000] Freeing  9d-100 pfn range: 99 pages freed
> [    0.000000] Freeing  20000-20200 pfn range: 512 pages freed
> [    0.000000] Freeing  40004-40005 pfn range: 1 pages freed
> [    0.000000] Freeing  bd8a7-be0e7 pfn range: 2112 pages freed
> [    0.000000] Freeing  beb81-beff2 pfn range: 1137 pages freed
> [    0.000000] Freeing  bf000-100000 pfn range: 266240 pages freed
> [    0.000000] Released 270101 pages of unused memory
> [    0.000000] Set 270101 page(s) to 1-1 mapping
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  Xen: 0000000000000000 - 000000000009d000 (usable)
> [    0.000000]  Xen: 000000000009d800 - 0000000000100000 (reserved)
> [    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
> [    0.000000]  Xen: 0000000020000000 - 0000000020200000 (reserved)
> [    0.000000]  Xen: 0000000020200000 - 0000000040004000 (usable)
> [    0.000000]  Xen: 0000000040004000 - 0000000040005000 (reserved)
> [    0.000000]  Xen: 0000000040005000 - 00000000bd8a7000 (usable)
> [    0.000000]  Xen: 00000000bd8a7000 - 00000000bde1f000 (reserved)
> [    0.000000]  Xen: 00000000bde1f000 - 00000000be09f000 (ACPI NVS)
> [    0.000000]  Xen: 00000000be09f000 - 00000000be0a4000 (ACPI data)
> [    0.000000]  Xen: 00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
> [    0.000000]  Xen: 00000000be0e7000 - 00000000beb81000 (usable)
> [    0.000000]  Xen: 00000000beb81000 - 00000000beff2000 (reserved)
> [    0.000000]  Xen: 00000000beff2000 - 00000000bf000000 (usable)
> [    0.000000]  Xen: 00000000bf800000 - 00000000cfa00000 (reserved)
> [    0.000000]  Xen: 00000000f8000000 - 00000000fc000000 (reserved)
> [    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
> [    0.000000]  Xen: 00000000fed00000 - 00000000fed04000 (reserved)
> [    0.000000]  Xen: 00000000fed1c000 - 00000000fed20000 (reserved)
> [    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  Xen: 00000000ff000000 - 0000000100000000 (reserved)
> [    0.000000]  Xen: 0000000100000000 - 000000042f600000 (usable)
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] DMI 2.7 present.
> [    0.000000] No AGP bridge found
> [    0.000000] last_pfn = 0x42f600 max_arch_pfn = 0x400000000
> [    0.000000] x2apic enabled by BIOS, switching to x2apic ops
> [    0.000000] last_pfn = 0xbf000 max_arch_pfn = 0x400000000
> [    0.000000] found SMP MP-table at [ffff8800000fceb0] fceb0
> [    0.000000] init_memory_mapping: 0000000000000000-00000000bf000000
> [    0.000000] init_memory_mapping: 0000000100000000-000000042f600000
> [    0.000000] RAMDISK: 0205f000 - 04630000
> [    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
> [    0.000000] ACPI: XSDT 00000000be084080 00084 (v01 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] ACPI: FACP 00000000be08e218 000F4 (v04 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] ACPI: DSDT 00000000be0841a0 0A077 (v02 ALASKA    A M I
> 00000014 INTL 20051117)
> [    0.000000] ACPI: FACS 00000000be09df80 00040
> [    0.000000] ACPI: APIC 00000000be08e310 00072 (v03 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] ACPI: ASF! 00000000be08e388 000A5 (v32 INTEL       HCG
> 00000001 TFSM 000F4240)
> [    0.000000] ACPI: MCFG 00000000be08e430 0003C (v01 ALASKA    A M I
> 01072009 MSFT 00000097)
> [    0.000000] ACPI: SSDT 00000000be08e470 004A6 (v01 Intel_ AoacTabl
> 00001000 INTL 20091112)
> [    0.000000] ACPI: AAFT 00000000be08e918 000C2 (v01 ALASKA OEMAAFT
> 01072009 MSFT 00000097)
> [    0.000000] ACPI: HPET 00000000be08e9e0 00038 (v01 ALASKA    A M I
> 01072009 AMI. 00000005)
> [    0.000000] ACPI: SSDT 00000000be08ea18 0036D (v01 SataRe SataTabl
> 00001000 INTL 20091112)
> [    0.000000] ACPI: SSDT 00000000be08ed88 009AA (v01  PmRef  Cpu0Ist
> 00003000 INTL 20051117)
> [    0.000000] ACPI: SSDT 00000000be08f738 00A92 (v01  PmRef    CpuPm
> 00003000 INTL 20051117)
> [    0.000000] ACPI: XMAR 00000000be0901d0 000B8 (v01 INTEL      SNB
> 00000001 INTL 00000001)
> [    0.000000] ACPI: BGRT 00000000be090288 0003C (v00 ALASKA    A M I
> 01072009 AMI  00010013)
> [    0.000000] Setting APIC routing to cluster x2apic.
> [    0.000000] No NUMA configuration found
> [    0.000000] Faking a node at 0000000000000000-000000042f600000
> [    0.000000] Initmem setup node 0 0000000000000000-000000042f600000
> [    0.000000]   NODE_DATA [00000003d7fe7000 - 00000003d7febfff]
> [    0.000000] Zone PFN ranges:
> [    0.000000]   DMA      0x00000010 -> 0x00001000
> [    0.000000]   DMA32    0x00001000 -> 0x00100000
> [    0.000000]   Normal   0x00100000 -> 0x0042f600
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] early_node_map[7] active PFN ranges
> [    0.000000]     0: 0x00000010 -> 0x0000009d
> [    0.000000]     0: 0x00000100 -> 0x00020000
> [    0.000000]     0: 0x00020200 -> 0x00040004
> [    0.000000]     0: 0x00040005 -> 0x000bd8a7
> [    0.000000]     0: 0x000be0e7 -> 0x000beb81
> [    0.000000]     0: 0x000beff2 -> 0x000bf000
> [    0.000000]     0: 0x00100000 -> 0x0042f600
> [    0.000000] ACPI: PM-Timer IO Port: 0x408
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
> [    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> [    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI
0-255
> [    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] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> [    0.000000] PM: Registered nosave memory: 000000000009d000 -
000000000009e000
> [    0.000000] PM: Registered nosave memory: 000000000009e000 -
0000000000100000
> [    0.000000] PM: Registered nosave memory: 0000000020000000 -
0000000020200000
> [    0.000000] PM: Registered nosave memory: 0000000040004000 -
0000000040005000
> [    0.000000] PM: Registered nosave memory: 00000000bd8a7000 -
00000000bde1f000
> [    0.000000] PM: Registered nosave memory: 00000000bde1f000 -
00000000be09f000
> [    0.000000] PM: Registered nosave memory: 00000000be09f000 -
00000000be0a4000
> [    0.000000] PM: Registered nosave memory: 00000000be0a4000 -
00000000be0e7000
> [    0.000000] PM: Registered nosave memory: 00000000beb81000 -
00000000beff2000
> [    0.000000] PM: Registered nosave memory: 00000000bf000000 -
00000000bf800000
> [    0.000000] PM: Registered nosave memory: 00000000bf800000 -
00000000cfa00000
> [    0.000000] PM: Registered nosave memory: 00000000cfa00000 -
00000000f8000000
> [    0.000000] PM: Registered nosave memory: 00000000f8000000 -
00000000fc000000
> [    0.000000] PM: Registered nosave memory: 00000000fc000000 -
00000000fec00000
> [    0.000000] PM: Registered nosave memory: 00000000fec00000 -
00000000fec01000
> [    0.000000] PM: Registered nosave memory: 00000000fec01000 -
00000000fed00000
> [    0.000000] PM: Registered nosave memory: 00000000fed00000 -
00000000fed04000
> [    0.000000] PM: Registered nosave memory: 00000000fed04000 -
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 -
00000000ff000000
> [    0.000000] PM: Registered nosave memory: 00000000ff000000 -
0000000100000000
> [    0.000000] Allocating PCI resources starting at cfa00000 (gap:
> cfa00000:28600000)
> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 4.2-unstable (preserve-AD)
> [    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256
> nr_cpu_ids:4 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8803d7c00000 s83072
> r8192 d23424 u524288
> [    3.860481] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 4048188
> [    3.860484] Policy zone: Normal
> [    3.860487] Kernel command line: placeholder
> root=UUID=74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=hvc0
> earlyprintk=xen
> [    3.860828] PID hash table entries: 4096 (order: 3, 32768 bytes)
> [    3.861070] invalid opcode: 0000 [#1] SMP
> [    3.861073] CPU 0
> [    3.861074] Modules linked in:
> [    3.861076]
> [    3.861078] Pid: 0, comm: swapper Not tainted 3.2.0-25-generic
> #40-Ubuntu To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extre6
> [    3.861083] RIP: e030:[<ffffffff8101d82c>]  [<ffffffff8101d82c>]
> xstate_enable+0x3c/0x50
> [    3.861090] RSP: e02b:ffffffff81c01e58  EFLAGS: 00010046
> [    3.861092] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX:
0000000000000000
> [    3.861094] RDX: 0000000000000000 RSI: 0000000000000007 RDI:
0000000000002660
> [    3.861096] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09:
ffffffff81c01e94
> [    3.861098] R10: 00000000ffffffff R11: 00000000ffffffff R12:
ffffffff81c01e90
> [    3.861100] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15:
ffff8803d7c0c480
> [    3.861104] FS:  0000000000000000(0000) GS:ffff8803d7c00000(0000)
> knlGS:0000000000000000
> [    3.861107] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    3.861108] CR2: 0000000000000000 CR3: 0000000001c05000 CR4:
0000000000002660
> [    3.861111] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
> [    3.861113] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
> [    3.861115] Process swapper (pid: 0, threadinfo ffffffff81c00000,
> task ffffffff81c0d020)
> [    3.861117] Stack:
> [    3.861119]  ffffffff81c01ec8 ffffffff81d04795 ffff8803d7c0b150
> ffff8803d7c0b950
> [    3.861123]  ffff8803d7c0b150 ffff8803d7c0b950 0000024000000007
> 0000000000000340
> [    3.861127]  0000000000000004 0000000000000008 0000000000000004
> 0000000000000000
> [    3.861131] Call Trace:
> [    3.861136]  [<ffffffff81d04795>] xstate_enable_boot_cpu+0xa9/0x174
> [    3.861141]  [<ffffffff8163660b>] xsave_init+0x26/0x28
> [    3.861143]  [<ffffffff816388d1>] cpu_init+0x2bb/0x2d8
> [    3.861146]  [<ffffffff81d00f92>] trap_init+0x169/0x171
> [    3.861149]  [<ffffffff81cfba28>] start_kernel+0x1d5/0x3c7
> [    3.861153]  [<ffffffff81cfb388>] x86_64_start_reservations+0x132/0x136
> [    3.861156]  [<ffffffff81cfef27>] xen_start_kernel+0x5d9/0x5e0
> [    3.861157] Code: 00 04 00 ff 14 25 90 76 c1 81 48 89 c7 48 81 cf
> 00 00 04 00 ff 14 25 98 76 c1 81 48 8b 05 cd 0d dc 00 31 c9 48
> [    3.861191] RIP  [<ffffffff8101d82c>] xstate_enable+0x3c/0x50
> [    3.861194]  RSP <ffffffff81c01e58
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--20cf302d4e32a0a05c04c2a24e7d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Jun 16, 2012 5:56 PM, &quot;Rolu&quot; &lt;<a href=3D"mailto:rolu@roce.o=
rg">rolu@roce.org</a>&gt; wrote:<br>
&gt;<br>
&gt; When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0<br>
&gt; crashes. I&#39;ve included a serial console log below.<br>
&gt;<br>
&gt; I&#39;ve used:<br>
&gt; Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to<br=
>
&gt; apply the AT_EMPTY_PATH patch from<br>
&gt; <a href=3D"http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg034=
60.html">http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html=
</a> to<br>
&gt; get it to compile.<br>
&gt; Linux 3.2.0-25, which is the default kernel in Ubuntu&#39;s repository=
 right now.<br>
&gt; Ubuntu 12.04 Precise<br>
&gt;<br>
&gt; Booting with the default Xen 4.1 from the Ubuntu repositories works.<b=
r>
&gt;<br>
&gt; Using the kernel from<br>
&gt; <a href=3D"http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/=
">http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/</a>, which is=
<br>
&gt; a mainline Linux kernel (and also more recent) works with my compiled<=
br>
&gt; version of Xen 4.2<br>
&gt;<br>
&gt; So,<br>
&gt; * Is xen 4.2 not happy with the 3.2 kernel I&#39;ve used?<br>
&gt; * Is this due to something Ubuntu modified in their default kernel?<br=
>
&gt; * Is this an issue with Xen?<br>
&gt; * Did I break something?</p>
<p>This is an issue with the Ubuntu kernel. Check this thread out:<br>
 <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.h=
tml">http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html</a>=
</p>
<p>Adding xsave=3D0 to the Xen kernel line in grub is the workaround.</p>
<p>&gt; -----<br>
&gt;<br>
&gt; =A0__ =A0__ =A0 =A0 =A0 =A0 =A0 =A0_ =A0_ =A0 =A0____ =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 _ =A0 =A0 =A0 =A0_ =A0 =A0 _<br>
&gt; =A0\ \/ /___ _ __ =A0 | || | =A0|___ \ =A0 =A0_ =A0 _ _ __ =A0___| |_ =
__ _| |__ | | ___<br>
&gt; =A0\ =A0// _ \ &#39;_ \ =A0| || |_ =A0 __) |__| | | | &#39;_ \/ __| __=
/ _` | &#39;_ \| |/ _ \<br>
&gt; =A0/ =A0\ =A0__/ | | | |__ =A0 _| / __/|__| |_| | | | \__ \ || (_| | |=
_) | | =A0__/<br>
&gt; =A0/_/\_\___|_| |_| =A0 =A0|_|(_)_____| =A0 \__,_|_| |_|___/\__\__,_|_=
.__/|_|\___|<br>
&gt;<br>
&gt; (XEN) Xen version 4.2-unstable (<a href=3D"mailto:root@roce.org">root@=
roce.org</a>) (gcc version 4.6.3<br>
&gt; (Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012<br>
&gt; (XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864=
f2c<br>
&gt; (XEN) Bootloader: GRUB 1.99-21ubuntu3.1<br>
&gt; (XEN) Command line: placeholder loglvl=3Dall guest_loglvl=3Dall<br>
&gt; console_timestamps=3D1 noreboot com1=3D115200,8n1,0x3f8,4 console=3Dco=
m1,vga<br>
&gt; (XEN) Video information:<br>
&gt; (XEN) =A0VGA is text mode 80x25, font 8x16<br>
&gt; (XEN) =A0VBE/DDC methods: V2; EDID transfer time: 1 seconds<br>
&gt; (XEN) Disc information:<br>
&gt; (XEN) =A0Found 3 MBR signatures<br>
&gt; (XEN) =A0Found 3 EDD information structures<br>
&gt; (XEN) Xen-e820 RAM map:<br>
&gt; (XEN) =A00000000000000000 - 000000000009d800 (usable)<br>
&gt; (XEN) =A0000000000009d800 - 00000000000a0000 (reserved)<br>
&gt; (XEN) =A000000000000e0000 - 0000000000100000 (reserved)<br>
&gt; (XEN) =A00000000000100000 - 0000000020000000 (usable)<br>
&gt; (XEN) =A00000000020000000 - 0000000020200000 (reserved)<br>
&gt; (XEN) =A00000000020200000 - 0000000040004000 (usable)<br>
&gt; (XEN) =A00000000040004000 - 0000000040005000 (reserved)<br>
&gt; (XEN) =A00000000040005000 - 00000000bd8a7000 (usable)<br>
&gt; (XEN) =A000000000bd8a7000 - 00000000bde1f000 (reserved)<br>
&gt; (XEN) =A000000000bde1f000 - 00000000be09f000 (ACPI NVS)<br>
&gt; (XEN) =A000000000be09f000 - 00000000be0a4000 (ACPI data)<br>
&gt; (XEN) =A000000000be0a4000 - 00000000be0e7000 (ACPI NVS)<br>
&gt; (XEN) =A000000000be0e7000 - 00000000beb81000 (usable)<br>
&gt; (XEN) =A000000000beb81000 - 00000000beff2000 (reserved)<br>
&gt; (XEN) =A000000000beff2000 - 00000000bf000000 (usable)<br>
&gt; (XEN) =A000000000bf800000 - 00000000cfa00000 (reserved)<br>
&gt; (XEN) =A000000000f8000000 - 00000000fc000000 (reserved)<br>
&gt; (XEN) =A000000000fec00000 - 00000000fec01000 (reserved)<br>
&gt; (XEN) =A000000000fed00000 - 00000000fed04000 (reserved)<br>
&gt; (XEN) =A000000000fed1c000 - 00000000fed20000 (reserved)<br>
&gt; (XEN) =A000000000fee00000 - 00000000fee01000 (reserved)<br>
&gt; (XEN) =A000000000ff000000 - 0000000100000000 (reserved)<br>
&gt; (XEN) =A00000000100000000 - 000000042f600000 (usable)<br>
&gt; (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)<br>
&gt; (XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA =A0 =A0A M I =A0 =A0 =A0 14=
 INTL 20051117)<br>
&gt; (XEN) ACPI: FACS BE09DF80, 0040<br>
&gt; (XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL =A0 =A0 =A0 HCG =A0 =A0 =A0=
 =A01 TFSM =A0 =A0F4240)<br>
&gt; (XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA =A0 =A0A M I =A01072009 MSF=
T =A0 =A0 =A0 97)<br>
&gt; (XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl =A0 =A0 1000 INTL =
20091112)<br>
&gt; (XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT =A0 1072009 MSFT =
=A0 =A0 =A0 97)<br>
&gt; (XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA =A0 =A0A M I =A01072009 AMI=
. =A0 =A0 =A0 =A05)<br>
&gt; (XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl =A0 =A0 1000 INTL =
20091112)<br>
&gt; (XEN) ACPI: SSDT BE08ED88, 09AA (r1 =A0PmRef =A0Cpu0Ist =A0 =A0 3000 I=
NTL 20051117)<br>
&gt; (XEN) ACPI: SSDT BE08F738, 0A92 (r1 =A0PmRef =A0 =A0CpuPm =A0 =A0 3000=
 INTL 20051117)<br>
&gt; (XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL =A0 =A0 =A0SNB =A0 =A0 =A0 =
=A0 1 INTL =A0 =A0 =A0 =A01)<br>
&gt; (XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA =A0 =A0A M I =A01072009 AMI=
 =A0 =A0 10013)<br>
&gt; (XEN) System RAM: 16086MB (16473004kB)<br>
&gt; (XEN) No NUMA configuration found<br>
&gt; (XEN) Faking a node at 0000000000000000-000000042f600000<br>
&gt; (XEN) Domain heap initialised<br>
&gt; (XEN) found SMP MP-table at 000fceb0<br>
&gt; (XEN) DMI 2.7 present.<br>
&gt; (XEN) Using APIC driver default<br>
&gt; (XEN) ACPI: PM-Timer IO Port: 0x408<br>
&gt; (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]<br>
&gt; (XEN) ACPI: 32/64X FACS address mismatch in FADT -<br>
&gt; be09df80/0000000000000000, using 32<br>
&gt; (XEN) ACPI: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wakeup_vec[be09df8c], v=
ec_size[20]<br>
&gt; (XEN) ACPI: Local APIC address 0xfee00000<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)<br>
&gt; (XEN) Processor #0 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)<br>
&gt; (XEN) Processor #2 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)<br>
&gt; (XEN) Processor #4 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)<br>
&gt; (XEN) Processor #6 7:10 APIC version 21<br>
&gt; (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])<br>
&gt; (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])<br>
&gt; (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23<b=
r>
&gt; (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)<br>
&gt; (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)<br>
&gt; (XEN) ACPI: IRQ0 used by override.<br>
&gt; (XEN) ACPI: IRQ2 used by override.<br>
&gt; (XEN) ACPI: IRQ9 used by override.<br>
&gt; (XEN) Enabling APIC mode: =A0Flat. =A0Using 1 I/O APICs<br>
&gt; (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000<br>
&gt; (XEN) Table is not found!<br>
&gt; (XEN) Using ACPI (MADT) for SMP configuration information<br>
&gt; (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)<br>
&gt; (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X<br>
&gt; (XEN) Switched to APIC driver x2apic_cluster.<br>
&gt; (XEN) Using scheduler: SMP Credit Scheduler (credit)<br>
&gt; (XEN) Detected 3300.138 MHz processor.<br>
&gt; (XEN) Initing memory sharing.<br>
&gt; (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7<br>
&gt; (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank=
<br>
&gt; 0 extended MCE MSR 0<br>
&gt; (XEN) Intel machine check reporting enabled<br>
&gt; (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 -=
 3f<br>
&gt; (XEN) PCI: MCFG area at f8000000 reserved in E820<br>
&gt; (XEN) PCI: Using MCFG for segment 0000 bus 00-3f<br>
&gt; (XEN) Intel VT-d Snoop Control not enabled.<br>
&gt; (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.<br>
&gt; (XEN) Intel VT-d Queued Invalidation enabled.<br>
&gt; (XEN) Intel VT-d Interrupt Remapping enabled.<br>
&gt; (XEN) Intel VT-d Shared EPT tables not enabled.<br>
&gt; (XEN) I/O virtualisation enabled<br>
&gt; (XEN) =A0- Dom0 mode: Relaxed<br>
&gt; (XEN) Enabled directed EOI with ioapic_ack_old on!<br>
&gt; (XEN) ENABLING IO-APIC IRQs<br>
&gt; (XEN) =A0-&gt; Using old ACK method<br>
&gt; (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1<b=
r>
&gt; (XEN) TSC deadline timer enabled<br>
&gt; (XEN) [2012-06-17 00:22:20] Platform timer is 14.318MHz HPET<br>
&gt; (XEN) [2012-06-17 00:22:20] Allocated console ring of 32 KiB.<br>
&gt; (XEN) [2012-06-17 00:22:20] VMX: Supported advanced features:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- APIC MMIO access virtualisation<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- APIC TPR shadow<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Extended Page Tables (EPT)<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Virtual-Processor Identifiers (VPID)<=
br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Virtual NMI<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- MSR direct-access bitmap<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0- Unrestricted Guest<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: ASIDs enabled.<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: VMX enabled<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: Hardware Assisted Paging (HAP) detect=
ed<br>
&gt; (XEN) [2012-06-17 00:22:20] HVM: HAP page sizes: 4kB, 2MB<br>
&gt; (XEN) [2012-06-17 00:22:20] Brought up 4 CPUs<br>
&gt; (XEN) [2012-06-17 00:22:20] ACPI sleep modes: S3<br>
&gt; (XEN) [2012-06-17 00:22:20] mcheck_poll: Machine check polling timer s=
tarted.<br>
&gt; (XEN) [2012-06-17 00:22:20] *** LOADING DOMAIN 0 ***<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1000000<=
br>
&gt; memsz=3D0xad5000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1c00000<=
br>
&gt; memsz=3D0xe50e0<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1ce6000<=
br>
&gt; memsz=3D0x14480<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: phdr: paddr=3D0x1cfb000<=
br>
&gt; memsz=3D0x364000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_parse_binary: memory: 0x1000000 -&gt; =
0x205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_OS =3D &quot;lin=
ux&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: GUEST_VERSION =3D &quo=
t;2.6&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: XEN_VERSION =3D &quot;=
xen-3.0&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: VIRT_BASE =3D 0xffffff=
ff80000000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: ENTRY =3D 0xffffffff81=
cfb200<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HYPERCALL_PAGE =3D<br>
&gt; 0xffffffff81001000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: FEATURES =3D<br>
&gt; &quot;!writable_page_tables|pae_pgdir_above_4gb&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PAE_MODE =3D &quot;yes=
&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: LOADER =3D &quot;gener=
ic&quot;<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: unknown xen elf note (=
0xd)<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1=
<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: HV_START_LOW =3D<br>
&gt; 0xffff800000000000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_parse_note: PADDR_OFFSET =3D 0x0<b=
r>
&gt; (XEN) [2012-06-17 00:22:20] elf_xen_addr_calc_check: addresses:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_base =A0 =A0 =A0 =A0=3D 0xfff=
fffff80000000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 elf_paddr_offset =3D 0x0<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_offset =A0 =A0 =A0=3D 0xfffff=
fff80000000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_kstart =A0 =A0 =A0=3D 0xfffff=
fff81000000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_kend =A0 =A0 =A0 =A0=3D 0xfff=
fffff8205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 virt_entry =A0 =A0 =A0 =3D 0xfffff=
fff81cfb200<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0 =A0 p2m_base =A0 =A0 =A0 =A0 =3D 0xfff=
fffffffffffff<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Xen =A0kernel: 64-bit, lsb, compat32<br=
>
&gt; (XEN) [2012-06-17 00:22:20] =A0Dom0 kernel: 64-bit, PAE, lsb, paddr<br=
>
&gt; 0x1000000 -&gt; 0x205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] PHYSICAL MEMORY ARRANGEMENT:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Dom0 alloc.:<br>
&gt; 0000000418000000-&gt;0000000420000000 (3987995 pages to be allocated)<=
br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Init. ramdisk: 000000042d02f000-&gt;000=
000042f5ff400<br>
&gt; (XEN) [2012-06-17 00:22:20] VIRTUAL MEMORY ARRANGEMENT:<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Loaded kernel: ffffffff81000000-&gt;fff=
fffff8205f000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Init. ramdisk: ffffffff8205f000-&gt;fff=
fffff8462f400<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Phys-Mach map: ffffffff84630000-&gt;fff=
fffff864eff60<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Start info: =A0 =A0ffffffff864f0000-&gt=
;ffffffff864f04b4<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Page tables: =A0 ffffffff864f1000-&gt;f=
fffffff86528000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0Boot stack: =A0 =A0ffffffff86528000-&gt=
;ffffffff86529000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000=
-&gt;ffffffff86800000<br>
&gt; (XEN) [2012-06-17 00:22:20] =A0ENTRY ADDRESS: ffffffff81cfb200<br>
&gt; (XEN) [2012-06-17 00:22:20] Dom0 has maximum 4 VCPUs<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 0 at<br>
&gt; 0xffffffff81000000 -&gt; 0xffffffff81ad5000<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 1 at<br>
&gt; 0xffffffff81c00000 -&gt; 0xffffffff81ce50e0<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 2 at<br>
&gt; 0xffffffff81ce6000 -&gt; 0xffffffff81cfa480<br>
&gt; (XEN) [2012-06-17 00:22:20] elf_load_binary: phdr 3 at<br>
&gt; 0xffffffff81cfb000 -&gt; 0xffffffff81dd3000<br>
&gt; (XEN) [2012-06-17 00:22:22] Scrubbing Free RAM: .done.<br>
&gt; (XEN) [2012-06-17 00:22:22] Initial low memory virq threshold set at<b=
r>
&gt; 0x4000 pages.<br>
&gt; (XEN) [2012-06-17 00:22:22] Std. Loglevel: All<br>
&gt; (XEN) [2012-06-17 00:22:22] Guest Loglevel: All<br>
&gt; (XEN) [2012-06-17 00:22:22] Xen is relinquishing VGA console.<br>
&gt; (XEN) [2012-06-17 00:22:22] *** Serial input -&gt; DOM0 (type &#39;CTR=
L-a&#39;<br>
&gt; three times to switch input to Xen)<br>
&gt; (XEN) [2012-06-17 00:22:22] Freed 244kB init memory.<br>
&gt; mapping kernel into physical memory<br>
&gt; Xen: setup ISA identity maps<br>
&gt; about to get started...<br>
&gt; [ =A0 =A00.000000] Initializing cgroup subsys cpuset<br>
&gt; [ =A0 =A00.000000] Initializing cgroup subsys cpu<br>
&gt; [ =A0 =A00.000000] Linux version 3.2.0-25-generic (buildd@crested) (gc=
c<br>
&gt; version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #40-Ubuntu SMP We)<br>
&gt; [ =A0 =A00.000000] Command line: placeholder<br>
&gt; root=3DUUID=3D74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=3Dhvc0<b=
r>
&gt; earlyprintk=3Dxen<br>
&gt; [ =A0 =A00.000000] KERNEL supported cpus:<br>
&gt; [ =A0 =A00.000000] =A0 Intel GenuineIntel<br>
&gt; [ =A0 =A00.000000] =A0 AMD AuthenticAMD<br>
&gt; [ =A0 =A00.000000] =A0 Centaur CentaurHauls<br>
&gt; [ =A0 =A00.000000] Freeing =A09d-100 pfn range: 99 pages freed<br>
&gt; [ =A0 =A00.000000] Freeing =A020000-20200 pfn range: 512 pages freed<b=
r>
&gt; [ =A0 =A00.000000] Freeing =A040004-40005 pfn range: 1 pages freed<br>
&gt; [ =A0 =A00.000000] Freeing =A0bd8a7-be0e7 pfn range: 2112 pages freed<=
br>
&gt; [ =A0 =A00.000000] Freeing =A0beb81-beff2 pfn range: 1137 pages freed<=
br>
&gt; [ =A0 =A00.000000] Freeing =A0bf000-100000 pfn range: 266240 pages fre=
ed<br>
&gt; [ =A0 =A00.000000] Released 270101 pages of unused memory<br>
&gt; [ =A0 =A00.000000] Set 270101 page(s) to 1-1 mapping<br>
&gt; [ =A0 =A00.000000] BIOS-provided physical RAM map:<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000000000000 - 000000000009d000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 000000000009d800 - 0000000000100000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000000100000 - 0000000020000000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000020000000 - 0000000020200000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000020200000 - 0000000040004000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000040004000 - 0000000040005000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000040005000 - 00000000bd8a7000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000bd8a7000 - 00000000bde1f000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000bde1f000 - 00000000be09f000 (ACPI N=
VS)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000be09f000 - 00000000be0a4000 (ACPI d=
ata)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000be0a4000 - 00000000be0e7000 (ACPI N=
VS)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000be0e7000 - 00000000beb81000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000beb81000 - 00000000beff2000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000beff2000 - 00000000bf000000 (usable=
)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000bf800000 - 00000000cfa00000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000f8000000 - 00000000fc000000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fec00000 - 00000000fec01000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fed00000 - 00000000fed04000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fed1c000 - 00000000fed20000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000fee00000 - 00000000fee01000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 00000000ff000000 - 0000000100000000 (reserv=
ed)<br>
&gt; [ =A0 =A00.000000] =A0Xen: 0000000100000000 - 000000042f600000 (usable=
)<br>
&gt; [ =A0 =A00.000000] bootconsole [xenboot0] enabled<br>
&gt; [ =A0 =A00.000000] NX (Execute Disable) protection: active<br>
&gt; [ =A0 =A00.000000] DMI 2.7 present.<br>
&gt; [ =A0 =A00.000000] No AGP bridge found<br>
&gt; [ =A0 =A00.000000] last_pfn =3D 0x42f600 max_arch_pfn =3D 0x400000000<=
br>
&gt; [ =A0 =A00.000000] x2apic enabled by BIOS, switching to x2apic ops<br>
&gt; [ =A0 =A00.000000] last_pfn =3D 0xbf000 max_arch_pfn =3D 0x400000000<b=
r>
&gt; [ =A0 =A00.000000] found SMP MP-table at [ffff8800000fceb0] fceb0<br>
&gt; [ =A0 =A00.000000] init_memory_mapping: 0000000000000000-00000000bf000=
000<br>
&gt; [ =A0 =A00.000000] init_memory_mapping: 0000000100000000-000000042f600=
000<br>
&gt; [ =A0 =A00.000000] RAMDISK: 0205f000 - 04630000<br>
&gt; [ =A0 =A00.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)<br>
&gt; [ =A0 =A00.000000] ACPI: XSDT 00000000be084080 00084 (v01 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] ACPI: FACP 00000000be08e218 000F4 (v04 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] ACPI: DSDT 00000000be0841a0 0A077 (v02 ALASKA =A0 =
=A0A M I<br>
&gt; 00000014 INTL 20051117)<br>
&gt; [ =A0 =A00.000000] ACPI: FACS 00000000be09df80 00040<br>
&gt; [ =A0 =A00.000000] ACPI: APIC 00000000be08e310 00072 (v03 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] ACPI: ASF! 00000000be08e388 000A5 (v32 INTEL =A0 =
=A0 =A0 HCG<br>
&gt; 00000001 TFSM 000F4240)<br>
&gt; [ =A0 =A00.000000] ACPI: MCFG 00000000be08e430 0003C (v01 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 MSFT 00000097)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08e470 004A6 (v01 Intel_ AoacT=
abl<br>
&gt; 00001000 INTL 20091112)<br>
&gt; [ =A0 =A00.000000] ACPI: AAFT 00000000be08e918 000C2 (v01 ALASKA OEMAA=
FT<br>
&gt; 01072009 MSFT 00000097)<br>
&gt; [ =A0 =A00.000000] ACPI: HPET 00000000be08e9e0 00038 (v01 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI. 00000005)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08ea18 0036D (v01 SataRe SataT=
abl<br>
&gt; 00001000 INTL 20091112)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08ed88 009AA (v01 =A0PmRef =A0=
Cpu0Ist<br>
&gt; 00003000 INTL 20051117)<br>
&gt; [ =A0 =A00.000000] ACPI: SSDT 00000000be08f738 00A92 (v01 =A0PmRef =A0=
 =A0CpuPm<br>
&gt; 00003000 INTL 20051117)<br>
&gt; [ =A0 =A00.000000] ACPI: XMAR 00000000be0901d0 000B8 (v01 INTEL =A0 =
=A0 =A0SNB<br>
&gt; 00000001 INTL 00000001)<br>
&gt; [ =A0 =A00.000000] ACPI: BGRT 00000000be090288 0003C (v00 ALASKA =A0 =
=A0A M I<br>
&gt; 01072009 AMI =A000010013)<br>
&gt; [ =A0 =A00.000000] Setting APIC routing to cluster x2apic.<br>
&gt; [ =A0 =A00.000000] No NUMA configuration found<br>
&gt; [ =A0 =A00.000000] Faking a node at 0000000000000000-000000042f600000<=
br>
&gt; [ =A0 =A00.000000] Initmem setup node 0 0000000000000000-000000042f600=
000<br>
&gt; [ =A0 =A00.000000] =A0 NODE_DATA [00000003d7fe7000 - 00000003d7febfff]=
<br>
&gt; [ =A0 =A00.000000] Zone PFN ranges:<br>
&gt; [ =A0 =A00.000000] =A0 DMA =A0 =A0 =A00x00000010 -&gt; 0x00001000<br>
&gt; [ =A0 =A00.000000] =A0 DMA32 =A0 =A00x00001000 -&gt; 0x00100000<br>
&gt; [ =A0 =A00.000000] =A0 Normal =A0 0x00100000 -&gt; 0x0042f600<br>
&gt; [ =A0 =A00.000000] Movable zone start PFN for each node<br>
&gt; [ =A0 =A00.000000] early_node_map[7] active PFN ranges<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00000010 -&gt; 0x0000009d<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00000100 -&gt; 0x00020000<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00020200 -&gt; 0x00040004<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00040005 -&gt; 0x000bd8a7<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x000be0e7 -&gt; 0x000beb81<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x000beff2 -&gt; 0x000bf000<br>
&gt; [ =A0 =A00.000000] =A0 =A0 0: 0x00100000 -&gt; 0x0042f600<br>
&gt; [ =A0 =A00.000000] ACPI: PM-Timer IO Port: 0x408<br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)<=
br>
&gt; [ =A0 =A00.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])=
<br>
&gt; [ =A0 =A00.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base=
[0])<br>
&gt; [ =A0 =A00.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec000=
00, GSI 0-255<br>
&gt; [ =A0 =A00.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl=
 dfl)<br>
&gt; [ =A0 =A00.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 hig=
h level)<br>
&gt; [ =A0 =A00.000000] Using ACPI (MADT) for SMP configuration information=
<br>
&gt; [ =A0 =A00.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000<br>
&gt; [ =A0 =A00.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 000000000009d000 - 00=
0000000009e000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 000000000009e000 - 00=
00000000100000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 0000000020000000 - 00=
00000020200000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 0000000040004000 - 00=
00000040005000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bd8a7000 - 00=
000000bde1f000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bde1f000 - 00=
000000be09f000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000be09f000 - 00=
000000be0a4000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000be0a4000 - 00=
000000be0e7000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000beb81000 - 00=
000000beff2000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bf000000 - 00=
000000bf800000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000bf800000 - 00=
000000cfa00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000cfa00000 - 00=
000000f8000000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000f8000000 - 00=
000000fc000000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fc000000 - 00=
000000fec00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fec00000 - 00=
000000fec01000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fec01000 - 00=
000000fed00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed00000 - 00=
000000fed04000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed04000 - 00=
000000fed1c000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed1c000 - 00=
000000fed20000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed20000 - 00=
000000fee00000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fee00000 - 00=
000000fee01000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000fee01000 - 00=
000000ff000000<br>
&gt; [ =A0 =A00.000000] PM: Registered nosave memory: 00000000ff000000 - 00=
00000100000000<br>
&gt; [ =A0 =A00.000000] Allocating PCI resources starting at cfa00000 (gap:=
<br>
&gt; cfa00000:28600000)<br>
&gt; [ =A0 =A00.000000] Booting paravirtualized kernel on Xen<br>
&gt; [ =A0 =A00.000000] Xen version: 4.2-unstable (preserve-AD)<br>
&gt; [ =A0 =A00.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256<br>
&gt; nr_cpu_ids:4 nr_node_ids:1<br>
&gt; [ =A0 =A00.000000] PERCPU: Embedded 28 pages/cpu @ffff8803d7c00000 s83=
072<br>
&gt; r8192 d23424 u524288<br>
&gt; [ =A0 =A03.860481] Built 1 zonelists in Zone order, mobility grouping =
on.<br>
&gt; Total pages: 4048188<br>
&gt; [ =A0 =A03.860484] Policy zone: Normal<br>
&gt; [ =A0 =A03.860487] Kernel command line: placeholder<br>
&gt; root=3DUUID=3D74eca254-73dc-478d-9c20-8e0c1fa8bebe ro console=3Dhvc0<b=
r>
&gt; earlyprintk=3Dxen<br>
&gt; [ =A0 =A03.860828] PID hash table entries: 4096 (order: 3, 32768 bytes=
)<br>
&gt; [ =A0 =A03.861070] invalid opcode: 0000 [#1] SMP<br>
&gt; [ =A0 =A03.861073] CPU 0<br>
&gt; [ =A0 =A03.861074] Modules linked in:<br>
&gt; [ =A0 =A03.861076]<br>
&gt; [ =A0 =A03.861078] Pid: 0, comm: swapper Not tainted 3.2.0-25-generic<=
br>
&gt; #40-Ubuntu To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extre6<br=
>
&gt; [ =A0 =A03.861083] RIP: e030:[&lt;ffffffff8101d82c&gt;] =A0[&lt;ffffff=
ff8101d82c&gt;]<br>
&gt; xstate_enable+0x3c/0x50<br>
&gt; [ =A0 =A03.861090] RSP: e02b:ffffffff81c01e58 =A0EFLAGS: 00010046<br>
&gt; [ =A0 =A03.861092] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX: 00=
00000000000000<br>
&gt; [ =A0 =A03.861094] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 00=
00000000002660<br>
&gt; [ =A0 =A03.861096] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09: ff=
ffffff81c01e94<br>
&gt; [ =A0 =A03.861098] R10: 00000000ffffffff R11: 00000000ffffffff R12: ff=
ffffff81c01e90<br>
&gt; [ =A0 =A03.861100] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15: ff=
ff8803d7c0c480<br>
&gt; [ =A0 =A03.861104] FS: =A00000000000000000(0000) GS:ffff8803d7c00000(0=
000)<br>
&gt; knlGS:0000000000000000<br>
&gt; [ =A0 =A03.861107] CS: =A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b=
<br>
&gt; [ =A0 =A03.861108] CR2: 0000000000000000 CR3: 0000000001c05000 CR4: 00=
00000000002660<br>
&gt; [ =A0 =A03.861111] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00=
00000000000000<br>
&gt; [ =A0 =A03.861113] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00=
00000000000400<br>
&gt; [ =A0 =A03.861115] Process swapper (pid: 0, threadinfo ffffffff81c0000=
0,<br>
&gt; task ffffffff81c0d020)<br>
&gt; [ =A0 =A03.861117] Stack:<br>
&gt; [ =A0 =A03.861119] =A0ffffffff81c01ec8 ffffffff81d04795 ffff8803d7c0b1=
50<br>
&gt; ffff8803d7c0b950<br>
&gt; [ =A0 =A03.861123] =A0ffff8803d7c0b150 ffff8803d7c0b950 00000240000000=
07<br>
&gt; 0000000000000340<br>
&gt; [ =A0 =A03.861127] =A00000000000000004 0000000000000008 00000000000000=
04<br>
&gt; 0000000000000000<br>
&gt; [ =A0 =A03.861131] Call Trace:<br>
&gt; [ =A0 =A03.861136] =A0[&lt;ffffffff81d04795&gt;] xstate_enable_boot_cp=
u+0xa9/0x174<br>
&gt; [ =A0 =A03.861141] =A0[&lt;ffffffff8163660b&gt;] xsave_init+0x26/0x28<=
br>
&gt; [ =A0 =A03.861143] =A0[&lt;ffffffff816388d1&gt;] cpu_init+0x2bb/0x2d8<=
br>
&gt; [ =A0 =A03.861146] =A0[&lt;ffffffff81d00f92&gt;] trap_init+0x169/0x171=
<br>
&gt; [ =A0 =A03.861149] =A0[&lt;ffffffff81cfba28&gt;] start_kernel+0x1d5/0x=
3c7<br>
&gt; [ =A0 =A03.861153] =A0[&lt;ffffffff81cfb388&gt;] x86_64_start_reservat=
ions+0x132/0x136<br>
&gt; [ =A0 =A03.861156] =A0[&lt;ffffffff81cfef27&gt;] xen_start_kernel+0x5d=
9/0x5e0<br>
&gt; [ =A0 =A03.861157] Code: 00 04 00 ff 14 25 90 76 c1 81 48 89 c7 48 81 =
cf<br>
&gt; 00 00 04 00 ff 14 25 98 76 c1 81 48 8b 05 cd 0d dc 00 31 c9 48<br>
&gt; [ =A0 =A03.861191] RIP =A0[&lt;ffffffff8101d82c&gt;] xstate_enable+0x3=
c/0x50<br>
&gt; [ =A0 =A03.861194] =A0RSP &lt;ffffffff81c01e58<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">http://lists.xen.org/xen-de=
vel</a><br>
</p>

--20cf302d4e32a0a05c04c2a24e7d--


--===============0413737885644258119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0413737885644258119==--


From xen-devel-bounces@lists.xen.org Sun Jun 17 03:24:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 03: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 1Sg65K-0005xl-Ms; Sun, 17 Jun 2012 03:23:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sg65K-0005xg-55
	for xen-devel@lists.xen.org; Sun, 17 Jun 2012 03:23:30 +0000
Received: from [85.158.138.51:28429] by server-9.bemta-3.messagelabs.com id
	56/5C-10419-0BD4DDF4; Sun, 17 Jun 2012 03:23:28 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339903406!23988146!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7810 invoked from network); 17 Jun 2012 03:23:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 03:23:28 -0000
Received: by obbwd20 with SMTP id wd20so8441813obb.32
	for <xen-devel@lists.xen.org>; Sat, 16 Jun 2012 20:23:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=AkVJtqPz+8f4bGo4IJvPYUtrhocfPli7yR7XvPkikEA=;
	b=T1CaO/U8Y/rm2DdEOoC24tr8AdcaeojLYdzRajo9zSlHO9VEhwEN40rx1tZ7Qmkv5o
	ahsew7hZgTo5gkRktNxD9JN2xAnTEa0Pg8FjYg7O3z+CIU7fX6eEPXyaJhuG573jZkxP
	zxFZrdpQEy/V+Y6G9SwBobeSXvQegq5cxpUbZxhNOveRpFZlEpHHl/wbuYhTiUtRQyTR
	igleBtF14oFmkki/+QMe1G2I8mCXfcQvWAwIyBWZAV02rYXvdeIZ9tm4K4TY3MT03YOP
	wpbwmNBiQfczLGDhOwpGnZxhAEAFj9MObOEOzDHDhuM1+oDBSIRJ8ItW43UjCjGZD2H6
	n5gg==
Received: by 10.50.181.137 with SMTP id dw9mr5541648igc.45.1339903406291; Sat,
	16 Jun 2012 20:23:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.66.14 with HTTP; Sat, 16 Jun 2012 20:23:06 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
References: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
	<CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Sun, 17 Jun 2012 05:23:06 +0200
Message-ID: <CABs9EjkQS4VbUjPE6mt_P2zCi3JxAT0LaiztiRTEb-SntUnGXQ@mail.gmail.com>
To: AP <apxeng@gmail.com>
X-Gm-Message-State: ALoCoQn15CZNhUBglqPKQjGJ6KThA7tEP0PtuxZROZGVHlOY+k8bJAbhHyOK7/aDTjDRU+RJKiMD
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jun 17, 2012 at 5:04 AM, AP <apxeng@gmail.com> wrote:
>
> On Jun 16, 2012 5:56 PM, "Rolu" <rolu@roce.org> wrote:
>>
>> When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
>> crashes. I've included a serial console log below.
>>
>> I've used:
>> Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
>> apply the AT_EMPTY_PATH patch from
>> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to
>> get it to compile.
>> Linux 3.2.0-25, which is the default kernel in Ubuntu's repository right
>> now.
>> Ubuntu 12.04 Precise
>>
>> Booting with the default Xen 4.1 from the Ubuntu repositories works.
>>
>> Using the kernel from
>> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is
>> a mainline Linux kernel (and also more recent) works with my compiled
>> version of Xen 4.2
>>
>> So,
>> * Is xen 4.2 not happy with the 3.2 kernel I've used?
>> * Is this due to something Ubuntu modified in their default kernel?
>> * Is this an issue with Xen?
>> * Did I break something?
>
> This is an issue with the Ubuntu kernel. Check this thread out:
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html
>
> Adding xsave=0 to the Xen kernel line in grub is the workaround.
>

Indeed, this worked. Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 03:24:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 03: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 1Sg65K-0005xl-Ms; Sun, 17 Jun 2012 03:23:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sg65K-0005xg-55
	for xen-devel@lists.xen.org; Sun, 17 Jun 2012 03:23:30 +0000
Received: from [85.158.138.51:28429] by server-9.bemta-3.messagelabs.com id
	56/5C-10419-0BD4DDF4; Sun, 17 Jun 2012 03:23:28 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1339903406!23988146!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7810 invoked from network); 17 Jun 2012 03:23:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 03:23:28 -0000
Received: by obbwd20 with SMTP id wd20so8441813obb.32
	for <xen-devel@lists.xen.org>; Sat, 16 Jun 2012 20:23:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=AkVJtqPz+8f4bGo4IJvPYUtrhocfPli7yR7XvPkikEA=;
	b=T1CaO/U8Y/rm2DdEOoC24tr8AdcaeojLYdzRajo9zSlHO9VEhwEN40rx1tZ7Qmkv5o
	ahsew7hZgTo5gkRktNxD9JN2xAnTEa0Pg8FjYg7O3z+CIU7fX6eEPXyaJhuG573jZkxP
	zxFZrdpQEy/V+Y6G9SwBobeSXvQegq5cxpUbZxhNOveRpFZlEpHHl/wbuYhTiUtRQyTR
	igleBtF14oFmkki/+QMe1G2I8mCXfcQvWAwIyBWZAV02rYXvdeIZ9tm4K4TY3MT03YOP
	wpbwmNBiQfczLGDhOwpGnZxhAEAFj9MObOEOzDHDhuM1+oDBSIRJ8ItW43UjCjGZD2H6
	n5gg==
Received: by 10.50.181.137 with SMTP id dw9mr5541648igc.45.1339903406291; Sat,
	16 Jun 2012 20:23:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.66.14 with HTTP; Sat, 16 Jun 2012 20:23:06 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
References: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
	<CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Sun, 17 Jun 2012 05:23:06 +0200
Message-ID: <CABs9EjkQS4VbUjPE6mt_P2zCi3JxAT0LaiztiRTEb-SntUnGXQ@mail.gmail.com>
To: AP <apxeng@gmail.com>
X-Gm-Message-State: ALoCoQn15CZNhUBglqPKQjGJ6KThA7tEP0PtuxZROZGVHlOY+k8bJAbhHyOK7/aDTjDRU+RJKiMD
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jun 17, 2012 at 5:04 AM, AP <apxeng@gmail.com> wrote:
>
> On Jun 16, 2012 5:56 PM, "Rolu" <rolu@roce.org> wrote:
>>
>> When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
>> crashes. I've included a serial console log below.
>>
>> I've used:
>> Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
>> apply the AT_EMPTY_PATH patch from
>> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to
>> get it to compile.
>> Linux 3.2.0-25, which is the default kernel in Ubuntu's repository right
>> now.
>> Ubuntu 12.04 Precise
>>
>> Booting with the default Xen 4.1 from the Ubuntu repositories works.
>>
>> Using the kernel from
>> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is
>> a mainline Linux kernel (and also more recent) works with my compiled
>> version of Xen 4.2
>>
>> So,
>> * Is xen 4.2 not happy with the 3.2 kernel I've used?
>> * Is this due to something Ubuntu modified in their default kernel?
>> * Is this an issue with Xen?
>> * Did I break something?
>
> This is an issue with the Ubuntu kernel. Check this thread out:
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html
>
> Adding xsave=0 to the Xen kernel line in grub is the workaround.
>

Indeed, this worked. Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 08:42:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 08:42: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 1SgB2w-0001Io-5Q; Sun, 17 Jun 2012 08:41: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 1SgB2u-0001Ij-GJ
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 08:41:20 +0000
Received: from [85.158.139.83:57151] by server-1.bemta-5.messagelabs.com id
	DB/6D-19721-F289DDF4; Sun, 17 Jun 2012 08:41:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339922479!28058195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15308 invoked from network); 17 Jun 2012 08:41:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 08:41:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,785,1330905600"; d="scan'208";a="13064014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 08:41:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 09:41:18 +0100
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 1SgB2r-0003aW-U1;
	Sun, 17 Jun 2012 08:41:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgB2r-0003BL-EH;
	Sun, 17 Jun 2012 09:41:17 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13069-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 09:41:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13069: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13069 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13069/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13061

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 13061 never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 08:42:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 08:42: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 1SgB2w-0001Io-5Q; Sun, 17 Jun 2012 08:41: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 1SgB2u-0001Ij-GJ
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 08:41:20 +0000
Received: from [85.158.139.83:57151] by server-1.bemta-5.messagelabs.com id
	DB/6D-19721-F289DDF4; Sun, 17 Jun 2012 08:41:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1339922479!28058195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15308 invoked from network); 17 Jun 2012 08:41:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 08:41:19 -0000
X-IronPort-AV: E=Sophos;i="4.75,785,1330905600"; d="scan'208";a="13064014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 08:41:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 09:41:18 +0100
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 1SgB2r-0003aW-U1;
	Sun, 17 Jun 2012 08:41:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgB2r-0003BL-EH;
	Sun, 17 Jun 2012 09:41:17 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13069-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 09:41:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13069: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13069 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13069/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13061

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 13061 never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 09:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 09:40: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 1SgBxL-0001or-Up; Sun, 17 Jun 2012 09:39:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SgBxL-0001om-4q
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 09:39:39 +0000
Received: from [85.158.143.35:2817] by server-3.bemta-4.messagelabs.com id
	5D/43-05808-AD5ADDF4; Sun, 17 Jun 2012 09:39:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339925977!13487639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20116 invoked from network); 17 Jun 2012 09:39:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 09:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,785,1330905600"; d="scan'208";a="13064170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 09:39:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 10:39:37 +0100
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 1SgBxJ-0003tT-4u;
	Sun, 17 Jun 2012 09:39:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgBxJ-0004NY-2x;
	Sun, 17 Jun 2012 10:39:37 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13071-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 10:39:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13071: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13071 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13071/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build        fail in 13052 REGR. vs. 12957

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 13068
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13068 pass in 13052

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2   fail like 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13068 blocked in 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13052 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 09:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 09:40: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 1SgBxL-0001or-Up; Sun, 17 Jun 2012 09:39:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SgBxL-0001om-4q
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 09:39:39 +0000
Received: from [85.158.143.35:2817] by server-3.bemta-4.messagelabs.com id
	5D/43-05808-AD5ADDF4; Sun, 17 Jun 2012 09:39:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1339925977!13487639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwOTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20116 invoked from network); 17 Jun 2012 09:39:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 09:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.75,785,1330905600"; d="scan'208";a="13064170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 09:39:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 10:39:37 +0100
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 1SgBxJ-0003tT-4u;
	Sun, 17 Jun 2012 09:39:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgBxJ-0004NY-2x;
	Sun, 17 Jun 2012 10:39:37 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13071-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 10:39:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13071: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13071 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13071/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build        fail in 13052 REGR. vs. 12957

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 13068
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13068 pass in 13052

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2   fail like 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13068 blocked in 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13052 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 22:45:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 22: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 1SgOCn-0001va-EZ; Sun, 17 Jun 2012 22:44:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SgOCl-0001vV-GQ
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 22:44:23 +0000
Received: from [85.158.143.35:53029] by server-2.bemta-4.messagelabs.com id
	B6/72-17938-6CD5EDF4; Sun, 17 Jun 2012 22:44:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339973062!12695738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3808 invoked from network); 17 Jun 2012 22:44:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 22:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,789,1330905600"; d="scan'208";a="13067349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 22:44:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 23:44:21 +0100
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 1SgOCj-00085s-1V;
	Sun, 17 Jun 2012 22:44:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgOCi-0004EW-PT;
	Sun, 17 Jun 2012 23:44:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13075-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 23:44:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13075: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13075 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13075/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13061

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 13061 never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 17 22:45:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Jun 2012 22: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 1SgOCn-0001va-EZ; Sun, 17 Jun 2012 22:44:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SgOCl-0001vV-GQ
	for xen-devel@lists.xensource.com; Sun, 17 Jun 2012 22:44:23 +0000
Received: from [85.158.143.35:53029] by server-2.bemta-4.messagelabs.com id
	B6/72-17938-6CD5EDF4; Sun, 17 Jun 2012 22:44:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1339973062!12695738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3808 invoked from network); 17 Jun 2012 22:44:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jun 2012 22:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,789,1330905600"; d="scan'208";a="13067349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jun 2012 22:44:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 17 Jun 2012 23:44:21 +0100
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 1SgOCj-00085s-1V;
	Sun, 17 Jun 2012 22:44:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgOCi-0004EW-PT;
	Sun, 17 Jun 2012 23:44:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13075-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 17 Jun 2012 23:44:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13075: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13075 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13075/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13061

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 13061 never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 01:46:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 01:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgR2P-0007wz-T9; Mon, 18 Jun 2012 01:45: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 1SgR2O-0007wq-91
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 01:45:52 +0000
Received: from [193.109.254.147:39158] by server-6.bemta-14.messagelabs.com id
	AF/1C-02426-F488EDF4; Mon, 18 Jun 2012 01:45:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339983951!10146292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2117 invoked from network); 18 Jun 2012 01:45:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 01:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,789,1330905600"; d="scan'208";a="13067844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 01:45:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 02:45:50 +0100
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 1SgR2M-0000de-9v;
	Mon, 18 Jun 2012 01:45:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgR2M-0000BF-0Q;
	Mon, 18 Jun 2012 02:45:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13076-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 02:45:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13076: 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 13076 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13076/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-qemuu-winxpsp3  3 host-install(3)    broken pass in 13071
 test-amd64-i386-xl-qemuu-win7-amd64 7 windows-install fail in 13071 pass in 13076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail blocked in 12957
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10  fail like 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13071 like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check fail in 13071 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=f7f8c33cd49885d69efc2e5f7f9a613d631762e2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable f7f8c33cd49885d69efc2e5f7f9a613d631762e2
+ branch=qemu-upstream-unstable
+ revision=f7f8c33cd49885d69efc2e5f7f9a613d631762e2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git f7f8c33cd49885d69efc2e5f7f9a613d631762e2:master
Counting objects: 1   
Counting objects: 7, done.
Compressing objects:  25% (1/4)   
Compressing objects:  50% (2/4)   
Compressing objects:  75% (3/4)   
Compressing objects: 100% (4/4)   
Compressing objects: 100% (4/4), done.
Writing objects:  25% (1/4)   
Writing objects:  50% (2/4)   
Writing objects:  75% (3/4)   
Writing objects: 100% (4/4)   
Writing objects: 100% (4/4), 896 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   6d8b472..f7f8c33  f7f8c33cd49885d69efc2e5f7f9a613d631762e2 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 01:46:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 01:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgR2P-0007wz-T9; Mon, 18 Jun 2012 01:45: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 1SgR2O-0007wq-91
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 01:45:52 +0000
Received: from [193.109.254.147:39158] by server-6.bemta-14.messagelabs.com id
	AF/1C-02426-F488EDF4; Mon, 18 Jun 2012 01:45:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1339983951!10146292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2117 invoked from network); 18 Jun 2012 01:45:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 01:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.75,789,1330905600"; d="scan'208";a="13067844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 01:45:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 02:45:50 +0100
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 1SgR2M-0000de-9v;
	Mon, 18 Jun 2012 01:45:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgR2M-0000BF-0Q;
	Mon, 18 Jun 2012 02:45:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13076-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 02:45:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13076: 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 13076 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13076/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-qemuu-winxpsp3  3 host-install(3)    broken pass in 13071
 test-amd64-i386-xl-qemuu-win7-amd64 7 windows-install fail in 13071 pass in 13076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail blocked in 12957
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10  fail like 12957
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13071 like 12957

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check fail in 13071 never pass

version targeted for testing:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2
baseline version:
 qemuu                6d8b472233779c2a028a03843603030d2b1aee86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=f7f8c33cd49885d69efc2e5f7f9a613d631762e2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable f7f8c33cd49885d69efc2e5f7f9a613d631762e2
+ branch=qemu-upstream-unstable
+ revision=f7f8c33cd49885d69efc2e5f7f9a613d631762e2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git f7f8c33cd49885d69efc2e5f7f9a613d631762e2:master
Counting objects: 1   
Counting objects: 7, done.
Compressing objects:  25% (1/4)   
Compressing objects:  50% (2/4)   
Compressing objects:  75% (3/4)   
Compressing objects: 100% (4/4)   
Compressing objects: 100% (4/4), done.
Writing objects:  25% (1/4)   
Writing objects:  50% (2/4)   
Writing objects:  75% (3/4)   
Writing objects: 100% (4/4)   
Writing objects: 100% (4/4), 896 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   6d8b472..f7f8c33  f7f8c33cd49885d69efc2e5f7f9a613d631762e2 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 07:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 07: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 1SgWRp-0003KY-5i; Mon, 18 Jun 2012 07:32: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 1SgWRm-0003KT-Ri
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 07:32:27 +0000
Received: from [85.158.139.83:41204] by server-7.bemta-5.messagelabs.com id
	87/4D-28276-989DEDF4; Mon, 18 Jun 2012 07:32:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340004730!28066589!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32509 invoked from network); 18 Jun 2012 07:32:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 07:32:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 08:32:09 +0100
Message-Id: <4FDEF595020000780008A5B7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 08:32:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FDB790F020000780008A406@nat28.tlf.novell.com>
	<CC012A16.43075%keir@xen.org>
In-Reply-To: <CC012A16.43075%keir@xen.org>
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] fpu_taskswitch adjustment 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.06.12 at 19:06, Keir Fraser <keir@xen.org> wrote:
> On 15/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> While pv-ops so far doesn't care to eliminate the two trap-and-
>> emulate CR0 accesses from the asm/xor.h save/restore
>> operations, the legacy x86-64 kernel uses conditional clts()/stts()
>> for this purpose. While looking into whether to extend this to the
>> newly added (in 3.5) AVX operations there I realized that this isn't
>> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
>> kernel_fpu_end() pair (as it will stts() at the end no matter what
>> the original state of CR0.TS was).
>> 
>> In order to not introduce completely new hypercalls to overcome
>> this (fpu_taskswitch isn't really extensible on its own), I'm
>> considering to add a new VM assist, altering the fpu_taskswitch
>> behavior so that it would return an indicator whether any change
>> to the virtual CR0.TS was done. That way, the kernel can
>> implement a true save/restore cycle here.
> 
> It should be possible for the guest kernel to track its CR0.TS setting
> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
> cleared on #NM.

Sure, but selling this to the Linux maintainers I would expect to be
harder than fitting the Xen side of things into the current save-
and-restore model the native xor code uses. It would only be strait
forward to implement on the legacy, forward ported trees.

However, with the #NM handler in pv-ops apparently not
leveraging the fact that CR0.TS is already cleared for it on entry,
maybe this could indeed be introduced together. Konrad?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 07:33:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 07: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 1SgWRp-0003KY-5i; Mon, 18 Jun 2012 07:32: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 1SgWRm-0003KT-Ri
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 07:32:27 +0000
Received: from [85.158.139.83:41204] by server-7.bemta-5.messagelabs.com id
	87/4D-28276-989DEDF4; Mon, 18 Jun 2012 07:32:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340004730!28066589!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32509 invoked from network); 18 Jun 2012 07:32:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 07:32:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 08:32:09 +0100
Message-Id: <4FDEF595020000780008A5B7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 08:32:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FDB790F020000780008A406@nat28.tlf.novell.com>
	<CC012A16.43075%keir@xen.org>
In-Reply-To: <CC012A16.43075%keir@xen.org>
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] fpu_taskswitch adjustment 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.06.12 at 19:06, Keir Fraser <keir@xen.org> wrote:
> On 15/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> While pv-ops so far doesn't care to eliminate the two trap-and-
>> emulate CR0 accesses from the asm/xor.h save/restore
>> operations, the legacy x86-64 kernel uses conditional clts()/stts()
>> for this purpose. While looking into whether to extend this to the
>> newly added (in 3.5) AVX operations there I realized that this isn't
>> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
>> kernel_fpu_end() pair (as it will stts() at the end no matter what
>> the original state of CR0.TS was).
>> 
>> In order to not introduce completely new hypercalls to overcome
>> this (fpu_taskswitch isn't really extensible on its own), I'm
>> considering to add a new VM assist, altering the fpu_taskswitch
>> behavior so that it would return an indicator whether any change
>> to the virtual CR0.TS was done. That way, the kernel can
>> implement a true save/restore cycle here.
> 
> It should be possible for the guest kernel to track its CR0.TS setting
> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
> cleared on #NM.

Sure, but selling this to the Linux maintainers I would expect to be
harder than fitting the Xen side of things into the current save-
and-restore model the native xor code uses. It would only be strait
forward to implement on the legacy, forward ported trees.

However, with the #NM handler in pv-ops apparently not
leveraging the fact that CR0.TS is already cleared for it on entry,
maybe this could indeed be introduced together. Konrad?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 08:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 08: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 1SgXSE-0004RZ-9u; Mon, 18 Jun 2012 08:36:58 +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 1SgXSC-0004RU-MC
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 08:36:57 +0000
Received: from [85.158.138.51:62133] by server-9.bemta-3.messagelabs.com id
	9A/D6-10419-7A8EEDF4; Mon, 18 Jun 2012 08:36:55 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340008614!28128095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19937 invoked from network); 18 Jun 2012 08:36:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 08:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,789,1330905600"; d="scan'208";a="13071504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 08:36:54 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 09:36:54 +0100
Message-ID: <4FDEE8A4.1080500@citrix.com>
Date: Mon, 18 Jun 2012 09:36:52 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IEEgYml0IGxhdGUgdGhpcyB3ZWVrLCBkdWUgdG8gbXkgYmVp
bmcgb24gdmFjYXRpb24uIEknbSBvbiB2YWNhdGlvbgo+IG5leHQgdHdvIE1vbmRheSBhcyB3ZWxs
IHNvIGl0IHdpbGwgYmUgbGF0ZSB0aGVuIHRvby4KPgo+IFBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6
Cj4gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9t
c2cwMDc5My5odG1sCj4KPiBUaGUgdGltZSBsaW5lIGlzIGFzIGZvbGxvd3M6Cj4KPiAxOSBNYXJj
aCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCj4gMiBBcHJpbCAgICAgICAgIC0tIEZl
YXR1cmUgRnJlZXplCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDw8ICBXRSBBUkUgSEVSRQo+IFdoZW4gSXQncyBSZWFkeSAtLSBGaXJzdCByZWxlYXNl
IGNhbmRpZGF0ZQo+IFdlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCByZWxlYXNlCj4KPiBU
aGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVyIHRoZSByZWxlYXNlIHBsYW4gYSBzdHJv
bmcgY2FzZSB3aWxsCj4gbm93IGhhdmUgdG8gYmUgbWFkZSBhcyB0byB3aHkgbmV3IGl0ZW1zIHNo
b3VsZCBiZSBhZGRlZCB0byB0aGUgbGlzdCwKPiBlc3BlY2lhbGx5IGFzIGEgYmxvY2tlciwgcmF0
aGVyIHRoYW4gZGVmZXJyZWQgdG8gNC4zLgo+Cj4gSWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgYnVn
cyB3aGljaCBtdXN0L3Nob3VsZCBiZSBmaXhlZCBmb3IgNC4yIHRoZW4KPiBwbGVhc2UgcmVwbHkg
dG8gdGhpcyB0aHJlYWQgKG90aGVyd2lzZSBJIG1heSBub3QgcmVtZW1iZXIgdG8gcGljayB0aGVt
Cj4gdXAgbmV4dCB3ZWVrKQo+Cj4gT3RoZXIgdGhhbiB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGNv
bnNpZGVyIHRoZSBmcmVlemUgdG8gYmUgaW4gZnVsbAo+IGVmZmVjdCBhbmQgdGhlIGJhciB0byBl
bnRyeSB0byA0LjIgdG8gYmUgdmVyeSBoaWdoLgo+Cj4gaHlwZXJ2aXNvciwgYmxvY2tlcnM6Cj4K
PiAgICAgICogTm9uZQo+Cj4gdG9vbHMsIGJsb2NrZXJzOgo+Cj4gICAgICAqIGxpYnhsIHN0YWJs
ZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+ICAgICAg
ICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBB
c3BlY3RzIG9mCj4gICAgICAgIHRoaXMgYXJlOgo+Cj4gICAgICAgICAgKiBMSUJYTF9OSUNfVFlQ
RSBlbnVtIG5hbWVzIGFyZSBjb25mdXNpbmcuCj4KPiAgICAgICAgICAqIEludGVyZmFjZXMgd2hp
Y2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6Cj4KPiAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5f
c3VzcGVuZC4gTW92ZSB4Y19kb21haW5fc2F2ZS9yZXN0b3JlIGludG8gYQo+ICAgICAgICAgICAg
ICAgIHNlcGFyYXRlIHByb2Nlc3MgKElhbkosIHBhdGNoZXMgcG9zdGVkKS4KPgo+ICAgICAgICAg
ICAgICAqIGxpYnhsX2RldmljZV97ZGlzayxuaWMsdmtiLGFkZCxwY2l9X2FkZCAoYW5kCj4gICAg
ICAgICAgICAgICAgcmVtb3ZlKS4gKFJvZ2VyLCBwYXRjaGVzIHBvc3RlZCBmb3IgZGlzayYgIG5p
YywgdmtiCj4gICAgICAgICAgICAgICAgdHJpdmlhbCwgbm90IGxvb2tlZCBhdCBwY2kgeWV0KQo+
Cj4gICAgICAgICAgKiB1c2UgbGlieGxfY3B1bWFwIGZvciBiX2luZm8uYXZhaWxfY3B1cyBpbnN0
ZWFkIG9mIGFuIGludCwKPiAgICAgICAgICAgIHRoaXMiYWxsb3dzIHNldHRpbmcgbW9yZSB0aGFu
IDMxIENQVVMgKFlhbmcgWiBaaGFuZywgcGF0Y2hlcwo+ICAgICAgICAgICAgcG9zdGVkKQo+Cj4g
ICAgICAgICAgKiB1c2UgYW4gZW51bSBmb3IgVkdBIGludGVyZmFjZSB0eXBlIChlLmcuIENpcnJ1
cywKPiAgICAgICAgICAgIFN0ZFZHQSkuIEFsbG93cyBmb3IgUVhMIHN1cHBvcnQgKGluIDQuMyku
IChaaG91IFBlbmcsCj4gICAgICAgICAgICBwYXRjaGVzIHBvc3RlZCkKPgo+ICAgICAgKiB4bCBj
b21wYXRpYmlsaXR5IHdpdGggeG06Cj4KPiAgICAgICAgICAqIFtCVUddIGNhbm5vdCBjcmVhdGUg
YW4gZW1wdHkgQ0QtUk9NIGRyaXZlIG9uIEhWTSBndWVzdCwKPiAgICAgICAgICAgIHJlcG9ydGVk
IGJ5IEZhYmlvIEZhbnRvbmkgaW48NEY5NjcyREQuMjA4MDkwMkB0aXNjYWxpLml0Pgo+Cj4gICAg
ICAgICAgKiBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IHRyeSB0byBzZWxlY3QgYSAoc2V0IG9mKSBu
b2RlKHMpIG9uCj4gICAgICAgICAgICB3aGljaCB0byBjcmVhdGUgYSBWTSBhbmQgcGluIGl0cyB2
Y3B1cyB0aGVyZS4gKERhcmlvCj4gICAgICAgICAgICBGYWdnaW9saSwgcGF0Y2hlcyByZXBvc3Rl
ZCwgdW5kZXIgcmV2aWV3KQo+Cj4gICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hl
bmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5IGluCj4gICAgICAgIHRyZWUuIE5lZWRzIHJlbGVh
c2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCj4gICAgICAgIHJlbWlu
ZCBwZW9wbGUgdG8gdGVzdCB4bC4KPgo+ICAgICAgKiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0cyBm
cm9tIHhsIChMaW51eCBhbmQgTmV0QlNEKSAoUm9nZXIgUGF1Cj4gICAgICAgIE1vbm7DqSwgcGF0
Y2hlcyBwb3N0ZWQpCgpBbm90aGVyIHJvdW5kIHBvc3RlZCAodjYpLCB3YWl0aW5nIGZvciByZXZp
ZXcuCgo+Cj4gICAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBo
b3RwbHVnIHNjcmlwdCAoUm9nZXIKPiAgICAgICAgUGF1IE1vbm7DqSwgImp1c3QgYmUgYSBtYXR0
ZXIgb2YgcmVtb3ZpbmcgYW4gImlmIiIpCj4KPiAgICAgICogQWRqdXN0bWVudHMgbmVlZGVkIGZv
ciBxZGlzayBiYWNrZW5kIHRvIHdvcmsgb24gbm9uLXB2b3BzIExpbnV4Lgo+ICAgICAgICAicWVt
dS94ZW5kaXNrOiBzZXQgbWF4aW11bSBudW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4g
QmV1bGljaCkKPgo+ICAgICAgKiBDb25maXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAt
PiAgNC4yIHdvcmtzLi4uCj4KPiAgICAgICogW0JVR10gQnVpbGQgZmFpbHVyZSBkdWUgdG8gZ2Nj
IC1Xc3dpdGNoIG9uIHNvbWUgZGlzdHJvcwo+ICAgICAgICB2cy4gTElCWExfRE9NQUlOX1RZUEUu
IChEYXJpbyBGYWdnaW9saSwgRE9ORSkKPgo+IGh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKPgo+
ICAgICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwLCBwYXRj
aGVzIHBvc3RlZCkKPgo+IHRvb2xzLCBuaWNlIHRvIGhhdmU6Cj4KPiAgICAgICogeGwgY29tcGF0
aWJpbGl0eSB3aXRoIHhtOgo+Cj4gICAgICAgICAgKiBBY2NlcHQgInhsIGNyIC9kZXYvbnVsbCBw
YXJhbT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29uZmlnCj4gICAgICAgICAgICBvbiB0aGUgY29t
bWFuZCBsaW5lIChXLiBNaWNoYWVsIFBldHVsbG8sIHBhdGNoIHBvc3RlZCkKPgo+ICAgICAgKiBs
aWJ4bDogQWRkIEFQSSB0byByZXRyaWV2ZSBkb21haW4gY29uc29sZSB0dHkgKEJhbXZvciBKaWFu
Cj4gICAgICAgIFpoYW5nLCBET05FKQo+Cj4gICAgICAqIGxpYnhsIHN0YWJsZSBBUEkKPgo+ICAg
ICAgICAgICogbGlieGxfd2FpdF9mb3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5
X3RhcmdldC4KPiAgICAgICAgICAgIEludGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRl
ZCB0bwo+ICAgICAgICAgICAgbG9ja2luZy9zZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0
ZS4gSWFuSiB0byBhZGQgbm90ZQo+ICAgICAgICAgICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVp
bmcgc3Vic3RhbmRhcmQgYnV0IG90aGVyd2lzZSBkZWZlcgo+ICAgICAgICAgICAgdG8gNC4zLgo+
Cj4gICAgICAgICAgKiBJbnRlcmZhY2VzIHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgo+Cj4g
ICAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQgYmUgZWFzeSBvbmNlCj4g
ICAgICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0gZG9uZS4gVGhpcyBpcyBiYXNpY2FsbHkg
YSBoZWxwZXIKPiAgICAgICAgICAgICAgICBmdW5jdGlvbiBhbmQgaXRzIGZ1bmN0aW9uYWxpdHkg
Y2FuIGJlIGltcGxlbWVudGVkIGluCj4gICAgICAgICAgICAgICAgdGVybXMgb2YgdGhlIGxpYnhs
X2Rpc2tfKiBpbnRlcmZhY2VzLiBJZiB0aGlzIGlzIG5vdAo+ICAgICAgICAgICAgICAgIGRvbmUg
aW4gdGltZSB3ZSBzaG91bGQgZG9jdW1lbnQgYXMgYSBzdWJzdGFuZGFyZAo+ICAgICAgICAgICAg
ICAgIGludGVyZmFjZSB3aGljaCBpcyBzdWJqZWN0IHRvIGNoYW5nZSBwb3N0IDQuMi4KPgo+ICAg
ICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBwYXRjaCBmb3IgcWVtdS11cHN0cmVhbQo+ICAg
ICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0Ogo+ICAgICAgICBodHRwOi8vbGlzdHMueGVu
Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1L21zZzAwMjUwLmh0bWwKPiAgICAg
ICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lmeWluZyB2aWRlb21lbSBzaXpl
IGZvciB0aGUKPiAgICAgICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29y
a3Mgd2l0aAo+ICAgICAgICBxZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNpIEvDpHJra8OkaW5l
bikKPgo+ICAgICAgKiBxZW11LXVwc3RyZWFtIGZvciBOZXRCU0QgKFJvZ2VyKQoKUGF0Y2ggY29t
bWl0dGVkIHRvIG5ldGJzZCBrZXJuZWwsIGF3YWl0aW5nIGFwcHJvdmFsLgoKPgo+ICAgICAgKiBb
QlVHXSBsb25nIHN0b3AgZHVyaW5nIHRoZSBndWVzdCBib290IHByb2Nlc3Mgd2l0aCBxY293IGlt
YWdlLAo+ICAgICAgICByZXBvcnRlZCBieSBJbnRlbDogaHR0cDovL2J1Z3ppbGxhLnhlbi5vcmcv
YnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjEKPgo+ICAgICAgKiBbQlVHXSB2Y3B1LXNldCBk
b2Vzbid0IHRha2UgZWZmZWN0IG9uIGd1ZXN0LCByZXBvcnRlZCBieSBJbnRlbDoKPiAgICAgICAg
aHR0cDovL2J1Z3ppbGxhLnhlbi5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjIKPgo+
ICAgICAgKiBMb2FkIGJsa3RhcCBkcml2ZXIgZnJvbSB4ZW5jb21tb25zIGluaXRzY3JpcHQgaWYg
YXZhaWxhYmxlLCB0aHJlYWQgYXQ6Cj4gICAgICAgIDxkYjYxNGU5MmZhZjc0M2UyMGIzZi4xMzM3
MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4ZWQgbW9yZQo+ICAgICAgICBwcm9wZXJseSBpbiA0LjMK
Pgo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Cj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Jun 18 08:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 08: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 1SgXSE-0004RZ-9u; Mon, 18 Jun 2012 08:36:58 +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 1SgXSC-0004RU-MC
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 08:36:57 +0000
Received: from [85.158.138.51:62133] by server-9.bemta-3.messagelabs.com id
	9A/D6-10419-7A8EEDF4; Mon, 18 Jun 2012 08:36:55 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340008614!28128095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19937 invoked from network); 18 Jun 2012 08:36:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 08:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.75,789,1330905600"; d="scan'208";a="13071504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 08:36:54 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 09:36:54 +0100
Message-ID: <4FDEE8A4.1080500@citrix.com>
Date: Mon, 18 Jun 2012 09:36:52 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IEEgYml0IGxhdGUgdGhpcyB3ZWVrLCBkdWUgdG8gbXkgYmVp
bmcgb24gdmFjYXRpb24uIEknbSBvbiB2YWNhdGlvbgo+IG5leHQgdHdvIE1vbmRheSBhcyB3ZWxs
IHNvIGl0IHdpbGwgYmUgbGF0ZSB0aGVuIHRvby4KPgo+IFBsYW4gZm9yIGEgNC4yIHJlbGVhc2U6
Cj4gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9t
c2cwMDc5My5odG1sCj4KPiBUaGUgdGltZSBsaW5lIGlzIGFzIGZvbGxvd3M6Cj4KPiAxOSBNYXJj
aCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCj4gMiBBcHJpbCAgICAgICAgIC0tIEZl
YXR1cmUgRnJlZXplCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDw8ICBXRSBBUkUgSEVSRQo+IFdoZW4gSXQncyBSZWFkeSAtLSBGaXJzdCByZWxlYXNl
IGNhbmRpZGF0ZQo+IFdlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCByZWxlYXNlCj4KPiBU
aGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVyIHRoZSByZWxlYXNlIHBsYW4gYSBzdHJv
bmcgY2FzZSB3aWxsCj4gbm93IGhhdmUgdG8gYmUgbWFkZSBhcyB0byB3aHkgbmV3IGl0ZW1zIHNo
b3VsZCBiZSBhZGRlZCB0byB0aGUgbGlzdCwKPiBlc3BlY2lhbGx5IGFzIGEgYmxvY2tlciwgcmF0
aGVyIHRoYW4gZGVmZXJyZWQgdG8gNC4zLgo+Cj4gSWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgYnVn
cyB3aGljaCBtdXN0L3Nob3VsZCBiZSBmaXhlZCBmb3IgNC4yIHRoZW4KPiBwbGVhc2UgcmVwbHkg
dG8gdGhpcyB0aHJlYWQgKG90aGVyd2lzZSBJIG1heSBub3QgcmVtZW1iZXIgdG8gcGljayB0aGVt
Cj4gdXAgbmV4dCB3ZWVrKQo+Cj4gT3RoZXIgdGhhbiB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGNv
bnNpZGVyIHRoZSBmcmVlemUgdG8gYmUgaW4gZnVsbAo+IGVmZmVjdCBhbmQgdGhlIGJhciB0byBl
bnRyeSB0byA0LjIgdG8gYmUgdmVyeSBoaWdoLgo+Cj4gaHlwZXJ2aXNvciwgYmxvY2tlcnM6Cj4K
PiAgICAgICogTm9uZQo+Cj4gdG9vbHMsIGJsb2NrZXJzOgo+Cj4gICAgICAqIGxpYnhsIHN0YWJs
ZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+ICAgICAg
ICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBB
c3BlY3RzIG9mCj4gICAgICAgIHRoaXMgYXJlOgo+Cj4gICAgICAgICAgKiBMSUJYTF9OSUNfVFlQ
RSBlbnVtIG5hbWVzIGFyZSBjb25mdXNpbmcuCj4KPiAgICAgICAgICAqIEludGVyZmFjZXMgd2hp
Y2ggbWF5IG5lZWQgdG8gYmUgYXN5bmM6Cj4KPiAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5f
c3VzcGVuZC4gTW92ZSB4Y19kb21haW5fc2F2ZS9yZXN0b3JlIGludG8gYQo+ICAgICAgICAgICAg
ICAgIHNlcGFyYXRlIHByb2Nlc3MgKElhbkosIHBhdGNoZXMgcG9zdGVkKS4KPgo+ICAgICAgICAg
ICAgICAqIGxpYnhsX2RldmljZV97ZGlzayxuaWMsdmtiLGFkZCxwY2l9X2FkZCAoYW5kCj4gICAg
ICAgICAgICAgICAgcmVtb3ZlKS4gKFJvZ2VyLCBwYXRjaGVzIHBvc3RlZCBmb3IgZGlzayYgIG5p
YywgdmtiCj4gICAgICAgICAgICAgICAgdHJpdmlhbCwgbm90IGxvb2tlZCBhdCBwY2kgeWV0KQo+
Cj4gICAgICAgICAgKiB1c2UgbGlieGxfY3B1bWFwIGZvciBiX2luZm8uYXZhaWxfY3B1cyBpbnN0
ZWFkIG9mIGFuIGludCwKPiAgICAgICAgICAgIHRoaXMiYWxsb3dzIHNldHRpbmcgbW9yZSB0aGFu
IDMxIENQVVMgKFlhbmcgWiBaaGFuZywgcGF0Y2hlcwo+ICAgICAgICAgICAgcG9zdGVkKQo+Cj4g
ICAgICAgICAgKiB1c2UgYW4gZW51bSBmb3IgVkdBIGludGVyZmFjZSB0eXBlIChlLmcuIENpcnJ1
cywKPiAgICAgICAgICAgIFN0ZFZHQSkuIEFsbG93cyBmb3IgUVhMIHN1cHBvcnQgKGluIDQuMyku
IChaaG91IFBlbmcsCj4gICAgICAgICAgICBwYXRjaGVzIHBvc3RlZCkKPgo+ICAgICAgKiB4bCBj
b21wYXRpYmlsaXR5IHdpdGggeG06Cj4KPiAgICAgICAgICAqIFtCVUddIGNhbm5vdCBjcmVhdGUg
YW4gZW1wdHkgQ0QtUk9NIGRyaXZlIG9uIEhWTSBndWVzdCwKPiAgICAgICAgICAgIHJlcG9ydGVk
IGJ5IEZhYmlvIEZhbnRvbmkgaW48NEY5NjcyREQuMjA4MDkwMkB0aXNjYWxpLml0Pgo+Cj4gICAg
ICAgICAgKiBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IHRyeSB0byBzZWxlY3QgYSAoc2V0IG9mKSBu
b2RlKHMpIG9uCj4gICAgICAgICAgICB3aGljaCB0byBjcmVhdGUgYSBWTSBhbmQgcGluIGl0cyB2
Y3B1cyB0aGVyZS4gKERhcmlvCj4gICAgICAgICAgICBGYWdnaW9saSwgcGF0Y2hlcyByZXBvc3Rl
ZCwgdW5kZXIgcmV2aWV3KQo+Cj4gICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hl
bmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5IGluCj4gICAgICAgIHRyZWUuIE5lZWRzIHJlbGVh
c2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCj4gICAgICAgIHJlbWlu
ZCBwZW9wbGUgdG8gdGVzdCB4bC4KPgo+ICAgICAgKiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0cyBm
cm9tIHhsIChMaW51eCBhbmQgTmV0QlNEKSAoUm9nZXIgUGF1Cj4gICAgICAgIE1vbm7DqSwgcGF0
Y2hlcyBwb3N0ZWQpCgpBbm90aGVyIHJvdW5kIHBvc3RlZCAodjYpLCB3YWl0aW5nIGZvciByZXZp
ZXcuCgo+Cj4gICAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBo
b3RwbHVnIHNjcmlwdCAoUm9nZXIKPiAgICAgICAgUGF1IE1vbm7DqSwgImp1c3QgYmUgYSBtYXR0
ZXIgb2YgcmVtb3ZpbmcgYW4gImlmIiIpCj4KPiAgICAgICogQWRqdXN0bWVudHMgbmVlZGVkIGZv
ciBxZGlzayBiYWNrZW5kIHRvIHdvcmsgb24gbm9uLXB2b3BzIExpbnV4Lgo+ICAgICAgICAicWVt
dS94ZW5kaXNrOiBzZXQgbWF4aW11bSBudW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4g
QmV1bGljaCkKPgo+ICAgICAgKiBDb25maXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAt
PiAgNC4yIHdvcmtzLi4uCj4KPiAgICAgICogW0JVR10gQnVpbGQgZmFpbHVyZSBkdWUgdG8gZ2Nj
IC1Xc3dpdGNoIG9uIHNvbWUgZGlzdHJvcwo+ICAgICAgICB2cy4gTElCWExfRE9NQUlOX1RZUEUu
IChEYXJpbyBGYWdnaW9saSwgRE9ORSkKPgo+IGh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKPgo+
ICAgICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwLCBwYXRj
aGVzIHBvc3RlZCkKPgo+IHRvb2xzLCBuaWNlIHRvIGhhdmU6Cj4KPiAgICAgICogeGwgY29tcGF0
aWJpbGl0eSB3aXRoIHhtOgo+Cj4gICAgICAgICAgKiBBY2NlcHQgInhsIGNyIC9kZXYvbnVsbCBw
YXJhbT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29uZmlnCj4gICAgICAgICAgICBvbiB0aGUgY29t
bWFuZCBsaW5lIChXLiBNaWNoYWVsIFBldHVsbG8sIHBhdGNoIHBvc3RlZCkKPgo+ICAgICAgKiBs
aWJ4bDogQWRkIEFQSSB0byByZXRyaWV2ZSBkb21haW4gY29uc29sZSB0dHkgKEJhbXZvciBKaWFu
Cj4gICAgICAgIFpoYW5nLCBET05FKQo+Cj4gICAgICAqIGxpYnhsIHN0YWJsZSBBUEkKPgo+ICAg
ICAgICAgICogbGlieGxfd2FpdF9mb3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5
X3RhcmdldC4KPiAgICAgICAgICAgIEludGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRl
ZCB0bwo+ICAgICAgICAgICAgbG9ja2luZy9zZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0
ZS4gSWFuSiB0byBhZGQgbm90ZQo+ICAgICAgICAgICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVp
bmcgc3Vic3RhbmRhcmQgYnV0IG90aGVyd2lzZSBkZWZlcgo+ICAgICAgICAgICAgdG8gNC4zLgo+
Cj4gICAgICAgICAgKiBJbnRlcmZhY2VzIHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgo+Cj4g
ICAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQgYmUgZWFzeSBvbmNlCj4g
ICAgICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0gZG9uZS4gVGhpcyBpcyBiYXNpY2FsbHkg
YSBoZWxwZXIKPiAgICAgICAgICAgICAgICBmdW5jdGlvbiBhbmQgaXRzIGZ1bmN0aW9uYWxpdHkg
Y2FuIGJlIGltcGxlbWVudGVkIGluCj4gICAgICAgICAgICAgICAgdGVybXMgb2YgdGhlIGxpYnhs
X2Rpc2tfKiBpbnRlcmZhY2VzLiBJZiB0aGlzIGlzIG5vdAo+ICAgICAgICAgICAgICAgIGRvbmUg
aW4gdGltZSB3ZSBzaG91bGQgZG9jdW1lbnQgYXMgYSBzdWJzdGFuZGFyZAo+ICAgICAgICAgICAg
ICAgIGludGVyZmFjZSB3aGljaCBpcyBzdWJqZWN0IHRvIGNoYW5nZSBwb3N0IDQuMi4KPgo+ICAg
ICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBwYXRjaCBmb3IgcWVtdS11cHN0cmVhbQo+ICAg
ICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0Ogo+ICAgICAgICBodHRwOi8vbGlzdHMueGVu
Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1L21zZzAwMjUwLmh0bWwKPiAgICAg
ICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lmeWluZyB2aWRlb21lbSBzaXpl
IGZvciB0aGUKPiAgICAgICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29y
a3Mgd2l0aAo+ICAgICAgICBxZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNpIEvDpHJra8OkaW5l
bikKPgo+ICAgICAgKiBxZW11LXVwc3RyZWFtIGZvciBOZXRCU0QgKFJvZ2VyKQoKUGF0Y2ggY29t
bWl0dGVkIHRvIG5ldGJzZCBrZXJuZWwsIGF3YWl0aW5nIGFwcHJvdmFsLgoKPgo+ICAgICAgKiBb
QlVHXSBsb25nIHN0b3AgZHVyaW5nIHRoZSBndWVzdCBib290IHByb2Nlc3Mgd2l0aCBxY293IGlt
YWdlLAo+ICAgICAgICByZXBvcnRlZCBieSBJbnRlbDogaHR0cDovL2J1Z3ppbGxhLnhlbi5vcmcv
YnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjEKPgo+ICAgICAgKiBbQlVHXSB2Y3B1LXNldCBk
b2Vzbid0IHRha2UgZWZmZWN0IG9uIGd1ZXN0LCByZXBvcnRlZCBieSBJbnRlbDoKPiAgICAgICAg
aHR0cDovL2J1Z3ppbGxhLnhlbi5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjIKPgo+
ICAgICAgKiBMb2FkIGJsa3RhcCBkcml2ZXIgZnJvbSB4ZW5jb21tb25zIGluaXRzY3JpcHQgaWYg
YXZhaWxhYmxlLCB0aHJlYWQgYXQ6Cj4gICAgICAgIDxkYjYxNGU5MmZhZjc0M2UyMGIzZi4xMzM3
MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4ZWQgbW9yZQo+ICAgICAgICBwcm9wZXJseSBpbiA0LjMK
Pgo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Cj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Jun 18 08:59:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 08:59: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 1SgXmt-0004fW-4u; Mon, 18 Jun 2012 08:58:19 +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 1SgXms-0004fR-71
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 08:58:18 +0000
Received: from [193.109.254.147:29056] by server-9.bemta-14.messagelabs.com id
	86/D3-07693-9ADEEDF4; Mon, 18 Jun 2012 08:58:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340009896!10198244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32012 invoked from network); 18 Jun 2012 08:58:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 08:58:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13072004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 08:58:16 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 09:58:16 +0100
Message-ID: <4FDEEDA7.4070308@citrix.com>
Date: Mon, 18 Jun 2012 09:58:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-2-git-send-email-roger.pau@citrix.com>
	<20443.26269.316806.269605@mariner.uk.xensource.com>
In-Reply-To: <20443.26269.316806.269605@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 01/13] libxl: change ao_device_remove to
	ao_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

Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 01/13] libxl: change ao_device_remove to ao_device"):
>> Introduce a new structure to track state of device backends, that will
>> be used in following patches on this series.
> ...
>
> Looks good.  I have only one comment:
>
>> +static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
>> +{
>> +    STATE_AO_GC(aodev->ao);
>> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
>> +    char *fe_path = libxl__device_frontend_path(gc, aodev->dev);
>> +    xs_transaction_t t = 0;
>> +    int ret = 0;
>> +
>> +    if (aodev->action == DEVICE_DISCONNECT) {
>> +        do {
>> +            t = xs_transaction_start(CTX->xsh);
>> +            libxl__xs_path_cleanup(gc, t, fe_path);
>> +            libxl__xs_path_cleanup(gc, t, be_path);
>> +            ret = !xs_transaction_end(CTX->xsh, t, 0);
>> +        } while (ret&&  errno == EAGAIN);
>
> The error handling here seems a bit lacking.  Perhaps you should
> import my "[PATCH 08/21] libxl: provide libxl__xs_*_checked ..." into
> your series and use those ?  You can see an example of how they're
> used in "[PATCH 09/21] libxl: wait for qemu to acknowledge logdirty
> command".

Is it possible to change this part of the code after you have committed 
your series? If you want I can send a patch to fix this so you can add 
it at the end of your series.

> And you need to check the return values from libxl__xs_path_cleanup.

Even if I check the return value from libxl__xs_path_cleanup I will only 
print an error message, but the logic of the function will not change, 
and the error message it's already printed by libxl__xs_path_cleanup. If 
front or back xenstore entries remove failed, I will still try to remove 
the other entries and commit the transaction.

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 Mon Jun 18 08:59:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 08:59: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 1SgXmt-0004fW-4u; Mon, 18 Jun 2012 08:58:19 +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 1SgXms-0004fR-71
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 08:58:18 +0000
Received: from [193.109.254.147:29056] by server-9.bemta-14.messagelabs.com id
	86/D3-07693-9ADEEDF4; Mon, 18 Jun 2012 08:58:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340009896!10198244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32012 invoked from network); 18 Jun 2012 08:58:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 08:58:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13072004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 08:58:16 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 09:58:16 +0100
Message-ID: <4FDEEDA7.4070308@citrix.com>
Date: Mon, 18 Jun 2012 09:58:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-2-git-send-email-roger.pau@citrix.com>
	<20443.26269.316806.269605@mariner.uk.xensource.com>
In-Reply-To: <20443.26269.316806.269605@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 01/13] libxl: change ao_device_remove to
	ao_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

Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 01/13] libxl: change ao_device_remove to ao_device"):
>> Introduce a new structure to track state of device backends, that will
>> be used in following patches on this series.
> ...
>
> Looks good.  I have only one comment:
>
>> +static void device_xsentries_remove(libxl__egc *egc, libxl__ao_device *aodev)
>> +{
>> +    STATE_AO_GC(aodev->ao);
>> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
>> +    char *fe_path = libxl__device_frontend_path(gc, aodev->dev);
>> +    xs_transaction_t t = 0;
>> +    int ret = 0;
>> +
>> +    if (aodev->action == DEVICE_DISCONNECT) {
>> +        do {
>> +            t = xs_transaction_start(CTX->xsh);
>> +            libxl__xs_path_cleanup(gc, t, fe_path);
>> +            libxl__xs_path_cleanup(gc, t, be_path);
>> +            ret = !xs_transaction_end(CTX->xsh, t, 0);
>> +        } while (ret&&  errno == EAGAIN);
>
> The error handling here seems a bit lacking.  Perhaps you should
> import my "[PATCH 08/21] libxl: provide libxl__xs_*_checked ..." into
> your series and use those ?  You can see an example of how they're
> used in "[PATCH 09/21] libxl: wait for qemu to acknowledge logdirty
> command".

Is it possible to change this part of the code after you have committed 
your series? If you want I can send a patch to fix this so you can add 
it at the end of your series.

> And you need to check the return values from libxl__xs_path_cleanup.

Even if I check the return value from libxl__xs_path_cleanup I will only 
print an error message, but the logic of the function will not change, 
and the error message it's already printed by libxl__xs_path_cleanup. If 
front or back xenstore entries remove failed, I will still try to remove 
the other entries and commit the transaction.

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 Mon Jun 18 09:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:01: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 1SgXpI-0004oF-TA; Mon, 18 Jun 2012 09:00:48 +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 1SgXpH-0004nz-3c
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 09:00:47 +0000
Received: from [85.158.139.83:59077] by server-11.bemta-5.messagelabs.com id
	F7/E7-20400-E3EEEDF4; Mon, 18 Jun 2012 09:00:46 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340010045!28156616!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5869 invoked from network); 18 Jun 2012 09:00:45 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 09:00:45 -0000
Received: from p5b2e2526.dip.t-dialin.net ([91.46.37.38] 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 1SgXpE-0002rf-6N; Mon, 18 Jun 2012 09:00:44 +0000
Message-ID: <4FDEEE3A.9090302@canonical.com>
Date: Mon, 18 Jun 2012 11:00:42 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Rolu <rolu@roce.org>
References: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
	<CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
	<CABs9EjkQS4VbUjPE6mt_P2zCi3JxAT0LaiztiRTEb-SntUnGXQ@mail.gmail.com>
In-Reply-To: <CABs9EjkQS4VbUjPE6mt_P2zCi3JxAT0LaiztiRTEb-SntUnGXQ@mail.gmail.com>
X-Enigmail-Version: 1.5pre
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8104762174770862141=="
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)
--===============8104762174770862141==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig4D7AFD07F4F7B9CAA9BA0C89"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4D7AFD07F4F7B9CAA9BA0C89
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 17.06.2012 05:23, Rolu wrote:
> On Sun, Jun 17, 2012 at 5:04 AM, AP <apxeng@gmail.com> wrote:
>>
>> On Jun 16, 2012 5:56 PM, "Rolu" <rolu@roce.org> wrote:
>>>
>>> When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
>>> crashes. I've included a serial console log below.
>>>
>>> I've used:
>>> Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
>>> apply the AT_EMPTY_PATH patch from
>>> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to=

>>> get it to compile.
>>> Linux 3.2.0-25, which is the default kernel in Ubuntu's repository ri=
ght
>>> now.
>>> Ubuntu 12.04 Precise
>>>
>>> Booting with the default Xen 4.1 from the Ubuntu repositories works.
>>>
>>> Using the kernel from
>>> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is=

>>> a mainline Linux kernel (and also more recent) works with my compiled=

>>> version of Xen 4.2
>>>
>>> So,
>>> * Is xen 4.2 not happy with the 3.2 kernel I've used?
>>> * Is this due to something Ubuntu modified in their default kernel?
>>> * Is this an issue with Xen?
>>> * Did I break something?
>>
>> This is an issue with the Ubuntu kernel. Check this thread out:
>> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html
>>
This is an issue between libc not checking all flags correctly and a curr=
ent
hack to work around a bug on older Xen versions.
If I understood correctly there was a fix going into libc but I am also i=
n the
process of changing that hack to prevent those issues. But it will go int=
o 12.10
first and then move backwards.

-Stefan

>> Adding xsave=3D0 to the Xen kernel line in grub is the workaround.
>>
>=20
> Indeed, this worked. Thanks!
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




--------------enig4D7AFD07F4F7B9CAA9BA0C89
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJP3u46AAoJEOhnXe7L7s6ju5QP/j1VWIp71pHlNKdXmlSpdlNB
DPrusJnA8hwTrnyzubbLkqViSoH75aOfF+LMeaq63UabS5E2XXVyRXp6q6QAvtJ3
XR+hSbGYLgvq/5BlF9bYoq5FMFzESOGDbKnMnVM2/VYgRuY5EqWqh/UAOPbQWzKl
eoR2axU/aQorB9MkIK1CtGdlOSZm2ADYvlJgfBz0uCv8/s/XlSuQWWsTyZyeyn0D
5aKU9Nf2BixsiSaPe+g8YAzqlZxTPxaKq1S8gkJ2MGwPVNozusa5koyWmDP++00v
jAPy8H840ErIeDOXnXlronmst9EgSTs8Gk8NifaiOojZF2d32Tbs6uHkUd6427oZ
LzYYgIp6aPtmChWF6hynx5l/teg3XRigenEwxJaO0LIP8u2Y0tpBIjRbPJjEEmm0
ELHrB1kuVWAbCH0ZPduXkI5CMrsl1ZbCVvrStl7FX5zULG1A5Y/hehYfKyTZUIFz
L+hD62i75gUNAym7TfDgROVXeUid3Y+m85hJTUvwu1lAxuVw8Qj9VFAGgwXTySxs
D5ozcjRI4BRtNzOMazGtxDTbtWx6E9Rapg9bB3WH0RSKX0ri7Wqn+r/lWBsAgmOL
wslgqosW17ChKsreeJvY4heoRyZJYyeJUn5bpGJ+ob2V/LI2SWU6Z8R4nlUOYGbS
TRLnAQhSQ/wr0fxpufew
=JXqE
-----END PGP SIGNATURE-----

--------------enig4D7AFD07F4F7B9CAA9BA0C89--


--===============8104762174770862141==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8104762174770862141==--


From xen-devel-bounces@lists.xen.org Mon Jun 18 09:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:01: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 1SgXpI-0004oF-TA; Mon, 18 Jun 2012 09:00:48 +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 1SgXpH-0004nz-3c
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 09:00:47 +0000
Received: from [85.158.139.83:59077] by server-11.bemta-5.messagelabs.com id
	F7/E7-20400-E3EEEDF4; Mon, 18 Jun 2012 09:00:46 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340010045!28156616!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5869 invoked from network); 18 Jun 2012 09:00:45 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 09:00:45 -0000
Received: from p5b2e2526.dip.t-dialin.net ([91.46.37.38] 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 1SgXpE-0002rf-6N; Mon, 18 Jun 2012 09:00:44 +0000
Message-ID: <4FDEEE3A.9090302@canonical.com>
Date: Mon, 18 Jun 2012 11:00:42 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Rolu <rolu@roce.org>
References: <CABs9Ej=msehOFRwqdqgPkgntoxQ9gZj5aA3y+gT+KV-BeJv+_Q@mail.gmail.com>
	<CAGU+ausBB5-uoojZaebgLwGFWgbPatrxeKAO7VNPiuTvYt0dWA@mail.gmail.com>
	<CABs9EjkQS4VbUjPE6mt_P2zCi3JxAT0LaiztiRTEb-SntUnGXQ@mail.gmail.com>
In-Reply-To: <CABs9EjkQS4VbUjPE6mt_P2zCi3JxAT0LaiztiRTEb-SntUnGXQ@mail.gmail.com>
X-Enigmail-Version: 1.5pre
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Possible bug, dom0 crash on ubuntu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8104762174770862141=="
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)
--===============8104762174770862141==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig4D7AFD07F4F7B9CAA9BA0C89"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4D7AFD07F4F7B9CAA9BA0C89
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 17.06.2012 05:23, Rolu wrote:
> On Sun, Jun 17, 2012 at 5:04 AM, AP <apxeng@gmail.com> wrote:
>>
>> On Jun 16, 2012 5:56 PM, "Rolu" <rolu@roce.org> wrote:
>>>
>>> When booting a recently compiled Xen 4.2 on Ubuntu 12.04, dom0
>>> crashes. I've included a serial console log below.
>>>
>>> I've used:
>>> Xen 4.2 unstable rev. 25483, compiled on the same machine. I had to
>>> apply the AT_EMPTY_PATH patch from
>>> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg03460.html to=

>>> get it to compile.
>>> Linux 3.2.0-25, which is the default kernel in Ubuntu's repository ri=
ght
>>> now.
>>> Ubuntu 12.04 Precise
>>>
>>> Booting with the default Xen 4.1 from the Ubuntu repositories works.
>>>
>>> Using the kernel from
>>> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/, which is=

>>> a mainline Linux kernel (and also more recent) works with my compiled=

>>> version of Xen 4.2
>>>
>>> So,
>>> * Is xen 4.2 not happy with the 3.2 kernel I've used?
>>> * Is this due to something Ubuntu modified in their default kernel?
>>> * Is this an issue with Xen?
>>> * Did I break something?
>>
>> This is an issue with the Ubuntu kernel. Check this thread out:
>> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00049.html
>>
This is an issue between libc not checking all flags correctly and a curr=
ent
hack to work around a bug on older Xen versions.
If I understood correctly there was a fix going into libc but I am also i=
n the
process of changing that hack to prevent those issues. But it will go int=
o 12.10
first and then move backwards.

-Stefan

>> Adding xsave=3D0 to the Xen kernel line in grub is the workaround.
>>
>=20
> Indeed, this worked. Thanks!
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




--------------enig4D7AFD07F4F7B9CAA9BA0C89
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJP3u46AAoJEOhnXe7L7s6ju5QP/j1VWIp71pHlNKdXmlSpdlNB
DPrusJnA8hwTrnyzubbLkqViSoH75aOfF+LMeaq63UabS5E2XXVyRXp6q6QAvtJ3
XR+hSbGYLgvq/5BlF9bYoq5FMFzESOGDbKnMnVM2/VYgRuY5EqWqh/UAOPbQWzKl
eoR2axU/aQorB9MkIK1CtGdlOSZm2ADYvlJgfBz0uCv8/s/XlSuQWWsTyZyeyn0D
5aKU9Nf2BixsiSaPe+g8YAzqlZxTPxaKq1S8gkJ2MGwPVNozusa5koyWmDP++00v
jAPy8H840ErIeDOXnXlronmst9EgSTs8Gk8NifaiOojZF2d32Tbs6uHkUd6427oZ
LzYYgIp6aPtmChWF6hynx5l/teg3XRigenEwxJaO0LIP8u2Y0tpBIjRbPJjEEmm0
ELHrB1kuVWAbCH0ZPduXkI5CMrsl1ZbCVvrStl7FX5zULG1A5Y/hehYfKyTZUIFz
L+hD62i75gUNAym7TfDgROVXeUid3Y+m85hJTUvwu1lAxuVw8Qj9VFAGgwXTySxs
D5ozcjRI4BRtNzOMazGtxDTbtWx6E9Rapg9bB3WH0RSKX0ri7Wqn+r/lWBsAgmOL
wslgqosW17ChKsreeJvY4heoRyZJYyeJUn5bpGJ+ob2V/LI2SWU6Z8R4nlUOYGbS
TRLnAQhSQ/wr0fxpufew
=JXqE
-----END PGP SIGNATURE-----

--------------enig4D7AFD07F4F7B9CAA9BA0C89--


--===============8104762174770862141==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8104762174770862141==--


From xen-devel-bounces@lists.xen.org Mon Jun 18 09:30:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09: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 1SgYHa-0005Bz-Bi; Mon, 18 Jun 2012 09:30:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rusty@ozlabs.org>) id 1SgYHY-0005Bu-BN
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 09:30:00 +0000
Received: from [85.158.143.99:33792] by server-1.bemta-4.messagelabs.com id
	A5/66-24392-715FEDF4; Mon, 18 Jun 2012 09:29:59 +0000
X-Env-Sender: rusty@ozlabs.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340011795!20138688!1
X-Originating-IP: [203.10.76.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18252 invoked from network); 18 Jun 2012 09:29:58 -0000
Received: from ozlabs.org (HELO ozlabs.org) (203.10.76.45)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 09:29:58 -0000
Received: by ozlabs.org (Postfix, from userid 1011)
	id B63B1B70EA; Mon, 18 Jun 2012 19:29:23 +1000 (EST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <4FDA304C.4050306@zytor.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
	<4FD8AB07.7080004@citrix.com>
	<20120614182913.GA21956@phenom.dumpdata.com>
	<4FDA304C.4050306@zytor.com>
User-Agent: Notmuch/0.12 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Mon, 18 Jun 2012 18:43:28 +0930
Message-ID: <87bokhyocn.fsf@rustcorp.com.au>
MIME-Version: 1.0
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
	get-and-clear functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 14 Jun 2012 11:41:16 -0700, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 06/14/2012 11:29 AM, Konrad Rzeszutek Wilk wrote:
> > 
> > Lets rope Rusty in this since he is the maintainer of lguest.
> >
> 
> Also, let's have realistic expectations for lguest.
> 
> I don't want to break lguest just for sh*ts and giggles, but if lguest
> is in the way of making forward progress for other things, it would have
> to have a very strong case to not be sacrificed.

Exactly!  Please cc' me if you need me to unbreak lguest, but for
performance?  Not really...

Cheers,
Rusty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 09:30:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09: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 1SgYHa-0005Bz-Bi; Mon, 18 Jun 2012 09:30:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rusty@ozlabs.org>) id 1SgYHY-0005Bu-BN
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 09:30:00 +0000
Received: from [85.158.143.99:33792] by server-1.bemta-4.messagelabs.com id
	A5/66-24392-715FEDF4; Mon, 18 Jun 2012 09:29:59 +0000
X-Env-Sender: rusty@ozlabs.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340011795!20138688!1
X-Originating-IP: [203.10.76.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18252 invoked from network); 18 Jun 2012 09:29:58 -0000
Received: from ozlabs.org (HELO ozlabs.org) (203.10.76.45)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 09:29:58 -0000
Received: by ozlabs.org (Postfix, from userid 1011)
	id B63B1B70EA; Mon, 18 Jun 2012 19:29:23 +1000 (EST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <4FDA304C.4050306@zytor.com>
References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com>
	<20120613140404.GH5979@phenom.dumpdata.com>
	<4FD8AB07.7080004@citrix.com>
	<20120614182913.GA21956@phenom.dumpdata.com>
	<4FDA304C.4050306@zytor.com>
User-Agent: Notmuch/0.12 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Mon, 18 Jun 2012 18:43:28 +0930
Message-ID: <87bokhyocn.fsf@rustcorp.com.au>
MIME-Version: 1.0
Cc: "x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD
	get-and-clear functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 14 Jun 2012 11:41:16 -0700, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 06/14/2012 11:29 AM, Konrad Rzeszutek Wilk wrote:
> > 
> > Lets rope Rusty in this since he is the maintainer of lguest.
> >
> 
> Also, let's have realistic expectations for lguest.
> 
> I don't want to break lguest just for sh*ts and giggles, but if lguest
> is in the way of making forward progress for other things, it would have
> to have a very strong case to not be sacrificed.

Exactly!  Please cc' me if you need me to unbreak lguest, but for
performance?  Not really...

Cheers,
Rusty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 09:35:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:35: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 1SgYMq-0005PU-4Q; Mon, 18 Jun 2012 09:35:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gabrielx.wu@intel.com>) id 1SgYMo-0005PM-Nj
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 09:35:26 +0000
Received: from [85.158.139.83:31378] by server-4.bemta-5.messagelabs.com id
	4E/B2-27831-D56FEDF4; Mon, 18 Jun 2012 09:35:25 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340012124!28455185!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM2ODY0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29031 invoked from network); 18 Jun 2012 09:35:25 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 09:35:25 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 18 Jun 2012 02:35:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="154733583"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 18 Jun 2012 02:35:23 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 18 Jun 2012 02:35:23 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Mon, 18 Jun 2012 17:35:21 +0800
From: "Wu, GabrielX" <gabrielx.wu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: VMX status report. Xen:25467 & Dom0:3.4.1
Thread-Index: AQHNTTWu0ZORwApGp0CimgR+KR8zzQ==
Date: Mon, 18 Jun 2012 09:35:21 +0000
Message-ID: <E4558C0C96688748837EB1B05BEED75A0FD1E65D@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: "Ren, Yongjie" <yongjie.ren@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>
Subject: [Xen-devel] VMX status report. Xen:25467 & Dom0:3.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

Hi all,

This is the test report of xen-unstable tree. 
There is one issue found and two issues got fixed.

Version Info:
=================================================================
xen-changeset:   25467:32034d1914a6
Dom0:          linux.git  3.4.1
=================================================================

New issue(1)
==============
1.Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824

Fixed issues(2)
==============
1. [VT-D] device reset fail when create/destroy guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752
2. cpu weight out of range error when create hvm domU
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818

Old issues(9)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
6. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
7. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
8. long stop during the guest boot process with qcow image
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
9. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822

Thanks,
Wu Ronghui(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 09:35:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:35: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 1SgYMq-0005PU-4Q; Mon, 18 Jun 2012 09:35:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gabrielx.wu@intel.com>) id 1SgYMo-0005PM-Nj
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 09:35:26 +0000
Received: from [85.158.139.83:31378] by server-4.bemta-5.messagelabs.com id
	4E/B2-27831-D56FEDF4; Mon, 18 Jun 2012 09:35:25 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340012124!28455185!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM2ODY0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29031 invoked from network); 18 Jun 2012 09:35:25 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 09:35:25 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 18 Jun 2012 02:35:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="154733583"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 18 Jun 2012 02:35:23 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 18 Jun 2012 02:35:23 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Mon, 18 Jun 2012 17:35:21 +0800
From: "Wu, GabrielX" <gabrielx.wu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: VMX status report. Xen:25467 & Dom0:3.4.1
Thread-Index: AQHNTTWu0ZORwApGp0CimgR+KR8zzQ==
Date: Mon, 18 Jun 2012 09:35:21 +0000
Message-ID: <E4558C0C96688748837EB1B05BEED75A0FD1E65D@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: "Ren, Yongjie" <yongjie.ren@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>
Subject: [Xen-devel] VMX status report. Xen:25467 & Dom0:3.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

Hi all,

This is the test report of xen-unstable tree. 
There is one issue found and two issues got fixed.

Version Info:
=================================================================
xen-changeset:   25467:32034d1914a6
Dom0:          linux.git  3.4.1
=================================================================

New issue(1)
==============
1.Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824

Fixed issues(2)
==============
1. [VT-D] device reset fail when create/destroy guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752
2. cpu weight out of range error when create hvm domU
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818

Old issues(9)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
6. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
7. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
8. long stop during the guest boot process with qcow image
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
9. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822

Thanks,
Wu Ronghui(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 09:39:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:39: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 1SgYQ4-0005X6-O6; Mon, 18 Jun 2012 09:38:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <svg@ngs.ru>)
	id 1SgYQ2-0005X1-Mz
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 09:38:46 +0000
Received: from [85.158.139.83:10624] by server-6.bemta-5.messagelabs.com id
	9B/29-11348-527FEDF4; Mon, 18 Jun 2012 09:38:45 +0000
X-Env-Sender: svg@ngs.ru
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340012324!27640226!1
X-Originating-IP: [195.19.71.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23668 invoked from network); 18 Jun 2012 09:38:45 -0000
Received: from smtpout27.ngs.ru (HELO smtpout.ngs.ru) (195.19.71.10)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 09:38:45 -0000
Received: from [192.168.0.100] (host-89-31-115-109.academ.org [89.31.115.109])
	(Authenticated sender: svg@ngs.ru)
	by mail.ngs.ru (smtp) with ESMTPA id 73759180338
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 16:38:38 +0700 (NOVT)
From: Sergey Zhukov <svg@ngs.ru>
To: xen-devel@lists.xen.org
Date: Mon, 18 Jun 2012 16:38:39 +0700
Message-ID: <1340012319.13742.114.camel@sergey>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Subject: [Xen-devel] Forking time 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,

I repost this message from xen-users list following by others
subscribers suggestions:


I found an article about forking time for redis NoSQL database in
different systems:

http://redis.io/topics/latency
---------Quote------------------
Fork time in different systems
Modern hardware is pretty fast to copy the page table, but Xen is not.
The problem with Xen is not virtualization-specific, but Xen-specific.
For instance using VMware or Virutal Box does not result into slow fork
time. The following is a table that compares fork time for different
Redis instance size. Data is obtained performing a BGSAVE and looking at
the latest_fork_usec filed in the INFO command output.

      * Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
        (12.8 milliseconds per GB).
      * Linux running on physical machine (Unknown HW) 6.1GB RSS forked
        in 80 milliseconds (13.1 milliseconds per GB)
      * Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
        forked into 62 millisecodns (9 milliseconds per GB).
      * Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
        (23.3 millisecond per GB).
      * Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
        (239.3 milliseconds per GB).
      * Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns
        (424 milliseconds per GB).

As you can see a VM running on Xen has a performance hit that is between
one order to two orders of magnitude. We believe this is a severe
problem with Xen and we hope it will be addressed ASAP.
----------End of quote-----------------

I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
test was performed on Intel Core I5 2500 processor unit. Forking time
was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
EC2/Linode were mentioned in the article, but still much slower then
VMWare or physical machines. Has anyone running with this issue? Or may
be there is a way to tune Xen for less forking times?

Sergey Zhukov


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 09:39:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:39: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 1SgYQ4-0005X6-O6; Mon, 18 Jun 2012 09:38:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <svg@ngs.ru>)
	id 1SgYQ2-0005X1-Mz
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 09:38:46 +0000
Received: from [85.158.139.83:10624] by server-6.bemta-5.messagelabs.com id
	9B/29-11348-527FEDF4; Mon, 18 Jun 2012 09:38:45 +0000
X-Env-Sender: svg@ngs.ru
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340012324!27640226!1
X-Originating-IP: [195.19.71.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23668 invoked from network); 18 Jun 2012 09:38:45 -0000
Received: from smtpout27.ngs.ru (HELO smtpout.ngs.ru) (195.19.71.10)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 09:38:45 -0000
Received: from [192.168.0.100] (host-89-31-115-109.academ.org [89.31.115.109])
	(Authenticated sender: svg@ngs.ru)
	by mail.ngs.ru (smtp) with ESMTPA id 73759180338
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 16:38:38 +0700 (NOVT)
From: Sergey Zhukov <svg@ngs.ru>
To: xen-devel@lists.xen.org
Date: Mon, 18 Jun 2012 16:38:39 +0700
Message-ID: <1340012319.13742.114.camel@sergey>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Subject: [Xen-devel] Forking time 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,

I repost this message from xen-users list following by others
subscribers suggestions:


I found an article about forking time for redis NoSQL database in
different systems:

http://redis.io/topics/latency
---------Quote------------------
Fork time in different systems
Modern hardware is pretty fast to copy the page table, but Xen is not.
The problem with Xen is not virtualization-specific, but Xen-specific.
For instance using VMware or Virutal Box does not result into slow fork
time. The following is a table that compares fork time for different
Redis instance size. Data is obtained performing a BGSAVE and looking at
the latest_fork_usec filed in the INFO command output.

      * Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
        (12.8 milliseconds per GB).
      * Linux running on physical machine (Unknown HW) 6.1GB RSS forked
        in 80 milliseconds (13.1 milliseconds per GB)
      * Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
        forked into 62 millisecodns (9 milliseconds per GB).
      * Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
        (23.3 millisecond per GB).
      * Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
        (239.3 milliseconds per GB).
      * Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns
        (424 milliseconds per GB).

As you can see a VM running on Xen has a performance hit that is between
one order to two orders of magnitude. We believe this is a severe
problem with Xen and we hope it will be addressed ASAP.
----------End of quote-----------------

I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
test was performed on Intel Core I5 2500 processor unit. Forking time
was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
EC2/Linode were mentioned in the article, but still much slower then
VMWare or physical machines. Has anyone running with this issue? Or may
be there is a way to tune Xen for less forking times?

Sergey Zhukov


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 09:51:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:51: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 1SgYbX-0005lF-Up; Mon, 18 Jun 2012 09:50: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 1SgYbV-0005lA-Qz
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 09:50:38 +0000
Received: from [85.158.139.83:18758] by server-3.bemta-5.messagelabs.com id
	98/0C-03367-CE9FEDF4; Mon, 18 Jun 2012 09:50:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340013036!28181179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10537 invoked from network); 18 Jun 2012 09:50:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 09:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13072935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 09:50:13 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 10:50:13 +0100
Message-ID: <4FDEF9D4.8090600@citrix.com>
Date: Mon, 18 Jun 2012 10:50:12 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <E1STyDY-0007RL-8b@xenbits.xen.org>
	<1337949759.22311.33.camel@zakaz.uk.xensource.com>
	<4FBF8B49.1080003@citrix.com>
	<1337954191.22311.35.camel@zakaz.uk.xensource.com>
In-Reply-To: <1337954191.22311.35.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [Xen-staging] [xen-unstable] autoconf: check for
 dev86 and iasl on x86* 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Fri, 2012-05-25 at 14:38 +0100, Roger Pau Monne wrote:
>>> Is that expected? I don't think it is... Should these not be the ones
>>> which are conditional?
>> It is a conditional, but since the script is the same for all
>> architectures and arch is not checked when doing a "configure --help",
>> all the possible options are printed, even those that don't apply to a
>> system. I will try to check if there's a better way to hide them, but
>> I'm not sure.
>
> If not then I guess the original patch should be reverted?

The original patch doesn't do anything, so yes it can be reverted 
(although it doesn't affect configure in any way).

>>>>    # Checks for programs.
>>>>    ac_ext=c
>>>> diff -r 49ce39c88aee -r dfe39bd65137 tools/configure.ac
>>>> --- a/tools/configure.ac	Mon May 14 16:20:33 2012 +0100
>>>> +++ b/tools/configure.ac	Mon May 14 16:22:39 2012 +0100
>>>> @@ -67,10 +67,16 @@ AC_ARG_VAR([CURL], [Path to curl-config
>>>>    AC_ARG_VAR([XML], [Path to xml2-config tool])
>>>>    AC_ARG_VAR([BASH], [Path to bash shell])
>>>>    AC_ARG_VAR([XGETTEXT], [Path to xgetttext tool])
>>>> -AC_ARG_VAR([AS86], [Path to as86 tool])
>>>> -AC_ARG_VAR([LD86], [Path to ld86 tool])
>>>> -AC_ARG_VAR([BCC], [Path to bcc tool])
>>>> -AC_ARG_VAR([IASL], [Path to iasl tool])
>>>> +
>>>> +dnl as86, ld86, bcc and iasl are only present in x86* systems
>>>> +case "$host_cpu" in
>>>> +i[[3456]]86|x86_64)
>>>> +    AC_ARG_VAR([AS86], [Path to as86 tool])
>>>> +    AC_ARG_VAR([LD86], [Path to ld86 tool])
>>>> +    AC_ARG_VAR([BCC], [Path to bcc tool])
>>>> +    AC_ARG_VAR([IASL], [Path to iasl tool])
>>>> +    ;;
>>>> +esac
>>>>
>>>>    # Checks for programs.
>>>>    AC_PROG_CC
>>>>
>> I don't know why, but I think my previous patch missed to also make the
>> actual check conditional, so the applied patch was useless. This should
>> fix it:
>>
>> 8<----------------------------------------------------------
>>
>> autoconf: disable dev86 and iasl checks on arm
>>
>> Run autogen after applying this patch.
>>
>> Signed-off-by: Roger Pau Monne<roger.pau@citrix.com>
>
> Looks good to me
> Acked-by: Ian Campbell<ian.campbell@citrix.com>

Any news on this one? It's been quite some time since the Ack, but I 
don't think it has been committed (or at least I cannot find it).

Thanks!

>> ---
>>    tools/configure.ac |   13 +++++++++----
>>    1 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/configure.ac b/tools/configure.ac
>> index 706ee13..f7aa9b8 100644
>> --- a/tools/configure.ac
>> +++ b/tools/configure.ac
>> @@ -109,10 +109,15 @@ AS_IF([test "x$pythontools" = "xy"], [
>>        AX_CHECK_PYTHON_DEVEL()
>>    ])
>>    AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
>> -AX_PATH_PROG_OR_FAIL([AS86], [as86])
>> -AX_PATH_PROG_OR_FAIL([LD86], [ld86])
>> -AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>> -AX_PATH_PROG_OR_FAIL([IASL], [iasl])
>> +dnl as86, ld86, bcc and iasl are only present in x86* systems
>> +case "$host_cpu" in
>> +i[[3456]]86|x86_64)
>> +    AX_PATH_PROG_OR_FAIL([AS86], [as86])
>> +    AX_PATH_PROG_OR_FAIL([LD86], [ld86])
>> +    AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>> +    AX_PATH_PROG_OR_FAIL([IASL], [iasl])
>> +    ;;
>> +esac
>>    AX_CHECK_UUID
>>    AX_CHECK_CURSES
>>    PKG_CHECK_MODULES(glib, glib-2.0)
>> --
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 09:51:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 09:51: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 1SgYbX-0005lF-Up; Mon, 18 Jun 2012 09:50: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 1SgYbV-0005lA-Qz
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 09:50:38 +0000
Received: from [85.158.139.83:18758] by server-3.bemta-5.messagelabs.com id
	98/0C-03367-CE9FEDF4; Mon, 18 Jun 2012 09:50:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340013036!28181179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10537 invoked from network); 18 Jun 2012 09:50:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 09:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13072935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 09:50:13 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 10:50:13 +0100
Message-ID: <4FDEF9D4.8090600@citrix.com>
Date: Mon, 18 Jun 2012 10:50:12 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <E1STyDY-0007RL-8b@xenbits.xen.org>
	<1337949759.22311.33.camel@zakaz.uk.xensource.com>
	<4FBF8B49.1080003@citrix.com>
	<1337954191.22311.35.camel@zakaz.uk.xensource.com>
In-Reply-To: <1337954191.22311.35.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [Xen-staging] [xen-unstable] autoconf: check for
 dev86 and iasl on x86* 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Fri, 2012-05-25 at 14:38 +0100, Roger Pau Monne wrote:
>>> Is that expected? I don't think it is... Should these not be the ones
>>> which are conditional?
>> It is a conditional, but since the script is the same for all
>> architectures and arch is not checked when doing a "configure --help",
>> all the possible options are printed, even those that don't apply to a
>> system. I will try to check if there's a better way to hide them, but
>> I'm not sure.
>
> If not then I guess the original patch should be reverted?

The original patch doesn't do anything, so yes it can be reverted 
(although it doesn't affect configure in any way).

>>>>    # Checks for programs.
>>>>    ac_ext=c
>>>> diff -r 49ce39c88aee -r dfe39bd65137 tools/configure.ac
>>>> --- a/tools/configure.ac	Mon May 14 16:20:33 2012 +0100
>>>> +++ b/tools/configure.ac	Mon May 14 16:22:39 2012 +0100
>>>> @@ -67,10 +67,16 @@ AC_ARG_VAR([CURL], [Path to curl-config
>>>>    AC_ARG_VAR([XML], [Path to xml2-config tool])
>>>>    AC_ARG_VAR([BASH], [Path to bash shell])
>>>>    AC_ARG_VAR([XGETTEXT], [Path to xgetttext tool])
>>>> -AC_ARG_VAR([AS86], [Path to as86 tool])
>>>> -AC_ARG_VAR([LD86], [Path to ld86 tool])
>>>> -AC_ARG_VAR([BCC], [Path to bcc tool])
>>>> -AC_ARG_VAR([IASL], [Path to iasl tool])
>>>> +
>>>> +dnl as86, ld86, bcc and iasl are only present in x86* systems
>>>> +case "$host_cpu" in
>>>> +i[[3456]]86|x86_64)
>>>> +    AC_ARG_VAR([AS86], [Path to as86 tool])
>>>> +    AC_ARG_VAR([LD86], [Path to ld86 tool])
>>>> +    AC_ARG_VAR([BCC], [Path to bcc tool])
>>>> +    AC_ARG_VAR([IASL], [Path to iasl tool])
>>>> +    ;;
>>>> +esac
>>>>
>>>>    # Checks for programs.
>>>>    AC_PROG_CC
>>>>
>> I don't know why, but I think my previous patch missed to also make the
>> actual check conditional, so the applied patch was useless. This should
>> fix it:
>>
>> 8<----------------------------------------------------------
>>
>> autoconf: disable dev86 and iasl checks on arm
>>
>> Run autogen after applying this patch.
>>
>> Signed-off-by: Roger Pau Monne<roger.pau@citrix.com>
>
> Looks good to me
> Acked-by: Ian Campbell<ian.campbell@citrix.com>

Any news on this one? It's been quite some time since the Ack, but I 
don't think it has been committed (or at least I cannot find it).

Thanks!

>> ---
>>    tools/configure.ac |   13 +++++++++----
>>    1 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/configure.ac b/tools/configure.ac
>> index 706ee13..f7aa9b8 100644
>> --- a/tools/configure.ac
>> +++ b/tools/configure.ac
>> @@ -109,10 +109,15 @@ AS_IF([test "x$pythontools" = "xy"], [
>>        AX_CHECK_PYTHON_DEVEL()
>>    ])
>>    AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
>> -AX_PATH_PROG_OR_FAIL([AS86], [as86])
>> -AX_PATH_PROG_OR_FAIL([LD86], [ld86])
>> -AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>> -AX_PATH_PROG_OR_FAIL([IASL], [iasl])
>> +dnl as86, ld86, bcc and iasl are only present in x86* systems
>> +case "$host_cpu" in
>> +i[[3456]]86|x86_64)
>> +    AX_PATH_PROG_OR_FAIL([AS86], [as86])
>> +    AX_PATH_PROG_OR_FAIL([LD86], [ld86])
>> +    AX_PATH_PROG_OR_FAIL([BCC], [bcc])
>> +    AX_PATH_PROG_OR_FAIL([IASL], [iasl])
>> +    ;;
>> +esac
>>    AX_CHECK_UUID
>>    AX_CHECK_CURSES
>>    PKG_CHECK_MODULES(glib, glib-2.0)
>> --
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10: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 1SgYss-0006Bj-RJ; Mon, 18 Jun 2012 10:08:34 +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 1SgYsr-0006Be-H3
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:08:33 +0000
Received: from [85.158.143.99:13133] by server-2.bemta-4.messagelabs.com id
	80/75-17938-02EFEDF4; Mon, 18 Jun 2012 10:08:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340014112!20147711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25271 invoked from network); 18 Jun 2012 10:08:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 10:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13073417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 10:08:31 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 11:08:31 +0100
Message-ID: <4FDEFE1E.20005@citrix.com>
Date: Mon, 18 Jun 2012 11:08:30 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
	<20434.6327.981198.867739@mariner.uk.xensource.com>
In-Reply-To: <20434.6327.981198.867739@mariner.uk.xensource.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>> the lack of the header files gntalloc.h.
>
>>    Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>
> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>

I'm not sure this has been committed, could you please check it Ian?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10: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 1SgYss-0006Bj-RJ; Mon, 18 Jun 2012 10:08:34 +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 1SgYsr-0006Be-H3
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:08:33 +0000
Received: from [85.158.143.99:13133] by server-2.bemta-4.messagelabs.com id
	80/75-17938-02EFEDF4; Mon, 18 Jun 2012 10:08:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340014112!20147711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25271 invoked from network); 18 Jun 2012 10:08:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 10:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13073417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 10:08:31 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 11:08:31 +0100
Message-ID: <4FDEFE1E.20005@citrix.com>
Date: Mon, 18 Jun 2012 11:08:30 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
	<20434.6327.981198.867739@mariner.uk.xensource.com>
In-Reply-To: <20434.6327.981198.867739@mariner.uk.xensource.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>> the lack of the header files gntalloc.h.
>
>>    Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>
> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>

I'm not sure this has been committed, could you please check it Ian?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgZLX-0007Dk-UZ; Mon, 18 Jun 2012 10:38:11 +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 1SgZLX-0007Dd-82
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:38:11 +0000
Received: from [85.158.139.83:6758] by server-10.bemta-5.messagelabs.com id
	27/AE-02190-2150FDF4; Mon, 18 Jun 2012 10:38:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340015880!28226050!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7804 invoked from network); 18 Jun 2012 10:38:01 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 10:38:01 -0000
Received: by ggnp1 with SMTP id p1so4022553ggn.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 03:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=pxn7HkozJkYLgvRdppwy7/mNdAMSSzlcsfrvykzGg1s=;
	b=ej8ZxDwAD9yrNKoQTz/ZddHyndYfSNuKy1B8HSYp5zc2YbaO4/4EUd3aSkCo5It8ur
	ZogoYZb4OOeQYZL0i6RlyZC90ApGco+qfKUjCsF1CBI9Glwm5KdCvbDaT6/Tlx/0Ugu6
	ENeWo2HAM46OFbavinHrsX1vrjG99zgwwJfK0W+N/LxFFpAmZKhw8or+wMukOmcB9qNf
	SrleLO6UvOVWc9BRxXFCJUThQbsTRjuLL2+j4NkdvAWfD4YIqZsnjzNVNsjsQjs1/yg5
	VKA2pxF3FBt1oLT4W5Z0rj/e3t0VgKCv8S0gCFSThJBxZCarIulQOV3lsjm/n4rFFVsT
	kKoQ==
MIME-Version: 1.0
Received: by 10.60.27.6 with SMTP id p6mr15043553oeg.37.1340015880137; Mon, 18
	Jun 2012 03:38:00 -0700 (PDT)
Received: by 10.182.176.36 with HTTP; Mon, 18 Jun 2012 03:38:00 -0700 (PDT)
In-Reply-To: <1340012319.13742.114.camel@sergey>
References: <1340012319.13742.114.camel@sergey>
Date: Mon, 18 Jun 2012 11:38:00 +0100
X-Google-Sender-Auth: fPFCsfY8xBFVa7DXzV4tkugh6GY
Message-ID: <CAFLBxZZ-+GOAfDpU817B5wH8yAgcrAgGT8a64GnBs-uRb_jSbw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Sergey Zhukov <svg@ngs.ru>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Forking time 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="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, Jun 18, 2012 at 10:38 AM, Sergey Zhukov <svg@ngs.ru> wrote:
> Hi,
>
> I repost this message from xen-users list following by others
> subscribers suggestions:
>
>
> I found an article about forking time for redis NoSQL database in
> different systems:
>
> http://redis.io/topics/latency
> ---------Quote------------------
> Fork time in different systems
> Modern hardware is pretty fast to copy the page table, but Xen is not.
> The problem with Xen is not virtualization-specific, but Xen-specific.
> For instance using VMware or Virutal Box does not result into slow fork
> time. The following is a table that compares fork time for different
> Redis instance size. Data is obtained performing a BGSAVE and looking at
> the latest_fork_usec filed in the INFO command output.
>
> =A0 =A0 =A0* Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
> =A0 =A0 =A0 =A0(12.8 milliseconds per GB).
> =A0 =A0 =A0* Linux running on physical machine (Unknown HW) 6.1GB RSS for=
ked
> =A0 =A0 =A0 =A0in 80 milliseconds (13.1 milliseconds per GB)
> =A0 =A0 =A0* Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
> =A0 =A0 =A0 =A0forked into 62 millisecodns (9 milliseconds per GB).
> =A0 =A0 =A0* Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
> =A0 =A0 =A0 =A0(23.3 millisecond per GB).
> =A0 =A0 =A0* Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
> =A0 =A0 =A0 =A0(239.3 milliseconds per GB).
> =A0 =A0 =A0* Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecod=
ns
> =A0 =A0 =A0 =A0(424 milliseconds per GB).
>
> As you can see a VM running on Xen has a performance hit that is between
> one order to two orders of magnitude. We believe this is a severe
> problem with Xen and we hope it will be addressed ASAP.
> ----------End of quote-----------------
>
> I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
> test was performed on Intel Core I5 2500 processor unit. Forking time
> was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
> EC2/Linode were mentioned in the article, but still much slower then
> VMWare or physical machines. Has anyone running with this issue? Or may
> be there is a way to tune Xen for less forking times?

[Sorry -- didn't see the post on this list before I responded to your
mail on xen-users.]

Which version of the kernel are you using for Xen?  And is it a pvops
kernel or a "classic xen" kernel?

Also, have you tried running Linux in HVM mode?

The original "classic Xen" kernel had a lot of performance tuning done
to it.  But the focus of pvops development for years has just been
*getting the necessary support into the kernel*, so these kinds of
microbenchmark performance things have suffered just because no one
has been looking at it.  We've got engineers looking more closely at
this now, so it's good to know what areas we need to look at.

If you use HVM mode, you'll most likely be using the same exact
codepaths that KVM will be using (hardware pagetable virtualization),
and so will hopefully get the same speed.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgZLX-0007Dk-UZ; Mon, 18 Jun 2012 10:38:11 +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 1SgZLX-0007Dd-82
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:38:11 +0000
Received: from [85.158.139.83:6758] by server-10.bemta-5.messagelabs.com id
	27/AE-02190-2150FDF4; Mon, 18 Jun 2012 10:38:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340015880!28226050!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7804 invoked from network); 18 Jun 2012 10:38:01 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 10:38:01 -0000
Received: by ggnp1 with SMTP id p1so4022553ggn.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 03:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=pxn7HkozJkYLgvRdppwy7/mNdAMSSzlcsfrvykzGg1s=;
	b=ej8ZxDwAD9yrNKoQTz/ZddHyndYfSNuKy1B8HSYp5zc2YbaO4/4EUd3aSkCo5It8ur
	ZogoYZb4OOeQYZL0i6RlyZC90ApGco+qfKUjCsF1CBI9Glwm5KdCvbDaT6/Tlx/0Ugu6
	ENeWo2HAM46OFbavinHrsX1vrjG99zgwwJfK0W+N/LxFFpAmZKhw8or+wMukOmcB9qNf
	SrleLO6UvOVWc9BRxXFCJUThQbsTRjuLL2+j4NkdvAWfD4YIqZsnjzNVNsjsQjs1/yg5
	VKA2pxF3FBt1oLT4W5Z0rj/e3t0VgKCv8S0gCFSThJBxZCarIulQOV3lsjm/n4rFFVsT
	kKoQ==
MIME-Version: 1.0
Received: by 10.60.27.6 with SMTP id p6mr15043553oeg.37.1340015880137; Mon, 18
	Jun 2012 03:38:00 -0700 (PDT)
Received: by 10.182.176.36 with HTTP; Mon, 18 Jun 2012 03:38:00 -0700 (PDT)
In-Reply-To: <1340012319.13742.114.camel@sergey>
References: <1340012319.13742.114.camel@sergey>
Date: Mon, 18 Jun 2012 11:38:00 +0100
X-Google-Sender-Auth: fPFCsfY8xBFVa7DXzV4tkugh6GY
Message-ID: <CAFLBxZZ-+GOAfDpU817B5wH8yAgcrAgGT8a64GnBs-uRb_jSbw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Sergey Zhukov <svg@ngs.ru>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Forking time 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="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, Jun 18, 2012 at 10:38 AM, Sergey Zhukov <svg@ngs.ru> wrote:
> Hi,
>
> I repost this message from xen-users list following by others
> subscribers suggestions:
>
>
> I found an article about forking time for redis NoSQL database in
> different systems:
>
> http://redis.io/topics/latency
> ---------Quote------------------
> Fork time in different systems
> Modern hardware is pretty fast to copy the page table, but Xen is not.
> The problem with Xen is not virtualization-specific, but Xen-specific.
> For instance using VMware or Virutal Box does not result into slow fork
> time. The following is a table that compares fork time for different
> Redis instance size. Data is obtained performing a BGSAVE and looking at
> the latest_fork_usec filed in the INFO command output.
>
> =A0 =A0 =A0* Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
> =A0 =A0 =A0 =A0(12.8 milliseconds per GB).
> =A0 =A0 =A0* Linux running on physical machine (Unknown HW) 6.1GB RSS for=
ked
> =A0 =A0 =A0 =A0in 80 milliseconds (13.1 milliseconds per GB)
> =A0 =A0 =A0* Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
> =A0 =A0 =A0 =A0forked into 62 millisecodns (9 milliseconds per GB).
> =A0 =A0 =A0* Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
> =A0 =A0 =A0 =A0(23.3 millisecond per GB).
> =A0 =A0 =A0* Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
> =A0 =A0 =A0 =A0(239.3 milliseconds per GB).
> =A0 =A0 =A0* Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecod=
ns
> =A0 =A0 =A0 =A0(424 milliseconds per GB).
>
> As you can see a VM running on Xen has a performance hit that is between
> one order to two orders of magnitude. We believe this is a severe
> problem with Xen and we hope it will be addressed ASAP.
> ----------End of quote-----------------
>
> I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
> test was performed on Intel Core I5 2500 processor unit. Forking time
> was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
> EC2/Linode were mentioned in the article, but still much slower then
> VMWare or physical machines. Has anyone running with this issue? Or may
> be there is a way to tune Xen for less forking times?

[Sorry -- didn't see the post on this list before I responded to your
mail on xen-users.]

Which version of the kernel are you using for Xen?  And is it a pvops
kernel or a "classic xen" kernel?

Also, have you tried running Linux in HVM mode?

The original "classic Xen" kernel had a lot of performance tuning done
to it.  But the focus of pvops development for years has just been
*getting the necessary support into the kernel*, so these kinds of
microbenchmark performance things have suffered just because no one
has been looking at it.  We've got engineers looking more closely at
this now, so it's good to know what areas we need to look at.

If you use HVM mode, you'll most likely be using the same exact
codepaths that KVM will be using (hardware pagetable virtualization),
and so will hopefully get the same speed.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10: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 1SgZLr-0007FY-GT; Mon, 18 Jun 2012 10:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SgZLq-0007FN-Jg
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:38:30 +0000
Received: from [85.158.143.99:34144] by server-1.bemta-4.messagelabs.com id
	7E/67-24392-5250FDF4; Mon, 18 Jun 2012 10:38:29 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340015908!27831303!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28444 invoked from network); 18 Jun 2012 10:38:29 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jun 2012 10:38:29 -0000
Received: from mail75-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id
	14.1.225.23; Mon, 18 Jun 2012 10:37:09 +0000
Received: from mail75-tx2 (localhost [127.0.0.1])	by mail75-tx2-R.bigfish.com
	(Postfix) with ESMTP id B5E953C00DE;
	Mon, 18 Jun 2012 10:37:09 +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: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2
	(MessageSwitch) id 1340015828470406_27560;
	Mon, 18 Jun 2012 10:37:08 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.240])	by
	mail75-tx2.bigfish.com (Postfix) with ESMTP id 7008418004E;
	Mon, 18 Jun 2012 10:37:08 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Mon, 18 Jun 2012 10:37:07 +0000
X-WSS-ID: 0M5T6VX-02-7IN-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 2A629C80FF;	Mon, 18 Jun 2012 05:38:20 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 18 Jun 2012 05:38:26 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Mon, 18 Jun 2012 05:38:20 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 18 Jun 2012
	06:38:20 -0400
Message-ID: <4FDF051A.1000300@amd.com>
Date: Mon, 18 Jun 2012 12:38:18 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
	<20434.6327.981198.867739@mariner.uk.xensource.com>
	<4FDEFE1E.20005@citrix.com>
In-Reply-To: <4FDEFE1E.20005@citrix.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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

On 06/18/12 12:08, Roger Pau Monne wrote:

> Ian Jackson wrote:
>> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools:
>> disable libvchan build on NetBSD"):
>>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>>> the lack of the header files gntalloc.h.
>>
>>>    Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
> 
> I'm not sure this has been committed, could you please check it Ian?


It has. See c/s 25472:1e4561d216db.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10: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 1SgZLr-0007FY-GT; Mon, 18 Jun 2012 10:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SgZLq-0007FN-Jg
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:38:30 +0000
Received: from [85.158.143.99:34144] by server-1.bemta-4.messagelabs.com id
	7E/67-24392-5250FDF4; Mon, 18 Jun 2012 10:38:29 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340015908!27831303!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28444 invoked from network); 18 Jun 2012 10:38:29 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jun 2012 10:38:29 -0000
Received: from mail75-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id
	14.1.225.23; Mon, 18 Jun 2012 10:37:09 +0000
Received: from mail75-tx2 (localhost [127.0.0.1])	by mail75-tx2-R.bigfish.com
	(Postfix) with ESMTP id B5E953C00DE;
	Mon, 18 Jun 2012 10:37:09 +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: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2
	(MessageSwitch) id 1340015828470406_27560;
	Mon, 18 Jun 2012 10:37:08 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.240])	by
	mail75-tx2.bigfish.com (Postfix) with ESMTP id 7008418004E;
	Mon, 18 Jun 2012 10:37:08 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Mon, 18 Jun 2012 10:37:07 +0000
X-WSS-ID: 0M5T6VX-02-7IN-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 2A629C80FF;	Mon, 18 Jun 2012 05:38:20 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 18 Jun 2012 05:38:26 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Mon, 18 Jun 2012 05:38:20 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 18 Jun 2012
	06:38:20 -0400
Message-ID: <4FDF051A.1000300@amd.com>
Date: Mon, 18 Jun 2012 12:38:18 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
	<20434.6327.981198.867739@mariner.uk.xensource.com>
	<4FDEFE1E.20005@citrix.com>
In-Reply-To: <4FDEFE1E.20005@citrix.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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

On 06/18/12 12:08, Roger Pau Monne wrote:

> Ian Jackson wrote:
>> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools:
>> disable libvchan build on NetBSD"):
>>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>>> the lack of the header files gntalloc.h.
>>
>>>    Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
> 
> I'm not sure this has been committed, could you please check it Ian?


It has. See c/s 25472:1e4561d216db.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:46:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10: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 1SgZTd-0007fD-F1; Mon, 18 Jun 2012 10:46: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 1SgZTb-0007f8-RR
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:46:31 +0000
Received: from [85.158.139.83:36643] by server-8.bemta-5.messagelabs.com id
	F1/C8-10278-6070FDF4; Mon, 18 Jun 2012 10:46:30 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340016390!20852441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23618 invoked from network); 18 Jun 2012 10:46:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 10:46:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13074538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 10:46:30 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 11:46:30 +0100
Message-ID: <4FDF0705.2050901@citrix.com>
Date: Mon, 18 Jun 2012 11:46:29 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
	<20434.6327.981198.867739@mariner.uk.xensource.com>
	<4FDEFE1E.20005@citrix.com>
In-Reply-To: <4FDEFE1E.20005@citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
> Ian Jackson wrote:
>> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
>>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>>> the lack of the header files gntalloc.h.
>>>     Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
>
> I'm not sure this has been committed, could you please check it Ian?

Sorry for the fuss, I've found this one on staging.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 10:46:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 10: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 1SgZTd-0007fD-F1; Mon, 18 Jun 2012 10:46: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 1SgZTb-0007f8-RR
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 10:46:31 +0000
Received: from [85.158.139.83:36643] by server-8.bemta-5.messagelabs.com id
	F1/C8-10278-6070FDF4; Mon, 18 Jun 2012 10:46:30 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340016390!20852441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23618 invoked from network); 18 Jun 2012 10:46:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 10:46:30 -0000
X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="13074538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 10:46:30 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 11:46:30 +0100
Message-ID: <4FDF0705.2050901@citrix.com>
Date: Mon, 18 Jun 2012 11:46:29 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-3-git-send-email-roger.pau@citrix.com>
	<4FB3C94A.2030603@amd.com>
	<20434.6327.981198.867739@mariner.uk.xensource.com>
	<4FDEFE1E.20005@citrix.com>
In-Reply-To: <4FDEFE1E.20005@citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
> Ian Jackson wrote:
>> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
>>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>>> the lack of the header files gntalloc.h.
>>>     Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
>
> I'm not sure this has been committed, could you please check it Ian?

Sorry for the fuss, I've found this one on staging.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 11:27:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 11:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sga79-0008Kb-Il; Mon, 18 Jun 2012 11:27:23 +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 1SfbzF-00009y-7i
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 19:15:14 +0000
Received: from [85.158.143.99:10971] by server-2.bemta-4.messagelabs.com id
	57/1F-17938-0C98BDF4; Fri, 15 Jun 2012 19:15:12 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339787708!27616580!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MzA5OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6130 invoked from network); 15 Jun 2012 19:15:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 19:15:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5FJF197022081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 19:15:02 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
	q5FJExqd002705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Jun 2012 19:15: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
	q5FJExUs028435; Fri, 15 Jun 2012 14:14:59 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Jun 2012 12:14:58 -0700
Date: Fri, 15 Jun 2012 12:14:56 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120615121456.3f0089ad@mantra.us.oracle.com>
In-Reply-To: <20120615155844.GB20422@phenom.dumpdata.com>
References: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
	<20120615155844.GB20422@phenom.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
Content-Type: multipart/mixed; boundary="MP_/c2HycnF26WhVANwYZbmqoQR"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Mon, 18 Jun 2012 11:27:21 +0000
Cc: xen-devel@lists.xensource.com, ml@consolo.de
Subject: Re: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/c2HycnF26WhVANwYZbmqoQR
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Fri, 15 Jun 2012 11:58:44 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Jun 14, 2012 at 03:11:48PM +0200, ml@consolo.de wrote:
> > 
> > Hi,
> > 
> > I am currently trying to get kdb working with the current 4.1 XEN
> > release. I first tried to use debuggers.hg, but could not manage to
> > compile it due tho many different errors.
> 
> Did you email the author (Mukesh) of debuggers.hg to see if he can
> help?
> 

I just posted a patch for unstable c/s 25467 last week. Attached here
again.

thanks,
Mukesh




--MP_/c2HycnF26WhVANwYZbmqoQR
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=kdb.patch

diff -r 32034d1914a6 xen/Makefile
--- a/xen/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -61,6 +61,7 @@ _clean: delete-unfresh-files
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C kdb clean
 	rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET)-syms *~ core
 	rm -f include/asm-*/asm-offsets.h
 	[ -d tools/figlet ] && rm -f .banner*
@@ -129,7 +130,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h
 	  echo ""; \
 	  echo "#endif") <$< >$@
 
-SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers
+SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers kdb
 define all_sources
     ( find include/asm-$(TARGET_ARCH) -name '*.h' -print; \
       find include -name 'asm-*' -prune -o -name '*.h' -print; \
diff -r 32034d1914a6 xen/Rules.mk
--- a/xen/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Rules.mk	Fri Jun 15 12:13:29 2012 -0700
@@ -10,6 +10,7 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto           ?= n
+kdb           ?= n
 
 include $(XEN_ROOT)/Config.mk
 
@@ -40,6 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/d
 ALL_OBJS-y               += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(kdb)          += $(BASEDIR)/kdb/built_in.o
 
 CFLAGS-y                += -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
@@ -53,6 +55,7 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFIL
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(kdb)           += -DXEN_KDB_CONFIG
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y                += -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff -r 32034d1914a6 xen/arch/x86/hvm/svm/entry.S
--- a/xen/arch/x86/hvm/svm/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -59,12 +59,23 @@ ENTRY(svm_asm_do_resume)
         get_current(bx)
         CLGI
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         testl $~0,(r(dx),r(ax),1)
         jnz  .Lsvm_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0, VCPU_nsvm_hap_enabled(r(bx))
 UNLIKELY_START(nz, nsvm_hap)
         mov  VCPU_nhvm_p2m(r(bx)),r(ax)
diff -r 32034d1914a6 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2170,6 +2170,10 @@ void svm_vmexit_handler(struct cpu_user_
         break;
 
     case VMEXIT_EXCEPTION_DB:
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+	    break;
+#endif
         if ( !v->domain->debugger_attached )
             goto exit_and_crash;
         domain_pause_for_debugger();
@@ -2182,6 +2186,10 @@ void svm_vmexit_handler(struct cpu_user_
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
         __update_guest_eip(regs, inst_len);
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_int3, regs))
+            break;
+#endif
         current->arch.gdbsx_vcpu_event = TRAP_int3;
         domain_pause_for_debugger();
         break;
diff -r 32034d1914a6 xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Fri Jun 15 12:13:29 2012 -0700
@@ -315,6 +315,36 @@ void setup_vmcb_dump(void)
     register_keyhandler('v', &vmcb_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+/* did == 0 : display for all HVM domains. domid 0 is never HVM.
+ *  * vid == -1 : display for all HVM VCPUs
+ *   */
+void kdb_dump_vmcb(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain (dp) {
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+            kdbp("  VMCB [domid: %d  vcpu:%d]:\n", dp->domain_id, vp->vcpu_id);
+            svm_vmcb_dump("kdb", vp->arch.hvm_svm.vmcb);
+            kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    rcu_read_unlock(&domlist_read_lock);
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 xen/arch/x86/hvm/vmx/entry.S
--- a/xen/arch/x86/hvm/vmx/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -124,12 +124,23 @@ vmx_asm_do_vmentry:
         get_current(bx)
         cli
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         cmpl $0,(r(dx),r(ax),1)
         jnz  .Lvmx_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0xff,VCPU_vmx_emulate(r(bx))
         jnz .Lvmx_goto_emulator
         testb $0xff,VCPU_vmx_realmode(r(bx))
diff -r 32034d1914a6 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Fri Jun 15 12:13:29 2012 -0700
@@ -1117,6 +1117,13 @@ void vmx_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
+#if defined(XEN_KDB_CONFIG)
+    if (kdb_dr7)
+        __vmwrite(GUEST_DR7, kdb_dr7);
+    else
+        __vmwrite(GUEST_DR7, 0);
+#endif
+
     debug_state = v->domain->debugger_attached
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_INT3]
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP];
@@ -1326,6 +1333,220 @@ void setup_vmcs_dump(void)
     register_keyhandler('v', &vmcs_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+#define GUEST_EFER      0x2806   /* see page 23-20 */
+#define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+
+/* it's a shame we can't use vmcs_dump_vcpu(), but it does vmx_vmcs_enter which
+ * will IPI other CPUs. also, print a subset relevant to software debugging */
+static void noinline kdb_print_vmcs(struct vcpu *vp)
+{
+    struct cpu_user_regs *regs = &vp->arch.user_regs;
+    unsigned long long x;
+
+    kdbp("*** Guest State ***\n");
+    kdbp("CR0: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR0),
+         (unsigned long long)vmr(CR0_READ_SHADOW), 
+         (unsigned long long)vmr(CR0_GUEST_HOST_MASK));
+    kdbp("CR4: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR4),
+         (unsigned long long)vmr(CR4_READ_SHADOW), 
+         (unsigned long long)vmr(CR4_GUEST_HOST_MASK));
+    kdbp("CR3: actual=0x%016llx, target_count=%d\n",
+         (unsigned long long)vmr(GUEST_CR3),
+         (int)vmr(CR3_TARGET_COUNT));
+    kdbp("     target0=%016llx, target1=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE0),
+         (unsigned long long)vmr(CR3_TARGET_VALUE1));
+    kdbp("     target2=%016llx, target3=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE2),
+         (unsigned long long)vmr(CR3_TARGET_VALUE3));
+    kdbp("RSP = 0x%016llx (0x%016llx)  RIP = 0x%016llx (0x%016llx)\n", 
+         (unsigned long long)vmr(GUEST_RSP),
+         (unsigned long long)regs->esp,
+         (unsigned long long)vmr(GUEST_RIP),
+         (unsigned long long)regs->eip);
+    kdbp("RFLAGS=0x%016llx (0x%016llx)  DR7 = 0x%016llx\n", 
+         (unsigned long long)vmr(GUEST_RFLAGS),
+         (unsigned long long)regs->eflags,
+         (unsigned long long)vmr(GUEST_DR7));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+         (unsigned long long)vmr(GUEST_SYSENTER_ESP),
+         (int)vmr(GUEST_SYSENTER_CS),
+         (unsigned long long)vmr(GUEST_SYSENTER_EIP));
+    vmx_dump_sel("CS", GUEST_CS_SELECTOR);
+    vmx_dump_sel("DS", GUEST_DS_SELECTOR);
+    vmx_dump_sel("SS", GUEST_SS_SELECTOR);
+    vmx_dump_sel("ES", GUEST_ES_SELECTOR);
+    vmx_dump_sel("FS", GUEST_FS_SELECTOR);
+    vmx_dump_sel("GS", GUEST_GS_SELECTOR);
+    vmx_dump_sel2("GDTR", GUEST_GDTR_LIMIT);
+    vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
+    vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
+    vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
+    kdbp("Guest PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
+    x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
+    x |= (uint32_t)vmr(TSC_OFFSET);
+    kdbp("TSC Offset = %016llx\n", x);
+    x  = (unsigned long long)vmr(GUEST_IA32_DEBUGCTL_HIGH) << 32;
+    x |= (uint32_t)vmr(GUEST_IA32_DEBUGCTL);
+    kdbp("DebugCtl=%016llx DebugExceptions=%016llx\n", x,
+           (unsigned long long)vmr(GUEST_PENDING_DBG_EXCEPTIONS));
+    kdbp("Interruptibility=%04x ActivityState=%04x\n",
+           (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
+           (int)vmr(GUEST_ACTIVITY_STATE));
+
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
+    kdbp("\n*** Host State ***\n");
+    kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
+           (unsigned long long)vmr(HOST_RSP),
+           (unsigned long long)vmr(HOST_RIP));
+    kdbp("CS=%04x DS=%04x ES=%04x FS=%04x GS=%04x SS=%04x TR=%04x\n",
+           (uint16_t)vmr(HOST_CS_SELECTOR),
+           (uint16_t)vmr(HOST_DS_SELECTOR),
+           (uint16_t)vmr(HOST_ES_SELECTOR),
+           (uint16_t)vmr(HOST_FS_SELECTOR),
+           (uint16_t)vmr(HOST_GS_SELECTOR),
+           (uint16_t)vmr(HOST_SS_SELECTOR),
+           (uint16_t)vmr(HOST_TR_SELECTOR));
+    kdbp("FSBase=%016llx GSBase=%016llx TRBase=%016llx\n",
+           (unsigned long long)vmr(HOST_FS_BASE),
+           (unsigned long long)vmr(HOST_GS_BASE),
+           (unsigned long long)vmr(HOST_TR_BASE));
+    kdbp("GDTBase=%016llx IDTBase=%016llx\n",
+           (unsigned long long)vmr(HOST_GDTR_BASE),
+           (unsigned long long)vmr(HOST_IDTR_BASE));
+    kdbp("CR0=%016llx CR3=%016llx CR4=%016llx\n",
+           (unsigned long long)vmr(HOST_CR0),
+           (unsigned long long)vmr(HOST_CR3),
+           (unsigned long long)vmr(HOST_CR4));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+           (unsigned long long)vmr(HOST_SYSENTER_ESP),
+           (int)vmr(HOST_SYSENTER_CS),
+           (unsigned long long)vmr(HOST_SYSENTER_EIP));
+    kdbp("Host PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(HOST_PAT_HIGH), (uint32_t)vmr(HOST_PAT));
+
+    kdbp("\n*** Control State ***\n");
+    kdbp("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n",
+           (uint32_t)vmr(PIN_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(CPU_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(SECONDARY_VM_EXEC_CONTROL));
+    kdbp("EntryControls=%08x ExitControls=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_CONTROLS),
+           (uint32_t)vmr(VM_EXIT_CONTROLS));
+    kdbp("ExceptionBitmap=%08x\n",
+           (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
+    kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_INTR_INFO),
+           (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("VMExit: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_EXIT_INTR_INFO),
+           (uint32_t)vmr(VM_EXIT_INTR_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("        reason=%08x qualification=%08x\n",
+           (uint32_t)vmr(VM_EXIT_REASON),
+           (uint32_t)vmr(EXIT_QUALIFICATION));
+    kdbp("IDTVectoring: info=%08x errcode=%08x\n",
+           (uint32_t)vmr(IDT_VECTORING_INFO),
+           (uint32_t)vmr(IDT_VECTORING_ERROR_CODE));
+    kdbp("TPR Threshold = 0x%02x\n",
+           (uint32_t)vmr(TPR_THRESHOLD));
+    kdbp("EPT pointer = 0x%08x%08x\n",
+           (uint32_t)vmr(EPT_POINTER_HIGH), (uint32_t)vmr(EPT_POINTER));
+    kdbp("Virtual processor ID = 0x%04x\n",
+           (uint32_t)vmr(VIRTUAL_PROCESSOR_ID));
+    kdbp("=================================================================\n");
+}
+
+/* Flush VMCS on this cpu if it needs to: 
+ *   - Upon leaving kdb, the HVM cpu will resume in vmx_vmexit_handler() and 
+ *     do __vmreads. So, the VMCS pointer can't be left cleared.
+ *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
+ *     vmlaunch must be done and not vmresume. This means, we must clear 
+ *     arch_vmx->launched.
+ */
+void kdb_curr_cpu_flush_vmcs(void)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    int ccpu = smp_processor_id();
+    struct vmcs_struct *cvp = this_cpu(current_vmcs);
+
+    if (this_cpu(current_vmcs) == NULL)
+        return;             /* no HVM active on this CPU */
+
+    kdbp("KDB:[%d] curvmcs:%lx/%lx\n", ccpu, cvp, virt_to_maddr(cvp));
+
+    /* looks like we got one. unfortunately, current_vmcs points to vmcs 
+     * and not VCPU, so we gotta search the entire list... */
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        for_each_vcpu (dp, vp) {
+            if ( vp->arch.hvm_vmx.vmcs == cvp ) {
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched = 0;
+                this_cpu(current_vmcs) = NULL;
+                kdbp("KDB:[%d] %d:%d current_vmcs:%lx flushed\n", 
+		     ccpu, dp->domain_id, vp->vcpu_id, cvp, virt_to_maddr(cvp));
+            }
+        }
+    }
+}
+
+/*
+ * domid == 0 : display for all HVM domains  (dom0 is never an HVM domain)
+ * vcpu id == -1 : display all vcpuids
+ * PreCondition: all HVM cpus (including current cpu) have flushed VMCS
+ */
+void kdb_dump_vmcs(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    struct vmcs_struct  *vmcsp;
+    u64 addr = -1;
+
+    ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
+    __vmptrst(&addr);
+
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+	    vmcsp = vp->arch.hvm_vmx.vmcs;
+            kdbp("VMCS %lx/%lx [domid:%d (%p)  vcpu:%d (%p)]:\n", vmcsp,
+	         virt_to_maddr(vmcsp), dp->domain_id, dp, vp->vcpu_id, vp);
+            __vmptrld(virt_to_maddr(vmcsp));
+            kdb_print_vmcs(vp);
+            __vmpclear(virt_to_maddr(vmcsp));
+            vp->arch.hvm_vmx.launched = 0;
+        }
+        kdbp("\n");
+    }
+    /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
+    if (addr && addr != (u64)-1)
+        __vmptrld(addr);
+}
+#endif
 
 /*
  * Local variables:
diff -r 32034d1914a6 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2183,11 +2183,14 @@ static void vmx_failed_vmentry(unsigned 
         printk("reason not known yet!");
         break;
     }
-
+#if defined(XEN_KDB_CONFIG)
+    kdbp("\n************* VMCS Area **************\n");
+    kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
-
+#endif
     domain_crash(curr->domain);
 }
 
@@ -2415,6 +2418,12 @@ void vmx_vmexit_handler(struct cpu_user_
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
+
+#if defined(XEN_KDB_CONFIG)
+            /* TRAP_debug: IP points correctly to next instr */
+            if (kdb_handle_trap_entry(vector, regs))
+                break;
+#endif
             domain_pause_for_debugger();
             break;
         case TRAP_int3: 
@@ -2423,6 +2432,13 @@ void vmx_vmexit_handler(struct cpu_user_
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
+#if defined(XEN_KDB_CONFIG)
+                /* vmcs.IP points to bp, kdb expects bp+1. Hence after the above
+                 * update_guest_eip which updates to bp+1. works for gdbsx too 
+                 */
+                if (kdb_handle_trap_entry(vector, regs))
+                    break;
+#endif
                 current->arch.gdbsx_vcpu_event = TRAP_int3;
                 domain_pause_for_debugger();
                 break;
@@ -2707,6 +2723,10 @@ void vmx_vmexit_handler(struct cpu_user_
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
+#if defined(XEN_KDB_CONFIG)
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+            break;
+#endif
         if ( v->arch.hvm_vcpu.single_step ) {
           hvm_memory_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
diff -r 32034d1914a6 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/irq.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2305,3 +2305,29 @@ bool_t hvm_domain_use_pirq(const struct 
     return is_hvm_domain(d) && pirq &&
            pirq->arch.hvm.emuirq != IRQ_UNBOUND; 
 }
+
+#ifdef XEN_KDB_CONFIG
+void kdb_prnt_guest_mapped_irqs(void)
+{
+    int irq, j;
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    kdbp("irq  vec  aff  type  domid:mapped-pirq pairs  (all in decimal)\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+        irq_guest_action_t *actp = (irq_guest_action_t *)dp->action;
+
+        if (!dp->handler ||dp->handler==&no_irq_type || !(dp->status&IRQ_GUEST))
+            continue;
+
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %3d %3s %-13s ", irq, archp->vector, affstr,
+             dp->handler->typename);
+        for (j=0; j < actp->nr_guests; j++)
+            kdbp("%03d:%04d ", actp->guest[j]->domain_id,
+                 domain_irq_to_pirq(actp->guest[j], irq));
+        kdbp("\n");
+    }
+}
+#endif
diff -r 32034d1914a6 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/setup.c	Fri Jun 15 12:13:29 2012 -0700
@@ -47,6 +47,13 @@
 #include <xen/cpu.h>
 #include <asm/nmi.h>
 
+#ifdef XEN_KDB_CONFIG
+#include <asm/debugger.h>
+
+int opt_earlykdb=0;
+boolean_param("earlykdb", opt_earlykdb);
+#endif
+
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
 boolean_param("nosmp", opt_nosmp);
@@ -1242,6 +1249,11 @@ void __init __start_xen(unsigned long mb
 
     trap_init();
 
+#ifdef XEN_KDB_CONFIG
+    kdb_init();
+    if (opt_earlykdb)
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+#endif
     rcu_init();
     
     early_time_init();
diff -r 32034d1914a6 xen/arch/x86/smp.c
--- a/xen/arch/x86/smp.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/smp.c	Fri Jun 15 12:13:29 2012 -0700
@@ -273,7 +273,7 @@ void smp_send_event_check_mask(const cpu
  * Structure and data for smp_call_function()/on_selected_cpus().
  */
 
-static void __smp_call_function_interrupt(void);
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs);
 static DEFINE_SPINLOCK(call_lock);
 static struct call_data_struct {
     void (*func) (void *info);
@@ -321,7 +321,7 @@ void on_selected_cpus(
     if ( cpumask_test_cpu(smp_processor_id(), &call_data.selected) )
     {
         local_irq_disable();
-        __smp_call_function_interrupt();
+        __smp_call_function_interrupt(NULL);
         local_irq_enable();
     }
 
@@ -390,7 +390,7 @@ void event_check_interrupt(struct cpu_us
     this_cpu(irq_count)++;
 }
 
-static void __smp_call_function_interrupt(void)
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs)
 {
     void (*func)(void *info) = call_data.func;
     void *info = call_data.info;
@@ -411,6 +411,11 @@ static void __smp_call_function_interrup
     {
         mb();
         cpumask_clear_cpu(cpu, &call_data.selected);
+#ifdef XEN_KDB_CONFIG
+        if (info && !strcmp(info, "XENKDB")) {           /* called from kdb */
+                (*(void (*)(struct cpu_user_regs *, void *))func)(regs, info);
+        } else
+#endif
         (*func)(info);
     }
 
@@ -421,5 +426,5 @@ void call_function_interrupt(struct cpu_
 {
     ack_APIC_irq();
     perfc_incr(ipis);
-    __smp_call_function_interrupt();
+    __smp_call_function_interrupt(regs);
 }
diff -r 32034d1914a6 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/time.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2007,6 +2007,46 @@ static int __init setup_dump_softtsc(voi
 }
 __initcall(setup_dump_softtsc);
 
+#ifdef XEN_KDB_CONFIG
+void kdb_time_resume(int update_domains)
+{
+        s_time_t now;
+        int ccpu = smp_processor_id();
+        struct cpu_time *t = &this_cpu(cpu_time);
+
+        if (!plt_src.read_counter)            /* not initialized for earlykdb */
+                return;
+
+        if (update_domains) {
+                plt_stamp = plt_src.read_counter();
+                platform_timer_stamp = plt_stamp64;
+                platform_time_calibration();
+                do_settime(get_cmos_time(), 0, read_platform_stime());
+        }
+        if (local_irq_is_enabled())
+                kdbp("kdb BUG: enabled in time_resume(). ccpu:%d\n", ccpu);
+
+        rdtscll(t->local_tsc_stamp);
+        now = read_platform_stime();
+        t->stime_master_stamp = now;
+        t->stime_local_stamp  = now;
+
+        update_vcpu_system_time(current);
+
+        if (update_domains)
+                set_timer(&calibration_timer, NOW() + EPOCH);
+}
+
+void kdb_dump_time_pcpu(void)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        kdbp("[%d]: cpu_time: %016lx\n", cpu, &per_cpu(cpu_time, cpu));
+        kdbp("[%d]: cpu_calibration: %016lx\n", cpu, 
+             &per_cpu(cpu_calibration, cpu));
+    }
+}
+#endif
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/traps.c	Fri Jun 15 12:13:29 2012 -0700
@@ -225,7 +225,7 @@ static void show_trace(struct cpu_user_r
 
 #else
 
-static void show_trace(struct cpu_user_regs *regs)
+void show_trace(struct cpu_user_regs *regs)
 {
     unsigned long *frame, next, addr, low, high;
 
@@ -3326,6 +3326,10 @@ void do_nmi(struct cpu_user_regs *regs)
     if ( nmi_callback(regs, cpu) )
         return;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_enabled && kdb_handle_trap_entry(TRAP_nmi, regs))
+        return;
+#endif
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
 
diff -r 32034d1914a6 xen/arch/x86/x86_64/compat/entry.S
--- a/xen/arch/x86/x86_64/compat/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/compat/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -95,6 +95,10 @@ compat_skip_clobber:
 /* %rbx: struct vcpu */
 ENTRY(compat_test_all_events)
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG
+        testl $1, kdb_session_begun(%rip)
+        jnz   compat_restore_all_guest
+#endif
 /*compat_test_softirqs:*/
         movl  VCPU_processor(%rbx),%eax
         shlq  $IRQSTAT_shift,%rax
diff -r 32034d1914a6 xen/arch/x86/x86_64/entry.S
--- a/xen/arch/x86/x86_64/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -184,6 +184,10 @@ skip_clobber:
 /* %rbx: struct vcpu */
 test_all_events:
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG                   /* 64bit dom0 will resume here */
+        testl $1, kdb_session_begun(%rip)
+        jnz   restore_all_guest
+#endif
 /*test_softirqs:*/  
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
@@ -546,6 +550,13 @@ ENTRY(debug)
 
 ENTRY(int3)
         pushq $0
+#ifdef XEN_KDB_CONFIG
+        pushq %rax
+        GET_CPUINFO_FIELD(CPUINFO_processor_id, %rax)
+        movq  (%rax), %rax
+        lock  bts %rax, kdb_cpu_traps(%rip)
+        popq  %rax
+#endif
         movl  $TRAP_int3,4(%rsp)
         jmp   handle_exception
 
diff -r 32034d1914a6 xen/common/domain.c
--- a/xen/common/domain.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/domain.c	Fri Jun 15 12:13:29 2012 -0700
@@ -530,6 +530,14 @@ void domain_shutdown(struct domain *d, u
 {
     struct vcpu *v;
 
+#ifdef XEN_KDB_CONFIG
+    if (reason == SHUTDOWN_crash) {
+        if ( IS_PRIV(d) )
+            kdb_trap_immed(KDB_TRAP_FATAL);
+        else
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+    }
+#endif
     spin_lock(&d->shutdown_lock);
 
     if ( d->shutdown_code == -1 )
@@ -624,7 +632,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* send VIRQ_DEBUGGER to guest only if gdbsx_vcpu_event is not active */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r 32034d1914a6 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/sched_credit.c	Fri Jun 15 12:13:29 2012 -0700
@@ -1475,6 +1475,33 @@ csched_dump_vcpu(struct csched_vcpu *svc
     printk("\n");
 }
 
+#ifdef XEN_KDB_CONFIG
+static void kdb_csched_dump(int cpu)
+{
+    struct csched_pcpu *pcpup = CSCHED_PCPU(cpu);
+    struct vcpu *scurrvp = (CSCHED_VCPU(current))->vcpu;
+    struct list_head *tmp, *runq = RUNQ(cpu);
+
+    kdbp("    csched_pcpu: %p\n", pcpup);
+    kdbp("    curr csched:%p {vcpu:%p id:%d domid:%d}\n", (current)->sched_priv,
+         scurrvp, scurrvp->vcpu_id, scurrvp->domain->domain_id);
+    kdbp("    runq:\n");
+
+    /* next is top of struct, so screw stupid, ugly hard to follow macros */
+    if (offsetof(struct csched_vcpu, runq_elem.next) != 0) {
+        kdbp("next is not first in struct csched_vcpu. please fixme\n");
+        return;        /* otherwise for loop will crash */
+    }
+    for (tmp = runq->next; tmp != runq; tmp = tmp->next) {
+
+        struct csched_vcpu *csp = (struct csched_vcpu *)tmp;
+        struct vcpu *vp = csp->vcpu;
+        kdbp("      csp:%p pri:%02d vcpu: {p:%p id:%d domid:%d}\n", csp,
+             csp->pri, vp, vp->vcpu_id, vp->domain->domain_id);
+    };
+}
+#endif
+
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
@@ -1484,6 +1511,10 @@ csched_dump_pcpu(const struct scheduler 
     int loop;
 #define cpustr keyhandler_scratch
 
+#ifdef XEN_KDB_CONFIG
+    kdb_csched_dump(cpu);
+    return;
+#endif
     spc = CSCHED_PCPU(cpu);
     runq = &spc->runq;
 
diff -r 32034d1914a6 xen/common/schedule.c
--- a/xen/common/schedule.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/schedule.c	Fri Jun 15 12:13:29 2012 -0700
@@ -1454,6 +1454,25 @@ void wait(void)
     schedule();
 }
 
+#ifdef XEN_KDB_CONFIG
+void kdb_print_sched_info(void)
+{
+    int cpu;
+
+    kdbp("Scheduler: name:%s opt_name:%s id:%d\n", ops.name, ops.opt_name,
+         ops.sched_id);
+    kdbp("per cpu schedule_data:\n");
+    for_each_online_cpu(cpu) {
+        struct schedule_data *p =  &per_cpu(schedule_data, cpu);
+        kdbp("  cpu:%d  &(per cpu)schedule_data:%p\n", cpu, p);
+        kdbp("         curr:%p sched_priv:%p\n", p->curr, p->sched_priv);
+        kdbp("\n");
+        ops.dump_cpu_state(&ops, cpu);
+        kdbp("\n");
+    }
+}
+#endif
+
 #ifdef CONFIG_COMPAT
 #include "compat/schedule.c"
 #endif
diff -r 32034d1914a6 xen/common/symbols.c
--- a/xen/common/symbols.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/symbols.c	Fri Jun 15 12:13:29 2012 -0700
@@ -168,3 +168,21 @@ void __print_symbol(const char *fmt, uns
 
     spin_unlock_irqrestore(&lock, flags);
 }
+
+#ifdef XEN_KDB_CONFIG
+/*
+ *  * Given a symbol, return its address 
+ *   */
+unsigned long address_lookup(char *symp)
+{
+    int i, off = 0;
+    char namebuf[KSYM_NAME_LEN+1];
+
+    for (i=0; i < symbols_num_syms; i++) {
+        off = symbols_expand_symbol(off, namebuf);
+        if (strcmp(namebuf, symp) == 0)                  /* found it */
+            return symbols_address(i);
+    }
+    return 0;
+}
+#endif
diff -r 32034d1914a6 xen/common/timer.c
--- a/xen/common/timer.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/timer.c	Fri Jun 15 12:13:29 2012 -0700
@@ -643,6 +643,48 @@ void __init timer_init(void)
     register_keyhandler('a', &dump_timerq_keyhandler);
 }
 
+#ifdef XEN_KDB_CONFIG
+#include <xen/symbols.h>
+void kdb_dump_timer_queues(void)
+{
+    struct timer  *t;
+    struct timers *ts;
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1];
+    int cpu, j;
+    u64 tsc;
+
+    for_each_online_cpu( cpu )
+    {
+        ts = &per_cpu(timers, cpu);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
+
+        /* timers in the heap */
+        for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
+            t = ts->heap[j];
+            kdbp("  %d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+        /* timers on the link list */
+        for ( t = ts->list, j = 0; t != NULL; t = t->list_next, j++ ) {
+            kdbp(" L%d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+    }
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/char/console.c	Fri Jun 15 12:13:29 2012 -0700
@@ -295,6 +295,21 @@ static void serial_rx(char c, struct cpu
 {
     static int switch_code_count = 0;
 
+#ifdef XEN_KDB_CONFIG
+    /* if ctrl-\ pressed and kdb handles it, return */
+    if (kdb_enabled && c == 0x1c) {
+        if (!kdb_session_begun) {
+            if (kdb_keyboard(regs))
+                return;
+        } else {
+            kdbp("Sorry... kdb session already active.. please try again..\n");
+            return;
+        }
+    }
+    if (kdb_session_begun)      /* kdb should already be polling */
+        return;                 /* swallow chars so they don't buffer in dom0 */
+#endif
+
     if ( switch_code && (c == switch_code) )
     {
         /* We eat CTRL-<switch_char> in groups of 3 to switch console input. */
@@ -710,6 +725,18 @@ void console_end_sync(void)
     atomic_dec(&print_everything);
 }
 
+#ifdef XEN_KDB_CONFIG
+void console_putc(char c)
+{
+    serial_putc(sercon_handle, c);
+}
+
+int console_getc(void)
+{
+    return serial_getc(sercon_handle);
+}
+#endif
+
 /*
  * printk rate limiting, lifted from Linux.
  *
diff -r 32034d1914a6 xen/include/asm-x86/debugger.h
--- a/xen/include/asm-x86/debugger.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/asm-x86/debugger.h	Fri Jun 15 12:13:29 2012 -0700
@@ -39,7 +39,11 @@
 #define DEBUGGER_trap_fatal(_v, _r) \
     if ( debugger_trap_fatal(_v, _r) ) return;
 
-#if defined(CRASH_DEBUG)
+#if defined(XEN_KDB_CONFIG)
+#define debugger_trap_immediate() kdb_trap_immed(KDB_TRAP_NONFATAL)
+#define debugger_trap_fatal(_v, _r) kdb_trap_fatal(_v, _r)
+
+#elif defined(CRASH_DEBUG)
 
 #include <xen/gdbstub.h>
 
@@ -70,6 +74,10 @@ static inline int debugger_trap_entry(
 {
     struct vcpu *v = current;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_handle_trap_entry(vector, regs))
+        return 1;
+#endif
     if ( guest_kernel_mode(v, regs) && v->domain->debugger_attached &&
          ((vector == TRAP_int3) || (vector == TRAP_debug)) )
     {
diff -r 32034d1914a6 xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/lib.h	Fri Jun 15 12:13:29 2012 -0700
@@ -116,4 +116,7 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+#ifdef XEN_KDB_CONFIG
+#include "../../kdb/include/kdb_extern.h"
+#endif
 #endif /* __LIB_H__ */
diff -r 32034d1914a6 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/sched.h	Fri Jun 15 12:13:29 2012 -0700
@@ -576,11 +576,14 @@ extern void (*dead_idle) (void);
 unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
-
+#ifdef XEN_KDB_CONFIG
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
diff -r 32034d1914a6 xen/kdb/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,5 @@
+
+obj-y		+= kdbmain.o kdb_cmds.o kdb_io.o 
+
+subdir-y += x86 guest
+
diff -r 32034d1914a6 xen/kdb/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/README	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,243 @@
+
+Welcome to kdb for xen, a hypervisor built in debugger.
+
+FEATURES:
+   - set breakpoints in hypervisor
+   - examine virt/machine memory, registers, domains, vcpus, etc...
+   - single step, single step till jump/call, step over call to next
+     instruction after the call.
+   - examine memory of a PV/HVM guest. 
+   - set breakpoints, single step, etc... for a PV guest.
+   - breaking into the debugger will freeze the system, all CPUs will pause,
+     no interrupts are acknowledged in the debugger. (Hence, the wall clock
+     will drift)
+   - single step will step only that cpu.
+   - earlykdb: break into kdb very early during boot. Put "earlykdb" on the
+               xen command line in grub.conf.
+   - generic tracing functions (see below) for quick tracing to debug timing
+     related problems. To use:
+        o set KDBTRCMAX to max num of recs in circular trc buffer in kdbmain.c
+	o call kdb_trc() from anywhere in xen
+	o turn tracing on by setting kdb_trcon in kdbmain.c or trcon command.
+	o trcp in kdb will give hints to dump trace recs. Use dd to see buffer
+	o trcz will zero out the entire buffer if needed.
+
+NOTE:
+   - since almost all numbers are in hex, 0x is not prefixed. Instead, decimal
+     numbers are preceded by $, as in $17 (sorry, one gets used to it). Note,
+     vcpu num, cpu num, domid are always displayed in decimal, without $.
+   - watchdog must be disabled to use kdb
+
+ISSUES:
+   - Currently, debug hypervisor is not supported. Make sure NDEBUG is defined
+     or compile with debug=n
+   - "timer went backwards" messages on dom0, but kdb/hyp should be fine.
+     I usually do "echo 2 > /proc/sys/kernel/printk" when using kdb.
+   - 32bit hypervisor may hang. Tested on 64bit hypervisor only.
+    
+
+TO BUILD:
+ - do >make kdb=y
+
+HOW TO USE:
+  1. A serial line is needed to use the debugger. Set up a serial line
+     from the source machine to target victim. Make sure the serial line
+     is working properly by displaying login prompt and loging in etc....
+
+  2. Add following to grub.conf:
+        kernel /xen.kdb console=com1,vga com1=57600,8n1 dom0_mem=542M
+
+        (57600 or whatever used in step 1 above)
+
+  3. Boot the hypervisor built with the debugger. 
+
+  4. ctrl-\ (ctrl and backslash) will break into the debugger. If the system is
+     badly hung, pressing NMI would also break into it. However, once kdb is
+     entered via NMI, normal execution can't continue.
+
+  5. type 'h' for list of commands.
+
+  6. Command line editing is limited to backspace. ctrl-c to start a new cmd.
+
+
+
+GUEST debug:
+  - type sym in the debugger
+  - for REL4, grep kallsyms_names, kallsyms_addresses, and kallsyms_num_syms
+    in the guest System.map* file. Run sym again with domid and the three
+    values on the command line.
+  - Now basic symbols can be used for guest debug. Note, if the binary is not
+    built with symbols, only function names are available, but not global vars.
+
+    Eg: sym 0 c0696084 c068a590 c0696080 c06b43e8 c06b4740
+        will set symbols for dom 0. Then :
+
+        [4]xkdb> bp some_function 0
+
+	wills set bp at some_function in dom 0
+
+	[3]xkdb> dw c068a590 32 0 : display 32 bytes of dom0 memory
+
+
+Tips:
+  - In "[0]xkdb>"  : 0 is the cpu number in decimal
+  - In
+      00000000c042645c: 0:do_timer+17                  push %ebp
+    0:do_timer : 0 is the domid in hex
+    offset +17 is in hex.
+
+    absense of 0: would indicate it's a hypervisor function
+
+  - commands starting with kdb (kdb*) are for kdb debug only.
+
+
+Finally,
+ - think hex.
+ - bug/problem: enter kdbdbg, reproduce, and send me the output.
+   If the output is not enough, I may ask to run kdbdbg twice, then collect
+   output.
+
+
+Thanks,
+Mukesh Rathor
+Oracle Corporatin, 
+Redwood Shores, CA 94065
+
+--------------------------------------------------------------------------------
+COMMAND DESCRIPTION:
+
+info:  Print basic info like version, compile flags, etc..
+
+cur:  print current domain id and vcpu id
+
+f: display current stack. If a vcpu ptr is given, then print stack for that
+   VCPU by using its IP and SP.
+
+fg: display stack for a guest given domid, SP and IP.
+
+dw: display words of memory. 'num' of bytes is optional, but if displaying guest
+    memory, then is required.
+
+dd: same as above, but display doublewords.
+
+dwm: same as above but the address is machine address instead of virtual.
+
+ddm: same as above, but display doublewords.
+
+dr: display registers. if 'sp' is specified then print few extra registers.
+
+drg: display guest context saved on stack bottom.
+
+dis: disassemble instructions. If disassembling for guest, then 'num' must
+     be specified. 'num' is number of instrs to display.
+
+dism: toggle disassembly mode between Intel and ATT/GAS.
+
+mw: modify word in memory given virtual address. 'domid' may be specified if
+    modifying guest memory. value is assumed in hex even without 0x.
+
+md: same as above but modify doubleword.
+
+mr: modify register. value is assumd hex.
+
+bc: clear given or all breakpoints
+
+bp: display breakpoints or set a breakpoint. Domid may be specified to set a bp
+    in guest. kdb functions may not be specified if debugging kdb.
+    Example:
+      xkdb> bp acpi_processor_idle  : will set bp in xen
+      xkdb> bp default_idle 0 :   will set bp in domid 0
+      xkdb> bp idle_cpu 9 :   will set bp in domid 9
+
+     Conditions may be specified for a bp: lhs == rhs or lhs != rhs
+     where : lhs is register like 'r6', 'rax', etc...  or memory location
+             rhs is hex value with or without leading 0x.
+     Thus,
+      xkdb> bp acpi_processor_idle rdi == c000 
+      xkdb> bp 0xffffffff80062ebc 0 rsi == ffff880021edbc98 : will break into
+            kdb at 0xffffffff80062ebc in dom0 when rsi is ffff880021edbc98 
+
+btp: break point trace. Upon bp, print some info and continue without stopping.
+   Ex: btp idle_cpu 7 rax rbx 0x20ef5a5 r9
+
+   will print: rax, rbx, *(long *)0x20ef5a5, r9 upon hitting idle_cpu() and 
+               continue.
+
+wp: set a watchpoint at a virtual address which can belong to hypervisor or
+    any guest. Do not specify wp in kdb path if debugging kdb.
+
+wc: clear given or all watchpoints.
+
+ni: single step, stepping over function calls.
+
+ss: single step. Be carefull when in interrupt handlers or context switches.
+    
+ssb: single step to branch. Use with care.
+
+go: leave kdb and continue.
+
+cpu: go back to orig cpu when entering kdb. If 'cpu number' given, then switch 
+     to that cpu. If 'all' then show status of all cpus.
+
+nmi: Only available in hung/crash state. Send NMI to a cpu that may be hung.
+
+sym: Initialize a symbol table for debugging a guest. Look into the System.map
+     file of guest for certain symbol values and provide them here.
+
+vcpuh: Given vcpu ptr, display hvm_vcpu struct.
+
+vcpu: Display current vcpu struct. If 'vcpu-ptr' given, display that vcpu.
+
+dom: display current domain. If 'domid' then display that domid. If 'all', then
+     display all domains.
+
+sched: show schedular info and run queues.
+
+mmu: print basic mmu info
+
+p2m: convert a gpfn to mfn given a domid. value in hex even without 0x.
+
+m2p: convert mfn to pfn. value in hex even without 0x.
+
+dpage: display struct page given a mfn or struct page ptr. Since, no info is 
+       kept on page type, we display all possible page types.
+
+dtrq: display timer queues.
+
+didt: dump IDT table.
+
+dgt: dump GDT table.
+
+dirq: display IRQ bindings.
+
+dvmc: display all or given dom/vcpu VMCS or VMCB.
+
+trcon: turn tracing on. Trace hooks must be added in xen and kdb function
+       called directly from there.
+
+trcoff: turn tracing off.
+
+trcz: zero trace buffer.
+
+trcp: give hints to print the circular trace buffer, like current active ptr.
+
+usr1: allows to add any arbitraty command quickly.
+
+--------------------------------------------------------------------------------
+/*
+ * Copyright (C) 2008 Oracle.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
diff -r 32034d1914a6 xen/kdb/guest/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y           := kdb_guest.o
+
diff -r 32034d1914a6 xen/kdb/guest/kdb_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/kdb_guest.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,342 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+/* information for symbols for a guest (includeing dom 0 ) is saved here */
+struct gst_syminfo {           /* guest symbols info */
+    int   domid;               /* which domain */
+    int   bitness;             /* 32 or 64 */
+    void *addrtblp;            /* ptr to (32/64)addresses tbl */
+    u8   *toktbl;              /* ptr to kallsyms_token_table */
+    u16  *tokidxtbl;           /* ptr to kallsyms_token_index */
+    u8   *kallsyms_names;      /* ptr to kallsyms_names */
+    long  kallsyms_num_syms;   /* ptr to kallsyms_num_syms */
+    kdbva_t  stext;            /* value of _stext in guest */
+    kdbva_t  etext;            /* value of _etext in guest */
+    kdbva_t  sinittext;        /* value of _sinittext in guest */
+    kdbva_t  einittext;        /* value of _einittext in guest */
+};
+
+#define MAX_CACHE 16                              /* cache upto 16 guests */
+struct gst_syminfo gst_syminfoa[MAX_CACHE];       /* guest symbol info array */
+
+static struct gst_syminfo *
+kdb_get_syminfo_slot(void)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].addrtblp == NULL)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+static struct gst_syminfo *
+kdb_domid2syminfop(domid_t domid)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].domid == domid)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+/* check if an address looks like text address in guest */
+int
+kdb_is_addr_guest_text(kdbva_t addr, int domid)
+{
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    if (!gp || !gp->stext || !gp->etext)
+        return 0;
+    KDBGP1("guestaddr: addr:%lx domid:%d\n", addr, domid);
+
+    return ( (addr >= gp->stext && addr <= gp->etext) ||
+             (addr >= gp->sinittext && addr <= gp->einittext) );
+}
+
+/*
+ * returns: value of kallsyms_addresses[idx];
+ */
+static kdbva_t
+kdb_rd_guest_addrtbl(struct gst_syminfo *gp, int idx)
+{
+    kdbva_t addr, retaddr=0;
+    int num = gp->bitness/8;       /* whether 4 byte or 8 byte ptrs */
+    domid_t id = gp->domid;
+
+    addr = (kdbva_t)(((char *)gp->addrtblp) + idx * num);
+    KDBGP1("rdguestaddrtbl:addr:%lx idx:%d\n", addr, idx);
+
+    if (kdb_read_mem(addr, (kdbbyt_t *)&retaddr,num,id) != num) {
+        kdbp("Can't read addrtbl domid:%d at:%lx\n", id, addr);
+        return 0;
+    }
+    KDBGP1("rdguestaddrtbl:exit:retaddr:%lx\n", retaddr);
+    return retaddr;
+}
+
+/* Based on el5 kallsyms.c file. */
+static unsigned int 
+kdb_expand_el5_sym(struct gst_syminfo *gp, unsigned int off, char *result)
+{   
+    int len, skipped_first = 0;
+    u8 u8idx, *tptr, *datap;
+    domid_t domid = gp->domid;
+
+    *result = '\0';
+
+    /* get the compressed symbol length from the first symbol byte */
+    datap = gp->kallsyms_names + off;
+    len = 0;
+    if ((kdb_read_mem((kdbva_t)datap, (kdbbyt_t *)&len, 1, domid)) != 1) {
+        KDBGP("failed to read guest memory\n");
+        return 0;
+    }
+    datap++;
+
+    /* update the offset to return the offset for the next symbol on
+     * the compressed stream */
+    off += len + 1;
+
+    /* for every byte on the compressed symbol data, copy the table
+     * entry for that byte */
+    while(len) {
+        u16 u16idx, *u16p;
+        if (kdb_read_mem((kdbva_t)datap,(kdbbyt_t *)&u8idx,1,domid)!=1){
+            kdbp("memory (u8idx) read error:%p\n",gp->tokidxtbl);
+            return 0;
+        }
+        u16p = u8idx + gp->tokidxtbl;
+        if (kdb_read_mem((kdbva_t)u16p,(kdbbyt_t *)&u16idx,2,domid)!=2){
+            kdbp("tokidxtbl read error:%p\n", u16p);
+            return 0;
+        }
+        tptr = gp->toktbl + u16idx;
+        datap++;
+        len--;
+
+        while ((kdb_read_mem((kdbva_t)tptr, (kdbbyt_t *)&u8idx, 1, domid)==1) &&
+               u8idx) {
+
+            if(skipped_first) {
+                *result = u8idx;
+                result++;
+            } else
+                skipped_first = 1;
+            tptr++;
+        }
+    }
+    *result = '\0';
+    return off;          /* return to offset to the next symbol */
+}
+
+#define EL4_NMLEN 127
+/* so much pain, so not sure of it's worth .. :).. */
+static kdbva_t
+kdb_expand_el4_sym(struct gst_syminfo *gp, int low, char *result, char *symp)
+{   
+    int i, j;
+    u8 *nmp = gp->kallsyms_names;       /* guest address space */
+    kdbbyt_t byte, prefix;
+    domid_t id = gp->domid;
+    kdbva_t addr;
+
+    KDBGP1("Eel4sym:nmp:%p maxidx:$%d sym:%s\n", nmp, low, symp);
+    for (i=0; i <= low; i++) {
+        /* unsigned prefix = *name++; */
+        if (kdb_read_mem((kdbva_t)nmp, &prefix, 1, id) != 1) {
+            kdbp("failed to read:%p domid:%x\n", nmp, id);
+            return 0;
+        }
+        KDBGP2("el4:i:%d prefix:%x\n", i, prefix);
+        nmp++;
+        /* strncpy(namebuf + prefix, name, KSYM_NAME_LEN - prefix); */
+        addr = (long)result + prefix;
+        for (j=0; j < EL4_NMLEN-prefix; j++) {
+            if (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) != 1) {
+                kdbp("failed read:%p domid:%x\n", nmp, id);
+                return 0;
+            }
+            KDBGP2("el4:j:%d byte:%x\n", j, byte);
+            *(kdbbyt_t *)addr = byte;
+            addr++; nmp++;
+            if (byte == '\0')
+                break;
+        }
+        KDBGP2("el4sym:i:%d res:%s\n", i, result);
+        if (symp && strcmp(result, symp) == 0)
+            return(kdb_rd_guest_addrtbl(gp, i));
+
+        /* kallsyms.c: name += strlen(name) + 1; */
+        if (j == EL4_NMLEN-prefix && byte != '\0')
+            while (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) && byte != '\0')
+                nmp++;
+    }
+    KDBGP1("Xel4sym: na-ga-da\n");
+    return 0;
+}
+
+static unsigned int
+kdb_get_el5_symoffset(struct gst_syminfo *gp, long pos)
+{
+    int i;
+    u8 data, *namep;
+    domid_t domid = gp->domid;
+
+    namep = gp->kallsyms_names;
+    for (i=0; i < pos; i++) {
+        if (kdb_read_mem((kdbva_t)namep, &data, 1, domid) != 1) {
+            kdbp("Can't read id:$%d mem:%p\n", domid, namep);
+            return 0;
+        }
+        namep = namep + data + 1;
+    }
+    return namep - gp->kallsyms_names;
+}
+
+/*
+ * for a given guest domid (domid >= 0 && < KDB_HYPDOMID), convert addr to
+ * symbol. offset is set to  addr - symbolstart
+ */
+char *
+kdb_guest_addr2sym(unsigned long addr, domid_t domid, ulong *offsp)
+{
+    static char namebuf[KSYM_NAME_LEN+1];
+    unsigned long low, high, mid;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    *offsp = 0;
+    if(!gp || gp->kallsyms_num_syms == 0)
+        return " ??? ";
+
+    namebuf[0] = namebuf[KSYM_NAME_LEN] = '\0';
+    if (1) {
+        /* do a binary search on the sorted kallsyms_addresses array */
+        low = 0;
+        high = gp->kallsyms_num_syms;
+
+        while (high-low > 1) {
+            mid = (low + high) / 2;
+            if (kdb_rd_guest_addrtbl(gp, mid) <= addr) 
+                low = mid;
+            else 
+                high = mid;
+        }
+        /* Grab name */
+        if (gp->toktbl) {
+            int symoff = kdb_get_el5_symoffset(gp,low);
+            kdb_expand_el5_sym(gp, symoff, namebuf);
+        } else
+            kdb_expand_el4_sym(gp, low, namebuf, NULL);
+        *offsp = addr - kdb_rd_guest_addrtbl(gp, low);
+        return namebuf;
+    }
+    return " ???? ";
+}
+
+
+/* 
+ * save guest (dom0 and others) symbols info : domid and following addresses:
+ *     &kallsyms_names &kallsyms_addresses &kallsyms_num_syms \
+ *     &kallsyms_token_table &kallsyms_token_index
+ */
+void
+kdb_sav_dom_syminfo(domid_t domid, long namesp, long addrap, long nump,
+                    long toktblp, long tokidxp)
+{
+    int bytes;
+    long val = 0;    /* must be set to zero for 32 on 64 cases */
+    struct gst_syminfo *gp = kdb_get_syminfo_slot();
+
+    if (gp == NULL) {
+        kdbp("kdb:kdb_sav_dom_syminfo():Table full.. symbols not saved\n");
+        return;
+    }
+    memset(gp, 0, sizeof(*gp));
+
+    gp->domid = domid;
+    gp->bitness = kdb_guest_bitness(domid);
+    gp->addrtblp = (void *)addrap;
+    gp->kallsyms_names = (u8 *)namesp;
+    gp->toktbl = (u8 *)toktblp;
+    gp->tokidxtbl = (u16 *)tokidxp;
+
+    KDBGP("domid:%x bitness:$%d numsyms:$%ld arrayp:%p\n", domid,
+          gp->bitness, gp->kallsyms_num_syms, gp->addrtblp);
+
+    bytes = gp->bitness/8;
+    if (kdb_read_mem(nump, (kdbbyt_t *)&val, bytes, domid) != bytes) {
+
+        kdbp("Unable to read number of symbols from:%lx\n", nump);
+        memset(gp, 0, sizeof(*gp));
+        return;
+    } else
+        kdbp("Number of symbols:$%ld\n", val);
+
+    gp->kallsyms_num_syms = val;
+
+    bytes = (gp->bitness/8) * gp->kallsyms_num_syms;
+    gp->stext = kdb_guest_sym2addr("_stext", domid);
+    gp->etext = kdb_guest_sym2addr("_etext", domid);
+    if (!gp->stext || !gp->etext)
+        kdbp("Warn: Can't find stext/etext\n");
+
+    if (gp->toktbl && gp->tokidxtbl) {
+        gp->sinittext = kdb_guest_sym2addr("_sinittext", domid);
+        gp->einittext = kdb_guest_sym2addr("_einittext", domid);
+        if (!gp->sinittext || !gp->einittext) {
+            kdbp("Warn: Can't find sinittext/einittext\n");
+    } 
+    }
+    KDBGP1("stxt:%lx etxt:%lx sitxt:%lx eitxt:%lx\n", gp->stext, gp->etext,
+           gp->sinittext, gp->einittext);
+    kdbp("Succesfully saved symbol info\n");
+}
+
+/*
+ * given a symbol string for a guest/domid, return its address
+ */
+kdbva_t
+kdb_guest_sym2addr(char *symp, domid_t domid)
+{
+    char namebuf[KSYM_NAME_LEN+1];
+    int i, off=0;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    KDBGP("sym2a: sym:%s domid:%x numsyms:%ld\n", symp, domid,
+          gp ? gp->kallsyms_num_syms: -1);
+
+    if (!gp)
+        return 0;
+
+    if (gp->toktbl == 0 || gp->tokidxtbl == 0)
+        return(kdb_expand_el4_sym(gp, gp->kallsyms_num_syms, namebuf, symp));
+
+    for (i=0; i < gp->kallsyms_num_syms; i++) {
+        off = kdb_expand_el5_sym(gp, off, namebuf);
+        KDBGP1("i:%d namebuf:%s\n", i, namebuf);
+        if (strcmp(namebuf, symp) == 0) {
+            return(kdb_rd_guest_addrtbl(gp, i));
+        }
+    }
+    KDBGP("sym2a:exit:na-ga-da\n");
+    return 0;
+}
diff -r 32034d1914a6 xen/kdb/include/kdb_extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdb_extern.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDB_EXTERN_H
+#define _KDB_EXTERN_H
+
+#define KDB_TRAP_FATAL     1    /* trap is fatal. can't resume from kdb */
+#define KDB_TRAP_NONFATAL  2    /* can resume from kdb */
+#define KDB_TRAP_KDBSTACK  3    /* to debug kdb itself. dump kdb stack */
+
+/* following can be called from anywhere in xen to debug */
+extern void kdb_trap_immed(int);
+extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
+extern void kdbp(const char *fmt, ...);
+
+typedef unsigned long kdbva_t;
+typedef unsigned char kdbbyt_t;
+typedef unsigned long kdbma_t;
+
+extern unsigned long kdb_dr7;
+
+
+extern volatile int kdb_session_begun;
+extern volatile int kdb_enabled;
+extern void kdb_init(void);
+extern int kdb_keyboard(struct cpu_user_regs *);
+extern void kdb_ssni_reenter(struct cpu_user_regs *);
+extern int kdb_handle_trap_entry(int, struct cpu_user_regs *);
+extern int kdb_trap_fatal(int, struct cpu_user_regs *);  /* fatal with regs */
+extern void kdb_dump_vmcs(uint16_t did, int vid);
+void kdb_dump_vmcb(uint16_t did, int vid);
+extern void kdb_dump_time_pcpu(void);
+
+
+#define VMPTRST_OPCODE  ".byte 0x0f,0xc7\n"     /* reg/opcode: /7 */
+#define MODRM_EAX_07    ".byte 0x38\n"          /* [EAX], with reg/opcode: /7 */
+static inline void __vmptrst(u64 *addr)
+{
+    asm volatile ( VMPTRST_OPCODE
+                   MODRM_EAX_07
+                   :
+                   : "a" (addr)
+                   : "memory");
+}
+
+extern void mukchk(unsigned long);
+#define is_hvm_or_hyb_domain is_hvm_domain
+#define is_hvm_or_hyb_vcpu is_hvm_vcpu
+
+
+#endif  /* _KDB_EXTERN_H */
diff -r 32034d1914a6 xen/kdb/include/kdbdefs.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbdefs.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBDEFS_H
+#define _KDBDEFS_H
+
+/* reason we are entering kdbmain (bp == breakpoint) */
+typedef enum {
+    KDB_REASON_KEYBOARD=1,  /* Keyboard entry - always 1 */
+    KDB_REASON_BPEXCP,      /* #BP excp: sw bp (INT3) */
+    KDB_REASON_DBEXCP,      /* #DB excp: TF flag or HW bp */
+    KDB_REASON_PAUSE_IPI,   /* received pause IPI from another CPU */
+} kdb_reason_t;
+
+
+/* cpu state: past, present, and future */
+typedef enum {
+    KDB_CPU_INVAL=0,     /* invalid value. not in or leaving kdb */
+    KDB_CPU_QUIT,        /* main cpu does GO. all others do QUIT */
+    KDB_CPU_PAUSE,       /* cpu is paused */
+    KDB_CPU_DISABLE,     /* disable interrupts */
+    KDB_CPU_SHOWPC,      /* all cpus must display their pc */
+    KDB_CPU_DO_VMEXIT,   /* all cpus must do vmcs vmexit. intel only */
+    KDB_CPU_MAIN_KDB,    /* cpu in kdb main command loop */
+    KDB_CPU_GO,          /* user entered go for this cpu */
+    KDB_CPU_SS,          /* single step for this cpu */
+    KDB_CPU_NI,          /* go to next instr after the call instr */
+    KDB_CPU_INSTALL_BP,  /* delayed install of sw bp(s) by this cpu */
+} kdb_cpu_cmd_t;
+
+/* ============= kdb commands ============================================= */
+
+typedef kdb_cpu_cmd_t (*kdb_func_t)(int, const char **, struct cpu_user_regs *);
+typedef kdb_cpu_cmd_t (*kdb_usgf_t)(void);
+
+typedef enum {
+    KDB_REPEAT_NONE = 0,    /* Do not repeat this command */
+    KDB_REPEAT_NO_ARGS,     /* Repeat the command without arguments */
+    KDB_REPEAT_WITH_ARGS,   /* Repeat the command including its arguments */
+} kdb_repeat_t;
+
+typedef struct _kdbtab {
+    char        *kdb_cmd_name;        /* Command name */
+    kdb_func_t   kdb_cmd_func;        /* ptr to function to execute command */
+    kdb_usgf_t   kdb_cmd_usgf;        /* usage function ptr */
+    int          kdb_cmd_crash_avail; /* available in sys fatal/crash state */
+    kdb_repeat_t kdb_cmd_repeat;      /* Does command auto repeat on enter? */
+} kdbtab_t;
+
+
+/* ============= types and stuff ========================================= */
+#define BFD_INVAL (~0UL)            /* invalid bfd_vma */
+
+#if defined(__x86_64__)
+  #define KDBIP rip
+  #define KDBSP rsp
+#else
+  #define KDBIP eip
+  #define KDBSP esp
+#endif
+
+/* ============= macros ================================================== */
+extern volatile int kdbdbg;
+#define KDBGP(...) {(kdbdbg) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP3(...) {0;};
+
+#define KDBMIN(x,y) (((x)<(y))?(x):(y))
+
+#endif  /* !_KDBDEFS_H */
diff -r 32034d1914a6 xen/kdb/include/kdbinc.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbinc.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBINC_H
+#define _KDBINC_H
+
+#include <xen/compile.h>
+#include <xen/config.h>
+#include <xen/version.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/mm.h>
+#include <xen/event.h>
+#include <xen/time.h>
+#include <xen/console.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/rangeset.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/delay.h>
+#include <xen/shutdown.h>
+#include <xen/percpu.h>
+#include <xen/multicall.h>
+#include <xen/rcupdate.h>
+#include <xen/ctype.h>
+#include <xen/symbols.h>
+#include <xen/shutdown.h>
+#include <xen/serial.h>
+#include <xen/grant_table.h>
+#include <asm/debugger.h>
+#include <asm/shared.h>
+#include <asm/apicdef.h>
+
+#include <asm/nmi.h>
+#include <asm/p2m.h>
+#include <asm/debugreg.h>
+#include <public/sched.h>
+#include <public/vcpu.h>
+#ifdef _XEN_LATEST
+#include <xsm/xsm.h>
+#endif
+
+#include <asm/hvm/vmx/vmx.h>
+
+#include "kdb_extern.h"
+#include "kdbdefs.h"
+#include "kdbproto.h"
+
+#endif /* !_KDBINC_H */
diff -r 32034d1914a6 xen/kdb/include/kdbproto.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbproto.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBPROTO_H
+#define _KDBPROTO_H
+
+/* hypervisor interfaces use by kdb or kdb interfaces in xen files */
+extern void console_putc(char);
+extern int console_getc(void);
+extern void show_trace(struct cpu_user_regs *);
+extern void kdb_dump_timer_queues(void);
+extern void kdb_time_resume(int);
+extern void kdb_print_sched_info(void);
+extern void kdb_curr_cpu_flush_vmcs(void);
+extern unsigned long address_lookup(char *);
+extern void kdb_prnt_guest_mapped_irqs(void);
+
+/* kdb globals */
+extern kdbtab_t *kdb_cmd_tbl;
+extern char kdb_prompt[32];
+extern volatile int kdb_sys_crash;
+extern volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+extern volatile int kdb_trcon;
+
+/* kdb interfaces */
+extern void __init kdb_io_init(void);
+extern void kdb_init_cmdtab(void);
+extern void kdb_do_cmds(struct cpu_user_regs *);
+extern int kdb_check_sw_bkpts(struct cpu_user_regs *);
+extern int kdb_check_watchpoints(struct cpu_user_regs *);
+extern void kdb_do_watchpoints(kdbva_t, int, int);
+extern void kdb_install_watchpoints(void);
+extern void kdb_clear_wps(int);
+extern kdbma_t kdb_rd_dbgreg(int);
+
+
+
+extern char *kdb_get_cmdline(char *);
+extern void kdb_clear_prev_cmd(void);
+extern void kdb_toggle_dis_syntax(void);
+extern int kdb_check_call_instr(domid_t, kdbva_t);
+extern void kdb_display_pc(struct cpu_user_regs *);
+extern kdbva_t kdb_print_instr(kdbva_t, long, domid_t);
+extern int kdb_read_mmem(kdbva_t, kdbbyt_t *, int);
+extern int kdb_read_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+extern int kdb_write_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+
+extern void kdb_install_all_swbp(void);
+extern void kdb_uninstall_all_swbp(void);
+extern int kdb_swbp_exists(void);
+extern void kdb_flush_swbp_table(void);
+extern int kdb_is_addr_guest_text(kdbva_t, int);
+extern kdbva_t kdb_guest_sym2addr(char *, domid_t);
+extern char *kdb_guest_addr2sym(unsigned long, domid_t, ulong *);
+extern void kdb_prnt_addr2sym(domid_t, kdbva_t, char *);
+extern void kdb_sav_dom_syminfo(domid_t, long, long, long, long, long);
+extern int kdb_guest_bitness(domid_t);
+extern void kdb_nmi_pause_cpus(cpumask_t);
+
+extern void kdb_trczero(void);
+void kdb_trcp(void);
+
+
+
+#endif /* !_KDBPROTO_H */
diff -r 32034d1914a6 xen/kdb/kdb_cmds.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_cmds.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3769 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+#if defined(__x86_64__)
+    #define KDBF64 "%lx"
+    #define KDBFL "%016lx"         /* print long all digits */
+#else
+    #define KDBF64 "%llx"
+    #define KDBFL "%08lx"
+#endif
+
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    #define KDB_LKDEF(l) ((l).raw.lock)
+    #define KDB_PGLLE(t) ((t).tail)    /* page list last element ^%$#@ */
+#else
+    #define KDB_LKDEF(l) ((l).lock)
+    #define KDB_PGLLE(t) ((t).prev)    /* page list last element ^%$#@ */
+#endif
+
+#define KDB_CMD_HISTORY_COUNT   32
+#define CMD_BUFLEN              200     /* kdb_printf: max printline == 256 */
+
+#define KDBMAXSBP 16                    /* max number of software breakpoints */
+#define KDB_MAXARGC 16                  /* max args in a kdb command */
+#define KDB_MAXBTP  8                   /* max display args in btp */
+
+/* condition is: 'r6 == 0x123f' or '0xffffffff82800000 != deadbeef'  */
+struct kdb_bpcond {
+    kdbbyt_t bp_cond_status;       /* 0 == off, 1 == register, 2 == memory */
+    kdbbyt_t bp_cond_type;         /* 0 == bad, 1 == equal, 2 == not equal */
+    ulong    bp_cond_lhs;          /* lhs of condition: reg offset or mem loc */
+    ulong    bp_cond_rhs;          /* right hand side of condition */
+};
+
+/* software breakpoint structure */
+struct kdb_sbrkpt {
+    kdbva_t  bp_addr;              /* address the bp is set at */
+    domid_t  bp_domid;             /* which domain the bp belongs to */
+    kdbbyt_t bp_originst;          /* save orig instr/s here */
+    kdbbyt_t bp_deleted;           /* delete pending on this bp */
+    kdbbyt_t bp_ni;                /* set for KDB_CPU_NI */
+    kdbbyt_t bp_just_added;        /* added in the current kdb session */
+    kdbbyt_t bp_type;              /* 0 = normal, 1 == cond,  2 == btp */
+    union {
+        struct kdb_bpcond bp_cond;
+        ulong *bp_btp;
+    } u;
+};
+
+/* don't use kmalloc in kdb which hijacks all cpus */
+static ulong kdb_btp_argsa[KDBMAXSBP][KDB_MAXBTP];
+static ulong *kdb_btp_ap[KDBMAXSBP];
+
+static struct kdb_reg_nmofs {
+    char *reg_nm;
+    int reg_offs;
+} kdb_reg_nm_offs[] =  {
+       { "rax", offsetof(struct cpu_user_regs, rax) },
+       { "rbx", offsetof(struct cpu_user_regs, rbx) },
+       { "rcx", offsetof(struct cpu_user_regs, rcx) },
+       { "rdx", offsetof(struct cpu_user_regs, rdx) },
+       { "rsi", offsetof(struct cpu_user_regs, rsi) },
+       { "rdi", offsetof(struct cpu_user_regs, rdi) },
+       { "rbp", offsetof(struct cpu_user_regs, rbp) },
+       { "rsp", offsetof(struct cpu_user_regs, rsp) },
+       { "r8",  offsetof(struct cpu_user_regs, r8) },
+       { "r9",  offsetof(struct cpu_user_regs, r9) },
+       { "r10", offsetof(struct cpu_user_regs, r10) },
+       { "r11", offsetof(struct cpu_user_regs, r11) },
+       { "r12", offsetof(struct cpu_user_regs, r12) },
+       { "r13", offsetof(struct cpu_user_regs, r13) },
+       { "r14", offsetof(struct cpu_user_regs, r14) },
+       { "r15", offsetof(struct cpu_user_regs, r15) },
+       { "rflags", offsetof(struct cpu_user_regs, rflags) } };
+
+static const int KDBBPSZ=1;                   /* size of KDB_BPINST is 1 byte*/
+static kdbbyt_t kdb_bpinst = 0xcc;            /* breakpoint instr: INT3 */
+static struct kdb_sbrkpt kdb_sbpa[KDBMAXSBP]; /* soft brkpt array/table */
+static kdbtab_t *tbp;
+
+static int kdb_set_bp(domid_t, kdbva_t, int, ulong *, char*, char*, char*);
+static void kdb_print_uregs(struct cpu_user_regs *);
+
+
+/* ===================== cmdline functions  ================================ */
+
+/* lp points to a string of only alpha numeric chars terminated by '\n'.
+ * Parse the string into argv pointers, and RETURN argc
+ * Eg:  if lp --> "dr  sp\n" :  argv[0]=="dr\0"  argv[1]=="sp\0"  argc==2
+ */
+static int
+kdb_parse_cmdline(char *lp, const char **argv)
+{
+    int i=0;
+
+    for (; *lp == ' '; lp++);      /* note: isspace() skips '\n' also */
+    while ( *lp != '\n' ) {
+        if (i == KDB_MAXARGC) {
+            printk("kdb: max args exceeded\n");
+            break;
+        }
+        argv[i++] = lp;
+        for (; *lp != ' ' && *lp != '\n'; lp++);
+        if (*lp != '\n')
+            *lp++ = '\0';
+        for (; *lp == ' '; lp++);
+    }
+    *lp = '\0';
+    return i;
+}
+
+void
+kdb_clear_prev_cmd()             /* so previous command is not repeated */
+{
+    tbp = NULL;
+}
+
+void
+kdb_do_cmds(struct cpu_user_regs *regs)
+{
+    char *cmdlinep;
+    const char *argv[KDB_MAXARGC];
+    int argc = 0, curcpu = smp_processor_id();
+    kdb_cpu_cmd_t result = KDB_CPU_MAIN_KDB;
+
+    snprintf(kdb_prompt, sizeof(kdb_prompt), "[%d]xkdb> ", curcpu);
+
+    while (result == KDB_CPU_MAIN_KDB) {
+        cmdlinep = kdb_get_cmdline(kdb_prompt);
+        if (*cmdlinep == '\n') {
+            if (tbp==NULL || tbp->kdb_cmd_func==NULL)
+                continue;
+            else
+                argc = -1;    /* repeat prev command */
+        } else {
+            argc = kdb_parse_cmdline(cmdlinep, argv);
+            for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_func; tbp++)  {
+                if (strcmp(argv[0], tbp->kdb_cmd_name)==0) 
+                    break;
+            }
+        }
+        if (kdb_sys_crash && tbp->kdb_cmd_func && !tbp->kdb_cmd_crash_avail) {
+            kdbp("cmd not available in fatal/crashed state....\n");
+            continue;
+        }
+        if (tbp->kdb_cmd_func) {
+            result = (*tbp->kdb_cmd_func)(argc, argv, regs);
+            if (tbp->kdb_cmd_repeat == KDB_REPEAT_NONE)
+                tbp = NULL;
+        } else
+            kdbp("kdb: Unknown cmd: %s\n", cmdlinep);
+    }
+    kdb_cpu_cmd[curcpu] = result;
+    return;
+}
+
+/* ===================== Util functions  ==================================== */
+
+int
+kdb_vcpu_valid(struct vcpu *in_vp)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    for(dp=domain_list; in_vp && dp; dp=dp->next_in_list)
+        for_each_vcpu(dp, vp)
+            if (in_vp == vp)
+                return 1;
+    return 0;     /* not found */
+}
+
+/*
+ * Given a symbol, find it's address
+ */
+static kdbva_t
+kdb_sym2addr(const char *p, domid_t domid)
+{
+    kdbva_t addr;
+
+    KDBGP1("sym2addr: p:%s domid:%d\n", p, domid);
+    if (domid == DOMID_IDLE)
+        addr = address_lookup((char *)p);
+    else
+        addr = (kdbva_t)kdb_guest_sym2addr((char *)p, domid);
+    KDBGP1("sym2addr: exit: addr returned:0x%lx\n", addr);
+    return addr;
+}
+
+/*
+ * convert ascii to int decimal (base 10). 
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2deci(const char *strp, int *intp)
+{
+    const char *endp;
+
+    KDBGP2("str2deci: str:%s\n", strp);
+    if (!isdigit(*strp))
+        return 0;
+    *intp = (int)simple_strtoul(strp, &endp, 10);
+    if (endp != strp+strlen(strp))
+        return 0;
+    KDBGP2("str2deci: intval:$%d\n", *intp);
+    return 1;
+}
+/*
+ * convert ascii to long. NOTE: base is 16
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2ulong(const char *strp, ulong *longp)
+{
+    ulong val;
+    const char *endp;
+
+    KDBGP2("str2long: str:%s\n", strp);
+    if (!isxdigit(*strp))
+        return 0;
+    val = (long)simple_strtoul(strp, &endp, 16);   /* handles leading 0x */
+    if (endp != strp+strlen(strp))
+        return 0;
+    if (longp)
+        *longp = val;
+    KDBGP2("str2long: val:0x%lx\n", val);
+    return 1;
+}
+/*
+ * convert a symbol or ascii address to hex address
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2addr(const char *strp, kdbva_t *addrp, domid_t id)
+{
+    kdbva_t addr;
+    const char *endp;
+
+    /* assume it's an address */
+    KDBGP2("str2addr: str:%s id:%d\n", strp, id);
+    addr = (kdbva_t)simple_strtoul(strp, &endp, 16); /*handles leading 0x */
+    if (endp != strp+strlen(strp))
+        if ( !(addr=kdb_sym2addr(strp, id)) )
+            return 0;
+    *addrp = addr;
+    KDBGP2("str2addr: addr:0x%lx\n", addr);
+    return 1;
+}
+
+/* Given domid, return ptr to struct domain 
+ * IF domid == DOMID_IDLE return ptr to idle_domain 
+ * IF domid == valid domain, return ptr to domain struct
+ * else domid is bad and return NULL
+ */
+static struct domain *
+kdb_domid2ptr(domid_t domid)
+{
+    struct domain *dp;
+
+    /* get_domain_by_id() ret NULL for both DOMID_IDLE and bad domids */
+    if (domid == DOMID_IDLE)
+        dp = idle_vcpu[smp_processor_id()]->domain;
+    else 
+        dp = get_domain_by_id(domid);   /* NULL now means bad domid */
+    return dp;
+}
+
+/*
+ * Returns:  0: failed. invalid domid or string, *idp not changed.
+ */
+static int
+kdb_str2domid(const char *domstr, domid_t *idp, int perr)
+{
+    int id;
+    if (!kdb_str2deci(domstr, &id) || !kdb_domid2ptr((domid_t)id)) {
+        if (perr)
+            kdbp("Invalid domid:%s\n", domstr);
+        return 0;
+    }
+    *idp = (domid_t)id;
+    return 1;
+}
+
+static struct domain *
+kdb_strdomid2ptr(const char *domstr, int perror)
+{
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
+}
+
+/* return a guest bitness: 32 or 64 */
+int
+kdb_guest_bitness(domid_t domid)
+{
+    const int HYPSZ = sizeof(long) * 8;
+    struct domain *dp = kdb_domid2ptr(domid);
+    int retval; 
+
+    if (is_idle_domain(dp))
+        retval = HYPSZ;
+    else if (is_hvm_or_hyb_domain(dp))
+        retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
+    else 
+        retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
+    KDBGP1("gbitness: domid:%d dp:%p bitness:%d\n", domid, dp, retval);
+    return retval;
+}
+
+/* kdb_print_spin_lock(&xyz_lock, "xyz_lock:", "\n"); */
+static void
+kdb_print_spin_lock(char *strp, spinlock_t *lkp, char *nlp)
+{
+    kdbp("%s %04hx %d %d%s", strp, KDB_LKDEF(*lkp), lkp->recurse_cpu,
+         lkp->recurse_cnt, nlp);
+}
+
+/* check if register string is valid. if yes, return offset to the register
+ * in cpu_user_regs, else return -1 */
+static int
+kdb_valid_reg(const char *nmp) 
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (strcmp(kdb_reg_nm_offs[i].reg_nm, nmp) == 0)
+            return kdb_reg_nm_offs[i].reg_offs;
+    return -1;
+}
+
+/* given offset of register, return register name string. if offset is invalid
+ * return NULL */
+static char *kdb_regoffs_to_name(int offs)
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (kdb_reg_nm_offs[i].reg_offs == offs)
+            return kdb_reg_nm_offs[i].reg_nm;
+    return NULL;
+}
+
+/* ===================== util struct funcs ================================= */
+static void
+kdb_prnt_timer(struct timer *tp)
+{
+#if XEN_SUBVERSION == 0 
+    kdbp(" expires:%016lx expires_end:%016lx cpu:%d status:%x\n", tp->expires, 
+         tp->expires_end, tp->cpu, tp->status);
+#else
+    kdbp(" expires:%016lx cpu:%d status:%x\n", tp->expires, tp->cpu,tp->status);
+#endif
+    kdbp(" function data:%p ptr:%p ", tp->data, tp->function);
+    kdb_prnt_addr2sym(DOMID_IDLE, (kdbva_t)tp->function, "\n");
+}
+
+static void 
+kdb_prnt_periodic_time(struct periodic_time *ptp)
+{
+    kdbp(" next:%p prev:%p\n", ptp->list.next, ptp->list.prev);
+    kdbp(" on_list:%d one_shot:%d dont_freeze:%d irq_issued:%d src:%x irq:%x\n",
+         ptp->on_list, ptp->one_shot, ptp->do_not_freeze, ptp->irq_issued,
+         ptp->source, ptp->irq);
+    kdbp(" vcpu:%p pending_intr_nr:%08x period:%016lx\n", ptp->vcpu,
+         ptp->pending_intr_nr, ptp->period);
+    kdbp(" scheduled:%016lx last_plt_gtime:%016lx\n", ptp->scheduled,
+         ptp->last_plt_gtime);
+    kdbp(" \n          timer info:\n");
+    kdb_prnt_timer(&ptp->timer);
+    kdbp("\n");
+}
+
+/* ===================== cmd functions  ==================================== */
+
+/*
+ * FUNCTION: Disassemble instructions
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dis(void)
+{
+    kdbp("dis [addr|sym][num][domid] : Disassemble instrs\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dis(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int num = 8;                           /* display 8 instr by default */
+    static kdbva_t addr = BFD_INVAL;
+    static domid_t domid;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dis();
+
+    if (argc != -1)      /* not a command repeat */
+        domid = guest_mode(regs) ?  current->domain->domain_id : DOMID_IDLE;
+
+    if (argc >= 4 && !kdb_str2domid(argv[3], &domid, 1)) { 
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc >= 3 && !kdb_str2deci(argv[2], &num)) {
+        kdbp("kdb:Invalid num\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc > 1 && !kdb_str2addr(argv[1], &addr, domid)) {
+        kdbp("kdb:Invalid addr/sym\n");
+        kdbp("(num has to be specified if providing domid)\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc == 1)                    /* not command repeat */
+        addr = regs->KDBIP;           /* PC is the default */
+    else if (addr == BFD_INVAL) {
+        kdbp("kdb:Invalid addr/sym\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    addr = kdb_print_instr(addr, num, domid);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* FUNCTION: kdb_cmdf_dism() Toggle disassembly syntax from Intel to ATT/GAS */
+static kdb_cpu_cmd_t
+kdb_usgf_dism(void)
+{
+    kdbp("dism: toggle disassembly mode between ATT/GAS and INTEL\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dism(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dism();
+
+    kdb_toggle_dis_syntax();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+_kdb_show_guest_stack(domid_t domid, kdbva_t ipaddr, kdbva_t spaddr)
+{
+    kdbva_t val;
+    int num=0, max=0, rd = kdb_guest_bitness(domid)/8;
+
+    kdb_print_instr(ipaddr, 1, domid);
+    KDBGP("_guest_stack:sp:%lx domid:%d rd:$%d\n", spaddr, domid, rd);
+    val = 0;                          /* must zero, in case guest is 32bit */
+    while((kdb_read_mem(spaddr,(kdbbyt_t *)&val,rd,domid)==rd) && num < 16){
+        KDBGP1("gstk:addr:%lx val:%lx\n", spaddr, val);
+        if (kdb_is_addr_guest_text(val, domid)) {
+            kdb_print_instr(val, 1, domid);
+            num++;
+        }
+        if (max++ > 10000)            /* don't walk down the stack forever */
+            break;                    /* 10k is chosen randomly */
+        spaddr += rd;
+    }
+}
+
+/* Read guest memory and display address that looks like text. */
+static void
+kdb_show_guest_stack(struct cpu_user_regs *regs, struct vcpu *vcpup)
+{
+    kdbva_t ipaddr=regs->KDBIP, spaddr = regs->KDBSP;
+    domid_t domid = vcpup->domain->domain_id;
+
+    ASSERT(domid != DOMID_IDLE);
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+}
+
+/* display stack. if vcpu ptr given, then display stack for that. Otherwise,
+ * use current regs */
+static kdb_cpu_cmd_t
+kdb_usgf_f(void)
+{
+    kdbp("f [vcpu-ptr]: dump current/vcpu stack\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_f(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_f();
+
+    if (argc > 1 ) {
+        struct vcpu *vp;
+        if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp)) {
+            kdbp("kdb: Bad VCPU ptr:%s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdb_show_guest_stack(&vp->arch.user_regs, vp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs))
+        kdb_show_guest_stack(regs, current);
+    else
+        show_trace(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an spaddr and domid for guest, dump stack */
+static kdb_cpu_cmd_t
+kdb_usgf_fg(void)
+{
+    kdbp("fg domid RIP ESP: dump guest stack given domid, RIP, and ESP\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_fg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid;
+    kdbva_t ipaddr, spaddr;
+
+    if (argc != 4) 
+        return kdb_usgf_fg();
+
+    if (kdb_str2domid(argv[1], &domid, 1)==0) {
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[2], &ipaddr)==0) {
+        kdbp("Bad ipaddr:%s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[3], &spaddr)==0) {
+        kdbp("Bad spaddr:%s\n", argv[3]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display kdb stack. for debugging kdb itself */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbf(void)
+{
+    kdbp("kdbf: display kdb stack. for debugging kdb only\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_kdbf(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbf();
+
+    kdb_trap_immed(KDB_TRAP_KDBSTACK);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* worker function to display memory. Request could be for any guest, domid.
+ * Also address could be machine or virtual */
+static void
+_kdb_display_mem(kdbva_t *addrp, int *lenp, int wordsz, int domid, int is_maddr)
+{
+    #define DDBUFSZ 4096
+
+    kdbbyt_t buf[DDBUFSZ], *bp;
+    int numrd, bytes;
+    int len = *lenp;
+    kdbva_t addr = *addrp;
+
+    /* round len down to wordsz boundry because on intel endian, printing
+     * characters is not prudent, (long and ints can't be interpreted 
+     * easily) */
+    len &= ~(wordsz-1);
+    len = KDBMIN(DDBUFSZ, len);
+    len = len ? len : wordsz;
+
+    KDBGP("dmem:addr:%lx buf:%p len:$%d domid:%d sz:$%d maddr:%d\n", addr,
+          buf, len, domid, wordsz, is_maddr);
+    if (is_maddr)
+        numrd=kdb_read_mmem((kdbma_t)addr, buf, len);
+    else
+        numrd=kdb_read_mem(addr, buf, len, domid);
+    if (numrd != len)
+        kdbp("Memory read error. Bytes read:$%d\n", numrd);
+
+    for (bp = buf; numrd > 0;) {
+        kdbp("%016lx: ", addr); 
+
+        /* display 16 bytes per line */
+        for (bytes=0; bytes < 16 && numrd > 0; bytes += wordsz) {
+            if (numrd >= wordsz) {
+                if (wordsz == 8)
+                    kdbp(" %016lx", *(long *)bp);
+                else
+                    kdbp(" %08x", *(int *)bp);
+                bp += wordsz;
+                numrd -= wordsz;
+                addr += wordsz;
+            }
+        }
+        kdbp("\n");
+        continue;
+    }
+    *lenp = len;
+    *addrp = addr;
+}
+
+/* display machine mem, ie, the given address is machine address */
+static kdb_cpu_cmd_t 
+kdb_display_mmem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbma_t maddr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&maddr, &len, wordsz, id, 1);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                                     /* default read len */
+
+    if (!kdb_str2ulong(argv[1], &maddr)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_display_mem(&maddr, &len, wordsz, 0, 1);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dwm(void)
+{
+    kdbp("dwm:  maddr|sym [num] : dump memory word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dwm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 4, kdb_usgf_dwm);
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ddm(void)
+{
+    kdbp("ddm:  maddr|sym [num] : dump double word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ddm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 8, kdb_usgf_ddm);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory : word or doubleword
+ *           wordsz : bytes in word. 4 or 8
+ *
+ *           We display upto BUFSZ bytes. User can just press enter for more.
+ *           addr is always in hex with or without leading 0x
+ */
+static kdb_cpu_cmd_t 
+kdb_display_mem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbva_t addr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&addr, &len, wordsz, id, 0);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    id = DOMID_IDLE;                /* not a command repeat, reset dom id */
+    if (argc >= 4) { 
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                       /* default read len */
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    _kdb_display_mem(&addr, &len, wordsz, id, 0);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dw(void)
+{
+    kdbp("dw vaddr|sym [num][domid] : dump mem word. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 4, kdb_usgf_dw);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dd(void)
+{
+    kdbp("dd vaddr|sym [num][domid] : dump dword. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dd(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 8, kdb_usgf_dd);
+}
+
+/* 
+ * FUNCTION: Modify Memory Word 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mw(void)
+{
+    kdbp("mw vaddr|sym val [domid] : modify memory word in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_mw();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val, 4, id) != 4)
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_md(void)
+{
+    kdbp("md vaddr|sym val [domid] : modify memory dword in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_md(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_md();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) {
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val,sizeof(val),id) != sizeof(val))
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct  Xgt_desc_struct {
+    unsigned short size;
+    unsigned long address __attribute__((packed));
+};
+
+void
+kdb_show_special_regs(struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    unsigned short tr;                 /* Task Register segment selector */
+    __u64 efer;
+
+    kdbp("\nSpecial Registers:\n");
+    __asm__ __volatile__ ("sidt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("IDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+    __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("GDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+
+    kdbp("cr0: %016lx  cr2: %016lx\n", read_cr0(), read_cr2());
+    kdbp("cr3: %016lx  cr4: %016lx\n", read_cr3(), read_cr4());
+    __asm__ __volatile__ ("str (%0) \n":: "a"(&tr) : "memory");
+    kdbp("TR: %x\n", tr);
+
+    rdmsrl(MSR_EFER, efer);    /* IA32_EFER */
+    kdbp("efer:"KDBF64" LMA(IA-32e mode):%d SCE(syscall/sysret):%d\n",
+         efer, ((efer&EFER_LMA) != 0), ((efer&EFER_SCE) != 0));
+
+    kdbp("DR0: %016lx  DR1:%016lx  DR2:%016lx\n", kdb_rd_dbgreg(0),
+         kdb_rd_dbgreg(1), kdb_rd_dbgreg(2)); 
+    kdbp("DR3: %016lx  DR6:%016lx  DR7:%016lx\n", kdb_rd_dbgreg(3),
+         kdb_rd_dbgreg(6), kdb_rd_dbgreg(7)); 
+}
+
+/* 
+ * FUNCTION: Dispaly Registers. If "sp" argument, then display additional regs
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dr(void)
+{
+    kdbp("dr [sp]: display registers. sp to display special regs also\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dr();
+
+    KDBGP1("regs:%p .rsp:%lx .rip:%lx\n", regs, regs->rsp, regs->rip);
+    show_registers(regs);
+    if (argc > 1 && !strcmp(argv[1], "sp")) 
+        kdb_show_special_regs(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* show registers on stack bottom where guest context is. same as dr if
+ * not running in guest mode */
+static kdb_cpu_cmd_t
+kdb_usgf_drg(void)
+{
+    kdbp("drg: display active guest registers at stack bottom\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_drg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_drg();
+
+    kdbp("\tNote: ds/es/fs/gs etc.. are not saved from the cpu\n");
+    kdb_print_uregs(guest_cpu_user_regs());
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Register
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mr(void)
+{
+    kdbp("mr reg val : Modify Register. val assumed in hex\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int regoffs;
+    ulong val;
+
+    if (argc != 3 || !kdb_str2ulong(argv[2], &val)) {
+        return kdb_usgf_mr();
+    }
+    argp = argv[1];
+
+#if defined(__x86_64__)
+    if ((regoffs=kdb_valid_reg(argp)) != -1)
+        *((uint64_t *)((char *)regs+regoffs)) = val;
+#else
+    if (!strcmp(argp, "eax"))
+        regs->eax = val;
+    else if (!strcmp(argp, "ebx"))
+        regs->ebx = val;
+    else if (!strcmp(argp, "ecx"))
+        regs->ecx = val;
+    else if (!strcmp(argp, "edx"))
+        regs->edx = val;
+    else if (!strcmp(argp, "esi"))
+        regs->esi = val;
+    else if (!strcmp(argp, "edi"))
+        regs->edi = val;
+    else if (!strcmp(argp, "ebp"))
+        regs->ebp = val;
+    else if (!strcmp(argp, "esp"))
+        regs->esp = val;
+    else if (!strcmp(argp, "eflags") || !strcmp(argp, "rflags"))
+        regs->eflags = val;
+#endif
+    else
+        kdbp("Error. Bad register : %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Single Step
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ss(void)
+{
+    kdbp("ss: single step\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ss(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    #define KDB_HALT_INSTR 0xf4
+
+    kdbbyt_t byte;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ss();
+
+    KDBGP("enter kdb_cmdf_ss \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_read_mem(regs->KDBIP, &byte, 1, id) == 1) {
+        if (byte == KDB_HALT_INSTR) {
+            kdbp("kdb: jumping over halt instruction\n");
+            regs->KDBIP++;
+        }
+    } else {
+        kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
+        current->arch.hvm_vcpu.single_step = 1;
+    } else
+        regs->eflags |= X86_EFLAGS_TF;
+
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Next Instruction, step over the call instr to the next instr
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ni(void)
+{
+    kdbp("ni: single step, stepping over function calls\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ni(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int sz, i;
+    domid_t id=guest_mode(regs) ? current->domain->domain_id:DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ni();
+
+    KDBGP("enter kdb_cmdf_ni \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if ((sz=kdb_check_call_instr(id, regs->KDBIP)) == 0)  /* !call instr */
+        return kdb_cmdf_ss(argc, argv, regs);         /* just do ss */
+
+    if ((i=kdb_set_bp(id, regs->KDBIP+sz, 1,0,0,0,0)) >= KDBMAXSBP) /* failed */
+        return KDB_CPU_MAIN_KDB;
+
+    kdb_sbpa[i].bp_ni = 1;
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+        current->arch.hvm_vcpu.single_step = 0;
+    else
+        regs->eflags &= ~X86_EFLAGS_TF;
+
+    return KDB_CPU_NI;
+}
+
+static void
+kdb_btf_enable(void)
+{
+    u64 debugctl;
+    rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 0x2);
+}
+
+/* 
+ * FUNCTION: Single Step to branch. Doesn't seem to work very well.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ssb(void)
+{
+    kdbp("ssb: singe step to branch\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ssb(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ssb();
+
+    KDBGP("MUK: enter kdb_cmdf_ssb\n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (is_hvm_or_hyb_vcpu(current)) 
+        current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
+
+    regs->eflags |= X86_EFLAGS_TF;
+    kdb_btf_enable();
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Continue Execution. TF must be cleared here as this could run on 
+ *           any cpu. Hence not OK to do it from kdb_end_session.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_go(void)
+{
+    kdbp("go: leave kdb and continue execution\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_go(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_go();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    return KDB_CPU_GO;
+}
+
+/* All cpus must display their current context */
+static kdb_cpu_cmd_t 
+kdb_cpu_status_all(int ccpu, struct cpu_user_regs *regs)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)   /* hung cpu */
+                continue;
+            kdb_cpu_cmd[cpu] = KDB_CPU_SHOWPC;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_SHOWPC);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * display/switch CPU. 
+ *  Argument:
+ *     none:   just go back to initial cpu
+ *     cpunum: switch to given vpu
+ *     "all":  show one line status of all cpus
+ */
+extern volatile int kdb_init_cpu;
+static kdb_cpu_cmd_t
+kdb_usgf_cpu(void)
+{
+    kdbp("cpu [all|num]: none will switch back to initial cpu\n");
+    kdbp("               cpunum to switch to the vcpu. all to show status\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_cpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+    int ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cpu();
+
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all"))
+            return kdb_cpu_status_all(ccpu, regs);
+
+            cpu = (int)simple_strtoul(argv[1], NULL, 0); /* handles 0x */
+            if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && 
+                cpu_online(cpu) && kdb_cpu_cmd[cpu] == KDB_CPU_PAUSE)
+            {
+                kdbp("Switching to cpu:%d\n", cpu);
+                kdb_cpu_cmd[cpu] = KDB_CPU_MAIN_KDB;
+
+                /* clear any single step on the current cpu */
+                regs->eflags &= ~X86_EFLAGS_TF;
+                return KDB_CPU_PAUSE;
+            } else {
+                if (cpu != ccpu)
+                    kdbp("Unable to switch to cpu:%d\n", cpu);
+                else {
+                    kdb_display_pc(regs);
+                }
+                return KDB_CPU_MAIN_KDB;
+            }
+    }
+    /* no arg means back to initial cpu */
+    if (!kdb_sys_crash && ccpu != kdb_init_cpu) {
+        if (kdb_cpu_cmd[kdb_init_cpu] == KDB_CPU_PAUSE) {
+            regs->eflags &= ~X86_EFLAGS_TF;
+            kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_MAIN_KDB;
+            return KDB_CPU_PAUSE;
+        } else
+            kdbp("Unable to switch to: %d\n", kdb_init_cpu);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* send NMI to all or given CPU. Must be crashed/fatal state */
+static kdb_cpu_cmd_t
+kdb_usgf_nmi(void)
+{
+    kdbp("nmi cpu#|all: send nmi cpu/s. must reboot when done with kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_nmi(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    cpumask_t cpumask;
+    int ccpu = smp_processor_id();
+
+    if (argc <= 1 || (argc > 1 && *argv[1] == '?'))
+        return kdb_usgf_nmi();
+
+    if (!kdb_sys_crash) {
+        kdbp("kdb: nmi cmd available in crashed state only\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!strcmp(argv[1], "all"))
+        cpumask = cpu_online_map;
+    else {
+        int cpu = (int)simple_strtoul(argv[1], NULL, 0);
+        if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && cpu_online(cpu))
+            cpumask = *cpumask_of(cpu);
+        else {
+            kdbp("KDB nmi: invalid cpu %s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    kdb_nmi_pause_cpus(cpumask);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_percpu(void)
+{
+    kdbp("percpu: display per cpu pointers\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_percpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_percpu();
+    kdb_dump_time_pcpu();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ========================= Breakpoints ==================================== */
+
+static void
+kdb_prnt_bp_cond(int bpnum)
+{
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {
+        kdbp("     ( %s %c%c %lx )\n", 
+             kdb_regoffs_to_name(bpcp->bp_cond_lhs),
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    } else {
+        kdbp("     ( %lx %c%c %lx )\n", bpcp->bp_cond_lhs,
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    }
+}
+
+static void
+kdb_prnt_bp_extra(int bpnum)
+{
+    if (kdb_sbpa[bpnum].bp_type == 2) {
+        ulong i, arg, *btp = kdb_sbpa[bpnum].u.bp_btp;
+        
+        kdbp("   will trace ");
+        for (i=0; i < KDB_MAXBTP && btp[i]; i++)
+            if ((arg=btp[i]) < sizeof (struct cpu_user_regs)) {
+                kdbp(" %s ", kdb_regoffs_to_name(arg));
+            } else {
+                kdbp(" %lx ", arg);
+            }
+        kdbp("\n");
+
+    } else if (kdb_sbpa[bpnum].bp_type == 1)
+        kdb_prnt_bp_cond(bpnum);
+}
+
+/*
+ * List software breakpoints
+ */
+static kdb_cpu_cmd_t
+kdb_display_sbkpts(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted) {
+            struct domain *dp = kdb_domid2ptr(kdb_sbpa[i].bp_domid);
+
+            if (dp == NULL || dp->is_dying) {
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                continue;
+            }
+            kdbp("[%d]: domid:%d 0x%lx   ", i, 
+                 kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr);
+            kdb_prnt_addr2sym(kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr,"\n");
+            kdb_prnt_bp_extra(i);
+        }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Check if any breakpoints that we need to install (delayed install)
+ * Returns: 1 if yes, 0 if none.
+ */
+int
+kdb_swbp_exists(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+/*
+ * Check if any breakpoints were deleted this kdb session
+ * Returns: 0 if none, 1 if yes
+ */
+static int
+kdb_swbp_deleted(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+
+/*
+ * Flush deleted sw breakpoints
+ */
+void
+kdb_flush_swbp_table(void)
+{
+    int i;
+    KDBGP("ccpu:%d flush_swbp_table: deleted:%x\n", smp_processor_id(), 
+          kdb_swbp_deleted());
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted) {
+            KDBGP("flush:[%x] addr:0x%lx\n",i,kdb_sbpa[i].bp_addr);
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        }
+}
+
+/*
+ * Delete/Clear a sw breakpoint
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bc(void)
+{
+    kdbp("bc $num|all : clear given or all breakpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, bpnum = -1, delall = 0;
+    const char *argp;
+
+    if (argc != 2 || *argv[1] == '?')
+        return kdb_usgf_bc();
+
+    if (!kdb_swbp_exists()) {
+        kdbp("No breakpoints are set\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        delall = 1;
+    else if (!kdb_str2deci(argp, &bpnum) || bpnum < 0 || bpnum > KDBMAXSBP) {
+        kdbp("Invalid bpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (delall && kdb_sbpa[i].bp_addr) {
+            kdbp("Deleted breakpoint [%x] addr:0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            continue;
+        }
+        if (bpnum != -1 && bpnum == i) {
+            kdbp("Deleted breakpoint [%x] at 0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            break;
+        }
+    }
+    if (i >= KDBMAXSBP && !delall)
+        kdbp("Unable to delete breakpoint: %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Install a breakpoint in the given array entry
+ * Returns: 0 : failed to install
+ *          1 : installed successfully
+ */
+static int
+kdb_install_swbp(int idx)                   /* which entry in the bp array */
+{
+    kdbva_t addr = kdb_sbpa[idx].bp_addr;
+    domid_t domid = kdb_sbpa[idx].bp_domid;
+    kdbbyt_t *p = &kdb_sbpa[idx].bp_originst;
+    struct domain *dp = kdb_domid2ptr(domid);
+
+    if (dp == NULL || dp->is_dying) {
+        memset(&kdb_sbpa[idx], 0, sizeof(kdb_sbpa[idx]));
+        kdbp("Removed bp %d addr:%p domid:%d\n", idx, addr, domid);
+        return 0;
+    }
+
+    if (kdb_read_mem(addr, p, KDBBPSZ, domid) != KDBBPSZ){
+        kdbp("Failed(R) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    if (kdb_write_mem(addr, &kdb_bpinst, KDBBPSZ, domid) != KDBBPSZ) {
+        kdbp("Failed(W) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    KDBGP("install_swbp: installed bp:%x at:0x%lx ccpu:%x domid:%d\n",
+          idx, kdb_sbpa[idx].bp_addr, smp_processor_id(), domid);
+    return 1;
+}
+
+/*
+ * Install all the software breakpoints
+ */
+void
+kdb_install_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_deleted && kdb_sbpa[i].bp_addr)
+            kdb_install_swbp(i);
+}
+
+static void
+kdb_uninstall_a_swbp(int i)
+{
+    kdbva_t addr = kdb_sbpa[i].bp_addr;
+    kdbbyt_t originst = kdb_sbpa[i].bp_originst;
+    domid_t id = kdb_sbpa[i].bp_domid;
+
+    kdb_sbpa[i].bp_just_added = 0;
+    if (!addr)
+        return;
+    if (kdb_write_mem(addr, &originst, KDBBPSZ, id) != KDBBPSZ) {
+        kdbp("Failed to uninstall breakpoint %x at:0x%lx domid:%d\n",
+             i, kdb_sbpa[i].bp_addr, id);
+    }
+}
+
+/*
+ * Uninstall all the software breakpoints at beginning of kdb session
+ */
+void
+kdb_uninstall_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++) 
+        kdb_uninstall_a_swbp(i);
+    KDBGP("ccpu:%d uninstalled all bps\n", smp_processor_id());
+}
+
+/* RETURNS: rc == 2: condition was not met,  rc == 3: condition was met */
+static int
+kdb_check_bp_condition(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong res = 0, lhsval=0;
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {             /* register condition */
+        uint64_t *rp = (uint64_t *)((char *)regs + bpcp->bp_cond_lhs);
+        lhsval = *rp;
+    } else if (bpcp->bp_cond_status == 2) {      /* memaddr condition */
+        ulong addr = bpcp->bp_cond_lhs;
+        int num = sizeof(lhsval);
+
+        if (kdb_read_mem(addr, (kdbbyt_t *)&lhsval, num, domid) != num) {
+            kdbp("kdb: unable to read %d bytes at %lx\n", num, addr);
+            return 3;
+        }
+    }
+    if (bpcp->bp_cond_type == 1)                 /* lhs == rhs */
+        res = (lhsval == bpcp->bp_cond_rhs);
+    else                                         /* lhs != rhs */
+        res = (lhsval != bpcp->bp_cond_rhs);
+
+    if (!res)
+        kdbp("KDB: [%d]Ignoring bp:%d condition not met. val:%lx\n", 
+              smp_processor_id(), bpnum, lhsval); 
+
+    KDBGP1("bpnum:%d domid:%d cond: %d %d %lx %lx res:%d\n", bpnum, domid, 
+           bpcp->bp_cond_status, bpcp->bp_cond_type, bpcp->bp_cond_lhs, 
+           bpcp->bp_cond_rhs, res);
+
+    return (res ? 3 : 2);
+}
+
+static void
+kdb_prnt_btp_info(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong i, arg, val, num, *btp = kdb_sbpa[bpnum].u.bp_btp;
+
+    kdb_prnt_addr2sym(domid, regs->KDBIP, "\n");
+    num = kdb_guest_bitness(domid)/8;
+    for (i=0; i < KDB_MAXBTP && (arg=btp[i]); i++) {
+        if (arg < sizeof (struct cpu_user_regs)) {
+            uint64_t *rp = (uint64_t *)((char *)regs + arg);
+            kdbp(" %s: %016lx ", kdb_regoffs_to_name(arg), *rp);
+        } else {
+            if (kdb_read_mem(arg, (kdbbyt_t *)&val, num, domid) != num)
+                kdbp("kdb: unable to read %d bytes at %lx\n", num, arg);
+            if (num == 8)
+                kdbp(" %016lx:%016lx ", arg, val);
+            else
+                kdbp(" %08lx:%08lx ", arg, val);
+        }
+    }
+    kdbp("\n");
+    KDBGP1("bpnum:%d domid:%d btp:%p num:%d\n", bpnum, domid, btp, num);
+}
+
+/*
+ * Check if the BP trap belongs to us. 
+ * Return: 0 : not one of ours. IP not changed. (leave kdb)
+ *         1 : one of ours but deleted. IP decremented. (leave kdb)
+ *         2 : one of ours but condition not met, or btp. IP decremented.(leave)
+ *         3 : one of ours and active. IP decremented. (stay in kdb)
+ */
+int 
+kdb_check_sw_bkpts(struct cpu_user_regs *regs)
+{
+    int i, rc=0;
+    domid_t curid;
+
+    curid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    for(i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_domid == curid  && 
+            kdb_sbpa[i].bp_addr == (regs->KDBIP- KDBBPSZ)) {
+
+            regs->KDBIP -= KDBBPSZ;
+            rc = 3;
+
+            if (kdb_sbpa[i].bp_ni) {
+                kdb_uninstall_a_swbp(i);
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            } else if (kdb_sbpa[i].bp_deleted) {
+                rc = 1;
+            } else if (kdb_sbpa[i].bp_type == 1) {
+                rc = kdb_check_bp_condition(i, regs, curid);
+            } else if (kdb_sbpa[i].bp_type == 2) {
+                kdb_prnt_btp_info(i, regs, curid);
+                rc = 2;
+            }
+            KDBGP1("ccpu:%d rc:%d curid:%d domid:%d addr:%lx\n", 
+                   smp_processor_id(), rc, curid, kdb_sbpa[i].bp_domid, 
+                   kdb_sbpa[i].bp_addr);
+            break;
+        }
+    }
+    return (rc);
+}
+
+/* Eg: r6 == 0x123EDF  or 0xFFFF2034 != 0xDEADBEEF
+ * regoffs: -1 means lhs is not reg. else offset of reg in cpu_user_regs
+ * addr: memory location if lhs is not register, eg, 0xFFFF2034
+ * condp : points to != or ==
+ * rhsval : right hand side value
+ */
+static void
+kdb_set_bp_cond(int bpnum, int regoffs, ulong addr, char *condp, ulong rhsval)
+{
+    if (bpnum >= KDBMAXSBP) {
+        kdbp("BUG: %s got invalid bpnum\n", __FUNCTION__);
+        return;
+    }
+    if (regoffs != -1) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 1;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = regoffs;
+    } else if (addr != 0) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 2;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = addr;
+    } else {
+        kdbp("error: invalid call to kdb_set_bp_cond\n");
+        return;
+    }
+    kdb_sbpa[bpnum].u.bp_cond.bp_cond_rhs = rhsval;
+
+    if (*condp == '!')
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 2;
+    else
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 1;
+}
+
+/* install breakpt at given addr. 
+ * ni: bp for next instr 
+ * btpa: ptr to args for btp for printing when bp is hit
+ * lhsp/condp/rhsp: point to strings of condition
+ *
+ * RETURNS: the index in array where installed. KDBMAXSBP if error 
+ */
+static int
+kdb_set_bp(domid_t domid, kdbva_t addr, int ni, ulong *btpa, char *lhsp, 
+           char *condp, char *rhsp)
+{
+    int i, pre_existing = 0, regoffs = -1;
+    ulong memloc=0, rhsval=0, tmpul;
+
+    if (btpa && (lhsp || rhsp || condp)) {
+        kdbp("internal error. btpa and (lhsp || rhsp || condp) set\n");
+        return KDBMAXSBP;
+    }
+    if (lhsp && ((regoffs=kdb_valid_reg(lhsp)) == -1)  &&
+        kdb_str2ulong(lhsp, &memloc) &&
+        kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0) {
+
+        kdbp("error: invalid argument: %s\n", lhsp);
+        return KDBMAXSBP;
+    }
+    if (rhsp && ! kdb_str2ulong(rhsp, &rhsval)) {
+        kdbp("error: invalid argument: %s\n", rhsp);
+        return KDBMAXSBP;
+    }
+
+    /* see if bp already set */
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_addr==addr && kdb_sbpa[i].bp_domid==domid) {
+
+            if (kdb_sbpa[i].bp_deleted) {
+                /* just re-set this bp again */
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                pre_existing = 1;
+            } else {
+                kdbp("Breakpoint already set \n");
+                return KDBMAXSBP;
+            }
+        }
+    }
+    /* see if any room left for another breakpoint */
+    for (i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_addr)
+            break;
+    if (i >= KDBMAXSBP) {
+        kdbp("ERROR: Breakpoint table full....\n");
+        return i;
+    }
+    kdb_sbpa[i].bp_addr = addr;
+    kdb_sbpa[i].bp_domid = domid;
+    if (btpa) {
+        kdb_sbpa[i].bp_type = 2;
+        kdb_sbpa[i].u.bp_btp = btpa;
+    } else if (regoffs != -1 || memloc) {
+        kdb_sbpa[i].bp_type = 1;
+        kdb_set_bp_cond(i, regoffs, memloc, condp, rhsval);
+    } else
+        kdb_sbpa[i].bp_type = 0;
+
+    if (kdb_install_swbp(i)) {                  /* make sure it can be done */
+        if (ni)
+            return i;
+
+        kdb_uninstall_a_swbp(i);                /* dont' show user INT3 */
+        if (!pre_existing)               /* make sure no is cpu sitting on it */
+            kdb_sbpa[i].bp_just_added = 1;
+
+        kdbp("bp %d set for domid:%d at: 0x%lx ", i, kdb_sbpa[i].bp_domid, 
+             kdb_sbpa[i].bp_addr);
+        kdb_prnt_addr2sym(domid, addr, "\n");
+        kdb_prnt_bp_extra(i);
+    } else {
+        kdbp("ERROR:Can't install bp: 0x%lx domid:%d\n", addr, domid);
+        if (pre_existing)     /* in case a cpu is sitting on this bp in traps */
+            kdb_sbpa[i].bp_deleted = 1;
+        else
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        return KDBMAXSBP;
+    }
+    /* make sure swbp reporting is enabled in the vmcb/vmcs */
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        struct domain *dp = kdb_domid2ptr(domid);
+        dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
+        KDBGP("debugger_attached set. domid:%d\n", domid);
+    }
+    return i;
+}
+
+/* 
+ * Set/List Software Breakpoint/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bp(void)
+{
+    kdbp("bp [addr|sym][domid][condition]: display or set a breakpoint\n");
+    kdbp("  where cond is like: r6 == 0x123F or rax != DEADBEEF or \n");
+    kdbp("       ffff82c48038fe58 == 321E or 0xffff82c48038fe58 != 0\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9");
+    kdbp(" r10 r11 r12 r13 r14 r15 rflags\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    int idx = -1;
+    domid_t domid = DOMID_IDLE;
+    char *domidstrp, *lhsp=NULL, *condp=NULL, *rhsp=NULL;
+
+    if ((argc > 1 && *argv[1] == '?') || argc == 4 || argc > 6)
+        return kdb_usgf_bp();
+
+    if (argc < 2 || kdb_sys_crash)         /* list all set breakpoints */
+        return kdb_display_sbkpts();
+
+    /* valid argc either: 2 3 5 or 6 
+     * 'bp idle_loop r6 == 0xc000' OR 'bp idle_loop 3 r9 != 0xdeadbeef' */
+    idx = (argc == 5) ? 2 : ((argc == 6) ? 3 : idx);
+    if (argc >= 5 ) {
+        lhsp = (char *)argv[idx];
+        condp = (char *)argv[idx+1];
+        rhsp = (char *)argv[idx+2];
+
+        if (!kdb_str2ulong(rhsp, NULL) || *(condp+1) != '=' || 
+            (*condp != '=' && *condp != '!')) {
+
+            return kdb_usgf_bp();
+        }
+    }
+    domidstrp = (argc == 3 || argc == 6 ) ? (char *)argv[2] : NULL;
+    if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
+        return kdb_usgf_bp();
+    }
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        kdbp("HVM domain not supported yet for conditional bp\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    /* make sure xen addr is in xen text, otherwise bp set in 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_set_bp(domid, addr, 0, NULL, lhsp, condp, rhsp);     /* 0 is ni flag */
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* trace breakpoint, meaning, upon bp trace/print some info and continue */
+
+static kdb_cpu_cmd_t
+kdb_usgf_btp(void)
+{
+    kdbp("btp addr|sym [domid] reg|domid-mem-addr... : breakpoint trace\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9 ");
+    kdbp("r10 r11 r12 r13 r14 r15 rflags\n");
+    kdbp("  Eg. btp idle_cpu 7 rax rbx 0x20ef5a5 r9\n");
+    kdbp("      will print rax, rbx, *(long *)0x20ef5a5, r9 and continue\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_btp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, btpidx, numrd, argsidx, regoffs = -1;
+    kdbva_t addr, memloc=0;
+    domid_t domid = DOMID_IDLE;
+    ulong *btpa, tmpul;
+
+    if ((argc > 1 && *argv[1] == '?') || argc < 3)
+        return kdb_usgf_btp();
+
+    argsidx = 2;                   /* assume 3rd arg is not domid */
+    if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
+
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+            kdbp("HVM domains are not currently supprted\n");
+            return KDB_CPU_MAIN_KDB;
+        } else
+            argsidx = 3;               /* 3rd arg is a domid */
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    /* make sure xen addr is in xen text, otherwise will trace 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    numrd = kdb_guest_bitness(domid)/8;
+    if (kdb_read_mem(addr, (kdbbyt_t *)&tmpul, numrd, domid) != numrd) {
+        kdbp("Unable to read mem from %s (%lx)\n", argv[1], addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    for (btpidx=0; btpidx < KDBMAXSBP && kdb_btp_ap[btpidx]; btpidx++);
+    if (btpidx >= KDBMAXSBP) {
+        kdbp("error: table full. delete few breakpoints\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    btpa = kdb_btp_argsa[btpidx];
+    memset(btpa, 0, sizeof(kdb_btp_argsa[0]));
+
+    for (i=0; argv[argsidx]; i++, argsidx++) {
+
+        if (((regoffs=kdb_valid_reg(argv[argsidx])) == -1)  &&
+            kdb_str2ulong(argv[argsidx], &memloc) &&
+            (memloc < sizeof (struct cpu_user_regs) ||
+            kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0)){
+
+            kdbp("error: invalid argument: %s\n", argv[argsidx]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        if (i >= KDB_MAXBTP) {
+            kdbp("error: cannot specify more than %d args\n", KDB_MAXBTP);
+            return KDB_CPU_MAIN_KDB;
+        }
+        btpa[i] = (regoffs == -1) ? memloc : regoffs;
+    }
+
+    i = kdb_set_bp(domid, addr, 0, btpa, 0, 0, 0);     /* 0 is ni flag */
+    if (i < KDBMAXSBP)
+        kdb_btp_ap[btpidx] = kdb_btp_argsa[btpidx];
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * Set/List watchpoints, ie, hardware breakpoint/s, in hypervisor
+ *   Usage: wp [sym|addr] [w|i]   w == write only data watchpoint
+ *                                i == IO watchpoint (read/write)
+ *
+ *   Eg:  wp        : list all watchpoints set
+ *        wp addr   : set a read/write wp at given addr
+ *        wp addr w : set a write only wp at given addr
+ *        wp addr i : set an IO wp at given addr (16bits port #)
+ *
+ *  TBD: allow to be set on particular cpu
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_wp(void)
+{
+    kdbp("wp [addr|sym][w|i]: display or set watchpoint. writeonly or IO\n");
+    kdbp("\tnote: watchpoint is triggered after the instruction executes\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    domid_t domid = DOMID_IDLE;
+    int rw = 3, len = 4;       /* for now just default to 4 bytes len */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_wp();
+
+    if (argc <= 1 || kdb_sys_crash) {       /* list all set watchpoints */
+        kdb_do_watchpoints(0, 0, 0);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2) {
+        if (!strcmp(argv[2], "w"))
+            rw = 1;
+        else if (!strcmp(argv[2], "i"))
+            rw = 2;
+        else {
+            return kdb_usgf_wp();
+        }
+    }
+    kdb_do_watchpoints(addr, rw, len);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_wc(void)
+{
+    kdbp("wc $num|all : clear given or all watchpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int wpnum;              /* wp num to delete. -1 for all */
+
+    if (argc != 2 || *argv[1] == '?') 
+        return kdb_usgf_wc();
+
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        wpnum = -1;
+    else if (!kdb_str2deci(argp, &wpnum)) {
+        kdbp("Invalid wpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_clear_wps(wpnum);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display struct hvm_vcpu{} in struct vcpu.arch{} */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpuh(void)
+{
+    kdbp("vcpuh vcpu-ptr : display hvm_vcpu struct\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpuh(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *vp;
+    struct hvm_vcpu *hvp;
+    struct hvm_io_op *ioop;
+    struct vlapic *vlp;
+
+    if (argc < 2 || *argv[1] == '?') 
+        return kdb_usgf_vcpuh();
+
+    if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
+        !is_hvm_or_hyb_vcpu(vp)) {
+
+        kdbp("kdb: Bad VCPU: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    hvp = &vp->arch.hvm_vcpu;
+    vlp = &hvp->vlapic;
+    kdbp("vcpu:%lx id:%d domid:%d\n", vp, vp->vcpu_id, vp->domain->domain_id);
+
+    ioop = NULL;   /* compiler warning */
+    kdbp("&hvm_vcpu:%lx  guest_efer:"KDBFL"\n", hvp, hvp->guest_efer);
+    kdbp("  guest_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->guest_cr[0],
+         hvp->guest_cr[1],hvp->guest_cr[2]);
+    kdbp("            [3]:"KDBFL" [4]:"KDBFL"\n", hvp->guest_cr[3],
+         hvp->guest_cr[4]);
+    kdbp("  hw_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->hw_cr[0],
+         hvp->hw_cr[1], hvp->hw_cr[2]);
+    kdbp("          [3]:"KDBFL" [4]:"KDBFL"\n", hvp->hw_cr[3], hvp->hw_cr[4]);
+
+    kdbp("  VLAPIC: base msr:"KDBF64" dis:%x tmrdiv:%x\n", 
+         vlp->hw.apic_base_msr, vlp->hw.disabled, vlp->hw.timer_divisor);
+    kdbp("          regs:%p regs_page:%p\n", vlp->regs, vlp->regs_page);
+    kdbp("          periodic time:\n"); 
+    kdb_prnt_periodic_time(&vlp->pt);
+
+    kdbp("  xen_port:%x flag_dr_dirty:%x dbg_st_latch:%x\n", hvp->xen_port,
+         hvp->flag_dr_dirty, hvp->debug_state_latch);
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+
+        struct arch_vmx_struct *vxp = &hvp->u.vmx;
+        kdbp("  &vmx: %p vmcs:%lx active_cpu:%x launched:%x\n", vxp, vxp->vmcs, 
+             vxp->active_cpu, vxp->launched);
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("    exec_ctrl:%x vpid:$%d\n", vxp->exec_control, vxp->vpid);
+#endif
+        kdbp("    host_cr0: "KDBFL" vmx: {realm:%x emulate:%x}\n",
+             vxp->host_cr0, vxp->vmx_realmode, vxp->vmx_emulate);
+
+#ifdef __x86_64__
+        kdbp("    &msr_state:%p\n", &vxp->msr_state);
+#endif
+    } else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+        struct arch_svm_struct *svp = &hvp->u.svm;
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("  &svm: vmcb:%lx pa:"KDBF64" asid:"KDBF64"\n", svp, svp->vmcb,
+             svp->vmcb_pa, svp->asid_generation);
+#endif
+        kdbp("    msrpm:%p lnch_core:%x vmcb_sync:%x\n", svp->msrpm, 
+             svp->launch_core, svp->vmcb_in_sync);
+    }
+    kdbp("  cachemode:%x io: {state: %x data: "KDBFL"}\n", hvp->cache_mode,
+         hvp->hvm_io.io_state, hvp->hvm_io.io_data);
+    kdbp("  mmio: {gva: "KDBFL" gpfn: "KDBFL"}\n", hvp->hvm_io.mmio_gva,
+         hvp->hvm_io.mmio_gpfn);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* also look into arch_get_info_guest() to get context */
+static void
+kdb_print_uregs(struct cpu_user_regs *regs)
+{
+#ifdef __x86_64__
+    kdbp("      rflags: %016lx   rip: %016lx\n", regs->rflags, regs->rip);
+    kdbp("         rax: %016lx   rbx: %016lx   rcx: %016lx\n",
+         regs->rax, regs->rbx, regs->rcx);
+    kdbp("         rdx: %016lx   rsi: %016lx   rdi: %016lx\n",
+         regs->rdx, regs->rsi, regs->rdi);
+    kdbp("         rbp: %016lx   rsp: %016lx    r8: %016lx\n",
+         regs->rbp, regs->rsp, regs->r8);
+    kdbp("          r9:  %016lx  r10: %016lx   r11: %016lx\n",
+         regs->r9,  regs->r10, regs->r11);
+    kdbp("         r12: %016lx   r13: %016lx   r14: %016lx\n",
+         regs->r12, regs->r13, regs->r14);
+    kdbp("         r15: %016lx\n", regs->r15);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+         "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%08lx entryvec:%08lx upcall_mask:%lx\n",
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#else
+    kdbp("      eflags: %016lx eip: 016lx\n", regs->eflags, regs->eip);
+    kdbp("      eax: %08x   ebx: %08x   ecx: %08x   edx: %08x\n",
+         regs->eax, regs->ebx, regs->ecx, regs->edx);
+    kdbp("      esi: %08x   edi: %08x   ebp: %08x   esp: %08x\n",
+         regs->esi, regs->edi, regs->ebp, regs->esp);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+     "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%04lx entryvec:%04lx upcall_mask:%lx\n", 
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#endif
+}
+
+#if XEN_SUBVERSION < 3             /* xen 3.1.x or xen 3.2.x */
+#ifdef CONFIG_COMPAT
+    #undef vcpu_info
+    #define vcpu_info(v, field)             \
+    (*(!has_32bit_shinfo((v)->domain) ?                                       \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->native.field : \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->compat.field))
+
+    #undef __shared_info
+    #define __shared_info(d, s, field)                      \
+    (*(!has_32bit_shinfo(d) ?                           \
+       (typeof(&(s)->compat.field))&(s)->native.field : \
+       (typeof(&(s)->compat.field))&(s)->compat.field))
+#endif
+#endif
+
+static void kdb_display_pv_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct pv_vcpu *gp = &vp->arch.pv_vcpu;
+
+    kdbp("      GDT_VIRT_START(vcpu): %lx\n", GDT_VIRT_START(vp));
+    kdbp("      GDT: entries:0x%lx  frames:\n", gp->gdt_ents);
+    for (i=0; i < 16; i=i+4) 
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->gdt_frames[i], 
+             gp->gdt_frames[i+1], gp->gdt_frames[i+2],gp->gdt_frames[i+3]);
+    
+    kdbp("      trap_ctxt:%lx kernel_ss:%lx kernel_sp:%lx\n", gp->trap_ctxt,
+         gp->kernel_ss, gp->kernel_sp);
+    kdbp("      ctrlregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->ctrlreg[i], 
+             gp->ctrlreg[i+1], gp->ctrlreg[i+2], gp->ctrlreg[i+3]);
+#ifdef __x86_64__
+    kdbp("      callback:   event: %016lx   failsafe: %016lx\n", 
+         gp->event_callback_eip, gp->failsafe_callback_eip);
+    kdbp("      base: fs:0x%lx gskern:0x%lx gsuser:0x%lx\n", 
+         gp->fs_base, gp->gs_base_kernel, gp->gs_base_user);
+#else
+    kdbp("      callback:   event: %08lx:%08lx   failsafe: %08lx:%08lx\n", 
+         gp->event_callback_cs, gp->event_callback_eip, 
+         gp->failsafe_callback_cs, gp->failsafe_callback_eip);
+#endif
+    kdbp("    vcpu_info_mfn: %lx  iopl: %x\n", gp->vcpu_info_mfn, gp->iopl);
+    kdbp("\n");
+}
+
+/* Display one VCPU info */
+static void
+kdb_display_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct arch_vcpu *avp = &vp->arch;
+    struct paging_vcpu *pvp = &vp->arch.paging;
+    int domid = vp->domain->domain_id;
+
+    kdbp("\nVCPU:  vcpu-id:%d  vcpu-ptr:%p ", vp->vcpu_id, vp);
+    kdbp("  processor:%d domid:%d  domp:%p\n", vp->processor, domid,vp->domain);
+
+    if (domid == DOMID_IDLE) {
+        kdbp("    IDLE vcpu.\n");
+        return;
+    }
+    kdbp("  pause: flags:0x%016lx count:%x\n", vp->pause_flags, 
+         vp->pause_count.counter);
+    kdbp("  vcpu: initdone:%d running:%d\n", 
+         vp->is_initialised, vp->is_running);
+    kdbp("  mcepend:%d nmipend:%d shut: def:%d paused:%d\n", 
+         vp->mce_pending,  vp->nmi_pending, vp->defer_shutdown, 
+         vp->paused_for_shutdown);
+    kdbp("  &vcpu_info:%p : evtchn_upc_pend:%x _mask:%x\n",
+         vp->vcpu_info, vcpu_info(vp, evtchn_upcall_pending),
+         vcpu_info(vp, evtchn_upcall_mask));
+    kdbp("  evt_pend_sel:%lx poll_evtchn:%x ", 
+         *(unsigned long *)&vcpu_info(vp, evtchn_pending_sel), vp->poll_evtchn);
+    kdb_print_spin_lock("virq_lock:", &vp->virq_lock, "\n");
+    for (i=0; i < NR_VIRQS; i++)
+        if (vp->virq_to_evtchn[i] != 0)
+            kdbp("      virq:$%d port:$%d\n", i, vp->virq_to_evtchn[i]);
+
+    kdbp("  next:%p periodic: period:0x%lx last_event:0x%lx\n", 
+         vp->next_in_list, vp->periodic_period, vp->periodic_last_event);
+    kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:%p sched_priv:0x%p\n",
+         vp->cpu_affinity, vp->vcpu_dirty_cpumask, vp->sched_priv);
+    kdbp("  &runstate: %p state: %x (eg. RUNSTATE_running) guestptr:%p\n", 
+         &vp->runstate, vp->runstate.state, runstate_guest(vp));
+    kdbp("\n");
+    kdbp("  arch info: (%p)\n", &vp->arch);
+    kdbp("    guest_context: VGCF_ flags:%lx", 
+         vp->arch.vgc_flags); /* VGCF_in_kernel */
+    if (is_hvm_or_hyb_vcpu(vp))
+        kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
+    kdbp("\n");
+    kdb_print_uregs(&vp->arch.user_regs);
+    kdbp("      debugregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", avp->debugreg[i], 
+             avp->debugreg[i+1], avp->debugreg[i+2], avp->debugreg[i+3]);
+    kdb_display_pv_vcpu(vp);
+
+    kdbp("    TF_flags: %016lx  guest_table: %016lx cr3:%016lx\n", 
+         vp->arch.flags, vp->arch.guest_table.pfn, avp->cr3); 
+    kdbp("    paging: \n");
+    kdbp("      vtlb:%p\n", &pvp->vtlb);
+    kdbp("      &pg_mode:%p gstlevels:%d &shadow:%p shlevels:%d\n",
+         pvp->mode, pvp->mode->guest_levels, &pvp->mode->shadow,
+         pvp->mode->shadow.shadow_levels);
+    kdbp("      shadow_vcpu:\n");
+    kdbp("        guest_vtable:%p last em_mfn:"KDBFL"\n",
+         pvp->shadow.guest_vtable, pvp->shadow.last_emulated_mfn);
+#if CONFIG_PAGING_LEVELS >= 3
+    kdbp("         l3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.l3table[3].l3, pvp->shadow.l3table[2].l3, 
+     pvp->shadow.l3table[1].l3, pvp->shadow.l3table[0].l3);
+    kdbp("        gl3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.gl3e[3].l3, pvp->shadow.gl3e[2].l3, 
+     pvp->shadow.gl3e[1].l3, pvp->shadow.gl3e[0].l3);
+#endif
+    kdbp("  gdbsx_vcpu_event:%x\n", vp->arch.gdbsx_vcpu_event);
+}
+
+/* 
+ * FUNCTION: Dispaly (current) VCPU/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpu(void)
+{
+    kdbp("vcpu [vcpu-ptr] : display current/vcpu-ptr vcpu info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *v = current;
+
+    if (argc > 2 || (argc > 1 && *argv[1] == '?'))
+        kdb_usgf_vcpu();
+    else if (argc <= 1)
+        kdb_display_vcpu(v);
+    else if (kdb_str2ulong(argv[1], (ulong *)&v) && kdb_vcpu_valid(v))
+        kdb_display_vcpu(v);
+    else 
+        kdbp("Invalid usage/argument:%s v:%lx\n", argv[1], (long)v);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* from paging_dump_domain_info() */
+static void kdb_pr_dom_pg_modes(struct domain *d)
+{
+    if (paging_mode_enabled(d)) {
+        kdbp(" paging mode enabled");
+        if ( paging_mode_shadow(d) )
+            kdbp(" shadow(PG_SH_enable)");
+        if ( paging_mode_hap(d) )
+            kdbp(" hap(PG_HAP_enable) ");
+        if ( paging_mode_refcounts(d) )
+            kdbp(" refcounts(PG_refcounts) ");
+        if ( paging_mode_log_dirty(d) )
+            kdbp(" log_dirty(PG_log_dirty) ");
+        if ( paging_mode_translate(d) )
+            kdbp(" translate(PG_translate) ");
+        if ( paging_mode_external(d) )
+            kdbp(" external(PG_external) ");
+    } else
+        kdbp(" disabled");
+    kdbp("\n");
+}
+
+/* print event channels info for a given domain 
+ * NOTE: very confusing, port and event channel refer to the same thing. evtchn
+ * is arry of pointers to a bucket of pointers to 128 struct evtchn{}. while
+ * 64bit xen can handle 4096 max channels, a 32bit guest is limited to 1024 */
+static void noinline kdb_print_dom_eventinfo(struct domain *dp)
+{
+    uint chn;
+
+    kdbp("\n");
+    kdbp("  Evt: MAX_EVTCHNS:$%d ptr:%p pollmsk:%08lx ",
+         MAX_EVTCHNS(dp), dp->evtchn, dp->poll_mask[0]);
+    kdb_print_spin_lock("lk:", &dp->event_lock, "\n");
+    kdbp("    &evtchn_pending:%p &evtchn_mask:%p\n", 
+         shared_info(dp, evtchn_pending), shared_info(dp, evtchn_mask));
+
+    kdbp("   Channels info: (everything is in decimal):\n");
+    for (chn=0; chn < MAX_EVTCHNS(dp); chn++ ) {
+        struct evtchn *bktp = dp->evtchn[chn/EVTCHNS_PER_BUCKET];
+        struct evtchn *chnp = &bktp[chn & (EVTCHNS_PER_BUCKET-1)];
+        char pbit = test_bit(chn, &shared_info(dp, evtchn_pending)) ? 'Y' : 'N';
+        char mbit = test_bit(chn, &shared_info(dp, evtchn_mask)) ? 'Y' : 'N';
+
+        if (bktp==NULL || chnp->state==ECS_FREE)
+            continue;
+
+        kdbp("    chn:%4u st:%d _xen=%d _vcpu_id:%2d ", chn, chnp->state,
+             chnp->xen_consumer, chnp->notify_vcpu_id);
+        if (chnp->state == ECS_UNBOUND)
+            kdbp(" rem-domid:%d", chnp->u.unbound.remote_domid);
+        else if (chnp->state == ECS_INTERDOMAIN)
+            kdbp(" rem-port:%d rem-dom:%d", chnp->u.interdomain.remote_port,
+                 chnp->u.interdomain.remote_dom->domain_id);
+        else if (chnp->state == ECS_PIRQ)
+            kdbp(" pirq:%d", chnp->u.pirq);
+        else if (chnp->state == ECS_VIRQ)
+            kdbp(" virq:%d", chnp->u.virq);
+
+        kdbp("  pend:%c mask:%c\n", pbit, mbit);
+    }
+#if 0
+    kdbp("pirq to evtchn mapping (pirq:evtchn) (all decimal):\n");
+    for (i=0; i < dp->nr_pirqs; i ++)
+        if (dp->pirq_to_evtchn[i])
+            kdbp("(%d:%d) ", i, dp->pirq_to_evtchn[i]);
+    kdbp("\n");
+#endif
+}
+
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    struct hvm_domain *hvp = &dp->arch.hvm_domain;
+
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+    if (hvp == NULL)
+        return;
+
+    if (hvp->irq.callback_via_type == HVMIRQ_callback_vector)
+        kdbp("    HVMIRQ_callback_vector: %x\n", hvp->irq.callback_via.vector);
+
+    if (!is_hvm_domain(dp))
+        return;
+
+    kdbp("    HVM PARAMS (all in hex):\n");
+    kdbp("\tioreq.page:%lx ioreq.va:%lx\n", hvp->ioreq.page, hvp->ioreq.va);
+    kdbp("\tbuf_ioreq.page:%lx ioreq.va:%lx\n", hvp->buf_ioreq.page, 
+         hvp->buf_ioreq.va);
+    kdbp("\tHVM_PARAM_CALLBACK_IRQ: %x\n", hvp->params[HVM_PARAM_CALLBACK_IRQ]);
+    kdbp("\tHVM_PARAM_STORE_PFN: %x\n", hvp->params[HVM_PARAM_STORE_PFN]);
+    kdbp("\tHVM_PARAM_STORE_EVTCHN: %x\n", hvp->params[HVM_PARAM_STORE_EVTCHN]);
+    kdbp("\tHVM_PARAM_PAE_ENABLED: %x\n", hvp->params[HVM_PARAM_PAE_ENABLED]);
+    kdbp("\tHVM_PARAM_IOREQ_PFN: %x\n", hvp->params[HVM_PARAM_IOREQ_PFN]);
+    kdbp("\tHVM_PARAM_BUFIOREQ_PFN: %x\n", hvp->params[HVM_PARAM_BUFIOREQ_PFN]);
+    kdbp("\tHVM_PARAM_VIRIDIAN: %x\n", hvp->params[HVM_PARAM_VIRIDIAN]);
+    kdbp("\tHVM_PARAM_TIMER_MODE: %x\n", hvp->params[HVM_PARAM_TIMER_MODE]);
+    kdbp("\tHVM_PARAM_HPET_ENABLED: %x\n", hvp->params[HVM_PARAM_HPET_ENABLED]);
+    kdbp("\tHVM_PARAM_IDENT_PT: %x\n", hvp->params[HVM_PARAM_IDENT_PT]);
+    kdbp("\tHVM_PARAM_DM_DOMAIN: %x\n", hvp->params[HVM_PARAM_DM_DOMAIN]);
+    kdbp("\tHVM_PARAM_ACPI_S_STATE: %x\n", hvp->params[HVM_PARAM_ACPI_S_STATE]);
+    kdbp("\tHVM_PARAM_VM86_TSS: %x\n", hvp->params[HVM_PARAM_VM86_TSS]);
+    kdbp("\tHVM_PARAM_VPT_ALIGN: %x\n", hvp->params[HVM_PARAM_VPT_ALIGN]);
+    kdbp("\tHVM_PARAM_CONSOLE_PFN: %x\n", hvp->params[HVM_PARAM_CONSOLE_PFN]);
+    kdbp("\tHVM_PARAM_CONSOLE_EVTCHN: %x\n", 
+         hvp->params[HVM_PARAM_CONSOLE_EVTCHN]);
+    kdbp("\tHVM_PARAM_ACPI_IOPORTS_LOCATION: %x\n", 
+         hvp->params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+    kdbp("\tHVM_PARAM_MEMORY_EVENT_SINGLE_STEP: %x\n", 
+         hvp->params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP]);
+}
+static void kdb_print_rangesets(struct domain *dp)
+{
+    int locked = spin_is_locked(&dp->rangesets_lock);
+
+    if (locked)
+        spin_unlock(&dp->rangesets_lock);
+    rangeset_domain_printk(dp);
+    if (locked)
+        spin_lock(&dp->rangesets_lock);
+}
+
+static void kdb_pr_vtsc_info(struct arch_domain *ap)
+{
+    kdbp("    VTSC info: tsc_mode:%x  vtsc:%x  vtsc_last:%016lx\n", 
+         ap->tsc_mode, ap->vtsc, ap->vtsc_last);
+    kdbp("        vtsc_offset:%016lx tsc_khz:%08lx incarnation:%x\n", 
+         ap->vtsc_offset, ap->vtsc_offset, ap->incarnation);
+    kdbp("        vtsc_kerncount:%016lx _usercount:%016lx\n",
+         ap->vtsc_kerncount, ap->vtsc_usercount);
+}
+
+/* display one domain info */
+static void
+kdb_display_dom(struct domain *dp)
+{
+    struct vcpu *vp;
+    int printed = 0;
+    struct grant_table *gp = dp->grant_table;
+    struct arch_domain *ap = &dp->arch;
+
+    kdbp("\nDOMAIN :    domid:0x%04x ptr:0x%p\n", dp->domain_id, dp);
+    if (dp->domain_id == DOMID_IDLE) {
+        kdbp("    IDLE domain.\n");
+        return;
+    }
+    if (dp->is_dying) {
+        kdbp("    domain is DYING.\n");
+        return;
+    }
+#if 0
+    kdb_print_spin_lock("  pgalk:", &dp->page_alloc_lock, "\n");
+    kdbp("  pglist:  0x%p 0x%p\n", dp->page_list.next,KDB_PGLLE(dp->page_list));
+    kdbp("  xpglist: 0x%p 0x%p\n", dp->xenpage_list.next, 
+         KDB_PGLLE(dp->xenpage_list));
+    kdbp("  next:0x%p hashnext:0x%p\n", 
+         dp->next_in_list, dp->next_in_hashbucket);
+#endif
+    kdbp("  PAGES: tot:0x%08x max:0x%08x xenheap:0x%08x\n", 
+         dp->tot_pages, dp->max_pages, dp->xenheap_pages);
+
+    kdb_print_rangesets(dp);
+    kdb_print_dom_eventinfo(dp);
+    kdbp("\n");
+    kdbp("  Grant table: gp:0x%p\n", gp);
+    if (gp) {
+        kdbp("    nr_frames:0x%08x shpp:0x%p active:0x%p\n",
+             gp->nr_grant_frames, gp->shared_raw, gp->active);
+        kdbp("    maptrk:0x%p maphd:0x%08x maplmt:0x%08x\n", 
+             gp->maptrack, gp->maptrack_head, gp->maptrack_limit);
+        kdbp("    mapcnt:");
+        kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
+    }
+    kdbp("  hvm:%d priv:%d need_iommu:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_privileged, dp->need_iommu,
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
+    kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
+    kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
+         dp->is_shut_down, dp->shutdown_code);
+    kdbp("  pausecnt:0x%08x vm_assist:0x"KDBFL" refcnt:0x%08x\n",
+         dp->pause_count.counter, dp->vm_assist, dp->refcnt.counter);
+    kdbp("  &domain_dirty_cpumask:%p\n", &dp->domain_dirty_cpumask); 
+
+    kdbp("  shared == vcpu_info[]: %p\n",  dp->shared_info); 
+    kdbp("    arch_shared: maxpfn: %lx pfn-mfn-frame-ll mfn: %lx\n", 
+         arch_get_max_pfn(dp), arch_get_pfn_to_mfn_frame_list_list(dp));
+    kdbp("\n");
+    kdbp("  arch_domain at : %p\n", ap);
+
+#ifdef CONFIG_X86_64
+    kdbp("    pt_pages:0x%p ", ap->mm_perdomain_pt_pages);
+    kdbp("    l2:0x%p l3:0x%p\n", ap->mm_perdomain_l2, ap->mm_perdomain_l3);
+#else
+    kdbp("    pt:0x%p ", ap->mm_perdomain_pt);
+#endif
+#ifdef CONFIG_X86_32
+    kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
+#endif
+    kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
+    kdb_pr_dom_pg_modes(dp);
+    kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
+         KDB_PGLLE(ap->p2m->pages));
+    kdbp("       max_mapped_pfn:"KDBFL, ap->p2m->max_mapped_pfn);
+#if XEN_SUBVERSION > 0 && XEN_VERSION == 4              /* xen 4.1 and above */
+    kdbp("  phys_table:%p\n", ap->p2m->phys_table.pfn);
+#else
+    kdbp("  phys_table.pfn:"KDBFL"\n", ap->phys_table.pfn);
+#endif
+    kdbp("    physaddr_bitsz:%d 32bit_pv:%d has_32bit_shinfo:%d\n", 
+         ap->physaddr_bitsize, ap->is_32bit_pv, ap->has_32bit_shinfo);
+    kdb_pr_vtsc_info(ap);
+    kdbp("  sched:0x%p  &handle:0x%p\n", dp->sched_priv, &dp->handle);
+    kdbp("  vcpu ptrs:\n   ");
+    for_each_vcpu(dp, vp) {
+        kdbp(" %d:%p", vp->vcpu_id, vp);
+        if (++printed % 4 == 0) kdbp("\n   ");
+    }
+    kdbp("\n");
+}
+
+/* 
+ * FUNCTION: Dispaly (current) domain/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dom(void)
+{
+    kdbp("dom [all|domid]: Display current/all/given domain/s\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dom(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int id;
+    struct domain *dp = current->domain;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dom();
+
+    if (argc > 1) {
+        for(dp=domain_list; dp; dp=dp->next_in_list)
+            if (kdb_str2deci(argv[1], &id) && dp->domain_id==id)
+                kdb_display_dom(dp);
+            else if (!strcmp(argv[1], "all")) 
+                kdb_display_dom(dp);
+    } else {
+        kdbp("Displaying current domain :\n");
+        kdb_display_dom(dp);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dirq(void)
+{
+    kdbp("dirq : dump irq bindings\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dirq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long irq, sz, offs, addr;
+    char buf[KSYM_NAME_LEN+1];
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dirq();
+
+#if XEN_VERSION < 4 && XEN_SUBVERSION < 5           /* xen 3.4.x or below */
+    kdbp("idx/irq#/status: all are in decimal\n");
+    kdbp("idx  irq#  status   action(handler name devid)\n");
+    for (irq=0; irq < NR_VECTORS; irq++) {
+        irq_desc_t  *dp = &irq_desc[irq];
+        if (!dp->action)
+            continue;
+        addr = (unsigned long)dp->action->handler;
+        kdbp("[%3ld]:irq:%3d st:%3d f:%s devnm:%s devid:0x%p\n",
+             i, vector_to_irq(irq), dp->status, (dp->status & IRQ_GUEST) ? 
+                            "GUEST IRQ" : symbols_lookup(addr, &sz, &offs, buf),
+             dp->action->name, dp->action->dev_id);
+    }
+#else
+    kdbp("irq_desc[]:%p nr_irqs: $%d nr_irqs_gsi: $%d\n", irq_desc, nr_irqs, 
+          nr_irqs_gsi);
+    kdbp("irq/vec#/status: in decimal. affinity in hex, not bitmap\n");
+    kdbp("irq-- vec sta function----------- name---- type--------- ");
+    kdbp("aff devid------------\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        void *devidp;
+        const char *symp, *nmp;
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+
+        if (!dp->handler || dp->handler==&no_irq_type || dp->status & IRQ_GUEST)
+            continue;
+
+        addr = dp->action ? (unsigned long)dp->action->handler : 0;
+        symp = addr ? symbols_lookup(addr, &sz, &offs, buf) : "n/a ";
+        nmp = addr ? dp->action->name : "n/a ";
+        devidp = addr ? dp->action->dev_id : NULL;
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %03d %03d %-19s %-8s %-13s %3s 0x%p\n", irq, archp->vector,
+             dp->status, symp, nmp, dp->handler->typename, affstr, devidp);
+    }
+    kdb_prnt_guest_mapped_irqs();
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+kdb_prnt_vec_irq_table(int cpu)
+{
+    int i,j, *tbl = per_cpu(vector_irq, cpu);
+
+    kdbp("CPU %d : ", cpu);
+    for (i=0, j=0; i < NR_VECTORS; i++)
+        if (tbl[i] != -1) {
+            kdbp("(%3d:%3d) ", i, tbl[i]);
+            if (!(++j % 5))
+                kdbp("\n        ");
+        }
+    kdbp("\n");
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dvit(void)
+{
+    kdbp("dvit [cpu|all]: dump (per cpu)vector irq table\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvit(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu, ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvit();
+    
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all")) 
+            cpu = -1;
+        else if (!kdb_str2deci(argv[1], &cpu)) {
+            kdbp("Invalid cpu:%d\n", cpu);
+            return kdb_usgf_dvit();
+        }
+    } else
+        cpu = ccpu;
+
+    kdbp("Per CPU vector irq table pairs (vector:irq) (all decimals):\n");
+    if (cpu != -1) 
+        kdb_prnt_vec_irq_table(cpu);
+    else
+        for_each_online_cpu(cpu) 
+            kdb_prnt_vec_irq_table(cpu);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* do vmexit on all cpu's so intel VMCS can be dumped */
+static kdb_cpu_cmd_t 
+kdb_all_cpu_flush_vmcs(void)
+{
+    int cpu, ccpu = smp_processor_id();
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdb_curr_cpu_flush_vmcs();
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE){  /* hung cpu */
+                kdbp("Skipping (hung?) cpu %d\n", cpu);
+                continue;
+            }
+            kdb_cpu_cmd[cpu] = KDB_CPU_DO_VMEXIT;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_DO_VMEXIT);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display VMCS or VMCB */
+static kdb_cpu_cmd_t
+kdb_usgf_dvmc(void)
+{
+    kdbp("dvmc [domid][vcpuid] : Dump vmcs/vmcb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvmc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid = 0;  /* unsigned type don't like -1 */
+    int vcpuid = -1;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvmc();
+
+    if (argc > 1) { 
+        if (!kdb_str2domid(argv[1], &domid, 1))
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2 && !kdb_str2deci(argv[2], &vcpuid)) {
+        kdbp("Bad vcpuid: 0x%x\n", vcpuid);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        kdb_all_cpu_flush_vmcs();
+        kdb_dump_vmcs(domid, (int)vcpuid);
+    } else {
+        kdb_dump_vmcb(domid, (int)vcpuid);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_mmio(void)
+{
+    kdbp("mmio: dump mmio related info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmio(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmio();
+
+    kdbp("r/o mmio ranges:\n");
+    rangeset_printk(mmio_ro_ranges);
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump timer/timers queues */
+static kdb_cpu_cmd_t
+kdb_usgf_dtrq(void)
+{
+    kdbp("dtrq: dump timer queues on all cpus\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dtrq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dtrq();
+
+    kdb_dump_timer_queues();
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct idte {
+    uint16_t offs0_15;
+    uint16_t selector;
+    uint16_t meta;
+    uint16_t offs16_31;
+    uint32_t offs32_63;
+    uint32_t resvd;
+};
+
+#ifdef __x86_64__
+static void
+kdb_print_idte(int num, struct idte *idtp) 
+{
+    uint16_t mta = idtp->meta;
+    char dpl = ((mta & 0x6000) >> 13);
+    char present = ((mta &0x8000) >> 15);
+    int tval = ((mta &0x300) >> 8);
+    char *type = (tval == 1) ? "Task" : ((tval== 2) ? "Intr" : "Trap");
+    domid_t domid = idtp->selector==__HYPERVISOR_CS64 ? DOMID_IDLE :
+                    current->domain->domain_id;
+    uint64_t addr = idtp->offs0_15 | ((uint64_t)idtp->offs16_31 << 16) | 
+                    ((uint64_t)idtp->offs32_63 << 32);
+
+    kdbp("[%03d]: %s %x  %x %04x:%016lx ", num, type, dpl, present,
+         idtp->selector, addr); 
+    kdb_prnt_addr2sym(domid, addr, "\n");
+}
+
+/* Dump 64bit idt table currently on this cpu. Intel Vol 3 section 5.14.1 */
+static kdb_cpu_cmd_t
+kdb_usgf_didt(void)
+{
+    kdbp("didt : dump IDT table on the current cpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i;
+    struct idte *idtp = (struct idte *)idt_tables[smp_processor_id()];
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_didt();
+
+    kdbp("IDT at:%p\n", idtp);
+    kdbp("idt#  Type DPL P addr (all hex except idt#)\n", idtp);
+    for (i=0; i < 256; i++, idtp++) 
+        kdb_print_idte(i, idtp);
+    return KDB_CPU_MAIN_KDB;
+}
+#else
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbp("kdb: Please implement me in 32bit hypervisor\n");
+    return KDB_CPU_MAIN_KDB;
+}
+#endif
+
+struct gdte {             /* same for TSS and LDT */
+    ulong limit0:16;
+    ulong base0:24;       /* linear address base, not pa */
+    ulong acctype:4;      /* Type: access rights */
+    ulong S:1;            /* S: 0 = system, 1 = code/data */
+    ulong DPL:2;          /* DPL */
+    ulong P:1;            /* P: Segment Present */
+    ulong limit1:4;
+    ulong AVL:1;          /* AVL: avail for use by system software */
+    ulong L:1;            /* L: 64bit code segment */
+    ulong DB:1;           /* D/B */
+    ulong G:1;            /* G: granularity */
+    ulong base1:8;        /* linear address base, not pa */
+};
+
+union gdte_u {
+    struct gdte gdte;
+    u64 gval;
+};
+
+struct call_gdte {
+    unsigned short offs0:16;
+    unsigned short sel:16;
+    unsigned short misc0:16;
+    unsigned short offs1:16;
+};
+
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
+union sgdte_u {
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
+    u64 sgval;
+};
+
+/* return binary form of a hex in string : max 4 chars 0000 to 1111 */
+static char *kdb_ret_acctype(uint acctype)
+{
+    static char buf[16];
+    char *p = buf;
+    int i;
+
+    if (acctype > 0xf) {
+        buf[0] = buf[1] = buf[2] = buf[3] = '?';
+        buf[5] = '\n';
+        return buf;
+    }
+    for (i=0; i < 4; i++, p++, acctype=acctype>>1)
+        *p = (acctype & 0x1) ? '1' : '0';
+
+    return buf;
+}
+
+/* Display GDT table. IA-32e mode is assumded. */
+/* first display non system descriptors then display system descriptors */
+static kdb_cpu_cmd_t
+kdb_usgf_dgdt(void)
+{
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
+         "given vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dgdt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    union gdte_u u1;
+    ulong start_addr, end_addr, taddr=0;
+    domid_t domid = DOMID_IDLE;
+    int idx;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dgdt();
+
+    if (argc > 1) {
+        if (argc != 3)
+            return kdb_usgf_dgdt();
+
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
+        } else {
+            kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
+            return kdb_usgf_dgdt();
+        }
+    } else {
+        __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
+    }
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
+    kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
+         "--Base Addr ----  Limit\n");
+    kdbp("                              Type\n");
+
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+            continue;
+
+        if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
+            continue;               /* what an effin x86 mess */
+
+        idx = (taddr - start_addr) / 8;
+        if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
+            taddr += sizeof(ulong);
+            continue;
+        }
+        kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
+             u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
+             (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
+             u1.gdte.limit0 | (u1.gdte.limit1<<16));
+    }
+
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
+        uint acctype;
+        u64 upper, addr64=0;
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
+            u1.gval == 0 || u1.gdte.S == 1) {
+            continue;
+        }
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+            kdbp("Could not read upper 8 bytes of system desc\n");
+            upper = 0;
+        }
+        acctype = u1.gdte.acctype;
+        if (acctype != 2 && acctype != 9 && acctype != 11 && acctype !=12 &&
+            acctype != 14 && acctype != 15)
+            continue;
+
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
+
+        /* Vol 3A: table: 3-2  page: 3-19 */
+        if (acctype == 2) {
+            kdbp("LDT gate (0010)\n");
+        }
+        else if (acctype == 9) {
+            kdbp("TSS avail gate(1001)\n");
+        }
+        else if (acctype == 11) {
+            kdbp("TSS busy gate(1011)\n");
+        }
+        else if (acctype == 12) {
+            kdbp("CALL gate (1100)\n");
+        }
+        else if (acctype == 14) {
+            kdbp("IDT gate (1110)\n");
+        }
+        else if (acctype == 15) {
+            kdbp("Trap gate (1111)\n"); 
+        }
+
+        if (acctype == 2 || acctype == 9 || acctype == 11) {
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display scheduler basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_sched(void)
+{
+    kdbp("sched: show schedular info and run queues\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sched(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_sched();
+
+    kdb_print_sched_info();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display MMU basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_mmu(void)
+{
+    kdbp("mmu: print basic MMU info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmu();
+
+    kdbp("MMU Info:\n");
+    kdbp("total  pages: %lx\n", total_pages);
+    kdbp("max page/mfn: %lx\n", max_page);
+    kdbp("frame_table:  %p\n", frame_table);
+    kdbp("DIRECTMAP_VIRT_START:  %lx\n", DIRECTMAP_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_START: %lx\n", HYPERVISOR_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_END:   %lx\n", HYPERVISOR_VIRT_END);
+    kdbp("RO_MPT_VIRT_START:     %lx\n", RO_MPT_VIRT_START);
+    kdbp("PERDOMAIN_VIRT_START:  %lx\n", PERDOMAIN_VIRT_START);
+    kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
+    kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
+         (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
+
+    kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
+    kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
+    kdbp("LAST_RESERVED_GDT_ENTRY: %lx\n", (ulong)LAST_RESERVED_GDT_ENTRY);
+    kdbp("  Per cpu non-compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(gdt_table, cpu));
+    }
+    kdbp("  Per cpu compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
+    }
+    kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
+#ifdef USER_MAPPINGS_ARE_GLOBAL
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
+#else
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
+#endif
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* for HVM/HYB guests, go thru EPT. For PV guest we need to go to the btree. 
+ * btree: pfn_to_mfn_frame_list_list is root that points (has mfns of) upto 16
+ * pages (call 'em l2 nodes) that contain mfns of guest p2m table pages 
+ * NOTE: num of entries in a p2m page is same as num of entries in l2 node */
+static noinline ulong
+kdb_gpfn2mfn(struct domain *dp, ulong gpfn, p2m_type_t *typep) 
+{
+    int idx;
+
+    if ( !paging_mode_translate(dp) ) {
+        mfn_t *mfn_va, mfn = arch_get_pfn_to_mfn_frame_list_list(dp);
+        int g_longsz = kdb_guest_bitness(dp->domain_id)/8;
+        int entries_per_pg = PAGE_SIZE/g_longsz;
+        const int shift = get_count_order(entries_per_pg);
+
+	if ( !mfn_valid(mfn) ) {
+	    kdbp("Invalid frame_list_list mfn:%lx for non-xlate guest\n", mfn);
+	    return INVALID_MFN;
+	}
+
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn >> 2*shift;     /* index in root page/node */
+        if (idx > 15) {
+            kdbp("gpfn:%lx idx:%x not in frame list limit of z16\n", gpfn, idx);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        if (mfn==0) {
+            kdbp("No mfn for idx:%d for gpfn:%lx in root pg\n", idx, gpfn);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn_va = map_domain_page(mfn);
+        KDBGP1("p2m: idx:%x fll:%lx mfn of 2nd lvl page:%lx\n", idx,
+               arch_get_pfn_to_mfn_frame_list_list(dp), mfn);
+
+        idx = (gpfn>>shift) & ((1<<shift)-1);     /* idx in l2 node */
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+        if (mfn == 0) {
+            kdbp("No mfn entry at:%x in 2nd lvl pg for gpfn:%lx\n", idx, gpfn);
+            return INVALID_MFN;
+        }
+        KDBGP1("p2m: idx:%x  mfn of p2m page:%lx\n", idx, mfn); 
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn & ((1<<shift)-1);
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+
+	*typep = -1;
+        return mfn;
+    } else
+        return get_gfn_query(dp, gpfn, typep);
+
+    return INVALID_MFN;
+}
+
+/* given a pfn, find it's mfn */
+static kdb_cpu_cmd_t
+kdb_usgf_p2m(void)
+{
+    kdbp("p2m domid 0xgpfn : gpfn to mfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_p2m(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gpfn, mfn;
+    p2m_type_t p2mtype;
+
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
+        !kdb_str2ulong(argv[2], &gpfn)) {
+
+        return kdb_usgf_p2m();
+    }
+    mfn = kdb_gpfn2mfn(dp, gpfn, &p2mtype);
+    if ( paging_mode_translate(dp) )
+        kdbp("p2m[%lx] == %lx type:%d/0x%x\n", gpfn, mfn, p2mtype, p2mtype);
+    else 
+        kdbp("p2m[%lx] == %lx type:N/A(PV)\n", gpfn, mfn);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an mfn, lookup pfn in the MPT */
+static kdb_cpu_cmd_t
+kdb_usgf_m2p(void)
+{
+    kdbp("m2p 0xmfn: mfn to pfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_m2p(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    mfn_t mfn;
+    if (argc > 1 && kdb_str2ulong(argv[1], &mfn))
+        if (mfn_valid(mfn))
+            kdbp("mpt[%x] == %lx\n", mfn, machine_to_phys_mapping[mfn]);
+        else
+            kdbp("Invalid mfn:%lx\n", mfn);
+    else
+        kdb_usgf_m2p();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void 
+kdb_pr_pg_pgt_flds(unsigned long type_info)
+{
+    switch (type_info & PGT_type_mask) {
+        case (PGT_l1_page_table):
+            kdbp("    page is PGT_l1_page_table\n");
+            break;
+        case PGT_l2_page_table:
+            kdbp("    page is PGT_l2_page_table\n");
+            break;
+        case PGT_l3_page_table:
+            kdbp("    page is PGT_l3_page_table\n");
+            break;
+        case PGT_l4_page_table:
+            kdbp("    page is PGT_l4_page_table\n");
+            break;
+        case PGT_seg_desc_page:
+            kdbp("    page is seg desc page\n");
+            break;
+        case PGT_writable_page:
+            kdbp("    page is writable page\n");
+            break;
+        case PGT_shared_page:
+            kdbp("    page is shared page\n");
+            break;
+    }
+    if (type_info & PGT_pinned)
+        kdbp("    page is pinned\n");
+    if (type_info & PGT_validated)
+        kdbp("    page is validated\n");
+    if (type_info & PGT_pae_xen_l2)
+        kdbp("    page is PGT_pae_xen_l2\n");
+    if (type_info & PGT_partial)
+        kdbp("    page is PGT_partial\n");
+    if (type_info & PGT_locked)
+        kdbp("    page is PGT_locked\n");
+}
+
+static void
+kdb_pr_pg_pgc_flds(unsigned long count_info)
+{
+    if (count_info & PGC_allocated)
+        kdbp("  PGC_allocated");
+    if (count_info & PGC_xen_heap)
+        kdbp("  PGC_xen_heap");
+    if (count_info & PGC_page_table)
+        kdbp("  PGC_page_table");
+    if (count_info & PGC_broken)
+        kdbp("  PGC_broken");
+#if XEN_VERSION < 4                                 /* xen 3.x.x */
+    if (count_info & PGC_offlining)
+        kdbp("  PGC_offlining");
+    if (count_info & PGC_offlined)
+        kdbp("  PGC_offlined");
+#else
+    if (count_info & PGC_state_inuse)
+        kdbp("  PGC_inuse");
+    if (count_info & PGC_state_offlining)
+        kdbp("  PGC_state_offlining");
+    if (count_info & PGC_state_offlined)
+        kdbp("  PGC_state_offlined");
+    if (count_info & PGC_state_free)
+        kdbp("  PGC_state_free");
+#endif
+    kdbp("\n");
+}
+
+/* print struct page_info{} given ptr to it or an mfn
+ * NOTE: that given an mfn there seems no way of knowing how it's used, so
+ *       here we just print all info and let user decide what's applicable */
+static kdb_cpu_cmd_t
+kdb_usgf_dpage(void)
+{
+    kdbp("dpage mfn|page-ptr : Display struct page\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dpage(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long val;
+    struct page_info *pgp;
+    struct domain *dp;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dpage();
+
+    if ((kdb_str2ulong(argv[1], &val) == 0)      ||
+        (val <  (ulong)frame_table && !mfn_valid(val))) {
+
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdbp("Page Info:\n");
+    if (val <= (ulong)frame_table) {       /* arg is mfn */
+        pgp = mfn_to_page(val);
+        kdbp("  mfn: %lx page_info:%p\n", val, pgp);
+    } else {
+        pgp = (struct page_info *)val; /* arg is struct page{} */
+        if (pgp < frame_table || pgp >= frame_table+max_page) {
+            kdbp("Invalid page ptr. below/beyond max_page\n");
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdbp("  mfn: %lx page_info:%p\n", page_to_mfn(pgp), pgp);
+    } 
+    kdbp("  count_info: %016lx  (refcnt: %x)\n", pgp->count_info,
+         pgp->count_info & PGC_count_mask);
+#if XEN_VERSION > 3 || XEN_SUBVERSION > 3             /* xen 3.4.x or later */
+    kdb_pr_pg_pgc_flds(pgp->count_info);
+
+    kdbp("In use info:\n");
+    kdbp("  type_info:%016lx\n", pgp->u.inuse.type_info);
+    kdb_pr_pg_pgt_flds(pgp->u.inuse.type_info);
+    dp = page_get_owner(pgp);
+    kdbp("  domid:%d (pickled:%lx)\n", dp ? dp->domain_id : -1, 
+         pgp->v.inuse._domain);
+
+    kdbp("Shadow Info:\n");
+    kdbp("  type:%x pinned:%x count:%x\n", pgp->u.sh.type, pgp->u.sh.pinned,
+         pgp->u.sh.count);
+    kdbp("  back:%lx  shadow_flags:%x  next_shadow:%lx\n", pgp->v.sh.back,
+         pgp->shadow_flags, pgp->next_shadow);
+
+    kdbp("Free Info\n");
+    kdbp("  need_tlbflush:%d order:%d tlbflush_timestamp:%x\n",
+         pgp->u.free.need_tlbflush, pgp->v.free.order, 
+         pgp->tlbflush_timestamp);
+#else
+    if (pgp->count_info & PGC_allocated)            /* page allocated */
+        kdbp("  PGC_allocated");
+    if (pgp->count_info & PGC_page_table)           /* page table page */
+        kdbp("  PGC_page_table");
+    kdbp("\n");
+    kdbp("  page is %s xen heap page\n", is_xen_heap_page(pgp) ? "a":"NOT");
+    kdbp("  cacheattr:%x\n", (pgp->count_info>>PGC_cacheattr_base) & 7);
+    if (pgp->count_info & PGC_count_mask) {         /* page in use */
+        dp = pgp->u.inuse._domain;         /* pickled domain */
+        kdbp("  page is in use\n");
+        kdbp("    domid: %d  (pickled dom:%x)\n", 
+             dp ? (unpickle_domptr(dp))->domain_id : -1, dp);
+        kdbp("    type_info: %lx\n", pgp->u.inuse.type_info);
+        kdb_prt_pg_type(pgp->u.inuse.type_info);
+    } else {                                         /* page is free */
+        kdbp("  page is free\n");
+        kdbp("    order: %x\n", pgp->u.free.order);
+        kdbp("    cpumask: %lx\n", pgp->u.free.cpumask.bits);
+    }
+    kdbp("  tlbflush/shadow_flags: %lx\n", pgp->shadow_flags);
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display asked msr value */
+static kdb_cpu_cmd_t
+kdb_usgf_dmsr(void)
+{
+    kdbp("dmsr address : Display msr value\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dmsr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long addr, val;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dmsr();
+
+    if ((kdb_str2ulong(argv[1], &addr) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    rdmsrl(addr, val);
+    kdbp("msr: %lx  val:%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_cpuid(void)
+{
+    kdbp("cpuid eax : Display cpuid value returned in rax\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_cpuid(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long rax=0, rbx=0, rcx=0, rdx=0;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_cpuid();
+
+    if ((kdb_str2ulong(argv[1], &rax) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+#if 0
+    __asm__ __volatile__ (
+            /* "pushl %%rax  \n" */
+
+            "movl %0, %%rax  \n"
+            "cpuid           \n" 
+            : "=&a" (rax), "=b" (rbx), "=c" (rcx), "=d" (rdx)
+            : "0" (rax)
+            : "rax", "rbx", "rcx", "rdx", "memory");
+#endif
+    cpuid(rax, &rax, &rbx, &rcx, &rdx);
+    kdbp("rax: %016lx  rbx:%016lx rcx:%016lx rdx:%016lx\n", rax, rbx,
+         rcx, rdx);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_wept(void)
+{
+    kdbp("wept domid gfn: walk ept table for given domid and gfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_wept(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gfn;
+
+    if ((argc > 1 && *argv[1] == '?') || argc != 3)
+        return kdb_usgf_wept();
+    if ((dp=kdb_strdomid2ptr(argv[1], 1)) && kdb_str2ulong(argv[2], &gfn))
+        ept_walk_table(dp, gfn);
+    else
+        kdb_usgf_wept();
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Save symbols info for a guest, dom0 or other...
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_sym(void)
+{
+   kdbp("sym domid &kallsyms_names &kallsyms_addresses &kallsyms_num_syms\n");
+   kdbp("\t [&kallsyms_token_table] [&kallsyms_token_index]\n");
+   kdbp("\ttoken _table and _index MUST be specified for el5\n");
+   return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sym(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong namesp, addrap, nump, toktblp, tokidxp;
+    domid_t domid;
+
+    if (argc < 5) {
+        return kdb_usgf_sym();
+    }
+    toktblp = tokidxp = 0;     /* optional parameters */
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &namesp)   &&
+        kdb_str2ulong(argv[3], &addrap)   &&
+        kdb_str2ulong(argv[4], &nump)     && 
+        (argc==5 || (argc==7 && kdb_str2ulong(argv[5], &toktblp) &&
+                                kdb_str2ulong(argv[6], &tokidxp)))) {
+
+        kdb_sav_dom_syminfo(domid, namesp, addrap,nump,toktblp,tokidxp);
+    } else
+        kdb_usgf_sym();
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* mods is the dumb ass &modules. modules is struct {nxt, prev}, and not ptr */
+static void
+kdb_dump_linux_modules(domid_t domid, ulong mods, uint nxtoffs, uint nmoffs, 
+                       uint coreoffs)
+{
+    const int bufsz = 56;
+    char buf[bufsz];
+    uint64_t addr, addrval, *nxtptr, *modptr;
+    uint i, num = 8;
+
+    if (kdb_guest_bitness(domid) == 32)
+        num = 4;
+
+    /* first read modules{}.next ptr */
+    if (kdb_read_mem(mods, (kdbbyt_t *)&nxtptr, num, domid) != num) {
+        kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+        return;
+    }
+
+    KDBGP("mods:%p nxtptr:%p nmoffs:%x coreoffs:%x\n", (void *)mods, nxtptr,
+          nmoffs, coreoffs);
+
+    while ((uint64_t)nxtptr != mods) {
+
+        modptr = (uint64_t *) ((ulong)nxtptr - nxtoffs);
+
+        addr = (ulong)modptr + coreoffs;
+        if (kdb_read_mem(addr, (kdbbyt_t *)&addrval, num, domid) != num) {
+            kdbp("ERROR: Could not read mod addr at :%p\n", (void *)addr);
+            return;
+        }
+
+        KDBGP("modptr:%p addr:%p\n", modptr, (void *)addr);
+        addr = (ulong)modptr + nmoffs;
+        i=0;
+        do {
+            if (kdb_read_mem(addr, (kdbbyt_t *)&buf[i], 1, domid) != 1) {
+                kdbp("ERROR:Could not read name ch at addr:%p\n", (void *)addr);
+                return;
+            }
+            addr++;
+        } while (buf[i] && i++ < bufsz);
+        buf[bufsz-1] = '\0';
+
+        kdbp("%016lx %016lx %s\n", modptr, addrval, buf);
+
+        if (kdb_read_mem((ulong)nxtptr, (kdbbyt_t *)&nxtptr, num, domid)!=num) {
+            kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+            return;
+        }
+        KDBGP("nxtptr:%p addr:%p\n", nxtptr, (void *)addr);
+    } 
+}
+
+/* Display modules loaded in linux guest */
+static kdb_cpu_cmd_t
+kdb_usgf_mod(void)
+{
+   kdbp("mod domid &modules next-offs name-offs module_core-offs\n");
+   kdbp("\twhere next-offs: &((struct module *)0)->list.next\n");
+   kdbp("\tname-offs: &((struct module *)0)->name etc..\n");
+   kdbp("\tDisplays all loaded modules in the linux guest\n");
+   kdbp("\tEg: mod 0 ffffffff80302780 8 0x18 0x178\n");
+
+   return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_cmdf_mod(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong mods, nxtoffs, nmoffs, coreoffs;
+    domid_t domid;
+
+    if (argc < 6) {
+        return kdb_usgf_mod();
+    }
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &mods)     &&
+        kdb_str2ulong(argv[3], &nxtoffs)  &&
+        kdb_str2ulong(argv[4], &nmoffs)   &&
+        kdb_str2ulong(argv[5], &coreoffs)) {
+
+        kdbp("modptr address name\n");
+        kdb_dump_linux_modules(domid, mods, nxtoffs, nmoffs, coreoffs);
+    } else
+        kdb_usgf_mod();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* toggle kdb debug trace level */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbdbg(void)
+{
+    kdbp("kdbdbg : trace info to debug kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_kdbdbg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbdbg();
+
+    kdbdbg = (kdbdbg==3) ? 0 : (kdbdbg+1);
+    kdbp("kdbdbg set to:%d\n", kdbdbg);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_reboot(void)
+{
+    kdbp("reboot: reboot system\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_reboot(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_reboot();
+
+    machine_restart(500);
+    return KDB_CPU_MAIN_KDB;              /* not reached */
+}
+
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcon(void)
+{
+    kdbp("trcon: turn user added kdb tracing on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcon(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcon();
+
+    kdb_trcon = 1;
+    kdbp("kdb tracing is now on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcoff(void)
+{
+    kdbp("trcoff: turn user added kdb tracing off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcoff(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcoff();
+
+    kdb_trcon = 0;
+    kdbp("kdb tracing is now off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcz(void)
+{
+    kdbp("trcz : zero entire trace buffer\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcz(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcz();
+
+    kdb_trczero();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcp(void)
+{
+    kdbp("trcp : give hints to dump trace buffer via dw/dd command\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcp();
+
+    kdb_trcp();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* print some basic info, constants, etc.. */
+static kdb_cpu_cmd_t
+kdb_usgf_info(void)
+{
+    kdbp("info : display basic info, constants, etc..\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_info(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    struct cpuinfo_x86 *bcdp;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_info();
+
+    kdbp("Version: %d.%d.%s (%s@%s) %s\n", xen_major_version(), 
+         xen_minor_version(), xen_extra_version(), xen_compile_by(), 
+         xen_compile_domain(), xen_compile_date());
+    kdbp("__XEN_LATEST_INTERFACE_VERSION__ : 0x%x\n", 
+         __XEN_LATEST_INTERFACE_VERSION__);
+    kdbp("__XEN_INTERFACE_VERSION__: 0x%x\n", __XEN_INTERFACE_VERSION__);
+
+    bcdp = &boot_cpu_data;
+    kdbp("CPU: (all decimal)");
+        if (bcdp->x86_vendor == X86_VENDOR_AMD)
+            kdbp(" AMD");
+        else
+            kdbp(" INTEL");
+        kdbp(" family:%d model:%d\n", bcdp->x86, bcdp->x86_model);
+        kdbp("     vendor_id:%16s model_id:%64s\n", bcdp->x86_vendor_id,
+             bcdp->x86_model_id);
+        kdbp("     cpuidlvl:%d cache:sz:%d align:%d\n", bcdp->cpuid_level,
+             bcdp->x86_cache_size, bcdp->x86_cache_alignment);
+        kdbp("     power:%d cores: max:%d booted:%d siblings:%d apicid:%d\n",
+             bcdp->x86_power, bcdp->x86_max_cores, bcdp->booted_cores,
+             bcdp->x86_num_siblings, bcdp->apicid);
+        kdbp("     ");
+        if (cpu_has_apic)
+            kdbp("_apic");
+        if (cpu_has_sep)
+            kdbp("|_sep");
+        if (cpu_has_xmm3)
+            kdbp("|_xmm3");
+        if (cpu_has_ht)
+            kdbp("|_ht");
+        if (cpu_has_nx)
+            kdbp("|_nx");
+        if (cpu_has_clflush)
+            kdbp("|_clflush");
+        if (cpu_has_page1gb)
+            kdbp("|_page1gb");
+        if (cpu_has_ffxsr)
+            kdbp("|_ffxsr");
+        if (cpu_has_x2apic)
+            kdbp("|_x2apic");
+    kdbp("\n\n");
+    kdbp("CC:");
+#if defined(CONFIG_X86_64)
+        kdbp(" CONFIG_X86_64");
+#endif
+#if defined(CONFIG_COMPAT)
+        kdbp(" CONFIG_COMPAT");
+#endif
+#if defined(CONFIG_PAGING_ASSISTANCE)
+        kdbp(" CONFIG_PAGING_ASSISTANCE");
+#endif
+    kdbp("\n");
+    kdbp("cpu has following features:\n");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ? 
+         "X86_FEATURE_TSC_RELIABLE" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_CONSTANT_TSC)? "X86_FEATURE_CONSTANT_TSC":"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ? "X86_FEATURE_NONSTOP_TSC" :"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_RDTSCP) ?  "X86_FEATURE_RDTSCP" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_FXSR) ?  "X86_FEATURE_FXSR" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_CPUID_FAULTING) ?  
+         "X86_FEATURE_CPUID_FAULTING" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_PAGE1GB) ?  "X86_FEATURE_PAGE1GB" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_MWAIT) ?  "X86_FEATURE_MWAIT" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_X2APIC) ?  "X86_FEATURE_X2APIC":"");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_XSAVE) ?  "X86_FEATURE_XSAVE":"");
+    kdbp("\n");
+
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
+    kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
+    kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
+
+    kdbp("\nDomains and their vcpus:\n");
+    for_each_domain(dp) {
+        struct vcpu *vp;
+        int printed=0;
+        kdbp("  Domain: {id:%d 0x%x   ptr:%p%s}  VCPUs:\n", 
+             dp->domain_id, dp->domain_id, dp, dp->is_dying ? " DYING":"");
+        for(vp=dp->vcpu[0]; vp; vp = vp->next_in_list) {
+            kdbp("  {id:%d p:%p runstate:%d}", vp->vcpu_id, vp, 
+                 vp->runstate.state);
+            if (++printed % 2 == 0) kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_cur(void)
+{
+    kdbp("cur : display current domid and vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Checking for guest_mode() not feasible here. if dom0->hcall->bp in xen, 
+ * then g_m() will show xen, but vcpu is still dom0. hence just look at 
+ * current only */
+static kdb_cpu_cmd_t
+kdb_cmdf_cur(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t id = current->domain->domain_id;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cur();
+
+    kdbp("domid: %d{%p} %s vcpu:%d {%p} ", id, current->domain,
+         (id==DOMID_IDLE) ? "(IDLE)" : "", current->vcpu_id, current);
+
+    /* if (id != DOMID_IDLE) { */
+        if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+            u64 addr = -1;
+            __vmptrst(&addr);
+            kdbp(" VMCS:"KDBFL, addr);
+        }
+    /* } */
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* stub to quickly and easily add a new command */
+static kdb_cpu_cmd_t
+kdb_usgf_usr1(void)
+{
+    kdbp("usr1: add any arbitrary cmd using this in kdb_cmds.c\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_usr1(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_h(void)
+{
+    kdbp("h: display all commands. See kdb/README for more info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_h(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbtab_t *tbp;
+
+    kdbp(" - ccpu is current cpu \n");
+    kdbp(" - following are always in decimal:\n");
+    kdbp("     vcpu num, cpu num, domid\n");
+    kdbp(" - otherwise, almost all numbers are in hex (0x not needed)\n");
+    kdbp(" - output: $17 means decimal 17\n");
+    kdbp(" - domid 7fff($32767) refers to hypervisor\n");
+    kdbp(" - if no domid before function name, then it's hypervisor\n");
+    kdbp(" - earlykdb in xen grub line to break into kdb during boot\n");
+    kdbp(" - command ? will show the command usage\n");
+    kdbp("\n");
+
+    for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_usgf; tbp++)
+        (*tbp->kdb_cmd_usgf)();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ===================== cmd table initialization ========================== */
+void __init
+kdb_init_cmdtab(void)
+{
+  static kdbtab_t _kdb_cmd_table[] = {
+
+    {"info", kdb_cmdf_info, kdb_usgf_info, 1, KDB_REPEAT_NONE},
+    {"cur",  kdb_cmdf_cur, kdb_usgf_cur, 1, KDB_REPEAT_NONE},
+
+    {"f",  kdb_cmdf_f,  kdb_usgf_f,  1, KDB_REPEAT_NONE},
+    {"fg", kdb_cmdf_fg, kdb_usgf_fg, 1, KDB_REPEAT_NONE},
+
+    {"dw",  kdb_cmdf_dw,  kdb_usgf_dw,  1, KDB_REPEAT_NO_ARGS},
+    {"dd",  kdb_cmdf_dd,  kdb_usgf_dd,  1, KDB_REPEAT_NO_ARGS},
+    {"dwm", kdb_cmdf_dwm, kdb_usgf_dwm, 1, KDB_REPEAT_NO_ARGS},
+    {"ddm", kdb_cmdf_ddm, kdb_usgf_ddm, 1, KDB_REPEAT_NO_ARGS},
+    {"dr",  kdb_cmdf_dr,  kdb_usgf_dr,  1, KDB_REPEAT_NONE},
+    {"drg", kdb_cmdf_drg, kdb_usgf_drg, 1, KDB_REPEAT_NONE},
+
+    {"dis", kdb_cmdf_dis,  kdb_usgf_dis,  1, KDB_REPEAT_NO_ARGS},
+    {"dism",kdb_cmdf_dism, kdb_usgf_dism, 1, KDB_REPEAT_NO_ARGS},
+
+    {"mw", kdb_cmdf_mw, kdb_usgf_mw, 1, KDB_REPEAT_NONE},
+    {"md", kdb_cmdf_md, kdb_usgf_md, 1, KDB_REPEAT_NONE},
+    {"mr", kdb_cmdf_mr, kdb_usgf_mr, 1, KDB_REPEAT_NONE},
+
+    {"bc", kdb_cmdf_bc, kdb_usgf_bc, 0, KDB_REPEAT_NONE},
+    {"bp", kdb_cmdf_bp, kdb_usgf_bp, 1, KDB_REPEAT_NONE},
+    {"btp", kdb_cmdf_btp, kdb_usgf_btp, 1, KDB_REPEAT_NONE},
+
+    {"wp", kdb_cmdf_wp, kdb_usgf_wp, 1, KDB_REPEAT_NONE},
+    {"wc", kdb_cmdf_wc, kdb_usgf_wc, 0, KDB_REPEAT_NONE},
+
+    {"ni", kdb_cmdf_ni, kdb_usgf_ni, 0, KDB_REPEAT_NO_ARGS},
+    {"ss", kdb_cmdf_ss, kdb_usgf_ss, 1, KDB_REPEAT_NO_ARGS},
+    {"ssb",kdb_cmdf_ssb,kdb_usgf_ssb,0, KDB_REPEAT_NO_ARGS},
+    {"go", kdb_cmdf_go, kdb_usgf_go, 0, KDB_REPEAT_NONE},
+
+    {"cpu",kdb_cmdf_cpu, kdb_usgf_cpu, 1, KDB_REPEAT_NONE},
+    {"nmi",kdb_cmdf_nmi, kdb_usgf_nmi, 1, KDB_REPEAT_NONE},
+    {"percpu",kdb_cmdf_percpu, kdb_usgf_percpu, 1, KDB_REPEAT_NONE},
+
+    {"sym",  kdb_cmdf_sym,   kdb_usgf_sym,   1, KDB_REPEAT_NONE},
+    {"mod",  kdb_cmdf_mod,   kdb_usgf_mod,   1, KDB_REPEAT_NONE},
+
+    {"vcpuh",kdb_cmdf_vcpuh, kdb_usgf_vcpuh, 1, KDB_REPEAT_NONE},
+    {"vcpu", kdb_cmdf_vcpu,  kdb_usgf_vcpu,  1, KDB_REPEAT_NONE},
+    {"dom",  kdb_cmdf_dom,   kdb_usgf_dom,   1, KDB_REPEAT_NONE},
+
+    {"sched", kdb_cmdf_sched, kdb_usgf_sched, 1, KDB_REPEAT_NONE},
+    {"mmu",   kdb_cmdf_mmu,   kdb_usgf_mmu,   1, KDB_REPEAT_NONE},
+    {"p2m",   kdb_cmdf_p2m,   kdb_usgf_p2m,   1, KDB_REPEAT_NONE},
+    {"m2p",   kdb_cmdf_m2p,   kdb_usgf_m2p,   1, KDB_REPEAT_NONE},
+    {"dpage", kdb_cmdf_dpage, kdb_usgf_dpage, 1, KDB_REPEAT_NONE},
+    {"dmsr",  kdb_cmdf_dmsr,  kdb_usgf_dmsr, 1, KDB_REPEAT_NONE},
+    {"cpuid",  kdb_cmdf_cpuid,  kdb_usgf_cpuid, 1, KDB_REPEAT_NONE},
+    {"wept",  kdb_cmdf_wept,  kdb_usgf_wept, 1, KDB_REPEAT_NONE},
+
+    {"dtrq", kdb_cmdf_dtrq,  kdb_usgf_dtrq, 1, KDB_REPEAT_NONE},
+    {"didt", kdb_cmdf_didt,  kdb_usgf_didt, 1, KDB_REPEAT_NONE},
+    {"dgdt", kdb_cmdf_dgdt,  kdb_usgf_dgdt, 1, KDB_REPEAT_NONE},
+    {"dirq", kdb_cmdf_dirq,  kdb_usgf_dirq, 1, KDB_REPEAT_NONE},
+    {"dvit", kdb_cmdf_dvit,  kdb_usgf_dvit, 1, KDB_REPEAT_NONE},
+    {"dvmc", kdb_cmdf_dvmc,  kdb_usgf_dvmc, 1, KDB_REPEAT_NONE},
+    {"mmio", kdb_cmdf_mmio,  kdb_usgf_mmio, 1, KDB_REPEAT_NONE},
+
+    /* tracing related commands */
+    {"trcon", kdb_cmdf_trcon,  kdb_usgf_trcon,  0, KDB_REPEAT_NONE},
+    {"trcoff",kdb_cmdf_trcoff, kdb_usgf_trcoff, 0, KDB_REPEAT_NONE},
+    {"trcz",  kdb_cmdf_trcz,   kdb_usgf_trcz,   0, KDB_REPEAT_NONE},
+    {"trcp",  kdb_cmdf_trcp,   kdb_usgf_trcp,   1, KDB_REPEAT_NONE},
+
+    {"usr1",  kdb_cmdf_usr1,   kdb_usgf_usr1,   1, KDB_REPEAT_NONE},
+    {"kdbf",  kdb_cmdf_kdbf,   kdb_usgf_kdbf,   1, KDB_REPEAT_NONE},
+    {"kdbdbg",kdb_cmdf_kdbdbg, kdb_usgf_kdbdbg, 1, KDB_REPEAT_NONE},
+    {"reboot",kdb_cmdf_reboot, kdb_usgf_reboot, 1, KDB_REPEAT_NONE},
+    {"h",     kdb_cmdf_h,      kdb_usgf_h,      1, KDB_REPEAT_NONE},
+
+    {"", NULL, NULL, 0, 0},
+  };
+    kdb_cmd_tbl = _kdb_cmd_table;
+    return;
+}
diff -r 32034d1914a6 xen/kdb/kdb_io.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_io.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+#include "include/kdbinc.h"
+
+#define K_BACKSPACE  0x8                   /* ctrl-H */
+#define K_BACKSPACE1 0x7f                  /* ctrl-? */
+#define K_UNDERSCORE 0x5f
+#define K_CMD_BUFSZ  160
+#define K_CMD_MAXI   (K_CMD_BUFSZ - 1)     /* max index in buffer */
+
+#if 0        /* make a history array some day */
+#define K_UP_ARROW                         /* sequence : 1b 5b 41 ie, '\e[A' */
+#define K_DN_ARROW                         /* sequence : 1b 5b 42 ie, '\e[B' */
+#define K_NUM_HIST   32
+static int cursor;
+static char cmds_a[NUM_HIST][K_CMD_BUFSZ];
+#endif
+
+static char cmds_a[K_CMD_BUFSZ];
+
+
+static int
+kdb_key_valid(int key)
+{
+    /* note: isspace() is more than ' ', hence we don't use it here */
+    if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
+            return 1;
+    return 0;
+}
+
+/* display kdb prompt and read command from the console 
+ * RETURNS: a '\n' terminated command buffer */
+char *
+kdb_get_cmdline(char *prompt)
+{
+    #define K_BELL     0x7
+    #define K_CTRL_C   0x3
+
+    int key, i=0;
+
+    kdbp(prompt);
+    memset(cmds_a, 0, K_CMD_BUFSZ);
+    cmds_a[K_CMD_BUFSZ-1] = '\n';
+
+    do {
+        key = console_getc();
+        if (key == '\r') 
+            key = '\n';
+        if (key == K_BACKSPACE1) 
+            key = K_BACKSPACE;
+
+        if (key == K_CTRL_C || (i==K_CMD_MAXI && key != '\n')) {
+            console_putc('\n');
+            if (i >= K_CMD_MAXI) {
+                kdbp("KDB: cmd buffer overflow\n");
+                console_putc(K_BELL);
+            }
+            memset(cmds_a, 0, K_CMD_BUFSZ);
+            i = 0;
+            kdbp(prompt);
+            continue;
+        }
+        if (!kdb_key_valid(key)) {
+            console_putc(K_BELL);
+            continue;
+        }
+        if (key == K_BACKSPACE) {
+            if (i==0) {
+                console_putc(K_BELL);
+                continue;
+            } else 
+                cmds_a[--i] = '\0';
+                console_putc(K_BACKSPACE);
+                console_putc(' ');        /* erase character */
+        } else
+            cmds_a[i++] = key;
+
+        console_putc(key);
+
+    } while (key != '\n');
+
+    return cmds_a;
+}
+
+/*
+ * printk takes a lock, an NMI could come in after that, and another cpu may 
+ * spin. also, the console lock is forced unlock, so panic is been seen on 
+ * 8 way. hence, no printk() calls.
+ */
+static volatile int kdbp_gate = 0;
+void
+kdbp(const char *fmt, ...)
+{
+    static char buf[1024];
+    va_list args;
+    char *p;
+    int i=0;
+
+    while ((__cmpxchg(&kdbp_gate, 0,1, sizeof(kdbp_gate)) != 0) && i++<1000)
+        mdelay(10);
+
+    va_start(args, fmt);
+    (void)vsnprintf(buf, sizeof(buf), fmt, args);
+    va_end(args);
+
+    for (p=buf; *p != '\0'; p++)
+        console_putc(*p);
+    kdbp_gate = 0;
+}
+
+
+/*
+ * copy/read machine memory. 
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mmem(kdbma_t maddr, kdbbyt_t *dbuf, int len)
+{
+    ulong remain, orig=len;
+
+    while (len > 0) {
+        ulong pagecnt = min_t(long, PAGE_SIZE-(maddr&~PAGE_MASK), len);
+        char *va = map_domain_page(maddr >> PAGE_SHIFT);
+
+        va = va + (maddr & (PAGE_SIZE-1));        /* add page offset */
+        remain = __copy_from_user(dbuf, (void *)va, pagecnt);
+        KDBGP1("maddr:%x va:%p len:%x pagecnt:%x rem:%x\n", 
+               maddr, va, len, pagecnt, remain);
+        unmap_domain_page(va);
+        len = len  - (pagecnt - remain);
+        if (remain != 0)
+            break;
+        maddr += pagecnt;
+        dbuf += pagecnt;
+    }
+    return orig - len;
+}
+
+
+/*
+ * copy/read guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mem(kdbva_t saddr, kdbbyt_t *dbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(saddr, dbuf, len, domid, 0, 0));
+}
+
+/*
+ * write guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes written
+ */
+int
+kdb_write_mem(kdbva_t daddr, kdbbyt_t *sbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(daddr, sbuf, len, domid, 1, 0));
+}
diff -r 32034d1914a6 xen/kdb/kdbmain.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdbmain.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+static int kdbmain(kdb_reason_t, struct cpu_user_regs *);
+static int kdbmain_fatal(struct cpu_user_regs *, int);
+static const char *kdb_gettrapname(int);
+
+/* ======================== GLOBAL VARIABLES =============================== */
+/* All global variables used by KDB must be defined here only. Module specific
+ * static variables must be declared in respective modules.
+ */
+kdbtab_t *kdb_cmd_tbl;
+char kdb_prompt[32];
+
+volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+cpumask_t kdb_cpu_traps;           /* bit per cpu to tell which cpus hit int3 */
+
+#ifndef NDEBUG
+    #error KDB is not supported on debug xen. Turn debug off
+#endif
+
+volatile int kdb_init_cpu = -1;           /* initial kdb cpu */
+volatile int kdb_session_begun = 0;       /* active kdb session? */
+volatile int kdb_enabled = 1;             /* kdb enabled currently? */
+volatile int kdb_sys_crash = 0;           /* are we in crashed state? */
+volatile int kdbdbg = 0;                  /* to debug kdb itself */
+
+static volatile int kdb_trap_immed_reason = 0;   /* reason for immed trap */
+
+static cpumask_t kdb_fatal_cpumask;       /* which cpus in fatal path */
+
+/* return index of first bit set in val. if val is 0, retval is undefined */
+static inline unsigned int kdb_firstbit(unsigned long val)
+{
+    __asm__ ( "bsf %1,%0" : "=r" (val) : "r" (val), "0" (BITS_PER_LONG) );
+    return (unsigned int)val;
+}
+
+void noinline mukchk(unsigned long ul)
+{
+}
+
+static void 
+kdb_dbg_prnt_ctrps(char *label, int ccpu)
+{
+    int i;
+    if (!kdbdbg)
+        return;
+
+    if (label || *label)
+        kdbp("%s ", label);
+    if (ccpu != -1)
+        kdbp("ccpu:%d ", ccpu);
+    kdbp("cputrps:");
+    for (i=sizeof(kdb_cpu_traps)/sizeof(kdb_cpu_traps.bits[0]) - 1; i >=0; i--)
+        kdbp(" %lx", kdb_cpu_traps.bits[i]);
+    kdbp("\n");
+}
+
+/* 
+ * Hold this cpu. Don't disable until all CPUs in kdb to avoid IPI deadlock 
+ */
+static void
+kdb_hold_this_cpu(int ccpu, struct cpu_user_regs *regs)
+{
+    KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+    do {
+        for(; kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE; cpu_relax());
+        KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DISABLE) {
+            local_irq_disable();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DO_VMEXIT) {
+            kdb_curr_cpu_flush_vmcs();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_SHOWPC) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+    } while (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE);     /* No goto, eh! */
+    KDBGP1("un hold: ccpu:%d cmd:%d\n", ccpu, kdb_cpu_cmd[ccpu]);
+}
+
+/*
+ * Pause this cpu while one CPU does main kdb processing. If that CPU does
+ * a "cpu switch" to this cpu, this cpu will become the main kdb cpu. If the
+ * user next does single step of some sort, this function will be exited,
+ * and this cpu will come back into kdb via kdb_handle_trap_entry function.
+ */
+static void 
+kdb_pause_this_cpu(struct cpu_user_regs *regs, void *unused)
+{
+    kdbmain(KDB_REASON_PAUSE_IPI, regs);
+}
+
+/* pause other cpus via an IPI. Note, disabled CPUs can't receive IPIs until
+ * enabled */
+static void
+kdb_smp_pause_cpus(void)
+{
+    int cpu, wait_count = 0;
+    int ccpu = smp_processor_id();      /* current cpu */
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL) {
+            kdbp("KDB: won't pause cpu:%d, cmd[cpu]=%d\n",cpu,kdb_cpu_cmd[cpu]);
+            cpumask_clear_cpu(cpu, &cpumask);
+        }
+    KDBGP("ccpu:%d will pause cpus. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    on_selected_cpus(&cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0);
+#else
+    on_selected_cpus(cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0, 0);
+#endif
+    mdelay(300);                     /* wait a bit for other CPUs to stop */
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+                bummer = 1;
+        if (!bummer)
+            break;
+        kdbp("ccpu:%d trying to stop other cpus...\n", ccpu);
+        mdelay(100);  /* wait 100 ms */
+    };
+    for_each_cpu(cpu, &cpumask)          /* now check who is with us */
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+            kdbp("Bummer cpu %d not paused. ccpu:%d\n", cpu,ccpu);
+        else {
+            kdb_cpu_cmd[cpu] = KDB_CPU_DISABLE;  /* tell it to disable ints */
+            while (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE);
+        }
+}
+
+/* 
+ * Do once per kdb session:  A kdb session lasts from 
+ *    keybord/HWBP/SWBP till KDB_CPU_INSTALL_BP is done. Within a session,
+ *    user may do several cpu switches, single step, next instr,  etc..
+ *
+ * DO: 1. pause other cpus if they are not already. they would already be 
+ *        if we are in single step mode
+ *     2. watchdog_disable() 
+ *     3. uninstall all sw breakpoints so that user doesn't see them
+ */
+static void
+kdb_begin_session(void)
+{
+    if (!kdb_session_begun) {
+        kdb_session_begun = 1;
+        kdb_smp_pause_cpus();
+        local_irq_disable();
+        watchdog_disable();
+        kdb_uninstall_all_swbp();
+    }
+}
+
+int noinline mukid(void)
+{
+    return smp_processor_id();
+}
+
+static void
+kdb_smp_unpause_cpus(int ccpu)
+{
+    int cpu;
+
+    int wait_count = 0;
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+
+    KDBGP("kdb_smp_unpause_other_cpus(). ccpu:%d\n", ccpu);
+    for_each_cpu(cpu, &cpumask)
+        kdb_cpu_cmd[cpu] = KDB_CPU_QUIT;
+
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+                bummer = 1;
+            if (!bummer)
+                break;
+            mdelay(90);  /* wait 90 ms, 50 too short on large systems */
+    };
+    /* now make sure they are all in there */
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+            kdbp("KDB: cpu %d still paused (cmd==%d). ccpu:%d\n",
+                 cpu, kdb_cpu_cmd[cpu], ccpu);
+}
+
+/*
+ * End of KDB session. 
+ *   This is called at the very end. In case of multiple cpus hitting BPs
+ *   and sitting on a trap handlers, the last cpu to exit will call this.
+ *   - isnstall all sw breakpoints, and purge deleted ones from table.
+ *   - clear TF here also in case go is entered on a different cpu after switch
+ */
+static void
+kdb_end_session(int ccpu, struct cpu_user_regs *regs)
+{
+    ASSERT(!cpumask_empty(&kdb_cpu_traps));
+    ASSERT(kdb_session_begun);
+    kdb_install_all_swbp();
+    kdb_flush_swbp_table();
+    kdb_install_watchpoints();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    kdb_time_resume(1);
+    kdb_session_begun = 0;      /* before unpause for kdb_install_watchpoints */
+    kdb_smp_unpause_cpus(ccpu);
+    watchdog_enable();
+    KDBGP("end_session:ccpu:%d\n", ccpu);
+}
+volatile int mukwpprnt;
+unsigned long mukaddr1 = 0xffffffff81243ae7, mukaddr2 = 0xffffffff8100986e;
+/* 
+ * check if we entered kdb because of DB trap. If yes, then check if
+ * we caused it or someone else.
+ * RETURNS: 0 : not one of ours. hypervisor must handle it. 
+ *          1 : #DB for delayed sw bp install. 
+ *          2 : this cpu must stay in kdb.
+ */
+static noinline int
+kdb_check_dbtrap(kdb_reason_t *reasp, int ss_mode, struct cpu_user_regs *regs) 
+{
+    int rc = 2;
+    int ccpu = smp_processor_id();
+
+    /* DB excp caused by hw breakpoint or the TF flag. The TF flag is set
+     * by us for ss mode or to install breakpoints. In ss mode, none of the
+     * breakpoints are installed. Check to make sure we intended BP INSTALL
+     * so we don't do it on a spurious DB trap.
+     * check for kdb_cpu_traps here also, because each cpu sitting on a trap
+     * must execute the instruction without the BP before passing control
+     * to next cpu in kdb_cpu_traps.
+     */
+    if (*reasp == KDB_REASON_DBEXCP && !ss_mode) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP) {
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                *reasp = KDB_REASON_PAUSE_IPI;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
+                kdb_init_cpu = -1;
+            } else {
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            }
+        } else if (! kdb_check_watchpoints(regs)) {
+            rc = 0;                        /* hyp must handle it */
+        } else {
+            if (regs->rip==mukaddr1 || regs->rip==mukaddr2)
+            {
+                if (mukwpprnt)
+                    kdbp("MUK: ignoring wp:%lx\n", regs->rip);
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            } 
+        }
+    }
+    return rc;
+}
+
+/* 
+ * Misc processing on kdb entry like displaying PC, adjust IP for sw bp.... 
+ */
+static void
+kdb_main_entry_misc(kdb_reason_t reason, struct cpu_user_regs *regs, 
+                    int ccpu, int ss_mode, int enabled)
+{
+    if (reason == KDB_REASON_KEYBOARD)
+        kdbp("\nEnter kdb (cpu:%d reason:%d vcpu=%d domid:%d"
+             " eflg:0x%lx irqs:%d)\n", ccpu, reason, current->vcpu_id, 
+             current->domain->domain_id, regs->eflags, enabled);
+    else if (ss_mode)
+        KDBGP1("KDBG: KDB single step mode. ccpu:%d\n", ccpu);
+
+    if (reason == KDB_REASON_BPEXCP && !ss_mode) 
+        kdbp("Breakpoint on cpu %d at 0x%lx\n", ccpu, regs->KDBIP);
+
+    /* display the current PC and instruction at it */
+    if (reason != KDB_REASON_PAUSE_IPI)
+        kdb_display_pc(regs);
+    console_start_sync();
+}
+
+/* 
+ * The MAIN kdb function. All cpus go thru this. IRQ is enabled on entry because
+ * a cpu could hit a bp set in disabled code.
+ * IPI: Even the main cpu must enable in case another CPU is trying to IPI us.
+ *      That way, it would IPI us, then get out and be ready for our pause IPI.
+ * IRQs: The reason irqs enable/disable is scattered is because on a typical
+ *       system IPIs are constantly going on amongs CPUs in a set of any size. 
+ *       As a result,  to avoid deadlock, cpus have to loop enabled, until a 
+ *       quorum is established and the session has begun.
+ * Step: Intel Vol3B 18.3.1.4 : An external interrupt may be serviced upon
+ *       single step. Since, the likely ext timer_interrupt and 
+ *       apic_timer_interrupt dont' mess with time data structs, we are prob OK
+ *       leaving enabled.
+ * Time: Very messy. Most platform timers are readonly, so we can't stop time
+ *       in the debugger. We take the only resort, let the TSC and plt run as
+ *       normal, upon leaving, "attempt" to bring everybody to current time.
+ * kdbcputraps: bit per cpu. each cpu sets it bit in entry.S. The bit is 
+ *              reliable because upon traps, Ints are disabled. the bit is set
+ *              before Ints are enabled.
+ *
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+static int
+kdbmain(kdb_reason_t reason, struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();                /* current cpu */
+    int rc = 1, cmd = kdb_cpu_cmd[ccpu];
+    int ss_mode = (cmd == KDB_CPU_SS || cmd == KDB_CPU_NI);
+    int delayed_install = (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP);
+    int enabled = local_irq_is_enabled();
+
+    KDBGP("kdbmain:ccpu:%d rsn:%d eflgs:0x%lx cmd:%d initc:%d irqs:%d "
+          "regs:%lx IP:%lx ", ccpu, reason, regs->eflags, cmd, 
+          kdb_init_cpu, enabled, regs, regs->KDBIP);
+    kdb_dbg_prnt_ctrps("", -1);
+
+    if (!ss_mode && !delayed_install)    /* initial kdb enter */
+        local_irq_enable();              /* so we can receive IPI */
+
+    if (!ss_mode && ccpu != kdb_init_cpu && reason != KDB_REASON_PAUSE_IPI){
+        int sz = sizeof(kdb_init_cpu);
+        while (__cmpxchg(&kdb_init_cpu, -1, ccpu, sz) != -1)
+            for(; kdb_init_cpu != -1; cpu_relax());
+    }
+    if (kdb_session_begun)
+        local_irq_disable();             /* kdb always runs disabled */
+
+    if (reason == KDB_REASON_BPEXCP) {             /* INT 3 */
+        cpumask_clear_cpu(ccpu, &kdb_cpu_traps);   /* remove ourself */
+        rc = kdb_check_sw_bkpts(regs);
+        if (rc == 0) {               /* not one of ours. leave kdb */
+            kdb_init_cpu = -1;
+            goto out;
+        } else if (rc == 1) {        /* one of ours but deleted */
+            if (cpumask_empty(&kdb_cpu_traps)) {
+                kdb_end_session(ccpu,regs);     
+                kdb_init_cpu = -1;
+                goto out;
+            } else {                 
+                /* release another trap cpu, and put ourself in a pause mode */
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d cmd:%d rsn:%d atrpcpu:%d initcpu:%d\n", ccpu, 
+                      kdb_cpu_cmd[ccpu], reason, a_trap_cpu, kdb_init_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                reason = KDB_REASON_PAUSE_IPI;
+                kdb_init_cpu = -1;
+            }
+        } else if (rc == 2) {        /* one of ours but condition not met */
+                kdb_begin_session();
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+        }
+    }
+
+    /* following will take care of KDB_CPU_INSTALL_BP, and also release
+     * kdb_init_cpu. it should not be done twice */
+    if ((rc=kdb_check_dbtrap(&reason, ss_mode, regs)) == 0 || rc == 1) {
+        kdb_init_cpu = -1;       /* leaving kdb */
+        goto out;                /* rc properly set to 0 or 1 */
+    }
+    if (reason != KDB_REASON_PAUSE_IPI) {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+    } else
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB && !ss_mode)
+        kdb_begin_session(); 
+
+    kdb_main_entry_misc(reason, regs, ccpu, ss_mode, enabled);
+    /* note, one or more cpu switches may occur in between */
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+            if (ccpu != kdb_init_cpu) {
+                kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_GO;
+                kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+                continue;               /* for the pause guy */
+            }
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                /* execute current instruction without 0xcc */
+                kdb_dbg_prnt_ctrps("nempty:", ccpu);
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            }
+        }
+        if (kdb_cpu_cmd[ccpu] != KDB_CPU_PAUSE  && 
+            kdb_cpu_cmd[ccpu] != KDB_CPU_MAIN_KDB)
+                break;
+    }
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+        ASSERT(cpumask_empty(&kdb_cpu_traps));
+        if (kdb_swbp_exists()) {
+            if (reason == KDB_REASON_BPEXCP) {
+                /* do delayed install */
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            } 
+        }
+        kdb_end_session(ccpu, regs);
+        kdb_init_cpu = -1;
+    }
+out:
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_QUIT) {
+        KDBGP("ccpu:%d _quit IP: %lx\n", ccpu, regs->KDBIP);
+        if (! kdb_session_begun)
+            kdb_install_watchpoints();
+        kdb_time_resume(0);
+        kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    }
+
+    /* for ss and delayed install, TF is set. not much in EXT INT handlers*/
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_NI)
+        kdb_time_resume(1);
+    if (enabled)
+        local_irq_enable();
+
+    KDBGP("kdbmain:X:ccpu:%d rc:%d cmd:%d eflg:0x%lx initc:%d sesn:%d " 
+          "cs:%x irqs:%d ", ccpu, rc, kdb_cpu_cmd[ccpu], regs->eflags, 
+          kdb_init_cpu, kdb_session_begun, regs->cs, local_irq_is_enabled());
+    kdb_dbg_prnt_ctrps("", -1);
+    return (rc ? 1 : 0);
+}
+
+/* 
+ * kdb entry function when coming in via a keyboard
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+int
+kdb_keyboard(struct cpu_user_regs *regs)
+{
+    return kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+
+#if 0
+/*
+ * this function called when kdb session active and user presses ctrl\ again.
+ * the assumption is that the user typed ni/ss cmd, and it never got back into
+ * kdb, or the user is impatient. Either case, we just fake it that the SS did
+ * finish. Since, all other kdb cpus must be holding disabled, the interrupt
+ * would be on the CPU that did the ss/ni cmd
+ */
+void
+kdb_ssni_reenter(struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();
+    int ccmd = kdb_cpu_cmd[ccpu];
+
+    if(ccmd == KDB_CPU_SS || ccmd == KDB_CPU_INSTALL_BP)
+        kdbmain(KDB_REASON_DBEXCP, regs); 
+    else 
+        kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+#endif
+
+/* 
+ * All traps are routed thru here. We care about BP (#3) trap (INT 3) and
+ * the DB trap(#1) only. 
+ * returns: 0 kdb has nothing do with this trap
+ *          1 kdb handled this trap 
+ */
+int
+kdb_handle_trap_entry(int vector, struct cpu_user_regs *regs)
+{
+    int rc = 0;
+    int ccpu = smp_processor_id();
+
+    if (vector == TRAP_int3) {
+        rc = kdbmain(KDB_REASON_BPEXCP, regs);
+
+    } else if (vector == TRAP_debug) {
+        KDBGP("ccpu:%d trapdbg reas:%d\n", ccpu, kdb_trap_immed_reason);
+
+        if (kdb_trap_immed_reason == KDB_TRAP_FATAL) { 
+            KDBGP("kdbtrp:fatal ccpu:%d vec:%d\n", ccpu, vector);
+            rc = kdbmain_fatal(regs, vector);
+            BUG();                             /* no return */
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_KDBSTACK) {
+            kdb_trap_immed_reason = 0;         /* show kdb stack */
+            show_registers(regs);
+            show_stack(regs);
+            regs->eflags &= ~X86_EFLAGS_TF;
+            rc = 1;
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_NONFATAL) {
+            kdb_trap_immed_reason = 0;
+            rc = kdb_keyboard(regs);
+        } else {                         /* ss/ni/delayed install... */
+            if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                current->arch.hvm_vcpu.single_step = 0;
+            rc = kdbmain(KDB_REASON_DBEXCP, regs); 
+        }
+
+    } else if (vector == TRAP_nmi) {                   /* external nmi */
+        /* when nmi is pressed, it could go to one or more or all cpus
+         * depending on the hardware. Also, for now assume it's fatal */
+        KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
+        rc = kdbmain_fatal(regs, TRAP_nmi);
+    } 
+    return rc;
+}
+
+int
+kdb_trap_fatal(int vector, struct cpu_user_regs *regs)
+{
+    kdbmain_fatal(regs, vector);
+    return 0;
+}
+
+/* From smp_send_nmi_allbutself() in crash.c which is static */
+void
+kdb_nmi_pause_cpus(cpumask_t cpumask)
+{
+    int ccpu = smp_processor_id();
+    mdelay(200);
+    cpumask_complement(&cpumask, &cpumask);              /* flip bit map */
+    cpumask_and(&cpumask, &cpumask, &cpu_online_map);    /* remove extra bits */
+    cpumask_clear_cpu(ccpu, &cpumask);/* absolutely make sure we're not on it */
+
+    KDBGP("ccpu:%d nmi pause. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+    if ( !cpumask_empty(&cpumask) )
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+        send_IPI_mask(&cpumask, APIC_DM_NMI);
+#else
+        send_IPI_mask(cpumask, APIC_DM_NMI);
+#endif
+    mdelay(200);
+    KDBGP("ccpu:%d nmi pause done...\n", ccpu);
+}
+
+/* 
+ * Separate function from kdbmain to keep both within sanity levels.
+ */
+DEFINE_SPINLOCK(kdb_fatal_lk);
+static int
+kdbmain_fatal(struct cpu_user_regs *regs, int vector)
+{
+    int ccpu = smp_processor_id();
+
+    console_start_sync();
+
+    KDBGP("mainf:ccpu:%d vec:%d irq:%d\n", ccpu, vector,local_irq_is_enabled());
+    cpumask_set_cpu(ccpu, &kdb_fatal_cpumask);        /* uses LOCK_PREFIX */
+
+    if (spin_trylock(&kdb_fatal_lk)) {
+
+        kdbp("*** kdb (Fatal Error on cpu:%d vec:%d %s):\n", ccpu,
+             vector, kdb_gettrapname(vector));
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+        kdb_display_pc(regs);
+
+        watchdog_disable();     /* important */
+        kdb_sys_crash = 1;
+        kdb_session_begun = 0;  /* incase session already active */
+        local_irq_enable();
+        kdb_nmi_pause_cpus(kdb_fatal_cpumask);
+
+        kdb_clear_prev_cmd();   /* buffered CRs will repeat prev cmd */
+        kdb_session_begun = 1;  /* for kdb_hold_this_cpu() */
+        local_irq_disable();
+    } else {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+    }
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+#if 0
+        /* dump is the only way to exit in crashed state */
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DUMP)
+            kdb_do_dump(regs);
+#endif
+    }
+    return 0;
+}
+
+/* Mostly called in fatal cases. earlykdb calls non-fatal.
+ * kdb_trap_immed_reason is global, so allow only one cpu at a time. Also,
+ * multiple cpu may be crashing at the same time. We enable because if there
+ * is a bad hang, at least ctrl-\ will break into kdb. Also, we don't call
+ * call kdb_keyboard directly becaue we don't have the register context.
+ */
+DEFINE_SPINLOCK(kdb_immed_lk);
+void
+kdb_trap_immed(int reason)            /* fatal, non-fatal, kdb stack etc... */
+{
+    int ccpu = smp_processor_id();
+    int disabled = !local_irq_is_enabled();
+
+    KDBGP("trapimm:ccpu:%d reas:%d\n", ccpu, reason);
+    local_irq_enable();
+    spin_lock(&kdb_immed_lk);
+    kdb_trap_immed_reason = reason;
+    barrier();
+    __asm__ __volatile__ ( "int $1" );
+    kdb_trap_immed_reason = 0;
+
+    spin_unlock(&kdb_immed_lk);
+    if (disabled)
+        local_irq_disable();
+}
+
+/* called very early during init, even before all CPUs are brought online */
+void 
+kdb_init(void)
+{
+        kdb_init_cmdtab();      /* Initialize Command Table */
+}
+
+static const char *
+kdb_gettrapname(int trapno)
+{
+    char *ret;
+    switch (trapno) {
+        case  0:  ret = "Divide Error"; break;
+        case  2:  ret = "NMI Interrupt"; break;
+        case  3:  ret = "Int 3 Trap"; break;
+        case  4:  ret = "Overflow Error"; break;
+        case  6:  ret = "Invalid Opcode"; break;
+        case  8:  ret = "Double Fault"; break;
+        case 10:  ret = "Invalid TSS"; break;
+        case 11:  ret = "Segment Not Present"; break;
+        case 12:  ret = "Stack-Segment Fault"; break;
+        case 13:  ret = "General Protection"; break;
+        case 14:  ret = "Page Fault"; break;
+        case 17:  ret = "Alignment Check"; break;
+        default: ret = " ????? ";
+    }
+    return ret;
+}
+
+
+/* ====================== Generic tracing subsystem ======================== */
+
+#define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
+                           * is 32 bytes */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
+
+typedef struct {
+    union {
+        struct { uint d0; uint cpu_trcid; } s0;
+        uint64_t l0;
+    }u;
+    uint64_t l1, l2, l3; 
+} trc_rec_t;
+
+static volatile unsigned int trcidx;    /* points to where new entry will go */
+static trc_rec_t trca[KDBTRCMAX];       /* trace array */
+
+/* atomically: add i to *p, return prev value of *p (ie, val before add) */
+static int
+kdb_fetch_and_add(int i, uint *p)
+{
+    asm volatile("lock xaddl %0, %1;" : "=r"(i) : "m"(*p), "0"(i));
+    return i;
+}
+
+/* zero out the entire buffer */
+void 
+kdb_trczero(void)
+{
+    for (trcidx = KDBTRCMAX-1; trcidx; trcidx--) {
+        memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    }
+    memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    kdbp("kdb trace buffer has been zeroed\n");
+}
+
+/* add trace entry: eg.: kdbtrc(0xe0f099, intdata, vcpu, domain, 0)
+ *    where:  0xe0f099 : 24bits max trcid, lower 8 bits are set to cpuid */
+void
+kdbtrc(uint trcid, uint int_d0, uint64_t d1_64, uint64_t d2_64, uint64_t d3_64)
+{
+    uint idx;
+
+    if (!kdb_trcon)
+        return;
+
+    idx = kdb_fetch_and_add(1, (uint*)&trcidx);
+    idx = idx % KDBTRCMAX;
+
+#if 0
+    trca[idx].u.s0.cpu_trcid = (smp_processor_id()<<24) | trcid;
+#endif
+    trca[idx].u.s0.cpu_trcid = (trcid<<8) | smp_processor_id();
+    trca[idx].u.s0.d0 = int_d0;
+    trca[idx].l1 = d1_64;
+    trca[idx].l2 = d2_64;
+    trca[idx].l3 = d3_64;
+}
+
+/* give hints so user can print trc buffer via the dd command. last has the
+ * most recent entry */
+void
+kdb_trcp(void)
+{
+    int i = trcidx % KDBTRCMAX;
+
+    i = (i==0) ? KDBTRCMAX-1 : i-1;
+    kdbp("trcbuf:    [0]: %016lx [MAX-1]: %016lx\n", &trca[0],
+         &trca[KDBTRCMAX-1]);
+    kdbp(" [most recent]: %016lx   trcidx: 0x%x\n", &trca[i], trcidx);
+}
+
diff -r 32034d1914a6 xen/kdb/x86/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y    := kdb_wp.o
+subdir-y += udis86-1.7
diff -r 32034d1914a6 xen/kdb/x86/kdb_wp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/kdb_wp.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,310 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+#if 0
+#define DR6_BT  0x00008000
+#define DR6_BS  0x00004000
+#define DR6_BD  0x00002000
+#endif
+#define DR6_B3  0x00000008
+#define DR6_B2  0x00000004
+#define DR6_B1  0x00000002
+#define DR6_B0  0x00000001
+
+#define KDB_MAXWP 4                          /* DR0 thru DR3 */
+
+struct kdb_wp {
+    kdbma_t  wp_addr;
+    int      wp_rwflag;
+    int      wp_len;
+    int      wp_deleted;                     /* pending delete */
+};
+static struct kdb_wp kdb_wpa[KDB_MAXWP];
+
+/* following because vmcs has it's own dr7. when vmcs runs, it messes up the
+ * native dr7 so we need to save/restore it */
+unsigned long kdb_dr7;
+
+
+/* Set G0-G3 bits in DR7. this does global enable of the corresponding wp */
+static void
+kdb_set_gx_in_dr7(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p | 0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p | 0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p | 0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p | 0x80;
+}
+
+/* Set LEN0 - LEN3 pair bits in DR7 (len should be 1 2 4 or 8) */
+static void
+kdb_set_len_in_dr7(int regno, kdbma_t *dr7p, int len)
+{
+    int lenbits = (len == 8) ? 2 : len-1;
+
+    *dr7p &= ~(0x3 << (18 + 4*regno));
+    *dr7p |= ((ulong)(lenbits & 0x3) << (18 + 4*regno));
+}
+
+static void
+kdb_set_dr7_rw(int regno, kdbma_t *dr7p, int rw)
+{
+    *dr7p &= ~(0x3 << (16 + 4*regno));
+    *dr7p |= ((ulong)(rw & 0x3)) << (16 + 4*regno);
+}
+
+/* get value of a debug register: DR0-DR3 DR6 DR7. other values return 0 */
+kdbma_t
+kdb_rd_dbgreg(int regnum)
+{
+    kdbma_t contents = 0;
+
+    if (regnum == 0)
+        __asm__ ("movq %%db0,%0\n\t":"=r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %%db1,%0\n\t":"=r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %%db2,%0\n\t":"=r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %%db3,%0\n\t":"=r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %%db6,%0\n\t":"=r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %%db7,%0\n\t":"=r"(contents));
+
+    return contents;
+}
+
+static void
+kdb_wr_dbgreg(int regnum, kdbma_t contents)
+{
+    if (regnum == 0)
+        __asm__ ("movq %0,%%db0\n\t"::"r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %0,%%db1\n\t"::"r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %0,%%db2\n\t"::"r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %0,%%db3\n\t"::"r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %0,%%db6\n\t"::"r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %0,%%db7\n\t"::"r"(contents));
+}
+
+static void
+kdb_print_wp_info(char *strp, int idx)
+{
+    kdbp("%s[%d]:%016lx len:%d ", strp, idx, kdb_wpa[idx].wp_addr,
+         kdb_wpa[idx].wp_len);
+    if (kdb_wpa[idx].wp_rwflag == 1)
+        kdbp("on data write only\n");
+    else if (kdb_wpa[idx].wp_rwflag == 2)
+        kdbp("on IO read/write\n");
+    else 
+        kdbp("on data read/write\n");
+}
+
+/*
+ * Returns : 0 if not one of ours
+ *           1 if one of ours
+ */
+int
+kdb_check_watchpoints(struct cpu_user_regs *regs)
+{
+    int wpnum;
+    kdbma_t dr6 = kdb_rd_dbgreg(6);
+
+    KDBGP1("check_wp: IP:%lx EFLAGS:%lx\n", regs->rip, regs->rflags);
+    if (dr6 & DR6_B0)
+        wpnum = 0;
+    else if (dr6 & DR6_B1)
+        wpnum = 1;
+    else if (dr6 & DR6_B2)
+        wpnum = 2;
+    else if (dr6 & DR6_B3)
+        wpnum = 3;
+    else
+        return 0;
+
+    kdb_print_wp_info("Watchpoint ", wpnum);
+    return 1;
+}
+
+/* set a watchpoint at a given address 
+ * PreCondition: addr != 0 */
+static void
+kdb_set_wp(kdbva_t addr, int rwflag, int len)
+{
+    int regno;
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        if (kdb_wpa[regno].wp_addr == addr && !kdb_wpa[regno].wp_deleted) {
+            kdbp("Watchpoint already set\n");
+            return;
+        }
+        if (kdb_wpa[regno].wp_deleted)
+            memset(&kdb_wpa[regno], 0, sizeof(kdb_wpa[regno]));
+    }
+    for (regno=0; regno < KDB_MAXWP && kdb_wpa[regno].wp_addr; regno++);
+    if (regno >= KDB_MAXWP) {
+        kdbp("watchpoint table full. limit:%d\n", KDB_MAXWP);
+        return;
+    }
+    kdb_wpa[regno].wp_addr = addr;
+    kdb_wpa[regno].wp_rwflag = rwflag;
+    kdb_wpa[regno].wp_len = len;
+    kdb_print_wp_info("Watchpoint set ", regno);
+}
+
+/* write reg DR0-3 with address. Update corresponding bits in DR7 */
+static void
+kdb_install_watchpoint(int regno, kdbma_t *dr7p)
+{
+    kdb_set_gx_in_dr7(regno, dr7p);
+    kdb_set_len_in_dr7(regno, dr7p, kdb_wpa[regno].wp_len); 
+    kdb_set_dr7_rw(regno, dr7p, kdb_wpa[regno].wp_rwflag);
+    kdb_wr_dbgreg(regno, kdb_wpa[regno].wp_addr);
+
+    KDBGP1("ccpu:%d installed wp. addr:%lx rw:%x len:%x dr7:%016lx\n",
+           smp_processor_id(), kdb_wpa[regno].wp_addr, 
+           kdb_wpa[regno].wp_rwflag, kdb_wpa[regno].wp_len, *dr7p);
+}
+
+/* clear G0-G3 bits in DR7 for given DR0-3 */
+static void
+kdb_clear_dr7_gx(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p & ~0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p & ~0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p & ~0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p & ~0x80;
+}
+
+/* update dr7 once, as it's slow to update debug regs and cpu's will still be 
+ * paused when leaving kdb.
+ *
+ * Just leave DR0-3 clobbered but remove bits from DR7 to disable wp 
+ */
+void
+kdb_install_watchpoints(void)
+{
+    int regno;
+    kdbma_t dr7 = kdb_rd_dbgreg(7);
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        /* do not clear wp_deleted here as all cpus must clear wps */
+        if (kdb_wpa[regno].wp_deleted) {
+            kdb_clear_dr7_gx(regno, &dr7);
+            continue;
+        }
+        if (kdb_wpa[regno].wp_addr)
+            kdb_install_watchpoint(regno, &dr7);
+    }
+    /* always clear DR6 when leaving */
+    kdb_wr_dbgreg(6, 0);
+    kdb_wr_dbgreg(7, dr7);
+
+    if (dr7 & DR7_ACTIVE_MASK)
+        kdb_dr7 = dr7;
+    else
+        kdb_dr7 = 0;
+#if 0
+    for(dp=domain_list; dp; dp=dp->next_in_list) {
+        struct vcpu *vp;
+        for_each_vcpu(dp, vp) {
+            for (regno=0; regno < KDB_MAXWP; regno++)
+                vp->arch.guest_context.debugreg[regno] = kdb_wpa[regno].wp_addr;
+
+            vp->arch.guest_context.debugreg[6] = 0;
+            vp->arch.guest_context.debugreg[7] = dr7;
+            KDBGP("kdb_install_watchpoints(): v:%p dr7:%lx\n", vp, dr7);
+            /* hvm_set_info_guest(vp);: Can't because can't vmcs_enter in kdb */
+        }
+    }
+#endif
+}
+
+/* clear watchpoint/s. wpnum == -1 to clear all watchpoints */
+void
+kdb_clear_wps(int wpnum)
+{
+    int i;
+
+    if (wpnum >= KDB_MAXWP) {
+        kdbp("Invalid wpnum %d\n", wpnum);
+        return;
+    }
+    if (wpnum >=0) {
+        if (kdb_wpa[wpnum].wp_addr) {
+            kdb_wpa[wpnum].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", wpnum);
+        } else
+            kdbp("watchpoint %d not set\n", wpnum);
+        return;
+    }
+    for (i=0; i < KDB_MAXWP; i++) {
+        if (kdb_wpa[i].wp_addr) {
+            kdb_wpa[i].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", i);
+        }
+    }
+}
+
+/* display any watchpoints that are set */
+static void
+kdb_display_wps(void)
+{
+    int i;
+    for (i=0; i < KDB_MAXWP; i++)
+        if (kdb_wpa[i].wp_addr && !kdb_wpa[i].wp_deleted) 
+            kdb_print_wp_info("", i);
+}
+
+/* 
+ * Display or Set hardware breakpoints, ie, watchpoints:
+ *   - Upto 4 are allowed
+ *   
+ *  rw_flag should be one of: 
+ *     01 == break on data write only
+ *     10 == break on IO read/write
+ *     11 == Break on data reads or writes
+ *
+ *  len should be one of : 1 2 4 8 
+ */
+void
+kdb_do_watchpoints(kdbva_t addr, int rw_flag, int len)
+{
+    if (addr == 0) {
+        kdb_display_wps();        /* display set watchpoints */
+        return;
+    }
+    kdb_set_wp(addr, rw_flag, len);
+    return;
+}
+
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/LICENSE
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/LICENSE	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,22 @@
+Copyright (c) 2002, 2003, 2004, 2005, 2006 <vivek@sig9.com>
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, 
+are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice, 
+      this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright notice, 
+      this list of conditions and the following disclaimer in the documentation 
+      and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,5 @@
+
+CFLAGS		+= -D__UD_STANDALONE__
+obj-y		:= decode.o input.o itab.o kdb_dis.o syn-att.o syn.o \
+                   syn-intel.o udis86.o
+
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/README	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,10 @@
+
+http://udis86.sourceforge.net/
+udis86-1.6 : 
+  - cd libudis86
+  - cp *c to here
+  - cp *h to here
+   
+Mukesh Rathor
+04/30/2008
+
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/decode.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,1197 @@
+/* -----------------------------------------------------------------------------
+ * decode.c
+ *
+ * Copyright (c) 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <assert.h>
+#include <string.h>
+#endif
+
+#include "types.h"
+#include "itab.h"
+#include "input.h"
+#include "decode.h"
+
+/* The max number of prefixes to an instruction */
+#define MAX_PREFIXES    15
+
+static struct ud_itab_entry ie_invalid = { UD_Iinvalid, O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_pause   = { UD_Ipause,   O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_nop     = { UD_Inop,     O_NONE, O_NONE, O_NONE, P_none };
+
+
+/* Looks up mnemonic code in the mnemonic string table
+ * Returns NULL if the mnemonic code is invalid
+ */
+const char * ud_lookup_mnemonic( enum ud_mnemonic_code c )
+{
+    if ( c < UD_Id3vil )
+        return ud_mnemonics_str[ c ];
+    return NULL;
+}
+
+
+/* Extracts instruction prefixes.
+ */
+static int get_prefixes( struct ud* u )
+{
+    unsigned int have_pfx = 1;
+    unsigned int i;
+    uint8_t curr;
+
+    /* if in error state, bail out */
+    if ( u->error ) 
+        return -1; 
+
+    /* keep going as long as there are prefixes available */
+    for ( i = 0; have_pfx ; ++i ) {
+
+        /* Get next byte. */
+        inp_next(u); 
+        if ( u->error ) 
+            return -1;
+        curr = inp_curr( u );
+
+        /* rex prefixes in 64bit mode */
+        if ( u->dis_mode == 64 && ( curr & 0xF0 ) == 0x40 ) {
+            u->pfx_rex = curr;  
+        } else {
+            switch ( curr )  
+            {
+            case 0x2E : 
+                u->pfx_seg = UD_R_CS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x36 :     
+                u->pfx_seg = UD_R_SS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x3E : 
+                u->pfx_seg = UD_R_DS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x26 : 
+                u->pfx_seg = UD_R_ES; 
+                u->pfx_rex = 0;
+                break;
+            case 0x64 : 
+                u->pfx_seg = UD_R_FS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x65 : 
+                u->pfx_seg = UD_R_GS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x67 : /* adress-size override prefix */ 
+                u->pfx_adr = 0x67;
+                u->pfx_rex = 0;
+                break;
+            case 0xF0 : 
+                u->pfx_lock = 0xF0;
+                u->pfx_rex  = 0;
+                break;
+            case 0x66: 
+                /* the 0x66 sse prefix is only effective if no other sse prefix
+                 * has already been specified.
+                 */
+                if ( !u->pfx_insn ) u->pfx_insn = 0x66;
+                u->pfx_opr = 0x66;           
+                u->pfx_rex = 0;
+                break;
+            case 0xF2:
+                u->pfx_insn  = 0xF2;
+                u->pfx_repne = 0xF2; 
+                u->pfx_rex   = 0;
+                break;
+            case 0xF3:
+                u->pfx_insn = 0xF3;
+                u->pfx_rep  = 0xF3; 
+                u->pfx_repe = 0xF3; 
+                u->pfx_rex  = 0;
+                break;
+            default : 
+                /* No more prefixes */
+                have_pfx = 0;
+                break;
+            }
+        }
+
+        /* check if we reached max instruction length */
+        if ( i + 1 == MAX_INSN_LENGTH ) {
+            u->error = 1;
+            break;
+        }
+    }
+
+    /* return status */
+    if ( u->error ) 
+        return -1; 
+
+    /* rewind back one byte in stream, since the above loop 
+     * stops with a non-prefix byte. 
+     */
+    inp_back(u);
+
+    /* speculatively determine the effective operand mode,
+     * based on the prefixes and the current disassembly
+     * mode. This may be inaccurate, but useful for mode
+     * dependent decoding.
+     */
+    if ( u->dis_mode == 64 ) {
+        u->opr_mode = REX_W( u->pfx_rex ) ? 64 : ( ( u->pfx_opr ) ? 16 : 32 ) ;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 64;
+    } else if ( u->dis_mode == 32 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+        u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+    } else if ( u->dis_mode == 16 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+    }
+
+    return 0;
+}
+
+
+/* Searches the instruction tables for the right entry.
+ */
+static int search_itab( struct ud * u )
+{
+    struct ud_itab_entry * e = NULL;
+    enum ud_itab_index table;
+    uint8_t peek;
+    uint8_t did_peek = 0;
+    uint8_t curr; 
+    uint8_t index;
+
+    /* if in state of error, return */
+    if ( u->error ) 
+        return -1;
+
+    /* get first byte of opcode. */
+    inp_next(u); 
+    if ( u->error ) 
+        return -1;
+    curr = inp_curr(u); 
+
+    /* resolve xchg, nop, pause crazyness */
+    if ( 0x90 == curr ) {
+        if ( !( u->dis_mode == 64 && REX_B( u->pfx_rex ) ) ) {
+            if ( u->pfx_rep ) {
+                u->pfx_rep = 0;
+                e = & ie_pause;
+            } else {
+                e = & ie_nop;
+            }
+            goto found_entry;
+        }
+    }
+
+    /* get top-level table */
+    if ( 0x0F == curr ) {
+        table = ITAB__0F;
+        curr  = inp_next(u);
+        if ( u->error )
+            return -1;
+
+        /* 2byte opcodes can be modified by 0x66, F3, and F2 prefixes */
+        if ( 0x66 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSE66__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSE66__0F;
+                u->pfx_opr = 0;
+            }
+        } else if ( 0xF2 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF2__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF2__0F; 
+                u->pfx_repne = 0;
+            }
+        } else if ( 0xF3 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF3__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF3__0F;
+                u->pfx_repe = 0;
+                u->pfx_rep  = 0;
+            }
+        }
+    /* pick an instruction from the 1byte table */
+    } else {
+        table = ITAB__1BYTE; 
+    }
+
+    index = curr;
+
+search:
+
+    e = & ud_itab_list[ table ][ index ];
+
+    /* if mnemonic constant is a standard instruction constant
+     * our search is over.
+     */
+    
+    if ( e->mnemonic < UD_Id3vil ) {
+        if ( e->mnemonic == UD_Iinvalid ) {
+            if ( did_peek ) {
+                inp_next( u ); if ( u->error ) return -1;
+            }
+            goto found_entry;
+        }
+        goto found_entry;
+    }
+
+    table = e->prefix;
+
+    switch ( e->mnemonic )
+    {
+    case UD_Igrp_reg:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_REG( peek );
+        break;
+
+    case UD_Igrp_mod:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_MOD( peek );
+        if ( index == 3 )
+           index = ITAB__MOD_INDX__11;
+        else 
+           index = ITAB__MOD_INDX__NOT_11; 
+        break;
+
+    case UD_Igrp_rm:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = MODRM_RM( curr );
+        break;
+
+    case UD_Igrp_x87:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = curr - 0xC0;
+        break;
+
+    case UD_Igrp_osize:
+        if ( u->opr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->opr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+ 
+    case UD_Igrp_asize:
+        if ( u->adr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->adr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;               
+
+    case UD_Igrp_mode:
+        if ( u->dis_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->dis_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+
+    case UD_Igrp_vendor:
+        if ( u->vendor == UD_VENDOR_INTEL ) 
+            index = ITAB__VENDOR_INDX__INTEL; 
+        else if ( u->vendor == UD_VENDOR_AMD )
+            index = ITAB__VENDOR_INDX__AMD;
+        else {
+            kdbp("KDB:search_itab(): unrecognized vendor id\n");
+            return -1;
+        }
+        break;
+
+    case UD_Id3vil:
+        kdbp("KDB:search_itab(): invalid instr mnemonic constant Id3vil\n");
+        return -1;
+
+    default:
+        kdbp("KDB:search_itab(): invalid instruction mnemonic constant\n");
+        return -1;
+    }
+
+    goto search;
+
+found_entry:
+
+    u->itab_entry = e;
+    u->mnemonic = u->itab_entry->mnemonic;
+
+    return 0;
+}
+
+
+static unsigned int resolve_operand_size( const struct ud * u, unsigned int s )
+{
+    switch ( s ) 
+    {
+    case SZ_V:
+        return ( u->opr_mode );
+    case SZ_Z:  
+        return ( u->opr_mode == 16 ) ? 16 : 32;
+    case SZ_P:  
+        return ( u->opr_mode == 16 ) ? SZ_WP : SZ_DP;
+    case SZ_MDQ:
+        return ( u->opr_mode == 16 ) ? 32 : u->opr_mode;
+    case SZ_RDQ:
+        return ( u->dis_mode == 64 ) ? 64 : 32;
+    default:
+        return s;
+    }
+}
+
+
+static int resolve_mnemonic( struct ud* u )
+{
+  /* far/near flags */
+  u->br_far = 0;
+  u->br_near = 0;
+  /* readjust operand sizes for call/jmp instrcutions */
+  if ( u->mnemonic == UD_Icall || u->mnemonic == UD_Ijmp ) {
+    /* WP: 16bit pointer */
+    if ( u->operand[ 0 ].size == SZ_WP ) {
+        u->operand[ 0 ].size = 16;
+        u->br_far = 1;
+        u->br_near= 0;
+    /* DP: 32bit pointer */
+    } else if ( u->operand[ 0 ].size == SZ_DP ) {
+        u->operand[ 0 ].size = 32;
+        u->br_far = 1;
+        u->br_near= 0;
+    } else {
+        u->br_far = 0;
+        u->br_near= 1;
+    }
+  /* resolve 3dnow weirdness. */
+  } else if ( u->mnemonic == UD_I3dnow ) {
+    u->mnemonic = ud_itab_list[ ITAB__3DNOW ][ inp_curr( u )  ].mnemonic;
+  }
+  /* SWAPGS is only valid in 64bits mode */
+  if ( u->mnemonic == UD_Iswapgs && u->dis_mode != 64 ) {
+    u->error = 1;
+    return -1;
+  }
+
+  return 0;
+}
+
+
+/* -----------------------------------------------------------------------------
+ * decode_a()- Decodes operands of the type seg:offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_a(struct ud* u, struct ud_operand *op)
+{
+  if (u->opr_mode == 16) {  
+    /* seg16:off16 */
+    op->type = UD_OP_PTR;
+    op->size = 32;
+    op->lval.ptr.off = inp_uint16(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  } else {
+    /* seg16:off32 */
+    op->type = UD_OP_PTR;
+    op->size = 48;
+    op->lval.ptr.off = inp_uint32(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_gpr() - Returns decoded General Purpose Register 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+decode_gpr(register struct ud* u, unsigned int s, unsigned char rm)
+{
+  s = resolve_operand_size(u, s);
+        
+  switch (s) {
+    case 64:
+        return UD_R_RAX + rm;
+    case SZ_DP:
+    case 32:
+        return UD_R_EAX + rm;
+    case SZ_WP:
+    case 16:
+        return UD_R_AX  + rm;
+    case  8:
+        if (u->dis_mode == 64 && u->pfx_rex) {
+            if (rm >= 4)
+                return UD_R_SPL + (rm-4);
+            return UD_R_AL + rm;
+        } else return UD_R_AL + rm;
+    default:
+        return 0;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr64() - 64bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr64(struct ud* u, enum ud_operand_code gpr_op)
+{
+  if (gpr_op >= OP_rAXr8 && gpr_op <= OP_rDIr15)
+    gpr_op = (gpr_op - OP_rAXr8) | (REX_B(u->pfx_rex) << 3);          
+  else  gpr_op = (gpr_op - OP_rAX);
+
+  if (u->opr_mode == 16)
+    return gpr_op + UD_R_AX;
+  if (u->dis_mode == 32 || 
+    (u->opr_mode == 32 && ! (REX_W(u->pfx_rex) || u->default64))) {
+    return gpr_op + UD_R_EAX;
+  }
+
+  return gpr_op + UD_R_RAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr32 () - 32bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr32(struct ud* u, enum ud_operand_code gpr_op)
+{
+  gpr_op = gpr_op - OP_eAX;
+
+  if (u->opr_mode == 16) 
+    return gpr_op + UD_R_AX;
+
+  return gpr_op +  UD_R_EAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_reg() - Resolves the register type 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_reg(struct ud* u, unsigned int type, unsigned char i)
+{
+  switch (type) {
+    case T_MMX :    return UD_R_MM0  + (i & 7);
+    case T_XMM :    return UD_R_XMM0 + i;
+    case T_CRG :    return UD_R_CR0  + i;
+    case T_DBG :    return UD_R_DR0  + i;
+    case T_SEG :    return UD_R_ES   + (i & 7);
+    case T_NONE:
+    default:    return UD_NONE;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_imm() - Decodes Immediate values.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_imm(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  op->size = resolve_operand_size(u, s);
+  op->type = UD_OP_IMM;
+
+  switch (op->size) {
+    case  8: op->lval.sbyte = inp_uint8(u);   break;
+    case 16: op->lval.uword = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: return;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_modrm() - Decodes ModRM Byte
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_modrm(struct ud* u, struct ud_operand *op, unsigned int s, 
+         unsigned char rm_type, struct ud_operand *opreg, 
+         unsigned char reg_size, unsigned char reg_type)
+{
+  unsigned char mod, rm, reg;
+
+  inp_next(u);
+
+  /* get mod, r/m and reg fields */
+  mod = MODRM_MOD(inp_curr(u));
+  rm  = (REX_B(u->pfx_rex) << 3) | MODRM_RM(inp_curr(u));
+  reg = (REX_R(u->pfx_rex) << 3) | MODRM_REG(inp_curr(u));
+
+  op->size = resolve_operand_size(u, s);
+
+  /* if mod is 11b, then the UD_R_m specifies a gpr/mmx/sse/control/debug */
+  if (mod == 3) {
+    op->type = UD_OP_REG;
+    if (rm_type ==  T_GPR)
+        op->base = decode_gpr(u, op->size, rm);
+    else    op->base = resolve_reg(u, rm_type, (REX_B(u->pfx_rex) << 3) | (rm&7));
+  } 
+  /* else its memory addressing */  
+  else {
+    op->type = UD_OP_MEM;
+
+    /* 64bit addressing */
+    if (u->adr_mode == 64) {
+
+        op->base = UD_R_RAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && (rm & 7) == 5) {           
+            op->base = UD_R_RIP;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+            
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_RAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_RAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            /* special conditions for base reference */
+            if (op->index == UD_R_RSP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            if (op->base == UD_R_RBP || op->base == UD_R_R13) {
+                if (mod == 0) 
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 32-Bit addressing mode */
+    else if (u->adr_mode == 32) {
+
+        /* get base */
+        op->base = UD_R_EAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && rm == 5) {
+            op->base = UD_NONE;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_EAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_EAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            if (op->index == UD_R_ESP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            /* special condition for base reference */
+            if (op->base == UD_R_EBP) {
+                if (mod == 0)
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 16bit addressing mode */
+    else  {
+        switch (rm) {
+            case 0: op->base = UD_R_BX; op->index = UD_R_SI; break;
+            case 1: op->base = UD_R_BX; op->index = UD_R_DI; break;
+            case 2: op->base = UD_R_BP; op->index = UD_R_SI; break;
+            case 3: op->base = UD_R_BP; op->index = UD_R_DI; break;
+            case 4: op->base = UD_R_SI; break;
+            case 5: op->base = UD_R_DI; break;
+            case 6: op->base = UD_R_BP; break;
+            case 7: op->base = UD_R_BX; break;
+        }
+
+        if (mod == 0 && rm == 6) {
+            op->offset= 16;
+            op->base = UD_NONE;
+        }
+        else if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2) 
+            op->offset = 16;
+    }
+  }  
+
+  /* extract offset, if any */
+  switch(op->offset) {
+    case 8 : op->lval.ubyte  = inp_uint8(u);  break;
+    case 16: op->lval.uword  = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: break;
+  }
+
+  /* resolve register encoded in reg field */
+  if (opreg) {
+    opreg->type = UD_OP_REG;
+    opreg->size = resolve_operand_size(u, reg_size);
+    if (reg_type == T_GPR) 
+        opreg->base = decode_gpr(u, opreg->size, reg);
+    else opreg->base = resolve_reg(u, reg_type, reg);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_o() - Decodes offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_o(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  switch (u->adr_mode) {
+    case 64:
+        op->offset = 64; 
+        op->lval.uqword = inp_uint64(u); 
+        break;
+    case 32:
+        op->offset = 32; 
+        op->lval.udword = inp_uint32(u); 
+        break;
+    case 16:
+        op->offset = 16; 
+        op->lval.uword  = inp_uint16(u); 
+        break;
+    default:
+        return;
+  }
+  op->type = UD_OP_MEM;
+  op->size = resolve_operand_size(u, s);
+}
+
+/* -----------------------------------------------------------------------------
+ * disasm_operands() - Disassembles Operands.
+ * -----------------------------------------------------------------------------
+ */
+static int disasm_operands(register struct ud* u)
+{
+
+
+  /* mopXt = map entry, operand X, type; */
+  enum ud_operand_code mop1t = u->itab_entry->operand1.type;
+  enum ud_operand_code mop2t = u->itab_entry->operand2.type;
+  enum ud_operand_code mop3t = u->itab_entry->operand3.type;
+
+  /* mopXs = map entry, operand X, size */
+  unsigned int mop1s = u->itab_entry->operand1.size;
+  unsigned int mop2s = u->itab_entry->operand2.size;
+  unsigned int mop3s = u->itab_entry->operand3.size;
+
+  /* iop = instruction operand */
+  register struct ud_operand* iop = u->operand;
+    
+  switch(mop1t) {
+    
+    case OP_A :
+        decode_a(u, &(iop[0]));
+        break;
+    
+    /* M[b] ... */
+    case OP_M :
+        if (MODRM_MOD(inp_peek(u)) == 3)
+            u->error= 1;
+    /* E, G/P/V/I/CL/1/S */
+    case OP_E :
+        if (mop2t == OP_G) {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+            else if (mop3t == OP_CL) {
+                iop[2].type = UD_OP_REG;
+                iop[2].base = UD_R_CL;
+                iop[2].size = 8;
+            }
+        }
+        else if (mop2t == OP_P)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_MMX);
+        else if (mop2t == OP_V)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_XMM);
+        else if (mop2t == OP_S)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_SEG);
+        else {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, NULL, 0, T_NONE);
+            if (mop2t == OP_CL) {
+                iop[1].type = UD_OP_REG;
+                iop[1].base = UD_R_CL;
+                iop[1].size = 8;
+            } else if (mop2t == OP_I1) {
+                iop[1].type = UD_OP_CONST;
+                u->operand[1].lval.udword = 1;
+            } else if (mop2t == OP_I) {
+                decode_imm(u, mop2s, &(iop[1]));
+            }
+        }
+        break;
+
+    /* G, E/PR[,I]/VR */
+    case OP_G :
+        if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_W)
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        break;
+
+    /* AL..BH, I/O/DX */
+    case OP_AL : case OP_CL : case OP_DL : case OP_BL :
+    case OP_AH : case OP_CH : case OP_DH : case OP_BH :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AL + (mop1t - OP_AL);
+        iop[0].size = 8;
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        }
+        else if (mop2t == OP_O)
+            decode_o(u, mop2s, &(iop[1]));
+        break;
+
+    /* rAX[r8]..rDI[r15], I/rAX..rDI/O */
+    case OP_rAXr8 : case OP_rCXr9 : case OP_rDXr10 : case OP_rBXr11 :
+    case OP_rSPr12: case OP_rBPr13: case OP_rSIr14 : case OP_rDIr15 :
+    case OP_rAX : case OP_rCX : case OP_rDX : case OP_rBX :
+    case OP_rSP : case OP_rBP : case OP_rSI : case OP_rDI :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr64(u, mop1t);
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t >= OP_rAX && mop2t <= OP_rDI) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = resolve_gpr64(u, mop2t);
+        }
+        else if (mop2t == OP_O) {
+            decode_o(u, mop2s, &(iop[1]));  
+            iop[0].size = resolve_operand_size(u, mop2s);
+        }
+        break;
+
+    /* AL[r8b]..BH[r15b], I */
+    case OP_ALr8b : case OP_CLr9b : case OP_DLr10b : case OP_BLr11b :
+    case OP_AHr12b: case OP_CHr13b: case OP_DHr14b : case OP_BHr15b :
+    {
+        ud_type_t gpr = (mop1t - OP_ALr8b) + UD_R_AL + 
+                        (REX_B(u->pfx_rex) << 3);
+        if (UD_R_AH <= gpr && u->pfx_rex)
+            gpr = gpr + 4;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = gpr;
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+    }
+
+    /* eAX..eDX, DX/I */
+    case OP_eAX : case OP_eCX : case OP_eDX : case OP_eBX :
+    case OP_eSP : case OP_eBP : case OP_eSI : case OP_eDI :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr32(u, mop1t);
+        if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        } else if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+
+    /* ES..GS */
+    case OP_ES : case OP_CS : case OP_DS :
+    case OP_SS : case OP_FS : case OP_GS :
+
+        /* in 64bits mode, only fs and gs are allowed */
+        if (u->dis_mode == 64)
+            if (mop1t != OP_FS && mop1t != OP_GS)
+                u->error= 1;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t - OP_ES) + UD_R_ES;
+        iop[0].size = 16;
+
+        break;
+
+    /* J */
+    case OP_J :
+        decode_imm(u, mop1s, &(iop[0]));        
+        iop[0].type = UD_OP_JIMM;
+        break ;
+
+    /* PR, I */
+    case OP_PR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* VR, I */
+    case OP_VR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* P, Q[,I]/W/E[,I],VR */
+    case OP_P :
+        if (mop2t == OP_Q) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_W) {
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        }
+        break;
+
+    /* R, C/D */
+    case OP_R :
+        if (mop2t == OP_C)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_CRG);
+        else if (mop2t == OP_D)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_DBG);
+        break;
+
+    /* C, R */
+    case OP_C :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_CRG);
+        break;
+
+    /* D, R */
+    case OP_D :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_DBG);
+        break;
+
+    /* Q, P */
+    case OP_Q :
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, &(iop[1]), mop2s, T_MMX);
+        break;
+
+    /* S, E */
+    case OP_S :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_SEG);
+        break;
+
+    /* W, V */
+    case OP_W :
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, &(iop[1]), mop2s, T_XMM);
+        break;
+
+    /* V, W[,I]/Q/M/E */
+    case OP_V :
+        if (mop2t == OP_W) {
+            /* special cases for movlps and movhps */
+            if (MODRM_MOD(inp_peek(u)) == 3) {
+                if (u->mnemonic == UD_Imovlps)
+                    u->mnemonic = UD_Imovhlps;
+                else
+                if (u->mnemonic == UD_Imovhps)
+                    u->mnemonic = UD_Imovlhps;
+            }
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_XMM);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_Q)
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        else if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        }
+        break;
+
+    /* DX, eAX/AL */
+    case OP_DX :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_DX;
+        iop[0].size = 16;
+
+        if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        } else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 8;
+        }
+
+        break;
+
+    /* I, I/AL/eAX */
+    case OP_I :
+        decode_imm(u, mop1s, &(iop[0]));
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 16;
+        } else if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        }
+        break;
+
+    /* O, AL/eAX */
+    case OP_O :
+        decode_o(u, mop1s, &(iop[0]));
+        iop[1].type = UD_OP_REG;
+        iop[1].size = resolve_operand_size(u, mop1s);
+        if (mop2t == OP_AL)
+            iop[1].base = UD_R_AL;
+        else if (mop2t == OP_eAX)
+            iop[1].base = resolve_gpr32(u, mop2t);
+        else if (mop2t == OP_rAX)
+            iop[1].base = resolve_gpr64(u, mop2t);      
+        break;
+
+    /* 3 */
+    case OP_I3 :
+        iop[0].type = UD_OP_CONST;
+        iop[0].lval.sbyte = 3;
+        break;
+
+    /* ST(n), ST(n) */
+    case OP_ST0 : case OP_ST1 : case OP_ST2 : case OP_ST3 :
+    case OP_ST4 : case OP_ST5 : case OP_ST6 : case OP_ST7 :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t-OP_ST0) + UD_R_ST0;
+        iop[0].size = 0;
+
+        if (mop2t >= OP_ST0 && mop2t <= OP_ST7) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = (mop2t-OP_ST0) + UD_R_ST0;
+            iop[1].size = 0;
+        }
+        break;
+
+    /* AX */
+    case OP_AX:
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AX;
+        iop[0].size = 16;
+        break;
+
+    /* none */
+    default :
+        iop[0].type = iop[1].type = iop[2].type = UD_NONE;
+  }
+
+  return 0;
+}
+
+/* -----------------------------------------------------------------------------
+ * clear_insn() - clear instruction pointer 
+ * -----------------------------------------------------------------------------
+ */
+static int clear_insn(register struct ud* u)
+{
+  u->error     = 0;
+  u->pfx_seg   = 0;
+  u->pfx_opr   = 0;
+  u->pfx_adr   = 0;
+  u->pfx_lock  = 0;
+  u->pfx_repne = 0;
+  u->pfx_rep   = 0;
+  u->pfx_repe  = 0;
+  u->pfx_seg   = 0;
+  u->pfx_rex   = 0;
+  u->pfx_insn  = 0;
+  u->mnemonic  = UD_Inone;
+  u->itab_entry = NULL;
+
+  memset( &u->operand[ 0 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 1 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 2 ], 0, sizeof( struct ud_operand ) );
+ 
+  return 0;
+}
+
+static int do_mode( struct ud* u )
+{
+  /* if in error state, bail out */
+  if ( u->error ) return -1; 
+
+  /* propagate perfix effects */
+  if ( u->dis_mode == 64 ) {  /* set 64bit-mode flags */
+
+    /* Check validity of  instruction m64 */
+    if ( P_INV64( u->itab_entry->prefix ) ) {
+        u->error = 1;
+        return -1;
+    }
+
+    /* effective rex prefix is the  effective mask for the 
+     * instruction hard-coded in the opcode map.
+     */
+    u->pfx_rex = ( u->pfx_rex & 0x40 ) | 
+                 ( u->pfx_rex & REX_PFX_MASK( u->itab_entry->prefix ) ); 
+
+    /* whether this instruction has a default operand size of 
+     * 64bit, also hardcoded into the opcode map.
+     */
+    u->default64 = P_DEF64( u->itab_entry->prefix ); 
+    /* calculate effective operand size */
+    if ( REX_W( u->pfx_rex ) ) {
+        u->opr_mode = 64;
+    } else if ( u->pfx_opr ) {
+        u->opr_mode = 16;
+    } else {
+        /* unless the default opr size of instruction is 64,
+         * the effective operand size in the absence of rex.w
+         * prefix is 32.
+         */
+        u->opr_mode = ( u->default64 ) ? 64 : 32;
+    }
+
+    /* calculate effective address size */
+    u->adr_mode = (u->pfx_adr) ? 32 : 64;
+  } else if ( u->dis_mode == 32 ) { /* set 32bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+    u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+  } else if ( u->dis_mode == 16 ) { /* set 16bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+    u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+  }
+
+  /* These flags determine which operand to apply the operand size
+   * cast to.
+   */
+  u->c1 = ( P_C1( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c2 = ( P_C2( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c3 = ( P_C3( u->itab_entry->prefix ) ) ? 1 : 0;
+
+  /* set flags for implicit addressing */
+  u->implicit_addr = P_IMPADDR( u->itab_entry->prefix );
+
+  return 0;
+}
+
+static int gen_hex( struct ud *u )
+{
+  unsigned int i;
+  unsigned char *src_ptr = inp_sess( u );
+  char* src_hex;
+
+  /* bail out if in error stat. */
+  if ( u->error ) return -1; 
+  /* output buffer pointe */
+  src_hex = ( char* ) u->insn_hexcode;
+  /* for each byte used to decode instruction */
+  for ( i = 0; i < u->inp_ctr; ++i, ++src_ptr) {
+    snprintf( src_hex, 2, "%02x", *src_ptr & 0xFF );
+    src_hex += 2;
+  }
+  return 0;
+}
+
+/* =============================================================================
+ * ud_decode() - Instruction decoder. Returns the number of bytes decoded.
+ * =============================================================================
+ */
+unsigned int ud_decode( struct ud* u )
+{
+  inp_start(u);
+
+  if ( clear_insn( u ) ) {
+    ; /* error */
+  } else if ( get_prefixes( u ) != 0 ) {
+    ; /* error */
+  } else if ( search_itab( u ) != 0 ) {
+    ; /* error */
+  } else if ( do_mode( u ) != 0 ) {
+    ; /* error */
+  } else if ( disasm_operands( u ) != 0 ) {
+    ; /* error */
+  } else if ( resolve_mnemonic( u ) != 0 ) {
+    ; /* error */
+  }
+
+  /* Handle decode error. */
+  if ( u->error ) {
+    /* clear out the decode data. */
+    clear_insn( u );
+    /* mark the sequence of bytes as invalid. */
+    u->itab_entry = & ie_invalid;
+    u->mnemonic = u->itab_entry->mnemonic;
+  } 
+
+  u->insn_offset = u->pc; /* set offset of instruction */
+  u->insn_fill = 0;   /* set translation buffer index to 0 */
+  u->pc += u->inp_ctr;    /* move program counter by bytes decoded */
+  gen_hex( u );       /* generate hex code */
+
+  /* return number of bytes disassembled. */
+  return u->inp_ctr;
+}
+
+/* vim:cindent
+ * vim:ts=4
+ * vim:sw=4
+ * vim:expandtab
+ */
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/decode.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,273 @@
+#ifndef UD_DECODE_H
+#define UD_DECODE_H
+
+#define MAX_INSN_LENGTH 15
+
+/* register classes */
+#define T_NONE  0
+#define T_GPR   1
+#define T_MMX   2
+#define T_CRG   3
+#define T_DBG   4
+#define T_SEG   5
+#define T_XMM   6
+
+/* itab prefix bits */
+#define P_none          ( 0 )
+#define P_c1            ( 1 << 0 )
+#define P_C1(n)         ( ( n >> 0 ) & 1 )
+#define P_rexb          ( 1 << 1 )
+#define P_REXB(n)       ( ( n >> 1 ) & 1 )
+#define P_depM          ( 1 << 2 )
+#define P_DEPM(n)       ( ( n >> 2 ) & 1 )
+#define P_c3            ( 1 << 3 )
+#define P_C3(n)         ( ( n >> 3 ) & 1 )
+#define P_inv64         ( 1 << 4 )
+#define P_INV64(n)      ( ( n >> 4 ) & 1 )
+#define P_rexw          ( 1 << 5 )
+#define P_REXW(n)       ( ( n >> 5 ) & 1 )
+#define P_c2            ( 1 << 6 )
+#define P_C2(n)         ( ( n >> 6 ) & 1 )
+#define P_def64         ( 1 << 7 )
+#define P_DEF64(n)      ( ( n >> 7 ) & 1 )
+#define P_rexr          ( 1 << 8 )
+#define P_REXR(n)       ( ( n >> 8 ) & 1 )
+#define P_oso           ( 1 << 9 )
+#define P_OSO(n)        ( ( n >> 9 ) & 1 )
+#define P_aso           ( 1 << 10 )
+#define P_ASO(n)        ( ( n >> 10 ) & 1 )
+#define P_rexx          ( 1 << 11 )
+#define P_REXX(n)       ( ( n >> 11 ) & 1 )
+#define P_ImpAddr       ( 1 << 12 )
+#define P_IMPADDR(n)    ( ( n >> 12 ) & 1 )
+
+/* rex prefix bits */
+#define REX_W(r)        ( ( 0xF & ( r ) )  >> 3 )
+#define REX_R(r)        ( ( 0x7 & ( r ) )  >> 2 )
+#define REX_X(r)        ( ( 0x3 & ( r ) )  >> 1 )
+#define REX_B(r)        ( ( 0x1 & ( r ) )  >> 0 )
+#define REX_PFX_MASK(n) ( ( P_REXW(n) << 3 ) | \
+                          ( P_REXR(n) << 2 ) | \
+                          ( P_REXX(n) << 1 ) | \
+                          ( P_REXB(n) << 0 ) )
+
+/* scable-index-base bits */
+#define SIB_S(b)        ( ( b ) >> 6 )
+#define SIB_I(b)        ( ( ( b ) >> 3 ) & 7 )
+#define SIB_B(b)        ( ( b ) & 7 )
+
+/* modrm bits */
+#define MODRM_REG(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_NNN(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_MOD(b)    ( ( ( b ) >> 6 ) & 3 )
+#define MODRM_RM(b)     ( ( b ) & 7 )
+
+/* operand type constants -- order is important! */
+
+enum ud_operand_code {
+    OP_NONE,
+
+    OP_A,      OP_E,      OP_M,       OP_G,       
+    OP_I,
+
+    OP_AL,     OP_CL,     OP_DL,      OP_BL,
+    OP_AH,     OP_CH,     OP_DH,      OP_BH,
+
+    OP_ALr8b,  OP_CLr9b,  OP_DLr10b,  OP_BLr11b,
+    OP_AHr12b, OP_CHr13b, OP_DHr14b,  OP_BHr15b,
+
+    OP_AX,     OP_CX,     OP_DX,      OP_BX,
+    OP_SI,     OP_DI,     OP_SP,      OP_BP,
+
+    OP_rAX,    OP_rCX,    OP_rDX,     OP_rBX,  
+    OP_rSP,    OP_rBP,    OP_rSI,     OP_rDI,
+
+    OP_rAXr8,  OP_rCXr9,  OP_rDXr10,  OP_rBXr11,  
+    OP_rSPr12, OP_rBPr13, OP_rSIr14,  OP_rDIr15,
+
+    OP_eAX,    OP_eCX,    OP_eDX,     OP_eBX,
+    OP_eSP,    OP_eBP,    OP_eSI,     OP_eDI,
+
+    OP_ES,     OP_CS,     OP_SS,      OP_DS,  
+    OP_FS,     OP_GS,
+
+    OP_ST0,    OP_ST1,    OP_ST2,     OP_ST3,
+    OP_ST4,    OP_ST5,    OP_ST6,     OP_ST7,
+
+    OP_J,      OP_S,      OP_O,          
+    OP_I1,     OP_I3, 
+
+    OP_V,      OP_W,      OP_Q,       OP_P, 
+
+    OP_R,      OP_C,  OP_D,       OP_VR,  OP_PR
+};
+
+
+/* operand size constants */
+
+enum ud_operand_size {
+    SZ_NA  = 0,
+    SZ_Z   = 1,
+    SZ_V   = 2,
+    SZ_P   = 3,
+    SZ_WP  = 4,
+    SZ_DP  = 5,
+    SZ_MDQ = 6,
+    SZ_RDQ = 7,
+
+    /* the following values are used as is,
+     * and thus hard-coded. changing them 
+     * will break internals 
+     */
+    SZ_B   = 8,
+    SZ_W   = 16,
+    SZ_D   = 32,
+    SZ_Q   = 64,
+    SZ_T   = 80,
+};
+
+/* itab entry operand definitions */
+
+#define O_rSPr12  { OP_rSPr12,   SZ_NA    }
+#define O_BL      { OP_BL,       SZ_NA    }
+#define O_BH      { OP_BH,       SZ_NA    }
+#define O_BP      { OP_BP,       SZ_NA    }
+#define O_AHr12b  { OP_AHr12b,   SZ_NA    }
+#define O_BX      { OP_BX,       SZ_NA    }
+#define O_Jz      { OP_J,        SZ_Z     }
+#define O_Jv      { OP_J,        SZ_V     }
+#define O_Jb      { OP_J,        SZ_B     }
+#define O_rSIr14  { OP_rSIr14,   SZ_NA    }
+#define O_GS      { OP_GS,       SZ_NA    }
+#define O_D       { OP_D,        SZ_NA    }
+#define O_rBPr13  { OP_rBPr13,   SZ_NA    }
+#define O_Ob      { OP_O,        SZ_B     }
+#define O_P       { OP_P,        SZ_NA    }
+#define O_Ow      { OP_O,        SZ_W     }
+#define O_Ov      { OP_O,        SZ_V     }
+#define O_Gw      { OP_G,        SZ_W     }
+#define O_Gv      { OP_G,        SZ_V     }
+#define O_rDX     { OP_rDX,      SZ_NA    }
+#define O_Gx      { OP_G,        SZ_MDQ   }
+#define O_Gd      { OP_G,        SZ_D     }
+#define O_Gb      { OP_G,        SZ_B     }
+#define O_rBXr11  { OP_rBXr11,   SZ_NA    }
+#define O_rDI     { OP_rDI,      SZ_NA    }
+#define O_rSI     { OP_rSI,      SZ_NA    }
+#define O_ALr8b   { OP_ALr8b,    SZ_NA    }
+#define O_eDI     { OP_eDI,      SZ_NA    }
+#define O_Gz      { OP_G,        SZ_Z     }
+#define O_eDX     { OP_eDX,      SZ_NA    }
+#define O_DHr14b  { OP_DHr14b,   SZ_NA    }
+#define O_rSP     { OP_rSP,      SZ_NA    }
+#define O_PR      { OP_PR,       SZ_NA    }
+#define O_NONE    { OP_NONE,     SZ_NA    }
+#define O_rCX     { OP_rCX,      SZ_NA    }
+#define O_jWP     { OP_J,        SZ_WP    }
+#define O_rDXr10  { OP_rDXr10,   SZ_NA    }
+#define O_Md      { OP_M,        SZ_D     }
+#define O_C       { OP_C,        SZ_NA    }
+#define O_G       { OP_G,        SZ_NA    }
+#define O_Mb      { OP_M,        SZ_B     }
+#define O_Mt      { OP_M,        SZ_T     }
+#define O_S       { OP_S,        SZ_NA    }
+#define O_Mq      { OP_M,        SZ_Q     }
+#define O_W       { OP_W,        SZ_NA    }
+#define O_ES      { OP_ES,       SZ_NA    }
+#define O_rBX     { OP_rBX,      SZ_NA    }
+#define O_Ed      { OP_E,        SZ_D     }
+#define O_DLr10b  { OP_DLr10b,   SZ_NA    }
+#define O_Mw      { OP_M,        SZ_W     }
+#define O_Eb      { OP_E,        SZ_B     }
+#define O_Ex      { OP_E,        SZ_MDQ   }
+#define O_Ez      { OP_E,        SZ_Z     }
+#define O_Ew      { OP_E,        SZ_W     }
+#define O_Ev      { OP_E,        SZ_V     }
+#define O_Ep      { OP_E,        SZ_P     }
+#define O_FS      { OP_FS,       SZ_NA    }
+#define O_Ms      { OP_M,        SZ_W     }
+#define O_rAXr8   { OP_rAXr8,    SZ_NA    }
+#define O_eBP     { OP_eBP,      SZ_NA    }
+#define O_Isb     { OP_I,        SZ_SB    }
+#define O_eBX     { OP_eBX,      SZ_NA    }
+#define O_rCXr9   { OP_rCXr9,    SZ_NA    }
+#define O_jDP     { OP_J,        SZ_DP    }
+#define O_CH      { OP_CH,       SZ_NA    }
+#define O_CL      { OP_CL,       SZ_NA    }
+#define O_R       { OP_R,        SZ_RDQ   }
+#define O_V       { OP_V,        SZ_NA    }
+#define O_CS      { OP_CS,       SZ_NA    }
+#define O_CHr13b  { OP_CHr13b,   SZ_NA    }
+#define O_eCX     { OP_eCX,      SZ_NA    }
+#define O_eSP     { OP_eSP,      SZ_NA    }
+#define O_SS      { OP_SS,       SZ_NA    }
+#define O_SP      { OP_SP,       SZ_NA    }
+#define O_BLr11b  { OP_BLr11b,   SZ_NA    }
+#define O_SI      { OP_SI,       SZ_NA    }
+#define O_eSI     { OP_eSI,      SZ_NA    }
+#define O_DL      { OP_DL,       SZ_NA    }
+#define O_DH      { OP_DH,       SZ_NA    }
+#define O_DI      { OP_DI,       SZ_NA    }
+#define O_DX      { OP_DX,       SZ_NA    }
+#define O_rBP     { OP_rBP,      SZ_NA    }
+#define O_Gvw     { OP_G,        SZ_MDQ   }
+#define O_I1      { OP_I1,       SZ_NA    }
+#define O_I3      { OP_I3,       SZ_NA    }
+#define O_DS      { OP_DS,       SZ_NA    }
+#define O_ST4     { OP_ST4,      SZ_NA    }
+#define O_ST5     { OP_ST5,      SZ_NA    }
+#define O_ST6     { OP_ST6,      SZ_NA    }
+#define O_ST7     { OP_ST7,      SZ_NA    }
+#define O_ST0     { OP_ST0,      SZ_NA    }
+#define O_ST1     { OP_ST1,      SZ_NA    }
+#define O_ST2     { OP_ST2,      SZ_NA    }
+#define O_ST3     { OP_ST3,      SZ_NA    }
+#define O_E       { OP_E,        SZ_NA    }
+#define O_AH      { OP_AH,       SZ_NA    }
+#define O_M       { OP_M,        SZ_NA    }
+#define O_AL      { OP_AL,       SZ_NA    }
+#define O_CLr9b   { OP_CLr9b,    SZ_NA    }
+#define O_Q       { OP_Q,        SZ_NA    }
+#define O_eAX     { OP_eAX,      SZ_NA    }
+#define O_VR      { OP_VR,       SZ_NA    }
+#define O_AX      { OP_AX,       SZ_NA    }
+#define O_rAX     { OP_rAX,      SZ_NA    }
+#define O_Iz      { OP_I,        SZ_Z     }
+#define O_rDIr15  { OP_rDIr15,   SZ_NA    }
+#define O_Iw      { OP_I,        SZ_W     }
+#define O_Iv      { OP_I,        SZ_V     }
+#define O_Ap      { OP_A,        SZ_P     }
+#define O_CX      { OP_CX,       SZ_NA    }
+#define O_Ib      { OP_I,        SZ_B     }
+#define O_BHr15b  { OP_BHr15b,   SZ_NA    }
+
+
+/* A single operand of an entry in the instruction table. 
+ * (internal use only)
+ */
+struct ud_itab_entry_operand 
+{
+  enum ud_operand_code type;
+  enum ud_operand_size size;
+};
+
+
+/* A single entry in an instruction table. 
+ *(internal use only)
+ */
+struct ud_itab_entry 
+{
+  enum ud_mnemonic_code         mnemonic;
+  struct ud_itab_entry_operand  operand1;
+  struct ud_itab_entry_operand  operand2;
+  struct ud_itab_entry_operand  operand3;
+  uint32_t                      prefix;
+};
+
+#endif /* UD_DECODE_H */
+
+/* vim:cindent
+ * vim:expandtab
+ * vim:ts=4
+ * vim:sw=4
+ */
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/extern.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,67 @@
+/* -----------------------------------------------------------------------------
+ * extern.h
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_EXTERN_H
+#define UD_EXTERN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #include <stdio.h> */
+#include "types.h"
+
+/* ============================= PUBLIC API ================================= */
+
+extern void ud_init(struct ud*);
+
+extern void ud_set_mode(struct ud*, uint8_t);
+
+extern void ud_set_pc(struct ud*, uint64_t);
+
+extern void ud_set_input_hook(struct ud*, int (*)(struct ud*));
+
+extern void ud_set_input_buffer(struct ud*, uint8_t*, size_t);
+
+#ifndef __UD_STANDALONE__
+extern void ud_set_input_file(struct ud*, FILE*);
+#endif /* __UD_STANDALONE__ */
+
+extern void ud_set_vendor(struct ud*, unsigned);
+
+extern void ud_set_syntax(struct ud*, void (*)(struct ud*));
+
+extern void ud_input_skip(struct ud*, size_t);
+
+extern int ud_input_end(struct ud*);
+
+extern unsigned int ud_decode(struct ud*);
+
+extern unsigned int ud_disassemble(struct ud*);
+
+extern void ud_translate_intel(struct ud*);
+
+extern void ud_translate_att(struct ud*);
+
+extern char* ud_insn_asm(struct ud* u);
+
+extern uint8_t* ud_insn_ptr(struct ud* u);
+
+extern uint64_t ud_insn_off(struct ud*);
+
+extern char* ud_insn_hex(struct ud*);
+
+extern unsigned int ud_insn_len(struct ud* u);
+
+extern const char* ud_lookup_mnemonic(enum ud_mnemonic_code c);
+
+/* ========================================================================== */
+
+#ifdef __cplusplus
+}
+#endif
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/input.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,226 @@
+/* -----------------------------------------------------------------------------
+ * input.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#include "extern.h"
+#include "types.h"
+#include "input.h"
+
+/* -----------------------------------------------------------------------------
+ * inp_buff_hook() - Hook for buffered inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_buff_hook(struct ud* u)
+{
+  if (u->inp_buff < u->inp_buff_end)
+	return *u->inp_buff++;
+  else	return -1;
+}
+
+#ifndef __UD_STANDALONE__
+/* -----------------------------------------------------------------------------
+ * inp_file_hook() - Hook for FILE inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_file_hook(struct ud* u)
+{
+  return fgetc(u->inp_file);
+}
+#endif /* __UD_STANDALONE__*/
+
+/* =============================================================================
+ * ud_inp_set_hook() - Sets input hook.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_hook(register struct ud* u, int (*hook)(struct ud*))
+{
+  u->inp_hook = hook;
+  inp_init(u);
+}
+
+/* =============================================================================
+ * ud_inp_set_buffer() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_buffer(register struct ud* u, uint8_t* buf, size_t len)
+{
+  u->inp_hook = inp_buff_hook;
+  u->inp_buff = buf;
+  u->inp_buff_end = buf + len;
+  inp_init(u);
+}
+
+#ifndef __UD_STANDALONE__
+/* =============================================================================
+ * ud_input_set_file() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_file(register struct ud* u, FILE* f)
+{
+  u->inp_hook = inp_file_hook;
+  u->inp_file = f;
+  inp_init(u);
+}
+#endif /* __UD_STANDALONE__ */
+
+/* =============================================================================
+ * ud_input_skip() - Skip n input bytes.
+ * =============================================================================
+ */
+extern void 
+ud_input_skip(struct ud* u, size_t n)
+{
+  while (n--) {
+	u->inp_hook(u);
+  }
+}
+
+/* =============================================================================
+ * ud_input_end() - Test for end of input.
+ * =============================================================================
+ */
+extern int 
+ud_input_end(struct ud* u)
+{
+  return (u->inp_curr == u->inp_fill) && u->inp_end;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_next() - Loads and returns the next byte from input.
+ *
+ * inp_curr and inp_fill are pointers to the cache. The program is written based
+ * on the property that they are 8-bits in size, and will eventually wrap around
+ * forming a circular buffer. So, the size of the cache is 256 in size, kind of
+ * unnecessary yet optimized.
+ *
+ * A buffer inp_sess stores the bytes disassembled for a single session.
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t inp_next(struct ud* u) 
+{
+  int c = -1;
+  /* if current pointer is not upto the fill point in the 
+   * input cache.
+   */
+  if ( u->inp_curr != u->inp_fill ) {
+	c = u->inp_cache[ ++u->inp_curr ];
+  /* if !end-of-input, call the input hook and get a byte */
+  } else if ( u->inp_end || ( c = u->inp_hook( u ) ) == -1 ) {
+	/* end-of-input, mark it as an error, since the decoder,
+	 * expected a byte more.
+	 */
+	u->error = 1;
+	/* flag end of input */
+	u->inp_end = 1;
+	return 0;
+  } else {
+	/* increment pointers, we have a new byte.  */
+	u->inp_curr = ++u->inp_fill;
+	/* add the byte to the cache */
+	u->inp_cache[ u->inp_fill ] = c;
+  }
+  /* record bytes input per decode-session. */
+  u->inp_sess[ u->inp_ctr++ ] = c;
+  /* return byte */
+  return ( uint8_t ) c;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_back() - Move back a single byte in the stream.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_back(struct ud* u) 
+{
+  if ( u->inp_ctr > 0 ) {
+	--u->inp_curr;
+	--u->inp_ctr;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_peek() - Peek into the next byte in source. 
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t
+inp_peek(struct ud* u) 
+{
+  uint8_t r = inp_next(u);
+  if ( !u->error ) inp_back(u); /* Don't backup if there was an error */
+  return r;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_move() - Move ahead n input bytes.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_move(struct ud* u, size_t n) 
+{
+  while (n--)
+	inp_next(u);
+}
+
+/*------------------------------------------------------------------------------
+ *  inp_uintN() - return uintN from source.
+ *------------------------------------------------------------------------------
+ */
+extern uint8_t 
+inp_uint8(struct ud* u)
+{
+  return inp_next(u);
+}
+
+extern uint16_t 
+inp_uint16(struct ud* u)
+{
+  uint16_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  return ret | (r << 8);
+}
+
+extern uint32_t 
+inp_uint32(struct ud* u)
+{
+  uint32_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  return ret | (r << 24);
+}
+
+extern uint64_t 
+inp_uint64(struct ud* u)
+{
+  uint64_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  ret = ret | (r << 24);
+  r = inp_next(u);
+  ret = ret | (r << 32);
+  r = inp_next(u);
+  ret = ret | (r << 40);
+  r = inp_next(u);
+  ret = ret | (r << 48);
+  r = inp_next(u);
+  return ret | (r << 56);
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/input.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,49 @@
+/* -----------------------------------------------------------------------------
+ * input.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_INPUT_H
+#define UD_INPUT_H
+
+#include "types.h"
+
+uint8_t inp_next(struct ud*);
+uint8_t inp_peek(struct ud*);
+uint8_t inp_uint8(struct ud*);
+uint16_t inp_uint16(struct ud*);
+uint32_t inp_uint32(struct ud*);
+uint64_t inp_uint64(struct ud*);
+void inp_move(struct ud*, size_t);
+void inp_back(struct ud*);
+
+/* inp_init() - Initializes the input system. */
+#define inp_init(u) \
+do { \
+  u->inp_curr = 0; \
+  u->inp_fill = 0; \
+  u->inp_ctr  = 0; \
+  u->inp_end  = 0; \
+} while (0)
+
+/* inp_start() - Should be called before each de-code operation. */
+#define inp_start(u) u->inp_ctr = 0
+
+/* inp_back() - Resets the current pointer to its position before the current
+ * instruction disassembly was started.
+ */
+#define inp_reset(u) \
+do { \
+  u->inp_curr -= u->inp_ctr; \
+  u->inp_ctr = 0; \
+} while (0)
+
+/* inp_sess() - Returns the pointer to current session. */
+#define inp_sess(u) (u->inp_sess)
+
+/* inp_cur() - Returns the current input byte. */
+#define inp_curr(u) ((u)->inp_cache[(u)->inp_curr])
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/itab.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3668 @@
+
+/* itab.c -- auto generated by opgen.py, do not edit. */
+
+#include "types.h"
+#include "decode.h"
+#include "itab.h"
+
+const char * ud_mnemonics_str[] = {
+  "3dnow",
+  "aaa",
+  "aad",
+  "aam",
+  "aas",
+  "adc",
+  "add",
+  "addpd",
+  "addps",
+  "addsd",
+  "addss",
+  "addsubpd",
+  "addsubps",
+  "and",
+  "andpd",
+  "andps",
+  "andnpd",
+  "andnps",
+  "arpl",
+  "movsxd",
+  "bound",
+  "bsf",
+  "bsr",
+  "bswap",
+  "bt",
+  "btc",
+  "btr",
+  "bts",
+  "call",
+  "cbw",
+  "cwde",
+  "cdqe",
+  "clc",
+  "cld",
+  "clflush",
+  "clgi",
+  "cli",
+  "clts",
+  "cmc",
+  "cmovo",
+  "cmovno",
+  "cmovb",
+  "cmovae",
+  "cmovz",
+  "cmovnz",
+  "cmovbe",
+  "cmova",
+  "cmovs",
+  "cmovns",
+  "cmovp",
+  "cmovnp",
+  "cmovl",
+  "cmovge",
+  "cmovle",
+  "cmovg",
+  "cmp",
+  "cmppd",
+  "cmpps",
+  "cmpsb",
+  "cmpsw",
+  "cmpsd",
+  "cmpsq",
+  "cmpss",
+  "cmpxchg",
+  "cmpxchg8b",
+  "comisd",
+  "comiss",
+  "cpuid",
+  "cvtdq2pd",
+  "cvtdq2ps",
+  "cvtpd2dq",
+  "cvtpd2pi",
+  "cvtpd2ps",
+  "cvtpi2ps",
+  "cvtpi2pd",
+  "cvtps2dq",
+  "cvtps2pi",
+  "cvtps2pd",
+  "cvtsd2si",
+  "cvtsd2ss",
+  "cvtsi2ss",
+  "cvtss2si",
+  "cvtss2sd",
+  "cvttpd2pi",
+  "cvttpd2dq",
+  "cvttps2dq",
+  "cvttps2pi",
+  "cvttsd2si",
+  "cvtsi2sd",
+  "cvttss2si",
+  "cwd",
+  "cdq",
+  "cqo",
+  "daa",
+  "das",
+  "dec",
+  "div",
+  "divpd",
+  "divps",
+  "divsd",
+  "divss",
+  "emms",
+  "enter",
+  "f2xm1",
+  "fabs",
+  "fadd",
+  "faddp",
+  "fbld",
+  "fbstp",
+  "fchs",
+  "fclex",
+  "fcmovb",
+  "fcmove",
+  "fcmovbe",
+  "fcmovu",
+  "fcmovnb",
+  "fcmovne",
+  "fcmovnbe",
+  "fcmovnu",
+  "fucomi",
+  "fcom",
+  "fcom2",
+  "fcomp3",
+  "fcomi",
+  "fucomip",
+  "fcomip",
+  "fcomp",
+  "fcomp5",
+  "fcompp",
+  "fcos",
+  "fdecstp",
+  "fdiv",
+  "fdivp",
+  "fdivr",
+  "fdivrp",
+  "femms",
+  "ffree",
+  "ffreep",
+  "ficom",
+  "ficomp",
+  "fild",
+  "fncstp",
+  "fninit",
+  "fiadd",
+  "fidivr",
+  "fidiv",
+  "fisub",
+  "fisubr",
+  "fist",
+  "fistp",
+  "fisttp",
+  "fld",
+  "fld1",
+  "fldl2t",
+  "fldl2e",
+  "fldlpi",
+  "fldlg2",
+  "fldln2",
+  "fldz",
+  "fldcw",
+  "fldenv",
+  "fmul",
+  "fmulp",
+  "fimul",
+  "fnop",
+  "fpatan",
+  "fprem",
+  "fprem1",
+  "fptan",
+  "frndint",
+  "frstor",
+  "fnsave",
+  "fscale",
+  "fsin",
+  "fsincos",
+  "fsqrt",
+  "fstp",
+  "fstp1",
+  "fstp8",
+  "fstp9",
+  "fst",
+  "fnstcw",
+  "fnstenv",
+  "fnstsw",
+  "fsub",
+  "fsubp",
+  "fsubr",
+  "fsubrp",
+  "ftst",
+  "fucom",
+  "fucomp",
+  "fucompp",
+  "fxam",
+  "fxch",
+  "fxch4",
+  "fxch7",
+  "fxrstor",
+  "fxsave",
+  "fpxtract",
+  "fyl2x",
+  "fyl2xp1",
+  "haddpd",
+  "haddps",
+  "hlt",
+  "hsubpd",
+  "hsubps",
+  "idiv",
+  "in",
+  "imul",
+  "inc",
+  "insb",
+  "insw",
+  "insd",
+  "int1",
+  "int3",
+  "int",
+  "into",
+  "invd",
+  "invlpg",
+  "invlpga",
+  "iretw",
+  "iretd",
+  "iretq",
+  "jo",
+  "jno",
+  "jb",
+  "jae",
+  "jz",
+  "jnz",
+  "jbe",
+  "ja",
+  "js",
+  "jns",
+  "jp",
+  "jnp",
+  "jl",
+  "jge",
+  "jle",
+  "jg",
+  "jcxz",
+  "jecxz",
+  "jrcxz",
+  "jmp",
+  "lahf",
+  "lar",
+  "lddqu",
+  "ldmxcsr",
+  "lds",
+  "lea",
+  "les",
+  "lfs",
+  "lgs",
+  "lidt",
+  "lss",
+  "leave",
+  "lfence",
+  "lgdt",
+  "lldt",
+  "lmsw",
+  "lock",
+  "lodsb",
+  "lodsw",
+  "lodsd",
+  "lodsq",
+  "loopnz",
+  "loope",
+  "loop",
+  "lsl",
+  "ltr",
+  "maskmovq",
+  "maxpd",
+  "maxps",
+  "maxsd",
+  "maxss",
+  "mfence",
+  "minpd",
+  "minps",
+  "minsd",
+  "minss",
+  "monitor",
+  "mov",
+  "movapd",
+  "movaps",
+  "movd",
+  "movddup",
+  "movdqa",
+  "movdqu",
+  "movdq2q",
+  "movhpd",
+  "movhps",
+  "movlhps",
+  "movlpd",
+  "movlps",
+  "movhlps",
+  "movmskpd",
+  "movmskps",
+  "movntdq",
+  "movnti",
+  "movntpd",
+  "movntps",
+  "movntq",
+  "movq",
+  "movqa",
+  "movq2dq",
+  "movsb",
+  "movsw",
+  "movsd",
+  "movsq",
+  "movsldup",
+  "movshdup",
+  "movss",
+  "movsx",
+  "movupd",
+  "movups",
+  "movzx",
+  "mul",
+  "mulpd",
+  "mulps",
+  "mulsd",
+  "mulss",
+  "mwait",
+  "neg",
+  "nop",
+  "not",
+  "or",
+  "orpd",
+  "orps",
+  "out",
+  "outsb",
+  "outsw",
+  "outsd",
+  "outsq",
+  "packsswb",
+  "packssdw",
+  "packuswb",
+  "paddb",
+  "paddw",
+  "paddq",
+  "paddsb",
+  "paddsw",
+  "paddusb",
+  "paddusw",
+  "pand",
+  "pandn",
+  "pause",
+  "pavgb",
+  "pavgw",
+  "pcmpeqb",
+  "pcmpeqw",
+  "pcmpeqd",
+  "pcmpgtb",
+  "pcmpgtw",
+  "pcmpgtd",
+  "pextrw",
+  "pinsrw",
+  "pmaddwd",
+  "pmaxsw",
+  "pmaxub",
+  "pminsw",
+  "pminub",
+  "pmovmskb",
+  "pmulhuw",
+  "pmulhw",
+  "pmullw",
+  "pmuludq",
+  "pop",
+  "popa",
+  "popad",
+  "popfw",
+  "popfd",
+  "popfq",
+  "por",
+  "prefetch",
+  "prefetchnta",
+  "prefetcht0",
+  "prefetcht1",
+  "prefetcht2",
+  "psadbw",
+  "pshufd",
+  "pshufhw",
+  "pshuflw",
+  "pshufw",
+  "pslldq",
+  "psllw",
+  "pslld",
+  "psllq",
+  "psraw",
+  "psrad",
+  "psrlw",
+  "psrld",
+  "psrlq",
+  "psrldq",
+  "psubb",
+  "psubw",
+  "psubd",
+  "psubq",
+  "psubsb",
+  "psubsw",
+  "psubusb",
+  "psubusw",
+  "punpckhbw",
+  "punpckhwd",
+  "punpckhdq",
+  "punpckhqdq",
+  "punpcklbw",
+  "punpcklwd",
+  "punpckldq",
+  "punpcklqdq",
+  "pi2fw",
+  "pi2fd",
+  "pf2iw",
+  "pf2id",
+  "pfnacc",
+  "pfpnacc",
+  "pfcmpge",
+  "pfmin",
+  "pfrcp",
+  "pfrsqrt",
+  "pfsub",
+  "pfadd",
+  "pfcmpgt",
+  "pfmax",
+  "pfrcpit1",
+  "pfrspit1",
+  "pfsubr",
+  "pfacc",
+  "pfcmpeq",
+  "pfmul",
+  "pfrcpit2",
+  "pmulhrw",
+  "pswapd",
+  "pavgusb",
+  "push",
+  "pusha",
+  "pushad",
+  "pushfw",
+  "pushfd",
+  "pushfq",
+  "pxor",
+  "rcl",
+  "rcr",
+  "rol",
+  "ror",
+  "rcpps",
+  "rcpss",
+  "rdmsr",
+  "rdpmc",
+  "rdtsc",
+  "rdtscp",
+  "repne",
+  "rep",
+  "ret",
+  "retf",
+  "rsm",
+  "rsqrtps",
+  "rsqrtss",
+  "sahf",
+  "sal",
+  "salc",
+  "sar",
+  "shl",
+  "shr",
+  "sbb",
+  "scasb",
+  "scasw",
+  "scasd",
+  "scasq",
+  "seto",
+  "setno",
+  "setb",
+  "setnb",
+  "setz",
+  "setnz",
+  "setbe",
+  "seta",
+  "sets",
+  "setns",
+  "setp",
+  "setnp",
+  "setl",
+  "setge",
+  "setle",
+  "setg",
+  "sfence",
+  "sgdt",
+  "shld",
+  "shrd",
+  "shufpd",
+  "shufps",
+  "sidt",
+  "sldt",
+  "smsw",
+  "sqrtps",
+  "sqrtpd",
+  "sqrtsd",
+  "sqrtss",
+  "stc",
+  "std",
+  "stgi",
+  "sti",
+  "skinit",
+  "stmxcsr",
+  "stosb",
+  "stosw",
+  "stosd",
+  "stosq",
+  "str",
+  "sub",
+  "subpd",
+  "subps",
+  "subsd",
+  "subss",
+  "swapgs",
+  "syscall",
+  "sysenter",
+  "sysexit",
+  "sysret",
+  "test",
+  "ucomisd",
+  "ucomiss",
+  "ud2",
+  "unpckhpd",
+  "unpckhps",
+  "unpcklps",
+  "unpcklpd",
+  "verr",
+  "verw",
+  "vmcall",
+  "vmclear",
+  "vmxon",
+  "vmptrld",
+  "vmptrst",
+  "vmresume",
+  "vmxoff",
+  "vmrun",
+  "vmmcall",
+  "vmload",
+  "vmsave",
+  "wait",
+  "wbinvd",
+  "wrmsr",
+  "xadd",
+  "xchg",
+  "xlatb",
+  "xor",
+  "xorpd",
+  "xorps",
+  "db",
+  "invalid",
+};
+
+
+
+static struct ud_itab_entry itab__0f[256] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_00__REG },
+  /* 01 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG },
+  /* 02 */  { UD_Ilar,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ilsl,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Isyscall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iclts,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isysret,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Iinvd,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Iwbinvd,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iud2,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_0D__REG },
+  /* 0E */  { UD_Ifemms,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovups,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovups,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_18__REG },
+  /* 19 */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1D */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1E */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1F */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 20 */  { UD_Imov,         O_R,     O_C,     O_NONE,  P_rexr },
+  /* 21 */  { UD_Imov,         O_R,     O_D,     O_NONE,  P_rexr },
+  /* 22 */  { UD_Imov,         O_C,     O_R,     O_NONE,  P_rexr },
+  /* 23 */  { UD_Imov,         O_D,     O_R,     O_NONE,  P_rexr },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovaps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovaps,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2ps,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntps,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttps2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtps2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomiss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomiss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iwrmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Irdtsc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Irdmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Irdpmc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Isysenter,    O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 35 */  { UD_Isysexit,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Icmovo,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 41 */  { UD_Icmovno,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 42 */  { UD_Icmovb,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 43 */  { UD_Icmovae,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 44 */  { UD_Icmovz,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 45 */  { UD_Icmovnz,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 46 */  { UD_Icmovbe,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 47 */  { UD_Icmova,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 48 */  { UD_Icmovs,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 49 */  { UD_Icmovns,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4A */  { UD_Icmovp,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4B */  { UD_Icmovnp,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4C */  { UD_Icmovl,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4D */  { UD_Icmovge,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4E */  { UD_Icmovle,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4F */  { UD_Icmovg,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 50 */  { UD_Imovmskps,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtps,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iandps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorps,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtps2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtdq2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Imovd,        O_P,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovq,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufw,      O_P,     O_Q,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iemms,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_P,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovq,        O_Q,     O_P,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Ijo,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 81 */  { UD_Ijno,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 82 */  { UD_Ijb,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 83 */  { UD_Ijae,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 84 */  { UD_Ijz,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 85 */  { UD_Ijnz,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 86 */  { UD_Ijbe,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 87 */  { UD_Ija,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 88 */  { UD_Ijs,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 89 */  { UD_Ijns,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8A */  { UD_Ijp,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8B */  { UD_Ijnp,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8C */  { UD_Ijl,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8D */  { UD_Ijge,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8E */  { UD_Ijle,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8F */  { UD_Ijg,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 90 */  { UD_Iseto,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 91 */  { UD_Isetno,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 92 */  { UD_Isetb,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 93 */  { UD_Isetnb,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 94 */  { UD_Isetz,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 95 */  { UD_Isetnz,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 96 */  { UD_Isetbe,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 97 */  { UD_Iseta,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 98 */  { UD_Isets,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 99 */  { UD_Isetns,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9A */  { UD_Isetp,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9B */  { UD_Isetnp,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9C */  { UD_Isetl,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9D */  { UD_Isetge,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9E */  { UD_Isetle,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9F */  { UD_Isetg,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* A0 */  { UD_Ipush,        O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A1 */  { UD_Ipop,         O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A2 */  { UD_Icpuid,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A3 */  { UD_Ibt,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A4 */  { UD_Ishld,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A5 */  { UD_Ishld,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Ipush,        O_GS,    O_NONE,  O_NONE,  P_none },
+  /* A9 */  { UD_Ipop,         O_GS,    O_NONE,  O_NONE,  P_none },
+  /* AA */  { UD_Irsm,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AB */  { UD_Ibts,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AC */  { UD_Ishrd,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AD */  { UD_Ishrd,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG },
+  /* AF */  { UD_Iimul,        O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B0 */  { UD_Icmpxchg,     O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* B1 */  { UD_Icmpxchg,     O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B2 */  { UD_Ilss,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B3 */  { UD_Ibtr,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B4 */  { UD_Ilfs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B5 */  { UD_Ilgs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B6 */  { UD_Imovzx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B7 */  { UD_Imovzx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_BA__REG },
+  /* BB */  { UD_Ibtc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BC */  { UD_Ibsf,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BD */  { UD_Ibsr,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BE */  { UD_Imovsx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BF */  { UD_Imovsx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpps,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Imovnti,      O_M,     O_Gvw,   O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C4 */  { UD_Ipinsrw,      O_P,     O_Ew,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_PR,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C6 */  { UD_Ishufps,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG },
+  /* C8 */  { UD_Ibswap,       O_rAXr8, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* C9 */  { UD_Ibswap,       O_rCXr9, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* CA */  { UD_Ibswap,       O_rDXr10, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CB */  { UD_Ibswap,       O_rBXr11, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CC */  { UD_Ibswap,       O_rSPr12, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CD */  { UD_Ibswap,       O_rBPr13, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CE */  { UD_Ibswap,       O_rSIr14, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CF */  { UD_Ibswap,       O_rDIr15, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Ipsrlw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_PR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipaddusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipaddusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Imovntq,      O_M,     O_P,     O_NONE,  P_none },
+  /* E8 */  { UD_Ipsubsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_00__reg[8] = {
+  /* 00 */  { UD_Isldt,        O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Istr,         O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Illdt,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iltr,         O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iverr,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iverw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg[8] = {
+  /* 00 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD },
+  /* 01 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD },
+  /* 02 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_02__MOD },
+  /* 03 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD },
+  /* 04 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_04__MOD },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod[2] = {
+  /* 00 */  { UD_Isgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmcall,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmresume,    O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxoff,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod[2] = {
+  /* 00 */  { UD_Isidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imonitor,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imwait,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_02__mod[2] = {
+  /* 00 */  { UD_Ilgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod[2] = {
+  /* 00 */  { UD_Ilidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR },
+  /* 06 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor[2] = {
+  /* 00 */  { UD_Ivmrun,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Ivmmcall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor[2] = {
+  /* 00 */  { UD_Ivmload,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Ivmsave,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Istgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor[2] = {
+  /* 00 */  { UD_Iclgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor[2] = {
+  /* 00 */  { UD_Iskinit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvlpga,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_04__mod[2] = {
+  /* 00 */  { UD_Ismsw,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Ilmsw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iinvlpg,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iswapgs,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Irdtscp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_0d__reg[8] = {
+  /* 00 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_18__reg[8] = {
+  /* 00 */  { UD_Iprefetchnta, O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetcht0,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetcht1,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetcht2,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ildmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Istmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iclflush,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ba__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ibt,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ibts,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ibtr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ibtc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Icmpxchg8b,   O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrld,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrst,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Ifabs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_If2xm1,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte[256] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iadd,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadd,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iadd,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iadd,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iadd,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 06 */  { UD_Ipush,        O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 07 */  { UD_Ipop,         O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 08 */  { UD_Ior,          O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 09 */  { UD_Ior,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0A */  { UD_Ior,          O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 0B */  { UD_Ior,          O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0C */  { UD_Ior,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 0D */  { UD_Ior,          O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 0E */  { UD_Ipush,        O_CS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iadc,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Iadc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Iadc,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iadc,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iadc,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 15 */  { UD_Iadc,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 16 */  { UD_Ipush,        O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 17 */  { UD_Ipop,         O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 18 */  { UD_Isbb,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 19 */  { UD_Isbb,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Isbb,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Isbb,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Isbb,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 1D */  { UD_Isbb,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 1E */  { UD_Ipush,        O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 1F */  { UD_Ipop,         O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 20 */  { UD_Iand,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 21 */  { UD_Iand,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 22 */  { UD_Iand,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 23 */  { UD_Iand,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 24 */  { UD_Iand,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 25 */  { UD_Iand,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Idaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 28 */  { UD_Isub,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Isub,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Isub,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Isub,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Isub,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 2D */  { UD_Isub,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Idas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 30 */  { UD_Ixor,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 31 */  { UD_Ixor,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 32 */  { UD_Ixor,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 33 */  { UD_Ixor,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 34 */  { UD_Ixor,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 35 */  { UD_Ixor,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iaaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 38 */  { UD_Icmp,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 39 */  { UD_Icmp,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3A */  { UD_Icmp,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 3B */  { UD_Icmp,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3C */  { UD_Icmp,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 3D */  { UD_Icmp,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iaas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 40 */  { UD_Iinc,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 41 */  { UD_Iinc,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 42 */  { UD_Iinc,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 43 */  { UD_Iinc,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 44 */  { UD_Iinc,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 45 */  { UD_Iinc,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 46 */  { UD_Iinc,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 47 */  { UD_Iinc,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 48 */  { UD_Idec,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 49 */  { UD_Idec,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 4A */  { UD_Idec,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 4B */  { UD_Idec,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 4C */  { UD_Idec,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 4D */  { UD_Idec,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 4E */  { UD_Idec,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 4F */  { UD_Idec,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 50 */  { UD_Ipush,        O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 51 */  { UD_Ipush,        O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 52 */  { UD_Ipush,        O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 53 */  { UD_Ipush,        O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 54 */  { UD_Ipush,        O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 55 */  { UD_Ipush,        O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 56 */  { UD_Ipush,        O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 57 */  { UD_Ipush,        O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 58 */  { UD_Ipop,         O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 59 */  { UD_Ipop,         O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 5A */  { UD_Ipop,         O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5B */  { UD_Ipop,         O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5C */  { UD_Ipop,         O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5D */  { UD_Ipop,         O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5E */  { UD_Ipop,         O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5F */  { UD_Ipop,         O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 60 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_60__OSIZE },
+  /* 61 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_61__OSIZE },
+  /* 62 */  { UD_Ibound,       O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* 63 */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_63__MODE },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Ipush,        O_Iz,    O_NONE,  O_NONE,  P_c1|P_oso },
+  /* 69 */  { UD_Iimul,        O_Gv,    O_Ev,    O_Iz,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipush,        O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* 6B */  { UD_Iimul,        O_Gv,    O_Ev,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinsb,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6D */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6D__OSIZE },
+  /* 6E */  { UD_Ioutsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6F */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6F__OSIZE },
+  /* 70 */  { UD_Ijo,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 71 */  { UD_Ijno,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 72 */  { UD_Ijb,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 73 */  { UD_Ijae,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 74 */  { UD_Ijz,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 75 */  { UD_Ijnz,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 76 */  { UD_Ijbe,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 77 */  { UD_Ija,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Ijs,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 79 */  { UD_Ijns,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7A */  { UD_Ijp,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7B */  { UD_Ijnp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7C */  { UD_Ijl,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7D */  { UD_Ijge,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7E */  { UD_Ijle,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7F */  { UD_Ijg,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 80 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_80__REG },
+  /* 81 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_81__REG },
+  /* 82 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_82__REG },
+  /* 83 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_83__REG },
+  /* 84 */  { UD_Itest,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 85 */  { UD_Itest,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 86 */  { UD_Ixchg,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 87 */  { UD_Ixchg,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 88 */  { UD_Imov,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 89 */  { UD_Imov,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8A */  { UD_Imov,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 8B */  { UD_Imov,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8C */  { UD_Imov,         O_Ev,    O_S,     O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8D */  { UD_Ilea,         O_Gv,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8E */  { UD_Imov,         O_S,     O_Ev,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8F */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_8F__REG },
+  /* 90 */  { UD_Ixchg,        O_rAXr8, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 91 */  { UD_Ixchg,        O_rCXr9, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 92 */  { UD_Ixchg,        O_rDXr10, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 93 */  { UD_Ixchg,        O_rBXr11, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 94 */  { UD_Ixchg,        O_rSPr12, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 95 */  { UD_Ixchg,        O_rBPr13, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 96 */  { UD_Ixchg,        O_rSIr14, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 97 */  { UD_Ixchg,        O_rDIr15, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 98 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_98__OSIZE },
+  /* 99 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_99__OSIZE },
+  /* 9A */  { UD_Icall,        O_Ap,    O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 9B */  { UD_Iwait,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9C */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE },
+  /* 9D */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE },
+  /* 9E */  { UD_Isahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9F */  { UD_Ilahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A0 */  { UD_Imov,         O_AL,    O_Ob,    O_NONE,  P_none },
+  /* A1 */  { UD_Imov,         O_rAX,   O_Ov,    O_NONE,  P_aso|P_oso|P_rexw },
+  /* A2 */  { UD_Imov,         O_Ob,    O_AL,    O_NONE,  P_none },
+  /* A3 */  { UD_Imov,         O_Ov,    O_rAX,   O_NONE,  P_aso|P_oso|P_rexw },
+  /* A4 */  { UD_Imovsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* A5 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A5__OSIZE },
+  /* A6 */  { UD_Icmpsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A7 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A7__OSIZE },
+  /* A8 */  { UD_Itest,        O_AL,    O_Ib,    O_NONE,  P_none },
+  /* A9 */  { UD_Itest,        O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* AA */  { UD_Istosb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AB */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AB__OSIZE },
+  /* AC */  { UD_Ilodsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AD */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AD__OSIZE },
+  /* AE */  { UD_Iscasb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AF__OSIZE },
+  /* B0 */  { UD_Imov,         O_ALr8b, O_Ib,    O_NONE,  P_rexb },
+  /* B1 */  { UD_Imov,         O_CLr9b, O_Ib,    O_NONE,  P_rexb },
+  /* B2 */  { UD_Imov,         O_DLr10b, O_Ib,    O_NONE, P_rexb },
+  /* B3 */  { UD_Imov,         O_BLr11b, O_Ib,    O_NONE, P_rexb },
+  /* B4 */  { UD_Imov,         O_AHr12b, O_Ib,    O_NONE, P_rexb },
+  /* B5 */  { UD_Imov,         O_CHr13b, O_Ib,    O_NONE, P_rexb },
+  /* B6 */  { UD_Imov,         O_DHr14b, O_Ib,    O_NONE, P_rexb },
+  /* B7 */  { UD_Imov,         O_BHr15b, O_Ib,    O_NONE, P_rexb },
+  /* B8 */  { UD_Imov,         O_rAXr8, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* B9 */  { UD_Imov,         O_rCXr9, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* BA */  { UD_Imov,         O_rDXr10, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BB */  { UD_Imov,         O_rBXr11, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BC */  { UD_Imov,         O_rSPr12, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BD */  { UD_Imov,         O_rBPr13, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BE */  { UD_Imov,         O_rSIr14, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BF */  { UD_Imov,         O_rDIr15, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* C0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C0__REG },
+  /* C1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C1__REG },
+  /* C2 */  { UD_Iret,         O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* C3 */  { UD_Iret,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* C4 */  { UD_Iles,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C5 */  { UD_Ilds,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C6__REG },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C7__REG },
+  /* C8 */  { UD_Ienter,       O_Iw,    O_Ib,    O_NONE,  P_def64|P_depM|P_none },
+  /* C9 */  { UD_Ileave,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CA */  { UD_Iretf,        O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* CB */  { UD_Iretf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CC */  { UD_Iint3,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CD */  { UD_Iint,         O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* CE */  { UD_Iinto,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* CF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_CF__OSIZE },
+  /* D0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D0__REG },
+  /* D1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D1__REG },
+  /* D2 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D2__REG },
+  /* D3 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D3__REG },
+  /* D4 */  { UD_Iaam,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D5 */  { UD_Iaad,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D6 */  { UD_Isalc,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D7 */  { UD_Ixlatb,       O_NONE,  O_NONE,  O_NONE,  P_rexw },
+  /* D8 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD },
+  /* D9 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD },
+  /* DA */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD },
+  /* DB */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD },
+  /* DC */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD },
+  /* DD */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD },
+  /* DE */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD },
+  /* DF */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD },
+  /* E0 */  { UD_Iloopnz,      O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E1 */  { UD_Iloope,       O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E2 */  { UD_Iloop,        O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E3 */  { UD_Igrp_asize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_E3__ASIZE },
+  /* E4 */  { UD_Iin,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* E5 */  { UD_Iin,          O_eAX,   O_Ib,    O_NONE,  P_oso },
+  /* E6 */  { UD_Iout,         O_Ib,    O_AL,    O_NONE,  P_none },
+  /* E7 */  { UD_Iout,         O_Ib,    O_eAX,   O_NONE,  P_oso },
+  /* E8 */  { UD_Icall,        O_Jz,    O_NONE,  O_NONE,  P_def64|P_oso },
+  /* E9 */  { UD_Ijmp,         O_Jz,    O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* EA */  { UD_Ijmp,         O_Ap,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* EB */  { UD_Ijmp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* EC */  { UD_Iin,          O_AL,    O_DX,    O_NONE,  P_none },
+  /* ED */  { UD_Iin,          O_eAX,   O_DX,    O_NONE,  P_oso },
+  /* EE */  { UD_Iout,         O_DX,    O_AL,    O_NONE,  P_none },
+  /* EF */  { UD_Iout,         O_DX,    O_eAX,   O_NONE,  P_oso },
+  /* F0 */  { UD_Ilock,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F1 */  { UD_Iint1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F2 */  { UD_Irepne,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F3 */  { UD_Irep,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F4 */  { UD_Ihlt,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F5 */  { UD_Icmc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F6__REG },
+  /* F7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F7__REG },
+  /* F8 */  { UD_Iclc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F9 */  { UD_Istc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FA */  { UD_Icli,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FB */  { UD_Isti,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FC */  { UD_Icld,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FD */  { UD_Istd,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FE__REG },
+  /* FF */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FF__REG },
+};
+
+static struct ud_itab_entry itab__1byte__op_60__osize[3] = {
+  /* 00 */  { UD_Ipusha,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipushad,      O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_61__osize[3] = {
+  /* 00 */  { UD_Ipopa,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipopad,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_63__mode[3] = {
+  /* 00 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 01 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 02 */  { UD_Imovsxd,      O_Gv,    O_Ed,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexx|P_rexr|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_6d__osize[3] = {
+  /* 00 */  { UD_Iinsw,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Iinsd,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_6f__osize[3] = {
+  /* 00 */  { UD_Ioutsw,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Ioutsd,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Ioutsq,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_80__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_81__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_82__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_83__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_8f__reg[8] = {
+  /* 00 */  { UD_Ipop,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_98__osize[3] = {
+  /* 00 */  { UD_Icbw,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icwde,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icdqe,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_99__osize[3] = {
+  /* 00 */  { UD_Icwd,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icdq,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icqo,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipushfq,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipopfq,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_a5__osize[3] = {
+  /* 00 */  { UD_Imovsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Imovsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Imovsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_a7__osize[3] = {
+  /* 00 */  { UD_Icmpsw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icmpsd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icmpsq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ab__osize[3] = {
+  /* 00 */  { UD_Istosw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Istosd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Istosq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ad__osize[3] = {
+  /* 00 */  { UD_Ilodsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Ilodsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Ilodsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AE__MOD__OP_00__REG },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifxsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifxrstor,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_af__osize[3] = {
+  /* 00 */  { UD_Iscasw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iscasd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iscasq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_c0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c6__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_c7__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_cf__osize[3] = {
+  /* 00 */  { UD_Iiretw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iiretd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iiretq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_d0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d2__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d3__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsub,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsub,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsub,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsub,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsub,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsub,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsub,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdiv,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdiv,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdiv,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdiv,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdiv,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdiv,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdiv,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ifst,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifldenv,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifldcw,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifnstenv,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstcw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifld,         O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifld,         O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifld,         O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifld,         O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifld,         O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifld,         O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifld,         O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifld,         O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifnop,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Ifstp1,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp1,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp1,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp1,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp1,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp1,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp1,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp1,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifchs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iftst,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifxam,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifld1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifldl2t,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifldl2e,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifldlpi,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifldlg2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifldln2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifldz,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Ifyl2x,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Ifptan,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Ifpatan,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Ifpxtract,    O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 35 */  { UD_Ifprem1,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Ifdecstp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 37 */  { UD_Ifncstp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 38 */  { UD_Ifprem,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 39 */  { UD_Ifyl2xp1,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3A */  { UD_Ifsqrt,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3B */  { UD_Ifsincos,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3C */  { UD_Ifrndint,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3D */  { UD_Ifscale,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3E */  { UD_Ifsin,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3F */  { UD_Ifcos,        O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovb,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovb,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovb,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovb,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovb,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovb,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovb,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovb,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmove,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmove,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmove,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmove,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmove,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmove,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmove,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmove,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovbe,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovbe,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovbe,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovbe,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovbe,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovbe,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovbe,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovbe,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovu,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovu,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovu,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovu,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovu,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovu,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovu,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovu,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Ifucompp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Ifld,         O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Ifstp,        O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovnb,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovnb,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovnb,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovnb,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovnb,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovnb,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovnb,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovnb,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmovne,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmovne,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmovne,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmovne,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmovne,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmovne,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmovne,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmovne,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovnbe,    O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovnbe,    O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovnbe,    O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovnbe,    O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovnbe,    O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovnbe,    O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovnbe,    O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovnbe,    O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovnu,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovnu,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovnu,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovnu,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovnu,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovnu,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovnu,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovnu,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Ifclex,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifninit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomi,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomi,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomi,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomi,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomi,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomi,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomi,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomi,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomi,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomi,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomi,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomi,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomi,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomi,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomi,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomi,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom2,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom2,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom2,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom2,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom2,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom2,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom2,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom2,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp3,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp3,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp3,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp3,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp3,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp3,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp3,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp3,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsub,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsub,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsub,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsub,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsub,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsub,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsub,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdiv,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdiv,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdiv,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdiv,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdiv,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdiv,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdiv,        O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifst,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifrstor,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ifnsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstsw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffree,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffree,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffree,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffree,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffree,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffree,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffree,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffree,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch4,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch4,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch4,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch4,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch4,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch4,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch4,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch4,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifst,         O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifst,         O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifst,         O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifst,         O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifst,         O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifst,         O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifst,         O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifst,         O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp,        O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp,        O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp,        O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp,        O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp,        O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp,        O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp,        O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp,        O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifucom,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Ifucom,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Ifucom,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifucom,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Ifucom,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifucom,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Ifucom,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 27 */  { UD_Ifucom,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 28 */  { UD_Ifucomp,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomp,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomp,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomp,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomp,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomp,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomp,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomp,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifaddp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifaddp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifaddp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifaddp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifaddp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifaddp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifaddp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifaddp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmulp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmulp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmulp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmulp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmulp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmulp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmulp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmulp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcomp5,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcomp5,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcomp5,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcomp5,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcomp5,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcomp5,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcomp5,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcomp5,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Ifcompp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Ifsubrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifbld,        O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifild,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifbstp,       O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifistp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffreep,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffreep,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffreep,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffreep,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffreep,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffreep,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffreep,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffreep,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch7,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch7,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch7,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch7,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch7,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch7,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch7,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch7,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifstp8,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifstp8,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifstp8,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifstp8,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifstp8,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifstp8,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifstp8,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifstp8,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp9,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp9,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp9,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp9,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp9,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp9,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp9,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp9,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifnstsw,      O_AX,    O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomip,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomip,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomip,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomip,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomip,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomip,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomip,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomip,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomip,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomip,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomip,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomip,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomip,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomip,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomip,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomip,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_e3__asize[3] = {
+  /* 00 */  { UD_Ijcxz,        O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 01 */  { UD_Ijecxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 02 */  { UD_Ijrcxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+};
+
+static struct ud_itab_entry itab__1byte__op_f6__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_f7__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_fe__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ff__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Icall,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Icall,        O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ijmp,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ijmp,         O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ipush,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__3dnow[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 59 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovupd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovupd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovapd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovapd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2pd,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntpd,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttpd2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtpd2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomisd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomisd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Imovmskpd,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iandpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorpd,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtpd2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtps2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Ipunpcklqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6D */  { UD_Ipunpckhqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6E */  { UD_Imovd,        O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovqa,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_V,     O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqa,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmppd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Ipinsrw,      O_V,     O_Ew,    O_Ib,    P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_VR,    O_Ib,    P_aso|P_rexr|P_rexb },
+  /* C6 */  { UD_Ishufpd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Ipsrlw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Imovq,        O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_VR,    O_NONE,  P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Icvttpd2dq,   O_V,     O_W,     O_NONE,  P_none },
+  /* E7 */  { UD_Imovntdq,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E8 */  { UD_Ipsubsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Ipsrldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Ipslldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmclear,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_ssef2__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovsd,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovddup,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2sd,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttsd2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtsd2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtsd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtsd2ss,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Isubsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Ipshuflw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpsd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovdq2q,     O_P,     O_VR,    O_NONE,  P_aso|P_rexb },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtpd2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Ilddqu,       O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovss,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovsldup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Imovshdup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2ss,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttss2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtss2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtss2sd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvttps2dq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Imovdqu,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufhw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovq,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqu,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpss,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovq2dq,     O_V,     O_PR,    O_NONE,  P_aso },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtdq2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxon,       O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+/* the order of this table matches enum ud_itab_index */
+struct ud_itab_entry * ud_itab_list[] = {
+  itab__0f,
+  itab__0f__op_00__reg,
+  itab__0f__op_01__reg,
+  itab__0f__op_01__reg__op_00__mod,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_01__mod,
+  itab__0f__op_01__reg__op_01__mod__op_01__rm,
+  itab__0f__op_01__reg__op_02__mod,
+  itab__0f__op_01__reg__op_03__mod,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor,
+  itab__0f__op_01__reg__op_04__mod,
+  itab__0f__op_01__reg__op_06__mod,
+  itab__0f__op_01__reg__op_07__mod,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_0d__reg,
+  itab__0f__op_18__reg,
+  itab__0f__op_71__reg,
+  itab__0f__op_72__reg,
+  itab__0f__op_73__reg,
+  itab__0f__op_ae__reg,
+  itab__0f__op_ae__reg__op_05__mod,
+  itab__0f__op_ae__reg__op_05__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_06__mod,
+  itab__0f__op_ae__reg__op_06__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_07__mod,
+  itab__0f__op_ae__reg__op_07__mod__op_01__rm,
+  itab__0f__op_ba__reg,
+  itab__0f__op_c7__reg,
+  itab__0f__op_c7__reg__op_00__vendor,
+  itab__0f__op_c7__reg__op_07__vendor,
+  itab__0f__op_d9__mod,
+  itab__0f__op_d9__mod__op_01__x87,
+  itab__1byte,
+  itab__1byte__op_60__osize,
+  itab__1byte__op_61__osize,
+  itab__1byte__op_63__mode,
+  itab__1byte__op_6d__osize,
+  itab__1byte__op_6f__osize,
+  itab__1byte__op_80__reg,
+  itab__1byte__op_81__reg,
+  itab__1byte__op_82__reg,
+  itab__1byte__op_83__reg,
+  itab__1byte__op_8f__reg,
+  itab__1byte__op_98__osize,
+  itab__1byte__op_99__osize,
+  itab__1byte__op_9c__mode,
+  itab__1byte__op_9c__mode__op_00__osize,
+  itab__1byte__op_9c__mode__op_01__osize,
+  itab__1byte__op_9d__mode,
+  itab__1byte__op_9d__mode__op_00__osize,
+  itab__1byte__op_9d__mode__op_01__osize,
+  itab__1byte__op_a5__osize,
+  itab__1byte__op_a7__osize,
+  itab__1byte__op_ab__osize,
+  itab__1byte__op_ad__osize,
+  itab__1byte__op_ae__mod,
+  itab__1byte__op_ae__mod__op_00__reg,
+  itab__1byte__op_af__osize,
+  itab__1byte__op_c0__reg,
+  itab__1byte__op_c1__reg,
+  itab__1byte__op_c6__reg,
+  itab__1byte__op_c7__reg,
+  itab__1byte__op_cf__osize,
+  itab__1byte__op_d0__reg,
+  itab__1byte__op_d1__reg,
+  itab__1byte__op_d2__reg,
+  itab__1byte__op_d3__reg,
+  itab__1byte__op_d8__mod,
+  itab__1byte__op_d8__mod__op_00__reg,
+  itab__1byte__op_d8__mod__op_01__x87,
+  itab__1byte__op_d9__mod,
+  itab__1byte__op_d9__mod__op_00__reg,
+  itab__1byte__op_d9__mod__op_01__x87,
+  itab__1byte__op_da__mod,
+  itab__1byte__op_da__mod__op_00__reg,
+  itab__1byte__op_da__mod__op_01__x87,
+  itab__1byte__op_db__mod,
+  itab__1byte__op_db__mod__op_00__reg,
+  itab__1byte__op_db__mod__op_01__x87,
+  itab__1byte__op_dc__mod,
+  itab__1byte__op_dc__mod__op_00__reg,
+  itab__1byte__op_dc__mod__op_01__x87,
+  itab__1byte__op_dd__mod,
+  itab__1byte__op_dd__mod__op_00__reg,
+  itab__1byte__op_dd__mod__op_01__x87,
+  itab__1byte__op_de__mod,
+  itab__1byte__op_de__mod__op_00__reg,
+  itab__1byte__op_de__mod__op_01__x87,
+  itab__1byte__op_df__mod,
+  itab__1byte__op_df__mod__op_00__reg,
+  itab__1byte__op_df__mod__op_01__x87,
+  itab__1byte__op_e3__asize,
+  itab__1byte__op_f6__reg,
+  itab__1byte__op_f7__reg,
+  itab__1byte__op_fe__reg,
+  itab__1byte__op_ff__reg,
+  itab__3dnow,
+  itab__pfx_sse66__0f,
+  itab__pfx_sse66__0f__op_71__reg,
+  itab__pfx_sse66__0f__op_72__reg,
+  itab__pfx_sse66__0f__op_73__reg,
+  itab__pfx_sse66__0f__op_c7__reg,
+  itab__pfx_sse66__0f__op_c7__reg__op_00__vendor,
+  itab__pfx_ssef2__0f,
+  itab__pfx_ssef3__0f,
+  itab__pfx_ssef3__0f__op_c7__reg,
+  itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor,
+};
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/itab.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,719 @@
+
+/* itab.h -- auto generated by opgen.py, do not edit. */
+
+#ifndef UD_ITAB_H
+#define UD_ITAB_H
+
+
+
+enum ud_itab_vendor_index {
+  ITAB__VENDOR_INDX__AMD,
+  ITAB__VENDOR_INDX__INTEL,
+};
+
+
+enum ud_itab_mode_index {
+  ITAB__MODE_INDX__16,
+  ITAB__MODE_INDX__32,
+  ITAB__MODE_INDX__64
+};
+
+
+enum ud_itab_mod_index {
+  ITAB__MOD_INDX__NOT_11,
+  ITAB__MOD_INDX__11
+};
+
+
+enum ud_itab_index {
+  ITAB__0F,
+  ITAB__0F__OP_00__REG,
+  ITAB__0F__OP_01__REG,
+  ITAB__0F__OP_01__REG__OP_00__MOD,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_01__MOD,
+  ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_02__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR,
+  ITAB__0F__OP_01__REG__OP_04__MOD,
+  ITAB__0F__OP_01__REG__OP_06__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_0D__REG,
+  ITAB__0F__OP_18__REG,
+  ITAB__0F__OP_71__REG,
+  ITAB__0F__OP_72__REG,
+  ITAB__0F__OP_73__REG,
+  ITAB__0F__OP_AE__REG,
+  ITAB__0F__OP_AE__REG__OP_05__MOD,
+  ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_06__MOD,
+  ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_07__MOD,
+  ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_BA__REG,
+  ITAB__0F__OP_C7__REG,
+  ITAB__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__0F__OP_C7__REG__OP_07__VENDOR,
+  ITAB__0F__OP_D9__MOD,
+  ITAB__0F__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE,
+  ITAB__1BYTE__OP_60__OSIZE,
+  ITAB__1BYTE__OP_61__OSIZE,
+  ITAB__1BYTE__OP_63__MODE,
+  ITAB__1BYTE__OP_6D__OSIZE,
+  ITAB__1BYTE__OP_6F__OSIZE,
+  ITAB__1BYTE__OP_80__REG,
+  ITAB__1BYTE__OP_81__REG,
+  ITAB__1BYTE__OP_82__REG,
+  ITAB__1BYTE__OP_83__REG,
+  ITAB__1BYTE__OP_8F__REG,
+  ITAB__1BYTE__OP_98__OSIZE,
+  ITAB__1BYTE__OP_99__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE,
+  ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE,
+  ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_A5__OSIZE,
+  ITAB__1BYTE__OP_A7__OSIZE,
+  ITAB__1BYTE__OP_AB__OSIZE,
+  ITAB__1BYTE__OP_AD__OSIZE,
+  ITAB__1BYTE__OP_AE__MOD,
+  ITAB__1BYTE__OP_AE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_AF__OSIZE,
+  ITAB__1BYTE__OP_C0__REG,
+  ITAB__1BYTE__OP_C1__REG,
+  ITAB__1BYTE__OP_C6__REG,
+  ITAB__1BYTE__OP_C7__REG,
+  ITAB__1BYTE__OP_CF__OSIZE,
+  ITAB__1BYTE__OP_D0__REG,
+  ITAB__1BYTE__OP_D1__REG,
+  ITAB__1BYTE__OP_D2__REG,
+  ITAB__1BYTE__OP_D3__REG,
+  ITAB__1BYTE__OP_D8__MOD,
+  ITAB__1BYTE__OP_D8__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D8__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_D9__MOD,
+  ITAB__1BYTE__OP_D9__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DA__MOD,
+  ITAB__1BYTE__OP_DA__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DA__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DB__MOD,
+  ITAB__1BYTE__OP_DB__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DB__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DC__MOD,
+  ITAB__1BYTE__OP_DC__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DC__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DD__MOD,
+  ITAB__1BYTE__OP_DD__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DD__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DE__MOD,
+  ITAB__1BYTE__OP_DE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DE__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DF__MOD,
+  ITAB__1BYTE__OP_DF__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DF__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_E3__ASIZE,
+  ITAB__1BYTE__OP_F6__REG,
+  ITAB__1BYTE__OP_F7__REG,
+  ITAB__1BYTE__OP_FE__REG,
+  ITAB__1BYTE__OP_FF__REG,
+  ITAB__3DNOW,
+  ITAB__PFX_SSE66__0F,
+  ITAB__PFX_SSE66__0F__OP_71__REG,
+  ITAB__PFX_SSE66__0F__OP_72__REG,
+  ITAB__PFX_SSE66__0F__OP_73__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__PFX_SSEF2__0F,
+  ITAB__PFX_SSEF3__0F,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR,
+};
+
+
+enum ud_mnemonic_code {
+  UD_I3dnow,
+  UD_Iaaa,
+  UD_Iaad,
+  UD_Iaam,
+  UD_Iaas,
+  UD_Iadc,
+  UD_Iadd,
+  UD_Iaddpd,
+  UD_Iaddps,
+  UD_Iaddsd,
+  UD_Iaddss,
+  UD_Iaddsubpd,
+  UD_Iaddsubps,
+  UD_Iand,
+  UD_Iandpd,
+  UD_Iandps,
+  UD_Iandnpd,
+  UD_Iandnps,
+  UD_Iarpl,
+  UD_Imovsxd,
+  UD_Ibound,
+  UD_Ibsf,
+  UD_Ibsr,
+  UD_Ibswap,
+  UD_Ibt,
+  UD_Ibtc,
+  UD_Ibtr,
+  UD_Ibts,
+  UD_Icall,
+  UD_Icbw,
+  UD_Icwde,
+  UD_Icdqe,
+  UD_Iclc,
+  UD_Icld,
+  UD_Iclflush,
+  UD_Iclgi,
+  UD_Icli,
+  UD_Iclts,
+  UD_Icmc,
+  UD_Icmovo,
+  UD_Icmovno,
+  UD_Icmovb,
+  UD_Icmovae,
+  UD_Icmovz,
+  UD_Icmovnz,
+  UD_Icmovbe,
+  UD_Icmova,
+  UD_Icmovs,
+  UD_Icmovns,
+  UD_Icmovp,
+  UD_Icmovnp,
+  UD_Icmovl,
+  UD_Icmovge,
+  UD_Icmovle,
+  UD_Icmovg,
+  UD_Icmp,
+  UD_Icmppd,
+  UD_Icmpps,
+  UD_Icmpsb,
+  UD_Icmpsw,
+  UD_Icmpsd,
+  UD_Icmpsq,
+  UD_Icmpss,
+  UD_Icmpxchg,
+  UD_Icmpxchg8b,
+  UD_Icomisd,
+  UD_Icomiss,
+  UD_Icpuid,
+  UD_Icvtdq2pd,
+  UD_Icvtdq2ps,
+  UD_Icvtpd2dq,
+  UD_Icvtpd2pi,
+  UD_Icvtpd2ps,
+  UD_Icvtpi2ps,
+  UD_Icvtpi2pd,
+  UD_Icvtps2dq,
+  UD_Icvtps2pi,
+  UD_Icvtps2pd,
+  UD_Icvtsd2si,
+  UD_Icvtsd2ss,
+  UD_Icvtsi2ss,
+  UD_Icvtss2si,
+  UD_Icvtss2sd,
+  UD_Icvttpd2pi,
+  UD_Icvttpd2dq,
+  UD_Icvttps2dq,
+  UD_Icvttps2pi,
+  UD_Icvttsd2si,
+  UD_Icvtsi2sd,
+  UD_Icvttss2si,
+  UD_Icwd,
+  UD_Icdq,
+  UD_Icqo,
+  UD_Idaa,
+  UD_Idas,
+  UD_Idec,
+  UD_Idiv,
+  UD_Idivpd,
+  UD_Idivps,
+  UD_Idivsd,
+  UD_Idivss,
+  UD_Iemms,
+  UD_Ienter,
+  UD_If2xm1,
+  UD_Ifabs,
+  UD_Ifadd,
+  UD_Ifaddp,
+  UD_Ifbld,
+  UD_Ifbstp,
+  UD_Ifchs,
+  UD_Ifclex,
+  UD_Ifcmovb,
+  UD_Ifcmove,
+  UD_Ifcmovbe,
+  UD_Ifcmovu,
+  UD_Ifcmovnb,
+  UD_Ifcmovne,
+  UD_Ifcmovnbe,
+  UD_Ifcmovnu,
+  UD_Ifucomi,
+  UD_Ifcom,
+  UD_Ifcom2,
+  UD_Ifcomp3,
+  UD_Ifcomi,
+  UD_Ifucomip,
+  UD_Ifcomip,
+  UD_Ifcomp,
+  UD_Ifcomp5,
+  UD_Ifcompp,
+  UD_Ifcos,
+  UD_Ifdecstp,
+  UD_Ifdiv,
+  UD_Ifdivp,
+  UD_Ifdivr,
+  UD_Ifdivrp,
+  UD_Ifemms,
+  UD_Iffree,
+  UD_Iffreep,
+  UD_Ificom,
+  UD_Ificomp,
+  UD_Ifild,
+  UD_Ifncstp,
+  UD_Ifninit,
+  UD_Ifiadd,
+  UD_Ifidivr,
+  UD_Ifidiv,
+  UD_Ifisub,
+  UD_Ifisubr,
+  UD_Ifist,
+  UD_Ifistp,
+  UD_Ifisttp,
+  UD_Ifld,
+  UD_Ifld1,
+  UD_Ifldl2t,
+  UD_Ifldl2e,
+  UD_Ifldlpi,
+  UD_Ifldlg2,
+  UD_Ifldln2,
+  UD_Ifldz,
+  UD_Ifldcw,
+  UD_Ifldenv,
+  UD_Ifmul,
+  UD_Ifmulp,
+  UD_Ifimul,
+  UD_Ifnop,
+  UD_Ifpatan,
+  UD_Ifprem,
+  UD_Ifprem1,
+  UD_Ifptan,
+  UD_Ifrndint,
+  UD_Ifrstor,
+  UD_Ifnsave,
+  UD_Ifscale,
+  UD_Ifsin,
+  UD_Ifsincos,
+  UD_Ifsqrt,
+  UD_Ifstp,
+  UD_Ifstp1,
+  UD_Ifstp8,
+  UD_Ifstp9,
+  UD_Ifst,
+  UD_Ifnstcw,
+  UD_Ifnstenv,
+  UD_Ifnstsw,
+  UD_Ifsub,
+  UD_Ifsubp,
+  UD_Ifsubr,
+  UD_Ifsubrp,
+  UD_Iftst,
+  UD_Ifucom,
+  UD_Ifucomp,
+  UD_Ifucompp,
+  UD_Ifxam,
+  UD_Ifxch,
+  UD_Ifxch4,
+  UD_Ifxch7,
+  UD_Ifxrstor,
+  UD_Ifxsave,
+  UD_Ifpxtract,
+  UD_Ifyl2x,
+  UD_Ifyl2xp1,
+  UD_Ihaddpd,
+  UD_Ihaddps,
+  UD_Ihlt,
+  UD_Ihsubpd,
+  UD_Ihsubps,
+  UD_Iidiv,
+  UD_Iin,
+  UD_Iimul,
+  UD_Iinc,
+  UD_Iinsb,
+  UD_Iinsw,
+  UD_Iinsd,
+  UD_Iint1,
+  UD_Iint3,
+  UD_Iint,
+  UD_Iinto,
+  UD_Iinvd,
+  UD_Iinvlpg,
+  UD_Iinvlpga,
+  UD_Iiretw,
+  UD_Iiretd,
+  UD_Iiretq,
+  UD_Ijo,
+  UD_Ijno,
+  UD_Ijb,
+  UD_Ijae,
+  UD_Ijz,
+  UD_Ijnz,
+  UD_Ijbe,
+  UD_Ija,
+  UD_Ijs,
+  UD_Ijns,
+  UD_Ijp,
+  UD_Ijnp,
+  UD_Ijl,
+  UD_Ijge,
+  UD_Ijle,
+  UD_Ijg,
+  UD_Ijcxz,
+  UD_Ijecxz,
+  UD_Ijrcxz,
+  UD_Ijmp,
+  UD_Ilahf,
+  UD_Ilar,
+  UD_Ilddqu,
+  UD_Ildmxcsr,
+  UD_Ilds,
+  UD_Ilea,
+  UD_Iles,
+  UD_Ilfs,
+  UD_Ilgs,
+  UD_Ilidt,
+  UD_Ilss,
+  UD_Ileave,
+  UD_Ilfence,
+  UD_Ilgdt,
+  UD_Illdt,
+  UD_Ilmsw,
+  UD_Ilock,
+  UD_Ilodsb,
+  UD_Ilodsw,
+  UD_Ilodsd,
+  UD_Ilodsq,
+  UD_Iloopnz,
+  UD_Iloope,
+  UD_Iloop,
+  UD_Ilsl,
+  UD_Iltr,
+  UD_Imaskmovq,
+  UD_Imaxpd,
+  UD_Imaxps,
+  UD_Imaxsd,
+  UD_Imaxss,
+  UD_Imfence,
+  UD_Iminpd,
+  UD_Iminps,
+  UD_Iminsd,
+  UD_Iminss,
+  UD_Imonitor,
+  UD_Imov,
+  UD_Imovapd,
+  UD_Imovaps,
+  UD_Imovd,
+  UD_Imovddup,
+  UD_Imovdqa,
+  UD_Imovdqu,
+  UD_Imovdq2q,
+  UD_Imovhpd,
+  UD_Imovhps,
+  UD_Imovlhps,
+  UD_Imovlpd,
+  UD_Imovlps,
+  UD_Imovhlps,
+  UD_Imovmskpd,
+  UD_Imovmskps,
+  UD_Imovntdq,
+  UD_Imovnti,
+  UD_Imovntpd,
+  UD_Imovntps,
+  UD_Imovntq,
+  UD_Imovq,
+  UD_Imovqa,
+  UD_Imovq2dq,
+  UD_Imovsb,
+  UD_Imovsw,
+  UD_Imovsd,
+  UD_Imovsq,
+  UD_Imovsldup,
+  UD_Imovshdup,
+  UD_Imovss,
+  UD_Imovsx,
+  UD_Imovupd,
+  UD_Imovups,
+  UD_Imovzx,
+  UD_Imul,
+  UD_Imulpd,
+  UD_Imulps,
+  UD_Imulsd,
+  UD_Imulss,
+  UD_Imwait,
+  UD_Ineg,
+  UD_Inop,
+  UD_Inot,
+  UD_Ior,
+  UD_Iorpd,
+  UD_Iorps,
+  UD_Iout,
+  UD_Ioutsb,
+  UD_Ioutsw,
+  UD_Ioutsd,
+  UD_Ioutsq,
+  UD_Ipacksswb,
+  UD_Ipackssdw,
+  UD_Ipackuswb,
+  UD_Ipaddb,
+  UD_Ipaddw,
+  UD_Ipaddq,
+  UD_Ipaddsb,
+  UD_Ipaddsw,
+  UD_Ipaddusb,
+  UD_Ipaddusw,
+  UD_Ipand,
+  UD_Ipandn,
+  UD_Ipause,
+  UD_Ipavgb,
+  UD_Ipavgw,
+  UD_Ipcmpeqb,
+  UD_Ipcmpeqw,
+  UD_Ipcmpeqd,
+  UD_Ipcmpgtb,
+  UD_Ipcmpgtw,
+  UD_Ipcmpgtd,
+  UD_Ipextrw,
+  UD_Ipinsrw,
+  UD_Ipmaddwd,
+  UD_Ipmaxsw,
+  UD_Ipmaxub,
+  UD_Ipminsw,
+  UD_Ipminub,
+  UD_Ipmovmskb,
+  UD_Ipmulhuw,
+  UD_Ipmulhw,
+  UD_Ipmullw,
+  UD_Ipmuludq,
+  UD_Ipop,
+  UD_Ipopa,
+  UD_Ipopad,
+  UD_Ipopfw,
+  UD_Ipopfd,
+  UD_Ipopfq,
+  UD_Ipor,
+  UD_Iprefetch,
+  UD_Iprefetchnta,
+  UD_Iprefetcht0,
+  UD_Iprefetcht1,
+  UD_Iprefetcht2,
+  UD_Ipsadbw,
+  UD_Ipshufd,
+  UD_Ipshufhw,
+  UD_Ipshuflw,
+  UD_Ipshufw,
+  UD_Ipslldq,
+  UD_Ipsllw,
+  UD_Ipslld,
+  UD_Ipsllq,
+  UD_Ipsraw,
+  UD_Ipsrad,
+  UD_Ipsrlw,
+  UD_Ipsrld,
+  UD_Ipsrlq,
+  UD_Ipsrldq,
+  UD_Ipsubb,
+  UD_Ipsubw,
+  UD_Ipsubd,
+  UD_Ipsubq,
+  UD_Ipsubsb,
+  UD_Ipsubsw,
+  UD_Ipsubusb,
+  UD_Ipsubusw,
+  UD_Ipunpckhbw,
+  UD_Ipunpckhwd,
+  UD_Ipunpckhdq,
+  UD_Ipunpckhqdq,
+  UD_Ipunpcklbw,
+  UD_Ipunpcklwd,
+  UD_Ipunpckldq,
+  UD_Ipunpcklqdq,
+  UD_Ipi2fw,
+  UD_Ipi2fd,
+  UD_Ipf2iw,
+  UD_Ipf2id,
+  UD_Ipfnacc,
+  UD_Ipfpnacc,
+  UD_Ipfcmpge,
+  UD_Ipfmin,
+  UD_Ipfrcp,
+  UD_Ipfrsqrt,
+  UD_Ipfsub,
+  UD_Ipfadd,
+  UD_Ipfcmpgt,
+  UD_Ipfmax,
+  UD_Ipfrcpit1,
+  UD_Ipfrspit1,
+  UD_Ipfsubr,
+  UD_Ipfacc,
+  UD_Ipfcmpeq,
+  UD_Ipfmul,
+  UD_Ipfrcpit2,
+  UD_Ipmulhrw,
+  UD_Ipswapd,
+  UD_Ipavgusb,
+  UD_Ipush,
+  UD_Ipusha,
+  UD_Ipushad,
+  UD_Ipushfw,
+  UD_Ipushfd,
+  UD_Ipushfq,
+  UD_Ipxor,
+  UD_Ircl,
+  UD_Ircr,
+  UD_Irol,
+  UD_Iror,
+  UD_Ircpps,
+  UD_Ircpss,
+  UD_Irdmsr,
+  UD_Irdpmc,
+  UD_Irdtsc,
+  UD_Irdtscp,
+  UD_Irepne,
+  UD_Irep,
+  UD_Iret,
+  UD_Iretf,
+  UD_Irsm,
+  UD_Irsqrtps,
+  UD_Irsqrtss,
+  UD_Isahf,
+  UD_Isal,
+  UD_Isalc,
+  UD_Isar,
+  UD_Ishl,
+  UD_Ishr,
+  UD_Isbb,
+  UD_Iscasb,
+  UD_Iscasw,
+  UD_Iscasd,
+  UD_Iscasq,
+  UD_Iseto,
+  UD_Isetno,
+  UD_Isetb,
+  UD_Isetnb,
+  UD_Isetz,
+  UD_Isetnz,
+  UD_Isetbe,
+  UD_Iseta,
+  UD_Isets,
+  UD_Isetns,
+  UD_Isetp,
+  UD_Isetnp,
+  UD_Isetl,
+  UD_Isetge,
+  UD_Isetle,
+  UD_Isetg,
+  UD_Isfence,
+  UD_Isgdt,
+  UD_Ishld,
+  UD_Ishrd,
+  UD_Ishufpd,
+  UD_Ishufps,
+  UD_Isidt,
+  UD_Isldt,
+  UD_Ismsw,
+  UD_Isqrtps,
+  UD_Isqrtpd,
+  UD_Isqrtsd,
+  UD_Isqrtss,
+  UD_Istc,
+  UD_Istd,
+  UD_Istgi,
+  UD_Isti,
+  UD_Iskinit,
+  UD_Istmxcsr,
+  UD_Istosb,
+  UD_Istosw,
+  UD_Istosd,
+  UD_Istosq,
+  UD_Istr,
+  UD_Isub,
+  UD_Isubpd,
+  UD_Isubps,
+  UD_Isubsd,
+  UD_Isubss,
+  UD_Iswapgs,
+  UD_Isyscall,
+  UD_Isysenter,
+  UD_Isysexit,
+  UD_Isysret,
+  UD_Itest,
+  UD_Iucomisd,
+  UD_Iucomiss,
+  UD_Iud2,
+  UD_Iunpckhpd,
+  UD_Iunpckhps,
+  UD_Iunpcklps,
+  UD_Iunpcklpd,
+  UD_Iverr,
+  UD_Iverw,
+  UD_Ivmcall,
+  UD_Ivmclear,
+  UD_Ivmxon,
+  UD_Ivmptrld,
+  UD_Ivmptrst,
+  UD_Ivmresume,
+  UD_Ivmxoff,
+  UD_Ivmrun,
+  UD_Ivmmcall,
+  UD_Ivmload,
+  UD_Ivmsave,
+  UD_Iwait,
+  UD_Iwbinvd,
+  UD_Iwrmsr,
+  UD_Ixadd,
+  UD_Ixchg,
+  UD_Ixlatb,
+  UD_Ixor,
+  UD_Ixorpd,
+  UD_Ixorps,
+  UD_Idb,
+  UD_Iinvalid,
+  UD_Id3vil,
+  UD_Ina,
+  UD_Igrp_reg,
+  UD_Igrp_rm,
+  UD_Igrp_vendor,
+  UD_Igrp_x87,
+  UD_Igrp_mode,
+  UD_Igrp_osize,
+  UD_Igrp_asize,
+  UD_Igrp_mod,
+  UD_Inone,
+};
+
+
+
+extern const char* ud_mnemonics_str[];;
+extern struct ud_itab_entry* ud_itab_list[];
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/kdb_dis.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include <xen/compile.h>                /* for XEN_SUBVERSION */
+#include "../../include/kdbinc.h"
+#include "extern.h"
+
+static void (*dis_syntax)(ud_t*) = UD_SYN_ATT; /* default dis-assembly syntax */
+
+static struct {                         /* info for kdb_read_byte_for_ud() */
+    kdbva_t kud_instr_addr;
+    domid_t kud_domid;
+} kdb_ud_rd_info;
+
+/* called via function ptr by ud when disassembling. 
+ * kdb info passed via kdb_ud_rd_info{} 
+ */
+static int
+kdb_read_byte_for_ud(struct ud *udp)
+{
+    kdbbyt_t bytebuf;
+    domid_t domid = kdb_ud_rd_info.kud_domid;
+    kdbva_t addr = kdb_ud_rd_info.kud_instr_addr;
+
+    if (kdb_read_mem(addr, &bytebuf, 1, domid) == 1) {
+        kdb_ud_rd_info.kud_instr_addr++;
+        KDBGP1("udrd:addr:%lx domid:%d byt:%x\n", addr, domid, bytebuf);
+        return bytebuf;
+    }
+    KDBGP1("udrd:addr:%lx domid:%d err\n", addr, domid);
+    return UD_EOI;
+}
+
+/* 
+ * given a domid, convert addr to symbol and print it 
+ * Eg: ffff828c801235e2: idle_loop+52                  jmp  idle_loop+55
+ *    Called twice here for idle_loop. In first case, nl is null, 
+ *    in the second case nl == '\n'
+ */
+void
+kdb_prnt_addr2sym(domid_t domid, kdbva_t addr, char *nl)
+{
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1], pbuf[150], prefix[8];
+    char *p = buf;
+
+    prefix[0]='\0';
+    if (domid != DOMID_IDLE) {
+        snprintf(prefix, 8, "%x:", domid);
+        p = kdb_guest_addr2sym(addr, domid, &offs);
+    } else
+        symbols_lookup(addr, &sz, &offs, buf);
+
+    snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
+    if (*nl != '\n')
+        kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
+    else
+        kdbp("%s%s", pbuf, nl);
+
+}
+
+static int
+kdb_jump_instr(enum ud_mnemonic_code mnemonic)
+{
+    return (mnemonic >= UD_Ijo && mnemonic <= UD_Ijmp);
+}
+
+/*
+ * print one instr: function so that we can print offsets of jmp etc.. as
+ *  symbol+offset instead of just address
+ */
+static void
+kdb_print_one_instr(struct ud *udp, domid_t domid)
+{
+    signed long val = 0;
+    ud_type_t type = udp->operand[0].type;
+
+    if ((udp->mnemonic == UD_Icall || kdb_jump_instr(udp->mnemonic)) &&
+        type == UD_OP_JIMM) {
+        
+        int sz = udp->operand[0].size;
+        char *p, ibuf[40], *q = ibuf;
+        kdbva_t addr;
+
+        if (sz == 8) val = udp->operand[0].lval.sbyte;
+        else if (sz == 16) val = udp->operand[0].lval.sword;
+        else if (sz == 32) val = udp->operand[0].lval.sdword;
+        else if (sz == 64) val = udp->operand[0].lval.sqword;
+        else kdbp("kdb_print_one_instr: Inval sz:z%d\n", sz);
+
+        addr = udp->pc + val;
+        for(p=ud_insn_asm(udp); (*q=*p) && *p!=' '; p++,q++);
+        *q='\0';
+        kdbp(" %-4s ", ibuf);    /* space before for long func names */
+        kdb_prnt_addr2sym(domid, addr, "\n");
+    } else
+        kdbp(" %-24s\n", ud_insn_asm(udp));
+#if 0
+    kdbp("mnemonic:z%d ", udp->mnemonic);
+    if (type == UD_OP_CONST) kdbp("type is const\n");
+    else if (type == UD_OP_JIMM) kdbp("type is JIMM\n");
+    else if (type == UD_OP_IMM) kdbp("type is IMM\n");
+    else if (type == UD_OP_PTR) kdbp("type is PTR\n");
+#endif
+}
+
+static void
+kdb_setup_ud(struct ud *udp, kdbva_t addr, domid_t domid)
+{
+    int bitness = kdb_guest_bitness(domid);
+    uint vendor = (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ?
+                                           UD_VENDOR_AMD : UD_VENDOR_INTEL;
+
+    KDBGP1("setup_ud:domid:%d bitness:%d addr:%lx\n", domid, bitness, addr);
+    ud_init(udp);
+    ud_set_mode(udp, kdb_guest_bitness(domid));
+    ud_set_syntax(udp, dis_syntax); 
+    ud_set_vendor(udp, vendor);           /* HVM: vmx/svm different instrs*/
+    ud_set_pc(udp, addr);                 /* for numbers printed on left */
+    ud_set_input_hook(udp, kdb_read_byte_for_ud);
+    kdb_ud_rd_info.kud_instr_addr = addr;
+    kdb_ud_rd_info.kud_domid = domid;
+}
+
+/*
+ * given an addr, print given number of instructions.
+ * Returns: address of next instruction in the stream
+ */
+kdbva_t
+kdb_print_instr(kdbva_t addr, long num, domid_t domid)
+{
+    struct ud ud_s;
+
+    KDBGP1("print_instr:addr:0x%lx num:%ld domid:%x\n", addr, num, domid);
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    while(num--) {
+        if (ud_disassemble(&ud_s)) {
+            uint64_t pc = ud_insn_off(&ud_s);
+            /* kdbp("%08x: ",(int)pc); */
+            kdbp("%016lx: ", pc);
+            kdb_prnt_addr2sym(domid, pc, "");
+            kdb_print_one_instr(&ud_s, domid);
+        } else
+            kdbp("KDB:Couldn't disassemble PC:0x%lx\n", addr);
+            /* for stack reads, don't always display error */
+    }
+    KDBGP1("print_instr:kudaddr:0x%lx\n", kdb_ud_rd_info.kud_instr_addr);
+    return kdb_ud_rd_info.kud_instr_addr;
+}
+
+void
+kdb_display_pc(struct cpu_user_regs *regs)
+{   
+    domid_t domid;
+    struct cpu_user_regs regs1 = *regs;
+    domid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+
+    regs1.KDBIP = regs->KDBIP;
+    kdb_print_instr(regs1.KDBIP, 1, domid);
+}
+
+/* check if the instr at the addr is call instruction
+ * RETURNS: size of the instr if it's a call instr, else 0
+ */
+int
+kdb_check_call_instr(domid_t domid, kdbva_t addr)
+{
+    struct ud ud_s;
+    int sz;
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    if ((sz=ud_disassemble(&ud_s)) && ud_s.mnemonic == UD_Icall)
+        return (sz);
+    return 0;
+}
+
+/* toggle ATT and Intel syntaxes */
+void
+kdb_toggle_dis_syntax(void)
+{
+    if (dis_syntax == UD_SYN_INTEL) {
+        dis_syntax = UD_SYN_ATT;
+        kdbp("dis syntax now set to ATT (Gas)\n");
+    } else {
+        dis_syntax = UD_SYN_INTEL;
+        kdbp("dis syntax now set to Intel (NASM)\n");
+    }
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn-att.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-att.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,211 @@
+/* -----------------------------------------------------------------------------
+ * syn-att.c
+ *
+ * Copyright (c) 2004, 2005, 2006 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case 16 : case 32 :
+		mkasm(u, "*");   break;
+	default: break;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+gen_operand(struct ud* u, struct ud_operand* op)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, "%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM:
+		if (u->br_far) opr_cast(u, op);
+		if (u->pfx_seg)
+			mkasm(u, "%%%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", (-op->lval.sbyte) & 0xff);
+			else	mkasm(u, "0x%x", op->lval.sbyte);
+		} 
+		else if (op->offset == 16) 
+			mkasm(u, "0x%x", op->lval.uword);
+		else if (op->offset == 32) 
+			mkasm(u, "0x%lx", op->lval.udword);
+		else if (op->offset == 64) 
+			mkasm(u, "0x" FMT64 "x", op->lval.uqword);
+
+		if (op->base)
+			mkasm(u, "(%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		if (op->index) {
+			if (op->base)
+				mkasm(u, ",");
+			else mkasm(u, "(");
+			mkasm(u, "%%%s", ud_reg_tab[op->index - UD_R_AL]);
+		}
+		if (op->scale)
+			mkasm(u, ",%d", op->scale);
+		if (op->base || op->index)
+			mkasm(u, ")");
+		break;
+
+	case UD_OP_IMM:
+		switch (op->size) {
+			case  8: mkasm(u, "$0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "$0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "$0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "$0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "$0x%x, $0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "$0x%x, $0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+			
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to AT&T syntax 
+ * =============================================================================
+ */
+extern void 
+ud_translate_att(struct ud *u)
+{
+  int size = 0;
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+  	mkasm(u,  "lock ");
+  if (u->pfx_rep)
+	mkasm(u,  "rep ");
+  if (u->pfx_repne)
+		mkasm(u,  "repne ");
+
+  /* special instructions */
+  switch (u->mnemonic) {
+	case UD_Iretf: 
+		mkasm(u, "lret "); 
+		break;
+	case UD_Idb:
+		mkasm(u, ".byte 0x%x", u->operand[0].lval.ubyte);
+		return;
+	case UD_Ijmp:
+	case UD_Icall:
+		if (u->br_far) mkasm(u,  "l");
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+		break;
+	case UD_Ibound:
+	case UD_Ienter:
+		if (u->operand[0].type != UD_NONE)
+			gen_operand(u, &u->operand[0]);
+		if (u->operand[1].type != UD_NONE) {
+			mkasm(u, ",");
+			gen_operand(u, &u->operand[1]);
+		}
+		return;
+	default:
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+  }
+
+  if (u->c1)
+	size = u->operand[0].size;
+  else if (u->c2)
+	size = u->operand[1].size;
+  else if (u->c3)
+	size = u->operand[2].size;
+
+  if (size == 8)
+	mkasm(u, "b");
+  else if (size == 16)
+	mkasm(u, "w");
+  else if (size == 64)
+ 	mkasm(u, "q");
+
+  mkasm(u, " ");
+
+  if (u->operand[2].type != UD_NONE) {
+	gen_operand(u, &u->operand[2]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[1].type != UD_NONE) {
+	gen_operand(u, &u->operand[1]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[0].type != UD_NONE)
+	gen_operand(u, &u->operand[0]);
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn-intel.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-intel.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,208 @@
+/* -----------------------------------------------------------------------------
+ * syn-intel.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case  8: mkasm(u, "byte " ); break;
+	case 16: mkasm(u, "word " ); break;
+	case 32: mkasm(u, "dword "); break;
+	case 64: mkasm(u, "qword "); break;
+	case 80: mkasm(u, "tword "); break;
+	default: break;
+  }
+  if (u->br_far)
+	mkasm(u, "far "); 
+  else if (u->br_near)
+	mkasm(u, "near ");
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void gen_operand(struct ud* u, struct ud_operand* op, int syn_cast)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM: {
+
+		int op_f = 0;
+
+		if (syn_cast) 
+			opr_cast(u, op);
+
+		mkasm(u, "[");
+
+		if (u->pfx_seg)
+			mkasm(u, "%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+		if (op->base) {
+			mkasm(u, "%s", ud_reg_tab[op->base - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->index) {
+			if (op_f)
+				mkasm(u, "+");
+			mkasm(u, "%s", ud_reg_tab[op->index - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->scale)
+			mkasm(u, "*%d", op->scale);
+
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", -op->lval.sbyte);
+			else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sbyte);
+		}
+		else if (op->offset == 16)
+			mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.uword);
+		else if (op->offset == 32) {
+			if (u->adr_mode == 64) {
+				if (op->lval.sdword < 0)
+					mkasm(u, "-0x%x", -op->lval.sdword);
+				else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sdword);
+			} 
+			else	mkasm(u, "%s0x%lx", (op_f) ? "+" : "", op->lval.udword);
+		}
+		else if (op->offset == 64) 
+			mkasm(u, "%s0x" FMT64 "x", (op_f) ? "+" : "", op->lval.uqword);
+
+		mkasm(u, "]");
+		break;
+	}
+			
+	case UD_OP_IMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8: mkasm(u, "0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "word 0x%x:0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "dword 0x%x:0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+
+	case UD_OP_CONST:
+		if (syn_cast) opr_cast(u, op);
+		mkasm(u, "%d", op->lval.udword);
+		break;
+
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to intel syntax 
+ * =============================================================================
+ */
+extern void ud_translate_intel(struct ud* u)
+{
+  /* -- prefixes -- */
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+	mkasm(u, "lock ");
+  if (u->pfx_rep)
+	mkasm(u, "rep ");
+  if (u->pfx_repne)
+	mkasm(u, "repne ");
+  if (u->implicit_addr && u->pfx_seg)
+	mkasm(u, "%s ", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+  /* print the instruction mnemonic */
+  mkasm(u, "%s ", ud_lookup_mnemonic(u->mnemonic));
+
+  /* operand 1 */
+  if (u->operand[0].type != UD_NONE) {
+	gen_operand(u, &u->operand[0], u->c1);
+  }
+  /* operand 2 */
+  if (u->operand[1].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[1], u->c2);
+  }
+
+  /* operand 3 */
+  if (u->operand[2].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[2], u->c3);
+  }
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,61 @@
+/* -----------------------------------------------------------------------------
+ * syn.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+/* -----------------------------------------------------------------------------
+ * Intel Register Table - Order Matters (types.h)!
+ * -----------------------------------------------------------------------------
+ */
+const char* ud_reg_tab[] = 
+{
+  "al",		"cl",		"dl",		"bl",
+  "ah",		"ch",		"dh",		"bh",
+  "spl",	"bpl",		"sil",		"dil",
+  "r8b",	"r9b",		"r10b",		"r11b",
+  "r12b",	"r13b",		"r14b",		"r15b",
+
+  "ax",		"cx",		"dx",		"bx",
+  "sp",		"bp",		"si",		"di",
+  "r8w",	"r9w",		"r10w",		"r11w",
+  "r12w",	"r13W"	,	"r14w",		"r15w",
+	
+  "eax",	"ecx",		"edx",		"ebx",
+  "esp",	"ebp",		"esi",		"edi",
+  "r8d",	"r9d",		"r10d",		"r11d",
+  "r12d",	"r13d",		"r14d",		"r15d",
+	
+  "rax",	"rcx",		"rdx",		"rbx",
+  "rsp",	"rbp",		"rsi",		"rdi",
+  "r8",		"r9",		"r10",		"r11",
+  "r12",	"r13",		"r14",		"r15",
+
+  "es",		"cs",		"ss",		"ds",
+  "fs",		"gs",	
+
+  "cr0",	"cr1",		"cr2",		"cr3",
+  "cr4",	"cr5",		"cr6",		"cr7",
+  "cr8",	"cr9",		"cr10",		"cr11",
+  "cr12",	"cr13",		"cr14",		"cr15",
+	
+  "dr0",	"dr1",		"dr2",		"dr3",
+  "dr4",	"dr5",		"dr6",		"dr7",
+  "dr8",	"dr9",		"dr10",		"dr11",
+  "dr12",	"dr13",		"dr14",		"dr15",
+
+  "mm0",	"mm1",		"mm2",		"mm3",
+  "mm4",	"mm5",		"mm6",		"mm7",
+
+  "st0",	"st1",		"st2",		"st3",
+  "st4",	"st5",		"st6",		"st7", 
+
+  "xmm0",	"xmm1",		"xmm2",		"xmm3",
+  "xmm4",	"xmm5",		"xmm6",		"xmm7",
+  "xmm8",	"xmm9",		"xmm10",	"xmm11",
+  "xmm12",	"xmm13",	"xmm14",	"xmm15",
+
+  "rip"
+};
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,27 @@
+/* -----------------------------------------------------------------------------
+ * syn.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_SYN_H
+#define UD_SYN_H
+
+#if 0
+#include <stdio.h>
+#include <stdarg.h>
+#endif
+#include "types.h"
+
+extern const char* ud_reg_tab[];
+
+static void mkasm(struct ud* u, const char* fmt, ...)
+{
+  va_list ap;
+  va_start(ap, fmt);
+  u->insn_fill += vsnprintf((char*) u->insn_buffer + u->insn_fill, 64, fmt, ap);
+  va_end(ap);
+}
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/types.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/types.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,186 @@
+/* -----------------------------------------------------------------------------
+ * types.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_TYPES_H
+#define UD_TYPES_H
+
+
+#include "../../include/kdbinc.h"
+
+#define FMT64 "%ll"
+#include "itab.h"
+
+/* -----------------------------------------------------------------------------
+ * All possible "types" of objects in udis86. Order is Important!
+ * -----------------------------------------------------------------------------
+ */
+enum ud_type
+{
+  UD_NONE,
+
+  /* 8 bit GPRs */
+  UD_R_AL,	UD_R_CL,	UD_R_DL,	UD_R_BL,
+  UD_R_AH,	UD_R_CH,	UD_R_DH,	UD_R_BH,
+  UD_R_SPL,	UD_R_BPL,	UD_R_SIL,	UD_R_DIL,
+  UD_R_R8B,	UD_R_R9B,	UD_R_R10B,	UD_R_R11B,
+  UD_R_R12B,	UD_R_R13B,	UD_R_R14B,	UD_R_R15B,
+
+  /* 16 bit GPRs */
+  UD_R_AX,	UD_R_CX,	UD_R_DX,	UD_R_BX,
+  UD_R_SP,	UD_R_BP,	UD_R_SI,	UD_R_DI,
+  UD_R_R8W,	UD_R_R9W,	UD_R_R10W,	UD_R_R11W,
+  UD_R_R12W,	UD_R_R13W,	UD_R_R14W,	UD_R_R15W,
+	
+  /* 32 bit GPRs */
+  UD_R_EAX,	UD_R_ECX,	UD_R_EDX,	UD_R_EBX,
+  UD_R_ESP,	UD_R_EBP,	UD_R_ESI,	UD_R_EDI,
+  UD_R_R8D,	UD_R_R9D,	UD_R_R10D,	UD_R_R11D,
+  UD_R_R12D,	UD_R_R13D,	UD_R_R14D,	UD_R_R15D,
+	
+  /* 64 bit GPRs */
+  UD_R_RAX,	UD_R_RCX,	UD_R_RDX,	UD_R_RBX,
+  UD_R_RSP,	UD_R_RBP,	UD_R_RSI,	UD_R_RDI,
+  UD_R_R8,	UD_R_R9,	UD_R_R10,	UD_R_R11,
+  UD_R_R12,	UD_R_R13,	UD_R_R14,	UD_R_R15,
+
+  /* segment registers */
+  UD_R_ES,	UD_R_CS,	UD_R_SS,	UD_R_DS,
+  UD_R_FS,	UD_R_GS,	
+
+  /* control registers*/
+  UD_R_CR0,	UD_R_CR1,	UD_R_CR2,	UD_R_CR3,
+  UD_R_CR4,	UD_R_CR5,	UD_R_CR6,	UD_R_CR7,
+  UD_R_CR8,	UD_R_CR9,	UD_R_CR10,	UD_R_CR11,
+  UD_R_CR12,	UD_R_CR13,	UD_R_CR14,	UD_R_CR15,
+	
+  /* debug registers */
+  UD_R_DR0,	UD_R_DR1,	UD_R_DR2,	UD_R_DR3,
+  UD_R_DR4,	UD_R_DR5,	UD_R_DR6,	UD_R_DR7,
+  UD_R_DR8,	UD_R_DR9,	UD_R_DR10,	UD_R_DR11,
+  UD_R_DR12,	UD_R_DR13,	UD_R_DR14,	UD_R_DR15,
+
+  /* mmx registers */
+  UD_R_MM0,	UD_R_MM1,	UD_R_MM2,	UD_R_MM3,
+  UD_R_MM4,	UD_R_MM5,	UD_R_MM6,	UD_R_MM7,
+
+  /* x87 registers */
+  UD_R_ST0,	UD_R_ST1,	UD_R_ST2,	UD_R_ST3,
+  UD_R_ST4,	UD_R_ST5,	UD_R_ST6,	UD_R_ST7, 
+
+  /* extended multimedia registers */
+  UD_R_XMM0,	UD_R_XMM1,	UD_R_XMM2,	UD_R_XMM3,
+  UD_R_XMM4,	UD_R_XMM5,	UD_R_XMM6,	UD_R_XMM7,
+  UD_R_XMM8,	UD_R_XMM9,	UD_R_XMM10,	UD_R_XMM11,
+  UD_R_XMM12,	UD_R_XMM13,	UD_R_XMM14,	UD_R_XMM15,
+
+  UD_R_RIP,
+
+  /* Operand Types */
+  UD_OP_REG,	UD_OP_MEM,	UD_OP_PTR,	UD_OP_IMM,	
+  UD_OP_JIMM,	UD_OP_CONST
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud_operand - Disassembled instruction Operand.
+ * -----------------------------------------------------------------------------
+ */
+struct ud_operand 
+{
+  enum ud_type		type;
+  uint8_t		size;
+  union {
+	int8_t		sbyte;
+	uint8_t		ubyte;
+	int16_t		sword;
+	uint16_t	uword;
+	int32_t		sdword;
+	uint32_t	udword;
+	int64_t		sqword;
+	uint64_t	uqword;
+
+	struct {
+		uint16_t seg;
+		uint32_t off;
+	} ptr;
+  } lval;
+
+  enum ud_type		base;
+  enum ud_type		index;
+  uint8_t		offset;
+  uint8_t		scale;	
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud - The udis86 object.
+ * -----------------------------------------------------------------------------
+ */
+struct ud
+{
+  int 			(*inp_hook) (struct ud*);
+  uint8_t		inp_curr;
+  uint8_t		inp_fill;
+  uint8_t		inp_ctr;
+  uint8_t*		inp_buff;
+  uint8_t*		inp_buff_end;
+  uint8_t		inp_end;
+  void			(*translator)(struct ud*);
+  uint64_t		insn_offset;
+  char			insn_hexcode[32];
+  char			insn_buffer[64];
+  unsigned int		insn_fill;
+  uint8_t		dis_mode;
+  uint64_t		pc;
+  uint8_t		vendor;
+  struct map_entry*	mapen;
+  enum ud_mnemonic_code	mnemonic;
+  struct ud_operand	operand[3];
+  uint8_t		error;
+  uint8_t	 	pfx_rex;
+  uint8_t 		pfx_seg;
+  uint8_t 		pfx_opr;
+  uint8_t 		pfx_adr;
+  uint8_t 		pfx_lock;
+  uint8_t 		pfx_rep;
+  uint8_t 		pfx_repe;
+  uint8_t 		pfx_repne;
+  uint8_t 		pfx_insn;
+  uint8_t		default64;
+  uint8_t		opr_mode;
+  uint8_t		adr_mode;
+  uint8_t		br_far;
+  uint8_t		br_near;
+  uint8_t		implicit_addr;
+  uint8_t		c1;
+  uint8_t		c2;
+  uint8_t		c3;
+  uint8_t 		inp_cache[256];
+  uint8_t		inp_sess[64];
+  struct ud_itab_entry * itab_entry;
+};
+
+/* -----------------------------------------------------------------------------
+ * Type-definitions
+ * -----------------------------------------------------------------------------
+ */
+typedef enum ud_type 		ud_type_t;
+typedef enum ud_mnemonic_code	ud_mnemonic_code_t;
+
+typedef struct ud 		ud_t;
+typedef struct ud_operand 	ud_operand_t;
+
+#define UD_SYN_INTEL		ud_translate_intel
+#define UD_SYN_ATT		ud_translate_att
+#define UD_EOI			-1
+#define UD_INP_CACHE_SZ		32
+#define UD_VENDOR_AMD		0
+#define UD_VENDOR_INTEL		1
+
+#define bail_out(ud,error_code) longjmp( (ud)->bailout, error_code )
+#define try_decode(ud) if ( setjmp( (ud)->bailout ) == 0 )
+#define catch_error() else
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/udis86.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/udis86.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,156 @@
+/* -----------------------------------------------------------------------------
+ * udis86.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#endif
+
+#include "input.h"
+#include "extern.h"
+
+/* =============================================================================
+ * ud_init() - Initializes ud_t object.
+ * =============================================================================
+ */
+extern void 
+ud_init(struct ud* u)
+{
+  memset((void*)u, 0, sizeof(struct ud));
+  ud_set_mode(u, 16);
+  u->mnemonic = UD_Iinvalid;
+  ud_set_pc(u, 0);
+#ifndef __UD_STANDALONE__
+  ud_set_input_file(u, stdin);
+#endif /* __UD_STANDALONE__ */
+}
+
+/* =============================================================================
+ * ud_disassemble() - disassembles one instruction and returns the number of 
+ * bytes disassembled. A zero means end of disassembly.
+ * =============================================================================
+ */
+extern unsigned int
+ud_disassemble(struct ud* u)
+{
+  if (ud_input_end(u))
+	return 0;
+
+ 
+  u->insn_buffer[0] = u->insn_hexcode[0] = 0;
+
+ 
+  if (ud_decode(u) == 0)
+	return 0;
+  if (u->translator)
+	u->translator(u);
+  return ud_insn_len(u);
+}
+
+/* =============================================================================
+ * ud_set_mode() - Set Disassemly Mode.
+ * =============================================================================
+ */
+extern void 
+ud_set_mode(struct ud* u, uint8_t m)
+{
+  switch(m) {
+	case 16:
+	case 32:
+	case 64: u->dis_mode = m ; return;
+	default: u->dis_mode = 16; return;
+  }
+}
+
+/* =============================================================================
+ * ud_set_vendor() - Set vendor.
+ * =============================================================================
+ */
+extern void 
+ud_set_vendor(struct ud* u, unsigned v)
+{
+  switch(v) {
+	case UD_VENDOR_INTEL:
+		u->vendor = v;
+		break;
+	default:
+		u->vendor = UD_VENDOR_AMD;
+  }
+}
+
+/* =============================================================================
+ * ud_set_pc() - Sets code origin. 
+ * =============================================================================
+ */
+extern void 
+ud_set_pc(struct ud* u, uint64_t o)
+{
+  u->pc = o;
+}
+
+/* =============================================================================
+ * ud_set_syntax() - Sets the output syntax.
+ * =============================================================================
+ */
+extern void 
+ud_set_syntax(struct ud* u, void (*t)(struct ud*))
+{
+  u->translator = t;
+}
+
+/* =============================================================================
+ * ud_insn() - returns the disassembled instruction
+ * =============================================================================
+ */
+extern char* 
+ud_insn_asm(struct ud* u) 
+{
+  return u->insn_buffer;
+}
+
+/* =============================================================================
+ * ud_insn_offset() - Returns the offset.
+ * =============================================================================
+ */
+extern uint64_t
+ud_insn_off(struct ud* u) 
+{
+  return u->insn_offset;
+}
+
+
+/* =============================================================================
+ * ud_insn_hex() - Returns hex form of disassembled instruction.
+ * =============================================================================
+ */
+extern char* 
+ud_insn_hex(struct ud* u) 
+{
+  return u->insn_hexcode;
+}
+
+/* =============================================================================
+ * ud_insn_ptr() - Returns code disassembled.
+ * =============================================================================
+ */
+extern uint8_t* 
+ud_insn_ptr(struct ud* u) 
+{
+  return u->inp_sess;
+}
+
+/* =============================================================================
+ * ud_insn_len() - Returns the count of bytes disassembled.
+ * =============================================================================
+ */
+extern unsigned int 
+ud_insn_len(struct ud* u) 
+{
+  return u->inp_ctr;
+}

--MP_/c2HycnF26WhVANwYZbmqoQR
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MP_/c2HycnF26WhVANwYZbmqoQR--


From xen-devel-bounces@lists.xen.org Mon Jun 18 11:27:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 11:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sga79-0008Kb-Il; Mon, 18 Jun 2012 11:27:23 +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 1SfbzF-00009y-7i
	for xen-devel@lists.xensource.com; Fri, 15 Jun 2012 19:15:14 +0000
Received: from [85.158.143.99:10971] by server-2.bemta-4.messagelabs.com id
	57/1F-17938-0C98BDF4; Fri, 15 Jun 2012 19:15:12 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1339787708!27616580!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5MzA5OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6130 invoked from network); 15 Jun 2012 19:15:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jun 2012 19:15:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5FJF197022081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Jun 2012 19:15:02 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
	q5FJExqd002705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Jun 2012 19:15: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
	q5FJExUs028435; Fri, 15 Jun 2012 14:14:59 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Jun 2012 12:14:58 -0700
Date: Fri, 15 Jun 2012 12:14:56 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120615121456.3f0089ad@mantra.us.oracle.com>
In-Reply-To: <20120615155844.GB20422@phenom.dumpdata.com>
References: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
	<20120615155844.GB20422@phenom.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
Content-Type: multipart/mixed; boundary="MP_/c2HycnF26WhVANwYZbmqoQR"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Mon, 18 Jun 2012 11:27:21 +0000
Cc: xen-devel@lists.xensource.com, ml@consolo.de
Subject: Re: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/c2HycnF26WhVANwYZbmqoQR
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Fri, 15 Jun 2012 11:58:44 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Jun 14, 2012 at 03:11:48PM +0200, ml@consolo.de wrote:
> > 
> > Hi,
> > 
> > I am currently trying to get kdb working with the current 4.1 XEN
> > release. I first tried to use debuggers.hg, but could not manage to
> > compile it due tho many different errors.
> 
> Did you email the author (Mukesh) of debuggers.hg to see if he can
> help?
> 

I just posted a patch for unstable c/s 25467 last week. Attached here
again.

thanks,
Mukesh




--MP_/c2HycnF26WhVANwYZbmqoQR
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=kdb.patch

diff -r 32034d1914a6 xen/Makefile
--- a/xen/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -61,6 +61,7 @@ _clean: delete-unfresh-files
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+	$(MAKE) -f $(BASEDIR)/Rules.mk -C kdb clean
 	rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET)-syms *~ core
 	rm -f include/asm-*/asm-offsets.h
 	[ -d tools/figlet ] && rm -f .banner*
@@ -129,7 +130,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h
 	  echo ""; \
 	  echo "#endif") <$< >$@
 
-SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers
+SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers kdb
 define all_sources
     ( find include/asm-$(TARGET_ARCH) -name '*.h' -print; \
       find include -name 'asm-*' -prune -o -name '*.h' -print; \
diff -r 32034d1914a6 xen/Rules.mk
--- a/xen/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/Rules.mk	Fri Jun 15 12:13:29 2012 -0700
@@ -10,6 +10,7 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto           ?= n
+kdb           ?= n
 
 include $(XEN_ROOT)/Config.mk
 
@@ -40,6 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/d
 ALL_OBJS-y               += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(kdb)          += $(BASEDIR)/kdb/built_in.o
 
 CFLAGS-y                += -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
@@ -53,6 +55,7 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFIL
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(kdb)           += -DXEN_KDB_CONFIG
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y                += -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff -r 32034d1914a6 xen/arch/x86/hvm/svm/entry.S
--- a/xen/arch/x86/hvm/svm/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -59,12 +59,23 @@ ENTRY(svm_asm_do_resume)
         get_current(bx)
         CLGI
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         testl $~0,(r(dx),r(ax),1)
         jnz  .Lsvm_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0, VCPU_nsvm_hap_enabled(r(bx))
 UNLIKELY_START(nz, nsvm_hap)
         mov  VCPU_nhvm_p2m(r(bx)),r(ax)
diff -r 32034d1914a6 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2170,6 +2170,10 @@ void svm_vmexit_handler(struct cpu_user_
         break;
 
     case VMEXIT_EXCEPTION_DB:
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+	    break;
+#endif
         if ( !v->domain->debugger_attached )
             goto exit_and_crash;
         domain_pause_for_debugger();
@@ -2182,6 +2186,10 @@ void svm_vmexit_handler(struct cpu_user_
         if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
             break;
         __update_guest_eip(regs, inst_len);
+#ifdef XEN_KDB_CONFIG
+        if (kdb_handle_trap_entry(TRAP_int3, regs))
+            break;
+#endif
         current->arch.gdbsx_vcpu_event = TRAP_int3;
         domain_pause_for_debugger();
         break;
diff -r 32034d1914a6 xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Fri Jun 15 12:13:29 2012 -0700
@@ -315,6 +315,36 @@ void setup_vmcb_dump(void)
     register_keyhandler('v', &vmcb_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+/* did == 0 : display for all HVM domains. domid 0 is never HVM.
+ *  * vid == -1 : display for all HVM VCPUs
+ *   */
+void kdb_dump_vmcb(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain (dp) {
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+            kdbp("  VMCB [domid: %d  vcpu:%d]:\n", dp->domain_id, vp->vcpu_id);
+            svm_vmcb_dump("kdb", vp->arch.hvm_svm.vmcb);
+            kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    rcu_read_unlock(&domlist_read_lock);
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 xen/arch/x86/hvm/vmx/entry.S
--- a/xen/arch/x86/hvm/vmx/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -124,12 +124,23 @@ vmx_asm_do_vmentry:
         get_current(bx)
         cli
 
+#ifdef XEN_KDB_CONFIG
+#if defined(__x86_64__)
+        testl $1, kdb_session_begun(%rip)
+#else
+        testl $1, kdb_session_begun
+#endif
+        jnz  .Lkdb_skip_softirq
+#endif
         mov  VCPU_processor(r(bx)),%eax
         shl  $IRQSTAT_shift,r(ax)
         lea  addr_of(irq_stat),r(dx)
         cmpl $0,(r(dx),r(ax),1)
         jnz  .Lvmx_process_softirqs
 
+#ifdef XEN_KDB_CONFIG
+.Lkdb_skip_softirq:
+#endif
         testb $0xff,VCPU_vmx_emulate(r(bx))
         jnz .Lvmx_goto_emulator
         testb $0xff,VCPU_vmx_realmode(r(bx))
diff -r 32034d1914a6 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Fri Jun 15 12:13:29 2012 -0700
@@ -1117,6 +1117,13 @@ void vmx_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
+#if defined(XEN_KDB_CONFIG)
+    if (kdb_dr7)
+        __vmwrite(GUEST_DR7, kdb_dr7);
+    else
+        __vmwrite(GUEST_DR7, 0);
+#endif
+
     debug_state = v->domain->debugger_attached
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_INT3]
                   || v->domain->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP];
@@ -1326,6 +1333,220 @@ void setup_vmcs_dump(void)
     register_keyhandler('v', &vmcs_dump_keyhandler);
 }
 
+#if defined(XEN_KDB_CONFIG)
+#define GUEST_EFER      0x2806   /* see page 23-20 */
+#define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+
+/* it's a shame we can't use vmcs_dump_vcpu(), but it does vmx_vmcs_enter which
+ * will IPI other CPUs. also, print a subset relevant to software debugging */
+static void noinline kdb_print_vmcs(struct vcpu *vp)
+{
+    struct cpu_user_regs *regs = &vp->arch.user_regs;
+    unsigned long long x;
+
+    kdbp("*** Guest State ***\n");
+    kdbp("CR0: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR0),
+         (unsigned long long)vmr(CR0_READ_SHADOW), 
+         (unsigned long long)vmr(CR0_GUEST_HOST_MASK));
+    kdbp("CR4: actual=0x%016llx, shadow=0x%016llx, gh_mask=%016llx\n",
+         (unsigned long long)vmr(GUEST_CR4),
+         (unsigned long long)vmr(CR4_READ_SHADOW), 
+         (unsigned long long)vmr(CR4_GUEST_HOST_MASK));
+    kdbp("CR3: actual=0x%016llx, target_count=%d\n",
+         (unsigned long long)vmr(GUEST_CR3),
+         (int)vmr(CR3_TARGET_COUNT));
+    kdbp("     target0=%016llx, target1=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE0),
+         (unsigned long long)vmr(CR3_TARGET_VALUE1));
+    kdbp("     target2=%016llx, target3=%016llx\n",
+         (unsigned long long)vmr(CR3_TARGET_VALUE2),
+         (unsigned long long)vmr(CR3_TARGET_VALUE3));
+    kdbp("RSP = 0x%016llx (0x%016llx)  RIP = 0x%016llx (0x%016llx)\n", 
+         (unsigned long long)vmr(GUEST_RSP),
+         (unsigned long long)regs->esp,
+         (unsigned long long)vmr(GUEST_RIP),
+         (unsigned long long)regs->eip);
+    kdbp("RFLAGS=0x%016llx (0x%016llx)  DR7 = 0x%016llx\n", 
+         (unsigned long long)vmr(GUEST_RFLAGS),
+         (unsigned long long)regs->eflags,
+         (unsigned long long)vmr(GUEST_DR7));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+         (unsigned long long)vmr(GUEST_SYSENTER_ESP),
+         (int)vmr(GUEST_SYSENTER_CS),
+         (unsigned long long)vmr(GUEST_SYSENTER_EIP));
+    vmx_dump_sel("CS", GUEST_CS_SELECTOR);
+    vmx_dump_sel("DS", GUEST_DS_SELECTOR);
+    vmx_dump_sel("SS", GUEST_SS_SELECTOR);
+    vmx_dump_sel("ES", GUEST_ES_SELECTOR);
+    vmx_dump_sel("FS", GUEST_FS_SELECTOR);
+    vmx_dump_sel("GS", GUEST_GS_SELECTOR);
+    vmx_dump_sel2("GDTR", GUEST_GDTR_LIMIT);
+    vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
+    vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
+    vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
+    kdbp("Guest PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
+    x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
+    x |= (uint32_t)vmr(TSC_OFFSET);
+    kdbp("TSC Offset = %016llx\n", x);
+    x  = (unsigned long long)vmr(GUEST_IA32_DEBUGCTL_HIGH) << 32;
+    x |= (uint32_t)vmr(GUEST_IA32_DEBUGCTL);
+    kdbp("DebugCtl=%016llx DebugExceptions=%016llx\n", x,
+           (unsigned long long)vmr(GUEST_PENDING_DBG_EXCEPTIONS));
+    kdbp("Interruptibility=%04x ActivityState=%04x\n",
+           (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
+           (int)vmr(GUEST_ACTIVITY_STATE));
+
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
+    kdbp("\n*** Host State ***\n");
+    kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
+           (unsigned long long)vmr(HOST_RSP),
+           (unsigned long long)vmr(HOST_RIP));
+    kdbp("CS=%04x DS=%04x ES=%04x FS=%04x GS=%04x SS=%04x TR=%04x\n",
+           (uint16_t)vmr(HOST_CS_SELECTOR),
+           (uint16_t)vmr(HOST_DS_SELECTOR),
+           (uint16_t)vmr(HOST_ES_SELECTOR),
+           (uint16_t)vmr(HOST_FS_SELECTOR),
+           (uint16_t)vmr(HOST_GS_SELECTOR),
+           (uint16_t)vmr(HOST_SS_SELECTOR),
+           (uint16_t)vmr(HOST_TR_SELECTOR));
+    kdbp("FSBase=%016llx GSBase=%016llx TRBase=%016llx\n",
+           (unsigned long long)vmr(HOST_FS_BASE),
+           (unsigned long long)vmr(HOST_GS_BASE),
+           (unsigned long long)vmr(HOST_TR_BASE));
+    kdbp("GDTBase=%016llx IDTBase=%016llx\n",
+           (unsigned long long)vmr(HOST_GDTR_BASE),
+           (unsigned long long)vmr(HOST_IDTR_BASE));
+    kdbp("CR0=%016llx CR3=%016llx CR4=%016llx\n",
+           (unsigned long long)vmr(HOST_CR0),
+           (unsigned long long)vmr(HOST_CR3),
+           (unsigned long long)vmr(HOST_CR4));
+    kdbp("Sysenter RSP=%016llx CS:RIP=%04x:%016llx\n",
+           (unsigned long long)vmr(HOST_SYSENTER_ESP),
+           (int)vmr(HOST_SYSENTER_CS),
+           (unsigned long long)vmr(HOST_SYSENTER_EIP));
+    kdbp("Host PAT = 0x%08x%08x\n",
+           (uint32_t)vmr(HOST_PAT_HIGH), (uint32_t)vmr(HOST_PAT));
+
+    kdbp("\n*** Control State ***\n");
+    kdbp("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n",
+           (uint32_t)vmr(PIN_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(CPU_BASED_VM_EXEC_CONTROL),
+           (uint32_t)vmr(SECONDARY_VM_EXEC_CONTROL));
+    kdbp("EntryControls=%08x ExitControls=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_CONTROLS),
+           (uint32_t)vmr(VM_EXIT_CONTROLS));
+    kdbp("ExceptionBitmap=%08x\n",
+           (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
+    kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_ENTRY_INTR_INFO),
+           (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("VMExit: intr_info=%08x errcode=%08x ilen=%08x\n",
+           (uint32_t)vmr(VM_EXIT_INTR_INFO),
+           (uint32_t)vmr(VM_EXIT_INTR_ERROR_CODE),
+           (uint32_t)vmr(VM_ENTRY_INSTRUCTION_LEN));
+    kdbp("        reason=%08x qualification=%08x\n",
+           (uint32_t)vmr(VM_EXIT_REASON),
+           (uint32_t)vmr(EXIT_QUALIFICATION));
+    kdbp("IDTVectoring: info=%08x errcode=%08x\n",
+           (uint32_t)vmr(IDT_VECTORING_INFO),
+           (uint32_t)vmr(IDT_VECTORING_ERROR_CODE));
+    kdbp("TPR Threshold = 0x%02x\n",
+           (uint32_t)vmr(TPR_THRESHOLD));
+    kdbp("EPT pointer = 0x%08x%08x\n",
+           (uint32_t)vmr(EPT_POINTER_HIGH), (uint32_t)vmr(EPT_POINTER));
+    kdbp("Virtual processor ID = 0x%04x\n",
+           (uint32_t)vmr(VIRTUAL_PROCESSOR_ID));
+    kdbp("=================================================================\n");
+}
+
+/* Flush VMCS on this cpu if it needs to: 
+ *   - Upon leaving kdb, the HVM cpu will resume in vmx_vmexit_handler() and 
+ *     do __vmreads. So, the VMCS pointer can't be left cleared.
+ *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
+ *     vmlaunch must be done and not vmresume. This means, we must clear 
+ *     arch_vmx->launched.
+ */
+void kdb_curr_cpu_flush_vmcs(void)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    int ccpu = smp_processor_id();
+    struct vmcs_struct *cvp = this_cpu(current_vmcs);
+
+    if (this_cpu(current_vmcs) == NULL)
+        return;             /* no HVM active on this CPU */
+
+    kdbp("KDB:[%d] curvmcs:%lx/%lx\n", ccpu, cvp, virt_to_maddr(cvp));
+
+    /* looks like we got one. unfortunately, current_vmcs points to vmcs 
+     * and not VCPU, so we gotta search the entire list... */
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        for_each_vcpu (dp, vp) {
+            if ( vp->arch.hvm_vmx.vmcs == cvp ) {
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched = 0;
+                this_cpu(current_vmcs) = NULL;
+                kdbp("KDB:[%d] %d:%d current_vmcs:%lx flushed\n", 
+		     ccpu, dp->domain_id, vp->vcpu_id, cvp, virt_to_maddr(cvp));
+            }
+        }
+    }
+}
+
+/*
+ * domid == 0 : display for all HVM domains  (dom0 is never an HVM domain)
+ * vcpu id == -1 : display all vcpuids
+ * PreCondition: all HVM cpus (including current cpu) have flushed VMCS
+ */
+void kdb_dump_vmcs(domid_t did, int vid)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+    struct vmcs_struct  *vmcsp;
+    u64 addr = -1;
+
+    ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
+    __vmptrst(&addr);
+
+    for_each_domain (dp) {
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
+            continue;
+        if (did != 0 && did != dp->domain_id)
+            continue;
+
+        for_each_vcpu (dp, vp) {
+            if (vid != -1 && vid != vp->vcpu_id)
+                continue;
+
+	    vmcsp = vp->arch.hvm_vmx.vmcs;
+            kdbp("VMCS %lx/%lx [domid:%d (%p)  vcpu:%d (%p)]:\n", vmcsp,
+	         virt_to_maddr(vmcsp), dp->domain_id, dp, vp->vcpu_id, vp);
+            __vmptrld(virt_to_maddr(vmcsp));
+            kdb_print_vmcs(vp);
+            __vmpclear(virt_to_maddr(vmcsp));
+            vp->arch.hvm_vmx.launched = 0;
+        }
+        kdbp("\n");
+    }
+    /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
+    if (addr && addr != (u64)-1)
+        __vmptrld(addr);
+}
+#endif
 
 /*
  * Local variables:
diff -r 32034d1914a6 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2183,11 +2183,14 @@ static void vmx_failed_vmentry(unsigned 
         printk("reason not known yet!");
         break;
     }
-
+#if defined(XEN_KDB_CONFIG)
+    kdbp("\n************* VMCS Area **************\n");
+    kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
-
+#endif
     domain_crash(curr->domain);
 }
 
@@ -2415,6 +2418,12 @@ void vmx_vmexit_handler(struct cpu_user_
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
+
+#if defined(XEN_KDB_CONFIG)
+            /* TRAP_debug: IP points correctly to next instr */
+            if (kdb_handle_trap_entry(vector, regs))
+                break;
+#endif
             domain_pause_for_debugger();
             break;
         case TRAP_int3: 
@@ -2423,6 +2432,13 @@ void vmx_vmexit_handler(struct cpu_user_
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
+#if defined(XEN_KDB_CONFIG)
+                /* vmcs.IP points to bp, kdb expects bp+1. Hence after the above
+                 * update_guest_eip which updates to bp+1. works for gdbsx too 
+                 */
+                if (kdb_handle_trap_entry(vector, regs))
+                    break;
+#endif
                 current->arch.gdbsx_vcpu_event = TRAP_int3;
                 domain_pause_for_debugger();
                 break;
@@ -2707,6 +2723,10 @@ void vmx_vmexit_handler(struct cpu_user_
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         vmx_update_cpu_exec_control(v);
+#if defined(XEN_KDB_CONFIG)
+        if (kdb_handle_trap_entry(TRAP_debug, regs))
+            break;
+#endif
         if ( v->arch.hvm_vcpu.single_step ) {
           hvm_memory_event_single_step(regs->eip);
           if ( v->domain->debugger_attached )
diff -r 32034d1914a6 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/irq.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2305,3 +2305,29 @@ bool_t hvm_domain_use_pirq(const struct 
     return is_hvm_domain(d) && pirq &&
            pirq->arch.hvm.emuirq != IRQ_UNBOUND; 
 }
+
+#ifdef XEN_KDB_CONFIG
+void kdb_prnt_guest_mapped_irqs(void)
+{
+    int irq, j;
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    kdbp("irq  vec  aff  type  domid:mapped-pirq pairs  (all in decimal)\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+        irq_guest_action_t *actp = (irq_guest_action_t *)dp->action;
+
+        if (!dp->handler ||dp->handler==&no_irq_type || !(dp->status&IRQ_GUEST))
+            continue;
+
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %3d %3s %-13s ", irq, archp->vector, affstr,
+             dp->handler->typename);
+        for (j=0; j < actp->nr_guests; j++)
+            kdbp("%03d:%04d ", actp->guest[j]->domain_id,
+                 domain_irq_to_pirq(actp->guest[j], irq));
+        kdbp("\n");
+    }
+}
+#endif
diff -r 32034d1914a6 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/setup.c	Fri Jun 15 12:13:29 2012 -0700
@@ -47,6 +47,13 @@
 #include <xen/cpu.h>
 #include <asm/nmi.h>
 
+#ifdef XEN_KDB_CONFIG
+#include <asm/debugger.h>
+
+int opt_earlykdb=0;
+boolean_param("earlykdb", opt_earlykdb);
+#endif
+
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
 boolean_param("nosmp", opt_nosmp);
@@ -1242,6 +1249,11 @@ void __init __start_xen(unsigned long mb
 
     trap_init();
 
+#ifdef XEN_KDB_CONFIG
+    kdb_init();
+    if (opt_earlykdb)
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+#endif
     rcu_init();
     
     early_time_init();
diff -r 32034d1914a6 xen/arch/x86/smp.c
--- a/xen/arch/x86/smp.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/smp.c	Fri Jun 15 12:13:29 2012 -0700
@@ -273,7 +273,7 @@ void smp_send_event_check_mask(const cpu
  * Structure and data for smp_call_function()/on_selected_cpus().
  */
 
-static void __smp_call_function_interrupt(void);
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs);
 static DEFINE_SPINLOCK(call_lock);
 static struct call_data_struct {
     void (*func) (void *info);
@@ -321,7 +321,7 @@ void on_selected_cpus(
     if ( cpumask_test_cpu(smp_processor_id(), &call_data.selected) )
     {
         local_irq_disable();
-        __smp_call_function_interrupt();
+        __smp_call_function_interrupt(NULL);
         local_irq_enable();
     }
 
@@ -390,7 +390,7 @@ void event_check_interrupt(struct cpu_us
     this_cpu(irq_count)++;
 }
 
-static void __smp_call_function_interrupt(void)
+static void __smp_call_function_interrupt(struct cpu_user_regs *regs)
 {
     void (*func)(void *info) = call_data.func;
     void *info = call_data.info;
@@ -411,6 +411,11 @@ static void __smp_call_function_interrup
     {
         mb();
         cpumask_clear_cpu(cpu, &call_data.selected);
+#ifdef XEN_KDB_CONFIG
+        if (info && !strcmp(info, "XENKDB")) {           /* called from kdb */
+                (*(void (*)(struct cpu_user_regs *, void *))func)(regs, info);
+        } else
+#endif
         (*func)(info);
     }
 
@@ -421,5 +426,5 @@ void call_function_interrupt(struct cpu_
 {
     ack_APIC_irq();
     perfc_incr(ipis);
-    __smp_call_function_interrupt();
+    __smp_call_function_interrupt(regs);
 }
diff -r 32034d1914a6 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/time.c	Fri Jun 15 12:13:29 2012 -0700
@@ -2007,6 +2007,46 @@ static int __init setup_dump_softtsc(voi
 }
 __initcall(setup_dump_softtsc);
 
+#ifdef XEN_KDB_CONFIG
+void kdb_time_resume(int update_domains)
+{
+        s_time_t now;
+        int ccpu = smp_processor_id();
+        struct cpu_time *t = &this_cpu(cpu_time);
+
+        if (!plt_src.read_counter)            /* not initialized for earlykdb */
+                return;
+
+        if (update_domains) {
+                plt_stamp = plt_src.read_counter();
+                platform_timer_stamp = plt_stamp64;
+                platform_time_calibration();
+                do_settime(get_cmos_time(), 0, read_platform_stime());
+        }
+        if (local_irq_is_enabled())
+                kdbp("kdb BUG: enabled in time_resume(). ccpu:%d\n", ccpu);
+
+        rdtscll(t->local_tsc_stamp);
+        now = read_platform_stime();
+        t->stime_master_stamp = now;
+        t->stime_local_stamp  = now;
+
+        update_vcpu_system_time(current);
+
+        if (update_domains)
+                set_timer(&calibration_timer, NOW() + EPOCH);
+}
+
+void kdb_dump_time_pcpu(void)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        kdbp("[%d]: cpu_time: %016lx\n", cpu, &per_cpu(cpu_time, cpu));
+        kdbp("[%d]: cpu_calibration: %016lx\n", cpu, 
+             &per_cpu(cpu_calibration, cpu));
+    }
+}
+#endif
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/traps.c	Fri Jun 15 12:13:29 2012 -0700
@@ -225,7 +225,7 @@ static void show_trace(struct cpu_user_r
 
 #else
 
-static void show_trace(struct cpu_user_regs *regs)
+void show_trace(struct cpu_user_regs *regs)
 {
     unsigned long *frame, next, addr, low, high;
 
@@ -3326,6 +3326,10 @@ void do_nmi(struct cpu_user_regs *regs)
     if ( nmi_callback(regs, cpu) )
         return;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_enabled && kdb_handle_trap_entry(TRAP_nmi, regs))
+        return;
+#endif
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
 
diff -r 32034d1914a6 xen/arch/x86/x86_64/compat/entry.S
--- a/xen/arch/x86/x86_64/compat/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/compat/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -95,6 +95,10 @@ compat_skip_clobber:
 /* %rbx: struct vcpu */
 ENTRY(compat_test_all_events)
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG
+        testl $1, kdb_session_begun(%rip)
+        jnz   compat_restore_all_guest
+#endif
 /*compat_test_softirqs:*/
         movl  VCPU_processor(%rbx),%eax
         shlq  $IRQSTAT_shift,%rax
diff -r 32034d1914a6 xen/arch/x86/x86_64/entry.S
--- a/xen/arch/x86/x86_64/entry.S	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/arch/x86/x86_64/entry.S	Fri Jun 15 12:13:29 2012 -0700
@@ -184,6 +184,10 @@ skip_clobber:
 /* %rbx: struct vcpu */
 test_all_events:
         cli                             # tests must not race interrupts
+#ifdef XEN_KDB_CONFIG                   /* 64bit dom0 will resume here */
+        testl $1, kdb_session_begun(%rip)
+        jnz   restore_all_guest
+#endif
 /*test_softirqs:*/  
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
@@ -546,6 +550,13 @@ ENTRY(debug)
 
 ENTRY(int3)
         pushq $0
+#ifdef XEN_KDB_CONFIG
+        pushq %rax
+        GET_CPUINFO_FIELD(CPUINFO_processor_id, %rax)
+        movq  (%rax), %rax
+        lock  bts %rax, kdb_cpu_traps(%rip)
+        popq  %rax
+#endif
         movl  $TRAP_int3,4(%rsp)
         jmp   handle_exception
 
diff -r 32034d1914a6 xen/common/domain.c
--- a/xen/common/domain.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/domain.c	Fri Jun 15 12:13:29 2012 -0700
@@ -530,6 +530,14 @@ void domain_shutdown(struct domain *d, u
 {
     struct vcpu *v;
 
+#ifdef XEN_KDB_CONFIG
+    if (reason == SHUTDOWN_crash) {
+        if ( IS_PRIV(d) )
+            kdb_trap_immed(KDB_TRAP_FATAL);
+        else
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+    }
+#endif
     spin_lock(&d->shutdown_lock);
 
     if ( d->shutdown_code == -1 )
@@ -624,7 +632,9 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_global_virq(VIRQ_DEBUGGER);
+    /* send VIRQ_DEBUGGER to guest only if gdbsx_vcpu_event is not active */
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r 32034d1914a6 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/sched_credit.c	Fri Jun 15 12:13:29 2012 -0700
@@ -1475,6 +1475,33 @@ csched_dump_vcpu(struct csched_vcpu *svc
     printk("\n");
 }
 
+#ifdef XEN_KDB_CONFIG
+static void kdb_csched_dump(int cpu)
+{
+    struct csched_pcpu *pcpup = CSCHED_PCPU(cpu);
+    struct vcpu *scurrvp = (CSCHED_VCPU(current))->vcpu;
+    struct list_head *tmp, *runq = RUNQ(cpu);
+
+    kdbp("    csched_pcpu: %p\n", pcpup);
+    kdbp("    curr csched:%p {vcpu:%p id:%d domid:%d}\n", (current)->sched_priv,
+         scurrvp, scurrvp->vcpu_id, scurrvp->domain->domain_id);
+    kdbp("    runq:\n");
+
+    /* next is top of struct, so screw stupid, ugly hard to follow macros */
+    if (offsetof(struct csched_vcpu, runq_elem.next) != 0) {
+        kdbp("next is not first in struct csched_vcpu. please fixme\n");
+        return;        /* otherwise for loop will crash */
+    }
+    for (tmp = runq->next; tmp != runq; tmp = tmp->next) {
+
+        struct csched_vcpu *csp = (struct csched_vcpu *)tmp;
+        struct vcpu *vp = csp->vcpu;
+        kdbp("      csp:%p pri:%02d vcpu: {p:%p id:%d domid:%d}\n", csp,
+             csp->pri, vp, vp->vcpu_id, vp->domain->domain_id);
+    };
+}
+#endif
+
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
@@ -1484,6 +1511,10 @@ csched_dump_pcpu(const struct scheduler 
     int loop;
 #define cpustr keyhandler_scratch
 
+#ifdef XEN_KDB_CONFIG
+    kdb_csched_dump(cpu);
+    return;
+#endif
     spc = CSCHED_PCPU(cpu);
     runq = &spc->runq;
 
diff -r 32034d1914a6 xen/common/schedule.c
--- a/xen/common/schedule.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/schedule.c	Fri Jun 15 12:13:29 2012 -0700
@@ -1454,6 +1454,25 @@ void wait(void)
     schedule();
 }
 
+#ifdef XEN_KDB_CONFIG
+void kdb_print_sched_info(void)
+{
+    int cpu;
+
+    kdbp("Scheduler: name:%s opt_name:%s id:%d\n", ops.name, ops.opt_name,
+         ops.sched_id);
+    kdbp("per cpu schedule_data:\n");
+    for_each_online_cpu(cpu) {
+        struct schedule_data *p =  &per_cpu(schedule_data, cpu);
+        kdbp("  cpu:%d  &(per cpu)schedule_data:%p\n", cpu, p);
+        kdbp("         curr:%p sched_priv:%p\n", p->curr, p->sched_priv);
+        kdbp("\n");
+        ops.dump_cpu_state(&ops, cpu);
+        kdbp("\n");
+    }
+}
+#endif
+
 #ifdef CONFIG_COMPAT
 #include "compat/schedule.c"
 #endif
diff -r 32034d1914a6 xen/common/symbols.c
--- a/xen/common/symbols.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/symbols.c	Fri Jun 15 12:13:29 2012 -0700
@@ -168,3 +168,21 @@ void __print_symbol(const char *fmt, uns
 
     spin_unlock_irqrestore(&lock, flags);
 }
+
+#ifdef XEN_KDB_CONFIG
+/*
+ *  * Given a symbol, return its address 
+ *   */
+unsigned long address_lookup(char *symp)
+{
+    int i, off = 0;
+    char namebuf[KSYM_NAME_LEN+1];
+
+    for (i=0; i < symbols_num_syms; i++) {
+        off = symbols_expand_symbol(off, namebuf);
+        if (strcmp(namebuf, symp) == 0)                  /* found it */
+            return symbols_address(i);
+    }
+    return 0;
+}
+#endif
diff -r 32034d1914a6 xen/common/timer.c
--- a/xen/common/timer.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/common/timer.c	Fri Jun 15 12:13:29 2012 -0700
@@ -643,6 +643,48 @@ void __init timer_init(void)
     register_keyhandler('a', &dump_timerq_keyhandler);
 }
 
+#ifdef XEN_KDB_CONFIG
+#include <xen/symbols.h>
+void kdb_dump_timer_queues(void)
+{
+    struct timer  *t;
+    struct timers *ts;
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1];
+    int cpu, j;
+    u64 tsc;
+
+    for_each_online_cpu( cpu )
+    {
+        ts = &per_cpu(timers, cpu);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
+
+        /* timers in the heap */
+        for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
+            t = ts->heap[j];
+            kdbp("  %d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+        /* timers on the link list */
+        for ( t = ts->list, j = 0; t != NULL; t = t->list_next, j++ ) {
+            kdbp(" L%d: exp=0x%08x%08x fn:%s data:%p\n",
+                 j, (u32)(t->expires>>32), (u32)t->expires,
+                 symbols_lookup((unsigned long)t->function, &sz, &offs, buf),
+                 t->data);
+        }
+    }
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r 32034d1914a6 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/drivers/char/console.c	Fri Jun 15 12:13:29 2012 -0700
@@ -295,6 +295,21 @@ static void serial_rx(char c, struct cpu
 {
     static int switch_code_count = 0;
 
+#ifdef XEN_KDB_CONFIG
+    /* if ctrl-\ pressed and kdb handles it, return */
+    if (kdb_enabled && c == 0x1c) {
+        if (!kdb_session_begun) {
+            if (kdb_keyboard(regs))
+                return;
+        } else {
+            kdbp("Sorry... kdb session already active.. please try again..\n");
+            return;
+        }
+    }
+    if (kdb_session_begun)      /* kdb should already be polling */
+        return;                 /* swallow chars so they don't buffer in dom0 */
+#endif
+
     if ( switch_code && (c == switch_code) )
     {
         /* We eat CTRL-<switch_char> in groups of 3 to switch console input. */
@@ -710,6 +725,18 @@ void console_end_sync(void)
     atomic_dec(&print_everything);
 }
 
+#ifdef XEN_KDB_CONFIG
+void console_putc(char c)
+{
+    serial_putc(sercon_handle, c);
+}
+
+int console_getc(void)
+{
+    return serial_getc(sercon_handle);
+}
+#endif
+
 /*
  * printk rate limiting, lifted from Linux.
  *
diff -r 32034d1914a6 xen/include/asm-x86/debugger.h
--- a/xen/include/asm-x86/debugger.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/asm-x86/debugger.h	Fri Jun 15 12:13:29 2012 -0700
@@ -39,7 +39,11 @@
 #define DEBUGGER_trap_fatal(_v, _r) \
     if ( debugger_trap_fatal(_v, _r) ) return;
 
-#if defined(CRASH_DEBUG)
+#if defined(XEN_KDB_CONFIG)
+#define debugger_trap_immediate() kdb_trap_immed(KDB_TRAP_NONFATAL)
+#define debugger_trap_fatal(_v, _r) kdb_trap_fatal(_v, _r)
+
+#elif defined(CRASH_DEBUG)
 
 #include <xen/gdbstub.h>
 
@@ -70,6 +74,10 @@ static inline int debugger_trap_entry(
 {
     struct vcpu *v = current;
 
+#ifdef XEN_KDB_CONFIG
+    if (kdb_handle_trap_entry(vector, regs))
+        return 1;
+#endif
     if ( guest_kernel_mode(v, regs) && v->domain->debugger_attached &&
          ((vector == TRAP_int3) || (vector == TRAP_debug)) )
     {
diff -r 32034d1914a6 xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/lib.h	Fri Jun 15 12:13:29 2012 -0700
@@ -116,4 +116,7 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+#ifdef XEN_KDB_CONFIG
+#include "../../kdb/include/kdb_extern.h"
+#endif
 #endif /* __LIB_H__ */
diff -r 32034d1914a6 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/xen/include/xen/sched.h	Fri Jun 15 12:13:29 2012 -0700
@@ -576,11 +576,14 @@ extern void (*dead_idle) (void);
 unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
-
+#ifdef XEN_KDB_CONFIG
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
diff -r 32034d1914a6 xen/kdb/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,5 @@
+
+obj-y		+= kdbmain.o kdb_cmds.o kdb_io.o 
+
+subdir-y += x86 guest
+
diff -r 32034d1914a6 xen/kdb/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/README	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,243 @@
+
+Welcome to kdb for xen, a hypervisor built in debugger.
+
+FEATURES:
+   - set breakpoints in hypervisor
+   - examine virt/machine memory, registers, domains, vcpus, etc...
+   - single step, single step till jump/call, step over call to next
+     instruction after the call.
+   - examine memory of a PV/HVM guest. 
+   - set breakpoints, single step, etc... for a PV guest.
+   - breaking into the debugger will freeze the system, all CPUs will pause,
+     no interrupts are acknowledged in the debugger. (Hence, the wall clock
+     will drift)
+   - single step will step only that cpu.
+   - earlykdb: break into kdb very early during boot. Put "earlykdb" on the
+               xen command line in grub.conf.
+   - generic tracing functions (see below) for quick tracing to debug timing
+     related problems. To use:
+        o set KDBTRCMAX to max num of recs in circular trc buffer in kdbmain.c
+	o call kdb_trc() from anywhere in xen
+	o turn tracing on by setting kdb_trcon in kdbmain.c or trcon command.
+	o trcp in kdb will give hints to dump trace recs. Use dd to see buffer
+	o trcz will zero out the entire buffer if needed.
+
+NOTE:
+   - since almost all numbers are in hex, 0x is not prefixed. Instead, decimal
+     numbers are preceded by $, as in $17 (sorry, one gets used to it). Note,
+     vcpu num, cpu num, domid are always displayed in decimal, without $.
+   - watchdog must be disabled to use kdb
+
+ISSUES:
+   - Currently, debug hypervisor is not supported. Make sure NDEBUG is defined
+     or compile with debug=n
+   - "timer went backwards" messages on dom0, but kdb/hyp should be fine.
+     I usually do "echo 2 > /proc/sys/kernel/printk" when using kdb.
+   - 32bit hypervisor may hang. Tested on 64bit hypervisor only.
+    
+
+TO BUILD:
+ - do >make kdb=y
+
+HOW TO USE:
+  1. A serial line is needed to use the debugger. Set up a serial line
+     from the source machine to target victim. Make sure the serial line
+     is working properly by displaying login prompt and loging in etc....
+
+  2. Add following to grub.conf:
+        kernel /xen.kdb console=com1,vga com1=57600,8n1 dom0_mem=542M
+
+        (57600 or whatever used in step 1 above)
+
+  3. Boot the hypervisor built with the debugger. 
+
+  4. ctrl-\ (ctrl and backslash) will break into the debugger. If the system is
+     badly hung, pressing NMI would also break into it. However, once kdb is
+     entered via NMI, normal execution can't continue.
+
+  5. type 'h' for list of commands.
+
+  6. Command line editing is limited to backspace. ctrl-c to start a new cmd.
+
+
+
+GUEST debug:
+  - type sym in the debugger
+  - for REL4, grep kallsyms_names, kallsyms_addresses, and kallsyms_num_syms
+    in the guest System.map* file. Run sym again with domid and the three
+    values on the command line.
+  - Now basic symbols can be used for guest debug. Note, if the binary is not
+    built with symbols, only function names are available, but not global vars.
+
+    Eg: sym 0 c0696084 c068a590 c0696080 c06b43e8 c06b4740
+        will set symbols for dom 0. Then :
+
+        [4]xkdb> bp some_function 0
+
+	wills set bp at some_function in dom 0
+
+	[3]xkdb> dw c068a590 32 0 : display 32 bytes of dom0 memory
+
+
+Tips:
+  - In "[0]xkdb>"  : 0 is the cpu number in decimal
+  - In
+      00000000c042645c: 0:do_timer+17                  push %ebp
+    0:do_timer : 0 is the domid in hex
+    offset +17 is in hex.
+
+    absense of 0: would indicate it's a hypervisor function
+
+  - commands starting with kdb (kdb*) are for kdb debug only.
+
+
+Finally,
+ - think hex.
+ - bug/problem: enter kdbdbg, reproduce, and send me the output.
+   If the output is not enough, I may ask to run kdbdbg twice, then collect
+   output.
+
+
+Thanks,
+Mukesh Rathor
+Oracle Corporatin, 
+Redwood Shores, CA 94065
+
+--------------------------------------------------------------------------------
+COMMAND DESCRIPTION:
+
+info:  Print basic info like version, compile flags, etc..
+
+cur:  print current domain id and vcpu id
+
+f: display current stack. If a vcpu ptr is given, then print stack for that
+   VCPU by using its IP and SP.
+
+fg: display stack for a guest given domid, SP and IP.
+
+dw: display words of memory. 'num' of bytes is optional, but if displaying guest
+    memory, then is required.
+
+dd: same as above, but display doublewords.
+
+dwm: same as above but the address is machine address instead of virtual.
+
+ddm: same as above, but display doublewords.
+
+dr: display registers. if 'sp' is specified then print few extra registers.
+
+drg: display guest context saved on stack bottom.
+
+dis: disassemble instructions. If disassembling for guest, then 'num' must
+     be specified. 'num' is number of instrs to display.
+
+dism: toggle disassembly mode between Intel and ATT/GAS.
+
+mw: modify word in memory given virtual address. 'domid' may be specified if
+    modifying guest memory. value is assumed in hex even without 0x.
+
+md: same as above but modify doubleword.
+
+mr: modify register. value is assumd hex.
+
+bc: clear given or all breakpoints
+
+bp: display breakpoints or set a breakpoint. Domid may be specified to set a bp
+    in guest. kdb functions may not be specified if debugging kdb.
+    Example:
+      xkdb> bp acpi_processor_idle  : will set bp in xen
+      xkdb> bp default_idle 0 :   will set bp in domid 0
+      xkdb> bp idle_cpu 9 :   will set bp in domid 9
+
+     Conditions may be specified for a bp: lhs == rhs or lhs != rhs
+     where : lhs is register like 'r6', 'rax', etc...  or memory location
+             rhs is hex value with or without leading 0x.
+     Thus,
+      xkdb> bp acpi_processor_idle rdi == c000 
+      xkdb> bp 0xffffffff80062ebc 0 rsi == ffff880021edbc98 : will break into
+            kdb at 0xffffffff80062ebc in dom0 when rsi is ffff880021edbc98 
+
+btp: break point trace. Upon bp, print some info and continue without stopping.
+   Ex: btp idle_cpu 7 rax rbx 0x20ef5a5 r9
+
+   will print: rax, rbx, *(long *)0x20ef5a5, r9 upon hitting idle_cpu() and 
+               continue.
+
+wp: set a watchpoint at a virtual address which can belong to hypervisor or
+    any guest. Do not specify wp in kdb path if debugging kdb.
+
+wc: clear given or all watchpoints.
+
+ni: single step, stepping over function calls.
+
+ss: single step. Be carefull when in interrupt handlers or context switches.
+    
+ssb: single step to branch. Use with care.
+
+go: leave kdb and continue.
+
+cpu: go back to orig cpu when entering kdb. If 'cpu number' given, then switch 
+     to that cpu. If 'all' then show status of all cpus.
+
+nmi: Only available in hung/crash state. Send NMI to a cpu that may be hung.
+
+sym: Initialize a symbol table for debugging a guest. Look into the System.map
+     file of guest for certain symbol values and provide them here.
+
+vcpuh: Given vcpu ptr, display hvm_vcpu struct.
+
+vcpu: Display current vcpu struct. If 'vcpu-ptr' given, display that vcpu.
+
+dom: display current domain. If 'domid' then display that domid. If 'all', then
+     display all domains.
+
+sched: show schedular info and run queues.
+
+mmu: print basic mmu info
+
+p2m: convert a gpfn to mfn given a domid. value in hex even without 0x.
+
+m2p: convert mfn to pfn. value in hex even without 0x.
+
+dpage: display struct page given a mfn or struct page ptr. Since, no info is 
+       kept on page type, we display all possible page types.
+
+dtrq: display timer queues.
+
+didt: dump IDT table.
+
+dgt: dump GDT table.
+
+dirq: display IRQ bindings.
+
+dvmc: display all or given dom/vcpu VMCS or VMCB.
+
+trcon: turn tracing on. Trace hooks must be added in xen and kdb function
+       called directly from there.
+
+trcoff: turn tracing off.
+
+trcz: zero trace buffer.
+
+trcp: give hints to print the circular trace buffer, like current active ptr.
+
+usr1: allows to add any arbitraty command quickly.
+
+--------------------------------------------------------------------------------
+/*
+ * Copyright (C) 2008 Oracle.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
diff -r 32034d1914a6 xen/kdb/guest/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y           := kdb_guest.o
+
diff -r 32034d1914a6 xen/kdb/guest/kdb_guest.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/guest/kdb_guest.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,342 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+/* information for symbols for a guest (includeing dom 0 ) is saved here */
+struct gst_syminfo {           /* guest symbols info */
+    int   domid;               /* which domain */
+    int   bitness;             /* 32 or 64 */
+    void *addrtblp;            /* ptr to (32/64)addresses tbl */
+    u8   *toktbl;              /* ptr to kallsyms_token_table */
+    u16  *tokidxtbl;           /* ptr to kallsyms_token_index */
+    u8   *kallsyms_names;      /* ptr to kallsyms_names */
+    long  kallsyms_num_syms;   /* ptr to kallsyms_num_syms */
+    kdbva_t  stext;            /* value of _stext in guest */
+    kdbva_t  etext;            /* value of _etext in guest */
+    kdbva_t  sinittext;        /* value of _sinittext in guest */
+    kdbva_t  einittext;        /* value of _einittext in guest */
+};
+
+#define MAX_CACHE 16                              /* cache upto 16 guests */
+struct gst_syminfo gst_syminfoa[MAX_CACHE];       /* guest symbol info array */
+
+static struct gst_syminfo *
+kdb_get_syminfo_slot(void)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].addrtblp == NULL)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+static struct gst_syminfo *
+kdb_domid2syminfop(domid_t domid)
+{
+    int i;
+    for (i=0; i < MAX_CACHE; i++)
+        if (gst_syminfoa[i].domid == domid)
+            return (&gst_syminfoa[i]);      
+
+    return NULL;
+}
+
+/* check if an address looks like text address in guest */
+int
+kdb_is_addr_guest_text(kdbva_t addr, int domid)
+{
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    if (!gp || !gp->stext || !gp->etext)
+        return 0;
+    KDBGP1("guestaddr: addr:%lx domid:%d\n", addr, domid);
+
+    return ( (addr >= gp->stext && addr <= gp->etext) ||
+             (addr >= gp->sinittext && addr <= gp->einittext) );
+}
+
+/*
+ * returns: value of kallsyms_addresses[idx];
+ */
+static kdbva_t
+kdb_rd_guest_addrtbl(struct gst_syminfo *gp, int idx)
+{
+    kdbva_t addr, retaddr=0;
+    int num = gp->bitness/8;       /* whether 4 byte or 8 byte ptrs */
+    domid_t id = gp->domid;
+
+    addr = (kdbva_t)(((char *)gp->addrtblp) + idx * num);
+    KDBGP1("rdguestaddrtbl:addr:%lx idx:%d\n", addr, idx);
+
+    if (kdb_read_mem(addr, (kdbbyt_t *)&retaddr,num,id) != num) {
+        kdbp("Can't read addrtbl domid:%d at:%lx\n", id, addr);
+        return 0;
+    }
+    KDBGP1("rdguestaddrtbl:exit:retaddr:%lx\n", retaddr);
+    return retaddr;
+}
+
+/* Based on el5 kallsyms.c file. */
+static unsigned int 
+kdb_expand_el5_sym(struct gst_syminfo *gp, unsigned int off, char *result)
+{   
+    int len, skipped_first = 0;
+    u8 u8idx, *tptr, *datap;
+    domid_t domid = gp->domid;
+
+    *result = '\0';
+
+    /* get the compressed symbol length from the first symbol byte */
+    datap = gp->kallsyms_names + off;
+    len = 0;
+    if ((kdb_read_mem((kdbva_t)datap, (kdbbyt_t *)&len, 1, domid)) != 1) {
+        KDBGP("failed to read guest memory\n");
+        return 0;
+    }
+    datap++;
+
+    /* update the offset to return the offset for the next symbol on
+     * the compressed stream */
+    off += len + 1;
+
+    /* for every byte on the compressed symbol data, copy the table
+     * entry for that byte */
+    while(len) {
+        u16 u16idx, *u16p;
+        if (kdb_read_mem((kdbva_t)datap,(kdbbyt_t *)&u8idx,1,domid)!=1){
+            kdbp("memory (u8idx) read error:%p\n",gp->tokidxtbl);
+            return 0;
+        }
+        u16p = u8idx + gp->tokidxtbl;
+        if (kdb_read_mem((kdbva_t)u16p,(kdbbyt_t *)&u16idx,2,domid)!=2){
+            kdbp("tokidxtbl read error:%p\n", u16p);
+            return 0;
+        }
+        tptr = gp->toktbl + u16idx;
+        datap++;
+        len--;
+
+        while ((kdb_read_mem((kdbva_t)tptr, (kdbbyt_t *)&u8idx, 1, domid)==1) &&
+               u8idx) {
+
+            if(skipped_first) {
+                *result = u8idx;
+                result++;
+            } else
+                skipped_first = 1;
+            tptr++;
+        }
+    }
+    *result = '\0';
+    return off;          /* return to offset to the next symbol */
+}
+
+#define EL4_NMLEN 127
+/* so much pain, so not sure of it's worth .. :).. */
+static kdbva_t
+kdb_expand_el4_sym(struct gst_syminfo *gp, int low, char *result, char *symp)
+{   
+    int i, j;
+    u8 *nmp = gp->kallsyms_names;       /* guest address space */
+    kdbbyt_t byte, prefix;
+    domid_t id = gp->domid;
+    kdbva_t addr;
+
+    KDBGP1("Eel4sym:nmp:%p maxidx:$%d sym:%s\n", nmp, low, symp);
+    for (i=0; i <= low; i++) {
+        /* unsigned prefix = *name++; */
+        if (kdb_read_mem((kdbva_t)nmp, &prefix, 1, id) != 1) {
+            kdbp("failed to read:%p domid:%x\n", nmp, id);
+            return 0;
+        }
+        KDBGP2("el4:i:%d prefix:%x\n", i, prefix);
+        nmp++;
+        /* strncpy(namebuf + prefix, name, KSYM_NAME_LEN - prefix); */
+        addr = (long)result + prefix;
+        for (j=0; j < EL4_NMLEN-prefix; j++) {
+            if (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) != 1) {
+                kdbp("failed read:%p domid:%x\n", nmp, id);
+                return 0;
+            }
+            KDBGP2("el4:j:%d byte:%x\n", j, byte);
+            *(kdbbyt_t *)addr = byte;
+            addr++; nmp++;
+            if (byte == '\0')
+                break;
+        }
+        KDBGP2("el4sym:i:%d res:%s\n", i, result);
+        if (symp && strcmp(result, symp) == 0)
+            return(kdb_rd_guest_addrtbl(gp, i));
+
+        /* kallsyms.c: name += strlen(name) + 1; */
+        if (j == EL4_NMLEN-prefix && byte != '\0')
+            while (kdb_read_mem((kdbva_t)nmp, &byte, 1, id) && byte != '\0')
+                nmp++;
+    }
+    KDBGP1("Xel4sym: na-ga-da\n");
+    return 0;
+}
+
+static unsigned int
+kdb_get_el5_symoffset(struct gst_syminfo *gp, long pos)
+{
+    int i;
+    u8 data, *namep;
+    domid_t domid = gp->domid;
+
+    namep = gp->kallsyms_names;
+    for (i=0; i < pos; i++) {
+        if (kdb_read_mem((kdbva_t)namep, &data, 1, domid) != 1) {
+            kdbp("Can't read id:$%d mem:%p\n", domid, namep);
+            return 0;
+        }
+        namep = namep + data + 1;
+    }
+    return namep - gp->kallsyms_names;
+}
+
+/*
+ * for a given guest domid (domid >= 0 && < KDB_HYPDOMID), convert addr to
+ * symbol. offset is set to  addr - symbolstart
+ */
+char *
+kdb_guest_addr2sym(unsigned long addr, domid_t domid, ulong *offsp)
+{
+    static char namebuf[KSYM_NAME_LEN+1];
+    unsigned long low, high, mid;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    *offsp = 0;
+    if(!gp || gp->kallsyms_num_syms == 0)
+        return " ??? ";
+
+    namebuf[0] = namebuf[KSYM_NAME_LEN] = '\0';
+    if (1) {
+        /* do a binary search on the sorted kallsyms_addresses array */
+        low = 0;
+        high = gp->kallsyms_num_syms;
+
+        while (high-low > 1) {
+            mid = (low + high) / 2;
+            if (kdb_rd_guest_addrtbl(gp, mid) <= addr) 
+                low = mid;
+            else 
+                high = mid;
+        }
+        /* Grab name */
+        if (gp->toktbl) {
+            int symoff = kdb_get_el5_symoffset(gp,low);
+            kdb_expand_el5_sym(gp, symoff, namebuf);
+        } else
+            kdb_expand_el4_sym(gp, low, namebuf, NULL);
+        *offsp = addr - kdb_rd_guest_addrtbl(gp, low);
+        return namebuf;
+    }
+    return " ???? ";
+}
+
+
+/* 
+ * save guest (dom0 and others) symbols info : domid and following addresses:
+ *     &kallsyms_names &kallsyms_addresses &kallsyms_num_syms \
+ *     &kallsyms_token_table &kallsyms_token_index
+ */
+void
+kdb_sav_dom_syminfo(domid_t domid, long namesp, long addrap, long nump,
+                    long toktblp, long tokidxp)
+{
+    int bytes;
+    long val = 0;    /* must be set to zero for 32 on 64 cases */
+    struct gst_syminfo *gp = kdb_get_syminfo_slot();
+
+    if (gp == NULL) {
+        kdbp("kdb:kdb_sav_dom_syminfo():Table full.. symbols not saved\n");
+        return;
+    }
+    memset(gp, 0, sizeof(*gp));
+
+    gp->domid = domid;
+    gp->bitness = kdb_guest_bitness(domid);
+    gp->addrtblp = (void *)addrap;
+    gp->kallsyms_names = (u8 *)namesp;
+    gp->toktbl = (u8 *)toktblp;
+    gp->tokidxtbl = (u16 *)tokidxp;
+
+    KDBGP("domid:%x bitness:$%d numsyms:$%ld arrayp:%p\n", domid,
+          gp->bitness, gp->kallsyms_num_syms, gp->addrtblp);
+
+    bytes = gp->bitness/8;
+    if (kdb_read_mem(nump, (kdbbyt_t *)&val, bytes, domid) != bytes) {
+
+        kdbp("Unable to read number of symbols from:%lx\n", nump);
+        memset(gp, 0, sizeof(*gp));
+        return;
+    } else
+        kdbp("Number of symbols:$%ld\n", val);
+
+    gp->kallsyms_num_syms = val;
+
+    bytes = (gp->bitness/8) * gp->kallsyms_num_syms;
+    gp->stext = kdb_guest_sym2addr("_stext", domid);
+    gp->etext = kdb_guest_sym2addr("_etext", domid);
+    if (!gp->stext || !gp->etext)
+        kdbp("Warn: Can't find stext/etext\n");
+
+    if (gp->toktbl && gp->tokidxtbl) {
+        gp->sinittext = kdb_guest_sym2addr("_sinittext", domid);
+        gp->einittext = kdb_guest_sym2addr("_einittext", domid);
+        if (!gp->sinittext || !gp->einittext) {
+            kdbp("Warn: Can't find sinittext/einittext\n");
+    } 
+    }
+    KDBGP1("stxt:%lx etxt:%lx sitxt:%lx eitxt:%lx\n", gp->stext, gp->etext,
+           gp->sinittext, gp->einittext);
+    kdbp("Succesfully saved symbol info\n");
+}
+
+/*
+ * given a symbol string for a guest/domid, return its address
+ */
+kdbva_t
+kdb_guest_sym2addr(char *symp, domid_t domid)
+{
+    char namebuf[KSYM_NAME_LEN+1];
+    int i, off=0;
+    struct gst_syminfo *gp = kdb_domid2syminfop(domid);
+
+    KDBGP("sym2a: sym:%s domid:%x numsyms:%ld\n", symp, domid,
+          gp ? gp->kallsyms_num_syms: -1);
+
+    if (!gp)
+        return 0;
+
+    if (gp->toktbl == 0 || gp->tokidxtbl == 0)
+        return(kdb_expand_el4_sym(gp, gp->kallsyms_num_syms, namebuf, symp));
+
+    for (i=0; i < gp->kallsyms_num_syms; i++) {
+        off = kdb_expand_el5_sym(gp, off, namebuf);
+        KDBGP1("i:%d namebuf:%s\n", i, namebuf);
+        if (strcmp(namebuf, symp) == 0) {
+            return(kdb_rd_guest_addrtbl(gp, i));
+        }
+    }
+    KDBGP("sym2a:exit:na-ga-da\n");
+    return 0;
+}
diff -r 32034d1914a6 xen/kdb/include/kdb_extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdb_extern.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDB_EXTERN_H
+#define _KDB_EXTERN_H
+
+#define KDB_TRAP_FATAL     1    /* trap is fatal. can't resume from kdb */
+#define KDB_TRAP_NONFATAL  2    /* can resume from kdb */
+#define KDB_TRAP_KDBSTACK  3    /* to debug kdb itself. dump kdb stack */
+
+/* following can be called from anywhere in xen to debug */
+extern void kdb_trap_immed(int);
+extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
+extern void kdbp(const char *fmt, ...);
+
+typedef unsigned long kdbva_t;
+typedef unsigned char kdbbyt_t;
+typedef unsigned long kdbma_t;
+
+extern unsigned long kdb_dr7;
+
+
+extern volatile int kdb_session_begun;
+extern volatile int kdb_enabled;
+extern void kdb_init(void);
+extern int kdb_keyboard(struct cpu_user_regs *);
+extern void kdb_ssni_reenter(struct cpu_user_regs *);
+extern int kdb_handle_trap_entry(int, struct cpu_user_regs *);
+extern int kdb_trap_fatal(int, struct cpu_user_regs *);  /* fatal with regs */
+extern void kdb_dump_vmcs(uint16_t did, int vid);
+void kdb_dump_vmcb(uint16_t did, int vid);
+extern void kdb_dump_time_pcpu(void);
+
+
+#define VMPTRST_OPCODE  ".byte 0x0f,0xc7\n"     /* reg/opcode: /7 */
+#define MODRM_EAX_07    ".byte 0x38\n"          /* [EAX], with reg/opcode: /7 */
+static inline void __vmptrst(u64 *addr)
+{
+    asm volatile ( VMPTRST_OPCODE
+                   MODRM_EAX_07
+                   :
+                   : "a" (addr)
+                   : "memory");
+}
+
+extern void mukchk(unsigned long);
+#define is_hvm_or_hyb_domain is_hvm_domain
+#define is_hvm_or_hyb_vcpu is_hvm_vcpu
+
+
+#endif  /* _KDB_EXTERN_H */
diff -r 32034d1914a6 xen/kdb/include/kdbdefs.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbdefs.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBDEFS_H
+#define _KDBDEFS_H
+
+/* reason we are entering kdbmain (bp == breakpoint) */
+typedef enum {
+    KDB_REASON_KEYBOARD=1,  /* Keyboard entry - always 1 */
+    KDB_REASON_BPEXCP,      /* #BP excp: sw bp (INT3) */
+    KDB_REASON_DBEXCP,      /* #DB excp: TF flag or HW bp */
+    KDB_REASON_PAUSE_IPI,   /* received pause IPI from another CPU */
+} kdb_reason_t;
+
+
+/* cpu state: past, present, and future */
+typedef enum {
+    KDB_CPU_INVAL=0,     /* invalid value. not in or leaving kdb */
+    KDB_CPU_QUIT,        /* main cpu does GO. all others do QUIT */
+    KDB_CPU_PAUSE,       /* cpu is paused */
+    KDB_CPU_DISABLE,     /* disable interrupts */
+    KDB_CPU_SHOWPC,      /* all cpus must display their pc */
+    KDB_CPU_DO_VMEXIT,   /* all cpus must do vmcs vmexit. intel only */
+    KDB_CPU_MAIN_KDB,    /* cpu in kdb main command loop */
+    KDB_CPU_GO,          /* user entered go for this cpu */
+    KDB_CPU_SS,          /* single step for this cpu */
+    KDB_CPU_NI,          /* go to next instr after the call instr */
+    KDB_CPU_INSTALL_BP,  /* delayed install of sw bp(s) by this cpu */
+} kdb_cpu_cmd_t;
+
+/* ============= kdb commands ============================================= */
+
+typedef kdb_cpu_cmd_t (*kdb_func_t)(int, const char **, struct cpu_user_regs *);
+typedef kdb_cpu_cmd_t (*kdb_usgf_t)(void);
+
+typedef enum {
+    KDB_REPEAT_NONE = 0,    /* Do not repeat this command */
+    KDB_REPEAT_NO_ARGS,     /* Repeat the command without arguments */
+    KDB_REPEAT_WITH_ARGS,   /* Repeat the command including its arguments */
+} kdb_repeat_t;
+
+typedef struct _kdbtab {
+    char        *kdb_cmd_name;        /* Command name */
+    kdb_func_t   kdb_cmd_func;        /* ptr to function to execute command */
+    kdb_usgf_t   kdb_cmd_usgf;        /* usage function ptr */
+    int          kdb_cmd_crash_avail; /* available in sys fatal/crash state */
+    kdb_repeat_t kdb_cmd_repeat;      /* Does command auto repeat on enter? */
+} kdbtab_t;
+
+
+/* ============= types and stuff ========================================= */
+#define BFD_INVAL (~0UL)            /* invalid bfd_vma */
+
+#if defined(__x86_64__)
+  #define KDBIP rip
+  #define KDBSP rsp
+#else
+  #define KDBIP eip
+  #define KDBSP esp
+#endif
+
+/* ============= macros ================================================== */
+extern volatile int kdbdbg;
+#define KDBGP(...) {(kdbdbg) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP1(...) {(kdbdbg>1) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP2(...) {(kdbdbg>2) ? kdbp(__VA_ARGS__):0;}
+#define KDBGP3(...) {0;};
+
+#define KDBMIN(x,y) (((x)<(y))?(x):(y))
+
+#endif  /* !_KDBDEFS_H */
diff -r 32034d1914a6 xen/kdb/include/kdbinc.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbinc.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBINC_H
+#define _KDBINC_H
+
+#include <xen/compile.h>
+#include <xen/config.h>
+#include <xen/version.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/mm.h>
+#include <xen/event.h>
+#include <xen/time.h>
+#include <xen/console.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/rangeset.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/delay.h>
+#include <xen/shutdown.h>
+#include <xen/percpu.h>
+#include <xen/multicall.h>
+#include <xen/rcupdate.h>
+#include <xen/ctype.h>
+#include <xen/symbols.h>
+#include <xen/shutdown.h>
+#include <xen/serial.h>
+#include <xen/grant_table.h>
+#include <asm/debugger.h>
+#include <asm/shared.h>
+#include <asm/apicdef.h>
+
+#include <asm/nmi.h>
+#include <asm/p2m.h>
+#include <asm/debugreg.h>
+#include <public/sched.h>
+#include <public/vcpu.h>
+#ifdef _XEN_LATEST
+#include <xsm/xsm.h>
+#endif
+
+#include <asm/hvm/vmx/vmx.h>
+
+#include "kdb_extern.h"
+#include "kdbdefs.h"
+#include "kdbproto.h"
+
+#endif /* !_KDBINC_H */
diff -r 32034d1914a6 xen/kdb/include/kdbproto.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/include/kdbproto.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#ifndef _KDBPROTO_H
+#define _KDBPROTO_H
+
+/* hypervisor interfaces use by kdb or kdb interfaces in xen files */
+extern void console_putc(char);
+extern int console_getc(void);
+extern void show_trace(struct cpu_user_regs *);
+extern void kdb_dump_timer_queues(void);
+extern void kdb_time_resume(int);
+extern void kdb_print_sched_info(void);
+extern void kdb_curr_cpu_flush_vmcs(void);
+extern unsigned long address_lookup(char *);
+extern void kdb_prnt_guest_mapped_irqs(void);
+
+/* kdb globals */
+extern kdbtab_t *kdb_cmd_tbl;
+extern char kdb_prompt[32];
+extern volatile int kdb_sys_crash;
+extern volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+extern volatile int kdb_trcon;
+
+/* kdb interfaces */
+extern void __init kdb_io_init(void);
+extern void kdb_init_cmdtab(void);
+extern void kdb_do_cmds(struct cpu_user_regs *);
+extern int kdb_check_sw_bkpts(struct cpu_user_regs *);
+extern int kdb_check_watchpoints(struct cpu_user_regs *);
+extern void kdb_do_watchpoints(kdbva_t, int, int);
+extern void kdb_install_watchpoints(void);
+extern void kdb_clear_wps(int);
+extern kdbma_t kdb_rd_dbgreg(int);
+
+
+
+extern char *kdb_get_cmdline(char *);
+extern void kdb_clear_prev_cmd(void);
+extern void kdb_toggle_dis_syntax(void);
+extern int kdb_check_call_instr(domid_t, kdbva_t);
+extern void kdb_display_pc(struct cpu_user_regs *);
+extern kdbva_t kdb_print_instr(kdbva_t, long, domid_t);
+extern int kdb_read_mmem(kdbva_t, kdbbyt_t *, int);
+extern int kdb_read_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+extern int kdb_write_mem(kdbva_t, kdbbyt_t *, int, domid_t);
+
+extern void kdb_install_all_swbp(void);
+extern void kdb_uninstall_all_swbp(void);
+extern int kdb_swbp_exists(void);
+extern void kdb_flush_swbp_table(void);
+extern int kdb_is_addr_guest_text(kdbva_t, int);
+extern kdbva_t kdb_guest_sym2addr(char *, domid_t);
+extern char *kdb_guest_addr2sym(unsigned long, domid_t, ulong *);
+extern void kdb_prnt_addr2sym(domid_t, kdbva_t, char *);
+extern void kdb_sav_dom_syminfo(domid_t, long, long, long, long, long);
+extern int kdb_guest_bitness(domid_t);
+extern void kdb_nmi_pause_cpus(cpumask_t);
+
+extern void kdb_trczero(void);
+void kdb_trcp(void);
+
+
+
+#endif /* !_KDBPROTO_H */
diff -r 32034d1914a6 xen/kdb/kdb_cmds.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_cmds.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3769 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+#if defined(__x86_64__)
+    #define KDBF64 "%lx"
+    #define KDBFL "%016lx"         /* print long all digits */
+#else
+    #define KDBF64 "%llx"
+    #define KDBFL "%08lx"
+#endif
+
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    #define KDB_LKDEF(l) ((l).raw.lock)
+    #define KDB_PGLLE(t) ((t).tail)    /* page list last element ^%$#@ */
+#else
+    #define KDB_LKDEF(l) ((l).lock)
+    #define KDB_PGLLE(t) ((t).prev)    /* page list last element ^%$#@ */
+#endif
+
+#define KDB_CMD_HISTORY_COUNT   32
+#define CMD_BUFLEN              200     /* kdb_printf: max printline == 256 */
+
+#define KDBMAXSBP 16                    /* max number of software breakpoints */
+#define KDB_MAXARGC 16                  /* max args in a kdb command */
+#define KDB_MAXBTP  8                   /* max display args in btp */
+
+/* condition is: 'r6 == 0x123f' or '0xffffffff82800000 != deadbeef'  */
+struct kdb_bpcond {
+    kdbbyt_t bp_cond_status;       /* 0 == off, 1 == register, 2 == memory */
+    kdbbyt_t bp_cond_type;         /* 0 == bad, 1 == equal, 2 == not equal */
+    ulong    bp_cond_lhs;          /* lhs of condition: reg offset or mem loc */
+    ulong    bp_cond_rhs;          /* right hand side of condition */
+};
+
+/* software breakpoint structure */
+struct kdb_sbrkpt {
+    kdbva_t  bp_addr;              /* address the bp is set at */
+    domid_t  bp_domid;             /* which domain the bp belongs to */
+    kdbbyt_t bp_originst;          /* save orig instr/s here */
+    kdbbyt_t bp_deleted;           /* delete pending on this bp */
+    kdbbyt_t bp_ni;                /* set for KDB_CPU_NI */
+    kdbbyt_t bp_just_added;        /* added in the current kdb session */
+    kdbbyt_t bp_type;              /* 0 = normal, 1 == cond,  2 == btp */
+    union {
+        struct kdb_bpcond bp_cond;
+        ulong *bp_btp;
+    } u;
+};
+
+/* don't use kmalloc in kdb which hijacks all cpus */
+static ulong kdb_btp_argsa[KDBMAXSBP][KDB_MAXBTP];
+static ulong *kdb_btp_ap[KDBMAXSBP];
+
+static struct kdb_reg_nmofs {
+    char *reg_nm;
+    int reg_offs;
+} kdb_reg_nm_offs[] =  {
+       { "rax", offsetof(struct cpu_user_regs, rax) },
+       { "rbx", offsetof(struct cpu_user_regs, rbx) },
+       { "rcx", offsetof(struct cpu_user_regs, rcx) },
+       { "rdx", offsetof(struct cpu_user_regs, rdx) },
+       { "rsi", offsetof(struct cpu_user_regs, rsi) },
+       { "rdi", offsetof(struct cpu_user_regs, rdi) },
+       { "rbp", offsetof(struct cpu_user_regs, rbp) },
+       { "rsp", offsetof(struct cpu_user_regs, rsp) },
+       { "r8",  offsetof(struct cpu_user_regs, r8) },
+       { "r9",  offsetof(struct cpu_user_regs, r9) },
+       { "r10", offsetof(struct cpu_user_regs, r10) },
+       { "r11", offsetof(struct cpu_user_regs, r11) },
+       { "r12", offsetof(struct cpu_user_regs, r12) },
+       { "r13", offsetof(struct cpu_user_regs, r13) },
+       { "r14", offsetof(struct cpu_user_regs, r14) },
+       { "r15", offsetof(struct cpu_user_regs, r15) },
+       { "rflags", offsetof(struct cpu_user_regs, rflags) } };
+
+static const int KDBBPSZ=1;                   /* size of KDB_BPINST is 1 byte*/
+static kdbbyt_t kdb_bpinst = 0xcc;            /* breakpoint instr: INT3 */
+static struct kdb_sbrkpt kdb_sbpa[KDBMAXSBP]; /* soft brkpt array/table */
+static kdbtab_t *tbp;
+
+static int kdb_set_bp(domid_t, kdbva_t, int, ulong *, char*, char*, char*);
+static void kdb_print_uregs(struct cpu_user_regs *);
+
+
+/* ===================== cmdline functions  ================================ */
+
+/* lp points to a string of only alpha numeric chars terminated by '\n'.
+ * Parse the string into argv pointers, and RETURN argc
+ * Eg:  if lp --> "dr  sp\n" :  argv[0]=="dr\0"  argv[1]=="sp\0"  argc==2
+ */
+static int
+kdb_parse_cmdline(char *lp, const char **argv)
+{
+    int i=0;
+
+    for (; *lp == ' '; lp++);      /* note: isspace() skips '\n' also */
+    while ( *lp != '\n' ) {
+        if (i == KDB_MAXARGC) {
+            printk("kdb: max args exceeded\n");
+            break;
+        }
+        argv[i++] = lp;
+        for (; *lp != ' ' && *lp != '\n'; lp++);
+        if (*lp != '\n')
+            *lp++ = '\0';
+        for (; *lp == ' '; lp++);
+    }
+    *lp = '\0';
+    return i;
+}
+
+void
+kdb_clear_prev_cmd()             /* so previous command is not repeated */
+{
+    tbp = NULL;
+}
+
+void
+kdb_do_cmds(struct cpu_user_regs *regs)
+{
+    char *cmdlinep;
+    const char *argv[KDB_MAXARGC];
+    int argc = 0, curcpu = smp_processor_id();
+    kdb_cpu_cmd_t result = KDB_CPU_MAIN_KDB;
+
+    snprintf(kdb_prompt, sizeof(kdb_prompt), "[%d]xkdb> ", curcpu);
+
+    while (result == KDB_CPU_MAIN_KDB) {
+        cmdlinep = kdb_get_cmdline(kdb_prompt);
+        if (*cmdlinep == '\n') {
+            if (tbp==NULL || tbp->kdb_cmd_func==NULL)
+                continue;
+            else
+                argc = -1;    /* repeat prev command */
+        } else {
+            argc = kdb_parse_cmdline(cmdlinep, argv);
+            for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_func; tbp++)  {
+                if (strcmp(argv[0], tbp->kdb_cmd_name)==0) 
+                    break;
+            }
+        }
+        if (kdb_sys_crash && tbp->kdb_cmd_func && !tbp->kdb_cmd_crash_avail) {
+            kdbp("cmd not available in fatal/crashed state....\n");
+            continue;
+        }
+        if (tbp->kdb_cmd_func) {
+            result = (*tbp->kdb_cmd_func)(argc, argv, regs);
+            if (tbp->kdb_cmd_repeat == KDB_REPEAT_NONE)
+                tbp = NULL;
+        } else
+            kdbp("kdb: Unknown cmd: %s\n", cmdlinep);
+    }
+    kdb_cpu_cmd[curcpu] = result;
+    return;
+}
+
+/* ===================== Util functions  ==================================== */
+
+int
+kdb_vcpu_valid(struct vcpu *in_vp)
+{
+    struct domain *dp;
+    struct vcpu *vp;
+
+    for(dp=domain_list; in_vp && dp; dp=dp->next_in_list)
+        for_each_vcpu(dp, vp)
+            if (in_vp == vp)
+                return 1;
+    return 0;     /* not found */
+}
+
+/*
+ * Given a symbol, find it's address
+ */
+static kdbva_t
+kdb_sym2addr(const char *p, domid_t domid)
+{
+    kdbva_t addr;
+
+    KDBGP1("sym2addr: p:%s domid:%d\n", p, domid);
+    if (domid == DOMID_IDLE)
+        addr = address_lookup((char *)p);
+    else
+        addr = (kdbva_t)kdb_guest_sym2addr((char *)p, domid);
+    KDBGP1("sym2addr: exit: addr returned:0x%lx\n", addr);
+    return addr;
+}
+
+/*
+ * convert ascii to int decimal (base 10). 
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2deci(const char *strp, int *intp)
+{
+    const char *endp;
+
+    KDBGP2("str2deci: str:%s\n", strp);
+    if (!isdigit(*strp))
+        return 0;
+    *intp = (int)simple_strtoul(strp, &endp, 10);
+    if (endp != strp+strlen(strp))
+        return 0;
+    KDBGP2("str2deci: intval:$%d\n", *intp);
+    return 1;
+}
+/*
+ * convert ascii to long. NOTE: base is 16
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2ulong(const char *strp, ulong *longp)
+{
+    ulong val;
+    const char *endp;
+
+    KDBGP2("str2long: str:%s\n", strp);
+    if (!isxdigit(*strp))
+        return 0;
+    val = (long)simple_strtoul(strp, &endp, 16);   /* handles leading 0x */
+    if (endp != strp+strlen(strp))
+        return 0;
+    if (longp)
+        *longp = val;
+    KDBGP2("str2long: val:0x%lx\n", val);
+    return 1;
+}
+/*
+ * convert a symbol or ascii address to hex address
+ * Return: 0 : failed to convert, otherwise 1 
+ */
+static int
+kdb_str2addr(const char *strp, kdbva_t *addrp, domid_t id)
+{
+    kdbva_t addr;
+    const char *endp;
+
+    /* assume it's an address */
+    KDBGP2("str2addr: str:%s id:%d\n", strp, id);
+    addr = (kdbva_t)simple_strtoul(strp, &endp, 16); /*handles leading 0x */
+    if (endp != strp+strlen(strp))
+        if ( !(addr=kdb_sym2addr(strp, id)) )
+            return 0;
+    *addrp = addr;
+    KDBGP2("str2addr: addr:0x%lx\n", addr);
+    return 1;
+}
+
+/* Given domid, return ptr to struct domain 
+ * IF domid == DOMID_IDLE return ptr to idle_domain 
+ * IF domid == valid domain, return ptr to domain struct
+ * else domid is bad and return NULL
+ */
+static struct domain *
+kdb_domid2ptr(domid_t domid)
+{
+    struct domain *dp;
+
+    /* get_domain_by_id() ret NULL for both DOMID_IDLE and bad domids */
+    if (domid == DOMID_IDLE)
+        dp = idle_vcpu[smp_processor_id()]->domain;
+    else 
+        dp = get_domain_by_id(domid);   /* NULL now means bad domid */
+    return dp;
+}
+
+/*
+ * Returns:  0: failed. invalid domid or string, *idp not changed.
+ */
+static int
+kdb_str2domid(const char *domstr, domid_t *idp, int perr)
+{
+    int id;
+    if (!kdb_str2deci(domstr, &id) || !kdb_domid2ptr((domid_t)id)) {
+        if (perr)
+            kdbp("Invalid domid:%s\n", domstr);
+        return 0;
+    }
+    *idp = (domid_t)id;
+    return 1;
+}
+
+static struct domain *
+kdb_strdomid2ptr(const char *domstr, int perror)
+{
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
+}
+
+/* return a guest bitness: 32 or 64 */
+int
+kdb_guest_bitness(domid_t domid)
+{
+    const int HYPSZ = sizeof(long) * 8;
+    struct domain *dp = kdb_domid2ptr(domid);
+    int retval; 
+
+    if (is_idle_domain(dp))
+        retval = HYPSZ;
+    else if (is_hvm_or_hyb_domain(dp))
+        retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
+    else 
+        retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
+    KDBGP1("gbitness: domid:%d dp:%p bitness:%d\n", domid, dp, retval);
+    return retval;
+}
+
+/* kdb_print_spin_lock(&xyz_lock, "xyz_lock:", "\n"); */
+static void
+kdb_print_spin_lock(char *strp, spinlock_t *lkp, char *nlp)
+{
+    kdbp("%s %04hx %d %d%s", strp, KDB_LKDEF(*lkp), lkp->recurse_cpu,
+         lkp->recurse_cnt, nlp);
+}
+
+/* check if register string is valid. if yes, return offset to the register
+ * in cpu_user_regs, else return -1 */
+static int
+kdb_valid_reg(const char *nmp) 
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (strcmp(kdb_reg_nm_offs[i].reg_nm, nmp) == 0)
+            return kdb_reg_nm_offs[i].reg_offs;
+    return -1;
+}
+
+/* given offset of register, return register name string. if offset is invalid
+ * return NULL */
+static char *kdb_regoffs_to_name(int offs)
+{
+    int i;
+    for (i=0; i < sizeof(kdb_reg_nm_offs)/sizeof(kdb_reg_nm_offs[0]); i++)
+        if (kdb_reg_nm_offs[i].reg_offs == offs)
+            return kdb_reg_nm_offs[i].reg_nm;
+    return NULL;
+}
+
+/* ===================== util struct funcs ================================= */
+static void
+kdb_prnt_timer(struct timer *tp)
+{
+#if XEN_SUBVERSION == 0 
+    kdbp(" expires:%016lx expires_end:%016lx cpu:%d status:%x\n", tp->expires, 
+         tp->expires_end, tp->cpu, tp->status);
+#else
+    kdbp(" expires:%016lx cpu:%d status:%x\n", tp->expires, tp->cpu,tp->status);
+#endif
+    kdbp(" function data:%p ptr:%p ", tp->data, tp->function);
+    kdb_prnt_addr2sym(DOMID_IDLE, (kdbva_t)tp->function, "\n");
+}
+
+static void 
+kdb_prnt_periodic_time(struct periodic_time *ptp)
+{
+    kdbp(" next:%p prev:%p\n", ptp->list.next, ptp->list.prev);
+    kdbp(" on_list:%d one_shot:%d dont_freeze:%d irq_issued:%d src:%x irq:%x\n",
+         ptp->on_list, ptp->one_shot, ptp->do_not_freeze, ptp->irq_issued,
+         ptp->source, ptp->irq);
+    kdbp(" vcpu:%p pending_intr_nr:%08x period:%016lx\n", ptp->vcpu,
+         ptp->pending_intr_nr, ptp->period);
+    kdbp(" scheduled:%016lx last_plt_gtime:%016lx\n", ptp->scheduled,
+         ptp->last_plt_gtime);
+    kdbp(" \n          timer info:\n");
+    kdb_prnt_timer(&ptp->timer);
+    kdbp("\n");
+}
+
+/* ===================== cmd functions  ==================================== */
+
+/*
+ * FUNCTION: Disassemble instructions
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dis(void)
+{
+    kdbp("dis [addr|sym][num][domid] : Disassemble instrs\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dis(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int num = 8;                           /* display 8 instr by default */
+    static kdbva_t addr = BFD_INVAL;
+    static domid_t domid;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dis();
+
+    if (argc != -1)      /* not a command repeat */
+        domid = guest_mode(regs) ?  current->domain->domain_id : DOMID_IDLE;
+
+    if (argc >= 4 && !kdb_str2domid(argv[3], &domid, 1)) { 
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc >= 3 && !kdb_str2deci(argv[2], &num)) {
+        kdbp("kdb:Invalid num\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc > 1 && !kdb_str2addr(argv[1], &addr, domid)) {
+        kdbp("kdb:Invalid addr/sym\n");
+        kdbp("(num has to be specified if providing domid)\n");
+        return KDB_CPU_MAIN_KDB;
+    } 
+    if (argc == 1)                    /* not command repeat */
+        addr = regs->KDBIP;           /* PC is the default */
+    else if (addr == BFD_INVAL) {
+        kdbp("kdb:Invalid addr/sym\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    addr = kdb_print_instr(addr, num, domid);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* FUNCTION: kdb_cmdf_dism() Toggle disassembly syntax from Intel to ATT/GAS */
+static kdb_cpu_cmd_t
+kdb_usgf_dism(void)
+{
+    kdbp("dism: toggle disassembly mode between ATT/GAS and INTEL\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dism(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dism();
+
+    kdb_toggle_dis_syntax();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+_kdb_show_guest_stack(domid_t domid, kdbva_t ipaddr, kdbva_t spaddr)
+{
+    kdbva_t val;
+    int num=0, max=0, rd = kdb_guest_bitness(domid)/8;
+
+    kdb_print_instr(ipaddr, 1, domid);
+    KDBGP("_guest_stack:sp:%lx domid:%d rd:$%d\n", spaddr, domid, rd);
+    val = 0;                          /* must zero, in case guest is 32bit */
+    while((kdb_read_mem(spaddr,(kdbbyt_t *)&val,rd,domid)==rd) && num < 16){
+        KDBGP1("gstk:addr:%lx val:%lx\n", spaddr, val);
+        if (kdb_is_addr_guest_text(val, domid)) {
+            kdb_print_instr(val, 1, domid);
+            num++;
+        }
+        if (max++ > 10000)            /* don't walk down the stack forever */
+            break;                    /* 10k is chosen randomly */
+        spaddr += rd;
+    }
+}
+
+/* Read guest memory and display address that looks like text. */
+static void
+kdb_show_guest_stack(struct cpu_user_regs *regs, struct vcpu *vcpup)
+{
+    kdbva_t ipaddr=regs->KDBIP, spaddr = regs->KDBSP;
+    domid_t domid = vcpup->domain->domain_id;
+
+    ASSERT(domid != DOMID_IDLE);
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+}
+
+/* display stack. if vcpu ptr given, then display stack for that. Otherwise,
+ * use current regs */
+static kdb_cpu_cmd_t
+kdb_usgf_f(void)
+{
+    kdbp("f [vcpu-ptr]: dump current/vcpu stack\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_f(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_f();
+
+    if (argc > 1 ) {
+        struct vcpu *vp;
+        if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp)) {
+            kdbp("kdb: Bad VCPU ptr:%s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdb_show_guest_stack(&vp->arch.user_regs, vp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs))
+        kdb_show_guest_stack(regs, current);
+    else
+        show_trace(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an spaddr and domid for guest, dump stack */
+static kdb_cpu_cmd_t
+kdb_usgf_fg(void)
+{
+    kdbp("fg domid RIP ESP: dump guest stack given domid, RIP, and ESP\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_fg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid;
+    kdbva_t ipaddr, spaddr;
+
+    if (argc != 4) 
+        return kdb_usgf_fg();
+
+    if (kdb_str2domid(argv[1], &domid, 1)==0) {
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[2], &ipaddr)==0) {
+        kdbp("Bad ipaddr:%s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_str2ulong(argv[3], &spaddr)==0) {
+        kdbp("Bad spaddr:%s\n", argv[3]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_show_guest_stack(domid, ipaddr, spaddr);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display kdb stack. for debugging kdb itself */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbf(void)
+{
+    kdbp("kdbf: display kdb stack. for debugging kdb only\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_kdbf(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbf();
+
+    kdb_trap_immed(KDB_TRAP_KDBSTACK);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* worker function to display memory. Request could be for any guest, domid.
+ * Also address could be machine or virtual */
+static void
+_kdb_display_mem(kdbva_t *addrp, int *lenp, int wordsz, int domid, int is_maddr)
+{
+    #define DDBUFSZ 4096
+
+    kdbbyt_t buf[DDBUFSZ], *bp;
+    int numrd, bytes;
+    int len = *lenp;
+    kdbva_t addr = *addrp;
+
+    /* round len down to wordsz boundry because on intel endian, printing
+     * characters is not prudent, (long and ints can't be interpreted 
+     * easily) */
+    len &= ~(wordsz-1);
+    len = KDBMIN(DDBUFSZ, len);
+    len = len ? len : wordsz;
+
+    KDBGP("dmem:addr:%lx buf:%p len:$%d domid:%d sz:$%d maddr:%d\n", addr,
+          buf, len, domid, wordsz, is_maddr);
+    if (is_maddr)
+        numrd=kdb_read_mmem((kdbma_t)addr, buf, len);
+    else
+        numrd=kdb_read_mem(addr, buf, len, domid);
+    if (numrd != len)
+        kdbp("Memory read error. Bytes read:$%d\n", numrd);
+
+    for (bp = buf; numrd > 0;) {
+        kdbp("%016lx: ", addr); 
+
+        /* display 16 bytes per line */
+        for (bytes=0; bytes < 16 && numrd > 0; bytes += wordsz) {
+            if (numrd >= wordsz) {
+                if (wordsz == 8)
+                    kdbp(" %016lx", *(long *)bp);
+                else
+                    kdbp(" %08x", *(int *)bp);
+                bp += wordsz;
+                numrd -= wordsz;
+                addr += wordsz;
+            }
+        }
+        kdbp("\n");
+        continue;
+    }
+    *lenp = len;
+    *addrp = addr;
+}
+
+/* display machine mem, ie, the given address is machine address */
+static kdb_cpu_cmd_t 
+kdb_display_mmem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbma_t maddr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&maddr, &len, wordsz, id, 1);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                                     /* default read len */
+
+    if (!kdb_str2ulong(argv[1], &maddr)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    _kdb_display_mem(&maddr, &len, wordsz, 0, 1);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dwm(void)
+{
+    kdbp("dwm:  maddr|sym [num] : dump memory word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dwm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 4, kdb_usgf_dwm);
+}
+
+/* 
+ * FUNCTION: Dispaly machine Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ddm(void)
+{
+    kdbp("ddm:  maddr|sym [num] : dump double word given machine addr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ddm(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mmem(argc, argv, 8, kdb_usgf_ddm);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory : word or doubleword
+ *           wordsz : bytes in word. 4 or 8
+ *
+ *           We display upto BUFSZ bytes. User can just press enter for more.
+ *           addr is always in hex with or without leading 0x
+ */
+static kdb_cpu_cmd_t 
+kdb_display_mem(int argc, const char **argv, int wordsz, kdb_usgf_t usg_fp)
+{
+    static kdbva_t addr;
+    static int len;
+    static domid_t id = DOMID_IDLE;
+
+    if (argc == -1) {
+        _kdb_display_mem(&addr, &len, wordsz, id, 0);  /* cmd repeat */
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc <= 1 || *argv[1] == '?')
+        return (*usg_fp)();
+
+    id = DOMID_IDLE;                /* not a command repeat, reset dom id */
+    if (argc >= 4) { 
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    /* check if num of bytes to display is given by user */
+    if (argc >= 3) {
+        if (!kdb_str2deci(argv[2], &len)) {
+            kdbp("Invalid length:%s\n", argv[2]);
+            return KDB_CPU_MAIN_KDB;
+        } 
+    } else
+        len = 32;                       /* default read len */
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    _kdb_display_mem(&addr, &len, wordsz, id, 0);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Dispaly Memory Word
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dw(void)
+{
+    kdbp("dw vaddr|sym [num][domid] : dump mem word. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 4, kdb_usgf_dw);
+}
+
+/* 
+ * FUNCTION: Dispaly Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dd(void)
+{
+    kdbp("dd vaddr|sym [num][domid] : dump dword. num required for domid\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dd(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return kdb_display_mem(argc, argv, 8, kdb_usgf_dd);
+}
+
+/* 
+ * FUNCTION: Modify Memory Word 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mw(void)
+{
+    kdbp("mw vaddr|sym val [domid] : modify memory word in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mw(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_mw();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) 
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val, 4, id) != 4)
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Memory DoubleWord 
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_md(void)
+{
+    kdbp("md vaddr|sym val [domid] : modify memory dword in vaddr\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_md(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong val;
+    kdbva_t addr;
+    domid_t id = DOMID_IDLE;
+
+    if (argc < 3) {
+        return kdb_usgf_md();
+    }
+    if (argc >=4) {
+        if (!kdb_str2domid(argv[3], &id, 1)) {
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    if (!kdb_str2ulong(argv[2], &val)) {
+        kdbp("Invalid val: %s\n", argv[2]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, id)) {
+        kdbp("Invalid addr/sym: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_write_mem(addr, (kdbbyt_t *)&val,sizeof(val),id) != sizeof(val))
+        kdbp("Unable to set 0x%lx to 0x%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct  Xgt_desc_struct {
+    unsigned short size;
+    unsigned long address __attribute__((packed));
+};
+
+void
+kdb_show_special_regs(struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    unsigned short tr;                 /* Task Register segment selector */
+    __u64 efer;
+
+    kdbp("\nSpecial Registers:\n");
+    __asm__ __volatile__ ("sidt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("IDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+    __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+    kdbp("GDTR: addr: %016lx limit: %04x\n", desc.address, desc.size);
+
+    kdbp("cr0: %016lx  cr2: %016lx\n", read_cr0(), read_cr2());
+    kdbp("cr3: %016lx  cr4: %016lx\n", read_cr3(), read_cr4());
+    __asm__ __volatile__ ("str (%0) \n":: "a"(&tr) : "memory");
+    kdbp("TR: %x\n", tr);
+
+    rdmsrl(MSR_EFER, efer);    /* IA32_EFER */
+    kdbp("efer:"KDBF64" LMA(IA-32e mode):%d SCE(syscall/sysret):%d\n",
+         efer, ((efer&EFER_LMA) != 0), ((efer&EFER_SCE) != 0));
+
+    kdbp("DR0: %016lx  DR1:%016lx  DR2:%016lx\n", kdb_rd_dbgreg(0),
+         kdb_rd_dbgreg(1), kdb_rd_dbgreg(2)); 
+    kdbp("DR3: %016lx  DR6:%016lx  DR7:%016lx\n", kdb_rd_dbgreg(3),
+         kdb_rd_dbgreg(6), kdb_rd_dbgreg(7)); 
+}
+
+/* 
+ * FUNCTION: Dispaly Registers. If "sp" argument, then display additional regs
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dr(void)
+{
+    kdbp("dr [sp]: display registers. sp to display special regs also\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dr();
+
+    KDBGP1("regs:%p .rsp:%lx .rip:%lx\n", regs, regs->rsp, regs->rip);
+    show_registers(regs);
+    if (argc > 1 && !strcmp(argv[1], "sp")) 
+        kdb_show_special_regs(regs);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* show registers on stack bottom where guest context is. same as dr if
+ * not running in guest mode */
+static kdb_cpu_cmd_t
+kdb_usgf_drg(void)
+{
+    kdbp("drg: display active guest registers at stack bottom\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_drg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_drg();
+
+    kdbp("\tNote: ds/es/fs/gs etc.. are not saved from the cpu\n");
+    kdb_print_uregs(guest_cpu_user_regs());
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Modify Register
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_mr(void)
+{
+    kdbp("mr reg val : Modify Register. val assumed in hex\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_mr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int regoffs;
+    ulong val;
+
+    if (argc != 3 || !kdb_str2ulong(argv[2], &val)) {
+        return kdb_usgf_mr();
+    }
+    argp = argv[1];
+
+#if defined(__x86_64__)
+    if ((regoffs=kdb_valid_reg(argp)) != -1)
+        *((uint64_t *)((char *)regs+regoffs)) = val;
+#else
+    if (!strcmp(argp, "eax"))
+        regs->eax = val;
+    else if (!strcmp(argp, "ebx"))
+        regs->ebx = val;
+    else if (!strcmp(argp, "ecx"))
+        regs->ecx = val;
+    else if (!strcmp(argp, "edx"))
+        regs->edx = val;
+    else if (!strcmp(argp, "esi"))
+        regs->esi = val;
+    else if (!strcmp(argp, "edi"))
+        regs->edi = val;
+    else if (!strcmp(argp, "ebp"))
+        regs->ebp = val;
+    else if (!strcmp(argp, "esp"))
+        regs->esp = val;
+    else if (!strcmp(argp, "eflags") || !strcmp(argp, "rflags"))
+        regs->eflags = val;
+#endif
+    else
+        kdbp("Error. Bad register : %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * FUNCTION: Single Step
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ss(void)
+{
+    kdbp("ss: single step\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ss(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    #define KDB_HALT_INSTR 0xf4
+
+    kdbbyt_t byte;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ss();
+
+    KDBGP("enter kdb_cmdf_ss \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (kdb_read_mem(regs->KDBIP, &byte, 1, id) == 1) {
+        if (byte == KDB_HALT_INSTR) {
+            kdbp("kdb: jumping over halt instruction\n");
+            regs->KDBIP++;
+        }
+    } else {
+        kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
+        current->arch.hvm_vcpu.single_step = 1;
+    } else
+        regs->eflags |= X86_EFLAGS_TF;
+
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Next Instruction, step over the call instr to the next instr
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ni(void)
+{
+    kdbp("ni: single step, stepping over function calls\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ni(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int sz, i;
+    domid_t id=guest_mode(regs) ? current->domain->domain_id:DOMID_IDLE;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ni();
+
+    KDBGP("enter kdb_cmdf_ni \n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if ((sz=kdb_check_call_instr(id, regs->KDBIP)) == 0)  /* !call instr */
+        return kdb_cmdf_ss(argc, argv, regs);         /* just do ss */
+
+    if ((i=kdb_set_bp(id, regs->KDBIP+sz, 1,0,0,0,0)) >= KDBMAXSBP) /* failed */
+        return KDB_CPU_MAIN_KDB;
+
+    kdb_sbpa[i].bp_ni = 1;
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+        current->arch.hvm_vcpu.single_step = 0;
+    else
+        regs->eflags &= ~X86_EFLAGS_TF;
+
+    return KDB_CPU_NI;
+}
+
+static void
+kdb_btf_enable(void)
+{
+    u64 debugctl;
+    rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 0x2);
+}
+
+/* 
+ * FUNCTION: Single Step to branch. Doesn't seem to work very well.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_ssb(void)
+{
+    kdbp("ssb: singe step to branch\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_ssb(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_ssb();
+
+    KDBGP("MUK: enter kdb_cmdf_ssb\n");
+    if (!regs) {
+        kdbp("%s: regs not available\n", __FUNCTION__);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (is_hvm_or_hyb_vcpu(current)) 
+        current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
+
+    regs->eflags |= X86_EFLAGS_TF;
+    kdb_btf_enable();
+    return KDB_CPU_SS;
+}
+
+/* 
+ * FUNCTION: Continue Execution. TF must be cleared here as this could run on 
+ *           any cpu. Hence not OK to do it from kdb_end_session.
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_go(void)
+{
+    kdbp("go: leave kdb and continue execution\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_go(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_go();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    return KDB_CPU_GO;
+}
+
+/* All cpus must display their current context */
+static kdb_cpu_cmd_t 
+kdb_cpu_status_all(int ccpu, struct cpu_user_regs *regs)
+{
+    int cpu;
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)   /* hung cpu */
+                continue;
+            kdb_cpu_cmd[cpu] = KDB_CPU_SHOWPC;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_SHOWPC);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * display/switch CPU. 
+ *  Argument:
+ *     none:   just go back to initial cpu
+ *     cpunum: switch to given vpu
+ *     "all":  show one line status of all cpus
+ */
+extern volatile int kdb_init_cpu;
+static kdb_cpu_cmd_t
+kdb_usgf_cpu(void)
+{
+    kdbp("cpu [all|num]: none will switch back to initial cpu\n");
+    kdbp("               cpunum to switch to the vcpu. all to show status\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_cpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+    int ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cpu();
+
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all"))
+            return kdb_cpu_status_all(ccpu, regs);
+
+            cpu = (int)simple_strtoul(argv[1], NULL, 0); /* handles 0x */
+            if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && 
+                cpu_online(cpu) && kdb_cpu_cmd[cpu] == KDB_CPU_PAUSE)
+            {
+                kdbp("Switching to cpu:%d\n", cpu);
+                kdb_cpu_cmd[cpu] = KDB_CPU_MAIN_KDB;
+
+                /* clear any single step on the current cpu */
+                regs->eflags &= ~X86_EFLAGS_TF;
+                return KDB_CPU_PAUSE;
+            } else {
+                if (cpu != ccpu)
+                    kdbp("Unable to switch to cpu:%d\n", cpu);
+                else {
+                    kdb_display_pc(regs);
+                }
+                return KDB_CPU_MAIN_KDB;
+            }
+    }
+    /* no arg means back to initial cpu */
+    if (!kdb_sys_crash && ccpu != kdb_init_cpu) {
+        if (kdb_cpu_cmd[kdb_init_cpu] == KDB_CPU_PAUSE) {
+            regs->eflags &= ~X86_EFLAGS_TF;
+            kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_MAIN_KDB;
+            return KDB_CPU_PAUSE;
+        } else
+            kdbp("Unable to switch to: %d\n", kdb_init_cpu);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* send NMI to all or given CPU. Must be crashed/fatal state */
+static kdb_cpu_cmd_t
+kdb_usgf_nmi(void)
+{
+    kdbp("nmi cpu#|all: send nmi cpu/s. must reboot when done with kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_nmi(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    cpumask_t cpumask;
+    int ccpu = smp_processor_id();
+
+    if (argc <= 1 || (argc > 1 && *argv[1] == '?'))
+        return kdb_usgf_nmi();
+
+    if (!kdb_sys_crash) {
+        kdbp("kdb: nmi cmd available in crashed state only\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!strcmp(argv[1], "all"))
+        cpumask = cpu_online_map;
+    else {
+        int cpu = (int)simple_strtoul(argv[1], NULL, 0);
+        if (cpu >= 0 && cpu < NR_CPUS && cpu != ccpu && cpu_online(cpu))
+            cpumask = *cpumask_of(cpu);
+        else {
+            kdbp("KDB nmi: invalid cpu %s\n", argv[1]);
+            return KDB_CPU_MAIN_KDB;
+        }
+    }
+    kdb_nmi_pause_cpus(cpumask);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_percpu(void)
+{
+    kdbp("percpu: display per cpu pointers\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_percpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_percpu();
+    kdb_dump_time_pcpu();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ========================= Breakpoints ==================================== */
+
+static void
+kdb_prnt_bp_cond(int bpnum)
+{
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {
+        kdbp("     ( %s %c%c %lx )\n", 
+             kdb_regoffs_to_name(bpcp->bp_cond_lhs),
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    } else {
+        kdbp("     ( %lx %c%c %lx )\n", bpcp->bp_cond_lhs,
+             bpcp->bp_cond_type == 1 ? '=' : '!', '=', bpcp->bp_cond_rhs);
+    }
+}
+
+static void
+kdb_prnt_bp_extra(int bpnum)
+{
+    if (kdb_sbpa[bpnum].bp_type == 2) {
+        ulong i, arg, *btp = kdb_sbpa[bpnum].u.bp_btp;
+        
+        kdbp("   will trace ");
+        for (i=0; i < KDB_MAXBTP && btp[i]; i++)
+            if ((arg=btp[i]) < sizeof (struct cpu_user_regs)) {
+                kdbp(" %s ", kdb_regoffs_to_name(arg));
+            } else {
+                kdbp(" %lx ", arg);
+            }
+        kdbp("\n");
+
+    } else if (kdb_sbpa[bpnum].bp_type == 1)
+        kdb_prnt_bp_cond(bpnum);
+}
+
+/*
+ * List software breakpoints
+ */
+static kdb_cpu_cmd_t
+kdb_display_sbkpts(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted) {
+            struct domain *dp = kdb_domid2ptr(kdb_sbpa[i].bp_domid);
+
+            if (dp == NULL || dp->is_dying) {
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                continue;
+            }
+            kdbp("[%d]: domid:%d 0x%lx   ", i, 
+                 kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr);
+            kdb_prnt_addr2sym(kdb_sbpa[i].bp_domid, kdb_sbpa[i].bp_addr,"\n");
+            kdb_prnt_bp_extra(i);
+        }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Check if any breakpoints that we need to install (delayed install)
+ * Returns: 1 if yes, 0 if none.
+ */
+int
+kdb_swbp_exists(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && !kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+/*
+ * Check if any breakpoints were deleted this kdb session
+ * Returns: 0 if none, 1 if yes
+ */
+static int
+kdb_swbp_deleted(void)
+{
+    int i;
+    for (i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted)
+            return 1;
+    return 0;
+}
+
+/*
+ * Flush deleted sw breakpoints
+ */
+void
+kdb_flush_swbp_table(void)
+{
+    int i;
+    KDBGP("ccpu:%d flush_swbp_table: deleted:%x\n", smp_processor_id(), 
+          kdb_swbp_deleted());
+    for(i=0; i < KDBMAXSBP; i++)
+        if (kdb_sbpa[i].bp_addr && kdb_sbpa[i].bp_deleted) {
+            KDBGP("flush:[%x] addr:0x%lx\n",i,kdb_sbpa[i].bp_addr);
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        }
+}
+
+/*
+ * Delete/Clear a sw breakpoint
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bc(void)
+{
+    kdbp("bc $num|all : clear given or all breakpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, bpnum = -1, delall = 0;
+    const char *argp;
+
+    if (argc != 2 || *argv[1] == '?')
+        return kdb_usgf_bc();
+
+    if (!kdb_swbp_exists()) {
+        kdbp("No breakpoints are set\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        delall = 1;
+    else if (!kdb_str2deci(argp, &bpnum) || bpnum < 0 || bpnum > KDBMAXSBP) {
+        kdbp("Invalid bpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (delall && kdb_sbpa[i].bp_addr) {
+            kdbp("Deleted breakpoint [%x] addr:0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            continue;
+        }
+        if (bpnum != -1 && bpnum == i) {
+            kdbp("Deleted breakpoint [%x] at 0x%lx domid:%d\n", 
+                 (int)i, kdb_sbpa[i].bp_addr, kdb_sbpa[i].bp_domid);
+            if (kdb_sbpa[i].bp_just_added)
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            else
+                kdb_sbpa[i].bp_deleted = 1;
+            break;
+        }
+    }
+    if (i >= KDBMAXSBP && !delall)
+        kdbp("Unable to delete breakpoint: %s\n", argp);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Install a breakpoint in the given array entry
+ * Returns: 0 : failed to install
+ *          1 : installed successfully
+ */
+static int
+kdb_install_swbp(int idx)                   /* which entry in the bp array */
+{
+    kdbva_t addr = kdb_sbpa[idx].bp_addr;
+    domid_t domid = kdb_sbpa[idx].bp_domid;
+    kdbbyt_t *p = &kdb_sbpa[idx].bp_originst;
+    struct domain *dp = kdb_domid2ptr(domid);
+
+    if (dp == NULL || dp->is_dying) {
+        memset(&kdb_sbpa[idx], 0, sizeof(kdb_sbpa[idx]));
+        kdbp("Removed bp %d addr:%p domid:%d\n", idx, addr, domid);
+        return 0;
+    }
+
+    if (kdb_read_mem(addr, p, KDBBPSZ, domid) != KDBBPSZ){
+        kdbp("Failed(R) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    if (kdb_write_mem(addr, &kdb_bpinst, KDBBPSZ, domid) != KDBBPSZ) {
+        kdbp("Failed(W) to install bp:%x at:0x%lx domid:%d\n",
+             idx, kdb_sbpa[idx].bp_addr, domid);
+        return 0;
+    }
+    KDBGP("install_swbp: installed bp:%x at:0x%lx ccpu:%x domid:%d\n",
+          idx, kdb_sbpa[idx].bp_addr, smp_processor_id(), domid);
+    return 1;
+}
+
+/*
+ * Install all the software breakpoints
+ */
+void
+kdb_install_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_deleted && kdb_sbpa[i].bp_addr)
+            kdb_install_swbp(i);
+}
+
+static void
+kdb_uninstall_a_swbp(int i)
+{
+    kdbva_t addr = kdb_sbpa[i].bp_addr;
+    kdbbyt_t originst = kdb_sbpa[i].bp_originst;
+    domid_t id = kdb_sbpa[i].bp_domid;
+
+    kdb_sbpa[i].bp_just_added = 0;
+    if (!addr)
+        return;
+    if (kdb_write_mem(addr, &originst, KDBBPSZ, id) != KDBBPSZ) {
+        kdbp("Failed to uninstall breakpoint %x at:0x%lx domid:%d\n",
+             i, kdb_sbpa[i].bp_addr, id);
+    }
+}
+
+/*
+ * Uninstall all the software breakpoints at beginning of kdb session
+ */
+void
+kdb_uninstall_all_swbp(void)
+{
+    int i;
+    for(i=0; i < KDBMAXSBP; i++) 
+        kdb_uninstall_a_swbp(i);
+    KDBGP("ccpu:%d uninstalled all bps\n", smp_processor_id());
+}
+
+/* RETURNS: rc == 2: condition was not met,  rc == 3: condition was met */
+static int
+kdb_check_bp_condition(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong res = 0, lhsval=0;
+    struct kdb_bpcond *bpcp = &kdb_sbpa[bpnum].u.bp_cond;
+
+    if (bpcp->bp_cond_status == 1) {             /* register condition */
+        uint64_t *rp = (uint64_t *)((char *)regs + bpcp->bp_cond_lhs);
+        lhsval = *rp;
+    } else if (bpcp->bp_cond_status == 2) {      /* memaddr condition */
+        ulong addr = bpcp->bp_cond_lhs;
+        int num = sizeof(lhsval);
+
+        if (kdb_read_mem(addr, (kdbbyt_t *)&lhsval, num, domid) != num) {
+            kdbp("kdb: unable to read %d bytes at %lx\n", num, addr);
+            return 3;
+        }
+    }
+    if (bpcp->bp_cond_type == 1)                 /* lhs == rhs */
+        res = (lhsval == bpcp->bp_cond_rhs);
+    else                                         /* lhs != rhs */
+        res = (lhsval != bpcp->bp_cond_rhs);
+
+    if (!res)
+        kdbp("KDB: [%d]Ignoring bp:%d condition not met. val:%lx\n", 
+              smp_processor_id(), bpnum, lhsval); 
+
+    KDBGP1("bpnum:%d domid:%d cond: %d %d %lx %lx res:%d\n", bpnum, domid, 
+           bpcp->bp_cond_status, bpcp->bp_cond_type, bpcp->bp_cond_lhs, 
+           bpcp->bp_cond_rhs, res);
+
+    return (res ? 3 : 2);
+}
+
+static void
+kdb_prnt_btp_info(int bpnum, struct cpu_user_regs *regs, domid_t domid)
+{
+    ulong i, arg, val, num, *btp = kdb_sbpa[bpnum].u.bp_btp;
+
+    kdb_prnt_addr2sym(domid, regs->KDBIP, "\n");
+    num = kdb_guest_bitness(domid)/8;
+    for (i=0; i < KDB_MAXBTP && (arg=btp[i]); i++) {
+        if (arg < sizeof (struct cpu_user_regs)) {
+            uint64_t *rp = (uint64_t *)((char *)regs + arg);
+            kdbp(" %s: %016lx ", kdb_regoffs_to_name(arg), *rp);
+        } else {
+            if (kdb_read_mem(arg, (kdbbyt_t *)&val, num, domid) != num)
+                kdbp("kdb: unable to read %d bytes at %lx\n", num, arg);
+            if (num == 8)
+                kdbp(" %016lx:%016lx ", arg, val);
+            else
+                kdbp(" %08lx:%08lx ", arg, val);
+        }
+    }
+    kdbp("\n");
+    KDBGP1("bpnum:%d domid:%d btp:%p num:%d\n", bpnum, domid, btp, num);
+}
+
+/*
+ * Check if the BP trap belongs to us. 
+ * Return: 0 : not one of ours. IP not changed. (leave kdb)
+ *         1 : one of ours but deleted. IP decremented. (leave kdb)
+ *         2 : one of ours but condition not met, or btp. IP decremented.(leave)
+ *         3 : one of ours and active. IP decremented. (stay in kdb)
+ */
+int 
+kdb_check_sw_bkpts(struct cpu_user_regs *regs)
+{
+    int i, rc=0;
+    domid_t curid;
+
+    curid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    for(i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_domid == curid  && 
+            kdb_sbpa[i].bp_addr == (regs->KDBIP- KDBBPSZ)) {
+
+            regs->KDBIP -= KDBBPSZ;
+            rc = 3;
+
+            if (kdb_sbpa[i].bp_ni) {
+                kdb_uninstall_a_swbp(i);
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+            } else if (kdb_sbpa[i].bp_deleted) {
+                rc = 1;
+            } else if (kdb_sbpa[i].bp_type == 1) {
+                rc = kdb_check_bp_condition(i, regs, curid);
+            } else if (kdb_sbpa[i].bp_type == 2) {
+                kdb_prnt_btp_info(i, regs, curid);
+                rc = 2;
+            }
+            KDBGP1("ccpu:%d rc:%d curid:%d domid:%d addr:%lx\n", 
+                   smp_processor_id(), rc, curid, kdb_sbpa[i].bp_domid, 
+                   kdb_sbpa[i].bp_addr);
+            break;
+        }
+    }
+    return (rc);
+}
+
+/* Eg: r6 == 0x123EDF  or 0xFFFF2034 != 0xDEADBEEF
+ * regoffs: -1 means lhs is not reg. else offset of reg in cpu_user_regs
+ * addr: memory location if lhs is not register, eg, 0xFFFF2034
+ * condp : points to != or ==
+ * rhsval : right hand side value
+ */
+static void
+kdb_set_bp_cond(int bpnum, int regoffs, ulong addr, char *condp, ulong rhsval)
+{
+    if (bpnum >= KDBMAXSBP) {
+        kdbp("BUG: %s got invalid bpnum\n", __FUNCTION__);
+        return;
+    }
+    if (regoffs != -1) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 1;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = regoffs;
+    } else if (addr != 0) {
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_status = 2;
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_lhs = addr;
+    } else {
+        kdbp("error: invalid call to kdb_set_bp_cond\n");
+        return;
+    }
+    kdb_sbpa[bpnum].u.bp_cond.bp_cond_rhs = rhsval;
+
+    if (*condp == '!')
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 2;
+    else
+        kdb_sbpa[bpnum].u.bp_cond.bp_cond_type = 1;
+}
+
+/* install breakpt at given addr. 
+ * ni: bp for next instr 
+ * btpa: ptr to args for btp for printing when bp is hit
+ * lhsp/condp/rhsp: point to strings of condition
+ *
+ * RETURNS: the index in array where installed. KDBMAXSBP if error 
+ */
+static int
+kdb_set_bp(domid_t domid, kdbva_t addr, int ni, ulong *btpa, char *lhsp, 
+           char *condp, char *rhsp)
+{
+    int i, pre_existing = 0, regoffs = -1;
+    ulong memloc=0, rhsval=0, tmpul;
+
+    if (btpa && (lhsp || rhsp || condp)) {
+        kdbp("internal error. btpa and (lhsp || rhsp || condp) set\n");
+        return KDBMAXSBP;
+    }
+    if (lhsp && ((regoffs=kdb_valid_reg(lhsp)) == -1)  &&
+        kdb_str2ulong(lhsp, &memloc) &&
+        kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0) {
+
+        kdbp("error: invalid argument: %s\n", lhsp);
+        return KDBMAXSBP;
+    }
+    if (rhsp && ! kdb_str2ulong(rhsp, &rhsval)) {
+        kdbp("error: invalid argument: %s\n", rhsp);
+        return KDBMAXSBP;
+    }
+
+    /* see if bp already set */
+    for (i=0; i < KDBMAXSBP; i++) {
+        if (kdb_sbpa[i].bp_addr==addr && kdb_sbpa[i].bp_domid==domid) {
+
+            if (kdb_sbpa[i].bp_deleted) {
+                /* just re-set this bp again */
+                memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+                pre_existing = 1;
+            } else {
+                kdbp("Breakpoint already set \n");
+                return KDBMAXSBP;
+            }
+        }
+    }
+    /* see if any room left for another breakpoint */
+    for (i=0; i < KDBMAXSBP; i++)
+        if (!kdb_sbpa[i].bp_addr)
+            break;
+    if (i >= KDBMAXSBP) {
+        kdbp("ERROR: Breakpoint table full....\n");
+        return i;
+    }
+    kdb_sbpa[i].bp_addr = addr;
+    kdb_sbpa[i].bp_domid = domid;
+    if (btpa) {
+        kdb_sbpa[i].bp_type = 2;
+        kdb_sbpa[i].u.bp_btp = btpa;
+    } else if (regoffs != -1 || memloc) {
+        kdb_sbpa[i].bp_type = 1;
+        kdb_set_bp_cond(i, regoffs, memloc, condp, rhsval);
+    } else
+        kdb_sbpa[i].bp_type = 0;
+
+    if (kdb_install_swbp(i)) {                  /* make sure it can be done */
+        if (ni)
+            return i;
+
+        kdb_uninstall_a_swbp(i);                /* dont' show user INT3 */
+        if (!pre_existing)               /* make sure no is cpu sitting on it */
+            kdb_sbpa[i].bp_just_added = 1;
+
+        kdbp("bp %d set for domid:%d at: 0x%lx ", i, kdb_sbpa[i].bp_domid, 
+             kdb_sbpa[i].bp_addr);
+        kdb_prnt_addr2sym(domid, addr, "\n");
+        kdb_prnt_bp_extra(i);
+    } else {
+        kdbp("ERROR:Can't install bp: 0x%lx domid:%d\n", addr, domid);
+        if (pre_existing)     /* in case a cpu is sitting on this bp in traps */
+            kdb_sbpa[i].bp_deleted = 1;
+        else
+            memset(&kdb_sbpa[i], 0, sizeof(kdb_sbpa[i]));
+        return KDBMAXSBP;
+    }
+    /* make sure swbp reporting is enabled in the vmcb/vmcs */
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        struct domain *dp = kdb_domid2ptr(domid);
+        dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
+        KDBGP("debugger_attached set. domid:%d\n", domid);
+    }
+    return i;
+}
+
+/* 
+ * Set/List Software Breakpoint/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_bp(void)
+{
+    kdbp("bp [addr|sym][domid][condition]: display or set a breakpoint\n");
+    kdbp("  where cond is like: r6 == 0x123F or rax != DEADBEEF or \n");
+    kdbp("       ffff82c48038fe58 == 321E or 0xffff82c48038fe58 != 0\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9");
+    kdbp(" r10 r11 r12 r13 r14 r15 rflags\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_bp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    int idx = -1;
+    domid_t domid = DOMID_IDLE;
+    char *domidstrp, *lhsp=NULL, *condp=NULL, *rhsp=NULL;
+
+    if ((argc > 1 && *argv[1] == '?') || argc == 4 || argc > 6)
+        return kdb_usgf_bp();
+
+    if (argc < 2 || kdb_sys_crash)         /* list all set breakpoints */
+        return kdb_display_sbkpts();
+
+    /* valid argc either: 2 3 5 or 6 
+     * 'bp idle_loop r6 == 0xc000' OR 'bp idle_loop 3 r9 != 0xdeadbeef' */
+    idx = (argc == 5) ? 2 : ((argc == 6) ? 3 : idx);
+    if (argc >= 5 ) {
+        lhsp = (char *)argv[idx];
+        condp = (char *)argv[idx+1];
+        rhsp = (char *)argv[idx+2];
+
+        if (!kdb_str2ulong(rhsp, NULL) || *(condp+1) != '=' || 
+            (*condp != '=' && *condp != '!')) {
+
+            return kdb_usgf_bp();
+        }
+    }
+    domidstrp = (argc == 3 || argc == 6 ) ? (char *)argv[2] : NULL;
+    if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
+        return kdb_usgf_bp();
+    }
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+        kdbp("HVM domain not supported yet for conditional bp\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    /* make sure xen addr is in xen text, otherwise bp set in 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_set_bp(domid, addr, 0, NULL, lhsp, condp, rhsp);     /* 0 is ni flag */
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* trace breakpoint, meaning, upon bp trace/print some info and continue */
+
+static kdb_cpu_cmd_t
+kdb_usgf_btp(void)
+{
+    kdbp("btp addr|sym [domid] reg|domid-mem-addr... : breakpoint trace\n");
+    kdbp("  regs: rax rbx rcx rdx rsi rdi rbp rsp r8 r9 ");
+    kdbp("r10 r11 r12 r13 r14 r15 rflags\n");
+    kdbp("  Eg. btp idle_cpu 7 rax rbx 0x20ef5a5 r9\n");
+    kdbp("      will print rax, rbx, *(long *)0x20ef5a5, r9 and continue\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_btp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i, btpidx, numrd, argsidx, regoffs = -1;
+    kdbva_t addr, memloc=0;
+    domid_t domid = DOMID_IDLE;
+    ulong *btpa, tmpul;
+
+    if ((argc > 1 && *argv[1] == '?') || argc < 3)
+        return kdb_usgf_btp();
+
+    argsidx = 2;                   /* assume 3rd arg is not domid */
+    if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
+
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
+            kdbp("HVM domains are not currently supprted\n");
+            return KDB_CPU_MAIN_KDB;
+        } else
+            argsidx = 3;               /* 3rd arg is a domid */
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    /* make sure xen addr is in xen text, otherwise will trace 64bit dom0/U */
+    if (domid == DOMID_IDLE && 
+        (addr < XEN_VIRT_START || addr > XEN_VIRT_END))
+    {
+        kdbp("addr:%lx not in  xen text\n", addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    numrd = kdb_guest_bitness(domid)/8;
+    if (kdb_read_mem(addr, (kdbbyt_t *)&tmpul, numrd, domid) != numrd) {
+        kdbp("Unable to read mem from %s (%lx)\n", argv[1], addr);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    for (btpidx=0; btpidx < KDBMAXSBP && kdb_btp_ap[btpidx]; btpidx++);
+    if (btpidx >= KDBMAXSBP) {
+        kdbp("error: table full. delete few breakpoints\n");
+        return KDB_CPU_MAIN_KDB;
+    }
+    btpa = kdb_btp_argsa[btpidx];
+    memset(btpa, 0, sizeof(kdb_btp_argsa[0]));
+
+    for (i=0; argv[argsidx]; i++, argsidx++) {
+
+        if (((regoffs=kdb_valid_reg(argv[argsidx])) == -1)  &&
+            kdb_str2ulong(argv[argsidx], &memloc) &&
+            (memloc < sizeof (struct cpu_user_regs) ||
+            kdb_read_mem(memloc, (kdbbyt_t *)&tmpul, sizeof(tmpul), domid)==0)){
+
+            kdbp("error: invalid argument: %s\n", argv[argsidx]);
+            return KDB_CPU_MAIN_KDB;
+        }
+        if (i >= KDB_MAXBTP) {
+            kdbp("error: cannot specify more than %d args\n", KDB_MAXBTP);
+            return KDB_CPU_MAIN_KDB;
+        }
+        btpa[i] = (regoffs == -1) ? memloc : regoffs;
+    }
+
+    i = kdb_set_bp(domid, addr, 0, btpa, 0, 0, 0);     /* 0 is ni flag */
+    if (i < KDBMAXSBP)
+        kdb_btp_ap[btpidx] = kdb_btp_argsa[btpidx];
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* 
+ * Set/List watchpoints, ie, hardware breakpoint/s, in hypervisor
+ *   Usage: wp [sym|addr] [w|i]   w == write only data watchpoint
+ *                                i == IO watchpoint (read/write)
+ *
+ *   Eg:  wp        : list all watchpoints set
+ *        wp addr   : set a read/write wp at given addr
+ *        wp addr w : set a write only wp at given addr
+ *        wp addr i : set an IO wp at given addr (16bits port #)
+ *
+ *  TBD: allow to be set on particular cpu
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_wp(void)
+{
+    kdbp("wp [addr|sym][w|i]: display or set watchpoint. writeonly or IO\n");
+    kdbp("\tnote: watchpoint is triggered after the instruction executes\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbva_t addr;
+    domid_t domid = DOMID_IDLE;
+    int rw = 3, len = 4;       /* for now just default to 4 bytes len */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_wp();
+
+    if (argc <= 1 || kdb_sys_crash) {       /* list all set watchpoints */
+        kdb_do_watchpoints(0, 0, 0);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (!kdb_str2addr(argv[1], &addr, domid) || addr == 0) {
+        kdbp("Invalid argument:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2) {
+        if (!strcmp(argv[2], "w"))
+            rw = 1;
+        else if (!strcmp(argv[2], "i"))
+            rw = 2;
+        else {
+            return kdb_usgf_wp();
+        }
+    }
+    kdb_do_watchpoints(addr, rw, len);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_wc(void)
+{
+    kdbp("wc $num|all : clear given or all watchpoints\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_wc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    const char *argp;
+    int wpnum;              /* wp num to delete. -1 for all */
+
+    if (argc != 2 || *argv[1] == '?') 
+        return kdb_usgf_wc();
+
+    argp = argv[1];
+
+    if (!strcmp(argp, "all"))
+        wpnum = -1;
+    else if (!kdb_str2deci(argp, &wpnum)) {
+        kdbp("Invalid wpnum: %s\n", argp);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdb_clear_wps(wpnum);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display struct hvm_vcpu{} in struct vcpu.arch{} */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpuh(void)
+{
+    kdbp("vcpuh vcpu-ptr : display hvm_vcpu struct\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpuh(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *vp;
+    struct hvm_vcpu *hvp;
+    struct hvm_io_op *ioop;
+    struct vlapic *vlp;
+
+    if (argc < 2 || *argv[1] == '?') 
+        return kdb_usgf_vcpuh();
+
+    if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
+        !is_hvm_or_hyb_vcpu(vp)) {
+
+        kdbp("kdb: Bad VCPU: %s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+
+    hvp = &vp->arch.hvm_vcpu;
+    vlp = &hvp->vlapic;
+    kdbp("vcpu:%lx id:%d domid:%d\n", vp, vp->vcpu_id, vp->domain->domain_id);
+
+    ioop = NULL;   /* compiler warning */
+    kdbp("&hvm_vcpu:%lx  guest_efer:"KDBFL"\n", hvp, hvp->guest_efer);
+    kdbp("  guest_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->guest_cr[0],
+         hvp->guest_cr[1],hvp->guest_cr[2]);
+    kdbp("            [3]:"KDBFL" [4]:"KDBFL"\n", hvp->guest_cr[3],
+         hvp->guest_cr[4]);
+    kdbp("  hw_cr: [0]:"KDBFL" [1]:"KDBFL" [2]:"KDBFL"\n", hvp->hw_cr[0],
+         hvp->hw_cr[1], hvp->hw_cr[2]);
+    kdbp("          [3]:"KDBFL" [4]:"KDBFL"\n", hvp->hw_cr[3], hvp->hw_cr[4]);
+
+    kdbp("  VLAPIC: base msr:"KDBF64" dis:%x tmrdiv:%x\n", 
+         vlp->hw.apic_base_msr, vlp->hw.disabled, vlp->hw.timer_divisor);
+    kdbp("          regs:%p regs_page:%p\n", vlp->regs, vlp->regs_page);
+    kdbp("          periodic time:\n"); 
+    kdb_prnt_periodic_time(&vlp->pt);
+
+    kdbp("  xen_port:%x flag_dr_dirty:%x dbg_st_latch:%x\n", hvp->xen_port,
+         hvp->flag_dr_dirty, hvp->debug_state_latch);
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+
+        struct arch_vmx_struct *vxp = &hvp->u.vmx;
+        kdbp("  &vmx: %p vmcs:%lx active_cpu:%x launched:%x\n", vxp, vxp->vmcs, 
+             vxp->active_cpu, vxp->launched);
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("    exec_ctrl:%x vpid:$%d\n", vxp->exec_control, vxp->vpid);
+#endif
+        kdbp("    host_cr0: "KDBFL" vmx: {realm:%x emulate:%x}\n",
+             vxp->host_cr0, vxp->vmx_realmode, vxp->vmx_emulate);
+
+#ifdef __x86_64__
+        kdbp("    &msr_state:%p\n", &vxp->msr_state);
+#endif
+    } else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+        struct arch_svm_struct *svp = &hvp->u.svm;
+#if XEN_VERSION != 4               /* xen 3.x.x */
+        kdbp("  &svm: vmcb:%lx pa:"KDBF64" asid:"KDBF64"\n", svp, svp->vmcb,
+             svp->vmcb_pa, svp->asid_generation);
+#endif
+        kdbp("    msrpm:%p lnch_core:%x vmcb_sync:%x\n", svp->msrpm, 
+             svp->launch_core, svp->vmcb_in_sync);
+    }
+    kdbp("  cachemode:%x io: {state: %x data: "KDBFL"}\n", hvp->cache_mode,
+         hvp->hvm_io.io_state, hvp->hvm_io.io_data);
+    kdbp("  mmio: {gva: "KDBFL" gpfn: "KDBFL"}\n", hvp->hvm_io.mmio_gva,
+         hvp->hvm_io.mmio_gpfn);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* also look into arch_get_info_guest() to get context */
+static void
+kdb_print_uregs(struct cpu_user_regs *regs)
+{
+#ifdef __x86_64__
+    kdbp("      rflags: %016lx   rip: %016lx\n", regs->rflags, regs->rip);
+    kdbp("         rax: %016lx   rbx: %016lx   rcx: %016lx\n",
+         regs->rax, regs->rbx, regs->rcx);
+    kdbp("         rdx: %016lx   rsi: %016lx   rdi: %016lx\n",
+         regs->rdx, regs->rsi, regs->rdi);
+    kdbp("         rbp: %016lx   rsp: %016lx    r8: %016lx\n",
+         regs->rbp, regs->rsp, regs->r8);
+    kdbp("          r9:  %016lx  r10: %016lx   r11: %016lx\n",
+         regs->r9,  regs->r10, regs->r11);
+    kdbp("         r12: %016lx   r13: %016lx   r14: %016lx\n",
+         regs->r12, regs->r13, regs->r14);
+    kdbp("         r15: %016lx\n", regs->r15);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+         "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%08lx entryvec:%08lx upcall_mask:%lx\n",
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#else
+    kdbp("      eflags: %016lx eip: 016lx\n", regs->eflags, regs->eip);
+    kdbp("      eax: %08x   ebx: %08x   ecx: %08x   edx: %08x\n",
+         regs->eax, regs->ebx, regs->ecx, regs->edx);
+    kdbp("      esi: %08x   edi: %08x   ebp: %08x   esp: %08x\n",
+         regs->esi, regs->edi, regs->ebp, regs->esp);
+    kdbp("      ds: %04x   es: %04x   fs: %04x   gs: %04x   "
+     "      ss: %04x   cs: %04x\n", regs->ds, regs->es, regs->fs,
+         regs->gs, regs->ss, regs->cs);
+    kdbp("      errcode:%04lx entryvec:%04lx upcall_mask:%lx\n", 
+         regs->error_code, regs->entry_vector, regs->saved_upcall_mask);
+#endif
+}
+
+#if XEN_SUBVERSION < 3             /* xen 3.1.x or xen 3.2.x */
+#ifdef CONFIG_COMPAT
+    #undef vcpu_info
+    #define vcpu_info(v, field)             \
+    (*(!has_32bit_shinfo((v)->domain) ?                                       \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->native.field : \
+       (typeof(&(v)->vcpu_info->compat.field))&(v)->vcpu_info->compat.field))
+
+    #undef __shared_info
+    #define __shared_info(d, s, field)                      \
+    (*(!has_32bit_shinfo(d) ?                           \
+       (typeof(&(s)->compat.field))&(s)->native.field : \
+       (typeof(&(s)->compat.field))&(s)->compat.field))
+#endif
+#endif
+
+static void kdb_display_pv_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct pv_vcpu *gp = &vp->arch.pv_vcpu;
+
+    kdbp("      GDT_VIRT_START(vcpu): %lx\n", GDT_VIRT_START(vp));
+    kdbp("      GDT: entries:0x%lx  frames:\n", gp->gdt_ents);
+    for (i=0; i < 16; i=i+4) 
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->gdt_frames[i], 
+             gp->gdt_frames[i+1], gp->gdt_frames[i+2],gp->gdt_frames[i+3]);
+    
+    kdbp("      trap_ctxt:%lx kernel_ss:%lx kernel_sp:%lx\n", gp->trap_ctxt,
+         gp->kernel_ss, gp->kernel_sp);
+    kdbp("      ctrlregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", gp->ctrlreg[i], 
+             gp->ctrlreg[i+1], gp->ctrlreg[i+2], gp->ctrlreg[i+3]);
+#ifdef __x86_64__
+    kdbp("      callback:   event: %016lx   failsafe: %016lx\n", 
+         gp->event_callback_eip, gp->failsafe_callback_eip);
+    kdbp("      base: fs:0x%lx gskern:0x%lx gsuser:0x%lx\n", 
+         gp->fs_base, gp->gs_base_kernel, gp->gs_base_user);
+#else
+    kdbp("      callback:   event: %08lx:%08lx   failsafe: %08lx:%08lx\n", 
+         gp->event_callback_cs, gp->event_callback_eip, 
+         gp->failsafe_callback_cs, gp->failsafe_callback_eip);
+#endif
+    kdbp("    vcpu_info_mfn: %lx  iopl: %x\n", gp->vcpu_info_mfn, gp->iopl);
+    kdbp("\n");
+}
+
+/* Display one VCPU info */
+static void
+kdb_display_vcpu(struct vcpu *vp)
+{
+    int i;
+    struct arch_vcpu *avp = &vp->arch;
+    struct paging_vcpu *pvp = &vp->arch.paging;
+    int domid = vp->domain->domain_id;
+
+    kdbp("\nVCPU:  vcpu-id:%d  vcpu-ptr:%p ", vp->vcpu_id, vp);
+    kdbp("  processor:%d domid:%d  domp:%p\n", vp->processor, domid,vp->domain);
+
+    if (domid == DOMID_IDLE) {
+        kdbp("    IDLE vcpu.\n");
+        return;
+    }
+    kdbp("  pause: flags:0x%016lx count:%x\n", vp->pause_flags, 
+         vp->pause_count.counter);
+    kdbp("  vcpu: initdone:%d running:%d\n", 
+         vp->is_initialised, vp->is_running);
+    kdbp("  mcepend:%d nmipend:%d shut: def:%d paused:%d\n", 
+         vp->mce_pending,  vp->nmi_pending, vp->defer_shutdown, 
+         vp->paused_for_shutdown);
+    kdbp("  &vcpu_info:%p : evtchn_upc_pend:%x _mask:%x\n",
+         vp->vcpu_info, vcpu_info(vp, evtchn_upcall_pending),
+         vcpu_info(vp, evtchn_upcall_mask));
+    kdbp("  evt_pend_sel:%lx poll_evtchn:%x ", 
+         *(unsigned long *)&vcpu_info(vp, evtchn_pending_sel), vp->poll_evtchn);
+    kdb_print_spin_lock("virq_lock:", &vp->virq_lock, "\n");
+    for (i=0; i < NR_VIRQS; i++)
+        if (vp->virq_to_evtchn[i] != 0)
+            kdbp("      virq:$%d port:$%d\n", i, vp->virq_to_evtchn[i]);
+
+    kdbp("  next:%p periodic: period:0x%lx last_event:0x%lx\n", 
+         vp->next_in_list, vp->periodic_period, vp->periodic_last_event);
+    kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:%p sched_priv:0x%p\n",
+         vp->cpu_affinity, vp->vcpu_dirty_cpumask, vp->sched_priv);
+    kdbp("  &runstate: %p state: %x (eg. RUNSTATE_running) guestptr:%p\n", 
+         &vp->runstate, vp->runstate.state, runstate_guest(vp));
+    kdbp("\n");
+    kdbp("  arch info: (%p)\n", &vp->arch);
+    kdbp("    guest_context: VGCF_ flags:%lx", 
+         vp->arch.vgc_flags); /* VGCF_in_kernel */
+    if (is_hvm_or_hyb_vcpu(vp))
+        kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
+    kdbp("\n");
+    kdb_print_uregs(&vp->arch.user_regs);
+    kdbp("      debugregs:\n");
+    for (i=0; i < 8; i=i+4)
+        kdbp("          %016lx %016lx %016lx %016lx\n", avp->debugreg[i], 
+             avp->debugreg[i+1], avp->debugreg[i+2], avp->debugreg[i+3]);
+    kdb_display_pv_vcpu(vp);
+
+    kdbp("    TF_flags: %016lx  guest_table: %016lx cr3:%016lx\n", 
+         vp->arch.flags, vp->arch.guest_table.pfn, avp->cr3); 
+    kdbp("    paging: \n");
+    kdbp("      vtlb:%p\n", &pvp->vtlb);
+    kdbp("      &pg_mode:%p gstlevels:%d &shadow:%p shlevels:%d\n",
+         pvp->mode, pvp->mode->guest_levels, &pvp->mode->shadow,
+         pvp->mode->shadow.shadow_levels);
+    kdbp("      shadow_vcpu:\n");
+    kdbp("        guest_vtable:%p last em_mfn:"KDBFL"\n",
+         pvp->shadow.guest_vtable, pvp->shadow.last_emulated_mfn);
+#if CONFIG_PAGING_LEVELS >= 3
+    kdbp("         l3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.l3table[3].l3, pvp->shadow.l3table[2].l3, 
+     pvp->shadow.l3table[1].l3, pvp->shadow.l3table[0].l3);
+    kdbp("        gl3tbl: 3:"KDBFL" 2:"KDBFL"\n"
+         "                1:"KDBFL" 0:"KDBFL"\n",
+     pvp->shadow.gl3e[3].l3, pvp->shadow.gl3e[2].l3, 
+     pvp->shadow.gl3e[1].l3, pvp->shadow.gl3e[0].l3);
+#endif
+    kdbp("  gdbsx_vcpu_event:%x\n", vp->arch.gdbsx_vcpu_event);
+}
+
+/* 
+ * FUNCTION: Dispaly (current) VCPU/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_vcpu(void)
+{
+    kdbp("vcpu [vcpu-ptr] : display current/vcpu-ptr vcpu info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_vcpu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct vcpu *v = current;
+
+    if (argc > 2 || (argc > 1 && *argv[1] == '?'))
+        kdb_usgf_vcpu();
+    else if (argc <= 1)
+        kdb_display_vcpu(v);
+    else if (kdb_str2ulong(argv[1], (ulong *)&v) && kdb_vcpu_valid(v))
+        kdb_display_vcpu(v);
+    else 
+        kdbp("Invalid usage/argument:%s v:%lx\n", argv[1], (long)v);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* from paging_dump_domain_info() */
+static void kdb_pr_dom_pg_modes(struct domain *d)
+{
+    if (paging_mode_enabled(d)) {
+        kdbp(" paging mode enabled");
+        if ( paging_mode_shadow(d) )
+            kdbp(" shadow(PG_SH_enable)");
+        if ( paging_mode_hap(d) )
+            kdbp(" hap(PG_HAP_enable) ");
+        if ( paging_mode_refcounts(d) )
+            kdbp(" refcounts(PG_refcounts) ");
+        if ( paging_mode_log_dirty(d) )
+            kdbp(" log_dirty(PG_log_dirty) ");
+        if ( paging_mode_translate(d) )
+            kdbp(" translate(PG_translate) ");
+        if ( paging_mode_external(d) )
+            kdbp(" external(PG_external) ");
+    } else
+        kdbp(" disabled");
+    kdbp("\n");
+}
+
+/* print event channels info for a given domain 
+ * NOTE: very confusing, port and event channel refer to the same thing. evtchn
+ * is arry of pointers to a bucket of pointers to 128 struct evtchn{}. while
+ * 64bit xen can handle 4096 max channels, a 32bit guest is limited to 1024 */
+static void noinline kdb_print_dom_eventinfo(struct domain *dp)
+{
+    uint chn;
+
+    kdbp("\n");
+    kdbp("  Evt: MAX_EVTCHNS:$%d ptr:%p pollmsk:%08lx ",
+         MAX_EVTCHNS(dp), dp->evtchn, dp->poll_mask[0]);
+    kdb_print_spin_lock("lk:", &dp->event_lock, "\n");
+    kdbp("    &evtchn_pending:%p &evtchn_mask:%p\n", 
+         shared_info(dp, evtchn_pending), shared_info(dp, evtchn_mask));
+
+    kdbp("   Channels info: (everything is in decimal):\n");
+    for (chn=0; chn < MAX_EVTCHNS(dp); chn++ ) {
+        struct evtchn *bktp = dp->evtchn[chn/EVTCHNS_PER_BUCKET];
+        struct evtchn *chnp = &bktp[chn & (EVTCHNS_PER_BUCKET-1)];
+        char pbit = test_bit(chn, &shared_info(dp, evtchn_pending)) ? 'Y' : 'N';
+        char mbit = test_bit(chn, &shared_info(dp, evtchn_mask)) ? 'Y' : 'N';
+
+        if (bktp==NULL || chnp->state==ECS_FREE)
+            continue;
+
+        kdbp("    chn:%4u st:%d _xen=%d _vcpu_id:%2d ", chn, chnp->state,
+             chnp->xen_consumer, chnp->notify_vcpu_id);
+        if (chnp->state == ECS_UNBOUND)
+            kdbp(" rem-domid:%d", chnp->u.unbound.remote_domid);
+        else if (chnp->state == ECS_INTERDOMAIN)
+            kdbp(" rem-port:%d rem-dom:%d", chnp->u.interdomain.remote_port,
+                 chnp->u.interdomain.remote_dom->domain_id);
+        else if (chnp->state == ECS_PIRQ)
+            kdbp(" pirq:%d", chnp->u.pirq);
+        else if (chnp->state == ECS_VIRQ)
+            kdbp(" virq:%d", chnp->u.virq);
+
+        kdbp("  pend:%c mask:%c\n", pbit, mbit);
+    }
+#if 0
+    kdbp("pirq to evtchn mapping (pirq:evtchn) (all decimal):\n");
+    for (i=0; i < dp->nr_pirqs; i ++)
+        if (dp->pirq_to_evtchn[i])
+            kdbp("(%d:%d) ", i, dp->pirq_to_evtchn[i]);
+    kdbp("\n");
+#endif
+}
+
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    struct hvm_domain *hvp = &dp->arch.hvm_domain;
+
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+    if (hvp == NULL)
+        return;
+
+    if (hvp->irq.callback_via_type == HVMIRQ_callback_vector)
+        kdbp("    HVMIRQ_callback_vector: %x\n", hvp->irq.callback_via.vector);
+
+    if (!is_hvm_domain(dp))
+        return;
+
+    kdbp("    HVM PARAMS (all in hex):\n");
+    kdbp("\tioreq.page:%lx ioreq.va:%lx\n", hvp->ioreq.page, hvp->ioreq.va);
+    kdbp("\tbuf_ioreq.page:%lx ioreq.va:%lx\n", hvp->buf_ioreq.page, 
+         hvp->buf_ioreq.va);
+    kdbp("\tHVM_PARAM_CALLBACK_IRQ: %x\n", hvp->params[HVM_PARAM_CALLBACK_IRQ]);
+    kdbp("\tHVM_PARAM_STORE_PFN: %x\n", hvp->params[HVM_PARAM_STORE_PFN]);
+    kdbp("\tHVM_PARAM_STORE_EVTCHN: %x\n", hvp->params[HVM_PARAM_STORE_EVTCHN]);
+    kdbp("\tHVM_PARAM_PAE_ENABLED: %x\n", hvp->params[HVM_PARAM_PAE_ENABLED]);
+    kdbp("\tHVM_PARAM_IOREQ_PFN: %x\n", hvp->params[HVM_PARAM_IOREQ_PFN]);
+    kdbp("\tHVM_PARAM_BUFIOREQ_PFN: %x\n", hvp->params[HVM_PARAM_BUFIOREQ_PFN]);
+    kdbp("\tHVM_PARAM_VIRIDIAN: %x\n", hvp->params[HVM_PARAM_VIRIDIAN]);
+    kdbp("\tHVM_PARAM_TIMER_MODE: %x\n", hvp->params[HVM_PARAM_TIMER_MODE]);
+    kdbp("\tHVM_PARAM_HPET_ENABLED: %x\n", hvp->params[HVM_PARAM_HPET_ENABLED]);
+    kdbp("\tHVM_PARAM_IDENT_PT: %x\n", hvp->params[HVM_PARAM_IDENT_PT]);
+    kdbp("\tHVM_PARAM_DM_DOMAIN: %x\n", hvp->params[HVM_PARAM_DM_DOMAIN]);
+    kdbp("\tHVM_PARAM_ACPI_S_STATE: %x\n", hvp->params[HVM_PARAM_ACPI_S_STATE]);
+    kdbp("\tHVM_PARAM_VM86_TSS: %x\n", hvp->params[HVM_PARAM_VM86_TSS]);
+    kdbp("\tHVM_PARAM_VPT_ALIGN: %x\n", hvp->params[HVM_PARAM_VPT_ALIGN]);
+    kdbp("\tHVM_PARAM_CONSOLE_PFN: %x\n", hvp->params[HVM_PARAM_CONSOLE_PFN]);
+    kdbp("\tHVM_PARAM_CONSOLE_EVTCHN: %x\n", 
+         hvp->params[HVM_PARAM_CONSOLE_EVTCHN]);
+    kdbp("\tHVM_PARAM_ACPI_IOPORTS_LOCATION: %x\n", 
+         hvp->params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+    kdbp("\tHVM_PARAM_MEMORY_EVENT_SINGLE_STEP: %x\n", 
+         hvp->params[HVM_PARAM_MEMORY_EVENT_SINGLE_STEP]);
+}
+static void kdb_print_rangesets(struct domain *dp)
+{
+    int locked = spin_is_locked(&dp->rangesets_lock);
+
+    if (locked)
+        spin_unlock(&dp->rangesets_lock);
+    rangeset_domain_printk(dp);
+    if (locked)
+        spin_lock(&dp->rangesets_lock);
+}
+
+static void kdb_pr_vtsc_info(struct arch_domain *ap)
+{
+    kdbp("    VTSC info: tsc_mode:%x  vtsc:%x  vtsc_last:%016lx\n", 
+         ap->tsc_mode, ap->vtsc, ap->vtsc_last);
+    kdbp("        vtsc_offset:%016lx tsc_khz:%08lx incarnation:%x\n", 
+         ap->vtsc_offset, ap->vtsc_offset, ap->incarnation);
+    kdbp("        vtsc_kerncount:%016lx _usercount:%016lx\n",
+         ap->vtsc_kerncount, ap->vtsc_usercount);
+}
+
+/* display one domain info */
+static void
+kdb_display_dom(struct domain *dp)
+{
+    struct vcpu *vp;
+    int printed = 0;
+    struct grant_table *gp = dp->grant_table;
+    struct arch_domain *ap = &dp->arch;
+
+    kdbp("\nDOMAIN :    domid:0x%04x ptr:0x%p\n", dp->domain_id, dp);
+    if (dp->domain_id == DOMID_IDLE) {
+        kdbp("    IDLE domain.\n");
+        return;
+    }
+    if (dp->is_dying) {
+        kdbp("    domain is DYING.\n");
+        return;
+    }
+#if 0
+    kdb_print_spin_lock("  pgalk:", &dp->page_alloc_lock, "\n");
+    kdbp("  pglist:  0x%p 0x%p\n", dp->page_list.next,KDB_PGLLE(dp->page_list));
+    kdbp("  xpglist: 0x%p 0x%p\n", dp->xenpage_list.next, 
+         KDB_PGLLE(dp->xenpage_list));
+    kdbp("  next:0x%p hashnext:0x%p\n", 
+         dp->next_in_list, dp->next_in_hashbucket);
+#endif
+    kdbp("  PAGES: tot:0x%08x max:0x%08x xenheap:0x%08x\n", 
+         dp->tot_pages, dp->max_pages, dp->xenheap_pages);
+
+    kdb_print_rangesets(dp);
+    kdb_print_dom_eventinfo(dp);
+    kdbp("\n");
+    kdbp("  Grant table: gp:0x%p\n", gp);
+    if (gp) {
+        kdbp("    nr_frames:0x%08x shpp:0x%p active:0x%p\n",
+             gp->nr_grant_frames, gp->shared_raw, gp->active);
+        kdbp("    maptrk:0x%p maphd:0x%08x maplmt:0x%08x\n", 
+             gp->maptrack, gp->maptrack_head, gp->maptrack_limit);
+        kdbp("    mapcnt:");
+        kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
+    }
+    kdbp("  hvm:%d priv:%d need_iommu:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_privileged, dp->need_iommu,
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
+    kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
+    kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
+         dp->is_shut_down, dp->shutdown_code);
+    kdbp("  pausecnt:0x%08x vm_assist:0x"KDBFL" refcnt:0x%08x\n",
+         dp->pause_count.counter, dp->vm_assist, dp->refcnt.counter);
+    kdbp("  &domain_dirty_cpumask:%p\n", &dp->domain_dirty_cpumask); 
+
+    kdbp("  shared == vcpu_info[]: %p\n",  dp->shared_info); 
+    kdbp("    arch_shared: maxpfn: %lx pfn-mfn-frame-ll mfn: %lx\n", 
+         arch_get_max_pfn(dp), arch_get_pfn_to_mfn_frame_list_list(dp));
+    kdbp("\n");
+    kdbp("  arch_domain at : %p\n", ap);
+
+#ifdef CONFIG_X86_64
+    kdbp("    pt_pages:0x%p ", ap->mm_perdomain_pt_pages);
+    kdbp("    l2:0x%p l3:0x%p\n", ap->mm_perdomain_l2, ap->mm_perdomain_l3);
+#else
+    kdbp("    pt:0x%p ", ap->mm_perdomain_pt);
+#endif
+#ifdef CONFIG_X86_32
+    kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
+#endif
+    kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
+    kdb_pr_dom_pg_modes(dp);
+    kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
+         KDB_PGLLE(ap->p2m->pages));
+    kdbp("       max_mapped_pfn:"KDBFL, ap->p2m->max_mapped_pfn);
+#if XEN_SUBVERSION > 0 && XEN_VERSION == 4              /* xen 4.1 and above */
+    kdbp("  phys_table:%p\n", ap->p2m->phys_table.pfn);
+#else
+    kdbp("  phys_table.pfn:"KDBFL"\n", ap->phys_table.pfn);
+#endif
+    kdbp("    physaddr_bitsz:%d 32bit_pv:%d has_32bit_shinfo:%d\n", 
+         ap->physaddr_bitsize, ap->is_32bit_pv, ap->has_32bit_shinfo);
+    kdb_pr_vtsc_info(ap);
+    kdbp("  sched:0x%p  &handle:0x%p\n", dp->sched_priv, &dp->handle);
+    kdbp("  vcpu ptrs:\n   ");
+    for_each_vcpu(dp, vp) {
+        kdbp(" %d:%p", vp->vcpu_id, vp);
+        if (++printed % 4 == 0) kdbp("\n   ");
+    }
+    kdbp("\n");
+}
+
+/* 
+ * FUNCTION: Dispaly (current) domain/s
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_dom(void)
+{
+    kdbp("dom [all|domid]: Display current/all/given domain/s\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t 
+kdb_cmdf_dom(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int id;
+    struct domain *dp = current->domain;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dom();
+
+    if (argc > 1) {
+        for(dp=domain_list; dp; dp=dp->next_in_list)
+            if (kdb_str2deci(argv[1], &id) && dp->domain_id==id)
+                kdb_display_dom(dp);
+            else if (!strcmp(argv[1], "all")) 
+                kdb_display_dom(dp);
+    } else {
+        kdbp("Displaying current domain :\n");
+        kdb_display_dom(dp);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dirq(void)
+{
+    kdbp("dirq : dump irq bindings\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dirq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long irq, sz, offs, addr;
+    char buf[KSYM_NAME_LEN+1];
+    char affstr[NR_CPUS/4+NR_CPUS/32+2];    /* courtesy dump_irqs() */
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dirq();
+
+#if XEN_VERSION < 4 && XEN_SUBVERSION < 5           /* xen 3.4.x or below */
+    kdbp("idx/irq#/status: all are in decimal\n");
+    kdbp("idx  irq#  status   action(handler name devid)\n");
+    for (irq=0; irq < NR_VECTORS; irq++) {
+        irq_desc_t  *dp = &irq_desc[irq];
+        if (!dp->action)
+            continue;
+        addr = (unsigned long)dp->action->handler;
+        kdbp("[%3ld]:irq:%3d st:%3d f:%s devnm:%s devid:0x%p\n",
+             i, vector_to_irq(irq), dp->status, (dp->status & IRQ_GUEST) ? 
+                            "GUEST IRQ" : symbols_lookup(addr, &sz, &offs, buf),
+             dp->action->name, dp->action->dev_id);
+    }
+#else
+    kdbp("irq_desc[]:%p nr_irqs: $%d nr_irqs_gsi: $%d\n", irq_desc, nr_irqs, 
+          nr_irqs_gsi);
+    kdbp("irq/vec#/status: in decimal. affinity in hex, not bitmap\n");
+    kdbp("irq-- vec sta function----------- name---- type--------- ");
+    kdbp("aff devid------------\n");
+    for (irq=0; irq < nr_irqs; irq++) {
+        void *devidp;
+        const char *symp, *nmp;
+        irq_desc_t  *dp = irq_to_desc(irq);
+        struct arch_irq_desc *archp = &dp->arch;
+
+        if (!dp->handler || dp->handler==&no_irq_type || dp->status & IRQ_GUEST)
+            continue;
+
+        addr = dp->action ? (unsigned long)dp->action->handler : 0;
+        symp = addr ? symbols_lookup(addr, &sz, &offs, buf) : "n/a ";
+        nmp = addr ? dp->action->name : "n/a ";
+        devidp = addr ? dp->action->dev_id : NULL;
+        cpumask_scnprintf(affstr, sizeof(affstr), dp->affinity);
+        kdbp("[%3ld] %03d %03d %-19s %-8s %-13s %3s 0x%p\n", irq, archp->vector,
+             dp->status, symp, nmp, dp->handler->typename, affstr, devidp);
+    }
+    kdb_prnt_guest_mapped_irqs();
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void
+kdb_prnt_vec_irq_table(int cpu)
+{
+    int i,j, *tbl = per_cpu(vector_irq, cpu);
+
+    kdbp("CPU %d : ", cpu);
+    for (i=0, j=0; i < NR_VECTORS; i++)
+        if (tbl[i] != -1) {
+            kdbp("(%3d:%3d) ", i, tbl[i]);
+            if (!(++j % 5))
+                kdbp("\n        ");
+        }
+    kdbp("\n");
+}
+
+/* Dump irq desc table */
+static kdb_cpu_cmd_t
+kdb_usgf_dvit(void)
+{
+    kdbp("dvit [cpu|all]: dump (per cpu)vector irq table\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvit(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu, ccpu = smp_processor_id();
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvit();
+    
+    if (argc > 1) {
+        if (!strcmp(argv[1], "all")) 
+            cpu = -1;
+        else if (!kdb_str2deci(argv[1], &cpu)) {
+            kdbp("Invalid cpu:%d\n", cpu);
+            return kdb_usgf_dvit();
+        }
+    } else
+        cpu = ccpu;
+
+    kdbp("Per CPU vector irq table pairs (vector:irq) (all decimals):\n");
+    if (cpu != -1) 
+        kdb_prnt_vec_irq_table(cpu);
+    else
+        for_each_online_cpu(cpu) 
+            kdb_prnt_vec_irq_table(cpu);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* do vmexit on all cpu's so intel VMCS can be dumped */
+static kdb_cpu_cmd_t 
+kdb_all_cpu_flush_vmcs(void)
+{
+    int cpu, ccpu = smp_processor_id();
+    for_each_online_cpu(cpu) {
+        if (cpu == ccpu) {
+            kdb_curr_cpu_flush_vmcs();
+        } else {
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE){  /* hung cpu */
+                kdbp("Skipping (hung?) cpu %d\n", cpu);
+                continue;
+            }
+            kdb_cpu_cmd[cpu] = KDB_CPU_DO_VMEXIT;
+            while (kdb_cpu_cmd[cpu]==KDB_CPU_DO_VMEXIT);
+        }
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display VMCS or VMCB */
+static kdb_cpu_cmd_t
+kdb_usgf_dvmc(void)
+{
+    kdbp("dvmc [domid][vcpuid] : Dump vmcs/vmcb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dvmc(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t domid = 0;  /* unsigned type don't like -1 */
+    int vcpuid = -1;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dvmc();
+
+    if (argc > 1) { 
+        if (!kdb_str2domid(argv[1], &domid, 1))
+            return KDB_CPU_MAIN_KDB;
+    }
+    if (argc > 2 && !kdb_str2deci(argv[2], &vcpuid)) {
+        kdbp("Bad vcpuid: 0x%x\n", vcpuid);
+        return KDB_CPU_MAIN_KDB;
+    }
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        kdb_all_cpu_flush_vmcs();
+        kdb_dump_vmcs(domid, (int)vcpuid);
+    } else {
+        kdb_dump_vmcb(domid, (int)vcpuid);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_mmio(void)
+{
+    kdbp("mmio: dump mmio related info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmio(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmio();
+
+    kdbp("r/o mmio ranges:\n");
+    rangeset_printk(mmio_ro_ranges);
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Dump timer/timers queues */
+static kdb_cpu_cmd_t
+kdb_usgf_dtrq(void)
+{
+    kdbp("dtrq: dump timer queues on all cpus\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dtrq(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dtrq();
+
+    kdb_dump_timer_queues();
+    return KDB_CPU_MAIN_KDB;
+}
+
+struct idte {
+    uint16_t offs0_15;
+    uint16_t selector;
+    uint16_t meta;
+    uint16_t offs16_31;
+    uint32_t offs32_63;
+    uint32_t resvd;
+};
+
+#ifdef __x86_64__
+static void
+kdb_print_idte(int num, struct idte *idtp) 
+{
+    uint16_t mta = idtp->meta;
+    char dpl = ((mta & 0x6000) >> 13);
+    char present = ((mta &0x8000) >> 15);
+    int tval = ((mta &0x300) >> 8);
+    char *type = (tval == 1) ? "Task" : ((tval== 2) ? "Intr" : "Trap");
+    domid_t domid = idtp->selector==__HYPERVISOR_CS64 ? DOMID_IDLE :
+                    current->domain->domain_id;
+    uint64_t addr = idtp->offs0_15 | ((uint64_t)idtp->offs16_31 << 16) | 
+                    ((uint64_t)idtp->offs32_63 << 32);
+
+    kdbp("[%03d]: %s %x  %x %04x:%016lx ", num, type, dpl, present,
+         idtp->selector, addr); 
+    kdb_prnt_addr2sym(domid, addr, "\n");
+}
+
+/* Dump 64bit idt table currently on this cpu. Intel Vol 3 section 5.14.1 */
+static kdb_cpu_cmd_t
+kdb_usgf_didt(void)
+{
+    kdbp("didt : dump IDT table on the current cpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int i;
+    struct idte *idtp = (struct idte *)idt_tables[smp_processor_id()];
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_didt();
+
+    kdbp("IDT at:%p\n", idtp);
+    kdbp("idt#  Type DPL P addr (all hex except idt#)\n", idtp);
+    for (i=0; i < 256; i++, idtp++) 
+        kdb_print_idte(i, idtp);
+    return KDB_CPU_MAIN_KDB;
+}
+#else
+static kdb_cpu_cmd_t
+kdb_cmdf_didt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbp("kdb: Please implement me in 32bit hypervisor\n");
+    return KDB_CPU_MAIN_KDB;
+}
+#endif
+
+struct gdte {             /* same for TSS and LDT */
+    ulong limit0:16;
+    ulong base0:24;       /* linear address base, not pa */
+    ulong acctype:4;      /* Type: access rights */
+    ulong S:1;            /* S: 0 = system, 1 = code/data */
+    ulong DPL:2;          /* DPL */
+    ulong P:1;            /* P: Segment Present */
+    ulong limit1:4;
+    ulong AVL:1;          /* AVL: avail for use by system software */
+    ulong L:1;            /* L: 64bit code segment */
+    ulong DB:1;           /* D/B */
+    ulong G:1;            /* G: granularity */
+    ulong base1:8;        /* linear address base, not pa */
+};
+
+union gdte_u {
+    struct gdte gdte;
+    u64 gval;
+};
+
+struct call_gdte {
+    unsigned short offs0:16;
+    unsigned short sel:16;
+    unsigned short misc0:16;
+    unsigned short offs1:16;
+};
+
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
+union sgdte_u {
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
+    u64 sgval;
+};
+
+/* return binary form of a hex in string : max 4 chars 0000 to 1111 */
+static char *kdb_ret_acctype(uint acctype)
+{
+    static char buf[16];
+    char *p = buf;
+    int i;
+
+    if (acctype > 0xf) {
+        buf[0] = buf[1] = buf[2] = buf[3] = '?';
+        buf[5] = '\n';
+        return buf;
+    }
+    for (i=0; i < 4; i++, p++, acctype=acctype>>1)
+        *p = (acctype & 0x1) ? '1' : '0';
+
+    return buf;
+}
+
+/* Display GDT table. IA-32e mode is assumded. */
+/* first display non system descriptors then display system descriptors */
+static kdb_cpu_cmd_t
+kdb_usgf_dgdt(void)
+{
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
+         "given vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dgdt(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct Xgt_desc_struct desc;
+    union gdte_u u1;
+    ulong start_addr, end_addr, taddr=0;
+    domid_t domid = DOMID_IDLE;
+    int idx;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_dgdt();
+
+    if (argc > 1) {
+        if (argc != 3)
+            return kdb_usgf_dgdt();
+
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
+        } else {
+            kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
+            return kdb_usgf_dgdt();
+        }
+    } else {
+        __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
+    }
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
+    kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
+         "--Base Addr ----  Limit\n");
+    kdbp("                              Type\n");
+
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+            continue;
+
+        if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
+            continue;               /* what an effin x86 mess */
+
+        idx = (taddr - start_addr) / 8;
+        if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
+            taddr += sizeof(ulong);
+            continue;
+        }
+        kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
+             u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
+             (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
+             u1.gdte.limit0 | (u1.gdte.limit1<<16));
+    }
+
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
+        uint acctype;
+        u64 upper, addr64=0;
+
+        /* not all entries are mapped. do this to avoid GP even if hyp */
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
+            u1.gval == 0 || u1.gdte.S == 1) {
+            continue;
+        }
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+            kdbp("Could not read upper 8 bytes of system desc\n");
+            upper = 0;
+        }
+        acctype = u1.gdte.acctype;
+        if (acctype != 2 && acctype != 9 && acctype != 11 && acctype !=12 &&
+            acctype != 14 && acctype != 15)
+            continue;
+
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
+
+        /* Vol 3A: table: 3-2  page: 3-19 */
+        if (acctype == 2) {
+            kdbp("LDT gate (0010)\n");
+        }
+        else if (acctype == 9) {
+            kdbp("TSS avail gate(1001)\n");
+        }
+        else if (acctype == 11) {
+            kdbp("TSS busy gate(1011)\n");
+        }
+        else if (acctype == 12) {
+            kdbp("CALL gate (1100)\n");
+        }
+        else if (acctype == 14) {
+            kdbp("IDT gate (1110)\n");
+        }
+        else if (acctype == 15) {
+            kdbp("Trap gate (1111)\n"); 
+        }
+
+        if (acctype == 2 || acctype == 9 || acctype == 11) {
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display scheduler basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_sched(void)
+{
+    kdbp("sched: show schedular info and run queues\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sched(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_sched();
+
+    kdb_print_sched_info();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Display MMU basic and extended info */
+static kdb_cpu_cmd_t
+kdb_usgf_mmu(void)
+{
+    kdbp("mmu: print basic MMU info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_mmu(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    int cpu;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_mmu();
+
+    kdbp("MMU Info:\n");
+    kdbp("total  pages: %lx\n", total_pages);
+    kdbp("max page/mfn: %lx\n", max_page);
+    kdbp("frame_table:  %p\n", frame_table);
+    kdbp("DIRECTMAP_VIRT_START:  %lx\n", DIRECTMAP_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_START: %lx\n", HYPERVISOR_VIRT_START);
+    kdbp("HYPERVISOR_VIRT_END:   %lx\n", HYPERVISOR_VIRT_END);
+    kdbp("RO_MPT_VIRT_START:     %lx\n", RO_MPT_VIRT_START);
+    kdbp("PERDOMAIN_VIRT_START:  %lx\n", PERDOMAIN_VIRT_START);
+    kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
+    kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
+         (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
+
+    kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
+    kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
+    kdbp("LAST_RESERVED_GDT_ENTRY: %lx\n", (ulong)LAST_RESERVED_GDT_ENTRY);
+    kdbp("  Per cpu non-compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(gdt_table, cpu));
+    }
+    kdbp("  Per cpu compat gdt_table:\n");
+    for_each_online_cpu(cpu) {
+        kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
+    }
+    kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
+#ifdef USER_MAPPINGS_ARE_GLOBAL
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
+#else
+    kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
+#endif
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* for HVM/HYB guests, go thru EPT. For PV guest we need to go to the btree. 
+ * btree: pfn_to_mfn_frame_list_list is root that points (has mfns of) upto 16
+ * pages (call 'em l2 nodes) that contain mfns of guest p2m table pages 
+ * NOTE: num of entries in a p2m page is same as num of entries in l2 node */
+static noinline ulong
+kdb_gpfn2mfn(struct domain *dp, ulong gpfn, p2m_type_t *typep) 
+{
+    int idx;
+
+    if ( !paging_mode_translate(dp) ) {
+        mfn_t *mfn_va, mfn = arch_get_pfn_to_mfn_frame_list_list(dp);
+        int g_longsz = kdb_guest_bitness(dp->domain_id)/8;
+        int entries_per_pg = PAGE_SIZE/g_longsz;
+        const int shift = get_count_order(entries_per_pg);
+
+	if ( !mfn_valid(mfn) ) {
+	    kdbp("Invalid frame_list_list mfn:%lx for non-xlate guest\n", mfn);
+	    return INVALID_MFN;
+	}
+
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn >> 2*shift;     /* index in root page/node */
+        if (idx > 15) {
+            kdbp("gpfn:%lx idx:%x not in frame list limit of z16\n", gpfn, idx);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        if (mfn==0) {
+            kdbp("No mfn for idx:%d for gpfn:%lx in root pg\n", idx, gpfn);
+            unmap_domain_page(mfn_va);
+            return INVALID_MFN;
+        }
+        mfn_va = map_domain_page(mfn);
+        KDBGP1("p2m: idx:%x fll:%lx mfn of 2nd lvl page:%lx\n", idx,
+               arch_get_pfn_to_mfn_frame_list_list(dp), mfn);
+
+        idx = (gpfn>>shift) & ((1<<shift)-1);     /* idx in l2 node */
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+        if (mfn == 0) {
+            kdbp("No mfn entry at:%x in 2nd lvl pg for gpfn:%lx\n", idx, gpfn);
+            return INVALID_MFN;
+        }
+        KDBGP1("p2m: idx:%x  mfn of p2m page:%lx\n", idx, mfn); 
+        mfn_va = map_domain_page(mfn);
+        idx = gpfn & ((1<<shift)-1);
+        mfn = (g_longsz == 4) ? ((int *)mfn_va)[idx] : mfn_va[idx];
+        unmap_domain_page(mfn_va);
+
+	*typep = -1;
+        return mfn;
+    } else
+        return get_gfn_query(dp, gpfn, typep);
+
+    return INVALID_MFN;
+}
+
+/* given a pfn, find it's mfn */
+static kdb_cpu_cmd_t
+kdb_usgf_p2m(void)
+{
+    kdbp("p2m domid 0xgpfn : gpfn to mfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_p2m(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gpfn, mfn;
+    p2m_type_t p2mtype;
+
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
+        !kdb_str2ulong(argv[2], &gpfn)) {
+
+        return kdb_usgf_p2m();
+    }
+    mfn = kdb_gpfn2mfn(dp, gpfn, &p2mtype);
+    if ( paging_mode_translate(dp) )
+        kdbp("p2m[%lx] == %lx type:%d/0x%x\n", gpfn, mfn, p2mtype, p2mtype);
+    else 
+        kdbp("p2m[%lx] == %lx type:N/A(PV)\n", gpfn, mfn);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* given an mfn, lookup pfn in the MPT */
+static kdb_cpu_cmd_t
+kdb_usgf_m2p(void)
+{
+    kdbp("m2p 0xmfn: mfn to pfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_m2p(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    mfn_t mfn;
+    if (argc > 1 && kdb_str2ulong(argv[1], &mfn))
+        if (mfn_valid(mfn))
+            kdbp("mpt[%x] == %lx\n", mfn, machine_to_phys_mapping[mfn]);
+        else
+            kdbp("Invalid mfn:%lx\n", mfn);
+    else
+        kdb_usgf_m2p();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static void 
+kdb_pr_pg_pgt_flds(unsigned long type_info)
+{
+    switch (type_info & PGT_type_mask) {
+        case (PGT_l1_page_table):
+            kdbp("    page is PGT_l1_page_table\n");
+            break;
+        case PGT_l2_page_table:
+            kdbp("    page is PGT_l2_page_table\n");
+            break;
+        case PGT_l3_page_table:
+            kdbp("    page is PGT_l3_page_table\n");
+            break;
+        case PGT_l4_page_table:
+            kdbp("    page is PGT_l4_page_table\n");
+            break;
+        case PGT_seg_desc_page:
+            kdbp("    page is seg desc page\n");
+            break;
+        case PGT_writable_page:
+            kdbp("    page is writable page\n");
+            break;
+        case PGT_shared_page:
+            kdbp("    page is shared page\n");
+            break;
+    }
+    if (type_info & PGT_pinned)
+        kdbp("    page is pinned\n");
+    if (type_info & PGT_validated)
+        kdbp("    page is validated\n");
+    if (type_info & PGT_pae_xen_l2)
+        kdbp("    page is PGT_pae_xen_l2\n");
+    if (type_info & PGT_partial)
+        kdbp("    page is PGT_partial\n");
+    if (type_info & PGT_locked)
+        kdbp("    page is PGT_locked\n");
+}
+
+static void
+kdb_pr_pg_pgc_flds(unsigned long count_info)
+{
+    if (count_info & PGC_allocated)
+        kdbp("  PGC_allocated");
+    if (count_info & PGC_xen_heap)
+        kdbp("  PGC_xen_heap");
+    if (count_info & PGC_page_table)
+        kdbp("  PGC_page_table");
+    if (count_info & PGC_broken)
+        kdbp("  PGC_broken");
+#if XEN_VERSION < 4                                 /* xen 3.x.x */
+    if (count_info & PGC_offlining)
+        kdbp("  PGC_offlining");
+    if (count_info & PGC_offlined)
+        kdbp("  PGC_offlined");
+#else
+    if (count_info & PGC_state_inuse)
+        kdbp("  PGC_inuse");
+    if (count_info & PGC_state_offlining)
+        kdbp("  PGC_state_offlining");
+    if (count_info & PGC_state_offlined)
+        kdbp("  PGC_state_offlined");
+    if (count_info & PGC_state_free)
+        kdbp("  PGC_state_free");
+#endif
+    kdbp("\n");
+}
+
+/* print struct page_info{} given ptr to it or an mfn
+ * NOTE: that given an mfn there seems no way of knowing how it's used, so
+ *       here we just print all info and let user decide what's applicable */
+static kdb_cpu_cmd_t
+kdb_usgf_dpage(void)
+{
+    kdbp("dpage mfn|page-ptr : Display struct page\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dpage(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long val;
+    struct page_info *pgp;
+    struct domain *dp;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dpage();
+
+    if ((kdb_str2ulong(argv[1], &val) == 0)      ||
+        (val <  (ulong)frame_table && !mfn_valid(val))) {
+
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    kdbp("Page Info:\n");
+    if (val <= (ulong)frame_table) {       /* arg is mfn */
+        pgp = mfn_to_page(val);
+        kdbp("  mfn: %lx page_info:%p\n", val, pgp);
+    } else {
+        pgp = (struct page_info *)val; /* arg is struct page{} */
+        if (pgp < frame_table || pgp >= frame_table+max_page) {
+            kdbp("Invalid page ptr. below/beyond max_page\n");
+            return KDB_CPU_MAIN_KDB;
+        }
+        kdbp("  mfn: %lx page_info:%p\n", page_to_mfn(pgp), pgp);
+    } 
+    kdbp("  count_info: %016lx  (refcnt: %x)\n", pgp->count_info,
+         pgp->count_info & PGC_count_mask);
+#if XEN_VERSION > 3 || XEN_SUBVERSION > 3             /* xen 3.4.x or later */
+    kdb_pr_pg_pgc_flds(pgp->count_info);
+
+    kdbp("In use info:\n");
+    kdbp("  type_info:%016lx\n", pgp->u.inuse.type_info);
+    kdb_pr_pg_pgt_flds(pgp->u.inuse.type_info);
+    dp = page_get_owner(pgp);
+    kdbp("  domid:%d (pickled:%lx)\n", dp ? dp->domain_id : -1, 
+         pgp->v.inuse._domain);
+
+    kdbp("Shadow Info:\n");
+    kdbp("  type:%x pinned:%x count:%x\n", pgp->u.sh.type, pgp->u.sh.pinned,
+         pgp->u.sh.count);
+    kdbp("  back:%lx  shadow_flags:%x  next_shadow:%lx\n", pgp->v.sh.back,
+         pgp->shadow_flags, pgp->next_shadow);
+
+    kdbp("Free Info\n");
+    kdbp("  need_tlbflush:%d order:%d tlbflush_timestamp:%x\n",
+         pgp->u.free.need_tlbflush, pgp->v.free.order, 
+         pgp->tlbflush_timestamp);
+#else
+    if (pgp->count_info & PGC_allocated)            /* page allocated */
+        kdbp("  PGC_allocated");
+    if (pgp->count_info & PGC_page_table)           /* page table page */
+        kdbp("  PGC_page_table");
+    kdbp("\n");
+    kdbp("  page is %s xen heap page\n", is_xen_heap_page(pgp) ? "a":"NOT");
+    kdbp("  cacheattr:%x\n", (pgp->count_info>>PGC_cacheattr_base) & 7);
+    if (pgp->count_info & PGC_count_mask) {         /* page in use */
+        dp = pgp->u.inuse._domain;         /* pickled domain */
+        kdbp("  page is in use\n");
+        kdbp("    domid: %d  (pickled dom:%x)\n", 
+             dp ? (unpickle_domptr(dp))->domain_id : -1, dp);
+        kdbp("    type_info: %lx\n", pgp->u.inuse.type_info);
+        kdb_prt_pg_type(pgp->u.inuse.type_info);
+    } else {                                         /* page is free */
+        kdbp("  page is free\n");
+        kdbp("    order: %x\n", pgp->u.free.order);
+        kdbp("    cpumask: %lx\n", pgp->u.free.cpumask.bits);
+    }
+    kdbp("  tlbflush/shadow_flags: %lx\n", pgp->shadow_flags);
+#endif
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* display asked msr value */
+static kdb_cpu_cmd_t
+kdb_usgf_dmsr(void)
+{
+    kdbp("dmsr address : Display msr value\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_dmsr(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long addr, val;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_dmsr();
+
+    if ((kdb_str2ulong(argv[1], &addr) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+    rdmsrl(addr, val);
+    kdbp("msr: %lx  val:%lx\n", addr, val);
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_cpuid(void)
+{
+    kdbp("cpuid eax : Display cpuid value returned in rax\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_cpuid(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    unsigned long rax=0, rbx=0, rcx=0, rdx=0;
+
+    if (argc <= 1 || *argv[1] == '?') 
+        return kdb_usgf_cpuid();
+
+    if ((kdb_str2ulong(argv[1], &rax) == 0)) {
+        kdbp("Invalid arg:%s\n", argv[1]);
+        return KDB_CPU_MAIN_KDB;
+    }
+#if 0
+    __asm__ __volatile__ (
+            /* "pushl %%rax  \n" */
+
+            "movl %0, %%rax  \n"
+            "cpuid           \n" 
+            : "=&a" (rax), "=b" (rbx), "=c" (rcx), "=d" (rdx)
+            : "0" (rax)
+            : "rax", "rbx", "rcx", "rdx", "memory");
+#endif
+    cpuid(rax, &rax, &rbx, &rcx, &rdx);
+    kdbp("rax: %016lx  rbx:%016lx rcx:%016lx rdx:%016lx\n", rax, rbx,
+         rcx, rdx);
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* execute cpuid for given value */
+static kdb_cpu_cmd_t
+kdb_usgf_wept(void)
+{
+    kdbp("wept domid gfn: walk ept table for given domid and gfn\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_wept(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    ulong gfn;
+
+    if ((argc > 1 && *argv[1] == '?') || argc != 3)
+        return kdb_usgf_wept();
+    if ((dp=kdb_strdomid2ptr(argv[1], 1)) && kdb_str2ulong(argv[2], &gfn))
+        ept_walk_table(dp, gfn);
+    else
+        kdb_usgf_wept();
+
+    return KDB_CPU_MAIN_KDB;
+}
+
+/*
+ * Save symbols info for a guest, dom0 or other...
+ */
+static kdb_cpu_cmd_t
+kdb_usgf_sym(void)
+{
+   kdbp("sym domid &kallsyms_names &kallsyms_addresses &kallsyms_num_syms\n");
+   kdbp("\t [&kallsyms_token_table] [&kallsyms_token_index]\n");
+   kdbp("\ttoken _table and _index MUST be specified for el5\n");
+   return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_sym(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong namesp, addrap, nump, toktblp, tokidxp;
+    domid_t domid;
+
+    if (argc < 5) {
+        return kdb_usgf_sym();
+    }
+    toktblp = tokidxp = 0;     /* optional parameters */
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &namesp)   &&
+        kdb_str2ulong(argv[3], &addrap)   &&
+        kdb_str2ulong(argv[4], &nump)     && 
+        (argc==5 || (argc==7 && kdb_str2ulong(argv[5], &toktblp) &&
+                                kdb_str2ulong(argv[6], &tokidxp)))) {
+
+        kdb_sav_dom_syminfo(domid, namesp, addrap,nump,toktblp,tokidxp);
+    } else
+        kdb_usgf_sym();
+    return KDB_CPU_MAIN_KDB;
+}
+
+
+/* mods is the dumb ass &modules. modules is struct {nxt, prev}, and not ptr */
+static void
+kdb_dump_linux_modules(domid_t domid, ulong mods, uint nxtoffs, uint nmoffs, 
+                       uint coreoffs)
+{
+    const int bufsz = 56;
+    char buf[bufsz];
+    uint64_t addr, addrval, *nxtptr, *modptr;
+    uint i, num = 8;
+
+    if (kdb_guest_bitness(domid) == 32)
+        num = 4;
+
+    /* first read modules{}.next ptr */
+    if (kdb_read_mem(mods, (kdbbyt_t *)&nxtptr, num, domid) != num) {
+        kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+        return;
+    }
+
+    KDBGP("mods:%p nxtptr:%p nmoffs:%x coreoffs:%x\n", (void *)mods, nxtptr,
+          nmoffs, coreoffs);
+
+    while ((uint64_t)nxtptr != mods) {
+
+        modptr = (uint64_t *) ((ulong)nxtptr - nxtoffs);
+
+        addr = (ulong)modptr + coreoffs;
+        if (kdb_read_mem(addr, (kdbbyt_t *)&addrval, num, domid) != num) {
+            kdbp("ERROR: Could not read mod addr at :%p\n", (void *)addr);
+            return;
+        }
+
+        KDBGP("modptr:%p addr:%p\n", modptr, (void *)addr);
+        addr = (ulong)modptr + nmoffs;
+        i=0;
+        do {
+            if (kdb_read_mem(addr, (kdbbyt_t *)&buf[i], 1, domid) != 1) {
+                kdbp("ERROR:Could not read name ch at addr:%p\n", (void *)addr);
+                return;
+            }
+            addr++;
+        } while (buf[i] && i++ < bufsz);
+        buf[bufsz-1] = '\0';
+
+        kdbp("%016lx %016lx %s\n", modptr, addrval, buf);
+
+        if (kdb_read_mem((ulong)nxtptr, (kdbbyt_t *)&nxtptr, num, domid)!=num) {
+            kdbp("ERROR: Could not read next at mod:%p\n", (void *)mods);
+            return;
+        }
+        KDBGP("nxtptr:%p addr:%p\n", nxtptr, (void *)addr);
+    } 
+}
+
+/* Display modules loaded in linux guest */
+static kdb_cpu_cmd_t
+kdb_usgf_mod(void)
+{
+   kdbp("mod domid &modules next-offs name-offs module_core-offs\n");
+   kdbp("\twhere next-offs: &((struct module *)0)->list.next\n");
+   kdbp("\tname-offs: &((struct module *)0)->name etc..\n");
+   kdbp("\tDisplays all loaded modules in the linux guest\n");
+   kdbp("\tEg: mod 0 ffffffff80302780 8 0x18 0x178\n");
+
+   return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_cmdf_mod(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    ulong mods, nxtoffs, nmoffs, coreoffs;
+    domid_t domid;
+
+    if (argc < 6) {
+        return kdb_usgf_mod();
+    }
+    if (kdb_str2domid(argv[1], &domid, 1) &&
+        kdb_str2ulong(argv[2], &mods)     &&
+        kdb_str2ulong(argv[3], &nxtoffs)  &&
+        kdb_str2ulong(argv[4], &nmoffs)   &&
+        kdb_str2ulong(argv[5], &coreoffs)) {
+
+        kdbp("modptr address name\n");
+        kdb_dump_linux_modules(domid, mods, nxtoffs, nmoffs, coreoffs);
+    } else
+        kdb_usgf_mod();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* toggle kdb debug trace level */
+static kdb_cpu_cmd_t
+kdb_usgf_kdbdbg(void)
+{
+    kdbp("kdbdbg : trace info to debug kdb\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_kdbdbg(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_kdbdbg();
+
+    kdbdbg = (kdbdbg==3) ? 0 : (kdbdbg+1);
+    kdbp("kdbdbg set to:%d\n", kdbdbg);
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_reboot(void)
+{
+    kdbp("reboot: reboot system\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_reboot(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_reboot();
+
+    machine_restart(500);
+    return KDB_CPU_MAIN_KDB;              /* not reached */
+}
+
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcon(void)
+{
+    kdbp("trcon: turn user added kdb tracing on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcon(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcon();
+
+    kdb_trcon = 1;
+    kdbp("kdb tracing is now on\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcoff(void)
+{
+    kdbp("trcoff: turn user added kdb tracing off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcoff(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcoff();
+
+    kdb_trcon = 0;
+    kdbp("kdb tracing is now off\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcz(void)
+{
+    kdbp("trcz : zero entire trace buffer\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcz(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcz();
+
+    kdb_trczero();
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_trcp(void)
+{
+    kdbp("trcp : give hints to dump trace buffer via dw/dd command\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_trcp(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_trcp();
+
+    kdb_trcp();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* print some basic info, constants, etc.. */
+static kdb_cpu_cmd_t
+kdb_usgf_info(void)
+{
+    kdbp("info : display basic info, constants, etc..\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_info(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    struct domain *dp;
+    struct cpuinfo_x86 *bcdp;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_info();
+
+    kdbp("Version: %d.%d.%s (%s@%s) %s\n", xen_major_version(), 
+         xen_minor_version(), xen_extra_version(), xen_compile_by(), 
+         xen_compile_domain(), xen_compile_date());
+    kdbp("__XEN_LATEST_INTERFACE_VERSION__ : 0x%x\n", 
+         __XEN_LATEST_INTERFACE_VERSION__);
+    kdbp("__XEN_INTERFACE_VERSION__: 0x%x\n", __XEN_INTERFACE_VERSION__);
+
+    bcdp = &boot_cpu_data;
+    kdbp("CPU: (all decimal)");
+        if (bcdp->x86_vendor == X86_VENDOR_AMD)
+            kdbp(" AMD");
+        else
+            kdbp(" INTEL");
+        kdbp(" family:%d model:%d\n", bcdp->x86, bcdp->x86_model);
+        kdbp("     vendor_id:%16s model_id:%64s\n", bcdp->x86_vendor_id,
+             bcdp->x86_model_id);
+        kdbp("     cpuidlvl:%d cache:sz:%d align:%d\n", bcdp->cpuid_level,
+             bcdp->x86_cache_size, bcdp->x86_cache_alignment);
+        kdbp("     power:%d cores: max:%d booted:%d siblings:%d apicid:%d\n",
+             bcdp->x86_power, bcdp->x86_max_cores, bcdp->booted_cores,
+             bcdp->x86_num_siblings, bcdp->apicid);
+        kdbp("     ");
+        if (cpu_has_apic)
+            kdbp("_apic");
+        if (cpu_has_sep)
+            kdbp("|_sep");
+        if (cpu_has_xmm3)
+            kdbp("|_xmm3");
+        if (cpu_has_ht)
+            kdbp("|_ht");
+        if (cpu_has_nx)
+            kdbp("|_nx");
+        if (cpu_has_clflush)
+            kdbp("|_clflush");
+        if (cpu_has_page1gb)
+            kdbp("|_page1gb");
+        if (cpu_has_ffxsr)
+            kdbp("|_ffxsr");
+        if (cpu_has_x2apic)
+            kdbp("|_x2apic");
+    kdbp("\n\n");
+    kdbp("CC:");
+#if defined(CONFIG_X86_64)
+        kdbp(" CONFIG_X86_64");
+#endif
+#if defined(CONFIG_COMPAT)
+        kdbp(" CONFIG_COMPAT");
+#endif
+#if defined(CONFIG_PAGING_ASSISTANCE)
+        kdbp(" CONFIG_PAGING_ASSISTANCE");
+#endif
+    kdbp("\n");
+    kdbp("cpu has following features:\n");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ? 
+         "X86_FEATURE_TSC_RELIABLE" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_CONSTANT_TSC)? "X86_FEATURE_CONSTANT_TSC":"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ? "X86_FEATURE_NONSTOP_TSC" :"");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_RDTSCP) ?  "X86_FEATURE_RDTSCP" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_FXSR) ?  "X86_FEATURE_FXSR" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_CPUID_FAULTING) ?  
+         "X86_FEATURE_CPUID_FAULTING" : "");
+    kdbp("  %s\n", 
+         boot_cpu_has(X86_FEATURE_PAGE1GB) ?  "X86_FEATURE_PAGE1GB" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_MWAIT) ?  "X86_FEATURE_MWAIT" : "");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_X2APIC) ?  "X86_FEATURE_X2APIC":"");
+    kdbp("  %s\n", boot_cpu_has(X86_FEATURE_XSAVE) ?  "X86_FEATURE_XSAVE":"");
+    kdbp("\n");
+
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
+    kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
+    kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
+
+    kdbp("\nDomains and their vcpus:\n");
+    for_each_domain(dp) {
+        struct vcpu *vp;
+        int printed=0;
+        kdbp("  Domain: {id:%d 0x%x   ptr:%p%s}  VCPUs:\n", 
+             dp->domain_id, dp->domain_id, dp, dp->is_dying ? " DYING":"");
+        for(vp=dp->vcpu[0]; vp; vp = vp->next_in_list) {
+            kdbp("  {id:%d p:%p runstate:%d}", vp->vcpu_id, vp, 
+                 vp->runstate.state);
+            if (++printed % 2 == 0) kdbp("\n");
+        }
+        kdbp("\n");
+    }
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_cur(void)
+{
+    kdbp("cur : display current domid and vcpu\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* Checking for guest_mode() not feasible here. if dom0->hcall->bp in xen, 
+ * then g_m() will show xen, but vcpu is still dom0. hence just look at 
+ * current only */
+static kdb_cpu_cmd_t
+kdb_cmdf_cur(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    domid_t id = current->domain->domain_id;
+
+    if (argc > 1 && *argv[1] == '?')
+        return kdb_usgf_cur();
+
+    kdbp("domid: %d{%p} %s vcpu:%d {%p} ", id, current->domain,
+         (id==DOMID_IDLE) ? "(IDLE)" : "", current->vcpu_id, current);
+
+    /* if (id != DOMID_IDLE) { */
+        if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+            u64 addr = -1;
+            __vmptrst(&addr);
+            kdbp(" VMCS:"KDBFL, addr);
+        }
+    /* } */
+    kdbp("\n");
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* stub to quickly and easily add a new command */
+static kdb_cpu_cmd_t
+kdb_usgf_usr1(void)
+{
+    kdbp("usr1: add any arbitrary cmd using this in kdb_cmds.c\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_usr1(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    return KDB_CPU_MAIN_KDB;
+}
+
+static kdb_cpu_cmd_t
+kdb_usgf_h(void)
+{
+    kdbp("h: display all commands. See kdb/README for more info\n");
+    return KDB_CPU_MAIN_KDB;
+}
+static kdb_cpu_cmd_t
+kdb_cmdf_h(int argc, const char **argv, struct cpu_user_regs *regs)
+{
+    kdbtab_t *tbp;
+
+    kdbp(" - ccpu is current cpu \n");
+    kdbp(" - following are always in decimal:\n");
+    kdbp("     vcpu num, cpu num, domid\n");
+    kdbp(" - otherwise, almost all numbers are in hex (0x not needed)\n");
+    kdbp(" - output: $17 means decimal 17\n");
+    kdbp(" - domid 7fff($32767) refers to hypervisor\n");
+    kdbp(" - if no domid before function name, then it's hypervisor\n");
+    kdbp(" - earlykdb in xen grub line to break into kdb during boot\n");
+    kdbp(" - command ? will show the command usage\n");
+    kdbp("\n");
+
+    for(tbp=kdb_cmd_tbl; tbp->kdb_cmd_usgf; tbp++)
+        (*tbp->kdb_cmd_usgf)();
+    return KDB_CPU_MAIN_KDB;
+}
+
+/* ===================== cmd table initialization ========================== */
+void __init
+kdb_init_cmdtab(void)
+{
+  static kdbtab_t _kdb_cmd_table[] = {
+
+    {"info", kdb_cmdf_info, kdb_usgf_info, 1, KDB_REPEAT_NONE},
+    {"cur",  kdb_cmdf_cur, kdb_usgf_cur, 1, KDB_REPEAT_NONE},
+
+    {"f",  kdb_cmdf_f,  kdb_usgf_f,  1, KDB_REPEAT_NONE},
+    {"fg", kdb_cmdf_fg, kdb_usgf_fg, 1, KDB_REPEAT_NONE},
+
+    {"dw",  kdb_cmdf_dw,  kdb_usgf_dw,  1, KDB_REPEAT_NO_ARGS},
+    {"dd",  kdb_cmdf_dd,  kdb_usgf_dd,  1, KDB_REPEAT_NO_ARGS},
+    {"dwm", kdb_cmdf_dwm, kdb_usgf_dwm, 1, KDB_REPEAT_NO_ARGS},
+    {"ddm", kdb_cmdf_ddm, kdb_usgf_ddm, 1, KDB_REPEAT_NO_ARGS},
+    {"dr",  kdb_cmdf_dr,  kdb_usgf_dr,  1, KDB_REPEAT_NONE},
+    {"drg", kdb_cmdf_drg, kdb_usgf_drg, 1, KDB_REPEAT_NONE},
+
+    {"dis", kdb_cmdf_dis,  kdb_usgf_dis,  1, KDB_REPEAT_NO_ARGS},
+    {"dism",kdb_cmdf_dism, kdb_usgf_dism, 1, KDB_REPEAT_NO_ARGS},
+
+    {"mw", kdb_cmdf_mw, kdb_usgf_mw, 1, KDB_REPEAT_NONE},
+    {"md", kdb_cmdf_md, kdb_usgf_md, 1, KDB_REPEAT_NONE},
+    {"mr", kdb_cmdf_mr, kdb_usgf_mr, 1, KDB_REPEAT_NONE},
+
+    {"bc", kdb_cmdf_bc, kdb_usgf_bc, 0, KDB_REPEAT_NONE},
+    {"bp", kdb_cmdf_bp, kdb_usgf_bp, 1, KDB_REPEAT_NONE},
+    {"btp", kdb_cmdf_btp, kdb_usgf_btp, 1, KDB_REPEAT_NONE},
+
+    {"wp", kdb_cmdf_wp, kdb_usgf_wp, 1, KDB_REPEAT_NONE},
+    {"wc", kdb_cmdf_wc, kdb_usgf_wc, 0, KDB_REPEAT_NONE},
+
+    {"ni", kdb_cmdf_ni, kdb_usgf_ni, 0, KDB_REPEAT_NO_ARGS},
+    {"ss", kdb_cmdf_ss, kdb_usgf_ss, 1, KDB_REPEAT_NO_ARGS},
+    {"ssb",kdb_cmdf_ssb,kdb_usgf_ssb,0, KDB_REPEAT_NO_ARGS},
+    {"go", kdb_cmdf_go, kdb_usgf_go, 0, KDB_REPEAT_NONE},
+
+    {"cpu",kdb_cmdf_cpu, kdb_usgf_cpu, 1, KDB_REPEAT_NONE},
+    {"nmi",kdb_cmdf_nmi, kdb_usgf_nmi, 1, KDB_REPEAT_NONE},
+    {"percpu",kdb_cmdf_percpu, kdb_usgf_percpu, 1, KDB_REPEAT_NONE},
+
+    {"sym",  kdb_cmdf_sym,   kdb_usgf_sym,   1, KDB_REPEAT_NONE},
+    {"mod",  kdb_cmdf_mod,   kdb_usgf_mod,   1, KDB_REPEAT_NONE},
+
+    {"vcpuh",kdb_cmdf_vcpuh, kdb_usgf_vcpuh, 1, KDB_REPEAT_NONE},
+    {"vcpu", kdb_cmdf_vcpu,  kdb_usgf_vcpu,  1, KDB_REPEAT_NONE},
+    {"dom",  kdb_cmdf_dom,   kdb_usgf_dom,   1, KDB_REPEAT_NONE},
+
+    {"sched", kdb_cmdf_sched, kdb_usgf_sched, 1, KDB_REPEAT_NONE},
+    {"mmu",   kdb_cmdf_mmu,   kdb_usgf_mmu,   1, KDB_REPEAT_NONE},
+    {"p2m",   kdb_cmdf_p2m,   kdb_usgf_p2m,   1, KDB_REPEAT_NONE},
+    {"m2p",   kdb_cmdf_m2p,   kdb_usgf_m2p,   1, KDB_REPEAT_NONE},
+    {"dpage", kdb_cmdf_dpage, kdb_usgf_dpage, 1, KDB_REPEAT_NONE},
+    {"dmsr",  kdb_cmdf_dmsr,  kdb_usgf_dmsr, 1, KDB_REPEAT_NONE},
+    {"cpuid",  kdb_cmdf_cpuid,  kdb_usgf_cpuid, 1, KDB_REPEAT_NONE},
+    {"wept",  kdb_cmdf_wept,  kdb_usgf_wept, 1, KDB_REPEAT_NONE},
+
+    {"dtrq", kdb_cmdf_dtrq,  kdb_usgf_dtrq, 1, KDB_REPEAT_NONE},
+    {"didt", kdb_cmdf_didt,  kdb_usgf_didt, 1, KDB_REPEAT_NONE},
+    {"dgdt", kdb_cmdf_dgdt,  kdb_usgf_dgdt, 1, KDB_REPEAT_NONE},
+    {"dirq", kdb_cmdf_dirq,  kdb_usgf_dirq, 1, KDB_REPEAT_NONE},
+    {"dvit", kdb_cmdf_dvit,  kdb_usgf_dvit, 1, KDB_REPEAT_NONE},
+    {"dvmc", kdb_cmdf_dvmc,  kdb_usgf_dvmc, 1, KDB_REPEAT_NONE},
+    {"mmio", kdb_cmdf_mmio,  kdb_usgf_mmio, 1, KDB_REPEAT_NONE},
+
+    /* tracing related commands */
+    {"trcon", kdb_cmdf_trcon,  kdb_usgf_trcon,  0, KDB_REPEAT_NONE},
+    {"trcoff",kdb_cmdf_trcoff, kdb_usgf_trcoff, 0, KDB_REPEAT_NONE},
+    {"trcz",  kdb_cmdf_trcz,   kdb_usgf_trcz,   0, KDB_REPEAT_NONE},
+    {"trcp",  kdb_cmdf_trcp,   kdb_usgf_trcp,   1, KDB_REPEAT_NONE},
+
+    {"usr1",  kdb_cmdf_usr1,   kdb_usgf_usr1,   1, KDB_REPEAT_NONE},
+    {"kdbf",  kdb_cmdf_kdbf,   kdb_usgf_kdbf,   1, KDB_REPEAT_NONE},
+    {"kdbdbg",kdb_cmdf_kdbdbg, kdb_usgf_kdbdbg, 1, KDB_REPEAT_NONE},
+    {"reboot",kdb_cmdf_reboot, kdb_usgf_reboot, 1, KDB_REPEAT_NONE},
+    {"h",     kdb_cmdf_h,      kdb_usgf_h,      1, KDB_REPEAT_NONE},
+
+    {"", NULL, NULL, 0, 0},
+  };
+    kdb_cmd_tbl = _kdb_cmd_table;
+    return;
+}
diff -r 32034d1914a6 xen/kdb/kdb_io.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdb_io.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+#include "include/kdbinc.h"
+
+#define K_BACKSPACE  0x8                   /* ctrl-H */
+#define K_BACKSPACE1 0x7f                  /* ctrl-? */
+#define K_UNDERSCORE 0x5f
+#define K_CMD_BUFSZ  160
+#define K_CMD_MAXI   (K_CMD_BUFSZ - 1)     /* max index in buffer */
+
+#if 0        /* make a history array some day */
+#define K_UP_ARROW                         /* sequence : 1b 5b 41 ie, '\e[A' */
+#define K_DN_ARROW                         /* sequence : 1b 5b 42 ie, '\e[B' */
+#define K_NUM_HIST   32
+static int cursor;
+static char cmds_a[NUM_HIST][K_CMD_BUFSZ];
+#endif
+
+static char cmds_a[K_CMD_BUFSZ];
+
+
+static int
+kdb_key_valid(int key)
+{
+    /* note: isspace() is more than ' ', hence we don't use it here */
+    if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
+            return 1;
+    return 0;
+}
+
+/* display kdb prompt and read command from the console 
+ * RETURNS: a '\n' terminated command buffer */
+char *
+kdb_get_cmdline(char *prompt)
+{
+    #define K_BELL     0x7
+    #define K_CTRL_C   0x3
+
+    int key, i=0;
+
+    kdbp(prompt);
+    memset(cmds_a, 0, K_CMD_BUFSZ);
+    cmds_a[K_CMD_BUFSZ-1] = '\n';
+
+    do {
+        key = console_getc();
+        if (key == '\r') 
+            key = '\n';
+        if (key == K_BACKSPACE1) 
+            key = K_BACKSPACE;
+
+        if (key == K_CTRL_C || (i==K_CMD_MAXI && key != '\n')) {
+            console_putc('\n');
+            if (i >= K_CMD_MAXI) {
+                kdbp("KDB: cmd buffer overflow\n");
+                console_putc(K_BELL);
+            }
+            memset(cmds_a, 0, K_CMD_BUFSZ);
+            i = 0;
+            kdbp(prompt);
+            continue;
+        }
+        if (!kdb_key_valid(key)) {
+            console_putc(K_BELL);
+            continue;
+        }
+        if (key == K_BACKSPACE) {
+            if (i==0) {
+                console_putc(K_BELL);
+                continue;
+            } else 
+                cmds_a[--i] = '\0';
+                console_putc(K_BACKSPACE);
+                console_putc(' ');        /* erase character */
+        } else
+            cmds_a[i++] = key;
+
+        console_putc(key);
+
+    } while (key != '\n');
+
+    return cmds_a;
+}
+
+/*
+ * printk takes a lock, an NMI could come in after that, and another cpu may 
+ * spin. also, the console lock is forced unlock, so panic is been seen on 
+ * 8 way. hence, no printk() calls.
+ */
+static volatile int kdbp_gate = 0;
+void
+kdbp(const char *fmt, ...)
+{
+    static char buf[1024];
+    va_list args;
+    char *p;
+    int i=0;
+
+    while ((__cmpxchg(&kdbp_gate, 0,1, sizeof(kdbp_gate)) != 0) && i++<1000)
+        mdelay(10);
+
+    va_start(args, fmt);
+    (void)vsnprintf(buf, sizeof(buf), fmt, args);
+    va_end(args);
+
+    for (p=buf; *p != '\0'; p++)
+        console_putc(*p);
+    kdbp_gate = 0;
+}
+
+
+/*
+ * copy/read machine memory. 
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mmem(kdbma_t maddr, kdbbyt_t *dbuf, int len)
+{
+    ulong remain, orig=len;
+
+    while (len > 0) {
+        ulong pagecnt = min_t(long, PAGE_SIZE-(maddr&~PAGE_MASK), len);
+        char *va = map_domain_page(maddr >> PAGE_SHIFT);
+
+        va = va + (maddr & (PAGE_SIZE-1));        /* add page offset */
+        remain = __copy_from_user(dbuf, (void *)va, pagecnt);
+        KDBGP1("maddr:%x va:%p len:%x pagecnt:%x rem:%x\n", 
+               maddr, va, len, pagecnt, remain);
+        unmap_domain_page(va);
+        len = len  - (pagecnt - remain);
+        if (remain != 0)
+            break;
+        maddr += pagecnt;
+        dbuf += pagecnt;
+    }
+    return orig - len;
+}
+
+
+/*
+ * copy/read guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes copied 
+ */
+int
+kdb_read_mem(kdbva_t saddr, kdbbyt_t *dbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(saddr, dbuf, len, domid, 0, 0));
+}
+
+/*
+ * write guest or hypervisor memory. (domid == DOMID_IDLE) => hyp
+ * RETURNS: number of bytes written
+ */
+int
+kdb_write_mem(kdbva_t daddr, kdbbyt_t *sbuf, int len, domid_t domid)
+{
+    return (len - dbg_rw_mem(daddr, sbuf, len, domid, 1, 0));
+}
diff -r 32034d1914a6 xen/kdb/kdbmain.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/kdbmain.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,757 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "include/kdbinc.h"
+
+static int kdbmain(kdb_reason_t, struct cpu_user_regs *);
+static int kdbmain_fatal(struct cpu_user_regs *, int);
+static const char *kdb_gettrapname(int);
+
+/* ======================== GLOBAL VARIABLES =============================== */
+/* All global variables used by KDB must be defined here only. Module specific
+ * static variables must be declared in respective modules.
+ */
+kdbtab_t *kdb_cmd_tbl;
+char kdb_prompt[32];
+
+volatile kdb_cpu_cmd_t kdb_cpu_cmd[NR_CPUS];
+cpumask_t kdb_cpu_traps;           /* bit per cpu to tell which cpus hit int3 */
+
+#ifndef NDEBUG
+    #error KDB is not supported on debug xen. Turn debug off
+#endif
+
+volatile int kdb_init_cpu = -1;           /* initial kdb cpu */
+volatile int kdb_session_begun = 0;       /* active kdb session? */
+volatile int kdb_enabled = 1;             /* kdb enabled currently? */
+volatile int kdb_sys_crash = 0;           /* are we in crashed state? */
+volatile int kdbdbg = 0;                  /* to debug kdb itself */
+
+static volatile int kdb_trap_immed_reason = 0;   /* reason for immed trap */
+
+static cpumask_t kdb_fatal_cpumask;       /* which cpus in fatal path */
+
+/* return index of first bit set in val. if val is 0, retval is undefined */
+static inline unsigned int kdb_firstbit(unsigned long val)
+{
+    __asm__ ( "bsf %1,%0" : "=r" (val) : "r" (val), "0" (BITS_PER_LONG) );
+    return (unsigned int)val;
+}
+
+void noinline mukchk(unsigned long ul)
+{
+}
+
+static void 
+kdb_dbg_prnt_ctrps(char *label, int ccpu)
+{
+    int i;
+    if (!kdbdbg)
+        return;
+
+    if (label || *label)
+        kdbp("%s ", label);
+    if (ccpu != -1)
+        kdbp("ccpu:%d ", ccpu);
+    kdbp("cputrps:");
+    for (i=sizeof(kdb_cpu_traps)/sizeof(kdb_cpu_traps.bits[0]) - 1; i >=0; i--)
+        kdbp(" %lx", kdb_cpu_traps.bits[i]);
+    kdbp("\n");
+}
+
+/* 
+ * Hold this cpu. Don't disable until all CPUs in kdb to avoid IPI deadlock 
+ */
+static void
+kdb_hold_this_cpu(int ccpu, struct cpu_user_regs *regs)
+{
+    KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+    do {
+        for(; kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE; cpu_relax());
+        KDBGP("ccpu:%d hold. cmd:%x\n", kdb_cpu_cmd[ccpu]);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DISABLE) {
+            local_irq_disable();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DO_VMEXIT) {
+            kdb_curr_cpu_flush_vmcs();
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_SHOWPC) {
+            kdbp("[%d]", ccpu);
+            kdb_display_pc(regs);
+            kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+        }
+    } while (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE);     /* No goto, eh! */
+    KDBGP1("un hold: ccpu:%d cmd:%d\n", ccpu, kdb_cpu_cmd[ccpu]);
+}
+
+/*
+ * Pause this cpu while one CPU does main kdb processing. If that CPU does
+ * a "cpu switch" to this cpu, this cpu will become the main kdb cpu. If the
+ * user next does single step of some sort, this function will be exited,
+ * and this cpu will come back into kdb via kdb_handle_trap_entry function.
+ */
+static void 
+kdb_pause_this_cpu(struct cpu_user_regs *regs, void *unused)
+{
+    kdbmain(KDB_REASON_PAUSE_IPI, regs);
+}
+
+/* pause other cpus via an IPI. Note, disabled CPUs can't receive IPIs until
+ * enabled */
+static void
+kdb_smp_pause_cpus(void)
+{
+    int cpu, wait_count = 0;
+    int ccpu = smp_processor_id();      /* current cpu */
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL) {
+            kdbp("KDB: won't pause cpu:%d, cmd[cpu]=%d\n",cpu,kdb_cpu_cmd[cpu]);
+            cpumask_clear_cpu(cpu, &cpumask);
+        }
+    KDBGP("ccpu:%d will pause cpus. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+    on_selected_cpus(&cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0);
+#else
+    on_selected_cpus(cpumask, (void (*)(void *))kdb_pause_this_cpu, 
+                     "XENKDB", 0, 0);
+#endif
+    mdelay(300);                     /* wait a bit for other CPUs to stop */
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+                bummer = 1;
+        if (!bummer)
+            break;
+        kdbp("ccpu:%d trying to stop other cpus...\n", ccpu);
+        mdelay(100);  /* wait 100 ms */
+    };
+    for_each_cpu(cpu, &cpumask)          /* now check who is with us */
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE)
+            kdbp("Bummer cpu %d not paused. ccpu:%d\n", cpu,ccpu);
+        else {
+            kdb_cpu_cmd[cpu] = KDB_CPU_DISABLE;  /* tell it to disable ints */
+            while (kdb_cpu_cmd[cpu] != KDB_CPU_PAUSE);
+        }
+}
+
+/* 
+ * Do once per kdb session:  A kdb session lasts from 
+ *    keybord/HWBP/SWBP till KDB_CPU_INSTALL_BP is done. Within a session,
+ *    user may do several cpu switches, single step, next instr,  etc..
+ *
+ * DO: 1. pause other cpus if they are not already. they would already be 
+ *        if we are in single step mode
+ *     2. watchdog_disable() 
+ *     3. uninstall all sw breakpoints so that user doesn't see them
+ */
+static void
+kdb_begin_session(void)
+{
+    if (!kdb_session_begun) {
+        kdb_session_begun = 1;
+        kdb_smp_pause_cpus();
+        local_irq_disable();
+        watchdog_disable();
+        kdb_uninstall_all_swbp();
+    }
+}
+
+int noinline mukid(void)
+{
+    return smp_processor_id();
+}
+
+static void
+kdb_smp_unpause_cpus(int ccpu)
+{
+    int cpu;
+
+    int wait_count = 0;
+    cpumask_t cpumask = cpu_online_map;
+
+    cpumask_clear_cpu(smp_processor_id(), &cpumask);
+
+    KDBGP("kdb_smp_unpause_other_cpus(). ccpu:%d\n", ccpu);
+    for_each_cpu(cpu, &cpumask)
+        kdb_cpu_cmd[cpu] = KDB_CPU_QUIT;
+
+    while(wait_count++ < 10) {
+        int bummer = 0;
+        for_each_cpu(cpu, &cpumask)
+            if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+                bummer = 1;
+            if (!bummer)
+                break;
+            mdelay(90);  /* wait 90 ms, 50 too short on large systems */
+    };
+    /* now make sure they are all in there */
+    for_each_cpu(cpu, &cpumask)
+        if (kdb_cpu_cmd[cpu] != KDB_CPU_INVAL)
+            kdbp("KDB: cpu %d still paused (cmd==%d). ccpu:%d\n",
+                 cpu, kdb_cpu_cmd[cpu], ccpu);
+}
+
+/*
+ * End of KDB session. 
+ *   This is called at the very end. In case of multiple cpus hitting BPs
+ *   and sitting on a trap handlers, the last cpu to exit will call this.
+ *   - isnstall all sw breakpoints, and purge deleted ones from table.
+ *   - clear TF here also in case go is entered on a different cpu after switch
+ */
+static void
+kdb_end_session(int ccpu, struct cpu_user_regs *regs)
+{
+    ASSERT(!cpumask_empty(&kdb_cpu_traps));
+    ASSERT(kdb_session_begun);
+    kdb_install_all_swbp();
+    kdb_flush_swbp_table();
+    kdb_install_watchpoints();
+
+    regs->eflags &= ~X86_EFLAGS_TF;
+    kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    kdb_time_resume(1);
+    kdb_session_begun = 0;      /* before unpause for kdb_install_watchpoints */
+    kdb_smp_unpause_cpus(ccpu);
+    watchdog_enable();
+    KDBGP("end_session:ccpu:%d\n", ccpu);
+}
+volatile int mukwpprnt;
+unsigned long mukaddr1 = 0xffffffff81243ae7, mukaddr2 = 0xffffffff8100986e;
+/* 
+ * check if we entered kdb because of DB trap. If yes, then check if
+ * we caused it or someone else.
+ * RETURNS: 0 : not one of ours. hypervisor must handle it. 
+ *          1 : #DB for delayed sw bp install. 
+ *          2 : this cpu must stay in kdb.
+ */
+static noinline int
+kdb_check_dbtrap(kdb_reason_t *reasp, int ss_mode, struct cpu_user_regs *regs) 
+{
+    int rc = 2;
+    int ccpu = smp_processor_id();
+
+    /* DB excp caused by hw breakpoint or the TF flag. The TF flag is set
+     * by us for ss mode or to install breakpoints. In ss mode, none of the
+     * breakpoints are installed. Check to make sure we intended BP INSTALL
+     * so we don't do it on a spurious DB trap.
+     * check for kdb_cpu_traps here also, because each cpu sitting on a trap
+     * must execute the instruction without the BP before passing control
+     * to next cpu in kdb_cpu_traps.
+     */
+    if (*reasp == KDB_REASON_DBEXCP && !ss_mode) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP) {
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                *reasp = KDB_REASON_PAUSE_IPI;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
+                kdb_init_cpu = -1;
+            } else {
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            }
+        } else if (! kdb_check_watchpoints(regs)) {
+            rc = 0;                        /* hyp must handle it */
+        } else {
+            if (regs->rip==mukaddr1 || regs->rip==mukaddr2)
+            {
+                if (mukwpprnt)
+                    kdbp("MUK: ignoring wp:%lx\n", regs->rip);
+                kdb_end_session(ccpu, regs);
+                rc = 1;
+            } 
+        }
+    }
+    return rc;
+}
+
+/* 
+ * Misc processing on kdb entry like displaying PC, adjust IP for sw bp.... 
+ */
+static void
+kdb_main_entry_misc(kdb_reason_t reason, struct cpu_user_regs *regs, 
+                    int ccpu, int ss_mode, int enabled)
+{
+    if (reason == KDB_REASON_KEYBOARD)
+        kdbp("\nEnter kdb (cpu:%d reason:%d vcpu=%d domid:%d"
+             " eflg:0x%lx irqs:%d)\n", ccpu, reason, current->vcpu_id, 
+             current->domain->domain_id, regs->eflags, enabled);
+    else if (ss_mode)
+        KDBGP1("KDBG: KDB single step mode. ccpu:%d\n", ccpu);
+
+    if (reason == KDB_REASON_BPEXCP && !ss_mode) 
+        kdbp("Breakpoint on cpu %d at 0x%lx\n", ccpu, regs->KDBIP);
+
+    /* display the current PC and instruction at it */
+    if (reason != KDB_REASON_PAUSE_IPI)
+        kdb_display_pc(regs);
+    console_start_sync();
+}
+
+/* 
+ * The MAIN kdb function. All cpus go thru this. IRQ is enabled on entry because
+ * a cpu could hit a bp set in disabled code.
+ * IPI: Even the main cpu must enable in case another CPU is trying to IPI us.
+ *      That way, it would IPI us, then get out and be ready for our pause IPI.
+ * IRQs: The reason irqs enable/disable is scattered is because on a typical
+ *       system IPIs are constantly going on amongs CPUs in a set of any size. 
+ *       As a result,  to avoid deadlock, cpus have to loop enabled, until a 
+ *       quorum is established and the session has begun.
+ * Step: Intel Vol3B 18.3.1.4 : An external interrupt may be serviced upon
+ *       single step. Since, the likely ext timer_interrupt and 
+ *       apic_timer_interrupt dont' mess with time data structs, we are prob OK
+ *       leaving enabled.
+ * Time: Very messy. Most platform timers are readonly, so we can't stop time
+ *       in the debugger. We take the only resort, let the TSC and plt run as
+ *       normal, upon leaving, "attempt" to bring everybody to current time.
+ * kdbcputraps: bit per cpu. each cpu sets it bit in entry.S. The bit is 
+ *              reliable because upon traps, Ints are disabled. the bit is set
+ *              before Ints are enabled.
+ *
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+static int
+kdbmain(kdb_reason_t reason, struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();                /* current cpu */
+    int rc = 1, cmd = kdb_cpu_cmd[ccpu];
+    int ss_mode = (cmd == KDB_CPU_SS || cmd == KDB_CPU_NI);
+    int delayed_install = (kdb_cpu_cmd[ccpu] == KDB_CPU_INSTALL_BP);
+    int enabled = local_irq_is_enabled();
+
+    KDBGP("kdbmain:ccpu:%d rsn:%d eflgs:0x%lx cmd:%d initc:%d irqs:%d "
+          "regs:%lx IP:%lx ", ccpu, reason, regs->eflags, cmd, 
+          kdb_init_cpu, enabled, regs, regs->KDBIP);
+    kdb_dbg_prnt_ctrps("", -1);
+
+    if (!ss_mode && !delayed_install)    /* initial kdb enter */
+        local_irq_enable();              /* so we can receive IPI */
+
+    if (!ss_mode && ccpu != kdb_init_cpu && reason != KDB_REASON_PAUSE_IPI){
+        int sz = sizeof(kdb_init_cpu);
+        while (__cmpxchg(&kdb_init_cpu, -1, ccpu, sz) != -1)
+            for(; kdb_init_cpu != -1; cpu_relax());
+    }
+    if (kdb_session_begun)
+        local_irq_disable();             /* kdb always runs disabled */
+
+    if (reason == KDB_REASON_BPEXCP) {             /* INT 3 */
+        cpumask_clear_cpu(ccpu, &kdb_cpu_traps);   /* remove ourself */
+        rc = kdb_check_sw_bkpts(regs);
+        if (rc == 0) {               /* not one of ours. leave kdb */
+            kdb_init_cpu = -1;
+            goto out;
+        } else if (rc == 1) {        /* one of ours but deleted */
+            if (cpumask_empty(&kdb_cpu_traps)) {
+                kdb_end_session(ccpu,regs);     
+                kdb_init_cpu = -1;
+                goto out;
+            } else {                 
+                /* release another trap cpu, and put ourself in a pause mode */
+                int a_trap_cpu = cpumask_first(&kdb_cpu_traps);
+                KDBGP("ccpu:%d cmd:%d rsn:%d atrpcpu:%d initcpu:%d\n", ccpu, 
+                      kdb_cpu_cmd[ccpu], reason, a_trap_cpu, kdb_init_cpu);
+                kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
+                reason = KDB_REASON_PAUSE_IPI;
+                kdb_init_cpu = -1;
+            }
+        } else if (rc == 2) {        /* one of ours but condition not met */
+                kdb_begin_session();
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+        }
+    }
+
+    /* following will take care of KDB_CPU_INSTALL_BP, and also release
+     * kdb_init_cpu. it should not be done twice */
+    if ((rc=kdb_check_dbtrap(&reason, ss_mode, regs)) == 0 || rc == 1) {
+        kdb_init_cpu = -1;       /* leaving kdb */
+        goto out;                /* rc properly set to 0 or 1 */
+    }
+    if (reason != KDB_REASON_PAUSE_IPI) {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+    } else
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB && !ss_mode)
+        kdb_begin_session(); 
+
+    kdb_main_entry_misc(reason, regs, ccpu, ss_mode, enabled);
+    /* note, one or more cpu switches may occur in between */
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+            if (ccpu != kdb_init_cpu) {
+                kdb_cpu_cmd[kdb_init_cpu] = KDB_CPU_GO;
+                kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+                continue;               /* for the pause guy */
+            }
+            if (!cpumask_empty(&kdb_cpu_traps)) {
+                /* execute current instruction without 0xcc */
+                kdb_dbg_prnt_ctrps("nempty:", ccpu);
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            }
+        }
+        if (kdb_cpu_cmd[ccpu] != KDB_CPU_PAUSE  && 
+            kdb_cpu_cmd[ccpu] != KDB_CPU_MAIN_KDB)
+                break;
+    }
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_GO) {
+        ASSERT(cpumask_empty(&kdb_cpu_traps));
+        if (kdb_swbp_exists()) {
+            if (reason == KDB_REASON_BPEXCP) {
+                /* do delayed install */
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
+                kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
+                goto out;
+            } 
+        }
+        kdb_end_session(ccpu, regs);
+        kdb_init_cpu = -1;
+    }
+out:
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_QUIT) {
+        KDBGP("ccpu:%d _quit IP: %lx\n", ccpu, regs->KDBIP);
+        if (! kdb_session_begun)
+            kdb_install_watchpoints();
+        kdb_time_resume(0);
+        kdb_cpu_cmd[ccpu] = KDB_CPU_INVAL;
+    }
+
+    /* for ss and delayed install, TF is set. not much in EXT INT handlers*/
+    if (kdb_cpu_cmd[ccpu] == KDB_CPU_NI)
+        kdb_time_resume(1);
+    if (enabled)
+        local_irq_enable();
+
+    KDBGP("kdbmain:X:ccpu:%d rc:%d cmd:%d eflg:0x%lx initc:%d sesn:%d " 
+          "cs:%x irqs:%d ", ccpu, rc, kdb_cpu_cmd[ccpu], regs->eflags, 
+          kdb_init_cpu, kdb_session_begun, regs->cs, local_irq_is_enabled());
+    kdb_dbg_prnt_ctrps("", -1);
+    return (rc ? 1 : 0);
+}
+
+/* 
+ * kdb entry function when coming in via a keyboard
+ * RETURNS: 0 : kdb was called for event it was not responsible
+ *          1 : event owned and handled by kdb 
+ */
+int
+kdb_keyboard(struct cpu_user_regs *regs)
+{
+    return kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+
+#if 0
+/*
+ * this function called when kdb session active and user presses ctrl\ again.
+ * the assumption is that the user typed ni/ss cmd, and it never got back into
+ * kdb, or the user is impatient. Either case, we just fake it that the SS did
+ * finish. Since, all other kdb cpus must be holding disabled, the interrupt
+ * would be on the CPU that did the ss/ni cmd
+ */
+void
+kdb_ssni_reenter(struct cpu_user_regs *regs)
+{
+    int ccpu = smp_processor_id();
+    int ccmd = kdb_cpu_cmd[ccpu];
+
+    if(ccmd == KDB_CPU_SS || ccmd == KDB_CPU_INSTALL_BP)
+        kdbmain(KDB_REASON_DBEXCP, regs); 
+    else 
+        kdbmain(KDB_REASON_KEYBOARD, regs);
+}
+#endif
+
+/* 
+ * All traps are routed thru here. We care about BP (#3) trap (INT 3) and
+ * the DB trap(#1) only. 
+ * returns: 0 kdb has nothing do with this trap
+ *          1 kdb handled this trap 
+ */
+int
+kdb_handle_trap_entry(int vector, struct cpu_user_regs *regs)
+{
+    int rc = 0;
+    int ccpu = smp_processor_id();
+
+    if (vector == TRAP_int3) {
+        rc = kdbmain(KDB_REASON_BPEXCP, regs);
+
+    } else if (vector == TRAP_debug) {
+        KDBGP("ccpu:%d trapdbg reas:%d\n", ccpu, kdb_trap_immed_reason);
+
+        if (kdb_trap_immed_reason == KDB_TRAP_FATAL) { 
+            KDBGP("kdbtrp:fatal ccpu:%d vec:%d\n", ccpu, vector);
+            rc = kdbmain_fatal(regs, vector);
+            BUG();                             /* no return */
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_KDBSTACK) {
+            kdb_trap_immed_reason = 0;         /* show kdb stack */
+            show_registers(regs);
+            show_stack(regs);
+            regs->eflags &= ~X86_EFLAGS_TF;
+            rc = 1;
+
+        } else if (kdb_trap_immed_reason == KDB_TRAP_NONFATAL) {
+            kdb_trap_immed_reason = 0;
+            rc = kdb_keyboard(regs);
+        } else {                         /* ss/ni/delayed install... */
+            if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                current->arch.hvm_vcpu.single_step = 0;
+            rc = kdbmain(KDB_REASON_DBEXCP, regs); 
+        }
+
+    } else if (vector == TRAP_nmi) {                   /* external nmi */
+        /* when nmi is pressed, it could go to one or more or all cpus
+         * depending on the hardware. Also, for now assume it's fatal */
+        KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
+        rc = kdbmain_fatal(regs, TRAP_nmi);
+    } 
+    return rc;
+}
+
+int
+kdb_trap_fatal(int vector, struct cpu_user_regs *regs)
+{
+    kdbmain_fatal(regs, vector);
+    return 0;
+}
+
+/* From smp_send_nmi_allbutself() in crash.c which is static */
+void
+kdb_nmi_pause_cpus(cpumask_t cpumask)
+{
+    int ccpu = smp_processor_id();
+    mdelay(200);
+    cpumask_complement(&cpumask, &cpumask);              /* flip bit map */
+    cpumask_and(&cpumask, &cpumask, &cpu_online_map);    /* remove extra bits */
+    cpumask_clear_cpu(ccpu, &cpumask);/* absolutely make sure we're not on it */
+
+    KDBGP("ccpu:%d nmi pause. mask:0x%lx\n", ccpu, cpumask.bits[0]);
+    if ( !cpumask_empty(&cpumask) )
+#if XEN_SUBVERSION > 4 || XEN_VERSION == 4              /* xen 3.5.x or above */
+        send_IPI_mask(&cpumask, APIC_DM_NMI);
+#else
+        send_IPI_mask(cpumask, APIC_DM_NMI);
+#endif
+    mdelay(200);
+    KDBGP("ccpu:%d nmi pause done...\n", ccpu);
+}
+
+/* 
+ * Separate function from kdbmain to keep both within sanity levels.
+ */
+DEFINE_SPINLOCK(kdb_fatal_lk);
+static int
+kdbmain_fatal(struct cpu_user_regs *regs, int vector)
+{
+    int ccpu = smp_processor_id();
+
+    console_start_sync();
+
+    KDBGP("mainf:ccpu:%d vec:%d irq:%d\n", ccpu, vector,local_irq_is_enabled());
+    cpumask_set_cpu(ccpu, &kdb_fatal_cpumask);        /* uses LOCK_PREFIX */
+
+    if (spin_trylock(&kdb_fatal_lk)) {
+
+        kdbp("*** kdb (Fatal Error on cpu:%d vec:%d %s):\n", ccpu,
+             vector, kdb_gettrapname(vector));
+        kdb_cpu_cmd[ccpu] = KDB_CPU_MAIN_KDB;
+        kdb_display_pc(regs);
+
+        watchdog_disable();     /* important */
+        kdb_sys_crash = 1;
+        kdb_session_begun = 0;  /* incase session already active */
+        local_irq_enable();
+        kdb_nmi_pause_cpus(kdb_fatal_cpumask);
+
+        kdb_clear_prev_cmd();   /* buffered CRs will repeat prev cmd */
+        kdb_session_begun = 1;  /* for kdb_hold_this_cpu() */
+        local_irq_disable();
+    } else {
+        kdb_cpu_cmd[ccpu] = KDB_CPU_PAUSE;
+    }
+    while (1) {
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_PAUSE)
+            kdb_hold_this_cpu(ccpu, regs);
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_MAIN_KDB)
+            kdb_do_cmds(regs);
+#if 0
+        /* dump is the only way to exit in crashed state */
+        if (kdb_cpu_cmd[ccpu] == KDB_CPU_DUMP)
+            kdb_do_dump(regs);
+#endif
+    }
+    return 0;
+}
+
+/* Mostly called in fatal cases. earlykdb calls non-fatal.
+ * kdb_trap_immed_reason is global, so allow only one cpu at a time. Also,
+ * multiple cpu may be crashing at the same time. We enable because if there
+ * is a bad hang, at least ctrl-\ will break into kdb. Also, we don't call
+ * call kdb_keyboard directly becaue we don't have the register context.
+ */
+DEFINE_SPINLOCK(kdb_immed_lk);
+void
+kdb_trap_immed(int reason)            /* fatal, non-fatal, kdb stack etc... */
+{
+    int ccpu = smp_processor_id();
+    int disabled = !local_irq_is_enabled();
+
+    KDBGP("trapimm:ccpu:%d reas:%d\n", ccpu, reason);
+    local_irq_enable();
+    spin_lock(&kdb_immed_lk);
+    kdb_trap_immed_reason = reason;
+    barrier();
+    __asm__ __volatile__ ( "int $1" );
+    kdb_trap_immed_reason = 0;
+
+    spin_unlock(&kdb_immed_lk);
+    if (disabled)
+        local_irq_disable();
+}
+
+/* called very early during init, even before all CPUs are brought online */
+void 
+kdb_init(void)
+{
+        kdb_init_cmdtab();      /* Initialize Command Table */
+}
+
+static const char *
+kdb_gettrapname(int trapno)
+{
+    char *ret;
+    switch (trapno) {
+        case  0:  ret = "Divide Error"; break;
+        case  2:  ret = "NMI Interrupt"; break;
+        case  3:  ret = "Int 3 Trap"; break;
+        case  4:  ret = "Overflow Error"; break;
+        case  6:  ret = "Invalid Opcode"; break;
+        case  8:  ret = "Double Fault"; break;
+        case 10:  ret = "Invalid TSS"; break;
+        case 11:  ret = "Segment Not Present"; break;
+        case 12:  ret = "Stack-Segment Fault"; break;
+        case 13:  ret = "General Protection"; break;
+        case 14:  ret = "Page Fault"; break;
+        case 17:  ret = "Alignment Check"; break;
+        default: ret = " ????? ";
+    }
+    return ret;
+}
+
+
+/* ====================== Generic tracing subsystem ======================== */
+
+#define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
+                           * is 32 bytes */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
+
+typedef struct {
+    union {
+        struct { uint d0; uint cpu_trcid; } s0;
+        uint64_t l0;
+    }u;
+    uint64_t l1, l2, l3; 
+} trc_rec_t;
+
+static volatile unsigned int trcidx;    /* points to where new entry will go */
+static trc_rec_t trca[KDBTRCMAX];       /* trace array */
+
+/* atomically: add i to *p, return prev value of *p (ie, val before add) */
+static int
+kdb_fetch_and_add(int i, uint *p)
+{
+    asm volatile("lock xaddl %0, %1;" : "=r"(i) : "m"(*p), "0"(i));
+    return i;
+}
+
+/* zero out the entire buffer */
+void 
+kdb_trczero(void)
+{
+    for (trcidx = KDBTRCMAX-1; trcidx; trcidx--) {
+        memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    }
+    memset(&trca[trcidx], 0, sizeof(trc_rec_t));
+    kdbp("kdb trace buffer has been zeroed\n");
+}
+
+/* add trace entry: eg.: kdbtrc(0xe0f099, intdata, vcpu, domain, 0)
+ *    where:  0xe0f099 : 24bits max trcid, lower 8 bits are set to cpuid */
+void
+kdbtrc(uint trcid, uint int_d0, uint64_t d1_64, uint64_t d2_64, uint64_t d3_64)
+{
+    uint idx;
+
+    if (!kdb_trcon)
+        return;
+
+    idx = kdb_fetch_and_add(1, (uint*)&trcidx);
+    idx = idx % KDBTRCMAX;
+
+#if 0
+    trca[idx].u.s0.cpu_trcid = (smp_processor_id()<<24) | trcid;
+#endif
+    trca[idx].u.s0.cpu_trcid = (trcid<<8) | smp_processor_id();
+    trca[idx].u.s0.d0 = int_d0;
+    trca[idx].l1 = d1_64;
+    trca[idx].l2 = d2_64;
+    trca[idx].l3 = d3_64;
+}
+
+/* give hints so user can print trc buffer via the dd command. last has the
+ * most recent entry */
+void
+kdb_trcp(void)
+{
+    int i = trcidx % KDBTRCMAX;
+
+    i = (i==0) ? KDBTRCMAX-1 : i-1;
+    kdbp("trcbuf:    [0]: %016lx [MAX-1]: %016lx\n", &trca[0],
+         &trca[KDBTRCMAX-1]);
+    kdbp(" [most recent]: %016lx   trcidx: 0x%x\n", &trca[i], trcidx);
+}
+
diff -r 32034d1914a6 xen/kdb/x86/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3 @@
+
+obj-y    := kdb_wp.o
+subdir-y += udis86-1.7
diff -r 32034d1914a6 xen/kdb/x86/kdb_wp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/kdb_wp.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,310 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "../include/kdbinc.h"
+
+#if 0
+#define DR6_BT  0x00008000
+#define DR6_BS  0x00004000
+#define DR6_BD  0x00002000
+#endif
+#define DR6_B3  0x00000008
+#define DR6_B2  0x00000004
+#define DR6_B1  0x00000002
+#define DR6_B0  0x00000001
+
+#define KDB_MAXWP 4                          /* DR0 thru DR3 */
+
+struct kdb_wp {
+    kdbma_t  wp_addr;
+    int      wp_rwflag;
+    int      wp_len;
+    int      wp_deleted;                     /* pending delete */
+};
+static struct kdb_wp kdb_wpa[KDB_MAXWP];
+
+/* following because vmcs has it's own dr7. when vmcs runs, it messes up the
+ * native dr7 so we need to save/restore it */
+unsigned long kdb_dr7;
+
+
+/* Set G0-G3 bits in DR7. this does global enable of the corresponding wp */
+static void
+kdb_set_gx_in_dr7(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p | 0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p | 0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p | 0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p | 0x80;
+}
+
+/* Set LEN0 - LEN3 pair bits in DR7 (len should be 1 2 4 or 8) */
+static void
+kdb_set_len_in_dr7(int regno, kdbma_t *dr7p, int len)
+{
+    int lenbits = (len == 8) ? 2 : len-1;
+
+    *dr7p &= ~(0x3 << (18 + 4*regno));
+    *dr7p |= ((ulong)(lenbits & 0x3) << (18 + 4*regno));
+}
+
+static void
+kdb_set_dr7_rw(int regno, kdbma_t *dr7p, int rw)
+{
+    *dr7p &= ~(0x3 << (16 + 4*regno));
+    *dr7p |= ((ulong)(rw & 0x3)) << (16 + 4*regno);
+}
+
+/* get value of a debug register: DR0-DR3 DR6 DR7. other values return 0 */
+kdbma_t
+kdb_rd_dbgreg(int regnum)
+{
+    kdbma_t contents = 0;
+
+    if (regnum == 0)
+        __asm__ ("movq %%db0,%0\n\t":"=r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %%db1,%0\n\t":"=r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %%db2,%0\n\t":"=r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %%db3,%0\n\t":"=r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %%db6,%0\n\t":"=r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %%db7,%0\n\t":"=r"(contents));
+
+    return contents;
+}
+
+static void
+kdb_wr_dbgreg(int regnum, kdbma_t contents)
+{
+    if (regnum == 0)
+        __asm__ ("movq %0,%%db0\n\t"::"r"(contents));
+    else if (regnum == 1)
+        __asm__ ("movq %0,%%db1\n\t"::"r"(contents));
+    else if (regnum == 2)
+        __asm__ ("movq %0,%%db2\n\t"::"r"(contents));
+    else if (regnum == 3)
+        __asm__ ("movq %0,%%db3\n\t"::"r"(contents));
+    else if (regnum == 6)
+        __asm__ ("movq %0,%%db6\n\t"::"r"(contents));
+    else if (regnum == 7)
+        __asm__ ("movq %0,%%db7\n\t"::"r"(contents));
+}
+
+static void
+kdb_print_wp_info(char *strp, int idx)
+{
+    kdbp("%s[%d]:%016lx len:%d ", strp, idx, kdb_wpa[idx].wp_addr,
+         kdb_wpa[idx].wp_len);
+    if (kdb_wpa[idx].wp_rwflag == 1)
+        kdbp("on data write only\n");
+    else if (kdb_wpa[idx].wp_rwflag == 2)
+        kdbp("on IO read/write\n");
+    else 
+        kdbp("on data read/write\n");
+}
+
+/*
+ * Returns : 0 if not one of ours
+ *           1 if one of ours
+ */
+int
+kdb_check_watchpoints(struct cpu_user_regs *regs)
+{
+    int wpnum;
+    kdbma_t dr6 = kdb_rd_dbgreg(6);
+
+    KDBGP1("check_wp: IP:%lx EFLAGS:%lx\n", regs->rip, regs->rflags);
+    if (dr6 & DR6_B0)
+        wpnum = 0;
+    else if (dr6 & DR6_B1)
+        wpnum = 1;
+    else if (dr6 & DR6_B2)
+        wpnum = 2;
+    else if (dr6 & DR6_B3)
+        wpnum = 3;
+    else
+        return 0;
+
+    kdb_print_wp_info("Watchpoint ", wpnum);
+    return 1;
+}
+
+/* set a watchpoint at a given address 
+ * PreCondition: addr != 0 */
+static void
+kdb_set_wp(kdbva_t addr, int rwflag, int len)
+{
+    int regno;
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        if (kdb_wpa[regno].wp_addr == addr && !kdb_wpa[regno].wp_deleted) {
+            kdbp("Watchpoint already set\n");
+            return;
+        }
+        if (kdb_wpa[regno].wp_deleted)
+            memset(&kdb_wpa[regno], 0, sizeof(kdb_wpa[regno]));
+    }
+    for (regno=0; regno < KDB_MAXWP && kdb_wpa[regno].wp_addr; regno++);
+    if (regno >= KDB_MAXWP) {
+        kdbp("watchpoint table full. limit:%d\n", KDB_MAXWP);
+        return;
+    }
+    kdb_wpa[regno].wp_addr = addr;
+    kdb_wpa[regno].wp_rwflag = rwflag;
+    kdb_wpa[regno].wp_len = len;
+    kdb_print_wp_info("Watchpoint set ", regno);
+}
+
+/* write reg DR0-3 with address. Update corresponding bits in DR7 */
+static void
+kdb_install_watchpoint(int regno, kdbma_t *dr7p)
+{
+    kdb_set_gx_in_dr7(regno, dr7p);
+    kdb_set_len_in_dr7(regno, dr7p, kdb_wpa[regno].wp_len); 
+    kdb_set_dr7_rw(regno, dr7p, kdb_wpa[regno].wp_rwflag);
+    kdb_wr_dbgreg(regno, kdb_wpa[regno].wp_addr);
+
+    KDBGP1("ccpu:%d installed wp. addr:%lx rw:%x len:%x dr7:%016lx\n",
+           smp_processor_id(), kdb_wpa[regno].wp_addr, 
+           kdb_wpa[regno].wp_rwflag, kdb_wpa[regno].wp_len, *dr7p);
+}
+
+/* clear G0-G3 bits in DR7 for given DR0-3 */
+static void
+kdb_clear_dr7_gx(int regno, kdbma_t *dr7p)
+{
+    if (regno == 0)
+        *dr7p = *dr7p & ~0x2;
+    else if (regno == 1)
+        *dr7p = *dr7p & ~0x8;
+    else if (regno == 2)
+        *dr7p = *dr7p & ~0x20;
+    else if (regno == 3)
+        *dr7p = *dr7p & ~0x80;
+}
+
+/* update dr7 once, as it's slow to update debug regs and cpu's will still be 
+ * paused when leaving kdb.
+ *
+ * Just leave DR0-3 clobbered but remove bits from DR7 to disable wp 
+ */
+void
+kdb_install_watchpoints(void)
+{
+    int regno;
+    kdbma_t dr7 = kdb_rd_dbgreg(7);
+
+    for (regno=0; regno < KDB_MAXWP; regno++) {
+        /* do not clear wp_deleted here as all cpus must clear wps */
+        if (kdb_wpa[regno].wp_deleted) {
+            kdb_clear_dr7_gx(regno, &dr7);
+            continue;
+        }
+        if (kdb_wpa[regno].wp_addr)
+            kdb_install_watchpoint(regno, &dr7);
+    }
+    /* always clear DR6 when leaving */
+    kdb_wr_dbgreg(6, 0);
+    kdb_wr_dbgreg(7, dr7);
+
+    if (dr7 & DR7_ACTIVE_MASK)
+        kdb_dr7 = dr7;
+    else
+        kdb_dr7 = 0;
+#if 0
+    for(dp=domain_list; dp; dp=dp->next_in_list) {
+        struct vcpu *vp;
+        for_each_vcpu(dp, vp) {
+            for (regno=0; regno < KDB_MAXWP; regno++)
+                vp->arch.guest_context.debugreg[regno] = kdb_wpa[regno].wp_addr;
+
+            vp->arch.guest_context.debugreg[6] = 0;
+            vp->arch.guest_context.debugreg[7] = dr7;
+            KDBGP("kdb_install_watchpoints(): v:%p dr7:%lx\n", vp, dr7);
+            /* hvm_set_info_guest(vp);: Can't because can't vmcs_enter in kdb */
+        }
+    }
+#endif
+}
+
+/* clear watchpoint/s. wpnum == -1 to clear all watchpoints */
+void
+kdb_clear_wps(int wpnum)
+{
+    int i;
+
+    if (wpnum >= KDB_MAXWP) {
+        kdbp("Invalid wpnum %d\n", wpnum);
+        return;
+    }
+    if (wpnum >=0) {
+        if (kdb_wpa[wpnum].wp_addr) {
+            kdb_wpa[wpnum].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", wpnum);
+        } else
+            kdbp("watchpoint %d not set\n", wpnum);
+        return;
+    }
+    for (i=0; i < KDB_MAXWP; i++) {
+        if (kdb_wpa[i].wp_addr) {
+            kdb_wpa[i].wp_deleted = 1;
+            kdb_print_wp_info("Deleted watchpoint", i);
+        }
+    }
+}
+
+/* display any watchpoints that are set */
+static void
+kdb_display_wps(void)
+{
+    int i;
+    for (i=0; i < KDB_MAXWP; i++)
+        if (kdb_wpa[i].wp_addr && !kdb_wpa[i].wp_deleted) 
+            kdb_print_wp_info("", i);
+}
+
+/* 
+ * Display or Set hardware breakpoints, ie, watchpoints:
+ *   - Upto 4 are allowed
+ *   
+ *  rw_flag should be one of: 
+ *     01 == break on data write only
+ *     10 == break on IO read/write
+ *     11 == Break on data reads or writes
+ *
+ *  len should be one of : 1 2 4 8 
+ */
+void
+kdb_do_watchpoints(kdbva_t addr, int rw_flag, int len)
+{
+    if (addr == 0) {
+        kdb_display_wps();        /* display set watchpoints */
+        return;
+    }
+    kdb_set_wp(addr, rw_flag, len);
+    return;
+}
+
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/LICENSE
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/LICENSE	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,22 @@
+Copyright (c) 2002, 2003, 2004, 2005, 2006 <vivek@sig9.com>
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, 
+are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice, 
+      this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright notice, 
+      this list of conditions and the following disclaimer in the documentation 
+      and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/Makefile	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,5 @@
+
+CFLAGS		+= -D__UD_STANDALONE__
+obj-y		:= decode.o input.o itab.o kdb_dis.o syn-att.o syn.o \
+                   syn-intel.o udis86.o
+
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/README	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,10 @@
+
+http://udis86.sourceforge.net/
+udis86-1.6 : 
+  - cd libudis86
+  - cp *c to here
+  - cp *h to here
+   
+Mukesh Rathor
+04/30/2008
+
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/decode.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,1197 @@
+/* -----------------------------------------------------------------------------
+ * decode.c
+ *
+ * Copyright (c) 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <assert.h>
+#include <string.h>
+#endif
+
+#include "types.h"
+#include "itab.h"
+#include "input.h"
+#include "decode.h"
+
+/* The max number of prefixes to an instruction */
+#define MAX_PREFIXES    15
+
+static struct ud_itab_entry ie_invalid = { UD_Iinvalid, O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_pause   = { UD_Ipause,   O_NONE, O_NONE, O_NONE, P_none };
+static struct ud_itab_entry ie_nop     = { UD_Inop,     O_NONE, O_NONE, O_NONE, P_none };
+
+
+/* Looks up mnemonic code in the mnemonic string table
+ * Returns NULL if the mnemonic code is invalid
+ */
+const char * ud_lookup_mnemonic( enum ud_mnemonic_code c )
+{
+    if ( c < UD_Id3vil )
+        return ud_mnemonics_str[ c ];
+    return NULL;
+}
+
+
+/* Extracts instruction prefixes.
+ */
+static int get_prefixes( struct ud* u )
+{
+    unsigned int have_pfx = 1;
+    unsigned int i;
+    uint8_t curr;
+
+    /* if in error state, bail out */
+    if ( u->error ) 
+        return -1; 
+
+    /* keep going as long as there are prefixes available */
+    for ( i = 0; have_pfx ; ++i ) {
+
+        /* Get next byte. */
+        inp_next(u); 
+        if ( u->error ) 
+            return -1;
+        curr = inp_curr( u );
+
+        /* rex prefixes in 64bit mode */
+        if ( u->dis_mode == 64 && ( curr & 0xF0 ) == 0x40 ) {
+            u->pfx_rex = curr;  
+        } else {
+            switch ( curr )  
+            {
+            case 0x2E : 
+                u->pfx_seg = UD_R_CS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x36 :     
+                u->pfx_seg = UD_R_SS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x3E : 
+                u->pfx_seg = UD_R_DS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x26 : 
+                u->pfx_seg = UD_R_ES; 
+                u->pfx_rex = 0;
+                break;
+            case 0x64 : 
+                u->pfx_seg = UD_R_FS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x65 : 
+                u->pfx_seg = UD_R_GS; 
+                u->pfx_rex = 0;
+                break;
+            case 0x67 : /* adress-size override prefix */ 
+                u->pfx_adr = 0x67;
+                u->pfx_rex = 0;
+                break;
+            case 0xF0 : 
+                u->pfx_lock = 0xF0;
+                u->pfx_rex  = 0;
+                break;
+            case 0x66: 
+                /* the 0x66 sse prefix is only effective if no other sse prefix
+                 * has already been specified.
+                 */
+                if ( !u->pfx_insn ) u->pfx_insn = 0x66;
+                u->pfx_opr = 0x66;           
+                u->pfx_rex = 0;
+                break;
+            case 0xF2:
+                u->pfx_insn  = 0xF2;
+                u->pfx_repne = 0xF2; 
+                u->pfx_rex   = 0;
+                break;
+            case 0xF3:
+                u->pfx_insn = 0xF3;
+                u->pfx_rep  = 0xF3; 
+                u->pfx_repe = 0xF3; 
+                u->pfx_rex  = 0;
+                break;
+            default : 
+                /* No more prefixes */
+                have_pfx = 0;
+                break;
+            }
+        }
+
+        /* check if we reached max instruction length */
+        if ( i + 1 == MAX_INSN_LENGTH ) {
+            u->error = 1;
+            break;
+        }
+    }
+
+    /* return status */
+    if ( u->error ) 
+        return -1; 
+
+    /* rewind back one byte in stream, since the above loop 
+     * stops with a non-prefix byte. 
+     */
+    inp_back(u);
+
+    /* speculatively determine the effective operand mode,
+     * based on the prefixes and the current disassembly
+     * mode. This may be inaccurate, but useful for mode
+     * dependent decoding.
+     */
+    if ( u->dis_mode == 64 ) {
+        u->opr_mode = REX_W( u->pfx_rex ) ? 64 : ( ( u->pfx_opr ) ? 16 : 32 ) ;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 64;
+    } else if ( u->dis_mode == 32 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+        u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+    } else if ( u->dis_mode == 16 ) {
+        u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+        u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+    }
+
+    return 0;
+}
+
+
+/* Searches the instruction tables for the right entry.
+ */
+static int search_itab( struct ud * u )
+{
+    struct ud_itab_entry * e = NULL;
+    enum ud_itab_index table;
+    uint8_t peek;
+    uint8_t did_peek = 0;
+    uint8_t curr; 
+    uint8_t index;
+
+    /* if in state of error, return */
+    if ( u->error ) 
+        return -1;
+
+    /* get first byte of opcode. */
+    inp_next(u); 
+    if ( u->error ) 
+        return -1;
+    curr = inp_curr(u); 
+
+    /* resolve xchg, nop, pause crazyness */
+    if ( 0x90 == curr ) {
+        if ( !( u->dis_mode == 64 && REX_B( u->pfx_rex ) ) ) {
+            if ( u->pfx_rep ) {
+                u->pfx_rep = 0;
+                e = & ie_pause;
+            } else {
+                e = & ie_nop;
+            }
+            goto found_entry;
+        }
+    }
+
+    /* get top-level table */
+    if ( 0x0F == curr ) {
+        table = ITAB__0F;
+        curr  = inp_next(u);
+        if ( u->error )
+            return -1;
+
+        /* 2byte opcodes can be modified by 0x66, F3, and F2 prefixes */
+        if ( 0x66 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSE66__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSE66__0F;
+                u->pfx_opr = 0;
+            }
+        } else if ( 0xF2 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF2__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF2__0F; 
+                u->pfx_repne = 0;
+            }
+        } else if ( 0xF3 == u->pfx_insn ) {
+            if ( ud_itab_list[ ITAB__PFX_SSEF3__0F ][ curr ].mnemonic != UD_Iinvalid ) {
+                table = ITAB__PFX_SSEF3__0F;
+                u->pfx_repe = 0;
+                u->pfx_rep  = 0;
+            }
+        }
+    /* pick an instruction from the 1byte table */
+    } else {
+        table = ITAB__1BYTE; 
+    }
+
+    index = curr;
+
+search:
+
+    e = & ud_itab_list[ table ][ index ];
+
+    /* if mnemonic constant is a standard instruction constant
+     * our search is over.
+     */
+    
+    if ( e->mnemonic < UD_Id3vil ) {
+        if ( e->mnemonic == UD_Iinvalid ) {
+            if ( did_peek ) {
+                inp_next( u ); if ( u->error ) return -1;
+            }
+            goto found_entry;
+        }
+        goto found_entry;
+    }
+
+    table = e->prefix;
+
+    switch ( e->mnemonic )
+    {
+    case UD_Igrp_reg:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_REG( peek );
+        break;
+
+    case UD_Igrp_mod:
+        peek     = inp_peek( u );
+        did_peek = 1;
+        index    = MODRM_MOD( peek );
+        if ( index == 3 )
+           index = ITAB__MOD_INDX__11;
+        else 
+           index = ITAB__MOD_INDX__NOT_11; 
+        break;
+
+    case UD_Igrp_rm:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = MODRM_RM( curr );
+        break;
+
+    case UD_Igrp_x87:
+        curr     = inp_next( u );
+        did_peek = 0;
+        if ( u->error )
+            return -1;
+        index    = curr - 0xC0;
+        break;
+
+    case UD_Igrp_osize:
+        if ( u->opr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->opr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+ 
+    case UD_Igrp_asize:
+        if ( u->adr_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->adr_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;               
+
+    case UD_Igrp_mode:
+        if ( u->dis_mode == 64 ) 
+            index = ITAB__MODE_INDX__64;
+        else if ( u->dis_mode == 32 ) 
+            index = ITAB__MODE_INDX__32;
+        else
+            index = ITAB__MODE_INDX__16;
+        break;
+
+    case UD_Igrp_vendor:
+        if ( u->vendor == UD_VENDOR_INTEL ) 
+            index = ITAB__VENDOR_INDX__INTEL; 
+        else if ( u->vendor == UD_VENDOR_AMD )
+            index = ITAB__VENDOR_INDX__AMD;
+        else {
+            kdbp("KDB:search_itab(): unrecognized vendor id\n");
+            return -1;
+        }
+        break;
+
+    case UD_Id3vil:
+        kdbp("KDB:search_itab(): invalid instr mnemonic constant Id3vil\n");
+        return -1;
+
+    default:
+        kdbp("KDB:search_itab(): invalid instruction mnemonic constant\n");
+        return -1;
+    }
+
+    goto search;
+
+found_entry:
+
+    u->itab_entry = e;
+    u->mnemonic = u->itab_entry->mnemonic;
+
+    return 0;
+}
+
+
+static unsigned int resolve_operand_size( const struct ud * u, unsigned int s )
+{
+    switch ( s ) 
+    {
+    case SZ_V:
+        return ( u->opr_mode );
+    case SZ_Z:  
+        return ( u->opr_mode == 16 ) ? 16 : 32;
+    case SZ_P:  
+        return ( u->opr_mode == 16 ) ? SZ_WP : SZ_DP;
+    case SZ_MDQ:
+        return ( u->opr_mode == 16 ) ? 32 : u->opr_mode;
+    case SZ_RDQ:
+        return ( u->dis_mode == 64 ) ? 64 : 32;
+    default:
+        return s;
+    }
+}
+
+
+static int resolve_mnemonic( struct ud* u )
+{
+  /* far/near flags */
+  u->br_far = 0;
+  u->br_near = 0;
+  /* readjust operand sizes for call/jmp instrcutions */
+  if ( u->mnemonic == UD_Icall || u->mnemonic == UD_Ijmp ) {
+    /* WP: 16bit pointer */
+    if ( u->operand[ 0 ].size == SZ_WP ) {
+        u->operand[ 0 ].size = 16;
+        u->br_far = 1;
+        u->br_near= 0;
+    /* DP: 32bit pointer */
+    } else if ( u->operand[ 0 ].size == SZ_DP ) {
+        u->operand[ 0 ].size = 32;
+        u->br_far = 1;
+        u->br_near= 0;
+    } else {
+        u->br_far = 0;
+        u->br_near= 1;
+    }
+  /* resolve 3dnow weirdness. */
+  } else if ( u->mnemonic == UD_I3dnow ) {
+    u->mnemonic = ud_itab_list[ ITAB__3DNOW ][ inp_curr( u )  ].mnemonic;
+  }
+  /* SWAPGS is only valid in 64bits mode */
+  if ( u->mnemonic == UD_Iswapgs && u->dis_mode != 64 ) {
+    u->error = 1;
+    return -1;
+  }
+
+  return 0;
+}
+
+
+/* -----------------------------------------------------------------------------
+ * decode_a()- Decodes operands of the type seg:offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_a(struct ud* u, struct ud_operand *op)
+{
+  if (u->opr_mode == 16) {  
+    /* seg16:off16 */
+    op->type = UD_OP_PTR;
+    op->size = 32;
+    op->lval.ptr.off = inp_uint16(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  } else {
+    /* seg16:off32 */
+    op->type = UD_OP_PTR;
+    op->size = 48;
+    op->lval.ptr.off = inp_uint32(u);
+    op->lval.ptr.seg = inp_uint16(u);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_gpr() - Returns decoded General Purpose Register 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+decode_gpr(register struct ud* u, unsigned int s, unsigned char rm)
+{
+  s = resolve_operand_size(u, s);
+        
+  switch (s) {
+    case 64:
+        return UD_R_RAX + rm;
+    case SZ_DP:
+    case 32:
+        return UD_R_EAX + rm;
+    case SZ_WP:
+    case 16:
+        return UD_R_AX  + rm;
+    case  8:
+        if (u->dis_mode == 64 && u->pfx_rex) {
+            if (rm >= 4)
+                return UD_R_SPL + (rm-4);
+            return UD_R_AL + rm;
+        } else return UD_R_AL + rm;
+    default:
+        return 0;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr64() - 64bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr64(struct ud* u, enum ud_operand_code gpr_op)
+{
+  if (gpr_op >= OP_rAXr8 && gpr_op <= OP_rDIr15)
+    gpr_op = (gpr_op - OP_rAXr8) | (REX_B(u->pfx_rex) << 3);          
+  else  gpr_op = (gpr_op - OP_rAX);
+
+  if (u->opr_mode == 16)
+    return gpr_op + UD_R_AX;
+  if (u->dis_mode == 32 || 
+    (u->opr_mode == 32 && ! (REX_W(u->pfx_rex) || u->default64))) {
+    return gpr_op + UD_R_EAX;
+  }
+
+  return gpr_op + UD_R_RAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_gpr32 () - 32bit General Purpose Register-Selection. 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_gpr32(struct ud* u, enum ud_operand_code gpr_op)
+{
+  gpr_op = gpr_op - OP_eAX;
+
+  if (u->opr_mode == 16) 
+    return gpr_op + UD_R_AX;
+
+  return gpr_op +  UD_R_EAX;
+}
+
+/* -----------------------------------------------------------------------------
+ * resolve_reg() - Resolves the register type 
+ * -----------------------------------------------------------------------------
+ */
+static enum ud_type 
+resolve_reg(struct ud* u, unsigned int type, unsigned char i)
+{
+  switch (type) {
+    case T_MMX :    return UD_R_MM0  + (i & 7);
+    case T_XMM :    return UD_R_XMM0 + i;
+    case T_CRG :    return UD_R_CR0  + i;
+    case T_DBG :    return UD_R_DR0  + i;
+    case T_SEG :    return UD_R_ES   + (i & 7);
+    case T_NONE:
+    default:    return UD_NONE;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_imm() - Decodes Immediate values.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_imm(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  op->size = resolve_operand_size(u, s);
+  op->type = UD_OP_IMM;
+
+  switch (op->size) {
+    case  8: op->lval.sbyte = inp_uint8(u);   break;
+    case 16: op->lval.uword = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: return;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_modrm() - Decodes ModRM Byte
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_modrm(struct ud* u, struct ud_operand *op, unsigned int s, 
+         unsigned char rm_type, struct ud_operand *opreg, 
+         unsigned char reg_size, unsigned char reg_type)
+{
+  unsigned char mod, rm, reg;
+
+  inp_next(u);
+
+  /* get mod, r/m and reg fields */
+  mod = MODRM_MOD(inp_curr(u));
+  rm  = (REX_B(u->pfx_rex) << 3) | MODRM_RM(inp_curr(u));
+  reg = (REX_R(u->pfx_rex) << 3) | MODRM_REG(inp_curr(u));
+
+  op->size = resolve_operand_size(u, s);
+
+  /* if mod is 11b, then the UD_R_m specifies a gpr/mmx/sse/control/debug */
+  if (mod == 3) {
+    op->type = UD_OP_REG;
+    if (rm_type ==  T_GPR)
+        op->base = decode_gpr(u, op->size, rm);
+    else    op->base = resolve_reg(u, rm_type, (REX_B(u->pfx_rex) << 3) | (rm&7));
+  } 
+  /* else its memory addressing */  
+  else {
+    op->type = UD_OP_MEM;
+
+    /* 64bit addressing */
+    if (u->adr_mode == 64) {
+
+        op->base = UD_R_RAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && (rm & 7) == 5) {           
+            op->base = UD_R_RIP;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+            
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_RAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_RAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            /* special conditions for base reference */
+            if (op->index == UD_R_RSP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            if (op->base == UD_R_RBP || op->base == UD_R_R13) {
+                if (mod == 0) 
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 32-Bit addressing mode */
+    else if (u->adr_mode == 32) {
+
+        /* get base */
+        op->base = UD_R_EAX + rm;
+
+        /* get offset type */
+        if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2)
+            op->offset = 32;
+        else if (mod == 0 && rm == 5) {
+            op->base = UD_NONE;
+            op->offset = 32;
+        } else  op->offset = 0;
+
+        /* Scale-Index-Base (SIB) */
+        if ((rm & 7) == 4) {
+            inp_next(u);
+
+            op->scale = (1 << SIB_S(inp_curr(u))) & ~1;
+            op->index = UD_R_EAX + (SIB_I(inp_curr(u)) | (REX_X(u->pfx_rex) << 3));
+            op->base  = UD_R_EAX + (SIB_B(inp_curr(u)) | (REX_B(u->pfx_rex) << 3));
+
+            if (op->index == UD_R_ESP) {
+                op->index = UD_NONE;
+                op->scale = UD_NONE;
+            }
+
+            /* special condition for base reference */
+            if (op->base == UD_R_EBP) {
+                if (mod == 0)
+                    op->base = UD_NONE;
+                if (mod == 1)
+                    op->offset = 8;
+                else op->offset = 32;
+            }
+        }
+    } 
+
+    /* 16bit addressing mode */
+    else  {
+        switch (rm) {
+            case 0: op->base = UD_R_BX; op->index = UD_R_SI; break;
+            case 1: op->base = UD_R_BX; op->index = UD_R_DI; break;
+            case 2: op->base = UD_R_BP; op->index = UD_R_SI; break;
+            case 3: op->base = UD_R_BP; op->index = UD_R_DI; break;
+            case 4: op->base = UD_R_SI; break;
+            case 5: op->base = UD_R_DI; break;
+            case 6: op->base = UD_R_BP; break;
+            case 7: op->base = UD_R_BX; break;
+        }
+
+        if (mod == 0 && rm == 6) {
+            op->offset= 16;
+            op->base = UD_NONE;
+        }
+        else if (mod == 1)
+            op->offset = 8;
+        else if (mod == 2) 
+            op->offset = 16;
+    }
+  }  
+
+  /* extract offset, if any */
+  switch(op->offset) {
+    case 8 : op->lval.ubyte  = inp_uint8(u);  break;
+    case 16: op->lval.uword  = inp_uint16(u);  break;
+    case 32: op->lval.udword = inp_uint32(u); break;
+    case 64: op->lval.uqword = inp_uint64(u); break;
+    default: break;
+  }
+
+  /* resolve register encoded in reg field */
+  if (opreg) {
+    opreg->type = UD_OP_REG;
+    opreg->size = resolve_operand_size(u, reg_size);
+    if (reg_type == T_GPR) 
+        opreg->base = decode_gpr(u, opreg->size, reg);
+    else opreg->base = resolve_reg(u, reg_type, reg);
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * decode_o() - Decodes offset
+ * -----------------------------------------------------------------------------
+ */
+static void 
+decode_o(struct ud* u, unsigned int s, struct ud_operand *op)
+{
+  switch (u->adr_mode) {
+    case 64:
+        op->offset = 64; 
+        op->lval.uqword = inp_uint64(u); 
+        break;
+    case 32:
+        op->offset = 32; 
+        op->lval.udword = inp_uint32(u); 
+        break;
+    case 16:
+        op->offset = 16; 
+        op->lval.uword  = inp_uint16(u); 
+        break;
+    default:
+        return;
+  }
+  op->type = UD_OP_MEM;
+  op->size = resolve_operand_size(u, s);
+}
+
+/* -----------------------------------------------------------------------------
+ * disasm_operands() - Disassembles Operands.
+ * -----------------------------------------------------------------------------
+ */
+static int disasm_operands(register struct ud* u)
+{
+
+
+  /* mopXt = map entry, operand X, type; */
+  enum ud_operand_code mop1t = u->itab_entry->operand1.type;
+  enum ud_operand_code mop2t = u->itab_entry->operand2.type;
+  enum ud_operand_code mop3t = u->itab_entry->operand3.type;
+
+  /* mopXs = map entry, operand X, size */
+  unsigned int mop1s = u->itab_entry->operand1.size;
+  unsigned int mop2s = u->itab_entry->operand2.size;
+  unsigned int mop3s = u->itab_entry->operand3.size;
+
+  /* iop = instruction operand */
+  register struct ud_operand* iop = u->operand;
+    
+  switch(mop1t) {
+    
+    case OP_A :
+        decode_a(u, &(iop[0]));
+        break;
+    
+    /* M[b] ... */
+    case OP_M :
+        if (MODRM_MOD(inp_peek(u)) == 3)
+            u->error= 1;
+    /* E, G/P/V/I/CL/1/S */
+    case OP_E :
+        if (mop2t == OP_G) {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+            else if (mop3t == OP_CL) {
+                iop[2].type = UD_OP_REG;
+                iop[2].base = UD_R_CL;
+                iop[2].size = 8;
+            }
+        }
+        else if (mop2t == OP_P)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_MMX);
+        else if (mop2t == OP_V)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_XMM);
+        else if (mop2t == OP_S)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_SEG);
+        else {
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, NULL, 0, T_NONE);
+            if (mop2t == OP_CL) {
+                iop[1].type = UD_OP_REG;
+                iop[1].base = UD_R_CL;
+                iop[1].size = 8;
+            } else if (mop2t == OP_I1) {
+                iop[1].type = UD_OP_CONST;
+                u->operand[1].lval.udword = 1;
+            } else if (mop2t == OP_I) {
+                decode_imm(u, mop2s, &(iop[1]));
+            }
+        }
+        break;
+
+    /* G, E/PR[,I]/VR */
+    case OP_G :
+        if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_GPR);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        } else if (mop2t == OP_W)
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_GPR);
+        break;
+
+    /* AL..BH, I/O/DX */
+    case OP_AL : case OP_CL : case OP_DL : case OP_BL :
+    case OP_AH : case OP_CH : case OP_DH : case OP_BH :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AL + (mop1t - OP_AL);
+        iop[0].size = 8;
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        }
+        else if (mop2t == OP_O)
+            decode_o(u, mop2s, &(iop[1]));
+        break;
+
+    /* rAX[r8]..rDI[r15], I/rAX..rDI/O */
+    case OP_rAXr8 : case OP_rCXr9 : case OP_rDXr10 : case OP_rBXr11 :
+    case OP_rSPr12: case OP_rBPr13: case OP_rSIr14 : case OP_rDIr15 :
+    case OP_rAX : case OP_rCX : case OP_rDX : case OP_rBX :
+    case OP_rSP : case OP_rBP : case OP_rSI : case OP_rDI :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr64(u, mop1t);
+
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t >= OP_rAX && mop2t <= OP_rDI) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = resolve_gpr64(u, mop2t);
+        }
+        else if (mop2t == OP_O) {
+            decode_o(u, mop2s, &(iop[1]));  
+            iop[0].size = resolve_operand_size(u, mop2s);
+        }
+        break;
+
+    /* AL[r8b]..BH[r15b], I */
+    case OP_ALr8b : case OP_CLr9b : case OP_DLr10b : case OP_BLr11b :
+    case OP_AHr12b: case OP_CHr13b: case OP_DHr14b : case OP_BHr15b :
+    {
+        ud_type_t gpr = (mop1t - OP_ALr8b) + UD_R_AL + 
+                        (REX_B(u->pfx_rex) << 3);
+        if (UD_R_AH <= gpr && u->pfx_rex)
+            gpr = gpr + 4;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = gpr;
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+    }
+
+    /* eAX..eDX, DX/I */
+    case OP_eAX : case OP_eCX : case OP_eDX : case OP_eBX :
+    case OP_eSP : case OP_eBP : case OP_eSI : case OP_eDI :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = resolve_gpr32(u, mop1t);
+        if (mop2t == OP_DX) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_DX;
+            iop[1].size = 16;
+        } else if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break;
+
+    /* ES..GS */
+    case OP_ES : case OP_CS : case OP_DS :
+    case OP_SS : case OP_FS : case OP_GS :
+
+        /* in 64bits mode, only fs and gs are allowed */
+        if (u->dis_mode == 64)
+            if (mop1t != OP_FS && mop1t != OP_GS)
+                u->error= 1;
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t - OP_ES) + UD_R_ES;
+        iop[0].size = 16;
+
+        break;
+
+    /* J */
+    case OP_J :
+        decode_imm(u, mop1s, &(iop[0]));        
+        iop[0].type = UD_OP_JIMM;
+        break ;
+
+    /* PR, I */
+    case OP_PR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* VR, I */
+    case OP_VR:
+        if (MODRM_MOD(inp_peek(u)) != 3)
+            u->error = 1;
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, NULL, 0, T_NONE);
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        break; 
+
+    /* P, Q[,I]/W/E[,I],VR */
+    case OP_P :
+        if (mop2t == OP_Q) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_W) {
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_VR) {
+            if (MODRM_MOD(inp_peek(u)) != 3)
+                u->error = 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_MMX);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_MMX);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        }
+        break;
+
+    /* R, C/D */
+    case OP_R :
+        if (mop2t == OP_C)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_CRG);
+        else if (mop2t == OP_D)
+            decode_modrm(u, &(iop[0]), mop1s, T_GPR, &(iop[1]), mop2s, T_DBG);
+        break;
+
+    /* C, R */
+    case OP_C :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_CRG);
+        break;
+
+    /* D, R */
+    case OP_D :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_DBG);
+        break;
+
+    /* Q, P */
+    case OP_Q :
+        decode_modrm(u, &(iop[0]), mop1s, T_MMX, &(iop[1]), mop2s, T_MMX);
+        break;
+
+    /* S, E */
+    case OP_S :
+        decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_SEG);
+        break;
+
+    /* W, V */
+    case OP_W :
+        decode_modrm(u, &(iop[0]), mop1s, T_XMM, &(iop[1]), mop2s, T_XMM);
+        break;
+
+    /* V, W[,I]/Q/M/E */
+    case OP_V :
+        if (mop2t == OP_W) {
+            /* special cases for movlps and movhps */
+            if (MODRM_MOD(inp_peek(u)) == 3) {
+                if (u->mnemonic == UD_Imovlps)
+                    u->mnemonic = UD_Imovhlps;
+                else
+                if (u->mnemonic == UD_Imovhps)
+                    u->mnemonic = UD_Imovlhps;
+            }
+            decode_modrm(u, &(iop[1]), mop2s, T_XMM, &(iop[0]), mop1s, T_XMM);
+            if (mop3t == OP_I)
+                decode_imm(u, mop3s, &(iop[2]));
+        } else if (mop2t == OP_Q)
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        else if (mop2t == OP_M) {
+            if (MODRM_MOD(inp_peek(u)) == 3)
+                u->error= 1;
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_E) {
+            decode_modrm(u, &(iop[1]), mop2s, T_GPR, &(iop[0]), mop1s, T_XMM);
+        } else if (mop2t == OP_PR) {
+            decode_modrm(u, &(iop[1]), mop2s, T_MMX, &(iop[0]), mop1s, T_XMM);
+        }
+        break;
+
+    /* DX, eAX/AL */
+    case OP_DX :
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_DX;
+        iop[0].size = 16;
+
+        if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        } else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 8;
+        }
+
+        break;
+
+    /* I, I/AL/eAX */
+    case OP_I :
+        decode_imm(u, mop1s, &(iop[0]));
+        if (mop2t == OP_I)
+            decode_imm(u, mop2s, &(iop[1]));
+        else if (mop2t == OP_AL) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = UD_R_AL;
+            iop[1].size = 16;
+        } else if (mop2t == OP_eAX) {
+            iop[1].type = UD_OP_REG;    
+            iop[1].base = resolve_gpr32(u, mop2t);
+        }
+        break;
+
+    /* O, AL/eAX */
+    case OP_O :
+        decode_o(u, mop1s, &(iop[0]));
+        iop[1].type = UD_OP_REG;
+        iop[1].size = resolve_operand_size(u, mop1s);
+        if (mop2t == OP_AL)
+            iop[1].base = UD_R_AL;
+        else if (mop2t == OP_eAX)
+            iop[1].base = resolve_gpr32(u, mop2t);
+        else if (mop2t == OP_rAX)
+            iop[1].base = resolve_gpr64(u, mop2t);      
+        break;
+
+    /* 3 */
+    case OP_I3 :
+        iop[0].type = UD_OP_CONST;
+        iop[0].lval.sbyte = 3;
+        break;
+
+    /* ST(n), ST(n) */
+    case OP_ST0 : case OP_ST1 : case OP_ST2 : case OP_ST3 :
+    case OP_ST4 : case OP_ST5 : case OP_ST6 : case OP_ST7 :
+
+        iop[0].type = UD_OP_REG;
+        iop[0].base = (mop1t-OP_ST0) + UD_R_ST0;
+        iop[0].size = 0;
+
+        if (mop2t >= OP_ST0 && mop2t <= OP_ST7) {
+            iop[1].type = UD_OP_REG;
+            iop[1].base = (mop2t-OP_ST0) + UD_R_ST0;
+            iop[1].size = 0;
+        }
+        break;
+
+    /* AX */
+    case OP_AX:
+        iop[0].type = UD_OP_REG;
+        iop[0].base = UD_R_AX;
+        iop[0].size = 16;
+        break;
+
+    /* none */
+    default :
+        iop[0].type = iop[1].type = iop[2].type = UD_NONE;
+  }
+
+  return 0;
+}
+
+/* -----------------------------------------------------------------------------
+ * clear_insn() - clear instruction pointer 
+ * -----------------------------------------------------------------------------
+ */
+static int clear_insn(register struct ud* u)
+{
+  u->error     = 0;
+  u->pfx_seg   = 0;
+  u->pfx_opr   = 0;
+  u->pfx_adr   = 0;
+  u->pfx_lock  = 0;
+  u->pfx_repne = 0;
+  u->pfx_rep   = 0;
+  u->pfx_repe  = 0;
+  u->pfx_seg   = 0;
+  u->pfx_rex   = 0;
+  u->pfx_insn  = 0;
+  u->mnemonic  = UD_Inone;
+  u->itab_entry = NULL;
+
+  memset( &u->operand[ 0 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 1 ], 0, sizeof( struct ud_operand ) );
+  memset( &u->operand[ 2 ], 0, sizeof( struct ud_operand ) );
+ 
+  return 0;
+}
+
+static int do_mode( struct ud* u )
+{
+  /* if in error state, bail out */
+  if ( u->error ) return -1; 
+
+  /* propagate perfix effects */
+  if ( u->dis_mode == 64 ) {  /* set 64bit-mode flags */
+
+    /* Check validity of  instruction m64 */
+    if ( P_INV64( u->itab_entry->prefix ) ) {
+        u->error = 1;
+        return -1;
+    }
+
+    /* effective rex prefix is the  effective mask for the 
+     * instruction hard-coded in the opcode map.
+     */
+    u->pfx_rex = ( u->pfx_rex & 0x40 ) | 
+                 ( u->pfx_rex & REX_PFX_MASK( u->itab_entry->prefix ) ); 
+
+    /* whether this instruction has a default operand size of 
+     * 64bit, also hardcoded into the opcode map.
+     */
+    u->default64 = P_DEF64( u->itab_entry->prefix ); 
+    /* calculate effective operand size */
+    if ( REX_W( u->pfx_rex ) ) {
+        u->opr_mode = 64;
+    } else if ( u->pfx_opr ) {
+        u->opr_mode = 16;
+    } else {
+        /* unless the default opr size of instruction is 64,
+         * the effective operand size in the absence of rex.w
+         * prefix is 32.
+         */
+        u->opr_mode = ( u->default64 ) ? 64 : 32;
+    }
+
+    /* calculate effective address size */
+    u->adr_mode = (u->pfx_adr) ? 32 : 64;
+  } else if ( u->dis_mode == 32 ) { /* set 32bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 16 : 32;
+    u->adr_mode = ( u->pfx_adr ) ? 16 : 32;
+  } else if ( u->dis_mode == 16 ) { /* set 16bit-mode flags */
+    u->opr_mode = ( u->pfx_opr ) ? 32 : 16;
+    u->adr_mode = ( u->pfx_adr ) ? 32 : 16;
+  }
+
+  /* These flags determine which operand to apply the operand size
+   * cast to.
+   */
+  u->c1 = ( P_C1( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c2 = ( P_C2( u->itab_entry->prefix ) ) ? 1 : 0;
+  u->c3 = ( P_C3( u->itab_entry->prefix ) ) ? 1 : 0;
+
+  /* set flags for implicit addressing */
+  u->implicit_addr = P_IMPADDR( u->itab_entry->prefix );
+
+  return 0;
+}
+
+static int gen_hex( struct ud *u )
+{
+  unsigned int i;
+  unsigned char *src_ptr = inp_sess( u );
+  char* src_hex;
+
+  /* bail out if in error stat. */
+  if ( u->error ) return -1; 
+  /* output buffer pointe */
+  src_hex = ( char* ) u->insn_hexcode;
+  /* for each byte used to decode instruction */
+  for ( i = 0; i < u->inp_ctr; ++i, ++src_ptr) {
+    snprintf( src_hex, 2, "%02x", *src_ptr & 0xFF );
+    src_hex += 2;
+  }
+  return 0;
+}
+
+/* =============================================================================
+ * ud_decode() - Instruction decoder. Returns the number of bytes decoded.
+ * =============================================================================
+ */
+unsigned int ud_decode( struct ud* u )
+{
+  inp_start(u);
+
+  if ( clear_insn( u ) ) {
+    ; /* error */
+  } else if ( get_prefixes( u ) != 0 ) {
+    ; /* error */
+  } else if ( search_itab( u ) != 0 ) {
+    ; /* error */
+  } else if ( do_mode( u ) != 0 ) {
+    ; /* error */
+  } else if ( disasm_operands( u ) != 0 ) {
+    ; /* error */
+  } else if ( resolve_mnemonic( u ) != 0 ) {
+    ; /* error */
+  }
+
+  /* Handle decode error. */
+  if ( u->error ) {
+    /* clear out the decode data. */
+    clear_insn( u );
+    /* mark the sequence of bytes as invalid. */
+    u->itab_entry = & ie_invalid;
+    u->mnemonic = u->itab_entry->mnemonic;
+  } 
+
+  u->insn_offset = u->pc; /* set offset of instruction */
+  u->insn_fill = 0;   /* set translation buffer index to 0 */
+  u->pc += u->inp_ctr;    /* move program counter by bytes decoded */
+  gen_hex( u );       /* generate hex code */
+
+  /* return number of bytes disassembled. */
+  return u->inp_ctr;
+}
+
+/* vim:cindent
+ * vim:ts=4
+ * vim:sw=4
+ * vim:expandtab
+ */
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/decode.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/decode.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,273 @@
+#ifndef UD_DECODE_H
+#define UD_DECODE_H
+
+#define MAX_INSN_LENGTH 15
+
+/* register classes */
+#define T_NONE  0
+#define T_GPR   1
+#define T_MMX   2
+#define T_CRG   3
+#define T_DBG   4
+#define T_SEG   5
+#define T_XMM   6
+
+/* itab prefix bits */
+#define P_none          ( 0 )
+#define P_c1            ( 1 << 0 )
+#define P_C1(n)         ( ( n >> 0 ) & 1 )
+#define P_rexb          ( 1 << 1 )
+#define P_REXB(n)       ( ( n >> 1 ) & 1 )
+#define P_depM          ( 1 << 2 )
+#define P_DEPM(n)       ( ( n >> 2 ) & 1 )
+#define P_c3            ( 1 << 3 )
+#define P_C3(n)         ( ( n >> 3 ) & 1 )
+#define P_inv64         ( 1 << 4 )
+#define P_INV64(n)      ( ( n >> 4 ) & 1 )
+#define P_rexw          ( 1 << 5 )
+#define P_REXW(n)       ( ( n >> 5 ) & 1 )
+#define P_c2            ( 1 << 6 )
+#define P_C2(n)         ( ( n >> 6 ) & 1 )
+#define P_def64         ( 1 << 7 )
+#define P_DEF64(n)      ( ( n >> 7 ) & 1 )
+#define P_rexr          ( 1 << 8 )
+#define P_REXR(n)       ( ( n >> 8 ) & 1 )
+#define P_oso           ( 1 << 9 )
+#define P_OSO(n)        ( ( n >> 9 ) & 1 )
+#define P_aso           ( 1 << 10 )
+#define P_ASO(n)        ( ( n >> 10 ) & 1 )
+#define P_rexx          ( 1 << 11 )
+#define P_REXX(n)       ( ( n >> 11 ) & 1 )
+#define P_ImpAddr       ( 1 << 12 )
+#define P_IMPADDR(n)    ( ( n >> 12 ) & 1 )
+
+/* rex prefix bits */
+#define REX_W(r)        ( ( 0xF & ( r ) )  >> 3 )
+#define REX_R(r)        ( ( 0x7 & ( r ) )  >> 2 )
+#define REX_X(r)        ( ( 0x3 & ( r ) )  >> 1 )
+#define REX_B(r)        ( ( 0x1 & ( r ) )  >> 0 )
+#define REX_PFX_MASK(n) ( ( P_REXW(n) << 3 ) | \
+                          ( P_REXR(n) << 2 ) | \
+                          ( P_REXX(n) << 1 ) | \
+                          ( P_REXB(n) << 0 ) )
+
+/* scable-index-base bits */
+#define SIB_S(b)        ( ( b ) >> 6 )
+#define SIB_I(b)        ( ( ( b ) >> 3 ) & 7 )
+#define SIB_B(b)        ( ( b ) & 7 )
+
+/* modrm bits */
+#define MODRM_REG(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_NNN(b)    ( ( ( b ) >> 3 ) & 7 )
+#define MODRM_MOD(b)    ( ( ( b ) >> 6 ) & 3 )
+#define MODRM_RM(b)     ( ( b ) & 7 )
+
+/* operand type constants -- order is important! */
+
+enum ud_operand_code {
+    OP_NONE,
+
+    OP_A,      OP_E,      OP_M,       OP_G,       
+    OP_I,
+
+    OP_AL,     OP_CL,     OP_DL,      OP_BL,
+    OP_AH,     OP_CH,     OP_DH,      OP_BH,
+
+    OP_ALr8b,  OP_CLr9b,  OP_DLr10b,  OP_BLr11b,
+    OP_AHr12b, OP_CHr13b, OP_DHr14b,  OP_BHr15b,
+
+    OP_AX,     OP_CX,     OP_DX,      OP_BX,
+    OP_SI,     OP_DI,     OP_SP,      OP_BP,
+
+    OP_rAX,    OP_rCX,    OP_rDX,     OP_rBX,  
+    OP_rSP,    OP_rBP,    OP_rSI,     OP_rDI,
+
+    OP_rAXr8,  OP_rCXr9,  OP_rDXr10,  OP_rBXr11,  
+    OP_rSPr12, OP_rBPr13, OP_rSIr14,  OP_rDIr15,
+
+    OP_eAX,    OP_eCX,    OP_eDX,     OP_eBX,
+    OP_eSP,    OP_eBP,    OP_eSI,     OP_eDI,
+
+    OP_ES,     OP_CS,     OP_SS,      OP_DS,  
+    OP_FS,     OP_GS,
+
+    OP_ST0,    OP_ST1,    OP_ST2,     OP_ST3,
+    OP_ST4,    OP_ST5,    OP_ST6,     OP_ST7,
+
+    OP_J,      OP_S,      OP_O,          
+    OP_I1,     OP_I3, 
+
+    OP_V,      OP_W,      OP_Q,       OP_P, 
+
+    OP_R,      OP_C,  OP_D,       OP_VR,  OP_PR
+};
+
+
+/* operand size constants */
+
+enum ud_operand_size {
+    SZ_NA  = 0,
+    SZ_Z   = 1,
+    SZ_V   = 2,
+    SZ_P   = 3,
+    SZ_WP  = 4,
+    SZ_DP  = 5,
+    SZ_MDQ = 6,
+    SZ_RDQ = 7,
+
+    /* the following values are used as is,
+     * and thus hard-coded. changing them 
+     * will break internals 
+     */
+    SZ_B   = 8,
+    SZ_W   = 16,
+    SZ_D   = 32,
+    SZ_Q   = 64,
+    SZ_T   = 80,
+};
+
+/* itab entry operand definitions */
+
+#define O_rSPr12  { OP_rSPr12,   SZ_NA    }
+#define O_BL      { OP_BL,       SZ_NA    }
+#define O_BH      { OP_BH,       SZ_NA    }
+#define O_BP      { OP_BP,       SZ_NA    }
+#define O_AHr12b  { OP_AHr12b,   SZ_NA    }
+#define O_BX      { OP_BX,       SZ_NA    }
+#define O_Jz      { OP_J,        SZ_Z     }
+#define O_Jv      { OP_J,        SZ_V     }
+#define O_Jb      { OP_J,        SZ_B     }
+#define O_rSIr14  { OP_rSIr14,   SZ_NA    }
+#define O_GS      { OP_GS,       SZ_NA    }
+#define O_D       { OP_D,        SZ_NA    }
+#define O_rBPr13  { OP_rBPr13,   SZ_NA    }
+#define O_Ob      { OP_O,        SZ_B     }
+#define O_P       { OP_P,        SZ_NA    }
+#define O_Ow      { OP_O,        SZ_W     }
+#define O_Ov      { OP_O,        SZ_V     }
+#define O_Gw      { OP_G,        SZ_W     }
+#define O_Gv      { OP_G,        SZ_V     }
+#define O_rDX     { OP_rDX,      SZ_NA    }
+#define O_Gx      { OP_G,        SZ_MDQ   }
+#define O_Gd      { OP_G,        SZ_D     }
+#define O_Gb      { OP_G,        SZ_B     }
+#define O_rBXr11  { OP_rBXr11,   SZ_NA    }
+#define O_rDI     { OP_rDI,      SZ_NA    }
+#define O_rSI     { OP_rSI,      SZ_NA    }
+#define O_ALr8b   { OP_ALr8b,    SZ_NA    }
+#define O_eDI     { OP_eDI,      SZ_NA    }
+#define O_Gz      { OP_G,        SZ_Z     }
+#define O_eDX     { OP_eDX,      SZ_NA    }
+#define O_DHr14b  { OP_DHr14b,   SZ_NA    }
+#define O_rSP     { OP_rSP,      SZ_NA    }
+#define O_PR      { OP_PR,       SZ_NA    }
+#define O_NONE    { OP_NONE,     SZ_NA    }
+#define O_rCX     { OP_rCX,      SZ_NA    }
+#define O_jWP     { OP_J,        SZ_WP    }
+#define O_rDXr10  { OP_rDXr10,   SZ_NA    }
+#define O_Md      { OP_M,        SZ_D     }
+#define O_C       { OP_C,        SZ_NA    }
+#define O_G       { OP_G,        SZ_NA    }
+#define O_Mb      { OP_M,        SZ_B     }
+#define O_Mt      { OP_M,        SZ_T     }
+#define O_S       { OP_S,        SZ_NA    }
+#define O_Mq      { OP_M,        SZ_Q     }
+#define O_W       { OP_W,        SZ_NA    }
+#define O_ES      { OP_ES,       SZ_NA    }
+#define O_rBX     { OP_rBX,      SZ_NA    }
+#define O_Ed      { OP_E,        SZ_D     }
+#define O_DLr10b  { OP_DLr10b,   SZ_NA    }
+#define O_Mw      { OP_M,        SZ_W     }
+#define O_Eb      { OP_E,        SZ_B     }
+#define O_Ex      { OP_E,        SZ_MDQ   }
+#define O_Ez      { OP_E,        SZ_Z     }
+#define O_Ew      { OP_E,        SZ_W     }
+#define O_Ev      { OP_E,        SZ_V     }
+#define O_Ep      { OP_E,        SZ_P     }
+#define O_FS      { OP_FS,       SZ_NA    }
+#define O_Ms      { OP_M,        SZ_W     }
+#define O_rAXr8   { OP_rAXr8,    SZ_NA    }
+#define O_eBP     { OP_eBP,      SZ_NA    }
+#define O_Isb     { OP_I,        SZ_SB    }
+#define O_eBX     { OP_eBX,      SZ_NA    }
+#define O_rCXr9   { OP_rCXr9,    SZ_NA    }
+#define O_jDP     { OP_J,        SZ_DP    }
+#define O_CH      { OP_CH,       SZ_NA    }
+#define O_CL      { OP_CL,       SZ_NA    }
+#define O_R       { OP_R,        SZ_RDQ   }
+#define O_V       { OP_V,        SZ_NA    }
+#define O_CS      { OP_CS,       SZ_NA    }
+#define O_CHr13b  { OP_CHr13b,   SZ_NA    }
+#define O_eCX     { OP_eCX,      SZ_NA    }
+#define O_eSP     { OP_eSP,      SZ_NA    }
+#define O_SS      { OP_SS,       SZ_NA    }
+#define O_SP      { OP_SP,       SZ_NA    }
+#define O_BLr11b  { OP_BLr11b,   SZ_NA    }
+#define O_SI      { OP_SI,       SZ_NA    }
+#define O_eSI     { OP_eSI,      SZ_NA    }
+#define O_DL      { OP_DL,       SZ_NA    }
+#define O_DH      { OP_DH,       SZ_NA    }
+#define O_DI      { OP_DI,       SZ_NA    }
+#define O_DX      { OP_DX,       SZ_NA    }
+#define O_rBP     { OP_rBP,      SZ_NA    }
+#define O_Gvw     { OP_G,        SZ_MDQ   }
+#define O_I1      { OP_I1,       SZ_NA    }
+#define O_I3      { OP_I3,       SZ_NA    }
+#define O_DS      { OP_DS,       SZ_NA    }
+#define O_ST4     { OP_ST4,      SZ_NA    }
+#define O_ST5     { OP_ST5,      SZ_NA    }
+#define O_ST6     { OP_ST6,      SZ_NA    }
+#define O_ST7     { OP_ST7,      SZ_NA    }
+#define O_ST0     { OP_ST0,      SZ_NA    }
+#define O_ST1     { OP_ST1,      SZ_NA    }
+#define O_ST2     { OP_ST2,      SZ_NA    }
+#define O_ST3     { OP_ST3,      SZ_NA    }
+#define O_E       { OP_E,        SZ_NA    }
+#define O_AH      { OP_AH,       SZ_NA    }
+#define O_M       { OP_M,        SZ_NA    }
+#define O_AL      { OP_AL,       SZ_NA    }
+#define O_CLr9b   { OP_CLr9b,    SZ_NA    }
+#define O_Q       { OP_Q,        SZ_NA    }
+#define O_eAX     { OP_eAX,      SZ_NA    }
+#define O_VR      { OP_VR,       SZ_NA    }
+#define O_AX      { OP_AX,       SZ_NA    }
+#define O_rAX     { OP_rAX,      SZ_NA    }
+#define O_Iz      { OP_I,        SZ_Z     }
+#define O_rDIr15  { OP_rDIr15,   SZ_NA    }
+#define O_Iw      { OP_I,        SZ_W     }
+#define O_Iv      { OP_I,        SZ_V     }
+#define O_Ap      { OP_A,        SZ_P     }
+#define O_CX      { OP_CX,       SZ_NA    }
+#define O_Ib      { OP_I,        SZ_B     }
+#define O_BHr15b  { OP_BHr15b,   SZ_NA    }
+
+
+/* A single operand of an entry in the instruction table. 
+ * (internal use only)
+ */
+struct ud_itab_entry_operand 
+{
+  enum ud_operand_code type;
+  enum ud_operand_size size;
+};
+
+
+/* A single entry in an instruction table. 
+ *(internal use only)
+ */
+struct ud_itab_entry 
+{
+  enum ud_mnemonic_code         mnemonic;
+  struct ud_itab_entry_operand  operand1;
+  struct ud_itab_entry_operand  operand2;
+  struct ud_itab_entry_operand  operand3;
+  uint32_t                      prefix;
+};
+
+#endif /* UD_DECODE_H */
+
+/* vim:cindent
+ * vim:expandtab
+ * vim:ts=4
+ * vim:sw=4
+ */
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/extern.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/extern.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,67 @@
+/* -----------------------------------------------------------------------------
+ * extern.h
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_EXTERN_H
+#define UD_EXTERN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #include <stdio.h> */
+#include "types.h"
+
+/* ============================= PUBLIC API ================================= */
+
+extern void ud_init(struct ud*);
+
+extern void ud_set_mode(struct ud*, uint8_t);
+
+extern void ud_set_pc(struct ud*, uint64_t);
+
+extern void ud_set_input_hook(struct ud*, int (*)(struct ud*));
+
+extern void ud_set_input_buffer(struct ud*, uint8_t*, size_t);
+
+#ifndef __UD_STANDALONE__
+extern void ud_set_input_file(struct ud*, FILE*);
+#endif /* __UD_STANDALONE__ */
+
+extern void ud_set_vendor(struct ud*, unsigned);
+
+extern void ud_set_syntax(struct ud*, void (*)(struct ud*));
+
+extern void ud_input_skip(struct ud*, size_t);
+
+extern int ud_input_end(struct ud*);
+
+extern unsigned int ud_decode(struct ud*);
+
+extern unsigned int ud_disassemble(struct ud*);
+
+extern void ud_translate_intel(struct ud*);
+
+extern void ud_translate_att(struct ud*);
+
+extern char* ud_insn_asm(struct ud* u);
+
+extern uint8_t* ud_insn_ptr(struct ud* u);
+
+extern uint64_t ud_insn_off(struct ud*);
+
+extern char* ud_insn_hex(struct ud*);
+
+extern unsigned int ud_insn_len(struct ud* u);
+
+extern const char* ud_lookup_mnemonic(enum ud_mnemonic_code c);
+
+/* ========================================================================== */
+
+#ifdef __cplusplus
+}
+#endif
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/input.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,226 @@
+/* -----------------------------------------------------------------------------
+ * input.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#include "extern.h"
+#include "types.h"
+#include "input.h"
+
+/* -----------------------------------------------------------------------------
+ * inp_buff_hook() - Hook for buffered inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_buff_hook(struct ud* u)
+{
+  if (u->inp_buff < u->inp_buff_end)
+	return *u->inp_buff++;
+  else	return -1;
+}
+
+#ifndef __UD_STANDALONE__
+/* -----------------------------------------------------------------------------
+ * inp_file_hook() - Hook for FILE inputs.
+ * -----------------------------------------------------------------------------
+ */
+static int 
+inp_file_hook(struct ud* u)
+{
+  return fgetc(u->inp_file);
+}
+#endif /* __UD_STANDALONE__*/
+
+/* =============================================================================
+ * ud_inp_set_hook() - Sets input hook.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_hook(register struct ud* u, int (*hook)(struct ud*))
+{
+  u->inp_hook = hook;
+  inp_init(u);
+}
+
+/* =============================================================================
+ * ud_inp_set_buffer() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_buffer(register struct ud* u, uint8_t* buf, size_t len)
+{
+  u->inp_hook = inp_buff_hook;
+  u->inp_buff = buf;
+  u->inp_buff_end = buf + len;
+  inp_init(u);
+}
+
+#ifndef __UD_STANDALONE__
+/* =============================================================================
+ * ud_input_set_file() - Set buffer as input.
+ * =============================================================================
+ */
+extern void 
+ud_set_input_file(register struct ud* u, FILE* f)
+{
+  u->inp_hook = inp_file_hook;
+  u->inp_file = f;
+  inp_init(u);
+}
+#endif /* __UD_STANDALONE__ */
+
+/* =============================================================================
+ * ud_input_skip() - Skip n input bytes.
+ * =============================================================================
+ */
+extern void 
+ud_input_skip(struct ud* u, size_t n)
+{
+  while (n--) {
+	u->inp_hook(u);
+  }
+}
+
+/* =============================================================================
+ * ud_input_end() - Test for end of input.
+ * =============================================================================
+ */
+extern int 
+ud_input_end(struct ud* u)
+{
+  return (u->inp_curr == u->inp_fill) && u->inp_end;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_next() - Loads and returns the next byte from input.
+ *
+ * inp_curr and inp_fill are pointers to the cache. The program is written based
+ * on the property that they are 8-bits in size, and will eventually wrap around
+ * forming a circular buffer. So, the size of the cache is 256 in size, kind of
+ * unnecessary yet optimized.
+ *
+ * A buffer inp_sess stores the bytes disassembled for a single session.
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t inp_next(struct ud* u) 
+{
+  int c = -1;
+  /* if current pointer is not upto the fill point in the 
+   * input cache.
+   */
+  if ( u->inp_curr != u->inp_fill ) {
+	c = u->inp_cache[ ++u->inp_curr ];
+  /* if !end-of-input, call the input hook and get a byte */
+  } else if ( u->inp_end || ( c = u->inp_hook( u ) ) == -1 ) {
+	/* end-of-input, mark it as an error, since the decoder,
+	 * expected a byte more.
+	 */
+	u->error = 1;
+	/* flag end of input */
+	u->inp_end = 1;
+	return 0;
+  } else {
+	/* increment pointers, we have a new byte.  */
+	u->inp_curr = ++u->inp_fill;
+	/* add the byte to the cache */
+	u->inp_cache[ u->inp_fill ] = c;
+  }
+  /* record bytes input per decode-session. */
+  u->inp_sess[ u->inp_ctr++ ] = c;
+  /* return byte */
+  return ( uint8_t ) c;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_back() - Move back a single byte in the stream.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_back(struct ud* u) 
+{
+  if ( u->inp_ctr > 0 ) {
+	--u->inp_curr;
+	--u->inp_ctr;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_peek() - Peek into the next byte in source. 
+ * -----------------------------------------------------------------------------
+ */
+extern uint8_t
+inp_peek(struct ud* u) 
+{
+  uint8_t r = inp_next(u);
+  if ( !u->error ) inp_back(u); /* Don't backup if there was an error */
+  return r;
+}
+
+/* -----------------------------------------------------------------------------
+ * inp_move() - Move ahead n input bytes.
+ * -----------------------------------------------------------------------------
+ */
+extern void
+inp_move(struct ud* u, size_t n) 
+{
+  while (n--)
+	inp_next(u);
+}
+
+/*------------------------------------------------------------------------------
+ *  inp_uintN() - return uintN from source.
+ *------------------------------------------------------------------------------
+ */
+extern uint8_t 
+inp_uint8(struct ud* u)
+{
+  return inp_next(u);
+}
+
+extern uint16_t 
+inp_uint16(struct ud* u)
+{
+  uint16_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  return ret | (r << 8);
+}
+
+extern uint32_t 
+inp_uint32(struct ud* u)
+{
+  uint32_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  return ret | (r << 24);
+}
+
+extern uint64_t 
+inp_uint64(struct ud* u)
+{
+  uint64_t r, ret;
+
+  ret = inp_next(u);
+  r = inp_next(u);
+  ret = ret | (r << 8);
+  r = inp_next(u);
+  ret = ret | (r << 16);
+  r = inp_next(u);
+  ret = ret | (r << 24);
+  r = inp_next(u);
+  ret = ret | (r << 32);
+  r = inp_next(u);
+  ret = ret | (r << 40);
+  r = inp_next(u);
+  ret = ret | (r << 48);
+  r = inp_next(u);
+  return ret | (r << 56);
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/input.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/input.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,49 @@
+/* -----------------------------------------------------------------------------
+ * input.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_INPUT_H
+#define UD_INPUT_H
+
+#include "types.h"
+
+uint8_t inp_next(struct ud*);
+uint8_t inp_peek(struct ud*);
+uint8_t inp_uint8(struct ud*);
+uint16_t inp_uint16(struct ud*);
+uint32_t inp_uint32(struct ud*);
+uint64_t inp_uint64(struct ud*);
+void inp_move(struct ud*, size_t);
+void inp_back(struct ud*);
+
+/* inp_init() - Initializes the input system. */
+#define inp_init(u) \
+do { \
+  u->inp_curr = 0; \
+  u->inp_fill = 0; \
+  u->inp_ctr  = 0; \
+  u->inp_end  = 0; \
+} while (0)
+
+/* inp_start() - Should be called before each de-code operation. */
+#define inp_start(u) u->inp_ctr = 0
+
+/* inp_back() - Resets the current pointer to its position before the current
+ * instruction disassembly was started.
+ */
+#define inp_reset(u) \
+do { \
+  u->inp_curr -= u->inp_ctr; \
+  u->inp_ctr = 0; \
+} while (0)
+
+/* inp_sess() - Returns the pointer to current session. */
+#define inp_sess(u) (u->inp_sess)
+
+/* inp_cur() - Returns the current input byte. */
+#define inp_curr(u) ((u)->inp_cache[(u)->inp_curr])
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/itab.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,3668 @@
+
+/* itab.c -- auto generated by opgen.py, do not edit. */
+
+#include "types.h"
+#include "decode.h"
+#include "itab.h"
+
+const char * ud_mnemonics_str[] = {
+  "3dnow",
+  "aaa",
+  "aad",
+  "aam",
+  "aas",
+  "adc",
+  "add",
+  "addpd",
+  "addps",
+  "addsd",
+  "addss",
+  "addsubpd",
+  "addsubps",
+  "and",
+  "andpd",
+  "andps",
+  "andnpd",
+  "andnps",
+  "arpl",
+  "movsxd",
+  "bound",
+  "bsf",
+  "bsr",
+  "bswap",
+  "bt",
+  "btc",
+  "btr",
+  "bts",
+  "call",
+  "cbw",
+  "cwde",
+  "cdqe",
+  "clc",
+  "cld",
+  "clflush",
+  "clgi",
+  "cli",
+  "clts",
+  "cmc",
+  "cmovo",
+  "cmovno",
+  "cmovb",
+  "cmovae",
+  "cmovz",
+  "cmovnz",
+  "cmovbe",
+  "cmova",
+  "cmovs",
+  "cmovns",
+  "cmovp",
+  "cmovnp",
+  "cmovl",
+  "cmovge",
+  "cmovle",
+  "cmovg",
+  "cmp",
+  "cmppd",
+  "cmpps",
+  "cmpsb",
+  "cmpsw",
+  "cmpsd",
+  "cmpsq",
+  "cmpss",
+  "cmpxchg",
+  "cmpxchg8b",
+  "comisd",
+  "comiss",
+  "cpuid",
+  "cvtdq2pd",
+  "cvtdq2ps",
+  "cvtpd2dq",
+  "cvtpd2pi",
+  "cvtpd2ps",
+  "cvtpi2ps",
+  "cvtpi2pd",
+  "cvtps2dq",
+  "cvtps2pi",
+  "cvtps2pd",
+  "cvtsd2si",
+  "cvtsd2ss",
+  "cvtsi2ss",
+  "cvtss2si",
+  "cvtss2sd",
+  "cvttpd2pi",
+  "cvttpd2dq",
+  "cvttps2dq",
+  "cvttps2pi",
+  "cvttsd2si",
+  "cvtsi2sd",
+  "cvttss2si",
+  "cwd",
+  "cdq",
+  "cqo",
+  "daa",
+  "das",
+  "dec",
+  "div",
+  "divpd",
+  "divps",
+  "divsd",
+  "divss",
+  "emms",
+  "enter",
+  "f2xm1",
+  "fabs",
+  "fadd",
+  "faddp",
+  "fbld",
+  "fbstp",
+  "fchs",
+  "fclex",
+  "fcmovb",
+  "fcmove",
+  "fcmovbe",
+  "fcmovu",
+  "fcmovnb",
+  "fcmovne",
+  "fcmovnbe",
+  "fcmovnu",
+  "fucomi",
+  "fcom",
+  "fcom2",
+  "fcomp3",
+  "fcomi",
+  "fucomip",
+  "fcomip",
+  "fcomp",
+  "fcomp5",
+  "fcompp",
+  "fcos",
+  "fdecstp",
+  "fdiv",
+  "fdivp",
+  "fdivr",
+  "fdivrp",
+  "femms",
+  "ffree",
+  "ffreep",
+  "ficom",
+  "ficomp",
+  "fild",
+  "fncstp",
+  "fninit",
+  "fiadd",
+  "fidivr",
+  "fidiv",
+  "fisub",
+  "fisubr",
+  "fist",
+  "fistp",
+  "fisttp",
+  "fld",
+  "fld1",
+  "fldl2t",
+  "fldl2e",
+  "fldlpi",
+  "fldlg2",
+  "fldln2",
+  "fldz",
+  "fldcw",
+  "fldenv",
+  "fmul",
+  "fmulp",
+  "fimul",
+  "fnop",
+  "fpatan",
+  "fprem",
+  "fprem1",
+  "fptan",
+  "frndint",
+  "frstor",
+  "fnsave",
+  "fscale",
+  "fsin",
+  "fsincos",
+  "fsqrt",
+  "fstp",
+  "fstp1",
+  "fstp8",
+  "fstp9",
+  "fst",
+  "fnstcw",
+  "fnstenv",
+  "fnstsw",
+  "fsub",
+  "fsubp",
+  "fsubr",
+  "fsubrp",
+  "ftst",
+  "fucom",
+  "fucomp",
+  "fucompp",
+  "fxam",
+  "fxch",
+  "fxch4",
+  "fxch7",
+  "fxrstor",
+  "fxsave",
+  "fpxtract",
+  "fyl2x",
+  "fyl2xp1",
+  "haddpd",
+  "haddps",
+  "hlt",
+  "hsubpd",
+  "hsubps",
+  "idiv",
+  "in",
+  "imul",
+  "inc",
+  "insb",
+  "insw",
+  "insd",
+  "int1",
+  "int3",
+  "int",
+  "into",
+  "invd",
+  "invlpg",
+  "invlpga",
+  "iretw",
+  "iretd",
+  "iretq",
+  "jo",
+  "jno",
+  "jb",
+  "jae",
+  "jz",
+  "jnz",
+  "jbe",
+  "ja",
+  "js",
+  "jns",
+  "jp",
+  "jnp",
+  "jl",
+  "jge",
+  "jle",
+  "jg",
+  "jcxz",
+  "jecxz",
+  "jrcxz",
+  "jmp",
+  "lahf",
+  "lar",
+  "lddqu",
+  "ldmxcsr",
+  "lds",
+  "lea",
+  "les",
+  "lfs",
+  "lgs",
+  "lidt",
+  "lss",
+  "leave",
+  "lfence",
+  "lgdt",
+  "lldt",
+  "lmsw",
+  "lock",
+  "lodsb",
+  "lodsw",
+  "lodsd",
+  "lodsq",
+  "loopnz",
+  "loope",
+  "loop",
+  "lsl",
+  "ltr",
+  "maskmovq",
+  "maxpd",
+  "maxps",
+  "maxsd",
+  "maxss",
+  "mfence",
+  "minpd",
+  "minps",
+  "minsd",
+  "minss",
+  "monitor",
+  "mov",
+  "movapd",
+  "movaps",
+  "movd",
+  "movddup",
+  "movdqa",
+  "movdqu",
+  "movdq2q",
+  "movhpd",
+  "movhps",
+  "movlhps",
+  "movlpd",
+  "movlps",
+  "movhlps",
+  "movmskpd",
+  "movmskps",
+  "movntdq",
+  "movnti",
+  "movntpd",
+  "movntps",
+  "movntq",
+  "movq",
+  "movqa",
+  "movq2dq",
+  "movsb",
+  "movsw",
+  "movsd",
+  "movsq",
+  "movsldup",
+  "movshdup",
+  "movss",
+  "movsx",
+  "movupd",
+  "movups",
+  "movzx",
+  "mul",
+  "mulpd",
+  "mulps",
+  "mulsd",
+  "mulss",
+  "mwait",
+  "neg",
+  "nop",
+  "not",
+  "or",
+  "orpd",
+  "orps",
+  "out",
+  "outsb",
+  "outsw",
+  "outsd",
+  "outsq",
+  "packsswb",
+  "packssdw",
+  "packuswb",
+  "paddb",
+  "paddw",
+  "paddq",
+  "paddsb",
+  "paddsw",
+  "paddusb",
+  "paddusw",
+  "pand",
+  "pandn",
+  "pause",
+  "pavgb",
+  "pavgw",
+  "pcmpeqb",
+  "pcmpeqw",
+  "pcmpeqd",
+  "pcmpgtb",
+  "pcmpgtw",
+  "pcmpgtd",
+  "pextrw",
+  "pinsrw",
+  "pmaddwd",
+  "pmaxsw",
+  "pmaxub",
+  "pminsw",
+  "pminub",
+  "pmovmskb",
+  "pmulhuw",
+  "pmulhw",
+  "pmullw",
+  "pmuludq",
+  "pop",
+  "popa",
+  "popad",
+  "popfw",
+  "popfd",
+  "popfq",
+  "por",
+  "prefetch",
+  "prefetchnta",
+  "prefetcht0",
+  "prefetcht1",
+  "prefetcht2",
+  "psadbw",
+  "pshufd",
+  "pshufhw",
+  "pshuflw",
+  "pshufw",
+  "pslldq",
+  "psllw",
+  "pslld",
+  "psllq",
+  "psraw",
+  "psrad",
+  "psrlw",
+  "psrld",
+  "psrlq",
+  "psrldq",
+  "psubb",
+  "psubw",
+  "psubd",
+  "psubq",
+  "psubsb",
+  "psubsw",
+  "psubusb",
+  "psubusw",
+  "punpckhbw",
+  "punpckhwd",
+  "punpckhdq",
+  "punpckhqdq",
+  "punpcklbw",
+  "punpcklwd",
+  "punpckldq",
+  "punpcklqdq",
+  "pi2fw",
+  "pi2fd",
+  "pf2iw",
+  "pf2id",
+  "pfnacc",
+  "pfpnacc",
+  "pfcmpge",
+  "pfmin",
+  "pfrcp",
+  "pfrsqrt",
+  "pfsub",
+  "pfadd",
+  "pfcmpgt",
+  "pfmax",
+  "pfrcpit1",
+  "pfrspit1",
+  "pfsubr",
+  "pfacc",
+  "pfcmpeq",
+  "pfmul",
+  "pfrcpit2",
+  "pmulhrw",
+  "pswapd",
+  "pavgusb",
+  "push",
+  "pusha",
+  "pushad",
+  "pushfw",
+  "pushfd",
+  "pushfq",
+  "pxor",
+  "rcl",
+  "rcr",
+  "rol",
+  "ror",
+  "rcpps",
+  "rcpss",
+  "rdmsr",
+  "rdpmc",
+  "rdtsc",
+  "rdtscp",
+  "repne",
+  "rep",
+  "ret",
+  "retf",
+  "rsm",
+  "rsqrtps",
+  "rsqrtss",
+  "sahf",
+  "sal",
+  "salc",
+  "sar",
+  "shl",
+  "shr",
+  "sbb",
+  "scasb",
+  "scasw",
+  "scasd",
+  "scasq",
+  "seto",
+  "setno",
+  "setb",
+  "setnb",
+  "setz",
+  "setnz",
+  "setbe",
+  "seta",
+  "sets",
+  "setns",
+  "setp",
+  "setnp",
+  "setl",
+  "setge",
+  "setle",
+  "setg",
+  "sfence",
+  "sgdt",
+  "shld",
+  "shrd",
+  "shufpd",
+  "shufps",
+  "sidt",
+  "sldt",
+  "smsw",
+  "sqrtps",
+  "sqrtpd",
+  "sqrtsd",
+  "sqrtss",
+  "stc",
+  "std",
+  "stgi",
+  "sti",
+  "skinit",
+  "stmxcsr",
+  "stosb",
+  "stosw",
+  "stosd",
+  "stosq",
+  "str",
+  "sub",
+  "subpd",
+  "subps",
+  "subsd",
+  "subss",
+  "swapgs",
+  "syscall",
+  "sysenter",
+  "sysexit",
+  "sysret",
+  "test",
+  "ucomisd",
+  "ucomiss",
+  "ud2",
+  "unpckhpd",
+  "unpckhps",
+  "unpcklps",
+  "unpcklpd",
+  "verr",
+  "verw",
+  "vmcall",
+  "vmclear",
+  "vmxon",
+  "vmptrld",
+  "vmptrst",
+  "vmresume",
+  "vmxoff",
+  "vmrun",
+  "vmmcall",
+  "vmload",
+  "vmsave",
+  "wait",
+  "wbinvd",
+  "wrmsr",
+  "xadd",
+  "xchg",
+  "xlatb",
+  "xor",
+  "xorpd",
+  "xorps",
+  "db",
+  "invalid",
+};
+
+
+
+static struct ud_itab_entry itab__0f[256] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_00__REG },
+  /* 01 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG },
+  /* 02 */  { UD_Ilar,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ilsl,         O_Gv,    O_Ew,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Isyscall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iclts,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isysret,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Iinvd,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Iwbinvd,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iud2,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_0D__REG },
+  /* 0E */  { UD_Ifemms,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovups,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovups,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhps,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_18__REG },
+  /* 19 */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1D */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1E */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1F */  { UD_Inop,         O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 20 */  { UD_Imov,         O_R,     O_C,     O_NONE,  P_rexr },
+  /* 21 */  { UD_Imov,         O_R,     O_D,     O_NONE,  P_rexr },
+  /* 22 */  { UD_Imov,         O_C,     O_R,     O_NONE,  P_rexr },
+  /* 23 */  { UD_Imov,         O_D,     O_R,     O_NONE,  P_rexr },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovaps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovaps,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2ps,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntps,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttps2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtps2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomiss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomiss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iwrmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Irdtsc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Irdmsr,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Irdpmc,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Isysenter,    O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 35 */  { UD_Isysexit,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Icmovo,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 41 */  { UD_Icmovno,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 42 */  { UD_Icmovb,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 43 */  { UD_Icmovae,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 44 */  { UD_Icmovz,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 45 */  { UD_Icmovnz,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 46 */  { UD_Icmovbe,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 47 */  { UD_Icmova,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 48 */  { UD_Icmovs,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 49 */  { UD_Icmovns,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4A */  { UD_Icmovp,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4B */  { UD_Icmovnp,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4C */  { UD_Icmovl,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4D */  { UD_Icmovge,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4E */  { UD_Icmovle,      O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 4F */  { UD_Icmovg,       O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 50 */  { UD_Imovmskps,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtps,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iandps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorps,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtps2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtdq2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxps,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Imovd,        O_P,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovq,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufw,      O_P,     O_Q,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iemms,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_P,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovq,        O_Q,     O_P,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Ijo,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 81 */  { UD_Ijno,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 82 */  { UD_Ijb,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 83 */  { UD_Ijae,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 84 */  { UD_Ijz,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 85 */  { UD_Ijnz,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 86 */  { UD_Ijbe,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 87 */  { UD_Ija,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 88 */  { UD_Ijs,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 89 */  { UD_Ijns,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8A */  { UD_Ijp,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8B */  { UD_Ijnp,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8C */  { UD_Ijl,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8D */  { UD_Ijge,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8E */  { UD_Ijle,         O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 8F */  { UD_Ijg,          O_Jz,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_oso },
+  /* 90 */  { UD_Iseto,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 91 */  { UD_Isetno,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 92 */  { UD_Isetb,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 93 */  { UD_Isetnb,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 94 */  { UD_Isetz,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 95 */  { UD_Isetnz,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 96 */  { UD_Isetbe,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 97 */  { UD_Iseta,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 98 */  { UD_Isets,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 99 */  { UD_Isetns,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9A */  { UD_Isetp,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9B */  { UD_Isetnp,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9C */  { UD_Isetl,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9D */  { UD_Isetge,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9E */  { UD_Isetle,       O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 9F */  { UD_Isetg,        O_Eb,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* A0 */  { UD_Ipush,        O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A1 */  { UD_Ipop,         O_FS,    O_NONE,  O_NONE,  P_none },
+  /* A2 */  { UD_Icpuid,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A3 */  { UD_Ibt,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A4 */  { UD_Ishld,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A5 */  { UD_Ishld,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Ipush,        O_GS,    O_NONE,  O_NONE,  P_none },
+  /* A9 */  { UD_Ipop,         O_GS,    O_NONE,  O_NONE,  P_none },
+  /* AA */  { UD_Irsm,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AB */  { UD_Ibts,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AC */  { UD_Ishrd,        O_Ev,    O_Gv,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AD */  { UD_Ishrd,        O_Ev,    O_Gv,    O_CL,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* AE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG },
+  /* AF */  { UD_Iimul,        O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B0 */  { UD_Icmpxchg,     O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* B1 */  { UD_Icmpxchg,     O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B2 */  { UD_Ilss,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B3 */  { UD_Ibtr,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B4 */  { UD_Ilfs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B5 */  { UD_Ilgs,         O_Gz,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B6 */  { UD_Imovzx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B7 */  { UD_Imovzx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_BA__REG },
+  /* BB */  { UD_Ibtc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BC */  { UD_Ibsf,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BD */  { UD_Ibsr,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BE */  { UD_Imovsx,       O_Gv,    O_Eb,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* BF */  { UD_Imovsx,       O_Gv,    O_Ew,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpps,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Imovnti,      O_M,     O_Gvw,   O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C4 */  { UD_Ipinsrw,      O_P,     O_Ew,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_PR,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C6 */  { UD_Ishufps,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG },
+  /* C8 */  { UD_Ibswap,       O_rAXr8, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* C9 */  { UD_Ibswap,       O_rCXr9, O_NONE,  O_NONE,  P_oso|P_rexw|P_rexb },
+  /* CA */  { UD_Ibswap,       O_rDXr10, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CB */  { UD_Ibswap,       O_rBXr11, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CC */  { UD_Ibswap,       O_rSPr12, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CD */  { UD_Ibswap,       O_rBPr13, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CE */  { UD_Ibswap,       O_rSIr14, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* CF */  { UD_Ibswap,       O_rDIr15, O_NONE,  O_NONE, P_oso|P_rexw|P_rexb },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Ipsrlw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_PR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipaddusb,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipaddusw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Imovntq,      O_M,     O_P,     O_NONE,  P_none },
+  /* E8 */  { UD_Ipsubsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_P,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_00__reg[8] = {
+  /* 00 */  { UD_Isldt,        O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Istr,         O_Ev,    O_NONE,  O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Illdt,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iltr,         O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iverr,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iverw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg[8] = {
+  /* 00 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD },
+  /* 01 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD },
+  /* 02 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_02__MOD },
+  /* 03 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD },
+  /* 04 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_04__MOD },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod[2] = {
+  /* 00 */  { UD_Isgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmcall,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmresume,    O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxoff,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod[2] = {
+  /* 00 */  { UD_Isidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_01__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imonitor,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imwait,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_02__mod[2] = {
+  /* 00 */  { UD_Ilgdt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod[2] = {
+  /* 00 */  { UD_Ilidt,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR },
+  /* 03 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR },
+  /* 04 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR },
+  /* 05 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR },
+  /* 06 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor[2] = {
+  /* 00 */  { UD_Ivmrun,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Ivmmcall,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor[2] = {
+  /* 00 */  { UD_Ivmload,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor[2] = {
+  /* 00 */  { UD_Ivmsave,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor[2] = {
+  /* 00 */  { UD_Istgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor[2] = {
+  /* 00 */  { UD_Iclgi,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor[2] = {
+  /* 00 */  { UD_Iskinit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvlpga,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_04__mod[2] = {
+  /* 00 */  { UD_Ismsw,        O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Ilmsw,        O_Ew,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iinvlpg,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Iswapgs,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor[2] = {
+  /* 00 */  { UD_Irdtscp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_0d__reg[8] = {
+  /* 00 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iprefetch,    O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_18__reg[8] = {
+  /* 00 */  { UD_Iprefetchnta, O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iprefetcht0,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iprefetcht1,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iprefetcht2,  O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_PR,    O_Ib,    O_NONE,  P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ildmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Istmxcsr,     O_Md,    O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD },
+  /* 06 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD },
+  /* 07 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_05__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Ilfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_06__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Imfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod[2] = {
+  /* 00 */  { UD_Iclflush,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Igrp_rm,      O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM },
+};
+
+static struct ud_itab_entry itab__0f__op_ae__reg__op_07__mod__op_01__rm[8] = {
+  /* 00 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Isfence,      O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__0f__op_ba__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ibt,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ibts,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ibtr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ibtc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Icmpxchg8b,   O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrld,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmptrst,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__0F__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__0f__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Ifabs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_If2xm1,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte[256] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iadd,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadd,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Iadd,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iadd,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 05 */  { UD_Iadd,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 06 */  { UD_Ipush,        O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 07 */  { UD_Ipop,         O_ES,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 08 */  { UD_Ior,          O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 09 */  { UD_Ior,          O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0A */  { UD_Ior,          O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 0B */  { UD_Ior,          O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 0C */  { UD_Ior,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 0D */  { UD_Ior,          O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 0E */  { UD_Ipush,        O_CS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iadc,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Iadc,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Iadc,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iadc,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iadc,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 15 */  { UD_Iadc,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 16 */  { UD_Ipush,        O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 17 */  { UD_Ipop,         O_SS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 18 */  { UD_Isbb,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 19 */  { UD_Isbb,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1A */  { UD_Isbb,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 1B */  { UD_Isbb,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 1C */  { UD_Isbb,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 1D */  { UD_Isbb,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 1E */  { UD_Ipush,        O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 1F */  { UD_Ipop,         O_DS,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 20 */  { UD_Iand,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 21 */  { UD_Iand,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 22 */  { UD_Iand,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 23 */  { UD_Iand,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 24 */  { UD_Iand,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 25 */  { UD_Iand,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Idaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 28 */  { UD_Isub,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Isub,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Isub,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Isub,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Isub,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 2D */  { UD_Isub,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Idas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 30 */  { UD_Ixor,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 31 */  { UD_Ixor,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 32 */  { UD_Ixor,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 33 */  { UD_Ixor,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 34 */  { UD_Ixor,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 35 */  { UD_Ixor,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iaaa,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 38 */  { UD_Icmp,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 39 */  { UD_Icmp,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3A */  { UD_Icmp,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 3B */  { UD_Icmp,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 3C */  { UD_Icmp,         O_AL,    O_Ib,    O_NONE,  P_none },
+  /* 3D */  { UD_Icmp,         O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iaas,         O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* 40 */  { UD_Iinc,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 41 */  { UD_Iinc,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 42 */  { UD_Iinc,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 43 */  { UD_Iinc,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 44 */  { UD_Iinc,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 45 */  { UD_Iinc,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 46 */  { UD_Iinc,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 47 */  { UD_Iinc,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 48 */  { UD_Idec,         O_eAX,   O_NONE,  O_NONE,  P_oso },
+  /* 49 */  { UD_Idec,         O_eCX,   O_NONE,  O_NONE,  P_oso },
+  /* 4A */  { UD_Idec,         O_eDX,   O_NONE,  O_NONE,  P_oso },
+  /* 4B */  { UD_Idec,         O_eBX,   O_NONE,  O_NONE,  P_oso },
+  /* 4C */  { UD_Idec,         O_eSP,   O_NONE,  O_NONE,  P_oso },
+  /* 4D */  { UD_Idec,         O_eBP,   O_NONE,  O_NONE,  P_oso },
+  /* 4E */  { UD_Idec,         O_eSI,   O_NONE,  O_NONE,  P_oso },
+  /* 4F */  { UD_Idec,         O_eDI,   O_NONE,  O_NONE,  P_oso },
+  /* 50 */  { UD_Ipush,        O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 51 */  { UD_Ipush,        O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 52 */  { UD_Ipush,        O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 53 */  { UD_Ipush,        O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 54 */  { UD_Ipush,        O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 55 */  { UD_Ipush,        O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 56 */  { UD_Ipush,        O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 57 */  { UD_Ipush,        O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 58 */  { UD_Ipop,         O_rAXr8, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 59 */  { UD_Ipop,         O_rCXr9, O_NONE,  O_NONE,  P_def64|P_depM|P_oso|P_rexb },
+  /* 5A */  { UD_Ipop,         O_rDXr10, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5B */  { UD_Ipop,         O_rBXr11, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5C */  { UD_Ipop,         O_rSPr12, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5D */  { UD_Ipop,         O_rBPr13, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5E */  { UD_Ipop,         O_rSIr14, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 5F */  { UD_Ipop,         O_rDIr15, O_NONE,  O_NONE, P_def64|P_depM|P_oso|P_rexb },
+  /* 60 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_60__OSIZE },
+  /* 61 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_61__OSIZE },
+  /* 62 */  { UD_Ibound,       O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* 63 */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_63__MODE },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Ipush,        O_Iz,    O_NONE,  O_NONE,  P_c1|P_oso },
+  /* 69 */  { UD_Iimul,        O_Gv,    O_Ev,    O_Iz,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipush,        O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* 6B */  { UD_Iimul,        O_Gv,    O_Ev,    O_Ib,    P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Iinsb,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6D */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6D__OSIZE },
+  /* 6E */  { UD_Ioutsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 6F */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_6F__OSIZE },
+  /* 70 */  { UD_Ijo,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 71 */  { UD_Ijno,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 72 */  { UD_Ijb,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 73 */  { UD_Ijae,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 74 */  { UD_Ijz,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 75 */  { UD_Ijnz,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 76 */  { UD_Ijbe,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 77 */  { UD_Ija,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 78 */  { UD_Ijs,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 79 */  { UD_Ijns,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7A */  { UD_Ijp,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7B */  { UD_Ijnp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7C */  { UD_Ijl,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7D */  { UD_Ijge,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7E */  { UD_Ijle,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 7F */  { UD_Ijg,          O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* 80 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_80__REG },
+  /* 81 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_81__REG },
+  /* 82 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_82__REG },
+  /* 83 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_83__REG },
+  /* 84 */  { UD_Itest,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 85 */  { UD_Itest,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 86 */  { UD_Ixchg,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 87 */  { UD_Ixchg,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 88 */  { UD_Imov,         O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 89 */  { UD_Imov,         O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8A */  { UD_Imov,         O_Gb,    O_Eb,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 8B */  { UD_Imov,         O_Gv,    O_Ev,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8C */  { UD_Imov,         O_Ev,    O_S,     O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8D */  { UD_Ilea,         O_Gv,    O_M,     O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 8E */  { UD_Imov,         O_S,     O_Ev,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* 8F */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_8F__REG },
+  /* 90 */  { UD_Ixchg,        O_rAXr8, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 91 */  { UD_Ixchg,        O_rCXr9, O_rAX,   O_NONE,  P_oso|P_rexw|P_rexb },
+  /* 92 */  { UD_Ixchg,        O_rDXr10, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 93 */  { UD_Ixchg,        O_rBXr11, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 94 */  { UD_Ixchg,        O_rSPr12, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 95 */  { UD_Ixchg,        O_rBPr13, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 96 */  { UD_Ixchg,        O_rSIr14, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 97 */  { UD_Ixchg,        O_rDIr15, O_rAX,   O_NONE, P_oso|P_rexw|P_rexb },
+  /* 98 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_98__OSIZE },
+  /* 99 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_99__OSIZE },
+  /* 9A */  { UD_Icall,        O_Ap,    O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 9B */  { UD_Iwait,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9C */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE },
+  /* 9D */  { UD_Igrp_mode,    O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE },
+  /* 9E */  { UD_Isahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 9F */  { UD_Ilahf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A0 */  { UD_Imov,         O_AL,    O_Ob,    O_NONE,  P_none },
+  /* A1 */  { UD_Imov,         O_rAX,   O_Ov,    O_NONE,  P_aso|P_oso|P_rexw },
+  /* A2 */  { UD_Imov,         O_Ob,    O_AL,    O_NONE,  P_none },
+  /* A3 */  { UD_Imov,         O_Ov,    O_rAX,   O_NONE,  P_aso|P_oso|P_rexw },
+  /* A4 */  { UD_Imovsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* A5 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A5__OSIZE },
+  /* A6 */  { UD_Icmpsb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* A7 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_A7__OSIZE },
+  /* A8 */  { UD_Itest,        O_AL,    O_Ib,    O_NONE,  P_none },
+  /* A9 */  { UD_Itest,        O_rAX,   O_Iz,    O_NONE,  P_oso|P_rexw },
+  /* AA */  { UD_Istosb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AB */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AB__OSIZE },
+  /* AC */  { UD_Ilodsb,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_none },
+  /* AD */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AD__OSIZE },
+  /* AE */  { UD_Iscasb,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* AF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AF__OSIZE },
+  /* B0 */  { UD_Imov,         O_ALr8b, O_Ib,    O_NONE,  P_rexb },
+  /* B1 */  { UD_Imov,         O_CLr9b, O_Ib,    O_NONE,  P_rexb },
+  /* B2 */  { UD_Imov,         O_DLr10b, O_Ib,    O_NONE, P_rexb },
+  /* B3 */  { UD_Imov,         O_BLr11b, O_Ib,    O_NONE, P_rexb },
+  /* B4 */  { UD_Imov,         O_AHr12b, O_Ib,    O_NONE, P_rexb },
+  /* B5 */  { UD_Imov,         O_CHr13b, O_Ib,    O_NONE, P_rexb },
+  /* B6 */  { UD_Imov,         O_DHr14b, O_Ib,    O_NONE, P_rexb },
+  /* B7 */  { UD_Imov,         O_BHr15b, O_Ib,    O_NONE, P_rexb },
+  /* B8 */  { UD_Imov,         O_rAXr8, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* B9 */  { UD_Imov,         O_rCXr9, O_Iv,    O_NONE,  P_oso|P_rexw|P_rexb },
+  /* BA */  { UD_Imov,         O_rDXr10, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BB */  { UD_Imov,         O_rBXr11, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BC */  { UD_Imov,         O_rSPr12, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BD */  { UD_Imov,         O_rBPr13, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BE */  { UD_Imov,         O_rSIr14, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* BF */  { UD_Imov,         O_rDIr15, O_Iv,    O_NONE, P_oso|P_rexw|P_rexb },
+  /* C0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C0__REG },
+  /* C1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C1__REG },
+  /* C2 */  { UD_Iret,         O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* C3 */  { UD_Iret,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* C4 */  { UD_Iles,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C5 */  { UD_Ilds,         O_Gv,    O_M,     O_NONE,  P_inv64|P_aso|P_oso },
+  /* C6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C6__REG },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_C7__REG },
+  /* C8 */  { UD_Ienter,       O_Iw,    O_Ib,    O_NONE,  P_def64|P_depM|P_none },
+  /* C9 */  { UD_Ileave,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CA */  { UD_Iretf,        O_Iw,    O_NONE,  O_NONE,  P_none },
+  /* CB */  { UD_Iretf,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CC */  { UD_Iint3,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* CD */  { UD_Iint,         O_Ib,    O_NONE,  O_NONE,  P_none },
+  /* CE */  { UD_Iinto,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* CF */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_CF__OSIZE },
+  /* D0 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D0__REG },
+  /* D1 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D1__REG },
+  /* D2 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D2__REG },
+  /* D3 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D3__REG },
+  /* D4 */  { UD_Iaam,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D5 */  { UD_Iaad,         O_Ib,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D6 */  { UD_Isalc,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_none },
+  /* D7 */  { UD_Ixlatb,       O_NONE,  O_NONE,  O_NONE,  P_rexw },
+  /* D8 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD },
+  /* D9 */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD },
+  /* DA */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD },
+  /* DB */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD },
+  /* DC */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD },
+  /* DD */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD },
+  /* DE */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD },
+  /* DF */  { UD_Igrp_mod,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD },
+  /* E0 */  { UD_Iloopnz,      O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E1 */  { UD_Iloope,       O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E2 */  { UD_Iloop,        O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* E3 */  { UD_Igrp_asize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_E3__ASIZE },
+  /* E4 */  { UD_Iin,          O_AL,    O_Ib,    O_NONE,  P_none },
+  /* E5 */  { UD_Iin,          O_eAX,   O_Ib,    O_NONE,  P_oso },
+  /* E6 */  { UD_Iout,         O_Ib,    O_AL,    O_NONE,  P_none },
+  /* E7 */  { UD_Iout,         O_Ib,    O_eAX,   O_NONE,  P_oso },
+  /* E8 */  { UD_Icall,        O_Jz,    O_NONE,  O_NONE,  P_def64|P_oso },
+  /* E9 */  { UD_Ijmp,         O_Jz,    O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* EA */  { UD_Ijmp,         O_Ap,    O_NONE,  O_NONE,  P_inv64|P_none },
+  /* EB */  { UD_Ijmp,         O_Jb,    O_NONE,  O_NONE,  P_none },
+  /* EC */  { UD_Iin,          O_AL,    O_DX,    O_NONE,  P_none },
+  /* ED */  { UD_Iin,          O_eAX,   O_DX,    O_NONE,  P_oso },
+  /* EE */  { UD_Iout,         O_DX,    O_AL,    O_NONE,  P_none },
+  /* EF */  { UD_Iout,         O_DX,    O_eAX,   O_NONE,  P_oso },
+  /* F0 */  { UD_Ilock,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F1 */  { UD_Iint1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F2 */  { UD_Irepne,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F3 */  { UD_Irep,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F4 */  { UD_Ihlt,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F5 */  { UD_Icmc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F6 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F6__REG },
+  /* F7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_F7__REG },
+  /* F8 */  { UD_Iclc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* F9 */  { UD_Istc,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FA */  { UD_Icli,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FB */  { UD_Isti,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FC */  { UD_Icld,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FD */  { UD_Istd,         O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* FE */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FE__REG },
+  /* FF */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_FF__REG },
+};
+
+static struct ud_itab_entry itab__1byte__op_60__osize[3] = {
+  /* 00 */  { UD_Ipusha,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipushad,      O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_61__osize[3] = {
+  /* 00 */  { UD_Ipopa,        O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 01 */  { UD_Ipopad,       O_NONE,  O_NONE,  O_NONE,  P_inv64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_63__mode[3] = {
+  /* 00 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 01 */  { UD_Iarpl,        O_Ew,    O_Gw,    O_NONE,  P_inv64|P_aso },
+  /* 02 */  { UD_Imovsxd,      O_Gv,    O_Ed,    O_NONE,  P_c2|P_aso|P_oso|P_rexw|P_rexx|P_rexr|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_6d__osize[3] = {
+  /* 00 */  { UD_Iinsw,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Iinsd,        O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_6f__osize[3] = {
+  /* 00 */  { UD_Ioutsw,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 01 */  { UD_Ioutsd,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+  /* 02 */  { UD_Ioutsq,       O_NONE,  O_NONE,  O_NONE,  P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_80__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_81__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_82__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_inv64|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_83__reg[8] = {
+  /* 00 */  { UD_Iadd,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ior,          O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iadc,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Isbb,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iand,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Isub,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ixor,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Icmp,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_8f__reg[8] = {
+  /* 00 */  { UD_Ipop,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_98__osize[3] = {
+  /* 00 */  { UD_Icbw,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icwde,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icdqe,        O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_99__osize[3] = {
+  /* 00 */  { UD_Icwd,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icdq,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icqo,         O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipushfq,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9c__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipushfw,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 01 */  { UD_Ipushfd,      O_NONE,  O_NONE,  O_NONE,  P_def64|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode[3] = {
+  /* 00 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE },
+  /* 01 */  { UD_Igrp_osize,   O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE },
+  /* 02 */  { UD_Ipopfq,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_00__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_9d__mode__op_01__osize[3] = {
+  /* 00 */  { UD_Ipopfw,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 01 */  { UD_Ipopfd,       O_NONE,  O_NONE,  O_NONE,  P_def64|P_depM|P_oso },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_a5__osize[3] = {
+  /* 00 */  { UD_Imovsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Imovsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Imovsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_a7__osize[3] = {
+  /* 00 */  { UD_Icmpsw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Icmpsd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Icmpsq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ab__osize[3] = {
+  /* 00 */  { UD_Istosw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Istosd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Istosq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ad__osize[3] = {
+  /* 00 */  { UD_Ilodsw,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 01 */  { UD_Ilodsd,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+  /* 02 */  { UD_Ilodsq,       O_NONE,  O_NONE,  O_NONE,  P_ImpAddr|P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_AE__MOD__OP_00__REG },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ae__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifxsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifxrstor,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_af__osize[3] = {
+  /* 00 */  { UD_Iscasw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iscasd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iscasq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_c0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_Ib,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_c6__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_c7__reg[8] = {
+  /* 00 */  { UD_Imov,         O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_cf__osize[3] = {
+  /* 00 */  { UD_Iiretw,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 01 */  { UD_Iiretd,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+  /* 02 */  { UD_Iiretq,       O_NONE,  O_NONE,  O_NONE,  P_oso|P_rexw },
+};
+
+static struct ud_itab_entry itab__1byte__op_d0__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_I1,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d1__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_I1,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d2__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Eb,    O_CL,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Eb,    O_CL,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d3__reg[8] = {
+  /* 00 */  { UD_Irol,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iror,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ircl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ircr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ishr,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ishl,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Isar,         O_Ev,    O_CL,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D8__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d8__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsub,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsub,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsub,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsub,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsub,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsub,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsub,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdiv,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdiv,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdiv,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdiv,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdiv,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdiv,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdiv,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivr,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivr,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivr,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivr,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivr,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivr,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivr,       O_ST0,   O_ST7,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_D9__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ifst,         O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifldenv,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifldcw,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifnstenv,     O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstcw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_d9__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifld,         O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifld,         O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifld,         O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifld,         O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifld,         O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifld,         O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifld,         O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifld,         O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch,        O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch,        O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch,        O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch,        O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch,        O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch,        O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch,        O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifnop,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Ifstp1,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp1,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp1,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp1,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp1,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp1,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp1,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp1,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifchs,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iftst,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifxam,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifld1,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifldl2t,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifldl2e,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifldlpi,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifldlg2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifldln2,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifldz,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Ifyl2x,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 32 */  { UD_Ifptan,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 33 */  { UD_Ifpatan,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 34 */  { UD_Ifpxtract,    O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 35 */  { UD_Ifprem1,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 36 */  { UD_Ifdecstp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 37 */  { UD_Ifncstp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 38 */  { UD_Ifprem,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 39 */  { UD_Ifyl2xp1,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3A */  { UD_Ifsqrt,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3B */  { UD_Ifsincos,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3C */  { UD_Ifrndint,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3D */  { UD_Ifscale,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3E */  { UD_Ifsin,        O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 3F */  { UD_Ifcos,        O_NONE,  O_NONE,  O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DA__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_da__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovb,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovb,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovb,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovb,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovb,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovb,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovb,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovb,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmove,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmove,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmove,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmove,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmove,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmove,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmove,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmove,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovbe,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovbe,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovbe,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovbe,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovbe,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovbe,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovbe,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovbe,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovu,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovu,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovu,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovu,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovu,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovu,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovu,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovu,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Ifucompp,     O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DB__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Md,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Ifld,         O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Ifstp,        O_Mt,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_db__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifcmovnb,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifcmovnb,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifcmovnb,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifcmovnb,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifcmovnb,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifcmovnb,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifcmovnb,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifcmovnb,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifcmovne,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifcmovne,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifcmovne,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifcmovne,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifcmovne,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifcmovne,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifcmovne,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifcmovne,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcmovnbe,    O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 11 */  { UD_Ifcmovnbe,    O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 12 */  { UD_Ifcmovnbe,    O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 13 */  { UD_Ifcmovnbe,    O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 14 */  { UD_Ifcmovnbe,    O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 15 */  { UD_Ifcmovnbe,    O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 16 */  { UD_Ifcmovnbe,    O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 17 */  { UD_Ifcmovnbe,    O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 18 */  { UD_Ifcmovnu,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 19 */  { UD_Ifcmovnu,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 1A */  { UD_Ifcmovnu,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 1B */  { UD_Ifcmovnu,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 1C */  { UD_Ifcmovnu,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 1D */  { UD_Ifcmovnu,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 1E */  { UD_Ifcmovnu,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 1F */  { UD_Ifcmovnu,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Ifclex,       O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifninit,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomi,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomi,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomi,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomi,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomi,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomi,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomi,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomi,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomi,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomi,       O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomi,       O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomi,       O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomi,       O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomi,       O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomi,       O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomi,       O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DC__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifadd,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifmul,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifcom,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifcomp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifsub,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifsubr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifdiv,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifdivr,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dc__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifadd,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifadd,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifadd,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifadd,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifadd,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifadd,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifadd,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifadd,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmul,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmul,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmul,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmul,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmul,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmul,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmul,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmul,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcom2,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcom2,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcom2,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcom2,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcom2,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcom2,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcom2,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcom2,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifcomp3,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifcomp3,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifcomp3,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifcomp3,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifcomp3,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifcomp3,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifcomp3,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifcomp3,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifsubr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsub,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsub,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsub,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsub,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsub,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsub,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsub,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsub,        O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivr,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivr,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivr,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivr,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivr,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivr,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivr,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivr,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdiv,        O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdiv,        O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdiv,        O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdiv,        O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdiv,        O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdiv,        O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdiv,        O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdiv,        O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DD__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifld,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifst,         O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifstp,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifrstor,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ifnsave,      O_M,     O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifnstsw,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_dd__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffree,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffree,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffree,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffree,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffree,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffree,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffree,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffree,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch4,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch4,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch4,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch4,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch4,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch4,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch4,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch4,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifst,         O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifst,         O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifst,         O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifst,         O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifst,         O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifst,         O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifst,         O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifst,         O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp,        O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp,        O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp,        O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp,        O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp,        O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp,        O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp,        O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp,        O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifucom,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Ifucom,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 22 */  { UD_Ifucom,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 23 */  { UD_Ifucom,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 24 */  { UD_Ifucom,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 25 */  { UD_Ifucom,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 26 */  { UD_Ifucom,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 27 */  { UD_Ifucom,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 28 */  { UD_Ifucomp,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomp,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomp,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomp,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomp,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomp,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomp,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomp,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DE__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifiadd,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifimul,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ificom,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ificomp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifisub,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifisubr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifidiv,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifidivr,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_de__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Ifaddp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 01 */  { UD_Ifaddp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 02 */  { UD_Ifaddp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 03 */  { UD_Ifaddp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 04 */  { UD_Ifaddp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 05 */  { UD_Ifaddp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 06 */  { UD_Ifaddp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 07 */  { UD_Ifaddp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 08 */  { UD_Ifmulp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 09 */  { UD_Ifmulp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 0A */  { UD_Ifmulp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 0B */  { UD_Ifmulp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 0C */  { UD_Ifmulp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 0D */  { UD_Ifmulp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 0E */  { UD_Ifmulp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 0F */  { UD_Ifmulp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 10 */  { UD_Ifcomp5,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifcomp5,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifcomp5,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifcomp5,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifcomp5,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifcomp5,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifcomp5,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifcomp5,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Ifcompp,      O_NONE,  O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Ifsubrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 21 */  { UD_Ifsubrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 22 */  { UD_Ifsubrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 23 */  { UD_Ifsubrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 24 */  { UD_Ifsubrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 25 */  { UD_Ifsubrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 26 */  { UD_Ifsubrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 27 */  { UD_Ifsubrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 28 */  { UD_Ifsubp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifsubp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifsubp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifsubp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifsubp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifsubp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifsubp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifsubp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifdivrp,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifdivrp,      O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifdivrp,      O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifdivrp,      O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifdivrp,      O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifdivrp,      O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifdivrp,      O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifdivrp,      O_ST7,   O_ST0,   O_NONE,  P_none },
+  /* 38 */  { UD_Ifdivp,       O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 39 */  { UD_Ifdivp,       O_ST1,   O_ST0,   O_NONE,  P_none },
+  /* 3A */  { UD_Ifdivp,       O_ST2,   O_ST0,   O_NONE,  P_none },
+  /* 3B */  { UD_Ifdivp,       O_ST3,   O_ST0,   O_NONE,  P_none },
+  /* 3C */  { UD_Ifdivp,       O_ST4,   O_ST0,   O_NONE,  P_none },
+  /* 3D */  { UD_Ifdivp,       O_ST5,   O_ST0,   O_NONE,  P_none },
+  /* 3E */  { UD_Ifdivp,       O_ST6,   O_ST0,   O_NONE,  P_none },
+  /* 3F */  { UD_Ifdivp,       O_ST7,   O_ST0,   O_NONE,  P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod[2] = {
+  /* 00 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_00__REG },
+  /* 01 */  { UD_Igrp_x87,     O_NONE, O_NONE, O_NONE,    ITAB__1BYTE__OP_DF__MOD__OP_01__X87 },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_00__reg[8] = {
+  /* 00 */  { UD_Ifild,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Ifisttp,      O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Ifist,        O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ifistp,       O_Mw,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ifbld,        O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ifild,        O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ifbstp,       O_Mt,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Ifistp,       O_Mq,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_df__mod__op_01__x87[64] = {
+  /* 00 */  { UD_Iffreep,      O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 01 */  { UD_Iffreep,      O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 02 */  { UD_Iffreep,      O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 03 */  { UD_Iffreep,      O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 04 */  { UD_Iffreep,      O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 05 */  { UD_Iffreep,      O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 06 */  { UD_Iffreep,      O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 07 */  { UD_Iffreep,      O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 08 */  { UD_Ifxch7,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 09 */  { UD_Ifxch7,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 0A */  { UD_Ifxch7,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 0B */  { UD_Ifxch7,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 0C */  { UD_Ifxch7,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 0D */  { UD_Ifxch7,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 0E */  { UD_Ifxch7,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 0F */  { UD_Ifxch7,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 10 */  { UD_Ifstp8,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 11 */  { UD_Ifstp8,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 12 */  { UD_Ifstp8,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 13 */  { UD_Ifstp8,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 14 */  { UD_Ifstp8,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 15 */  { UD_Ifstp8,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 16 */  { UD_Ifstp8,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 17 */  { UD_Ifstp8,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 18 */  { UD_Ifstp9,       O_ST0,   O_NONE,  O_NONE,  P_none },
+  /* 19 */  { UD_Ifstp9,       O_ST1,   O_NONE,  O_NONE,  P_none },
+  /* 1A */  { UD_Ifstp9,       O_ST2,   O_NONE,  O_NONE,  P_none },
+  /* 1B */  { UD_Ifstp9,       O_ST3,   O_NONE,  O_NONE,  P_none },
+  /* 1C */  { UD_Ifstp9,       O_ST4,   O_NONE,  O_NONE,  P_none },
+  /* 1D */  { UD_Ifstp9,       O_ST5,   O_NONE,  O_NONE,  P_none },
+  /* 1E */  { UD_Ifstp9,       O_ST6,   O_NONE,  O_NONE,  P_none },
+  /* 1F */  { UD_Ifstp9,       O_ST7,   O_NONE,  O_NONE,  P_none },
+  /* 20 */  { UD_Ifnstsw,      O_AX,    O_NONE,  O_NONE,  P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Ifucomip,     O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 29 */  { UD_Ifucomip,     O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 2A */  { UD_Ifucomip,     O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 2B */  { UD_Ifucomip,     O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 2C */  { UD_Ifucomip,     O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 2D */  { UD_Ifucomip,     O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 2E */  { UD_Ifucomip,     O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 2F */  { UD_Ifucomip,     O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 30 */  { UD_Ifcomip,      O_ST0,   O_ST0,   O_NONE,  P_none },
+  /* 31 */  { UD_Ifcomip,      O_ST0,   O_ST1,   O_NONE,  P_none },
+  /* 32 */  { UD_Ifcomip,      O_ST0,   O_ST2,   O_NONE,  P_none },
+  /* 33 */  { UD_Ifcomip,      O_ST0,   O_ST3,   O_NONE,  P_none },
+  /* 34 */  { UD_Ifcomip,      O_ST0,   O_ST4,   O_NONE,  P_none },
+  /* 35 */  { UD_Ifcomip,      O_ST0,   O_ST5,   O_NONE,  P_none },
+  /* 36 */  { UD_Ifcomip,      O_ST0,   O_ST6,   O_NONE,  P_none },
+  /* 37 */  { UD_Ifcomip,      O_ST0,   O_ST7,   O_NONE,  P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_e3__asize[3] = {
+  /* 00 */  { UD_Ijcxz,        O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 01 */  { UD_Ijecxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+  /* 02 */  { UD_Ijrcxz,       O_Jb,    O_NONE,  O_NONE,  P_aso },
+};
+
+static struct ud_itab_entry itab__1byte__op_f6__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Eb,    O_Ib,    O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_f7__reg[8] = {
+  /* 00 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Itest,        O_Ev,    O_Iz,    O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Inot,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Ineg,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Imul,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Iimul,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Idiv,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iidiv,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__1byte__op_fe__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Eb,    O_NONE,  O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__1byte__op_ff__reg[8] = {
+  /* 00 */  { UD_Iinc,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 01 */  { UD_Idec,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 02 */  { UD_Icall,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 03 */  { UD_Icall,        O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 04 */  { UD_Ijmp,         O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_depM|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 05 */  { UD_Ijmp,         O_Ep,    O_NONE,  O_NONE,  P_c1|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 06 */  { UD_Ipush,        O_Ev,    O_NONE,  O_NONE,  P_c1|P_def64|P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__3dnow[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 11 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 12 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 59 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovupd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovupd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovlpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Imovlpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 14 */  { UD_Iunpcklpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 15 */  { UD_Iunpckhpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 16 */  { UD_Imovhpd,      O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Imovhpd,      O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Imovapd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 29 */  { UD_Imovapd,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2A */  { UD_Icvtpi2pd,    O_V,     O_Q,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Imovntpd,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2C */  { UD_Icvttpd2pi,   O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtpd2pi,    O_P,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iucomisd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2F */  { UD_Icomisd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Imovmskpd,    O_Gd,    O_VR,    O_NONE,  P_oso|P_rexr|P_rexb },
+  /* 51 */  { UD_Isqrtpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iandpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 55 */  { UD_Iandnpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 56 */  { UD_Iorpd,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 57 */  { UD_Ixorpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 58 */  { UD_Iaddpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtpd2ps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvtps2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxpd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Ipunpcklbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 61 */  { UD_Ipunpcklwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 62 */  { UD_Ipunpckldq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 63 */  { UD_Ipacksswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 64 */  { UD_Ipcmpgtb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 65 */  { UD_Ipcmpgtw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 66 */  { UD_Ipcmpgtd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 67 */  { UD_Ipackuswb,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 68 */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 69 */  { UD_Ipunpckhwd,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6A */  { UD_Ipunpckhdq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6B */  { UD_Ipackssdw,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6C */  { UD_Ipunpcklqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6D */  { UD_Ipunpckhqdq,  O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 6E */  { UD_Imovd,        O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 6F */  { UD_Imovqa,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_71__REG },
+  /* 72 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_72__REG },
+  /* 73 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_73__REG },
+  /* 74 */  { UD_Ipcmpeqb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 75 */  { UD_Ipcmpeqw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 76 */  { UD_Ipcmpeqd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubpd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Imovd,        O_Ex,    O_V,     O_NONE,  P_c1|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqa,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmppd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Ipinsrw,      O_V,     O_Ew,    O_Ib,    P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C5 */  { UD_Ipextrw,      O_Gd,    O_VR,    O_Ib,    P_aso|P_rexr|P_rexb },
+  /* C6 */  { UD_Ishufpd,      O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubpd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Ipsrlw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D2 */  { UD_Ipsrld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D3 */  { UD_Ipsrlq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D4 */  { UD_Ipaddq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D5 */  { UD_Ipmullw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D6 */  { UD_Imovq,        O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D7 */  { UD_Ipmovmskb,    O_Gd,    O_VR,    O_NONE,  P_rexr|P_rexb },
+  /* D8 */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D9 */  { UD_Ipsubusw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DA */  { UD_Ipminub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DB */  { UD_Ipand,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DC */  { UD_Ipsubusb,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DD */  { UD_Ipunpckhbw,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DE */  { UD_Ipmaxub,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* DF */  { UD_Ipandn,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E0 */  { UD_Ipavgb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E1 */  { UD_Ipsraw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E2 */  { UD_Ipsrad,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E3 */  { UD_Ipavgw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E4 */  { UD_Ipmulhuw,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E5 */  { UD_Ipmulhw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E6 */  { UD_Icvttpd2dq,   O_V,     O_W,     O_NONE,  P_none },
+  /* E7 */  { UD_Imovntdq,     O_M,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E8 */  { UD_Ipsubsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E9 */  { UD_Ipsubsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EA */  { UD_Ipminsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EB */  { UD_Ipor,         O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EC */  { UD_Ipaddsb,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* ED */  { UD_Ipaddsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EE */  { UD_Ipmaxsw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* EF */  { UD_Ipxor,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Ipsllw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F2 */  { UD_Ipslld,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F3 */  { UD_Ipsllq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F4 */  { UD_Ipmuludq,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F5 */  { UD_Ipmaddwd,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F6 */  { UD_Ipsadbw,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F7 */  { UD_Imaskmovq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F8 */  { UD_Ipsubb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F9 */  { UD_Ipsubw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FA */  { UD_Ipsubd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FB */  { UD_Ipsubq,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FC */  { UD_Ipaddb,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FD */  { UD_Ipaddw,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_71__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsraw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllw,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_72__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Ipsrad,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipslld,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_73__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Ipsrlq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 03 */  { UD_Ipsrldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Ipsllq,       O_VR,    O_Ib,    O_NONE,  P_rexb },
+  /* 07 */  { UD_Ipslldq,      O_VR,    O_Ib,    O_NONE,  P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_sse66__0f__op_c7__reg__op_00__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmclear,     O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+static struct ud_itab_entry itab__pfx_ssef2__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovsd,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovddup,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2sd,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttsd2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtsd2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtsd,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 53 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtsd2ss,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 5C */  { UD_Isubsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxsd,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 70 */  { UD_Ipshuflw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Ihaddps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7D */  { UD_Ihsubps,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_oso|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpsd,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iaddsubps,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovdq2q,     O_P,     O_VR,    O_NONE,  P_aso|P_rexb },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtpd2dq,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Ilddqu,       O_V,     O_M,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f[256] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 08 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 09 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 0F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 10 */  { UD_Imovss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 11 */  { UD_Imovss,       O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 12 */  { UD_Imovsldup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 13 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 14 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 15 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 16 */  { UD_Imovshdup,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 17 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 18 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 19 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 1F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 20 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 21 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 22 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 23 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 24 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 25 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 26 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 27 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 28 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 29 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2A */  { UD_Icvtsi2ss,    O_V,     O_Ex,    O_NONE,  P_c2|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2C */  { UD_Icvttss2si,   O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2D */  { UD_Icvtss2si,    O_Gvw,   O_W,     O_NONE,  P_c1|P_aso|P_rexr|P_rexx|P_rexb },
+  /* 2E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 2F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 30 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 31 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 32 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 33 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 34 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 35 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 36 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 37 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 38 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 39 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 3F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 40 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 41 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 42 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 43 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 44 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 45 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 46 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 47 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 48 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 49 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 4F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 50 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 51 */  { UD_Isqrtss,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 52 */  { UD_Irsqrtss,     O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 53 */  { UD_Ircpss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 54 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 55 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 56 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 57 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 58 */  { UD_Iaddss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 59 */  { UD_Imulss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5A */  { UD_Icvtss2sd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5B */  { UD_Icvttps2dq,   O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5C */  { UD_Isubss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5D */  { UD_Iminss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5E */  { UD_Idivss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 5F */  { UD_Imaxss,       O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 60 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 61 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 62 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 63 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 64 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 65 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 66 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 67 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 68 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 69 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 6F */  { UD_Imovdqu,      O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 70 */  { UD_Ipshufhw,     O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* 71 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 72 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 73 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 74 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 75 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 76 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 77 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 78 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 79 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 7E */  { UD_Imovq,        O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 7F */  { UD_Imovdqu,      O_W,     O_V,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* 80 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 81 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 82 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 83 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 84 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 85 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 86 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 87 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 88 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 89 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 8F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 90 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 91 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 92 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 93 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 94 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 95 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 96 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 97 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 98 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 99 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9A */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9B */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9C */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9D */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9E */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 9F */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* A9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* AF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* B9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* BF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C0 */  { UD_Ixadd,        O_Eb,    O_Gb,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C1 */  { UD_Ixadd,        O_Ev,    O_Gv,    O_NONE,  P_aso|P_rexw|P_rexr|P_rexx|P_rexb },
+  /* C2 */  { UD_Icmpss,       O_V,     O_W,     O_Ib,    P_aso|P_rexr|P_rexx|P_rexb },
+  /* C3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C7 */  { UD_Igrp_reg,     O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG },
+  /* C8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* C9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* CF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D6 */  { UD_Imovq2dq,     O_V,     O_PR,    O_NONE,  P_aso },
+  /* D7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* D9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* DF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E6 */  { UD_Icvtdq2pd,    O_V,     O_W,     O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+  /* E7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* E9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* ED */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* EF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F0 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F1 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F2 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F3 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F4 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F5 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F6 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F7 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F8 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* F9 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FA */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FB */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FC */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FD */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FE */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* FF */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg[8] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 02 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 03 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 04 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 05 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 06 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 07 */  { UD_Igrp_vendor,  O_NONE, O_NONE, O_NONE,    ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR },
+};
+
+static struct ud_itab_entry itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor[2] = {
+  /* 00 */  { UD_Iinvalid,     O_NONE, O_NONE, O_NONE,    P_none },
+  /* 01 */  { UD_Ivmxon,       O_Mq,    O_NONE,  O_NONE,  P_aso|P_rexr|P_rexx|P_rexb },
+};
+
+/* the order of this table matches enum ud_itab_index */
+struct ud_itab_entry * ud_itab_list[] = {
+  itab__0f,
+  itab__0f__op_00__reg,
+  itab__0f__op_01__reg,
+  itab__0f__op_01__reg__op_00__mod,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_00__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_01__mod,
+  itab__0f__op_01__reg__op_01__mod__op_01__rm,
+  itab__0f__op_01__reg__op_02__mod,
+  itab__0f__op_01__reg__op_03__mod,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_00__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_02__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_03__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_04__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_05__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_06__vendor,
+  itab__0f__op_01__reg__op_03__mod__op_01__rm__op_07__vendor,
+  itab__0f__op_01__reg__op_04__mod,
+  itab__0f__op_01__reg__op_06__mod,
+  itab__0f__op_01__reg__op_07__mod,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm,
+  itab__0f__op_01__reg__op_07__mod__op_01__rm__op_01__vendor,
+  itab__0f__op_0d__reg,
+  itab__0f__op_18__reg,
+  itab__0f__op_71__reg,
+  itab__0f__op_72__reg,
+  itab__0f__op_73__reg,
+  itab__0f__op_ae__reg,
+  itab__0f__op_ae__reg__op_05__mod,
+  itab__0f__op_ae__reg__op_05__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_06__mod,
+  itab__0f__op_ae__reg__op_06__mod__op_01__rm,
+  itab__0f__op_ae__reg__op_07__mod,
+  itab__0f__op_ae__reg__op_07__mod__op_01__rm,
+  itab__0f__op_ba__reg,
+  itab__0f__op_c7__reg,
+  itab__0f__op_c7__reg__op_00__vendor,
+  itab__0f__op_c7__reg__op_07__vendor,
+  itab__0f__op_d9__mod,
+  itab__0f__op_d9__mod__op_01__x87,
+  itab__1byte,
+  itab__1byte__op_60__osize,
+  itab__1byte__op_61__osize,
+  itab__1byte__op_63__mode,
+  itab__1byte__op_6d__osize,
+  itab__1byte__op_6f__osize,
+  itab__1byte__op_80__reg,
+  itab__1byte__op_81__reg,
+  itab__1byte__op_82__reg,
+  itab__1byte__op_83__reg,
+  itab__1byte__op_8f__reg,
+  itab__1byte__op_98__osize,
+  itab__1byte__op_99__osize,
+  itab__1byte__op_9c__mode,
+  itab__1byte__op_9c__mode__op_00__osize,
+  itab__1byte__op_9c__mode__op_01__osize,
+  itab__1byte__op_9d__mode,
+  itab__1byte__op_9d__mode__op_00__osize,
+  itab__1byte__op_9d__mode__op_01__osize,
+  itab__1byte__op_a5__osize,
+  itab__1byte__op_a7__osize,
+  itab__1byte__op_ab__osize,
+  itab__1byte__op_ad__osize,
+  itab__1byte__op_ae__mod,
+  itab__1byte__op_ae__mod__op_00__reg,
+  itab__1byte__op_af__osize,
+  itab__1byte__op_c0__reg,
+  itab__1byte__op_c1__reg,
+  itab__1byte__op_c6__reg,
+  itab__1byte__op_c7__reg,
+  itab__1byte__op_cf__osize,
+  itab__1byte__op_d0__reg,
+  itab__1byte__op_d1__reg,
+  itab__1byte__op_d2__reg,
+  itab__1byte__op_d3__reg,
+  itab__1byte__op_d8__mod,
+  itab__1byte__op_d8__mod__op_00__reg,
+  itab__1byte__op_d8__mod__op_01__x87,
+  itab__1byte__op_d9__mod,
+  itab__1byte__op_d9__mod__op_00__reg,
+  itab__1byte__op_d9__mod__op_01__x87,
+  itab__1byte__op_da__mod,
+  itab__1byte__op_da__mod__op_00__reg,
+  itab__1byte__op_da__mod__op_01__x87,
+  itab__1byte__op_db__mod,
+  itab__1byte__op_db__mod__op_00__reg,
+  itab__1byte__op_db__mod__op_01__x87,
+  itab__1byte__op_dc__mod,
+  itab__1byte__op_dc__mod__op_00__reg,
+  itab__1byte__op_dc__mod__op_01__x87,
+  itab__1byte__op_dd__mod,
+  itab__1byte__op_dd__mod__op_00__reg,
+  itab__1byte__op_dd__mod__op_01__x87,
+  itab__1byte__op_de__mod,
+  itab__1byte__op_de__mod__op_00__reg,
+  itab__1byte__op_de__mod__op_01__x87,
+  itab__1byte__op_df__mod,
+  itab__1byte__op_df__mod__op_00__reg,
+  itab__1byte__op_df__mod__op_01__x87,
+  itab__1byte__op_e3__asize,
+  itab__1byte__op_f6__reg,
+  itab__1byte__op_f7__reg,
+  itab__1byte__op_fe__reg,
+  itab__1byte__op_ff__reg,
+  itab__3dnow,
+  itab__pfx_sse66__0f,
+  itab__pfx_sse66__0f__op_71__reg,
+  itab__pfx_sse66__0f__op_72__reg,
+  itab__pfx_sse66__0f__op_73__reg,
+  itab__pfx_sse66__0f__op_c7__reg,
+  itab__pfx_sse66__0f__op_c7__reg__op_00__vendor,
+  itab__pfx_ssef2__0f,
+  itab__pfx_ssef3__0f,
+  itab__pfx_ssef3__0f__op_c7__reg,
+  itab__pfx_ssef3__0f__op_c7__reg__op_07__vendor,
+};
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/itab.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/itab.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,719 @@
+
+/* itab.h -- auto generated by opgen.py, do not edit. */
+
+#ifndef UD_ITAB_H
+#define UD_ITAB_H
+
+
+
+enum ud_itab_vendor_index {
+  ITAB__VENDOR_INDX__AMD,
+  ITAB__VENDOR_INDX__INTEL,
+};
+
+
+enum ud_itab_mode_index {
+  ITAB__MODE_INDX__16,
+  ITAB__MODE_INDX__32,
+  ITAB__MODE_INDX__64
+};
+
+
+enum ud_itab_mod_index {
+  ITAB__MOD_INDX__NOT_11,
+  ITAB__MOD_INDX__11
+};
+
+
+enum ud_itab_index {
+  ITAB__0F,
+  ITAB__0F__OP_00__REG,
+  ITAB__0F__OP_01__REG,
+  ITAB__0F__OP_01__REG__OP_00__MOD,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_00__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_01__MOD,
+  ITAB__0F__OP_01__REG__OP_01__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_02__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_00__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_02__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_03__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_04__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_05__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_06__VENDOR,
+  ITAB__0F__OP_01__REG__OP_03__MOD__OP_01__RM__OP_07__VENDOR,
+  ITAB__0F__OP_01__REG__OP_04__MOD,
+  ITAB__0F__OP_01__REG__OP_06__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_01__REG__OP_07__MOD__OP_01__RM__OP_01__VENDOR,
+  ITAB__0F__OP_0D__REG,
+  ITAB__0F__OP_18__REG,
+  ITAB__0F__OP_71__REG,
+  ITAB__0F__OP_72__REG,
+  ITAB__0F__OP_73__REG,
+  ITAB__0F__OP_AE__REG,
+  ITAB__0F__OP_AE__REG__OP_05__MOD,
+  ITAB__0F__OP_AE__REG__OP_05__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_06__MOD,
+  ITAB__0F__OP_AE__REG__OP_06__MOD__OP_01__RM,
+  ITAB__0F__OP_AE__REG__OP_07__MOD,
+  ITAB__0F__OP_AE__REG__OP_07__MOD__OP_01__RM,
+  ITAB__0F__OP_BA__REG,
+  ITAB__0F__OP_C7__REG,
+  ITAB__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__0F__OP_C7__REG__OP_07__VENDOR,
+  ITAB__0F__OP_D9__MOD,
+  ITAB__0F__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE,
+  ITAB__1BYTE__OP_60__OSIZE,
+  ITAB__1BYTE__OP_61__OSIZE,
+  ITAB__1BYTE__OP_63__MODE,
+  ITAB__1BYTE__OP_6D__OSIZE,
+  ITAB__1BYTE__OP_6F__OSIZE,
+  ITAB__1BYTE__OP_80__REG,
+  ITAB__1BYTE__OP_81__REG,
+  ITAB__1BYTE__OP_82__REG,
+  ITAB__1BYTE__OP_83__REG,
+  ITAB__1BYTE__OP_8F__REG,
+  ITAB__1BYTE__OP_98__OSIZE,
+  ITAB__1BYTE__OP_99__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE,
+  ITAB__1BYTE__OP_9C__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9C__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE,
+  ITAB__1BYTE__OP_9D__MODE__OP_00__OSIZE,
+  ITAB__1BYTE__OP_9D__MODE__OP_01__OSIZE,
+  ITAB__1BYTE__OP_A5__OSIZE,
+  ITAB__1BYTE__OP_A7__OSIZE,
+  ITAB__1BYTE__OP_AB__OSIZE,
+  ITAB__1BYTE__OP_AD__OSIZE,
+  ITAB__1BYTE__OP_AE__MOD,
+  ITAB__1BYTE__OP_AE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_AF__OSIZE,
+  ITAB__1BYTE__OP_C0__REG,
+  ITAB__1BYTE__OP_C1__REG,
+  ITAB__1BYTE__OP_C6__REG,
+  ITAB__1BYTE__OP_C7__REG,
+  ITAB__1BYTE__OP_CF__OSIZE,
+  ITAB__1BYTE__OP_D0__REG,
+  ITAB__1BYTE__OP_D1__REG,
+  ITAB__1BYTE__OP_D2__REG,
+  ITAB__1BYTE__OP_D3__REG,
+  ITAB__1BYTE__OP_D8__MOD,
+  ITAB__1BYTE__OP_D8__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D8__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_D9__MOD,
+  ITAB__1BYTE__OP_D9__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_D9__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DA__MOD,
+  ITAB__1BYTE__OP_DA__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DA__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DB__MOD,
+  ITAB__1BYTE__OP_DB__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DB__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DC__MOD,
+  ITAB__1BYTE__OP_DC__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DC__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DD__MOD,
+  ITAB__1BYTE__OP_DD__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DD__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DE__MOD,
+  ITAB__1BYTE__OP_DE__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DE__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_DF__MOD,
+  ITAB__1BYTE__OP_DF__MOD__OP_00__REG,
+  ITAB__1BYTE__OP_DF__MOD__OP_01__X87,
+  ITAB__1BYTE__OP_E3__ASIZE,
+  ITAB__1BYTE__OP_F6__REG,
+  ITAB__1BYTE__OP_F7__REG,
+  ITAB__1BYTE__OP_FE__REG,
+  ITAB__1BYTE__OP_FF__REG,
+  ITAB__3DNOW,
+  ITAB__PFX_SSE66__0F,
+  ITAB__PFX_SSE66__0F__OP_71__REG,
+  ITAB__PFX_SSE66__0F__OP_72__REG,
+  ITAB__PFX_SSE66__0F__OP_73__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG,
+  ITAB__PFX_SSE66__0F__OP_C7__REG__OP_00__VENDOR,
+  ITAB__PFX_SSEF2__0F,
+  ITAB__PFX_SSEF3__0F,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG,
+  ITAB__PFX_SSEF3__0F__OP_C7__REG__OP_07__VENDOR,
+};
+
+
+enum ud_mnemonic_code {
+  UD_I3dnow,
+  UD_Iaaa,
+  UD_Iaad,
+  UD_Iaam,
+  UD_Iaas,
+  UD_Iadc,
+  UD_Iadd,
+  UD_Iaddpd,
+  UD_Iaddps,
+  UD_Iaddsd,
+  UD_Iaddss,
+  UD_Iaddsubpd,
+  UD_Iaddsubps,
+  UD_Iand,
+  UD_Iandpd,
+  UD_Iandps,
+  UD_Iandnpd,
+  UD_Iandnps,
+  UD_Iarpl,
+  UD_Imovsxd,
+  UD_Ibound,
+  UD_Ibsf,
+  UD_Ibsr,
+  UD_Ibswap,
+  UD_Ibt,
+  UD_Ibtc,
+  UD_Ibtr,
+  UD_Ibts,
+  UD_Icall,
+  UD_Icbw,
+  UD_Icwde,
+  UD_Icdqe,
+  UD_Iclc,
+  UD_Icld,
+  UD_Iclflush,
+  UD_Iclgi,
+  UD_Icli,
+  UD_Iclts,
+  UD_Icmc,
+  UD_Icmovo,
+  UD_Icmovno,
+  UD_Icmovb,
+  UD_Icmovae,
+  UD_Icmovz,
+  UD_Icmovnz,
+  UD_Icmovbe,
+  UD_Icmova,
+  UD_Icmovs,
+  UD_Icmovns,
+  UD_Icmovp,
+  UD_Icmovnp,
+  UD_Icmovl,
+  UD_Icmovge,
+  UD_Icmovle,
+  UD_Icmovg,
+  UD_Icmp,
+  UD_Icmppd,
+  UD_Icmpps,
+  UD_Icmpsb,
+  UD_Icmpsw,
+  UD_Icmpsd,
+  UD_Icmpsq,
+  UD_Icmpss,
+  UD_Icmpxchg,
+  UD_Icmpxchg8b,
+  UD_Icomisd,
+  UD_Icomiss,
+  UD_Icpuid,
+  UD_Icvtdq2pd,
+  UD_Icvtdq2ps,
+  UD_Icvtpd2dq,
+  UD_Icvtpd2pi,
+  UD_Icvtpd2ps,
+  UD_Icvtpi2ps,
+  UD_Icvtpi2pd,
+  UD_Icvtps2dq,
+  UD_Icvtps2pi,
+  UD_Icvtps2pd,
+  UD_Icvtsd2si,
+  UD_Icvtsd2ss,
+  UD_Icvtsi2ss,
+  UD_Icvtss2si,
+  UD_Icvtss2sd,
+  UD_Icvttpd2pi,
+  UD_Icvttpd2dq,
+  UD_Icvttps2dq,
+  UD_Icvttps2pi,
+  UD_Icvttsd2si,
+  UD_Icvtsi2sd,
+  UD_Icvttss2si,
+  UD_Icwd,
+  UD_Icdq,
+  UD_Icqo,
+  UD_Idaa,
+  UD_Idas,
+  UD_Idec,
+  UD_Idiv,
+  UD_Idivpd,
+  UD_Idivps,
+  UD_Idivsd,
+  UD_Idivss,
+  UD_Iemms,
+  UD_Ienter,
+  UD_If2xm1,
+  UD_Ifabs,
+  UD_Ifadd,
+  UD_Ifaddp,
+  UD_Ifbld,
+  UD_Ifbstp,
+  UD_Ifchs,
+  UD_Ifclex,
+  UD_Ifcmovb,
+  UD_Ifcmove,
+  UD_Ifcmovbe,
+  UD_Ifcmovu,
+  UD_Ifcmovnb,
+  UD_Ifcmovne,
+  UD_Ifcmovnbe,
+  UD_Ifcmovnu,
+  UD_Ifucomi,
+  UD_Ifcom,
+  UD_Ifcom2,
+  UD_Ifcomp3,
+  UD_Ifcomi,
+  UD_Ifucomip,
+  UD_Ifcomip,
+  UD_Ifcomp,
+  UD_Ifcomp5,
+  UD_Ifcompp,
+  UD_Ifcos,
+  UD_Ifdecstp,
+  UD_Ifdiv,
+  UD_Ifdivp,
+  UD_Ifdivr,
+  UD_Ifdivrp,
+  UD_Ifemms,
+  UD_Iffree,
+  UD_Iffreep,
+  UD_Ificom,
+  UD_Ificomp,
+  UD_Ifild,
+  UD_Ifncstp,
+  UD_Ifninit,
+  UD_Ifiadd,
+  UD_Ifidivr,
+  UD_Ifidiv,
+  UD_Ifisub,
+  UD_Ifisubr,
+  UD_Ifist,
+  UD_Ifistp,
+  UD_Ifisttp,
+  UD_Ifld,
+  UD_Ifld1,
+  UD_Ifldl2t,
+  UD_Ifldl2e,
+  UD_Ifldlpi,
+  UD_Ifldlg2,
+  UD_Ifldln2,
+  UD_Ifldz,
+  UD_Ifldcw,
+  UD_Ifldenv,
+  UD_Ifmul,
+  UD_Ifmulp,
+  UD_Ifimul,
+  UD_Ifnop,
+  UD_Ifpatan,
+  UD_Ifprem,
+  UD_Ifprem1,
+  UD_Ifptan,
+  UD_Ifrndint,
+  UD_Ifrstor,
+  UD_Ifnsave,
+  UD_Ifscale,
+  UD_Ifsin,
+  UD_Ifsincos,
+  UD_Ifsqrt,
+  UD_Ifstp,
+  UD_Ifstp1,
+  UD_Ifstp8,
+  UD_Ifstp9,
+  UD_Ifst,
+  UD_Ifnstcw,
+  UD_Ifnstenv,
+  UD_Ifnstsw,
+  UD_Ifsub,
+  UD_Ifsubp,
+  UD_Ifsubr,
+  UD_Ifsubrp,
+  UD_Iftst,
+  UD_Ifucom,
+  UD_Ifucomp,
+  UD_Ifucompp,
+  UD_Ifxam,
+  UD_Ifxch,
+  UD_Ifxch4,
+  UD_Ifxch7,
+  UD_Ifxrstor,
+  UD_Ifxsave,
+  UD_Ifpxtract,
+  UD_Ifyl2x,
+  UD_Ifyl2xp1,
+  UD_Ihaddpd,
+  UD_Ihaddps,
+  UD_Ihlt,
+  UD_Ihsubpd,
+  UD_Ihsubps,
+  UD_Iidiv,
+  UD_Iin,
+  UD_Iimul,
+  UD_Iinc,
+  UD_Iinsb,
+  UD_Iinsw,
+  UD_Iinsd,
+  UD_Iint1,
+  UD_Iint3,
+  UD_Iint,
+  UD_Iinto,
+  UD_Iinvd,
+  UD_Iinvlpg,
+  UD_Iinvlpga,
+  UD_Iiretw,
+  UD_Iiretd,
+  UD_Iiretq,
+  UD_Ijo,
+  UD_Ijno,
+  UD_Ijb,
+  UD_Ijae,
+  UD_Ijz,
+  UD_Ijnz,
+  UD_Ijbe,
+  UD_Ija,
+  UD_Ijs,
+  UD_Ijns,
+  UD_Ijp,
+  UD_Ijnp,
+  UD_Ijl,
+  UD_Ijge,
+  UD_Ijle,
+  UD_Ijg,
+  UD_Ijcxz,
+  UD_Ijecxz,
+  UD_Ijrcxz,
+  UD_Ijmp,
+  UD_Ilahf,
+  UD_Ilar,
+  UD_Ilddqu,
+  UD_Ildmxcsr,
+  UD_Ilds,
+  UD_Ilea,
+  UD_Iles,
+  UD_Ilfs,
+  UD_Ilgs,
+  UD_Ilidt,
+  UD_Ilss,
+  UD_Ileave,
+  UD_Ilfence,
+  UD_Ilgdt,
+  UD_Illdt,
+  UD_Ilmsw,
+  UD_Ilock,
+  UD_Ilodsb,
+  UD_Ilodsw,
+  UD_Ilodsd,
+  UD_Ilodsq,
+  UD_Iloopnz,
+  UD_Iloope,
+  UD_Iloop,
+  UD_Ilsl,
+  UD_Iltr,
+  UD_Imaskmovq,
+  UD_Imaxpd,
+  UD_Imaxps,
+  UD_Imaxsd,
+  UD_Imaxss,
+  UD_Imfence,
+  UD_Iminpd,
+  UD_Iminps,
+  UD_Iminsd,
+  UD_Iminss,
+  UD_Imonitor,
+  UD_Imov,
+  UD_Imovapd,
+  UD_Imovaps,
+  UD_Imovd,
+  UD_Imovddup,
+  UD_Imovdqa,
+  UD_Imovdqu,
+  UD_Imovdq2q,
+  UD_Imovhpd,
+  UD_Imovhps,
+  UD_Imovlhps,
+  UD_Imovlpd,
+  UD_Imovlps,
+  UD_Imovhlps,
+  UD_Imovmskpd,
+  UD_Imovmskps,
+  UD_Imovntdq,
+  UD_Imovnti,
+  UD_Imovntpd,
+  UD_Imovntps,
+  UD_Imovntq,
+  UD_Imovq,
+  UD_Imovqa,
+  UD_Imovq2dq,
+  UD_Imovsb,
+  UD_Imovsw,
+  UD_Imovsd,
+  UD_Imovsq,
+  UD_Imovsldup,
+  UD_Imovshdup,
+  UD_Imovss,
+  UD_Imovsx,
+  UD_Imovupd,
+  UD_Imovups,
+  UD_Imovzx,
+  UD_Imul,
+  UD_Imulpd,
+  UD_Imulps,
+  UD_Imulsd,
+  UD_Imulss,
+  UD_Imwait,
+  UD_Ineg,
+  UD_Inop,
+  UD_Inot,
+  UD_Ior,
+  UD_Iorpd,
+  UD_Iorps,
+  UD_Iout,
+  UD_Ioutsb,
+  UD_Ioutsw,
+  UD_Ioutsd,
+  UD_Ioutsq,
+  UD_Ipacksswb,
+  UD_Ipackssdw,
+  UD_Ipackuswb,
+  UD_Ipaddb,
+  UD_Ipaddw,
+  UD_Ipaddq,
+  UD_Ipaddsb,
+  UD_Ipaddsw,
+  UD_Ipaddusb,
+  UD_Ipaddusw,
+  UD_Ipand,
+  UD_Ipandn,
+  UD_Ipause,
+  UD_Ipavgb,
+  UD_Ipavgw,
+  UD_Ipcmpeqb,
+  UD_Ipcmpeqw,
+  UD_Ipcmpeqd,
+  UD_Ipcmpgtb,
+  UD_Ipcmpgtw,
+  UD_Ipcmpgtd,
+  UD_Ipextrw,
+  UD_Ipinsrw,
+  UD_Ipmaddwd,
+  UD_Ipmaxsw,
+  UD_Ipmaxub,
+  UD_Ipminsw,
+  UD_Ipminub,
+  UD_Ipmovmskb,
+  UD_Ipmulhuw,
+  UD_Ipmulhw,
+  UD_Ipmullw,
+  UD_Ipmuludq,
+  UD_Ipop,
+  UD_Ipopa,
+  UD_Ipopad,
+  UD_Ipopfw,
+  UD_Ipopfd,
+  UD_Ipopfq,
+  UD_Ipor,
+  UD_Iprefetch,
+  UD_Iprefetchnta,
+  UD_Iprefetcht0,
+  UD_Iprefetcht1,
+  UD_Iprefetcht2,
+  UD_Ipsadbw,
+  UD_Ipshufd,
+  UD_Ipshufhw,
+  UD_Ipshuflw,
+  UD_Ipshufw,
+  UD_Ipslldq,
+  UD_Ipsllw,
+  UD_Ipslld,
+  UD_Ipsllq,
+  UD_Ipsraw,
+  UD_Ipsrad,
+  UD_Ipsrlw,
+  UD_Ipsrld,
+  UD_Ipsrlq,
+  UD_Ipsrldq,
+  UD_Ipsubb,
+  UD_Ipsubw,
+  UD_Ipsubd,
+  UD_Ipsubq,
+  UD_Ipsubsb,
+  UD_Ipsubsw,
+  UD_Ipsubusb,
+  UD_Ipsubusw,
+  UD_Ipunpckhbw,
+  UD_Ipunpckhwd,
+  UD_Ipunpckhdq,
+  UD_Ipunpckhqdq,
+  UD_Ipunpcklbw,
+  UD_Ipunpcklwd,
+  UD_Ipunpckldq,
+  UD_Ipunpcklqdq,
+  UD_Ipi2fw,
+  UD_Ipi2fd,
+  UD_Ipf2iw,
+  UD_Ipf2id,
+  UD_Ipfnacc,
+  UD_Ipfpnacc,
+  UD_Ipfcmpge,
+  UD_Ipfmin,
+  UD_Ipfrcp,
+  UD_Ipfrsqrt,
+  UD_Ipfsub,
+  UD_Ipfadd,
+  UD_Ipfcmpgt,
+  UD_Ipfmax,
+  UD_Ipfrcpit1,
+  UD_Ipfrspit1,
+  UD_Ipfsubr,
+  UD_Ipfacc,
+  UD_Ipfcmpeq,
+  UD_Ipfmul,
+  UD_Ipfrcpit2,
+  UD_Ipmulhrw,
+  UD_Ipswapd,
+  UD_Ipavgusb,
+  UD_Ipush,
+  UD_Ipusha,
+  UD_Ipushad,
+  UD_Ipushfw,
+  UD_Ipushfd,
+  UD_Ipushfq,
+  UD_Ipxor,
+  UD_Ircl,
+  UD_Ircr,
+  UD_Irol,
+  UD_Iror,
+  UD_Ircpps,
+  UD_Ircpss,
+  UD_Irdmsr,
+  UD_Irdpmc,
+  UD_Irdtsc,
+  UD_Irdtscp,
+  UD_Irepne,
+  UD_Irep,
+  UD_Iret,
+  UD_Iretf,
+  UD_Irsm,
+  UD_Irsqrtps,
+  UD_Irsqrtss,
+  UD_Isahf,
+  UD_Isal,
+  UD_Isalc,
+  UD_Isar,
+  UD_Ishl,
+  UD_Ishr,
+  UD_Isbb,
+  UD_Iscasb,
+  UD_Iscasw,
+  UD_Iscasd,
+  UD_Iscasq,
+  UD_Iseto,
+  UD_Isetno,
+  UD_Isetb,
+  UD_Isetnb,
+  UD_Isetz,
+  UD_Isetnz,
+  UD_Isetbe,
+  UD_Iseta,
+  UD_Isets,
+  UD_Isetns,
+  UD_Isetp,
+  UD_Isetnp,
+  UD_Isetl,
+  UD_Isetge,
+  UD_Isetle,
+  UD_Isetg,
+  UD_Isfence,
+  UD_Isgdt,
+  UD_Ishld,
+  UD_Ishrd,
+  UD_Ishufpd,
+  UD_Ishufps,
+  UD_Isidt,
+  UD_Isldt,
+  UD_Ismsw,
+  UD_Isqrtps,
+  UD_Isqrtpd,
+  UD_Isqrtsd,
+  UD_Isqrtss,
+  UD_Istc,
+  UD_Istd,
+  UD_Istgi,
+  UD_Isti,
+  UD_Iskinit,
+  UD_Istmxcsr,
+  UD_Istosb,
+  UD_Istosw,
+  UD_Istosd,
+  UD_Istosq,
+  UD_Istr,
+  UD_Isub,
+  UD_Isubpd,
+  UD_Isubps,
+  UD_Isubsd,
+  UD_Isubss,
+  UD_Iswapgs,
+  UD_Isyscall,
+  UD_Isysenter,
+  UD_Isysexit,
+  UD_Isysret,
+  UD_Itest,
+  UD_Iucomisd,
+  UD_Iucomiss,
+  UD_Iud2,
+  UD_Iunpckhpd,
+  UD_Iunpckhps,
+  UD_Iunpcklps,
+  UD_Iunpcklpd,
+  UD_Iverr,
+  UD_Iverw,
+  UD_Ivmcall,
+  UD_Ivmclear,
+  UD_Ivmxon,
+  UD_Ivmptrld,
+  UD_Ivmptrst,
+  UD_Ivmresume,
+  UD_Ivmxoff,
+  UD_Ivmrun,
+  UD_Ivmmcall,
+  UD_Ivmload,
+  UD_Ivmsave,
+  UD_Iwait,
+  UD_Iwbinvd,
+  UD_Iwrmsr,
+  UD_Ixadd,
+  UD_Ixchg,
+  UD_Ixlatb,
+  UD_Ixor,
+  UD_Ixorpd,
+  UD_Ixorps,
+  UD_Idb,
+  UD_Iinvalid,
+  UD_Id3vil,
+  UD_Ina,
+  UD_Igrp_reg,
+  UD_Igrp_rm,
+  UD_Igrp_vendor,
+  UD_Igrp_x87,
+  UD_Igrp_mode,
+  UD_Igrp_osize,
+  UD_Igrp_asize,
+  UD_Igrp_mod,
+  UD_Inone,
+};
+
+
+
+extern const char* ud_mnemonics_str[];;
+extern struct ud_itab_entry* ud_itab_list[];
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/kdb_dis.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2009, Mukesh Rathor, Oracle Corp.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 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, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include <xen/compile.h>                /* for XEN_SUBVERSION */
+#include "../../include/kdbinc.h"
+#include "extern.h"
+
+static void (*dis_syntax)(ud_t*) = UD_SYN_ATT; /* default dis-assembly syntax */
+
+static struct {                         /* info for kdb_read_byte_for_ud() */
+    kdbva_t kud_instr_addr;
+    domid_t kud_domid;
+} kdb_ud_rd_info;
+
+/* called via function ptr by ud when disassembling. 
+ * kdb info passed via kdb_ud_rd_info{} 
+ */
+static int
+kdb_read_byte_for_ud(struct ud *udp)
+{
+    kdbbyt_t bytebuf;
+    domid_t domid = kdb_ud_rd_info.kud_domid;
+    kdbva_t addr = kdb_ud_rd_info.kud_instr_addr;
+
+    if (kdb_read_mem(addr, &bytebuf, 1, domid) == 1) {
+        kdb_ud_rd_info.kud_instr_addr++;
+        KDBGP1("udrd:addr:%lx domid:%d byt:%x\n", addr, domid, bytebuf);
+        return bytebuf;
+    }
+    KDBGP1("udrd:addr:%lx domid:%d err\n", addr, domid);
+    return UD_EOI;
+}
+
+/* 
+ * given a domid, convert addr to symbol and print it 
+ * Eg: ffff828c801235e2: idle_loop+52                  jmp  idle_loop+55
+ *    Called twice here for idle_loop. In first case, nl is null, 
+ *    in the second case nl == '\n'
+ */
+void
+kdb_prnt_addr2sym(domid_t domid, kdbva_t addr, char *nl)
+{
+    unsigned long sz, offs;
+    char buf[KSYM_NAME_LEN+1], pbuf[150], prefix[8];
+    char *p = buf;
+
+    prefix[0]='\0';
+    if (domid != DOMID_IDLE) {
+        snprintf(prefix, 8, "%x:", domid);
+        p = kdb_guest_addr2sym(addr, domid, &offs);
+    } else
+        symbols_lookup(addr, &sz, &offs, buf);
+
+    snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
+    if (*nl != '\n')
+        kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
+    else
+        kdbp("%s%s", pbuf, nl);
+
+}
+
+static int
+kdb_jump_instr(enum ud_mnemonic_code mnemonic)
+{
+    return (mnemonic >= UD_Ijo && mnemonic <= UD_Ijmp);
+}
+
+/*
+ * print one instr: function so that we can print offsets of jmp etc.. as
+ *  symbol+offset instead of just address
+ */
+static void
+kdb_print_one_instr(struct ud *udp, domid_t domid)
+{
+    signed long val = 0;
+    ud_type_t type = udp->operand[0].type;
+
+    if ((udp->mnemonic == UD_Icall || kdb_jump_instr(udp->mnemonic)) &&
+        type == UD_OP_JIMM) {
+        
+        int sz = udp->operand[0].size;
+        char *p, ibuf[40], *q = ibuf;
+        kdbva_t addr;
+
+        if (sz == 8) val = udp->operand[0].lval.sbyte;
+        else if (sz == 16) val = udp->operand[0].lval.sword;
+        else if (sz == 32) val = udp->operand[0].lval.sdword;
+        else if (sz == 64) val = udp->operand[0].lval.sqword;
+        else kdbp("kdb_print_one_instr: Inval sz:z%d\n", sz);
+
+        addr = udp->pc + val;
+        for(p=ud_insn_asm(udp); (*q=*p) && *p!=' '; p++,q++);
+        *q='\0';
+        kdbp(" %-4s ", ibuf);    /* space before for long func names */
+        kdb_prnt_addr2sym(domid, addr, "\n");
+    } else
+        kdbp(" %-24s\n", ud_insn_asm(udp));
+#if 0
+    kdbp("mnemonic:z%d ", udp->mnemonic);
+    if (type == UD_OP_CONST) kdbp("type is const\n");
+    else if (type == UD_OP_JIMM) kdbp("type is JIMM\n");
+    else if (type == UD_OP_IMM) kdbp("type is IMM\n");
+    else if (type == UD_OP_PTR) kdbp("type is PTR\n");
+#endif
+}
+
+static void
+kdb_setup_ud(struct ud *udp, kdbva_t addr, domid_t domid)
+{
+    int bitness = kdb_guest_bitness(domid);
+    uint vendor = (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ?
+                                           UD_VENDOR_AMD : UD_VENDOR_INTEL;
+
+    KDBGP1("setup_ud:domid:%d bitness:%d addr:%lx\n", domid, bitness, addr);
+    ud_init(udp);
+    ud_set_mode(udp, kdb_guest_bitness(domid));
+    ud_set_syntax(udp, dis_syntax); 
+    ud_set_vendor(udp, vendor);           /* HVM: vmx/svm different instrs*/
+    ud_set_pc(udp, addr);                 /* for numbers printed on left */
+    ud_set_input_hook(udp, kdb_read_byte_for_ud);
+    kdb_ud_rd_info.kud_instr_addr = addr;
+    kdb_ud_rd_info.kud_domid = domid;
+}
+
+/*
+ * given an addr, print given number of instructions.
+ * Returns: address of next instruction in the stream
+ */
+kdbva_t
+kdb_print_instr(kdbva_t addr, long num, domid_t domid)
+{
+    struct ud ud_s;
+
+    KDBGP1("print_instr:addr:0x%lx num:%ld domid:%x\n", addr, num, domid);
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    while(num--) {
+        if (ud_disassemble(&ud_s)) {
+            uint64_t pc = ud_insn_off(&ud_s);
+            /* kdbp("%08x: ",(int)pc); */
+            kdbp("%016lx: ", pc);
+            kdb_prnt_addr2sym(domid, pc, "");
+            kdb_print_one_instr(&ud_s, domid);
+        } else
+            kdbp("KDB:Couldn't disassemble PC:0x%lx\n", addr);
+            /* for stack reads, don't always display error */
+    }
+    KDBGP1("print_instr:kudaddr:0x%lx\n", kdb_ud_rd_info.kud_instr_addr);
+    return kdb_ud_rd_info.kud_instr_addr;
+}
+
+void
+kdb_display_pc(struct cpu_user_regs *regs)
+{   
+    domid_t domid;
+    struct cpu_user_regs regs1 = *regs;
+    domid = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+
+    regs1.KDBIP = regs->KDBIP;
+    kdb_print_instr(regs1.KDBIP, 1, domid);
+}
+
+/* check if the instr at the addr is call instruction
+ * RETURNS: size of the instr if it's a call instr, else 0
+ */
+int
+kdb_check_call_instr(domid_t domid, kdbva_t addr)
+{
+    struct ud ud_s;
+    int sz;
+
+    kdb_setup_ud(&ud_s, addr, domid);
+    if ((sz=ud_disassemble(&ud_s)) && ud_s.mnemonic == UD_Icall)
+        return (sz);
+    return 0;
+}
+
+/* toggle ATT and Intel syntaxes */
+void
+kdb_toggle_dis_syntax(void)
+{
+    if (dis_syntax == UD_SYN_INTEL) {
+        dis_syntax = UD_SYN_ATT;
+        kdbp("dis syntax now set to ATT (Gas)\n");
+    } else {
+        dis_syntax = UD_SYN_INTEL;
+        kdbp("dis syntax now set to Intel (NASM)\n");
+    }
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn-att.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-att.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,211 @@
+/* -----------------------------------------------------------------------------
+ * syn-att.c
+ *
+ * Copyright (c) 2004, 2005, 2006 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case 16 : case 32 :
+		mkasm(u, "*");   break;
+	default: break;
+  }
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+gen_operand(struct ud* u, struct ud_operand* op)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, "%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM:
+		if (u->br_far) opr_cast(u, op);
+		if (u->pfx_seg)
+			mkasm(u, "%%%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", (-op->lval.sbyte) & 0xff);
+			else	mkasm(u, "0x%x", op->lval.sbyte);
+		} 
+		else if (op->offset == 16) 
+			mkasm(u, "0x%x", op->lval.uword);
+		else if (op->offset == 32) 
+			mkasm(u, "0x%lx", op->lval.udword);
+		else if (op->offset == 64) 
+			mkasm(u, "0x" FMT64 "x", op->lval.uqword);
+
+		if (op->base)
+			mkasm(u, "(%%%s", ud_reg_tab[op->base - UD_R_AL]);
+		if (op->index) {
+			if (op->base)
+				mkasm(u, ",");
+			else mkasm(u, "(");
+			mkasm(u, "%%%s", ud_reg_tab[op->index - UD_R_AL]);
+		}
+		if (op->scale)
+			mkasm(u, ",%d", op->scale);
+		if (op->base || op->index)
+			mkasm(u, ")");
+		break;
+
+	case UD_OP_IMM:
+		switch (op->size) {
+			case  8: mkasm(u, "$0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "$0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "$0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "$0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "$0x%x, $0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "$0x%x, $0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+			
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to AT&T syntax 
+ * =============================================================================
+ */
+extern void 
+ud_translate_att(struct ud *u)
+{
+  int size = 0;
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+  	mkasm(u,  "lock ");
+  if (u->pfx_rep)
+	mkasm(u,  "rep ");
+  if (u->pfx_repne)
+		mkasm(u,  "repne ");
+
+  /* special instructions */
+  switch (u->mnemonic) {
+	case UD_Iretf: 
+		mkasm(u, "lret "); 
+		break;
+	case UD_Idb:
+		mkasm(u, ".byte 0x%x", u->operand[0].lval.ubyte);
+		return;
+	case UD_Ijmp:
+	case UD_Icall:
+		if (u->br_far) mkasm(u,  "l");
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+		break;
+	case UD_Ibound:
+	case UD_Ienter:
+		if (u->operand[0].type != UD_NONE)
+			gen_operand(u, &u->operand[0]);
+		if (u->operand[1].type != UD_NONE) {
+			mkasm(u, ",");
+			gen_operand(u, &u->operand[1]);
+		}
+		return;
+	default:
+		mkasm(u, "%s", ud_lookup_mnemonic(u->mnemonic));
+  }
+
+  if (u->c1)
+	size = u->operand[0].size;
+  else if (u->c2)
+	size = u->operand[1].size;
+  else if (u->c3)
+	size = u->operand[2].size;
+
+  if (size == 8)
+	mkasm(u, "b");
+  else if (size == 16)
+	mkasm(u, "w");
+  else if (size == 64)
+ 	mkasm(u, "q");
+
+  mkasm(u, " ");
+
+  if (u->operand[2].type != UD_NONE) {
+	gen_operand(u, &u->operand[2]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[1].type != UD_NONE) {
+	gen_operand(u, &u->operand[1]);
+	mkasm(u, ", ");
+  }
+
+  if (u->operand[0].type != UD_NONE)
+	gen_operand(u, &u->operand[0]);
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn-intel.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn-intel.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,208 @@
+/* -----------------------------------------------------------------------------
+ * syn-intel.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+#include "types.h"
+#include "extern.h"
+#include "decode.h"
+#include "itab.h"
+#include "syn.h"
+
+/* -----------------------------------------------------------------------------
+ * opr_cast() - Prints an operand cast.
+ * -----------------------------------------------------------------------------
+ */
+static void 
+opr_cast(struct ud* u, struct ud_operand* op)
+{
+  switch(op->size) {
+	case  8: mkasm(u, "byte " ); break;
+	case 16: mkasm(u, "word " ); break;
+	case 32: mkasm(u, "dword "); break;
+	case 64: mkasm(u, "qword "); break;
+	case 80: mkasm(u, "tword "); break;
+	default: break;
+  }
+  if (u->br_far)
+	mkasm(u, "far "); 
+  else if (u->br_near)
+	mkasm(u, "near ");
+}
+
+/* -----------------------------------------------------------------------------
+ * gen_operand() - Generates assembly output for each operand.
+ * -----------------------------------------------------------------------------
+ */
+static void gen_operand(struct ud* u, struct ud_operand* op, int syn_cast)
+{
+  switch(op->type) {
+	case UD_OP_REG:
+		mkasm(u, ud_reg_tab[op->base - UD_R_AL]);
+		break;
+
+	case UD_OP_MEM: {
+
+		int op_f = 0;
+
+		if (syn_cast) 
+			opr_cast(u, op);
+
+		mkasm(u, "[");
+
+		if (u->pfx_seg)
+			mkasm(u, "%s:", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+		if (op->base) {
+			mkasm(u, "%s", ud_reg_tab[op->base - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->index) {
+			if (op_f)
+				mkasm(u, "+");
+			mkasm(u, "%s", ud_reg_tab[op->index - UD_R_AL]);
+			op_f = 1;
+		}
+
+		if (op->scale)
+			mkasm(u, "*%d", op->scale);
+
+		if (op->offset == 8) {
+			if (op->lval.sbyte < 0)
+				mkasm(u, "-0x%x", -op->lval.sbyte);
+			else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sbyte);
+		}
+		else if (op->offset == 16)
+			mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.uword);
+		else if (op->offset == 32) {
+			if (u->adr_mode == 64) {
+				if (op->lval.sdword < 0)
+					mkasm(u, "-0x%x", -op->lval.sdword);
+				else	mkasm(u, "%s0x%x", (op_f) ? "+" : "", op->lval.sdword);
+			} 
+			else	mkasm(u, "%s0x%lx", (op_f) ? "+" : "", op->lval.udword);
+		}
+		else if (op->offset == 64) 
+			mkasm(u, "%s0x" FMT64 "x", (op_f) ? "+" : "", op->lval.uqword);
+
+		mkasm(u, "]");
+		break;
+	}
+			
+	case UD_OP_IMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8: mkasm(u, "0x%x", op->lval.ubyte);    break;
+			case 16: mkasm(u, "0x%x", op->lval.uword);    break;
+			case 32: mkasm(u, "0x%lx", op->lval.udword);  break;
+			case 64: mkasm(u, "0x" FMT64 "x", op->lval.uqword); break;
+			default: break;
+		}
+		break;
+
+	case UD_OP_JIMM:
+		if (syn_cast) opr_cast(u, op);
+		switch (op->size) {
+			case  8:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sbyte); 
+				break;
+			case 16:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sword);
+				break;
+			case 32:
+				mkasm(u, "0x" FMT64 "x", u->pc + op->lval.sdword);
+				break;
+			default:break;
+		}
+		break;
+
+	case UD_OP_PTR:
+		switch (op->size) {
+			case 32:
+				mkasm(u, "word 0x%x:0x%x", op->lval.ptr.seg, 
+					op->lval.ptr.off & 0xFFFF);
+				break;
+			case 48:
+				mkasm(u, "dword 0x%x:0x%lx", op->lval.ptr.seg, 
+					op->lval.ptr.off);
+				break;
+		}
+		break;
+
+	case UD_OP_CONST:
+		if (syn_cast) opr_cast(u, op);
+		mkasm(u, "%d", op->lval.udword);
+		break;
+
+	default: return;
+  }
+}
+
+/* =============================================================================
+ * translates to intel syntax 
+ * =============================================================================
+ */
+extern void ud_translate_intel(struct ud* u)
+{
+  /* -- prefixes -- */
+
+  /* check if P_OSO prefix is used */
+  if (! P_OSO(u->itab_entry->prefix) && u->pfx_opr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "o32 ");
+			break;
+		case 32:
+		case 64:
+ 			mkasm(u, "o16 ");
+			break;
+	}
+  }
+
+  /* check if P_ASO prefix was used */
+  if (! P_ASO(u->itab_entry->prefix) && u->pfx_adr) {
+	switch (u->dis_mode) {
+		case 16: 
+			mkasm(u, "a32 ");
+			break;
+		case 32:
+ 			mkasm(u, "a16 ");
+			break;
+		case 64:
+ 			mkasm(u, "a32 ");
+			break;
+	}
+  }
+
+  if (u->pfx_lock)
+	mkasm(u, "lock ");
+  if (u->pfx_rep)
+	mkasm(u, "rep ");
+  if (u->pfx_repne)
+	mkasm(u, "repne ");
+  if (u->implicit_addr && u->pfx_seg)
+	mkasm(u, "%s ", ud_reg_tab[u->pfx_seg - UD_R_AL]);
+
+  /* print the instruction mnemonic */
+  mkasm(u, "%s ", ud_lookup_mnemonic(u->mnemonic));
+
+  /* operand 1 */
+  if (u->operand[0].type != UD_NONE) {
+	gen_operand(u, &u->operand[0], u->c1);
+  }
+  /* operand 2 */
+  if (u->operand[1].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[1], u->c2);
+  }
+
+  /* operand 3 */
+  if (u->operand[2].type != UD_NONE) {
+	mkasm(u, ", ");
+	gen_operand(u, &u->operand[2], u->c3);
+  }
+}
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,61 @@
+/* -----------------------------------------------------------------------------
+ * syn.c
+ *
+ * Copyright (c) 2002, 2003, 2004 Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See (LICENSE)
+ * -----------------------------------------------------------------------------
+ */
+
+/* -----------------------------------------------------------------------------
+ * Intel Register Table - Order Matters (types.h)!
+ * -----------------------------------------------------------------------------
+ */
+const char* ud_reg_tab[] = 
+{
+  "al",		"cl",		"dl",		"bl",
+  "ah",		"ch",		"dh",		"bh",
+  "spl",	"bpl",		"sil",		"dil",
+  "r8b",	"r9b",		"r10b",		"r11b",
+  "r12b",	"r13b",		"r14b",		"r15b",
+
+  "ax",		"cx",		"dx",		"bx",
+  "sp",		"bp",		"si",		"di",
+  "r8w",	"r9w",		"r10w",		"r11w",
+  "r12w",	"r13W"	,	"r14w",		"r15w",
+	
+  "eax",	"ecx",		"edx",		"ebx",
+  "esp",	"ebp",		"esi",		"edi",
+  "r8d",	"r9d",		"r10d",		"r11d",
+  "r12d",	"r13d",		"r14d",		"r15d",
+	
+  "rax",	"rcx",		"rdx",		"rbx",
+  "rsp",	"rbp",		"rsi",		"rdi",
+  "r8",		"r9",		"r10",		"r11",
+  "r12",	"r13",		"r14",		"r15",
+
+  "es",		"cs",		"ss",		"ds",
+  "fs",		"gs",	
+
+  "cr0",	"cr1",		"cr2",		"cr3",
+  "cr4",	"cr5",		"cr6",		"cr7",
+  "cr8",	"cr9",		"cr10",		"cr11",
+  "cr12",	"cr13",		"cr14",		"cr15",
+	
+  "dr0",	"dr1",		"dr2",		"dr3",
+  "dr4",	"dr5",		"dr6",		"dr7",
+  "dr8",	"dr9",		"dr10",		"dr11",
+  "dr12",	"dr13",		"dr14",		"dr15",
+
+  "mm0",	"mm1",		"mm2",		"mm3",
+  "mm4",	"mm5",		"mm6",		"mm7",
+
+  "st0",	"st1",		"st2",		"st3",
+  "st4",	"st5",		"st6",		"st7", 
+
+  "xmm0",	"xmm1",		"xmm2",		"xmm3",
+  "xmm4",	"xmm5",		"xmm6",		"xmm7",
+  "xmm8",	"xmm9",		"xmm10",	"xmm11",
+  "xmm12",	"xmm13",	"xmm14",	"xmm15",
+
+  "rip"
+};
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/syn.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/syn.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,27 @@
+/* -----------------------------------------------------------------------------
+ * syn.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_SYN_H
+#define UD_SYN_H
+
+#if 0
+#include <stdio.h>
+#include <stdarg.h>
+#endif
+#include "types.h"
+
+extern const char* ud_reg_tab[];
+
+static void mkasm(struct ud* u, const char* fmt, ...)
+{
+  va_list ap;
+  va_start(ap, fmt);
+  u->insn_fill += vsnprintf((char*) u->insn_buffer + u->insn_fill, 64, fmt, ap);
+  va_end(ap);
+}
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/types.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/types.h	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,186 @@
+/* -----------------------------------------------------------------------------
+ * types.h
+ *
+ * Copyright (c) 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+#ifndef UD_TYPES_H
+#define UD_TYPES_H
+
+
+#include "../../include/kdbinc.h"
+
+#define FMT64 "%ll"
+#include "itab.h"
+
+/* -----------------------------------------------------------------------------
+ * All possible "types" of objects in udis86. Order is Important!
+ * -----------------------------------------------------------------------------
+ */
+enum ud_type
+{
+  UD_NONE,
+
+  /* 8 bit GPRs */
+  UD_R_AL,	UD_R_CL,	UD_R_DL,	UD_R_BL,
+  UD_R_AH,	UD_R_CH,	UD_R_DH,	UD_R_BH,
+  UD_R_SPL,	UD_R_BPL,	UD_R_SIL,	UD_R_DIL,
+  UD_R_R8B,	UD_R_R9B,	UD_R_R10B,	UD_R_R11B,
+  UD_R_R12B,	UD_R_R13B,	UD_R_R14B,	UD_R_R15B,
+
+  /* 16 bit GPRs */
+  UD_R_AX,	UD_R_CX,	UD_R_DX,	UD_R_BX,
+  UD_R_SP,	UD_R_BP,	UD_R_SI,	UD_R_DI,
+  UD_R_R8W,	UD_R_R9W,	UD_R_R10W,	UD_R_R11W,
+  UD_R_R12W,	UD_R_R13W,	UD_R_R14W,	UD_R_R15W,
+	
+  /* 32 bit GPRs */
+  UD_R_EAX,	UD_R_ECX,	UD_R_EDX,	UD_R_EBX,
+  UD_R_ESP,	UD_R_EBP,	UD_R_ESI,	UD_R_EDI,
+  UD_R_R8D,	UD_R_R9D,	UD_R_R10D,	UD_R_R11D,
+  UD_R_R12D,	UD_R_R13D,	UD_R_R14D,	UD_R_R15D,
+	
+  /* 64 bit GPRs */
+  UD_R_RAX,	UD_R_RCX,	UD_R_RDX,	UD_R_RBX,
+  UD_R_RSP,	UD_R_RBP,	UD_R_RSI,	UD_R_RDI,
+  UD_R_R8,	UD_R_R9,	UD_R_R10,	UD_R_R11,
+  UD_R_R12,	UD_R_R13,	UD_R_R14,	UD_R_R15,
+
+  /* segment registers */
+  UD_R_ES,	UD_R_CS,	UD_R_SS,	UD_R_DS,
+  UD_R_FS,	UD_R_GS,	
+
+  /* control registers*/
+  UD_R_CR0,	UD_R_CR1,	UD_R_CR2,	UD_R_CR3,
+  UD_R_CR4,	UD_R_CR5,	UD_R_CR6,	UD_R_CR7,
+  UD_R_CR8,	UD_R_CR9,	UD_R_CR10,	UD_R_CR11,
+  UD_R_CR12,	UD_R_CR13,	UD_R_CR14,	UD_R_CR15,
+	
+  /* debug registers */
+  UD_R_DR0,	UD_R_DR1,	UD_R_DR2,	UD_R_DR3,
+  UD_R_DR4,	UD_R_DR5,	UD_R_DR6,	UD_R_DR7,
+  UD_R_DR8,	UD_R_DR9,	UD_R_DR10,	UD_R_DR11,
+  UD_R_DR12,	UD_R_DR13,	UD_R_DR14,	UD_R_DR15,
+
+  /* mmx registers */
+  UD_R_MM0,	UD_R_MM1,	UD_R_MM2,	UD_R_MM3,
+  UD_R_MM4,	UD_R_MM5,	UD_R_MM6,	UD_R_MM7,
+
+  /* x87 registers */
+  UD_R_ST0,	UD_R_ST1,	UD_R_ST2,	UD_R_ST3,
+  UD_R_ST4,	UD_R_ST5,	UD_R_ST6,	UD_R_ST7, 
+
+  /* extended multimedia registers */
+  UD_R_XMM0,	UD_R_XMM1,	UD_R_XMM2,	UD_R_XMM3,
+  UD_R_XMM4,	UD_R_XMM5,	UD_R_XMM6,	UD_R_XMM7,
+  UD_R_XMM8,	UD_R_XMM9,	UD_R_XMM10,	UD_R_XMM11,
+  UD_R_XMM12,	UD_R_XMM13,	UD_R_XMM14,	UD_R_XMM15,
+
+  UD_R_RIP,
+
+  /* Operand Types */
+  UD_OP_REG,	UD_OP_MEM,	UD_OP_PTR,	UD_OP_IMM,	
+  UD_OP_JIMM,	UD_OP_CONST
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud_operand - Disassembled instruction Operand.
+ * -----------------------------------------------------------------------------
+ */
+struct ud_operand 
+{
+  enum ud_type		type;
+  uint8_t		size;
+  union {
+	int8_t		sbyte;
+	uint8_t		ubyte;
+	int16_t		sword;
+	uint16_t	uword;
+	int32_t		sdword;
+	uint32_t	udword;
+	int64_t		sqword;
+	uint64_t	uqword;
+
+	struct {
+		uint16_t seg;
+		uint32_t off;
+	} ptr;
+  } lval;
+
+  enum ud_type		base;
+  enum ud_type		index;
+  uint8_t		offset;
+  uint8_t		scale;	
+};
+
+/* -----------------------------------------------------------------------------
+ * struct ud - The udis86 object.
+ * -----------------------------------------------------------------------------
+ */
+struct ud
+{
+  int 			(*inp_hook) (struct ud*);
+  uint8_t		inp_curr;
+  uint8_t		inp_fill;
+  uint8_t		inp_ctr;
+  uint8_t*		inp_buff;
+  uint8_t*		inp_buff_end;
+  uint8_t		inp_end;
+  void			(*translator)(struct ud*);
+  uint64_t		insn_offset;
+  char			insn_hexcode[32];
+  char			insn_buffer[64];
+  unsigned int		insn_fill;
+  uint8_t		dis_mode;
+  uint64_t		pc;
+  uint8_t		vendor;
+  struct map_entry*	mapen;
+  enum ud_mnemonic_code	mnemonic;
+  struct ud_operand	operand[3];
+  uint8_t		error;
+  uint8_t	 	pfx_rex;
+  uint8_t 		pfx_seg;
+  uint8_t 		pfx_opr;
+  uint8_t 		pfx_adr;
+  uint8_t 		pfx_lock;
+  uint8_t 		pfx_rep;
+  uint8_t 		pfx_repe;
+  uint8_t 		pfx_repne;
+  uint8_t 		pfx_insn;
+  uint8_t		default64;
+  uint8_t		opr_mode;
+  uint8_t		adr_mode;
+  uint8_t		br_far;
+  uint8_t		br_near;
+  uint8_t		implicit_addr;
+  uint8_t		c1;
+  uint8_t		c2;
+  uint8_t		c3;
+  uint8_t 		inp_cache[256];
+  uint8_t		inp_sess[64];
+  struct ud_itab_entry * itab_entry;
+};
+
+/* -----------------------------------------------------------------------------
+ * Type-definitions
+ * -----------------------------------------------------------------------------
+ */
+typedef enum ud_type 		ud_type_t;
+typedef enum ud_mnemonic_code	ud_mnemonic_code_t;
+
+typedef struct ud 		ud_t;
+typedef struct ud_operand 	ud_operand_t;
+
+#define UD_SYN_INTEL		ud_translate_intel
+#define UD_SYN_ATT		ud_translate_att
+#define UD_EOI			-1
+#define UD_INP_CACHE_SZ		32
+#define UD_VENDOR_AMD		0
+#define UD_VENDOR_INTEL		1
+
+#define bail_out(ud,error_code) longjmp( (ud)->bailout, error_code )
+#define try_decode(ud) if ( setjmp( (ud)->bailout ) == 0 )
+#define catch_error() else
+
+#endif
diff -r 32034d1914a6 xen/kdb/x86/udis86-1.7/udis86.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/kdb/x86/udis86-1.7/udis86.c	Fri Jun 15 12:13:29 2012 -0700
@@ -0,0 +1,156 @@
+/* -----------------------------------------------------------------------------
+ * udis86.c
+ *
+ * Copyright (c) 2004, 2005, 2006, Vivek Mohan <vivek@sig9.com>
+ * All rights reserved. See LICENSE
+ * -----------------------------------------------------------------------------
+ */
+
+#if 0
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#endif
+
+#include "input.h"
+#include "extern.h"
+
+/* =============================================================================
+ * ud_init() - Initializes ud_t object.
+ * =============================================================================
+ */
+extern void 
+ud_init(struct ud* u)
+{
+  memset((void*)u, 0, sizeof(struct ud));
+  ud_set_mode(u, 16);
+  u->mnemonic = UD_Iinvalid;
+  ud_set_pc(u, 0);
+#ifndef __UD_STANDALONE__
+  ud_set_input_file(u, stdin);
+#endif /* __UD_STANDALONE__ */
+}
+
+/* =============================================================================
+ * ud_disassemble() - disassembles one instruction and returns the number of 
+ * bytes disassembled. A zero means end of disassembly.
+ * =============================================================================
+ */
+extern unsigned int
+ud_disassemble(struct ud* u)
+{
+  if (ud_input_end(u))
+	return 0;
+
+ 
+  u->insn_buffer[0] = u->insn_hexcode[0] = 0;
+
+ 
+  if (ud_decode(u) == 0)
+	return 0;
+  if (u->translator)
+	u->translator(u);
+  return ud_insn_len(u);
+}
+
+/* =============================================================================
+ * ud_set_mode() - Set Disassemly Mode.
+ * =============================================================================
+ */
+extern void 
+ud_set_mode(struct ud* u, uint8_t m)
+{
+  switch(m) {
+	case 16:
+	case 32:
+	case 64: u->dis_mode = m ; return;
+	default: u->dis_mode = 16; return;
+  }
+}
+
+/* =============================================================================
+ * ud_set_vendor() - Set vendor.
+ * =============================================================================
+ */
+extern void 
+ud_set_vendor(struct ud* u, unsigned v)
+{
+  switch(v) {
+	case UD_VENDOR_INTEL:
+		u->vendor = v;
+		break;
+	default:
+		u->vendor = UD_VENDOR_AMD;
+  }
+}
+
+/* =============================================================================
+ * ud_set_pc() - Sets code origin. 
+ * =============================================================================
+ */
+extern void 
+ud_set_pc(struct ud* u, uint64_t o)
+{
+  u->pc = o;
+}
+
+/* =============================================================================
+ * ud_set_syntax() - Sets the output syntax.
+ * =============================================================================
+ */
+extern void 
+ud_set_syntax(struct ud* u, void (*t)(struct ud*))
+{
+  u->translator = t;
+}
+
+/* =============================================================================
+ * ud_insn() - returns the disassembled instruction
+ * =============================================================================
+ */
+extern char* 
+ud_insn_asm(struct ud* u) 
+{
+  return u->insn_buffer;
+}
+
+/* =============================================================================
+ * ud_insn_offset() - Returns the offset.
+ * =============================================================================
+ */
+extern uint64_t
+ud_insn_off(struct ud* u) 
+{
+  return u->insn_offset;
+}
+
+
+/* =============================================================================
+ * ud_insn_hex() - Returns hex form of disassembled instruction.
+ * =============================================================================
+ */
+extern char* 
+ud_insn_hex(struct ud* u) 
+{
+  return u->insn_hexcode;
+}
+
+/* =============================================================================
+ * ud_insn_ptr() - Returns code disassembled.
+ * =============================================================================
+ */
+extern uint8_t* 
+ud_insn_ptr(struct ud* u) 
+{
+  return u->inp_sess;
+}
+
+/* =============================================================================
+ * ud_insn_len() - Returns the count of bytes disassembled.
+ * =============================================================================
+ */
+extern unsigned int 
+ud_insn_len(struct ud* u) 
+{
+  return u->inp_ctr;
+}

--MP_/c2HycnF26WhVANwYZbmqoQR
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--MP_/c2HycnF26WhVANwYZbmqoQR--


From xen-devel-bounces@lists.xen.org Mon Jun 18 11:36:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 11:36: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 1SgaFA-000058-6d; Mon, 18 Jun 2012 11:35:40 +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 1SgaF8-000051-5t
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 11:35:38 +0000
Received: from [85.158.143.99:59462] by server-3.bemta-4.messagelabs.com id
	CE/53-05808-9821FDF4; Mon, 18 Jun 2012 11:35:37 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340019333!27886809!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjM2MDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29159 invoked from network); 18 Jun 2012 11:35:34 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jun 2012 11:35:34 -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 43F8D201E;
	Mon, 18 Jun 2012 14:35:13 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id CBD2620060; Mon, 18 Jun 2012 14:35:07 +0300 (EEST)
Date: Mon, 18 Jun 2012 14:35:07 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sergey Zhukov <svg@ngs.ru>
Message-ID: <20120618113507.GV2058@reaktio.net>
References: <1340012319.13742.114.camel@sergey>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340012319.13742.114.camel@sergey>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Forking time 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 Mon, Jun 18, 2012 at 04:38:39PM +0700, Sergey Zhukov wrote:
> Hi,
> 
> I repost this message from xen-users list following by others
> subscribers suggestions:
> 
> 
> I found an article about forking time for redis NoSQL database in
> different systems:
> 
> http://redis.io/topics/latency
> ---------Quote------------------
> Fork time in different systems
> Modern hardware is pretty fast to copy the page table, but Xen is not.
> The problem with Xen is not virtualization-specific, but Xen-specific.
> For instance using VMware or Virutal Box does not result into slow fork
> time. The following is a table that compares fork time for different
> Redis instance size. Data is obtained performing a BGSAVE and looking at
> the latest_fork_usec filed in the INFO command output.
> 
>       * Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
>         (12.8 milliseconds per GB).
>       * Linux running on physical machine (Unknown HW) 6.1GB RSS forked
>         in 80 milliseconds (13.1 milliseconds per GB)
>       * Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
>         forked into 62 millisecodns (9 milliseconds per GB).
>       * Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
>         (23.3 millisecond per GB).
>       * Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
>         (239.3 milliseconds per GB).
>       * Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns
>         (424 milliseconds per GB).
> 
> As you can see a VM running on Xen has a performance hit that is between
> one order to two orders of magnitude. We believe this is a severe
> problem with Xen and we hope it will be addressed ASAP.
> ----------End of quote-----------------
> 
> I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
> test was performed on Intel Core I5 2500 processor unit. Forking time
> was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
> EC2/Linode were mentioned in the article, but still much slower then
> VMWare or physical machines. Has anyone running with this issue? Or may
> be there is a way to tune Xen for less forking times?
> 

If you need good fork-performance you should use Xen PVHVM guests, not PV.

Xen PV model needs to validate the new process page tables in the hypervisor 
every time when a fork happens, so that will have some performance hit in fork-heavy workloads.

HVM does not need to do that.. so please try switching to Xen PVHVM and benchmark again.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 11:36:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 11:36: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 1SgaFA-000058-6d; Mon, 18 Jun 2012 11:35:40 +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 1SgaF8-000051-5t
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 11:35:38 +0000
Received: from [85.158.143.99:59462] by server-3.bemta-4.messagelabs.com id
	CE/53-05808-9821FDF4; Mon, 18 Jun 2012 11:35:37 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340019333!27886809!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjM2MDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29159 invoked from network); 18 Jun 2012 11:35:34 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jun 2012 11:35:34 -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 43F8D201E;
	Mon, 18 Jun 2012 14:35:13 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id CBD2620060; Mon, 18 Jun 2012 14:35:07 +0300 (EEST)
Date: Mon, 18 Jun 2012 14:35:07 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sergey Zhukov <svg@ngs.ru>
Message-ID: <20120618113507.GV2058@reaktio.net>
References: <1340012319.13742.114.camel@sergey>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340012319.13742.114.camel@sergey>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Forking time 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 Mon, Jun 18, 2012 at 04:38:39PM +0700, Sergey Zhukov wrote:
> Hi,
> 
> I repost this message from xen-users list following by others
> subscribers suggestions:
> 
> 
> I found an article about forking time for redis NoSQL database in
> different systems:
> 
> http://redis.io/topics/latency
> ---------Quote------------------
> Fork time in different systems
> Modern hardware is pretty fast to copy the page table, but Xen is not.
> The problem with Xen is not virtualization-specific, but Xen-specific.
> For instance using VMware or Virutal Box does not result into slow fork
> time. The following is a table that compares fork time for different
> Redis instance size. Data is obtained performing a BGSAVE and looking at
> the latest_fork_usec filed in the INFO command output.
> 
>       * Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds
>         (12.8 milliseconds per GB).
>       * Linux running on physical machine (Unknown HW) 6.1GB RSS forked
>         in 80 milliseconds (13.1 milliseconds per GB)
>       * Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS
>         forked into 62 millisecodns (9 milliseconds per GB).
>       * Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds
>         (23.3 millisecond per GB).
>       * Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds
>         (239.3 milliseconds per GB).
>       * Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns
>         (424 milliseconds per GB).
> 
> As you can see a VM running on Xen has a performance hit that is between
> one order to two orders of magnitude. We believe this is a severe
> problem with Xen and we hope it will be addressed ASAP.
> ----------End of quote-----------------
> 
> I made my own test with Xen 4.1 and Redis 2.4 with 7.04GB dataset. The
> test was performed on Intel Core I5 2500 processor unit. Forking time
> was about 1 sec or 151 ms/GB - it's faster then tests over Amazon
> EC2/Linode were mentioned in the article, but still much slower then
> VMWare or physical machines. Has anyone running with this issue? Or may
> be there is a way to tune Xen for less forking times?
> 

If you need good fork-performance you should use Xen PVHVM guests, not PV.

Xen PV model needs to validate the new process page tables in the hypervisor 
every time when a fork happens, so that will have some performance hit in fork-heavy workloads.

HVM does not need to do that.. so please try switching to Xen PVHVM and benchmark again.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 11:36:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 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 1SgaFm-00009Q-K1; Mon, 18 Jun 2012 11:36: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 1SgaFk-00009D-UK
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 11:36:17 +0000
Received: from [85.158.138.51:62690] by server-9.bemta-3.messagelabs.com id
	AB/BC-10419-FA21FDF4; Mon, 18 Jun 2012 11:36:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340019375!20116051!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17212 invoked from network); 18 Jun 2012 11:36:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	18 Jun 2012 11:36:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 12:36:14 +0100
Message-Id: <4FDF2ECC020000780008A6AF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 12:36:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
In-Reply-To: <20120614153913.GC24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
> Here are the structs:
> 
> typedef struct v4v_ring_data_ent                                             
>                          
> {                                                                            
>                          
>     struct v4v_addr ring;                                                    
>                          
>     uint16_t flags;                                                          
>                          
>     uint16_t pad0;                                                           
>                          
>     uint32_t space_required;                                                 
>                          
>     uint32_t max_message_size;                                               
>                          
> } v4v_ring_data_ent_t;                                                       
>                          
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                               
>                          
>                                                                              
>                          
> typedef struct v4v_ring_data                                                 
>                          
> {                                                                            
>                          
>     uint64_t magic;                                                          
>                          
>     uint32_t nent;                                                           
>                          
>     uint32_t padding;                                                        
>                          
>     uint64_t reserved[4];                                                    
>                          
>     v4v_ring_data_ent_t ring[0];                                             
>                          
> } v4v_ring_data_t;                                                           
>                          
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> 
> I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I 
> would like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.
> 
> Here is the code that I use for doing that (with explicte cast in 
> guest_handle_cast):
>     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
>     XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>         guest_handle_cast (ring_data_hnd, uint8_t);
>     guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
>     ring_data_ent_hnd =
>         guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
>     ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);

Something as simple as

#define guest_handle_for_field(hnd, type, fld) \
    ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })

works quite fine for me is an example like

int v4v_test(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_data_t) urp) {
    v4v_ring_data_t ring_data;
    XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;

    copy_from_guest(&ring_data, urp, 1);
    ring_data_ent_hnd = guest_handle_for_field(urp, v4v_ring_data_ent_t, ring[0]);
    return v4v_fill_ring_datas(d, ring_data.nent, ring_data_ent_hnd);
}

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 11:36:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 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 1SgaFm-00009Q-K1; Mon, 18 Jun 2012 11:36: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 1SgaFk-00009D-UK
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 11:36:17 +0000
Received: from [85.158.138.51:62690] by server-9.bemta-3.messagelabs.com id
	AB/BC-10419-FA21FDF4; Mon, 18 Jun 2012 11:36:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340019375!20116051!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17212 invoked from network); 18 Jun 2012 11:36:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	18 Jun 2012 11:36:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 12:36:14 +0100
Message-Id: <4FDF2ECC020000780008A6AF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 12:36:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
In-Reply-To: <20120614153913.GC24063@spongy>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
 guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
> Here are the structs:
> 
> typedef struct v4v_ring_data_ent                                             
>                          
> {                                                                            
>                          
>     struct v4v_addr ring;                                                    
>                          
>     uint16_t flags;                                                          
>                          
>     uint16_t pad0;                                                           
>                          
>     uint32_t space_required;                                                 
>                          
>     uint32_t max_message_size;                                               
>                          
> } v4v_ring_data_ent_t;                                                       
>                          
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);                               
>                          
>                                                                              
>                          
> typedef struct v4v_ring_data                                                 
>                          
> {                                                                            
>                          
>     uint64_t magic;                                                          
>                          
>     uint32_t nent;                                                           
>                          
>     uint32_t padding;                                                        
>                          
>     uint64_t reserved[4];                                                    
>                          
>     v4v_ring_data_ent_t ring[0];                                             
>                          
> } v4v_ring_data_t;                                                           
>                          
> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> 
> I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall and I 
> would like to access the ring data inside it which is a XEN_GUEST_HANDLE as well.
> 
> Here is the code that I use for doing that (with explicte cast in 
> guest_handle_cast):
>     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
>     XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>         guest_handle_cast (ring_data_hnd, uint8_t);
>     guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
>     ring_data_ent_hnd =
>         guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
>     ret = v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hnd);

Something as simple as

#define guest_handle_for_field(hnd, type, fld) \
    ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })

works quite fine for me is an example like

int v4v_test(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_data_t) urp) {
    v4v_ring_data_t ring_data;
    XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;

    copy_from_guest(&ring_data, urp, 1);
    ring_data_ent_hnd = guest_handle_for_field(urp, v4v_ring_data_ent_t, ring[0]);
    return v4v_fill_ring_datas(d, ring_data.nent, ring_data_ent_hnd);
}

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 12:07:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12:07: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 1SgajK-0000zI-7Z; Mon, 18 Jun 2012 12:06:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SgajJ-0000zC-4B
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:06:49 +0000
Received: from [193.109.254.147:34649] by server-11.bemta-14.messagelabs.com
	id 81/31-24843-8D91FDF4; Mon, 18 Jun 2012 12:06:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340021193!10346164!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4569 invoked from network); 18 Jun 2012 12:06:34 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-27.messagelabs.com with SMTP;
	18 Jun 2012 12:06:34 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78956053; Mon, 18 Jun 2012 14:06:33 +0200
Message-ID: <1340021184.2997.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Jun 2012 14:06:24 +0200
In-Reply-To: <1339570785.4705.9.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5108417430431163465=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5108417430431163465==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-njUotSmzpnQIOEfDvjt3"


--=-njUotSmzpnQIOEfDvjt3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:=20
> > Ian J answered for the general commit case but in case you are
> > interested for the mq case you can put a comment at the top of the patc=
h
> > (before the changelog) with the same form as what "hg export" gives you=
.
> > e.g.:
> >         # HG changeset patch
> >         # User Ian Campbell <ian.campbell@citrix.com>
> >=20
> I am, indeed, interested in patchqueues... So thanks to both of you. :-)
>=20
> > This makes qpush do the right thing (IIRC, I didn't try it just now...)=
.
> >=20
> I see. It seems `hg qrefresh' also takes a -u argument which is doing
> the trick.
>=20
For the record, I tried the above and it seemed to work on my local
copy, but not while sending via patchbomb... :-( I'll try IanC's
suggestion for next time... Sorry. :-(

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-njUotSmzpnQIOEfDvjt3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/fGcAACgkQk4XaBE3IOsQReACgqIoOluI8L98LzzMBi6QJ+LP7
+Q0AoK9TO3JUVG6vrUUJXnyNP0FZVAzn
=X64V
-----END PGP SIGNATURE-----

--=-njUotSmzpnQIOEfDvjt3--



--===============5108417430431163465==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5108417430431163465==--



From xen-devel-bounces@lists.xen.org Mon Jun 18 12:07:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12:07: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 1SgajK-0000zI-7Z; Mon, 18 Jun 2012 12:06:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SgajJ-0000zC-4B
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:06:49 +0000
Received: from [193.109.254.147:34649] by server-11.bemta-14.messagelabs.com
	id 81/31-24843-8D91FDF4; Mon, 18 Jun 2012 12:06:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340021193!10346164!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4569 invoked from network); 18 Jun 2012 12:06:34 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-27.messagelabs.com with SMTP;
	18 Jun 2012 12:06:34 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78956053; Mon, 18 Jun 2012 14:06:33 +0200
Message-ID: <1340021184.2997.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Jun 2012 14:06:24 +0200
In-Reply-To: <1339570785.4705.9.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5108417430431163465=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5108417430431163465==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-njUotSmzpnQIOEfDvjt3"


--=-njUotSmzpnQIOEfDvjt3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:=20
> > Ian J answered for the general commit case but in case you are
> > interested for the mq case you can put a comment at the top of the patc=
h
> > (before the changelog) with the same form as what "hg export" gives you=
.
> > e.g.:
> >         # HG changeset patch
> >         # User Ian Campbell <ian.campbell@citrix.com>
> >=20
> I am, indeed, interested in patchqueues... So thanks to both of you. :-)
>=20
> > This makes qpush do the right thing (IIRC, I didn't try it just now...)=
.
> >=20
> I see. It seems `hg qrefresh' also takes a -u argument which is doing
> the trick.
>=20
For the record, I tried the above and it seemed to work on my local
copy, but not while sending via patchbomb... :-( I'll try IanC's
suggestion for next time... Sorry. :-(

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-njUotSmzpnQIOEfDvjt3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/fGcAACgkQk4XaBE3IOsQReACgqIoOluI8L98LzzMBi6QJ+LP7
+Q0AoK9TO3JUVG6vrUUJXnyNP0FZVAzn
=X64V
-----END PGP SIGNATURE-----

--=-njUotSmzpnQIOEfDvjt3--



--===============5108417430431163465==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5108417430431163465==--



From xen-devel-bounces@lists.xen.org Mon Jun 18 12:13:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgapN-00018T-3r; Mon, 18 Jun 2012 12:13:05 +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 1SgapL-00018N-ST
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:13:04 +0000
Received: from [193.109.254.147:60248] by server-11.bemta-14.messagelabs.com
	id 32/29-24843-F4B1FDF4; Mon, 18 Jun 2012 12:13:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340021582!10237884!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8310 invoked from network); 18 Jun 2012 12:13:02 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 12:13:02 -0000
Received: by eaak12 with SMTP id k12so1687421eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 05:13:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=m0QjjbA5pSHA88w3BquC/RIz1vu9HQx0bxpnUII6soQ=;
	b=Syg/SUvTB75SBd7Qb4SNEb6+31nglpKLj20ncZlafqNJqws5QpFwQ1ZkbwLxZcJZwB
	FEKX4NhjeOYi4QSoQCBl3zJqn0fgGq5FnhQLBwo2CA3llnHvI2eZ5cICDY5d0grlSuhg
	FdL8uM09OikxEXTXJ31bHmbzx7hdiGafENlCiPOB2iYs8yj/tF5IIm0heNwzIBKiArCs
	ovLF8UDyX/dYsL67+jiLhOy9aJ8ukKqtkDPqq+CbInjjMflGCnVj4MEmuP5F3EBz2yk+
	8mBY0eWPcYSGDVs5rSG3+P8ZU1LTM59Q8THMqlNi6dCIGyys32JBfq9bdMG6oXdKyfXT
	JZSg==
Received: by 10.14.48.71 with SMTP id u47mr3354332eeb.205.1340021581653;
	Mon, 18 Jun 2012 05:13:01 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id z5sm60715118eem.3.2012.06.18.05.13.00
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 05:13:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 13:12:56 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC04D9D8.431BE%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1NS7GIhaFcexrne0CyMjD4CkPDqA==
In-Reply-To: <4FDEF595020000780008A5B7@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] fpu_taskswitch adjustment 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 18/06/2012 08:32, "Jan Beulich" <JBeulich@suse.com> wrote:

>> It should be possible for the guest kernel to track its CR0.TS setting
>> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
>> cleared on #NM.
> 
> Sure, but selling this to the Linux maintainers I would expect to be
> harder than fitting the Xen side of things into the current save-
> and-restore model the native xor code uses. It would only be strait
> forward to implement on the legacy, forward ported trees.

Wouldn't it be hidden entirely behind pv_ops hooks and within Xen-specific
SSE save/restore code? I suppose you'd need to statically allocate the
per-cpu space for tracking the CR0.TS state... But overall it seems it will
be of little/no concern to other kernel maintainers?

 -- Keir

> However, with the #NM handler in pv-ops apparently not
> leveraging the fact that CR0.TS is already cleared for it on entry,
> maybe this could indeed be introduced together. Konrad?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 12:13:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12:13:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgapN-00018T-3r; Mon, 18 Jun 2012 12:13:05 +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 1SgapL-00018N-ST
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:13:04 +0000
Received: from [193.109.254.147:60248] by server-11.bemta-14.messagelabs.com
	id 32/29-24843-F4B1FDF4; Mon, 18 Jun 2012 12:13:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340021582!10237884!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8310 invoked from network); 18 Jun 2012 12:13:02 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 12:13:02 -0000
Received: by eaak12 with SMTP id k12so1687421eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 05:13:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=m0QjjbA5pSHA88w3BquC/RIz1vu9HQx0bxpnUII6soQ=;
	b=Syg/SUvTB75SBd7Qb4SNEb6+31nglpKLj20ncZlafqNJqws5QpFwQ1ZkbwLxZcJZwB
	FEKX4NhjeOYi4QSoQCBl3zJqn0fgGq5FnhQLBwo2CA3llnHvI2eZ5cICDY5d0grlSuhg
	FdL8uM09OikxEXTXJ31bHmbzx7hdiGafENlCiPOB2iYs8yj/tF5IIm0heNwzIBKiArCs
	ovLF8UDyX/dYsL67+jiLhOy9aJ8ukKqtkDPqq+CbInjjMflGCnVj4MEmuP5F3EBz2yk+
	8mBY0eWPcYSGDVs5rSG3+P8ZU1LTM59Q8THMqlNi6dCIGyys32JBfq9bdMG6oXdKyfXT
	JZSg==
Received: by 10.14.48.71 with SMTP id u47mr3354332eeb.205.1340021581653;
	Mon, 18 Jun 2012 05:13:01 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id z5sm60715118eem.3.2012.06.18.05.13.00
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 05:13:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 13:12:56 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC04D9D8.431BE%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1NS7GIhaFcexrne0CyMjD4CkPDqA==
In-Reply-To: <4FDEF595020000780008A5B7@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] fpu_taskswitch adjustment 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 18/06/2012 08:32, "Jan Beulich" <JBeulich@suse.com> wrote:

>> It should be possible for the guest kernel to track its CR0.TS setting
>> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
>> cleared on #NM.
> 
> Sure, but selling this to the Linux maintainers I would expect to be
> harder than fitting the Xen side of things into the current save-
> and-restore model the native xor code uses. It would only be strait
> forward to implement on the legacy, forward ported trees.

Wouldn't it be hidden entirely behind pv_ops hooks and within Xen-specific
SSE save/restore code? I suppose you'd need to statically allocate the
per-cpu space for tracking the CR0.TS state... But overall it seems it will
be of little/no concern to other kernel maintainers?

 -- Keir

> However, with the #NM handler in pv-ops apparently not
> leveraging the fact that CR0.TS is already cleared for it on entry,
> maybe this could indeed be introduced together. Konrad?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 12:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12:20: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 1Sgavs-0001J4-2i; Mon, 18 Jun 2012 12:19:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sgavq-0001Iz-8B
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:19:46 +0000
Received: from [85.158.143.99:48230] by server-1.bemta-4.messagelabs.com id
	69/BD-24392-1EC1FDF4; Mon, 18 Jun 2012 12:19:45 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340021983!24503974!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15781 invoked from network); 18 Jun 2012 12:19:44 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-216.messagelabs.com with SMTP;
	18 Jun 2012 12:19:44 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78956305; Mon, 18 Jun 2012 14:19:43 +0200
Message-ID: <1340021982.2997.2.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Jun 2012 14:19:42 +0200
In-Reply-To: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5808402642343887905=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5808402642343887905==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ZYlbwKH8db/LQcBzDEBG"


--=-ZYlbwKH8db/LQcBzDEBG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-12 at 14:00 +0100, Ian Campbell wrote:=20
> * xl compatibility with xm:
>=20
>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
>=20
>         * does not automatically try to select a (set of) node(s) on
>           which to create a VM and pin its vcpus there. (Dario
>           Faggioli, patches reposted, under review)
>=20
v2 posted last Friday.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ZYlbwKH8db/LQcBzDEBG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/fHN4ACgkQk4XaBE3IOsRqygCfRo78oZGsUDA/s12wr23rhr1Q
hfMAn1sFH+lBfOk7RqU/4s2dyWP608xp
=h2no
-----END PGP SIGNATURE-----

--=-ZYlbwKH8db/LQcBzDEBG--



--===============5808402642343887905==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5808402642343887905==--



From xen-devel-bounces@lists.xen.org Mon Jun 18 12:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12:20: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 1Sgavs-0001J4-2i; Mon, 18 Jun 2012 12:19:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Sgavq-0001Iz-8B
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:19:46 +0000
Received: from [85.158.143.99:48230] by server-1.bemta-4.messagelabs.com id
	69/BD-24392-1EC1FDF4; Mon, 18 Jun 2012 12:19:45 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340021983!24503974!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15781 invoked from network); 18 Jun 2012 12:19:44 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-216.messagelabs.com with SMTP;
	18 Jun 2012 12:19:44 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 78956305; Mon, 18 Jun 2012 14:19:43 +0200
Message-ID: <1340021982.2997.2.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Jun 2012 14:19:42 +0200
In-Reply-To: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5808402642343887905=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5808402642343887905==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ZYlbwKH8db/LQcBzDEBG"


--=-ZYlbwKH8db/LQcBzDEBG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-12 at 14:00 +0100, Ian Campbell wrote:=20
> * xl compatibility with xm:
>=20
>         * [BUG] cannot create an empty CD-ROM drive on HVM guest,
>           reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
>=20
>         * does not automatically try to select a (set of) node(s) on
>           which to create a VM and pin its vcpus there. (Dario
>           Faggioli, patches reposted, under review)
>=20
v2 posted last Friday.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ZYlbwKH8db/LQcBzDEBG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/fHN4ACgkQk4XaBE3IOsRqygCfRo78oZGsUDA/s12wr23rhr1Q
hfMAn1sFH+lBfOk7RqU/4s2dyWP608xp
=h2no
-----END PGP SIGNATURE-----

--=-ZYlbwKH8db/LQcBzDEBG--



--===============5808402642343887905==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5808402642343887905==--



From xen-devel-bounces@lists.xen.org Mon Jun 18 12:45:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12: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 1SgbKS-0001iS-D8; Mon, 18 Jun 2012 12:45:12 +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 1SgbKR-0001iN-GB
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:45:11 +0000
Received: from [85.158.139.83:2924] by server-12.bemta-5.messagelabs.com id
	3C/B0-25233-6D22FDF4; Mon, 18 Jun 2012 12:45:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340023509!28135645!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2262 invoked from network); 18 Jun 2012 12:45:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 12:45:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 13:45:08 +0100
Message-Id: <4FDF3EF2020000780008A6F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 13:45:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FDEF595020000780008A5B7@nat28.tlf.novell.com>
	<CC04D9D8.431BE%keir@xen.org>
In-Reply-To: <CC04D9D8.431BE%keir@xen.org>
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] fpu_taskswitch adjustment 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 18.06.12 at 14:12, Keir Fraser <keir@xen.org> wrote:
> On 18/06/2012 08:32, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> It should be possible for the guest kernel to track its CR0.TS setting
>>> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
>>> cleared on #NM.
>> 
>> Sure, but selling this to the Linux maintainers I would expect to be
>> harder than fitting the Xen side of things into the current save-
>> and-restore model the native xor code uses. It would only be strait
>> forward to implement on the legacy, forward ported trees.
> 
> Wouldn't it be hidden entirely behind pv_ops hooks and within Xen-specific
> SSE save/restore code? I suppose you'd need to statically allocate the
> per-cpu space for tracking the CR0.TS state... But overall it seems it will
> be of little/no concern to other kernel maintainers?

The #NM handler part wouldn't afaict. Everything else indeed
ought to be restricted to the functions backing paravirt.h's clts()
and write_cr0().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 12:45:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12: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 1SgbKS-0001iS-D8; Mon, 18 Jun 2012 12:45:12 +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 1SgbKR-0001iN-GB
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:45:11 +0000
Received: from [85.158.139.83:2924] by server-12.bemta-5.messagelabs.com id
	3C/B0-25233-6D22FDF4; Mon, 18 Jun 2012 12:45:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340023509!28135645!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2262 invoked from network); 18 Jun 2012 12:45:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	18 Jun 2012 12:45:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 13:45:08 +0100
Message-Id: <4FDF3EF2020000780008A6F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 13:45:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FDEF595020000780008A5B7@nat28.tlf.novell.com>
	<CC04D9D8.431BE%keir@xen.org>
In-Reply-To: <CC04D9D8.431BE%keir@xen.org>
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] fpu_taskswitch adjustment 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 18.06.12 at 14:12, Keir Fraser <keir@xen.org> wrote:
> On 18/06/2012 08:32, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> It should be possible for the guest kernel to track its CR0.TS setting
>>> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
>>> cleared on #NM.
>> 
>> Sure, but selling this to the Linux maintainers I would expect to be
>> harder than fitting the Xen side of things into the current save-
>> and-restore model the native xor code uses. It would only be strait
>> forward to implement on the legacy, forward ported trees.
> 
> Wouldn't it be hidden entirely behind pv_ops hooks and within Xen-specific
> SSE save/restore code? I suppose you'd need to statically allocate the
> per-cpu space for tracking the CR0.TS state... But overall it seems it will
> be of little/no concern to other kernel maintainers?

The #NM handler part wouldn't afaict. Everything else indeed
ought to be restricted to the functions backing paravirt.h's clts()
and write_cr0().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 12:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12: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 1SgbPZ-0001rL-8v; Mon, 18 Jun 2012 12:50:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SgbPY-0001rF-0A
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:50:28 +0000
Received: from [85.158.143.99:10163] by server-1.bemta-4.messagelabs.com id
	5E/08-24392-3142FDF4; Mon, 18 Jun 2012 12:50:27 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340023821!20843519!1
X-Originating-IP: [209.85.216.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9129 invoked from network); 18 Jun 2012 12:50:26 -0000
Received: from mail-qa0-f49.google.com (HELO mail-qa0-f49.google.com)
	(209.85.216.49)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 12:50:26 -0000
Received: by qabj40 with SMTP id j40so5022764qab.15
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 05:50:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=bBMXZXDYuY1qugrUfy3Zc9pLt265lL89FSJJyBALs5o=;
	b=fl+WG7Z1Asyn+LWPdV7emEW/0b1cIrPs7DMdRMuhxss3QW9xjOGYbycyy+dKYlQZIK
	MrTQLRXKjV4LQPfEFCfnnyc+LeMthcQbBMzpAuoE69gGWE+PNAst1erOZNSSM1oZMb3C
	2EaZZKOWo8TGHFBiFj17QjEpOOZFk+VGKIyG6Mi/DUHOWbQsSyt8FJgahzBrtgDiAuPJ
	uBSzMd6PSHwlp2Rw+Uta7quZ2+GiE4Hg1tsHqcPGDyftCVlK3uGO3iBBCuUDtBd05pSz
	aFzjdJrZAj3ll9svPkarN/UkCcOvCWuTjEpRp3k6k6VW/dvGDMF0gzQHS3vn0qCg9eiv
	4JLg==
Received: by 10.224.217.67 with SMTP id hl3mr26795224qab.75.1340023821397;
	Mon, 18 Jun 2012 05:50:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.162.10 with HTTP; Mon, 18 Jun 2012 05:50:01 -0700 (PDT)
In-Reply-To: <4FDF2ECC020000780008A6AF@nat28.tlf.novell.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
	<4FDF2ECC020000780008A6AF@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 18 Jun 2012 13:50:01 +0100
Message-ID: <CAEBdQ90m+CwQM8+wtEX+amcqBnUrPWg5Cv+gW_UTLcb4W7zZ1Q@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 18 June 2012 12:36, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 14.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
>> Here are the structs:
>>
>> typedef struct v4v_ring_data_ent
>>
>> {
>>
>> =A0 =A0 struct v4v_addr ring;
>>
>> =A0 =A0 uint16_t flags;
>>
>> =A0 =A0 uint16_t pad0;
>>
>> =A0 =A0 uint32_t space_required;
>>
>> =A0 =A0 uint32_t max_message_size;
>>
>> } v4v_ring_data_ent_t;
>>
>> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
>>
>>
>>
>> typedef struct v4v_ring_data
>>
>> {
>>
>> =A0 =A0 uint64_t magic;
>>
>> =A0 =A0 uint32_t nent;
>>
>> =A0 =A0 uint32_t padding;
>>
>> =A0 =A0 uint64_t reserved[4];
>>
>> =A0 =A0 v4v_ring_data_ent_t ring[0];
>>
>> } v4v_ring_data_t;
>>
>> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
>>
>> I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall an=
d I
>> would like to access the ring data inside it which is a XEN_GUEST_HANDLE=
 as well.
>>
>> Here is the code that I use for doing that (with explicte cast in
>> guest_handle_cast):
>> =A0 =A0 XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
>> =A0 =A0 XEN_GUEST_HANDLE (uint8_t) slop_hnd =3D
>> =A0 =A0 =A0 =A0 guest_handle_cast (ring_data_hnd, uint8_t);
>> =A0 =A0 guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
>> =A0 =A0 ring_data_ent_hnd =3D
>> =A0 =A0 =A0 =A0 guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
>> =A0 =A0 ret =3D v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hn=
d);
>
> Something as simple as
>
> #define guest_handle_for_field(hnd, type, fld) \
> =A0 =A0((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
>
> works quite fine for me is an example like
>
> int v4v_test(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_data_t) urp) {
> =A0 =A0v4v_ring_data_t ring_data;
> =A0 =A0XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;
>
> =A0 =A0copy_from_guest(&ring_data, urp, 1);
> =A0 =A0ring_data_ent_hnd =3D guest_handle_for_field(urp, v4v_ring_data_en=
t_t, ring[0]);
> =A0 =A0return v4v_fill_ring_datas(d, ring_data.nent, ring_data_ent_hnd);
> }
>

Thanks!
That works for me too. I'll replace the code in my patch series.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 12:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 12: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 1SgbPZ-0001rL-8v; Mon, 18 Jun 2012 12:50:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SgbPY-0001rF-0A
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 12:50:28 +0000
Received: from [85.158.143.99:10163] by server-1.bemta-4.messagelabs.com id
	5E/08-24392-3142FDF4; Mon, 18 Jun 2012 12:50:27 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340023821!20843519!1
X-Originating-IP: [209.85.216.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9129 invoked from network); 18 Jun 2012 12:50:26 -0000
Received: from mail-qa0-f49.google.com (HELO mail-qa0-f49.google.com)
	(209.85.216.49)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 12:50:26 -0000
Received: by qabj40 with SMTP id j40so5022764qab.15
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 05:50:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=bBMXZXDYuY1qugrUfy3Zc9pLt265lL89FSJJyBALs5o=;
	b=fl+WG7Z1Asyn+LWPdV7emEW/0b1cIrPs7DMdRMuhxss3QW9xjOGYbycyy+dKYlQZIK
	MrTQLRXKjV4LQPfEFCfnnyc+LeMthcQbBMzpAuoE69gGWE+PNAst1erOZNSSM1oZMb3C
	2EaZZKOWo8TGHFBiFj17QjEpOOZFk+VGKIyG6Mi/DUHOWbQsSyt8FJgahzBrtgDiAuPJ
	uBSzMd6PSHwlp2Rw+Uta7quZ2+GiE4Hg1tsHqcPGDyftCVlK3uGO3iBBCuUDtBd05pSz
	aFzjdJrZAj3ll9svPkarN/UkCcOvCWuTjEpRp3k6k6VW/dvGDMF0gzQHS3vn0qCg9eiv
	4JLg==
Received: by 10.224.217.67 with SMTP id hl3mr26795224qab.75.1340023821397;
	Mon, 18 Jun 2012 05:50:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.162.10 with HTTP; Mon, 18 Jun 2012 05:50:01 -0700 (PDT)
In-Reply-To: <4FDF2ECC020000780008A6AF@nat28.tlf.novell.com>
References: <1338476832-26653-1-git-send-email-jean.guyader@citrix.com>
	<1338476832-26653-5-git-send-email-jean.guyader@citrix.com>
	<4FC7AEBD020000780008774C@nat28.tlf.novell.com>
	<20120614140815.GB22025@spongy>
	<20120614142614.GE90181@ocelot.phlegethon.org>
	<20120614142751.GF90181@ocelot.phlegethon.org>
	<20120614144008.GA24063@spongy> <20120614153913.GC24063@spongy>
	<4FDF2ECC020000780008A6AF@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 18 Jun 2012 13:50:01 +0100
Message-ID: <CAEBdQ90m+CwQM8+wtEX+amcqBnUrPWg5Cv+gW_UTLcb4W7zZ1Q@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for
	guest_handle_cast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 18 June 2012 12:36, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 14.06.12 at 17:39, Jean Guyader <jean.guyader@citrix.com> wrote:
>> Here are the structs:
>>
>> typedef struct v4v_ring_data_ent
>>
>> {
>>
>> =A0 =A0 struct v4v_addr ring;
>>
>> =A0 =A0 uint16_t flags;
>>
>> =A0 =A0 uint16_t pad0;
>>
>> =A0 =A0 uint32_t space_required;
>>
>> =A0 =A0 uint32_t max_message_size;
>>
>> } v4v_ring_data_ent_t;
>>
>> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
>>
>>
>>
>> typedef struct v4v_ring_data
>>
>> {
>>
>> =A0 =A0 uint64_t magic;
>>
>> =A0 =A0 uint32_t nent;
>>
>> =A0 =A0 uint32_t padding;
>>
>> =A0 =A0 uint64_t reserved[4];
>>
>> =A0 =A0 v4v_ring_data_ent_t ring[0];
>>
>> } v4v_ring_data_t;
>>
>> DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
>>
>> I get a XEN_GUEST_HANDLE(v4v_ring_data_t) as argument of my hypercall an=
d I
>> would like to access the ring data inside it which is a XEN_GUEST_HANDLE=
 as well.
>>
>> Here is the code that I use for doing that (with explicte cast in
>> guest_handle_cast):
>> =A0 =A0 XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd;
>> =A0 =A0 XEN_GUEST_HANDLE (uint8_t) slop_hnd =3D
>> =A0 =A0 =A0 =A0 guest_handle_cast (ring_data_hnd, uint8_t);
>> =A0 =A0 guest_handle_add_offset (slop_hnd, sizeof (v4v_ring_data_t));
>> =A0 =A0 ring_data_ent_hnd =3D
>> =A0 =A0 =A0 =A0 guest_handle_cast (slop_hnd, v4v_ring_data_ent_t);
>> =A0 =A0 ret =3D v4v_fill_ring_datas (d, ring_data.nent, ring_data_ent_hn=
d);
>
> Something as simple as
>
> #define guest_handle_for_field(hnd, type, fld) \
> =A0 =A0((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
>
> works quite fine for me is an example like
>
> int v4v_test(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_data_t) urp) {
> =A0 =A0v4v_ring_data_t ring_data;
> =A0 =A0XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;
>
> =A0 =A0copy_from_guest(&ring_data, urp, 1);
> =A0 =A0ring_data_ent_hnd =3D guest_handle_for_field(urp, v4v_ring_data_en=
t_t, ring[0]);
> =A0 =A0return v4v_fill_ring_datas(d, ring_data.nent, ring_data_ent_hnd);
> }
>

Thanks!
That works for me too. I'll replace the code in my patch series.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 13:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 13: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 1SgcUG-0002YT-2n; Mon, 18 Jun 2012 13:59:24 +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 1SgcUE-0002YN-LM
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 13:59:22 +0000
Received: from [85.158.143.35:62160] by server-1.bemta-4.messagelabs.com id
	02/48-24392-A343FDF4; Mon, 18 Jun 2012 13:59:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340027961!12465234!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19220 invoked from network); 18 Jun 2012 13:59:21 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 13:59:21 -0000
Received: by eekd41 with SMTP id d41so1763479eek.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 06:59:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AaPuNpdkyfY5wFfjdeJ4ZCce2LmLnUWOwpydynOfAF8=;
	b=DET5BqrVcQYse9w8YVxiP5afF9bjD9bFHovxVgSMCSTNbryIGMcUY/+Yf48ceWKWrW
	cdYZegnH2dufVGmwV0Z6k/Bc5/kWH1Vph7nOn9RQkSZf7F6GgNSF4nFgmmPjOKPF/7oF
	ow4jRE6vlkUika9b95e9MoS13j1ohrk7L6X9bzrYAlCXZPQ5G0urrAcw6Uo/9LGdXoq/
	kvA7M+JLNiD7SCVV3cxl3BGnY3bvu/19p9PWZ0P/5vJXp1PZhvapSvwLGFfuCTpSkVnG
	IGPdqISLVhI27UjEohqmTpY0SHvXjSaOn/L7P0TZDeqC+VXuMZdUBo8YnQA4huSRDCWk
	xuoA==
Received: by 10.14.127.198 with SMTP id d46mr3679869eei.101.1340027961042;
	Mon, 18 Jun 2012 06:59:21 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id p41sm61848088eef.5.2012.06.18.06.59.19
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 06:59:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 14:59:15 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC04F2C3.431CC%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1NWou2yJlDpUZuz0qUu8ZOhgNVKg==
In-Reply-To: <4FDF3EF2020000780008A6F1@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] fpu_taskswitch adjustment 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 18/06/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Wouldn't it be hidden entirely behind pv_ops hooks and within Xen-specific
>> SSE save/restore code? I suppose you'd need to statically allocate the
>> per-cpu space for tracking the CR0.TS state... But overall it seems it will
>> be of little/no concern to other kernel maintainers?
> 
> The #NM handler part wouldn't afaict. Everything else indeed
> ought to be restricted to the functions backing paravirt.h's clts()
> and write_cr0().

Yes, the #NM handler might need extra treatment. Perhaps we could install
our own #NM wrapper around the kernel's generic handler, which first clears
the saved CR0.TS flag. Then on clts() in the generic handler, our paravirt
clts() would see the flag is already clear and do no hypercall.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 13:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 13: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 1SgcUG-0002YT-2n; Mon, 18 Jun 2012 13:59:24 +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 1SgcUE-0002YN-LM
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 13:59:22 +0000
Received: from [85.158.143.35:62160] by server-1.bemta-4.messagelabs.com id
	02/48-24392-A343FDF4; Mon, 18 Jun 2012 13:59:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340027961!12465234!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19220 invoked from network); 18 Jun 2012 13:59:21 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 13:59:21 -0000
Received: by eekd41 with SMTP id d41so1763479eek.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 06:59:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AaPuNpdkyfY5wFfjdeJ4ZCce2LmLnUWOwpydynOfAF8=;
	b=DET5BqrVcQYse9w8YVxiP5afF9bjD9bFHovxVgSMCSTNbryIGMcUY/+Yf48ceWKWrW
	cdYZegnH2dufVGmwV0Z6k/Bc5/kWH1Vph7nOn9RQkSZf7F6GgNSF4nFgmmPjOKPF/7oF
	ow4jRE6vlkUika9b95e9MoS13j1ohrk7L6X9bzrYAlCXZPQ5G0urrAcw6Uo/9LGdXoq/
	kvA7M+JLNiD7SCVV3cxl3BGnY3bvu/19p9PWZ0P/5vJXp1PZhvapSvwLGFfuCTpSkVnG
	IGPdqISLVhI27UjEohqmTpY0SHvXjSaOn/L7P0TZDeqC+VXuMZdUBo8YnQA4huSRDCWk
	xuoA==
Received: by 10.14.127.198 with SMTP id d46mr3679869eei.101.1340027961042;
	Mon, 18 Jun 2012 06:59:21 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id p41sm61848088eef.5.2012.06.18.06.59.19
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 06:59:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 14:59:15 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC04F2C3.431CC%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1NWou2yJlDpUZuz0qUu8ZOhgNVKg==
In-Reply-To: <4FDF3EF2020000780008A6F1@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] fpu_taskswitch adjustment 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 18/06/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Wouldn't it be hidden entirely behind pv_ops hooks and within Xen-specific
>> SSE save/restore code? I suppose you'd need to statically allocate the
>> per-cpu space for tracking the CR0.TS state... But overall it seems it will
>> be of little/no concern to other kernel maintainers?
> 
> The #NM handler part wouldn't afaict. Everything else indeed
> ought to be restricted to the functions backing paravirt.h's clts()
> and write_cr0().

Yes, the #NM handler might need extra treatment. Perhaps we could install
our own #NM wrapper around the kernel's generic handler, which first clears
the saved CR0.TS flag. Then on clts() in the generic handler, our paravirt
clts() would see the flag is already clear and do no hypercall.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:06:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgcb6-0002mB-Ua; Mon, 18 Jun 2012 14:06:28 +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 1Sgcb5-0002m6-Qu
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:06:28 +0000
Received: from [85.158.139.83:11369] by server-11.bemta-5.messagelabs.com id
	C3/AD-20400-2E53FDF4; Mon, 18 Jun 2012 14:06:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340028385!28513971!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13674 invoked from network); 18 Jun 2012 14:06:26 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:06:26 -0000
Received: by eaak12 with SMTP id k12so1756878eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 07:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9Q87Gcmf9hDxo2lm+qpMhg0aEKHhHfuppx+GDS6SyTk=;
	b=AC3vVtRuRB2cGpSaRJU/CsIaSACX7oBS+eIpcC17IJhnyIoozDeogmHpPv+RJ71D6e
	Ev9sLkJ05k2rVDclIsOkBOHjJMsl90T3oJYEYzw6IxVvPHDJYG2ZRDQIj81af13HJ4nJ
	bAbNvCjs+9eMnJClzeDD9VdquyBI1Zn11UNyuKOEn19rCIxUCTfpufKaeoFp1QQR3c5o
	UvCu/ULe/iMWFV4bVc3LFO/EA+u3Y1YVUPAPp8ORg9urMLjlxp7gyIj/smjMDA56i4+R
	/djfQsYLojO2E1lX21nPFwSmXMgV0RKPv8ieDtU3h9RsS/rDwx2H5kxf7nmrY/mFajvD
	kquA==
Received: by 10.14.188.129 with SMTP id a1mr3571637een.10.1340028365887;
	Mon, 18 Jun 2012 07:06:05 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id o16sm61894792eeb.13.2012.06.18.07.06.04
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 07:06:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 15:05:58 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC04F456.431CD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
	to be set for any callback
Thread-Index: Ac1NW3vr36vP0Tz5aky2/swLmku55A==
In-Reply-To: <4FD881530200007800089ACB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
 to be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/06/2012 11:02, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than deferring the detection of these to the point where they
> get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
> to be raised by IRET, which invokes the guest's [fragile] fail-safe
> callback), don't even allow such to be set.
> 
> 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
> @@ -736,6 +736,14 @@ int arch_set_info_guest(
>      {
>          if ( !compat )
>          {
> +#ifdef __x86_64__
> +            if ( !is_canonical_address(c.nat->user_regs.eip) ||
> +                 !is_canonical_address(c.nat->event_callback_eip) ||
> +                 !is_canonical_address(c.nat->syscall_callback_eip) ||
> +                 !is_canonical_address(c.nat->failsafe_callback_eip) )
> +                return -EINVAL;
> +#endif
> +
>              fixup_guest_stack_selector(d, c.nat->user_regs.ss);
>              fixup_guest_stack_selector(d, c.nat->kernel_ss);
>              fixup_guest_code_selector(d, c.nat->user_regs.cs);
> @@ -745,7 +753,11 @@ int arch_set_info_guest(
>  #endif
>  
>              for ( i = 0; i < 256; i++ )
> +            {
> +                if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
> +                    return -EINVAL;
>                  fixup_guest_code_selector(d, c.nat->trap_ctxt[i].cs);
> +            }
>  
>              /* LDT safety checks. */
>              if ( ((c.nat->ldt_base & (PAGE_SIZE-1)) != 0) ||
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1033,6 +1033,9 @@ long arch_do_domctl(
>  #ifdef __x86_64__
>              if ( !is_hvm_domain(d) )
>              {
> +                if ( !is_canonical_address(evc->sysenter_callback_eip) ||
> +                     !is_canonical_address(evc->syscall32_callback_eip) )
> +                    goto ext_vcpucontext_out;
>                  fixup_guest_code_selector(d, evc->sysenter_callback_cs);
>                  v->arch.pv_vcpu.sysenter_callback_cs      =
>                      evc->sysenter_callback_cs;
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3581,6 +3581,9 @@ long register_guest_nmi_callback(unsigne
>      struct domain *d = v->domain;
>      struct trap_info *t = &v->arch.pv_vcpu.trap_ctxt[TRAP_nmi];
>  
> +    if ( !is_canonical_address(address) )
> +        return -EINVAL;
> +
>      t->vector  = TRAP_nmi;
>      t->flags   = 0;
>      t->cs      = (is_pv_32on64_domain(d) ?
> @@ -3708,6 +3711,9 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
>          if ( cur.address == 0 )
>              break;
>  
> +        if ( !is_canonical_address(cur.address) )
> +            return -EINVAL;
> +
>          fixup_guest_code_selector(curr->domain, cur.cs);
>  
>          memcpy(&dst[cur.vector], &cur, sizeof(cur));
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 18 14:06:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgcb6-0002mB-Ua; Mon, 18 Jun 2012 14:06:28 +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 1Sgcb5-0002m6-Qu
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:06:28 +0000
Received: from [85.158.139.83:11369] by server-11.bemta-5.messagelabs.com id
	C3/AD-20400-2E53FDF4; Mon, 18 Jun 2012 14:06:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340028385!28513971!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13674 invoked from network); 18 Jun 2012 14:06:26 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:06:26 -0000
Received: by eaak12 with SMTP id k12so1756878eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 07:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9Q87Gcmf9hDxo2lm+qpMhg0aEKHhHfuppx+GDS6SyTk=;
	b=AC3vVtRuRB2cGpSaRJU/CsIaSACX7oBS+eIpcC17IJhnyIoozDeogmHpPv+RJ71D6e
	Ev9sLkJ05k2rVDclIsOkBOHjJMsl90T3oJYEYzw6IxVvPHDJYG2ZRDQIj81af13HJ4nJ
	bAbNvCjs+9eMnJClzeDD9VdquyBI1Zn11UNyuKOEn19rCIxUCTfpufKaeoFp1QQR3c5o
	UvCu/ULe/iMWFV4bVc3LFO/EA+u3Y1YVUPAPp8ORg9urMLjlxp7gyIj/smjMDA56i4+R
	/djfQsYLojO2E1lX21nPFwSmXMgV0RKPv8ieDtU3h9RsS/rDwx2H5kxf7nmrY/mFajvD
	kquA==
Received: by 10.14.188.129 with SMTP id a1mr3571637een.10.1340028365887;
	Mon, 18 Jun 2012 07:06:05 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id o16sm61894792eeb.13.2012.06.18.07.06.04
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 07:06:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 15:05:58 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC04F456.431CD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
	to be set for any callback
Thread-Index: Ac1NW3vr36vP0Tz5aky2/swLmku55A==
In-Reply-To: <4FD881530200007800089ACB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: don't allow non-canonical addresses
 to be set for any callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/06/2012 11:02, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than deferring the detection of these to the point where they
> get actually used (the fix for XSA-7, 25480:76eaf5966c05, causing a #GP
> to be raised by IRET, which invokes the guest's [fragile] fail-safe
> callback), don't even allow such to be set.
> 
> 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
> @@ -736,6 +736,14 @@ int arch_set_info_guest(
>      {
>          if ( !compat )
>          {
> +#ifdef __x86_64__
> +            if ( !is_canonical_address(c.nat->user_regs.eip) ||
> +                 !is_canonical_address(c.nat->event_callback_eip) ||
> +                 !is_canonical_address(c.nat->syscall_callback_eip) ||
> +                 !is_canonical_address(c.nat->failsafe_callback_eip) )
> +                return -EINVAL;
> +#endif
> +
>              fixup_guest_stack_selector(d, c.nat->user_regs.ss);
>              fixup_guest_stack_selector(d, c.nat->kernel_ss);
>              fixup_guest_code_selector(d, c.nat->user_regs.cs);
> @@ -745,7 +753,11 @@ int arch_set_info_guest(
>  #endif
>  
>              for ( i = 0; i < 256; i++ )
> +            {
> +                if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
> +                    return -EINVAL;
>                  fixup_guest_code_selector(d, c.nat->trap_ctxt[i].cs);
> +            }
>  
>              /* LDT safety checks. */
>              if ( ((c.nat->ldt_base & (PAGE_SIZE-1)) != 0) ||
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1033,6 +1033,9 @@ long arch_do_domctl(
>  #ifdef __x86_64__
>              if ( !is_hvm_domain(d) )
>              {
> +                if ( !is_canonical_address(evc->sysenter_callback_eip) ||
> +                     !is_canonical_address(evc->syscall32_callback_eip) )
> +                    goto ext_vcpucontext_out;
>                  fixup_guest_code_selector(d, evc->sysenter_callback_cs);
>                  v->arch.pv_vcpu.sysenter_callback_cs      =
>                      evc->sysenter_callback_cs;
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3581,6 +3581,9 @@ long register_guest_nmi_callback(unsigne
>      struct domain *d = v->domain;
>      struct trap_info *t = &v->arch.pv_vcpu.trap_ctxt[TRAP_nmi];
>  
> +    if ( !is_canonical_address(address) )
> +        return -EINVAL;
> +
>      t->vector  = TRAP_nmi;
>      t->flags   = 0;
>      t->cs      = (is_pv_32on64_domain(d) ?
> @@ -3708,6 +3711,9 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
>          if ( cur.address == 0 )
>              break;
>  
> +        if ( !is_canonical_address(cur.address) )
> +            return -EINVAL;
> +
>          fixup_guest_code_selector(curr->domain, cur.cs);
>  
>          memcpy(&dst[cur.vector], &cur, sizeof(cur));
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 18 14:07:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14: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 1SgcbL-0002nK-G2; Mon, 18 Jun 2012 14:06:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SgcbJ-0002nD-RZ
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:06:42 +0000
Received: from [85.158.139.83:13012] by server-7.bemta-5.messagelabs.com id
	0C/EC-28276-0F53FDF4; Mon, 18 Jun 2012 14:06:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340028385!28513971!2
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14373 invoked from network); 18 Jun 2012 14:06:40 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:06:40 -0000
Received: by mail-ey0-f173.google.com with SMTP id k12so1756878eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 07:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nmYQ4eNYMRlRfVgRH/3tCNBlVtakxexG9f1QSc9y09M=;
	b=xJTQ1O+rwWwczNvD5I8avZvGqdUQ+2ICKMKW3HTiQGRjOxxHagvx3u7eStooWwHfec
	/+waQ7P7AqCmc/H866bxm7oOd6XIVLy2pmqs4/z8Hwlw8gKrfI+IF9EENMtoqEagj1b/
	wbR5UJoXuE+HYLaKWYAoiBzM4y0dEoo4IBZO9k7giyN1llwef7aZ6uadHaYsDp6HRNgz
	+6qBLNDTrONVV51yzF8Znz6OXKK3AQIfC02g04/Xi07qRF+mAUkDLNHorT+wGiGLBZxy
	oGEld4QjTeLE2tgxRyYWeInrhug7AjA6Zpn8Mmw/BISgtFRwUE87jAqhvmvGrGK0r0PV
	LWnQ==
Received: by 10.14.96.72 with SMTP id q48mr2118753eef.122.1340028399971;
	Mon, 18 Jun 2012 07:06:39 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id h53sm61953520eea.1.2012.06.18.07.06.37
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 07:06:38 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 15:06:35 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC04F47B.431CE%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
Thread-Index: Ac1NW5H5zkdulotI6UCNquq/ybVutg==
In-Reply-To: <4FD881CB0200007800089ADB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 11:04, "Jan Beulich" <JBeulich@suse.com> wrote:

> Our product management wasn't happy with the "solution" for XSA-9, and
> demanded that customer systems must continue to boot. Rather than
> having our and perhaps other distros carry non-trivial patches, allow
> for more fine grained control (panic on boot, deny guest creation, or
> merely warn) by means of a single line change.

All this seems to allow is to boot but not create domU-s. Which seems a bit
pointless.

 -- Keir

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -32,8 +32,11 @@
>  static char opt_famrev[14];
>  string_param("cpuid_mask_cpu", opt_famrev);
>  
> -static bool_t opt_allow_unsafe;
> +#ifdef __x86_64__
> +/* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
> +s8 __read_mostly opt_allow_unsafe = -1;
>  boolean_param("allow_unsafe", opt_allow_unsafe);
> +#endif
>  
>  static inline void wrmsr_amd(unsigned int index, unsigned int lo,
> unsigned int hi)
> @@ -496,10 +499,19 @@ static void __devinit init_amd(struct cp
> clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
>  
>  #ifdef __x86_64__
> - if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)
> + if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
> +  opt_allow_unsafe = 1;
> + else if (opt_allow_unsafe < 0)
> panic("Xen will not boot on this CPU for security reasons.\n"
>      "Pass \"allow_unsafe\" if you're trusting all your"
>      " (PV) guest kernels.\n");
> + else if (!opt_allow_unsafe && c == &boot_cpu_data)
> +  printk(KERN_WARNING
> +         "*** Xen will not allow creation of DomU-s on"
> +         " this CPU for security reasons. ***\n"
> +         KERN_WARNING
> +         "*** Pass \"allow_unsafe\" if you're trusting"
> +         " all your (PV) guest kernels. ***\n");
>  
> /* AMD CPUs do not support SYSENTER outside of legacy mode. */
> clear_bit(X86_FEATURE_SEP, c->x86_capability);
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -55,6 +55,7 @@
>  #include <asm/traps.h>
>  #include <asm/nmi.h>
>  #include <asm/mce.h>
> +#include <asm/amd.h>
>  #include <xen/numa.h>
>  #include <xen/iommu.h>
>  #ifdef CONFIG_COMPAT
> @@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,
>  
>  #else /* __x86_64__ */
>  
> +    if ( d->domain_id && !is_idle_domain(d) &&
> +         cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )
> +    {
> +        if ( !opt_allow_unsafe )
> +        {
> +            printk(XENLOG_G_ERR "Xen does not allow DomU creation on this
> CPU"
> +                   " for security reasons.\n");
> +            return -EPERM;
> +        }
> +        printk(XENLOG_G_WARNING
> +               "Dom%d may compromise security on this CPU.\n",
> +               d->domain_id);
> +    }
> +
>      BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_pt_pages)
>                   != PAGE_SIZE);
>      pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> --- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -147,6 +147,8 @@ struct cpuinfo_x86;
>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>  
>  #ifdef __x86_64__
> +extern s8 opt_allow_unsafe;
> +
>  void fam10h_check_enable_mmcfg(void);
>  void check_enable_amd_mmconf_dmi(void);
>  #endif
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:07:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14: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 1SgcbL-0002nK-G2; Mon, 18 Jun 2012 14:06:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SgcbJ-0002nD-RZ
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:06:42 +0000
Received: from [85.158.139.83:13012] by server-7.bemta-5.messagelabs.com id
	0C/EC-28276-0F53FDF4; Mon, 18 Jun 2012 14:06:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340028385!28513971!2
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14373 invoked from network); 18 Jun 2012 14:06:40 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:06:40 -0000
Received: by mail-ey0-f173.google.com with SMTP id k12so1756878eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 07:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nmYQ4eNYMRlRfVgRH/3tCNBlVtakxexG9f1QSc9y09M=;
	b=xJTQ1O+rwWwczNvD5I8avZvGqdUQ+2ICKMKW3HTiQGRjOxxHagvx3u7eStooWwHfec
	/+waQ7P7AqCmc/H866bxm7oOd6XIVLy2pmqs4/z8Hwlw8gKrfI+IF9EENMtoqEagj1b/
	wbR5UJoXuE+HYLaKWYAoiBzM4y0dEoo4IBZO9k7giyN1llwef7aZ6uadHaYsDp6HRNgz
	+6qBLNDTrONVV51yzF8Znz6OXKK3AQIfC02g04/Xi07qRF+mAUkDLNHorT+wGiGLBZxy
	oGEld4QjTeLE2tgxRyYWeInrhug7AjA6Zpn8Mmw/BISgtFRwUE87jAqhvmvGrGK0r0PV
	LWnQ==
Received: by 10.14.96.72 with SMTP id q48mr2118753eef.122.1340028399971;
	Mon, 18 Jun 2012 07:06:39 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id h53sm61953520eea.1.2012.06.18.07.06.37
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 07:06:38 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 15:06:35 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC04F47B.431CE%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
Thread-Index: Ac1NW5H5zkdulotI6UCNquq/ybVutg==
In-Reply-To: <4FD881CB0200007800089ADB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 11:04, "Jan Beulich" <JBeulich@suse.com> wrote:

> Our product management wasn't happy with the "solution" for XSA-9, and
> demanded that customer systems must continue to boot. Rather than
> having our and perhaps other distros carry non-trivial patches, allow
> for more fine grained control (panic on boot, deny guest creation, or
> merely warn) by means of a single line change.

All this seems to allow is to boot but not create domU-s. Which seems a bit
pointless.

 -- Keir

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -32,8 +32,11 @@
>  static char opt_famrev[14];
>  string_param("cpuid_mask_cpu", opt_famrev);
>  
> -static bool_t opt_allow_unsafe;
> +#ifdef __x86_64__
> +/* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
> +s8 __read_mostly opt_allow_unsafe = -1;
>  boolean_param("allow_unsafe", opt_allow_unsafe);
> +#endif
>  
>  static inline void wrmsr_amd(unsigned int index, unsigned int lo,
> unsigned int hi)
> @@ -496,10 +499,19 @@ static void __devinit init_amd(struct cp
> clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
>  
>  #ifdef __x86_64__
> - if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)
> + if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
> +  opt_allow_unsafe = 1;
> + else if (opt_allow_unsafe < 0)
> panic("Xen will not boot on this CPU for security reasons.\n"
>      "Pass \"allow_unsafe\" if you're trusting all your"
>      " (PV) guest kernels.\n");
> + else if (!opt_allow_unsafe && c == &boot_cpu_data)
> +  printk(KERN_WARNING
> +         "*** Xen will not allow creation of DomU-s on"
> +         " this CPU for security reasons. ***\n"
> +         KERN_WARNING
> +         "*** Pass \"allow_unsafe\" if you're trusting"
> +         " all your (PV) guest kernels. ***\n");
>  
> /* AMD CPUs do not support SYSENTER outside of legacy mode. */
> clear_bit(X86_FEATURE_SEP, c->x86_capability);
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -55,6 +55,7 @@
>  #include <asm/traps.h>
>  #include <asm/nmi.h>
>  #include <asm/mce.h>
> +#include <asm/amd.h>
>  #include <xen/numa.h>
>  #include <xen/iommu.h>
>  #ifdef CONFIG_COMPAT
> @@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,
>  
>  #else /* __x86_64__ */
>  
> +    if ( d->domain_id && !is_idle_domain(d) &&
> +         cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )
> +    {
> +        if ( !opt_allow_unsafe )
> +        {
> +            printk(XENLOG_G_ERR "Xen does not allow DomU creation on this
> CPU"
> +                   " for security reasons.\n");
> +            return -EPERM;
> +        }
> +        printk(XENLOG_G_WARNING
> +               "Dom%d may compromise security on this CPU.\n",
> +               d->domain_id);
> +    }
> +
>      BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_pt_pages)
>                   != PAGE_SIZE);
>      pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> --- a/xen/include/asm-x86/amd.h
> +++ b/xen/include/asm-x86/amd.h
> @@ -147,6 +147,8 @@ struct cpuinfo_x86;
>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>  
>  #ifdef __x86_64__
> +extern s8 opt_allow_unsafe;
> +
>  void fam10h_check_enable_mmcfg(void);
>  void check_enable_amd_mmconf_dmi(void);
>  #endif
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:14:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgcik-0003Mb-5M; Mon, 18 Jun 2012 14:14:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Sgcii-0003MW-MT
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:14:20 +0000
Received: from [193.109.254.147:15319] by server-1.bemta-14.messagelabs.com id
	25/C1-24612-CB73FDF4; Mon, 18 Jun 2012 14:14:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340028859!10307024!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25589 invoked from network); 18 Jun 2012 14:14:19 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:14:19 -0000
Received: by eaak12 with SMTP id k12so1763755eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 07:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:mime-version:content-type:content-transfer-encoding;
	bh=Oyp5Oca2Mb+EO3HahHrt5v1/MDiqqohcLpD9/8B4uBg=;
	b=bBJIiAgMREZLEWd8ibBmQ6hxuSmasKz8C9RlYx1v0y30/mUYiR2zEzWdIU3/2WkKsG
	XIruKocuzioWq2mV2HdW1K4hWuAST9BjO7GJHZ4xk50SN52P39VmAixAFInfN9gOaoOW
	4AO7FWU5VUqRM3e+EzDmsiuKFZttiHQYFfCkS62ZFkXwO1IDEPSMpYXlzFG33k9ErZW2
	KF4tMnrMlUGlCaceCGMZun1OJvCx3a9sQ/IUxAD0ala45DhQSrspNFFoG3d8WAsHwad7
	ISjZ1a6zJWs4PEadFxSVIlk5mgYLKqj71JaPlXDbO/kGllFfnl7uVwHn9taonbqH6L6Y
	+WTQ==
Received: by 10.14.188.129 with SMTP id a1mr3579533een.10.1340028858777;
	Mon, 18 Jun 2012 07:14:18 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id o16sm61989830eeb.13.2012.06.18.07.14.17
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 07:14:18 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 15:14:14 +0100
From: Keir Fraser <keir@xen.org>
To: <xen-devel@lists.xen.org>
Message-ID: <CC04F646.431E2%keir@xen.org>
Thread-Topic: [ANNOUNCE] Second release candidates for Xen 4.0.4 and 4.1.3
Thread-Index: Ac1NXKOOEABdcbeNmU6bhSc02dys/g==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4 and
	4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:

http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)

Please test!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:14:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgcik-0003Mb-5M; Mon, 18 Jun 2012 14:14:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Sgcii-0003MW-MT
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:14:20 +0000
Received: from [193.109.254.147:15319] by server-1.bemta-14.messagelabs.com id
	25/C1-24612-CB73FDF4; Mon, 18 Jun 2012 14:14:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340028859!10307024!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25589 invoked from network); 18 Jun 2012 14:14:19 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:14:19 -0000
Received: by eaak12 with SMTP id k12so1763755eaa.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 07:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:mime-version:content-type:content-transfer-encoding;
	bh=Oyp5Oca2Mb+EO3HahHrt5v1/MDiqqohcLpD9/8B4uBg=;
	b=bBJIiAgMREZLEWd8ibBmQ6hxuSmasKz8C9RlYx1v0y30/mUYiR2zEzWdIU3/2WkKsG
	XIruKocuzioWq2mV2HdW1K4hWuAST9BjO7GJHZ4xk50SN52P39VmAixAFInfN9gOaoOW
	4AO7FWU5VUqRM3e+EzDmsiuKFZttiHQYFfCkS62ZFkXwO1IDEPSMpYXlzFG33k9ErZW2
	KF4tMnrMlUGlCaceCGMZun1OJvCx3a9sQ/IUxAD0ala45DhQSrspNFFoG3d8WAsHwad7
	ISjZ1a6zJWs4PEadFxSVIlk5mgYLKqj71JaPlXDbO/kGllFfnl7uVwHn9taonbqH6L6Y
	+WTQ==
Received: by 10.14.188.129 with SMTP id a1mr3579533een.10.1340028858777;
	Mon, 18 Jun 2012 07:14:18 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id o16sm61989830eeb.13.2012.06.18.07.14.17
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 07:14:18 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 15:14:14 +0100
From: Keir Fraser <keir@xen.org>
To: <xen-devel@lists.xen.org>
Message-ID: <CC04F646.431E2%keir@xen.org>
Thread-Topic: [ANNOUNCE] Second release candidates for Xen 4.0.4 and 4.1.3
Thread-Index: Ac1NXKOOEABdcbeNmU6bhSc02dys/g==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4 and
	4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:

http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)

Please test!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:29:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:29: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 1Sgcwm-0003ub-Ik; Mon, 18 Jun 2012 14:28: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 1Sgcwl-0003uV-6J
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:28:51 +0000
Received: from [85.158.143.99:33989] by server-2.bemta-4.messagelabs.com id
	08/F6-17938-22B3FDF4; Mon, 18 Jun 2012 14:28:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340029730!27921985!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 18 Jun 2012 14:28:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	18 Jun 2012 14:28:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 15:28:49 +0100
Message-Id: <4FDF573E020000780008A74D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 15:28:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FD881CB0200007800089ADB@nat28.tlf.novell.com>
	<CC04F47B.431CE%keir@xen.org>
In-Reply-To: <CC04F47B.431CE%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:06, Keir Fraser <keir@xen.org> wrote:
> On 13/06/2012 11:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Our product management wasn't happy with the "solution" for XSA-9, and
>> demanded that customer systems must continue to boot. Rather than
>> having our and perhaps other distros carry non-trivial patches, allow
>> for more fine grained control (panic on boot, deny guest creation, or
>> merely warn) by means of a single line change.
> 
> All this seems to allow is to boot but not create domU-s. Which seems a bit
> pointless.

I agree, but that is what our PM mandated as minimal remaining
functionality (refusing to boot was not deemed acceptable). So
my aim with this patch is to carry just a single line distro specific
patch adjusting from the upstream default to the distro default.
Carrying the full patch indefinitely just doesn't seem desirable,
but would be necessary if you're not considering this acceptable.

Jan

>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -32,8 +32,11 @@
>>  static char opt_famrev[14];
>>  string_param("cpuid_mask_cpu", opt_famrev);
>>  
>> -static bool_t opt_allow_unsafe;
>> +#ifdef __x86_64__
>> +/* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
>> +s8 __read_mostly opt_allow_unsafe = -1;
>>  boolean_param("allow_unsafe", opt_allow_unsafe);
>> +#endif
>>  
>>  static inline void wrmsr_amd(unsigned int index, unsigned int lo,
>> unsigned int hi)
>> @@ -496,10 +499,19 @@ static void __devinit init_amd(struct cp
>> clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
>>  
>>  #ifdef __x86_64__
>> - if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)
>> + if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
>> +  opt_allow_unsafe = 1;
>> + else if (opt_allow_unsafe < 0)
>> panic("Xen will not boot on this CPU for security reasons.\n"
>>      "Pass \"allow_unsafe\" if you're trusting all your"
>>      " (PV) guest kernels.\n");
>> + else if (!opt_allow_unsafe && c == &boot_cpu_data)
>> +  printk(KERN_WARNING
>> +         "*** Xen will not allow creation of DomU-s on"
>> +         " this CPU for security reasons. ***\n"
>> +         KERN_WARNING
>> +         "*** Pass \"allow_unsafe\" if you're trusting"
>> +         " all your (PV) guest kernels. ***\n");
>>  
>> /* AMD CPUs do not support SYSENTER outside of legacy mode. */
>> clear_bit(X86_FEATURE_SEP, c->x86_capability);
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -55,6 +55,7 @@
>>  #include <asm/traps.h>
>>  #include <asm/nmi.h>
>>  #include <asm/mce.h>
>> +#include <asm/amd.h>
>>  #include <xen/numa.h>
>>  #include <xen/iommu.h>
>>  #ifdef CONFIG_COMPAT
>> @@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,
>>  
>>  #else /* __x86_64__ */
>>  
>> +    if ( d->domain_id && !is_idle_domain(d) &&
>> +         cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )
>> +    {
>> +        if ( !opt_allow_unsafe )
>> +        {
>> +            printk(XENLOG_G_ERR "Xen does not allow DomU creation on this
>> CPU"
>> +                   " for security reasons.\n");
>> +            return -EPERM;
>> +        }
>> +        printk(XENLOG_G_WARNING
>> +               "Dom%d may compromise security on this CPU.\n",
>> +               d->domain_id);
>> +    }
>> +
>>      BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_pt_pages)
>>                   != PAGE_SIZE);
>>      pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
>> --- a/xen/include/asm-x86/amd.h
>> +++ b/xen/include/asm-x86/amd.h
>> @@ -147,6 +147,8 @@ struct cpuinfo_x86;
>>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>>  
>>  #ifdef __x86_64__
>> +extern s8 opt_allow_unsafe;
>> +
>>  void fam10h_check_enable_mmcfg(void);
>>  void check_enable_amd_mmconf_dmi(void);
>>  #endif
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:29:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:29: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 1Sgcwm-0003ub-Ik; Mon, 18 Jun 2012 14:28: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 1Sgcwl-0003uV-6J
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 14:28:51 +0000
Received: from [85.158.143.99:33989] by server-2.bemta-4.messagelabs.com id
	08/F6-17938-22B3FDF4; Mon, 18 Jun 2012 14:28:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340029730!27921985!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 18 Jun 2012 14:28:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	18 Jun 2012 14:28:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Jun 2012 15:28:49 +0100
Message-Id: <4FDF573E020000780008A74D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 18 Jun 2012 15:28:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FD881CB0200007800089ADB@nat28.tlf.novell.com>
	<CC04F47B.431CE%keir@xen.org>
In-Reply-To: <CC04F47B.431CE%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64: refine the XSA-9 fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:06, Keir Fraser <keir@xen.org> wrote:
> On 13/06/2012 11:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Our product management wasn't happy with the "solution" for XSA-9, and
>> demanded that customer systems must continue to boot. Rather than
>> having our and perhaps other distros carry non-trivial patches, allow
>> for more fine grained control (panic on boot, deny guest creation, or
>> merely warn) by means of a single line change.
> 
> All this seems to allow is to boot but not create domU-s. Which seems a bit
> pointless.

I agree, but that is what our PM mandated as minimal remaining
functionality (refusing to boot was not deemed acceptable). So
my aim with this patch is to carry just a single line distro specific
patch adjusting from the upstream default to the distro default.
Carrying the full patch indefinitely just doesn't seem desirable,
but would be necessary if you're not considering this acceptable.

Jan

>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -32,8 +32,11 @@
>>  static char opt_famrev[14];
>>  string_param("cpuid_mask_cpu", opt_famrev);
>>  
>> -static bool_t opt_allow_unsafe;
>> +#ifdef __x86_64__
>> +/* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
>> +s8 __read_mostly opt_allow_unsafe = -1;
>>  boolean_param("allow_unsafe", opt_allow_unsafe);
>> +#endif
>>  
>>  static inline void wrmsr_amd(unsigned int index, unsigned int lo,
>> unsigned int hi)
>> @@ -496,10 +499,19 @@ static void __devinit init_amd(struct cp
>> clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
>>  
>>  #ifdef __x86_64__
>> - if (cpu_has_amd_erratum(c, AMD_ERRATUM_121) && !opt_allow_unsafe)
>> + if (!cpu_has_amd_erratum(c, AMD_ERRATUM_121))
>> +  opt_allow_unsafe = 1;
>> + else if (opt_allow_unsafe < 0)
>> panic("Xen will not boot on this CPU for security reasons.\n"
>>      "Pass \"allow_unsafe\" if you're trusting all your"
>>      " (PV) guest kernels.\n");
>> + else if (!opt_allow_unsafe && c == &boot_cpu_data)
>> +  printk(KERN_WARNING
>> +         "*** Xen will not allow creation of DomU-s on"
>> +         " this CPU for security reasons. ***\n"
>> +         KERN_WARNING
>> +         "*** Pass \"allow_unsafe\" if you're trusting"
>> +         " all your (PV) guest kernels. ***\n");
>>  
>> /* AMD CPUs do not support SYSENTER outside of legacy mode. */
>> clear_bit(X86_FEATURE_SEP, c->x86_capability);
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -55,6 +55,7 @@
>>  #include <asm/traps.h>
>>  #include <asm/nmi.h>
>>  #include <asm/mce.h>
>> +#include <asm/amd.h>
>>  #include <xen/numa.h>
>>  #include <xen/iommu.h>
>>  #ifdef CONFIG_COMPAT
>> @@ -531,6 +532,20 @@ int arch_domain_create(struct domain *d,
>>  
>>  #else /* __x86_64__ */
>>  
>> +    if ( d->domain_id && !is_idle_domain(d) &&
>> +         cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_121) )
>> +    {
>> +        if ( !opt_allow_unsafe )
>> +        {
>> +            printk(XENLOG_G_ERR "Xen does not allow DomU creation on this
>> CPU"
>> +                   " for security reasons.\n");
>> +            return -EPERM;
>> +        }
>> +        printk(XENLOG_G_WARNING
>> +               "Dom%d may compromise security on this CPU.\n",
>> +               d->domain_id);
>> +    }
>> +
>>      BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.mm_perdomain_pt_pages)
>>                   != PAGE_SIZE);
>>      pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
>> --- a/xen/include/asm-x86/amd.h
>> +++ b/xen/include/asm-x86/amd.h
>> @@ -147,6 +147,8 @@ struct cpuinfo_x86;
>>  int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
>>  
>>  #ifdef __x86_64__
>> +extern s8 opt_allow_unsafe;
>> +
>>  void fam10h_check_enable_mmcfg(void);
>>  void check_enable_amd_mmconf_dmi(void);
>>  #endif
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:38:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgd5e-0004Gn-Je; Mon, 18 Jun 2012 14:38: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 1Sgd5c-0004Gi-G6
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 14:38:01 +0000
Received: from [85.158.139.83:29587] by server-1.bemta-5.messagelabs.com id
	1A/BC-19721-74D3FDF4; Mon, 18 Jun 2012 14:37:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340030278!20900529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5854 invoked from network); 18 Jun 2012 14:37:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:37:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,792,1330905600"; d="scan'208";a="13082425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 14:37:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 15:37:58 +0100
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 1Sgd5Z-0005Xz-TY;
	Mon, 18 Jun 2012 14:37:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sgd5Z-0008MM-DL;
	Mon, 18 Jun 2012 15:37:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Sgd5Z-0008MM-DL@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 15:37:57 +0100
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-i386-i386-xl-win
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-i386-i386-xl-win
test windows-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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6


  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13075 fail [host=leaf-beetle] / 13025 ok.
Failure / basis pass flights: 13075 / 13025
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-6d8b472233779c2a028a03843603030d2b1aee86 http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-9dffb1864f2c
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 17 nodes in revision graph
Searching for test results:
 7623 [host=gall-mite]
 8249 [host=earwig]
 8289 [host=potato-beetle]
 7624 [host=itch-mite]
 8674 [host=earwig]
 8175 [host=gall-mite]
 7628 [host=earwig]
 7791 [host=earwig]
 7629 [host=itch-mite]
 8100 [host=potato-beetle]
 8024 [host=earwig]
 7544 []
 7630 [host=earwig]
 8026 [host=earwig]
 7874 [host=gall-mite]
 8292 []
 7633 [host=earwig]
 8256 [host=potato-beetle]
 7634 [host=earwig]
 8029 [host=earwig]
 8295 [host=itch-mite]
 8423 [host=earwig]
 7798 [host=gall-mite]
 8108 [host=gall-mite]
 8363 [host=potato-beetle]
 8427 [host=itch-mite]
 8034 [host=earwig]
 7554 [host=earwig]
 7882 [host=earwig]
 7556 [host=potato-beetle]
 8302 !! flight 8302 missing revision for qemuu
 7726 [host=gall-mite]
 8191 [host=itch-mite]
 8369 !! flight 8369 missing revision for qemuu
 7728 [host=earwig]
 7807 [host=gall-mite]
 8305 []
 7889 [host=gall-mite]
 7563 [host=gall-mite]
 7733 [host=gall-mite]
 7815 [host=earwig]
 8046 [host=earwig]
 8308 [host=potato-beetle]
 7896 [host=earwig]
 8374 [host=itch-mite]
 7738 [host=gall-mite]
 8201 !! flight 8201 missing revision for qemuu
 8127 [host=itch-mite]
 8312 [host=itch-mite]
 7742 [host=gall-mite]
 7978 [host=itch-mite]
 8054 [host=gall-mite]
 7577 [host=itch-mite]
 7663 [host=potato-beetle]
 7904 [host=gall-mite]
 7980 [host=earwig]
 8316 [host=earwig]
 8057 [host=itch-mite]
 8209 [host=earwig]
 7748 [host=itch-mite]
 7749 [host=earwig]
 7830 [host=earwig]
 8061 [host=earwig]
 8137 [host=gall-mite]
 7751 []
 8387 [host=earwig]
 8643 [host=gall-mite]
 7753 [host=itch-mite]
 8217 [host=earwig]
 8325 [host=earwig]
 7836 [host=gall-mite]
 5145 [host=gall-mite]
 5159 [host=earwig]
 5161 [host=gall-mite]
 7590 [host=itch-mite]
 7676 []
 5180 [host=gall-mite]
 8142 [host=itch-mite]
 8326 [host=potato-beetle]
 5237 [host=earwig]
 5238 [host=gall-mite]
 5231 [host=gall-mite]
 8067 !! flight 8067 missing revision for qemuu
 5233 [host=gall-mite]
 5240 [host=earwig]
 8327 !! flight 8327 missing revision for qemuu
 5352 [host=gall-mite]
 8328 [host=gall-mite]
 5469 [host=gall-mite]
 5363 [host=gall-mite]
 5435 []
 5508 [host=earwig]
 5482 [host=earwig]
 5500 [host=earwig]
 5501 [host=gall-mite]
 5502 [host=itch-mite]
 5503 [host=earwig]
 7760 [host=gall-mite]
 5506 [host=earwig]
 7680 [host=earwig]
 5538 [host=earwig]
 5566 [host=earwig]
 5568 [host=gall-mite]
 8071 [host=itch-mite]
 5588 [host=earwig]
 5644 []
 5590 [host=gall-mite]
 5593 [host=earwig]
 5620 [host=gall-mite]
 5650 []
 5654 []
 5640 [host=gall-mite]
 5641 [host=gall-mite]
 5655 []
 5656 []
 8147 [host=potato-beetle]
 5657 []
 5658 []
 5659 []
 8223 [host=gall-mite]
 5660 []
 5661 []
 5689 [host=gall-mite]
 5663 []
 5664 []
 5665 []
 5666 []
 8394 [host=potato-beetle]
 5696 [host=gall-mite]
 5673 [host=itch-mite]
 5697 [host=gall-mite]
 5677 [host=itch-mite]
 5680 [host=gall-mite]
 5685 [host=earwig]
 5692 [host=gall-mite]
 5700 [host=earwig]
 5740 [host=itch-mite]
 5741 [host=gall-mite]
 5743 [host=earwig]
 5748 [host=earwig]
 5749 [host=earwig]
 5750 [host=itch-mite]
 5751 [host=gall-mite]
 5752 [host=earwig]
 5781 []
 5772 [host=gall-mite]
 5753 [host=earwig]
 5754 [host=itch-mite]
 5755 [host=gall-mite]
 5756 [host=earwig]
 5757 [host=itch-mite]
 5823 [host=earwig]
 5758 [host=itch-mite]
 5760 [host=gall-mite]
 5762 [host=itch-mite]
 5764 [host=itch-mite]
 5766 [host=itch-mite]
 5775 [host=earwig]
 5787 [host=earwig]
 5806 [host=itch-mite]
 5825 [host=earwig]
 5830 [host=gall-mite]
 5833 [host=earwig]
 5855 [host=gall-mite]
 5862 [host=earwig]
 7914 [host=gall-mite]
 5870 [host=gall-mite]
 6156 [host=earwig]
 6282 [host=potato-beetle]
 6272 [host=gall-mite]
 6207 !! flight 6207 missing revision for qemuu
 6244 [host=earwig]
 6246 [host=gall-mite]
 6261 [host=potato-beetle]
 6266 [host=gall-mite]
 6280 [host=gall-mite]
 6291 [host=earwig]
 6288 [host=gall-mite]
 6289 [host=earwig]
 6295 [host=potato-beetle]
 6296 [host=gall-mite]
 6297 [host=gall-mite]
 6299 [host=gall-mite]
 6301 [host=earwig]
 6305 !! flight 6305 missing revision for qemuu
 6363 [host=gall-mite]
 6307 [host=gall-mite]
 6340 [host=earwig]
 6310 [host=earwig]
 6316 [host=gall-mite]
 6319 [host=gall-mite]
 6323 [host=earwig]
 6367 [host=earwig]
 6325 [host=earwig]
 6327 [host=earwig]
 6345 [host=gall-mite]
 6331 [host=earwig]
 6334 !! flight 6334 missing revision for qemuu
 6382 [host=earwig]
 6336 [host=gall-mite]
 6374 [host=gall-mite]
 6369 [host=gall-mite]
 6354 [host=potato-beetle]
 6396 [host=gall-mite]
 6413 [host=gall-mite]
 6441 [host=earwig]
 6597 [host=potato-beetle]
 6608 [host=gall-mite]
 6564 [host=earwig]
 6599 [host=earwig]
 6612 [host=itch-mite]
 6590 [host=potato-beetle]
 6602 [host=earwig]
 6605 [host=earwig]
 6617 [host=potato-beetle]
 6621 [host=itch-mite]
 7846 [host=earwig]
 7922 [host=gall-mite]
 6624 [host=gall-mite]
 6628 [host=gall-mite]
 7766 [host=earwig]
 6636 [host=itch-mite]
 6640 [host=earwig]
 6647 [host=itch-mite]
 6651 [host=gall-mite]
 6652 [host=earwig]
 6658 [host=itch-mite]
 6663 [host=gall-mite]
 6667 []
 6724 [host=gall-mite]
 6688 []
 6690 []
 6692 [host=gall-mite]
 6708 []
 6726 [host=itch-mite]
 6711 []
 6712 []
 6733 [host=earwig]
 6713 []
 6714 []
 6734 [host=itch-mite]
 6715 []
 6716 []
 6717 []
 6736 [host=gall-mite]
 6718 []
 6719 []
 6720 []
 8000 [host=earwig]
 6737 [host=itch-mite]
 6740 [host=gall-mite]
 8652 [host=potato-beetle]
 6743 [host=itch-mite]
 6746 [host=gall-mite]
 6747 [host=gall-mite]
 6748 [host=itch-mite]
 6749 [host=earwig]
 6751 [host=gall-mite]
 6752 [host=itch-mite]
 6753 [host=earwig]
 6756 [host=potato-beetle]
 6757 [host=gall-mite]
 6758 [host=earwig]
 6769 [host=itch-mite]
 6770 [host=gall-mite]
 6776 [host=itch-mite]
 6777 [host=itch-mite]
 6784 [host=earwig]
 6789 [host=earwig]
 6795 [host=earwig]
 6808 [host=earwig]
 6809 [host=gall-mite]
 6812 [host=itch-mite]
 6813 [host=earwig]
 8078 !! flight 8078 missing revision for qemuu
 6814 [host=gall-mite]
 6818 !! flight 6818 missing revision for qemuu
 6819 [host=earwig]
 6820 [host=earwig]
 8230 [host=potato-beetle]
 6822 [host=itch-mite]
 6825 !! flight 6825 missing revision for qemuu
 6827 [host=earwig]
 6829 [host=potato-beetle]
 6830 [host=earwig]
 6832 [host=gall-mite]
 6836 [host=itch-mite]
 6837 [host=earwig]
 6838 [host=itch-mite]
 6890 !! flight 6890 missing revision for qemuu
 6840 [host=gall-mite]
 6841 []
 6844 []
 6892 [host=itch-mite]
 6854 []
 6905 [host=potato-beetle]
 6894 [host=earwig]
 6863 []
 6895 [host=potato-beetle]
 6870 []
 6872 []
 6896 [host=gall-mite]
 6873 []
 6874 []
 6897 !! flight 6897 missing revision for qemuu
 6875 []
 6876 [host=earwig]
 6877 [host=gall-mite]
 6878 [host=earwig]
 6879 [host=itch-mite]
 6880 [host=gall-mite]
 6884 [host=earwig]
 6898 [host=potato-beetle]
 6899 [host=itch-mite]
 6903 [host=gall-mite]
 6904 [host=gall-mite]
 6914 [host=potato-beetle]
 6915 [host=earwig]
 6918 [host=potato-beetle]
 6922 [host=potato-beetle]
 6927 !! flight 6927 missing revision for qemuu
 8080 [host=itch-mite]
 6930 !! flight 6930 missing revision for qemuu
 6935 [host=gall-mite]
 6936 [host=itch-mite]
 6941 !! flight 6941 missing revision for qemuu
 6942 [host=potato-beetle]
 6943 [host=earwig]
 6944 !! flight 6944 missing revision for qemuu
 6945 !! flight 6945 missing revision for qemuu
 6946 [host=potato-beetle]
 6986 !! flight 6986 missing revision for qemuu
 7003 [host=itch-mite]
 6987 [host=potato-beetle]
 7607 [host=itch-mite]
 6988 [host=gall-mite]
 6992 [host=earwig]
 6993 !! flight 6993 missing revision for qemuu
 8401 [host=earwig]
 7693 [host=earwig]
 6994 [host=gall-mite]
 6996 [host=itch-mite]
 7772 [host=potato-beetle]
 6997 [host=earwig]
 6999 [host=potato-beetle]
 7000 [host=earwig]
 7038 [host=potato-beetle]
 7608 [host=earwig]
 7040 [host=earwig]
 7041 !! flight 7041 missing revision for qemuu
 7056 [host=earwig]
 8006 [host=itch-mite]
 8158 [host=potato-beetle]
 7077 [host=earwig]
 7080 [host=itch-mite]
 7083 !! flight 7083 missing revision for qemuu
 7084 [host=potato-beetle]
 7128 [host=earwig]
 7130 [host=itch-mite]
 7854 [host=gall-mite]
 7111 [host=gall-mite]
 7115 [host=itch-mite]
 7134 [host=itch-mite]
 7122 [host=gall-mite]
 7139 [host=earwig]
 7144 []
 7150 []
 8008 [host=itch-mite]
 7160 []
 8236 !! flight 8236 missing revision for qemuu
 7170 []
 7179 []
 7611 [host=gall-mite]
 7185 []
 7202 []
 7209 []
 7698 [host=earwig]
 7219 []
 7225 []
 7240 []
 8087 [host=gall-mite]
 7264 []
 7779 [host=earwig]
 7275 []
 8664 [host=itch-mite]
 8240 [host=gall-mite]
 7285 [host=gall-mite]
 8409 !! flight 8409 missing revision for qemuu
 7307 [host=itch-mite]
 7860 [host=earwig]
 8013 [host=earwig]
 7315 [host=itch-mite]
 7320 [host=itch-mite]
 7331 []
 7335 []
 7337 []
 7341 []
 7342 []
 7343 [host=gall-mite]
 7346 [host=earwig]
 7364 [host=earwig]
 7366 [host=itch-mite]
 7369 [host=earwig]
 7371 [host=gall-mite]
 7373 []
 7375 []
 7391 [host=earwig]
 7402 [host=earwig]
 8091 [host=itch-mite]
 7409 [host=gall-mite]
 7420 !! flight 7420 missing revision for qemuu
 8244 [host=itch-mite]
 7438 [host=earwig]
 7619 []
 7784 [host=gall-mite]
 7467 [host=gall-mite]
 7470 [host=earwig]
 7472 [host=gall-mite]
 7474 [host=earwig]
 7479 [host=earwig]
 7485 [host=gall-mite]
 7517 [host=itch-mite]
 7491 [host=earwig]
 7865 [host=gall-mite]
 8018 [host=earwig]
 7499 [host=earwig]
 7510 [host=earwig]
 7621 [host=itch-mite]
 8712 [host=field-cricket]
 8722 [host=moss-bug]
 8713 [host=field-cricket]
 8687 [host=itch-mite]
 8735 [host=itch-mite]
 8723 [host=gall-mite]
 8696 [host=potato-beetle]
 8715 [host=field-cricket]
 8707 [host=field-cricket]
 8724 [host=itch-mite]
 8710 [host=gall-mite]
 8717 [host=itch-mite]
 8711 !! flight 8711 missing revision for qemuu
 8718 [host=lace-bug]
 8725 [host=lace-bug]
 8721 !! flight 8721 missing revision for qemuu
 8729 [host=itch-mite]
 8726 [host=potato-beetle]
 8727 [host=field-cricket]
 8731 [host=gall-mite]
 8739 [host=itch-mite]
 8781 []
 8760 !! flight 8760 missing revision for qemuu
 8822 [host=gall-mite]
 8803 []
 8833 [host=gall-mite]
 8769 [host=gall-mite]
 8823 [host=field-cricket]
 8791 []
 8776 []
 8810 []
 8825 [host=itch-mite]
 8826 [host=itch-mite]
 8814 [host=itch-mite]
 8828 [host=itch-mite]
 8836 []
 8817 !! flight 8817 missing revision for qemuu
 8829 [host=itch-mite]
 8830 [host=field-cricket]
 8831 [host=itch-mite]
 8832 [host=field-cricket]
 8846 []
 8854 [host=itch-mite]
 8857 [host=field-cricket]
 8862 [host=field-cricket]
 8859 [host=lace-bug]
 8865 []
 8869 []
 8870 []
 8871 []
 8872 []
 8873 []
 8876 []
 8948 []
 8937 []
 8903 []
 8923 []
 8884 []
 8895 []
 8940 []
 8942 []
 8933 []
 8951 []
 8935 []
 8945 []
 8960 []
 8955 []
 8975 []
 8986 []
 8990 []
 8991 []
 9075 [host=lace-bug]
 8995 [host=field-cricket]
 9065 [host=earwig]
 9000 [host=earwig]
 9043 [host=bush-cricket]
 9083 [host=field-cricket]
 9005 [host=field-cricket]
 9067 [host=itch-mite]
 9054 [host=itch-mite]
 9077 [host=potato-beetle]
 9059 !! flight 9059 missing revision for qemuu
 9069 !! flight 9069 missing revision for qemuu
 9061 [host=potato-beetle]
 9063 [host=lace-bug]
 9071 [host=lace-bug]
 9079 !! flight 9079 missing revision for qemuu
 9085 [host=lace-bug]
 9073 [host=potato-beetle]
 9098 []
 9081 [host=potato-beetle]
 9097 []
 9105 [host=potato-beetle]
 9109 [host=lace-bug]
 9110 [host=field-cricket]
 9113 [host=earwig]
 9115 [host=field-cricket]
 9118 [host=bush-cricket]
 9176 [host=potato-beetle]
 9119 [host=field-cricket]
 9204 [host=gall-mite]
 9191 [host=field-cricket]
 9121 [host=bush-cricket]
 9138 [host=gall-mite]
 9181 [host=gall-mite]
 9163 [host=earwig]
 9198 [host=field-cricket]
 9182 [host=gall-mite]
 9192 [host=gall-mite]
 9183 [host=bush-cricket]
 9160 [host=field-cricket]
 9193 [host=field-cricket]
 9169 [host=bush-cricket]
 9186 [host=field-cricket]
 9187 [host=gall-mite]
 9201 [host=bush-cricket]
 9195 [host=earwig]
 9188 [host=bush-cricket]
 9203 [host=earwig]
 9224 [host=bush-cricket]
 9207 [host=field-cricket]
 9234 [host=lace-bug]
 9235 [host=field-cricket]
 9236 [host=field-cricket]
 9237 [host=gall-mite]
 9238 [host=field-cricket]
 9242 [host=field-cricket]
 9239 [host=bush-cricket]
 9243 [host=field-cricket]
 9244 [host=earwig]
 9245 [host=gall-mite]
 9246 [host=field-cricket]
 9247 [host=earwig]
 9251 [host=bush-cricket]
 9252 [host=potato-beetle]
 9253 [host=earwig]
 9275 [host=bush-cricket]
 9292 [host=earwig]
 9339 [host=gall-mite]
 9341 [host=bush-cricket]
 9342 [host=field-cricket]
 9343 [host=bush-cricket]
 9344 [host=bush-cricket]
 9345 [host=earwig]
 9346 [host=potato-beetle]
 9347 [host=field-cricket]
 9348 [host=bush-cricket]
 9349 [host=field-cricket]
 9350 [host=bush-cricket]
 9351 [host=gall-mite]
 9355 [host=field-cricket]
 9363 [host=gall-mite]
 9471 [host=bush-cricket]
 9615 [host=field-cricket]
 9649 [host=field-cricket]
 9625 [host=earwig]
 9661 [host=earwig]
 9650 [host=field-cricket]
 9593 [host=gall-mite]
 9637 [host=gall-mite]
 9651 [host=gall-mite]
 9638 [host=field-cricket]
 9662 [host=gall-mite]
 9639 [host=moss-bug]
 9601 [host=field-cricket]
 9640 [host=gall-mite]
 9608 [host=potato-beetle]
 9611 [host=earwig]
 9652 [host=moss-bug]
 9642 [host=field-cricket]
 9644 [host=earwig]
 9655 [host=earwig]
 9645 [host=field-cricket]
 9646 [host=gall-mite]
 9656 [host=gall-mite]
 9647 [host=field-cricket]
 9648 [host=gall-mite]
 9663 [host=earwig]
 9659 [host=field-cricket]
 9741 [host=field-cricket]
 9742 [host=moss-bug]
 9743 [host=potato-beetle]
 9745 [host=field-cricket]
 9746 [host=itch-mite]
 9747 !! flight 9747 missing revision for qemuu
 9748 [host=field-cricket]
 9749 [host=itch-mite]
 9764 [host=itch-mite]
 9752 [host=potato-beetle]
 9753 [host=itch-mite]
 9765 [host=itch-mite]
 9766 [host=itch-mite]
 9789 [host=field-cricket]
 9767 [host=gall-mite]
 9802 [host=potato-beetle]
 9799 [host=itch-mite]
 9803 [host=gall-mite]
 9800 [host=itch-mite]
 9817 [host=field-cricket]
 9806 [host=itch-mite]
 9878 [host=potato-beetle]
 9864 []
 9832 [host=gall-mite]
 9868 [host=field-cricket]
 9855 [host=field-cricket]
 9857 [host=itch-mite]
 9860 [host=moss-bug]
 9901 [host=lace-bug]
 9872 !! flight 9872 missing revision for qemuu
 9884 [host=itch-mite]
 9893 [host=gall-mite]
 9906 [host=moss-bug]
 9915 [host=field-cricket]
 9924 !! flight 9924 missing revision for qemuu
 9931 [host=gall-mite]
 9936 [host=itch-mite]
 9941 [host=moss-bug]
 9946 [host=field-cricket]
 9951 !! flight 9951 missing revision for qemuu
 9955 [host=gall-mite]
 9956 [host=itch-mite]
 9958 [host=lace-bug]
 9959 []
 9978 []
 9962 []
 10022 [host=itch-mite]
 10013 []
 10016 []
 10008 []
 10017 []
 10018 []
 10019 []
 10020 []
 10023 [host=gall-mite]
 10032 [host=lace-bug]
 10045 !! flight 10045 missing revision for qemuu
 10051 [host=itch-mite]
 10082 [host=moss-bug]
 10083 [host=moss-bug]
 10084 [host=moss-bug]
 10085 [host=moss-bug]
 10056 [host=lace-bug]
 10098 [host=bush-cricket]
 10086 [host=moss-bug]
 10087 [host=moss-bug]
 10088 [host=moss-bug]
 10062 [host=bush-cricket]
 10089 [host=moss-bug]
 10090 [host=moss-bug]
 10069 [host=moss-bug]
 10073 [host=moss-bug]
 10074 [host=moss-bug]
 10091 [host=moss-bug]
 10075 [host=moss-bug]
 10076 [host=moss-bug]
 10093 [host=moss-bug]
 10077 [host=moss-bug]
 10078 [host=moss-bug]
 10094 [host=moss-bug]
 10079 [host=moss-bug]
 10080 [host=moss-bug]
 10095 [host=moss-bug]
 10081 [host=moss-bug]
 10096 [host=moss-bug]
 10092 [host=gall-mite]
 10097 [host=moss-bug]
 10105 [host=lace-bug]
 10117 [host=bush-cricket]
 10135 [host=lace-bug]
 10112 [host=potato-beetle]
 10129 [host=itch-mite]
 10132 [host=moss-bug]
 10145 [host=gall-mite]
 10138 !! flight 10138 missing revision for qemuu
 10157 [host=lace-bug]
 10231 [host=lace-bug]
 10244 []
 10168 [host=itch-mite]
 10195 [host=lace-bug]
 10201 [host=gall-mite]
 10202 [host=moss-bug]
 10176 !! flight 10176 missing revision for qemuu
 10182 [host=gall-mite]
 10183 [host=potato-beetle]
 10185 [host=field-cricket]
 10189 [host=gall-mite]
 10190 [host=bush-cricket]
 10191 [host=field-cricket]
 10192 [host=potato-beetle]
 10214 !! flight 10214 missing revision for qemuu
 10257 [host=field-cricket]
 10239 [host=potato-beetle]
 10246 [host=bush-cricket]
 10264 []
 10313 []
 10289 []
 10332 []
 10294 []
 10298 []
 10347 []
 10300 []
 10317 []
 10305 []
 10322 []
 10325 []
 10344 []
 10360 [host=field-cricket]
 10353 [host=field-cricket]
 10371 [host=field-cricket]
 10390 [host=potato-beetle]
 10393 [host=moss-bug]
 10397 [host=field-cricket]
 10401 [host=bush-cricket]
 10473 [host=field-cricket]
 10474 [host=field-cricket]
 10466 [host=field-cricket]
 10475 [host=gall-mite]
 10491 [host=gall-mite]
 10454 [host=field-cricket]
 10468 !! flight 10468 missing revision for qemuu
 10470 [host=field-cricket]
 10486 [host=gall-mite]
 10471 [host=bush-cricket]
 10472 [host=field-cricket]
 10476 [host=field-cricket]
 10480 [host=bush-cricket]
 10481 [host=bush-cricket]
 10489 [host=bush-cricket]
 10492 [host=gall-mite]
 10490 [host=field-cricket]
 10493 [host=bush-cricket]
 10502 [host=gall-mite]
 10498 [host=field-cricket]
 10504 [host=bush-cricket]
 10511 [host=gall-mite]
 10515 [host=field-cricket]
 10534 [host=field-cricket]
 10563 [host=field-cricket]
 10603 [host=gall-mite]
 10517 [host=bush-cricket]
 10522 [host=bush-cricket]
 10564 [host=gall-mite]
 10524 [host=bush-cricket]
 10528 [host=field-cricket]
 10529 [host=gall-mite]
 10531 [host=field-cricket]
 10569 [host=bush-cricket]
 10545 [host=gall-mite]
 10554 [host=bush-cricket]
 10577 [host=field-cricket]
 10555 [host=field-cricket]
 10558 [host=gall-mite]
 10613 [host=field-cricket]
 10571 [host=field-cricket]
 10606 [host=lace-bug]
 10585 [host=gall-mite]
 10600 [host=potato-beetle]
 10610 [host=gall-mite]
 10596 [host=bush-cricket]
 10598 [host=field-cricket]
 10607 [host=field-cricket]
 10611 [host=gall-mite]
 10608 [host=gall-mite]
 10609 [host=gall-mite]
 10612 [host=bush-cricket]
 10620 [host=gall-mite]
 10618 [host=field-cricket]
 10614 [host=gall-mite]
 10619 [host=gall-mite]
 10621 [host=gall-mite]
 10622 [host=bush-cricket]
 10623 [host=field-cricket]
 10628 [host=potato-beetle]
 10629 [host=gall-mite]
 10630 [host=gall-mite]
 10631 [host=bush-cricket]
 10632 [host=gall-mite]
 10635 [host=field-cricket]
 10636 []
 10689 [host=gall-mite]
 10639 []
 10640 [host=field-cricket]
 10641 [host=bush-cricket]
 10642 [host=gall-mite]
 10643 [host=bush-cricket]
 10644 [host=gall-mite]
 10681 [host=field-cricket]
 10645 [host=bush-cricket]
 10646 [host=field-cricket]
 10649 [host=gall-mite]
 10680 [host=bush-cricket]
 10700 [host=potato-beetle]
 10716 [host=lace-bug]
 10722 [host=earwig]
 10736 [host=earwig]
 10731 [host=field-cricket]
 10739 [host=field-cricket]
 10738 [host=field-cricket]
 10737 [host=bush-cricket]
 10740 [host=bush-cricket]
 10741 [host=bush-cricket]
 10743 [host=bush-cricket]
 10742 [host=gall-mite]
 10771 [host=potato-beetle]
 10775 [host=itch-mite]
 10749 [host=itch-mite]
 10752 [host=earwig]
 10755 [host=field-cricket]
 10776 [host=field-cricket]
 10758 [host=field-cricket]
 10757 [host=lace-bug]
 10759 [host=field-cricket]
 10760 [host=lace-bug]
 10765 [host=lace-bug]
 10781 [host=moss-bug]
 10766 [host=lace-bug]
 10763 [host=itch-mite]
 10768 [host=lace-bug]
 10770 [host=itch-mite]
 10772 [host=itch-mite]
 10773 [host=itch-mite]
 10774 [host=itch-mite]
 10785 [host=lace-bug]
 10861 [host=gall-mite]
 10976 [host=field-cricket]
 10906 [host=field-cricket]
 10869 [host=gall-mite]
 10872 [host=gall-mite]
 10913 [host=itch-mite]
 10867 [host=earwig]
 10874 [host=gall-mite]
 10891 [host=bush-cricket]
 10875 !! flight 10875 missing revision for qemuu
 10882 [host=gall-mite]
 10898 [host=earwig]
 10885 [host=gall-mite]
 10886 [host=gall-mite]
 10884 [host=moss-bug]
 10887 [host=gall-mite]
 10888 [host=lace-bug]
 10915 [host=bush-cricket]
 10902 !! flight 10902 missing revision for qemuu
 10925 [host=itch-mite]
 10932 [host=lace-bug]
 11028 [host=gall-mite]
 11164 [host=moss-bug]
 11217 [host=field-cricket]
 11275 [host=gall-mite]
 11558 []
 11561 [host=gall-mite]
 11600 !! flight 11600 missing revision for qemuu
 11574 [host=bush-cricket]
 11601 !! flight 11601 missing revision for qemuu
 11603 []
 11582 [host=moss-bug]
 11643 !! flight 11643 missing revision for qemuu
 11584 [host=potato-beetle]
 11591 [host=earwig]
 11595 !! flight 11595 missing revision for qemuu
 11609 []
 11637 []
 11627 []
 11631 []
 11649 !! flight 11649 missing revision for qemuu
 11660 pass irrelevant
 11748 pass irrelevant
 11761 pass irrelevant
 11807 pass irrelevant
 11782 pass irrelevant
 11864 pass irrelevant
 11823 pass irrelevant
 11831 []
 11868 pass irrelevant
 11825 []
 11857 pass irrelevant
 11892 pass irrelevant
 11871 pass irrelevant
 11901 pass irrelevant
 11893 pass irrelevant
 11905 pass irrelevant
 11894 pass irrelevant
 11902 pass irrelevant
 11895 pass irrelevant
 11896 pass irrelevant
 11907 pass irrelevant
 11903 pass irrelevant
 11904 pass irrelevant
 11918 []
 11911 pass irrelevant
 11979 pass irrelevant
 12007 []
 11995 pass irrelevant
 11959 pass irrelevant
 11980 pass irrelevant
 11981 pass irrelevant
 11934 pass irrelevant
 11962 pass irrelevant
 11937 pass irrelevant
 11942 pass irrelevant
 11965 pass irrelevant
 11943 pass irrelevant
 11944 pass irrelevant
 11967 pass irrelevant
 11946 pass irrelevant
 11955 pass irrelevant
 11957 pass irrelevant
 11973 []
 11997 pass irrelevant
 11986 pass irrelevant
 11976 pass irrelevant
 11978 pass irrelevant
 11988 pass irrelevant
 12001 pass irrelevant
 11991 pass irrelevant
 12003 pass irrelevant
 12022 pass irrelevant
 12018 []
 12031 pass irrelevant
 12024 pass irrelevant
 12043 fail irrelevant
 12035 fail irrelevant
 12073 fail irrelevant
 12090 fail irrelevant
 12098 fail irrelevant
 12053 blocked irrelevant
 12079 fail irrelevant
 12100 pass irrelevant
 12120 pass irrelevant
 12102 fail irrelevant
 12099 pass irrelevant
 12062 fail irrelevant
 12085 fail irrelevant
 12089 pass irrelevant
 12135 pass irrelevant
 12132 pass irrelevant
 12091 fail irrelevant
 12104 pass irrelevant
 12093 fail irrelevant
 12094 pass irrelevant
 12095 pass irrelevant
 12096 fail irrelevant
 12106 pass irrelevant
 12097 pass irrelevant
 12115 []
 12127 pass irrelevant
 12130 pass irrelevant
 12144 pass irrelevant
 12156 pass irrelevant
 12213 pass irrelevant
 12170 pass irrelevant
 12173 pass irrelevant
 12217 pass irrelevant
 12195 pass irrelevant
 12177 pass irrelevant
 12201 []
 12180 pass irrelevant
 12231 pass irrelevant
 12183 pass irrelevant
 12204 pass irrelevant
 12185 pass irrelevant
 12220 pass irrelevant
 12244 pass irrelevant
 12188 pass irrelevant
 12206 pass irrelevant
 12235 pass irrelevant
 12210 pass irrelevant
 12247 pass irrelevant
 12225 pass irrelevant
 12228 pass irrelevant
 12248 pass irrelevant
 12230 pass irrelevant
 12249 pass irrelevant
 12237 pass irrelevant
 12250 []
 12252 []
 12278 pass irrelevant
 12351 pass irrelevant
 12352 pass irrelevant
 12353 []
 12414 pass irrelevant
 12399 pass irrelevant
 12401 pass irrelevant
 12377 pass irrelevant
 12385 []
 12437 pass irrelevant
 12389 pass irrelevant
 12392 pass irrelevant
 12407 pass irrelevant
 12394 pass irrelevant
 12423 pass irrelevant
 12431 pass irrelevant
 12451 []
 12445 []
 12461 pass irrelevant
 12456 pass irrelevant
 12481 pass irrelevant
 12476 pass irrelevant
 12519 pass irrelevant
 12542 pass irrelevant
 12529 pass irrelevant
 12493 pass irrelevant
 12552 pass irrelevant
 12504 pass irrelevant
 12545 pass irrelevant
 12534 pass irrelevant
 12548 pass irrelevant
 12559 pass irrelevant
 12579 pass irrelevant
 12563 pass irrelevant
 12587 pass irrelevant
 12635 pass irrelevant
 12650 pass irrelevant
 12668 pass irrelevant
 12702 pass irrelevant
 12639 pass irrelevant
 12658 pass irrelevant
 12693 pass irrelevant
 12671 fail irrelevant
 12698 pass irrelevant
 12685 pass irrelevant
 12695 pass irrelevant
 12701 pass irrelevant
 12709 pass irrelevant
 12712 pass irrelevant
 12716 pass irrelevant
 12721 pass irrelevant
 12723 pass irrelevant
 12727 pass irrelevant
 12748 pass irrelevant
 12728 pass irrelevant
 12729 pass irrelevant
 12753 pass irrelevant
 12732 []
 12754 pass irrelevant
 12755 pass irrelevant
 12786 pass irrelevant
 12733 pass irrelevant
 12756 pass irrelevant
 12738 pass irrelevant
 12740 pass irrelevant
 12758 pass irrelevant
 12743 pass irrelevant
 12760 pass irrelevant
 12788 pass irrelevant
 12745 pass irrelevant
 12761 pass irrelevant
 12797 pass irrelevant
 12763 pass irrelevant
 12789 pass irrelevant
 12790 pass irrelevant
 12791 pass irrelevant
 12800 pass irrelevant
 12792 pass irrelevant
 12782 pass irrelevant
 12793 pass irrelevant
 12806 pass irrelevant
 12823 pass irrelevant
 12827 pass irrelevant
 12828 []
 12834 pass irrelevant
 12860 pass irrelevant
 12889 pass irrelevant
 12849 pass irrelevant
 12852 pass irrelevant
 12854 pass irrelevant
 12856 pass irrelevant
 12857 pass irrelevant
 12893 pass irrelevant
 12858 pass irrelevant
 12859 pass irrelevant
 12876 fail irrelevant
 12884 pass irrelevant
 12887 pass irrelevant
 12923 pass irrelevant
 12907 pass irrelevant
 12915 pass irrelevant
 12910 pass irrelevant
 12912 pass irrelevant
 12934 pass irrelevant
 12920 pass irrelevant
 12921 pass irrelevant
 12925 pass irrelevant
 12939 pass irrelevant
 12945 pass irrelevant
 12947 pass irrelevant
 12951 pass irrelevant
 13019 pass irrelevant
 12956 pass irrelevant
 12958 pass irrelevant
 13004 pass irrelevant
 13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 12981 pass irrelevant
 12960 pass irrelevant
 12964 pass irrelevant
 13038 []
 12967 pass irrelevant
 12968 pass irrelevant
 12969 pass irrelevant
 12971 pass irrelevant
 12972 pass irrelevant
 12975 pass irrelevant
 12976 pass irrelevant
 12977 pass irrelevant
 12988 pass irrelevant
 12978 pass irrelevant
 13020 pass irrelevant
 12979 pass irrelevant
 12995 pass irrelevant
 12980 pass irrelevant
 12996 pass irrelevant
 13006 pass irrelevant
 12997 pass irrelevant
 12998 pass irrelevant
 13023 pass irrelevant
 13012 pass irrelevant
 13051 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 12999 pass irrelevant
 13013 pass irrelevant
 13002 pass irrelevant
 13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13003 pass irrelevant
 13014 pass irrelevant
 13045 []
 13015 pass irrelevant
 13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13016 pass irrelevant
 13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13018 pass irrelevant
 13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13046 []
 13037 []
 13053 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13061 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13069 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13073 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13074 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13077 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
 13078 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
 13075 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13079 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13081 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13082 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13083 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13084 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
Searching for interesting versions
 Result found: flight 13024 (pass), for basis pass
 Result found: flight 13051 (fail), for basis failure
 Repro found: flight 13073 (pass), for basis pass
 Repro found: flight 13074 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
No revisions left to test, checking graph state.
 Result found: flight 13024 (pass), for last pass
 Result found: flight 13079 (fail), for first failure
 Repro found: flight 13081 (pass), for last pass
 Repro found: flight 13082 (fail), for first failure
 Repro found: flight 13083 (pass), for last pass
 Repro found: flight 13084 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.{dot,ps,png,html}.
----------------------------------------
13084: tolerable ALL FAIL

flight 13084 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13084/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-i386-i386-xl-win         7 windows-install         fail baseline untested


jobs:
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Jun 18 14:38:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgd5e-0004Gn-Je; Mon, 18 Jun 2012 14:38: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 1Sgd5c-0004Gi-G6
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 14:38:01 +0000
Received: from [85.158.139.83:29587] by server-1.bemta-5.messagelabs.com id
	1A/BC-19721-74D3FDF4; Mon, 18 Jun 2012 14:37:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340030278!20900529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5854 invoked from network); 18 Jun 2012 14:37:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:37:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,792,1330905600"; d="scan'208";a="13082425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 14:37:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 15:37:58 +0100
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 1Sgd5Z-0005Xz-TY;
	Mon, 18 Jun 2012 14:37:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sgd5Z-0008MM-DL;
	Mon, 18 Jun 2012 15:37:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Sgd5Z-0008MM-DL@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 15:37:57 +0100
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-i386-i386-xl-win
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-i386-i386-xl-win
test windows-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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6


  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13075 fail [host=leaf-beetle] / 13025 ok.
Failure / basis pass flights: 13075 / 13025
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-6d8b472233779c2a028a03843603030d2b1aee86 http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-9dffb1864f2c
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 17 nodes in revision graph
Searching for test results:
 7623 [host=gall-mite]
 8249 [host=earwig]
 8289 [host=potato-beetle]
 7624 [host=itch-mite]
 8674 [host=earwig]
 8175 [host=gall-mite]
 7628 [host=earwig]
 7791 [host=earwig]
 7629 [host=itch-mite]
 8100 [host=potato-beetle]
 8024 [host=earwig]
 7544 []
 7630 [host=earwig]
 8026 [host=earwig]
 7874 [host=gall-mite]
 8292 []
 7633 [host=earwig]
 8256 [host=potato-beetle]
 7634 [host=earwig]
 8029 [host=earwig]
 8295 [host=itch-mite]
 8423 [host=earwig]
 7798 [host=gall-mite]
 8108 [host=gall-mite]
 8363 [host=potato-beetle]
 8427 [host=itch-mite]
 8034 [host=earwig]
 7554 [host=earwig]
 7882 [host=earwig]
 7556 [host=potato-beetle]
 8302 !! flight 8302 missing revision for qemuu
 7726 [host=gall-mite]
 8191 [host=itch-mite]
 8369 !! flight 8369 missing revision for qemuu
 7728 [host=earwig]
 7807 [host=gall-mite]
 8305 []
 7889 [host=gall-mite]
 7563 [host=gall-mite]
 7733 [host=gall-mite]
 7815 [host=earwig]
 8046 [host=earwig]
 8308 [host=potato-beetle]
 7896 [host=earwig]
 8374 [host=itch-mite]
 7738 [host=gall-mite]
 8201 !! flight 8201 missing revision for qemuu
 8127 [host=itch-mite]
 8312 [host=itch-mite]
 7742 [host=gall-mite]
 7978 [host=itch-mite]
 8054 [host=gall-mite]
 7577 [host=itch-mite]
 7663 [host=potato-beetle]
 7904 [host=gall-mite]
 7980 [host=earwig]
 8316 [host=earwig]
 8057 [host=itch-mite]
 8209 [host=earwig]
 7748 [host=itch-mite]
 7749 [host=earwig]
 7830 [host=earwig]
 8061 [host=earwig]
 8137 [host=gall-mite]
 7751 []
 8387 [host=earwig]
 8643 [host=gall-mite]
 7753 [host=itch-mite]
 8217 [host=earwig]
 8325 [host=earwig]
 7836 [host=gall-mite]
 5145 [host=gall-mite]
 5159 [host=earwig]
 5161 [host=gall-mite]
 7590 [host=itch-mite]
 7676 []
 5180 [host=gall-mite]
 8142 [host=itch-mite]
 8326 [host=potato-beetle]
 5237 [host=earwig]
 5238 [host=gall-mite]
 5231 [host=gall-mite]
 8067 !! flight 8067 missing revision for qemuu
 5233 [host=gall-mite]
 5240 [host=earwig]
 8327 !! flight 8327 missing revision for qemuu
 5352 [host=gall-mite]
 8328 [host=gall-mite]
 5469 [host=gall-mite]
 5363 [host=gall-mite]
 5435 []
 5508 [host=earwig]
 5482 [host=earwig]
 5500 [host=earwig]
 5501 [host=gall-mite]
 5502 [host=itch-mite]
 5503 [host=earwig]
 7760 [host=gall-mite]
 5506 [host=earwig]
 7680 [host=earwig]
 5538 [host=earwig]
 5566 [host=earwig]
 5568 [host=gall-mite]
 8071 [host=itch-mite]
 5588 [host=earwig]
 5644 []
 5590 [host=gall-mite]
 5593 [host=earwig]
 5620 [host=gall-mite]
 5650 []
 5654 []
 5640 [host=gall-mite]
 5641 [host=gall-mite]
 5655 []
 5656 []
 8147 [host=potato-beetle]
 5657 []
 5658 []
 5659 []
 8223 [host=gall-mite]
 5660 []
 5661 []
 5689 [host=gall-mite]
 5663 []
 5664 []
 5665 []
 5666 []
 8394 [host=potato-beetle]
 5696 [host=gall-mite]
 5673 [host=itch-mite]
 5697 [host=gall-mite]
 5677 [host=itch-mite]
 5680 [host=gall-mite]
 5685 [host=earwig]
 5692 [host=gall-mite]
 5700 [host=earwig]
 5740 [host=itch-mite]
 5741 [host=gall-mite]
 5743 [host=earwig]
 5748 [host=earwig]
 5749 [host=earwig]
 5750 [host=itch-mite]
 5751 [host=gall-mite]
 5752 [host=earwig]
 5781 []
 5772 [host=gall-mite]
 5753 [host=earwig]
 5754 [host=itch-mite]
 5755 [host=gall-mite]
 5756 [host=earwig]
 5757 [host=itch-mite]
 5823 [host=earwig]
 5758 [host=itch-mite]
 5760 [host=gall-mite]
 5762 [host=itch-mite]
 5764 [host=itch-mite]
 5766 [host=itch-mite]
 5775 [host=earwig]
 5787 [host=earwig]
 5806 [host=itch-mite]
 5825 [host=earwig]
 5830 [host=gall-mite]
 5833 [host=earwig]
 5855 [host=gall-mite]
 5862 [host=earwig]
 7914 [host=gall-mite]
 5870 [host=gall-mite]
 6156 [host=earwig]
 6282 [host=potato-beetle]
 6272 [host=gall-mite]
 6207 !! flight 6207 missing revision for qemuu
 6244 [host=earwig]
 6246 [host=gall-mite]
 6261 [host=potato-beetle]
 6266 [host=gall-mite]
 6280 [host=gall-mite]
 6291 [host=earwig]
 6288 [host=gall-mite]
 6289 [host=earwig]
 6295 [host=potato-beetle]
 6296 [host=gall-mite]
 6297 [host=gall-mite]
 6299 [host=gall-mite]
 6301 [host=earwig]
 6305 !! flight 6305 missing revision for qemuu
 6363 [host=gall-mite]
 6307 [host=gall-mite]
 6340 [host=earwig]
 6310 [host=earwig]
 6316 [host=gall-mite]
 6319 [host=gall-mite]
 6323 [host=earwig]
 6367 [host=earwig]
 6325 [host=earwig]
 6327 [host=earwig]
 6345 [host=gall-mite]
 6331 [host=earwig]
 6334 !! flight 6334 missing revision for qemuu
 6382 [host=earwig]
 6336 [host=gall-mite]
 6374 [host=gall-mite]
 6369 [host=gall-mite]
 6354 [host=potato-beetle]
 6396 [host=gall-mite]
 6413 [host=gall-mite]
 6441 [host=earwig]
 6597 [host=potato-beetle]
 6608 [host=gall-mite]
 6564 [host=earwig]
 6599 [host=earwig]
 6612 [host=itch-mite]
 6590 [host=potato-beetle]
 6602 [host=earwig]
 6605 [host=earwig]
 6617 [host=potato-beetle]
 6621 [host=itch-mite]
 7846 [host=earwig]
 7922 [host=gall-mite]
 6624 [host=gall-mite]
 6628 [host=gall-mite]
 7766 [host=earwig]
 6636 [host=itch-mite]
 6640 [host=earwig]
 6647 [host=itch-mite]
 6651 [host=gall-mite]
 6652 [host=earwig]
 6658 [host=itch-mite]
 6663 [host=gall-mite]
 6667 []
 6724 [host=gall-mite]
 6688 []
 6690 []
 6692 [host=gall-mite]
 6708 []
 6726 [host=itch-mite]
 6711 []
 6712 []
 6733 [host=earwig]
 6713 []
 6714 []
 6734 [host=itch-mite]
 6715 []
 6716 []
 6717 []
 6736 [host=gall-mite]
 6718 []
 6719 []
 6720 []
 8000 [host=earwig]
 6737 [host=itch-mite]
 6740 [host=gall-mite]
 8652 [host=potato-beetle]
 6743 [host=itch-mite]
 6746 [host=gall-mite]
 6747 [host=gall-mite]
 6748 [host=itch-mite]
 6749 [host=earwig]
 6751 [host=gall-mite]
 6752 [host=itch-mite]
 6753 [host=earwig]
 6756 [host=potato-beetle]
 6757 [host=gall-mite]
 6758 [host=earwig]
 6769 [host=itch-mite]
 6770 [host=gall-mite]
 6776 [host=itch-mite]
 6777 [host=itch-mite]
 6784 [host=earwig]
 6789 [host=earwig]
 6795 [host=earwig]
 6808 [host=earwig]
 6809 [host=gall-mite]
 6812 [host=itch-mite]
 6813 [host=earwig]
 8078 !! flight 8078 missing revision for qemuu
 6814 [host=gall-mite]
 6818 !! flight 6818 missing revision for qemuu
 6819 [host=earwig]
 6820 [host=earwig]
 8230 [host=potato-beetle]
 6822 [host=itch-mite]
 6825 !! flight 6825 missing revision for qemuu
 6827 [host=earwig]
 6829 [host=potato-beetle]
 6830 [host=earwig]
 6832 [host=gall-mite]
 6836 [host=itch-mite]
 6837 [host=earwig]
 6838 [host=itch-mite]
 6890 !! flight 6890 missing revision for qemuu
 6840 [host=gall-mite]
 6841 []
 6844 []
 6892 [host=itch-mite]
 6854 []
 6905 [host=potato-beetle]
 6894 [host=earwig]
 6863 []
 6895 [host=potato-beetle]
 6870 []
 6872 []
 6896 [host=gall-mite]
 6873 []
 6874 []
 6897 !! flight 6897 missing revision for qemuu
 6875 []
 6876 [host=earwig]
 6877 [host=gall-mite]
 6878 [host=earwig]
 6879 [host=itch-mite]
 6880 [host=gall-mite]
 6884 [host=earwig]
 6898 [host=potato-beetle]
 6899 [host=itch-mite]
 6903 [host=gall-mite]
 6904 [host=gall-mite]
 6914 [host=potato-beetle]
 6915 [host=earwig]
 6918 [host=potato-beetle]
 6922 [host=potato-beetle]
 6927 !! flight 6927 missing revision for qemuu
 8080 [host=itch-mite]
 6930 !! flight 6930 missing revision for qemuu
 6935 [host=gall-mite]
 6936 [host=itch-mite]
 6941 !! flight 6941 missing revision for qemuu
 6942 [host=potato-beetle]
 6943 [host=earwig]
 6944 !! flight 6944 missing revision for qemuu
 6945 !! flight 6945 missing revision for qemuu
 6946 [host=potato-beetle]
 6986 !! flight 6986 missing revision for qemuu
 7003 [host=itch-mite]
 6987 [host=potato-beetle]
 7607 [host=itch-mite]
 6988 [host=gall-mite]
 6992 [host=earwig]
 6993 !! flight 6993 missing revision for qemuu
 8401 [host=earwig]
 7693 [host=earwig]
 6994 [host=gall-mite]
 6996 [host=itch-mite]
 7772 [host=potato-beetle]
 6997 [host=earwig]
 6999 [host=potato-beetle]
 7000 [host=earwig]
 7038 [host=potato-beetle]
 7608 [host=earwig]
 7040 [host=earwig]
 7041 !! flight 7041 missing revision for qemuu
 7056 [host=earwig]
 8006 [host=itch-mite]
 8158 [host=potato-beetle]
 7077 [host=earwig]
 7080 [host=itch-mite]
 7083 !! flight 7083 missing revision for qemuu
 7084 [host=potato-beetle]
 7128 [host=earwig]
 7130 [host=itch-mite]
 7854 [host=gall-mite]
 7111 [host=gall-mite]
 7115 [host=itch-mite]
 7134 [host=itch-mite]
 7122 [host=gall-mite]
 7139 [host=earwig]
 7144 []
 7150 []
 8008 [host=itch-mite]
 7160 []
 8236 !! flight 8236 missing revision for qemuu
 7170 []
 7179 []
 7611 [host=gall-mite]
 7185 []
 7202 []
 7209 []
 7698 [host=earwig]
 7219 []
 7225 []
 7240 []
 8087 [host=gall-mite]
 7264 []
 7779 [host=earwig]
 7275 []
 8664 [host=itch-mite]
 8240 [host=gall-mite]
 7285 [host=gall-mite]
 8409 !! flight 8409 missing revision for qemuu
 7307 [host=itch-mite]
 7860 [host=earwig]
 8013 [host=earwig]
 7315 [host=itch-mite]
 7320 [host=itch-mite]
 7331 []
 7335 []
 7337 []
 7341 []
 7342 []
 7343 [host=gall-mite]
 7346 [host=earwig]
 7364 [host=earwig]
 7366 [host=itch-mite]
 7369 [host=earwig]
 7371 [host=gall-mite]
 7373 []
 7375 []
 7391 [host=earwig]
 7402 [host=earwig]
 8091 [host=itch-mite]
 7409 [host=gall-mite]
 7420 !! flight 7420 missing revision for qemuu
 8244 [host=itch-mite]
 7438 [host=earwig]
 7619 []
 7784 [host=gall-mite]
 7467 [host=gall-mite]
 7470 [host=earwig]
 7472 [host=gall-mite]
 7474 [host=earwig]
 7479 [host=earwig]
 7485 [host=gall-mite]
 7517 [host=itch-mite]
 7491 [host=earwig]
 7865 [host=gall-mite]
 8018 [host=earwig]
 7499 [host=earwig]
 7510 [host=earwig]
 7621 [host=itch-mite]
 8712 [host=field-cricket]
 8722 [host=moss-bug]
 8713 [host=field-cricket]
 8687 [host=itch-mite]
 8735 [host=itch-mite]
 8723 [host=gall-mite]
 8696 [host=potato-beetle]
 8715 [host=field-cricket]
 8707 [host=field-cricket]
 8724 [host=itch-mite]
 8710 [host=gall-mite]
 8717 [host=itch-mite]
 8711 !! flight 8711 missing revision for qemuu
 8718 [host=lace-bug]
 8725 [host=lace-bug]
 8721 !! flight 8721 missing revision for qemuu
 8729 [host=itch-mite]
 8726 [host=potato-beetle]
 8727 [host=field-cricket]
 8731 [host=gall-mite]
 8739 [host=itch-mite]
 8781 []
 8760 !! flight 8760 missing revision for qemuu
 8822 [host=gall-mite]
 8803 []
 8833 [host=gall-mite]
 8769 [host=gall-mite]
 8823 [host=field-cricket]
 8791 []
 8776 []
 8810 []
 8825 [host=itch-mite]
 8826 [host=itch-mite]
 8814 [host=itch-mite]
 8828 [host=itch-mite]
 8836 []
 8817 !! flight 8817 missing revision for qemuu
 8829 [host=itch-mite]
 8830 [host=field-cricket]
 8831 [host=itch-mite]
 8832 [host=field-cricket]
 8846 []
 8854 [host=itch-mite]
 8857 [host=field-cricket]
 8862 [host=field-cricket]
 8859 [host=lace-bug]
 8865 []
 8869 []
 8870 []
 8871 []
 8872 []
 8873 []
 8876 []
 8948 []
 8937 []
 8903 []
 8923 []
 8884 []
 8895 []
 8940 []
 8942 []
 8933 []
 8951 []
 8935 []
 8945 []
 8960 []
 8955 []
 8975 []
 8986 []
 8990 []
 8991 []
 9075 [host=lace-bug]
 8995 [host=field-cricket]
 9065 [host=earwig]
 9000 [host=earwig]
 9043 [host=bush-cricket]
 9083 [host=field-cricket]
 9005 [host=field-cricket]
 9067 [host=itch-mite]
 9054 [host=itch-mite]
 9077 [host=potato-beetle]
 9059 !! flight 9059 missing revision for qemuu
 9069 !! flight 9069 missing revision for qemuu
 9061 [host=potato-beetle]
 9063 [host=lace-bug]
 9071 [host=lace-bug]
 9079 !! flight 9079 missing revision for qemuu
 9085 [host=lace-bug]
 9073 [host=potato-beetle]
 9098 []
 9081 [host=potato-beetle]
 9097 []
 9105 [host=potato-beetle]
 9109 [host=lace-bug]
 9110 [host=field-cricket]
 9113 [host=earwig]
 9115 [host=field-cricket]
 9118 [host=bush-cricket]
 9176 [host=potato-beetle]
 9119 [host=field-cricket]
 9204 [host=gall-mite]
 9191 [host=field-cricket]
 9121 [host=bush-cricket]
 9138 [host=gall-mite]
 9181 [host=gall-mite]
 9163 [host=earwig]
 9198 [host=field-cricket]
 9182 [host=gall-mite]
 9192 [host=gall-mite]
 9183 [host=bush-cricket]
 9160 [host=field-cricket]
 9193 [host=field-cricket]
 9169 [host=bush-cricket]
 9186 [host=field-cricket]
 9187 [host=gall-mite]
 9201 [host=bush-cricket]
 9195 [host=earwig]
 9188 [host=bush-cricket]
 9203 [host=earwig]
 9224 [host=bush-cricket]
 9207 [host=field-cricket]
 9234 [host=lace-bug]
 9235 [host=field-cricket]
 9236 [host=field-cricket]
 9237 [host=gall-mite]
 9238 [host=field-cricket]
 9242 [host=field-cricket]
 9239 [host=bush-cricket]
 9243 [host=field-cricket]
 9244 [host=earwig]
 9245 [host=gall-mite]
 9246 [host=field-cricket]
 9247 [host=earwig]
 9251 [host=bush-cricket]
 9252 [host=potato-beetle]
 9253 [host=earwig]
 9275 [host=bush-cricket]
 9292 [host=earwig]
 9339 [host=gall-mite]
 9341 [host=bush-cricket]
 9342 [host=field-cricket]
 9343 [host=bush-cricket]
 9344 [host=bush-cricket]
 9345 [host=earwig]
 9346 [host=potato-beetle]
 9347 [host=field-cricket]
 9348 [host=bush-cricket]
 9349 [host=field-cricket]
 9350 [host=bush-cricket]
 9351 [host=gall-mite]
 9355 [host=field-cricket]
 9363 [host=gall-mite]
 9471 [host=bush-cricket]
 9615 [host=field-cricket]
 9649 [host=field-cricket]
 9625 [host=earwig]
 9661 [host=earwig]
 9650 [host=field-cricket]
 9593 [host=gall-mite]
 9637 [host=gall-mite]
 9651 [host=gall-mite]
 9638 [host=field-cricket]
 9662 [host=gall-mite]
 9639 [host=moss-bug]
 9601 [host=field-cricket]
 9640 [host=gall-mite]
 9608 [host=potato-beetle]
 9611 [host=earwig]
 9652 [host=moss-bug]
 9642 [host=field-cricket]
 9644 [host=earwig]
 9655 [host=earwig]
 9645 [host=field-cricket]
 9646 [host=gall-mite]
 9656 [host=gall-mite]
 9647 [host=field-cricket]
 9648 [host=gall-mite]
 9663 [host=earwig]
 9659 [host=field-cricket]
 9741 [host=field-cricket]
 9742 [host=moss-bug]
 9743 [host=potato-beetle]
 9745 [host=field-cricket]
 9746 [host=itch-mite]
 9747 !! flight 9747 missing revision for qemuu
 9748 [host=field-cricket]
 9749 [host=itch-mite]
 9764 [host=itch-mite]
 9752 [host=potato-beetle]
 9753 [host=itch-mite]
 9765 [host=itch-mite]
 9766 [host=itch-mite]
 9789 [host=field-cricket]
 9767 [host=gall-mite]
 9802 [host=potato-beetle]
 9799 [host=itch-mite]
 9803 [host=gall-mite]
 9800 [host=itch-mite]
 9817 [host=field-cricket]
 9806 [host=itch-mite]
 9878 [host=potato-beetle]
 9864 []
 9832 [host=gall-mite]
 9868 [host=field-cricket]
 9855 [host=field-cricket]
 9857 [host=itch-mite]
 9860 [host=moss-bug]
 9901 [host=lace-bug]
 9872 !! flight 9872 missing revision for qemuu
 9884 [host=itch-mite]
 9893 [host=gall-mite]
 9906 [host=moss-bug]
 9915 [host=field-cricket]
 9924 !! flight 9924 missing revision for qemuu
 9931 [host=gall-mite]
 9936 [host=itch-mite]
 9941 [host=moss-bug]
 9946 [host=field-cricket]
 9951 !! flight 9951 missing revision for qemuu
 9955 [host=gall-mite]
 9956 [host=itch-mite]
 9958 [host=lace-bug]
 9959 []
 9978 []
 9962 []
 10022 [host=itch-mite]
 10013 []
 10016 []
 10008 []
 10017 []
 10018 []
 10019 []
 10020 []
 10023 [host=gall-mite]
 10032 [host=lace-bug]
 10045 !! flight 10045 missing revision for qemuu
 10051 [host=itch-mite]
 10082 [host=moss-bug]
 10083 [host=moss-bug]
 10084 [host=moss-bug]
 10085 [host=moss-bug]
 10056 [host=lace-bug]
 10098 [host=bush-cricket]
 10086 [host=moss-bug]
 10087 [host=moss-bug]
 10088 [host=moss-bug]
 10062 [host=bush-cricket]
 10089 [host=moss-bug]
 10090 [host=moss-bug]
 10069 [host=moss-bug]
 10073 [host=moss-bug]
 10074 [host=moss-bug]
 10091 [host=moss-bug]
 10075 [host=moss-bug]
 10076 [host=moss-bug]
 10093 [host=moss-bug]
 10077 [host=moss-bug]
 10078 [host=moss-bug]
 10094 [host=moss-bug]
 10079 [host=moss-bug]
 10080 [host=moss-bug]
 10095 [host=moss-bug]
 10081 [host=moss-bug]
 10096 [host=moss-bug]
 10092 [host=gall-mite]
 10097 [host=moss-bug]
 10105 [host=lace-bug]
 10117 [host=bush-cricket]
 10135 [host=lace-bug]
 10112 [host=potato-beetle]
 10129 [host=itch-mite]
 10132 [host=moss-bug]
 10145 [host=gall-mite]
 10138 !! flight 10138 missing revision for qemuu
 10157 [host=lace-bug]
 10231 [host=lace-bug]
 10244 []
 10168 [host=itch-mite]
 10195 [host=lace-bug]
 10201 [host=gall-mite]
 10202 [host=moss-bug]
 10176 !! flight 10176 missing revision for qemuu
 10182 [host=gall-mite]
 10183 [host=potato-beetle]
 10185 [host=field-cricket]
 10189 [host=gall-mite]
 10190 [host=bush-cricket]
 10191 [host=field-cricket]
 10192 [host=potato-beetle]
 10214 !! flight 10214 missing revision for qemuu
 10257 [host=field-cricket]
 10239 [host=potato-beetle]
 10246 [host=bush-cricket]
 10264 []
 10313 []
 10289 []
 10332 []
 10294 []
 10298 []
 10347 []
 10300 []
 10317 []
 10305 []
 10322 []
 10325 []
 10344 []
 10360 [host=field-cricket]
 10353 [host=field-cricket]
 10371 [host=field-cricket]
 10390 [host=potato-beetle]
 10393 [host=moss-bug]
 10397 [host=field-cricket]
 10401 [host=bush-cricket]
 10473 [host=field-cricket]
 10474 [host=field-cricket]
 10466 [host=field-cricket]
 10475 [host=gall-mite]
 10491 [host=gall-mite]
 10454 [host=field-cricket]
 10468 !! flight 10468 missing revision for qemuu
 10470 [host=field-cricket]
 10486 [host=gall-mite]
 10471 [host=bush-cricket]
 10472 [host=field-cricket]
 10476 [host=field-cricket]
 10480 [host=bush-cricket]
 10481 [host=bush-cricket]
 10489 [host=bush-cricket]
 10492 [host=gall-mite]
 10490 [host=field-cricket]
 10493 [host=bush-cricket]
 10502 [host=gall-mite]
 10498 [host=field-cricket]
 10504 [host=bush-cricket]
 10511 [host=gall-mite]
 10515 [host=field-cricket]
 10534 [host=field-cricket]
 10563 [host=field-cricket]
 10603 [host=gall-mite]
 10517 [host=bush-cricket]
 10522 [host=bush-cricket]
 10564 [host=gall-mite]
 10524 [host=bush-cricket]
 10528 [host=field-cricket]
 10529 [host=gall-mite]
 10531 [host=field-cricket]
 10569 [host=bush-cricket]
 10545 [host=gall-mite]
 10554 [host=bush-cricket]
 10577 [host=field-cricket]
 10555 [host=field-cricket]
 10558 [host=gall-mite]
 10613 [host=field-cricket]
 10571 [host=field-cricket]
 10606 [host=lace-bug]
 10585 [host=gall-mite]
 10600 [host=potato-beetle]
 10610 [host=gall-mite]
 10596 [host=bush-cricket]
 10598 [host=field-cricket]
 10607 [host=field-cricket]
 10611 [host=gall-mite]
 10608 [host=gall-mite]
 10609 [host=gall-mite]
 10612 [host=bush-cricket]
 10620 [host=gall-mite]
 10618 [host=field-cricket]
 10614 [host=gall-mite]
 10619 [host=gall-mite]
 10621 [host=gall-mite]
 10622 [host=bush-cricket]
 10623 [host=field-cricket]
 10628 [host=potato-beetle]
 10629 [host=gall-mite]
 10630 [host=gall-mite]
 10631 [host=bush-cricket]
 10632 [host=gall-mite]
 10635 [host=field-cricket]
 10636 []
 10689 [host=gall-mite]
 10639 []
 10640 [host=field-cricket]
 10641 [host=bush-cricket]
 10642 [host=gall-mite]
 10643 [host=bush-cricket]
 10644 [host=gall-mite]
 10681 [host=field-cricket]
 10645 [host=bush-cricket]
 10646 [host=field-cricket]
 10649 [host=gall-mite]
 10680 [host=bush-cricket]
 10700 [host=potato-beetle]
 10716 [host=lace-bug]
 10722 [host=earwig]
 10736 [host=earwig]
 10731 [host=field-cricket]
 10739 [host=field-cricket]
 10738 [host=field-cricket]
 10737 [host=bush-cricket]
 10740 [host=bush-cricket]
 10741 [host=bush-cricket]
 10743 [host=bush-cricket]
 10742 [host=gall-mite]
 10771 [host=potato-beetle]
 10775 [host=itch-mite]
 10749 [host=itch-mite]
 10752 [host=earwig]
 10755 [host=field-cricket]
 10776 [host=field-cricket]
 10758 [host=field-cricket]
 10757 [host=lace-bug]
 10759 [host=field-cricket]
 10760 [host=lace-bug]
 10765 [host=lace-bug]
 10781 [host=moss-bug]
 10766 [host=lace-bug]
 10763 [host=itch-mite]
 10768 [host=lace-bug]
 10770 [host=itch-mite]
 10772 [host=itch-mite]
 10773 [host=itch-mite]
 10774 [host=itch-mite]
 10785 [host=lace-bug]
 10861 [host=gall-mite]
 10976 [host=field-cricket]
 10906 [host=field-cricket]
 10869 [host=gall-mite]
 10872 [host=gall-mite]
 10913 [host=itch-mite]
 10867 [host=earwig]
 10874 [host=gall-mite]
 10891 [host=bush-cricket]
 10875 !! flight 10875 missing revision for qemuu
 10882 [host=gall-mite]
 10898 [host=earwig]
 10885 [host=gall-mite]
 10886 [host=gall-mite]
 10884 [host=moss-bug]
 10887 [host=gall-mite]
 10888 [host=lace-bug]
 10915 [host=bush-cricket]
 10902 !! flight 10902 missing revision for qemuu
 10925 [host=itch-mite]
 10932 [host=lace-bug]
 11028 [host=gall-mite]
 11164 [host=moss-bug]
 11217 [host=field-cricket]
 11275 [host=gall-mite]
 11558 []
 11561 [host=gall-mite]
 11600 !! flight 11600 missing revision for qemuu
 11574 [host=bush-cricket]
 11601 !! flight 11601 missing revision for qemuu
 11603 []
 11582 [host=moss-bug]
 11643 !! flight 11643 missing revision for qemuu
 11584 [host=potato-beetle]
 11591 [host=earwig]
 11595 !! flight 11595 missing revision for qemuu
 11609 []
 11637 []
 11627 []
 11631 []
 11649 !! flight 11649 missing revision for qemuu
 11660 pass irrelevant
 11748 pass irrelevant
 11761 pass irrelevant
 11807 pass irrelevant
 11782 pass irrelevant
 11864 pass irrelevant
 11823 pass irrelevant
 11831 []
 11868 pass irrelevant
 11825 []
 11857 pass irrelevant
 11892 pass irrelevant
 11871 pass irrelevant
 11901 pass irrelevant
 11893 pass irrelevant
 11905 pass irrelevant
 11894 pass irrelevant
 11902 pass irrelevant
 11895 pass irrelevant
 11896 pass irrelevant
 11907 pass irrelevant
 11903 pass irrelevant
 11904 pass irrelevant
 11918 []
 11911 pass irrelevant
 11979 pass irrelevant
 12007 []
 11995 pass irrelevant
 11959 pass irrelevant
 11980 pass irrelevant
 11981 pass irrelevant
 11934 pass irrelevant
 11962 pass irrelevant
 11937 pass irrelevant
 11942 pass irrelevant
 11965 pass irrelevant
 11943 pass irrelevant
 11944 pass irrelevant
 11967 pass irrelevant
 11946 pass irrelevant
 11955 pass irrelevant
 11957 pass irrelevant
 11973 []
 11997 pass irrelevant
 11986 pass irrelevant
 11976 pass irrelevant
 11978 pass irrelevant
 11988 pass irrelevant
 12001 pass irrelevant
 11991 pass irrelevant
 12003 pass irrelevant
 12022 pass irrelevant
 12018 []
 12031 pass irrelevant
 12024 pass irrelevant
 12043 fail irrelevant
 12035 fail irrelevant
 12073 fail irrelevant
 12090 fail irrelevant
 12098 fail irrelevant
 12053 blocked irrelevant
 12079 fail irrelevant
 12100 pass irrelevant
 12120 pass irrelevant
 12102 fail irrelevant
 12099 pass irrelevant
 12062 fail irrelevant
 12085 fail irrelevant
 12089 pass irrelevant
 12135 pass irrelevant
 12132 pass irrelevant
 12091 fail irrelevant
 12104 pass irrelevant
 12093 fail irrelevant
 12094 pass irrelevant
 12095 pass irrelevant
 12096 fail irrelevant
 12106 pass irrelevant
 12097 pass irrelevant
 12115 []
 12127 pass irrelevant
 12130 pass irrelevant
 12144 pass irrelevant
 12156 pass irrelevant
 12213 pass irrelevant
 12170 pass irrelevant
 12173 pass irrelevant
 12217 pass irrelevant
 12195 pass irrelevant
 12177 pass irrelevant
 12201 []
 12180 pass irrelevant
 12231 pass irrelevant
 12183 pass irrelevant
 12204 pass irrelevant
 12185 pass irrelevant
 12220 pass irrelevant
 12244 pass irrelevant
 12188 pass irrelevant
 12206 pass irrelevant
 12235 pass irrelevant
 12210 pass irrelevant
 12247 pass irrelevant
 12225 pass irrelevant
 12228 pass irrelevant
 12248 pass irrelevant
 12230 pass irrelevant
 12249 pass irrelevant
 12237 pass irrelevant
 12250 []
 12252 []
 12278 pass irrelevant
 12351 pass irrelevant
 12352 pass irrelevant
 12353 []
 12414 pass irrelevant
 12399 pass irrelevant
 12401 pass irrelevant
 12377 pass irrelevant
 12385 []
 12437 pass irrelevant
 12389 pass irrelevant
 12392 pass irrelevant
 12407 pass irrelevant
 12394 pass irrelevant
 12423 pass irrelevant
 12431 pass irrelevant
 12451 []
 12445 []
 12461 pass irrelevant
 12456 pass irrelevant
 12481 pass irrelevant
 12476 pass irrelevant
 12519 pass irrelevant
 12542 pass irrelevant
 12529 pass irrelevant
 12493 pass irrelevant
 12552 pass irrelevant
 12504 pass irrelevant
 12545 pass irrelevant
 12534 pass irrelevant
 12548 pass irrelevant
 12559 pass irrelevant
 12579 pass irrelevant
 12563 pass irrelevant
 12587 pass irrelevant
 12635 pass irrelevant
 12650 pass irrelevant
 12668 pass irrelevant
 12702 pass irrelevant
 12639 pass irrelevant
 12658 pass irrelevant
 12693 pass irrelevant
 12671 fail irrelevant
 12698 pass irrelevant
 12685 pass irrelevant
 12695 pass irrelevant
 12701 pass irrelevant
 12709 pass irrelevant
 12712 pass irrelevant
 12716 pass irrelevant
 12721 pass irrelevant
 12723 pass irrelevant
 12727 pass irrelevant
 12748 pass irrelevant
 12728 pass irrelevant
 12729 pass irrelevant
 12753 pass irrelevant
 12732 []
 12754 pass irrelevant
 12755 pass irrelevant
 12786 pass irrelevant
 12733 pass irrelevant
 12756 pass irrelevant
 12738 pass irrelevant
 12740 pass irrelevant
 12758 pass irrelevant
 12743 pass irrelevant
 12760 pass irrelevant
 12788 pass irrelevant
 12745 pass irrelevant
 12761 pass irrelevant
 12797 pass irrelevant
 12763 pass irrelevant
 12789 pass irrelevant
 12790 pass irrelevant
 12791 pass irrelevant
 12800 pass irrelevant
 12792 pass irrelevant
 12782 pass irrelevant
 12793 pass irrelevant
 12806 pass irrelevant
 12823 pass irrelevant
 12827 pass irrelevant
 12828 []
 12834 pass irrelevant
 12860 pass irrelevant
 12889 pass irrelevant
 12849 pass irrelevant
 12852 pass irrelevant
 12854 pass irrelevant
 12856 pass irrelevant
 12857 pass irrelevant
 12893 pass irrelevant
 12858 pass irrelevant
 12859 pass irrelevant
 12876 fail irrelevant
 12884 pass irrelevant
 12887 pass irrelevant
 12923 pass irrelevant
 12907 pass irrelevant
 12915 pass irrelevant
 12910 pass irrelevant
 12912 pass irrelevant
 12934 pass irrelevant
 12920 pass irrelevant
 12921 pass irrelevant
 12925 pass irrelevant
 12939 pass irrelevant
 12945 pass irrelevant
 12947 pass irrelevant
 12951 pass irrelevant
 13019 pass irrelevant
 12956 pass irrelevant
 12958 pass irrelevant
 13004 pass irrelevant
 13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 12981 pass irrelevant
 12960 pass irrelevant
 12964 pass irrelevant
 13038 []
 12967 pass irrelevant
 12968 pass irrelevant
 12969 pass irrelevant
 12971 pass irrelevant
 12972 pass irrelevant
 12975 pass irrelevant
 12976 pass irrelevant
 12977 pass irrelevant
 12988 pass irrelevant
 12978 pass irrelevant
 13020 pass irrelevant
 12979 pass irrelevant
 12995 pass irrelevant
 12980 pass irrelevant
 12996 pass irrelevant
 13006 pass irrelevant
 12997 pass irrelevant
 12998 pass irrelevant
 13023 pass irrelevant
 13012 pass irrelevant
 13051 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 12999 pass irrelevant
 13013 pass irrelevant
 13002 pass irrelevant
 13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13003 pass irrelevant
 13014 pass irrelevant
 13045 []
 13015 pass irrelevant
 13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13016 pass irrelevant
 13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13018 pass irrelevant
 13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13046 []
 13037 []
 13053 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13061 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13069 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13073 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13074 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13077 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
 13078 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
 13075 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9dffb1864f2c
 13079 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13081 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13082 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13083 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13084 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
Searching for interesting versions
 Result found: flight 13024 (pass), for basis pass
 Result found: flight 13051 (fail), for basis failure
 Repro found: flight 13073 (pass), for basis pass
 Repro found: flight 13074 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
No revisions left to test, checking graph state.
 Result found: flight 13024 (pass), for last pass
 Result found: flight 13079 (fail), for first failure
 Repro found: flight 13081 (pass), for last pass
 Repro found: flight 13082 (fail), for first failure
 Repro found: flight 13083 (pass), for last pass
 Repro found: flight 13084 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.{dot,ps,png,html}.
----------------------------------------
13084: tolerable ALL FAIL

flight 13084 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13084/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-i386-i386-xl-win         7 windows-install         fail baseline untested


jobs:
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Jun 18 14:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14: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 1SgdMr-0004bY-Fi; Mon, 18 Jun 2012 14:55: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 1SgdMq-0004bT-1v
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 14:55:48 +0000
Received: from [85.158.143.99:25773] by server-2.bemta-4.messagelabs.com id
	47/BA-17938-3714FDF4; Mon, 18 Jun 2012 14:55:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340031346!27883921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27441 invoked from network); 18 Jun 2012 14:55:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:55:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,792,1330905600"; d="scan'208";a="13082985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 14:55:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 15:55:46 +0100
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 1SgdMo-0005eL-E3;
	Mon, 18 Jun 2012 14:55:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgdMo-0006uS-DR;
	Mon, 18 Jun 2012 15:55:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13086-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 15:55:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13086: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13086 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13086/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13048
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13048

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-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-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  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  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9
baseline version:
 linux                26a7895e70104811258cf023d06a21f92ab590c6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 14:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 14: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 1SgdMr-0004bY-Fi; Mon, 18 Jun 2012 14:55: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 1SgdMq-0004bT-1v
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 14:55:48 +0000
Received: from [85.158.143.99:25773] by server-2.bemta-4.messagelabs.com id
	47/BA-17938-3714FDF4; Mon, 18 Jun 2012 14:55:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340031346!27883921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27441 invoked from network); 18 Jun 2012 14:55:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 14:55:46 -0000
X-IronPort-AV: E=Sophos;i="4.75,792,1330905600"; d="scan'208";a="13082985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 14:55:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 18 Jun 2012 15:55:46 +0100
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 1SgdMo-0005eL-E3;
	Mon, 18 Jun 2012 14:55:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SgdMo-0006uS-DR;
	Mon, 18 Jun 2012 15:55:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13086-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 15:55:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13086: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13086 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13086/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13048
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13048

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-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-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  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  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9
baseline version:
 linux                26a7895e70104811258cf023d06a21f92ab590c6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 15:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 15: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 1SgeHm-00058j-65; Mon, 18 Jun 2012 15:54:38 +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 1SgeHk-00058d-QD
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 15:54:37 +0000
Received: from [85.158.138.51:56405] by server-10.bemta-3.messagelabs.com id
	00/25-01753-B3F4FDF4; Mon, 18 Jun 2012 15:54:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340034874!9577567!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20170 invoked from network); 18 Jun 2012 15:54:34 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 15:54:34 -0000
Received: by eekd41 with SMTP id d41so1851137eek.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 08:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=w70WtiNF4wK6oTNAzeENa+qvFnS18chYEEZmJMFYhQ4=;
	b=xjoXfeFiPgKWANJXEKA4e8Gg7Lg5lDvqEfrsYWv8V96o2grrhduEUiu1o3FXRy4YGe
	Poej+osSFiK6tRn9zIh/8rzgr6VQpolvcKer+w65dE1Q+P3VGsTj4oCfBSlb2IKfXjSv
	J9TsBv4uZcyU3MgrrCxnIl1QdPETWLnGNHzIBjxVonEQtrN7hsaiF8jMn+ZshwPAy10K
	LLqo+2jEqNwmZmMWswfZ2VMEPtOvlMq0sl1y74UUQJujqJSSc0rXfU9FYteR+iTMYxsU
	yUE0FGa2lM/cRCQbWKPy4Azb0r/J/bXWNTJ0Q13zCL3FXZYXW/xJNvA/orksRrgtPopk
	6N2A==
Received: by 10.14.39.194 with SMTP id d42mr3513452eeb.68.1340034874143;
	Mon, 18 Jun 2012 08:54:34 -0700 (PDT)
Received: from [192.168.0.40] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id g46sm63152931eea.14.2012.06.18.08.54.31
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 08:54:32 -0700 (PDT)
Message-ID: <1340034865.4705.86.camel@Solace>
From: Dario Faggioli <raistlin.df@gmail.com>
To: xen-devel@lists.xen.org
Date: Mon, 18 Jun 2012 17:54:25 +0200
In-Reply-To: <0e566a40afad1e3dc299.1339779878@Solace>
References: <patchbomb.1339779868@Solace>
	<0e566a40afad1e3dc299.1339779878@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 19:04 +0200, Dario Faggioli wrote:
> +### Automatic Guest Placement with xl ###
> +
> +In case no "cpus=" option is specified in the config file, xl tries
> +to figure out on its own on which node(s) the domain could fit best.
> +
> +First of all, it needs to find a node (or a set of nodes) that have
> +enough free memory for accommodating the domain. After that, the actual
> +decision on where to put the new guest happens by generating all the
> +possible combinations of nodes that satisfies the above and chose among
> +them according to the following heuristics:
> +
> +  *  candidates involving fewer nodes come first. In case two (or more)
> +     candidates span the same number of nodes,
> +  *  candidates with greater amount of free memory come first. In case
> +     two (or more) candidates differ in their amount of free memory by
> +     less than 10%,
> +  *  candidates with fewer domains already placed on them come first.
> +
> +Giving preference to small candidates ensures better performance for
> +the guest, as it avoid spreading its memory among different nodes.
> +Using the nodes that have the biggest amounts of free memory helps
> +keeping the memory fragmentation small, from a system wide perspective.
> +Finally, in case more candidates fulfil these criteria by the same
> +extent, choosing the candidate that is hosting fewer domain helps
> +balancing the load on the various nodes.
> +

This part below is basically a leftover from previous version. Things
does not work like that any longer. Basically, what we do is looking for
all the nodes, or a sets of nodes, that have enough free memory and at
least as much pCPUs as the domain has vCPUs and then apply the
heuristics outlined above.
> +The last step is figuring out whether the selected candidate contains
> +at least as much CPUs as the number of VCPUs of the VM. The current
> +solution for the case when this is not verified is just to add some
> +more nodes, until the condition turns into being true. When doing
> +this, the nodes with the least possible distance from the ones
> +already in the nodemap are considered.
> +

Sorry, (already fixed in my local patchqueue)
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 Mon Jun 18 15:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 15: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 1SgeHm-00058j-65; Mon, 18 Jun 2012 15:54:38 +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 1SgeHk-00058d-QD
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 15:54:37 +0000
Received: from [85.158.138.51:56405] by server-10.bemta-3.messagelabs.com id
	00/25-01753-B3F4FDF4; Mon, 18 Jun 2012 15:54:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340034874!9577567!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20170 invoked from network); 18 Jun 2012 15:54:34 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 15:54:34 -0000
Received: by eekd41 with SMTP id d41so1851137eek.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 08:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=w70WtiNF4wK6oTNAzeENa+qvFnS18chYEEZmJMFYhQ4=;
	b=xjoXfeFiPgKWANJXEKA4e8Gg7Lg5lDvqEfrsYWv8V96o2grrhduEUiu1o3FXRy4YGe
	Poej+osSFiK6tRn9zIh/8rzgr6VQpolvcKer+w65dE1Q+P3VGsTj4oCfBSlb2IKfXjSv
	J9TsBv4uZcyU3MgrrCxnIl1QdPETWLnGNHzIBjxVonEQtrN7hsaiF8jMn+ZshwPAy10K
	LLqo+2jEqNwmZmMWswfZ2VMEPtOvlMq0sl1y74UUQJujqJSSc0rXfU9FYteR+iTMYxsU
	yUE0FGa2lM/cRCQbWKPy4Azb0r/J/bXWNTJ0Q13zCL3FXZYXW/xJNvA/orksRrgtPopk
	6N2A==
Received: by 10.14.39.194 with SMTP id d42mr3513452eeb.68.1340034874143;
	Mon, 18 Jun 2012 08:54:34 -0700 (PDT)
Received: from [192.168.0.40] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id g46sm63152931eea.14.2012.06.18.08.54.31
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 08:54:32 -0700 (PDT)
Message-ID: <1340034865.4705.86.camel@Solace>
From: Dario Faggioli <raistlin.df@gmail.com>
To: xen-devel@lists.xen.org
Date: Mon, 18 Jun 2012 17:54:25 +0200
In-Reply-To: <0e566a40afad1e3dc299.1339779878@Solace>
References: <patchbomb.1339779868@Solace>
	<0e566a40afad1e3dc299.1339779878@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 19:04 +0200, Dario Faggioli wrote:
> +### Automatic Guest Placement with xl ###
> +
> +In case no "cpus=" option is specified in the config file, xl tries
> +to figure out on its own on which node(s) the domain could fit best.
> +
> +First of all, it needs to find a node (or a set of nodes) that have
> +enough free memory for accommodating the domain. After that, the actual
> +decision on where to put the new guest happens by generating all the
> +possible combinations of nodes that satisfies the above and chose among
> +them according to the following heuristics:
> +
> +  *  candidates involving fewer nodes come first. In case two (or more)
> +     candidates span the same number of nodes,
> +  *  candidates with greater amount of free memory come first. In case
> +     two (or more) candidates differ in their amount of free memory by
> +     less than 10%,
> +  *  candidates with fewer domains already placed on them come first.
> +
> +Giving preference to small candidates ensures better performance for
> +the guest, as it avoid spreading its memory among different nodes.
> +Using the nodes that have the biggest amounts of free memory helps
> +keeping the memory fragmentation small, from a system wide perspective.
> +Finally, in case more candidates fulfil these criteria by the same
> +extent, choosing the candidate that is hosting fewer domain helps
> +balancing the load on the various nodes.
> +

This part below is basically a leftover from previous version. Things
does not work like that any longer. Basically, what we do is looking for
all the nodes, or a sets of nodes, that have enough free memory and at
least as much pCPUs as the domain has vCPUs and then apply the
heuristics outlined above.
> +The last step is figuring out whether the selected candidate contains
> +at least as much CPUs as the number of VCPUs of the VM. The current
> +solution for the case when this is not verified is just to add some
> +more nodes, until the condition turns into being true. When doing
> +this, the nodes with the least possible distance from the ones
> +already in the nodemap are considered.
> +

Sorry, (already fixed in my local patchqueue)
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 Mon Jun 18 16:08:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 16: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 1SgeUL-0005ly-FI; Mon, 18 Jun 2012 16:07:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sge99-00055v-PT
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 15:45:43 +0000
Received: from [85.158.143.99:50657] by server-1.bemta-4.messagelabs.com id
	38/A1-24392-72D4FDF4; Mon, 18 Jun 2012 15:45:43 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340034342!21529663!1
X-Originating-IP: [80.67.18.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMTguMTMgPT4gNDg3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15116 invoked from network); 18 Jun 2012 15:45:42 -0000
Received: from smtprelay01.ispgateway.de (HELO smtprelay01.ispgateway.de)
	(80.67.18.13) by server-10.tower-216.messagelabs.com with SMTP;
	18 Jun 2012 15:45:42 -0000
Received: from [80.67.16.114] (helo=webmailfront01.ispgateway.de)
	by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>)
	id 1Sge97-0004Er-U9; Mon, 18 Jun 2012 17:45:41 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Mon, 18 Jun 2012 17:45:41 +0200
Date: Mon, 18 Jun 2012 17:45:41 +0200
Message-ID: <20120618174541.Horde.5R_AWUlCcOxP300l24U1ByA@webmail.df.eu>
From: ml@consolo.de
To: Mukesh Rathor <mukesh.rathor@oracle.com>
References: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
	<20120615155844.GB20422@phenom.dumpdata.com>
	<20120615121456.3f0089ad@mantra.us.oracle.com>
In-Reply-To: <20120615121456.3f0089ad@mantra.us.oracle.com>
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Mon, 18 Jun 2012 16:07:36 +0000
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

thx a lot ..

cw

Zitat von Mukesh Rathor <mukesh.rathor@oracle.com>:

> On Fri, 15 Jun 2012 11:58:44 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
>> On Thu, Jun 14, 2012 at 03:11:48PM +0200, ml@consolo.de wrote:
>> >
>> > Hi,
>> >
>> > I am currently trying to get kdb working with the current 4.1 XEN
>> > release. I first tried to use debuggers.hg, but could not manage to
>> > compile it due tho many different errors.
>>
>> Did you email the author (Mukesh) of debuggers.hg to see if he can
>> help?
>>
>
> I just posted a patch for unstable c/s 25467 last week. Attached here
> again.
>
> thanks,
> Mukesh




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 16:08:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 16: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 1SgeUL-0005ly-FI; Mon, 18 Jun 2012 16:07:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml@consolo.de>) id 1Sge99-00055v-PT
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 15:45:43 +0000
Received: from [85.158.143.99:50657] by server-1.bemta-4.messagelabs.com id
	38/A1-24392-72D4FDF4; Mon, 18 Jun 2012 15:45:43 +0000
X-Env-Sender: ml@consolo.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340034342!21529663!1
X-Originating-IP: [80.67.18.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNjcuMTguMTMgPT4gNDg3NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15116 invoked from network); 18 Jun 2012 15:45:42 -0000
Received: from smtprelay01.ispgateway.de (HELO smtprelay01.ispgateway.de)
	(80.67.18.13) by server-10.tower-216.messagelabs.com with SMTP;
	18 Jun 2012 15:45:42 -0000
Received: from [80.67.16.114] (helo=webmailfront01.ispgateway.de)
	by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <ml@consolo.de>)
	id 1Sge97-0004Er-U9; Mon, 18 Jun 2012 17:45:41 +0200
Received: from syssec98.syssec.ruhr-uni-bochum.de
	(syssec98.syssec.ruhr-uni-bochum.de [134.147.202.98]) by webmail.df.eu
	(Horde Framework) with HTTP; Mon, 18 Jun 2012 17:45:41 +0200
Date: Mon, 18 Jun 2012 17:45:41 +0200
Message-ID: <20120618174541.Horde.5R_AWUlCcOxP300l24U1ByA@webmail.df.eu>
From: ml@consolo.de
To: Mukesh Rathor <mukesh.rathor@oracle.com>
References: <20120614151148.Horde.haVTPcL8999P2eMUDQK1xEA@webmail.df.eu>
	<20120615155844.GB20422@phenom.dumpdata.com>
	<20120615121456.3f0089ad@mantra.us.oracle.com>
In-Reply-To: <20120615121456.3f0089ad@mantra.us.oracle.com>
User-Agent: Internet Messaging Program (IMP) H4 (5.0.19)
MIME-Version: 1.0
Content-Disposition: inline
X-Df-Sender: bWxAY29uc29sby5kZQ==
X-Mailman-Approved-At: Mon, 18 Jun 2012 16:07:36 +0000
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] using kdb with current xen release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

thx a lot ..

cw

Zitat von Mukesh Rathor <mukesh.rathor@oracle.com>:

> On Fri, 15 Jun 2012 11:58:44 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
>> On Thu, Jun 14, 2012 at 03:11:48PM +0200, ml@consolo.de wrote:
>> >
>> > Hi,
>> >
>> > I am currently trying to get kdb working with the current 4.1 XEN
>> > release. I first tried to use debuggers.hg, but could not manage to
>> > compile it due tho many different errors.
>>
>> Did you email the author (Mukesh) of debuggers.hg to see if he can
>> help?
>>
>
> I just posted a patch for unstable c/s 25467 last week. Attached here
> again.
>
> thanks,
> Mukesh




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 16:50:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 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 1Sgf9F-0006M7-LA; Mon, 18 Jun 2012 16:49: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 1Sgf9D-0006M0-LJ
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 16:49:51 +0000
Received: from [193.109.254.147:38194] by server-5.bemta-14.messagelabs.com id
	0A/12-04343-E2C5FDF4; Mon, 18 Jun 2012 16:49:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340038190!4417626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7645 invoked from network); 18 Jun 2012 16:49:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 16:49:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="13085758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 16: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.213.0; Mon, 18 Jun 2012 17:49:50 +0100
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 1Sgf9C-0006Kf-0c;
	Mon, 18 Jun 2012 16: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 1Sgf9B-00020V-Q6;
	Mon, 18 Jun 2012 17:49:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13080-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 17:49:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13080: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13080 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13080/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 16:50:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 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 1Sgf9F-0006M7-LA; Mon, 18 Jun 2012 16:49: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 1Sgf9D-0006M0-LJ
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 16:49:51 +0000
Received: from [193.109.254.147:38194] by server-5.bemta-14.messagelabs.com id
	0A/12-04343-E2C5FDF4; Mon, 18 Jun 2012 16:49:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340038190!4417626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEwNTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7645 invoked from network); 18 Jun 2012 16:49:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 16:49:50 -0000
X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="13085758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jun 2012 16: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.213.0; Mon, 18 Jun 2012 17:49:50 +0100
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 1Sgf9C-0006Kf-0c;
	Mon, 18 Jun 2012 16: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 1Sgf9B-00020V-Q6;
	Mon, 18 Jun 2012 17:49:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13080-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Jun 2012 17:49:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13080: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13080 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13080/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9dffb1864f2c
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 18:32:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 18:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SggkY-0007Vo-FP; Mon, 18 Jun 2012 18:32: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 1SggkX-0007Vj-2D
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 18:32:29 +0000
Received: from [85.158.139.83:52105] by server-4.bemta-5.messagelabs.com id
	D3/6C-27831-C347FDF4; Mon, 18 Jun 2012 18:32:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340044346!21051664!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5NTkwMw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1474 invoked from network); 18 Jun 2012 18:32:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 18:32:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5IIWNCv023026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 18 Jun 2012 18:32:24 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
	q5IIWN62012415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2012 18:32:23 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
	q5IIWMSl020346; Mon, 18 Jun 2012 13:32:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 18 Jun 2012 11:32:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 146FE402A4; Mon, 18 Jun 2012 14:24:51 -0400 (EDT)
Date: Mon, 18 Jun 2012 14:24:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120618182450.GF24750@phenom.dumpdata.com>
References: <4FDB790F020000780008A406@nat28.tlf.novell.com>
	<CC012A16.43075%keir@xen.org>
	<4FDEF595020000780008A5B7@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FDEF595020000780008A5B7@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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 Mon, Jun 18, 2012 at 08:32:05AM +0100, Jan Beulich wrote:
> >>> On 15.06.12 at 19:06, Keir Fraser <keir@xen.org> wrote:
> > On 15/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> > 
> >> While pv-ops so far doesn't care to eliminate the two trap-and-
> >> emulate CR0 accesses from the asm/xor.h save/restore
> >> operations, the legacy x86-64 kernel uses conditional clts()/stts()
> >> for this purpose. While looking into whether to extend this to the
> >> newly added (in 3.5) AVX operations there I realized that this isn't
> >> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
> >> kernel_fpu_end() pair (as it will stts() at the end no matter what
> >> the original state of CR0.TS was).

That sounds like a bug in the generic code then?
> >> 
> >> In order to not introduce completely new hypercalls to overcome
> >> this (fpu_taskswitch isn't really extensible on its own), I'm
> >> considering to add a new VM assist, altering the fpu_taskswitch
> >> behavior so that it would return an indicator whether any change
> >> to the virtual CR0.TS was done. That way, the kernel can
> >> implement a true save/restore cycle here.

How would that work with the multi-calls? Right now clts is batched
and so is cr0 write.
> > 
> > It should be possible for the guest kernel to track its CR0.TS setting
> > shouldn't it? It gets modified only via a few paravirt hooks, and implicitly

Hm, the clts() paravirt could take advantage of the per-cpu cr0 to
figure out whether it truly needs to do anything.

> > cleared on #NM.
> Sure, but selling this to the Linux maintainers I would expect to be
> harder than fitting the Xen side of things into the current save-
> and-restore model the native xor code uses. It would only be strait
> forward to implement on the legacy, forward ported trees.
> 
> However, with the #NM handler in pv-ops apparently not
> leveraging the fact that CR0.TS is already cleared for it on entry,
> maybe this could indeed be introduced together. Konrad?

Would this require an extra pvops call from the #NM handler?

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 18:32:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 18:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SggkY-0007Vo-FP; Mon, 18 Jun 2012 18:32: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 1SggkX-0007Vj-2D
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 18:32:29 +0000
Received: from [85.158.139.83:52105] by server-4.bemta-5.messagelabs.com id
	D3/6C-27831-C347FDF4; Mon, 18 Jun 2012 18:32:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340044346!21051664!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5NTkwMw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1474 invoked from network); 18 Jun 2012 18:32:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 18:32:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5IIWNCv023026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 18 Jun 2012 18:32:24 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
	q5IIWN62012415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2012 18:32:23 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
	q5IIWMSl020346; Mon, 18 Jun 2012 13:32:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 18 Jun 2012 11:32:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 146FE402A4; Mon, 18 Jun 2012 14:24:51 -0400 (EDT)
Date: Mon, 18 Jun 2012 14:24:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120618182450.GF24750@phenom.dumpdata.com>
References: <4FDB790F020000780008A406@nat28.tlf.novell.com>
	<CC012A16.43075%keir@xen.org>
	<4FDEF595020000780008A5B7@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FDEF595020000780008A5B7@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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 Mon, Jun 18, 2012 at 08:32:05AM +0100, Jan Beulich wrote:
> >>> On 15.06.12 at 19:06, Keir Fraser <keir@xen.org> wrote:
> > On 15/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> > 
> >> While pv-ops so far doesn't care to eliminate the two trap-and-
> >> emulate CR0 accesses from the asm/xor.h save/restore
> >> operations, the legacy x86-64 kernel uses conditional clts()/stts()
> >> for this purpose. While looking into whether to extend this to the
> >> newly added (in 3.5) AVX operations there I realized that this isn't
> >> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
> >> kernel_fpu_end() pair (as it will stts() at the end no matter what
> >> the original state of CR0.TS was).

That sounds like a bug in the generic code then?
> >> 
> >> In order to not introduce completely new hypercalls to overcome
> >> this (fpu_taskswitch isn't really extensible on its own), I'm
> >> considering to add a new VM assist, altering the fpu_taskswitch
> >> behavior so that it would return an indicator whether any change
> >> to the virtual CR0.TS was done. That way, the kernel can
> >> implement a true save/restore cycle here.

How would that work with the multi-calls? Right now clts is batched
and so is cr0 write.
> > 
> > It should be possible for the guest kernel to track its CR0.TS setting
> > shouldn't it? It gets modified only via a few paravirt hooks, and implicitly

Hm, the clts() paravirt could take advantage of the per-cpu cr0 to
figure out whether it truly needs to do anything.

> > cleared on #NM.
> Sure, but selling this to the Linux maintainers I would expect to be
> harder than fitting the Xen side of things into the current save-
> and-restore model the native xor code uses. It would only be strait
> forward to implement on the legacy, forward ported trees.
> 
> However, with the #NM handler in pv-ops apparently not
> leveraging the fact that CR0.TS is already cleared for it on entry,
> maybe this could indeed be introduced together. Konrad?

Would this require an extra pvops call from the #NM handler?

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 18:44:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 18:44: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 1SggvL-0007pO-Uu; Mon, 18 Jun 2012 18:43:39 +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 1SggvL-0007pJ-Ew
	for Xen-devel@lists.xensource.com; Mon, 18 Jun 2012 18:43:39 +0000
Received: from [85.158.143.35:38951] by server-1.bemta-4.messagelabs.com id
	45/64-24392-AD67FDF4; Mon, 18 Jun 2012 18:43:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340045016!5423379!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTkxMzg5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6731 invoked from network); 18 Jun 2012 18:43:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jun 2012 18:43:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5IIhUAF004140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 18 Jun 2012 18:43: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
	q5IIhTQM014967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2012 18:43:29 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
	q5IIhTQp007403; Mon, 18 Jun 2012 13:43:29 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 18 Jun 2012 11:43:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 91E16402A4; Mon, 18 Jun 2012 14:35:57 -0400 (EDT)
Date: Mon, 18 Jun 2012 14:35:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120618183557.GA28050@phenom.dumpdata.com>
References: <20120614184338.43fb879b@mantra.us.oracle.com>
	<alpine.DEB.2.02.1206151201150.14957@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206151201150.14957@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>
Subject: Re: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 15, 2012 at 12:02:19PM +0100, Stefano Stabellini wrote:
> On Fri, 15 Jun 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > During my refresh to latest linux, I noticed, direct mapping of all
> > non-RAM pages in xen_set_identity_and_release(). I currently don't map
> > all at front, but as needed looking at the PAGE_IO bit in the pte. One

PV doesn't look at that all the time either. The P2M tree code
has a couple of leafs, that if they have IDENTITY_FRAME_BIT set it will
automatically stick _PAGE_IOMAP on the PTE.

> > result of that is minor change to common code macro:
> > 
> >         __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
> > to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)

I am really wafling on that. Jeremy posted a patch some time ago
to x86 folks that would do something similar (I can't remember the
details), but hpa said - why don't you just consult the E820.

That is where the IDENTITY_FRAME_BIT thing in the P2M tree came
about. It could probably be implemented for your cases using ranges.

Similary to how Xen permits/disallows certain IO regions to be touched.
Would something like that potentially allow you do something like this:

xen_hybrid_pte()

phys_addr_t phys = pte.pte & PTE_PFN_MASK

if (phys .. within ranges)
	pte |= _PAGE_IOMAP;
return pte;

> >
> > 
> > To avoid this change, and keep all my changes limited to xen files only,
> > I thought I could just map the entire non-ram pages up front too. But
> > I am concerned the EPT may grow too large? Specially, when we get to 
> > *really* large NUMA boxes. What do you guys think? Should I worry about
> > it?

Would NUMA boxes have more than 1GB of E820 non-RAM regions? I can see them
having gobs of RAM regions, but non-RAM regions?

> 
> I would map them all up front and worry about it later.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 18 18:44:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 18:44: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 1SggvL-0007pO-Uu; Mon, 18 Jun 2012 18:43:39 +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 1SggvL-0007pJ-Ew
	for Xen-devel@lists.xensource.com; Mon, 18 Jun 2012 18:43:39 +0000
Received: from [85.158.143.35:38951] by server-1.bemta-4.messagelabs.com id
	45/64-24392-AD67FDF4; Mon, 18 Jun 2012 18:43:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340045016!5423379!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTkxMzg5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6731 invoked from network); 18 Jun 2012 18:43:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jun 2012 18:43:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5IIhUAF004140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 18 Jun 2012 18:43: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
	q5IIhTQM014967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2012 18:43:29 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
	q5IIhTQp007403; Mon, 18 Jun 2012 13:43:29 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 18 Jun 2012 11:43:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 91E16402A4; Mon, 18 Jun 2012 14:35:57 -0400 (EDT)
Date: Mon, 18 Jun 2012 14:35:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120618183557.GA28050@phenom.dumpdata.com>
References: <20120614184338.43fb879b@mantra.us.oracle.com>
	<alpine.DEB.2.02.1206151201150.14957@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206151201150.14957@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>
Subject: Re: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 15, 2012 at 12:02:19PM +0100, Stefano Stabellini wrote:
> On Fri, 15 Jun 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > During my refresh to latest linux, I noticed, direct mapping of all
> > non-RAM pages in xen_set_identity_and_release(). I currently don't map
> > all at front, but as needed looking at the PAGE_IO bit in the pte. One

PV doesn't look at that all the time either. The P2M tree code
has a couple of leafs, that if they have IDENTITY_FRAME_BIT set it will
automatically stick _PAGE_IOMAP on the PTE.

> > result of that is minor change to common code macro:
> > 
> >         __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
> > to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)

I am really wafling on that. Jeremy posted a patch some time ago
to x86 folks that would do something similar (I can't remember the
details), but hpa said - why don't you just consult the E820.

That is where the IDENTITY_FRAME_BIT thing in the P2M tree came
about. It could probably be implemented for your cases using ranges.

Similary to how Xen permits/disallows certain IO regions to be touched.
Would something like that potentially allow you do something like this:

xen_hybrid_pte()

phys_addr_t phys = pte.pte & PTE_PFN_MASK

if (phys .. within ranges)
	pte |= _PAGE_IOMAP;
return pte;

> >
> > 
> > To avoid this change, and keep all my changes limited to xen files only,
> > I thought I could just map the entire non-ram pages up front too. But
> > I am concerned the EPT may grow too large? Specially, when we get to 
> > *really* large NUMA boxes. What do you guys think? Should I worry about
> > it?

Would NUMA boxes have more than 1GB of E820 non-RAM regions? I can see them
having gobs of RAM regions, but non-RAM regions?

> 
> I would map them all up front and worry about it later.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 18 21:02:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 21:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgj4t-00010E-KF; Mon, 18 Jun 2012 21:01:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sgj4s-000109-3T
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 21:01:38 +0000
Received: from [193.109.254.147:42113] by server-10.bemta-14.messagelabs.com
	id E1/7C-05433-1379FDF4; Mon, 18 Jun 2012 21:01:37 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340053293!3523984!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9748 invoked from network); 18 Jun 2012 21:01:35 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 21:01:35 -0000
Received: by obbta14 with SMTP id ta14so35258obb.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 13:57:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=KgCPZ0rSHXSrQXPvhSUO4PtJXZh7+LotsG/wLg2pl9A=;
	b=eEKLH3XIaKi9EWctO6aS5eE+n6ol1iuYQjZO0qOFKTisop8X9AqQnt9D28x9TzZ21Q
	Rm7qEwWGxCu8y2uvnf3kL1cK674Ym7Z1+lgH5ZmKDgGyRjzMNDyzrnJWagjKv0+48ymf
	2V7kwtTwkmEzurP/XthhYyZEp0vFOFCMi+CZS/bTI0zAaVsy6aHL3kl2qojWtRHeYuWE
	rbNHCjtT6oj2rFMzuhj8Ym2xIT2ajITcEMbhmGNBwn6mr1svfyjKK7fo68svS0hQHxR1
	dQZHWu29GPfvYaAKjPvkzlPaa6Eg0BqaT6zvLUVEtVgx/Ua6wAjQwhm54q+UA2leTVFE
	3grg==
Received: by 10.60.19.226 with SMTP id i2mr17137529oee.20.1340053076492; Mon,
	18 Jun 2012 13:57:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 18 Jun 2012 13:57:36 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Mon, 18 Jun 2012 22:57:36 +0200
Message-ID: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQk3d9j2Wkd8meiNlHuwKtEs+dO02L206QD+KlD2Eoz7LHqgUCRyWxEMq5rPKETFu7y7kMIJ
Subject: [Xen-devel] Issue with MSI in a HVM domU with several passed
	through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I have a HVM domU running Ubuntu 12.04. It has several PCI devices
passed through to it (USB controllers, onboard sound, ATI video card
with gfx_passthru 0). It has some issues, the most apparent one with
the sound, which doesn't play normally but repeats the same short
fragment over and over for a while until moving on to the next
fragment. The Xen dmesg prints lots of lines like:

(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3

The number behind 108:d varies occasionally.

Since vmsi.c seems to deal with passing on MSI interrupts, I tried
booting the domU with pci=nomsi. This made things work and sound now
plays normally. Not using MSI at all doesn't seem like a very good
solution though.

What makes this happen, and can I fix it in a better way?

Data:
Xen: 4.2 unstable rev. 25483
Dom0 Ubuntu 12.04 3.4.0-030400-generic #201205210521

----- Xen dmesg when starting the domU without pci=nomsi:
(XEN) [2012-06-18 20:13:35] memory.c:131:d0 Could not allocate
order=18 extent: id=3 memflags=0 (0 of 1)
(XEN) [2012-06-18 20:13:37] physdev.c:174: dom3: 16:-1 already mapped to 16
(XEN) [2012-06-18 20:13:37] physdev.c:174: dom3: 16:-1 already mapped to 16
(XEN) [2012-06-18 20:13:37] HVM3: HVM Loader
(XEN) [2012-06-18 20:13:37] HVM3: Detected Xen v4.2-unstable
(XEN) [2012-06-18 20:13:37] HVM3: Xenbus rings @0xfeffc000, event channel 3
(XEN) [2012-06-18 20:13:37] HVM3: System requested ROMBIOS
(XEN) [2012-06-18 20:13:37] HVM3: CPU speed is 3300 MHz
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 0 changed 0 -> 5
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 0 routed to IRQ5
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 1 changed 0 -> 10
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 1 routed to IRQ10
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 2 changed 0 -> 11
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 2 routed to IRQ11
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 3 changed 0 -> 5
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 3 routed to IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:2 INTD->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:3 INTA->IRQ10
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 03:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 04:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 05:0 INTA->IRQ10
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 06:0 INTA->IRQ11
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 07:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 08:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 10 size 10000000: e000000c
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 18 size 00020000: f3000004
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 30 size 00020000: f3020000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 05:0 bar 10 size 00010000: f3040004
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 08:0 bar 10 size 00004000: f3050004
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 02:0 bar 14 size 00001000: f3054000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 06:0 bar 10 size 00001000: f3055000
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 07:0 bar 10 size 00001000: f3056000
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 04:0 bar 14 size 00000100: f3057000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 20 size 00000100: 0000c201
(XEN) [2012-06-18 20:13:37] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:2 bar 20 size 00000020: 0000c301
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:1 bar 20 size 00000010: 0000c321
(XEN) [2012-06-18 20:13:37] HVM3: Multiprocessor initialisation:
(XEN) [2012-06-18 20:13:37] HVM3:  - CPU0 ... 36-bit phys ... fixed
MTRRs ... var MTRRs [3/8] ... done.
(XEN) [2012-06-18 20:13:37] HVM3: Testing HVM environment:
(XEN) [2012-06-18 20:13:37] HVM3:  - REP INSB across page boundaries ... passed
(XEN) [2012-06-18 20:13:37] HVM3:  - GS base MSRs and SWAPGS ... passed
(XEN) [2012-06-18 20:13:37] HVM3: Passed 2 of 2 tests
(XEN) [2012-06-18 20:13:37] HVM3: Writing SMBIOS tables ...
(XEN) [2012-06-18 20:13:37] HVM3: Loading ROMBIOS ...
(XEN) [2012-06-18 20:13:37] HVM3: 12636 bytes of ROMBIOS high-memory extensions:
(XEN) [2012-06-18 20:13:37] HVM3:   Relocating to 0xfc001000-0xfc00415c ... done
(XEN) [2012-06-18 20:13:37] HVM3: Creating MP tables ...
(XEN) [2012-06-18 20:13:37] HVM3: Loading Cirrus VGABIOS ...
(XEN) [2012-06-18 20:13:37] HVM3: Loading PCI Option ROM ...
(XEN) [2012-06-18 20:13:37] HVM3:  - Manufacturer: http://ipxe.org
(XEN) [2012-06-18 20:13:37] HVM3:  - Product name: iPXE
(XEN) [2012-06-18 20:13:37] HVM3: Option ROMs:
(XEN) [2012-06-18 20:13:37] HVM3:  c0000-c8fff: VGA BIOS
(XEN) [2012-06-18 20:13:37] HVM3:  c9000-d8fff: Etherboot ROM
(XEN) [2012-06-18 20:13:37] HVM3: Loading ACPI ...
(XEN) [2012-06-18 20:13:37] HVM3: vm86 TSS at fc010280
(XEN) [2012-06-18 20:13:37] HVM3: BIOS map:
(XEN) [2012-06-18 20:13:37] HVM3:  f0000-fffff: Main BIOS
(XEN) [2012-06-18 20:13:37] HVM3: E820 table:
(XEN) [2012-06-18 20:13:37] HVM3:  [00]: 00000000:00000000 -
00000000:0009e000: RAM
(XEN) [2012-06-18 20:13:37] HVM3:  [01]: 00000000:0009e000 -
00000000:000a0000: RESERVED
(XEN) [2012-06-18 20:13:37] HVM3:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) [2012-06-18 20:13:37] HVM3:  [02]: 00000000:000e0000 -
00000000:00100000: RESERVED
(XEN) [2012-06-18 20:13:37] HVM3:  [03]: 00000000:00100000 -
00000000:e0000000: RAM
(XEN) [2012-06-18 20:13:37] HVM3:  HOLE: 00000000:e0000000 - 00000000:fc000000
(XEN) [2012-06-18 20:13:37] HVM3:  [04]: 00000000:fc000000 -
00000001:00000000: RESERVED
(XEN) [2012-06-18 20:13:37] HVM3:  [05]: 00000001:00000000 -
00000002:9f800000: RAM
(XEN) [2012-06-18 20:13:37] HVM3: Invoking ROMBIOS ...
(XEN) [2012-06-18 20:13:37] HVM3: $Revision: 1.221 $ $Date: 2008/12/07
17:32:29 $
(XEN) [2012-06-18 20:13:38] stdvga.c:147:d3 entering stdvga and caching modes
(XEN) [2012-06-18 20:13:38] HVM3: VGABios $Id: vgabios.c,v 1.67
2008/01/27 09:44:12 vruppert Exp $
(XEN) [2012-06-18 20:13:38] HVM3: Bochs BIOS - build: 06/23/99
(XEN) [2012-06-18 20:13:38] HVM3: $Revision: 1.221 $ $Date: 2008/12/07
17:32:29 $
(XEN) [2012-06-18 20:13:38] HVM3: Options: apmbios pcibios eltorito PMM
(XEN) [2012-06-18 20:13:38] HVM3:
(XEN) [2012-06-18 20:13:38] HVM3: ata0-0: PCHS=16383/16/63
translation=lba LCHS=1024/255/63
(XEN) [2012-06-18 20:13:38] HVM3: ata0 master: QEMU HARDDISK ATA-7
Hard-Disk (30720 MBytes)
(XEN) [2012-06-18 20:13:40] HVM3: IDE time out
(XEN) [2012-06-18 20:13:40] HVM3: ata1 master: QEMU DVD-ROM ATAPI-4
CD-Rom/DVD-Rom
(XEN) [2012-06-18 20:13:41] HVM3: IDE time out
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3: Press F12 for boot menu.
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3: Booting from Hard Disk...
(XEN) [2012-06-18 20:13:41] HVM3: Booting from 0000:7c00
(XEN) [2012-06-18 20:13:43] stdvga.c:151:d3 leaving stdvga
(XEN) [2012-06-18 20:13:55] irq.c:350: Dom3 callback via changed to
Direct Vector 0xf3
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 0 changed 5 -> 0
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 1 changed 10 -> 0
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 2 changed 11 -> 0
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 3 changed 5 -> 0
(XEN) [2012-06-18 20:13:56] irq.c:2234: dom3: pirq 49 or emuirq 23
already mapped
(XEN) [2012-06-18 20:13:56] vmsi.c:108:d3 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:02] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d0 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d0 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:21] vmsi.c:108:d0 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:51] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:24:36] vmsi.c:108:d32767 Unsupported delivery mode 3

----- Xen dmesg when starting dom0:

 __  __            _  _    ____                     _        _     _
 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.2-unstable (root@roce.org) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012
(XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864f2c
(XEN) Bootloader: GRUB 1.99-21ubuntu3.1
(XEN) Command line: placeholder xsave=0 loglvl=all guest_loglvl=all
console_timestamps=1 noreboot com1=115200,8n1,0x3f8,4 console=com1,vga
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 3 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d800 (usable)
(XEN)  000000000009d800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000bd8a7000 (usable)
(XEN)  00000000bd8a7000 - 00000000bde1f000 (reserved)
(XEN)  00000000bde1f000 - 00000000be09f000 (ACPI NVS)
(XEN)  00000000be09f000 - 00000000be0a4000 (ACPI data)
(XEN)  00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
(XEN)  00000000be0e7000 - 00000000beb81000 (usable)
(XEN)  00000000beb81000 - 00000000beff2000 (reserved)
(XEN)  00000000beff2000 - 00000000bf000000 (usable)
(XEN)  00000000bf800000 - 00000000cfa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000042f600000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA    A M I       14 INTL 20051117)
(XEN) ACPI: FACS BE09DF80, 0040
(XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
(XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl     1000 INTL 20091112)
(XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT   1072009 MSFT       97)
(XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA    A M I  1072009 AMI.        5)
(XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl     1000 INTL 20091112)
(XEN) ACPI: SSDT BE08ED88, 09AA (r1  PmRef  Cpu0Ist     3000 INTL 20051117)
(XEN) ACPI: SSDT BE08F738, 0A92 (r1  PmRef    CpuPm     3000 INTL 20051117)
(XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL      SNB         1 INTL        1)
(XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA    A M I  1072009 AMI     10013)
(XEN) System RAM: 16086MB (16473004kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000042f600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fceb0
(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 -
be09df80/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[be09df8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, 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) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3300.119 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1239: 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 f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(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) TSC deadline timer enabled
(XEN) [2012-06-18 20:50:08] Platform timer is 14.318MHz HPET
(XEN) [2012-06-18 20:50:08] Allocated console ring of 32 KiB.
(XEN) [2012-06-18 20:50:08] VMX: Supported advanced features:
(XEN) [2012-06-18 20:50:08]  - APIC MMIO access virtualisation
(XEN) [2012-06-18 20:50:08]  - APIC TPR shadow
(XEN) [2012-06-18 20:50:08]  - Extended Page Tables (EPT)
(XEN) [2012-06-18 20:50:08]  - Virtual-Processor Identifiers (VPID)
(XEN) [2012-06-18 20:50:08]  - Virtual NMI
(XEN) [2012-06-18 20:50:08]  - MSR direct-access bitmap
(XEN) [2012-06-18 20:50:08]  - Unrestricted Guest
(XEN) [2012-06-18 20:50:08] HVM: ASIDs enabled.
(XEN) [2012-06-18 20:50:08] HVM: VMX enabled
(XEN) [2012-06-18 20:50:08] HVM: Hardware Assisted Paging (HAP) detected
(XEN) [2012-06-18 20:50:08] HVM: HAP page sizes: 4kB, 2MB
(XEN) [2012-06-18 20:50:08] Brought up 4 CPUs
(XEN) [2012-06-18 20:50:08] ACPI sleep modes: S3
(XEN) [2012-06-18 20:50:08] mcheck_poll: Machine check polling timer started.
(XEN) [2012-06-18 20:50:08] *** LOADING DOMAIN 0 ***
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1000000
memsz=0xad7000
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1c00000
memsz=0xd90e8
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1cda000
memsz=0x14480
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1cef000
memsz=0x656000
(XEN) [2012-06-18 20:50:08] elf_parse_binary: memory: 0x1000000 -> 0x2345000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: GUEST_OS = "linux"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: ENTRY = 0xffffffff81cef200
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: HYPERCALL_PAGE =
0xffffffff81001000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: FEATURES =
"!writable_page_tables|pae_pgdir_above_4gb"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: PAE_MODE = "yes"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: LOADER = "generic"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: HV_START_LOW =
0xffff800000000000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) [2012-06-18 20:50:08] elf_xen_addr_calc_check: addresses:
(XEN) [2012-06-18 20:50:08]     virt_base        = 0xffffffff80000000
(XEN) [2012-06-18 20:50:08]     elf_paddr_offset = 0x0
(XEN) [2012-06-18 20:50:08]     virt_offset      = 0xffffffff80000000
(XEN) [2012-06-18 20:50:08]     virt_kstart      = 0xffffffff81000000
(XEN) [2012-06-18 20:50:08]     virt_kend        = 0xffffffff82345000
(XEN) [2012-06-18 20:50:08]     virt_entry       = 0xffffffff81cef200
(XEN) [2012-06-18 20:50:08]     p2m_base         = 0xffffffffffffffff
(XEN) [2012-06-18 20:50:08]  Xen  kernel: 64-bit, lsb, compat32
(XEN) [2012-06-18 20:50:08]  Dom0 kernel: 64-bit, PAE, lsb, paddr
0x1000000 -> 0x2345000
(XEN) [2012-06-18 20:50:08] PHYSICAL MEMORY ARRANGEMENT:
(XEN) [2012-06-18 20:50:08]  Dom0 alloc.:
0000000418000000->0000000420000000 (3987939 pages to be allocated)
(XEN) [2012-06-18 20:50:08]  Init. ramdisk: 000000042cff7000->000000042f5ffa00
(XEN) [2012-06-18 20:50:08] VIRTUAL MEMORY ARRANGEMENT:
(XEN) [2012-06-18 20:50:08]  Loaded kernel: ffffffff81000000->ffffffff82345000
(XEN) [2012-06-18 20:50:08]  Init. ramdisk: ffffffff82345000->ffffffff8494da00
(XEN) [2012-06-18 20:50:08]  Phys-Mach map: ffffffff8494e000->ffffffff8680df60
(XEN) [2012-06-18 20:50:08]  Start info:    ffffffff8680e000->ffffffff8680e4b4
(XEN) [2012-06-18 20:50:08]  Page tables:   ffffffff8680f000->ffffffff86848000
(XEN) [2012-06-18 20:50:08]  Boot stack:    ffffffff86848000->ffffffff86849000
(XEN) [2012-06-18 20:50:08]  TOTAL:         ffffffff80000000->ffffffff86c00000
(XEN) [2012-06-18 20:50:08]  ENTRY ADDRESS: ffffffff81cef200
(XEN) [2012-06-18 20:50:08] Dom0 has maximum 4 VCPUs
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 0 at
0xffffffff81000000 -> 0xffffffff81ad7000
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 1 at
0xffffffff81c00000 -> 0xffffffff81cd90e8
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 2 at
0xffffffff81cda000 -> 0xffffffff81cee480
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 3 at
0xffffffff81cef000 -> 0xffffffff81dc6000
(XEN) [2012-06-18 20:50:11] Scrubbing Free RAM: .done.
(XEN) [2012-06-18 20:50:11] Initial low memory virq threshold set at
0x4000 pages.
(XEN) [2012-06-18 20:50:11] Std. Loglevel: All
(XEN) [2012-06-18 20:50:11] Guest Loglevel: All
(XEN) [2012-06-18 20:50:11] Xen is relinquishing VGA console.
(XEN) [2012-06-18 20:50:11] *** Serial input -> DOM0 (type 'CTRL-a'
three times to switch input to Xen)
(XEN) [2012-06-18 20:50:11] Freed 244kB init memory.
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:01.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:02.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:14.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:16.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1a.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1b.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.4
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.5
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.6
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.7
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1d.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1f.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1f.2
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1f.3
(XEN) [2012-06-18 20:50:12] PCI add device 0000:01:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:01:00.1
(XEN) [2012-06-18 20:50:12] PCI add device 0000:03:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:04:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:05:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:06:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:07:01.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:07:02.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:07:03.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:0a:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:0b:02.0
(XEN) [2012-06-18 20:50:41] no cpu_id for acpi_id 5
(XEN) [2012-06-18 20:50:41] no cpu_id for acpi_id 6
(XEN) [2012-06-18 20:50:41] no cpu_id for acpi_id 7
(XEN) [2012-06-18 20:50:41] no cpu_id for 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 Mon Jun 18 21:02:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 21:02:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgj4t-00010E-KF; Mon, 18 Jun 2012 21:01:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sgj4s-000109-3T
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 21:01:38 +0000
Received: from [193.109.254.147:42113] by server-10.bemta-14.messagelabs.com
	id E1/7C-05433-1379FDF4; Mon, 18 Jun 2012 21:01:37 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340053293!3523984!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9748 invoked from network); 18 Jun 2012 21:01:35 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 21:01:35 -0000
Received: by obbta14 with SMTP id ta14so35258obb.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 13:57:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=KgCPZ0rSHXSrQXPvhSUO4PtJXZh7+LotsG/wLg2pl9A=;
	b=eEKLH3XIaKi9EWctO6aS5eE+n6ol1iuYQjZO0qOFKTisop8X9AqQnt9D28x9TzZ21Q
	Rm7qEwWGxCu8y2uvnf3kL1cK674Ym7Z1+lgH5ZmKDgGyRjzMNDyzrnJWagjKv0+48ymf
	2V7kwtTwkmEzurP/XthhYyZEp0vFOFCMi+CZS/bTI0zAaVsy6aHL3kl2qojWtRHeYuWE
	rbNHCjtT6oj2rFMzuhj8Ym2xIT2ajITcEMbhmGNBwn6mr1svfyjKK7fo68svS0hQHxR1
	dQZHWu29GPfvYaAKjPvkzlPaa6Eg0BqaT6zvLUVEtVgx/Ua6wAjQwhm54q+UA2leTVFE
	3grg==
Received: by 10.60.19.226 with SMTP id i2mr17137529oee.20.1340053076492; Mon,
	18 Jun 2012 13:57:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 18 Jun 2012 13:57:36 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Mon, 18 Jun 2012 22:57:36 +0200
Message-ID: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQk3d9j2Wkd8meiNlHuwKtEs+dO02L206QD+KlD2Eoz7LHqgUCRyWxEMq5rPKETFu7y7kMIJ
Subject: [Xen-devel] Issue with MSI in a HVM domU with several passed
	through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I have a HVM domU running Ubuntu 12.04. It has several PCI devices
passed through to it (USB controllers, onboard sound, ATI video card
with gfx_passthru 0). It has some issues, the most apparent one with
the sound, which doesn't play normally but repeats the same short
fragment over and over for a while until moving on to the next
fragment. The Xen dmesg prints lots of lines like:

(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3

The number behind 108:d varies occasionally.

Since vmsi.c seems to deal with passing on MSI interrupts, I tried
booting the domU with pci=nomsi. This made things work and sound now
plays normally. Not using MSI at all doesn't seem like a very good
solution though.

What makes this happen, and can I fix it in a better way?

Data:
Xen: 4.2 unstable rev. 25483
Dom0 Ubuntu 12.04 3.4.0-030400-generic #201205210521

----- Xen dmesg when starting the domU without pci=nomsi:
(XEN) [2012-06-18 20:13:35] memory.c:131:d0 Could not allocate
order=18 extent: id=3 memflags=0 (0 of 1)
(XEN) [2012-06-18 20:13:37] physdev.c:174: dom3: 16:-1 already mapped to 16
(XEN) [2012-06-18 20:13:37] physdev.c:174: dom3: 16:-1 already mapped to 16
(XEN) [2012-06-18 20:13:37] HVM3: HVM Loader
(XEN) [2012-06-18 20:13:37] HVM3: Detected Xen v4.2-unstable
(XEN) [2012-06-18 20:13:37] HVM3: Xenbus rings @0xfeffc000, event channel 3
(XEN) [2012-06-18 20:13:37] HVM3: System requested ROMBIOS
(XEN) [2012-06-18 20:13:37] HVM3: CPU speed is 3300 MHz
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 0 changed 0 -> 5
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 0 routed to IRQ5
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 1 changed 0 -> 10
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 1 routed to IRQ10
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 2 changed 0 -> 11
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 2 routed to IRQ11
(XEN) [2012-06-18 20:13:37] irq.c:270: Dom3 PCI link 3 changed 0 -> 5
(XEN) [2012-06-18 20:13:37] HVM3: PCI-ISA link 3 routed to IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:2 INTD->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:3 INTA->IRQ10
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 03:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 04:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 05:0 INTA->IRQ10
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 06:0 INTA->IRQ11
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 07:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 08:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 INTA->IRQ5
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 10 size 10000000: e000000c
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 18 size 00020000: f3000004
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 30 size 00020000: f3020000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 05:0 bar 10 size 00010000: f3040004
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 08:0 bar 10 size 00004000: f3050004
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 02:0 bar 14 size 00001000: f3054000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 06:0 bar 10 size 00001000: f3055000
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 07:0 bar 10 size 00001000: f3056000
(XEN) [2012-06-18 20:13:37] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 04:0 bar 14 size 00000100: f3057000
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 10:0 bar 20 size 00000100: 0000c201
(XEN) [2012-06-18 20:13:37] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:2 bar 20 size 00000020: 0000c301
(XEN) [2012-06-18 20:13:37] HVM3: pci dev 01:1 bar 20 size 00000010: 0000c321
(XEN) [2012-06-18 20:13:37] HVM3: Multiprocessor initialisation:
(XEN) [2012-06-18 20:13:37] HVM3:  - CPU0 ... 36-bit phys ... fixed
MTRRs ... var MTRRs [3/8] ... done.
(XEN) [2012-06-18 20:13:37] HVM3: Testing HVM environment:
(XEN) [2012-06-18 20:13:37] HVM3:  - REP INSB across page boundaries ... passed
(XEN) [2012-06-18 20:13:37] HVM3:  - GS base MSRs and SWAPGS ... passed
(XEN) [2012-06-18 20:13:37] HVM3: Passed 2 of 2 tests
(XEN) [2012-06-18 20:13:37] HVM3: Writing SMBIOS tables ...
(XEN) [2012-06-18 20:13:37] HVM3: Loading ROMBIOS ...
(XEN) [2012-06-18 20:13:37] HVM3: 12636 bytes of ROMBIOS high-memory extensions:
(XEN) [2012-06-18 20:13:37] HVM3:   Relocating to 0xfc001000-0xfc00415c ... done
(XEN) [2012-06-18 20:13:37] HVM3: Creating MP tables ...
(XEN) [2012-06-18 20:13:37] HVM3: Loading Cirrus VGABIOS ...
(XEN) [2012-06-18 20:13:37] HVM3: Loading PCI Option ROM ...
(XEN) [2012-06-18 20:13:37] HVM3:  - Manufacturer: http://ipxe.org
(XEN) [2012-06-18 20:13:37] HVM3:  - Product name: iPXE
(XEN) [2012-06-18 20:13:37] HVM3: Option ROMs:
(XEN) [2012-06-18 20:13:37] HVM3:  c0000-c8fff: VGA BIOS
(XEN) [2012-06-18 20:13:37] HVM3:  c9000-d8fff: Etherboot ROM
(XEN) [2012-06-18 20:13:37] HVM3: Loading ACPI ...
(XEN) [2012-06-18 20:13:37] HVM3: vm86 TSS at fc010280
(XEN) [2012-06-18 20:13:37] HVM3: BIOS map:
(XEN) [2012-06-18 20:13:37] HVM3:  f0000-fffff: Main BIOS
(XEN) [2012-06-18 20:13:37] HVM3: E820 table:
(XEN) [2012-06-18 20:13:37] HVM3:  [00]: 00000000:00000000 -
00000000:0009e000: RAM
(XEN) [2012-06-18 20:13:37] HVM3:  [01]: 00000000:0009e000 -
00000000:000a0000: RESERVED
(XEN) [2012-06-18 20:13:37] HVM3:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) [2012-06-18 20:13:37] HVM3:  [02]: 00000000:000e0000 -
00000000:00100000: RESERVED
(XEN) [2012-06-18 20:13:37] HVM3:  [03]: 00000000:00100000 -
00000000:e0000000: RAM
(XEN) [2012-06-18 20:13:37] HVM3:  HOLE: 00000000:e0000000 - 00000000:fc000000
(XEN) [2012-06-18 20:13:37] HVM3:  [04]: 00000000:fc000000 -
00000001:00000000: RESERVED
(XEN) [2012-06-18 20:13:37] HVM3:  [05]: 00000001:00000000 -
00000002:9f800000: RAM
(XEN) [2012-06-18 20:13:37] HVM3: Invoking ROMBIOS ...
(XEN) [2012-06-18 20:13:37] HVM3: $Revision: 1.221 $ $Date: 2008/12/07
17:32:29 $
(XEN) [2012-06-18 20:13:38] stdvga.c:147:d3 entering stdvga and caching modes
(XEN) [2012-06-18 20:13:38] HVM3: VGABios $Id: vgabios.c,v 1.67
2008/01/27 09:44:12 vruppert Exp $
(XEN) [2012-06-18 20:13:38] HVM3: Bochs BIOS - build: 06/23/99
(XEN) [2012-06-18 20:13:38] HVM3: $Revision: 1.221 $ $Date: 2008/12/07
17:32:29 $
(XEN) [2012-06-18 20:13:38] HVM3: Options: apmbios pcibios eltorito PMM
(XEN) [2012-06-18 20:13:38] HVM3:
(XEN) [2012-06-18 20:13:38] HVM3: ata0-0: PCHS=16383/16/63
translation=lba LCHS=1024/255/63
(XEN) [2012-06-18 20:13:38] HVM3: ata0 master: QEMU HARDDISK ATA-7
Hard-Disk (30720 MBytes)
(XEN) [2012-06-18 20:13:40] HVM3: IDE time out
(XEN) [2012-06-18 20:13:40] HVM3: ata1 master: QEMU DVD-ROM ATAPI-4
CD-Rom/DVD-Rom
(XEN) [2012-06-18 20:13:41] HVM3: IDE time out
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3: Press F12 for boot menu.
(XEN) [2012-06-18 20:13:41] HVM3:
(XEN) [2012-06-18 20:13:41] HVM3: Booting from Hard Disk...
(XEN) [2012-06-18 20:13:41] HVM3: Booting from 0000:7c00
(XEN) [2012-06-18 20:13:43] stdvga.c:151:d3 leaving stdvga
(XEN) [2012-06-18 20:13:55] irq.c:350: Dom3 callback via changed to
Direct Vector 0xf3
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3040 mfn=f7d00 nr=10
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3055 mfn=f7d18 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3056 mfn=f7d17 nr=1
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3050 mfn=f7d10 nr=4
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:remove: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:remove: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=e0000 mfn=e0000 nr=10000
(XEN) [2012-06-18 20:13:55] memory_map:add: dom3 gfn=f3000 mfn=f7c20 nr=20
(XEN) [2012-06-18 20:13:55] ioport_map:add: dom3 gport=c200 mport=e000 nr=100
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 0 changed 5 -> 0
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 1 changed 10 -> 0
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 2 changed 11 -> 0
(XEN) [2012-06-18 20:13:55] irq.c:270: Dom3 PCI link 3 changed 5 -> 0
(XEN) [2012-06-18 20:13:56] irq.c:2234: dom3: pirq 49 or emuirq 23
already mapped
(XEN) [2012-06-18 20:13:56] vmsi.c:108:d3 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:02] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d0 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d0 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:21] vmsi.c:108:d0 Unsupported delivery mode 3
(XEN) [2012-06-18 20:14:51] vmsi.c:108:d32767 Unsupported delivery mode 3
(XEN) [2012-06-18 20:24:36] vmsi.c:108:d32767 Unsupported delivery mode 3

----- Xen dmesg when starting dom0:

 __  __            _  _    ____                     _        _     _
 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.2-unstable (root@roce.org) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) Fri Jun 15 05:32:29 CEST 2012
(XEN) Latest ChangeSet: Thu Jun 14 16:05:42 2012 +0100 25483:9dffb1864f2c
(XEN) Bootloader: GRUB 1.99-21ubuntu3.1
(XEN) Command line: placeholder xsave=0 loglvl=all guest_loglvl=all
console_timestamps=1 noreboot com1=115200,8n1,0x3f8,4 console=com1,vga
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 3 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d800 (usable)
(XEN)  000000000009d800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000bd8a7000 (usable)
(XEN)  00000000bd8a7000 - 00000000bde1f000 (reserved)
(XEN)  00000000bde1f000 - 00000000be09f000 (ACPI NVS)
(XEN)  00000000be09f000 - 00000000be0a4000 (ACPI data)
(XEN)  00000000be0a4000 - 00000000be0e7000 (ACPI NVS)
(XEN)  00000000be0e7000 - 00000000beb81000 (usable)
(XEN)  00000000beb81000 - 00000000beff2000 (reserved)
(XEN)  00000000beff2000 - 00000000bf000000 (usable)
(XEN)  00000000bf800000 - 00000000cfa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000042f600000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT BE084080, 0084 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: FACP BE08E218, 00F4 (r4 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: DSDT BE0841A0, A077 (r2 ALASKA    A M I       14 INTL 20051117)
(XEN) ACPI: FACS BE09DF80, 0040
(XEN) ACPI: APIC BE08E310, 0072 (r3 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: ASF! BE08E388, 00A5 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) ACPI: MCFG BE08E430, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
(XEN) ACPI: SSDT BE08E470, 04A6 (r1 Intel_ AoacTabl     1000 INTL 20091112)
(XEN) ACPI: AAFT BE08E918, 00C2 (r1 ALASKA OEMAAFT   1072009 MSFT       97)
(XEN) ACPI: HPET BE08E9E0, 0038 (r1 ALASKA    A M I  1072009 AMI.        5)
(XEN) ACPI: SSDT BE08EA18, 036D (r1 SataRe SataTabl     1000 INTL 20091112)
(XEN) ACPI: SSDT BE08ED88, 09AA (r1  PmRef  Cpu0Ist     3000 INTL 20051117)
(XEN) ACPI: SSDT BE08F738, 0A92 (r1  PmRef    CpuPm     3000 INTL 20051117)
(XEN) ACPI: DMAR BE0901D0, 00B8 (r1 INTEL      SNB         1 INTL        1)
(XEN) ACPI: BGRT BE090288, 003C (r0 ALASKA    A M I  1072009 AMI     10013)
(XEN) System RAM: 16086MB (16473004kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000042f600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fceb0
(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 -
be09df80/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[be09df8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, 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) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3300.119 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1239: 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 f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(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) TSC deadline timer enabled
(XEN) [2012-06-18 20:50:08] Platform timer is 14.318MHz HPET
(XEN) [2012-06-18 20:50:08] Allocated console ring of 32 KiB.
(XEN) [2012-06-18 20:50:08] VMX: Supported advanced features:
(XEN) [2012-06-18 20:50:08]  - APIC MMIO access virtualisation
(XEN) [2012-06-18 20:50:08]  - APIC TPR shadow
(XEN) [2012-06-18 20:50:08]  - Extended Page Tables (EPT)
(XEN) [2012-06-18 20:50:08]  - Virtual-Processor Identifiers (VPID)
(XEN) [2012-06-18 20:50:08]  - Virtual NMI
(XEN) [2012-06-18 20:50:08]  - MSR direct-access bitmap
(XEN) [2012-06-18 20:50:08]  - Unrestricted Guest
(XEN) [2012-06-18 20:50:08] HVM: ASIDs enabled.
(XEN) [2012-06-18 20:50:08] HVM: VMX enabled
(XEN) [2012-06-18 20:50:08] HVM: Hardware Assisted Paging (HAP) detected
(XEN) [2012-06-18 20:50:08] HVM: HAP page sizes: 4kB, 2MB
(XEN) [2012-06-18 20:50:08] Brought up 4 CPUs
(XEN) [2012-06-18 20:50:08] ACPI sleep modes: S3
(XEN) [2012-06-18 20:50:08] mcheck_poll: Machine check polling timer started.
(XEN) [2012-06-18 20:50:08] *** LOADING DOMAIN 0 ***
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1000000
memsz=0xad7000
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1c00000
memsz=0xd90e8
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1cda000
memsz=0x14480
(XEN) [2012-06-18 20:50:08] elf_parse_binary: phdr: paddr=0x1cef000
memsz=0x656000
(XEN) [2012-06-18 20:50:08] elf_parse_binary: memory: 0x1000000 -> 0x2345000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: GUEST_OS = "linux"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: ENTRY = 0xffffffff81cef200
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: HYPERCALL_PAGE =
0xffffffff81001000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: FEATURES =
"!writable_page_tables|pae_pgdir_above_4gb"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: PAE_MODE = "yes"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: LOADER = "generic"
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: HV_START_LOW =
0xffff800000000000
(XEN) [2012-06-18 20:50:08] elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) [2012-06-18 20:50:08] elf_xen_addr_calc_check: addresses:
(XEN) [2012-06-18 20:50:08]     virt_base        = 0xffffffff80000000
(XEN) [2012-06-18 20:50:08]     elf_paddr_offset = 0x0
(XEN) [2012-06-18 20:50:08]     virt_offset      = 0xffffffff80000000
(XEN) [2012-06-18 20:50:08]     virt_kstart      = 0xffffffff81000000
(XEN) [2012-06-18 20:50:08]     virt_kend        = 0xffffffff82345000
(XEN) [2012-06-18 20:50:08]     virt_entry       = 0xffffffff81cef200
(XEN) [2012-06-18 20:50:08]     p2m_base         = 0xffffffffffffffff
(XEN) [2012-06-18 20:50:08]  Xen  kernel: 64-bit, lsb, compat32
(XEN) [2012-06-18 20:50:08]  Dom0 kernel: 64-bit, PAE, lsb, paddr
0x1000000 -> 0x2345000
(XEN) [2012-06-18 20:50:08] PHYSICAL MEMORY ARRANGEMENT:
(XEN) [2012-06-18 20:50:08]  Dom0 alloc.:
0000000418000000->0000000420000000 (3987939 pages to be allocated)
(XEN) [2012-06-18 20:50:08]  Init. ramdisk: 000000042cff7000->000000042f5ffa00
(XEN) [2012-06-18 20:50:08] VIRTUAL MEMORY ARRANGEMENT:
(XEN) [2012-06-18 20:50:08]  Loaded kernel: ffffffff81000000->ffffffff82345000
(XEN) [2012-06-18 20:50:08]  Init. ramdisk: ffffffff82345000->ffffffff8494da00
(XEN) [2012-06-18 20:50:08]  Phys-Mach map: ffffffff8494e000->ffffffff8680df60
(XEN) [2012-06-18 20:50:08]  Start info:    ffffffff8680e000->ffffffff8680e4b4
(XEN) [2012-06-18 20:50:08]  Page tables:   ffffffff8680f000->ffffffff86848000
(XEN) [2012-06-18 20:50:08]  Boot stack:    ffffffff86848000->ffffffff86849000
(XEN) [2012-06-18 20:50:08]  TOTAL:         ffffffff80000000->ffffffff86c00000
(XEN) [2012-06-18 20:50:08]  ENTRY ADDRESS: ffffffff81cef200
(XEN) [2012-06-18 20:50:08] Dom0 has maximum 4 VCPUs
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 0 at
0xffffffff81000000 -> 0xffffffff81ad7000
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 1 at
0xffffffff81c00000 -> 0xffffffff81cd90e8
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 2 at
0xffffffff81cda000 -> 0xffffffff81cee480
(XEN) [2012-06-18 20:50:08] elf_load_binary: phdr 3 at
0xffffffff81cef000 -> 0xffffffff81dc6000
(XEN) [2012-06-18 20:50:11] Scrubbing Free RAM: .done.
(XEN) [2012-06-18 20:50:11] Initial low memory virq threshold set at
0x4000 pages.
(XEN) [2012-06-18 20:50:11] Std. Loglevel: All
(XEN) [2012-06-18 20:50:11] Guest Loglevel: All
(XEN) [2012-06-18 20:50:11] Xen is relinquishing VGA console.
(XEN) [2012-06-18 20:50:11] *** Serial input -> DOM0 (type 'CTRL-a'
three times to switch input to Xen)
(XEN) [2012-06-18 20:50:11] Freed 244kB init memory.
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:01.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:02.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:14.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:16.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1a.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1b.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.4
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.5
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.6
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1c.7
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1d.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1f.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1f.2
(XEN) [2012-06-18 20:50:12] PCI add device 0000:00:1f.3
(XEN) [2012-06-18 20:50:12] PCI add device 0000:01:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:01:00.1
(XEN) [2012-06-18 20:50:12] PCI add device 0000:03:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:04:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:05:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:06:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:07:01.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:07:02.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:07:03.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:0a:00.0
(XEN) [2012-06-18 20:50:12] PCI add device 0000:0b:02.0
(XEN) [2012-06-18 20:50:41] no cpu_id for acpi_id 5
(XEN) [2012-06-18 20:50:41] no cpu_id for acpi_id 6
(XEN) [2012-06-18 20:50:41] no cpu_id for acpi_id 7
(XEN) [2012-06-18 20:50:41] no cpu_id for 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 Mon Jun 18 21:23:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 21: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 1SgjPQ-0001Hq-Ms; Mon, 18 Jun 2012 21:22:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1SgjPP-0001Hl-4J
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 21:22:51 +0000
Received: from [85.158.139.83:14978] by server-12.bemta-5.messagelabs.com id
	16/95-25233-A2C9FDF4; Mon, 18 Jun 2012 21:22:50 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340054567!20948490!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26301 invoked from network); 18 Jun 2012 21:22:49 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 21:22:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=Wk7TXSMGELqz
	j7o5Qr+NUHE12eA=; b=GFGh9k58le44lQuugMd4MxzN6F8ozP32ZH98ji71JNKu
	hY+3bJF74wah76t5xmeLKP8IbxUOYUyWw6Ln9LrO8SN3sYO3O6b+Bdnr2khABh2v
	sPog4e8AKKhc1rTEGrgvfKGXGqu5Botwft0Ag2qOYBDWoh9KZLNohM7XPwOcCbI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=FQpt7Q
	NxmhNNaQcvnGFdmxQupkTjwD2ZodMEVlqtoYoc39QoTcMlV8EnBbN0881d6hM5S2
	Zmq6aNL/f0vUOSyLXppo0/4Xe+UGqt6Hv5ueai/croUgutlX9dPW2sAxqyM32k9w
	jMe7XRncJQuMGO8/66NfOJSvWYqLtfd2px/rk=
Received: (qmail 8019 invoked from network); 18 Jun 2012 21:22:46 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	18 Jun 2012 21:22:46 -0000
Message-ID: <4FDF9C25.9080306@gt.net>
Date: Mon, 18 Jun 2012 14:22:45 -0700
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EA88A4A.1040805@gt.net>
	<20111027110703.GG59656@ocelot.phlegethon.org>
In-Reply-To: <20111027110703.GG59656@ocelot.phlegethon.org>
Subject: Re: [Xen-devel] Clock jumping during live migrations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 10/27/2011 4:07 AM, Tim Deegan wrote:
> At 15:31 -0700 on 26 Oct (1319643098), Nathan March wrote:
>> Having an issue where the clock on a VM will jump ahead by the timezone
>> offset but only certain directions between certain machines.
>>
>> For example, if I run a "sleep 1; date" loop on the VM and migrate it
>> from xen4 to xen7:
>>
>> Wed Oct 26 21:14:46 PDT 2011
>> Thu Oct 27 04:19:03 PDT 2011
>> xen4 ~ # uname -a
>> Linux xen4 3.0.3 #3 SMP Thu Sep 1 23:39:43 PDT 2011 x86_64 Intel(R)
> I think maybe you need these patches on your dom0 kernel:
>
> http://lists.xensource.com/archives/html/xen-devel/2011-10/msg01762.html

Unfortunately I'm still running into this problem, migrating VM's 
between particular dom0's will result in a jump forward of anywhere from 
minutes to hours. This has persisted through dom0 and xen upgrades (now 
on dom0 3.2.7 / xen 4.1.2) so maybe we're missing something in the domu 
kernel (2.6.32.27)? Reviewing kernel change logs doesn't indicate 
anything's changed in regard to clocksources though.

Examples (just running date on the domU after each migration)

Initially: Mon Jun 18 13:53:48 PDT 2012
Xen2 -> Xen8: Mon Jun 18 13:55:05 PDT 2012 (No shift)
Xen8 -> Xen2: Mon Jun 18 14:27:31 PDT 2012 (+30 approx minutes)
Xen2 -> Xen8: Mon Jun 18 14:28:38 PDT 2012 (No shift)
Xen8 -> Xen2: Mon Jun 18 15:01:21 PDT 2012 (+30 minutes again)

This is now running with a domu kernel of 2.6.32.27 (w/ grsec) and a 
dom0 kernel of 3.2.7 on both dom0's (they should be identical). I've 
tried both the "tsc" and "xen" clocksources in the domU with no effect 
(no others are listed in available_clocksources).

Not sure if this is useful, but while on xen8:
(XEN) dom27: mode=0,ofs=0xffc56b8eee259ecf,khz=2266790,inc=13,vtsc 
count: 37835 kernel, 750 user

After moving to xen2:
(XEN) dom7: mode=0,ofs=0xffc51d4984ee8f42,khz=2266790,inc=14,vtsc count: 
17628 kernel, 71 user

Anyone have any suggestions here?

Thanks,
Nathan

-- 
Nathan March<nathan@gt.net>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 21:23:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 21: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 1SgjPQ-0001Hq-Ms; Mon, 18 Jun 2012 21:22:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1SgjPP-0001Hl-4J
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 21:22:51 +0000
Received: from [85.158.139.83:14978] by server-12.bemta-5.messagelabs.com id
	16/95-25233-A2C9FDF4; Mon, 18 Jun 2012 21:22:50 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340054567!20948490!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26301 invoked from network); 18 Jun 2012 21:22:49 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jun 2012 21:22:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=Wk7TXSMGELqz
	j7o5Qr+NUHE12eA=; b=GFGh9k58le44lQuugMd4MxzN6F8ozP32ZH98ji71JNKu
	hY+3bJF74wah76t5xmeLKP8IbxUOYUyWw6Ln9LrO8SN3sYO3O6b+Bdnr2khABh2v
	sPog4e8AKKhc1rTEGrgvfKGXGqu5Botwft0Ag2qOYBDWoh9KZLNohM7XPwOcCbI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=FQpt7Q
	NxmhNNaQcvnGFdmxQupkTjwD2ZodMEVlqtoYoc39QoTcMlV8EnBbN0881d6hM5S2
	Zmq6aNL/f0vUOSyLXppo0/4Xe+UGqt6Hv5ueai/croUgutlX9dPW2sAxqyM32k9w
	jMe7XRncJQuMGO8/66NfOJSvWYqLtfd2px/rk=
Received: (qmail 8019 invoked from network); 18 Jun 2012 21:22:46 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	18 Jun 2012 21:22:46 -0000
Message-ID: <4FDF9C25.9080306@gt.net>
Date: Mon, 18 Jun 2012 14:22:45 -0700
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EA88A4A.1040805@gt.net>
	<20111027110703.GG59656@ocelot.phlegethon.org>
In-Reply-To: <20111027110703.GG59656@ocelot.phlegethon.org>
Subject: Re: [Xen-devel] Clock jumping during live migrations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 10/27/2011 4:07 AM, Tim Deegan wrote:
> At 15:31 -0700 on 26 Oct (1319643098), Nathan March wrote:
>> Having an issue where the clock on a VM will jump ahead by the timezone
>> offset but only certain directions between certain machines.
>>
>> For example, if I run a "sleep 1; date" loop on the VM and migrate it
>> from xen4 to xen7:
>>
>> Wed Oct 26 21:14:46 PDT 2011
>> Thu Oct 27 04:19:03 PDT 2011
>> xen4 ~ # uname -a
>> Linux xen4 3.0.3 #3 SMP Thu Sep 1 23:39:43 PDT 2011 x86_64 Intel(R)
> I think maybe you need these patches on your dom0 kernel:
>
> http://lists.xensource.com/archives/html/xen-devel/2011-10/msg01762.html

Unfortunately I'm still running into this problem, migrating VM's 
between particular dom0's will result in a jump forward of anywhere from 
minutes to hours. This has persisted through dom0 and xen upgrades (now 
on dom0 3.2.7 / xen 4.1.2) so maybe we're missing something in the domu 
kernel (2.6.32.27)? Reviewing kernel change logs doesn't indicate 
anything's changed in regard to clocksources though.

Examples (just running date on the domU after each migration)

Initially: Mon Jun 18 13:53:48 PDT 2012
Xen2 -> Xen8: Mon Jun 18 13:55:05 PDT 2012 (No shift)
Xen8 -> Xen2: Mon Jun 18 14:27:31 PDT 2012 (+30 approx minutes)
Xen2 -> Xen8: Mon Jun 18 14:28:38 PDT 2012 (No shift)
Xen8 -> Xen2: Mon Jun 18 15:01:21 PDT 2012 (+30 minutes again)

This is now running with a domu kernel of 2.6.32.27 (w/ grsec) and a 
dom0 kernel of 3.2.7 on both dom0's (they should be identical). I've 
tried both the "tsc" and "xen" clocksources in the domU with no effect 
(no others are listed in available_clocksources).

Not sure if this is useful, but while on xen8:
(XEN) dom27: mode=0,ofs=0xffc56b8eee259ecf,khz=2266790,inc=13,vtsc 
count: 37835 kernel, 750 user

After moving to xen2:
(XEN) dom7: mode=0,ofs=0xffc51d4984ee8f42,khz=2266790,inc=14,vtsc count: 
17628 kernel, 71 user

Anyone have any suggestions here?

Thanks,
Nathan

-- 
Nathan March<nathan@gt.net>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 22:25:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 22:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgkNj-00024Q-4M; Mon, 18 Jun 2012 22:25:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1SgkNh-00024I-FM
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 22:25:09 +0000
Received: from [193.109.254.147:35828] by server-6.bemta-14.messagelabs.com id
	75/18-08993-4CAAFDF4; Mon, 18 Jun 2012 22:25:08 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340058307!10324301!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17231 invoked from network); 18 Jun 2012 22:25:07 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 22:25:07 -0000
Received: by lbom4 with SMTP id m4so6292160lbo.30
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Jun 2012 15:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=1sCotBLQZSU7IgTug7phYSjC4l3IaNaMntyP5i6x2+Y=;
	b=s3VMH1ZUiqYE4g5UYS2rrSam9QNs8Y33z40Y0i4JW/vXVLynwFPud50gupKEYmSdrU
	oFGLl5XyI3GF6N34sV22bRCTO/uqZ1QeIraE1QmxtpxfUVzdAXTDZhPbQCh8se0PZOaY
	bnmI9AOZmftmG7P3eJG06Xh9bRAVpwQn5gTKryRBS3kTxia+uSn8ZOE52mRa3UKqfuXm
	TKrNxJEnYvyNJQBbwwalZTn798QpWJ9to2Lxu0G8aabifa6WhqW5cWwRh0enxNbNO6s+
	aCbr/WXOIat53ZolHs1SB+IzIdvWUs9WKScRPbInuzMSuzdcmqrVucsKhzLHg0kxfDFQ
	mZwg==
Received: by 10.112.23.196 with SMTP id o4mr7165964lbf.49.1340058307069; Mon,
	18 Jun 2012 15:25:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.40.10 with HTTP; Mon, 18 Jun 2012 15:24:26 -0700 (PDT)
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Tue, 19 Jun 2012 02:54:26 +0430
Message-ID: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] fsimage - no such 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

I am having a problem with pygrub of the current (rev 25467)
xen-unstable pygrub in Ubuntu 12.04. pygrub can not read any image. I
have traced the python code and found the problem being in
fsimage.open(file, offset, bootfsoptions). It raises IOError "no such
file or directory". I even wrote the following code and got the same
error.

#!/usr/bin/python
import fsimage

print "Hello, World!"
try:
    fs = fsimage.open("/root/guest/mini.iso", 0, "")
except Exception as e:
    print "Exception ", e

It seems that libfsimage has a problem with current version of Ubuntu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 22:25:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 22:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgkNj-00024Q-4M; Mon, 18 Jun 2012 22:25:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1SgkNh-00024I-FM
	for xen-devel@lists.xensource.com; Mon, 18 Jun 2012 22:25:09 +0000
Received: from [193.109.254.147:35828] by server-6.bemta-14.messagelabs.com id
	75/18-08993-4CAAFDF4; Mon, 18 Jun 2012 22:25:08 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340058307!10324301!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17231 invoked from network); 18 Jun 2012 22:25:07 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 22:25:07 -0000
Received: by lbom4 with SMTP id m4so6292160lbo.30
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Jun 2012 15:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=1sCotBLQZSU7IgTug7phYSjC4l3IaNaMntyP5i6x2+Y=;
	b=s3VMH1ZUiqYE4g5UYS2rrSam9QNs8Y33z40Y0i4JW/vXVLynwFPud50gupKEYmSdrU
	oFGLl5XyI3GF6N34sV22bRCTO/uqZ1QeIraE1QmxtpxfUVzdAXTDZhPbQCh8se0PZOaY
	bnmI9AOZmftmG7P3eJG06Xh9bRAVpwQn5gTKryRBS3kTxia+uSn8ZOE52mRa3UKqfuXm
	TKrNxJEnYvyNJQBbwwalZTn798QpWJ9to2Lxu0G8aabifa6WhqW5cWwRh0enxNbNO6s+
	aCbr/WXOIat53ZolHs1SB+IzIdvWUs9WKScRPbInuzMSuzdcmqrVucsKhzLHg0kxfDFQ
	mZwg==
Received: by 10.112.23.196 with SMTP id o4mr7165964lbf.49.1340058307069; Mon,
	18 Jun 2012 15:25:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.40.10 with HTTP; Mon, 18 Jun 2012 15:24:26 -0700 (PDT)
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Tue, 19 Jun 2012 02:54:26 +0430
Message-ID: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] fsimage - no such 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

I am having a problem with pygrub of the current (rev 25467)
xen-unstable pygrub in Ubuntu 12.04. pygrub can not read any image. I
have traced the python code and found the problem being in
fsimage.open(file, offset, bootfsoptions). It raises IOError "no such
file or directory". I even wrote the following code and got the same
error.

#!/usr/bin/python
import fsimage

print "Hello, World!"
try:
    fs = fsimage.open("/root/guest/mini.iso", 0, "")
except Exception as e:
    print "Exception ", e

It seems that libfsimage has a problem with current version of Ubuntu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 22:36:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 22:36: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 1SgkY7-0002Gp-AB; Mon, 18 Jun 2012 22:35:55 +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 1SgkY6-0002Gk-Bf
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 22:35:54 +0000
Received: from [85.158.139.83:41422] by server-3.bemta-5.messagelabs.com id
	E8/48-03367-94DAFDF4; Mon, 18 Jun 2012 22:35:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340058951!28214097!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32581 invoked from network); 18 Jun 2012 22:35:51 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 22:35:51 -0000
Received: by wgbed3 with SMTP id ed3so4138478wgb.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 15:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jwA1kXOaiVd0LgeHhaoyQgvlDBi9LyugiLIBWL79s2s=;
	b=wO+gdl/Atv12Uu+g7lWV/OVJjHQ3HiZ3Hy11wAGFjL6z+0hDh0lOMBXlh4eLTIC09B
	XQbrc/cZQmYayZDwyyB+dy++zibh21E+nzB7QPkxHPOnTObNQv/mQ+Wv3SGdqvb2ewR4
	yKXNaRPOJWdSGxVNbd368lHWvQ9biRmHDJcRensvIScPMWaHAH8YSAc5eWQjE73YHJnR
	Ig+3ueOu4ouJ2uEnk8BNoChY0ig90RzoMLxfuUe+S/uaK+BLCjGGRvjCHuveZU+0OKoe
	jTFCGIlgiPsfUykSJiZakJctyHg3XMq9I8yXpqaP1Ohn+wjhBPgIaZTD3XkJnI4wkP0P
	ne7w==
Received: by 10.216.145.97 with SMTP id o75mr9005694wej.7.1340058947813;
	Mon, 18 Jun 2012 15:35:47 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id e20sm28296401wiv.7.2012.06.18.15.35.46
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 15:35:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 23:35:43 +0100
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC056BCF.4321A%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1NorIASNJZUgrjfkCgkFXGWYarrg==
In-Reply-To: <20120618182450.GF24750@phenom.dumpdata.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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 18/06/2012 19:24, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:

>>> It should be possible for the guest kernel to track its CR0.TS setting
>>> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
> 
> Hm, the clts() paravirt could take advantage of the per-cpu cr0 to
> figure out whether it truly needs to do anything.

Exactly.

>>> cleared on #NM.
>> Sure, but selling this to the Linux maintainers I would expect to be
>> harder than fitting the Xen side of things into the current save-
>> and-restore model the native xor code uses. It would only be strait
>> forward to implement on the legacy, forward ported trees.
>> 
>> However, with the #NM handler in pv-ops apparently not
>> leveraging the fact that CR0.TS is already cleared for it on entry,
>> maybe this could indeed be introduced together. Konrad?
> 
> Would this require an extra pvops call from the #NM handler?

Or we wrap the #NM handler (somehow?) and clear the per-cpu cr0.ts software
flag before calling into the generic #NM handler.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 18 22:36:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Jun 2012 22:36: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 1SgkY7-0002Gp-AB; Mon, 18 Jun 2012 22:35:55 +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 1SgkY6-0002Gk-Bf
	for xen-devel@lists.xen.org; Mon, 18 Jun 2012 22:35:54 +0000
Received: from [85.158.139.83:41422] by server-3.bemta-5.messagelabs.com id
	E8/48-03367-94DAFDF4; Mon, 18 Jun 2012 22:35:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340058951!28214097!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32581 invoked from network); 18 Jun 2012 22:35:51 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jun 2012 22:35:51 -0000
Received: by wgbed3 with SMTP id ed3so4138478wgb.32
	for <xen-devel@lists.xen.org>; Mon, 18 Jun 2012 15:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jwA1kXOaiVd0LgeHhaoyQgvlDBi9LyugiLIBWL79s2s=;
	b=wO+gdl/Atv12Uu+g7lWV/OVJjHQ3HiZ3Hy11wAGFjL6z+0hDh0lOMBXlh4eLTIC09B
	XQbrc/cZQmYayZDwyyB+dy++zibh21E+nzB7QPkxHPOnTObNQv/mQ+Wv3SGdqvb2ewR4
	yKXNaRPOJWdSGxVNbd368lHWvQ9biRmHDJcRensvIScPMWaHAH8YSAc5eWQjE73YHJnR
	Ig+3ueOu4ouJ2uEnk8BNoChY0ig90RzoMLxfuUe+S/uaK+BLCjGGRvjCHuveZU+0OKoe
	jTFCGIlgiPsfUykSJiZakJctyHg3XMq9I8yXpqaP1Ohn+wjhBPgIaZTD3XkJnI4wkP0P
	ne7w==
Received: by 10.216.145.97 with SMTP id o75mr9005694wej.7.1340058947813;
	Mon, 18 Jun 2012 15:35:47 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id e20sm28296401wiv.7.2012.06.18.15.35.46
	(version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 15:35:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 18 Jun 2012 23:35:43 +0100
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC056BCF.4321A%keir@xen.org>
Thread-Topic: [Xen-devel] fpu_taskswitch adjustment proposal
Thread-Index: Ac1NorIASNJZUgrjfkCgkFXGWYarrg==
In-Reply-To: <20120618182450.GF24750@phenom.dumpdata.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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 18/06/2012 19:24, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:

>>> It should be possible for the guest kernel to track its CR0.TS setting
>>> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
> 
> Hm, the clts() paravirt could take advantage of the per-cpu cr0 to
> figure out whether it truly needs to do anything.

Exactly.

>>> cleared on #NM.
>> Sure, but selling this to the Linux maintainers I would expect to be
>> harder than fitting the Xen side of things into the current save-
>> and-restore model the native xor code uses. It would only be strait
>> forward to implement on the legacy, forward ported trees.
>> 
>> However, with the #NM handler in pv-ops apparently not
>> leveraging the fact that CR0.TS is already cleared for it on entry,
>> maybe this could indeed be introduced together. Konrad?
> 
> Would this require an extra pvops call from the #NM handler?

Or we wrap the #NM handler (somehow?) and clear the per-cpu cr0.ts software
flag before calling into the generic #NM handler.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrur-0001RM-Bs; Tue, 19 Jun 2012 06:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1Sgruq-0001RB-3O
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:52 +0000
Received: from [85.158.143.99:60669] by server-3.bemta-4.messagelabs.com id
	F9/64-05808-7EB10EF4; Tue, 19 Jun 2012 06:27:51 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340087269!27420977!2
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27155 invoked from network); 19 Jun 2012 06:27:51 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Jun 2012 06:27:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331945"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:48 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:23 +0800
Message-Id: <1340087306-6096-2-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: Add EPT A/D bits definitions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EPT A/D bits definitions.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/include/asm-x86/hvm/vmx/vmcs.h |    4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |    3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6100619..c0b9a44 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -62,7 +62,8 @@ struct vmx_domain {
         struct {
             u64 ept_mt :3,
                 ept_wl :3,
-                rsvd   :6,
+                ept_ad :1,
+                rsvd   :5,
                 asr    :52;
         };
         u64 eptp;
@@ -194,6 +195,7 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
 #define VMX_EPT_SUPERPAGE_2MB                   0x00010000
 #define VMX_EPT_SUPERPAGE_1GB                   0x00020000
 #define VMX_EPT_INVEPT_INSTRUCTION              0x00100000
+#define VMX_EPT_AD_BITS_SUPPORT                 0x00200000
 #define VMX_EPT_INVEPT_SINGLE_CONTEXT           0x02000000
 #define VMX_EPT_INVEPT_ALL_CONTEXT              0x04000000
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index accfa3f..416504f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -37,7 +37,8 @@ typedef union {
         emt         :   3,  /* bits 5:3 - EPT Memory type */
         ipat        :   1,  /* bit 6 - Ignore PAT memory type */
         sp          :   1,  /* bit 7 - Is this a superpage? */
-        rsvd1       :   2,  /* bits 9:8 - Reserved for future use */
+        a           :   1,  /* bit 8 - Access bit */
+        d           :   1,  /* bit 9 - Dirty bit */
         avail1      :   1,  /* bit 10 - Software available 1 */
         rsvd2_snp   :   1,  /* bit 11 - Used for VT-d snoop control
                                in shared EPT/VT-d usage */
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrur-0001RX-UR; Tue, 19 Jun 2012 06:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1Sgruq-0001RC-HF
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:52 +0000
Received: from [85.158.143.99:8993] by server-2.bemta-4.messagelabs.com id
	0D/BD-17938-7EB10EF4; Tue, 19 Jun 2012 06:27:51 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340087269!27420977!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27116 invoked from network); 19 Jun 2012 06:27:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Jun 2012 06:27:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331940"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:47 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:22 +0800
Message-Id: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
enable VMMs to efficiently implement memory management and page classification
algorithms to optimize VM memory operations.

This series of patches enable EPT dirty bit feature for guest live migration.

PATCH 1/4: Add EPT A/D bits definitions.

PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.

PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will 
only update the log dirty bitmap, but won't clear the EPT page dirty bit. 
The function is used by live migration peek round with EPT D bit supported.

PATCH 4/4: enable EPT dirty bit for guest live migration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrut-0001Rj-Aq; Tue, 19 Jun 2012 06:27:55 +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 1Sgrur-0001RL-FP
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:53 +0000
Received: from [193.109.254.147:65246] by server-2.bemta-14.messagelabs.com id
	39/C5-01735-8EB10EF4; Tue, 19 Jun 2012 06:27:52 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340087271!10359593!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31785 invoked from network); 19 Jun 2012 06:27:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 06:27:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331956"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:50 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:24 +0800
Message-Id: <1340087306-6096-3-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: add xen parameter to control A/D bits
	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>
MIME-Version: 1.0
Content-Type: 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 xen parameter to control A/D bits support, it on by default.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/hvm/vmx/vmcs.c       |    1 +
 xen/arch/x86/hvm/vmx/vmx.c        |    8 ++++++++
 xen/arch/x86/mm/p2m.c             |    3 +++
 xen/include/asm-x86/hap.h         |    3 +++
 xen/include/asm-x86/hvm/vmx/vmx.h |    3 +++
 5 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 38b5d03..5a6be4c 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -85,6 +85,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_virtualize_apic_accesses, "APIC MMIO access virtualisation");
     P(cpu_has_vmx_tpr_shadow, "APIC TPR shadow");
     P(cpu_has_vmx_ept, "Extended Page Tables (EPT)");
+    P(cpu_has_vmx_ept_ad_bits, "EPT A/D Bits");
     P(cpu_has_vmx_vpid, "Virtual-Processor Identifiers (VPID)");
     P(cpu_has_vmx_vnmi, "Virtual NMI");
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index ffb86c1..cb94226 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -37,6 +37,7 @@
 #include <asm/spinlock.h>
 #include <asm/paging.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/mem_sharing.h>
 #include <asm/hvm/emulate.h>
 #include <asm/hvm/hvm.h>
@@ -89,6 +90,10 @@ static int vmx_domain_initialise(struct domain *d)
     d->arch.hvm_domain.vmx.ept_control.asr  =
         pagetable_get_pfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
 
+    /* set EPT access and dirty bits support */
+    d->arch.hvm_domain.vmx.ept_control.ept_ad =
+        cpu_has_vmx_ept_ad_bits? 1 : 0;
+
     if ( !zalloc_cpumask_var(&d->arch.hvm_domain.vmx.ept_synced) )
         return -ENOMEM;
 
@@ -1574,6 +1579,9 @@ struct hvm_function_table * __init start_vmx(void)
         if ( cpu_has_vmx_ept_1gb )
             vmx_function_table.hap_capabilities |= HVM_HAP_SUPERPAGE_1GB;
 
+        if ( cpu_has_vmx_ept_ad_bits )
+            hap_has_access_bit = hap_has_dirty_bit = 1;
+
         setup_ept_dump();
     }
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3cdc417..0a796f3 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -46,6 +46,9 @@ boolean_param("hap_1gb", opt_hap_1gb);
 bool_t __read_mostly opt_hap_2mb = 1;
 boolean_param("hap_2mb", opt_hap_2mb);
 
+bool_t __read_mostly opt_hap_ad_bits = 1;
+boolean_param("hap_ad_bits", opt_hap_ad_bits);
+
 /* Printouts */
 #define P2M_PRINTK(_f, _a...)                                \
     debugtrace_printk("p2m: %s(): " _f, __func__, ##_a)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..00d0296 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 
+extern int hap_has_dirty_bit __read_mostly;
+extern int hap_has_access_bit __read_mostly;
+
 #endif /* XEN_HAP_H */
 
 /*
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index 416504f..f552d08 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -201,6 +201,9 @@ extern u64 vmx_ept_vpid_cap;
     (vmx_ept_vpid_cap & VMX_EPT_SUPERPAGE_2MB)
 #define cpu_has_vmx_ept_invept_single_context   \
     (vmx_ept_vpid_cap & VMX_EPT_INVEPT_SINGLE_CONTEXT)
+extern bool_t opt_hap_ad_bits;
+#define cpu_has_vmx_ept_ad_bits                 \
+    ( opt_hap_ad_bits ? (vmx_ept_vpid_cap & VMX_EPT_AD_BITS_SUPPORT) : 0 )
 
 #define EPT_2MB_SHIFT     16
 #define EPT_1GB_SHIFT     17
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgruv-0001SO-JF; Tue, 19 Jun 2012 06:27:57 +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 1Sgrut-0001Rn-R5
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:56 +0000
Received: from [193.109.254.147:59461] by server-1.bemta-14.messagelabs.com id
	D5/1F-24612-BEB10EF4; Tue, 19 Jun 2012 06:27:55 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340087271!10359593!3
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32114 invoked from network); 19 Jun 2012 06:27:54 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 06:27:54 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331973"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:52 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:26 +0800
Message-Id: <1340087306-6096-5-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] xen: enable EPT dirty bit for guest 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>
MIME-Version: 1.0
Content-Type: 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 p2m type is p2m_ram_logdirty, page should be read/write/execute(d) with EPT
dirty bit support.

When guest live migration with EPT dirty bit support, it does not trigger EPT
violation any longer, we flush dirty bitmap in ept_change_entry_type_page()
function, by walking the EPT page table.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/mm/p2m-ept.c |   50 ++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index f373905..e07004d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -24,6 +24,7 @@
 #include <asm/types.h>
 #include <asm/domain.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
 #include <xen/iommu.h>
@@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
                                                     entry->mfn);
             break;
         case p2m_ram_logdirty:
+            entry->w = hap_has_dirty_bit;
+            entry->r = entry->x = 1;
+            /* Not necessarily need to clear A bit, but it is safe anyway */
+            entry->a = entry->d = 0;
+            break;
         case p2m_ram_ro:
         case p2m_ram_shared:
             entry->r = entry->x = 1;
@@ -373,6 +379,9 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
                 need_modify_vtd_table = 0;
 
             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
+
+            if ( old_entry.d && (old_entry.sa_p2mt == p2m_ram_logdirty) )
+                paging_mark_dirty(d, mfn_x(mfn));
         }
 
         atomic_write_ept_entry(ept_entry, new_entry);
@@ -749,7 +758,8 @@ void ept_change_entry_emt_with_range(struct domain *d,
  * quickly enable or diable log-dirty tracking
  */
 static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
-                                       p2m_type_t ot, p2m_type_t nt)
+                                       p2m_type_t ot, p2m_type_t nt,
+                                       struct domain *d, int mask)
 {
     ept_entry_t e, *epte = map_domain_page(mfn_x(ept_page_mfn));
 
@@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
             ept_change_entry_type_page(_mfn(epte[i].mfn),
-                                       ept_page_level - 1, ot, nt);
+                                       ept_page_level - 1, ot, nt, d, mask);
         else
         {
             e = atomic_read_ept_entry(&epte[i]);
             if ( e.sa_p2mt != ot )
                 continue;
 
+            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
+            {
+                int j, nr_pages;
+                struct p2m_domain *p2m = p2m_get_hostp2m(d);
+                for ( j = 0, nr_pages = 1; j < ept_page_level;
+                      j++, nr_pages *= 512 ) {}
+                for ( j = 0; j < nr_pages; j++ )
+                    paging_mark_dirty(d, e.mfn + j);
+
+                /* split super page to 4k page, so that dirty bitmap can 
+                 * map the dirty page
+                 */
+                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
+                    continue;
+                atomic_write_ept_entry(&epte[i], e);
+            }
             e.sa_p2mt = nt;
             ept_p2m_type_to_flags(&e, nt, e.access);
+            if (!mask)
+                e.a = e.d = 0;
             atomic_write_ept_entry(&epte[i], e);
         }
     }
@@ -786,7 +814,22 @@ static void ept_change_entry_type_global(struct p2m_domain *p2m,
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
     BUG_ON(ot != nt && (ot == p2m_mmio_direct || nt == p2m_mmio_direct));
 
-    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d), ot, nt);
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, WALK_EPT_UNUSED);
+
+    ept_sync_domain(d);
+}
+
+static void ept_query_entry_global(struct p2m_domain *p2m, int mask)
+{
+    struct domain *d = p2m->domain;
+    p2m_type_t ot = p2m_ram_logdirty;
+    p2m_type_t nt = p2m_ram_logdirty;
+    if ( ept_get_asr(d) == 0 )
+        return;
+
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, mask);
 
     ept_sync_domain(d);
 }
@@ -796,6 +839,7 @@ void ept_p2m_init(struct p2m_domain *p2m)
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->query_entry_global = ept_query_entry_global;
     p2m->audit_p2m = NULL;
 }
 
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrut-0001Rr-Ps; Tue, 19 Jun 2012 06:27:55 +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 1Sgrus-0001Rd-MY
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:55 +0000
Received: from [193.109.254.147:59385] by server-9.bemta-14.messagelabs.com id
	9D/4B-07693-9EB10EF4; Tue, 19 Jun 2012 06:27:53 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340087271!10359593!2
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31800 invoked from network); 19 Jun 2012 06:27:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 06:27:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331964"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:51 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:25 +0800
Message-Id: <1340087306-6096-4-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: introduce new function
	update_dirty_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>
MIME-Version: 1.0
Content-Type: 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 log_dirty new function update_dirty_bitmap, which will only update the
log dirty bitmap, but won't clear the EPT page dirty bit. The function is used
by live migration peek round with EPT D bit supported.

Set correct p2m type when EPT dirty bit supported.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan<haitao.shan@intel.com>
---
 xen/arch/x86/mm/hap/hap.c       |   36 +++++++++++++++++++++++++++++++-----
 xen/arch/x86/mm/p2m-pt.c        |    1 +
 xen/arch/x86/mm/p2m.c           |    8 ++++++++
 xen/arch/x86/mm/paging.c        |   32 +++++++++++++++++++-------------
 xen/arch/x86/mm/shadow/common.c |    2 +-
 xen/include/asm-x86/domain.h    |    1 +
 xen/include/asm-x86/hap.h       |    3 +++
 xen/include/asm-x86/p2m.h       |    5 ++++-
 xen/include/asm-x86/paging.h    |    3 ++-
 9 files changed, 70 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 13b4be2..3839273 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -52,6 +52,10 @@
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
+/* Define whether HW has access and dirty bits seperately */
+int hap_has_dirty_bit __read_mostly = 0;
+int hap_has_access_bit __read_mostly = 0;
+
 /************************************************/
 /*          HAP VRAM TRACKING SUPPORT           */
 /************************************************/
@@ -72,6 +76,7 @@ static int hap_enable_vram_tracking(struct domain *d)
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
                           p2m_ram_rw, p2m_ram_logdirty);
 
+    /* A TLB flush is needed no matter whether hap dirty bit is supported */
     flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
@@ -79,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain *d)
 static int hap_disable_vram_tracking(struct domain *d)
 {
     struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    p2m_type_t p2mt = p2m_ram_rw;
 
     if ( !dirty_vram )
         return -EINVAL;
 
+    /* With hap dirty bit, p2m type cannot be changed from p2m_ram_logdirty
+     * to p2m_ram_rw when first fault is met. Actually, there is no such
+     * fault occurred.
+     */
+    if ( hap_has_dirty_bit )
+        p2mt = p2m_ram_logdirty;
+
     paging_lock(d);
     d->arch.paging.mode &= ~PG_log_dirty;
     paging_unlock(d);
 
     /* set l1e entries of P2M table with normal mode */
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
+                          p2mt, p2m_ram_rw);
 
-    flush_tlb_mask(d->domain_dirty_cpumask);
+    /* With hap dirty bit, we actually did not change HW sensitive bits
+     * of the P2M tables.
+     */
+    if ( !hap_has_dirty_bit )
+        flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
 
@@ -113,7 +130,7 @@ static void hap_vram_tracking_init(struct domain *d)
 {
     paging_log_dirty_init(d, hap_enable_vram_tracking,
                           hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
+                          hap_clean_vram_tracking, NULL);
 }
 
 int hap_track_dirty_vram(struct domain *d,
@@ -216,8 +233,16 @@ static int hap_disable_log_dirty(struct domain *d)
 
 static void hap_clean_dirty_bitmap(struct domain *d)
 {
+    p2m_type_t p2mt = (hap_has_dirty_bit)? p2m_ram_logdirty : p2m_ram_rw;
     /* set l1e entries of P2M table to be read-only. */
-    p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
+    p2m_change_entry_type_global(d, p2mt, p2m_ram_logdirty);
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_update_dirty_bitmap(struct domain *d)
+{
+    /* find out dirty page by walking EPT table and update dirty bitmap. */
+    p2m_query_entry_global(d, WALK_EPT_D);
     flush_tlb_mask(d->domain_dirty_cpumask);
 }
 
@@ -234,7 +259,8 @@ void hap_logdirty_init(struct domain *d)
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
-                          hap_clean_dirty_bitmap);
+                          hap_clean_dirty_bitmap,
+                          hap_update_dirty_bitmap);
 }
 
 /************************************************/
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index c97cac4..7334167 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -1141,6 +1141,7 @@ void p2m_pt_init(struct p2m_domain *p2m)
     p2m->set_entry = p2m_set_entry;
     p2m->get_entry = p2m_gfn_to_mfn;
     p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->query_entry_global = NULL;
     p2m->write_p2m_entry = paging_write_p2m_entry;
 #if P2M_AUDIT
     p2m->audit_p2m = p2m_pt_audit_p2m;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 0a796f3..299f6b1 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain *d,
     p2m_unlock(p2m);
 }
 
+void p2m_query_entry_global(struct domain *d, int mask)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    ASSERT(p2m);
+    p2m_lock(p2m);
+    p2m->query_entry_global(p2m, mask);
+    p2m_unlock(p2m);
+}
+
 mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
                     unsigned int *page_order, bool_t locked)
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..12ee552 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     int i4, i3, i2;
 
     domain_pause(d);
-    paging_lock(d);
 
     clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
+    if ( clean )
+    {
+        /* We need to further call clean_dirty_bitmap() functions of specific
+         * paging modes (shadow or hap).  Safe because the domain is paused.
+         * And this call must be made before actually transferring the dirty
+         * bitmap since with HW hap dirty bit support, dirty bitmap is
+         * produced by hooking on this call. */
+        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    }
+
+    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
+    {
+        d->arch.paging.log_dirty.update_dirty_bitmap(d);
+    }
+
+    paging_lock(d);
 
     PAGING_DEBUG(LOGDIRTY, "log-dirty %s: dom %u faults=%u dirty=%u\n",
                  (clean) ? "clean" : "peek",
@@ -420,17 +435,6 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     if ( pages < sc->pages )
         sc->pages = pages;
 
-    paging_unlock(d);
-
-    if ( clean )
-    {
-        /* We need to further call clean_dirty_bitmap() functions of specific
-         * paging modes (shadow or hap).  Safe because the domain is paused. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
-    }
-    domain_unpause(d);
-    return rv;
-
  out:
     paging_unlock(d);
     domain_unpause(d);
@@ -600,11 +604,13 @@ int paging_log_dirty_range(struct domain *d,
 void paging_log_dirty_init(struct domain *d,
                            int    (*enable_log_dirty)(struct domain *d),
                            int    (*disable_log_dirty)(struct domain *d),
-                           void   (*clean_dirty_bitmap)(struct domain *d))
+                           void   (*clean_dirty_bitmap)(struct domain *d),
+                           void   (*update_dirty_bitmap)(struct domain *d))
 {
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
+    d->arch.paging.log_dirty.update_dirty_bitmap = update_dirty_bitmap;
 }
 
 /* This function fress log dirty bitmap resources. */
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index dc245be..f4e7566 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -50,7 +50,7 @@ void shadow_domain_init(struct domain *d, unsigned int domcr_flags)
 
     /* Use shadow pagetables for log-dirty support */
     paging_log_dirty_init(d, shadow_enable_log_dirty, 
-                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap);
+                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap, NULL);
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     d->arch.paging.shadow.oos_active = 0;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index aecee68..22cd0f9 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -179,6 +179,7 @@ struct log_dirty_domain {
     int            (*enable_log_dirty   )(struct domain *d);
     int            (*disable_log_dirty  )(struct domain *d);
     void           (*clean_dirty_bitmap )(struct domain *d);
+    void           (*update_dirty_bitmap )(struct domain *d);
 };
 
 struct paging_domain {
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index 00d0296..efd73cc 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -31,6 +31,9 @@
 #define HAP_ERROR(_f, _a...)                                          \
     printk("hap error: %s(): " _f, __func__, ##_a)
 
+#define WALK_EPT_UNUSED    0
+#define WALK_EPT_D         2
+
 /************************************************/
 /*          hap domain page mapping             */
 /************************************************/
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 63bc7cf..21ed9a5 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -249,7 +249,7 @@ struct p2m_domain {
     void               (*change_entry_type_global)(struct p2m_domain *p2m,
                                                    p2m_type_t ot,
                                                    p2m_type_t nt);
-    
+    void               (*query_entry_global)(struct p2m_domain *p2m, int mask);
     void               (*write_p2m_entry)(struct p2m_domain *p2m,
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
@@ -506,6 +506,9 @@ int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
 void p2m_change_entry_type_global(struct domain *d, 
                                   p2m_type_t ot, p2m_type_t nt);
 
+/* Query across all p2m entries in a domain */
+void p2m_query_entry_global(struct domain *d, int mask);
+
 /* Change types across a range of p2m entries (start ... end-1) */
 void p2m_change_type_range(struct domain *d, 
                            unsigned long start, unsigned long end,
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index c432a97..9d95e51 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -160,7 +160,8 @@ int paging_log_dirty_disable(struct domain *d);
 void paging_log_dirty_init(struct domain *d,
                            int  (*enable_log_dirty)(struct domain *d),
                            int  (*disable_log_dirty)(struct domain *d),
-                           void (*clean_dirty_bitmap)(struct domain *d));
+                           void (*clean_dirty_bitmap)(struct domain *d),
+                           void (*update_dirty_bitmap)(struct domain *d));
 
 /* mark a page as dirty */
 void paging_mark_dirty(struct domain *d, unsigned long guest_mfn);
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrur-0001RX-UR; Tue, 19 Jun 2012 06:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1Sgruq-0001RC-HF
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:52 +0000
Received: from [85.158.143.99:8993] by server-2.bemta-4.messagelabs.com id
	0D/BD-17938-7EB10EF4; Tue, 19 Jun 2012 06:27:51 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340087269!27420977!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27116 invoked from network); 19 Jun 2012 06:27:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Jun 2012 06:27:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331940"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:47 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:22 +0800
Message-Id: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
enable VMMs to efficiently implement memory management and page classification
algorithms to optimize VM memory operations.

This series of patches enable EPT dirty bit feature for guest live migration.

PATCH 1/4: Add EPT A/D bits definitions.

PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.

PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will 
only update the log dirty bitmap, but won't clear the EPT page dirty bit. 
The function is used by live migration peek round with EPT D bit supported.

PATCH 4/4: enable EPT dirty bit for guest live migration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgruv-0001SO-JF; Tue, 19 Jun 2012 06:27:57 +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 1Sgrut-0001Rn-R5
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:56 +0000
Received: from [193.109.254.147:59461] by server-1.bemta-14.messagelabs.com id
	D5/1F-24612-BEB10EF4; Tue, 19 Jun 2012 06:27:55 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340087271!10359593!3
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32114 invoked from network); 19 Jun 2012 06:27:54 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 06:27:54 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331973"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:52 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:26 +0800
Message-Id: <1340087306-6096-5-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] xen: enable EPT dirty bit for guest 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>
MIME-Version: 1.0
Content-Type: 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 p2m type is p2m_ram_logdirty, page should be read/write/execute(d) with EPT
dirty bit support.

When guest live migration with EPT dirty bit support, it does not trigger EPT
violation any longer, we flush dirty bitmap in ept_change_entry_type_page()
function, by walking the EPT page table.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/mm/p2m-ept.c |   50 ++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index f373905..e07004d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -24,6 +24,7 @@
 #include <asm/types.h>
 #include <asm/domain.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
 #include <xen/iommu.h>
@@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
                                                     entry->mfn);
             break;
         case p2m_ram_logdirty:
+            entry->w = hap_has_dirty_bit;
+            entry->r = entry->x = 1;
+            /* Not necessarily need to clear A bit, but it is safe anyway */
+            entry->a = entry->d = 0;
+            break;
         case p2m_ram_ro:
         case p2m_ram_shared:
             entry->r = entry->x = 1;
@@ -373,6 +379,9 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
                 need_modify_vtd_table = 0;
 
             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
+
+            if ( old_entry.d && (old_entry.sa_p2mt == p2m_ram_logdirty) )
+                paging_mark_dirty(d, mfn_x(mfn));
         }
 
         atomic_write_ept_entry(ept_entry, new_entry);
@@ -749,7 +758,8 @@ void ept_change_entry_emt_with_range(struct domain *d,
  * quickly enable or diable log-dirty tracking
  */
 static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
-                                       p2m_type_t ot, p2m_type_t nt)
+                                       p2m_type_t ot, p2m_type_t nt,
+                                       struct domain *d, int mask)
 {
     ept_entry_t e, *epte = map_domain_page(mfn_x(ept_page_mfn));
 
@@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
             ept_change_entry_type_page(_mfn(epte[i].mfn),
-                                       ept_page_level - 1, ot, nt);
+                                       ept_page_level - 1, ot, nt, d, mask);
         else
         {
             e = atomic_read_ept_entry(&epte[i]);
             if ( e.sa_p2mt != ot )
                 continue;
 
+            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
+            {
+                int j, nr_pages;
+                struct p2m_domain *p2m = p2m_get_hostp2m(d);
+                for ( j = 0, nr_pages = 1; j < ept_page_level;
+                      j++, nr_pages *= 512 ) {}
+                for ( j = 0; j < nr_pages; j++ )
+                    paging_mark_dirty(d, e.mfn + j);
+
+                /* split super page to 4k page, so that dirty bitmap can 
+                 * map the dirty page
+                 */
+                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
+                    continue;
+                atomic_write_ept_entry(&epte[i], e);
+            }
             e.sa_p2mt = nt;
             ept_p2m_type_to_flags(&e, nt, e.access);
+            if (!mask)
+                e.a = e.d = 0;
             atomic_write_ept_entry(&epte[i], e);
         }
     }
@@ -786,7 +814,22 @@ static void ept_change_entry_type_global(struct p2m_domain *p2m,
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
     BUG_ON(ot != nt && (ot == p2m_mmio_direct || nt == p2m_mmio_direct));
 
-    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d), ot, nt);
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, WALK_EPT_UNUSED);
+
+    ept_sync_domain(d);
+}
+
+static void ept_query_entry_global(struct p2m_domain *p2m, int mask)
+{
+    struct domain *d = p2m->domain;
+    p2m_type_t ot = p2m_ram_logdirty;
+    p2m_type_t nt = p2m_ram_logdirty;
+    if ( ept_get_asr(d) == 0 )
+        return;
+
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, mask);
 
     ept_sync_domain(d);
 }
@@ -796,6 +839,7 @@ void ept_p2m_init(struct p2m_domain *p2m)
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->query_entry_global = ept_query_entry_global;
     p2m->audit_p2m = NULL;
 }
 
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrut-0001Rj-Aq; Tue, 19 Jun 2012 06:27:55 +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 1Sgrur-0001RL-FP
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:53 +0000
Received: from [193.109.254.147:65246] by server-2.bemta-14.messagelabs.com id
	39/C5-01735-8EB10EF4; Tue, 19 Jun 2012 06:27:52 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340087271!10359593!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31785 invoked from network); 19 Jun 2012 06:27:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 06:27:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331956"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:50 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:24 +0800
Message-Id: <1340087306-6096-3-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: add xen parameter to control A/D bits
	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>
MIME-Version: 1.0
Content-Type: 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 xen parameter to control A/D bits support, it on by default.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/hvm/vmx/vmcs.c       |    1 +
 xen/arch/x86/hvm/vmx/vmx.c        |    8 ++++++++
 xen/arch/x86/mm/p2m.c             |    3 +++
 xen/include/asm-x86/hap.h         |    3 +++
 xen/include/asm-x86/hvm/vmx/vmx.h |    3 +++
 5 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 38b5d03..5a6be4c 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -85,6 +85,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_virtualize_apic_accesses, "APIC MMIO access virtualisation");
     P(cpu_has_vmx_tpr_shadow, "APIC TPR shadow");
     P(cpu_has_vmx_ept, "Extended Page Tables (EPT)");
+    P(cpu_has_vmx_ept_ad_bits, "EPT A/D Bits");
     P(cpu_has_vmx_vpid, "Virtual-Processor Identifiers (VPID)");
     P(cpu_has_vmx_vnmi, "Virtual NMI");
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index ffb86c1..cb94226 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -37,6 +37,7 @@
 #include <asm/spinlock.h>
 #include <asm/paging.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/mem_sharing.h>
 #include <asm/hvm/emulate.h>
 #include <asm/hvm/hvm.h>
@@ -89,6 +90,10 @@ static int vmx_domain_initialise(struct domain *d)
     d->arch.hvm_domain.vmx.ept_control.asr  =
         pagetable_get_pfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
 
+    /* set EPT access and dirty bits support */
+    d->arch.hvm_domain.vmx.ept_control.ept_ad =
+        cpu_has_vmx_ept_ad_bits? 1 : 0;
+
     if ( !zalloc_cpumask_var(&d->arch.hvm_domain.vmx.ept_synced) )
         return -ENOMEM;
 
@@ -1574,6 +1579,9 @@ struct hvm_function_table * __init start_vmx(void)
         if ( cpu_has_vmx_ept_1gb )
             vmx_function_table.hap_capabilities |= HVM_HAP_SUPERPAGE_1GB;
 
+        if ( cpu_has_vmx_ept_ad_bits )
+            hap_has_access_bit = hap_has_dirty_bit = 1;
+
         setup_ept_dump();
     }
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3cdc417..0a796f3 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -46,6 +46,9 @@ boolean_param("hap_1gb", opt_hap_1gb);
 bool_t __read_mostly opt_hap_2mb = 1;
 boolean_param("hap_2mb", opt_hap_2mb);
 
+bool_t __read_mostly opt_hap_ad_bits = 1;
+boolean_param("hap_ad_bits", opt_hap_ad_bits);
+
 /* Printouts */
 #define P2M_PRINTK(_f, _a...)                                \
     debugtrace_printk("p2m: %s(): " _f, __func__, ##_a)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..00d0296 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 
+extern int hap_has_dirty_bit __read_mostly;
+extern int hap_has_access_bit __read_mostly;
+
 #endif /* XEN_HAP_H */
 
 /*
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index 416504f..f552d08 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -201,6 +201,9 @@ extern u64 vmx_ept_vpid_cap;
     (vmx_ept_vpid_cap & VMX_EPT_SUPERPAGE_2MB)
 #define cpu_has_vmx_ept_invept_single_context   \
     (vmx_ept_vpid_cap & VMX_EPT_INVEPT_SINGLE_CONTEXT)
+extern bool_t opt_hap_ad_bits;
+#define cpu_has_vmx_ept_ad_bits                 \
+    ( opt_hap_ad_bits ? (vmx_ept_vpid_cap & VMX_EPT_AD_BITS_SUPPORT) : 0 )
 
 #define EPT_2MB_SHIFT     16
 #define EPT_1GB_SHIFT     17
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrut-0001Rr-Ps; Tue, 19 Jun 2012 06:27:55 +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 1Sgrus-0001Rd-MY
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:55 +0000
Received: from [193.109.254.147:59385] by server-9.bemta-14.messagelabs.com id
	9D/4B-07693-9EB10EF4; Tue, 19 Jun 2012 06:27:53 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340087271!10359593!2
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31800 invoked from network); 19 Jun 2012 06:27:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 06:27:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331964"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:51 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:25 +0800
Message-Id: <1340087306-6096-4-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: introduce new function
	update_dirty_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>
MIME-Version: 1.0
Content-Type: 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 log_dirty new function update_dirty_bitmap, which will only update the
log dirty bitmap, but won't clear the EPT page dirty bit. The function is used
by live migration peek round with EPT D bit supported.

Set correct p2m type when EPT dirty bit supported.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan<haitao.shan@intel.com>
---
 xen/arch/x86/mm/hap/hap.c       |   36 +++++++++++++++++++++++++++++++-----
 xen/arch/x86/mm/p2m-pt.c        |    1 +
 xen/arch/x86/mm/p2m.c           |    8 ++++++++
 xen/arch/x86/mm/paging.c        |   32 +++++++++++++++++++-------------
 xen/arch/x86/mm/shadow/common.c |    2 +-
 xen/include/asm-x86/domain.h    |    1 +
 xen/include/asm-x86/hap.h       |    3 +++
 xen/include/asm-x86/p2m.h       |    5 ++++-
 xen/include/asm-x86/paging.h    |    3 ++-
 9 files changed, 70 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 13b4be2..3839273 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -52,6 +52,10 @@
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
+/* Define whether HW has access and dirty bits seperately */
+int hap_has_dirty_bit __read_mostly = 0;
+int hap_has_access_bit __read_mostly = 0;
+
 /************************************************/
 /*          HAP VRAM TRACKING SUPPORT           */
 /************************************************/
@@ -72,6 +76,7 @@ static int hap_enable_vram_tracking(struct domain *d)
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
                           p2m_ram_rw, p2m_ram_logdirty);
 
+    /* A TLB flush is needed no matter whether hap dirty bit is supported */
     flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
@@ -79,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain *d)
 static int hap_disable_vram_tracking(struct domain *d)
 {
     struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    p2m_type_t p2mt = p2m_ram_rw;
 
     if ( !dirty_vram )
         return -EINVAL;
 
+    /* With hap dirty bit, p2m type cannot be changed from p2m_ram_logdirty
+     * to p2m_ram_rw when first fault is met. Actually, there is no such
+     * fault occurred.
+     */
+    if ( hap_has_dirty_bit )
+        p2mt = p2m_ram_logdirty;
+
     paging_lock(d);
     d->arch.paging.mode &= ~PG_log_dirty;
     paging_unlock(d);
 
     /* set l1e entries of P2M table with normal mode */
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
+                          p2mt, p2m_ram_rw);
 
-    flush_tlb_mask(d->domain_dirty_cpumask);
+    /* With hap dirty bit, we actually did not change HW sensitive bits
+     * of the P2M tables.
+     */
+    if ( !hap_has_dirty_bit )
+        flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
 
@@ -113,7 +130,7 @@ static void hap_vram_tracking_init(struct domain *d)
 {
     paging_log_dirty_init(d, hap_enable_vram_tracking,
                           hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
+                          hap_clean_vram_tracking, NULL);
 }
 
 int hap_track_dirty_vram(struct domain *d,
@@ -216,8 +233,16 @@ static int hap_disable_log_dirty(struct domain *d)
 
 static void hap_clean_dirty_bitmap(struct domain *d)
 {
+    p2m_type_t p2mt = (hap_has_dirty_bit)? p2m_ram_logdirty : p2m_ram_rw;
     /* set l1e entries of P2M table to be read-only. */
-    p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
+    p2m_change_entry_type_global(d, p2mt, p2m_ram_logdirty);
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_update_dirty_bitmap(struct domain *d)
+{
+    /* find out dirty page by walking EPT table and update dirty bitmap. */
+    p2m_query_entry_global(d, WALK_EPT_D);
     flush_tlb_mask(d->domain_dirty_cpumask);
 }
 
@@ -234,7 +259,8 @@ void hap_logdirty_init(struct domain *d)
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
-                          hap_clean_dirty_bitmap);
+                          hap_clean_dirty_bitmap,
+                          hap_update_dirty_bitmap);
 }
 
 /************************************************/
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index c97cac4..7334167 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -1141,6 +1141,7 @@ void p2m_pt_init(struct p2m_domain *p2m)
     p2m->set_entry = p2m_set_entry;
     p2m->get_entry = p2m_gfn_to_mfn;
     p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->query_entry_global = NULL;
     p2m->write_p2m_entry = paging_write_p2m_entry;
 #if P2M_AUDIT
     p2m->audit_p2m = p2m_pt_audit_p2m;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 0a796f3..299f6b1 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain *d,
     p2m_unlock(p2m);
 }
 
+void p2m_query_entry_global(struct domain *d, int mask)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    ASSERT(p2m);
+    p2m_lock(p2m);
+    p2m->query_entry_global(p2m, mask);
+    p2m_unlock(p2m);
+}
+
 mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
                     unsigned int *page_order, bool_t locked)
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..12ee552 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     int i4, i3, i2;
 
     domain_pause(d);
-    paging_lock(d);
 
     clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
+    if ( clean )
+    {
+        /* We need to further call clean_dirty_bitmap() functions of specific
+         * paging modes (shadow or hap).  Safe because the domain is paused.
+         * And this call must be made before actually transferring the dirty
+         * bitmap since with HW hap dirty bit support, dirty bitmap is
+         * produced by hooking on this call. */
+        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    }
+
+    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
+    {
+        d->arch.paging.log_dirty.update_dirty_bitmap(d);
+    }
+
+    paging_lock(d);
 
     PAGING_DEBUG(LOGDIRTY, "log-dirty %s: dom %u faults=%u dirty=%u\n",
                  (clean) ? "clean" : "peek",
@@ -420,17 +435,6 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     if ( pages < sc->pages )
         sc->pages = pages;
 
-    paging_unlock(d);
-
-    if ( clean )
-    {
-        /* We need to further call clean_dirty_bitmap() functions of specific
-         * paging modes (shadow or hap).  Safe because the domain is paused. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
-    }
-    domain_unpause(d);
-    return rv;
-
  out:
     paging_unlock(d);
     domain_unpause(d);
@@ -600,11 +604,13 @@ int paging_log_dirty_range(struct domain *d,
 void paging_log_dirty_init(struct domain *d,
                            int    (*enable_log_dirty)(struct domain *d),
                            int    (*disable_log_dirty)(struct domain *d),
-                           void   (*clean_dirty_bitmap)(struct domain *d))
+                           void   (*clean_dirty_bitmap)(struct domain *d),
+                           void   (*update_dirty_bitmap)(struct domain *d))
 {
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
+    d->arch.paging.log_dirty.update_dirty_bitmap = update_dirty_bitmap;
 }
 
 /* This function fress log dirty bitmap resources. */
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index dc245be..f4e7566 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -50,7 +50,7 @@ void shadow_domain_init(struct domain *d, unsigned int domcr_flags)
 
     /* Use shadow pagetables for log-dirty support */
     paging_log_dirty_init(d, shadow_enable_log_dirty, 
-                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap);
+                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap, NULL);
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     d->arch.paging.shadow.oos_active = 0;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index aecee68..22cd0f9 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -179,6 +179,7 @@ struct log_dirty_domain {
     int            (*enable_log_dirty   )(struct domain *d);
     int            (*disable_log_dirty  )(struct domain *d);
     void           (*clean_dirty_bitmap )(struct domain *d);
+    void           (*update_dirty_bitmap )(struct domain *d);
 };
 
 struct paging_domain {
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index 00d0296..efd73cc 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -31,6 +31,9 @@
 #define HAP_ERROR(_f, _a...)                                          \
     printk("hap error: %s(): " _f, __func__, ##_a)
 
+#define WALK_EPT_UNUSED    0
+#define WALK_EPT_D         2
+
 /************************************************/
 /*          hap domain page mapping             */
 /************************************************/
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 63bc7cf..21ed9a5 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -249,7 +249,7 @@ struct p2m_domain {
     void               (*change_entry_type_global)(struct p2m_domain *p2m,
                                                    p2m_type_t ot,
                                                    p2m_type_t nt);
-    
+    void               (*query_entry_global)(struct p2m_domain *p2m, int mask);
     void               (*write_p2m_entry)(struct p2m_domain *p2m,
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
@@ -506,6 +506,9 @@ int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
 void p2m_change_entry_type_global(struct domain *d, 
                                   p2m_type_t ot, p2m_type_t nt);
 
+/* Query across all p2m entries in a domain */
+void p2m_query_entry_global(struct domain *d, int mask);
+
 /* Change types across a range of p2m entries (start ... end-1) */
 void p2m_change_type_range(struct domain *d, 
                            unsigned long start, unsigned long end,
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index c432a97..9d95e51 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -160,7 +160,8 @@ int paging_log_dirty_disable(struct domain *d);
 void paging_log_dirty_init(struct domain *d,
                            int  (*enable_log_dirty)(struct domain *d),
                            int  (*disable_log_dirty)(struct domain *d),
-                           void (*clean_dirty_bitmap)(struct domain *d));
+                           void (*clean_dirty_bitmap)(struct domain *d),
+                           void (*update_dirty_bitmap)(struct domain *d));
 
 /* mark a page as dirty */
 void paging_mark_dirty(struct domain *d, unsigned long guest_mfn);
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 06:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 06: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 1Sgrur-0001RM-Bs; Tue, 19 Jun 2012 06:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1Sgruq-0001RB-3O
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 06:27:52 +0000
Received: from [85.158.143.99:60669] by server-3.bemta-4.messagelabs.com id
	F9/64-05808-7EB10EF4; Tue, 19 Jun 2012 06:27:51 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340087269!27420977!2
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI3OTcyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27155 invoked from network); 19 Jun 2012 06:27:51 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Jun 2012 06:27:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2012 23:27:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167331945"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2012 23:27:48 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 19 Jun 2012 14:28:23 +0800
Message-Id: <1340087306-6096-2-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
Cc: Haitao Shan <haitao.shan@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	keir@xen.org, xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: Add EPT A/D bits definitions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EPT A/D bits definitions.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/include/asm-x86/hvm/vmx/vmcs.h |    4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |    3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6100619..c0b9a44 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -62,7 +62,8 @@ struct vmx_domain {
         struct {
             u64 ept_mt :3,
                 ept_wl :3,
-                rsvd   :6,
+                ept_ad :1,
+                rsvd   :5,
                 asr    :52;
         };
         u64 eptp;
@@ -194,6 +195,7 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
 #define VMX_EPT_SUPERPAGE_2MB                   0x00010000
 #define VMX_EPT_SUPERPAGE_1GB                   0x00020000
 #define VMX_EPT_INVEPT_INSTRUCTION              0x00100000
+#define VMX_EPT_AD_BITS_SUPPORT                 0x00200000
 #define VMX_EPT_INVEPT_SINGLE_CONTEXT           0x02000000
 #define VMX_EPT_INVEPT_ALL_CONTEXT              0x04000000
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index accfa3f..416504f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -37,7 +37,8 @@ typedef union {
         emt         :   3,  /* bits 5:3 - EPT Memory type */
         ipat        :   1,  /* bit 6 - Ignore PAT memory type */
         sp          :   1,  /* bit 7 - Is this a superpage? */
-        rsvd1       :   2,  /* bits 9:8 - Reserved for future use */
+        a           :   1,  /* bit 8 - Access bit */
+        d           :   1,  /* bit 9 - Dirty bit */
         avail1      :   1,  /* bit 10 - Software available 1 */
         rsvd2_snp   :   1,  /* bit 11 - Used for VT-d snoop control
                                in shared EPT/VT-d usage */
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 08:36:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 08:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgtv4-00049N-AA; Tue, 19 Jun 2012 08:36:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1Sgtv3-00049I-Et
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 08:36:13 +0000
Received: from [193.109.254.147:40534] by server-9.bemta-14.messagelabs.com id
	DD/BA-07693-CF930EF4; Tue, 19 Jun 2012 08:36:12 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340094958!3593948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29912 invoked from network); 19 Jun 2012 08:35:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 08:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208";a="13094052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 08:35:58 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 19 Jun 2012
	09:35:58 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Mohammad Hedayati <hedayati.mo@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 19 Jun 2012 09:35:54 +0100
Thread-Topic: [Xen-devel] fsimage - no such file
Thread-Index: Ac1NoW3ydDyVL5uHTO6rNoXLqIB4gAAUv2Lg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
In-Reply-To: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@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] fsimage - no such 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

I have the same problem on xen-unstable 54c8c9eaee92+. I think libfsimage comes with xen (in my repo it's under ./tools/libfsimage). I've investigated a bit and found that in my occasion libfsimage tries to access directory /usr/lib64/fs which doesn't exist, whereas /usr/lib/fs does. I linked /usr/lib64/fs to /usr/lib/fs but then I got other problems, don't remember what. I don't know if this has to do with the fact that my dom0 is 64bit (Debian unstable), or that the domU is 64bit (Debian unstable again), or both.

-----Original Message-----
From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Mohammad Hedayati
Sent: 18 June 2012 23:24
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] fsimage - no such file

I am having a problem with pygrub of the current (rev 25467) xen-unstable pygrub in Ubuntu 12.04. pygrub can not read any image. I have traced the python code and found the problem being in fsimage.open(file, offset, bootfsoptions). It raises IOError "no such file or directory". I even wrote the following code and got the same error.

#!/usr/bin/python
import fsimage

print "Hello, World!"
try:
    fs = fsimage.open("/root/guest/mini.iso", 0, "") except Exception as e:
    print "Exception ", e

It seems that libfsimage has a problem with current version of Ubuntu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/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 Jun 19 08:36:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 08:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sgtv4-00049N-AA; Tue, 19 Jun 2012 08:36:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1Sgtv3-00049I-Et
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 08:36:13 +0000
Received: from [193.109.254.147:40534] by server-9.bemta-14.messagelabs.com id
	DD/BA-07693-CF930EF4; Tue, 19 Jun 2012 08:36:12 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340094958!3593948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDExMzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29912 invoked from network); 19 Jun 2012 08:35:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 08:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208";a="13094052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 08:35:58 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 19 Jun 2012
	09:35:58 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Mohammad Hedayati <hedayati.mo@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 19 Jun 2012 09:35:54 +0100
Thread-Topic: [Xen-devel] fsimage - no such file
Thread-Index: Ac1NoW3ydDyVL5uHTO6rNoXLqIB4gAAUv2Lg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
In-Reply-To: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@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] fsimage - no such 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

I have the same problem on xen-unstable 54c8c9eaee92+. I think libfsimage comes with xen (in my repo it's under ./tools/libfsimage). I've investigated a bit and found that in my occasion libfsimage tries to access directory /usr/lib64/fs which doesn't exist, whereas /usr/lib/fs does. I linked /usr/lib64/fs to /usr/lib/fs but then I got other problems, don't remember what. I don't know if this has to do with the fact that my dom0 is 64bit (Debian unstable), or that the domU is 64bit (Debian unstable again), or both.

-----Original Message-----
From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Mohammad Hedayati
Sent: 18 June 2012 23:24
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] fsimage - no such file

I am having a problem with pygrub of the current (rev 25467) xen-unstable pygrub in Ubuntu 12.04. pygrub can not read any image. I have traced the python code and found the problem being in fsimage.open(file, offset, bootfsoptions). It raises IOError "no such file or directory". I even wrote the following code and got the same error.

#!/usr/bin/python
import fsimage

print "Hello, World!"
try:
    fs = fsimage.open("/root/guest/mini.iso", 0, "") except Exception as e:
    print "Exception ", e

It seems that libfsimage has a problem with current version of Ubuntu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/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 Jun 19 09:11:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09:11:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SguSI-0004Us-8f; Tue, 19 Jun 2012 09:10:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SguSH-0004Un-6V
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 09:10:33 +0000
Received: from [193.109.254.147:27405] by server-7.bemta-14.messagelabs.com id
	6E/69-29827-80240EF4; Tue, 19 Jun 2012 09:10:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340097024!8013872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23934 invoked from network); 19 Jun 2012 09:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 09:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13095075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 09:09:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 10:09:50 +0100
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 1SguRa-0003Eh-IK;
	Tue, 19 Jun 2012 09:09:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SguRa-0006dM-AF;
	Tue, 19 Jun 2012 10:09:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13088-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 10:09:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13088: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13088 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13088/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b6a857411ba
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:11:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09:11:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SguSI-0004Us-8f; Tue, 19 Jun 2012 09:10:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SguSH-0004Un-6V
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 09:10:33 +0000
Received: from [193.109.254.147:27405] by server-7.bemta-14.messagelabs.com id
	6E/69-29827-80240EF4; Tue, 19 Jun 2012 09:10:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340097024!8013872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23934 invoked from network); 19 Jun 2012 09:10:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 09:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13095075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 09:09:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 10:09:50 +0100
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 1SguRa-0003Eh-IK;
	Tue, 19 Jun 2012 09:09:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SguRa-0006dM-AF;
	Tue, 19 Jun 2012 10:09:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13088-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 10:09:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13088: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13088 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13088/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b6a857411ba
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgudM-0004gB-E8; Tue, 19 Jun 2012 09:22: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 1SgudL-0004g6-3q
	for Xen-devel@lists.xensource.com; Tue, 19 Jun 2012 09:21:59 +0000
Received: from [85.158.143.35:46061] by server-1.bemta-4.messagelabs.com id
	20/BC-24392-6B440EF4; Tue, 19 Jun 2012 09:21:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340097632!5947603!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32735 invoked from network); 19 Jun 2012 09:20:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	19 Jun 2012 09:20:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Jun 2012 10:20:31 +0100
Message-Id: <4FE060A9020000780008A915@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 19 Jun 2012 10:21:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120614184338.43fb879b@mantra.us.oracle.com>
	<alpine.DEB.2.02.1206151201150.14957@kaball.uk.xensource.com>
	<20120618183557.GA28050@phenom.dumpdata.com>
In-Reply-To: <20120618183557.GA28050@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 20:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Jun 15, 2012 at 12:02:19PM +0100, Stefano Stabellini wrote:
>> On Fri, 15 Jun 2012, Mukesh Rathor wrote:
>> > Hi guys,
>> > 
>> > During my refresh to latest linux, I noticed, direct mapping of all
>> > non-RAM pages in xen_set_identity_and_release(). I currently don't map
>> > all at front, but as needed looking at the PAGE_IO bit in the pte. One
> 
> PV doesn't look at that all the time either. The P2M tree code
> has a couple of leafs, that if they have IDENTITY_FRAME_BIT set it will
> automatically stick _PAGE_IOMAP on the PTE.
> 
>> > result of that is minor change to common code macro:
>> > 
>> >         __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
>> > to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)
> 
> I am really wafling on that. Jeremy posted a patch some time ago
> to x86 folks that would do something similar (I can't remember the
> details), but hpa said - why don't you just consult the E820.
> 
> That is where the IDENTITY_FRAME_BIT thing in the P2M tree came
> about. It could probably be implemented for your cases using ranges.
> 
> Similary to how Xen permits/disallows certain IO regions to be touched.
> Would something like that potentially allow you do something like this:
> 
> xen_hybrid_pte()
> 
> phys_addr_t phys = pte.pte & PTE_PFN_MASK
> 
> if (phys .. within ranges)
> 	pte |= _PAGE_IOMAP;
> return pte;
> 
>> >
>> > 
>> > To avoid this change, and keep all my changes limited to xen files only,
>> > I thought I could just map the entire non-ram pages up front too. But
>> > I am concerned the EPT may grow too large? Specially, when we get to 
>> > *really* large NUMA boxes. What do you guys think? Should I worry about
>> > it?
> 
> Would NUMA boxes have more than 1GB of E820 non-RAM regions? I can see them
> having gobs of RAM regions, but non-RAM regions?

There can be multi-terabyte-sized non-RAM regions on systems
with discontiguous RAM.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgudM-0004gB-E8; Tue, 19 Jun 2012 09:22: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 1SgudL-0004g6-3q
	for Xen-devel@lists.xensource.com; Tue, 19 Jun 2012 09:21:59 +0000
Received: from [85.158.143.35:46061] by server-1.bemta-4.messagelabs.com id
	20/BC-24392-6B440EF4; Tue, 19 Jun 2012 09:21:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340097632!5947603!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32735 invoked from network); 19 Jun 2012 09:20:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	19 Jun 2012 09:20:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Jun 2012 10:20:31 +0100
Message-Id: <4FE060A9020000780008A915@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 19 Jun 2012 10:21:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120614184338.43fb879b@mantra.us.oracle.com>
	<alpine.DEB.2.02.1206151201150.14957@kaball.uk.xensource.com>
	<20120618183557.GA28050@phenom.dumpdata.com>
In-Reply-To: <20120618183557.GA28050@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID] : mapping IO mems in the EPT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 20:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Jun 15, 2012 at 12:02:19PM +0100, Stefano Stabellini wrote:
>> On Fri, 15 Jun 2012, Mukesh Rathor wrote:
>> > Hi guys,
>> > 
>> > During my refresh to latest linux, I noticed, direct mapping of all
>> > non-RAM pages in xen_set_identity_and_release(). I currently don't map
>> > all at front, but as needed looking at the PAGE_IO bit in the pte. One
> 
> PV doesn't look at that all the time either. The P2M tree code
> has a couple of leafs, that if they have IDENTITY_FRAME_BIT set it will
> automatically stick _PAGE_IOMAP on the PTE.
> 
>> > result of that is minor change to common code macro:
>> > 
>> >         __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to
>> > to        __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)
> 
> I am really wafling on that. Jeremy posted a patch some time ago
> to x86 folks that would do something similar (I can't remember the
> details), but hpa said - why don't you just consult the E820.
> 
> That is where the IDENTITY_FRAME_BIT thing in the P2M tree came
> about. It could probably be implemented for your cases using ranges.
> 
> Similary to how Xen permits/disallows certain IO regions to be touched.
> Would something like that potentially allow you do something like this:
> 
> xen_hybrid_pte()
> 
> phys_addr_t phys = pte.pte & PTE_PFN_MASK
> 
> if (phys .. within ranges)
> 	pte |= _PAGE_IOMAP;
> return pte;
> 
>> >
>> > 
>> > To avoid this change, and keep all my changes limited to xen files only,
>> > I thought I could just map the entire non-ram pages up front too. But
>> > I am concerned the EPT may grow too large? Specially, when we get to 
>> > *really* large NUMA boxes. What do you guys think? Should I worry about
>> > it?
> 
> Would NUMA boxes have more than 1GB of E820 non-RAM regions? I can see them
> having gobs of RAM regions, but non-RAM regions?

There can be multi-terabyte-sized non-RAM regions on systems
with discontiguous RAM.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:43:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09: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 1Sguxu-0004w1-C8; Tue, 19 Jun 2012 09:43: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 1Sguxs-0004vr-Un
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:43:13 +0000
Received: from [85.158.143.35:20569] by server-2.bemta-4.messagelabs.com id
	64/01-17938-0B940EF4; Tue, 19 Jun 2012 09:43:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340098991!14464280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24623 invoked from network); 19 Jun 2012 09:43:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 09:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13096083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 09:43:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 10:43:11 +0100
Message-ID: <1340098989.16742.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 19 Jun 2012 10:43:09 +0100
In-Reply-To: <20120614084732.GA82539@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<20120607090334.GC70339@ocelot.phlegethon.org>
	<1339600416.24104.228.camel@zakaz.uk.xensource.com>
	<20120614084732.GA82539@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 09:47 +0100, Tim Deegan wrote:
> At 16:13 +0100 on 13 Jun (1339604016), Ian Campbell wrote:
> > Yes, that looks nice, although you still need a bit of a quirk for the
> > third level table bit. Patch below.
> 
> Much nicer.   One more round of nits below if you feel keen; in any case,
> Acked-by: Tim Deegan <tim@xen.org>

Thanks. Your nits were sensible so I have folded them in.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:43:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09: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 1Sguxu-0004w1-C8; Tue, 19 Jun 2012 09:43: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 1Sguxs-0004vr-Un
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:43:13 +0000
Received: from [85.158.143.35:20569] by server-2.bemta-4.messagelabs.com id
	64/01-17938-0B940EF4; Tue, 19 Jun 2012 09:43:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340098991!14464280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24623 invoked from network); 19 Jun 2012 09:43:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 09:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13096083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 09:43:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 10:43:11 +0100
Message-ID: <1340098989.16742.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 19 Jun 2012 10:43:09 +0100
In-Reply-To: <20120614084732.GA82539@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-11-git-send-email-ian.campbell@citrix.com>
	<20120607090334.GC70339@ocelot.phlegethon.org>
	<1339600416.24104.228.camel@zakaz.uk.xensource.com>
	<20120614084732.GA82539@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/38] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 09:47 +0100, Tim Deegan wrote:
> At 16:13 +0100 on 13 Jun (1339604016), Ian Campbell wrote:
> > Yes, that looks nice, although you still need a bit of a quirk for the
> > third level table bit. Patch below.
> 
> Much nicer.   One more round of nits below if you feel keen; in any case,
> Acked-by: Tim Deegan <tim@xen.org>

Thanks. Your nits were sensible so I have folded them in.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09: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 1Sguzq-00050c-Rx; Tue, 19 Jun 2012 09:45:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Sguzp-00050V-Vd
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:45:14 +0000
Received: from [193.109.254.147:27165] by server-6.bemta-14.messagelabs.com id
	95/73-08993-92A40EF4; Tue, 19 Jun 2012 09:45:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340099112!10517662!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18809 invoked from network); 19 Jun 2012 09:45:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 09:45:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Jun 2012 10:45:12 +0100
Message-Id: <4FE06671020000780008A946@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 19 Jun 2012 10:45:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
In-Reply-To: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.06.12 at 22:57, Rolu <rolu@roce.org> wrote:
> I have a HVM domU running Ubuntu 12.04. It has several PCI devices
> passed through to it (USB controllers, onboard sound, ATI video card
> with gfx_passthru 0). It has some issues, the most apparent one with
> the sound, which doesn't play normally but repeats the same short
> fragment over and over for a while until moving on to the next
> fragment. The Xen dmesg prints lots of lines like:
> 
> (XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3

Which indicates something wrong in the guest kernel or in the
translation layers (qemu, less likely the hypervisor itself). Valid
MSIs can't have a delivery mode of 3 (a reserved encoding).

> The number behind 108:d varies occasionally.

Yes, that number is bogus (has no guaranteed relation to the
target domain).

> Since vmsi.c seems to deal with passing on MSI interrupts, I tried
> booting the domU with pci=nomsi. This made things work and sound now
> plays normally. Not using MSI at all doesn't seem like a very good
> solution though.
> 
> What makes this happen, and can I fix it in a better way?

Unless this is in the guest kernel, we'll likely need a code fix here,
but for determining what and where, we'd need you to provide
the qemu log for the domain as well (there ought to be entries
starting with "Update msi with pirq", and the gflags value is of
particular interest). Depending on what we see, we may then
need you to do some further debugging.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09: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 1Sguzq-00050c-Rx; Tue, 19 Jun 2012 09:45:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Sguzp-00050V-Vd
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:45:14 +0000
Received: from [193.109.254.147:27165] by server-6.bemta-14.messagelabs.com id
	95/73-08993-92A40EF4; Tue, 19 Jun 2012 09:45:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340099112!10517662!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18809 invoked from network); 19 Jun 2012 09:45:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	19 Jun 2012 09:45:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Jun 2012 10:45:12 +0100
Message-Id: <4FE06671020000780008A946@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 19 Jun 2012 10:45:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
In-Reply-To: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.06.12 at 22:57, Rolu <rolu@roce.org> wrote:
> I have a HVM domU running Ubuntu 12.04. It has several PCI devices
> passed through to it (USB controllers, onboard sound, ATI video card
> with gfx_passthru 0). It has some issues, the most apparent one with
> the sound, which doesn't play normally but repeats the same short
> fragment over and over for a while until moving on to the next
> fragment. The Xen dmesg prints lots of lines like:
> 
> (XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3

Which indicates something wrong in the guest kernel or in the
translation layers (qemu, less likely the hypervisor itself). Valid
MSIs can't have a delivery mode of 3 (a reserved encoding).

> The number behind 108:d varies occasionally.

Yes, that number is bogus (has no guaranteed relation to the
target domain).

> Since vmsi.c seems to deal with passing on MSI interrupts, I tried
> booting the domU with pci=nomsi. This made things work and sound now
> plays normally. Not using MSI at all doesn't seem like a very good
> solution though.
> 
> What makes this happen, and can I fix it in a better way?

Unless this is in the guest kernel, we'll likely need a code fix here,
but for determining what and where, we'd need you to provide
the qemu log for the domain as well (there ought to be entries
starting with "Update msi with pirq", and the gflags value is of
particular interest). Depending on what we see, we may then
need you to do some further debugging.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:56:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09: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 1SgvAg-0005Ho-5g; Tue, 19 Jun 2012 09:56: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 1SgvAe-0005He-Im
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:56:24 +0000
Received: from [85.158.143.35:51103] by server-2.bemta-4.messagelabs.com id
	3A/FC-17938-7CC40EF4; Tue, 19 Jun 2012 09:56:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340099766!5096227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2629 invoked from network); 19 Jun 2012 09:56:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	19 Jun 2012 09:56:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Jun 2012 10:56:06 +0100
Message-Id: <4FE068FF020000780008A954@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 19 Jun 2012 10:56:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
	<1340087306-6096-3-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1340087306-6096-3-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, Haitao Shan <haitao.shan@intel.com>, xiantao.zhang@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen: add xen parameter to control A/D
 bits 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 19.06.12 at 08:28, Xudong Hao <xudong.hao@intel.com> wrote:
> @@ -1574,6 +1579,9 @@ struct hvm_function_table * __init start_vmx(void)
>          if ( cpu_has_vmx_ept_1gb )
>              vmx_function_table.hap_capabilities |= HVM_HAP_SUPERPAGE_1GB;
>  
> +        if ( cpu_has_vmx_ept_ad_bits )
> +            hap_has_access_bit = hap_has_dirty_bit = 1;

So you're using these flags here, ...

> +
>          setup_ept_dump();
>      }
>  
> --- a/xen/include/asm-x86/hap.h
> +++ b/xen/include/asm-x86/hap.h
> @@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
>  
>  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
>  
> +extern int hap_has_dirty_bit __read_mostly;
> +extern int hap_has_access_bit __read_mostly;

... and you're declaring them here, but I fail to find their definition.
How does the result of applying up to this patch build?

Also, they should clearly be bool_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 Jun 19 09:56:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09: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 1SgvAg-0005Ho-5g; Tue, 19 Jun 2012 09:56: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 1SgvAe-0005He-Im
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:56:24 +0000
Received: from [85.158.143.35:51103] by server-2.bemta-4.messagelabs.com id
	3A/FC-17938-7CC40EF4; Tue, 19 Jun 2012 09:56:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340099766!5096227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2629 invoked from network); 19 Jun 2012 09:56:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	19 Jun 2012 09:56:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Jun 2012 10:56:06 +0100
Message-Id: <4FE068FF020000780008A954@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 19 Jun 2012 10:56:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
	<1340087306-6096-3-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1340087306-6096-3-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, Haitao Shan <haitao.shan@intel.com>, xiantao.zhang@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen: add xen parameter to control A/D
 bits 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 19.06.12 at 08:28, Xudong Hao <xudong.hao@intel.com> wrote:
> @@ -1574,6 +1579,9 @@ struct hvm_function_table * __init start_vmx(void)
>          if ( cpu_has_vmx_ept_1gb )
>              vmx_function_table.hap_capabilities |= HVM_HAP_SUPERPAGE_1GB;
>  
> +        if ( cpu_has_vmx_ept_ad_bits )
> +            hap_has_access_bit = hap_has_dirty_bit = 1;

So you're using these flags here, ...

> +
>          setup_ept_dump();
>      }
>  
> --- a/xen/include/asm-x86/hap.h
> +++ b/xen/include/asm-x86/hap.h
> @@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
>  
>  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
>  
> +extern int hap_has_dirty_bit __read_mostly;
> +extern int hap_has_access_bit __read_mostly;

... and you're declaring them here, but I fail to find their definition.
How does the result of applying up to this patch build?

Also, they should clearly be bool_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 Jun 19 09:59:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09:59: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 1SgvDI-0005Nt-NR; Tue, 19 Jun 2012 09:59: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 1SgvDH-0005Nn-1F
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:59:07 +0000
Received: from [85.158.143.99:31252] by server-1.bemta-4.messagelabs.com id
	9E/80-24392-A6D40EF4; Tue, 19 Jun 2012 09:59:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340099945!22711245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15649 invoked from network); 19 Jun 2012 09:59:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 09:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13096546"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 09:59:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 10:59:05 +0100
Message-ID: <1340099943.16742.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Tue, 19 Jun 2012 10:59:03 +0100
In-Reply-To: <CAE+SDMwQSaDnatuj3uh9Se_E9LbzO8KKX5MNabwHVW2MkDGqFw@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
	<CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
	<1339491940.24104.8.camel@zakaz.uk.xensource.com>
	<CAE+SDMwQSaDnatuj3uh9Se_E9LbzO8KKX5MNabwHVW2MkDGqFw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 16:59 +0100, Zeinab Alebouyeh wrote:
> you means that if I use a function, &function_name gives me the
> physical address of function or the virtual address of function?

virtual.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 09:59:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 09:59: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 1SgvDI-0005Nt-NR; Tue, 19 Jun 2012 09:59: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 1SgvDH-0005Nn-1F
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 09:59:07 +0000
Received: from [85.158.143.99:31252] by server-1.bemta-4.messagelabs.com id
	9E/80-24392-A6D40EF4; Tue, 19 Jun 2012 09:59:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340099945!22711245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15649 invoked from network); 19 Jun 2012 09:59:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 09:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13096546"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 09:59:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 10:59:05 +0100
Message-ID: <1340099943.16742.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Zeinab Alebouyeh <z.alebouyeh@gmail.com>
Date: Tue, 19 Jun 2012 10:59:03 +0100
In-Reply-To: <CAE+SDMwQSaDnatuj3uh9Se_E9LbzO8KKX5MNabwHVW2MkDGqFw@mail.gmail.com>
References: <CAE+SDMxmX9ipiV4V8q2TbGKteT9m8qizLJXJLBBU-xuDSqLXww@mail.gmail.com>
	<1338975815.32319.40.camel@zakaz.uk.xensource.com>
	<CAE+SDMx=nW2Adk-2xepEvSgx2kfXxteNYBFEF8EYj8VUHh9Dgw@mail.gmail.com>
	<1339050679.6557.21.camel@dagon.hellion.org.uk>
	<CAE+SDMz1Yak4zSYiT1ow7QmxmbTghtd2oKjzCCAgVtn0RjZY1Q@mail.gmail.com>
	<1339491940.24104.8.camel@zakaz.uk.xensource.com>
	<CAE+SDMwQSaDnatuj3uh9Se_E9LbzO8KKX5MNabwHVW2MkDGqFw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Grab the physical address of a label
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 16:59 +0100, Zeinab Alebouyeh wrote:
> you means that if I use a function, &function_name gives me the
> physical address of function or the virtual address of function?

virtual.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 10:05:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 10: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 1SgvIt-0005gC-Ff; Tue, 19 Jun 2012 10:04: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 1SgvIs-0005g7-Rw
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 10:04:55 +0000
Received: from [193.109.254.147:11009] by server-2.bemta-14.messagelabs.com id
	E3/D3-01735-6CE40EF4; Tue, 19 Jun 2012 10:04:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340100281!10407063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5444 invoked from network); 19 Jun 2012 10:04:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 10:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13096744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 10:04:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 11:04:41 +0100
Message-ID: <1340100279.16742.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 11:04:39 +0100
In-Reply-To: <20442.706.194448.288137@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
	<20442.706.194448.288137@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 16:26 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> > On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > > Change the internal and external APIs for domain save (suspend) to be
> > > capable of asynchronous operation.  The implementation remains
> > > synchronous.  The interfaces surrounding device model saving are still
> > > synchronous.
> ...
> > >  * The `suspend_callback' function passed to libxl_domain_save is
> > >    never called by the existing implementation in libxl.  Abolish it.
> > 
> > Furthermore xl never passes one in either.
> 
> Right.  I will update the commit message to note this too.
> 
> > > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > A few minor comments below, but otherwise looks good to me.
> 
> Thanks...
> 
> > > +static void remus_crashed_cb(libxl__egc *egc,
> > > +                             libxl__domain_suspend_state *dss, int rc)
> > 
> > I'm not sure "crashed" is quite right here, it's finished for whatever
> > reason which may not necessarily be a crash (going forward it should
> > rarely be a crash, I think). It's "stopped" or "done" or something.
> 
> How about "remus_target_gone_cb" ?

Sounds fine to me, unless you want to work the word "failover" into it?

> > >  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
> > [...]
> > > @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> > > 
> > >  /*----- Domain suspend (save) functions -----*/
> > > 
> > > -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> > > -                                         libxl_domain_type type,
> > > -                                         int live, int debug,
> > > -                                         const libxl_domain_remus_info *r_info);
> > > +/* calls callback when done */
> > 
> > Which callback? dss->callback I guess.
> 
> What a confusing way to quote this.

Yes, sorry.

>   You're referring to this function
> of course:
> 
> > > +_hidden void libxl__domain_suspend(libxl__egc *egc,
> > > +                                   libxl__domain_suspend_state *dss);
> 
> Gripe gripe these comments before functions are inducing you to
> top-post !
> 
> Anyway, yes.  I will clarify this comment.

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 Jun 19 10:05:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 10: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 1SgvIt-0005gC-Ff; Tue, 19 Jun 2012 10:04: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 1SgvIs-0005g7-Rw
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 10:04:55 +0000
Received: from [193.109.254.147:11009] by server-2.bemta-14.messagelabs.com id
	E3/D3-01735-6CE40EF4; Tue, 19 Jun 2012 10:04:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340100281!10407063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5444 invoked from network); 19 Jun 2012 10:04:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 10:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13096744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 10:04:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 11:04:41 +0100
Message-ID: <1340100279.16742.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 11:04:39 +0100
In-Reply-To: <20442.706.194448.288137@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
	<20442.706.194448.288137@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 16:26 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> > On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > > Change the internal and external APIs for domain save (suspend) to be
> > > capable of asynchronous operation.  The implementation remains
> > > synchronous.  The interfaces surrounding device model saving are still
> > > synchronous.
> ...
> > >  * The `suspend_callback' function passed to libxl_domain_save is
> > >    never called by the existing implementation in libxl.  Abolish it.
> > 
> > Furthermore xl never passes one in either.
> 
> Right.  I will update the commit message to note this too.
> 
> > > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > A few minor comments below, but otherwise looks good to me.
> 
> Thanks...
> 
> > > +static void remus_crashed_cb(libxl__egc *egc,
> > > +                             libxl__domain_suspend_state *dss, int rc)
> > 
> > I'm not sure "crashed" is quite right here, it's finished for whatever
> > reason which may not necessarily be a crash (going forward it should
> > rarely be a crash, I think). It's "stopped" or "done" or something.
> 
> How about "remus_target_gone_cb" ?

Sounds fine to me, unless you want to work the word "failover" into it?

> > >  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
> > [...]
> > > @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> > > 
> > >  /*----- Domain suspend (save) functions -----*/
> > > 
> > > -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> > > -                                         libxl_domain_type type,
> > > -                                         int live, int debug,
> > > -                                         const libxl_domain_remus_info *r_info);
> > > +/* calls callback when done */
> > 
> > Which callback? dss->callback I guess.
> 
> What a confusing way to quote this.

Yes, sorry.

>   You're referring to this function
> of course:
> 
> > > +_hidden void libxl__domain_suspend(libxl__egc *egc,
> > > +                                   libxl__domain_suspend_state *dss);
> 
> Gripe gripe these comments before functions are inducing you to
> top-post !
> 
> Anyway, yes.  I will clarify this comment.

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 Jun 19 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 10: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 1Sgw7v-0007cy-Hi; Tue, 19 Jun 2012 10:57: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 1Sgw7t-0007cp-9p
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 10:57:37 +0000
Received: from [85.158.143.35:53859] by server-2.bemta-4.messagelabs.com id
	5D/21-17938-02B50EF4; Tue, 19 Jun 2012 10:57:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340103454!12984252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25178 invoked from network); 19 Jun 2012 10:57:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 10:57:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13098285"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 10:57:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 11:57:34 +0100
Message-ID: <1340103453.24176.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thanos Makatos <thanos.makatos@citrix.com>
Date: Tue, 19 Jun 2012 11:57:33 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 09:35 +0100, Thanos Makatos wrote:
> I have the same problem on xen-unstable 54c8c9eaee92+. I think
> libfsimage comes with xen (in my repo it's under ./tools/libfsimage).
> I've investigated a bit and found that in my occasion libfsimage tries
> to access directory /usr/lib64/fs which doesn't exist,
> whereas /usr/lib/fs does. I linked /usr/lib64/fs to /usr/lib/fs but
> then I got other problems, don't remember what. I don't know if this
> has to do with the fact that my dom0 is 64bit (Debian unstable), or
> that the domU is 64bit (Debian unstable again), or both.

Aha I'd been puzzling over why people had been seeing this but I'm not! 

This very likely is to do with Debian and Ubuntu's transition to
"multiarch" which has necessitated removing the old compatibility
symlink /usr/lib64 -> /usr/lib.

lib64 is a RPMism which doesn't really apply to Debian and derivatives
and therefore you need to tweak your Xen config before building. I use
the following local configuration patch (I should probably do the
equivalent in .config):

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1339576073 -3600
# Node ID 6eabee6807b48c72bcc35a28170f0729500def85
# Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
imported patch debian-lib-dir.patch

diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
--- a/config/StdGNU.mk	Wed Jun 13 09:27:53 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 13 09:27:53 2012 +0100
@@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
+LIBLEAFDIR_x86_64 ?= lib
 LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)

Can you try a fresh build with this applied and see if that helps.

If it does then I shall update
http://wiki.xen.org/wiki/Compiling_Xen_From_Source with this
information!

Roger -- is there any way we could automate this via autoconf 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 Jun 19 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 10: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 1Sgw7v-0007cy-Hi; Tue, 19 Jun 2012 10:57: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 1Sgw7t-0007cp-9p
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 10:57:37 +0000
Received: from [85.158.143.35:53859] by server-2.bemta-4.messagelabs.com id
	5D/21-17938-02B50EF4; Tue, 19 Jun 2012 10:57:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340103454!12984252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25178 invoked from network); 19 Jun 2012 10:57:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 10:57:35 -0000
X-IronPort-AV: E=Sophos;i="4.75,797,1330905600"; d="scan'208";a="13098285"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 10:57:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 11:57:34 +0100
Message-ID: <1340103453.24176.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thanos Makatos <thanos.makatos@citrix.com>
Date: Tue, 19 Jun 2012 11:57:33 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 09:35 +0100, Thanos Makatos wrote:
> I have the same problem on xen-unstable 54c8c9eaee92+. I think
> libfsimage comes with xen (in my repo it's under ./tools/libfsimage).
> I've investigated a bit and found that in my occasion libfsimage tries
> to access directory /usr/lib64/fs which doesn't exist,
> whereas /usr/lib/fs does. I linked /usr/lib64/fs to /usr/lib/fs but
> then I got other problems, don't remember what. I don't know if this
> has to do with the fact that my dom0 is 64bit (Debian unstable), or
> that the domU is 64bit (Debian unstable again), or both.

Aha I'd been puzzling over why people had been seeing this but I'm not! 

This very likely is to do with Debian and Ubuntu's transition to
"multiarch" which has necessitated removing the old compatibility
symlink /usr/lib64 -> /usr/lib.

lib64 is a RPMism which doesn't really apply to Debian and derivatives
and therefore you need to tweak your Xen config before building. I use
the following local configuration patch (I should probably do the
equivalent in .config):

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1339576073 -3600
# Node ID 6eabee6807b48c72bcc35a28170f0729500def85
# Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
imported patch debian-lib-dir.patch

diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
--- a/config/StdGNU.mk	Wed Jun 13 09:27:53 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 13 09:27:53 2012 +0100
@@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
+LIBLEAFDIR_x86_64 ?= lib
 LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)

Can you try a fresh build with this applied and see if that helps.

If it does then I shall update
http://wiki.xen.org/wiki/Compiling_Xen_From_Source with this
information!

Roger -- is there any way we could automate this via autoconf 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 Jun 19 11:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 11: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 1SgwTk-000827-Ku; Tue, 19 Jun 2012 11:20:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1SgwTj-00081z-9L
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 11:20:11 +0000
Received: from [85.158.143.35:55801] by server-2.bemta-4.messagelabs.com id
	B0/15-17938-A6060EF4; Tue, 19 Jun 2012 11:20:10 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340104808!5545078!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26864 invoked from network); 19 Jun 2012 11:20:09 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 11:20:09 -0000
Received: by lbom4 with SMTP id m4so7192217lbo.30
	for <xen-devel@lists.xensource.com>;
	Tue, 19 Jun 2012 04:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=4PDY7aWD0lIHc1XoXGkDUEgESF6+PVoM2ck0dpEPeaw=;
	b=vpEzQ5+TBPvbzcaQUkNs6Xo0d5expdiQoOYIrJCqkt8fzy2pBk/MlYi3hXgVV3iNAl
	UWUou2BpMCjaWUJsCdhuM8+U77WeE0N94n46nixl+Aqj8u9RTNS7ByDFy/uc/VMin9uI
	/MhItqva40AvlaUG8rOFwM9+TUigP7JfTwTgBkmYU3HUup1ieqoLf9CR2AUjVlf6tBTF
	coa22jGpSzC8HbrvJnzfoKBNp9evx0tc8oYS+UdsY57MmBhSXyPfmTN+ErU8q1OPsN6D
	MvNpSdhMt0zK0GqUYd17Sy+CmCYtr6t4oQn4fVi0VAJWN6xFVPN3nfFX6KSqoznvgHuk
	kbEA==
Received: by 10.112.83.136 with SMTP id q8mr7816350lby.60.1340104808246; Tue,
	19 Jun 2012 04:20:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.40.10 with HTTP; Tue, 19 Jun 2012 04:19:27 -0700 (PDT)
In-Reply-To: <1340103453.24176.7.camel@zakaz.uk.xensource.com>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Tue, 19 Jun 2012 14:49:27 +0330
Message-ID: <CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBKdW4gMTksIDIwMTIgYXQgMjoyNyBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gVHVlLCAyMDEyLTA2LTE5IGF0IDA5OjM1ICswMTAw
LCBUaGFub3MgTWFrYXRvcyB3cm90ZToKPj4gSSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gb24geGVu
LXVuc3RhYmxlIDU0YzhjOWVhZWU5MisuIEkgdGhpbmsKPj4gbGliZnNpbWFnZSBjb21lcyB3aXRo
IHhlbiAoaW4gbXkgcmVwbyBpdCdzIHVuZGVyIC4vdG9vbHMvbGliZnNpbWFnZSkuCj4+IEkndmUg
aW52ZXN0aWdhdGVkIGEgYml0IGFuZCBmb3VuZCB0aGF0IGluIG15IG9jY2FzaW9uIGxpYmZzaW1h
Z2UgdHJpZXMKPj4gdG8gYWNjZXNzIGRpcmVjdG9yeSAvdXNyL2xpYjY0L2ZzIHdoaWNoIGRvZXNu
J3QgZXhpc3QsCj4+IHdoZXJlYXMgL3Vzci9saWIvZnMgZG9lcy4gSSBsaW5rZWQgL3Vzci9saWI2
NC9mcyB0byAvdXNyL2xpYi9mcyBidXQKPj4gdGhlbiBJIGdvdCBvdGhlciBwcm9ibGVtcywgZG9u
J3QgcmVtZW1iZXIgd2hhdC4gSSBkb24ndCBrbm93IGlmIHRoaXMKPj4gaGFzIHRvIGRvIHdpdGgg
dGhlIGZhY3QgdGhhdCBteSBkb20wIGlzIDY0Yml0IChEZWJpYW4gdW5zdGFibGUpLCBvcgo+PiB0
aGF0IHRoZSBkb21VIGlzIDY0Yml0IChEZWJpYW4gdW5zdGFibGUgYWdhaW4pLCBvciBib3RoLgo+
Cj4gQWhhIEknZCBiZWVuIHB1enpsaW5nIG92ZXIgd2h5IHBlb3BsZSBoYWQgYmVlbiBzZWVpbmcg
dGhpcyBidXQgSSdtIG5vdCEKPgo+IFRoaXMgdmVyeSBsaWtlbHkgaXMgdG8gZG8gd2l0aCBEZWJp
YW4gYW5kIFVidW50dSdzIHRyYW5zaXRpb24gdG8KPiAibXVsdGlhcmNoIiB3aGljaCBoYXMgbmVj
ZXNzaXRhdGVkIHJlbW92aW5nIHRoZSBvbGQgY29tcGF0aWJpbGl0eQo+IHN5bWxpbmsgL3Vzci9s
aWI2NCAtPiAvdXNyL2xpYi4KCkxpbmtpbmcgL3Vzci9saWI2NC9mcyB0byAvdXNyL2xpYi9mcyBz
b2x2ZWQgdGhlIHByb2JsZW0gZm9yIG1lLiBJIGhhdmUKcGF0Y2hlZCBTdGRHTlUubWsgc28gY291
bGRuJ3QgdGhpbmsgb2YgdGhpcyB0byBiZSB0aGUgY2F1c2UuCgo+IGxpYjY0IGlzIGEgUlBNaXNt
IHdoaWNoIGRvZXNuJ3QgcmVhbGx5IGFwcGx5IHRvIERlYmlhbiBhbmQgZGVyaXZhdGl2ZXMKPiBh
bmQgdGhlcmVmb3JlIHlvdSBuZWVkIHRvIHR3ZWFrIHlvdXIgWGVuIGNvbmZpZyBiZWZvcmUgYnVp
bGRpbmcuIEkgdXNlCj4gdGhlIGZvbGxvd2luZyBsb2NhbCBjb25maWd1cmF0aW9uIHBhdGNoIChJ
IHNob3VsZCBwcm9iYWJseSBkbyB0aGUKPiBlcXVpdmFsZW50IGluIC5jb25maWcpOgo+Cj4gIyBI
RyBjaGFuZ2VzZXQgcGF0Y2gKPiAjIFVzZXIgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KPiAjIERhdGUgMTMzOTU3NjA3MyAtMzYwMAo+ICMgTm9kZSBJRCA2ZWFiZWU2ODA3
YjQ4YzcyYmNjMzVhMjgxNzBmMDcyOTUwMGRlZjg1Cj4gIyBQYXJlbnQgwqA4MGMwNjc3ZjBmODM3
MGE0NTQyYWFiODFhYjkzMzgwYjBkYWIyNWRiCj4gaW1wb3J0ZWQgcGF0Y2ggZGViaWFuLWxpYi1k
aXIucGF0Y2gKPgo+IGRpZmYgLXIgODBjMDY3N2YwZjgzIC1yIDZlYWJlZTY4MDdiNCBjb25maWcv
U3RkR05VLm1rCj4gLS0tIGEvY29uZmlnL1N0ZEdOVS5tayDCoFdlZCBKdW4gMTMgMDk6Mjc6NTMg
MjAxMiArMDEwMAo+ICsrKyBiL2NvbmZpZy9TdGRHTlUubWsgwqBXZWQgSnVuIDEzIDA5OjI3OjUz
IDIwMTIgKzAxMDAKPiBAQCAtMzQsNyArMzQsNyBAQCBCSU5ESVIgPSAkKFBSRUZJWCkvYmluCj4g
wqBJTkNMVURFRElSID0gJChQUkVGSVgpL2luY2x1ZGUKPiDCoExJQkxFQUZESVIgPSBsaWIKPiDC
oExJQkxFQUZESVJfeDg2XzMyID0gbGliCj4gLUxJQkxFQUZESVJfeDg2XzY0ID89IGxpYjY0Cj4g
K0xJQkxFQUZESVJfeDg2XzY0ID89IGxpYgo+IMKgTElCRElSID0gJChQUkVGSVgpLyQoTElCTEVB
RkRJUikKPiDCoExJQkRJUl94ODZfMzIgPSAkKFBSRUZJWCkvJChMSUJMRUFGRElSX3g4Nl8zMikK
PiDCoExJQkRJUl94ODZfNjQgPSAkKFBSRUZJWCkvJChMSUJMRUFGRElSX3g4Nl82NCkKPgo+IENh
biB5b3UgdHJ5IGEgZnJlc2ggYnVpbGQgd2l0aCB0aGlzIGFwcGxpZWQgYW5kIHNlZSBpZiB0aGF0
IGhlbHBzLgpJIGhhdmUgYXBwbGllZCB0aGlzIHBhdGNoLiBJIHRoaW5rIGxpYmZzaW1hZ2UgaXMg
c29tZWhvdyBub3QgYmVpbmcKYWZmZWN0ZWQgd2l0aCB0aGlzLiBZZXQsIGxpbmtpbmcgL3Vzci9s
aWI2NC9mcyAtPiAvdXNyL2xpYi9mcyBzb2x2ZXMKdGhlIHByb2JsZW0uCj4KPiBJZiBpdCBkb2Vz
IHRoZW4gSSBzaGFsbCB1cGRhdGUKPiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQ29tcGlsaW5n
X1hlbl9Gcm9tX1NvdXJjZSB3aXRoIHRoaXMKPiBpbmZvcm1hdGlvbiEKPgo+IFJvZ2VyIC0tIGlz
IHRoZXJlIGFueSB3YXkgd2UgY291bGQgYXV0b21hdGUgdGhpcyB2aWEgYXV0b2NvbmYgZm9yIDQu
Mj8KPgo+IElhbi4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Jun 19 11:20:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 11: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 1SgwTk-000827-Ku; Tue, 19 Jun 2012 11:20:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1SgwTj-00081z-9L
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 11:20:11 +0000
Received: from [85.158.143.35:55801] by server-2.bemta-4.messagelabs.com id
	B0/15-17938-A6060EF4; Tue, 19 Jun 2012 11:20:10 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340104808!5545078!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26864 invoked from network); 19 Jun 2012 11:20:09 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 11:20:09 -0000
Received: by lbom4 with SMTP id m4so7192217lbo.30
	for <xen-devel@lists.xensource.com>;
	Tue, 19 Jun 2012 04:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=4PDY7aWD0lIHc1XoXGkDUEgESF6+PVoM2ck0dpEPeaw=;
	b=vpEzQ5+TBPvbzcaQUkNs6Xo0d5expdiQoOYIrJCqkt8fzy2pBk/MlYi3hXgVV3iNAl
	UWUou2BpMCjaWUJsCdhuM8+U77WeE0N94n46nixl+Aqj8u9RTNS7ByDFy/uc/VMin9uI
	/MhItqva40AvlaUG8rOFwM9+TUigP7JfTwTgBkmYU3HUup1ieqoLf9CR2AUjVlf6tBTF
	coa22jGpSzC8HbrvJnzfoKBNp9evx0tc8oYS+UdsY57MmBhSXyPfmTN+ErU8q1OPsN6D
	MvNpSdhMt0zK0GqUYd17Sy+CmCYtr6t4oQn4fVi0VAJWN6xFVPN3nfFX6KSqoznvgHuk
	kbEA==
Received: by 10.112.83.136 with SMTP id q8mr7816350lby.60.1340104808246; Tue,
	19 Jun 2012 04:20:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.40.10 with HTTP; Tue, 19 Jun 2012 04:19:27 -0700 (PDT)
In-Reply-To: <1340103453.24176.7.camel@zakaz.uk.xensource.com>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Tue, 19 Jun 2012 14:49:27 +0330
Message-ID: <CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBKdW4gMTksIDIwMTIgYXQgMjoyNyBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gVHVlLCAyMDEyLTA2LTE5IGF0IDA5OjM1ICswMTAw
LCBUaGFub3MgTWFrYXRvcyB3cm90ZToKPj4gSSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gb24geGVu
LXVuc3RhYmxlIDU0YzhjOWVhZWU5MisuIEkgdGhpbmsKPj4gbGliZnNpbWFnZSBjb21lcyB3aXRo
IHhlbiAoaW4gbXkgcmVwbyBpdCdzIHVuZGVyIC4vdG9vbHMvbGliZnNpbWFnZSkuCj4+IEkndmUg
aW52ZXN0aWdhdGVkIGEgYml0IGFuZCBmb3VuZCB0aGF0IGluIG15IG9jY2FzaW9uIGxpYmZzaW1h
Z2UgdHJpZXMKPj4gdG8gYWNjZXNzIGRpcmVjdG9yeSAvdXNyL2xpYjY0L2ZzIHdoaWNoIGRvZXNu
J3QgZXhpc3QsCj4+IHdoZXJlYXMgL3Vzci9saWIvZnMgZG9lcy4gSSBsaW5rZWQgL3Vzci9saWI2
NC9mcyB0byAvdXNyL2xpYi9mcyBidXQKPj4gdGhlbiBJIGdvdCBvdGhlciBwcm9ibGVtcywgZG9u
J3QgcmVtZW1iZXIgd2hhdC4gSSBkb24ndCBrbm93IGlmIHRoaXMKPj4gaGFzIHRvIGRvIHdpdGgg
dGhlIGZhY3QgdGhhdCBteSBkb20wIGlzIDY0Yml0IChEZWJpYW4gdW5zdGFibGUpLCBvcgo+PiB0
aGF0IHRoZSBkb21VIGlzIDY0Yml0IChEZWJpYW4gdW5zdGFibGUgYWdhaW4pLCBvciBib3RoLgo+
Cj4gQWhhIEknZCBiZWVuIHB1enpsaW5nIG92ZXIgd2h5IHBlb3BsZSBoYWQgYmVlbiBzZWVpbmcg
dGhpcyBidXQgSSdtIG5vdCEKPgo+IFRoaXMgdmVyeSBsaWtlbHkgaXMgdG8gZG8gd2l0aCBEZWJp
YW4gYW5kIFVidW50dSdzIHRyYW5zaXRpb24gdG8KPiAibXVsdGlhcmNoIiB3aGljaCBoYXMgbmVj
ZXNzaXRhdGVkIHJlbW92aW5nIHRoZSBvbGQgY29tcGF0aWJpbGl0eQo+IHN5bWxpbmsgL3Vzci9s
aWI2NCAtPiAvdXNyL2xpYi4KCkxpbmtpbmcgL3Vzci9saWI2NC9mcyB0byAvdXNyL2xpYi9mcyBz
b2x2ZWQgdGhlIHByb2JsZW0gZm9yIG1lLiBJIGhhdmUKcGF0Y2hlZCBTdGRHTlUubWsgc28gY291
bGRuJ3QgdGhpbmsgb2YgdGhpcyB0byBiZSB0aGUgY2F1c2UuCgo+IGxpYjY0IGlzIGEgUlBNaXNt
IHdoaWNoIGRvZXNuJ3QgcmVhbGx5IGFwcGx5IHRvIERlYmlhbiBhbmQgZGVyaXZhdGl2ZXMKPiBh
bmQgdGhlcmVmb3JlIHlvdSBuZWVkIHRvIHR3ZWFrIHlvdXIgWGVuIGNvbmZpZyBiZWZvcmUgYnVp
bGRpbmcuIEkgdXNlCj4gdGhlIGZvbGxvd2luZyBsb2NhbCBjb25maWd1cmF0aW9uIHBhdGNoIChJ
IHNob3VsZCBwcm9iYWJseSBkbyB0aGUKPiBlcXVpdmFsZW50IGluIC5jb25maWcpOgo+Cj4gIyBI
RyBjaGFuZ2VzZXQgcGF0Y2gKPiAjIFVzZXIgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KPiAjIERhdGUgMTMzOTU3NjA3MyAtMzYwMAo+ICMgTm9kZSBJRCA2ZWFiZWU2ODA3
YjQ4YzcyYmNjMzVhMjgxNzBmMDcyOTUwMGRlZjg1Cj4gIyBQYXJlbnQgwqA4MGMwNjc3ZjBmODM3
MGE0NTQyYWFiODFhYjkzMzgwYjBkYWIyNWRiCj4gaW1wb3J0ZWQgcGF0Y2ggZGViaWFuLWxpYi1k
aXIucGF0Y2gKPgo+IGRpZmYgLXIgODBjMDY3N2YwZjgzIC1yIDZlYWJlZTY4MDdiNCBjb25maWcv
U3RkR05VLm1rCj4gLS0tIGEvY29uZmlnL1N0ZEdOVS5tayDCoFdlZCBKdW4gMTMgMDk6Mjc6NTMg
MjAxMiArMDEwMAo+ICsrKyBiL2NvbmZpZy9TdGRHTlUubWsgwqBXZWQgSnVuIDEzIDA5OjI3OjUz
IDIwMTIgKzAxMDAKPiBAQCAtMzQsNyArMzQsNyBAQCBCSU5ESVIgPSAkKFBSRUZJWCkvYmluCj4g
wqBJTkNMVURFRElSID0gJChQUkVGSVgpL2luY2x1ZGUKPiDCoExJQkxFQUZESVIgPSBsaWIKPiDC
oExJQkxFQUZESVJfeDg2XzMyID0gbGliCj4gLUxJQkxFQUZESVJfeDg2XzY0ID89IGxpYjY0Cj4g
K0xJQkxFQUZESVJfeDg2XzY0ID89IGxpYgo+IMKgTElCRElSID0gJChQUkVGSVgpLyQoTElCTEVB
RkRJUikKPiDCoExJQkRJUl94ODZfMzIgPSAkKFBSRUZJWCkvJChMSUJMRUFGRElSX3g4Nl8zMikK
PiDCoExJQkRJUl94ODZfNjQgPSAkKFBSRUZJWCkvJChMSUJMRUFGRElSX3g4Nl82NCkKPgo+IENh
biB5b3UgdHJ5IGEgZnJlc2ggYnVpbGQgd2l0aCB0aGlzIGFwcGxpZWQgYW5kIHNlZSBpZiB0aGF0
IGhlbHBzLgpJIGhhdmUgYXBwbGllZCB0aGlzIHBhdGNoLiBJIHRoaW5rIGxpYmZzaW1hZ2UgaXMg
c29tZWhvdyBub3QgYmVpbmcKYWZmZWN0ZWQgd2l0aCB0aGlzLiBZZXQsIGxpbmtpbmcgL3Vzci9s
aWI2NC9mcyAtPiAvdXNyL2xpYi9mcyBzb2x2ZXMKdGhlIHByb2JsZW0uCj4KPiBJZiBpdCBkb2Vz
IHRoZW4gSSBzaGFsbCB1cGRhdGUKPiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQ29tcGlsaW5n
X1hlbl9Gcm9tX1NvdXJjZSB3aXRoIHRoaXMKPiBpbmZvcm1hdGlvbiEKPgo+IFJvZ2VyIC0tIGlz
IHRoZXJlIGFueSB3YXkgd2UgY291bGQgYXV0b21hdGUgdGhpcyB2aWEgYXV0b2NvbmYgZm9yIDQu
Mj8KPgo+IElhbi4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:03:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13: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 1Sgy52-0000TA-Q0; Tue, 19 Jun 2012 13: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.Jackson@eu.citrix.com>) id 1Sgy50-0000T3-ES
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:02:46 +0000
Received: from [85.158.143.35:36823] by server-1.bemta-4.messagelabs.com id
	8C/5F-24392-47870EF4; Tue, 19 Jun 2012 13:02:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340110961!15788534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25021 invoked from network); 19 Jun 2012 13:02:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:02:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13101866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:02:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 14:02:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sgy4i-0004th-Kd; Tue, 19 Jun 2012 13:02:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sgy4i-00076G-Gd;
	Tue, 19 Jun 2012 14:02:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20448.30820.166288.216230@mariner.uk.xensource.com>
Date: Tue, 19 Jun 2012 14:02:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340100279.16742.10.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
	<20442.706.194448.288137@mariner.uk.xensource.com>
	<1340100279.16742.10.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> On Thu, 2012-06-14 at 16:26 +0100, Ian Jackson wrote:
> > How about "remus_target_gone_cb" ?
> 
> Sounds fine to me, unless you want to work the word "failover" into it?

remus_failover_cb ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:03:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13: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 1Sgy52-0000TA-Q0; Tue, 19 Jun 2012 13: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.Jackson@eu.citrix.com>) id 1Sgy50-0000T3-ES
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:02:46 +0000
Received: from [85.158.143.35:36823] by server-1.bemta-4.messagelabs.com id
	8C/5F-24392-47870EF4; Tue, 19 Jun 2012 13:02:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340110961!15788534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25021 invoked from network); 19 Jun 2012 13:02:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:02:42 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13101866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:02:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 14:02:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sgy4i-0004th-Kd; Tue, 19 Jun 2012 13:02:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sgy4i-00076G-Gd;
	Tue, 19 Jun 2012 14:02:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20448.30820.166288.216230@mariner.uk.xensource.com>
Date: Tue, 19 Jun 2012 14:02:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340100279.16742.10.camel@zakaz.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
	<20442.706.194448.288137@mariner.uk.xensource.com>
	<1340100279.16742.10.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> On Thu, 2012-06-14 at 16:26 +0100, Ian Jackson wrote:
> > How about "remus_target_gone_cb" ?
> 
> Sounds fine to me, unless you want to work the word "failover" into it?

remus_failover_cb ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:24:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:24: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 1SgyPZ-0000jc-O4; Tue, 19 Jun 2012 13:24:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SgyPZ-0000jX-16
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:24:01 +0000
Received: from [85.158.143.35:16928] by server-2.bemta-4.messagelabs.com id
	BE/8E-17938-07D70EF4; Tue, 19 Jun 2012 13:24:00 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340112239!15793708!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2418 invoked from network); 19 Jun 2012 13:23:59 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:23:59 -0000
Received: by eekd41 with SMTP id d41so2224675eek.32
	for <xen-devel@lists.xen.org>; Tue, 19 Jun 2012 06:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=glygWPFfEEX83ujfltob4b1fd7rCnlXNPPVvPkgqphU=;
	b=DW5lautxTBHy+M8P9QlAzU+f7rMRv7zp2sHBFfTeE8jFk/iv5maK5oD2CSgaBCCPAl
	kLOQjVbGA6/fywBJki2Pxlk8sIYww2qWwYOli9X459+kOji1jM/vqCcpMQWzcc4LPDGd
	mRznARSdhFgBnEq7CgiBFW4cVlNIAIPfnYaS2Qz2Y8XnyoO+1NZMIPx2rYgcEkbQAAaw
	8frNCfgqGpwEQktevXrZa5WiMgbnwCCO34veIOkk3Zl0bpgF1DoACzBT5fBrW39qVJBn
	RpgNAZ7RfcjMWMMsw87yk0442HUOWnCS+qb+rLxBzxMuXIeqRaBtzQ2g7LnkLuJIMh31
	Ux9A==
Received: by 10.14.98.204 with SMTP id v52mr4269738eef.199.1340112239136;
	Tue, 19 Jun 2012 06:23:59 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id g46sm75994769eea.14.2012.06.19.06.23.56
	(version=SSLv3 cipher=OTHER); Tue, 19 Jun 2012 06:23:57 -0700 (PDT)
Message-ID: <4FE07D6B.7080908@xen.org>
Date: Tue, 19 Jun 2012 14:23:55 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Minuters: Xen Maintainer,
 Committer and Developer Meeting for June 2012
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

The meeting took place last Wed, the 14th of June
Minutes see: 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/June_2012_Minutes 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:24:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:24: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 1SgyPZ-0000jc-O4; Tue, 19 Jun 2012 13:24:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SgyPZ-0000jX-16
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:24:01 +0000
Received: from [85.158.143.35:16928] by server-2.bemta-4.messagelabs.com id
	BE/8E-17938-07D70EF4; Tue, 19 Jun 2012 13:24:00 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340112239!15793708!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2418 invoked from network); 19 Jun 2012 13:23:59 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:23:59 -0000
Received: by eekd41 with SMTP id d41so2224675eek.32
	for <xen-devel@lists.xen.org>; Tue, 19 Jun 2012 06:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=glygWPFfEEX83ujfltob4b1fd7rCnlXNPPVvPkgqphU=;
	b=DW5lautxTBHy+M8P9QlAzU+f7rMRv7zp2sHBFfTeE8jFk/iv5maK5oD2CSgaBCCPAl
	kLOQjVbGA6/fywBJki2Pxlk8sIYww2qWwYOli9X459+kOji1jM/vqCcpMQWzcc4LPDGd
	mRznARSdhFgBnEq7CgiBFW4cVlNIAIPfnYaS2Qz2Y8XnyoO+1NZMIPx2rYgcEkbQAAaw
	8frNCfgqGpwEQktevXrZa5WiMgbnwCCO34veIOkk3Zl0bpgF1DoACzBT5fBrW39qVJBn
	RpgNAZ7RfcjMWMMsw87yk0442HUOWnCS+qb+rLxBzxMuXIeqRaBtzQ2g7LnkLuJIMh31
	Ux9A==
Received: by 10.14.98.204 with SMTP id v52mr4269738eef.199.1340112239136;
	Tue, 19 Jun 2012 06:23:59 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id g46sm75994769eea.14.2012.06.19.06.23.56
	(version=SSLv3 cipher=OTHER); Tue, 19 Jun 2012 06:23:57 -0700 (PDT)
Message-ID: <4FE07D6B.7080908@xen.org>
Date: Tue, 19 Jun 2012 14:23:55 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Minuters: Xen Maintainer,
 Committer and Developer Meeting for June 2012
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

The meeting took place last Wed, the 14th of June
Minutes see: 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/June_2012_Minutes 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:33:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgyYo-0000wE-Qe; Tue, 19 Jun 2012 13:33:34 +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 1SgyYn-0000w5-BV
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:33:33 +0000
Received: from [193.109.254.147:43767] by server-7.bemta-14.messagelabs.com id
	0E/87-29827-CAF70EF4; Tue, 19 Jun 2012 13:33:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340112811!10550453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16585 invoked from network); 19 Jun 2012 13:33:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13103081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:33:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 14:33:31 +0100
Message-ID: <1340112809.24176.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 14:33:29 +0100
In-Reply-To: <20442.1961.665575.42873@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
	<1339591954.24104.200.camel@zakaz.uk.xensource.com>
	<20442.1961.665575.42873@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
 logdirty command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 16:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge logdirty command"):
> > On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > > The current migration code in libxl instructs qemu to start or stop
> > > logdirty, but it does not wait for an acknowledgement from qemu before
> > > continuing.  This might lead to memory corruption (!)
> ...
> > > +static void logdirty_init(libxl__logdirty_switch *lds)
> > > +{
> > > +    lds->cmd_path = 0;
> > > +    libxl__ev_xswatch_init(&lds->watch);
> > > +    libxl__ev_time_init(&lds->timeout);
> > 
> > I meant to mention this once before when reviewing some patch or other
> > but I'm not sure I actually did, so at the risk of repeating myself:
> > 
> > This watch with timeout pattern seems to be reasonably common (in fact,
> > I'm not sure we have any watches without a timeout). It might be a
> > candidate for a specific helper routine in the future?
> 
> Perhaps.  We should think about this.

Yes, I should have said the phrase "4.3" in there somewhere.

>   I'm not sure it's necessary
> now.  The benefit might be relatively small, as the callback function
> would more complicated.

Could still have two callbacks, and just helpers for the setup &
teardown phases?

> Perhaps we should integrate the single xs read which most of these callers also have.

You mean pass in the value of the watched key? That's also a
possibility.

> 
> > > +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
> > > +                            const char *watch_path, const char *event_path)
> > > +{
> ...
> > > + out:
> > > +    /* rc < 0: error
> > > +     * rc == 0: ok, we are done
> > > +     * rc == +1: need to keep waiting
> > > +     */
> > > +    libxl__xs_transaction_abort(gc, &t);
> > > +
> > > +    if (!rc) {
> > > +        switch_logdirty_done(egc,dss,1);
> > > +    } else if (rc < 0) {
> > > +        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);
> > 
> > Is it only "response read failed" which can cause us to end up here,
> > looks like the read, rm etc could do it?
> 
> Oh yes.  I should fix that message.  (All of these paths have already
> logged something already, but another message probably doesn't hurt.)
> 
> 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 Jun 19 13:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:33:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgyYo-0000wE-Qe; Tue, 19 Jun 2012 13:33:34 +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 1SgyYn-0000w5-BV
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:33:33 +0000
Received: from [193.109.254.147:43767] by server-7.bemta-14.messagelabs.com id
	0E/87-29827-CAF70EF4; Tue, 19 Jun 2012 13:33:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340112811!10550453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16585 invoked from network); 19 Jun 2012 13:33:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13103081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:33:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 14:33:31 +0100
Message-ID: <1340112809.24176.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 14:33:29 +0100
In-Reply-To: <20442.1961.665575.42873@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-9-git-send-email-ian.jackson@eu.citrix.com>
	<1339591954.24104.200.camel@zakaz.uk.xensource.com>
	<20442.1961.665575.42873@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge
 logdirty command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-14 at 16:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 08/19] libxl: wait for qemu to acknowledge logdirty command"):
> > On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> > > The current migration code in libxl instructs qemu to start or stop
> > > logdirty, but it does not wait for an acknowledgement from qemu before
> > > continuing.  This might lead to memory corruption (!)
> ...
> > > +static void logdirty_init(libxl__logdirty_switch *lds)
> > > +{
> > > +    lds->cmd_path = 0;
> > > +    libxl__ev_xswatch_init(&lds->watch);
> > > +    libxl__ev_time_init(&lds->timeout);
> > 
> > I meant to mention this once before when reviewing some patch or other
> > but I'm not sure I actually did, so at the risk of repeating myself:
> > 
> > This watch with timeout pattern seems to be reasonably common (in fact,
> > I'm not sure we have any watches without a timeout). It might be a
> > candidate for a specific helper routine in the future?
> 
> Perhaps.  We should think about this.

Yes, I should have said the phrase "4.3" in there somewhere.

>   I'm not sure it's necessary
> now.  The benefit might be relatively small, as the callback function
> would more complicated.

Could still have two callbacks, and just helpers for the setup &
teardown phases?

> Perhaps we should integrate the single xs read which most of these callers also have.

You mean pass in the value of the watched key? That's also a
possibility.

> 
> > > +static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
> > > +                            const char *watch_path, const char *event_path)
> > > +{
> ...
> > > + out:
> > > +    /* rc < 0: error
> > > +     * rc == 0: ok, we are done
> > > +     * rc == +1: need to keep waiting
> > > +     */
> > > +    libxl__xs_transaction_abort(gc, &t);
> > > +
> > > +    if (!rc) {
> > > +        switch_logdirty_done(egc,dss,1);
> > > +    } else if (rc < 0) {
> > > +        LOG(ERROR,"logdirty switch: response read failed (rc=%d)",rc);
> > 
> > Is it only "response read failed" which can cause us to end up here,
> > looks like the read, rm etc could do it?
> 
> Oh yes.  I should fix that message.  (All of these paths have already
> logged something already, but another message probably doesn't hurt.)
> 
> 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 Jun 19 13:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:40: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 1Sgyf2-00015r-N2; Tue, 19 Jun 2012 13:40: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 1Sgyf0-00015k-V4
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 13:39:59 +0000
Received: from [85.158.143.99:27551] by server-3.bemta-4.messagelabs.com id
	16/3B-05808-E2180EF4; Tue, 19 Jun 2012 13:39:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340113196!27175450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13785 invoked from network); 19 Jun 2012 13:39:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13103245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:39:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 14:39:55 +0100
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 1Sgyex-00056S-Fl;
	Tue, 19 Jun 2012 13:39:55 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sgyex-0000cD-9B;
	Tue, 19 Jun 2012 14:39:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13089-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 14:39:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13089: 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 13089 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13089/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 13050
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 13050
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13050

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           15 guest-stop                   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-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  e231998f4e3a
baseline version:
 xen                  e35c8bb53255

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=e231998f4e3a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing e231998f4e3a
+ branch=xen-4.0-testing
+ revision=e231998f4e3a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r e231998f4e3a ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:40:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:40: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 1Sgyf2-00015r-N2; Tue, 19 Jun 2012 13:40: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 1Sgyf0-00015k-V4
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 13:39:59 +0000
Received: from [85.158.143.99:27551] by server-3.bemta-4.messagelabs.com id
	16/3B-05808-E2180EF4; Tue, 19 Jun 2012 13:39:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340113196!27175450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13785 invoked from network); 19 Jun 2012 13:39:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13103245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:39:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 14:39:55 +0100
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 1Sgyex-00056S-Fl;
	Tue, 19 Jun 2012 13:39:55 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sgyex-0000cD-9B;
	Tue, 19 Jun 2012 14:39:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13089-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 14:39:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13089: 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 13089 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13089/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 13050
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 13050
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13050

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           15 guest-stop                   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-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  e231998f4e3a
baseline version:
 xen                  e35c8bb53255

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=e231998f4e3a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing e231998f4e3a
+ branch=xen-4.0-testing
+ revision=e231998f4e3a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r e231998f4e3a ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:49:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:49: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 1Sgyny-0001Mg-VA; Tue, 19 Jun 2012 13:49:14 +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 1Sgyny-0001Mb-4D
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 13:49:14 +0000
Received: from [193.109.254.147:47294] by server-12.bemta-14.messagelabs.com
	id 9D/AD-30461-95380EF4; Tue, 19 Jun 2012 13:49:13 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340113752!10554144!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5927 invoked from network); 19 Jun 2012 13:49:12 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:49:12 -0000
Received: by eeke50 with SMTP id e50so2755272eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 19 Jun 2012 06:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=MRgdxditvJ42H5Q2ITmTTb+r43cB7ph9h+OPYtci2Ds=;
	b=He4ieE4U/qXCYiyohQwfILzp69KNiFen8cmysxBlu5uGIDEqGcfa+zhDvuCUQONy7B
	bz0KiwgMmLfFgXZ/OLLxeeXa1XN3pq1vFjQpcmZCct/iqvMTDrHQmM28dzq86Rg2PxOJ
	eVVtB+K1G9ocz3UvBC61LwLgBXHfOk5j/7euPi9ROe01kpdw0iF6EgYyDFIFON9gnOAO
	V41CQydBsAfZ8GVQ964/4pUTZg+UUvvgLvlEqg3uQEQi+A4SjbT63ZKGlPWncEI1vUGQ
	rvU2ELDnmW6XxJraGoREpsKjfWcYXPVHTVhWn5Q0/RrZW14vnMGY5xvNMSFdPwqDCM3c
	tyxQ==
MIME-Version: 1.0
Received: by 10.14.99.11 with SMTP id w11mr4437848eef.67.1340113752377; Tue,
	19 Jun 2012 06:49:12 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Tue, 19 Jun 2012 06:49:12 -0700 (PDT)
In-Reply-To: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
Date: Tue, 19 Jun 2012 09:49:12 -0400
Message-ID: <CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I previously email at xen-user list but didn't get any response. I am
using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.


---------- Forwarded message ----------
From: Shakeel Butt <shakeel.butt@gmail.com>
Date: Mon, Jun 18, 2012 at 10:06 AM
Subject: netback (Network backend) in domU
To: xen-users@lists.xen.org


Hi,

I am trying to setup a domU as a network backend for some other domUs.
I configured bridge in netback-domU using network-bridge script (not a
driver domain). I am assigning static ip addresses to all domUs.
Something like =A0dom0 <-> netback-domU <-> other-domU.

In the setup, netback-domU and other-domU are able to ping each other
but whenever I tried to ping dom0 from other-domU, I get a XEN error
message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
dom0 kernel "#### netback grant fails".

I didn't check if dom0 is trying to pin grant frame of other-domU but
why dom0 would do it. Please any help will be appreciated.

BTW does the bridge in dom0 needs to know that one of its interface is
connected to another bridge in netback-domU? (don't know how or why)

thanks,
Shakeel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:49:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13:49: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 1Sgyny-0001Mg-VA; Tue, 19 Jun 2012 13:49:14 +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 1Sgyny-0001Mb-4D
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 13:49:14 +0000
Received: from [193.109.254.147:47294] by server-12.bemta-14.messagelabs.com
	id 9D/AD-30461-95380EF4; Tue, 19 Jun 2012 13:49:13 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340113752!10554144!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5927 invoked from network); 19 Jun 2012 13:49:12 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:49:12 -0000
Received: by eeke50 with SMTP id e50so2755272eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 19 Jun 2012 06:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=MRgdxditvJ42H5Q2ITmTTb+r43cB7ph9h+OPYtci2Ds=;
	b=He4ieE4U/qXCYiyohQwfILzp69KNiFen8cmysxBlu5uGIDEqGcfa+zhDvuCUQONy7B
	bz0KiwgMmLfFgXZ/OLLxeeXa1XN3pq1vFjQpcmZCct/iqvMTDrHQmM28dzq86Rg2PxOJ
	eVVtB+K1G9ocz3UvBC61LwLgBXHfOk5j/7euPi9ROe01kpdw0iF6EgYyDFIFON9gnOAO
	V41CQydBsAfZ8GVQ964/4pUTZg+UUvvgLvlEqg3uQEQi+A4SjbT63ZKGlPWncEI1vUGQ
	rvU2ELDnmW6XxJraGoREpsKjfWcYXPVHTVhWn5Q0/RrZW14vnMGY5xvNMSFdPwqDCM3c
	tyxQ==
MIME-Version: 1.0
Received: by 10.14.99.11 with SMTP id w11mr4437848eef.67.1340113752377; Tue,
	19 Jun 2012 06:49:12 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Tue, 19 Jun 2012 06:49:12 -0700 (PDT)
In-Reply-To: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
Date: Tue, 19 Jun 2012 09:49:12 -0400
Message-ID: <CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I previously email at xen-user list but didn't get any response. I am
using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.


---------- Forwarded message ----------
From: Shakeel Butt <shakeel.butt@gmail.com>
Date: Mon, Jun 18, 2012 at 10:06 AM
Subject: netback (Network backend) in domU
To: xen-users@lists.xen.org


Hi,

I am trying to setup a domU as a network backend for some other domUs.
I configured bridge in netback-domU using network-bridge script (not a
driver domain). I am assigning static ip addresses to all domUs.
Something like =A0dom0 <-> netback-domU <-> other-domU.

In the setup, netback-domU and other-domU are able to ping each other
but whenever I tried to ping dom0 from other-domU, I get a XEN error
message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
dom0 kernel "#### netback grant fails".

I didn't check if dom0 is trying to pin grant frame of other-domU but
why dom0 would do it. Please any help will be appreciated.

BTW does the bridge in dom0 needs to know that one of its interface is
connected to another bridge in netback-domU? (don't know how or why)

thanks,
Shakeel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 13:51:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13: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 1SgypJ-0001Q1-Dd; Tue, 19 Jun 2012 13:50: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 1SgypI-0001Pc-0R
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:50:36 +0000
Received: from [85.158.143.99:36142] by server-1.bemta-4.messagelabs.com id
	40/84-24392-9A380EF4; Tue, 19 Jun 2012 13:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340113831!18456432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17750 invoked from network); 19 Jun 2012 13:50:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:50:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13103590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:50:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 14:50:31 +0100
Message-ID: <1340113830.24176.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 14:50:30 +0100
In-Reply-To: <20442.5612.626430.387995@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
	<1339585498.24104.190.camel@zakaz.uk.xensource.com>
	<20442.5612.626430.387995@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > >  testidl: testidl.o libxlutil.so libxenlight.so
> > >         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> > [...]
> > > @@ -170,6 +184,7 @@ install: all
> > >         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
> > >         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
> > >         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> > > +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
> > 
> > This needs an INSTALL_DIR for $(DESTDIR)$(PRIVATE_BINDIR) to support
> > "make -C tools/libxl DESTDIR=xxx install" else:
> >         install: cannot create regular file `/tmp/tmplKa0Y7/usr/lib/xen/bin': No such file or directory
> 
> OK.  I guess I never do that and it's a bit of a mystery why one
> would without having done a more general install before, but it's
> clearly a correct change.

I build and install on a different machine, which means I install into
DESTDIR=`mkdtemp ...` and tar, copy etc. I do one full build to seed
everything and then incrementally just the dir I'm working in, so this
hits me because on the incremental ones the fresh DESTDIR doesn't have
the directory yet.

> 
> > > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > > index b48452c..fea0c94 100644
> ...
> > >  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> > > -        uint32_t size, void *data)
> ...
> > > +    libxl_ctx *ctx = CTX;
> > 
> > Any reason you didn't s/ctx/CTX/ in one of your preparatory patches?
> 
> I didn't want to do that unless it was necessary.  There was already
> enough else going on.  I don't think having a ctx rather than using
> CTX is wrong, although it is slightly less in the modern idiom.

Fair enough.

> 
> > >  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
> > >                             unsigned long vm_generationid_addr)
> > >  {
> > >      STATE_AO_GC(dss->ao);
> > > -    int r;
> > > +    int r, rc;
> > > +    uint32_t toolstack_data_len;
> > > +
> > > +    /* Resources we need to free */
> > > +    uint8_t *toolstack_data_buf = 0;
> > > +
> > > +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> > > +        (&dss->shs.callbacks.save.a);
> > > +
> > > +    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
> > > +                              &toolstack_data_len, dss);
> > 
> > This seems to be called twice? I'm looking at the source after the full
> > series is applied and I see
> >         dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
> > in libxl__domain_suspend as well as this call here.
> 
> But in fact dss->shs.callbacks.save.toolstack_save is never used
> anywhere in that version.  The bug is that libxl__xc_domain_save
> should call the callback function (if it is non-null), not call
> libxl__toolstack_save directly.
> 
> > The callback one seems to be otherwise unused.
> 
> Exactly.
> 
> I have fixed this:
> 
>   * libxl__xc_domain_save uses supplied callback function pointer,

                                ^ the ?
>     rather than calling libxl__toolstack_save directly;
>     toolstack data save callback is only supplied to libxc if
>     in-libxl caller supplied a callback.

     ^ "the" or "an"?

Otherwise looks good.

> > > +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> > > +                       const char *mode_arg, int data_fd,
> > > +                       const unsigned long *argnums, int num_argnums)
> > > +{
> ...
> > > +    libxl__carefd_begin();
> > > +    for (i=0; i<2; i++) {
> > > +        int fds[2];
> > > +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> > > +        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
> > > +        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);
> > 
> > Using !i here is clever, but I had to deploy a pen to be sure the
> > assignments were all correct.
> > 
> > Open coding this simple loop would also give you the opportunity the
> > have comments like "/* This is the helper processes's stdout */" etc in
> > the appropriate place to aid in comprehension when checking the correct
> > end of each pipe goes in the right place.
> 
> Perhaps the right answer is to use a better variable name than `i'.
> I wrote it out longhand and it looked like this:

[...]
> which is a great way to obscure the subtle differences between the two
> stanzas.  How about:
> 
>     libxl__carefd_begin();
>     int childfd;
>     for (childfd=0; childfd<2; childfd++) {
>         /* Setting up the pipe for the child's fd childfd */
>         int fds[2];
>         if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
>         int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
>         int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
>         childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
>         shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
>     }
>     libxl__carefd_unlock();
> 
> ?

Yes renaming that variable, adding those inline /*read*/ etc comments
and the local variable naming has really helped, thanks

> > > +        rc = ERROR_FAIL;
> > > + out:
> > > +        /* this is here because otherwise we bypass the decl of msg[] */
> > 
> > I don't get this comment, why can't "out:" be in the normal place after
> > the non-error return?
> 
> Because it is not legal to "goto" within the scope of a variable whose
> size is not a constant.

Ah OK, I didn't realise this, another interesting C quirk!

>   The alternative would be to introduce a block
> scope starting before `unsigned char msg[msglen]' and ending after
> `return'.
> 
> Arguably msg[msglen] is asking too much (up to 64K) of the caller's
> stack.  Should I change it ?

I think it's OK in a userspace process.

Although one thing to watch out for would be the stack guard page which
modern Linux has -- this can cause issues with large stack allocations
since you trigger the guard page instead of growing the stack like you'd
expect -- I suppose this is really a bug in your compiler and/or libc
but it does seem common enough to avoid for now...

> > > --- /dev/null
> > > +++ b/tools/libxl/libxl_save_helper.c
> > > @@ -0,0 +1,279 @@
> > > +/*
> > > + * Copyright (C) 2012      Citrix Ltd.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU Lesser General Public License as published
> > > + * by the Free Software Foundation; version 2.1 only. with the special
> > > + * exception on linking described in file LICENSE.
> > 
> > LGPL, or perhaps GPL since this is a helper?
> > 
> > (I suppose the same argument could be made for xl itself)
> 
> I can see no reason to deviate from the licence of the rest of libxl.
> If nothing else, code may move between the helper and libxl proper.

That's a very good point.

> 
> > > +int helper_getreply(void *user)
> > > +{
> > > +    int v;
> > > +    int r = read_exactly(0, &v, sizeof(v));
> > > +    if (r<=0) exit(-2);
> > 
> > You use -1 a lot but here you use -2, are we supposed to be able to
> > infer something from the specific error code?
> 
> Not really.  I used -1 for general system call failures.  This
> particular situation might include a protocol error by the parent,
> though, so I thought I'd distinguish it.  That way if you get a
> message saying the helper exited with a nonzero exit status foobar you
> get slightly more information.
> 
> I could make this more formal and be more consistent with these exit
> statuses, or alternatively I could abolish it.  I don't think it's
> critical - nothing turns on this exit status.

Lets just leave it then.

> > > +foreach my $ah (qw(callout helper)) {
> > > +    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
> > [...]
> > > +END
> > [...]
> > > +END
> > [...]
> > > +END
> > 
> > I think I can infer what this does, but wow ;-)
> 
> Following a suggestion from Mark Wooding I have changed this to:
> 
>           <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
>   #include "libxl_osdeps.h"
> 
>   #include <assert.h>
>   #include <string.h>
>   #include <stdint.h>
>   #include <limits.h>
>   END_BOTH
> 
>   #include "libxl_internal.h"
> 
>   END_CALLOUT
> 
>   #include "_libxl_save_msgs_${ah}.h"
>   #include <xenctrl.h>
>   #include <xenguest.h>
> 
>   END_HELPER
> 
> which I think is much clearer.

I agree with Mark, 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 Jun 19 13:51:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 13: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 1SgypJ-0001Q1-Dd; Tue, 19 Jun 2012 13:50: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 1SgypI-0001Pc-0R
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 13:50:36 +0000
Received: from [85.158.143.99:36142] by server-1.bemta-4.messagelabs.com id
	40/84-24392-9A380EF4; Tue, 19 Jun 2012 13:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340113831!18456432!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17750 invoked from network); 19 Jun 2012 13:50:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 13:50:32 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13103590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 13:50:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 14:50:31 +0100
Message-ID: <1340113830.24176.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 14:50:30 +0100
In-Reply-To: <20442.5612.626430.387995@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-6-git-send-email-ian.jackson@eu.citrix.com>
	<1339585498.24104.190.camel@zakaz.uk.xensource.com>
	<20442.5612.626430.387995@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/19] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > >  testidl: testidl.o libxlutil.so libxenlight.so
> > >         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> > [...]
> > > @@ -170,6 +184,7 @@ install: all
> > >         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
> > >         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
> > >         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> > > +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
> > 
> > This needs an INSTALL_DIR for $(DESTDIR)$(PRIVATE_BINDIR) to support
> > "make -C tools/libxl DESTDIR=xxx install" else:
> >         install: cannot create regular file `/tmp/tmplKa0Y7/usr/lib/xen/bin': No such file or directory
> 
> OK.  I guess I never do that and it's a bit of a mystery why one
> would without having done a more general install before, but it's
> clearly a correct change.

I build and install on a different machine, which means I install into
DESTDIR=`mkdtemp ...` and tar, copy etc. I do one full build to seed
everything and then incrementally just the dir I'm working in, so this
hits me because on the incremental ones the fresh DESTDIR doesn't have
the directory yet.

> 
> > > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > > index b48452c..fea0c94 100644
> ...
> > >  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> > > -        uint32_t size, void *data)
> ...
> > > +    libxl_ctx *ctx = CTX;
> > 
> > Any reason you didn't s/ctx/CTX/ in one of your preparatory patches?
> 
> I didn't want to do that unless it was necessary.  There was already
> enough else going on.  I don't think having a ctx rather than using
> CTX is wrong, although it is slightly less in the modern idiom.

Fair enough.

> 
> > >  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
> > >                             unsigned long vm_generationid_addr)
> > >  {
> > >      STATE_AO_GC(dss->ao);
> > > -    int r;
> > > +    int r, rc;
> > > +    uint32_t toolstack_data_len;
> > > +
> > > +    /* Resources we need to free */
> > > +    uint8_t *toolstack_data_buf = 0;
> > > +
> > > +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> > > +        (&dss->shs.callbacks.save.a);
> > > +
> > > +    r = libxl__toolstack_save(dss->domid, &toolstack_data_buf,
> > > +                              &toolstack_data_len, dss);
> > 
> > This seems to be called twice? I'm looking at the source after the full
> > series is applied and I see
> >         dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
> > in libxl__domain_suspend as well as this call here.
> 
> But in fact dss->shs.callbacks.save.toolstack_save is never used
> anywhere in that version.  The bug is that libxl__xc_domain_save
> should call the callback function (if it is non-null), not call
> libxl__toolstack_save directly.
> 
> > The callback one seems to be otherwise unused.
> 
> Exactly.
> 
> I have fixed this:
> 
>   * libxl__xc_domain_save uses supplied callback function pointer,

                                ^ the ?
>     rather than calling libxl__toolstack_save directly;
>     toolstack data save callback is only supplied to libxc if
>     in-libxl caller supplied a callback.

     ^ "the" or "an"?

Otherwise looks good.

> > > +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> > > +                       const char *mode_arg, int data_fd,
> > > +                       const unsigned long *argnums, int num_argnums)
> > > +{
> ...
> > > +    libxl__carefd_begin();
> > > +    for (i=0; i<2; i++) {
> > > +        int fds[2];
> > > +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> > > +        childs_pipes[i] = libxl__carefd_record(CTX, fds[i]);
> > > +        shs->pipes[i] = libxl__carefd_record(CTX, fds[!i]);
> > 
> > Using !i here is clever, but I had to deploy a pen to be sure the
> > assignments were all correct.
> > 
> > Open coding this simple loop would also give you the opportunity the
> > have comments like "/* This is the helper processes's stdout */" etc in
> > the appropriate place to aid in comprehension when checking the correct
> > end of each pipe goes in the right place.
> 
> Perhaps the right answer is to use a better variable name than `i'.
> I wrote it out longhand and it looked like this:

[...]
> which is a great way to obscure the subtle differences between the two
> stanzas.  How about:
> 
>     libxl__carefd_begin();
>     int childfd;
>     for (childfd=0; childfd<2; childfd++) {
>         /* Setting up the pipe for the child's fd childfd */
>         int fds[2];
>         if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
>         int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
>         int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
>         childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
>         shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
>     }
>     libxl__carefd_unlock();
> 
> ?

Yes renaming that variable, adding those inline /*read*/ etc comments
and the local variable naming has really helped, thanks

> > > +        rc = ERROR_FAIL;
> > > + out:
> > > +        /* this is here because otherwise we bypass the decl of msg[] */
> > 
> > I don't get this comment, why can't "out:" be in the normal place after
> > the non-error return?
> 
> Because it is not legal to "goto" within the scope of a variable whose
> size is not a constant.

Ah OK, I didn't realise this, another interesting C quirk!

>   The alternative would be to introduce a block
> scope starting before `unsigned char msg[msglen]' and ending after
> `return'.
> 
> Arguably msg[msglen] is asking too much (up to 64K) of the caller's
> stack.  Should I change it ?

I think it's OK in a userspace process.

Although one thing to watch out for would be the stack guard page which
modern Linux has -- this can cause issues with large stack allocations
since you trigger the guard page instead of growing the stack like you'd
expect -- I suppose this is really a bug in your compiler and/or libc
but it does seem common enough to avoid for now...

> > > --- /dev/null
> > > +++ b/tools/libxl/libxl_save_helper.c
> > > @@ -0,0 +1,279 @@
> > > +/*
> > > + * Copyright (C) 2012      Citrix Ltd.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU Lesser General Public License as published
> > > + * by the Free Software Foundation; version 2.1 only. with the special
> > > + * exception on linking described in file LICENSE.
> > 
> > LGPL, or perhaps GPL since this is a helper?
> > 
> > (I suppose the same argument could be made for xl itself)
> 
> I can see no reason to deviate from the licence of the rest of libxl.
> If nothing else, code may move between the helper and libxl proper.

That's a very good point.

> 
> > > +int helper_getreply(void *user)
> > > +{
> > > +    int v;
> > > +    int r = read_exactly(0, &v, sizeof(v));
> > > +    if (r<=0) exit(-2);
> > 
> > You use -1 a lot but here you use -2, are we supposed to be able to
> > infer something from the specific error code?
> 
> Not really.  I used -1 for general system call failures.  This
> particular situation might include a protocol error by the parent,
> though, so I thought I'd distinguish it.  That way if you get a
> message saying the helper exited with a nonzero exit status foobar you
> get slightly more information.
> 
> I could make this more formal and be more consistent with these exit
> statuses, or alternatively I could abolish it.  I don't think it's
> critical - nothing turns on this exit status.

Lets just leave it then.

> > > +foreach my $ah (qw(callout helper)) {
> > > +    $out_body{$ah} .= <<END.($ah eq 'callout' ? <<END : <<END);
> > [...]
> > > +END
> > [...]
> > > +END
> > [...]
> > > +END
> > 
> > I think I can infer what this does, but wow ;-)
> 
> Following a suggestion from Mark Wooding I have changed this to:
> 
>           <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
>   #include "libxl_osdeps.h"
> 
>   #include <assert.h>
>   #include <string.h>
>   #include <stdint.h>
>   #include <limits.h>
>   END_BOTH
> 
>   #include "libxl_internal.h"
> 
>   END_CALLOUT
> 
>   #include "_libxl_save_msgs_${ah}.h"
>   #include <xenctrl.h>
>   #include <xenguest.h>
> 
>   END_HELPER
> 
> which I think is much clearer.

I agree with Mark, 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 Jun 19 14:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 14:46: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 1SgzhF-0002DP-MO; Tue, 19 Jun 2012 14:46:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SgzhD-0002DK-T9
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 14:46:20 +0000
Received: from [85.158.143.99:4555] by server-1.bemta-4.messagelabs.com id
	3E/D6-24392-9B090EF4; Tue, 19 Jun 2012 14:46:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340117176!18468223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24936 invoked from network); 19 Jun 2012 14:46:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 14:46:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13105572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 14: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.213.0; Tue, 19 Jun 2012 15:46:16 +0100
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 1Sgzh9-0005SM-SJ;
	Tue, 19 Jun 2012 14:46:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sgzh9-0002xv-N0;
	Tue, 19 Jun 2012 15:46:15 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13090-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 15:46:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13090: 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 13090 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13090/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13047
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13047

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-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-win7-amd64 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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  11dfb8e06343
baseline version:
 xen                  a9c0a89c08f2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=11dfb8e06343
+ . 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 11dfb8e06343
+ branch=xen-4.1-testing
+ revision=11dfb8e06343
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 11dfb8e06343 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 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 Jun 19 14:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 14:46: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 1SgzhF-0002DP-MO; Tue, 19 Jun 2012 14:46:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SgzhD-0002DK-T9
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 14:46:20 +0000
Received: from [85.158.143.99:4555] by server-1.bemta-4.messagelabs.com id
	3E/D6-24392-9B090EF4; Tue, 19 Jun 2012 14:46:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340117176!18468223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24936 invoked from network); 19 Jun 2012 14:46:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 14:46:17 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13105572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 14: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.213.0; Tue, 19 Jun 2012 15:46:16 +0100
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 1Sgzh9-0005SM-SJ;
	Tue, 19 Jun 2012 14:46:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sgzh9-0002xv-N0;
	Tue, 19 Jun 2012 15:46:15 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13090-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 15:46:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13090: 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 13090 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13090/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13047
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13047

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-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-win7-amd64 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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  11dfb8e06343
baseline version:
 xen                  a9c0a89c08f2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=11dfb8e06343
+ . 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 11dfb8e06343
+ branch=xen-4.1-testing
+ revision=11dfb8e06343
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 11dfb8e06343 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 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 Jun 19 14:47:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 14:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgziC-0002Fe-3c; Tue, 19 Jun 2012 14:47:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SgziA-0002FT-50
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 14:47:18 +0000
Received: from [85.158.139.83:50358] by server-8.bemta-5.messagelabs.com id
	17/28-10278-5F090EF4; Tue, 19 Jun 2012 14:47:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340117236!17185120!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjQ1NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19055 invoked from network); 19 Jun 2012 14:47:16 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-182.messagelabs.com with SMTP;
	19 Jun 2012 14:47:16 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 7A4FD300061;
	Tue, 19 Jun 2012 07:47:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=lFj6/I+dnwMFfdNrKX825k
	WmJrF5BZl52/mYOKaXOFgsQLtMrcshpiuoRTaqYHSY8IymBxEcy0K5/A8TrJXN77
	C5iXqrRHycdful2JzG8r2hhNPwxJj7j0XvQ8RrrJRgqf/ozGx4zfQQhKG9EME8BU
	5oc7iIJIQ+lfhOTjibDRI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=8+g55JcC0REU
	fv/jJLBOPkwKt1c=; b=MLm1yktsQ/yvoi9sXMcO2492LDSr1mpL4WiFGTDjTDL5
	VN+8igRaTICqJrcGNVvxRN0OQ5gMICXdLpjRxB8oqbCZsl+nV+O+xQbY3UjyabNZ
	G14eO0G+5TVMpCLay+jfkOhKlS5Y0Y7MuKLMbmjMpvKCQp5QWr1aTYGKPgN4OIQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id E127D300059; 
	Tue, 19 Jun 2012 07:47:14 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: b3a8ef4c556cc9a2d310cd8dd1e2f625c92c8515
Message-Id: <b3a8ef4c556cc9a2d310.1340117300@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 19 Jun 2012 10:48:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Clean up unshare path for foreign
	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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c |  34 +++++++++++-----------------------
 1 files changed, 11 insertions(+), 23 deletions(-)


In its current shape, if Xen unshares a foreign gfn successfully while building
a foreign writable map, it is left with a reference to the old shared page in
the "target" var.

Instead, push unsharing request down on the initial get_page_from_gfn call,
which will DTRT.

This allows for greatly simplifying the unshare related condition handling,
removing ugly comments and s86_64 ifdef-ery.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f0806cb74009 -r b3a8ef4c556c xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3563,10 +3563,12 @@ int do_mmu_update(
                     l1_pgentry_t l1e = l1e_from_intpte(req.val);
                     p2m_type_t l1e_p2mt = p2m_ram_rw;
                     struct page_info *target = NULL;
+                    p2m_query_t q = (l1e_get_flags(l1e) & _PAGE_RW) ?
+                                        P2M_UNSHARE : P2M_ALLOC;
 
                     if ( paging_mode_translate(pg_owner) )
                         target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
-                                                   &l1e_p2mt, P2M_ALLOC);
+                                                   &l1e_p2mt, q);
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
@@ -3581,29 +3583,15 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-#ifdef __x86_64__
-                    /* XXX: Ugly: pull all the checks into a separate function. 
-                     * Don't want to do it now, not to interfere with mem_paging
-                     * patches */
-                    else if ( p2m_ram_shared == l1e_p2mt )
+                    /* If we tried to unshare and failed */
+                    else if ( (q & P2M_UNSHARE) && p2m_is_shared(l1e_p2mt) )
                     {
-                        /* Unshare the page for RW foreign mappings */
-                        if ( l1e_get_flags(l1e) & _PAGE_RW )
-                        {
-                            unsigned long gfn = l1e_get_pfn(l1e);
-                            rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
-                            if ( rc )
-                            {
-                                if ( target )
-                                    put_page(target);
-                                /* Notify helper, don't care about errors, will not
-                                 * sleep on wq, since we're a foreign domain. */
-                                (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
-                                break; 
-                            }
-                        }
-                    } 
-#endif
+                        /* We could not have obtained a page ref. */
+                        ASSERT(target == NULL);
+                        /* And mem_sharing_notify has already been called. */
+                        rc = -ENOMEM;
+                        break;
+                    }
 
                     rc = mod_l1_entry(va, l1e, mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 14:47:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 14:47:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SgziC-0002Fe-3c; Tue, 19 Jun 2012 14:47:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SgziA-0002FT-50
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 14:47:18 +0000
Received: from [85.158.139.83:50358] by server-8.bemta-5.messagelabs.com id
	17/28-10278-5F090EF4; Tue, 19 Jun 2012 14:47:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340117236!17185120!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjQ1NzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19055 invoked from network); 19 Jun 2012 14:47:16 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-182.messagelabs.com with SMTP;
	19 Jun 2012 14:47:16 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 7A4FD300061;
	Tue, 19 Jun 2012 07:47:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=lFj6/I+dnwMFfdNrKX825k
	WmJrF5BZl52/mYOKaXOFgsQLtMrcshpiuoRTaqYHSY8IymBxEcy0K5/A8TrJXN77
	C5iXqrRHycdful2JzG8r2hhNPwxJj7j0XvQ8RrrJRgqf/ozGx4zfQQhKG9EME8BU
	5oc7iIJIQ+lfhOTjibDRI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=8+g55JcC0REU
	fv/jJLBOPkwKt1c=; b=MLm1yktsQ/yvoi9sXMcO2492LDSr1mpL4WiFGTDjTDL5
	VN+8igRaTICqJrcGNVvxRN0OQ5gMICXdLpjRxB8oqbCZsl+nV+O+xQbY3UjyabNZ
	G14eO0G+5TVMpCLay+jfkOhKlS5Y0Y7MuKLMbmjMpvKCQp5QWr1aTYGKPgN4OIQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id E127D300059; 
	Tue, 19 Jun 2012 07:47:14 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: b3a8ef4c556cc9a2d310cd8dd1e2f625c92c8515
Message-Id: <b3a8ef4c556cc9a2d310.1340117300@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 19 Jun 2012 10:48:20 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: andres@gridcentric.ca, tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Clean up unshare path for foreign
	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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm.c |  34 +++++++++++-----------------------
 1 files changed, 11 insertions(+), 23 deletions(-)


In its current shape, if Xen unshares a foreign gfn successfully while building
a foreign writable map, it is left with a reference to the old shared page in
the "target" var.

Instead, push unsharing request down on the initial get_page_from_gfn call,
which will DTRT.

This allows for greatly simplifying the unshare related condition handling,
removing ugly comments and s86_64 ifdef-ery.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f0806cb74009 -r b3a8ef4c556c xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3563,10 +3563,12 @@ int do_mmu_update(
                     l1_pgentry_t l1e = l1e_from_intpte(req.val);
                     p2m_type_t l1e_p2mt = p2m_ram_rw;
                     struct page_info *target = NULL;
+                    p2m_query_t q = (l1e_get_flags(l1e) & _PAGE_RW) ?
+                                        P2M_UNSHARE : P2M_ALLOC;
 
                     if ( paging_mode_translate(pg_owner) )
                         target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e),
-                                                   &l1e_p2mt, P2M_ALLOC);
+                                                   &l1e_p2mt, q);
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
@@ -3581,29 +3583,15 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-#ifdef __x86_64__
-                    /* XXX: Ugly: pull all the checks into a separate function. 
-                     * Don't want to do it now, not to interfere with mem_paging
-                     * patches */
-                    else if ( p2m_ram_shared == l1e_p2mt )
+                    /* If we tried to unshare and failed */
+                    else if ( (q & P2M_UNSHARE) && p2m_is_shared(l1e_p2mt) )
                     {
-                        /* Unshare the page for RW foreign mappings */
-                        if ( l1e_get_flags(l1e) & _PAGE_RW )
-                        {
-                            unsigned long gfn = l1e_get_pfn(l1e);
-                            rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
-                            if ( rc )
-                            {
-                                if ( target )
-                                    put_page(target);
-                                /* Notify helper, don't care about errors, will not
-                                 * sleep on wq, since we're a foreign domain. */
-                                (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
-                                break; 
-                            }
-                        }
-                    } 
-#endif
+                        /* We could not have obtained a page ref. */
+                        ASSERT(target == NULL);
+                        /* And mem_sharing_notify has already been called. */
+                        rc = -ENOMEM;
+                        break;
+                    }
 
                     rc = mod_l1_entry(va, l1e, mfn,
                                       cmd == MMU_PT_UPDATE_PRESERVE_AD, v,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 15:21:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 15:21: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 1Sh0Ep-00031j-LQ; Tue, 19 Jun 2012 15:21: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 1Sh0Eo-00031e-AS
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 15:21:02 +0000
Received: from [85.158.139.83:51742] by server-3.bemta-5.messagelabs.com id
	EF/AE-03367-DD890EF4; Tue, 19 Jun 2012 15:21:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340119260!28734593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20339 invoked from network); 19 Jun 2012 15:21:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 15:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13106398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 15:15:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 16:15:51 +0100
Message-ID: <1340118949.24176.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 16:15:49 +0100
In-Reply-To: <20448.30820.166288.216230@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
	<20442.706.194448.288137@mariner.uk.xensource.com>
	<1340100279.16742.10.camel@zakaz.uk.xensource.com>
	<20448.30820.166288.216230@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 14:02 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> > On Thu, 2012-06-14 at 16:26 +0100, Ian Jackson wrote:
> > > How about "remus_target_gone_cb" ?
> > 
> > Sounds fine to me, unless you want to work the word "failover" into it?
> 
> remus_failover_cb ?

Sounds good.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 15:21:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 15:21: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 1Sh0Ep-00031j-LQ; Tue, 19 Jun 2012 15:21: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 1Sh0Eo-00031e-AS
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 15:21:02 +0000
Received: from [85.158.139.83:51742] by server-3.bemta-5.messagelabs.com id
	EF/AE-03367-DD890EF4; Tue, 19 Jun 2012 15:21:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340119260!28734593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20339 invoked from network); 19 Jun 2012 15:21:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 15:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13106398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 15:15:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 16:15:51 +0100
Message-ID: <1340118949.24176.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 19 Jun 2012 16:15:49 +0100
In-Reply-To: <20448.30820.166288.216230@mariner.uk.xensource.com>
References: <1339176870-32652-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339176870-32652-5-git-send-email-ian.jackson@eu.citrix.com>
	<1339519893.24104.115.camel@zakaz.uk.xensource.com>
	<20442.706.194448.288137@mariner.uk.xensource.com>
	<1340100279.16742.10.camel@zakaz.uk.xensource.com>
	<20448.30820.166288.216230@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 14:02 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/19] libxl: domain save: API changes for asynchrony"):
> > On Thu, 2012-06-14 at 16:26 +0100, Ian Jackson wrote:
> > > How about "remus_target_gone_cb" ?
> > 
> > Sounds fine to me, unless you want to work the word "failover" into it?
> 
> remus_failover_cb ?

Sounds good.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 15:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 15: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 1Sh0pH-0003Ny-TE; Tue, 19 Jun 2012 15:58:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sh0pG-0003Nt-8e
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 15:58:42 +0000
Received: from [85.158.138.51:34190] by server-1.bemta-3.messagelabs.com id
	43/0B-14648-1B1A0EF4; Tue, 19 Jun 2012 15:58:41 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340121519!28557378!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU2NDE5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22754 invoked from network); 19 Jun 2012 15:58:40 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 15:58:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340121520; x=1371657520;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=L0vQyw4q5iigq7R8tQ6csNGPTQTZxHzYBMPqhLb2rz0=;
	b=eHBBw0T8EqJORCpc1EruRTxZqmNrLtlEUv6QIjBAQSnVSGu36OXLdMQN
	r52xhhvT4iw6xjh4FJKLlPLZ8zpvhg==;
X-IronPort-AV: E=Sophos;i="4.77,437,1336348800"; d="scan'208";a="317515570"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2012 15:58:35 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-47-94.sea3.amazon.com [10.50.47.94])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5JFwYYt014673; Tue, 19 Jun 2012 15:58:34 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Tue, 19 Jun 2012 08:58:29 -0700
Date: Tue, 19 Jun 2012 08:58:28 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120619155828.GA4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340103453.24176.7.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such 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, Jun 19, 2012 at 03:57:33AM -0700, Ian Campbell wrote:
> On Tue, 2012-06-19 at 09:35 +0100, Thanos Makatos wrote:
> > I have the same problem on xen-unstable 54c8c9eaee92+. I think
> > libfsimage comes with xen (in my repo it's under ./tools/libfsimage).
> > I've investigated a bit and found that in my occasion libfsimage tries
> > to access directory /usr/lib64/fs which doesn't exist,
> > whereas /usr/lib/fs does. I linked /usr/lib64/fs to /usr/lib/fs but
> > then I got other problems, don't remember what. I don't know if this
> > has to do with the fact that my dom0 is 64bit (Debian unstable), or
> > that the domU is 64bit (Debian unstable again), or both.
> 
> Aha I'd been puzzling over why people had been seeing this but I'm not! 
> 
> This very likely is to do with Debian and Ubuntu's transition to
> "multiarch" which has necessitated removing the old compatibility
> symlink /usr/lib64 -> /usr/lib.
> 
> lib64 is a RPMism which doesn't really apply to Debian and derivatives
> and therefore you need to tweak your Xen config before building. I use
> the following local configuration patch (I should probably do the
> equivalent in .config):

lib64 isn't an RPMism, its a Filesystem Hiarchary Standardism [1].

Pretty much every distribution but Debian (and derivatives) adopted
lib64 for all platforms where running 32-bit binaries was common place
(read: all platforms but Alpha and Itanium).

Matt Taggart proposed multiarch for Debian in 2004 (where Red Hat and
SUSE already had support for running a mix of 32-bit and 64-bit
applications on one system), which is captured in the Debian wiki [2].
Ubuntu added support for co-installing 32-bit and 64-bit software in
11.04 [3].

I'm a bit surprised that Debian and Ubuntu can't continue to have a
symlink for lib64 that points at lib/x86_64-linux-gnu. No matter since
I suppose the correct fix is to install the plugins in /usr/lib/$target/fs 
and define FSIMAGE_FSDIR to point there when building libfsimage on
systems that implement multiarch.

Matt

[1] http://www.pathname.com/fhs/
[2] http://wiki.debian.org/Multiarch/TheCaseForMultiarch
[3] https://wiki.ubuntu.com/MultiarchSpec

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 15:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 15: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 1Sh0pH-0003Ny-TE; Tue, 19 Jun 2012 15:58:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sh0pG-0003Nt-8e
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 15:58:42 +0000
Received: from [85.158.138.51:34190] by server-1.bemta-3.messagelabs.com id
	43/0B-14648-1B1A0EF4; Tue, 19 Jun 2012 15:58:41 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340121519!28557378!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU2NDE5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22754 invoked from network); 19 Jun 2012 15:58:40 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 15:58:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340121520; x=1371657520;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=L0vQyw4q5iigq7R8tQ6csNGPTQTZxHzYBMPqhLb2rz0=;
	b=eHBBw0T8EqJORCpc1EruRTxZqmNrLtlEUv6QIjBAQSnVSGu36OXLdMQN
	r52xhhvT4iw6xjh4FJKLlPLZ8zpvhg==;
X-IronPort-AV: E=Sophos;i="4.77,437,1336348800"; d="scan'208";a="317515570"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2012 15:58:35 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-47-94.sea3.amazon.com [10.50.47.94])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5JFwYYt014673; Tue, 19 Jun 2012 15:58:34 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Tue, 19 Jun 2012 08:58:29 -0700
Date: Tue, 19 Jun 2012 08:58:28 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120619155828.GA4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340103453.24176.7.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such 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, Jun 19, 2012 at 03:57:33AM -0700, Ian Campbell wrote:
> On Tue, 2012-06-19 at 09:35 +0100, Thanos Makatos wrote:
> > I have the same problem on xen-unstable 54c8c9eaee92+. I think
> > libfsimage comes with xen (in my repo it's under ./tools/libfsimage).
> > I've investigated a bit and found that in my occasion libfsimage tries
> > to access directory /usr/lib64/fs which doesn't exist,
> > whereas /usr/lib/fs does. I linked /usr/lib64/fs to /usr/lib/fs but
> > then I got other problems, don't remember what. I don't know if this
> > has to do with the fact that my dom0 is 64bit (Debian unstable), or
> > that the domU is 64bit (Debian unstable again), or both.
> 
> Aha I'd been puzzling over why people had been seeing this but I'm not! 
> 
> This very likely is to do with Debian and Ubuntu's transition to
> "multiarch" which has necessitated removing the old compatibility
> symlink /usr/lib64 -> /usr/lib.
> 
> lib64 is a RPMism which doesn't really apply to Debian and derivatives
> and therefore you need to tweak your Xen config before building. I use
> the following local configuration patch (I should probably do the
> equivalent in .config):

lib64 isn't an RPMism, its a Filesystem Hiarchary Standardism [1].

Pretty much every distribution but Debian (and derivatives) adopted
lib64 for all platforms where running 32-bit binaries was common place
(read: all platforms but Alpha and Itanium).

Matt Taggart proposed multiarch for Debian in 2004 (where Red Hat and
SUSE already had support for running a mix of 32-bit and 64-bit
applications on one system), which is captured in the Debian wiki [2].
Ubuntu added support for co-installing 32-bit and 64-bit software in
11.04 [3].

I'm a bit surprised that Debian and Ubuntu can't continue to have a
symlink for lib64 that points at lib/x86_64-linux-gnu. No matter since
I suppose the correct fix is to install the plugins in /usr/lib/$target/fs 
and define FSIMAGE_FSDIR to point there when building libfsimage on
systems that implement multiarch.

Matt

[1] http://www.pathname.com/fhs/
[2] http://wiki.debian.org/Multiarch/TheCaseForMultiarch
[3] https://wiki.ubuntu.com/MultiarchSpec

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 16:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sh11A-00040E-3j; Tue, 19 Jun 2012 16:11:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sh118-000409-5P
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:10:58 +0000
Received: from [85.158.143.35:56314] by server-2.bemta-4.messagelabs.com id
	16/72-17938-194A0EF4; Tue, 19 Jun 2012 16:10:57 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340122254!12352519!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjkzNjY2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 19 Jun 2012 16:10:56 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:10:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340122256; x=1371658256;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:content-transfer-encoding:in-reply-to;
	bh=2LTuSsqQmiNjLA3GXA72pc+ftrTvliQ79H+/juDbarM=;
	b=mHPjVygQl3yjaJFsVcDZZtNcN2833e2NC/SyRQQbGcsPeayxlqQQsvy8
	X8WFYAC9RZv1kUgrcOoT1PGX8FMz6Q==;
X-IronPort-AV: E=Sophos;i="4.77,437,1336348800"; d="scan'208";a="984521537"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2012 16:10:47 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-47-94.sea3.amazon.com [10.50.47.94])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5JGAiYb028608; Tue, 19 Jun 2012 16:10:44 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Tue, 19 Jun 2012 09:10:39 -0700
Date: Tue, 19 Jun 2012 09:10:39 -0700
From: Matt Wilson <msw@amazon.com>
To: Mohammad Hedayati <hedayati.mo@gmail.com>
Message-ID: <20120619161039.GB4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such 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="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, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
> > # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
> > # Parent =A080c0677f0f8370a4542aab81ab93380b0dab25db
> > imported patch debian-lib-dir.patch
> >
> > diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
> > --- a/config/StdGNU.mk =A0Wed Jun 13 09:27:53 2012 +0100
> > +++ b/config/StdGNU.mk =A0Wed Jun 13 09:27:53 2012 +0100
> > @@ -34,7 +34,7 @@ BINDIR =3D $(PREFIX)/bin
> > =A0INCLUDEDIR =3D $(PREFIX)/include
> > =A0LIBLEAFDIR =3D lib
> > =A0LIBLEAFDIR_x86_32 =3D lib
> > -LIBLEAFDIR_x86_64 ?=3D lib64
> > +LIBLEAFDIR_x86_64 ?=3D lib
> > =A0LIBDIR =3D $(PREFIX)/$(LIBLEAFDIR)
> > =A0LIBDIR_x86_32 =3D $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > =A0LIBDIR_x86_64 =3D $(PREFIX)/$(LIBLEAFDIR_x86_64)
> >
> > Can you try a fresh build with this applied and see if that helps.
> I have applied this patch. I think libfsimage is somehow not being
> affected with this. Yet, linking /usr/lib64/fs -> /usr/lib/fs solves
> the problem.

libfsimage is going to blindly look in /usr/lib64 on non-Itanium
64-bit Linux platforms. See tools/libfsimage/common/fsimage_plugin.c:134

#if defined(FSIMAGE_FSDIR)
        if (fsdir =3D=3D NULL)
                fsdir =3D FSIMAGE_FSDIR;
#elif defined(__sun__)
        if (fsdir =3D=3D NULL)
                fsdir =3D "/usr/lib/fs";

        if (sizeof(void *) =3D=3D 8)
                isadir =3D "64/";
#elif defined(__ia64__)
        if (fsdir =3D=3D NULL)
                fsdir =3D "/usr/lib/fs";
#else
        if (fsdir =3D=3D NULL) {
                if (sizeof(void *) =3D=3D 8)
                        fsdir =3D "/usr/lib64/fs";
                else
                        fsdir =3D "/usr/lib/fs";
        }
#endif

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:11:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 16:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sh11A-00040E-3j; Tue, 19 Jun 2012 16:11:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sh118-000409-5P
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:10:58 +0000
Received: from [85.158.143.35:56314] by server-2.bemta-4.messagelabs.com id
	16/72-17938-194A0EF4; Tue, 19 Jun 2012 16:10:57 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340122254!12352519!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjkzNjY2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 19 Jun 2012 16:10:56 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:10:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340122256; x=1371658256;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:content-transfer-encoding:in-reply-to;
	bh=2LTuSsqQmiNjLA3GXA72pc+ftrTvliQ79H+/juDbarM=;
	b=mHPjVygQl3yjaJFsVcDZZtNcN2833e2NC/SyRQQbGcsPeayxlqQQsvy8
	X8WFYAC9RZv1kUgrcOoT1PGX8FMz6Q==;
X-IronPort-AV: E=Sophos;i="4.77,437,1336348800"; d="scan'208";a="984521537"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2012 16:10:47 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-47-94.sea3.amazon.com [10.50.47.94])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5JGAiYb028608; Tue, 19 Jun 2012 16:10:44 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Tue, 19 Jun 2012 09:10:39 -0700
Date: Tue, 19 Jun 2012 09:10:39 -0700
From: Matt Wilson <msw@amazon.com>
To: Mohammad Hedayati <hedayati.mo@gmail.com>
Message-ID: <20120619161039.GB4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such 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="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, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
> > # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
> > # Parent =A080c0677f0f8370a4542aab81ab93380b0dab25db
> > imported patch debian-lib-dir.patch
> >
> > diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
> > --- a/config/StdGNU.mk =A0Wed Jun 13 09:27:53 2012 +0100
> > +++ b/config/StdGNU.mk =A0Wed Jun 13 09:27:53 2012 +0100
> > @@ -34,7 +34,7 @@ BINDIR =3D $(PREFIX)/bin
> > =A0INCLUDEDIR =3D $(PREFIX)/include
> > =A0LIBLEAFDIR =3D lib
> > =A0LIBLEAFDIR_x86_32 =3D lib
> > -LIBLEAFDIR_x86_64 ?=3D lib64
> > +LIBLEAFDIR_x86_64 ?=3D lib
> > =A0LIBDIR =3D $(PREFIX)/$(LIBLEAFDIR)
> > =A0LIBDIR_x86_32 =3D $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > =A0LIBDIR_x86_64 =3D $(PREFIX)/$(LIBLEAFDIR_x86_64)
> >
> > Can you try a fresh build with this applied and see if that helps.
> I have applied this patch. I think libfsimage is somehow not being
> affected with this. Yet, linking /usr/lib64/fs -> /usr/lib/fs solves
> the problem.

libfsimage is going to blindly look in /usr/lib64 on non-Itanium
64-bit Linux platforms. See tools/libfsimage/common/fsimage_plugin.c:134

#if defined(FSIMAGE_FSDIR)
        if (fsdir =3D=3D NULL)
                fsdir =3D FSIMAGE_FSDIR;
#elif defined(__sun__)
        if (fsdir =3D=3D NULL)
                fsdir =3D "/usr/lib/fs";

        if (sizeof(void *) =3D=3D 8)
                isadir =3D "64/";
#elif defined(__ia64__)
        if (fsdir =3D=3D NULL)
                fsdir =3D "/usr/lib/fs";
#else
        if (fsdir =3D=3D NULL) {
                if (sizeof(void *) =3D=3D 8)
                        fsdir =3D "/usr/lib64/fs";
                else
                        fsdir =3D "/usr/lib/fs";
        }
#endif

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:14:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 16:14: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 1Sh144-00046U-MB; Tue, 19 Jun 2012 16:14: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 1Sh142-00046P-9E
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:13:58 +0000
Received: from [85.158.139.83:30715] by server-11.bemta-5.messagelabs.com id
	64/89-20400-545A0EF4; Tue, 19 Jun 2012 16:13:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340122436!24513282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13736 invoked from network); 19 Jun 2012 16:13:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:13:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13107747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 16:13:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 17:13:51 +0100
Message-ID: <1340122429.24176.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 19 Jun 2012 17:13:49 +0100
In-Reply-To: <20120619155828.GA4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<20120619155828.GA4296@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 16:58 +0100, Matt Wilson wrote:
> On Tue, Jun 19, 2012 at 03:57:33AM -0700, Ian Campbell wrote:
> > On Tue, 2012-06-19 at 09:35 +0100, Thanos Makatos wrote:
> > lib64 is a RPMism which doesn't really apply to Debian and derivatives
> > and therefore you need to tweak your Xen config before building. I use
> > the following local configuration patch (I should probably do the
> > equivalent in .config):
> 
> lib64 isn't an RPMism, its a Filesystem Hiarchary Standardism [1].

Yes, right, I keep making that mistake.

[...]

> I'm a bit surprised that Debian and Ubuntu can't continue to have a
> symlink for lib64 that points at lib/x86_64-linux-gnu.

I'm not sure either.

> No matter since
> I suppose the correct fix is to install the plugins in /usr/lib/$target/fs 
> and define FSIMAGE_FSDIR to point there when building libfsimage on
> systems that implement multiarch.

I think the current use of $(LIBDIR)/fs/... is correct -- assuming you
actually set LIBDIR to the correct thing (which would
be /usr/lib/$target on a multiarch system).

In the meantime I think defaulting to autodetecting /usr/lib
vs. /usr/lib64 would make things continue to work. multiarch is more of
a packaging thing and the config snippets allow maintainers to do the
right thing).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:14:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 16:14: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 1Sh144-00046U-MB; Tue, 19 Jun 2012 16:14: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 1Sh142-00046P-9E
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:13:58 +0000
Received: from [85.158.139.83:30715] by server-11.bemta-5.messagelabs.com id
	64/89-20400-545A0EF4; Tue, 19 Jun 2012 16:13:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340122436!24513282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13736 invoked from network); 19 Jun 2012 16:13:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:13:57 -0000
X-IronPort-AV: E=Sophos;i="4.75,798,1330905600"; d="scan'208";a="13107747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 16:13:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 17:13:51 +0100
Message-ID: <1340122429.24176.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 19 Jun 2012 17:13:49 +0100
In-Reply-To: <20120619155828.GA4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<20120619155828.GA4296@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 16:58 +0100, Matt Wilson wrote:
> On Tue, Jun 19, 2012 at 03:57:33AM -0700, Ian Campbell wrote:
> > On Tue, 2012-06-19 at 09:35 +0100, Thanos Makatos wrote:
> > lib64 is a RPMism which doesn't really apply to Debian and derivatives
> > and therefore you need to tweak your Xen config before building. I use
> > the following local configuration patch (I should probably do the
> > equivalent in .config):
> 
> lib64 isn't an RPMism, its a Filesystem Hiarchary Standardism [1].

Yes, right, I keep making that mistake.

[...]

> I'm a bit surprised that Debian and Ubuntu can't continue to have a
> symlink for lib64 that points at lib/x86_64-linux-gnu.

I'm not sure either.

> No matter since
> I suppose the correct fix is to install the plugins in /usr/lib/$target/fs 
> and define FSIMAGE_FSDIR to point there when building libfsimage on
> systems that implement multiarch.

I think the current use of $(LIBDIR)/fs/... is correct -- assuming you
actually set LIBDIR to the correct thing (which would
be /usr/lib/$target on a multiarch system).

In the meantime I think defaulting to autodetecting /usr/lib
vs. /usr/lib64 would make things continue to work. multiarch is more of
a packaging thing and the config snippets allow maintainers to do the
right thing).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:34:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 16: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 1Sh1NQ-0004jf-In; Tue, 19 Jun 2012 16:34: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 1Sh1NP-0004jM-6h
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:33:59 +0000
Received: from [85.158.139.83:48318] by server-9.bemta-5.messagelabs.com id
	D2/33-01069-6F9A0EF4; Tue, 19 Jun 2012 16:33:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340123637!25755138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 647 invoked from network); 19 Jun 2012 16:33:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="13108111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 16:33:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 17:33:38 +0100
Message-ID: <1340123614.24176.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 19 Jun 2012 17:33:34 +0100
In-Reply-To: <1340122429.24176.43.camel@zakaz.uk.xensource.com>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<20120619155828.GA4296@US-SEA-R8XVZTX>
	<1340122429.24176.43.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 17:13 +0100, Ian Campbell wrote:
> In the meantime I think defaulting to autodetecting /usr/lib
> vs. /usr/lib64 would make things continue to work. multiarch is more
> of a packaging thing and the config snippets allow maintainers to do
> the right thing). 

Or maybe we should ditch LIBLEAFDIR_x86_32 and LIBLEAFDIR_x86_64 etc and
just have LIBDIR which defaults to /usr/lib but is settable
via ./configure --libdir=...?

This seems to be the norm for configure using build systems so it
shouldn't be all that surprising.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:34:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 16: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 1Sh1NQ-0004jf-In; Tue, 19 Jun 2012 16:34: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 1Sh1NP-0004jM-6h
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:33:59 +0000
Received: from [85.158.139.83:48318] by server-9.bemta-5.messagelabs.com id
	D2/33-01069-6F9A0EF4; Tue, 19 Jun 2012 16:33:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340123637!25755138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 647 invoked from network); 19 Jun 2012 16:33:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="13108111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 16:33:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 17:33:38 +0100
Message-ID: <1340123614.24176.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 19 Jun 2012 17:33:34 +0100
In-Reply-To: <1340122429.24176.43.camel@zakaz.uk.xensource.com>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<20120619155828.GA4296@US-SEA-R8XVZTX>
	<1340122429.24176.43.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 17:13 +0100, Ian Campbell wrote:
> In the meantime I think defaulting to autodetecting /usr/lib
> vs. /usr/lib64 would make things continue to work. multiarch is more
> of a packaging thing and the config snippets allow maintainers to do
> the right thing). 

Or maybe we should ditch LIBLEAFDIR_x86_32 and LIBLEAFDIR_x86_64 etc and
just have LIBDIR which defaults to /usr/lib but is settable
via ./configure --libdir=...?

This seems to be the norm for configure using build systems so it
shouldn't be all that surprising.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:36:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 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 1Sh1Pk-0004qV-PH; Tue, 19 Jun 2012 16:36: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 1Sh1Pj-0004qI-9n
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:36:23 +0000
Received: from [193.109.254.147:16698] by server-7.bemta-14.messagelabs.com id
	B4/E1-29827-68AA0EF4; Tue, 19 Jun 2012 16:36:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340123781!4883287!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4076 invoked from network); 19 Jun 2012 16:36:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="13108165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 16:36:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 17:36:21 +0100
Message-ID: <1340123764.24176.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 19 Jun 2012 17:36:04 +0100
In-Reply-To: <20120619161039.GB4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
	<20120619161039.GB4296@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 17:10 +0100, Matt Wilson wrote:
> On Tue, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
> > > # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
> > > # Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
> > > imported patch debian-lib-dir.patch
> > >
> > > diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
> > > --- a/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> > > +++ b/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> > > @@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
> > >  INCLUDEDIR = $(PREFIX)/include
> > >  LIBLEAFDIR = lib
> > >  LIBLEAFDIR_x86_32 = lib
> > > -LIBLEAFDIR_x86_64 ?= lib64
> > > +LIBLEAFDIR_x86_64 ?= lib
> > >  LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > >  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > >  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > >
> > > Can you try a fresh build with this applied and see if that helps.
> > I have applied this patch. I think libfsimage is somehow not being
> > affected with this. Yet, linking /usr/lib64/fs -> /usr/lib/fs solves
> > the problem.
> 
> libfsimage is going to blindly look in /usr/lib64 on non-Itanium
> 64-bit Linux platforms. See tools/libfsimage/common/fsimage_plugin.c:134

Oh bloody hell, I hadn't spotted that.

We should definitely be setting FSIMAGE_FSDIR to something sane based on
LIBDIR and not letting all sorts of weird heuristics kick in.

Ian.

> 
> #if defined(FSIMAGE_FSDIR)
>         if (fsdir == NULL)
>                 fsdir = FSIMAGE_FSDIR;
> #elif defined(__sun__)
>         if (fsdir == NULL)
>                 fsdir = "/usr/lib/fs";
> 
>         if (sizeof(void *) == 8)
>                 isadir = "64/";
> #elif defined(__ia64__)
>         if (fsdir == NULL)
>                 fsdir = "/usr/lib/fs";
> #else
>         if (fsdir == NULL) {
>                 if (sizeof(void *) == 8)
>                         fsdir = "/usr/lib64/fs";
>                 else
>                         fsdir = "/usr/lib/fs";
>         }
> #endif
> 
> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:36:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 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 1Sh1Pk-0004qV-PH; Tue, 19 Jun 2012 16:36: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 1Sh1Pj-0004qI-9n
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:36:23 +0000
Received: from [193.109.254.147:16698] by server-7.bemta-14.messagelabs.com id
	B4/E1-29827-68AA0EF4; Tue, 19 Jun 2012 16:36:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340123781!4883287!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4076 invoked from network); 19 Jun 2012 16:36:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 16:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="13108165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 16:36:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 19 Jun 2012 17:36:21 +0100
Message-ID: <1340123764.24176.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 19 Jun 2012 17:36:04 +0100
In-Reply-To: <20120619161039.GB4296@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
	<20120619161039.GB4296@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Mohammad Hedayati <hedayati.mo@gmail.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 17:10 +0100, Matt Wilson wrote:
> On Tue, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
> > > # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
> > > # Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
> > > imported patch debian-lib-dir.patch
> > >
> > > diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
> > > --- a/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> > > +++ b/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> > > @@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
> > >  INCLUDEDIR = $(PREFIX)/include
> > >  LIBLEAFDIR = lib
> > >  LIBLEAFDIR_x86_32 = lib
> > > -LIBLEAFDIR_x86_64 ?= lib64
> > > +LIBLEAFDIR_x86_64 ?= lib
> > >  LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > >  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > >  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > >
> > > Can you try a fresh build with this applied and see if that helps.
> > I have applied this patch. I think libfsimage is somehow not being
> > affected with this. Yet, linking /usr/lib64/fs -> /usr/lib/fs solves
> > the problem.
> 
> libfsimage is going to blindly look in /usr/lib64 on non-Itanium
> 64-bit Linux platforms. See tools/libfsimage/common/fsimage_plugin.c:134

Oh bloody hell, I hadn't spotted that.

We should definitely be setting FSIMAGE_FSDIR to something sane based on
LIBDIR and not letting all sorts of weird heuristics kick in.

Ian.

> 
> #if defined(FSIMAGE_FSDIR)
>         if (fsdir == NULL)
>                 fsdir = FSIMAGE_FSDIR;
> #elif defined(__sun__)
>         if (fsdir == NULL)
>                 fsdir = "/usr/lib/fs";
> 
>         if (sizeof(void *) == 8)
>                 isadir = "64/";
> #elif defined(__ia64__)
>         if (fsdir == NULL)
>                 fsdir = "/usr/lib/fs";
> #else
>         if (fsdir == NULL) {
>                 if (sizeof(void *) == 8)
>                         fsdir = "/usr/lib64/fs";
>                 else
>                         fsdir = "/usr/lib/fs";
>         }
> #endif
> 
> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 16:49:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 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 1Sh1bl-0005Me-1T; Tue, 19 Jun 2012 16:48:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Sh1bj-0005MW-Eh
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:48:47 +0000
Received: from [85.158.138.51:4496] by server-12.bemta-3.messagelabs.com id
	E4/4F-30206-E6DA0EF4; Tue, 19 Jun 2012 16:48:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340124524!28540348!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTkzODQw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19921 invoked from network); 19 Jun 2012 16:48:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jun 2012 16:48:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5JGmgdW020957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Jun 2012 16:48:42 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
	q5JGmfTQ011836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2012 16:48:41 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q5JGmfnT006502; Tue, 19 Jun 2012 11:48:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Jun 2012 09:48:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C0CA8402B8; Tue, 19 Jun 2012 12:41:07 -0400 (EDT)
Date: Tue, 19 Jun 2012 12:41:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Message-ID: <20120619164107.GA24413@phenom.dumpdata.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 19, 2012 at 09:49:12AM -0400, Shakeel Butt wrote:
> I previously email at xen-user list but didn't get any response. I am
> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.

Wow. That is quite ancient. Do you see the same problem with the latest
Linux kernel?

> =

> =

> ---------- Forwarded message ----------
> From: Shakeel Butt <shakeel.butt@gmail.com>
> Date: Mon, Jun 18, 2012 at 10:06 AM
> Subject: netback (Network backend) in domU
> To: xen-users@lists.xen.org
> =

> =

> Hi,
> =

> I am trying to setup a domU as a network backend for some other domUs.
> I configured bridge in netback-domU using network-bridge script (not a
> driver domain). I am assigning static ip addresses to all domUs.
> Something like =A0dom0 <-> netback-domU <-> other-domU.
> =

> In the setup, netback-domU and other-domU are able to ping each other
> but whenever I tried to ping dom0 from other-domU, I get a XEN error
> message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
> dom0 kernel "#### netback grant fails".
> =

> I didn't check if dom0 is trying to pin grant frame of other-domU but
> why dom0 would do it. Please any help will be appreciated.

Looks like a bug in the old code.
> =

> BTW does the bridge in dom0 needs to know that one of its interface is
> connected to another bridge in netback-domU? (don't know how or why)

No.
> =

> thanks,
> Shakeel
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 19 16:49:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 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 1Sh1bl-0005Me-1T; Tue, 19 Jun 2012 16:48:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Sh1bj-0005MW-Eh
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 16:48:47 +0000
Received: from [85.158.138.51:4496] by server-12.bemta-3.messagelabs.com id
	E4/4F-30206-E6DA0EF4; Tue, 19 Jun 2012 16:48:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340124524!28540348!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTkzODQw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19921 invoked from network); 19 Jun 2012 16:48:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jun 2012 16:48:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5JGmgdW020957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Jun 2012 16:48:42 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
	q5JGmfTQ011836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2012 16:48:41 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q5JGmfnT006502; Tue, 19 Jun 2012 11:48:41 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Jun 2012 09:48:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C0CA8402B8; Tue, 19 Jun 2012 12:41:07 -0400 (EDT)
Date: Tue, 19 Jun 2012 12:41:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Message-ID: <20120619164107.GA24413@phenom.dumpdata.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 19, 2012 at 09:49:12AM -0400, Shakeel Butt wrote:
> I previously email at xen-user list but didn't get any response. I am
> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.

Wow. That is quite ancient. Do you see the same problem with the latest
Linux kernel?

> =

> =

> ---------- Forwarded message ----------
> From: Shakeel Butt <shakeel.butt@gmail.com>
> Date: Mon, Jun 18, 2012 at 10:06 AM
> Subject: netback (Network backend) in domU
> To: xen-users@lists.xen.org
> =

> =

> Hi,
> =

> I am trying to setup a domU as a network backend for some other domUs.
> I configured bridge in netback-domU using network-bridge script (not a
> driver domain). I am assigning static ip addresses to all domUs.
> Something like =A0dom0 <-> netback-domU <-> other-domU.
> =

> In the setup, netback-domU and other-domU are able to ping each other
> but whenever I tried to ping dom0 from other-domU, I get a XEN error
> message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
> dom0 kernel "#### netback grant fails".
> =

> I didn't check if dom0 is trying to pin grant frame of other-domU but
> why dom0 would do it. Please any help will be appreciated.

Looks like a bug in the old code.
> =

> BTW does the bridge in dom0 needs to know that one of its interface is
> connected to another bridge in netback-domU? (don't know how or why)

No.
> =

> thanks,
> Shakeel
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 19 17:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 17: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 1Sh1z8-0005iD-4d; Tue, 19 Jun 2012 17:12:58 +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 1Sh1z6-0005i8-B3
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 17:12:56 +0000
Received: from [85.158.139.83:43406] by server-9.bemta-5.messagelabs.com id
	EC/18-01069-713B0EF4; Tue, 19 Jun 2012 17:12:55 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340125974!28386790!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20875 invoked from network); 19 Jun 2012 17:12:54 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 17:12:54 -0000
Received: by eeke50 with SMTP id e50so2921113eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 19 Jun 2012 10:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KTTFxNQh+TnG3v5dA2ayVTFAmJEQjh5GM38WY0JpJJg=;
	b=wrdKmnHlqshY7e9Icw2MaNseLyGcR4Qfd4FpIlYoYAIlQ30VqQGllOsjjcKrtvC0Qi
	RgkVAyyb/KUEND01qxVOpHUoHDVNaO91TCi3kTrecRmp/fngHAkNPpCFIq4XARKcgqXY
	7xj3TLZlr2v00flv2GVehZ8GrrZgR1xnAhlyjxrxpgO4xIvHIQSN6/l+WcfvABKE3dLM
	YSJBOrVNbaV/gbsXAcaWUB1tiz8MGCAT3A72cVITvz55QZSNA234HcRpbVyegIGmloVm
	KyaYlrRMCUfPruZ8l+1rUjFOKYxmram20zDKIYoKbuW0BlkyTAZQX5Q6rOH+PYDvyYh/
	QFbQ==
MIME-Version: 1.0
Received: by 10.14.40.84 with SMTP id e60mr4637595eeb.75.1340125974317; Tue,
	19 Jun 2012 10:12:54 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Tue, 19 Jun 2012 10:12:54 -0700 (PDT)
In-Reply-To: <20120619164107.GA24413@phenom.dumpdata.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<20120619164107.GA24413@phenom.dumpdata.com>
Date: Tue, 19 Jun 2012 13:12:54 -0400
Message-ID: <CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 19, 2012 at 12:41 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jun 19, 2012 at 09:49:12AM -0400, Shakeel Butt wrote:
>> I previously email at xen-user list but didn't get any response. I am
>> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.
>
> Wow. That is quite ancient. Do you see the same problem with the latest
> Linux kernel?
>
I didn't try with newer kernel but will do it now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 17:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 17: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 1Sh1z8-0005iD-4d; Tue, 19 Jun 2012 17:12:58 +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 1Sh1z6-0005i8-B3
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 17:12:56 +0000
Received: from [85.158.139.83:43406] by server-9.bemta-5.messagelabs.com id
	EC/18-01069-713B0EF4; Tue, 19 Jun 2012 17:12:55 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340125974!28386790!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20875 invoked from network); 19 Jun 2012 17:12:54 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 17:12:54 -0000
Received: by eeke50 with SMTP id e50so2921113eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 19 Jun 2012 10:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KTTFxNQh+TnG3v5dA2ayVTFAmJEQjh5GM38WY0JpJJg=;
	b=wrdKmnHlqshY7e9Icw2MaNseLyGcR4Qfd4FpIlYoYAIlQ30VqQGllOsjjcKrtvC0Qi
	RgkVAyyb/KUEND01qxVOpHUoHDVNaO91TCi3kTrecRmp/fngHAkNPpCFIq4XARKcgqXY
	7xj3TLZlr2v00flv2GVehZ8GrrZgR1xnAhlyjxrxpgO4xIvHIQSN6/l+WcfvABKE3dLM
	YSJBOrVNbaV/gbsXAcaWUB1tiz8MGCAT3A72cVITvz55QZSNA234HcRpbVyegIGmloVm
	KyaYlrRMCUfPruZ8l+1rUjFOKYxmram20zDKIYoKbuW0BlkyTAZQX5Q6rOH+PYDvyYh/
	QFbQ==
MIME-Version: 1.0
Received: by 10.14.40.84 with SMTP id e60mr4637595eeb.75.1340125974317; Tue,
	19 Jun 2012 10:12:54 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Tue, 19 Jun 2012 10:12:54 -0700 (PDT)
In-Reply-To: <20120619164107.GA24413@phenom.dumpdata.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<20120619164107.GA24413@phenom.dumpdata.com>
Date: Tue, 19 Jun 2012 13:12:54 -0400
Message-ID: <CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 19, 2012 at 12:41 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jun 19, 2012 at 09:49:12AM -0400, Shakeel Butt wrote:
>> I previously email at xen-user list but didn't get any response. I am
>> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.
>
> Wow. That is quite ancient. Do you see the same problem with the latest
> Linux kernel?
>
I didn't try with newer kernel but will do it now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 17:34:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 17:34: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 1Sh2Jj-0005xh-48; Tue, 19 Jun 2012 17:34:15 +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 1Sh2Jh-0005xc-IP
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 17:34:13 +0000
Received: from [85.158.139.83:33511] by server-3.bemta-5.messagelabs.com id
	B8/31-03367-418B0EF4; Tue, 19 Jun 2012 17:34:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340127251!28388691!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjUyMDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21413 invoked from network); 19 Jun 2012 17:34:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jun 2012 17:34:12 -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 81A8D2EA0;
	Tue, 19 Jun 2012 20:34:10 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6161120060; Tue, 19 Jun 2012 20:34:10 +0300 (EEST)
Date: Tue, 19 Jun 2012 20:34:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Shakeel Butt <shakeel.butt@gmail.com>
Message-ID: <20120619173410.GW2058@reaktio.net>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<20120619164107.GA24413@phenom.dumpdata.com>
	<CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 19, 2012 at 01:12:54PM -0400, Shakeel Butt wrote:
> On Tue, Jun 19, 2012 at 12:41 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Jun 19, 2012 at 09:49:12AM -0400, Shakeel Butt wrote:
> >> I previously email at xen-user list but didn't get any response. I am
> >> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.
> >
> > Wow. That is quite ancient. Do you see the same problem with the latest
> > Linux kernel?
> >
> I didn't try with newer kernel but will do it now.
> 

And while you're at it try new Xen aswell :)
So Xen 4.1.2+ and Linux 3.4.2+.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 17:34:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 17:34: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 1Sh2Jj-0005xh-48; Tue, 19 Jun 2012 17:34:15 +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 1Sh2Jh-0005xc-IP
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 17:34:13 +0000
Received: from [85.158.139.83:33511] by server-3.bemta-5.messagelabs.com id
	B8/31-03367-418B0EF4; Tue, 19 Jun 2012 17:34:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340127251!28388691!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjUyMDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21413 invoked from network); 19 Jun 2012 17:34:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jun 2012 17:34:12 -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 81A8D2EA0;
	Tue, 19 Jun 2012 20:34:10 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6161120060; Tue, 19 Jun 2012 20:34:10 +0300 (EEST)
Date: Tue, 19 Jun 2012 20:34:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Shakeel Butt <shakeel.butt@gmail.com>
Message-ID: <20120619173410.GW2058@reaktio.net>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<20120619164107.GA24413@phenom.dumpdata.com>
	<CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 19, 2012 at 01:12:54PM -0400, Shakeel Butt wrote:
> On Tue, Jun 19, 2012 at 12:41 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Jun 19, 2012 at 09:49:12AM -0400, Shakeel Butt wrote:
> >> I previously email at xen-user list but didn't get any response. I am
> >> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.
> >
> > Wow. That is quite ancient. Do you see the same problem with the latest
> > Linux kernel?
> >
> I didn't try with newer kernel but will do it now.
> 

And while you're at it try new Xen aswell :)
So Xen 4.1.2+ and Linux 3.4.2+.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 18:16:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 18: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 1Sh2yH-0006Lc-JE; Tue, 19 Jun 2012 18:16: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 1Sh2yF-0006LX-Uk
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 18:16:08 +0000
Received: from [85.158.138.51:39692] by server-10.bemta-3.messagelabs.com id
	D6/A3-01753-7E1C0EF4; Tue, 19 Jun 2012 18:16:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340129766!27322025!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17042 invoked from network); 19 Jun 2012 18:16:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 18:16:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="13109213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 18:16:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 19:16:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sh2yD-0006hQ-84	for xen-devel@lists.xen.org;
	Tue, 19 Jun 2012 18:16:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sh2yD-0007Uc-7A	for
	xen-devel@lists.xen.org; Tue, 19 Jun 2012 19:16:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20448.49637.38489.246434@mariner.uk.xensource.com>
Date: Tue, 19 Jun 2012 19:16:05 +0100
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduction
------------

The Xen.org security response team is charged with implementing the
Xen security response process, the current version of which can be
found here:

    http://www.xen.org/projects/security_vulnerability_process.html

Over the past two months we on that team have been involved with
XSA-7 / CVE-2012-0217 and its various fallout.

During this exercise we have encountered some problems with the
process.  Also, we have had to make some difficult decisions.  We feel
it is essential for keeping us honest that we explain to the community
what we did, and when.  There's a detailed timeline at the bottom of
this mail, listing the important events; reading it will give you a
much clearer picture of the problems we encountered and why we are
asking for various issues to be clarified.

In this message I'll go through some of the problems we encountered.
Where there are uncontroversial improvements for the process we
propose them here.  For the more controversial issues, in this message
we will raise the questions and discuss the issues in a neutral way,
and make our individual responses separately.

The outcome of this discussion will be a set of changes to be agreed
on and/or voted on using the existing Xen.org governance processes:
    http://www.xen.org/projects/governance.html

This discussion will take place on the xen-devel mailing list.
We expect it to take some weeks.


Summary of the most important difficulties we encountered
---------------------------------------------------------

One member of the predisclosure list, only a few days before the
embargo date, mounted a sustained and eventually successful lobbying
campaign to get the embargo extened.

There were leaks during the embargo period, after it had been
extended, which we experienced as enquiries from community members.

We were forced to made several ad-hoc decisions with insufficient
guidance from the process document.

We discovered too late in the process that the set of vulnerable
operating systems was substantially wider than we thought.



The big issues
--------------

1. Purpose of the process

The first point is that we think the security vulnerability process
document should have an explanation of what its goals are.  This would
have greatly assisted us when making some of the more difficult
decisions.

In particular, if the process explained its purpose, we would be able
to refer to the spirit of the document when making interpretation
decisions or dealing with issues not clearly resolved by the document.

In this context we need to decide whether:
 (a) the predisclosure arrangements are just there so that
     organisations can backport patches, develop and test updated
     versions, and so forth;
 (b) the arrangements are also intended to allow operators to deploy
     fixed versions.

Of course this needs to deal clearly with the common stituation of an
organisation running Xen which is a direct consumer of Xen.org source
code.


2. Extension of embargo dates

The most controversial decision was whether the embargo date might be
extended after it had originally been set.  We resisted these
suggestions, referring to the process document, which does not
contemplate extending the disclosure period.  However, when a
predisclosure list member pressured the discoverer into requesting an
extension, we felt the best interpretation of the process document
required us to acquiesce.

Specifically, of course, we as a team would like clearer guidance from
the process about whether, and if so under what circumstances, a
predisclosure period should be extended.


3. Decisionmaking

It was suggested to us several times, and indeed seemed to be regarded
by some as an underlying principle, that the predisclosure list
members should be making the decisions about disclosure schedule etc.

The question of who is to make the decisions, and on what basis, needs
to be addressed.


4. Length of (default) predisclosure period

Several members of the predisclosure list suggested that the
predisclosure period was too short.  Others were ready within the
predisclosure period's timeframe, and were disappointed to see it
extended and to have to delay their fixes.


5. Criteria for predisclosure list membership

We had one request from a public Xen cloud provider to be provided
with predisclosure information.  However it appeared to us that they
didn't meet the size threshold in the process document.

The size threshold is of course open to discussion.

We need to clarify whether upstreams and hardware vendors should be on
the predisclosure list.  Currently we have one notable upstream vendor
on that list.

Our preliminary view is that the predisclosure list should be used for
downstream notifications.  Upstreams, including hardware
manufacturers, should be brought in to the disclosure process as
needed.  And as noted, our process for making sure we do that properly
needs to be formalised.

It is probably time for a review of the membership of the
predisclosure list, in any case, after we have incorporated any
changes to the criteria which are agreed as a result of this
discussion.


6. Sharing of information and code between predisclosure participants

We need the process document to be clearer about what kinds of
communications are contemplated _between_ members of the predisclosure
list.

One particular issue here which also relates to the predisclosure
membership criteria, is whether large indirect consumers of Xen should
be on the predisclosure list in their own right.  That would allow
them to deploy the fix before the embargo date.  It would also allow
them to prepare for testing and deployment, before the fix is
available from their vendor (who would in this scenario also be
entitled to be a predisclosure list member).

In this context, the process needs to clarify whether vendors may
release fixed binaries during the predisclosure period.  Certainly
these should not be released other than to predisclosure list members,
since the nature of a bug can often by discovered by reverse
engineering.  But can they be released to predisclousre list members ?



More minor policy questions
---------------------------

7. Public communications during the embargo period

We need to clarify what individual vendors are allowed to say during
the embargo period.  It was brought to our attention that one public
cloud provider told its users that their VMs would be migrated due to
"a vendor issue" which would be revealed in "a few weeks".  Our view
was that that was fine.

As a starting point, it seems to us that it is OK to disclose that
there is an issue, including its XSA and CVE numbers and its planned
disclosure date; but that it is not OK to disclose the impact, scope,
set of vulnerable systems, and certainly not the nature of the
vulnerability.

And we need to clarify what information the security team should give
out when we get an enquiry from a community member about an embargoed
problem.


8. Predisclosure subscription process, and email address criteria

We certainly need to clarify the subscription process to the list, to
make it clear that the organisation's security team should request all
subscriptions and that self-subscriptions via the mailing list
interface will be rejected out of hand.  The current arrangements have
caused quite a lot of admin work, to confirm various change requests.

The predisclosure list contains a number of individuals at various
organisations.  One vendor seemed to get into difficulty because it
had only one individual on the predisclosure list, which seems to have
unfortunately kept their established team in the dark during the early
stages of the process.  The process document requires that downstreams
on the list have established security teams.  Should we require that
such response teams' contact details be publicly advertised ?  Should
we insist that only response teams' role addresses may be included on
the list ?


9. Vulnerability process scope

We need to clarify the scope of the process document.  Currently it
looks like it covers every Xen.org project.

While it would be a nice ideal to support every Xen.org project this
way, in practice the team behind security@xen do not have the
expertise or resources to fix problems in (say) XCP, or the ARM PV
port.  Our capability is concentrated on the "Upstream Xen" codebase
(xen-*.hg and its sub-repositories) and the Xen support code in Linux.

Perhaps this could be dealt with by making it clear that problems are
handled on a best effort basis.


10. Exploits

We need a clear policy about releasing proof of concept exploits -
whether, when and who to.


11. Transparency

We think the process document should explicitly state that any
potentially controversial private decisions made by the Xen.org
security response team should be disclosed after the vulnerability
itself is disclosed.


Lacunae in the process
----------------------

12. Holidays

The original planned disclosure date, 2012-05-01, was a public holiday
in many places.  We should try to avoid holidays, and Fridays.  We
need to discuss which territories' holidays should be checked and make
a list for inclusion in the process.


13. Patch development and review

The patch development process is too closed and not robust enough.

We need to be much clearer both about the need for security patches to
fix things in the smallest, simplest and most reliable way, and not
fix or "improve" matters in unrelated ways.  Our internal code review
needs to be much better.

We need to clarify that other issues discovered during the course of
investigating a security disclosure will not be publicly discussed
without first consulting the Xen.org security team, regardless of
their actual relationship to the vulnerability at hand or expected
security impact.  Otherwise there is a substantial risk that such
changes will draw attention to embargoed problems.

It may be that it would be a better idea to send out earlier
advisories without patches to the predisclosure list, to enable those
predisclosure list members who would like to do so to help with
development and testing of the patches.  If so this needs to be
catered for.


14. Early consideration of which other organisations to bring in

Our process needs to have, very early on, an explicit step to of
deciding which other projects/organisations may also be vulnerable and
may therefore need to be part of the same disclosure process.  It also
needs to make sure that we ask for any help (for example from
upstreams or hardware vendors) as soon as possible.

We also need to explicitly determine the availability of various key
players over the disclosure timeline as an early step.  One of the
difficulties we encountered was that one of the more important team
members was unexpectedly out of their office at a critical point.


15. Process automation

Many of the advisory versions sent to the predisclosure list contained
clerical errors.  Our processes for constructing these need to be
made more automatic.


Thanks for your attention,
Ian.
on behalf of the Xen.org security response team


Timeline (here "us" is the Xen.org security team)
-------------------------------------------------

 2012-04-09  Xen.org and FreeBSD notified of the problem (which
             will become XSA-7 / CVE-2012-0217) by the discoverer.

 2012-04-11  Discoverer tells us that they are happy with following the
             Xen.org process for this vulnerability, and asks for
             objections from FreeBSD.

 2012-04-11  We ask the Debian security team to allocate us a CVE
             candidate number.  (We have had difficulty with getting
             these from Mitre.)

 2012-04-12  We confirm in response to a question from Debian
             that we think Debian is vulnerable, giving some more
             information but not enough to find the problem.

 2012-04-12  We contact AMD to ask them to confirm whether any
             AMD processors are vulnerable.

 2012-04-12  Debian allocates us CVE-2012-0217.  We make sure that
             everyone currently aware of the issue is told.

 2012-04-13  Prompted by the discoverer, we contacts NetBSD
             so that they can check if they also are vulnerable,
             given that we believe that NetBSD may share the relevant
             code with FreeBSD.

 2012-04-16  Near-final draft of the predisclosure advisory is ready,
             including initial versions of patches for xen-unstable,
             Xen 4.1 and Xen 4.0.

 2012-04-17  The problem which will later become XSA-8 /
             CVE-2012-0218 is spotted and a fix committed to
             xen-unstable.hg, without mentioning that this bug is a
             security vulnerability.  In our view this was a mistake.

 2012-04-17  XSA-7 v1 is sent out, with an embargo end date of
             2012-05-01.

 2012-04-17  We become aware of the earlier commit and assign it
             XSA-8.  XSA-7 v2 is sent out, with a slightly improved
             patch and mentioning that XSA-8 will follow.

 2012-04-18  We ask Mitre and Debian for a CVE for XSA-8.  We send
             XSA-7 v3, and XSA-8 to the predisclosure list.

 2012-04-20  We send XSA-8 v2, which contains backported patches and
             corrections to the advisory text widening the set of
             possibly affected systems.

 2012-04-20  We send XSA-7 v4, which contains backported patches and
             the information that AMD CPUs are not vulnerable
             (following confirmation from AMD).

 2012-04-20  A member of the predisclosure list complains to us that
             the disclosure schedule is too short, and making various
             other points about the process.  We reply with a
             reference to the process document; we suggest that if the
             organisation feels that the process needs improving this
             should be discussed in public.

 2012-04-20  We are asked by a member of the predisclosure list whether
             it would be OK to release fixed binaries to a customer of
             theirs who is also a member of the predisclosure list.
             On the 2012-04-23, after internal discussions and
             consulting with the discoverer, we reply to say that we
             think that would be OK.

 2012-04-20  We are asked by a member of the predisclousre list
             whether there is any way they can verify whether their
             systems are vulnerable, or perhaps whether we can share
             any proof of concept exploit code.  Again, we consulted
             with the discoverer.

 2012-04-21  The discoverer reproduces the problem on a widely-deployed
             proprietary operating system that runs on x86, and
             suggests to us that the embargo period should therefore
             be extended.  We reply:

       Our process doesn't contemplate the extension of the embargo
       after the release of information to our predisclosure list.

       It would in theory be possible for us to email the
       predisclosure list ask them to extend the embargo date.
       However, from a practical point of view, if anyone didn't get
       the email they might go ahead and disclose on the original
       date, leaving us all scrambling madly with an unexpected
       disclosure.  And from a process point of view, that would be
       departing substantially from our published process, so I'm very
       reluctant.

       Certainly you are entitled to notify [proprietary OS vendor]
       right away and it would be sensible to do so.

             With hindsight it was an error not to consider, as part
             of the formal process, which other operating systems
             might be vulnerable.

 2012-04-26  We obtain the number CVE-2012-0218 from Debian for XSA-8.

 2012-04-26  We send XSA-7 v5 with improved wording.
             We send XSA-8 v3, with the CVE number.

 2012-04-28  A member of the predisclosure list requests an extension
             of the disclosure timeframe, and in the same message
             requests a change to the email address subscribed to the
             predisclosure list.  We reply declining, referring to our
             process document, and once again inviting public
             discussion of the process itself.

 2012-04-28  The member of the predisclosure list asking for an
             extension asks to be put in touch with all the other
             members of the predisclosure list and proposes a
             conference call.

 2012-04-30  We decline to give further details of the predisclosure
             list members, other than the organisational identities
             listed.  We again decline to extend the disclosure date.

 2012-04-30  The member asking for an extension reiterates their
             request, citing support from various other named
             predisclosure list members - in at least some cases,
             exaggerating the level of such support.

 2012-04-30  Various other members of the predisclosure list report to
             us having been asked to support the member asking for a
             delay.  CEOs of several companies were involved.  In some
             cases the other members support the request.  We again
             decline.

 2012-04-30  The member requesting an embargo suggests holding a straw
             poll of predisclosure list members on the question of a
             delay.  Again, we decline.

 2012-04-30  The member requesting an embargo places intense pressure
             on the employers of some members of the Xen.org security
             team to try to get the decision changed, without success.

 2012-04-30 23:06 Z  (13h before planned disclosure)
             The member requesting an embargo contacts the employer
             of the discoverer to apply pressure.  The discoverer
             notifies Xen.org that "on behalf of the organization who
             discovered this issue" they request a delay, giving
             a putative but unconfirmed new disclosure date of the
             2012-05-31.

 2012-05-01 08:08 Z  (3h52 before planned disclosure)
             Xen.org team decides, after internal discussions, that
             as the policy gives the discoverer control of the
             disclosure date, and the question is not otherwise
             addressed, we must agree to this request.

 2012-05-10 08:48 Z  (3h12 before planned disclosure)
             We send an ad-hoc message to the predisclosure list
             requesting a disclosure delay for XSA-7 / XSA-8.
             We do not include a revised disclosure date as we don't
             have one confirmed.

 2012-05-01  Backport of XSA-7/XSA-8 patches to 3.4 are prepared.

 2012-05-02  We become aware, indirectly, that US-CERT have become
             involved.

 2012-05-03  US-CERT suggest to us a disclosure date of 2012-06-12.
             We make a formal response, saying that we think this is
             far too late.

 2012-05-03  We receive the first enquiry from a Xen community member
             not on the predisclosure list, saying they had heard
             somerthing was wrong, and asking about it.  This is the
             first of several such enquiries.

             We quote the number CVE-2012-0217 and say that we expect
             it to be disclosed on the 12th of June, but that we
             aren't allowed to say more.

 2012-05-08  We press the discoverers' employer for a confirmed
             disclosure date.

 2012-05-08  Given that no disclosure date is forthcoming, we send
             XSA-7 v6 and XSA-8 v4, with an indefinite embargo and the
             backport patch for Xen 3.4.

 2012-05-14  Given that still no firm date is forthcoming, we (the
             Xen.org team) point out to the discoverers and to CERT
             that our policy requires us to honour reasonable
             requests, but that the continued lack of any date is
             unreasonable, and demanding that a date be set by the
             2012-05-18.

 2012-05-14  The discover confirms 2012-06-12 as the disclosure
             date.

 2012-05-15  We send XSA-7 v7 and XSA-8 v5 with the disclosure date of
             2012-06-12.

 2012-05-15  We receive a complaint about the delay from a member of
             the predisclosure list.

 2012-05-15  A member of the predisclosure list discovers what will
             become XSA-9.  The context was testing the fix for
             XSA-7.

 2012-05-16  We conclude that this is due to AMD erratum #121, and
             involve AMD.

 2012-05-16  After discussions we conclude that there is no reasonable
             software workaround for Xen and that instead Xen should
             refuse to boot on affected systems.

 2012-05-18  We decide that releasing this as a separate advisory with
             the same embargo date will be less confusing than trying
             to fold it into XSA-7.

 2012-05-18  While investigating this we come to the conclusion that
             our previous patch to fix XSA-7 was incomplete.

 2012-05-21  First draft of XSA-9 is available.

 2012-05-22  After intense internal discussions we decide that the
             original fix for XSA-7 is too fragile and conclude that
             it should be replaced by something more obvious.

 2012-05-23  We request a CVE for XSA-9 from Mitre and Debian.

 2012-05-24  We send XSA-7 v8, now with a cross-reference to XSA-9,
             and with updated simpler patch, and XSA-8 v6, and
             XSA-9 v1 with its own separate patch, to the
             predisclosure list.

 2012-05-24  Mitre assign CVE-2012-2934 for XSA-9.

 2012-06-11  We send XSA-9 v2, containing the CVE and a clear
             statement that no affected processors support SVM.
             (The delay to this message was a mistake by the Xen.org
             team.)

 2012-06-12  Public disclosure.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 18:16:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 18: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 1Sh2yH-0006Lc-JE; Tue, 19 Jun 2012 18:16: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 1Sh2yF-0006LX-Uk
	for xen-devel@lists.xen.org; Tue, 19 Jun 2012 18:16:08 +0000
Received: from [85.158.138.51:39692] by server-10.bemta-3.messagelabs.com id
	D6/A3-01753-7E1C0EF4; Tue, 19 Jun 2012 18:16:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340129766!27322025!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDEyOTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17042 invoked from network); 19 Jun 2012 18:16:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jun 2012 18:16:06 -0000
X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="13109213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jun 2012 18:16:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 19 Jun 2012 19:16:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sh2yD-0006hQ-84	for xen-devel@lists.xen.org;
	Tue, 19 Jun 2012 18:16:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sh2yD-0007Uc-7A	for
	xen-devel@lists.xen.org; Tue, 19 Jun 2012 19:16:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20448.49637.38489.246434@mariner.uk.xensource.com>
Date: Tue, 19 Jun 2012 19:16:05 +0100
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduction
------------

The Xen.org security response team is charged with implementing the
Xen security response process, the current version of which can be
found here:

    http://www.xen.org/projects/security_vulnerability_process.html

Over the past two months we on that team have been involved with
XSA-7 / CVE-2012-0217 and its various fallout.

During this exercise we have encountered some problems with the
process.  Also, we have had to make some difficult decisions.  We feel
it is essential for keeping us honest that we explain to the community
what we did, and when.  There's a detailed timeline at the bottom of
this mail, listing the important events; reading it will give you a
much clearer picture of the problems we encountered and why we are
asking for various issues to be clarified.

In this message I'll go through some of the problems we encountered.
Where there are uncontroversial improvements for the process we
propose them here.  For the more controversial issues, in this message
we will raise the questions and discuss the issues in a neutral way,
and make our individual responses separately.

The outcome of this discussion will be a set of changes to be agreed
on and/or voted on using the existing Xen.org governance processes:
    http://www.xen.org/projects/governance.html

This discussion will take place on the xen-devel mailing list.
We expect it to take some weeks.


Summary of the most important difficulties we encountered
---------------------------------------------------------

One member of the predisclosure list, only a few days before the
embargo date, mounted a sustained and eventually successful lobbying
campaign to get the embargo extened.

There were leaks during the embargo period, after it had been
extended, which we experienced as enquiries from community members.

We were forced to made several ad-hoc decisions with insufficient
guidance from the process document.

We discovered too late in the process that the set of vulnerable
operating systems was substantially wider than we thought.



The big issues
--------------

1. Purpose of the process

The first point is that we think the security vulnerability process
document should have an explanation of what its goals are.  This would
have greatly assisted us when making some of the more difficult
decisions.

In particular, if the process explained its purpose, we would be able
to refer to the spirit of the document when making interpretation
decisions or dealing with issues not clearly resolved by the document.

In this context we need to decide whether:
 (a) the predisclosure arrangements are just there so that
     organisations can backport patches, develop and test updated
     versions, and so forth;
 (b) the arrangements are also intended to allow operators to deploy
     fixed versions.

Of course this needs to deal clearly with the common stituation of an
organisation running Xen which is a direct consumer of Xen.org source
code.


2. Extension of embargo dates

The most controversial decision was whether the embargo date might be
extended after it had originally been set.  We resisted these
suggestions, referring to the process document, which does not
contemplate extending the disclosure period.  However, when a
predisclosure list member pressured the discoverer into requesting an
extension, we felt the best interpretation of the process document
required us to acquiesce.

Specifically, of course, we as a team would like clearer guidance from
the process about whether, and if so under what circumstances, a
predisclosure period should be extended.


3. Decisionmaking

It was suggested to us several times, and indeed seemed to be regarded
by some as an underlying principle, that the predisclosure list
members should be making the decisions about disclosure schedule etc.

The question of who is to make the decisions, and on what basis, needs
to be addressed.


4. Length of (default) predisclosure period

Several members of the predisclosure list suggested that the
predisclosure period was too short.  Others were ready within the
predisclosure period's timeframe, and were disappointed to see it
extended and to have to delay their fixes.


5. Criteria for predisclosure list membership

We had one request from a public Xen cloud provider to be provided
with predisclosure information.  However it appeared to us that they
didn't meet the size threshold in the process document.

The size threshold is of course open to discussion.

We need to clarify whether upstreams and hardware vendors should be on
the predisclosure list.  Currently we have one notable upstream vendor
on that list.

Our preliminary view is that the predisclosure list should be used for
downstream notifications.  Upstreams, including hardware
manufacturers, should be brought in to the disclosure process as
needed.  And as noted, our process for making sure we do that properly
needs to be formalised.

It is probably time for a review of the membership of the
predisclosure list, in any case, after we have incorporated any
changes to the criteria which are agreed as a result of this
discussion.


6. Sharing of information and code between predisclosure participants

We need the process document to be clearer about what kinds of
communications are contemplated _between_ members of the predisclosure
list.

One particular issue here which also relates to the predisclosure
membership criteria, is whether large indirect consumers of Xen should
be on the predisclosure list in their own right.  That would allow
them to deploy the fix before the embargo date.  It would also allow
them to prepare for testing and deployment, before the fix is
available from their vendor (who would in this scenario also be
entitled to be a predisclosure list member).

In this context, the process needs to clarify whether vendors may
release fixed binaries during the predisclosure period.  Certainly
these should not be released other than to predisclosure list members,
since the nature of a bug can often by discovered by reverse
engineering.  But can they be released to predisclousre list members ?



More minor policy questions
---------------------------

7. Public communications during the embargo period

We need to clarify what individual vendors are allowed to say during
the embargo period.  It was brought to our attention that one public
cloud provider told its users that their VMs would be migrated due to
"a vendor issue" which would be revealed in "a few weeks".  Our view
was that that was fine.

As a starting point, it seems to us that it is OK to disclose that
there is an issue, including its XSA and CVE numbers and its planned
disclosure date; but that it is not OK to disclose the impact, scope,
set of vulnerable systems, and certainly not the nature of the
vulnerability.

And we need to clarify what information the security team should give
out when we get an enquiry from a community member about an embargoed
problem.


8. Predisclosure subscription process, and email address criteria

We certainly need to clarify the subscription process to the list, to
make it clear that the organisation's security team should request all
subscriptions and that self-subscriptions via the mailing list
interface will be rejected out of hand.  The current arrangements have
caused quite a lot of admin work, to confirm various change requests.

The predisclosure list contains a number of individuals at various
organisations.  One vendor seemed to get into difficulty because it
had only one individual on the predisclosure list, which seems to have
unfortunately kept their established team in the dark during the early
stages of the process.  The process document requires that downstreams
on the list have established security teams.  Should we require that
such response teams' contact details be publicly advertised ?  Should
we insist that only response teams' role addresses may be included on
the list ?


9. Vulnerability process scope

We need to clarify the scope of the process document.  Currently it
looks like it covers every Xen.org project.

While it would be a nice ideal to support every Xen.org project this
way, in practice the team behind security@xen do not have the
expertise or resources to fix problems in (say) XCP, or the ARM PV
port.  Our capability is concentrated on the "Upstream Xen" codebase
(xen-*.hg and its sub-repositories) and the Xen support code in Linux.

Perhaps this could be dealt with by making it clear that problems are
handled on a best effort basis.


10. Exploits

We need a clear policy about releasing proof of concept exploits -
whether, when and who to.


11. Transparency

We think the process document should explicitly state that any
potentially controversial private decisions made by the Xen.org
security response team should be disclosed after the vulnerability
itself is disclosed.


Lacunae in the process
----------------------

12. Holidays

The original planned disclosure date, 2012-05-01, was a public holiday
in many places.  We should try to avoid holidays, and Fridays.  We
need to discuss which territories' holidays should be checked and make
a list for inclusion in the process.


13. Patch development and review

The patch development process is too closed and not robust enough.

We need to be much clearer both about the need for security patches to
fix things in the smallest, simplest and most reliable way, and not
fix or "improve" matters in unrelated ways.  Our internal code review
needs to be much better.

We need to clarify that other issues discovered during the course of
investigating a security disclosure will not be publicly discussed
without first consulting the Xen.org security team, regardless of
their actual relationship to the vulnerability at hand or expected
security impact.  Otherwise there is a substantial risk that such
changes will draw attention to embargoed problems.

It may be that it would be a better idea to send out earlier
advisories without patches to the predisclosure list, to enable those
predisclosure list members who would like to do so to help with
development and testing of the patches.  If so this needs to be
catered for.


14. Early consideration of which other organisations to bring in

Our process needs to have, very early on, an explicit step to of
deciding which other projects/organisations may also be vulnerable and
may therefore need to be part of the same disclosure process.  It also
needs to make sure that we ask for any help (for example from
upstreams or hardware vendors) as soon as possible.

We also need to explicitly determine the availability of various key
players over the disclosure timeline as an early step.  One of the
difficulties we encountered was that one of the more important team
members was unexpectedly out of their office at a critical point.


15. Process automation

Many of the advisory versions sent to the predisclosure list contained
clerical errors.  Our processes for constructing these need to be
made more automatic.


Thanks for your attention,
Ian.
on behalf of the Xen.org security response team


Timeline (here "us" is the Xen.org security team)
-------------------------------------------------

 2012-04-09  Xen.org and FreeBSD notified of the problem (which
             will become XSA-7 / CVE-2012-0217) by the discoverer.

 2012-04-11  Discoverer tells us that they are happy with following the
             Xen.org process for this vulnerability, and asks for
             objections from FreeBSD.

 2012-04-11  We ask the Debian security team to allocate us a CVE
             candidate number.  (We have had difficulty with getting
             these from Mitre.)

 2012-04-12  We confirm in response to a question from Debian
             that we think Debian is vulnerable, giving some more
             information but not enough to find the problem.

 2012-04-12  We contact AMD to ask them to confirm whether any
             AMD processors are vulnerable.

 2012-04-12  Debian allocates us CVE-2012-0217.  We make sure that
             everyone currently aware of the issue is told.

 2012-04-13  Prompted by the discoverer, we contacts NetBSD
             so that they can check if they also are vulnerable,
             given that we believe that NetBSD may share the relevant
             code with FreeBSD.

 2012-04-16  Near-final draft of the predisclosure advisory is ready,
             including initial versions of patches for xen-unstable,
             Xen 4.1 and Xen 4.0.

 2012-04-17  The problem which will later become XSA-8 /
             CVE-2012-0218 is spotted and a fix committed to
             xen-unstable.hg, without mentioning that this bug is a
             security vulnerability.  In our view this was a mistake.

 2012-04-17  XSA-7 v1 is sent out, with an embargo end date of
             2012-05-01.

 2012-04-17  We become aware of the earlier commit and assign it
             XSA-8.  XSA-7 v2 is sent out, with a slightly improved
             patch and mentioning that XSA-8 will follow.

 2012-04-18  We ask Mitre and Debian for a CVE for XSA-8.  We send
             XSA-7 v3, and XSA-8 to the predisclosure list.

 2012-04-20  We send XSA-8 v2, which contains backported patches and
             corrections to the advisory text widening the set of
             possibly affected systems.

 2012-04-20  We send XSA-7 v4, which contains backported patches and
             the information that AMD CPUs are not vulnerable
             (following confirmation from AMD).

 2012-04-20  A member of the predisclosure list complains to us that
             the disclosure schedule is too short, and making various
             other points about the process.  We reply with a
             reference to the process document; we suggest that if the
             organisation feels that the process needs improving this
             should be discussed in public.

 2012-04-20  We are asked by a member of the predisclosure list whether
             it would be OK to release fixed binaries to a customer of
             theirs who is also a member of the predisclosure list.
             On the 2012-04-23, after internal discussions and
             consulting with the discoverer, we reply to say that we
             think that would be OK.

 2012-04-20  We are asked by a member of the predisclousre list
             whether there is any way they can verify whether their
             systems are vulnerable, or perhaps whether we can share
             any proof of concept exploit code.  Again, we consulted
             with the discoverer.

 2012-04-21  The discoverer reproduces the problem on a widely-deployed
             proprietary operating system that runs on x86, and
             suggests to us that the embargo period should therefore
             be extended.  We reply:

       Our process doesn't contemplate the extension of the embargo
       after the release of information to our predisclosure list.

       It would in theory be possible for us to email the
       predisclosure list ask them to extend the embargo date.
       However, from a practical point of view, if anyone didn't get
       the email they might go ahead and disclose on the original
       date, leaving us all scrambling madly with an unexpected
       disclosure.  And from a process point of view, that would be
       departing substantially from our published process, so I'm very
       reluctant.

       Certainly you are entitled to notify [proprietary OS vendor]
       right away and it would be sensible to do so.

             With hindsight it was an error not to consider, as part
             of the formal process, which other operating systems
             might be vulnerable.

 2012-04-26  We obtain the number CVE-2012-0218 from Debian for XSA-8.

 2012-04-26  We send XSA-7 v5 with improved wording.
             We send XSA-8 v3, with the CVE number.

 2012-04-28  A member of the predisclosure list requests an extension
             of the disclosure timeframe, and in the same message
             requests a change to the email address subscribed to the
             predisclosure list.  We reply declining, referring to our
             process document, and once again inviting public
             discussion of the process itself.

 2012-04-28  The member of the predisclosure list asking for an
             extension asks to be put in touch with all the other
             members of the predisclosure list and proposes a
             conference call.

 2012-04-30  We decline to give further details of the predisclosure
             list members, other than the organisational identities
             listed.  We again decline to extend the disclosure date.

 2012-04-30  The member asking for an extension reiterates their
             request, citing support from various other named
             predisclosure list members - in at least some cases,
             exaggerating the level of such support.

 2012-04-30  Various other members of the predisclosure list report to
             us having been asked to support the member asking for a
             delay.  CEOs of several companies were involved.  In some
             cases the other members support the request.  We again
             decline.

 2012-04-30  The member requesting an embargo suggests holding a straw
             poll of predisclosure list members on the question of a
             delay.  Again, we decline.

 2012-04-30  The member requesting an embargo places intense pressure
             on the employers of some members of the Xen.org security
             team to try to get the decision changed, without success.

 2012-04-30 23:06 Z  (13h before planned disclosure)
             The member requesting an embargo contacts the employer
             of the discoverer to apply pressure.  The discoverer
             notifies Xen.org that "on behalf of the organization who
             discovered this issue" they request a delay, giving
             a putative but unconfirmed new disclosure date of the
             2012-05-31.

 2012-05-01 08:08 Z  (3h52 before planned disclosure)
             Xen.org team decides, after internal discussions, that
             as the policy gives the discoverer control of the
             disclosure date, and the question is not otherwise
             addressed, we must agree to this request.

 2012-05-10 08:48 Z  (3h12 before planned disclosure)
             We send an ad-hoc message to the predisclosure list
             requesting a disclosure delay for XSA-7 / XSA-8.
             We do not include a revised disclosure date as we don't
             have one confirmed.

 2012-05-01  Backport of XSA-7/XSA-8 patches to 3.4 are prepared.

 2012-05-02  We become aware, indirectly, that US-CERT have become
             involved.

 2012-05-03  US-CERT suggest to us a disclosure date of 2012-06-12.
             We make a formal response, saying that we think this is
             far too late.

 2012-05-03  We receive the first enquiry from a Xen community member
             not on the predisclosure list, saying they had heard
             somerthing was wrong, and asking about it.  This is the
             first of several such enquiries.

             We quote the number CVE-2012-0217 and say that we expect
             it to be disclosed on the 12th of June, but that we
             aren't allowed to say more.

 2012-05-08  We press the discoverers' employer for a confirmed
             disclosure date.

 2012-05-08  Given that no disclosure date is forthcoming, we send
             XSA-7 v6 and XSA-8 v4, with an indefinite embargo and the
             backport patch for Xen 3.4.

 2012-05-14  Given that still no firm date is forthcoming, we (the
             Xen.org team) point out to the discoverers and to CERT
             that our policy requires us to honour reasonable
             requests, but that the continued lack of any date is
             unreasonable, and demanding that a date be set by the
             2012-05-18.

 2012-05-14  The discover confirms 2012-06-12 as the disclosure
             date.

 2012-05-15  We send XSA-7 v7 and XSA-8 v5 with the disclosure date of
             2012-06-12.

 2012-05-15  We receive a complaint about the delay from a member of
             the predisclosure list.

 2012-05-15  A member of the predisclosure list discovers what will
             become XSA-9.  The context was testing the fix for
             XSA-7.

 2012-05-16  We conclude that this is due to AMD erratum #121, and
             involve AMD.

 2012-05-16  After discussions we conclude that there is no reasonable
             software workaround for Xen and that instead Xen should
             refuse to boot on affected systems.

 2012-05-18  We decide that releasing this as a separate advisory with
             the same embargo date will be less confusing than trying
             to fold it into XSA-7.

 2012-05-18  While investigating this we come to the conclusion that
             our previous patch to fix XSA-7 was incomplete.

 2012-05-21  First draft of XSA-9 is available.

 2012-05-22  After intense internal discussions we decide that the
             original fix for XSA-7 is too fragile and conclude that
             it should be replaced by something more obvious.

 2012-05-23  We request a CVE for XSA-9 from Mitre and Debian.

 2012-05-24  We send XSA-7 v8, now with a cross-reference to XSA-9,
             and with updated simpler patch, and XSA-8 v6, and
             XSA-9 v1 with its own separate patch, to the
             predisclosure list.

 2012-05-24  Mitre assign CVE-2012-2934 for XSA-9.

 2012-06-11  We send XSA-9 v2, containing the CVE and a clear
             statement that no affected processors support SVM.
             (The delay to this message was a mistake by the Xen.org
             team.)

 2012-06-12  Public disclosure.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 19:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 19: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 1Sh3rG-00077L-T8; Tue, 19 Jun 2012 19:12:58 +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 1Sh3rF-00077G-W4
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 19:12:58 +0000
Received: from [85.158.143.35:14998] by server-1.bemta-4.messagelabs.com id
	AD/B7-24392-93FC0EF4; Tue, 19 Jun 2012 19:12:57 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340133175!6057733!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9074 invoked from network); 19 Jun 2012 19:12:56 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jun 2012 19:12:56 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 8A5775424B; Tue, 19 Jun 2012 21:12:53 +0200 (CEST)
Date: Tue, 19 Jun 2012 21:12:53 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120619191253.GA22807@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [PATCH] Fix asmlinkage 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

According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
it is correct.

The patch adds the missing asmlinkage to function declarations affected.
It is needed for 4.1 and 4.2.

Signed-off-by: Bastian Blank <waldi@debian.org>

---
Origin: debian
Forwarded: no
Last-Update: 2012-06-15

--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/arch/x86/i8259.c
+++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/arch/x86/i8259.c
@@ -62,7 +62,7 @@
     IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \
     IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)
 
-    static void (*interrupt[])(void) = {
+    static void (*asmlinkage interrupt[])(void) = {
         IRQLIST_16(0x0), IRQLIST_16(0x1), IRQLIST_16(0x2), IRQLIST_16(0x3),
         IRQLIST_16(0x4), IRQLIST_16(0x5), IRQLIST_16(0x6), IRQLIST_16(0x7),
         IRQLIST_16(0x8), IRQLIST_16(0x9), IRQLIST_16(0xa), IRQLIST_16(0xb),
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/svm/intr.h
+++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/svm/intr.h
@@ -21,6 +21,8 @@
 #ifndef __ASM_X86_HVM_SVM_INTR_H__
 #define __ASM_X86_HVM_SVM_INTR_H__
 
-void svm_intr_assist(void);
+#include <asm/config.h>
+
+asmlinkage void svm_intr_assist(void);
 
 #endif /* __ASM_X86_HVM_SVM_INTR_H__ */
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/vmx/vmx.h
+++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -63,7 +63,7 @@
 
 void vmx_asm_vmexit_handler(struct cpu_user_regs);
 void vmx_asm_do_vmentry(void);
-void vmx_intr_assist(void);
+asmlinkage void vmx_intr_assist(void);
 void vmx_do_resume(struct vcpu *);
 void vmx_vlapic_msr_changed(struct vcpu *v);
 void vmx_realmode(struct cpu_user_regs *regs);
-- 
There is a multi-legged creature crawling on your shoulder.
		-- Spock, "A Taste of Armageddon", stardate 3193.9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 19:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 19: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 1Sh3rG-00077L-T8; Tue, 19 Jun 2012 19:12:58 +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 1Sh3rF-00077G-W4
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 19:12:58 +0000
Received: from [85.158.143.35:14998] by server-1.bemta-4.messagelabs.com id
	AD/B7-24392-93FC0EF4; Tue, 19 Jun 2012 19:12:57 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340133175!6057733!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9074 invoked from network); 19 Jun 2012 19:12:56 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jun 2012 19:12:56 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 8A5775424B; Tue, 19 Jun 2012 21:12:53 +0200 (CEST)
Date: Tue, 19 Jun 2012 21:12:53 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120619191253.GA22807@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	xen-devel@lists.xensource.com
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [PATCH] Fix asmlinkage 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

According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
it is correct.

The patch adds the missing asmlinkage to function declarations affected.
It is needed for 4.1 and 4.2.

Signed-off-by: Bastian Blank <waldi@debian.org>

---
Origin: debian
Forwarded: no
Last-Update: 2012-06-15

--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/arch/x86/i8259.c
+++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/arch/x86/i8259.c
@@ -62,7 +62,7 @@
     IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \
     IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)
 
-    static void (*interrupt[])(void) = {
+    static void (*asmlinkage interrupt[])(void) = {
         IRQLIST_16(0x0), IRQLIST_16(0x1), IRQLIST_16(0x2), IRQLIST_16(0x3),
         IRQLIST_16(0x4), IRQLIST_16(0x5), IRQLIST_16(0x6), IRQLIST_16(0x7),
         IRQLIST_16(0x8), IRQLIST_16(0x9), IRQLIST_16(0xa), IRQLIST_16(0xb),
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/svm/intr.h
+++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/svm/intr.h
@@ -21,6 +21,8 @@
 #ifndef __ASM_X86_HVM_SVM_INTR_H__
 #define __ASM_X86_HVM_SVM_INTR_H__
 
-void svm_intr_assist(void);
+#include <asm/config.h>
+
+asmlinkage void svm_intr_assist(void);
 
 #endif /* __ASM_X86_HVM_SVM_INTR_H__ */
--- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/vmx/vmx.h
+++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -63,7 +63,7 @@
 
 void vmx_asm_vmexit_handler(struct cpu_user_regs);
 void vmx_asm_do_vmentry(void);
-void vmx_intr_assist(void);
+asmlinkage void vmx_intr_assist(void);
 void vmx_do_resume(struct vcpu *);
 void vmx_vlapic_msr_changed(struct vcpu *v);
 void vmx_realmode(struct cpu_user_regs *regs);
-- 
There is a multi-legged creature crawling on your shoulder.
		-- Spock, "A Taste of Armageddon", stardate 3193.9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 20:45:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 20: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 1Sh5Ht-0007lt-W6; Tue, 19 Jun 2012 20:44:34 +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 1Sh5Ht-0007lo-Dt
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 20:44:33 +0000
Received: from [85.158.138.51:21132] by server-11.bemta-3.messagelabs.com id
	FF/FA-02904-0B4E0EF4; Tue, 19 Jun 2012 20:44:32 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340138671!28591762!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjUyMDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6498 invoked from network); 19 Jun 2012 20:44:32 -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; 19 Jun 2012 20:44:32 -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 32A992704;
	Tue, 19 Jun 2012 23:44:29 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DB78020060; Tue, 19 Jun 2012 23:44:29 +0300 (EEST)
Date: Tue, 19 Jun 2012 23:44:29 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120619204429.GX2058@reaktio.net>
References: <40352EBA8B4DF841A9907B883F22B59B0FCC58DE@SHSMSX102.ccr.corp.intel.com>
	<20120313153857.GA12984@reaktio.net>
	<1B4B44D9196EFF41AE41FDA404FC0A1005DA03@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1005DA03@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [Xen-devel] VMX status report. Xen:24911 & Dom0:	d93dc5c4...
 Nested VMX testing?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Mar 14, 2012 at 08:00:09AM +0000, Ren, Yongjie wrote:
> > 
> > Hello,
> > 
> > > This is the test report of xen-unstable tree. We've switched our Dom0 to
> > upstream Linux 3.1-rc7 instead of Jeremy's 2.6.32.x tree.
> > > We've also upgraded our nightly test system from RHEL5.5 to RHEL6.2.
> > > We found four new issues and one old issue got fixed.
> > >
> > 
> > Is Intel planning to start testing Nested VMX ?
> 
> Yes, we've made several automated test cases for Nested VMX.
> The bad news is there's some bug on Nested VMX.
> From my recent test, the following is the status for Nested VMX.
>    Xen on Xen: failed. L1 Xen guest can't boot up. It hangs at the boot for xen hypervisor.
>    KVM on Xen: pass. L2 RHEL5.5 guest can boot up on L1 KVM guest.
> (We use the same version of dom0 and xen-unstable as mentioned in the report.)
> Intel will make more effort on Nested VMX bug fixing this year.
> 

Hello again,

I'm wondering.. Does Intel have plans to do more Nested VMX testing (and bugfixes) before Xen 4.2 release? 
There's an action point on the Xen 4.2 status email about describing the status of Nested VMX support. 


> 
> > It seems AMD has done a lot of testing with Nested SVM with Xen..
> > 


Thanks,

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 19 20:45:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Jun 2012 20: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 1Sh5Ht-0007lt-W6; Tue, 19 Jun 2012 20:44:34 +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 1Sh5Ht-0007lo-Dt
	for xen-devel@lists.xensource.com; Tue, 19 Jun 2012 20:44:33 +0000
Received: from [85.158.138.51:21132] by server-11.bemta-3.messagelabs.com id
	FF/FA-02904-0B4E0EF4; Tue, 19 Jun 2012 20:44:32 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340138671!28591762!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MjUyMDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6498 invoked from network); 19 Jun 2012 20:44:32 -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; 19 Jun 2012 20:44:32 -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 32A992704;
	Tue, 19 Jun 2012 23:44:29 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DB78020060; Tue, 19 Jun 2012 23:44:29 +0300 (EEST)
Date: Tue, 19 Jun 2012 23:44:29 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120619204429.GX2058@reaktio.net>
References: <40352EBA8B4DF841A9907B883F22B59B0FCC58DE@SHSMSX102.ccr.corp.intel.com>
	<20120313153857.GA12984@reaktio.net>
	<1B4B44D9196EFF41AE41FDA404FC0A1005DA03@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1005DA03@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [Xen-devel] VMX status report. Xen:24911 & Dom0:	d93dc5c4...
 Nested VMX testing?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Mar 14, 2012 at 08:00:09AM +0000, Ren, Yongjie wrote:
> > 
> > Hello,
> > 
> > > This is the test report of xen-unstable tree. We've switched our Dom0 to
> > upstream Linux 3.1-rc7 instead of Jeremy's 2.6.32.x tree.
> > > We've also upgraded our nightly test system from RHEL5.5 to RHEL6.2.
> > > We found four new issues and one old issue got fixed.
> > >
> > 
> > Is Intel planning to start testing Nested VMX ?
> 
> Yes, we've made several automated test cases for Nested VMX.
> The bad news is there's some bug on Nested VMX.
> From my recent test, the following is the status for Nested VMX.
>    Xen on Xen: failed. L1 Xen guest can't boot up. It hangs at the boot for xen hypervisor.
>    KVM on Xen: pass. L2 RHEL5.5 guest can boot up on L1 KVM guest.
> (We use the same version of dom0 and xen-unstable as mentioned in the report.)
> Intel will make more effort on Nested VMX bug fixing this year.
> 

Hello again,

I'm wondering.. Does Intel have plans to do more Nested VMX testing (and bugfixes) before Xen 4.2 release? 
There's an action point on the Xen 4.2 status email about describing the status of Nested VMX support. 


> 
> > It seems AMD has done a lot of testing with Nested SVM with Xen..
> > 


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 Jun 20 00:49:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 00: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 1Sh96I-0002DN-2n; Wed, 20 Jun 2012 00:48:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sh96G-0002DI-Q3
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 00:48:49 +0000
Received: from [193.109.254.147:35653] by server-12.bemta-14.messagelabs.com
	id B8/DB-30461-0FD11EF4; Wed, 20 Jun 2012 00:48:48 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340153326!8435580!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1Mjc3MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1089 invoked from network); 20 Jun 2012 00:48:47 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 00:48:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340153327; x=1371689327;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=4xv0AWl5I99CxJeAcQgsUw7STPj4UB+0uhzTVsb09L8=;
	b=Xk/vYNC5b7Xj3OiV15j/e2h/hHiuj+0AnxlXK1fg9OCDb7MZWoYfqL/8
	8tlShdxixpF2ezkEzOER39FY6GhTIg==;
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="397568379"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 00:48:45 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5K0miKe014479; Wed, 20 Jun 2012 00:48:44 GMT
MIME-Version: 1.0
X-Mercurial-Node: 0a592e08ac31b3934372f910a0c54f72676ff217
Message-Id: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/1.7.3
Date: Wed, 20 Jun 2012 00:46:57 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shared libraries are automatically installed into /usr/lib
or /usr/lib64, depending on the supplied --prefix value and
$(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.

With this change, packagers can supply the desired location for shared
libraries on the ./configure command line. Packagers need to note that
the default behaviour on 64-bit Linux systems will be to install shared
libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
to ./configure.

Additionally, the libfsimage plugins are now loaded explicitly from
$LIBDIR/fs, removing platform-based decision trees in code.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 0a592e08ac31 config/StdGNU.mk
--- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -35,7 +35,6 @@ INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_32 = lib
 LIBLEAFDIR_x86_64 ?= lib64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 LIBEXEC = $(LIBDIR_x86_32)/xen/bin
diff -r 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
--- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_64 = lib/amd64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 MANDIR = $(PREFIX)/share/man
 MAN1DIR = $(MANDIR)/man1
diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,7 @@
 # Prefix and install folder
 PREFIX              := @prefix@
+exec_prefix         := @exec_prefix@
+LIBDIR              := @libdir@
 LIBLEAFDIR_x86_64   := @LIB_PATH@
 
 # A debug build of tools?
diff -r 32034d1914a6 -r 0a592e08ac31 config/x86_64.mk
--- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -11,7 +11,6 @@ CONFIG_IOEMU := y
 CFLAGS += -m64
 
 LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
-LIBDIR = $(LIBDIR_x86_64)
 
 SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
 
diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/Rules.mk
--- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,17 +1,12 @@
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
+CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
 CFLAGS += -Werror -D_GNU_SOURCE
 LDFLAGS += -L../common/
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
 
-FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
-FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
-FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
-FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
-FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
-FSDIR = $(FSDIR-y)
+FSDIR = $(LIBDIR)/fs
 
 FSLIB = fsimage.so
 
@@ -20,8 +15,8 @@ fs-all: $(FSLIB)
 
 .PHONY: fs-install
 fs-install: fs-all
-	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
-	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
+	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
 
 $(FSLIB): $(PIC_OBJS)
 	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/Makefile
--- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,5 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 MAJOR = 1.0
 MINOR = 0
diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/fsimage_plugin.c
--- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
@@ -122,7 +122,6 @@ fail:
 static int load_plugins(void)
 {
 	const char *fsdir = getenv("FSIMAGE_FSDIR");
-	const char *isadir = "";
 	struct dirent *dp = NULL;
 	struct dirent *dpp;
 	DIR *dir = NULL;
@@ -131,27 +130,12 @@ static int load_plugins(void)
 	int err;
 	int ret = -1;
 
-#if defined(FSIMAGE_FSDIR)
+#if !defined(FSIMAGE_FSDIR)
+#error FSIMAGE_FSDIR not defined
+#else
 	if (fsdir == NULL)
 		fsdir = FSIMAGE_FSDIR;
-#elif defined(__sun__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-
-	if (sizeof(void *) == 8)
-		isadir = "64/";
-#elif defined(__ia64__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-#else
-	if (fsdir == NULL) {
-		if (sizeof(void *) == 8)
-			fsdir = "/usr/lib64/fs";
-		else
-			fsdir = "/usr/lib/fs";
-	}
 #endif
-
 	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
 		goto fail;
 
@@ -172,8 +156,8 @@ static int load_plugins(void)
 		if (strcmp(dpp->d_name, "..") == 0)
 			continue;
 
-		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
-		    dpp->d_name, isadir);
+		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
+			dpp->d_name);
 
 		if (init_plugin(tmp) != 0)
 			goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 00:49:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 00: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 1Sh96I-0002DN-2n; Wed, 20 Jun 2012 00:48:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sh96G-0002DI-Q3
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 00:48:49 +0000
Received: from [193.109.254.147:35653] by server-12.bemta-14.messagelabs.com
	id B8/DB-30461-0FD11EF4; Wed, 20 Jun 2012 00:48:48 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340153326!8435580!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1Mjc3MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1089 invoked from network); 20 Jun 2012 00:48:47 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 00:48:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340153327; x=1371689327;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=4xv0AWl5I99CxJeAcQgsUw7STPj4UB+0uhzTVsb09L8=;
	b=Xk/vYNC5b7Xj3OiV15j/e2h/hHiuj+0AnxlXK1fg9OCDb7MZWoYfqL/8
	8tlShdxixpF2ezkEzOER39FY6GhTIg==;
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="397568379"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 00:48:45 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5K0miKe014479; Wed, 20 Jun 2012 00:48:44 GMT
MIME-Version: 1.0
X-Mercurial-Node: 0a592e08ac31b3934372f910a0c54f72676ff217
Message-Id: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/1.7.3
Date: Wed, 20 Jun 2012 00:46:57 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shared libraries are automatically installed into /usr/lib
or /usr/lib64, depending on the supplied --prefix value and
$(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.

With this change, packagers can supply the desired location for shared
libraries on the ./configure command line. Packagers need to note that
the default behaviour on 64-bit Linux systems will be to install shared
libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
to ./configure.

Additionally, the libfsimage plugins are now loaded explicitly from
$LIBDIR/fs, removing platform-based decision trees in code.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 0a592e08ac31 config/StdGNU.mk
--- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -35,7 +35,6 @@ INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_32 = lib
 LIBLEAFDIR_x86_64 ?= lib64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 LIBEXEC = $(LIBDIR_x86_32)/xen/bin
diff -r 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
--- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_64 = lib/amd64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 MANDIR = $(PREFIX)/share/man
 MAN1DIR = $(MANDIR)/man1
diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,7 @@
 # Prefix and install folder
 PREFIX              := @prefix@
+exec_prefix         := @exec_prefix@
+LIBDIR              := @libdir@
 LIBLEAFDIR_x86_64   := @LIB_PATH@
 
 # A debug build of tools?
diff -r 32034d1914a6 -r 0a592e08ac31 config/x86_64.mk
--- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -11,7 +11,6 @@ CONFIG_IOEMU := y
 CFLAGS += -m64
 
 LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
-LIBDIR = $(LIBDIR_x86_64)
 
 SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
 
diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/Rules.mk
--- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,17 +1,12 @@
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
+CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
 CFLAGS += -Werror -D_GNU_SOURCE
 LDFLAGS += -L../common/
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
 
-FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
-FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
-FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
-FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
-FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
-FSDIR = $(FSDIR-y)
+FSDIR = $(LIBDIR)/fs
 
 FSLIB = fsimage.so
 
@@ -20,8 +15,8 @@ fs-all: $(FSLIB)
 
 .PHONY: fs-install
 fs-install: fs-all
-	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
-	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
+	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
 
 $(FSLIB): $(PIC_OBJS)
 	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/Makefile
--- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,5 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 MAJOR = 1.0
 MINOR = 0
diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/fsimage_plugin.c
--- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
@@ -122,7 +122,6 @@ fail:
 static int load_plugins(void)
 {
 	const char *fsdir = getenv("FSIMAGE_FSDIR");
-	const char *isadir = "";
 	struct dirent *dp = NULL;
 	struct dirent *dpp;
 	DIR *dir = NULL;
@@ -131,27 +130,12 @@ static int load_plugins(void)
 	int err;
 	int ret = -1;
 
-#if defined(FSIMAGE_FSDIR)
+#if !defined(FSIMAGE_FSDIR)
+#error FSIMAGE_FSDIR not defined
+#else
 	if (fsdir == NULL)
 		fsdir = FSIMAGE_FSDIR;
-#elif defined(__sun__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-
-	if (sizeof(void *) == 8)
-		isadir = "64/";
-#elif defined(__ia64__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-#else
-	if (fsdir == NULL) {
-		if (sizeof(void *) == 8)
-			fsdir = "/usr/lib64/fs";
-		else
-			fsdir = "/usr/lib/fs";
-	}
 #endif
-
 	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
 		goto fail;
 
@@ -172,8 +156,8 @@ static int load_plugins(void)
 		if (strcmp(dpp->d_name, "..") == 0)
 			continue;
 
-		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
-		    dpp->d_name, isadir);
+		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
+			dpp->d_name);
 
 		if (init_plugin(tmp) != 0)
 			goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:25:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01:25: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 1Sh9fO-0006f3-KH; Wed, 20 Jun 2012 01:25:06 +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 1Sh9fN-0006ey-4V
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:25:05 +0000
Received: from [85.158.138.51:22525] by server-2.bemta-3.messagelabs.com id
	A8/CB-10266-07621EF4; Wed, 20 Jun 2012 01:25:04 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340155502!19628284!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxNzk2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3609 invoked from network); 20 Jun 2012 01:25:03 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-174.messagelabs.com with SMTP;
	20 Jun 2012 01:25:03 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 19 Jun 2012 18:24:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="182450234"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 19 Jun 2012 18:24:59 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 18:24:58 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 18:24:58 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Wed, 20 Jun 2012 09:24:56 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 2/4] xen: add xen parameter to control A/D bits support
Thread-Index: AQHNTeSptGqOy5UqSkq7048q+pIAZpcA4ciAgAGI4SA=
Date: Wed, 20 Jun 2012 01:24:55 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDFB78A@SHSMSX102.ccr.corp.intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
	<1340087306-6096-3-git-send-email-xudong.hao@intel.com>
	<4FE068FF020000780008A954@nat28.tlf.novell.com>
In-Reply-To: <4FE068FF020000780008A954@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: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: add xen parameter to control A/D
	bits 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: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, June 19, 2012 5:57 PM
> To: Hao, Xudong
> Cc: Shan, Haitao; Zhang, Xiantao; xen-devel@lists.xen.org; keir@xen.org
> Subject: Re: [PATCH 2/4] xen: add xen parameter to control A/D bits support
> 
> >>> On 19.06.12 at 08:28, Xudong Hao <xudong.hao@intel.com> wrote:
> > @@ -1574,6 +1579,9 @@ struct hvm_function_table * __init
> start_vmx(void)
> >          if ( cpu_has_vmx_ept_1gb )
> >              vmx_function_table.hap_capabilities |=
> HVM_HAP_SUPERPAGE_1GB;
> >
> > +        if ( cpu_has_vmx_ept_ad_bits )
> > +            hap_has_access_bit = hap_has_dirty_bit = 1;
> 
> So you're using these flags here, ...
> 
> > +
> >          setup_ept_dump();
> >      }
> >
> > --- a/xen/include/asm-x86/hap.h
> > +++ b/xen/include/asm-x86/hap.h
> > @@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
> >
> >  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
> >
> > +extern int hap_has_dirty_bit __read_mostly;
> > +extern int hap_has_access_bit __read_mostly;
> 
> ... and you're declaring them here, but I fail to find their definition.
> How does the result of applying up to this patch build?
> 

The definition is in patch 3, I'll move them in this patch.

> Also, they should clearly be bool_t.
> 

Thanks, I'll use type bool_t instead of int.

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:25:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01:25: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 1Sh9fO-0006f3-KH; Wed, 20 Jun 2012 01:25:06 +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 1Sh9fN-0006ey-4V
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:25:05 +0000
Received: from [85.158.138.51:22525] by server-2.bemta-3.messagelabs.com id
	A8/CB-10266-07621EF4; Wed, 20 Jun 2012 01:25:04 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340155502!19628284!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxNzk2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3609 invoked from network); 20 Jun 2012 01:25:03 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-174.messagelabs.com with SMTP;
	20 Jun 2012 01:25:03 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 19 Jun 2012 18:24:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="182450234"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 19 Jun 2012 18:24:59 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 18:24:58 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 18:24:58 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Wed, 20 Jun 2012 09:24:56 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 2/4] xen: add xen parameter to control A/D bits support
Thread-Index: AQHNTeSptGqOy5UqSkq7048q+pIAZpcA4ciAgAGI4SA=
Date: Wed, 20 Jun 2012 01:24:55 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDFB78A@SHSMSX102.ccr.corp.intel.com>
References: <1340087306-6096-1-git-send-email-xudong.hao@intel.com>
	<1340087306-6096-3-git-send-email-xudong.hao@intel.com>
	<4FE068FF020000780008A954@nat28.tlf.novell.com>
In-Reply-To: <4FE068FF020000780008A954@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: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: add xen parameter to control A/D
	bits 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: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, June 19, 2012 5:57 PM
> To: Hao, Xudong
> Cc: Shan, Haitao; Zhang, Xiantao; xen-devel@lists.xen.org; keir@xen.org
> Subject: Re: [PATCH 2/4] xen: add xen parameter to control A/D bits support
> 
> >>> On 19.06.12 at 08:28, Xudong Hao <xudong.hao@intel.com> wrote:
> > @@ -1574,6 +1579,9 @@ struct hvm_function_table * __init
> start_vmx(void)
> >          if ( cpu_has_vmx_ept_1gb )
> >              vmx_function_table.hap_capabilities |=
> HVM_HAP_SUPERPAGE_1GB;
> >
> > +        if ( cpu_has_vmx_ept_ad_bits )
> > +            hap_has_access_bit = hap_has_dirty_bit = 1;
> 
> So you're using these flags here, ...
> 
> > +
> >          setup_ept_dump();
> >      }
> >
> > --- a/xen/include/asm-x86/hap.h
> > +++ b/xen/include/asm-x86/hap.h
> > @@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
> >
> >  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
> >
> > +extern int hap_has_dirty_bit __read_mostly;
> > +extern int hap_has_access_bit __read_mostly;
> 
> ... and you're declaring them here, but I fail to find their definition.
> How does the result of applying up to this patch build?
> 

The definition is in patch 3, I'll move them in this patch.

> Also, they should clearly be bool_t.
> 

Thanks, I'll use type bool_t instead of int.

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAb-000708-1G; Wed, 20 Jun 2012 01:57:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAZ-0006zb-08
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:19 +0000
Received: from [85.158.143.99:4629] by server-1.bemta-4.messagelabs.com id
	88/F3-24392-EFD21EF4; Wed, 20 Jun 2012 01:57:18 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340157437!21775817!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30072 invoked from network); 20 Jun 2012 01:57:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 01:57:17 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756529"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:11 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:45 +0800
Message-Id: <1340157467-19553-3-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 2/4] xen: add xen parameter to control A/D
	bits 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>
MIME-Version: 1.0
Content-Type: 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 xen parameter to control A/D bits support, it on by default.

Changes from v1:
- Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to patch2.
- define them as bool_t instead of int.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/hvm/vmx/vmcs.c       |    1 +
 xen/arch/x86/hvm/vmx/vmx.c        |    8 ++++++++
 xen/arch/x86/mm/hap/hap.c         |    4 ++++
 xen/arch/x86/mm/p2m.c             |    3 +++
 xen/include/asm-x86/hap.h         |    3 +++
 xen/include/asm-x86/hvm/vmx/vmx.h |    3 +++
 6 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 38b5d03..5a6be4c 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -85,6 +85,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_virtualize_apic_accesses, "APIC MMIO access virtualisation");
     P(cpu_has_vmx_tpr_shadow, "APIC TPR shadow");
     P(cpu_has_vmx_ept, "Extended Page Tables (EPT)");
+    P(cpu_has_vmx_ept_ad_bits, "EPT A/D Bits");
     P(cpu_has_vmx_vpid, "Virtual-Processor Identifiers (VPID)");
     P(cpu_has_vmx_vnmi, "Virtual NMI");
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index ffb86c1..cb94226 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -37,6 +37,7 @@
 #include <asm/spinlock.h>
 #include <asm/paging.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/mem_sharing.h>
 #include <asm/hvm/emulate.h>
 #include <asm/hvm/hvm.h>
@@ -89,6 +90,10 @@ static int vmx_domain_initialise(struct domain *d)
     d->arch.hvm_domain.vmx.ept_control.asr  =
         pagetable_get_pfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
 
+    /* set EPT access and dirty bits support */
+    d->arch.hvm_domain.vmx.ept_control.ept_ad =
+        cpu_has_vmx_ept_ad_bits? 1 : 0;
+
     if ( !zalloc_cpumask_var(&d->arch.hvm_domain.vmx.ept_synced) )
         return -ENOMEM;
 
@@ -1574,6 +1579,9 @@ struct hvm_function_table * __init start_vmx(void)
         if ( cpu_has_vmx_ept_1gb )
             vmx_function_table.hap_capabilities |= HVM_HAP_SUPERPAGE_1GB;
 
+        if ( cpu_has_vmx_ept_ad_bits )
+            hap_has_access_bit = hap_has_dirty_bit = 1;
+
         setup_ept_dump();
     }
 
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 13b4be2..8790c58 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -52,6 +52,10 @@
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
+/* Define whether HW has access and dirty bits seperately */
+bool_t hap_has_dirty_bit __read_mostly = 0;
+bool_t hap_has_access_bit __read_mostly = 0;
+
 /************************************************/
 /*          HAP VRAM TRACKING SUPPORT           */
 /************************************************/
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3cdc417..0a796f3 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -46,6 +46,9 @@ boolean_param("hap_1gb", opt_hap_1gb);
 bool_t __read_mostly opt_hap_2mb = 1;
 boolean_param("hap_2mb", opt_hap_2mb);
 
+bool_t __read_mostly opt_hap_ad_bits = 1;
+boolean_param("hap_ad_bits", opt_hap_ad_bits);
+
 /* Printouts */
 #define P2M_PRINTK(_f, _a...)                                \
     debugtrace_printk("p2m: %s(): " _f, __func__, ##_a)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..bd5d732 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 
+extern bool_t hap_has_dirty_bit __read_mostly;
+extern bool_t hap_has_access_bit __read_mostly;
+
 #endif /* XEN_HAP_H */
 
 /*
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index 416504f..f552d08 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -201,6 +201,9 @@ extern u64 vmx_ept_vpid_cap;
     (vmx_ept_vpid_cap & VMX_EPT_SUPERPAGE_2MB)
 #define cpu_has_vmx_ept_invept_single_context   \
     (vmx_ept_vpid_cap & VMX_EPT_INVEPT_SINGLE_CONTEXT)
+extern bool_t opt_hap_ad_bits;
+#define cpu_has_vmx_ept_ad_bits                 \
+    ( opt_hap_ad_bits ? (vmx_ept_vpid_cap & VMX_EPT_AD_BITS_SUPPORT) : 0 )
 
 #define EPT_2MB_SHIFT     16
 #define EPT_1GB_SHIFT     17
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAb-000708-1G; Wed, 20 Jun 2012 01:57:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAZ-0006zb-08
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:19 +0000
Received: from [85.158.143.99:4629] by server-1.bemta-4.messagelabs.com id
	88/F3-24392-EFD21EF4; Wed, 20 Jun 2012 01:57:18 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340157437!21775817!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30072 invoked from network); 20 Jun 2012 01:57:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 01:57:17 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756529"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:11 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:45 +0800
Message-Id: <1340157467-19553-3-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 2/4] xen: add xen parameter to control A/D
	bits 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>
MIME-Version: 1.0
Content-Type: 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 xen parameter to control A/D bits support, it on by default.

Changes from v1:
- Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to patch2.
- define them as bool_t instead of int.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/hvm/vmx/vmcs.c       |    1 +
 xen/arch/x86/hvm/vmx/vmx.c        |    8 ++++++++
 xen/arch/x86/mm/hap/hap.c         |    4 ++++
 xen/arch/x86/mm/p2m.c             |    3 +++
 xen/include/asm-x86/hap.h         |    3 +++
 xen/include/asm-x86/hvm/vmx/vmx.h |    3 +++
 6 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 38b5d03..5a6be4c 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -85,6 +85,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_virtualize_apic_accesses, "APIC MMIO access virtualisation");
     P(cpu_has_vmx_tpr_shadow, "APIC TPR shadow");
     P(cpu_has_vmx_ept, "Extended Page Tables (EPT)");
+    P(cpu_has_vmx_ept_ad_bits, "EPT A/D Bits");
     P(cpu_has_vmx_vpid, "Virtual-Processor Identifiers (VPID)");
     P(cpu_has_vmx_vnmi, "Virtual NMI");
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index ffb86c1..cb94226 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -37,6 +37,7 @@
 #include <asm/spinlock.h>
 #include <asm/paging.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/mem_sharing.h>
 #include <asm/hvm/emulate.h>
 #include <asm/hvm/hvm.h>
@@ -89,6 +90,10 @@ static int vmx_domain_initialise(struct domain *d)
     d->arch.hvm_domain.vmx.ept_control.asr  =
         pagetable_get_pfn(p2m_get_pagetable(p2m_get_hostp2m(d)));
 
+    /* set EPT access and dirty bits support */
+    d->arch.hvm_domain.vmx.ept_control.ept_ad =
+        cpu_has_vmx_ept_ad_bits? 1 : 0;
+
     if ( !zalloc_cpumask_var(&d->arch.hvm_domain.vmx.ept_synced) )
         return -ENOMEM;
 
@@ -1574,6 +1579,9 @@ struct hvm_function_table * __init start_vmx(void)
         if ( cpu_has_vmx_ept_1gb )
             vmx_function_table.hap_capabilities |= HVM_HAP_SUPERPAGE_1GB;
 
+        if ( cpu_has_vmx_ept_ad_bits )
+            hap_has_access_bit = hap_has_dirty_bit = 1;
+
         setup_ept_dump();
     }
 
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 13b4be2..8790c58 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -52,6 +52,10 @@
 #undef page_to_mfn
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
+/* Define whether HW has access and dirty bits seperately */
+bool_t hap_has_dirty_bit __read_mostly = 0;
+bool_t hap_has_access_bit __read_mostly = 0;
+
 /************************************************/
 /*          HAP VRAM TRACKING SUPPORT           */
 /************************************************/
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3cdc417..0a796f3 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -46,6 +46,9 @@ boolean_param("hap_1gb", opt_hap_1gb);
 bool_t __read_mostly opt_hap_2mb = 1;
 boolean_param("hap_2mb", opt_hap_2mb);
 
+bool_t __read_mostly opt_hap_ad_bits = 1;
+boolean_param("hap_ad_bits", opt_hap_ad_bits);
+
 /* Printouts */
 #define P2M_PRINTK(_f, _a...)                                \
     debugtrace_printk("p2m: %s(): " _f, __func__, ##_a)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..bd5d732 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -64,6 +64,9 @@ int   hap_track_dirty_vram(struct domain *d,
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 
+extern bool_t hap_has_dirty_bit __read_mostly;
+extern bool_t hap_has_access_bit __read_mostly;
+
 #endif /* XEN_HAP_H */
 
 /*
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index 416504f..f552d08 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -201,6 +201,9 @@ extern u64 vmx_ept_vpid_cap;
     (vmx_ept_vpid_cap & VMX_EPT_SUPERPAGE_2MB)
 #define cpu_has_vmx_ept_invept_single_context   \
     (vmx_ept_vpid_cap & VMX_EPT_INVEPT_SINGLE_CONTEXT)
+extern bool_t opt_hap_ad_bits;
+#define cpu_has_vmx_ept_ad_bits                 \
+    ( opt_hap_ad_bits ? (vmx_ept_vpid_cap & VMX_EPT_AD_BITS_SUPPORT) : 0 )
 
 #define EPT_2MB_SHIFT     16
 #define EPT_1GB_SHIFT     17
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAb-00070N-JF; Wed, 20 Jun 2012 01:57:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAZ-0006zh-MM
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:20 +0000
Received: from [85.158.143.99:55250] by server-2.bemta-4.messagelabs.com id
	DA/8E-17938-EFD21EF4; Wed, 20 Jun 2012 01:57:18 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340157437!21775817!2
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30102 invoked from network); 20 Jun 2012 01:57:18 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 01:57:18 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:16 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756541"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:15 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:47 +0800
Message-Id: <1340157467-19553-5-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest 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>
MIME-Version: 1.0
Content-Type: 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 p2m type is p2m_ram_logdirty, page should be read/write/execute(d) with EPT
dirty bit support.

When guest live migration with EPT dirty bit support, it does not trigger EPT
violation any longer, we flush dirty bitmap in ept_change_entry_type_page()
function, by walking the EPT page table.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/mm/p2m-ept.c |   50 ++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index f373905..e07004d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -24,6 +24,7 @@
 #include <asm/types.h>
 #include <asm/domain.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
 #include <xen/iommu.h>
@@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
                                                     entry->mfn);
             break;
         case p2m_ram_logdirty:
+            entry->w = hap_has_dirty_bit;
+            entry->r = entry->x = 1;
+            /* Not necessarily need to clear A bit, but it is safe anyway */
+            entry->a = entry->d = 0;
+            break;
         case p2m_ram_ro:
         case p2m_ram_shared:
             entry->r = entry->x = 1;
@@ -373,6 +379,9 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
                 need_modify_vtd_table = 0;
 
             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
+
+            if ( old_entry.d && (old_entry.sa_p2mt == p2m_ram_logdirty) )
+                paging_mark_dirty(d, mfn_x(mfn));
         }
 
         atomic_write_ept_entry(ept_entry, new_entry);
@@ -749,7 +758,8 @@ void ept_change_entry_emt_with_range(struct domain *d,
  * quickly enable or diable log-dirty tracking
  */
 static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
-                                       p2m_type_t ot, p2m_type_t nt)
+                                       p2m_type_t ot, p2m_type_t nt,
+                                       struct domain *d, int mask)
 {
     ept_entry_t e, *epte = map_domain_page(mfn_x(ept_page_mfn));
 
@@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
             ept_change_entry_type_page(_mfn(epte[i].mfn),
-                                       ept_page_level - 1, ot, nt);
+                                       ept_page_level - 1, ot, nt, d, mask);
         else
         {
             e = atomic_read_ept_entry(&epte[i]);
             if ( e.sa_p2mt != ot )
                 continue;
 
+            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
+            {
+                int j, nr_pages;
+                struct p2m_domain *p2m = p2m_get_hostp2m(d);
+                for ( j = 0, nr_pages = 1; j < ept_page_level;
+                      j++, nr_pages *= 512 ) {}
+                for ( j = 0; j < nr_pages; j++ )
+                    paging_mark_dirty(d, e.mfn + j);
+
+                /* split super page to 4k page, so that dirty bitmap can 
+                 * map the dirty page
+                 */
+                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
+                    continue;
+                atomic_write_ept_entry(&epte[i], e);
+            }
             e.sa_p2mt = nt;
             ept_p2m_type_to_flags(&e, nt, e.access);
+            if (!mask)
+                e.a = e.d = 0;
             atomic_write_ept_entry(&epte[i], e);
         }
     }
@@ -786,7 +814,22 @@ static void ept_change_entry_type_global(struct p2m_domain *p2m,
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
     BUG_ON(ot != nt && (ot == p2m_mmio_direct || nt == p2m_mmio_direct));
 
-    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d), ot, nt);
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, WALK_EPT_UNUSED);
+
+    ept_sync_domain(d);
+}
+
+static void ept_query_entry_global(struct p2m_domain *p2m, int mask)
+{
+    struct domain *d = p2m->domain;
+    p2m_type_t ot = p2m_ram_logdirty;
+    p2m_type_t nt = p2m_ram_logdirty;
+    if ( ept_get_asr(d) == 0 )
+        return;
+
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, mask);
 
     ept_sync_domain(d);
 }
@@ -796,6 +839,7 @@ void ept_p2m_init(struct p2m_domain *p2m)
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->query_entry_global = ept_query_entry_global;
     p2m->audit_p2m = NULL;
 }
 
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAb-00070N-JF; Wed, 20 Jun 2012 01:57:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAZ-0006zh-MM
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:20 +0000
Received: from [85.158.143.99:55250] by server-2.bemta-4.messagelabs.com id
	DA/8E-17938-EFD21EF4; Wed, 20 Jun 2012 01:57:18 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340157437!21775817!2
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30102 invoked from network); 20 Jun 2012 01:57:18 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 01:57:18 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:16 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756541"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:15 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:47 +0800
Message-Id: <1340157467-19553-5-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest 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>
MIME-Version: 1.0
Content-Type: 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 p2m type is p2m_ram_logdirty, page should be read/write/execute(d) with EPT
dirty bit support.

When guest live migration with EPT dirty bit support, it does not trigger EPT
violation any longer, we flush dirty bitmap in ept_change_entry_type_page()
function, by walking the EPT page table.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/arch/x86/mm/p2m-ept.c |   50 ++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index f373905..e07004d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -24,6 +24,7 @@
 #include <asm/types.h>
 #include <asm/domain.h>
 #include <asm/p2m.h>
+#include <asm/hap.h>
 #include <asm/hvm/vmx/vmx.h>
 #include <asm/hvm/vmx/vmcs.h>
 #include <xen/iommu.h>
@@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
                                                     entry->mfn);
             break;
         case p2m_ram_logdirty:
+            entry->w = hap_has_dirty_bit;
+            entry->r = entry->x = 1;
+            /* Not necessarily need to clear A bit, but it is safe anyway */
+            entry->a = entry->d = 0;
+            break;
         case p2m_ram_ro:
         case p2m_ram_shared:
             entry->r = entry->x = 1;
@@ -373,6 +379,9 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
                 need_modify_vtd_table = 0;
 
             ept_p2m_type_to_flags(&new_entry, p2mt, p2ma);
+
+            if ( old_entry.d && (old_entry.sa_p2mt == p2m_ram_logdirty) )
+                paging_mark_dirty(d, mfn_x(mfn));
         }
 
         atomic_write_ept_entry(ept_entry, new_entry);
@@ -749,7 +758,8 @@ void ept_change_entry_emt_with_range(struct domain *d,
  * quickly enable or diable log-dirty tracking
  */
 static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
-                                       p2m_type_t ot, p2m_type_t nt)
+                                       p2m_type_t ot, p2m_type_t nt,
+                                       struct domain *d, int mask)
 {
     ept_entry_t e, *epte = map_domain_page(mfn_x(ept_page_mfn));
 
@@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
             ept_change_entry_type_page(_mfn(epte[i].mfn),
-                                       ept_page_level - 1, ot, nt);
+                                       ept_page_level - 1, ot, nt, d, mask);
         else
         {
             e = atomic_read_ept_entry(&epte[i]);
             if ( e.sa_p2mt != ot )
                 continue;
 
+            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
+            {
+                int j, nr_pages;
+                struct p2m_domain *p2m = p2m_get_hostp2m(d);
+                for ( j = 0, nr_pages = 1; j < ept_page_level;
+                      j++, nr_pages *= 512 ) {}
+                for ( j = 0; j < nr_pages; j++ )
+                    paging_mark_dirty(d, e.mfn + j);
+
+                /* split super page to 4k page, so that dirty bitmap can 
+                 * map the dirty page
+                 */
+                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
+                    continue;
+                atomic_write_ept_entry(&epte[i], e);
+            }
             e.sa_p2mt = nt;
             ept_p2m_type_to_flags(&e, nt, e.access);
+            if (!mask)
+                e.a = e.d = 0;
             atomic_write_ept_entry(&epte[i], e);
         }
     }
@@ -786,7 +814,22 @@ static void ept_change_entry_type_global(struct p2m_domain *p2m,
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
     BUG_ON(ot != nt && (ot == p2m_mmio_direct || nt == p2m_mmio_direct));
 
-    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d), ot, nt);
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, WALK_EPT_UNUSED);
+
+    ept_sync_domain(d);
+}
+
+static void ept_query_entry_global(struct p2m_domain *p2m, int mask)
+{
+    struct domain *d = p2m->domain;
+    p2m_type_t ot = p2m_ram_logdirty;
+    p2m_type_t nt = p2m_ram_logdirty;
+    if ( ept_get_asr(d) == 0 )
+        return;
+
+    ept_change_entry_type_page(_mfn(ept_get_asr(d)), ept_get_wl(d),
+                               ot, nt, p2m->domain, mask);
 
     ept_sync_domain(d);
 }
@@ -796,6 +839,7 @@ void ept_p2m_init(struct p2m_domain *p2m)
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->query_entry_global = ept_query_entry_global;
     p2m->audit_p2m = NULL;
 }
 
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAa-0006zm-97; Wed, 20 Jun 2012 01:57:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAX-0006zV-Pn
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:17 +0000
Received: from [85.158.139.83:4984] by server-11.bemta-5.messagelabs.com id
	21/7C-20400-CFD21EF4; Wed, 20 Jun 2012 01:57:16 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340157435!24566525!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16378 invoked from network); 20 Jun 2012 01:57:16 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 01:57:16 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:09 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756511"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:08 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:43 +0800
Message-Id: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to patch2.
- define them as bool_t instead of int.

Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
enable VMMs to efficiently implement memory management and page classification
algorithms to optimize VM memory operations.

This series of patches enable EPT dirty bit feature for guest live migration.

PATCH 1/4: Add EPT A/D bits definitions.

PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.

PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will 
only update the log dirty bitmap, but won't clear the EPT page dirty bit. 
The function is used by live migration peek round with EPT D bit supported.

PATCH 4/4: enable EPT dirty bit for guest live migration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAa-0006zm-97; Wed, 20 Jun 2012 01:57:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAX-0006zV-Pn
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:17 +0000
Received: from [85.158.139.83:4984] by server-11.bemta-5.messagelabs.com id
	21/7C-20400-CFD21EF4; Wed, 20 Jun 2012 01:57:16 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340157435!24566525!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16378 invoked from network); 20 Jun 2012 01:57:16 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 01:57:16 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:09 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756511"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:08 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:43 +0800
Message-Id: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to patch2.
- define them as bool_t instead of int.

Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
enable VMMs to efficiently implement memory management and page classification
algorithms to optimize VM memory operations.

This series of patches enable EPT dirty bit feature for guest live migration.

PATCH 1/4: Add EPT A/D bits definitions.

PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.

PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will 
only update the log dirty bitmap, but won't clear the EPT page dirty bit. 
The function is used by live migration peek round with EPT D bit supported.

PATCH 4/4: enable EPT dirty bit for guest live migration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAa-000701-Ls; Wed, 20 Jun 2012 01:57:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAY-0006zW-Cl
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:18 +0000
Received: from [85.158.139.83:13780] by server-2.bemta-5.messagelabs.com id
	44/01-04598-DFD21EF4; Wed, 20 Jun 2012 01:57:17 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340157435!24566525!2
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16439 invoked from network); 20 Jun 2012 01:57:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 01:57:17 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756520"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:09 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:44 +0800
Message-Id: <1340157467-19553-2-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 1/4] xen: Add EPT A/D bits definitions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EPT A/D bits definitions.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/include/asm-x86/hvm/vmx/vmcs.h |    4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |    3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6100619..c0b9a44 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -62,7 +62,8 @@ struct vmx_domain {
         struct {
             u64 ept_mt :3,
                 ept_wl :3,
-                rsvd   :6,
+                ept_ad :1,
+                rsvd   :5,
                 asr    :52;
         };
         u64 eptp;
@@ -194,6 +195,7 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
 #define VMX_EPT_SUPERPAGE_2MB                   0x00010000
 #define VMX_EPT_SUPERPAGE_1GB                   0x00020000
 #define VMX_EPT_INVEPT_INSTRUCTION              0x00100000
+#define VMX_EPT_AD_BITS_SUPPORT                 0x00200000
 #define VMX_EPT_INVEPT_SINGLE_CONTEXT           0x02000000
 #define VMX_EPT_INVEPT_ALL_CONTEXT              0x04000000
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index accfa3f..416504f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -37,7 +37,8 @@ typedef union {
         emt         :   3,  /* bits 5:3 - EPT Memory type */
         ipat        :   1,  /* bit 6 - Ignore PAT memory type */
         sp          :   1,  /* bit 7 - Is this a superpage? */
-        rsvd1       :   2,  /* bits 9:8 - Reserved for future use */
+        a           :   1,  /* bit 8 - Access bit */
+        d           :   1,  /* bit 9 - Dirty bit */
         avail1      :   1,  /* bit 10 - Software available 1 */
         rsvd2_snp   :   1,  /* bit 11 - Used for VT-d snoop control
                                in shared EPT/VT-d usage */
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAa-000701-Ls; Wed, 20 Jun 2012 01:57:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAY-0006zW-Cl
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:18 +0000
Received: from [85.158.139.83:13780] by server-2.bemta-5.messagelabs.com id
	44/01-04598-DFD21EF4; Wed, 20 Jun 2012 01:57:17 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340157435!24566525!2
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16439 invoked from network); 20 Jun 2012 01:57:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 01:57:17 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756520"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:09 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:44 +0800
Message-Id: <1340157467-19553-2-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 1/4] xen: Add EPT A/D bits definitions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 EPT A/D bits definitions.

Signed-off-by: Haitao Shan<haitao.shan@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 xen/include/asm-x86/hvm/vmx/vmcs.h |    4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |    3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6100619..c0b9a44 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -62,7 +62,8 @@ struct vmx_domain {
         struct {
             u64 ept_mt :3,
                 ept_wl :3,
-                rsvd   :6,
+                ept_ad :1,
+                rsvd   :5,
                 asr    :52;
         };
         u64 eptp;
@@ -194,6 +195,7 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
 #define VMX_EPT_SUPERPAGE_2MB                   0x00010000
 #define VMX_EPT_SUPERPAGE_1GB                   0x00020000
 #define VMX_EPT_INVEPT_INSTRUCTION              0x00100000
+#define VMX_EPT_AD_BITS_SUPPORT                 0x00200000
 #define VMX_EPT_INVEPT_SINGLE_CONTEXT           0x02000000
 #define VMX_EPT_INVEPT_ALL_CONTEXT              0x04000000
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index accfa3f..416504f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -37,7 +37,8 @@ typedef union {
         emt         :   3,  /* bits 5:3 - EPT Memory type */
         ipat        :   1,  /* bit 6 - Ignore PAT memory type */
         sp          :   1,  /* bit 7 - Is this a superpage? */
-        rsvd1       :   2,  /* bits 9:8 - Reserved for future use */
+        a           :   1,  /* bit 8 - Access bit */
+        d           :   1,  /* bit 9 - Dirty bit */
         avail1      :   1,  /* bit 10 - Software available 1 */
         rsvd2_snp   :   1,  /* bit 11 - Used for VT-d snoop control
                                in shared EPT/VT-d usage */
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAb-00070W-W3; Wed, 20 Jun 2012 01:57:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAZ-0006zg-Q7
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:20 +0000
Received: from [85.158.139.83:13811] by server-8.bemta-5.messagelabs.com id
	F5/45-10278-EFD21EF4; Wed, 20 Jun 2012 01:57:18 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340157435!24566525!3
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16489 invoked from network); 20 Jun 2012 01:57:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 01:57:17 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756537"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:13 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:46 +0800
Message-Id: <1340157467-19553-4-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
	update_dirty_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>
MIME-Version: 1.0
Content-Type: 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 log_dirty new function update_dirty_bitmap, which will only update the
log dirty bitmap, but won't clear the EPT page dirty bit. The function is used
by live migration peek round with EPT D bit supported.

Set correct p2m type when EPT dirty bit supported.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan<haitao.shan@intel.com>
---
 xen/arch/x86/mm/hap/hap.c       |   32 +++++++++++++++++++++++++++-----
 xen/arch/x86/mm/p2m-pt.c        |    1 +
 xen/arch/x86/mm/p2m.c           |    9 +++++++++
 xen/arch/x86/mm/paging.c        |   32 +++++++++++++++++++-------------
 xen/arch/x86/mm/shadow/common.c |    2 +-
 xen/include/asm-x86/domain.h    |    1 +
 xen/include/asm-x86/hap.h       |    3 +++
 xen/include/asm-x86/p2m.h       |    5 ++++-
 xen/include/asm-x86/paging.h    |    3 ++-
 9 files changed, 67 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 8790c58..2a4cf1d 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -76,6 +76,7 @@ static int hap_enable_vram_tracking(struct domain *d)
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
                           p2m_ram_rw, p2m_ram_logdirty);
 
+    /* A TLB flush is needed no matter whether hap dirty bit is supported */
     flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
@@ -83,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain *d)
 static int hap_disable_vram_tracking(struct domain *d)
 {
     struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    p2m_type_t p2mt = p2m_ram_rw;
 
     if ( !dirty_vram )
         return -EINVAL;
 
+    /* With hap dirty bit, p2m type cannot be changed from p2m_ram_logdirty
+     * to p2m_ram_rw when first fault is met. Actually, there is no such
+     * fault occurred.
+     */
+    if ( hap_has_dirty_bit )
+        p2mt = p2m_ram_logdirty;
+
     paging_lock(d);
     d->arch.paging.mode &= ~PG_log_dirty;
     paging_unlock(d);
 
     /* set l1e entries of P2M table with normal mode */
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
+                          p2mt, p2m_ram_rw);
 
-    flush_tlb_mask(d->domain_dirty_cpumask);
+    /* With hap dirty bit, we actually did not change HW sensitive bits
+     * of the P2M tables.
+     */
+    if ( !hap_has_dirty_bit )
+        flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
 
@@ -117,7 +130,7 @@ static void hap_vram_tracking_init(struct domain *d)
 {
     paging_log_dirty_init(d, hap_enable_vram_tracking,
                           hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
+                          hap_clean_vram_tracking, NULL);
 }
 
 int hap_track_dirty_vram(struct domain *d,
@@ -220,8 +233,16 @@ static int hap_disable_log_dirty(struct domain *d)
 
 static void hap_clean_dirty_bitmap(struct domain *d)
 {
+    p2m_type_t p2mt = (hap_has_dirty_bit)? p2m_ram_logdirty : p2m_ram_rw;
     /* set l1e entries of P2M table to be read-only. */
-    p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
+    p2m_change_entry_type_global(d, p2mt, p2m_ram_logdirty);
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_update_dirty_bitmap(struct domain *d)
+{
+    /* find out dirty page by walking EPT table and update dirty bitmap. */
+    p2m_query_entry_global(d, WALK_EPT_D);
     flush_tlb_mask(d->domain_dirty_cpumask);
 }
 
@@ -238,7 +259,8 @@ void hap_logdirty_init(struct domain *d)
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
-                          hap_clean_dirty_bitmap);
+                          hap_clean_dirty_bitmap,
+                          hap_update_dirty_bitmap);
 }
 
 /************************************************/
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index c97cac4..7334167 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -1141,6 +1141,7 @@ void p2m_pt_init(struct p2m_domain *p2m)
     p2m->set_entry = p2m_set_entry;
     p2m->get_entry = p2m_gfn_to_mfn;
     p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->query_entry_global = NULL;
     p2m->write_p2m_entry = paging_write_p2m_entry;
 #if P2M_AUDIT
     p2m->audit_p2m = p2m_pt_audit_p2m;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 0a796f3..26b1ca7 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain *d,
     p2m_unlock(p2m);
 }
 
+void p2m_query_entry_global(struct domain *d, int mask)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    ASSERT(p2m);
+    p2m_lock(p2m);
+    p2m->query_entry_global(p2m, mask);
+    p2m_unlock(p2m);
+}
+
 mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
                     unsigned int *page_order, bool_t locked)
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..12ee552 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     int i4, i3, i2;
 
     domain_pause(d);
-    paging_lock(d);
 
     clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
+    if ( clean )
+    {
+        /* We need to further call clean_dirty_bitmap() functions of specific
+         * paging modes (shadow or hap).  Safe because the domain is paused.
+         * And this call must be made before actually transferring the dirty
+         * bitmap since with HW hap dirty bit support, dirty bitmap is
+         * produced by hooking on this call. */
+        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    }
+
+    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
+    {
+        d->arch.paging.log_dirty.update_dirty_bitmap(d);
+    }
+
+    paging_lock(d);
 
     PAGING_DEBUG(LOGDIRTY, "log-dirty %s: dom %u faults=%u dirty=%u\n",
                  (clean) ? "clean" : "peek",
@@ -420,17 +435,6 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     if ( pages < sc->pages )
         sc->pages = pages;
 
-    paging_unlock(d);
-
-    if ( clean )
-    {
-        /* We need to further call clean_dirty_bitmap() functions of specific
-         * paging modes (shadow or hap).  Safe because the domain is paused. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
-    }
-    domain_unpause(d);
-    return rv;
-
  out:
     paging_unlock(d);
     domain_unpause(d);
@@ -600,11 +604,13 @@ int paging_log_dirty_range(struct domain *d,
 void paging_log_dirty_init(struct domain *d,
                            int    (*enable_log_dirty)(struct domain *d),
                            int    (*disable_log_dirty)(struct domain *d),
-                           void   (*clean_dirty_bitmap)(struct domain *d))
+                           void   (*clean_dirty_bitmap)(struct domain *d),
+                           void   (*update_dirty_bitmap)(struct domain *d))
 {
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
+    d->arch.paging.log_dirty.update_dirty_bitmap = update_dirty_bitmap;
 }
 
 /* This function fress log dirty bitmap resources. */
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index dc245be..f4e7566 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -50,7 +50,7 @@ void shadow_domain_init(struct domain *d, unsigned int domcr_flags)
 
     /* Use shadow pagetables for log-dirty support */
     paging_log_dirty_init(d, shadow_enable_log_dirty, 
-                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap);
+                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap, NULL);
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     d->arch.paging.shadow.oos_active = 0;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index aecee68..22cd0f9 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -179,6 +179,7 @@ struct log_dirty_domain {
     int            (*enable_log_dirty   )(struct domain *d);
     int            (*disable_log_dirty  )(struct domain *d);
     void           (*clean_dirty_bitmap )(struct domain *d);
+    void           (*update_dirty_bitmap )(struct domain *d);
 };
 
 struct paging_domain {
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index bd5d732..fb43b27 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -31,6 +31,9 @@
 #define HAP_ERROR(_f, _a...)                                          \
     printk("hap error: %s(): " _f, __func__, ##_a)
 
+#define WALK_EPT_UNUSED    0
+#define WALK_EPT_D         2
+
 /************************************************/
 /*          hap domain page mapping             */
 /************************************************/
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 63bc7cf..21ed9a5 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -249,7 +249,7 @@ struct p2m_domain {
     void               (*change_entry_type_global)(struct p2m_domain *p2m,
                                                    p2m_type_t ot,
                                                    p2m_type_t nt);
-    
+    void               (*query_entry_global)(struct p2m_domain *p2m, int mask);
     void               (*write_p2m_entry)(struct p2m_domain *p2m,
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
@@ -506,6 +506,9 @@ int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
 void p2m_change_entry_type_global(struct domain *d, 
                                   p2m_type_t ot, p2m_type_t nt);
 
+/* Query across all p2m entries in a domain */
+void p2m_query_entry_global(struct domain *d, int mask);
+
 /* Change types across a range of p2m entries (start ... end-1) */
 void p2m_change_type_range(struct domain *d, 
                            unsigned long start, unsigned long end,
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index c432a97..9d95e51 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -160,7 +160,8 @@ int paging_log_dirty_disable(struct domain *d);
 void paging_log_dirty_init(struct domain *d,
                            int  (*enable_log_dirty)(struct domain *d),
                            int  (*disable_log_dirty)(struct domain *d),
-                           void (*clean_dirty_bitmap)(struct domain *d));
+                           void (*clean_dirty_bitmap)(struct domain *d),
+                           void (*update_dirty_bitmap)(struct domain *d));
 
 /* mark a page as dirty */
 void paging_mark_dirty(struct domain *d, unsigned long guest_mfn);
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 01:57:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 01: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 1ShAAb-00070W-W3; Wed, 20 Jun 2012 01:57:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1ShAAZ-0006zg-Q7
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 01:57:20 +0000
Received: from [85.158.139.83:13811] by server-8.bemta-5.messagelabs.com id
	F5/45-10278-EFD21EF4; Wed, 20 Jun 2012 01:57:18 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340157435!24566525!3
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM3ODQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16489 invoked from network); 20 Jun 2012 01:57:17 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 01:57:17 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Jun 2012 18:57:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="155756537"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 19 Jun 2012 18:57:13 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 20 Jun 2012 09:57:46 +0800
Message-Id: <1340157467-19553-4-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Cc: xudong.hao@intel.com, haitao.shan@intel.com, keir@xen.org,
	xiantao.zhang@intel.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
	update_dirty_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>
MIME-Version: 1.0
Content-Type: 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 log_dirty new function update_dirty_bitmap, which will only update the
log dirty bitmap, but won't clear the EPT page dirty bit. The function is used
by live migration peek round with EPT D bit supported.

Set correct p2m type when EPT dirty bit supported.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan<haitao.shan@intel.com>
---
 xen/arch/x86/mm/hap/hap.c       |   32 +++++++++++++++++++++++++++-----
 xen/arch/x86/mm/p2m-pt.c        |    1 +
 xen/arch/x86/mm/p2m.c           |    9 +++++++++
 xen/arch/x86/mm/paging.c        |   32 +++++++++++++++++++-------------
 xen/arch/x86/mm/shadow/common.c |    2 +-
 xen/include/asm-x86/domain.h    |    1 +
 xen/include/asm-x86/hap.h       |    3 +++
 xen/include/asm-x86/p2m.h       |    5 ++++-
 xen/include/asm-x86/paging.h    |    3 ++-
 9 files changed, 67 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 8790c58..2a4cf1d 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -76,6 +76,7 @@ static int hap_enable_vram_tracking(struct domain *d)
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
                           p2m_ram_rw, p2m_ram_logdirty);
 
+    /* A TLB flush is needed no matter whether hap dirty bit is supported */
     flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
@@ -83,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain *d)
 static int hap_disable_vram_tracking(struct domain *d)
 {
     struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    p2m_type_t p2mt = p2m_ram_rw;
 
     if ( !dirty_vram )
         return -EINVAL;
 
+    /* With hap dirty bit, p2m type cannot be changed from p2m_ram_logdirty
+     * to p2m_ram_rw when first fault is met. Actually, there is no such
+     * fault occurred.
+     */
+    if ( hap_has_dirty_bit )
+        p2mt = p2m_ram_logdirty;
+
     paging_lock(d);
     d->arch.paging.mode &= ~PG_log_dirty;
     paging_unlock(d);
 
     /* set l1e entries of P2M table with normal mode */
     p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
+                          p2mt, p2m_ram_rw);
 
-    flush_tlb_mask(d->domain_dirty_cpumask);
+    /* With hap dirty bit, we actually did not change HW sensitive bits
+     * of the P2M tables.
+     */
+    if ( !hap_has_dirty_bit )
+        flush_tlb_mask(d->domain_dirty_cpumask);
     return 0;
 }
 
@@ -117,7 +130,7 @@ static void hap_vram_tracking_init(struct domain *d)
 {
     paging_log_dirty_init(d, hap_enable_vram_tracking,
                           hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
+                          hap_clean_vram_tracking, NULL);
 }
 
 int hap_track_dirty_vram(struct domain *d,
@@ -220,8 +233,16 @@ static int hap_disable_log_dirty(struct domain *d)
 
 static void hap_clean_dirty_bitmap(struct domain *d)
 {
+    p2m_type_t p2mt = (hap_has_dirty_bit)? p2m_ram_logdirty : p2m_ram_rw;
     /* set l1e entries of P2M table to be read-only. */
-    p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
+    p2m_change_entry_type_global(d, p2mt, p2m_ram_logdirty);
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_update_dirty_bitmap(struct domain *d)
+{
+    /* find out dirty page by walking EPT table and update dirty bitmap. */
+    p2m_query_entry_global(d, WALK_EPT_D);
     flush_tlb_mask(d->domain_dirty_cpumask);
 }
 
@@ -238,7 +259,8 @@ void hap_logdirty_init(struct domain *d)
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
-                          hap_clean_dirty_bitmap);
+                          hap_clean_dirty_bitmap,
+                          hap_update_dirty_bitmap);
 }
 
 /************************************************/
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index c97cac4..7334167 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -1141,6 +1141,7 @@ void p2m_pt_init(struct p2m_domain *p2m)
     p2m->set_entry = p2m_set_entry;
     p2m->get_entry = p2m_gfn_to_mfn;
     p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->query_entry_global = NULL;
     p2m->write_p2m_entry = paging_write_p2m_entry;
 #if P2M_AUDIT
     p2m->audit_p2m = p2m_pt_audit_p2m;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 0a796f3..26b1ca7 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain *d,
     p2m_unlock(p2m);
 }
 
+void p2m_query_entry_global(struct domain *d, int mask)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    ASSERT(p2m);
+    p2m_lock(p2m);
+    p2m->query_entry_global(p2m, mask);
+    p2m_unlock(p2m);
+}
+
 mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
                     unsigned int *page_order, bool_t locked)
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..12ee552 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     int i4, i3, i2;
 
     domain_pause(d);
-    paging_lock(d);
 
     clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
+    if ( clean )
+    {
+        /* We need to further call clean_dirty_bitmap() functions of specific
+         * paging modes (shadow or hap).  Safe because the domain is paused.
+         * And this call must be made before actually transferring the dirty
+         * bitmap since with HW hap dirty bit support, dirty bitmap is
+         * produced by hooking on this call. */
+        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    }
+
+    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
+    {
+        d->arch.paging.log_dirty.update_dirty_bitmap(d);
+    }
+
+    paging_lock(d);
 
     PAGING_DEBUG(LOGDIRTY, "log-dirty %s: dom %u faults=%u dirty=%u\n",
                  (clean) ? "clean" : "peek",
@@ -420,17 +435,6 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     if ( pages < sc->pages )
         sc->pages = pages;
 
-    paging_unlock(d);
-
-    if ( clean )
-    {
-        /* We need to further call clean_dirty_bitmap() functions of specific
-         * paging modes (shadow or hap).  Safe because the domain is paused. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
-    }
-    domain_unpause(d);
-    return rv;
-
  out:
     paging_unlock(d);
     domain_unpause(d);
@@ -600,11 +604,13 @@ int paging_log_dirty_range(struct domain *d,
 void paging_log_dirty_init(struct domain *d,
                            int    (*enable_log_dirty)(struct domain *d),
                            int    (*disable_log_dirty)(struct domain *d),
-                           void   (*clean_dirty_bitmap)(struct domain *d))
+                           void   (*clean_dirty_bitmap)(struct domain *d),
+                           void   (*update_dirty_bitmap)(struct domain *d))
 {
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
+    d->arch.paging.log_dirty.update_dirty_bitmap = update_dirty_bitmap;
 }
 
 /* This function fress log dirty bitmap resources. */
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index dc245be..f4e7566 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -50,7 +50,7 @@ void shadow_domain_init(struct domain *d, unsigned int domcr_flags)
 
     /* Use shadow pagetables for log-dirty support */
     paging_log_dirty_init(d, shadow_enable_log_dirty, 
-                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap);
+                          shadow_disable_log_dirty, shadow_clean_dirty_bitmap, NULL);
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
     d->arch.paging.shadow.oos_active = 0;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index aecee68..22cd0f9 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -179,6 +179,7 @@ struct log_dirty_domain {
     int            (*enable_log_dirty   )(struct domain *d);
     int            (*disable_log_dirty  )(struct domain *d);
     void           (*clean_dirty_bitmap )(struct domain *d);
+    void           (*update_dirty_bitmap )(struct domain *d);
 };
 
 struct paging_domain {
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index bd5d732..fb43b27 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -31,6 +31,9 @@
 #define HAP_ERROR(_f, _a...)                                          \
     printk("hap error: %s(): " _f, __func__, ##_a)
 
+#define WALK_EPT_UNUSED    0
+#define WALK_EPT_D         2
+
 /************************************************/
 /*          hap domain page mapping             */
 /************************************************/
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 63bc7cf..21ed9a5 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -249,7 +249,7 @@ struct p2m_domain {
     void               (*change_entry_type_global)(struct p2m_domain *p2m,
                                                    p2m_type_t ot,
                                                    p2m_type_t nt);
-    
+    void               (*query_entry_global)(struct p2m_domain *p2m, int mask);
     void               (*write_p2m_entry)(struct p2m_domain *p2m,
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
@@ -506,6 +506,9 @@ int guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
 void p2m_change_entry_type_global(struct domain *d, 
                                   p2m_type_t ot, p2m_type_t nt);
 
+/* Query across all p2m entries in a domain */
+void p2m_query_entry_global(struct domain *d, int mask);
+
 /* Change types across a range of p2m entries (start ... end-1) */
 void p2m_change_type_range(struct domain *d, 
                            unsigned long start, unsigned long end,
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index c432a97..9d95e51 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -160,7 +160,8 @@ int paging_log_dirty_disable(struct domain *d);
 void paging_log_dirty_init(struct domain *d,
                            int  (*enable_log_dirty)(struct domain *d),
                            int  (*disable_log_dirty)(struct domain *d),
-                           void (*clean_dirty_bitmap)(struct domain *d));
+                           void (*clean_dirty_bitmap)(struct domain *d),
+                           void (*update_dirty_bitmap)(struct domain *d));
 
 /* mark a page as dirty */
 void paging_mark_dirty(struct domain *d, unsigned long guest_mfn);
-- 
1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 02:41:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 02:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShAqY-0008HK-OH; Wed, 20 Jun 2012 02:40:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShAqX-0008HF-Az
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 02:40:41 +0000
Received: from [85.158.143.35:60451] by server-1.bemta-4.messagelabs.com id
	4C/12-24392-82831EF4; Wed, 20 Jun 2012 02:40:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340160039!5232837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1993 invoked from network); 20 Jun 2012 02:40:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 02:40:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="13112789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 02:40:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 03:40:38 +0100
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 1ShAqU-0000xf-7P;
	Wed, 20 Jun 2012 02: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 1ShAqS-0008GB-H9;
	Wed, 20 Jun 2012 03:40:36 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 03:40:36 +0100
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-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-win7-amd64
test windows-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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6


  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13088 fail [host=leaf-beetle] / 13025 ok.
Failure / basis pass flights: 13088 / 13025
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-f7f8c33cd49885d69efc2e5f7f9a613d631762e2 http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-5b6a857411ba
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-upstream-unstable.git /export/home/osstest/repos/qemu-upstream-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-upstream-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
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-upstream-unstable.git /export/home/osstest/repos/qemu-upstream-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-upstream-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1021 nodes in revision graph
Searching for test results:
 13019 pass irrelevant
 12958 pass irrelevant
 13004 pass irrelevant
 13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 12981 pass irrelevant
 12960 pass irrelevant
 12964 pass irrelevant
 13038 []
 12967 pass irrelevant
 12968 pass irrelevant
 12969 pass irrelevant
 12971 pass irrelevant
 12972 pass irrelevant
 12975 pass irrelevant
 12976 pass irrelevant
 12977 pass irrelevant
 12988 pass irrelevant
 12978 pass irrelevant
 13020 pass irrelevant
 12979 pass irrelevant
 12995 pass irrelevant
 12980 pass irrelevant
 12996 pass irrelevant
 13006 pass irrelevant
 12997 pass irrelevant
 12998 pass irrelevant
 13023 pass irrelevant
 13012 pass irrelevant
 13051 fail irrelevant
 12999 pass irrelevant
 13013 pass irrelevant
 13002 pass irrelevant
 13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13003 pass irrelevant
 13014 pass irrelevant
 13045 []
 13015 pass irrelevant
 13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13016 pass irrelevant
 13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13018 pass irrelevant
 13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13046 []
 13037 []
 13053 fail irrelevant
 13061 fail irrelevant
 13069 fail irrelevant
 13099 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
 13102 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13103 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13075 fail irrelevant
 13105 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13080 fail irrelevant
 13087 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13092 fail irrelevant
 13093 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
 13094 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
 13095 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13088 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
 13096 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Searching for interesting versions
 Result found: flight 13024 (pass), for basis pass
 Result found: flight 13088 (fail), for basis failure
 Repro found: flight 13096 (pass), for basis pass
 Repro found: flight 13099 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
No revisions left to test, checking graph state.
 Result found: flight 13024 (pass), for last pass
 Result found: flight 13095 (fail), for first failure
 Repro found: flight 13096 (pass), for last pass
 Repro found: flight 13102 (fail), for first failure
 Repro found: flight 13103 (pass), for last pass
 Repro found: flight 13105 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.windows-install.{dot,ps,png,html}.
----------------------------------------
13105: tolerable ALL FAIL

flight 13105 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13105/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested


jobs:
 test-amd64-amd64-xl-win7-amd64                               fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Jun 20 02:41:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 02:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShAqY-0008HK-OH; Wed, 20 Jun 2012 02:40:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShAqX-0008HF-Az
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 02:40:41 +0000
Received: from [85.158.143.35:60451] by server-1.bemta-4.messagelabs.com id
	4C/12-24392-82831EF4; Wed, 20 Jun 2012 02:40:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340160039!5232837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1993 invoked from network); 20 Jun 2012 02:40:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 02:40:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="13112789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 02:40:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 03:40:38 +0100
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 1ShAqU-0000xf-7P;
	Wed, 20 Jun 2012 02: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 1ShAqS-0008GB-H9;
	Wed, 20 Jun 2012 03:40:36 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 03:40:36 +0100
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-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-win7-amd64
test windows-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/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6


  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13088 fail [host=leaf-beetle] / 13025 ok.
Failure / basis pass flights: 13088 / 13025
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/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03843603030d2b1aee86-f7f8c33cd49885d69efc2e5f7f9a613d631762e2 http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-5b6a857411ba
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-upstream-unstable.git /export/home/osstest/repos/qemu-upstream-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-upstream-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
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-upstream-unstable.git /export/home/osstest/repos/qemu-upstream-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-upstream-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1021 nodes in revision graph
Searching for test results:
 13019 pass irrelevant
 12958 pass irrelevant
 13004 pass irrelevant
 13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 12981 pass irrelevant
 12960 pass irrelevant
 12964 pass irrelevant
 13038 []
 12967 pass irrelevant
 12968 pass irrelevant
 12969 pass irrelevant
 12971 pass irrelevant
 12972 pass irrelevant
 12975 pass irrelevant
 12976 pass irrelevant
 12977 pass irrelevant
 12988 pass irrelevant
 12978 pass irrelevant
 13020 pass irrelevant
 12979 pass irrelevant
 12995 pass irrelevant
 12980 pass irrelevant
 12996 pass irrelevant
 13006 pass irrelevant
 12997 pass irrelevant
 12998 pass irrelevant
 13023 pass irrelevant
 13012 pass irrelevant
 13051 fail irrelevant
 12999 pass irrelevant
 13013 pass irrelevant
 13002 pass irrelevant
 13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13003 pass irrelevant
 13014 pass irrelevant
 13045 []
 13015 pass irrelevant
 13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13016 pass irrelevant
 13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13018 pass irrelevant
 13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
 13046 []
 13037 []
 13053 fail irrelevant
 13061 fail irrelevant
 13069 fail irrelevant
 13099 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
 13102 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13103 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13075 fail irrelevant
 13105 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13080 fail irrelevant
 13087 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
 13092 fail irrelevant
 13093 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
 13094 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
 13095 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
 13088 fail a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
 13096 pass a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
Searching for interesting versions
 Result found: flight 13024 (pass), for basis pass
 Result found: flight 13088 (fail), for basis failure
 Repro found: flight 13096 (pass), for basis pass
 Repro found: flight 13099 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 50c553be472c9f4b05a0526c0aae98709ca9ffff 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
No revisions left to test, checking graph state.
 Result found: flight 13024 (pass), for last pass
 Result found: flight 13095 (fail), for first failure
 Repro found: flight 13096 (pass), for last pass
 Repro found: flight 13102 (fail), for first failure
 Repro found: flight 13103 (pass), for last pass
 Repro found: flight 13105 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  9d1fd58ff602
  Bug not present: 32034d1914a6

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25468:9d1fd58ff602
  user:        Dario Faggioli <dario.faggioli@citrix.com>
  date:        Fri Jun 08 15:26:01 2012 +0100
      
      xl: check for meaningful combination of sedf config file parameters
      
      As it happens in the implementation of `xl sched-sedf -d ...', some
      consistency checking is needed for the scheduling parameters when
      they come from the config file.
      
      Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
      Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
      Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.windows-install.{dot,ps,png,html}.
----------------------------------------
13105: tolerable ALL FAIL

flight 13105 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13105/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested


jobs:
 test-amd64-amd64-xl-win7-amd64                               fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Jun 20 05:46:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 05:46: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 1ShDkI-0002yw-4V; Wed, 20 Jun 2012 05:46:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1ShDkG-0002yr-Q5
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 05:46:25 +0000
Received: from [85.158.139.83:13188] by server-11.bemta-5.messagelabs.com id
	D5/8A-20400-0B361EF4; Wed, 20 Jun 2012 05:46:24 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340171182!28522407!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxNzk2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17591 invoked from network); 20 Jun 2012 05:46:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 05:46:23 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Jun 2012 22:46:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167855442"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga001.fm.intel.com with ESMTP; 19 Jun 2012 22:46:21 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 22:46:20 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 22:46:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Wed, 20 Jun 2012 13:46:14 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Pasi K?rkk?inen <pasik@iki.fi>
Thread-Topic: [Xen-devel] VMX status report. Xen:24911 & Dom0:	d93dc5c4...
	Nested VMX testing?
Thread-Index: AQHNTlxjOp46Wznx+EynFoTXviJUspcCsRRw
Date: Wed, 20 Jun 2012 05:46:14 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FC10E@SHSMSX101.ccr.corp.intel.com>
References: <40352EBA8B4DF841A9907B883F22B59B0FCC58DE@SHSMSX102.ccr.corp.intel.com>
	<20120313153857.GA12984@reaktio.net>
	<1B4B44D9196EFF41AE41FDA404FC0A1005DA03@SHSMSX101.ccr.corp.intel.com>
	<20120619204429.GX2058@reaktio.net>
In-Reply-To: <20120619204429.GX2058@reaktio.net>
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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [Xen-devel] VMX status report. Xen:24911 & Dom0:	d93dc5c4...
 Nested VMX testing?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> Sent: Wednesday, June 20, 2012 4:44 AM
> To: Ren, Yongjie
> Cc: Zhou, Chao; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] VMX status report. Xen:24911 & Dom0:
> d93dc5c4... Nested VMX testing?
> =

> On Wed, Mar 14, 2012 at 08:00:09AM +0000, Ren, Yongjie wrote:
> > >
> > > Hello,
> > >
> > > > This is the test report of xen-unstable tree. We've switched our Do=
m0
> to
> > > upstream Linux 3.1-rc7 instead of Jeremy's 2.6.32.x tree.
> > > > We've also upgraded our nightly test system from RHEL5.5 to
> RHEL6.2.
> > > > We found four new issues and one old issue got fixed.
> > > >
> > >
> > > Is Intel planning to start testing Nested VMX ?
> >
> > Yes, we've made several automated test cases for Nested VMX.
> > The bad news is there's some bug on Nested VMX.
> > From my recent test, the following is the status for Nested VMX.
> >    Xen on Xen: failed. L1 Xen guest can't boot up. It hangs at the boot
> for xen hypervisor.
> >    KVM on Xen: pass. L2 RHEL5.5 guest can boot up on L1 KVM guest.
> > (We use the same version of dom0 and xen-unstable as mentioned in the
> report.)
> > Intel will make more effort on Nested VMX bug fixing this year.
> >
> =

> Hello again,
> =

> I'm wondering.. Does Intel have plans to do more Nested VMX testing (and
> bugfixes) before Xen 4.2 release?
> There's an action point on the Xen 4.2 status email about describing the
> status of Nested VMX support.
> =

Hum, we don't have specific plan or bug fixes on Nested VMX before 4.2 rele=
ase.
But we have an engineer who is looking at this issue now.
And we also test nested vmx biweekly. The status is the same as I described=
 before.
	Xen on Xen: failed. L1 guest can't boot up.
	KVM on Xen: good.

> =

> >
> > > It seems AMD has done a lot of testing with Nested SVM with Xen..
> > >
> =

> =

> 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 Jun 20 05:46:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 05:46: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 1ShDkI-0002yw-4V; Wed, 20 Jun 2012 05:46:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1ShDkG-0002yr-Q5
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 05:46:25 +0000
Received: from [85.158.139.83:13188] by server-11.bemta-5.messagelabs.com id
	D5/8A-20400-0B361EF4; Wed, 20 Jun 2012 05:46:24 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340171182!28522407!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxNzk2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17591 invoked from network); 20 Jun 2012 05:46:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 05:46:23 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Jun 2012 22:46:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="167855442"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga001.fm.intel.com with ESMTP; 19 Jun 2012 22:46:21 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 22:46:20 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 19 Jun 2012 22:46:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Wed, 20 Jun 2012 13:46:14 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Pasi K?rkk?inen <pasik@iki.fi>
Thread-Topic: [Xen-devel] VMX status report. Xen:24911 & Dom0:	d93dc5c4...
	Nested VMX testing?
Thread-Index: AQHNTlxjOp46Wznx+EynFoTXviJUspcCsRRw
Date: Wed, 20 Jun 2012 05:46:14 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FC10E@SHSMSX101.ccr.corp.intel.com>
References: <40352EBA8B4DF841A9907B883F22B59B0FCC58DE@SHSMSX102.ccr.corp.intel.com>
	<20120313153857.GA12984@reaktio.net>
	<1B4B44D9196EFF41AE41FDA404FC0A1005DA03@SHSMSX101.ccr.corp.intel.com>
	<20120619204429.GX2058@reaktio.net>
In-Reply-To: <20120619204429.GX2058@reaktio.net>
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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [Xen-devel] VMX status report. Xen:24911 & Dom0:	d93dc5c4...
 Nested VMX testing?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]
> Sent: Wednesday, June 20, 2012 4:44 AM
> To: Ren, Yongjie
> Cc: Zhou, Chao; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] VMX status report. Xen:24911 & Dom0:
> d93dc5c4... Nested VMX testing?
> =

> On Wed, Mar 14, 2012 at 08:00:09AM +0000, Ren, Yongjie wrote:
> > >
> > > Hello,
> > >
> > > > This is the test report of xen-unstable tree. We've switched our Do=
m0
> to
> > > upstream Linux 3.1-rc7 instead of Jeremy's 2.6.32.x tree.
> > > > We've also upgraded our nightly test system from RHEL5.5 to
> RHEL6.2.
> > > > We found four new issues and one old issue got fixed.
> > > >
> > >
> > > Is Intel planning to start testing Nested VMX ?
> >
> > Yes, we've made several automated test cases for Nested VMX.
> > The bad news is there's some bug on Nested VMX.
> > From my recent test, the following is the status for Nested VMX.
> >    Xen on Xen: failed. L1 Xen guest can't boot up. It hangs at the boot
> for xen hypervisor.
> >    KVM on Xen: pass. L2 RHEL5.5 guest can boot up on L1 KVM guest.
> > (We use the same version of dom0 and xen-unstable as mentioned in the
> report.)
> > Intel will make more effort on Nested VMX bug fixing this year.
> >
> =

> Hello again,
> =

> I'm wondering.. Does Intel have plans to do more Nested VMX testing (and
> bugfixes) before Xen 4.2 release?
> There's an action point on the Xen 4.2 status email about describing the
> status of Nested VMX support.
> =

Hum, we don't have specific plan or bug fixes on Nested VMX before 4.2 rele=
ase.
But we have an engineer who is looking at this issue now.
And we also test nested vmx biweekly. The status is the same as I described=
 before.
	Xen on Xen: failed. L1 guest can't boot up.
	KVM on Xen: good.

> =

> >
> > > It seems AMD has done a lot of testing with Nested SVM with Xen..
> > >
> =

> =

> 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 Jun 20 06:10:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 06:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShE7N-0003oa-He; Wed, 20 Jun 2012 06:10: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 1ShE7M-0003oT-72
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 06:10:16 +0000
Received: from [193.109.254.147:8386] by server-9.bemta-14.messagelabs.com id
	12/A6-07693-74961EF4; Wed, 20 Jun 2012 06:10:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340172614!8185173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9792 invoked from network); 20 Jun 2012 06:10:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 06:10:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="13113938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 06:10:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 07:10:13 +0100
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 1ShE7J-00025A-E6;
	Wed, 20 Jun 2012 06:10:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShE7J-0000gs-60;
	Wed, 20 Jun 2012 07:10:13 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13098-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 07:10:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13098: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13098 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13098/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b6a857411ba
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Jun 20 06:10:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 06:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShE7N-0003oa-He; Wed, 20 Jun 2012 06:10: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 1ShE7M-0003oT-72
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 06:10:16 +0000
Received: from [193.109.254.147:8386] by server-9.bemta-14.messagelabs.com id
	12/A6-07693-74961EF4; Wed, 20 Jun 2012 06:10:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340172614!8185173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9792 invoked from network); 20 Jun 2012 06:10:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 06:10:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="13113938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 06:10:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 07:10:13 +0100
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 1ShE7J-00025A-E6;
	Wed, 20 Jun 2012 06:10:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShE7J-0000gs-60;
	Wed, 20 Jun 2012 07:10:13 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13098-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 07:10:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13098: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13098 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13098/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b6a857411ba
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Jun 20 07:36:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 07: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 1ShFSG-0005oE-8R; Wed, 20 Jun 2012 07:35:56 +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 1ShFSE-0005o0-GZ
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 07:35:54 +0000
Received: from [85.158.138.51:2554] by server-12.bemta-3.messagelabs.com id
	3D/5F-30206-95D71EF4; Wed, 20 Jun 2012 07:35:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340177752!27465522!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1325 invoked from network); 20 Jun 2012 07:35:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	20 Jun 2012 07:35:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 08:35:52 +0100
Message-Id: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 08:36:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2F018C94.0__="
Subject: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part2F018C94.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- /dev/null
+++ b/docs/misc/efi.txt
@@ -0,0 +1,52 @@
+Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, =
as
+4.5.x was probably never really tested for this purpose) and binutils =
2.22 or
+newer. Additionally, the binutils build must be configured to include =
support
+for the x86_64-pep emulation (i.e. --enable-targets=3Dx86_64-pep or an =
option of
+equivalent effect should be passed to the configure script).
+
+Once built, "make install-xen" can place the resulting binary directly =
int
+the EFI boot partition, provided EFI_VENDOR is set (and EFI_MOUNTPOINT is
+overridden as needed, should the default of /boot/efi not match the =
target
+system).
+
+The binary itself will require a configuration file (names with the .efi
+extension of the binary's name replaced by .cfg, and - until an existing =
file
+is found - trailing name components dropped at '.', '-', and '_' =
separators
+will be tried) to be present in the same directory as the binary. (To
+illustrate the name handling, a binary named xen-4.2-unstable.efi would =
try
+xen-4.2-unstable.cfg, xen-4.2.cfg, xen-4.cfg, and xen.cfg in order.) One =
can
+override this with a command line option ("-cfg=3D<filename>").
+
+The configuration file consists of one or more sections headed by a =
section
+name enclosed in square brackets, with individual values specified in =
each
+section. A section named [global] is treated specially to allow certain
+settings to apply to all other sections (or to provide defaults for =
certain
+settings in case individual sections don't specify them). A typical file =
would
+thus look like this ('#' serving as comment character):
+
+**************************example begin******************************
+[global]
+default=3Dsle11sp2
+
+[sle11sp2]
+options=3Dconsole=3Dvga,com1 com1=3D57600 loglvl=3Dall noreboot
+kernel=3Dvmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=3Dxen
+ramdisk=3Dinitrd-3.0.31-0.4-xen
+**************************example end********************************
+
+Other values to specify are
+
+video=3Dgfx-<xres>[x<yres>[x<depth>]]
+(specifying a video mode to select if available; in case of problems the
+"-basevideo" command line option can be used to skip altering video =
modes)
+
+xsm=3D<filename>
+(specifying an XSM module to load)
+
+ucode=3D<filename>
+(specifying a CPU microcode blob to load)
+
+Filenames must be specified relative to the location of the EFI binary.
+
+Extra options to be passed to Xen can also be specified on the command =
line,
+following a "--" separator option.




--=__Part2F018C94.0__=
Content-Type: text/plain; name="EFI-build-doc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="EFI-build-doc.patch"

x86-64/EFI: document building and usage=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- /dev/null=0A+++ b/docs/misc/efi.txt=0A@@ -0,0 =
+1,52 @@=0A+Building xen.efi requires gcc 4.5.x or above (4.6.x or newer =
recommended, as=0A+4.5.x was probably never really tested for this =
purpose) and binutils 2.22 or=0A+newer. Additionally, the binutils build =
must be configured to include support=0A+for the x86_64-pep emulation =
(i.e. --enable-targets=3Dx86_64-pep or an option of=0A+equivalent effect =
should be passed to the configure script).=0A+=0A+Once built, "make =
install-xen" can place the resulting binary directly int=0A+the EFI boot =
partition, provided EFI_VENDOR is set (and EFI_MOUNTPOINT is=0A+overridden =
as needed, should the default of /boot/efi not match the target=0A+system).=
=0A+=0A+The binary itself will require a configuration file (names with =
the .efi=0A+extension of the binary's name replaced by .cfg, and - until =
an existing file=0A+is found - trailing name components dropped at '.', =
'-', and '_' separators=0A+will be tried) to be present in the same =
directory as the binary. (To=0A+illustrate the name handling, a binary =
named xen-4.2-unstable.efi would try=0A+xen-4.2-unstable.cfg, xen-4.2.cfg, =
xen-4.cfg, and xen.cfg in order.) One can=0A+override this with a command =
line option ("-cfg=3D<filename>").=0A+=0A+The configuration file consists =
of one or more sections headed by a section=0A+name enclosed in square =
brackets, with individual values specified in each=0A+section. A section =
named [global] is treated specially to allow certain=0A+settings to apply =
to all other sections (or to provide defaults for certain=0A+settings in =
case individual sections don't specify them). A typical file would=0A+thus =
look like this ('#' serving as comment character):=0A+=0A+*****************=
*********example begin******************************=0A+[global]=0A+default=
=3Dsle11sp2=0A+=0A+[sle11sp2]=0A+options=3Dconsole=3Dvga,com1 com1=3D57600 =
loglvl=3Dall noreboot=0A+kernel=3Dvmlinuz-3.0.31-0.4-xen ignore_loglevel =
#earlyprintk=3Dxen=0A+ramdisk=3Dinitrd-3.0.31-0.4-xen=0A+******************=
********example end********************************=0A+=0A+Other values to =
specify are=0A+=0A+video=3Dgfx-<xres>[x<yres>[x<depth>]]=0A+(specifying a =
video mode to select if available; in case of problems the=0A+"-basevideo" =
command line option can be used to skip altering video modes)=0A+=0A+xsm=3D=
<filename>=0A+(specifying an XSM module to load)=0A+=0A+ucode=3D<filename>=
=0A+(specifying a CPU microcode blob to load)=0A+=0A+Filenames must be =
specified relative to the location of the EFI binary.=0A+=0A+Extra options =
to be passed to Xen can also be specified on the command line,=0A+following=
 a "--" separator option.=0A
--=__Part2F018C94.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

--=__Part2F018C94.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 20 07:36:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 07: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 1ShFSG-0005oE-8R; Wed, 20 Jun 2012 07:35:56 +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 1ShFSE-0005o0-GZ
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 07:35:54 +0000
Received: from [85.158.138.51:2554] by server-12.bemta-3.messagelabs.com id
	3D/5F-30206-95D71EF4; Wed, 20 Jun 2012 07:35:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340177752!27465522!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1325 invoked from network); 20 Jun 2012 07:35:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	20 Jun 2012 07:35:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 08:35:52 +0100
Message-Id: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 08:36:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2F018C94.0__="
Subject: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part2F018C94.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- /dev/null
+++ b/docs/misc/efi.txt
@@ -0,0 +1,52 @@
+Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, =
as
+4.5.x was probably never really tested for this purpose) and binutils =
2.22 or
+newer. Additionally, the binutils build must be configured to include =
support
+for the x86_64-pep emulation (i.e. --enable-targets=3Dx86_64-pep or an =
option of
+equivalent effect should be passed to the configure script).
+
+Once built, "make install-xen" can place the resulting binary directly =
int
+the EFI boot partition, provided EFI_VENDOR is set (and EFI_MOUNTPOINT is
+overridden as needed, should the default of /boot/efi not match the =
target
+system).
+
+The binary itself will require a configuration file (names with the .efi
+extension of the binary's name replaced by .cfg, and - until an existing =
file
+is found - trailing name components dropped at '.', '-', and '_' =
separators
+will be tried) to be present in the same directory as the binary. (To
+illustrate the name handling, a binary named xen-4.2-unstable.efi would =
try
+xen-4.2-unstable.cfg, xen-4.2.cfg, xen-4.cfg, and xen.cfg in order.) One =
can
+override this with a command line option ("-cfg=3D<filename>").
+
+The configuration file consists of one or more sections headed by a =
section
+name enclosed in square brackets, with individual values specified in =
each
+section. A section named [global] is treated specially to allow certain
+settings to apply to all other sections (or to provide defaults for =
certain
+settings in case individual sections don't specify them). A typical file =
would
+thus look like this ('#' serving as comment character):
+
+**************************example begin******************************
+[global]
+default=3Dsle11sp2
+
+[sle11sp2]
+options=3Dconsole=3Dvga,com1 com1=3D57600 loglvl=3Dall noreboot
+kernel=3Dvmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=3Dxen
+ramdisk=3Dinitrd-3.0.31-0.4-xen
+**************************example end********************************
+
+Other values to specify are
+
+video=3Dgfx-<xres>[x<yres>[x<depth>]]
+(specifying a video mode to select if available; in case of problems the
+"-basevideo" command line option can be used to skip altering video =
modes)
+
+xsm=3D<filename>
+(specifying an XSM module to load)
+
+ucode=3D<filename>
+(specifying a CPU microcode blob to load)
+
+Filenames must be specified relative to the location of the EFI binary.
+
+Extra options to be passed to Xen can also be specified on the command =
line,
+following a "--" separator option.




--=__Part2F018C94.0__=
Content-Type: text/plain; name="EFI-build-doc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="EFI-build-doc.patch"

x86-64/EFI: document building and usage=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- /dev/null=0A+++ b/docs/misc/efi.txt=0A@@ -0,0 =
+1,52 @@=0A+Building xen.efi requires gcc 4.5.x or above (4.6.x or newer =
recommended, as=0A+4.5.x was probably never really tested for this =
purpose) and binutils 2.22 or=0A+newer. Additionally, the binutils build =
must be configured to include support=0A+for the x86_64-pep emulation =
(i.e. --enable-targets=3Dx86_64-pep or an option of=0A+equivalent effect =
should be passed to the configure script).=0A+=0A+Once built, "make =
install-xen" can place the resulting binary directly int=0A+the EFI boot =
partition, provided EFI_VENDOR is set (and EFI_MOUNTPOINT is=0A+overridden =
as needed, should the default of /boot/efi not match the target=0A+system).=
=0A+=0A+The binary itself will require a configuration file (names with =
the .efi=0A+extension of the binary's name replaced by .cfg, and - until =
an existing file=0A+is found - trailing name components dropped at '.', =
'-', and '_' separators=0A+will be tried) to be present in the same =
directory as the binary. (To=0A+illustrate the name handling, a binary =
named xen-4.2-unstable.efi would try=0A+xen-4.2-unstable.cfg, xen-4.2.cfg, =
xen-4.cfg, and xen.cfg in order.) One can=0A+override this with a command =
line option ("-cfg=3D<filename>").=0A+=0A+The configuration file consists =
of one or more sections headed by a section=0A+name enclosed in square =
brackets, with individual values specified in each=0A+section. A section =
named [global] is treated specially to allow certain=0A+settings to apply =
to all other sections (or to provide defaults for certain=0A+settings in =
case individual sections don't specify them). A typical file would=0A+thus =
look like this ('#' serving as comment character):=0A+=0A+*****************=
*********example begin******************************=0A+[global]=0A+default=
=3Dsle11sp2=0A+=0A+[sle11sp2]=0A+options=3Dconsole=3Dvga,com1 com1=3D57600 =
loglvl=3Dall noreboot=0A+kernel=3Dvmlinuz-3.0.31-0.4-xen ignore_loglevel =
#earlyprintk=3Dxen=0A+ramdisk=3Dinitrd-3.0.31-0.4-xen=0A+******************=
********example end********************************=0A+=0A+Other values to =
specify are=0A+=0A+video=3Dgfx-<xres>[x<yres>[x<depth>]]=0A+(specifying a =
video mode to select if available; in case of problems the=0A+"-basevideo" =
command line option can be used to skip altering video modes)=0A+=0A+xsm=3D=
<filename>=0A+(specifying an XSM module to load)=0A+=0A+ucode=3D<filename>=
=0A+(specifying a CPU microcode blob to load)=0A+=0A+Filenames must be =
specified relative to the location of the EFI binary.=0A+=0A+Extra options =
to be passed to Xen can also be specified on the command line,=0A+following=
 a "--" separator option.=0A
--=__Part2F018C94.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

--=__Part2F018C94.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 20 07:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 07: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 1ShFgb-00062X-No; Wed, 20 Jun 2012 07:50:45 +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 1ShFga-00062S-2D
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 07:50:44 +0000
Received: from [85.158.139.83:26480] by server-1.bemta-5.messagelabs.com id
	F2/A6-19721-3D081EF4; Wed, 20 Jun 2012 07:50:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340178642!21327087!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17104 invoked from network); 20 Jun 2012 07:50:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 07:50:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 08:50:41 +0100
Message-Id: <4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 08:51:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
In-Reply-To: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-win7-amd64
> test windows-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/staging/xen-unstable.hg 
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  9d1fd58ff602
>   Bug not present: 32034d1914a6
> 
> 
>   changeset:   25468:9d1fd58ff602
>   user:        Dario Faggioli <dario.faggioli@citrix.com>
>   date:        Fri Jun 08 15:26:01 2012 +0100
>       
>       xl: check for meaningful combination of sedf config file parameters

Dario,

these bisection results have been posted for a couple of days,
yet so far I don't recall having seen any sign from you as to what
you're plans are. Given that this has now been holding up a push
for over 10 days, I think I'll have to request reverting the change
otherwise.

Jan

>       As it happens in the implementation of `xl sched-sedf -d ...', some
>       consistency checking is needed for the scheduling parameters when
>       they come from the config file.
>       
>       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test- 
> amd64-amd64-xl-win7-amd64.windows-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  13088 fail [host=leaf-beetle] / 13025 ok.
> Failure / basis pass flights: 13088 / 13025
> 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/staging/xen-unstable.hg 
> Latest a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> Generating revisions with ./adhoc-revtuple-generator  
> git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-
> a938a246d34912423c560f475ccf1ce0c71d9d00 
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0
> aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff 
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03
> 843603030d2b1aee86-f7f8c33cd49885d69efc2e5f7f9a613d631762e2 
> http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-5b6a857411ba 
> 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-upstream-unstable.git 
> /export/home/osstest/repos/qemu-upstream-unstable...
> Initialized empty Git repository in 
> /export/home/osstest/repos/qemu-upstream-unstable/
> updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 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-upstream-unstable.git 
> /export/home/osstest/repos/qemu-upstream-unstable...
> Initialized empty Git repository in 
> /export/home/osstest/repos/qemu-upstream-unstable/
> updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> Loaded 1021 nodes in revision graph
> Searching for test results:
>  13019 pass irrelevant
>  12958 pass irrelevant
>  13004 pass irrelevant
>  13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
>  12981 pass irrelevant
>  12960 pass irrelevant
>  12964 pass irrelevant
>  13038 []
>  12967 pass irrelevant
>  12968 pass irrelevant
>  12969 pass irrelevant
>  12971 pass irrelevant
>  12972 pass irrelevant
>  12975 pass irrelevant
>  12976 pass irrelevant
>  12977 pass irrelevant
>  12988 pass irrelevant
>  12978 pass irrelevant
>  13020 pass irrelevant
>  12979 pass irrelevant
>  12995 pass irrelevant
>  12980 pass irrelevant
>  12996 pass irrelevant
>  13006 pass irrelevant
>  12997 pass irrelevant
>  12998 pass irrelevant
>  13023 pass irrelevant
>  13012 pass irrelevant
>  13051 fail irrelevant
>  12999 pass irrelevant
>  13013 pass irrelevant
>  13002 pass irrelevant
>  13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13003 pass irrelevant
>  13014 pass irrelevant
>  13045 []
>  13015 pass irrelevant
>  13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13016 pass irrelevant
>  13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
>  13018 pass irrelevant
>  13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
>  13046 []
>  13037 []
>  13053 fail irrelevant
>  13061 fail irrelevant
>  13069 fail irrelevant
>  13099 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
>  13102 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
>  13103 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13075 fail irrelevant
>  13105 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
>  13080 fail irrelevant
>  13087 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13092 fail irrelevant
>  13093 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
>  13094 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
>  13095 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
>  13088 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
>  13096 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> Searching for interesting versions
>  Result found: flight 13024 (pass), for basis pass
>  Result found: flight 13088 (fail), for basis failure
>  Repro found: flight 13096 (pass), for basis pass
>  Repro found: flight 13099 (fail), for basis failure
>  0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> No revisions left to test, checking graph state.
>  Result found: flight 13024 (pass), for last pass
>  Result found: flight 13095 (fail), for first failure
>  Repro found: flight 13096 (pass), for last pass
>  Repro found: flight 13102 (fail), for first failure
>  Repro found: flight 13103 (pass), for last pass
>  Repro found: flight 13105 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  9d1fd58ff602
>   Bug not present: 32034d1914a6
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   25468:9d1fd58ff602
>   user:        Dario Faggioli <dario.faggioli@citrix.com>
>   date:        Fri Jun 08 15:26:01 2012 +0100
>       
>       xl: check for meaningful combination of sedf config file parameters
>       
>       As it happens in the implementation of `xl sched-sedf -d ...', some
>       consistency checking is needed for the scheduling parameters when
>       they come from the config file.
>       
>       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> Revision graph left in 
> /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.w
> indows-install.{dot,ps,png,html}.
> ----------------------------------------
> 13105: tolerable ALL FAIL
> 
> flight 13105 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13105/ 
> 
> Failures :-/ but no regressions.
> 
> Tests which did not succeed,
> including tests which could not be run:
>  test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
> 
> 
> jobs:
>  test-amd64-amd64-xl-win7-amd64                               fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://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 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 07:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 07: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 1ShFgb-00062X-No; Wed, 20 Jun 2012 07:50:45 +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 1ShFga-00062S-2D
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 07:50:44 +0000
Received: from [85.158.139.83:26480] by server-1.bemta-5.messagelabs.com id
	F2/A6-19721-3D081EF4; Wed, 20 Jun 2012 07:50:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340178642!21327087!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17104 invoked from network); 20 Jun 2012 07:50:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 07:50:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 08:50:41 +0100
Message-Id: <4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 08:51:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
In-Reply-To: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-win7-amd64
> test windows-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/staging/xen-unstable.hg 
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  9d1fd58ff602
>   Bug not present: 32034d1914a6
> 
> 
>   changeset:   25468:9d1fd58ff602
>   user:        Dario Faggioli <dario.faggioli@citrix.com>
>   date:        Fri Jun 08 15:26:01 2012 +0100
>       
>       xl: check for meaningful combination of sedf config file parameters

Dario,

these bisection results have been posted for a couple of days,
yet so far I don't recall having seen any sign from you as to what
you're plans are. Given that this has now been holding up a push
for over 10 days, I think I'll have to request reverting the change
otherwise.

Jan

>       As it happens in the implementation of `xl sched-sedf -d ...', some
>       consistency checking is needed for the scheduling parameters when
>       they come from the config file.
>       
>       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test- 
> amd64-amd64-xl-win7-amd64.windows-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  13088 fail [host=leaf-beetle] / 13025 ok.
> Failure / basis pass flights: 13088 / 13025
> 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/staging/xen-unstable.hg 
> Latest a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> Generating revisions with ./adhoc-revtuple-generator  
> git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-
> a938a246d34912423c560f475ccf1ce0c71d9d00 
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0
> aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff 
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03
> 843603030d2b1aee86-f7f8c33cd49885d69efc2e5f7f9a613d631762e2 
> http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-5b6a857411ba 
> 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-upstream-unstable.git 
> /export/home/osstest/repos/qemu-upstream-unstable...
> Initialized empty Git repository in 
> /export/home/osstest/repos/qemu-upstream-unstable/
> updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 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-upstream-unstable.git 
> /export/home/osstest/repos/qemu-upstream-unstable...
> Initialized empty Git repository in 
> /export/home/osstest/repos/qemu-upstream-unstable/
> updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> Loaded 1021 nodes in revision graph
> Searching for test results:
>  13019 pass irrelevant
>  12958 pass irrelevant
>  13004 pass irrelevant
>  13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
>  12981 pass irrelevant
>  12960 pass irrelevant
>  12964 pass irrelevant
>  13038 []
>  12967 pass irrelevant
>  12968 pass irrelevant
>  12969 pass irrelevant
>  12971 pass irrelevant
>  12972 pass irrelevant
>  12975 pass irrelevant
>  12976 pass irrelevant
>  12977 pass irrelevant
>  12988 pass irrelevant
>  12978 pass irrelevant
>  13020 pass irrelevant
>  12979 pass irrelevant
>  12995 pass irrelevant
>  12980 pass irrelevant
>  12996 pass irrelevant
>  13006 pass irrelevant
>  12997 pass irrelevant
>  12998 pass irrelevant
>  13023 pass irrelevant
>  13012 pass irrelevant
>  13051 fail irrelevant
>  12999 pass irrelevant
>  13013 pass irrelevant
>  13002 pass irrelevant
>  13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13003 pass irrelevant
>  13014 pass irrelevant
>  13045 []
>  13015 pass irrelevant
>  13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13016 pass irrelevant
>  13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
>  13018 pass irrelevant
>  13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
>  13046 []
>  13037 []
>  13053 fail irrelevant
>  13061 fail irrelevant
>  13069 fail irrelevant
>  13099 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
>  13102 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
>  13103 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13075 fail irrelevant
>  13105 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
>  13080 fail irrelevant
>  13087 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
>  13092 fail irrelevant
>  13093 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
>  13094 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
>  13095 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
>  13088 fail a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
>  13096 pass a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> Searching for interesting versions
>  Result found: flight 13024 (pass), for basis pass
>  Result found: flight 13088 (fail), for basis failure
>  Repro found: flight 13096 (pass), for basis pass
>  Repro found: flight 13099 (fail), for basis failure
>  0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 
> 50c553be472c9f4b05a0526c0aae98709ca9ffff 
> 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> No revisions left to test, checking graph state.
>  Result found: flight 13024 (pass), for last pass
>  Result found: flight 13095 (fail), for first failure
>  Repro found: flight 13096 (pass), for last pass
>  Repro found: flight 13102 (fail), for first failure
>  Repro found: flight 13103 (pass), for last pass
>  Repro found: flight 13105 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  9d1fd58ff602
>   Bug not present: 32034d1914a6
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   25468:9d1fd58ff602
>   user:        Dario Faggioli <dario.faggioli@citrix.com>
>   date:        Fri Jun 08 15:26:01 2012 +0100
>       
>       xl: check for meaningful combination of sedf config file parameters
>       
>       As it happens in the implementation of `xl sched-sedf -d ...', some
>       consistency checking is needed for the scheduling parameters when
>       they come from the config file.
>       
>       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> Revision graph left in 
> /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.w
> indows-install.{dot,ps,png,html}.
> ----------------------------------------
> 13105: tolerable ALL FAIL
> 
> flight 13105 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13105/ 
> 
> Failures :-/ but no regressions.
> 
> Tests which did not succeed,
> including tests which could not be run:
>  test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
> 
> 
> jobs:
>  test-amd64-amd64-xl-win7-amd64                               fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://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 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 07:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 07: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 1ShFop-0006FJ-SJ; Wed, 20 Jun 2012 07:59:15 +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 1ShFoo-0006FE-Ke
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 07:59:14 +0000
Received: from [85.158.139.83:53243] by server-3.bemta-5.messagelabs.com id
	60/B2-03367-1D281EF4; Wed, 20 Jun 2012 07:59:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340179153!28586462!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15815 invoked from network); 20 Jun 2012 07:59: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 SMTP;
	20 Jun 2012 07:59:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 08:59:13 +0100
Message-Id: <4FE19F1B020000780008ABEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 08:59:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bastian Blank" <waldi@debian.org>
References: <20120619191253.GA22807@wavehammer.waldi.eu.org>
In-Reply-To: <20120619191253.GA22807@wavehammer.waldi.eu.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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 19.06.12 at 21:12, Bastian Blank <waldi@debian.org> wrote:
> According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
> void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
> it is correct.
> 
> The patch adds the missing asmlinkage to function declarations affected.
> It is needed for 4.1 and 4.2.

Iirc Keir had already taken steps towards removing all the
(pointless) asmlinkage annotations, so if there are any left I
think we'd rather see them removed than made consistent.

Additionally I doubt there is such a problem in current -unstable,
as the result of Keir's work was to have asmlinkage defined to
nothing on x86 (so I can't see how gcc would be able to diagnose
any inconsistencies). Is Debian (and 4.1) perhaps rather in need
of some backport?

Jan

> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> ---
> Origin: debian
> Forwarded: no
> Last-Update: 2012-06-15
> 
> --- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/arch/x86/i8259.c
> +++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/arch/x86/i8259.c
> @@ -62,7 +62,7 @@
>      IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \
>      IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)
>  
> -    static void (*interrupt[])(void) = {
> +    static void (*asmlinkage interrupt[])(void) = {
>          IRQLIST_16(0x0), IRQLIST_16(0x1), IRQLIST_16(0x2), IRQLIST_16(0x3),
>          IRQLIST_16(0x4), IRQLIST_16(0x5), IRQLIST_16(0x6), IRQLIST_16(0x7),
>          IRQLIST_16(0x8), IRQLIST_16(0x9), IRQLIST_16(0xa), IRQLIST_16(0xb),
> --- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/svm/intr.h
> +++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/svm/intr.h
> @@ -21,6 +21,8 @@
>  #ifndef __ASM_X86_HVM_SVM_INTR_H__
>  #define __ASM_X86_HVM_SVM_INTR_H__
>  
> -void svm_intr_assist(void);
> +#include <asm/config.h>
> +
> +asmlinkage void svm_intr_assist(void);

Furthermore, this ...

>  #endif /* __ASM_X86_HVM_SVM_INTR_H__ */
> --- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/vmx/vmx.h
> @@ -63,7 +63,7 @@
>  
>  void vmx_asm_vmexit_handler(struct cpu_user_regs);
>  void vmx_asm_do_vmentry(void);
> -void vmx_intr_assist(void);
> +asmlinkage void vmx_intr_assist(void);

... and this declaration could be dropped altogether (as having
call sites in assembly files only).

Jan

>  void vmx_do_resume(struct vcpu *);
>  void vmx_vlapic_msr_changed(struct vcpu *v);
>  void vmx_realmode(struct cpu_user_regs *regs);
> -- 
> There is a multi-legged creature crawling on your shoulder.
> 		-- Spock, "A Taste of Armageddon", stardate 3193.9
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 20 07:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 07: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 1ShFop-0006FJ-SJ; Wed, 20 Jun 2012 07:59:15 +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 1ShFoo-0006FE-Ke
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 07:59:14 +0000
Received: from [85.158.139.83:53243] by server-3.bemta-5.messagelabs.com id
	60/B2-03367-1D281EF4; Wed, 20 Jun 2012 07:59:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340179153!28586462!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15815 invoked from network); 20 Jun 2012 07:59: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 SMTP;
	20 Jun 2012 07:59:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 08:59:13 +0100
Message-Id: <4FE19F1B020000780008ABEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 08:59:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bastian Blank" <waldi@debian.org>
References: <20120619191253.GA22807@wavehammer.waldi.eu.org>
In-Reply-To: <20120619191253.GA22807@wavehammer.waldi.eu.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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 19.06.12 at 21:12, Bastian Blank <waldi@debian.org> wrote:
> According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
> void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
> it is correct.
> 
> The patch adds the missing asmlinkage to function declarations affected.
> It is needed for 4.1 and 4.2.

Iirc Keir had already taken steps towards removing all the
(pointless) asmlinkage annotations, so if there are any left I
think we'd rather see them removed than made consistent.

Additionally I doubt there is such a problem in current -unstable,
as the result of Keir's work was to have asmlinkage defined to
nothing on x86 (so I can't see how gcc would be able to diagnose
any inconsistencies). Is Debian (and 4.1) perhaps rather in need
of some backport?

Jan

> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> ---
> Origin: debian
> Forwarded: no
> Last-Update: 2012-06-15
> 
> --- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/arch/x86/i8259.c
> +++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/arch/x86/i8259.c
> @@ -62,7 +62,7 @@
>      IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \
>      IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)
>  
> -    static void (*interrupt[])(void) = {
> +    static void (*asmlinkage interrupt[])(void) = {
>          IRQLIST_16(0x0), IRQLIST_16(0x1), IRQLIST_16(0x2), IRQLIST_16(0x3),
>          IRQLIST_16(0x4), IRQLIST_16(0x5), IRQLIST_16(0x6), IRQLIST_16(0x7),
>          IRQLIST_16(0x8), IRQLIST_16(0x9), IRQLIST_16(0xa), IRQLIST_16(0xb),
> --- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/svm/intr.h
> +++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/svm/intr.h
> @@ -21,6 +21,8 @@
>  #ifndef __ASM_X86_HVM_SVM_INTR_H__
>  #define __ASM_X86_HVM_SVM_INTR_H__
>  
> -void svm_intr_assist(void);
> +#include <asm/config.h>
> +
> +asmlinkage void svm_intr_assist(void);

Furthermore, this ...

>  #endif /* __ASM_X86_HVM_SVM_INTR_H__ */
> --- xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2.orig/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/xen/include/asm-x86/hvm/vmx/vmx.h
> @@ -63,7 +63,7 @@
>  
>  void vmx_asm_vmexit_handler(struct cpu_user_regs);
>  void vmx_asm_do_vmentry(void);
> -void vmx_intr_assist(void);
> +asmlinkage void vmx_intr_assist(void);

... and this declaration could be dropped altogether (as having
call sites in assembly files only).

Jan

>  void vmx_do_resume(struct vcpu *);
>  void vmx_vlapic_msr_changed(struct vcpu *v);
>  void vmx_realmode(struct cpu_user_regs *regs);
> -- 
> There is a multi-legged creature crawling on your shoulder.
> 		-- Spock, "A Taste of Armageddon", stardate 3193.9
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Jun 20 08:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShG2F-0006xz-Jt; Wed, 20 Jun 2012 08:13:07 +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 1ShG2E-0006xu-HA
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:13:06 +0000
Received: from [85.158.138.51:65076] by server-9.bemta-3.messagelabs.com id
	27/EE-10419-11681EF4; Wed, 20 Jun 2012 08:13:05 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340179981!9896580!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2821 invoked from network); 20 Jun 2012 08:13:03 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jun 2012 08:13:03 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 6CA545424B; Wed, 20 Jun 2012 10:12:59 +0200 (CEST)
Date: Wed, 20 Jun 2012 10:12:59 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120620081258.GA2521@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
References: <20120619191253.GA22807@wavehammer.waldi.eu.org>
	<4FE19F1B020000780008ABEC@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE19F1B020000780008ABEC@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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, Jun 20, 2012 at 08:59:55AM +0100, Jan Beulich wrote:
> Iirc Keir had already taken steps towards removing all the
> (pointless) asmlinkage annotations, so if there are any left I
> think we'd rather see them removed than made consistent.

I see a lot of them and always not on both declaration and definition.

| xen/arch/arm/traps.c:asmlinkage void __div0(void)
| xen/arch/arm/traps.c:asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void leave_hypervisor_tail(void)
| xen/common/softirq.c:asmlinkage void do_softirq(void)
| xen/include/acpi/acpixf.h:acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state);
| xen/include/acpi/acpixf.h:acpi_status asmlinkage acpi_enter_sleep_state_s4bios(void);
| xen/include/xen/softirq.h:asmlinkage void do_softirq(void);

It is not longer problematic because asmlinkage is always defined
empty, but it is still there.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
		-- Kirk, "The Gamesters of Triskelion", stardate 3211.7

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShG2F-0006xz-Jt; Wed, 20 Jun 2012 08:13:07 +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 1ShG2E-0006xu-HA
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:13:06 +0000
Received: from [85.158.138.51:65076] by server-9.bemta-3.messagelabs.com id
	27/EE-10419-11681EF4; Wed, 20 Jun 2012 08:13:05 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340179981!9896580!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2821 invoked from network); 20 Jun 2012 08:13:03 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jun 2012 08:13:03 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 6CA545424B; Wed, 20 Jun 2012 10:12:59 +0200 (CEST)
Date: Wed, 20 Jun 2012 10:12:59 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120620081258.GA2521@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
References: <20120619191253.GA22807@wavehammer.waldi.eu.org>
	<4FE19F1B020000780008ABEC@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE19F1B020000780008ABEC@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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, Jun 20, 2012 at 08:59:55AM +0100, Jan Beulich wrote:
> Iirc Keir had already taken steps towards removing all the
> (pointless) asmlinkage annotations, so if there are any left I
> think we'd rather see them removed than made consistent.

I see a lot of them and always not on both declaration and definition.

| xen/arch/arm/traps.c:asmlinkage void __div0(void)
| xen/arch/arm/traps.c:asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
| xen/arch/arm/traps.c:asmlinkage void leave_hypervisor_tail(void)
| xen/common/softirq.c:asmlinkage void do_softirq(void)
| xen/include/acpi/acpixf.h:acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state);
| xen/include/acpi/acpixf.h:acpi_status asmlinkage acpi_enter_sleep_state_s4bios(void);
| xen/include/xen/softirq.h:asmlinkage void do_softirq(void);

It is not longer problematic because asmlinkage is always defined
empty, but it is still there.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
		-- Kirk, "The Gamesters of Triskelion", stardate 3211.7

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:29:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08:29:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShGHP-0007AN-2m; Wed, 20 Jun 2012 08:28:47 +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 1ShGHN-0007AI-Mp
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 08:28:45 +0000
Received: from [85.158.143.35:18346] by server-1.bemta-4.messagelabs.com id
	8C/04-24392-DB981EF4; Wed, 20 Jun 2012 08:28:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340180924!5437795!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDQwMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22622 invoked from network); 20 Jun 2012 08:28:44 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 08:28:44 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5K8SMRw031299;
	Wed, 20 Jun 2012 09:28:26 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5K8S9Qq009966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 09:28:09 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5K8S9LV004371;
	Wed, 20 Jun 2012 09:28:09 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5K8S8Ho004368; Wed, 20 Jun 2012 09:28:08 +0100 (BST)
Date: Wed, 20 Jun 2012 09:28:08 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Bastian Blank <waldi@debian.org>
In-Reply-To: <20120619191253.GA22807@wavehammer.waldi.eu.org>
Message-ID: <alpine.GSO.2.00.1206200922330.4323@algedi.dur.ac.uk>
References: <20120619191253.GA22807@wavehammer.waldi.eu.org>
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: q5K8SMRw031299
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Jun 2012, Bastian Blank wrote:

> According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
> void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
> it is correct.
>
> The patch adds the missing asmlinkage to function declarations affected.
> It is needed for 4.1 and 4.2.
>
> Signed-off-by: Bastian Blank <waldi@debian.org>

This is only relevant for 4.1 . In 4.2 asmlinkage got flattened to a no-op 
in changeset 24511
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a141f6d64916 . It 
would be a good idea to get this problem fixed for 4.1.3 but backporting 
the change from 4.2 might be a better idea.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:29:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08:29:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShGHP-0007AN-2m; Wed, 20 Jun 2012 08:28:47 +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 1ShGHN-0007AI-Mp
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 08:28:45 +0000
Received: from [85.158.143.35:18346] by server-1.bemta-4.messagelabs.com id
	8C/04-24392-DB981EF4; Wed, 20 Jun 2012 08:28:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340180924!5437795!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDQwMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22622 invoked from network); 20 Jun 2012 08:28:44 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 08:28:44 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5K8SMRw031299;
	Wed, 20 Jun 2012 09:28:26 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5K8S9Qq009966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 09:28:09 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5K8S9LV004371;
	Wed, 20 Jun 2012 09:28:09 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5K8S8Ho004368; Wed, 20 Jun 2012 09:28:08 +0100 (BST)
Date: Wed, 20 Jun 2012 09:28:08 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Bastian Blank <waldi@debian.org>
In-Reply-To: <20120619191253.GA22807@wavehammer.waldi.eu.org>
Message-ID: <alpine.GSO.2.00.1206200922330.4323@algedi.dur.ac.uk>
References: <20120619191253.GA22807@wavehammer.waldi.eu.org>
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: q5K8SMRw031299
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Jun 2012, Bastian Blank wrote:

> According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
> void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
> it is correct.
>
> The patch adds the missing asmlinkage to function declarations affected.
> It is needed for 4.1 and 4.2.
>
> Signed-off-by: Bastian Blank <waldi@debian.org>

This is only relevant for 4.1 . In 4.2 asmlinkage got flattened to a no-op 
in changeset 24511
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a141f6d64916 . It 
would be a good idea to get this problem fixed for 4.1.3 but backporting 
the change from 4.2 might be a better idea.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGS9-0007O2-79; Wed, 20 Jun 2012 08:39:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1ShGS8-0007Nx-IW
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:39:52 +0000
Received: from [193.109.254.147:39498] by server-5.bemta-14.messagelabs.com id
	E0/F9-04343-75C81EF4; Wed, 20 Jun 2012 08:39:51 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340181590!10602137!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDQwMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9032 invoked from network); 20 Jun 2012 08:39:51 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 08:39:51 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5K8buP8005275;
	Wed, 20 Jun 2012 09:38:00 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5K8bfP8010566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 09:37:41 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5K8bfjc004379;
	Wed, 20 Jun 2012 09:37:41 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5K8bfPc004376; Wed, 20 Jun 2012 09:37:41 +0100 (BST)
Date: Wed, 20 Jun 2012 09:37:41 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CC04F646.431E2%keir@xen.org>
Message-ID: <alpine.GSO.2.00.1206200932380.4323@algedi.dur.ac.uk>
References: <CC04F646.431E2%keir@xen.org>
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: q5K8buP8005275
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
 and	4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Mon, 18 Jun 2012, Keir Fraser wrote:

> I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:
>
> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)

Can I nominate xen-unstable revision 24511 for backporting please? It is 
needed to build 4.1 for gcc 4.7 - I haven't tried 4.0 .

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGS9-0007O2-79; Wed, 20 Jun 2012 08:39:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1ShGS8-0007Nx-IW
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:39:52 +0000
Received: from [193.109.254.147:39498] by server-5.bemta-14.messagelabs.com id
	E0/F9-04343-75C81EF4; Wed, 20 Jun 2012 08:39:51 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340181590!10602137!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDQwMTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9032 invoked from network); 20 Jun 2012 08:39:51 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 08:39:51 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5K8buP8005275;
	Wed, 20 Jun 2012 09:38:00 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5K8bfP8010566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 09:37:41 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5K8bfjc004379;
	Wed, 20 Jun 2012 09:37:41 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5K8bfPc004376; Wed, 20 Jun 2012 09:37:41 +0100 (BST)
Date: Wed, 20 Jun 2012 09:37:41 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CC04F646.431E2%keir@xen.org>
Message-ID: <alpine.GSO.2.00.1206200932380.4323@algedi.dur.ac.uk>
References: <CC04F646.431E2%keir@xen.org>
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: q5K8buP8005275
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
 and	4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Mon, 18 Jun 2012, Keir Fraser wrote:

> I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:
>
> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)

Can I nominate xen-unstable revision 24511 for backporting please? It is 
needed to build 4.1 for gcc 4.7 - I haven't tried 4.0 .

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGV7-0007Ux-Q2; Wed, 20 Jun 2012 08:42:57 +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 1ShGV6-0007Us-Tz
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:42:57 +0000
Received: from [85.158.143.35:50271] by server-3.bemta-4.messagelabs.com id
	7C/F9-05808-01D81EF4; Wed, 20 Jun 2012 08:42:56 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340181775!6134133!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22890 invoked from network); 20 Jun 2012 08:42:55 -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;
	20 Jun 2012 08:42:55 -0000
Received: by eekd41 with SMTP id d41so2598183eek.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 01:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=iXDEZvr9CljbNwZSjnkB6BkekizZV33kmLlNtim/r6A=;
	b=O2qeUT9mJvaMPGDUJEopXoqurIkPfPtNEPVNZrwW6WC+Cua1fGyKx6EL1FoIfB0CPs
	zXrAeZVDyHHP8dc0r420bbPsMB/xRJS2+CWIbKYy1DNztIzUwN0GMuXSXeYJjLzYcdd0
	5tVuM4VO6+P5U1PG9JcD9fDI/IyV30+uc0aXu4pIuVDossjp6uccDVf/D3qTf48JWCOj
	DtHcCc87geiz3gOZnlwZWW6B80s8IjxAY7Suf6C3q+65XJoXYl65ZoBQzqWp+KyBJLhM
	7ZYFs9i1FqCMKIOM6vyMX41IeoUBOZBVCv/M5wAO8wVUqsh/V/N5WUO+wnueE0t57da8
	utRw==
Received: by 10.14.100.197 with SMTP id z45mr5161940eef.54.1340181774919;
	Wed, 20 Jun 2012 01:42:54 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id u16sm87274884eeb.16.2012.06.20.01.42.52
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 01:42:54 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 09:42:50 +0100
From: Keir Fraser <keir@xen.org>
To: Bastian Blank <waldi@debian.org>,
	<xen-devel@lists.xen.org>
Message-ID: <CC074B9A.43307%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] Fix asmlinkage functions
Thread-Index: Ac1OwKyYC/QYRBU7+UadGvRk/9JJKA==
In-Reply-To: <20120620081258.GA2521@wavehammer.waldi.eu.org>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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 20/06/2012 09:12, "Bastian Blank" <waldi@debian.org> wrote:

> On Wed, Jun 20, 2012 at 08:59:55AM +0100, Jan Beulich wrote:
>> Iirc Keir had already taken steps towards removing all the
>> (pointless) asmlinkage annotations, so if there are any left I
>> think we'd rather see them removed than made consistent.
> 
> I see a lot of them and always not on both declaration and definition.

Most of the below are in arch/arm, no relevance to x86. The few others are
acceptable, only acpi_enter_sleep_state() has a 'non-matching' definition in
arch/x86, but of course x86 asmlinkage is a no-op so it's fine.

I have backported my xen-unstable patch to 4.0 and 4.1, so you should find
those trees build okay now.

 -- Keir

> | xen/arch/arm/traps.c:asmlinkage void __div0(void)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_undefined_instruction(struct
> cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_supervisor_call(struct
> cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_prefetch_abort(struct
> cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_data_abort(struct cpu_user_regs
> *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_hypervisor(struct cpu_user_regs
> *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void leave_hypervisor_tail(void)
> | xen/common/softirq.c:asmlinkage void do_softirq(void)
> | xen/include/acpi/acpixf.h:acpi_status asmlinkage acpi_enter_sleep_state(u8
> sleep_state);
> | xen/include/acpi/acpixf.h:acpi_status asmlinkage
> acpi_enter_sleep_state_s4bios(void);
> | xen/include/xen/softirq.h:asmlinkage void do_softirq(void);
> 
> It is not longer problematic because asmlinkage is always defined
> empty, but it is still there.
> 
> Bastian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGV7-0007Ux-Q2; Wed, 20 Jun 2012 08:42:57 +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 1ShGV6-0007Us-Tz
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:42:57 +0000
Received: from [85.158.143.35:50271] by server-3.bemta-4.messagelabs.com id
	7C/F9-05808-01D81EF4; Wed, 20 Jun 2012 08:42:56 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340181775!6134133!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22890 invoked from network); 20 Jun 2012 08:42:55 -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;
	20 Jun 2012 08:42:55 -0000
Received: by eekd41 with SMTP id d41so2598183eek.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 01:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=iXDEZvr9CljbNwZSjnkB6BkekizZV33kmLlNtim/r6A=;
	b=O2qeUT9mJvaMPGDUJEopXoqurIkPfPtNEPVNZrwW6WC+Cua1fGyKx6EL1FoIfB0CPs
	zXrAeZVDyHHP8dc0r420bbPsMB/xRJS2+CWIbKYy1DNztIzUwN0GMuXSXeYJjLzYcdd0
	5tVuM4VO6+P5U1PG9JcD9fDI/IyV30+uc0aXu4pIuVDossjp6uccDVf/D3qTf48JWCOj
	DtHcCc87geiz3gOZnlwZWW6B80s8IjxAY7Suf6C3q+65XJoXYl65ZoBQzqWp+KyBJLhM
	7ZYFs9i1FqCMKIOM6vyMX41IeoUBOZBVCv/M5wAO8wVUqsh/V/N5WUO+wnueE0t57da8
	utRw==
Received: by 10.14.100.197 with SMTP id z45mr5161940eef.54.1340181774919;
	Wed, 20 Jun 2012 01:42:54 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id u16sm87274884eeb.16.2012.06.20.01.42.52
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 01:42:54 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 09:42:50 +0100
From: Keir Fraser <keir@xen.org>
To: Bastian Blank <waldi@debian.org>,
	<xen-devel@lists.xen.org>
Message-ID: <CC074B9A.43307%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] Fix asmlinkage functions
Thread-Index: Ac1OwKyYC/QYRBU7+UadGvRk/9JJKA==
In-Reply-To: <20120620081258.GA2521@wavehammer.waldi.eu.org>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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 20/06/2012 09:12, "Bastian Blank" <waldi@debian.org> wrote:

> On Wed, Jun 20, 2012 at 08:59:55AM +0100, Jan Beulich wrote:
>> Iirc Keir had already taken steps towards removing all the
>> (pointless) asmlinkage annotations, so if there are any left I
>> think we'd rather see them removed than made consistent.
> 
> I see a lot of them and always not on both declaration and definition.

Most of the below are in arch/arm, no relevance to x86. The few others are
acceptable, only acpi_enter_sleep_state() has a 'non-matching' definition in
arch/x86, but of course x86 asmlinkage is a no-op so it's fine.

I have backported my xen-unstable patch to 4.0 and 4.1, so you should find
those trees build okay now.

 -- Keir

> | xen/arch/arm/traps.c:asmlinkage void __div0(void)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_undefined_instruction(struct
> cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_supervisor_call(struct
> cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_prefetch_abort(struct
> cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_data_abort(struct cpu_user_regs
> *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_hypervisor(struct cpu_user_regs
> *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_irq(struct cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void do_trap_fiq(struct cpu_user_regs *regs)
> | xen/arch/arm/traps.c:asmlinkage void leave_hypervisor_tail(void)
> | xen/common/softirq.c:asmlinkage void do_softirq(void)
> | xen/include/acpi/acpixf.h:acpi_status asmlinkage acpi_enter_sleep_state(u8
> sleep_state);
> | xen/include/acpi/acpixf.h:acpi_status asmlinkage
> acpi_enter_sleep_state_s4bios(void);
> | xen/include/xen/softirq.h:asmlinkage void do_softirq(void);
> 
> It is not longer problematic because asmlinkage is always defined
> empty, but it is still there.
> 
> Bastian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGVu-0007YS-7X; Wed, 20 Jun 2012 08:43:46 +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 1ShGVs-0007YB-6J
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 08:43:44 +0000
Received: from [85.158.139.83:53999] by server-7.bemta-5.messagelabs.com id
	C5/BB-28276-F3D81EF4; Wed, 20 Jun 2012 08:43:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340181822!21338532!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4468 invoked from network); 20 Jun 2012 08:43:42 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 08:43:42 -0000
Received: by eeke50 with SMTP id e50so3165755eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 20 Jun 2012 01:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=202BLLhdKmE+UGjC9g/4K/+2qXa5YQg3O2/mMMgrU5w=;
	b=QSKSxYuEdF5Bywsp38OJ8U7o0Ud0PsQ2pEPtBmumezFNP7Jpihdv16L9tZaGJtYq4u
	kJaK1Qt56g5BO8mT9XGAAqze8TxJdWhxYF8Lwq3sTW9wHtDLZhcxyikzJA3MHs8W6a3o
	6zz/N4yN4GXDP/UG4b5879yOTY8oM29ud1/h7k4mU2Tue4uh0hAxZchDQjLKud/y89R6
	bG+PGp9qFaM9DrBuMtHJW41Zfm1LDtKfhPu24x3ocKkWvqsFVr79SzJc7hVU68wPk2oC
	FnGUl2c2Cr68ndHYSFRakx/qZcUa43zuadiYYiwQ00vwoLPIojFGC6xBPjhJ2hRBCTaR
	UHcA==
Received: by 10.14.100.137 with SMTP id z9mr4839809eef.227.1340181822346;
	Wed, 20 Jun 2012 01:43:42 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id y54sm87301015eef.10.2012.06.20.01.43.39
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 01:43:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 09:43:28 +0100
From: Keir Fraser <keir@xen.org>
To: M A Young <m.a.young@durham.ac.uk>,
	Bastian Blank <waldi@debian.org>
Message-ID: <CC074BC0.43308%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] Fix asmlinkage functions
Thread-Index: Ac1OwMM/q2TMpWXhMEGqEDGC9lHZdA==
In-Reply-To: <alpine.GSO.2.00.1206200922330.4323@algedi.dur.ac.uk>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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 20/06/2012 09:28, "M A Young" <m.a.young@durham.ac.uk> wrote:

> On Tue, 19 Jun 2012, Bastian Blank wrote:
> 
>> According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
>> void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
>> it is correct.
>> 
>> The patch adds the missing asmlinkage to function declarations affected.
>> It is needed for 4.1 and 4.2.
>> 
>> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> This is only relevant for 4.1 . In 4.2 asmlinkage got flattened to a no-op
> in changeset 24511
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a141f6d64916 . It
> would be a good idea to get this problem fixed for 4.1.3 but backporting
> the change from 4.2 might be a better idea.

Done, and for forthcoming 4.0.4-rc3 too.

> Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGVu-0007YS-7X; Wed, 20 Jun 2012 08:43:46 +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 1ShGVs-0007YB-6J
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 08:43:44 +0000
Received: from [85.158.139.83:53999] by server-7.bemta-5.messagelabs.com id
	C5/BB-28276-F3D81EF4; Wed, 20 Jun 2012 08:43:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340181822!21338532!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4468 invoked from network); 20 Jun 2012 08:43:42 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 08:43:42 -0000
Received: by eeke50 with SMTP id e50so3165755eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 20 Jun 2012 01:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=202BLLhdKmE+UGjC9g/4K/+2qXa5YQg3O2/mMMgrU5w=;
	b=QSKSxYuEdF5Bywsp38OJ8U7o0Ud0PsQ2pEPtBmumezFNP7Jpihdv16L9tZaGJtYq4u
	kJaK1Qt56g5BO8mT9XGAAqze8TxJdWhxYF8Lwq3sTW9wHtDLZhcxyikzJA3MHs8W6a3o
	6zz/N4yN4GXDP/UG4b5879yOTY8oM29ud1/h7k4mU2Tue4uh0hAxZchDQjLKud/y89R6
	bG+PGp9qFaM9DrBuMtHJW41Zfm1LDtKfhPu24x3ocKkWvqsFVr79SzJc7hVU68wPk2oC
	FnGUl2c2Cr68ndHYSFRakx/qZcUa43zuadiYYiwQ00vwoLPIojFGC6xBPjhJ2hRBCTaR
	UHcA==
Received: by 10.14.100.137 with SMTP id z9mr4839809eef.227.1340181822346;
	Wed, 20 Jun 2012 01:43:42 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id y54sm87301015eef.10.2012.06.20.01.43.39
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 01:43:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 09:43:28 +0100
From: Keir Fraser <keir@xen.org>
To: M A Young <m.a.young@durham.ac.uk>,
	Bastian Blank <waldi@debian.org>
Message-ID: <CC074BC0.43308%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] Fix asmlinkage functions
Thread-Index: Ac1OwMM/q2TMpWXhMEGqEDGC9lHZdA==
In-Reply-To: <alpine.GSO.2.00.1206200922330.4323@algedi.dur.ac.uk>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix asmlinkage 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 20/06/2012 09:28, "M A Young" <m.a.young@durham.ac.uk> wrote:

> On Tue, 19 Jun 2012, Bastian Blank wrote:
> 
>> According to gcc-4.7, "void bla(void)" is incompatible with "asmlinkage
>> void bla(void)". As asmlinkage expands to __attribute__((regparm(0))),
>> it is correct.
>> 
>> The patch adds the missing asmlinkage to function declarations affected.
>> It is needed for 4.1 and 4.2.
>> 
>> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> This is only relevant for 4.1 . In 4.2 asmlinkage got flattened to a no-op
> in changeset 24511
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a141f6d64916 . It
> would be a good idea to get this problem fixed for 4.1.3 but backporting
> the change from 4.2 might be a better idea.

Done, and for forthcoming 4.0.4-rc3 too.

> Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGan-0007qq-3D; Wed, 20 Jun 2012 08:48: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 1ShGak-0007qf-Te
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:48:47 +0000
Received: from [85.158.139.83:5205] by server-3.bemta-5.messagelabs.com id
	77/EE-03367-E6E81EF4; Wed, 20 Jun 2012 08:48:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340182125!24298610!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6179 invoked from network); 20 Jun 2012 08:48:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 08:48:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 09:48:44 +0100
Message-Id: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 09:49:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
In-Reply-To: <20448.49637.38489.246434@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 20:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
Representing only personal (i.e. not necessarily my employer's)
opinions below.

> 1. Purpose of the process
> 
> The first point is that we think the security vulnerability process
> document should have an explanation of what its goals are.  This would
> have greatly assisted us when making some of the more difficult
> decisions.
> 
> In particular, if the process explained its purpose, we would be able
> to refer to the spirit of the document when making interpretation
> decisions or dealing with issues not clearly resolved by the document.
> 
> In this context we need to decide whether:
>  (a) the predisclosure arrangements are just there so that
>      organisations can backport patches, develop and test updated
>      versions, and so forth;
>  (b) the arrangements are also intended to allow operators to deploy
>      fixed versions.
> 
> Of course this needs to deal clearly with the common stituation of an
> organisation running Xen which is a direct consumer of Xen.org source
> code.

(a). Anything beyond may give (and apparently gave in the case
at hand) unfair advantages to certain downstreams over others.

> 2. Extension of embargo dates
> 
> The most controversial decision was whether the embargo date might be
> extended after it had originally been set.  We resisted these
> suggestions, referring to the process document, which does not
> contemplate extending the disclosure period.  However, when a
> predisclosure list member pressured the discoverer into requesting an
> extension, we felt the best interpretation of the process document
> required us to acquiesce.
> 
> Specifically, of course, we as a team would like clearer guidance from
> the process about whether, and if so under what circumstances, a
> predisclosure period should be extended.

I think this should be done via (perhaps silent) consensus on the
pre-discosure list. Leaving the embargo time line determination
entirely to the discoverer isn't really suitable. He might provide an
initial suggestion, but we ought to set a period of time (say, a
week or less) during which adjustment proposals can be made.

Extensions to the embargo period should be limited exclusively to
cases where problems addressing the problem in a timely manner
(including eventual later _necessary_ adjustments to the fixes)
arise.

> 3. Decisionmaking
> 
> It was suggested to us several times, and indeed seemed to be regarded
> by some as an underlying principle, that the predisclosure list
> members should be making the decisions about disclosure schedule etc.
> 
> The question of who is to make the decisions, and on what basis, needs
> to be addressed.

See above. Leaving this to the discretion of the discoverer is
neither open nor fair.

> 4. Length of (default) predisclosure period
> 
> Several members of the predisclosure list suggested that the
> predisclosure period was too short.  Others were ready within the
> predisclosure period's timeframe, and were disappointed to see it
> extended and to have to delay their fixes.

Setting a default period might be counter productive. There may
be cases (for example had we wanted to fix XSA-9 properly)
where developing a fix could take quite a bit of time. Not having
a fix ready shouldn't, however, prevent initial announcements of
a problem.

> 5. Criteria for predisclosure list membership
> 
> We had one request from a public Xen cloud provider to be provided
> with predisclosure information.  However it appeared to us that they
> didn't meet the size threshold in the process document.
> 
> The size threshold is of course open to discussion.
> 
> We need to clarify whether upstreams and hardware vendors should be on
> the predisclosure list.  Currently we have one notable upstream vendor
> on that list.
> 
> Our preliminary view is that the predisclosure list should be used for
> downstream notifications.  Upstreams, including hardware
> manufacturers, should be brought in to the disclosure process as
> needed.  And as noted, our process for making sure we do that properly
> needs to be formalised.
> 
> It is probably time for a review of the membership of the
> predisclosure list, in any case, after we have incorporated any
> changes to the criteria which are agreed as a result of this
> discussion.

I think having hardware vendors involved is really only necessary
when hardware related issues need to be dealt with.

As to downstreams, I think only direct ones should be involved in
any decision making processes. Indirect ones might be allowed on
the list, but exclusively as observers. Mis-use of the observer role
(e.g. as in influencing those participating in decision making in
undue ways), should it become known, should result in removal of
list membership.

> 6. Sharing of information and code between predisclosure participants
> 
> We need the process document to be clearer about what kinds of
> communications are contemplated _between_ members of the predisclosure
> list.
> 
> One particular issue here which also relates to the predisclosure
> membership criteria, is whether large indirect consumers of Xen should
> be on the predisclosure list in their own right.  That would allow
> them to deploy the fix before the embargo date.  It would also allow
> them to prepare for testing and deployment, before the fix is
> available from their vendor (who would in this scenario also be
> entitled to be a predisclosure list member).
> 
> In this context, the process needs to clarify whether vendors may
> release fixed binaries during the predisclosure period.  Certainly
> these should not be released other than to predisclosure list members,
> since the nature of a bug can often by discovered by reverse
> engineering.  But can they be released to predisclousre list members ?

As indicated above, this should not be permitted, due to
fairness considerations. Otherwise we should not place
restrictions on who might be on the list at least as an observer.

> 7. Public communications during the embargo period
> 
> We need to clarify what individual vendors are allowed to say during
> the embargo period.  It was brought to our attention that one public
> cloud provider told its users that their VMs would be migrated due to
> "a vendor issue" which would be revealed in "a few weeks".  Our view
> was that that was fine.
> 
> As a starting point, it seems to us that it is OK to disclose that
> there is an issue, including its XSA and CVE numbers and its planned
> disclosure date; but that it is not OK to disclose the impact, scope,
> set of vulnerable systems, and certainly not the nature of the
> vulnerability.
> 
> And we need to clarify what information the security team should give
> out when we get an enquiry from a community member about an embargoed
> problem.

Just the same we allow individual vendors to communicate -
acknowledge the fact that there is a vulnerability, identifiers, and
expected embargo deadline.

The alternative would be to not do and allow any communication,
which I think is not realistic to enforce.

> 8. Predisclosure subscription process, and email address criteria
> 
> We certainly need to clarify the subscription process to the list, to
> make it clear that the organisation's security team should request all
> subscriptions and that self-subscriptions via the mailing list
> interface will be rejected out of hand.  The current arrangements have
> caused quite a lot of admin work, to confirm various change requests.
> 
> The predisclosure list contains a number of individuals at various
> organisations.  One vendor seemed to get into difficulty because it
> had only one individual on the predisclosure list, which seems to have
> unfortunately kept their established team in the dark during the early
> stages of the process.  The process document requires that downstreams
> on the list have established security teams.  Should we require that
> such response teams' contact details be publicly advertised ?  Should
> we insist that only response teams' role addresses may be included on
> the list ?

Yes.

> 9. Vulnerability process scope
> 
> We need to clarify the scope of the process document.  Currently it
> looks like it covers every Xen.org project.
> 
> While it would be a nice ideal to support every Xen.org project this
> way, in practice the team behind security@xen do not have the
> expertise or resources to fix problems in (say) XCP, or the ARM PV
> port.  Our capability is concentrated on the "Upstream Xen" codebase
> (xen-*.hg and its sub-repositories) and the Xen support code in Linux.
> 
> Perhaps this could be dealt with by making it clear that problems are
> handled on a best effort basis.

Agreed.

> 10. Exploits
> 
> We need a clear policy about releasing proof of concept exploits -
> whether, when and who to.

This I think could (and perhaps should) be really be left to the
discoverer, as this may be considered intellectual property.

> 11. Transparency
> 
> We think the process document should explicitly state that any
> potentially controversial private decisions made by the Xen.org
> security response team should be disclosed after the vulnerability
> itself is disclosed.

While fine from a theoretical pov, this places extra work on the
security response team, and I'm therefore not sure it's worth it.

Perhaps, if anything, such information (when regarding details of
the implementation of a fix) could go into the commit message.

> 13. Patch development and review
> 
> The patch development process is too closed and not robust enough.
> 
> We need to be much clearer both about the need for security patches to
> fix things in the smallest, simplest and most reliable way, and not
> fix or "improve" matters in unrelated ways.  Our internal code review
> needs to be much better.

I think this shouldn't be as strict. Selecting e.g. between larger,
less performance intrusive changes over smaller changes with a
larger impact on performance should be done on a case by case
basis. (I'm still of the opinion that the original XSA-7 fix, which
now became c/s 25485:5b6a857411ba [minus the now pointless
adjustment to the hypercall path], would have been the better
one, despite it having required quite a bit of thinking to verify
that it is sufficient in that final form. The main problem here was
that no-one, including me, took the time early on to document all
the affected code paths for others to verify, and patch review
wasn't concise enough either.)

If in doubt, room should be provided to involve individuals not
on the security response team (of course requiring them to not
disclose the knowledge gained).

> We need to clarify that other issues discovered during the course of
> investigating a security disclosure will not be publicly discussed
> without first consulting the Xen.org security team, regardless of
> their actual relationship to the vulnerability at hand or expected
> security impact.  Otherwise there is a substantial risk that such
> changes will draw attention to embargoed problems.

I don't think this is strictly necessary, nor a problem. This has
become a problem in the recent process mainly due to the
extraordinary length of the embargo period.

> It may be that it would be a better idea to send out earlier
> advisories without patches to the predisclosure list, to enable those
> predisclosure list members who would like to do so to help with
> development and testing of the patches.  If so this needs to be
> catered for.

As said earlier, if a fix is available, it of course should be included.
But there shouldn't be any requirement for that.

> 14. Early consideration of which other organisations to bring in
> 
> Our process needs to have, very early on, an explicit step to of
> deciding which other projects/organisations may also be vulnerable and
> may therefore need to be part of the same disclosure process.  It also
> needs to make sure that we ask for any help (for example from
> upstreams or hardware vendors) as soon as possible.

Our security response team should only take our projects into
consideration. Cross project vulnerabilities should be managed
by entities set up to deal with this. (Not that I'm generally in
favor of copying bad behavior, but note how the problem in
XSA-7 was not brought to our or other OS vendors' attention
when dealt with years ago in Linux.)

Jan

> We also need to explicitly determine the availability of various key
> players over the disclosure timeline as an early step.  One of the
> difficulties we encountered was that one of the more important team
> members was unexpectedly out of their office at a critical point.
> 
> 
> 15. Process automation
> 
> Many of the advisory versions sent to the predisclosure list contained
> clerical errors.  Our processes for constructing these need to be
> made more automatic.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGan-0007qq-3D; Wed, 20 Jun 2012 08:48: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 1ShGak-0007qf-Te
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:48:47 +0000
Received: from [85.158.139.83:5205] by server-3.bemta-5.messagelabs.com id
	77/EE-03367-E6E81EF4; Wed, 20 Jun 2012 08:48:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340182125!24298610!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6179 invoked from network); 20 Jun 2012 08:48:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	20 Jun 2012 08:48:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 09:48:44 +0100
Message-Id: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 09:49:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
In-Reply-To: <20448.49637.38489.246434@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 20:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
Representing only personal (i.e. not necessarily my employer's)
opinions below.

> 1. Purpose of the process
> 
> The first point is that we think the security vulnerability process
> document should have an explanation of what its goals are.  This would
> have greatly assisted us when making some of the more difficult
> decisions.
> 
> In particular, if the process explained its purpose, we would be able
> to refer to the spirit of the document when making interpretation
> decisions or dealing with issues not clearly resolved by the document.
> 
> In this context we need to decide whether:
>  (a) the predisclosure arrangements are just there so that
>      organisations can backport patches, develop and test updated
>      versions, and so forth;
>  (b) the arrangements are also intended to allow operators to deploy
>      fixed versions.
> 
> Of course this needs to deal clearly with the common stituation of an
> organisation running Xen which is a direct consumer of Xen.org source
> code.

(a). Anything beyond may give (and apparently gave in the case
at hand) unfair advantages to certain downstreams over others.

> 2. Extension of embargo dates
> 
> The most controversial decision was whether the embargo date might be
> extended after it had originally been set.  We resisted these
> suggestions, referring to the process document, which does not
> contemplate extending the disclosure period.  However, when a
> predisclosure list member pressured the discoverer into requesting an
> extension, we felt the best interpretation of the process document
> required us to acquiesce.
> 
> Specifically, of course, we as a team would like clearer guidance from
> the process about whether, and if so under what circumstances, a
> predisclosure period should be extended.

I think this should be done via (perhaps silent) consensus on the
pre-discosure list. Leaving the embargo time line determination
entirely to the discoverer isn't really suitable. He might provide an
initial suggestion, but we ought to set a period of time (say, a
week or less) during which adjustment proposals can be made.

Extensions to the embargo period should be limited exclusively to
cases where problems addressing the problem in a timely manner
(including eventual later _necessary_ adjustments to the fixes)
arise.

> 3. Decisionmaking
> 
> It was suggested to us several times, and indeed seemed to be regarded
> by some as an underlying principle, that the predisclosure list
> members should be making the decisions about disclosure schedule etc.
> 
> The question of who is to make the decisions, and on what basis, needs
> to be addressed.

See above. Leaving this to the discretion of the discoverer is
neither open nor fair.

> 4. Length of (default) predisclosure period
> 
> Several members of the predisclosure list suggested that the
> predisclosure period was too short.  Others were ready within the
> predisclosure period's timeframe, and were disappointed to see it
> extended and to have to delay their fixes.

Setting a default period might be counter productive. There may
be cases (for example had we wanted to fix XSA-9 properly)
where developing a fix could take quite a bit of time. Not having
a fix ready shouldn't, however, prevent initial announcements of
a problem.

> 5. Criteria for predisclosure list membership
> 
> We had one request from a public Xen cloud provider to be provided
> with predisclosure information.  However it appeared to us that they
> didn't meet the size threshold in the process document.
> 
> The size threshold is of course open to discussion.
> 
> We need to clarify whether upstreams and hardware vendors should be on
> the predisclosure list.  Currently we have one notable upstream vendor
> on that list.
> 
> Our preliminary view is that the predisclosure list should be used for
> downstream notifications.  Upstreams, including hardware
> manufacturers, should be brought in to the disclosure process as
> needed.  And as noted, our process for making sure we do that properly
> needs to be formalised.
> 
> It is probably time for a review of the membership of the
> predisclosure list, in any case, after we have incorporated any
> changes to the criteria which are agreed as a result of this
> discussion.

I think having hardware vendors involved is really only necessary
when hardware related issues need to be dealt with.

As to downstreams, I think only direct ones should be involved in
any decision making processes. Indirect ones might be allowed on
the list, but exclusively as observers. Mis-use of the observer role
(e.g. as in influencing those participating in decision making in
undue ways), should it become known, should result in removal of
list membership.

> 6. Sharing of information and code between predisclosure participants
> 
> We need the process document to be clearer about what kinds of
> communications are contemplated _between_ members of the predisclosure
> list.
> 
> One particular issue here which also relates to the predisclosure
> membership criteria, is whether large indirect consumers of Xen should
> be on the predisclosure list in their own right.  That would allow
> them to deploy the fix before the embargo date.  It would also allow
> them to prepare for testing and deployment, before the fix is
> available from their vendor (who would in this scenario also be
> entitled to be a predisclosure list member).
> 
> In this context, the process needs to clarify whether vendors may
> release fixed binaries during the predisclosure period.  Certainly
> these should not be released other than to predisclosure list members,
> since the nature of a bug can often by discovered by reverse
> engineering.  But can they be released to predisclousre list members ?

As indicated above, this should not be permitted, due to
fairness considerations. Otherwise we should not place
restrictions on who might be on the list at least as an observer.

> 7. Public communications during the embargo period
> 
> We need to clarify what individual vendors are allowed to say during
> the embargo period.  It was brought to our attention that one public
> cloud provider told its users that their VMs would be migrated due to
> "a vendor issue" which would be revealed in "a few weeks".  Our view
> was that that was fine.
> 
> As a starting point, it seems to us that it is OK to disclose that
> there is an issue, including its XSA and CVE numbers and its planned
> disclosure date; but that it is not OK to disclose the impact, scope,
> set of vulnerable systems, and certainly not the nature of the
> vulnerability.
> 
> And we need to clarify what information the security team should give
> out when we get an enquiry from a community member about an embargoed
> problem.

Just the same we allow individual vendors to communicate -
acknowledge the fact that there is a vulnerability, identifiers, and
expected embargo deadline.

The alternative would be to not do and allow any communication,
which I think is not realistic to enforce.

> 8. Predisclosure subscription process, and email address criteria
> 
> We certainly need to clarify the subscription process to the list, to
> make it clear that the organisation's security team should request all
> subscriptions and that self-subscriptions via the mailing list
> interface will be rejected out of hand.  The current arrangements have
> caused quite a lot of admin work, to confirm various change requests.
> 
> The predisclosure list contains a number of individuals at various
> organisations.  One vendor seemed to get into difficulty because it
> had only one individual on the predisclosure list, which seems to have
> unfortunately kept their established team in the dark during the early
> stages of the process.  The process document requires that downstreams
> on the list have established security teams.  Should we require that
> such response teams' contact details be publicly advertised ?  Should
> we insist that only response teams' role addresses may be included on
> the list ?

Yes.

> 9. Vulnerability process scope
> 
> We need to clarify the scope of the process document.  Currently it
> looks like it covers every Xen.org project.
> 
> While it would be a nice ideal to support every Xen.org project this
> way, in practice the team behind security@xen do not have the
> expertise or resources to fix problems in (say) XCP, or the ARM PV
> port.  Our capability is concentrated on the "Upstream Xen" codebase
> (xen-*.hg and its sub-repositories) and the Xen support code in Linux.
> 
> Perhaps this could be dealt with by making it clear that problems are
> handled on a best effort basis.

Agreed.

> 10. Exploits
> 
> We need a clear policy about releasing proof of concept exploits -
> whether, when and who to.

This I think could (and perhaps should) be really be left to the
discoverer, as this may be considered intellectual property.

> 11. Transparency
> 
> We think the process document should explicitly state that any
> potentially controversial private decisions made by the Xen.org
> security response team should be disclosed after the vulnerability
> itself is disclosed.

While fine from a theoretical pov, this places extra work on the
security response team, and I'm therefore not sure it's worth it.

Perhaps, if anything, such information (when regarding details of
the implementation of a fix) could go into the commit message.

> 13. Patch development and review
> 
> The patch development process is too closed and not robust enough.
> 
> We need to be much clearer both about the need for security patches to
> fix things in the smallest, simplest and most reliable way, and not
> fix or "improve" matters in unrelated ways.  Our internal code review
> needs to be much better.

I think this shouldn't be as strict. Selecting e.g. between larger,
less performance intrusive changes over smaller changes with a
larger impact on performance should be done on a case by case
basis. (I'm still of the opinion that the original XSA-7 fix, which
now became c/s 25485:5b6a857411ba [minus the now pointless
adjustment to the hypercall path], would have been the better
one, despite it having required quite a bit of thinking to verify
that it is sufficient in that final form. The main problem here was
that no-one, including me, took the time early on to document all
the affected code paths for others to verify, and patch review
wasn't concise enough either.)

If in doubt, room should be provided to involve individuals not
on the security response team (of course requiring them to not
disclose the knowledge gained).

> We need to clarify that other issues discovered during the course of
> investigating a security disclosure will not be publicly discussed
> without first consulting the Xen.org security team, regardless of
> their actual relationship to the vulnerability at hand or expected
> security impact.  Otherwise there is a substantial risk that such
> changes will draw attention to embargoed problems.

I don't think this is strictly necessary, nor a problem. This has
become a problem in the recent process mainly due to the
extraordinary length of the embargo period.

> It may be that it would be a better idea to send out earlier
> advisories without patches to the predisclosure list, to enable those
> predisclosure list members who would like to do so to help with
> development and testing of the patches.  If so this needs to be
> catered for.

As said earlier, if a fix is available, it of course should be included.
But there shouldn't be any requirement for that.

> 14. Early consideration of which other organisations to bring in
> 
> Our process needs to have, very early on, an explicit step to of
> deciding which other projects/organisations may also be vulnerable and
> may therefore need to be part of the same disclosure process.  It also
> needs to make sure that we ask for any help (for example from
> upstreams or hardware vendors) as soon as possible.

Our security response team should only take our projects into
consideration. Cross project vulnerabilities should be managed
by entities set up to deal with this. (Not that I'm generally in
favor of copying bad behavior, but note how the problem in
XSA-7 was not brought to our or other OS vendors' attention
when dealt with years ago in Linux.)

Jan

> We also need to explicitly determine the availability of various key
> players over the disclosure timeline as an early step.  One of the
> difficulties we encountered was that one of the more important team
> members was unexpectedly out of their office at a critical point.
> 
> 
> 15. Process automation
> 
> Many of the advisory versions sent to the predisclosure list contained
> clerical errors.  Our processes for constructing these need to be
> made more automatic.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:49:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGbO-0007tP-MM; Wed, 20 Jun 2012 08:49:26 +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 1ShGbN-0007tF-8Q
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:49:25 +0000
Received: from [85.158.143.99:36084] by server-1.bemta-4.messagelabs.com id
	7C/60-24392-49E81EF4; Wed, 20 Jun 2012 08:49:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340182163!21825398!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31301 invoked from network); 20 Jun 2012 08:49:24 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 08:49:24 -0000
Received: by eaak12 with SMTP id k12so2584423eaa.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 01:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PPMr75gmmmfGfxQW9px1M14/ATo3dZXZPLmOpUrKEio=;
	b=B0xQ74Qd+T2OfLZKbo8saL9IvuIqcfvFavFMiclKHjgD3QjJYRF3IOzQVvuyp7JeHq
	B5HjD/dGyzEjh/4gWrN4LULMlOPGaw/UU9du6udhnxNpJRtI5mVQ8IMnfoYHhK2XTQeP
	wOh/opijgu7MfnHVoT3rilP8qaBfX5XCAj9B80x28UU19p62fX3XESA/JPWJuooyxQIt
	ci/Bmqqyn/TYSYKZm3gQv/pp5SttDrewqRut++W1s1t9SDf8J26W1glU4+gqLjED3T48
	oX/zcJpyKGIMPui30iuGAzklW6DOFks9blEchIp3mlgIRrblYpINd6v7aYQR6ORoKPy4
	wPQg==
Received: by 10.14.187.137 with SMTP id y9mr4891176eem.62.1340182163511;
	Wed, 20 Jun 2012 01:49:23 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id q53sm87375879eef.8.2012.06.20.01.49.22
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 01:49:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 09:49:17 +0100
From: Keir Fraser <keir@xen.org>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <CC074D1D.43310%keir@xen.org>
Thread-Topic: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
	and 4.1.3
Thread-Index: Ac1OwZNEu+hiQ6kfwk6uvNYq+6CWXA==
In-Reply-To: <alpine.GSO.2.00.1206200932380.4323@algedi.dur.ac.uk>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
 and 4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/06/2012 09:37, "M A Young" <m.a.young@durham.ac.uk> wrote:

> On Mon, 18 Jun 2012, Keir Fraser wrote:
> 
>> I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:
>> 
>> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
>> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)
> 
> Can I nominate xen-unstable revision 24511 for backporting please? It is
> needed to build 4.1 for gcc 4.7 - I haven't tried 4.0 .

Done and done.

> Michael Young



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:49:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08: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 1ShGbO-0007tP-MM; Wed, 20 Jun 2012 08:49:26 +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 1ShGbN-0007tF-8Q
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:49:25 +0000
Received: from [85.158.143.99:36084] by server-1.bemta-4.messagelabs.com id
	7C/60-24392-49E81EF4; Wed, 20 Jun 2012 08:49:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340182163!21825398!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31301 invoked from network); 20 Jun 2012 08:49:24 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 08:49:24 -0000
Received: by eaak12 with SMTP id k12so2584423eaa.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 01:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PPMr75gmmmfGfxQW9px1M14/ATo3dZXZPLmOpUrKEio=;
	b=B0xQ74Qd+T2OfLZKbo8saL9IvuIqcfvFavFMiclKHjgD3QjJYRF3IOzQVvuyp7JeHq
	B5HjD/dGyzEjh/4gWrN4LULMlOPGaw/UU9du6udhnxNpJRtI5mVQ8IMnfoYHhK2XTQeP
	wOh/opijgu7MfnHVoT3rilP8qaBfX5XCAj9B80x28UU19p62fX3XESA/JPWJuooyxQIt
	ci/Bmqqyn/TYSYKZm3gQv/pp5SttDrewqRut++W1s1t9SDf8J26W1glU4+gqLjED3T48
	oX/zcJpyKGIMPui30iuGAzklW6DOFks9blEchIp3mlgIRrblYpINd6v7aYQR6ORoKPy4
	wPQg==
Received: by 10.14.187.137 with SMTP id y9mr4891176eem.62.1340182163511;
	Wed, 20 Jun 2012 01:49:23 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id q53sm87375879eef.8.2012.06.20.01.49.22
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 01:49:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 09:49:17 +0100
From: Keir Fraser <keir@xen.org>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <CC074D1D.43310%keir@xen.org>
Thread-Topic: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
	and 4.1.3
Thread-Index: Ac1OwZNEu+hiQ6kfwk6uvNYq+6CWXA==
In-Reply-To: <alpine.GSO.2.00.1206200932380.4323@algedi.dur.ac.uk>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
 and 4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/06/2012 09:37, "M A Young" <m.a.young@durham.ac.uk> wrote:

> On Mon, 18 Jun 2012, Keir Fraser wrote:
> 
>> I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:
>> 
>> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
>> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)
> 
> Can I nominate xen-unstable revision 24511 for backporting please? It is
> needed to build 4.1 for gcc 4.7 - I haven't tried 4.0 .

Done and done.

> Michael Young



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 08:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08:51: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 1ShGdI-00082u-7z; Wed, 20 Jun 2012 08:51:24 +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 1ShGdG-00082C-MG
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:51:22 +0000
Received: from [85.158.143.99:49376] by server-2.bemta-4.messagelabs.com id
	12/EC-17938-A0F81EF4; Wed, 20 Jun 2012 08:51:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340182281!16628383!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22290 invoked from network); 20 Jun 2012 08:51:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 08:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="13117383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 08:51:17 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 09:51:17 +0100
Message-ID: <4FE18F05.8030309@citrix.com>
Date: Wed, 20 Jun 2012 09:51:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
In-Reply-To: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
>
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
>
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
>
> Signed-off-by: Matt Wilson<msw@amazon.com>

Thanks for the patch! The way FSIMAGE_FSDIR is set is really wrong.

> diff -r 32034d1914a6 -r 0a592e08ac31 config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -35,7 +35,6 @@ INCLUDEDIR = $(PREFIX)/include
>   LIBLEAFDIR = lib
>   LIBLEAFDIR_x86_32 = lib
>   LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>   LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>   LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> diff -r 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
> --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
>   INCLUDEDIR = $(PREFIX)/include
>   LIBLEAFDIR = lib
>   LIBLEAFDIR_x86_64 = lib/amd64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>   MANDIR = $(PREFIX)/share/man
>   MAN1DIR = $(MANDIR)/man1

Can we clean this a little bit more, and remove LIBDIR_x86_32,
LIBLEAFDIR_x86_64, LIBDIR_x86_64, LIBDIR_x86_32 and LIBLEAFDIR?

> diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,7 @@
>   # Prefix and install folder
>   PREFIX              := @prefix@
> +exec_prefix         := @exec_prefix@
> +LIBDIR              := @libdir@
>   LIBLEAFDIR_x86_64   := @LIB_PATH@
>
>   # A debug build of tools?
> diff -r 32034d1914a6 -r 0a592e08ac31 config/x86_64.mk
> --- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -11,7 +11,6 @@ CONFIG_IOEMU := y
>   CFLAGS += -m64
>
>   LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
> -LIBDIR = $(LIBDIR_x86_64)
>
>   SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
>
> diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/Rules.mk
> --- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,17 +1,12 @@
>   include $(XEN_ROOT)/tools/Rules.mk
>
> -CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
> +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"

I would prefer to set FSIMAGE_FSDIR or an equivalent define in 
tools/config.h and include that header in 
tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that 
value from the compiler command line.

>   CFLAGS += -Werror -D_GNU_SOURCE
>   LDFLAGS += -L../common/
>
>   PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
>
> -FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
> -FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
> -FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
> -FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
> -FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
> -FSDIR = $(FSDIR-y)
> +FSDIR = $(LIBDIR)/fs
>
>   FSLIB = fsimage.so
>
> @@ -20,8 +15,8 @@ fs-all: $(FSLIB)
>
>   .PHONY: fs-install
>   fs-install: fs-all
> -	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
> -	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
> +	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
> +	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
>
>   $(FSLIB): $(PIC_OBJS)
>   	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
> diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/Makefile
> --- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,5 @@
>   XEN_ROOT = $(CURDIR)/../../..
> -include $(XEN_ROOT)/tools/Rules.mk
> +include $(XEN_ROOT)/tools/libfsimage/Rules.mk
>
>   MAJOR = 1.0
>   MINOR = 0
> diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/fsimage_plugin.c
> --- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
> @@ -122,7 +122,6 @@ fail:
>   static int load_plugins(void)
>   {
>   	const char *fsdir = getenv("FSIMAGE_FSDIR");
> -	const char *isadir = "";
>   	struct dirent *dp = NULL;
>   	struct dirent *dpp;
>   	DIR *dir = NULL;
> @@ -131,27 +130,12 @@ static int load_plugins(void)
>   	int err;
>   	int ret = -1;
>
> -#if defined(FSIMAGE_FSDIR)
> +#if !defined(FSIMAGE_FSDIR)
> +#error FSIMAGE_FSDIR not defined
> +#else
>   	if (fsdir == NULL)
>   		fsdir = FSIMAGE_FSDIR;
> -#elif defined(__sun__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -
> -	if (sizeof(void *) == 8)
> -		isadir = "64/";
> -#elif defined(__ia64__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -#else
> -	if (fsdir == NULL) {
> -		if (sizeof(void *) == 8)
> -			fsdir = "/usr/lib64/fs";
> -		else
> -			fsdir = "/usr/lib/fs";
> -	}
>   #endif
> -
>   	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
>   		goto fail;
>
> @@ -172,8 +156,8 @@ static int load_plugins(void)
>   		if (strcmp(dpp->d_name, "..") == 0)
>   			continue;
>
> -		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
> -		    dpp->d_name, isadir);
> +		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
> +			dpp->d_name);
>
>   		if (init_plugin(tmp) != 0)
>   			goto fail;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 08:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 08:51: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 1ShGdI-00082u-7z; Wed, 20 Jun 2012 08:51:24 +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 1ShGdG-00082C-MG
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 08:51:22 +0000
Received: from [85.158.143.99:49376] by server-2.bemta-4.messagelabs.com id
	12/EC-17938-A0F81EF4; Wed, 20 Jun 2012 08:51:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340182281!16628383!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22290 invoked from network); 20 Jun 2012 08:51:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 08:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,440,1336348800"; d="scan'208";a="13117383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 08:51:17 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 09:51:17 +0100
Message-ID: <4FE18F05.8030309@citrix.com>
Date: Wed, 20 Jun 2012 09:51:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
In-Reply-To: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
>
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
>
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
>
> Signed-off-by: Matt Wilson<msw@amazon.com>

Thanks for the patch! The way FSIMAGE_FSDIR is set is really wrong.

> diff -r 32034d1914a6 -r 0a592e08ac31 config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -35,7 +35,6 @@ INCLUDEDIR = $(PREFIX)/include
>   LIBLEAFDIR = lib
>   LIBLEAFDIR_x86_32 = lib
>   LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>   LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>   LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> diff -r 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
> --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
>   INCLUDEDIR = $(PREFIX)/include
>   LIBLEAFDIR = lib
>   LIBLEAFDIR_x86_64 = lib/amd64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>   MANDIR = $(PREFIX)/share/man
>   MAN1DIR = $(MANDIR)/man1

Can we clean this a little bit more, and remove LIBDIR_x86_32,
LIBLEAFDIR_x86_64, LIBDIR_x86_64, LIBDIR_x86_32 and LIBLEAFDIR?

> diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,7 @@
>   # Prefix and install folder
>   PREFIX              := @prefix@
> +exec_prefix         := @exec_prefix@
> +LIBDIR              := @libdir@
>   LIBLEAFDIR_x86_64   := @LIB_PATH@
>
>   # A debug build of tools?
> diff -r 32034d1914a6 -r 0a592e08ac31 config/x86_64.mk
> --- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -11,7 +11,6 @@ CONFIG_IOEMU := y
>   CFLAGS += -m64
>
>   LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
> -LIBDIR = $(LIBDIR_x86_64)
>
>   SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
>
> diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/Rules.mk
> --- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,17 +1,12 @@
>   include $(XEN_ROOT)/tools/Rules.mk
>
> -CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
> +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"

I would prefer to set FSIMAGE_FSDIR or an equivalent define in 
tools/config.h and include that header in 
tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that 
value from the compiler command line.

>   CFLAGS += -Werror -D_GNU_SOURCE
>   LDFLAGS += -L../common/
>
>   PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
>
> -FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
> -FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
> -FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
> -FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
> -FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
> -FSDIR = $(FSDIR-y)
> +FSDIR = $(LIBDIR)/fs
>
>   FSLIB = fsimage.so
>
> @@ -20,8 +15,8 @@ fs-all: $(FSLIB)
>
>   .PHONY: fs-install
>   fs-install: fs-all
> -	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
> -	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
> +	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
> +	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
>
>   $(FSLIB): $(PIC_OBJS)
>   	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
> diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/Makefile
> --- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,5 @@
>   XEN_ROOT = $(CURDIR)/../../..
> -include $(XEN_ROOT)/tools/Rules.mk
> +include $(XEN_ROOT)/tools/libfsimage/Rules.mk
>
>   MAJOR = 1.0
>   MINOR = 0
> diff -r 32034d1914a6 -r 0a592e08ac31 tools/libfsimage/common/fsimage_plugin.c
> --- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
> @@ -122,7 +122,6 @@ fail:
>   static int load_plugins(void)
>   {
>   	const char *fsdir = getenv("FSIMAGE_FSDIR");
> -	const char *isadir = "";
>   	struct dirent *dp = NULL;
>   	struct dirent *dpp;
>   	DIR *dir = NULL;
> @@ -131,27 +130,12 @@ static int load_plugins(void)
>   	int err;
>   	int ret = -1;
>
> -#if defined(FSIMAGE_FSDIR)
> +#if !defined(FSIMAGE_FSDIR)
> +#error FSIMAGE_FSDIR not defined
> +#else
>   	if (fsdir == NULL)
>   		fsdir = FSIMAGE_FSDIR;
> -#elif defined(__sun__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -
> -	if (sizeof(void *) == 8)
> -		isadir = "64/";
> -#elif defined(__ia64__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -#else
> -	if (fsdir == NULL) {
> -		if (sizeof(void *) == 8)
> -			fsdir = "/usr/lib64/fs";
> -		else
> -			fsdir = "/usr/lib/fs";
> -	}
>   #endif
> -
>   	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
>   		goto fail;
>
> @@ -172,8 +156,8 @@ static int load_plugins(void)
>   		if (strcmp(dpp->d_name, "..") == 0)
>   			continue;
>
> -		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
> -		    dpp->d_name, isadir);
> +		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
> +			dpp->d_name);
>
>   		if (init_plugin(tmp) != 0)
>   			goto fail;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 09:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 09: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 1ShGs5-0008Rp-0W; Wed, 20 Jun 2012 09: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 1ShGs3-0008Rk-4F
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 09:06:39 +0000
Received: from [193.109.254.147:37463] by server-10.bemta-14.messagelabs.com
	id 21/96-05433-E9291EF4; Wed, 20 Jun 2012 09:06:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340183195!4989180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30203 invoked from network); 20 Jun 2012 09:06:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:06:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13117872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:06:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 10:06:10 +0100
Message-ID: <1340183168.4906.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 10:06:08 +0100
In-Reply-To: <4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <raistlin@linux.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 08:51 +0100, Jan Beulich wrote:
> >>> On 20.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-amd64-xl-win7-amd64
> > test windows-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/staging/xen-unstable.hg
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  9d1fd58ff602
> >   Bug not present: 32034d1914a6
> >
> >
> >   changeset:   25468:9d1fd58ff602
> >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> >   date:        Fri Jun 08 15:26:01 2012 +0100
> >
> >       xl: check for meaningful combination of sedf config file parameters
> 
> Dario,
> 
> these bisection results have been posted for a couple of days,
> yet so far I don't recall having seen any sign from you as to what
> you're plans are. Given that this has now been holding up a push
> for over 10 days, I think I'll have to request reverting the change
> otherwise.

It's not been as long as ten days, the commit was the 14th. But yes we
need to know what is going on here ASAP -- Dario please can you take a
look.

It's an odd one -- the logs seem to show the guest has started but the
patch in question would (or should!) cause an early error return during
build. It's possible that the recent test system outage has caused the
bisector to get confused but it has fingered this changeset at least
twice now.

The bisector really should try and pull out S-o-b's et al from the
offending commit and add appropriate CCs. There's also something of an
expectation that developers will keep an eye on the test system results
after a patch of theirs has been expected though.

Ian.

> 
> Jan
> 
> >       As it happens in the implementation of `xl sched-sedf -d ...', some
> >       consistency checking is needed for the scheduling parameters when
> >       they come from the config file.
> >
> >       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >
> >
> >
> >
> > For bisection revision-tuple graph see:
> >
> > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-
> > amd64-amd64-xl-win7-amd64.windows-install.html
> > Revision IDs in each graph node refer, respectively, to the Trees above.
> >
> > ----------------------------------------
> > Searching for failure / basis pass:
> >  13088 fail [host=leaf-beetle] / 13025 ok.
> > Failure / basis pass flights: 13088 / 13025
> > 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/staging/xen-unstable.hg
> > Latest a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> > Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> > Generating revisions with ./adhoc-revtuple-generator
> > git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-
> > a938a246d34912423c560f475ccf1ce0c71d9d00
> > git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0
> > aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff
> > git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03
> > 843603030d2b1aee86-f7f8c33cd49885d69efc2e5f7f9a613d631762e2
> > http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-5b6a857411ba
> > 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-upstream-unstable.git
> > /export/home/osstest/repos/qemu-upstream-unstable...
> > Initialized empty Git repository in
> > /export/home/osstest/repos/qemu-upstream-unstable/
> > updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> > 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-upstream-unstable.git
> > /export/home/osstest/repos/qemu-upstream-unstable...
> > Initialized empty Git repository in
> > /export/home/osstest/repos/qemu-upstream-unstable/
> > updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> > Loaded 1021 nodes in revision graph
> > Searching for test results:
> >  13019 pass irrelevant
> >  12958 pass irrelevant
> >  13004 pass irrelevant
> >  13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
> >  12981 pass irrelevant
> >  12960 pass irrelevant
> >  12964 pass irrelevant
> >  13038 []
> >  12967 pass irrelevant
> >  12968 pass irrelevant
> >  12969 pass irrelevant
> >  12971 pass irrelevant
> >  12972 pass irrelevant
> >  12975 pass irrelevant
> >  12976 pass irrelevant
> >  12977 pass irrelevant
> >  12988 pass irrelevant
> >  12978 pass irrelevant
> >  13020 pass irrelevant
> >  12979 pass irrelevant
> >  12995 pass irrelevant
> >  12980 pass irrelevant
> >  12996 pass irrelevant
> >  13006 pass irrelevant
> >  12997 pass irrelevant
> >  12998 pass irrelevant
> >  13023 pass irrelevant
> >  13012 pass irrelevant
> >  13051 fail irrelevant
> >  12999 pass irrelevant
> >  13013 pass irrelevant
> >  13002 pass irrelevant
> >  13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13003 pass irrelevant
> >  13014 pass irrelevant
> >  13045 []
> >  13015 pass irrelevant
> >  13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13016 pass irrelevant
> >  13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
> >  13018 pass irrelevant
> >  13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
> >  13046 []
> >  13037 []
> >  13053 fail irrelevant
> >  13061 fail irrelevant
> >  13069 fail irrelevant
> >  13099 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> >  13102 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
> >  13103 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13075 fail irrelevant
> >  13105 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
> >  13080 fail irrelevant
> >  13087 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13092 fail irrelevant
> >  13093 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
> >  13094 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
> >  13095 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
> >  13088 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> >  13096 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> > Searching for interesting versions
> >  Result found: flight 13024 (pass), for basis pass
> >  Result found: flight 13088 (fail), for basis failure
> >  Repro found: flight 13096 (pass), for basis pass
> >  Repro found: flight 13099 (fail), for basis failure
> >  0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> > No revisions left to test, checking graph state.
> >  Result found: flight 13024 (pass), for last pass
> >  Result found: flight 13095 (fail), for first failure
> >  Repro found: flight 13096 (pass), for last pass
> >  Repro found: flight 13102 (fail), for first failure
> >  Repro found: flight 13103 (pass), for last pass
> >  Repro found: flight 13105 (fail), for first failure
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  9d1fd58ff602
> >   Bug not present: 32034d1914a6
> >
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> >
> >   changeset:   25468:9d1fd58ff602
> >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> >   date:        Fri Jun 08 15:26:01 2012 +0100
> >
> >       xl: check for meaningful combination of sedf config file parameters
> >
> >       As it happens in the implementation of `xl sched-sedf -d ...', some
> >       consistency checking is needed for the scheduling parameters when
> >       they come from the config file.
> >
> >       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >
> >
> >
> > Revision graph left in
> > /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.w
> > indows-install.{dot,ps,png,html}.
> > ----------------------------------------
> > 13105: tolerable ALL FAIL
> >
> > flight 13105 xen-unstable real-bisect [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13105/
> >
> > Failures :-/ but no regressions.
> >
> > Tests which did not succeed,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
> >
> >
> > jobs:
> >  test-amd64-amd64-xl-win7-amd64                               fail
> >
> >
> > ------------------------------------------------------------
> > sg-report-flight on woking.cam.xci-test.com
> > logs: /home/xc_osstest/logs
> > images: /home/xc_osstest/images
> >
> > Logs, config files, etc. are available at
> >     http://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
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 09:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 09: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 1ShGs5-0008Rp-0W; Wed, 20 Jun 2012 09: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 1ShGs3-0008Rk-4F
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 09:06:39 +0000
Received: from [193.109.254.147:37463] by server-10.bemta-14.messagelabs.com
	id 21/96-05433-E9291EF4; Wed, 20 Jun 2012 09:06:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340183195!4989180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30203 invoked from network); 20 Jun 2012 09:06:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:06:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13117872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:06:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 10:06:10 +0100
Message-ID: <1340183168.4906.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 10:06:08 +0100
In-Reply-To: <4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <raistlin@linux.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 08:51 +0100, Jan Beulich wrote:
> >>> On 20.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-amd64-xl-win7-amd64
> > test windows-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/staging/xen-unstable.hg
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  9d1fd58ff602
> >   Bug not present: 32034d1914a6
> >
> >
> >   changeset:   25468:9d1fd58ff602
> >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> >   date:        Fri Jun 08 15:26:01 2012 +0100
> >
> >       xl: check for meaningful combination of sedf config file parameters
> 
> Dario,
> 
> these bisection results have been posted for a couple of days,
> yet so far I don't recall having seen any sign from you as to what
> you're plans are. Given that this has now been holding up a push
> for over 10 days, I think I'll have to request reverting the change
> otherwise.

It's not been as long as ten days, the commit was the 14th. But yes we
need to know what is going on here ASAP -- Dario please can you take a
look.

It's an odd one -- the logs seem to show the guest has started but the
patch in question would (or should!) cause an early error return during
build. It's possible that the recent test system outage has caused the
bisector to get confused but it has fingered this changeset at least
twice now.

The bisector really should try and pull out S-o-b's et al from the
offending commit and add appropriate CCs. There's also something of an
expectation that developers will keep an eye on the test system results
after a patch of theirs has been expected though.

Ian.

> 
> Jan
> 
> >       As it happens in the implementation of `xl sched-sedf -d ...', some
> >       consistency checking is needed for the scheduling parameters when
> >       they come from the config file.
> >
> >       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >
> >
> >
> >
> > For bisection revision-tuple graph see:
> >
> > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-
> > amd64-amd64-xl-win7-amd64.windows-install.html
> > Revision IDs in each graph node refer, respectively, to the Trees above.
> >
> > ----------------------------------------
> > Searching for failure / basis pass:
> >  13088 fail [host=leaf-beetle] / 13025 ok.
> > Failure / basis pass flights: 13088 / 13025
> > 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/staging/xen-unstable.hg
> > Latest a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> > Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> > Generating revisions with ./adhoc-revtuple-generator
> > git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-
> > a938a246d34912423c560f475ccf1ce0c71d9d00
> > git://xenbits.xen.org/staging/qemu-xen-unstable.git#50c553be472c9f4b05a0526c0
> > aae98709ca9ffff-50c553be472c9f4b05a0526c0aae98709ca9ffff
> > git://xenbits.xen.org/staging/qemu-upstream-unstable.git#6d8b472233779c2a028a03
> > 843603030d2b1aee86-f7f8c33cd49885d69efc2e5f7f9a613d631762e2
> > http://xenbits.xen.org/staging/xen-unstable.hg#32034d1914a6-5b6a857411ba
> > 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-upstream-unstable.git
> > /export/home/osstest/repos/qemu-upstream-unstable...
> > Initialized empty Git repository in
> > /export/home/osstest/repos/qemu-upstream-unstable/
> > updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> > 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-upstream-unstable.git
> > /export/home/osstest/repos/qemu-upstream-unstable...
> > Initialized empty Git repository in
> > /export/home/osstest/repos/qemu-upstream-unstable/
> > updating cache /export/home/osstest/repos/git-cache qemu-upstream-unstable...
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> > Loaded 1021 nodes in revision graph
> > Searching for test results:
> >  13019 pass irrelevant
> >  12958 pass irrelevant
> >  13004 pass irrelevant
> >  13027 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
> >  12981 pass irrelevant
> >  12960 pass irrelevant
> >  12964 pass irrelevant
> >  13038 []
> >  12967 pass irrelevant
> >  12968 pass irrelevant
> >  12969 pass irrelevant
> >  12971 pass irrelevant
> >  12972 pass irrelevant
> >  12975 pass irrelevant
> >  12976 pass irrelevant
> >  12977 pass irrelevant
> >  12988 pass irrelevant
> >  12978 pass irrelevant
> >  13020 pass irrelevant
> >  12979 pass irrelevant
> >  12995 pass irrelevant
> >  12980 pass irrelevant
> >  12996 pass irrelevant
> >  13006 pass irrelevant
> >  12997 pass irrelevant
> >  12998 pass irrelevant
> >  13023 pass irrelevant
> >  13012 pass irrelevant
> >  13051 fail irrelevant
> >  12999 pass irrelevant
> >  13013 pass irrelevant
> >  13002 pass irrelevant
> >  13024 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13003 pass irrelevant
> >  13014 pass irrelevant
> >  13045 []
> >  13015 pass irrelevant
> >  13025 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13016 pass irrelevant
> >  13026 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
> >  13018 pass irrelevant
> >  13032 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 a70b35deb2b5
> >  13046 []
> >  13037 []
> >  13053 fail irrelevant
> >  13061 fail irrelevant
> >  13069 fail irrelevant
> >  13099 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> >  13102 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
> >  13103 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13075 fail irrelevant
> >  13105 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
> >  13080 fail irrelevant
> >  13087 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> >  13092 fail irrelevant
> >  13093 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 5b61b5779fca
> >  13094 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 4d40d7a4c6f1
> >  13095 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 9d1fd58ff602
> >  13088 fail a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > f7f8c33cd49885d69efc2e5f7f9a613d631762e2 5b6a857411ba
> >  13096 pass a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> > Searching for interesting versions
> >  Result found: flight 13024 (pass), for basis pass
> >  Result found: flight 13088 (fail), for basis failure
> >  Repro found: flight 13096 (pass), for basis pass
> >  Repro found: flight 13099 (fail), for basis failure
> >  0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00
> > 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > 6d8b472233779c2a028a03843603030d2b1aee86 32034d1914a6
> > No revisions left to test, checking graph state.
> >  Result found: flight 13024 (pass), for last pass
> >  Result found: flight 13095 (fail), for first failure
> >  Repro found: flight 13096 (pass), for last pass
> >  Repro found: flight 13102 (fail), for first failure
> >  Repro found: flight 13103 (pass), for last pass
> >  Repro found: flight 13105 (fail), for first failure
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  9d1fd58ff602
> >   Bug not present: 32034d1914a6
> >
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> >
> >   changeset:   25468:9d1fd58ff602
> >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> >   date:        Fri Jun 08 15:26:01 2012 +0100
> >
> >       xl: check for meaningful combination of sedf config file parameters
> >
> >       As it happens in the implementation of `xl sched-sedf -d ...', some
> >       consistency checking is needed for the scheduling parameters when
> >       they come from the config file.
> >
> >       Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >       Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >       Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> >
> >
> >
> > Revision graph left in
> > /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.w
> > indows-install.{dot,ps,png,html}.
> > ----------------------------------------
> > 13105: tolerable ALL FAIL
> >
> > flight 13105 xen-unstable real-bisect [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13105/
> >
> > Failures :-/ but no regressions.
> >
> > Tests which did not succeed,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
> >
> >
> > jobs:
> >  test-amd64-amd64-xl-win7-amd64                               fail
> >
> >
> > ------------------------------------------------------------
> > sg-report-flight on woking.cam.xci-test.com
> > logs: /home/xc_osstest/logs
> > images: /home/xc_osstest/images
> >
> > Logs, config files, etc. are available at
> >     http://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
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 09:11:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 09:11: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 1ShGwb-00009v-NS; Wed, 20 Jun 2012 09:11: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 1ShGwa-00009q-9S
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 09:11:20 +0000
Received: from [85.158.139.83:11543] by server-9.bemta-5.messagelabs.com id
	EB/26-01069-7B391EF4; Wed, 20 Jun 2012 09:11:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340183478!28560290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15291 invoked from network); 20 Jun 2012 09:11:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13118011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:10:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 10:10:36 +0100
Message-ID: <1340183435.4906.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 20 Jun 2012 10:10:35 +0100
In-Reply-To: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 01:46 +0100, Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Thanks for doing this.

> diff -r 32034d1914a6 -r 0a592e08ac31 config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -35,7 +35,6 @@ INCLUDEDIR = $(PREFIX)/include
>  LIBLEAFDIR = lib
>  LIBLEAFDIR_x86_32 = lib
>  LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
>  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)

Roger already asked if we can somehow get rid of all the LEAFDIR stuff
too.

> diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,7 @@
>  # Prefix and install folder
>  PREFIX              := @prefix@
> +exec_prefix         := @exec_prefix@

Is exec_prefix related to this change?

> +LIBDIR              := @libdir@
>  LIBLEAFDIR_x86_64   := @LIB_PATH@
>  
>  # A debug build of tools?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 09:11:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 09:11: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 1ShGwb-00009v-NS; Wed, 20 Jun 2012 09:11: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 1ShGwa-00009q-9S
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 09:11:20 +0000
Received: from [85.158.139.83:11543] by server-9.bemta-5.messagelabs.com id
	EB/26-01069-7B391EF4; Wed, 20 Jun 2012 09:11:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340183478!28560290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15291 invoked from network); 20 Jun 2012 09:11:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13118011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:10:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 10:10:36 +0100
Message-ID: <1340183435.4906.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 20 Jun 2012 10:10:35 +0100
In-Reply-To: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 01:46 +0100, Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Thanks for doing this.

> diff -r 32034d1914a6 -r 0a592e08ac31 config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -35,7 +35,6 @@ INCLUDEDIR = $(PREFIX)/include
>  LIBLEAFDIR = lib
>  LIBLEAFDIR_x86_32 = lib
>  LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
>  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)

Roger already asked if we can somehow get rid of all the LEAFDIR stuff
too.

> diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,7 @@
>  # Prefix and install folder
>  PREFIX              := @prefix@
> +exec_prefix         := @exec_prefix@

Is exec_prefix related to this change?

> +LIBDIR              := @libdir@
>  LIBLEAFDIR_x86_64   := @LIB_PATH@
>  
>  # A debug build of tools?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 09:45:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 09: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 1ShHTd-0000W4-Qx; Wed, 20 Jun 2012 09:45:29 +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 1ShHTc-0000Vz-4s
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 09:45:28 +0000
Received: from [85.158.143.35:18350] by server-1.bemta-4.messagelabs.com id
	1E/82-24392-7BB91EF4; Wed, 20 Jun 2012 09:45:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340185520!15943710!1
X-Originating-IP: [209.85.216.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30275 invoked from network); 20 Jun 2012 09:45:23 -0000
Received: from mail-qa0-f49.google.com (HELO mail-qa0-f49.google.com)
	(209.85.216.49)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:45:23 -0000
Received: by qabj40 with SMTP id j40so186825qab.15
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 02:45:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=OOne4CFAVO26R/YUyEfCHPJrxtpHUIk5kIw0kJlkjJ0=;
	b=SAEVjfcMtDYhjrP3cM23GpIzXphbrNZGXggeuUw3UFtOaAK7POzfGghExol1mCZhI3
	CHsRrURcqFXdr35sHzmJ0QR+JRZcCXf+3wXXZ/R7Z3AkIbyubx9pe/e/wSDDJ6EGjAx+
	/6hs2u+wW69DTaq7EZKkSOpNzo5Xta6Q5vIMxpWuSkbL+Q19mW7on6u2fVKGhbMcqtpG
	lSHPynOFXOc1tEAveGKTocCiAkcQDzGijdbQtojch645DkfXopFUDTak2505Nk+u2fuG
	quCVZC8wbnzWXcK7DZHCvM72Wgsk/Jy6P1n+exV8FLDK45fqIOhaCprGNx6RxTrJgj5u
	39Lg==
MIME-Version: 1.0
Received: by 10.229.69.30 with SMTP id x30mr11818002qci.13.1340185520135; Wed,
	20 Jun 2012 02:45:20 -0700 (PDT)
Received: by 10.229.213.211 with HTTP; Wed, 20 Jun 2012 02:45:20 -0700 (PDT)
In-Reply-To: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
Date: Wed, 20 Jun 2012 10:45:20 +0100
X-Google-Sender-Auth: nVqAySxBf20aKtGppa8--dupccA
Message-ID: <CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> The most controversial decision was whether the embargo date might be
>> extended after it had originally been set. =A0We resisted these
>> suggestions, referring to the process document, which does not
>> contemplate extending the disclosure period. =A0However, when a
>> predisclosure list member pressured the discoverer into requesting an
>> extension, we felt the best interpretation of the process document
>> required us to acquiesce.
>>
>> Specifically, of course, we as a team would like clearer guidance from
>> the process about whether, and if so under what circumstances, a
>> predisclosure period should be extended.
>
> I think this should be done via (perhaps silent) consensus on the
> pre-discosure list. Leaving the embargo time line determination
> entirely to the discoverer isn't really suitable. He might provide an
> initial suggestion, but we ought to set a period of time (say, a
> week or less) during which adjustment proposals can be made.

The problem with this is that extending the embargo helps providers
who are on the predisclosure list (a minority), but hurts those not on
the list (the vast majority).  So there's a moral hazard with what you
suggest: it is just way too easy for the people on the list to vote to
make their own lives easier, not considering the plight of those who
are not big enough or connected enough to be on the list.  Doing so
also favors large players and incumbents against small players; doing
so may well be considered anti-competitive and illegal in many
jurisdictions.

The only way this would work is if the predisclosure list consisted
exclusively of software providers, and specifically excluded service
providers.  It should be possible to include all software providers on
the list, since it's a relatively small number of entities.
Furthermore, since software providers presumably care about the
security of their customers, it would provide the incentive to make
the embargo as short as is reasonable.

>> 3. Decisionmaking
>>
>> It was suggested to us several times, and indeed seemed to be regarded
>> by some as an underlying principle, that the predisclosure list
>> members should be making the decisions about disclosure schedule etc.
>>
>> The question of who is to make the decisions, and on what basis, needs
>> to be addressed.
>
> See above. Leaving this to the discretion of the discoverer is
> neither open nor fair.

But there's a practical matter to consider here: if it's known that we
won't cooperate with the discoverer wrt disclosure times, discoverers
may simply not share their information with us.  I think that's the
main reason for the "do what the discoverer wants" rule.  I think
there needs to be some kind of a balance though: extending the embargo
less than 12 hours before the deadline is clearly not reasonable.

>> Several members of the predisclosure list suggested that the
>> predisclosure period was too short. =A0Others were ready within the
>> predisclosure period's timeframe, and were disappointed to see it
>> extended and to have to delay their fixes.
>
> Setting a default period might be counter productive. There may
> be cases (for example had we wanted to fix XSA-9 properly)
> where developing a fix could take quite a bit of time. Not having
> a fix ready shouldn't, however, prevent initial announcements of
> a problem.

A default period can be considered a guideline.  In the case of a
particularly tricky fix, saying, "Normally we would set 2 weeks, but I
think in this case we should go for 3 or 4" is perfectly reasonable.

Since the embargo is really for software providers to test fixes,
perhaps we should suggest it should be "X business days after a fix is
released", rather than "X days after the vulnerability is disclosed"?

> As to downstreams, I think only direct ones should be involved in
> any decision making processes. Indirect ones might be allowed on
> the list, but exclusively as observers. Mis-use of the observer role
> (e.g. as in influencing those participating in decision making in
> undue ways), should it become known, should result in removal of
> list membership.

What do you mean by "direct" and "indirect"?  If by "direct" you mean,
"sell/distribute software", and "indirect" you mean, "use the software
to provide a service", I think we're probably in agreement. :-)

-George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 09:45:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 09: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 1ShHTd-0000W4-Qx; Wed, 20 Jun 2012 09:45:29 +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 1ShHTc-0000Vz-4s
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 09:45:28 +0000
Received: from [85.158.143.35:18350] by server-1.bemta-4.messagelabs.com id
	1E/82-24392-7BB91EF4; Wed, 20 Jun 2012 09:45:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340185520!15943710!1
X-Originating-IP: [209.85.216.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30275 invoked from network); 20 Jun 2012 09:45:23 -0000
Received: from mail-qa0-f49.google.com (HELO mail-qa0-f49.google.com)
	(209.85.216.49)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:45:23 -0000
Received: by qabj40 with SMTP id j40so186825qab.15
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 02:45:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=OOne4CFAVO26R/YUyEfCHPJrxtpHUIk5kIw0kJlkjJ0=;
	b=SAEVjfcMtDYhjrP3cM23GpIzXphbrNZGXggeuUw3UFtOaAK7POzfGghExol1mCZhI3
	CHsRrURcqFXdr35sHzmJ0QR+JRZcCXf+3wXXZ/R7Z3AkIbyubx9pe/e/wSDDJ6EGjAx+
	/6hs2u+wW69DTaq7EZKkSOpNzo5Xta6Q5vIMxpWuSkbL+Q19mW7on6u2fVKGhbMcqtpG
	lSHPynOFXOc1tEAveGKTocCiAkcQDzGijdbQtojch645DkfXopFUDTak2505Nk+u2fuG
	quCVZC8wbnzWXcK7DZHCvM72Wgsk/Jy6P1n+exV8FLDK45fqIOhaCprGNx6RxTrJgj5u
	39Lg==
MIME-Version: 1.0
Received: by 10.229.69.30 with SMTP id x30mr11818002qci.13.1340185520135; Wed,
	20 Jun 2012 02:45:20 -0700 (PDT)
Received: by 10.229.213.211 with HTTP; Wed, 20 Jun 2012 02:45:20 -0700 (PDT)
In-Reply-To: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
Date: Wed, 20 Jun 2012 10:45:20 +0100
X-Google-Sender-Auth: nVqAySxBf20aKtGppa8--dupccA
Message-ID: <CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> The most controversial decision was whether the embargo date might be
>> extended after it had originally been set. =A0We resisted these
>> suggestions, referring to the process document, which does not
>> contemplate extending the disclosure period. =A0However, when a
>> predisclosure list member pressured the discoverer into requesting an
>> extension, we felt the best interpretation of the process document
>> required us to acquiesce.
>>
>> Specifically, of course, we as a team would like clearer guidance from
>> the process about whether, and if so under what circumstances, a
>> predisclosure period should be extended.
>
> I think this should be done via (perhaps silent) consensus on the
> pre-discosure list. Leaving the embargo time line determination
> entirely to the discoverer isn't really suitable. He might provide an
> initial suggestion, but we ought to set a period of time (say, a
> week or less) during which adjustment proposals can be made.

The problem with this is that extending the embargo helps providers
who are on the predisclosure list (a minority), but hurts those not on
the list (the vast majority).  So there's a moral hazard with what you
suggest: it is just way too easy for the people on the list to vote to
make their own lives easier, not considering the plight of those who
are not big enough or connected enough to be on the list.  Doing so
also favors large players and incumbents against small players; doing
so may well be considered anti-competitive and illegal in many
jurisdictions.

The only way this would work is if the predisclosure list consisted
exclusively of software providers, and specifically excluded service
providers.  It should be possible to include all software providers on
the list, since it's a relatively small number of entities.
Furthermore, since software providers presumably care about the
security of their customers, it would provide the incentive to make
the embargo as short as is reasonable.

>> 3. Decisionmaking
>>
>> It was suggested to us several times, and indeed seemed to be regarded
>> by some as an underlying principle, that the predisclosure list
>> members should be making the decisions about disclosure schedule etc.
>>
>> The question of who is to make the decisions, and on what basis, needs
>> to be addressed.
>
> See above. Leaving this to the discretion of the discoverer is
> neither open nor fair.

But there's a practical matter to consider here: if it's known that we
won't cooperate with the discoverer wrt disclosure times, discoverers
may simply not share their information with us.  I think that's the
main reason for the "do what the discoverer wants" rule.  I think
there needs to be some kind of a balance though: extending the embargo
less than 12 hours before the deadline is clearly not reasonable.

>> Several members of the predisclosure list suggested that the
>> predisclosure period was too short. =A0Others were ready within the
>> predisclosure period's timeframe, and were disappointed to see it
>> extended and to have to delay their fixes.
>
> Setting a default period might be counter productive. There may
> be cases (for example had we wanted to fix XSA-9 properly)
> where developing a fix could take quite a bit of time. Not having
> a fix ready shouldn't, however, prevent initial announcements of
> a problem.

A default period can be considered a guideline.  In the case of a
particularly tricky fix, saying, "Normally we would set 2 weeks, but I
think in this case we should go for 3 or 4" is perfectly reasonable.

Since the embargo is really for software providers to test fixes,
perhaps we should suggest it should be "X business days after a fix is
released", rather than "X days after the vulnerability is disclosed"?

> As to downstreams, I think only direct ones should be involved in
> any decision making processes. Indirect ones might be allowed on
> the list, but exclusively as observers. Mis-use of the observer role
> (e.g. as in influencing those participating in decision making in
> undue ways), should it become known, should result in removal of
> list membership.

What do you mean by "direct" and "indirect"?  If by "direct" you mean,
"sell/distribute software", and "indirect" you mean, "use the software
to provide a service", I think we're probably in agreement. :-)

-George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 10:00:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 10: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 1ShHhg-0000iU-7y; Wed, 20 Jun 2012 10:00: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 1ShHhf-0000iP-9J
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 09:59:59 +0000
Received: from [85.158.139.83:50239] by server-5.bemta-5.messagelabs.com id
	1E/F4-02722-E1F91EF4; Wed, 20 Jun 2012 09:59:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340186397!24315723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6350 invoked from network); 20 Jun 2012 09:59:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13119401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:59:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 10:59:57 +0100
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 1ShHhd-0003KC-05;
	Wed, 20 Jun 2012 09:59:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShHhc-0005FF-R9;
	Wed, 20 Jun 2012 10:59:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13100-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 10:59:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13100: 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 13100 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13100/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13048
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13048

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9
baseline version:
 linux                26a7895e70104811258cf023d06a21f92ab590c6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=839cf7a236278ae358ff12141a168c0982fa0cd9
+ . 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 839cf7a236278ae358ff12141a168c0982fa0cd9
+ branch=linux-3.0
+ revision=839cf7a236278ae358ff12141a168c0982fa0cd9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 839cf7a236278ae358ff12141a168c0982fa0cd9:tested/linux-3.0
Counting objects: 1   
Counting objects: 13   
Counting objects: 173, done.
Compressing objects:   4% (1/22)   
Compressing objects:   9% (2/22)   
Compressing objects:  13% (3/22)   
Compressing objects:  18% (4/22)   
Compressing objects:  22% (5/22)   
Compressing objects:  27% (6/22)   
Compressing objects:  31% (7/22)   
Compressing objects:  36% (8/22)   
Compressing objects:  40% (9/22)   
Compressing objects:  45% (10/22)   
Compressing objects:  50% (11/22)   
Compressing objects:  54% (12/22)   
Compressing objects:  59% (13/22)   
Compressing objects:  63% (14/22)   
Compressing objects:  68% (15/22)   
Compressing objects:  72% (16/22)   
Compressing objects:  77% (17/22)   
Compressing objects:  81% (18/22)   
Compressing objects:  86% (19/22)   
Compressing objects:  90% (20/22)   
Compressing objects:  95% (21/22)   
Compressing objects: 100% (22/22)   
Compressing objects: 100% (22/22), done.
Writing objects:   0% (1/120)   
Writing objects:   1% (2/120)   
Writing objects:   2% (3/120)   
Writing objects:   3% (4/120)   
Writing objects:   4% (5/120)   
Writing objects:   5% (6/120)   
Writing objects:   6% (8/120)   
Writing objects:   7% (9/120)   
Writing objects:   8% (10/120)   
Writing objects:   9% (11/120)   
Writing objects:  10% (12/120)   
Writing objects:  11% (14/120)   
Writing objects:  12% (15/120)   
Writing objects:  13% (16/120)   
Writing objects:  14% (17/120)   
Writing objects:  15% (18/120)   
Writing objects:  16% (20/120)   
Writing objects:  17% (21/120)   
Writing objects:  18% (22/120)   
Writing objects:  19% (23/120)   
Writing objects:  20% (24/120)   
Writing objects:  21% (26/120)   
Writing objects:  22% (27/120)   
Writing objects:  23% (28/120)   
Writing objects:  24% (29/120)   
Writing objects:  25% (30/120)   
Writing objects:  26% (32/120)   
Writing objects:  27% (33/120)   
Writing objects:  28% (34/120)   
Writing objects:  29% (35/120)   
Writing objects:  30% (36/120)   
Writing objects:  31% (38/120)   
Writing objects:  32% (39/120)   
Writing objects:  33% (40/120)   
Writing objects:  34% (41/120)   
Writing objects:  35% (42/120)   
Writing objects:  36% (44/120)   
Writing objects:  37% (45/120)   
Writing objects:  38% (46/120)   
Writing objects:  40% (48/120)   
Writing objects:  41% (50/120)   
Writing objects:  42% (51/120)   
Writing objects:  43% (52/120)   
Writing objects:  44% (53/120)   
Writing objects:  45% (54/120)   
Writing objects:  46% (56/120)   
Writing objects:  47% (57/120)   
Writing objects:  48% (58/120)   
Writing objects:  49% (59/120)   
Writing objects:  50% (60/120)   
Writing objects:  51% (62/120)   
Writing objects:  52% (63/120)   
Writing objects:  53% (64/120)   
Writing objects:  54% (65/120)   
Writing objects:  55% (66/120)   
Writing objects:  56% (68/120)   
Writing objects:  57% (69/120)   
Writing objects:  58% (70/120)   
Writing objects:  59% (71/120)   
Writing objects:  60% (72/120)   
Writing objects:  61% (74/120)   
Writing objects:  62% (75/120)   
Writing objects:  63% (76/120)   
Writing objects:  64% (77/120)   
Writing objects:  65% (78/120)   
Writing objects:  66% (80/120)   
Writing objects:  67% (81/120)   
Writing objects:  68% (82/120)   
Writing objects:  69% (83/120)   
Writing objects:  70% (84/120)   
Writing objects:  71% (86/120)   
Writing objects:  72% (87/120)   
Writing objects:  73% (88/120)   
Writing objects:  74% (89/120)   
Writing objects:  75% (90/120)   
Writing objects:  76% (92/120)   
Writing objects:  77% (93/120)   
Writing objects:  78% (94/120)   
Writing objects:  79% (95/120)   
Writing objects:  80% (96/120)   
Writing objects:  81% (98/120)   
Writing objects:  82% (99/120)   
Writing objects:  83% (100/120)   
Writing objects:  84% (101/120)   
Writing objects:  85% (102/120)   
Writing objects:  86% (104/120)   
Writing objects:  87% (105/120)   
Writing objects:  88% (106/120)   
Writing objects:  89% (107/120)   
Writing objects:  90% (108/120)   
Writing objects:  91% (110/120)   
Writing objects:  92% (111/120)   
Writing objects:  93% (112/120)   
Writing objects:  94% (113/120)   
Writing objects:  95% (114/120)   
Writing objects:  96% (116/120)   
Writing objects:  97% (117/120)   
Writing objects:  98% (118/120)   
Writing objects:  99% (119/120)   
Writing objects: 100% (120/120)   
Writing objects: 100% (120/120), 21.09 KiB, done.
Total 120 (delta 98), reused 120 (delta 98)
To xen@xenbits.xensource.com:git/linux-pvops.git
   26a7895..839cf7a  839cf7a236278ae358ff12141a168c0982fa0cd9 -> 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 Wed Jun 20 10:00:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 10: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 1ShHhg-0000iU-7y; Wed, 20 Jun 2012 10:00: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 1ShHhf-0000iP-9J
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 09:59:59 +0000
Received: from [85.158.139.83:50239] by server-5.bemta-5.messagelabs.com id
	1E/F4-02722-E1F91EF4; Wed, 20 Jun 2012 09:59:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340186397!24315723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6350 invoked from network); 20 Jun 2012 09:59:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 09:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13119401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:59:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 10:59:57 +0100
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 1ShHhd-0003KC-05;
	Wed, 20 Jun 2012 09:59:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShHhc-0005FF-R9;
	Wed, 20 Jun 2012 10:59:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13100-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 10:59:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13100: 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 13100 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13100/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13048
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13048

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9
baseline version:
 linux                26a7895e70104811258cf023d06a21f92ab590c6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=839cf7a236278ae358ff12141a168c0982fa0cd9
+ . 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 839cf7a236278ae358ff12141a168c0982fa0cd9
+ branch=linux-3.0
+ revision=839cf7a236278ae358ff12141a168c0982fa0cd9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 839cf7a236278ae358ff12141a168c0982fa0cd9:tested/linux-3.0
Counting objects: 1   
Counting objects: 13   
Counting objects: 173, done.
Compressing objects:   4% (1/22)   
Compressing objects:   9% (2/22)   
Compressing objects:  13% (3/22)   
Compressing objects:  18% (4/22)   
Compressing objects:  22% (5/22)   
Compressing objects:  27% (6/22)   
Compressing objects:  31% (7/22)   
Compressing objects:  36% (8/22)   
Compressing objects:  40% (9/22)   
Compressing objects:  45% (10/22)   
Compressing objects:  50% (11/22)   
Compressing objects:  54% (12/22)   
Compressing objects:  59% (13/22)   
Compressing objects:  63% (14/22)   
Compressing objects:  68% (15/22)   
Compressing objects:  72% (16/22)   
Compressing objects:  77% (17/22)   
Compressing objects:  81% (18/22)   
Compressing objects:  86% (19/22)   
Compressing objects:  90% (20/22)   
Compressing objects:  95% (21/22)   
Compressing objects: 100% (22/22)   
Compressing objects: 100% (22/22), done.
Writing objects:   0% (1/120)   
Writing objects:   1% (2/120)   
Writing objects:   2% (3/120)   
Writing objects:   3% (4/120)   
Writing objects:   4% (5/120)   
Writing objects:   5% (6/120)   
Writing objects:   6% (8/120)   
Writing objects:   7% (9/120)   
Writing objects:   8% (10/120)   
Writing objects:   9% (11/120)   
Writing objects:  10% (12/120)   
Writing objects:  11% (14/120)   
Writing objects:  12% (15/120)   
Writing objects:  13% (16/120)   
Writing objects:  14% (17/120)   
Writing objects:  15% (18/120)   
Writing objects:  16% (20/120)   
Writing objects:  17% (21/120)   
Writing objects:  18% (22/120)   
Writing objects:  19% (23/120)   
Writing objects:  20% (24/120)   
Writing objects:  21% (26/120)   
Writing objects:  22% (27/120)   
Writing objects:  23% (28/120)   
Writing objects:  24% (29/120)   
Writing objects:  25% (30/120)   
Writing objects:  26% (32/120)   
Writing objects:  27% (33/120)   
Writing objects:  28% (34/120)   
Writing objects:  29% (35/120)   
Writing objects:  30% (36/120)   
Writing objects:  31% (38/120)   
Writing objects:  32% (39/120)   
Writing objects:  33% (40/120)   
Writing objects:  34% (41/120)   
Writing objects:  35% (42/120)   
Writing objects:  36% (44/120)   
Writing objects:  37% (45/120)   
Writing objects:  38% (46/120)   
Writing objects:  40% (48/120)   
Writing objects:  41% (50/120)   
Writing objects:  42% (51/120)   
Writing objects:  43% (52/120)   
Writing objects:  44% (53/120)   
Writing objects:  45% (54/120)   
Writing objects:  46% (56/120)   
Writing objects:  47% (57/120)   
Writing objects:  48% (58/120)   
Writing objects:  49% (59/120)   
Writing objects:  50% (60/120)   
Writing objects:  51% (62/120)   
Writing objects:  52% (63/120)   
Writing objects:  53% (64/120)   
Writing objects:  54% (65/120)   
Writing objects:  55% (66/120)   
Writing objects:  56% (68/120)   
Writing objects:  57% (69/120)   
Writing objects:  58% (70/120)   
Writing objects:  59% (71/120)   
Writing objects:  60% (72/120)   
Writing objects:  61% (74/120)   
Writing objects:  62% (75/120)   
Writing objects:  63% (76/120)   
Writing objects:  64% (77/120)   
Writing objects:  65% (78/120)   
Writing objects:  66% (80/120)   
Writing objects:  67% (81/120)   
Writing objects:  68% (82/120)   
Writing objects:  69% (83/120)   
Writing objects:  70% (84/120)   
Writing objects:  71% (86/120)   
Writing objects:  72% (87/120)   
Writing objects:  73% (88/120)   
Writing objects:  74% (89/120)   
Writing objects:  75% (90/120)   
Writing objects:  76% (92/120)   
Writing objects:  77% (93/120)   
Writing objects:  78% (94/120)   
Writing objects:  79% (95/120)   
Writing objects:  80% (96/120)   
Writing objects:  81% (98/120)   
Writing objects:  82% (99/120)   
Writing objects:  83% (100/120)   
Writing objects:  84% (101/120)   
Writing objects:  85% (102/120)   
Writing objects:  86% (104/120)   
Writing objects:  87% (105/120)   
Writing objects:  88% (106/120)   
Writing objects:  89% (107/120)   
Writing objects:  90% (108/120)   
Writing objects:  91% (110/120)   
Writing objects:  92% (111/120)   
Writing objects:  93% (112/120)   
Writing objects:  94% (113/120)   
Writing objects:  95% (114/120)   
Writing objects:  96% (116/120)   
Writing objects:  97% (117/120)   
Writing objects:  98% (118/120)   
Writing objects:  99% (119/120)   
Writing objects: 100% (120/120)   
Writing objects: 100% (120/120), 21.09 KiB, done.
Total 120 (delta 98), reused 120 (delta 98)
To xen@xenbits.xensource.com:git/linux-pvops.git
   26a7895..839cf7a  839cf7a236278ae358ff12141a168c0982fa0cd9 -> 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 Wed Jun 20 10:32:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 10:32: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 1ShICY-00014e-Pf; Wed, 20 Jun 2012 10:31: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 1ShICX-00014Z-Ap
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 10:31:53 +0000
Received: from [193.109.254.147:55298] by server-4.bemta-14.messagelabs.com id
	7F/50-02077-896A1EF4; Wed, 20 Jun 2012 10:31:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340188311!3608331!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19453 invoked from network); 20 Jun 2012 10:31:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 10:31:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 11:31:51 +0100
Message-Id: <4FE1C2E3020000780008AC77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 11:32:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
	<CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com>
In-Reply-To: <CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:45, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>>> The most controversial decision was whether the embargo date might be
>>> extended after it had originally been set.  We resisted these
>>> suggestions, referring to the process document, which does not
>>> contemplate extending the disclosure period.  However, when a
>>> predisclosure list member pressured the discoverer into requesting an
>>> extension, we felt the best interpretation of the process document
>>> required us to acquiesce.
>>>
>>> Specifically, of course, we as a team would like clearer guidance from
>>> the process about whether, and if so under what circumstances, a
>>> predisclosure period should be extended.
>>
>> I think this should be done via (perhaps silent) consensus on the
>> pre-discosure list. Leaving the embargo time line determination
>> entirely to the discoverer isn't really suitable. He might provide an
>> initial suggestion, but we ought to set a period of time (say, a
>> week or less) during which adjustment proposals can be made.
> 
> The problem with this is that extending the embargo helps providers
> who are on the predisclosure list (a minority), but hurts those not on
> the list (the vast majority).  So there's a moral hazard with what you
> suggest: it is just way too easy for the people on the list to vote to
> make their own lives easier, not considering the plight of those who
> are not big enough or connected enough to be on the list.  Doing so
> also favors large players and incumbents against small players; doing
> so may well be considered anti-competitive and illegal in many
> jurisdictions.
> 
> The only way this would work is if the predisclosure list consisted
> exclusively of software providers, and specifically excluded service
> providers.  It should be possible to include all software providers on
> the list, since it's a relatively small number of entities.
> Furthermore, since software providers presumably care about the
> security of their customers, it would provide the incentive to make
> the embargo as short as is reasonable.

You need to take this in context with my proposal to have only
software vendors have a vote here, and to allow service
providers at most an observing (maybe recommending to a
limited degree) role.

>>> 3. Decisionmaking
>>>
>>> It was suggested to us several times, and indeed seemed to be regarded
>>> by some as an underlying principle, that the predisclosure list
>>> members should be making the decisions about disclosure schedule etc.
>>>
>>> The question of who is to make the decisions, and on what basis, needs
>>> to be addressed.
>>
>> See above. Leaving this to the discretion of the discoverer is
>> neither open nor fair.
> 
> But there's a practical matter to consider here: if it's known that we
> won't cooperate with the discoverer wrt disclosure times, discoverers
> may simply not share their information with us.  I think that's the
> main reason for the "do what the discoverer wants" rule.  I think
> there needs to be some kind of a balance though: extending the embargo
> less than 12 hours before the deadline is clearly not reasonable.

I still suggested that the discoverer gets a first shot at the
embargo deadline. But if everyone else disagrees (i.e. the
deadline was unreasonable), then it should be possible to ignore
the discoverer's preference.

>>> Several members of the predisclosure list suggested that the
>>> predisclosure period was too short.  Others were ready within the
>>> predisclosure period's timeframe, and were disappointed to see it
>>> extended and to have to delay their fixes.
>>
>> Setting a default period might be counter productive. There may
>> be cases (for example had we wanted to fix XSA-9 properly)
>> where developing a fix could take quite a bit of time. Not having
>> a fix ready shouldn't, however, prevent initial announcements of
>> a problem.
> 
> A default period can be considered a guideline.  In the case of a
> particularly tricky fix, saying, "Normally we would set 2 weeks, but I
> think in this case we should go for 3 or 4" is perfectly reasonable.
> 
> Since the embargo is really for software providers to test fixes,
> perhaps we should suggest it should be "X business days after a fix is
> released", rather than "X days after the vulnerability is disclosed"?

Yes, that sounds like a reasonable thing.

>> As to downstreams, I think only direct ones should be involved in
>> any decision making processes. Indirect ones might be allowed on
>> the list, but exclusively as observers. Mis-use of the observer role
>> (e.g. as in influencing those participating in decision making in
>> undue ways), should it become known, should result in removal of
>> list membership.
> 
> What do you mean by "direct" and "indirect"?  If by "direct" you mean,
> "sell/distribute software", and "indirect" you mean, "use the software
> to provide a service", I think we're probably in agreement. :-)

That's what I mean, and so we are apparently.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 10:32:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 10:32: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 1ShICY-00014e-Pf; Wed, 20 Jun 2012 10:31: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 1ShICX-00014Z-Ap
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 10:31:53 +0000
Received: from [193.109.254.147:55298] by server-4.bemta-14.messagelabs.com id
	7F/50-02077-896A1EF4; Wed, 20 Jun 2012 10:31:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340188311!3608331!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19453 invoked from network); 20 Jun 2012 10:31:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 10:31:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 11:31:51 +0100
Message-Id: <4FE1C2E3020000780008AC77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 11:32:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
	<CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com>
In-Reply-To: <CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:45, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>>> The most controversial decision was whether the embargo date might be
>>> extended after it had originally been set.  We resisted these
>>> suggestions, referring to the process document, which does not
>>> contemplate extending the disclosure period.  However, when a
>>> predisclosure list member pressured the discoverer into requesting an
>>> extension, we felt the best interpretation of the process document
>>> required us to acquiesce.
>>>
>>> Specifically, of course, we as a team would like clearer guidance from
>>> the process about whether, and if so under what circumstances, a
>>> predisclosure period should be extended.
>>
>> I think this should be done via (perhaps silent) consensus on the
>> pre-discosure list. Leaving the embargo time line determination
>> entirely to the discoverer isn't really suitable. He might provide an
>> initial suggestion, but we ought to set a period of time (say, a
>> week or less) during which adjustment proposals can be made.
> 
> The problem with this is that extending the embargo helps providers
> who are on the predisclosure list (a minority), but hurts those not on
> the list (the vast majority).  So there's a moral hazard with what you
> suggest: it is just way too easy for the people on the list to vote to
> make their own lives easier, not considering the plight of those who
> are not big enough or connected enough to be on the list.  Doing so
> also favors large players and incumbents against small players; doing
> so may well be considered anti-competitive and illegal in many
> jurisdictions.
> 
> The only way this would work is if the predisclosure list consisted
> exclusively of software providers, and specifically excluded service
> providers.  It should be possible to include all software providers on
> the list, since it's a relatively small number of entities.
> Furthermore, since software providers presumably care about the
> security of their customers, it would provide the incentive to make
> the embargo as short as is reasonable.

You need to take this in context with my proposal to have only
software vendors have a vote here, and to allow service
providers at most an observing (maybe recommending to a
limited degree) role.

>>> 3. Decisionmaking
>>>
>>> It was suggested to us several times, and indeed seemed to be regarded
>>> by some as an underlying principle, that the predisclosure list
>>> members should be making the decisions about disclosure schedule etc.
>>>
>>> The question of who is to make the decisions, and on what basis, needs
>>> to be addressed.
>>
>> See above. Leaving this to the discretion of the discoverer is
>> neither open nor fair.
> 
> But there's a practical matter to consider here: if it's known that we
> won't cooperate with the discoverer wrt disclosure times, discoverers
> may simply not share their information with us.  I think that's the
> main reason for the "do what the discoverer wants" rule.  I think
> there needs to be some kind of a balance though: extending the embargo
> less than 12 hours before the deadline is clearly not reasonable.

I still suggested that the discoverer gets a first shot at the
embargo deadline. But if everyone else disagrees (i.e. the
deadline was unreasonable), then it should be possible to ignore
the discoverer's preference.

>>> Several members of the predisclosure list suggested that the
>>> predisclosure period was too short.  Others were ready within the
>>> predisclosure period's timeframe, and were disappointed to see it
>>> extended and to have to delay their fixes.
>>
>> Setting a default period might be counter productive. There may
>> be cases (for example had we wanted to fix XSA-9 properly)
>> where developing a fix could take quite a bit of time. Not having
>> a fix ready shouldn't, however, prevent initial announcements of
>> a problem.
> 
> A default period can be considered a guideline.  In the case of a
> particularly tricky fix, saying, "Normally we would set 2 weeks, but I
> think in this case we should go for 3 or 4" is perfectly reasonable.
> 
> Since the embargo is really for software providers to test fixes,
> perhaps we should suggest it should be "X business days after a fix is
> released", rather than "X days after the vulnerability is disclosed"?

Yes, that sounds like a reasonable thing.

>> As to downstreams, I think only direct ones should be involved in
>> any decision making processes. Indirect ones might be allowed on
>> the list, but exclusively as observers. Mis-use of the observer role
>> (e.g. as in influencing those participating in decision making in
>> undue ways), should it become known, should result in removal of
>> list membership.
> 
> What do you mean by "direct" and "indirect"?  If by "direct" you mean,
> "sell/distribute software", and "indirect" you mean, "use the software
> to provide a service", I think we're probably in agreement. :-)

That's what I mean, and so we are apparently.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 10:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 10:34:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShIF3-0001Ac-CK; Wed, 20 Jun 2012 10:34:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShIF1-0001AT-41
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 10:34:27 +0000
Received: from [85.158.143.35:13764] by server-1.bemta-4.messagelabs.com id
	35/AD-24392-237A1EF4; Wed, 20 Jun 2012 10:34:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340188465!14012547!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4169 invoked from network); 20 Jun 2012 10:34:25 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 10:34:25 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79009740; Wed, 20 Jun 2012 12:34:24 +0200
Message-ID: <1340188450.20225.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 20 Jun 2012 12:34:10 +0200
In-Reply-To: <1340183168.4906.8.camel@zakaz.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7534598395259090256=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7534598395259090256==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-U0Ptp0iKiju7vDkZKAuY"


--=-U0Ptp0iKiju7vDkZKAuY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 10:06 +0100, Ian Campbell wrote:
> On Wed, 2012-06-20 at 08:51 +0100, Jan Beulich wrote:
> > >>> On 20.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> > > branch xen-unstable
> > > xen branch xen-unstable
> > > job test-amd64-amd64-xl-win7-amd64
> > > test windows-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/staging/xen-unstable.hg
> > >
> > > *** Found and reproduced problem changeset ***
> > >
> > >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> > >   Bug introduced:  9d1fd58ff602
> > >   Bug not present: 32034d1914a6
> > >
> > >
> > >   changeset:   25468:9d1fd58ff602
> > >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> > >   date:        Fri Jun 08 15:26:01 2012 +0100
> > >
> > >       xl: check for meaningful combination of sedf config file parame=
ters
> >=20
> > Dario,
> >=20
> > these bisection results have been posted for a couple of days,
> > yet so far I don't recall having seen any sign from you as to what
> > you're plans are. Given that this has now been holding up a push
> > for over 10 days, I think I'll have to request reverting the change
> > otherwise.
>=20
> It's not been as long as ten days, the commit was the 14th. But yes we
> need to know what is going on here ASAP -- Dario please can you take a
> look.
>=20
Definitely!

Sorry for this, the mail has been put on hold in some folder and I
haven't even seen it till now! :-(

> It's an odd one -- the logs seem to show the guest has started but the
> patch in question would (or should!) cause an early error return during
> build. It's possible that the recent test system outage has caused the
> bisector to get confused but it has fingered this changeset at least
> twice now.
>=20
I'll check what's going on immediately. Sorry again.

> The bisector really should try and pull out S-o-b's et al from the
> offending commit and add appropriate CCs. There's also something of an
> expectation that developers will keep an eye on the test system results
> after a patch of theirs has been expected though.
>=20
Sure. Being on Cc would have helped a bit, but it's definitely my fault
not noticing the whole thing sooner!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-U0Ptp0iKiju7vDkZKAuY
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)

iEUEABECAAYFAk/hpyIACgkQk4XaBE3IOsRXHQCfQlA7Y3aMkg6hY8Uz9mNe+XAo
/pYAl1tyq+lgvI0X4lvVsjWRpmfHtCY=
=WKe2
-----END PGP SIGNATURE-----

--=-U0Ptp0iKiju7vDkZKAuY--



--===============7534598395259090256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7534598395259090256==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 10:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 10:34:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShIF3-0001Ac-CK; Wed, 20 Jun 2012 10:34:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShIF1-0001AT-41
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 10:34:27 +0000
Received: from [85.158.143.35:13764] by server-1.bemta-4.messagelabs.com id
	35/AD-24392-237A1EF4; Wed, 20 Jun 2012 10:34:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340188465!14012547!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4169 invoked from network); 20 Jun 2012 10:34:25 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 10:34:25 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79009740; Wed, 20 Jun 2012 12:34:24 +0200
Message-ID: <1340188450.20225.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 20 Jun 2012 12:34:10 +0200
In-Reply-To: <1340183168.4906.8.camel@zakaz.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7534598395259090256=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7534598395259090256==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-U0Ptp0iKiju7vDkZKAuY"


--=-U0Ptp0iKiju7vDkZKAuY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 10:06 +0100, Ian Campbell wrote:
> On Wed, 2012-06-20 at 08:51 +0100, Jan Beulich wrote:
> > >>> On 20.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> > > branch xen-unstable
> > > xen branch xen-unstable
> > > job test-amd64-amd64-xl-win7-amd64
> > > test windows-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/staging/xen-unstable.hg
> > >
> > > *** Found and reproduced problem changeset ***
> > >
> > >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> > >   Bug introduced:  9d1fd58ff602
> > >   Bug not present: 32034d1914a6
> > >
> > >
> > >   changeset:   25468:9d1fd58ff602
> > >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> > >   date:        Fri Jun 08 15:26:01 2012 +0100
> > >
> > >       xl: check for meaningful combination of sedf config file parame=
ters
> >=20
> > Dario,
> >=20
> > these bisection results have been posted for a couple of days,
> > yet so far I don't recall having seen any sign from you as to what
> > you're plans are. Given that this has now been holding up a push
> > for over 10 days, I think I'll have to request reverting the change
> > otherwise.
>=20
> It's not been as long as ten days, the commit was the 14th. But yes we
> need to know what is going on here ASAP -- Dario please can you take a
> look.
>=20
Definitely!

Sorry for this, the mail has been put on hold in some folder and I
haven't even seen it till now! :-(

> It's an odd one -- the logs seem to show the guest has started but the
> patch in question would (or should!) cause an early error return during
> build. It's possible that the recent test system outage has caused the
> bisector to get confused but it has fingered this changeset at least
> twice now.
>=20
I'll check what's going on immediately. Sorry again.

> The bisector really should try and pull out S-o-b's et al from the
> offending commit and add appropriate CCs. There's also something of an
> expectation that developers will keep an eye on the test system results
> after a patch of theirs has been expected though.
>=20
Sure. Being on Cc would have helped a bit, but it's definitely my fault
not noticing the whole thing sooner!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-U0Ptp0iKiju7vDkZKAuY
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)

iEUEABECAAYFAk/hpyIACgkQk4XaBE3IOsRXHQCfQlA7Y3aMkg6hY8Uz9mNe+XAo
/pYAl1tyq+lgvI0X4lvVsjWRpmfHtCY=
=WKe2
-----END PGP SIGNATURE-----

--=-U0Ptp0iKiju7vDkZKAuY--



--===============7534598395259090256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7534598395259090256==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 11:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:30:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShJ6e-0001fn-TH; Wed, 20 Jun 2012 11:29:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShJ6d-0001fi-LX
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:29:51 +0000
Received: from [193.109.254.147:54851] by server-2.bemta-14.messagelabs.com id
	2A/1F-01735-E24B1EF4; Wed, 20 Jun 2012 11:29:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340191790!8257788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21036 invoked from network); 20 Jun 2012 11:29:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 11:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13121656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 11:29:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 12:29:49 +0100
Message-ID: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 20 Jun 2012 12:29:48 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QSBiaXQgbGF0ZSB0aGlzIHdlZWssIGR1ZSB0byBteSBiZWluZyBvbiB2YWNhdGlvbi4gTm9ybWFs
IE1vbmRheQpzZXJ2aWNlIHNob3VsZCBiZSByZXN1bWVkIG5leHQgd2Vlay4KClBsYW4gZm9yIGEg
NC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVs
LzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhlIHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgoKMTkg
TWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAgLS0g
RmVhdHVyZSBGcmVlemUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJdCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2UgY2Fu
ZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCByZWxlYXNlCgpUaGUgdXBkYXRl
ZCBUT0RPIGxpc3QgZm9sbG93cy4KCklmIHlvdSBhcmUgYXdhcmUgb2YgYW55IGJ1Z3Mgd2hpY2gg
bXVzdC9zaG91bGQgYmUgZml4ZWQgZm9yIDQuMiB0aGVuCnBsZWFzZSByZXBseSB0byB0aGlzIHRo
cmVhZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJlciB0byBwaWNrIHRoZW0KdXAgbmV4dCB3
ZWVrKQoKQXMgd2VsbCBhcyBbQlVHXXMgSSd2ZSBhbHNvIHN0YXJ0ZWQgdHJhY2tpbmcgdGhpbmdz
IHRvIFtDSEVDS10gYmVmb3JlCnRoZSByZWxlYXNlLiBUaGVzZSBhcmUgYmFzaWNhbGx5IGZvciB0
aGluZ3Mgd2hpY2ggd2Ugb3VnaHQgdG8gY29uZmlybQpkdXJpbmcgdGhlIFJDIGN5Y2xlcyBlLmcu
IHRoaW5ncyB3aGljaCBhcmUgbm90IGNvdmVyZWQgYnkgYXV0b21hdGVkCnRlc3RpbmcuCgpQZXIg
dGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwgbm93IGhhdmUgdG8gYmUgbWFkZSBh
cyB0byB3aHkKbmV3IGl0ZW1zIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgbGlzdCwgZXNwZWNpYWxs
eSBhcyBhIGJsb2NrZXIsIHJhdGhlcgp0aGFuIGRlZmVycmVkIHRvIDQuMy4KCmh5cGVydmlzb3Is
IGJsb2NrZXJzOgoKICAgICogTm9uZQogCnRvb2xzLCBibG9ja2VyczoKCiAgICAqIGxpYnhsIHN0
YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQogICAg
ICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBB
c3BlY3RzIG9mCiAgICAgIHRoaXMgYXJlOgoKICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5
IG5lZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9zdXNwZW5kLiBN
b3ZlIHhjX2RvbWFpbl9zYXZlL3Jlc3RvcmUgaW50byBhCiAgICAgICAgICAgICAgc2VwYXJhdGUg
cHJvY2VzcyAoSWFuIEphY2tzb24sIHBhdGNoZXMgcmV2aWV3cyBhbmQgcmVwb3N0ZWQpLgoKICAg
ICAgICAgICAgKiBsaWJ4bF9kZXZpY2Vfe2Rpc2ssbmljLHZrYixhZGQscGNpfV9hZGQgKGFuZAog
ICAgICAgICAgICAgIHJlbW92ZSkuIChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzIHBvc3RlZCBm
b3IgZGlzayAmIG5pYywgdmtiCiAgICAgICAgICAgICAgdHJpdmlhbCwgbm90IGxvb2tlZCBhdCBw
Y2kgeWV0KQoKICAgICAgICAqIExJQlhMX05JQ19UWVBFIGVudW0gbmFtZXMgYXJlIGNvbmZ1c2lu
Zy4gKFJvZ2VyLCBpbmNsdWRlZCBpbgogICAgICAgICAgY2FsbGluZyBob3RwbHVnIHNjcmlwdHMg
c2VyaWVzKQoKICAgICAgICAqIHVzZSBsaWJ4bF9jcHVtYXAgZm9yIGJfaW5mby5hdmFpbF9jcHVz
IGluc3RlYWQgb2YgYW4gaW50LAogICAgICAgICAgdGhpcyBhbGxvd3Mgc2V0dGluZyBtb3JlIHRo
YW4gMzEgQ1BVUyAoWWFuZyBaIFpoYW5nLCBwYXRjaGVzCiAgICAgICAgICBwb3N0ZWQsIGF3YWl0
aW5nIGEgcmVwb3N0KQoKICAgICAgICAqIHVzZSBhbiBlbnVtIGZvciBWR0EgaW50ZXJmYWNlIHR5
cGUgKGUuZy4gQ2lycnVzLAogICAgICAgICAgU3RkVkdBKS4gQWxsb3dzIGZvciBRWEwgc3VwcG9y
dCAoaW4gNC4zKS4gKFpob3UgUGVuZywKICAgICAgICAgIGF3YWl0aW5nIHJlcG9zdCkKCiAgICAq
IHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAgKiBbQlVHXSBjYW5ub3QgY3JlYXRl
IGFuIGVtcHR5IENELVJPTSBkcml2ZSBvbiBIVk0gZ3Vlc3QsCiAgICAgICAgICByZXBvcnRlZCBi
eSBGYWJpbyBGYW50b25pIGluIDw0Rjk2NzJERC4yMDgwOTAyQHRpc2NhbGkuaXQ+CgogICAgICAg
ICogZG9lcyBub3QgYXV0b21hdGljYWxseSB0cnkgdG8gc2VsZWN0IGEgKHNldCBvZikgbm9kZShz
KSBvbgogICAgICAgICAgd2hpY2ggdG8gY3JlYXRlIGEgVk0gYW5kIHBpbiBpdHMgdmNwdXMgdGhl
cmUuIChEYXJpbwogICAgICAgICAgRmFnZ2lvbGksIHYyIHBvc3RlZCkKCiAgICAqIE1vcmUgZm9y
bWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5IGluCiAgICAg
IHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMx
IHRvCiAgICAgIHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KCiAgICAqIGNhbGxpbmcgaG90cGx1
ZyBzY3JpcHRzIGZyb20geGwgKExpbnV4IGFuZCBOZXRCU0QpIChSb2dlciBQYXUKICAgICAgTW9u
bsOpLCB2NiBwb3N0ZWQsIGF3YWl0aW5nIHJldmlldykKCiAgICAqIEJsb2NrIHNjcmlwdCBzdXBw
b3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKICAgICAgUGF1IE1v
bm7DqSwgImp1c3QgYmUgYSBtYXR0ZXIgb2YgcmVtb3ZpbmcgYW4gImlmIiIpCgogICAgKiBBZGp1
c3RtZW50cyBuZWVkZWQgZm9yIHFkaXNrIGJhY2tlbmQgdG8gd29yayBvbiBub24tcHZvcHMgTGlu
dXguCiAgICAgICJxZW11L3hlbmRpc2s6IHNldCBtYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8g
YmUgdXNlZCIgKEphbgogICAgICBCZXVsaWNoLCBwYXRjaCBjb21taXR0ZWQgdG8gcWVtdS14ZW4t
dXBzdHJlYW0sIHBlbmRpbmcgZm9yCiAgICAgIHFlbXUteGVuLXRyYWRpdGlvbmFsKQoKICAgICog
W0NIRUNLXSBDb25maXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAtPiA0LjIgd29ya3Mu
CgogICAgKiBbQlVHXSBMSUJMRUFGRElSIGV0IGFsIGFuZCBsaWJmc2ltYWdlIGRvIHRoZSB3cm9u
ZyB0aGluZyBvbgogICAgICBtb2Rlcm4gRGViaWFuL1VidW50dSB3LyBtdWx0aWFyY2ggY2FwYWJp
bGl0aWVzIChNYXR0IFdpbHNvbiwKICAgICAgcGF0Y2ggcG9zdGVkKQoKICAgICogW0NIRUNLXSBU
ZXN0IHN0dWIgZG9tYWlucyB3b3JrIHdpdGggeGwuCgpoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6
CgogICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwLCBhbmQg
cmV2aWV3ZWQKICAgICAgYXdhaXRpbmcgcmVwb3N0KQoKdG9vbHMsIG5pY2UgdG8gaGF2ZToKCiAg
ICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAgKiBBY2NlcHQgInhsIGNyIC9k
ZXYvbnVsbCBwYXJhbT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29uZmlnCiAgICAgICAgICBvbiB0
aGUgY29tbWFuZCBsaW5lIChXLiBNaWNoYWVsIFBldHVsbG8sIHBhdGNoIHBvc3RlZCkKCiAgICAq
IGxpYnhsIHN0YWJsZSBBUEkKCiAgICAgICAgKiBsaWJ4bF93YWl0X2Zvcl9mcmVlX21lbW9yeS9s
aWJ4bF93YWl0X2Zvcl9tZW1vcnlfdGFyZ2V0LgogICAgICAgICAgSW50ZXJmYWNlIG5lZWRzIGFu
IG92ZXJoYXVsLCByZWxhdGVkIHRvCiAgICAgICAgICBsb2NraW5nL3NlcmlhbGl6YXRpb24gb3Zl
ciBkb21haW4gY3JlYXRlLiBJYW5KIHRvIGFkZCBub3RlCiAgICAgICAgICBhYm91dCB0aGlzIGlu
dGVyZmFjZSBiZWluZyBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVyCiAgICAgICAgICB0
byA0LjMuCgogICAgICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoK
CiAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQgYmUgZWFzeSBvbmNlCiAg
ICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0gZG9uZS4gVGhpcyBpcyBiYXNpY2FsbHkgYSBo
ZWxwZXIKICAgICAgICAgICAgICBmdW5jdGlvbiBhbmQgaXRzIGZ1bmN0aW9uYWxpdHkgY2FuIGJl
IGltcGxlbWVudGVkIGluCiAgICAgICAgICAgICAgdGVybXMgb2YgdGhlIGxpYnhsX2Rpc2tfKiBp
bnRlcmZhY2VzLiBJZiB0aGlzIGlzIG5vdAogICAgICAgICAgICAgIGRvbmUgaW4gdGltZSB3ZSBz
aG91bGQgZG9jdW1lbnQgYXMgYSBzdWJzdGFuZGFyZAogICAgICAgICAgICAgIGludGVyZmFjZSB3
aGljaCBpcyBzdWJqZWN0IHRvIGNoYW5nZSBwb3N0IDQuMi4KCiAgICAqIHhsLmNmZyg1KSBkb2N1
bWVudGF0aW9uIHBhdGNoIGZvciBxZW11LXVwc3RyZWFtCiAgICAgIHZpZGVvcmFtL3ZpZGVvbWVt
IHN1cHBvcnQ6CiAgICAgIGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRl
dmVsLzIwMTItMDUvbXNnMDAyNTAuaHRtbAogICAgICBxZW11LXVwc3RyZWFtIGRvZXNuJ3Qgc3Vw
cG9ydCBzcGVjaWZ5aW5nIHZpZGVvbWVtIHNpemUgZm9yIHRoZQogICAgICBIVk0gZ3Vlc3QgY2ly
cnVzL3N0ZHZnYS4gIChidXQgdGhpcyB3b3JrcyB3aXRoCiAgICAgIHFlbXUteGVuLXRyYWRpdGlv
bmFsKS4gKFBhc2kgS8Okcmtrw6RpbmVuKQoKICAgICogcWVtdS11cHN0cmVhbSBmb3IgTmV0QlNE
IChSb2dlciwgcGF0Y2ggY29tbWl0ZWQgdG8gTmV0QlNECiAgICAgIGtlcm5lbCwgYXdhaXRpbmcg
YXBwcm92YWwsIERPTkUgYXMgZmFyIGFzIFhlbiA0LjIgaXMgY29uY2VybmVkKQoKICAgICogW0JV
R10gbG9uZyBzdG9wIGR1cmluZyB0aGUgZ3Vlc3QgYm9vdCBwcm9jZXNzIHdpdGggcWNvdyBpbWFn
ZSwKICAgICAgcmVwb3J0ZWQgYnkgSW50ZWw6IGh0dHA6Ly9idWd6aWxsYS54ZW4ub3JnL2J1Z3pp
bGxhL3Nob3dfYnVnLmNnaT9pZD0xODIxCgogICAgKiBbQlVHXSB2Y3B1LXNldCBkb2Vzbid0IHRh
a2UgZWZmZWN0IG9uIGd1ZXN0LCByZXBvcnRlZCBieSBJbnRlbDoKICAgICAgaHR0cDovL2J1Z3pp
bGxhLnhlbi5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjIKCiAgICAqIExvYWQgYmxr
dGFwIGRyaXZlciBmcm9tIHhlbmNvbW1vbnMgaW5pdHNjcmlwdCBpZiBhdmFpbGFibGUsIHRocmVh
ZCBhdDoKICAgICAgPGRiNjE0ZTkyZmFmNzQzZTIwYjNmLjEzMzcwOTY5NzdAa29kbzI+LiBUbyBi
ZSBmaXhlZCBtb3JlCiAgICAgIHByb3Blcmx5IGluIDQuMy4gKFBhdGNoIHBvc3RlZCwgZGlzY3Vz
c2lvbiwgcGxhbiB0byB0YWtlIHNpbXBsZQogICAgICB4ZW5jb21tb25zIHBhdGNoIGZvciA0LjIg
YW5kIHJldmlzdCBmb3IgNC4zKQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Jun 20 11:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:30:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShJ6e-0001fn-TH; Wed, 20 Jun 2012 11:29:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShJ6d-0001fi-LX
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:29:51 +0000
Received: from [193.109.254.147:54851] by server-2.bemta-14.messagelabs.com id
	2A/1F-01735-E24B1EF4; Wed, 20 Jun 2012 11:29:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340191790!8257788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21036 invoked from network); 20 Jun 2012 11:29:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 11:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13121656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 11:29:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 12:29:49 +0100
Message-ID: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Wed, 20 Jun 2012 12:29:48 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QSBiaXQgbGF0ZSB0aGlzIHdlZWssIGR1ZSB0byBteSBiZWluZyBvbiB2YWNhdGlvbi4gTm9ybWFs
IE1vbmRheQpzZXJ2aWNlIHNob3VsZCBiZSByZXN1bWVkIG5leHQgd2Vlay4KClBsYW4gZm9yIGEg
NC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVs
LzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhlIHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgoKMTkg
TWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAgLS0g
RmVhdHVyZSBGcmVlemUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJdCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2UgY2Fu
ZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCByZWxlYXNlCgpUaGUgdXBkYXRl
ZCBUT0RPIGxpc3QgZm9sbG93cy4KCklmIHlvdSBhcmUgYXdhcmUgb2YgYW55IGJ1Z3Mgd2hpY2gg
bXVzdC9zaG91bGQgYmUgZml4ZWQgZm9yIDQuMiB0aGVuCnBsZWFzZSByZXBseSB0byB0aGlzIHRo
cmVhZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJlciB0byBwaWNrIHRoZW0KdXAgbmV4dCB3
ZWVrKQoKQXMgd2VsbCBhcyBbQlVHXXMgSSd2ZSBhbHNvIHN0YXJ0ZWQgdHJhY2tpbmcgdGhpbmdz
IHRvIFtDSEVDS10gYmVmb3JlCnRoZSByZWxlYXNlLiBUaGVzZSBhcmUgYmFzaWNhbGx5IGZvciB0
aGluZ3Mgd2hpY2ggd2Ugb3VnaHQgdG8gY29uZmlybQpkdXJpbmcgdGhlIFJDIGN5Y2xlcyBlLmcu
IHRoaW5ncyB3aGljaCBhcmUgbm90IGNvdmVyZWQgYnkgYXV0b21hdGVkCnRlc3RpbmcuCgpQZXIg
dGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBjYXNlIHdpbGwgbm93IGhhdmUgdG8gYmUgbWFkZSBh
cyB0byB3aHkKbmV3IGl0ZW1zIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgbGlzdCwgZXNwZWNpYWxs
eSBhcyBhIGJsb2NrZXIsIHJhdGhlcgp0aGFuIGRlZmVycmVkIHRvIDQuMy4KCmh5cGVydmlzb3Is
IGJsb2NrZXJzOgoKICAgICogTm9uZQogCnRvb2xzLCBibG9ja2VyczoKCiAgICAqIGxpYnhsIHN0
YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQogICAg
ICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBB
c3BlY3RzIG9mCiAgICAgIHRoaXMgYXJlOgoKICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5
IG5lZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAgICAqIGxpYnhsX2RvbWFpbl9zdXNwZW5kLiBN
b3ZlIHhjX2RvbWFpbl9zYXZlL3Jlc3RvcmUgaW50byBhCiAgICAgICAgICAgICAgc2VwYXJhdGUg
cHJvY2VzcyAoSWFuIEphY2tzb24sIHBhdGNoZXMgcmV2aWV3cyBhbmQgcmVwb3N0ZWQpLgoKICAg
ICAgICAgICAgKiBsaWJ4bF9kZXZpY2Vfe2Rpc2ssbmljLHZrYixhZGQscGNpfV9hZGQgKGFuZAog
ICAgICAgICAgICAgIHJlbW92ZSkuIChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzIHBvc3RlZCBm
b3IgZGlzayAmIG5pYywgdmtiCiAgICAgICAgICAgICAgdHJpdmlhbCwgbm90IGxvb2tlZCBhdCBw
Y2kgeWV0KQoKICAgICAgICAqIExJQlhMX05JQ19UWVBFIGVudW0gbmFtZXMgYXJlIGNvbmZ1c2lu
Zy4gKFJvZ2VyLCBpbmNsdWRlZCBpbgogICAgICAgICAgY2FsbGluZyBob3RwbHVnIHNjcmlwdHMg
c2VyaWVzKQoKICAgICAgICAqIHVzZSBsaWJ4bF9jcHVtYXAgZm9yIGJfaW5mby5hdmFpbF9jcHVz
IGluc3RlYWQgb2YgYW4gaW50LAogICAgICAgICAgdGhpcyBhbGxvd3Mgc2V0dGluZyBtb3JlIHRo
YW4gMzEgQ1BVUyAoWWFuZyBaIFpoYW5nLCBwYXRjaGVzCiAgICAgICAgICBwb3N0ZWQsIGF3YWl0
aW5nIGEgcmVwb3N0KQoKICAgICAgICAqIHVzZSBhbiBlbnVtIGZvciBWR0EgaW50ZXJmYWNlIHR5
cGUgKGUuZy4gQ2lycnVzLAogICAgICAgICAgU3RkVkdBKS4gQWxsb3dzIGZvciBRWEwgc3VwcG9y
dCAoaW4gNC4zKS4gKFpob3UgUGVuZywKICAgICAgICAgIGF3YWl0aW5nIHJlcG9zdCkKCiAgICAq
IHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAgKiBbQlVHXSBjYW5ub3QgY3JlYXRl
IGFuIGVtcHR5IENELVJPTSBkcml2ZSBvbiBIVk0gZ3Vlc3QsCiAgICAgICAgICByZXBvcnRlZCBi
eSBGYWJpbyBGYW50b25pIGluIDw0Rjk2NzJERC4yMDgwOTAyQHRpc2NhbGkuaXQ+CgogICAgICAg
ICogZG9lcyBub3QgYXV0b21hdGljYWxseSB0cnkgdG8gc2VsZWN0IGEgKHNldCBvZikgbm9kZShz
KSBvbgogICAgICAgICAgd2hpY2ggdG8gY3JlYXRlIGEgVk0gYW5kIHBpbiBpdHMgdmNwdXMgdGhl
cmUuIChEYXJpbwogICAgICAgICAgRmFnZ2lvbGksIHYyIHBvc3RlZCkKCiAgICAqIE1vcmUgZm9y
bWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5IGluCiAgICAg
IHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMx
IHRvCiAgICAgIHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KCiAgICAqIGNhbGxpbmcgaG90cGx1
ZyBzY3JpcHRzIGZyb20geGwgKExpbnV4IGFuZCBOZXRCU0QpIChSb2dlciBQYXUKICAgICAgTW9u
bsOpLCB2NiBwb3N0ZWQsIGF3YWl0aW5nIHJldmlldykKCiAgICAqIEJsb2NrIHNjcmlwdCBzdXBw
b3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKICAgICAgUGF1IE1v
bm7DqSwgImp1c3QgYmUgYSBtYXR0ZXIgb2YgcmVtb3ZpbmcgYW4gImlmIiIpCgogICAgKiBBZGp1
c3RtZW50cyBuZWVkZWQgZm9yIHFkaXNrIGJhY2tlbmQgdG8gd29yayBvbiBub24tcHZvcHMgTGlu
dXguCiAgICAgICJxZW11L3hlbmRpc2s6IHNldCBtYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8g
YmUgdXNlZCIgKEphbgogICAgICBCZXVsaWNoLCBwYXRjaCBjb21taXR0ZWQgdG8gcWVtdS14ZW4t
dXBzdHJlYW0sIHBlbmRpbmcgZm9yCiAgICAgIHFlbXUteGVuLXRyYWRpdGlvbmFsKQoKICAgICog
W0NIRUNLXSBDb25maXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAtPiA0LjIgd29ya3Mu
CgogICAgKiBbQlVHXSBMSUJMRUFGRElSIGV0IGFsIGFuZCBsaWJmc2ltYWdlIGRvIHRoZSB3cm9u
ZyB0aGluZyBvbgogICAgICBtb2Rlcm4gRGViaWFuL1VidW50dSB3LyBtdWx0aWFyY2ggY2FwYWJp
bGl0aWVzIChNYXR0IFdpbHNvbiwKICAgICAgcGF0Y2ggcG9zdGVkKQoKICAgICogW0NIRUNLXSBU
ZXN0IHN0dWIgZG9tYWlucyB3b3JrIHdpdGggeGwuCgpoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6
CgogICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwLCBhbmQg
cmV2aWV3ZWQKICAgICAgYXdhaXRpbmcgcmVwb3N0KQoKdG9vbHMsIG5pY2UgdG8gaGF2ZToKCiAg
ICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKCiAgICAgICAgKiBBY2NlcHQgInhsIGNyIC9k
ZXYvbnVsbCBwYXJhbT12YWx1ZSIgdG8gcHJvdmlkZSBhbGwgY29uZmlnCiAgICAgICAgICBvbiB0
aGUgY29tbWFuZCBsaW5lIChXLiBNaWNoYWVsIFBldHVsbG8sIHBhdGNoIHBvc3RlZCkKCiAgICAq
IGxpYnhsIHN0YWJsZSBBUEkKCiAgICAgICAgKiBsaWJ4bF93YWl0X2Zvcl9mcmVlX21lbW9yeS9s
aWJ4bF93YWl0X2Zvcl9tZW1vcnlfdGFyZ2V0LgogICAgICAgICAgSW50ZXJmYWNlIG5lZWRzIGFu
IG92ZXJoYXVsLCByZWxhdGVkIHRvCiAgICAgICAgICBsb2NraW5nL3NlcmlhbGl6YXRpb24gb3Zl
ciBkb21haW4gY3JlYXRlLiBJYW5KIHRvIGFkZCBub3RlCiAgICAgICAgICBhYm91dCB0aGlzIGlu
dGVyZmFjZSBiZWluZyBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVyCiAgICAgICAgICB0
byA0LjMuCgogICAgICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoK
CiAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQgYmUgZWFzeSBvbmNlCiAg
ICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0gZG9uZS4gVGhpcyBpcyBiYXNpY2FsbHkgYSBo
ZWxwZXIKICAgICAgICAgICAgICBmdW5jdGlvbiBhbmQgaXRzIGZ1bmN0aW9uYWxpdHkgY2FuIGJl
IGltcGxlbWVudGVkIGluCiAgICAgICAgICAgICAgdGVybXMgb2YgdGhlIGxpYnhsX2Rpc2tfKiBp
bnRlcmZhY2VzLiBJZiB0aGlzIGlzIG5vdAogICAgICAgICAgICAgIGRvbmUgaW4gdGltZSB3ZSBz
aG91bGQgZG9jdW1lbnQgYXMgYSBzdWJzdGFuZGFyZAogICAgICAgICAgICAgIGludGVyZmFjZSB3
aGljaCBpcyBzdWJqZWN0IHRvIGNoYW5nZSBwb3N0IDQuMi4KCiAgICAqIHhsLmNmZyg1KSBkb2N1
bWVudGF0aW9uIHBhdGNoIGZvciBxZW11LXVwc3RyZWFtCiAgICAgIHZpZGVvcmFtL3ZpZGVvbWVt
IHN1cHBvcnQ6CiAgICAgIGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRl
dmVsLzIwMTItMDUvbXNnMDAyNTAuaHRtbAogICAgICBxZW11LXVwc3RyZWFtIGRvZXNuJ3Qgc3Vw
cG9ydCBzcGVjaWZ5aW5nIHZpZGVvbWVtIHNpemUgZm9yIHRoZQogICAgICBIVk0gZ3Vlc3QgY2ly
cnVzL3N0ZHZnYS4gIChidXQgdGhpcyB3b3JrcyB3aXRoCiAgICAgIHFlbXUteGVuLXRyYWRpdGlv
bmFsKS4gKFBhc2kgS8Okcmtrw6RpbmVuKQoKICAgICogcWVtdS11cHN0cmVhbSBmb3IgTmV0QlNE
IChSb2dlciwgcGF0Y2ggY29tbWl0ZWQgdG8gTmV0QlNECiAgICAgIGtlcm5lbCwgYXdhaXRpbmcg
YXBwcm92YWwsIERPTkUgYXMgZmFyIGFzIFhlbiA0LjIgaXMgY29uY2VybmVkKQoKICAgICogW0JV
R10gbG9uZyBzdG9wIGR1cmluZyB0aGUgZ3Vlc3QgYm9vdCBwcm9jZXNzIHdpdGggcWNvdyBpbWFn
ZSwKICAgICAgcmVwb3J0ZWQgYnkgSW50ZWw6IGh0dHA6Ly9idWd6aWxsYS54ZW4ub3JnL2J1Z3pp
bGxhL3Nob3dfYnVnLmNnaT9pZD0xODIxCgogICAgKiBbQlVHXSB2Y3B1LXNldCBkb2Vzbid0IHRh
a2UgZWZmZWN0IG9uIGd1ZXN0LCByZXBvcnRlZCBieSBJbnRlbDoKICAgICAgaHR0cDovL2J1Z3pp
bGxhLnhlbi5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTE4MjIKCiAgICAqIExvYWQgYmxr
dGFwIGRyaXZlciBmcm9tIHhlbmNvbW1vbnMgaW5pdHNjcmlwdCBpZiBhdmFpbGFibGUsIHRocmVh
ZCBhdDoKICAgICAgPGRiNjE0ZTkyZmFmNzQzZTIwYjNmLjEzMzcwOTY5NzdAa29kbzI+LiBUbyBi
ZSBmaXhlZCBtb3JlCiAgICAgIHByb3Blcmx5IGluIDQuMy4gKFBhdGNoIHBvc3RlZCwgZGlzY3Vz
c2lvbiwgcGxhbiB0byB0YWtlIHNpbXBsZQogICAgICB4ZW5jb21tb25zIHBhdGNoIGZvciA0LjIg
YW5kIHJldmlzdCBmb3IgNC4zKQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Jun 20 11:35:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShJBs-0001pt-M6; Wed, 20 Jun 2012 11:35: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 1ShJBr-0001po-Bw
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:35:15 +0000
Received: from [85.158.139.83:30686] by server-10.bemta-5.messagelabs.com id
	38/41-02190-275B1EF4; Wed, 20 Jun 2012 11:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340192111!21380078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20098 invoked from network); 20 Jun 2012 11:35:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 11:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13121809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 11: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.213.0;
	Wed, 20 Jun 2012 12:35:12 +0100
Message-ID: <1340192110.4906.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 12:35:10 +0100
In-Reply-To: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 08:36 +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The text looks fine to me, thanks. One comment inline below.

Did you consider using markdown syntax to get a somewhat formatted HTML
output? You'd basically just need to s/.txt/.markdown/ and tweak things
a bit to use the markdown syntax (which is designed to mostly follow the
sorts of ASCII typographical conventions which people use anyway).

http://daringfireball.net/projects/markdown/

> --- /dev/null
> +++ b/docs/misc/efi.txt
> @@ -0,0 +1,52 @@
> +Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, as
> +4.5.x was probably never really tested for this purpose) and binutils 2.22 or
> +newer. Additionally, the binutils build must be configured to include support
> +for the x86_64-pep emulation (i.e. --enable-targets=x86_64-pep or an option of
> +equivalent effect should be passed to the configure script).
> +
> +Once built, "make install-xen" can place the resulting binary directly int
> +the EFI boot partition, provided EFI_VENDOR is set (and EFI_MOUNTPOINT is
> +overridden as needed, should the default of /boot/efi not match the target
> +system).
> +
> +The binary itself will require a configuration file (names with the .efi
> +extension of the binary's name replaced by .cfg, and - until an existing file
> +is found - trailing name components dropped at '.', '-', and '_' separators
> +will be tried) to be present in the same directory as the binary. (To
> +illustrate the name handling, a binary named xen-4.2-unstable.efi would try
> +xen-4.2-unstable.cfg, xen-4.2.cfg, xen-4.cfg, and xen.cfg in order.) One can
> +override this with a command line option ("-cfg=<filename>").
> +
> +The configuration file consists of one or more sections headed by a section
> +name enclosed in square brackets, with individual values specified in each
> +section. A section named [global] is treated specially to allow certain
> +settings to apply to all other sections (or to provide defaults for certain
> +settings in case individual sections don't specify them). A typical file would
> +thus look like this ('#' serving as comment character):
> +
> +**************************example begin******************************
> +[global]
> +default=sle11sp2
> +
> +[sle11sp2]
> +options=console=vga,com1 com1=57600 loglvl=all noreboot
> +kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
> +ramdisk=initrd-3.0.31-0.4-xen
> +**************************example end********************************
> +
> +Other values to specify are

As well as "Other values" I think you need to document the ones above as
well.

> +
> +video=gfx-<xres>[x<yres>[x<depth>]]
> +(specifying a video mode to select if available; in case of problems the
> +"-basevideo" command line option can be used to skip altering video modes)
> +
> +xsm=<filename>
> +(specifying an XSM module to load)
> +
> +ucode=<filename>
> +(specifying a CPU microcode blob to load)
> +
> +Filenames must be specified relative to the location of the EFI binary.
> +
> +Extra options to be passed to Xen can also be specified on the command line,
> +following a "--" separator option.
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 11:35:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShJBs-0001pt-M6; Wed, 20 Jun 2012 11:35: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 1ShJBr-0001po-Bw
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:35:15 +0000
Received: from [85.158.139.83:30686] by server-10.bemta-5.messagelabs.com id
	38/41-02190-275B1EF4; Wed, 20 Jun 2012 11:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340192111!21380078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20098 invoked from network); 20 Jun 2012 11:35:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 11:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13121809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 11: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.213.0;
	Wed, 20 Jun 2012 12:35:12 +0100
Message-ID: <1340192110.4906.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 12:35:10 +0100
In-Reply-To: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 08:36 +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The text looks fine to me, thanks. One comment inline below.

Did you consider using markdown syntax to get a somewhat formatted HTML
output? You'd basically just need to s/.txt/.markdown/ and tweak things
a bit to use the markdown syntax (which is designed to mostly follow the
sorts of ASCII typographical conventions which people use anyway).

http://daringfireball.net/projects/markdown/

> --- /dev/null
> +++ b/docs/misc/efi.txt
> @@ -0,0 +1,52 @@
> +Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, as
> +4.5.x was probably never really tested for this purpose) and binutils 2.22 or
> +newer. Additionally, the binutils build must be configured to include support
> +for the x86_64-pep emulation (i.e. --enable-targets=x86_64-pep or an option of
> +equivalent effect should be passed to the configure script).
> +
> +Once built, "make install-xen" can place the resulting binary directly int
> +the EFI boot partition, provided EFI_VENDOR is set (and EFI_MOUNTPOINT is
> +overridden as needed, should the default of /boot/efi not match the target
> +system).
> +
> +The binary itself will require a configuration file (names with the .efi
> +extension of the binary's name replaced by .cfg, and - until an existing file
> +is found - trailing name components dropped at '.', '-', and '_' separators
> +will be tried) to be present in the same directory as the binary. (To
> +illustrate the name handling, a binary named xen-4.2-unstable.efi would try
> +xen-4.2-unstable.cfg, xen-4.2.cfg, xen-4.cfg, and xen.cfg in order.) One can
> +override this with a command line option ("-cfg=<filename>").
> +
> +The configuration file consists of one or more sections headed by a section
> +name enclosed in square brackets, with individual values specified in each
> +section. A section named [global] is treated specially to allow certain
> +settings to apply to all other sections (or to provide defaults for certain
> +settings in case individual sections don't specify them). A typical file would
> +thus look like this ('#' serving as comment character):
> +
> +**************************example begin******************************
> +[global]
> +default=sle11sp2
> +
> +[sle11sp2]
> +options=console=vga,com1 com1=57600 loglvl=all noreboot
> +kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
> +ramdisk=initrd-3.0.31-0.4-xen
> +**************************example end********************************
> +
> +Other values to specify are

As well as "Other values" I think you need to document the ones above as
well.

> +
> +video=gfx-<xres>[x<yres>[x<depth>]]
> +(specifying a video mode to select if available; in case of problems the
> +"-basevideo" command line option can be used to skip altering video modes)
> +
> +xsm=<filename>
> +(specifying an XSM module to load)
> +
> +ucode=<filename>
> +(specifying a CPU microcode blob to load)
> +
> +Filenames must be specified relative to the location of the EFI binary.
> +
> +Extra options to be passed to Xen can also be specified on the command line,
> +following a "--" separator option.
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 11:45:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:45: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 1ShJLR-00021q-RK; Wed, 20 Jun 2012 11:45:09 +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 1ShJLQ-00021l-DH
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:45:08 +0000
Received: from [85.158.143.99:25521] by server-3.bemta-4.messagelabs.com id
	56/35-05808-3C7B1EF4; Wed, 20 Jun 2012 11:45:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340192704!18471831!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9233 invoked from network); 20 Jun 2012 11:45:06 -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 Jun 2012 11:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336363200"; d="scan'208";a="28748072"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 07:45:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 07:45:04 -0400
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 1ShJKB-0002zL-DG	for
	xen-devel@lists.xen.org; Wed, 20 Jun 2012 12:43:51 +0100
Message-ID: <4FE1B777.4010407@citrix.com>
Date: Wed, 20 Jun 2012 12:43:51 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.2
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAvMDYvMTIgMTI6MjksIElhbiBDYW1wYmVsbCB3cm90ZToKPiBBIGJpdCBsYXRlIHRoaXMg
d2VlaywgZHVlIHRvIG15IGJlaW5nIG9uIHZhY2F0aW9uLiBOb3JtYWwgTW9uZGF5Cj4gc2Vydmlj
ZSBzaG91bGQgYmUgcmVzdW1lZCBuZXh0IHdlZWsuCj4KPiBQbGFuIGZvciBhIDQuMiByZWxlYXNl
Ogo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMv
bXNnMDA3OTMuaHRtbAo+Cj4gVGhlIHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgo+Cj4gMTkgTWFy
Y2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgo+IDIgQXByaWwgICAgICAgICAtLSBG
ZWF0dXJlIEZyZWV6ZQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDw8IFdFIEFSRSBIRVJFCj4gV2hlbiBJdCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2Ug
Y2FuZGlkYXRlCj4gV2Vla2x5ICAgICAgICAgIC0tIFJDTisxIHVudGlsIHJlbGVhc2UKPgo+IFRo
ZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLgo+Cj4gSWYgeW91IGFyZSBhd2FyZSBvZiBhbnkg
YnVncyB3aGljaCBtdXN0L3Nob3VsZCBiZSBmaXhlZCBmb3IgNC4yIHRoZW4KPiBwbGVhc2UgcmVw
bHkgdG8gdGhpcyB0aHJlYWQgKG90aGVyd2lzZSBJIG1heSBub3QgcmVtZW1iZXIgdG8gcGljayB0
aGVtCj4gdXAgbmV4dCB3ZWVrKQo+Cj4gQXMgd2VsbCBhcyBbQlVHXXMgSSd2ZSBhbHNvIHN0YXJ0
ZWQgdHJhY2tpbmcgdGhpbmdzIHRvIFtDSEVDS10gYmVmb3JlCj4gdGhlIHJlbGVhc2UuIFRoZXNl
IGFyZSBiYXNpY2FsbHkgZm9yIHRoaW5ncyB3aGljaCB3ZSBvdWdodCB0byBjb25maXJtCj4gZHVy
aW5nIHRoZSBSQyBjeWNsZXMgZS5nLiB0aGluZ3Mgd2hpY2ggYXJlIG5vdCBjb3ZlcmVkIGJ5IGF1
dG9tYXRlZAo+IHRlc3RpbmcuCj4KPiBQZXIgdGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBjYXNl
IHdpbGwgbm93IGhhdmUgdG8gYmUgbWFkZSBhcyB0byB3aHkKPiBuZXcgaXRlbXMgc2hvdWxkIGJl
IGFkZGVkIHRvIHRoZSBsaXN0LCBlc3BlY2lhbGx5IGFzIGEgYmxvY2tlciwgcmF0aGVyCj4gdGhh
biBkZWZlcnJlZCB0byA0LjMuCj4KPiBoeXBlcnZpc29yLCBibG9ja2VyczoKPgo+ICAgICAqIE5v
bmUKCk5vdCBjZXJ0YWluIGlmIHRoaXMgaXMgYSBibG9ja2VyIG9yIG5pY2UtdG8taGF2ZSwgYnV0
IHdlIGhhdmUgaWRlbnRpZmllZAphIHJlZ3Jlc3Npb24gd2l0aCBYZW4ncyBhYmlsaXR5IHRvIGJv
b3QsIHN1cHBlY3RlZGx5IGR1ZSB0byBjL3MKMjUzMzY6ZWRkN2M3YWQxYWQyICJ4ODY6IGFkanVz
dCBoYW5kbGluZyBvZiBpbnRlcnJ1cHRzIGNvbWluZyBpbiB2aWEKbGVnYWN5IHZlY3RvcnMiIG9u
IEFNRCBoYXJkd2FyZSB3aXRoIGFuIE1QLUJJT1MgYnVnIGNsYWltaW5nIHRoYXQgdGhlClBJVCBp
cyBub3QgY29ubmVjdGVkIHRocm91Z2ggdGhlIElPLUFQSUMuICBGaXhpbmcgdGhpcyBpcyBuZXh0
IG9uIG15CnRvZG8gbGlzdCwgYW5kIEkgaG9wZSB0byBoYXZlIGEgc29sdXRpb24gYXZhaWxhYmxl
IGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsuCgp+QW5kcmV3Cgo+ICAKPiB0b29scywgYmxvY2tlcnM6
Cj4KPiAgICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmlu
ZSBhIHN0YWJsZSBBUEkKPiAgICAgICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJl
bHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCj4gICAgICAgdGhpcyBhcmU6Cj4KPiAgICAg
ICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKPgo+ICAgICAgICAg
ICAgICogbGlieGxfZG9tYWluX3N1c3BlbmQuIE1vdmUgeGNfZG9tYWluX3NhdmUvcmVzdG9yZSBp
bnRvIGEKPiAgICAgICAgICAgICAgIHNlcGFyYXRlIHByb2Nlc3MgKElhbiBKYWNrc29uLCBwYXRj
aGVzIHJldmlld3MgYW5kIHJlcG9zdGVkKS4KPgo+ICAgICAgICAgICAgICogbGlieGxfZGV2aWNl
X3tkaXNrLG5pYyx2a2IsYWRkLHBjaX1fYWRkIChhbmQKPiAgICAgICAgICAgICAgIHJlbW92ZSku
IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzIHBvc3RlZCBmb3IgZGlzayAmIG5pYywgdmtiCj4g
ICAgICAgICAgICAgICB0cml2aWFsLCBub3QgbG9va2VkIGF0IHBjaSB5ZXQpCj4KPiAgICAgICAg
ICogTElCWExfTklDX1RZUEUgZW51bSBuYW1lcyBhcmUgY29uZnVzaW5nLiAoUm9nZXIsIGluY2x1
ZGVkIGluCj4gICAgICAgICAgIGNhbGxpbmcgaG90cGx1ZyBzY3JpcHRzIHNlcmllcykKPgo+ICAg
ICAgICAgKiB1c2UgbGlieGxfY3B1bWFwIGZvciBiX2luZm8uYXZhaWxfY3B1cyBpbnN0ZWFkIG9m
IGFuIGludCwKPiAgICAgICAgICAgdGhpcyBhbGxvd3Mgc2V0dGluZyBtb3JlIHRoYW4gMzEgQ1BV
UyAoWWFuZyBaIFpoYW5nLCBwYXRjaGVzCj4gICAgICAgICAgIHBvc3RlZCwgYXdhaXRpbmcgYSBy
ZXBvc3QpCj4KPiAgICAgICAgICogdXNlIGFuIGVudW0gZm9yIFZHQSBpbnRlcmZhY2UgdHlwZSAo
ZS5nLiBDaXJydXMsCj4gICAgICAgICAgIFN0ZFZHQSkuIEFsbG93cyBmb3IgUVhMIHN1cHBvcnQg
KGluIDQuMykuIChaaG91IFBlbmcsCj4gICAgICAgICAgIGF3YWl0aW5nIHJlcG9zdCkKPgo+ICAg
ICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPgo+ICAgICAgICAgKiBbQlVHXSBjYW5ub3Qg
Y3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZSBvbiBIVk0gZ3Vlc3QsCj4gICAgICAgICAgIHJl
cG9ydGVkIGJ5IEZhYmlvIEZhbnRvbmkgaW4gPDRGOTY3MkRELjIwODA5MDJAdGlzY2FsaS5pdD4K
Pgo+ICAgICAgICAgKiBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IHRyeSB0byBzZWxlY3QgYSAoc2V0
IG9mKSBub2RlKHMpIG9uCj4gICAgICAgICAgIHdoaWNoIHRvIGNyZWF0ZSBhIFZNIGFuZCBwaW4g
aXRzIHZjcHVzIHRoZXJlLiAoRGFyaW8KPiAgICAgICAgICAgRmFnZ2lvbGksIHYyIHBvc3RlZCkK
Pgo+ICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hl
cyBhbHJlYWR5IGluCj4gICAgICAgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11
bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiAgICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwu
Cj4KPiAgICAgKiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsIChMaW51eCBhbmQgTmV0
QlNEKSAoUm9nZXIgUGF1Cj4gICAgICAgTW9ubsOpLCB2NiBwb3N0ZWQsIGF3YWl0aW5nIHJldmll
dykKPgo+ICAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3Rw
bHVnIHNjcmlwdCAoUm9nZXIKPiAgICAgICBQYXUgTW9ubsOpLCAianVzdCBiZSBhIG1hdHRlciBv
ZiByZW1vdmluZyBhbiAiaWYiIikKPgo+ICAgICAqIEFkanVzdG1lbnRzIG5lZWRlZCBmb3IgcWRp
c2sgYmFja2VuZCB0byB3b3JrIG9uIG5vbi1wdm9wcyBMaW51eC4KPiAgICAgICAicWVtdS94ZW5k
aXNrOiBzZXQgbWF4aW11bSBudW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4KPiAgICAg
ICBCZXVsaWNoLCBwYXRjaCBjb21taXR0ZWQgdG8gcWVtdS14ZW4tdXBzdHJlYW0sIHBlbmRpbmcg
Zm9yCj4gICAgICAgcWVtdS14ZW4tdHJhZGl0aW9uYWwpCj4KPiAgICAgKiBbQ0hFQ0tdIENvbmZp
cm0gdGhhdCBtaWdyYXRpb24gZnJvbSBYZW4gNC4xIC0+IDQuMiB3b3Jrcy4KPgo+ICAgICAqIFtC
VUddIExJQkxFQUZESVIgZXQgYWwgYW5kIGxpYmZzaW1hZ2UgZG8gdGhlIHdyb25nIHRoaW5nIG9u
Cj4gICAgICAgbW9kZXJuIERlYmlhbi9VYnVudHUgdy8gbXVsdGlhcmNoIGNhcGFiaWxpdGllcyAo
TWF0dCBXaWxzb24sCj4gICAgICAgcGF0Y2ggcG9zdGVkKQo+Cj4gICAgICogW0NIRUNLXSBUZXN0
IHN0dWIgZG9tYWlucyB3b3JrIHdpdGggeGwuCj4KPiBoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6
Cj4KPiAgICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwLCBh
bmQgcmV2aWV3ZWQKPiAgICAgICBhd2FpdGluZyByZXBvc3QpCj4KPiB0b29scywgbmljZSB0byBo
YXZlOgo+Cj4gICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgo+Cj4gICAgICAgICAqIEFj
Y2VwdCAieGwgY3IgL2Rldi9udWxsIHBhcmFtPXZhbHVlIiB0byBwcm92aWRlIGFsbCBjb25maWcK
PiAgICAgICAgICAgb24gdGhlIGNvbW1hbmQgbGluZSAoVy4gTWljaGFlbCBQZXR1bGxvLCBwYXRj
aCBwb3N0ZWQpCj4KPiAgICAgKiBsaWJ4bCBzdGFibGUgQVBJCj4KPiAgICAgICAgICogbGlieGxf
d2FpdF9mb3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5X3RhcmdldC4KPiAgICAg
ICAgICAgSW50ZXJmYWNlIG5lZWRzIGFuIG92ZXJoYXVsLCByZWxhdGVkIHRvCj4gICAgICAgICAg
IGxvY2tpbmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUuIElhbkogdG8gYWRkIG5v
dGUKPiAgICAgICAgICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVpbmcgc3Vic3RhbmRhcmQgYnV0
IG90aGVyd2lzZSBkZWZlcgo+ICAgICAgICAgICB0byA0LjMuCj4KPiAgICAgICAgICogSW50ZXJm
YWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKPgo+ICAgICAgICAgICAgICogbGlieGxf
Y2Ryb21faW5zZXJ0LiBTaG91bGQgYmUgZWFzeSBvbmNlCj4gICAgICAgICAgICAgICBkaXNrX3th
ZGQscmVtb3ZlfSBkb25lLiBUaGlzIGlzIGJhc2ljYWxseSBhIGhlbHBlcgo+ICAgICAgICAgICAg
ICAgZnVuY3Rpb24gYW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRlZCBpbgo+
ICAgICAgICAgICAgICAgdGVybXMgb2YgdGhlIGxpYnhsX2Rpc2tfKiBpbnRlcmZhY2VzLiBJZiB0
aGlzIGlzIG5vdAo+ICAgICAgICAgICAgICAgZG9uZSBpbiB0aW1lIHdlIHNob3VsZCBkb2N1bWVu
dCBhcyBhIHN1YnN0YW5kYXJkCj4gICAgICAgICAgICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3Vi
amVjdCB0byBjaGFuZ2UgcG9zdCA0LjIuCj4KPiAgICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlv
biBwYXRjaCBmb3IgcWVtdS11cHN0cmVhbQo+ICAgICAgIHZpZGVvcmFtL3ZpZGVvbWVtIHN1cHBv
cnQ6Cj4gICAgICAgaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwv
MjAxMi0wNS9tc2cwMDI1MC5odG1sCj4gICAgICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBv
cnQgc3BlY2lmeWluZyB2aWRlb21lbSBzaXplIGZvciB0aGUKPiAgICAgICBIVk0gZ3Vlc3QgY2ly
cnVzL3N0ZHZnYS4gIChidXQgdGhpcyB3b3JrcyB3aXRoCj4gICAgICAgcWVtdS14ZW4tdHJhZGl0
aW9uYWwpLiAoUGFzaSBLw6Rya2vDpGluZW4pCj4KPiAgICAgKiBxZW11LXVwc3RyZWFtIGZvciBO
ZXRCU0QgKFJvZ2VyLCBwYXRjaCBjb21taXRlZCB0byBOZXRCU0QKPiAgICAgICBrZXJuZWwsIGF3
YWl0aW5nIGFwcHJvdmFsLCBET05FIGFzIGZhciBhcyBYZW4gNC4yIGlzIGNvbmNlcm5lZCkKPgo+
ICAgICAqIFtCVUddIGxvbmcgc3RvcCBkdXJpbmcgdGhlIGd1ZXN0IGJvb3QgcHJvY2VzcyB3aXRo
IHFjb3cgaW1hZ2UsCj4gICAgICAgcmVwb3J0ZWQgYnkgSW50ZWw6IGh0dHA6Ly9idWd6aWxsYS54
ZW4ub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0xODIxCj4KPiAgICAgKiBbQlVHXSB2Y3B1
LXNldCBkb2Vzbid0IHRha2UgZWZmZWN0IG9uIGd1ZXN0LCByZXBvcnRlZCBieSBJbnRlbDoKPiAg
ICAgICBodHRwOi8vYnVnemlsbGEueGVuLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MTgy
Mgo+Cj4gICAgICogTG9hZCBibGt0YXAgZHJpdmVyIGZyb20geGVuY29tbW9ucyBpbml0c2NyaXB0
IGlmIGF2YWlsYWJsZSwgdGhyZWFkIGF0Ogo+ICAgICAgIDxkYjYxNGU5MmZhZjc0M2UyMGIzZi4x
MzM3MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4ZWQgbW9yZQo+ICAgICAgIHByb3Blcmx5IGluIDQu
My4gKFBhdGNoIHBvc3RlZCwgZGlzY3Vzc2lvbiwgcGxhbiB0byB0YWtlIHNpbXBsZQo+ICAgICAg
IHhlbmNvbW1vbnMgcGF0Y2ggZm9yIDQuMiBhbmQgcmV2aXN0IGZvciA0LjMpCj4KPgo+Cj4KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAoKLS0gCkFuZHJldyBDb29wZXIgLSBEb20wIEtlcm5lbCBFbmdpbmVl
ciwgQ2l0cml4IFhlblNlcnZlcgpUOiArNDQgKDApMTIyMyAyMjUgOTAwLCBodHRwOi8vd3d3LmNp
dHJpeC5jb20KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 20 11:45:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:45: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 1ShJLR-00021q-RK; Wed, 20 Jun 2012 11:45:09 +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 1ShJLQ-00021l-DH
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:45:08 +0000
Received: from [85.158.143.99:25521] by server-3.bemta-4.messagelabs.com id
	56/35-05808-3C7B1EF4; Wed, 20 Jun 2012 11:45:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340192704!18471831!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9233 invoked from network); 20 Jun 2012 11:45:06 -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 Jun 2012 11:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336363200"; d="scan'208";a="28748072"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 07:45:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 07:45:04 -0400
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 1ShJKB-0002zL-DG	for
	xen-devel@lists.xen.org; Wed, 20 Jun 2012 12:43:51 +0100
Message-ID: <4FE1B777.4010407@citrix.com>
Date: Wed, 20 Jun 2012 12:43:51 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.2
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAvMDYvMTIgMTI6MjksIElhbiBDYW1wYmVsbCB3cm90ZToKPiBBIGJpdCBsYXRlIHRoaXMg
d2VlaywgZHVlIHRvIG15IGJlaW5nIG9uIHZhY2F0aW9uLiBOb3JtYWwgTW9uZGF5Cj4gc2Vydmlj
ZSBzaG91bGQgYmUgcmVzdW1lZCBuZXh0IHdlZWsuCj4KPiBQbGFuIGZvciBhIDQuMiByZWxlYXNl
Ogo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDMv
bXNnMDA3OTMuaHRtbAo+Cj4gVGhlIHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgo+Cj4gMTkgTWFy
Y2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgo+IDIgQXByaWwgICAgICAgICAtLSBG
ZWF0dXJlIEZyZWV6ZQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDw8IFdFIEFSRSBIRVJFCj4gV2hlbiBJdCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2Ug
Y2FuZGlkYXRlCj4gV2Vla2x5ICAgICAgICAgIC0tIFJDTisxIHVudGlsIHJlbGVhc2UKPgo+IFRo
ZSB1cGRhdGVkIFRPRE8gbGlzdCBmb2xsb3dzLgo+Cj4gSWYgeW91IGFyZSBhd2FyZSBvZiBhbnkg
YnVncyB3aGljaCBtdXN0L3Nob3VsZCBiZSBmaXhlZCBmb3IgNC4yIHRoZW4KPiBwbGVhc2UgcmVw
bHkgdG8gdGhpcyB0aHJlYWQgKG90aGVyd2lzZSBJIG1heSBub3QgcmVtZW1iZXIgdG8gcGljayB0
aGVtCj4gdXAgbmV4dCB3ZWVrKQo+Cj4gQXMgd2VsbCBhcyBbQlVHXXMgSSd2ZSBhbHNvIHN0YXJ0
ZWQgdHJhY2tpbmcgdGhpbmdzIHRvIFtDSEVDS10gYmVmb3JlCj4gdGhlIHJlbGVhc2UuIFRoZXNl
IGFyZSBiYXNpY2FsbHkgZm9yIHRoaW5ncyB3aGljaCB3ZSBvdWdodCB0byBjb25maXJtCj4gZHVy
aW5nIHRoZSBSQyBjeWNsZXMgZS5nLiB0aGluZ3Mgd2hpY2ggYXJlIG5vdCBjb3ZlcmVkIGJ5IGF1
dG9tYXRlZAo+IHRlc3RpbmcuCj4KPiBQZXIgdGhlIHJlbGVhc2UgcGxhbiBhIHN0cm9uZyBjYXNl
IHdpbGwgbm93IGhhdmUgdG8gYmUgbWFkZSBhcyB0byB3aHkKPiBuZXcgaXRlbXMgc2hvdWxkIGJl
IGFkZGVkIHRvIHRoZSBsaXN0LCBlc3BlY2lhbGx5IGFzIGEgYmxvY2tlciwgcmF0aGVyCj4gdGhh
biBkZWZlcnJlZCB0byA0LjMuCj4KPiBoeXBlcnZpc29yLCBibG9ja2VyczoKPgo+ICAgICAqIE5v
bmUKCk5vdCBjZXJ0YWluIGlmIHRoaXMgaXMgYSBibG9ja2VyIG9yIG5pY2UtdG8taGF2ZSwgYnV0
IHdlIGhhdmUgaWRlbnRpZmllZAphIHJlZ3Jlc3Npb24gd2l0aCBYZW4ncyBhYmlsaXR5IHRvIGJv
b3QsIHN1cHBlY3RlZGx5IGR1ZSB0byBjL3MKMjUzMzY6ZWRkN2M3YWQxYWQyICJ4ODY6IGFkanVz
dCBoYW5kbGluZyBvZiBpbnRlcnJ1cHRzIGNvbWluZyBpbiB2aWEKbGVnYWN5IHZlY3RvcnMiIG9u
IEFNRCBoYXJkd2FyZSB3aXRoIGFuIE1QLUJJT1MgYnVnIGNsYWltaW5nIHRoYXQgdGhlClBJVCBp
cyBub3QgY29ubmVjdGVkIHRocm91Z2ggdGhlIElPLUFQSUMuICBGaXhpbmcgdGhpcyBpcyBuZXh0
IG9uIG15CnRvZG8gbGlzdCwgYW5kIEkgaG9wZSB0byBoYXZlIGEgc29sdXRpb24gYXZhaWxhYmxl
IGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsuCgp+QW5kcmV3Cgo+ICAKPiB0b29scywgYmxvY2tlcnM6
Cj4KPiAgICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmlu
ZSBhIHN0YWJsZSBBUEkKPiAgICAgICB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJl
bHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCj4gICAgICAgdGhpcyBhcmU6Cj4KPiAgICAg
ICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKPgo+ICAgICAgICAg
ICAgICogbGlieGxfZG9tYWluX3N1c3BlbmQuIE1vdmUgeGNfZG9tYWluX3NhdmUvcmVzdG9yZSBp
bnRvIGEKPiAgICAgICAgICAgICAgIHNlcGFyYXRlIHByb2Nlc3MgKElhbiBKYWNrc29uLCBwYXRj
aGVzIHJldmlld3MgYW5kIHJlcG9zdGVkKS4KPgo+ICAgICAgICAgICAgICogbGlieGxfZGV2aWNl
X3tkaXNrLG5pYyx2a2IsYWRkLHBjaX1fYWRkIChhbmQKPiAgICAgICAgICAgICAgIHJlbW92ZSku
IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzIHBvc3RlZCBmb3IgZGlzayAmIG5pYywgdmtiCj4g
ICAgICAgICAgICAgICB0cml2aWFsLCBub3QgbG9va2VkIGF0IHBjaSB5ZXQpCj4KPiAgICAgICAg
ICogTElCWExfTklDX1RZUEUgZW51bSBuYW1lcyBhcmUgY29uZnVzaW5nLiAoUm9nZXIsIGluY2x1
ZGVkIGluCj4gICAgICAgICAgIGNhbGxpbmcgaG90cGx1ZyBzY3JpcHRzIHNlcmllcykKPgo+ICAg
ICAgICAgKiB1c2UgbGlieGxfY3B1bWFwIGZvciBiX2luZm8uYXZhaWxfY3B1cyBpbnN0ZWFkIG9m
IGFuIGludCwKPiAgICAgICAgICAgdGhpcyBhbGxvd3Mgc2V0dGluZyBtb3JlIHRoYW4gMzEgQ1BV
UyAoWWFuZyBaIFpoYW5nLCBwYXRjaGVzCj4gICAgICAgICAgIHBvc3RlZCwgYXdhaXRpbmcgYSBy
ZXBvc3QpCj4KPiAgICAgICAgICogdXNlIGFuIGVudW0gZm9yIFZHQSBpbnRlcmZhY2UgdHlwZSAo
ZS5nLiBDaXJydXMsCj4gICAgICAgICAgIFN0ZFZHQSkuIEFsbG93cyBmb3IgUVhMIHN1cHBvcnQg
KGluIDQuMykuIChaaG91IFBlbmcsCj4gICAgICAgICAgIGF3YWl0aW5nIHJlcG9zdCkKPgo+ICAg
ICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPgo+ICAgICAgICAgKiBbQlVHXSBjYW5ub3Qg
Y3JlYXRlIGFuIGVtcHR5IENELVJPTSBkcml2ZSBvbiBIVk0gZ3Vlc3QsCj4gICAgICAgICAgIHJl
cG9ydGVkIGJ5IEZhYmlvIEZhbnRvbmkgaW4gPDRGOTY3MkRELjIwODA5MDJAdGlzY2FsaS5pdD4K
Pgo+ICAgICAgICAgKiBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IHRyeSB0byBzZWxlY3QgYSAoc2V0
IG9mKSBub2RlKHMpIG9uCj4gICAgICAgICAgIHdoaWNoIHRvIGNyZWF0ZSBhIFZNIGFuZCBwaW4g
aXRzIHZjcHVzIHRoZXJlLiAoRGFyaW8KPiAgICAgICAgICAgRmFnZ2lvbGksIHYyIHBvc3RlZCkK
Pgo+ICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hl
cyBhbHJlYWR5IGluCj4gICAgICAgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11
bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiAgICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwu
Cj4KPiAgICAgKiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0cyBmcm9tIHhsIChMaW51eCBhbmQgTmV0
QlNEKSAoUm9nZXIgUGF1Cj4gICAgICAgTW9ubsOpLCB2NiBwb3N0ZWQsIGF3YWl0aW5nIHJldmll
dykKPgo+ICAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3Rw
bHVnIHNjcmlwdCAoUm9nZXIKPiAgICAgICBQYXUgTW9ubsOpLCAianVzdCBiZSBhIG1hdHRlciBv
ZiByZW1vdmluZyBhbiAiaWYiIikKPgo+ICAgICAqIEFkanVzdG1lbnRzIG5lZWRlZCBmb3IgcWRp
c2sgYmFja2VuZCB0byB3b3JrIG9uIG5vbi1wdm9wcyBMaW51eC4KPiAgICAgICAicWVtdS94ZW5k
aXNrOiBzZXQgbWF4aW11bSBudW1iZXIgb2YgZ3JhbnRzIHRvIGJlIHVzZWQiIChKYW4KPiAgICAg
ICBCZXVsaWNoLCBwYXRjaCBjb21taXR0ZWQgdG8gcWVtdS14ZW4tdXBzdHJlYW0sIHBlbmRpbmcg
Zm9yCj4gICAgICAgcWVtdS14ZW4tdHJhZGl0aW9uYWwpCj4KPiAgICAgKiBbQ0hFQ0tdIENvbmZp
cm0gdGhhdCBtaWdyYXRpb24gZnJvbSBYZW4gNC4xIC0+IDQuMiB3b3Jrcy4KPgo+ICAgICAqIFtC
VUddIExJQkxFQUZESVIgZXQgYWwgYW5kIGxpYmZzaW1hZ2UgZG8gdGhlIHdyb25nIHRoaW5nIG9u
Cj4gICAgICAgbW9kZXJuIERlYmlhbi9VYnVudHUgdy8gbXVsdGlhcmNoIGNhcGFiaWxpdGllcyAo
TWF0dCBXaWxzb24sCj4gICAgICAgcGF0Y2ggcG9zdGVkKQo+Cj4gICAgICogW0NIRUNLXSBUZXN0
IHN0dWIgZG9tYWlucyB3b3JrIHdpdGggeGwuCj4KPiBoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6
Cj4KPiAgICAgKiBQb0QgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIChHZW9yZ2UgRHVubGFwLCBh
bmQgcmV2aWV3ZWQKPiAgICAgICBhd2FpdGluZyByZXBvc3QpCj4KPiB0b29scywgbmljZSB0byBo
YXZlOgo+Cj4gICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgo+Cj4gICAgICAgICAqIEFj
Y2VwdCAieGwgY3IgL2Rldi9udWxsIHBhcmFtPXZhbHVlIiB0byBwcm92aWRlIGFsbCBjb25maWcK
PiAgICAgICAgICAgb24gdGhlIGNvbW1hbmQgbGluZSAoVy4gTWljaGFlbCBQZXR1bGxvLCBwYXRj
aCBwb3N0ZWQpCj4KPiAgICAgKiBsaWJ4bCBzdGFibGUgQVBJCj4KPiAgICAgICAgICogbGlieGxf
d2FpdF9mb3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5X3RhcmdldC4KPiAgICAg
ICAgICAgSW50ZXJmYWNlIG5lZWRzIGFuIG92ZXJoYXVsLCByZWxhdGVkIHRvCj4gICAgICAgICAg
IGxvY2tpbmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUuIElhbkogdG8gYWRkIG5v
dGUKPiAgICAgICAgICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVpbmcgc3Vic3RhbmRhcmQgYnV0
IG90aGVyd2lzZSBkZWZlcgo+ICAgICAgICAgICB0byA0LjMuCj4KPiAgICAgICAgICogSW50ZXJm
YWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKPgo+ICAgICAgICAgICAgICogbGlieGxf
Y2Ryb21faW5zZXJ0LiBTaG91bGQgYmUgZWFzeSBvbmNlCj4gICAgICAgICAgICAgICBkaXNrX3th
ZGQscmVtb3ZlfSBkb25lLiBUaGlzIGlzIGJhc2ljYWxseSBhIGhlbHBlcgo+ICAgICAgICAgICAg
ICAgZnVuY3Rpb24gYW5kIGl0cyBmdW5jdGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRlZCBpbgo+
ICAgICAgICAgICAgICAgdGVybXMgb2YgdGhlIGxpYnhsX2Rpc2tfKiBpbnRlcmZhY2VzLiBJZiB0
aGlzIGlzIG5vdAo+ICAgICAgICAgICAgICAgZG9uZSBpbiB0aW1lIHdlIHNob3VsZCBkb2N1bWVu
dCBhcyBhIHN1YnN0YW5kYXJkCj4gICAgICAgICAgICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3Vi
amVjdCB0byBjaGFuZ2UgcG9zdCA0LjIuCj4KPiAgICAgKiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlv
biBwYXRjaCBmb3IgcWVtdS11cHN0cmVhbQo+ICAgICAgIHZpZGVvcmFtL3ZpZGVvbWVtIHN1cHBv
cnQ6Cj4gICAgICAgaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwv
MjAxMi0wNS9tc2cwMDI1MC5odG1sCj4gICAgICAgcWVtdS11cHN0cmVhbSBkb2Vzbid0IHN1cHBv
cnQgc3BlY2lmeWluZyB2aWRlb21lbSBzaXplIGZvciB0aGUKPiAgICAgICBIVk0gZ3Vlc3QgY2ly
cnVzL3N0ZHZnYS4gIChidXQgdGhpcyB3b3JrcyB3aXRoCj4gICAgICAgcWVtdS14ZW4tdHJhZGl0
aW9uYWwpLiAoUGFzaSBLw6Rya2vDpGluZW4pCj4KPiAgICAgKiBxZW11LXVwc3RyZWFtIGZvciBO
ZXRCU0QgKFJvZ2VyLCBwYXRjaCBjb21taXRlZCB0byBOZXRCU0QKPiAgICAgICBrZXJuZWwsIGF3
YWl0aW5nIGFwcHJvdmFsLCBET05FIGFzIGZhciBhcyBYZW4gNC4yIGlzIGNvbmNlcm5lZCkKPgo+
ICAgICAqIFtCVUddIGxvbmcgc3RvcCBkdXJpbmcgdGhlIGd1ZXN0IGJvb3QgcHJvY2VzcyB3aXRo
IHFjb3cgaW1hZ2UsCj4gICAgICAgcmVwb3J0ZWQgYnkgSW50ZWw6IGh0dHA6Ly9idWd6aWxsYS54
ZW4ub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0xODIxCj4KPiAgICAgKiBbQlVHXSB2Y3B1
LXNldCBkb2Vzbid0IHRha2UgZWZmZWN0IG9uIGd1ZXN0LCByZXBvcnRlZCBieSBJbnRlbDoKPiAg
ICAgICBodHRwOi8vYnVnemlsbGEueGVuLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MTgy
Mgo+Cj4gICAgICogTG9hZCBibGt0YXAgZHJpdmVyIGZyb20geGVuY29tbW9ucyBpbml0c2NyaXB0
IGlmIGF2YWlsYWJsZSwgdGhyZWFkIGF0Ogo+ICAgICAgIDxkYjYxNGU5MmZhZjc0M2UyMGIzZi4x
MzM3MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4ZWQgbW9yZQo+ICAgICAgIHByb3Blcmx5IGluIDQu
My4gKFBhdGNoIHBvc3RlZCwgZGlzY3Vzc2lvbiwgcGxhbiB0byB0YWtlIHNpbXBsZQo+ICAgICAg
IHhlbmNvbW1vbnMgcGF0Y2ggZm9yIDQuMiBhbmQgcmV2aXN0IGZvciA0LjMpCj4KPgo+Cj4KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAoKLS0gCkFuZHJldyBDb29wZXIgLSBEb20wIEtlcm5lbCBFbmdpbmVl
ciwgQ2l0cml4IFhlblNlcnZlcgpUOiArNDQgKDApMTIyMyAyMjUgOTAwLCBodHRwOi8vd3d3LmNp
dHJpeC5jb20KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 20 11:54:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:54: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 1ShJTz-0002Ch-R1; Wed, 20 Jun 2012 11:53: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 1ShJTz-0002Cc-1T
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 11:53:59 +0000
Received: from [85.158.143.35:51167] by server-1.bemta-4.messagelabs.com id
	B4/9D-24392-6D9B1EF4; Wed, 20 Jun 2012 11:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340193231!12835822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17987 invoked from network); 20 Jun 2012 11:53:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 11:53:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13122344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 11:53:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 12:53:51 +0100
Message-ID: <1340193230.4906.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Wed, 20 Jun 2012 12:53:50 +0100
In-Reply-To: <CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 14:49 +0100, Shakeel Butt wrote:
> I previously email at xen-user list but didn't get any response. I am
> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.

Apart from the ancient version the main thing which I think is missing
is all the configuration detail specifics.

What are the actual network configuration in dom0 and domU? How are your
bridges setup? What hotplug scripts are you using? Are they triggering?
etc. What I'm looking for here is specific details like the outputs of
"ifconfig -a" "brctl show" the contents of files like ifcfg-*
or /etc/network/interfaces (depending on distro) in all the involved
domains.

Also how are you starting the netback-domU guest (command line), what is
its configuration file?

Same for the other-domU.

How are you attaching the vif to dom0, what command are you running to
make that happen?

When the system is setup with all domains running what does "xenstore-ls
-fp" contain? This will contain details of which device if attached to
which.

> 
> 
> ---------- Forwarded message ----------
> From: Shakeel Butt <shakeel.butt@gmail.com>
> Date: Mon, Jun 18, 2012 at 10:06 AM
> Subject: netback (Network backend) in domU
> To: xen-users@lists.xen.org
> 
> 
> Hi,
> 
> I am trying to setup a domU as a network backend for some other domUs.
> I configured bridge in netback-domU using network-bridge script (not a
> driver domain). I am assigning static ip addresses to all domUs.
> Something like  dom0 <-> netback-domU <-> other-domU.
> 
> In the setup, netback-domU and other-domU are able to ping each other
> but whenever I tried to ping dom0 from other-domU, I get a XEN error
> message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
> dom0 kernel "#### netback grant fails".
> 
> I didn't check if dom0 is trying to pin grant frame of other-domU but
> why dom0 would do it. Please any help will be appreciated.
> 
> BTW does the bridge in dom0 needs to know that one of its interface is
> connected to another bridge in netback-domU? (don't know how or why)
> 
> thanks,
> Shakeel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 11:54:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:54: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 1ShJTz-0002Ch-R1; Wed, 20 Jun 2012 11:53: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 1ShJTz-0002Cc-1T
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 11:53:59 +0000
Received: from [85.158.143.35:51167] by server-1.bemta-4.messagelabs.com id
	B4/9D-24392-6D9B1EF4; Wed, 20 Jun 2012 11:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340193231!12835822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17987 invoked from network); 20 Jun 2012 11:53:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 11:53:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13122344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 11:53:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 12:53:51 +0100
Message-ID: <1340193230.4906.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Wed, 20 Jun 2012 12:53:50 +0100
In-Reply-To: <CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-19 at 14:49 +0100, Shakeel Butt wrote:
> I previously email at xen-user list but didn't get any response. I am
> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.

Apart from the ancient version the main thing which I think is missing
is all the configuration detail specifics.

What are the actual network configuration in dom0 and domU? How are your
bridges setup? What hotplug scripts are you using? Are they triggering?
etc. What I'm looking for here is specific details like the outputs of
"ifconfig -a" "brctl show" the contents of files like ifcfg-*
or /etc/network/interfaces (depending on distro) in all the involved
domains.

Also how are you starting the netback-domU guest (command line), what is
its configuration file?

Same for the other-domU.

How are you attaching the vif to dom0, what command are you running to
make that happen?

When the system is setup with all domains running what does "xenstore-ls
-fp" contain? This will contain details of which device if attached to
which.

> 
> 
> ---------- Forwarded message ----------
> From: Shakeel Butt <shakeel.butt@gmail.com>
> Date: Mon, Jun 18, 2012 at 10:06 AM
> Subject: netback (Network backend) in domU
> To: xen-users@lists.xen.org
> 
> 
> Hi,
> 
> I am trying to setup a domU as a network backend for some other domUs.
> I configured bridge in netback-domU using network-bridge script (not a
> driver domain). I am assigning static ip addresses to all domUs.
> Something like  dom0 <-> netback-domU <-> other-domU.
> 
> In the setup, netback-domU and other-domU are able to ping each other
> but whenever I tried to ping dom0 from other-domU, I get a XEN error
> message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
> dom0 kernel "#### netback grant fails".
> 
> I didn't check if dom0 is trying to pin grant frame of other-domU but
> why dom0 would do it. Please any help will be appreciated.
> 
> BTW does the bridge in dom0 needs to know that one of its interface is
> connected to another bridge in netback-domU? (don't know how or why)
> 
> thanks,
> Shakeel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 11:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:55:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShJVP-0002GR-AH; Wed, 20 Jun 2012 11:55: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 1ShJVN-0002GD-Ni
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:55:25 +0000
Received: from [193.109.254.147:60955] by server-7.bemta-14.messagelabs.com id
	D4/69-29827-C2AB1EF4; Wed, 20 Jun 2012 11:55:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340193322!9818886!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 20 Jun 2012 11:55:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 11:55:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 12:55:22 +0100
Message-Id: <4FE1D674020000780008ACA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 12:56:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340192110.4906.33.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] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-20 at 08:36 +0100, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> The text looks fine to me, thanks. One comment inline below.
> 
> Did you consider using markdown syntax to get a somewhat formatted HTML
> output? You'd basically just need to s/.txt/.markdown/ and tweak things
> a bit to use the markdown syntax (which is designed to mostly follow the
> sorts of ASCII typographical conventions which people use anyway).
> 
> http://daringfireball.net/projects/markdown/ 

I didn't consider this, but I can certainly convert it if that's what
is preferred these days.

>> +**************************example begin******************************
>> +[global]
>> +default=sle11sp2
>> +
>> +[sle11sp2]
>> +options=console=vga,com1 com1=57600 loglvl=all noreboot
>> +kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
>> +ramdisk=initrd-3.0.31-0.4-xen
>> +**************************example end********************************
>> +
>> +Other values to specify are
> 
> As well as "Other values" I think you need to document the ones above as
> well.

Hmm, I would think anyone half way familiar with Xen can interpret
the meaning of the four ones used above without extra explanation.
I don't intend this small piece of text to be a reference document,
but just an aid to people (having got tired of individuals contacting
me namely about how to build xen.efi, despite all the information
being available already - just scattered around).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 11:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 11:55:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShJVP-0002GR-AH; Wed, 20 Jun 2012 11:55: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 1ShJVN-0002GD-Ni
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 11:55:25 +0000
Received: from [193.109.254.147:60955] by server-7.bemta-14.messagelabs.com id
	D4/69-29827-C2AB1EF4; Wed, 20 Jun 2012 11:55:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340193322!9818886!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 20 Jun 2012 11:55:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 11:55:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 12:55:22 +0100
Message-Id: <4FE1D674020000780008ACA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 12:56:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340192110.4906.33.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] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-20 at 08:36 +0100, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> The text looks fine to me, thanks. One comment inline below.
> 
> Did you consider using markdown syntax to get a somewhat formatted HTML
> output? You'd basically just need to s/.txt/.markdown/ and tweak things
> a bit to use the markdown syntax (which is designed to mostly follow the
> sorts of ASCII typographical conventions which people use anyway).
> 
> http://daringfireball.net/projects/markdown/ 

I didn't consider this, but I can certainly convert it if that's what
is preferred these days.

>> +**************************example begin******************************
>> +[global]
>> +default=sle11sp2
>> +
>> +[sle11sp2]
>> +options=console=vga,com1 com1=57600 loglvl=all noreboot
>> +kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
>> +ramdisk=initrd-3.0.31-0.4-xen
>> +**************************example end********************************
>> +
>> +Other values to specify are
> 
> As well as "Other values" I think you need to document the ones above as
> well.

Hmm, I would think anyone half way familiar with Xen can interpret
the meaning of the four ones used above without extra explanation.
I don't intend this small piece of text to be a reference document,
but just an aid to people (having got tired of individuals contacting
me namely about how to build xen.efi, despite all the information
being available already - just scattered around).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 12:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 12: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 1ShJcC-0002dj-AA; Wed, 20 Jun 2012 12:02: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 1ShJcA-0002dY-Hg
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 12:02:26 +0000
Received: from [85.158.139.83:64585] by server-12.bemta-5.messagelabs.com id
	86/DB-25233-1DBB1EF4; Wed, 20 Jun 2012 12:02:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340193744!27926722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27993 invoked from network); 20 Jun 2012 12:02:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 12:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13122558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 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.213.0;
	Wed, 20 Jun 2012 13:02:08 +0100
Message-ID: <1340193727.4906.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 13:02:07 +0100
In-Reply-To: <4FE1D674020000780008ACA4@nat28.tlf.novell.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
	<4FE1D674020000780008ACA4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 12:56 +0100, Jan Beulich wrote:
> >>> On 20.06.12 at 13:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-06-20 at 08:36 +0100, Jan Beulich wrote:
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > The text looks fine to me, thanks. One comment inline below.
> > 
> > Did you consider using markdown syntax to get a somewhat formatted HTML
> > output? You'd basically just need to s/.txt/.markdown/ and tweak things
> > a bit to use the markdown syntax (which is designed to mostly follow the
> > sorts of ASCII typographical conventions which people use anyway).
> > 
> > http://daringfireball.net/projects/markdown/ 
> 
> I didn't consider this, but I can certainly convert it if that's what
> is preferred these days.

I think it's generally preferred for new stuff if the author is willing
(i.e. we'd still rather have .txt than nothing)

> >> +**************************example begin******************************
> >> +[global]
> >> +default=sle11sp2
> >> +
> >> +[sle11sp2]
> >> +options=console=vga,com1 com1=57600 loglvl=all noreboot
> >> +kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
> >> +ramdisk=initrd-3.0.31-0.4-xen
> >> +**************************example end********************************
> >> +
> >> +Other values to specify are
> > 
> > As well as "Other values" I think you need to document the ones above as
> > well.
> 
> Hmm, I would think anyone half way familiar with Xen can interpret
> the meaning of the four ones used above without extra explanation.

The problem is more those which aren't familiar with Xen who think they
want to deploy it using EFI, for whatever reason.

> I don't intend this small piece of text to be a reference document,
> but just an aid to people (having got tired of individuals contacting
> me namely about how to build xen.efi, despite all the information
> being available already - just scattered around).

Sure. Documenting those three options will help with that too, won't it?
I'd expect that getting pestered by those who can't figure that sort of
thing out would be doubly annoying!

I don't think it'll take more than a line to document each one, a link
to http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html might
be useful too.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 12:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 12: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 1ShJcC-0002dj-AA; Wed, 20 Jun 2012 12:02: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 1ShJcA-0002dY-Hg
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 12:02:26 +0000
Received: from [85.158.139.83:64585] by server-12.bemta-5.messagelabs.com id
	86/DB-25233-1DBB1EF4; Wed, 20 Jun 2012 12:02:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340193744!27926722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27993 invoked from network); 20 Jun 2012 12:02:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 12:02:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208";a="13122558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 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.213.0;
	Wed, 20 Jun 2012 13:02:08 +0100
Message-ID: <1340193727.4906.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 13:02:07 +0100
In-Reply-To: <4FE1D674020000780008ACA4@nat28.tlf.novell.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
	<4FE1D674020000780008ACA4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 12:56 +0100, Jan Beulich wrote:
> >>> On 20.06.12 at 13:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-06-20 at 08:36 +0100, Jan Beulich wrote:
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > The text looks fine to me, thanks. One comment inline below.
> > 
> > Did you consider using markdown syntax to get a somewhat formatted HTML
> > output? You'd basically just need to s/.txt/.markdown/ and tweak things
> > a bit to use the markdown syntax (which is designed to mostly follow the
> > sorts of ASCII typographical conventions which people use anyway).
> > 
> > http://daringfireball.net/projects/markdown/ 
> 
> I didn't consider this, but I can certainly convert it if that's what
> is preferred these days.

I think it's generally preferred for new stuff if the author is willing
(i.e. we'd still rather have .txt than nothing)

> >> +**************************example begin******************************
> >> +[global]
> >> +default=sle11sp2
> >> +
> >> +[sle11sp2]
> >> +options=console=vga,com1 com1=57600 loglvl=all noreboot
> >> +kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
> >> +ramdisk=initrd-3.0.31-0.4-xen
> >> +**************************example end********************************
> >> +
> >> +Other values to specify are
> > 
> > As well as "Other values" I think you need to document the ones above as
> > well.
> 
> Hmm, I would think anyone half way familiar with Xen can interpret
> the meaning of the four ones used above without extra explanation.

The problem is more those which aren't familiar with Xen who think they
want to deploy it using EFI, for whatever reason.

> I don't intend this small piece of text to be a reference document,
> but just an aid to people (having got tired of individuals contacting
> me namely about how to build xen.efi, despite all the information
> being available already - just scattered around).

Sure. Documenting those three options will help with that too, won't it?
I'd expect that getting pestered by those who can't figure that sort of
thing out would be doubly annoying!

I don't think it'll take more than a line to document each one, a link
to http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html might
be useful too.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 12:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 12: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 1ShJp4-0002uU-RK; Wed, 20 Jun 2012 12:15:46 +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 1ShJp3-0002uP-52
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 12:15:45 +0000
Received: from [85.158.138.51:45493] by server-8.bemta-3.messagelabs.com id
	93/09-06157-0FEB1EF4; Wed, 20 Jun 2012 12:15:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340194540!20543476!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTcyMDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTcyMDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13238 invoked from network); 20 Jun 2012 12:15:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 12:15:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIiC0MFyD7
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-066-248.pools.arcor-ip.net [88.65.66.248])
	by smtp.strato.de (jorabe mo69) (RZmta 29.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e03409o5KAwKOK
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 14:15:40 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 642E218637; Wed, 20 Jun 2012 14:15:39 +0200 (CEST)
Date: Wed, 20 Jun 2012 14:15:39 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20120620121539.GA18219@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] grant table errors with qemu-xen-traditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 if thats guest or host related, but current xen-unstable
with device_model_version="qemu-xen-traditional" fail to access the
block device properly, both PV and HVM are affected. The guest runs the
upcoming 12.2 kernel, which is based on forward ported xenlinux sources.

I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
qemu-xen-traditional, but that does not seem to help.

Any idea whats wrong?

Olaf

/var/log/xen/qemu-dm-Factory_para_default.log

domid: 29
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
/usr/src/packages/BUILD/xen-4.2.25485/non-dbg/tools/qemu-xen-traditional-dir/hw/xen_blktap.c:628: Init blktap pipes
Could not open /var/run/tap/qemu-read-29
xs_read(): target get error. /local/domain/29/target.
xs_read(): vncpasswd get error. /vm/766033e3-17f7-4803-aab5-055e5360439e/vncpasswd.
xen be: qdisk-5632: xen be: qdisk-5632: error: unknown operation (4)
error: unknown operation (4)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 118 maps)
can't map 11 grant refs (Cannot allocate memory, 118 maps)
Key lost : keysym=0x1008ff02(269025026)


/var/log/xen/qemu-dm-Factory_full_bug694863.log

domid: 3
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /local_vminages/vdisk-Factory_full_bug694863-disk0 (drv 'aio')
Using file /local_vminages/vdisk-Factory_full_bug694863-disk0 in read-write mode
Watching /local/domain/0/device-model/3/logdirty/cmd
Watching /local/domain/0/device-model/3/command
Watching /local/domain/3/cpu
char device redirected to /dev/pts/5
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 78136f56-5614-4006-a24e-c73c6a3dc29e
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/3/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/78136f56-5614-4006-a24e-c73c6a3dc29e/vncpasswd.
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/3/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/3/log-throttling'
medium change watch on `/local/domain/3/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.
Unknown PV product 65535 loaded in guest
PV driver build 50593792
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 119 maps)
can't map 11 grant refs (Cannot allocate memory, 119 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 2 grant refs (Cannot allocate memory, 127 maps)
can't map 2 grant refs (Cannot allocate memory, 127 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 3 grant refs (Cannot allocate memory, 127 maps)
can't map 3 grant refs (Cannot allocate memory, 127 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 5 grant refs (Cannot allocate memory, 127 maps)
can't map 5 grant refs (Cannot allocate memory, 127 maps)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 12:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 12: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 1ShJp4-0002uU-RK; Wed, 20 Jun 2012 12:15:46 +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 1ShJp3-0002uP-52
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 12:15:45 +0000
Received: from [85.158.138.51:45493] by server-8.bemta-3.messagelabs.com id
	93/09-06157-0FEB1EF4; Wed, 20 Jun 2012 12:15:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340194540!20543476!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTcyMDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTcyMDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13238 invoked from network); 20 Jun 2012 12:15:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 12:15:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIiC0MFyD7
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-066-248.pools.arcor-ip.net [88.65.66.248])
	by smtp.strato.de (jorabe mo69) (RZmta 29.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e03409o5KAwKOK
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 14:15:40 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 642E218637; Wed, 20 Jun 2012 14:15:39 +0200 (CEST)
Date: Wed, 20 Jun 2012 14:15:39 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20120620121539.GA18219@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] grant table errors with qemu-xen-traditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 if thats guest or host related, but current xen-unstable
with device_model_version="qemu-xen-traditional" fail to access the
block device properly, both PV and HVM are affected. The guest runs the
upcoming 12.2 kernel, which is based on forward ported xenlinux sources.

I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
qemu-xen-traditional, but that does not seem to help.

Any idea whats wrong?

Olaf

/var/log/xen/qemu-dm-Factory_para_default.log

domid: 29
Warning: vlan 0 is not connected to host network
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
/usr/src/packages/BUILD/xen-4.2.25485/non-dbg/tools/qemu-xen-traditional-dir/hw/xen_blktap.c:628: Init blktap pipes
Could not open /var/run/tap/qemu-read-29
xs_read(): target get error. /local/domain/29/target.
xs_read(): vncpasswd get error. /vm/766033e3-17f7-4803-aab5-055e5360439e/vncpasswd.
xen be: qdisk-5632: xen be: qdisk-5632: error: unknown operation (4)
error: unknown operation (4)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 118 maps)
can't map 11 grant refs (Cannot allocate memory, 118 maps)
Key lost : keysym=0x1008ff02(269025026)


/var/log/xen/qemu-dm-Factory_full_bug694863.log

domid: 3
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /local_vminages/vdisk-Factory_full_bug694863-disk0 (drv 'aio')
Using file /local_vminages/vdisk-Factory_full_bug694863-disk0 in read-write mode
Watching /local/domain/0/device-model/3/logdirty/cmd
Watching /local/domain/0/device-model/3/command
Watching /local/domain/3/cpu
char device redirected to /dev/pts/5
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 78136f56-5614-4006-a24e-c73c6a3dc29e
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/3/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/78136f56-5614-4006-a24e-c73c6a3dc29e/vncpasswd.
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/3/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/3/log-throttling'
medium change watch on `/local/domain/3/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.
Unknown PV product 65535 loaded in guest
PV driver build 50593792
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 119 maps)
can't map 11 grant refs (Cannot allocate memory, 119 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 4 grant refs (Cannot allocate memory, 126 maps)
can't map 4 grant refs (Cannot allocate memory, 126 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 2 grant refs (Cannot allocate memory, 127 maps)
can't map 2 grant refs (Cannot allocate memory, 127 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 3 grant refs (Cannot allocate memory, 127 maps)
can't map 3 grant refs (Cannot allocate memory, 127 maps)
xc: error: linux_gnttab_grant_map: ioctl MAP_GRANT_REF failed (12 = Cannot allocate memory): Internal error
xen be: qdisk-768: xen be: qdisk-768: can't map 5 grant refs (Cannot allocate memory, 127 maps)
can't map 5 grant refs (Cannot allocate memory, 127 maps)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 12:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 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 1ShKCR-0003AL-Ts; Wed, 20 Jun 2012 12:39:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ShKCQ-0003AG-E8
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 12:39:55 +0000
Received: from [85.158.143.35:15098] by server-2.bemta-4.messagelabs.com id
	2B/8D-17938-994C1EF4; Wed, 20 Jun 2012 12:39:53 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340195991!5331116!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29761 invoked from network); 20 Jun 2012 12:39:51 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jun 2012 12:39:51 -0000
Received: from mail75-am1-R.bigfish.com (10.3.201.239) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 20 Jun 2012 12:38:26 +0000
Received: from mail75-am1 (localhost [127.0.0.1])	by mail75-am1-R.bigfish.com
	(Postfix) with ESMTP id A1453120216;
	Wed, 20 Jun 2012 12:38:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275dhz2dh668h839hd25he5bhf0ah34h)
Received: from mail75-am1 (localhost.localdomain [127.0.0.1]) by mail75-am1
	(MessageSwitch) id 1340195902295595_18419;
	Wed, 20 Jun 2012 12:38:22 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.251])	by
	mail75-am1.bigfish.com (Postfix) with ESMTP id 3B94932024F;
	Wed, 20 Jun 2012 12:38:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server id
	14.1.225.23; Wed, 20 Jun 2012 12:38:21 +0000
X-WSS-ID: 0M5X1U4-01-40Q-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DCC81028009;	Wed, 20 Jun 2012 07:39:40 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 20 Jun 2012 07:39:53 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 20 Jun 2012 07:39:41 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 20 Jun 2012
	08:39:39 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3459849C69E; Wed, 20 Jun 2012
	13:39:38 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id EECD95940FF; Wed, 20 Jun 2012
	14:39:37 +0200 (CEST)
Message-ID: <4FE1C423.6070001@amd.com>
Date: Wed, 20 Jun 2012 14:37:55 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge
	<jeremy@goop.org>, Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary="------------010709040101000902080703"
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010709040101000902080703
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0 
it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel 
crash.
The hypervisor does not matter, I tried 4.1.3-rc2 as well as various 
unstable versions including 25467, also 32-bit versions of 4.1.
The Dom0 kernels were always PVOPS versions, the problems starts with 
3.2-rc1~194 and is still in 3.5.0-rc3.
Also you need to restrict the Dom0 memory with dom0_mem=
The crash says (on a 3.4.3 32bit Dom0 kernel):
uruk:~ # ./acpidump32
[  158.843444] ------------[ cut here ]------------
[  158.843460] kernel BUG at mm/rmap.c:1027!
[  158.843466] invalid opcode: 0000 [#1] SMP
[  158.843472] Modules linked in:
[  158.843478]
[  158.843483] Pid: 4874, comm: acpidump32 Tainted: G        W    3.4.0+ 
#105 empty empty/S3993
[  158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
[  158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
[  158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
[  158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
[  158.843522]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[  158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
[  158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[  158.843581] DR6: ffff0ff0 DR7: 00000400
[  158.843586] Process acpidump32 (pid: 4874, ti=d6090000 task=d60b34f0 
task.ti=d6090000)
[  158.843591] Stack:
[  158.843594]  dfecb6e0 00000001 d6091ea8 c10b15c4 00000000 d6022dc0 
d61fbdd8 d6022dc0
[  158.843610]  00000000 d6091efc c10aacbe 00000000 99948025 80000001 
d8aa1f80 80000001
[  158.843631]  dfefc800 00000000 d8aa1f80 00000000 166b7025 d7f407d0 
b76faf64 99948025
[  158.843649] Call Trace:
[  158.843656]  [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
[  158.843664]  [<c10aacbe>] handle_pte_fault+0x81d/0xa06
[  158.843674]  [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
[  158.843683]  [<c159e4e8>] ? spurious_fault+0x104/0x104
[  158.843688]  [<c159e881>] do_page_fault+0x399/0x3b4
[  158.843696]  [<c10c639d>] ? filp_close+0x55/0x5f
[  158.843701]  [<c10c6408>] ? sys_close+0x61/0xa0
[  158.843706]  [<c159e4e8>] ? spurious_fault+0x104/0x104
[  158.843714]  [<c159c452>] error_code+0x5a/0x60
[  158.843720]  [<c159e4e8>] ? spurious_fault+0x104/0x104
[  158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03 50 
4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44 85 f6 
75 02 <0f> 0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89 73 04 f6
[  158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45 SS:ESP 
0069:d6091e84
[  158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
[  158.843854] note: acpidump32[4874] exited with preempt_count 1


On 64bit the OOM goes around, finally killing the login shell:
uruk:~ # ./acpidump_inst
acpi_map_memory(917504, 131072);
opened /dev/mem (fd=3)
calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
   mmap returned 0xf7571000, function returns 0xf7571000
acpi_map_table(cfef0f64, "XSDT");
acpi_map_memory(3488550756, 36);
opened /dev/mem (fd=3)
calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
   mmap returned 0xf76fd000, function returns 0xf76fdf64
   having mapped table header
   reading signature:

Welcome to SUSE Linux Enterprise Server 11 SP1  (i586) - Kernel 
3.5.0-rc3+ (hvc0).

uruk login:
-----------
This dump shows that the bug happens the moment acpidump accesses the 
mmapped ACPI table at @cfef0000 (the lower map at e0000 works).

This is extra unfortunate as in SLES11 acpidump will be called by the 
kbd init script (querying the BIOS NumLock setting!)

I bisected the Dom0 kernel to find this one (v3.2-rc~194):
commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
Merge: 315eb8a f3f436e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Oct 25 09:17:07 2011 +0200

     Merge branch 'stable/e820-3.2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

     * 'stable/e820-3.2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
       xen: release all pages within 1-1 p2m mappings
       xen: allow extra memory to be in multiple regions
       xen: allow balloon driver to use more than one memory region
       xen/balloon: simplify test for the end of usable RAM
       xen/balloon: account for pages released during memory setup


I tried to find something obvious, but to no avail. At least the new 
E820 looks sane, nothing that would prevent the mapping of the requested 
regions. Reverting this commit will not work easily on newer kernels, 
also is probably not desirable.

But it does not show on every machine here, so the machine E820 could 
actually be a differentiator. This particular box was a dual socket 
Barcelona server with 12GB of memory.

This whole PV memory management goes beyond my knowledge, so I'd like to 
ask for help on this issue.
If you need more information (I attached the boot log, which shows the 
two E820 tables), please ask. I can also quickly do some experiments if 
needed.

Thanks a lot,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

--------------010709040101000902080703
Content-Type: text/plain; charset="ISO-8859-1"; name="uruk.bootlog"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="uruk.bootlog"
Content-Description: uruk.bootlog

 __  __            _  _    ____                     _        _     _      
 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
                                                                          
(XEN) Xen version 4.2-unstable (aprzywar@osrc.amd.com) (gcc version 4.5.2 (GCC) ) Wed Jun 20 12:54:00 CEST 2012
(XEN) Latest ChangeSet: Thu Jun 07 19:46:57 2012 +0100 25467:32034d1914a6
(XEN) Bootloader: GNU GRUB 0.97-os.8
(XEN) Command line: console=com1 com1=115200 loglvl=all guest_loglvl=all noreboot dom0_mem=512M
(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 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000008ac00 (usable)
(XEN)  000000000008ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000ce000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cfef0000 (usable)
(XEN)  00000000cfef0000 - 00000000cfef7000 (ACPI data)
(XEN)  00000000cfef7000 - 00000000cff03000 (ACPI NVS)
(XEN)  00000000cff03000 - 00000000d0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec03000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff80000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000330000000 (usable)
(XEN) ACPI: RSDP 000F8010, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT CFEF0F64, 0064 (r1 BRCM   Anaheim   6040000 PTL   2000001)
(XEN) ACPI: FACP CFEF103C, 00F4 (r3 BRCM   EXPLOSN   6040000 MSFT  2000001)
(XEN) ACPI Warning (tbfadt-0444): Optional field "Pm2ControlBlock" has zero address or length: 0000000000000000/C [20070126]
(XEN) ACPI: DSDT CFEF1130, 4777 (r2 AMD    Anaheim   6040000 MSFT  2000002)
(XEN) ACPI: FACS CFF02FC0, 0040
(XEN) ACPI: TCPA CFEF58A7, 0032 (r1 BRCM   Anaheim   6040000 PTL  20000001)
(XEN) ACPI: SRAT CFEF58D9, 0150 (r1 AMD    HAMMER    6040000 AMD         1)
(XEN) ACPI: SSDT CFEF5A29, 143C (r1 AMD    POWERNOW  6040000 AMD         1)
(XEN) ACPI: HPET CFEF6E65, 0038 (r1 BRCM   Anaheim   6040000 BRCM  2000001)
(XEN) ACPI: SSDT CFEF6E9D, 0049 (r1 BRCM   PRT0      6040000 BRCM  2000001)
(XEN) ACPI: SPCR CFEF6EE6, 0050 (r1 PTLTD  $UCRTBL$  6040000 PTL         1)
(XEN) ACPI: APIC CFEF6F36, 00CA (r1 BRCM   Anaheim   6040000 PTL   2000001)
(XEN) System RAM: 12286MB (12581352kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 4 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 5 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 6 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 7 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-d0000000
(XEN) SRAT: Node 0 PXM 0 100000000-1b0000000
(XEN) SRAT: Node 1 PXM 1 1b0000000-330000000
(XEN) NUMA: Allocated memnodemap from 32e92f000 - 32e933000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 30 bits
(XEN) found SMP MP-table at 000f8040
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x508
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[544,504], pm1x_evt[500,540]
(XEN) ACPI:                  wakeup_vec[cff02fcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) Processor #1 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
(XEN) Processor #3 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
(XEN) Processor #5 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
(XEN) Processor #6 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
(XEN) Processor #7 0:2 APIC version 16
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-15
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[16])
(XEN) IOAPIC[1]: apic_id 9, version 17, address 0xfec01000, GSI 16-31
(XEN) ACPI: IOAPIC (id[0x0a] address[0xfec02000] gsi_base[32])
(XEN) IOAPIC[2]: apic_id 10, version 17, address 0xfec02000, GSI 32-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 3 I/O APICs
(XEN) ACPI: HPET id: 0x1166a201 base: 0xfed00000
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 1504 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2094.849 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD Fam10h machine check reporting enabled
(XEN) AMD-Vi: IOMMU not found!
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) HVM: ASIDs enabled.
(XEN) SVM: Supported advanced features:
(XEN)  - Nested Page Tables (NPT)
(XEN)  - Last Branch Record (LBR) Virtualisation
(XEN) HVM: SVM enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) Brought up 8 CPUs
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) HPET: 3 timers (0 will be used for broadcast)
(XEN) ACPI sleep modes: S3
(XEN) MCA: Use hw thresholding to adjust polling frequency
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0xb54000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0xab0e8
(XEN) elf_parse_binary: phdr: paddr=0x1cac000 memsz=0x12f00
(XEN) elf_parse_binary: phdr: paddr=0x1cbf000 memsz=0x5a4000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x2263000
(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 = 0xffffffff81cbf210
(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        = 0xffffffff82263000
(XEN)     virt_entry       = 0xffffffff81cbf210
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2263000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000320000000->0000000324000000 (114688 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82263000
(XEN)  Init. ramdisk: ffffffff82263000->ffffffff82263000
(XEN)  Phys-Mach map: ffffffff82263000->ffffffff82363000
(XEN)  Start info:    ffffffff82363000->ffffffff823634b4
(XEN)  Page tables:   ffffffff82364000->ffffffff82379000
(XEN)  Boot stack:    ffffffff82379000->ffffffff8237a000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82400000
(XEN)  ENTRY ADDRESS: ffffffff81cbf210
(XEN) Dom0 has maximum 8 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81b54000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81cab0e8
(XEN) elf_load_binary: phdr 2 at 0xffffffff81cac000 -> 0xffffffff81cbef00
(XEN) elf_load_binary: phdr 3 at 0xffffffff81cbf000 -> 0xffffffff81d6b000
(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 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.5.0-rc3+ (aprzywar@dosorca) (gcc version 4.5.2 (GCC) ) #103 SMP Mon Jun 18 14:11:37 CEST 2012
[    0.000000] Command line: root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
[    0.000000] Freeing 8a-100 pfn range: 118 pages freed
[    0.000000] Released 118 pages of unused memory
[    0.000000] Set 196998 page(s) to 1-1 mapping
[    0.000000] Populating 20000-20076 pfn range: 118 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x0000000000089fff] usable
[    0.000000] Xen: [mem 0x000000000008ac00-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000cfeeffff] usable
[    0.000000] Xen: [mem 0x00000000cfef0000-0x00000000cfef6fff] ACPI data
[    0.000000] Xen: [mem 0x00000000cfef7000-0x00000000cff02fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cff03000-0x00000000cfffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec02fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000fff80000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000190621fff] usable
[    0.000000] Xen: [mem 0x0000000190622000-0x000000032fffffff] unusable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x190622 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xcfef0 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000f8040-0x000f804f] mapped at [ffff8800000f8040]
[    0.000000] init_memory_mapping: [mem 0x00000000-0xcfeeffff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x190621fff]
[    0.000000] ACPI: RSDP 00000000000f8010 00024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 00000000cfef0f64 00064 (v01 BRCM   Anaheim  06040000 PTL  02000001)
[    0.000000] ACPI: FACP 00000000cfef103c 000F4 (v03 BRCM   EXPLOSN  06040000 MSFT 02000001)
[    0.000000] ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0xC (20120320/tbfadt-579)
[    0.000000] ACPI: DSDT 00000000cfef1130 04777 (v02 AMD    Anaheim  06040000 MSFT 02000002)
[    0.000000] ACPI: FACS 00000000cff02fc0 00040
[    0.000000] ACPI: TCPA 00000000cfef58a7 00032 (v01 BRCM   Anaheim  06040000 PTL  20000001)
[    0.000000] ACPI: SRAT 00000000cfef58d9 00150 (v01 AMD    HAMMER   06040000 AMD  00000001)
[    0.000000] ACPI: SSDT 00000000cfef5a29 0143C (v01 AMD    POWERNOW 06040000 AMD  00000001)
[    0.000000] ACPI: HPET 00000000cfef6e65 00038 (v01 BRCM   Anaheim  06040000 BRCM 02000001)
[    0.000000] ACPI: SSDT 00000000cfef6e9d 00049 (v01 BRCM   PRT0     06040000 BRCM 02000001)
[    0.000000] ACPI: SPCR 00000000cfef6ee6 00050 (v01 PTLTD  $UCRTBL$ 06040000 PTL  00000001)
[    0.000000] ACPI: APIC 00000000cfef6f36 000CA (v01 BRCM   Anaheim  06040000 PTL  02000001)
[    0.000000] Scanning NUMA topology in Northbridge 24
[    0.000000] Number of physical nodes 2
[    0.000000] Node 0 MemBase 0000000000000000 Limit 0000000190622000
[    0.000000] Node 1 bogus settings 1b0000000-190622000.
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x190621fff]
[    0.000000]   NODE_DATA [mem 0x20072000-0x20075fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x190621fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x00089fff]
[    0.000000]   node   0: [mem 0x00100000-0xcfeeffff]
[    0.000000]   node   0: [mem 0x100000000-0x190621fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x508
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-15
[    0.000000] ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[16])
[    0.000000] IOAPIC[1]: apic_id 9, version 17, address 0xfec01000, GSI 16-31
[    0.000000] ACPI: IOAPIC (id[0x0a] address[0xfec02000] gsi_base[32])
[    0.000000] IOAPIC[2]: apic_id 10, version 17, address 0xfec02000, GSI 32-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x1166a201 base: 0xfed00000
[    0.000000] SMP: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000008a000 - 000000000008b000
[    0.000000] PM: Registered nosave memory: 000000000008b000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000cfef0000 - 00000000cfef7000
[    0.000000] PM: Registered nosave memory: 00000000cfef7000 - 00000000cff03000
[    0.000000] PM: Registered nosave memory: 00000000cff03000 - 00000000d0000000
[    0.000000] PM: Registered nosave memory: 00000000d0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec03000
[    0.000000] PM: Registered nosave memory: 00000000fec03000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000fff80000
[    0.000000] PM: Registered nosave memory: 00000000fff80000 - 0000000100000000
[    0.000000] e820: [mem 0xd0000000-0xfebfffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 26 pages/cpu @ffff88001fe00000 s77568 r8192 d20736 u262144
[    6.478463] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1415680
[    6.478467] Policy zone: Normal
[    6.478472] Kernel command line: root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
[    6.478607] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    6.478617] __ex_table already sorted, skipping sort
[    6.566265] software IO TLB [mem 0x15400000-0x193fffff] (64MB) mapped at [ffff880015400000-ffff8800193fffff]
[    6.569911] Memory: 337772k/6559880k available (6898k kernel code, 788056k absent, 5434052k reserved, 6070k data, 728k init)
[    6.570040] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    6.570102] Hierarchical RCU implementation.
[    6.570121] NR_IRQS:4352 nr_irqs:1152 16
[    6.570235] xen: sci override: global_irq=9 trigger=0 polarity=1
[    6.570273] xen: acpi sci 9
[    6.580509] Console: colour VGA+ 80x25
[    6.580517] console [hvc0] enabled, bootconsole disabled
[    6.580517] console [hvc0] enabled, bootconsole disabled
[    6.580578] installing Xen timer for CPU 0
[    6.580617] Detected 2094.848 MHz processor.
[    6.580630] Calibrating delay loop (skipped), value calculated using timer frequency.. 4189.69 BogoMIPS (lpj=8379392)
[    6.580636] pid_max: default: 32768 minimum: 301
[    6.580682] Security Framework initialized
[    6.583355] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    6.589029] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    6.591229] Mount-cache hash table entries: 256
[    6.591586] Initializing cgroup subsys cpuacct
[    6.591593] Initializing cgroup subsys blkio
[    6.591597] Initializing cgroup subsys perf_event
[    6.591603] Initializing cgroup subsys net_prio
[    6.591683] CPU: Physical Processor ID: 0
[    6.591686] CPU: Processor Core ID: 0
[    6.595474] ACPI: Core revision 20120320
[    7.006297] cpu 0 spinlock event irq 65
[    7.006332] Performance Events: AMD PMU driver.
[    7.006337] ------------[ cut here ]------------
[    7.006351] WARNING: at arch/x86/xen/enlighten.c:862 xen_apic_write+0x15/0x17()
[    7.006355] Hardware name: empty
[    7.006359] Modules linked in:
[    7.006364] Pid: 1, comm: swapper/0 Not tainted 3.5.0-rc3+ #103
[    7.006369] Call Trace:
[    7.006379]  [<ffffffff8105053b>] warn_slowpath_common+0x80/0x98
[    7.006386]  [<ffffffff81050568>] warn_slowpath_null+0x15/0x17
[    7.006392]  [<ffffffff81003411>] xen_apic_write+0x15/0x17
[    7.006398]  [<ffffffff81016dc2>] perf_events_lapic_init+0x2e/0x30
[    7.006407]  [<ffffffff81ccaaa2>] init_hw_perf_events+0x266/0x42a
[    7.006415]  [<ffffffff81008531>] ? xen_smp_intr_init+0x18c/0x263
[    7.006420]  [<ffffffff81cca83c>] ? check_bugs+0x2d/0x2d
[    7.006426]  [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
[    7.006434]  [<ffffffff81cbfbe5>] kernel_init+0x9f/0x1d0
[    7.006443]  [<ffffffff816b9764>] kernel_thread_helper+0x4/0x10
[    7.006450]  [<ffffffff816b2e38>] ? retint_restore_args+0x5/0x6
[    7.006456]  [<ffffffff816b9760>] ? gs_change+0x13/0x13
[    7.006469] ---[ end trace 4eaa2a86a8e2da22 ]---
[    7.006474] ... version:                0
[    7.006477] ... bit width:              48
[    7.006480] ... generic registers:      4
[    7.006483] ... value mask:             0000ffffffffffff
[    7.006486] ... max period:             00007fffffffffff
[    7.006489] ... fixed-purpose events:   0
[    7.006492] ... event mask:             000000000000000f
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.007193] MCE: In-kernel MCE decoding enabled.
[    7.007328] installing Xen timer for CPU 1
[    7.007347] cpu 1 spinlock event irq 72
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.007721] installing Xen timer for CPU 2
[    7.007735] cpu 2 spinlock event irq 79
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.008028] installing Xen timer for CPU 3
[    7.008042] cpu 3 spinlock event irq 86
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.008337] installing Xen timer for CPU 4
[    7.008352] cpu 4 spinlock event irq 93
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.008676] installing Xen timer for CPU 5
[    7.008691] cpu 5 spinlock event irq 100
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.009028] installing Xen timer for CPU 6
[    7.009042] cpu 6 spinlock event irq 107
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.009388] installing Xen timer for CPU 7
[    7.009402] cpu 7 spinlock event irq 114
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.009672] Brought up 8 CPUs
[    7.010659] EVM: security.capability
[    7.010790] PM: Registering ACPI NVS region [mem 0xcfef7000-0xcff02fff] (49152 bytes)
[    7.010840] xor: automatically using best checksumming function:
[    7.050872]    generic_sse:  2684.000 MB/sec
[    7.050896] Grant tables using version 2 layout.
[    7.050917] Grant table initialized
[    7.050980] RTC time: 10:49:10, date: 06/20/12
[    7.051038] NET: Registered protocol family 16
[    7.052288] TOM: 00000000d0000000 aka 3328M
[    7.052319] TOM2: 0000000330000000 aka 13056M
[    7.052605] ACPI: bus type pci registered
[    7.052814] PCI: Using configuration type 1 for base access
[    7.052819] PCI: Using configuration type 1 for extended access
[    7.075903] bio: create slab <bio-0> at 0
[    7.144028] raid6: sse2x1    2320 MB/s
[    7.212782] raid6: sse2x2    3292 MB/s
[    7.281490] raid6: sse2x4    3456 MB/s
[    7.281494] raid6: using algorithm sse2x4 (3456 MB/s)
[    7.281498] raid6: using intx1 recovery algorithm
[    7.281603] ACPI: Added _OSI(Module Device)
[    7.281608] ACPI: Added _OSI(Processor Device)
[    7.281611] ACPI: Added _OSI(3.0 _SCP Extensions)
[    7.281615] ACPI: Added _OSI(Processor Aggregator Device)
[    7.288311] ACPI: Interpreter enabled
[    7.288332] ACPI: (supports S0 S1 S5)
[    7.288338] ACPI: Using IOAPIC for interrupt routing
[    7.302182] ACPI: No dock devices found.
[    7.302191] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    7.303385] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
[    7.304756] pci_root PNP0A08:00: host bridge window [io  0x0000-0x03af]
[    7.304762] pci_root PNP0A08:00: host bridge window [io  0x03e0-0x0fff]
[    7.304768] pci_root PNP0A08:00: host bridge window [io  0x03b0-0x03df]
[    7.304773] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
[    7.304779] pci_root PNP0A08:00: host bridge window [io  0x1000-0x6fff]
[    7.304784] pci_root PNP0A08:00: host bridge window [io  0x7000-0xffff]
[    7.304789] pci_root PNP0A08:00: host bridge window [mem 0xfec00000-0xfecfffff]
[    7.304795] pci_root PNP0A08:00: host bridge window [mem 0xe8000000-0xefffffff]
[    7.304800] pci_root PNP0A08:00: host bridge window [mem 0xd8000000-0xd84fffff]
[    7.304806] pci_root PNP0A08:00: host bridge window [mem 0xd0000000-0xd7ffffff]
[    7.304811] pci_root PNP0A08:00: host bridge window [mem 0xfe000000-0xfebfffff]
[    7.304817] pci_root PNP0A08:00: host bridge window [mem 0xfec04000-0xfecfffff]
[    7.304822] pci_root PNP0A08:00: host bridge window [mem 0xfed00400-0xfed07fff]
[    7.304828] pci_root PNP0A08:00: host bridge window [mem 0xfed08008-0xfedfffff]
[    7.304834] pci_root PNP0A08:00: host bridge window [mem 0xfee01000-0xffffffff]
[    7.304841] pci_root PNP0A08:00: host bridge window expanded to [mem 0xfec00000-0xfecfffff]; [mem 0xfec04000-0xfecfffff] ignored
[    7.304955] PCI host bridge to bus 0000:00
[    7.304961] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    7.304966] pci_bus 0000:00: root bus resource [io  0x03e0-0x0fff]
[    7.304972] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    7.304977] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    7.304982] pci_bus 0000:00: root bus resource [io  0x1000-0x6fff]
[    7.304987] pci_bus 0000:00: root bus resource [io  0x7000-0xffff]
[    7.304992] pci_bus 0000:00: root bus resource [mem 0xfec00000-0xfecfffff]
[    7.304998] pci_bus 0000:00: root bus resource [mem 0xe8000000-0xefffffff]
[    7.305003] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xd84fffff]
[    7.305008] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xd7ffffff]
[    7.305014] pci_bus 0000:00: root bus resource [mem 0xfe000000-0xfebfffff]
[    7.305019] pci_bus 0000:00: root bus resource [mem 0xfed00400-0xfed07fff]
[    7.305024] pci_bus 0000:00: root bus resource [mem 0xfed08008-0xfedfffff]
[    7.305030] pci_bus 0000:00: root bus resource [mem 0xfee01000-0xffffffff]
[    7.305214] pci 0000:00:01.0: Enabling HT MSI Mapping
[    7.310204] pci 0000:00:01.0: PCI bridge to [bus 01-02]
[    7.310330] pci 0000:01:0d.0: PCI bridge to [bus 02-02]
[    7.310494] pci 0000:00:06.0: PCI bridge to [bus 03-03]
[    7.310611] pci 0000:00:07.0: PCI bridge to [bus 04-04]
[    7.310728] pci 0000:00:08.0: PCI bridge to [bus 05-05]
[    7.310845] pci 0000:00:09.0: PCI bridge to [bus 06-06]
[    7.311203] pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    7.311225] pci 0000:00:0a.0: PCI bridge to [bus 07-08]
[    7.311961] pci 0000:07:00.0: PCI bridge to [bus 08-08]
[    7.312601]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    7.312608]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[    7.312613] ACPI _OSC control for PCIe not granted, disabling ASPM
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:02.1
(XEN) PCI add device 0000:00:02.2
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:03.1
(XEN) PCI add device 0000:00:03.2
(XEN) PCI add device 0000:00:04.0
(XEN) PCI add device 0000:00:06.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:08.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add device 0000:00:18.0
(XEN) PCI add device 0000:00:18.1
(XEN) PCI add device 0000:00:18.2
(XEN) PCI add device 0000:00:18.3
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:00:19.0
(XEN) PCI add device 0000:00:19.1
(XEN) PCI add device 0000:00:19.2
(XEN) PCI add device 0000:00:19.3
(XEN) PCI add device 0000:00:19.4
(XEN) PCI add device 0000:01:0d.0
(XEN) PCI add device 0000:01:0e.0
(XEN) PCI add device 0000:01:0e.1
(XEN) PCI add device 0000:07:00.0
(XEN) PCI add device 0000:08:04.0
(XEN) PCI add device 0000:08:04.1
[    7.320699] ACPI: PCI Interrupt Link [LNKU] (IRQs *10 11)
[    7.320751] ACPI: PCI Interrupt Link [LNKW] (IRQs 10 11) *0, disabled.
[    7.320824] ACPI: PCI Interrupt Link [LNKS] (IRQs 5 *7 11)
[    7.320938] ACPI: PCI Interrupt Link [LN00] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.320984] ACPI: PCI Interrupt Link [LN01] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321049] ACPI: PCI Interrupt Link [LN02] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321098] ACPI: PCI Interrupt Link [LN03] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321158] ACPI: PCI Interrupt Link [LN04] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321218] ACPI: PCI Interrupt Link [LN05] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321268] ACPI: PCI Interrupt Link [LN06] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321317] ACPI: PCI Interrupt Link [LN07] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321370] ACPI: PCI Interrupt Link [LN08] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321432] ACPI: PCI Interrupt Link [LN09] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321488] ACPI: PCI Interrupt Link [LN0A] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321548] ACPI: PCI Interrupt Link [LN0B] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321610] ACPI: PCI Interrupt Link [LN0C] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321666] ACPI: PCI Interrupt Link [LN0D] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321709] ACPI: PCI Interrupt Link [LN0E] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321779] ACPI: PCI Interrupt Link [LN0F] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321844] ACPI: PCI Interrupt Link [LN10] (IRQs 3 4 5 7 *11 12 14 15)
[    7.321908] ACPI: PCI Interrupt Link [LN11] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321963] ACPI: PCI Interrupt Link [LN12] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322018] ACPI: PCI Interrupt Link [LN13] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322100] ACPI: PCI Interrupt Link [LN14] (IRQs 3 4 *5 7 11 12 14 15)
[    7.322153] ACPI: PCI Interrupt Link [LN15] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322208] ACPI: PCI Interrupt Link [LN16] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322306] ACPI: PCI Interrupt Link [LN17] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322383] ACPI: PCI Interrupt Link [LN18] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322423] ACPI: PCI Interrupt Link [LN19] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322487] ACPI: PCI Interrupt Link [LN1A] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322565] ACPI: PCI Interrupt Link [LN1B] (IRQs 3 4 *5 7 11 12 14 15)
[    7.322616] ACPI: PCI Interrupt Link [LN1C] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322664] ACPI: PCI Interrupt Link [LN1D] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322732] ACPI: PCI Interrupt Link [LN1E] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322779] ACPI: PCI Interrupt Link [LN1F] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322957] xen/balloon: Initialising balloon driver.
[    7.366475] xen-balloon: Initialising balloon driver.
[    7.366941] vgaarb: device added: PCI:0000:00:04.0,decodes=io+mem,owns=io+mem,locks=none
[    7.366966] vgaarb: loaded
[    7.366969] vgaarb: bridge control possible 0000:00:04.0
[    7.367272] SCSI subsystem initialized
[    7.367777] ACPI: bus type usb registered
[    7.367949] usbcore: registered new interface driver usbfs
[    7.368037] usbcore: registered new interface driver hub
[    7.368160] usbcore: registered new device driver usb
[    7.368734] Advanced Linux Sound Architecture Driver Version 1.0.25.
[    7.368740] PCI: Using ACPI for IRQ routing
[    7.369374] NetLabel: Initializing
[    7.369378] NetLabel:  domain hash size = 128
[    7.369382] NetLabel:  protocols = UNLABELED CIPSOv4
[    7.369444] NetLabel:  unlabeled traffic allowed by default
[    7.369626] Switching to clocksource xen
[    7.369827] pnp: PnP ACPI init
[    7.369841] ACPI: bus type pnp registered
[    7.370049] system 00:00: [mem 0xfed08000-0xfed08007] has been reserved
[    7.370828] system 00:01: [mem 0xe0000000-0xefffffff] could not be reserved
[    7.373707] system 00:0b: [io  0x040b] has been reserved
[    7.373713] system 00:0b: [io  0x04d0-0x04d1] has been reserved
[    7.373720] system 00:0b: [io  0x04d6] has been reserved
[    7.373725] system 00:0b: [io  0x0500-0x0560] has been reserved
[    7.373730] system 00:0b: [io  0x0558-0x055b] has been reserved
[    7.373736] system 00:0b: [io  0x0580-0x058f] has been reserved
[    7.373741] system 00:0b: [io  0x0590-0x0593] has been reserved
[    7.373746] system 00:0b: [io  0x0600-0x061f] has been reserved
[    7.373751] system 00:0b: [io  0x0620-0x0623] has been reserved
[    7.373759] system 00:0b: [io  0x0700-0x0703] has been reserved
[    7.373767] system 00:0b: [io  0x0c00-0x0c01] has been reserved
[    7.373772] system 00:0b: [io  0x0c06-0x0c08] has been reserved
[    7.373777] system 00:0b: [io  0x0c14] has been reserved
[    7.373782] system 00:0b: [io  0x0c49-0x0c4a] has been reserved
[    7.373787] system 00:0b: [io  0x0c50-0x0c53] has been reserved
[    7.373792] system 00:0b: [io  0x0c6c] has been reserved
[    7.373797] system 00:0b: [io  0x0c6f] has been reserved
[    7.373802] system 00:0b: [io  0x0cd6-0x0cd7] has been reserved
[    7.373807] system 00:0b: [io  0x0cf9] could not be reserved
[    7.373813] system 00:0b: [io  0x0f50-0x0f58] has been reserved
[    7.373966] Already setup the GSI :4
[    7.375025] pnp: PnP ACPI: found 16 devices
[    7.375029] ACPI: ACPI bus type pnp unregistered
[    7.386348] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    7.386597] pci 0000:00:01.0: BAR 15: assigned [mem 0xe8000000-0xe80fffff pref]
[    7.386605] pci 0000:00:04.0: BAR 6: assigned [mem 0xfec20000-0xfec3ffff pref]
[    7.386615] pci 0000:01:0e.0: BAR 6: assigned [mem 0xe8000000-0xe801ffff pref]
[    7.386621] pci 0000:01:0d.0: PCI bridge to [bus 02-02]
[    7.386641] pci 0000:00:01.0: PCI bridge to [bus 01-02]
[    7.386647] pci 0000:00:01.0:   bridge window [io  0x6000-0x6fff]
[    7.386657] pci 0000:00:01.0:   bridge window [mem 0xd8100000-0xd81fffff]
[    7.386671] pci 0000:00:01.0:   bridge window [mem 0xe8000000-0xe80fffff pref]
[    7.386694] pci 0000:00:06.0: PCI bridge to [bus 03-03]
[    7.386723] pci 0000:00:07.0: PCI bridge to [bus 04-04]
[    7.386765] pci 0000:00:08.0: PCI bridge to [bus 05-05]
[    7.386809] pci 0000:00:09.0: PCI bridge to [bus 06-06]
[    7.386838] pci 0000:07:00.0: PCI bridge to [bus 08-08]
[    7.386854] pci 0000:07:00.0:   bridge window [mem 0xd8000000-0xd80fffff]
[    7.386902] pci 0000:00:0a.0: PCI bridge to [bus 07-08]
[    7.386918] pci 0000:00:0a.0:   bridge window [mem 0xd8000000-0xd80fffff]
[    7.387036] Already setup the GSI :32
[    7.387056] Already setup the GSI :32
[    7.387066] Already setup the GSI :32
[    7.387077] Already setup the GSI :32
[    7.387185] NET: Registered protocol family 2
[    7.387503] IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
[    7.389348] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    7.391853] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    7.392402] TCP: Hash tables configured (established 262144 bind 65536)
[    7.392409] TCP: reno registered
[    7.392508] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    7.392632] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    7.392849] NET: Registered protocol family 1
[    7.393089] RPC: Registered named UNIX socket transport module.
[    7.393096] RPC: Registered udp transport module.
[    7.393105] RPC: Registered tcp transport module.
[    7.393108] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    7.393302] pci 0000:00:02.0: disabled boot interrupts on device [1166:0205]
[    7.393480] ACPI: PCI Interrupt Link [LNKU] enabled at IRQ 10
[    7.445860] Already setup the GSI :10
[    7.501776] Already setup the GSI :10
[    7.504275] microcode: CPU0: patch_level=0x01000065
[    7.504286] microcode: CPU1: patch_level=0x01000065
[    7.504306] microcode: CPU2: patch_level=0x01000065
[    7.504330] microcode: CPU3: patch_level=0x01000065
[    7.504355] microcode: CPU4: patch_level=0x01000065
[    7.504377] microcode: CPU5: patch_level=0x01000065
[    7.504403] microcode: CPU6: patch_level=0x01000065
[    7.504430] microcode: CPU7: patch_level=0x01000065
[    7.504530] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    7.506353] sha1_ssse3: Neither AVX nor SSSE3 is available/usable.
[    7.506880] audit: initializing netlink socket (disabled)
[    7.506913] type=2000 audit(1340189350.092:1): initialized
[    7.540089] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    7.546507] VFS: Disk quotas dquot_6.5.2
[    7.546632] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    7.548235] NFS: Registering the id_resolver key type
[    7.548256] Key type id_resolver registered
[    7.548934] fuse init (API version 7.19)
[    7.549329] msgmni has been set to 659
[    7.551203] NET: Registered protocol family 38
[    7.551391] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    7.551398] io scheduler noop registered
[    7.551402] io scheduler deadline registered
[    7.551601] io scheduler cfq registered (default)
[    7.553669] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0C:00/input/input0
[    7.553679] ACPI: Power Button [PWRB]
[    7.553888] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    7.553894] ACPI: Power Button [PWRF]
[    7.554059] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input2
[    7.554065] ACPI: Sleep Button [SLPF]
[    7.560418] Event-channel device installed.
[    7.561677] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
[    7.837905] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    7.859709] 00:0d: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    7.860308] hpet_acpi_add: no address or irqs in _CRS
[    7.860512] Non-volatile memory driver v1.3
[    7.860592] Linux agpgart interface v0.103
[    7.863161] [drm] Initialized drm 1.1.0 20060810
[    7.863167] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[    7.866674] brd: module loaded
[    7.868524] loop: module loaded
[    7.869066] nbd: registered device at major 43
[    7.872550] Loading iSCSI transport class v2.0-870.
[    7.874722] ACPI: PCI Interrupt Link [LNKS] enabled at IRQ 11
[    7.876203] scsi0 : sata_svw
[    7.876467] scsi1 : sata_svw
[    7.876699] scsi2 : sata_svw
[    7.876971] scsi3 : sata_svw
[    7.877156] ata1: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100000 irq 11
[    7.877162] ata2: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100100 irq 11
[    7.877168] ata3: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100200 irq 11
[    7.877177] ata4: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100300 irq 11
[    7.877346] Already setup the GSI :11
[    7.879305] scsi4 : pata_serverworks
[    7.879539] scsi5 : pata_serverworks
[    7.879885] ata5: PATA max UDMA/66 cmd 0x1f0 ctl 0x3f6 bmdma 0x4800 irq 14
[    7.879894] ata6: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0x4808 irq 15
[    7.882842] tun: Universal TUN/TAP device driver, 1.6
[    7.882848] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    7.883212] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
[    7.883464] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.10 (March 21, 2012)
[    7.883609] tg3.c:v3.123 (March 21, 2012)
[    7.943267] tg3 0000:08:04.0: eth0: Tigon3 [partno(BCM95715) rev 9003] (PCIX:133MHz:64-bit) MAC address 00:e0:81:80:1d:9c
[    7.943281] tg3 0000:08:04.0: eth0: attached PHY is 5714 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[    7.943288] tg3 0000:08:04.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    7.943294] tg3 0000:08:04.0: eth0: dma_rwctrl[76148000] dma_mask[40-bit]
[    7.943487] Already setup the GSI :36
[    7.988541] tg3 0000:08:04.1: eth1: Tigon3 [partno(BCM95715) rev 9003] (PCIX:133MHz:64-bit) MAC address 00:e0:81:80:1d:9d
[    7.988550] tg3 0000:08:04.1: eth1: attached PHY is 5714 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[    7.988557] tg3 0000:08:04.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    7.988563] tg3 0000:08:04.1: eth1: dma_rwctrl[76148000] dma_mask[40-bit]
[    7.988733] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[    7.988738] e100: Copyright(c) 1999-2006 Intel Corporation
[    7.988835] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    7.988840] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    7.988938] e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
[    7.988942] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    7.989044] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.6.0-k
[    7.989049] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    7.989136] sky2: driver version 1.30
[    7.989683] Initialising Xen virtual ethernet driver.
[    7.989761] Fusion MPT base driver 3.04.20
[    7.989765] Copyright (c) 1999-2008 LSI Corporation
[    7.989781] Fusion MPT SAS Host driver 3.04.20
[    7.989881] Fusion MPT misc device (ioctl) driver 3.04.20
[    7.989970] mptctl: Registered with Fusion MPT base driver
[    7.989974] mptctl: /dev/mptctl @ (major,minor=10,220)
[    7.990251] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    7.990437] Already setup the GSI :10
[    7.990466] ehci_hcd 0000:00:03.2: EHCI Host Controller
[    7.990645] ehci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 1
[    8.017764] ehci_hcd 0000:00:03.2: irq 10, io mem 0xd8412000
[    8.029737] ehci_hcd 0000:00:03.2: USB 2.0 started, EHCI 1.00
[    8.029789] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    8.029798] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.029803] usb usb1: Product: EHCI Host Controller
[    8.029808] usb usb1: Manufacturer: Linux 3.5.0-rc3+ ehci_hcd
[    8.029812] usb usb1: SerialNumber: 0000:00:03.2
[    8.030088] hub 1-0:1.0: USB hub found
[    8.030096] hub 1-0:1.0: 4 ports detected
[    8.030321] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    8.030500] Already setup the GSI :10
[    8.030527] ohci_hcd 0000:00:03.0: OHCI Host Controller
[    8.030641] ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2
[    8.030684] ohci_hcd 0000:00:03.0: irq 10, io mem 0xd8410000
[    8.042313] ata5.01: ATAPI: DV-28E-R, 1.8A, max UDMA/33
[    8.058292] ata5.01: configured for UDMA/33
[    8.085871] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    8.085877] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.085882] usb usb2: Product: OHCI Host Controller
[    8.085886] usb usb2: Manufacturer: Linux 3.5.0-rc3+ ohci_hcd
[    8.085891] usb usb2: SerialNumber: 0000:00:03.0
[    8.086152] hub 2-0:1.0: USB hub found
[    8.086162] hub 2-0:1.0: 2 ports detected
[    8.086355] Already setup the GSI :10
[    8.086381] ohci_hcd 0000:00:03.1: OHCI Host Controller
[    8.086485] ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 3
[    8.086533] ohci_hcd 0000:00:03.1[    8.972360] ata3: SATA link down (SStatus 4 SControl 300)
[    9.300339] ata4: SATA link down (SStatus 4 SControl 300)
[    9.304551] scsi 4:0:1:0: CD-ROM            TEAC     DV-28E-R         1.8A PQ: 0 ANSI: 5
[    9.309465] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
[    9.309471] cdrom: Uniform CD-ROM driver Revision: 3.20
[    9.309933] sr 4:0:1:0: Attached scsi generic sg1 type 5
[    9.465898] md: Waiting for all devices to be available before autodetect
[    9.465905] md: If you don't use raid, use raid=noautodetect
[    9.466217] md: Autodetecting RAID arrays.
[    9.466221] md: Scanned 0 and added 0 devices.
[    9.466225] md: autorun ...
[    9.466227] md: ... autorun DONE.
[    9.618177] kjournald starting.  Commit interval 5 seconds
[    9.618515] EXT3-fs (sda2): using internal journal
[    9.634755] EXT3-fs (sda2): recovery complete
[    9.634773] EXT3-fs (sda2): mounted filesystem with writeback data mode
[    9.634812] VFS: Mounted root (ext3 filesystem) on device 8:2.
[    9.635302] Freeing unused kernel memory: 728k freed
[    9.635605] Write protecting the kernel read-only data: 12288k
[    9.642755] Freeing unused kernel memory: 1280k freed
[    9.643732] Freeing unused kernel memory: 688k freed
[   10.945707] udevd (1368): /proc/1368/oom_adj is deprecated, please use /proc/1368/oom_score_adj instead.
[   10.945761] udevd version 128 started
[   12.146999] Adding 7815584k swap on /dev/sda1.  Priority:-1 extents:1 across:7815584k 
[   13.829592] dd: sending ioctl 801c6d02 to a partition!
[   13.829613] dd: sending ioctl 80306d02 to a partition!
[   13.829618] dd: sending ioctl 80306d02 to a partition!
[   18.907214] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

--------------010709040101000902080703
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010709040101000902080703--


From xen-devel-bounces@lists.xen.org Wed Jun 20 12:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 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 1ShKCR-0003AL-Ts; Wed, 20 Jun 2012 12:39:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ShKCQ-0003AG-E8
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 12:39:55 +0000
Received: from [85.158.143.35:15098] by server-2.bemta-4.messagelabs.com id
	2B/8D-17938-994C1EF4; Wed, 20 Jun 2012 12:39:53 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340195991!5331116!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29761 invoked from network); 20 Jun 2012 12:39:51 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jun 2012 12:39:51 -0000
Received: from mail75-am1-R.bigfish.com (10.3.201.239) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 20 Jun 2012 12:38:26 +0000
Received: from mail75-am1 (localhost [127.0.0.1])	by mail75-am1-R.bigfish.com
	(Postfix) with ESMTP id A1453120216;
	Wed, 20 Jun 2012 12:38:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275dhz2dh668h839hd25he5bhf0ah34h)
Received: from mail75-am1 (localhost.localdomain [127.0.0.1]) by mail75-am1
	(MessageSwitch) id 1340195902295595_18419;
	Wed, 20 Jun 2012 12:38:22 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.251])	by
	mail75-am1.bigfish.com (Postfix) with ESMTP id 3B94932024F;
	Wed, 20 Jun 2012 12:38:22 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server id
	14.1.225.23; Wed, 20 Jun 2012 12:38:21 +0000
X-WSS-ID: 0M5X1U4-01-40Q-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DCC81028009;	Wed, 20 Jun 2012 07:39:40 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 20 Jun 2012 07:39:53 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 20 Jun 2012 07:39:41 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 20 Jun 2012
	08:39:39 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3459849C69E; Wed, 20 Jun 2012
	13:39:38 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id EECD95940FF; Wed, 20 Jun 2012
	14:39:37 +0200 (CEST)
Message-ID: <4FE1C423.6070001@amd.com>
Date: Wed, 20 Jun 2012 14:37:55 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge
	<jeremy@goop.org>, Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary="------------010709040101000902080703"
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010709040101000902080703
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0 
it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel 
crash.
The hypervisor does not matter, I tried 4.1.3-rc2 as well as various 
unstable versions including 25467, also 32-bit versions of 4.1.
The Dom0 kernels were always PVOPS versions, the problems starts with 
3.2-rc1~194 and is still in 3.5.0-rc3.
Also you need to restrict the Dom0 memory with dom0_mem=
The crash says (on a 3.4.3 32bit Dom0 kernel):
uruk:~ # ./acpidump32
[  158.843444] ------------[ cut here ]------------
[  158.843460] kernel BUG at mm/rmap.c:1027!
[  158.843466] invalid opcode: 0000 [#1] SMP
[  158.843472] Modules linked in:
[  158.843478]
[  158.843483] Pid: 4874, comm: acpidump32 Tainted: G        W    3.4.0+ 
#105 empty empty/S3993
[  158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
[  158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
[  158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
[  158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
[  158.843522]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[  158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
[  158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[  158.843581] DR6: ffff0ff0 DR7: 00000400
[  158.843586] Process acpidump32 (pid: 4874, ti=d6090000 task=d60b34f0 
task.ti=d6090000)
[  158.843591] Stack:
[  158.843594]  dfecb6e0 00000001 d6091ea8 c10b15c4 00000000 d6022dc0 
d61fbdd8 d6022dc0
[  158.843610]  00000000 d6091efc c10aacbe 00000000 99948025 80000001 
d8aa1f80 80000001
[  158.843631]  dfefc800 00000000 d8aa1f80 00000000 166b7025 d7f407d0 
b76faf64 99948025
[  158.843649] Call Trace:
[  158.843656]  [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
[  158.843664]  [<c10aacbe>] handle_pte_fault+0x81d/0xa06
[  158.843674]  [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
[  158.843683]  [<c159e4e8>] ? spurious_fault+0x104/0x104
[  158.843688]  [<c159e881>] do_page_fault+0x399/0x3b4
[  158.843696]  [<c10c639d>] ? filp_close+0x55/0x5f
[  158.843701]  [<c10c6408>] ? sys_close+0x61/0xa0
[  158.843706]  [<c159e4e8>] ? spurious_fault+0x104/0x104
[  158.843714]  [<c159c452>] error_code+0x5a/0x60
[  158.843720]  [<c159e4e8>] ? spurious_fault+0x104/0x104
[  158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03 50 
4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44 85 f6 
75 02 <0f> 0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89 73 04 f6
[  158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45 SS:ESP 
0069:d6091e84
[  158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
[  158.843854] note: acpidump32[4874] exited with preempt_count 1


On 64bit the OOM goes around, finally killing the login shell:
uruk:~ # ./acpidump_inst
acpi_map_memory(917504, 131072);
opened /dev/mem (fd=3)
calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
   mmap returned 0xf7571000, function returns 0xf7571000
acpi_map_table(cfef0f64, "XSDT");
acpi_map_memory(3488550756, 36);
opened /dev/mem (fd=3)
calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
   mmap returned 0xf76fd000, function returns 0xf76fdf64
   having mapped table header
   reading signature:

Welcome to SUSE Linux Enterprise Server 11 SP1  (i586) - Kernel 
3.5.0-rc3+ (hvc0).

uruk login:
-----------
This dump shows that the bug happens the moment acpidump accesses the 
mmapped ACPI table at @cfef0000 (the lower map at e0000 works).

This is extra unfortunate as in SLES11 acpidump will be called by the 
kbd init script (querying the BIOS NumLock setting!)

I bisected the Dom0 kernel to find this one (v3.2-rc~194):
commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
Merge: 315eb8a f3f436e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Oct 25 09:17:07 2011 +0200

     Merge branch 'stable/e820-3.2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

     * 'stable/e820-3.2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
       xen: release all pages within 1-1 p2m mappings
       xen: allow extra memory to be in multiple regions
       xen: allow balloon driver to use more than one memory region
       xen/balloon: simplify test for the end of usable RAM
       xen/balloon: account for pages released during memory setup


I tried to find something obvious, but to no avail. At least the new 
E820 looks sane, nothing that would prevent the mapping of the requested 
regions. Reverting this commit will not work easily on newer kernels, 
also is probably not desirable.

But it does not show on every machine here, so the machine E820 could 
actually be a differentiator. This particular box was a dual socket 
Barcelona server with 12GB of memory.

This whole PV memory management goes beyond my knowledge, so I'd like to 
ask for help on this issue.
If you need more information (I attached the boot log, which shows the 
two E820 tables), please ask. I can also quickly do some experiments if 
needed.

Thanks a lot,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

--------------010709040101000902080703
Content-Type: text/plain; charset="ISO-8859-1"; name="uruk.bootlog"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="uruk.bootlog"
Content-Description: uruk.bootlog

 __  __            _  _    ____                     _        _     _      
 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
                                                                          
(XEN) Xen version 4.2-unstable (aprzywar@osrc.amd.com) (gcc version 4.5.2 (GCC) ) Wed Jun 20 12:54:00 CEST 2012
(XEN) Latest ChangeSet: Thu Jun 07 19:46:57 2012 +0100 25467:32034d1914a6
(XEN) Bootloader: GNU GRUB 0.97-os.8
(XEN) Command line: console=com1 com1=115200 loglvl=all guest_loglvl=all noreboot dom0_mem=512M
(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 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000008ac00 (usable)
(XEN)  000000000008ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000ce000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cfef0000 (usable)
(XEN)  00000000cfef0000 - 00000000cfef7000 (ACPI data)
(XEN)  00000000cfef7000 - 00000000cff03000 (ACPI NVS)
(XEN)  00000000cff03000 - 00000000d0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec03000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff80000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000330000000 (usable)
(XEN) ACPI: RSDP 000F8010, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT CFEF0F64, 0064 (r1 BRCM   Anaheim   6040000 PTL   2000001)
(XEN) ACPI: FACP CFEF103C, 00F4 (r3 BRCM   EXPLOSN   6040000 MSFT  2000001)
(XEN) ACPI Warning (tbfadt-0444): Optional field "Pm2ControlBlock" has zero address or length: 0000000000000000/C [20070126]
(XEN) ACPI: DSDT CFEF1130, 4777 (r2 AMD    Anaheim   6040000 MSFT  2000002)
(XEN) ACPI: FACS CFF02FC0, 0040
(XEN) ACPI: TCPA CFEF58A7, 0032 (r1 BRCM   Anaheim   6040000 PTL  20000001)
(XEN) ACPI: SRAT CFEF58D9, 0150 (r1 AMD    HAMMER    6040000 AMD         1)
(XEN) ACPI: SSDT CFEF5A29, 143C (r1 AMD    POWERNOW  6040000 AMD         1)
(XEN) ACPI: HPET CFEF6E65, 0038 (r1 BRCM   Anaheim   6040000 BRCM  2000001)
(XEN) ACPI: SSDT CFEF6E9D, 0049 (r1 BRCM   PRT0      6040000 BRCM  2000001)
(XEN) ACPI: SPCR CFEF6EE6, 0050 (r1 PTLTD  $UCRTBL$  6040000 PTL         1)
(XEN) ACPI: APIC CFEF6F36, 00CA (r1 BRCM   Anaheim   6040000 PTL   2000001)
(XEN) System RAM: 12286MB (12581352kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 4 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 5 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 6 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 7 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-d0000000
(XEN) SRAT: Node 0 PXM 0 100000000-1b0000000
(XEN) SRAT: Node 1 PXM 1 1b0000000-330000000
(XEN) NUMA: Allocated memnodemap from 32e92f000 - 32e933000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 30 bits
(XEN) found SMP MP-table at 000f8040
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x508
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[544,504], pm1x_evt[500,540]
(XEN) ACPI:                  wakeup_vec[cff02fcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) Processor #1 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
(XEN) Processor #3 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
(XEN) Processor #5 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
(XEN) Processor #6 0:2 APIC version 16
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
(XEN) Processor #7 0:2 APIC version 16
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-15
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[16])
(XEN) IOAPIC[1]: apic_id 9, version 17, address 0xfec01000, GSI 16-31
(XEN) ACPI: IOAPIC (id[0x0a] address[0xfec02000] gsi_base[32])
(XEN) IOAPIC[2]: apic_id 10, version 17, address 0xfec02000, GSI 32-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 3 I/O APICs
(XEN) ACPI: HPET id: 0x1166a201 base: 0xfed00000
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 1504 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2094.849 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD Fam10h machine check reporting enabled
(XEN) AMD-Vi: IOMMU not found!
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) HVM: ASIDs enabled.
(XEN) SVM: Supported advanced features:
(XEN)  - Nested Page Tables (NPT)
(XEN)  - Last Branch Record (LBR) Virtualisation
(XEN) HVM: SVM enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) Brought up 8 CPUs
(XEN) microcode: collect_cpu_info: patch_id=0x1000065
(XEN) HPET: 3 timers (0 will be used for broadcast)
(XEN) ACPI sleep modes: S3
(XEN) MCA: Use hw thresholding to adjust polling frequency
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0xb54000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0xab0e8
(XEN) elf_parse_binary: phdr: paddr=0x1cac000 memsz=0x12f00
(XEN) elf_parse_binary: phdr: paddr=0x1cbf000 memsz=0x5a4000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x2263000
(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 = 0xffffffff81cbf210
(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        = 0xffffffff82263000
(XEN)     virt_entry       = 0xffffffff81cbf210
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2263000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000320000000->0000000324000000 (114688 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82263000
(XEN)  Init. ramdisk: ffffffff82263000->ffffffff82263000
(XEN)  Phys-Mach map: ffffffff82263000->ffffffff82363000
(XEN)  Start info:    ffffffff82363000->ffffffff823634b4
(XEN)  Page tables:   ffffffff82364000->ffffffff82379000
(XEN)  Boot stack:    ffffffff82379000->ffffffff8237a000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82400000
(XEN)  ENTRY ADDRESS: ffffffff81cbf210
(XEN) Dom0 has maximum 8 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81b54000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81cab0e8
(XEN) elf_load_binary: phdr 2 at 0xffffffff81cac000 -> 0xffffffff81cbef00
(XEN) elf_load_binary: phdr 3 at 0xffffffff81cbf000 -> 0xffffffff81d6b000
(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 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.5.0-rc3+ (aprzywar@dosorca) (gcc version 4.5.2 (GCC) ) #103 SMP Mon Jun 18 14:11:37 CEST 2012
[    0.000000] Command line: root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
[    0.000000] Freeing 8a-100 pfn range: 118 pages freed
[    0.000000] Released 118 pages of unused memory
[    0.000000] Set 196998 page(s) to 1-1 mapping
[    0.000000] Populating 20000-20076 pfn range: 118 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x0000000000089fff] usable
[    0.000000] Xen: [mem 0x000000000008ac00-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000cfeeffff] usable
[    0.000000] Xen: [mem 0x00000000cfef0000-0x00000000cfef6fff] ACPI data
[    0.000000] Xen: [mem 0x00000000cfef7000-0x00000000cff02fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cff03000-0x00000000cfffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec02fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000fff80000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000190621fff] usable
[    0.000000] Xen: [mem 0x0000000190622000-0x000000032fffffff] unusable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x190622 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xcfef0 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000f8040-0x000f804f] mapped at [ffff8800000f8040]
[    0.000000] init_memory_mapping: [mem 0x00000000-0xcfeeffff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x190621fff]
[    0.000000] ACPI: RSDP 00000000000f8010 00024 (v02 PTLTD )
[    0.000000] ACPI: XSDT 00000000cfef0f64 00064 (v01 BRCM   Anaheim  06040000 PTL  02000001)
[    0.000000] ACPI: FACP 00000000cfef103c 000F4 (v03 BRCM   EXPLOSN  06040000 MSFT 02000001)
[    0.000000] ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0xC (20120320/tbfadt-579)
[    0.000000] ACPI: DSDT 00000000cfef1130 04777 (v02 AMD    Anaheim  06040000 MSFT 02000002)
[    0.000000] ACPI: FACS 00000000cff02fc0 00040
[    0.000000] ACPI: TCPA 00000000cfef58a7 00032 (v01 BRCM   Anaheim  06040000 PTL  20000001)
[    0.000000] ACPI: SRAT 00000000cfef58d9 00150 (v01 AMD    HAMMER   06040000 AMD  00000001)
[    0.000000] ACPI: SSDT 00000000cfef5a29 0143C (v01 AMD    POWERNOW 06040000 AMD  00000001)
[    0.000000] ACPI: HPET 00000000cfef6e65 00038 (v01 BRCM   Anaheim  06040000 BRCM 02000001)
[    0.000000] ACPI: SSDT 00000000cfef6e9d 00049 (v01 BRCM   PRT0     06040000 BRCM 02000001)
[    0.000000] ACPI: SPCR 00000000cfef6ee6 00050 (v01 PTLTD  $UCRTBL$ 06040000 PTL  00000001)
[    0.000000] ACPI: APIC 00000000cfef6f36 000CA (v01 BRCM   Anaheim  06040000 PTL  02000001)
[    0.000000] Scanning NUMA topology in Northbridge 24
[    0.000000] Number of physical nodes 2
[    0.000000] Node 0 MemBase 0000000000000000 Limit 0000000190622000
[    0.000000] Node 1 bogus settings 1b0000000-190622000.
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x190621fff]
[    0.000000]   NODE_DATA [mem 0x20072000-0x20075fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x190621fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x00089fff]
[    0.000000]   node   0: [mem 0x00100000-0xcfeeffff]
[    0.000000]   node   0: [mem 0x100000000-0x190621fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x508
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-15
[    0.000000] ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[16])
[    0.000000] IOAPIC[1]: apic_id 9, version 17, address 0xfec01000, GSI 16-31
[    0.000000] ACPI: IOAPIC (id[0x0a] address[0xfec02000] gsi_base[32])
[    0.000000] IOAPIC[2]: apic_id 10, version 17, address 0xfec02000, GSI 32-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x1166a201 base: 0xfed00000
[    0.000000] SMP: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000008a000 - 000000000008b000
[    0.000000] PM: Registered nosave memory: 000000000008b000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000cfef0000 - 00000000cfef7000
[    0.000000] PM: Registered nosave memory: 00000000cfef7000 - 00000000cff03000
[    0.000000] PM: Registered nosave memory: 00000000cff03000 - 00000000d0000000
[    0.000000] PM: Registered nosave memory: 00000000d0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec03000
[    0.000000] PM: Registered nosave memory: 00000000fec03000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000fff80000
[    0.000000] PM: Registered nosave memory: 00000000fff80000 - 0000000100000000
[    0.000000] e820: [mem 0xd0000000-0xfebfffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 26 pages/cpu @ffff88001fe00000 s77568 r8192 d20736 u262144
[    6.478463] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1415680
[    6.478467] Policy zone: Normal
[    6.478472] Kernel command line: root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
[    6.478607] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    6.478617] __ex_table already sorted, skipping sort
[    6.566265] software IO TLB [mem 0x15400000-0x193fffff] (64MB) mapped at [ffff880015400000-ffff8800193fffff]
[    6.569911] Memory: 337772k/6559880k available (6898k kernel code, 788056k absent, 5434052k reserved, 6070k data, 728k init)
[    6.570040] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    6.570102] Hierarchical RCU implementation.
[    6.570121] NR_IRQS:4352 nr_irqs:1152 16
[    6.570235] xen: sci override: global_irq=9 trigger=0 polarity=1
[    6.570273] xen: acpi sci 9
[    6.580509] Console: colour VGA+ 80x25
[    6.580517] console [hvc0] enabled, bootconsole disabled
[    6.580517] console [hvc0] enabled, bootconsole disabled
[    6.580578] installing Xen timer for CPU 0
[    6.580617] Detected 2094.848 MHz processor.
[    6.580630] Calibrating delay loop (skipped), value calculated using timer frequency.. 4189.69 BogoMIPS (lpj=8379392)
[    6.580636] pid_max: default: 32768 minimum: 301
[    6.580682] Security Framework initialized
[    6.583355] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    6.589029] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    6.591229] Mount-cache hash table entries: 256
[    6.591586] Initializing cgroup subsys cpuacct
[    6.591593] Initializing cgroup subsys blkio
[    6.591597] Initializing cgroup subsys perf_event
[    6.591603] Initializing cgroup subsys net_prio
[    6.591683] CPU: Physical Processor ID: 0
[    6.591686] CPU: Processor Core ID: 0
[    6.595474] ACPI: Core revision 20120320
[    7.006297] cpu 0 spinlock event irq 65
[    7.006332] Performance Events: AMD PMU driver.
[    7.006337] ------------[ cut here ]------------
[    7.006351] WARNING: at arch/x86/xen/enlighten.c:862 xen_apic_write+0x15/0x17()
[    7.006355] Hardware name: empty
[    7.006359] Modules linked in:
[    7.006364] Pid: 1, comm: swapper/0 Not tainted 3.5.0-rc3+ #103
[    7.006369] Call Trace:
[    7.006379]  [<ffffffff8105053b>] warn_slowpath_common+0x80/0x98
[    7.006386]  [<ffffffff81050568>] warn_slowpath_null+0x15/0x17
[    7.006392]  [<ffffffff81003411>] xen_apic_write+0x15/0x17
[    7.006398]  [<ffffffff81016dc2>] perf_events_lapic_init+0x2e/0x30
[    7.006407]  [<ffffffff81ccaaa2>] init_hw_perf_events+0x266/0x42a
[    7.006415]  [<ffffffff81008531>] ? xen_smp_intr_init+0x18c/0x263
[    7.006420]  [<ffffffff81cca83c>] ? check_bugs+0x2d/0x2d
[    7.006426]  [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
[    7.006434]  [<ffffffff81cbfbe5>] kernel_init+0x9f/0x1d0
[    7.006443]  [<ffffffff816b9764>] kernel_thread_helper+0x4/0x10
[    7.006450]  [<ffffffff816b2e38>] ? retint_restore_args+0x5/0x6
[    7.006456]  [<ffffffff816b9760>] ? gs_change+0x13/0x13
[    7.006469] ---[ end trace 4eaa2a86a8e2da22 ]---
[    7.006474] ... version:                0
[    7.006477] ... bit width:              48
[    7.006480] ... generic registers:      4
[    7.006483] ... value mask:             0000ffffffffffff
[    7.006486] ... max period:             00007fffffffffff
[    7.006489] ... fixed-purpose events:   0
[    7.006492] ... event mask:             000000000000000f
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.007193] MCE: In-kernel MCE decoding enabled.
[    7.007328] installing Xen timer for CPU 1
[    7.007347] cpu 1 spinlock event irq 72
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.007721] installing Xen timer for CPU 2
[    7.007735] cpu 2 spinlock event irq 79
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.008028] installing Xen timer for CPU 3
[    7.008042] cpu 3 spinlock event irq 86
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.008337] installing Xen timer for CPU 4
[    7.008352] cpu 4 spinlock event irq 93
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.008676] installing Xen timer for CPU 5
[    7.008691] cpu 5 spinlock event irq 100
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.009028] installing Xen timer for CPU 6
[    7.009042] cpu 6 spinlock event irq 107
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.009388] installing Xen timer for CPU 7
[    7.009402] cpu 7 spinlock event irq 114
(XEN) domain.c:700:d0 Attempt to change CR4 flags 00000660 -> 00000760
[    7.009672] Brought up 8 CPUs
[    7.010659] EVM: security.capability
[    7.010790] PM: Registering ACPI NVS region [mem 0xcfef7000-0xcff02fff] (49152 bytes)
[    7.010840] xor: automatically using best checksumming function:
[    7.050872]    generic_sse:  2684.000 MB/sec
[    7.050896] Grant tables using version 2 layout.
[    7.050917] Grant table initialized
[    7.050980] RTC time: 10:49:10, date: 06/20/12
[    7.051038] NET: Registered protocol family 16
[    7.052288] TOM: 00000000d0000000 aka 3328M
[    7.052319] TOM2: 0000000330000000 aka 13056M
[    7.052605] ACPI: bus type pci registered
[    7.052814] PCI: Using configuration type 1 for base access
[    7.052819] PCI: Using configuration type 1 for extended access
[    7.075903] bio: create slab <bio-0> at 0
[    7.144028] raid6: sse2x1    2320 MB/s
[    7.212782] raid6: sse2x2    3292 MB/s
[    7.281490] raid6: sse2x4    3456 MB/s
[    7.281494] raid6: using algorithm sse2x4 (3456 MB/s)
[    7.281498] raid6: using intx1 recovery algorithm
[    7.281603] ACPI: Added _OSI(Module Device)
[    7.281608] ACPI: Added _OSI(Processor Device)
[    7.281611] ACPI: Added _OSI(3.0 _SCP Extensions)
[    7.281615] ACPI: Added _OSI(Processor Aggregator Device)
[    7.288311] ACPI: Interpreter enabled
[    7.288332] ACPI: (supports S0 S1 S5)
[    7.288338] ACPI: Using IOAPIC for interrupt routing
[    7.302182] ACPI: No dock devices found.
[    7.302191] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    7.303385] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
[    7.304756] pci_root PNP0A08:00: host bridge window [io  0x0000-0x03af]
[    7.304762] pci_root PNP0A08:00: host bridge window [io  0x03e0-0x0fff]
[    7.304768] pci_root PNP0A08:00: host bridge window [io  0x03b0-0x03df]
[    7.304773] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
[    7.304779] pci_root PNP0A08:00: host bridge window [io  0x1000-0x6fff]
[    7.304784] pci_root PNP0A08:00: host bridge window [io  0x7000-0xffff]
[    7.304789] pci_root PNP0A08:00: host bridge window [mem 0xfec00000-0xfecfffff]
[    7.304795] pci_root PNP0A08:00: host bridge window [mem 0xe8000000-0xefffffff]
[    7.304800] pci_root PNP0A08:00: host bridge window [mem 0xd8000000-0xd84fffff]
[    7.304806] pci_root PNP0A08:00: host bridge window [mem 0xd0000000-0xd7ffffff]
[    7.304811] pci_root PNP0A08:00: host bridge window [mem 0xfe000000-0xfebfffff]
[    7.304817] pci_root PNP0A08:00: host bridge window [mem 0xfec04000-0xfecfffff]
[    7.304822] pci_root PNP0A08:00: host bridge window [mem 0xfed00400-0xfed07fff]
[    7.304828] pci_root PNP0A08:00: host bridge window [mem 0xfed08008-0xfedfffff]
[    7.304834] pci_root PNP0A08:00: host bridge window [mem 0xfee01000-0xffffffff]
[    7.304841] pci_root PNP0A08:00: host bridge window expanded to [mem 0xfec00000-0xfecfffff]; [mem 0xfec04000-0xfecfffff] ignored
[    7.304955] PCI host bridge to bus 0000:00
[    7.304961] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    7.304966] pci_bus 0000:00: root bus resource [io  0x03e0-0x0fff]
[    7.304972] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    7.304977] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    7.304982] pci_bus 0000:00: root bus resource [io  0x1000-0x6fff]
[    7.304987] pci_bus 0000:00: root bus resource [io  0x7000-0xffff]
[    7.304992] pci_bus 0000:00: root bus resource [mem 0xfec00000-0xfecfffff]
[    7.304998] pci_bus 0000:00: root bus resource [mem 0xe8000000-0xefffffff]
[    7.305003] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xd84fffff]
[    7.305008] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xd7ffffff]
[    7.305014] pci_bus 0000:00: root bus resource [mem 0xfe000000-0xfebfffff]
[    7.305019] pci_bus 0000:00: root bus resource [mem 0xfed00400-0xfed07fff]
[    7.305024] pci_bus 0000:00: root bus resource [mem 0xfed08008-0xfedfffff]
[    7.305030] pci_bus 0000:00: root bus resource [mem 0xfee01000-0xffffffff]
[    7.305214] pci 0000:00:01.0: Enabling HT MSI Mapping
[    7.310204] pci 0000:00:01.0: PCI bridge to [bus 01-02]
[    7.310330] pci 0000:01:0d.0: PCI bridge to [bus 02-02]
[    7.310494] pci 0000:00:06.0: PCI bridge to [bus 03-03]
[    7.310611] pci 0000:00:07.0: PCI bridge to [bus 04-04]
[    7.310728] pci 0000:00:08.0: PCI bridge to [bus 05-05]
[    7.310845] pci 0000:00:09.0: PCI bridge to [bus 06-06]
[    7.311203] pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    7.311225] pci 0000:00:0a.0: PCI bridge to [bus 07-08]
[    7.311961] pci 0000:07:00.0: PCI bridge to [bus 08-08]
[    7.312601]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    7.312608]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[    7.312613] ACPI _OSC control for PCIe not granted, disabling ASPM
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:02.1
(XEN) PCI add device 0000:00:02.2
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:03.1
(XEN) PCI add device 0000:00:03.2
(XEN) PCI add device 0000:00:04.0
(XEN) PCI add device 0000:00:06.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:08.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add device 0000:00:18.0
(XEN) PCI add device 0000:00:18.1
(XEN) PCI add device 0000:00:18.2
(XEN) PCI add device 0000:00:18.3
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:00:19.0
(XEN) PCI add device 0000:00:19.1
(XEN) PCI add device 0000:00:19.2
(XEN) PCI add device 0000:00:19.3
(XEN) PCI add device 0000:00:19.4
(XEN) PCI add device 0000:01:0d.0
(XEN) PCI add device 0000:01:0e.0
(XEN) PCI add device 0000:01:0e.1
(XEN) PCI add device 0000:07:00.0
(XEN) PCI add device 0000:08:04.0
(XEN) PCI add device 0000:08:04.1
[    7.320699] ACPI: PCI Interrupt Link [LNKU] (IRQs *10 11)
[    7.320751] ACPI: PCI Interrupt Link [LNKW] (IRQs 10 11) *0, disabled.
[    7.320824] ACPI: PCI Interrupt Link [LNKS] (IRQs 5 *7 11)
[    7.320938] ACPI: PCI Interrupt Link [LN00] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.320984] ACPI: PCI Interrupt Link [LN01] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321049] ACPI: PCI Interrupt Link [LN02] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321098] ACPI: PCI Interrupt Link [LN03] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321158] ACPI: PCI Interrupt Link [LN04] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321218] ACPI: PCI Interrupt Link [LN05] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321268] ACPI: PCI Interrupt Link [LN06] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321317] ACPI: PCI Interrupt Link [LN07] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321370] ACPI: PCI Interrupt Link [LN08] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321432] ACPI: PCI Interrupt Link [LN09] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321488] ACPI: PCI Interrupt Link [LN0A] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321548] ACPI: PCI Interrupt Link [LN0B] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321610] ACPI: PCI Interrupt Link [LN0C] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321666] ACPI: PCI Interrupt Link [LN0D] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321709] ACPI: PCI Interrupt Link [LN0E] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321779] ACPI: PCI Interrupt Link [LN0F] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321844] ACPI: PCI Interrupt Link [LN10] (IRQs 3 4 5 7 *11 12 14 15)
[    7.321908] ACPI: PCI Interrupt Link [LN11] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.321963] ACPI: PCI Interrupt Link [LN12] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322018] ACPI: PCI Interrupt Link [LN13] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322100] ACPI: PCI Interrupt Link [LN14] (IRQs 3 4 *5 7 11 12 14 15)
[    7.322153] ACPI: PCI Interrupt Link [LN15] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322208] ACPI: PCI Interrupt Link [LN16] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322306] ACPI: PCI Interrupt Link [LN17] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322383] ACPI: PCI Interrupt Link [LN18] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322423] ACPI: PCI Interrupt Link [LN19] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322487] ACPI: PCI Interrupt Link [LN1A] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322565] ACPI: PCI Interrupt Link [LN1B] (IRQs 3 4 *5 7 11 12 14 15)
[    7.322616] ACPI: PCI Interrupt Link [LN1C] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322664] ACPI: PCI Interrupt Link [LN1D] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322732] ACPI: PCI Interrupt Link [LN1E] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322779] ACPI: PCI Interrupt Link [LN1F] (IRQs 3 4 5 7 11 12 14 15) *0, disabled.
[    7.322957] xen/balloon: Initialising balloon driver.
[    7.366475] xen-balloon: Initialising balloon driver.
[    7.366941] vgaarb: device added: PCI:0000:00:04.0,decodes=io+mem,owns=io+mem,locks=none
[    7.366966] vgaarb: loaded
[    7.366969] vgaarb: bridge control possible 0000:00:04.0
[    7.367272] SCSI subsystem initialized
[    7.367777] ACPI: bus type usb registered
[    7.367949] usbcore: registered new interface driver usbfs
[    7.368037] usbcore: registered new interface driver hub
[    7.368160] usbcore: registered new device driver usb
[    7.368734] Advanced Linux Sound Architecture Driver Version 1.0.25.
[    7.368740] PCI: Using ACPI for IRQ routing
[    7.369374] NetLabel: Initializing
[    7.369378] NetLabel:  domain hash size = 128
[    7.369382] NetLabel:  protocols = UNLABELED CIPSOv4
[    7.369444] NetLabel:  unlabeled traffic allowed by default
[    7.369626] Switching to clocksource xen
[    7.369827] pnp: PnP ACPI init
[    7.369841] ACPI: bus type pnp registered
[    7.370049] system 00:00: [mem 0xfed08000-0xfed08007] has been reserved
[    7.370828] system 00:01: [mem 0xe0000000-0xefffffff] could not be reserved
[    7.373707] system 00:0b: [io  0x040b] has been reserved
[    7.373713] system 00:0b: [io  0x04d0-0x04d1] has been reserved
[    7.373720] system 00:0b: [io  0x04d6] has been reserved
[    7.373725] system 00:0b: [io  0x0500-0x0560] has been reserved
[    7.373730] system 00:0b: [io  0x0558-0x055b] has been reserved
[    7.373736] system 00:0b: [io  0x0580-0x058f] has been reserved
[    7.373741] system 00:0b: [io  0x0590-0x0593] has been reserved
[    7.373746] system 00:0b: [io  0x0600-0x061f] has been reserved
[    7.373751] system 00:0b: [io  0x0620-0x0623] has been reserved
[    7.373759] system 00:0b: [io  0x0700-0x0703] has been reserved
[    7.373767] system 00:0b: [io  0x0c00-0x0c01] has been reserved
[    7.373772] system 00:0b: [io  0x0c06-0x0c08] has been reserved
[    7.373777] system 00:0b: [io  0x0c14] has been reserved
[    7.373782] system 00:0b: [io  0x0c49-0x0c4a] has been reserved
[    7.373787] system 00:0b: [io  0x0c50-0x0c53] has been reserved
[    7.373792] system 00:0b: [io  0x0c6c] has been reserved
[    7.373797] system 00:0b: [io  0x0c6f] has been reserved
[    7.373802] system 00:0b: [io  0x0cd6-0x0cd7] has been reserved
[    7.373807] system 00:0b: [io  0x0cf9] could not be reserved
[    7.373813] system 00:0b: [io  0x0f50-0x0f58] has been reserved
[    7.373966] Already setup the GSI :4
[    7.375025] pnp: PnP ACPI: found 16 devices
[    7.375029] ACPI: ACPI bus type pnp unregistered
[    7.386348] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    7.386597] pci 0000:00:01.0: BAR 15: assigned [mem 0xe8000000-0xe80fffff pref]
[    7.386605] pci 0000:00:04.0: BAR 6: assigned [mem 0xfec20000-0xfec3ffff pref]
[    7.386615] pci 0000:01:0e.0: BAR 6: assigned [mem 0xe8000000-0xe801ffff pref]
[    7.386621] pci 0000:01:0d.0: PCI bridge to [bus 02-02]
[    7.386641] pci 0000:00:01.0: PCI bridge to [bus 01-02]
[    7.386647] pci 0000:00:01.0:   bridge window [io  0x6000-0x6fff]
[    7.386657] pci 0000:00:01.0:   bridge window [mem 0xd8100000-0xd81fffff]
[    7.386671] pci 0000:00:01.0:   bridge window [mem 0xe8000000-0xe80fffff pref]
[    7.386694] pci 0000:00:06.0: PCI bridge to [bus 03-03]
[    7.386723] pci 0000:00:07.0: PCI bridge to [bus 04-04]
[    7.386765] pci 0000:00:08.0: PCI bridge to [bus 05-05]
[    7.386809] pci 0000:00:09.0: PCI bridge to [bus 06-06]
[    7.386838] pci 0000:07:00.0: PCI bridge to [bus 08-08]
[    7.386854] pci 0000:07:00.0:   bridge window [mem 0xd8000000-0xd80fffff]
[    7.386902] pci 0000:00:0a.0: PCI bridge to [bus 07-08]
[    7.386918] pci 0000:00:0a.0:   bridge window [mem 0xd8000000-0xd80fffff]
[    7.387036] Already setup the GSI :32
[    7.387056] Already setup the GSI :32
[    7.387066] Already setup the GSI :32
[    7.387077] Already setup the GSI :32
[    7.387185] NET: Registered protocol family 2
[    7.387503] IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
[    7.389348] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    7.391853] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    7.392402] TCP: Hash tables configured (established 262144 bind 65536)
[    7.392409] TCP: reno registered
[    7.392508] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    7.392632] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    7.392849] NET: Registered protocol family 1
[    7.393089] RPC: Registered named UNIX socket transport module.
[    7.393096] RPC: Registered udp transport module.
[    7.393105] RPC: Registered tcp transport module.
[    7.393108] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    7.393302] pci 0000:00:02.0: disabled boot interrupts on device [1166:0205]
[    7.393480] ACPI: PCI Interrupt Link [LNKU] enabled at IRQ 10
[    7.445860] Already setup the GSI :10
[    7.501776] Already setup the GSI :10
[    7.504275] microcode: CPU0: patch_level=0x01000065
[    7.504286] microcode: CPU1: patch_level=0x01000065
[    7.504306] microcode: CPU2: patch_level=0x01000065
[    7.504330] microcode: CPU3: patch_level=0x01000065
[    7.504355] microcode: CPU4: patch_level=0x01000065
[    7.504377] microcode: CPU5: patch_level=0x01000065
[    7.504403] microcode: CPU6: patch_level=0x01000065
[    7.504430] microcode: CPU7: patch_level=0x01000065
[    7.504530] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    7.506353] sha1_ssse3: Neither AVX nor SSSE3 is available/usable.
[    7.506880] audit: initializing netlink socket (disabled)
[    7.506913] type=2000 audit(1340189350.092:1): initialized
[    7.540089] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    7.546507] VFS: Disk quotas dquot_6.5.2
[    7.546632] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    7.548235] NFS: Registering the id_resolver key type
[    7.548256] Key type id_resolver registered
[    7.548934] fuse init (API version 7.19)
[    7.549329] msgmni has been set to 659
[    7.551203] NET: Registered protocol family 38
[    7.551391] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    7.551398] io scheduler noop registered
[    7.551402] io scheduler deadline registered
[    7.551601] io scheduler cfq registered (default)
[    7.553669] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0C:00/input/input0
[    7.553679] ACPI: Power Button [PWRB]
[    7.553888] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    7.553894] ACPI: Power Button [PWRF]
[    7.554059] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input2
[    7.554065] ACPI: Sleep Button [SLPF]
[    7.560418] Event-channel device installed.
[    7.561677] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
(XEN) Cannot bind IRQ4 to dom0. In use by 'ns16550'.
(XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'.
[    7.837905] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    7.859709] 00:0d: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    7.860308] hpet_acpi_add: no address or irqs in _CRS
[    7.860512] Non-volatile memory driver v1.3
[    7.860592] Linux agpgart interface v0.103
[    7.863161] [drm] Initialized drm 1.1.0 20060810
[    7.863167] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[    7.866674] brd: module loaded
[    7.868524] loop: module loaded
[    7.869066] nbd: registered device at major 43
[    7.872550] Loading iSCSI transport class v2.0-870.
[    7.874722] ACPI: PCI Interrupt Link [LNKS] enabled at IRQ 11
[    7.876203] scsi0 : sata_svw
[    7.876467] scsi1 : sata_svw
[    7.876699] scsi2 : sata_svw
[    7.876971] scsi3 : sata_svw
[    7.877156] ata1: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100000 irq 11
[    7.877162] ata2: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100100 irq 11
[    7.877168] ata3: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100200 irq 11
[    7.877177] ata4: SATA max UDMA/133 mmio m8192@0xd8100000 port 0xd8100300 irq 11
[    7.877346] Already setup the GSI :11
[    7.879305] scsi4 : pata_serverworks
[    7.879539] scsi5 : pata_serverworks
[    7.879885] ata5: PATA max UDMA/66 cmd 0x1f0 ctl 0x3f6 bmdma 0x4800 irq 14
[    7.879894] ata6: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0x4808 irq 15
[    7.882842] tun: Universal TUN/TAP device driver, 1.6
[    7.882848] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    7.883212] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
[    7.883464] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.10 (March 21, 2012)
[    7.883609] tg3.c:v3.123 (March 21, 2012)
[    7.943267] tg3 0000:08:04.0: eth0: Tigon3 [partno(BCM95715) rev 9003] (PCIX:133MHz:64-bit) MAC address 00:e0:81:80:1d:9c
[    7.943281] tg3 0000:08:04.0: eth0: attached PHY is 5714 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[    7.943288] tg3 0000:08:04.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    7.943294] tg3 0000:08:04.0: eth0: dma_rwctrl[76148000] dma_mask[40-bit]
[    7.943487] Already setup the GSI :36
[    7.988541] tg3 0000:08:04.1: eth1: Tigon3 [partno(BCM95715) rev 9003] (PCIX:133MHz:64-bit) MAC address 00:e0:81:80:1d:9d
[    7.988550] tg3 0000:08:04.1: eth1: attached PHY is 5714 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[    7.988557] tg3 0000:08:04.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    7.988563] tg3 0000:08:04.1: eth1: dma_rwctrl[76148000] dma_mask[40-bit]
[    7.988733] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[    7.988738] e100: Copyright(c) 1999-2006 Intel Corporation
[    7.988835] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    7.988840] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    7.988938] e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
[    7.988942] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    7.989044] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.6.0-k
[    7.989049] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    7.989136] sky2: driver version 1.30
[    7.989683] Initialising Xen virtual ethernet driver.
[    7.989761] Fusion MPT base driver 3.04.20
[    7.989765] Copyright (c) 1999-2008 LSI Corporation
[    7.989781] Fusion MPT SAS Host driver 3.04.20
[    7.989881] Fusion MPT misc device (ioctl) driver 3.04.20
[    7.989970] mptctl: Registered with Fusion MPT base driver
[    7.989974] mptctl: /dev/mptctl @ (major,minor=10,220)
[    7.990251] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    7.990437] Already setup the GSI :10
[    7.990466] ehci_hcd 0000:00:03.2: EHCI Host Controller
[    7.990645] ehci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 1
[    8.017764] ehci_hcd 0000:00:03.2: irq 10, io mem 0xd8412000
[    8.029737] ehci_hcd 0000:00:03.2: USB 2.0 started, EHCI 1.00
[    8.029789] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    8.029798] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.029803] usb usb1: Product: EHCI Host Controller
[    8.029808] usb usb1: Manufacturer: Linux 3.5.0-rc3+ ehci_hcd
[    8.029812] usb usb1: SerialNumber: 0000:00:03.2
[    8.030088] hub 1-0:1.0: USB hub found
[    8.030096] hub 1-0:1.0: 4 ports detected
[    8.030321] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    8.030500] Already setup the GSI :10
[    8.030527] ohci_hcd 0000:00:03.0: OHCI Host Controller
[    8.030641] ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2
[    8.030684] ohci_hcd 0000:00:03.0: irq 10, io mem 0xd8410000
[    8.042313] ata5.01: ATAPI: DV-28E-R, 1.8A, max UDMA/33
[    8.058292] ata5.01: configured for UDMA/33
[    8.085871] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    8.085877] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.085882] usb usb2: Product: OHCI Host Controller
[    8.085886] usb usb2: Manufacturer: Linux 3.5.0-rc3+ ohci_hcd
[    8.085891] usb usb2: SerialNumber: 0000:00:03.0
[    8.086152] hub 2-0:1.0: USB hub found
[    8.086162] hub 2-0:1.0: 2 ports detected
[    8.086355] Already setup the GSI :10
[    8.086381] ohci_hcd 0000:00:03.1: OHCI Host Controller
[    8.086485] ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 3
[    8.086533] ohci_hcd 0000:00:03.1[    8.972360] ata3: SATA link down (SStatus 4 SControl 300)
[    9.300339] ata4: SATA link down (SStatus 4 SControl 300)
[    9.304551] scsi 4:0:1:0: CD-ROM            TEAC     DV-28E-R         1.8A PQ: 0 ANSI: 5
[    9.309465] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
[    9.309471] cdrom: Uniform CD-ROM driver Revision: 3.20
[    9.309933] sr 4:0:1:0: Attached scsi generic sg1 type 5
[    9.465898] md: Waiting for all devices to be available before autodetect
[    9.465905] md: If you don't use raid, use raid=noautodetect
[    9.466217] md: Autodetecting RAID arrays.
[    9.466221] md: Scanned 0 and added 0 devices.
[    9.466225] md: autorun ...
[    9.466227] md: ... autorun DONE.
[    9.618177] kjournald starting.  Commit interval 5 seconds
[    9.618515] EXT3-fs (sda2): using internal journal
[    9.634755] EXT3-fs (sda2): recovery complete
[    9.634773] EXT3-fs (sda2): mounted filesystem with writeback data mode
[    9.634812] VFS: Mounted root (ext3 filesystem) on device 8:2.
[    9.635302] Freeing unused kernel memory: 728k freed
[    9.635605] Write protecting the kernel read-only data: 12288k
[    9.642755] Freeing unused kernel memory: 1280k freed
[    9.643732] Freeing unused kernel memory: 688k freed
[   10.945707] udevd (1368): /proc/1368/oom_adj is deprecated, please use /proc/1368/oom_score_adj instead.
[   10.945761] udevd version 128 started
[   12.146999] Adding 7815584k swap on /dev/sda1.  Priority:-1 extents:1 across:7815584k 
[   13.829592] dd: sending ioctl 801c6d02 to a partition!
[   13.829613] dd: sending ioctl 80306d02 to a partition!
[   13.829618] dd: sending ioctl 80306d02 to a partition!
[   18.907214] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

--------------010709040101000902080703
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010709040101000902080703--


From xen-devel-bounces@lists.xen.org Wed Jun 20 13:03:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShKYw-0003TD-76; Wed, 20 Jun 2012 13:03:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShKYv-0003T8-64
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:03:09 +0000
Received: from [85.158.143.35:41564] by server-2.bemta-4.messagelabs.com id
	29/5D-17938-C0AC1EF4; Wed, 20 Jun 2012 13:03:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340197387!15428032!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13721 invoked from network); 20 Jun 2012 13:03:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 13:03:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 14:03:07 +0100
Message-Id: <4FE1E656020000780008AD62@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 14:03:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH, v2] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Jan Beulich <jbeulich@suse.com>

---
v2: Switch to using markdown as suggested by Ian Campbell.
    Also document obvious config file options, as also suggested by Ian.

--- /dev/null
+++ b/docs/misc/efi.markdown
@@ -0,0 +1,79 @@
+Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, as
+4.5.x was probably never really tested for this purpose) and binutils 2.22 or
+newer. Additionally, the binutils build must be configured to include support
+for the x86_64-pep emulation (i.e. `--enable-targets=x86_64-pep` or an option
+of equivalent effect should be passed to the configure script).
+
+Once built, `make install-xen` can place the resulting binary directly into
+the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
+`EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
+match your system).
+
+The binary itself will require a configuration file (names with the `.efi`
+extension of the binary's name replaced by `.cfg`, and - until an existing
+file is found - trailing name components dropped at `.`, `-`, and `_`
+separators will be tried) to be present in the same directory as the binary.
+(To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
+try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
+order.) One can override this with a command line option (`-cfg=<filename>`).
+
+The configuration file consists of one or more sections headed by a section
+name enclosed in square brackets, with individual values specified in each
+section. A section named `[global]` is treated specially to allow certain
+settings to apply to all other sections (or to provide defaults for certain
+settings in case individual sections don't specify them). A typical file would
+thus look like this (`#` serving as comment character):
+
+    **************************example begin******************************
+
+    [global]
+    default=sle11sp2
+    
+    [sle11sp2]
+    options=console=vga,com1 com1=57600 loglvl=all noreboot
+    kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
+    ramdisk=initrd-3.0.31-0.4-xen
+
+    **************************example end********************************
+
+The individual values used here are:
+
+###`default=<name>`
+
+Specifies the section to use for booting, if none was specified on the command
+line; only meaningful in the `[global]` section. This isn't required; if
+absent, section headers will be ignored and for each value looked for the
+first instance within the file will be used.
+
+###`options=<text>`
+
+Specifies the options passed to the hypervisor, see [Xen Hypervisor Command
+Line Options](xen-command-line.html).
+
+###`kernel=<filename>[ <options>]`
+
+Specifies the Dom0 kernel binary and the options to pass to it.
+
+###`ramdisk=<filename>`
+
+Specifies a Linux-style initial RAM disk image to load.
+
+Other values to specify are:
+
+###`video=gfx-<xres>[x<yres>[x<depth>]]`
+
+Specifies a video mode to select if available. In case of problems, the
+`-basevideo` command line option can be used to skip altering video modes.
+
+###`xsm=<filename>`
+
+Specifies an XSM module to load.
+
+###`ucode=<filename>`
+
+Specifies a CPU microcode blob to load.
+
+Filenames must be specified relative to the location of the EFI binary.
+
+Extra options to be passed to Xen can also be specified on the command line,
+following a `--` separator option.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:03:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShKYw-0003TD-76; Wed, 20 Jun 2012 13:03:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShKYv-0003T8-64
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:03:09 +0000
Received: from [85.158.143.35:41564] by server-2.bemta-4.messagelabs.com id
	29/5D-17938-C0AC1EF4; Wed, 20 Jun 2012 13:03:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340197387!15428032!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13721 invoked from network); 20 Jun 2012 13:03:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 13:03:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 14:03:07 +0100
Message-Id: <4FE1E656020000780008AD62@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 14:03:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH, v2] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Jan Beulich <jbeulich@suse.com>

---
v2: Switch to using markdown as suggested by Ian Campbell.
    Also document obvious config file options, as also suggested by Ian.

--- /dev/null
+++ b/docs/misc/efi.markdown
@@ -0,0 +1,79 @@
+Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, as
+4.5.x was probably never really tested for this purpose) and binutils 2.22 or
+newer. Additionally, the binutils build must be configured to include support
+for the x86_64-pep emulation (i.e. `--enable-targets=x86_64-pep` or an option
+of equivalent effect should be passed to the configure script).
+
+Once built, `make install-xen` can place the resulting binary directly into
+the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
+`EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
+match your system).
+
+The binary itself will require a configuration file (names with the `.efi`
+extension of the binary's name replaced by `.cfg`, and - until an existing
+file is found - trailing name components dropped at `.`, `-`, and `_`
+separators will be tried) to be present in the same directory as the binary.
+(To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
+try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
+order.) One can override this with a command line option (`-cfg=<filename>`).
+
+The configuration file consists of one or more sections headed by a section
+name enclosed in square brackets, with individual values specified in each
+section. A section named `[global]` is treated specially to allow certain
+settings to apply to all other sections (or to provide defaults for certain
+settings in case individual sections don't specify them). A typical file would
+thus look like this (`#` serving as comment character):
+
+    **************************example begin******************************
+
+    [global]
+    default=sle11sp2
+    
+    [sle11sp2]
+    options=console=vga,com1 com1=57600 loglvl=all noreboot
+    kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
+    ramdisk=initrd-3.0.31-0.4-xen
+
+    **************************example end********************************
+
+The individual values used here are:
+
+###`default=<name>`
+
+Specifies the section to use for booting, if none was specified on the command
+line; only meaningful in the `[global]` section. This isn't required; if
+absent, section headers will be ignored and for each value looked for the
+first instance within the file will be used.
+
+###`options=<text>`
+
+Specifies the options passed to the hypervisor, see [Xen Hypervisor Command
+Line Options](xen-command-line.html).
+
+###`kernel=<filename>[ <options>]`
+
+Specifies the Dom0 kernel binary and the options to pass to it.
+
+###`ramdisk=<filename>`
+
+Specifies a Linux-style initial RAM disk image to load.
+
+Other values to specify are:
+
+###`video=gfx-<xres>[x<yres>[x<depth>]]`
+
+Specifies a video mode to select if available. In case of problems, the
+`-basevideo` command line option can be used to skip altering video modes.
+
+###`xsm=<filename>`
+
+Specifies an XSM module to load.
+
+###`ucode=<filename>`
+
+Specifies a CPU microcode blob to load.
+
+Filenames must be specified relative to the location of the EFI binary.
+
+Extra options to be passed to Xen can also be specified on the command line,
+following a `--` separator option.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:06:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:06: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 1ShKc7-0003ac-Qi; Wed, 20 Jun 2012 13:06:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShKc5-0003aS-Lp
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:06:25 +0000
Received: from [85.158.143.35:7166] by server-2.bemta-4.messagelabs.com id
	51/95-17938-0DAC1EF4; Wed, 20 Jun 2012 13:06:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340197582!6193957!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23029 invoked from network); 20 Jun 2012 13:06:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 13:06:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 14:06:22 +0100
Message-Id: <4FE1E718020000780008AD65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 14:07:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>
In-Reply-To: <4FE1B777.4010407@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.06.12 at 13:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 20/06/12 12:29, Ian Campbell wrote:
>> hypervisor, blockers:
>>
>>     * None
> 
> Not certain if this is a blocker or nice-to-have, but we have identified
> a regression with Xen's ability to boot, suppectedly due to c/s
> 25336:edd7c7ad1ad2 "x86: adjust handling of interrupts coming in via
> legacy vectors" on AMD hardware with an MP-BIOS bug claiming that the
> PIT is not connected through the IO-APIC.  Fixing this is next on my
> todo list, and I hope to have a solution available by the end of the week.

Sure this (being a regression) is a blocker. Care to share any
details, e.g. a hypervisor logs with "apic_verbosity=debug" without
and with that c/s?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:06:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:06: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 1ShKc7-0003ac-Qi; Wed, 20 Jun 2012 13:06:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShKc5-0003aS-Lp
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:06:25 +0000
Received: from [85.158.143.35:7166] by server-2.bemta-4.messagelabs.com id
	51/95-17938-0DAC1EF4; Wed, 20 Jun 2012 13:06:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340197582!6193957!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23029 invoked from network); 20 Jun 2012 13:06:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 13:06:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 14:06:22 +0100
Message-Id: <4FE1E718020000780008AD65@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 14:07:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>
In-Reply-To: <4FE1B777.4010407@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.06.12 at 13:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 20/06/12 12:29, Ian Campbell wrote:
>> hypervisor, blockers:
>>
>>     * None
> 
> Not certain if this is a blocker or nice-to-have, but we have identified
> a regression with Xen's ability to boot, suppectedly due to c/s
> 25336:edd7c7ad1ad2 "x86: adjust handling of interrupts coming in via
> legacy vectors" on AMD hardware with an MP-BIOS bug claiming that the
> PIT is not connected through the IO-APIC.  Fixing this is next on my
> todo list, and I hope to have a solution available by the end of the week.

Sure this (being a regression) is a blocker. Care to share any
details, e.g. a hypervisor logs with "apic_verbosity=debug" without
and with that c/s?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:11:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShKgO-0003lx-GN; Wed, 20 Jun 2012 13:10: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 1ShKgN-0003ls-3R
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:10:51 +0000
Received: from [85.158.138.51:25779] by server-3.bemta-3.messagelabs.com id
	10/30-26490-ADBC1EF4; Wed, 20 Jun 2012 13:10:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340197849!28702448!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21610 invoked from network); 20 Jun 2012 13:10:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	20 Jun 2012 13:10:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 14:10:48 +0100
Message-Id: <4FE1E823020000780008AD6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 14:11:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20120620121539.GA18219@aepfle.de>
In-Reply-To: <20120620121539.GA18219@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grant table errors with qemu-xen-traditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 14:15, Olaf Hering <olaf@aepfle.de> wrote:

> I'm not sure if thats guest or host related, but current xen-unstable
> with device_model_version="qemu-xen-traditional" fail to access the
> block device properly, both PV and HVM are affected. The guest runs the
> upcoming 12.2 kernel, which is based on forward ported xenlinux sources.
> 
> I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
> qemu-xen-traditional, but that does not seem to help.
> 
> Any idea whats wrong?

Did you verify that the added code actually gets executed? The
log messages provided suggest that the limit didn't really get
raised from its default of 128.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:11:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShKgO-0003lx-GN; Wed, 20 Jun 2012 13:10: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 1ShKgN-0003ls-3R
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:10:51 +0000
Received: from [85.158.138.51:25779] by server-3.bemta-3.messagelabs.com id
	10/30-26490-ADBC1EF4; Wed, 20 Jun 2012 13:10:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340197849!28702448!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21610 invoked from network); 20 Jun 2012 13:10:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	20 Jun 2012 13:10:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 14:10:48 +0100
Message-Id: <4FE1E823020000780008AD6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 14:11:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20120620121539.GA18219@aepfle.de>
In-Reply-To: <20120620121539.GA18219@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grant table errors with qemu-xen-traditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 14:15, Olaf Hering <olaf@aepfle.de> wrote:

> I'm not sure if thats guest or host related, but current xen-unstable
> with device_model_version="qemu-xen-traditional" fail to access the
> block device properly, both PV and HVM are affected. The guest runs the
> upcoming 12.2 kernel, which is based on forward ported xenlinux sources.
> 
> I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
> qemu-xen-traditional, but that does not seem to help.
> 
> Any idea whats wrong?

Did you verify that the added code actually gets executed? The
log messages provided suggest that the limit didn't really get
raised from its default of 128.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShKow-0003xM-I7; Wed, 20 Jun 2012 13:19:42 +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 1ShKou-0003xH-Pa
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:19:40 +0000
Received: from [85.158.143.35:57077] by server-2.bemta-4.messagelabs.com id
	DF/13-17938-CEDC1EF4; Wed, 20 Jun 2012 13:19:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340198378!14710602!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26001 invoked from network); 20 Jun 2012 13:19:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336363200"; d="scan'208";a="28761030"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:19:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 09:19:09 -0400
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 1ShKoP-0005pp-Cf;
	Wed, 20 Jun 2012 14:19:09 +0100
Message-ID: <4FE1CDCD.4090009@citrix.com>
Date: Wed, 20 Jun 2012 14:19:09 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>
	<4FE1E718020000780008AD65@nat28.tlf.novell.com>
In-Reply-To: <4FE1E718020000780008AD65@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/06/12 14:07, Jan Beulich wrote:
>>>> On 20.06.12 at 13:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 20/06/12 12:29, Ian Campbell wrote:
>>> hypervisor, blockers:
>>>
>>>     * None
>> Not certain if this is a blocker or nice-to-have, but we have identified
>> a regression with Xen's ability to boot, suppectedly due to c/s
>> 25336:edd7c7ad1ad2 "x86: adjust handling of interrupts coming in via
>> legacy vectors" on AMD hardware with an MP-BIOS bug claiming that the
>> PIT is not connected through the IO-APIC.  Fixing this is next on my
>> todo list, and I hope to have a solution available by the end of the week.
> Sure this (being a regression) is a blocker. Care to share any
> details, e.g. a hypervisor logs with "apic_verbosity=debug" without
> and with that c/s?
>
> Jan
>

I have not investigated yet as I am just wrapping up a more important
issue, but the issue was a constant console spam saying no handler for
vector 0xe5, which was causing the server to run like treacle.  The
issue started occurring shortly after I backported c/s 25336 to
XenServer, which is why I suspect it as the culprit.  Having said that,
the patch appears to work fine on every other server we have, so I
suspect its some motherboard quirk; it is a slightly old AMD box we
have, and is 100% reproducible.  I am hoping to have time to start
looking at the problem this afternoon.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShKow-0003xM-I7; Wed, 20 Jun 2012 13:19:42 +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 1ShKou-0003xH-Pa
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:19:40 +0000
Received: from [85.158.143.35:57077] by server-2.bemta-4.messagelabs.com id
	DF/13-17938-CEDC1EF4; Wed, 20 Jun 2012 13:19:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340198378!14710602!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26001 invoked from network); 20 Jun 2012 13:19:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336363200"; d="scan'208";a="28761030"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 09:19:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 09:19:09 -0400
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 1ShKoP-0005pp-Cf;
	Wed, 20 Jun 2012 14:19:09 +0100
Message-ID: <4FE1CDCD.4090009@citrix.com>
Date: Wed, 20 Jun 2012 14:19:09 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>
	<4FE1E718020000780008AD65@nat28.tlf.novell.com>
In-Reply-To: <4FE1E718020000780008AD65@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/06/12 14:07, Jan Beulich wrote:
>>>> On 20.06.12 at 13:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 20/06/12 12:29, Ian Campbell wrote:
>>> hypervisor, blockers:
>>>
>>>     * None
>> Not certain if this is a blocker or nice-to-have, but we have identified
>> a regression with Xen's ability to boot, suppectedly due to c/s
>> 25336:edd7c7ad1ad2 "x86: adjust handling of interrupts coming in via
>> legacy vectors" on AMD hardware with an MP-BIOS bug claiming that the
>> PIT is not connected through the IO-APIC.  Fixing this is next on my
>> todo list, and I hope to have a solution available by the end of the week.
> Sure this (being a regression) is a blocker. Care to share any
> details, e.g. a hypervisor logs with "apic_verbosity=debug" without
> and with that c/s?
>
> Jan
>

I have not investigated yet as I am just wrapping up a more important
issue, but the issue was a constant console spam saying no handler for
vector 0xe5, which was causing the server to run like treacle.  The
issue started occurring shortly after I backported c/s 25336 to
XenServer, which is why I suspect it as the culprit.  Having said that,
the patch appears to work fine on every other server we have, so I
suspect its some motherboard quirk; it is a slightly old AMD box we
have, and is 100% reproducible.  I am hoping to have time to start
looking at the problem this afternoon.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:37:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShL6H-0004CG-Cq; Wed, 20 Jun 2012 13:37: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 1ShL6F-0004CB-Iw
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:37:35 +0000
Received: from [85.158.143.99:16206] by server-2.bemta-4.messagelabs.com id
	9C/0A-17938-E12D1EF4; Wed, 20 Jun 2012 13:37:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340199452!18495804!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5728 invoked from network); 20 Jun 2012 13:37:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:37:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:37:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:37:26 +0100
Message-ID: <1340199444.4906.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 20 Jun 2012 14:37:24 +0100
In-Reply-To: <20120607101826.GJ70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
	<20120607092951.GE70339@ocelot.phlegethon.org>
	<1339061691.15265.49.camel@zakaz.uk.xensource.com>
	<20120607101826.GJ70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 11:18 +0100, Tim Deegan wrote:
> At 10:34 +0100 on 07 Jun (1339065291), Ian Campbell wrote:
> > On Thu, 2012-06-07 at 10:29 +0100, Tim Deegan wrote:
> > > > +int domain_uart0_init(struct domain *d)
> > > > +{
> > > > +    int rc;
> > > > +    if ( d->domain_id == 0 )
> > > > +        return 0;
> > > 
> > > Why?  There's no equivalent gate on the MMIO handlers.
> > 
> > dom0 has the actual uart mapped at this address, not the emulated one.
> > Maybe that should be written at the caller instead?
> 
> Yes - ideally in the same place that puts the MMIO hooks in that will
> call the other functions in this file. 

Turns out that there isn't actually such a place, these are part of a
global list of mmio handlers which is traversed for any guest dabt.

This might be something we want to improve (using bits in not-present
p2m entries to identify specific handlers or whatever) but not right now
I think.

I've pulled the dom0 check out into the caller of the init function, but
left an ASSERT behind. I also shortened that long line by using a
#define for the end and removing the dom0 check from there too.

8<------------------------------------------------------------

>From 401e861ff99860d07e758c8d6e3260b8fb847fc5 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 12:55:31 +0100
Subject: [PATCH] arm: implement vpl011 (UART) emulator.

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    5 ++
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  145 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 ++++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 63bad07..931261b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    /* Domain 0 gets a real UART not an emulated one */
+    if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..5dc8b28
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,145 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_START 0x1c090000
+#define UART0_END   (UART0_START+65536)
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    ASSERT( d->domain_id );
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        return -ENOMEM;
+
+    return 0;
+
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= UART0_START && addr < UART0_END;
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        /* ignore any status bits */
+        uart0_print_char((int)((*r) & 0xFF));
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 10ed540..f295a82 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Wed Jun 20 13:37:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShL6H-0004CG-Cq; Wed, 20 Jun 2012 13:37: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 1ShL6F-0004CB-Iw
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:37:35 +0000
Received: from [85.158.143.99:16206] by server-2.bemta-4.messagelabs.com id
	9C/0A-17938-E12D1EF4; Wed, 20 Jun 2012 13:37:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340199452!18495804!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5728 invoked from network); 20 Jun 2012 13:37:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:37:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:37:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:37:26 +0100
Message-ID: <1340199444.4906.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 20 Jun 2012 14:37:24 +0100
In-Reply-To: <20120607101826.GJ70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-18-git-send-email-ian.campbell@citrix.com>
	<20120607092951.GE70339@ocelot.phlegethon.org>
	<1339061691.15265.49.camel@zakaz.uk.xensource.com>
	<20120607101826.GJ70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 18/38] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 11:18 +0100, Tim Deegan wrote:
> At 10:34 +0100 on 07 Jun (1339065291), Ian Campbell wrote:
> > On Thu, 2012-06-07 at 10:29 +0100, Tim Deegan wrote:
> > > > +int domain_uart0_init(struct domain *d)
> > > > +{
> > > > +    int rc;
> > > > +    if ( d->domain_id == 0 )
> > > > +        return 0;
> > > 
> > > Why?  There's no equivalent gate on the MMIO handlers.
> > 
> > dom0 has the actual uart mapped at this address, not the emulated one.
> > Maybe that should be written at the caller instead?
> 
> Yes - ideally in the same place that puts the MMIO hooks in that will
> call the other functions in this file. 

Turns out that there isn't actually such a place, these are part of a
global list of mmio handlers which is traversed for any guest dabt.

This might be something we want to improve (using bits in not-present
p2m entries to identify specific handlers or whatever) but not right now
I think.

I've pulled the dom0 check out into the caller of the init function, but
left an ASSERT behind. I also shortened that long line by using a
#define for the end and removing the dom0 check from there too.

8<------------------------------------------------------------

>From 401e861ff99860d07e758c8d6e3260b8fb847fc5 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 12:55:31 +0100
Subject: [PATCH] arm: implement vpl011 (UART) emulator.

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    5 ++
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  145 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 ++++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 63bad07..931261b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    /* Domain 0 gets a real UART not an emulated one */
+    if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..5dc8b28
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,145 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_START 0x1c090000
+#define UART0_END   (UART0_START+65536)
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    ASSERT( d->domain_id );
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        return -ENOMEM;
+
+    return 0;
+
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= UART0_START && addr < UART0_END;
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        /* ignore any status bits */
+        uart0_print_char((int)((*r) & 0xFF));
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 10ed540..f295a82 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Wed Jun 20 13:43:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShLBk-0004Lo-Q6; Wed, 20 Jun 2012 13:43: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 1ShLBj-0004Lg-RK
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:43:16 +0000
Received: from [85.158.138.51:60516] by server-5.bemta-3.messagelabs.com id
	56/76-01572-373D1EF4; Wed, 20 Jun 2012 13:43:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340199794!20562429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27300 invoked from network); 20 Jun 2012 13:43:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:43:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:43:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 14:43:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShLBh-0004cv-QX; Wed, 20 Jun 2012 13:43:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShLBh-0008Qm-P5;
	Wed, 20 Jun 2012 14:43:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.54129.523732.173929@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 14:43:13 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340183168.4906.8.camel@zakaz.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-win7-amd64"):
> It's an odd one -- the logs seem to show the guest has started but the
> patch in question would (or should!) cause an early error return during
> build. It's possible that the recent test system outage has caused the
> bisector to get confused but it has fingered this changeset at least
> twice now.

The bisector has repro'd this on the same host with 6 tests:
alternately failures for 9d1fd58ff602 and successes for 32034d1914a6.

So if it's a heisenbug we've been moderately (but not outrageously)
unlucky that it actually fingered a specific changeset rather than
just shrugging its shoulders and moving on.  (It does the latter quite
a lot.)

> The bisector really should try and pull out S-o-b's et al from the
> offending commit and add appropriate CCs. There's also something of an
> expectation that developers will keep an eye on the test system results
> after a patch of theirs has been expected though.

Yes, it would be nice if it did that.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:43:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShLBk-0004Lo-Q6; Wed, 20 Jun 2012 13:43: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 1ShLBj-0004Lg-RK
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:43:16 +0000
Received: from [85.158.138.51:60516] by server-5.bemta-3.messagelabs.com id
	56/76-01572-373D1EF4; Wed, 20 Jun 2012 13:43:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340199794!20562429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27300 invoked from network); 20 Jun 2012 13:43:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:43:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:43:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 14:43:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShLBh-0004cv-QX; Wed, 20 Jun 2012 13:43:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShLBh-0008Qm-P5;
	Wed, 20 Jun 2012 14:43:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.54129.523732.173929@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 14:43:13 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340183168.4906.8.camel@zakaz.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-amd64-xl-win7-amd64"):
> It's an odd one -- the logs seem to show the guest has started but the
> patch in question would (or should!) cause an early error return during
> build. It's possible that the recent test system outage has caused the
> bisector to get confused but it has fingered this changeset at least
> twice now.

The bisector has repro'd this on the same host with 6 tests:
alternately failures for 9d1fd58ff602 and successes for 32034d1914a6.

So if it's a heisenbug we've been moderately (but not outrageously)
unlucky that it actually fingered a specific changeset rather than
just shrugging its shoulders and moving on.  (It does the latter quite
a lot.)

> The bisector really should try and pull out S-o-b's et al from the
> offending commit and add appropriate CCs. There's also something of an
> expectation that developers will keep an eye on the test system results
> after a patch of theirs has been expected though.

Yes, it would be nice if it did that.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:49:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:49: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 1ShLH9-0004ig-N5; Wed, 20 Jun 2012 13:48: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 1ShLH7-0004iY-Ue
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:48:50 +0000
Received: from [85.158.139.83:61001] by server-2.bemta-5.messagelabs.com id
	98/E0-04598-1C4D1EF4; Wed, 20 Jun 2012 13:48:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340200128!24686627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21231 invoked from network); 20 Jun 2012 13:48:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:48:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:48:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:48:47 +0100
Message-ID: <1340200126.4906.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 20 Jun 2012 14:48:46 +0100
In-Reply-To: <20120607094152.GG70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
	<20120607094152.GG70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/38] arm: dump guest s1 walk on data abort
 which is not a stage 2 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

On Thu, 2012-06-07 at 10:41 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565190), Ian Campbell wrote:
> > +    offset = addr >> (12+10);
> > +    printk("1ST[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",
> 
> Nit: 0x%08 prints '0' as '0x00000000', which is nicer I think.

Agreed, I wasn't aware of this nit of the printf formatting strings
until you told me.

> Otherwise: ack.

Thanks, update patch is below.

8<---------------------------------------------------------------

>From e045b07e1509482e66333a9300668b4d24c33d13 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 14:19:41 +0100
Subject: [PATCH] arm: dump guest s1 walk on data abort which is not a stage 2
 issue.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   75 +++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/processor.h |    1 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 40bb375..d8eb5a9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -28,6 +28,7 @@
 #include <xen/errno.h>
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
+#include <xen/domain_page.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -528,6 +529,62 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
+void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+{
+    uint32_t ttbcr = READ_CP32(TTBCR);
+    uint32_t ttbr0 = READ_CP32(TTBR0);
+    paddr_t paddr;
+    uint32_t offset;
+    uint32_t *first = NULL, *second = NULL;
+
+    printk("dom%d VA 0x%08"PRIx32"\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));
+
+    if ( ttbcr & TTBCR_EAE )
+    {
+        printk("Cannot handle LPAE guest PT walk\n");
+        return;
+    }
+    if ( (ttbcr & TTBCR_N_MASK) != 0 )
+    {
+        printk("Cannot handle TTBR1 guest walks\n");
+        return;
+    }
+
+    paddr = p2m_lookup(d, ttbr0 & PAGE_MASK);
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed TTBR0 maddr lookup\n");
+        goto done;
+    }
+    first = map_domain_page(paddr>>PAGE_SHIFT);
+
+    offset = addr >> (12+10);
+    printk("1ST[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, first[offset]);
+    if ( !(first[offset] & 0x1) ||
+         !(first[offset] & 0x2) )
+        goto done;
+
+    paddr = p2m_lookup(d, first[offset] & PAGE_MASK);
+
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed L1 entry maddr lookup\n");
+        goto done;
+    }
+    second = map_domain_page(paddr>>PAGE_SHIFT);
+    offset = (addr >> 12) & 0x3FF;
+    printk("2ND[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, second[offset]);
+
+done:
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
                                      struct hsr_dabt dabt)
 {
@@ -535,11 +592,12 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     int level = -1;
     mmio_info_t info;
 
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+
     if (dabt.s1ptw)
         goto bad_data_abort;
 
-    info.dabt = dabt;
-    info.gva = READ_CP32(HDFAR);
     info.gpa = gva_to_ipa(info.gva);
 
     if (handle_mmio(&info))
@@ -553,18 +611,23 @@ bad_data_abort:
     msg = decode_fsc( dabt.dfsc, &level);
 
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           "    gva=%"PRIx32"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
-           info.gva, info.gpa);
-    if (dabt.valid)
+           info.gva);
+    if ( !dabt.s1ptw )
+        printk("    gpa=%"PRIpaddr"\n", info.gpa);
+    if ( dabt.valid )
         printk("    size=%d sign=%d write=%d reg=%d\n",
                dabt.size, dabt.sign, dabt.write, dabt.reg);
     else
         printk("    instruction syndrome invalid\n");
     printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
            dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
-
+    if ( !dabt.s1ptw )
+        dump_p2m_lookup(current->domain, info.gpa);
+    else
+        dump_guest_s1_walk(current->domain, info.gva);
     show_execution_state(regs);
     panic("Unhandled guest data abort\n");
 }
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ec6fb48..81924a4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -25,6 +25,7 @@
 #define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
+#define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
 #define TTBCR_N_16KB 0x00
 #define TTBCR_N_8KB  0x01
-- 
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 Wed Jun 20 13:49:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:49: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 1ShLH9-0004ig-N5; Wed, 20 Jun 2012 13:48: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 1ShLH7-0004iY-Ue
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:48:50 +0000
Received: from [85.158.139.83:61001] by server-2.bemta-5.messagelabs.com id
	98/E0-04598-1C4D1EF4; Wed, 20 Jun 2012 13:48:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340200128!24686627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21231 invoked from network); 20 Jun 2012 13:48:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:48:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:48:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:48:47 +0100
Message-ID: <1340200126.4906.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 20 Jun 2012 14:48:46 +0100
In-Reply-To: <20120607094152.GG70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-21-git-send-email-ian.campbell@citrix.com>
	<20120607094152.GG70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/38] arm: dump guest s1 walk on data abort
 which is not a stage 2 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

On Thu, 2012-06-07 at 10:41 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565190), Ian Campbell wrote:
> > +    offset = addr >> (12+10);
> > +    printk("1ST[%#03"PRIx32"] (%#"PRIpaddr") = %#010"PRIx32"\n",
> 
> Nit: 0x%08 prints '0' as '0x00000000', which is nicer I think.

Agreed, I wasn't aware of this nit of the printf formatting strings
until you told me.

> Otherwise: ack.

Thanks, update patch is below.

8<---------------------------------------------------------------

>From e045b07e1509482e66333a9300668b4d24c33d13 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 14:19:41 +0100
Subject: [PATCH] arm: dump guest s1 walk on data abort which is not a stage 2
 issue.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   75 +++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/processor.h |    1 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 40bb375..d8eb5a9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -28,6 +28,7 @@
 #include <xen/errno.h>
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
+#include <xen/domain_page.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -528,6 +529,62 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
+void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+{
+    uint32_t ttbcr = READ_CP32(TTBCR);
+    uint32_t ttbr0 = READ_CP32(TTBR0);
+    paddr_t paddr;
+    uint32_t offset;
+    uint32_t *first = NULL, *second = NULL;
+
+    printk("dom%d VA 0x%08"PRIx32"\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));
+
+    if ( ttbcr & TTBCR_EAE )
+    {
+        printk("Cannot handle LPAE guest PT walk\n");
+        return;
+    }
+    if ( (ttbcr & TTBCR_N_MASK) != 0 )
+    {
+        printk("Cannot handle TTBR1 guest walks\n");
+        return;
+    }
+
+    paddr = p2m_lookup(d, ttbr0 & PAGE_MASK);
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed TTBR0 maddr lookup\n");
+        goto done;
+    }
+    first = map_domain_page(paddr>>PAGE_SHIFT);
+
+    offset = addr >> (12+10);
+    printk("1ST[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, first[offset]);
+    if ( !(first[offset] & 0x1) ||
+         !(first[offset] & 0x2) )
+        goto done;
+
+    paddr = p2m_lookup(d, first[offset] & PAGE_MASK);
+
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed L1 entry maddr lookup\n");
+        goto done;
+    }
+    second = map_domain_page(paddr>>PAGE_SHIFT);
+    offset = (addr >> 12) & 0x3FF;
+    printk("2ND[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, second[offset]);
+
+done:
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
                                      struct hsr_dabt dabt)
 {
@@ -535,11 +592,12 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     int level = -1;
     mmio_info_t info;
 
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+
     if (dabt.s1ptw)
         goto bad_data_abort;
 
-    info.dabt = dabt;
-    info.gva = READ_CP32(HDFAR);
     info.gpa = gva_to_ipa(info.gva);
 
     if (handle_mmio(&info))
@@ -553,18 +611,23 @@ bad_data_abort:
     msg = decode_fsc( dabt.dfsc, &level);
 
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           "    gva=%"PRIx32"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
-           info.gva, info.gpa);
-    if (dabt.valid)
+           info.gva);
+    if ( !dabt.s1ptw )
+        printk("    gpa=%"PRIpaddr"\n", info.gpa);
+    if ( dabt.valid )
         printk("    size=%d sign=%d write=%d reg=%d\n",
                dabt.size, dabt.sign, dabt.write, dabt.reg);
     else
         printk("    instruction syndrome invalid\n");
     printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
            dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
-
+    if ( !dabt.s1ptw )
+        dump_p2m_lookup(current->domain, info.gpa);
+    else
+        dump_guest_s1_walk(current->domain, info.gva);
     show_execution_state(regs);
     panic("Unhandled guest data abort\n");
 }
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ec6fb48..81924a4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -25,6 +25,7 @@
 #define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
+#define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
 #define TTBCR_N_16KB 0x00
 #define TTBCR_N_8KB  0x01
-- 
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 Wed Jun 20 13:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShLLc-0004vO-Us; Wed, 20 Jun 2012 13:53:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShLLb-0004vI-Uj
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:53:28 +0000
Received: from [85.158.138.51:37041] by server-8.bemta-3.messagelabs.com id
	AD/44-06157-2D5D1EF4; Wed, 20 Jun 2012 13:53:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340200400!28736181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10533 invoked from network); 20 Jun 2012 13:53:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:53:20 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:53:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:53:19 +0100
Message-ID: <1340200398.4906.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 14:53:18 +0100
In-Reply-To: <alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/38] arm: implement
 vcpu_show_execution_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, 2012-06-06 at 18:26 +0100, Stefano Stabellini wrote:
> > @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
> >      show_stack(regs);
> >  }
> >  
> > +void vcpu_show_execution_state(struct vcpu *v)
> > +{
> > +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> > +           v->domain->domain_id, v->vcpu_id);
> > +
> > +    if ( v == current )
> > +    {
> > +        show_execution_state(guest_cpu_user_regs());
> > +        return;
> > +    }
> > +
> > +    vcpu_pause(v); /* acceptably dangerous */
> > +
> > +    vcpu_show_registers(v);
> > +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> > +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
> 
> isn't the if condition inverted?

I think what I'm trying to do here is only dump the stack if the guest
was in one of the privileged modes (i.e. not user mode). 

I don't really recall why -- I guess I figured the usermode stack was
not likely to be all that useful. Unless there's some reason (which I've
forgotten) why we can't walk guest userspace stacks, but given that the
entirety of the implementation of show_guest_stack() is:
        static void show_guest_stack(struct cpu_user_regs *regs)
        {
            printk("GUEST STACK GOES HERE\n");
        }
I guess it doesn't really matter ;-)

Ian.
> 
> > +    vcpu_unpause(v);
> > +}
> > +
> >  static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
> >  {
> >      printk("Unexpected Trap: %s\n", msg);
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13: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 1ShLLc-0004vO-Us; Wed, 20 Jun 2012 13:53:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShLLb-0004vI-Uj
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:53:28 +0000
Received: from [85.158.138.51:37041] by server-8.bemta-3.messagelabs.com id
	AD/44-06157-2D5D1EF4; Wed, 20 Jun 2012 13:53:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340200400!28736181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10533 invoked from network); 20 Jun 2012 13:53:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:53:20 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:53:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:53:19 +0100
Message-ID: <1340200398.4906.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 14:53:18 +0100
In-Reply-To: <alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/38] arm: implement
 vcpu_show_execution_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, 2012-06-06 at 18:26 +0100, Stefano Stabellini wrote:
> > @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
> >      show_stack(regs);
> >  }
> >  
> > +void vcpu_show_execution_state(struct vcpu *v)
> > +{
> > +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> > +           v->domain->domain_id, v->vcpu_id);
> > +
> > +    if ( v == current )
> > +    {
> > +        show_execution_state(guest_cpu_user_regs());
> > +        return;
> > +    }
> > +
> > +    vcpu_pause(v); /* acceptably dangerous */
> > +
> > +    vcpu_show_registers(v);
> > +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> > +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
> 
> isn't the if condition inverted?

I think what I'm trying to do here is only dump the stack if the guest
was in one of the privileged modes (i.e. not user mode). 

I don't really recall why -- I guess I figured the usermode stack was
not likely to be all that useful. Unless there's some reason (which I've
forgotten) why we can't walk guest userspace stacks, but given that the
entirety of the implementation of show_guest_stack() is:
        static void show_guest_stack(struct cpu_user_regs *regs)
        {
            printk("GUEST STACK GOES HERE\n");
        }
I guess it doesn't really matter ;-)

Ian.
> 
> > +    vcpu_unpause(v);
> > +}
> > +
> >  static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
> >  {
> >      printk("Unexpected Trap: %s\n", msg);
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:57:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:57: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 1ShLOp-00055w-Hw; Wed, 20 Jun 2012 13:56: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 1ShLOn-00055m-RZ
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:56:46 +0000
Received: from [193.109.254.147:22216] by server-1.bemta-14.messagelabs.com id
	18/23-24612-D96D1EF4; Wed, 20 Jun 2012 13:56:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340200566!8567576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30156 invoked from network); 20 Jun 2012 13:56:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:56:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:56:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:56:05 +0100
Message-ID: <1340200564.4906.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 14:56:04 +0100
In-Reply-To: <1340200398.4906.60.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
	<1340200398.4906.60.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/38] arm: implement
 vcpu_show_execution_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, 2012-06-20 at 14:53 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 18:26 +0100, Stefano Stabellini wrote:
> > > @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
> > >      show_stack(regs);
> > >  }
> > >  
> > > +void vcpu_show_execution_state(struct vcpu *v)
> > > +{
> > > +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> > > +           v->domain->domain_id, v->vcpu_id);
> > > +
> > > +    if ( v == current )
> > > +    {
> > > +        show_execution_state(guest_cpu_user_regs());
> > > +        return;
> > > +    }
> > > +
> > > +    vcpu_pause(v); /* acceptably dangerous */
> > > +
> > > +    vcpu_show_registers(v);
> > > +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> > > +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
> > 
> > isn't the if condition inverted?
> 
> I think what I'm trying to do here is only dump the stack if the guest
> was in one of the privileged modes (i.e. not user mode). 
> 
> I don't really recall why -- I guess I figured the usermode stack was
> not likely to be all that useful.

It looks like I just copied the behaviour of x86, which has:
   if ( guest_kernel_mode(v, &v->arch.user_regs) )
        show_guest_stack(v, &v->arch.user_regs);

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:57:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 13:57: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 1ShLOp-00055w-Hw; Wed, 20 Jun 2012 13:56: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 1ShLOn-00055m-RZ
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:56:46 +0000
Received: from [193.109.254.147:22216] by server-1.bemta-14.messagelabs.com id
	18/23-24612-D96D1EF4; Wed, 20 Jun 2012 13:56:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340200566!8567576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30156 invoked from network); 20 Jun 2012 13:56:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:56:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13125858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 13:56:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:56:05 +0100
Message-ID: <1340200564.4906.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 14:56:04 +0100
In-Reply-To: <1340200398.4906.60.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-22-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061825480.2415@kaball.uk.xensource.com>
	<1340200398.4906.60.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 22/38] arm: implement
 vcpu_show_execution_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, 2012-06-20 at 14:53 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 18:26 +0100, Stefano Stabellini wrote:
> > > @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
> > >      show_stack(regs);
> > >  }
> > >  
> > > +void vcpu_show_execution_state(struct vcpu *v)
> > > +{
> > > +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> > > +           v->domain->domain_id, v->vcpu_id);
> > > +
> > > +    if ( v == current )
> > > +    {
> > > +        show_execution_state(guest_cpu_user_regs());
> > > +        return;
> > > +    }
> > > +
> > > +    vcpu_pause(v); /* acceptably dangerous */
> > > +
> > > +    vcpu_show_registers(v);
> > > +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> > > +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
> > 
> > isn't the if condition inverted?
> 
> I think what I'm trying to do here is only dump the stack if the guest
> was in one of the privileged modes (i.e. not user mode). 
> 
> I don't really recall why -- I guess I figured the usermode stack was
> not likely to be all that useful.

It looks like I just copied the behaviour of x86, which has:
   if ( guest_kernel_mode(v, &v->arch.user_regs) )
        show_guest_stack(v, &v->arch.user_regs);

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:59:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 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 1ShLRJ-0005FW-3R; Wed, 20 Jun 2012 13:59:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ShLRG-0005FN-QC
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:59:19 +0000
Received: from [193.109.254.147:5016] by server-4.bemta-14.messagelabs.com id
	82/94-02077-637D1EF4; Wed, 20 Jun 2012 13:59:18 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340200754!3654773!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6518 invoked from network); 20 Jun 2012 13:59:15 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:59:15 -0000
Received: by obbta14 with SMTP id ta14so3618485obb.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 06:59:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=ziP3h4OQ+kRBzmYr+dt8zM3hsdE+toSRc76i7hO5BB4=;
	b=hekQoC4wOMC2qDZZo+WPn1PBDGA/hH8MRPMtpoQxLmXB8Whz6GHAbvdCaVCd2P07g7
	jKB4Q67uEpHSe0xxAf4zhGLRdaOo24BGL3CXp1UFB8uiFVXmTpCMTCQzVxPy+E+ciVYf
	WhBHp6A4Wuvai4gQhPDDaPIDPEoE1CqXWligS+taam3wd1oAtv73wKSjw9j0CnyF/RDG
	pubKZxMtooxiDjMJWo3PEFwWgZAt9EDsKyNsvPEtcHLc4o1BhbV4M0TlAKjEkhHGIFj5
	MV3rniC3jVqdSaYbERAESOpFvBCe0S0RhwjBEQQq8R6ew5KkQ7EcAE3Px8tA+d6N86qq
	MEeA==
Received: by 10.182.174.70 with SMTP id bq6mr13550896obc.78.1340200754326;
	Wed, 20 Jun 2012 06:59:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 20 Jun 2012 06:58:54 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE06671020000780008A946@nat28.tlf.novell.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
From: Rolu <rolu@roce.org>
Date: Wed, 20 Jun 2012 15:58:54 +0200
Message-ID: <CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlZTs82Vu9rLyzgOkPaiHtpiVNoFUgkShziotphbqrEp/AF08ZAgi9x7g+AH15wFnkbmfao
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 19, 2012 at 11:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 18.06.12 at 22:57, Rolu <rolu@roce.org> wrote:
>> I have a HVM domU running Ubuntu 12.04. It has several PCI devices
>> passed through to it (USB controllers, onboard sound, ATI video card
>> with gfx_passthru 0). It has some issues, the most apparent one with
>> the sound, which doesn't play normally but repeats the same short
>> fragment over and over for a while until moving on to the next
>> fragment. The Xen dmesg prints lots of lines like:
>>
>> (XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
>
> Which indicates something wrong in the guest kernel or in the
> translation layers (qemu, less likely the hypervisor itself). Valid
> MSIs can't have a delivery mode of 3 (a reserved encoding).
>
>> The number behind 108:d varies occasionally.
>
> Yes, that number is bogus (has no guaranteed relation to the
> target domain).
>
>> Since vmsi.c seems to deal with passing on MSI interrupts, I tried
>> booting the domU with pci=nomsi. This made things work and sound now
>> plays normally. Not using MSI at all doesn't seem like a very good
>> solution though.
>>
>> What makes this happen, and can I fix it in a better way?
>
> Unless this is in the guest kernel, we'll likely need a code fix here,
> but for determining what and where, we'd need you to provide
> the qemu log for the domain as well (there ought to be entries
> starting with "Update msi with pirq", and the gflags value is of
> particular interest). Depending on what we see, we may then
> need you to do some further debugging.
>

There are, these: (I've copied the full logs below)

pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f

To produce the logs I started the domU and let it run until it
displayed the graphical login screen, which plays a short sound.

The qemu logs give several errors and warnings, such as (there are
multiple of each of these):

pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]

Are these related, and/or cause for worry? I've looked around some but
apart from the fact that they have to do with PCI it doesn't tell me
much. They occur no matter whether I use pci=nomsi or not.

The qemu log, without pci=nomsi set, sound stutters:

domid: 3
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /panda/ubuntuhv2.img (drv 'aio')
Using file /panda/ubuntuhv2.img in read-write mode
Strip off blktap sub-type prefix to
/panda/ubuntu-12.04-desktop-amd64.iso (drv 'aio')
Using file /panda/ubuntu-12.04-desktop-amd64.iso in read-only mode
Watching /local/domain/0/device-model/3/logdirty/cmd
Watching /local/domain/0/device-model/3/command
Watching /local/domain/3/cpu
char device redirected to /dev/pts/2
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = bfd25022-34fc-43e9-82ed-70fb4fdbd7bd
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/3/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1):
aio:/panda/ubuntu-12.04-desktop-amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/3/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/3/log-throttling'
medium change watch on `/local/domain/3/log-throttling' - unknown
device, ignored
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:14.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0
pt_register_regions: IO region registered (size=0x00010000 base_addr=0xf7d00004)
pt_msi_setup: msi mapped with pirq 37
pci_intx: intx=1
register_real_device: Real physical device 00:14.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1a.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d18000)
pci_intx: intx=1
register_real_device: Real physical device 00:1a.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1d.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d17000)
pci_intx: intx=1
register_real_device: Real physical device 00:1d.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1b.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1b.0x0
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf7d10004)
pt_msi_setup: msi mapped with pirq 36
pci_intx: intx=1
register_real_device: Real physical device 00:1b.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01:00.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00020000 base_addr=0xf7c20004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000e001)
pt_register_regions: Expansion ROM registered (size=0x00020000
base_addr=0xf7c00000)
pt_msi_setup: msi mapped with pirq 35
pci_intx: intx=1
register_real_device: Real physical device 01:00.0 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=1
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=1
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=1
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=1
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=1
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=1
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
region type 1 at [c100,c200).
region type 0 at [f3057000,f3057100).
squash iomem [f3057000, f3057100).
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:06:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:07:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_pci_write_config: [00:08:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f



The qemu log, with pci=nomsi set, sound is okay:

domid: 2
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /panda/ubuntuhv2.img (drv 'aio')
Using file /panda/ubuntuhv2.img in read-write mode
Strip off blktap sub-type prefix to
/panda/ubuntu-12.04-desktop-amd64.iso (drv 'aio')
Using file /panda/ubuntu-12.04-desktop-amd64.iso in read-only mode
Watching /local/domain/0/device-model/2/logdirty/cmd
Watching /local/domain/0/device-model/2/command
Watching /local/domain/2/cpu
char device redirected to /dev/pts/2
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 376e7089-c20e-40d9-8e93-c7e4bec2e72d
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/2/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1):
aio:/panda/ubuntu-12.04-desktop-amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/2/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/2/log-throttling'
medium change watch on `/local/domain/2/log-throttling' - unknown
device, ignored
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:14.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0
pt_register_regions: IO region registered (size=0x00010000 base_addr=0xf7d00004)
pt_msi_setup: msi mapped with pirq 37
pci_intx: intx=1
register_real_device: Real physical device 00:14.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1a.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d18000)
pci_intx: intx=1
register_real_device: Real physical device 00:1a.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1d.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d17000)
pci_intx: intx=1
register_real_device: Real physical device 00:1d.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1b.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1b.0x0
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf7d10004)
pt_msi_setup: msi mapped with pirq 36
pci_intx: intx=1
register_real_device: Real physical device 00:1b.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01:00.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00020000 base_addr=0xf7c20004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000e001)
pt_register_regions: Expansion ROM registered (size=0x00020000
base_addr=0xf7c00000)
pt_msi_setup: msi mapped with pirq 35
pci_intx: intx=1
register_real_device: Real physical device 01:00.0 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=1
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=1
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=1
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=1
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=1
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=1
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
region type 1 at [c100,c200).
region type 0 at [f3057000,f3057100).
squash iomem [f3057000, f3057100).
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:06:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:07:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_pci_write_config: [00:08:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 13:59:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 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 1ShLRJ-0005FW-3R; Wed, 20 Jun 2012 13:59:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ShLRG-0005FN-QC
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 13:59:19 +0000
Received: from [193.109.254.147:5016] by server-4.bemta-14.messagelabs.com id
	82/94-02077-637D1EF4; Wed, 20 Jun 2012 13:59:18 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340200754!3654773!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6518 invoked from network); 20 Jun 2012 13:59:15 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 13:59:15 -0000
Received: by obbta14 with SMTP id ta14so3618485obb.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 06:59:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=ziP3h4OQ+kRBzmYr+dt8zM3hsdE+toSRc76i7hO5BB4=;
	b=hekQoC4wOMC2qDZZo+WPn1PBDGA/hH8MRPMtpoQxLmXB8Whz6GHAbvdCaVCd2P07g7
	jKB4Q67uEpHSe0xxAf4zhGLRdaOo24BGL3CXp1UFB8uiFVXmTpCMTCQzVxPy+E+ciVYf
	WhBHp6A4Wuvai4gQhPDDaPIDPEoE1CqXWligS+taam3wd1oAtv73wKSjw9j0CnyF/RDG
	pubKZxMtooxiDjMJWo3PEFwWgZAt9EDsKyNsvPEtcHLc4o1BhbV4M0TlAKjEkhHGIFj5
	MV3rniC3jVqdSaYbERAESOpFvBCe0S0RhwjBEQQq8R6ew5KkQ7EcAE3Px8tA+d6N86qq
	MEeA==
Received: by 10.182.174.70 with SMTP id bq6mr13550896obc.78.1340200754326;
	Wed, 20 Jun 2012 06:59:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 20 Jun 2012 06:58:54 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE06671020000780008A946@nat28.tlf.novell.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
From: Rolu <rolu@roce.org>
Date: Wed, 20 Jun 2012 15:58:54 +0200
Message-ID: <CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlZTs82Vu9rLyzgOkPaiHtpiVNoFUgkShziotphbqrEp/AF08ZAgi9x7g+AH15wFnkbmfao
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 19, 2012 at 11:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 18.06.12 at 22:57, Rolu <rolu@roce.org> wrote:
>> I have a HVM domU running Ubuntu 12.04. It has several PCI devices
>> passed through to it (USB controllers, onboard sound, ATI video card
>> with gfx_passthru 0). It has some issues, the most apparent one with
>> the sound, which doesn't play normally but repeats the same short
>> fragment over and over for a while until moving on to the next
>> fragment. The Xen dmesg prints lots of lines like:
>>
>> (XEN) [2012-06-18 20:14:16] vmsi.c:108:d32767 Unsupported delivery mode 3
>
> Which indicates something wrong in the guest kernel or in the
> translation layers (qemu, less likely the hypervisor itself). Valid
> MSIs can't have a delivery mode of 3 (a reserved encoding).
>
>> The number behind 108:d varies occasionally.
>
> Yes, that number is bogus (has no guaranteed relation to the
> target domain).
>
>> Since vmsi.c seems to deal with passing on MSI interrupts, I tried
>> booting the domU with pci=nomsi. This made things work and sound now
>> plays normally. Not using MSI at all doesn't seem like a very good
>> solution though.
>>
>> What makes this happen, and can I fix it in a better way?
>
> Unless this is in the guest kernel, we'll likely need a code fix here,
> but for determining what and where, we'd need you to provide
> the qemu log for the domain as well (there ought to be entries
> starting with "Update msi with pirq", and the gflags value is of
> particular interest). Depending on what we see, we may then
> need you to do some further debugging.
>

There are, these: (I've copied the full logs below)

pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f

To produce the logs I started the domU and let it run until it
displayed the graphical login screen, which plays a short sound.

The qemu logs give several errors and warnings, such as (there are
multiple of each of these):

pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]

Are these related, and/or cause for worry? I've looked around some but
apart from the fact that they have to do with PCI it doesn't tell me
much. They occur no matter whether I use pci=nomsi or not.

The qemu log, without pci=nomsi set, sound stutters:

domid: 3
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /panda/ubuntuhv2.img (drv 'aio')
Using file /panda/ubuntuhv2.img in read-write mode
Strip off blktap sub-type prefix to
/panda/ubuntu-12.04-desktop-amd64.iso (drv 'aio')
Using file /panda/ubuntu-12.04-desktop-amd64.iso in read-only mode
Watching /local/domain/0/device-model/3/logdirty/cmd
Watching /local/domain/0/device-model/3/command
Watching /local/domain/3/cpu
char device redirected to /dev/pts/2
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = bfd25022-34fc-43e9-82ed-70fb4fdbd7bd
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/3/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1):
aio:/panda/ubuntu-12.04-desktop-amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/3/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/3/log-throttling'
medium change watch on `/local/domain/3/log-throttling' - unknown
device, ignored
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:14.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0
pt_register_regions: IO region registered (size=0x00010000 base_addr=0xf7d00004)
pt_msi_setup: msi mapped with pirq 37
pci_intx: intx=1
register_real_device: Real physical device 00:14.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1a.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d18000)
pci_intx: intx=1
register_real_device: Real physical device 00:1a.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1d.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d17000)
pci_intx: intx=1
register_real_device: Real physical device 00:1d.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1b.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1b.0x0
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf7d10004)
pt_msi_setup: msi mapped with pirq 36
pci_intx: intx=1
register_real_device: Real physical device 00:1b.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01:00.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00020000 base_addr=0xf7c20004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000e001)
pt_register_regions: Expansion ROM registered (size=0x00020000
base_addr=0xf7c00000)
pt_msi_setup: msi mapped with pirq 35
pci_intx: intx=1
register_real_device: Real physical device 01:00.0 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=1
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=1
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=1
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=1
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=1
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=1
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
region type 1 at [c100,c200).
region type 0 at [f3057000,f3057100).
squash iomem [f3057000, f3057100).
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:06:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:07:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_pci_write_config: [00:08:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f



The qemu log, with pci=nomsi set, sound is okay:

domid: 2
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /panda/ubuntuhv2.img (drv 'aio')
Using file /panda/ubuntuhv2.img in read-write mode
Strip off blktap sub-type prefix to
/panda/ubuntu-12.04-desktop-amd64.iso (drv 'aio')
Using file /panda/ubuntu-12.04-desktop-amd64.iso in read-only mode
Watching /local/domain/0/device-model/2/logdirty/cmd
Watching /local/domain/0/device-model/2/command
Watching /local/domain/2/cpu
char device redirected to /dev/pts/2
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 376e7089-c20e-40d9-8e93-c7e4bec2e72d
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/2/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1):
aio:/panda/ubuntu-12.04-desktop-amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/2/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/2/log-throttling'
medium change watch on `/local/domain/2/log-throttling' - unknown
device, ignored
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:14.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0
pt_register_regions: IO region registered (size=0x00010000 base_addr=0xf7d00004)
pt_msi_setup: msi mapped with pirq 37
pci_intx: intx=1
register_real_device: Real physical device 00:14.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1a.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d18000)
pci_intx: intx=1
register_real_device: Real physical device 00:1a.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1d.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x0
pt_register_regions: IO region registered (size=0x00000400 base_addr=0xf7d17000)
pci_intx: intx=1
register_real_device: Real physical device 00:1d.0 registered successfuly!
IRQ type = INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 00:1b.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x1b.0x0
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf7d10004)
pt_msi_setup: msi mapped with pirq 36
pci_intx: intx=1
register_real_device: Real physical device 00:1b.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 01:00.0 ...
pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00020000 base_addr=0xf7c20004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000e001)
pt_register_regions: Expansion ROM registered (size=0x00020000
base_addr=0xf7c00000)
pt_msi_setup: msi mapped with pirq 35
pci_intx: intx=1
register_real_device: Real physical device 01:00.0 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=1
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=1
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=1
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=1
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=1
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=1
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
region type 1 at [c100,c200).
region type 0 at [f3057000,f3057100).
squash iomem [f3057000, f3057100).
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3040000 maddr=f7d00000 type=0 len=65536 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:06:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3055000 maddr=f7d18000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_pci_write_config: [00:07:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3056000 maddr=f7d17000 type=0 len=4096 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_pci_write_config: [00:08:0] Warning: Guest attempt to set address
to unused Base Address Register. [Offset:30h][Length:4]
pt_iomem_map: e_phys=f3050000 maddr=f7d10000 type=0 len=16384 index=0
first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=ffff pio_base=e000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456
index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f7c20000 type=0 len=131072 index=2
first_map=0
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=0
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]
pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 14:01:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 14:01: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 1ShLTO-0005T8-P5; Wed, 20 Jun 2012 14:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShLTN-0005St-7N
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 14:01:29 +0000
Received: from [85.158.143.99:26357] by server-2.bemta-4.messagelabs.com id
	4D/0A-17938-8B7D1EF4; Wed, 20 Jun 2012 14:01:28 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340200887!23003364!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2087 invoked from network); 20 Jun 2012 14:01:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 14:01:27 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79015805; Wed, 20 Jun 2012 16:01:26 +0200
Message-ID: <1340200879.20225.11.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 16:01:19 +0200
In-Reply-To: <20449.54129.523732.173929@mariner.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
	<20449.54129.523732.173929@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3951826315511861575=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3951826315511861575==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HoqefdMERWiLl25TDKrj"


--=-HoqefdMERWiLl25TDKrj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 14:43 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete t=
est-amd64-amd64-xl-win7-amd64"):
> > It's an odd one -- the logs seem to show the guest has started but the
> > patch in question would (or should!) cause an early error return during
> > build. It's possible that the recent test system outage has caused the
> > bisector to get confused but it has fingered this changeset at least
> > twice now.
>=20
> The bisector has repro'd this on the same host with 6 tests:
> alternately failures for 9d1fd58ff602 and successes for 32034d1914a6.
>=20
Which means it might be unrelated from that specific commit (sorry if
it's a stupid question, just want to be sure I'm getting things
correct :-/ )

> So if it's a heisenbug we've been moderately (but not outrageously)
> unlucky that it actually fingered a specific changeset rather than
> just shrugging its shoulders and moving on.  (It does the latter quite
> a lot.)
>=20
Just to be sure, this part of the bisector report:

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-win7-amd64
test windows-install

means that the test that failed was 'job
test-amd64-amd64-xl-win7-amd64' (and, specifically, during
'windows-install' phase), right?

I'm asking because I actually found a bug in that change, _but_ it only
comes into play if the SEDF scheduler is being used. In fact, this test
also fails:

http://www.chiark.greenend.org.uk/~xensrcts/logs/13053/test-amd64-amd64-xl-=
sedf/info.html

and it does by saying this:

2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/x=
en/debian.guest.osstest.cfg
libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf=
: Invalid argument
libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)bui=
ld domain: -3
Parsing config from /etc/xen/debian.guest.osstest.cfg

Which is actually related to my patch, and for which I already have a
fix ready.

OTOH, I really don't see how that patch might cause that HVM windows
domain to die, given the log for 'test-amd64-amd64-xl-sedf' says this:

Parsing config from /etc/xen/win.guest.osstest.cfg
Daemon running with PID 2642

Which seems to mean, at least to me, that the check happened without
causing any issues (as it, conversely, does when SEDF is the scheduler).

Anyway, I'll send the patch for the SEDF case and try to reproduce the
bug for the credit+Win7+HVM case.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-HoqefdMERWiLl25TDKrj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/h168ACgkQk4XaBE3IOsQISgCfWXq4J/pz7evfQn2b/TXgrO29
GOEAnRwEa04F8ZfemStWhzy+7QeGw63z
=Qezv
-----END PGP SIGNATURE-----

--=-HoqefdMERWiLl25TDKrj--



--===============3951826315511861575==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3951826315511861575==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 14:01:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 14:01: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 1ShLTO-0005T8-P5; Wed, 20 Jun 2012 14:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShLTN-0005St-7N
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 14:01:29 +0000
Received: from [85.158.143.99:26357] by server-2.bemta-4.messagelabs.com id
	4D/0A-17938-8B7D1EF4; Wed, 20 Jun 2012 14:01:28 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340200887!23003364!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2087 invoked from network); 20 Jun 2012 14:01:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 14:01:27 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79015805; Wed, 20 Jun 2012 16:01:26 +0200
Message-ID: <1340200879.20225.11.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 16:01:19 +0200
In-Reply-To: <20449.54129.523732.173929@mariner.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
	<20449.54129.523732.173929@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3951826315511861575=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3951826315511861575==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HoqefdMERWiLl25TDKrj"


--=-HoqefdMERWiLl25TDKrj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 14:43 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete t=
est-amd64-amd64-xl-win7-amd64"):
> > It's an odd one -- the logs seem to show the guest has started but the
> > patch in question would (or should!) cause an early error return during
> > build. It's possible that the recent test system outage has caused the
> > bisector to get confused but it has fingered this changeset at least
> > twice now.
>=20
> The bisector has repro'd this on the same host with 6 tests:
> alternately failures for 9d1fd58ff602 and successes for 32034d1914a6.
>=20
Which means it might be unrelated from that specific commit (sorry if
it's a stupid question, just want to be sure I'm getting things
correct :-/ )

> So if it's a heisenbug we've been moderately (but not outrageously)
> unlucky that it actually fingered a specific changeset rather than
> just shrugging its shoulders and moving on.  (It does the latter quite
> a lot.)
>=20
Just to be sure, this part of the bisector report:

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-win7-amd64
test windows-install

means that the test that failed was 'job
test-amd64-amd64-xl-win7-amd64' (and, specifically, during
'windows-install' phase), right?

I'm asking because I actually found a bug in that change, _but_ it only
comes into play if the SEDF scheduler is being used. In fact, this test
also fails:

http://www.chiark.greenend.org.uk/~xensrcts/logs/13053/test-amd64-amd64-xl-=
sedf/info.html

and it does by saying this:

2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/x=
en/debian.guest.osstest.cfg
libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf=
: Invalid argument
libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)bui=
ld domain: -3
Parsing config from /etc/xen/debian.guest.osstest.cfg

Which is actually related to my patch, and for which I already have a
fix ready.

OTOH, I really don't see how that patch might cause that HVM windows
domain to die, given the log for 'test-amd64-amd64-xl-sedf' says this:

Parsing config from /etc/xen/win.guest.osstest.cfg
Daemon running with PID 2642

Which seems to mean, at least to me, that the check happened without
causing any issues (as it, conversely, does when SEDF is the scheduler).

Anyway, I'll send the patch for the SEDF case and try to reproduce the
bug for the credit+Win7+HVM case.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-HoqefdMERWiLl25TDKrj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/h168ACgkQk4XaBE3IOsQISgCfWXq4J/pz7evfQn2b/TXgrO29
GOEAnRwEa04F8ZfemStWhzy+7QeGw63z
=Qezv
-----END PGP SIGNATURE-----

--=-HoqefdMERWiLl25TDKrj--



--===============3951826315511861575==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3951826315511861575==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 14:59:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 14:59: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 1ShMNI-00068J-JH; Wed, 20 Jun 2012 14:59:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1ShMNH-00068E-5q
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 14:59:15 +0000
Received: from [193.109.254.147:55750] by server-12.bemta-14.messagelabs.com
	id 98/A3-30461-245E1EF4; Wed, 20 Jun 2012 14:59:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340204352!10777099!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5ODY1NQ==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22574 invoked from network); 20 Jun 2012 14:59:13 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 14:59:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5KEx6dL017581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Jun 2012 14:59: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
	q5KEx56b028561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 14:59: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
	q5KEx306003293; Wed, 20 Jun 2012 09:59:03 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Jun 2012 07:59:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0A1C2402B8; Wed, 20 Jun 2012 10:51:28 -0400 (EDT)
Date: Wed, 20 Jun 2012 10:51:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120620145127.GD12787@phenom.dumpdata.com>
References: <4FE1C423.6070001@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE1C423.6070001@amd.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 <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 02:37:55PM +0200, Andre Przywara wrote:
> Hi,
> 
> we have some problems with acpidump running on Xen Dom0. On 64 bit
> Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a
> kernel crash.
> The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
> unstable versions including 25467, also 32-bit versions of 4.1.
> The Dom0 kernels were always PVOPS versions, the problems starts
> with 3.2-rc1~194 and is still in 3.5.0-rc3.
> Also you need to restrict the Dom0 memory with dom0_mem=
> The crash says (on a 3.4.3 32bit Dom0 kernel):
> uruk:~ # ./acpidump32
> [  158.843444] ------------[ cut here ]------------
> [  158.843460] kernel BUG at mm/rmap.c:1027!
> [  158.843466] invalid opcode: 0000 [#1] SMP
> [  158.843472] Modules linked in:
> [  158.843478]
> [  158.843483] Pid: 4874, comm: acpidump32 Tainted: G        W
> 3.4.0+ #105 empty empty/S3993
> [  158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
> [  158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
> [  158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
> [  158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
> [  158.843522]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
> [  158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
> [  158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [  158.843581] DR6: ffff0ff0 DR7: 00000400
> [  158.843586] Process acpidump32 (pid: 4874, ti=d6090000
> task=d60b34f0 task.ti=d6090000)
> [  158.843591] Stack:
> [  158.843594]  dfecb6e0 00000001 d6091ea8 c10b15c4 00000000
> d6022dc0 d61fbdd8 d6022dc0
> [  158.843610]  00000000 d6091efc c10aacbe 00000000 99948025
> 80000001 d8aa1f80 80000001
> [  158.843631]  dfefc800 00000000 d8aa1f80 00000000 166b7025
> d7f407d0 b76faf64 99948025
> [  158.843649] Call Trace:
> [  158.843656]  [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
> [  158.843664]  [<c10aacbe>] handle_pte_fault+0x81d/0xa06
> [  158.843674]  [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
> [  158.843683]  [<c159e4e8>] ? spurious_fault+0x104/0x104
> [  158.843688]  [<c159e881>] do_page_fault+0x399/0x3b4
> [  158.843696]  [<c10c639d>] ? filp_close+0x55/0x5f
> [  158.843701]  [<c10c6408>] ? sys_close+0x61/0xa0
> [  158.843706]  [<c159e4e8>] ? spurious_fault+0x104/0x104
> [  158.843714]  [<c159c452>] error_code+0x5a/0x60
> [  158.843720]  [<c159e4e8>] ? spurious_fault+0x104/0x104
> [  158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03
> 50 4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44
> 85 f6 75 02 <0f> 0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89
> 73 04 f6
> [  158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45
> SS:ESP 0069:d6091e84
> [  158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
> [  158.843854] note: acpidump32[4874] exited with preempt_count 1
> 
> 
> On 64bit the OOM goes around, finally killing the login shell:
> uruk:~ # ./acpidump_inst
> acpi_map_memory(917504, 131072);
> opened /dev/mem (fd=3)
> calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
>   mmap returned 0xf7571000, function returns 0xf7571000
> acpi_map_table(cfef0f64, "XSDT");
> acpi_map_memory(3488550756, 36);
> opened /dev/mem (fd=3)
> calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
>   mmap returned 0xf76fd000, function returns 0xf76fdf64
>   having mapped table header
>   reading signature:
> 
> Welcome to SUSE Linux Enterprise Server 11 SP1  (i586) - Kernel
> 3.5.0-rc3+ (hvc0).
> 
> uruk login:
> -----------
> This dump shows that the bug happens the moment acpidump accesses
> the mmapped ACPI table at @cfef0000 (the lower map at e0000 works).

What is the e0000 one? I don't see in your E820 the region being
reserved?

> 
> This is extra unfortunate as in SLES11 acpidump will be called by
> the kbd init script (querying the BIOS NumLock setting!)

Ah. Is the acpidump somewhere easily available to compile? Should
I get it from here:
http://www.lesswatts.org/projects/acpi/utilities.php

> 
> I bisected the Dom0 kernel to find this one (v3.2-rc~194):
> commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
> Merge: 315eb8a f3f436e
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Tue Oct 25 09:17:07 2011 +0200
> 
>     Merge branch 'stable/e820-3.2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
> 
>     * 'stable/e820-3.2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:

Oh boy. v3.2 .. that is eons ago! :-)

>       xen: release all pages within 1-1 p2m mappings
>       xen: allow extra memory to be in multiple regions
>       xen: allow balloon driver to use more than one memory region
>       xen/balloon: simplify test for the end of usable RAM
>       xen/balloon: account for pages released during memory setup
> 
> 
> I tried to find something obvious, but to no avail. At least the new
> E820 looks sane, nothing that would prevent the mapping of the
> requested regions. Reverting this commit will not work easily on
> newer kernels, also is probably not desirable.

The one thing that comes to my mind is the 1-1 mapping having
some issues. Can you boot the kernel with 'debug loglevel=8'. That should
print something like this:

Setting pfn cfef0->cfef7 to 1-1 
or such during bootup.

> 
> But it does not show on every machine here, so the machine E820
> could actually be a differentiator. This particular box was a dual
> socket Barcelona server with 12GB of memory.
> 
> This whole PV memory management goes beyond my knowledge, so I'd
> like to ask for help on this issue.
> If you need more information (I attached the boot log, which shows
> the two E820 tables), please ask. I can also quickly do some
> experiments if needed.

This is strange one - the P2M code should fetch the MFN (so it should
give you cfef0) whenever anybody asks for that. Lets double-check that.

Can you try this little module?
[not compile tested]


#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/pagemap.h>
#include <linux/init.h>
#include <xen/xen.h>
#define ACPITEST  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("acpitest");
MODULE_LICENSE("GPL");
MODULE_VERSION(ACPITEST);

static int __init acpitest_init(void)
{
	unsigned int pfn = 0xcfef0;
	unsigned int mfn;
	void *data;

	mfn = pfn_to_mfn(pfn);
	WARN_ON(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
	if (pfn != mfn) {
		printk(KERN_INFO "raw p2m (%lx) gives us: %lx\n", pfn, get_phys_to_machine(pfn));
		return -EINVAL;
	}
	data = mfn_to_virt(mfn);
	printk(KERN_INFO "va is 0x%lx\n", data);
	print_hex_dump_bytes("acpi:", DUMP_PREFIX_OFFSET, data, PAGE_SIZE);
	
	return 0;
}
static void __exit acpitest_exit(void)
{
}
module_init(acpitest_init);
module_exit(acpitest_exit);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 14:59:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 14:59: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 1ShMNI-00068J-JH; Wed, 20 Jun 2012 14:59:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1ShMNH-00068E-5q
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 14:59:15 +0000
Received: from [193.109.254.147:55750] by server-12.bemta-14.messagelabs.com
	id 98/A3-30461-245E1EF4; Wed, 20 Jun 2012 14:59:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340204352!10777099!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU5ODY1NQ==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22574 invoked from network); 20 Jun 2012 14:59:13 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 14:59:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5KEx6dL017581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Jun 2012 14:59: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
	q5KEx56b028561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 14:59: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
	q5KEx306003293; Wed, 20 Jun 2012 09:59:03 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Jun 2012 07:59:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0A1C2402B8; Wed, 20 Jun 2012 10:51:28 -0400 (EDT)
Date: Wed, 20 Jun 2012 10:51:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120620145127.GD12787@phenom.dumpdata.com>
References: <4FE1C423.6070001@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE1C423.6070001@amd.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 <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 02:37:55PM +0200, Andre Przywara wrote:
> Hi,
> 
> we have some problems with acpidump running on Xen Dom0. On 64 bit
> Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a
> kernel crash.
> The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
> unstable versions including 25467, also 32-bit versions of 4.1.
> The Dom0 kernels were always PVOPS versions, the problems starts
> with 3.2-rc1~194 and is still in 3.5.0-rc3.
> Also you need to restrict the Dom0 memory with dom0_mem=
> The crash says (on a 3.4.3 32bit Dom0 kernel):
> uruk:~ # ./acpidump32
> [  158.843444] ------------[ cut here ]------------
> [  158.843460] kernel BUG at mm/rmap.c:1027!
> [  158.843466] invalid opcode: 0000 [#1] SMP
> [  158.843472] Modules linked in:
> [  158.843478]
> [  158.843483] Pid: 4874, comm: acpidump32 Tainted: G        W
> 3.4.0+ #105 empty empty/S3993
> [  158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
> [  158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
> [  158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
> [  158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
> [  158.843522]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
> [  158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
> [  158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [  158.843581] DR6: ffff0ff0 DR7: 00000400
> [  158.843586] Process acpidump32 (pid: 4874, ti=d6090000
> task=d60b34f0 task.ti=d6090000)
> [  158.843591] Stack:
> [  158.843594]  dfecb6e0 00000001 d6091ea8 c10b15c4 00000000
> d6022dc0 d61fbdd8 d6022dc0
> [  158.843610]  00000000 d6091efc c10aacbe 00000000 99948025
> 80000001 d8aa1f80 80000001
> [  158.843631]  dfefc800 00000000 d8aa1f80 00000000 166b7025
> d7f407d0 b76faf64 99948025
> [  158.843649] Call Trace:
> [  158.843656]  [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
> [  158.843664]  [<c10aacbe>] handle_pte_fault+0x81d/0xa06
> [  158.843674]  [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
> [  158.843683]  [<c159e4e8>] ? spurious_fault+0x104/0x104
> [  158.843688]  [<c159e881>] do_page_fault+0x399/0x3b4
> [  158.843696]  [<c10c639d>] ? filp_close+0x55/0x5f
> [  158.843701]  [<c10c6408>] ? sys_close+0x61/0xa0
> [  158.843706]  [<c159e4e8>] ? spurious_fault+0x104/0x104
> [  158.843714]  [<c159c452>] error_code+0x5a/0x60
> [  158.843720]  [<c159e4e8>] ? spurious_fault+0x104/0x104
> [  158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03
> 50 4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44
> 85 f6 75 02 <0f> 0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89
> 73 04 f6
> [  158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45
> SS:ESP 0069:d6091e84
> [  158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
> [  158.843854] note: acpidump32[4874] exited with preempt_count 1
> 
> 
> On 64bit the OOM goes around, finally killing the login shell:
> uruk:~ # ./acpidump_inst
> acpi_map_memory(917504, 131072);
> opened /dev/mem (fd=3)
> calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
>   mmap returned 0xf7571000, function returns 0xf7571000
> acpi_map_table(cfef0f64, "XSDT");
> acpi_map_memory(3488550756, 36);
> opened /dev/mem (fd=3)
> calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
>   mmap returned 0xf76fd000, function returns 0xf76fdf64
>   having mapped table header
>   reading signature:
> 
> Welcome to SUSE Linux Enterprise Server 11 SP1  (i586) - Kernel
> 3.5.0-rc3+ (hvc0).
> 
> uruk login:
> -----------
> This dump shows that the bug happens the moment acpidump accesses
> the mmapped ACPI table at @cfef0000 (the lower map at e0000 works).

What is the e0000 one? I don't see in your E820 the region being
reserved?

> 
> This is extra unfortunate as in SLES11 acpidump will be called by
> the kbd init script (querying the BIOS NumLock setting!)

Ah. Is the acpidump somewhere easily available to compile? Should
I get it from here:
http://www.lesswatts.org/projects/acpi/utilities.php

> 
> I bisected the Dom0 kernel to find this one (v3.2-rc~194):
> commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
> Merge: 315eb8a f3f436e
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Tue Oct 25 09:17:07 2011 +0200
> 
>     Merge branch 'stable/e820-3.2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
> 
>     * 'stable/e820-3.2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:

Oh boy. v3.2 .. that is eons ago! :-)

>       xen: release all pages within 1-1 p2m mappings
>       xen: allow extra memory to be in multiple regions
>       xen: allow balloon driver to use more than one memory region
>       xen/balloon: simplify test for the end of usable RAM
>       xen/balloon: account for pages released during memory setup
> 
> 
> I tried to find something obvious, but to no avail. At least the new
> E820 looks sane, nothing that would prevent the mapping of the
> requested regions. Reverting this commit will not work easily on
> newer kernels, also is probably not desirable.

The one thing that comes to my mind is the 1-1 mapping having
some issues. Can you boot the kernel with 'debug loglevel=8'. That should
print something like this:

Setting pfn cfef0->cfef7 to 1-1 
or such during bootup.

> 
> But it does not show on every machine here, so the machine E820
> could actually be a differentiator. This particular box was a dual
> socket Barcelona server with 12GB of memory.
> 
> This whole PV memory management goes beyond my knowledge, so I'd
> like to ask for help on this issue.
> If you need more information (I attached the boot log, which shows
> the two E820 tables), please ask. I can also quickly do some
> experiments if needed.

This is strange one - the P2M code should fetch the MFN (so it should
give you cfef0) whenever anybody asks for that. Lets double-check that.

Can you try this little module?
[not compile tested]


#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/pagemap.h>
#include <linux/init.h>
#include <xen/xen.h>
#define ACPITEST  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("acpitest");
MODULE_LICENSE("GPL");
MODULE_VERSION(ACPITEST);

static int __init acpitest_init(void)
{
	unsigned int pfn = 0xcfef0;
	unsigned int mfn;
	void *data;

	mfn = pfn_to_mfn(pfn);
	WARN_ON(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
	if (pfn != mfn) {
		printk(KERN_INFO "raw p2m (%lx) gives us: %lx\n", pfn, get_phys_to_machine(pfn));
		return -EINVAL;
	}
	data = mfn_to_virt(mfn);
	printk(KERN_INFO "va is 0x%lx\n", data);
	print_hex_dump_bytes("acpi:", DUMP_PREFIX_OFFSET, data, PAGE_SIZE);
	
	return 0;
}
static void __exit acpitest_exit(void)
{
}
module_init(acpitest_init);
module_exit(acpitest_exit);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShMac-0006OM-VW; Wed, 20 Jun 2012 15:13:02 +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 1ShMac-0006OH-0U
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:13:02 +0000
Received: from [193.109.254.147:59137] by server-10.bemta-14.messagelabs.com
	id 89/7D-05433-D78E1EF4; Wed, 20 Jun 2012 15:13:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340205180!10678126!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDUyMzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDUyMzg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 20 Jun 2012 15:13:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 15:13:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIiC0MFyD7
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-066-248.pools.arcor-ip.net [88.65.66.248])
	by smtp.strato.de (jorabe mo22) (RZmta 29.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R07870o5KDxKSk ;
	Wed, 20 Jun 2012 17:12:47 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E95BC18637; Wed, 20 Jun 2012 17:12:46 +0200 (CEST)
Date: Wed, 20 Jun 2012 17:12:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120620151246.GA18207@aepfle.de>
References: <20120620121539.GA18219@aepfle.de>
	<4FE1E823020000780008AD6B@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE1E823020000780008AD6B@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grant table errors with qemu-xen-traditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, Jan Beulich wrote:

> >>> On 20.06.12 at 14:15, Olaf Hering <olaf@aepfle.de> wrote:
> 
> > I'm not sure if thats guest or host related, but current xen-unstable
> > with device_model_version="qemu-xen-traditional" fail to access the
> > block device properly, both PV and HVM are affected. The guest runs the
> > upcoming 12.2 kernel, which is based on forward ported xenlinux sources.
> > 
> > I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
> > qemu-xen-traditional, but that does not seem to help.
> > 
> > Any idea whats wrong?
> 
> Did you verify that the added code actually gets executed? The
> log messages provided suggest that the limit didn't really get
> raised from its default of 128.

The patch applied with fuzz, so patch decided to put the change into
blk_disconnect() instead of blk_alloc(). With a correctly refreshed
patch qemu-xen-traditional works again.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShMac-0006OM-VW; Wed, 20 Jun 2012 15:13:02 +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 1ShMac-0006OH-0U
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:13:02 +0000
Received: from [193.109.254.147:59137] by server-10.bemta-14.messagelabs.com
	id 89/7D-05433-D78E1EF4; Wed, 20 Jun 2012 15:13:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340205180!10678126!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDUyMzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDUyMzg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 20 Jun 2012 15:13:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 15:13:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIiC0MFyD7
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-066-248.pools.arcor-ip.net [88.65.66.248])
	by smtp.strato.de (jorabe mo22) (RZmta 29.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R07870o5KDxKSk ;
	Wed, 20 Jun 2012 17:12:47 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E95BC18637; Wed, 20 Jun 2012 17:12:46 +0200 (CEST)
Date: Wed, 20 Jun 2012 17:12:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120620151246.GA18207@aepfle.de>
References: <20120620121539.GA18219@aepfle.de>
	<4FE1E823020000780008AD6B@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE1E823020000780008AD6B@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grant table errors with qemu-xen-traditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, Jan Beulich wrote:

> >>> On 20.06.12 at 14:15, Olaf Hering <olaf@aepfle.de> wrote:
> 
> > I'm not sure if thats guest or host related, but current xen-unstable
> > with device_model_version="qemu-xen-traditional" fail to access the
> > block device properly, both PV and HVM are affected. The guest runs the
> > upcoming 12.2 kernel, which is based on forward ported xenlinux sources.
> > 
> > I added f7f8c33cd49885d69efc2e5f7f9a613d631762e2 to
> > qemu-xen-traditional, but that does not seem to help.
> > 
> > Any idea whats wrong?
> 
> Did you verify that the added code actually gets executed? The
> log messages provided suggest that the limit didn't really get
> raised from its default of 128.

The patch applied with fuzz, so patch decided to put the change into
blk_disconnect() instead of blk_alloc(). With a correctly refreshed
patch qemu-xen-traditional works again.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:18:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShMfd-0006Xz-Mk; Wed, 20 Jun 2012 15:18:13 +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 1ShMfc-0006Xs-4A
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:18:12 +0000
Received: from [85.158.143.35:53783] by server-3.bemta-4.messagelabs.com id
	61/15-05808-3B9E1EF4; Wed, 20 Jun 2012 15:18:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340205479!5795715!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11385 invoked from network); 20 Jun 2012 15:17:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 15:17:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 16:17:58 +0100
Message-Id: <4FE205F1020000780008ADFB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 16:18:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEEC04DC1.0__="
Subject: [Xen-devel] [PATCH] x86/mm: fix mod_l1_entry() return value when
 encountering r/o MMIO page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartEEC04DC1.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While putting together the workaround announced in
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I
found that mod_l1_entry(), upon encountering a set bit in
mmio_ro_ranges, would return 1 instead of 0 (the removal of the write
permission is supposed to be entirely transparent to the caller, even
more so to the calling guest).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
             break;
         case 1:
             l1e_remove_flags(nl1e, _PAGE_RW);
+            rc =3D 0;
             break;
         }
         if ( page )




--=__PartEEC04DC1.0__=
Content-Type: text/plain; name="x86-mm-mod-l1-entry-mmio-ro.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mm-mod-l1-entry-mmio-ro.patch"

x86/mm: fix mod_l1_entry() return value when encountering r/o MMIO =
page=0A=0AWhile putting together the workaround announced in=0Ahttp://lists=
.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I=0Afound that =
mod_l1_entry(), upon encountering a set bit in=0Ammio_ro_ranges, would =
return 1 instead of 0 (the removal of the write=0Apermission is supposed =
to be entirely transparent to the caller, even=0Amore so to the calling =
guest).=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@@ -1875,6 +1875,7 @@ =
static int mod_l1_entry(l1_pgentry_t *pl=0A             break;=0A         =
case 1:=0A             l1e_remove_flags(nl1e, _PAGE_RW);=0A+            rc =
=3D 0;=0A             break;=0A         }=0A         if ( page )=0A
--=__PartEEC04DC1.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

--=__PartEEC04DC1.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 20 15:18:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShMfd-0006Xz-Mk; Wed, 20 Jun 2012 15:18:13 +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 1ShMfc-0006Xs-4A
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:18:12 +0000
Received: from [85.158.143.35:53783] by server-3.bemta-4.messagelabs.com id
	61/15-05808-3B9E1EF4; Wed, 20 Jun 2012 15:18:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340205479!5795715!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11385 invoked from network); 20 Jun 2012 15:17:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 15:17:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 16:17:58 +0100
Message-Id: <4FE205F1020000780008ADFB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 16:18:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEEC04DC1.0__="
Subject: [Xen-devel] [PATCH] x86/mm: fix mod_l1_entry() return value when
 encountering r/o MMIO page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartEEC04DC1.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While putting together the workaround announced in
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I
found that mod_l1_entry(), upon encountering a set bit in
mmio_ro_ranges, would return 1 instead of 0 (the removal of the write
permission is supposed to be entirely transparent to the caller, even
more so to the calling guest).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
             break;
         case 1:
             l1e_remove_flags(nl1e, _PAGE_RW);
+            rc =3D 0;
             break;
         }
         if ( page )




--=__PartEEC04DC1.0__=
Content-Type: text/plain; name="x86-mm-mod-l1-entry-mmio-ro.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mm-mod-l1-entry-mmio-ro.patch"

x86/mm: fix mod_l1_entry() return value when encountering r/o MMIO =
page=0A=0AWhile putting together the workaround announced in=0Ahttp://lists=
.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I=0Afound that =
mod_l1_entry(), upon encountering a set bit in=0Ammio_ro_ranges, would =
return 1 instead of 0 (the removal of the write=0Apermission is supposed =
to be entirely transparent to the caller, even=0Amore so to the calling =
guest).=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@@ -1875,6 +1875,7 @@ =
static int mod_l1_entry(l1_pgentry_t *pl=0A             break;=0A         =
case 1:=0A             l1e_remove_flags(nl1e, _PAGE_RW);=0A+            rc =
=3D 0;=0A             break;=0A         }=0A         if ( page )=0A
--=__PartEEC04DC1.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

--=__PartEEC04DC1.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 20 15:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShMmp-0006iy-KB; Wed, 20 Jun 2012 15:25: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 1ShMmn-0006it-Gp
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:25:37 +0000
Received: from [85.158.138.51:54536] by server-1.bemta-3.messagelabs.com id
	1B/8F-14648-07BE1EF4; Wed, 20 Jun 2012 15:25:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340205935!25775176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 20 Jun 2012 15:25:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:25:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13128719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15: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.213.0;
	Wed, 20 Jun 2012 16:25:31 +0100
Message-ID: <1340205929.4906.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 16:25:29 +0100
In-Reply-To: <alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
> On Tue, 12 Jun 2012, Ian Campbell wrote:
> > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > tools, blockers:
> > > > 
> > > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> > > >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> > > 
> > > Patch was posted and is in upstream qemu, just needs pulling back
> > > into our two clones.
> > 
> > Thanks. CCing Stefano to be sure he knows that...
> 
> qemu-upstream-unstable has been updated, Ian is responsible for
> qemu-xen-unstable.

I was about to ping Ian J about this, because there seems to be breakage
which would be fixed by this (Olaf: "grant table errors with
qemu-xen-traditional" today) but it looks like these patches weren't
actually submitted against the traditional tree? Or at least I can't
find any such thing.

Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply
as is to the trad tree? Has any one tried running it? Is this what Olaf
tested in the thread referenced above?

That thread also references
<4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
should be applied to the trad tree too. Has anyone tested that combo?

I can see how Ian missed this -- it very much looked like those two
patches were for qemu-upstream only to me (from the subject, cc line etc
etc).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShMmp-0006iy-KB; Wed, 20 Jun 2012 15:25: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 1ShMmn-0006it-Gp
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:25:37 +0000
Received: from [85.158.138.51:54536] by server-1.bemta-3.messagelabs.com id
	1B/8F-14648-07BE1EF4; Wed, 20 Jun 2012 15:25:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340205935!25775176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 20 Jun 2012 15:25:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:25:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13128719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15: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.213.0;
	Wed, 20 Jun 2012 16:25:31 +0100
Message-ID: <1340205929.4906.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 16:25:29 +0100
In-Reply-To: <alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
> On Tue, 12 Jun 2012, Ian Campbell wrote:
> > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
> > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > tools, blockers:
> > > > 
> > > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
> > > >       "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)
> > > 
> > > Patch was posted and is in upstream qemu, just needs pulling back
> > > into our two clones.
> > 
> > Thanks. CCing Stefano to be sure he knows that...
> 
> qemu-upstream-unstable has been updated, Ian is responsible for
> qemu-xen-unstable.

I was about to ping Ian J about this, because there seems to be breakage
which would be fixed by this (Olaf: "grant table errors with
qemu-xen-traditional" today) but it looks like these patches weren't
actually submitted against the traditional tree? Or at least I can't
find any such thing.

Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply
as is to the trad tree? Has any one tried running it? Is this what Olaf
tested in the thread referenced above?

That thread also references
<4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
should be applied to the trad tree too. Has anyone tested that combo?

I can see how Ian missed this -- it very much looked like those two
patches were for qemu-upstream only to me (from the subject, cc line etc
etc).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShMtX-0006tY-Et; Wed, 20 Jun 2012 15:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShMtV-0006tT-1j
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:32:33 +0000
Received: from [85.158.143.99:9456] by server-1.bemta-4.messagelabs.com id
	F4/41-24392-01DE1EF4; Wed, 20 Jun 2012 15:32:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340206351!27969479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28516 invoked from network); 20 Jun 2012 15:32:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13128899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:32:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:32:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShMtS-0005QM-To; Wed, 20 Jun 2012 15:32:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShMtS-00005B-Sa;
	Wed, 20 Jun 2012 16:32:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.60686.870961.578671@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:32:30 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1340200879.20225.11.camel@Solace>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
	<20449.54129.523732.173929@mariner.uk.xensource.com>
	<1340200879.20225.11.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-win7-amd64"):
> On Wed, 2012-06-20 at 14:43 +0100, Ian Jackson wrote:
> > The bisector has repro'd this on the same host with 6 tests:
> > alternately failures for 9d1fd58ff602 and successes for 32034d1914a6.
> 
> Which means it might be unrelated from that specific commit (sorry if
> it's a stupid question, just want to be sure I'm getting things
> correct :-/ )

No.  If it fails with 9d1fd58ff602 and succeeds with 32034d1914a6 then
9d1fd58ff602 is responsible because 32034d1914a6 is the only parent of
9d1fd58ff602.

> > So if it's a heisenbug we've been moderately (but not outrageously)
> > unlucky that it actually fingered a specific changeset rather than
> > just shrugging its shoulders and moving on.  (It does the latter quite
> > a lot.)
> 
> Just to be sure, this part of the bisector report:
> 
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-win7-amd64
> test windows-install
> 
> means that the test that failed was 'job
> test-amd64-amd64-xl-win7-amd64' (and, specifically, during
> 'windows-install' phase), right?

Yes.

> I'm asking because I actually found a bug in that change, _but_ it only
> comes into play if the SEDF scheduler is being used. In fact, this test
> also fails:
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13053/test-amd64-amd64-xl-sedf/info.html
...
> 2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg
> libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument
> libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3
> Parsing config from /etc/xen/debian.guest.osstest.cfg
> 
> Which is actually related to my patch, and for which I already have a
> fix ready.

Right.

> OTOH, I really don't see how that patch might cause that HVM windows
> domain to die, given the log for 'test-amd64-amd64-xl-sedf' says this:
> 
> Parsing config from /etc/xen/win.guest.osstest.cfg
> Daemon running with PID 2642
> 
> Which seems to mean, at least to me, that the check happened without
> causing any issues (as it, conversely, does when SEDF is the scheduler).

The failure of the non-sedf test is that Windows takes too long to
become ready.

If you look at this page:

  http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.windows-install.html

you can see what the bisector did.

Flights 13024, 13025, 13087, 13096 and 13103 used code built from 
32034d1914a6 and passed.

Flights 13095, 13102 and 13105 used code built from from 9d1fd58ff602
and failed.  These all used the builds from flight 13033, which was
another bisector run.

It is possible that the build in 13033 is broken somehow.
Xen and tools came from here:
  http://www.chiark.greenend.org.uk/~xensrcts/logs/13033/build-amd64/
Dom0 kernel came from here:
  http://www.chiark.greenend.org.uk/~xensrcts/logs/13033/build-amd64-pvops/

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShMtX-0006tY-Et; Wed, 20 Jun 2012 15:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShMtV-0006tT-1j
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:32:33 +0000
Received: from [85.158.143.99:9456] by server-1.bemta-4.messagelabs.com id
	F4/41-24392-01DE1EF4; Wed, 20 Jun 2012 15:32:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340206351!27969479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28516 invoked from network); 20 Jun 2012 15:32:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13128899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:32:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:32:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShMtS-0005QM-To; Wed, 20 Jun 2012 15:32:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShMtS-00005B-Sa;
	Wed, 20 Jun 2012 16:32:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.60686.870961.578671@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:32:30 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1340200879.20225.11.camel@Solace>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
	<20449.54129.523732.173929@mariner.uk.xensource.com>
	<1340200879.20225.11.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-win7-amd64"):
> On Wed, 2012-06-20 at 14:43 +0100, Ian Jackson wrote:
> > The bisector has repro'd this on the same host with 6 tests:
> > alternately failures for 9d1fd58ff602 and successes for 32034d1914a6.
> 
> Which means it might be unrelated from that specific commit (sorry if
> it's a stupid question, just want to be sure I'm getting things
> correct :-/ )

No.  If it fails with 9d1fd58ff602 and succeeds with 32034d1914a6 then
9d1fd58ff602 is responsible because 32034d1914a6 is the only parent of
9d1fd58ff602.

> > So if it's a heisenbug we've been moderately (but not outrageously)
> > unlucky that it actually fingered a specific changeset rather than
> > just shrugging its shoulders and moving on.  (It does the latter quite
> > a lot.)
> 
> Just to be sure, this part of the bisector report:
> 
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-win7-amd64
> test windows-install
> 
> means that the test that failed was 'job
> test-amd64-amd64-xl-win7-amd64' (and, specifically, during
> 'windows-install' phase), right?

Yes.

> I'm asking because I actually found a bug in that change, _but_ it only
> comes into play if the SEDF scheduler is being used. In fact, this test
> also fails:
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13053/test-amd64-amd64-xl-sedf/info.html
...
> 2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg
> libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument
> libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3
> Parsing config from /etc/xen/debian.guest.osstest.cfg
> 
> Which is actually related to my patch, and for which I already have a
> fix ready.

Right.

> OTOH, I really don't see how that patch might cause that HVM windows
> domain to die, given the log for 'test-amd64-amd64-xl-sedf' says this:
> 
> Parsing config from /etc/xen/win.guest.osstest.cfg
> Daemon running with PID 2642
> 
> Which seems to mean, at least to me, that the check happened without
> causing any issues (as it, conversely, does when SEDF is the scheduler).

The failure of the non-sedf test is that Windows takes too long to
become ready.

If you look at this page:

  http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.windows-install.html

you can see what the bisector did.

Flights 13024, 13025, 13087, 13096 and 13103 used code built from 
32034d1914a6 and passed.

Flights 13095, 13102 and 13105 used code built from from 9d1fd58ff602
and failed.  These all used the builds from flight 13033, which was
another bisector run.

It is possible that the build in 13033 is broken somehow.
Xen and tools came from here:
  http://www.chiark.greenend.org.uk/~xensrcts/logs/13033/build-amd64/
Dom0 kernel came from here:
  http://www.chiark.greenend.org.uk/~xensrcts/logs/13033/build-amd64-pvops/

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShMvN-00071F-4M; Wed, 20 Jun 2012 15:34: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 1ShMvL-000712-FW
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:34:27 +0000
Received: from [85.158.143.35:3563] by server-1.bemta-4.messagelabs.com id
	DE/24-24392-28DE1EF4; Wed, 20 Jun 2012 15:34:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340206465!14079498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17993 invoked from network); 20 Jun 2012 15:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13128955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:34:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 16:34:25 +0100
Message-ID: <1340206463.4906.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 20 Jun 2012 16:34:23 +0100
In-Reply-To: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1339608534 14400
> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> tools/hotplug: fix locking

A better title would be "tools/hotplug: Switch to locking with flock"
since "fix" is not very descriptive.

The commit message should also state why changing this scheme is
preferable to fixing the current one.

Is this flock tool widely available? Does it need to be added to the
dependencies in the README?

> The current locking implementation would allow two processes get the lock
> simultaneously:

[...snip shell trace...]

Can you add a line or two of analysis to explain where in that shell
spew things are actually going wrong and why?

> This patch is ported from Red Hat Enterprise Linux 5.8.

I think we need a Signed-off-by from the original patch author. (Unless
DCO clause b somehow applies?)


Thanks,
Ian.

> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> 
> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
> @@ -1,5 +1,6 @@
>  #
>  # Copyright (c) 2005 XenSource Ltd.
> +# Copyright (c) 2007 Red Hat
>  #
>  # This library is free software; you can redistribute it and/or
>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
> @@ -19,92 +20,30 @@
>  # Serialisation
>  #
>  
> -LOCK_SLEEPTIME=1
> -LOCK_SPINNING_RETRIES=5
> -LOCK_RETRIES=100
>  LOCK_BASEDIR=/var/run/xen-hotplug
>  
> +_setlockfd()
> +{
> +    local i
> +    for ((i = 0; i < ${#_lockdict}; i++))
> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> +    done
> +    _lockdict[$i]="$1"
> +    let _lockfd=200+i
> +}
> +
>  
>  claim_lock()
>  {
> -  local lockdir="$LOCK_BASEDIR/$1"
> -  mkdir -p "$LOCK_BASEDIR"
> -  _claim_lock "$lockdir"
> +    mkdir -p "$LOCK_BASEDIR"
> +    _setlockfd $1
> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
> +    flock -x $_lockfd
>  }
>  
> 
>  release_lock()
>  {
> -  _release_lock "$LOCK_BASEDIR/$1"
> +    _setlockfd $1
> +    flock -u $_lockfd
>  }
> -
> -
> -# This function will be redefined in xen-hotplug-common.sh.
> -sigerr() {
> -  exit 1
> -}
> -
> -
> -_claim_lock()
> -{
> -  local lockdir="$1"
> -  local owner=$(_lock_owner "$lockdir")
> -  local retries=0
> -
> -  while [ $retries -lt $LOCK_RETRIES ]
> -  do
> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> -      _update_lock_info "$lockdir" && return
> -
> -    local new_owner=$(_lock_owner "$lockdir")
> -    if [ "$new_owner" != "$owner" ]
> -    then
> -      owner="$new_owner"
> -      retries=0
> -    else
> -      local pid=$(echo $owner | cut -d : -f 1)
> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> -      then
> -        _release_lock $lockdir
> -      fi
> -    fi
> -
> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
> -    then
> -      sleep $LOCK_SLEEPTIME
> -    else
> -      sleep 0
> -    fi
> -    retries=$(($retries + 1))
> -  done
> -  _steal_lock "$lockdir"
> -}
> -
> -
> -_release_lock()
> -{
> -  trap sigerr ERR
> -  rm -rf "$1" 2>/dev/null || true
> -}
> -
> -
> -_steal_lock()
> -{
> -  local lockdir="$1"
> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> -  log err "Forced to steal lock on $lockdir from $owner!"
> -  _release_lock "$lockdir"
> -  _claim_lock "$lockdir"
> -}
> -
> -
> -_lock_owner()
> -{
> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> -}
> -
> -
> -_update_lock_info()
> -{
> -  echo "$$: $0" >"$1/owner"
> -}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 15:34:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShMvN-00071F-4M; Wed, 20 Jun 2012 15:34: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 1ShMvL-000712-FW
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:34:27 +0000
Received: from [85.158.143.35:3563] by server-1.bemta-4.messagelabs.com id
	DE/24-24392-28DE1EF4; Wed, 20 Jun 2012 15:34:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340206465!14079498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17993 invoked from network); 20 Jun 2012 15:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13128955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:34:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 16:34:25 +0100
Message-ID: <1340206463.4906.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 20 Jun 2012 16:34:23 +0100
In-Reply-To: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1339608534 14400
> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> tools/hotplug: fix locking

A better title would be "tools/hotplug: Switch to locking with flock"
since "fix" is not very descriptive.

The commit message should also state why changing this scheme is
preferable to fixing the current one.

Is this flock tool widely available? Does it need to be added to the
dependencies in the README?

> The current locking implementation would allow two processes get the lock
> simultaneously:

[...snip shell trace...]

Can you add a line or two of analysis to explain where in that shell
spew things are actually going wrong and why?

> This patch is ported from Red Hat Enterprise Linux 5.8.

I think we need a Signed-off-by from the original patch author. (Unless
DCO clause b somehow applies?)


Thanks,
Ian.

> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> 
> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
> @@ -1,5 +1,6 @@
>  #
>  # Copyright (c) 2005 XenSource Ltd.
> +# Copyright (c) 2007 Red Hat
>  #
>  # This library is free software; you can redistribute it and/or
>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
> @@ -19,92 +20,30 @@
>  # Serialisation
>  #
>  
> -LOCK_SLEEPTIME=1
> -LOCK_SPINNING_RETRIES=5
> -LOCK_RETRIES=100
>  LOCK_BASEDIR=/var/run/xen-hotplug
>  
> +_setlockfd()
> +{
> +    local i
> +    for ((i = 0; i < ${#_lockdict}; i++))
> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> +    done
> +    _lockdict[$i]="$1"
> +    let _lockfd=200+i
> +}
> +
>  
>  claim_lock()
>  {
> -  local lockdir="$LOCK_BASEDIR/$1"
> -  mkdir -p "$LOCK_BASEDIR"
> -  _claim_lock "$lockdir"
> +    mkdir -p "$LOCK_BASEDIR"
> +    _setlockfd $1
> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
> +    flock -x $_lockfd
>  }
>  
> 
>  release_lock()
>  {
> -  _release_lock "$LOCK_BASEDIR/$1"
> +    _setlockfd $1
> +    flock -u $_lockfd
>  }
> -
> -
> -# This function will be redefined in xen-hotplug-common.sh.
> -sigerr() {
> -  exit 1
> -}
> -
> -
> -_claim_lock()
> -{
> -  local lockdir="$1"
> -  local owner=$(_lock_owner "$lockdir")
> -  local retries=0
> -
> -  while [ $retries -lt $LOCK_RETRIES ]
> -  do
> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> -      _update_lock_info "$lockdir" && return
> -
> -    local new_owner=$(_lock_owner "$lockdir")
> -    if [ "$new_owner" != "$owner" ]
> -    then
> -      owner="$new_owner"
> -      retries=0
> -    else
> -      local pid=$(echo $owner | cut -d : -f 1)
> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> -      then
> -        _release_lock $lockdir
> -      fi
> -    fi
> -
> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
> -    then
> -      sleep $LOCK_SLEEPTIME
> -    else
> -      sleep 0
> -    fi
> -    retries=$(($retries + 1))
> -  done
> -  _steal_lock "$lockdir"
> -}
> -
> -
> -_release_lock()
> -{
> -  trap sigerr ERR
> -  rm -rf "$1" 2>/dev/null || true
> -}
> -
> -
> -_steal_lock()
> -{
> -  local lockdir="$1"
> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> -  log err "Forced to steal lock on $lockdir from $owner!"
> -  _release_lock "$lockdir"
> -  _claim_lock "$lockdir"
> -}
> -
> -
> -_lock_owner()
> -{
> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> -}
> -
> -
> -_update_lock_info()
> -{
> -  echo "$$: $0" >"$1/owner"
> -}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 15:39:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:39: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 1ShMzd-0007En-Qa; Wed, 20 Jun 2012 15:38: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 1ShMzc-0007Eg-4v
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:38:52 +0000
Received: from [85.158.143.35:52475] by server-2.bemta-4.messagelabs.com id
	41/EC-17938-B8EE1EF4; Wed, 20 Jun 2012 15:38:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340206730!12541139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18635 invoked from network); 20 Jun 2012 15:38:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:38:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15: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.213.0;
	Wed, 20 Jun 2012 16:38:50 +0100
Message-ID: <1340206729.4906.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 16:38:49 +0100
In-Reply-To: <alpine.DEB.2.02.1206061833290.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061833290.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/38] arm: use correct attributes for
 mappings in copy_from_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 Wed, 2012-06-06 at 18:38 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
> > a device type mapping (hence dev shared).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/kernel.c       |    8 ++++----
> >  xen/arch/arm/setup.c        |    2 +-
> >  xen/include/asm-arm/setup.h |    2 +-
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index 130d488..1a705c9 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -39,7 +39,7 @@ struct minimal_dtb_header {
> >   * @paddr: source physical address
> >   * @len: length to copy
> >   */
> > -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
> > +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr)
> >  {
> >      void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
> >  
> > @@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
> >          s = paddr & (PAGE_SIZE-1);
> >          l = min(PAGE_SIZE - s, len);
> >  
> > -        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
> > +        set_fixmap(FIXMAP_MISC, p, mattr);
> >          memcpy(dst, src + s, l);
> >  
> >          paddr += l;
> > @@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
> >      /*
> >       * Check for an appended DTB.
> >       */
> > -    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
> > +    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
> >      if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
> >          end += be32_to_cpu(dtb_hdr.total_size);
> >      }
> > @@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
> >      if ( info->kernel_img == NULL )
> >          panic("Cannot allocate temporary buffer for kernel.\n");
> >  
> > -    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> > +    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
> >  
> >      if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
> >          return rc;
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index b0cfacc..f5473cd 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
> >       * TODO: handle other payloads too.
> >       */
> >      device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
> > -    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
> > +    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
> >  
> >      /* Add non-xenheap memory */
> >      init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
> > diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> > index 05ff89e..faadccc 100644
> > --- a/xen/include/asm-arm/setup.h
> > +++ b/xen/include/asm-arm/setup.h
> > @@ -3,7 +3,7 @@
> >  
> >  #include <public/version.h>
> >  
> > -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> > +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr);
> >  
> >  void arch_get_xen_caps(xen_capabilities_info_t *info);
> >  
> 
> The patch is correct, but it shouldn't call the new parameter mattr
> because it can easily be confused with the memattr bits (see
> http://marc.info/?l=xen-devel&m=133856578918985).
> I would call it "int attrindx" instead.

Yes, this is a good point and attrindx is a good name, I'll make that
change.

I also added a comment to the two sets of #defines explaining which they
are. Updated patch is:

8<------------------------------------------------

>From 08f78c5b7e31ed0f6533ff6a378c586c0db58276 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 14:02:26 +0100
Subject: [PATCH] arm: use correct attributes for mappings in
 copy_from_paddr()

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/page.h  |   15 +++++++++++++++
 xen/include/asm-arm/setup.h |    2 +-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..2d56130 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, attrindx);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d6c0178..fd70553 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 6efe23c..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,13 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
 #define MATTR_DEV     0x1
 #define MATTR_MEM     0xf
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..6433b4e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Wed Jun 20 15:39:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:39: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 1ShMzd-0007En-Qa; Wed, 20 Jun 2012 15:38: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 1ShMzc-0007Eg-4v
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:38:52 +0000
Received: from [85.158.143.35:52475] by server-2.bemta-4.messagelabs.com id
	41/EC-17938-B8EE1EF4; Wed, 20 Jun 2012 15:38:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340206730!12541139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18635 invoked from network); 20 Jun 2012 15:38:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:38:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15: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.213.0;
	Wed, 20 Jun 2012 16:38:50 +0100
Message-ID: <1340206729.4906.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 20 Jun 2012 16:38:49 +0100
In-Reply-To: <alpine.DEB.2.02.1206061833290.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-23-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061833290.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 23/38] arm: use correct attributes for
 mappings in copy_from_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 Wed, 2012-06-06 at 18:38 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
> > a device type mapping (hence dev shared).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/kernel.c       |    8 ++++----
> >  xen/arch/arm/setup.c        |    2 +-
> >  xen/include/asm-arm/setup.h |    2 +-
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index 130d488..1a705c9 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -39,7 +39,7 @@ struct minimal_dtb_header {
> >   * @paddr: source physical address
> >   * @len: length to copy
> >   */
> > -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
> > +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr)
> >  {
> >      void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
> >  
> > @@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
> >          s = paddr & (PAGE_SIZE-1);
> >          l = min(PAGE_SIZE - s, len);
> >  
> > -        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
> > +        set_fixmap(FIXMAP_MISC, p, mattr);
> >          memcpy(dst, src + s, l);
> >  
> >          paddr += l;
> > @@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
> >      /*
> >       * Check for an appended DTB.
> >       */
> > -    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
> > +    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
> >      if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
> >          end += be32_to_cpu(dtb_hdr.total_size);
> >      }
> > @@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
> >      if ( info->kernel_img == NULL )
> >          panic("Cannot allocate temporary buffer for kernel.\n");
> >  
> > -    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> > +    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
> >  
> >      if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
> >          return rc;
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index b0cfacc..f5473cd 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
> >       * TODO: handle other payloads too.
> >       */
> >      device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
> > -    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
> > +    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
> >  
> >      /* Add non-xenheap memory */
> >      init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
> > diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> > index 05ff89e..faadccc 100644
> > --- a/xen/include/asm-arm/setup.h
> > +++ b/xen/include/asm-arm/setup.h
> > @@ -3,7 +3,7 @@
> >  
> >  #include <public/version.h>
> >  
> > -void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> > +void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int mattr);
> >  
> >  void arch_get_xen_caps(xen_capabilities_info_t *info);
> >  
> 
> The patch is correct, but it shouldn't call the new parameter mattr
> because it can easily be confused with the memattr bits (see
> http://marc.info/?l=xen-devel&m=133856578918985).
> I would call it "int attrindx" instead.

Yes, this is a good point and attrindx is a good name, I'll make that
change.

I also added a comment to the two sets of #defines explaining which they
are. Updated patch is:

8<------------------------------------------------

>From 08f78c5b7e31ed0f6533ff6a378c586c0db58276 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 14:02:26 +0100
Subject: [PATCH] arm: use correct attributes for mappings in
 copy_from_paddr()

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/page.h  |   15 +++++++++++++++
 xen/include/asm-arm/setup.h |    2 +-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..2d56130 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, attrindx);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d6c0178..fd70553 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 6efe23c..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,13 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
 #define MATTR_DEV     0x1
 #define MATTR_MEM     0xf
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..6433b4e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Wed Jun 20 15:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShN0u-0007Ip-8h; Wed, 20 Jun 2012 15:40:12 +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 1ShN0s-0007Ih-SB
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:40:11 +0000
Received: from [193.109.254.147:64974] by server-4.bemta-14.messagelabs.com id
	57/C7-02077-ADEE1EF4; Wed, 20 Jun 2012 15:40:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340206808!5080609!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24107 invoked from network); 20 Jun 2012 15:40:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 15:40:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 16:40:08 +0100
Message-Id: <4FE20B23020000780008AE16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 16:40:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340205929.4906.66.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
>> On Tue, 12 Jun 2012, Ian Campbell wrote:
>> > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
>> > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > > tools, blockers:
>> > > > 
>> > > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
>> > > >       "qemu/xendisk: set maximum number of grants to be used" (Jan 
> Beulich)
>> > > 
>> > > Patch was posted and is in upstream qemu, just needs pulling back
>> > > into our two clones.
>> > 
>> > Thanks. CCing Stefano to be sure he knows that...
>> 
>> qemu-upstream-unstable has been updated, Ian is responsible for
>> qemu-xen-unstable.
> 
> I was about to ping Ian J about this, because there seems to be breakage
> which would be fixed by this (Olaf: "grant table errors with
> qemu-xen-traditional" today) but it looks like these patches weren't
> actually submitted against the traditional tree? Or at least I can't
> find any such thing.
> 
> Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply
> as is to the trad tree? Has any one tried running it? Is this what Olaf
> tested in the thread referenced above?

Apparently yes, except that the change did get applied to the
wrong function (and hence didn't work).

> That thread also references
> <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
> should be applied to the trad tree too. Has anyone tested that combo?
> 
> I can see how Ian missed this -- it very much looked like those two
> patches were for qemu-upstream only to me (from the subject, cc line etc
> etc).

I didn't think that I needed to formally submit patches that were
requested to be ported over to -traditional when they already
went into upstream qemu. If I'm wrong with this, then please let
me know and I'll submit both patches asap.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShN0u-0007Ip-8h; Wed, 20 Jun 2012 15:40:12 +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 1ShN0s-0007Ih-SB
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:40:11 +0000
Received: from [193.109.254.147:64974] by server-4.bemta-14.messagelabs.com id
	57/C7-02077-ADEE1EF4; Wed, 20 Jun 2012 15:40:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340206808!5080609!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24107 invoked from network); 20 Jun 2012 15:40:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 15:40:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 16:40:08 +0100
Message-Id: <4FE20B23020000780008AE16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 16:40:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340205929.4906.66.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
>> On Tue, 12 Jun 2012, Ian Campbell wrote:
>> > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:
>> > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > > tools, blockers:
>> > > > 
>> > > >     * Adjustments needed for qdisk backend to work on non-pvops Linux.
>> > > >       "qemu/xendisk: set maximum number of grants to be used" (Jan 
> Beulich)
>> > > 
>> > > Patch was posted and is in upstream qemu, just needs pulling back
>> > > into our two clones.
>> > 
>> > Thanks. CCing Stefano to be sure he knows that...
>> 
>> qemu-upstream-unstable has been updated, Ian is responsible for
>> qemu-xen-unstable.
> 
> I was about to ping Ian J about this, because there seems to be breakage
> which would be fixed by this (Olaf: "grant table errors with
> qemu-xen-traditional" today) but it looks like these patches weren't
> actually submitted against the traditional tree? Or at least I can't
> find any such thing.
> 
> Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply
> as is to the trad tree? Has any one tried running it? Is this what Olaf
> tested in the thread referenced above?

Apparently yes, except that the change did get applied to the
wrong function (and hence didn't work).

> That thread also references
> <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
> should be applied to the trad tree too. Has anyone tested that combo?
> 
> I can see how Ian missed this -- it very much looked like those two
> patches were for qemu-upstream only to me (from the subject, cc line etc
> etc).

I didn't think that I needed to formally submit patches that were
requested to be ported over to -traditional when they already
went into upstream qemu. If I'm wrong with this, then please let
me know and I'll submit both patches asap.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:45:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:45: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 1ShN5d-0007Xt-W1; Wed, 20 Jun 2012 15:45: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 1ShN5c-0007Xn-Q1
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 15:45:05 +0000
Received: from [193.109.254.147:65430] by server-1.bemta-14.messagelabs.com id
	73/AD-24612-000F1EF4; Wed, 20 Jun 2012 15:45:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340207103!3567881!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15507 invoked from network); 20 Jun 2012 15:45:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 15:45:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 16:45:02 +0100
Message-Id: <4FE20C49020000780008AE25@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 16:45:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
In-Reply-To: <4FD9D559.9050206@amd.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0F21AC39.3__="
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled 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.

--=__Part0F21AC39.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 14.06.12 at 14:13, Wei Wang <wei.wang2@amd.com> wrote:
> Am 12.06.2012 18:43, schrieb Jan Beulich:
>>>>> On 12.06.12 at 18:08, Andrew Cooper<andrew.cooper3@citrix.com>  =
wrote:
>>> On 12/06/12 16:13, Jan Beulich wrote:
>>>>>>> On 12.06.12 at 14:02, Wei Wang<wei.wang2@amd.com>  wrote:
>>>>> I had attached a revised patch, please check it.
>>>> While the patch technically looks better now, you didn't eliminate
>>>> my objections to the approach you take, nor did you comment on
>>>> the proposed alternative.
>>>>
>>>> A fundamental problem is that your IOMMUs show up as a "normal"
>>>> PCI devices, breaking the separation between what is being
>>>> managed by the hypervisor vs by the Dom0 kernel. (This even
>>>> allows something as odd as passing through an IOMMU to a
>>>> DomU, which would clearly upset the hypervisor.)
>>>>
>>>>> I found that the following Linux commit triggers this issue. It has =
been
>>>>> included into 3.4 pv_ops.
>>>>>
>>>>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>>>>     Author: Eric W. Biederman<ebiederm@xmission.com>
>>>>>     Date:   Mon Oct 17 11:46:06 2011 -0700
>>>>>
>>>>>     PCI: msi: Disable msi interrupts when we initialize a pci device =
"
>>>> Thanks for locating this. As it stands, it is incomplete though
>>>> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
>>>> it won't have a means to suppress the "screaming" interrupts.
>>>
>>> I feel that the correct solution would be for Xen to hide the PCI
>>> devices from dom0.  Xen already hides the DMAR ACPI table (by turning =
it
>>> to an XMAR table), and this would be the logical way to proceed now =
that
>>> IOMMU internals are appearing as PCI devices.
>=20
> That sounds absolutely good to me. thanks for the suggestion.
>=20
>> That is precisely what I suggested in my response to the first
>> version of this patch, and I'd also volunteer to look into putting
>> together a first draft implementation if we sort of agree that
>> this is the way to go.
>=20
> Cool! thanks for doing that. Looking forward to it in Xen 4.2 since=20
> iommu msi is really broken with recent Linux dom0...

Rather than submitting it for inclusion immediately, I'd rather see
you first use it successfully. Below/attached what appears to
work fine for me in contrived situations (i.e. hiding bridges with
nothing connected, as I still don't have any AMD IOMMU system
at hand).

Jan

Note that due to ptwr_do_page_fault() being run first, there'll be a
MEM_LOG() issued for each such attempt. If that's undesirable, the
order of the calls would need to be swapped.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
             break;
         case 1:
             l1e_remove_flags(nl1e, _PAGE_RW);
+            rc =3D 0;
             break;
         }
         if ( page )
@@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
     return 0;
 }
=20
+#ifdef __x86_64__
+/*************************
+ * fault handling for read-only MMIO pages
+ */
+
+struct mmio_ro_emulate_ctxt {
+    struct x86_emulate_ctxt ctxt;
+    unsigned long cr2;
+};
+
+static int mmio_ro_emulated_read(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    return X86EMUL_UNHANDLEABLE;
+}
+
+static int mmio_ro_emulated_write(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =3D
+        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
+
+    /* Only allow naturally-aligned stores at the original %cr2 address. =
*/
+    if ( ((bytes | offset) & (bytes - 1)) || offset !=3D mmio_ro_ctxt->cr2=
 )
+    {
+        MEM_LOG("mmio_ro_emulate: bad access (cr2=3D%lx, addr=3D%lx, =
bytes=3D%u)",
+                mmio_ro_ctxt->cr2, offset, bytes);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    return X86EMUL_OKAY;
+}
+
+static const struct x86_emulate_ops mmio_ro_emulate_ops =3D {
+    .read       =3D mmio_ro_emulated_read,
+    .insn_fetch =3D ptwr_emulated_read,
+    .write      =3D mmio_ro_emulated_write,
+};
+
+/* Check if guest is trying to modify a r/o MMIO page. */
+int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
+                          struct cpu_user_regs *regs)
+{
+    l1_pgentry_t      pte;
+    unsigned long     mfn;
+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) ?
+                                  32 : BITS_PER_LONG;
+    struct mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {
+        .ctxt.regs =3D regs,
+        .ctxt.addr_size =3D addr_size,
+        .ctxt.sp_size =3D addr_size,
+        .cr2 =3D addr
+    };
+    int rc;
+
+    /* Attempt to read the PTE that maps the VA being accessed. */
+    guest_get_eff_l1e(v, addr, &pte);
+
+    /* We are looking only for read-only mappings of MMIO pages. */
+    if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESE=
NT) )
+        return 0;
+
+    mfn =3D l1e_get_pfn(pte);
+    if ( mfn_valid(mfn) )
+    {
+        struct page_info *page =3D mfn_to_page(mfn);
+        struct domain *owner =3D page_get_owner_and_reference(page);
+
+        if ( owner )
+            put_page(page);
+        if ( owner !=3D dom_io )
+            return 0;
+    }
+
+    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
+        return 0;
+
+    rc =3D x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);
+
+    return rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
+}
+#endif /* __x86_64__ */
+
 void free_xen_pagetable(void *v)
 {
     if ( system_state =3D=3D SYS_STATE_early_boot )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
         return 0;
     }
=20
-    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
-         guest_kernel_mode(v, regs) )
-    {
-        unsigned int mbs =3D PFEC_write_access;
-        unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;
-
-        /* Do not check if access-protection fault since the page may=20
-           legitimately be not present in shadow page tables */
-        if ( !paging_mode_enabled(d) )
-            mbs |=3D PFEC_page_present;
-
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&
+    if ( guest_kernel_mode(v, regs) &&
+         !(regs->error_code & (PFEC_reserved_bit | PFEC_insn_fetch)) &&
+         (regs->error_code & PFEC_write_access) )
+    {
+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
+             /* Do not check if access-protection fault since the page =
may
+                legitimately be not present in shadow page tables */
+             (paging_mode_enabled(d) ||
+              (regs->error_code & PFEC_page_present)) &&
              ptwr_do_page_fault(v, addr, regs) )
             return EXCRET_fault_fixed;
+
+#ifdef __x86_64__
+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_present) &&
+             mmio_ro_do_page_fault(v, addr, regs) )
+            return EXCRET_fault_fixed;
+#endif
     }
=20
     /* For non-external shadowed guests, we fix up both their own=20
@@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,=20
         return 0;
=20
     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;
+    if ( write )
+    {
+        const unsigned long *ro_map =3D pci_get_ro_map(0);
+
+        if ( ro_map && test_bit(machine_bdf, ro_map) )
+            return 0;
+    }
     start =3D d->arch.pci_cf8 & 0xFF;
     end =3D start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
--- a/xen/arch/x86/x86_32/pci.c
+++ b/xen/arch/x86/x86_32/pci.c
@@ -6,6 +6,7 @@
=20
 #include <xen/spinlock.h>
 #include <xen/pci.h>
+#include <xen/init.h>
 #include <asm/io.h>
=20
 #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
@@ -70,3 +71,7 @@ void pci_conf_write32(
     BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
 }
+
+void __init arch_pci_ro_device(int seg, int bdf)
+{
+}
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const=20
     return (void __iomem *) virt;
 }
=20
+void arch_pci_ro_device(int seg, int bdf)
+{
+    unsigned int idx, bus =3D PCI_BUS(bdf);
+
+    for (idx =3D 0; idx < pci_mmcfg_config_num; ++idx) {
+        const struct acpi_mcfg_allocation *cfg =3D pci_mmcfg_virt[idx].cfg=
;
+        unsigned long mfn =3D (cfg->address >> PAGE_SHIFT) + bdf;
+
+        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment !=3D seg ||
+            cfg->start_bus_number > bus || cfg->end_bus_number < bus)
+            continue;
+
+        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
+            printk(XENLOG_ERR
+                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) =
read-only\n",
+                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
+                   mfn);
+    }
+}
+
 int pci_mmcfg_arch_enable(unsigned int idx)
 {
     const typeof(pci_mmcfg_config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg;
+    const unsigned long *ro_map =3D pci_get_ro_map(cfg->pci_segment);
=20
     if (pci_mmcfg_virt[idx].virt)
         return 0;
@@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
     }
     printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
            cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
+    if (ro_map) {
+        unsigned int bdf =3D PCI_BDF(cfg->start_bus_number, 0, 0);
+        unsigned int end =3D PCI_BDF(cfg->end_bus_number, -1, -1);
+
+        while ((bdf =3D find_next_bit(ro_map, end + 1, bdf)) <=3D end) {
+            arch_pci_ro_device(cfg->pci_segment, bdf);
+            if (bdf++ =3D=3D end)
+                break;
+        }
+    }
     return 0;
 }
=20
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
     if ( rt )
         return -ENODEV;
=20
+    rt =3D pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
+    if ( rt )
+        printk(XENLOG_ERR
+               "Could not mark config space of %04x:%02x:%02x.%u =
read-only (%d)\n",
+               iommu->seg, bus, dev, func, rt);
+
     list_add_tail(&iommu->list, &amd_iommu_head);
=20
     return 0;
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
 unlock:
     spin_unlock(&d->event_lock);
 }
-
-static int __init setup_mmio_ro_ranges(void)
-{
-    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
-                                  RANGESETF_prettyprint_hex);
-    return 0;
-}
-__initcall(setup_mmio_ro_ranges);
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -36,6 +36,7 @@
 struct pci_seg {
     struct list_head alldevs_list;
     u16 nr;
+    unsigned long *ro_map;
     /* bus2bridge_lock protects bus2bridge array */
     spinlock_t bus2bridge_lock;
 #define MAX_BUSES 256
@@ -106,6 +107,8 @@ void __init pt_pci_init(void)
     radix_tree_init(&pci_segments);
     if ( !alloc_pseg(0) )
         panic("Could not initialize PCI segment 0\n");
+    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
+                                  RANGESETF_prettyprint_hex);
 }
=20
 int __init pci_add_segment(u16 seg)
@@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
     return alloc_pseg(seg) ? 0 : -ENOMEM;
 }
=20
+const unsigned long *pci_get_ro_map(u16 seg)
+{
+    struct pci_seg *pseg =3D get_pseg(seg);
+
+    return pseg ? pseg->ro_map : NULL;
+}
+
 static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
 {
     struct pci_dev *pdev;
@@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
     xfree(pdev);
 }
=20
+int __init pci_ro_device(int seg, int bus, int devfn)
+{
+    struct pci_seg *pseg =3D alloc_pseg(seg);
+    struct pci_dev *pdev;
+
+    if ( !pseg )
+        return -ENOMEM;
+    pdev =3D alloc_pdev(pseg, bus, devfn);
+    if ( !pdev )
+        return -ENOMEM;
+
+    if ( !pseg->ro_map )
+    {
+        size_t sz =3D BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long=
);
+
+        pseg->ro_map =3D alloc_xenheap_pages(get_order_from_bytes(sz), =
0);
+        if ( !pseg->ro_map )
+            return -ENOMEM;
+        memset(pseg->ro_map, 0, sz);
+    }
+
+    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
+    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
+
+    return 0;
+}
+
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
 {
     struct pci_seg *pseg =3D get_pseg(seg);
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
=20
 int  ptwr_do_page_fault(struct vcpu *, unsigned long,
                         struct cpu_user_regs *);
+int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
+                           struct cpu_user_regs *);
=20
 int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
=20
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
 void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
 void pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
+const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info =
*);
 int pci_remove_device(u16 seg, u8 bus, u8 devfn);
+int pci_ro_device(int seg, int bus, int devfn);
+void arch_pci_ro_device(int seg, int bdf);
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
 struct pci_dev *pci_get_pdev_by_domain(
     struct domain *, int seg, int bus, int devfn);


--=__Part0F21AC39.3__=
Content-Type: text/plain; name="pci-disallow-write.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-disallow-write.patch"

Note that due to ptwr_do_page_fault() being run first, there'll be =
a=0AMEM_LOG() issued for each such attempt. If that's undesirable, =
the=0Aorder of the calls would need to be swapped.=0A=0A--- a/xen/arch/x86/=
mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -1875,6 +1875,7 @@ static int =
mod_l1_entry(l1_pgentry_t *pl=0A             break;=0A         case 1:=0A  =
           l1e_remove_flags(nl1e, _PAGE_RW);=0A+            rc =3D 0;=0A   =
          break;=0A         }=0A         if ( page )=0A@@ -5208,6 +5209,97 =
@@ int ptwr_do_page_fault(struct vcpu *v, u=0A     return 0;=0A }=0A =
=0A+#ifdef __x86_64__=0A+/*************************=0A+ * fault handling =
for read-only MMIO pages=0A+ */=0A+=0A+struct mmio_ro_emulate_ctxt {=0A+   =
 struct x86_emulate_ctxt ctxt;=0A+    unsigned long cr2;=0A+};=0A+=0A+stati=
c int mmio_ro_emulated_read(=0A+    enum x86_segment seg,=0A+    unsigned =
long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+    struct =
x86_emulate_ctxt *ctxt)=0A+{=0A+    return X86EMUL_UNHANDLEABLE;=0A+}=0A+=
=0A+static int mmio_ro_emulated_write(=0A+    enum x86_segment seg,=0A+    =
unsigned long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+  =
  struct x86_emulate_ctxt *ctxt)=0A+{=0A+    struct mmio_ro_emulate_ctxt =
*mmio_ro_ctxt =3D=0A+        container_of(ctxt, struct mmio_ro_emulate_ctxt=
, ctxt);=0A+=0A+    /* Only allow naturally-aligned stores at the original =
%cr2 address. */=0A+    if ( ((bytes | offset) & (bytes - 1)) || offset =
!=3D mmio_ro_ctxt->cr2 )=0A+    {=0A+        MEM_LOG("mmio_ro_emulate: bad =
access (cr2=3D%lx, addr=3D%lx, bytes=3D%u)",=0A+                mmio_ro_ctx=
t->cr2, offset, bytes);=0A+        return X86EMUL_UNHANDLEABLE;=0A+    =
}=0A+=0A+    return X86EMUL_OKAY;=0A+}=0A+=0A+static const struct =
x86_emulate_ops mmio_ro_emulate_ops =3D {=0A+    .read       =3D mmio_ro_em=
ulated_read,=0A+    .insn_fetch =3D ptwr_emulated_read,=0A+    .write      =
=3D mmio_ro_emulated_write,=0A+};=0A+=0A+/* Check if guest is trying to =
modify a r/o MMIO page. */=0A+int mmio_ro_do_page_fault(struct vcpu *v, =
unsigned long addr,=0A+                          struct cpu_user_regs =
*regs)=0A+{=0A+    l1_pgentry_t      pte;=0A+    unsigned long     =
mfn;=0A+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) =
?=0A+                                  32 : BITS_PER_LONG;=0A+    struct =
mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {=0A+        .ctxt.regs =3D =
regs,=0A+        .ctxt.addr_size =3D addr_size,=0A+        .ctxt.sp_size =
=3D addr_size,=0A+        .cr2 =3D addr=0A+    };=0A+    int rc;=0A+=0A+   =
 /* Attempt to read the PTE that maps the VA being accessed. */=0A+    =
guest_get_eff_l1e(v, addr, &pte);=0A+=0A+    /* We are looking only for =
read-only mappings of MMIO pages. */=0A+    if ( ((l1e_get_flags(pte) & =
(_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESENT) )=0A+        return =
0;=0A+=0A+    mfn =3D l1e_get_pfn(pte);=0A+    if ( mfn_valid(mfn) )=0A+   =
 {=0A+        struct page_info *page =3D mfn_to_page(mfn);=0A+        =
struct domain *owner =3D page_get_owner_and_reference(page);=0A+=0A+       =
 if ( owner )=0A+            put_page(page);=0A+        if ( owner !=3D =
dom_io )=0A+            return 0;=0A+    }=0A+=0A+    if ( !rangeset_contai=
ns_singleton(mmio_ro_ranges, mfn) )=0A+        return 0;=0A+=0A+    rc =3D =
x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);=0A+=0A+    return =
rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;=0A+}=0A+#endif /* =
__x86_64__ */=0A+=0A void free_xen_pagetable(void *v)=0A {=0A     if ( =
system_state =3D=3D SYS_STATE_early_boot )=0A--- a/xen/arch/x86/traps.c=0A+=
++ b/xen/arch/x86/traps.c=0A@@ -1349,20 +1349,23 @@ static int fixup_page_f=
ault(unsigned lon=0A         return 0;=0A     }=0A =0A-    if ( VM_ASSIST(d=
, VMASST_TYPE_writable_pagetables) &&=0A-         guest_kernel_mode(v, =
regs) )=0A-    {=0A-        unsigned int mbs =3D PFEC_write_access;=0A-    =
    unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;=0A-=0A-      =
  /* Do not check if access-protection fault since the page may =0A-       =
    legitimately be not present in shadow page tables */=0A-        if ( =
!paging_mode_enabled(d) )=0A-            mbs |=3D PFEC_page_present;=0A-=0A=
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&=0A+    if ( =
guest_kernel_mode(v, regs) &&=0A+         !(regs->error_code & (PFEC_reserv=
ed_bit | PFEC_insn_fetch)) &&=0A+         (regs->error_code & PFEC_write_ac=
cess) )=0A+    {=0A+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetabl=
es) &&=0A+             /* Do not check if access-protection fault since =
the page may=0A+                legitimately be not present in shadow page =
tables */=0A+             (paging_mode_enabled(d) ||=0A+              =
(regs->error_code & PFEC_page_present)) &&=0A              ptwr_do_page_fau=
lt(v, addr, regs) )=0A             return EXCRET_fault_fixed;=0A+=0A+#ifdef=
 __x86_64__=0A+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_pre=
sent) &&=0A+             mmio_ro_do_page_fault(v, addr, regs) )=0A+        =
    return EXCRET_fault_fixed;=0A+#endif=0A     }=0A =0A     /* For =
non-external shadowed guests, we fix up both their own =0A@@ -1690,6 =
+1693,13 @@ static int pci_cfg_ok(struct domain *d, =0A         return =
0;=0A =0A     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;=0A+    if ( =
write )=0A+    {=0A+        const unsigned long *ro_map =3D pci_get_ro_map(=
0);=0A+=0A+        if ( ro_map && test_bit(machine_bdf, ro_map) )=0A+      =
      return 0;=0A+    }=0A     start =3D d->arch.pci_cf8 & 0xFF;=0A     =
end =3D start + size - 1;=0A     if (xsm_pci_config_permission(d, =
machine_bdf, start, end, write))=0A--- a/xen/arch/x86/x86_32/pci.c=0A+++ =
b/xen/arch/x86/x86_32/pci.c=0A@@ -6,6 +6,7 @@=0A =0A #include <xen/spinlock=
.h>=0A #include <xen/pci.h>=0A+#include <xen/init.h>=0A #include <asm/io.h>=
=0A =0A #define PCI_CONF_ADDRESS(bus, dev, func, reg) \=0A@@ -70,3 +71,7 =
@@ void pci_conf_write32(=0A     BUG_ON((bus > 255) || (dev > 31) || (func =
> 7) || (reg > 255));=0A     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, =
func, reg), 0, 4, data);=0A }=0A+=0A+void __init arch_pci_ro_device(int =
seg, int bdf)=0A+{=0A+}=0A--- a/xen/arch/x86/x86_64/mmconfig_64.c=0A+++ =
b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ -145,9 +145,30 @@ static void =
__iomem *mcfg_ioremap(const =0A     return (void __iomem *) virt;=0A }=0A =
=0A+void arch_pci_ro_device(int seg, int bdf)=0A+{=0A+    unsigned int =
idx, bus =3D PCI_BUS(bdf);=0A+=0A+    for (idx =3D 0; idx < pci_mmcfg_confi=
g_num; ++idx) {=0A+        const struct acpi_mcfg_allocation *cfg =3D =
pci_mmcfg_virt[idx].cfg;=0A+        unsigned long mfn =3D (cfg->address >> =
PAGE_SHIFT) + bdf;=0A+=0A+        if (!pci_mmcfg_virt[idx].virt || =
cfg->pci_segment !=3D seg ||=0A+            cfg->start_bus_number > bus || =
cfg->end_bus_number < bus)=0A+            continue;=0A+=0A+        if =
(rangeset_add_singleton(mmio_ro_ranges, mfn))=0A+            printk(XENLOG_=
ERR=0A+                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn =
%#lx) read-only\n",=0A+                   cfg->pci_segment, bus, PCI_SLOT(b=
df), PCI_FUNC(bdf),=0A+                   mfn);=0A+    }=0A+}=0A+=0A int =
pci_mmcfg_arch_enable(unsigned int idx)=0A {=0A     const typeof(pci_mmcfg_=
config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg;=0A+    const unsigned long =
*ro_map =3D pci_get_ro_map(cfg->pci_segment);=0A =0A     if (pci_mmcfg_virt=
[idx].virt)=0A         return 0;=0A@@ -159,6 +180,16 @@ int pci_mmcfg_arch_=
enable(unsigned int i=0A     }=0A     printk(KERN_INFO "PCI: Using MCFG =
for segment %04x bus %02x-%02x\n",=0A            cfg->pci_segment, =
cfg->start_bus_number, cfg->end_bus_number);=0A+    if (ro_map) {=0A+      =
  unsigned int bdf =3D PCI_BDF(cfg->start_bus_number, 0, 0);=0A+        =
unsigned int end =3D PCI_BDF(cfg->end_bus_number, -1, -1);=0A+=0A+        =
while ((bdf =3D find_next_bit(ro_map, end + 1, bdf)) <=3D end) {=0A+       =
     arch_pci_ro_device(cfg->pci_segment, bdf);=0A+            if (bdf++ =
=3D=3D end)=0A+                break;=0A+        }=0A+    }=0A     return =
0;=0A }=0A =0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_detect.c=0A@@ -153,6 +153,12 @@ int =
__init amd_iommu_detect_one_acpi(=0A     if ( rt )=0A         return =
-ENODEV;=0A =0A+    rt =3D pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, =
func));=0A+    if ( rt )=0A+        printk(XENLOG_ERR=0A+               =
"Could not mark config space of %04x:%02x:%02x.%u read-only (%d)\n",=0A+   =
            iommu->seg, bus, dev, func, rt);=0A+=0A     list_add_tail(&iomm=
u->list, &amd_iommu_head);=0A =0A     return 0;=0A--- a/xen/drivers/passthr=
ough/io.c=0A+++ b/xen/drivers/passthrough/io.c=0A@@ -593,11 +593,3 @@ void =
hvm_dpci_eoi(struct domain *d, unsi=0A unlock:=0A     spin_unlock(&d->event=
_lock);=0A }=0A-=0A-static int __init setup_mmio_ro_ranges(void)=0A-{=0A-  =
  mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",=0A-             =
                     RANGESETF_prettyprint_hex);=0A-    return 0;=0A-}=0A-_=
_initcall(setup_mmio_ro_ranges);=0A--- a/xen/drivers/passthrough/pci.c=0A++=
+ b/xen/drivers/passthrough/pci.c=0A@@ -36,6 +36,7 @@=0A struct pci_seg =
{=0A     struct list_head alldevs_list;=0A     u16 nr;=0A+    unsigned =
long *ro_map;=0A     /* bus2bridge_lock protects bus2bridge array */=0A    =
 spinlock_t bus2bridge_lock;=0A #define MAX_BUSES 256=0A@@ -106,6 +107,8 =
@@ void __init pt_pci_init(void)=0A     radix_tree_init(&pci_segments);=0A =
    if ( !alloc_pseg(0) )=0A         panic("Could not initialize PCI =
segment 0\n");=0A+    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio =
ranges",=0A+                                  RANGESETF_prettyprint_hex);=
=0A }=0A =0A int __init pci_add_segment(u16 seg)=0A@@ -113,6 +116,13 @@ =
int __init pci_add_segment(u16 seg)=0A     return alloc_pseg(seg) ? 0 : =
-ENOMEM;=0A }=0A =0A+const unsigned long *pci_get_ro_map(u16 seg)=0A+{=0A+ =
   struct pci_seg *pseg =3D get_pseg(seg);=0A+=0A+    return pseg ? =
pseg->ro_map : NULL;=0A+}=0A+=0A static struct pci_dev *alloc_pdev(struct =
pci_seg *pseg, u8 bus, u8 devfn)=0A {=0A     struct pci_dev *pdev;=0A@@ =
-198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps=0A     =
xfree(pdev);=0A }=0A =0A+int __init pci_ro_device(int seg, int bus, int =
devfn)=0A+{=0A+    struct pci_seg *pseg =3D alloc_pseg(seg);=0A+    struct =
pci_dev *pdev;=0A+=0A+    if ( !pseg )=0A+        return -ENOMEM;=0A+    =
pdev =3D alloc_pdev(pseg, bus, devfn);=0A+    if ( !pdev )=0A+        =
return -ENOMEM;=0A+=0A+    if ( !pseg->ro_map )=0A+    {=0A+        size_t =
sz =3D BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);=0A+=0A+      =
  pseg->ro_map =3D alloc_xenheap_pages(get_order_from_bytes(sz), 0);=0A+   =
     if ( !pseg->ro_map )=0A+            return -ENOMEM;=0A+        =
memset(pseg->ro_map, 0, sz);=0A+    }=0A+=0A+    __set_bit(PCI_BDF2(bus, =
devfn), pseg->ro_map);=0A+    arch_pci_ro_device(seg, PCI_BDF2(bus, =
devfn));=0A+=0A+    return 0;=0A+}=0A+=0A struct pci_dev *pci_get_pdev(int =
seg, int bus, int devfn)=0A {=0A     struct pci_seg *pseg =3D get_pseg(seg)=
;=0A--- a/xen/include/asm-x86/mm.h=0A+++ b/xen/include/asm-x86/mm.h=0A@@ =
-555,6 +555,8 @@ void memguard_unguard_stack(void *p);=0A =0A int  =
ptwr_do_page_fault(struct vcpu *, unsigned long,=0A                        =
 struct cpu_user_regs *);=0A+int  mmio_ro_do_page_fault(struct vcpu *, =
unsigned long,=0A+                           struct cpu_user_regs *);=0A =
=0A int audit_adjust_pgtables(struct domain *d, int dir, int noisy);=0A =
=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -98,8 =
+98,11 @@ struct pci_dev *pci_lock_domain_pdev(=0A void setup_dom0_pci_devi=
ces(struct domain *, void (*)(struct pci_dev *));=0A void pci_release_devic=
es(struct domain *d);=0A int pci_add_segment(u16 seg);=0A+const unsigned =
long *pci_get_ro_map(u16 seg);=0A int pci_add_device(u16 seg, u8 bus, u8 =
devfn, const struct pci_dev_info *);=0A int pci_remove_device(u16 seg, u8 =
bus, u8 devfn);=0A+int pci_ro_device(int seg, int bus, int devfn);=0A+void =
arch_pci_ro_device(int seg, int bdf);=0A struct pci_dev *pci_get_pdev(int =
seg, int bus, int devfn);=0A struct pci_dev *pci_get_pdev_by_domain(=0A    =
 struct domain *, int seg, int bus, int devfn);=0A
--=__Part0F21AC39.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part0F21AC39.3__=--


From xen-devel-bounces@lists.xen.org Wed Jun 20 15:45:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:45: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 1ShN5d-0007Xt-W1; Wed, 20 Jun 2012 15:45: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 1ShN5c-0007Xn-Q1
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 15:45:05 +0000
Received: from [193.109.254.147:65430] by server-1.bemta-14.messagelabs.com id
	73/AD-24612-000F1EF4; Wed, 20 Jun 2012 15:45:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340207103!3567881!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15507 invoked from network); 20 Jun 2012 15:45:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 15:45:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 16:45:02 +0100
Message-Id: <4FE20C49020000780008AE25@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 16:45:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
In-Reply-To: <4FD9D559.9050206@amd.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0F21AC39.3__="
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled 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.

--=__Part0F21AC39.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 14.06.12 at 14:13, Wei Wang <wei.wang2@amd.com> wrote:
> Am 12.06.2012 18:43, schrieb Jan Beulich:
>>>>> On 12.06.12 at 18:08, Andrew Cooper<andrew.cooper3@citrix.com>  =
wrote:
>>> On 12/06/12 16:13, Jan Beulich wrote:
>>>>>>> On 12.06.12 at 14:02, Wei Wang<wei.wang2@amd.com>  wrote:
>>>>> I had attached a revised patch, please check it.
>>>> While the patch technically looks better now, you didn't eliminate
>>>> my objections to the approach you take, nor did you comment on
>>>> the proposed alternative.
>>>>
>>>> A fundamental problem is that your IOMMUs show up as a "normal"
>>>> PCI devices, breaking the separation between what is being
>>>> managed by the hypervisor vs by the Dom0 kernel. (This even
>>>> allows something as odd as passing through an IOMMU to a
>>>> DomU, which would clearly upset the hypervisor.)
>>>>
>>>>> I found that the following Linux commit triggers this issue. It has =
been
>>>>> included into 3.4 pv_ops.
>>>>>
>>>>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>>>>     Author: Eric W. Biederman<ebiederm@xmission.com>
>>>>>     Date:   Mon Oct 17 11:46:06 2011 -0700
>>>>>
>>>>>     PCI: msi: Disable msi interrupts when we initialize a pci device =
"
>>>> Thanks for locating this. As it stands, it is incomplete though
>>>> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
>>>> it won't have a means to suppress the "screaming" interrupts.
>>>
>>> I feel that the correct solution would be for Xen to hide the PCI
>>> devices from dom0.  Xen already hides the DMAR ACPI table (by turning =
it
>>> to an XMAR table), and this would be the logical way to proceed now =
that
>>> IOMMU internals are appearing as PCI devices.
>=20
> That sounds absolutely good to me. thanks for the suggestion.
>=20
>> That is precisely what I suggested in my response to the first
>> version of this patch, and I'd also volunteer to look into putting
>> together a first draft implementation if we sort of agree that
>> this is the way to go.
>=20
> Cool! thanks for doing that. Looking forward to it in Xen 4.2 since=20
> iommu msi is really broken with recent Linux dom0...

Rather than submitting it for inclusion immediately, I'd rather see
you first use it successfully. Below/attached what appears to
work fine for me in contrived situations (i.e. hiding bridges with
nothing connected, as I still don't have any AMD IOMMU system
at hand).

Jan

Note that due to ptwr_do_page_fault() being run first, there'll be a
MEM_LOG() issued for each such attempt. If that's undesirable, the
order of the calls would need to be swapped.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
             break;
         case 1:
             l1e_remove_flags(nl1e, _PAGE_RW);
+            rc =3D 0;
             break;
         }
         if ( page )
@@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
     return 0;
 }
=20
+#ifdef __x86_64__
+/*************************
+ * fault handling for read-only MMIO pages
+ */
+
+struct mmio_ro_emulate_ctxt {
+    struct x86_emulate_ctxt ctxt;
+    unsigned long cr2;
+};
+
+static int mmio_ro_emulated_read(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    return X86EMUL_UNHANDLEABLE;
+}
+
+static int mmio_ro_emulated_write(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =3D
+        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
+
+    /* Only allow naturally-aligned stores at the original %cr2 address. =
*/
+    if ( ((bytes | offset) & (bytes - 1)) || offset !=3D mmio_ro_ctxt->cr2=
 )
+    {
+        MEM_LOG("mmio_ro_emulate: bad access (cr2=3D%lx, addr=3D%lx, =
bytes=3D%u)",
+                mmio_ro_ctxt->cr2, offset, bytes);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    return X86EMUL_OKAY;
+}
+
+static const struct x86_emulate_ops mmio_ro_emulate_ops =3D {
+    .read       =3D mmio_ro_emulated_read,
+    .insn_fetch =3D ptwr_emulated_read,
+    .write      =3D mmio_ro_emulated_write,
+};
+
+/* Check if guest is trying to modify a r/o MMIO page. */
+int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
+                          struct cpu_user_regs *regs)
+{
+    l1_pgentry_t      pte;
+    unsigned long     mfn;
+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) ?
+                                  32 : BITS_PER_LONG;
+    struct mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {
+        .ctxt.regs =3D regs,
+        .ctxt.addr_size =3D addr_size,
+        .ctxt.sp_size =3D addr_size,
+        .cr2 =3D addr
+    };
+    int rc;
+
+    /* Attempt to read the PTE that maps the VA being accessed. */
+    guest_get_eff_l1e(v, addr, &pte);
+
+    /* We are looking only for read-only mappings of MMIO pages. */
+    if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESE=
NT) )
+        return 0;
+
+    mfn =3D l1e_get_pfn(pte);
+    if ( mfn_valid(mfn) )
+    {
+        struct page_info *page =3D mfn_to_page(mfn);
+        struct domain *owner =3D page_get_owner_and_reference(page);
+
+        if ( owner )
+            put_page(page);
+        if ( owner !=3D dom_io )
+            return 0;
+    }
+
+    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
+        return 0;
+
+    rc =3D x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);
+
+    return rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
+}
+#endif /* __x86_64__ */
+
 void free_xen_pagetable(void *v)
 {
     if ( system_state =3D=3D SYS_STATE_early_boot )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
         return 0;
     }
=20
-    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
-         guest_kernel_mode(v, regs) )
-    {
-        unsigned int mbs =3D PFEC_write_access;
-        unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;
-
-        /* Do not check if access-protection fault since the page may=20
-           legitimately be not present in shadow page tables */
-        if ( !paging_mode_enabled(d) )
-            mbs |=3D PFEC_page_present;
-
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&
+    if ( guest_kernel_mode(v, regs) &&
+         !(regs->error_code & (PFEC_reserved_bit | PFEC_insn_fetch)) &&
+         (regs->error_code & PFEC_write_access) )
+    {
+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
+             /* Do not check if access-protection fault since the page =
may
+                legitimately be not present in shadow page tables */
+             (paging_mode_enabled(d) ||
+              (regs->error_code & PFEC_page_present)) &&
              ptwr_do_page_fault(v, addr, regs) )
             return EXCRET_fault_fixed;
+
+#ifdef __x86_64__
+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_present) &&
+             mmio_ro_do_page_fault(v, addr, regs) )
+            return EXCRET_fault_fixed;
+#endif
     }
=20
     /* For non-external shadowed guests, we fix up both their own=20
@@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,=20
         return 0;
=20
     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;
+    if ( write )
+    {
+        const unsigned long *ro_map =3D pci_get_ro_map(0);
+
+        if ( ro_map && test_bit(machine_bdf, ro_map) )
+            return 0;
+    }
     start =3D d->arch.pci_cf8 & 0xFF;
     end =3D start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
--- a/xen/arch/x86/x86_32/pci.c
+++ b/xen/arch/x86/x86_32/pci.c
@@ -6,6 +6,7 @@
=20
 #include <xen/spinlock.h>
 #include <xen/pci.h>
+#include <xen/init.h>
 #include <asm/io.h>
=20
 #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
@@ -70,3 +71,7 @@ void pci_conf_write32(
     BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
 }
+
+void __init arch_pci_ro_device(int seg, int bdf)
+{
+}
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const=20
     return (void __iomem *) virt;
 }
=20
+void arch_pci_ro_device(int seg, int bdf)
+{
+    unsigned int idx, bus =3D PCI_BUS(bdf);
+
+    for (idx =3D 0; idx < pci_mmcfg_config_num; ++idx) {
+        const struct acpi_mcfg_allocation *cfg =3D pci_mmcfg_virt[idx].cfg=
;
+        unsigned long mfn =3D (cfg->address >> PAGE_SHIFT) + bdf;
+
+        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment !=3D seg ||
+            cfg->start_bus_number > bus || cfg->end_bus_number < bus)
+            continue;
+
+        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
+            printk(XENLOG_ERR
+                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) =
read-only\n",
+                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
+                   mfn);
+    }
+}
+
 int pci_mmcfg_arch_enable(unsigned int idx)
 {
     const typeof(pci_mmcfg_config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg;
+    const unsigned long *ro_map =3D pci_get_ro_map(cfg->pci_segment);
=20
     if (pci_mmcfg_virt[idx].virt)
         return 0;
@@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
     }
     printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
            cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
+    if (ro_map) {
+        unsigned int bdf =3D PCI_BDF(cfg->start_bus_number, 0, 0);
+        unsigned int end =3D PCI_BDF(cfg->end_bus_number, -1, -1);
+
+        while ((bdf =3D find_next_bit(ro_map, end + 1, bdf)) <=3D end) {
+            arch_pci_ro_device(cfg->pci_segment, bdf);
+            if (bdf++ =3D=3D end)
+                break;
+        }
+    }
     return 0;
 }
=20
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
     if ( rt )
         return -ENODEV;
=20
+    rt =3D pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
+    if ( rt )
+        printk(XENLOG_ERR
+               "Could not mark config space of %04x:%02x:%02x.%u =
read-only (%d)\n",
+               iommu->seg, bus, dev, func, rt);
+
     list_add_tail(&iommu->list, &amd_iommu_head);
=20
     return 0;
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
 unlock:
     spin_unlock(&d->event_lock);
 }
-
-static int __init setup_mmio_ro_ranges(void)
-{
-    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
-                                  RANGESETF_prettyprint_hex);
-    return 0;
-}
-__initcall(setup_mmio_ro_ranges);
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -36,6 +36,7 @@
 struct pci_seg {
     struct list_head alldevs_list;
     u16 nr;
+    unsigned long *ro_map;
     /* bus2bridge_lock protects bus2bridge array */
     spinlock_t bus2bridge_lock;
 #define MAX_BUSES 256
@@ -106,6 +107,8 @@ void __init pt_pci_init(void)
     radix_tree_init(&pci_segments);
     if ( !alloc_pseg(0) )
         panic("Could not initialize PCI segment 0\n");
+    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
+                                  RANGESETF_prettyprint_hex);
 }
=20
 int __init pci_add_segment(u16 seg)
@@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
     return alloc_pseg(seg) ? 0 : -ENOMEM;
 }
=20
+const unsigned long *pci_get_ro_map(u16 seg)
+{
+    struct pci_seg *pseg =3D get_pseg(seg);
+
+    return pseg ? pseg->ro_map : NULL;
+}
+
 static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
 {
     struct pci_dev *pdev;
@@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
     xfree(pdev);
 }
=20
+int __init pci_ro_device(int seg, int bus, int devfn)
+{
+    struct pci_seg *pseg =3D alloc_pseg(seg);
+    struct pci_dev *pdev;
+
+    if ( !pseg )
+        return -ENOMEM;
+    pdev =3D alloc_pdev(pseg, bus, devfn);
+    if ( !pdev )
+        return -ENOMEM;
+
+    if ( !pseg->ro_map )
+    {
+        size_t sz =3D BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long=
);
+
+        pseg->ro_map =3D alloc_xenheap_pages(get_order_from_bytes(sz), =
0);
+        if ( !pseg->ro_map )
+            return -ENOMEM;
+        memset(pseg->ro_map, 0, sz);
+    }
+
+    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
+    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
+
+    return 0;
+}
+
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
 {
     struct pci_seg *pseg =3D get_pseg(seg);
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
=20
 int  ptwr_do_page_fault(struct vcpu *, unsigned long,
                         struct cpu_user_regs *);
+int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
+                           struct cpu_user_regs *);
=20
 int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
=20
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
 void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
 void pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
+const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info =
*);
 int pci_remove_device(u16 seg, u8 bus, u8 devfn);
+int pci_ro_device(int seg, int bus, int devfn);
+void arch_pci_ro_device(int seg, int bdf);
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
 struct pci_dev *pci_get_pdev_by_domain(
     struct domain *, int seg, int bus, int devfn);


--=__Part0F21AC39.3__=
Content-Type: text/plain; name="pci-disallow-write.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-disallow-write.patch"

Note that due to ptwr_do_page_fault() being run first, there'll be =
a=0AMEM_LOG() issued for each such attempt. If that's undesirable, =
the=0Aorder of the calls would need to be swapped.=0A=0A--- a/xen/arch/x86/=
mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -1875,6 +1875,7 @@ static int =
mod_l1_entry(l1_pgentry_t *pl=0A             break;=0A         case 1:=0A  =
           l1e_remove_flags(nl1e, _PAGE_RW);=0A+            rc =3D 0;=0A   =
          break;=0A         }=0A         if ( page )=0A@@ -5208,6 +5209,97 =
@@ int ptwr_do_page_fault(struct vcpu *v, u=0A     return 0;=0A }=0A =
=0A+#ifdef __x86_64__=0A+/*************************=0A+ * fault handling =
for read-only MMIO pages=0A+ */=0A+=0A+struct mmio_ro_emulate_ctxt {=0A+   =
 struct x86_emulate_ctxt ctxt;=0A+    unsigned long cr2;=0A+};=0A+=0A+stati=
c int mmio_ro_emulated_read(=0A+    enum x86_segment seg,=0A+    unsigned =
long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+    struct =
x86_emulate_ctxt *ctxt)=0A+{=0A+    return X86EMUL_UNHANDLEABLE;=0A+}=0A+=
=0A+static int mmio_ro_emulated_write(=0A+    enum x86_segment seg,=0A+    =
unsigned long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+  =
  struct x86_emulate_ctxt *ctxt)=0A+{=0A+    struct mmio_ro_emulate_ctxt =
*mmio_ro_ctxt =3D=0A+        container_of(ctxt, struct mmio_ro_emulate_ctxt=
, ctxt);=0A+=0A+    /* Only allow naturally-aligned stores at the original =
%cr2 address. */=0A+    if ( ((bytes | offset) & (bytes - 1)) || offset =
!=3D mmio_ro_ctxt->cr2 )=0A+    {=0A+        MEM_LOG("mmio_ro_emulate: bad =
access (cr2=3D%lx, addr=3D%lx, bytes=3D%u)",=0A+                mmio_ro_ctx=
t->cr2, offset, bytes);=0A+        return X86EMUL_UNHANDLEABLE;=0A+    =
}=0A+=0A+    return X86EMUL_OKAY;=0A+}=0A+=0A+static const struct =
x86_emulate_ops mmio_ro_emulate_ops =3D {=0A+    .read       =3D mmio_ro_em=
ulated_read,=0A+    .insn_fetch =3D ptwr_emulated_read,=0A+    .write      =
=3D mmio_ro_emulated_write,=0A+};=0A+=0A+/* Check if guest is trying to =
modify a r/o MMIO page. */=0A+int mmio_ro_do_page_fault(struct vcpu *v, =
unsigned long addr,=0A+                          struct cpu_user_regs =
*regs)=0A+{=0A+    l1_pgentry_t      pte;=0A+    unsigned long     =
mfn;=0A+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) =
?=0A+                                  32 : BITS_PER_LONG;=0A+    struct =
mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {=0A+        .ctxt.regs =3D =
regs,=0A+        .ctxt.addr_size =3D addr_size,=0A+        .ctxt.sp_size =
=3D addr_size,=0A+        .cr2 =3D addr=0A+    };=0A+    int rc;=0A+=0A+   =
 /* Attempt to read the PTE that maps the VA being accessed. */=0A+    =
guest_get_eff_l1e(v, addr, &pte);=0A+=0A+    /* We are looking only for =
read-only mappings of MMIO pages. */=0A+    if ( ((l1e_get_flags(pte) & =
(_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESENT) )=0A+        return =
0;=0A+=0A+    mfn =3D l1e_get_pfn(pte);=0A+    if ( mfn_valid(mfn) )=0A+   =
 {=0A+        struct page_info *page =3D mfn_to_page(mfn);=0A+        =
struct domain *owner =3D page_get_owner_and_reference(page);=0A+=0A+       =
 if ( owner )=0A+            put_page(page);=0A+        if ( owner !=3D =
dom_io )=0A+            return 0;=0A+    }=0A+=0A+    if ( !rangeset_contai=
ns_singleton(mmio_ro_ranges, mfn) )=0A+        return 0;=0A+=0A+    rc =3D =
x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);=0A+=0A+    return =
rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;=0A+}=0A+#endif /* =
__x86_64__ */=0A+=0A void free_xen_pagetable(void *v)=0A {=0A     if ( =
system_state =3D=3D SYS_STATE_early_boot )=0A--- a/xen/arch/x86/traps.c=0A+=
++ b/xen/arch/x86/traps.c=0A@@ -1349,20 +1349,23 @@ static int fixup_page_f=
ault(unsigned lon=0A         return 0;=0A     }=0A =0A-    if ( VM_ASSIST(d=
, VMASST_TYPE_writable_pagetables) &&=0A-         guest_kernel_mode(v, =
regs) )=0A-    {=0A-        unsigned int mbs =3D PFEC_write_access;=0A-    =
    unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;=0A-=0A-      =
  /* Do not check if access-protection fault since the page may =0A-       =
    legitimately be not present in shadow page tables */=0A-        if ( =
!paging_mode_enabled(d) )=0A-            mbs |=3D PFEC_page_present;=0A-=0A=
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&=0A+    if ( =
guest_kernel_mode(v, regs) &&=0A+         !(regs->error_code & (PFEC_reserv=
ed_bit | PFEC_insn_fetch)) &&=0A+         (regs->error_code & PFEC_write_ac=
cess) )=0A+    {=0A+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetabl=
es) &&=0A+             /* Do not check if access-protection fault since =
the page may=0A+                legitimately be not present in shadow page =
tables */=0A+             (paging_mode_enabled(d) ||=0A+              =
(regs->error_code & PFEC_page_present)) &&=0A              ptwr_do_page_fau=
lt(v, addr, regs) )=0A             return EXCRET_fault_fixed;=0A+=0A+#ifdef=
 __x86_64__=0A+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_pre=
sent) &&=0A+             mmio_ro_do_page_fault(v, addr, regs) )=0A+        =
    return EXCRET_fault_fixed;=0A+#endif=0A     }=0A =0A     /* For =
non-external shadowed guests, we fix up both their own =0A@@ -1690,6 =
+1693,13 @@ static int pci_cfg_ok(struct domain *d, =0A         return =
0;=0A =0A     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;=0A+    if ( =
write )=0A+    {=0A+        const unsigned long *ro_map =3D pci_get_ro_map(=
0);=0A+=0A+        if ( ro_map && test_bit(machine_bdf, ro_map) )=0A+      =
      return 0;=0A+    }=0A     start =3D d->arch.pci_cf8 & 0xFF;=0A     =
end =3D start + size - 1;=0A     if (xsm_pci_config_permission(d, =
machine_bdf, start, end, write))=0A--- a/xen/arch/x86/x86_32/pci.c=0A+++ =
b/xen/arch/x86/x86_32/pci.c=0A@@ -6,6 +6,7 @@=0A =0A #include <xen/spinlock=
.h>=0A #include <xen/pci.h>=0A+#include <xen/init.h>=0A #include <asm/io.h>=
=0A =0A #define PCI_CONF_ADDRESS(bus, dev, func, reg) \=0A@@ -70,3 +71,7 =
@@ void pci_conf_write32(=0A     BUG_ON((bus > 255) || (dev > 31) || (func =
> 7) || (reg > 255));=0A     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, =
func, reg), 0, 4, data);=0A }=0A+=0A+void __init arch_pci_ro_device(int =
seg, int bdf)=0A+{=0A+}=0A--- a/xen/arch/x86/x86_64/mmconfig_64.c=0A+++ =
b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ -145,9 +145,30 @@ static void =
__iomem *mcfg_ioremap(const =0A     return (void __iomem *) virt;=0A }=0A =
=0A+void arch_pci_ro_device(int seg, int bdf)=0A+{=0A+    unsigned int =
idx, bus =3D PCI_BUS(bdf);=0A+=0A+    for (idx =3D 0; idx < pci_mmcfg_confi=
g_num; ++idx) {=0A+        const struct acpi_mcfg_allocation *cfg =3D =
pci_mmcfg_virt[idx].cfg;=0A+        unsigned long mfn =3D (cfg->address >> =
PAGE_SHIFT) + bdf;=0A+=0A+        if (!pci_mmcfg_virt[idx].virt || =
cfg->pci_segment !=3D seg ||=0A+            cfg->start_bus_number > bus || =
cfg->end_bus_number < bus)=0A+            continue;=0A+=0A+        if =
(rangeset_add_singleton(mmio_ro_ranges, mfn))=0A+            printk(XENLOG_=
ERR=0A+                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn =
%#lx) read-only\n",=0A+                   cfg->pci_segment, bus, PCI_SLOT(b=
df), PCI_FUNC(bdf),=0A+                   mfn);=0A+    }=0A+}=0A+=0A int =
pci_mmcfg_arch_enable(unsigned int idx)=0A {=0A     const typeof(pci_mmcfg_=
config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg;=0A+    const unsigned long =
*ro_map =3D pci_get_ro_map(cfg->pci_segment);=0A =0A     if (pci_mmcfg_virt=
[idx].virt)=0A         return 0;=0A@@ -159,6 +180,16 @@ int pci_mmcfg_arch_=
enable(unsigned int i=0A     }=0A     printk(KERN_INFO "PCI: Using MCFG =
for segment %04x bus %02x-%02x\n",=0A            cfg->pci_segment, =
cfg->start_bus_number, cfg->end_bus_number);=0A+    if (ro_map) {=0A+      =
  unsigned int bdf =3D PCI_BDF(cfg->start_bus_number, 0, 0);=0A+        =
unsigned int end =3D PCI_BDF(cfg->end_bus_number, -1, -1);=0A+=0A+        =
while ((bdf =3D find_next_bit(ro_map, end + 1, bdf)) <=3D end) {=0A+       =
     arch_pci_ro_device(cfg->pci_segment, bdf);=0A+            if (bdf++ =
=3D=3D end)=0A+                break;=0A+        }=0A+    }=0A     return =
0;=0A }=0A =0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_detect.c=0A@@ -153,6 +153,12 @@ int =
__init amd_iommu_detect_one_acpi(=0A     if ( rt )=0A         return =
-ENODEV;=0A =0A+    rt =3D pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, =
func));=0A+    if ( rt )=0A+        printk(XENLOG_ERR=0A+               =
"Could not mark config space of %04x:%02x:%02x.%u read-only (%d)\n",=0A+   =
            iommu->seg, bus, dev, func, rt);=0A+=0A     list_add_tail(&iomm=
u->list, &amd_iommu_head);=0A =0A     return 0;=0A--- a/xen/drivers/passthr=
ough/io.c=0A+++ b/xen/drivers/passthrough/io.c=0A@@ -593,11 +593,3 @@ void =
hvm_dpci_eoi(struct domain *d, unsi=0A unlock:=0A     spin_unlock(&d->event=
_lock);=0A }=0A-=0A-static int __init setup_mmio_ro_ranges(void)=0A-{=0A-  =
  mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",=0A-             =
                     RANGESETF_prettyprint_hex);=0A-    return 0;=0A-}=0A-_=
_initcall(setup_mmio_ro_ranges);=0A--- a/xen/drivers/passthrough/pci.c=0A++=
+ b/xen/drivers/passthrough/pci.c=0A@@ -36,6 +36,7 @@=0A struct pci_seg =
{=0A     struct list_head alldevs_list;=0A     u16 nr;=0A+    unsigned =
long *ro_map;=0A     /* bus2bridge_lock protects bus2bridge array */=0A    =
 spinlock_t bus2bridge_lock;=0A #define MAX_BUSES 256=0A@@ -106,6 +107,8 =
@@ void __init pt_pci_init(void)=0A     radix_tree_init(&pci_segments);=0A =
    if ( !alloc_pseg(0) )=0A         panic("Could not initialize PCI =
segment 0\n");=0A+    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio =
ranges",=0A+                                  RANGESETF_prettyprint_hex);=
=0A }=0A =0A int __init pci_add_segment(u16 seg)=0A@@ -113,6 +116,13 @@ =
int __init pci_add_segment(u16 seg)=0A     return alloc_pseg(seg) ? 0 : =
-ENOMEM;=0A }=0A =0A+const unsigned long *pci_get_ro_map(u16 seg)=0A+{=0A+ =
   struct pci_seg *pseg =3D get_pseg(seg);=0A+=0A+    return pseg ? =
pseg->ro_map : NULL;=0A+}=0A+=0A static struct pci_dev *alloc_pdev(struct =
pci_seg *pseg, u8 bus, u8 devfn)=0A {=0A     struct pci_dev *pdev;=0A@@ =
-198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps=0A     =
xfree(pdev);=0A }=0A =0A+int __init pci_ro_device(int seg, int bus, int =
devfn)=0A+{=0A+    struct pci_seg *pseg =3D alloc_pseg(seg);=0A+    struct =
pci_dev *pdev;=0A+=0A+    if ( !pseg )=0A+        return -ENOMEM;=0A+    =
pdev =3D alloc_pdev(pseg, bus, devfn);=0A+    if ( !pdev )=0A+        =
return -ENOMEM;=0A+=0A+    if ( !pseg->ro_map )=0A+    {=0A+        size_t =
sz =3D BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);=0A+=0A+      =
  pseg->ro_map =3D alloc_xenheap_pages(get_order_from_bytes(sz), 0);=0A+   =
     if ( !pseg->ro_map )=0A+            return -ENOMEM;=0A+        =
memset(pseg->ro_map, 0, sz);=0A+    }=0A+=0A+    __set_bit(PCI_BDF2(bus, =
devfn), pseg->ro_map);=0A+    arch_pci_ro_device(seg, PCI_BDF2(bus, =
devfn));=0A+=0A+    return 0;=0A+}=0A+=0A struct pci_dev *pci_get_pdev(int =
seg, int bus, int devfn)=0A {=0A     struct pci_seg *pseg =3D get_pseg(seg)=
;=0A--- a/xen/include/asm-x86/mm.h=0A+++ b/xen/include/asm-x86/mm.h=0A@@ =
-555,6 +555,8 @@ void memguard_unguard_stack(void *p);=0A =0A int  =
ptwr_do_page_fault(struct vcpu *, unsigned long,=0A                        =
 struct cpu_user_regs *);=0A+int  mmio_ro_do_page_fault(struct vcpu *, =
unsigned long,=0A+                           struct cpu_user_regs *);=0A =
=0A int audit_adjust_pgtables(struct domain *d, int dir, int noisy);=0A =
=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -98,8 =
+98,11 @@ struct pci_dev *pci_lock_domain_pdev(=0A void setup_dom0_pci_devi=
ces(struct domain *, void (*)(struct pci_dev *));=0A void pci_release_devic=
es(struct domain *d);=0A int pci_add_segment(u16 seg);=0A+const unsigned =
long *pci_get_ro_map(u16 seg);=0A int pci_add_device(u16 seg, u8 bus, u8 =
devfn, const struct pci_dev_info *);=0A int pci_remove_device(u16 seg, u8 =
bus, u8 devfn);=0A+int pci_ro_device(int seg, int bus, int devfn);=0A+void =
arch_pci_ro_device(int seg, int bdf);=0A struct pci_dev *pci_get_pdev(int =
seg, int bus, int devfn);=0A struct pci_dev *pci_get_pdev_by_domain(=0A    =
 struct domain *, int seg, int bus, int devfn);=0A
--=__Part0F21AC39.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part0F21AC39.3__=--


From xen-devel-bounces@lists.xen.org Wed Jun 20 15:46:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:46: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 1ShN6l-0007bp-Lh; Wed, 20 Jun 2012 15:46:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShN6j-0007bf-Rh
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:46:14 +0000
Received: from [193.109.254.147:36508] by server-4.bemta-14.messagelabs.com id
	3D/7D-02077-540F1EF4; Wed, 20 Jun 2012 15:46:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340207171!10645757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10240 invoked from network); 20 Jun 2012 15:46:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:46:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:46:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShN6h-0005VX-B9; Wed, 20 Jun 2012 15:46:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShN6h-00006c-AB;
	Wed, 20 Jun 2012 16:46:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.61507.302383.517925@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:46:11 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340205929.4906.66.camel@zakaz.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
> On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
> > qemu-upstream-unstable has been updated, Ian is responsible for
> > qemu-xen-unstable.

Sorry, I had this message marked to go back to but...

> I was about to ping Ian J about this, because there seems to be breakage
> which would be fixed by this (Olaf: "grant table errors with
> qemu-xen-traditional" today) but it looks like these patches weren't
> actually submitted against the traditional tree? Or at least I can't
> find any such thing.

...indeed I wasn't sure what it was referring to.

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 Jun 20 15:46:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:46: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 1ShN6l-0007bp-Lh; Wed, 20 Jun 2012 15:46:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShN6j-0007bf-Rh
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:46:14 +0000
Received: from [193.109.254.147:36508] by server-4.bemta-14.messagelabs.com id
	3D/7D-02077-540F1EF4; Wed, 20 Jun 2012 15:46:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340207171!10645757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10240 invoked from network); 20 Jun 2012 15:46:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:46:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:46:11 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShN6h-0005VX-B9; Wed, 20 Jun 2012 15:46:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShN6h-00006c-AB;
	Wed, 20 Jun 2012 16:46:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.61507.302383.517925@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:46:11 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340205929.4906.66.camel@zakaz.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
> On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
> > qemu-upstream-unstable has been updated, Ian is responsible for
> > qemu-xen-unstable.

Sorry, I had this message marked to go back to but...

> I was about to ping Ian J about this, because there seems to be breakage
> which would be fixed by this (Olaf: "grant table errors with
> qemu-xen-traditional" today) but it looks like these patches weren't
> actually submitted against the traditional tree? Or at least I can't
> find any such thing.

...indeed I wasn't sure what it was referring to.

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 Jun 20 15:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShN7y-0007i5-4X; Wed, 20 Jun 2012 15:47:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShN7w-0007hn-Rx
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:47:28 +0000
Received: from [85.158.143.99:40061] by server-3.bemta-4.messagelabs.com id
	CA/0F-05808-090F1EF4; Wed, 20 Jun 2012 15:47:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340207245!27971900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22528 invoked from network); 20 Jun 2012 15:47:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:47:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:47:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:47:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShN7t-0005Vx-E9; Wed, 20 Jun 2012 15:47:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShN7t-00006n-DE;
	Wed, 20 Jun 2012 16:47:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.61581.396812.290324@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:47:25 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4FE20B23020000780008AE16@nat28.tlf.novell.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 TODO / Release Plan"):
> I didn't think that I needed to formally submit patches that were
> requested to be ported over to -traditional when they already
> went into upstream qemu. If I'm wrong with this, then please let
> me know and I'll submit both patches asap.

Certainly there is nothing automatic (people or computers) that fishes
changes to qemu upstream into -traditional.  If you want something
committed to qemu-xen-traditional you'll have to say so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:47:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShN7y-0007i5-4X; Wed, 20 Jun 2012 15:47:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShN7w-0007hn-Rx
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:47:28 +0000
Received: from [85.158.143.99:40061] by server-3.bemta-4.messagelabs.com id
	CA/0F-05808-090F1EF4; Wed, 20 Jun 2012 15:47:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340207245!27971900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22528 invoked from network); 20 Jun 2012 15:47:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:47:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:47:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:47:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShN7t-0005Vx-E9; Wed, 20 Jun 2012 15:47:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShN7t-00006n-DE;
	Wed, 20 Jun 2012 16:47:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.61581.396812.290324@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:47:25 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4FE20B23020000780008AE16@nat28.tlf.novell.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 TODO / Release Plan"):
> I didn't think that I needed to formally submit patches that were
> requested to be ported over to -traditional when they already
> went into upstream qemu. If I'm wrong with this, then please let
> me know and I'll submit both patches asap.

Certainly there is nothing automatic (people or computers) that fishes
changes to qemu upstream into -traditional.  If you want something
committed to qemu-xen-traditional you'll have to say so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:50:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShNAb-0007xT-MV; Wed, 20 Jun 2012 15:50:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShNAZ-0007xH-T7
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:50:12 +0000
Received: from [85.158.138.51:18003] by server-10.bemta-3.messagelabs.com id
	59/45-01753-331F1EF4; Wed, 20 Jun 2012 15:50:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340207408!28638895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17232 invoked from network); 20 Jun 2012 15:50:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:50:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 16:50:08 +0100
Message-ID: <1340207407.4906.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 16:50:07 +0100
In-Reply-To: <4FE20B23020000780008AE16@nat28.tlf.novell.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 16:40 +0100, Jan Beulich wrote:
> > That thread also references
> > <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
> > should be applied to the trad tree too. Has anyone tested that combo?
> > 
> > I can see how Ian missed this -- it very much looked like those two
> > patches were for qemu-upstream only to me (from the subject, cc line etc
> > etc).
> 
> I didn't think that I needed to formally submit patches that were
> requested to be ported over to -traditional when they already
> went into upstream qemu. If I'm wrong with this, then please let
> me know and I'll submit both patches asap.

This is really for Ian J to say but IMHO the two code bases have
diverged enough that blindly pulling from upstream -> traditional is not
a good idea, so at the least the change needs to be tested in that
context.

Even if we were happy to just pull things in then the mail needs to note
somewhere which tree(s) the patch should be applied to. 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:50:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15: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 1ShNAb-0007xT-MV; Wed, 20 Jun 2012 15:50:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShNAZ-0007xH-T7
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:50:12 +0000
Received: from [85.158.138.51:18003] by server-10.bemta-3.messagelabs.com id
	59/45-01753-331F1EF4; Wed, 20 Jun 2012 15:50:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340207408!28638895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17232 invoked from network); 20 Jun 2012 15:50:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:50:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 16:50:08 +0100
Message-ID: <1340207407.4906.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 16:50:07 +0100
In-Reply-To: <4FE20B23020000780008AE16@nat28.tlf.novell.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 16:40 +0100, Jan Beulich wrote:
> > That thread also references
> > <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which
> > should be applied to the trad tree too. Has anyone tested that combo?
> > 
> > I can see how Ian missed this -- it very much looked like those two
> > patches were for qemu-upstream only to me (from the subject, cc line etc
> > etc).
> 
> I didn't think that I needed to formally submit patches that were
> requested to be ported over to -traditional when they already
> went into upstream qemu. If I'm wrong with this, then please let
> me know and I'll submit both patches asap.

This is really for Ian J to say but IMHO the two code bases have
diverged enough that blindly pulling from upstream -> traditional is not
a good idea, so at the least the change needs to be tested in that
context.

Even if we were happy to just pull things in then the mail needs to note
somewhere which tree(s) the patch should be applied to. 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShNJ0-0008Bj-JL; Wed, 20 Jun 2012 15:58:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShNIz-0008Ba-7X
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:58:53 +0000
Received: from [85.158.139.83:49350] by server-12.bemta-5.messagelabs.com id
	71/A8-25233-C33F1EF4; Wed, 20 Jun 2012 15:58:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340207932!28940482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27754 invoked from network); 20 Jun 2012 15:58:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:58:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:58:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShNIw-0005aJ-GX; Wed, 20 Jun 2012 15:58:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShNIw-000084-FZ;
	Wed, 20 Jun 2012 16:58:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.62266.471079.950707@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:58:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340207407.4906.77.camel@zakaz.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.com>
	<1340207407.4906.77.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
> This is really for Ian J to say but IMHO the two code bases have
> diverged enough that blindly pulling from upstream -> traditional is not
> a good idea, so at the least the change needs to be tested in that
> context.

Indeed.  I would like someone to at least have looked at the automatic
merge output from a cherry pick.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 15:59:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 15:59:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShNJ0-0008Bj-JL; Wed, 20 Jun 2012 15:58:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShNIz-0008Ba-7X
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 15:58:53 +0000
Received: from [85.158.139.83:49350] by server-12.bemta-5.messagelabs.com id
	71/A8-25233-C33F1EF4; Wed, 20 Jun 2012 15:58:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340207932!28940482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27754 invoked from network); 20 Jun 2012 15:58:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 15:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,444,1336348800"; d="scan'208";a="13129650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:58:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 20 Jun 2012 16:58:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShNIw-0005aJ-GX; Wed, 20 Jun 2012 15:58:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShNIw-000084-FZ;
	Wed, 20 Jun 2012 16:58:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20449.62266.471079.950707@mariner.uk.xensource.com>
Date: Wed, 20 Jun 2012 16:58:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340207407.4906.77.camel@zakaz.uk.xensource.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.com>
	<1340207407.4906.77.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
> This is really for Ian J to say but IMHO the two code bases have
> diverged enough that blindly pulling from upstream -> traditional is not
> a good idea, so at the least the change needs to be tested in that
> context.

Indeed.  I would like someone to at least have looked at the automatic
merge output from a cherry pick.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:04:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:04: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 1ShNOG-0000WH-Bq; Wed, 20 Jun 2012 16:04:20 +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 1ShNOF-0000WC-Am
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:04:19 +0000
Received: from [193.109.254.147:32534] by server-4.bemta-14.messagelabs.com id
	BE/9F-02077-284F1EF4; Wed, 20 Jun 2012 16:04:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340208184!2995909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4766 invoked from network); 20 Jun 2012 16:03:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 16:03:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 17:03:04 +0100
Message-Id: <4FE21084020000780008AE60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 17:03:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
In-Reply-To: <CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.06.12 at 15:58, Rolu <rolu@roce.org> wrote:
> On Tue, Jun 19, 2012 at 11:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Unless this is in the guest kernel, we'll likely need a code fix here,
>> but for determining what and where, we'd need you to provide
>> the qemu log for the domain as well (there ought to be entries
>> starting with "Update msi with pirq", and the gflags value is of
>> particular interest). Depending on what we see, we may then
>> need you to do some further debugging.
>>
> 
> There are, these: (I've copied the full logs below)
> 
> pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
> pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
> pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f

Okay, so at that point the bad value is already there. I'd
suggest taking it up the usage chain, so adding some logging
in pt_msgdata_reg_write() (where the original value -
ptdev->msi->data - is being computed) would likely be a
good first step.

At the same time, adding logging to the guest kernel would
be nice, to see what value it actually writes (in a current
kernel this would be in __write_msi_msg()).

> The qemu logs give several errors and warnings, such as (there are
> multiple of each of these):
> 
> pt_iomul_init: Error: pt_iomul_init can't open file
> /dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
> pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
> to unused Base Address Register. [Offset:30h][Length:4]
> pt_pci_read_config: [00:10:0] Error: Failed to read register with
> offset exceeding FFh. [Offset:ffh][Length:1]
> 
> Are these related, and/or cause for worry? I've looked around some but
> apart from the fact that they have to do with PCI it doesn't tell me
> much. They occur no matter whether I use pci=nomsi or not.

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 Wed Jun 20 16:04:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:04: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 1ShNOG-0000WH-Bq; Wed, 20 Jun 2012 16:04:20 +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 1ShNOF-0000WC-Am
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:04:19 +0000
Received: from [193.109.254.147:32534] by server-4.bemta-14.messagelabs.com id
	BE/9F-02077-284F1EF4; Wed, 20 Jun 2012 16:04:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340208184!2995909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4766 invoked from network); 20 Jun 2012 16:03:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 16:03:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 17:03:04 +0100
Message-Id: <4FE21084020000780008AE60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 17:03:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
In-Reply-To: <CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.06.12 at 15:58, Rolu <rolu@roce.org> wrote:
> On Tue, Jun 19, 2012 at 11:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Unless this is in the guest kernel, we'll likely need a code fix here,
>> but for determining what and where, we'd need you to provide
>> the qemu log for the domain as well (there ought to be entries
>> starting with "Update msi with pirq", and the gflags value is of
>> particular interest). Depending on what we see, we may then
>> need you to do some further debugging.
>>
> 
> There are, these: (I've copied the full logs below)
> 
> pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
> pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
> pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f

Okay, so at that point the bad value is already there. I'd
suggest taking it up the usage chain, so adding some logging
in pt_msgdata_reg_write() (where the original value -
ptdev->msi->data - is being computed) would likely be a
good first step.

At the same time, adding logging to the guest kernel would
be nice, to see what value it actually writes (in a current
kernel this would be in __write_msi_msg()).

> The qemu logs give several errors and warnings, such as (there are
> multiple of each of these):
> 
> pt_iomul_init: Error: pt_iomul_init can't open file
> /dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0
> pt_pci_write_config: [00:05:0] Warning: Guest attempt to set address
> to unused Base Address Register. [Offset:30h][Length:4]
> pt_pci_read_config: [00:10:0] Error: Failed to read register with
> offset exceeding FFh. [Offset:ffh][Length:1]
> 
> Are these related, and/or cause for worry? I've looked around some but
> apart from the fact that they have to do with PCI it doesn't tell me
> much. They occur no matter whether I use pci=nomsi or not.

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 Wed Jun 20 16:04:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShNOT-0000Xa-Ok; Wed, 20 Jun 2012 16:04: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 1ShNOR-0000XF-Sc
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:04:32 +0000
Received: from [85.158.143.99:33621] by server-1.bemta-4.messagelabs.com id
	11/82-24392-F84F1EF4; Wed, 20 Jun 2012 16:04:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340208270!27395593!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18238 invoked from network); 20 Jun 2012 16:04:30 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:04:30 -0000
Received: by eekd41 with SMTP id d41so2881989eek.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 09:04:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HLbI4Y4LKoko+9ySDTwkOmge2PkDVM3EmwW37ce5N/g=;
	b=x6ro8vclgX1CGmzokvH103IhwiexFs0XOxhQbZ3NAzXrOKbLiH3Xrb92AJV8iX8/jD
	YeNBc8YrCa0s4TfDa/rZcPfhZSCb0MezlFiMqGVgZh5AYsOxxnL2NXD64e2PlszLqC+M
	2TujKEWyJUKEWvCA2yl+ATaUAyOq4WtK7rLmQnTsWGKjIBGxAiqlp0yB7kqJeSHmURfn
	6S3fzJlVwXNAlzqzrWjiNu2PgPBv2vmDigsqpOARgoG+oTHrVhDa707P6hBCQPdLIsTs
	EYqcU4Vd8tMZQ1E3Pxw//FPlRz5u4YZKtVY9SOuLgZOaXkFKjidll+jVgnTPVQGNybi6
	YC3g==
Received: by 10.14.98.75 with SMTP id u51mr5150610eef.61.1340208269597;
	Wed, 20 Jun 2012 09:04:29 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id c42sm92442073eeb.2.2012.06.20.09.04.25
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 09:04:29 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 17:04:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC07B30C.434B1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH, v2] x86-64/EFI: document building and usage
Thread-Index: Ac1O/lUZIjxiuQyeM0aBb6wYBvhvzg==
In-Reply-To: <4FE1E656020000780008AD62@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH, v2] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 14:03, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> v2: Switch to using markdown as suggested by Ian Campbell.
>     Also document obvious config file options, as also suggested by Ian.
> 
> --- /dev/null
> +++ b/docs/misc/efi.markdown
> @@ -0,0 +1,79 @@
> +Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, as
> +4.5.x was probably never really tested for this purpose) and binutils 2.22 or
> +newer. Additionally, the binutils build must be configured to include support
> +for the x86_64-pep emulation (i.e. `--enable-targets=x86_64-pep` or an option
> +of equivalent effect should be passed to the configure script).
> +
> +Once built, `make install-xen` can place the resulting binary directly into
> +the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
> +`EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi`
> not
> +match your system).
> +
> +The binary itself will require a configuration file (names with the `.efi`
> +extension of the binary's name replaced by `.cfg`, and - until an existing
> +file is found - trailing name components dropped at `.`, `-`, and `_`
> +separators will be tried) to be present in the same directory as the binary.
> +(To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
> +try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
> +order.) One can override this with a command line option (`-cfg=<filename>`).
> +
> +The configuration file consists of one or more sections headed by a section
> +name enclosed in square brackets, with individual values specified in each
> +section. A section named `[global]` is treated specially to allow certain
> +settings to apply to all other sections (or to provide defaults for certain
> +settings in case individual sections don't specify them). A typical file
> would
> +thus look like this (`#` serving as comment character):
> +
> +    **************************example begin******************************
> +
> +    [global]
> +    default=sle11sp2
> +    
> +    [sle11sp2]
> +    options=console=vga,com1 com1=57600 loglvl=all noreboot
> +    kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
> +    ramdisk=initrd-3.0.31-0.4-xen
> +
> +    **************************example end********************************
> +
> +The individual values used here are:
> +
> +###`default=<name>`
> +
> +Specifies the section to use for booting, if none was specified on the
> command
> +line; only meaningful in the `[global]` section. This isn't required; if
> +absent, section headers will be ignored and for each value looked for the
> +first instance within the file will be used.
> +
> +###`options=<text>`
> +
> +Specifies the options passed to the hypervisor, see [Xen Hypervisor Command
> +Line Options](xen-command-line.html).
> +
> +###`kernel=<filename>[ <options>]`
> +
> +Specifies the Dom0 kernel binary and the options to pass to it.
> +
> +###`ramdisk=<filename>`
> +
> +Specifies a Linux-style initial RAM disk image to load.
> +
> +Other values to specify are:
> +
> +###`video=gfx-<xres>[x<yres>[x<depth>]]`
> +
> +Specifies a video mode to select if available. In case of problems, the
> +`-basevideo` command line option can be used to skip altering video modes.
> +
> +###`xsm=<filename>`
> +
> +Specifies an XSM module to load.
> +
> +###`ucode=<filename>`
> +
> +Specifies a CPU microcode blob to load.
> +
> +Filenames must be specified relative to the location of the EFI binary.
> +
> +Extra options to be passed to Xen can also be specified on the command line,
> +following a `--` separator option.
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 16:04:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:04:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShNOT-0000Xa-Ok; Wed, 20 Jun 2012 16:04: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 1ShNOR-0000XF-Sc
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:04:32 +0000
Received: from [85.158.143.99:33621] by server-1.bemta-4.messagelabs.com id
	11/82-24392-F84F1EF4; Wed, 20 Jun 2012 16:04:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340208270!27395593!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18238 invoked from network); 20 Jun 2012 16:04:30 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:04:30 -0000
Received: by eekd41 with SMTP id d41so2881989eek.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 09:04:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HLbI4Y4LKoko+9ySDTwkOmge2PkDVM3EmwW37ce5N/g=;
	b=x6ro8vclgX1CGmzokvH103IhwiexFs0XOxhQbZ3NAzXrOKbLiH3Xrb92AJV8iX8/jD
	YeNBc8YrCa0s4TfDa/rZcPfhZSCb0MezlFiMqGVgZh5AYsOxxnL2NXD64e2PlszLqC+M
	2TujKEWyJUKEWvCA2yl+ATaUAyOq4WtK7rLmQnTsWGKjIBGxAiqlp0yB7kqJeSHmURfn
	6S3fzJlVwXNAlzqzrWjiNu2PgPBv2vmDigsqpOARgoG+oTHrVhDa707P6hBCQPdLIsTs
	EYqcU4Vd8tMZQ1E3Pxw//FPlRz5u4YZKtVY9SOuLgZOaXkFKjidll+jVgnTPVQGNybi6
	YC3g==
Received: by 10.14.98.75 with SMTP id u51mr5150610eef.61.1340208269597;
	Wed, 20 Jun 2012 09:04:29 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id c42sm92442073eeb.2.2012.06.20.09.04.25
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 09:04:29 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 17:04:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC07B30C.434B1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH, v2] x86-64/EFI: document building and usage
Thread-Index: Ac1O/lUZIjxiuQyeM0aBb6wYBvhvzg==
In-Reply-To: <4FE1E656020000780008AD62@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH, v2] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 14:03, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> v2: Switch to using markdown as suggested by Ian Campbell.
>     Also document obvious config file options, as also suggested by Ian.
> 
> --- /dev/null
> +++ b/docs/misc/efi.markdown
> @@ -0,0 +1,79 @@
> +Building xen.efi requires gcc 4.5.x or above (4.6.x or newer recommended, as
> +4.5.x was probably never really tested for this purpose) and binutils 2.22 or
> +newer. Additionally, the binutils build must be configured to include support
> +for the x86_64-pep emulation (i.e. `--enable-targets=x86_64-pep` or an option
> +of equivalent effect should be passed to the configure script).
> +
> +Once built, `make install-xen` can place the resulting binary directly into
> +the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
> +`EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi`
> not
> +match your system).
> +
> +The binary itself will require a configuration file (names with the `.efi`
> +extension of the binary's name replaced by `.cfg`, and - until an existing
> +file is found - trailing name components dropped at `.`, `-`, and `_`
> +separators will be tried) to be present in the same directory as the binary.
> +(To illustrate the name handling, a binary named `xen-4.2-unstable.efi` would
> +try `xen-4.2-unstable.cfg`, `xen-4.2.cfg`, `xen-4.cfg`, and `xen.cfg` in
> +order.) One can override this with a command line option (`-cfg=<filename>`).
> +
> +The configuration file consists of one or more sections headed by a section
> +name enclosed in square brackets, with individual values specified in each
> +section. A section named `[global]` is treated specially to allow certain
> +settings to apply to all other sections (or to provide defaults for certain
> +settings in case individual sections don't specify them). A typical file
> would
> +thus look like this (`#` serving as comment character):
> +
> +    **************************example begin******************************
> +
> +    [global]
> +    default=sle11sp2
> +    
> +    [sle11sp2]
> +    options=console=vga,com1 com1=57600 loglvl=all noreboot
> +    kernel=vmlinuz-3.0.31-0.4-xen ignore_loglevel #earlyprintk=xen
> +    ramdisk=initrd-3.0.31-0.4-xen
> +
> +    **************************example end********************************
> +
> +The individual values used here are:
> +
> +###`default=<name>`
> +
> +Specifies the section to use for booting, if none was specified on the
> command
> +line; only meaningful in the `[global]` section. This isn't required; if
> +absent, section headers will be ignored and for each value looked for the
> +first instance within the file will be used.
> +
> +###`options=<text>`
> +
> +Specifies the options passed to the hypervisor, see [Xen Hypervisor Command
> +Line Options](xen-command-line.html).
> +
> +###`kernel=<filename>[ <options>]`
> +
> +Specifies the Dom0 kernel binary and the options to pass to it.
> +
> +###`ramdisk=<filename>`
> +
> +Specifies a Linux-style initial RAM disk image to load.
> +
> +Other values to specify are:
> +
> +###`video=gfx-<xres>[x<yres>[x<depth>]]`
> +
> +Specifies a video mode to select if available. In case of problems, the
> +`-basevideo` command line option can be used to skip altering video modes.
> +
> +###`xsm=<filename>`
> +
> +Specifies an XSM module to load.
> +
> +###`ucode=<filename>`
> +
> +Specifies a CPU microcode blob to load.
> +
> +Filenames must be specified relative to the location of the EFI binary.
> +
> +Extra options to be passed to Xen can also be specified on the command line,
> +following a `--` separator option.
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 20 16:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:04: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 1ShNOZ-0000Yn-5C; Wed, 20 Jun 2012 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 <keir.xen@gmail.com>) id 1ShNOX-0000YM-4q
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:04:37 +0000
Received: from [193.109.254.147:35597] by server-2.bemta-14.messagelabs.com id
	4D/79-01735-494F1EF4; Wed, 20 Jun 2012 16:04:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340208275!8594279!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31596 invoked from network); 20 Jun 2012 16:04:35 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:04:35 -0000
Received: by eaak12 with SMTP id k12so2862450eaa.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 09:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Ziv6H65n72J1MkhkyCrQ9bYcKs3vUS39oBbMdD47y7k=;
	b=tMoRO/1fOU8qHtHr06WQDBA58UYEpvOOskwen+G98/gCr3KrWS/+Nn/KOY86gcnSYE
	WAMXnkkAHJ+KZeIXWJYkBC03WQZs6S9/2a1MXXOah+l6pNJOgrYl0jpD6Fnnwf4DIxEf
	O7F5vPduksDUjBmYqiysG0rAIPJjQoJShDgQQ9wwajO3QbS18gT+znAbrIijlj0uKZ34
	j4O5W183AAE/99FR+TbJ869vFjD1EBSqJkReAUihX8qDwPL9z5Zlu2m18lDQGnc5KhWC
	CHdnCPGWAqjKx0YMQ62bgca6D2GbBOtd2omASdFaqKRLfxVl5mweEMwxRUvF2jkxjVMJ
	lxRw==
Received: by 10.14.100.144 with SMTP id z16mr5229971eef.50.1340208275102;
	Wed, 20 Jun 2012 09:04:35 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id c42sm92442073eeb.2.2012.06.20.09.04.29
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 09:04:34 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 17:04:24 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC07B318.434B2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: fix mod_l1_entry() return value when
	encountering r/o MMIO page
Thread-Index: Ac1O/lxAsdbuOPzMLEyJDs9jFm2XCw==
In-Reply-To: <4FE205F1020000780008ADFB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/mm: fix mod_l1_entry() return value
 when encountering r/o MMIO page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/06/2012 16:18, "Jan Beulich" <JBeulich@suse.com> wrote:

> While putting together the workaround announced in
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I
> found that mod_l1_entry(), upon encountering a set bit in
> mmio_ro_ranges, would return 1 instead of 0 (the removal of the write
> permission is supposed to be entirely transparent to the caller, even
> more so to the calling guest).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>              break;
>          case 1:
>              l1e_remove_flags(nl1e, _PAGE_RW);
> +            rc = 0;
>              break;
>          }
>          if ( page )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:04: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 1ShNOZ-0000Yn-5C; Wed, 20 Jun 2012 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 <keir.xen@gmail.com>) id 1ShNOX-0000YM-4q
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:04:37 +0000
Received: from [193.109.254.147:35597] by server-2.bemta-14.messagelabs.com id
	4D/79-01735-494F1EF4; Wed, 20 Jun 2012 16:04:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340208275!8594279!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31596 invoked from network); 20 Jun 2012 16:04:35 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:04:35 -0000
Received: by eaak12 with SMTP id k12so2862450eaa.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 09:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Ziv6H65n72J1MkhkyCrQ9bYcKs3vUS39oBbMdD47y7k=;
	b=tMoRO/1fOU8qHtHr06WQDBA58UYEpvOOskwen+G98/gCr3KrWS/+Nn/KOY86gcnSYE
	WAMXnkkAHJ+KZeIXWJYkBC03WQZs6S9/2a1MXXOah+l6pNJOgrYl0jpD6Fnnwf4DIxEf
	O7F5vPduksDUjBmYqiysG0rAIPJjQoJShDgQQ9wwajO3QbS18gT+znAbrIijlj0uKZ34
	j4O5W183AAE/99FR+TbJ869vFjD1EBSqJkReAUihX8qDwPL9z5Zlu2m18lDQGnc5KhWC
	CHdnCPGWAqjKx0YMQ62bgca6D2GbBOtd2omASdFaqKRLfxVl5mweEMwxRUvF2jkxjVMJ
	lxRw==
Received: by 10.14.100.144 with SMTP id z16mr5229971eef.50.1340208275102;
	Wed, 20 Jun 2012 09:04:35 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id c42sm92442073eeb.2.2012.06.20.09.04.29
	(version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 09:04:34 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 20 Jun 2012 17:04:24 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC07B318.434B2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: fix mod_l1_entry() return value when
	encountering r/o MMIO page
Thread-Index: Ac1O/lxAsdbuOPzMLEyJDs9jFm2XCw==
In-Reply-To: <4FE205F1020000780008ADFB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/mm: fix mod_l1_entry() return value
 when encountering r/o MMIO page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/06/2012 16:18, "Jan Beulich" <JBeulich@suse.com> wrote:

> While putting together the workaround announced in
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg00709.html, I
> found that mod_l1_entry(), upon encountering a set bit in
> mmio_ro_ranges, would return 1 instead of 0 (the removal of the write
> permission is supposed to be entirely transparent to the caller, even
> more so to the calling guest).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>              break;
>          case 1:
>              l1e_remove_flags(nl1e, _PAGE_RW);
> +            rc = 0;
>              break;
>          }
>          if ( page )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:06:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:06: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 1ShNQH-0000mv-LV; Wed, 20 Jun 2012 16:06:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShNQG-0000md-4f
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:06:24 +0000
Received: from [85.158.143.35:50328] by server-3.bemta-4.messagelabs.com id
	73/48-05808-FF4F1EF4; Wed, 20 Jun 2012 16:06:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340208367!16152654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8502 invoked from network); 20 Jun 2012 16:06:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 16:06:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 17:06:07 +0100
Message-Id: <4FE2113A020000780008AE6D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 17:06:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.com>
	<20449.61581.396812.290324@mariner.uk.xensource.com>
In-Reply-To: <20449.61581.396812.290324@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
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] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:47, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
>> I didn't think that I needed to formally submit patches that were
>> requested to be ported over to -traditional when they already
>> went into upstream qemu. If I'm wrong with this, then please let
>> me know and I'll submit both patches asap.
> 
> Certainly there is nothing automatic (people or computers) that fishes
> changes to qemu upstream into -traditional.  If you want something
> committed to qemu-xen-traditional you'll have to say so.

I'm not talking about anything automatic here. The need for
pulling the change over was pointed out a number of times by
both Stefano and me.

Anyway - do you need a formal patch submission, or can you
just pull out the one important and possibly one secondary
commits?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:06:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:06: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 1ShNQH-0000mv-LV; Wed, 20 Jun 2012 16:06:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShNQG-0000md-4f
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:06:24 +0000
Received: from [85.158.143.35:50328] by server-3.bemta-4.messagelabs.com id
	73/48-05808-FF4F1EF4; Wed, 20 Jun 2012 16:06:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340208367!16152654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8502 invoked from network); 20 Jun 2012 16:06:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 16:06:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Jun 2012 17:06:07 +0100
Message-Id: <4FE2113A020000780008AE6D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 20 Jun 2012 17:06:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1339506046.24104.30.camel@zakaz.uk.xensource.com>
	<4FD766E2020000780008974F@nat28.tlf.novell.com>
	<1339509935.24104.66.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206131146200.14957@kaball.uk.xensource.com>
	<1340205929.4906.66.camel@zakaz.uk.xensource.com>
	<4FE20B23020000780008AE16@nat28.tlf.novell.com>
	<20449.61581.396812.290324@mariner.uk.xensource.com>
In-Reply-To: <20449.61581.396812.290324@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
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] Xen 4.2 TODO / Release Plan
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:47, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"):
>> I didn't think that I needed to formally submit patches that were
>> requested to be ported over to -traditional when they already
>> went into upstream qemu. If I'm wrong with this, then please let
>> me know and I'll submit both patches asap.
> 
> Certainly there is nothing automatic (people or computers) that fishes
> changes to qemu upstream into -traditional.  If you want something
> committed to qemu-xen-traditional you'll have to say so.

I'm not talking about anything automatic here. The need for
pulling the change over was pointed out a number of times by
both Stefano and me.

Anyway - do you need a formal patch submission, or can you
just pull out the one important and possibly one secondary
commits?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShNyF-0001TO-53; Wed, 20 Jun 2012 16:41:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShNyD-0001TJ-9f
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:41:29 +0000
Received: from [85.158.139.83:46515] by server-1.bemta-5.messagelabs.com id
	1C/6B-19721-83DF1EF4; Wed, 20 Jun 2012 16:41:28 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340210483!24400205!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU2NzQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27855 invoked from network); 20 Jun 2012 16:41:25 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:41:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340210485; x=1371746485;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=nuOdGhMzkMh2vBji1nCyqYrt1E9rloNcBbp45diqyk8=;
	b=HLoTwLHWcEtTsJaX2sv9K5U/dBRZFqphKHArvN41GurbnIHlF1HeLRIO
	aBiQ4/dZaQhSCoRgqNxLZIYi5PSCuA==;
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="318027709"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 16:41:22 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.56])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q5KGfJbc030056; Wed, 20 Jun 2012 16:41:20 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 20 Jun 2012 09:41:11 -0700
Date: Wed, 20 Jun 2012 09:41:11 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120620164111.GA2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<1340183435.4906.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340183435.4906.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 02:10:35AM -0700, Ian Campbell wrote:
> On Wed, 2012-06-20 at 01:46 +0100, Matt Wilson wrote:
> >
> >  LIBLEAFDIR = lib
> >  LIBLEAFDIR_x86_32 = lib
> >  LIBLEAFDIR_x86_64 ?= lib64
> > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> >  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> >  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> 
> Roger already asked if we can somehow get rid of all the LEAFDIR stuff
> too.

That'd be lovely. I was a little worried about the python syspath
bits, but now that I've looked to see that it uses distutils that
should be fine.

> > diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> > --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> > @@ -1,5 +1,7 @@
> >  # Prefix and install folder
> >  PREFIX              := @prefix@
> > +exec_prefix         := @exec_prefix@
> 
> Is exec_prefix related to this change?

Yes, libdir defauts to ${exec_prefix}/lib, so if we don't bring
exec_prefix into Tooks.mk, files will land in /lib by default instead
of /usr/lib.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShNyF-0001TO-53; Wed, 20 Jun 2012 16:41:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShNyD-0001TJ-9f
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:41:29 +0000
Received: from [85.158.139.83:46515] by server-1.bemta-5.messagelabs.com id
	1C/6B-19721-83DF1EF4; Wed, 20 Jun 2012 16:41:28 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340210483!24400205!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU2NzQ5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27855 invoked from network); 20 Jun 2012 16:41:25 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:41:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340210485; x=1371746485;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=nuOdGhMzkMh2vBji1nCyqYrt1E9rloNcBbp45diqyk8=;
	b=HLoTwLHWcEtTsJaX2sv9K5U/dBRZFqphKHArvN41GurbnIHlF1HeLRIO
	aBiQ4/dZaQhSCoRgqNxLZIYi5PSCuA==;
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="318027709"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 16:41:22 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.56])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q5KGfJbc030056; Wed, 20 Jun 2012 16:41:20 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 20 Jun 2012 09:41:11 -0700
Date: Wed, 20 Jun 2012 09:41:11 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120620164111.GA2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<1340183435.4906.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340183435.4906.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 02:10:35AM -0700, Ian Campbell wrote:
> On Wed, 2012-06-20 at 01:46 +0100, Matt Wilson wrote:
> >
> >  LIBLEAFDIR = lib
> >  LIBLEAFDIR_x86_32 = lib
> >  LIBLEAFDIR_x86_64 ?= lib64
> > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> >  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> >  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> 
> Roger already asked if we can somehow get rid of all the LEAFDIR stuff
> too.

That'd be lovely. I was a little worried about the python syspath
bits, but now that I've looked to see that it uses distutils that
should be fine.

> > diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> > --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> > @@ -1,5 +1,7 @@
> >  # Prefix and install folder
> >  PREFIX              := @prefix@
> > +exec_prefix         := @exec_prefix@
> 
> Is exec_prefix related to this change?

Yes, libdir defauts to ${exec_prefix}/lib, so if we don't bring
exec_prefix into Tooks.mk, files will land in /lib by default instead
of /usr/lib.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:44:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShO16-0001ZS-NP; Wed, 20 Jun 2012 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 <msw@amazon.com>) id 1ShO15-0001ZF-5R
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:44:27 +0000
Received: from [85.158.143.35:9688] by server-1.bemta-4.messagelabs.com id
	8F/84-24392-AEDF1EF4; Wed, 20 Jun 2012 16:44:26 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340210663!14750101!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzQ3OTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5166 invoked from network); 20 Jun 2012 16:44:25 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:44:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340210665; x=1371746665;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=TqQwktQj9JNBWqgjYgPJ02vViw2LADscdNKgyJgo4jg=;
	b=ODMrz8vpw1HYaup4xXQNcyGsnbtcXjUxweM+s1UdzoIugh4NaiwOC56C
	wHU1LzS6/x/WKIbkNjoV3oP8/n9HVQ==;
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="251562246"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 16:44:22 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.56])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q5KGiLpq001756; Wed, 20 Jun 2012 16:44:21 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 20 Jun 2012 09:44:13 -0700
Date: Wed, 20 Jun 2012 09:44:13 -0700
From: Matt Wilson <msw@amazon.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120620164413.GB2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE18F05.8030309@citrix.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 01:51:17AM -0700, Roger Pau Monne wrote:
> Matt Wilson wrote:
> > Signed-off-by: Matt Wilson<msw@amazon.com>
> 
> Thanks for the patch! The way FSIMAGE_FSDIR is set is really wrong.

No problem. The FSIMAGE_FSDIR bit was a gross hack so I didn't have to
touch autoconf, which I try to avoid. ;-)

> > diff -r 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
> > --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> > @@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
> >   INCLUDEDIR = $(PREFIX)/include
> >   LIBLEAFDIR = lib
> >   LIBLEAFDIR_x86_64 = lib/amd64
> > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> >   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> >   MANDIR = $(PREFIX)/share/man
> >   MAN1DIR = $(MANDIR)/man1
> 
> Can we clean this a little bit more, and remove LIBDIR_x86_32,
> LIBLEAFDIR_x86_64, LIBDIR_x86_64, LIBDIR_x86_32 and LIBLEAFDIR?

I was thinking that too, but was a little worried about expectations
on Solaris. Maybe I souldn't.

> > -CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
> > +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
> 
> I would prefer to set FSIMAGE_FSDIR or an equivalent define in 
> tools/config.h and include that header in 
> tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that 
> value from the compiler command line.

Makes sense.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:44:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShO16-0001ZS-NP; Wed, 20 Jun 2012 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 <msw@amazon.com>) id 1ShO15-0001ZF-5R
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:44:27 +0000
Received: from [85.158.143.35:9688] by server-1.bemta-4.messagelabs.com id
	8F/84-24392-AEDF1EF4; Wed, 20 Jun 2012 16:44:26 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340210663!14750101!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzQ3OTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5166 invoked from network); 20 Jun 2012 16:44:25 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:44:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340210665; x=1371746665;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=TqQwktQj9JNBWqgjYgPJ02vViw2LADscdNKgyJgo4jg=;
	b=ODMrz8vpw1HYaup4xXQNcyGsnbtcXjUxweM+s1UdzoIugh4NaiwOC56C
	wHU1LzS6/x/WKIbkNjoV3oP8/n9HVQ==;
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="251562246"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 16:44:22 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.56])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q5KGiLpq001756; Wed, 20 Jun 2012 16:44:21 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 20 Jun 2012 09:44:13 -0700
Date: Wed, 20 Jun 2012 09:44:13 -0700
From: Matt Wilson <msw@amazon.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120620164413.GB2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE18F05.8030309@citrix.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 01:51:17AM -0700, Roger Pau Monne wrote:
> Matt Wilson wrote:
> > Signed-off-by: Matt Wilson<msw@amazon.com>
> 
> Thanks for the patch! The way FSIMAGE_FSDIR is set is really wrong.

No problem. The FSIMAGE_FSDIR bit was a gross hack so I didn't have to
touch autoconf, which I try to avoid. ;-)

> > diff -r 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
> > --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> > @@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
> >   INCLUDEDIR = $(PREFIX)/include
> >   LIBLEAFDIR = lib
> >   LIBLEAFDIR_x86_64 = lib/amd64
> > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> >   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> >   MANDIR = $(PREFIX)/share/man
> >   MAN1DIR = $(MANDIR)/man1
> 
> Can we clean this a little bit more, and remove LIBDIR_x86_32,
> LIBLEAFDIR_x86_64, LIBDIR_x86_64, LIBDIR_x86_32 and LIBLEAFDIR?

I was thinking that too, but was a little worried about expectations
on Solaris. Maybe I souldn't.

> > -CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
> > +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
> 
> I would prefer to set FSIMAGE_FSDIR or an equivalent define in 
> tools/config.h and include that header in 
> tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that 
> value from the compiler command line.

Makes sense.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:44:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:44: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 1ShO18-0001Zj-3F; Wed, 20 Jun 2012 16:44: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 1ShO17-0001ZY-BN
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:44:29 +0000
Received: from [85.158.143.35:17994] by server-2.bemta-4.messagelabs.com id
	32/66-17938-CEDF1EF4; Wed, 20 Jun 2012 16:44:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340210668!14087999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10530 invoked from network); 20 Jun 2012 16:44:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:44:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="13130565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 16:44:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 17:44:27 +0100
Message-ID: <1340210666.4906.79.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 20 Jun 2012 17:44:26 +0100
In-Reply-To: <20120620164111.GA2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<1340183435.4906.10.camel@zakaz.uk.xensource.com>
	<20120620164111.GA2640@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 17:41 +0100, Matt Wilson wrote:
> On Wed, Jun 20, 2012 at 02:10:35AM -0700, Ian Campbell wrote:
> > On Wed, 2012-06-20 at 01:46 +0100, Matt Wilson wrote:
> > >
> > >  LIBLEAFDIR = lib
> > >  LIBLEAFDIR_x86_32 = lib
> > >  LIBLEAFDIR_x86_64 ?= lib64
> > > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > >  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > >  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > 
> > Roger already asked if we can somehow get rid of all the LEAFDIR stuff
> > too.
> 
> That'd be lovely. I was a little worried about the python syspath
> bits, but now that I've looked to see that it uses distutils that
> should be fine.

Cool!

> > > diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> > > --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> > > +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> > > @@ -1,5 +1,7 @@
> > >  # Prefix and install folder
> > >  PREFIX              := @prefix@
> > > +exec_prefix         := @exec_prefix@
> > 
> > Is exec_prefix related to this change?
> 
> Yes, libdir defauts to ${exec_prefix}/lib, so if we don't bring
> exec_prefix into Tooks.mk, files will land in /lib by default instead
> of /usr/lib.

Ah, makes perfect sense, 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 Jun 20 16:44:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16:44: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 1ShO18-0001Zj-3F; Wed, 20 Jun 2012 16:44: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 1ShO17-0001ZY-BN
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:44:29 +0000
Received: from [85.158.143.35:17994] by server-2.bemta-4.messagelabs.com id
	32/66-17938-CEDF1EF4; Wed, 20 Jun 2012 16:44:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340210668!14087999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10530 invoked from network); 20 Jun 2012 16:44:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:44:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="13130565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 16:44:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 17:44:27 +0100
Message-ID: <1340210666.4906.79.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 20 Jun 2012 17:44:26 +0100
In-Reply-To: <20120620164111.GA2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<1340183435.4906.10.camel@zakaz.uk.xensource.com>
	<20120620164111.GA2640@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 17:41 +0100, Matt Wilson wrote:
> On Wed, Jun 20, 2012 at 02:10:35AM -0700, Ian Campbell wrote:
> > On Wed, 2012-06-20 at 01:46 +0100, Matt Wilson wrote:
> > >
> > >  LIBLEAFDIR = lib
> > >  LIBLEAFDIR_x86_32 = lib
> > >  LIBLEAFDIR_x86_64 ?= lib64
> > > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > >  LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > >  LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > 
> > Roger already asked if we can somehow get rid of all the LEAFDIR stuff
> > too.
> 
> That'd be lovely. I was a little worried about the python syspath
> bits, but now that I've looked to see that it uses distutils that
> should be fine.

Cool!

> > > diff -r 32034d1914a6 -r 0a592e08ac31 config/Tools.mk.in
> > > --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> > > +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> > > @@ -1,5 +1,7 @@
> > >  # Prefix and install folder
> > >  PREFIX              := @prefix@
> > > +exec_prefix         := @exec_prefix@
> > 
> > Is exec_prefix related to this change?
> 
> Yes, libdir defauts to ${exec_prefix}/lib, so if we don't bring
> exec_prefix into Tooks.mk, files will land in /lib by default instead
> of /usr/lib.

Ah, makes perfect sense, 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 Jun 20 16:51:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16: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 1ShO7j-0001ye-QO; Wed, 20 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1ShO7h-0001yK-MO
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:51:17 +0000
Received: from [85.158.139.83:41573] by server-5.bemta-5.messagelabs.com id
	65/18-02722-48FF1EF4; Wed, 20 Jun 2012 16:51:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340211076!28672276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24760 invoked from network); 20 Jun 2012 16:51:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="13130685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 16:51:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 17:51:10 +0100
Message-ID: <1340211068.4906.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 20 Jun 2012 17:51:08 +0100
In-Reply-To: <20120620164413.GB2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com> <20120620164413.GB2640@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
> > > --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> > > +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> > > @@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
> > >   INCLUDEDIR = $(PREFIX)/include
> > >   LIBLEAFDIR = lib
> > >   LIBLEAFDIR_x86_64 = lib/amd64
> > > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > >   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > >   MANDIR = $(PREFIX)/share/man
> > >   MAN1DIR = $(MANDIR)/man1
> > 
> > Can we clean this a little bit more, and remove LIBDIR_x86_32,
> > LIBLEAFDIR_x86_64, LIBDIR_x86_64, LIBDIR_x86_32 and LIBLEAFDIR?
> 
> I was thinking that too, but was a little worried about expectations
> on Solaris. Maybe I souldn't.

I'm sure that Solaris doesn't work already, feel free to break it.

We should probably just nuke all these vestigial Solaris bits in 4.3...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 16:51:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 16: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 1ShO7j-0001ye-QO; Wed, 20 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1ShO7h-0001yK-MO
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 16:51:17 +0000
Received: from [85.158.139.83:41573] by server-5.bemta-5.messagelabs.com id
	65/18-02722-48FF1EF4; Wed, 20 Jun 2012 16:51:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340211076!28672276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24760 invoked from network); 20 Jun 2012 16:51:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 16:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="13130685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 16:51:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 17:51:10 +0100
Message-ID: <1340211068.4906.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 20 Jun 2012 17:51:08 +0100
In-Reply-To: <20120620164413.GB2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com> <20120620164413.GB2640@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 32034d1914a6 -r 0a592e08ac31 config/SunOS.mk
> > > --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> > > +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> > > @@ -24,7 +24,6 @@ BINDIR = $(PREFIX)/bin
> > >   INCLUDEDIR = $(PREFIX)/include
> > >   LIBLEAFDIR = lib
> > >   LIBLEAFDIR_x86_64 = lib/amd64
> > > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > >   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > >   MANDIR = $(PREFIX)/share/man
> > >   MAN1DIR = $(MANDIR)/man1
> > 
> > Can we clean this a little bit more, and remove LIBDIR_x86_32,
> > LIBLEAFDIR_x86_64, LIBDIR_x86_64, LIBDIR_x86_32 and LIBLEAFDIR?
> 
> I was thinking that too, but was a little worried about expectations
> on Solaris. Maybe I souldn't.

I'm sure that Solaris doesn't work already, feel free to break it.

We should probably just nuke all these vestigial Solaris bits in 4.3...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 17:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShOPr-0003Hc-Fg; Wed, 20 Jun 2012 17:10:03 +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 1ShOPp-0003HJ-V2
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:10:02 +0000
Received: from [85.158.139.83:28027] by server-9.bemta-5.messagelabs.com id
	19/D3-01069-9E302EF4; Wed, 20 Jun 2012 17:10:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340212200!27988475!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15913 invoked from network); 20 Jun 2012 17:10:00 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 17:10:00 -0000
Received: by wgbed3 with SMTP id ed3so5602503wgb.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 10:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=69QkJrXpS6qZAUBqpmKdXGGs+hvJKcQDbJNSTfT4kdA=;
	b=XZFTCHHRrmdEHETM9cTRZ8jmkgWHcRkq7AltosNTqzx12DlpEIr55uzYOoptarqy4a
	P96RVItkewT7nzhrPuslvI2H8rai7paImU8OO6DO8WDDnq2evTQIz+06dffMebeyd2r1
	N3JIYfp96lUF6EkgE0unc/P4mcIaRJq7trr7bi6ZG6x7Lqs9DD1PZ+H9i0R3V8MyA/k3
	rONCJWex+Kjfy+ImKoQdyab9I8Q3u2ltwQCSAPqX1cJFrluJ4jvtOGGeWnpXY7L00vfc
	mRS11ua3+am8Ha8Usaxi3HgqPgJaAW3YJyxtw3L/7lBVUYwTvUQPSyS7BSH/gJmypzZl
	Xsyw==
Received: by 10.180.102.228 with SMTP id fr4mr13551107wib.6.1340212200300;
	Wed, 20 Jun 2012 10:10:00 -0700 (PDT)
Received: from [127.0.1.1] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id gb9sm40025516wib.8.2012.06.20.10.09.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 20 Jun 2012 10:09:58 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: cbd6b5a7d0451a98a8c6607c8384e52a0a8f999a
Message-Id: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Jun 2012 19:09:56 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "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] xl: fix sedf parameters 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

9d1fd58ff602 was bogous in not letting a new domain being created
if its scheduling parameters --when running under the sedf scheduler--
were not fully specified, making creation fail like in this example
here below:

2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg
libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument
libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3
Parsing config from /etc/xen/debian.guest.osstest.cfg

This is due to the fact the values for period, slice, weight and
extratime should be consistent among each others, and if not all
are explicitly specified, someone has to make that happen. That
was right the purpose of the change in question, but it was failing
at achieving so.

This commit fixes things by forcing unspecified parameters to
sensible values, depending on the ones the user provided.

Signed-off-by: Dario Faggioli <dario.faggioli@citix.com>

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
@@ -555,6 +555,8 @@ static int sched_params_valid(libxl_doma
     int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
     int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
     int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    int has_extratime =
+                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
     libxl_domain_sched_params sci;
 
     libxl_domain_sched_params_get(ctx, domid, &sci);
@@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
     if (sci.sched == LIBXL_SCHEDULER_SEDF) {
         if (has_weight && (has_period || has_slice))
             return 0;
-
+        if (has_period != has_slice)
+            return 0;
+
+        /*
+         * Idea is, if we specify a weight, then both period and
+         * slice has to be zero. OTOH, if we do not specify a weight,
+         * that means we want a pure best effort domain or an actual
+         * real-time one. In the former case, it is period that needs
+         * to be zero, in the latter, weight should be.
+         */
         if (has_weight) {
             scp->slice = 0;
             scp->period = 0;
         }
-        if (has_period || has_slice)
+        else if (!has_period) {
+            /* We can setup a proper best effort domain (extra time only)
+             * iff we either already have or are asking for some extra time. */
+            scp->weight = has_extratime ? scp->extratime : sci.extratime;
+            scp->period = 0;
+        }
+        if (has_period && has_slice)
             scp->weight = 0;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 17:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShOPr-0003Hc-Fg; Wed, 20 Jun 2012 17:10:03 +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 1ShOPp-0003HJ-V2
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:10:02 +0000
Received: from [85.158.139.83:28027] by server-9.bemta-5.messagelabs.com id
	19/D3-01069-9E302EF4; Wed, 20 Jun 2012 17:10:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340212200!27988475!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15913 invoked from network); 20 Jun 2012 17:10:00 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 17:10:00 -0000
Received: by wgbed3 with SMTP id ed3so5602503wgb.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 10:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=69QkJrXpS6qZAUBqpmKdXGGs+hvJKcQDbJNSTfT4kdA=;
	b=XZFTCHHRrmdEHETM9cTRZ8jmkgWHcRkq7AltosNTqzx12DlpEIr55uzYOoptarqy4a
	P96RVItkewT7nzhrPuslvI2H8rai7paImU8OO6DO8WDDnq2evTQIz+06dffMebeyd2r1
	N3JIYfp96lUF6EkgE0unc/P4mcIaRJq7trr7bi6ZG6x7Lqs9DD1PZ+H9i0R3V8MyA/k3
	rONCJWex+Kjfy+ImKoQdyab9I8Q3u2ltwQCSAPqX1cJFrluJ4jvtOGGeWnpXY7L00vfc
	mRS11ua3+am8Ha8Usaxi3HgqPgJaAW3YJyxtw3L/7lBVUYwTvUQPSyS7BSH/gJmypzZl
	Xsyw==
Received: by 10.180.102.228 with SMTP id fr4mr13551107wib.6.1340212200300;
	Wed, 20 Jun 2012 10:10:00 -0700 (PDT)
Received: from [127.0.1.1] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id gb9sm40025516wib.8.2012.06.20.10.09.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 20 Jun 2012 10:09:58 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: cbd6b5a7d0451a98a8c6607c8384e52a0a8f999a
Message-Id: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Jun 2012 19:09:56 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "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] xl: fix sedf parameters 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

9d1fd58ff602 was bogous in not letting a new domain being created
if its scheduling parameters --when running under the sedf scheduler--
were not fully specified, making creation fail like in this example
here below:

2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg
libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument
libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3
Parsing config from /etc/xen/debian.guest.osstest.cfg

This is due to the fact the values for period, slice, weight and
extratime should be consistent among each others, and if not all
are explicitly specified, someone has to make that happen. That
was right the purpose of the change in question, but it was failing
at achieving so.

This commit fixes things by forcing unspecified parameters to
sensible values, depending on the ones the user provided.

Signed-off-by: Dario Faggioli <dario.faggioli@citix.com>

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
@@ -555,6 +555,8 @@ static int sched_params_valid(libxl_doma
     int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
     int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
     int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    int has_extratime =
+                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
     libxl_domain_sched_params sci;
 
     libxl_domain_sched_params_get(ctx, domid, &sci);
@@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
     if (sci.sched == LIBXL_SCHEDULER_SEDF) {
         if (has_weight && (has_period || has_slice))
             return 0;
-
+        if (has_period != has_slice)
+            return 0;
+
+        /*
+         * Idea is, if we specify a weight, then both period and
+         * slice has to be zero. OTOH, if we do not specify a weight,
+         * that means we want a pure best effort domain or an actual
+         * real-time one. In the former case, it is period that needs
+         * to be zero, in the latter, weight should be.
+         */
         if (has_weight) {
             scp->slice = 0;
             scp->period = 0;
         }
-        if (has_period || has_slice)
+        else if (!has_period) {
+            /* We can setup a proper best effort domain (extra time only)
+             * iff we either already have or are asking for some extra time. */
+            scp->weight = has_extratime ? scp->extratime : sci.extratime;
+            scp->period = 0;
+        }
+        if (has_period && has_slice)
             scp->weight = 0;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 17:12:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17:12: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 1ShOS6-0003SF-J8; Wed, 20 Jun 2012 17:12:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShOS5-0003S6-6n
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:12:21 +0000
Received: from [193.109.254.147:63138] by server-6.bemta-14.messagelabs.com id
	37/2D-08993-47402EF4; Wed, 20 Jun 2012 17:12:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340212339!8329193!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 20 Jun 2012 17:12:19 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 17:12:19 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79021134; Wed, 20 Jun 2012 19:12:19 +0200
Message-ID: <1340212332.20225.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 19:12:12 +0200
In-Reply-To: <20449.60686.870961.578671@mariner.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
	<20449.54129.523732.173929@mariner.uk.xensource.com>
	<1340200879.20225.11.camel@Solace>
	<20449.60686.870961.578671@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6584221254643905027=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6584221254643905027==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-XySzu4peFZzD7o8xCmAm"


--=-XySzu4peFZzD7o8xCmAm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 16:32 +0100, Ian Jackson wrote:
> > Which means it might be unrelated from that specific commit (sorry if
> > it's a stupid question, just want to be sure I'm getting things
> > correct :-/ )
>=20
> No.  If it fails with 9d1fd58ff602 and succeeds with 32034d1914a6 then
> 9d1fd58ff602 is responsible because 32034d1914a6 is the only parent of
> 9d1fd58ff602.
>=20
I see.

> Flights 13095, 13102 and 13105 used code built from from 9d1fd58ff602
> and failed.  These all used the builds from flight 13033, which was
> another bisector run.
>=20
> It is possible that the build in 13033 is broken somehow.
>
Well, I couldn't say how that change could affect a non-sedf run
otherwise! :-(

Let's see what future flights will tell us...

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-XySzu4peFZzD7o8xCmAm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/iBGwACgkQk4XaBE3IOsRVnwCgmWsimsEv8+4YDjJp/tN+8fCe
bcIAnRCEwubyDxX3mj5u/A7f1ubS+qxo
=13Cq
-----END PGP SIGNATURE-----

--=-XySzu4peFZzD7o8xCmAm--



--===============6584221254643905027==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6584221254643905027==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 17:12:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17:12: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 1ShOS6-0003SF-J8; Wed, 20 Jun 2012 17:12:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShOS5-0003S6-6n
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:12:21 +0000
Received: from [193.109.254.147:63138] by server-6.bemta-14.messagelabs.com id
	37/2D-08993-47402EF4; Wed, 20 Jun 2012 17:12:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340212339!8329193!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19911 invoked from network); 20 Jun 2012 17:12:19 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Jun 2012 17:12:19 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79021134; Wed, 20 Jun 2012 19:12:19 +0200
Message-ID: <1340212332.20225.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 20 Jun 2012 19:12:12 +0200
In-Reply-To: <20449.60686.870961.578671@mariner.uk.xensource.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
	<1340183168.4906.8.camel@zakaz.uk.xensource.com>
	<20449.54129.523732.173929@mariner.uk.xensource.com>
	<1340200879.20225.11.camel@Solace>
	<20449.60686.870961.578671@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6584221254643905027=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6584221254643905027==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-XySzu4peFZzD7o8xCmAm"


--=-XySzu4peFZzD7o8xCmAm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 16:32 +0100, Ian Jackson wrote:
> > Which means it might be unrelated from that specific commit (sorry if
> > it's a stupid question, just want to be sure I'm getting things
> > correct :-/ )
>=20
> No.  If it fails with 9d1fd58ff602 and succeeds with 32034d1914a6 then
> 9d1fd58ff602 is responsible because 32034d1914a6 is the only parent of
> 9d1fd58ff602.
>=20
I see.

> Flights 13095, 13102 and 13105 used code built from from 9d1fd58ff602
> and failed.  These all used the builds from flight 13033, which was
> another bisector run.
>=20
> It is possible that the build in 13033 is broken somehow.
>
Well, I couldn't say how that change could affect a non-sedf run
otherwise! :-(

Let's see what future flights will tell us...

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-XySzu4peFZzD7o8xCmAm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/iBGwACgkQk4XaBE3IOsRVnwCgmWsimsEv8+4YDjJp/tN+8fCe
bcIAnRCEwubyDxX3mj5u/A7f1ubS+qxo
=13Cq
-----END PGP SIGNATURE-----

--=-XySzu4peFZzD7o8xCmAm--



--===============6584221254643905027==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6584221254643905027==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 17:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShOXs-00042P-O0; Wed, 20 Jun 2012 17:18:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShOXq-000423-Vl
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:18:19 +0000
Received: from [85.158.143.35:31057] by server-1.bemta-4.messagelabs.com id
	EE/03-24392-AD502EF4; Wed, 20 Jun 2012 17:18:18 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340212697!10121696!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5544 invoked from network); 20 Jun 2012 17:18:17 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 17:18:17 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79021219; Wed, 20 Jun 2012 19:18:17 +0200
Message-ID: <1340212691.20225.19.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 19:18:11 +0200
In-Reply-To: <4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8130890186397400921=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8130890186397400921==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-pxJ56hlMJ7IL1URqjHJv"


--=-pxJ56hlMJ7IL1URqjHJv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 08:51 +0100, Jan Beulich wrote:
> >>> On 20.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-amd64-xl-win7-amd64
> > test windows-install
> >=20
> > 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/staging/xen-unstable.hg=20
> >=20
> > *** Found and reproduced problem changeset ***
> >=20
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg=
=20
> >   Bug introduced:  9d1fd58ff602
> >   Bug not present: 32034d1914a6
> >=20
> >=20
> >   changeset:   25468:9d1fd58ff602
> >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> >   date:        Fri Jun 08 15:26:01 2012 +0100
> >      =20
> >       xl: check for meaningful combination of sedf config file paramete=
rs
>=20
Ok, this was causing a bug at least in *-sedf-* related tes runs, for
which I just sent a fix (<cbd6b5a7d0451a98a8c6.1340212196@Solace>,
[PATCH] xl: fix sedf parameters checking).

Basically, when not specifying explicitly the sedf scheduling
parameters, one couldn't even start a new domain.

I'd swear I tested that case, even more than once, but I apparently am
wrong. :-(

Anyway, sorry for both that and not noticing this sooner. As soon as
we'll have the fix committed (provided you like it) we can see what
happens to both the -sedf and non -sedf runs in future flights. I know
the bisector is something to be trusted, but I really hope to see the
issue for non -sedf cases to be caused by something else, as I can't
reproduce it and neither I can see how that could happen. :-O

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-pxJ56hlMJ7IL1URqjHJv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/iBdMACgkQk4XaBE3IOsSQ6QCgizdqV9vClirak92nHmxkgGiA
A8oAnjt2D2ympmk9s1utzxWxR7VKzcGs
=aUkS
-----END PGP SIGNATURE-----

--=-pxJ56hlMJ7IL1URqjHJv--



--===============8130890186397400921==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8130890186397400921==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 17:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShOXs-00042P-O0; Wed, 20 Jun 2012 17:18:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShOXq-000423-Vl
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:18:19 +0000
Received: from [85.158.143.35:31057] by server-1.bemta-4.messagelabs.com id
	EE/03-24392-AD502EF4; Wed, 20 Jun 2012 17:18:18 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340212697!10121696!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5544 invoked from network); 20 Jun 2012 17:18:17 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	20 Jun 2012 17:18:17 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79021219; Wed, 20 Jun 2012 19:18:17 +0200
Message-ID: <1340212691.20225.19.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 20 Jun 2012 19:18:11 +0200
In-Reply-To: <4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
References: <E1ShAqS-0008GB-H9@woking.cam.xci-test.com>
	<4FE19D1B020000780008ABDB@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: keir@xen.org, xen-devel <xen-devel@lists.xen.org>,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8130890186397400921=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8130890186397400921==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-pxJ56hlMJ7IL1URqjHJv"


--=-pxJ56hlMJ7IL1URqjHJv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-20 at 08:51 +0100, Jan Beulich wrote:
> >>> On 20.06.12 at 04:40, xen.org <ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-amd64-xl-win7-amd64
> > test windows-install
> >=20
> > 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/staging/xen-unstable.hg=20
> >=20
> > *** Found and reproduced problem changeset ***
> >=20
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg=
=20
> >   Bug introduced:  9d1fd58ff602
> >   Bug not present: 32034d1914a6
> >=20
> >=20
> >   changeset:   25468:9d1fd58ff602
> >   user:        Dario Faggioli <dario.faggioli@citrix.com>
> >   date:        Fri Jun 08 15:26:01 2012 +0100
> >      =20
> >       xl: check for meaningful combination of sedf config file paramete=
rs
>=20
Ok, this was causing a bug at least in *-sedf-* related tes runs, for
which I just sent a fix (<cbd6b5a7d0451a98a8c6.1340212196@Solace>,
[PATCH] xl: fix sedf parameters checking).

Basically, when not specifying explicitly the sedf scheduling
parameters, one couldn't even start a new domain.

I'd swear I tested that case, even more than once, but I apparently am
wrong. :-(

Anyway, sorry for both that and not noticing this sooner. As soon as
we'll have the fix committed (provided you like it) we can see what
happens to both the -sedf and non -sedf runs in future flights. I know
the bisector is something to be trusted, but I really hope to see the
issue for non -sedf cases to be caused by something else, as I can't
reproduce it and neither I can see how that could happen. :-O

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-pxJ56hlMJ7IL1URqjHJv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/iBdMACgkQk4XaBE3IOsSQ6QCgizdqV9vClirak92nHmxkgGiA
A8oAnjt2D2ympmk9s1utzxWxR7VKzcGs
=aUkS
-----END PGP SIGNATURE-----

--=-pxJ56hlMJ7IL1URqjHJv--



--===============8130890186397400921==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8130890186397400921==--



From xen-devel-bounces@lists.xen.org Wed Jun 20 17:51:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17: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 1ShP3F-0004m4-Su; Wed, 20 Jun 2012 17:50:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1ShP3E-0004lw-MZ
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:50:44 +0000
Received: from [85.158.143.99:59908] by server-1.bemta-4.messagelabs.com id
	C6/0B-24392-37D02EF4; Wed, 20 Jun 2012 17:50:43 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340214638!27746458!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTkzNTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27661 invoked from network); 20 Jun 2012 17:50:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 17:50:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5KHoUfN015395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Jun 2012 17:50:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5KHoT9s013083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 17:50:29 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q5KHoSSV021170; Wed, 20 Jun 2012 12:50:28 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Jun 2012 10:50:28 -0700
Message-ID: <4FE20E27.8000108@oracle.com>
Date: Wed, 20 Jun 2012 13:53:43 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340206463.4906.72.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/20/2012 11:34 AM, Ian Campbell wrote:
> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
>> # HG changeset patch
>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
>> # Date 1339608534 14400
>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
>> tools/hotplug: fix locking
> A better title would be "tools/hotplug: Switch to locking with flock"
> since "fix" is not very descriptive.
Agree.
>
> The commit message should also state why changing this scheme is
> preferable to fixing the current one.
I have two points:

1. No timeout: in the old one, if one process holding the lock more than 100
   seconds, other processes could steal it.
2. No leftovers: if a process holding this lock is dead, it will close the lock
   file, so it will not affect other processes.

>
> Is this flock tool widely available? Does it need to be added to the
> dependencies in the README?
It is widely distributed: it's part of the util-linux package. So I think no
need to document it.
>
>> The current locking implementation would allow two processes get the lock
>> simultaneously:
> [...snip shell trace...]
>
> Can you add a line or two of analysis to explain where in that shell
> spew things are actually going wrong and why?
I didn't spent much time on this complicated implement. But it fails for me and
also for others (from response).
>
>> This patch is ported from Red Hat Enterprise Linux 5.8.
> I think we need a Signed-off-by from the original patch author. (Unless
> DCO clause b somehow applies?)
I'm not sure how to handle this. There's no signed-off-by on the original Red
Hat patch. Could anyone in Red Hat help to get it signed off?

Thanks,

Zhigang
>
>
> Thanks,
> Ian.
>
>> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
>> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
>>
>> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
>> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
>> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
>> @@ -1,5 +1,6 @@
>>  #
>>  # Copyright (c) 2005 XenSource Ltd.
>> +# Copyright (c) 2007 Red Hat
>>  #
>>  # This library is free software; you can redistribute it and/or
>>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
>> @@ -19,92 +20,30 @@
>>  # Serialisation
>>  #
>>  
>> -LOCK_SLEEPTIME=1
>> -LOCK_SPINNING_RETRIES=5
>> -LOCK_RETRIES=100
>>  LOCK_BASEDIR=/var/run/xen-hotplug
>>  
>> +_setlockfd()
>> +{
>> +    local i
>> +    for ((i = 0; i < ${#_lockdict}; i++))
>> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
>> +    done
>> +    _lockdict[$i]="$1"
>> +    let _lockfd=200+i
>> +}
>> +
>>  
>>  claim_lock()
>>  {
>> -  local lockdir="$LOCK_BASEDIR/$1"
>> -  mkdir -p "$LOCK_BASEDIR"
>> -  _claim_lock "$lockdir"
>> +    mkdir -p "$LOCK_BASEDIR"
>> +    _setlockfd $1
>> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
>> +    flock -x $_lockfd
>>  }
>>  
>>
>>  release_lock()
>>  {
>> -  _release_lock "$LOCK_BASEDIR/$1"
>> +    _setlockfd $1
>> +    flock -u $_lockfd
>>  }
>> -
>> -
>> -# This function will be redefined in xen-hotplug-common.sh.
>> -sigerr() {
>> -  exit 1
>> -}
>> -
>> -
>> -_claim_lock()
>> -{
>> -  local lockdir="$1"
>> -  local owner=$(_lock_owner "$lockdir")
>> -  local retries=0
>> -
>> -  while [ $retries -lt $LOCK_RETRIES ]
>> -  do
>> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
>> -      _update_lock_info "$lockdir" && return
>> -
>> -    local new_owner=$(_lock_owner "$lockdir")
>> -    if [ "$new_owner" != "$owner" ]
>> -    then
>> -      owner="$new_owner"
>> -      retries=0
>> -    else
>> -      local pid=$(echo $owner | cut -d : -f 1)
>> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
>> -      then
>> -        _release_lock $lockdir
>> -      fi
>> -    fi
>> -
>> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>> -    then
>> -      sleep $LOCK_SLEEPTIME
>> -    else
>> -      sleep 0
>> -    fi
>> -    retries=$(($retries + 1))
>> -  done
>> -  _steal_lock "$lockdir"
>> -}
>> -
>> -
>> -_release_lock()
>> -{
>> -  trap sigerr ERR
>> -  rm -rf "$1" 2>/dev/null || true
>> -}
>> -
>> -
>> -_steal_lock()
>> -{
>> -  local lockdir="$1"
>> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
>> -  log err "Forced to steal lock on $lockdir from $owner!"
>> -  _release_lock "$lockdir"
>> -  _claim_lock "$lockdir"
>> -}
>> -
>> -
>> -_lock_owner()
>> -{
>> -  cat "$1/owner" 2>/dev/null || echo "unknown"
>> -}
>> -
>> -
>> -_update_lock_info()
>> -{
>> -  echo "$$: $0" >"$1/owner"
>> -}
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Wed Jun 20 17:51:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 17: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 1ShP3F-0004m4-Su; Wed, 20 Jun 2012 17:50:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1ShP3E-0004lw-MZ
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 17:50:44 +0000
Received: from [85.158.143.99:59908] by server-1.bemta-4.messagelabs.com id
	C6/0B-24392-37D02EF4; Wed, 20 Jun 2012 17:50:43 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340214638!27746458!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTkzNTMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27661 invoked from network); 20 Jun 2012 17:50:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jun 2012 17:50:43 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5KHoUfN015395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Jun 2012 17:50:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5KHoT9s013083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2012 17:50:29 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q5KHoSSV021170; Wed, 20 Jun 2012 12:50:28 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Jun 2012 10:50:28 -0700
Message-ID: <4FE20E27.8000108@oracle.com>
Date: Wed, 20 Jun 2012 13:53:43 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340206463.4906.72.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/20/2012 11:34 AM, Ian Campbell wrote:
> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
>> # HG changeset patch
>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
>> # Date 1339608534 14400
>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
>> tools/hotplug: fix locking
> A better title would be "tools/hotplug: Switch to locking with flock"
> since "fix" is not very descriptive.
Agree.
>
> The commit message should also state why changing this scheme is
> preferable to fixing the current one.
I have two points:

1. No timeout: in the old one, if one process holding the lock more than 100
   seconds, other processes could steal it.
2. No leftovers: if a process holding this lock is dead, it will close the lock
   file, so it will not affect other processes.

>
> Is this flock tool widely available? Does it need to be added to the
> dependencies in the README?
It is widely distributed: it's part of the util-linux package. So I think no
need to document it.
>
>> The current locking implementation would allow two processes get the lock
>> simultaneously:
> [...snip shell trace...]
>
> Can you add a line or two of analysis to explain where in that shell
> spew things are actually going wrong and why?
I didn't spent much time on this complicated implement. But it fails for me and
also for others (from response).
>
>> This patch is ported from Red Hat Enterprise Linux 5.8.
> I think we need a Signed-off-by from the original patch author. (Unless
> DCO clause b somehow applies?)
I'm not sure how to handle this. There's no signed-off-by on the original Red
Hat patch. Could anyone in Red Hat help to get it signed off?

Thanks,

Zhigang
>
>
> Thanks,
> Ian.
>
>> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
>> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
>>
>> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
>> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
>> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
>> @@ -1,5 +1,6 @@
>>  #
>>  # Copyright (c) 2005 XenSource Ltd.
>> +# Copyright (c) 2007 Red Hat
>>  #
>>  # This library is free software; you can redistribute it and/or
>>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
>> @@ -19,92 +20,30 @@
>>  # Serialisation
>>  #
>>  
>> -LOCK_SLEEPTIME=1
>> -LOCK_SPINNING_RETRIES=5
>> -LOCK_RETRIES=100
>>  LOCK_BASEDIR=/var/run/xen-hotplug
>>  
>> +_setlockfd()
>> +{
>> +    local i
>> +    for ((i = 0; i < ${#_lockdict}; i++))
>> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
>> +    done
>> +    _lockdict[$i]="$1"
>> +    let _lockfd=200+i
>> +}
>> +
>>  
>>  claim_lock()
>>  {
>> -  local lockdir="$LOCK_BASEDIR/$1"
>> -  mkdir -p "$LOCK_BASEDIR"
>> -  _claim_lock "$lockdir"
>> +    mkdir -p "$LOCK_BASEDIR"
>> +    _setlockfd $1
>> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
>> +    flock -x $_lockfd
>>  }
>>  
>>
>>  release_lock()
>>  {
>> -  _release_lock "$LOCK_BASEDIR/$1"
>> +    _setlockfd $1
>> +    flock -u $_lockfd
>>  }
>> -
>> -
>> -# This function will be redefined in xen-hotplug-common.sh.
>> -sigerr() {
>> -  exit 1
>> -}
>> -
>> -
>> -_claim_lock()
>> -{
>> -  local lockdir="$1"
>> -  local owner=$(_lock_owner "$lockdir")
>> -  local retries=0
>> -
>> -  while [ $retries -lt $LOCK_RETRIES ]
>> -  do
>> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
>> -      _update_lock_info "$lockdir" && return
>> -
>> -    local new_owner=$(_lock_owner "$lockdir")
>> -    if [ "$new_owner" != "$owner" ]
>> -    then
>> -      owner="$new_owner"
>> -      retries=0
>> -    else
>> -      local pid=$(echo $owner | cut -d : -f 1)
>> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
>> -      then
>> -        _release_lock $lockdir
>> -      fi
>> -    fi
>> -
>> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
>> -    then
>> -      sleep $LOCK_SLEEPTIME
>> -    else
>> -      sleep 0
>> -    fi
>> -    retries=$(($retries + 1))
>> -  done
>> -  _steal_lock "$lockdir"
>> -}
>> -
>> -
>> -_release_lock()
>> -{
>> -  trap sigerr ERR
>> -  rm -rf "$1" 2>/dev/null || true
>> -}
>> -
>> -
>> -_steal_lock()
>> -{
>> -  local lockdir="$1"
>> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
>> -  log err "Forced to steal lock on $lockdir from $owner!"
>> -  _release_lock "$lockdir"
>> -  _claim_lock "$lockdir"
>> -}
>> -
>> -
>> -_lock_owner()
>> -{
>> -  cat "$1/owner" 2>/dev/null || echo "unknown"
>> -}
>> -
>> -
>> -_update_lock_info()
>> -{
>> -  echo "$$: $0" >"$1/owner"
>> -}
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Wed Jun 20 18:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 18: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 1ShPTD-00058T-6F; Wed, 20 Jun 2012 18:17:35 +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 1ShPTB-00058O-NM
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 18:17:33 +0000
Received: from [85.158.138.51:36849] by server-9.bemta-3.messagelabs.com id
	1C/66-10419-CB312EF4; Wed, 20 Jun 2012 18:17:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340216249!25797637!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30513 invoked from network); 20 Jun 2012 18:17:32 -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 Jun 2012 18:17:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336363200"; d="scan'208";a="199461741"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 14:17:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:17:04 -0400
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 1ShPRa-0006YO-V6;
	Wed, 20 Jun 2012 19:15:54 +0100
Message-ID: <4FE2135A.3010602@citrix.com>
Date: Wed, 20 Jun 2012 19:15:54 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CC04F646.431E2%keir@xen.org>
In-Reply-To: <CC04F646.431E2%keir@xen.org>
X-Enigmail-Version: 1.4.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
 and 4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/06/12 15:14, Keir Fraser wrote:
> Folks,
>
> I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:
>
> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)
>
> Please test!
>
>  -- Keir

Can I recommend for backport:

23940:187d59e32a58 - ocaml/stubs: Bugfixes for console ring and vcpu
affinities
25271:54da0329e259 - x86_64: Fix off-by-one errors for Interrupt Stack
Tables
25478:6d1a30dc47e8 - x86/nmi: Fix deadlock in unknown_nmi_error() (when
it passes through staging)

They all appear to apply cleanly to 4.1, and I am not aware of them
having any other dependencies.

>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 18:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 18: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 1ShPTD-00058T-6F; Wed, 20 Jun 2012 18:17:35 +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 1ShPTB-00058O-NM
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 18:17:33 +0000
Received: from [85.158.138.51:36849] by server-9.bemta-3.messagelabs.com id
	1C/66-10419-CB312EF4; Wed, 20 Jun 2012 18:17:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340216249!25797637!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjA2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30513 invoked from network); 20 Jun 2012 18:17:32 -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 Jun 2012 18:17:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336363200"; d="scan'208";a="199461741"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 14:17:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 14:17:04 -0400
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 1ShPRa-0006YO-V6;
	Wed, 20 Jun 2012 19:15:54 +0100
Message-ID: <4FE2135A.3010602@citrix.com>
Date: Wed, 20 Jun 2012 19:15:54 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CC04F646.431E2%keir@xen.org>
In-Reply-To: <CC04F646.431E2%keir@xen.org>
X-Enigmail-Version: 1.4.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Second release candidates for Xen 4.0.4
 and 4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/06/12 15:14, Keir Fraser wrote:
> Folks,
>
> I have just tagged 2nd release candidates for 4.0.4 and 4.1.3:
>
> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc2)
> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc2)
>
> Please test!
>
>  -- Keir

Can I recommend for backport:

23940:187d59e32a58 - ocaml/stubs: Bugfixes for console ring and vcpu
affinities
25271:54da0329e259 - x86_64: Fix off-by-one errors for Interrupt Stack
Tables
25478:6d1a30dc47e8 - x86/nmi: Fix deadlock in unknown_nmi_error() (when
it passes through staging)

They all appear to apply cleanly to 4.1, and I am not aware of them
having any other dependencies.

>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 18:28:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 18: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 1ShPdD-0005JW-9b; Wed, 20 Jun 2012 18:27:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShPdB-0005JR-Vi
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 18:27:54 +0000
Received: from [85.158.143.99:21388] by server-1.bemta-4.messagelabs.com id
	25/44-24392-92612EF4; Wed, 20 Jun 2012 18:27:53 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340216870!20618891!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzQ3OTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14058 invoked from network); 20 Jun 2012 18:27:52 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 18:27:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340216872; x=1371752872;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=xkGaCT0Id8g4hbemS2Pa3VCMk6iCmp7WJhlIp2gYhZM=;
	b=XRd0ipkVRgKk/VSbUk5motf+kjYIJ6V6j9HKH5Xij8dx5H+57tNN61UX
	dX/s6wHkuIZrxZH0xe4FVtLtSd8Inw==;
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="251598926"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 18:27:49 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.56])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5KIRlrY025388; Wed, 20 Jun 2012 18:27:47 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 20 Jun 2012 11:27:42 -0700
Date: Wed, 20 Jun 2012 11:27:42 -0700
From: Matt Wilson <msw@amazon.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120620182742.GC2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com>
	<20120620164413.GB2640@US-SEA-R8XVZTX>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120620164413.GB2640@US-SEA-R8XVZTX>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 09:44:13AM -0700, Wilson, Matt wrote:
> On Wed, Jun 20, 2012 at 01:51:17AM -0700, Roger Pau Monne wrote:
> > Matt Wilson wrote:
> > > +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
> > 
> > I would prefer to set FSIMAGE_FSDIR or an equivalent define in 
> > tools/config.h and include that header in 
> > tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that 
> > value from the compiler command line.

It turns out to be tricky to do this, since you have to recursively
expand the value from libdir="${exec_prefix}/lib". Also, it's counter
to the generally accepted pattern for passing these types of variables
down when using autoconf, which actually is to use -D in CFLAGS.

See also this thread:
  http://stackoverflow.com/questions/5867136/autoconf-how-to-get-installation-paths-into-config-h

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 18:28:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 18: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 1ShPdD-0005JW-9b; Wed, 20 Jun 2012 18:27:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShPdB-0005JR-Vi
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 18:27:54 +0000
Received: from [85.158.143.99:21388] by server-1.bemta-4.messagelabs.com id
	25/44-24392-92612EF4; Wed, 20 Jun 2012 18:27:53 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340216870!20618891!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzQ3OTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14058 invoked from network); 20 Jun 2012 18:27:52 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 18:27:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340216872; x=1371752872;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=xkGaCT0Id8g4hbemS2Pa3VCMk6iCmp7WJhlIp2gYhZM=;
	b=XRd0ipkVRgKk/VSbUk5motf+kjYIJ6V6j9HKH5Xij8dx5H+57tNN61UX
	dX/s6wHkuIZrxZH0xe4FVtLtSd8Inw==;
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="251598926"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 18:27:49 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.56])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5KIRlrY025388; Wed, 20 Jun 2012 18:27:47 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Wed, 20 Jun 2012 11:27:42 -0700
Date: Wed, 20 Jun 2012 11:27:42 -0700
From: Matt Wilson <msw@amazon.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120620182742.GC2640@US-SEA-R8XVZTX>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com>
	<20120620164413.GB2640@US-SEA-R8XVZTX>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120620164413.GB2640@US-SEA-R8XVZTX>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 09:44:13AM -0700, Wilson, Matt wrote:
> On Wed, Jun 20, 2012 at 01:51:17AM -0700, Roger Pau Monne wrote:
> > Matt Wilson wrote:
> > > +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
> > 
> > I would prefer to set FSIMAGE_FSDIR or an equivalent define in 
> > tools/config.h and include that header in 
> > tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that 
> > value from the compiler command line.

It turns out to be tricky to do this, since you have to recursively
expand the value from libdir="${exec_prefix}/lib". Also, it's counter
to the generally accepted pattern for passing these types of variables
down when using autoconf, which actually is to use -D in CFLAGS.

See also this thread:
  http://stackoverflow.com/questions/5867136/autoconf-how-to-get-installation-paths-into-config-h

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 18:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 18: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 1ShPnt-0005Xf-EJ; Wed, 20 Jun 2012 18:38: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 1ShPnr-0005Xa-Rn
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 18:38:56 +0000
Received: from [85.158.143.35:6963] by server-2.bemta-4.messagelabs.com id
	C2/AB-17938-FB812EF4; Wed, 20 Jun 2012 18:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340217534!12905132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16397 invoked from network); 20 Jun 2012 18:38:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 18:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="13132257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 18:38:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 19:38:54 +0100
Message-ID: <1340217533.4998.3.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 20 Jun 2012 19:38:53 +0100
In-Reply-To: <CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sorry for the late response, I seem to have lost this reply on my desktop somewhere...

On Thu, 2012-06-07 at 03:34 +0100, ZhouPeng wrote:
> On Wed, Jun 6, 2012 at 7:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
> >>  # Complex libxl types
> >>  #
> >> +
> >> +libxl_vga_interface_info = Struct("vga_interface_info", [
> >> +    ("type",    libxl_vga_interface_type),
> >> +    ])
> >
> > Unfortunately "type" is a reserved word in ocaml (and possibly other
> > languages, which causes the bindings to fail to build:
> Thanks for your review.
> 
> I didn't build against ocaml.
> I 'make install' in tools/libxl directly.
> >        make[4]: Entering directory `/local/scratch/ianc/devel/committer.git/tools/ocaml/libs/xl'
> >         MLDEP
> >        File "xenlight.ml", line 116, characters 2-6:
> >        Error: Syntax error
> >         MLI      xenlight.cmi
> >        File "xenlight.mli", line 116, characters 2-6:
> >        Error: Syntax error: 'end' expected
> >        File "xenlight.mli", line 113, characters 28-31:
> >        Error: This 'sig' might be unmatched
> >
> > Ideally we'd make the bindings generator do appropriate substitutions on
> > keywords but the usual workaround is to s/type/kind for the field name.
> >
> > BTW, I wasn't going to bounce the patch over this but could
> 
> Sorry, I'm not farmiliar with the vocabulary  'bounce',
> do you mean s/type/kind is necessary or not?

Yes, it is necessary.

By "bounce" I meant ask you to resubmit. IOW I wasn't going to ask you
to resubmit over the LIBXL_VGA_INTERFACE_TYPE_DEFAULT part, but I
figured since you needed to fix the ocaml stuff I would mention it.

> I think you mean necessary, right?
> > LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
> > the type?
> do you mean this way below?
> libxl_vga_interface_type = Enumeration("vga_interface_type", [
>     (-1, "DEFAULT"),
>     (0, "CIRRUS"),
>     (1, "STD"),
>     ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
> 
> In my understanding, LIBXL_VGA_INTERFACE_TYPE_DEFAULT is not really
> a meaningful vga type (even not present default vga to use, but just tag the
> variable has never be initialized, so in meaningless state).
> It's only used to check if libxl_vga_interface_type var is
> initialized (whether stdvga setted by vm.cfg), to
> avoid random value initialized.

Actually, looking at the definition of libxl_vga_interface_type you
should avoid using 0 as a real thing and then this becomes
        libxl_vga_interface_type = Enumeration("vga_interface_type", [
        	(1, "CIRRUS"),
        	(2, "STD"),
        ])

Since the "default default" is 0 you can test for default just by
using !b_info.... here.

You'll notice that most other enums in the IDL have this property except
where the specific values come from elsewhere (like timer mode).

Several enums also include "UNKNOWN" as an explicit entry, which is much
the same as including "DEFAULT" IMHO.

> It's equal with LIBXL_MEMKB_DEFAULT in this context.

This is semantically a bit different to the enum case.

> It's the same with LIBXL_TIMER_MODE_DEFAULT

TIMER_MODE is not a good example to follow because the specific values
come from the hypervisor and libxl simple matches them.

> > I'm not sure why we don't do the same for
> > LIBXL_TIMER_MODE_DEFAULT already.
> >
> > Ian.
> >
> >
> >> +
> >>  libxl_vnc_info = Struct("vnc_info", [
> >>      ("enable",        libxl_defbool),
> >>      # "address:port" that should be listened on
> >> @@ -281,7 +291,7 @@ libxl_domain_build_info = Struct("domain
> >>                                         ("nested_hvm",       libxl_defbool),
> >>                                         ("incr_generationid",libxl_defbool),
> >>                                         ("nographic",        libxl_defbool),
> >> -                                       ("stdvga",           libxl_defbool),
> >> +                                       ("vga",
> >> libxl_vga_interface_info),
> >>                                         ("vnc",              libxl_vnc_info),
> >>                                         # keyboard layout, default is
> >> en-us keyboard
> >>                                         ("keymap",           string),
> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
> >> --- a/tools/libxl/xl_cmdimpl.c        Sat Jun 02 08:39:45 2012 +0100
> >> +++ b/tools/libxl/xl_cmdimpl.c        Tue Jun 05 17:39:37 2012 +0800
> >> @@ -1256,7 +1256,10 @@ skip_vfb:
> >>  #undef parse_extra_args
> >>
> >>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> >> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> >> +            if (l)
> >> +                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
> >> +
> >>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
> >>          xlu_cfg_replace_string (config, "vnclisten",
> >>                                  &b_info->u.hvm.vnc.listen, 0);
> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
> >> --- a/tools/libxl/xl_sxp.c    Sat Jun 02 08:39:45 2012 +0100
> >> +++ b/tools/libxl/xl_sxp.c    Tue Jun 05 17:39:37 2012 +0800
> >> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
> >>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
> >>          printf("\t\t\t(no_incr_generationid %s)\n",
> >>                 libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
> >> -        printf("\t\t\t(stdvga %s)\n",
> >> -               libxl_defbool_to_string(b_info->u.hvm.stdvga));
> >> +        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type ==
> >> +                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
> >> +                                      "True" : "False");
> >>          printf("\t\t\t(vnc %s)\n",
> >>                 libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
> >>          printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> >>
> >>
> >
> >
> 
> 
> 










_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 18:39:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 18: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 1ShPnt-0005Xf-EJ; Wed, 20 Jun 2012 18:38: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 1ShPnr-0005Xa-Rn
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 18:38:56 +0000
Received: from [85.158.143.35:6963] by server-2.bemta-4.messagelabs.com id
	C2/AB-17938-FB812EF4; Wed, 20 Jun 2012 18:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340217534!12905132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE1ODM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16397 invoked from network); 20 Jun 2012 18:38:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 18:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336348800"; d="scan'208";a="13132257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 18:38:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 19:38:54 +0100
Message-ID: <1340217533.4998.3.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 20 Jun 2012 19:38:53 +0100
In-Reply-To: <CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sorry for the late response, I seem to have lost this reply on my desktop somewhere...

On Thu, 2012-06-07 at 03:34 +0100, ZhouPeng wrote:
> On Wed, Jun 6, 2012 at 7:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
> >>  # Complex libxl types
> >>  #
> >> +
> >> +libxl_vga_interface_info = Struct("vga_interface_info", [
> >> +    ("type",    libxl_vga_interface_type),
> >> +    ])
> >
> > Unfortunately "type" is a reserved word in ocaml (and possibly other
> > languages, which causes the bindings to fail to build:
> Thanks for your review.
> 
> I didn't build against ocaml.
> I 'make install' in tools/libxl directly.
> >        make[4]: Entering directory `/local/scratch/ianc/devel/committer.git/tools/ocaml/libs/xl'
> >         MLDEP
> >        File "xenlight.ml", line 116, characters 2-6:
> >        Error: Syntax error
> >         MLI      xenlight.cmi
> >        File "xenlight.mli", line 116, characters 2-6:
> >        Error: Syntax error: 'end' expected
> >        File "xenlight.mli", line 113, characters 28-31:
> >        Error: This 'sig' might be unmatched
> >
> > Ideally we'd make the bindings generator do appropriate substitutions on
> > keywords but the usual workaround is to s/type/kind for the field name.
> >
> > BTW, I wasn't going to bounce the patch over this but could
> 
> Sorry, I'm not farmiliar with the vocabulary  'bounce',
> do you mean s/type/kind is necessary or not?

Yes, it is necessary.

By "bounce" I meant ask you to resubmit. IOW I wasn't going to ask you
to resubmit over the LIBXL_VGA_INTERFACE_TYPE_DEFAULT part, but I
figured since you needed to fix the ocaml stuff I would mention it.

> I think you mean necessary, right?
> > LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
> > the type?
> do you mean this way below?
> libxl_vga_interface_type = Enumeration("vga_interface_type", [
>     (-1, "DEFAULT"),
>     (0, "CIRRUS"),
>     (1, "STD"),
>     ], init_val = "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
> 
> In my understanding, LIBXL_VGA_INTERFACE_TYPE_DEFAULT is not really
> a meaningful vga type (even not present default vga to use, but just tag the
> variable has never be initialized, so in meaningless state).
> It's only used to check if libxl_vga_interface_type var is
> initialized (whether stdvga setted by vm.cfg), to
> avoid random value initialized.

Actually, looking at the definition of libxl_vga_interface_type you
should avoid using 0 as a real thing and then this becomes
        libxl_vga_interface_type = Enumeration("vga_interface_type", [
        	(1, "CIRRUS"),
        	(2, "STD"),
        ])

Since the "default default" is 0 you can test for default just by
using !b_info.... here.

You'll notice that most other enums in the IDL have this property except
where the specific values come from elsewhere (like timer mode).

Several enums also include "UNKNOWN" as an explicit entry, which is much
the same as including "DEFAULT" IMHO.

> It's equal with LIBXL_MEMKB_DEFAULT in this context.

This is semantically a bit different to the enum case.

> It's the same with LIBXL_TIMER_MODE_DEFAULT

TIMER_MODE is not a good example to follow because the specific values
come from the hypervisor and libxl simple matches them.

> > I'm not sure why we don't do the same for
> > LIBXL_TIMER_MODE_DEFAULT already.
> >
> > Ian.
> >
> >
> >> +
> >>  libxl_vnc_info = Struct("vnc_info", [
> >>      ("enable",        libxl_defbool),
> >>      # "address:port" that should be listened on
> >> @@ -281,7 +291,7 @@ libxl_domain_build_info = Struct("domain
> >>                                         ("nested_hvm",       libxl_defbool),
> >>                                         ("incr_generationid",libxl_defbool),
> >>                                         ("nographic",        libxl_defbool),
> >> -                                       ("stdvga",           libxl_defbool),
> >> +                                       ("vga",
> >> libxl_vga_interface_info),
> >>                                         ("vnc",              libxl_vnc_info),
> >>                                         # keyboard layout, default is
> >> en-us keyboard
> >>                                         ("keymap",           string),
> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
> >> --- a/tools/libxl/xl_cmdimpl.c        Sat Jun 02 08:39:45 2012 +0100
> >> +++ b/tools/libxl/xl_cmdimpl.c        Tue Jun 05 17:39:37 2012 +0800
> >> @@ -1256,7 +1256,10 @@ skip_vfb:
> >>  #undef parse_extra_args
> >>
> >>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> >> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> >> +            if (l)
> >> +                b_info->u.hvm.vga.type = LIBXL_VGA_INTERFACE_TYPE_STD;
> >> +
> >>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
> >>          xlu_cfg_replace_string (config, "vnclisten",
> >>                                  &b_info->u.hvm.vnc.listen, 0);
> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
> >> --- a/tools/libxl/xl_sxp.c    Sat Jun 02 08:39:45 2012 +0100
> >> +++ b/tools/libxl/xl_sxp.c    Tue Jun 05 17:39:37 2012 +0800
> >> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
> >>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
> >>          printf("\t\t\t(no_incr_generationid %s)\n",
> >>                 libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
> >> -        printf("\t\t\t(stdvga %s)\n",
> >> -               libxl_defbool_to_string(b_info->u.hvm.stdvga));
> >> +        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type ==
> >> +                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
> >> +                                      "True" : "False");
> >>          printf("\t\t\t(vnc %s)\n",
> >>                 libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
> >>          printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> >>
> >>
> >
> >
> 
> 
> 










_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 19:35:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 19:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShQgK-0006LN-IU; Wed, 20 Jun 2012 19:35:12 +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 1ShQgJ-0006LI-SF
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 19:35:12 +0000
Received: from [85.158.138.51:12220] by server-4.bemta-3.messagelabs.com id
	DD/7C-17105-FE522EF4; Wed, 20 Jun 2012 19:35:11 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340220908!28708079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11922 invoked from network); 20 Jun 2012 19:35:10 -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;
	20 Jun 2012 19:35:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336363200"; d="scan'208";a="28825478"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:35:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 15:35:06 -0400
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 1ShQb9-0000Ws-Qw;
	Wed, 20 Jun 2012 20:29:51 +0100
Message-ID: <4FE224AF.2060107@citrix.com>
Date: Wed, 20 Jun 2012 20:29:51 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>	<4FE1E718020000780008AD65@nat28.tlf.novell.com>
	<4FE1CDCD.4090009@citrix.com>
In-Reply-To: <4FE1CDCD.4090009@citrix.com>
X-Enigmail-Version: 1.4.2
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> I have not investigated yet as I am just wrapping up a more important
> issue, but the issue was a constant console spam saying no handler for
> vector 0xe5, which was causing the server to run like treacle.  The
> issue started occurring shortly after I backported c/s 25336 to
> XenServer, which is why I suspect it as the culprit.  Having said that,
> the patch appears to work fine on every other server we have, so I
> suspect its some motherboard quirk; it is a slightly old AMD box we
> have, and is 100% reproducible.  I am hoping to have time to start
> looking at the problem this afternoon.
>

After some investigation, it appears that the server in question is not
old (as the bug report I received said).  It appears to be a fairly-new
evaluation dual socket AMD box, with a beta-looking BIOS, which can't
reliably boot Xen 3.4 or Xen 4.1 (with or without the changeset), can't
reliably reboot via ACPI, and cant reliably turn back on after you cut
its power.

As such, I would say that the server is rather more suspect than Xen
4.2, so this IRQ issue should probably not be considered a blocker.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 19:35:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 19:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShQgK-0006LN-IU; Wed, 20 Jun 2012 19:35:12 +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 1ShQgJ-0006LI-SF
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 19:35:12 +0000
Received: from [85.158.138.51:12220] by server-4.bemta-3.messagelabs.com id
	DD/7C-17105-FE522EF4; Wed, 20 Jun 2012 19:35:11 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340220908!28708079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTE1NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11922 invoked from network); 20 Jun 2012 19:35:10 -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;
	20 Jun 2012 19:35:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,445,1336363200"; d="scan'208";a="28825478"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jun 2012 15:35:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 20 Jun 2012 15:35:06 -0400
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 1ShQb9-0000Ws-Qw;
	Wed, 20 Jun 2012 20:29:51 +0100
Message-ID: <4FE224AF.2060107@citrix.com>
Date: Wed, 20 Jun 2012 20:29:51 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>	<4FE1E718020000780008AD65@nat28.tlf.novell.com>
	<4FE1CDCD.4090009@citrix.com>
In-Reply-To: <4FE1CDCD.4090009@citrix.com>
X-Enigmail-Version: 1.4.2
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> I have not investigated yet as I am just wrapping up a more important
> issue, but the issue was a constant console spam saying no handler for
> vector 0xe5, which was causing the server to run like treacle.  The
> issue started occurring shortly after I backported c/s 25336 to
> XenServer, which is why I suspect it as the culprit.  Having said that,
> the patch appears to work fine on every other server we have, so I
> suspect its some motherboard quirk; it is a slightly old AMD box we
> have, and is 100% reproducible.  I am hoping to have time to start
> looking at the problem this afternoon.
>

After some investigation, it appears that the server in question is not
old (as the bug report I received said).  It appears to be a fairly-new
evaluation dual socket AMD box, with a beta-looking BIOS, which can't
reliably boot Xen 3.4 or Xen 4.1 (with or without the changeset), can't
reliably reboot via ACPI, and cant reliably turn back on after you cut
its power.

As such, I would say that the server is rather more suspect than Xen
4.2, so this IRQ issue should probably not be considered a blocker.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 22:17:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 22:17: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 1ShTCf-0007SQ-CZ; Wed, 20 Jun 2012 22:16:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1ShTCd-0007SL-Os
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 22:16:44 +0000
Received: from [85.158.143.99:31292] by server-2.bemta-4.messagelabs.com id
	82/68-17938-BCB42EF4; Wed, 20 Jun 2012 22:16:43 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340230600!28311085!1
X-Originating-IP: [209.85.217.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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6495 invoked from network); 20 Jun 2012 22:16:41 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 22:16:41 -0000
Received: by lbom4 with SMTP id m4so1572299lbo.30
	for <xen-devel@lists.xensource.com>;
	Wed, 20 Jun 2012 15:16:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=cirnp8b6EXzv3MI/AZyPRxvq8BoV6TYPh/o4lDzwIYA=;
	b=bI/u2WWMjJ+SZt9WNyoZgcJZ3CvALtpAGNNuFQZCrpqElPNPKe4LLVBbCMer1iDU0j
	/pZ5pWktbXXoLS/pVvOw1tBNkVBjZ0D5SPINfJPfgA8Sa0Ob2H7mHyVDKS3RAx97nKek
	gDYebHk2rYI6X7gdC86cVCX/HGfuftkqWPYwJ6rLZoJqfIXawaYQhwfyBZHE9AGc4OxM
	FbFZeVA4Zsl+gKfKoYrE2NZNaKrSqbo7yq/9J6x5EtVVxXVuwKqZkLgSv33L6o/4WGH3
	EW+vIS/6ktnxAHdNWkAaP+iiXWoOwM+klNB7yjeLvGgn/Qjs2eQeNqnuLn221F+4Xg4R
	plrQ==
MIME-Version: 1.0
Received: by 10.152.144.234 with SMTP id sp10mr24044979lab.51.1340230600255;
	Wed, 20 Jun 2012 15:16:40 -0700 (PDT)
Received: by 10.114.36.38 with HTTP; Wed, 20 Jun 2012 15:16:40 -0700 (PDT)
Date: Wed, 20 Jun 2012 18:16:40 -0400
Message-ID: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] 4.2-Unstable Crash/Reboot(i5 2500/DQ67SW)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7657866687548287553=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7657866687548287553==
Content-Type: multipart/alternative; boundary=e89a8f22bfb1d867a404c2eec0ea

--e89a8f22bfb1d867a404c2eec0ea
Content-Type: text/plain; charset=ISO-8859-1

Environment: Xen-4.2 Unstable - built about a week ago
             OS: Fedora 17
           CPU: i5 2500
Motherboard: DQ67SW latest bios

Trying to get passthrough working, 4.1.2 Bluescreens going into windows,
figured I probably needed some of the patches in 4.2, built it and it just
crashes and reboots. Installed a Serial card, got the terminal working and
was able to capture the crash. I have also included the dmidecode CPU and
BIOS from the normal Fedora 17 kernel(non-xen).

Please let me know if I can provide anything else.

=============================================
[root@xenzibar ~]# dmidecode --type bios
# dmidecode 2.11
SMBIOS 2.6 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Intel Corp.
Version: SWQ6710H.86A.0062.2012.0418.1112
Release Date: 04/18/2012
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported

===============================================
[root@xenzibar ~]# dmidecode --type processor
# dmidecode 2.11
SMBIOS 2.6 present.

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: SKTH
Type: Central Processor
Family: Core i5
Manufacturer: Intel(R) Corp.
ID: A7 06 02 00 FF FB EB BF
Signature: Type 0, Family 6, Model 42, Stepping 7
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
Voltage: 1.1 V
External Clock: 100 MHz
Max Speed: 3800 MHz
Current Speed: 3300 MHz
Status: Populated, Enabled
Upgrade: Socket BGA1155
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: 0x0007
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Part Number: To Be Filled By O.E.M.
Core Count: 4
Core Enabled: 4
Thread Count: 4
Characteristics:
64-bit capable

===================================================================

 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.2-unstable (root@) (gcc version 4.7.0 20120507 (Red Hat
4.72
(XEN) Latest ChangeSet: Thu Jun 07 19:46:57 2012 +0100 25467:32034d1914a6
(XEN) Bootloader: GRUB 2.00~beta4
(XEN) Command line: placeholder loglvl=all guest_loglvl=all
com1=19200,8n1,pci,a
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040000000 (usable)
(XEN)  0000000040000000 - 0000000040200000 (reserved)
(XEN)  0000000040200000 - 00000000ae854000 (usable)
(XEN)  00000000ae854000 - 00000000ae85d000 (ACPI data)
(XEN)  00000000ae85d000 - 00000000ae8a8000 (ACPI NVS)
(XEN)  00000000ae8a8000 - 00000000ae8b0000 (usable)
(XEN)  00000000ae8b0000 - 00000000ae9a4000 (reserved)
(XEN)  00000000ae9a4000 - 00000000ae9a6000 (usable)
(XEN)  00000000ae9a6000 - 00000000aebc5000 (reserved)
(XEN)  00000000aebc5000 - 00000000aebc6000 (usable)
(XEN)  00000000aebc6000 - 00000000aebd6000 (reserved)
(XEN)  00000000aebd6000 - 00000000aebf5000 (ACPI NVS)
(XEN)  00000000aebf5000 - 00000000aec19000 (reserved)
(XEN)  00000000aec19000 - 00000000aec5c000 (ACPI NVS)
(XEN)  00000000aec5c000 - 00000000aee7c000 (reserved)
(XEN)  00000000aee7c000 - 00000000af000000 (usable)
(XEN)  00000000af800000 - 00000000bfa00000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000043e600000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2  INTEL)
(XEN) ACPI: XSDT AE854070, 0064 (r1 INTEL  DQ67SW    1072009 AMI     10013)
(XEN) ACPI: FACP AE85BB50, 00F4 (r4 INTEL  DQ67SW    1072009 AMI     10013)
(XEN) ACPI: DSDT AE854168, 79E1 (r2 INTEL  DQ67SW         16 INTL 20051117)
(XEN) ACPI: FACS AEBDBF80, 0040
(XEN) ACPI: APIC AE85BC48, 0072 (r3 INTEL  DQ67SW    1072009 AMI     10013)
(XEN) ACPI: TCPA AE85BCC0, 0032 (r2 INTEL  DQ67SW          1 MSFT  1000013)
(XEN) ACPI: SSDT AE85BCF8, 0102 (r1 INTEL  DQ67SW          1 MSFT  3000001)
(XEN) ACPI: MCFG AE85BE00, 003C (r1 INTEL  DQ67SW    1072009 MSFT       97)
(XEN) ACPI: HPET AE85BE40, 0038 (r1 INTEL  DQ67SW    1072009 AMI.        4)
(XEN) ACPI: ASF! AE85BE78, 00A0 (r32 INTEL  DQ67SW          1 TFSM    F4240)
(XEN) ACPI: DMAR AE85BF18, 00E8 (r1 INTEL  DQ67SW          1 INTL        1)
(XEN) System RAM: 16075MB (16461300kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000043e600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fda30
(XEN) DMI 2.6 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 -
aebdbf80/0000000000000000, u2
(XEN) ACPI:                  wakeup_vec[aebdbf8c], 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[0x04] enabled)
(XEN) Processor #4 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 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) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3292.554 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0
extend0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 3f
(XEN) PCI: Not using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(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) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 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
(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=0xa8c000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0xde0e8
(XEN) elf_parse_binary: phdr: paddr=0x1cdf000 memsz=0x14440
(XEN) elf_parse_binary: phdr: paddr=0x1cf4000 memsz=0x6c3000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x23b7000
(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 = 0xffffffff81cf4200
(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        = 0xffffffff823b7000
(XEN)     virt_entry       = 0xffffffff81cf4200
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x23b7000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000420000000->0000000428000000 (3983123 pages to
be a)
(XEN)  Init. ramdisk: 000000043b8e8000->000000043e5ffa00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff823b7000
(XEN)  Init. ramdisk: ffffffff823b7000->ffffffff850cea00
(XEN)  Phys-Mach map: ffffffff850cf000->ffffffff86f89158
(XEN)  Start info:    ffffffff86f8a000->ffffffff86f8a4b4
(XEN)  Page tables:   ffffffff86f8b000->ffffffff86fc8000
(XEN)  Boot stack:    ffffffff86fc8000->ffffffff86fc9000
(XEN)  TOTAL:         ffffffff80000000->ffffffff87400000
(XEN)  ENTRY ADDRESS: ffffffff81cf4200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81a8c000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81cde0e8
(XEN) elf_load_binary: phdr 2 at 0xffffffff81cdf000 -> 0xffffffff81cf3440
(XEN) elf_load_binary: phdr 3 at 0xffffffff81cf4000 -> 0xffffffff81de0000
(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 Xe)
(XEN) Freed 232kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    4.034307] invalid opcode: 0000 [#1] SMP
[    4.034311] CPU 0
[    4.034312] Modules linked in:
[    4.034314]
[    4.034316] Pid: 0, comm: swapper Not tainted 3.4.0-1.fc17.x86_64 #1
   W
[    4.034320] RIP: e030:[<ffffffff8101d777>]  [<ffffffff8101d777>]
xstate_enab0
[    4.034326] RSP: e02b:ffffffff81c01e48  EFLAGS: 00010046
[    4.034328] RAX: 0000000000000007 RBX: ffffffff81c01e80 RCX:
0000000000000000
[    4.034330] RDX: 0000000000000000 RSI: 0000000000000007 RDI:
0000000000002660
[    4.034332] RBP: ffffffff81c01e48 R08: aaaaaaaaaaaaaaaa R09:
ffffffff81c01e80
[    4.034333] R10: ffffffff81c01e84 R11: 00000000ffffffff R12:
ffffffff81c01e84
[    4.034335] R13: ffffffff81c01e7c R14: ffffffff81c01e78 R15:
ffffffff81c13020
[    4.034339] FS:  0000000000000000(0000) GS:ffff8803d6e00000(0000)
knlGS:00000
[    4.034341] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    4.034343] CR2: 0000000000000000 CR3: 0000000001c0b000 CR4:
0000000000002660
[    4.034345] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    4.034347] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[    4.034349] Process swapper (pid: 0, threadinfo ffffffff81c00000, task
fffff)
[    4.034351] Stack:
[    4.034352]  ffffffff81c01ec8 ffffffff81cfcce2 ffff8803d6e0b110
000000008005b
[    4.034356]  0000000080050033 ffffffff81c13020 0000024000000007
0000000000000
[    4.034359]  ffff8803d6e0b110 ffff8803d6e0b910 ffff8803d6e0b110
0000000000008
[    4.034363] Call Trace:
[    4.034368]  [<ffffffff81cfcce2>] xstate_enable_boot_cpu+0xa9/0x26d
[    4.034371]  [<ffffffff815da82b>] xsave_init+0x26/0x28
[    4.034374]  [<ffffffff815dca8f>] cpu_init+0x2ea/0x307
[    4.034377]  [<ffffffff81cf92cb>] trap_init+0x173/0x1e8
[    4.034379]  [<ffffffff81cf4a3f>] start_kernel+0x1dc/0x3c4
[    4.034382]  [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
[    4.034384]  [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
[    4.034387]  [<ffffffff81cf7101>] xen_start_kernel+0x58c/0x593
[    4.034388] Code: 48 89 e5 ff 14 25 10 da c1 81 48 89 c7 48 81 cf 00 00
04 0
[    4.034415] RIP  [<ffffffff8101d777>] xstate_enable+0x37/0x40
[    4.034417]  RSP <ffffffff81c01e48>
[    4.034424] ---[ end trace a7919e7f17c0a725 ]---
[    4.034426] Kernel panic - not syncing: Attempted to kill the idle task!
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
================================================================================

Thanks in advance for your assistance.
Paul

--e89a8f22bfb1d867a404c2eec0ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Environment: Xen-4.2 Unstable - built about a week ago<div>=A0 =A0 =A0 =A0 =
=A0 =A0 =A0OS: Fedora 17=A0</div><div>=A0 =A0 =A0 =A0 =A0 =A0CPU: i5 2500</=
div><div>Motherboard: DQ67SW latest bios</div><div><br></div><div>Trying to=
 get passthrough working, 4.1.2 Bluescreens going into windows, figured I p=
robably needed some of the patches in 4.2, built it and it just crashes and=
 reboots. Installed a Serial card, got the terminal working and was able to=
 capture the crash. I have also included the dmidecode CPU and BIOS from th=
e normal Fedora 17 kernel(non-xen).=A0</div>
<div><br></div><div>Please let me know if I can provide anything else.</div=
><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D</div><div><div>[root@xenzibar ~]# dmidecode --type bios</div><div># =
dmidecode 2.11</div>
<div>SMBIOS 2.6 present.</div><div><br></div><div>Handle 0x0000, DMI type 0=
, 24 bytes</div><div>BIOS Information</div><div><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre">	</span>Vendor: Intel Corp.</div><div><span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Version: SWQ6710H=
.86A.0062.2012.0418.1112</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Relea=
se Date: 04/18/2012</div><div><span class=3D"Apple-tab-span" style=3D"white=
-space:pre">	</span>Address: 0xF0000</div><div><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre">	</span>Runtime Size: 64 kB</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>ROM S=
ize: 1024 kB</div><div><span class=3D"Apple-tab-span" style=3D"white-space:=
pre">	</span>Characteristics:</div><div><span class=3D"Apple-tab-span" styl=
e=3D"white-space:pre">		</span>PCI is supported</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>BIOS=
 is upgradeable</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre">		</span>BIOS shadowing is allowed</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre">		</span>Boot from CD is supported</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>Sele=
ctable boot is supported</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre">		</span>BIOS ROM is socketed</div><div><span class=3D"App=
le-tab-span" style=3D"white-space:pre">		</span>EDD is supported</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>5.25=
&quot;/1.2 MB floppy services are supported (int 13h)</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>3.5&quot;/720 kB flo=
ppy services are supported (int 13h)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>3.5&=
quot;/2.88 MB floppy services are supported (int 13h)</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>Print screen service=
 is supported (int 5h)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>8042=
 keyboard services are supported (int 9h)</div><div><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre">		</span>Serial services are supported (i=
nt 14h)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>Prin=
ter services are supported (int 17h)</div><div><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre">		</span>ACPI is supported</div><div><span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre">		</span>USB legacy is supp=
orted</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>BIOS=
 boot specification is supported</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">		</span>Targeted content distribution is supporte=
d</div>
<div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D</div><div>[root@xenzibar ~]# dmidecode --type processor</div><=
div># dmidecode 2.11</div><div>SMBIOS 2.6 present.</div><div><br></div><div=
>Handle 0x0004, DMI type 4, 42 bytes</div>
<div>Processor Information</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">	</span>Socket Designation: SKTH</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Type: Central Process=
or</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Famil=
y: Core i5</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pr=
e">	</span>Manufacturer: Intel(R) Corp.</div><div><span class=3D"Apple-tab-=
span" style=3D"white-space:pre">	</span>ID: A7 06 02 00 FF FB EB BF</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Signa=
ture: Type 0, Family 6, Model 42, Stepping 7</div><div><span class=3D"Apple=
-tab-span" style=3D"white-space:pre">	</span>Flags:</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>FPU (Floating-point =
unit on-chip)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>VME =
(Virtual mode extension)</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre">		</span>DE (Debugging extension)</div><div><span class=3D=
"Apple-tab-span" style=3D"white-space:pre">		</span>PSE (Page size extensio=
n)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>TSC =
(Time stamp counter)</div><div><span class=3D"Apple-tab-span" style=3D"whit=
e-space:pre">		</span>MSR (Model specific registers)</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>PAE (Physical addres=
s extension)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>MCE =
(Machine check exception)</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre">		</span>CX8 (CMPXCHG8 instruction supported)</div><div><=
span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>APIC (On-c=
hip APIC hardware supported)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>SEP =
(Fast system call)</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">		</span>MTRR (Memory type range registers)</div><div><span clas=
s=3D"Apple-tab-span" style=3D"white-space:pre">		</span>PGE (Page global en=
able)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>MCA =
(Machine check architecture)</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">		</span>CMOV (Conditional move instruction supported)=
</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>PAT =
(Page attribute table)</div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre">		</span>PSE-36 (36-bit page size extension)</div><div><span=
 class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>CLFSH (CLFLUSH=
 instruction supported)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>DS (=
Debug store)</div><div><span class=3D"Apple-tab-span" style=3D"white-space:=
pre">		</span>ACPI (ACPI supported)</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre">		</span>MMX (MMX technology supported)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>FXSR=
 (FXSAVE and FXSTOR instructions supported)</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre">		</span>SSE (Streaming SIMD extensions=
)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>SSE2=
 (Streaming SIMD extensions 2)</div><div><span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre">		</span>SS (Self-snoop)</div><div><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre">		</span>HTT (Multi-threading)</div=
>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>TM (=
Thermal monitor supported)</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">		</span>PBE (Pending break enabled)</div><div><span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Version: Intel(R)=
 Core(TM) i5-2500 CPU @ 3.30GHz</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Volta=
ge: 1.1 V</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre=
">	</span>External Clock: 100 MHz</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Max Speed: 3800 MHz</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Curre=
nt Speed: 3300 MHz</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">	</span>Status: Populated, Enabled</div><div><span class=3D"Appl=
e-tab-span" style=3D"white-space:pre">	</span>Upgrade: Socket BGA1155</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>L1 Ca=
che Handle: 0x0005</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">	</span>L2 Cache Handle: 0x0006</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre">	</span>L3 Cache Handle: 0x0007</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Seria=
l Number: To Be Filled By O.E.M.</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">	</span>Asset Tag: To Be Filled By O.E.M.</div><di=
v><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Part Num=
ber: To Be Filled By O.E.M.</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Core =
Count: 4</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"=
>	</span>Core Enabled: 4</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre">	</span>Thread Count: 4</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Chara=
cteristics:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re">		</span>64-bit capable</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div>
<div><br></div><div>=A0\ \/ /___ _ __ =A0 | || | =A0|___ \ =A0 =A0_ =A0 _ _=
 __ =A0___| |_ __ _| |__ | | ___=A0</div><div>=A0 \ =A0// _ \ &#39;_ \ =A0|=
 || |_ =A0 __) |__| | | | &#39;_ \/ __| __/ _` | &#39;_ \| |/ _ \</div><div=
>=A0 / =A0\ =A0__/ | | | |__ =A0 _| / __/|__| |_| | | | \__ \ || (_| | |_) =
| | =A0__/</div>
<div>=A0/_/\_\___|_| |_| =A0 =A0|_|(_)_____| =A0 \__,_|_| |_|___/\__\__,_|_=
.__/|_|\___|</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0=A0</div><div>(XEN) Xen version 4.2-unstable (root@) (g=
cc version 4.7.0 20120507 (Red Hat 4.72</div>
<div>(XEN) Latest ChangeSet: Thu Jun 07 19:46:57 2012 +0100 25467:32034d191=
4a6</div><div>(XEN) Bootloader: GRUB 2.00~beta4</div><div>(XEN) Command lin=
e: placeholder loglvl=3Dall guest_loglvl=3Dall com1=3D19200,8n1,pci,a</div>=
<div>
(XEN) Video information:</div><div>(XEN) =A0VGA is text mode 80x25, font 8x=
16</div><div>(XEN) =A0VBE/DDC methods: V2; EDID transfer time: 1 seconds</d=
iv><div>(XEN) Disc information:</div><div>(XEN) =A0Found 2 MBR signatures</=
div>
<div>(XEN) =A0Found 3 EDD information structures</div><div>(XEN) Xen-e820 R=
AM map:</div><div>(XEN) =A00000000000000000 - 000000000009ac00 (usable)</di=
v><div>(XEN) =A0000000000009ac00 - 00000000000a0000 (reserved)</div><div>(X=
EN) =A000000000000e0000 - 0000000000100000 (reserved)</div>
<div>(XEN) =A00000000000100000 - 0000000020000000 (usable)</div><div>(XEN) =
=A00000000020000000 - 0000000020200000 (reserved)</div><div>(XEN) =A0000000=
0020200000 - 0000000040000000 (usable)</div><div>(XEN) =A00000000040000000 =
- 0000000040200000 (reserved)</div>
<div>(XEN) =A00000000040200000 - 00000000ae854000 (usable)</div><div>(XEN) =
=A000000000ae854000 - 00000000ae85d000 (ACPI data)</div><div>(XEN) =A000000=
000ae85d000 - 00000000ae8a8000 (ACPI NVS)</div><div>(XEN) =A000000000ae8a80=
00 - 00000000ae8b0000 (usable)</div>
<div>(XEN) =A000000000ae8b0000 - 00000000ae9a4000 (reserved)</div><div>(XEN=
) =A000000000ae9a4000 - 00000000ae9a6000 (usable)</div><div>(XEN) =A0000000=
00ae9a6000 - 00000000aebc5000 (reserved)</div><div>(XEN) =A000000000aebc500=
0 - 00000000aebc6000 (usable)</div>
<div>(XEN) =A000000000aebc6000 - 00000000aebd6000 (reserved)</div><div>(XEN=
) =A000000000aebd6000 - 00000000aebf5000 (ACPI NVS)</div><div>(XEN) =A00000=
0000aebf5000 - 00000000aec19000 (reserved)</div><div>(XEN) =A000000000aec19=
000 - 00000000aec5c000 (ACPI NVS)</div>
<div>(XEN) =A000000000aec5c000 - 00000000aee7c000 (reserved)</div><div>(XEN=
) =A000000000aee7c000 - 00000000af000000 (usable)</div><div>(XEN) =A0000000=
00af800000 - 00000000bfa00000 (reserved)</div><div>(XEN) =A000000000fed1c00=
0 - 00000000fed40000 (reserved)</div>
<div>(XEN) =A000000000ff000000 - 0000000100000000 (reserved)</div><div>(XEN=
) =A00000000100000000 - 000000043e600000 (usable)</div><div>(XEN) ACPI: RSD=
P 000F0450, 0024 (r2 =A0INTEL)</div><div>(XEN) ACPI: XSDT AE854070, 0064 (r=
1 INTEL =A0DQ67SW =A0 =A01072009 AMI =A0 =A0 10013)</div>
<div>(XEN) ACPI: FACP AE85BB50, 00F4 (r4 INTEL =A0DQ67SW =A0 =A01072009 AMI=
 =A0 =A0 10013)</div><div>(XEN) ACPI: DSDT AE854168, 79E1 (r2 INTEL =A0DQ67=
SW =A0 =A0 =A0 =A0 16 INTL 20051117)</div><div>(XEN) ACPI: FACS AEBDBF80, 0=
040</div><div>(XEN) ACPI: APIC AE85BC48, 0072 (r3 INTEL =A0DQ67SW =A0 =A010=
72009 AMI =A0 =A0 10013)</div>
<div>(XEN) ACPI: TCPA AE85BCC0, 0032 (r2 INTEL =A0DQ67SW =A0 =A0 =A0 =A0 =
=A01 MSFT =A01000013)</div><div>(XEN) ACPI: SSDT AE85BCF8, 0102 (r1 INTEL =
=A0DQ67SW =A0 =A0 =A0 =A0 =A01 MSFT =A03000001)</div><div>(XEN) ACPI: MCFG =
AE85BE00, 003C (r1 INTEL =A0DQ67SW =A0 =A01072009 MSFT =A0 =A0 =A0 97)</div=
>
<div>(XEN) ACPI: HPET AE85BE40, 0038 (r1 INTEL =A0DQ67SW =A0 =A01072009 AMI=
. =A0 =A0 =A0 =A04)</div><div>(XEN) ACPI: ASF! AE85BE78, 00A0 (r32 INTEL =
=A0DQ67SW =A0 =A0 =A0 =A0 =A01 TFSM =A0 =A0F4240)</div><div>(XEN) ACPI: DMA=
R AE85BF18, 00E8 (r1 INTEL =A0DQ67SW =A0 =A0 =A0 =A0 =A01 INTL =A0 =A0 =A0 =
=A01)</div>
<div>(XEN) System RAM: 16075MB (16461300kB)</div><div>(XEN) No NUMA configu=
ration found</div><div>(XEN) Faking a node at 0000000000000000-000000043e60=
0000</div><div>(XEN) Domain heap initialised</div><div>(XEN) found SMP MP-t=
able at 000fda30</div>
<div>(XEN) DMI 2.6 present.</div><div>(XEN) Using APIC driver default</div>=
<div>(XEN) ACPI: PM-Timer IO Port: 0x408</div><div>(XEN) ACPI: ACPI SLEEP I=
NFO: pm1x_cnt[404,0], pm1x_evt[400,0]</div><div>(XEN) ACPI: 32/64X FACS add=
ress mismatch in FADT - aebdbf80/0000000000000000, u2</div>
<div>(XEN) ACPI: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wakeup_vec[aebdbf8c], v=
ec_size[20]</div><div>(XEN) ACPI: Local APIC address 0xfee00000</div><div>(=
XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)</div><div>(XEN) Pro=
cessor #0 6:10 APIC version 21</div>
<div>(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)</div><div>(XE=
N) Processor #2 6:10 APIC version 21</div><div>(XEN) ACPI: LAPIC (acpi_id[0=
x03] lapic_id[0x04] enabled)</div><div>(XEN) Processor #4 6:10 APIC version=
 21</div>
<div>(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)</div><div>(XE=
N) Processor #6 6:10 APIC version 21</div><div>(XEN) ACPI: LAPIC_NMI (acpi_=
id[0xff] high edge lint[0x1])</div><div>(XEN) ACPI: IOAPIC (id[0x00] addres=
s[0xfec00000] gsi_base[0])</div>
<div>(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23</=
div><div>(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)</di=
v><div>(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)</d=
iv>
<div>(XEN) ACPI: IRQ0 used by override.</div><div>(XEN) ACPI: IRQ2 used by =
override.</div><div>(XEN) ACPI: IRQ9 used by override.</div><div>(XEN) Enab=
ling APIC mode: =A0Flat. =A0Using 1 I/O APICs</div><div>(XEN) ACPI: HPET id=
: 0x8086a701 base: 0xfed00000</div>
<div>(XEN) Table is not found!</div><div>(XEN) Using ACPI (MADT) for SMP co=
nfiguration information</div><div>(XEN) SMP: Allowing 4 CPUs (0 hotplug CPU=
s)</div><div>(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X</div><div>(XEN) Switch=
ed to APIC driver x2apic_cluster.</div>
<div>(XEN) Using scheduler: SMP Credit Scheduler (credit)</div><div>(XEN) D=
etected 3292.554 MHz processor.</div><div>(XEN) Initing memory sharing.</di=
v><div>(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7</div>
<div>(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank=
 0 extend0</div><div>(XEN) Intel machine check reporting enabled</div><div>=
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 3f</=
div>
<div>(XEN) PCI: Not using MCFG for segment 0000 bus 00-3f</div><div>(XEN) I=
ntel VT-d Snoop Control not enabled.</div><div>(XEN) Intel VT-d Dom0 DMA Pa=
ssthrough not enabled.</div><div>(XEN) Intel VT-d Queued Invalidation enabl=
ed.</div>
<div>(XEN) Intel VT-d Interrupt Remapping enabled.</div><div>(XEN) Intel VT=
-d Shared EPT tables not enabled.</div><div>(XEN) I/O virtualisation enable=
d</div><div>(XEN) =A0- Dom0 mode: Relaxed</div><div>(XEN) Enabled directed =
EOI with ioapic_ack_old on!</div>
<div>(XEN) ENABLING IO-APIC IRQs</div><div>(XEN) =A0-&gt; Using old ACK met=
hod</div><div>(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pi=
n2=3D-1</div><div>(XEN) TSC deadline timer enabled</div><div>(XEN) Platform=
 timer is 14.318MHz HPET</div>
<div>(XEN) Allocated console ring of 32 KiB.</div><div>(XEN) VMX: Supported=
 advanced features:</div><div>(XEN) =A0- APIC MMIO access virtualisation</d=
iv><div>(XEN) =A0- APIC TPR shadow</div><div>(XEN) =A0- Extended Page Table=
s (EPT)</div>
<div>(XEN) =A0- Virtual-Processor Identifiers (VPID)</div><div>(XEN) =A0- V=
irtual NMI</div><div>(XEN) =A0- MSR direct-access bitmap</div><div>(XEN) =
=A0- Unrestricted Guest</div><div>(XEN) HVM: ASIDs enabled.</div><div>(XEN)=
 HVM: VMX enabled</div>
<div>(XEN) HVM: Hardware Assisted Paging (HAP) detected</div><div>(XEN) HVM=
: HAP page sizes: 4kB, 2MB</div><div>(XEN) Brought up 4 CPUs</div><div>(XEN=
) ACPI sleep modes: S3</div><div>(XEN) mcheck_poll: Machine check polling t=
imer started.</div>
<div>(XEN) *** LOADING DOMAIN 0 ***</div><div>(XEN) elf_parse_binary: phdr:=
 paddr=3D0x1000000 memsz=3D0xa8c000</div><div>(XEN) elf_parse_binary: phdr:=
 paddr=3D0x1c00000 memsz=3D0xde0e8</div><div>(XEN) elf_parse_binary: phdr: =
paddr=3D0x1cdf000 memsz=3D0x14440</div>
<div>(XEN) elf_parse_binary: phdr: paddr=3D0x1cf4000 memsz=3D0x6c3000</div>=
<div>(XEN) elf_parse_binary: memory: 0x1000000 -&gt; 0x23b7000</div><div>(X=
EN) elf_xen_parse_note: GUEST_OS =3D &quot;linux&quot;</div><div>(XEN) elf_=
xen_parse_note: GUEST_VERSION =3D &quot;2.6&quot;</div>
<div>(XEN) elf_xen_parse_note: XEN_VERSION =3D &quot;xen-3.0&quot;</div><di=
v>(XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000</div><div>(XEN=
) elf_xen_parse_note: ENTRY =3D 0xffffffff81cf4200</div><div>(XEN) elf_xen_=
parse_note: HYPERCALL_PAGE =3D 0xffffffff81001000</div>
<div>(XEN) elf_xen_parse_note: FEATURES =3D &quot;!writable_page_tables|pae=
_pgdir_above_4gb&quot;</div><div>(XEN) elf_xen_parse_note: PAE_MODE =3D &qu=
ot;yes&quot;</div><div>(XEN) elf_xen_parse_note: LOADER =3D &quot;generic&q=
uot;</div>
<div>(XEN) elf_xen_parse_note: unknown xen elf note (0xd)</div><div>(XEN) e=
lf_xen_parse_note: SUSPEND_CANCEL =3D 0x1</div><div>(XEN) elf_xen_parse_not=
e: HV_START_LOW =3D 0xffff800000000000</div><div>(XEN) elf_xen_parse_note: =
PADDR_OFFSET =3D 0x0</div>
<div>(XEN) elf_xen_addr_calc_check: addresses:</div><div>(XEN) =A0 =A0 virt=
_base =A0 =A0 =A0 =A0=3D 0xffffffff80000000</div><div>(XEN) =A0 =A0 elf_pad=
dr_offset =3D 0x0</div><div>(XEN) =A0 =A0 virt_offset =A0 =A0 =A0=3D 0xffff=
ffff80000000</div><div>(XEN) =A0 =A0 virt_kstart =A0 =A0 =A0=3D 0xffffffff8=
1000000</div>
<div>(XEN) =A0 =A0 virt_kend =A0 =A0 =A0 =A0=3D 0xffffffff823b7000</div><di=
v>(XEN) =A0 =A0 virt_entry =A0 =A0 =A0 =3D 0xffffffff81cf4200</div><div>(XE=
N) =A0 =A0 p2m_base =A0 =A0 =A0 =A0 =3D 0xffffffffffffffff</div><div>(XEN) =
=A0Xen =A0kernel: 64-bit, lsb, compat32</div>
<div>(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -&gt; 0x23b700=
0</div><div>(XEN) PHYSICAL MEMORY ARRANGEMENT:</div><div>(XEN) =A0Dom0 allo=
c.: =A0 0000000420000000-&gt;0000000428000000 (3983123 pages to be a)</div>=
<div>
(XEN) =A0Init. ramdisk: 000000043b8e8000-&gt;000000043e5ffa00</div><div>(XE=
N) VIRTUAL MEMORY ARRANGEMENT:</div><div>(XEN) =A0Loaded kernel: ffffffff81=
000000-&gt;ffffffff823b7000</div><div>(XEN) =A0Init. ramdisk: ffffffff823b7=
000-&gt;ffffffff850cea00</div>
<div>(XEN) =A0Phys-Mach map: ffffffff850cf000-&gt;ffffffff86f89158</div><di=
v>(XEN) =A0Start info: =A0 =A0ffffffff86f8a000-&gt;ffffffff86f8a4b4</div><d=
iv>(XEN) =A0Page tables: =A0 ffffffff86f8b000-&gt;ffffffff86fc8000</div><di=
v>(XEN) =A0Boot stack: =A0 =A0ffffffff86fc8000-&gt;ffffffff86fc9000</div>
<div>(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000-&gt;ffffffff87400000<=
/div><div>(XEN) =A0ENTRY ADDRESS: ffffffff81cf4200</div><div>(XEN) Dom0 has=
 maximum 4 VCPUs</div><div>(XEN) elf_load_binary: phdr 0 at 0xffffffff81000=
000 -&gt; 0xffffffff81a8c000</div>
<div>(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -&gt; 0xffffffff81=
cde0e8</div><div>(XEN) elf_load_binary: phdr 2 at 0xffffffff81cdf000 -&gt; =
0xffffffff81cf3440</div><div>(XEN) elf_load_binary: phdr 3 at 0xffffffff81c=
f4000 -&gt; 0xffffffff81de0000</div>
<div>(XEN) Scrubbing Free RAM: .done.</div><div>(XEN) Initial low memory vi=
rq threshold set at 0x4000 pages.</div><div>(XEN) Std. Loglevel: All</div><=
div>(XEN) Guest Loglevel: All</div><div>(XEN) Xen is relinquishing VGA cons=
ole.</div>
<div>(XEN) *** Serial input -&gt; DOM0 (type &#39;CTRL-a&#39; three times t=
o switch input to Xe)</div><div>(XEN) Freed 232kB init memory.</div><div>ma=
pping kernel into physical memory</div><div>Xen: setup ISA identity maps</d=
iv>
<div>about to get started...</div><div>[ =A0 =A04.034307] invalid opcode: 0=
000 [#1] SMP=A0</div><div>[ =A0 =A04.034311] CPU 0=A0</div><div>[ =A0 =A04.=
034312] Modules linked in:</div><div>[ =A0 =A04.034314]=A0</div><div>[ =A0 =
=A04.034316] Pid: 0, comm: swapper Not tainted 3.4.0-1.fc17.x86_64 #1 =A0 =
=A0 =A0 =A0W</div>
<div>[ =A0 =A04.034320] RIP: e030:[&lt;ffffffff8101d777&gt;] =A0[&lt;ffffff=
ff8101d777&gt;] xstate_enab0</div><div>[ =A0 =A04.034326] RSP: e02b:fffffff=
f81c01e48 =A0EFLAGS: 00010046</div><div>[ =A0 =A04.034328] RAX: 00000000000=
00007 RBX: ffffffff81c01e80 RCX: 0000000000000000</div>
<div>[ =A0 =A04.034330] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 00=
00000000002660</div><div>[ =A0 =A04.034332] RBP: ffffffff81c01e48 R08: aaaa=
aaaaaaaaaaaa R09: ffffffff81c01e80</div><div>[ =A0 =A04.034333] R10: ffffff=
ff81c01e84 R11: 00000000ffffffff R12: ffffffff81c01e84</div>
<div>[ =A0 =A04.034335] R13: ffffffff81c01e7c R14: ffffffff81c01e78 R15: ff=
ffffff81c13020</div><div>[ =A0 =A04.034339] FS: =A00000000000000000(0000) G=
S:ffff8803d6e00000(0000) knlGS:00000</div><div>[ =A0 =A04.034341] CS: =A0e0=
33 DS: 0000 ES: 0000 CR0: 000000008005003b</div>
<div>[ =A0 =A04.034343] CR2: 0000000000000000 CR3: 0000000001c0b000 CR4: 00=
00000000002660</div><div>[ =A0 =A04.034345] DR0: 0000000000000000 DR1: 0000=
000000000000 DR2: 0000000000000000</div><div>[ =A0 =A04.034347] DR3: 000000=
0000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400</div>
<div>[ =A0 =A04.034349] Process swapper (pid: 0, threadinfo ffffffff81c0000=
0, task fffff)</div><div>[ =A0 =A04.034351] Stack:</div><div>[ =A0 =A04.034=
352] =A0ffffffff81c01ec8 ffffffff81cfcce2 ffff8803d6e0b110 000000008005b</d=
iv><div>[ =A0 =A04.034356] =A00000000080050033 ffffffff81c13020 00000240000=
00007 0000000000000</div>
<div>[ =A0 =A04.034359] =A0ffff8803d6e0b110 ffff8803d6e0b910 ffff8803d6e0b1=
10 0000000000008</div><div>[ =A0 =A04.034363] Call Trace:</div><div>[ =A0 =
=A04.034368] =A0[&lt;ffffffff81cfcce2&gt;] xstate_enable_boot_cpu+0xa9/0x26=
d</div><div>[ =A0 =A04.034371] =A0[&lt;ffffffff815da82b&gt;] xsave_init+0x2=
6/0x28</div>
<div>[ =A0 =A04.034374] =A0[&lt;ffffffff815dca8f&gt;] cpu_init+0x2ea/0x307<=
/div><div>[ =A0 =A04.034377] =A0[&lt;ffffffff81cf92cb&gt;] trap_init+0x173/=
0x1e8</div><div>[ =A0 =A04.034379] =A0[&lt;ffffffff81cf4a3f&gt;] start_kern=
el+0x1dc/0x3c4</div>
<div>[ =A0 =A04.034382] =A0[&lt;ffffffff81cf4662&gt;] ? repair_env_string+0=
x5e/0x5e</div><div>[ =A0 =A04.034384] =A0[&lt;ffffffff81cf4346&gt;] x86_64_=
start_reservations+0x131/0x135</div><div>[ =A0 =A04.034387] =A0[&lt;fffffff=
f81cf7101&gt;] xen_start_kernel+0x58c/0x593</div>
<div>[ =A0 =A04.034388] Code: 48 89 e5 ff 14 25 10 da c1 81 48 89 c7 48 81 =
cf 00 00 04 0=A0</div><div>[ =A0 =A04.034415] RIP =A0[&lt;ffffffff8101d777&=
gt;] xstate_enable+0x37/0x40</div><div>[ =A0 =A04.034417] =A0RSP &lt;ffffff=
ff81c01e48&gt;</div>
<div>[ =A0 =A04.034424] ---[ end trace a7919e7f17c0a725 ]---</div><div>[ =
=A0 =A04.034426] Kernel panic - not syncing: Attempted to kill the idle tas=
k!</div><div>(XEN) Domain 0 crashed: rebooting machine in 5 seconds.</div><=
/div><div>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</div><div><br></div><div>Thanks in advance for your assista=
nce.</div><div>Paul</div>

--e89a8f22bfb1d867a404c2eec0ea--


--===============7657866687548287553==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7657866687548287553==--


From xen-devel-bounces@lists.xen.org Wed Jun 20 22:17:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 22:17: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 1ShTCf-0007SQ-CZ; Wed, 20 Jun 2012 22:16:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1ShTCd-0007SL-Os
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 22:16:44 +0000
Received: from [85.158.143.99:31292] by server-2.bemta-4.messagelabs.com id
	82/68-17938-BCB42EF4; Wed, 20 Jun 2012 22:16:43 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340230600!28311085!1
X-Originating-IP: [209.85.217.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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6495 invoked from network); 20 Jun 2012 22:16:41 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 22:16:41 -0000
Received: by lbom4 with SMTP id m4so1572299lbo.30
	for <xen-devel@lists.xensource.com>;
	Wed, 20 Jun 2012 15:16:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=cirnp8b6EXzv3MI/AZyPRxvq8BoV6TYPh/o4lDzwIYA=;
	b=bI/u2WWMjJ+SZt9WNyoZgcJZ3CvALtpAGNNuFQZCrpqElPNPKe4LLVBbCMer1iDU0j
	/pZ5pWktbXXoLS/pVvOw1tBNkVBjZ0D5SPINfJPfgA8Sa0Ob2H7mHyVDKS3RAx97nKek
	gDYebHk2rYI6X7gdC86cVCX/HGfuftkqWPYwJ6rLZoJqfIXawaYQhwfyBZHE9AGc4OxM
	FbFZeVA4Zsl+gKfKoYrE2NZNaKrSqbo7yq/9J6x5EtVVxXVuwKqZkLgSv33L6o/4WGH3
	EW+vIS/6ktnxAHdNWkAaP+iiXWoOwM+klNB7yjeLvGgn/Qjs2eQeNqnuLn221F+4Xg4R
	plrQ==
MIME-Version: 1.0
Received: by 10.152.144.234 with SMTP id sp10mr24044979lab.51.1340230600255;
	Wed, 20 Jun 2012 15:16:40 -0700 (PDT)
Received: by 10.114.36.38 with HTTP; Wed, 20 Jun 2012 15:16:40 -0700 (PDT)
Date: Wed, 20 Jun 2012 18:16:40 -0400
Message-ID: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] 4.2-Unstable Crash/Reboot(i5 2500/DQ67SW)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7657866687548287553=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7657866687548287553==
Content-Type: multipart/alternative; boundary=e89a8f22bfb1d867a404c2eec0ea

--e89a8f22bfb1d867a404c2eec0ea
Content-Type: text/plain; charset=ISO-8859-1

Environment: Xen-4.2 Unstable - built about a week ago
             OS: Fedora 17
           CPU: i5 2500
Motherboard: DQ67SW latest bios

Trying to get passthrough working, 4.1.2 Bluescreens going into windows,
figured I probably needed some of the patches in 4.2, built it and it just
crashes and reboots. Installed a Serial card, got the terminal working and
was able to capture the crash. I have also included the dmidecode CPU and
BIOS from the normal Fedora 17 kernel(non-xen).

Please let me know if I can provide anything else.

=============================================
[root@xenzibar ~]# dmidecode --type bios
# dmidecode 2.11
SMBIOS 2.6 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Intel Corp.
Version: SWQ6710H.86A.0062.2012.0418.1112
Release Date: 04/18/2012
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported

===============================================
[root@xenzibar ~]# dmidecode --type processor
# dmidecode 2.11
SMBIOS 2.6 present.

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: SKTH
Type: Central Processor
Family: Core i5
Manufacturer: Intel(R) Corp.
ID: A7 06 02 00 FF FB EB BF
Signature: Type 0, Family 6, Model 42, Stepping 7
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
Voltage: 1.1 V
External Clock: 100 MHz
Max Speed: 3800 MHz
Current Speed: 3300 MHz
Status: Populated, Enabled
Upgrade: Socket BGA1155
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: 0x0007
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Part Number: To Be Filled By O.E.M.
Core Count: 4
Core Enabled: 4
Thread Count: 4
Characteristics:
64-bit capable

===================================================================

 \ \/ /___ _ __   | || |  |___ \    _   _ _ __  ___| |_ __ _| |__ | | ___
  \  // _ \ '_ \  | || |_   __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / __/|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_____|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|

(XEN) Xen version 4.2-unstable (root@) (gcc version 4.7.0 20120507 (Red Hat
4.72
(XEN) Latest ChangeSet: Thu Jun 07 19:46:57 2012 +0100 25467:32034d1914a6
(XEN) Bootloader: GRUB 2.00~beta4
(XEN) Command line: placeholder loglvl=all guest_loglvl=all
com1=19200,8n1,pci,a
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040000000 (usable)
(XEN)  0000000040000000 - 0000000040200000 (reserved)
(XEN)  0000000040200000 - 00000000ae854000 (usable)
(XEN)  00000000ae854000 - 00000000ae85d000 (ACPI data)
(XEN)  00000000ae85d000 - 00000000ae8a8000 (ACPI NVS)
(XEN)  00000000ae8a8000 - 00000000ae8b0000 (usable)
(XEN)  00000000ae8b0000 - 00000000ae9a4000 (reserved)
(XEN)  00000000ae9a4000 - 00000000ae9a6000 (usable)
(XEN)  00000000ae9a6000 - 00000000aebc5000 (reserved)
(XEN)  00000000aebc5000 - 00000000aebc6000 (usable)
(XEN)  00000000aebc6000 - 00000000aebd6000 (reserved)
(XEN)  00000000aebd6000 - 00000000aebf5000 (ACPI NVS)
(XEN)  00000000aebf5000 - 00000000aec19000 (reserved)
(XEN)  00000000aec19000 - 00000000aec5c000 (ACPI NVS)
(XEN)  00000000aec5c000 - 00000000aee7c000 (reserved)
(XEN)  00000000aee7c000 - 00000000af000000 (usable)
(XEN)  00000000af800000 - 00000000bfa00000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000043e600000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2  INTEL)
(XEN) ACPI: XSDT AE854070, 0064 (r1 INTEL  DQ67SW    1072009 AMI     10013)
(XEN) ACPI: FACP AE85BB50, 00F4 (r4 INTEL  DQ67SW    1072009 AMI     10013)
(XEN) ACPI: DSDT AE854168, 79E1 (r2 INTEL  DQ67SW         16 INTL 20051117)
(XEN) ACPI: FACS AEBDBF80, 0040
(XEN) ACPI: APIC AE85BC48, 0072 (r3 INTEL  DQ67SW    1072009 AMI     10013)
(XEN) ACPI: TCPA AE85BCC0, 0032 (r2 INTEL  DQ67SW          1 MSFT  1000013)
(XEN) ACPI: SSDT AE85BCF8, 0102 (r1 INTEL  DQ67SW          1 MSFT  3000001)
(XEN) ACPI: MCFG AE85BE00, 003C (r1 INTEL  DQ67SW    1072009 MSFT       97)
(XEN) ACPI: HPET AE85BE40, 0038 (r1 INTEL  DQ67SW    1072009 AMI.        4)
(XEN) ACPI: ASF! AE85BE78, 00A0 (r32 INTEL  DQ67SW          1 TFSM    F4240)
(XEN) ACPI: DMAR AE85BF18, 00E8 (r1 INTEL  DQ67SW          1 INTL        1)
(XEN) System RAM: 16075MB (16461300kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000043e600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fda30
(XEN) DMI 2.6 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 -
aebdbf80/0000000000000000, u2
(XEN) ACPI:                  wakeup_vec[aebdbf8c], 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[0x04] enabled)
(XEN) Processor #4 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 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) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3292.554 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0
extend0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 3f
(XEN) PCI: Not using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(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) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 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
(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=0xa8c000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0xde0e8
(XEN) elf_parse_binary: phdr: paddr=0x1cdf000 memsz=0x14440
(XEN) elf_parse_binary: phdr: paddr=0x1cf4000 memsz=0x6c3000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x23b7000
(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 = 0xffffffff81cf4200
(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        = 0xffffffff823b7000
(XEN)     virt_entry       = 0xffffffff81cf4200
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x23b7000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000420000000->0000000428000000 (3983123 pages to
be a)
(XEN)  Init. ramdisk: 000000043b8e8000->000000043e5ffa00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff823b7000
(XEN)  Init. ramdisk: ffffffff823b7000->ffffffff850cea00
(XEN)  Phys-Mach map: ffffffff850cf000->ffffffff86f89158
(XEN)  Start info:    ffffffff86f8a000->ffffffff86f8a4b4
(XEN)  Page tables:   ffffffff86f8b000->ffffffff86fc8000
(XEN)  Boot stack:    ffffffff86fc8000->ffffffff86fc9000
(XEN)  TOTAL:         ffffffff80000000->ffffffff87400000
(XEN)  ENTRY ADDRESS: ffffffff81cf4200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81a8c000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81cde0e8
(XEN) elf_load_binary: phdr 2 at 0xffffffff81cdf000 -> 0xffffffff81cf3440
(XEN) elf_load_binary: phdr 3 at 0xffffffff81cf4000 -> 0xffffffff81de0000
(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 Xe)
(XEN) Freed 232kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    4.034307] invalid opcode: 0000 [#1] SMP
[    4.034311] CPU 0
[    4.034312] Modules linked in:
[    4.034314]
[    4.034316] Pid: 0, comm: swapper Not tainted 3.4.0-1.fc17.x86_64 #1
   W
[    4.034320] RIP: e030:[<ffffffff8101d777>]  [<ffffffff8101d777>]
xstate_enab0
[    4.034326] RSP: e02b:ffffffff81c01e48  EFLAGS: 00010046
[    4.034328] RAX: 0000000000000007 RBX: ffffffff81c01e80 RCX:
0000000000000000
[    4.034330] RDX: 0000000000000000 RSI: 0000000000000007 RDI:
0000000000002660
[    4.034332] RBP: ffffffff81c01e48 R08: aaaaaaaaaaaaaaaa R09:
ffffffff81c01e80
[    4.034333] R10: ffffffff81c01e84 R11: 00000000ffffffff R12:
ffffffff81c01e84
[    4.034335] R13: ffffffff81c01e7c R14: ffffffff81c01e78 R15:
ffffffff81c13020
[    4.034339] FS:  0000000000000000(0000) GS:ffff8803d6e00000(0000)
knlGS:00000
[    4.034341] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    4.034343] CR2: 0000000000000000 CR3: 0000000001c0b000 CR4:
0000000000002660
[    4.034345] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    4.034347] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[    4.034349] Process swapper (pid: 0, threadinfo ffffffff81c00000, task
fffff)
[    4.034351] Stack:
[    4.034352]  ffffffff81c01ec8 ffffffff81cfcce2 ffff8803d6e0b110
000000008005b
[    4.034356]  0000000080050033 ffffffff81c13020 0000024000000007
0000000000000
[    4.034359]  ffff8803d6e0b110 ffff8803d6e0b910 ffff8803d6e0b110
0000000000008
[    4.034363] Call Trace:
[    4.034368]  [<ffffffff81cfcce2>] xstate_enable_boot_cpu+0xa9/0x26d
[    4.034371]  [<ffffffff815da82b>] xsave_init+0x26/0x28
[    4.034374]  [<ffffffff815dca8f>] cpu_init+0x2ea/0x307
[    4.034377]  [<ffffffff81cf92cb>] trap_init+0x173/0x1e8
[    4.034379]  [<ffffffff81cf4a3f>] start_kernel+0x1dc/0x3c4
[    4.034382]  [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
[    4.034384]  [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
[    4.034387]  [<ffffffff81cf7101>] xen_start_kernel+0x58c/0x593
[    4.034388] Code: 48 89 e5 ff 14 25 10 da c1 81 48 89 c7 48 81 cf 00 00
04 0
[    4.034415] RIP  [<ffffffff8101d777>] xstate_enable+0x37/0x40
[    4.034417]  RSP <ffffffff81c01e48>
[    4.034424] ---[ end trace a7919e7f17c0a725 ]---
[    4.034426] Kernel panic - not syncing: Attempted to kill the idle task!
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
================================================================================

Thanks in advance for your assistance.
Paul

--e89a8f22bfb1d867a404c2eec0ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Environment: Xen-4.2 Unstable - built about a week ago<div>=A0 =A0 =A0 =A0 =
=A0 =A0 =A0OS: Fedora 17=A0</div><div>=A0 =A0 =A0 =A0 =A0 =A0CPU: i5 2500</=
div><div>Motherboard: DQ67SW latest bios</div><div><br></div><div>Trying to=
 get passthrough working, 4.1.2 Bluescreens going into windows, figured I p=
robably needed some of the patches in 4.2, built it and it just crashes and=
 reboots. Installed a Serial card, got the terminal working and was able to=
 capture the crash. I have also included the dmidecode CPU and BIOS from th=
e normal Fedora 17 kernel(non-xen).=A0</div>
<div><br></div><div>Please let me know if I can provide anything else.</div=
><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D</div><div><div>[root@xenzibar ~]# dmidecode --type bios</div><div># =
dmidecode 2.11</div>
<div>SMBIOS 2.6 present.</div><div><br></div><div>Handle 0x0000, DMI type 0=
, 24 bytes</div><div>BIOS Information</div><div><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre">	</span>Vendor: Intel Corp.</div><div><span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Version: SWQ6710H=
.86A.0062.2012.0418.1112</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Relea=
se Date: 04/18/2012</div><div><span class=3D"Apple-tab-span" style=3D"white=
-space:pre">	</span>Address: 0xF0000</div><div><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre">	</span>Runtime Size: 64 kB</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>ROM S=
ize: 1024 kB</div><div><span class=3D"Apple-tab-span" style=3D"white-space:=
pre">	</span>Characteristics:</div><div><span class=3D"Apple-tab-span" styl=
e=3D"white-space:pre">		</span>PCI is supported</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>BIOS=
 is upgradeable</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre">		</span>BIOS shadowing is allowed</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre">		</span>Boot from CD is supported</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>Sele=
ctable boot is supported</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre">		</span>BIOS ROM is socketed</div><div><span class=3D"App=
le-tab-span" style=3D"white-space:pre">		</span>EDD is supported</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>5.25=
&quot;/1.2 MB floppy services are supported (int 13h)</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>3.5&quot;/720 kB flo=
ppy services are supported (int 13h)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>3.5&=
quot;/2.88 MB floppy services are supported (int 13h)</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>Print screen service=
 is supported (int 5h)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>8042=
 keyboard services are supported (int 9h)</div><div><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre">		</span>Serial services are supported (i=
nt 14h)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>Prin=
ter services are supported (int 17h)</div><div><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre">		</span>ACPI is supported</div><div><span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre">		</span>USB legacy is supp=
orted</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>BIOS=
 boot specification is supported</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">		</span>Targeted content distribution is supporte=
d</div>
<div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D</div><div>[root@xenzibar ~]# dmidecode --type processor</div><=
div># dmidecode 2.11</div><div>SMBIOS 2.6 present.</div><div><br></div><div=
>Handle 0x0004, DMI type 4, 42 bytes</div>
<div>Processor Information</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">	</span>Socket Designation: SKTH</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Type: Central Process=
or</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Famil=
y: Core i5</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pr=
e">	</span>Manufacturer: Intel(R) Corp.</div><div><span class=3D"Apple-tab-=
span" style=3D"white-space:pre">	</span>ID: A7 06 02 00 FF FB EB BF</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Signa=
ture: Type 0, Family 6, Model 42, Stepping 7</div><div><span class=3D"Apple=
-tab-span" style=3D"white-space:pre">	</span>Flags:</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>FPU (Floating-point =
unit on-chip)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>VME =
(Virtual mode extension)</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre">		</span>DE (Debugging extension)</div><div><span class=3D=
"Apple-tab-span" style=3D"white-space:pre">		</span>PSE (Page size extensio=
n)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>TSC =
(Time stamp counter)</div><div><span class=3D"Apple-tab-span" style=3D"whit=
e-space:pre">		</span>MSR (Model specific registers)</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">		</span>PAE (Physical addres=
s extension)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>MCE =
(Machine check exception)</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre">		</span>CX8 (CMPXCHG8 instruction supported)</div><div><=
span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>APIC (On-c=
hip APIC hardware supported)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>SEP =
(Fast system call)</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">		</span>MTRR (Memory type range registers)</div><div><span clas=
s=3D"Apple-tab-span" style=3D"white-space:pre">		</span>PGE (Page global en=
able)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>MCA =
(Machine check architecture)</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">		</span>CMOV (Conditional move instruction supported)=
</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>PAT =
(Page attribute table)</div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre">		</span>PSE-36 (36-bit page size extension)</div><div><span=
 class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>CLFSH (CLFLUSH=
 instruction supported)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>DS (=
Debug store)</div><div><span class=3D"Apple-tab-span" style=3D"white-space:=
pre">		</span>ACPI (ACPI supported)</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre">		</span>MMX (MMX technology supported)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>FXSR=
 (FXSAVE and FXSTOR instructions supported)</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre">		</span>SSE (Streaming SIMD extensions=
)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>SSE2=
 (Streaming SIMD extensions 2)</div><div><span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre">		</span>SS (Self-snoop)</div><div><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre">		</span>HTT (Multi-threading)</div=
>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>TM (=
Thermal monitor supported)</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">		</span>PBE (Pending break enabled)</div><div><span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Version: Intel(R)=
 Core(TM) i5-2500 CPU @ 3.30GHz</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Volta=
ge: 1.1 V</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre=
">	</span>External Clock: 100 MHz</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Max Speed: 3800 MHz</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Curre=
nt Speed: 3300 MHz</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">	</span>Status: Populated, Enabled</div><div><span class=3D"Appl=
e-tab-span" style=3D"white-space:pre">	</span>Upgrade: Socket BGA1155</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>L1 Ca=
che Handle: 0x0005</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">	</span>L2 Cache Handle: 0x0006</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre">	</span>L3 Cache Handle: 0x0007</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Seria=
l Number: To Be Filled By O.E.M.</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">	</span>Asset Tag: To Be Filled By O.E.M.</div><di=
v><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Part Num=
ber: To Be Filled By O.E.M.</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Core =
Count: 4</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"=
>	</span>Core Enabled: 4</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre">	</span>Thread Count: 4</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Chara=
cteristics:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re">		</span>64-bit capable</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div>
<div><br></div><div>=A0\ \/ /___ _ __ =A0 | || | =A0|___ \ =A0 =A0_ =A0 _ _=
 __ =A0___| |_ __ _| |__ | | ___=A0</div><div>=A0 \ =A0// _ \ &#39;_ \ =A0|=
 || |_ =A0 __) |__| | | | &#39;_ \/ __| __/ _` | &#39;_ \| |/ _ \</div><div=
>=A0 / =A0\ =A0__/ | | | |__ =A0 _| / __/|__| |_| | | | \__ \ || (_| | |_) =
| | =A0__/</div>
<div>=A0/_/\_\___|_| |_| =A0 =A0|_|(_)_____| =A0 \__,_|_| |_|___/\__\__,_|_=
.__/|_|\___|</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0=A0</div><div>(XEN) Xen version 4.2-unstable (root@) (g=
cc version 4.7.0 20120507 (Red Hat 4.72</div>
<div>(XEN) Latest ChangeSet: Thu Jun 07 19:46:57 2012 +0100 25467:32034d191=
4a6</div><div>(XEN) Bootloader: GRUB 2.00~beta4</div><div>(XEN) Command lin=
e: placeholder loglvl=3Dall guest_loglvl=3Dall com1=3D19200,8n1,pci,a</div>=
<div>
(XEN) Video information:</div><div>(XEN) =A0VGA is text mode 80x25, font 8x=
16</div><div>(XEN) =A0VBE/DDC methods: V2; EDID transfer time: 1 seconds</d=
iv><div>(XEN) Disc information:</div><div>(XEN) =A0Found 2 MBR signatures</=
div>
<div>(XEN) =A0Found 3 EDD information structures</div><div>(XEN) Xen-e820 R=
AM map:</div><div>(XEN) =A00000000000000000 - 000000000009ac00 (usable)</di=
v><div>(XEN) =A0000000000009ac00 - 00000000000a0000 (reserved)</div><div>(X=
EN) =A000000000000e0000 - 0000000000100000 (reserved)</div>
<div>(XEN) =A00000000000100000 - 0000000020000000 (usable)</div><div>(XEN) =
=A00000000020000000 - 0000000020200000 (reserved)</div><div>(XEN) =A0000000=
0020200000 - 0000000040000000 (usable)</div><div>(XEN) =A00000000040000000 =
- 0000000040200000 (reserved)</div>
<div>(XEN) =A00000000040200000 - 00000000ae854000 (usable)</div><div>(XEN) =
=A000000000ae854000 - 00000000ae85d000 (ACPI data)</div><div>(XEN) =A000000=
000ae85d000 - 00000000ae8a8000 (ACPI NVS)</div><div>(XEN) =A000000000ae8a80=
00 - 00000000ae8b0000 (usable)</div>
<div>(XEN) =A000000000ae8b0000 - 00000000ae9a4000 (reserved)</div><div>(XEN=
) =A000000000ae9a4000 - 00000000ae9a6000 (usable)</div><div>(XEN) =A0000000=
00ae9a6000 - 00000000aebc5000 (reserved)</div><div>(XEN) =A000000000aebc500=
0 - 00000000aebc6000 (usable)</div>
<div>(XEN) =A000000000aebc6000 - 00000000aebd6000 (reserved)</div><div>(XEN=
) =A000000000aebd6000 - 00000000aebf5000 (ACPI NVS)</div><div>(XEN) =A00000=
0000aebf5000 - 00000000aec19000 (reserved)</div><div>(XEN) =A000000000aec19=
000 - 00000000aec5c000 (ACPI NVS)</div>
<div>(XEN) =A000000000aec5c000 - 00000000aee7c000 (reserved)</div><div>(XEN=
) =A000000000aee7c000 - 00000000af000000 (usable)</div><div>(XEN) =A0000000=
00af800000 - 00000000bfa00000 (reserved)</div><div>(XEN) =A000000000fed1c00=
0 - 00000000fed40000 (reserved)</div>
<div>(XEN) =A000000000ff000000 - 0000000100000000 (reserved)</div><div>(XEN=
) =A00000000100000000 - 000000043e600000 (usable)</div><div>(XEN) ACPI: RSD=
P 000F0450, 0024 (r2 =A0INTEL)</div><div>(XEN) ACPI: XSDT AE854070, 0064 (r=
1 INTEL =A0DQ67SW =A0 =A01072009 AMI =A0 =A0 10013)</div>
<div>(XEN) ACPI: FACP AE85BB50, 00F4 (r4 INTEL =A0DQ67SW =A0 =A01072009 AMI=
 =A0 =A0 10013)</div><div>(XEN) ACPI: DSDT AE854168, 79E1 (r2 INTEL =A0DQ67=
SW =A0 =A0 =A0 =A0 16 INTL 20051117)</div><div>(XEN) ACPI: FACS AEBDBF80, 0=
040</div><div>(XEN) ACPI: APIC AE85BC48, 0072 (r3 INTEL =A0DQ67SW =A0 =A010=
72009 AMI =A0 =A0 10013)</div>
<div>(XEN) ACPI: TCPA AE85BCC0, 0032 (r2 INTEL =A0DQ67SW =A0 =A0 =A0 =A0 =
=A01 MSFT =A01000013)</div><div>(XEN) ACPI: SSDT AE85BCF8, 0102 (r1 INTEL =
=A0DQ67SW =A0 =A0 =A0 =A0 =A01 MSFT =A03000001)</div><div>(XEN) ACPI: MCFG =
AE85BE00, 003C (r1 INTEL =A0DQ67SW =A0 =A01072009 MSFT =A0 =A0 =A0 97)</div=
>
<div>(XEN) ACPI: HPET AE85BE40, 0038 (r1 INTEL =A0DQ67SW =A0 =A01072009 AMI=
. =A0 =A0 =A0 =A04)</div><div>(XEN) ACPI: ASF! AE85BE78, 00A0 (r32 INTEL =
=A0DQ67SW =A0 =A0 =A0 =A0 =A01 TFSM =A0 =A0F4240)</div><div>(XEN) ACPI: DMA=
R AE85BF18, 00E8 (r1 INTEL =A0DQ67SW =A0 =A0 =A0 =A0 =A01 INTL =A0 =A0 =A0 =
=A01)</div>
<div>(XEN) System RAM: 16075MB (16461300kB)</div><div>(XEN) No NUMA configu=
ration found</div><div>(XEN) Faking a node at 0000000000000000-000000043e60=
0000</div><div>(XEN) Domain heap initialised</div><div>(XEN) found SMP MP-t=
able at 000fda30</div>
<div>(XEN) DMI 2.6 present.</div><div>(XEN) Using APIC driver default</div>=
<div>(XEN) ACPI: PM-Timer IO Port: 0x408</div><div>(XEN) ACPI: ACPI SLEEP I=
NFO: pm1x_cnt[404,0], pm1x_evt[400,0]</div><div>(XEN) ACPI: 32/64X FACS add=
ress mismatch in FADT - aebdbf80/0000000000000000, u2</div>
<div>(XEN) ACPI: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wakeup_vec[aebdbf8c], v=
ec_size[20]</div><div>(XEN) ACPI: Local APIC address 0xfee00000</div><div>(=
XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)</div><div>(XEN) Pro=
cessor #0 6:10 APIC version 21</div>
<div>(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)</div><div>(XE=
N) Processor #2 6:10 APIC version 21</div><div>(XEN) ACPI: LAPIC (acpi_id[0=
x03] lapic_id[0x04] enabled)</div><div>(XEN) Processor #4 6:10 APIC version=
 21</div>
<div>(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)</div><div>(XE=
N) Processor #6 6:10 APIC version 21</div><div>(XEN) ACPI: LAPIC_NMI (acpi_=
id[0xff] high edge lint[0x1])</div><div>(XEN) ACPI: IOAPIC (id[0x00] addres=
s[0xfec00000] gsi_base[0])</div>
<div>(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23</=
div><div>(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)</di=
v><div>(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)</d=
iv>
<div>(XEN) ACPI: IRQ0 used by override.</div><div>(XEN) ACPI: IRQ2 used by =
override.</div><div>(XEN) ACPI: IRQ9 used by override.</div><div>(XEN) Enab=
ling APIC mode: =A0Flat. =A0Using 1 I/O APICs</div><div>(XEN) ACPI: HPET id=
: 0x8086a701 base: 0xfed00000</div>
<div>(XEN) Table is not found!</div><div>(XEN) Using ACPI (MADT) for SMP co=
nfiguration information</div><div>(XEN) SMP: Allowing 4 CPUs (0 hotplug CPU=
s)</div><div>(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X</div><div>(XEN) Switch=
ed to APIC driver x2apic_cluster.</div>
<div>(XEN) Using scheduler: SMP Credit Scheduler (credit)</div><div>(XEN) D=
etected 3292.554 MHz processor.</div><div>(XEN) Initing memory sharing.</di=
v><div>(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7</div>
<div>(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank=
 0 extend0</div><div>(XEN) Intel machine check reporting enabled</div><div>=
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 3f</=
div>
<div>(XEN) PCI: Not using MCFG for segment 0000 bus 00-3f</div><div>(XEN) I=
ntel VT-d Snoop Control not enabled.</div><div>(XEN) Intel VT-d Dom0 DMA Pa=
ssthrough not enabled.</div><div>(XEN) Intel VT-d Queued Invalidation enabl=
ed.</div>
<div>(XEN) Intel VT-d Interrupt Remapping enabled.</div><div>(XEN) Intel VT=
-d Shared EPT tables not enabled.</div><div>(XEN) I/O virtualisation enable=
d</div><div>(XEN) =A0- Dom0 mode: Relaxed</div><div>(XEN) Enabled directed =
EOI with ioapic_ack_old on!</div>
<div>(XEN) ENABLING IO-APIC IRQs</div><div>(XEN) =A0-&gt; Using old ACK met=
hod</div><div>(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pi=
n2=3D-1</div><div>(XEN) TSC deadline timer enabled</div><div>(XEN) Platform=
 timer is 14.318MHz HPET</div>
<div>(XEN) Allocated console ring of 32 KiB.</div><div>(XEN) VMX: Supported=
 advanced features:</div><div>(XEN) =A0- APIC MMIO access virtualisation</d=
iv><div>(XEN) =A0- APIC TPR shadow</div><div>(XEN) =A0- Extended Page Table=
s (EPT)</div>
<div>(XEN) =A0- Virtual-Processor Identifiers (VPID)</div><div>(XEN) =A0- V=
irtual NMI</div><div>(XEN) =A0- MSR direct-access bitmap</div><div>(XEN) =
=A0- Unrestricted Guest</div><div>(XEN) HVM: ASIDs enabled.</div><div>(XEN)=
 HVM: VMX enabled</div>
<div>(XEN) HVM: Hardware Assisted Paging (HAP) detected</div><div>(XEN) HVM=
: HAP page sizes: 4kB, 2MB</div><div>(XEN) Brought up 4 CPUs</div><div>(XEN=
) ACPI sleep modes: S3</div><div>(XEN) mcheck_poll: Machine check polling t=
imer started.</div>
<div>(XEN) *** LOADING DOMAIN 0 ***</div><div>(XEN) elf_parse_binary: phdr:=
 paddr=3D0x1000000 memsz=3D0xa8c000</div><div>(XEN) elf_parse_binary: phdr:=
 paddr=3D0x1c00000 memsz=3D0xde0e8</div><div>(XEN) elf_parse_binary: phdr: =
paddr=3D0x1cdf000 memsz=3D0x14440</div>
<div>(XEN) elf_parse_binary: phdr: paddr=3D0x1cf4000 memsz=3D0x6c3000</div>=
<div>(XEN) elf_parse_binary: memory: 0x1000000 -&gt; 0x23b7000</div><div>(X=
EN) elf_xen_parse_note: GUEST_OS =3D &quot;linux&quot;</div><div>(XEN) elf_=
xen_parse_note: GUEST_VERSION =3D &quot;2.6&quot;</div>
<div>(XEN) elf_xen_parse_note: XEN_VERSION =3D &quot;xen-3.0&quot;</div><di=
v>(XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000</div><div>(XEN=
) elf_xen_parse_note: ENTRY =3D 0xffffffff81cf4200</div><div>(XEN) elf_xen_=
parse_note: HYPERCALL_PAGE =3D 0xffffffff81001000</div>
<div>(XEN) elf_xen_parse_note: FEATURES =3D &quot;!writable_page_tables|pae=
_pgdir_above_4gb&quot;</div><div>(XEN) elf_xen_parse_note: PAE_MODE =3D &qu=
ot;yes&quot;</div><div>(XEN) elf_xen_parse_note: LOADER =3D &quot;generic&q=
uot;</div>
<div>(XEN) elf_xen_parse_note: unknown xen elf note (0xd)</div><div>(XEN) e=
lf_xen_parse_note: SUSPEND_CANCEL =3D 0x1</div><div>(XEN) elf_xen_parse_not=
e: HV_START_LOW =3D 0xffff800000000000</div><div>(XEN) elf_xen_parse_note: =
PADDR_OFFSET =3D 0x0</div>
<div>(XEN) elf_xen_addr_calc_check: addresses:</div><div>(XEN) =A0 =A0 virt=
_base =A0 =A0 =A0 =A0=3D 0xffffffff80000000</div><div>(XEN) =A0 =A0 elf_pad=
dr_offset =3D 0x0</div><div>(XEN) =A0 =A0 virt_offset =A0 =A0 =A0=3D 0xffff=
ffff80000000</div><div>(XEN) =A0 =A0 virt_kstart =A0 =A0 =A0=3D 0xffffffff8=
1000000</div>
<div>(XEN) =A0 =A0 virt_kend =A0 =A0 =A0 =A0=3D 0xffffffff823b7000</div><di=
v>(XEN) =A0 =A0 virt_entry =A0 =A0 =A0 =3D 0xffffffff81cf4200</div><div>(XE=
N) =A0 =A0 p2m_base =A0 =A0 =A0 =A0 =3D 0xffffffffffffffff</div><div>(XEN) =
=A0Xen =A0kernel: 64-bit, lsb, compat32</div>
<div>(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -&gt; 0x23b700=
0</div><div>(XEN) PHYSICAL MEMORY ARRANGEMENT:</div><div>(XEN) =A0Dom0 allo=
c.: =A0 0000000420000000-&gt;0000000428000000 (3983123 pages to be a)</div>=
<div>
(XEN) =A0Init. ramdisk: 000000043b8e8000-&gt;000000043e5ffa00</div><div>(XE=
N) VIRTUAL MEMORY ARRANGEMENT:</div><div>(XEN) =A0Loaded kernel: ffffffff81=
000000-&gt;ffffffff823b7000</div><div>(XEN) =A0Init. ramdisk: ffffffff823b7=
000-&gt;ffffffff850cea00</div>
<div>(XEN) =A0Phys-Mach map: ffffffff850cf000-&gt;ffffffff86f89158</div><di=
v>(XEN) =A0Start info: =A0 =A0ffffffff86f8a000-&gt;ffffffff86f8a4b4</div><d=
iv>(XEN) =A0Page tables: =A0 ffffffff86f8b000-&gt;ffffffff86fc8000</div><di=
v>(XEN) =A0Boot stack: =A0 =A0ffffffff86fc8000-&gt;ffffffff86fc9000</div>
<div>(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000-&gt;ffffffff87400000<=
/div><div>(XEN) =A0ENTRY ADDRESS: ffffffff81cf4200</div><div>(XEN) Dom0 has=
 maximum 4 VCPUs</div><div>(XEN) elf_load_binary: phdr 0 at 0xffffffff81000=
000 -&gt; 0xffffffff81a8c000</div>
<div>(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -&gt; 0xffffffff81=
cde0e8</div><div>(XEN) elf_load_binary: phdr 2 at 0xffffffff81cdf000 -&gt; =
0xffffffff81cf3440</div><div>(XEN) elf_load_binary: phdr 3 at 0xffffffff81c=
f4000 -&gt; 0xffffffff81de0000</div>
<div>(XEN) Scrubbing Free RAM: .done.</div><div>(XEN) Initial low memory vi=
rq threshold set at 0x4000 pages.</div><div>(XEN) Std. Loglevel: All</div><=
div>(XEN) Guest Loglevel: All</div><div>(XEN) Xen is relinquishing VGA cons=
ole.</div>
<div>(XEN) *** Serial input -&gt; DOM0 (type &#39;CTRL-a&#39; three times t=
o switch input to Xe)</div><div>(XEN) Freed 232kB init memory.</div><div>ma=
pping kernel into physical memory</div><div>Xen: setup ISA identity maps</d=
iv>
<div>about to get started...</div><div>[ =A0 =A04.034307] invalid opcode: 0=
000 [#1] SMP=A0</div><div>[ =A0 =A04.034311] CPU 0=A0</div><div>[ =A0 =A04.=
034312] Modules linked in:</div><div>[ =A0 =A04.034314]=A0</div><div>[ =A0 =
=A04.034316] Pid: 0, comm: swapper Not tainted 3.4.0-1.fc17.x86_64 #1 =A0 =
=A0 =A0 =A0W</div>
<div>[ =A0 =A04.034320] RIP: e030:[&lt;ffffffff8101d777&gt;] =A0[&lt;ffffff=
ff8101d777&gt;] xstate_enab0</div><div>[ =A0 =A04.034326] RSP: e02b:fffffff=
f81c01e48 =A0EFLAGS: 00010046</div><div>[ =A0 =A04.034328] RAX: 00000000000=
00007 RBX: ffffffff81c01e80 RCX: 0000000000000000</div>
<div>[ =A0 =A04.034330] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 00=
00000000002660</div><div>[ =A0 =A04.034332] RBP: ffffffff81c01e48 R08: aaaa=
aaaaaaaaaaaa R09: ffffffff81c01e80</div><div>[ =A0 =A04.034333] R10: ffffff=
ff81c01e84 R11: 00000000ffffffff R12: ffffffff81c01e84</div>
<div>[ =A0 =A04.034335] R13: ffffffff81c01e7c R14: ffffffff81c01e78 R15: ff=
ffffff81c13020</div><div>[ =A0 =A04.034339] FS: =A00000000000000000(0000) G=
S:ffff8803d6e00000(0000) knlGS:00000</div><div>[ =A0 =A04.034341] CS: =A0e0=
33 DS: 0000 ES: 0000 CR0: 000000008005003b</div>
<div>[ =A0 =A04.034343] CR2: 0000000000000000 CR3: 0000000001c0b000 CR4: 00=
00000000002660</div><div>[ =A0 =A04.034345] DR0: 0000000000000000 DR1: 0000=
000000000000 DR2: 0000000000000000</div><div>[ =A0 =A04.034347] DR3: 000000=
0000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400</div>
<div>[ =A0 =A04.034349] Process swapper (pid: 0, threadinfo ffffffff81c0000=
0, task fffff)</div><div>[ =A0 =A04.034351] Stack:</div><div>[ =A0 =A04.034=
352] =A0ffffffff81c01ec8 ffffffff81cfcce2 ffff8803d6e0b110 000000008005b</d=
iv><div>[ =A0 =A04.034356] =A00000000080050033 ffffffff81c13020 00000240000=
00007 0000000000000</div>
<div>[ =A0 =A04.034359] =A0ffff8803d6e0b110 ffff8803d6e0b910 ffff8803d6e0b1=
10 0000000000008</div><div>[ =A0 =A04.034363] Call Trace:</div><div>[ =A0 =
=A04.034368] =A0[&lt;ffffffff81cfcce2&gt;] xstate_enable_boot_cpu+0xa9/0x26=
d</div><div>[ =A0 =A04.034371] =A0[&lt;ffffffff815da82b&gt;] xsave_init+0x2=
6/0x28</div>
<div>[ =A0 =A04.034374] =A0[&lt;ffffffff815dca8f&gt;] cpu_init+0x2ea/0x307<=
/div><div>[ =A0 =A04.034377] =A0[&lt;ffffffff81cf92cb&gt;] trap_init+0x173/=
0x1e8</div><div>[ =A0 =A04.034379] =A0[&lt;ffffffff81cf4a3f&gt;] start_kern=
el+0x1dc/0x3c4</div>
<div>[ =A0 =A04.034382] =A0[&lt;ffffffff81cf4662&gt;] ? repair_env_string+0=
x5e/0x5e</div><div>[ =A0 =A04.034384] =A0[&lt;ffffffff81cf4346&gt;] x86_64_=
start_reservations+0x131/0x135</div><div>[ =A0 =A04.034387] =A0[&lt;fffffff=
f81cf7101&gt;] xen_start_kernel+0x58c/0x593</div>
<div>[ =A0 =A04.034388] Code: 48 89 e5 ff 14 25 10 da c1 81 48 89 c7 48 81 =
cf 00 00 04 0=A0</div><div>[ =A0 =A04.034415] RIP =A0[&lt;ffffffff8101d777&=
gt;] xstate_enable+0x37/0x40</div><div>[ =A0 =A04.034417] =A0RSP &lt;ffffff=
ff81c01e48&gt;</div>
<div>[ =A0 =A04.034424] ---[ end trace a7919e7f17c0a725 ]---</div><div>[ =
=A0 =A04.034426] Kernel panic - not syncing: Attempted to kill the idle tas=
k!</div><div>(XEN) Domain 0 crashed: rebooting machine in 5 seconds.</div><=
/div><div>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</div><div><br></div><div>Thanks in advance for your assista=
nce.</div><div>Paul</div>

--e89a8f22bfb1d867a404c2eec0ea--


--===============7657866687548287553==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7657866687548287553==--


From xen-devel-bounces@lists.xen.org Wed Jun 20 22:53:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 22: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 1ShTln-0007nT-MT; Wed, 20 Jun 2012 22:53:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShTlm-0007nN-QY
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 22:53:02 +0000
Received: from [193.109.254.147:61618] by server-10.bemta-14.messagelabs.com
	id 10/BF-05433-E4452EF4; Wed, 20 Jun 2012 22:53:02 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340232779!10744455!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzUxMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2744 invoked from network); 20 Jun 2012 22:53:01 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 22:53:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340232781; x=1371768781;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=Px5skNGYj2B1iLm6OhdALa9erwEo2B8T4BnIkgHBn7o=;
	b=a0Jxg3qyQpLtJR+KTCV3gawgkCCxPTP5BAA2xkJCTeXyzYXz2jKHbPI0
	w5q4ownvmI1dKSyDYtqZ5FdnGopd+A==;
X-IronPort-AV: E=Sophos;i="4.77,447,1336348800"; d="scan'208";a="251689824"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 22:52:55 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5KMqs1b022126; Wed, 20 Jun 2012 22:52:54 GMT
MIME-Version: 1.0
Message-Id: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Jun 2012 22:51:48 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 removed all the LIBLEAF bits in this version, but kept passing
the libfsimage plugin location via compiler command line.

If there's a better way to do this, I'm certainly open to it. But
looking at it further today I think this isn't too horrible.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 22:53:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 22: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 1ShTln-0007nT-MT; Wed, 20 Jun 2012 22:53:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShTlm-0007nN-QY
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 22:53:02 +0000
Received: from [193.109.254.147:61618] by server-10.bemta-14.messagelabs.com
	id 10/BF-05433-E4452EF4; Wed, 20 Jun 2012 22:53:02 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340232779!10744455!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzUxMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2744 invoked from network); 20 Jun 2012 22:53:01 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 22:53:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340232781; x=1371768781;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=Px5skNGYj2B1iLm6OhdALa9erwEo2B8T4BnIkgHBn7o=;
	b=a0Jxg3qyQpLtJR+KTCV3gawgkCCxPTP5BAA2xkJCTeXyzYXz2jKHbPI0
	w5q4ownvmI1dKSyDYtqZ5FdnGopd+A==;
X-IronPort-AV: E=Sophos;i="4.77,447,1336348800"; d="scan'208";a="251689824"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 22:52:55 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5KMqs1b022126; Wed, 20 Jun 2012 22:52:54 GMT
MIME-Version: 1.0
Message-Id: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Jun 2012 22:51:48 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 removed all the LIBLEAF bits in this version, but kept passing
the libfsimage plugin location via compiler command line.

If there's a better way to do this, I'm certainly open to it. But
looking at it further today I think this isn't too horrible.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 22:53:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 22: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 1ShTlp-0007ne-1o; Wed, 20 Jun 2012 22:53:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShTln-0007nS-Pp
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 22:53:04 +0000
Received: from [193.109.254.147:22259] by server-11.bemta-14.messagelabs.com
	id 3C/B5-24843-F4452EF4; Wed, 20 Jun 2012 22:53:03 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340232779!10744455!2
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzUxMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2782 invoked from network); 20 Jun 2012 22:53:02 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 22:53:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340232782; x=1371768782;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=O4Xv1I+5mnxBpIrYHN/9x7ty/J263ONQ4m6o9miZsbA=;
	b=YGzYPkX7fSokzjtz2kJKq/ySuPTXALFxXCD3YSZWqy9Y6Xlg68pFvk7f
	i9ysd3H/BtCrmeo1JeL6SxftPEJa9Q==;
X-IronPort-AV: E=Sophos;i="4.77,447,1336348800"; d="scan'208";a="251689829"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 22:52:56 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5KMqs1c022126; Wed, 20 Jun 2012 22:52:55 GMT
MIME-Version: 1.0
X-Mercurial-Node: 4ba90ad045963033e72c25d4d11f5d1caec23814
Message-Id: <4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
In-Reply-To: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Jun 2012 22:51:49 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shared libraries are automatically installed into /usr/lib
or /usr/lib64, depending on the supplied --prefix value and
$(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.

With this change, packagers can supply the desired location for shared
libraries on the ./configure command line. Packagers need to note that
the default behaviour on 64-bit Linux systems will be to install shared
libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
to ./configure.

Additionally, the libfsimage plugins are now loaded explicitly from
$LIBDIR/fs, removing platform-based decision trees in code.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 4ba90ad04596 Config.mk
--- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -43,6 +43,7 @@ endif
 
 include $(XEN_ROOT)/config/$(XEN_OS).mk
 include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
+include $(XEN_ROOT)/config/Tools.mk
 
 SHAREDIR    ?= $(PREFIX)/share
 DOCDIR      ?= $(SHAREDIR)/doc/xen
@@ -67,7 +68,7 @@ endef
 
 ifneq ($(EXTRA_PREFIX),)
 EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
-EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
+EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
 endif
 
 PYTHON      ?= python
diff -r 32034d1914a6 -r 4ba90ad04596 config/NetBSD.mk
--- a/config/NetBSD.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/NetBSD.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,7 +1,6 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
 # Override settings for this OS
-LIBLEAFDIR_x86_64 = lib
 LIBEXEC = $(PREFIX)/libexec
 PRIVATE_BINDIR = $(BINDIR)
 
diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
--- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
-LIBEXEC = $(LIBDIR_x86_32)/xen/bin
+LIBEXEC = $(PREFIX)/lib/xen/bin
 SHAREDIR = $(PREFIX)/share
 MANDIR = $(SHAREDIR)/man
 MAN1DIR = $(MANDIR)/man1
diff -r 32034d1914a6 -r 4ba90ad04596 config/SunOS.mk
--- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -22,10 +22,6 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_64 = lib/amd64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 MANDIR = $(PREFIX)/share/man
 MAN1DIR = $(MANDIR)/man1
 MAN8DIR = $(MANDIR)/man8
diff -r 32034d1914a6 -r 4ba90ad04596 config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
@@ -1,6 +1,7 @@
 # Prefix and install folder
 PREFIX              := @prefix@
-LIBLEAFDIR_x86_64   := @LIB_PATH@
+exec_prefix         := @exec_prefix@
+LIBDIR              := @libdir@
 
 # A debug build of tools?
 debug               := @debug@
diff -r 32034d1914a6 -r 4ba90ad04596 config/x86_64.mk
--- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -10,9 +10,6 @@ CONFIG_IOEMU := y
 
 CFLAGS += -m64
 
-LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
-LIBDIR = $(LIBDIR_x86_64)
-
 SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
 
 # Use only if calling $(LD) directly.
diff -r 32034d1914a6 -r 4ba90ad04596 tools/libfsimage/Rules.mk
--- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,17 +1,12 @@
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
+CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
 CFLAGS += -Werror -D_GNU_SOURCE
 LDFLAGS += -L../common/
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
 
-FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
-FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
-FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
-FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
-FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
-FSDIR = $(FSDIR-y)
+FSDIR = $(LIBDIR)/fs
 
 FSLIB = fsimage.so
 
@@ -20,8 +15,8 @@ fs-all: $(FSLIB)
 
 .PHONY: fs-install
 fs-install: fs-all
-	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
-	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
+	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
 
 $(FSLIB): $(PIC_OBJS)
 	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
diff -r 32034d1914a6 -r 4ba90ad04596 tools/libfsimage/common/Makefile
--- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,5 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 MAJOR = 1.0
 MINOR = 0
diff -r 32034d1914a6 -r 4ba90ad04596 tools/libfsimage/common/fsimage_plugin.c
--- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
@@ -122,7 +122,6 @@ fail:
 static int load_plugins(void)
 {
 	const char *fsdir = getenv("FSIMAGE_FSDIR");
-	const char *isadir = "";
 	struct dirent *dp = NULL;
 	struct dirent *dpp;
 	DIR *dir = NULL;
@@ -131,27 +130,12 @@ static int load_plugins(void)
 	int err;
 	int ret = -1;
 
-#if defined(FSIMAGE_FSDIR)
+#if !defined(FSIMAGE_FSDIR)
+#error FSIMAGE_FSDIR not defined
+#else
 	if (fsdir == NULL)
 		fsdir = FSIMAGE_FSDIR;
-#elif defined(__sun__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-
-	if (sizeof(void *) == 8)
-		isadir = "64/";
-#elif defined(__ia64__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-#else
-	if (fsdir == NULL) {
-		if (sizeof(void *) == 8)
-			fsdir = "/usr/lib64/fs";
-		else
-			fsdir = "/usr/lib/fs";
-	}
 #endif
-
 	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
 		goto fail;
 
@@ -172,8 +156,8 @@ static int load_plugins(void)
 		if (strcmp(dpp->d_name, "..") == 0)
 			continue;
 
-		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
-		    dpp->d_name, isadir);
+		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
+			dpp->d_name);
 
 		if (init_plugin(tmp) != 0)
 			goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 22:53:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 22: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 1ShTlp-0007ne-1o; Wed, 20 Jun 2012 22:53:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShTln-0007nS-Pp
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 22:53:04 +0000
Received: from [193.109.254.147:22259] by server-11.bemta-14.messagelabs.com
	id 3C/B5-24843-F4452EF4; Wed, 20 Jun 2012 22:53:03 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340232779!10744455!2
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzUxMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2782 invoked from network); 20 Jun 2012 22:53:02 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 22:53:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340232782; x=1371768782;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=O4Xv1I+5mnxBpIrYHN/9x7ty/J263ONQ4m6o9miZsbA=;
	b=YGzYPkX7fSokzjtz2kJKq/ySuPTXALFxXCD3YSZWqy9Y6Xlg68pFvk7f
	i9ysd3H/BtCrmeo1JeL6SxftPEJa9Q==;
X-IronPort-AV: E=Sophos;i="4.77,447,1336348800"; d="scan'208";a="251689829"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2012 22:52:56 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5KMqs1c022126; Wed, 20 Jun 2012 22:52:55 GMT
MIME-Version: 1.0
X-Mercurial-Node: 4ba90ad045963033e72c25d4d11f5d1caec23814
Message-Id: <4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
In-Reply-To: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Jun 2012 22:51:49 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shared libraries are automatically installed into /usr/lib
or /usr/lib64, depending on the supplied --prefix value and
$(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.

With this change, packagers can supply the desired location for shared
libraries on the ./configure command line. Packagers need to note that
the default behaviour on 64-bit Linux systems will be to install shared
libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
to ./configure.

Additionally, the libfsimage plugins are now loaded explicitly from
$LIBDIR/fs, removing platform-based decision trees in code.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 4ba90ad04596 Config.mk
--- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -43,6 +43,7 @@ endif
 
 include $(XEN_ROOT)/config/$(XEN_OS).mk
 include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
+include $(XEN_ROOT)/config/Tools.mk
 
 SHAREDIR    ?= $(PREFIX)/share
 DOCDIR      ?= $(SHAREDIR)/doc/xen
@@ -67,7 +68,7 @@ endef
 
 ifneq ($(EXTRA_PREFIX),)
 EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
-EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
+EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
 endif
 
 PYTHON      ?= python
diff -r 32034d1914a6 -r 4ba90ad04596 config/NetBSD.mk
--- a/config/NetBSD.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/NetBSD.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,7 +1,6 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
 # Override settings for this OS
-LIBLEAFDIR_x86_64 = lib
 LIBEXEC = $(PREFIX)/libexec
 PRIVATE_BINDIR = $(BINDIR)
 
diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
--- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
-LIBEXEC = $(LIBDIR_x86_32)/xen/bin
+LIBEXEC = $(PREFIX)/lib/xen/bin
 SHAREDIR = $(PREFIX)/share
 MANDIR = $(SHAREDIR)/man
 MAN1DIR = $(MANDIR)/man1
diff -r 32034d1914a6 -r 4ba90ad04596 config/SunOS.mk
--- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -22,10 +22,6 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_64 = lib/amd64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 MANDIR = $(PREFIX)/share/man
 MAN1DIR = $(MANDIR)/man1
 MAN8DIR = $(MANDIR)/man8
diff -r 32034d1914a6 -r 4ba90ad04596 config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
@@ -1,6 +1,7 @@
 # Prefix and install folder
 PREFIX              := @prefix@
-LIBLEAFDIR_x86_64   := @LIB_PATH@
+exec_prefix         := @exec_prefix@
+LIBDIR              := @libdir@
 
 # A debug build of tools?
 debug               := @debug@
diff -r 32034d1914a6 -r 4ba90ad04596 config/x86_64.mk
--- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -10,9 +10,6 @@ CONFIG_IOEMU := y
 
 CFLAGS += -m64
 
-LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
-LIBDIR = $(LIBDIR_x86_64)
-
 SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
 
 # Use only if calling $(LD) directly.
diff -r 32034d1914a6 -r 4ba90ad04596 tools/libfsimage/Rules.mk
--- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,17 +1,12 @@
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
+CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
 CFLAGS += -Werror -D_GNU_SOURCE
 LDFLAGS += -L../common/
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
 
-FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
-FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
-FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
-FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
-FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
-FSDIR = $(FSDIR-y)
+FSDIR = $(LIBDIR)/fs
 
 FSLIB = fsimage.so
 
@@ -20,8 +15,8 @@ fs-all: $(FSLIB)
 
 .PHONY: fs-install
 fs-install: fs-all
-	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
-	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
+	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
 
 $(FSLIB): $(PIC_OBJS)
 	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
diff -r 32034d1914a6 -r 4ba90ad04596 tools/libfsimage/common/Makefile
--- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,5 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 MAJOR = 1.0
 MINOR = 0
diff -r 32034d1914a6 -r 4ba90ad04596 tools/libfsimage/common/fsimage_plugin.c
--- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
@@ -122,7 +122,6 @@ fail:
 static int load_plugins(void)
 {
 	const char *fsdir = getenv("FSIMAGE_FSDIR");
-	const char *isadir = "";
 	struct dirent *dp = NULL;
 	struct dirent *dpp;
 	DIR *dir = NULL;
@@ -131,27 +130,12 @@ static int load_plugins(void)
 	int err;
 	int ret = -1;
 
-#if defined(FSIMAGE_FSDIR)
+#if !defined(FSIMAGE_FSDIR)
+#error FSIMAGE_FSDIR not defined
+#else
 	if (fsdir == NULL)
 		fsdir = FSIMAGE_FSDIR;
-#elif defined(__sun__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-
-	if (sizeof(void *) == 8)
-		isadir = "64/";
-#elif defined(__ia64__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-#else
-	if (fsdir == NULL) {
-		if (sizeof(void *) == 8)
-			fsdir = "/usr/lib64/fs";
-		else
-			fsdir = "/usr/lib/fs";
-	}
 #endif
-
 	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
 		goto fail;
 
@@ -172,8 +156,8 @@ static int load_plugins(void)
 		if (strcmp(dpp->d_name, "..") == 0)
 			continue;
 
-		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
-		    dpp->d_name, isadir);
+		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
+			dpp->d_name);
 
 		if (init_plugin(tmp) != 0)
 			goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 23:26:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 23:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShUHZ-0000al-W6; Wed, 20 Jun 2012 23:25:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ShUHY-0000ag-Rf
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 23:25:53 +0000
Received: from [193.109.254.147:43557] by server-2.bemta-14.messagelabs.com id
	30/F2-01735-00C52EF4; Wed, 20 Jun 2012 23:25:52 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340234744!10747077!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14410 invoked from network); 20 Jun 2012 23:25:46 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 23:25:46 -0000
Received: by obbef5 with SMTP id ef5so58216obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 20 Jun 2012 16:25:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=AeAtPjdozvxOccjc91mzGiJNhRQmnJXr0tiDbWre5Yw=;
	b=jHJjVM/ShriM9qjb55DllF9TSoqOtmuRsixZdeedhh5mhyIT1EW8dSVUKYNK8jhWPe
	GSUJy6ee37wrS9GfwXjUP2gsbDLRagxEsw1c5rDmbvIVZJwcn/7ItbfS+0P9UCxi9IZ0
	gf8M9IhzocbAa9bbf9YhMLsFD8sXpwkDvSDs5VTRmrtb6PW1vBm/Q5N/qMi0ActXG+gG
	Mrq10WEP29u3cVIKim19QdxGm2iOXTs87MRa2MPNPFKROx2MNG1tPXVLWDEOVmriohAN
	+0rfgjyU51fG5iRrLSQQELQD2McL5hKe36Yc3+gAHyDEto3NLja4Q1HuZ4h1sNqCYm9A
	Rc/g==
Received: by 10.182.14.101 with SMTP id o5mr14616545obc.1.1340234744258; Wed,
	20 Jun 2012 16:25:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 20 Jun 2012 16:25:24 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
References: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 21 Jun 2012 01:25:24 +0200
Message-ID: <CABs9Ej=TpBUyLaPB0FMmL+oZUeZtJTjTAb=gX3nOJY9p5k5yiw@mail.gmail.com>
To: Paul S <pstroud@gmail.com>
X-Gm-Message-State: ALoCoQkCvS+ZxJ/0/PoUZoDRXwLKsDxR/G7Q8qlPH0snW5HS3HI3GgUOC5x2JbrkgVoAkvc1lh5Z
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 4.2-Unstable Crash/Reboot(i5 2500/DQ67SW)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 21, 2012 at 12:16 AM, Paul S <pstroud@gmail.com> wrote:
> Environment: Xen-4.2 Unstable - built about a week ago
> =A0 =A0 =A0 =A0 =A0 =A0 =A0OS: Fedora 17
> =A0 =A0 =A0 =A0 =A0 =A0CPU: i5 2500
> Motherboard: DQ67SW latest bios
>
> Trying to get passthrough working, 4.1.2 Bluescreens going into windows,
> figured I probably needed some of the patches in 4.2, built it and it just
> crashes and reboots. Installed a Serial card, got the terminal working and
> was able to capture the crash. I have also included the dmidecode CPU and
> BIOS from the normal Fedora 17 kernel(non-xen).
>

The crash you get with 4.2 looks like the issue I had recently, see
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00998.html

Add xsave=3D0 to the Xen kernel line in grub, or use a newer dom0 kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 20 23:26:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Jun 2012 23:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShUHZ-0000al-W6; Wed, 20 Jun 2012 23:25:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ShUHY-0000ag-Rf
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 23:25:53 +0000
Received: from [193.109.254.147:43557] by server-2.bemta-14.messagelabs.com id
	30/F2-01735-00C52EF4; Wed, 20 Jun 2012 23:25:52 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340234744!10747077!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14410 invoked from network); 20 Jun 2012 23:25:46 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jun 2012 23:25:46 -0000
Received: by obbef5 with SMTP id ef5so58216obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 20 Jun 2012 16:25:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=AeAtPjdozvxOccjc91mzGiJNhRQmnJXr0tiDbWre5Yw=;
	b=jHJjVM/ShriM9qjb55DllF9TSoqOtmuRsixZdeedhh5mhyIT1EW8dSVUKYNK8jhWPe
	GSUJy6ee37wrS9GfwXjUP2gsbDLRagxEsw1c5rDmbvIVZJwcn/7ItbfS+0P9UCxi9IZ0
	gf8M9IhzocbAa9bbf9YhMLsFD8sXpwkDvSDs5VTRmrtb6PW1vBm/Q5N/qMi0ActXG+gG
	Mrq10WEP29u3cVIKim19QdxGm2iOXTs87MRa2MPNPFKROx2MNG1tPXVLWDEOVmriohAN
	+0rfgjyU51fG5iRrLSQQELQD2McL5hKe36Yc3+gAHyDEto3NLja4Q1HuZ4h1sNqCYm9A
	Rc/g==
Received: by 10.182.14.101 with SMTP id o5mr14616545obc.1.1340234744258; Wed,
	20 Jun 2012 16:25:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 20 Jun 2012 16:25:24 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
References: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 21 Jun 2012 01:25:24 +0200
Message-ID: <CABs9Ej=TpBUyLaPB0FMmL+oZUeZtJTjTAb=gX3nOJY9p5k5yiw@mail.gmail.com>
To: Paul S <pstroud@gmail.com>
X-Gm-Message-State: ALoCoQkCvS+ZxJ/0/PoUZoDRXwLKsDxR/G7Q8qlPH0snW5HS3HI3GgUOC5x2JbrkgVoAkvc1lh5Z
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 4.2-Unstable Crash/Reboot(i5 2500/DQ67SW)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 21, 2012 at 12:16 AM, Paul S <pstroud@gmail.com> wrote:
> Environment: Xen-4.2 Unstable - built about a week ago
> =A0 =A0 =A0 =A0 =A0 =A0 =A0OS: Fedora 17
> =A0 =A0 =A0 =A0 =A0 =A0CPU: i5 2500
> Motherboard: DQ67SW latest bios
>
> Trying to get passthrough working, 4.1.2 Bluescreens going into windows,
> figured I probably needed some of the patches in 4.2, built it and it just
> crashes and reboots. Installed a Serial card, got the terminal working and
> was able to capture the crash. I have also included the dmidecode CPU and
> BIOS from the normal Fedora 17 kernel(non-xen).
>

The crash you get with 4.2 looks like the issue I had recently, see
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00998.html

Add xsave=3D0 to the Xen kernel line in grub, or use a newer dom0 kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 00:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 00:35: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 1ShVM8-00021n-AT; Thu, 21 Jun 2012 00:34:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1ShVM6-00021i-Ez
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 00:34:38 +0000
Received: from [85.158.143.99:37293] by server-3.bemta-4.messagelabs.com id
	DA/E0-05808-D1C62EF4; Thu, 21 Jun 2012 00:34:37 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340238876!28320962!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3571 invoked from network); 21 Jun 2012 00:34:37 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 00:34:37 -0000
Received: by yenl1 with SMTP id l1so52484yen.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 17:34:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=k+Tc+yMtN6l3fHI86T1H/GpHVF0ErsTLJs4uMQqCSXE=;
	b=b/BOuWUuUbWuRhgPvBtoPFAXZz9TfRZYBv6baCtNkGRs+7OPeDvLWzxquJICymlba1
	LTk4YjpRnKTE3wFiW+rQeNncaFSW+KI/mrl7SrRKSJHuKVxne/Bliom6ASE1aCpp/NJu
	JQ8s73gVgEnS67xqvLgYq3TS66StI50hBR+zJjPeEW38zIxYGHsh2qbnvYQupncRFOWK
	k0FaEJK+wv7yIPWSxFRqu5MXDmwSjjuWXQUU2wHyFAWnrKp1JdBxZOFPuHV+7z/XKM4V
	n6YBjlhQgcIP6IszYYLAottUZGWHsohwtANPA6UtgMmI3ZyRQpUM0GFSMAXDsAwbALBD
	Og4A==
Received: by 10.236.153.104 with SMTP id e68mr30085826yhk.36.1340238875780;
	Wed, 20 Jun 2012 17:34:35 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id y63sm101131024yha.9.2012.06.20.17.34.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 20 Jun 2012 17:34:35 -0700 (PDT)
Message-ID: <4FE26C0E.9070104@gmail.com>
Date: Wed, 20 Jun 2012 20:34:22 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen 4.2
	rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0760382024588517640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============0760382024588517640==
Content-Type: multipart/alternative;
 boundary="------------060306010903060306020708"

This is a multi-part message in MIME format.
--------------060306010903060306020708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Just out of annoyance more than curiosity, but ever since I started 
using Xen 4.2-unstable rev-25467, every time I try to run "sudo xl 
create <domu_config_file>", or "sudo xl reboot", or "sudo xl destroy", 
it always gives me this message:

"*xend is running, which prevents xl from working correctly.
If you still want to force the execution of xl please use the -f option*"

I am now forced to use the "-f" option anytime i am using the xl 
toolstack. It never used to be that way going back to Xen 4.2-unstable 
rev-25459. I was reading something about this a while ago on the 
Xen-devel list, but forget what.

SOOO, any logical reason for the need to use the FORCE option every time 
you run the XL command? AND assuming it is not something on my setup 
that is causing it, will it always stay like this in future revisions?

Thank you for any enlightening

--------------060306010903060306020708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Just out of annoyance more than curiosity, but ever since I started
    using Xen 4.2-unstable rev-25467, every time I try to run "sudo xl
    create &lt;domu_config_file&gt;", or "sudo xl reboot", or "sudo xl
    destroy", it always gives me this message:<br>
    <br>
    "<b>xend is running, which prevents xl from working correctly.<br>
      If you still want to force the execution of xl please use the -f
      option</b>"<br>
    <br>
    I am now forced to use the "-f" option anytime i am using the xl
    toolstack. It never used to be that way going back to Xen
    4.2-unstable rev-25459. I was reading something about this a while
    ago on the Xen-devel list, but forget what.<br>
    <br>
    SOOO, any logical reason for the need to use the FORCE option every
    time you run the XL command? AND assuming it is not something on my
    setup that is causing it, will it always stay like this in future
    revisions? <br>
    <br>
    Thank you for any enlightening <br>
  </body>
</html>

--------------060306010903060306020708--


--===============0760382024588517640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0760382024588517640==--


From xen-devel-bounces@lists.xen.org Thu Jun 21 00:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 00:35: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 1ShVM8-00021n-AT; Thu, 21 Jun 2012 00:34:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1ShVM6-00021i-Ez
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 00:34:38 +0000
Received: from [85.158.143.99:37293] by server-3.bemta-4.messagelabs.com id
	DA/E0-05808-D1C62EF4; Thu, 21 Jun 2012 00:34:37 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340238876!28320962!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3571 invoked from network); 21 Jun 2012 00:34:37 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 00:34:37 -0000
Received: by yenl1 with SMTP id l1so52484yen.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 17:34:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=k+Tc+yMtN6l3fHI86T1H/GpHVF0ErsTLJs4uMQqCSXE=;
	b=b/BOuWUuUbWuRhgPvBtoPFAXZz9TfRZYBv6baCtNkGRs+7OPeDvLWzxquJICymlba1
	LTk4YjpRnKTE3wFiW+rQeNncaFSW+KI/mrl7SrRKSJHuKVxne/Bliom6ASE1aCpp/NJu
	JQ8s73gVgEnS67xqvLgYq3TS66StI50hBR+zJjPeEW38zIxYGHsh2qbnvYQupncRFOWK
	k0FaEJK+wv7yIPWSxFRqu5MXDmwSjjuWXQUU2wHyFAWnrKp1JdBxZOFPuHV+7z/XKM4V
	n6YBjlhQgcIP6IszYYLAottUZGWHsohwtANPA6UtgMmI3ZyRQpUM0GFSMAXDsAwbALBD
	Og4A==
Received: by 10.236.153.104 with SMTP id e68mr30085826yhk.36.1340238875780;
	Wed, 20 Jun 2012 17:34:35 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id y63sm101131024yha.9.2012.06.20.17.34.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 20 Jun 2012 17:34:35 -0700 (PDT)
Message-ID: <4FE26C0E.9070104@gmail.com>
Date: Wed, 20 Jun 2012 20:34:22 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen 4.2
	rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0760382024588517640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============0760382024588517640==
Content-Type: multipart/alternative;
 boundary="------------060306010903060306020708"

This is a multi-part message in MIME format.
--------------060306010903060306020708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Just out of annoyance more than curiosity, but ever since I started 
using Xen 4.2-unstable rev-25467, every time I try to run "sudo xl 
create <domu_config_file>", or "sudo xl reboot", or "sudo xl destroy", 
it always gives me this message:

"*xend is running, which prevents xl from working correctly.
If you still want to force the execution of xl please use the -f option*"

I am now forced to use the "-f" option anytime i am using the xl 
toolstack. It never used to be that way going back to Xen 4.2-unstable 
rev-25459. I was reading something about this a while ago on the 
Xen-devel list, but forget what.

SOOO, any logical reason for the need to use the FORCE option every time 
you run the XL command? AND assuming it is not something on my setup 
that is causing it, will it always stay like this in future revisions?

Thank you for any enlightening

--------------060306010903060306020708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Just out of annoyance more than curiosity, but ever since I started
    using Xen 4.2-unstable rev-25467, every time I try to run "sudo xl
    create &lt;domu_config_file&gt;", or "sudo xl reboot", or "sudo xl
    destroy", it always gives me this message:<br>
    <br>
    "<b>xend is running, which prevents xl from working correctly.<br>
      If you still want to force the execution of xl please use the -f
      option</b>"<br>
    <br>
    I am now forced to use the "-f" option anytime i am using the xl
    toolstack. It never used to be that way going back to Xen
    4.2-unstable rev-25459. I was reading something about this a while
    ago on the Xen-devel list, but forget what.<br>
    <br>
    SOOO, any logical reason for the need to use the FORCE option every
    time you run the XL command? AND assuming it is not something on my
    setup that is causing it, will it always stay like this in future
    revisions? <br>
    <br>
    Thank you for any enlightening <br>
  </body>
</html>

--------------060306010903060306020708--


--===============0760382024588517640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0760382024588517640==--


From xen-devel-bounces@lists.xen.org Thu Jun 21 00:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 00: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 1ShVW8-0002DW-4Z; Thu, 21 Jun 2012 00:45:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <palutke.ralph@gmx.de>) id 1ShVW7-0002DR-2a
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 00:44:59 +0000
Received: from [85.158.143.99:61361] by server-1.bemta-4.messagelabs.com id
	71/9F-24392-A8E62EF4; Thu, 21 Jun 2012 00:44:58 +0000
X-Env-Sender: palutke.ralph@gmx.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340239497!23024747!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyNjI5Mw==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyNjI5Mw==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7792 invoked from network); 21 Jun 2012 00:44:57 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-2.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 00:44:57 -0000
Received: (qmail invoked by alias); 21 Jun 2012 00:44:56 -0000
Received: from p4FFE7DE8.dip.t-dialin.net (EHLO gmx.de) [79.254.125.232]
	by mail.gmx.net (mp012) with SMTP; 21 Jun 2012 02:44:56 +0200
X-Authenticated: #110968699
X-Provags-ID: V01U2FsdGVkX1+wJ2FkBy6wY2h6TQQko4qRSpC/mQBFebEiPMre08
	tH8jZrOT3zvLp9
Received: by gmx.de (sSMTP sendmail emulation); Thu, 21 Jun 2012 02:44:48 +0200
From: palutke.ralph@gmx.de
Date: Thu, 21 Jun 2012 02:44:48 +0200
To: xen-devel@lists.xen.org
Message-ID: <20120621004447.GA12981@mean_maschine.fritz.box>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] how to check for already existing 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 guys, 

let me shortly introduce myself. I'm a student and recently work on my bachelor thesis. My goal is to write a little hypervisor.
I'm not quite sure if this is the right mailing list, but i guess you'll gonna tell me.
i have two quick questions:

1. before i can use the vmxon instruction i do have to set vmxe flag in cr4 register. but what if some hypervisor is already running? is there a way to check 
if one is running??

2. before i set the vmxe bit in cr4, i check if it is already enabled. i do this while my module gets loaded. but i observed a strange thing. sometimes
the vmxe bit seems to be set while the other time it isn't. do you have any explanation for that behaviour? do i have to check if the bit is set before 
actually setting it? I've looked at a few hypervisor projects and it seems that no one does it. my primary thought was, if the bit is set a hypervisor is running, 
but i don't think that's true anymore. so do i need the check?

greetings 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 00:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 00: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 1ShVW8-0002DW-4Z; Thu, 21 Jun 2012 00:45:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <palutke.ralph@gmx.de>) id 1ShVW7-0002DR-2a
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 00:44:59 +0000
Received: from [85.158.143.99:61361] by server-1.bemta-4.messagelabs.com id
	71/9F-24392-A8E62EF4; Thu, 21 Jun 2012 00:44:58 +0000
X-Env-Sender: palutke.ralph@gmx.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340239497!23024747!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyNjI5Mw==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyNjI5Mw==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7792 invoked from network); 21 Jun 2012 00:44:57 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-2.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 00:44:57 -0000
Received: (qmail invoked by alias); 21 Jun 2012 00:44:56 -0000
Received: from p4FFE7DE8.dip.t-dialin.net (EHLO gmx.de) [79.254.125.232]
	by mail.gmx.net (mp012) with SMTP; 21 Jun 2012 02:44:56 +0200
X-Authenticated: #110968699
X-Provags-ID: V01U2FsdGVkX1+wJ2FkBy6wY2h6TQQko4qRSpC/mQBFebEiPMre08
	tH8jZrOT3zvLp9
Received: by gmx.de (sSMTP sendmail emulation); Thu, 21 Jun 2012 02:44:48 +0200
From: palutke.ralph@gmx.de
Date: Thu, 21 Jun 2012 02:44:48 +0200
To: xen-devel@lists.xen.org
Message-ID: <20120621004447.GA12981@mean_maschine.fritz.box>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] how to check for already existing 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 guys, 

let me shortly introduce myself. I'm a student and recently work on my bachelor thesis. My goal is to write a little hypervisor.
I'm not quite sure if this is the right mailing list, but i guess you'll gonna tell me.
i have two quick questions:

1. before i can use the vmxon instruction i do have to set vmxe flag in cr4 register. but what if some hypervisor is already running? is there a way to check 
if one is running??

2. before i set the vmxe bit in cr4, i check if it is already enabled. i do this while my module gets loaded. but i observed a strange thing. sometimes
the vmxe bit seems to be set while the other time it isn't. do you have any explanation for that behaviour? do i have to check if the bit is set before 
actually setting it? I've looked at a few hypervisor projects and it seems that no one does it. my primary thought was, if the bit is set a hypervisor is running, 
but i don't think that's true anymore. so do i need the check?

greetings 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 02:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 02: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 1ShWoT-0007as-34; Thu, 21 Jun 2012 02:08:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ShWoS-0007an-87
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 02:08:00 +0000
Received: from [85.158.143.35:10150] by server-2.bemta-4.messagelabs.com id
	7E/20-17938-FF182EF4; Thu, 21 Jun 2012 02:07:59 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340244477!14138253!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24914 invoked from network); 21 Jun 2012 02:07:59 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 02:07:59 -0000
Received: by obbta14 with SMTP id ta14so271245obb.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 19:07:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=iY7URV+jA/VFTq34j3W3HKOM3SheWNJDLHEC6h4nXVM=;
	b=VrYNisB+6e2GbPyXZZnrGyYYkfmdf/vwwKlniORYACw7E5q8SQNuOOF9QuA9FZkYkj
	I6PoQqH98G5eLynFc9K7taVvdeu2oWYOfE/Qy28rb2fuOZmW6FyIvx1eDSX+U8UBIauY
	7vmP4ttZSyqdarPt4/UIPLfUcY/PwaLqHas0B1QaQX1NEVgKTqb+/pKKG/NvzcC9r9Fi
	5VKKxcDudHObwzHLtRZ9nt+mlhIqo5R7D9lSNuZsCW2k8oOaICaa4gXlRhoQfNZZshis
	SuOFbraQQgIKLRKQB5dYOoU9s52DQvg1irHcxaA8R6qP1GTOOSVCRKIzD2Sj+v3KQZSs
	lHxA==
Received: by 10.182.197.65 with SMTP id is1mr25904363obc.27.1340244477276;
	Wed, 20 Jun 2012 19:07:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 20 Jun 2012 19:07:36 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE26C0E.9070104@gmail.com>
References: <4FE26C0E.9070104@gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 21 Jun 2012 04:07:36 +0200
Message-ID: <CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
To: cyberhawk001@gmail.com
X-Gm-Message-State: ALoCoQnoaRUjtMsCuzWvCUn/Yp735FEYxU4MNFlO4gA07GW8fvODogVSZxAXU729iL61kXjwM0Wv
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
	4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 2:34 AM,  <cyberhawk001@gmail.com> wrote:
> Just out of annoyance more than curiosity, but ever since I started using
> Xen 4.2-unstable rev-25467, every time I try to run "sudo xl create
> <domu_config_file>", or "sudo xl reboot", or "sudo xl destroy", it always
> gives me this message:
>
> "xend is running, which prevents xl from working correctly.
> If you still want to force the execution of xl please use the -f option"
>
> I am now forced to use the "-f" option anytime i am using the xl toolstack.
> It never used to be that way going back to Xen 4.2-unstable rev-25459. I was
> reading something about this a while ago on the Xen-devel list, but forget
> what.
>
> SOOO, any logical reason for the need to use the FORCE option every time you
> run the XL command? AND assuming it is not something on my setup that is
> causing it, will it always stay like this in future revisions?
>

Xend and xl are part of different toolstacks and should not be used
together. You should investigate why you have xend running, most
likely it shouldn't be.

Xen 4.2 and newer have the xl toolstack as default.
Xen 4.1 and older have the xend/xm toolstack as default.

See http://wiki.xen.org/wiki/Choice_of_Toolstacks for more info.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 02:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 02: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 1ShWoT-0007as-34; Thu, 21 Jun 2012 02:08:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1ShWoS-0007an-87
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 02:08:00 +0000
Received: from [85.158.143.35:10150] by server-2.bemta-4.messagelabs.com id
	7E/20-17938-FF182EF4; Thu, 21 Jun 2012 02:07:59 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340244477!14138253!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24914 invoked from network); 21 Jun 2012 02:07:59 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 02:07:59 -0000
Received: by obbta14 with SMTP id ta14so271245obb.32
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 19:07:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=iY7URV+jA/VFTq34j3W3HKOM3SheWNJDLHEC6h4nXVM=;
	b=VrYNisB+6e2GbPyXZZnrGyYYkfmdf/vwwKlniORYACw7E5q8SQNuOOF9QuA9FZkYkj
	I6PoQqH98G5eLynFc9K7taVvdeu2oWYOfE/Qy28rb2fuOZmW6FyIvx1eDSX+U8UBIauY
	7vmP4ttZSyqdarPt4/UIPLfUcY/PwaLqHas0B1QaQX1NEVgKTqb+/pKKG/NvzcC9r9Fi
	5VKKxcDudHObwzHLtRZ9nt+mlhIqo5R7D9lSNuZsCW2k8oOaICaa4gXlRhoQfNZZshis
	SuOFbraQQgIKLRKQB5dYOoU9s52DQvg1irHcxaA8R6qP1GTOOSVCRKIzD2Sj+v3KQZSs
	lHxA==
Received: by 10.182.197.65 with SMTP id is1mr25904363obc.27.1340244477276;
	Wed, 20 Jun 2012 19:07:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 20 Jun 2012 19:07:36 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE26C0E.9070104@gmail.com>
References: <4FE26C0E.9070104@gmail.com>
From: Rolu <rolu@roce.org>
Date: Thu, 21 Jun 2012 04:07:36 +0200
Message-ID: <CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
To: cyberhawk001@gmail.com
X-Gm-Message-State: ALoCoQnoaRUjtMsCuzWvCUn/Yp735FEYxU4MNFlO4gA07GW8fvODogVSZxAXU729iL61kXjwM0Wv
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
	4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 2:34 AM,  <cyberhawk001@gmail.com> wrote:
> Just out of annoyance more than curiosity, but ever since I started using
> Xen 4.2-unstable rev-25467, every time I try to run "sudo xl create
> <domu_config_file>", or "sudo xl reboot", or "sudo xl destroy", it always
> gives me this message:
>
> "xend is running, which prevents xl from working correctly.
> If you still want to force the execution of xl please use the -f option"
>
> I am now forced to use the "-f" option anytime i am using the xl toolstack.
> It never used to be that way going back to Xen 4.2-unstable rev-25459. I was
> reading something about this a while ago on the Xen-devel list, but forget
> what.
>
> SOOO, any logical reason for the need to use the FORCE option every time you
> run the XL command? AND assuming it is not something on my setup that is
> causing it, will it always stay like this in future revisions?
>

Xend and xl are part of different toolstacks and should not be used
together. You should investigate why you have xend running, most
likely it shouldn't be.

Xen 4.2 and newer have the xl toolstack as default.
Xen 4.1 and older have the xend/xm toolstack as default.

See http://wiki.xen.org/wiki/Choice_of_Toolstacks for more info.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 02:31:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 02: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 1ShXBF-000858-RS; Thu, 21 Jun 2012 02:31: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 1ShXBD-000853-Gt
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 02:31:31 +0000
Received: from [85.158.143.35:61454] by server-1.bemta-4.messagelabs.com id
	61/48-24392-28782EF4; Thu, 21 Jun 2012 02:31:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340245889!10168639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19574 invoked from network); 21 Jun 2012 02:31:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 02:31:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,448,1336348800"; d="scan'208";a="13135935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 02:31:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 03:31:29 +0100
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 1ShXBA-0000XM-R5;
	Thu, 21 Jun 2012 02:31:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShXBA-0008Vw-Lu;
	Thu, 21 Jun 2012 03:31:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13109-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 03:31:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13109: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13109 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13109/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b6a857411ba
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Jun 21 02:31:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 02: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 1ShXBF-000858-RS; Thu, 21 Jun 2012 02:31: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 1ShXBD-000853-Gt
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 02:31:31 +0000
Received: from [85.158.143.35:61454] by server-1.bemta-4.messagelabs.com id
	61/48-24392-28782EF4; Thu, 21 Jun 2012 02:31:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340245889!10168639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19574 invoked from network); 21 Jun 2012 02:31:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 02:31:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,448,1336348800"; d="scan'208";a="13135935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 02:31:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 03:31:29 +0100
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 1ShXBA-0000XM-R5;
	Thu, 21 Jun 2012 02:31:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShXBA-0008Vw-Lu;
	Thu, 21 Jun 2012 03:31:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13109-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 03:31:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13109: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13109 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13109/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b6a857411ba
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Jun 21 02:53:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 02:53: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 1ShXVh-0000KT-Ln; Thu, 21 Jun 2012 02:52:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1ShXVg-0000KM-56
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 02:52:40 +0000
Received: from [85.158.143.35:25996] by server-2.bemta-4.messagelabs.com id
	35/EE-17938-77C82EF4; Thu, 21 Jun 2012 02:52:39 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340247157!16084800!1
X-Originating-IP: [209.85.213.41]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14688 invoked from network); 21 Jun 2012 02:52:38 -0000
Received: from mail-yw0-f41.google.com (HELO mail-yw0-f41.google.com)
	(209.85.213.41)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 02:52:38 -0000
Received: by yhr47 with SMTP id 47so134743yhr.28
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 19:52:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=eysdiqGcy3jfcnntXAybttbiL16c8N/ioe6f2J2UTwM=;
	b=rEQIsSoR6p6Mxde1QhC3xl+bDrWdgSANRdLU59J+oWLJvZ/T6vZXx+3kn0k5yefaQf
	uBfP0S0X7cpcmDV4AoyNMgd8jB3RQ6nl20zb1dPFlhYNcsbGos+CKId2T66HtY3im4Og
	vk/WLQInVk1XfXLIhkZ9MlpGGAE0qKfQ7KHjDzeP+DOMKMvumzTL1ma5Mm0IhWpws167
	yzYu6mrspOXZTHkgRYE8UfJHY3Fy4FjmzVmTTV3S73Xb8iPJ3UQnQdCUJ8BZl+0+wFAP
	iOx5Uo7sqBbmMkYaH0kW1BVzqhsog0pKB5pzbnhBaRgfUBzF/9amKsM+yGG3XoOOWMEO
	OZcA==
Received: by 10.236.155.41 with SMTP id i29mr30257123yhk.115.1340247156787;
	Wed, 20 Jun 2012 19:52:36 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id f8sm38974361anm.16.2012.06.20.19.52.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 20 Jun 2012 19:52:35 -0700 (PDT)
Message-ID: <4FE28C67.30000@gmail.com>
Date: Wed, 20 Jun 2012 22:52:23 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
In-Reply-To: <CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
 4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8495108855433470291=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8495108855433470291==
Content-Type: multipart/alternative;
 boundary="------------090901050102060909010405"

This is a multi-part message in MIME format.
--------------090901050102060909010405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 6/20/2012 10:07 PM, Rolu wrote:
> On Thu, Jun 21, 2012 at 2:34 AM,<cyberhawk001@gmail.com>  wrote:
>> Just out of annoyance more than curiosity, but ever since I started using
>> Xen 4.2-unstable rev-25467, every time I try to run "sudo xl create
>> <domu_config_file>", or "sudo xl reboot", or "sudo xl destroy", it always
>> gives me this message:
>>
>> "xend is running, which prevents xl from working correctly.
>> If you still want to force the execution of xl please use the -f option"
>>
>> I am now forced to use the "-f" option anytime i am using the xl toolstack.
>> It never used to be that way going back to Xen 4.2-unstable rev-25459. I was
>> reading something about this a while ago on the Xen-devel list, but forget
>> what.
>>
>> SOOO, any logical reason for the need to use the FORCE option every time you
>> run the XL command? AND assuming it is not something on my setup that is
>> causing it, will it always stay like this in future revisions?
>>
> Xend and xl are part of different toolstacks and should not be used
> together. You should investigate why you have xend running, most
> likely it shouldn't be.
>
> Xen 4.2 and newer have the xl toolstack as default.
> Xen 4.1 and older have the xend/xm toolstack as default.
>
> Seehttp://wiki.xen.org/wiki/Choice_of_Toolstacks  for more info.

Yes i know the difference between XL and XM toolstacks and have been 
using Xen 4.2-unstable with XL since the beginning of my Xen journey. As 
i mentioned before, i never had this issue with a previous Xen 4.2 
person as i mentioned it, HOWEVER i have messed around with XCP and 
different version of Xen on this Debian before, SO very likely i forgot 
to remove or uninstall something between changes, just trying to figure 
out how to make it stop asking me to force anything.

I was checking to make sure XEND was stopped by running "*sudo 
/etc/init.d/xend stop*" and i get an error message as below:

*Traceback (most recent call last):
   file "usr/sbin/xen", line 36, in <module>
     from xen.xend.server import SrvDaemon
ImportError: No module named xen.xend.server*

WHICH also happens to be the exact same message i have been getting 
every time i shut down Dom0 for quite a while now and been meaning to 
ask about that.

Once i run "*sudo update-rc.d xend stop*" than i am able to run "*sudo 
xl create*" without the FORCE option, but once i reboot the system, it 
comes back and have to run the "*sudo update-rc.d xend stop*" all over 
again. SO wondering how to disable xend from loading at boot time? Or 
just get rid of whatever remnants floating around that is interfering 
with things.




--------------090901050102060909010405
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">
    On 6/20/2012 10:07 PM, Rolu wrote:
    <blockquote
cite="mid:CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com"
      type="cite">
      <pre wrap="">On Thu, Jun 21, 2012 at 2:34 AM,  <a class="moz-txt-link-rfc2396E" href="mailto:cyberhawk001@gmail.com">&lt;cyberhawk001@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Just out of annoyance more than curiosity, but ever since I started using
Xen 4.2-unstable rev-25467, every time I try to run "sudo xl create
&lt;domu_config_file&gt;", or "sudo xl reboot", or "sudo xl destroy", it always
gives me this message:

"xend is running, which prevents xl from working correctly.
If you still want to force the execution of xl please use the -f option"

I am now forced to use the "-f" option anytime i am using the xl toolstack.
It never used to be that way going back to Xen 4.2-unstable rev-25459. I was
reading something about this a while ago on the Xen-devel list, but forget
what.

SOOO, any logical reason for the need to use the FORCE option every time you
run the XL command? AND assuming it is not something on my setup that is
causing it, will it always stay like this in future revisions?

</pre>
      </blockquote>
      <pre wrap="">Xend and xl are part of different toolstacks and should not be used
together. You should investigate why you have xend running, most
likely it shouldn't be.

Xen 4.2 and newer have the xl toolstack as default.
Xen 4.1 and older have the xend/xm toolstack as default.

See <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Choice_of_Toolstacks">http://wiki.xen.org/wiki/Choice_of_Toolstacks</a> for more info.
</pre>
    </blockquote>
    <br>
    Yes i know the difference between XL and XM toolstacks and have been
    using Xen 4.2-unstable with XL since the beginning of my Xen
    journey. As i mentioned before, i never had this issue with a
    previous Xen 4.2 person as i mentioned it, HOWEVER i have messed
    around with XCP and different version of Xen on this Debian before,
    SO very likely i forgot to remove or uninstall something between
    changes, just trying to figure out how to make it stop asking me to
    force anything.<br>
    <br>
    I was checking to make sure XEND was stopped by running "<b>sudo
      /etc/init.d/xend stop</b>" and i get an error message as below:<br>
    <br>
    <b>Traceback (most recent call last):<br>
      &nbsp; file "usr/sbin/xen", line 36, in &lt;module&gt;<br>
      &nbsp;&nbsp;&nbsp; from xen.xend.server import SrvDaemon<br>
      ImportError: No module named xen.xend.server</b> <br>
    <br>
    WHICH also happens to be the exact same message i have been getting
    every time i shut down Dom0 for quite a while now and been meaning
    to ask about that.<br>
    <br>
    Once i run "<b>sudo update-rc.d xend stop</b>" than i am able to run
    "<b>sudo xl create</b>" without the FORCE option, but once i reboot
    the system, it comes back and have to run the "<b>sudo update-rc.d
      xend stop</b>" all over again. SO wondering how to disable xend
    from loading at boot time? Or just get rid of whatever remnants
    floating around that is interfering with things.<br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------090901050102060909010405--


--===============8495108855433470291==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8495108855433470291==--


From xen-devel-bounces@lists.xen.org Thu Jun 21 02:53:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 02:53: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 1ShXVh-0000KT-Ln; Thu, 21 Jun 2012 02:52:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1ShXVg-0000KM-56
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 02:52:40 +0000
Received: from [85.158.143.35:25996] by server-2.bemta-4.messagelabs.com id
	35/EE-17938-77C82EF4; Thu, 21 Jun 2012 02:52:39 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340247157!16084800!1
X-Originating-IP: [209.85.213.41]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14688 invoked from network); 21 Jun 2012 02:52:38 -0000
Received: from mail-yw0-f41.google.com (HELO mail-yw0-f41.google.com)
	(209.85.213.41)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 02:52:38 -0000
Received: by yhr47 with SMTP id 47so134743yhr.28
	for <xen-devel@lists.xen.org>; Wed, 20 Jun 2012 19:52:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=eysdiqGcy3jfcnntXAybttbiL16c8N/ioe6f2J2UTwM=;
	b=rEQIsSoR6p6Mxde1QhC3xl+bDrWdgSANRdLU59J+oWLJvZ/T6vZXx+3kn0k5yefaQf
	uBfP0S0X7cpcmDV4AoyNMgd8jB3RQ6nl20zb1dPFlhYNcsbGos+CKId2T66HtY3im4Og
	vk/WLQInVk1XfXLIhkZ9MlpGGAE0qKfQ7KHjDzeP+DOMKMvumzTL1ma5Mm0IhWpws167
	yzYu6mrspOXZTHkgRYE8UfJHY3Fy4FjmzVmTTV3S73Xb8iPJ3UQnQdCUJ8BZl+0+wFAP
	iOx5Uo7sqBbmMkYaH0kW1BVzqhsog0pKB5pzbnhBaRgfUBzF/9amKsM+yGG3XoOOWMEO
	OZcA==
Received: by 10.236.155.41 with SMTP id i29mr30257123yhk.115.1340247156787;
	Wed, 20 Jun 2012 19:52:36 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id f8sm38974361anm.16.2012.06.20.19.52.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 20 Jun 2012 19:52:35 -0700 (PDT)
Message-ID: <4FE28C67.30000@gmail.com>
Date: Wed, 20 Jun 2012 22:52:23 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
In-Reply-To: <CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
 4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8495108855433470291=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8495108855433470291==
Content-Type: multipart/alternative;
 boundary="------------090901050102060909010405"

This is a multi-part message in MIME format.
--------------090901050102060909010405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 6/20/2012 10:07 PM, Rolu wrote:
> On Thu, Jun 21, 2012 at 2:34 AM,<cyberhawk001@gmail.com>  wrote:
>> Just out of annoyance more than curiosity, but ever since I started using
>> Xen 4.2-unstable rev-25467, every time I try to run "sudo xl create
>> <domu_config_file>", or "sudo xl reboot", or "sudo xl destroy", it always
>> gives me this message:
>>
>> "xend is running, which prevents xl from working correctly.
>> If you still want to force the execution of xl please use the -f option"
>>
>> I am now forced to use the "-f" option anytime i am using the xl toolstack.
>> It never used to be that way going back to Xen 4.2-unstable rev-25459. I was
>> reading something about this a while ago on the Xen-devel list, but forget
>> what.
>>
>> SOOO, any logical reason for the need to use the FORCE option every time you
>> run the XL command? AND assuming it is not something on my setup that is
>> causing it, will it always stay like this in future revisions?
>>
> Xend and xl are part of different toolstacks and should not be used
> together. You should investigate why you have xend running, most
> likely it shouldn't be.
>
> Xen 4.2 and newer have the xl toolstack as default.
> Xen 4.1 and older have the xend/xm toolstack as default.
>
> Seehttp://wiki.xen.org/wiki/Choice_of_Toolstacks  for more info.

Yes i know the difference between XL and XM toolstacks and have been 
using Xen 4.2-unstable with XL since the beginning of my Xen journey. As 
i mentioned before, i never had this issue with a previous Xen 4.2 
person as i mentioned it, HOWEVER i have messed around with XCP and 
different version of Xen on this Debian before, SO very likely i forgot 
to remove or uninstall something between changes, just trying to figure 
out how to make it stop asking me to force anything.

I was checking to make sure XEND was stopped by running "*sudo 
/etc/init.d/xend stop*" and i get an error message as below:

*Traceback (most recent call last):
   file "usr/sbin/xen", line 36, in <module>
     from xen.xend.server import SrvDaemon
ImportError: No module named xen.xend.server*

WHICH also happens to be the exact same message i have been getting 
every time i shut down Dom0 for quite a while now and been meaning to 
ask about that.

Once i run "*sudo update-rc.d xend stop*" than i am able to run "*sudo 
xl create*" without the FORCE option, but once i reboot the system, it 
comes back and have to run the "*sudo update-rc.d xend stop*" all over 
again. SO wondering how to disable xend from loading at boot time? Or 
just get rid of whatever remnants floating around that is interfering 
with things.




--------------090901050102060909010405
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">
    On 6/20/2012 10:07 PM, Rolu wrote:
    <blockquote
cite="mid:CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com"
      type="cite">
      <pre wrap="">On Thu, Jun 21, 2012 at 2:34 AM,  <a class="moz-txt-link-rfc2396E" href="mailto:cyberhawk001@gmail.com">&lt;cyberhawk001@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Just out of annoyance more than curiosity, but ever since I started using
Xen 4.2-unstable rev-25467, every time I try to run "sudo xl create
&lt;domu_config_file&gt;", or "sudo xl reboot", or "sudo xl destroy", it always
gives me this message:

"xend is running, which prevents xl from working correctly.
If you still want to force the execution of xl please use the -f option"

I am now forced to use the "-f" option anytime i am using the xl toolstack.
It never used to be that way going back to Xen 4.2-unstable rev-25459. I was
reading something about this a while ago on the Xen-devel list, but forget
what.

SOOO, any logical reason for the need to use the FORCE option every time you
run the XL command? AND assuming it is not something on my setup that is
causing it, will it always stay like this in future revisions?

</pre>
      </blockquote>
      <pre wrap="">Xend and xl are part of different toolstacks and should not be used
together. You should investigate why you have xend running, most
likely it shouldn't be.

Xen 4.2 and newer have the xl toolstack as default.
Xen 4.1 and older have the xend/xm toolstack as default.

See <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Choice_of_Toolstacks">http://wiki.xen.org/wiki/Choice_of_Toolstacks</a> for more info.
</pre>
    </blockquote>
    <br>
    Yes i know the difference between XL and XM toolstacks and have been
    using Xen 4.2-unstable with XL since the beginning of my Xen
    journey. As i mentioned before, i never had this issue with a
    previous Xen 4.2 person as i mentioned it, HOWEVER i have messed
    around with XCP and different version of Xen on this Debian before,
    SO very likely i forgot to remove or uninstall something between
    changes, just trying to figure out how to make it stop asking me to
    force anything.<br>
    <br>
    I was checking to make sure XEND was stopped by running "<b>sudo
      /etc/init.d/xend stop</b>" and i get an error message as below:<br>
    <br>
    <b>Traceback (most recent call last):<br>
      &nbsp; file "usr/sbin/xen", line 36, in &lt;module&gt;<br>
      &nbsp;&nbsp;&nbsp; from xen.xend.server import SrvDaemon<br>
      ImportError: No module named xen.xend.server</b> <br>
    <br>
    WHICH also happens to be the exact same message i have been getting
    every time i shut down Dom0 for quite a while now and been meaning
    to ask about that.<br>
    <br>
    Once i run "<b>sudo update-rc.d xend stop</b>" than i am able to run
    "<b>sudo xl create</b>" without the FORCE option, but once i reboot
    the system, it comes back and have to run the "<b>sudo update-rc.d
      xend stop</b>" all over again. SO wondering how to disable xend
    from loading at boot time? Or just get rid of whatever remnants
    floating around that is interfering with things.<br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------090901050102060909010405--


--===============8495108855433470291==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8495108855433470291==--


From xen-devel-bounces@lists.xen.org Thu Jun 21 05:21:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 05:21: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 1ShZoz-00050w-MY; Thu, 21 Jun 2012 05:20: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 1ShZox-00050p-UK
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 05:20:44 +0000
Received: from [85.158.143.35:36338] by server-1.bemta-4.messagelabs.com id
	E3/8C-24392-B2FA2EF4; Thu, 21 Jun 2012 05:20:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340256042!16096317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30918 invoked from network); 21 Jun 2012 05:20:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 05:20:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13136929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 05:20:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 06:20:37 +0100
Message-ID: <1340256036.4998.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "cyberhawk001@gmail.com" <cyberhawk001@gmail.com>
Date: Thu, 21 Jun 2012 06:20:36 +0100
In-Reply-To: <4FE28C67.30000@gmail.com>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
	<4FE28C67.30000@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
 4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 03:52 +0100, cyberhawk001@gmail.com wrote:

> Once i run "sudo update-rc.d xend stop" than i am able to run "sudo xl
> create" without the FORCE option, but once i reboot the system, it
> comes back and have to run the "sudo update-rc.d xend stop" all over
> again. SO wondering how to disable xend from loading at boot time? Or
> just get rid of whatever remnants floating around that is interfering
> with things.

You need to remove the initscript which is starting xend on boot. Try
"update-rc.d xend disable".

The reason for this check to prevent xl from running while xend is
active is that using xl while xend is running can lead to subtle and
confusing bugs.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 05:21:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 05:21: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 1ShZoz-00050w-MY; Thu, 21 Jun 2012 05:20: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 1ShZox-00050p-UK
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 05:20:44 +0000
Received: from [85.158.143.35:36338] by server-1.bemta-4.messagelabs.com id
	E3/8C-24392-B2FA2EF4; Thu, 21 Jun 2012 05:20:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340256042!16096317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30918 invoked from network); 21 Jun 2012 05:20:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 05:20:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13136929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 05:20:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 06:20:37 +0100
Message-ID: <1340256036.4998.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "cyberhawk001@gmail.com" <cyberhawk001@gmail.com>
Date: Thu, 21 Jun 2012 06:20:36 +0100
In-Reply-To: <4FE28C67.30000@gmail.com>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
	<4FE28C67.30000@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
 4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 03:52 +0100, cyberhawk001@gmail.com wrote:

> Once i run "sudo update-rc.d xend stop" than i am able to run "sudo xl
> create" without the FORCE option, but once i reboot the system, it
> comes back and have to run the "sudo update-rc.d xend stop" all over
> again. SO wondering how to disable xend from loading at boot time? Or
> just get rid of whatever remnants floating around that is interfering
> with things.

You need to remove the initscript which is starting xend on boot. Try
"update-rc.d xend disable".

The reason for this check to prevent xl from running while xend is
active is that using xl while xend is running can lead to subtle and
confusing bugs.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 06:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 06: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 1Shacf-0006XI-CC; Thu, 21 Jun 2012 06:12: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 1Shacd-0006XC-Ma
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 06:12:04 +0000
Received: from [85.158.138.51:7584] by server-7.bemta-3.messagelabs.com id
	63/C4-10113-23BB2EF4; Thu, 21 Jun 2012 06:12:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340259122!28657555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13110 invoked from network); 21 Jun 2012 06:12:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 06:12:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13137358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 06:12:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 07:12:00 +0100
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 1Shaca-0001pi-Qe;
	Thu, 21 Jun 2012 06:12:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Shaca-0005mW-QG;
	Thu, 21 Jun 2012 07:12:00 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13112-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 07:12:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13112: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13112 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13112/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13089

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13089
 test-amd64-amd64-xl-sedf     11 guest-localmigrate       fail blocked in 13089
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10   fail blocked in 13089

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  ffd1f786a7b5
baseline version:
 xen                  e231998f4e3a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Jun 21 06:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 06: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 1Shacf-0006XI-CC; Thu, 21 Jun 2012 06:12: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 1Shacd-0006XC-Ma
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 06:12:04 +0000
Received: from [85.158.138.51:7584] by server-7.bemta-3.messagelabs.com id
	63/C4-10113-23BB2EF4; Thu, 21 Jun 2012 06:12:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340259122!28657555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13110 invoked from network); 21 Jun 2012 06:12:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 06:12:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13137358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 06:12:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 07:12:00 +0100
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 1Shaca-0001pi-Qe;
	Thu, 21 Jun 2012 06:12:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Shaca-0005mW-QG;
	Thu, 21 Jun 2012 07:12:00 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13112-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 07:12:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13112: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13112 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13112/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13089

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13089
 test-amd64-amd64-xl-sedf     11 guest-localmigrate       fail blocked in 13089
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10   fail blocked in 13089

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  ffd1f786a7b5
baseline version:
 xen                  e231998f4e3a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Jun 21 07:16:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 07: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 1Shbcq-0007HG-KT; Thu, 21 Jun 2012 07:16:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Shbcn-0007HB-MA
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 07:16:18 +0000
Received: from [85.158.143.35:21346] by server-2.bemta-4.messagelabs.com id
	46/F9-17938-14AC2EF4; Thu, 21 Jun 2012 07:16:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340262975!16110568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27813 invoked from network); 21 Jun 2012 07:16:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 07:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13138114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 07:15:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 08:15:51 +0100
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 1ShbcM-0002DY-St;
	Thu, 21 Jun 2012 07:15:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShbcM-0002SK-SY;
	Thu, 21 Jun 2012 08:15:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13113-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 08:15:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13113: 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 13113 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13113/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13090

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13090
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13090

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 07:16:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 07: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 1Shbcq-0007HG-KT; Thu, 21 Jun 2012 07:16:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Shbcn-0007HB-MA
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 07:16:18 +0000
Received: from [85.158.143.35:21346] by server-2.bemta-4.messagelabs.com id
	46/F9-17938-14AC2EF4; Thu, 21 Jun 2012 07:16:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340262975!16110568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27813 invoked from network); 21 Jun 2012 07:16:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 07:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13138114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 07:15:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 08:15:51 +0100
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 1ShbcM-0002DY-St;
	Thu, 21 Jun 2012 07:15:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShbcM-0002SK-SY;
	Thu, 21 Jun 2012 08:15:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13113-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 08:15:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13113: 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 13113 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13113/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13090

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13090
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13090

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shccj-0008CK-BZ; Thu, 21 Jun 2012 08:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shcch-0008CF-Bv
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:20:15 +0000
Received: from [85.158.143.35:10686] by server-3.bemta-4.messagelabs.com id
	92/92-05808-E39D2EF4; Thu, 21 Jun 2012 08:20:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340266810!5633649!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2770 invoked from network); 21 Jun 2012 08:20:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13139440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08: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.213.0;
	Thu, 21 Jun 2012 09:20:10 +0100
Message-ID: <1340266524.21872.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120606181852.GB38649@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
	<20120606181852.GB38649@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
Date: Thu, 21 Jun 2012 09:15:24 +0100
MIME-Version: 1.0
X-Mailer: Evolution 3.2.2-1 
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
 paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 19:18 +0100, Tim Deegan wrote:
> At 19:04 +0100 on 06 Jun (1339009473), Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/mm.c |    8 ++++++++
> > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > index 160a4e9..ab52171 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> > >      lpae_t pte, *p;
> > >      int i;
> > >  
> > > +    if ( boot_phys_offset != 0 )
> > > +    {
> > > +        /* Remove the old identity mapping of the boot paddr */
> > > +        pte.bits = 0;
> > > +        dest_va = (unsigned long)_start + boot_phys_offset;
> > > +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> > > +    }
> > 
> > It looks like we are already doing this few lines below.
> 
> We used to do this here and now we do it futher down, after the copy.
> That way the secondary CPUs can come up on the pre-copy tables where
> the identity map still exists.

I think I wrote this patch before your SMP series went in, but since
there was no textual conflict I didn't notice that I should nuke it.

Hrm... I was about to do the nuking but without it I see:

        At 0x00000000, Error: Pagetable properties were remapped while
        MMU was enabled, may be stale translations

from the model. I use 
        cluster.messages.ignore_warning_level=0x1
in my cfg which I think is a bit more verbose than the default.

I need to re-figure out what lead me to this change...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shccj-0008CK-BZ; Thu, 21 Jun 2012 08:20:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shcch-0008CF-Bv
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:20:15 +0000
Received: from [85.158.143.35:10686] by server-3.bemta-4.messagelabs.com id
	92/92-05808-E39D2EF4; Thu, 21 Jun 2012 08:20:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340266810!5633649!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2770 invoked from network); 21 Jun 2012 08:20:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13139440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08: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.213.0;
	Thu, 21 Jun 2012 09:20:10 +0100
Message-ID: <1340266524.21872.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120606181852.GB38649@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
	<20120606181852.GB38649@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
Date: Thu, 21 Jun 2012 09:15:24 +0100
MIME-Version: 1.0
X-Mailer: Evolution 3.2.2-1 
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
 paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 19:18 +0100, Tim Deegan wrote:
> At 19:04 +0100 on 06 Jun (1339009473), Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/mm.c |    8 ++++++++
> > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > index 160a4e9..ab52171 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> > >      lpae_t pte, *p;
> > >      int i;
> > >  
> > > +    if ( boot_phys_offset != 0 )
> > > +    {
> > > +        /* Remove the old identity mapping of the boot paddr */
> > > +        pte.bits = 0;
> > > +        dest_va = (unsigned long)_start + boot_phys_offset;
> > > +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> > > +    }
> > 
> > It looks like we are already doing this few lines below.
> 
> We used to do this here and now we do it futher down, after the copy.
> That way the secondary CPUs can come up on the pre-copy tables where
> the identity map still exists.

I think I wrote this patch before your SMP series went in, but since
there was no textual conflict I didn't notice that I should nuke it.

Hrm... I was about to do the nuking but without it I see:

        At 0x00000000, Error: Pagetable properties were remapped while
        MMU was enabled, may be stale translations

from the model. I use 
        cluster.messages.ignore_warning_level=0x1
in my cfg which I think is a bit more verbose than the default.

I need to re-figure out what lead me to this change...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:34:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShcpW-0008Rm-UU; Thu, 21 Jun 2012 08:33: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 1ShcpV-0008Rh-Ge
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:33:29 +0000
Received: from [85.158.138.51:5018] by server-10.bemta-3.messagelabs.com id
	F1/33-01753-85CD2EF4; Thu, 21 Jun 2012 08:33:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340267607!20691611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7110 invoked from network); 21 Jun 2012 08:33:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:33:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13139754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:33:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:33:27 +0100
Message-ID: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 21 Jun 2012 09:33:25 +0100
In-Reply-To: <4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r 32034d1914a6 -r 4ba90ad04596 Config.mk
> --- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -43,6 +43,7 @@ endif
>  
>  include $(XEN_ROOT)/config/$(XEN_OS).mk
>  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
> +include $(XEN_ROOT)/config/Tools.mk

Unfortunately this won't work, our policy is that you only need to
invoke configure in order to build the tools -- so the top-level
Config.mk cannot include configure generated files.

>  
>  SHAREDIR    ?= $(PREFIX)/share
>  DOCDIR      ?= $(SHAREDIR)/doc/xen
> @@ -67,7 +68,7 @@ endef
>  
>  ifneq ($(EXTRA_PREFIX),)
>  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))

since we are sort of reverting 16950:0faf620bc749 here this could in
theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
include Tools.mk though. :-/

Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
hypervisor and other non-tools builds? If not then we could consider
pushing it down a level.

In the tools case I think we already have a way to inject arbitrary -L
and -I options -- so maybe this can just go away?

CCing Ian (who wrote 16950) and Olaf, whose been doing stuff in this
area.

> diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
>  PREFIX ?= /usr
>  BINDIR = $(PREFIX)/bin
>  INCLUDEDIR = $(PREFIX)/include
> -LIBLEAFDIR = lib
> -LIBLEAFDIR_x86_32 = lib
> -LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> +LIBEXEC = $(PREFIX)/lib/xen/bin

Wouldn't this be $(LIBDIR)/xen/bin ?

I suppose configure defines a libexec but it isn't the one we want?

> @@ -131,27 +130,12 @@ static int load_plugins(void)
>  	int err;
>  	int ret = -1;
>  
> -#if defined(FSIMAGE_FSDIR)
> +#if !defined(FSIMAGE_FSDIR)
> +#error FSIMAGE_FSDIR not defined

FWIW I'd be happy with the regular message you get from using an
undefined symbol, if you want to ditch this #error.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:34:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:34:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShcpW-0008Rm-UU; Thu, 21 Jun 2012 08:33: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 1ShcpV-0008Rh-Ge
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:33:29 +0000
Received: from [85.158.138.51:5018] by server-10.bemta-3.messagelabs.com id
	F1/33-01753-85CD2EF4; Thu, 21 Jun 2012 08:33:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340267607!20691611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7110 invoked from network); 21 Jun 2012 08:33:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:33:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13139754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:33:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:33:27 +0100
Message-ID: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 21 Jun 2012 09:33:25 +0100
In-Reply-To: <4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r 32034d1914a6 -r 4ba90ad04596 Config.mk
> --- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -43,6 +43,7 @@ endif
>  
>  include $(XEN_ROOT)/config/$(XEN_OS).mk
>  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
> +include $(XEN_ROOT)/config/Tools.mk

Unfortunately this won't work, our policy is that you only need to
invoke configure in order to build the tools -- so the top-level
Config.mk cannot include configure generated files.

>  
>  SHAREDIR    ?= $(PREFIX)/share
>  DOCDIR      ?= $(SHAREDIR)/doc/xen
> @@ -67,7 +68,7 @@ endef
>  
>  ifneq ($(EXTRA_PREFIX),)
>  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))

since we are sort of reverting 16950:0faf620bc749 here this could in
theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
include Tools.mk though. :-/

Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
hypervisor and other non-tools builds? If not then we could consider
pushing it down a level.

In the tools case I think we already have a way to inject arbitrary -L
and -I options -- so maybe this can just go away?

CCing Ian (who wrote 16950) and Olaf, whose been doing stuff in this
area.

> diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
>  PREFIX ?= /usr
>  BINDIR = $(PREFIX)/bin
>  INCLUDEDIR = $(PREFIX)/include
> -LIBLEAFDIR = lib
> -LIBLEAFDIR_x86_32 = lib
> -LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> +LIBEXEC = $(PREFIX)/lib/xen/bin

Wouldn't this be $(LIBDIR)/xen/bin ?

I suppose configure defines a libexec but it isn't the one we want?

> @@ -131,27 +130,12 @@ static int load_plugins(void)
>  	int err;
>  	int ret = -1;
>  
> -#if defined(FSIMAGE_FSDIR)
> +#if !defined(FSIMAGE_FSDIR)
> +#error FSIMAGE_FSDIR not defined

FWIW I'd be happy with the regular message you get from using an
undefined symbol, if you want to ditch this #error.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:40: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 1Shcvt-0000AZ-P6; Thu, 21 Jun 2012 08:40:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shcvr-0000AT-HZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:40:03 +0000
Received: from [85.158.138.51:56255] by server-3.bemta-3.messagelabs.com id
	8A/87-26490-2EDD2EF4; Thu, 21 Jun 2012 08:40:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340268001!22438106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2490 invoked from network); 21 Jun 2012 08:40:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13139941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:40:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:40:01 +0100
Message-ID: <1338449525.7864.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Simon Rowe <Simon.Rowe@eu.citrix.com>
In-Reply-To: <201205301310.09243.simon.rowe@eu.citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Thu, 31 May 2012 08:32:05 +0100
MIME-Version: 1.0
X-Mailer: Evolution 3.2.2-1 
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
> 
> > If this little trick applies to both NetBSD and uclibc too then I guess
> > it would be OK, otherwise I think autoconf is necessary.
> 
> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
> makefile unilaterally sets USE_PTHREAD for example.

It has autoconf stuff available to it, I think, it just hasn't had cause
to use it yet...

(USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
library/cmdline tools and is for building against libc's which don't
have pthreads)

> Shall I just drop this test for now and if/when xenstore is updated to use
> autoconf it can be addressed then?

I'd like to here from Roger about what this means for NetBSD and uclibc,
if it works on those then I think it is fine to do 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 Jun 21 08:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:40: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 1Shcvt-0000AZ-P6; Thu, 21 Jun 2012 08:40:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shcvr-0000AT-HZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:40:03 +0000
Received: from [85.158.138.51:56255] by server-3.bemta-3.messagelabs.com id
	8A/87-26490-2EDD2EF4; Thu, 21 Jun 2012 08:40:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340268001!22438106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2490 invoked from network); 21 Jun 2012 08:40:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13139941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:40:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:40:01 +0100
Message-ID: <1338449525.7864.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Simon Rowe <Simon.Rowe@eu.citrix.com>
In-Reply-To: <201205301310.09243.simon.rowe@eu.citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Thu, 31 May 2012 08:32:05 +0100
MIME-Version: 1.0
X-Mailer: Evolution 3.2.2-1 
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
> 
> > If this little trick applies to both NetBSD and uclibc too then I guess
> > it would be OK, otherwise I think autoconf is necessary.
> 
> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
> makefile unilaterally sets USE_PTHREAD for example.

It has autoconf stuff available to it, I think, it just hasn't had cause
to use it yet...

(USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
library/cmdline tools and is for building against libc's which don't
have pthreads)

> Shall I just drop this test for now and if/when xenstore is updated to use
> autoconf it can be addressed then?

I'd like to here from Roger about what this means for NetBSD and uclibc,
if it works on those then I think it is fine to do 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 Jun 21 08:47:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1Shd2o-0000LG-MO; Thu, 21 Jun 2012 08:47: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 1Shd2n-0000L9-MX
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:47:13 +0000
Received: from [85.158.138.51:49020] by server-3.bemta-3.messagelabs.com id
	FF/F3-26490-09FD2EF4; Thu, 21 Jun 2012 08:47:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340268432!20694808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9390 invoked from network); 21 Jun 2012 08:47:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13140113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:47:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:47:11 +0100
Message-ID: <1340268430.21872.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 09:47:10 +0100
In-Reply-To: <1339761246-27641-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/21] libxc: Do not segfault if (e.g.)
 switch_qemu_logdirty 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, 2012-06-15 at 12:53 +0100, Ian Jackson wrote:
> In xc_domain_save the local variable `ob' is initialised to NULL.
> There are then various startup actions.  Some of these `goto out' on
> failure; for example the call to callbacks->switch_qemu_logdirty on
> l.978.  However, out is used both by success and error paths.  So it
> attempts (l.2043) to flush the current output buffer.  If ob has not
> yet been assigned a non-NULL value, this segfaults.  So make the call
> to outbuf_flush conditional on ob.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Doing anything like splitting the error case into a separate path etc
looks too complex to me, so this seems like the best change.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I couldn't help noticing that there are a bunch of "goto out" statements
_after_ the out label. They all appear to be protected by an if (!rc)
and be preceded by an rc = 1, but talk about making it hard for the
reader!

> ---
>  tools/libxc/xc_domain_save.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index fcc7718..c359649 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -2040,7 +2040,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>      }
>  
>      /* Flush last write and discard cache for file. */
> -    if ( outbuf_flush(xch, ob, io_fd) < 0 ) {
> +    if ( ob && outbuf_flush(xch, ob, io_fd) < 0 ) {
>          PERROR("Error when flushing output buffer");
>          rc = 1;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:47:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1Shd2o-0000LG-MO; Thu, 21 Jun 2012 08:47: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 1Shd2n-0000L9-MX
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:47:13 +0000
Received: from [85.158.138.51:49020] by server-3.bemta-3.messagelabs.com id
	FF/F3-26490-09FD2EF4; Thu, 21 Jun 2012 08:47:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340268432!20694808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9390 invoked from network); 21 Jun 2012 08:47:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13140113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:47:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:47:11 +0100
Message-ID: <1340268430.21872.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 09:47:10 +0100
In-Reply-To: <1339761246-27641-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/21] libxc: Do not segfault if (e.g.)
 switch_qemu_logdirty 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, 2012-06-15 at 12:53 +0100, Ian Jackson wrote:
> In xc_domain_save the local variable `ob' is initialised to NULL.
> There are then various startup actions.  Some of these `goto out' on
> failure; for example the call to callbacks->switch_qemu_logdirty on
> l.978.  However, out is used both by success and error paths.  So it
> attempts (l.2043) to flush the current output buffer.  If ob has not
> yet been assigned a non-NULL value, this segfaults.  So make the call
> to outbuf_flush conditional on ob.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Doing anything like splitting the error case into a separate path etc
looks too complex to me, so this seems like the best change.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I couldn't help noticing that there are a bunch of "goto out" statements
_after_ the out label. They all appear to be protected by an if (!rc)
and be preceded by an rc = 1, but talk about making it hard for the
reader!

> ---
>  tools/libxc/xc_domain_save.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index fcc7718..c359649 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -2040,7 +2040,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>      }
>  
>      /* Flush last write and discard cache for file. */
> -    if ( outbuf_flush(xch, ob, io_fd) < 0 ) {
> +    if ( ob && outbuf_flush(xch, ob, io_fd) < 0 ) {
>          PERROR("Error when flushing output buffer");
>          rc = 1;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shd7H-0000SJ-Dp; Thu, 21 Jun 2012 08:51:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Shd7F-0000SB-Ow
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:51:49 +0000
Received: from [85.158.143.35:64925] by server-1.bemta-4.messagelabs.com id
	16/DF-24392-4A0E2EF4; Thu, 21 Jun 2012 08:51:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340268705!16257707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2355 invoked from network); 21 Jun 2012 08:51:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13140240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:51:42 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 09:51:42 +0100
Message-ID: <4FE2E09E.4000202@citrix.com>
Date: Thu, 21 Jun 2012 09:51:42 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Matt Wilson <msw@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
>>   SHAREDIR    ?= $(PREFIX)/share
>>   DOCDIR      ?= $(SHAREDIR)/doc/xen
>> @@ -67,7 +68,7 @@ endef
>>
>>   ifneq ($(EXTRA_PREFIX),)
>>   EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
>> -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
>> +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
>
> since we are sort of reverting 16950:0faf620bc749 here this could in
> theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> include Tools.mk though. :-/
>
> Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> hypervisor and other non-tools builds? If not then we could consider
> pushing it down a level.
>
> In the tools case I think we already have a way to inject arbitrary -L
> and -I options -- so maybe this can just go away?
>
> CCing Ian (who wrote 16950) and Olaf, whose been doing stuff in this
> area.

EXTRA_LIB was keep to maintain backward compatibility, but the use of 
the APPEND_ and PREPEND_ flags should provide the same functionality 
with more flexibility (see 24141:078392e5078d).

I don't think the hypervisor needs any special libs to build, at least I 
never had to pass any extra libs to build it on the several not so 
common systems I've build Xen on (NetBSD and uClibc).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shd7H-0000SJ-Dp; Thu, 21 Jun 2012 08:51:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Shd7F-0000SB-Ow
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:51:49 +0000
Received: from [85.158.143.35:64925] by server-1.bemta-4.messagelabs.com id
	16/DF-24392-4A0E2EF4; Thu, 21 Jun 2012 08:51:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340268705!16257707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2355 invoked from network); 21 Jun 2012 08:51:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13140240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:51:42 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 09:51:42 +0100
Message-ID: <4FE2E09E.4000202@citrix.com>
Date: Thu, 21 Jun 2012 09:51:42 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
Cc: Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Matt Wilson <msw@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
>>   SHAREDIR    ?= $(PREFIX)/share
>>   DOCDIR      ?= $(SHAREDIR)/doc/xen
>> @@ -67,7 +68,7 @@ endef
>>
>>   ifneq ($(EXTRA_PREFIX),)
>>   EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
>> -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
>> +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
>
> since we are sort of reverting 16950:0faf620bc749 here this could in
> theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> include Tools.mk though. :-/
>
> Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> hypervisor and other non-tools builds? If not then we could consider
> pushing it down a level.
>
> In the tools case I think we already have a way to inject arbitrary -L
> and -I options -- so maybe this can just go away?
>
> CCing Ian (who wrote 16950) and Olaf, whose been doing stuff in this
> area.

EXTRA_LIB was keep to maintain backward compatibility, but the use of 
the APPEND_ and PREPEND_ flags should provide the same functionality 
with more flexibility (see 24141:078392e5078d).

I don't think the hypervisor needs any special libs to build, at least I 
never had to pass any extra libs to build it on the several not so 
common systems I've build Xen on (NetBSD and uClibc).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:53:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1Shd8c-0000XT-Sp; Thu, 21 Jun 2012 08:53:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shd8b-0000XM-4J
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:53:13 +0000
Received: from [85.158.143.35:17123] by server-2.bemta-4.messagelabs.com id
	D4/7F-17938-8F0E2EF4; Thu, 21 Jun 2012 08:53:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340268786!17336514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28688 invoked from network); 21 Jun 2012 08:53:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13140293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:53:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:53:05 +0100
Message-ID: <1340268784.21872.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 09:53:04 +0100
In-Reply-To: <6c32fcbbd4896a55b73e.1339779869@Solace>
References: <patchbomb.1339779868@Solace>
	<6c32fcbbd4896a55b73e.1339779869@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
 GCREALLOC_ARRAY 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 Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> Causing a build failure when trying to use it:
> 
> xxx: error: expected ';' before ')' token
> xxx: error: expected statement before ')' token
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
>  #define GCREALLOC_ARRAY(var, nmemb)                                     \
>      (assert(nmemb > 0),                                                 \
>       assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
> -     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
> +     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
>  
> 
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:53:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1Shd8c-0000XT-Sp; Thu, 21 Jun 2012 08:53:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shd8b-0000XM-4J
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:53:13 +0000
Received: from [85.158.143.35:17123] by server-2.bemta-4.messagelabs.com id
	D4/7F-17938-8F0E2EF4; Thu, 21 Jun 2012 08:53:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340268786!17336514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE3MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28688 invoked from network); 21 Jun 2012 08:53:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 08:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,449,1336348800"; d="scan'208";a="13140293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 08:53:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:53:05 +0100
Message-ID: <1340268784.21872.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 09:53:04 +0100
In-Reply-To: <6c32fcbbd4896a55b73e.1339779869@Solace>
References: <patchbomb.1339779868@Solace>
	<6c32fcbbd4896a55b73e.1339779869@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
 GCREALLOC_ARRAY 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 Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> Causing a build failure when trying to use it:
> 
> xxx: error: expected ';' before ')' token
> xxx: error: expected statement before ')' token
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
>  #define GCREALLOC_ARRAY(var, nmemb)                                     \
>      (assert(nmemb > 0),                                                 \
>       assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
> -     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
> +     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
>  
> 
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1Shd94-0000aG-9H; Thu, 21 Jun 2012 08:53: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 1Shd92-0000Zv-UZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:53:41 +0000
Received: from [85.158.138.51:44184] by server-3.bemta-3.messagelabs.com id
	A1/8F-26490-311E2EF4; Thu, 21 Jun 2012 08:53:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340268819!22441551!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDY1MDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDY1MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7978 invoked from network); 21 Jun 2012 08:53:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Jun 2012 08:53:39 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0ME1Y=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-020.pools.arcor-ip.net [88.65.85.20])
	by smtp.strato.de (jored mo3) (RZmta 29.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g02272o5L7Ji5h ;
	Thu, 21 Jun 2012 10:53:39 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5EE6918637; Thu, 21 Jun 2012 10:53:38 +0200 (CEST)
Date: Thu, 21 Jun 2012 10:53:38 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621085338.GA18516@aepfle.de>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, Ian Campbell wrote:

> On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > Currently shared libraries are automatically installed into /usr/lib
> > or /usr/lib64, depending on the supplied --prefix value and
> > $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> > do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> > 
> > With this change, packagers can supply the desired location for shared
> > libraries on the ./configure command line. Packagers need to note that
> > the default behaviour on 64-bit Linux systems will be to install shared
> > libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> > to ./configure.

Perhaps that should be stated in the README, which states to call just
configure without options.

> >  SHAREDIR    ?= $(PREFIX)/share
> >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > @@ -67,7 +68,7 @@ endef
> >  
> >  ifneq ($(EXTRA_PREFIX),)
> >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> 
> since we are sort of reverting 16950:0faf620bc749 here this could in
> theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> include Tools.mk though. :-/
> 
> Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> hypervisor and other non-tools builds? If not then we could consider
> pushing it down a level.
> 
> In the tools case I think we already have a way to inject arbitrary -L
> and -I options -- so maybe this can just go away?

I'm not sure what the purpose of EXTRA_INCLUDES and EXTRA_LIB is, now
that EXTRA_CFLAGS can be specified, since changeset 25464:75a2bb5db228.

Perhaps its use case should also be added to the README?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1Shd94-0000aG-9H; Thu, 21 Jun 2012 08:53: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 1Shd92-0000Zv-UZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 08:53:41 +0000
Received: from [85.158.138.51:44184] by server-3.bemta-3.messagelabs.com id
	A1/8F-26490-311E2EF4; Thu, 21 Jun 2012 08:53:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340268819!22441551!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDY1MDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzNDY1MDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7978 invoked from network); 21 Jun 2012 08:53:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Jun 2012 08:53:39 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0ME1Y=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-020.pools.arcor-ip.net [88.65.85.20])
	by smtp.strato.de (jored mo3) (RZmta 29.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g02272o5L7Ji5h ;
	Thu, 21 Jun 2012 10:53:39 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5EE6918637; Thu, 21 Jun 2012 10:53:38 +0200 (CEST)
Date: Thu, 21 Jun 2012 10:53:38 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621085338.GA18516@aepfle.de>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, Ian Campbell wrote:

> On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > Currently shared libraries are automatically installed into /usr/lib
> > or /usr/lib64, depending on the supplied --prefix value and
> > $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> > do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> > 
> > With this change, packagers can supply the desired location for shared
> > libraries on the ./configure command line. Packagers need to note that
> > the default behaviour on 64-bit Linux systems will be to install shared
> > libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> > to ./configure.

Perhaps that should be stated in the README, which states to call just
configure without options.

> >  SHAREDIR    ?= $(PREFIX)/share
> >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > @@ -67,7 +68,7 @@ endef
> >  
> >  ifneq ($(EXTRA_PREFIX),)
> >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> 
> since we are sort of reverting 16950:0faf620bc749 here this could in
> theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> include Tools.mk though. :-/
> 
> Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> hypervisor and other non-tools builds? If not then we could consider
> pushing it down a level.
> 
> In the tools case I think we already have a way to inject arbitrary -L
> and -I options -- so maybe this can just go away?

I'm not sure what the purpose of EXTRA_INCLUDES and EXTRA_LIB is, now
that EXTRA_CFLAGS can be specified, since changeset 25464:75a2bb5db228.

Perhaps its use case should also be added to the README?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 08:58:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1ShdDm-0000v3-10; Thu, 21 Jun 2012 08:58:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1ShdDk-0000uu-Mn
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 08:58:33 +0000
Received: from [85.158.139.83:9058] by server-4.bemta-5.messagelabs.com id
	89/EC-27831-732E2EF4; Thu, 21 Jun 2012 08:58:31 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340269108!21422040!1
X-Originating-IP: [220.181.15.62]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYyID0+IDE2MTkx\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYyID0+IDE2MTkx\n,HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3755 invoked from network); 21 Jun 2012 08:58:30 -0000
Received: from m15-62.126.com (HELO m15-62.126.com) (220.181.15.62)
	by server-16.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 08:58:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=ug/XW3I9i6wa70lTbHMuCQ4A7iAl6S7liPa7
	9Dx+/7o=; b=d380MXZsT+cRQVCubNb37mOVDb/BBTgZthXoiGFUCEuDWxuxneau
	YqqkGCNXXiszdHNeT6hlXlc+iW9ohUCECAIqt2BIDjiV7o846Bd4cm4tMHTtcmyy
	paY2XVe0zGh6v7hN5gaD2chPQ/3tC3cAObYN8Y8kMT48jTh0IK/A6RE=
Received: from hxkhust$126.com ( [115.156.232.40] ) by ajax-webmail-wmsvr62
	(Coremail) ; Thu, 21 Jun 2012 16:58:26 +0800 (CST)
X-Originating-IP: [115.156.232.40]
Date: Thu, 21 Jun 2012 16:58:26 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: xen-devel@lists.xensource.com
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: zqUjF2Zvb3Rlcl9odG09NjExOjgx
MIME-Version: 1.0
Message-ID: <4922725b.17027.1380e4394d1.Coremail.hxkhust@126.com>
X-CM-TRANSID: PsqowEC58EMz4uJPhvo2AA--.2465W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiaQ3UBU1ryfG-BgAAsS
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] pvm's VBD on linux kernel 3.X
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4546115732954116765=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4546115732954116765==
Content-Type: multipart/alternative; 
	boundary="----=_Part_247869_233642887.1340269106385"

------=_Part_247869_233642887.1340269106385
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,guys!
 
Nowadays with linux kernel 3.x's coming the modules of blktap/blktap2 are excluded in the mainline kernel and have no xenpatches for me to patch.However I have been doing some research on paravirtualized guest os and usually take a image file as the virtual block device.Thus if I would like to change the process of reading image files(PVM's VBDs, whose format is raw) in xen,Which source code file should I scan first?
 
hxkhust
 
------=_Part_247869_233642887.1340269106385
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,guys!</DIV>
<DIV>&nbsp;</DIV>
<DIV>Nowadays with linux kernel 3.x's coming the modules of blktap/blktap2 are excluded in the mainline kernel and have no xenpatches for me to patch.However I have been doing some research on paravirtualized guest os and usually take a image file as the virtual block device.Thus if I would like to change the process of reading image files(PVM's VBDs, whose format is raw)&nbsp;in xen,Which source code file should I scan first?</DIV>
<DIV>&nbsp;</DIV>
<DIV>hxkhust</DIV>
<DIV>&nbsp;</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_247869_233642887.1340269106385--



--===============4546115732954116765==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4546115732954116765==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 08:58:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 08: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 1ShdDm-0000v3-10; Thu, 21 Jun 2012 08:58:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1ShdDk-0000uu-Mn
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 08:58:33 +0000
Received: from [85.158.139.83:9058] by server-4.bemta-5.messagelabs.com id
	89/EC-27831-732E2EF4; Thu, 21 Jun 2012 08:58:31 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340269108!21422040!1
X-Originating-IP: [220.181.15.62]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYyID0+IDE2MTkx\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjYyID0+IDE2MTkx\n,HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3755 invoked from network); 21 Jun 2012 08:58:30 -0000
Received: from m15-62.126.com (HELO m15-62.126.com) (220.181.15.62)
	by server-16.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 08:58:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=ug/XW3I9i6wa70lTbHMuCQ4A7iAl6S7liPa7
	9Dx+/7o=; b=d380MXZsT+cRQVCubNb37mOVDb/BBTgZthXoiGFUCEuDWxuxneau
	YqqkGCNXXiszdHNeT6hlXlc+iW9ohUCECAIqt2BIDjiV7o846Bd4cm4tMHTtcmyy
	paY2XVe0zGh6v7hN5gaD2chPQ/3tC3cAObYN8Y8kMT48jTh0IK/A6RE=
Received: from hxkhust$126.com ( [115.156.232.40] ) by ajax-webmail-wmsvr62
	(Coremail) ; Thu, 21 Jun 2012 16:58:26 +0800 (CST)
X-Originating-IP: [115.156.232.40]
Date: Thu, 21 Jun 2012 16:58:26 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: xen-devel@lists.xensource.com
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: zqUjF2Zvb3Rlcl9odG09NjExOjgx
MIME-Version: 1.0
Message-ID: <4922725b.17027.1380e4394d1.Coremail.hxkhust@126.com>
X-CM-TRANSID: PsqowEC58EMz4uJPhvo2AA--.2465W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiaQ3UBU1ryfG-BgAAsS
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] pvm's VBD on linux kernel 3.X
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4546115732954116765=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4546115732954116765==
Content-Type: multipart/alternative; 
	boundary="----=_Part_247869_233642887.1340269106385"

------=_Part_247869_233642887.1340269106385
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,guys!
 
Nowadays with linux kernel 3.x's coming the modules of blktap/blktap2 are excluded in the mainline kernel and have no xenpatches for me to patch.However I have been doing some research on paravirtualized guest os and usually take a image file as the virtual block device.Thus if I would like to change the process of reading image files(PVM's VBDs, whose format is raw) in xen,Which source code file should I scan first?
 
hxkhust
 
------=_Part_247869_233642887.1340269106385
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,guys!</DIV>
<DIV>&nbsp;</DIV>
<DIV>Nowadays with linux kernel 3.x's coming the modules of blktap/blktap2 are excluded in the mainline kernel and have no xenpatches for me to patch.However I have been doing some research on paravirtualized guest os and usually take a image file as the virtual block device.Thus if I would like to change the process of reading image files(PVM's VBDs, whose format is raw)&nbsp;in xen,Which source code file should I scan first?</DIV>
<DIV>&nbsp;</DIV>
<DIV>hxkhust</DIV>
<DIV>&nbsp;</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_247869_233642887.1340269106385--



--===============4546115732954116765==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4546115732954116765==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 09:02:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdHX-00015h-R7; Thu, 21 Jun 2012 09:02:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdHV-00015Y-NL
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:02:26 +0000
Received: from [193.109.254.147:51133] by server-9.bemta-14.messagelabs.com id
	02/13-07693-123E2EF4; Thu, 21 Jun 2012 09:02:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340269343!10850319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21448 invoked from network); 21 Jun 2012 09:02:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:02:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:02:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:02:23 +0100
Message-ID: <1340269342.21872.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:02:22 +0100
In-Reply-To: <16222d05875389899968.1339779871@Solace>
References: <patchbomb.1339779868@Solace>
	<16222d05875389899968.1339779871@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> Make some NUMA node information available to the toolstack. Achieve
> this by means of xc_numainfo(), which exposes memory size and amount
> of free memory of each node, as well as the relative distances of
> each node to all the others.
> 
> For properly exposing distances we need the IDL to support arrays.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * malloc converted to libxl__zalloc(NOGC, ...).
>  * The patch also accommodates some bits of what was in "libxc,
>    libxl: introduce xc_nodemap_t and libxl_nodemap" which was
>    removed as well, as full support for node maps at libxc
>    level is not needed (yet!).
> 
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -35,6 +35,20 @@ int xc_get_max_cpus(xc_interface *xch)
>      return max_cpus;
>  }
>  
> +int xc_get_max_nodes(xc_interface *xch)
> +{
> +    static int max_nodes = 0;
> +    xc_physinfo_t physinfo;
> +
> +    if ( max_nodes )
> +        return max_nodes;
> +
> +    if ( !xc_physinfo(xch, &physinfo) )
> +        max_nodes = physinfo.max_node_id + 1;
> +
> +    return max_nodes;
> +}
> +
>  int xc_get_cpumap_size(xc_interface *xch)
>  {
>      return (xc_get_max_cpus(xch) + 7) / 8;
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -329,6 +329,12 @@ int xc_get_cpumap_size(xc_interface *xch
>  /* allocate a cpumap */
>  xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
>  
> + /*
> + * NODEMAP handling
> + */
> +/* return maximum number of NUMA nodes the hypervisor supports */
> +int xc_get_max_nodes(xc_interface *xch);
> +
>  /*
>   * DOMAIN DEBUGGING FUNCTIONS
>   */
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3223,6 +3223,71 @@ fail:
>      return ret;
>  }
>  
> +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
> +{
[...]

The hypercall buffer stuff all looks good.

> +    if (ret)
> +        *nr = max_nodes;

You could put this before the fail: label. Not that it matters.

> +    return ret;
> +}
> +
>  const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
>  {
>      union {
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -532,6 +532,9 @@ int libxl_domain_preserve(libxl_ctx *ctx
>  /* get max. number of cpus supported by hypervisor */
>  int libxl_get_max_cpus(libxl_ctx *ctx);
>  
> +/* get max. number of NUMA nodes supported by hypervisor */
> +int libxl_get_max_nodes(libxl_ctx *ctx);
> +
>  int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
>                          const char *old_name, const char *new_name);
>  
> @@ -769,6 +772,13 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
>  #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
>  libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
>  void libxl_cputopology_list_free(libxl_cputopology *, int nr);
> +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
> +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
> +  /* On success, a list of nr libxl_numainfo elements is returned.
> +   * That is from malloc, thus it is up to the caller to invoke
> +   * libxl_cpupoolinfo_list_free() on it.

Don't you mean libxl_numinfo_list_free() ?

Also normally we put the comment before the prototype.

> +   */
> +void libxl_numainfo_list_free(libxl_numainfo *, int nr);
>  libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
>                                         int *nb_vcpu, int *nrcpus);
>  void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -423,6 +423,12 @@ libxl_physinfo = Struct("physinfo", [
>      ("cap_hvm_directio", bool),
>      ], dir=DIR_OUT)
>  
> +libxl_numainfo = Struct("numainfo", [
> +    ("size", uint64),
> +    ("free", uint64),
> +    ("dists", Array(uint32, "num_dists")),

This is an array of distances from this node to each other node? That
could be worth a comment.


> +    ], dir=DIR_OUT)
> +
>  libxl_cputopology = Struct("cputopology", [
>      ("core", uint32),
>      ("socket", uint32),
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
>      return xc_get_max_cpus(ctx->xch);
>  }
>  
> +int libxl_get_max_nodes(libxl_ctx *ctx)
> +{
> +    return xc_get_max_nodes(ctx->xch);
> +}

Is this needed externally to libxl or do we expect all callers to use
libxl_get_numainfo? I suppose there is no harm in exporting this either
way.

> +
>  int libxl__enum_from_string(const libxl_enum_string_table *t,
>                              const char *s, int *e)
>  {
> @@ -551,6 +556,14 @@ int libxl__enum_from_string(const libxl_
>      return ERROR_FAIL;
>  }
>  
> +void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
> +{
> +    int i;
> +    for (i = 0; i < nr; i++)
> +        libxl_numainfo_dispose(&list[i]);
> +    free(list);
> +}
> +
>  void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
>  {
>      int i;
> 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
> @@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
>  
>  /* XEN_SYSCTL_numainfo */
> +#define INVALID_NUMAINFO_ID (~0U)

It feels like there ought to be hunks in the hypervisor which either use
this symbol instead of a hardcoded ~0U or which remove the internal
definition in favour of this one?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:02:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdHX-00015h-R7; Thu, 21 Jun 2012 09:02:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdHV-00015Y-NL
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:02:26 +0000
Received: from [193.109.254.147:51133] by server-9.bemta-14.messagelabs.com id
	02/13-07693-123E2EF4; Thu, 21 Jun 2012 09:02:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340269343!10850319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21448 invoked from network); 21 Jun 2012 09:02:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:02:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:02:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:02:23 +0100
Message-ID: <1340269342.21872.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:02:22 +0100
In-Reply-To: <16222d05875389899968.1339779871@Solace>
References: <patchbomb.1339779868@Solace>
	<16222d05875389899968.1339779871@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> Make some NUMA node information available to the toolstack. Achieve
> this by means of xc_numainfo(), which exposes memory size and amount
> of free memory of each node, as well as the relative distances of
> each node to all the others.
> 
> For properly exposing distances we need the IDL to support arrays.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * malloc converted to libxl__zalloc(NOGC, ...).
>  * The patch also accommodates some bits of what was in "libxc,
>    libxl: introduce xc_nodemap_t and libxl_nodemap" which was
>    removed as well, as full support for node maps at libxc
>    level is not needed (yet!).
> 
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -35,6 +35,20 @@ int xc_get_max_cpus(xc_interface *xch)
>      return max_cpus;
>  }
>  
> +int xc_get_max_nodes(xc_interface *xch)
> +{
> +    static int max_nodes = 0;
> +    xc_physinfo_t physinfo;
> +
> +    if ( max_nodes )
> +        return max_nodes;
> +
> +    if ( !xc_physinfo(xch, &physinfo) )
> +        max_nodes = physinfo.max_node_id + 1;
> +
> +    return max_nodes;
> +}
> +
>  int xc_get_cpumap_size(xc_interface *xch)
>  {
>      return (xc_get_max_cpus(xch) + 7) / 8;
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -329,6 +329,12 @@ int xc_get_cpumap_size(xc_interface *xch
>  /* allocate a cpumap */
>  xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
>  
> + /*
> + * NODEMAP handling
> + */
> +/* return maximum number of NUMA nodes the hypervisor supports */
> +int xc_get_max_nodes(xc_interface *xch);
> +
>  /*
>   * DOMAIN DEBUGGING FUNCTIONS
>   */
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3223,6 +3223,71 @@ fail:
>      return ret;
>  }
>  
> +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
> +{
[...]

The hypercall buffer stuff all looks good.

> +    if (ret)
> +        *nr = max_nodes;

You could put this before the fail: label. Not that it matters.

> +    return ret;
> +}
> +
>  const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
>  {
>      union {
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -532,6 +532,9 @@ int libxl_domain_preserve(libxl_ctx *ctx
>  /* get max. number of cpus supported by hypervisor */
>  int libxl_get_max_cpus(libxl_ctx *ctx);
>  
> +/* get max. number of NUMA nodes supported by hypervisor */
> +int libxl_get_max_nodes(libxl_ctx *ctx);
> +
>  int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
>                          const char *old_name, const char *new_name);
>  
> @@ -769,6 +772,13 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
>  #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
>  libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
>  void libxl_cputopology_list_free(libxl_cputopology *, int nr);
> +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
> +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
> +  /* On success, a list of nr libxl_numainfo elements is returned.
> +   * That is from malloc, thus it is up to the caller to invoke
> +   * libxl_cpupoolinfo_list_free() on it.

Don't you mean libxl_numinfo_list_free() ?

Also normally we put the comment before the prototype.

> +   */
> +void libxl_numainfo_list_free(libxl_numainfo *, int nr);
>  libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
>                                         int *nb_vcpu, int *nrcpus);
>  void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -423,6 +423,12 @@ libxl_physinfo = Struct("physinfo", [
>      ("cap_hvm_directio", bool),
>      ], dir=DIR_OUT)
>  
> +libxl_numainfo = Struct("numainfo", [
> +    ("size", uint64),
> +    ("free", uint64),
> +    ("dists", Array(uint32, "num_dists")),

This is an array of distances from this node to each other node? That
could be worth a comment.


> +    ], dir=DIR_OUT)
> +
>  libxl_cputopology = Struct("cputopology", [
>      ("core", uint32),
>      ("socket", uint32),
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
>      return xc_get_max_cpus(ctx->xch);
>  }
>  
> +int libxl_get_max_nodes(libxl_ctx *ctx)
> +{
> +    return xc_get_max_nodes(ctx->xch);
> +}

Is this needed externally to libxl or do we expect all callers to use
libxl_get_numainfo? I suppose there is no harm in exporting this either
way.

> +
>  int libxl__enum_from_string(const libxl_enum_string_table *t,
>                              const char *s, int *e)
>  {
> @@ -551,6 +556,14 @@ int libxl__enum_from_string(const libxl_
>      return ERROR_FAIL;
>  }
>  
> +void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
> +{
> +    int i;
> +    for (i = 0; i < nr; i++)
> +        libxl_numainfo_dispose(&list[i]);
> +    free(list);
> +}
> +
>  void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
>  {
>      int i;
> 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
> @@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
>  
>  /* XEN_SYSCTL_numainfo */
> +#define INVALID_NUMAINFO_ID (~0U)

It feels like there ought to be hunks in the hypervisor which either use
this symbol instead of a hardcoded ~0U or which remove the internal
definition in favour of this one?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:04:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdJ6-0001Fp-GE; Thu, 21 Jun 2012 09:04: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 1ShdJ5-0001Fh-DU
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:04:03 +0000
Received: from [193.109.254.147:20364] by server-7.bemta-14.messagelabs.com id
	E4/41-29827-283E2EF4; Thu, 21 Jun 2012 09:04:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340269441!3995598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31828 invoked from network); 21 Jun 2012 09:04:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:04:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:04:01 +0100
Message-ID: <1340269440.21872.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:04:00 +0100
In-Reply-To: <0e64330fdbfdd74a6ddf.1339779872@Solace>
References: <patchbomb.1339779868@Solace>
	<0e64330fdbfdd74a6ddf.1339779872@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04 of 10 v2] xl: add more NUMA information
 to `xl info -n'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> So that the user knows how much memory there is on each node and
> how far they are from each others.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes from v1:
>  * integer division replaced by right shift.
> 
> 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
> @@ -4254,6 +4254,36 @@ static void output_physinfo(void)
>      return;
>  }
>  
> +static void output_numainfo(void)
> +{
> +    libxl_numainfo *info;
> +    int i, j, nr;
> +
> +    info = libxl_get_numainfo(ctx, &nr);
> +    if (info == NULL) {
> +        fprintf(stderr, "libxl_get_numainfo failed.\n");
> +        return;
> +    }
> +
> +    printf("numa_info              :\n");
> +    printf("node:    memsize    memfree    distances\n");
> +
> +    for (i = 0; i < nr; i++) {
> +        if (info[i].size != LIBXL_NUMAINFO_INVALID_ENTRY) {
> +            printf("%4d:    %6"PRIu64"     %6"PRIu64"      %d", i,
> +                   info[i].size >> 20, info[i].free >> 20,
> +                   info[i].dists[0]);
> +            for (j = 1; j < info[i].num_dists; j++)
> +                printf(",%d", info[i].dists[j]);
> +            printf("\n");
> +        }
> +    }
> +
> +    libxl_numainfo_list_free(info, nr);
> +
> +    return;
> +}
> +
>  static void output_topologyinfo(void)
>  {
>      libxl_cputopology *info;
> @@ -4276,8 +4306,6 @@ static void output_topologyinfo(void)
>  
>      libxl_cputopology_list_free(info, nr);
>  
> -    printf("numa_info              : none\n");
> -
>      return;
>  }
>  
> @@ -4287,8 +4315,10 @@ static void info(int numa)
>  
>      output_physinfo();
>  
> -    if (numa)
> +    if (numa) {
>          output_topologyinfo();
> +        output_numainfo();
> +    }
>  
>      output_xeninfo();
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:04:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdJ6-0001Fp-GE; Thu, 21 Jun 2012 09:04: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 1ShdJ5-0001Fh-DU
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:04:03 +0000
Received: from [193.109.254.147:20364] by server-7.bemta-14.messagelabs.com id
	E4/41-29827-283E2EF4; Thu, 21 Jun 2012 09:04:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340269441!3995598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31828 invoked from network); 21 Jun 2012 09:04:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:04:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:04:01 +0100
Message-ID: <1340269440.21872.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:04:00 +0100
In-Reply-To: <0e64330fdbfdd74a6ddf.1339779872@Solace>
References: <patchbomb.1339779868@Solace>
	<0e64330fdbfdd74a6ddf.1339779872@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04 of 10 v2] xl: add more NUMA information
 to `xl info -n'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> So that the user knows how much memory there is on each node and
> how far they are from each others.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes from v1:
>  * integer division replaced by right shift.
> 
> 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
> @@ -4254,6 +4254,36 @@ static void output_physinfo(void)
>      return;
>  }
>  
> +static void output_numainfo(void)
> +{
> +    libxl_numainfo *info;
> +    int i, j, nr;
> +
> +    info = libxl_get_numainfo(ctx, &nr);
> +    if (info == NULL) {
> +        fprintf(stderr, "libxl_get_numainfo failed.\n");
> +        return;
> +    }
> +
> +    printf("numa_info              :\n");
> +    printf("node:    memsize    memfree    distances\n");
> +
> +    for (i = 0; i < nr; i++) {
> +        if (info[i].size != LIBXL_NUMAINFO_INVALID_ENTRY) {
> +            printf("%4d:    %6"PRIu64"     %6"PRIu64"      %d", i,
> +                   info[i].size >> 20, info[i].free >> 20,
> +                   info[i].dists[0]);
> +            for (j = 1; j < info[i].num_dists; j++)
> +                printf(",%d", info[i].dists[j]);
> +            printf("\n");
> +        }
> +    }
> +
> +    libxl_numainfo_list_free(info, nr);
> +
> +    return;
> +}
> +
>  static void output_topologyinfo(void)
>  {
>      libxl_cputopology *info;
> @@ -4276,8 +4306,6 @@ static void output_topologyinfo(void)
>  
>      libxl_cputopology_list_free(info, nr);
>  
> -    printf("numa_info              : none\n");
> -
>      return;
>  }
>  
> @@ -4287,8 +4315,10 @@ static void info(int numa)
>  
>      output_physinfo();
>  
> -    if (numa)
> +    if (numa) {
>          output_topologyinfo();
> +        output_numainfo();
> +    }
>  
>      output_xeninfo();
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdOi-0001VJ-9e; Thu, 21 Jun 2012 09:09:52 +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 1ShdOh-0001VE-Cn
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:09:51 +0000
Received: from [85.158.143.35:35786] by server-3.bemta-4.messagelabs.com id
	8E/C9-05808-ED4E2EF4; Thu, 21 Jun 2012 09:09:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340269788!14191321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20604 invoked from network); 21 Jun 2012 09:09:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:09:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:09:48 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 10:09:48 +0100
Message-ID: <4FE2E4DC.5030500@citrix.com>
Date: Thu, 21 Jun 2012 10:09:48 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338449525.7864.14.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
>> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
>>
>>> If this little trick applies to both NetBSD and uclibc too then I guess
>>> it would be OK, otherwise I think autoconf is necessary.
>> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
>> makefile unilaterally sets USE_PTHREAD for example.
>
> It has autoconf stuff available to it, I think, it just hasn't had cause
> to use it yet...
>
> (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
> library/cmdline tools and is for building against libc's which don't
> have pthreads)
>
>> Shall I just drop this test for now and if/when xenstore is updated to use
>> autoconf it can be addressed then?
>
> I'd like to here from Roger about what this means for NetBSD and uclibc,
> if it works on those then I think it is fine to do this.

Sorry for the delay, I just received this today (don't know why). I've 
been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.

What I don't really like is the hardcoded (16 * 1024) value, how do you 
know this is greater than PTHREAD_STACK_MIN?

Frankly I don't understand why do we have to touch this, even if you 
requested 256MB of stack it won't we allocated until you get a page 
fault, so you are only using the physical memory you need.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdOi-0001VJ-9e; Thu, 21 Jun 2012 09:09:52 +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 1ShdOh-0001VE-Cn
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:09:51 +0000
Received: from [85.158.143.35:35786] by server-3.bemta-4.messagelabs.com id
	8E/C9-05808-ED4E2EF4; Thu, 21 Jun 2012 09:09:50 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340269788!14191321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20604 invoked from network); 21 Jun 2012 09:09:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:09:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:09:48 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 10:09:48 +0100
Message-ID: <4FE2E4DC.5030500@citrix.com>
Date: Thu, 21 Jun 2012 10:09:48 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1338449525.7864.14.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
>> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
>>
>>> If this little trick applies to both NetBSD and uclibc too then I guess
>>> it would be OK, otherwise I think autoconf is necessary.
>> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
>> makefile unilaterally sets USE_PTHREAD for example.
>
> It has autoconf stuff available to it, I think, it just hasn't had cause
> to use it yet...
>
> (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
> library/cmdline tools and is for building against libc's which don't
> have pthreads)
>
>> Shall I just drop this test for now and if/when xenstore is updated to use
>> autoconf it can be addressed then?
>
> I'd like to here from Roger about what this means for NetBSD and uclibc,
> if it works on those then I think it is fine to do this.

Sorry for the delay, I just received this today (don't know why). I've 
been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.

What I don't really like is the hardcoded (16 * 1024) value, how do you 
know this is greater than PTHREAD_STACK_MIN?

Frankly I don't understand why do we have to touch this, even if you 
requested 256MB of stack it won't we allocated until you get a page 
fault, so you are only using the physical memory you need.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:12:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdR7-0001bf-Re; Thu, 21 Jun 2012 09:12:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1ShdR6-0001bU-1e
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:12:20 +0000
Received: from [85.158.143.99:30524] by server-1.bemta-4.messagelabs.com id
	4B/8F-24392-375E2EF4; Thu, 21 Jun 2012 09:12:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340269938!27503335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17292 invoked from network); 21 Jun 2012 09:12:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:12:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:12:18 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 10:12:18 +0100
Message-ID: <4FE2E571.5040505@citrix.com>
Date: Thu, 21 Jun 2012 10:12:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com>
	<20120620164413.GB2640@US-SEA-R8XVZTX>
	<20120620182742.GC2640@US-SEA-R8XVZTX>
In-Reply-To: <20120620182742.GC2640@US-SEA-R8XVZTX>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson wrote:
> On Wed, Jun 20, 2012 at 09:44:13AM -0700, Wilson, Matt wrote:
>> On Wed, Jun 20, 2012 at 01:51:17AM -0700, Roger Pau Monne wrote:
>>> Matt Wilson wrote:
>>>> +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
>>> I would prefer to set FSIMAGE_FSDIR or an equivalent define in
>>> tools/config.h and include that header in
>>> tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that
>>> value from the compiler command line.
>
> It turns out to be tricky to do this, since you have to recursively
> expand the value from libdir="${exec_prefix}/lib". Also, it's counter
> to the generally accepted pattern for passing these types of variables
> down when using autoconf, which actually is to use -D in CFLAGS.
>
> See also this thread:
>    http://stackoverflow.com/questions/5867136/autoconf-how-to-get-installation-paths-into-config-h

Fair enough, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:12:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdR7-0001bf-Re; Thu, 21 Jun 2012 09:12:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1ShdR6-0001bU-1e
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:12:20 +0000
Received: from [85.158.143.99:30524] by server-1.bemta-4.messagelabs.com id
	4B/8F-24392-375E2EF4; Thu, 21 Jun 2012 09:12:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340269938!27503335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17292 invoked from network); 21 Jun 2012 09:12:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:12:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:12:18 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 10:12:18 +0100
Message-ID: <4FE2E571.5040505@citrix.com>
Date: Thu, 21 Jun 2012 10:12:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <0a592e08ac31b3934372.1340153217@kaos-source-31003.sea31.amazon.com>
	<4FE18F05.8030309@citrix.com>
	<20120620164413.GB2640@US-SEA-R8XVZTX>
	<20120620182742.GC2640@US-SEA-R8XVZTX>
In-Reply-To: <20120620182742.GC2640@US-SEA-R8XVZTX>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: honour --libdir when it is passed to
 ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson wrote:
> On Wed, Jun 20, 2012 at 09:44:13AM -0700, Wilson, Matt wrote:
>> On Wed, Jun 20, 2012 at 01:51:17AM -0700, Roger Pau Monne wrote:
>>> Matt Wilson wrote:
>>>> +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
>>> I would prefer to set FSIMAGE_FSDIR or an equivalent define in
>>> tools/config.h and include that header in
>>> tools/libfsimage/common/fsimage_plugin.h, so we don't have to pass that
>>> value from the compiler command line.
>
> It turns out to be tricky to do this, since you have to recursively
> expand the value from libdir="${exec_prefix}/lib". Also, it's counter
> to the generally accepted pattern for passing these types of variables
> down when using autoconf, which actually is to use -D in CFLAGS.
>
> See also this thread:
>    http://stackoverflow.com/questions/5867136/autoconf-how-to-get-installation-paths-into-config-h

Fair enough, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdRD-0001c8-7Q; Thu, 21 Jun 2012 09:12:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdRB-0001bv-TA
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:12:26 +0000
Received: from [193.109.254.147:45436] by server-12.bemta-14.messagelabs.com
	id E5/3B-30461-975E2EF4; Thu, 21 Jun 2012 09:12:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340269944!3685768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6652 invoked from network); 21 Jun 2012 09:12:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:12:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:12:24 +0100
Message-ID: <1340269942.21872.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:12:22 +0100
In-Reply-To: <5d3cbf2e6370d1989bcd.1339779873@Solace>
References: <patchbomb.1339779868@Solace>
	<5d3cbf2e6370d1989bcd.1339779873@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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 Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> And leave to the caller the burden of knowing and remembering what kind
> of bitmap each instance of libxl_bitmap is.
> 
> This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some other
> related interface name substitution, e.g., libxl_for_each_cpu) in a bunch
> of files, with no real functional change involved.
> 
> A specific allocation helper is introduced, besides libxl_bitmap_alloc().
> It is called libxl_cpu_bitmap_alloc() and is meant at substituting the old
> libxl_cpumap_alloc(). It is just something easier to use in cases where one
> wants to allocate a libxl_bitmap that is going to serve as a cpu map.
> 
> This is because we want to be able to deal with both cpu and NUMA node
> maps, but we don't want to duplicate all the various helpers and wrappers.

FWIW I'd have been perfectly happy with a bunch of 
	#define for_each_cpu(mumble) for_each_bit(mumble)
type stuff, but I think Ian J and yourself didn't like those which I'm
also fine with.

> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -99,8 +99,8 @@ yajl_gen_status libxl_uuid_gen_json(yajl
>      return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUID_FMTLEN);
>  }
> 
> -yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand,
> -                                      libxl_cpumap *cpumap)
> +yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
> +                                      libxl_bitmap *cpumap)

Minor nit: You likely meant to rename cpumap in the argument list too.

>  {
>      yajl_gen_status s;
>      int i;
> @@ -108,8 +108,8 @@ yajl_gen_status libxl_cpumap_gen_json(ya
>      s = yajl_gen_array_open(hand);
>      if (s != yajl_gen_status_ok) goto out;
> 
> -    libxl_for_each_cpu(i, *cpumap) {
> -        if (libxl_cpumap_test(cpumap, i)) {
> +    libxl_for_each_bit(i, *cpumap) {
> +        if (libxl_bitmap_test(cpumap, i)) {
>              s = yajl_gen_integer(hand, i);
>              if (s != yajl_gen_status_ok) goto out;
>          }

Even with that minor nit:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdRD-0001c8-7Q; Thu, 21 Jun 2012 09:12:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdRB-0001bv-TA
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:12:26 +0000
Received: from [193.109.254.147:45436] by server-12.bemta-14.messagelabs.com
	id E5/3B-30461-975E2EF4; Thu, 21 Jun 2012 09:12:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340269944!3685768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6652 invoked from network); 21 Jun 2012 09:12:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13140888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:12:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:12:24 +0100
Message-ID: <1340269942.21872.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:12:22 +0100
In-Reply-To: <5d3cbf2e6370d1989bcd.1339779873@Solace>
References: <patchbomb.1339779868@Solace>
	<5d3cbf2e6370d1989bcd.1339779873@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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 Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> And leave to the caller the burden of knowing and remembering what kind
> of bitmap each instance of libxl_bitmap is.
> 
> This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some other
> related interface name substitution, e.g., libxl_for_each_cpu) in a bunch
> of files, with no real functional change involved.
> 
> A specific allocation helper is introduced, besides libxl_bitmap_alloc().
> It is called libxl_cpu_bitmap_alloc() and is meant at substituting the old
> libxl_cpumap_alloc(). It is just something easier to use in cases where one
> wants to allocate a libxl_bitmap that is going to serve as a cpu map.
> 
> This is because we want to be able to deal with both cpu and NUMA node
> maps, but we don't want to duplicate all the various helpers and wrappers.

FWIW I'd have been perfectly happy with a bunch of 
	#define for_each_cpu(mumble) for_each_bit(mumble)
type stuff, but I think Ian J and yourself didn't like those which I'm
also fine with.

> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -99,8 +99,8 @@ yajl_gen_status libxl_uuid_gen_json(yajl
>      return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUID_FMTLEN);
>  }
> 
> -yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand,
> -                                      libxl_cpumap *cpumap)
> +yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
> +                                      libxl_bitmap *cpumap)

Minor nit: You likely meant to rename cpumap in the argument list too.

>  {
>      yajl_gen_status s;
>      int i;
> @@ -108,8 +108,8 @@ yajl_gen_status libxl_cpumap_gen_json(ya
>      s = yajl_gen_array_open(hand);
>      if (s != yajl_gen_status_ok) goto out;
> 
> -    libxl_for_each_cpu(i, *cpumap) {
> -        if (libxl_cpumap_test(cpumap, i)) {
> +    libxl_for_each_bit(i, *cpumap) {
> +        if (libxl_bitmap_test(cpumap, i)) {
>              s = yajl_gen_integer(hand, i);
>              if (s != yajl_gen_status_ok) goto out;
>          }

Even with that minor nit:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:18:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdXK-0001x9-2U; Thu, 21 Jun 2012 09:18: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 1ShdXI-0001wz-K8
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:18:44 +0000
Received: from [85.158.138.51:60933] by server-3.bemta-3.messagelabs.com id
	15/D2-26490-3F6E2EF4; Thu, 21 Jun 2012 09:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340270322!28692921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7701 invoked from network); 21 Jun 2012 09:18:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141061"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:18:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:18:42 +0100
Message-ID: <1340270320.21872.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 21 Jun 2012 10:18:40 +0100
In-Reply-To: <4FE2E4DC.5030500@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 10:09 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
> >> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
> >>
> >>> If this little trick applies to both NetBSD and uclibc too then I guess
> >>> it would be OK, otherwise I think autoconf is necessary.
> >> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
> >> makefile unilaterally sets USE_PTHREAD for example.
> >
> > It has autoconf stuff available to it, I think, it just hasn't had cause
> > to use it yet...
> >
> > (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
> > library/cmdline tools and is for building against libc's which don't
> > have pthreads)
> >
> >> Shall I just drop this test for now and if/when xenstore is updated to use
> >> autoconf it can be addressed then?
> >
> > I'd like to here from Roger about what this means for NetBSD and uclibc,
> > if it works on those then I think it is fine to do this.
> 
> Sorry for the delay, I just received this today (don't know why).

It seemed to have been stuck in my outbox, I thought it was another
unrelated mail (which I sent this morning) so I hit go.

BTW, I think this patch went in already...

>  I've 
> been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.
> 
> What I don't really like is the hardcoded (16 * 1024) value, how do you 
> know this is greater than PTHREAD_STACK_MIN?

pthread_attr_setstacksize(1) specifically says that PTHREAD_STACK_MIN is
16K, but I don't know if that is a real specified thing or just Linux
bias in the manpage.

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html doesn't seem to say anything about the value of PTHREAD_STACK_MIN.

How about we fix this when we come across a system which has a smaller
minimum stack?

> Frankly I don't understand why do we have to touch this, even if you 
> requested 256MB of stack it won't we allocated until you get a page 
> fault, so you are only using the physical memory you need.

With 256M stack 4 threads would take up 1G of your virtual address space
(regardless of whether it is populated or not), and 12 threads would
take up 3G -- which is the whole virtual address space of a 32 bit
process, which is rather limiting.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:18:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdXK-0001x9-2U; Thu, 21 Jun 2012 09:18: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 1ShdXI-0001wz-K8
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:18:44 +0000
Received: from [85.158.138.51:60933] by server-3.bemta-3.messagelabs.com id
	15/D2-26490-3F6E2EF4; Thu, 21 Jun 2012 09:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340270322!28692921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7701 invoked from network); 21 Jun 2012 09:18:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141061"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:18:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:18:42 +0100
Message-ID: <1340270320.21872.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 21 Jun 2012 10:18:40 +0100
In-Reply-To: <4FE2E4DC.5030500@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 10:09 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
> >> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
> >>
> >>> If this little trick applies to both NetBSD and uclibc too then I guess
> >>> it would be OK, otherwise I think autoconf is necessary.
> >> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
> >> makefile unilaterally sets USE_PTHREAD for example.
> >
> > It has autoconf stuff available to it, I think, it just hasn't had cause
> > to use it yet...
> >
> > (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
> > library/cmdline tools and is for building against libc's which don't
> > have pthreads)
> >
> >> Shall I just drop this test for now and if/when xenstore is updated to use
> >> autoconf it can be addressed then?
> >
> > I'd like to here from Roger about what this means for NetBSD and uclibc,
> > if it works on those then I think it is fine to do this.
> 
> Sorry for the delay, I just received this today (don't know why).

It seemed to have been stuck in my outbox, I thought it was another
unrelated mail (which I sent this morning) so I hit go.

BTW, I think this patch went in already...

>  I've 
> been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.
> 
> What I don't really like is the hardcoded (16 * 1024) value, how do you 
> know this is greater than PTHREAD_STACK_MIN?

pthread_attr_setstacksize(1) specifically says that PTHREAD_STACK_MIN is
16K, but I don't know if that is a real specified thing or just Linux
bias in the manpage.

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html doesn't seem to say anything about the value of PTHREAD_STACK_MIN.

How about we fix this when we come across a system which has a smaller
minimum stack?

> Frankly I don't understand why do we have to touch this, even if you 
> requested 256MB of stack it won't we allocated until you get a page 
> fault, so you are only using the physical memory you need.

With 256M stack 4 threads would take up 1G of your virtual address space
(regardless of whether it is populated or not), and 12 threads would
take up 3G -- which is the whole virtual address space of a 32 bit
process, which is rather limiting.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:22:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdaO-00023b-Lr; Thu, 21 Jun 2012 09:21:56 +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 1ShdaN-00023U-3D
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:21:55 +0000
Received: from [193.109.254.147:28240] by server-7.bemta-14.messagelabs.com id
	18/77-29827-2B7E2EF4; Thu, 21 Jun 2012 09:21:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340270508!3795799!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17317 invoked from network); 21 Jun 2012 09:21:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:21:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:21:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:21:07 +0100
Message-ID: <1340270466.21872.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 21 Jun 2012 10:21:06 +0100
In-Reply-To: <20120621085338.GA18516@aepfle.de>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621085338.GA18516@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 09:53 +0100, Olaf Hering wrote:
> On Thu, Jun 21, Ian Campbell wrote:
> 
> > On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > > Currently shared libraries are automatically installed into /usr/lib
> > > or /usr/lib64, depending on the supplied --prefix value and
> > > $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> > > do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> > > 
> > > With this change, packagers can supply the desired location for shared
> > > libraries on the ./configure command line. Packagers need to note that
> > > the default behaviour on 64-bit Linux systems will be to install shared
> > > libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> > > to ./configure.
> 
> Perhaps that should be stated in the README, which states to call just
> configure without options.

I'd have assumed that it was well understood what options one
could/should pass to configure? Anybody who's ever built anything on a
system which uses lib64 must know it, right?

Anyway, README already says:
   If you want, you can run ./configure --help to see the list of
   options available options when building and installing Xen.

> 
> > >  SHAREDIR    ?= $(PREFIX)/share
> > >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > > @@ -67,7 +68,7 @@ endef
> > >  
> > >  ifneq ($(EXTRA_PREFIX),)
> > >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> > 
> > since we are sort of reverting 16950:0faf620bc749 here this could in
> > theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> > include Tools.mk though. :-/
> > 
> > Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> > hypervisor and other non-tools builds? If not then we could consider
> > pushing it down a level.
> > 
> > In the tools case I think we already have a way to inject arbitrary -L
> > and -I options -- so maybe this can just go away?
> 
> I'm not sure what the purpose of EXTRA_INCLUDES and EXTRA_LIB is, now
> that EXTRA_CFLAGS can be specified, since changeset 25464:75a2bb5db228.
> 
> Perhaps its use case should also be added to the README?

It sounds to me like it could be deleted instead.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:22:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShdaO-00023b-Lr; Thu, 21 Jun 2012 09:21:56 +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 1ShdaN-00023U-3D
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:21:55 +0000
Received: from [193.109.254.147:28240] by server-7.bemta-14.messagelabs.com id
	18/77-29827-2B7E2EF4; Thu, 21 Jun 2012 09:21:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340270508!3795799!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17317 invoked from network); 21 Jun 2012 09:21:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:21:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:21:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:21:07 +0100
Message-ID: <1340270466.21872.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 21 Jun 2012 10:21:06 +0100
In-Reply-To: <20120621085338.GA18516@aepfle.de>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621085338.GA18516@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 09:53 +0100, Olaf Hering wrote:
> On Thu, Jun 21, Ian Campbell wrote:
> 
> > On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > > Currently shared libraries are automatically installed into /usr/lib
> > > or /usr/lib64, depending on the supplied --prefix value and
> > > $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> > > do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> > > 
> > > With this change, packagers can supply the desired location for shared
> > > libraries on the ./configure command line. Packagers need to note that
> > > the default behaviour on 64-bit Linux systems will be to install shared
> > > libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> > > to ./configure.
> 
> Perhaps that should be stated in the README, which states to call just
> configure without options.

I'd have assumed that it was well understood what options one
could/should pass to configure? Anybody who's ever built anything on a
system which uses lib64 must know it, right?

Anyway, README already says:
   If you want, you can run ./configure --help to see the list of
   options available options when building and installing Xen.

> 
> > >  SHAREDIR    ?= $(PREFIX)/share
> > >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > > @@ -67,7 +68,7 @@ endef
> > >  
> > >  ifneq ($(EXTRA_PREFIX),)
> > >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> > 
> > since we are sort of reverting 16950:0faf620bc749 here this could in
> > theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> > include Tools.mk though. :-/
> > 
> > Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> > hypervisor and other non-tools builds? If not then we could consider
> > pushing it down a level.
> > 
> > In the tools case I think we already have a way to inject arbitrary -L
> > and -I options -- so maybe this can just go away?
> 
> I'm not sure what the purpose of EXTRA_INCLUDES and EXTRA_LIB is, now
> that EXTRA_CFLAGS can be specified, since changeset 25464:75a2bb5db228.
> 
> Perhaps its use case should also be added to the README?

It sounds to me like it could be deleted instead.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:27:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:27: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 1ShdfR-0002Fb-DN; Thu, 21 Jun 2012 09:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdfP-0002FV-KJ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:27:07 +0000
Received: from [85.158.143.99:19200] by server-1.bemta-4.messagelabs.com id
	8D/01-24392-AE8E2EF4; Thu, 21 Jun 2012 09:27:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340270826!20712748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 21 Jun 2012 09:27:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:27:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:26:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:26:50 +0100
Message-ID: <1340270809.21872.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Jun 2012 10:26:49 +0100
In-Reply-To: <1340266524.21872.2.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
	<20120606181852.GB38649@ocelot.phlegethon.org>
	<1340266524.21872.2.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
 paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 09:15 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 19:18 +0100, Tim Deegan wrote:
> > At 19:04 +0100 on 06 Jun (1339009473), Stefano Stabellini wrote:
> > > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > >  xen/arch/arm/mm.c |    8 ++++++++
> > > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > > index 160a4e9..ab52171 100644
> > > > --- a/xen/arch/arm/mm.c
> > > > +++ b/xen/arch/arm/mm.c
> > > > @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> > > >      lpae_t pte, *p;
> > > >      int i;
> > > >  
> > > > +    if ( boot_phys_offset != 0 )
> > > > +    {
> > > > +        /* Remove the old identity mapping of the boot paddr */
> > > > +        pte.bits = 0;
> > > > +        dest_va = (unsigned long)_start + boot_phys_offset;
> > > > +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> > > > +    }
> > > 
> > > It looks like we are already doing this few lines below.
> > 
> > We used to do this here and now we do it futher down, after the copy.
> > That way the secondary CPUs can come up on the pre-copy tables where
> > the identity map still exists.
> 
> I think I wrote this patch before your SMP series went in, but since
> there was no textual conflict I didn't notice that I should nuke it.
> 
> Hrm... I was about to do the nuking but without it I see:
> 
>         At 0x00000000, Error: Pagetable properties were remapped while
>         MMU was enabled, may be stale translations

I must've been running a stale hypervisor image because now I don't see
this even with the patch removed.

So I've now nuked the patch from 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 Thu Jun 21 09:27:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:27: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 1ShdfR-0002Fb-DN; Thu, 21 Jun 2012 09:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdfP-0002FV-KJ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:27:07 +0000
Received: from [85.158.143.99:19200] by server-1.bemta-4.messagelabs.com id
	8D/01-24392-AE8E2EF4; Thu, 21 Jun 2012 09:27:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340270826!20712748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 21 Jun 2012 09:27:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:27:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:26:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:26:50 +0100
Message-ID: <1340270809.21872.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Jun 2012 10:26:49 +0100
In-Reply-To: <1340266524.21872.2.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-25-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206061846260.2415@kaball.uk.xensource.com>
	<20120606181852.GB38649@ocelot.phlegethon.org>
	<1340266524.21872.2.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot
 paddr when we are done with it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 09:15 +0100, Ian Campbell wrote:
> On Wed, 2012-06-06 at 19:18 +0100, Tim Deegan wrote:
> > At 19:04 +0100 on 06 Jun (1339009473), Stefano Stabellini wrote:
> > > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > >  xen/arch/arm/mm.c |    8 ++++++++
> > > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > > index 160a4e9..ab52171 100644
> > > > --- a/xen/arch/arm/mm.c
> > > > +++ b/xen/arch/arm/mm.c
> > > > @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
> > > >      lpae_t pte, *p;
> > > >      int i;
> > > >  
> > > > +    if ( boot_phys_offset != 0 )
> > > > +    {
> > > > +        /* Remove the old identity mapping of the boot paddr */
> > > > +        pte.bits = 0;
> > > > +        dest_va = (unsigned long)_start + boot_phys_offset;
> > > > +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> > > > +    }
> > > 
> > > It looks like we are already doing this few lines below.
> > 
> > We used to do this here and now we do it futher down, after the copy.
> > That way the secondary CPUs can come up on the pre-copy tables where
> > the identity map still exists.
> 
> I think I wrote this patch before your SMP series went in, but since
> there was no textual conflict I didn't notice that I should nuke it.
> 
> Hrm... I was about to do the nuking but without it I see:
> 
>         At 0x00000000, Error: Pagetable properties were remapped while
>         MMU was enabled, may be stale translations

I must've been running a stale hypervisor image because now I don't see
this even with the patch removed.

So I've now nuked the patch from 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 Thu Jun 21 09:30:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:30: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 1ShdiP-0002Nl-4j; Thu, 21 Jun 2012 09:30: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 1ShdiO-0002Nf-7O
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:30:12 +0000
Received: from [85.158.143.35:33346] by server-1.bemta-4.messagelabs.com id
	9A/D7-24392-3A9E2EF4; Thu, 21 Jun 2012 09:30:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340271009!13354995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 445 invoked from network); 21 Jun 2012 09:30:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:30:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:30:09 +0100
Message-ID: <1340271008.21872.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:30:08 +0100
In-Reply-To: <8ef7de2b4328e4f65982.1339779874@Solace>
References: <patchbomb.1339779868@Solace>
	<8ef7de2b4328e4f65982.1339779874@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06 of 10 v2] libxl: expand the libxl_bitmap
	API a 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 Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> By adding copying and *_is_full/*_is_empty facilities.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * now libxl_is_full/empty return 1 if true and 0 if false,
>    as logic (and as requested during review).
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -506,6 +506,35 @@ void libxl_bitmap_dispose(libxl_bitmap *
>      free(map->map);
>  }
>  
> +void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                       const libxl_bitmap *sptr)
> +{
> +    int sz;
> +
> +    sz = dptr->size = sptr->size;
> +    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));

I think you need either some checks/asserts on the two relative sizes or
a reallocation of the destination map. Otherwise you risk an overflow.

Perhaps a simple assert (i.e. make it the callers problem) would be ok?

> +}
> +
> +int libxl_bitmap_is_full(const libxl_bitmap *bitmap)
> +{
> +    int i;
> +
> +    for (i = 0; i < bitmap->size; i++)
> +        if (bitmap->map[i] != (uint8_t)-1)
> +            return 0;
> +   return 1;
> +}
> +
> +int libxl_bitmap_is_empty(const libxl_bitmap *bitmap)
> +{
> +    int i;
> +
> +    for (i = 0; i < bitmap->size; i++)
> +        if (bitmap->map[i])
> +            return 0;
> +    return 1;
> +}
> +
>  int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit)
>  {
>      if (bit >= bitmap->size * 8)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -66,6 +66,10 @@ int libxl_vdev_to_device_disk(libxl_ctx 
>  int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits);
>      /* Allocated bimap is from malloc, libxl_bitmap_dispose() to be
>       * called by the application when done. */
> +void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                       const libxl_bitmap *sptr);
> +int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
> +int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
>  int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
>  void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
>  void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:30:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:30: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 1ShdiP-0002Nl-4j; Thu, 21 Jun 2012 09:30: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 1ShdiO-0002Nf-7O
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:30:12 +0000
Received: from [85.158.143.35:33346] by server-1.bemta-4.messagelabs.com id
	9A/D7-24392-3A9E2EF4; Thu, 21 Jun 2012 09:30:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340271009!13354995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 445 invoked from network); 21 Jun 2012 09:30:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:30:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:30:09 +0100
Message-ID: <1340271008.21872.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:30:08 +0100
In-Reply-To: <8ef7de2b4328e4f65982.1339779874@Solace>
References: <patchbomb.1339779868@Solace>
	<8ef7de2b4328e4f65982.1339779874@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06 of 10 v2] libxl: expand the libxl_bitmap
	API a 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 Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> By adding copying and *_is_full/*_is_empty facilities.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * now libxl_is_full/empty return 1 if true and 0 if false,
>    as logic (and as requested during review).
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -506,6 +506,35 @@ void libxl_bitmap_dispose(libxl_bitmap *
>      free(map->map);
>  }
>  
> +void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                       const libxl_bitmap *sptr)
> +{
> +    int sz;
> +
> +    sz = dptr->size = sptr->size;
> +    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));

I think you need either some checks/asserts on the two relative sizes or
a reallocation of the destination map. Otherwise you risk an overflow.

Perhaps a simple assert (i.e. make it the callers problem) would be ok?

> +}
> +
> +int libxl_bitmap_is_full(const libxl_bitmap *bitmap)
> +{
> +    int i;
> +
> +    for (i = 0; i < bitmap->size; i++)
> +        if (bitmap->map[i] != (uint8_t)-1)
> +            return 0;
> +   return 1;
> +}
> +
> +int libxl_bitmap_is_empty(const libxl_bitmap *bitmap)
> +{
> +    int i;
> +
> +    for (i = 0; i < bitmap->size; i++)
> +        if (bitmap->map[i])
> +            return 0;
> +    return 1;
> +}
> +
>  int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit)
>  {
>      if (bit >= bitmap->size * 8)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -66,6 +66,10 @@ int libxl_vdev_to_device_disk(libxl_ctx 
>  int libxl_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *bitmap, int n_bits);
>      /* Allocated bimap is from malloc, libxl_bitmap_dispose() to be
>       * called by the application when done. */
> +void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                       const libxl_bitmap *sptr);
> +int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
> +int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
>  int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
>  void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
>  void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:35:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdnJ-0002dm-0s; Thu, 21 Jun 2012 09:35:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdnH-0002de-AQ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:35:15 +0000
Received: from [85.158.143.99:21095] by server-3.bemta-4.messagelabs.com id
	6D/67-05808-2DAE2EF4; Thu, 21 Jun 2012 09:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340271311!23163537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17833 invoked from network); 21 Jun 2012 09:35:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 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.213.0;
	Thu, 21 Jun 2012 10:35:11 +0100
Message-ID: <1340271310.21872.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:35:10 +0100
In-Reply-To: <c5707aff782ac5248339.1339779875@Solace>
References: <patchbomb.1339779868@Solace>
	<c5707aff782ac5248339.1339779875@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07 of 10 v2] libxl: introduce some node map
	helpers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:

> +int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
> +                            const libxl_bitmap *nodemap,
> +                            libxl_bitmap *cpumap);
> +    /* populate cpumap with the cpus spanned by the nodes in nodemap */

Comments before proto please (I know libxl is a bit of a mish-mash, but
we'll try to be consistent going forward...)

Otherwise: Acked-by: Ian Campbell <ian.campbell@citrix.com>

> +int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
> +                            const libxl_bitmap *cpuemap,
> +                            libxl_bitmap *nodemap);
> +    /* populate nodemap with the nodes of the cpus in cpumap */
> +
>  static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
>      return (s + 1023) / 1024;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:35:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdnJ-0002dm-0s; Thu, 21 Jun 2012 09:35:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1ShdnH-0002de-AQ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:35:15 +0000
Received: from [85.158.143.99:21095] by server-3.bemta-4.messagelabs.com id
	6D/67-05808-2DAE2EF4; Thu, 21 Jun 2012 09:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340271311!23163537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17833 invoked from network); 21 Jun 2012 09:35:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 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.213.0;
	Thu, 21 Jun 2012 10:35:11 +0100
Message-ID: <1340271310.21872.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:35:10 +0100
In-Reply-To: <c5707aff782ac5248339.1339779875@Solace>
References: <patchbomb.1339779868@Solace>
	<c5707aff782ac5248339.1339779875@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07 of 10 v2] libxl: introduce some node map
	helpers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:

> +int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
> +                            const libxl_bitmap *nodemap,
> +                            libxl_bitmap *cpumap);
> +    /* populate cpumap with the cpus spanned by the nodes in nodemap */

Comments before proto please (I know libxl is a bit of a mish-mash, but
we'll try to be consistent going forward...)

Otherwise: Acked-by: Ian Campbell <ian.campbell@citrix.com>

> +int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
> +                            const libxl_bitmap *cpuemap,
> +                            libxl_bitmap *nodemap);
> +    /* populate nodemap with the nodes of the cpus in cpumap */
> +
>  static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
>      return (s + 1023) / 1024;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:39:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdrZ-0002mf-N5; Thu, 21 Jun 2012 09:39: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 1ShdrX-0002mX-TI
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:39:40 +0000
Received: from [193.109.254.147:28223] by server-2.bemta-14.messagelabs.com id
	67/BD-01735-BDBE2EF4; Thu, 21 Jun 2012 09:39:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340271578!10931108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6227 invoked from network); 21 Jun 2012 09:39:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:39:38 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 10:39:38 +0100
Message-ID: <4FE2EBD9.4040101@citrix.com>
Date: Thu, 21 Jun 2012 10:39:37 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340270320.21872.31.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-21 at 10:09 +0100, Roger Pau Monne wrote:
>> Ian Campbell wrote:
>>> On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
>>>> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
>>>>
>>>>> If this little trick applies to both NetBSD and uclibc too then I guess
>>>>> it would be OK, otherwise I think autoconf is necessary.
>>>> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
>>>> makefile unilaterally sets USE_PTHREAD for example.
>>> It has autoconf stuff available to it, I think, it just hasn't had cause
>>> to use it yet...
>>>
>>> (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
>>> library/cmdline tools and is for building against libc's which don't
>>> have pthreads)
>>>
>>>> Shall I just drop this test for now and if/when xenstore is updated to use
>>>> autoconf it can be addressed then?
>>> I'd like to here from Roger about what this means for NetBSD and uclibc,
>>> if it works on those then I think it is fine to do this.
>> Sorry for the delay, I just received this today (don't know why).
>
> It seemed to have been stuck in my outbox, I thought it was another
> unrelated mail (which I sent this morning) so I hit go.
>
> BTW, I think this patch went in already...
>
>>   I've
>> been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.
>>
>> What I don't really like is the hardcoded (16 * 1024) value, how do you
>> know this is greater than PTHREAD_STACK_MIN?
>
> pthread_attr_setstacksize(1) specifically says that PTHREAD_STACK_MIN is
> 16K, but I don't know if that is a real specified thing or just Linux
> bias in the manpage.

PTHREAD_STACK_MIN it's also present on NetBSD and uClibc, so I guess we 
should use PTHREAD_STACK_MIN (or PTHREAD_STACK_MIN * 2) if the default 
stack size has to be changed to some sensible value (which I still don't 
think it has to). Can we guarantee PTHREAD_STACK_MIN is not going to 
change to something greater than 16k thus breaking this patch?

> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html doesn't seem to say anything about the value of PTHREAD_STACK_MIN.
>
> How about we fix this when we come across a system which has a smaller
> minimum stack?
>
>> Frankly I don't understand why do we have to touch this, even if you
>> requested 256MB of stack it won't we allocated until you get a page
>> fault, so you are only using the physical memory you need.
>
> With 256M stack 4 threads would take up 1G of your virtual address space
> (regardless of whether it is populated or not), and 12 threads would
> take up 3G -- which is the whole virtual address space of a 32 bit
> process, which is rather limiting.

This should be set by the OS to a sensible value that allows creating a 
reasonable number of threads, given that the default in Linux is 8MB, it 
will allow you to create 375 threads on a 32bit system, which looks like 
a pretty high number to me. Anyway limiting the stack size of a single 
thread won't make much of difference regarding this, because all the 
other threads will still take the default value.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:39:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdrZ-0002mf-N5; Thu, 21 Jun 2012 09:39: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 1ShdrX-0002mX-TI
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:39:40 +0000
Received: from [193.109.254.147:28223] by server-2.bemta-14.messagelabs.com id
	67/BD-01735-BDBE2EF4; Thu, 21 Jun 2012 09:39:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340271578!10931108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6227 invoked from network); 21 Jun 2012 09:39:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13141673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:39:38 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 10:39:38 +0100
Message-ID: <4FE2EBD9.4040101@citrix.com>
Date: Thu, 21 Jun 2012 10:39:37 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340270320.21872.31.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-21 at 10:09 +0100, Roger Pau Monne wrote:
>> Ian Campbell wrote:
>>> On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
>>>> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
>>>>
>>>>> If this little trick applies to both NetBSD and uclibc too then I guess
>>>>> it would be OK, otherwise I think autoconf is necessary.
>>>> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
>>>> makefile unilaterally sets USE_PTHREAD for example.
>>> It has autoconf stuff available to it, I think, it just hasn't had cause
>>> to use it yet...
>>>
>>> (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
>>> library/cmdline tools and is for building against libc's which don't
>>> have pthreads)
>>>
>>>> Shall I just drop this test for now and if/when xenstore is updated to use
>>>> autoconf it can be addressed then?
>>> I'd like to here from Roger about what this means for NetBSD and uclibc,
>>> if it works on those then I think it is fine to do this.
>> Sorry for the delay, I just received this today (don't know why).
>
> It seemed to have been stuck in my outbox, I thought it was another
> unrelated mail (which I sent this morning) so I hit go.
>
> BTW, I think this patch went in already...
>
>>   I've
>> been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.
>>
>> What I don't really like is the hardcoded (16 * 1024) value, how do you
>> know this is greater than PTHREAD_STACK_MIN?
>
> pthread_attr_setstacksize(1) specifically says that PTHREAD_STACK_MIN is
> 16K, but I don't know if that is a real specified thing or just Linux
> bias in the manpage.

PTHREAD_STACK_MIN it's also present on NetBSD and uClibc, so I guess we 
should use PTHREAD_STACK_MIN (or PTHREAD_STACK_MIN * 2) if the default 
stack size has to be changed to some sensible value (which I still don't 
think it has to). Can we guarantee PTHREAD_STACK_MIN is not going to 
change to something greater than 16k thus breaking this patch?

> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html doesn't seem to say anything about the value of PTHREAD_STACK_MIN.
>
> How about we fix this when we come across a system which has a smaller
> minimum stack?
>
>> Frankly I don't understand why do we have to touch this, even if you
>> requested 256MB of stack it won't we allocated until you get a page
>> fault, so you are only using the physical memory you need.
>
> With 256M stack 4 threads would take up 1G of your virtual address space
> (regardless of whether it is populated or not), and 12 threads would
> take up 3G -- which is the whole virtual address space of a 32 bit
> process, which is rather limiting.

This should be set by the OS to a sensible value that allows creating a 
reasonable number of threads, given that the default in Linux is 8MB, it 
will allow you to create 375 threads on a 32bit system, which looks like 
a pretty high number to me. Anyway limiting the stack size of a single 
thread won't make much of difference regarding this, because all the 
other threads will still take the default value.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdxE-0002xa-GH; Thu, 21 Jun 2012 09:45:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShdxD-0002xV-Pz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:45:32 +0000
Received: from [85.158.138.51:58318] by server-12.bemta-3.messagelabs.com id
	9F/EE-30206-63DE2EF4; Thu, 21 Jun 2012 09:45:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340271926!28762986!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28546 invoked from network); 21 Jun 2012 09:45:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 09:45:26 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035483; Thu, 21 Jun 2012 11:45:25 +0200
Message-ID: <1340271893.4856.1.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 11:44:53 +0200
In-Reply-To: <1340271310.21872.39.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<c5707aff782ac5248339.1339779875@Solace>
	<1340271310.21872.39.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07 of 10 v2] libxl: introduce some node map
	helpers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4850892310211227805=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4850892310211227805==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IMaqDooBkKwbYDlCNuqj"


--=-IMaqDooBkKwbYDlCNuqj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:35 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
>=20
> > +int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
> > +                            const libxl_bitmap *nodemap,
> > +                            libxl_bitmap *cpumap);
> > +    /* populate cpumap with the cpus spanned by the nodes in nodemap *=
/
>=20
> Comments before proto please=20
>
Ok.

> (I know libxl is a bit of a mish-mash, but
> we'll try to be consistent going forward...)
>=20
Yeah, it's just hard to figure out which one of the various suits you
can find in the file(s) for similar things that one should follow! :-P

Thanks for looking at this,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-IMaqDooBkKwbYDlCNuqj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i7RUACgkQk4XaBE3IOsSEFgCgiAmkb2BEinVYCCISKX3QKyeg
w18AnRvWjz6PMVnhljCcS+evgM+3RNMF
=o4Zb
-----END PGP SIGNATURE-----

--=-IMaqDooBkKwbYDlCNuqj--



--===============4850892310211227805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4850892310211227805==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 09:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1ShdxE-0002xa-GH; Thu, 21 Jun 2012 09:45:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShdxD-0002xV-Pz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:45:32 +0000
Received: from [85.158.138.51:58318] by server-12.bemta-3.messagelabs.com id
	9F/EE-30206-63DE2EF4; Thu, 21 Jun 2012 09:45:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340271926!28762986!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28546 invoked from network); 21 Jun 2012 09:45:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 09:45:26 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035483; Thu, 21 Jun 2012 11:45:25 +0200
Message-ID: <1340271893.4856.1.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 11:44:53 +0200
In-Reply-To: <1340271310.21872.39.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<c5707aff782ac5248339.1339779875@Solace>
	<1340271310.21872.39.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07 of 10 v2] libxl: introduce some node map
	helpers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4850892310211227805=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4850892310211227805==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IMaqDooBkKwbYDlCNuqj"


--=-IMaqDooBkKwbYDlCNuqj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:35 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
>=20
> > +int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
> > +                            const libxl_bitmap *nodemap,
> > +                            libxl_bitmap *cpumap);
> > +    /* populate cpumap with the cpus spanned by the nodes in nodemap *=
/
>=20
> Comments before proto please=20
>
Ok.

> (I know libxl is a bit of a mish-mash, but
> we'll try to be consistent going forward...)
>=20
Yeah, it's just hard to figure out which one of the various suits you
can find in the file(s) for similar things that one should follow! :-P

Thanks for looking at this,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-IMaqDooBkKwbYDlCNuqj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i7RUACgkQk4XaBE3IOsSEFgCgiAmkb2BEinVYCCISKX3QKyeg
w18AnRvWjz6PMVnhljCcS+evgM+3RNMF
=o4Zb
-----END PGP SIGNATURE-----

--=-IMaqDooBkKwbYDlCNuqj--



--===============4850892310211227805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4850892310211227805==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 09:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shdxs-00030O-UA; Thu, 21 Jun 2012 09:46:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Shdxr-000308-De
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:46:11 +0000
Received: from [193.109.254.147:46763] by server-6.bemta-14.messagelabs.com id
	27/C5-08993-16DE2EF4; Thu, 21 Jun 2012 09:46:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340271968!3694866!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30152 invoked from network); 21 Jun 2012 09:46:08 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 09:46:08 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035506; Thu, 21 Jun 2012 11:46:07 +0200
Message-ID: <1340271961.4856.3.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 11:46:01 +0200
In-Reply-To: <1340271008.21872.37.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<8ef7de2b4328e4f65982.1339779874@Solace>
	<1340271008.21872.37.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06 of 10 v2] libxl: expand the libxl_bitmap
	API a 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: multipart/mixed; boundary="===============4100000043151327924=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4100000043151327924==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-OBsyJWiwhK4LNXc2PdmY"


--=-OBsyJWiwhK4LNXc2PdmY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:30 +0100, Ian Campbell wrote:
> > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c
> > +++ b/tools/libxl/libxl_utils.c
> > @@ -506,6 +506,35 @@ void libxl_bitmap_dispose(libxl_bitmap *
> >      free(map->map);
> >  }
> > =20
> > +void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
> > +                       const libxl_bitmap *sptr)
> > +{
> > +    int sz;
> > +
> > +    sz =3D dptr->size =3D sptr->size;
> > +    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>=20
> I think you need either some checks/asserts on the two relative sizes or
> a reallocation of the destination map. Otherwise you risk an overflow.
>=20
> Perhaps a simple assert (i.e. make it the callers problem) would be ok?
>=20
Sounds reasonable, will do that.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-OBsyJWiwhK4LNXc2PdmY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i7VkACgkQk4XaBE3IOsQiRQCfRKIzxuzky8VtgJxrmU3wXKWh
mHIAnA1bgwtVPmdUyq+iIR8hsE0HDWIg
=rDap
-----END PGP SIGNATURE-----

--=-OBsyJWiwhK4LNXc2PdmY--



--===============4100000043151327924==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4100000043151327924==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 09:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shdxs-00030O-UA; Thu, 21 Jun 2012 09:46:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Shdxr-000308-De
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:46:11 +0000
Received: from [193.109.254.147:46763] by server-6.bemta-14.messagelabs.com id
	27/C5-08993-16DE2EF4; Thu, 21 Jun 2012 09:46:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340271968!3694866!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30152 invoked from network); 21 Jun 2012 09:46:08 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 09:46:08 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035506; Thu, 21 Jun 2012 11:46:07 +0200
Message-ID: <1340271961.4856.3.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 11:46:01 +0200
In-Reply-To: <1340271008.21872.37.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<8ef7de2b4328e4f65982.1339779874@Solace>
	<1340271008.21872.37.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06 of 10 v2] libxl: expand the libxl_bitmap
	API a 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: multipart/mixed; boundary="===============4100000043151327924=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4100000043151327924==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-OBsyJWiwhK4LNXc2PdmY"


--=-OBsyJWiwhK4LNXc2PdmY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:30 +0100, Ian Campbell wrote:
> > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c
> > +++ b/tools/libxl/libxl_utils.c
> > @@ -506,6 +506,35 @@ void libxl_bitmap_dispose(libxl_bitmap *
> >      free(map->map);
> >  }
> > =20
> > +void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
> > +                       const libxl_bitmap *sptr)
> > +{
> > +    int sz;
> > +
> > +    sz =3D dptr->size =3D sptr->size;
> > +    memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>=20
> I think you need either some checks/asserts on the two relative sizes or
> a reallocation of the destination map. Otherwise you risk an overflow.
>=20
> Perhaps a simple assert (i.e. make it the callers problem) would be ok?
>=20
Sounds reasonable, will do that.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-OBsyJWiwhK4LNXc2PdmY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i7VkACgkQk4XaBE3IOsQiRQCfRKIzxuzky8VtgJxrmU3wXKWh
mHIAnA1bgwtVPmdUyq+iIR8hsE0HDWIg
=rDap
-----END PGP SIGNATURE-----

--=-OBsyJWiwhK4LNXc2PdmY--



--===============4100000043151327924==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4100000043151327924==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 09:50:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:50: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 1She1Z-0003DM-Ip; Thu, 21 Jun 2012 09:50:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1She1Y-0003DE-9y
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:50:00 +0000
Received: from [85.158.143.99:5206] by server-1.bemta-4.messagelabs.com id
	65/F4-24392-64EE2EF4; Thu, 21 Jun 2012 09:49:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340272197!28436298!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 21 Jun 2012 09:49:57 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 09:49:57 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035615; Thu, 21 Jun 2012 11:49:57 +0200
Message-ID: <1340272189.4856.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 11:49:49 +0200
In-Reply-To: <1340269942.21872.26.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<5d3cbf2e6370d1989bcd.1339779873@Solace>
	<1340269942.21872.26.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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: multipart/mixed; boundary="===============2481638585428177731=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2481638585428177731==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+G9pnVtrphDEkdalKZOD"


--=-+G9pnVtrphDEkdalKZOD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:12 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > And leave to the caller the burden of knowing and remembering what kind
> > of bitmap each instance of libxl_bitmap is.
> >=20
> > This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some othe=
r
> > related interface name substitution, e.g., libxl_for_each_cpu) in a bun=
ch
> > of files, with no real functional change involved.
> >=20
> > A specific allocation helper is introduced, besides libxl_bitmap_alloc(=
).
> > It is called libxl_cpu_bitmap_alloc() and is meant at substituting the =
old
> > libxl_cpumap_alloc(). It is just something easier to use in cases where=
 one
> > wants to allocate a libxl_bitmap that is going to serve as a cpu map.
> >=20
> > This is because we want to be able to deal with both cpu and NUMA node
> > maps, but we don't want to duplicate all the various helpers and wrappe=
rs.
>=20
> FWIW I'd have been perfectly happy with a bunch of=20
> 	#define for_each_cpu(mumble) for_each_bit(mumble)
> type stuff, but I think Ian J and yourself didn't like those which I'm
> also fine with.
>=20
Well, I'm fine with both approaches, actually. However, I've been asked
by Ian during last round to kill the duplication as much as I can, and
here it is what I came out with. :-)

That being said, if it's just a matter of adding back a couple of
libxl_for_each_{set_}cpu as a define to libxl_for_each_{set_} bit, I
could well do that, as it looks a "reasonable" amount of wrapper
duplication to me...

> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>
> > diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> > --- a/tools/libxl/libxl_json.c
> > +++ b/tools/libxl/libxl_json.c
> > @@ -99,8 +99,8 @@ yajl_gen_status libxl_uuid_gen_json(yajl
> >      return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUI=
D_FMTLEN);
> >  }
> >=20
> > -yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand,
> > -                                      libxl_cpumap *cpumap)
> > +yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
> > +                                      libxl_bitmap *cpumap)
>=20
> Minor nit: You likely meant to rename cpumap in the argument list too.
>=20
In this case, I sure did, thanks for pointing it out.

> Even with that minor nit:
>=20
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
Good!

I'll fix the nit, as I have to resubmit anyway. :-P

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-+G9pnVtrphDEkdalKZOD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i7j0ACgkQk4XaBE3IOsSnHQCgn6VVrKWi4keM3tdIict+vjk0
ybwAn3yEsiwMQVkjaqX5nnlQ5PKLeIMi
=Mq4G
-----END PGP SIGNATURE-----

--=-+G9pnVtrphDEkdalKZOD--



--===============2481638585428177731==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2481638585428177731==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 09:50:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09:50: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 1She1Z-0003DM-Ip; Thu, 21 Jun 2012 09:50:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1She1Y-0003DE-9y
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:50:00 +0000
Received: from [85.158.143.99:5206] by server-1.bemta-4.messagelabs.com id
	65/F4-24392-64EE2EF4; Thu, 21 Jun 2012 09:49:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340272197!28436298!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 21 Jun 2012 09:49:57 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 09:49:57 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035615; Thu, 21 Jun 2012 11:49:57 +0200
Message-ID: <1340272189.4856.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 11:49:49 +0200
In-Reply-To: <1340269942.21872.26.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<5d3cbf2e6370d1989bcd.1339779873@Solace>
	<1340269942.21872.26.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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: multipart/mixed; boundary="===============2481638585428177731=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2481638585428177731==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+G9pnVtrphDEkdalKZOD"


--=-+G9pnVtrphDEkdalKZOD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:12 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > And leave to the caller the burden of knowing and remembering what kind
> > of bitmap each instance of libxl_bitmap is.
> >=20
> > This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some othe=
r
> > related interface name substitution, e.g., libxl_for_each_cpu) in a bun=
ch
> > of files, with no real functional change involved.
> >=20
> > A specific allocation helper is introduced, besides libxl_bitmap_alloc(=
).
> > It is called libxl_cpu_bitmap_alloc() and is meant at substituting the =
old
> > libxl_cpumap_alloc(). It is just something easier to use in cases where=
 one
> > wants to allocate a libxl_bitmap that is going to serve as a cpu map.
> >=20
> > This is because we want to be able to deal with both cpu and NUMA node
> > maps, but we don't want to duplicate all the various helpers and wrappe=
rs.
>=20
> FWIW I'd have been perfectly happy with a bunch of=20
> 	#define for_each_cpu(mumble) for_each_bit(mumble)
> type stuff, but I think Ian J and yourself didn't like those which I'm
> also fine with.
>=20
Well, I'm fine with both approaches, actually. However, I've been asked
by Ian during last round to kill the duplication as much as I can, and
here it is what I came out with. :-)

That being said, if it's just a matter of adding back a couple of
libxl_for_each_{set_}cpu as a define to libxl_for_each_{set_} bit, I
could well do that, as it looks a "reasonable" amount of wrapper
duplication to me...

> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.eu.com>
> > diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> > --- a/tools/libxl/libxl_json.c
> > +++ b/tools/libxl/libxl_json.c
> > @@ -99,8 +99,8 @@ yajl_gen_status libxl_uuid_gen_json(yajl
> >      return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUI=
D_FMTLEN);
> >  }
> >=20
> > -yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand,
> > -                                      libxl_cpumap *cpumap)
> > +yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand,
> > +                                      libxl_bitmap *cpumap)
>=20
> Minor nit: You likely meant to rename cpumap in the argument list too.
>=20
In this case, I sure did, thanks for pointing it out.

> Even with that minor nit:
>=20
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
Good!

I'll fix the nit, as I have to resubmit anyway. :-P

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-+G9pnVtrphDEkdalKZOD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i7j0ACgkQk4XaBE3IOsSnHQCgn6VVrKWi4keM3tdIict+vjk0
ybwAn3yEsiwMQVkjaqX5nnlQ5PKLeIMi
=Mq4G
-----END PGP SIGNATURE-----

--=-+G9pnVtrphDEkdalKZOD--



--===============2481638585428177731==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2481638585428177731==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 09:54:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1She5e-0003Op-7t; Thu, 21 Jun 2012 09:54: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 1She5d-0003Of-Fz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:54:13 +0000
Received: from [85.158.139.83:24900] by server-5.bemta-5.messagelabs.com id
	21/B9-02722-44FE2EF4; Thu, 21 Jun 2012 09:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340272451!24834777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19460 invoked from network); 21 Jun 2012 09:54:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:54:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13142349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:53:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:53:43 +0100
Message-ID: <1340272422.21872.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:53:42 +0100
In-Reply-To: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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

On Wed, 2012-06-20 at 18:09 +0100, Dario Faggioli wrote:
> 9d1fd58ff602 was bogous in not letting a new domain being created
> if its scheduling parameters --when running under the sedf scheduler--
> were not fully specified, making creation fail like in this example
> here below:
> 
> 2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg
> libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument
> libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3
> Parsing config from /etc/xen/debian.guest.osstest.cfg
> 
> This is due to the fact the values for period, slice, weight and
> extratime should be consistent among each others, and if not all
> are explicitly specified, someone has to make that happen. That
> was right the purpose of the change in question, but it was failing
> at achieving so.
> 
> This commit fixes things by forcing unspecified parameters to
> sensible values, depending on the ones the user provided.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citix.com>

Thanks for this. I'd like to get it in ASAP so we can start passing
tests again. I have a few queries though unfortunately...

(most of the comments below are just me thinking aloud following the
logic, because it's pretty subtle...)

> 
> 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
> @@ -555,6 +555,8 @@ static int sched_params_valid(libxl_doma
>      int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
>      int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
>      int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
> +    int has_extratime =
> +                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
>      libxl_domain_sched_params sci;
>  
>      libxl_domain_sched_params_get(ctx, domid, &sci);
> @@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
>      if (sci.sched == LIBXL_SCHEDULER_SEDF) {
>          if (has_weight && (has_period || has_slice))
>              return 0;
> -
> +        if (has_period != has_slice)
> +            return 0;

OK, so if you give period you _must_ give slice too, there is no
default?

> +
> +        /*
> +         * Idea is, if we specify a weight, then both period and
> +         * slice has to be zero. OTOH, if we do not specify a weight,
> +         * that means we want a pure best effort domain or an actual
> +         * real-time one. In the former case, it is period that needs
> +         * to be zero, in the latter, weight should be.
> +         */

I suspect there is a doc somewhere of which combinations of values are
valid and what they mean etc -- perhaps we could link to it here?

It's docs/misc/sedf_scheduler_mini-HOWTO.txt I suppose?

>          if (has_weight) {
>              scp->slice = 0;
>              scp->period = 0;
>          }

If we have a weight then we've already checked that we don't has_period
or has_slice so force them to zero. Makes sense.

> -        if (has_period || has_slice)
> +        else if (!has_period) {

So here we don't have weight or period. We also know we don't have a
slice either because we checked that we either have or don't have both
of slice and period.

> +            /* We can setup a proper best effort domain (extra time only)
> +             * iff we either already have or are asking for some extra time. */
> +            scp->weight = has_extratime ? scp->extratime : sci.extratime;

weight = extratime?

If I understand correctly then weight is an integer and extratime is a
bool, which just seems wrong. Or is this subtly relying on the fact that
True == 1 and therefore we set the weight to either 1 or 0?

If so then adding some !! on the bools would ensure that you really have
0 or 1 and not some other True value. Also expanding the comment to say
that iff we have extratime then weight == 1 would make this clearer.

> +            scp->period = 0;
> +        }
> +        if (has_period && has_slice)

is this also the same as "else if (has_period && has_slice)", which
since we know has_period == has_slice is "else if (has_period")" which,
given the previous "else if (!has_period)" is just "else" (plus a
comment ;-))

>              scp->weight = 0;
>      }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:54:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1She5e-0003Op-7t; Thu, 21 Jun 2012 09:54: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 1She5d-0003Of-Fz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 09:54:13 +0000
Received: from [85.158.139.83:24900] by server-5.bemta-5.messagelabs.com id
	21/B9-02722-44FE2EF4; Thu, 21 Jun 2012 09:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340272451!24834777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19460 invoked from network); 21 Jun 2012 09:54:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 09:54:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13142349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:53:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 10:53:43 +0100
Message-ID: <1340272422.21872.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 10:53:42 +0100
In-Reply-To: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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

On Wed, 2012-06-20 at 18:09 +0100, Dario Faggioli wrote:
> 9d1fd58ff602 was bogous in not letting a new domain being created
> if its scheduling parameters --when running under the sedf scheduler--
> were not fully specified, making creation fail like in this example
> here below:
> 
> 2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg
> libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument
> libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3
> Parsing config from /etc/xen/debian.guest.osstest.cfg
> 
> This is due to the fact the values for period, slice, weight and
> extratime should be consistent among each others, and if not all
> are explicitly specified, someone has to make that happen. That
> was right the purpose of the change in question, but it was failing
> at achieving so.
> 
> This commit fixes things by forcing unspecified parameters to
> sensible values, depending on the ones the user provided.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citix.com>

Thanks for this. I'd like to get it in ASAP so we can start passing
tests again. I have a few queries though unfortunately...

(most of the comments below are just me thinking aloud following the
logic, because it's pretty subtle...)

> 
> 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
> @@ -555,6 +555,8 @@ static int sched_params_valid(libxl_doma
>      int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
>      int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
>      int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
> +    int has_extratime =
> +                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
>      libxl_domain_sched_params sci;
>  
>      libxl_domain_sched_params_get(ctx, domid, &sci);
> @@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
>      if (sci.sched == LIBXL_SCHEDULER_SEDF) {
>          if (has_weight && (has_period || has_slice))
>              return 0;
> -
> +        if (has_period != has_slice)
> +            return 0;

OK, so if you give period you _must_ give slice too, there is no
default?

> +
> +        /*
> +         * Idea is, if we specify a weight, then both period and
> +         * slice has to be zero. OTOH, if we do not specify a weight,
> +         * that means we want a pure best effort domain or an actual
> +         * real-time one. In the former case, it is period that needs
> +         * to be zero, in the latter, weight should be.
> +         */

I suspect there is a doc somewhere of which combinations of values are
valid and what they mean etc -- perhaps we could link to it here?

It's docs/misc/sedf_scheduler_mini-HOWTO.txt I suppose?

>          if (has_weight) {
>              scp->slice = 0;
>              scp->period = 0;
>          }

If we have a weight then we've already checked that we don't has_period
or has_slice so force them to zero. Makes sense.

> -        if (has_period || has_slice)
> +        else if (!has_period) {

So here we don't have weight or period. We also know we don't have a
slice either because we checked that we either have or don't have both
of slice and period.

> +            /* We can setup a proper best effort domain (extra time only)
> +             * iff we either already have or are asking for some extra time. */
> +            scp->weight = has_extratime ? scp->extratime : sci.extratime;

weight = extratime?

If I understand correctly then weight is an integer and extratime is a
bool, which just seems wrong. Or is this subtly relying on the fact that
True == 1 and therefore we set the weight to either 1 or 0?

If so then adding some !! on the bools would ensure that you really have
0 or 1 and not some other True value. Also expanding the comment to say
that iff we have extratime then weight == 1 would make this clearer.

> +            scp->period = 0;
> +        }
> +        if (has_period && has_slice)

is this also the same as "else if (has_period && has_slice)", which
since we know has_period == has_slice is "else if (has_period")" which,
given the previous "else if (!has_period)" is just "else" (plus a
comment ;-))

>              scp->weight = 0;
>      }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:59:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1SheAV-0003aU-4Q; Thu, 21 Jun 2012 09:59:15 +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 1SheAT-0003aP-IP
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 09:59:13 +0000
Received: from [193.109.254.147:28100] by server-7.bemta-14.messagelabs.com id
	CC/B2-29827-070F2EF4; Thu, 21 Jun 2012 09:59:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340272752!10002530!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2187 invoked from network); 21 Jun 2012 09:59:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 09:59:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 10:59:11 +0100
Message-Id: <4FE30CBB020000780008B06B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 10:59:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>,
	"Jesse Barnes" <jbarnes@virtuousgeek.org>,<ebiederm@xmission.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
In-Reply-To: <4FDA0028.3090609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
 dom0 (was: Re: [PATCH V2] amd iommu: re-enable iommu msi if dom0 disabled
 it)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
> Am 14.06.2012 16:18, schrieb Jan Beulich:
>> Have you at all considered getting this fixed on the kernel side?
>> As I don't have direct access to any AMD IOMMU capable
>> system - can one, other than by enumerating the respective
>> PCI IDs or reading ACPI tables, reasonably easily identify the
>> devices in question (e.g. via vendor/class/sub-class or some
>> such)? That might permit skipping those in the offending kernel
>> code...
> 
> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
> should be enough to identify amd iommu device. I could send you a kernel 
> patch for review using this approach. I would believe that fixing this 
> issue in 4.2, no matter how, is really important for amd iommu.

As you didn't come forward with anything, here's my first
take on this:

Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
interrupts when we initialize a pci device") caused MSI to get disabled
on Xen Dom0 despite it having got turned on purposefully by the
hypervisor. As an immediate band aid, suppress the disabling in this
specific case.

I don't think, however, that either the original change or this fix are
really appropriate. The original fix, besides leaving aside the
presence of a hypervisor like Xen, doesn't deal with all possible
cases (in particular it has no effect if the secondary kernel was built
with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
Xen, the logic like this should probably be skipped altogether (i.e. it
should be entirely left to the hypervisor, being the entity in control
of IRQs).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@kernel.org 

---
 drivers/pci/msi.c       |    7 +++++++
 include/linux/pci_ids.h |    1 +
 2 files changed, 8 insertions(+)

--- 3.5-rc3/drivers/pci/msi.c
+++ 3.5-rc3-xen-pci-msi-no-iommu-disable/drivers/pci/msi.c
@@ -20,6 +20,7 @@
 #include <linux/errno.h>
 #include <linux/io.h>
 #include <linux/slab.h>
+#include <xen/xen.h>
 
 #include "pci.h"
 #include "msi.h"
@@ -1022,7 +1023,13 @@ void pci_msi_init_pci_dev(struct pci_dev
 	/* Disable the msi hardware to avoid screaming interrupts
 	 * during boot.  This is the power on reset default so
 	 * usually this should be a noop.
+	 * But on a Xen host don't do this for IOMMUs which the hypervisor
+	 * is in control of (and hence has already enabled on purpose).
 	 */
+	if (xen_initial_domain()
+	    && (dev->class >> 8) == PCI_CLASS_SYSTEM_IOMMU
+	    && dev->vendor == PCI_VENDOR_ID_AMD)
+		return;
 	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
 	if (pos)
 		msi_set_enable(dev, pos, 0);
--- 3.5-rc3/include/linux/pci_ids.h
+++ 3.5-rc3-xen-pci-msi-no-iommu-disable/include/linux/pci_ids.h
@@ -75,6 +75,7 @@
 #define PCI_CLASS_SYSTEM_RTC		0x0803
 #define PCI_CLASS_SYSTEM_PCI_HOTPLUG	0x0804
 #define PCI_CLASS_SYSTEM_SDHCI		0x0805
+#define PCI_CLASS_SYSTEM_IOMMU		0x0806
 #define PCI_CLASS_SYSTEM_OTHER		0x0880
 
 #define PCI_BASE_CLASS_INPUT		0x09




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 09:59:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 09: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 1SheAV-0003aU-4Q; Thu, 21 Jun 2012 09:59:15 +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 1SheAT-0003aP-IP
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 09:59:13 +0000
Received: from [193.109.254.147:28100] by server-7.bemta-14.messagelabs.com id
	CC/B2-29827-070F2EF4; Thu, 21 Jun 2012 09:59:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340272752!10002530!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2187 invoked from network); 21 Jun 2012 09:59:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 09:59:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 10:59:11 +0100
Message-Id: <4FE30CBB020000780008B06B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 10:59:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>,
	"Jesse Barnes" <jbarnes@virtuousgeek.org>,<ebiederm@xmission.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
In-Reply-To: <4FDA0028.3090609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
 dom0 (was: Re: [PATCH V2] amd iommu: re-enable iommu msi if dom0 disabled
 it)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
> Am 14.06.2012 16:18, schrieb Jan Beulich:
>> Have you at all considered getting this fixed on the kernel side?
>> As I don't have direct access to any AMD IOMMU capable
>> system - can one, other than by enumerating the respective
>> PCI IDs or reading ACPI tables, reasonably easily identify the
>> devices in question (e.g. via vendor/class/sub-class or some
>> such)? That might permit skipping those in the offending kernel
>> code...
> 
> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
> should be enough to identify amd iommu device. I could send you a kernel 
> patch for review using this approach. I would believe that fixing this 
> issue in 4.2, no matter how, is really important for amd iommu.

As you didn't come forward with anything, here's my first
take on this:

Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
interrupts when we initialize a pci device") caused MSI to get disabled
on Xen Dom0 despite it having got turned on purposefully by the
hypervisor. As an immediate band aid, suppress the disabling in this
specific case.

I don't think, however, that either the original change or this fix are
really appropriate. The original fix, besides leaving aside the
presence of a hypervisor like Xen, doesn't deal with all possible
cases (in particular it has no effect if the secondary kernel was built
with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
Xen, the logic like this should probably be skipped altogether (i.e. it
should be entirely left to the hypervisor, being the entity in control
of IRQs).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@kernel.org 

---
 drivers/pci/msi.c       |    7 +++++++
 include/linux/pci_ids.h |    1 +
 2 files changed, 8 insertions(+)

--- 3.5-rc3/drivers/pci/msi.c
+++ 3.5-rc3-xen-pci-msi-no-iommu-disable/drivers/pci/msi.c
@@ -20,6 +20,7 @@
 #include <linux/errno.h>
 #include <linux/io.h>
 #include <linux/slab.h>
+#include <xen/xen.h>
 
 #include "pci.h"
 #include "msi.h"
@@ -1022,7 +1023,13 @@ void pci_msi_init_pci_dev(struct pci_dev
 	/* Disable the msi hardware to avoid screaming interrupts
 	 * during boot.  This is the power on reset default so
 	 * usually this should be a noop.
+	 * But on a Xen host don't do this for IOMMUs which the hypervisor
+	 * is in control of (and hence has already enabled on purpose).
 	 */
+	if (xen_initial_domain()
+	    && (dev->class >> 8) == PCI_CLASS_SYSTEM_IOMMU
+	    && dev->vendor == PCI_VENDOR_ID_AMD)
+		return;
 	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
 	if (pos)
 		msi_set_enable(dev, pos, 0);
--- 3.5-rc3/include/linux/pci_ids.h
+++ 3.5-rc3-xen-pci-msi-no-iommu-disable/include/linux/pci_ids.h
@@ -75,6 +75,7 @@
 #define PCI_CLASS_SYSTEM_RTC		0x0803
 #define PCI_CLASS_SYSTEM_PCI_HOTPLUG	0x0804
 #define PCI_CLASS_SYSTEM_SDHCI		0x0805
+#define PCI_CLASS_SYSTEM_IOMMU		0x0806
 #define PCI_CLASS_SYSTEM_OTHER		0x0880
 
 #define PCI_BASE_CLASS_INPUT		0x09




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:00:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:00: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 1SheBb-0003ir-Ik; Thu, 21 Jun 2012 10:00:23 +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 1SheBZ-0003ii-TH
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:00:22 +0000
Received: from [193.109.254.147:46398] by server-6.bemta-14.messagelabs.com id
	3C/56-08993-5B0F2EF4; Thu, 21 Jun 2012 10:00:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340272817!8446496!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23847 invoked from network); 21 Jun 2012 10:00:17 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:00:17 -0000
Received: by eaak12 with SMTP id k12so143972eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 03:00:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=ST5u9hhiRZyaI/N1ewU5UwDI1UB4JQtBrt9KijrYYcM=;
	b=DEBZuGHJIcx5+1XD/vq9ZuWVSCUEmAtlhslF0jqkzMjtekNZXmtwSfPPQtfpASFK91
	xCXy+O3STsDdx4q0QdxGdF4A62/4c2LPJVWQcU9qWu9IwZOSq1+AMz/pFrQ40OPcQe0f
	KOLrFHN+/vjJHvDAnIuhp7Z8d2tOBsd7uU1UvzWw9YhePN/fQvXUS3bqayuT+3275tSR
	dobJZxcsuX3tldlIztjhfmf/OXlmpTgXCLe49kwihvNHtgzi6T/Qub+1cj+BMCrbsxtw
	Wb9K/mdtUrjE9wKTH3gffD+XDRSXje2NJM57TQHMqmzbshmaa0PaQ2PenmNdxNdr6QWd
	y2IQ==
Received: by 10.14.98.136 with SMTP id v8mr5794292eef.145.1340272817032;
	Thu, 21 Jun 2012 03:00:17 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id z5sm101095669eem.3.2012.06.21.03.00.15
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 03:00:16 -0700 (PDT)
Message-ID: <4FE2F0AE.9050901@xen.org>
Date: Thu, 21 Jun 2012 11:00:14 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [Minutes] Xen Maintainer,
 Committer and Developer Meeting - Minutes June 2012
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

Published at:
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/June_2012_Minutes 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:00:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:00: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 1SheBb-0003ir-Ik; Thu, 21 Jun 2012 10:00:23 +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 1SheBZ-0003ii-TH
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:00:22 +0000
Received: from [193.109.254.147:46398] by server-6.bemta-14.messagelabs.com id
	3C/56-08993-5B0F2EF4; Thu, 21 Jun 2012 10:00:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340272817!8446496!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23847 invoked from network); 21 Jun 2012 10:00:17 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:00:17 -0000
Received: by eaak12 with SMTP id k12so143972eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 03:00:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=ST5u9hhiRZyaI/N1ewU5UwDI1UB4JQtBrt9KijrYYcM=;
	b=DEBZuGHJIcx5+1XD/vq9ZuWVSCUEmAtlhslF0jqkzMjtekNZXmtwSfPPQtfpASFK91
	xCXy+O3STsDdx4q0QdxGdF4A62/4c2LPJVWQcU9qWu9IwZOSq1+AMz/pFrQ40OPcQe0f
	KOLrFHN+/vjJHvDAnIuhp7Z8d2tOBsd7uU1UvzWw9YhePN/fQvXUS3bqayuT+3275tSR
	dobJZxcsuX3tldlIztjhfmf/OXlmpTgXCLe49kwihvNHtgzi6T/Qub+1cj+BMCrbsxtw
	Wb9K/mdtUrjE9wKTH3gffD+XDRSXje2NJM57TQHMqmzbshmaa0PaQ2PenmNdxNdr6QWd
	y2IQ==
Received: by 10.14.98.136 with SMTP id v8mr5794292eef.145.1340272817032;
	Thu, 21 Jun 2012 03:00:17 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id z5sm101095669eem.3.2012.06.21.03.00.15
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 03:00:16 -0700 (PDT)
Message-ID: <4FE2F0AE.9050901@xen.org>
Date: Thu, 21 Jun 2012 11:00:14 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [Minutes] Xen Maintainer,
 Committer and Developer Meeting - Minutes June 2012
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

Published at:
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/June_2012_Minutes 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:00:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10: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 1SheBl-0003jo-Uq; Thu, 21 Jun 2012 10:00:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SheBl-0003jg-CM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:00:33 +0000
Received: from [85.158.143.35:52552] by server-3.bemta-4.messagelabs.com id
	FF/23-05808-0C0F2EF4; Thu, 21 Jun 2012 10:00:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340272821!10231946!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29265 invoked from network); 21 Jun 2012 10:00:21 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 10:00:21 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035897; Thu, 21 Jun 2012 12:00:20 +0200
Message-ID: <1340272814.4856.16.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 12:00:14 +0200
In-Reply-To: <1340269342.21872.20.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<16222d05875389899968.1339779871@Solace>
	<1340269342.21872.20.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1194041570605301455=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1194041570605301455==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-nR4dY8gfBHS4Qc8CBOA8"


--=-nR4dY8gfBHS4Qc8CBOA8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:02 +0100, Ian Campbell wrote:
> > diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> > --- a/tools/libxc/xenctrl.h
> > +++ b/tools/libxc/xenctrl.h
> ...
> > +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
> > +{
> [...]
>=20
> The hypercall buffer stuff all looks good.
>=20
> > +    if (ret)
> > +        *nr =3D max_nodes;
>=20
> You could put this before the fail: label. Not that it matters.
>=20
Ok.

> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> ...
> >  #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
> >  libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
> >  void libxl_cputopology_list_free(libxl_cputopology *, int nr);
> > +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
> > +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
> > +  /* On success, a list of nr libxl_numainfo elements is returned.
> > +   * That is from malloc, thus it is up to the caller to invoke
> > +   * libxl_cpupoolinfo_list_free() on it.
>=20
> Don't you mean libxl_numinfo_list_free() ?
>=20
> Also normally we put the comment before the prototype.
>=20
Yes, I did, and will fix it. For the comment, again, I'll move that
up... It's just you can find so much different "examples" in those
files... :-O

> > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c
> > +++ b/tools/libxl/libxl_utils.c
> > @@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
> >      return xc_get_max_cpus(ctx->xch);
> >  }
> > =20
> > +int libxl_get_max_nodes(libxl_ctx *ctx)
> > +{
> > +    return xc_get_max_nodes(ctx->xch);
> > +}
>=20
> Is this needed externally to libxl or do we expect all callers to use
> libxl_get_numainfo? I suppose there is no harm in exporting this either
> way.
>=20
I'm not sure. What I did is to replicate what happens for
libxl_get_max_cpus(), but I really don't know whether or not they both
make any sense outside libxl. It does not look that bad to me that we
offer our users a chance to figure out how many cpus and/or nodes they
have, without needing to call the proper libxl_get_*info(), which is
quite a bit more of a burden. FWIW, I'd leave both of them public.


> > 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
> > @@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
> >  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
> > =20
> >  /* XEN_SYSCTL_numainfo */
> > +#define INVALID_NUMAINFO_ID (~0U)
>=20
> It feels like there ought to be hunks in the hypervisor which either use
> this symbol instead of a hardcoded ~0U or which remove the internal
> definition in favour of this one?
>=20
Again, -topologyinfo machinery does exactly this, so I really think we
either fix/change or leave as they are both of them (which of course I
can do, just tell me if that is what you want).

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-nR4dY8gfBHS4Qc8CBOA8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i8K4ACgkQk4XaBE3IOsRyjgCgjTxRDM4Y7MyA5KoPDkDrZwDz
eVgAn0LXquY5ny8k0AtoJdndnbq6q2bV
=EOOP
-----END PGP SIGNATURE-----

--=-nR4dY8gfBHS4Qc8CBOA8--



--===============1194041570605301455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1194041570605301455==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 10:00:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10: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 1SheBl-0003jo-Uq; Thu, 21 Jun 2012 10:00:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SheBl-0003jg-CM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:00:33 +0000
Received: from [85.158.143.35:52552] by server-3.bemta-4.messagelabs.com id
	FF/23-05808-0C0F2EF4; Thu, 21 Jun 2012 10:00:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340272821!10231946!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29265 invoked from network); 21 Jun 2012 10:00:21 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 10:00:21 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79035897; Thu, 21 Jun 2012 12:00:20 +0200
Message-ID: <1340272814.4856.16.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 12:00:14 +0200
In-Reply-To: <1340269342.21872.20.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<16222d05875389899968.1339779871@Solace>
	<1340269342.21872.20.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1194041570605301455=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1194041570605301455==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-nR4dY8gfBHS4Qc8CBOA8"


--=-nR4dY8gfBHS4Qc8CBOA8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:02 +0100, Ian Campbell wrote:
> > diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> > --- a/tools/libxc/xenctrl.h
> > +++ b/tools/libxc/xenctrl.h
> ...
> > +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
> > +{
> [...]
>=20
> The hypercall buffer stuff all looks good.
>=20
> > +    if (ret)
> > +        *nr =3D max_nodes;
>=20
> You could put this before the fail: label. Not that it matters.
>=20
Ok.

> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> ...
> >  #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
> >  libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
> >  void libxl_cputopology_list_free(libxl_cputopology *, int nr);
> > +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
> > +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
> > +  /* On success, a list of nr libxl_numainfo elements is returned.
> > +   * That is from malloc, thus it is up to the caller to invoke
> > +   * libxl_cpupoolinfo_list_free() on it.
>=20
> Don't you mean libxl_numinfo_list_free() ?
>=20
> Also normally we put the comment before the prototype.
>=20
Yes, I did, and will fix it. For the comment, again, I'll move that
up... It's just you can find so much different "examples" in those
files... :-O

> > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c
> > +++ b/tools/libxl/libxl_utils.c
> > @@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
> >      return xc_get_max_cpus(ctx->xch);
> >  }
> > =20
> > +int libxl_get_max_nodes(libxl_ctx *ctx)
> > +{
> > +    return xc_get_max_nodes(ctx->xch);
> > +}
>=20
> Is this needed externally to libxl or do we expect all callers to use
> libxl_get_numainfo? I suppose there is no harm in exporting this either
> way.
>=20
I'm not sure. What I did is to replicate what happens for
libxl_get_max_cpus(), but I really don't know whether or not they both
make any sense outside libxl. It does not look that bad to me that we
offer our users a chance to figure out how many cpus and/or nodes they
have, without needing to call the proper libxl_get_*info(), which is
quite a bit more of a burden. FWIW, I'd leave both of them public.


> > 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
> > @@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
> >  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
> > =20
> >  /* XEN_SYSCTL_numainfo */
> > +#define INVALID_NUMAINFO_ID (~0U)
>=20
> It feels like there ought to be hunks in the hypervisor which either use
> this symbol instead of a hardcoded ~0U or which remove the internal
> definition in favour of this one?
>=20
Again, -topologyinfo machinery does exactly this, so I really think we
either fix/change or leave as they are both of them (which of course I
can do, just tell me if that is what you want).

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-nR4dY8gfBHS4Qc8CBOA8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i8K4ACgkQk4XaBE3IOsRyjgCgjTxRDM4Y7MyA5KoPDkDrZwDz
eVgAn0LXquY5ny8k0AtoJdndnbq6q2bV
=EOOP
-----END PGP SIGNATURE-----

--=-nR4dY8gfBHS4Qc8CBOA8--



--===============1194041570605301455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1194041570605301455==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 10:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:19: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 1SheTU-0004Bm-LD; Thu, 21 Jun 2012 10:18:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SheTT-0004Bh-RT
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:18:52 +0000
Received: from [85.158.139.83:55109] by server-11.bemta-5.messagelabs.com id
	14/A0-20400-B05F2EF4; Thu, 21 Jun 2012 10:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340273930!23648169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18429 invoked from network); 21 Jun 2012 10:18:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10: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.213.0;
	Thu, 21 Jun 2012 11:18:50 +0100
Message-ID: <1340273928.21872.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 21 Jun 2012 11:18:48 +0100
In-Reply-To: <4FE2EBD9.4040101@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
	<4FE2EBD9.4040101@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 10:39 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Thu, 2012-06-21 at 10:09 +0100, Roger Pau Monne wrote:
> >> Ian Campbell wrote:
> >>> On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
> >>>> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
> >>>>
> >>>>> If this little trick applies to both NetBSD and uclibc too then I guess
> >>>>> it would be OK, otherwise I think autoconf is necessary.
> >>>> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
> >>>> makefile unilaterally sets USE_PTHREAD for example.
> >>> It has autoconf stuff available to it, I think, it just hasn't had cause
> >>> to use it yet...
> >>>
> >>> (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
> >>> library/cmdline tools and is for building against libc's which don't
> >>> have pthreads)
> >>>
> >>>> Shall I just drop this test for now and if/when xenstore is updated to use
> >>>> autoconf it can be addressed then?
> >>> I'd like to here from Roger about what this means for NetBSD and uclibc,
> >>> if it works on those then I think it is fine to do this.
> >> Sorry for the delay, I just received this today (don't know why).
> >
> > It seemed to have been stuck in my outbox, I thought it was another
> > unrelated mail (which I sent this morning) so I hit go.
> >
> > BTW, I think this patch went in already...
> >
> >>   I've
> >> been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.
> >>
> >> What I don't really like is the hardcoded (16 * 1024) value, how do you
> >> know this is greater than PTHREAD_STACK_MIN?
> >
> > pthread_attr_setstacksize(1) specifically says that PTHREAD_STACK_MIN is
> > 16K, but I don't know if that is a real specified thing or just Linux
> > bias in the manpage.
> 
> PTHREAD_STACK_MIN it's also present on NetBSD and uClibc, so I guess we 
> should use PTHREAD_STACK_MIN (or PTHREAD_STACK_MIN * 2) if the default 
> stack size has to be changed to some sensible value (which I still don't 
> think it has to). Can we guarantee PTHREAD_STACK_MIN is not going to 
> change to something greater than 16k thus breaking this patch?

Using PTHREAD_STACK_MIN sounds like a good idea, since this patch is in
can you send an incremental update? You could do max(PTHREAD_STACK_MIN,
16*1204) perhaps?

> > http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html doesn't seem to say anything about the value of PTHREAD_STACK_MIN.
> >
> > How about we fix this when we come across a system which has a smaller
> > minimum stack?
> >
> >> Frankly I don't understand why do we have to touch this, even if you
> >> requested 256MB of stack it won't we allocated until you get a page
> >> fault, so you are only using the physical memory you need.
> >
> > With 256M stack 4 threads would take up 1G of your virtual address space
> > (regardless of whether it is populated or not), and 12 threads would
> > take up 3G -- which is the whole virtual address space of a 32 bit
> > process, which is rather limiting.
> 
> This should be set by the OS to a sensible value that allows creating a 
> reasonable number of threads, given that the default in Linux is 8MB, it 
> will allow you to create 375 threads on a 32bit system, which looks like 
> a pretty high number to me.

It won't be that high in practice, due to all the other users of virtual
memory as well as fragmentation (i.e. libraries get loaded all over the
place and perhaps don't leave large contiguous chunks etc).

>  Anyway limiting the stack size of a single 
> thread won't make much of difference regarding this, because all the 
> other threads will still take the default value.

I don't recall if I was the original author of this patch or if I was
just involved at the time but this limit really did get hit on
XenServer. IIRC care is taken in whichever process it was to reduce all
the threads to reasonable stack sizes. Its only polite that libxenstore
as a library minimises it's stack usage in order that users of the
library can in turn minimise it's own footprint.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:19: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 1SheTU-0004Bm-LD; Thu, 21 Jun 2012 10:18:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SheTT-0004Bh-RT
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:18:52 +0000
Received: from [85.158.139.83:55109] by server-11.bemta-5.messagelabs.com id
	14/A0-20400-B05F2EF4; Thu, 21 Jun 2012 10:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340273930!23648169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18429 invoked from network); 21 Jun 2012 10:18:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10: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.213.0;
	Thu, 21 Jun 2012 11:18:50 +0100
Message-ID: <1340273928.21872.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 21 Jun 2012 11:18:48 +0100
In-Reply-To: <4FE2EBD9.4040101@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
	<4FE2EBD9.4040101@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 10:39 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Thu, 2012-06-21 at 10:09 +0100, Roger Pau Monne wrote:
> >> Ian Campbell wrote:
> >>> On Wed, 2012-05-30 at 13:10 +0100, Simon Rowe wrote:
> >>>> On Wednesday 30 May 2012 10:40:15 Ian Campbell wrote:
> >>>>
> >>>>> If this little trick applies to both NetBSD and uclibc too then I guess
> >>>>> it would be OK, otherwise I think autoconf is necessary.
> >>>> It doesn't look to my untrained eye that xenstore is autoconf-aware. The
> >>>> makefile unilaterally sets USE_PTHREAD for example.
> >>> It has autoconf stuff available to it, I think, it just hasn't had cause
> >>> to use it yet...
> >>>
> >>> (USE_PTHREAD is a bit of an odd one anyway, it refers only to the client
> >>> library/cmdline tools and is for building against libc's which don't
> >>> have pthreads)
> >>>
> >>>> Shall I just drop this test for now and if/when xenstore is updated to use
> >>>> autoconf it can be addressed then?
> >>> I'd like to here from Roger about what this means for NetBSD and uclibc,
> >>> if it works on those then I think it is fine to do this.
> >> Sorry for the delay, I just received this today (don't know why).
> >
> > It seemed to have been stuck in my outbox, I thought it was another
> > unrelated mail (which I sent this morning) so I hit go.
> >
> > BTW, I think this patch went in already...
> >
> >>   I've
> >> been looking at NetBSD and uClibc, and both have pthread_attr_setstacksize.
> >>
> >> What I don't really like is the hardcoded (16 * 1024) value, how do you
> >> know this is greater than PTHREAD_STACK_MIN?
> >
> > pthread_attr_setstacksize(1) specifically says that PTHREAD_STACK_MIN is
> > 16K, but I don't know if that is a real specified thing or just Linux
> > bias in the manpage.
> 
> PTHREAD_STACK_MIN it's also present on NetBSD and uClibc, so I guess we 
> should use PTHREAD_STACK_MIN (or PTHREAD_STACK_MIN * 2) if the default 
> stack size has to be changed to some sensible value (which I still don't 
> think it has to). Can we guarantee PTHREAD_STACK_MIN is not going to 
> change to something greater than 16k thus breaking this patch?

Using PTHREAD_STACK_MIN sounds like a good idea, since this patch is in
can you send an incremental update? You could do max(PTHREAD_STACK_MIN,
16*1204) perhaps?

> > http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html doesn't seem to say anything about the value of PTHREAD_STACK_MIN.
> >
> > How about we fix this when we come across a system which has a smaller
> > minimum stack?
> >
> >> Frankly I don't understand why do we have to touch this, even if you
> >> requested 256MB of stack it won't we allocated until you get a page
> >> fault, so you are only using the physical memory you need.
> >
> > With 256M stack 4 threads would take up 1G of your virtual address space
> > (regardless of whether it is populated or not), and 12 threads would
> > take up 3G -- which is the whole virtual address space of a 32 bit
> > process, which is rather limiting.
> 
> This should be set by the OS to a sensible value that allows creating a 
> reasonable number of threads, given that the default in Linux is 8MB, it 
> will allow you to create 375 threads on a 32bit system, which looks like 
> a pretty high number to me.

It won't be that high in practice, due to all the other users of virtual
memory as well as fragmentation (i.e. libraries get loaded all over the
place and perhaps don't leave large contiguous chunks etc).

>  Anyway limiting the stack size of a single 
> thread won't make much of difference regarding this, because all the 
> other threads will still take the default value.

I don't recall if I was the original author of this patch or if I was
just involved at the time but this limit really did get hit on
XenServer. IIRC care is taken in whichever process it was to reduce all
the threads to reasonable stack sizes. Its only polite that libxenstore
as a library minimises it's stack usage in order that users of the
library can in turn minimise it's own footprint.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:21:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:21: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 1SheVs-0004IF-71; Thu, 21 Jun 2012 10:21: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 1SheVr-0004I5-2g
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:21:19 +0000
Received: from [193.109.254.147:2661] by server-6.bemta-14.messagelabs.com id
	F2/CF-08993-D95F2EF4; Thu, 21 Jun 2012 10:21:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340274075!10821274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29511 invoked from network); 21 Jun 2012 10:21:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:21:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:21:12 +0100
Message-ID: <1340274071.21872.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 11:21:11 +0100
In-Reply-To: <1340272814.4856.16.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<16222d05875389899968.1339779871@Solace>
	<1340269342.21872.20.camel@zakaz.uk.xensource.com>
	<1340272814.4856.16.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> > > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > > --- a/tools/libxl/libxl_utils.c
> > > +++ b/tools/libxl/libxl_utils.c
> > > @@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
> > >      return xc_get_max_cpus(ctx->xch);
> > >  }
> > >  
> > > +int libxl_get_max_nodes(libxl_ctx *ctx)
> > > +{
> > > +    return xc_get_max_nodes(ctx->xch);
> > > +}
> > 
> > Is this needed externally to libxl or do we expect all callers to use
> > libxl_get_numainfo? I suppose there is no harm in exporting this either
> > way.
> > 
> I'm not sure. What I did is to replicate what happens for
> libxl_get_max_cpus(), but I really don't know whether or not they both
> make any sense outside libxl. It does not look that bad to me that we
> offer our users a chance to figure out how many cpus and/or nodes they
> have, without needing to call the proper libxl_get_*info(), which is
> quite a bit more of a burden. FWIW, I'd leave both of them public.

OK.

> > > 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
> > > @@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
> > >  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
> > >  
> > >  /* XEN_SYSCTL_numainfo */
> > > +#define INVALID_NUMAINFO_ID (~0U)
> > 
> > It feels like there ought to be hunks in the hypervisor which either use
> > this symbol instead of a hardcoded ~0U or which remove the internal
> > definition in favour of this one?
> > 
> Again, -topologyinfo machinery does exactly this, so I really think we
> either fix/change or leave as they are both of them (which of course I
> can do, just tell me if that is what you want).

Lets leave it as is then.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:21:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:21: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 1SheVs-0004IF-71; Thu, 21 Jun 2012 10:21: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 1SheVr-0004I5-2g
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:21:19 +0000
Received: from [193.109.254.147:2661] by server-6.bemta-14.messagelabs.com id
	F2/CF-08993-D95F2EF4; Thu, 21 Jun 2012 10:21:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340274075!10821274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29511 invoked from network); 21 Jun 2012 10:21:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:21:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:21:12 +0100
Message-ID: <1340274071.21872.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 11:21:11 +0100
In-Reply-To: <1340272814.4856.16.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<16222d05875389899968.1339779871@Solace>
	<1340269342.21872.20.camel@zakaz.uk.xensource.com>
	<1340272814.4856.16.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03 of 10 v2] libxl,
	libxc: introduce libxl_get_numainfo()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> > > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > > --- a/tools/libxl/libxl_utils.c
> > > +++ b/tools/libxl/libxl_utils.c
> > > @@ -537,6 +537,11 @@ int libxl_get_max_cpus(libxl_ctx *ctx)
> > >      return xc_get_max_cpus(ctx->xch);
> > >  }
> > >  
> > > +int libxl_get_max_nodes(libxl_ctx *ctx)
> > > +{
> > > +    return xc_get_max_nodes(ctx->xch);
> > > +}
> > 
> > Is this needed externally to libxl or do we expect all callers to use
> > libxl_get_numainfo? I suppose there is no harm in exporting this either
> > way.
> > 
> I'm not sure. What I did is to replicate what happens for
> libxl_get_max_cpus(), but I really don't know whether or not they both
> make any sense outside libxl. It does not look that bad to me that we
> offer our users a chance to figure out how many cpus and/or nodes they
> have, without needing to call the proper libxl_get_*info(), which is
> quite a bit more of a burden. FWIW, I'd leave both of them public.

OK.

> > > 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
> > > @@ -484,6 +484,7 @@ typedef struct xen_sysctl_topologyinfo x
> > >  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
> > >  
> > >  /* XEN_SYSCTL_numainfo */
> > > +#define INVALID_NUMAINFO_ID (~0U)
> > 
> > It feels like there ought to be hunks in the hypervisor which either use
> > this symbol instead of a hardcoded ~0U or which remove the internal
> > definition in favour of this one?
> > 
> Again, -topologyinfo machinery does exactly this, so I really think we
> either fix/change or leave as they are both of them (which of course I
> can do, just tell me if that is what you want).

Lets leave it as is then.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:22:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:22: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 1SheXF-0004O0-M7; Thu, 21 Jun 2012 10:22: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 1SheXE-0004Np-3Y
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:22:44 +0000
Received: from [85.158.139.83:35927] by server-8.bemta-5.messagelabs.com id
	90/4F-10278-3F5F2EF4; Thu, 21 Jun 2012 10:22:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340274162!23649072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3804 invoked from network); 21 Jun 2012 10:22:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:22:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:22:22 +0100
Message-ID: <1340274140.21872.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 11:22:20 +0100
In-Reply-To: <1340272189.4856.7.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<5d3cbf2e6370d1989bcd.1339779873@Solace>
	<1340269942.21872.26.camel@zakaz.uk.xensource.com>
	<1340272189.4856.7.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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 Thu, 2012-06-21 at 10:49 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-21 at 10:12 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > > And leave to the caller the burden of knowing and remembering what kind
> > > of bitmap each instance of libxl_bitmap is.
> > > 
> > > This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some other
> > > related interface name substitution, e.g., libxl_for_each_cpu) in a bunch
> > > of files, with no real functional change involved.
> > > 
> > > A specific allocation helper is introduced, besides libxl_bitmap_alloc().
> > > It is called libxl_cpu_bitmap_alloc() and is meant at substituting the old
> > > libxl_cpumap_alloc(). It is just something easier to use in cases where one
> > > wants to allocate a libxl_bitmap that is going to serve as a cpu map.
> > > 
> > > This is because we want to be able to deal with both cpu and NUMA node
> > > maps, but we don't want to duplicate all the various helpers and wrappers.
> > 
> > FWIW I'd have been perfectly happy with a bunch of 
> > 	#define for_each_cpu(mumble) for_each_bit(mumble)
> > type stuff, but I think Ian J and yourself didn't like those which I'm
> > also fine with.
> > 
> Well, I'm fine with both approaches, actually. However, I've been asked
> by Ian during last round to kill the duplication as much as I can, and
> here it is what I came out with. :-)
> 
> That being said, if it's just a matter of adding back a couple of
> libxl_for_each_{set_}cpu as a define to libxl_for_each_{set_} bit, I
> could well do that, as it looks a "reasonable" amount of wrapper
> duplication to me...

Lets not bother now -- it's easier to add a wrapper in the future than
to remove a bad one done in haste in the last stages of the release.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:22:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:22: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 1SheXF-0004O0-M7; Thu, 21 Jun 2012 10:22: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 1SheXE-0004Np-3Y
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:22:44 +0000
Received: from [85.158.139.83:35927] by server-8.bemta-5.messagelabs.com id
	90/4F-10278-3F5F2EF4; Thu, 21 Jun 2012 10:22:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340274162!23649072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3804 invoked from network); 21 Jun 2012 10:22:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:22:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:22:22 +0100
Message-ID: <1340274140.21872.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 11:22:20 +0100
In-Reply-To: <1340272189.4856.7.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<5d3cbf2e6370d1989bcd.1339779873@Solace>
	<1340269942.21872.26.camel@zakaz.uk.xensource.com>
	<1340272189.4856.7.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to
	libxl_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 Thu, 2012-06-21 at 10:49 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-21 at 10:12 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > > And leave to the caller the burden of knowing and remembering what kind
> > > of bitmap each instance of libxl_bitmap is.
> > > 
> > > This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some other
> > > related interface name substitution, e.g., libxl_for_each_cpu) in a bunch
> > > of files, with no real functional change involved.
> > > 
> > > A specific allocation helper is introduced, besides libxl_bitmap_alloc().
> > > It is called libxl_cpu_bitmap_alloc() and is meant at substituting the old
> > > libxl_cpumap_alloc(). It is just something easier to use in cases where one
> > > wants to allocate a libxl_bitmap that is going to serve as a cpu map.
> > > 
> > > This is because we want to be able to deal with both cpu and NUMA node
> > > maps, but we don't want to duplicate all the various helpers and wrappers.
> > 
> > FWIW I'd have been perfectly happy with a bunch of 
> > 	#define for_each_cpu(mumble) for_each_bit(mumble)
> > type stuff, but I think Ian J and yourself didn't like those which I'm
> > also fine with.
> > 
> Well, I'm fine with both approaches, actually. However, I've been asked
> by Ian during last round to kill the duplication as much as I can, and
> here it is what I came out with. :-)
> 
> That being said, if it's just a matter of adding back a couple of
> libxl_for_each_{set_}cpu as a define to libxl_for_each_{set_} bit, I
> could well do that, as it looks a "reasonable" amount of wrapper
> duplication to me...

Lets not bother now -- it's easier to add a wrapper in the future than
to remove a bad one done in haste in the last stages of the release.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10: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 1ShebJ-0004eU-Fq; Thu, 21 Jun 2012 10:26:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShebI-0004eP-8l
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:26:56 +0000
Received: from [85.158.143.99:22016] by server-1.bemta-4.messagelabs.com id
	0E/D1-24392-FE6F2EF4; Thu, 21 Jun 2012 10:26:55 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340274414!23146067!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.6 required=7.0 tests=DIET_1
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10284 invoked from network); 21 Jun 2012 10:26:54 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 10:26:54 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79036727; Thu, 21 Jun 2012 12:26:53 +0200
Message-ID: <1340274407.4856.39.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 12:26:47 +0200
In-Reply-To: <1340272422.21872.53.camel@zakaz.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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: multipart/mixed; boundary="===============1841123279559293979=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1841123279559293979==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ruogyMbHGg+ZUxMZBNVQ"


--=-ruogyMbHGg+ZUxMZBNVQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:53 +0100, Ian Campbell wrote:
> Thanks for this. I'd like to get it in ASAP so we can start passing
> tests again.=20
>
Hopefully! :-O

> I have a few queries though unfortunately...
>=20
Sure.

> (most of the comments below are just me thinking aloud following the
> logic, because it's pretty subtle...)
>=20
That's more than reasonable, it took a lot of this to me too. The point
is that the sedf scheduler is not, from POV of both the algorithm and
the interface, is a shape I'd call "good". Just think that if you _get()
dom0's scheduling parameters and you try to _set() back what you just
got, it will fail! :-(

Unfortunately, I can't think of any way to put some sense into it
without almost rewriting both (i.e., algorithm and interface), which I'm
still hoping to find the time to do at some point! :-)


> > @@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
> >      if (sci.sched =3D=3D LIBXL_SCHEDULER_SEDF) {
> >          if (has_weight && (has_period || has_slice))
> >              return 0;
> > -
> > +        if (has_period !=3D has_slice)
> > +            return 0;
>=20
> OK, so if you give period you _must_ give slice too, there is no
> default?
>=20
Default for period is 100ms (although it's some sort of fake period, but
anyway). Default for slice is 0. So, theoretically, you could just
provide slice and rely on period being there, but not the vice versa.
However, if one wants an EDF real-time scheduler domain, I don't think
it's too much to ask to provide both slice and period, given it also
makes what follows easier to handle. Let me know if you think the other
way around. It's not that hard to deal with it here (without affecting
the logic below to much, which is already too complicated!).

> > +        /*
> > +         * Idea is, if we specify a weight, then both period and
> > +         * slice has to be zero. OTOH, if we do not specify a weight,
> > +         * that means we want a pure best effort domain or an actual
> > +         * real-time one. In the former case, it is period that needs
> > +         * to be zero, in the latter, weight should be.
> > +         */
>=20
> I suspect there is a doc somewhere of which combinations of values are
> valid and what they mean etc -- perhaps we could link to it here?
>=20
> It's docs/misc/sedf_scheduler_mini-HOWTO.txt I suppose?
>=20
Yes, I can point the reader to it. Thanks.

> >          if (has_weight) {
> >              scp->slice =3D 0;
> >              scp->period =3D 0;
> >          }
>=20
> If we have a weight then we've already checked that we don't has_period
> or has_slice so force them to zero. Makes sense.
>=20
And besides making sense, it's needed for the set-scheduling-parameter
call to be successful (as it is the vice versa, if we have slice and
period, weight should be zeroed).


> > -        if (has_period || has_slice)
> > +        else if (!has_period) {
>=20
> So here we don't have weight or period. We also know we don't have a
> slice either because we checked that we either have or don't have both
> of slice and period.
>=20
Yep.

> > +            /* We can setup a proper best effort domain (extra time on=
ly)
> > +             * iff we either already have or are asking for some extra=
 time. */
> > +            scp->weight =3D has_extratime ? scp->extratime : sci.extra=
time;
>=20
> weight =3D extratime?
>=20
> If I understand correctly then weight is an integer and extratime is a
> bool, which just seems wrong. Or is this subtly relying on the fact that
> True =3D=3D 1 and therefore we set the weight to either 1 or 0?
>=20
Exactly. As I tried to explain in the comment, not providing _anything_,
i.e., no slice/period and no weight, means you want a pure best effort
domain or whatever the default is, right? Ok, unfortunately, the default
is period=3D100,slice=3D0,weight=3D0,extratime=3D1, which would just fail, =
as
we're not providing any weight, we're providing a period but with zero
slice! Therefore I need to do something to fix things, or trying to
create a domain without passing any scheduling parameters would just
always fail (as it is actually happening).

Also, I can't just set period to zero, as the call will fail also if I
try to set weight=3D0, besides setting it internally in the scheduler code
(and that's why it is that that is returned when you ask for
actual/default scheduling parameters). :-O

However, if you set extratime=3D1 (with period=3D0 and slice=3D0), whatever
weight you provide, will be zeroed by the hypervisor, even if you can't
pass weight=3D0 yourself.

Tricky eh?

> If so then adding some !! on the bools would ensure that you really have
> 0 or 1 and not some other True value. Also expanding the comment to say
> that iff we have extratime then weight =3D=3D 1 would make this clearer.
>=20
Ok, I suppose I can do that. :-)

> > +            scp->period =3D 0;
> > +        }
> > +        if (has_period && has_slice)
>=20
> is this also the same as "else if (has_period && has_slice)", which
> since we know has_period =3D=3D has_slice is "else if (has_period")" whic=
h,
> given the previous "else if (!has_period)" is just "else" (plus a
> comment ;-))
>=20
Probably. :-) I'll double check that and turn into what you suggest when
resubmitting.

Both when I did this in the first place and now, I tried to look at what
main_sched_sedf() does and replicate that logic as much as I can, to
make things easier to understand. The point here is we're being called
by a different context/situation, but I maybe can give it another shot
and see if I can quickly come up with something less mind blowing! :-P

Thanks for looking at the patch.
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-ruogyMbHGg+ZUxMZBNVQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i9ucACgkQk4XaBE3IOsREpACgpGvQUHiyhZ0XPHPQOWIQwab5
9xcAnixibtmaOHq+tUXn5rVDdaRosefq
=a7aP
-----END PGP SIGNATURE-----

--=-ruogyMbHGg+ZUxMZBNVQ--



--===============1841123279559293979==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1841123279559293979==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 10:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10: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 1ShebJ-0004eU-Fq; Thu, 21 Jun 2012 10:26:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShebI-0004eP-8l
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:26:56 +0000
Received: from [85.158.143.99:22016] by server-1.bemta-4.messagelabs.com id
	0E/D1-24392-FE6F2EF4; Thu, 21 Jun 2012 10:26:55 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340274414!23146067!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.6 required=7.0 tests=DIET_1
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10284 invoked from network); 21 Jun 2012 10:26:54 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 10:26:54 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79036727; Thu, 21 Jun 2012 12:26:53 +0200
Message-ID: <1340274407.4856.39.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 12:26:47 +0200
In-Reply-To: <1340272422.21872.53.camel@zakaz.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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: multipart/mixed; boundary="===============1841123279559293979=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1841123279559293979==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ruogyMbHGg+ZUxMZBNVQ"


--=-ruogyMbHGg+ZUxMZBNVQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 10:53 +0100, Ian Campbell wrote:
> Thanks for this. I'd like to get it in ASAP so we can start passing
> tests again.=20
>
Hopefully! :-O

> I have a few queries though unfortunately...
>=20
Sure.

> (most of the comments below are just me thinking aloud following the
> logic, because it's pretty subtle...)
>=20
That's more than reasonable, it took a lot of this to me too. The point
is that the sedf scheduler is not, from POV of both the algorithm and
the interface, is a shape I'd call "good". Just think that if you _get()
dom0's scheduling parameters and you try to _set() back what you just
got, it will fail! :-(

Unfortunately, I can't think of any way to put some sense into it
without almost rewriting both (i.e., algorithm and interface), which I'm
still hoping to find the time to do at some point! :-)


> > @@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
> >      if (sci.sched =3D=3D LIBXL_SCHEDULER_SEDF) {
> >          if (has_weight && (has_period || has_slice))
> >              return 0;
> > -
> > +        if (has_period !=3D has_slice)
> > +            return 0;
>=20
> OK, so if you give period you _must_ give slice too, there is no
> default?
>=20
Default for period is 100ms (although it's some sort of fake period, but
anyway). Default for slice is 0. So, theoretically, you could just
provide slice and rely on period being there, but not the vice versa.
However, if one wants an EDF real-time scheduler domain, I don't think
it's too much to ask to provide both slice and period, given it also
makes what follows easier to handle. Let me know if you think the other
way around. It's not that hard to deal with it here (without affecting
the logic below to much, which is already too complicated!).

> > +        /*
> > +         * Idea is, if we specify a weight, then both period and
> > +         * slice has to be zero. OTOH, if we do not specify a weight,
> > +         * that means we want a pure best effort domain or an actual
> > +         * real-time one. In the former case, it is period that needs
> > +         * to be zero, in the latter, weight should be.
> > +         */
>=20
> I suspect there is a doc somewhere of which combinations of values are
> valid and what they mean etc -- perhaps we could link to it here?
>=20
> It's docs/misc/sedf_scheduler_mini-HOWTO.txt I suppose?
>=20
Yes, I can point the reader to it. Thanks.

> >          if (has_weight) {
> >              scp->slice =3D 0;
> >              scp->period =3D 0;
> >          }
>=20
> If we have a weight then we've already checked that we don't has_period
> or has_slice so force them to zero. Makes sense.
>=20
And besides making sense, it's needed for the set-scheduling-parameter
call to be successful (as it is the vice versa, if we have slice and
period, weight should be zeroed).


> > -        if (has_period || has_slice)
> > +        else if (!has_period) {
>=20
> So here we don't have weight or period. We also know we don't have a
> slice either because we checked that we either have or don't have both
> of slice and period.
>=20
Yep.

> > +            /* We can setup a proper best effort domain (extra time on=
ly)
> > +             * iff we either already have or are asking for some extra=
 time. */
> > +            scp->weight =3D has_extratime ? scp->extratime : sci.extra=
time;
>=20
> weight =3D extratime?
>=20
> If I understand correctly then weight is an integer and extratime is a
> bool, which just seems wrong. Or is this subtly relying on the fact that
> True =3D=3D 1 and therefore we set the weight to either 1 or 0?
>=20
Exactly. As I tried to explain in the comment, not providing _anything_,
i.e., no slice/period and no weight, means you want a pure best effort
domain or whatever the default is, right? Ok, unfortunately, the default
is period=3D100,slice=3D0,weight=3D0,extratime=3D1, which would just fail, =
as
we're not providing any weight, we're providing a period but with zero
slice! Therefore I need to do something to fix things, or trying to
create a domain without passing any scheduling parameters would just
always fail (as it is actually happening).

Also, I can't just set period to zero, as the call will fail also if I
try to set weight=3D0, besides setting it internally in the scheduler code
(and that's why it is that that is returned when you ask for
actual/default scheduling parameters). :-O

However, if you set extratime=3D1 (with period=3D0 and slice=3D0), whatever
weight you provide, will be zeroed by the hypervisor, even if you can't
pass weight=3D0 yourself.

Tricky eh?

> If so then adding some !! on the bools would ensure that you really have
> 0 or 1 and not some other True value. Also expanding the comment to say
> that iff we have extratime then weight =3D=3D 1 would make this clearer.
>=20
Ok, I suppose I can do that. :-)

> > +            scp->period =3D 0;
> > +        }
> > +        if (has_period && has_slice)
>=20
> is this also the same as "else if (has_period && has_slice)", which
> since we know has_period =3D=3D has_slice is "else if (has_period")" whic=
h,
> given the previous "else if (!has_period)" is just "else" (plus a
> comment ;-))
>=20
Probably. :-) I'll double check that and turn into what you suggest when
resubmitting.

Both when I did this in the first place and now, I tried to look at what
main_sched_sedf() does and replicate that logic as much as I can, to
make things easier to understand. The point here is we're being called
by a different context/situation, but I maybe can give it another shot
and see if I can quickly come up with something less mind blowing! :-P

Thanks for looking at the patch.
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-ruogyMbHGg+ZUxMZBNVQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i9ucACgkQk4XaBE3IOsREpACgpGvQUHiyhZ0XPHPQOWIQwab5
9xcAnixibtmaOHq+tUXn5rVDdaRosefq
=a7aP
-----END PGP SIGNATURE-----

--=-ruogyMbHGg+ZUxMZBNVQ--



--===============1841123279559293979==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1841123279559293979==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 10:27:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10: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 1Shebw-0004hf-Td; Thu, 21 Jun 2012 10:27:36 +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 1Shebv-0004hX-Qa
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:27:35 +0000
Received: from [85.158.138.51:20129] by server-6.bemta-3.messagelabs.com id
	11/58-11602-617F2EF4; Thu, 21 Jun 2012 10:27:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340274454!10128451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31637 invoked from network); 21 Jun 2012 10:27:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:27:16 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 11:27:16 +0100
Message-ID: <4FE2F704.1070608@citrix.com>
Date: Thu, 21 Jun 2012 11:27:16 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
	<4FE2EBD9.4040101@citrix.com>
	<1340273928.21872.62.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340273928.21872.62.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> Using PTHREAD_STACK_MIN sounds like a good idea, since this patch is in
> can you send an incremental update? You could do max(PTHREAD_STACK_MIN,
> 16*1204) perhaps?

If we are trying to reduce stack as much as possible shouldn't we use 
PTHREAD_STACK_MIN directly?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:27:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10: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 1Shebw-0004hf-Td; Thu, 21 Jun 2012 10:27:36 +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 1Shebv-0004hX-Qa
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:27:35 +0000
Received: from [85.158.138.51:20129] by server-6.bemta-3.messagelabs.com id
	11/58-11602-617F2EF4; Thu, 21 Jun 2012 10:27:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340274454!10128451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31637 invoked from network); 21 Jun 2012 10:27:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:27:16 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 11:27:16 +0100
Message-ID: <4FE2F704.1070608@citrix.com>
Date: Thu, 21 Jun 2012 11:27:16 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.3 (Macintosh/20120304)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
	<4FE2EBD9.4040101@citrix.com>
	<1340273928.21872.62.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340273928.21872.62.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> Using PTHREAD_STACK_MIN sounds like a good idea, since this patch is in
> can you send an incremental update? You could do max(PTHREAD_STACK_MIN,
> 16*1204) perhaps?

If we are trying to reduce stack as much as possible shouldn't we use 
PTHREAD_STACK_MIN directly?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sheh6-0004yc-LE; Thu, 21 Jun 2012 10:32:56 +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 1Sheh5-0004yW-7z
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:32:55 +0000
Received: from [193.109.254.147:21268] by server-3.bemta-14.messagelabs.com id
	B1/A8-08687-658F2EF4; Thu, 21 Jun 2012 10:32:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340274773!10824150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28142 invoked from network); 21 Jun 2012 10:32:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:32:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:32:17 +0100
Message-ID: <1340274736.21872.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 21 Jun 2012 11:32:16 +0100
In-Reply-To: <4FE2F704.1070608@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
	<4FE2EBD9.4040101@citrix.com>
	<1340273928.21872.62.camel@zakaz.uk.xensource.com>
	<4FE2F704.1070608@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 11:27 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > Using PTHREAD_STACK_MIN sounds like a good idea, since this patch is in
> > can you send an incremental update? You could do max(PTHREAD_STACK_MIN,
> > 16*1204) perhaps?
> 
> If we are trying to reduce stack as much as possible shouldn't we use 
> PTHREAD_STACK_MIN directly?

My thinking was that 16K has been validated as a minimum. I/we don't
know what would happen e.g. if PTHREAD_STACK_MIN was 8K without doing
further investigative 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 Jun 21 10:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sheh6-0004yc-LE; Thu, 21 Jun 2012 10:32:56 +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 1Sheh5-0004yW-7z
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:32:55 +0000
Received: from [193.109.254.147:21268] by server-3.bemta-14.messagelabs.com id
	B1/A8-08687-658F2EF4; Thu, 21 Jun 2012 10:32:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340274773!10824150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28142 invoked from network); 21 Jun 2012 10:32:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:32:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:32:17 +0100
Message-ID: <1340274736.21872.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 21 Jun 2012 11:32:16 +0100
In-Reply-To: <4FE2F704.1070608@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
	<1340270320.21872.31.camel@zakaz.uk.xensource.com>
	<4FE2EBD9.4040101@citrix.com>
	<1340273928.21872.62.camel@zakaz.uk.xensource.com>
	<4FE2F704.1070608@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 11:27 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > Using PTHREAD_STACK_MIN sounds like a good idea, since this patch is in
> > can you send an incremental update? You could do max(PTHREAD_STACK_MIN,
> > 16*1204) perhaps?
> 
> If we are trying to reduce stack as much as possible shouldn't we use 
> PTHREAD_STACK_MIN directly?

My thinking was that 16K has been validated as a minimum. I/we don't
know what would happen e.g. if PTHREAD_STACK_MIN was 8K without doing
further investigative 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 Jun 21 10:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SheoZ-0005Bo-Ih; Thu, 21 Jun 2012 10:40: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 1SheoY-0005Bj-9F
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:40:38 +0000
Received: from [193.109.254.147:37867] by server-8.bemta-14.messagelabs.com id
	94/64-30743-52AF2EF4; Thu, 21 Jun 2012 10:40:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340275232!10012389!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24278 invoked from network); 21 Jun 2012 10:40:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:40:32 +0100
Message-ID: <1340275231.21872.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 11:40:31 +0100
In-Reply-To: <1340274407.4856.39.camel@Solace>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
	<1340274407.4856.39.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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

On Thu, 2012-06-21 at 11:26 +0100, Dario Faggioli wrote:

> > > @@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
> > >      if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> > >          if (has_weight && (has_period || has_slice))
> > >              return 0;
> > > -
> > > +        if (has_period != has_slice)
> > > +            return 0;
> > 
> > OK, so if you give period you _must_ give slice too, there is no
> > default?
> > 
> Default for period is 100ms (although it's some sort of fake period, but
> anyway). Default for slice is 0. So, theoretically, you could just
> provide slice and rely on period being there, but not the vice versa.
> However, if one wants an EDF real-time scheduler domain, I don't think
> it's too much to ask to provide both slice and period, given it also
> makes what follows easier to handle. Let me know if you think the other
> way around. It's not that hard to deal with it here (without affecting
> the logic below to much, which is already too complicated!).

This is fine as is.

> > > +            /* We can setup a proper best effort domain (extra time only)
> > > +             * iff we either already have or are asking for some extra time. */
> > > +            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> > 
> > weight = extratime?
> > 
> > If I understand correctly then weight is an integer and extratime is a
> > bool, which just seems wrong. Or is this subtly relying on the fact that
> > True == 1 and therefore we set the weight to either 1 or 0?
> > 
> Exactly. As I tried to explain in the comment, not providing _anything_,
> i.e., no slice/period and no weight, means you want a pure best effort
> domain or whatever the default is, right? Ok, unfortunately, the default
> is period=100,slice=0,weight=0,extratime=1, which would just fail, as
> we're not providing any weight, we're providing a period but with zero
> slice! Therefore I need to do something to fix things, or trying to
> create a domain without passing any scheduling parameters would just
> always fail (as it is actually happening).
> 
> Also, I can't just set period to zero, as the call will fail also if I
> try to set weight=0, besides setting it internally in the scheduler code
> (and that's why it is that that is returned when you ask for
> actual/default scheduling parameters). :-O
> 
> However, if you set extratime=1 (with period=0 and slice=0), whatever
> weight you provide, will be zeroed by the hypervisor, even if you can't
> pass weight=0 yourself.

Ah, ok, so the key thing, which I think needs to be in the comment, is
that weight must be non-zero in this case but that the specific value is
irrelevant since it will be zeroed.

I think it might be worth also mentioning in the comment what best
effort means in practice.I think it means a domain which can use extra
time but which has no actual period/slice/weight of its own (despite the
wrinkle about how you must supply weight).

> 
> Tricky eh?

Tricky isn't the half of it ;-)

> > If so then adding some !! on the bools would ensure that you really have
> > 0 or 1 and not some other True value. Also expanding the comment to say
> > that iff we have extratime then weight == 1 would make this clearer.
> > 
> Ok, I suppose I can do that. :-)

I'm not sure it's necessary if you include the comment to explain the
thing about weight being non-zero and getting clearer, but it can't hurt
I suppose.

> Both when I did this in the first place and now, I tried to look at what
> main_sched_sedf() does and replicate that logic as much as I can, to
> make things easier to understand. The point here is we're being called
> by a different context/situation, but I maybe can give it another shot
> and see if I can quickly come up with something less mind blowing! :-P

I think actually with your explanations the current way seems to make
sense to me, some more detail in the comments should be sufficient I
think. Rewriting it again into something (even if it were less mind
blowing) would likely still mean another round of this sort of
conversation I expect  ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:40:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SheoZ-0005Bo-Ih; Thu, 21 Jun 2012 10:40: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 1SheoY-0005Bj-9F
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:40:38 +0000
Received: from [193.109.254.147:37867] by server-8.bemta-14.messagelabs.com id
	94/64-30743-52AF2EF4; Thu, 21 Jun 2012 10:40:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340275232!10012389!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24278 invoked from network); 21 Jun 2012 10:40:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 10:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13143712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 10:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 11:40:32 +0100
Message-ID: <1340275231.21872.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 11:40:31 +0100
In-Reply-To: <1340274407.4856.39.camel@Solace>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
	<1340274407.4856.39.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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

On Thu, 2012-06-21 at 11:26 +0100, Dario Faggioli wrote:

> > > @@ -563,12 +565,27 @@ static int sched_params_valid(libxl_doma
> > >      if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> > >          if (has_weight && (has_period || has_slice))
> > >              return 0;
> > > -
> > > +        if (has_period != has_slice)
> > > +            return 0;
> > 
> > OK, so if you give period you _must_ give slice too, there is no
> > default?
> > 
> Default for period is 100ms (although it's some sort of fake period, but
> anyway). Default for slice is 0. So, theoretically, you could just
> provide slice and rely on period being there, but not the vice versa.
> However, if one wants an EDF real-time scheduler domain, I don't think
> it's too much to ask to provide both slice and period, given it also
> makes what follows easier to handle. Let me know if you think the other
> way around. It's not that hard to deal with it here (without affecting
> the logic below to much, which is already too complicated!).

This is fine as is.

> > > +            /* We can setup a proper best effort domain (extra time only)
> > > +             * iff we either already have or are asking for some extra time. */
> > > +            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> > 
> > weight = extratime?
> > 
> > If I understand correctly then weight is an integer and extratime is a
> > bool, which just seems wrong. Or is this subtly relying on the fact that
> > True == 1 and therefore we set the weight to either 1 or 0?
> > 
> Exactly. As I tried to explain in the comment, not providing _anything_,
> i.e., no slice/period and no weight, means you want a pure best effort
> domain or whatever the default is, right? Ok, unfortunately, the default
> is period=100,slice=0,weight=0,extratime=1, which would just fail, as
> we're not providing any weight, we're providing a period but with zero
> slice! Therefore I need to do something to fix things, or trying to
> create a domain without passing any scheduling parameters would just
> always fail (as it is actually happening).
> 
> Also, I can't just set period to zero, as the call will fail also if I
> try to set weight=0, besides setting it internally in the scheduler code
> (and that's why it is that that is returned when you ask for
> actual/default scheduling parameters). :-O
> 
> However, if you set extratime=1 (with period=0 and slice=0), whatever
> weight you provide, will be zeroed by the hypervisor, even if you can't
> pass weight=0 yourself.

Ah, ok, so the key thing, which I think needs to be in the comment, is
that weight must be non-zero in this case but that the specific value is
irrelevant since it will be zeroed.

I think it might be worth also mentioning in the comment what best
effort means in practice.I think it means a domain which can use extra
time but which has no actual period/slice/weight of its own (despite the
wrinkle about how you must supply weight).

> 
> Tricky eh?

Tricky isn't the half of it ;-)

> > If so then adding some !! on the bools would ensure that you really have
> > 0 or 1 and not some other True value. Also expanding the comment to say
> > that iff we have extratime then weight == 1 would make this clearer.
> > 
> Ok, I suppose I can do that. :-)

I'm not sure it's necessary if you include the comment to explain the
thing about weight being non-zero and getting clearer, but it can't hurt
I suppose.

> Both when I did this in the first place and now, I tried to look at what
> main_sched_sedf() does and replicate that logic as much as I can, to
> make things easier to understand. The point here is we're being called
> by a different context/situation, but I maybe can give it another shot
> and see if I can quickly come up with something less mind blowing! :-P

I think actually with your explanations the current way seems to make
sense to me, some more detail in the comments should be sufficient I
think. Rewriting it again into something (even if it were less mind
blowing) would likely still mean another round of this sort of
conversation I expect  ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 10:55:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:55: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 1Shf2L-0005O7-19; Thu, 21 Jun 2012 10:54:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Shf2J-0005O2-OO
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:54:51 +0000
Received: from [193.109.254.147:44507] by server-4.bemta-14.messagelabs.com id
	1E/E9-02077-A7DF2EF4; Thu, 21 Jun 2012 10:54:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340276084!5222740!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30700 invoked from network); 21 Jun 2012 10:54:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 10:54:45 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79037643; Thu, 21 Jun 2012 12:54:44 +0200
Message-ID: <1340276077.4856.41.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 12:54:37 +0200
In-Reply-To: <1340275231.21872.73.camel@zakaz.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
	<1340274407.4856.39.camel@Solace>
	<1340275231.21872.73.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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: multipart/mixed; boundary="===============3614310485676241470=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3614310485676241470==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-SFduc8iiz10kvwH0+QmM"


--=-SFduc8iiz10kvwH0+QmM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 11:40 +0100, Ian Campbell wrote:
> > Also, I can't just set period to zero, as the call will fail also if I
> > try to set weight=3D0, besides setting it internally in the scheduler c=
ode
> > (and that's why it is that that is returned when you ask for
> > actual/default scheduling parameters). :-O
> >=20
> > However, if you set extratime=3D1 (with period=3D0 and slice=3D0), what=
ever
> > weight you provide, will be zeroed by the hypervisor, even if you can't
> > pass weight=3D0 yourself.
>=20
> Ah, ok, so the key thing, which I think needs to be in the comment, is
> that weight must be non-zero in this case but that the specific value is
> irrelevant since it will be zeroed.
>=20
Exactly!

> I think it might be worth also mentioning in the comment what best
> effort means in practice.I think it means a domain which can use extra
> time but which has no actual period/slice/weight of its own (despite the
> wrinkle about how you must supply weight).
>=20
Ok.
=20
> > Tricky eh?
>=20
> Tricky isn't the half of it ;-)
>
:-)

> > Both when I did this in the first place and now, I tried to look at wha=
t
> > main_sched_sedf() does and replicate that logic as much as I can, to
> > make things easier to understand. The point here is we're being called
> > by a different context/situation, but I maybe can give it another shot
> > and see if I can quickly come up with something less mind blowing! :-P
>=20
> I think actually with your explanations the current way seems to make
> sense to me, some more detail in the comments should be sufficient I
> think. Rewriting it again into something (even if it were less mind
> blowing) would likely still mean another round of this sort of
> conversation I expect  ;-)
>=20
Me too. I'll add those bits and resend then.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-SFduc8iiz10kvwH0+QmM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i/W0ACgkQk4XaBE3IOsSwQACaAgRq+549cD+KR+t6inq1ZfaH
6HgAoIZdQHWbczT3EU0oCm2nD+ZwURLM
=139y
-----END PGP SIGNATURE-----

--=-SFduc8iiz10kvwH0+QmM--



--===============3614310485676241470==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3614310485676241470==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 10:55:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 10:55: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 1Shf2L-0005O7-19; Thu, 21 Jun 2012 10:54:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Shf2J-0005O2-OO
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 10:54:51 +0000
Received: from [193.109.254.147:44507] by server-4.bemta-14.messagelabs.com id
	1E/E9-02077-A7DF2EF4; Thu, 21 Jun 2012 10:54:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340276084!5222740!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30700 invoked from network); 21 Jun 2012 10:54:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 10:54:45 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79037643; Thu, 21 Jun 2012 12:54:44 +0200
Message-ID: <1340276077.4856.41.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 12:54:37 +0200
In-Reply-To: <1340275231.21872.73.camel@zakaz.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
	<1340274407.4856.39.camel@Solace>
	<1340275231.21872.73.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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] xl: fix sedf parameters 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: multipart/mixed; boundary="===============3614310485676241470=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3614310485676241470==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-SFduc8iiz10kvwH0+QmM"


--=-SFduc8iiz10kvwH0+QmM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 11:40 +0100, Ian Campbell wrote:
> > Also, I can't just set period to zero, as the call will fail also if I
> > try to set weight=3D0, besides setting it internally in the scheduler c=
ode
> > (and that's why it is that that is returned when you ask for
> > actual/default scheduling parameters). :-O
> >=20
> > However, if you set extratime=3D1 (with period=3D0 and slice=3D0), what=
ever
> > weight you provide, will be zeroed by the hypervisor, even if you can't
> > pass weight=3D0 yourself.
>=20
> Ah, ok, so the key thing, which I think needs to be in the comment, is
> that weight must be non-zero in this case but that the specific value is
> irrelevant since it will be zeroed.
>=20
Exactly!

> I think it might be worth also mentioning in the comment what best
> effort means in practice.I think it means a domain which can use extra
> time but which has no actual period/slice/weight of its own (despite the
> wrinkle about how you must supply weight).
>=20
Ok.
=20
> > Tricky eh?
>=20
> Tricky isn't the half of it ;-)
>
:-)

> > Both when I did this in the first place and now, I tried to look at wha=
t
> > main_sched_sedf() does and replicate that logic as much as I can, to
> > make things easier to understand. The point here is we're being called
> > by a different context/situation, but I maybe can give it another shot
> > and see if I can quickly come up with something less mind blowing! :-P
>=20
> I think actually with your explanations the current way seems to make
> sense to me, some more detail in the comments should be sufficient I
> think. Rewriting it again into something (even if it were less mind
> blowing) would likely still mean another round of this sort of
> conversation I expect  ;-)
>=20
Me too. I'll add those bits and resend then.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-SFduc8iiz10kvwH0+QmM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/i/W0ACgkQk4XaBE3IOsSwQACaAgRq+549cD+KR+t6inq1ZfaH
6HgAoIZdQHWbczT3EU0oCm2nD+ZwURLM
=139y
-----END PGP SIGNATURE-----

--=-SFduc8iiz10kvwH0+QmM--



--===============3614310485676241470==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3614310485676241470==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 11:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShfG8-0005ew-D3; Thu, 21 Jun 2012 11:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ebiederm@xmission.com>) id 1ShfG6-0005en-9q
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 11:09:06 +0000
Received: from [85.158.143.35:33328] by server-1.bemta-4.messagelabs.com id
	FF/47-24392-1D003EF4; Thu, 21 Jun 2012 11:09:05 +0000
X-Env-Sender: ebiederm@xmission.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340276944!5505534!1
X-Originating-IP: [166.70.13.233]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13910 invoked from network); 21 Jun 2012 11:09:04 -0000
Received: from out03.mta.xmission.com (HELO out03.mta.xmission.com)
	(166.70.13.233) by server-5.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 11:09:04 -0000
Received: from in02.mta.xmission.com ([166.70.13.52])
	by out03.mta.xmission.com with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76)
	(envelope-from <ebiederm@xmission.com>)
	id 1ShfFy-0007TS-C7; Thu, 21 Jun 2012 05:08:58 -0600
Received: from c-98-207-153-68.hsd1.ca.comcast.net ([98.207.153.68]
	helo=eric-ThinkPad-X220.xmission.com)
	by in02.mta.xmission.com with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.69) (envelope-from <ebiederm@xmission.com>)
	id 1ShfFu-0005cH-KV; Thu, 21 Jun 2012 05:08:58 -0600
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Jan Beulich" <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
Date: Thu, 21 Jun 2012 04:08:46 -0700
In-Reply-To: <4FE30CBB020000780008B06B@nat28.tlf.novell.com> (Jan Beulich's
	message of "Thu, 21 Jun 2012 10:59:55 +0100")
Message-ID: <8762ak9b29.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
MIME-Version: 1.0
X-XM-SPF: eid=; ; ; mid=; ; ; hst=in02.mta.xmission.com; ; ; ip=98.207.153.68; ;
	; frm=ebiederm@xmission.com; ; ; spf=neutral
X-XM-AID: U2FsdGVkX1+zTv42c1jtzR6wiuHP6xKTAAlQ6UdVasA=
X-SA-Exim-Connect-IP: 98.207.153.68
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sa02.xmission.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=8.0 tests=ALL_TRUSTED,BAYES_05,
	DCC_CHECK_NEGATIVE, FVGT_m_MULTI_ODD, T_TM2_M_HEADER_IN_MSG,
	T_TooManySym_01, XMSubLong autolearn=disabled version=3.3.1
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.1 XMSubLong Long Subject
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG
	* -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5%
	*      [score: 0.0118]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa02 1397; Body=1 Fuz1=1 Fuz2=1]
	*  0.4 FVGT_m_MULTI_ODD Contains multiple odd letter combinations
	*  0.0 T_TooManySym_01 4+ unique symbols in subject
X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ;"Jan Beulich" <JBeulich@suse.com>
X-Spam-Relay-Country: 
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, Wei Wang <wei.wang2@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>> Have you at all considered getting this fixed on the kernel side?
>>> As I don't have direct access to any AMD IOMMU capable
>>> system - can one, other than by enumerating the respective
>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>> devices in question (e.g. via vendor/class/sub-class or some
>>> such)? That might permit skipping those in the offending kernel
>>> code...
>> 
>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
>> should be enough to identify amd iommu device. I could send you a kernel 
>> patch for review using this approach. I would believe that fixing this 
>> issue in 4.2, no matter how, is really important for amd iommu.
>
> As you didn't come forward with anything, here's my first
> take on this:
>
> Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
> interrupts when we initialize a pci device") caused MSI to get disabled
> on Xen Dom0 despite it having got turned on purposefully by the
> hypervisor. As an immediate band aid, suppress the disabling in this
> specific case.
>
> I don't think, however, that either the original change or this fix are
> really appropriate. The original fix, besides leaving aside the
> presence of a hypervisor like Xen, doesn't deal with all possible
> cases (in particular it has no effect if the secondary kernel was built
> with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
> Xen, the logic like this should probably be skipped altogether (i.e. it
> should be entirely left to the hypervisor, being the entity in control
> of IRQs).

The original fix is fine. Xen dom0 remains insane.  Although perhaps
some better than Xen dom0 once was.

Why does the dom0 kernel even get any access to pci devices that
Xen doesn't want it to touch?

As far as I can tell my patch has revealed a design bug in Xen.  If you
don't want to be messed up by the kernel don't let the kernel touch
things.  At the very least we need an abstraction much cleaner
than the patch below.

Eric


> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: stable@kernel.org 
>
> ---
>  drivers/pci/msi.c       |    7 +++++++
>  include/linux/pci_ids.h |    1 +
>  2 files changed, 8 insertions(+)
>
> --- 3.5-rc3/drivers/pci/msi.c
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/drivers/pci/msi.c
> @@ -20,6 +20,7 @@
>  #include <linux/errno.h>
>  #include <linux/io.h>
>  #include <linux/slab.h>
> +#include <xen/xen.h>
>  
>  #include "pci.h"
>  #include "msi.h"
> @@ -1022,7 +1023,13 @@ void pci_msi_init_pci_dev(struct pci_dev
>  	/* Disable the msi hardware to avoid screaming interrupts
>  	 * during boot.  This is the power on reset default so
>  	 * usually this should be a noop.
> +	 * But on a Xen host don't do this for IOMMUs which the hypervisor
> +	 * is in control of (and hence has already enabled on purpose).
>  	 */
> +	if (xen_initial_domain()
> +	    && (dev->class >> 8) == PCI_CLASS_SYSTEM_IOMMU
> +	    && dev->vendor == PCI_VENDOR_ID_AMD)
> +		return;
>  	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
>  	if (pos)
>  		msi_set_enable(dev, pos, 0);
> --- 3.5-rc3/include/linux/pci_ids.h
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/include/linux/pci_ids.h
> @@ -75,6 +75,7 @@
>  #define PCI_CLASS_SYSTEM_RTC		0x0803
>  #define PCI_CLASS_SYSTEM_PCI_HOTPLUG	0x0804
>  #define PCI_CLASS_SYSTEM_SDHCI		0x0805
> +#define PCI_CLASS_SYSTEM_IOMMU		0x0806
>  #define PCI_CLASS_SYSTEM_OTHER		0x0880
>  
>  #define PCI_BASE_CLASS_INPUT		0x09

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShfG8-0005ew-D3; Thu, 21 Jun 2012 11:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ebiederm@xmission.com>) id 1ShfG6-0005en-9q
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 11:09:06 +0000
Received: from [85.158.143.35:33328] by server-1.bemta-4.messagelabs.com id
	FF/47-24392-1D003EF4; Thu, 21 Jun 2012 11:09:05 +0000
X-Env-Sender: ebiederm@xmission.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340276944!5505534!1
X-Originating-IP: [166.70.13.233]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13910 invoked from network); 21 Jun 2012 11:09:04 -0000
Received: from out03.mta.xmission.com (HELO out03.mta.xmission.com)
	(166.70.13.233) by server-5.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 11:09:04 -0000
Received: from in02.mta.xmission.com ([166.70.13.52])
	by out03.mta.xmission.com with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76)
	(envelope-from <ebiederm@xmission.com>)
	id 1ShfFy-0007TS-C7; Thu, 21 Jun 2012 05:08:58 -0600
Received: from c-98-207-153-68.hsd1.ca.comcast.net ([98.207.153.68]
	helo=eric-ThinkPad-X220.xmission.com)
	by in02.mta.xmission.com with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.69) (envelope-from <ebiederm@xmission.com>)
	id 1ShfFu-0005cH-KV; Thu, 21 Jun 2012 05:08:58 -0600
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Jan Beulich" <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
Date: Thu, 21 Jun 2012 04:08:46 -0700
In-Reply-To: <4FE30CBB020000780008B06B@nat28.tlf.novell.com> (Jan Beulich's
	message of "Thu, 21 Jun 2012 10:59:55 +0100")
Message-ID: <8762ak9b29.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
MIME-Version: 1.0
X-XM-SPF: eid=; ; ; mid=; ; ; hst=in02.mta.xmission.com; ; ; ip=98.207.153.68; ;
	; frm=ebiederm@xmission.com; ; ; spf=neutral
X-XM-AID: U2FsdGVkX1+zTv42c1jtzR6wiuHP6xKTAAlQ6UdVasA=
X-SA-Exim-Connect-IP: 98.207.153.68
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sa02.xmission.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=8.0 tests=ALL_TRUSTED,BAYES_05,
	DCC_CHECK_NEGATIVE, FVGT_m_MULTI_ODD, T_TM2_M_HEADER_IN_MSG,
	T_TooManySym_01, XMSubLong autolearn=disabled version=3.3.1
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.1 XMSubLong Long Subject
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG
	* -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5%
	*      [score: 0.0118]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa02 1397; Body=1 Fuz1=1 Fuz2=1]
	*  0.4 FVGT_m_MULTI_ODD Contains multiple odd letter combinations
	*  0.0 T_TooManySym_01 4+ unique symbols in subject
X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ;"Jan Beulich" <JBeulich@suse.com>
X-Spam-Relay-Country: 
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, Wei Wang <wei.wang2@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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

"Jan Beulich" <JBeulich@suse.com> writes:

>>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>> Have you at all considered getting this fixed on the kernel side?
>>> As I don't have direct access to any AMD IOMMU capable
>>> system - can one, other than by enumerating the respective
>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>> devices in question (e.g. via vendor/class/sub-class or some
>>> such)? That might permit skipping those in the offending kernel
>>> code...
>> 
>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
>> should be enough to identify amd iommu device. I could send you a kernel 
>> patch for review using this approach. I would believe that fixing this 
>> issue in 4.2, no matter how, is really important for amd iommu.
>
> As you didn't come forward with anything, here's my first
> take on this:
>
> Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
> interrupts when we initialize a pci device") caused MSI to get disabled
> on Xen Dom0 despite it having got turned on purposefully by the
> hypervisor. As an immediate band aid, suppress the disabling in this
> specific case.
>
> I don't think, however, that either the original change or this fix are
> really appropriate. The original fix, besides leaving aside the
> presence of a hypervisor like Xen, doesn't deal with all possible
> cases (in particular it has no effect if the secondary kernel was built
> with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
> Xen, the logic like this should probably be skipped altogether (i.e. it
> should be entirely left to the hypervisor, being the entity in control
> of IRQs).

The original fix is fine. Xen dom0 remains insane.  Although perhaps
some better than Xen dom0 once was.

Why does the dom0 kernel even get any access to pci devices that
Xen doesn't want it to touch?

As far as I can tell my patch has revealed a design bug in Xen.  If you
don't want to be messed up by the kernel don't let the kernel touch
things.  At the very least we need an abstraction much cleaner
than the patch below.

Eric


> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: stable@kernel.org 
>
> ---
>  drivers/pci/msi.c       |    7 +++++++
>  include/linux/pci_ids.h |    1 +
>  2 files changed, 8 insertions(+)
>
> --- 3.5-rc3/drivers/pci/msi.c
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/drivers/pci/msi.c
> @@ -20,6 +20,7 @@
>  #include <linux/errno.h>
>  #include <linux/io.h>
>  #include <linux/slab.h>
> +#include <xen/xen.h>
>  
>  #include "pci.h"
>  #include "msi.h"
> @@ -1022,7 +1023,13 @@ void pci_msi_init_pci_dev(struct pci_dev
>  	/* Disable the msi hardware to avoid screaming interrupts
>  	 * during boot.  This is the power on reset default so
>  	 * usually this should be a noop.
> +	 * But on a Xen host don't do this for IOMMUs which the hypervisor
> +	 * is in control of (and hence has already enabled on purpose).
>  	 */
> +	if (xen_initial_domain()
> +	    && (dev->class >> 8) == PCI_CLASS_SYSTEM_IOMMU
> +	    && dev->vendor == PCI_VENDOR_ID_AMD)
> +		return;
>  	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
>  	if (pos)
>  		msi_set_enable(dev, pos, 0);
> --- 3.5-rc3/include/linux/pci_ids.h
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/include/linux/pci_ids.h
> @@ -75,6 +75,7 @@
>  #define PCI_CLASS_SYSTEM_RTC		0x0803
>  #define PCI_CLASS_SYSTEM_PCI_HOTPLUG	0x0804
>  #define PCI_CLASS_SYSTEM_SDHCI		0x0805
> +#define PCI_CLASS_SYSTEM_IOMMU		0x0806
>  #define PCI_CLASS_SYSTEM_OTHER		0x0880
>  
>  #define PCI_BASE_CLASS_INPUT		0x09

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShfV9-0005uF-2A; Thu, 21 Jun 2012 11:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShfV8-0005uA-5u
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 11:24:38 +0000
Received: from [85.158.143.35:64206] by server-2.bemta-4.messagelabs.com id
	84/F4-17938-57403EF4; Thu, 21 Jun 2012 11:24:37 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340277823!10251924!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24026 invoked from network); 21 Jun 2012 11:23:44 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-10.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 11:23:44 -0000
Received: from mail110-ch1-R.bigfish.com (10.43.68.226) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:22:16 +0000
Received: from mail110-ch1 (localhost [127.0.0.1])	by
	mail110-ch1-R.bigfish.com (Postfix) with ESMTP id AFF0F4000E2;
	Thu, 21 Jun 2012 11:22:16 +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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail110-ch1 (localhost.localdomain [127.0.0.1]) by mail110-ch1
	(MessageSwitch) id 134027773587667_28119;
	Thu, 21 Jun 2012 11:22:15 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.231])	by mail110-ch1.bigfish.com (Postfix) with ESMTP id
	086BB80045;	Thu, 21 Jun 2012 11:22:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:22:14 +0000
X-WSS-ID: 0M5YSZD-02-4VO-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 217E2C8006;	Thu, 21 Jun 2012 06:23:36 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 06:23:53 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 06:23:37 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	07:23:36 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 10B0649C69D; Thu, 21 Jun 2012
	12:23:35 +0100 (BST)
Message-ID: <4FE303C4.3060705@amd.com>
Date: Thu, 21 Jun 2012 13:21:40 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
In-Reply-To: <4FE30CBB020000780008B06B@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 11:59 AM, Jan Beulich wrote:
>>>> On 14.06.12 at 17:15, Wei Wang<wei.wang2@amd.com>  wrote:
>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>> Have you at all considered getting this fixed on the kernel side?
>>> As I don't have direct access to any AMD IOMMU capable
>>> system - can one, other than by enumerating the respective
>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>> devices in question (e.g. via vendor/class/sub-class or some
>>> such)? That might permit skipping those in the offending kernel
>>> code...
>>
>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral)
>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this
>> should be enough to identify amd iommu device. I could send you a kernel
>> patch for review using this approach. I would believe that fixing this
>> issue in 4.2, no matter how, is really important for amd iommu.
>
> As you didn't come forward with anything, here's my first
> take on this:

Hi Jan
Thanks a lot for the patch. Actually I plan to send my version today, 
which is based on 3.4 pv_ops but looks very similar to yours. So, Acked!

I also evaluated the possibility of hiding iommu device from dom0. I 
think the change is no quite a lot, at least, for io based pcicfg 
access. A proof-of-concept patch is attached.

Thanks,
Wei

diff -r baa85434d0ec xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c      Thu Jun 21 11:30:59 2012 +0200
+++ b/xen/arch/x86/traps.c      Thu Jun 21 13:19:02 2012 +0200
@@ -73,6 +73,7 @@
  #include <asm/hpet.h>
  #include <public/arch-x86/cpuid.h>
  #include <xsm/xsm.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>

  /*
   * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
@@ -1686,10 +1687,19 @@ static int pci_cfg_ok(struct domain *d,
  {
      uint32_t machine_bdf;
      uint16_t start, end;
+    struct amd_iommu *iommu;
+
      if (!IS_PRIV(d))
          return 0;

      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
+
+    for_each_amd_iommu ( iommu )
+    {
+        if ( machine_bdf == iommu->bdf )
+            return 0;
+    }
+
      start = d->arch.pci_cf8 & 0xFF;
      end = start + size - 1;
      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))

>
> Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
> interrupts when we initialize a pci device") caused MSI to get disabled
> on Xen Dom0 despite it having got turned on purposefully by the
> hypervisor. As an immediate band aid, suppress the disabling in this
> specific case.
>
> I don't think, however, that either the original change or this fix are
> really appropriate. The original fix, besides leaving aside the
> presence of a hypervisor like Xen, doesn't deal with all possible
> cases (in particular it has no effect if the secondary kernel was built
> with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
> Xen, the logic like this should probably be skipped altogether (i.e. it
> should be entirely left to the hypervisor, being the entity in control
> of IRQs).
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Cc: stable@kernel.org
>
> ---
>   drivers/pci/msi.c       |    7 +++++++
>   include/linux/pci_ids.h |    1 +
>   2 files changed, 8 insertions(+)
>
> --- 3.5-rc3/drivers/pci/msi.c
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/drivers/pci/msi.c
> @@ -20,6 +20,7 @@
>   #include<linux/errno.h>
>   #include<linux/io.h>
>   #include<linux/slab.h>
> +#include<xen/xen.h>
>
>   #include "pci.h"
>   #include "msi.h"
> @@ -1022,7 +1023,13 @@ void pci_msi_init_pci_dev(struct pci_dev
>   	/* Disable the msi hardware to avoid screaming interrupts
>   	 * during boot.  This is the power on reset default so
>   	 * usually this should be a noop.
> +	 * But on a Xen host don't do this for IOMMUs which the hypervisor
> +	 * is in control of (and hence has already enabled on purpose).
>   	 */
> +	if (xen_initial_domain()
> +	&&  (dev->class>>  8) == PCI_CLASS_SYSTEM_IOMMU
> +	&&  dev->vendor == PCI_VENDOR_ID_AMD)
> +		return;
>   	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
>   	if (pos)
>   		msi_set_enable(dev, pos, 0);
> --- 3.5-rc3/include/linux/pci_ids.h
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/include/linux/pci_ids.h
> @@ -75,6 +75,7 @@
>   #define PCI_CLASS_SYSTEM_RTC		0x0803
>   #define PCI_CLASS_SYSTEM_PCI_HOTPLUG	0x0804
>   #define PCI_CLASS_SYSTEM_SDHCI		0x0805
> +#define PCI_CLASS_SYSTEM_IOMMU		0x0806
>   #define PCI_CLASS_SYSTEM_OTHER		0x0880
>
>   #define PCI_BASE_CLASS_INPUT		0x09
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:25:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShfV9-0005uF-2A; Thu, 21 Jun 2012 11:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShfV8-0005uA-5u
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 11:24:38 +0000
Received: from [85.158.143.35:64206] by server-2.bemta-4.messagelabs.com id
	84/F4-17938-57403EF4; Thu, 21 Jun 2012 11:24:37 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340277823!10251924!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24026 invoked from network); 21 Jun 2012 11:23:44 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-10.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 11:23:44 -0000
Received: from mail110-ch1-R.bigfish.com (10.43.68.226) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:22:16 +0000
Received: from mail110-ch1 (localhost [127.0.0.1])	by
	mail110-ch1-R.bigfish.com (Postfix) with ESMTP id AFF0F4000E2;
	Thu, 21 Jun 2012 11:22:16 +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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail110-ch1 (localhost.localdomain [127.0.0.1]) by mail110-ch1
	(MessageSwitch) id 134027773587667_28119;
	Thu, 21 Jun 2012 11:22:15 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.231])	by mail110-ch1.bigfish.com (Postfix) with ESMTP id
	086BB80045;	Thu, 21 Jun 2012 11:22:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:22:14 +0000
X-WSS-ID: 0M5YSZD-02-4VO-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 217E2C8006;	Thu, 21 Jun 2012 06:23:36 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 06:23:53 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 06:23:37 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	07:23:36 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 10B0649C69D; Thu, 21 Jun 2012
	12:23:35 +0100 (BST)
Message-ID: <4FE303C4.3060705@amd.com>
Date: Thu, 21 Jun 2012 13:21:40 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
In-Reply-To: <4FE30CBB020000780008B06B@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 11:59 AM, Jan Beulich wrote:
>>>> On 14.06.12 at 17:15, Wei Wang<wei.wang2@amd.com>  wrote:
>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>> Have you at all considered getting this fixed on the kernel side?
>>> As I don't have direct access to any AMD IOMMU capable
>>> system - can one, other than by enumerating the respective
>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>> devices in question (e.g. via vendor/class/sub-class or some
>>> such)? That might permit skipping those in the offending kernel
>>> code...
>>
>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral)
>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this
>> should be enough to identify amd iommu device. I could send you a kernel
>> patch for review using this approach. I would believe that fixing this
>> issue in 4.2, no matter how, is really important for amd iommu.
>
> As you didn't come forward with anything, here's my first
> take on this:

Hi Jan
Thanks a lot for the patch. Actually I plan to send my version today, 
which is based on 3.4 pv_ops but looks very similar to yours. So, Acked!

I also evaluated the possibility of hiding iommu device from dom0. I 
think the change is no quite a lot, at least, for io based pcicfg 
access. A proof-of-concept patch is attached.

Thanks,
Wei

diff -r baa85434d0ec xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c      Thu Jun 21 11:30:59 2012 +0200
+++ b/xen/arch/x86/traps.c      Thu Jun 21 13:19:02 2012 +0200
@@ -73,6 +73,7 @@
  #include <asm/hpet.h>
  #include <public/arch-x86/cpuid.h>
  #include <xsm/xsm.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>

  /*
   * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
@@ -1686,10 +1687,19 @@ static int pci_cfg_ok(struct domain *d,
  {
      uint32_t machine_bdf;
      uint16_t start, end;
+    struct amd_iommu *iommu;
+
      if (!IS_PRIV(d))
          return 0;

      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
+
+    for_each_amd_iommu ( iommu )
+    {
+        if ( machine_bdf == iommu->bdf )
+            return 0;
+    }
+
      start = d->arch.pci_cf8 & 0xFF;
      end = start + size - 1;
      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))

>
> Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
> interrupts when we initialize a pci device") caused MSI to get disabled
> on Xen Dom0 despite it having got turned on purposefully by the
> hypervisor. As an immediate band aid, suppress the disabling in this
> specific case.
>
> I don't think, however, that either the original change or this fix are
> really appropriate. The original fix, besides leaving aside the
> presence of a hypervisor like Xen, doesn't deal with all possible
> cases (in particular it has no effect if the secondary kernel was built
> with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
> Xen, the logic like this should probably be skipped altogether (i.e. it
> should be entirely left to the hypervisor, being the entity in control
> of IRQs).
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Cc: stable@kernel.org
>
> ---
>   drivers/pci/msi.c       |    7 +++++++
>   include/linux/pci_ids.h |    1 +
>   2 files changed, 8 insertions(+)
>
> --- 3.5-rc3/drivers/pci/msi.c
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/drivers/pci/msi.c
> @@ -20,6 +20,7 @@
>   #include<linux/errno.h>
>   #include<linux/io.h>
>   #include<linux/slab.h>
> +#include<xen/xen.h>
>
>   #include "pci.h"
>   #include "msi.h"
> @@ -1022,7 +1023,13 @@ void pci_msi_init_pci_dev(struct pci_dev
>   	/* Disable the msi hardware to avoid screaming interrupts
>   	 * during boot.  This is the power on reset default so
>   	 * usually this should be a noop.
> +	 * But on a Xen host don't do this for IOMMUs which the hypervisor
> +	 * is in control of (and hence has already enabled on purpose).
>   	 */
> +	if (xen_initial_domain()
> +	&&  (dev->class>>  8) == PCI_CLASS_SYSTEM_IOMMU
> +	&&  dev->vendor == PCI_VENDOR_ID_AMD)
> +		return;
>   	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
>   	if (pos)
>   		msi_set_enable(dev, pos, 0);
> --- 3.5-rc3/include/linux/pci_ids.h
> +++ 3.5-rc3-xen-pci-msi-no-iommu-disable/include/linux/pci_ids.h
> @@ -75,6 +75,7 @@
>   #define PCI_CLASS_SYSTEM_RTC		0x0803
>   #define PCI_CLASS_SYSTEM_PCI_HOTPLUG	0x0804
>   #define PCI_CLASS_SYSTEM_SDHCI		0x0805
> +#define PCI_CLASS_SYSTEM_IOMMU		0x0806
>   #define PCI_CLASS_SYSTEM_OTHER		0x0880
>
>   #define PCI_BASE_CLASS_INPUT		0x09
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:41:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shfkc-0006A5-Iy; Thu, 21 Jun 2012 11:40: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 1Shfkb-0006A0-8F
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:40:37 +0000
Received: from [193.109.254.147:13820] by server-5.bemta-14.messagelabs.com id
	FE/4F-04343-43803EF4; Thu, 21 Jun 2012 11:40:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340278833!10794962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15144 invoked from network); 21 Jun 2012 11:40:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:40:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:40:33 +0100
Message-ID: <1340278832.21872.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 12:40:32 +0100
In-Reply-To: <81f18379bb3d4d9397d1.1339779876@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> If a domain does not have a VCPU affinity, try to pin it automatically to some
> PCPUs. This is done taking into account the NUMA characteristics of the host.
> In fact, we look for a combination of host's NUMA nodes with enough free memory
> and number of PCPUs for the new domain, and pin it to the VCPUs of those nodes.
> 
> Once we know which ones, among all the possible combinations, represents valid
> placement candidates for a domain, use some heuistics for deciding which is the

                                              heuristics

> best. For instance, smaller candidates are considered to be better, both from
> the domain's point of view (fewer memory spreading among nodes) and from the
> system as a whole point of view (fewer memoy fragmentation).  In case of

                                         memory

> candidates of equal sizes (i.e., with the same number of nodes), the one with
> the greater amount of memory wins, as this is also good for keeping memory
> fragmentation under control.
> 
> This all happens internally to libxl, and no API for driving the mechanism is
> provided for now. This matches what xend already does.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * This patches incorporates the changes from both "libxl, xl: enable automatic
>    placement of guests on NUMA nodes" and "libxl, xl: heuristics for reordering
>    NUMA placement candidates" from v1.
>  * The logic of the algorithm is basically the same as in v1, but the splitting
>    of it in the various functions has been completely redesigned from scratch.
>  * No public API for placement or candidate generation is now exposed,
>    everything happens within libxl, as agreed during v1 review.
>  * The relevant documentation have been moved near the actual functions and
>    features. Also, the amount and (hopefully!) the quality of the documentation
>    has been improved a lot, as requested.
>  * All the comments about using the proper libxl facilities and helpers for
>    allocations, etc., have been considered and applied.
>  * This patch still bails out from NUMA optimizations if it find out cpupools
>    are being utilized. It is next patch that makes the two things interact
>    properly, as suggested during review.
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -111,8 +111,8 @@ created online and the remainder will be
> 
>  =item B<cpus="CPU-LIST">
> 
> -List of which cpus the guest is allowed to use. Default behavior is

There is (according to grep) a slight preference for British spelling,
but I imagine we are totally inconsistent all over the place so lets not
worry too much ;-)

> -`all cpus`. A C<CPU-LIST> may be specified as follows:
> +List of which cpus the guest is allowed to use. By default xl will (via
> +libxl) pick some cpus (see below). A C<CPU-LIST> may be specified as follows:
> 
>  =over 4
> 
> @@ -132,6 +132,12 @@ run on cpu #3 of the host.
> 
>  =back
> 
> +If this option is not specified, libxl automatically tries to place the new
> +domain on the host's NUMA nodes (provided the host has more than one NUMA
> +node) by pinning it to the cpus of those nodes. An heuristical approach is

I don't think heuristical is a word, I think "A heuristic approach..."
is fine

(not sure about "A heuristic" vs "An heuristic" but A sounds more
natural to me, generally the rule is An before "vowel sounds" so I guess
it depends on how you pronounce the h in heuristic, which varies even
depending on which bit of England you are from ;-))

> +utilized with the goals of maximizing performance for the domain and, at
> +the same time, achieving efficient utilization of the host's CPUs and RAM.
> +
>  =item B<cpu_weight=WEIGHT>
> 
>  A domain with a weight of 512 will get twice as much CPU as a domain
> 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

I think it would be quite reasonable for you to create a new
libxl_numa(_placement).c if you wanted too. likewise a libxl_numa.h
header. Up to you.

> @@ -95,6 +95,459 @@ out:
>      return sched;
>  }
> 
> +/*
> + * What follows are helpers for generating all the k-combinations
> + * without repetitions of a set S with n elements in it. Formally
> + * speaking, they are subsets of k distinct elements of S and, if
> + * S is n elements big, the number of k-combinations is equal to
> + * the binomial coefficient (n k), which means we get exactly
> + * n!/(k! * (n - k)!) subsets, all of them with k elements.
> + *
> + * The various subset are geneated one after the other by calling

                            generated

> + * comb_init() first, and, after that, comb_next()
> + * (n k)-1 times. An iterator is used to store the curent status

                                                      current

> + * of the whole generation operation (i.e., basically, the last
> + * combination that has been generated). As soon as all
> + * combinations have been generated, comb_next() will
> + * start returning 0 instead of 1. It is of course impotant that

                                                      important

> + * the same instance of the iterator and the same values for
> + * n and k are used for each call. If that doesn't happen, the
> + * result is unspecified.
> + *
> + * The algorithm is a well known one,

Worth a link/reference?

>  and it produces the
> + * combinations in such a way that they (well, more precisely,
> + * their indexes it the array/map representing the set) come in
> + * lexicogaphic order.

      lexicographic

> + *
> + * For example, with n = 5 and k = 3, calling comb_init()
> + * will generate { 0, 1, 2 }, while subsequent valid calls to
> + * comb_next() will produce the following:
> + * { { 0, 1, 2 }, { 0, 1, 3 }, { 0, 1, 4 },

                ^ strictly speaking this 0,1,2 isn't produced by a call
                to comb_next since it came from the initial comb_init,
                right? IOW the first comb_next() call won't duplicate
                it...

I'm not going to try very hard to review the algorithm here, I trust you
and I've got a head cold ;-)

> + *   { 0, 2, 3 }, { 0, 2, 4 }, { 0, 3, 4 },
> + *   { 1, 2, 3 }, { 1, 2, 4 }, { 1, 3, 4 },
> + *   { 2, 3, 4 } }
> + *
> + * This is used by the automatic NUMA placement logic below.
> + */
> +typedef int* comb_iter_t;
> +
> +static int comb_init(libxl__gc *gc, comb_iter_t *it, int n, int k)
> +{
> +    comb_iter_t new_iter;
> +    int i;
> +
> +    if (n < k)
> +        return 0;
> +
> +    /* First set is always { 0, 1, 2, ..., k-1 } */
> +    GCNEW_ARRAY(new_iter, k);
> +    for (i = 0; i < k; i++)
> +        new_iter[i] = i;
> +
> +    *it = new_iter;
> +    return 1;
> +}
> +
> +static int comb_next(comb_iter_t it, int n, int k)
> +{
> +    int i;
> +
> +    /*
> +     * The idea here is to find the leftmost element from where
> +     * we should start incrementing the indexes of the iterator.
> +     * This means looking for the highest index that can be increased
> +     * while still producing value smaller than n-1. In the example
> +     * above, when dealing with { 0, 1, 4 }, such an element is the
> +     * second one, as the third is already equal to 4 (which actually
> +     * is n-1).
> +     * Once we found from where to start, we increment that element
> +     * and overide the right-hand rest of the iterator with its

              override

> +     * successors, thus achieving lexicographic ordering.
> +     *
> +     * Regarding the termination of the generation process, when we
> +     * manage in bringing n-k at the very first position of the iterator,
> +     * we know that is the last valid combination ( { 2, 3, 4 }, with
> +     * n - k = 5 - 2 = 2, in the example above), and thus we start
> +     * returning 0 as soon as we cross that border.
> +     */
> +    for (i = k - 1; it[i] == n - k + i; i--) {
> +        if (i <= 0)
> +            return 0;
> +    }
> +    for (it[i]++, i++; i < k; i++)
> +        it[i] = it[i - 1] + 1;
> +    return 1;
> +}
> +
> +/* NUMA automatic placement (see libxl_internal.h for details) */
> +
> +/*
> + * This function turns a k-combination iterator into a node map.
> + * This means the bits in the node map corresponding to the indexes
> + * of the given combination are the ones that will be set.
> + * For example, if the iterator represents the combination { 0, 2, 4},
> + * the node map will have bits #0, #2 and #4 set to one and i thus
> + * will point to node 0, node 2 and and node 4.

What is "i" in this last bit ("i thus will point to")? I don't think you
are referring to the loop iterator variable.

If you meant "it" then I don't think it needs saying that a node map
with bits 0, 2 and 4 set refers to nodes 0, 2 and 4.

> + */
> +static void comb_get_nodemap(comb_iter_t it, libxl_bitmap *nodemap, int k)
> +{
> +    int i;
> +
> +    libxl_bitmap_set_none(nodemap);
> +    for (i = 0; i < k; i++)
> +        libxl_bitmap_set(nodemap, it[i]);
> +}
> +
> +/* Retrieve the number of cpus that the nodes that are part of the nodemap
> + * span. */
> +static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
> +                                 const libxl_bitmap *nodemap)

nodes here == node's ? But can't have an apostrophe in a function which
makes it ready weird to me. Perhaps "nodemap_count_cpus"?

> +{
> +    int i, nodes_cpus = 0;
> +
> +    for (i = 0; i < nr_cpus; i++) {
> +        if (libxl_bitmap_test(nodemap, tinfo[i].node))
> +            nodes_cpus++;
> +    }
> +    return nodes_cpus;
> +}
> +
[...]
> +/* Retrieve the number of domains that can potentially run on the cpus
> + * the nodes that are part of the nodemap. */
> +static int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tinfo,
> +                                 const libxl_bitmap *nodemap)
> +{
> +    libxl_dominfo *dinfo = NULL;
> +    libxl_bitmap dom_nodemap;
> +    int nr_doms, nr_cpus;
> +    int nr_domains = 0;
> +    int i, j, k;
> +
> +    dinfo = libxl_list_domain(CTX, &nr_doms);
> +    if (dinfo == NULL)
> +        return ERROR_FAIL;
> +
> +    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap) < 0) {
> +        nr_domains = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    for (i = 0; i < nr_doms; i++) {
> +        libxl_vcpuinfo *vinfo;
> +        int nr_vcpus;
> +
> +        vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_cpus);
> +        if (vinfo == NULL)
> +            continue;
> +
> +        libxl_bitmap_set_none(&dom_nodemap);
> +        for (j = 0; j < nr_vcpus; j++) {
> +            libxl_for_each_set_bit(k, vinfo[j].cpumap)
> +                libxl_bitmap_set(&dom_nodemap, tinfo[k].node);
> +        }
> +
> +        libxl_for_each_set_bit(j, dom_nodemap) {
> +            if (libxl_bitmap_test(nodemap, j)) {
> +                nr_domains++;
> +                goto found;

AKA break?

> +            }
> +        }
> + found:
> +        libxl_vcpuinfo_list_free(vinfo, nr_vcpus);
> +    }
> +
> + out:
> +    libxl_bitmap_dispose(&dom_nodemap);

You can come to out if libxl_nodebitmap_alloc fails -- in which case
dom_nodemap is (potentially) uninitialised.

You could just move out: down a line.

Otherwise we'd need libxl_bitmap_init which zeroes everything such that
calling dispose is safe even if you don't call alloc. I don't mind
which.

> +    libxl_dominfo_list_free(dinfo, nr_doms);
> +    return nr_domains;
> +}
> +
> +/*
> + * This function tries to figure out if the host has a consistent number
> + * of cpus along all its NUMA nodes. In fact, if that is the case, we can
> + * calculate the minimum number of nodes needed for a domain by just
> + * dividing its total number of vcpus by this value computed here.
> + * However, we are not allowed to assume that all the nodes have the
> + * same number of cpus. Therefore, in case discrepancies among different
> + * nodes are found, this function just returns 0 and the caller needs
> + * to sort out things in some other way.

If the caller has to deal with this anyway why bother with this check
and/or the other algorithm?

> + */
> +static int cpus_per_node_count(libxl_cputopology *tinfo, int nr_cpus,
> +                               libxl_numainfo *ninfo, int nr_nodes)
> +{
> +    int cpus_per_node = 0;
> +    int j, i;
> +
> +    /* This makes sense iff # of PCPUs is the same for all nodes */
> +    for (j = 0; j < nr_nodes; j++) {
> +        int curr_cpus = 0;
> +
> +        for (i = 0; i < nr_cpus; i++) {
> +            if (tinfo[i].node == j)
> +                curr_cpus++;
> +        }
> +        /* So, if the above does not hold, turn the whole thing off! */
> +        cpus_per_node = cpus_per_node == 0 ? curr_cpus : cpus_per_node;
> +        if (cpus_per_node != curr_cpus)
> +            return 0;
> +    }
> +    return cpus_per_node;
> +}
> +
> +/* Get all the placement candidates satisfying some specific conditions */
> +int libxl__get_numa_candidates(libxl__gc *gc,
> +                               uint32_t min_free_memkb, int min_cpus,
> +                               int min_nodes, int max_nodes,
> +                               libxl__numa_candidate *cndts[], int *nr_cndts)
> +{
> +    libxl__numa_candidate *new_cndts = NULL;
> +    libxl_cputopology *tinfo = NULL;
> +    libxl_numainfo *ninfo = NULL;
> +    libxl_bitmap nodemap;
> +    int nr_nodes, nr_cpus;
> +    int array_size, rc;
> +
> +    /* Get platform info and prepare the map for testing the combinations */
> +    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
> +    if (ninfo == NULL)
> +        return ERROR_FAIL;
> +    /* If we don't have at least 2 nodes, it is useless to proceed */

You don't want to return whichever of those 2 nodes meets the
constraints?

> +    if (nr_nodes < 2) {
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus);
> +    if (tinfo == NULL) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    rc = libxl_node_bitmap_alloc(CTX, &nodemap);
> +    if (rc)
> +        goto out;
> +
> +    /*
> +     * Round up and down some of the constraints. For instance, the minimum
> +     * number of cpus a candidate should have must at least be non-negative.
> +     * Regarding the minimum number of NUMA nodes, if 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
> +     * from 1 otherwise). The maximum number of nodes should not exceed the
> +     * number of existent NUMA nodes on the host, or the candidate genaration

                                                                     generation

> +     * won't work properly.
> +     */
> +    min_cpus = min_cpus <= 0 ? 0 : min_cpus;
> +    if (min_nodes <= 0) {
> +        int cpus_per_node;
> +
> +        cpus_per_node = cpus_per_node_count(tinfo, nr_cpus, ninfo, nr_nodes);
> +        if (cpus_per_node == 0)
> +            min_nodes = 1;
> +        else
> +            min_nodes = (min_cpus + cpus_per_node - 1) / cpus_per_node;
> +    }
> +    min_nodes = min_nodes > nr_nodes ? nr_nodes : min_nodes;
> +    if (max_nodes <= 0)
> +        max_nodes = nr_nodes;
> +    else
> +        max_nodes = max_nodes > nr_nodes ? nr_nodes : max_nodes;
> +    if (min_nodes > max_nodes) {
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +
> +    /* Initialize the local storage for the combinations */
> +    *nr_cndts = 0;
> +    array_size = nr_nodes;
> +    GCNEW_ARRAY(new_cndts, array_size);
> +
> +    /* Generate all the combinations of any size from min_nodes to
> +     * max_nodes (see comb_init() and comb_next()). */
> +    while (min_nodes <= max_nodes) {
> +        comb_iter_t comb_iter;
> +        int comb_ok;
> +
> +        /*
> +        * And here it is. Each step of this cycle generates a combination of
> +        * nodes as big as min_nodes mandates.  Each of these combinations is
> +        * checked against the constraints provided by the caller (namely,
> +        * amount of free memory and number of cpus) and it becomes an actual
> +        * placement candidate iff it passes the check.
> +         */
> +        for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
> +             comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
> +            uint32_t nodes_free_memkb;
> +            int nodes_cpus;
> +
> +            comb_get_nodemap(comb_iter, &nodemap, min_nodes);
> +
> +            /* If there is not enough memoy in this combination, skip it

                                        memory

> +             * and go generating the next one... */
> +            nodes_free_memkb = nodemap_to_free_memkb(ninfo, &nodemap);
> +            if (min_free_memkb > 0 && nodes_free_memkb < min_free_memkb)
> +                continue;
> +
> +            /* And the same applies if this combination is short in cpus */
> +            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
> +            if (min_cpus > 0 && nodes_cpus < min_cpus)
> +                continue;
> +
> +            /*
> +             * Conditions are met, we can add this combination to the
> +             * NUMA placement candidates list. We first make sure there
> +             * is enough space in there, and then we initialize the new
> +             * candidate element with the node map corresponding to the
> +             * combination we are dealing with. Memory allocation for
> +             * expanding the array that hosts the list happens in chunks
> +             * equal to the number of NUMA nodes in the system (to
> +             * avoid allocating memory each and every time we find a
> +             * new candidate).
> +             */
> +            if (*nr_cndts == array_size)
> +                array_size += nr_nodes;
> +            GCREALLOC_ARRAY(new_cndts, array_size);
> +
> +            libxl__numa_candidate_alloc(gc, &new_cndts[*nr_cndts]);
> +            libxl__numa_candidate_put_nodemap(gc, &new_cndts[*nr_cndts],
> +                                              &nodemap);
> +            new_cndts[*nr_cndts].nr_domains =
> +                                    nodemap_to_nr_domains(gc, tinfo, &nodemap);
> +            new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
> +            new_cndts[*nr_cndts].nr_nodes = min_nodes;
> +            new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
> +
> +            LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
> +                       "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
> +                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
> +                       new_cndts[*nr_cndts].free_memkb / 1024);
> +
> +            (*nr_cndts)++;
> +        }
> +        min_nodes++;
> +    }
> +
> +    *cndts = new_cndts;
> + out:
> +    libxl_bitmap_dispose(&nodemap);

nodemap might not have been initialised?

> +    libxl_cputopology_list_free(tinfo, nr_cpus);
> +    libxl_numainfo_list_free(ninfo, nr_nodes);

It looks like the nr_* may also not have been initialised, but maybe
list_free is safe in that case since the associated array must
necessarily be NULL?

> +    return rc;
> +}
> +
> +void libxl__sort_numa_candidates(libxl__numa_candidate cndts[], int nr_cndts,
> +                                 libxl__numa_candidate_cmpf cmpf)
> +{
> +    /* Reorder candidates (see the comparison function for
> +     * the details on the heuristics) */
> +    qsort(cndts, nr_cndts, sizeof(cndts[0]), cmpf);
> +}
> +
> +/*
> + * The NUMA placement candidates are reordered according to the following
> + * heuristics:
> + *  - candidates involving fewer nodes come first. In case two (or
> + *    more) candidates span the same number of nodes,
> + *  - candidates with greater amount of free memory come first. In
> + *    case two (or more) candidates differ in their amount of free
> + *    memory by less than 10%,
> + *  - candidates with fewer domains insisting on them at the time of
> + *    this call come first.
> + */
> +static int numa_cmpf(const void *v1, const void *v2)
> +{
> +    const libxl__numa_candidate *c1 = (const libxl__numa_candidate*) v1;
> +    const libxl__numa_candidate *c2 = (const libxl__numa_candidate*) v2;

Are these casts necessary?

> +    double mem_diff = labs(c1->free_memkb - c2->free_memkb);
> +    double mem_avg = (c1->free_memkb + c2->free_memkb) / 2.0;
> +
> +    if (c1->nr_nodes != c2->nr_nodes)
> +        return c1->nr_nodes - c2->nr_nodes;
> +
> +    if ((mem_diff / mem_avg) * 100.0 < 10.0 &&

Is all this FP math necessary? Using integers might have some rounding
but is it significant or do we care if it gets it slightly wrong?

> +        c1->nr_domains != c2->nr_domains)
> +        return c1->nr_domains - c2->nr_domains;
> +
> +    return c2->free_memkb - c1->free_memkb;
> +}
> +
> +/* The actual automatic NUMA placement routine */
> +static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
> +{
> +    int nr_candidates = 0;
> +    libxl__numa_candidate *candidates = NULL;
> +    libxl_bitmap candidate_nodemap;
> +    libxl_cpupoolinfo *pinfo;
> +    int nr_pools, rc = 0;
> +    uint32_t memkb;
> +
> +    /* First of all, if cpupools are in use, better not to mess with them */
> +    pinfo = libxl_list_cpupool(CTX, &nr_pools);
> +    if (!pinfo)
> +        return ERROR_FAIL;
> +    if (nr_pools > 1) {
> +        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
> +        goto out;
> +    }
> +
> +    rc = libxl_domain_need_memory(CTX, info, &memkb);
> +    if (rc)
> +        goto out;
> +    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    /* Find all the candidates with enough free memory and at least
> +     * as much pcpus as the domain has vcpus.  */
> +    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
> +                                    &candidates, &nr_candidates);
> +    if (rc)
> +        goto out;
> +
> +    LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates);
> +
> +    /* No suitable placement candidates. We just return without touching the
> +     * domain's info->cpumap. It will have affinity with all nodes/cpus. */
> +    if (nr_candidates == 0)
> +        goto out;
> +
> +    /* Bring the best candidate in front of the list --> candidates[0] */
> +    if (nr_candidates > 1)
> +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);

Is the start up cost of libxl__sort_numa_candidates significant enough
to make that if worthwhile?

> +
> +    /*
> +     * At this point, the first candidate in the array is the one we want.
> +     * Go for it by mapping its node map to the domain's info->cpumap.
> +     */
> +    libxl__numa_candidate_get_nodemap(gc, &candidates[0], &candidate_nodemap);
> +    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
> +    if (rc)
> +        goto out;
> +
> +    LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
> +                "%"PRIu32" KB free selected", candidates[0].nr_nodes,
> +                candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
> +
> + out:
> +    libxl_bitmap_dispose(&candidate_nodemap);
> +    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
> +    return rc;
> +}
> +
>  int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>                libxl_domain_build_info *info, libxl__domain_build_state *state)
>  {
> @@ -104,7 +557,22 @@ int libxl__build_pre(libxl__gc *gc, uint
>      uint32_t rtc_timeoffset;
> 
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +
> +    /*
> +     * 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 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,
> +     * whatever that turns out to be.
> +     */
> +    if (libxl_bitmap_is_full(&info->cpumap)) {
> +        int rc = numa_place_domain(gc, info);
> +        if (rc)
> +            return rc;

I'm not sure about this, if numa_place_domain fails for any reason would
we be not better off logging and continuing without placement? We
already do that explicitly in a couple of cases.

> +    }
>      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,
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
>  #define CTX_LOCK (libxl__ctx_lock(CTX))
>  #define CTX_UNLOCK (libxl__ctx_unlock(CTX))
> 
> +/*
> + * Automatic NUMA placement
> + *
> + * These functions and data structures deal with the initial placement of a
> + * domain onto the host NUMA nodes.
> + *
> + * The key concept here is the one of "numa placement candidate" (or jusr "numa

                                                                        just

> + * candidate", "placement candidate" or even "candidate"), which basically is a

Do we really need that level of detail about what we might call it?
There's no minimum word limit you know ;-)

> + * set of nodes whose characteristics have been successfully checked against
> + * some specific requirements. More pecisely, a candidate is the nodemap

                                       precisely

> + * associated with one of the possible subset of the host NUMA nodes providing
> + * a certain amount of free memory, or a given number of cpus, or even both
> + * (depending in what the caller wants). For convenience of use, some of this
> + * information are stored within the candidate itselfs, instead of always being

                                                  itself

> + * dynamically computed. A candidate can consist of just one, up to all the
> + * available nodes on the host (the latter being, of course, not ideal).

I can't parse this sentence.

>   For
> + * instance, looking for a numa candidates with 2GB of free memoy means we want

                                                              memory

> + * all the possible subsets of the host NUMA nodes with, cumulatively, at least
> + * 2GB of free memory. That could be possible by just using one particular
> + * node, or may require more nodes, depending on the characteristics of the
> + * host, on how many domains have been created already, on how big they are,
> + * etc.
> + *
> + * The intended usage is as follows:
> + *  1. by, fist of all, calling libxl__get_numa_candidates(), and specifying
> + *     the proper constraints to it (e.g., the amount of memory a domain need
> + *     as the minimum amount of free memory fo the candidates) one can build

                                               for

> + *     up a whole set of suitable placing alternatives for a domain;
> + *  2. after that, one specific candidate should be chosen. That can happen
> + *     by looking at their various characteristics;
> + *  3. the chosen candidate's nodemap should be utilized for computing the
> + *     actual affinity of the domain which, given the curent NUMA support

                                                         current

> + *     in the hypervisor, is what determines the placement of the domain's
> + *     vcpus and memory.
> + *
> + * To make phase 2 even easier, a sorting helper function for the list of
> + * candidates is povided in the form of libxl__sort_numa_candidates(). The only

                    provided

> + * that is needed is defining a comparison function, containing the chriteria

                                                                       criteria

> + * for deciding, given two candidates, which one is 'better'. Depending on how
> + * the comparison function is defined, the best candidate (where, of course,
> + * best is defined with respect to the heuristics implemented in the comparison
> + * function itself, libxl__numa_candidate_cmpf()) could become the first o the

                                                                           or

> + * last element of the list.
> + *
> + * Summarizing, achieving automatic NUMA placement is just a matter of
> + * obtaining the list of suitable placement candidates, perhaps asking for each
> + * of them to provide at least the amount of memory the domain needs. After
> + * that just implement a comparison function by means of the various helpers
> + * retrieving the relevant information about the candidates themselves.
> + * Finally, call the sorting helper function and use the candidate that became
> + * (typically) the first element of the list fo determining the domain's

                                               for

> + * affinity.
> + */
> +
> +typedef struct {
> +    int nr_cpus, nr_nodes;
> +    int nr_domains;
> +    uint32_t free_memkb;
> +    libxl_bitmap nodemap;
> +} libxl__numa_candidate;
> +
> +/*
> + * This generates the list of NUMA placement candidates satisfying some
> + * specific conditions. If min_nodes and/or max_nodes are not 0, their value is
> + * used to determine the minimum and maximum number of nodes that are allow to
> + * be present in each candidate. If min_nodes and/or max_nodes are 0, the
> + * minimum and maximum number of nodes to be used are automatically selected by
> + * the implementation (and that will likely be just 1 node for the minimum and
> + * the total number of existent nodes for the maximum). Re min_free_memkb and
> + * min_cpu, if not 0, they specify the caller only wants candidates with at
> + * least that amount of free memory and that number of cpus, respectively. If
> + * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
> + * of cpus won't be checked at all, which means a candidate will always be
> + * considered suitable wrt the specific constraint.  cndts is where the list of
> + * exactly nr_cndts candidates is returned. Note that, in case no candidates
> + * are found at all, the function returns successfully, but with nr_cndts equal
> + * to zero.
> + */
> +_hidden int libxl__get_numa_candidates(libxl__gc *gc,
> +                                uint32_t min_free_memkb, int min_cpus,
> +                                int min_nodes, int max_nodes,
> +                                libxl__numa_candidate *cndts[], int *nr_cndts);
> +
> +/* allocation and deallocation for placement candidates */
> +static inline int libxl__numa_candidate_alloc(libxl__gc *gc,
> +                                              libxl__numa_candidate *cndt)
> +{
> +    return libxl_node_bitmap_alloc(CTX, &cndt->nodemap);
> +}
> +static inline void libxl__numa_candidate_dispose(libxl__numa_candidate *cndt)
> +{
> +    libxl_bitmap_dispose(&cndt->nodemap);
> +}
> +static inline void libxl__numacandidate_list_free(libxl__numa_candidate *cndts,
> +                                                  int nr_cndts)
> +{
> +    int i;
> +
> +    for (i = 0; i < nr_cndts; i++)
> +        libxl__numa_candidate_dispose(&cndts[i]);
> +    free(cndts);
> +}
> +
> +/* retrieve (in nodemap) the node map associated to placement candidate cndt */
> +static inline
> +void libxl__numa_candidate_get_nodemap(libxl__gc *gc,
> +                                       const libxl__numa_candidate *cndt,
> +                                       libxl_bitmap *nodemap)
> +{
> +    libxl_bitmap_copy(CTX, nodemap, &cndt->nodemap);
> +}
> +/* set the node map of placement candidate cndt to match nodemap */
> +static inline
> +void libxl__numa_candidate_put_nodemap(libxl__gc *gc,
> +                                       libxl__numa_candidate *cndt,
> +                                       const libxl_bitmap *nodemap)
> +{
> +    libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap);
> +}
> +
> +/* signature for the comparison function between two candidates c1 and c2
> + * (the thid parameter is provided to enable thread safety). */

           third

But there isn't actually a third parameter so it's a bit moot ;-)

> +typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2);
> +/* sort the list of candidates in cndts (an array with nr_cndts elements in
> + * it) using cmpf for comparing two candidates. Uses libc's qsort(). */
> +_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
> +                                         int nr_cndts,
> +                                         libxl__numa_candidate_cmpf cmpf);
> 
>  /*
>   * Inserts "elm_new" into the sorted list "head".



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:41:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shfkc-0006A5-Iy; Thu, 21 Jun 2012 11:40: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 1Shfkb-0006A0-8F
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:40:37 +0000
Received: from [193.109.254.147:13820] by server-5.bemta-14.messagelabs.com id
	FE/4F-04343-43803EF4; Thu, 21 Jun 2012 11:40:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340278833!10794962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15144 invoked from network); 21 Jun 2012 11:40:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:40:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:40:33 +0100
Message-ID: <1340278832.21872.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 12:40:32 +0100
In-Reply-To: <81f18379bb3d4d9397d1.1339779876@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> If a domain does not have a VCPU affinity, try to pin it automatically to some
> PCPUs. This is done taking into account the NUMA characteristics of the host.
> In fact, we look for a combination of host's NUMA nodes with enough free memory
> and number of PCPUs for the new domain, and pin it to the VCPUs of those nodes.
> 
> Once we know which ones, among all the possible combinations, represents valid
> placement candidates for a domain, use some heuistics for deciding which is the

                                              heuristics

> best. For instance, smaller candidates are considered to be better, both from
> the domain's point of view (fewer memory spreading among nodes) and from the
> system as a whole point of view (fewer memoy fragmentation).  In case of

                                         memory

> candidates of equal sizes (i.e., with the same number of nodes), the one with
> the greater amount of memory wins, as this is also good for keeping memory
> fragmentation under control.
> 
> This all happens internally to libxl, and no API for driving the mechanism is
> provided for now. This matches what xend already does.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * This patches incorporates the changes from both "libxl, xl: enable automatic
>    placement of guests on NUMA nodes" and "libxl, xl: heuristics for reordering
>    NUMA placement candidates" from v1.
>  * The logic of the algorithm is basically the same as in v1, but the splitting
>    of it in the various functions has been completely redesigned from scratch.
>  * No public API for placement or candidate generation is now exposed,
>    everything happens within libxl, as agreed during v1 review.
>  * The relevant documentation have been moved near the actual functions and
>    features. Also, the amount and (hopefully!) the quality of the documentation
>    has been improved a lot, as requested.
>  * All the comments about using the proper libxl facilities and helpers for
>    allocations, etc., have been considered and applied.
>  * This patch still bails out from NUMA optimizations if it find out cpupools
>    are being utilized. It is next patch that makes the two things interact
>    properly, as suggested during review.
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -111,8 +111,8 @@ created online and the remainder will be
> 
>  =item B<cpus="CPU-LIST">
> 
> -List of which cpus the guest is allowed to use. Default behavior is

There is (according to grep) a slight preference for British spelling,
but I imagine we are totally inconsistent all over the place so lets not
worry too much ;-)

> -`all cpus`. A C<CPU-LIST> may be specified as follows:
> +List of which cpus the guest is allowed to use. By default xl will (via
> +libxl) pick some cpus (see below). A C<CPU-LIST> may be specified as follows:
> 
>  =over 4
> 
> @@ -132,6 +132,12 @@ run on cpu #3 of the host.
> 
>  =back
> 
> +If this option is not specified, libxl automatically tries to place the new
> +domain on the host's NUMA nodes (provided the host has more than one NUMA
> +node) by pinning it to the cpus of those nodes. An heuristical approach is

I don't think heuristical is a word, I think "A heuristic approach..."
is fine

(not sure about "A heuristic" vs "An heuristic" but A sounds more
natural to me, generally the rule is An before "vowel sounds" so I guess
it depends on how you pronounce the h in heuristic, which varies even
depending on which bit of England you are from ;-))

> +utilized with the goals of maximizing performance for the domain and, at
> +the same time, achieving efficient utilization of the host's CPUs and RAM.
> +
>  =item B<cpu_weight=WEIGHT>
> 
>  A domain with a weight of 512 will get twice as much CPU as a domain
> 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

I think it would be quite reasonable for you to create a new
libxl_numa(_placement).c if you wanted too. likewise a libxl_numa.h
header. Up to you.

> @@ -95,6 +95,459 @@ out:
>      return sched;
>  }
> 
> +/*
> + * What follows are helpers for generating all the k-combinations
> + * without repetitions of a set S with n elements in it. Formally
> + * speaking, they are subsets of k distinct elements of S and, if
> + * S is n elements big, the number of k-combinations is equal to
> + * the binomial coefficient (n k), which means we get exactly
> + * n!/(k! * (n - k)!) subsets, all of them with k elements.
> + *
> + * The various subset are geneated one after the other by calling

                            generated

> + * comb_init() first, and, after that, comb_next()
> + * (n k)-1 times. An iterator is used to store the curent status

                                                      current

> + * of the whole generation operation (i.e., basically, the last
> + * combination that has been generated). As soon as all
> + * combinations have been generated, comb_next() will
> + * start returning 0 instead of 1. It is of course impotant that

                                                      important

> + * the same instance of the iterator and the same values for
> + * n and k are used for each call. If that doesn't happen, the
> + * result is unspecified.
> + *
> + * The algorithm is a well known one,

Worth a link/reference?

>  and it produces the
> + * combinations in such a way that they (well, more precisely,
> + * their indexes it the array/map representing the set) come in
> + * lexicogaphic order.

      lexicographic

> + *
> + * For example, with n = 5 and k = 3, calling comb_init()
> + * will generate { 0, 1, 2 }, while subsequent valid calls to
> + * comb_next() will produce the following:
> + * { { 0, 1, 2 }, { 0, 1, 3 }, { 0, 1, 4 },

                ^ strictly speaking this 0,1,2 isn't produced by a call
                to comb_next since it came from the initial comb_init,
                right? IOW the first comb_next() call won't duplicate
                it...

I'm not going to try very hard to review the algorithm here, I trust you
and I've got a head cold ;-)

> + *   { 0, 2, 3 }, { 0, 2, 4 }, { 0, 3, 4 },
> + *   { 1, 2, 3 }, { 1, 2, 4 }, { 1, 3, 4 },
> + *   { 2, 3, 4 } }
> + *
> + * This is used by the automatic NUMA placement logic below.
> + */
> +typedef int* comb_iter_t;
> +
> +static int comb_init(libxl__gc *gc, comb_iter_t *it, int n, int k)
> +{
> +    comb_iter_t new_iter;
> +    int i;
> +
> +    if (n < k)
> +        return 0;
> +
> +    /* First set is always { 0, 1, 2, ..., k-1 } */
> +    GCNEW_ARRAY(new_iter, k);
> +    for (i = 0; i < k; i++)
> +        new_iter[i] = i;
> +
> +    *it = new_iter;
> +    return 1;
> +}
> +
> +static int comb_next(comb_iter_t it, int n, int k)
> +{
> +    int i;
> +
> +    /*
> +     * The idea here is to find the leftmost element from where
> +     * we should start incrementing the indexes of the iterator.
> +     * This means looking for the highest index that can be increased
> +     * while still producing value smaller than n-1. In the example
> +     * above, when dealing with { 0, 1, 4 }, such an element is the
> +     * second one, as the third is already equal to 4 (which actually
> +     * is n-1).
> +     * Once we found from where to start, we increment that element
> +     * and overide the right-hand rest of the iterator with its

              override

> +     * successors, thus achieving lexicographic ordering.
> +     *
> +     * Regarding the termination of the generation process, when we
> +     * manage in bringing n-k at the very first position of the iterator,
> +     * we know that is the last valid combination ( { 2, 3, 4 }, with
> +     * n - k = 5 - 2 = 2, in the example above), and thus we start
> +     * returning 0 as soon as we cross that border.
> +     */
> +    for (i = k - 1; it[i] == n - k + i; i--) {
> +        if (i <= 0)
> +            return 0;
> +    }
> +    for (it[i]++, i++; i < k; i++)
> +        it[i] = it[i - 1] + 1;
> +    return 1;
> +}
> +
> +/* NUMA automatic placement (see libxl_internal.h for details) */
> +
> +/*
> + * This function turns a k-combination iterator into a node map.
> + * This means the bits in the node map corresponding to the indexes
> + * of the given combination are the ones that will be set.
> + * For example, if the iterator represents the combination { 0, 2, 4},
> + * the node map will have bits #0, #2 and #4 set to one and i thus
> + * will point to node 0, node 2 and and node 4.

What is "i" in this last bit ("i thus will point to")? I don't think you
are referring to the loop iterator variable.

If you meant "it" then I don't think it needs saying that a node map
with bits 0, 2 and 4 set refers to nodes 0, 2 and 4.

> + */
> +static void comb_get_nodemap(comb_iter_t it, libxl_bitmap *nodemap, int k)
> +{
> +    int i;
> +
> +    libxl_bitmap_set_none(nodemap);
> +    for (i = 0; i < k; i++)
> +        libxl_bitmap_set(nodemap, it[i]);
> +}
> +
> +/* Retrieve the number of cpus that the nodes that are part of the nodemap
> + * span. */
> +static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
> +                                 const libxl_bitmap *nodemap)

nodes here == node's ? But can't have an apostrophe in a function which
makes it ready weird to me. Perhaps "nodemap_count_cpus"?

> +{
> +    int i, nodes_cpus = 0;
> +
> +    for (i = 0; i < nr_cpus; i++) {
> +        if (libxl_bitmap_test(nodemap, tinfo[i].node))
> +            nodes_cpus++;
> +    }
> +    return nodes_cpus;
> +}
> +
[...]
> +/* Retrieve the number of domains that can potentially run on the cpus
> + * the nodes that are part of the nodemap. */
> +static int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tinfo,
> +                                 const libxl_bitmap *nodemap)
> +{
> +    libxl_dominfo *dinfo = NULL;
> +    libxl_bitmap dom_nodemap;
> +    int nr_doms, nr_cpus;
> +    int nr_domains = 0;
> +    int i, j, k;
> +
> +    dinfo = libxl_list_domain(CTX, &nr_doms);
> +    if (dinfo == NULL)
> +        return ERROR_FAIL;
> +
> +    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap) < 0) {
> +        nr_domains = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    for (i = 0; i < nr_doms; i++) {
> +        libxl_vcpuinfo *vinfo;
> +        int nr_vcpus;
> +
> +        vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_cpus);
> +        if (vinfo == NULL)
> +            continue;
> +
> +        libxl_bitmap_set_none(&dom_nodemap);
> +        for (j = 0; j < nr_vcpus; j++) {
> +            libxl_for_each_set_bit(k, vinfo[j].cpumap)
> +                libxl_bitmap_set(&dom_nodemap, tinfo[k].node);
> +        }
> +
> +        libxl_for_each_set_bit(j, dom_nodemap) {
> +            if (libxl_bitmap_test(nodemap, j)) {
> +                nr_domains++;
> +                goto found;

AKA break?

> +            }
> +        }
> + found:
> +        libxl_vcpuinfo_list_free(vinfo, nr_vcpus);
> +    }
> +
> + out:
> +    libxl_bitmap_dispose(&dom_nodemap);

You can come to out if libxl_nodebitmap_alloc fails -- in which case
dom_nodemap is (potentially) uninitialised.

You could just move out: down a line.

Otherwise we'd need libxl_bitmap_init which zeroes everything such that
calling dispose is safe even if you don't call alloc. I don't mind
which.

> +    libxl_dominfo_list_free(dinfo, nr_doms);
> +    return nr_domains;
> +}
> +
> +/*
> + * This function tries to figure out if the host has a consistent number
> + * of cpus along all its NUMA nodes. In fact, if that is the case, we can
> + * calculate the minimum number of nodes needed for a domain by just
> + * dividing its total number of vcpus by this value computed here.
> + * However, we are not allowed to assume that all the nodes have the
> + * same number of cpus. Therefore, in case discrepancies among different
> + * nodes are found, this function just returns 0 and the caller needs
> + * to sort out things in some other way.

If the caller has to deal with this anyway why bother with this check
and/or the other algorithm?

> + */
> +static int cpus_per_node_count(libxl_cputopology *tinfo, int nr_cpus,
> +                               libxl_numainfo *ninfo, int nr_nodes)
> +{
> +    int cpus_per_node = 0;
> +    int j, i;
> +
> +    /* This makes sense iff # of PCPUs is the same for all nodes */
> +    for (j = 0; j < nr_nodes; j++) {
> +        int curr_cpus = 0;
> +
> +        for (i = 0; i < nr_cpus; i++) {
> +            if (tinfo[i].node == j)
> +                curr_cpus++;
> +        }
> +        /* So, if the above does not hold, turn the whole thing off! */
> +        cpus_per_node = cpus_per_node == 0 ? curr_cpus : cpus_per_node;
> +        if (cpus_per_node != curr_cpus)
> +            return 0;
> +    }
> +    return cpus_per_node;
> +}
> +
> +/* Get all the placement candidates satisfying some specific conditions */
> +int libxl__get_numa_candidates(libxl__gc *gc,
> +                               uint32_t min_free_memkb, int min_cpus,
> +                               int min_nodes, int max_nodes,
> +                               libxl__numa_candidate *cndts[], int *nr_cndts)
> +{
> +    libxl__numa_candidate *new_cndts = NULL;
> +    libxl_cputopology *tinfo = NULL;
> +    libxl_numainfo *ninfo = NULL;
> +    libxl_bitmap nodemap;
> +    int nr_nodes, nr_cpus;
> +    int array_size, rc;
> +
> +    /* Get platform info and prepare the map for testing the combinations */
> +    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
> +    if (ninfo == NULL)
> +        return ERROR_FAIL;
> +    /* If we don't have at least 2 nodes, it is useless to proceed */

You don't want to return whichever of those 2 nodes meets the
constraints?

> +    if (nr_nodes < 2) {
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus);
> +    if (tinfo == NULL) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    rc = libxl_node_bitmap_alloc(CTX, &nodemap);
> +    if (rc)
> +        goto out;
> +
> +    /*
> +     * Round up and down some of the constraints. For instance, the minimum
> +     * number of cpus a candidate should have must at least be non-negative.
> +     * Regarding the minimum number of NUMA nodes, if 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
> +     * from 1 otherwise). The maximum number of nodes should not exceed the
> +     * number of existent NUMA nodes on the host, or the candidate genaration

                                                                     generation

> +     * won't work properly.
> +     */
> +    min_cpus = min_cpus <= 0 ? 0 : min_cpus;
> +    if (min_nodes <= 0) {
> +        int cpus_per_node;
> +
> +        cpus_per_node = cpus_per_node_count(tinfo, nr_cpus, ninfo, nr_nodes);
> +        if (cpus_per_node == 0)
> +            min_nodes = 1;
> +        else
> +            min_nodes = (min_cpus + cpus_per_node - 1) / cpus_per_node;
> +    }
> +    min_nodes = min_nodes > nr_nodes ? nr_nodes : min_nodes;
> +    if (max_nodes <= 0)
> +        max_nodes = nr_nodes;
> +    else
> +        max_nodes = max_nodes > nr_nodes ? nr_nodes : max_nodes;
> +    if (min_nodes > max_nodes) {
> +        rc = ERROR_INVAL;
> +        goto out;
> +    }
> +
> +    /* Initialize the local storage for the combinations */
> +    *nr_cndts = 0;
> +    array_size = nr_nodes;
> +    GCNEW_ARRAY(new_cndts, array_size);
> +
> +    /* Generate all the combinations of any size from min_nodes to
> +     * max_nodes (see comb_init() and comb_next()). */
> +    while (min_nodes <= max_nodes) {
> +        comb_iter_t comb_iter;
> +        int comb_ok;
> +
> +        /*
> +        * And here it is. Each step of this cycle generates a combination of
> +        * nodes as big as min_nodes mandates.  Each of these combinations is
> +        * checked against the constraints provided by the caller (namely,
> +        * amount of free memory and number of cpus) and it becomes an actual
> +        * placement candidate iff it passes the check.
> +         */
> +        for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
> +             comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
> +            uint32_t nodes_free_memkb;
> +            int nodes_cpus;
> +
> +            comb_get_nodemap(comb_iter, &nodemap, min_nodes);
> +
> +            /* If there is not enough memoy in this combination, skip it

                                        memory

> +             * and go generating the next one... */
> +            nodes_free_memkb = nodemap_to_free_memkb(ninfo, &nodemap);
> +            if (min_free_memkb > 0 && nodes_free_memkb < min_free_memkb)
> +                continue;
> +
> +            /* And the same applies if this combination is short in cpus */
> +            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
> +            if (min_cpus > 0 && nodes_cpus < min_cpus)
> +                continue;
> +
> +            /*
> +             * Conditions are met, we can add this combination to the
> +             * NUMA placement candidates list. We first make sure there
> +             * is enough space in there, and then we initialize the new
> +             * candidate element with the node map corresponding to the
> +             * combination we are dealing with. Memory allocation for
> +             * expanding the array that hosts the list happens in chunks
> +             * equal to the number of NUMA nodes in the system (to
> +             * avoid allocating memory each and every time we find a
> +             * new candidate).
> +             */
> +            if (*nr_cndts == array_size)
> +                array_size += nr_nodes;
> +            GCREALLOC_ARRAY(new_cndts, array_size);
> +
> +            libxl__numa_candidate_alloc(gc, &new_cndts[*nr_cndts]);
> +            libxl__numa_candidate_put_nodemap(gc, &new_cndts[*nr_cndts],
> +                                              &nodemap);
> +            new_cndts[*nr_cndts].nr_domains =
> +                                    nodemap_to_nr_domains(gc, tinfo, &nodemap);
> +            new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
> +            new_cndts[*nr_cndts].nr_nodes = min_nodes;
> +            new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
> +
> +            LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
> +                       "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
> +                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
> +                       new_cndts[*nr_cndts].free_memkb / 1024);
> +
> +            (*nr_cndts)++;
> +        }
> +        min_nodes++;
> +    }
> +
> +    *cndts = new_cndts;
> + out:
> +    libxl_bitmap_dispose(&nodemap);

nodemap might not have been initialised?

> +    libxl_cputopology_list_free(tinfo, nr_cpus);
> +    libxl_numainfo_list_free(ninfo, nr_nodes);

It looks like the nr_* may also not have been initialised, but maybe
list_free is safe in that case since the associated array must
necessarily be NULL?

> +    return rc;
> +}
> +
> +void libxl__sort_numa_candidates(libxl__numa_candidate cndts[], int nr_cndts,
> +                                 libxl__numa_candidate_cmpf cmpf)
> +{
> +    /* Reorder candidates (see the comparison function for
> +     * the details on the heuristics) */
> +    qsort(cndts, nr_cndts, sizeof(cndts[0]), cmpf);
> +}
> +
> +/*
> + * The NUMA placement candidates are reordered according to the following
> + * heuristics:
> + *  - candidates involving fewer nodes come first. In case two (or
> + *    more) candidates span the same number of nodes,
> + *  - candidates with greater amount of free memory come first. In
> + *    case two (or more) candidates differ in their amount of free
> + *    memory by less than 10%,
> + *  - candidates with fewer domains insisting on them at the time of
> + *    this call come first.
> + */
> +static int numa_cmpf(const void *v1, const void *v2)
> +{
> +    const libxl__numa_candidate *c1 = (const libxl__numa_candidate*) v1;
> +    const libxl__numa_candidate *c2 = (const libxl__numa_candidate*) v2;

Are these casts necessary?

> +    double mem_diff = labs(c1->free_memkb - c2->free_memkb);
> +    double mem_avg = (c1->free_memkb + c2->free_memkb) / 2.0;
> +
> +    if (c1->nr_nodes != c2->nr_nodes)
> +        return c1->nr_nodes - c2->nr_nodes;
> +
> +    if ((mem_diff / mem_avg) * 100.0 < 10.0 &&

Is all this FP math necessary? Using integers might have some rounding
but is it significant or do we care if it gets it slightly wrong?

> +        c1->nr_domains != c2->nr_domains)
> +        return c1->nr_domains - c2->nr_domains;
> +
> +    return c2->free_memkb - c1->free_memkb;
> +}
> +
> +/* The actual automatic NUMA placement routine */
> +static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
> +{
> +    int nr_candidates = 0;
> +    libxl__numa_candidate *candidates = NULL;
> +    libxl_bitmap candidate_nodemap;
> +    libxl_cpupoolinfo *pinfo;
> +    int nr_pools, rc = 0;
> +    uint32_t memkb;
> +
> +    /* First of all, if cpupools are in use, better not to mess with them */
> +    pinfo = libxl_list_cpupool(CTX, &nr_pools);
> +    if (!pinfo)
> +        return ERROR_FAIL;
> +    if (nr_pools > 1) {
> +        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
> +        goto out;
> +    }
> +
> +    rc = libxl_domain_need_memory(CTX, info, &memkb);
> +    if (rc)
> +        goto out;
> +    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    /* Find all the candidates with enough free memory and at least
> +     * as much pcpus as the domain has vcpus.  */
> +    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
> +                                    &candidates, &nr_candidates);
> +    if (rc)
> +        goto out;
> +
> +    LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates);
> +
> +    /* No suitable placement candidates. We just return without touching the
> +     * domain's info->cpumap. It will have affinity with all nodes/cpus. */
> +    if (nr_candidates == 0)
> +        goto out;
> +
> +    /* Bring the best candidate in front of the list --> candidates[0] */
> +    if (nr_candidates > 1)
> +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);

Is the start up cost of libxl__sort_numa_candidates significant enough
to make that if worthwhile?

> +
> +    /*
> +     * At this point, the first candidate in the array is the one we want.
> +     * Go for it by mapping its node map to the domain's info->cpumap.
> +     */
> +    libxl__numa_candidate_get_nodemap(gc, &candidates[0], &candidate_nodemap);
> +    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
> +    if (rc)
> +        goto out;
> +
> +    LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
> +                "%"PRIu32" KB free selected", candidates[0].nr_nodes,
> +                candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
> +
> + out:
> +    libxl_bitmap_dispose(&candidate_nodemap);
> +    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
> +    return rc;
> +}
> +
>  int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>                libxl_domain_build_info *info, libxl__domain_build_state *state)
>  {
> @@ -104,7 +557,22 @@ int libxl__build_pre(libxl__gc *gc, uint
>      uint32_t rtc_timeoffset;
> 
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +
> +    /*
> +     * 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 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,
> +     * whatever that turns out to be.
> +     */
> +    if (libxl_bitmap_is_full(&info->cpumap)) {
> +        int rc = numa_place_domain(gc, info);
> +        if (rc)
> +            return rc;

I'm not sure about this, if numa_place_domain fails for any reason would
we be not better off logging and continuing without placement? We
already do that explicitly in a couple of cases.

> +    }
>      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,
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
>  #define CTX_LOCK (libxl__ctx_lock(CTX))
>  #define CTX_UNLOCK (libxl__ctx_unlock(CTX))
> 
> +/*
> + * Automatic NUMA placement
> + *
> + * These functions and data structures deal with the initial placement of a
> + * domain onto the host NUMA nodes.
> + *
> + * The key concept here is the one of "numa placement candidate" (or jusr "numa

                                                                        just

> + * candidate", "placement candidate" or even "candidate"), which basically is a

Do we really need that level of detail about what we might call it?
There's no minimum word limit you know ;-)

> + * set of nodes whose characteristics have been successfully checked against
> + * some specific requirements. More pecisely, a candidate is the nodemap

                                       precisely

> + * associated with one of the possible subset of the host NUMA nodes providing
> + * a certain amount of free memory, or a given number of cpus, or even both
> + * (depending in what the caller wants). For convenience of use, some of this
> + * information are stored within the candidate itselfs, instead of always being

                                                  itself

> + * dynamically computed. A candidate can consist of just one, up to all the
> + * available nodes on the host (the latter being, of course, not ideal).

I can't parse this sentence.

>   For
> + * instance, looking for a numa candidates with 2GB of free memoy means we want

                                                              memory

> + * all the possible subsets of the host NUMA nodes with, cumulatively, at least
> + * 2GB of free memory. That could be possible by just using one particular
> + * node, or may require more nodes, depending on the characteristics of the
> + * host, on how many domains have been created already, on how big they are,
> + * etc.
> + *
> + * The intended usage is as follows:
> + *  1. by, fist of all, calling libxl__get_numa_candidates(), and specifying
> + *     the proper constraints to it (e.g., the amount of memory a domain need
> + *     as the minimum amount of free memory fo the candidates) one can build

                                               for

> + *     up a whole set of suitable placing alternatives for a domain;
> + *  2. after that, one specific candidate should be chosen. That can happen
> + *     by looking at their various characteristics;
> + *  3. the chosen candidate's nodemap should be utilized for computing the
> + *     actual affinity of the domain which, given the curent NUMA support

                                                         current

> + *     in the hypervisor, is what determines the placement of the domain's
> + *     vcpus and memory.
> + *
> + * To make phase 2 even easier, a sorting helper function for the list of
> + * candidates is povided in the form of libxl__sort_numa_candidates(). The only

                    provided

> + * that is needed is defining a comparison function, containing the chriteria

                                                                       criteria

> + * for deciding, given two candidates, which one is 'better'. Depending on how
> + * the comparison function is defined, the best candidate (where, of course,
> + * best is defined with respect to the heuristics implemented in the comparison
> + * function itself, libxl__numa_candidate_cmpf()) could become the first o the

                                                                           or

> + * last element of the list.
> + *
> + * Summarizing, achieving automatic NUMA placement is just a matter of
> + * obtaining the list of suitable placement candidates, perhaps asking for each
> + * of them to provide at least the amount of memory the domain needs. After
> + * that just implement a comparison function by means of the various helpers
> + * retrieving the relevant information about the candidates themselves.
> + * Finally, call the sorting helper function and use the candidate that became
> + * (typically) the first element of the list fo determining the domain's

                                               for

> + * affinity.
> + */
> +
> +typedef struct {
> +    int nr_cpus, nr_nodes;
> +    int nr_domains;
> +    uint32_t free_memkb;
> +    libxl_bitmap nodemap;
> +} libxl__numa_candidate;
> +
> +/*
> + * This generates the list of NUMA placement candidates satisfying some
> + * specific conditions. If min_nodes and/or max_nodes are not 0, their value is
> + * used to determine the minimum and maximum number of nodes that are allow to
> + * be present in each candidate. If min_nodes and/or max_nodes are 0, the
> + * minimum and maximum number of nodes to be used are automatically selected by
> + * the implementation (and that will likely be just 1 node for the minimum and
> + * the total number of existent nodes for the maximum). Re min_free_memkb and
> + * min_cpu, if not 0, they specify the caller only wants candidates with at
> + * least that amount of free memory and that number of cpus, respectively. If
> + * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
> + * of cpus won't be checked at all, which means a candidate will always be
> + * considered suitable wrt the specific constraint.  cndts is where the list of
> + * exactly nr_cndts candidates is returned. Note that, in case no candidates
> + * are found at all, the function returns successfully, but with nr_cndts equal
> + * to zero.
> + */
> +_hidden int libxl__get_numa_candidates(libxl__gc *gc,
> +                                uint32_t min_free_memkb, int min_cpus,
> +                                int min_nodes, int max_nodes,
> +                                libxl__numa_candidate *cndts[], int *nr_cndts);
> +
> +/* allocation and deallocation for placement candidates */
> +static inline int libxl__numa_candidate_alloc(libxl__gc *gc,
> +                                              libxl__numa_candidate *cndt)
> +{
> +    return libxl_node_bitmap_alloc(CTX, &cndt->nodemap);
> +}
> +static inline void libxl__numa_candidate_dispose(libxl__numa_candidate *cndt)
> +{
> +    libxl_bitmap_dispose(&cndt->nodemap);
> +}
> +static inline void libxl__numacandidate_list_free(libxl__numa_candidate *cndts,
> +                                                  int nr_cndts)
> +{
> +    int i;
> +
> +    for (i = 0; i < nr_cndts; i++)
> +        libxl__numa_candidate_dispose(&cndts[i]);
> +    free(cndts);
> +}
> +
> +/* retrieve (in nodemap) the node map associated to placement candidate cndt */
> +static inline
> +void libxl__numa_candidate_get_nodemap(libxl__gc *gc,
> +                                       const libxl__numa_candidate *cndt,
> +                                       libxl_bitmap *nodemap)
> +{
> +    libxl_bitmap_copy(CTX, nodemap, &cndt->nodemap);
> +}
> +/* set the node map of placement candidate cndt to match nodemap */
> +static inline
> +void libxl__numa_candidate_put_nodemap(libxl__gc *gc,
> +                                       libxl__numa_candidate *cndt,
> +                                       const libxl_bitmap *nodemap)
> +{
> +    libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap);
> +}
> +
> +/* signature for the comparison function between two candidates c1 and c2
> + * (the thid parameter is provided to enable thread safety). */

           third

But there isn't actually a third parameter so it's a bit moot ;-)

> +typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2);
> +/* sort the list of candidates in cndts (an array with nr_cndts elements in
> + * it) using cmpf for comparing two candidates. Uses libc's qsort(). */
> +_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
> +                                         int nr_cndts,
> +                                         libxl__numa_candidate_cmpf cmpf);
> 
>  /*
>   * Inserts "elm_new" into the sorted list "head".



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:41:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11: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 1Shfkr-0006BE-4V; Thu, 21 Jun 2012 11:40:53 +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 1Shfkp-0006B6-KZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:40:51 +0000
Received: from [85.158.138.51:43127] by server-9.bemta-3.messagelabs.com id
	02/C9-10419-24803EF4; Thu, 21 Jun 2012 11:40:50 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340278849!28828616!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19228 invoked from network); 21 Jun 2012 11:40:50 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:40:50 -0000
Received: by qaeb19 with SMTP id b19so3568064qae.11
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 04:40:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=loVrZYR6IVtB7VhoTZQZOTFPCxlvFLBzdvPAz6Eq/X0=;
	b=SeyI4N0fpnDjEAQL8tMFR9ap8HXTn6xrW/u9hyafNukwSa5mCyOP+0Lj2/ZLN2DN+n
	Pv9plHAg4Ks92gl/5yi8Ns1ge4xPTeP3uulpYYhuCQ4QwyKt1fbp4OycrMYGoHi4OHCz
	+a6cg3Cw38fi1a5y0ZZ8x+i5I24YTIDGwvLAnwzgcxkgnS4lCuwdMEFLlX94ZEERj9n7
	d6A+pVH6N+LKdzM3t0bYWFkcqB1OxeG0K+UQlS9iNFq/MXb8KnyWq0WlO/x1tM7z9T0y
	F+kl9JRV6HZcPjX/cwmVBChAE3030PE5iIfPAJ7rx3oyc1FIPsP1nkRjCeEGWymGYbNf
	nTQQ==
MIME-Version: 1.0
Received: by 10.229.136.149 with SMTP id r21mr13951924qct.75.1340278848816;
	Thu, 21 Jun 2012 04:40:48 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 21 Jun 2012 04:40:48 -0700 (PDT)
In-Reply-To: <1340256036.4998.6.camel@dagon.hellion.org.uk>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
	<4FE28C67.30000@gmail.com>
	<1340256036.4998.6.camel@dagon.hellion.org.uk>
Date: Thu, 21 Jun 2012 12:40:48 +0100
X-Google-Sender-Auth: p95Bn-YX4dtzZyeAynNSDAD7lDI
Message-ID: <CAFLBxZbuWA4==72hf48Ss+i8re-YWjpg_8YbPF3V0+R1sKUBVA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
	4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 6:20 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The reason for this check to prevent xl from running while xend is
> active is that using xl while xend is running can lead to subtle and
> confusing bugs.

Just to emphasize the point: about a month ago I spent 3 full days
trying to track down what I thought was an ugly reference-counting
error on domain destruction, but turned out just to be xend running in
the background and messing with things behind xl's back.  That's what
prompted us to put in the check. :-)

Perhaps the warning should explicitly mentioning disabling xend as the
best solution?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:41:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11: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 1Shfkr-0006BE-4V; Thu, 21 Jun 2012 11:40:53 +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 1Shfkp-0006B6-KZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:40:51 +0000
Received: from [85.158.138.51:43127] by server-9.bemta-3.messagelabs.com id
	02/C9-10419-24803EF4; Thu, 21 Jun 2012 11:40:50 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340278849!28828616!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19228 invoked from network); 21 Jun 2012 11:40:50 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:40:50 -0000
Received: by qaeb19 with SMTP id b19so3568064qae.11
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 04:40:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=loVrZYR6IVtB7VhoTZQZOTFPCxlvFLBzdvPAz6Eq/X0=;
	b=SeyI4N0fpnDjEAQL8tMFR9ap8HXTn6xrW/u9hyafNukwSa5mCyOP+0Lj2/ZLN2DN+n
	Pv9plHAg4Ks92gl/5yi8Ns1ge4xPTeP3uulpYYhuCQ4QwyKt1fbp4OycrMYGoHi4OHCz
	+a6cg3Cw38fi1a5y0ZZ8x+i5I24YTIDGwvLAnwzgcxkgnS4lCuwdMEFLlX94ZEERj9n7
	d6A+pVH6N+LKdzM3t0bYWFkcqB1OxeG0K+UQlS9iNFq/MXb8KnyWq0WlO/x1tM7z9T0y
	F+kl9JRV6HZcPjX/cwmVBChAE3030PE5iIfPAJ7rx3oyc1FIPsP1nkRjCeEGWymGYbNf
	nTQQ==
MIME-Version: 1.0
Received: by 10.229.136.149 with SMTP id r21mr13951924qct.75.1340278848816;
	Thu, 21 Jun 2012 04:40:48 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 21 Jun 2012 04:40:48 -0700 (PDT)
In-Reply-To: <1340256036.4998.6.camel@dagon.hellion.org.uk>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
	<4FE28C67.30000@gmail.com>
	<1340256036.4998.6.camel@dagon.hellion.org.uk>
Date: Thu, 21 Jun 2012 12:40:48 +0100
X-Google-Sender-Auth: p95Bn-YX4dtzZyeAynNSDAD7lDI
Message-ID: <CAFLBxZbuWA4==72hf48Ss+i8re-YWjpg_8YbPF3V0+R1sKUBVA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
	4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 6:20 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The reason for this check to prevent xl from running while xend is
> active is that using xl while xend is running can lead to subtle and
> confusing bugs.

Just to emphasize the point: about a month ago I spent 3 full days
trying to track down what I thought was an ugly reference-counting
error on domain destruction, but turned out just to be xend running in
the background and messing with things behind xl's back.  That's what
prompted us to put in the check. :-)

Perhaps the warning should explicitly mentioning disabling xend as the
best solution?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:43:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:43: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 1Shfmu-0006Lt-Lr; Thu, 21 Jun 2012 11:43: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 1Shfmt-0006Lk-Fz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:42:59 +0000
Received: from [85.158.139.83:37507] by server-7.bemta-5.messagelabs.com id
	76/1A-28276-2C803EF4; Thu, 21 Jun 2012 11:42:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340278977!28716829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6049 invoked from network); 21 Jun 2012 11:42:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:42:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145780"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:42:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:42:57 +0100
Message-ID: <1340278976.21872.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 21 Jun 2012 12:42:56 +0100
In-Reply-To: <4FE20E27.8000108@oracle.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Don Dutile <ddutile@redhat.com>, Andrew Jones <drjones@redhat.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> On 06/20/2012 11:34 AM, Ian Campbell wrote:
> > On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> >> # HG changeset patch
> >> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> >> # Date 1339608534 14400
> >> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> >> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> >> tools/hotplug: fix locking
> > A better title would be "tools/hotplug: Switch to locking with flock"
> > since "fix" is not very descriptive.
> Agree.
> >
> > The commit message should also state why changing this scheme is
> > preferable to fixing the current one.
> I have two points:
> 
> 1. No timeout: in the old one, if one process holding the lock more than 100
>    seconds, other processes could steal it.
> 2. No leftovers: if a process holding this lock is dead, it will close the lock
>    file, so it will not affect other processes.
> 
> >
> > Is this flock tool widely available? Does it need to be added to the
> > dependencies in the README?
> It is widely distributed: it's part of the util-linux package. So I think no
> need to document it.
> >
> >> The current locking implementation would allow two processes get the lock
> >> simultaneously:
> > [...snip shell trace...]
> >
> > Can you add a line or two of analysis to explain where in that shell
> > spew things are actually going wrong and why?
> I didn't spent much time on this complicated implement. But it fails for me and
> also for others (from response).
> >
> >> This patch is ported from Red Hat Enterprise Linux 5.8.
> > I think we need a Signed-off-by from the original patch author. (Unless
> > DCO clause b somehow applies?)
> I'm not sure how to handle this. There's no signed-off-by on the original Red
> Hat patch. Could anyone in Red Hat help to get it signed off?

Perhaps Andrew Jones or Don Dutile can point us in the right direction
(both CCd) if you identify the precise source of the patch (i.e. the
name of the .src.rpm and the name of the patch within it)?

I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
recent) but maybe I'm looking in the wrong place.

Ian.
> 
> Thanks,
> 
> Zhigang
> >
> >
> > Thanks,
> > Ian.
> >
> >> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> >> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> >>
> >> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
> >> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> >> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
> >> @@ -1,5 +1,6 @@
> >>  #
> >>  # Copyright (c) 2005 XenSource Ltd.
> >> +# Copyright (c) 2007 Red Hat
> >>  #
> >>  # This library is free software; you can redistribute it and/or
> >>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
> >> @@ -19,92 +20,30 @@
> >>  # Serialisation
> >>  #
> >>  
> >> -LOCK_SLEEPTIME=1
> >> -LOCK_SPINNING_RETRIES=5
> >> -LOCK_RETRIES=100
> >>  LOCK_BASEDIR=/var/run/xen-hotplug
> >>  
> >> +_setlockfd()
> >> +{
> >> +    local i
> >> +    for ((i = 0; i < ${#_lockdict}; i++))
> >> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> >> +    done
> >> +    _lockdict[$i]="$1"
> >> +    let _lockfd=200+i
> >> +}
> >> +
> >>  
> >>  claim_lock()
> >>  {
> >> -  local lockdir="$LOCK_BASEDIR/$1"
> >> -  mkdir -p "$LOCK_BASEDIR"
> >> -  _claim_lock "$lockdir"
> >> +    mkdir -p "$LOCK_BASEDIR"
> >> +    _setlockfd $1
> >> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
> >> +    flock -x $_lockfd
> >>  }
> >>  
> >>
> >>  release_lock()
> >>  {
> >> -  _release_lock "$LOCK_BASEDIR/$1"
> >> +    _setlockfd $1
> >> +    flock -u $_lockfd
> >>  }
> >> -
> >> -
> >> -# This function will be redefined in xen-hotplug-common.sh.
> >> -sigerr() {
> >> -  exit 1
> >> -}
> >> -
> >> -
> >> -_claim_lock()
> >> -{
> >> -  local lockdir="$1"
> >> -  local owner=$(_lock_owner "$lockdir")
> >> -  local retries=0
> >> -
> >> -  while [ $retries -lt $LOCK_RETRIES ]
> >> -  do
> >> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> >> -      _update_lock_info "$lockdir" && return
> >> -
> >> -    local new_owner=$(_lock_owner "$lockdir")
> >> -    if [ "$new_owner" != "$owner" ]
> >> -    then
> >> -      owner="$new_owner"
> >> -      retries=0
> >> -    else
> >> -      local pid=$(echo $owner | cut -d : -f 1)
> >> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> >> -      then
> >> -        _release_lock $lockdir
> >> -      fi
> >> -    fi
> >> -
> >> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
> >> -    then
> >> -      sleep $LOCK_SLEEPTIME
> >> -    else
> >> -      sleep 0
> >> -    fi
> >> -    retries=$(($retries + 1))
> >> -  done
> >> -  _steal_lock "$lockdir"
> >> -}
> >> -
> >> -
> >> -_release_lock()
> >> -{
> >> -  trap sigerr ERR
> >> -  rm -rf "$1" 2>/dev/null || true
> >> -}
> >> -
> >> -
> >> -_steal_lock()
> >> -{
> >> -  local lockdir="$1"
> >> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> >> -  log err "Forced to steal lock on $lockdir from $owner!"
> >> -  _release_lock "$lockdir"
> >> -  _claim_lock "$lockdir"
> >> -}
> >> -
> >> -
> >> -_lock_owner()
> >> -{
> >> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> >> -}
> >> -
> >> -
> >> -_update_lock_info()
> >> -{
> >> -  echo "$$: $0" >"$1/owner"
> >> -}
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@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 Jun 21 11:43:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:43: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 1Shfmu-0006Lt-Lr; Thu, 21 Jun 2012 11:43: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 1Shfmt-0006Lk-Fz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:42:59 +0000
Received: from [85.158.139.83:37507] by server-7.bemta-5.messagelabs.com id
	76/1A-28276-2C803EF4; Thu, 21 Jun 2012 11:42:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340278977!28716829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6049 invoked from network); 21 Jun 2012 11:42:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:42:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145780"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:42:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:42:57 +0100
Message-ID: <1340278976.21872.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 21 Jun 2012 12:42:56 +0100
In-Reply-To: <4FE20E27.8000108@oracle.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Don Dutile <ddutile@redhat.com>, Andrew Jones <drjones@redhat.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> On 06/20/2012 11:34 AM, Ian Campbell wrote:
> > On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> >> # HG changeset patch
> >> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> >> # Date 1339608534 14400
> >> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> >> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> >> tools/hotplug: fix locking
> > A better title would be "tools/hotplug: Switch to locking with flock"
> > since "fix" is not very descriptive.
> Agree.
> >
> > The commit message should also state why changing this scheme is
> > preferable to fixing the current one.
> I have two points:
> 
> 1. No timeout: in the old one, if one process holding the lock more than 100
>    seconds, other processes could steal it.
> 2. No leftovers: if a process holding this lock is dead, it will close the lock
>    file, so it will not affect other processes.
> 
> >
> > Is this flock tool widely available? Does it need to be added to the
> > dependencies in the README?
> It is widely distributed: it's part of the util-linux package. So I think no
> need to document it.
> >
> >> The current locking implementation would allow two processes get the lock
> >> simultaneously:
> > [...snip shell trace...]
> >
> > Can you add a line or two of analysis to explain where in that shell
> > spew things are actually going wrong and why?
> I didn't spent much time on this complicated implement. But it fails for me and
> also for others (from response).
> >
> >> This patch is ported from Red Hat Enterprise Linux 5.8.
> > I think we need a Signed-off-by from the original patch author. (Unless
> > DCO clause b somehow applies?)
> I'm not sure how to handle this. There's no signed-off-by on the original Red
> Hat patch. Could anyone in Red Hat help to get it signed off?

Perhaps Andrew Jones or Don Dutile can point us in the right direction
(both CCd) if you identify the precise source of the patch (i.e. the
name of the .src.rpm and the name of the patch within it)?

I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
recent) but maybe I'm looking in the wrong place.

Ian.
> 
> Thanks,
> 
> Zhigang
> >
> >
> > Thanks,
> > Ian.
> >
> >> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> >> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> >>
> >> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
> >> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> >> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
> >> @@ -1,5 +1,6 @@
> >>  #
> >>  # Copyright (c) 2005 XenSource Ltd.
> >> +# Copyright (c) 2007 Red Hat
> >>  #
> >>  # This library is free software; you can redistribute it and/or
> >>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
> >> @@ -19,92 +20,30 @@
> >>  # Serialisation
> >>  #
> >>  
> >> -LOCK_SLEEPTIME=1
> >> -LOCK_SPINNING_RETRIES=5
> >> -LOCK_RETRIES=100
> >>  LOCK_BASEDIR=/var/run/xen-hotplug
> >>  
> >> +_setlockfd()
> >> +{
> >> +    local i
> >> +    for ((i = 0; i < ${#_lockdict}; i++))
> >> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> >> +    done
> >> +    _lockdict[$i]="$1"
> >> +    let _lockfd=200+i
> >> +}
> >> +
> >>  
> >>  claim_lock()
> >>  {
> >> -  local lockdir="$LOCK_BASEDIR/$1"
> >> -  mkdir -p "$LOCK_BASEDIR"
> >> -  _claim_lock "$lockdir"
> >> +    mkdir -p "$LOCK_BASEDIR"
> >> +    _setlockfd $1
> >> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
> >> +    flock -x $_lockfd
> >>  }
> >>  
> >>
> >>  release_lock()
> >>  {
> >> -  _release_lock "$LOCK_BASEDIR/$1"
> >> +    _setlockfd $1
> >> +    flock -u $_lockfd
> >>  }
> >> -
> >> -
> >> -# This function will be redefined in xen-hotplug-common.sh.
> >> -sigerr() {
> >> -  exit 1
> >> -}
> >> -
> >> -
> >> -_claim_lock()
> >> -{
> >> -  local lockdir="$1"
> >> -  local owner=$(_lock_owner "$lockdir")
> >> -  local retries=0
> >> -
> >> -  while [ $retries -lt $LOCK_RETRIES ]
> >> -  do
> >> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> >> -      _update_lock_info "$lockdir" && return
> >> -
> >> -    local new_owner=$(_lock_owner "$lockdir")
> >> -    if [ "$new_owner" != "$owner" ]
> >> -    then
> >> -      owner="$new_owner"
> >> -      retries=0
> >> -    else
> >> -      local pid=$(echo $owner | cut -d : -f 1)
> >> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> >> -      then
> >> -        _release_lock $lockdir
> >> -      fi
> >> -    fi
> >> -
> >> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
> >> -    then
> >> -      sleep $LOCK_SLEEPTIME
> >> -    else
> >> -      sleep 0
> >> -    fi
> >> -    retries=$(($retries + 1))
> >> -  done
> >> -  _steal_lock "$lockdir"
> >> -}
> >> -
> >> -
> >> -_release_lock()
> >> -{
> >> -  trap sigerr ERR
> >> -  rm -rf "$1" 2>/dev/null || true
> >> -}
> >> -
> >> -
> >> -_steal_lock()
> >> -{
> >> -  local lockdir="$1"
> >> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> >> -  log err "Forced to steal lock on $lockdir from $owner!"
> >> -  _release_lock "$lockdir"
> >> -  _claim_lock "$lockdir"
> >> -}
> >> -
> >> -
> >> -_lock_owner()
> >> -{
> >> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> >> -}
> >> -
> >> -
> >> -_update_lock_info()
> >> -{
> >> -  echo "$$: $0" >"$1/owner"
> >> -}
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@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 Jun 21 11:44:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:44: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 1Shfng-0006QM-4Z; Thu, 21 Jun 2012 11:43: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 1Shfnf-0006QA-5e
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:43:47 +0000
Received: from [85.158.143.99:60163] by server-3.bemta-4.messagelabs.com id
	91/EF-05808-2F803EF4; Thu, 21 Jun 2012 11:43:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340279026!16854984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8229 invoked from network); 21 Jun 2012 11:43:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:43:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:43:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:43:46 +0100
Message-ID: <1340279024.21872.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 21 Jun 2012 12:43:44 +0100
In-Reply-To: <CAFLBxZbuWA4==72hf48Ss+i8re-YWjpg_8YbPF3V0+R1sKUBVA@mail.gmail.com>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
	<4FE28C67.30000@gmail.com>	<1340256036.4998.6.camel@dagon.hellion.org.uk>
	<CAFLBxZbuWA4==72hf48Ss+i8re-YWjpg_8YbPF3V0+R1sKUBVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
 4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 12:40 +0100, George Dunlap wrote:
> On Thu, Jun 21, 2012 at 6:20 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > The reason for this check to prevent xl from running while xend is
> > active is that using xl while xend is running can lead to subtle and
> > confusing bugs.
> 
> Just to emphasize the point: about a month ago I spent 3 full days
> trying to track down what I thought was an ugly reference-counting
> error on domain destruction, but turned out just to be xend running in
> the background and messing with things behind xl's back.  That's what
> prompted us to put in the check. :-)
> 
> Perhaps the warning should explicitly mentioning disabling xend as the
> best solution?

Yes, I think that would be a good idea.

> 
>  -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:44:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:44: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 1Shfng-0006QM-4Z; Thu, 21 Jun 2012 11:43: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 1Shfnf-0006QA-5e
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:43:47 +0000
Received: from [85.158.143.99:60163] by server-3.bemta-4.messagelabs.com id
	91/EF-05808-2F803EF4; Thu, 21 Jun 2012 11:43:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340279026!16854984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8229 invoked from network); 21 Jun 2012 11:43:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:43:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:43:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:43:46 +0100
Message-ID: <1340279024.21872.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 21 Jun 2012 12:43:44 +0100
In-Reply-To: <CAFLBxZbuWA4==72hf48Ss+i8re-YWjpg_8YbPF3V0+R1sKUBVA@mail.gmail.com>
References: <4FE26C0E.9070104@gmail.com>
	<CABs9Ej=K7GGHHk43MJvekvffCVjQoVs5=+HursF2BmLRcU31ng@mail.gmail.com>
	<4FE28C67.30000@gmail.com>	<1340256036.4998.6.camel@dagon.hellion.org.uk>
	<CAFLBxZbuWA4==72hf48Ss+i8re-YWjpg_8YbPF3V0+R1sKUBVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Why the need for "-f" with XL in Xen
 4.2 rev-25467
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 12:40 +0100, George Dunlap wrote:
> On Thu, Jun 21, 2012 at 6:20 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > The reason for this check to prevent xl from running while xend is
> > active is that using xl while xend is running can lead to subtle and
> > confusing bugs.
> 
> Just to emphasize the point: about a month ago I spent 3 full days
> trying to track down what I thought was an ugly reference-counting
> error on domain destruction, but turned out just to be xend running in
> the background and messing with things behind xl's back.  That's what
> prompted us to put in the check. :-)
> 
> Perhaps the warning should explicitly mentioning disabling xend as the
> best solution?

Yes, I think that would be a good idea.

> 
>  -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 11:49:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11: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 1ShftB-0006ls-UC; Thu, 21 Jun 2012 11:49: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 1Shft9-0006ln-Ke
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:49:27 +0000
Received: from [85.158.139.83:56729] by server-11.bemta-5.messagelabs.com id
	EA/97-20400-64A03EF4; Thu, 21 Jun 2012 11:49:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340279366!26097154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29600 invoked from network); 21 Jun 2012 11:49:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:49:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:49:26 +0100
Message-ID: <1340279364.21872.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 21 Jun 2012 12:49:24 +0100
In-Reply-To: <1340278976.21872.114.camel@zakaz.uk.xensource.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> > On 06/20/2012 11:34 AM, Ian Campbell wrote:
> > > On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> > >> # HG changeset patch
> > >> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> > >> # Date 1339608534 14400
> > >> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> > >> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> > >> tools/hotplug: fix locking
> > > A better title would be "tools/hotplug: Switch to locking with flock"
> > > since "fix" is not very descriptive.
> > Agree.
> > >
> > > The commit message should also state why changing this scheme is
> > > preferable to fixing the current one.
> > I have two points:
> > 
> > 1. No timeout: in the old one, if one process holding the lock more than 100
> >    seconds, other processes could steal it.
> > 2. No leftovers: if a process holding this lock is dead, it will close the lock
> >    file, so it will not affect other processes.
> > 
> > >
> > > Is this flock tool widely available? Does it need to be added to the
> > > dependencies in the README?
> > It is widely distributed: it's part of the util-linux package. So I think no
> > need to document it.
> > >
> > >> The current locking implementation would allow two processes get the lock
> > >> simultaneously:
> > > [...snip shell trace...]
> > >
> > > Can you add a line or two of analysis to explain where in that shell
> > > spew things are actually going wrong and why?
> > I didn't spent much time on this complicated implement. But it fails for me and
> > also for others (from response).
> > >
> > >> This patch is ported from Red Hat Enterprise Linux 5.8.
> > > I think we need a Signed-off-by from the original patch author. (Unless
> > > DCO clause b somehow applies?)
> > I'm not sure how to handle this. There's no signed-off-by on the original Red
> > Hat patch. Could anyone in Red Hat help to get it signed off?
> 
> Perhaps Andrew Jones or Don Dutile can point us in the right direction
> (both CCd) if you identify the precise source of the patch (i.e. the
> name of the .src.rpm and the name of the patch within it)?
> 
> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
> recent) but maybe I'm looking in the wrong place.

Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
that RH shipped kernel+xen in a single source package, oh well).

%changelog says:
        * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
        - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)

Daniel CCd.

I wonder if there were any followup fixes or changes, especially wrt to
your point 1 above (the lack of a timeout now) requiring xend (or now
libxl) changes?

> 
> Ian.
> > 
> > Thanks,
> > 
> > Zhigang
> > >
> > >
> > > Thanks,
> > > Ian.
> > >
> > >> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> > >> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> > >>
> > >> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
> > >> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> > >> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
> > >> @@ -1,5 +1,6 @@
> > >>  #
> > >>  # Copyright (c) 2005 XenSource Ltd.
> > >> +# Copyright (c) 2007 Red Hat
> > >>  #
> > >>  # This library is free software; you can redistribute it and/or
> > >>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
> > >> @@ -19,92 +20,30 @@
> > >>  # Serialisation
> > >>  #
> > >>  
> > >> -LOCK_SLEEPTIME=1
> > >> -LOCK_SPINNING_RETRIES=5
> > >> -LOCK_RETRIES=100
> > >>  LOCK_BASEDIR=/var/run/xen-hotplug
> > >>  
> > >> +_setlockfd()
> > >> +{
> > >> +    local i
> > >> +    for ((i = 0; i < ${#_lockdict}; i++))
> > >> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> > >> +    done
> > >> +    _lockdict[$i]="$1"
> > >> +    let _lockfd=200+i
> > >> +}
> > >> +
> > >>  
> > >>  claim_lock()
> > >>  {
> > >> -  local lockdir="$LOCK_BASEDIR/$1"
> > >> -  mkdir -p "$LOCK_BASEDIR"
> > >> -  _claim_lock "$lockdir"
> > >> +    mkdir -p "$LOCK_BASEDIR"
> > >> +    _setlockfd $1
> > >> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
> > >> +    flock -x $_lockfd
> > >>  }
> > >>  
> > >>
> > >>  release_lock()
> > >>  {
> > >> -  _release_lock "$LOCK_BASEDIR/$1"
> > >> +    _setlockfd $1
> > >> +    flock -u $_lockfd
> > >>  }
> > >> -
> > >> -
> > >> -# This function will be redefined in xen-hotplug-common.sh.
> > >> -sigerr() {
> > >> -  exit 1
> > >> -}
> > >> -
> > >> -
> > >> -_claim_lock()
> > >> -{
> > >> -  local lockdir="$1"
> > >> -  local owner=$(_lock_owner "$lockdir")
> > >> -  local retries=0
> > >> -
> > >> -  while [ $retries -lt $LOCK_RETRIES ]
> > >> -  do
> > >> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> > >> -      _update_lock_info "$lockdir" && return
> > >> -
> > >> -    local new_owner=$(_lock_owner "$lockdir")
> > >> -    if [ "$new_owner" != "$owner" ]
> > >> -    then
> > >> -      owner="$new_owner"
> > >> -      retries=0
> > >> -    else
> > >> -      local pid=$(echo $owner | cut -d : -f 1)
> > >> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> > >> -      then
> > >> -        _release_lock $lockdir
> > >> -      fi
> > >> -    fi
> > >> -
> > >> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
> > >> -    then
> > >> -      sleep $LOCK_SLEEPTIME
> > >> -    else
> > >> -      sleep 0
> > >> -    fi
> > >> -    retries=$(($retries + 1))
> > >> -  done
> > >> -  _steal_lock "$lockdir"
> > >> -}
> > >> -
> > >> -
> > >> -_release_lock()
> > >> -{
> > >> -  trap sigerr ERR
> > >> -  rm -rf "$1" 2>/dev/null || true
> > >> -}
> > >> -
> > >> -
> > >> -_steal_lock()
> > >> -{
> > >> -  local lockdir="$1"
> > >> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> > >> -  log err "Forced to steal lock on $lockdir from $owner!"
> > >> -  _release_lock "$lockdir"
> > >> -  _claim_lock "$lockdir"
> > >> -}
> > >> -
> > >> -
> > >> -_lock_owner()
> > >> -{
> > >> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> > >> -}
> > >> -
> > >> -
> > >> -_update_lock_info()
> > >> -{
> > >> -  echo "$$: $0" >"$1/owner"
> > >> -}
> > >>
> > >> _______________________________________________
> > >> Xen-devel mailing list
> > >> Xen-devel@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 Jun 21 11:49:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11: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 1ShftB-0006ls-UC; Thu, 21 Jun 2012 11:49: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 1Shft9-0006ln-Ke
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:49:27 +0000
Received: from [85.158.139.83:56729] by server-11.bemta-5.messagelabs.com id
	EA/97-20400-64A03EF4; Thu, 21 Jun 2012 11:49:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340279366!26097154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29600 invoked from network); 21 Jun 2012 11:49:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,450,1336348800"; d="scan'208";a="13145942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 11:49:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:49:26 +0100
Message-ID: <1340279364.21872.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 21 Jun 2012 12:49:24 +0100
In-Reply-To: <1340278976.21872.114.camel@zakaz.uk.xensource.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> > On 06/20/2012 11:34 AM, Ian Campbell wrote:
> > > On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> > >> # HG changeset patch
> > >> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> > >> # Date 1339608534 14400
> > >> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> > >> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> > >> tools/hotplug: fix locking
> > > A better title would be "tools/hotplug: Switch to locking with flock"
> > > since "fix" is not very descriptive.
> > Agree.
> > >
> > > The commit message should also state why changing this scheme is
> > > preferable to fixing the current one.
> > I have two points:
> > 
> > 1. No timeout: in the old one, if one process holding the lock more than 100
> >    seconds, other processes could steal it.
> > 2. No leftovers: if a process holding this lock is dead, it will close the lock
> >    file, so it will not affect other processes.
> > 
> > >
> > > Is this flock tool widely available? Does it need to be added to the
> > > dependencies in the README?
> > It is widely distributed: it's part of the util-linux package. So I think no
> > need to document it.
> > >
> > >> The current locking implementation would allow two processes get the lock
> > >> simultaneously:
> > > [...snip shell trace...]
> > >
> > > Can you add a line or two of analysis to explain where in that shell
> > > spew things are actually going wrong and why?
> > I didn't spent much time on this complicated implement. But it fails for me and
> > also for others (from response).
> > >
> > >> This patch is ported from Red Hat Enterprise Linux 5.8.
> > > I think we need a Signed-off-by from the original patch author. (Unless
> > > DCO clause b somehow applies?)
> > I'm not sure how to handle this. There's no signed-off-by on the original Red
> > Hat patch. Could anyone in Red Hat help to get it signed off?
> 
> Perhaps Andrew Jones or Don Dutile can point us in the right direction
> (both CCd) if you identify the precise source of the patch (i.e. the
> name of the .src.rpm and the name of the patch within it)?
> 
> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
> recent) but maybe I'm looking in the wrong place.

Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
that RH shipped kernel+xen in a single source package, oh well).

%changelog says:
        * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
        - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)

Daniel CCd.

I wonder if there were any followup fixes or changes, especially wrt to
your point 1 above (the lack of a timeout now) requiring xend (or now
libxl) changes?

> 
> Ian.
> > 
> > Thanks,
> > 
> > Zhigang
> > >
> > >
> > > Thanks,
> > > Ian.
> > >
> > >> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> > >> Cc: Kouya Shimura <kouya@jp.fujitsu.com>
> > >>
> > >> diff -r 32034d1914a6 -r 650b03f41214 tools/hotplug/Linux/locking.sh
> > >> --- a/tools/hotplug/Linux/locking.sh	Thu Jun 07 19:46:57 2012 +0100
> > >> +++ b/tools/hotplug/Linux/locking.sh	Wed Jun 13 13:28:54 2012 -0400
> > >> @@ -1,5 +1,6 @@
> > >>  #
> > >>  # Copyright (c) 2005 XenSource Ltd.
> > >> +# Copyright (c) 2007 Red Hat
> > >>  #
> > >>  # This library is free software; you can redistribute it and/or
> > >>  # modify it under the terms of version 2.1 of the GNU Lesser General Public
> > >> @@ -19,92 +20,30 @@
> > >>  # Serialisation
> > >>  #
> > >>  
> > >> -LOCK_SLEEPTIME=1
> > >> -LOCK_SPINNING_RETRIES=5
> > >> -LOCK_RETRIES=100
> > >>  LOCK_BASEDIR=/var/run/xen-hotplug
> > >>  
> > >> +_setlockfd()
> > >> +{
> > >> +    local i
> > >> +    for ((i = 0; i < ${#_lockdict}; i++))
> > >> +    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> > >> +    done
> > >> +    _lockdict[$i]="$1"
> > >> +    let _lockfd=200+i
> > >> +}
> > >> +
> > >>  
> > >>  claim_lock()
> > >>  {
> > >> -  local lockdir="$LOCK_BASEDIR/$1"
> > >> -  mkdir -p "$LOCK_BASEDIR"
> > >> -  _claim_lock "$lockdir"
> > >> +    mkdir -p "$LOCK_BASEDIR"
> > >> +    _setlockfd $1
> > >> +    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
> > >> +    flock -x $_lockfd
> > >>  }
> > >>  
> > >>
> > >>  release_lock()
> > >>  {
> > >> -  _release_lock "$LOCK_BASEDIR/$1"
> > >> +    _setlockfd $1
> > >> +    flock -u $_lockfd
> > >>  }
> > >> -
> > >> -
> > >> -# This function will be redefined in xen-hotplug-common.sh.
> > >> -sigerr() {
> > >> -  exit 1
> > >> -}
> > >> -
> > >> -
> > >> -_claim_lock()
> > >> -{
> > >> -  local lockdir="$1"
> > >> -  local owner=$(_lock_owner "$lockdir")
> > >> -  local retries=0
> > >> -
> > >> -  while [ $retries -lt $LOCK_RETRIES ]
> > >> -  do
> > >> -    mkdir "$lockdir" 2>/dev/null && trap "_release_lock $lockdir; sigerr" ERR &&
> > >> -      _update_lock_info "$lockdir" && return
> > >> -
> > >> -    local new_owner=$(_lock_owner "$lockdir")
> > >> -    if [ "$new_owner" != "$owner" ]
> > >> -    then
> > >> -      owner="$new_owner"
> > >> -      retries=0
> > >> -    else
> > >> -      local pid=$(echo $owner | cut -d : -f 1)
> > >> -      if [ -n "$pid" -a "$pid" != "unknown" -a ! -f "/proc/$pid/status" ]
> > >> -      then
> > >> -        _release_lock $lockdir
> > >> -      fi
> > >> -    fi
> > >> -
> > >> -    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
> > >> -    then
> > >> -      sleep $LOCK_SLEEPTIME
> > >> -    else
> > >> -      sleep 0
> > >> -    fi
> > >> -    retries=$(($retries + 1))
> > >> -  done
> > >> -  _steal_lock "$lockdir"
> > >> -}
> > >> -
> > >> -
> > >> -_release_lock()
> > >> -{
> > >> -  trap sigerr ERR
> > >> -  rm -rf "$1" 2>/dev/null || true
> > >> -}
> > >> -
> > >> -
> > >> -_steal_lock()
> > >> -{
> > >> -  local lockdir="$1"
> > >> -  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
> > >> -  log err "Forced to steal lock on $lockdir from $owner!"
> > >> -  _release_lock "$lockdir"
> > >> -  _claim_lock "$lockdir"
> > >> -}
> > >> -
> > >> -
> > >> -_lock_owner()
> > >> -{
> > >> -  cat "$1/owner" 2>/dev/null || echo "unknown"
> > >> -}
> > >> -
> > >> -
> > >> -_update_lock_info()
> > >> -{
> > >> -  echo "$$: $0" >"$1/owner"
> > >> -}
> > >>
> > >> _______________________________________________
> > >> Xen-devel mailing list
> > >> Xen-devel@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 Jun 21 11:49:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:49: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 1ShftO-0006nE-Jg; Thu, 21 Jun 2012 11:49:42 +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 1ShftN-0006mO-26
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:49:41 +0000
Received: from [85.158.138.51:7333] by server-10.bemta-3.messagelabs.com id
	B5/69-01753-35A03EF4; Thu, 21 Jun 2012 11:49:39 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340279378!28884299!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4612 invoked from network); 21 Jun 2012 11:49:38 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:49:38 -0000
Received: by eaak12 with SMTP id k12so193837eaa.32
	for <multiple recipients>; Thu, 21 Jun 2012 04:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=X2/Miwl7VxMRkf++fqtcFGpguVe4nZryzmWQCnWvEmM=;
	b=z9zbPTw7jT9BLs/INeylb3UuBLcTRqNxbKGYyT72KRV5nKAOXI20FdcCjYII/zvKr5
	zwsKkCpAVRqQZMYHA1DngiM/QCawHq+66xAK9m4QDvmwWj3FHlQvdEs+xMqhK6dPoRjj
	+AV57ES7Qz7J++hQ0nIdOGLHyu812PzJ6XRh1RJ/plE6UCM9ItWazfyfs/wH6p3RUK2C
	dVkQHke6Lo7ph5xbR5FVlgKjFzsMsJNfBu30iK/NMIEw8bYwdIsww76Z3QtRaFnMVhbS
	9KSiLkunnd6ZScWNEEO3YdLHXzlwLTh3YEXfxCsZQZQBIQTQB6zIITBccCg/S1YUPGiJ
	zjCw==
Received: by 10.14.98.136 with SMTP id v8mr5870680eef.145.1340279377847;
	Thu, 21 Jun 2012 04:49:37 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id z5sm102050447eem.3.2012.06.21.04.49.35
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 04:49:36 -0700 (PDT)
Message-ID: <4FE30A4E.90809@xen.org>
Date: Thu, 21 Jun 2012 12:49:34 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] Xen Document Day: June 25, 2012 on IRC freenode #xendocs
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. A quick reminder that the next Xen DocumentDayis happening 
next Monday. 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
Lars

*********************
* 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 Thu Jun 21 11:49:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:49: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 1ShftO-0006nE-Jg; Thu, 21 Jun 2012 11:49:42 +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 1ShftN-0006mO-26
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:49:41 +0000
Received: from [85.158.138.51:7333] by server-10.bemta-3.messagelabs.com id
	B5/69-01753-35A03EF4; Thu, 21 Jun 2012 11:49:39 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340279378!28884299!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4612 invoked from network); 21 Jun 2012 11:49:38 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 11:49:38 -0000
Received: by eaak12 with SMTP id k12so193837eaa.32
	for <multiple recipients>; Thu, 21 Jun 2012 04:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=X2/Miwl7VxMRkf++fqtcFGpguVe4nZryzmWQCnWvEmM=;
	b=z9zbPTw7jT9BLs/INeylb3UuBLcTRqNxbKGYyT72KRV5nKAOXI20FdcCjYII/zvKr5
	zwsKkCpAVRqQZMYHA1DngiM/QCawHq+66xAK9m4QDvmwWj3FHlQvdEs+xMqhK6dPoRjj
	+AV57ES7Qz7J++hQ0nIdOGLHyu812PzJ6XRh1RJ/plE6UCM9ItWazfyfs/wH6p3RUK2C
	dVkQHke6Lo7ph5xbR5FVlgKjFzsMsJNfBu30iK/NMIEw8bYwdIsww76Z3QtRaFnMVhbS
	9KSiLkunnd6ZScWNEEO3YdLHXzlwLTh3YEXfxCsZQZQBIQTQB6zIITBccCg/S1YUPGiJ
	zjCw==
Received: by 10.14.98.136 with SMTP id v8mr5870680eef.145.1340279377847;
	Thu, 21 Jun 2012 04:49:37 -0700 (PDT)
Received: from [172.16.25.10] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id z5sm102050447eem.3.2012.06.21.04.49.35
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 04:49:36 -0700 (PDT)
Message-ID: <4FE30A4E.90809@xen.org>
Date: Thu, 21 Jun 2012 12:49:34 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] Xen Document Day: June 25, 2012 on IRC freenode #xendocs
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. A quick reminder that the next Xen DocumentDayis happening 
next Monday. 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
Lars

*********************
* 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 Thu Jun 21 11:53:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:53: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 1ShfwY-0007FJ-1C; Thu, 21 Jun 2012 11:52:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1ShfwW-0007F4-GN
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:52:56 +0000
Received: from [85.158.139.83:17960] by server-12.bemta-5.messagelabs.com id
	8A/25-25233-71B03EF4; Thu, 21 Jun 2012 11:52:55 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340279572!28839516!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20647 invoked from network); 21 Jun 2012 11:52:54 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 11:52:54 -0000
Received: from mail38-ch1-R.bigfish.com (10.43.68.231) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:51:26 +0000
Received: from mail38-ch1 (localhost [127.0.0.1])	by mail38-ch1-R.bigfish.com
	(Postfix) with ESMTP id ACD313C0433	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 11:51:25 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25he5bhf0ah34h)
Received: from mail38-ch1 (localhost.localdomain [127.0.0.1]) by mail38-ch1
	(MessageSwitch) id 1340279483973863_21641;
	Thu, 21 Jun 2012 11:51:23 +0000 (UTC)
Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail38-ch1.bigfish.com (Postfix) with ESMTP id
	EB31F360132
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 11:51:23 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:51:22 +0000
X-WSS-ID: 0M5YUBY-01-031-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2EA7E102800A	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 06:52:45 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 06:53:02 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 21 Jun 2012 06:52:45 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	07:52:43 -0400
Message-ID: <4FE30B08.2010407@amd.com>
Date: Thu, 21 Jun 2012 13:52:40 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------010003000704010203020302"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nsvm: fix check if guest enabled nested paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010003000704010203020302
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Fix check if guest enabled nested paging.
Fixes crashes with Windows guests when shadow-on-nested is used.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010003000704010203020302
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_npf.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_npf.diff"
Content-Description: xen_nh_npf.diff

diff -r 195185eba60b xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Thu Jun 21 11:26:43 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Thu Jun 21 13:30:07 2012 +0200
@@ -935,6 +935,9 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
         return 0;
 
     case VMEXIT_NPF:
+        if (nestedhvm_paging_mode_hap(v))
+            break;
+        return 0;
     case VMEXIT_INVALID:
         /* Always intercepted */
         break;

--------------010003000704010203020302
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010003000704010203020302--


From xen-devel-bounces@lists.xen.org Thu Jun 21 11:53:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 11:53: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 1ShfwY-0007FJ-1C; Thu, 21 Jun 2012 11:52:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1ShfwW-0007F4-GN
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 11:52:56 +0000
Received: from [85.158.139.83:17960] by server-12.bemta-5.messagelabs.com id
	8A/25-25233-71B03EF4; Thu, 21 Jun 2012 11:52:55 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340279572!28839516!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20647 invoked from network); 21 Jun 2012 11:52:54 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 11:52:54 -0000
Received: from mail38-ch1-R.bigfish.com (10.43.68.231) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:51:26 +0000
Received: from mail38-ch1 (localhost [127.0.0.1])	by mail38-ch1-R.bigfish.com
	(Postfix) with ESMTP id ACD313C0433	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 11:51:25 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202hzz8275bhz2dh668h839hd25he5bhf0ah34h)
Received: from mail38-ch1 (localhost.localdomain [127.0.0.1]) by mail38-ch1
	(MessageSwitch) id 1340279483973863_21641;
	Thu, 21 Jun 2012 11:51:23 +0000 (UTC)
Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail38-ch1.bigfish.com (Postfix) with ESMTP id
	EB31F360132
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 11:51:23 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 11:51:22 +0000
X-WSS-ID: 0M5YUBY-01-031-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2EA7E102800A	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 06:52:45 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 06:53:02 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 21 Jun 2012 06:52:45 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	07:52:43 -0400
Message-ID: <4FE30B08.2010407@amd.com>
Date: Thu, 21 Jun 2012 13:52:40 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------010003000704010203020302"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nsvm: fix check if guest enabled nested paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010003000704010203020302
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Fix check if guest enabled nested paging.
Fixes crashes with Windows guests when shadow-on-nested is used.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010003000704010203020302
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_npf.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_npf.diff"
Content-Description: xen_nh_npf.diff

diff -r 195185eba60b xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Thu Jun 21 11:26:43 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Thu Jun 21 13:30:07 2012 +0200
@@ -935,6 +935,9 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
         return 0;
 
     case VMEXIT_NPF:
+        if (nestedhvm_paging_mode_hap(v))
+            break;
+        return 0;
     case VMEXIT_INVALID:
         /* Always intercepted */
         break;

--------------010003000704010203020302
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010003000704010203020302--


From xen-devel-bounces@lists.xen.org Thu Jun 21 12:06:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1Shg9T-0007t5-2q; Thu, 21 Jun 2012 12:06: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 1Shg9R-0007sw-Lh
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:06:18 +0000
Received: from [85.158.138.51:56697] by server-10.bemta-3.messagelabs.com id
	E3/68-01753-83E03EF4; Thu, 21 Jun 2012 12:06:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340280375!25932238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31247 invoked from network); 21 Jun 2012 12:06:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 12:06:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:06:15 +0100
Message-Id: <4FE32A81020000780008B11B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:06:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
In-Reply-To: <4FE303C4.3060705@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 13:21, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/21/2012 11:59 AM, Jan Beulich wrote:
>>>>> On 14.06.12 at 17:15, Wei Wang<wei.wang2@amd.com>  wrote:
>>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>> Have you at all considered getting this fixed on the kernel side?
>>>> As I don't have direct access to any AMD IOMMU capable
>>>> system - can one, other than by enumerating the respective
>>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>>> devices in question (e.g. via vendor/class/sub-class or some
>>>> such)? That might permit skipping those in the offending kernel
>>>> code...
>>>
>>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral)
>>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this
>>> should be enough to identify amd iommu device. I could send you a kernel
>>> patch for review using this approach. I would believe that fixing this
>>> issue in 4.2, no matter how, is really important for amd iommu.
>>
>> As you didn't come forward with anything, here's my first
>> take on this:
> 
> Hi Jan
> Thanks a lot for the patch. Actually I plan to send my version today, 
> which is based on 3.4 pv_ops but looks very similar to yours. So, Acked!
> 
> I also evaluated the possibility of hiding iommu device from dom0. I 
> think the change is no quite a lot, at least, for io based pcicfg 
> access. A proof-of-concept patch is attached.

This completely hides the device from Dom0, but only when
config space is accessed via method 1. Did you not see my
earlier patch doing this for MCFG as well (albeit only disallowing
writes, so allowing the device to still be seen by Dom0)?

Whether completely hiding the device is actually okay I can't
easily tell: Would IOMMUs always be either at func 0 of a single-
unction device, or at a non-zero func of a multi-function one? If
not, other devices may get hidden implicitly.

Also I noticed just now that guest_io_read() wouldn't really
behave correctly when pci_cfg_ok() returned false - it might
pass back 0xff even for a multi-byte read. I'll send a fix shortly.

Jan

> --- a/xen/arch/x86/traps.c      Thu Jun 21 11:30:59 2012 +0200
> +++ b/xen/arch/x86/traps.c      Thu Jun 21 13:19:02 2012 +0200
> @@ -73,6 +73,7 @@
>   #include <asm/hpet.h>
>   #include <public/arch-x86/cpuid.h>
>   #include <xsm/xsm.h>
> +#include <asm/hvm/svm/amd-iommu-proto.h>
> 
>   /*
>    * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
> @@ -1686,10 +1687,19 @@ static int pci_cfg_ok(struct domain *d,
>   {
>       uint32_t machine_bdf;
>       uint16_t start, end;
> +    struct amd_iommu *iommu;
> +
>       if (!IS_PRIV(d))
>           return 0;
> 
>       machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
> +
> +    for_each_amd_iommu ( iommu )
> +    {
> +        if ( machine_bdf == iommu->bdf )
> +            return 0;
> +    }
> +
>       start = d->arch.pci_cf8 & 0xFF;
>       end = start + size - 1;
>       if (xsm_pci_config_permission(d, machine_bdf, start, end, write))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:06:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1Shg9T-0007t5-2q; Thu, 21 Jun 2012 12:06: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 1Shg9R-0007sw-Lh
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:06:18 +0000
Received: from [85.158.138.51:56697] by server-10.bemta-3.messagelabs.com id
	E3/68-01753-83E03EF4; Thu, 21 Jun 2012 12:06:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340280375!25932238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31247 invoked from network); 21 Jun 2012 12:06:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 12:06:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:06:15 +0100
Message-Id: <4FE32A81020000780008B11B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:06:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
In-Reply-To: <4FE303C4.3060705@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 13:21, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/21/2012 11:59 AM, Jan Beulich wrote:
>>>>> On 14.06.12 at 17:15, Wei Wang<wei.wang2@amd.com>  wrote:
>>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>> Have you at all considered getting this fixed on the kernel side?
>>>> As I don't have direct access to any AMD IOMMU capable
>>>> system - can one, other than by enumerating the respective
>>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>>> devices in question (e.g. via vendor/class/sub-class or some
>>>> such)? That might permit skipping those in the offending kernel
>>>> code...
>>>
>>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral)
>>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this
>>> should be enough to identify amd iommu device. I could send you a kernel
>>> patch for review using this approach. I would believe that fixing this
>>> issue in 4.2, no matter how, is really important for amd iommu.
>>
>> As you didn't come forward with anything, here's my first
>> take on this:
> 
> Hi Jan
> Thanks a lot for the patch. Actually I plan to send my version today, 
> which is based on 3.4 pv_ops but looks very similar to yours. So, Acked!
> 
> I also evaluated the possibility of hiding iommu device from dom0. I 
> think the change is no quite a lot, at least, for io based pcicfg 
> access. A proof-of-concept patch is attached.

This completely hides the device from Dom0, but only when
config space is accessed via method 1. Did you not see my
earlier patch doing this for MCFG as well (albeit only disallowing
writes, so allowing the device to still be seen by Dom0)?

Whether completely hiding the device is actually okay I can't
easily tell: Would IOMMUs always be either at func 0 of a single-
unction device, or at a non-zero func of a multi-function one? If
not, other devices may get hidden implicitly.

Also I noticed just now that guest_io_read() wouldn't really
behave correctly when pci_cfg_ok() returned false - it might
pass back 0xff even for a multi-byte read. I'll send a fix shortly.

Jan

> --- a/xen/arch/x86/traps.c      Thu Jun 21 11:30:59 2012 +0200
> +++ b/xen/arch/x86/traps.c      Thu Jun 21 13:19:02 2012 +0200
> @@ -73,6 +73,7 @@
>   #include <asm/hpet.h>
>   #include <public/arch-x86/cpuid.h>
>   #include <xsm/xsm.h>
> +#include <asm/hvm/svm/amd-iommu-proto.h>
> 
>   /*
>    * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
> @@ -1686,10 +1687,19 @@ static int pci_cfg_ok(struct domain *d,
>   {
>       uint32_t machine_bdf;
>       uint16_t start, end;
> +    struct amd_iommu *iommu;
> +
>       if (!IS_PRIV(d))
>           return 0;
> 
>       machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
> +
> +    for_each_amd_iommu ( iommu )
> +    {
> +        if ( machine_bdf == iommu->bdf )
> +            return 0;
> +    }
> +
>       start = d->arch.pci_cf8 & 0xFF;
>       end = start + size - 1;
>       if (xsm_pci_config_permission(d, machine_bdf, start, end, write))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShgCC-0007ze-LF; Thu, 21 Jun 2012 12:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1ShgCA-0007zZ-PP
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:09:06 +0000
Received: from [85.158.143.35:23689] by server-3.bemta-4.messagelabs.com id
	06/9A-05808-2EE03EF4; Thu, 21 Jun 2012 12:09:06 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340280543!13035965!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwMTY1Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 21 Jun 2012 12:09:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 12:09:05 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5LC8sWK007762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 12:08: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
	q5LC8r5S012772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2012 12:08:54 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
	q5LC8rSj019374; Thu, 21 Jun 2012 07:08:53 -0500
Received: from localhost.localdomain (/24.91.180.42)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Jun 2012 05:08:53 -0700
Message-ID: <4FE30ED3.6040805@oracle.com>
Date: Thu, 21 Jun 2012 08:08:51 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340279364.21872.118.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Andrew Jones <drjones@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/21/2012 07:49 AM, Ian Campbell wrote:
> On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
>> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
>>> On 06/20/2012 11:34 AM, Ian Campbell wrote:
>>>> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
>>>>> # HG changeset patch
>>>>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
>>>>> # Date 1339608534 14400
>>>>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
>>>>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
>>>>> tools/hotplug: fix locking
>>>> A better title would be "tools/hotplug: Switch to locking with flock"
>>>> since "fix" is not very descriptive.
>>> Agree.
>>>> The commit message should also state why changing this scheme is
>>>> preferable to fixing the current one.
>>> I have two points:
>>>
>>> 1. No timeout: in the old one, if one process holding the lock more than 100
>>>    seconds, other processes could steal it.
>>> 2. No leftovers: if a process holding this lock is dead, it will close the lock
>>>    file, so it will not affect other processes.
>>>
>>>> Is this flock tool widely available? Does it need to be added to the
>>>> dependencies in the README?
>>> It is widely distributed: it's part of the util-linux package. So I think no
>>> need to document it.
>>>>> The current locking implementation would allow two processes get the lock
>>>>> simultaneously:
>>>> [...snip shell trace...]
>>>>
>>>> Can you add a line or two of analysis to explain where in that shell
>>>> spew things are actually going wrong and why?
>>> I didn't spent much time on this complicated implement. But it fails for me and
>>> also for others (from response).
>>>>> This patch is ported from Red Hat Enterprise Linux 5.8.
>>>> I think we need a Signed-off-by from the original patch author. (Unless
>>>> DCO clause b somehow applies?)
>>> I'm not sure how to handle this. There's no signed-off-by on the original Red
>>> Hat patch. Could anyone in Red Hat help to get it signed off?
>> Perhaps Andrew Jones or Don Dutile can point us in the right direction
>> (both CCd) if you identify the precise source of the patch (i.e. the
>> name of the .src.rpm and the name of the patch within it)?
>>
>> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
>> recent) but maybe I'm looking in the wrong place.
> Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
> that RH shipped kernel+xen in a single source package, oh well).
>
> %changelog says:
>         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
>         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
>
> Daniel CCd.
>
> I wonder if there were any followup fixes or changes, especially wrt to
> your point 1 above (the lack of a timeout now) requiring xend (or now
> libxl) changes?

We have another timeout in xend/xl: if device backend is not setup properly, the
device creation will fail.

Without any timeout for this locking, all backend uevent scripts will hang if
one goes wrong. Just stealing the lock upon timeoutis not a good idea: it may
cause error or damage. What about adding a long (10minutes) timeout? (by adding
-w/--wait/--timeout 600)

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShgCC-0007ze-LF; Thu, 21 Jun 2012 12:09:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1ShgCA-0007zZ-PP
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:09:06 +0000
Received: from [85.158.143.35:23689] by server-3.bemta-4.messagelabs.com id
	06/9A-05808-2EE03EF4; Thu, 21 Jun 2012 12:09:06 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1340280543!13035965!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwMTY1Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 21 Jun 2012 12:09:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 12:09:05 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5LC8sWK007762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 12:08: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
	q5LC8r5S012772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2012 12:08:54 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
	q5LC8rSj019374; Thu, 21 Jun 2012 07:08:53 -0500
Received: from localhost.localdomain (/24.91.180.42)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Jun 2012 05:08:53 -0700
Message-ID: <4FE30ED3.6040805@oracle.com>
Date: Thu, 21 Jun 2012 08:08:51 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340279364.21872.118.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Andrew Jones <drjones@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/21/2012 07:49 AM, Ian Campbell wrote:
> On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
>> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
>>> On 06/20/2012 11:34 AM, Ian Campbell wrote:
>>>> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
>>>>> # HG changeset patch
>>>>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
>>>>> # Date 1339608534 14400
>>>>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
>>>>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
>>>>> tools/hotplug: fix locking
>>>> A better title would be "tools/hotplug: Switch to locking with flock"
>>>> since "fix" is not very descriptive.
>>> Agree.
>>>> The commit message should also state why changing this scheme is
>>>> preferable to fixing the current one.
>>> I have two points:
>>>
>>> 1. No timeout: in the old one, if one process holding the lock more than 100
>>>    seconds, other processes could steal it.
>>> 2. No leftovers: if a process holding this lock is dead, it will close the lock
>>>    file, so it will not affect other processes.
>>>
>>>> Is this flock tool widely available? Does it need to be added to the
>>>> dependencies in the README?
>>> It is widely distributed: it's part of the util-linux package. So I think no
>>> need to document it.
>>>>> The current locking implementation would allow two processes get the lock
>>>>> simultaneously:
>>>> [...snip shell trace...]
>>>>
>>>> Can you add a line or two of analysis to explain where in that shell
>>>> spew things are actually going wrong and why?
>>> I didn't spent much time on this complicated implement. But it fails for me and
>>> also for others (from response).
>>>>> This patch is ported from Red Hat Enterprise Linux 5.8.
>>>> I think we need a Signed-off-by from the original patch author. (Unless
>>>> DCO clause b somehow applies?)
>>> I'm not sure how to handle this. There's no signed-off-by on the original Red
>>> Hat patch. Could anyone in Red Hat help to get it signed off?
>> Perhaps Andrew Jones or Don Dutile can point us in the right direction
>> (both CCd) if you identify the precise source of the patch (i.e. the
>> name of the .src.rpm and the name of the patch within it)?
>>
>> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
>> recent) but maybe I'm looking in the wrong place.
> Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
> that RH shipped kernel+xen in a single source package, oh well).
>
> %changelog says:
>         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
>         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
>
> Daniel CCd.
>
> I wonder if there were any followup fixes or changes, especially wrt to
> your point 1 above (the lack of a timeout now) requiring xend (or now
> libxl) changes?

We have another timeout in xend/xl: if device backend is not setup properly, the
device creation will fail.

Without any timeout for this locking, all backend uevent scripts will hang if
one goes wrong. Just stealing the lock upon timeoutis not a good idea: it may
cause error or damage. What about adding a long (10minutes) timeout? (by adding
-w/--wait/--timeout 600)

Thanks,

Zhigang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShgK5-0008Cz-JU; Thu, 21 Jun 2012 12:17: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 1ShgK4-0008Cu-2K
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:17:16 +0000
Received: from [85.158.143.35:17907] by server-2.bemta-4.messagelabs.com id
	92/1E-17938-BC013EF4; Thu, 21 Jun 2012 12:17:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340281034!16175475!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22766 invoked from network); 21 Jun 2012 12:17:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 12:17:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:17:13 +0100
Message-Id: <4FE32D13020000780008B134@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:17:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part371996E3.0__="
Subject: [Xen-devel] [PATCH] x86/PCI: fix guest_io_read() when pci_cfg_ok()
 denies 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>
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.

--=__Part371996E3.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

For a multi-byte aligned read, this so far resulted in 0x00ff to be
put in the guest's register rather than 0xffff or 0xffffffff, which in
turn could confuse bus scanning functions (which, when reading vendor
and/or device IDs, expect to get back all zeroes or all ones).

As the value gets masked to the read width when merging back into the
full result, setting the initial value to all ones should not harm any
or the other cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1717,7 +1717,7 @@ static uint32_t guest_io_read(
     while ( bytes !=3D 0 )
     {
         unsigned int size =3D 1;
-        uint32_t sub_data =3D 0xff;
+        uint32_t sub_data =3D ~0;
=20
         if ( (port =3D=3D 0x42) || (port =3D=3D 0x43) || (port =3D=3D =
0x61) )
         {




--=__Part371996E3.0__=
Content-Type: text/plain; name="x86-PCI-config-read-not-ok.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-PCI-config-read-not-ok.patch"

x86/PCI: fix guest_io_read() when pci_cfg_ok() denies access=0A=0AFor a =
multi-byte aligned read, this so far resulted in 0x00ff to be=0Aput in the =
guest's register rather than 0xffff or 0xffffffff, which in=0Aturn could =
confuse bus scanning functions (which, when reading vendor=0Aand/or device =
IDs, expect to get back all zeroes or all ones).=0A=0AAs the value gets =
masked to the read width when merging back into the=0Afull result, setting =
the initial value to all ones should not harm any=0Aor the other =
cases.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -1717,7 +1717,7 =
@@ static uint32_t guest_io_read(=0A     while ( bytes !=3D 0 )=0A     =
{=0A         unsigned int size =3D 1;=0A-        uint32_t sub_data =3D =
0xff;=0A+        uint32_t sub_data =3D ~0;=0A =0A         if ( (port =
=3D=3D 0x42) || (port =3D=3D 0x43) || (port =3D=3D 0x61) )=0A         {=0A
--=__Part371996E3.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

--=__Part371996E3.0__=--


From xen-devel-bounces@lists.xen.org Thu Jun 21 12:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShgK5-0008Cz-JU; Thu, 21 Jun 2012 12:17: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 1ShgK4-0008Cu-2K
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:17:16 +0000
Received: from [85.158.143.35:17907] by server-2.bemta-4.messagelabs.com id
	92/1E-17938-BC013EF4; Thu, 21 Jun 2012 12:17:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340281034!16175475!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22766 invoked from network); 21 Jun 2012 12:17:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 12:17:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:17:13 +0100
Message-Id: <4FE32D13020000780008B134@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:17:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part371996E3.0__="
Subject: [Xen-devel] [PATCH] x86/PCI: fix guest_io_read() when pci_cfg_ok()
 denies 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>
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.

--=__Part371996E3.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

For a multi-byte aligned read, this so far resulted in 0x00ff to be
put in the guest's register rather than 0xffff or 0xffffffff, which in
turn could confuse bus scanning functions (which, when reading vendor
and/or device IDs, expect to get back all zeroes or all ones).

As the value gets masked to the read width when merging back into the
full result, setting the initial value to all ones should not harm any
or the other cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1717,7 +1717,7 @@ static uint32_t guest_io_read(
     while ( bytes !=3D 0 )
     {
         unsigned int size =3D 1;
-        uint32_t sub_data =3D 0xff;
+        uint32_t sub_data =3D ~0;
=20
         if ( (port =3D=3D 0x42) || (port =3D=3D 0x43) || (port =3D=3D =
0x61) )
         {




--=__Part371996E3.0__=
Content-Type: text/plain; name="x86-PCI-config-read-not-ok.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-PCI-config-read-not-ok.patch"

x86/PCI: fix guest_io_read() when pci_cfg_ok() denies access=0A=0AFor a =
multi-byte aligned read, this so far resulted in 0x00ff to be=0Aput in the =
guest's register rather than 0xffff or 0xffffffff, which in=0Aturn could =
confuse bus scanning functions (which, when reading vendor=0Aand/or device =
IDs, expect to get back all zeroes or all ones).=0A=0AAs the value gets =
masked to the read width when merging back into the=0Afull result, setting =
the initial value to all ones should not harm any=0Aor the other =
cases.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -1717,7 +1717,7 =
@@ static uint32_t guest_io_read(=0A     while ( bytes !=3D 0 )=0A     =
{=0A         unsigned int size =3D 1;=0A-        uint32_t sub_data =3D =
0xff;=0A+        uint32_t sub_data =3D ~0;=0A =0A         if ( (port =
=3D=3D 0x42) || (port =3D=3D 0x43) || (port =3D=3D 0x61) )=0A         {=0A
--=__Part371996E3.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

--=__Part371996E3.0__=--


From xen-devel-bounces@lists.xen.org Thu Jun 21 12:20:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgMz-0008JJ-Fm; Thu, 21 Jun 2012 12:20: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 1ShgMx-0008JE-PJ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:20:15 +0000
Received: from [85.158.143.35:40029] by server-3.bemta-4.messagelabs.com id
	F5/9B-05808-F7113EF4; Thu, 21 Jun 2012 12:20:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340281191!13392223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31522 invoked from network); 21 Jun 2012 12:19:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 12:19:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:19:51 +0100
Message-Id: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:20:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5779F682.0__="
Subject: [Xen-devel] [PATCH] docs/xen-headers: allow headers to be symlinks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part5779F682.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There's no apparent reason not to permit this, and since we don't
support out-of-source-tree builds, the least overhead way of doing
multiple, differently configured (perhaps different architecture)
builds from a single source tree is to create symlinked build trees.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -368,7 +368,7 @@ foreach $pass (qw(1 2)) {
     find({ wanted =3D>=20
                sub {
                    return unless m/\.h$/;
-                   lstat $File::Find::name or die "$File::Find::name $!";
+                   stat $File::Find::name or die "$File::Find::name $!";
                    -f _ or die "$File::Find::name";
                    substr($File::Find::name, 0, 1+length $basedir)=20
                        eq "$basedir/"




--=__Part5779F682.0__=
Content-Type: text/plain; name="docs-xen-header-symlink.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="docs-xen-header-symlink.patch"

docs/xen-headers: allow headers to be symlinks=0A=0AThere's no apparent =
reason not to permit this, and since we don't=0Asupport out-of-source-tree =
builds, the least overhead way of doing=0Amultiple, differently configured =
(perhaps different architecture)=0Abuilds from a single source tree is to =
create symlinked build trees.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A--- a/docs/xen-headers=0A+++ b/docs/xen-headers=0A@@ -368,7 =
+368,7 @@ foreach $pass (qw(1 2)) {=0A     find({ wanted =3D> =0A          =
      sub {=0A                    return unless m/\.h$/;=0A-               =
    lstat $File::Find::name or die "$File::Find::name $!";=0A+             =
      stat $File::Find::name or die "$File::Find::name $!";=0A             =
       -f _ or die "$File::Find::name";=0A                    substr($File:=
:Find::name, 0, 1+length $basedir) =0A                        eq "$basedir/=
"=0A
--=__Part5779F682.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

--=__Part5779F682.0__=--


From xen-devel-bounces@lists.xen.org Thu Jun 21 12:20:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgMz-0008JJ-Fm; Thu, 21 Jun 2012 12:20: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 1ShgMx-0008JE-PJ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:20:15 +0000
Received: from [85.158.143.35:40029] by server-3.bemta-4.messagelabs.com id
	F5/9B-05808-F7113EF4; Thu, 21 Jun 2012 12:20:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340281191!13392223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31522 invoked from network); 21 Jun 2012 12:19:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 12:19:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:19:51 +0100
Message-Id: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:20:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5779F682.0__="
Subject: [Xen-devel] [PATCH] docs/xen-headers: allow headers to be symlinks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part5779F682.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There's no apparent reason not to permit this, and since we don't
support out-of-source-tree builds, the least overhead way of doing
multiple, differently configured (perhaps different architecture)
builds from a single source tree is to create symlinked build trees.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -368,7 +368,7 @@ foreach $pass (qw(1 2)) {
     find({ wanted =3D>=20
                sub {
                    return unless m/\.h$/;
-                   lstat $File::Find::name or die "$File::Find::name $!";
+                   stat $File::Find::name or die "$File::Find::name $!";
                    -f _ or die "$File::Find::name";
                    substr($File::Find::name, 0, 1+length $basedir)=20
                        eq "$basedir/"




--=__Part5779F682.0__=
Content-Type: text/plain; name="docs-xen-header-symlink.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="docs-xen-header-symlink.patch"

docs/xen-headers: allow headers to be symlinks=0A=0AThere's no apparent =
reason not to permit this, and since we don't=0Asupport out-of-source-tree =
builds, the least overhead way of doing=0Amultiple, differently configured =
(perhaps different architecture)=0Abuilds from a single source tree is to =
create symlinked build trees.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A--- a/docs/xen-headers=0A+++ b/docs/xen-headers=0A@@ -368,7 =
+368,7 @@ foreach $pass (qw(1 2)) {=0A     find({ wanted =3D> =0A          =
      sub {=0A                    return unless m/\.h$/;=0A-               =
    lstat $File::Find::name or die "$File::Find::name $!";=0A+             =
      stat $File::Find::name or die "$File::Find::name $!";=0A             =
       -f _ or die "$File::Find::name";=0A                    substr($File:=
:Find::name, 0, 1+length $basedir) =0A                        eq "$basedir/=
"=0A
--=__Part5779F682.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

--=__Part5779F682.0__=--


From xen-devel-bounces@lists.xen.org Thu Jun 21 12:20:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgNJ-0008Kv-Tv; Thu, 21 Jun 2012 12:20:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <berrange@redhat.com>) id 1ShgNI-0008Kh-7l
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:20:36 +0000
Received: from [85.158.139.83:2311] by server-7.bemta-5.messagelabs.com id
	52/7A-28276-39113EF4; Thu, 21 Jun 2012 12:20:35 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340281233!17551643!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6892 invoked from network); 21 Jun 2012 12:20:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 12:20:34 -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 q5LCKRM5002945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 08:20:27 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q5LCKNWE022571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 21 Jun 2012 08:20:25 -0400
Date: Thu, 21 Jun 2012 13:20:22 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621122022.GO21124@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340279364.21872.118.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Andrew Jones <drjones@redhat.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" <berrange@redhat.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, Jun 21, 2012 at 12:49:24PM +0100, Ian Campbell wrote:
> On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
> > On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> > > On 06/20/2012 11:34 AM, Ian Campbell wrote:
> > > > On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> > > >> # HG changeset patch
> > > >> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> > > >> # Date 1339608534 14400
> > > >> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> > > >> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> > > >> tools/hotplug: fix locking
> > > > A better title would be "tools/hotplug: Switch to locking with flock"
> > > > since "fix" is not very descriptive.
> > > Agree.
> > > >
> > > > The commit message should also state why changing this scheme is
> > > > preferable to fixing the current one.
> > > I have two points:
> > > 
> > > 1. No timeout: in the old one, if one process holding the lock more than 100
> > >    seconds, other processes could steal it.
> > > 2. No leftovers: if a process holding this lock is dead, it will close the lock
> > >    file, so it will not affect other processes.
> > > 
> > > >
> > > > Is this flock tool widely available? Does it need to be added to the
> > > > dependencies in the README?
> > > It is widely distributed: it's part of the util-linux package. So I think no
> > > need to document it.
> > > >
> > > >> The current locking implementation would allow two processes get the lock
> > > >> simultaneously:
> > > > [...snip shell trace...]
> > > >
> > > > Can you add a line or two of analysis to explain where in that shell
> > > > spew things are actually going wrong and why?
> > > I didn't spent much time on this complicated implement. But it fails for me and
> > > also for others (from response).
> > > >
> > > >> This patch is ported from Red Hat Enterprise Linux 5.8.
> > > > I think we need a Signed-off-by from the original patch author. (Unless
> > > > DCO clause b somehow applies?)
> > > I'm not sure how to handle this. There's no signed-off-by on the original Red
> > > Hat patch. Could anyone in Red Hat help to get it signed off?
> > 
> > Perhaps Andrew Jones or Don Dutile can point us in the right direction
> > (both CCd) if you identify the precise source of the patch (i.e. the
> > name of the .src.rpm and the name of the patch within it)?
> > 
> > I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
> > recent) but maybe I'm looking in the wrong place.
> 
> Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
> that RH shipped kernel+xen in a single source package, oh well).
> 
> %changelog says:
>         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
>         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
> 
> Daniel CCd.
> 
> I wonder if there were any followup fixes or changes, especially wrt to
> your point 1 above (the lack of a timeout now) requiring xend (or now
> libxl) changes?

Removing any kind of timeout was in fact the point of this change.
We do not want hotplug scripts stealing each others locks, or
timing out, because the timeouts cause alot of problems when
launching guests on a highly loaded machine where execution time
can be alot longer than a timeout setting may expect.

I expect you can't see the original BZ ticket quoted, since it
has customer information in it.  Here is my description of
what the problem we weere solving was:

[quote]
In the normal case of a single domain booting with one disk, the disk hotplug
script will fire once. In this case taking out the lock will never cause a sleep
because there's no other concurrent invocations. If a domain has 4 disks
configured, then the hotplug script will fire 4 times, all 4 invocations at
pretty much the same time. If there is even a little load on the system, the
locking function in the shell script will sleep for a few seconds - as many as 5
seconds, or potentially even time out & fail completely.

If say 4 or even more domains each with 4 disks start up at once, that's 16
invocations of the hotplug script running at once. There will be alot of sleep's
done & because of the very coarse 1 second granularity the delay can add up
significantly. 

The change to using flock() removes the arbitrary 1 second sleep, so the very
instant once hotplug script finishes, another can start & there is no repeated
attempts & failures to lock which would add more delay.
[/quote]

Usually it was our policy to send all these kind of patches upstream,
so I'm not really sure why this was not already merged. Possibly I
forgot to submit it, or maybe it was rejected - I honestly can't
remember.

Below is the original patch I wrote, to which I apply:

  Signed-off-by: Daniel P. Berrange.

diff -rup xen-3.1.0-src.orig/tools/examples/locking.sh xen-3.1.0-src.new/tools/examples/locking.sh
--- xen-3.1.0-src.orig/tools/examples/locking.sh	2006-10-15 08:22:03.000000000 -0400
+++ xen-3.1.0-src.new/tools/examples/locking.sh	2007-09-12 11:25:20.000000000 -0400
@@ -1,5 +1,6 @@
 #
 # Copyright (c) 2005 XenSource Ltd.
+# Copyright (c) 2007 Red Hat
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of version 2.1 of the GNU Lesser General Public
@@ -19,80 +20,30 @@
 # Serialisation
 #
 
-LOCK_SLEEPTIME=1
-LOCK_SPINNING_RETRIES=5
-LOCK_RETRIES=100
 LOCK_BASEDIR=/var/run/xen-hotplug
 
-
-claim_lock()
-{
-  local lockdir="$LOCK_BASEDIR/$1"
-  mkdir -p "$LOCK_BASEDIR"
-  _claim_lock "$lockdir"
-}
-
-
-release_lock()
-{
-  _release_lock "$LOCK_BASEDIR/$1"
-}
-
-
-_claim_lock()
+_setlockfd()
 {
-  local lockdir="$1"
-  local owner=$(_lock_owner "$lockdir")
-  local retries=0
-
-  while [ $retries -lt $LOCK_RETRIES ]
-  do
-    mkdir "$lockdir" 2>/dev/null && trap "release_lock $1; sigerr" ERR &&
-      _update_lock_info "$lockdir" && return
-
-    local new_owner=$(_lock_owner "$lockdir")
-    if [ "$new_owner" != "$owner" ]
-    then
-      owner="$new_owner"
-      retries=0
-    fi
-
-    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
-    then
-      sleep $LOCK_SLEEPTIME
-    else
-      sleep 0
-    fi
-    retries=$(($retries + 1))
-  done
-  _steal_lock "$lockdir"
+    local i
+    for ((i = 0; i < ${#_lockdict}; i++))
+    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
+    done
+    _lockdict[$i]="$1"
+    let _lockfd=200+i
 }
 
 
-_release_lock()
-{
-  trap sigerr ERR
-  rm -rf "$1" 2>/dev/null || true
-}
-
-
-_steal_lock()
-{
-  local lockdir="$1"
-  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
-  log err "Forced to steal lock on $lockdir from $owner!"
-  _release_lock "$lockdir"
-  _claim_lock "$lockdir"
-}
-
-
-_lock_owner()
+claim_lock()
 {
-  cat "$1/owner" 2>/dev/null || echo "unknown"
+    mkdir -p "$LOCK_BASEDIR"
+    _setlockfd $1
+    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
+    flock -x $_lockfd
 }
 
 
-_update_lock_info()
+release_lock()
 {
-  echo "$$: $0" >"$1/owner"
+    _setlockfd $1
+    flock -u $_lockfd
 }



Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:20:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgNJ-0008Kv-Tv; Thu, 21 Jun 2012 12:20:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <berrange@redhat.com>) id 1ShgNI-0008Kh-7l
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:20:36 +0000
Received: from [85.158.139.83:2311] by server-7.bemta-5.messagelabs.com id
	52/7A-28276-39113EF4; Thu, 21 Jun 2012 12:20:35 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340281233!17551643!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6892 invoked from network); 21 Jun 2012 12:20:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 12:20:34 -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 q5LCKRM5002945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 08:20:27 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q5LCKNWE022571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 21 Jun 2012 08:20:25 -0400
Date: Thu, 21 Jun 2012 13:20:22 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621122022.GO21124@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340279364.21872.118.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Andrew Jones <drjones@redhat.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" <berrange@redhat.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, Jun 21, 2012 at 12:49:24PM +0100, Ian Campbell wrote:
> On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
> > On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> > > On 06/20/2012 11:34 AM, Ian Campbell wrote:
> > > > On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> > > >> # HG changeset patch
> > > >> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> > > >> # Date 1339608534 14400
> > > >> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> > > >> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> > > >> tools/hotplug: fix locking
> > > > A better title would be "tools/hotplug: Switch to locking with flock"
> > > > since "fix" is not very descriptive.
> > > Agree.
> > > >
> > > > The commit message should also state why changing this scheme is
> > > > preferable to fixing the current one.
> > > I have two points:
> > > 
> > > 1. No timeout: in the old one, if one process holding the lock more than 100
> > >    seconds, other processes could steal it.
> > > 2. No leftovers: if a process holding this lock is dead, it will close the lock
> > >    file, so it will not affect other processes.
> > > 
> > > >
> > > > Is this flock tool widely available? Does it need to be added to the
> > > > dependencies in the README?
> > > It is widely distributed: it's part of the util-linux package. So I think no
> > > need to document it.
> > > >
> > > >> The current locking implementation would allow two processes get the lock
> > > >> simultaneously:
> > > > [...snip shell trace...]
> > > >
> > > > Can you add a line or two of analysis to explain where in that shell
> > > > spew things are actually going wrong and why?
> > > I didn't spent much time on this complicated implement. But it fails for me and
> > > also for others (from response).
> > > >
> > > >> This patch is ported from Red Hat Enterprise Linux 5.8.
> > > > I think we need a Signed-off-by from the original patch author. (Unless
> > > > DCO clause b somehow applies?)
> > > I'm not sure how to handle this. There's no signed-off-by on the original Red
> > > Hat patch. Could anyone in Red Hat help to get it signed off?
> > 
> > Perhaps Andrew Jones or Don Dutile can point us in the right direction
> > (both CCd) if you identify the precise source of the patch (i.e. the
> > name of the .src.rpm and the name of the patch within it)?
> > 
> > I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
> > recent) but maybe I'm looking in the wrong place.
> 
> Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
> that RH shipped kernel+xen in a single source package, oh well).
> 
> %changelog says:
>         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
>         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
> 
> Daniel CCd.
> 
> I wonder if there were any followup fixes or changes, especially wrt to
> your point 1 above (the lack of a timeout now) requiring xend (or now
> libxl) changes?

Removing any kind of timeout was in fact the point of this change.
We do not want hotplug scripts stealing each others locks, or
timing out, because the timeouts cause alot of problems when
launching guests on a highly loaded machine where execution time
can be alot longer than a timeout setting may expect.

I expect you can't see the original BZ ticket quoted, since it
has customer information in it.  Here is my description of
what the problem we weere solving was:

[quote]
In the normal case of a single domain booting with one disk, the disk hotplug
script will fire once. In this case taking out the lock will never cause a sleep
because there's no other concurrent invocations. If a domain has 4 disks
configured, then the hotplug script will fire 4 times, all 4 invocations at
pretty much the same time. If there is even a little load on the system, the
locking function in the shell script will sleep for a few seconds - as many as 5
seconds, or potentially even time out & fail completely.

If say 4 or even more domains each with 4 disks start up at once, that's 16
invocations of the hotplug script running at once. There will be alot of sleep's
done & because of the very coarse 1 second granularity the delay can add up
significantly. 

The change to using flock() removes the arbitrary 1 second sleep, so the very
instant once hotplug script finishes, another can start & there is no repeated
attempts & failures to lock which would add more delay.
[/quote]

Usually it was our policy to send all these kind of patches upstream,
so I'm not really sure why this was not already merged. Possibly I
forgot to submit it, or maybe it was rejected - I honestly can't
remember.

Below is the original patch I wrote, to which I apply:

  Signed-off-by: Daniel P. Berrange.

diff -rup xen-3.1.0-src.orig/tools/examples/locking.sh xen-3.1.0-src.new/tools/examples/locking.sh
--- xen-3.1.0-src.orig/tools/examples/locking.sh	2006-10-15 08:22:03.000000000 -0400
+++ xen-3.1.0-src.new/tools/examples/locking.sh	2007-09-12 11:25:20.000000000 -0400
@@ -1,5 +1,6 @@
 #
 # Copyright (c) 2005 XenSource Ltd.
+# Copyright (c) 2007 Red Hat
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of version 2.1 of the GNU Lesser General Public
@@ -19,80 +20,30 @@
 # Serialisation
 #
 
-LOCK_SLEEPTIME=1
-LOCK_SPINNING_RETRIES=5
-LOCK_RETRIES=100
 LOCK_BASEDIR=/var/run/xen-hotplug
 
-
-claim_lock()
-{
-  local lockdir="$LOCK_BASEDIR/$1"
-  mkdir -p "$LOCK_BASEDIR"
-  _claim_lock "$lockdir"
-}
-
-
-release_lock()
-{
-  _release_lock "$LOCK_BASEDIR/$1"
-}
-
-
-_claim_lock()
+_setlockfd()
 {
-  local lockdir="$1"
-  local owner=$(_lock_owner "$lockdir")
-  local retries=0
-
-  while [ $retries -lt $LOCK_RETRIES ]
-  do
-    mkdir "$lockdir" 2>/dev/null && trap "release_lock $1; sigerr" ERR &&
-      _update_lock_info "$lockdir" && return
-
-    local new_owner=$(_lock_owner "$lockdir")
-    if [ "$new_owner" != "$owner" ]
-    then
-      owner="$new_owner"
-      retries=0
-    fi
-
-    if [ $retries -gt $LOCK_SPINNING_RETRIES ]
-    then
-      sleep $LOCK_SLEEPTIME
-    else
-      sleep 0
-    fi
-    retries=$(($retries + 1))
-  done
-  _steal_lock "$lockdir"
+    local i
+    for ((i = 0; i < ${#_lockdict}; i++))
+    do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
+    done
+    _lockdict[$i]="$1"
+    let _lockfd=200+i
 }
 
 
-_release_lock()
-{
-  trap sigerr ERR
-  rm -rf "$1" 2>/dev/null || true
-}
-
-
-_steal_lock()
-{
-  local lockdir="$1"
-  local owner=$(cat "$lockdir/owner" 2>/dev/null || echo "unknown")
-  log err "Forced to steal lock on $lockdir from $owner!"
-  _release_lock "$lockdir"
-  _claim_lock "$lockdir"
-}
-
-
-_lock_owner()
+claim_lock()
 {
-  cat "$1/owner" 2>/dev/null || echo "unknown"
+    mkdir -p "$LOCK_BASEDIR"
+    _setlockfd $1
+    eval "exec $_lockfd>>$LOCK_BASEDIR/$1"
+    flock -x $_lockfd
 }
 
 
-_update_lock_info()
+release_lock()
 {
-  echo "$$: $0" >"$1/owner"
+    _setlockfd $1
+    flock -u $_lockfd
 }



Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:24:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:24: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 1ShgQQ-0000Aw-N2; Thu, 21 Jun 2012 12:23:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <berrange@redhat.com>) id 1ShgQP-0000An-GK
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:23:49 +0000
Received: from [85.158.138.51:9081] by server-2.bemta-3.messagelabs.com id
	70/B1-10266-45213EF4; Thu, 21 Jun 2012 12:23:48 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340281427!28798864!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30621 invoked from network); 21 Jun 2012 12:23:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 12:23:47 -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 q5LCNfjE028114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 08:23:41 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q5LCNbwc009943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 21 Jun 2012 08:23:40 -0400
Date: Thu, 21 Jun 2012 13:23:37 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20120621122337.GP21124@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<4FE30ED3.6040805@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE30ED3.6040805@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" <berrange@redhat.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, Jun 21, 2012 at 08:08:51AM -0400, Zhigang Wang wrote:
> On 06/21/2012 07:49 AM, Ian Campbell wrote:
> > On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
> >> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> >>> On 06/20/2012 11:34 AM, Ian Campbell wrote:
> >>>> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> >>>>> # HG changeset patch
> >>>>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> >>>>> # Date 1339608534 14400
> >>>>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> >>>>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> >>>>> tools/hotplug: fix locking
> >>>> A better title would be "tools/hotplug: Switch to locking with flock"
> >>>> since "fix" is not very descriptive.
> >>> Agree.
> >>>> The commit message should also state why changing this scheme is
> >>>> preferable to fixing the current one.
> >>> I have two points:
> >>>
> >>> 1. No timeout: in the old one, if one process holding the lock more than 100
> >>>    seconds, other processes could steal it.
> >>> 2. No leftovers: if a process holding this lock is dead, it will close the lock
> >>>    file, so it will not affect other processes.
> >>>
> >>>> Is this flock tool widely available? Does it need to be added to the
> >>>> dependencies in the README?
> >>> It is widely distributed: it's part of the util-linux package. So I think no
> >>> need to document it.
> >>>>> The current locking implementation would allow two processes get the lock
> >>>>> simultaneously:
> >>>> [...snip shell trace...]
> >>>>
> >>>> Can you add a line or two of analysis to explain where in that shell
> >>>> spew things are actually going wrong and why?
> >>> I didn't spent much time on this complicated implement. But it fails for me and
> >>> also for others (from response).
> >>>>> This patch is ported from Red Hat Enterprise Linux 5.8.
> >>>> I think we need a Signed-off-by from the original patch author. (Unless
> >>>> DCO clause b somehow applies?)
> >>> I'm not sure how to handle this. There's no signed-off-by on the original Red
> >>> Hat patch. Could anyone in Red Hat help to get it signed off?
> >> Perhaps Andrew Jones or Don Dutile can point us in the right direction
> >> (both CCd) if you identify the precise source of the patch (i.e. the
> >> name of the .src.rpm and the name of the patch within it)?
> >>
> >> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
> >> recent) but maybe I'm looking in the wrong place.
> > Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
> > that RH shipped kernel+xen in a single source package, oh well).
> >
> > %changelog says:
> >         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
> >         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
> >
> > Daniel CCd.
> >
> > I wonder if there were any followup fixes or changes, especially wrt to
> > your point 1 above (the lack of a timeout now) requiring xend (or now
> > libxl) changes?
> 
> We have another timeout in xend/xl: if device backend is not setup properly, the
> device creation will fail.
> 
> Without any timeout for this locking, all backend uevent scripts will hang if
> one goes wrong. Just stealing the lock upon timeoutis not a good idea: it may
> cause error or damage. What about adding a long (10minutes) timeout? (by adding
> -w/--wait/--timeout 600)

Timeouts are a really bad idea for this area of code. If you make the
timeout really long (10 mins as you suggest), then no other guest can
be started during this entire 10 minute window if something goes wrong.
IMHO this is unacceptable.  If you make the timeout short enough that
you don't unduly delay other VM startup operations, then you will often
hit bogus timeouts under high load.

In practice the scripts should not hang unless something is seriously
wrong, in which case timing out & pretending every thing is still fine
for the future is bogus.  If you have real world examples of hangs
then you should focus efforts on fixing the hangs, rather than papering
over the problem with a timeout.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:24:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:24: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 1ShgQQ-0000Aw-N2; Thu, 21 Jun 2012 12:23:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <berrange@redhat.com>) id 1ShgQP-0000An-GK
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:23:49 +0000
Received: from [85.158.138.51:9081] by server-2.bemta-3.messagelabs.com id
	70/B1-10266-45213EF4; Thu, 21 Jun 2012 12:23:48 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340281427!28798864!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30621 invoked from network); 21 Jun 2012 12:23:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 12:23:47 -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 q5LCNfjE028114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 08:23:41 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q5LCNbwc009943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 21 Jun 2012 08:23:40 -0400
Date: Thu, 21 Jun 2012 13:23:37 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Message-ID: <20120621122337.GP21124@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<4FE30ED3.6040805@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE30ED3.6040805@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" <berrange@redhat.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, Jun 21, 2012 at 08:08:51AM -0400, Zhigang Wang wrote:
> On 06/21/2012 07:49 AM, Ian Campbell wrote:
> > On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
> >> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
> >>> On 06/20/2012 11:34 AM, Ian Campbell wrote:
> >>>> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
> >>>>> # HG changeset patch
> >>>>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> >>>>> # Date 1339608534 14400
> >>>>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
> >>>>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
> >>>>> tools/hotplug: fix locking
> >>>> A better title would be "tools/hotplug: Switch to locking with flock"
> >>>> since "fix" is not very descriptive.
> >>> Agree.
> >>>> The commit message should also state why changing this scheme is
> >>>> preferable to fixing the current one.
> >>> I have two points:
> >>>
> >>> 1. No timeout: in the old one, if one process holding the lock more than 100
> >>>    seconds, other processes could steal it.
> >>> 2. No leftovers: if a process holding this lock is dead, it will close the lock
> >>>    file, so it will not affect other processes.
> >>>
> >>>> Is this flock tool widely available? Does it need to be added to the
> >>>> dependencies in the README?
> >>> It is widely distributed: it's part of the util-linux package. So I think no
> >>> need to document it.
> >>>>> The current locking implementation would allow two processes get the lock
> >>>>> simultaneously:
> >>>> [...snip shell trace...]
> >>>>
> >>>> Can you add a line or two of analysis to explain where in that shell
> >>>> spew things are actually going wrong and why?
> >>> I didn't spent much time on this complicated implement. But it fails for me and
> >>> also for others (from response).
> >>>>> This patch is ported from Red Hat Enterprise Linux 5.8.
> >>>> I think we need a Signed-off-by from the original patch author. (Unless
> >>>> DCO clause b somehow applies?)
> >>> I'm not sure how to handle this. There's no signed-off-by on the original Red
> >>> Hat patch. Could anyone in Red Hat help to get it signed off?
> >> Perhaps Andrew Jones or Don Dutile can point us in the right direction
> >> (both CCd) if you identify the precise source of the patch (i.e. the
> >> name of the .src.rpm and the name of the patch within it)?
> >>
> >> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
> >> recent) but maybe I'm looking in the wrong place.
> > Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
> > that RH shipped kernel+xen in a single source package, oh well).
> >
> > %changelog says:
> >         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
> >         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
> >
> > Daniel CCd.
> >
> > I wonder if there were any followup fixes or changes, especially wrt to
> > your point 1 above (the lack of a timeout now) requiring xend (or now
> > libxl) changes?
> 
> We have another timeout in xend/xl: if device backend is not setup properly, the
> device creation will fail.
> 
> Without any timeout for this locking, all backend uevent scripts will hang if
> one goes wrong. Just stealing the lock upon timeoutis not a good idea: it may
> cause error or damage. What about adding a long (10minutes) timeout? (by adding
> -w/--wait/--timeout 600)

Timeouts are a really bad idea for this area of code. If you make the
timeout really long (10 mins as you suggest), then no other guest can
be started during this entire 10 minute window if something goes wrong.
IMHO this is unacceptable.  If you make the timeout short enough that
you don't unduly delay other VM startup operations, then you will often
hit bogus timeouts under high load.

In practice the scripts should not hang unless something is seriously
wrong, in which case timing out & pretending every thing is still fine
for the future is bogus.  If you have real world examples of hangs
then you should focus efforts on fixing the hangs, rather than papering
over the problem with a timeout.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:28:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgUl-0000NV-EQ; Thu, 21 Jun 2012 12:28: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 1ShgUk-0000NN-9e
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:28:18 +0000
Received: from [85.158.139.83:13075] by server-10.bemta-5.messagelabs.com id
	73/52-02190-16313EF4; Thu, 21 Jun 2012 12:28:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340281696!23676776!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8662 invoked from network); 21 Jun 2012 12:28:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 12:28:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:28:16 +0100
Message-Id: <4FE32FAA020000780008B157@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:28:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com><4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	(Jan Beulich's message of "Thu, 21 Jun 2012 10:59:55 +0100")
	<8762ak9b29.fsf@xmission.com>
In-Reply-To: <8762ak9b29.fsf@xmission.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, Wei Wang <wei.wang2@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 13:08, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Jan Beulich" <JBeulich@suse.com> writes:
> 
>>>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
>>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>> Have you at all considered getting this fixed on the kernel side?
>>>> As I don't have direct access to any AMD IOMMU capable
>>>> system - can one, other than by enumerating the respective
>>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>>> devices in question (e.g. via vendor/class/sub-class or some
>>>> such)? That might permit skipping those in the offending kernel
>>>> code...
>>> 
>>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
>>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
>>> should be enough to identify amd iommu device. I could send you a kernel 
>>> patch for review using this approach. I would believe that fixing this 
>>> issue in 4.2, no matter how, is really important for amd iommu.
>>
>> As you didn't come forward with anything, here's my first
>> take on this:
>>
>> Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
>> interrupts when we initialize a pci device") caused MSI to get disabled
>> on Xen Dom0 despite it having got turned on purposefully by the
>> hypervisor. As an immediate band aid, suppress the disabling in this
>> specific case.
>>
>> I don't think, however, that either the original change or this fix are
>> really appropriate. The original fix, besides leaving aside the
>> presence of a hypervisor like Xen, doesn't deal with all possible
>> cases (in particular it has no effect if the secondary kernel was built
>> with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
>> Xen, the logic like this should probably be skipped altogether (i.e. it
>> should be entirely left to the hypervisor, being the entity in control
>> of IRQs).
> 
> The original fix is fine. Xen dom0 remains insane.  Although perhaps
> some better than Xen dom0 once was.
> 
> Why does the dom0 kernel even get any access to pci devices that
> Xen doesn't want it to touch?
> 
> As far as I can tell my patch has revealed a design bug in Xen.  If you
> don't want to be messed up by the kernel don't let the kernel touch
> things.

I rather think this is a design bug of the AMD IOMMU - it should
never have got surfaced as a PCI device.

Furthermore, fully hiding _any_ PCI device from Dom0 has its
own set of problems - depending on the nature of the device,
full emulation of all devices may become necessary to get this
implemented (because this can implicitly hide other devices, or
the Dom0 kernel re-assigning BARs could get in conflict with
what the hidden devices use).

Xen's model has always been to allow Dom0 full control over all
peripherals and bridges, so if all of the sudden PCI devices of
other kinds show up, we can't simply re-model everything.

>  At the very least we need an abstraction much cleaner
> than the patch below.

Probably - any suggestion? As said in the mail I sent, this is
meant to overcome the immediate problem, and a more
permanent fix would be desirable (ideally suppressing the
playing with the MSI related data altogether, following the
rest of the MSI support in Xen/Dom0).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:28:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgUl-0000NV-EQ; Thu, 21 Jun 2012 12:28: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 1ShgUk-0000NN-9e
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:28:18 +0000
Received: from [85.158.139.83:13075] by server-10.bemta-5.messagelabs.com id
	73/52-02190-16313EF4; Thu, 21 Jun 2012 12:28:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340281696!23676776!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8662 invoked from network); 21 Jun 2012 12:28:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 12:28:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:28:16 +0100
Message-Id: <4FE32FAA020000780008B157@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:28:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com><4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	(Jan Beulich's message of "Thu, 21 Jun 2012 10:59:55 +0100")
	<8762ak9b29.fsf@xmission.com>
In-Reply-To: <8762ak9b29.fsf@xmission.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, Wei Wang <wei.wang2@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 13:08, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Jan Beulich" <JBeulich@suse.com> writes:
> 
>>>>> On 14.06.12 at 17:15, Wei Wang <wei.wang2@amd.com> wrote:
>>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>> Have you at all considered getting this fixed on the kernel side?
>>>> As I don't have direct access to any AMD IOMMU capable
>>>> system - can one, other than by enumerating the respective
>>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>>> devices in question (e.g. via vendor/class/sub-class or some
>>>> such)? That might permit skipping those in the offending kernel
>>>> code...
>>> 
>>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral) 
>>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this 
>>> should be enough to identify amd iommu device. I could send you a kernel 
>>> patch for review using this approach. I would believe that fixing this 
>>> issue in 4.2, no matter how, is really important for amd iommu.
>>
>> As you didn't come forward with anything, here's my first
>> take on this:
>>
>> Commit d5dea7d95c48d7bc951cee4910a7fd9c0cd26fb0 ("PCI: msi: Disable msi
>> interrupts when we initialize a pci device") caused MSI to get disabled
>> on Xen Dom0 despite it having got turned on purposefully by the
>> hypervisor. As an immediate band aid, suppress the disabling in this
>> specific case.
>>
>> I don't think, however, that either the original change or this fix are
>> really appropriate. The original fix, besides leaving aside the
>> presence of a hypervisor like Xen, doesn't deal with all possible
>> cases (in particular it has no effect if the secondary kernel was built
>> with CONFIG_PCI_MSI unset). And taking into account a hypervisor like
>> Xen, the logic like this should probably be skipped altogether (i.e. it
>> should be entirely left to the hypervisor, being the entity in control
>> of IRQs).
> 
> The original fix is fine. Xen dom0 remains insane.  Although perhaps
> some better than Xen dom0 once was.
> 
> Why does the dom0 kernel even get any access to pci devices that
> Xen doesn't want it to touch?
> 
> As far as I can tell my patch has revealed a design bug in Xen.  If you
> don't want to be messed up by the kernel don't let the kernel touch
> things.

I rather think this is a design bug of the AMD IOMMU - it should
never have got surfaced as a PCI device.

Furthermore, fully hiding _any_ PCI device from Dom0 has its
own set of problems - depending on the nature of the device,
full emulation of all devices may become necessary to get this
implemented (because this can implicitly hide other devices, or
the Dom0 kernel re-assigning BARs could get in conflict with
what the hidden devices use).

Xen's model has always been to allow Dom0 full control over all
peripherals and bridges, so if all of the sudden PCI devices of
other kinds show up, we can't simply re-model everything.

>  At the very least we need an abstraction much cleaner
> than the patch below.

Probably - any suggestion? As said in the mail I sent, this is
meant to overcome the immediate problem, and a more
permanent fix would be desirable (ideally suppressing the
playing with the MSI related data altogether, following the
rest of the MSI support in Xen/Dom0).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:31:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1ShgXs-0000Vv-1K; Thu, 21 Jun 2012 12:31:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShgXq-0000Vm-EE
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:31:30 +0000
Received: from [85.158.139.83:44693] by server-1.bemta-5.messagelabs.com id
	C4/52-19721-12413EF4; Thu, 21 Jun 2012 12:31:29 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340281888!28847430!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10904 invoked from network); 21 Jun 2012 12:31:28 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.144)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 12:31:28 -0000
Received: from mail48-db3-R.bigfish.com (10.3.81.236) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 12:30:01 +0000
Received: from mail48-db3 (localhost [127.0.0.1])	by mail48-db3-R.bigfish.com
	(Postfix) with ESMTP id 077494001E5;
	Thu, 21 Jun 2012 12:30:01 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail48-db3 (localhost.localdomain [127.0.0.1]) by mail48-db3
	(MessageSwitch) id 1340281798868061_31269;
	Thu, 21 Jun 2012 12:29:58 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.253])	by
	mail48-db3.bigfish.com (Postfix) with ESMTP id D0D793C0047;
	Thu, 21 Jun 2012 12:29:58 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 12:29:58 +0000
X-WSS-ID: 0M5YW49-01-24D-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22DD71028009;	Thu, 21 Jun 2012 07:31:20 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 07:31:37 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 07:31:20 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	08:30:49 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A1FE149C69D; Thu, 21 Jun 2012
	13:30:47 +0100 (BST)
Message-ID: <4FE31385.3060502@amd.com>
Date: Thu, 21 Jun 2012 14:28:53 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
In-Reply-To: <4FE32A81020000780008B11B@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 02:06 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 13:21, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/21/2012 11:59 AM, Jan Beulich wrote:
>>>>>> On 14.06.12 at 17:15, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>>> Have you at all considered getting this fixed on the kernel side?
>>>>> As I don't have direct access to any AMD IOMMU capable
>>>>> system - can one, other than by enumerating the respective
>>>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>>>> devices in question (e.g. via vendor/class/sub-class or some
>>>>> such)? That might permit skipping those in the offending kernel
>>>>> code...
>>>>
>>>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral)
>>>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this
>>>> should be enough to identify amd iommu device. I could send you a kernel
>>>> patch for review using this approach. I would believe that fixing this
>>>> issue in 4.2, no matter how, is really important for amd iommu.
>>>
>>> As you didn't come forward with anything, here's my first
>>> take on this:
>>
>> Hi Jan
>> Thanks a lot for the patch. Actually I plan to send my version today,
>> which is based on 3.4 pv_ops but looks very similar to yours. So, Acked!
>>
>> I also evaluated the possibility of hiding iommu device from dom0. I
>> think the change is no quite a lot, at least, for io based pcicfg
>> access. A proof-of-concept patch is attached.
>
> This completely hides the device from Dom0, but only when
> config space is accessed via method 1. Did you not see my
> earlier patch doing this for MCFG as well
Could you please provide a particular c/s number?... (I saw too many c/s 
might be related to this topic). so that I could work out a patch to 
support both i/o and mmcfg.

(albeit only disallowing
> writes, so allowing the device to still be seen by Dom0)?
Sounds better to me...this still allows user to check iommu status from 
lspci.

> Whether completely hiding the device is actually okay I can't
> easily tell: Would IOMMUs always be either at func 0 of a single-
> unction device, or at a non-zero func of a multi-function one? If
> not, other devices may get hidden implicitly.

AMD IOMMU is an independent pci-e endpoint, and this function will not 
be used for other purposes other than containing an iommu. So I don't 
see that iommu will share bdf value with other devices.

Thanks,
Wei

> Also I noticed just now that guest_io_read() wouldn't really
> behave correctly when pci_cfg_ok() returned false - it might
> pass back 0xff even for a multi-byte read. I'll send a fix shortly.
>
> Jan
>
>> --- a/xen/arch/x86/traps.c      Thu Jun 21 11:30:59 2012 +0200
>> +++ b/xen/arch/x86/traps.c      Thu Jun 21 13:19:02 2012 +0200
>> @@ -73,6 +73,7 @@
>>    #include<asm/hpet.h>
>>    #include<public/arch-x86/cpuid.h>
>>    #include<xsm/xsm.h>
>> +#include<asm/hvm/svm/amd-iommu-proto.h>
>>
>>    /*
>>     * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
>> @@ -1686,10 +1687,19 @@ static int pci_cfg_ok(struct domain *d,
>>    {
>>        uint32_t machine_bdf;
>>        uint16_t start, end;
>> +    struct amd_iommu *iommu;
>> +
>>        if (!IS_PRIV(d))
>>            return 0;
>>
>>        machine_bdf = (d->arch.pci_cf8>>  8)&  0xFFFF;
>> +
>> +    for_each_amd_iommu ( iommu )
>> +    {
>> +        if ( machine_bdf == iommu->bdf )
>> +            return 0;
>> +    }
>> +
>>        start = d->arch.pci_cf8&  0xFF;
>>        end = start + size - 1;
>>        if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:31:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1ShgXs-0000Vv-1K; Thu, 21 Jun 2012 12:31:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShgXq-0000Vm-EE
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:31:30 +0000
Received: from [85.158.139.83:44693] by server-1.bemta-5.messagelabs.com id
	C4/52-19721-12413EF4; Thu, 21 Jun 2012 12:31:29 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340281888!28847430!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10904 invoked from network); 21 Jun 2012 12:31:28 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.144)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 12:31:28 -0000
Received: from mail48-db3-R.bigfish.com (10.3.81.236) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 12:30:01 +0000
Received: from mail48-db3 (localhost [127.0.0.1])	by mail48-db3-R.bigfish.com
	(Postfix) with ESMTP id 077494001E5;
	Thu, 21 Jun 2012 12:30:01 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail48-db3 (localhost.localdomain [127.0.0.1]) by mail48-db3
	(MessageSwitch) id 1340281798868061_31269;
	Thu, 21 Jun 2012 12:29:58 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.253])	by
	mail48-db3.bigfish.com (Postfix) with ESMTP id D0D793C0047;
	Thu, 21 Jun 2012 12:29:58 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 12:29:58 +0000
X-WSS-ID: 0M5YW49-01-24D-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 22DD71028009;	Thu, 21 Jun 2012 07:31:20 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 07:31:37 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 07:31:20 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	08:30:49 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A1FE149C69D; Thu, 21 Jun 2012
	13:30:47 +0100 (BST)
Message-ID: <4FE31385.3060502@amd.com>
Date: Thu, 21 Jun 2012 14:28:53 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
In-Reply-To: <4FE32A81020000780008B11B@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 02:06 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 13:21, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/21/2012 11:59 AM, Jan Beulich wrote:
>>>>>> On 14.06.12 at 17:15, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> Am 14.06.2012 16:18, schrieb Jan Beulich:
>>>>> Have you at all considered getting this fixed on the kernel side?
>>>>> As I don't have direct access to any AMD IOMMU capable
>>>>> system - can one, other than by enumerating the respective
>>>>> PCI IDs or reading ACPI tables, reasonably easily identify the
>>>>> devices in question (e.g. via vendor/class/sub-class or some
>>>>> such)? That might permit skipping those in the offending kernel
>>>>> code...
>>>>
>>>> AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral)
>>>> and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this
>>>> should be enough to identify amd iommu device. I could send you a kernel
>>>> patch for review using this approach. I would believe that fixing this
>>>> issue in 4.2, no matter how, is really important for amd iommu.
>>>
>>> As you didn't come forward with anything, here's my first
>>> take on this:
>>
>> Hi Jan
>> Thanks a lot for the patch. Actually I plan to send my version today,
>> which is based on 3.4 pv_ops but looks very similar to yours. So, Acked!
>>
>> I also evaluated the possibility of hiding iommu device from dom0. I
>> think the change is no quite a lot, at least, for io based pcicfg
>> access. A proof-of-concept patch is attached.
>
> This completely hides the device from Dom0, but only when
> config space is accessed via method 1. Did you not see my
> earlier patch doing this for MCFG as well
Could you please provide a particular c/s number?... (I saw too many c/s 
might be related to this topic). so that I could work out a patch to 
support both i/o and mmcfg.

(albeit only disallowing
> writes, so allowing the device to still be seen by Dom0)?
Sounds better to me...this still allows user to check iommu status from 
lspci.

> Whether completely hiding the device is actually okay I can't
> easily tell: Would IOMMUs always be either at func 0 of a single-
> unction device, or at a non-zero func of a multi-function one? If
> not, other devices may get hidden implicitly.

AMD IOMMU is an independent pci-e endpoint, and this function will not 
be used for other purposes other than containing an iommu. So I don't 
see that iommu will share bdf value with other devices.

Thanks,
Wei

> Also I noticed just now that guest_io_read() wouldn't really
> behave correctly when pci_cfg_ok() returned false - it might
> pass back 0xff even for a multi-byte read. I'll send a fix shortly.
>
> Jan
>
>> --- a/xen/arch/x86/traps.c      Thu Jun 21 11:30:59 2012 +0200
>> +++ b/xen/arch/x86/traps.c      Thu Jun 21 13:19:02 2012 +0200
>> @@ -73,6 +73,7 @@
>>    #include<asm/hpet.h>
>>    #include<public/arch-x86/cpuid.h>
>>    #include<xsm/xsm.h>
>> +#include<asm/hvm/svm/amd-iommu-proto.h>
>>
>>    /*
>>     * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
>> @@ -1686,10 +1687,19 @@ static int pci_cfg_ok(struct domain *d,
>>    {
>>        uint32_t machine_bdf;
>>        uint16_t start, end;
>> +    struct amd_iommu *iommu;
>> +
>>        if (!IS_PRIV(d))
>>            return 0;
>>
>>        machine_bdf = (d->arch.pci_cf8>>  8)&  0xFFFF;
>> +
>> +    for_each_amd_iommu ( iommu )
>> +    {
>> +        if ( machine_bdf == iommu->bdf )
>> +            return 0;
>> +    }
>> +
>>        start = d->arch.pci_cf8&  0xFF;
>>        end = start + size - 1;
>>        if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:44:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shgjp-00013K-V3; Thu, 21 Jun 2012 12:43: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 1Shgjo-00013E-KP
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:43:52 +0000
Received: from [85.158.139.83:43163] by server-1.bemta-5.messagelabs.com id
	B4/5B-19721-70713EF4; Thu, 21 Jun 2012 12:43:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340282631!28729545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23211 invoked from network); 21 Jun 2012 12:43:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 12:43:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13147690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 12:43:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 13:43:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Shgjm-0004CX-CA; Thu, 21 Jun 2012 12:43:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Shgjm-0001H4-8T;
	Thu, 21 Jun 2012 13:43:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.5894.186007.344630@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 13:43:50 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"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] xl: fix sedf parameters 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

Dario Faggioli writes ("[PATCH] xl: fix sedf parameters checking"):
> 9d1fd58ff602 was bogous in not letting a new domain being created
> if its scheduling parameters --when running under the sedf scheduler--
> were not fully specified, making creation fail like in this example
> here below:

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I fix a typo in the commit message.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:44:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shgjp-00013K-V3; Thu, 21 Jun 2012 12:43: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 1Shgjo-00013E-KP
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 12:43:52 +0000
Received: from [85.158.139.83:43163] by server-1.bemta-5.messagelabs.com id
	B4/5B-19721-70713EF4; Thu, 21 Jun 2012 12:43:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340282631!28729545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23211 invoked from network); 21 Jun 2012 12:43:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 12:43:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13147690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 12:43:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 13:43:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Shgjm-0004CX-CA; Thu, 21 Jun 2012 12:43:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Shgjm-0001H4-8T;
	Thu, 21 Jun 2012 13:43:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.5894.186007.344630@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 13:43:50 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"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] xl: fix sedf parameters 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

Dario Faggioli writes ("[PATCH] xl: fix sedf parameters checking"):
> 9d1fd58ff602 was bogous in not letting a new domain being created
> if its scheduling parameters --when running under the sedf scheduler--
> were not fully specified, making creation fail like in this example
> here below:

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I fix a typo in the commit message.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:44:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgkW-00016O-DK; Thu, 21 Jun 2012 12:44: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 1ShgkU-00016G-HE
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:44:34 +0000
Received: from [85.158.143.99:35597] by server-1.bemta-4.messagelabs.com id
	80/52-24392-13713EF4; Thu, 21 Jun 2012 12:44:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340282673!25080359!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23553 invoked from network); 21 Jun 2012 12:44:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 12:44:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:44:32 +0100
Message-Id: <4FE3337C020000780008B177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:45:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
In-Reply-To: <4FE31385.3060502@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 14:28, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/21/2012 02:06 PM, Jan Beulich wrote:
>>>>> On 21.06.12 at 13:21, Wei Wang<wei.wang2@amd.com>  wrote:
>>> I also evaluated the possibility of hiding iommu device from dom0. I
>>> think the change is no quite a lot, at least, for io based pcicfg
>>> access. A proof-of-concept patch is attached.
>>
>> This completely hides the device from Dom0, but only when
>> config space is accessed via method 1. Did you not see my
>> earlier patch doing this for MCFG as well
> Could you please provide a particular c/s number?... (I saw too many c/s 
> might be related to this topic). so that I could work out a patch to 
> support both i/o and mmcfg.

I sent this to you yesterday, so you'd be able to test whether
it actually fulfills its purpose before we discuss whether this is
acceptable for 4.2. See
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01129.html

> (albeit only disallowing
>> writes, so allowing the device to still be seen by Dom0)?
> Sounds better to me...this still allows user to check iommu status from 
> lspci.
> 
>> Whether completely hiding the device is actually okay I can't
>> easily tell: Would IOMMUs always be either at func 0 of a single-
>> unction device, or at a non-zero func of a multi-function one? If
>> not, other devices may get hidden implicitly.
> 
> AMD IOMMU is an independent pci-e endpoint, and this function will not 
> be used for other purposes other than containing an iommu. So I don't 
> see that iommu will share bdf value with other devices.

The question is not regarding bdf, but regarding whether under
the same seg:bus:dev there might be multiple functions, one of
which is the IOMMU, and if so, whether the IOMMU would be
guaranteed to have a non-zero function number.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 12:44:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 12: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 1ShgkW-00016O-DK; Thu, 21 Jun 2012 12:44: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 1ShgkU-00016G-HE
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 12:44:34 +0000
Received: from [85.158.143.99:35597] by server-1.bemta-4.messagelabs.com id
	80/52-24392-13713EF4; Thu, 21 Jun 2012 12:44:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340282673!25080359!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23553 invoked from network); 21 Jun 2012 12:44:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 12:44:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 13:44:32 +0100
Message-Id: <4FE3337C020000780008B177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 13:45:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
In-Reply-To: <4FE31385.3060502@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 14:28, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/21/2012 02:06 PM, Jan Beulich wrote:
>>>>> On 21.06.12 at 13:21, Wei Wang<wei.wang2@amd.com>  wrote:
>>> I also evaluated the possibility of hiding iommu device from dom0. I
>>> think the change is no quite a lot, at least, for io based pcicfg
>>> access. A proof-of-concept patch is attached.
>>
>> This completely hides the device from Dom0, but only when
>> config space is accessed via method 1. Did you not see my
>> earlier patch doing this for MCFG as well
> Could you please provide a particular c/s number?... (I saw too many c/s 
> might be related to this topic). so that I could work out a patch to 
> support both i/o and mmcfg.

I sent this to you yesterday, so you'd be able to test whether
it actually fulfills its purpose before we discuss whether this is
acceptable for 4.2. See
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01129.html

> (albeit only disallowing
>> writes, so allowing the device to still be seen by Dom0)?
> Sounds better to me...this still allows user to check iommu status from 
> lspci.
> 
>> Whether completely hiding the device is actually okay I can't
>> easily tell: Would IOMMUs always be either at func 0 of a single-
>> unction device, or at a non-zero func of a multi-function one? If
>> not, other devices may get hidden implicitly.
> 
> AMD IOMMU is an independent pci-e endpoint, and this function will not 
> be used for other purposes other than containing an iommu. So I don't 
> see that iommu will share bdf value with other devices.

The question is not regarding bdf, but regarding whether under
the same seg:bus:dev there might be multiple functions, one of
which is the IOMMU, and if so, whether the IOMMU would be
guaranteed to have a non-zero function number.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:04:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shh3H-0001X9-7Y; Thu, 21 Jun 2012 13:03:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Shh3F-0001X2-T6
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:03:58 +0000
Received: from [85.158.143.35:40189] by server-1.bemta-4.messagelabs.com id
	87/59-24392-DBB13EF4; Thu, 21 Jun 2012 13:03:57 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340283834!17391935!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwMTY1Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11562 invoked from network); 21 Jun 2012 13:03:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 13:03:55 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5LD3j33032244
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 13:03:46 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
	q5LD3iQ3012748
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2012 13:03:45 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
	q5LD3hBx016110; Thu, 21 Jun 2012 08:03:43 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Jun 2012 06:03:43 -0700
Message-ID: <4FE31C74.7050100@oracle.com>
Date: Thu, 21 Jun 2012 09:07:00 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: "Daniel P. Berrange" <berrange@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<4FE30ED3.6040805@oracle.com> <20120621122337.GP21124@redhat.com>
In-Reply-To: <20120621122337.GP21124@redhat.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/21/2012 08:23 AM, Daniel P. Berrange wrote:
> On Thu, Jun 21, 2012 at 08:08:51AM -0400, Zhigang Wang wrote:
>> On 06/21/2012 07:49 AM, Ian Campbell wrote:
>>> On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
>>>> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
>>>>> On 06/20/2012 11:34 AM, Ian Campbell wrote:
>>>>>> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
>>>>>>> # HG changeset patch
>>>>>>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
>>>>>>> # Date 1339608534 14400
>>>>>>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
>>>>>>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
>>>>>>> tools/hotplug: fix locking
>>>>>> A better title would be "tools/hotplug: Switch to locking with flock"
>>>>>> since "fix" is not very descriptive.
>>>>> Agree.
>>>>>> The commit message should also state why changing this scheme is
>>>>>> preferable to fixing the current one.
>>>>> I have two points:
>>>>>
>>>>> 1. No timeout: in the old one, if one process holding the lock more than 100
>>>>>    seconds, other processes could steal it.
>>>>> 2. No leftovers: if a process holding this lock is dead, it will close the lock
>>>>>    file, so it will not affect other processes.
>>>>>
>>>>>> Is this flock tool widely available? Does it need to be added to the
>>>>>> dependencies in the README?
>>>>> It is widely distributed: it's part of the util-linux package. So I think no
>>>>> need to document it.
>>>>>>> The current locking implementation would allow two processes get the lock
>>>>>>> simultaneously:
>>>>>> [...snip shell trace...]
>>>>>>
>>>>>> Can you add a line or two of analysis to explain where in that shell
>>>>>> spew things are actually going wrong and why?
>>>>> I didn't spent much time on this complicated implement. But it fails for me and
>>>>> also for others (from response).
>>>>>>> This patch is ported from Red Hat Enterprise Linux 5.8.
>>>>>> I think we need a Signed-off-by from the original patch author. (Unless
>>>>>> DCO clause b somehow applies?)
>>>>> I'm not sure how to handle this. There's no signed-off-by on the original Red
>>>>> Hat patch. Could anyone in Red Hat help to get it signed off?
>>>> Perhaps Andrew Jones or Don Dutile can point us in the right direction
>>>> (both CCd) if you identify the precise source of the patch (i.e. the
>>>> name of the .src.rpm and the name of the patch within it)?
>>>>
>>>> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
>>>> recent) but maybe I'm looking in the wrong place.
>>> Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
>>> that RH shipped kernel+xen in a single source package, oh well).
>>>
>>> %changelog says:
>>>         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
>>>         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
>>>
>>> Daniel CCd.
>>>
>>> I wonder if there were any followup fixes or changes, especially wrt to
>>> your point 1 above (the lack of a timeout now) requiring xend (or now
>>> libxl) changes?
>> We have another timeout in xend/xl: if device backend is not setup properly, the
>> device creation will fail.
>>
>> Without any timeout for this locking, all backend uevent scripts will hang if
>> one goes wrong. Just stealing the lock upon timeoutis not a good idea: it may
>> cause error or damage. What about adding a long (10minutes) timeout? (by adding
>> -w/--wait/--timeout 600)
> Timeouts are a really bad idea for this area of code. If you make the
> timeout really long (10 mins as you suggest), then no other guest can
> be started during this entire 10 minute window if something goes wrong.
> IMHO this is unacceptable.  If you make the timeout short enough that
> you don't unduly delay other VM startup operations, then you will often
> hit bogus timeouts under high load.
>
> In practice the scripts should not hang unless something is seriously
> wrong, in which case timing out & pretending every thing is still fine
> for the future is bogus.  If you have real world examples of hangs
> then you should focus efforts on fixing the hangs, rather than papering
> over the problem with a timeout.
>
> Daniel
Thanks Daniel. I agree with your points on timeout.

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:04:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shh3H-0001X9-7Y; Thu, 21 Jun 2012 13:03:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Shh3F-0001X2-T6
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:03:58 +0000
Received: from [85.158.143.35:40189] by server-1.bemta-4.messagelabs.com id
	87/59-24392-DBB13EF4; Thu, 21 Jun 2012 13:03:57 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340283834!17391935!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwMTY1Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11562 invoked from network); 21 Jun 2012 13:03:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 13:03:55 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5LD3j33032244
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 13:03:46 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
	q5LD3iQ3012748
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2012 13:03:45 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
	q5LD3hBx016110; Thu, 21 Jun 2012 08:03:43 -0500
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Jun 2012 06:03:43 -0700
Message-ID: <4FE31C74.7050100@oracle.com>
Date: Thu, 21 Jun 2012 09:07:00 -0400
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: "Daniel P. Berrange" <berrange@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<4FE30ED3.6040805@oracle.com> <20120621122337.GP21124@redhat.com>
In-Reply-To: <20120621122337.GP21124@redhat.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Andrew Jones <drjones@redhat.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/21/2012 08:23 AM, Daniel P. Berrange wrote:
> On Thu, Jun 21, 2012 at 08:08:51AM -0400, Zhigang Wang wrote:
>> On 06/21/2012 07:49 AM, Ian Campbell wrote:
>>> On Thu, 2012-06-21 at 12:42 +0100, Ian Campbell wrote:
>>>> On Wed, 2012-06-20 at 18:53 +0100, Zhigang Wang wrote:
>>>>> On 06/20/2012 11:34 AM, Ian Campbell wrote:
>>>>>> On Wed, 2012-06-13 at 18:29 +0100, Zhigang Wang wrote:
>>>>>>> # HG changeset patch
>>>>>>> # User Zhigang Wang <zhigang.x.wang@oracle.com>
>>>>>>> # Date 1339608534 14400
>>>>>>> # Node ID 650b03f412143c3057abbd0ae0e256e6b3fd2ba8
>>>>>>> # Parent  32034d1914a607d7b6f1f060352b4cac973600f8
>>>>>>> tools/hotplug: fix locking
>>>>>> A better title would be "tools/hotplug: Switch to locking with flock"
>>>>>> since "fix" is not very descriptive.
>>>>> Agree.
>>>>>> The commit message should also state why changing this scheme is
>>>>>> preferable to fixing the current one.
>>>>> I have two points:
>>>>>
>>>>> 1. No timeout: in the old one, if one process holding the lock more than 100
>>>>>    seconds, other processes could steal it.
>>>>> 2. No leftovers: if a process holding this lock is dead, it will close the lock
>>>>>    file, so it will not affect other processes.
>>>>>
>>>>>> Is this flock tool widely available? Does it need to be added to the
>>>>>> dependencies in the README?
>>>>> It is widely distributed: it's part of the util-linux package. So I think no
>>>>> need to document it.
>>>>>>> The current locking implementation would allow two processes get the lock
>>>>>>> simultaneously:
>>>>>> [...snip shell trace...]
>>>>>>
>>>>>> Can you add a line or two of analysis to explain where in that shell
>>>>>> spew things are actually going wrong and why?
>>>>> I didn't spent much time on this complicated implement. But it fails for me and
>>>>> also for others (from response).
>>>>>>> This patch is ported from Red Hat Enterprise Linux 5.8.
>>>>>> I think we need a Signed-off-by from the original patch author. (Unless
>>>>>> DCO clause b somehow applies?)
>>>>> I'm not sure how to handle this. There's no signed-off-by on the original Red
>>>>> Hat patch. Could anyone in Red Hat help to get it signed off?
>>>> Perhaps Andrew Jones or Don Dutile can point us in the right direction
>>>> (both CCd) if you identify the precise source of the patch (i.e. the
>>>> name of the .src.rpm and the name of the patch within it)?
>>>>
>>>> I looked in kernel-2.6.18-308.8.2.el5.src.rpm (which seems fairly
>>>> recent) but maybe I'm looking in the wrong place.
>>> Nevermind, I found it in xen-3.0.3-135.el5_8.2.src.rpm (I'd have sworn
>>> that RH shipped kernel+xen in a single source package, oh well).
>>>
>>> %changelog says:
>>>         * Fri Sep 14 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-40.el5
>>>         - Rewrite locking in hotplug scripts to fix timeouts (rhbz #267861)
>>>
>>> Daniel CCd.
>>>
>>> I wonder if there were any followup fixes or changes, especially wrt to
>>> your point 1 above (the lack of a timeout now) requiring xend (or now
>>> libxl) changes?
>> We have another timeout in xend/xl: if device backend is not setup properly, the
>> device creation will fail.
>>
>> Without any timeout for this locking, all backend uevent scripts will hang if
>> one goes wrong. Just stealing the lock upon timeoutis not a good idea: it may
>> cause error or damage. What about adding a long (10minutes) timeout? (by adding
>> -w/--wait/--timeout 600)
> Timeouts are a really bad idea for this area of code. If you make the
> timeout really long (10 mins as you suggest), then no other guest can
> be started during this entire 10 minute window if something goes wrong.
> IMHO this is unacceptable.  If you make the timeout short enough that
> you don't unduly delay other VM startup operations, then you will often
> hit bogus timeouts under high load.
>
> In practice the scripts should not hang unless something is seriously
> wrong, in which case timing out & pretending every thing is still fine
> for the future is bogus.  If you have real world examples of hangs
> then you should focus efforts on fixing the hangs, rather than papering
> over the problem with a timeout.
>
> Daniel
Thanks Daniel. I agree with your points on timeout.

Zhigang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:13:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:13: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 1ShhC1-0001lX-DI; Thu, 21 Jun 2012 13:13:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShhBz-0001lS-By
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:12:59 +0000
Received: from [85.158.139.83:39404] by server-7.bemta-5.messagelabs.com id
	ED/48-28276-ADD13EF4; Thu, 21 Jun 2012 13:12:58 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340284376!24877567!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9280 invoked from network); 21 Jun 2012 13:12:57 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 13:12:57 -0000
Received: from mail103-tx2-R.bigfish.com (10.9.14.244) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:11:29 +0000
Received: from mail103-tx2 (localhost [127.0.0.1])	by
	mail103-tx2-R.bigfish.com (Postfix) with ESMTP id F0D66320473;
	Thu, 21 Jun 2012 13:11:28 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail103-tx2 (localhost.localdomain [127.0.0.1]) by mail103-tx2
	(MessageSwitch) id 1340284287162916_28359;
	Thu, 21 Jun 2012 13:11:27 +0000 (UTC)
Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.245])	by
	mail103-tx2.bigfish.com (Postfix) with ESMTP id 2401C420049;
	Thu, 21 Jun 2012 13:11:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:11:22 +0000
X-WSS-ID: 0M5YY1A-01-0W8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2289F1028023;	Thu, 21 Jun 2012 08:12:46 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 08:13:03 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 08:12:46 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	09:12:46 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 19E3849C69D; Thu, 21 Jun 2012
	14:12:45 +0100 (BST)
Message-ID: <4FE31D5A.7060701@amd.com>
Date: Thu, 21 Jun 2012 15:10:50 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
	<4FE3337C020000780008B177@nat28.tlf.novell.com>
In-Reply-To: <4FE3337C020000780008B177@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 02:45 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 14:28, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/21/2012 02:06 PM, Jan Beulich wrote:
>>>>>> On 21.06.12 at 13:21, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> I also evaluated the possibility of hiding iommu device from dom0. I
>>>> think the change is no quite a lot, at least, for io based pcicfg
>>>> access. A proof-of-concept patch is attached.
>>>
>>> This completely hides the device from Dom0, but only when
>>> config space is accessed via method 1. Did you not see my
>>> earlier patch doing this for MCFG as well
>> Could you please provide a particular c/s number?... (I saw too many c/s
>> might be related to this topic). so that I could work out a patch to
>> support both i/o and mmcfg.
>
> I sent this to you yesterday, so you'd be able to test whether
> it actually fulfills its purpose before we discuss whether this is
> acceptable for 4.2. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01129.html

Oh, yes I found it, my email filter did not work well so I did not see 
it at the right folder. I will test right now.

>
>> (albeit only disallowing
>>> writes, so allowing the device to still be seen by Dom0)?
>> Sounds better to me...this still allows user to check iommu status from
>> lspci.
>>
>>> Whether completely hiding the device is actually okay I can't
>>> easily tell: Would IOMMUs always be either at func 0 of a single-
>>> unction device, or at a non-zero func of a multi-function one? If
>>> not, other devices may get hidden implicitly.
>>
>> AMD IOMMU is an independent pci-e endpoint, and this function will not
>> be used for other purposes other than containing an iommu. So I don't
>> see that iommu will share bdf value with other devices.
>
> The question is not regarding bdf, but regarding whether under
> the same seg:bus:dev there might be multiple functions, one of
> which is the IOMMU, and if so, whether the IOMMU would be
> guaranteed to have a non-zero function number.

In a real system (single or multiple iommu), amd iommu shares the same 
device number with north bridge but has function number 2.. (e.g 
bus:00.2) Howerver according to spec, it does not guaranteed to have 
non-zero function number. So what is the problem you see if iommu uses 
fun0 on a multi-func device?

Thanks,
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 Jun 21 13:13:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:13: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 1ShhC1-0001lX-DI; Thu, 21 Jun 2012 13:13:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShhBz-0001lS-By
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:12:59 +0000
Received: from [85.158.139.83:39404] by server-7.bemta-5.messagelabs.com id
	ED/48-28276-ADD13EF4; Thu, 21 Jun 2012 13:12:58 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340284376!24877567!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9280 invoked from network); 21 Jun 2012 13:12:57 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 13:12:57 -0000
Received: from mail103-tx2-R.bigfish.com (10.9.14.244) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:11:29 +0000
Received: from mail103-tx2 (localhost [127.0.0.1])	by
	mail103-tx2-R.bigfish.com (Postfix) with ESMTP id F0D66320473;
	Thu, 21 Jun 2012 13:11:28 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail103-tx2 (localhost.localdomain [127.0.0.1]) by mail103-tx2
	(MessageSwitch) id 1340284287162916_28359;
	Thu, 21 Jun 2012 13:11:27 +0000 (UTC)
Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.245])	by
	mail103-tx2.bigfish.com (Postfix) with ESMTP id 2401C420049;
	Thu, 21 Jun 2012 13:11:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:11:22 +0000
X-WSS-ID: 0M5YY1A-01-0W8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2289F1028023;	Thu, 21 Jun 2012 08:12:46 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 08:13:03 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 08:12:46 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	09:12:46 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 19E3849C69D; Thu, 21 Jun 2012
	14:12:45 +0100 (BST)
Message-ID: <4FE31D5A.7060701@amd.com>
Date: Thu, 21 Jun 2012 15:10:50 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
	<4FE3337C020000780008B177@nat28.tlf.novell.com>
In-Reply-To: <4FE3337C020000780008B177@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 02:45 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 14:28, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/21/2012 02:06 PM, Jan Beulich wrote:
>>>>>> On 21.06.12 at 13:21, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> I also evaluated the possibility of hiding iommu device from dom0. I
>>>> think the change is no quite a lot, at least, for io based pcicfg
>>>> access. A proof-of-concept patch is attached.
>>>
>>> This completely hides the device from Dom0, but only when
>>> config space is accessed via method 1. Did you not see my
>>> earlier patch doing this for MCFG as well
>> Could you please provide a particular c/s number?... (I saw too many c/s
>> might be related to this topic). so that I could work out a patch to
>> support both i/o and mmcfg.
>
> I sent this to you yesterday, so you'd be able to test whether
> it actually fulfills its purpose before we discuss whether this is
> acceptable for 4.2. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01129.html

Oh, yes I found it, my email filter did not work well so I did not see 
it at the right folder. I will test right now.

>
>> (albeit only disallowing
>>> writes, so allowing the device to still be seen by Dom0)?
>> Sounds better to me...this still allows user to check iommu status from
>> lspci.
>>
>>> Whether completely hiding the device is actually okay I can't
>>> easily tell: Would IOMMUs always be either at func 0 of a single-
>>> unction device, or at a non-zero func of a multi-function one? If
>>> not, other devices may get hidden implicitly.
>>
>> AMD IOMMU is an independent pci-e endpoint, and this function will not
>> be used for other purposes other than containing an iommu. So I don't
>> see that iommu will share bdf value with other devices.
>
> The question is not regarding bdf, but regarding whether under
> the same seg:bus:dev there might be multiple functions, one of
> which is the IOMMU, and if so, whether the IOMMU would be
> guaranteed to have a non-zero function number.

In a real system (single or multiple iommu), amd iommu shares the same 
device number with north bridge but has function number 2.. (e.g 
bus:00.2) Howerver according to spec, it does not guaranteed to have 
non-zero function number. So what is the problem you see if iommu uses 
fun0 on a multi-func device?

Thanks,
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 Jun 21 13:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhIx-0001vZ-Dk; Thu, 21 Jun 2012 13:20:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShhIv-0001vO-Vn
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:20:10 +0000
Received: from [85.158.138.51:16627] by server-1.bemta-3.messagelabs.com id
	9A/AE-14648-98F13EF4; Thu, 21 Jun 2012 13:20:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340284808!10162611!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30422 invoked from network); 21 Jun 2012 13:20:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 13:20:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 14:20:07 +0100
Message-Id: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 14:20:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <dgdegra@tycho.nsa.gov>,"Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

The mmconfig part of this is seriously broken: These operations,
even when carried out by Dom0, are MMIO accesses, and hence
are invisible to the hypervisor without extra handling. Putting
the checks into pci_mmcfg_{read,write}() has the effect of
potentially denying the _hypervisor_ access. So I think at least
that part needs to be reverted.

Even the I/O port base logic isn't fully correct - AMD's extension
to access extended config space isn't being taken care of (i.e.
wrong register values might get passed to the xsm callback).

(It is, btw, also this c/s that prompted the fix titled "x86/PCI:
fix guest_io_read() when pci_cfg_ok() denies access" I sent
out earlier today, so if we decide to revert the whole c/s, that
wouldn't be needed anymore. Yet the function comes handy
for dealing with the MMIO-write-masking that we're currently
evaluating with the AMD folks to get their IOMMU interrupts
working again with recent Linux Dom0 - see yesterday's
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01129.html.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhIx-0001vZ-Dk; Thu, 21 Jun 2012 13:20:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1ShhIv-0001vO-Vn
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:20:10 +0000
Received: from [85.158.138.51:16627] by server-1.bemta-3.messagelabs.com id
	9A/AE-14648-98F13EF4; Thu, 21 Jun 2012 13:20:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340284808!10162611!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30422 invoked from network); 21 Jun 2012 13:20:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 13:20:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 14:20:07 +0100
Message-Id: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 14:20:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <dgdegra@tycho.nsa.gov>,"Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

The mmconfig part of this is seriously broken: These operations,
even when carried out by Dom0, are MMIO accesses, and hence
are invisible to the hypervisor without extra handling. Putting
the checks into pci_mmcfg_{read,write}() has the effect of
potentially denying the _hypervisor_ access. So I think at least
that part needs to be reverted.

Even the I/O port base logic isn't fully correct - AMD's extension
to access extended config space isn't being taken care of (i.e.
wrong register values might get passed to the xsm callback).

(It is, btw, also this c/s that prompted the fix titled "x86/PCI:
fix guest_io_read() when pci_cfg_ok() denies access" I sent
out earlier today, so if we decide to revert the whole c/s, that
wouldn't be needed anymore. Yet the function comes handy
for dealing with the MMIO-write-masking that we're currently
evaluating with the AMD folks to get their IOMMU interrupts
working again with recent Linux Dom0 - see yesterday's
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01129.html.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:24:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:24: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 1ShhMf-00023F-28; Thu, 21 Jun 2012 13:24: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 1ShhMd-000235-Ua
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:24:00 +0000
Received: from [193.109.254.147:57418] by server-10.bemta-14.messagelabs.com
	id 2D/40-05433-F6023EF4; Thu, 21 Jun 2012 13:23:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340285038!10051114!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30301 invoked from network); 21 Jun 2012 13:23:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 13:23:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 14:23:58 +0100
Message-Id: <4FE33CB9020000780008B1C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 14:24:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
	<4FE3337C020000780008B177@nat28.tlf.novell.com>
	<4FE31D5A.7060701@amd.com>
In-Reply-To: <4FE31D5A.7060701@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 15:10, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/21/2012 02:45 PM, Jan Beulich wrote:
>>>>> On 21.06.12 at 14:28, Wei Wang<wei.wang2@amd.com>  wrote:
>>> AMD IOMMU is an independent pci-e endpoint, and this function will not
>>> be used for other purposes other than containing an iommu. So I don't
>>> see that iommu will share bdf value with other devices.
>>
>> The question is not regarding bdf, but regarding whether under
>> the same seg:bus:dev there might be multiple functions, one of
>> which is the IOMMU, and if so, whether the IOMMU would be
>> guaranteed to have a non-zero function number.
> 
> In a real system (single or multiple iommu), amd iommu shares the same 
> device number with north bridge but has function number 2.. (e.g 
> bus:00.2) Howerver according to spec, it does not guaranteed to have 
> non-zero function number. So what is the problem you see if iommu uses 
> fun0 on a multi-func device?

If it's on func 0 and gets hidden completely (as done by your
partial patch), other functions won't be found when scanning
for them (because secondary functions get looked at only
when func 0 actually exists, as otherwise evaluating the header
type register is invalid).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:24:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:24: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 1ShhMf-00023F-28; Thu, 21 Jun 2012 13:24: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 1ShhMd-000235-Ua
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:24:00 +0000
Received: from [193.109.254.147:57418] by server-10.bemta-14.messagelabs.com
	id 2D/40-05433-F6023EF4; Thu, 21 Jun 2012 13:23:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340285038!10051114!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30301 invoked from network); 21 Jun 2012 13:23:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 13:23:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 14:23:58 +0100
Message-Id: <4FE33CB9020000780008B1C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 14:24:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
	<4FE3337C020000780008B177@nat28.tlf.novell.com>
	<4FE31D5A.7060701@amd.com>
In-Reply-To: <4FE31D5A.7060701@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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 21.06.12 at 15:10, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/21/2012 02:45 PM, Jan Beulich wrote:
>>>>> On 21.06.12 at 14:28, Wei Wang<wei.wang2@amd.com>  wrote:
>>> AMD IOMMU is an independent pci-e endpoint, and this function will not
>>> be used for other purposes other than containing an iommu. So I don't
>>> see that iommu will share bdf value with other devices.
>>
>> The question is not regarding bdf, but regarding whether under
>> the same seg:bus:dev there might be multiple functions, one of
>> which is the IOMMU, and if so, whether the IOMMU would be
>> guaranteed to have a non-zero function number.
> 
> In a real system (single or multiple iommu), amd iommu shares the same 
> device number with north bridge but has function number 2.. (e.g 
> bus:00.2) Howerver according to spec, it does not guaranteed to have 
> non-zero function number. So what is the problem you see if iommu uses 
> fun0 on a multi-func device?

If it's on func 0 and gets hidden completely (as done by your
partial patch), other functions won't be found when scanning
for them (because secondary functions get looked at only
when func 0 actually exists, as otherwise evaluating the header
type register is invalid).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhRn-0002ES-Q3; Thu, 21 Jun 2012 13:29:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShhRm-0002EN-8z
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:29:18 +0000
Received: from [85.158.138.51:49147] by server-8.bemta-3.messagelabs.com id
	A3/78-06157-DA123EF4; Thu, 21 Jun 2012 13:29:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340285355!28906283!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4572 invoked from network); 21 Jun 2012 13:29:16 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 13:29:16 -0000
Received: from mail138-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:27:48 +0000
Received: from mail138-va3 (localhost [127.0.0.1])	by
	mail138-va3-R.bigfish.com (Postfix) with ESMTP id 7875E2203FE;
	Thu, 21 Jun 2012 13:27:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail138-va3 (localhost.localdomain [127.0.0.1]) by mail138-va3
	(MessageSwitch) id 1340285266532266_7332;
	Thu, 21 Jun 2012 13:27:46 +0000 (UTC)
Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.254])	by
	mail138-va3.bigfish.com (Postfix) with ESMTP id 72EBE1E0050;
	Thu, 21 Jun 2012 13:27:46 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:27:45 +0000
X-WSS-ID: 0M5YYSK-01-1YF-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A4E310280D9;	Thu, 21 Jun 2012 08:29:08 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 08:29:25 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 08:29:08 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	09:29:07 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9F1A549C69D; Thu, 21 Jun 2012
	14:29:06 +0100 (BST)
Message-ID: <4FE32130.20706@amd.com>
Date: Thu, 21 Jun 2012 15:27:12 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
	<4FE3337C020000780008B177@nat28.tlf.novell.com>
	<4FE31D5A.7060701@amd.com>
	<4FE33CB9020000780008B1C4@nat28.tlf.novell.com>
In-Reply-To: <4FE33CB9020000780008B1C4@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 03:24 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 15:10, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/21/2012 02:45 PM, Jan Beulich wrote:
>>>>>> On 21.06.12 at 14:28, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> AMD IOMMU is an independent pci-e endpoint, and this function will not
>>>> be used for other purposes other than containing an iommu. So I don't
>>>> see that iommu will share bdf value with other devices.
>>>
>>> The question is not regarding bdf, but regarding whether under
>>> the same seg:bus:dev there might be multiple functions, one of
>>> which is the IOMMU, and if so, whether the IOMMU would be
>>> guaranteed to have a non-zero function number.
>>
>> In a real system (single or multiple iommu), amd iommu shares the same
>> device number with north bridge but has function number 2.. (e.g
>> bus:00.2) Howerver according to spec, it does not guaranteed to have
>> non-zero function number. So what is the problem you see if iommu uses
>> fun0 on a multi-func device?
>
> If it's on func 0 and gets hidden completely (as done by your
> partial patch), other functions won't be found when scanning
> for them (because secondary functions get looked at only
> when func 0 actually exists, as otherwise evaluating the header
> type register is invalid).

OK, understood. Then I think we do need to allow pci cfg read for iommu 
device.

Thanks
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 Jun 21 13:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhRn-0002ES-Q3; Thu, 21 Jun 2012 13:29:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShhRm-0002EN-8z
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:29:18 +0000
Received: from [85.158.138.51:49147] by server-8.bemta-3.messagelabs.com id
	A3/78-06157-DA123EF4; Thu, 21 Jun 2012 13:29:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340285355!28906283!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4572 invoked from network); 21 Jun 2012 13:29:16 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 13:29:16 -0000
Received: from mail138-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:27:48 +0000
Received: from mail138-va3 (localhost [127.0.0.1])	by
	mail138-va3-R.bigfish.com (Postfix) with ESMTP id 7875E2203FE;
	Thu, 21 Jun 2012 13:27:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail138-va3 (localhost.localdomain [127.0.0.1]) by mail138-va3
	(MessageSwitch) id 1340285266532266_7332;
	Thu, 21 Jun 2012 13:27:46 +0000 (UTC)
Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.254])	by
	mail138-va3.bigfish.com (Postfix) with ESMTP id 72EBE1E0050;
	Thu, 21 Jun 2012 13:27:46 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 13:27:45 +0000
X-WSS-ID: 0M5YYSK-01-1YF-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2A4E310280D9;	Thu, 21 Jun 2012 08:29:08 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 08:29:25 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 21 Jun 2012 08:29:08 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	09:29:07 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9F1A549C69D; Thu, 21 Jun 2012
	14:29:06 +0100 (BST)
Message-ID: <4FE32130.20706@amd.com>
Date: Thu, 21 Jun 2012 15:27:12 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FDA0ECD0200007800089FEA@nat28.tlf.novell.com>
	<4FDA0028.3090609@amd.com>
	<4FE30CBB020000780008B06B@nat28.tlf.novell.com>
	<4FE303C4.3060705@amd.com>
	<4FE32A81020000780008B11B@nat28.tlf.novell.com>
	<4FE31385.3060502@amd.com>
	<4FE3337C020000780008B177@nat28.tlf.novell.com>
	<4FE31D5A.7060701@amd.com>
	<4FE33CB9020000780008B1C4@nat28.tlf.novell.com>
In-Reply-To: <4FE33CB9020000780008B1C4@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>, ebiederm@xmission.com,
	SherryHurwitz <sherry.hurwitz@amd.com>, stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] PCI/MSI: don't disable AMD IOMMU MSI on Xen
	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-Transfer-Encoding: 7bit
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/21/2012 03:24 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 15:10, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/21/2012 02:45 PM, Jan Beulich wrote:
>>>>>> On 21.06.12 at 14:28, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> AMD IOMMU is an independent pci-e endpoint, and this function will not
>>>> be used for other purposes other than containing an iommu. So I don't
>>>> see that iommu will share bdf value with other devices.
>>>
>>> The question is not regarding bdf, but regarding whether under
>>> the same seg:bus:dev there might be multiple functions, one of
>>> which is the IOMMU, and if so, whether the IOMMU would be
>>> guaranteed to have a non-zero function number.
>>
>> In a real system (single or multiple iommu), amd iommu shares the same
>> device number with north bridge but has function number 2.. (e.g
>> bus:00.2) Howerver according to spec, it does not guaranteed to have
>> non-zero function number. So what is the problem you see if iommu uses
>> fun0 on a multi-func device?
>
> If it's on func 0 and gets hidden completely (as done by your
> partial patch), other functions won't be found when scanning
> for them (because secondary functions get looked at only
> when func 0 actually exists, as otherwise evaluating the header
> type register is invalid).

OK, understood. Then I think we do need to allow pci cfg read for iommu 
device.

Thanks
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 Jun 21 13:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhUO-0002Kn-CZ; Thu, 21 Jun 2012 13:32: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 1ShhUM-0002Kc-RO
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:31:59 +0000
Received: from [85.158.139.83:16448] by server-6.bemta-5.messagelabs.com id
	1F/FF-11348-D4223EF4; Thu, 21 Jun 2012 13:31:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340285516!21604484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 21 Jun 2012 13:31:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 13:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13149066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 13:31:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 14:31:56 +0100
Message-ID: <1340285514.26083.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 14:31:54 +0100
In-Reply-To: <93dc34fa681a1391dcf9.1339779877@Solace>
References: <patchbomb.1339779868@Solace>
	<93dc34fa681a1391dcf9.1339779877@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
 with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> In such a way that only the cpus belonging to the cpupool of the
> domain being placed are considered for the placement itself.
> 
> This happens by filtering out all the nodes in which the cpupool has
> not any cpu from the placement candidates. After that -- as a cpu pooling
> not necessarily happens at NUMA nodes boundaries -- we also make sure
> only the actual cpus that are part of the pool are considered when
> counting how much processors a placement candidate is able to provide.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
> @@ -198,15 +198,27 @@ static void comb_get_nodemap(comb_iter_t
>          libxl_bitmap_set(nodemap, it[i]);
>  }
>  
> +/* Retrieve how many nodes a nodemap spans. */
> +static int nodemap_to_nr_nodes(const libxl_bitmap *nodemap)
> +{
> +    int i, nr_nodes = 0;
> +
> +    libxl_for_each_set_bit(i, *nodemap)
> +        nr_nodes++;
> +    return nr_nodes;
> +}
> +
>  /* Retrieve the number of cpus that the nodes that are part of the nodemap
> - * span. */
> + * span and that are also set in suitable_cpumap. */
>  static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
> +                                 const libxl_bitmap *suitable_cpumap,
>                                   const libxl_bitmap *nodemap)
>  {
>      int i, nodes_cpus = 0;
>  
>      for (i = 0; i < nr_cpus; i++) {
> -        if (libxl_bitmap_test(nodemap, tinfo[i].node))
> +        if (libxl_bitmap_test(suitable_cpumap, i) &&
> +            libxl_bitmap_test(nodemap, tinfo[i].node))
>              nodes_cpus++;
>      }
>      return nodes_cpus;
> @@ -311,12 +323,13 @@ static int cpus_per_node_count(libxl_cpu
>  int libxl__get_numa_candidates(libxl__gc *gc,
>                                 uint32_t min_free_memkb, int min_cpus,
>                                 int min_nodes, int max_nodes,
> +                               const libxl_bitmap *suitable_cpumap,
>                                 libxl__numa_candidate *cndts[], int *nr_cndts)
>  {
>      libxl__numa_candidate *new_cndts = NULL;
>      libxl_cputopology *tinfo = NULL;
>      libxl_numainfo *ninfo = NULL;
> -    libxl_bitmap nodemap;
> +    libxl_bitmap suitable_nodemap, nodemap;
>      int nr_nodes, nr_cpus;
>      int array_size, rc;
>  
> @@ -340,6 +353,15 @@ int libxl__get_numa_candidates(libxl__gc
>      if (rc)
>          goto out;
>  
> +    /* Allocate and prepare the map of the node that can be utilized for
> +     * placement, basing on the map of suitable cpus. */
> +    rc = libxl_node_bitmap_alloc(CTX, &suitable_nodemap);
> +    if (rc)
> +        goto out;
> +    rc = libxl_cpumap_to_nodemap(CTX, suitable_cpumap, &suitable_nodemap);
> +    if (rc)
> +        goto out;
> +
>      /*
>       * Round up and down some of the constraints. For instance, the minimum
>       * number of cpus a candidate should have must at least be non-negative.
> @@ -391,9 +413,14 @@ int libxl__get_numa_candidates(libxl__gc
>          for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
>               comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
>              uint32_t nodes_free_memkb;
> -            int nodes_cpus;
> +            int i, nodes_cpus;
>  
> +            /* Get the nodemap for the combination and filter unwnted nodes */

                                                                 unwanted

>              comb_get_nodemap(comb_iter, &nodemap, min_nodes);
> +            libxl_for_each_set_bit(i, nodemap) {
> +                if (!libxl_bitmap_test(&suitable_nodemap, i))
> +                    libxl_bitmap_reset(&nodemap, i);
> +            }
>  
>              /* If there is not enough memoy in this combination, skip it
>               * and go generating the next one... */
> @@ -402,7 +429,8 @@ int libxl__get_numa_candidates(libxl__gc
>                  continue;
>  
>              /* And the same applies if this combination is short in cpus */
> -            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
> +            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, suitable_cpumap,
> +                                               &nodemap);
>              if (min_cpus > 0 && nodes_cpus < min_cpus)
>                  continue;
>  
> @@ -427,12 +455,13 @@ int libxl__get_numa_candidates(libxl__gc
>              new_cndts[*nr_cndts].nr_domains =
>                                      nodemap_to_nr_domains(gc, tinfo, &nodemap);
>              new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
> -            new_cndts[*nr_cndts].nr_nodes = min_nodes;
> +            new_cndts[*nr_cndts].nr_nodes = nodemap_to_nr_nodes(&nodemap);
>              new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
>  
>              LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
>                         "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
> -                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
> +                       new_cndts[*nr_cndts].nr_nodes,
> +                       new_cndts[*nr_cndts].nr_cpus,
>                         new_cndts[*nr_cndts].free_memkb / 1024);
>  
>              (*nr_cndts)++;
> @@ -442,6 +471,7 @@ int libxl__get_numa_candidates(libxl__gc
>  
>      *cndts = new_cndts;
>   out:
> +    libxl_bitmap_dispose(&suitable_nodemap);
>      libxl_bitmap_dispose(&nodemap);
>      libxl_cputopology_list_free(tinfo, nr_cpus);
>      libxl_numainfo_list_free(ninfo, nr_nodes);
> @@ -485,23 +515,27 @@ static int numa_cmpf(const void *v1, con
>  }
>  
>  /* The actual automatic NUMA placement routine */
> -static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
> +static int numa_place_domain(libxl__gc *gc, uint32_t domid,
> +                             libxl_domain_build_info *info)
>  {
>      int nr_candidates = 0;
>      libxl__numa_candidate *candidates = NULL;
>      libxl_bitmap candidate_nodemap;
> -    libxl_cpupoolinfo *pinfo;
> -    int nr_pools, rc = 0;
> +    libxl_cpupoolinfo cpupool_info;
> +    int i, cpupool, rc = 0;
>      uint32_t memkb;
>  
> -    /* First of all, if cpupools are in use, better not to mess with them */
> -    pinfo = libxl_list_cpupool(CTX, &nr_pools);
> -    if (!pinfo)
> -        return ERROR_FAIL;
> -    if (nr_pools > 1) {
> -        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
> -        goto out;
> -    }
> +    /*
> +     * Extract the cpumap from the cpupool the domain belong to. In fact,
> +     * it only makes sense to consider the cpus/nodes that are in there
> +     * for placement.
> +     */
> +    rc = cpupool = libxl__domain_cpupool(gc, domid);
> +    if (rc < 0)
> +        return rc;
> +    rc = libxl_cpupool_info(CTX, &cpupool_info, cpupool);
> +    if (rc)
> +        return rc;
>  
>      rc = libxl_domain_need_memory(CTX, info, &memkb);
>      if (rc)
> @@ -513,7 +547,8 @@ static int numa_place_domain(libxl__gc *
>  
>      /* Find all the candidates with enough free memory and at least
>       * as much pcpus as the domain has vcpus.  */
> -    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
> +    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus,
> +                                    0, 0, &cpupool_info.cpumap,
>                                      &candidates, &nr_candidates);
>      if (rc)
>          goto out;
> @@ -538,13 +573,20 @@ static int numa_place_domain(libxl__gc *
>      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);
> +    }
> +
>      LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
>                  "%"PRIu32" KB free selected", candidates[0].nr_nodes,
>                  candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
>  
>   out:
>      libxl_bitmap_dispose(&candidate_nodemap);
> -    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
> +    libxl_cpupoolinfo_dispose(&cpupool_info);
>      return rc;
>  }
>  
> @@ -567,7 +609,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>       * whatever that turns out to be.
>       */
>      if (libxl_bitmap_is_full(&info->cpumap)) {
> -        int rc = numa_place_domain(gc, info);
> +        int rc = numa_place_domain(gc, domid, info);
>          if (rc)
>              return rc;
>      }
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2094,14 +2094,17 @@ typedef struct {
>   * least that amount of free memory and that number of cpus, respectively. If
>   * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
>   * of cpus won't be checked at all, which means a candidate will always be
> - * considered suitable wrt the specific constraint.  cndts is where the list of
> - * exactly nr_cndts candidates is returned. Note that, in case no candidates
> - * are found at all, the function returns successfully, but with nr_cndts equal
> - * to zero.
> + * considered suitable wrt the specific constraint. suitable_cpumap is useful
> + * for specifyin we want only the cpus in that mask to be considered while

         specifying

Apart from those two spelling errors:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> + * generating placement candidates (for example because of cpupools). cndts is
> + * where the list of exactly nr_cndts candidates is returned. Note that, in
> + * case no candidates are found at all, the function returns successfully, but
> + * with nr_cndts equal to zero.
>   */
>  _hidden int libxl__get_numa_candidates(libxl__gc *gc,
>                                  uint32_t min_free_memkb, int min_cpus,
>                                  int min_nodes, int max_nodes,
> +                                const libxl_bitmap *suitable_cpumap,
>                                  libxl__numa_candidate *cndts[], int *nr_cndts);
>  
>  /* allocation and deallocation for placement candidates */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhUO-0002Kn-CZ; Thu, 21 Jun 2012 13:32: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 1ShhUM-0002Kc-RO
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:31:59 +0000
Received: from [85.158.139.83:16448] by server-6.bemta-5.messagelabs.com id
	1F/FF-11348-D4223EF4; Thu, 21 Jun 2012 13:31:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340285516!21604484!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 21 Jun 2012 13:31:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 13:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13149066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 13:31:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 14:31:56 +0100
Message-ID: <1340285514.26083.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 14:31:54 +0100
In-Reply-To: <93dc34fa681a1391dcf9.1339779877@Solace>
References: <patchbomb.1339779868@Solace>
	<93dc34fa681a1391dcf9.1339779877@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
 with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> In such a way that only the cpus belonging to the cpupool of the
> domain being placed are considered for the placement itself.
> 
> This happens by filtering out all the nodes in which the cpupool has
> not any cpu from the placement candidates. After that -- as a cpu pooling
> not necessarily happens at NUMA nodes boundaries -- we also make sure
> only the actual cpus that are part of the pool are considered when
> counting how much processors a placement candidate is able to provide.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.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
> @@ -198,15 +198,27 @@ static void comb_get_nodemap(comb_iter_t
>          libxl_bitmap_set(nodemap, it[i]);
>  }
>  
> +/* Retrieve how many nodes a nodemap spans. */
> +static int nodemap_to_nr_nodes(const libxl_bitmap *nodemap)
> +{
> +    int i, nr_nodes = 0;
> +
> +    libxl_for_each_set_bit(i, *nodemap)
> +        nr_nodes++;
> +    return nr_nodes;
> +}
> +
>  /* Retrieve the number of cpus that the nodes that are part of the nodemap
> - * span. */
> + * span and that are also set in suitable_cpumap. */
>  static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus,
> +                                 const libxl_bitmap *suitable_cpumap,
>                                   const libxl_bitmap *nodemap)
>  {
>      int i, nodes_cpus = 0;
>  
>      for (i = 0; i < nr_cpus; i++) {
> -        if (libxl_bitmap_test(nodemap, tinfo[i].node))
> +        if (libxl_bitmap_test(suitable_cpumap, i) &&
> +            libxl_bitmap_test(nodemap, tinfo[i].node))
>              nodes_cpus++;
>      }
>      return nodes_cpus;
> @@ -311,12 +323,13 @@ static int cpus_per_node_count(libxl_cpu
>  int libxl__get_numa_candidates(libxl__gc *gc,
>                                 uint32_t min_free_memkb, int min_cpus,
>                                 int min_nodes, int max_nodes,
> +                               const libxl_bitmap *suitable_cpumap,
>                                 libxl__numa_candidate *cndts[], int *nr_cndts)
>  {
>      libxl__numa_candidate *new_cndts = NULL;
>      libxl_cputopology *tinfo = NULL;
>      libxl_numainfo *ninfo = NULL;
> -    libxl_bitmap nodemap;
> +    libxl_bitmap suitable_nodemap, nodemap;
>      int nr_nodes, nr_cpus;
>      int array_size, rc;
>  
> @@ -340,6 +353,15 @@ int libxl__get_numa_candidates(libxl__gc
>      if (rc)
>          goto out;
>  
> +    /* Allocate and prepare the map of the node that can be utilized for
> +     * placement, basing on the map of suitable cpus. */
> +    rc = libxl_node_bitmap_alloc(CTX, &suitable_nodemap);
> +    if (rc)
> +        goto out;
> +    rc = libxl_cpumap_to_nodemap(CTX, suitable_cpumap, &suitable_nodemap);
> +    if (rc)
> +        goto out;
> +
>      /*
>       * Round up and down some of the constraints. For instance, the minimum
>       * number of cpus a candidate should have must at least be non-negative.
> @@ -391,9 +413,14 @@ int libxl__get_numa_candidates(libxl__gc
>          for (comb_ok = comb_init(gc, &comb_iter, nr_nodes, min_nodes); comb_ok;
>               comb_ok = comb_next(comb_iter, nr_nodes, min_nodes)) {
>              uint32_t nodes_free_memkb;
> -            int nodes_cpus;
> +            int i, nodes_cpus;
>  
> +            /* Get the nodemap for the combination and filter unwnted nodes */

                                                                 unwanted

>              comb_get_nodemap(comb_iter, &nodemap, min_nodes);
> +            libxl_for_each_set_bit(i, nodemap) {
> +                if (!libxl_bitmap_test(&suitable_nodemap, i))
> +                    libxl_bitmap_reset(&nodemap, i);
> +            }
>  
>              /* If there is not enough memoy in this combination, skip it
>               * and go generating the next one... */
> @@ -402,7 +429,8 @@ int libxl__get_numa_candidates(libxl__gc
>                  continue;
>  
>              /* And the same applies if this combination is short in cpus */
> -            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap);
> +            nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, suitable_cpumap,
> +                                               &nodemap);
>              if (min_cpus > 0 && nodes_cpus < min_cpus)
>                  continue;
>  
> @@ -427,12 +455,13 @@ int libxl__get_numa_candidates(libxl__gc
>              new_cndts[*nr_cndts].nr_domains =
>                                      nodemap_to_nr_domains(gc, tinfo, &nodemap);
>              new_cndts[*nr_cndts].free_memkb = nodes_free_memkb;
> -            new_cndts[*nr_cndts].nr_nodes = min_nodes;
> +            new_cndts[*nr_cndts].nr_nodes = nodemap_to_nr_nodes(&nodemap);
>              new_cndts[*nr_cndts].nr_cpus = nodes_cpus;
>  
>              LOG(DEBUG, "NUMA placement candidate #%d found: nr_nodes=%d, "
>                         "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts,
> -                       min_nodes, new_cndts[*nr_cndts].nr_cpus,
> +                       new_cndts[*nr_cndts].nr_nodes,
> +                       new_cndts[*nr_cndts].nr_cpus,
>                         new_cndts[*nr_cndts].free_memkb / 1024);
>  
>              (*nr_cndts)++;
> @@ -442,6 +471,7 @@ int libxl__get_numa_candidates(libxl__gc
>  
>      *cndts = new_cndts;
>   out:
> +    libxl_bitmap_dispose(&suitable_nodemap);
>      libxl_bitmap_dispose(&nodemap);
>      libxl_cputopology_list_free(tinfo, nr_cpus);
>      libxl_numainfo_list_free(ninfo, nr_nodes);
> @@ -485,23 +515,27 @@ static int numa_cmpf(const void *v1, con
>  }
>  
>  /* The actual automatic NUMA placement routine */
> -static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *info)
> +static int numa_place_domain(libxl__gc *gc, uint32_t domid,
> +                             libxl_domain_build_info *info)
>  {
>      int nr_candidates = 0;
>      libxl__numa_candidate *candidates = NULL;
>      libxl_bitmap candidate_nodemap;
> -    libxl_cpupoolinfo *pinfo;
> -    int nr_pools, rc = 0;
> +    libxl_cpupoolinfo cpupool_info;
> +    int i, cpupool, rc = 0;
>      uint32_t memkb;
>  
> -    /* First of all, if cpupools are in use, better not to mess with them */
> -    pinfo = libxl_list_cpupool(CTX, &nr_pools);
> -    if (!pinfo)
> -        return ERROR_FAIL;
> -    if (nr_pools > 1) {
> -        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
> -        goto out;
> -    }
> +    /*
> +     * Extract the cpumap from the cpupool the domain belong to. In fact,
> +     * it only makes sense to consider the cpus/nodes that are in there
> +     * for placement.
> +     */
> +    rc = cpupool = libxl__domain_cpupool(gc, domid);
> +    if (rc < 0)
> +        return rc;
> +    rc = libxl_cpupool_info(CTX, &cpupool_info, cpupool);
> +    if (rc)
> +        return rc;
>  
>      rc = libxl_domain_need_memory(CTX, info, &memkb);
>      if (rc)
> @@ -513,7 +547,8 @@ static int numa_place_domain(libxl__gc *
>  
>      /* Find all the candidates with enough free memory and at least
>       * as much pcpus as the domain has vcpus.  */
> -    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0,
> +    rc = libxl__get_numa_candidates(gc, memkb, info->max_vcpus,
> +                                    0, 0, &cpupool_info.cpumap,
>                                      &candidates, &nr_candidates);
>      if (rc)
>          goto out;
> @@ -538,13 +573,20 @@ static int numa_place_domain(libxl__gc *
>      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);
> +    }
> +
>      LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
>                  "%"PRIu32" KB free selected", candidates[0].nr_nodes,
>                  candidates[0].nr_cpus, candidates[0].free_memkb / 1024);
>  
>   out:
>      libxl_bitmap_dispose(&candidate_nodemap);
> -    libxl_cpupoolinfo_list_free(pinfo, nr_pools);
> +    libxl_cpupoolinfo_dispose(&cpupool_info);
>      return rc;
>  }
>  
> @@ -567,7 +609,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>       * whatever that turns out to be.
>       */
>      if (libxl_bitmap_is_full(&info->cpumap)) {
> -        int rc = numa_place_domain(gc, info);
> +        int rc = numa_place_domain(gc, domid, info);
>          if (rc)
>              return rc;
>      }
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2094,14 +2094,17 @@ typedef struct {
>   * least that amount of free memory and that number of cpus, respectively. If
>   * min_free_memkb and/or min_cpus are 0, the candidates' free memory and number
>   * of cpus won't be checked at all, which means a candidate will always be
> - * considered suitable wrt the specific constraint.  cndts is where the list of
> - * exactly nr_cndts candidates is returned. Note that, in case no candidates
> - * are found at all, the function returns successfully, but with nr_cndts equal
> - * to zero.
> + * considered suitable wrt the specific constraint. suitable_cpumap is useful
> + * for specifyin we want only the cpus in that mask to be considered while

         specifying

Apart from those two spelling errors:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> + * generating placement candidates (for example because of cpupools). cndts is
> + * where the list of exactly nr_cndts candidates is returned. Note that, in
> + * case no candidates are found at all, the function returns successfully, but
> + * with nr_cndts equal to zero.
>   */
>  _hidden int libxl__get_numa_candidates(libxl__gc *gc,
>                                  uint32_t min_free_memkb, int min_cpus,
>                                  int min_nodes, int max_nodes,
> +                                const libxl_bitmap *suitable_cpumap,
>                                  libxl__numa_candidate *cndts[], int *nr_cndts);
>  
>  /* allocation and deallocation for placement candidates */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:34: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 1ShhWF-0002Uc-2l; Thu, 21 Jun 2012 13:33:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1ShhWD-0002UV-OI
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:33:53 +0000
Received: from [85.158.138.51:32555] by server-8.bemta-3.messagelabs.com id
	88/71-06157-0C223EF4; Thu, 21 Jun 2012 13:33:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340285630!28852374!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjExNTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4394 invoked from network); 21 Jun 2012 13:33:52 -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;
	21 Jun 2012 13:33:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336363200"; d="scan'208";a="199562432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:33:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:33:50 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ShhW9-0000Dr-MI;
	Thu, 21 Jun 2012 14:33:49 +0100
MIME-Version: 1.0
X-Mercurial-Node: 849fe346b05a3265894e6ce16292f81def92fce7
Message-ID: <849fe346b05a3265894e.1340285500@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 21 Jun 2012 14:31:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl: Clarify 'xend is running' error message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340285415 -3600
# Node ID 849fe346b05a3265894e6ce16292f81def92fce7
# Parent  baa85434d0ec16629ca30b7c07deaa9beb3ea9c5
xl: Clarify 'xend is running' error message

* Give reason for check (unpredictable results)
* Give a better recommendation (shut down xend)
* Make it clear that -f is overriding a safety check.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -251,9 +251,9 @@ int main(int argc, char **argv)
             for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
                 if (!access(locks[i], F_OK) && !force_execution) {
                     fprintf(stderr,
-"xend is running, which prevents xl from working correctly.\n"
-"If you still want to force the execution of xl please use the -f\n"
-"option.\n"
+"xend is running, which may cause unpredictable results when using\n"
+"this xl command.  Please shut down xend before continuing.\n\n"
+"(This check can be overridden with the -f option.)\n"
                             );
                     ret = 1;
                     goto xit;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:34: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 1ShhWF-0002Uc-2l; Thu, 21 Jun 2012 13:33:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1ShhWD-0002UV-OI
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 13:33:53 +0000
Received: from [85.158.138.51:32555] by server-8.bemta-3.messagelabs.com id
	88/71-06157-0C223EF4; Thu, 21 Jun 2012 13:33:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340285630!28852374!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjExNTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4394 invoked from network); 21 Jun 2012 13:33:52 -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;
	21 Jun 2012 13:33:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336363200"; d="scan'208";a="199562432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 09:33:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 09:33:50 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1ShhW9-0000Dr-MI;
	Thu, 21 Jun 2012 14:33:49 +0100
MIME-Version: 1.0
X-Mercurial-Node: 849fe346b05a3265894e6ce16292f81def92fce7
Message-ID: <849fe346b05a3265894e.1340285500@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 21 Jun 2012 14:31:40 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl: Clarify 'xend is running' error message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340285415 -3600
# Node ID 849fe346b05a3265894e6ce16292f81def92fce7
# Parent  baa85434d0ec16629ca30b7c07deaa9beb3ea9c5
xl: Clarify 'xend is running' error message

* Give reason for check (unpredictable results)
* Give a better recommendation (shut down xend)
* Make it clear that -f is overriding a safety check.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -251,9 +251,9 @@ int main(int argc, char **argv)
             for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) {
                 if (!access(locks[i], F_OK) && !force_execution) {
                     fprintf(stderr,
-"xend is running, which prevents xl from working correctly.\n"
-"If you still want to force the execution of xl please use the -f\n"
-"option.\n"
+"xend is running, which may cause unpredictable results when using\n"
+"this xl command.  Please shut down xend before continuing.\n\n"
+"(This check can be overridden with the -f option.)\n"
                             );
                     ret = 1;
                     goto xit;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:39:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhbU-0002ke-R2; Thu, 21 Jun 2012 13:39: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 1ShhbT-0002kZ-9t
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:39:19 +0000
Received: from [85.158.139.83:35611] by server-6.bemta-5.messagelabs.com id
	AC/30-11348-60423EF4; Thu, 21 Jun 2012 13:39:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340285956!28293106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13974 invoked from network); 21 Jun 2012 13:39:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 13:39:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13149247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 13:38:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 14:38:41 +0100
Message-ID: <1340285920.26083.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 14:38:40 +0100
In-Reply-To: <0e566a40afad1e3dc299.1339779878@Solace>
References: <patchbomb.1339779868@Solace>
	<0e566a40afad1e3dc299.1339779878@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> About rationale, usage and (some small bits of) API.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * API documentation moved close to the actual functions.
> 
> diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
> new file mode 100644
> --- /dev/null
> +++ b/docs/misc/xl-numa-placement.markdown
> @@ -0,0 +1,74 @@
> +# Guest Automatic NUMA Placement in libxl and xl #
> +
> +## Rationale ##
> +
> +The Xen hypervisor deals with Non-Uniform Memory Access (NUMA])
> +machines by assigning to its domain a "node affinity", i.e., a set of NUMA
> +nodes of the host from which it gets its memory allocated.
> +
> +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 ##
> +
> +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).
> +
> +### Manual Guest Placement with xl ###
> +
> +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
> +affects NUMA placement and memory accesses as the hypervisor constructs
> +the node affinity of a VM basing right on its CPU affinity when it is
> +created.
> +
> +This is very simple and effective, but requires the user/system
> +administrator to explicitly specify affinities for each and every domain,
> +or Xen won't be able to enable guarantee the locality for their memory
> +accesses.
> +
> +### Automatic Guest Placement with xl ###
> +
> +In case no "cpus=" option is specified in the config file, xl tries
> +to figure out on its own on which node(s) the domain could fit best.
> +
> +First of all, it needs to find a node (or a set of nodes) that have
> +enough free memory for accommodating the domain. After that, the actual
> +decision on where to put the new guest happens by generating all the
> +possible combinations of nodes that satisfies the above and chose among
> +them according to the following heuristics:
> +
> +  *  candidates involving fewer nodes come first. In case two (or more)
> +     candidates span the same number of nodes,
> +  *  candidates with greater amount of free memory come first. In case
> +     two (or more) candidates differ in their amount of free memory by
> +     less than 10%,
> +  *  candidates with fewer domains already placed on them come first.
> +
> +Giving preference to small candidates ensures better performance for
> +the guest, as it avoid spreading its memory among different nodes.
> +Using the nodes that have the biggest amounts of free memory helps
> +keeping the memory fragmentation small, from a system wide perspective.
> +Finally, in case more candidates fulfil these criteria by the same
> +extent, choosing the candidate that is hosting fewer domain helps
> +balancing the load on the various nodes.

[...]

snipped the bit you said was wrong. It was just be remove not replaced, right?


> +
> +## Guest Placement within libxl ##
> +
> +xl achieves automatic NUMA placement by means of the following API
> +calls, provided by libxl.

This last seems out of date.

Assuming the bit above was to be removed not replaced:
Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:39:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1ShhbU-0002ke-R2; Thu, 21 Jun 2012 13:39: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 1ShhbT-0002kZ-9t
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:39:19 +0000
Received: from [85.158.139.83:35611] by server-6.bemta-5.messagelabs.com id
	AC/30-11348-60423EF4; Thu, 21 Jun 2012 13:39:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340285956!28293106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13974 invoked from network); 21 Jun 2012 13:39:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 13:39:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13149247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 13:38:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 14:38:41 +0100
Message-ID: <1340285920.26083.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 14:38:40 +0100
In-Reply-To: <0e566a40afad1e3dc299.1339779878@Solace>
References: <patchbomb.1339779868@Solace>
	<0e566a40afad1e3dc299.1339779878@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> About rationale, usage and (some small bits of) API.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * API documentation moved close to the actual functions.
> 
> diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
> new file mode 100644
> --- /dev/null
> +++ b/docs/misc/xl-numa-placement.markdown
> @@ -0,0 +1,74 @@
> +# Guest Automatic NUMA Placement in libxl and xl #
> +
> +## Rationale ##
> +
> +The Xen hypervisor deals with Non-Uniform Memory Access (NUMA])
> +machines by assigning to its domain a "node affinity", i.e., a set of NUMA
> +nodes of the host from which it gets its memory allocated.
> +
> +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 ##
> +
> +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).
> +
> +### Manual Guest Placement with xl ###
> +
> +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
> +affects NUMA placement and memory accesses as the hypervisor constructs
> +the node affinity of a VM basing right on its CPU affinity when it is
> +created.
> +
> +This is very simple and effective, but requires the user/system
> +administrator to explicitly specify affinities for each and every domain,
> +or Xen won't be able to enable guarantee the locality for their memory
> +accesses.
> +
> +### Automatic Guest Placement with xl ###
> +
> +In case no "cpus=" option is specified in the config file, xl tries
> +to figure out on its own on which node(s) the domain could fit best.
> +
> +First of all, it needs to find a node (or a set of nodes) that have
> +enough free memory for accommodating the domain. After that, the actual
> +decision on where to put the new guest happens by generating all the
> +possible combinations of nodes that satisfies the above and chose among
> +them according to the following heuristics:
> +
> +  *  candidates involving fewer nodes come first. In case two (or more)
> +     candidates span the same number of nodes,
> +  *  candidates with greater amount of free memory come first. In case
> +     two (or more) candidates differ in their amount of free memory by
> +     less than 10%,
> +  *  candidates with fewer domains already placed on them come first.
> +
> +Giving preference to small candidates ensures better performance for
> +the guest, as it avoid spreading its memory among different nodes.
> +Using the nodes that have the biggest amounts of free memory helps
> +keeping the memory fragmentation small, from a system wide perspective.
> +Finally, in case more candidates fulfil these criteria by the same
> +extent, choosing the candidate that is hosting fewer domain helps
> +balancing the load on the various nodes.

[...]

snipped the bit you said was wrong. It was just be remove not replaced, right?


> +
> +## Guest Placement within libxl ##
> +
> +xl achieves automatic NUMA placement by means of the following API
> +calls, provided by libxl.

This last seems out of date.

Assuming the bit above was to be removed not replaced:
Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShhqQ-0002xB-Ht; Thu, 21 Jun 2012 13:54:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShhqO-0002x3-VO
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:54:45 +0000
Received: from [193.109.254.147:50673] by server-12.bemta-14.messagelabs.com
	id 7C/B9-30461-3A723EF4; Thu, 21 Jun 2012 13:54:43 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340286882!10881098!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10090 invoked from network); 21 Jun 2012 13:54:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 13:54:42 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79043103; Thu, 21 Jun 2012 15:54:41 +0200
Message-ID: <1340286875.4856.44.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 15:54:35 +0200
In-Reply-To: <1340285514.26083.4.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<93dc34fa681a1391dcf9.1339779877@Solace>
	<1340285514.26083.4.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
 with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4650304660794103223=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4650304660794103223==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-JHd/MqUqlItnkN/1c8CN"


--=-JHd/MqUqlItnkN/1c8CN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 14:31 +0100, Ian Campbell wrote:
> > + * considered suitable wrt the specific constraint. suitable_cpumap is=
 useful
> > + * for specifyin we want only the cpus in that mask to be considered w=
hile
>=20
>          specifying
>=20
> Apart from those two spelling errors:
>
Yeah, sorry for that. I'm very bad in spelling correctly when typing,
and this bloody keyboard is not helping! :-P

Isn't there any tool for spell checking code comments?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-JHd/MqUqlItnkN/1c8CN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jJ5sACgkQk4XaBE3IOsSyVACggblwX7MTqO3yV5xbJQ19kBGc
lowAn1XXWfPko6EBo5HPEy/ORb2ueok0
=YTSc
-----END PGP SIGNATURE-----

--=-JHd/MqUqlItnkN/1c8CN--



--===============4650304660794103223==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4650304660794103223==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 13:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShhqQ-0002xB-Ht; Thu, 21 Jun 2012 13:54:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShhqO-0002x3-VO
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:54:45 +0000
Received: from [193.109.254.147:50673] by server-12.bemta-14.messagelabs.com
	id 7C/B9-30461-3A723EF4; Thu, 21 Jun 2012 13:54:43 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340286882!10881098!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10090 invoked from network); 21 Jun 2012 13:54:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 13:54:42 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79043103; Thu, 21 Jun 2012 15:54:41 +0200
Message-ID: <1340286875.4856.44.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 15:54:35 +0200
In-Reply-To: <1340285514.26083.4.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<93dc34fa681a1391dcf9.1339779877@Solace>
	<1340285514.26083.4.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
 with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4650304660794103223=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4650304660794103223==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-JHd/MqUqlItnkN/1c8CN"


--=-JHd/MqUqlItnkN/1c8CN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 14:31 +0100, Ian Campbell wrote:
> > + * considered suitable wrt the specific constraint. suitable_cpumap is=
 useful
> > + * for specifyin we want only the cpus in that mask to be considered w=
hile
>=20
>          specifying
>=20
> Apart from those two spelling errors:
>
Yeah, sorry for that. I'm very bad in spelling correctly when typing,
and this bloody keyboard is not helping! :-P

Isn't there any tool for spell checking code comments?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-JHd/MqUqlItnkN/1c8CN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jJ5sACgkQk4XaBE3IOsSyVACggblwX7MTqO3yV5xbJQ19kBGc
lowAn1XXWfPko6EBo5HPEy/ORb2ueok0
=YTSc
-----END PGP SIGNATURE-----

--=-JHd/MqUqlItnkN/1c8CN--



--===============4650304660794103223==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4650304660794103223==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 13:57:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1Shht1-000339-3k; Thu, 21 Jun 2012 13:57:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Shhsz-000332-CM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:57:25 +0000
Received: from [85.158.143.99:45859] by server-3.bemta-4.messagelabs.com id
	79/4B-05808-44823EF4; Thu, 21 Jun 2012 13:57:24 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340287043!22079543!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17790 invoked from network); 21 Jun 2012 13:57:24 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 13:57:24 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79043172; Thu, 21 Jun 2012 15:57:23 +0200
Message-ID: <1340287037.4856.47.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 15:57:17 +0200
In-Reply-To: <1340285920.26083.8.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<0e566a40afad1e3dc299.1339779878@Solace>
	<1340285920.26083.8.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7399392068150607059=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7399392068150607059==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-OobNtzXsRn/J9NUdg3/0"


--=-OobNtzXsRn/J9NUdg3/0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 14:38 +0100, Ian Campbell wrote:
> snipped the bit you said was wrong. It was just be remove not replaced, r=
ight?
>=20
Yes, it will go away, as the algorithm changed and does not do that any
longer.

> > +
> > +## Guest Placement within libxl ##
> > +
> > +xl achieves automatic NUMA placement by means of the following API
> > +calls, provided by libxl.
>=20
> This last seems out of date.
>=20
Indeed, thanks.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-OobNtzXsRn/J9NUdg3/0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jKD0ACgkQk4XaBE3IOsTU8wCeNjoEuzd23XwdovK425EWKFPg
sjwAn3AF16M7rq9SbklZ0QieaVkhzbEl
=CWwc
-----END PGP SIGNATURE-----

--=-OobNtzXsRn/J9NUdg3/0--



--===============7399392068150607059==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7399392068150607059==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 13:57:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13: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 1Shht1-000339-3k; Thu, 21 Jun 2012 13:57:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Shhsz-000332-CM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:57:25 +0000
Received: from [85.158.143.99:45859] by server-3.bemta-4.messagelabs.com id
	79/4B-05808-44823EF4; Thu, 21 Jun 2012 13:57:24 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340287043!22079543!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17790 invoked from network); 21 Jun 2012 13:57:24 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 13:57:24 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79043172; Thu, 21 Jun 2012 15:57:23 +0200
Message-ID: <1340287037.4856.47.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 15:57:17 +0200
In-Reply-To: <1340285920.26083.8.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<0e566a40afad1e3dc299.1339779878@Solace>
	<1340285920.26083.8.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10 of 10 v2] Some automatic NUMA placement
	documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7399392068150607059=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7399392068150607059==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-OobNtzXsRn/J9NUdg3/0"


--=-OobNtzXsRn/J9NUdg3/0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 14:38 +0100, Ian Campbell wrote:
> snipped the bit you said was wrong. It was just be remove not replaced, r=
ight?
>=20
Yes, it will go away, as the algorithm changed and does not do that any
longer.

> > +
> > +## Guest Placement within libxl ##
> > +
> > +xl achieves automatic NUMA placement by means of the following API
> > +calls, provided by libxl.
>=20
> This last seems out of date.
>=20
Indeed, thanks.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-OobNtzXsRn/J9NUdg3/0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jKD0ACgkQk4XaBE3IOsTU8wCeNjoEuzd23XwdovK425EWKFPg
sjwAn3AF16M7rq9SbklZ0QieaVkhzbEl
=CWwc
-----END PGP SIGNATURE-----

--=-OobNtzXsRn/J9NUdg3/0--



--===============7399392068150607059==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7399392068150607059==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 13:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:58: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 1Shhti-00036H-HI; Thu, 21 Jun 2012 13:58:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shhth-000363-Bv
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:58:09 +0000
Received: from [193.109.254.147:58313] by server-3.bemta-14.messagelabs.com id
	6F/E6-08687-07823EF4; Thu, 21 Jun 2012 13:58:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340287084!8776087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7732 invoked from network); 21 Jun 2012 13:58:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 13:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13149746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 13:58:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 14:58:04 +0100
Message-ID: <1340287082.26083.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 14:58:02 +0100
In-Reply-To: <1340286875.4856.44.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<93dc34fa681a1391dcf9.1339779877@Solace>
	<1340285514.26083.4.camel@zakaz.uk.xensource.com>
	<1340286875.4856.44.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
 with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 14:54 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-21 at 14:31 +0100, Ian Campbell wrote:
> > > + * considered suitable wrt the specific constraint. suitable_cpumap is useful
> > > + * for specifyin we want only the cpus in that mask to be considered while
> > 
> >          specifying
> > 
> > Apart from those two spelling errors:
> >
> Yeah, sorry for that. I'm very bad in spelling correctly when typing,
> and this bloody keyboard is not helping! :-P
> 
> Isn't there any tool for spell checking code comments?

I've often thought such a thing would be useful, but I don't know of
one.

TBH I only really spot the spelling errors because my mail client
happens to draw a squiggly red line under them in the quotes.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 13:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 13:58: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 1Shhti-00036H-HI; Thu, 21 Jun 2012 13:58:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Shhth-000363-Bv
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 13:58:09 +0000
Received: from [193.109.254.147:58313] by server-3.bemta-14.messagelabs.com id
	6F/E6-08687-07823EF4; Thu, 21 Jun 2012 13:58:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340287084!8776087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7732 invoked from network); 21 Jun 2012 13:58:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 13:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13149746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 13:58:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 14:58:04 +0100
Message-ID: <1340287082.26083.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 14:58:02 +0100
In-Reply-To: <1340286875.4856.44.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<93dc34fa681a1391dcf9.1339779877@Solace>
	<1340285514.26083.4.camel@zakaz.uk.xensource.com>
	<1340286875.4856.44.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09 of 10 v2] libxl: have NUMA placement deal
 with cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 14:54 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-21 at 14:31 +0100, Ian Campbell wrote:
> > > + * considered suitable wrt the specific constraint. suitable_cpumap is useful
> > > + * for specifyin we want only the cpus in that mask to be considered while
> > 
> >          specifying
> > 
> > Apart from those two spelling errors:
> >
> Yeah, sorry for that. I'm very bad in spelling correctly when typing,
> and this bloody keyboard is not helping! :-P
> 
> Isn't there any tool for spell checking code comments?

I've often thought such a thing would be useful, but I don't know of
one.

TBH I only really spot the spelling errors because my mail client
happens to draw a squiggly red line under them in the quotes.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiE4-0003ZA-N3; Thu, 21 Jun 2012 14:19:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1ShiE3-0003Z5-AZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:19:11 +0000
Received: from [85.158.143.99:39600] by server-3.bemta-4.messagelabs.com id
	36/CF-05808-E5D23EF4; Thu, 21 Jun 2012 14:19:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340288349!28442696!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5286 invoked from network); 21 Jun 2012 14:19:10 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-15.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 14:19:10 -0000
X-TM-IMSS-Message-ID: <8e17b60000001fec@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8e17b60000001fec ; Thu, 21 Jun 2012 10:19:51 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LEJ224001455; 
	Thu, 21 Jun 2012 10:19:02 -0400
Message-ID: <4FE32D56.6000809@tycho.nsa.gov>
Date: Thu, 21 Jun 2012 10:19:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
In-Reply-To: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

On 06/21/2012 09:20 AM, Jan Beulich wrote:
> The mmconfig part of this is seriously broken: These operations,
> even when carried out by Dom0, are MMIO accesses, and hence
> are invisible to the hypervisor without extra handling. Putting
> the checks into pci_mmcfg_{read,write}() has the effect of
> potentially denying the _hypervisor_ access. So I think at least
> that part needs to be reverted.

I agree - the XSM checks are intended to be done only when the hypervisor
is accessing on behalf of the domain, which looks to be covered by the
traps part of the patch. These checks are currently intended to deny a
domain with IS_PRIV but without full hardware access - in particular,
without access to the PCI configuration MMIO area - from using legacy 
register access to reconfigure PCI devices.

While it may be useful to extend this access check to include the PCI 
configuration MMIO pages, this would require emulating both reads and
writes to any page that has entries that a particular domain does not
have access to. The existing pciback/pcifront configuration access model
already handles these issues without changes to the hypervisor.

> Even the I/O port base logic isn't fully correct - AMD's extension
> to access extended config space isn't being taken care of (i.e.
> wrong register values might get passed to the xsm callback).

Looks like a trivial one-line fix, I'll send a patch momentarily. I wasn't
aware of that extension when I was writing the cf8 decoding.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiE4-0003ZA-N3; Thu, 21 Jun 2012 14:19:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1ShiE3-0003Z5-AZ
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:19:11 +0000
Received: from [85.158.143.99:39600] by server-3.bemta-4.messagelabs.com id
	36/CF-05808-E5D23EF4; Thu, 21 Jun 2012 14:19:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340288349!28442696!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5286 invoked from network); 21 Jun 2012 14:19:10 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-15.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 14:19:10 -0000
X-TM-IMSS-Message-ID: <8e17b60000001fec@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8e17b60000001fec ; Thu, 21 Jun 2012 10:19:51 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LEJ224001455; 
	Thu, 21 Jun 2012 10:19:02 -0400
Message-ID: <4FE32D56.6000809@tycho.nsa.gov>
Date: Thu, 21 Jun 2012 10:19:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
In-Reply-To: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

On 06/21/2012 09:20 AM, Jan Beulich wrote:
> The mmconfig part of this is seriously broken: These operations,
> even when carried out by Dom0, are MMIO accesses, and hence
> are invisible to the hypervisor without extra handling. Putting
> the checks into pci_mmcfg_{read,write}() has the effect of
> potentially denying the _hypervisor_ access. So I think at least
> that part needs to be reverted.

I agree - the XSM checks are intended to be done only when the hypervisor
is accessing on behalf of the domain, which looks to be covered by the
traps part of the patch. These checks are currently intended to deny a
domain with IS_PRIV but without full hardware access - in particular,
without access to the PCI configuration MMIO area - from using legacy 
register access to reconfigure PCI devices.

While it may be useful to extend this access check to include the PCI 
configuration MMIO pages, this would require emulating both reads and
writes to any page that has entries that a particular domain does not
have access to. The existing pciback/pcifront configuration access model
already handles these issues without changes to the hypervisor.

> Even the I/O port base logic isn't fully correct - AMD's extension
> to access extended config space isn't being taken care of (i.e.
> wrong register values might get passed to the xsm callback).

Looks like a trivial one-line fix, I'll send a patch momentarily. I wasn't
aware of that extension when I was writing the cf8 decoding.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiEq-0003bj-5U; Thu, 21 Jun 2012 14:20:00 +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 1ShiEo-0003bU-E8
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:19:58 +0000
Received: from [85.158.139.83:42698] by server-5.bemta-5.messagelabs.com id
	D8/2E-02722-B8D23EF4; Thu, 21 Jun 2012 14:19:55 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340288394!28871635!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19692 invoked from network); 21 Jun 2012 14:19:54 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 14:19:54 -0000
Received: by wgbed3 with SMTP id ed3so481183wgb.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 07:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=TLPPAfKWhjsroK0SmLwfelY/F9F1lAAy4tS1eVBWqlY=;
	b=p8E0RsCEhpGcfnxEtmbv0gdCPQCeTeLa+yXkXgD6cuztO3kgUzFPquvRgHfUWZ3lyn
	aumigs5KR3E9l8nPbX7SxXPSJ6cHtr62T1GL069KXxp4skLgpT2mMb4AF0PvFnFZVUEP
	cGRDssWa/YRkhDBS6l0cctgjIinBrbTupJE9jcfWa/XnJsXAU/REezf//SNqezAtU861
	MYeNsxeSUctZfL1at2OuCXhiMlQm+wzU9EP3St5c4uCYNi1DNNDY80Tlkekj1nFwF3m1
	pgrRXfdnpxglvwKAfX5xfVuQFVrFHSuBF1+z7PWmjVzByAw5aIsLzHb7+PbZdKUMq/q5
	MdqQ==
Received: by 10.180.97.165 with SMTP id eb5mr23943687wib.0.1340288394340;
	Thu, 21 Jun 2012 07:19:54 -0700 (PDT)
Received: from [127.0.1.1] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id f7sm89386858wiv.2.2012.06.21.07.19.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 21 Jun 2012 07:19:52 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: fe85a8d600800524917ca1d3904c56c8a0b7660f
Message-Id: <fe85a8d600800524917c.1340288390@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Jun 2012 16:19:50 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] xl: improve the comments for sedf parameters
	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

As agreed during review of what has become 513d5e196e23.

No real functional changes.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -565,28 +565,40 @@ static int sched_params_valid(libxl_doma
     if (sci.sched == LIBXL_SCHEDULER_SEDF) {
         if (has_weight && (has_period || has_slice))
             return 0;
+        /* If you want a real-time domain, with its own period and
+         * slice, please, do provide both! */
         if (has_period != has_slice)
             return 0;
 
         /*
          * Idea is, if we specify a weight, then both period and
-         * slice has to be zero. OTOH, if we do not specify a weight,
-         * that means we want a pure best effort domain or an actual
-         * real-time one. In the former case, it is period that needs
-         * to be zero, in the latter, weight should be.
+         * slice has to be zero. OTOH, if we do specify a period and
+         * slice, it is weight that should be zeroed. See
+         * docs/misc/sedf_scheduler_mini-HOWTO.txt for more details
+         * on the meaningful combinations and their meanings.
          */
         if (has_weight) {
             scp->slice = 0;
             scp->period = 0;
         }
         else if (!has_period) {
-            /* We can setup a proper best effort domain (extra time only)
-             * iff we either already have or are asking for some extra time. */
+            /* No weight nor slice/period means best effort. Parameters needs
+             * some mangling in order to properly ask for that, though. */
+
+            /*
+             * Providing no weight does not make any sense if we do not allow
+             * the domain to run in extra time. On the other hand, if we have
+             * extra time, weight will be ignored (and zeroed) by Xen, but it
+             * can't be zero here, or the call for setting the scheduling
+             * parameters will fail. So, avoid the latter by setting a random
+             * weight (namely, 1), as it will be ignored anyway.
+             */
             scp->weight = has_extratime ? scp->extratime : sci.extratime;
             scp->period = 0;
-        }
-        if (has_period && has_slice)
+        } else {
+            /* Real-time domain: will get slice CPU time over every period */
             scp->weight = 0;
+       }
     }
 
     return 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiEq-0003bj-5U; Thu, 21 Jun 2012 14:20:00 +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 1ShiEo-0003bU-E8
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:19:58 +0000
Received: from [85.158.139.83:42698] by server-5.bemta-5.messagelabs.com id
	D8/2E-02722-B8D23EF4; Thu, 21 Jun 2012 14:19:55 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340288394!28871635!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19692 invoked from network); 21 Jun 2012 14:19:54 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 14:19:54 -0000
Received: by wgbed3 with SMTP id ed3so481183wgb.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 07:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=TLPPAfKWhjsroK0SmLwfelY/F9F1lAAy4tS1eVBWqlY=;
	b=p8E0RsCEhpGcfnxEtmbv0gdCPQCeTeLa+yXkXgD6cuztO3kgUzFPquvRgHfUWZ3lyn
	aumigs5KR3E9l8nPbX7SxXPSJ6cHtr62T1GL069KXxp4skLgpT2mMb4AF0PvFnFZVUEP
	cGRDssWa/YRkhDBS6l0cctgjIinBrbTupJE9jcfWa/XnJsXAU/REezf//SNqezAtU861
	MYeNsxeSUctZfL1at2OuCXhiMlQm+wzU9EP3St5c4uCYNi1DNNDY80Tlkekj1nFwF3m1
	pgrRXfdnpxglvwKAfX5xfVuQFVrFHSuBF1+z7PWmjVzByAw5aIsLzHb7+PbZdKUMq/q5
	MdqQ==
Received: by 10.180.97.165 with SMTP id eb5mr23943687wib.0.1340288394340;
	Thu, 21 Jun 2012 07:19:54 -0700 (PDT)
Received: from [127.0.1.1] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id f7sm89386858wiv.2.2012.06.21.07.19.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 21 Jun 2012 07:19:52 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: fe85a8d600800524917ca1d3904c56c8a0b7660f
Message-Id: <fe85a8d600800524917c.1340288390@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Jun 2012 16:19:50 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] xl: improve the comments for sedf parameters
	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

As agreed during review of what has become 513d5e196e23.

No real functional changes.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -565,28 +565,40 @@ static int sched_params_valid(libxl_doma
     if (sci.sched == LIBXL_SCHEDULER_SEDF) {
         if (has_weight && (has_period || has_slice))
             return 0;
+        /* If you want a real-time domain, with its own period and
+         * slice, please, do provide both! */
         if (has_period != has_slice)
             return 0;
 
         /*
          * Idea is, if we specify a weight, then both period and
-         * slice has to be zero. OTOH, if we do not specify a weight,
-         * that means we want a pure best effort domain or an actual
-         * real-time one. In the former case, it is period that needs
-         * to be zero, in the latter, weight should be.
+         * slice has to be zero. OTOH, if we do specify a period and
+         * slice, it is weight that should be zeroed. See
+         * docs/misc/sedf_scheduler_mini-HOWTO.txt for more details
+         * on the meaningful combinations and their meanings.
          */
         if (has_weight) {
             scp->slice = 0;
             scp->period = 0;
         }
         else if (!has_period) {
-            /* We can setup a proper best effort domain (extra time only)
-             * iff we either already have or are asking for some extra time. */
+            /* No weight nor slice/period means best effort. Parameters needs
+             * some mangling in order to properly ask for that, though. */
+
+            /*
+             * Providing no weight does not make any sense if we do not allow
+             * the domain to run in extra time. On the other hand, if we have
+             * extra time, weight will be ignored (and zeroed) by Xen, but it
+             * can't be zero here, or the call for setting the scheduling
+             * parameters will fail. So, avoid the latter by setting a random
+             * weight (namely, 1), as it will be ignored anyway.
+             */
             scp->weight = has_extratime ? scp->extratime : sci.extratime;
             scp->period = 0;
-        }
-        if (has_period && has_slice)
+        } else {
+            /* Real-time domain: will get slice CPU time over every period */
             scp->weight = 0;
+       }
     }
 
     return 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShiFm-0003hw-Oj; Thu, 21 Jun 2012 14:20:58 +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 1ShiFl-0003hm-T2
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:20:57 +0000
Received: from [193.109.254.147:4400] by server-9.bemta-14.messagelabs.com id
	4D/84-07693-9CD23EF4; Thu, 21 Jun 2012 14:20:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340288453!3760477!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28456 invoked from network); 21 Jun 2012 14:20:53 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-11.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 14:20:53 -0000
X-TM-IMSS-Message-ID: <8e19281300001934@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8e19281300001934 ; Thu, 21 Jun 2012 10:23:06 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LEKj7b001677; 
	Thu, 21 Jun 2012 10:20:45 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Date: Thu, 21 Jun 2012 10:20:44 -0400
Message-Id: <1340288444-6585-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.10.2
In-Reply-To: <4FE32D56.6000809@tycho.nsa.gov>
References: <4FE32D56.6000809@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using AMD's extension to access the extended PCI config space, only
the low byte of the register number was being passed to XSM. Include the
full value.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/traps.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2264583..38ad9e7 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1691,6 +1691,7 @@ static int pci_cfg_ok(struct domain *d, int write, int size)
 
     machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
     start = d->arch.pci_cf8 & 0xFF;
+    start |= (d->arch.pci_cf8 >> 16) & 0xF00;
     end = start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
         return 0;
-- 
1.7.10.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShiFm-0003hw-Oj; Thu, 21 Jun 2012 14:20:58 +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 1ShiFl-0003hm-T2
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:20:57 +0000
Received: from [193.109.254.147:4400] by server-9.bemta-14.messagelabs.com id
	4D/84-07693-9CD23EF4; Thu, 21 Jun 2012 14:20:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340288453!3760477!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28456 invoked from network); 21 Jun 2012 14:20:53 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-11.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 14:20:53 -0000
X-TM-IMSS-Message-ID: <8e19281300001934@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8e19281300001934 ; Thu, 21 Jun 2012 10:23:06 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LEKj7b001677; 
	Thu, 21 Jun 2012 10:20:45 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Date: Thu, 21 Jun 2012 10:20:44 -0400
Message-Id: <1340288444-6585-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.10.2
In-Reply-To: <4FE32D56.6000809@tycho.nsa.gov>
References: <4FE32D56.6000809@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using AMD's extension to access the extended PCI config space, only
the low byte of the register number was being passed to XSM. Include the
full value.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/traps.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2264583..38ad9e7 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1691,6 +1691,7 @@ static int pci_cfg_ok(struct domain *d, int write, int size)
 
     machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
     start = d->arch.pci_cf8 & 0xFF;
+    start |= (d->arch.pci_cf8 >> 16) & 0xF00;
     end = start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
         return 0;
-- 
1.7.10.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiGv-0003pG-7R; Thu, 21 Jun 2012 14:22:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ShiGt-0003oz-IZ
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 14:22:07 +0000
Received: from [193.109.254.147:2677] by server-8.bemta-14.messagelabs.com id
	4C/C5-30743-E0E23EF4; Thu, 21 Jun 2012 14:22:06 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340288524!3760693!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2695 invoked from network); 21 Jun 2012 14:22:04 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 14:22:04 -0000
Received: from mail74-va3-R.bigfish.com (10.7.14.251) by
	VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 14:20:37 +0000
Received: from mail74-va3 (localhost [127.0.0.1])	by mail74-va3-R.bigfish.com
	(Postfix) with ESMTP id C97632C037F;
	Thu, 21 Jun 2012 14:20:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I103dK179dN168aJ148cI1432Ic55bszz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail74-va3 (localhost.localdomain [127.0.0.1]) by mail74-va3
	(MessageSwitch) id 1340288435574103_643; Thu, 21 Jun 2012 14:20:35 +0000
	(UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.235])	by
	mail74-va3.bigfish.com (Postfix) with ESMTP id 887C3340058;
	Thu, 21 Jun 2012 14:20:35 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 14:20:34 +0000
X-WSS-ID: 0M5Z18N-01-23O-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E6B910280DD;	Thu, 21 Jun 2012 09:21:58 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 09:22:14 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 21 Jun 2012 09:21:58 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	10:21:57 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BF1B949C69D; Thu, 21 Jun 2012
	15:21:54 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id 924C25940FF; Thu, 21 Jun 2012
	16:21:54 +0200 (CEST)
Message-ID: <4FE32DDA.10204@amd.com>
Date: Thu, 21 Jun 2012 16:21:14 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4FE1C423.6070001@amd.com>
	<20120620145127.GD12787@phenom.dumpdata.com>
In-Reply-To: <20120620145127.GD12787@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/20/2012 04:51 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 20, 2012 at 02:37:55PM +0200, Andre Przywara wrote:

Konrad,

thanks for looking at the problem. Replies inline...

>> we have some problems with acpidump running on Xen Dom0. On 64 bit
>> Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a
>> kernel crash.
>> The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
>> unstable versions including 25467, also 32-bit versions of 4.1.
>> The Dom0 kernels were always PVOPS versions, the problems starts
>> with 3.2-rc1~194 and is still in 3.5.0-rc3.
>> Also you need to restrict the Dom0 memory with dom0_mem=
>> The crash says (on a 3.4.3 32bit Dom0 kernel):
>> uruk:~ # ./acpidump32
>> [  158.843444] ------------[ cut here ]------------
>> [  158.843460] kernel BUG at mm/rmap.c:1027!
>> [  158.843466] invalid opcode: 0000 [#1] SMP
>> [  158.843472] Modules linked in:
>> [  158.843478]
>> [  158.843483] Pid: 4874, comm: acpidump32 Tainted: G        W
>> 3.4.0+ #105 empty empty/S3993
>> [  158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
>> [  158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
>> [  158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
>> [  158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
>> [  158.843522]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
>> [  158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
>> [  158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> [  158.843581] DR6: ffff0ff0 DR7: 00000400
>> [  158.843586] Process acpidump32 (pid: 4874, ti=d6090000
>> task=d60b34f0 task.ti=d6090000)
>> [  158.843591] Stack:
>> [  158.843594]  dfecb6e0 00000001 d6091ea8 c10b15c4 00000000
>> d6022dc0 d61fbdd8 d6022dc0
>> [  158.843610]  00000000 d6091efc c10aacbe 00000000 99948025
>> 80000001 d8aa1f80 80000001
>> [  158.843631]  dfefc800 00000000 d8aa1f80 00000000 166b7025
>> d7f407d0 b76faf64 99948025
>> [  158.843649] Call Trace:
>> [  158.843656]  [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
>> [  158.843664]  [<c10aacbe>] handle_pte_fault+0x81d/0xa06
>> [  158.843674]  [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
>> [  158.843683]  [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [  158.843688]  [<c159e881>] do_page_fault+0x399/0x3b4
>> [  158.843696]  [<c10c639d>] ? filp_close+0x55/0x5f
>> [  158.843701]  [<c10c6408>] ? sys_close+0x61/0xa0
>> [  158.843706]  [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [  158.843714]  [<c159c452>] error_code+0x5a/0x60
>> [  158.843720]  [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [  158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03
>> 50 4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44
>> 85 f6 75 02<0f>  0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89
>> 73 04 f6
>> [  158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45
>> SS:ESP 0069:d6091e84
>> [  158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
>> [  158.843854] note: acpidump32[4874] exited with preempt_count 1
>>
>>
>> On 64bit the OOM goes around, finally killing the login shell:
>> uruk:~ # ./acpidump_inst
>> acpi_map_memory(917504, 131072);
>> opened /dev/mem (fd=3)
>> calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
>>    mmap returned 0xf7571000, function returns 0xf7571000
>> acpi_map_table(cfef0f64, "XSDT");
>> acpi_map_memory(3488550756, 36);
>> opened /dev/mem (fd=3)
>> calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
>>    mmap returned 0xf76fd000, function returns 0xf76fdf64
>>    having mapped table header
>>    reading signature:
>>
>> Welcome to SUSE Linux Enterprise Server 11 SP1  (i586) - Kernel
>> 3.5.0-rc3+ (hvc0).
>>
>> uruk login:
>> -----------
>> This dump shows that the bug happens the moment acpidump accesses
>> the mmapped ACPI table at @cfef0000 (the lower map at e0000 works).
>
> What is the e0000 one? I don't see in your E820 the region being
> reserved?

E0000 is the below 1 MB BIOS area with the ACPI RSDP root pointer.
E000:0000 in old DOS speak. The ACPI spec says that the pointer to the 
tables is hidden somewhere between 896K and 1MB at 16 byte granularity.
acpidump scans this area for the ACPI magic number.
So mapping /dev/mem is not fully broken, as this part at least works.

>>
>> This is extra unfortunate as in SLES11 acpidump will be called by
>> the kbd init script (querying the BIOS NumLock setting!)
>
> Ah. Is the acpidump somewhere easily available to compile? Should
> I get it from here:
> http://www.lesswatts.org/projects/acpi/utilities.php

Right, it is in the pmtools-20071116.tar.gz archive. Just say make in 
the acpidump directory.

>>
>> I bisected the Dom0 kernel to find this one (v3.2-rc~194):
>> commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
>> Merge: 315eb8a f3f436e
>> Author: Linus Torvalds<torvalds@linux-foundation.org>
>> Date:   Tue Oct 25 09:17:07 2011 +0200
>>
>>      Merge branch 'stable/e820-3.2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
>>
>>      * 'stable/e820-3.2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
>
> Oh boy. v3.2 .. that is eons ago! :-)

Tell that those 2.6.32 or even 2.6.18 users...

>
>>        xen: release all pages within 1-1 p2m mappings
>>        xen: allow extra memory to be in multiple regions
>>        xen: allow balloon driver to use more than one memory region
>>        xen/balloon: simplify test for the end of usable RAM
>>        xen/balloon: account for pages released during memory setup
>>
>>
>> I tried to find something obvious, but to no avail. At least the new
>> E820 looks sane, nothing that would prevent the mapping of the
>> requested regions. Reverting this commit will not work easily on
>> newer kernels, also is probably not desirable.
>
> The one thing that comes to my mind is the 1-1 mapping having
> some issues. Can you boot the kernel with 'debug loglevel=8'. That should
> print something like this:
>
> Setting pfn cfef0->cfef7 to 1-1
> or such during bootup.

Hmm, I couldn't trigger such messages. Do I need some magic config to 
enable them? So far I have (among others):
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_VIRTUAL=y
CONFIG_DEBUG_MEMORY_INIT=y

>>
>> But it does not show on every machine here, so the machine E820
>> could actually be a differentiator. This particular box was a dual
>> socket Barcelona server with 12GB of memory.
>>
>> This whole PV memory management goes beyond my knowledge, so I'd
>> like to ask for help on this issue.
>> If you need more information (I attached the boot log, which shows
>> the two E820 tables), please ask. I can also quickly do some
>> experiments if needed.
>
> This is strange one - the P2M code should fetch the MFN (so it should
> give you cfef0) whenever anybody asks for that. Lets double-check that.
>
> Can you try this little module?

Right, it chokes. Mapping memory below 1MB works:
# insmod testxenmap.ko pfn=0xf8
# rmmod testxenmap
# dmesg
...
[   60.369526] va is 0xffff8800000f8000
[   60.369533] acpi:00000000: 80 dc 0f 00 00 ff 00 00 00 00 00 00 00 00 
00 00  ................
[   60.369536] acpi:00000010: 52 53 44 20 50 54 52 20 4a 50 54 4c 54 44 
20 02  RSD PTR JPTLTD .
[   60.369538] acpi:00000020: 20 0f ef cf 24 00 00 00 64 0f ef cf 00 00 
00 00   ...$...d.......
....
you see the magic "RSD PTR " string here, at 0x20 the 32bit address of 
the actual tables (0xcfef0f20), which we try next:
# insmod testxenmap.ko pfn=0xcfef0
insmod: error inserting 'testxenmap.ko': -1 Invalid parameters
# dmesg
....
[  351.964914] ------------[ cut here ]------------
[  351.964924] WARNING: at /src/linux-2.6/xentest/testxenmap.c:24 
acpitest_init+0x5e/0x1000 [testxenmap]()
[  351.964926] Hardware name: empty
[  351.964928] We get cfef0 instead of ffffffffffffffff!
[  351.964933] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
[  351.964936] Pid: 4937, comm: insmod Tainted: G        W  O 3.5.0-rc3+ 
#106
[  351.964938] Call Trace:
[  351.964944]  [<ffffffffa000a05e>] ? acpitest_init+0x5e/0x1000 
[testxenmap]
[  351.964953]  [<ffffffff81050747>] warn_slowpath_common+0x80/0x98
[  351.964956]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
[  351.964959]  [<ffffffff810507f3>] warn_slowpath_fmt+0x41/0x43
[  351.964963]  [<ffffffffa000a05e>] acpitest_init+0x5e/0x1000 [testxenmap]
[  351.964966]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
[  351.964971]  [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
[  351.964976]  [<ffffffff81094512>] sys_init_module+0xbf/0x24b
[  351.964982]  [<ffffffff816bb826>] cstar_dispatch+0x7/0x21
[  351.964985] ---[ end trace 4eaa2a86a8e2da24 ]---
[  351.964987] raw p2m (cfef0) gives us: ffffffffffffffff

starting the kernel without dom0_mem (where acpidump works flawlessly) 
also makes the module crash, although only at the point dumping the 
buffer (so this could be a different issue):
# insmod testxenmap.ko pfn=0xcfef0
[  243.071693] va is 0xffff8800cfef0000
[  243.071710] BUG: unable to handle kernel paging request at 
ffff8800cfef0000
[  243.071733] IP: [<ffffffff81275a22>] hex_dump_to_buffer+0x19c/0x282
[  243.071742] PGD 1c0c067 PUD f5b067 PMD fdb067 PTE 0
[  243.071748] Oops: 0000 [#1] SMP
[  243.071753] CPU 5
[  243.071757] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
[  243.071762]
[  243.071768] Pid: 4825, comm: insmod Tainted: G        W  O 3.5.0-rc3+ 
#106 empty empty/S3993
[  243.071777] RIP: e030:[<ffffffff81275a22>]  [<ffffffff81275a22>] 
hex_dump_to_buffer+0x19c/0x282
[  243.071783] RSP: e02b:ffff880312e2fd58  EFLAGS: 00010203
...

Hope that helps and thanks!

Andre.

> [not compile tested]
ACK ;-)
>
> #include<linux/module.h>
> #include<linux/kthread.h>
> #include<linux/pagemap.h>
> #include<linux/init.h>
> #include<xen/xen.h>
+ #include<xen/page.h>
> #define ACPITEST  "0.1"
>
> MODULE_AUTHOR("Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>");
> MODULE_DESCRIPTION("acpitest");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(ACPITEST);
>
+unsigned long pfn = 0xcfef0;
+module_param(pfn, ulong, 0644);
+MODULE_PARM_DESC(pfn, "pfn to test");
+
> static int __init acpitest_init(void)
> {
- 	unsigned int pfn = 0xcfef0;
- 	unsigned int mfn;
+ 	unsigned long mfn;
> 	void *data;
>
> 	mfn = pfn_to_mfn(pfn);
- 	WARN_ON(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
+ 	WARN(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
> 	if (pfn != mfn) {
> 		printk(KERN_INFO "raw p2m (%lx) gives us: %lx\n", pfn, get_phys_to_machine(pfn));
> 		return -EINVAL;
> 	}
> 	data = mfn_to_virt(mfn);
- 	printk(KERN_INFO "va is 0x%lx\n", data);
+ 	printk(KERN_INFO "va is 0x%p\n", data);
> 	print_hex_dump_bytes("acpi:", DUMP_PREFIX_OFFSET, data, PAGE_SIZE);
> 	
> 	return 0;
> }
> static void __exit acpitest_exit(void)
> {
> }
> module_init(acpitest_init);
> module_exit(acpitest_exit);
>
>


-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiGv-0003pG-7R; Thu, 21 Jun 2012 14:22:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1ShiGt-0003oz-IZ
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 14:22:07 +0000
Received: from [193.109.254.147:2677] by server-8.bemta-14.messagelabs.com id
	4C/C5-30743-E0E23EF4; Thu, 21 Jun 2012 14:22:06 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340288524!3760693!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2695 invoked from network); 21 Jun 2012 14:22:04 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 14:22:04 -0000
Received: from mail74-va3-R.bigfish.com (10.7.14.251) by
	VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 14:20:37 +0000
Received: from mail74-va3 (localhost [127.0.0.1])	by mail74-va3-R.bigfish.com
	(Postfix) with ESMTP id C97632C037F;
	Thu, 21 Jun 2012 14:20:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I103dK179dN168aJ148cI1432Ic55bszz1202hzz8275bh8275dhz2dh668h839hd25he5bhf0ah)
Received: from mail74-va3 (localhost.localdomain [127.0.0.1]) by mail74-va3
	(MessageSwitch) id 1340288435574103_643; Thu, 21 Jun 2012 14:20:35 +0000
	(UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.235])	by
	mail74-va3.bigfish.com (Postfix) with ESMTP id 887C3340058;
	Thu, 21 Jun 2012 14:20:35 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 14:20:34 +0000
X-WSS-ID: 0M5Z18N-01-23O-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E6B910280DD;	Thu, 21 Jun 2012 09:21:58 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 09:22:14 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 21 Jun 2012 09:21:58 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	10:21:57 -0400
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BF1B949C69D; Thu, 21 Jun 2012
	15:21:54 +0100 (BST)
Received: from [165.204.15.38] (wanderer.osrc.amd.com [165.204.15.38])	by
	mail.osrc.amd.com (Postfix) with ESMTPS id 924C25940FF; Thu, 21 Jun 2012
	16:21:54 +0200 (CEST)
Message-ID: <4FE32DDA.10204@amd.com>
Date: Thu, 21 Jun 2012 16:21:14 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4FE1C423.6070001@amd.com>
	<20120620145127.GD12787@phenom.dumpdata.com>
In-Reply-To: <20120620145127.GD12787@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/20/2012 04:51 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 20, 2012 at 02:37:55PM +0200, Andre Przywara wrote:

Konrad,

thanks for looking at the problem. Replies inline...

>> we have some problems with acpidump running on Xen Dom0. On 64 bit
>> Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a
>> kernel crash.
>> The hypervisor does not matter, I tried 4.1.3-rc2 as well as various
>> unstable versions including 25467, also 32-bit versions of 4.1.
>> The Dom0 kernels were always PVOPS versions, the problems starts
>> with 3.2-rc1~194 and is still in 3.5.0-rc3.
>> Also you need to restrict the Dom0 memory with dom0_mem=
>> The crash says (on a 3.4.3 32bit Dom0 kernel):
>> uruk:~ # ./acpidump32
>> [  158.843444] ------------[ cut here ]------------
>> [  158.843460] kernel BUG at mm/rmap.c:1027!
>> [  158.843466] invalid opcode: 0000 [#1] SMP
>> [  158.843472] Modules linked in:
>> [  158.843478]
>> [  158.843483] Pid: 4874, comm: acpidump32 Tainted: G        W
>> 3.4.0+ #105 empty empty/S3993
>> [  158.843493] EIP: 0061:[<c10b0e27>] EFLAGS: 00010246 CPU: 3
>> [  158.843505] EIP is at __page_set_anon_rmap+0x12/0x45
>> [  158.843511] EAX: d6022dc0 EBX: dfecb6e0 ECX: b76faf64 EDX: b76faf64
>> [  158.843516] ESI: 00000000 EDI: b76faf64 EBP: d6091e8c ESP: d6091e84
>> [  158.843522]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
>> [  158.843529] CR0: 8005003b CR2: b76faf64 CR3: 17633000 CR4: 00000660
>> [  158.843535] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> [  158.843581] DR6: ffff0ff0 DR7: 00000400
>> [  158.843586] Process acpidump32 (pid: 4874, ti=d6090000
>> task=d60b34f0 task.ti=d6090000)
>> [  158.843591] Stack:
>> [  158.843594]  dfecb6e0 00000001 d6091ea8 c10b15c4 00000000
>> d6022dc0 d61fbdd8 d6022dc0
>> [  158.843610]  00000000 d6091efc c10aacbe 00000000 99948025
>> 80000001 d8aa1f80 80000001
>> [  158.843631]  dfefc800 00000000 d8aa1f80 00000000 166b7025
>> d7f407d0 b76faf64 99948025
>> [  158.843649] Call Trace:
>> [  158.843656]  [<c10b15c4>] do_page_add_anon_rmap+0x5b/0x64
>> [  158.843664]  [<c10aacbe>] handle_pte_fault+0x81d/0xa06
>> [  158.843674]  [<c10ab0ff>] handle_mm_fault+0x1fa/0x209
>> [  158.843683]  [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [  158.843688]  [<c159e881>] do_page_fault+0x399/0x3b4
>> [  158.843696]  [<c10c639d>] ? filp_close+0x55/0x5f
>> [  158.843701]  [<c10c6408>] ? sys_close+0x61/0xa0
>> [  158.843706]  [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [  158.843714]  [<c159c452>] error_code+0x5a/0x60
>> [  158.843720]  [<c159e4e8>] ? spurious_fault+0x104/0x104
>> [  158.843724] Code: e8 45 91 00 00 89 c2 eb 09 2b 50 04 c1 ea 0c 03
>> 50 4c 89 53 08 5b 5e 5d c3 55 89 e5 56 53 89 c3 89 d0 89 ca 8b 70 44
>> 85 f6 75 02<0f>  0b f6 43 04 01 75 27 83 7d 08 00 75 02 8b 36 46 89
>> 73 04 f6
>> [  158.843824] EIP: [<c10b0e27>] __page_set_anon_rmap+0x12/0x45
>> SS:ESP 0069:d6091e84
>> [  158.843848] ---[ end trace 4eaa2a86a8e2da24 ]---
>> [  158.843854] note: acpidump32[4874] exited with preempt_count 1
>>
>>
>> On 64bit the OOM goes around, finally killing the login shell:
>> uruk:~ # ./acpidump_inst
>> acpi_map_memory(917504, 131072);
>> opened /dev/mem (fd=3)
>> calling mmap(NULL, 131072, PROT_READ, MAP_PRIVATE, fd, e0000);
>>    mmap returned 0xf7571000, function returns 0xf7571000
>> acpi_map_table(cfef0f64, "XSDT");
>> acpi_map_memory(3488550756, 36);
>> opened /dev/mem (fd=3)
>> calling mmap(NULL, 3976, PROT_READ, MAP_PRIVATE, fd, cfef0000);
>>    mmap returned 0xf76fd000, function returns 0xf76fdf64
>>    having mapped table header
>>    reading signature:
>>
>> Welcome to SUSE Linux Enterprise Server 11 SP1  (i586) - Kernel
>> 3.5.0-rc3+ (hvc0).
>>
>> uruk login:
>> -----------
>> This dump shows that the bug happens the moment acpidump accesses
>> the mmapped ACPI table at @cfef0000 (the lower map at e0000 works).
>
> What is the e0000 one? I don't see in your E820 the region being
> reserved?

E0000 is the below 1 MB BIOS area with the ACPI RSDP root pointer.
E000:0000 in old DOS speak. The ACPI spec says that the pointer to the 
tables is hidden somewhere between 896K and 1MB at 16 byte granularity.
acpidump scans this area for the ACPI magic number.
So mapping /dev/mem is not fully broken, as this part at least works.

>>
>> This is extra unfortunate as in SLES11 acpidump will be called by
>> the kbd init script (querying the BIOS NumLock setting!)
>
> Ah. Is the acpidump somewhere easily available to compile? Should
> I get it from here:
> http://www.lesswatts.org/projects/acpi/utilities.php

Right, it is in the pmtools-20071116.tar.gz archive. Just say make in 
the acpidump directory.

>>
>> I bisected the Dom0 kernel to find this one (v3.2-rc~194):
>> commit 5eef150c1d7e41baaefd00dd56c153debcd86aee
>> Merge: 315eb8a f3f436e
>> Author: Linus Torvalds<torvalds@linux-foundation.org>
>> Date:   Tue Oct 25 09:17:07 2011 +0200
>>
>>      Merge branch 'stable/e820-3.2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
>>
>>      * 'stable/e820-3.2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
>
> Oh boy. v3.2 .. that is eons ago! :-)

Tell that those 2.6.32 or even 2.6.18 users...

>
>>        xen: release all pages within 1-1 p2m mappings
>>        xen: allow extra memory to be in multiple regions
>>        xen: allow balloon driver to use more than one memory region
>>        xen/balloon: simplify test for the end of usable RAM
>>        xen/balloon: account for pages released during memory setup
>>
>>
>> I tried to find something obvious, but to no avail. At least the new
>> E820 looks sane, nothing that would prevent the mapping of the
>> requested regions. Reverting this commit will not work easily on
>> newer kernels, also is probably not desirable.
>
> The one thing that comes to my mind is the 1-1 mapping having
> some issues. Can you boot the kernel with 'debug loglevel=8'. That should
> print something like this:
>
> Setting pfn cfef0->cfef7 to 1-1
> or such during bootup.

Hmm, I couldn't trigger such messages. Do I need some magic config to 
enable them? So far I have (among others):
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_VIRTUAL=y
CONFIG_DEBUG_MEMORY_INIT=y

>>
>> But it does not show on every machine here, so the machine E820
>> could actually be a differentiator. This particular box was a dual
>> socket Barcelona server with 12GB of memory.
>>
>> This whole PV memory management goes beyond my knowledge, so I'd
>> like to ask for help on this issue.
>> If you need more information (I attached the boot log, which shows
>> the two E820 tables), please ask. I can also quickly do some
>> experiments if needed.
>
> This is strange one - the P2M code should fetch the MFN (so it should
> give you cfef0) whenever anybody asks for that. Lets double-check that.
>
> Can you try this little module?

Right, it chokes. Mapping memory below 1MB works:
# insmod testxenmap.ko pfn=0xf8
# rmmod testxenmap
# dmesg
...
[   60.369526] va is 0xffff8800000f8000
[   60.369533] acpi:00000000: 80 dc 0f 00 00 ff 00 00 00 00 00 00 00 00 
00 00  ................
[   60.369536] acpi:00000010: 52 53 44 20 50 54 52 20 4a 50 54 4c 54 44 
20 02  RSD PTR JPTLTD .
[   60.369538] acpi:00000020: 20 0f ef cf 24 00 00 00 64 0f ef cf 00 00 
00 00   ...$...d.......
....
you see the magic "RSD PTR " string here, at 0x20 the 32bit address of 
the actual tables (0xcfef0f20), which we try next:
# insmod testxenmap.ko pfn=0xcfef0
insmod: error inserting 'testxenmap.ko': -1 Invalid parameters
# dmesg
....
[  351.964914] ------------[ cut here ]------------
[  351.964924] WARNING: at /src/linux-2.6/xentest/testxenmap.c:24 
acpitest_init+0x5e/0x1000 [testxenmap]()
[  351.964926] Hardware name: empty
[  351.964928] We get cfef0 instead of ffffffffffffffff!
[  351.964933] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
[  351.964936] Pid: 4937, comm: insmod Tainted: G        W  O 3.5.0-rc3+ 
#106
[  351.964938] Call Trace:
[  351.964944]  [<ffffffffa000a05e>] ? acpitest_init+0x5e/0x1000 
[testxenmap]
[  351.964953]  [<ffffffff81050747>] warn_slowpath_common+0x80/0x98
[  351.964956]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
[  351.964959]  [<ffffffff810507f3>] warn_slowpath_fmt+0x41/0x43
[  351.964963]  [<ffffffffa000a05e>] acpitest_init+0x5e/0x1000 [testxenmap]
[  351.964966]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
[  351.964971]  [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
[  351.964976]  [<ffffffff81094512>] sys_init_module+0xbf/0x24b
[  351.964982]  [<ffffffff816bb826>] cstar_dispatch+0x7/0x21
[  351.964985] ---[ end trace 4eaa2a86a8e2da24 ]---
[  351.964987] raw p2m (cfef0) gives us: ffffffffffffffff

starting the kernel without dom0_mem (where acpidump works flawlessly) 
also makes the module crash, although only at the point dumping the 
buffer (so this could be a different issue):
# insmod testxenmap.ko pfn=0xcfef0
[  243.071693] va is 0xffff8800cfef0000
[  243.071710] BUG: unable to handle kernel paging request at 
ffff8800cfef0000
[  243.071733] IP: [<ffffffff81275a22>] hex_dump_to_buffer+0x19c/0x282
[  243.071742] PGD 1c0c067 PUD f5b067 PMD fdb067 PTE 0
[  243.071748] Oops: 0000 [#1] SMP
[  243.071753] CPU 5
[  243.071757] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
[  243.071762]
[  243.071768] Pid: 4825, comm: insmod Tainted: G        W  O 3.5.0-rc3+ 
#106 empty empty/S3993
[  243.071777] RIP: e030:[<ffffffff81275a22>]  [<ffffffff81275a22>] 
hex_dump_to_buffer+0x19c/0x282
[  243.071783] RSP: e02b:ffff880312e2fd58  EFLAGS: 00010203
...

Hope that helps and thanks!

Andre.

> [not compile tested]
ACK ;-)
>
> #include<linux/module.h>
> #include<linux/kthread.h>
> #include<linux/pagemap.h>
> #include<linux/init.h>
> #include<xen/xen.h>
+ #include<xen/page.h>
> #define ACPITEST  "0.1"
>
> MODULE_AUTHOR("Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>");
> MODULE_DESCRIPTION("acpitest");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(ACPITEST);
>
+unsigned long pfn = 0xcfef0;
+module_param(pfn, ulong, 0644);
+MODULE_PARM_DESC(pfn, "pfn to test");
+
> static int __init acpitest_init(void)
> {
- 	unsigned int pfn = 0xcfef0;
- 	unsigned int mfn;
+ 	unsigned long mfn;
> 	void *data;
>
> 	mfn = pfn_to_mfn(pfn);
- 	WARN_ON(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
+ 	WARN(pfn != mfn, "We get %lx instead of %lx!\n", pfn, mfn);
> 	if (pfn != mfn) {
> 		printk(KERN_INFO "raw p2m (%lx) gives us: %lx\n", pfn, get_phys_to_machine(pfn));
> 		return -EINVAL;
> 	}
> 	data = mfn_to_virt(mfn);
- 	printk(KERN_INFO "va is 0x%lx\n", data);
+ 	printk(KERN_INFO "va is 0x%p\n", data);
> 	print_hex_dump_bytes("acpi:", DUMP_PREFIX_OFFSET, data, PAGE_SIZE);
> 	
> 	return 0;
> }
> static void __exit acpitest_exit(void)
> {
> }
> module_init(acpitest_init);
> module_exit(acpitest_exit);
>
>


-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:33:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiRA-0004Cu-DS; Thu, 21 Jun 2012 14:32:44 +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 1ShiR8-0004CD-VS
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:32:43 +0000
Received: from [193.109.254.147:33474] by server-6.bemta-14.messagelabs.com id
	67/AE-08993-A8033EF4; Thu, 21 Jun 2012 14:32:42 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340289160!8783877!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19012 invoked from network); 21 Jun 2012 14:32:40 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 14:32:40 -0000
Received: by eaak12 with SMTP id k12so302482eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 07:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=bFUqZXJillUsepeo1TENJbrp7BmW1fKzmuyH3hJUpUA=;
	b=0pLDV72SUKql3pLnz69ogYV86lo5z3pvSJbQhGFwSlxxLO9q7bBLEuT1IahPUxgmEj
	vfe5kT0Vj/3LZNfNewW2qZG+0cd71ZpXr8PXSbj/Hrk+rC0SgR6lJMLm4cMw90xj71Pr
	Y8GJJUlqQZuEa6ISHyebA4arobfe/KnaoqE6UijNJM3EnOlI9ZPmE8fSz0XdljlJecQD
	wa/v4e71Wr8Z8djSvIGxiKGjeHbNdqDD9hf6SUg2G2oBE9YjZB+ry7QGfiqQDAt/5rOL
	hDFYqHrnzAExFmBRzdHQzyM3HWRKZzlPHeIwPIZvni4sFHzXoQLC19vzkbrI8CSmZWZt
	8KlQ==
Received: by 10.14.29.71 with SMTP id h47mr6231252eea.129.1340289160443;
	Thu, 21 Jun 2012 07:32:40 -0700 (PDT)
Received: from [192.168.0.40] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id c42sm103465309eeb.2.2012.06.21.07.32.36
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 07:32:38 -0700 (PDT)
Message-ID: <1340289150.4856.51.camel@Solace>
From: Dario Faggioli <raistlin.df@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 16:32:30 +0200
In-Reply-To: <1339570785.4705.9.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:
> > Ian J answered for the general commit case but in case you are
> > interested for the mq case you can put a comment at the top of the patch
> > (before the changelog) with the same form as what "hg export" gives you.
> > e.g.:
> >         # HG changeset patch
> >         # User Ian Campbell <ian.campbell@citrix.com>
> > 
So, I have this in place, as I did when sent v2. However, as I suppose
this is not doing its job, as I see this:

From: 	Dario Faggioli <raistlinxxx>
To: 	xen-develxxx
Cc: 	...
Subject: 	[PATCH 02 of 10 v2] libxl: add a new Array type to the IDL

Maybe I should remove the --plain option from my patchbomb line, so that
those comments make it to the list?

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 Thu Jun 21 14:33:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiRA-0004Cu-DS; Thu, 21 Jun 2012 14:32:44 +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 1ShiR8-0004CD-VS
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:32:43 +0000
Received: from [193.109.254.147:33474] by server-6.bemta-14.messagelabs.com id
	67/AE-08993-A8033EF4; Thu, 21 Jun 2012 14:32:42 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340289160!8783877!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19012 invoked from network); 21 Jun 2012 14:32:40 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 14:32:40 -0000
Received: by eaak12 with SMTP id k12so302482eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 07:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=bFUqZXJillUsepeo1TENJbrp7BmW1fKzmuyH3hJUpUA=;
	b=0pLDV72SUKql3pLnz69ogYV86lo5z3pvSJbQhGFwSlxxLO9q7bBLEuT1IahPUxgmEj
	vfe5kT0Vj/3LZNfNewW2qZG+0cd71ZpXr8PXSbj/Hrk+rC0SgR6lJMLm4cMw90xj71Pr
	Y8GJJUlqQZuEa6ISHyebA4arobfe/KnaoqE6UijNJM3EnOlI9ZPmE8fSz0XdljlJecQD
	wa/v4e71Wr8Z8djSvIGxiKGjeHbNdqDD9hf6SUg2G2oBE9YjZB+ry7QGfiqQDAt/5rOL
	hDFYqHrnzAExFmBRzdHQzyM3HWRKZzlPHeIwPIZvni4sFHzXoQLC19vzkbrI8CSmZWZt
	8KlQ==
Received: by 10.14.29.71 with SMTP id h47mr6231252eea.129.1340289160443;
	Thu, 21 Jun 2012 07:32:40 -0700 (PDT)
Received: from [192.168.0.40] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id c42sm103465309eeb.2.2012.06.21.07.32.36
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 07:32:38 -0700 (PDT)
Message-ID: <1340289150.4856.51.camel@Solace>
From: Dario Faggioli <raistlin.df@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 16:32:30 +0200
In-Reply-To: <1339570785.4705.9.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:
> > Ian J answered for the general commit case but in case you are
> > interested for the mq case you can put a comment at the top of the patch
> > (before the changelog) with the same form as what "hg export" gives you.
> > e.g.:
> >         # HG changeset patch
> >         # User Ian Campbell <ian.campbell@citrix.com>
> > 
So, I have this in place, as I did when sent v2. However, as I suppose
this is not doing its job, as I see this:

From: 	Dario Faggioli <raistlinxxx>
To: 	xen-develxxx
Cc: 	...
Subject: 	[PATCH 02 of 10 v2] libxl: add a new Array type to the IDL

Maybe I should remove the --plain option from my patchbomb line, so that
those comments make it to the list?

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 Thu Jun 21 14:35:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:35: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 1ShiTe-0004Jo-VB; Thu, 21 Jun 2012 14:35:18 +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 1ShiTd-0004Jh-7a
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:35:17 +0000
Received: from [85.158.138.51:60228] by server-2.bemta-3.messagelabs.com id
	B2/2F-10266-42133EF4; Thu, 21 Jun 2012 14:35:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340289315!28920428!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjk1NjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjk1NjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1321 invoked from network); 21 Jun 2012 14:35:15 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 14:35:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0ME1Y=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-020.pools.arcor-ip.net [88.65.85.20])
	by smtp.strato.de (jorabe mo32) (RZmta 29.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V079ebo5LEVV9N ;
	Thu, 21 Jun 2012 16:35:15 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 7C8C618637; Thu, 21 Jun 2012 16:35:14 +0200 (CEST)
Date: Thu, 21 Jun 2012 16:35:14 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621143514.GA4799@aepfle.de>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621085338.GA18516@aepfle.de>
	<1340270466.21872.33.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340270466.21872.33.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, Ian Campbell wrote:

> On Thu, 2012-06-21 at 09:53 +0100, Olaf Hering wrote:
> > On Thu, Jun 21, Ian Campbell wrote:
> > 
> > > On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > > > Currently shared libraries are automatically installed into /usr/lib
> > > > or /usr/lib64, depending on the supplied --prefix value and
> > > > $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> > > > do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> > > > 
> > > > With this change, packagers can supply the desired location for shared
> > > > libraries on the ./configure command line. Packagers need to note that
> > > > the default behaviour on 64-bit Linux systems will be to install shared
> > > > libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> > > > to ./configure.
> > 
> > Perhaps that should be stated in the README, which states to call just
> > configure without options.
> 
> I'd have assumed that it was well understood what options one
> could/should pass to configure? Anybody who's ever built anything on a
> system which uses lib64 must know it, right?

I think you are right, those who build from source will most likely know
that already. I'm building rpm packages so all this configure stuff is
kind of hidden from me.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:35:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:35: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 1ShiTe-0004Jo-VB; Thu, 21 Jun 2012 14:35:18 +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 1ShiTd-0004Jh-7a
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:35:17 +0000
Received: from [85.158.138.51:60228] by server-2.bemta-3.messagelabs.com id
	B2/2F-10266-42133EF4; Thu, 21 Jun 2012 14:35:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340289315!28920428!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjk1NjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjk1NjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1321 invoked from network); 21 Jun 2012 14:35:15 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 14:35:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0ME1Y=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-020.pools.arcor-ip.net [88.65.85.20])
	by smtp.strato.de (jorabe mo32) (RZmta 29.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V079ebo5LEVV9N ;
	Thu, 21 Jun 2012 16:35:15 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 7C8C618637; Thu, 21 Jun 2012 16:35:14 +0200 (CEST)
Date: Thu, 21 Jun 2012 16:35:14 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621143514.GA4799@aepfle.de>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621085338.GA18516@aepfle.de>
	<1340270466.21872.33.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340270466.21872.33.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, Ian Campbell wrote:

> On Thu, 2012-06-21 at 09:53 +0100, Olaf Hering wrote:
> > On Thu, Jun 21, Ian Campbell wrote:
> > 
> > > On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > > > Currently shared libraries are automatically installed into /usr/lib
> > > > or /usr/lib64, depending on the supplied --prefix value and
> > > > $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> > > > do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> > > > 
> > > > With this change, packagers can supply the desired location for shared
> > > > libraries on the ./configure command line. Packagers need to note that
> > > > the default behaviour on 64-bit Linux systems will be to install shared
> > > > libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> > > > to ./configure.
> > 
> > Perhaps that should be stated in the README, which states to call just
> > configure without options.
> 
> I'd have assumed that it was well understood what options one
> could/should pass to configure? Anybody who's ever built anything on a
> system which uses lib64 must know it, right?

I think you are right, those who build from source will most likely know
that already. I'm building rpm packages so all this configure stuff is
kind of hidden from me.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiU8-0004MH-Bt; Thu, 21 Jun 2012 14:35: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 1ShiU6-0004M0-MR
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:35:46 +0000
Received: from [85.158.143.35:3137] by server-1.bemta-4.messagelabs.com id
	D3/41-24392-14133EF4; Thu, 21 Jun 2012 14:35:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340289341!14924256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11717 invoked from network); 21 Jun 2012 14:35:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 14:35:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13150965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 14:35:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 15:35:40 +0100
Message-ID: <1340289339.26083.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin.df@gmail.com>
Date: Thu, 21 Jun 2012 15:35:39 +0100
In-Reply-To: <1340289150.4856.51.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace> <1340289150.4856.51.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 15:32 +0100, Dario Faggioli wrote:
> On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:
> > > Ian J answered for the general commit case but in case you are
> > > interested for the mq case you can put a comment at the top of the patch
> > > (before the changelog) with the same form as what "hg export" gives you.
> > > e.g.:
> > >         # HG changeset patch
> > >         # User Ian Campbell <ian.campbell@citrix.com>
> > > 
> So, I have this in place, as I did when sent v2. However, as I suppose
> this is not doing its job, as I see this:
> 
> From: 	Dario Faggioli <raistlinxxx>
> To: 	xen-develxxx
> Cc: 	...
> Subject: 	[PATCH 02 of 10 v2] libxl: add a new Array type to the IDL
> 
> Maybe I should remove the --plain option from my patchbomb line, so that
> those comments make it to the list?

That would work, I don't normally use --plain.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14: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 1ShiU8-0004MH-Bt; Thu, 21 Jun 2012 14:35: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 1ShiU6-0004M0-MR
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:35:46 +0000
Received: from [85.158.143.35:3137] by server-1.bemta-4.messagelabs.com id
	D3/41-24392-14133EF4; Thu, 21 Jun 2012 14:35:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340289341!14924256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11717 invoked from network); 21 Jun 2012 14:35:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 14:35:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="13150965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 14:35:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 15:35:40 +0100
Message-ID: <1340289339.26083.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin.df@gmail.com>
Date: Thu, 21 Jun 2012 15:35:39 +0100
In-Reply-To: <1340289150.4856.51.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace> <1340289150.4856.51.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 15:32 +0100, Dario Faggioli wrote:
> On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:
> > > Ian J answered for the general commit case but in case you are
> > > interested for the mq case you can put a comment at the top of the patch
> > > (before the changelog) with the same form as what "hg export" gives you.
> > > e.g.:
> > >         # HG changeset patch
> > >         # User Ian Campbell <ian.campbell@citrix.com>
> > > 
> So, I have this in place, as I did when sent v2. However, as I suppose
> this is not doing its job, as I see this:
> 
> From: 	Dario Faggioli <raistlinxxx>
> To: 	xen-develxxx
> Cc: 	...
> Subject: 	[PATCH 02 of 10 v2] libxl: add a new Array type to the IDL
> 
> Maybe I should remove the --plain option from my patchbomb line, so that
> those comments make it to the list?

That would work, I don't normally use --plain.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:36:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:36: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 1ShiUO-0004Ob-Te; Thu, 21 Jun 2012 14:36:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShiUM-0004OB-UI
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:36:03 +0000
Received: from [85.158.143.35:36732] by server-1.bemta-4.messagelabs.com id
	4F/B1-24392-25133EF4; Thu, 21 Jun 2012 14:36:02 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340289360!15648243!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13071 invoked from network); 21 Jun 2012 14:36:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 14:36:01 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79044208; Thu, 21 Jun 2012 16:36:00 +0200
Message-ID: <1340289354.4856.52.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 16:35:54 +0200
In-Reply-To: <1339570785.4705.9.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4318596750524020133=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4318596750524020133==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ubfy9hbn94vY3+vynMMt"


--=-ubfy9hbn94vY3+vynMMt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:
> > Ian J answered for the general commit case but in case you are
> > interested for the mq case you can put a comment at the top of the patc=
h
> > (before the changelog) with the same form as what "hg export" gives you=
.
> > e.g.:
> >         # HG changeset patch
> >         # User Ian Campbell <ian.campbell@citrix.com>
> >=20
So, I have this in place, as I did when sent v2. However, as I suppose
this is not doing its job, as I see this:

From: 	Dario Faggioli <raistlinxxx>
To: 	xen-develxxx
Cc: 	...
Subject: 	[PATCH 02 of 10 v2] libxl: add a new Array type to the IDL

Maybe I should remove the --plain option from my patchbomb line, so that
those comments make it to the list?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)




--=-ubfy9hbn94vY3+vynMMt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jMUoACgkQk4XaBE3IOsSqkwCeINarWNEmlNhkNn65ErDCf1Lk
nloAnAyf9PeYTS9VQy6aVjqr7/W2nNmX
=l9Vg
-----END PGP SIGNATURE-----

--=-ubfy9hbn94vY3+vynMMt--



--===============4318596750524020133==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4318596750524020133==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 14:36:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:36: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 1ShiUO-0004Ob-Te; Thu, 21 Jun 2012 14:36:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShiUM-0004OB-UI
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 14:36:03 +0000
Received: from [85.158.143.35:36732] by server-1.bemta-4.messagelabs.com id
	4F/B1-24392-25133EF4; Thu, 21 Jun 2012 14:36:02 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340289360!15648243!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13071 invoked from network); 21 Jun 2012 14:36:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 14:36:01 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79044208; Thu, 21 Jun 2012 16:36:00 +0200
Message-ID: <1340289354.4856.52.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 16:35:54 +0200
In-Reply-To: <1339570785.4705.9.camel@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20434.1587.672976.543703@mariner.uk.xensource.com>
	<1339168462.5003.15.camel@Solace>
	<1339491730.24104.6.camel@zakaz.uk.xensource.com>
	<1339570785.4705.9.camel@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4318596750524020133=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4318596750524020133==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ubfy9hbn94vY3+vynMMt"


--=-ubfy9hbn94vY3+vynMMt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-06-13 at 08:59 +0200, Dario Faggioli wrote:
> > Ian J answered for the general commit case but in case you are
> > interested for the mq case you can put a comment at the top of the patc=
h
> > (before the changelog) with the same form as what "hg export" gives you=
.
> > e.g.:
> >         # HG changeset patch
> >         # User Ian Campbell <ian.campbell@citrix.com>
> >=20
So, I have this in place, as I did when sent v2. However, as I suppose
this is not doing its job, as I see this:

From: 	Dario Faggioli <raistlinxxx>
To: 	xen-develxxx
Cc: 	...
Subject: 	[PATCH 02 of 10 v2] libxl: add a new Array type to the IDL

Maybe I should remove the --plain option from my patchbomb line, so that
those comments make it to the list?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)




--=-ubfy9hbn94vY3+vynMMt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jMUoACgkQk4XaBE3IOsSqkwCeINarWNEmlNhkNn65ErDCf1Lk
nloAnAyf9PeYTS9VQy6aVjqr7/W2nNmX
=l9Vg
-----END PGP SIGNATURE-----

--=-ubfy9hbn94vY3+vynMMt--



--===============4318596750524020133==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4318596750524020133==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 14:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shiao-0004pd-P1; Thu, 21 Jun 2012 14:42:42 +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 1Shian-0004pY-LG
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 14:42:41 +0000
Received: from [193.109.254.147:61866] by server-3.bemta-14.messagelabs.com id
	CA/39-08687-1E233EF4; Thu, 21 Jun 2012 14:42:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340289759!10902944!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwMTY1Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19708 invoked from network); 21 Jun 2012 14:42:40 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 14:42:40 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5LEgZFF020997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 14:42:36 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
	q5LEgYpe014934
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2012 14:42:35 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
	q5LEgYjh009087; Thu, 21 Jun 2012 09:42:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Jun 2012 07:42:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BE800402B8; Thu, 21 Jun 2012 10:34:58 -0400 (EDT)
Date: Thu, 21 Jun 2012 10:34:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Rolu <rolu@roce.org>
Message-ID: <20120621143458.GC23530@phenom.dumpdata.com>
References: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
	<CABs9Ej=TpBUyLaPB0FMmL+oZUeZtJTjTAb=gX3nOJY9p5k5yiw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CABs9Ej=TpBUyLaPB0FMmL+oZUeZtJTjTAb=gX3nOJY9p5k5yiw@mail.gmail.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, Paul S <pstroud@gmail.com>
Subject: Re: [Xen-devel] 4.2-Unstable Crash/Reboot(i5 2500/DQ67SW)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 21, 2012 at 01:25:24AM +0200, Rolu wrote:
> On Thu, Jun 21, 2012 at 12:16 AM, Paul S <pstroud@gmail.com> wrote:
> > Environment: Xen-4.2 Unstable - built about a week ago
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0OS: Fedora 17
> > =A0 =A0 =A0 =A0 =A0 =A0CPU: i5 2500
> > Motherboard: DQ67SW latest bios
> >
> > Trying to get passthrough working, 4.1.2 Bluescreens going into windows,
> > figured I probably needed some of the patches in 4.2, built it and it j=
ust
> > crashes and reboots. Installed a Serial card, got the terminal working =
and
> > was able to capture the crash. I have also included the dmidecode CPU a=
nd
> > BIOS from the normal Fedora 17 kernel(non-xen).
> >
> =

> The crash you get with 4.2 looks like the issue I had recently, see
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg00998.html
> =

> Add xsave=3D0 to the Xen kernel line in grub, or use a newer dom0 kernel.

Well, to be fair - he is using a new kernel. It is just that Fedora
adds a patch that half-way disables xsave.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 14:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 14:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shiao-0004pd-P1; Thu, 21 Jun 2012 14:42:42 +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 1Shian-0004pY-LG
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 14:42:41 +0000
Received: from [193.109.254.147:61866] by server-3.bemta-14.messagelabs.com id
	CA/39-08687-1E233EF4; Thu, 21 Jun 2012 14:42:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340289759!10902944!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwMTY1Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19708 invoked from network); 21 Jun 2012 14:42:40 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jun 2012 14:42:40 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5LEgZFF020997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Jun 2012 14:42:36 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
	q5LEgYpe014934
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2012 14:42:35 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
	q5LEgYjh009087; Thu, 21 Jun 2012 09:42:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Jun 2012 07:42:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BE800402B8; Thu, 21 Jun 2012 10:34:58 -0400 (EDT)
Date: Thu, 21 Jun 2012 10:34:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Rolu <rolu@roce.org>
Message-ID: <20120621143458.GC23530@phenom.dumpdata.com>
References: <CAEpZYZbU=dS=VHyCHQG+kh1BKWF=mRsKOqxQNtbZCbyvJruCXA@mail.gmail.com>
	<CABs9Ej=TpBUyLaPB0FMmL+oZUeZtJTjTAb=gX3nOJY9p5k5yiw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CABs9Ej=TpBUyLaPB0FMmL+oZUeZtJTjTAb=gX3nOJY9p5k5yiw@mail.gmail.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, Paul S <pstroud@gmail.com>
Subject: Re: [Xen-devel] 4.2-Unstable Crash/Reboot(i5 2500/DQ67SW)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 21, 2012 at 01:25:24AM +0200, Rolu wrote:
> On Thu, Jun 21, 2012 at 12:16 AM, Paul S <pstroud@gmail.com> wrote:
> > Environment: Xen-4.2 Unstable - built about a week ago
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0OS: Fedora 17
> > =A0 =A0 =A0 =A0 =A0 =A0CPU: i5 2500
> > Motherboard: DQ67SW latest bios
> >
> > Trying to get passthrough working, 4.1.2 Bluescreens going into windows,
> > figured I probably needed some of the patches in 4.2, built it and it j=
ust
> > crashes and reboots. Installed a Serial card, got the terminal working =
and
> > was able to capture the crash. I have also included the dmidecode CPU a=
nd
> > BIOS from the normal Fedora 17 kernel(non-xen).
> >
> =

> The crash you get with 4.2 looks like the issue I had recently, see
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg00998.html
> =

> Add xsave=3D0 to the Xen kernel line in grub, or use a newer dom0 kernel.

Well, to be fair - he is using a new kernel. It is just that Fedora
adds a patch that half-way disables xsave.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:05:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15:05: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 1Shiw6-00056R-Ol; Thu, 21 Jun 2012 15:04:42 +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 1Shiw4-00056M-TM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:04:41 +0000
Received: from [85.158.138.51:4342] by server-12.bemta-3.messagelabs.com id
	5C/17-30206-70833EF4; Thu, 21 Jun 2012 15:04:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340291079!19964829!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4969 invoked from network); 21 Jun 2012 15:04:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 15:04:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:04:38 +0100
Message-Id: <4FE35452020000780008B274@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:05:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE32D56.6000809@tycho.nsa.gov>
	<1340288444-6585-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1340288444-6585-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:20, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When using AMD's extension to access the extended PCI config space, only
> the low byte of the register number was being passed to XSM. Include the
> full value.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/arch/x86/traps.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 2264583..38ad9e7 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1691,6 +1691,7 @@ static int pci_cfg_ok(struct domain *d, int write, int 
> size)
>  
>      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
>      start = d->arch.pci_cf8 & 0xFF;
> +    start |= (d->arch.pci_cf8 >> 16) & 0xF00;

You should be doing this only if the functionality is actually
available (AMD only) and enabled (MSR bit). See Linux'es
pci_io_ecs_init() and Xen's handling of Dom0 writes to
MSR_AMD64_NB_CFG.

Jan

>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>          return 0;
> -- 
> 1.7.10.2




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:05:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15:05: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 1Shiw6-00056R-Ol; Thu, 21 Jun 2012 15:04:42 +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 1Shiw4-00056M-TM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:04:41 +0000
Received: from [85.158.138.51:4342] by server-12.bemta-3.messagelabs.com id
	5C/17-30206-70833EF4; Thu, 21 Jun 2012 15:04:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340291079!19964829!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4969 invoked from network); 21 Jun 2012 15:04:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 15:04:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:04:38 +0100
Message-Id: <4FE35452020000780008B274@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:05:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE32D56.6000809@tycho.nsa.gov>
	<1340288444-6585-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1340288444-6585-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:20, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When using AMD's extension to access the extended PCI config space, only
> the low byte of the register number was being passed to XSM. Include the
> full value.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/arch/x86/traps.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 2264583..38ad9e7 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1691,6 +1691,7 @@ static int pci_cfg_ok(struct domain *d, int write, int 
> size)
>  
>      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
>      start = d->arch.pci_cf8 & 0xFF;
> +    start |= (d->arch.pci_cf8 >> 16) & 0xF00;

You should be doing this only if the functionality is actually
available (AMD only) and enabled (MSR bit). See Linux'es
pci_io_ecs_init() and Xen's handling of Dom0 writes to
MSR_AMD64_NB_CFG.

Jan

>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>          return 0;
> -- 
> 1.7.10.2




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:12:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15: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 1Shj3W-0005Gn-Mo; Thu, 21 Jun 2012 15:12:22 +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 1Shj3U-0005Gh-SE
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:12:20 +0000
Received: from [193.109.254.147:38714] by server-6.bemta-14.messagelabs.com id
	F7/DA-08993-4D933EF4; Thu, 21 Jun 2012 15:12:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340291537!10865846!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19231 invoked from network); 21 Jun 2012 15:12:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 15:12:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:12:17 +0100
Message-Id: <4FE3561C020000780008B280@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:13:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
	<4FE32D56.6000809@tycho.nsa.gov>
In-Reply-To: <4FE32D56.6000809@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

>>> On 21.06.12 at 16:19, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 06/21/2012 09:20 AM, Jan Beulich wrote:
>> The mmconfig part of this is seriously broken: These operations,
>> even when carried out by Dom0, are MMIO accesses, and hence
>> are invisible to the hypervisor without extra handling. Putting
>> the checks into pci_mmcfg_{read,write}() has the effect of
>> potentially denying the _hypervisor_ access. So I think at least
>> that part needs to be reverted.
> 
> I agree - the XSM checks are intended to be done only when the hypervisor
> is accessing on behalf of the domain, which looks to be covered by the
> traps part of the patch. These checks are currently intended to deny a
> domain with IS_PRIV but without full hardware access - in particular,
> without access to the PCI configuration MMIO area - from using legacy 
> register access to reconfigure PCI devices.
> 
> While it may be useful to extend this access check to include the PCI 
> configuration MMIO pages, this would require emulating both reads and
> writes to any page that has entries that a particular domain does not
> have access to. The existing pciback/pcifront configuration access model
> already handles these issues without changes to the hypervisor.

So do I read correctly that you agree to revert that part of said
c/s?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:12:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15: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 1Shj3W-0005Gn-Mo; Thu, 21 Jun 2012 15:12:22 +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 1Shj3U-0005Gh-SE
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:12:20 +0000
Received: from [193.109.254.147:38714] by server-6.bemta-14.messagelabs.com id
	F7/DA-08993-4D933EF4; Thu, 21 Jun 2012 15:12:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340291537!10865846!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19231 invoked from network); 21 Jun 2012 15:12:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 15:12:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:12:17 +0100
Message-Id: <4FE3561C020000780008B280@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:13:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
	<4FE32D56.6000809@tycho.nsa.gov>
In-Reply-To: <4FE32D56.6000809@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

>>> On 21.06.12 at 16:19, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 06/21/2012 09:20 AM, Jan Beulich wrote:
>> The mmconfig part of this is seriously broken: These operations,
>> even when carried out by Dom0, are MMIO accesses, and hence
>> are invisible to the hypervisor without extra handling. Putting
>> the checks into pci_mmcfg_{read,write}() has the effect of
>> potentially denying the _hypervisor_ access. So I think at least
>> that part needs to be reverted.
> 
> I agree - the XSM checks are intended to be done only when the hypervisor
> is accessing on behalf of the domain, which looks to be covered by the
> traps part of the patch. These checks are currently intended to deny a
> domain with IS_PRIV but without full hardware access - in particular,
> without access to the PCI configuration MMIO area - from using legacy 
> register access to reconfigure PCI devices.
> 
> While it may be useful to extend this access check to include the PCI 
> configuration MMIO pages, this would require emulating both reads and
> writes to any page that has entries that a particular domain does not
> have access to. The existing pciback/pcifront configuration access model
> already handles these issues without changes to the hypervisor.

So do I read correctly that you agree to revert that part of said
c/s?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1Shj5I-0005LS-6L; Thu, 21 Jun 2012 15:14:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Shj5G-0005LK-IE
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:14:10 +0000
Received: from [85.158.143.99:50262] by server-2.bemta-4.messagelabs.com id
	40/53-17938-14A33EF4; Thu, 21 Jun 2012 15:14:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340291648!23155193!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 21 Jun 2012 15:14:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 15:14:09 -0000
X-TM-IMSS-Message-ID: <8e4a13e9000030fe@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8e4a13e9000030fe ; Thu, 21 Jun 2012 11:14:52 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LFE3Zs004789; 
	Thu, 21 Jun 2012 11:14:03 -0400
Message-ID: <4FE33A3B.2090108@tycho.nsa.gov>
Date: Thu, 21 Jun 2012 11:14:03 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
	<4FE32D56.6000809@tycho.nsa.gov>
	<4FE3561C020000780008B280@nat28.tlf.novell.com>
In-Reply-To: <4FE3561C020000780008B280@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

On 06/21/2012 11:13 AM, Jan Beulich wrote:
>>>> On 21.06.12 at 16:19, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 06/21/2012 09:20 AM, Jan Beulich wrote:
>>> The mmconfig part of this is seriously broken: These operations,
>>> even when carried out by Dom0, are MMIO accesses, and hence
>>> are invisible to the hypervisor without extra handling. Putting
>>> the checks into pci_mmcfg_{read,write}() has the effect of
>>> potentially denying the _hypervisor_ access. So I think at least
>>> that part needs to be reverted.
>>
>> I agree - the XSM checks are intended to be done only when the hypervisor
>> is accessing on behalf of the domain, which looks to be covered by the
>> traps part of the patch. These checks are currently intended to deny a
>> domain with IS_PRIV but without full hardware access - in particular,
>> without access to the PCI configuration MMIO area - from using legacy 
>> register access to reconfigure PCI devices.
>>
>> While it may be useful to extend this access check to include the PCI 
>> configuration MMIO pages, this would require emulating both reads and
>> writes to any page that has entries that a particular domain does not
>> have access to. The existing pciback/pcifront configuration access model
>> already handles these issues without changes to the hypervisor.
> 
> So do I read correctly that you agree to revert that part of said
> c/s?
> 
> Jan
> 

Yes.

-- 
Daniel De Graaf
National Security Agency



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1Shj5I-0005LS-6L; Thu, 21 Jun 2012 15:14:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Shj5G-0005LK-IE
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:14:10 +0000
Received: from [85.158.143.99:50262] by server-2.bemta-4.messagelabs.com id
	40/53-17938-14A33EF4; Thu, 21 Jun 2012 15:14:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340291648!23155193!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13924 invoked from network); 21 Jun 2012 15:14:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-216.messagelabs.com with SMTP;
	21 Jun 2012 15:14:09 -0000
X-TM-IMSS-Message-ID: <8e4a13e9000030fe@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8e4a13e9000030fe ; Thu, 21 Jun 2012 11:14:52 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LFE3Zs004789; 
	Thu, 21 Jun 2012 11:14:03 -0400
Message-ID: <4FE33A3B.2090108@tycho.nsa.gov>
Date: Thu, 21 Jun 2012 11:14:03 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE33BD2020000780008B1B9@nat28.tlf.novell.com>
	<4FE32D56.6000809@tycho.nsa.gov>
	<4FE3561C020000780008B280@nat28.tlf.novell.com>
In-Reply-To: <4FE3561C020000780008B280@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] c/s 24425:053a44894279 (xsm: add checks on PCI
 configuration 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

On 06/21/2012 11:13 AM, Jan Beulich wrote:
>>>> On 21.06.12 at 16:19, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 06/21/2012 09:20 AM, Jan Beulich wrote:
>>> The mmconfig part of this is seriously broken: These operations,
>>> even when carried out by Dom0, are MMIO accesses, and hence
>>> are invisible to the hypervisor without extra handling. Putting
>>> the checks into pci_mmcfg_{read,write}() has the effect of
>>> potentially denying the _hypervisor_ access. So I think at least
>>> that part needs to be reverted.
>>
>> I agree - the XSM checks are intended to be done only when the hypervisor
>> is accessing on behalf of the domain, which looks to be covered by the
>> traps part of the patch. These checks are currently intended to deny a
>> domain with IS_PRIV but without full hardware access - in particular,
>> without access to the PCI configuration MMIO area - from using legacy 
>> register access to reconfigure PCI devices.
>>
>> While it may be useful to extend this access check to include the PCI 
>> configuration MMIO pages, this would require emulating both reads and
>> writes to any page that has entries that a particular domain does not
>> have access to. The existing pciback/pcifront configuration access model
>> already handles these issues without changes to the hypervisor.
> 
> So do I read correctly that you agree to revert that part of said
> c/s?
> 
> Jan
> 

Yes.

-- 
Daniel De Graaf
National Security Agency



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:29:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15:29: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 1ShjJO-0005hZ-OQ; Thu, 21 Jun 2012 15:28: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 1ShjJN-0005hT-Dy
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:28:45 +0000
Received: from [85.158.139.83:34939] by server-4.bemta-5.messagelabs.com id
	06/2A-27831-CAD33EF4; Thu, 21 Jun 2012 15:28:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340292523!28860789!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12592 invoked from network); 21 Jun 2012 15:28:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 15:28:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:28:43 +0100
Message-Id: <4FE359F6020000780008B299@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:29:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3F119EC6.0__="
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH] x86-64: revert mmconfig part of c/s
	24425:053a44894279
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part3F119EC6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

These additions did not fulfill their purpose - they checked hypervisor
config space accesses instead of guest (Dom0) ones.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -14,7 +14,6 @@
 #include <xen/xmalloc.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
-#include <xsm/xsm.h>
=20
 #include "mmconfig.h"
=20
@@ -59,7 +58,6 @@ int pci_mmcfg_read(unsigned int seg, uns
               unsigned int devfn, int reg, int len, u32 *value)
 {
     char __iomem *addr;
-    uint32_t mbdf;
=20
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK =
*/
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
@@ -67,12 +65,6 @@ err:        *value =3D -1;
         return -EINVAL;
     }
=20
-    mbdf =3D (seg << 16) | (bus << 8) | devfn;
-    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - =
1, 0)) {
-        *value =3D -1;
-        return -EPERM;
-    }
-
     addr =3D pci_dev_base(seg, bus, devfn);
     if (!addr)
         goto err;
@@ -96,16 +88,11 @@ int pci_mmcfg_write(unsigned int seg, un
                unsigned int devfn, int reg, int len, u32 value)
 {
     char __iomem *addr;
-    uint32_t mbdf;
=20
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK =
*/
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
         return -EINVAL;
=20
-    mbdf =3D (seg << 16) | (bus << 8) | devfn;
-    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - =
1, 1))
-        return -EPERM;
-
     addr =3D pci_dev_base(seg, bus, devfn);
     if (!addr)
         return -EINVAL;




--=__Part3F119EC6.0__=
Content-Type: text/plain; name="x86_64-mmcfg-revert-24425.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-mmcfg-revert-24425.patch"

x86-64: revert mmconfig part of c/s 24425:053a44894279=0A=0AThese =
additions did not fulfill their purpose - they checked hypervisor=0Aconfig =
space accesses instead of guest (Dom0) ones.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/x86_64/mmconfig_64.c=0A=
+++ b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ -14,7 +14,6 @@=0A #include =
<xen/xmalloc.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=0A-#in=
clude <xsm/xsm.h>=0A =0A #include "mmconfig.h"=0A =0A@@ -59,7 +58,6 @@ int =
pci_mmcfg_read(unsigned int seg, uns=0A               unsigned int devfn, =
int reg, int len, u32 *value)=0A {=0A     char __iomem *addr;=0A-    =
uint32_t mbdf;=0A =0A     /* Why do we have this when nobody checks it. =
How about a BUG()!? -AK */=0A     if (unlikely((bus > 255) || (devfn > =
255) || (reg > 4095))) {=0A@@ -67,12 +65,6 @@ err:        *value =3D =
-1;=0A         return -EINVAL;=0A     }=0A =0A-    mbdf =3D (seg << 16) | =
(bus << 8) | devfn;=0A-    if (xsm_pci_config_permission(current->domain, =
mbdf, reg, reg + len - 1, 0)) {=0A-        *value =3D -1;=0A-        =
return -EPERM;=0A-    }=0A-=0A     addr =3D pci_dev_base(seg, bus, =
devfn);=0A     if (!addr)=0A         goto err;=0A@@ -96,16 +88,11 @@ int =
pci_mmcfg_write(unsigned int seg, un=0A                unsigned int devfn, =
int reg, int len, u32 value)=0A {=0A     char __iomem *addr;=0A-    =
uint32_t mbdf;=0A =0A     /* Why do we have this when nobody checks it. =
How about a BUG()!? -AK */=0A     if (unlikely((bus > 255) || (devfn > =
255) || (reg > 4095)))=0A         return -EINVAL;=0A =0A-    mbdf =3D (seg =
<< 16) | (bus << 8) | devfn;=0A-    if (xsm_pci_config_permission(current->=
domain, mbdf, reg, reg + len - 1, 1))=0A-        return -EPERM;=0A-=0A     =
addr =3D pci_dev_base(seg, bus, devfn);=0A     if (!addr)=0A         =
return -EINVAL;=0A
--=__Part3F119EC6.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

--=__Part3F119EC6.0__=--


From xen-devel-bounces@lists.xen.org Thu Jun 21 15:29:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15:29: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 1ShjJO-0005hZ-OQ; Thu, 21 Jun 2012 15:28: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 1ShjJN-0005hT-Dy
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 15:28:45 +0000
Received: from [85.158.139.83:34939] by server-4.bemta-5.messagelabs.com id
	06/2A-27831-CAD33EF4; Thu, 21 Jun 2012 15:28:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340292523!28860789!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12592 invoked from network); 21 Jun 2012 15:28:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 15:28:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:28:43 +0100
Message-Id: <4FE359F6020000780008B299@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:29:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3F119EC6.0__="
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH] x86-64: revert mmconfig part of c/s
	24425:053a44894279
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part3F119EC6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

These additions did not fulfill their purpose - they checked hypervisor
config space accesses instead of guest (Dom0) ones.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -14,7 +14,6 @@
 #include <xen/xmalloc.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
-#include <xsm/xsm.h>
=20
 #include "mmconfig.h"
=20
@@ -59,7 +58,6 @@ int pci_mmcfg_read(unsigned int seg, uns
               unsigned int devfn, int reg, int len, u32 *value)
 {
     char __iomem *addr;
-    uint32_t mbdf;
=20
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK =
*/
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
@@ -67,12 +65,6 @@ err:        *value =3D -1;
         return -EINVAL;
     }
=20
-    mbdf =3D (seg << 16) | (bus << 8) | devfn;
-    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - =
1, 0)) {
-        *value =3D -1;
-        return -EPERM;
-    }
-
     addr =3D pci_dev_base(seg, bus, devfn);
     if (!addr)
         goto err;
@@ -96,16 +88,11 @@ int pci_mmcfg_write(unsigned int seg, un
                unsigned int devfn, int reg, int len, u32 value)
 {
     char __iomem *addr;
-    uint32_t mbdf;
=20
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK =
*/
     if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
         return -EINVAL;
=20
-    mbdf =3D (seg << 16) | (bus << 8) | devfn;
-    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - =
1, 1))
-        return -EPERM;
-
     addr =3D pci_dev_base(seg, bus, devfn);
     if (!addr)
         return -EINVAL;




--=__Part3F119EC6.0__=
Content-Type: text/plain; name="x86_64-mmcfg-revert-24425.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-mmcfg-revert-24425.patch"

x86-64: revert mmconfig part of c/s 24425:053a44894279=0A=0AThese =
additions did not fulfill their purpose - they checked hypervisor=0Aconfig =
space accesses instead of guest (Dom0) ones.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/x86_64/mmconfig_64.c=0A=
+++ b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ -14,7 +14,6 @@=0A #include =
<xen/xmalloc.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=0A-#in=
clude <xsm/xsm.h>=0A =0A #include "mmconfig.h"=0A =0A@@ -59,7 +58,6 @@ int =
pci_mmcfg_read(unsigned int seg, uns=0A               unsigned int devfn, =
int reg, int len, u32 *value)=0A {=0A     char __iomem *addr;=0A-    =
uint32_t mbdf;=0A =0A     /* Why do we have this when nobody checks it. =
How about a BUG()!? -AK */=0A     if (unlikely((bus > 255) || (devfn > =
255) || (reg > 4095))) {=0A@@ -67,12 +65,6 @@ err:        *value =3D =
-1;=0A         return -EINVAL;=0A     }=0A =0A-    mbdf =3D (seg << 16) | =
(bus << 8) | devfn;=0A-    if (xsm_pci_config_permission(current->domain, =
mbdf, reg, reg + len - 1, 0)) {=0A-        *value =3D -1;=0A-        =
return -EPERM;=0A-    }=0A-=0A     addr =3D pci_dev_base(seg, bus, =
devfn);=0A     if (!addr)=0A         goto err;=0A@@ -96,16 +88,11 @@ int =
pci_mmcfg_write(unsigned int seg, un=0A                unsigned int devfn, =
int reg, int len, u32 value)=0A {=0A     char __iomem *addr;=0A-    =
uint32_t mbdf;=0A =0A     /* Why do we have this when nobody checks it. =
How about a BUG()!? -AK */=0A     if (unlikely((bus > 255) || (devfn > =
255) || (reg > 4095)))=0A         return -EINVAL;=0A =0A-    mbdf =3D (seg =
<< 16) | (bus << 8) | devfn;=0A-    if (xsm_pci_config_permission(current->=
domain, mbdf, reg, reg + len - 1, 1))=0A-        return -EPERM;=0A-=0A     =
addr =3D pci_dev_base(seg, bus, devfn);=0A     if (!addr)=0A         =
return -EINVAL;=0A
--=__Part3F119EC6.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

--=__Part3F119EC6.0__=--


From xen-devel-bounces@lists.xen.org Thu Jun 21 15:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15: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 1ShjLx-0005nI-A4; Thu, 21 Jun 2012 15:31:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShjLv-0005nA-Gx
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 15:31:23 +0000
Received: from [193.109.254.147:36380] by server-9.bemta-14.messagelabs.com id
	3B/F3-07693-A4E33EF4; Thu, 21 Jun 2012 15:31:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340292664!8521636!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21786 invoked from network); 21 Jun 2012 15:31:05 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.141)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 15:31:05 -0000
Received: from mail38-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 15:29:36 +0000
Received: from mail38-db3 (localhost [127.0.0.1])	by mail38-db3-R.bigfish.com
	(Postfix) with ESMTP id B1B7320456;
	Thu, 21 Jun 2012 15:29:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzbb2dI98dI9371I1432I4015I8b9clzz1202hzzz2dh668h839hd25he5bhf0ah)
Received: from mail38-db3 (localhost.localdomain [127.0.0.1]) by mail38-db3
	(MessageSwitch) id 1340292574816159_22273;
	Thu, 21 Jun 2012 15:29:34 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.243])	by
	mail38-db3.bigfish.com (Postfix) with ESMTP id BAB584E004A;
	Thu, 21 Jun 2012 15:29:34 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 15:29:33 +0000
X-WSS-ID: 0M5Z4FL-01-A11-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26DEE10280D9;	Thu, 21 Jun 2012 10:30:57 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 10:31:13 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 21 Jun 2012 10:30:57 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	11:30:55 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3C73F49C69D; Thu, 21 Jun 2012
	16:30:54 +0100 (BST)
Message-ID: <4FE33DBC.4030104@amd.com>
Date: Thu, 21 Jun 2012 17:29:00 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FE20C49020000780008AE25@nat28.tlf.novell.com>
In-Reply-To: <4FE20C49020000780008AE25@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled 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 06/20/2012 05:45 PM, Jan Beulich wrote:
  > Rather than submitting it for inclusion immediately, I'd rather see
> you first use it successfully. Below/attached what appears to
> work fine for me in contrived situations (i.e. hiding bridges with
> nothing connected, as I still don't have any AMD IOMMU system
> at hand).

Hi Jan,

The patch works for me. IOMMU msi Capability is shown as enabled with 
this patch.
Thanks,
Wei

00:00.2 Generic system peripheral [0806]: Advanced Micro Devices [AMD] 
Device 1419
         Subsystem: Advanced Micro Devices [AMD] Device 1419
         Flags: bus master, fast devsel, latency 0, IRQ 11
         Capabilities: [40] Secure device <?>
         Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
         Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+


> Jan
>
> Note that due to ptwr_do_page_fault() being run first, there'll be a
> MEM_LOG() issued for each such attempt. If that's undesirable, the
> order of the calls would need to be swapped.
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>               break;
>           case 1:
>               l1e_remove_flags(nl1e, _PAGE_RW);
> +            rc = 0;
>               break;
>           }
>           if ( page )
> @@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>       return 0;
>   }
>
> +#ifdef __x86_64__
> +/*************************
> + * fault handling for read-only MMIO pages
> + */
> +
> +struct mmio_ro_emulate_ctxt {
> +    struct x86_emulate_ctxt ctxt;
> +    unsigned long cr2;
> +};
> +
> +static int mmio_ro_emulated_read(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    return X86EMUL_UNHANDLEABLE;
> +}
> +
> +static int mmio_ro_emulated_write(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
> +
> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
> +    if ( ((bytes | offset)&  (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
> +    {
> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx, bytes=%u)",
> +                mmio_ro_ctxt->cr2, offset, bytes);
> +        return X86EMUL_UNHANDLEABLE;
> +    }
> +
> +    return X86EMUL_OKAY;
> +}
> +
> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
> +    .read       = mmio_ro_emulated_read,
> +    .insn_fetch = ptwr_emulated_read,
> +    .write      = mmio_ro_emulated_write,
> +};
> +
> +/* Check if guest is trying to modify a r/o MMIO page. */
> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
> +                          struct cpu_user_regs *regs)
> +{
> +    l1_pgentry_t      pte;
> +    unsigned long     mfn;
> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
> +                                  32 : BITS_PER_LONG;
> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
> +        .ctxt.regs = regs,
> +        .ctxt.addr_size = addr_size,
> +        .ctxt.sp_size = addr_size,
> +        .cr2 = addr
> +    };
> +    int rc;
> +
> +    /* Attempt to read the PTE that maps the VA being accessed. */
> +    guest_get_eff_l1e(v, addr,&pte);
> +
> +    /* We are looking only for read-only mappings of MMIO pages. */
> +    if ( ((l1e_get_flags(pte)&  (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) )
> +        return 0;
> +
> +    mfn = l1e_get_pfn(pte);
> +    if ( mfn_valid(mfn) )
> +    {
> +        struct page_info *page = mfn_to_page(mfn);
> +        struct domain *owner = page_get_owner_and_reference(page);
> +
> +        if ( owner )
> +            put_page(page);
> +        if ( owner != dom_io )
> +            return 0;
> +    }
> +
> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
> +        return 0;
> +
> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt,&mmio_ro_emulate_ops);
> +
> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
> +}
> +#endif /* __x86_64__ */
> +
>   void free_xen_pagetable(void *v)
>   {
>       if ( system_state == SYS_STATE_early_boot )
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>           return 0;
>       }
>
> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
> -         guest_kernel_mode(v, regs) )
> -    {
> -        unsigned int mbs = PFEC_write_access;
> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
> -
> -        /* Do not check if access-protection fault since the page may
> -           legitimately be not present in shadow page tables */
> -        if ( !paging_mode_enabled(d) )
> -            mbs |= PFEC_page_present;
> -
> -        if ( ((regs->error_code&  (mbs | mbz)) == mbs)&&
> +    if ( guest_kernel_mode(v, regs)&&
> +         !(regs->error_code&  (PFEC_reserved_bit | PFEC_insn_fetch))&&
> +         (regs->error_code&  PFEC_write_access) )
> +    {
> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
> +             /* Do not check if access-protection fault since the page may
> +                legitimately be not present in shadow page tables */
> +             (paging_mode_enabled(d) ||
> +              (regs->error_code&  PFEC_page_present))&&
>                ptwr_do_page_fault(v, addr, regs) )
>               return EXCRET_fault_fixed;
> +
> +#ifdef __x86_64__
> +        if ( IS_PRIV(d)&&  (regs->error_code&  PFEC_page_present)&&
> +             mmio_ro_do_page_fault(v, addr, regs) )
> +            return EXCRET_fault_fixed;
> +#endif
>       }
>
>       /* For non-external shadowed guests, we fix up both their own
> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>           return 0;
>
>       machine_bdf = (d->arch.pci_cf8>>  8)&  0xFFFF;
> +    if ( write )
> +    {
> +        const unsigned long *ro_map = pci_get_ro_map(0);
> +
> +        if ( ro_map&&  test_bit(machine_bdf, ro_map) )
> +            return 0;
> +    }
>       start = d->arch.pci_cf8&  0xFF;
>       end = start + size - 1;
>       if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
> --- a/xen/arch/x86/x86_32/pci.c
> +++ b/xen/arch/x86/x86_32/pci.c
> @@ -6,6 +6,7 @@
>
>   #include<xen/spinlock.h>
>   #include<xen/pci.h>
> +#include<xen/init.h>
>   #include<asm/io.h>
>
>   #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
> @@ -70,3 +71,7 @@ void pci_conf_write32(
>       BUG_ON((bus>  255) || (dev>  31) || (func>  7) || (reg>  255));
>       pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>   }
> +
> +void __init arch_pci_ro_device(int seg, int bdf)
> +{
> +}
> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> @@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const
>       return (void __iomem *) virt;
>   }
>
> +void arch_pci_ro_device(int seg, int bdf)
> +{
> +    unsigned int idx, bus = PCI_BUS(bdf);
> +
> +    for (idx = 0; idx<  pci_mmcfg_config_num; ++idx) {
> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
> +        unsigned long mfn = (cfg->address>>  PAGE_SHIFT) + bdf;
> +
> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
> +            cfg->start_bus_number>  bus || cfg->end_bus_number<  bus)
> +            continue;
> +
> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
> +            printk(XENLOG_ERR
> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) read-only\n",
> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
> +                   mfn);
> +    }
> +}
> +
>   int pci_mmcfg_arch_enable(unsigned int idx)
>   {
>       const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>
>       if (pci_mmcfg_virt[idx].virt)
>           return 0;
> @@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>       }
>       printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>              cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
> +    if (ro_map) {
> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
> +
> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf))<= end) {
> +            arch_pci_ro_device(cfg->pci_segment, bdf);
> +            if (bdf++ == end)
> +                break;
> +        }
> +    }
>       return 0;
>   }
>
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>       if ( rt )
>           return -ENODEV;
>
> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
> +    if ( rt )
> +        printk(XENLOG_ERR
> +               "Could not mark config space of %04x:%02x:%02x.%u read-only (%d)\n",
> +               iommu->seg, bus, dev, func, rt);
> +
>       list_add_tail(&iommu->list,&amd_iommu_head);
>
>       return 0;
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>   unlock:
>       spin_unlock(&d->event_lock);
>   }
> -
> -static int __init setup_mmio_ro_ranges(void)
> -{
> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> -                                  RANGESETF_prettyprint_hex);
> -    return 0;
> -}
> -__initcall(setup_mmio_ro_ranges);
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -36,6 +36,7 @@
>   struct pci_seg {
>       struct list_head alldevs_list;
>       u16 nr;
> +    unsigned long *ro_map;
>       /* bus2bridge_lock protects bus2bridge array */
>       spinlock_t bus2bridge_lock;
>   #define MAX_BUSES 256
> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>       radix_tree_init(&pci_segments);
>       if ( !alloc_pseg(0) )
>           panic("Could not initialize PCI segment 0\n");
> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> +                                  RANGESETF_prettyprint_hex);
>   }
>
>   int __init pci_add_segment(u16 seg)
> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>       return alloc_pseg(seg) ? 0 : -ENOMEM;
>   }
>
> +const unsigned long *pci_get_ro_map(u16 seg)
> +{
> +    struct pci_seg *pseg = get_pseg(seg);
> +
> +    return pseg ? pseg->ro_map : NULL;
> +}
> +
>   static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>   {
>       struct pci_dev *pdev;
> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>       xfree(pdev);
>   }
>
> +int __init pci_ro_device(int seg, int bus, int devfn)
> +{
> +    struct pci_seg *pseg = alloc_pseg(seg);
> +    struct pci_dev *pdev;
> +
> +    if ( !pseg )
> +        return -ENOMEM;
> +    pdev = alloc_pdev(pseg, bus, devfn);
> +    if ( !pdev )
> +        return -ENOMEM;
> +
> +    if ( !pseg->ro_map )
> +    {
> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
> +
> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
> +        if ( !pseg->ro_map )
> +            return -ENOMEM;
> +        memset(pseg->ro_map, 0, sz);
> +    }
> +
> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
> +
> +    return 0;
> +}
> +
>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>   {
>       struct pci_seg *pseg = get_pseg(seg);
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>
>   int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>                           struct cpu_user_regs *);
> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
> +                           struct cpu_user_regs *);
>
>   int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>   void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>   void pci_release_devices(struct domain *d);
>   int pci_add_segment(u16 seg);
> +const unsigned long *pci_get_ro_map(u16 seg);
>   int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
>   int pci_remove_device(u16 seg, u8 bus, u8 devfn);
> +int pci_ro_device(int seg, int bus, int devfn);
> +void arch_pci_ro_device(int seg, int bdf);
>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>   struct pci_dev *pci_get_pdev_by_domain(
>       struct domain *, int seg, int bus, int devfn);
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15: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 1ShjLx-0005nI-A4; Thu, 21 Jun 2012 15:31:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1ShjLv-0005nA-Gx
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 15:31:23 +0000
Received: from [193.109.254.147:36380] by server-9.bemta-14.messagelabs.com id
	3B/F3-07693-A4E33EF4; Thu, 21 Jun 2012 15:31:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340292664!8521636!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21786 invoked from network); 21 Jun 2012 15:31:05 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.141)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 15:31:05 -0000
Received: from mail38-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 15:29:36 +0000
Received: from mail38-db3 (localhost [127.0.0.1])	by mail38-db3-R.bigfish.com
	(Postfix) with ESMTP id B1B7320456;
	Thu, 21 Jun 2012 15:29:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzbb2dI98dI9371I1432I4015I8b9clzz1202hzzz2dh668h839hd25he5bhf0ah)
Received: from mail38-db3 (localhost.localdomain [127.0.0.1]) by mail38-db3
	(MessageSwitch) id 1340292574816159_22273;
	Thu, 21 Jun 2012 15:29:34 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.243])	by
	mail38-db3.bigfish.com (Postfix) with ESMTP id BAB584E004A;
	Thu, 21 Jun 2012 15:29:34 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 15:29:33 +0000
X-WSS-ID: 0M5Z4FL-01-A11-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26DEE10280D9;	Thu, 21 Jun 2012 10:30:57 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 21 Jun 2012 10:31:13 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 21 Jun 2012 10:30:57 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 21 Jun 2012
	11:30:55 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 3C73F49C69D; Thu, 21 Jun 2012
	16:30:54 +0100 (BST)
Message-ID: <4FE33DBC.4030104@amd.com>
Date: Thu, 21 Jun 2012 17:29:00 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FE20C49020000780008AE25@nat28.tlf.novell.com>
In-Reply-To: <4FE20C49020000780008AE25@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled 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 06/20/2012 05:45 PM, Jan Beulich wrote:
  > Rather than submitting it for inclusion immediately, I'd rather see
> you first use it successfully. Below/attached what appears to
> work fine for me in contrived situations (i.e. hiding bridges with
> nothing connected, as I still don't have any AMD IOMMU system
> at hand).

Hi Jan,

The patch works for me. IOMMU msi Capability is shown as enabled with 
this patch.
Thanks,
Wei

00:00.2 Generic system peripheral [0806]: Advanced Micro Devices [AMD] 
Device 1419
         Subsystem: Advanced Micro Devices [AMD] Device 1419
         Flags: bus master, fast devsel, latency 0, IRQ 11
         Capabilities: [40] Secure device <?>
         Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
         Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+


> Jan
>
> Note that due to ptwr_do_page_fault() being run first, there'll be a
> MEM_LOG() issued for each such attempt. If that's undesirable, the
> order of the calls would need to be swapped.
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>               break;
>           case 1:
>               l1e_remove_flags(nl1e, _PAGE_RW);
> +            rc = 0;
>               break;
>           }
>           if ( page )
> @@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>       return 0;
>   }
>
> +#ifdef __x86_64__
> +/*************************
> + * fault handling for read-only MMIO pages
> + */
> +
> +struct mmio_ro_emulate_ctxt {
> +    struct x86_emulate_ctxt ctxt;
> +    unsigned long cr2;
> +};
> +
> +static int mmio_ro_emulated_read(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    return X86EMUL_UNHANDLEABLE;
> +}
> +
> +static int mmio_ro_emulated_write(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
> +
> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
> +    if ( ((bytes | offset)&  (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
> +    {
> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx, bytes=%u)",
> +                mmio_ro_ctxt->cr2, offset, bytes);
> +        return X86EMUL_UNHANDLEABLE;
> +    }
> +
> +    return X86EMUL_OKAY;
> +}
> +
> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
> +    .read       = mmio_ro_emulated_read,
> +    .insn_fetch = ptwr_emulated_read,
> +    .write      = mmio_ro_emulated_write,
> +};
> +
> +/* Check if guest is trying to modify a r/o MMIO page. */
> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
> +                          struct cpu_user_regs *regs)
> +{
> +    l1_pgentry_t      pte;
> +    unsigned long     mfn;
> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
> +                                  32 : BITS_PER_LONG;
> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
> +        .ctxt.regs = regs,
> +        .ctxt.addr_size = addr_size,
> +        .ctxt.sp_size = addr_size,
> +        .cr2 = addr
> +    };
> +    int rc;
> +
> +    /* Attempt to read the PTE that maps the VA being accessed. */
> +    guest_get_eff_l1e(v, addr,&pte);
> +
> +    /* We are looking only for read-only mappings of MMIO pages. */
> +    if ( ((l1e_get_flags(pte)&  (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) )
> +        return 0;
> +
> +    mfn = l1e_get_pfn(pte);
> +    if ( mfn_valid(mfn) )
> +    {
> +        struct page_info *page = mfn_to_page(mfn);
> +        struct domain *owner = page_get_owner_and_reference(page);
> +
> +        if ( owner )
> +            put_page(page);
> +        if ( owner != dom_io )
> +            return 0;
> +    }
> +
> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
> +        return 0;
> +
> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt,&mmio_ro_emulate_ops);
> +
> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
> +}
> +#endif /* __x86_64__ */
> +
>   void free_xen_pagetable(void *v)
>   {
>       if ( system_state == SYS_STATE_early_boot )
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>           return 0;
>       }
>
> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
> -         guest_kernel_mode(v, regs) )
> -    {
> -        unsigned int mbs = PFEC_write_access;
> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
> -
> -        /* Do not check if access-protection fault since the page may
> -           legitimately be not present in shadow page tables */
> -        if ( !paging_mode_enabled(d) )
> -            mbs |= PFEC_page_present;
> -
> -        if ( ((regs->error_code&  (mbs | mbz)) == mbs)&&
> +    if ( guest_kernel_mode(v, regs)&&
> +         !(regs->error_code&  (PFEC_reserved_bit | PFEC_insn_fetch))&&
> +         (regs->error_code&  PFEC_write_access) )
> +    {
> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
> +             /* Do not check if access-protection fault since the page may
> +                legitimately be not present in shadow page tables */
> +             (paging_mode_enabled(d) ||
> +              (regs->error_code&  PFEC_page_present))&&
>                ptwr_do_page_fault(v, addr, regs) )
>               return EXCRET_fault_fixed;
> +
> +#ifdef __x86_64__
> +        if ( IS_PRIV(d)&&  (regs->error_code&  PFEC_page_present)&&
> +             mmio_ro_do_page_fault(v, addr, regs) )
> +            return EXCRET_fault_fixed;
> +#endif
>       }
>
>       /* For non-external shadowed guests, we fix up both their own
> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>           return 0;
>
>       machine_bdf = (d->arch.pci_cf8>>  8)&  0xFFFF;
> +    if ( write )
> +    {
> +        const unsigned long *ro_map = pci_get_ro_map(0);
> +
> +        if ( ro_map&&  test_bit(machine_bdf, ro_map) )
> +            return 0;
> +    }
>       start = d->arch.pci_cf8&  0xFF;
>       end = start + size - 1;
>       if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
> --- a/xen/arch/x86/x86_32/pci.c
> +++ b/xen/arch/x86/x86_32/pci.c
> @@ -6,6 +6,7 @@
>
>   #include<xen/spinlock.h>
>   #include<xen/pci.h>
> +#include<xen/init.h>
>   #include<asm/io.h>
>
>   #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
> @@ -70,3 +71,7 @@ void pci_conf_write32(
>       BUG_ON((bus>  255) || (dev>  31) || (func>  7) || (reg>  255));
>       pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>   }
> +
> +void __init arch_pci_ro_device(int seg, int bdf)
> +{
> +}
> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> @@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const
>       return (void __iomem *) virt;
>   }
>
> +void arch_pci_ro_device(int seg, int bdf)
> +{
> +    unsigned int idx, bus = PCI_BUS(bdf);
> +
> +    for (idx = 0; idx<  pci_mmcfg_config_num; ++idx) {
> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
> +        unsigned long mfn = (cfg->address>>  PAGE_SHIFT) + bdf;
> +
> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
> +            cfg->start_bus_number>  bus || cfg->end_bus_number<  bus)
> +            continue;
> +
> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
> +            printk(XENLOG_ERR
> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) read-only\n",
> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
> +                   mfn);
> +    }
> +}
> +
>   int pci_mmcfg_arch_enable(unsigned int idx)
>   {
>       const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>
>       if (pci_mmcfg_virt[idx].virt)
>           return 0;
> @@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>       }
>       printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>              cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
> +    if (ro_map) {
> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
> +
> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf))<= end) {
> +            arch_pci_ro_device(cfg->pci_segment, bdf);
> +            if (bdf++ == end)
> +                break;
> +        }
> +    }
>       return 0;
>   }
>
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>       if ( rt )
>           return -ENODEV;
>
> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
> +    if ( rt )
> +        printk(XENLOG_ERR
> +               "Could not mark config space of %04x:%02x:%02x.%u read-only (%d)\n",
> +               iommu->seg, bus, dev, func, rt);
> +
>       list_add_tail(&iommu->list,&amd_iommu_head);
>
>       return 0;
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>   unlock:
>       spin_unlock(&d->event_lock);
>   }
> -
> -static int __init setup_mmio_ro_ranges(void)
> -{
> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> -                                  RANGESETF_prettyprint_hex);
> -    return 0;
> -}
> -__initcall(setup_mmio_ro_ranges);
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -36,6 +36,7 @@
>   struct pci_seg {
>       struct list_head alldevs_list;
>       u16 nr;
> +    unsigned long *ro_map;
>       /* bus2bridge_lock protects bus2bridge array */
>       spinlock_t bus2bridge_lock;
>   #define MAX_BUSES 256
> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>       radix_tree_init(&pci_segments);
>       if ( !alloc_pseg(0) )
>           panic("Could not initialize PCI segment 0\n");
> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> +                                  RANGESETF_prettyprint_hex);
>   }
>
>   int __init pci_add_segment(u16 seg)
> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>       return alloc_pseg(seg) ? 0 : -ENOMEM;
>   }
>
> +const unsigned long *pci_get_ro_map(u16 seg)
> +{
> +    struct pci_seg *pseg = get_pseg(seg);
> +
> +    return pseg ? pseg->ro_map : NULL;
> +}
> +
>   static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>   {
>       struct pci_dev *pdev;
> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>       xfree(pdev);
>   }
>
> +int __init pci_ro_device(int seg, int bus, int devfn)
> +{
> +    struct pci_seg *pseg = alloc_pseg(seg);
> +    struct pci_dev *pdev;
> +
> +    if ( !pseg )
> +        return -ENOMEM;
> +    pdev = alloc_pdev(pseg, bus, devfn);
> +    if ( !pdev )
> +        return -ENOMEM;
> +
> +    if ( !pseg->ro_map )
> +    {
> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
> +
> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
> +        if ( !pseg->ro_map )
> +            return -ENOMEM;
> +        memset(pseg->ro_map, 0, sz);
> +    }
> +
> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
> +
> +    return 0;
> +}
> +
>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>   {
>       struct pci_seg *pseg = get_pseg(seg);
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>
>   int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>                           struct cpu_user_regs *);
> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
> +                           struct cpu_user_regs *);
>
>   int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>   void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>   void pci_release_devices(struct domain *d);
>   int pci_add_segment(u16 seg);
> +const unsigned long *pci_get_ro_map(u16 seg);
>   int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
>   int pci_remove_device(u16 seg, u8 bus, u8 devfn);
> +int pci_ro_device(int seg, int bus, int devfn);
> +void arch_pci_ro_device(int seg, int bdf);
>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>   struct pci_dev *pci_get_pdev_by_domain(
>       struct domain *, int seg, int bus, int devfn);
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15:49: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 1ShjdJ-00068D-4a; Thu, 21 Jun 2012 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 <JBeulich@suse.com>) id 1ShjdH-000688-IM
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 15:49:20 +0000
Received: from [193.109.254.147:21672] by server-5.bemta-14.messagelabs.com id
	72/30-04343-E7243EF4; Thu, 21 Jun 2012 15:49:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340293757!10081198!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23469 invoked from network); 21 Jun 2012 15:49:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 15:49:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:49:17 +0100
Message-Id: <4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:49:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FE20C49020000780008AE25@nat28.tlf.novell.com>
	<4FE33DBC.4030104@amd.com>
In-Reply-To: <4FE33DBC.4030104@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.06.12 at 17:29, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/20/2012 05:45 PM, Jan Beulich wrote:
>   > Rather than submitting it for inclusion immediately, I'd rather see
>> you first use it successfully. Below/attached what appears to
>> work fine for me in contrived situations (i.e. hiding bridges with
>> nothing connected, as I still don't have any AMD IOMMU system
>> at hand).
> 
> The patch works for me. IOMMU msi Capability is shown as enabled with 
> this patch.

Keir,

the question now arises whether we really want this, and
particularly this late before 4.2. The Linux folks don't seem to
be willing to take the strait forward workaround for the
problem introduced at their end, so we will likely need
something (the more that the questionable fix already made
it into various stable trees) before 4.2 goes out (and even
the older trees would be affected, just that putting a change
like this there is even more questionable).

There are obviously more potential problems in this area: If
any of the MMIO addresses used by AMD's IOMMU is
configurable through one of the BARs, and if Dom0 decides to
re-assign MMIO space, neither allowing the writes nor simply
dropping them as done here will work. Whether that's a real
problem I don't know - Wei? And there might be other issues
arising from dropping all writes - we might just currently not be
aware of them.

Jan

> 00:00.2 Generic system peripheral [0806]: Advanced Micro Devices [AMD] 
> Device 1419
>          Subsystem: Advanced Micro Devices [AMD] Device 1419
>          Flags: bus master, fast devsel, latency 0, IRQ 11
>          Capabilities: [40] Secure device <?>
>          Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
> 
> 
>> Jan
>>
>> Note that due to ptwr_do_page_fault() being run first, there'll be a
>> MEM_LOG() issued for each such attempt. If that's undesirable, the
>> order of the calls would need to be swapped.
>>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>>               break;
>>           case 1:
>>               l1e_remove_flags(nl1e, _PAGE_RW);
>> +            rc = 0;
>>               break;
>>           }
>>           if ( page )
>> @@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>>       return 0;
>>   }
>>
>> +#ifdef __x86_64__
>> +/*************************
>> + * fault handling for read-only MMIO pages
>> + */
>> +
>> +struct mmio_ro_emulate_ctxt {
>> +    struct x86_emulate_ctxt ctxt;
>> +    unsigned long cr2;
>> +};
>> +
>> +static int mmio_ro_emulated_read(
>> +    enum x86_segment seg,
>> +    unsigned long offset,
>> +    void *p_data,
>> +    unsigned int bytes,
>> +    struct x86_emulate_ctxt *ctxt)
>> +{
>> +    return X86EMUL_UNHANDLEABLE;
>> +}
>> +
>> +static int mmio_ro_emulated_write(
>> +    enum x86_segment seg,
>> +    unsigned long offset,
>> +    void *p_data,
>> +    unsigned int bytes,
>> +    struct x86_emulate_ctxt *ctxt)
>> +{
>> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
>> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
>> +
>> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
>> +    if ( ((bytes | offset)&  (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
>> +    {
>> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx, 
> bytes=%u)",
>> +                mmio_ro_ctxt->cr2, offset, bytes);
>> +        return X86EMUL_UNHANDLEABLE;
>> +    }
>> +
>> +    return X86EMUL_OKAY;
>> +}
>> +
>> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
>> +    .read       = mmio_ro_emulated_read,
>> +    .insn_fetch = ptwr_emulated_read,
>> +    .write      = mmio_ro_emulated_write,
>> +};
>> +
>> +/* Check if guest is trying to modify a r/o MMIO page. */
>> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
>> +                          struct cpu_user_regs *regs)
>> +{
>> +    l1_pgentry_t      pte;
>> +    unsigned long     mfn;
>> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
>> +                                  32 : BITS_PER_LONG;
>> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
>> +        .ctxt.regs = regs,
>> +        .ctxt.addr_size = addr_size,
>> +        .ctxt.sp_size = addr_size,
>> +        .cr2 = addr
>> +    };
>> +    int rc;
>> +
>> +    /* Attempt to read the PTE that maps the VA being accessed. */
>> +    guest_get_eff_l1e(v, addr,&pte);
>> +
>> +    /* We are looking only for read-only mappings of MMIO pages. */
>> +    if ( ((l1e_get_flags(pte)&  (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) 
> )
>> +        return 0;
>> +
>> +    mfn = l1e_get_pfn(pte);
>> +    if ( mfn_valid(mfn) )
>> +    {
>> +        struct page_info *page = mfn_to_page(mfn);
>> +        struct domain *owner = page_get_owner_and_reference(page);
>> +
>> +        if ( owner )
>> +            put_page(page);
>> +        if ( owner != dom_io )
>> +            return 0;
>> +    }
>> +
>> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>> +        return 0;
>> +
>> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt,&mmio_ro_emulate_ops);
>> +
>> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
>> +}
>> +#endif /* __x86_64__ */
>> +
>>   void free_xen_pagetable(void *v)
>>   {
>>       if ( system_state == SYS_STATE_early_boot )
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>>           return 0;
>>       }
>>
>> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>> -         guest_kernel_mode(v, regs) )
>> -    {
>> -        unsigned int mbs = PFEC_write_access;
>> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
>> -
>> -        /* Do not check if access-protection fault since the page may
>> -           legitimately be not present in shadow page tables */
>> -        if ( !paging_mode_enabled(d) )
>> -            mbs |= PFEC_page_present;
>> -
>> -        if ( ((regs->error_code&  (mbs | mbz)) == mbs)&&
>> +    if ( guest_kernel_mode(v, regs)&&
>> +         !(regs->error_code&  (PFEC_reserved_bit | PFEC_insn_fetch))&&
>> +         (regs->error_code&  PFEC_write_access) )
>> +    {
>> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>> +             /* Do not check if access-protection fault since the page may
>> +                legitimately be not present in shadow page tables */
>> +             (paging_mode_enabled(d) ||
>> +              (regs->error_code&  PFEC_page_present))&&
>>                ptwr_do_page_fault(v, addr, regs) )
>>               return EXCRET_fault_fixed;
>> +
>> +#ifdef __x86_64__
>> +        if ( IS_PRIV(d)&&  (regs->error_code&  PFEC_page_present)&&
>> +             mmio_ro_do_page_fault(v, addr, regs) )
>> +            return EXCRET_fault_fixed;
>> +#endif
>>       }
>>
>>       /* For non-external shadowed guests, we fix up both their own
>> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>>           return 0;
>>
>>       machine_bdf = (d->arch.pci_cf8>>  8)&  0xFFFF;
>> +    if ( write )
>> +    {
>> +        const unsigned long *ro_map = pci_get_ro_map(0);
>> +
>> +        if ( ro_map&&  test_bit(machine_bdf, ro_map) )
>> +            return 0;
>> +    }
>>       start = d->arch.pci_cf8&  0xFF;
>>       end = start + size - 1;
>>       if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>> --- a/xen/arch/x86/x86_32/pci.c
>> +++ b/xen/arch/x86/x86_32/pci.c
>> @@ -6,6 +6,7 @@
>>
>>   #include<xen/spinlock.h>
>>   #include<xen/pci.h>
>> +#include<xen/init.h>
>>   #include<asm/io.h>
>>
>>   #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
>> @@ -70,3 +71,7 @@ void pci_conf_write32(
>>       BUG_ON((bus>  255) || (dev>  31) || (func>  7) || (reg>  255));
>>       pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>>   }
>> +
>> +void __init arch_pci_ro_device(int seg, int bdf)
>> +{
>> +}
>> --- a/xen/arch/x86/x86_64/mmconfig_64.c
>> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
>> @@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const
>>       return (void __iomem *) virt;
>>   }
>>
>> +void arch_pci_ro_device(int seg, int bdf)
>> +{
>> +    unsigned int idx, bus = PCI_BUS(bdf);
>> +
>> +    for (idx = 0; idx<  pci_mmcfg_config_num; ++idx) {
>> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
>> +        unsigned long mfn = (cfg->address>>  PAGE_SHIFT) + bdf;
>> +
>> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
>> +            cfg->start_bus_number>  bus || cfg->end_bus_number<  bus)
>> +            continue;
>> +
>> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
>> +            printk(XENLOG_ERR
>> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) 
> read-only\n",
>> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
>> +                   mfn);
>> +    }
>> +}
>> +
>>   int pci_mmcfg_arch_enable(unsigned int idx)
>>   {
>>       const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
>> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>>
>>       if (pci_mmcfg_virt[idx].virt)
>>           return 0;
>> @@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>>       }
>>       printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>>              cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
>> +    if (ro_map) {
>> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
>> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
>> +
>> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf))<= end) {
>> +            arch_pci_ro_device(cfg->pci_segment, bdf);
>> +            if (bdf++ == end)
>> +                break;
>> +        }
>> +    }
>>       return 0;
>>   }
>>
>> --- a/xen/drivers/passthrough/amd/iommu_detect.c
>> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
>> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>>       if ( rt )
>>           return -ENODEV;
>>
>> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
>> +    if ( rt )
>> +        printk(XENLOG_ERR
>> +               "Could not mark config space of %04x:%02x:%02x.%u read-only 
> (%d)\n",
>> +               iommu->seg, bus, dev, func, rt);
>> +
>>       list_add_tail(&iommu->list,&amd_iommu_head);
>>
>>       return 0;
>> --- a/xen/drivers/passthrough/io.c
>> +++ b/xen/drivers/passthrough/io.c
>> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>>   unlock:
>>       spin_unlock(&d->event_lock);
>>   }
>> -
>> -static int __init setup_mmio_ro_ranges(void)
>> -{
>> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>> -                                  RANGESETF_prettyprint_hex);
>> -    return 0;
>> -}
>> -__initcall(setup_mmio_ro_ranges);
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -36,6 +36,7 @@
>>   struct pci_seg {
>>       struct list_head alldevs_list;
>>       u16 nr;
>> +    unsigned long *ro_map;
>>       /* bus2bridge_lock protects bus2bridge array */
>>       spinlock_t bus2bridge_lock;
>>   #define MAX_BUSES 256
>> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>>       radix_tree_init(&pci_segments);
>>       if ( !alloc_pseg(0) )
>>           panic("Could not initialize PCI segment 0\n");
>> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>> +                                  RANGESETF_prettyprint_hex);
>>   }
>>
>>   int __init pci_add_segment(u16 seg)
>> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>>       return alloc_pseg(seg) ? 0 : -ENOMEM;
>>   }
>>
>> +const unsigned long *pci_get_ro_map(u16 seg)
>> +{
>> +    struct pci_seg *pseg = get_pseg(seg);
>> +
>> +    return pseg ? pseg->ro_map : NULL;
>> +}
>> +
>>   static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>>   {
>>       struct pci_dev *pdev;
>> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>>       xfree(pdev);
>>   }
>>
>> +int __init pci_ro_device(int seg, int bus, int devfn)
>> +{
>> +    struct pci_seg *pseg = alloc_pseg(seg);
>> +    struct pci_dev *pdev;
>> +
>> +    if ( !pseg )
>> +        return -ENOMEM;
>> +    pdev = alloc_pdev(pseg, bus, devfn);
>> +    if ( !pdev )
>> +        return -ENOMEM;
>> +
>> +    if ( !pseg->ro_map )
>> +    {
>> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
>> +
>> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
>> +        if ( !pseg->ro_map )
>> +            return -ENOMEM;
>> +        memset(pseg->ro_map, 0, sz);
>> +    }
>> +
>> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
>> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
>> +
>> +    return 0;
>> +}
>> +
>>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>>   {
>>       struct pci_seg *pseg = get_pseg(seg);
>> --- a/xen/include/asm-x86/mm.h
>> +++ b/xen/include/asm-x86/mm.h
>> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>>
>>   int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>>                           struct cpu_user_regs *);
>> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
>> +                           struct cpu_user_regs *);
>>
>>   int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>>
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>>   void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>>   void pci_release_devices(struct domain *d);
>>   int pci_add_segment(u16 seg);
>> +const unsigned long *pci_get_ro_map(u16 seg);
>>   int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info 
> *);
>>   int pci_remove_device(u16 seg, u8 bus, u8 devfn);
>> +int pci_ro_device(int seg, int bus, int devfn);
>> +void arch_pci_ro_device(int seg, int bdf);
>>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>>   struct pci_dev *pci_get_pdev_by_domain(
>>       struct domain *, int seg, int bus, int devfn);
>>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 15:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 15:49: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 1ShjdJ-00068D-4a; Thu, 21 Jun 2012 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 <JBeulich@suse.com>) id 1ShjdH-000688-IM
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 15:49:20 +0000
Received: from [193.109.254.147:21672] by server-5.bemta-14.messagelabs.com id
	72/30-04343-E7243EF4; Thu, 21 Jun 2012 15:49:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340293757!10081198!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23469 invoked from network); 21 Jun 2012 15:49:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 15:49:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 16:49:17 +0100
Message-Id: <4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 16:49:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FE20C49020000780008AE25@nat28.tlf.novell.com>
	<4FE33DBC.4030104@amd.com>
In-Reply-To: <4FE33DBC.4030104@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.06.12 at 17:29, Wei Wang <wei.wang2@amd.com> wrote:
> On 06/20/2012 05:45 PM, Jan Beulich wrote:
>   > Rather than submitting it for inclusion immediately, I'd rather see
>> you first use it successfully. Below/attached what appears to
>> work fine for me in contrived situations (i.e. hiding bridges with
>> nothing connected, as I still don't have any AMD IOMMU system
>> at hand).
> 
> The patch works for me. IOMMU msi Capability is shown as enabled with 
> this patch.

Keir,

the question now arises whether we really want this, and
particularly this late before 4.2. The Linux folks don't seem to
be willing to take the strait forward workaround for the
problem introduced at their end, so we will likely need
something (the more that the questionable fix already made
it into various stable trees) before 4.2 goes out (and even
the older trees would be affected, just that putting a change
like this there is even more questionable).

There are obviously more potential problems in this area: If
any of the MMIO addresses used by AMD's IOMMU is
configurable through one of the BARs, and if Dom0 decides to
re-assign MMIO space, neither allowing the writes nor simply
dropping them as done here will work. Whether that's a real
problem I don't know - Wei? And there might be other issues
arising from dropping all writes - we might just currently not be
aware of them.

Jan

> 00:00.2 Generic system peripheral [0806]: Advanced Micro Devices [AMD] 
> Device 1419
>          Subsystem: Advanced Micro Devices [AMD] Device 1419
>          Flags: bus master, fast devsel, latency 0, IRQ 11
>          Capabilities: [40] Secure device <?>
>          Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
> 
> 
>> Jan
>>
>> Note that due to ptwr_do_page_fault() being run first, there'll be a
>> MEM_LOG() issued for each such attempt. If that's undesirable, the
>> order of the calls would need to be swapped.
>>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>>               break;
>>           case 1:
>>               l1e_remove_flags(nl1e, _PAGE_RW);
>> +            rc = 0;
>>               break;
>>           }
>>           if ( page )
>> @@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>>       return 0;
>>   }
>>
>> +#ifdef __x86_64__
>> +/*************************
>> + * fault handling for read-only MMIO pages
>> + */
>> +
>> +struct mmio_ro_emulate_ctxt {
>> +    struct x86_emulate_ctxt ctxt;
>> +    unsigned long cr2;
>> +};
>> +
>> +static int mmio_ro_emulated_read(
>> +    enum x86_segment seg,
>> +    unsigned long offset,
>> +    void *p_data,
>> +    unsigned int bytes,
>> +    struct x86_emulate_ctxt *ctxt)
>> +{
>> +    return X86EMUL_UNHANDLEABLE;
>> +}
>> +
>> +static int mmio_ro_emulated_write(
>> +    enum x86_segment seg,
>> +    unsigned long offset,
>> +    void *p_data,
>> +    unsigned int bytes,
>> +    struct x86_emulate_ctxt *ctxt)
>> +{
>> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
>> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
>> +
>> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
>> +    if ( ((bytes | offset)&  (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
>> +    {
>> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx, 
> bytes=%u)",
>> +                mmio_ro_ctxt->cr2, offset, bytes);
>> +        return X86EMUL_UNHANDLEABLE;
>> +    }
>> +
>> +    return X86EMUL_OKAY;
>> +}
>> +
>> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
>> +    .read       = mmio_ro_emulated_read,
>> +    .insn_fetch = ptwr_emulated_read,
>> +    .write      = mmio_ro_emulated_write,
>> +};
>> +
>> +/* Check if guest is trying to modify a r/o MMIO page. */
>> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
>> +                          struct cpu_user_regs *regs)
>> +{
>> +    l1_pgentry_t      pte;
>> +    unsigned long     mfn;
>> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
>> +                                  32 : BITS_PER_LONG;
>> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
>> +        .ctxt.regs = regs,
>> +        .ctxt.addr_size = addr_size,
>> +        .ctxt.sp_size = addr_size,
>> +        .cr2 = addr
>> +    };
>> +    int rc;
>> +
>> +    /* Attempt to read the PTE that maps the VA being accessed. */
>> +    guest_get_eff_l1e(v, addr,&pte);
>> +
>> +    /* We are looking only for read-only mappings of MMIO pages. */
>> +    if ( ((l1e_get_flags(pte)&  (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) 
> )
>> +        return 0;
>> +
>> +    mfn = l1e_get_pfn(pte);
>> +    if ( mfn_valid(mfn) )
>> +    {
>> +        struct page_info *page = mfn_to_page(mfn);
>> +        struct domain *owner = page_get_owner_and_reference(page);
>> +
>> +        if ( owner )
>> +            put_page(page);
>> +        if ( owner != dom_io )
>> +            return 0;
>> +    }
>> +
>> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>> +        return 0;
>> +
>> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt,&mmio_ro_emulate_ops);
>> +
>> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
>> +}
>> +#endif /* __x86_64__ */
>> +
>>   void free_xen_pagetable(void *v)
>>   {
>>       if ( system_state == SYS_STATE_early_boot )
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>>           return 0;
>>       }
>>
>> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>> -         guest_kernel_mode(v, regs) )
>> -    {
>> -        unsigned int mbs = PFEC_write_access;
>> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
>> -
>> -        /* Do not check if access-protection fault since the page may
>> -           legitimately be not present in shadow page tables */
>> -        if ( !paging_mode_enabled(d) )
>> -            mbs |= PFEC_page_present;
>> -
>> -        if ( ((regs->error_code&  (mbs | mbz)) == mbs)&&
>> +    if ( guest_kernel_mode(v, regs)&&
>> +         !(regs->error_code&  (PFEC_reserved_bit | PFEC_insn_fetch))&&
>> +         (regs->error_code&  PFEC_write_access) )
>> +    {
>> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>> +             /* Do not check if access-protection fault since the page may
>> +                legitimately be not present in shadow page tables */
>> +             (paging_mode_enabled(d) ||
>> +              (regs->error_code&  PFEC_page_present))&&
>>                ptwr_do_page_fault(v, addr, regs) )
>>               return EXCRET_fault_fixed;
>> +
>> +#ifdef __x86_64__
>> +        if ( IS_PRIV(d)&&  (regs->error_code&  PFEC_page_present)&&
>> +             mmio_ro_do_page_fault(v, addr, regs) )
>> +            return EXCRET_fault_fixed;
>> +#endif
>>       }
>>
>>       /* For non-external shadowed guests, we fix up both their own
>> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>>           return 0;
>>
>>       machine_bdf = (d->arch.pci_cf8>>  8)&  0xFFFF;
>> +    if ( write )
>> +    {
>> +        const unsigned long *ro_map = pci_get_ro_map(0);
>> +
>> +        if ( ro_map&&  test_bit(machine_bdf, ro_map) )
>> +            return 0;
>> +    }
>>       start = d->arch.pci_cf8&  0xFF;
>>       end = start + size - 1;
>>       if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>> --- a/xen/arch/x86/x86_32/pci.c
>> +++ b/xen/arch/x86/x86_32/pci.c
>> @@ -6,6 +6,7 @@
>>
>>   #include<xen/spinlock.h>
>>   #include<xen/pci.h>
>> +#include<xen/init.h>
>>   #include<asm/io.h>
>>
>>   #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
>> @@ -70,3 +71,7 @@ void pci_conf_write32(
>>       BUG_ON((bus>  255) || (dev>  31) || (func>  7) || (reg>  255));
>>       pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>>   }
>> +
>> +void __init arch_pci_ro_device(int seg, int bdf)
>> +{
>> +}
>> --- a/xen/arch/x86/x86_64/mmconfig_64.c
>> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
>> @@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const
>>       return (void __iomem *) virt;
>>   }
>>
>> +void arch_pci_ro_device(int seg, int bdf)
>> +{
>> +    unsigned int idx, bus = PCI_BUS(bdf);
>> +
>> +    for (idx = 0; idx<  pci_mmcfg_config_num; ++idx) {
>> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
>> +        unsigned long mfn = (cfg->address>>  PAGE_SHIFT) + bdf;
>> +
>> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
>> +            cfg->start_bus_number>  bus || cfg->end_bus_number<  bus)
>> +            continue;
>> +
>> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
>> +            printk(XENLOG_ERR
>> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) 
> read-only\n",
>> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
>> +                   mfn);
>> +    }
>> +}
>> +
>>   int pci_mmcfg_arch_enable(unsigned int idx)
>>   {
>>       const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
>> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>>
>>       if (pci_mmcfg_virt[idx].virt)
>>           return 0;
>> @@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>>       }
>>       printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>>              cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
>> +    if (ro_map) {
>> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
>> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
>> +
>> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf))<= end) {
>> +            arch_pci_ro_device(cfg->pci_segment, bdf);
>> +            if (bdf++ == end)
>> +                break;
>> +        }
>> +    }
>>       return 0;
>>   }
>>
>> --- a/xen/drivers/passthrough/amd/iommu_detect.c
>> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
>> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>>       if ( rt )
>>           return -ENODEV;
>>
>> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
>> +    if ( rt )
>> +        printk(XENLOG_ERR
>> +               "Could not mark config space of %04x:%02x:%02x.%u read-only 
> (%d)\n",
>> +               iommu->seg, bus, dev, func, rt);
>> +
>>       list_add_tail(&iommu->list,&amd_iommu_head);
>>
>>       return 0;
>> --- a/xen/drivers/passthrough/io.c
>> +++ b/xen/drivers/passthrough/io.c
>> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>>   unlock:
>>       spin_unlock(&d->event_lock);
>>   }
>> -
>> -static int __init setup_mmio_ro_ranges(void)
>> -{
>> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>> -                                  RANGESETF_prettyprint_hex);
>> -    return 0;
>> -}
>> -__initcall(setup_mmio_ro_ranges);
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -36,6 +36,7 @@
>>   struct pci_seg {
>>       struct list_head alldevs_list;
>>       u16 nr;
>> +    unsigned long *ro_map;
>>       /* bus2bridge_lock protects bus2bridge array */
>>       spinlock_t bus2bridge_lock;
>>   #define MAX_BUSES 256
>> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>>       radix_tree_init(&pci_segments);
>>       if ( !alloc_pseg(0) )
>>           panic("Could not initialize PCI segment 0\n");
>> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>> +                                  RANGESETF_prettyprint_hex);
>>   }
>>
>>   int __init pci_add_segment(u16 seg)
>> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>>       return alloc_pseg(seg) ? 0 : -ENOMEM;
>>   }
>>
>> +const unsigned long *pci_get_ro_map(u16 seg)
>> +{
>> +    struct pci_seg *pseg = get_pseg(seg);
>> +
>> +    return pseg ? pseg->ro_map : NULL;
>> +}
>> +
>>   static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>>   {
>>       struct pci_dev *pdev;
>> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>>       xfree(pdev);
>>   }
>>
>> +int __init pci_ro_device(int seg, int bus, int devfn)
>> +{
>> +    struct pci_seg *pseg = alloc_pseg(seg);
>> +    struct pci_dev *pdev;
>> +
>> +    if ( !pseg )
>> +        return -ENOMEM;
>> +    pdev = alloc_pdev(pseg, bus, devfn);
>> +    if ( !pdev )
>> +        return -ENOMEM;
>> +
>> +    if ( !pseg->ro_map )
>> +    {
>> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
>> +
>> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
>> +        if ( !pseg->ro_map )
>> +            return -ENOMEM;
>> +        memset(pseg->ro_map, 0, sz);
>> +    }
>> +
>> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
>> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
>> +
>> +    return 0;
>> +}
>> +
>>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>>   {
>>       struct pci_seg *pseg = get_pseg(seg);
>> --- a/xen/include/asm-x86/mm.h
>> +++ b/xen/include/asm-x86/mm.h
>> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>>
>>   int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>>                           struct cpu_user_regs *);
>> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
>> +                           struct cpu_user_regs *);
>>
>>   int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>>
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>>   void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>>   void pci_release_devices(struct domain *d);
>>   int pci_add_segment(u16 seg);
>> +const unsigned long *pci_get_ro_map(u16 seg);
>>   int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info 
> *);
>>   int pci_remove_device(u16 seg, u8 bus, u8 devfn);
>> +int pci_ro_device(int seg, int bus, int devfn);
>> +void arch_pci_ro_device(int seg, int bdf);
>>   struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>>   struct pci_dev *pci_get_pdev_by_domain(
>>       struct domain *, int seg, int bus, int devfn);
>>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:06:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1Shjtg-0006mt-NP; Thu, 21 Jun 2012 16:06:16 +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 1Shjtf-0006mo-IF
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 16:06:15 +0000
Received: from [85.158.138.51:40781] by server-3.bemta-3.messagelabs.com id
	8D/A0-26490-67643EF4; Thu, 21 Jun 2012 16:06:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340294774!27770917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14894 invoked from network); 21 Jun 2012 16:06:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 16:06:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 17:06:13 +0100
Message-Id: <4FE362C0020000780008B2CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 17:06:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Recently we design xen vMCE as attached.
> Please kindly help me to review it, any comments/suggestions are 
> appreciated.

The concept looks quite okay, provided no OS has a problem with
the limitations imposed (most notably the restriction to a single
reporting bank, particularly in the context of e.g. Linux partly
ignoring the first bank under some conditions iirc).

As to not needing any migration specific adjustments - what if
a migration is in progress when an event needs to be delivered?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:06:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1Shjtg-0006mt-NP; Thu, 21 Jun 2012 16:06:16 +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 1Shjtf-0006mo-IF
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 16:06:15 +0000
Received: from [85.158.138.51:40781] by server-3.bemta-3.messagelabs.com id
	8D/A0-26490-67643EF4; Thu, 21 Jun 2012 16:06:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340294774!27770917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14894 invoked from network); 21 Jun 2012 16:06:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 16:06:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Jun 2012 17:06:13 +0100
Message-Id: <4FE362C0020000780008B2CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 21 Jun 2012 17:06:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Recently we design xen vMCE as attached.
> Please kindly help me to review it, any comments/suggestions are 
> appreciated.

The concept looks quite okay, provided no OS has a problem with
the limitations imposed (most notably the restriction to a single
reporting bank, particularly in the context of e.g. Linux partly
ignoring the first bank under some conditions iirc).

As to not needing any migration specific adjustments - what if
a migration is in progress when an event needs to be delivered?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:18:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1Shk5S-0006yD-VD; Thu, 21 Jun 2012 16:18:26 +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 1Shk5R-0006y8-9H
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:18:25 +0000
Received: from [85.158.143.35:46349] by server-1.bemta-4.messagelabs.com id
	3C/98-24392-05943EF4; Thu, 21 Jun 2012 16:18:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340295501!16220804!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjExNTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28990 invoked from network); 21 Jun 2012 16:18:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:18:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336363200"; d="scan'208";a="199588365"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 12:18:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:18:12 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Shk5E-0005Wv-CO;
	Thu, 21 Jun 2012 17:18:12 +0100
Message-ID: <4FE348C1.5030407@eu.citrix.com>
Date: Thu, 21 Jun 2012 17:16:01 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
In-Reply-To: <81f18379bb3d4d9397d1.1339779876@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 15/06/12 18:04, Dario Faggioli wrote:
> If a domain does not have a VCPU affinity, try to pin it automatically to some
> PCPUs. This is done taking into account the NUMA characteristics of the host.
> In fact, we look for a combination of host's NUMA nodes with enough free memory
> and number of PCPUs for the new domain, and pin it to the VCPUs of those nodes.
>
> Once we know which ones, among all the possible combinations, represents valid
> placement candidates for a domain, use some heuistics for deciding which is the
> best. For instance, smaller candidates are considered to be better, both from
> the domain's point of view (fewer memory spreading among nodes) and from the
> system as a whole point of view (fewer memoy fragmentation).  In case of
> candidates of equal sizes (i.e., with the same number of nodes), the one with
> the greater amount of memory wins, as this is also good for keeping memory
> fragmentation under control.
>
> This all happens internally to libxl, and no API for driving the mechanism is
> provided for now. This matches what xend already does.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
Overall I think this approach is much better.  I haven't done an 
extremely detailed review, but I do have some comments below.
> +    /*
> +     * Round up and down some of the constraints. For instance, the minimum
> +     * number of cpus a candidate should have must at least be non-negative.
> +     * Regarding the minimum number of NUMA nodes, if 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
> +     * from 1 otherwise). The maximum number of nodes should not exceed the
> +     * number of existent NUMA nodes on the host, or the candidate genaration
> +     * won't work properly.
> +     */
> +    min_cpus = min_cpus<= 0 ? 0 : min_cpus;
Wouldn't it just make more sense to specify that "min_cpus" (and other 
parameters) had to be >=0?

In any case, this is a very complicated way of saying "if (min_cpus<0) 
min_cpus = 0;".
> +    if (min_nodes<= 0) {
> +        int cpus_per_node;
> +
> +        cpus_per_node = cpus_per_node_count(tinfo, nr_cpus, ninfo, nr_nodes);
> +        if (cpus_per_node == 0)
> +            min_nodes = 1;
> +        else
> +            min_nodes = (min_cpus + cpus_per_node - 1) / cpus_per_node;
> +    }
Same here; you could just write "if(!min_nodes) {..."
> +    min_nodes = min_nodes>  nr_nodes ? nr_nodes : min_nodes;
> +    if (max_nodes<= 0)
> +        max_nodes = nr_nodes;
> +    else
> +        max_nodes = max_nodes>  nr_nodes ? nr_nodes : max_nodes;
if (max_nodes == 0 || max_nodes > nr_nodes) max_nodes = nr_nodes;
> +
> +/*
> + * The NUMA placement candidates are reordered according to the following
> + * heuristics:
> + *  - candidates involving fewer nodes come first. In case two (or
> + *    more) candidates span the same number of nodes,
> + *  - candidates with greater amount of free memory come first. In
> + *    case two (or more) candidates differ in their amount of free
> + *    memory by less than 10%,
Interesting idea -- sounds pretty reasonable.
> + *  - candidates with fewer domains insisting on them at the time of
> + *    this call come first.
Do you mean "existing"?  I think "assigned to" is probably better.
> + */
> +static int numa_cmpf(const void *v1, const void *v2)
> +{
> +    const libxl__numa_candidate *c1 = (const libxl__numa_candidate*) v1;
> +    const libxl__numa_candidate *c2 = (const libxl__numa_candidate*) v2;
> +    double mem_diff = labs(c1->free_memkb - c2->free_memkb);
> +    double mem_avg = (c1->free_memkb + c2->free_memkb) / 2.0;
> +
> +    if (c1->nr_nodes != c2->nr_nodes)
> +        return c1->nr_nodes - c2->nr_nodes;
> +
> +    if ((mem_diff / mem_avg) * 100.0<  10.0&&
> +        c1->nr_domains != c2->nr_domains)
> +        return c1->nr_domains - c2->nr_domains;
I realize this isn't a hot path, but it seems like moving into FP is 
really unnecessary.  You can just do this:

if ( ((mem_diff * 100) / mem_avg) < 10 ...

One minor note: I personally think it's a lot more readable to put the 
'&&' and '||' on the same line as the next item, rather than the 
previous item; i.e.:
  if ( expression_a
&& expression_b )

One more thing: Is there a reason why you put get_numa_candidates() in 
libxl_internal.h, but not sort_numa_candidates()?  It seems like both or 
neither should go. :-)

That's all I have for now.  I'm OK with the general approach, so here's 
a "weak ack", so if a maintainer is happy with the code, he can check it in:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

I'll try to come back and give a more detailed code review if I get a 
chance.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:18:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1Shk5S-0006yD-VD; Thu, 21 Jun 2012 16:18:26 +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 1Shk5R-0006y8-9H
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:18:25 +0000
Received: from [85.158.143.35:46349] by server-1.bemta-4.messagelabs.com id
	3C/98-24392-05943EF4; Thu, 21 Jun 2012 16:18:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340295501!16220804!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjExNTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28990 invoked from network); 21 Jun 2012 16:18:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:18:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,451,1336363200"; d="scan'208";a="199588365"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 12:18:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 21 Jun 2012 12:18:12 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Shk5E-0005Wv-CO;
	Thu, 21 Jun 2012 17:18:12 +0100
Message-ID: <4FE348C1.5030407@eu.citrix.com>
Date: Thu, 21 Jun 2012 17:16:01 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
In-Reply-To: <81f18379bb3d4d9397d1.1339779876@Solace>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 15/06/12 18:04, Dario Faggioli wrote:
> If a domain does not have a VCPU affinity, try to pin it automatically to some
> PCPUs. This is done taking into account the NUMA characteristics of the host.
> In fact, we look for a combination of host's NUMA nodes with enough free memory
> and number of PCPUs for the new domain, and pin it to the VCPUs of those nodes.
>
> Once we know which ones, among all the possible combinations, represents valid
> placement candidates for a domain, use some heuistics for deciding which is the
> best. For instance, smaller candidates are considered to be better, both from
> the domain's point of view (fewer memory spreading among nodes) and from the
> system as a whole point of view (fewer memoy fragmentation).  In case of
> candidates of equal sizes (i.e., with the same number of nodes), the one with
> the greater amount of memory wins, as this is also good for keeping memory
> fragmentation under control.
>
> This all happens internally to libxl, and no API for driving the mechanism is
> provided for now. This matches what xend already does.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
Overall I think this approach is much better.  I haven't done an 
extremely detailed review, but I do have some comments below.
> +    /*
> +     * Round up and down some of the constraints. For instance, the minimum
> +     * number of cpus a candidate should have must at least be non-negative.
> +     * Regarding the minimum number of NUMA nodes, if 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
> +     * from 1 otherwise). The maximum number of nodes should not exceed the
> +     * number of existent NUMA nodes on the host, or the candidate genaration
> +     * won't work properly.
> +     */
> +    min_cpus = min_cpus<= 0 ? 0 : min_cpus;
Wouldn't it just make more sense to specify that "min_cpus" (and other 
parameters) had to be >=0?

In any case, this is a very complicated way of saying "if (min_cpus<0) 
min_cpus = 0;".
> +    if (min_nodes<= 0) {
> +        int cpus_per_node;
> +
> +        cpus_per_node = cpus_per_node_count(tinfo, nr_cpus, ninfo, nr_nodes);
> +        if (cpus_per_node == 0)
> +            min_nodes = 1;
> +        else
> +            min_nodes = (min_cpus + cpus_per_node - 1) / cpus_per_node;
> +    }
Same here; you could just write "if(!min_nodes) {..."
> +    min_nodes = min_nodes>  nr_nodes ? nr_nodes : min_nodes;
> +    if (max_nodes<= 0)
> +        max_nodes = nr_nodes;
> +    else
> +        max_nodes = max_nodes>  nr_nodes ? nr_nodes : max_nodes;
if (max_nodes == 0 || max_nodes > nr_nodes) max_nodes = nr_nodes;
> +
> +/*
> + * The NUMA placement candidates are reordered according to the following
> + * heuristics:
> + *  - candidates involving fewer nodes come first. In case two (or
> + *    more) candidates span the same number of nodes,
> + *  - candidates with greater amount of free memory come first. In
> + *    case two (or more) candidates differ in their amount of free
> + *    memory by less than 10%,
Interesting idea -- sounds pretty reasonable.
> + *  - candidates with fewer domains insisting on them at the time of
> + *    this call come first.
Do you mean "existing"?  I think "assigned to" is probably better.
> + */
> +static int numa_cmpf(const void *v1, const void *v2)
> +{
> +    const libxl__numa_candidate *c1 = (const libxl__numa_candidate*) v1;
> +    const libxl__numa_candidate *c2 = (const libxl__numa_candidate*) v2;
> +    double mem_diff = labs(c1->free_memkb - c2->free_memkb);
> +    double mem_avg = (c1->free_memkb + c2->free_memkb) / 2.0;
> +
> +    if (c1->nr_nodes != c2->nr_nodes)
> +        return c1->nr_nodes - c2->nr_nodes;
> +
> +    if ((mem_diff / mem_avg) * 100.0<  10.0&&
> +        c1->nr_domains != c2->nr_domains)
> +        return c1->nr_domains - c2->nr_domains;
I realize this isn't a hot path, but it seems like moving into FP is 
really unnecessary.  You can just do this:

if ( ((mem_diff * 100) / mem_avg) < 10 ...

One minor note: I personally think it's a lot more readable to put the 
'&&' and '||' on the same line as the next item, rather than the 
previous item; i.e.:
  if ( expression_a
&& expression_b )

One more thing: Is there a reason why you put get_numa_candidates() in 
libxl_internal.h, but not sort_numa_candidates()?  It seems like both or 
neither should go. :-)

That's all I have for now.  I'm OK with the general approach, so here's 
a "weak ack", so if a maintainer is happy with the code, he can check it in:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

I'll try to come back and give a more detailed code review if I get a 
chance.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkCI-000781-R0; Thu, 21 Jun 2012 16:25:30 +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 1ShkCH-00077w-V6
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:25:30 +0000
Received: from [85.158.138.51:54231] by server-7.bemta-3.messagelabs.com id
	AE/79-10113-9FA43EF4; Thu, 21 Jun 2012 16:25:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340295928!19733337!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16125 invoked from network); 21 Jun 2012 16:25:28 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:25:28 -0000
Received: by eaak12 with SMTP id k12so390623eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 09:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Swu+L7Czp4U9psFafUSPYtOpjln5S7F1/zCl+3v2ps8=;
	b=SNYhHZqcQPub8nol1qayp1Xn0wGkJSZwXJ/FY2RPL6SI2vAUlTqlmktMnNuRL9ojv2
	TScmwiixGSWetFaNGm1ohPs7kprEVYjmPZ8/YHfppsG++gXBs/UM4Bj5OYIGUsWcrCOf
	/DUtgo57Ojddsc/PVfmTN5DGzgK+EN6bps6frOdthZ0x4BEsxpdWZK5CU2d+Tfi6FUi2
	X0UNYbY0z76Uj8sorH+419hlRvu/6UmVuFsvqiR+93lXzTpVf0KQsKmTyynBwn0lyL0M
	eTX6ppG1mRoGUM7M77c0Vn2/hqrTb500kIkggnXNuIKXDXgTWOlc8LEORhGEgT5HCD3R
	qe/w==
Received: by 10.14.99.79 with SMTP id w55mr6078366eef.59.1340295927690;
	Thu, 21 Jun 2012 09:25:27 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	y54sm104379317eef.10.2012.06.21.09.25.26
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 09:25:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 21 Jun 2012 17:25:25 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC090985.363BA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/PCI: fix guest_io_read() when
	pci_cfg_ok() denies access
Thread-Index: Ac1PynZHAyO/PWkWBUWGF1WbS2kaiQ==
In-Reply-To: <4FE32D13020000780008B134@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/PCI: fix guest_io_read() when
 pci_cfg_ok() denies 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

On 21/06/2012 13:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> For a multi-byte aligned read, this so far resulted in 0x00ff to be
> put in the guest's register rather than 0xffff or 0xffffffff, which in
> turn could confuse bus scanning functions (which, when reading vendor
> and/or device IDs, expect to get back all zeroes or all ones).
> 
> As the value gets masked to the read width when merging back into the
> full result, setting the initial value to all ones should not harm any
> or the other cases.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1717,7 +1717,7 @@ static uint32_t guest_io_read(
>      while ( bytes != 0 )
>      {
>          unsigned int size = 1;
> -        uint32_t sub_data = 0xff;
> +        uint32_t sub_data = ~0;
>  
>          if ( (port == 0x42) || (port == 0x43) || (port == 0x61) )
>          {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 21 16:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkCI-000781-R0; Thu, 21 Jun 2012 16:25:30 +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 1ShkCH-00077w-V6
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:25:30 +0000
Received: from [85.158.138.51:54231] by server-7.bemta-3.messagelabs.com id
	AE/79-10113-9FA43EF4; Thu, 21 Jun 2012 16:25:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340295928!19733337!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16125 invoked from network); 21 Jun 2012 16:25:28 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:25:28 -0000
Received: by eaak12 with SMTP id k12so390623eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 09:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Swu+L7Czp4U9psFafUSPYtOpjln5S7F1/zCl+3v2ps8=;
	b=SNYhHZqcQPub8nol1qayp1Xn0wGkJSZwXJ/FY2RPL6SI2vAUlTqlmktMnNuRL9ojv2
	TScmwiixGSWetFaNGm1ohPs7kprEVYjmPZ8/YHfppsG++gXBs/UM4Bj5OYIGUsWcrCOf
	/DUtgo57Ojddsc/PVfmTN5DGzgK+EN6bps6frOdthZ0x4BEsxpdWZK5CU2d+Tfi6FUi2
	X0UNYbY0z76Uj8sorH+419hlRvu/6UmVuFsvqiR+93lXzTpVf0KQsKmTyynBwn0lyL0M
	eTX6ppG1mRoGUM7M77c0Vn2/hqrTb500kIkggnXNuIKXDXgTWOlc8LEORhGEgT5HCD3R
	qe/w==
Received: by 10.14.99.79 with SMTP id w55mr6078366eef.59.1340295927690;
	Thu, 21 Jun 2012 09:25:27 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	y54sm104379317eef.10.2012.06.21.09.25.26
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 09:25:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 21 Jun 2012 17:25:25 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC090985.363BA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/PCI: fix guest_io_read() when
	pci_cfg_ok() denies access
Thread-Index: Ac1PynZHAyO/PWkWBUWGF1WbS2kaiQ==
In-Reply-To: <4FE32D13020000780008B134@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/PCI: fix guest_io_read() when
 pci_cfg_ok() denies 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

On 21/06/2012 13:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> For a multi-byte aligned read, this so far resulted in 0x00ff to be
> put in the guest's register rather than 0xffff or 0xffffffff, which in
> turn could confuse bus scanning functions (which, when reading vendor
> and/or device IDs, expect to get back all zeroes or all ones).
> 
> As the value gets masked to the read width when merging back into the
> full result, setting the initial value to all ones should not harm any
> or the other cases.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1717,7 +1717,7 @@ static uint32_t guest_io_read(
>      while ( bytes != 0 )
>      {
>          unsigned int size = 1;
> -        uint32_t sub_data = 0xff;
> +        uint32_t sub_data = ~0;
>  
>          if ( (port == 0x42) || (port == 0x43) || (port == 0x61) )
>          {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 21 16:27:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkDf-0007Dz-Gr; Thu, 21 Jun 2012 16:26:55 +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 1ShkDd-0007Dm-Dz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:26:53 +0000
Received: from [85.158.139.83:18189] by server-11.bemta-5.messagelabs.com id
	7B/C6-20400-C4B43EF4; Thu, 21 Jun 2012 16:26:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340296011!28871266!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17800 invoked from network); 21 Jun 2012 16:26:51 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:26:51 -0000
Received: by eaak12 with SMTP id k12so391333eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 09:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=6Kn0EaUJxLijxuDI+MCakuj9ZDbBG9QX1wzMh28/e1w=;
	b=yAXjEh2Q2C2aE7bjnPLswD3jKV8/97qkM1W/GYiEUQjFbLStQrQk7glV0rMyOVVxvy
	0Tu7pkjNukCWgBjIRcPFL06WFGv4kJuPPRfgG4mKY1rwtH7QnXH/HC3WyAv5OehM2IPb
	enj18y/jqxCReXljG8uXEIrt5xLKna17x5J20GRhS8RxX3gykLzGf1GWLvKo2Qc0q8Iv
	lneVJkaoKDjocH59RF1eSFWcVLGoXKVZ/t84iwVsm8y5mgd6qC/r7oA39kWu400fGH1l
	YRJ9+socXnY1NMkxXm1xxwOwTLMXjy/A14SVpBM0fwfIFkvBKySy66PEX9igoRMK/gEA
	mYtQ==
Received: by 10.14.47.138 with SMTP id t10mr6071979eeb.133.1340296011503;
	Thu, 21 Jun 2012 09:26:51 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id a16sm104429733eeg.0.2012.06.21.09.26.50
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 09:26:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 21 Jun 2012 17:26:48 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC0909D8.363BB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86-64: revert mmconfig part of c/s
	24425:053a44894279
Thread-Index: Ac1PyqfASEgTtLCiOkSDK6NCflborg==
In-Reply-To: <4FE359F6020000780008B299@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH] x86-64: revert mmconfig part of c/s
 24425:053a44894279
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 16:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> These additions did not fulfill their purpose - they checked hypervisor
> config space accesses instead of guest (Dom0) ones.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> @@ -14,7 +14,6 @@
>  #include <xen/xmalloc.h>
>  #include <xen/pci.h>
>  #include <xen/pci_regs.h>
> -#include <xsm/xsm.h>
>  
>  #include "mmconfig.h"
>  
> @@ -59,7 +58,6 @@ int pci_mmcfg_read(unsigned int seg, uns
>                unsigned int devfn, int reg, int len, u32 *value)
>  {
>      char __iomem *addr;
> -    uint32_t mbdf;
>  
>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
>      if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
> @@ -67,12 +65,6 @@ err:        *value = -1;
>          return -EINVAL;
>      }
>  
> -    mbdf = (seg << 16) | (bus << 8) | devfn;
> -    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1,
> 0)) {
> -        *value = -1;
> -        return -EPERM;
> -    }
> -
>      addr = pci_dev_base(seg, bus, devfn);
>      if (!addr)
>          goto err;
> @@ -96,16 +88,11 @@ int pci_mmcfg_write(unsigned int seg, un
>                 unsigned int devfn, int reg, int len, u32 value)
>  {
>      char __iomem *addr;
> -    uint32_t mbdf;
>  
>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
>      if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
>          return -EINVAL;
>  
> -    mbdf = (seg << 16) | (bus << 8) | devfn;
> -    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1,
> 1))
> -        return -EPERM;
> -
>      addr = pci_dev_base(seg, bus, devfn);
>      if (!addr)
>          return -EINVAL;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:27:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkDf-0007Dz-Gr; Thu, 21 Jun 2012 16:26:55 +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 1ShkDd-0007Dm-Dz
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:26:53 +0000
Received: from [85.158.139.83:18189] by server-11.bemta-5.messagelabs.com id
	7B/C6-20400-C4B43EF4; Thu, 21 Jun 2012 16:26:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340296011!28871266!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17800 invoked from network); 21 Jun 2012 16:26:51 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:26:51 -0000
Received: by eaak12 with SMTP id k12so391333eaa.32
	for <xen-devel@lists.xen.org>; Thu, 21 Jun 2012 09:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=6Kn0EaUJxLijxuDI+MCakuj9ZDbBG9QX1wzMh28/e1w=;
	b=yAXjEh2Q2C2aE7bjnPLswD3jKV8/97qkM1W/GYiEUQjFbLStQrQk7glV0rMyOVVxvy
	0Tu7pkjNukCWgBjIRcPFL06WFGv4kJuPPRfgG4mKY1rwtH7QnXH/HC3WyAv5OehM2IPb
	enj18y/jqxCReXljG8uXEIrt5xLKna17x5J20GRhS8RxX3gykLzGf1GWLvKo2Qc0q8Iv
	lneVJkaoKDjocH59RF1eSFWcVLGoXKVZ/t84iwVsm8y5mgd6qC/r7oA39kWu400fGH1l
	YRJ9+socXnY1NMkxXm1xxwOwTLMXjy/A14SVpBM0fwfIFkvBKySy66PEX9igoRMK/gEA
	mYtQ==
Received: by 10.14.47.138 with SMTP id t10mr6071979eeb.133.1340296011503;
	Thu, 21 Jun 2012 09:26:51 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id a16sm104429733eeg.0.2012.06.21.09.26.50
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 09:26:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 21 Jun 2012 17:26:48 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC0909D8.363BB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86-64: revert mmconfig part of c/s
	24425:053a44894279
Thread-Index: Ac1PyqfASEgTtLCiOkSDK6NCflborg==
In-Reply-To: <4FE359F6020000780008B299@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH] x86-64: revert mmconfig part of c/s
 24425:053a44894279
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 16:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> These additions did not fulfill their purpose - they checked hypervisor
> config space accesses instead of guest (Dom0) ones.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> @@ -14,7 +14,6 @@
>  #include <xen/xmalloc.h>
>  #include <xen/pci.h>
>  #include <xen/pci_regs.h>
> -#include <xsm/xsm.h>
>  
>  #include "mmconfig.h"
>  
> @@ -59,7 +58,6 @@ int pci_mmcfg_read(unsigned int seg, uns
>                unsigned int devfn, int reg, int len, u32 *value)
>  {
>      char __iomem *addr;
> -    uint32_t mbdf;
>  
>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
>      if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
> @@ -67,12 +65,6 @@ err:        *value = -1;
>          return -EINVAL;
>      }
>  
> -    mbdf = (seg << 16) | (bus << 8) | devfn;
> -    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1,
> 0)) {
> -        *value = -1;
> -        return -EPERM;
> -    }
> -
>      addr = pci_dev_base(seg, bus, devfn);
>      if (!addr)
>          goto err;
> @@ -96,16 +88,11 @@ int pci_mmcfg_write(unsigned int seg, un
>                 unsigned int devfn, int reg, int len, u32 value)
>  {
>      char __iomem *addr;
> -    uint32_t mbdf;
>  
>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
>      if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
>          return -EINVAL;
>  
> -    mbdf = (seg << 16) | (bus << 8) | devfn;
> -    if (xsm_pci_config_permission(current->domain, mbdf, reg, reg + len - 1,
> 1))
> -        return -EPERM;
> -
>      addr = pci_dev_base(seg, bus, devfn);
>      if (!addr)
>          return -EINVAL;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:31:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkI8-0007Pc-70; Thu, 21 Jun 2012 16:31:32 +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 1ShkI5-0007PO-MX
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 16:31:30 +0000
Received: from [85.158.138.51:20024] by server-8.bemta-3.messagelabs.com id
	86/7A-06157-06C43EF4; Thu, 21 Jun 2012 16:31:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340296287!20723151!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20629 invoked from network); 21 Jun 2012 16:31:27 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:31:27 -0000
Received: by eaaa12 with SMTP id a12so643462eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 21 Jun 2012 09:31:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=wo45xSniEtW0niz5++bY61opbULCmMbkPlTKBTr8mE4=;
	b=pAVaG3Mc9MpXyynbbcWstDhHdtJHgdI1Ll5ltqafcsxKkminWl+F/ie6/iqmJA9JmJ
	xx9OD7SAwSlu9PAuEdl3bRrXJQOeEmbb6bJ+oSpkno0L7oorIw956kHcHIZsgDnKzNr5
	ArGSe8OWiiurgFTeCCYWw7z3dejw4ngahTpnaCKv7cYjqytzUKMmzg4+1WfTWOK0vScq
	fWKPFCF3ud2cHz8r5hn96q5hy6tbSpIkx7ZEDtKeqHRpeZx+GZW5NI4ij89BmPRoFILV
	b9nNwaoUPYHYvFmlBNrw7Sjs3NLI7LJ8KDGLIj33xZAtNKzQvkj44AFgRRC7O/7aF5Sf
	Uwxg==
Received: by 10.14.101.79 with SMTP id a55mr4978050eeg.32.1340296287317;
	Thu, 21 Jun 2012 09:31:27 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	c51sm104420590eei.12.2012.06.21.09.31.25
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 09:31:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 21 Jun 2012 17:31:20 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC090AE8.364B8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
	disabled it
Thread-Index: Ac1Py0ngnBn/MIC0vECPcRD2s1fFOA==
In-Reply-To: <4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/06/2012 16:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> the question now arises whether we really want this, and
> particularly this late before 4.2. The Linux folks don't seem to
> be willing to take the strait forward workaround for the
> problem introduced at their end, so we will likely need
> something (the more that the questionable fix already made
> it into various stable trees) before 4.2 goes out (and even
> the older trees would be affected, just that putting a change
> like this there is even more questionable).

I'd be okay seeing the proposed patch go in ahead of 4.2.0-rc1.

 -- Keir

> There are obviously more potential problems in this area: If
> any of the MMIO addresses used by AMD's IOMMU is
> configurable through one of the BARs, and if Dom0 decides to
> re-assign MMIO space, neither allowing the writes nor simply
> dropping them as done here will work. Whether that's a real
> problem I don't know - Wei? And there might be other issues
> arising from dropping all writes - we might just currently not be
> aware of them.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:31:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkI8-0007Pc-70; Thu, 21 Jun 2012 16:31:32 +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 1ShkI5-0007PO-MX
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 16:31:30 +0000
Received: from [85.158.138.51:20024] by server-8.bemta-3.messagelabs.com id
	86/7A-06157-06C43EF4; Thu, 21 Jun 2012 16:31:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340296287!20723151!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20629 invoked from network); 21 Jun 2012 16:31:27 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:31:27 -0000
Received: by eaaa12 with SMTP id a12so643462eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 21 Jun 2012 09:31:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=wo45xSniEtW0niz5++bY61opbULCmMbkPlTKBTr8mE4=;
	b=pAVaG3Mc9MpXyynbbcWstDhHdtJHgdI1Ll5ltqafcsxKkminWl+F/ie6/iqmJA9JmJ
	xx9OD7SAwSlu9PAuEdl3bRrXJQOeEmbb6bJ+oSpkno0L7oorIw956kHcHIZsgDnKzNr5
	ArGSe8OWiiurgFTeCCYWw7z3dejw4ngahTpnaCKv7cYjqytzUKMmzg4+1WfTWOK0vScq
	fWKPFCF3ud2cHz8r5hn96q5hy6tbSpIkx7ZEDtKeqHRpeZx+GZW5NI4ij89BmPRoFILV
	b9nNwaoUPYHYvFmlBNrw7Sjs3NLI7LJ8KDGLIj33xZAtNKzQvkj44AFgRRC7O/7aF5Sf
	Uwxg==
Received: by 10.14.101.79 with SMTP id a55mr4978050eeg.32.1340296287317;
	Thu, 21 Jun 2012 09:31:27 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	c51sm104420590eei.12.2012.06.21.09.31.25
	(version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 09:31:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 21 Jun 2012 17:31:20 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC090AE8.364B8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
	disabled it
Thread-Index: Ac1Py0ngnBn/MIC0vECPcRD2s1fFOA==
In-Reply-To: <4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <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 V2] amd iommu: re-enable iommu msi if dom0
 disabled it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/06/2012 16:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> the question now arises whether we really want this, and
> particularly this late before 4.2. The Linux folks don't seem to
> be willing to take the strait forward workaround for the
> problem introduced at their end, so we will likely need
> something (the more that the questionable fix already made
> it into various stable trees) before 4.2 goes out (and even
> the older trees would be affected, just that putting a change
> like this there is even more questionable).

I'd be okay seeing the proposed patch go in ahead of 4.2.0-rc1.

 -- Keir

> There are obviously more potential problems in this area: If
> any of the MMIO addresses used by AMD's IOMMU is
> configurable through one of the BARs, and if Dom0 decides to
> re-assign MMIO space, neither allowing the writes nor simply
> dropping them as done here will work. Whether that's a real
> problem I don't know - Wei? And there might be other issues
> arising from dropping all writes - we might just currently not be
> aware of them.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 16:34:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkKs-0007b1-Pg; Thu, 21 Jun 2012 16:34:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShkKr-0007at-3Z
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:34:21 +0000
Received: from [85.158.143.35:63157] by server-1.bemta-4.messagelabs.com id
	81/CB-24392-C0D43EF4; Thu, 21 Jun 2012 16:34:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340296458!5569412!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6008 invoked from network); 21 Jun 2012 16:34:18 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 16:34:18 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79047437; Thu, 21 Jun 2012 18:34:18 +0200
Message-ID: <1340296452.4856.87.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 18:34:12 +0200
In-Reply-To: <1340278832.21872.112.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4221436308183304941=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4221436308183304941==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-TmAEWxlzJjZEf48v6cyw"


--=-TmAEWxlzJjZEf48v6cyw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 12:40 +0100, Ian Campbell wrote:
> > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -111,8 +111,8 @@ created online and the remainder will be
> >=20
> >  =3Ditem B<cpus=3D"CPU-LIST">
> >=20
> > -List of which cpus the guest is allowed to use. Default behavior is
>=20
> There is (according to grep) a slight preference for British spelling,
> but I imagine we are totally inconsistent all over the place so lets not
> worry too much ;-)
>=20
Especially considering I'm removing it! :-P (However, I'm sure it was me
that put that line in some time ago, so I'll make a note about
this! :-D).

> > @@ -132,6 +132,12 @@ run on cpu #3 of the host.
> >=20
> >  =3Dback
> >=20
> > +If this option is not specified, libxl automatically tries to place th=
e new
> > +domain on the host's NUMA nodes (provided the host has more than one N=
UMA
> > +node) by pinning it to the cpus of those nodes. An heuristical approac=
h is
>=20
> I don't think heuristical is a word, I think "A heuristic approach..."
> is fine
>=20
Fixed (with "A heuristic approach"). Thanks.

> > + * the same instance of the iterator and the same values for
> > + * n and k are used for each call. If that doesn't happen, the
> > + * result is unspecified.
> > + *
> > + * The algorithm is a well known one,
>=20
> Worth a link/reference?
>=20
As you like... The general idea is described, for example, in this
Wikipedia page http://en.wikipedia.org/wiki/Combination , the actual
algorithm appeared, for instance, in D. Knuth's "The Art of Computer
Programming - Volume 4, Fascicle 3", but in many other places as well. I
guess I can cite TAOCP, although I'm not sure it is actually the first,
and thus the one who should be credited for this... But I guess that
doesn't matter too much, does it?

> > + *
> > + * For example, with n =3D 5 and k =3D 3, calling comb_init()
> > + * will generate { 0, 1, 2 }, while subsequent valid calls to
> > + * comb_next() will produce the following:
> > + * { { 0, 1, 2 }, { 0, 1, 3 }, { 0, 1, 4 },
>=20
>                 ^ strictly speaking this 0,1,2 isn't produced by a call
>                 to comb_next since it came from the initial comb_init,
>                 right?=20
Yes, that's right.

> IOW the first comb_next() call won't duplicate
>                 it...
>=20
No, it won't. I'll fix this in the comment.

> I'm not going to try very hard to review the algorithm here, I trust you
> and I've got a head cold ;-)
>=20
Fine. :-)

> > +/* NUMA automatic placement (see libxl_internal.h for details) */
> > +
> > +/*
> > + * This function turns a k-combination iterator into a node map.
> > + * This means the bits in the node map corresponding to the indexes
> > + * of the given combination are the ones that will be set.
> > + * For example, if the iterator represents the combination { 0, 2, 4},
> > + * the node map will have bits #0, #2 and #4 set to one and i thus
> > + * will point to node 0, node 2 and and node 4.
>=20
> What is "i" in this last bit ("i thus will point to")? I don't think you
> are referring to the loop iterator variable.
>=20
> If you meant "it" then I don't think it needs saying that a node map
> with bits 0, 2 and 4 set refers to nodes 0, 2 and 4.
>=20
It was actually "it", and I'm happy to kill that part of the sentence.

> > +/* Retrieve the number of cpus that the nodes that are part of the nod=
emap
> > + * span. */
> > +static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus=
,
> > +                                 const libxl_bitmap *nodemap)
>=20
> nodes here =3D=3D node's ? But can't have an apostrophe in a function whi=
ch
> makes it ready weird to me. Perhaps "nodemap_count_cpus"?
>=20
Right. I wanted to stick to the nodemap_to_xxx() for those group of
function, so I changed this one into "nodemap_to_nr_cpus()". Hope it is
fine...

> > +/* Retrieve the number of domains that can potentially run on the cpus
> > + * the nodes that are part of the nodemap. */
> > +static int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tin=
fo,
> > +                                 const libxl_bitmap *nodemap)
> > +{
> > +    libxl_dominfo *dinfo =3D NULL;
> > +    libxl_bitmap dom_nodemap;
> > +    int nr_doms, nr_cpus;
> > +    int nr_domains =3D 0;
> > +    int i, j, k;
> > +
> > +    dinfo =3D libxl_list_domain(CTX, &nr_doms);
> > +    if (dinfo =3D=3D NULL)
> > +        return ERROR_FAIL;
> > +
> > +    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap) < 0) {
> > +        nr_domains =3D ERROR_FAIL;
> > +        goto out;
> > +    }
> > +
> > +    for (i =3D 0; i < nr_doms; i++) {
> > +        libxl_vcpuinfo *vinfo;
> > +        int nr_vcpus;
> > +
> > +        vinfo =3D libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_=
cpus);
> > +        if (vinfo =3D=3D NULL)
> > +            continue;
> > +
> > +        libxl_bitmap_set_none(&dom_nodemap);
> > +        for (j =3D 0; j < nr_vcpus; j++) {
> > +            libxl_for_each_set_bit(k, vinfo[j].cpumap)
> > +                libxl_bitmap_set(&dom_nodemap, tinfo[k].node);
> > +        }
> > +
> > +        libxl_for_each_set_bit(j, dom_nodemap) {
> > +            if (libxl_bitmap_test(nodemap, j)) {
> > +                nr_domains++;
> > +                goto found;
>=20
> AKA break?
>=20
Yes. Leftover from v1, which I forgot to adapt.
> > +            }
> > +        }
> > + found:
> > +        libxl_vcpuinfo_list_free(vinfo, nr_vcpus);
> > +    }
> > +
> > + out:
> > +    libxl_bitmap_dispose(&dom_nodemap);
>=20
> You can come to out if libxl_nodebitmap_alloc fails -- in which case
> dom_nodemap is (potentially) uninitialised.
>
> You could just move out: down a line.
>=20
Right. As I did not really like that "nr_domains =3D ERROR_FAIL" I changed
the error handling style of this function as a whole so that now I do
not need the out: label any more.

> > +/*
> > + * This function tries to figure out if the host has a consistent numb=
er
> > + * of cpus along all its NUMA nodes. In fact, if that is the case, we =
can
> > + * calculate the minimum number of nodes needed for a domain by just
> > + * dividing its total number of vcpus by this value computed here.
> > + * However, we are not allowed to assume that all the nodes have the
> > + * same number of cpus. Therefore, in case discrepancies among differe=
nt
> > + * nodes are found, this function just returns 0 and the caller needs
> > + * to sort out things in some other way.
>=20
> If the caller has to deal with this anyway why bother with this check
> and/or the other algorithm?
>=20
Mmm... I'm not sure I get what you mean here. Perhaps my commenting
about the whole thing was not so clear in the first place.

The (George's :-)) idea is, if we know each node has 8 CPUs, and our
domain wants more than that, it does not make sense to start looking for
placement solutions with just one node. Actually, if the domain wants
fewer than 16 CPUs, starting looking from solutions with 2 nodes in them
should be the right thing.

That being said, I think it's important we do not assume we won't ever
find some architecture with different number of CPUs in different nodes,
and that is what a zero return from that function means.

What was that you thought not to be worthwhile?

> > +/* Get all the placement candidates satisfying some specific condition=
s */
> > +int libxl__get_numa_candidates(libxl__gc *gc,
> > +                               uint32_t min_free_memkb, int min_cpus,
> > +                               int min_nodes, int max_nodes,
> > +                               libxl__numa_candidate *cndts[], int *nr=
_cndts)
> > +{
> > +    libxl__numa_candidate *new_cndts =3D NULL;
> > +    libxl_cputopology *tinfo =3D NULL;
> > +    libxl_numainfo *ninfo =3D NULL;
> > +    libxl_bitmap nodemap;
> > +    int nr_nodes, nr_cpus;
> > +    int array_size, rc;
> > +
> > +    /* Get platform info and prepare the map for testing the combinati=
ons */
> > +    ninfo =3D libxl_get_numainfo(CTX, &nr_nodes);
> > +    if (ninfo =3D=3D NULL)
> > +        return ERROR_FAIL;
> > +    /* If we don't have at least 2 nodes, it is useless to proceed */
>=20
> You don't want to return whichever of those 2 nodes meets the
> constraints?
>=20
I actually was meaning something like "hey, there's only _1_ node, go
for it!" :-P

> ...
> > +    *cndts =3D new_cndts;
> > + out:
> > +    libxl_bitmap_dispose(&nodemap);
>=20
> nodemap might not have been initialised?
>
Mmm... Right. So I really think I need an init function. :-(

> > +    libxl_cputopology_list_free(tinfo, nr_cpus);
> > +    libxl_numainfo_list_free(ninfo, nr_nodes);
>=20
> It looks like the nr_* may also not have been initialised, but maybe
> list_free is safe in that case since the associated array must
> necessarily be NULL?
>=20
Well, probably, but as they both do a "for (i=3D0;i<nr_*;i++)" I think
it's safer if I "=3D0" those twos, is that ok?

> > +/*
> > + * The NUMA placement candidates are reordered according to the follow=
ing
> > + * heuristics:
> > + *  - candidates involving fewer nodes come first. In case two (or
> > + *    more) candidates span the same number of nodes,
> > + *  - candidates with greater amount of free memory come first. In
> > + *    case two (or more) candidates differ in their amount of free
> > + *    memory by less than 10%,
> > + *  - candidates with fewer domains insisting on them at the time of
> > + *    this call come first.
> > + */
> > +static int numa_cmpf(const void *v1, const void *v2)
> > +{
> > +    const libxl__numa_candidate *c1 =3D (const libxl__numa_candidate*)=
 v1;
> > +    const libxl__numa_candidate *c2 =3D (const libxl__numa_candidate*)=
 v2;
>=20
> Are these casts necessary?
>=20
Will check and remove if not. Thanks.

> > +    double mem_diff =3D labs(c1->free_memkb - c2->free_memkb);
> > +    double mem_avg =3D (c1->free_memkb + c2->free_memkb) / 2.0;
> > +
> > +    if (c1->nr_nodes !=3D c2->nr_nodes)
> > +        return c1->nr_nodes - c2->nr_nodes;
> > +
> > +    if ((mem_diff / mem_avg) * 100.0 < 10.0 &&
>=20
> Is all this FP math necessary? Using integers might have some rounding
> but is it significant or do we care if it gets it slightly wrong?
>=20
I think integer is fine... It's heuristics, after all. I'll go for it.

> > +/* The actual automatic NUMA placement routine */
> > +static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *i=
nfo)
> > +{
> > +    int nr_candidates =3D 0;
> > +    libxl__numa_candidate *candidates =3D NULL;
> > +    libxl_bitmap candidate_nodemap;
> > +    libxl_cpupoolinfo *pinfo;
> > +    int nr_pools, rc =3D 0;
> > +    uint32_t memkb;
> > +
> > +    /* First of all, if cpupools are in use, better not to mess with t=
hem */
> > +    pinfo =3D libxl_list_cpupool(CTX, &nr_pools);
> > +    if (!pinfo)
> > +        return ERROR_FAIL;
> > +    if (nr_pools > 1) {
> > +        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
> > +        goto out;
> > +    }
> > +
> > +    rc =3D libxl_domain_need_memory(CTX, info, &memkb);
> > +    if (rc)
> > +        goto out;
> > +    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) {
> > +        rc =3D ERROR_FAIL;
> > +        goto out;
> > +    }
> > +
> > +    /* Find all the candidates with enough free memory and at least
> > +     * as much pcpus as the domain has vcpus.  */
> > +    rc =3D libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0=
,
> > +                                    &candidates, &nr_candidates);
> > +    if (rc)
> > +        goto out;
> > +
> > +    LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates);
> > +
> > +    /* No suitable placement candidates. We just return without touchi=
ng the
> > +     * domain's info->cpumap. It will have affinity with all nodes/cpu=
s. */
> > +    if (nr_candidates =3D=3D 0)
> > +        goto out;
> > +
> > +    /* Bring the best candidate in front of the list --> candidates[0]=
 */
> > +    if (nr_candidates > 1)
> > +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cm=
pf);
>=20
> Is the start up cost of libxl__sort_numa_candidates significant enough
> to make that if worthwhile?
>=20
I'm not sure what you mean here, I'm afraid ... :-(

> > +
> > +    /*
> > +     * 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 does not, it just leaves=
 it
> > +     * as it is. This means (unless some weird error manifests) the su=
bsequent
> > +     * call to libxl_set_vcpuaffinity_all() will do the actual placeme=
nt,
> > +     * whatever that turns out to be.
> > +     */
> > +    if (libxl_bitmap_is_full(&info->cpumap)) {
> > +        int rc =3D numa_place_domain(gc, info);
> > +        if (rc)
> > +            return rc;
>=20
> I'm not sure about this, if numa_place_domain fails for any reason would
> we be not better off logging and continuing without placement? We
> already do that explicitly in a couple of cases.
>=20
Well, actually, if it "fails" in the sense it finds no candidates or
does not manage in placing the domain, it returns 0, so we do right what
you're suggesting. I'm sure this is stated in some comment but I guess I
can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
something, which I think has to be handled like this, hasn't it?

Perhaps I can also add some logging about "successfully failing", i.e.,
not getting into any error but not being able to place the domain. If
yes, that will happen _inside_ numa_place_domain() rather than here.

> > + * dynamically computed. A candidate can consist of just one, up to al=
l the
> > + * available nodes on the host (the latter being, of course, not ideal=
).
>=20
> I can't parse this sentence.
>=20
Sorry. I just meant a placement candidate is a set of nodes, so it can
be one node, four nodes, or even comprise all the available nodes.

> > +/* signature for the comparison function between two candidates c1 and=
 c2
> > + * (the thid parameter is provided to enable thread safety). */
>=20
>            third
>=20
> But there isn't actually a third parameter so it's a bit moot ;-)
>=20
> > +typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *=
v2);
>
You're right. That is a leftover from where I was trying to use
qsort_r() for sorting, but it turned out to not be necessary in this
case. Killed.

Thanks again and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-TmAEWxlzJjZEf48v6cyw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jTQQACgkQk4XaBE3IOsR2dgCgpGgoHPFcFLRDHvx/WWFgM+/U
fvcAmgO39rzfgPDoFjdGiNfKN2O+lmgZ
=jydB
-----END PGP SIGNATURE-----

--=-TmAEWxlzJjZEf48v6cyw--



--===============4221436308183304941==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4221436308183304941==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 16:34:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16: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 1ShkKs-0007b1-Pg; Thu, 21 Jun 2012 16:34:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShkKr-0007at-3Z
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:34:21 +0000
Received: from [85.158.143.35:63157] by server-1.bemta-4.messagelabs.com id
	81/CB-24392-C0D43EF4; Thu, 21 Jun 2012 16:34:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340296458!5569412!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6008 invoked from network); 21 Jun 2012 16:34:18 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	21 Jun 2012 16:34:18 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79047437; Thu, 21 Jun 2012 18:34:18 +0200
Message-ID: <1340296452.4856.87.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 21 Jun 2012 18:34:12 +0200
In-Reply-To: <1340278832.21872.112.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4221436308183304941=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4221436308183304941==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-TmAEWxlzJjZEf48v6cyw"


--=-TmAEWxlzJjZEf48v6cyw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 12:40 +0100, Ian Campbell wrote:
> > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -111,8 +111,8 @@ created online and the remainder will be
> >=20
> >  =3Ditem B<cpus=3D"CPU-LIST">
> >=20
> > -List of which cpus the guest is allowed to use. Default behavior is
>=20
> There is (according to grep) a slight preference for British spelling,
> but I imagine we are totally inconsistent all over the place so lets not
> worry too much ;-)
>=20
Especially considering I'm removing it! :-P (However, I'm sure it was me
that put that line in some time ago, so I'll make a note about
this! :-D).

> > @@ -132,6 +132,12 @@ run on cpu #3 of the host.
> >=20
> >  =3Dback
> >=20
> > +If this option is not specified, libxl automatically tries to place th=
e new
> > +domain on the host's NUMA nodes (provided the host has more than one N=
UMA
> > +node) by pinning it to the cpus of those nodes. An heuristical approac=
h is
>=20
> I don't think heuristical is a word, I think "A heuristic approach..."
> is fine
>=20
Fixed (with "A heuristic approach"). Thanks.

> > + * the same instance of the iterator and the same values for
> > + * n and k are used for each call. If that doesn't happen, the
> > + * result is unspecified.
> > + *
> > + * The algorithm is a well known one,
>=20
> Worth a link/reference?
>=20
As you like... The general idea is described, for example, in this
Wikipedia page http://en.wikipedia.org/wiki/Combination , the actual
algorithm appeared, for instance, in D. Knuth's "The Art of Computer
Programming - Volume 4, Fascicle 3", but in many other places as well. I
guess I can cite TAOCP, although I'm not sure it is actually the first,
and thus the one who should be credited for this... But I guess that
doesn't matter too much, does it?

> > + *
> > + * For example, with n =3D 5 and k =3D 3, calling comb_init()
> > + * will generate { 0, 1, 2 }, while subsequent valid calls to
> > + * comb_next() will produce the following:
> > + * { { 0, 1, 2 }, { 0, 1, 3 }, { 0, 1, 4 },
>=20
>                 ^ strictly speaking this 0,1,2 isn't produced by a call
>                 to comb_next since it came from the initial comb_init,
>                 right?=20
Yes, that's right.

> IOW the first comb_next() call won't duplicate
>                 it...
>=20
No, it won't. I'll fix this in the comment.

> I'm not going to try very hard to review the algorithm here, I trust you
> and I've got a head cold ;-)
>=20
Fine. :-)

> > +/* NUMA automatic placement (see libxl_internal.h for details) */
> > +
> > +/*
> > + * This function turns a k-combination iterator into a node map.
> > + * This means the bits in the node map corresponding to the indexes
> > + * of the given combination are the ones that will be set.
> > + * For example, if the iterator represents the combination { 0, 2, 4},
> > + * the node map will have bits #0, #2 and #4 set to one and i thus
> > + * will point to node 0, node 2 and and node 4.
>=20
> What is "i" in this last bit ("i thus will point to")? I don't think you
> are referring to the loop iterator variable.
>=20
> If you meant "it" then I don't think it needs saying that a node map
> with bits 0, 2 and 4 set refers to nodes 0, 2 and 4.
>=20
It was actually "it", and I'm happy to kill that part of the sentence.

> > +/* Retrieve the number of cpus that the nodes that are part of the nod=
emap
> > + * span. */
> > +static int nodemap_to_nodes_cpus(libxl_cputopology *tinfo, int nr_cpus=
,
> > +                                 const libxl_bitmap *nodemap)
>=20
> nodes here =3D=3D node's ? But can't have an apostrophe in a function whi=
ch
> makes it ready weird to me. Perhaps "nodemap_count_cpus"?
>=20
Right. I wanted to stick to the nodemap_to_xxx() for those group of
function, so I changed this one into "nodemap_to_nr_cpus()". Hope it is
fine...

> > +/* Retrieve the number of domains that can potentially run on the cpus
> > + * the nodes that are part of the nodemap. */
> > +static int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tin=
fo,
> > +                                 const libxl_bitmap *nodemap)
> > +{
> > +    libxl_dominfo *dinfo =3D NULL;
> > +    libxl_bitmap dom_nodemap;
> > +    int nr_doms, nr_cpus;
> > +    int nr_domains =3D 0;
> > +    int i, j, k;
> > +
> > +    dinfo =3D libxl_list_domain(CTX, &nr_doms);
> > +    if (dinfo =3D=3D NULL)
> > +        return ERROR_FAIL;
> > +
> > +    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap) < 0) {
> > +        nr_domains =3D ERROR_FAIL;
> > +        goto out;
> > +    }
> > +
> > +    for (i =3D 0; i < nr_doms; i++) {
> > +        libxl_vcpuinfo *vinfo;
> > +        int nr_vcpus;
> > +
> > +        vinfo =3D libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_=
cpus);
> > +        if (vinfo =3D=3D NULL)
> > +            continue;
> > +
> > +        libxl_bitmap_set_none(&dom_nodemap);
> > +        for (j =3D 0; j < nr_vcpus; j++) {
> > +            libxl_for_each_set_bit(k, vinfo[j].cpumap)
> > +                libxl_bitmap_set(&dom_nodemap, tinfo[k].node);
> > +        }
> > +
> > +        libxl_for_each_set_bit(j, dom_nodemap) {
> > +            if (libxl_bitmap_test(nodemap, j)) {
> > +                nr_domains++;
> > +                goto found;
>=20
> AKA break?
>=20
Yes. Leftover from v1, which I forgot to adapt.
> > +            }
> > +        }
> > + found:
> > +        libxl_vcpuinfo_list_free(vinfo, nr_vcpus);
> > +    }
> > +
> > + out:
> > +    libxl_bitmap_dispose(&dom_nodemap);
>=20
> You can come to out if libxl_nodebitmap_alloc fails -- in which case
> dom_nodemap is (potentially) uninitialised.
>
> You could just move out: down a line.
>=20
Right. As I did not really like that "nr_domains =3D ERROR_FAIL" I changed
the error handling style of this function as a whole so that now I do
not need the out: label any more.

> > +/*
> > + * This function tries to figure out if the host has a consistent numb=
er
> > + * of cpus along all its NUMA nodes. In fact, if that is the case, we =
can
> > + * calculate the minimum number of nodes needed for a domain by just
> > + * dividing its total number of vcpus by this value computed here.
> > + * However, we are not allowed to assume that all the nodes have the
> > + * same number of cpus. Therefore, in case discrepancies among differe=
nt
> > + * nodes are found, this function just returns 0 and the caller needs
> > + * to sort out things in some other way.
>=20
> If the caller has to deal with this anyway why bother with this check
> and/or the other algorithm?
>=20
Mmm... I'm not sure I get what you mean here. Perhaps my commenting
about the whole thing was not so clear in the first place.

The (George's :-)) idea is, if we know each node has 8 CPUs, and our
domain wants more than that, it does not make sense to start looking for
placement solutions with just one node. Actually, if the domain wants
fewer than 16 CPUs, starting looking from solutions with 2 nodes in them
should be the right thing.

That being said, I think it's important we do not assume we won't ever
find some architecture with different number of CPUs in different nodes,
and that is what a zero return from that function means.

What was that you thought not to be worthwhile?

> > +/* Get all the placement candidates satisfying some specific condition=
s */
> > +int libxl__get_numa_candidates(libxl__gc *gc,
> > +                               uint32_t min_free_memkb, int min_cpus,
> > +                               int min_nodes, int max_nodes,
> > +                               libxl__numa_candidate *cndts[], int *nr=
_cndts)
> > +{
> > +    libxl__numa_candidate *new_cndts =3D NULL;
> > +    libxl_cputopology *tinfo =3D NULL;
> > +    libxl_numainfo *ninfo =3D NULL;
> > +    libxl_bitmap nodemap;
> > +    int nr_nodes, nr_cpus;
> > +    int array_size, rc;
> > +
> > +    /* Get platform info and prepare the map for testing the combinati=
ons */
> > +    ninfo =3D libxl_get_numainfo(CTX, &nr_nodes);
> > +    if (ninfo =3D=3D NULL)
> > +        return ERROR_FAIL;
> > +    /* If we don't have at least 2 nodes, it is useless to proceed */
>=20
> You don't want to return whichever of those 2 nodes meets the
> constraints?
>=20
I actually was meaning something like "hey, there's only _1_ node, go
for it!" :-P

> ...
> > +    *cndts =3D new_cndts;
> > + out:
> > +    libxl_bitmap_dispose(&nodemap);
>=20
> nodemap might not have been initialised?
>
Mmm... Right. So I really think I need an init function. :-(

> > +    libxl_cputopology_list_free(tinfo, nr_cpus);
> > +    libxl_numainfo_list_free(ninfo, nr_nodes);
>=20
> It looks like the nr_* may also not have been initialised, but maybe
> list_free is safe in that case since the associated array must
> necessarily be NULL?
>=20
Well, probably, but as they both do a "for (i=3D0;i<nr_*;i++)" I think
it's safer if I "=3D0" those twos, is that ok?

> > +/*
> > + * The NUMA placement candidates are reordered according to the follow=
ing
> > + * heuristics:
> > + *  - candidates involving fewer nodes come first. In case two (or
> > + *    more) candidates span the same number of nodes,
> > + *  - candidates with greater amount of free memory come first. In
> > + *    case two (or more) candidates differ in their amount of free
> > + *    memory by less than 10%,
> > + *  - candidates with fewer domains insisting on them at the time of
> > + *    this call come first.
> > + */
> > +static int numa_cmpf(const void *v1, const void *v2)
> > +{
> > +    const libxl__numa_candidate *c1 =3D (const libxl__numa_candidate*)=
 v1;
> > +    const libxl__numa_candidate *c2 =3D (const libxl__numa_candidate*)=
 v2;
>=20
> Are these casts necessary?
>=20
Will check and remove if not. Thanks.

> > +    double mem_diff =3D labs(c1->free_memkb - c2->free_memkb);
> > +    double mem_avg =3D (c1->free_memkb + c2->free_memkb) / 2.0;
> > +
> > +    if (c1->nr_nodes !=3D c2->nr_nodes)
> > +        return c1->nr_nodes - c2->nr_nodes;
> > +
> > +    if ((mem_diff / mem_avg) * 100.0 < 10.0 &&
>=20
> Is all this FP math necessary? Using integers might have some rounding
> but is it significant or do we care if it gets it slightly wrong?
>=20
I think integer is fine... It's heuristics, after all. I'll go for it.

> > +/* The actual automatic NUMA placement routine */
> > +static int numa_place_domain(libxl__gc *gc, libxl_domain_build_info *i=
nfo)
> > +{
> > +    int nr_candidates =3D 0;
> > +    libxl__numa_candidate *candidates =3D NULL;
> > +    libxl_bitmap candidate_nodemap;
> > +    libxl_cpupoolinfo *pinfo;
> > +    int nr_pools, rc =3D 0;
> > +    uint32_t memkb;
> > +
> > +    /* First of all, if cpupools are in use, better not to mess with t=
hem */
> > +    pinfo =3D libxl_list_cpupool(CTX, &nr_pools);
> > +    if (!pinfo)
> > +        return ERROR_FAIL;
> > +    if (nr_pools > 1) {
> > +        LOG(NOTICE, "skipping NUMA placement as cpupools are in use");
> > +        goto out;
> > +    }
> > +
> > +    rc =3D libxl_domain_need_memory(CTX, info, &memkb);
> > +    if (rc)
> > +        goto out;
> > +    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) {
> > +        rc =3D ERROR_FAIL;
> > +        goto out;
> > +    }
> > +
> > +    /* Find all the candidates with enough free memory and at least
> > +     * as much pcpus as the domain has vcpus.  */
> > +    rc =3D libxl__get_numa_candidates(gc, memkb, info->max_vcpus, 0, 0=
,
> > +                                    &candidates, &nr_candidates);
> > +    if (rc)
> > +        goto out;
> > +
> > +    LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates);
> > +
> > +    /* No suitable placement candidates. We just return without touchi=
ng the
> > +     * domain's info->cpumap. It will have affinity with all nodes/cpu=
s. */
> > +    if (nr_candidates =3D=3D 0)
> > +        goto out;
> > +
> > +    /* Bring the best candidate in front of the list --> candidates[0]=
 */
> > +    if (nr_candidates > 1)
> > +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cm=
pf);
>=20
> Is the start up cost of libxl__sort_numa_candidates significant enough
> to make that if worthwhile?
>=20
I'm not sure what you mean here, I'm afraid ... :-(

> > +
> > +    /*
> > +     * 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 does not, it just leaves=
 it
> > +     * as it is. This means (unless some weird error manifests) the su=
bsequent
> > +     * call to libxl_set_vcpuaffinity_all() will do the actual placeme=
nt,
> > +     * whatever that turns out to be.
> > +     */
> > +    if (libxl_bitmap_is_full(&info->cpumap)) {
> > +        int rc =3D numa_place_domain(gc, info);
> > +        if (rc)
> > +            return rc;
>=20
> I'm not sure about this, if numa_place_domain fails for any reason would
> we be not better off logging and continuing without placement? We
> already do that explicitly in a couple of cases.
>=20
Well, actually, if it "fails" in the sense it finds no candidates or
does not manage in placing the domain, it returns 0, so we do right what
you're suggesting. I'm sure this is stated in some comment but I guess I
can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
something, which I think has to be handled like this, hasn't it?

Perhaps I can also add some logging about "successfully failing", i.e.,
not getting into any error but not being able to place the domain. If
yes, that will happen _inside_ numa_place_domain() rather than here.

> > + * dynamically computed. A candidate can consist of just one, up to al=
l the
> > + * available nodes on the host (the latter being, of course, not ideal=
).
>=20
> I can't parse this sentence.
>=20
Sorry. I just meant a placement candidate is a set of nodes, so it can
be one node, four nodes, or even comprise all the available nodes.

> > +/* signature for the comparison function between two candidates c1 and=
 c2
> > + * (the thid parameter is provided to enable thread safety). */
>=20
>            third
>=20
> But there isn't actually a third parameter so it's a bit moot ;-)
>=20
> > +typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *=
v2);
>
You're right. That is a leftover from where I was trying to use
qsort_r() for sorting, but it turned out to not be necessary in this
case. Killed.

Thanks again and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-TmAEWxlzJjZEf48v6cyw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jTQQACgkQk4XaBE3IOsR2dgCgpGgoHPFcFLRDHvx/WWFgM+/U
fvcAmgO39rzfgPDoFjdGiNfKN2O+lmgZ
=jydB
-----END PGP SIGNATURE-----

--=-TmAEWxlzJjZEf48v6cyw--



--===============4221436308183304941==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4221436308183304941==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 16:43:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16:43: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 1ShkTH-0007ou-Qo; Thu, 21 Jun 2012 16:43: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 1ShkTF-0007oj-T0
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 16:43:02 +0000
Received: from [85.158.139.83:9680] by server-6.bemta-5.messagelabs.com id
	AF/A8-11348-F0F43EF4; Thu, 21 Jun 2012 16:42:55 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340296974!28326941!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23768 invoked from network); 21 Jun 2012 16:42:54 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:42:54 -0000
Received: by eaaa12 with SMTP id a12so650391eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 21 Jun 2012 09:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Y4rIuPz/zffJBVDjuJOgwf021FMdvHEKFK3CzGyvYxg=;
	b=onKzCN/jKOG5Fawnn+hmoEKq7InTMuG+/xXqqNXkE9mxh2vCc5pi6dQi8pXTFUy6xM
	nkdH9QeehI0L3fwb/AwBDXDamCzCyCPZCLqa4/FCNrkkNEMSZEc4XewNgaqqXZVYpwMm
	lQvzXL3xf60FoFtID12clwpR8rWRQKNvdBkbFSgY4OV6rH244xEK92ZXPwiVyr13dLxP
	J/gnnTwBW7nAljEdEZ2w96mCw6TAt+/ODhDu8MkUf27X9rT0KbWRQN/bUKuY/c6BWNjB
	qi51rOqDdo9qZ2gF9Bx6Go3zh3oyfcO05Og2WbKz5DHcdPxQAaijuXN1I+jeUMU6CTFL
	yr+A==
MIME-Version: 1.0
Received: by 10.14.119.73 with SMTP id m49mr5609206eeh.187.1340296973790; Thu,
	21 Jun 2012 09:42:53 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Thu, 21 Jun 2012 09:42:53 -0700 (PDT)
In-Reply-To: <1340193230.4906.45.camel@zakaz.uk.xensource.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<1340193230.4906.45.camel@zakaz.uk.xensource.com>
Date: Thu, 21 Jun 2012 12:42:53 -0400
Message-ID: <CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My mistake, I should have given more detail. I have included all the
necessary details in this email. I used network-bridge for creating
bridge in netback-domU and dom0 uses the same script on bootup. While
I think vif-bridge is used in both dom0 and netback-domU for hotplug
script.

The network configuration of netback-domU is

vif =3D ['mac=3D00:16:3e:00:00:94, bridge=3Deth0, ip=3D135.207.223.70']

while for other-domU is

vif =3D ['mac=3D00:16:3e:00:00:96, bridge=3Deth0, ip=3D135.207.223.71,
backend=3Dtest-domU-SD']

Detail of Dom0:
-----------------
-bash-3.2# xenstore-ls
local =3D ""
 domain =3D ""
  0 =3D ""
   backend =3D ""
    vif =3D ""
     1 =3D ""
      0 =3D ""
       bridge =3D "eth0"
       domain =3D "test-domU-SD"
       handle =3D "0"
       uuid =3D "d9f2c904-becd-9bcc-fa4f-4c9a800e585a"
       script =3D "/etc/xen/scripts/vif-bridge"
       ip =3D "135.207.223.70"
       state =3D "4"
       frontend =3D "/local/domain/1/device/vif/0"
       mac =3D "00:16:3e:00:00:94"
       online =3D "1"
       frontend-id =3D "1"
       feature-sg =3D "1"
       feature-gso-tcpv4 =3D "1"
       feature-rx-copy =3D "1"
       hotplug-status =3D "connected"
--------
  1 =3D ""
   device =3D ""
    vif =3D ""
     0 =3D ""
      mac =3D "00:16:3e:00:00:94"
      handle =3D "0"
      protocol =3D "x86_64-abi"
      backend-id =3D "0"
      state =3D "4"
      backend =3D "/local/domain/0/backend/vif/1/0"
      tx-ring-ref =3D "768"
      rx-ring-ref =3D "769"
      event-channel =3D "11"
      request-rx-copy =3D "0"
      feature-rx-notify =3D "1"
      feature-no-csum-offload =3D "0"
      feature-sg =3D "1"
      feature-gso-tcpv4 =3D "1"
   backend =3D ""
    vif =3D ""
     2 =3D ""
      0 =3D ""
       bridge =3D "eth0"
       domain =3D "test-domU"
       handle =3D "0"
       uuid =3D "2314d790-5223-cf26-59b2-1c0d6d053fe0"
       script =3D "/etc/xen/scripts/vif-bridge"
       ip =3D "135.207.223.71"
       state =3D "4"
       frontend =3D "/local/domain/2/device/vif/0"
       mac =3D "00:16:3e:00:00:96"
       online =3D "1"
       frontend-id =3D "2"
       feature-sg =3D "1"
       feature-gso-tcpv4 =3D "1"
       feature-rx-copy =3D "1"
       feature-rx-flip =3D "0"
       hotplug-status =3D "connected"
-------
  2 =3D ""
   device =3D ""
    vif =3D ""
     0 =3D ""
      mac =3D "00:16:3e:00:00:96"
      handle =3D "0"
      protocol =3D "x86_64-abi"
      backend-id =3D "1"
      state =3D "4"
      backend =3D "/local/domain/1/backend/vif/2/0"
      tx-ring-ref =3D "768"
      rx-ring-ref =3D "769"
      event-channel =3D "11"
      request-rx-copy =3D "1"
      feature-rx-notify =3D "1"
      feature-no-csum-offload =3D "0"
      feature-sg =3D "1"
      feature-gso-tcpv4 =3D "1"

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
eth0		8000.00219b9006ec	no		peth0
            							vif1.0
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:21:9b:90:06:ec
          inet addr:135.207.223.69  Bcast:135.207.223.255  Mask:255.255.255=
.0
          inet6 addr: fe80::221:9bff:fe90:6ec/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10596 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2707 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:776291 (758.0 KiB)  TX bytes:439416 (429.1 KiB)

lo ---

peth0     Link encap:Ethernet  HWaddr 00:21:9b:90:06:ec
          inet6 addr: fe80::221:9bff:fe90:6ec/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11737 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2851 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1046046 (1021.5 KiB)  TX bytes:465670 (454.7 KiB)
          Interrupt:18 Memory:d6000000-d6012800

veth0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif0.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif1.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:146 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4460 errors:0 dropped:33 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:11978 (11.6 KiB)  TX bytes:401242 (391.8 KiB)


Detail of netback-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
          inet addr:135.207.223.70  Bcast:135.207.223.255  Mask:255.255.255=
.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3960 errors:0 dropped:0 overruns:0 frame:0
          TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:293401 (286.5 KiB)  TX bytes:10323 (10.0 KiB)

lo        Link encap:Local Loopback  0  Metric:1
          RX packets:3957 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:348942 (340.7 KiB)  TX bytes:11041 (10.7 KiB)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2036 errors:0 dropped:2 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:1334 (1.3 KiB)  TX bytes:176630 (172.4 KiB)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
eth0		8000.00163e000094	no		vif2.0
            							peth0
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:94
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.70
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

Detail of other-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:96
          inet addr:135.207.223.71  Bcast:135.207.223.255  Mask:255.255.255=
.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2187 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:192417 (187.9 KiB)  TX bytes:1670 (1.6 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:96
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.71
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

------------------------------------------------------------------------
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

peth0     Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3957 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:348942 (340.7 KiB)  TX bytes:11041 (10.7 KiB)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2036 errors:0 dropped:2 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:1334 (1.3 KiB)  TX bytes:176630 (172.4 KiB)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
eth0		8000.00163e000094	no		vif2.0
            							peth0
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:94
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.70
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

Detail of other-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:96
          inet addr:135.207.223.71  Bcast:135.207.223.255  Mask:255.255.255=
.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2187 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:192417 (187.9 KiB)  TX bytes:1670 (1.6 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:96
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.71
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

------------------------------------------------------------------------

Shakeel

On Wed, Jun 20, 2012 at 7:53 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2012-06-19 at 14:49 +0100, Shakeel Butt wrote:
>> I previously email at xen-user list but didn't get any response. I am
>> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.
>
> Apart from the ancient version the main thing which I think is missing
> is all the configuration detail specifics.
>
> What are the actual network configuration in dom0 and domU? How are your
> bridges setup? What hotplug scripts are you using? Are they triggering?
> etc. What I'm looking for here is specific details like the outputs of
> "ifconfig -a" "brctl show" the contents of files like ifcfg-*
> or /etc/network/interfaces (depending on distro) in all the involved
> domains.
>
> Also how are you starting the netback-domU guest (command line), what is
> its configuration file?
>
> Same for the other-domU.
>
> How are you attaching the vif to dom0, what command are you running to
> make that happen?
>
> When the system is setup with all domains running what does "xenstore-ls
> -fp" contain? This will contain details of which device if attached to
> which.
>
>>
>>
>> ---------- Forwarded message ----------
>> From: Shakeel Butt <shakeel.butt@gmail.com>
>> Date: Mon, Jun 18, 2012 at 10:06 AM
>> Subject: netback (Network backend) in domU
>> To: xen-users@lists.xen.org
>>
>>
>> Hi,
>>
>> I am trying to setup a domU as a network backend for some other domUs.
>> I configured bridge in netback-domU using network-bridge script (not a
>> driver domain). I am assigning static ip addresses to all domUs.
>> Something like =A0dom0 <-> netback-domU <-> other-domU.
>>
>> In the setup, netback-domU and other-domU are able to ping each other
>> but whenever I tried to ping dom0 from other-domU, I get a XEN error
>> message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
>> dom0 kernel "#### netback grant fails".
>>
>> I didn't check if dom0 is trying to pin grant frame of other-domU but
>> why dom0 would do it. Please any help will be appreciated.
>>
>> BTW does the bridge in dom0 needs to know that one of its interface is
>> connected to another bridge in netback-domU? (don't know how or why)
>>
>> thanks,
>> Shakeel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Jun 21 16:43:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16:43: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 1ShkTH-0007ou-Qo; Thu, 21 Jun 2012 16:43: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 1ShkTF-0007oj-T0
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 16:43:02 +0000
Received: from [85.158.139.83:9680] by server-6.bemta-5.messagelabs.com id
	AF/A8-11348-F0F43EF4; Thu, 21 Jun 2012 16:42:55 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340296974!28326941!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23768 invoked from network); 21 Jun 2012 16:42:54 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 16:42:54 -0000
Received: by eaaa12 with SMTP id a12so650391eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 21 Jun 2012 09:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Y4rIuPz/zffJBVDjuJOgwf021FMdvHEKFK3CzGyvYxg=;
	b=onKzCN/jKOG5Fawnn+hmoEKq7InTMuG+/xXqqNXkE9mxh2vCc5pi6dQi8pXTFUy6xM
	nkdH9QeehI0L3fwb/AwBDXDamCzCyCPZCLqa4/FCNrkkNEMSZEc4XewNgaqqXZVYpwMm
	lQvzXL3xf60FoFtID12clwpR8rWRQKNvdBkbFSgY4OV6rH244xEK92ZXPwiVyr13dLxP
	J/gnnTwBW7nAljEdEZ2w96mCw6TAt+/ODhDu8MkUf27X9rT0KbWRQN/bUKuY/c6BWNjB
	qi51rOqDdo9qZ2gF9Bx6Go3zh3oyfcO05Og2WbKz5DHcdPxQAaijuXN1I+jeUMU6CTFL
	yr+A==
MIME-Version: 1.0
Received: by 10.14.119.73 with SMTP id m49mr5609206eeh.187.1340296973790; Thu,
	21 Jun 2012 09:42:53 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Thu, 21 Jun 2012 09:42:53 -0700 (PDT)
In-Reply-To: <1340193230.4906.45.camel@zakaz.uk.xensource.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<1340193230.4906.45.camel@zakaz.uk.xensource.com>
Date: Thu, 21 Jun 2012 12:42:53 -0400
Message-ID: <CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My mistake, I should have given more detail. I have included all the
necessary details in this email. I used network-bridge for creating
bridge in netback-domU and dom0 uses the same script on bootup. While
I think vif-bridge is used in both dom0 and netback-domU for hotplug
script.

The network configuration of netback-domU is

vif =3D ['mac=3D00:16:3e:00:00:94, bridge=3Deth0, ip=3D135.207.223.70']

while for other-domU is

vif =3D ['mac=3D00:16:3e:00:00:96, bridge=3Deth0, ip=3D135.207.223.71,
backend=3Dtest-domU-SD']

Detail of Dom0:
-----------------
-bash-3.2# xenstore-ls
local =3D ""
 domain =3D ""
  0 =3D ""
   backend =3D ""
    vif =3D ""
     1 =3D ""
      0 =3D ""
       bridge =3D "eth0"
       domain =3D "test-domU-SD"
       handle =3D "0"
       uuid =3D "d9f2c904-becd-9bcc-fa4f-4c9a800e585a"
       script =3D "/etc/xen/scripts/vif-bridge"
       ip =3D "135.207.223.70"
       state =3D "4"
       frontend =3D "/local/domain/1/device/vif/0"
       mac =3D "00:16:3e:00:00:94"
       online =3D "1"
       frontend-id =3D "1"
       feature-sg =3D "1"
       feature-gso-tcpv4 =3D "1"
       feature-rx-copy =3D "1"
       hotplug-status =3D "connected"
--------
  1 =3D ""
   device =3D ""
    vif =3D ""
     0 =3D ""
      mac =3D "00:16:3e:00:00:94"
      handle =3D "0"
      protocol =3D "x86_64-abi"
      backend-id =3D "0"
      state =3D "4"
      backend =3D "/local/domain/0/backend/vif/1/0"
      tx-ring-ref =3D "768"
      rx-ring-ref =3D "769"
      event-channel =3D "11"
      request-rx-copy =3D "0"
      feature-rx-notify =3D "1"
      feature-no-csum-offload =3D "0"
      feature-sg =3D "1"
      feature-gso-tcpv4 =3D "1"
   backend =3D ""
    vif =3D ""
     2 =3D ""
      0 =3D ""
       bridge =3D "eth0"
       domain =3D "test-domU"
       handle =3D "0"
       uuid =3D "2314d790-5223-cf26-59b2-1c0d6d053fe0"
       script =3D "/etc/xen/scripts/vif-bridge"
       ip =3D "135.207.223.71"
       state =3D "4"
       frontend =3D "/local/domain/2/device/vif/0"
       mac =3D "00:16:3e:00:00:96"
       online =3D "1"
       frontend-id =3D "2"
       feature-sg =3D "1"
       feature-gso-tcpv4 =3D "1"
       feature-rx-copy =3D "1"
       feature-rx-flip =3D "0"
       hotplug-status =3D "connected"
-------
  2 =3D ""
   device =3D ""
    vif =3D ""
     0 =3D ""
      mac =3D "00:16:3e:00:00:96"
      handle =3D "0"
      protocol =3D "x86_64-abi"
      backend-id =3D "1"
      state =3D "4"
      backend =3D "/local/domain/1/backend/vif/2/0"
      tx-ring-ref =3D "768"
      rx-ring-ref =3D "769"
      event-channel =3D "11"
      request-rx-copy =3D "1"
      feature-rx-notify =3D "1"
      feature-no-csum-offload =3D "0"
      feature-sg =3D "1"
      feature-gso-tcpv4 =3D "1"

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
eth0		8000.00219b9006ec	no		peth0
            							vif1.0
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:21:9b:90:06:ec
          inet addr:135.207.223.69  Bcast:135.207.223.255  Mask:255.255.255=
.0
          inet6 addr: fe80::221:9bff:fe90:6ec/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10596 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2707 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:776291 (758.0 KiB)  TX bytes:439416 (429.1 KiB)

lo ---

peth0     Link encap:Ethernet  HWaddr 00:21:9b:90:06:ec
          inet6 addr: fe80::221:9bff:fe90:6ec/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11737 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2851 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1046046 (1021.5 KiB)  TX bytes:465670 (454.7 KiB)
          Interrupt:18 Memory:d6000000-d6012800

veth0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif0.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif1.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:146 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4460 errors:0 dropped:33 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:11978 (11.6 KiB)  TX bytes:401242 (391.8 KiB)


Detail of netback-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
          inet addr:135.207.223.70  Bcast:135.207.223.255  Mask:255.255.255=
.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3960 errors:0 dropped:0 overruns:0 frame:0
          TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:293401 (286.5 KiB)  TX bytes:10323 (10.0 KiB)

lo        Link encap:Local Loopback  0  Metric:1
          RX packets:3957 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:348942 (340.7 KiB)  TX bytes:11041 (10.7 KiB)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2036 errors:0 dropped:2 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:1334 (1.3 KiB)  TX bytes:176630 (172.4 KiB)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
eth0		8000.00163e000094	no		vif2.0
            							peth0
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:94
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.70
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

Detail of other-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:96
          inet addr:135.207.223.71  Bcast:135.207.223.255  Mask:255.255.255=
.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2187 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:192417 (187.9 KiB)  TX bytes:1670 (1.6 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:96
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.71
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

------------------------------------------------------------------------
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

peth0     Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3957 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:348942 (340.7 KiB)  TX bytes:11041 (10.7 KiB)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2036 errors:0 dropped:2 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:1334 (1.3 KiB)  TX bytes:176630 (172.4 KiB)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
eth0		8000.00163e000094	no		vif2.0
            							peth0
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:94
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.70
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

Detail of other-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:96
          inet addr:135.207.223.71  Bcast:135.207.223.255  Mask:255.255.255=
.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2187 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:192417 (187.9 KiB)  TX bytes:1670 (1.6 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

-bash-3.2# brctl show
bridge name	bridge id		STP enabled	interfaces
-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=3Deth0
BOOTPROTO=3Dstatic
HWADDR=3D00:16:3e:00:00:96
ONBOOT=3Dyes
TYPE=3DEthernet
IPADDR=3D135.207.223.71
NETMASK=3D255.255.255.0
GATEWAY=3D135.207.223.1

------------------------------------------------------------------------

Shakeel

On Wed, Jun 20, 2012 at 7:53 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2012-06-19 at 14:49 +0100, Shakeel Butt wrote:
>> I previously email at xen-user list but didn't get any response. I am
>> using Xen-3.4.0 and 2.6.18 as dom0 kernel and facing below problem.
>
> Apart from the ancient version the main thing which I think is missing
> is all the configuration detail specifics.
>
> What are the actual network configuration in dom0 and domU? How are your
> bridges setup? What hotplug scripts are you using? Are they triggering?
> etc. What I'm looking for here is specific details like the outputs of
> "ifconfig -a" "brctl show" the contents of files like ifcfg-*
> or /etc/network/interfaces (depending on distro) in all the involved
> domains.
>
> Also how are you starting the netback-domU guest (command line), what is
> its configuration file?
>
> Same for the other-domU.
>
> How are you attaching the vif to dom0, what command are you running to
> make that happen?
>
> When the system is setup with all domains running what does "xenstore-ls
> -fp" contain? This will contain details of which device if attached to
> which.
>
>>
>>
>> ---------- Forwarded message ----------
>> From: Shakeel Butt <shakeel.butt@gmail.com>
>> Date: Mon, Jun 18, 2012 at 10:06 AM
>> Subject: netback (Network backend) in domU
>> To: xen-users@lists.xen.org
>>
>>
>> Hi,
>>
>> I am trying to setup a domU as a network backend for some other domUs.
>> I configured bridge in netback-domU using network-bridge script (not a
>> driver domain). I am assigning static ip addresses to all domUs.
>> Something like =A0dom0 <-> netback-domU <-> other-domU.
>>
>> In the setup, netback-domU and other-domU are able to ping each other
>> but whenever I tried to ping dom0 from other-domU, I get a XEN error
>> message "grant_table.c:387:d0 Could not pin grant frame 9d44e" and in
>> dom0 kernel "#### netback grant fails".
>>
>> I didn't check if dom0 is trying to pin grant frame of other-domU but
>> why dom0 would do it. Please any help will be appreciated.
>>
>> BTW does the bridge in dom0 needs to know that one of its interface is
>> connected to another bridge in netback-domU? (don't know how or why)
>>
>> thanks,
>> Shakeel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Jun 21 16:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShkUE-0007t3-ED; Thu, 21 Jun 2012 16:44:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShkUC-0007sq-DE
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:44:00 +0000
Received: from [85.158.139.83:21142] by server-5.bemta-5.messagelabs.com id
	C3/6E-02722-F4F43EF4; Thu, 21 Jun 2012 16:43:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340297038!21520562!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 787 invoked from network); 21 Jun 2012 16:43:58 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 16:43:58 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79047614; Thu, 21 Jun 2012 18:43:58 +0200
Message-ID: <1340297032.4856.93.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 21 Jun 2012 18:43:52 +0200
In-Reply-To: <4FE348C1.5030407@eu.citrix.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1449598143496131169=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1449598143496131169==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-/gQHvu2D2Ezi9V16qqmU"


--=-/gQHvu2D2Ezi9V16qqmU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 17:16 +0100, George Dunlap wrote:
> > Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
> Overall I think this approach is much better. =20
>
Cool, Thanks.

> > +    /*
> > +     * Round up and down some of the constraints. For instance, the mi=
nimum
> > +     * number of cpus a candidate should have must at least be non-neg=
ative.
> > +     * Regarding the minimum number of NUMA nodes, if not explicitly s=
pecified
> > +     * (i.e., min_nodes<=3D 0), we try to figure out a sensible number=
 of nodes
> > +     * from where to start generating candidates, if possible (or just=
 start
> > +     * from 1 otherwise). The maximum number of nodes should not excee=
d the
> > +     * number of existent NUMA nodes on the host, or the candidate gen=
aration
> > +     * won't work properly.
> > +     */
> > +    min_cpus =3D min_cpus<=3D 0 ? 0 : min_cpus;
> Wouldn't it just make more sense to specify that "min_cpus" (and other=
=20
> parameters) had to be >=3D0?
>=20
Yes, I think that make sense, will do.

> > +/*
> > + * The NUMA placement candidates are reordered according to the follow=
ing
> > + * heuristics:
> > + *  - candidates involving fewer nodes come first. In case two (or
> > + *    more) candidates span the same number of nodes,
> > + *  - candidates with greater amount of free memory come first. In
> > + *    case two (or more) candidates differ in their amount of free
> > + *    memory by less than 10%,
> Interesting idea -- sounds pretty reasonable.
>
Time will tell... :-O

> > +static int numa_cmpf(const void *v1, const void *v2)
> > +{
> > +    const libxl__numa_candidate *c1 =3D (const libxl__numa_candidate*)=
 v1;
> > +    const libxl__numa_candidate *c2 =3D (const libxl__numa_candidate*)=
 v2;
> > +    double mem_diff =3D labs(c1->free_memkb - c2->free_memkb);
> > +    double mem_avg =3D (c1->free_memkb + c2->free_memkb) / 2.0;
> > +
> > +    if (c1->nr_nodes !=3D c2->nr_nodes)
> > +        return c1->nr_nodes - c2->nr_nodes;
> > +
> > +    if ((mem_diff / mem_avg) * 100.0<  10.0&&
> > +        c1->nr_domains !=3D c2->nr_domains)
> > +        return c1->nr_domains - c2->nr_domains;
> I realize this isn't a hot path, but it seems like moving into FP is=20
> really unnecessary.  You can just do this:
>=20
Yeah, IanC pointed out that too. I'll convert everything toward integer
arith.

> One more thing: Is there a reason why you put get_numa_candidates() in=
=20
> libxl_internal.h, but not sort_numa_candidates()?  It seems like both or=
=20
> neither should go. :-)
>=20
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
...
+_hidden int libxl__get_numa_candidates(libxl__gc *gc,
+                                uint32_t min_free_memkb, int min_cpus,
+                                int min_nodes, int max_nodes,
+                                libxl__numa_candidate *cndts[], int *nr_cn=
dts);
+
...
+/* signature for the comparison function between two candidates c1 and c2
+ * (the thid parameter is provided to enable thread safety). */
+typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2);
+/* sort the list of candidates in cndts (an array with nr_cndts elements i=
n
+ * it) using cmpf for comparing two candidates. Uses libc's qsort(). */
+_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
+                                         int nr_cndts,
+                                         libxl__numa_candidate_cmpf cmpf);

But I'm not entirely sure I understood what you meant...

> That's all I have for now.  I'm OK with the general approach, so here's=
=20
> a "weak ack", so if a maintainer is happy with the code, he can check it =
in:
>=20
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
Ok, that's very nice. I'll have to respin the series, so I'll definitely
address your comments and add your ack. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-/gQHvu2D2Ezi9V16qqmU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jT0gACgkQk4XaBE3IOsSkYQCePx8xo5yBpyL4gmoI3tJmGNfF
k4UAn0kaftnp/vdCcA6XemJ6eOpRGu5k
=vTnK
-----END PGP SIGNATURE-----

--=-/gQHvu2D2Ezi9V16qqmU--



--===============1449598143496131169==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1449598143496131169==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 16:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 16:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShkUE-0007t3-ED; Thu, 21 Jun 2012 16:44:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShkUC-0007sq-DE
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 16:44:00 +0000
Received: from [85.158.139.83:21142] by server-5.bemta-5.messagelabs.com id
	C3/6E-02722-F4F43EF4; Thu, 21 Jun 2012 16:43:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340297038!21520562!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 787 invoked from network); 21 Jun 2012 16:43:58 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-182.messagelabs.com with SMTP;
	21 Jun 2012 16:43:58 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79047614; Thu, 21 Jun 2012 18:43:58 +0200
Message-ID: <1340297032.4856.93.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 21 Jun 2012 18:43:52 +0200
In-Reply-To: <4FE348C1.5030407@eu.citrix.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com>
X-Mailer: Evolution 3.2.2-1+b1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1449598143496131169=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1449598143496131169==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-/gQHvu2D2Ezi9V16qqmU"


--=-/gQHvu2D2Ezi9V16qqmU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 17:16 +0100, George Dunlap wrote:
> > Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
> Overall I think this approach is much better. =20
>
Cool, Thanks.

> > +    /*
> > +     * Round up and down some of the constraints. For instance, the mi=
nimum
> > +     * number of cpus a candidate should have must at least be non-neg=
ative.
> > +     * Regarding the minimum number of NUMA nodes, if not explicitly s=
pecified
> > +     * (i.e., min_nodes<=3D 0), we try to figure out a sensible number=
 of nodes
> > +     * from where to start generating candidates, if possible (or just=
 start
> > +     * from 1 otherwise). The maximum number of nodes should not excee=
d the
> > +     * number of existent NUMA nodes on the host, or the candidate gen=
aration
> > +     * won't work properly.
> > +     */
> > +    min_cpus =3D min_cpus<=3D 0 ? 0 : min_cpus;
> Wouldn't it just make more sense to specify that "min_cpus" (and other=
=20
> parameters) had to be >=3D0?
>=20
Yes, I think that make sense, will do.

> > +/*
> > + * The NUMA placement candidates are reordered according to the follow=
ing
> > + * heuristics:
> > + *  - candidates involving fewer nodes come first. In case two (or
> > + *    more) candidates span the same number of nodes,
> > + *  - candidates with greater amount of free memory come first. In
> > + *    case two (or more) candidates differ in their amount of free
> > + *    memory by less than 10%,
> Interesting idea -- sounds pretty reasonable.
>
Time will tell... :-O

> > +static int numa_cmpf(const void *v1, const void *v2)
> > +{
> > +    const libxl__numa_candidate *c1 =3D (const libxl__numa_candidate*)=
 v1;
> > +    const libxl__numa_candidate *c2 =3D (const libxl__numa_candidate*)=
 v2;
> > +    double mem_diff =3D labs(c1->free_memkb - c2->free_memkb);
> > +    double mem_avg =3D (c1->free_memkb + c2->free_memkb) / 2.0;
> > +
> > +    if (c1->nr_nodes !=3D c2->nr_nodes)
> > +        return c1->nr_nodes - c2->nr_nodes;
> > +
> > +    if ((mem_diff / mem_avg) * 100.0<  10.0&&
> > +        c1->nr_domains !=3D c2->nr_domains)
> > +        return c1->nr_domains - c2->nr_domains;
> I realize this isn't a hot path, but it seems like moving into FP is=20
> really unnecessary.  You can just do this:
>=20
Yeah, IanC pointed out that too. I'll convert everything toward integer
arith.

> One more thing: Is there a reason why you put get_numa_candidates() in=
=20
> libxl_internal.h, but not sort_numa_candidates()?  It seems like both or=
=20
> neither should go. :-)
>=20
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
...
+_hidden int libxl__get_numa_candidates(libxl__gc *gc,
+                                uint32_t min_free_memkb, int min_cpus,
+                                int min_nodes, int max_nodes,
+                                libxl__numa_candidate *cndts[], int *nr_cn=
dts);
+
...
+/* signature for the comparison function between two candidates c1 and c2
+ * (the thid parameter is provided to enable thread safety). */
+typedef int (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2);
+/* sort the list of candidates in cndts (an array with nr_cndts elements i=
n
+ * it) using cmpf for comparing two candidates. Uses libc's qsort(). */
+_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
+                                         int nr_cndts,
+                                         libxl__numa_candidate_cmpf cmpf);

But I'm not entirely sure I understood what you meant...

> That's all I have for now.  I'm OK with the general approach, so here's=
=20
> a "weak ack", so if a maintainer is happy with the code, he can check it =
in:
>=20
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
Ok, that's very nice. I'll have to respin the series, so I'll definitely
address your comments and add your ack. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-/gQHvu2D2Ezi9V16qqmU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jT0gACgkQk4XaBE3IOsSkYQCePx8xo5yBpyL4gmoI3tJmGNfF
k4UAn0kaftnp/vdCcA6XemJ6eOpRGu5k
=vTnK
-----END PGP SIGNATURE-----

--=-/gQHvu2D2Ezi9V16qqmU--



--===============1449598143496131169==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1449598143496131169==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 17:01:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17: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 1ShklD-0008EX-4C; Thu, 21 Jun 2012 17:01:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1ShklB-0008ES-KM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:01:33 +0000
Received: from [85.158.138.51:55637] by server-5.bemta-3.messagelabs.com id
	F4/44-01572-C6353EF4; Thu, 21 Jun 2012 17:01:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340298091!28890634!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4568 invoked from network); 21 Jun 2012 17:01:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 17:01:31 -0000
X-TM-IMSS-Message-ID: <8eac5de500004fcc@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8eac5de500004fcc ; Thu, 21 Jun 2012 13:02:13 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LH1Opx010164; 
	Thu, 21 Jun 2012 13:01:25 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: keir@xen.org, JBeulich@suse.com
Date: Thu, 21 Jun 2012 13:01:22 -0400
Message-Id: <1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.10.2
In-Reply-To: <4FE35452020000780008B274@nat28.tlf.novell.com>
References: <4FE35452020000780008B274@nat28.tlf.novell.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 attempting to use AMD's extension to access the extended PCI config
space, only the low byte of the register number was being passed to XSM.
Include the correct value of the register if this feature is enabled;
otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/traps.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2264583..d836452 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1686,11 +1686,24 @@ static int pci_cfg_ok(struct domain *d, int write, int size)
 {
     uint32_t machine_bdf;
     uint16_t start, end;
+    uint64_t msr_val;
     if (!IS_PRIV(d))
         return 0;
 
     machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
     start = d->arch.pci_cf8 & 0xFF;
+    if ( d->arch.pci_cf8 & 0x0F000000 )
+    {
+        /* Possible AMD extended configuration access */
+        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
+             boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
+            return 0;
+        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
+            return 0;
+        if ( !(msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT)) )
+            return 0;
+        start |= (d->arch.pci_cf8 >> 16) & 0xF00;
+    }
     end = start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
         return 0;
-- 
1.7.10.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:01:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17: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 1ShklD-0008EX-4C; Thu, 21 Jun 2012 17:01:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1ShklB-0008ES-KM
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:01:33 +0000
Received: from [85.158.138.51:55637] by server-5.bemta-3.messagelabs.com id
	F4/44-01572-C6353EF4; Thu, 21 Jun 2012 17:01:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340298091!28890634!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4568 invoked from network); 21 Jun 2012 17:01:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 17:01:31 -0000
X-TM-IMSS-Message-ID: <8eac5de500004fcc@nsa.gov>
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by
	nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service
	7.1) id 8eac5de500004fcc ; Thu, 21 Jun 2012 13:02:13 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q5LH1Opx010164; 
	Thu, 21 Jun 2012 13:01:25 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: keir@xen.org, JBeulich@suse.com
Date: Thu, 21 Jun 2012 13:01:22 -0400
Message-Id: <1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.10.2
In-Reply-To: <4FE35452020000780008B274@nat28.tlf.novell.com>
References: <4FE35452020000780008B274@nat28.tlf.novell.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 attempting to use AMD's extension to access the extended PCI config
space, only the low byte of the register number was being passed to XSM.
Include the correct value of the register if this feature is enabled;
otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/traps.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2264583..d836452 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1686,11 +1686,24 @@ static int pci_cfg_ok(struct domain *d, int write, int size)
 {
     uint32_t machine_bdf;
     uint16_t start, end;
+    uint64_t msr_val;
     if (!IS_PRIV(d))
         return 0;
 
     machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
     start = d->arch.pci_cf8 & 0xFF;
+    if ( d->arch.pci_cf8 & 0x0F000000 )
+    {
+        /* Possible AMD extended configuration access */
+        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
+             boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
+            return 0;
+        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
+            return 0;
+        if ( !(msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT)) )
+            return 0;
+        start |= (d->arch.pci_cf8 >> 16) & 0xF00;
+    }
     end = start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
         return 0;
-- 
1.7.10.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shl2U-0000Aa-Aq; Thu, 21 Jun 2012 17:19: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 1Shl2T-0000AV-0N
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:19:25 +0000
Received: from [193.109.254.147:48906] by server-11.bemta-14.messagelabs.com
	id A1/EA-24843-C9753EF4; Thu, 21 Jun 2012 17:19:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340299162!8814391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11818 invoked from network); 21 Jun 2012 17:19:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:19:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:19:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Shl2Q-0005mI-7m; Thu, 21 Jun 2012 17:19:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Shl2Q-0004fL-4W;
	Thu, 21 Jun 2012 18:19:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.22426.90214.74528@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:19:22 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE2E4DC.5030500@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] xs: set read_thread stacksize"):
> Frankly I don't understand why do we have to touch this, even if you 
> requested 256MB of stack it won't we allocated until you get a page 
> fault, so you are only using the physical memory you need.

It uses up a lot of address space on 32-bit if nothing else.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Shl2U-0000Aa-Aq; Thu, 21 Jun 2012 17:19: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 1Shl2T-0000AV-0N
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:19:25 +0000
Received: from [193.109.254.147:48906] by server-11.bemta-14.messagelabs.com
	id A1/EA-24843-C9753EF4; Thu, 21 Jun 2012 17:19:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340299162!8814391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11818 invoked from network); 21 Jun 2012 17:19:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:19:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:19:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Shl2Q-0005mI-7m; Thu, 21 Jun 2012 17:19:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Shl2Q-0004fL-4W;
	Thu, 21 Jun 2012 18:19:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.22426.90214.74528@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:19:22 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE2E4DC.5030500@citrix.com>
References: <0cf61ed6ce86de2b61db.1338307000@drall.uk.xensource.com>
	<201205300856.15605.simon.rowe@eu.citrix.com>
	<1338370815.31698.26.camel@zakaz.uk.xensource.com>
	<201205301310.09243.simon.rowe@eu.citrix.com>
	<1338449525.7864.14.camel@zakaz.uk.xensource.com>
	<4FE2E4DC.5030500@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Simon Rowe <Simon.Rowe@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xs: set read_thread stacksize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH] xs: set read_thread stacksize"):
> Frankly I don't understand why do we have to touch this, even if you 
> requested 256MB of stack it won't we allocated until you get a page 
> fault, so you are only using the physical memory you need.

It uses up a lot of address space on 32-bit if nothing else.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:22:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1Shl4y-0000GT-TB; Thu, 21 Jun 2012 17:22:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Shl4y-0000GO-Ac
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:22:00 +0000
Received: from [85.158.143.99:41253] by server-1.bemta-4.messagelabs.com id
	7D/F5-24392-73853EF4; Thu, 21 Jun 2012 17:21:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340299319!21466675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9772 invoked from network); 21 Jun 2012 17:21:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:21:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:21:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Shl4w-0005nH-Ps; Thu, 21 Jun 2012 17:21:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Shl4w-0004ff-Na;
	Thu, 21 Jun 2012 18:21:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.22582.717552.469036@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:21:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340272422.21872.53.camel@zakaz.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: fix sedf parameters 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

Ian Campbell writes ("Re: [PATCH] xl: fix sedf parameters checking"):
> On Wed, 2012-06-20 at 18:09 +0100, Dario Faggioli wrote:
> > 9d1fd58ff602 was bogous in not letting a new domain being created
> > if its scheduling parameters --when running under the sedf scheduler--
> > were not fully specified, making creation fail like in this example
> > here below:
...
> 
> Thanks for this. I'd like to get it in ASAP so we can start passing
> tests again. I have a few queries though unfortunately...

You'll see I've applied it already.  I would be happy to take a
followup cleanup/fixup.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:22:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 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 1Shl4y-0000GT-TB; Thu, 21 Jun 2012 17:22:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Shl4y-0000GO-Ac
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:22:00 +0000
Received: from [85.158.143.99:41253] by server-1.bemta-4.messagelabs.com id
	7D/F5-24392-73853EF4; Thu, 21 Jun 2012 17:21:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340299319!21466675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9772 invoked from network); 21 Jun 2012 17:21:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:21:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:21:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Shl4w-0005nH-Ps; Thu, 21 Jun 2012 17:21:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Shl4w-0004ff-Na;
	Thu, 21 Jun 2012 18:21:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.22582.717552.469036@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:21:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340272422.21872.53.camel@zakaz.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <raistlin@linux.it>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: fix sedf parameters 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

Ian Campbell writes ("Re: [PATCH] xl: fix sedf parameters checking"):
> On Wed, 2012-06-20 at 18:09 +0100, Dario Faggioli wrote:
> > 9d1fd58ff602 was bogous in not letting a new domain being created
> > if its scheduling parameters --when running under the sedf scheduler--
> > were not fully specified, making creation fail like in this example
> > here below:
...
> 
> Thanks for this. I'd like to get it in ASAP so we can start passing
> tests again. I have a few queries though unfortunately...

You'll see I've applied it already.  I would be happy to take a
followup cleanup/fixup.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17: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 1ShlHS-0000Xk-79; Thu, 21 Jun 2012 17:34: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 1ShlHR-0000Xf-8p
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:34:53 +0000
Received: from [193.109.254.147:14296] by server-5.bemta-14.messagelabs.com id
	41/E4-04343-C3B53EF4; Thu, 21 Jun 2012 17:34:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340300092!5305726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16483 invoked from network); 21 Jun 2012 17:34:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:34:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:34:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:34:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShlHP-0005ri-3w; Thu, 21 Jun 2012 17:34:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShlHP-0004gY-2E;
	Thu, 21 Jun 2012 18:34:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.23355.53407.759361@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:34:51 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-4-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-4-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 03/13] libxl: convert
	libxl_domain_destroy to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 03/13] libxl: convert libxl_domain_destroy to an async op"):
> This change introduces some new structures, and breaks the mutual
> dependency that libxl_domain_destroy and libxl__destroy_device_model
> had. This is done by checking if the domid passed to
> libxl_domain_destroy has a stubdom, and then having the bulk of the
> destroy machinery in a separate function (libxl__destroy_domid) that
> doesn't check for stubdom presence, since we check for it in the upper
> level function. The reason behind this change is the need to use
> structures for ao operations, and it was impossible to have two
> different self-referencing structs.

See below for a couple of typos, but:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 8612fe4..8478606 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
...
> +/* Prepare a bunch of devices for addition/removal. Every ao_device in
> + * ao_devices is set to 'active', and the ao_device 'base' filed is set to
                                                              ^^^^^
> + * the one pointed by aodevs.

field

> + */
> +_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
> +                                       libxl__ao_devices *aodevs);
> +
> +/* Generic callback to use when adding/removing several devices, this will
> + * check if the given aodev is the last one, and call the callback in the
> + * parent libxl__ao_devices struct, passing the appropiate error if found.
                                                   ^^^^^^^^^^
appropriate

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17: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 1ShlHS-0000Xk-79; Thu, 21 Jun 2012 17:34: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 1ShlHR-0000Xf-8p
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:34:53 +0000
Received: from [193.109.254.147:14296] by server-5.bemta-14.messagelabs.com id
	41/E4-04343-C3B53EF4; Thu, 21 Jun 2012 17:34:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340300092!5305726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16483 invoked from network); 21 Jun 2012 17:34:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:34:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:34:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:34:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShlHP-0005ri-3w; Thu, 21 Jun 2012 17:34:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShlHP-0004gY-2E;
	Thu, 21 Jun 2012 18:34:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.23355.53407.759361@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:34:51 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-4-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-4-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 03/13] libxl: convert
	libxl_domain_destroy to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 03/13] libxl: convert libxl_domain_destroy to an async op"):
> This change introduces some new structures, and breaks the mutual
> dependency that libxl_domain_destroy and libxl__destroy_device_model
> had. This is done by checking if the domid passed to
> libxl_domain_destroy has a stubdom, and then having the bulk of the
> destroy machinery in a separate function (libxl__destroy_domid) that
> doesn't check for stubdom presence, since we check for it in the upper
> level function. The reason behind this change is the need to use
> structures for ao operations, and it was impossible to have two
> different self-referencing structs.

See below for a couple of typos, but:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 8612fe4..8478606 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
...
> +/* Prepare a bunch of devices for addition/removal. Every ao_device in
> + * ao_devices is set to 'active', and the ao_device 'base' filed is set to
                                                              ^^^^^
> + * the one pointed by aodevs.

field

> + */
> +_hidden void libxl__prepare_ao_devices(libxl__ao *ao,
> +                                       libxl__ao_devices *aodevs);
> +
> +/* Generic callback to use when adding/removing several devices, this will
> + * check if the given aodev is the last one, and call the callback in the
> + * parent libxl__ao_devices struct, passing the appropiate error if found.
                                                   ^^^^^^^^^^
appropriate

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:35:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShlI5-0000Zw-Ka; Thu, 21 Jun 2012 17:35:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShlI3-0000Zh-Nb
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:35:31 +0000
Received: from [193.109.254.147:20368] by server-5.bemta-14.messagelabs.com id
	98/45-04343-36B53EF4; Thu, 21 Jun 2012 17:35:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340300130!10946312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21605 invoked from network); 21 Jun 2012 17:35:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:35:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:35:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShlI1-0005rz-Pj; Thu, 21 Jun 2012 17:35:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShlI1-0004gi-Or;
	Thu, 21 Jun 2012 18:35:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.23393.652605.290214@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:35:29 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-5-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 04/13] libxl: move bootloader data
 strucutres and 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

Roger Pau Monne writes ("[PATCH v6 04/13] libxl: move bootloader data strucutres and prototypes"):
> Move bootloader and related data after all the device stuff, since
> libxl__bootloader_state will depend on libxl__ao_device (to perform
> the local attach of a device).
> 
> This is pure code motion.

On that basis (without having checked it myself):

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:35:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShlI5-0000Zw-Ka; Thu, 21 Jun 2012 17:35:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShlI3-0000Zh-Nb
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:35:31 +0000
Received: from [193.109.254.147:20368] by server-5.bemta-14.messagelabs.com id
	98/45-04343-36B53EF4; Thu, 21 Jun 2012 17:35:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340300130!10946312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21605 invoked from network); 21 Jun 2012 17:35:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:35:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 17:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 18:35:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShlI1-0005rz-Pj; Thu, 21 Jun 2012 17:35:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1ShlI1-0004gi-Or;
	Thu, 21 Jun 2012 18:35:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.23393.652605.290214@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:35:29 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-5-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-5-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 04/13] libxl: move bootloader data
 strucutres and 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

Roger Pau Monne writes ("[PATCH v6 04/13] libxl: move bootloader data strucutres and prototypes"):
> Move bootloader and related data after all the device stuff, since
> libxl__bootloader_state will depend on libxl__ao_device (to perform
> the local attach of a device).
> 
> This is pure code motion.

On that basis (without having checked it myself):

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17:58: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 1ShleP-0000ub-MA; Thu, 21 Jun 2012 17:58:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShleO-0000uW-Uu
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:58:37 +0000
Received: from [85.158.138.51:61900] by server-9.bemta-3.messagelabs.com id
	88/F5-10419-CC063EF4; Thu, 21 Jun 2012 17:58:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340301514!20800753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19287 invoked from network); 21 Jun 2012 17:58:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:58:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 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.213.0; Thu, 21 Jun 2012 18:58:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShleL-0005zX-IR; Thu, 21 Jun 2012 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 1ShleL-0004hv-HS;
	Thu, 21 Jun 2012 18:58:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.24777.528406.191318@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:58:33 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-6-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-6-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 05/13] libxl: convert
 libxl__device_disk_local_attach to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 05/13] libxl: convert libxl__device_disk_local_attach to an async op"):
> This will be needed in future patches, when libxl__device_disk_add
> becomes async also. Create a new status structure that defines the
> local attach of a disk device and use it in
> libxl__device_disk_local_attach.

This is looking good.  I have a couple of comments:

> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index 7ebc0df..182a975 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
...
> +static void bootloader_fisnihed_cb(libxl__egc *egc,
                          ^^^^^^^^
`finished'.  You have apparently managed to misspell this everywhere
you mention it!

> +                                   libxl__disk_local_state *dls,
> +                                   int rc);
> +
>  static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
>                                  int rc)
>  {
>      bootloader_cleanup(egc, bl);
> +
> +    if (bl->diskpath) {
> +        bl->dls.callback = bootloader_fisnihed_cb;
> +        libxl__device_disk_local_detach(egc, &bl->dls);
> +        return;
> +    }

Can we make libxl__device_disk_local_detach idempotent (and perhaps
call it `libxl__device_disk_local_attached_initiate_cleanup' or
something, if you can think of a name that's less than a paragraph) ?

If so then this would be simpler and wouldn't need to test
bl->diskpath.

> +static void bootloader_disk_attached_cb(libxl__egc *egc,
> +                                        libxl__disk_local_state *dls,
> +                                        int rc)
...
> +    bl->diskpath = bl->dls.diskpath;

Now that we have a bl->dls.diskpath, surely we can do away with
bl->diskpath ?  I'm not a fan of having multiple variables with the
same information in them, unless it's essential.  It just leads to
confusion and error.

> +/*
> + * Make a disk available in this (the control) domain. Calls dls->callback
> + * when finished.
> + */
> +_hidden void libxl__device_disk_local_attach(libxl__egc *egc,
> +                                             libxl__disk_local_state *dls);
> +_hidden void libxl__device_disk_local_detach(libxl__egc *egc,
> +                                             libxl__disk_local_state *dls);

You really need to explain the rules for one of these dls's.

Is it something like this:

     * A libxl__disk_local_state may be in the following states:
     *    Undefined, Idle, Attaching, Attached, Detaching

    typedef void libxl__disk_local_state_callback(libxl__egc*,
                                                  libxl__disk_local_state*,
                                                  int rc);

   _hidden void libxl__device_disk_local_attach(libxl__egc *egc,
                                                libxl__disk_local_state *dls);
       /* Undefined/Idle -> Attaching.  Will call callback.
        * On entry to callback, if rc!=0 dls is Idle;
        * if rc==0 it is Attached and dls->diskpath is usable. */

   _hidden void libxl__device_disk_local_detach(libxl__egc *egc,
                                                libxl__disk_local_state *dls);
       /* Attached -> Detaching.  Will call callback.
        * On entry to callback, dls is Idle, regardless of
        * success or failure. */

And my suggestion about idempotency would change this latter comment
to:
       /* Idle/Attached -> Detaching.  Will call callback.
        * On entry to callback, dls is Idle, regardless of
        * success or failure. */

And the bootloader code might want this:

   _hidden void libxl__device_disk_local_init(libxl__disk_local_state *dls);
       /* Undefined/Idle -> Idle */

Or you can explain it in prose if you like.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 17:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 17:58: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 1ShleP-0000ub-MA; Thu, 21 Jun 2012 17:58:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1ShleO-0000uW-Uu
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 17:58:37 +0000
Received: from [85.158.138.51:61900] by server-9.bemta-3.messagelabs.com id
	88/F5-10419-CC063EF4; Thu, 21 Jun 2012 17:58:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340301514!20800753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDE4MTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19287 invoked from network); 21 Jun 2012 17:58:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 17:58:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="13155730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 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.213.0; Thu, 21 Jun 2012 18:58:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1ShleL-0005zX-IR; Thu, 21 Jun 2012 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 1ShleL-0004hv-HS;
	Thu, 21 Jun 2012 18:58:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20451.24777.528406.191318@mariner.uk.xensource.com>
Date: Thu, 21 Jun 2012 18:58:33 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-6-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-6-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 05/13] libxl: convert
 libxl__device_disk_local_attach to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 05/13] libxl: convert libxl__device_disk_local_attach to an async op"):
> This will be needed in future patches, when libxl__device_disk_add
> becomes async also. Create a new status structure that defines the
> local attach of a disk device and use it in
> libxl__device_disk_local_attach.

This is looking good.  I have a couple of comments:

> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index 7ebc0df..182a975 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
...
> +static void bootloader_fisnihed_cb(libxl__egc *egc,
                          ^^^^^^^^
`finished'.  You have apparently managed to misspell this everywhere
you mention it!

> +                                   libxl__disk_local_state *dls,
> +                                   int rc);
> +
>  static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
>                                  int rc)
>  {
>      bootloader_cleanup(egc, bl);
> +
> +    if (bl->diskpath) {
> +        bl->dls.callback = bootloader_fisnihed_cb;
> +        libxl__device_disk_local_detach(egc, &bl->dls);
> +        return;
> +    }

Can we make libxl__device_disk_local_detach idempotent (and perhaps
call it `libxl__device_disk_local_attached_initiate_cleanup' or
something, if you can think of a name that's less than a paragraph) ?

If so then this would be simpler and wouldn't need to test
bl->diskpath.

> +static void bootloader_disk_attached_cb(libxl__egc *egc,
> +                                        libxl__disk_local_state *dls,
> +                                        int rc)
...
> +    bl->diskpath = bl->dls.diskpath;

Now that we have a bl->dls.diskpath, surely we can do away with
bl->diskpath ?  I'm not a fan of having multiple variables with the
same information in them, unless it's essential.  It just leads to
confusion and error.

> +/*
> + * Make a disk available in this (the control) domain. Calls dls->callback
> + * when finished.
> + */
> +_hidden void libxl__device_disk_local_attach(libxl__egc *egc,
> +                                             libxl__disk_local_state *dls);
> +_hidden void libxl__device_disk_local_detach(libxl__egc *egc,
> +                                             libxl__disk_local_state *dls);

You really need to explain the rules for one of these dls's.

Is it something like this:

     * A libxl__disk_local_state may be in the following states:
     *    Undefined, Idle, Attaching, Attached, Detaching

    typedef void libxl__disk_local_state_callback(libxl__egc*,
                                                  libxl__disk_local_state*,
                                                  int rc);

   _hidden void libxl__device_disk_local_attach(libxl__egc *egc,
                                                libxl__disk_local_state *dls);
       /* Undefined/Idle -> Attaching.  Will call callback.
        * On entry to callback, if rc!=0 dls is Idle;
        * if rc==0 it is Attached and dls->diskpath is usable. */

   _hidden void libxl__device_disk_local_detach(libxl__egc *egc,
                                                libxl__disk_local_state *dls);
       /* Attached -> Detaching.  Will call callback.
        * On entry to callback, dls is Idle, regardless of
        * success or failure. */

And my suggestion about idempotency would change this latter comment
to:
       /* Idle/Attached -> Detaching.  Will call callback.
        * On entry to callback, dls is Idle, regardless of
        * success or failure. */

And the bootloader code might want this:

   _hidden void libxl__device_disk_local_init(libxl__disk_local_state *dls);
       /* Undefined/Idle -> Idle */

Or you can explain it in prose if you like.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 18:17:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 18: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 1ShlwU-0001LU-RI; Thu, 21 Jun 2012 18:17:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1ShlwT-0001LP-Li
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 18:17:17 +0000
Received: from [85.158.143.35:30011] by server-2.bemta-4.messagelabs.com id
	11/E5-17938-D2563EF4; Thu, 21 Jun 2012 18:17:17 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340302636!5581572!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5605 invoked from network); 21 Jun 2012 18:17:16 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 18:17:16 -0000
Received: by eaaa12 with SMTP id a12so694525eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 21 Jun 2012 11:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Gx1zaFYG8MqCODQw74VIXkdODffxtdGTv99qI5DuyvI=;
	b=Xk68xUKjFwrfdqdxwcv+cvPdA68F8p2m+cbSzlQzAvQ5BQ6EJDUl4vrGA/TZY1/oHk
	f8aFqJELHMr38e0Zx96oSxVb9qTHPliTdctgvm6zBlsHNeUZHQojscF3x43/fjo3TYM4
	gc3HkC/oQ1rFyRyGesJ7L/FnnmPYYJR6oPYghLpAyBhhcU9RAZ0nYcE9YJS1VshBdI+4
	PoSPGKk99I/UII86wfNNZCoZVv+b4+JdQlyMO/I7LJbskPQVmfD+5p1cPZz4NNO9LuHC
	1JtYQRLFRtkGs9un3Gill+3EoYV4jjIOiMwXrBpJFu8hOkOJLmU7zScqwORf1HSJPf6v
	V49A==
MIME-Version: 1.0
Received: by 10.14.99.10 with SMTP id w10mr6403143eef.175.1340302635780; Thu,
	21 Jun 2012 11:17:15 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Thu, 21 Jun 2012 11:17:15 -0700 (PDT)
In-Reply-To: <CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<1340193230.4906.45.camel@zakaz.uk.xensource.com>
	<CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
Date: Thu, 21 Jun 2012 14:17:15 -0400
Message-ID: <CAGj-7pVyZZ=VQ566fvENhKJ58v=F+3Ub0hsTuY3d0ao7FtwZhQ@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have messed up my copy/paste on details of netback-domU and
other-domU. So, for these two the clear details are below:

Detail of netback-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0     Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
         inet addr:135.207.223.70  Bcast:135.207.223.255  Mask:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:3960 errors:0 dropped:0 overruns:0 frame:0
         TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:293401 (286.5 KiB)  TX bytes:10323 (10.0 KiB)

lo       Link encap:Local Loopback  0  Metric:1
         inet addr:127.0.0.1  Mask:255.0.0.0
         UP LOOPBACK RUNNING  MTU:16436  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

peth0     Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:3957 errors:0 dropped:0 overruns:0 frame:0
         TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:348942 (340.7 KiB)  TX bytes:11041 (10.7 KiB)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:24 errors:0 dropped:0 overruns:0 frame:0
         TX packets:2036 errors:0 dropped:2 overruns:0 carrier:0
         collisions:0 txqueuelen:32
         RX bytes:1334 (1.3 KiB)  TX bytes:176630 (172.4 KiB)


-bash-3.2# brctl show
bridge name     bridge id               STP enabled     interfaces
eth0            8000.00163e000094       no              vif2.0

         peth0


-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:16:3e:00:00:94
ONBOOT=yes
TYPE=Ethernet
IPADDR=135.207.223.70
NETMASK=255.255.255.0
GATEWAY=135.207.223.1

Detail of other-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:96
         inet addr:135.207.223.71  Bcast:135.207.223.255  Mask:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:2187 errors:0 dropped:0 overruns:0 frame:0
         TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:192417 (187.9 KiB)  TX bytes:1670 (1.6 KiB)

lo        Link encap:Local Loopback
         inet addr:127.0.0.1  Mask:255.0.0.0
         UP LOOPBACK RUNNING  MTU:16436  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

-bash-3.2# brctl show
bridge name     bridge id               STP enabled     interfaces

-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:16:3e:00:00:96
ONBOOT=yes
TYPE=Ethernet
IPADDR=135.207.223.71
NETMASK=255.255.255.0
GATEWAY=135.207.223.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 18:17:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 18: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 1ShlwU-0001LU-RI; Thu, 21 Jun 2012 18:17:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1ShlwT-0001LP-Li
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 18:17:17 +0000
Received: from [85.158.143.35:30011] by server-2.bemta-4.messagelabs.com id
	11/E5-17938-D2563EF4; Thu, 21 Jun 2012 18:17:17 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340302636!5581572!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5605 invoked from network); 21 Jun 2012 18:17:16 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 18:17:16 -0000
Received: by eaaa12 with SMTP id a12so694525eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 21 Jun 2012 11:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Gx1zaFYG8MqCODQw74VIXkdODffxtdGTv99qI5DuyvI=;
	b=Xk68xUKjFwrfdqdxwcv+cvPdA68F8p2m+cbSzlQzAvQ5BQ6EJDUl4vrGA/TZY1/oHk
	f8aFqJELHMr38e0Zx96oSxVb9qTHPliTdctgvm6zBlsHNeUZHQojscF3x43/fjo3TYM4
	gc3HkC/oQ1rFyRyGesJ7L/FnnmPYYJR6oPYghLpAyBhhcU9RAZ0nYcE9YJS1VshBdI+4
	PoSPGKk99I/UII86wfNNZCoZVv+b4+JdQlyMO/I7LJbskPQVmfD+5p1cPZz4NNO9LuHC
	1JtYQRLFRtkGs9un3Gill+3EoYV4jjIOiMwXrBpJFu8hOkOJLmU7zScqwORf1HSJPf6v
	V49A==
MIME-Version: 1.0
Received: by 10.14.99.10 with SMTP id w10mr6403143eef.175.1340302635780; Thu,
	21 Jun 2012 11:17:15 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Thu, 21 Jun 2012 11:17:15 -0700 (PDT)
In-Reply-To: <CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<1340193230.4906.45.camel@zakaz.uk.xensource.com>
	<CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
Date: Thu, 21 Jun 2012 14:17:15 -0400
Message-ID: <CAGj-7pVyZZ=VQ566fvENhKJ58v=F+3Ub0hsTuY3d0ao7FtwZhQ@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have messed up my copy/paste on details of netback-domU and
other-domU. So, for these two the clear details are below:

Detail of netback-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0     Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
         inet addr:135.207.223.70  Bcast:135.207.223.255  Mask:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:3960 errors:0 dropped:0 overruns:0 frame:0
         TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:293401 (286.5 KiB)  TX bytes:10323 (10.0 KiB)

lo       Link encap:Local Loopback  0  Metric:1
         inet addr:127.0.0.1  Mask:255.0.0.0
         UP LOOPBACK RUNNING  MTU:16436  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

peth0     Link encap:Ethernet  HWaddr 00:16:3E:00:00:94
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:3957 errors:0 dropped:0 overruns:0 frame:0
         TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:348942 (340.7 KiB)  TX bytes:11041 (10.7 KiB)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:24 errors:0 dropped:0 overruns:0 frame:0
         TX packets:2036 errors:0 dropped:2 overruns:0 carrier:0
         collisions:0 txqueuelen:32
         RX bytes:1334 (1.3 KiB)  TX bytes:176630 (172.4 KiB)


-bash-3.2# brctl show
bridge name     bridge id               STP enabled     interfaces
eth0            8000.00163e000094       no              vif2.0

         peth0


-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:16:3e:00:00:94
ONBOOT=yes
TYPE=Ethernet
IPADDR=135.207.223.70
NETMASK=255.255.255.0
GATEWAY=135.207.223.1

Detail of other-domU:
-----------------------
-bash-3.2# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3E:00:00:96
         inet addr:135.207.223.71  Bcast:135.207.223.255  Mask:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:2187 errors:0 dropped:0 overruns:0 frame:0
         TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:192417 (187.9 KiB)  TX bytes:1670 (1.6 KiB)

lo        Link encap:Local Loopback
         inet addr:127.0.0.1  Mask:255.0.0.0
         UP LOOPBACK RUNNING  MTU:16436  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

-bash-3.2# brctl show
bridge name     bridge id               STP enabled     interfaces

-bash-3.2# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:16:3e:00:00:96
ONBOOT=yes
TYPE=Ethernet
IPADDR=135.207.223.71
NETMASK=255.255.255.0
GATEWAY=135.207.223.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 18:44:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 18:44: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 1ShmMg-0001mJ-HP; Thu, 21 Jun 2012 18:44:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShmMf-0001mE-9G
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 18:44:21 +0000
Received: from [193.109.254.147:54315] by server-10.bemta-14.messagelabs.com
	id 1F/EF-05433-48B63EF4; Thu, 21 Jun 2012 18:44:20 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340304258!10104472!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU3MTk5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22305 invoked from network); 21 Jun 2012 18:44:19 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 18:44:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340304259; x=1371840259;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=5OljKYI/1tPmrNKVvokIbBadZ3GZVAAAWFK/ERPZwX4=;
	b=Ry4jfxVQP72+gFQB7R6tDjhIrs1SQfpyU7D0boiVtNm7bgOYkDzn074z
	FEH2YlANBGAlb5X9UL1UU/sDMkAZQg==;
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="318608069"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2012 18:43:54 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.101])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q5LIhqC9029373; Thu, 21 Jun 2012 18:43:52 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Thu, 21 Jun 2012 11:43:49 -0700
Date: Thu, 21 Jun 2012 11:43:49 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621184036.GD2640@US-SEA-R8XVZTX>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Olaf Hering <olaf@aepfle.de>,
	"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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 01:33:25AM -0700, Ian Campbell wrote:
> On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > diff -r 32034d1914a6 -r 4ba90ad04596 Config.mk
> > --- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
> > @@ -43,6 +43,7 @@ endif
> >  
> >  include $(XEN_ROOT)/config/$(XEN_OS).mk
> >  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
> > +include $(XEN_ROOT)/config/Tools.mk
> 
> Unfortunately this won't work, our policy is that you only need to
> invoke configure in order to build the tools -- so the top-level
> Config.mk cannot include configure generated files.

Aah, sorry. Good to know.

> >  SHAREDIR    ?= $(PREFIX)/share
> >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > @@ -67,7 +68,7 @@ endef
> >  
> >  ifneq ($(EXTRA_PREFIX),)
> >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> 
> since we are sort of reverting 16950:0faf620bc749 here this could in
> theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> include Tools.mk though. :-/

That would result in looking in /some/extra/prefix/usr/lib, which is
not what I'd expect is desired. 

> Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> hypervisor and other non-tools builds? If not then we could consider
> pushing it down a level.

That stuff has been around since the bitkeeper import. No idea why
they'd be needed.

> In the tools case I think we already have a way to inject arbitrary -L
> and -I options -- so maybe this can just go away?

Sounds good to me. :-)

> CCing Ian (who wrote 16950) and Olaf, whose been doing stuff in this
> area.
> 
> > diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
> > --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> > @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
> >  PREFIX ?= /usr
> >  BINDIR = $(PREFIX)/bin
> >  INCLUDEDIR = $(PREFIX)/include
> > -LIBLEAFDIR = lib
> > -LIBLEAFDIR_x86_32 = lib
> > -LIBLEAFDIR_x86_64 ?= lib64
> > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> > +LIBEXEC = $(PREFIX)/lib/xen/bin
> 
> Wouldn't this be $(LIBDIR)/xen/bin ?

No, the old behavior (which I retained) is to always install
$(LIBEXEC) files to /usr/lib/xen/bin (since it was defined to
$(LIBDIR_x86_32), which expands to /usr/lib), even on non-Itanium
64-bit Linux platforms. This results in having paths like:

/usr/lib/xen/bin/qemu-dm
/usr/lib/xen/bin/stubdom-dm
/usr/lib/xen/bin/stubdompath.sh

Confusingly, we also install "private" binaries to $(PRIVATE_BINDIR),
which expands to $(PRIVATE_PREFIX)/bin which expands to $(LIBDIR)/xen/bin,
which expands to /usr/lib64/xen/bin. This results in paths like:

/usr/lib64/xen/bin/lsevtchn
/usr/lib64/xen/bin/qemu-dm
/usr/lib64/xen/bin/readnotes
/usr/lib64/xen/bin/xc_restore
/usr/lib64/xen/bin/xc_save
/usr/lib64/xen/bin/xenconsole
/usr/lib64/xen/bin/xenctx

This split doesn't match my personal taste, which is for all
"internal" binaries to live in /usr/libexec. Now, with my FHS / LSB
hat on (which is admittedly very dusty, full of holes, and smells a
bit), there's no current ratified standard guidance for using
/usr/libexec on Linux systems, but the first FHS 3.0 [1] includes it.

> I suppose configure defines a libexec but it isn't the one we want?

By default, configure will define libexec to be /usr/libexec, which I
like. If we switched to using the value provided from configure, we
people who don't like /usr/libexec could just provide a different
value at ./configure time.

> > @@ -131,27 +130,12 @@ static int load_plugins(void)
> >  	int err;
> >  	int ret = -1;
> >  
> > -#if defined(FSIMAGE_FSDIR)
> > +#if !defined(FSIMAGE_FSDIR)
> > +#error FSIMAGE_FSDIR not defined
> 
> FWIW I'd be happy with the regular message you get from using an
> undefined symbol, if you want to ditch this #error.

Sounds good to me. Thanks for the review!

Matt

[1] http://www.linuxbase.org/betaspecs/fhs/fhs.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 18:44:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 18:44: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 1ShmMg-0001mJ-HP; Thu, 21 Jun 2012 18:44:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1ShmMf-0001mE-9G
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 18:44:21 +0000
Received: from [193.109.254.147:54315] by server-10.bemta-14.messagelabs.com
	id 1F/EF-05433-48B63EF4; Thu, 21 Jun 2012 18:44:20 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340304258!10104472!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU3MTk5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22305 invoked from network); 21 Jun 2012 18:44:19 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 18:44:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340304259; x=1371840259;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=5OljKYI/1tPmrNKVvokIbBadZ3GZVAAAWFK/ERPZwX4=;
	b=Ry4jfxVQP72+gFQB7R6tDjhIrs1SQfpyU7D0boiVtNm7bgOYkDzn074z
	FEH2YlANBGAlb5X9UL1UU/sDMkAZQg==;
X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208";a="318608069"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2012 18:43:54 +0000
Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.63.104.101])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with SMTP id
	q5LIhqC9029373; Thu, 21 Jun 2012 18:43:52 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Thu, 21 Jun 2012 11:43:49 -0700
Date: Thu, 21 Jun 2012 11:43:49 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120621184036.GD2640@US-SEA-R8XVZTX>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340267605.21872.10.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Olaf Hering <olaf@aepfle.de>,
	"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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 01:33:25AM -0700, Ian Campbell wrote:
> On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > diff -r 32034d1914a6 -r 4ba90ad04596 Config.mk
> > --- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
> > @@ -43,6 +43,7 @@ endif
> >  
> >  include $(XEN_ROOT)/config/$(XEN_OS).mk
> >  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
> > +include $(XEN_ROOT)/config/Tools.mk
> 
> Unfortunately this won't work, our policy is that you only need to
> invoke configure in order to build the tools -- so the top-level
> Config.mk cannot include configure generated files.

Aah, sorry. Good to know.

> >  SHAREDIR    ?= $(PREFIX)/share
> >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > @@ -67,7 +68,7 @@ endef
> >  
> >  ifneq ($(EXTRA_PREFIX),)
> >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> 
> since we are sort of reverting 16950:0faf620bc749 here this could in
> theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> include Tools.mk though. :-/

That would result in looking in /some/extra/prefix/usr/lib, which is
not what I'd expect is desired. 

> Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
> hypervisor and other non-tools builds? If not then we could consider
> pushing it down a level.

That stuff has been around since the bitkeeper import. No idea why
they'd be needed.

> In the tools case I think we already have a way to inject arbitrary -L
> and -I options -- so maybe this can just go away?

Sounds good to me. :-)

> CCing Ian (who wrote 16950) and Olaf, whose been doing stuff in this
> area.
> 
> > diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
> > --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> > @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
> >  PREFIX ?= /usr
> >  BINDIR = $(PREFIX)/bin
> >  INCLUDEDIR = $(PREFIX)/include
> > -LIBLEAFDIR = lib
> > -LIBLEAFDIR_x86_32 = lib
> > -LIBLEAFDIR_x86_64 ?= lib64
> > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> > +LIBEXEC = $(PREFIX)/lib/xen/bin
> 
> Wouldn't this be $(LIBDIR)/xen/bin ?

No, the old behavior (which I retained) is to always install
$(LIBEXEC) files to /usr/lib/xen/bin (since it was defined to
$(LIBDIR_x86_32), which expands to /usr/lib), even on non-Itanium
64-bit Linux platforms. This results in having paths like:

/usr/lib/xen/bin/qemu-dm
/usr/lib/xen/bin/stubdom-dm
/usr/lib/xen/bin/stubdompath.sh

Confusingly, we also install "private" binaries to $(PRIVATE_BINDIR),
which expands to $(PRIVATE_PREFIX)/bin which expands to $(LIBDIR)/xen/bin,
which expands to /usr/lib64/xen/bin. This results in paths like:

/usr/lib64/xen/bin/lsevtchn
/usr/lib64/xen/bin/qemu-dm
/usr/lib64/xen/bin/readnotes
/usr/lib64/xen/bin/xc_restore
/usr/lib64/xen/bin/xc_save
/usr/lib64/xen/bin/xenconsole
/usr/lib64/xen/bin/xenctx

This split doesn't match my personal taste, which is for all
"internal" binaries to live in /usr/libexec. Now, with my FHS / LSB
hat on (which is admittedly very dusty, full of holes, and smells a
bit), there's no current ratified standard guidance for using
/usr/libexec on Linux systems, but the first FHS 3.0 [1] includes it.

> I suppose configure defines a libexec but it isn't the one we want?

By default, configure will define libexec to be /usr/libexec, which I
like. If we switched to using the value provided from configure, we
people who don't like /usr/libexec could just provide a different
value at ./configure time.

> > @@ -131,27 +130,12 @@ static int load_plugins(void)
> >  	int err;
> >  	int ret = -1;
> >  
> > -#if defined(FSIMAGE_FSDIR)
> > +#if !defined(FSIMAGE_FSDIR)
> > +#error FSIMAGE_FSDIR not defined
> 
> FWIW I'd be happy with the regular message you get from using an
> undefined symbol, if you want to ditch this #error.

Sounds good to me. Thanks for the review!

Matt

[1] http://www.linuxbase.org/betaspecs/fhs/fhs.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 21:10:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 21: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 1Shod5-0003Cp-VE; Thu, 21 Jun 2012 21:09:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1Shod4-0003Ch-97
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 21:09:26 +0000
Received: from [85.158.139.83:23016] by server-3.bemta-5.messagelabs.com id
	04/83-03367-58D83EF4; Thu, 21 Jun 2012 21:09:25 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340312963!28209939!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23878 invoked from network); 21 Jun 2012 21:09:24 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 21:09:24 -0000
Received: from mail37-tx2-R.bigfish.com (10.9.14.237) by
	TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 21:07:55 +0000
Received: from mail37-tx2 (localhost [127.0.0.1])	by mail37-tx2-R.bigfish.com
	(Postfix) with ESMTP id CDB7780437	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 21:07:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.38; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: 1
X-BigFish: VPS1(zzzz1202hzzz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail37-tx2 (localhost.localdomain [127.0.0.1]) by mail37-tx2
	(MessageSwitch) id 1340312873363979_22259;
	Thu, 21 Jun 2012 21:07:53 +0000 (UTC)
Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.252])	by
	mail37-tx2.bigfish.com (Postfix) with ESMTP id 4C134180133	for
	<xen-devel@lists.xen.org>; Thu, 21 Jun 2012 21:07:53 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.38) by TX2EHSMHS020.bigfish.com
	(10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Thu, 21 Jun 2012 21:07:53 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM26.ds.Vanderbilt.edu ([fe80::b8bb:fb81:d5ba:1d6%11]) with
	mapi; Thu, 21 Jun 2012 16:09:20 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Jun 2012 16:09:19 -0500
Thread-Topic: Regarding domctl hypercall from dom0 kernel...
Thread-Index: AQHNT/BbT10Y+2QqQkyBVQwWZfC/jg==
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A12EA62C163@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Subject: [Xen-devel] Regarding domctl hypercall from dom0 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

Hi,

I am trying to invoke domctl hypercall (XEN_DOMCTL_SCHEDOP_putinfo) from dom0 kernel. For my research i need to dynamically change the credits for guest domains. Following are my code additions,  

Kernel modifications: 
In /source/arch/x86/include/asm/xen/hypercall.h added

static inline int
HYPERVISOR_domctl(unsigned long arg)
{
        return _hypercall1(int, domctl, arg);
}


In source/include/xen/interface/xen.h added 

#define __HYPERVISOR_domctl               36


added a system call to invoke hypercall from dom0 user space, system call code is as follows

#include <linux/linkage.h>
#include <linux/kernel.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>

#ifndef uint64_aligned_t
#define uint64_aligned_t uint64_t
#endif

#define XEN_DOMCTL_INTERFACE_VERSION 0x00000007

/* XEN_DOMCTL_scheduler_op */
/* Scheduler types. */
#define XEN_SCHEDULER_SEDF     4
#define XEN_SCHEDULER_CREDIT   5
#define XEN_SCHEDULER_CREDIT2  6
#define XEN_SCHEDULER_ARINC653 7

/* Set or get info? */
#define XEN_DOMCTL_SCHEDOP_putinfo 0
#define XEN_DOMCTL_SCHEDOP_getinfo 1
struct xen_domctl_scheduler_op {
    uint32_t sched_id;  /* XEN_SCHEDULER_* */
    uint32_t cmd;       /* XEN_DOMCTL_SCHEDOP_* */
    union {
        struct xen_domctl_sched_sedf {
            uint64_aligned_t period;
            uint64_aligned_t slice;
            uint64_aligned_t latency;
            uint32_t extratime;
            uint32_t weight;
        } sedf;
        struct xen_domctl_sched_credit {
            uint16_t weight;
            uint16_t cap;
        } credit;
        struct xen_domctl_sched_credit2 {
            uint16_t weight;
        } credit2;
    } u;
};
typedef struct xen_domctl_scheduler_op xen_domctl_scheduler_op_t;


struct xen_domctl_synced {
    char is_synchronized;
    int sync_done;
    char sync_currently_running;
};
typedef struct xen_domctl_synced xen_domctl_synced_t;

 struct xen_domctl {
        uint32_t cmd;
        #define XEN_DOMCTL_scheduler_op                  16
        #define XEN_DOMCTL_set_synced                    68
        #define XEN_DOMCTL_get_synced                    69
        uint32_t interface_version; /* XEN_DOMCTL_INTERFACE_VERSION */
        domid_t  domain;
        union {
                struct xen_domctl_scheduler_op      scheduler_op;
                struct xen_domctl_synced            synced;

                uint8_t                             pad[128];
        } u;
};
typedef struct xen_domctl xen_domctl_t;

asmlinkage long sys_mycall(int i)
{
        int retval;
        xen_domctl_t dom;

        dom.domain = i;
        dom.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
        dom.cmd = XEN_DOMCTL_scheduler_op;
        dom.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
        dom.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
        dom.u.scheduler_op.u.credit.weight=128;
        dom.u.scheduler_op.u.credit.cap = 1;
  
        retval = HYPERVISOR_domctl((unsigned long)&dom);
        printk(KERN_DEBUG "XEN_DOMCTL_SCHEDOP_putinfo hypercall returned %d\n", retval);

        return retval;
}



Hypercall returns a -22 (EINVAL) error code.

Any help would be appreciated.

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 21:10:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 21: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 1Shod5-0003Cp-VE; Thu, 21 Jun 2012 21:09:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1Shod4-0003Ch-97
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 21:09:26 +0000
Received: from [85.158.139.83:23016] by server-3.bemta-5.messagelabs.com id
	04/83-03367-58D83EF4; Thu, 21 Jun 2012 21:09:25 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340312963!28209939!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23878 invoked from network); 21 Jun 2012 21:09:24 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 21:09:24 -0000
Received: from mail37-tx2-R.bigfish.com (10.9.14.237) by
	TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 21:07:55 +0000
Received: from mail37-tx2 (localhost [127.0.0.1])	by mail37-tx2-R.bigfish.com
	(Postfix) with ESMTP id CDB7780437	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 21:07:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.38; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: 1
X-BigFish: VPS1(zzzz1202hzzz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail37-tx2 (localhost.localdomain [127.0.0.1]) by mail37-tx2
	(MessageSwitch) id 1340312873363979_22259;
	Thu, 21 Jun 2012 21:07:53 +0000 (UTC)
Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.252])	by
	mail37-tx2.bigfish.com (Postfix) with ESMTP id 4C134180133	for
	<xen-devel@lists.xen.org>; Thu, 21 Jun 2012 21:07:53 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.38) by TX2EHSMHS020.bigfish.com
	(10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Thu, 21 Jun 2012 21:07:53 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM26.ds.Vanderbilt.edu ([fe80::b8bb:fb81:d5ba:1d6%11]) with
	mapi; Thu, 21 Jun 2012 16:09:20 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Jun 2012 16:09:19 -0500
Thread-Topic: Regarding domctl hypercall from dom0 kernel...
Thread-Index: AQHNT/BbT10Y+2QqQkyBVQwWZfC/jg==
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A12EA62C163@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Subject: [Xen-devel] Regarding domctl hypercall from dom0 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

Hi,

I am trying to invoke domctl hypercall (XEN_DOMCTL_SCHEDOP_putinfo) from dom0 kernel. For my research i need to dynamically change the credits for guest domains. Following are my code additions,  

Kernel modifications: 
In /source/arch/x86/include/asm/xen/hypercall.h added

static inline int
HYPERVISOR_domctl(unsigned long arg)
{
        return _hypercall1(int, domctl, arg);
}


In source/include/xen/interface/xen.h added 

#define __HYPERVISOR_domctl               36


added a system call to invoke hypercall from dom0 user space, system call code is as follows

#include <linux/linkage.h>
#include <linux/kernel.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>

#ifndef uint64_aligned_t
#define uint64_aligned_t uint64_t
#endif

#define XEN_DOMCTL_INTERFACE_VERSION 0x00000007

/* XEN_DOMCTL_scheduler_op */
/* Scheduler types. */
#define XEN_SCHEDULER_SEDF     4
#define XEN_SCHEDULER_CREDIT   5
#define XEN_SCHEDULER_CREDIT2  6
#define XEN_SCHEDULER_ARINC653 7

/* Set or get info? */
#define XEN_DOMCTL_SCHEDOP_putinfo 0
#define XEN_DOMCTL_SCHEDOP_getinfo 1
struct xen_domctl_scheduler_op {
    uint32_t sched_id;  /* XEN_SCHEDULER_* */
    uint32_t cmd;       /* XEN_DOMCTL_SCHEDOP_* */
    union {
        struct xen_domctl_sched_sedf {
            uint64_aligned_t period;
            uint64_aligned_t slice;
            uint64_aligned_t latency;
            uint32_t extratime;
            uint32_t weight;
        } sedf;
        struct xen_domctl_sched_credit {
            uint16_t weight;
            uint16_t cap;
        } credit;
        struct xen_domctl_sched_credit2 {
            uint16_t weight;
        } credit2;
    } u;
};
typedef struct xen_domctl_scheduler_op xen_domctl_scheduler_op_t;


struct xen_domctl_synced {
    char is_synchronized;
    int sync_done;
    char sync_currently_running;
};
typedef struct xen_domctl_synced xen_domctl_synced_t;

 struct xen_domctl {
        uint32_t cmd;
        #define XEN_DOMCTL_scheduler_op                  16
        #define XEN_DOMCTL_set_synced                    68
        #define XEN_DOMCTL_get_synced                    69
        uint32_t interface_version; /* XEN_DOMCTL_INTERFACE_VERSION */
        domid_t  domain;
        union {
                struct xen_domctl_scheduler_op      scheduler_op;
                struct xen_domctl_synced            synced;

                uint8_t                             pad[128];
        } u;
};
typedef struct xen_domctl xen_domctl_t;

asmlinkage long sys_mycall(int i)
{
        int retval;
        xen_domctl_t dom;

        dom.domain = i;
        dom.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
        dom.cmd = XEN_DOMCTL_scheduler_op;
        dom.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
        dom.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
        dom.u.scheduler_op.u.credit.weight=128;
        dom.u.scheduler_op.u.credit.cap = 1;
  
        retval = HYPERVISOR_domctl((unsigned long)&dom);
        printk(KERN_DEBUG "XEN_DOMCTL_SCHEDOP_putinfo hypercall returned %d\n", retval);

        return retval;
}



Hypercall returns a -22 (EINVAL) error code.

Any help would be appreciated.

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 21:15:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 21:15: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 1ShoiJ-0003MZ-NI; Thu, 21 Jun 2012 21:14:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1ShoiH-0003MS-IF
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 21:14:49 +0000
Received: from [85.158.139.83:41874] by server-11.bemta-5.messagelabs.com id
	52/55-20400-7CE83EF4; Thu, 21 Jun 2012 21:14:47 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340313287!21668074!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15255 invoked from network); 21 Jun 2012 21:14:47 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 21:14:47 -0000
Received: from mail35-db3-R.bigfish.com (10.3.81.231) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 21:13:19 +0000
Received: from mail35-db3 (localhost [127.0.0.1])	by mail35-db3-R.bigfish.com
	(Postfix) with ESMTP id 0543842042B	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 21:13:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.30; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: 0
X-BigFish: VPS0(zz4015Izz1202hzzz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail35-db3 (localhost.localdomain [127.0.0.1]) by mail35-db3
	(MessageSwitch) id 1340313196963346_20986;
	Thu, 21 Jun 2012 21:13:16 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.231])	by
	mail35-db3.bigfish.com (Postfix) with ESMTP id DFE8932023A	for
	<xen-devel@lists.xen.org>; Thu, 21 Jun 2012 21:13:16 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.30) by DB3EHSMHS008.bigfish.com
	(10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Thu, 21 Jun 2012 21:13:16 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM24.ds.Vanderbilt.edu ([::1]) with mapi;
	Thu, 21 Jun 2012 16:14:40 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Jun 2012 16:10:12 -0500
Thread-Topic: Regarding selecting scheduler at boot time...
Thread-Index: AQHNT/LeKPYlX2jG/kqxh2Ntk4I9fw==
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Subject: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30. 

When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0. However, if I supply sched=credit (default) or sched=credit2, specified scheduler gets selected and dom0 boots perfectly fine. Not sure if it is a bug.

Thanks,
Ashish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 21:15:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 21:15: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 1ShoiJ-0003MZ-NI; Thu, 21 Jun 2012 21:14:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1ShoiH-0003MS-IF
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 21:14:49 +0000
Received: from [85.158.139.83:41874] by server-11.bemta-5.messagelabs.com id
	52/55-20400-7CE83EF4; Thu, 21 Jun 2012 21:14:47 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340313287!21668074!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15255 invoked from network); 21 Jun 2012 21:14:47 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 21:14:47 -0000
Received: from mail35-db3-R.bigfish.com (10.3.81.231) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 21:13:19 +0000
Received: from mail35-db3 (localhost [127.0.0.1])	by mail35-db3-R.bigfish.com
	(Postfix) with ESMTP id 0543842042B	for <xen-devel@lists.xen.org>;
	Thu, 21 Jun 2012 21:13:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.30; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: 0
X-BigFish: VPS0(zz4015Izz1202hzzz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail35-db3 (localhost.localdomain [127.0.0.1]) by mail35-db3
	(MessageSwitch) id 1340313196963346_20986;
	Thu, 21 Jun 2012 21:13:16 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.231])	by
	mail35-db3.bigfish.com (Postfix) with ESMTP id DFE8932023A	for
	<xen-devel@lists.xen.org>; Thu, 21 Jun 2012 21:13:16 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.30) by DB3EHSMHS008.bigfish.com
	(10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Thu, 21 Jun 2012 21:13:16 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM24.ds.Vanderbilt.edu ([::1]) with mapi;
	Thu, 21 Jun 2012 16:14:40 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Jun 2012 16:10:12 -0500
Thread-Topic: Regarding selecting scheduler at boot time...
Thread-Index: AQHNT/LeKPYlX2jG/kqxh2Ntk4I9fw==
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Subject: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30. 

When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0. However, if I supply sched=credit (default) or sched=credit2, specified scheduler gets selected and dom0 boots perfectly fine. Not sure if it is a bug.

Thanks,
Ashish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 21:59:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 21: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 1ShpP8-0004LL-JP; Thu, 21 Jun 2012 21:59:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShpP7-0004LF-2m
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 21:59:05 +0000
Received: from [85.158.138.51:18093] by server-7.bemta-3.messagelabs.com id
	21/2B-10113-82993EF4; Thu, 21 Jun 2012 21:59:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340315943!10230219!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2246 invoked from network); 21 Jun 2012 21:59:03 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 21:59:03 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79051581; Thu, 21 Jun 2012 23:59:02 +0200
Message-ID: <1340315931.2757.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 23:58:51 +0200
In-Reply-To: <20451.22582.717552.469036@mariner.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
	<20451.22582.717552.469036@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "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] xl: fix sedf parameters 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: multipart/mixed; boundary="===============8840180145757138276=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8840180145757138276==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-/45YSa9tbLK/MK3xgREa"


--=-/45YSa9tbLK/MK3xgREa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 18:21 +0100, Ian Jackson wrote:=20
> Ian Campbell writes ("Re: [PATCH] xl: fix sedf parameters checking"):
> > On Wed, 2012-06-20 at 18:09 +0100, Dario Faggioli wrote:
> > > 9d1fd58ff602 was bogous in not letting a new domain being created
> > > if its scheduling parameters --when running under the sedf scheduler-=
-
> > > were not fully specified, making creation fail like in this example
> > > here below:
> ...
> >=20
> > Thanks for this. I'd like to get it in ASAP so we can start passing
> > tests again. I have a few queries though unfortunately...
>=20
> You'll see I've applied it already. =20
>
Yes, I saw that earlier in the afternoon.

> I would be happy to take a
> followup cleanup/fixup.
>=20
I already sent something like that:

Subject: 	[PATCH] xl: improve the comments for sedf parameters checking
 Date: 	        Thu, 21 Jun 2012 16:19:50 +0200
 Message-id: 	<fe85a8d600800524917c.1340288390@Solace>

:-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-/45YSa9tbLK/MK3xgREa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jmRsACgkQk4XaBE3IOsT3CQCfRLGoUP7/eWkGP39QEn2MBXxl
7RkAn3PsxJ2ROo3fh+K2vLm5c0+zVUok
=E2dO
-----END PGP SIGNATURE-----

--=-/45YSa9tbLK/MK3xgREa--



--===============8840180145757138276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8840180145757138276==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 21:59:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 21: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 1ShpP8-0004LL-JP; Thu, 21 Jun 2012 21:59:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShpP7-0004LF-2m
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 21:59:05 +0000
Received: from [85.158.138.51:18093] by server-7.bemta-3.messagelabs.com id
	21/2B-10113-82993EF4; Thu, 21 Jun 2012 21:59:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340315943!10230219!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2246 invoked from network); 21 Jun 2012 21:59:03 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	21 Jun 2012 21:59:03 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79051581; Thu, 21 Jun 2012 23:59:02 +0200
Message-ID: <1340315931.2757.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 23:58:51 +0200
In-Reply-To: <20451.22582.717552.469036@mariner.uk.xensource.com>
References: <cbd6b5a7d0451a98a8c6.1340212196@Solace>
	<1340272422.21872.53.camel@zakaz.uk.xensource.com>
	<20451.22582.717552.469036@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "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] xl: fix sedf parameters 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: multipart/mixed; boundary="===============8840180145757138276=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8840180145757138276==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-/45YSa9tbLK/MK3xgREa"


--=-/45YSa9tbLK/MK3xgREa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 18:21 +0100, Ian Jackson wrote:=20
> Ian Campbell writes ("Re: [PATCH] xl: fix sedf parameters checking"):
> > On Wed, 2012-06-20 at 18:09 +0100, Dario Faggioli wrote:
> > > 9d1fd58ff602 was bogous in not letting a new domain being created
> > > if its scheduling parameters --when running under the sedf scheduler-=
-
> > > were not fully specified, making creation fail like in this example
> > > here below:
> ...
> >=20
> > Thanks for this. I'd like to get it in ASAP so we can start passing
> > tests again. I have a few queries though unfortunately...
>=20
> You'll see I've applied it already. =20
>
Yes, I saw that earlier in the afternoon.

> I would be happy to take a
> followup cleanup/fixup.
>=20
I already sent something like that:

Subject: 	[PATCH] xl: improve the comments for sedf parameters checking
 Date: 	        Thu, 21 Jun 2012 16:19:50 +0200
 Message-id: 	<fe85a8d600800524917c.1340288390@Solace>

:-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-/45YSa9tbLK/MK3xgREa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jmRsACgkQk4XaBE3IOsT3CQCfRLGoUP7/eWkGP39QEn2MBXxl
7RkAn3PsxJ2ROo3fh+K2vLm5c0+zVUok
=E2dO
-----END PGP SIGNATURE-----

--=-/45YSa9tbLK/MK3xgREa--



--===============8840180145757138276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8840180145757138276==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 22:02:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 22: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 1ShpSW-0004Uw-6u; Thu, 21 Jun 2012 22:02:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShpSU-0004Uj-8a
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 22:02:34 +0000
Received: from [193.109.254.147:48314] by server-12.bemta-14.messagelabs.com
	id D3/70-30461-9F993EF4; Thu, 21 Jun 2012 22:02:33 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340316152!10970227!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3536 invoked from network); 21 Jun 2012 22:02:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 22:02:32 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79051607; Fri, 22 Jun 2012 00:02:32 +0200
Message-ID: <1340316146.2757.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
Date: Fri, 22 Jun 2012 00:02:26 +0200
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8605745441039028258=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8605745441039028258==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-qcHw4d5XpF0O6r4pMtaG"


--=-qcHw4d5XpF0O6r4pMtaG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 16:10 -0500, Tapdiya, Ashish wrote:=20
> Hi,
>=20
Hello,

> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.=20
>=20
> When I supply sched=3Dsedf or sched=3Darinc653 as boot parameter I can't =
boot into dom0.=20
>
ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console (see this:
http://wiki.xen.org/wiki/Xen_Serial_Console).

Also, what machine are we talking about? E.g., how many and what kind of
CPUs?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-qcHw4d5XpF0O6r4pMtaG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jmfIACgkQk4XaBE3IOsTK5ACeO1CWGbOsj+7A/Skvz5OE7u0D
pV0An3kfVWwdOFUxBfMDoTvpfIre8j0Q
=PnHL
-----END PGP SIGNATURE-----

--=-qcHw4d5XpF0O6r4pMtaG--



--===============8605745441039028258==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8605745441039028258==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 22:02:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 22: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 1ShpSW-0004Uw-6u; Thu, 21 Jun 2012 22:02:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1ShpSU-0004Uj-8a
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 22:02:34 +0000
Received: from [193.109.254.147:48314] by server-12.bemta-14.messagelabs.com
	id D3/70-30461-9F993EF4; Thu, 21 Jun 2012 22:02:33 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340316152!10970227!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3536 invoked from network); 21 Jun 2012 22:02:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	21 Jun 2012 22:02:32 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79051607; Fri, 22 Jun 2012 00:02:32 +0200
Message-ID: <1340316146.2757.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
Date: Fri, 22 Jun 2012 00:02:26 +0200
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8605745441039028258=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8605745441039028258==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-qcHw4d5XpF0O6r4pMtaG"


--=-qcHw4d5XpF0O6r4pMtaG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-21 at 16:10 -0500, Tapdiya, Ashish wrote:=20
> Hi,
>=20
Hello,

> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.=20
>=20
> When I supply sched=3Dsedf or sched=3Darinc653 as boot parameter I can't =
boot into dom0.=20
>
ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console (see this:
http://wiki.xen.org/wiki/Xen_Serial_Console).

Also, what machine are we talking about? E.g., how many and what kind of
CPUs?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-qcHw4d5XpF0O6r4pMtaG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/jmfIACgkQk4XaBE3IOsTK5ACeO1CWGbOsj+7A/Skvz5OE7u0D
pV0An3kfVWwdOFUxBfMDoTvpfIre8j0Q
=PnHL
-----END PGP SIGNATURE-----

--=-qcHw4d5XpF0O6r4pMtaG--



--===============8605745441039028258==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8605745441039028258==--



From xen-devel-bounces@lists.xen.org Thu Jun 21 22:33:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 22: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 1ShpwF-0004qT-0p; Thu, 21 Jun 2012 22:33:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1ShpwD-0004qO-LX
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 22:33:17 +0000
Received: from [85.158.143.99:38488] by server-2.bemta-4.messagelabs.com id
	48/44-17938-D21A3EF4; Thu, 21 Jun 2012 22:33:17 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340317996!23277578!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26104 invoked from network); 21 Jun 2012 22:33:16 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.204)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 22:33:16 -0000
Received: from mail13-am1-R.bigfish.com (10.3.201.249) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 22:31:48 +0000
Received: from mail13-am1 (localhost [127.0.0.1])	by mail13-am1-R.bigfish.com
	(Postfix) with ESMTP id 1361B205AD;
	Thu, 21 Jun 2012 22:31:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.26; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: -5
X-BigFish: VPS-5(zz98dI9371I936eI146fI1432I4015Izz1202hzz8275dhz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1
	(MessageSwitch) id 1340317905275431_1239;
	Thu, 21 Jun 2012 22:31:45 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.251])	by
	mail13-am1.bigfish.com (Postfix) with ESMTP id 419D4160049;
	Thu, 21 Jun 2012 22:31:45 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.26) by AM1EHSMHS005.bigfish.com
	(10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Thu, 21 Jun 2012 22:31:45 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-HCWNEM20.ds.Vanderbilt.edu ([::1]) with mapi;
	Thu, 21 Jun 2012 17:32:58 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 17:31:13 -0500
Thread-Topic: [Xen-devel] Regarding selecting scheduler at boot time...
Thread-Index: Ac1P+ZGw4u38l8d6R9WwEQUCxWmNhgAA/7V8
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A12EA62C166@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>,
	<1340316146.2757.4.camel@Abyss>
In-Reply-To: <1340316146.2757.4.camel@Abyss>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario,

I dont have a log currently, I will get it as soon as possible. I am using a single physical machine, Intel Xeon 2.4 Ghz Quad Core.

Thanks,
~Ashish 
________________________________________
From: Dario Faggioli [raistlin@linux.it]
Sent: Thursday, June 21, 2012 5:02 PM
To: Tapdiya, Ashish
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...

On Thu, 2012-06-21 at 16:10 -0500, Tapdiya, Ashish wrote:
> Hi,
>
Hello,

> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0.
>
ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console (see this:
http://wiki.xen.org/wiki/Xen_Serial_Console).

Also, what machine are we talking about? E.g., how many and what kind of
CPUs?

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 Thu Jun 21 22:33:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 22: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 1ShpwF-0004qT-0p; Thu, 21 Jun 2012 22:33:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1ShpwD-0004qO-LX
	for xen-devel@lists.xen.org; Thu, 21 Jun 2012 22:33:17 +0000
Received: from [85.158.143.99:38488] by server-2.bemta-4.messagelabs.com id
	48/44-17938-D21A3EF4; Thu, 21 Jun 2012 22:33:17 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340317996!23277578!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26104 invoked from network); 21 Jun 2012 22:33:16 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.204)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Jun 2012 22:33:16 -0000
Received: from mail13-am1-R.bigfish.com (10.3.201.249) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 21 Jun 2012 22:31:48 +0000
Received: from mail13-am1 (localhost [127.0.0.1])	by mail13-am1-R.bigfish.com
	(Postfix) with ESMTP id 1361B205AD;
	Thu, 21 Jun 2012 22:31:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.26; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: -5
X-BigFish: VPS-5(zz98dI9371I936eI146fI1432I4015Izz1202hzz8275dhz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1
	(MessageSwitch) id 1340317905275431_1239;
	Thu, 21 Jun 2012 22:31:45 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.251])	by
	mail13-am1.bigfish.com (Postfix) with ESMTP id 419D4160049;
	Thu, 21 Jun 2012 22:31:45 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.26) by AM1EHSMHS005.bigfish.com
	(10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Thu, 21 Jun 2012 22:31:45 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-HCWNEM20.ds.Vanderbilt.edu ([::1]) with mapi;
	Thu, 21 Jun 2012 17:32:58 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 21 Jun 2012 17:31:13 -0500
Thread-Topic: [Xen-devel] Regarding selecting scheduler at boot time...
Thread-Index: Ac1P+ZGw4u38l8d6R9WwEQUCxWmNhgAA/7V8
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A12EA62C166@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>,
	<1340316146.2757.4.camel@Abyss>
In-Reply-To: <1340316146.2757.4.camel@Abyss>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario,

I dont have a log currently, I will get it as soon as possible. I am using a single physical machine, Intel Xeon 2.4 Ghz Quad Core.

Thanks,
~Ashish 
________________________________________
From: Dario Faggioli [raistlin@linux.it]
Sent: Thursday, June 21, 2012 5:02 PM
To: Tapdiya, Ashish
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...

On Thu, 2012-06-21 at 16:10 -0500, Tapdiya, Ashish wrote:
> Hi,
>
Hello,

> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0.
>
ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console (see this:
http://wiki.xen.org/wiki/Xen_Serial_Console).

Also, what machine are we talking about? E.g., how many and what kind of
CPUs?

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 Thu Jun 21 22:59:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 22: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 1ShqLK-00056O-BY; Thu, 21 Jun 2012 22:59: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 1ShqLI-00056G-Hp
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 22:59:12 +0000
Received: from [85.158.138.51:30144] by server-12.bemta-3.messagelabs.com id
	B9/E3-30206-E37A3EF4; Thu, 21 Jun 2012 22:59:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340319549!27810500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6182 invoked from network); 21 Jun 2012 22:59:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 22:59:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,454,1336348800"; d="scan'208";a="13158560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 22:59:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 23:59:09 +0100
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 1ShqLF-0007ca-0Z;
	Thu, 21 Jun 2012 22:59:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShqLE-0008PU-Vd;
	Thu, 21 Jun 2012 23:59:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13300-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 23:59:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13300: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13300 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13300/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13090
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13090
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13090
 build-i386                    4 xen-build                 fail REGR. vs. 13090

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 21 22:59:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Jun 2012 22: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 1ShqLK-00056O-BY; Thu, 21 Jun 2012 22:59: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 1ShqLI-00056G-Hp
	for xen-devel@lists.xensource.com; Thu, 21 Jun 2012 22:59:12 +0000
Received: from [85.158.138.51:30144] by server-12.bemta-3.messagelabs.com id
	B9/E3-30206-E37A3EF4; Thu, 21 Jun 2012 22:59:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340319549!27810500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6182 invoked from network); 21 Jun 2012 22:59:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jun 2012 22:59:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,454,1336348800"; d="scan'208";a="13158560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jun 2012 22:59:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 21 Jun 2012 23:59:09 +0100
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 1ShqLF-0007ca-0Z;
	Thu, 21 Jun 2012 22:59:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShqLE-0008PU-Vd;
	Thu, 21 Jun 2012 23:59:09 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13300-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 21 Jun 2012 23:59:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13300: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13300 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13300/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13090
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13090
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13090
 build-i386                    4 xen-build                 fail REGR. vs. 13090

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 02:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 02:06:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShtFZ-0002sO-Gj; Fri, 22 Jun 2012 02: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 1ShtFX-0002sJ-Hp
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 02:05:27 +0000
Received: from [85.158.139.83:42909] by server-6.bemta-5.messagelabs.com id
	03/98-11348-6E2D3EF4; Fri, 22 Jun 2012 02:05:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340330725!17650317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8438 invoked from network); 22 Jun 2012 02:05:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 02:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,454,1336348800"; d="scan'208";a="13159459"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 02: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.213.0; Fri, 22 Jun 2012 03:05:25 +0100
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 1ShtFU-0000DN-Sf;
	Fri, 22 Jun 2012 02:05:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShtFU-0007Ku-S2;
	Fri, 22 Jun 2012 03:05:24 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13299-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 03:05:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13299: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13299 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13299/

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. 13089

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13089

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  ffd1f786a7b5
baseline version:
 xen                  e231998f4e3a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 02:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 02:06:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1ShtFZ-0002sO-Gj; Fri, 22 Jun 2012 02: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 1ShtFX-0002sJ-Hp
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 02:05:27 +0000
Received: from [85.158.139.83:42909] by server-6.bemta-5.messagelabs.com id
	03/98-11348-6E2D3EF4; Fri, 22 Jun 2012 02:05:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340330725!17650317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8438 invoked from network); 22 Jun 2012 02:05:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 02:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,454,1336348800"; d="scan'208";a="13159459"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 02: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.213.0; Fri, 22 Jun 2012 03:05:25 +0100
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 1ShtFU-0000DN-Sf;
	Fri, 22 Jun 2012 02:05:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1ShtFU-0007Ku-S2;
	Fri, 22 Jun 2012 03:05:24 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13299-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 03:05:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13299: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13299 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13299/

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. 13089

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13089

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  ffd1f786a7b5
baseline version:
 xen                  e231998f4e3a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 03:01:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 03: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 1Shu7B-0003bQ-I3; Fri, 22 Jun 2012 03:00:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Shu79-0003bL-NK
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 03:00:52 +0000
Received: from [85.158.143.99:19496] by server-1.bemta-4.messagelabs.com id
	42/89-24392-3EFD3EF4; Fri, 22 Jun 2012 03:00:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340334050!28562034!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28308 invoked from network); 22 Jun 2012 03:00:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 03:00:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,455,1336348800"; d="scan'208";a="13159614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 03:00:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 04:00:50 +0100
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 1Shu77-0000WL-Si;
	Fri, 22 Jun 2012 03:00:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Shu77-0004Sz-Rj;
	Fri, 22 Jun 2012 04:00:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13302-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 04:00:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13302: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13302 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13302/

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. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
 build-i386                    4 xen-build                 fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 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-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  513d5e196e23
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  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-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 03:01:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 03: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 1Shu7B-0003bQ-I3; Fri, 22 Jun 2012 03:00:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Shu79-0003bL-NK
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 03:00:52 +0000
Received: from [85.158.143.99:19496] by server-1.bemta-4.messagelabs.com id
	42/89-24392-3EFD3EF4; Fri, 22 Jun 2012 03:00:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340334050!28562034!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28308 invoked from network); 22 Jun 2012 03:00:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 03:00:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,455,1336348800"; d="scan'208";a="13159614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 03:00:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 04:00:50 +0100
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 1Shu77-0000WL-Si;
	Fri, 22 Jun 2012 03:00:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Shu77-0004Sz-Rj;
	Fri, 22 Jun 2012 04:00:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13302-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 04:00:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13302: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13302 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13302/

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. 13025
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
 build-i386                    4 xen-build                 fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 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-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  513d5e196e23
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  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-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 04:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 04: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 1Shvjg-0004JU-L9; Fri, 22 Jun 2012 04:44: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 1Shvje-0004JP-Qs
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 04:44:43 +0000
Received: from [85.158.139.83:13667] by server-5.bemta-5.messagelabs.com id
	D1/C6-02722-A38F3EF4; Fri, 22 Jun 2012 04:44:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340340281!26213793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25314 invoked from network); 22 Jun 2012 04:44:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 04:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,455,1336348800"; d="scan'208";a="13160668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 04:44:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 05:44:41 +0100
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 1Shvjc-00014Z-Mn;
	Fri, 22 Jun 2012 04:44:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Shvjc-0002EE-Hi;
	Fri, 22 Jun 2012 05:44:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13312-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 05:44:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13312: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13312 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13312/

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. 13090
 test-amd64-i386-xl-credit2   3 host-install(3) broken in 13113 REGR. vs. 13090

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 13113

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13090
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13090

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-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-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail in 13113 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 13113 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 13113 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 13113 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 13113 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 13113 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 13113 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 13113 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 13113 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13113 never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop        fail in 13113 never pass
 test-i386-i386-win           16 leak-check/check      fail in 13113 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 13113 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 13113 never pass

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 04:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 04: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 1Shvjg-0004JU-L9; Fri, 22 Jun 2012 04:44: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 1Shvje-0004JP-Qs
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 04:44:43 +0000
Received: from [85.158.139.83:13667] by server-5.bemta-5.messagelabs.com id
	D1/C6-02722-A38F3EF4; Fri, 22 Jun 2012 04:44:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340340281!26213793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25314 invoked from network); 22 Jun 2012 04:44:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 04:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,455,1336348800"; d="scan'208";a="13160668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 04:44:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 05:44:41 +0100
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 1Shvjc-00014Z-Mn;
	Fri, 22 Jun 2012 04:44:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Shvjc-0002EE-Hi;
	Fri, 22 Jun 2012 05:44:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13312-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 05:44:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13312: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13312 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13312/

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. 13090
 test-amd64-i386-xl-credit2   3 host-install(3) broken in 13113 REGR. vs. 13090

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 13113

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13090
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13090

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-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-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail in 13113 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 13113 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 13113 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 13113 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 13113 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 13113 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 13113 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 13113 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 13113 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13113 never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop        fail in 13113 never pass
 test-i386-i386-win           16 leak-check/check      fail in 13113 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 13113 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 13113 never pass

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 08:03:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1Shypf-00070S-Oc; Fri, 22 Jun 2012 08:03:07 +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 1Shype-00070N-48
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:03:06 +0000
Received: from [85.158.138.51:48544] by server-12.bemta-3.messagelabs.com id
	0C/13-30206-9B624EF4; Fri, 22 Jun 2012 08:03:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340352184!27857466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26142 invoked from network); 22 Jun 2012 08:03:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 08:03:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 09:03:04 +0100
Message-Id: <4FE44303020000780008B486@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 09:03:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE35452020000780008B274@nat28.tlf.novell.com>
	<1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 19:01, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When attempting to use AMD's extension to access the extended PCI config
> space, only the low byte of the register number was being passed to XSM.
> Include the correct value of the register if this feature is enabled;
> otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
> access.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/arch/x86/traps.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 2264583..d836452 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1686,11 +1686,24 @@ static int pci_cfg_ok(struct domain *d, int write, 
> int size)
>  {
>      uint32_t machine_bdf;
>      uint16_t start, end;
> +    uint64_t msr_val;
>      if (!IS_PRIV(d))
>          return 0;
>  
>      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
>      start = d->arch.pci_cf8 & 0xFF;
> +    if ( d->arch.pci_cf8 & 0x0F000000 )
> +    {
> +        /* Possible AMD extended configuration access */
> +        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
> +             boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
> +            return 0;
> +        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
> +            return 0;
> +        if ( !(msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT)) )
> +            return 0;

Not quite, still. Let me come back with a modified version later
today.

Jan

> +        start |= (d->arch.pci_cf8 >> 16) & 0xF00;
> +    }
>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>          return 0;
> -- 
> 1.7.10.2




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 08:03:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1Shypf-00070S-Oc; Fri, 22 Jun 2012 08:03:07 +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 1Shype-00070N-48
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:03:06 +0000
Received: from [85.158.138.51:48544] by server-12.bemta-3.messagelabs.com id
	0C/13-30206-9B624EF4; Fri, 22 Jun 2012 08:03:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340352184!27857466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26142 invoked from network); 22 Jun 2012 08:03:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 08:03:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 09:03:04 +0100
Message-Id: <4FE44303020000780008B486@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 09:03:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE35452020000780008B274@nat28.tlf.novell.com>
	<1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 19:01, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When attempting to use AMD's extension to access the extended PCI config
> space, only the low byte of the register number was being passed to XSM.
> Include the correct value of the register if this feature is enabled;
> otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
> access.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/arch/x86/traps.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 2264583..d836452 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1686,11 +1686,24 @@ static int pci_cfg_ok(struct domain *d, int write, 
> int size)
>  {
>      uint32_t machine_bdf;
>      uint16_t start, end;
> +    uint64_t msr_val;
>      if (!IS_PRIV(d))
>          return 0;
>  
>      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
>      start = d->arch.pci_cf8 & 0xFF;
> +    if ( d->arch.pci_cf8 & 0x0F000000 )
> +    {
> +        /* Possible AMD extended configuration access */
> +        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
> +             boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
> +            return 0;
> +        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
> +            return 0;
> +        if ( !(msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT)) )
> +            return 0;

Not quite, still. Let me come back with a modified version later
today.

Jan

> +        start |= (d->arch.pci_cf8 >> 16) & 0xF00;
> +    }
>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>          return 0;
> -- 
> 1.7.10.2




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 08:18:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1Shz3j-0007D2-7z; Fri, 22 Jun 2012 08:17: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 1Shz3h-0007Cx-AB
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:17:37 +0000
Received: from [85.158.143.99:50241] by server-1.bemta-4.messagelabs.com id
	BB/58-24392-02A24EF4; Fri, 22 Jun 2012 08:17:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340353055!22188395!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12198 invoked from network); 22 Jun 2012 08:17:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	22 Jun 2012 08:17:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 09:17:35 +0100
Message-Id: <4FE44667020000780008B492@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 09:18:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBE901857.1__="
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH] AMD IOMMU: add mechanism to protect their PCI
 devices' config spaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartBE901857.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Recent Dom0 kernels want to disable PCI MSI on all devices, yet doing
so on AMD IOMMUs (which get represented by a PCI device) disables part
of the functionality set up by the hypervisor.

Add a mechanism to mark certain PCI devices as having write protected
config spaces (both through port based [method 1] accesses and, for
x86-64, mmconfig), and use that for AMD's IOMMUs.

Note that due to ptwr_do_page_fault() being run first, there'll be a
MEM_LOG() issued for each such mmconfig based write attempt. If that's
undesirable, the order of the calls in fixup_page_fault() would need
to be swapped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Wei Wang <wei.wang2@amd.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5209,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
     return 0;
 }
=20
+#ifdef __x86_64__
+/*************************
+ * fault handling for read-only MMIO pages
+ */
+
+struct mmio_ro_emulate_ctxt {
+    struct x86_emulate_ctxt ctxt;
+    unsigned long cr2;
+};
+
+static int mmio_ro_emulated_read(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    return X86EMUL_UNHANDLEABLE;
+}
+
+static int mmio_ro_emulated_write(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =3D
+        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
+
+    /* Only allow naturally-aligned stores at the original %cr2 address. =
*/
+    if ( ((bytes | offset) & (bytes - 1)) || offset !=3D mmio_ro_ctxt->cr2=
 )
+    {
+        MEM_LOG("mmio_ro_emulate: bad access (cr2=3D%lx, addr=3D%lx, =
bytes=3D%u)",
+                mmio_ro_ctxt->cr2, offset, bytes);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    return X86EMUL_OKAY;
+}
+
+static const struct x86_emulate_ops mmio_ro_emulate_ops =3D {
+    .read       =3D mmio_ro_emulated_read,
+    .insn_fetch =3D ptwr_emulated_read,
+    .write      =3D mmio_ro_emulated_write,
+};
+
+/* Check if guest is trying to modify a r/o MMIO page. */
+int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
+                          struct cpu_user_regs *regs)
+{
+    l1_pgentry_t      pte;
+    unsigned long     mfn;
+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) ?
+                                  32 : BITS_PER_LONG;
+    struct mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {
+        .ctxt.regs =3D regs,
+        .ctxt.addr_size =3D addr_size,
+        .ctxt.sp_size =3D addr_size,
+        .cr2 =3D addr
+    };
+    int rc;
+
+    /* Attempt to read the PTE that maps the VA being accessed. */
+    guest_get_eff_l1e(v, addr, &pte);
+
+    /* We are looking only for read-only mappings of MMIO pages. */
+    if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESE=
NT) )
+        return 0;
+
+    mfn =3D l1e_get_pfn(pte);
+    if ( mfn_valid(mfn) )
+    {
+        struct page_info *page =3D mfn_to_page(mfn);
+        struct domain *owner =3D page_get_owner_and_reference(page);
+
+        if ( owner )
+            put_page(page);
+        if ( owner !=3D dom_io )
+            return 0;
+    }
+
+    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
+        return 0;
+
+    rc =3D x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);
+
+    return rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
+}
+#endif /* __x86_64__ */
+
 void free_xen_pagetable(void *v)
 {
     if ( system_state =3D=3D SYS_STATE_early_boot )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
         return 0;
     }
=20
-    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
-         guest_kernel_mode(v, regs) )
-    {
-        unsigned int mbs =3D PFEC_write_access;
-        unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;
-
-        /* Do not check if access-protection fault since the page may=20
-           legitimately be not present in shadow page tables */
-        if ( !paging_mode_enabled(d) )
-            mbs |=3D PFEC_page_present;
-
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&
+    if ( guest_kernel_mode(v, regs) &&
+         !(regs->error_code & (PFEC_reserved_bit | PFEC_insn_fetch)) &&
+         (regs->error_code & PFEC_write_access) )
+    {
+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
+             /* Do not check if access-protection fault since the page =
may
+                legitimately be not present in shadow page tables */
+             (paging_mode_enabled(d) ||
+              (regs->error_code & PFEC_page_present)) &&
              ptwr_do_page_fault(v, addr, regs) )
             return EXCRET_fault_fixed;
+
+#ifdef __x86_64__
+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_present) &&
+             mmio_ro_do_page_fault(v, addr, regs) )
+            return EXCRET_fault_fixed;
+#endif
     }
=20
     /* For non-external shadowed guests, we fix up both their own=20
@@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,=20
         return 0;
=20
     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;
+    if ( write )
+    {
+        const unsigned long *ro_map =3D pci_get_ro_map(0);
+
+        if ( ro_map && test_bit(machine_bdf, ro_map) )
+            return 0;
+    }
     start =3D d->arch.pci_cf8 & 0xFF;
     end =3D start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
--- a/xen/arch/x86/x86_32/pci.c
+++ b/xen/arch/x86/x86_32/pci.c
@@ -6,6 +6,7 @@
=20
 #include <xen/spinlock.h>
 #include <xen/pci.h>
+#include <xen/init.h>
 #include <asm/io.h>
=20
 #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
@@ -70,3 +71,7 @@ void pci_conf_write32(
     BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
 }
+
+void __init arch_pci_ro_device(int seg, int bdf)
+{
+}
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -14,6 +14,8 @@
 #include <xen/xmalloc.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
+#include <xen/iommu.h>
+#include <xen/rangeset.h>
=20
 #include "mmconfig.h"
=20
@@ -132,9 +134,30 @@ static void __iomem *mcfg_ioremap(const=20
     return (void __iomem *) virt;
 }
=20
+void arch_pci_ro_device(int seg, int bdf)
+{
+    unsigned int idx, bus =3D PCI_BUS(bdf);
+
+    for (idx =3D 0; idx < pci_mmcfg_config_num; ++idx) {
+        const struct acpi_mcfg_allocation *cfg =3D pci_mmcfg_virt[idx].cfg=
;
+        unsigned long mfn =3D (cfg->address >> PAGE_SHIFT) + bdf;
+
+        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment !=3D seg ||
+            cfg->start_bus_number > bus || cfg->end_bus_number < bus)
+            continue;
+
+        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
+            printk(XENLOG_ERR
+                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) =
read-only\n",
+                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
+                   mfn);
+    }
+}
+
 int pci_mmcfg_arch_enable(unsigned int idx)
 {
     const typeof(pci_mmcfg_config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg;
+    const unsigned long *ro_map =3D pci_get_ro_map(cfg->pci_segment);
=20
     if (pci_mmcfg_virt[idx].virt)
         return 0;
@@ -146,6 +169,16 @@ int pci_mmcfg_arch_enable(unsigned int i
     }
     printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
            cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
+    if (ro_map) {
+        unsigned int bdf =3D PCI_BDF(cfg->start_bus_number, 0, 0);
+        unsigned int end =3D PCI_BDF(cfg->end_bus_number, -1, -1);
+
+        while ((bdf =3D find_next_bit(ro_map, end + 1, bdf)) <=3D end) {
+            arch_pci_ro_device(cfg->pci_segment, bdf);
+            if (bdf++ =3D=3D end)
+                break;
+        }
+    }
     return 0;
 }
=20
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
     if ( rt )
         return -ENODEV;
=20
+    rt =3D pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
+    if ( rt )
+        printk(XENLOG_ERR
+               "Could not mark config space of %04x:%02x:%02x.%u =
read-only (%d)\n",
+               iommu->seg, bus, dev, func, rt);
+
     list_add_tail(&iommu->list, &amd_iommu_head);
=20
     return 0;
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
 unlock:
     spin_unlock(&d->event_lock);
 }
-
-static int __init setup_mmio_ro_ranges(void)
-{
-    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
-                                  RANGESETF_prettyprint_hex);
-    return 0;
-}
-__initcall(setup_mmio_ro_ranges);
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -36,6 +36,7 @@
 struct pci_seg {
     struct list_head alldevs_list;
     u16 nr;
+    unsigned long *ro_map;
     /* bus2bridge_lock protects bus2bridge array */
     spinlock_t bus2bridge_lock;
 #define MAX_BUSES 256
@@ -106,6 +107,8 @@ void __init pt_pci_init(void)
     radix_tree_init(&pci_segments);
     if ( !alloc_pseg(0) )
         panic("Could not initialize PCI segment 0\n");
+    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
+                                  RANGESETF_prettyprint_hex);
 }
=20
 int __init pci_add_segment(u16 seg)
@@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
     return alloc_pseg(seg) ? 0 : -ENOMEM;
 }
=20
+const unsigned long *pci_get_ro_map(u16 seg)
+{
+    struct pci_seg *pseg =3D get_pseg(seg);
+
+    return pseg ? pseg->ro_map : NULL;
+}
+
 static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
 {
     struct pci_dev *pdev;
@@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
     xfree(pdev);
 }
=20
+int __init pci_ro_device(int seg, int bus, int devfn)
+{
+    struct pci_seg *pseg =3D alloc_pseg(seg);
+    struct pci_dev *pdev;
+
+    if ( !pseg )
+        return -ENOMEM;
+    pdev =3D alloc_pdev(pseg, bus, devfn);
+    if ( !pdev )
+        return -ENOMEM;
+
+    if ( !pseg->ro_map )
+    {
+        size_t sz =3D BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long=
);
+
+        pseg->ro_map =3D alloc_xenheap_pages(get_order_from_bytes(sz), =
0);
+        if ( !pseg->ro_map )
+            return -ENOMEM;
+        memset(pseg->ro_map, 0, sz);
+    }
+
+    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
+    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
+
+    return 0;
+}
+
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
 {
     struct pci_seg *pseg =3D get_pseg(seg);
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
=20
 int  ptwr_do_page_fault(struct vcpu *, unsigned long,
                         struct cpu_user_regs *);
+int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
+                           struct cpu_user_regs *);
=20
 int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
=20
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
 void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
 void pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
+const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info =
*);
 int pci_remove_device(u16 seg, u8 bus, u8 devfn);
+int pci_ro_device(int seg, int bus, int devfn);
+void arch_pci_ro_device(int seg, int bdf);
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
 struct pci_dev *pci_get_pdev_by_domain(
     struct domain *, int seg, int bus, int devfn);



--=__PartBE901857.1__=
Content-Type: text/plain; name="pci-disallow-write.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-disallow-write.patch"

AMD IOMMU: add mechanism to protect their PCI devices' config spaces=0A=0AR=
ecent Dom0 kernels want to disable PCI MSI on all devices, yet doing=0Aso =
on AMD IOMMUs (which get represented by a PCI device) disables part=0Aof =
the functionality set up by the hypervisor.=0A=0AAdd a mechanism to mark =
certain PCI devices as having write protected=0Aconfig spaces (both =
through port based [method 1] accesses and, for=0Ax86-64, mmconfig), and =
use that for AMD's IOMMUs.=0A=0ANote that due to ptwr_do_page_fault() =
being run first, there'll be a=0AMEM_LOG() issued for each such mmconfig =
based write attempt. If that's=0Aundesirable, the order of the calls in =
fixup_page_fault() would need=0Ato be swapped.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0ATested-by: Wei Wang <wei.wang2@amd.com>=0A=0A=
--- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -5209,6 +5209,97 @@ =
int ptwr_do_page_fault(struct vcpu *v, u=0A     return 0;=0A }=0A =
=0A+#ifdef __x86_64__=0A+/*************************=0A+ * fault handling =
for read-only MMIO pages=0A+ */=0A+=0A+struct mmio_ro_emulate_ctxt {=0A+   =
 struct x86_emulate_ctxt ctxt;=0A+    unsigned long cr2;=0A+};=0A+=0A+stati=
c int mmio_ro_emulated_read(=0A+    enum x86_segment seg,=0A+    unsigned =
long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+    struct =
x86_emulate_ctxt *ctxt)=0A+{=0A+    return X86EMUL_UNHANDLEABLE;=0A+}=0A+=
=0A+static int mmio_ro_emulated_write(=0A+    enum x86_segment seg,=0A+    =
unsigned long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+  =
  struct x86_emulate_ctxt *ctxt)=0A+{=0A+    struct mmio_ro_emulate_ctxt =
*mmio_ro_ctxt =3D=0A+        container_of(ctxt, struct mmio_ro_emulate_ctxt=
, ctxt);=0A+=0A+    /* Only allow naturally-aligned stores at the original =
%cr2 address. */=0A+    if ( ((bytes | offset) & (bytes - 1)) || offset =
!=3D mmio_ro_ctxt->cr2 )=0A+    {=0A+        MEM_LOG("mmio_ro_emulate: bad =
access (cr2=3D%lx, addr=3D%lx, bytes=3D%u)",=0A+                mmio_ro_ctx=
t->cr2, offset, bytes);=0A+        return X86EMUL_UNHANDLEABLE;=0A+    =
}=0A+=0A+    return X86EMUL_OKAY;=0A+}=0A+=0A+static const struct =
x86_emulate_ops mmio_ro_emulate_ops =3D {=0A+    .read       =3D mmio_ro_em=
ulated_read,=0A+    .insn_fetch =3D ptwr_emulated_read,=0A+    .write      =
=3D mmio_ro_emulated_write,=0A+};=0A+=0A+/* Check if guest is trying to =
modify a r/o MMIO page. */=0A+int mmio_ro_do_page_fault(struct vcpu *v, =
unsigned long addr,=0A+                          struct cpu_user_regs =
*regs)=0A+{=0A+    l1_pgentry_t      pte;=0A+    unsigned long     =
mfn;=0A+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) =
?=0A+                                  32 : BITS_PER_LONG;=0A+    struct =
mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {=0A+        .ctxt.regs =3D =
regs,=0A+        .ctxt.addr_size =3D addr_size,=0A+        .ctxt.sp_size =
=3D addr_size,=0A+        .cr2 =3D addr=0A+    };=0A+    int rc;=0A+=0A+   =
 /* Attempt to read the PTE that maps the VA being accessed. */=0A+    =
guest_get_eff_l1e(v, addr, &pte);=0A+=0A+    /* We are looking only for =
read-only mappings of MMIO pages. */=0A+    if ( ((l1e_get_flags(pte) & =
(_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESENT) )=0A+        return =
0;=0A+=0A+    mfn =3D l1e_get_pfn(pte);=0A+    if ( mfn_valid(mfn) )=0A+   =
 {=0A+        struct page_info *page =3D mfn_to_page(mfn);=0A+        =
struct domain *owner =3D page_get_owner_and_reference(page);=0A+=0A+       =
 if ( owner )=0A+            put_page(page);=0A+        if ( owner !=3D =
dom_io )=0A+            return 0;=0A+    }=0A+=0A+    if ( !rangeset_contai=
ns_singleton(mmio_ro_ranges, mfn) )=0A+        return 0;=0A+=0A+    rc =3D =
x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);=0A+=0A+    return =
rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;=0A+}=0A+#endif /* =
__x86_64__ */=0A+=0A void free_xen_pagetable(void *v)=0A {=0A     if ( =
system_state =3D=3D SYS_STATE_early_boot )=0A--- a/xen/arch/x86/traps.c=0A+=
++ b/xen/arch/x86/traps.c=0A@@ -1349,20 +1349,23 @@ static int fixup_page_f=
ault(unsigned lon=0A         return 0;=0A     }=0A =0A-    if ( VM_ASSIST(d=
, VMASST_TYPE_writable_pagetables) &&=0A-         guest_kernel_mode(v, =
regs) )=0A-    {=0A-        unsigned int mbs =3D PFEC_write_access;=0A-    =
    unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;=0A-=0A-      =
  /* Do not check if access-protection fault since the page may =0A-       =
    legitimately be not present in shadow page tables */=0A-        if ( =
!paging_mode_enabled(d) )=0A-            mbs |=3D PFEC_page_present;=0A-=0A=
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&=0A+    if ( =
guest_kernel_mode(v, regs) &&=0A+         !(regs->error_code & (PFEC_reserv=
ed_bit | PFEC_insn_fetch)) &&=0A+         (regs->error_code & PFEC_write_ac=
cess) )=0A+    {=0A+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetabl=
es) &&=0A+             /* Do not check if access-protection fault since =
the page may=0A+                legitimately be not present in shadow page =
tables */=0A+             (paging_mode_enabled(d) ||=0A+              =
(regs->error_code & PFEC_page_present)) &&=0A              ptwr_do_page_fau=
lt(v, addr, regs) )=0A             return EXCRET_fault_fixed;=0A+=0A+#ifdef=
 __x86_64__=0A+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_pre=
sent) &&=0A+             mmio_ro_do_page_fault(v, addr, regs) )=0A+        =
    return EXCRET_fault_fixed;=0A+#endif=0A     }=0A =0A     /* For =
non-external shadowed guests, we fix up both their own =0A@@ -1690,6 =
+1693,13 @@ static int pci_cfg_ok(struct domain *d, =0A         return =
0;=0A =0A     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;=0A+    if ( =
write )=0A+    {=0A+        const unsigned long *ro_map =3D pci_get_ro_map(=
0);=0A+=0A+        if ( ro_map && test_bit(machine_bdf, ro_map) )=0A+      =
      return 0;=0A+    }=0A     start =3D d->arch.pci_cf8 & 0xFF;=0A     =
end =3D start + size - 1;=0A     if (xsm_pci_config_permission(d, =
machine_bdf, start, end, write))=0A--- a/xen/arch/x86/x86_32/pci.c=0A+++ =
b/xen/arch/x86/x86_32/pci.c=0A@@ -6,6 +6,7 @@=0A =0A #include <xen/spinlock=
.h>=0A #include <xen/pci.h>=0A+#include <xen/init.h>=0A #include <asm/io.h>=
=0A =0A #define PCI_CONF_ADDRESS(bus, dev, func, reg) \=0A@@ -70,3 +71,7 =
@@ void pci_conf_write32(=0A     BUG_ON((bus > 255) || (dev > 31) || (func =
> 7) || (reg > 255));=0A     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, =
func, reg), 0, 4, data);=0A }=0A+=0A+void __init arch_pci_ro_device(int =
seg, int bdf)=0A+{=0A+}=0A--- a/xen/arch/x86/x86_64/mmconfig_64.c=0A+++ =
b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ -14,6 +14,8 @@=0A #include =
<xen/xmalloc.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=0A+#in=
clude <xen/iommu.h>=0A+#include <xen/rangeset.h>=0A =0A #include "mmconfig.=
h"=0A =0A@@ -132,9 +134,30 @@ static void __iomem *mcfg_ioremap(const =0A  =
   return (void __iomem *) virt;=0A }=0A =0A+void arch_pci_ro_device(int =
seg, int bdf)=0A+{=0A+    unsigned int idx, bus =3D PCI_BUS(bdf);=0A+=0A+  =
  for (idx =3D 0; idx < pci_mmcfg_config_num; ++idx) {=0A+        const =
struct acpi_mcfg_allocation *cfg =3D pci_mmcfg_virt[idx].cfg;=0A+        =
unsigned long mfn =3D (cfg->address >> PAGE_SHIFT) + bdf;=0A+=0A+        =
if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment !=3D seg ||=0A+          =
  cfg->start_bus_number > bus || cfg->end_bus_number < bus)=0A+            =
continue;=0A+=0A+        if (rangeset_add_singleton(mmio_ro_ranges, =
mfn))=0A+            printk(XENLOG_ERR=0A+                   "%04x:%02x:%02=
x.%u: could not mark MCFG (mfn %#lx) read-only\n",=0A+                   =
cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),=0A+                   =
mfn);=0A+    }=0A+}=0A+=0A int pci_mmcfg_arch_enable(unsigned int idx)=0A =
{=0A     const typeof(pci_mmcfg_config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg=
;=0A+    const unsigned long *ro_map =3D pci_get_ro_map(cfg->pci_segment);=
=0A =0A     if (pci_mmcfg_virt[idx].virt)=0A         return 0;=0A@@ -146,6 =
+169,16 @@ int pci_mmcfg_arch_enable(unsigned int i=0A     }=0A     =
printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",=0A    =
        cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);=0A+ =
   if (ro_map) {=0A+        unsigned int bdf =3D PCI_BDF(cfg->start_bus_num=
ber, 0, 0);=0A+        unsigned int end =3D PCI_BDF(cfg->end_bus_number, =
-1, -1);=0A+=0A+        while ((bdf =3D find_next_bit(ro_map, end + 1, =
bdf)) <=3D end) {=0A+            arch_pci_ro_device(cfg->pci_segment, =
bdf);=0A+            if (bdf++ =3D=3D end)=0A+                break;=0A+   =
     }=0A+    }=0A     return 0;=0A }=0A =0A--- a/xen/drivers/passthrough/a=
md/iommu_detect.c=0A+++ b/xen/drivers/passthrough/amd/iommu_detect.c=0A@@ =
-153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(=0A     if ( rt =
)=0A         return -ENODEV;=0A =0A+    rt =3D pci_ro_device(iommu->seg, =
bus, PCI_DEVFN(dev, func));=0A+    if ( rt )=0A+        printk(XENLOG_ERR=
=0A+               "Could not mark config space of %04x:%02x:%02x.%u =
read-only (%d)\n",=0A+               iommu->seg, bus, dev, func, =
rt);=0A+=0A     list_add_tail(&iommu->list, &amd_iommu_head);=0A =0A     =
return 0;=0A--- a/xen/drivers/passthrough/io.c=0A+++ b/xen/drivers/passthro=
ugh/io.c=0A@@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, =
unsi=0A unlock:=0A     spin_unlock(&d->event_lock);=0A }=0A-=0A-static int =
__init setup_mmio_ro_ranges(void)=0A-{=0A-    mmio_ro_ranges =3D rangeset_n=
ew(NULL, "r/o mmio ranges",=0A-                                  RANGESETF_=
prettyprint_hex);=0A-    return 0;=0A-}=0A-__initcall(setup_mmio_ro_ranges)=
;=0A--- a/xen/drivers/passthrough/pci.c=0A+++ b/xen/drivers/passthrough/pci=
.c=0A@@ -36,6 +36,7 @@=0A struct pci_seg {=0A     struct list_head =
alldevs_list;=0A     u16 nr;=0A+    unsigned long *ro_map;=0A     /* =
bus2bridge_lock protects bus2bridge array */=0A     spinlock_t bus2bridge_l=
ock;=0A #define MAX_BUSES 256=0A@@ -106,6 +107,8 @@ void __init pt_pci_init=
(void)=0A     radix_tree_init(&pci_segments);=0A     if ( !alloc_pseg(0) =
)=0A         panic("Could not initialize PCI segment 0\n");=0A+    =
mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",=0A+               =
                   RANGESETF_prettyprint_hex);=0A }=0A =0A int __init =
pci_add_segment(u16 seg)=0A@@ -113,6 +116,13 @@ int __init pci_add_segment(=
u16 seg)=0A     return alloc_pseg(seg) ? 0 : -ENOMEM;=0A }=0A =0A+const =
unsigned long *pci_get_ro_map(u16 seg)=0A+{=0A+    struct pci_seg *pseg =
=3D get_pseg(seg);=0A+=0A+    return pseg ? pseg->ro_map : NULL;=0A+}=0A+=
=0A static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 =
devfn)=0A {=0A     struct pci_dev *pdev;=0A@@ -198,6 +208,33 @@ static =
void free_pdev(struct pci_seg *ps=0A     xfree(pdev);=0A }=0A =0A+int =
__init pci_ro_device(int seg, int bus, int devfn)=0A+{=0A+    struct =
pci_seg *pseg =3D alloc_pseg(seg);=0A+    struct pci_dev *pdev;=0A+=0A+    =
if ( !pseg )=0A+        return -ENOMEM;=0A+    pdev =3D alloc_pdev(pseg, =
bus, devfn);=0A+    if ( !pdev )=0A+        return -ENOMEM;=0A+=0A+    if =
( !pseg->ro_map )=0A+    {=0A+        size_t sz =3D BITS_TO_LONGS(PCI_BDF(-=
1, -1, -1) + 1) * sizeof(long);=0A+=0A+        pseg->ro_map =3D alloc_xenhe=
ap_pages(get_order_from_bytes(sz), 0);=0A+        if ( !pseg->ro_map )=0A+ =
           return -ENOMEM;=0A+        memset(pseg->ro_map, 0, sz);=0A+    =
}=0A+=0A+    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);=0A+    =
arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));=0A+=0A+    return 0;=0A+}=0A=
+=0A struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)=0A {=0A     =
struct pci_seg *pseg =3D get_pseg(seg);=0A--- a/xen/include/asm-x86/mm.h=0A=
+++ b/xen/include/asm-x86/mm.h=0A@@ -555,6 +555,8 @@ void memguard_unguard_=
stack(void *p);=0A =0A int  ptwr_do_page_fault(struct vcpu *, unsigned =
long,=0A                         struct cpu_user_regs *);=0A+int  =
mmio_ro_do_page_fault(struct vcpu *, unsigned long,=0A+                    =
       struct cpu_user_regs *);=0A =0A int audit_adjust_pgtables(struct =
domain *d, int dir, int noisy);=0A =0A--- a/xen/include/xen/pci.h=0A+++ =
b/xen/include/xen/pci.h=0A@@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domai=
n_pdev(=0A void setup_dom0_pci_devices(struct domain *, void (*)(struct =
pci_dev *));=0A void pci_release_devices(struct domain *d);=0A int =
pci_add_segment(u16 seg);=0A+const unsigned long *pci_get_ro_map(u16 =
seg);=0A int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct =
pci_dev_info *);=0A int pci_remove_device(u16 seg, u8 bus, u8 devfn);=0A+in=
t pci_ro_device(int seg, int bus, int devfn);=0A+void arch_pci_ro_device(in=
t seg, int bdf);=0A struct pci_dev *pci_get_pdev(int seg, int bus, int =
devfn);=0A struct pci_dev *pci_get_pdev_by_domain(=0A     struct domain *, =
int seg, int bus, int devfn);=0A
--=__PartBE901857.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

--=__PartBE901857.1__=--


From xen-devel-bounces@lists.xen.org Fri Jun 22 08:18:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1Shz3j-0007D2-7z; Fri, 22 Jun 2012 08:17: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 1Shz3h-0007Cx-AB
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:17:37 +0000
Received: from [85.158.143.99:50241] by server-1.bemta-4.messagelabs.com id
	BB/58-24392-02A24EF4; Fri, 22 Jun 2012 08:17:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340353055!22188395!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12198 invoked from network); 22 Jun 2012 08:17:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	22 Jun 2012 08:17:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 09:17:35 +0100
Message-Id: <4FE44667020000780008B492@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 09:18:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBE901857.1__="
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH] AMD IOMMU: add mechanism to protect their PCI
 devices' config spaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartBE901857.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Recent Dom0 kernels want to disable PCI MSI on all devices, yet doing
so on AMD IOMMUs (which get represented by a PCI device) disables part
of the functionality set up by the hypervisor.

Add a mechanism to mark certain PCI devices as having write protected
config spaces (both through port based [method 1] accesses and, for
x86-64, mmconfig), and use that for AMD's IOMMUs.

Note that due to ptwr_do_page_fault() being run first, there'll be a
MEM_LOG() issued for each such mmconfig based write attempt. If that's
undesirable, the order of the calls in fixup_page_fault() would need
to be swapped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Wei Wang <wei.wang2@amd.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5209,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
     return 0;
 }
=20
+#ifdef __x86_64__
+/*************************
+ * fault handling for read-only MMIO pages
+ */
+
+struct mmio_ro_emulate_ctxt {
+    struct x86_emulate_ctxt ctxt;
+    unsigned long cr2;
+};
+
+static int mmio_ro_emulated_read(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    return X86EMUL_UNHANDLEABLE;
+}
+
+static int mmio_ro_emulated_write(
+    enum x86_segment seg,
+    unsigned long offset,
+    void *p_data,
+    unsigned int bytes,
+    struct x86_emulate_ctxt *ctxt)
+{
+    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =3D
+        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
+
+    /* Only allow naturally-aligned stores at the original %cr2 address. =
*/
+    if ( ((bytes | offset) & (bytes - 1)) || offset !=3D mmio_ro_ctxt->cr2=
 )
+    {
+        MEM_LOG("mmio_ro_emulate: bad access (cr2=3D%lx, addr=3D%lx, =
bytes=3D%u)",
+                mmio_ro_ctxt->cr2, offset, bytes);
+        return X86EMUL_UNHANDLEABLE;
+    }
+
+    return X86EMUL_OKAY;
+}
+
+static const struct x86_emulate_ops mmio_ro_emulate_ops =3D {
+    .read       =3D mmio_ro_emulated_read,
+    .insn_fetch =3D ptwr_emulated_read,
+    .write      =3D mmio_ro_emulated_write,
+};
+
+/* Check if guest is trying to modify a r/o MMIO page. */
+int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
+                          struct cpu_user_regs *regs)
+{
+    l1_pgentry_t      pte;
+    unsigned long     mfn;
+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) ?
+                                  32 : BITS_PER_LONG;
+    struct mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {
+        .ctxt.regs =3D regs,
+        .ctxt.addr_size =3D addr_size,
+        .ctxt.sp_size =3D addr_size,
+        .cr2 =3D addr
+    };
+    int rc;
+
+    /* Attempt to read the PTE that maps the VA being accessed. */
+    guest_get_eff_l1e(v, addr, &pte);
+
+    /* We are looking only for read-only mappings of MMIO pages. */
+    if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESE=
NT) )
+        return 0;
+
+    mfn =3D l1e_get_pfn(pte);
+    if ( mfn_valid(mfn) )
+    {
+        struct page_info *page =3D mfn_to_page(mfn);
+        struct domain *owner =3D page_get_owner_and_reference(page);
+
+        if ( owner )
+            put_page(page);
+        if ( owner !=3D dom_io )
+            return 0;
+    }
+
+    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
+        return 0;
+
+    rc =3D x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);
+
+    return rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
+}
+#endif /* __x86_64__ */
+
 void free_xen_pagetable(void *v)
 {
     if ( system_state =3D=3D SYS_STATE_early_boot )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
         return 0;
     }
=20
-    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
-         guest_kernel_mode(v, regs) )
-    {
-        unsigned int mbs =3D PFEC_write_access;
-        unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;
-
-        /* Do not check if access-protection fault since the page may=20
-           legitimately be not present in shadow page tables */
-        if ( !paging_mode_enabled(d) )
-            mbs |=3D PFEC_page_present;
-
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&
+    if ( guest_kernel_mode(v, regs) &&
+         !(regs->error_code & (PFEC_reserved_bit | PFEC_insn_fetch)) &&
+         (regs->error_code & PFEC_write_access) )
+    {
+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
+             /* Do not check if access-protection fault since the page =
may
+                legitimately be not present in shadow page tables */
+             (paging_mode_enabled(d) ||
+              (regs->error_code & PFEC_page_present)) &&
              ptwr_do_page_fault(v, addr, regs) )
             return EXCRET_fault_fixed;
+
+#ifdef __x86_64__
+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_present) &&
+             mmio_ro_do_page_fault(v, addr, regs) )
+            return EXCRET_fault_fixed;
+#endif
     }
=20
     /* For non-external shadowed guests, we fix up both their own=20
@@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,=20
         return 0;
=20
     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;
+    if ( write )
+    {
+        const unsigned long *ro_map =3D pci_get_ro_map(0);
+
+        if ( ro_map && test_bit(machine_bdf, ro_map) )
+            return 0;
+    }
     start =3D d->arch.pci_cf8 & 0xFF;
     end =3D start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
--- a/xen/arch/x86/x86_32/pci.c
+++ b/xen/arch/x86/x86_32/pci.c
@@ -6,6 +6,7 @@
=20
 #include <xen/spinlock.h>
 #include <xen/pci.h>
+#include <xen/init.h>
 #include <asm/io.h>
=20
 #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
@@ -70,3 +71,7 @@ void pci_conf_write32(
     BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
 }
+
+void __init arch_pci_ro_device(int seg, int bdf)
+{
+}
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -14,6 +14,8 @@
 #include <xen/xmalloc.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
+#include <xen/iommu.h>
+#include <xen/rangeset.h>
=20
 #include "mmconfig.h"
=20
@@ -132,9 +134,30 @@ static void __iomem *mcfg_ioremap(const=20
     return (void __iomem *) virt;
 }
=20
+void arch_pci_ro_device(int seg, int bdf)
+{
+    unsigned int idx, bus =3D PCI_BUS(bdf);
+
+    for (idx =3D 0; idx < pci_mmcfg_config_num; ++idx) {
+        const struct acpi_mcfg_allocation *cfg =3D pci_mmcfg_virt[idx].cfg=
;
+        unsigned long mfn =3D (cfg->address >> PAGE_SHIFT) + bdf;
+
+        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment !=3D seg ||
+            cfg->start_bus_number > bus || cfg->end_bus_number < bus)
+            continue;
+
+        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
+            printk(XENLOG_ERR
+                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx) =
read-only\n",
+                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
+                   mfn);
+    }
+}
+
 int pci_mmcfg_arch_enable(unsigned int idx)
 {
     const typeof(pci_mmcfg_config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg;
+    const unsigned long *ro_map =3D pci_get_ro_map(cfg->pci_segment);
=20
     if (pci_mmcfg_virt[idx].virt)
         return 0;
@@ -146,6 +169,16 @@ int pci_mmcfg_arch_enable(unsigned int i
     }
     printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
            cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
+    if (ro_map) {
+        unsigned int bdf =3D PCI_BDF(cfg->start_bus_number, 0, 0);
+        unsigned int end =3D PCI_BDF(cfg->end_bus_number, -1, -1);
+
+        while ((bdf =3D find_next_bit(ro_map, end + 1, bdf)) <=3D end) {
+            arch_pci_ro_device(cfg->pci_segment, bdf);
+            if (bdf++ =3D=3D end)
+                break;
+        }
+    }
     return 0;
 }
=20
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
     if ( rt )
         return -ENODEV;
=20
+    rt =3D pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
+    if ( rt )
+        printk(XENLOG_ERR
+               "Could not mark config space of %04x:%02x:%02x.%u =
read-only (%d)\n",
+               iommu->seg, bus, dev, func, rt);
+
     list_add_tail(&iommu->list, &amd_iommu_head);
=20
     return 0;
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
 unlock:
     spin_unlock(&d->event_lock);
 }
-
-static int __init setup_mmio_ro_ranges(void)
-{
-    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
-                                  RANGESETF_prettyprint_hex);
-    return 0;
-}
-__initcall(setup_mmio_ro_ranges);
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -36,6 +36,7 @@
 struct pci_seg {
     struct list_head alldevs_list;
     u16 nr;
+    unsigned long *ro_map;
     /* bus2bridge_lock protects bus2bridge array */
     spinlock_t bus2bridge_lock;
 #define MAX_BUSES 256
@@ -106,6 +107,8 @@ void __init pt_pci_init(void)
     radix_tree_init(&pci_segments);
     if ( !alloc_pseg(0) )
         panic("Could not initialize PCI segment 0\n");
+    mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
+                                  RANGESETF_prettyprint_hex);
 }
=20
 int __init pci_add_segment(u16 seg)
@@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
     return alloc_pseg(seg) ? 0 : -ENOMEM;
 }
=20
+const unsigned long *pci_get_ro_map(u16 seg)
+{
+    struct pci_seg *pseg =3D get_pseg(seg);
+
+    return pseg ? pseg->ro_map : NULL;
+}
+
 static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
 {
     struct pci_dev *pdev;
@@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
     xfree(pdev);
 }
=20
+int __init pci_ro_device(int seg, int bus, int devfn)
+{
+    struct pci_seg *pseg =3D alloc_pseg(seg);
+    struct pci_dev *pdev;
+
+    if ( !pseg )
+        return -ENOMEM;
+    pdev =3D alloc_pdev(pseg, bus, devfn);
+    if ( !pdev )
+        return -ENOMEM;
+
+    if ( !pseg->ro_map )
+    {
+        size_t sz =3D BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long=
);
+
+        pseg->ro_map =3D alloc_xenheap_pages(get_order_from_bytes(sz), =
0);
+        if ( !pseg->ro_map )
+            return -ENOMEM;
+        memset(pseg->ro_map, 0, sz);
+    }
+
+    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
+    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
+
+    return 0;
+}
+
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
 {
     struct pci_seg *pseg =3D get_pseg(seg);
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
=20
 int  ptwr_do_page_fault(struct vcpu *, unsigned long,
                         struct cpu_user_regs *);
+int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
+                           struct cpu_user_regs *);
=20
 int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
=20
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
 void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
 void pci_release_devices(struct domain *d);
 int pci_add_segment(u16 seg);
+const unsigned long *pci_get_ro_map(u16 seg);
 int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info =
*);
 int pci_remove_device(u16 seg, u8 bus, u8 devfn);
+int pci_ro_device(int seg, int bus, int devfn);
+void arch_pci_ro_device(int seg, int bdf);
 struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
 struct pci_dev *pci_get_pdev_by_domain(
     struct domain *, int seg, int bus, int devfn);



--=__PartBE901857.1__=
Content-Type: text/plain; name="pci-disallow-write.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-disallow-write.patch"

AMD IOMMU: add mechanism to protect their PCI devices' config spaces=0A=0AR=
ecent Dom0 kernels want to disable PCI MSI on all devices, yet doing=0Aso =
on AMD IOMMUs (which get represented by a PCI device) disables part=0Aof =
the functionality set up by the hypervisor.=0A=0AAdd a mechanism to mark =
certain PCI devices as having write protected=0Aconfig spaces (both =
through port based [method 1] accesses and, for=0Ax86-64, mmconfig), and =
use that for AMD's IOMMUs.=0A=0ANote that due to ptwr_do_page_fault() =
being run first, there'll be a=0AMEM_LOG() issued for each such mmconfig =
based write attempt. If that's=0Aundesirable, the order of the calls in =
fixup_page_fault() would need=0Ato be swapped.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0ATested-by: Wei Wang <wei.wang2@amd.com>=0A=0A=
--- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -5209,6 +5209,97 @@ =
int ptwr_do_page_fault(struct vcpu *v, u=0A     return 0;=0A }=0A =
=0A+#ifdef __x86_64__=0A+/*************************=0A+ * fault handling =
for read-only MMIO pages=0A+ */=0A+=0A+struct mmio_ro_emulate_ctxt {=0A+   =
 struct x86_emulate_ctxt ctxt;=0A+    unsigned long cr2;=0A+};=0A+=0A+stati=
c int mmio_ro_emulated_read(=0A+    enum x86_segment seg,=0A+    unsigned =
long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+    struct =
x86_emulate_ctxt *ctxt)=0A+{=0A+    return X86EMUL_UNHANDLEABLE;=0A+}=0A+=
=0A+static int mmio_ro_emulated_write(=0A+    enum x86_segment seg,=0A+    =
unsigned long offset,=0A+    void *p_data,=0A+    unsigned int bytes,=0A+  =
  struct x86_emulate_ctxt *ctxt)=0A+{=0A+    struct mmio_ro_emulate_ctxt =
*mmio_ro_ctxt =3D=0A+        container_of(ctxt, struct mmio_ro_emulate_ctxt=
, ctxt);=0A+=0A+    /* Only allow naturally-aligned stores at the original =
%cr2 address. */=0A+    if ( ((bytes | offset) & (bytes - 1)) || offset =
!=3D mmio_ro_ctxt->cr2 )=0A+    {=0A+        MEM_LOG("mmio_ro_emulate: bad =
access (cr2=3D%lx, addr=3D%lx, bytes=3D%u)",=0A+                mmio_ro_ctx=
t->cr2, offset, bytes);=0A+        return X86EMUL_UNHANDLEABLE;=0A+    =
}=0A+=0A+    return X86EMUL_OKAY;=0A+}=0A+=0A+static const struct =
x86_emulate_ops mmio_ro_emulate_ops =3D {=0A+    .read       =3D mmio_ro_em=
ulated_read,=0A+    .insn_fetch =3D ptwr_emulated_read,=0A+    .write      =
=3D mmio_ro_emulated_write,=0A+};=0A+=0A+/* Check if guest is trying to =
modify a r/o MMIO page. */=0A+int mmio_ro_do_page_fault(struct vcpu *v, =
unsigned long addr,=0A+                          struct cpu_user_regs =
*regs)=0A+{=0A+    l1_pgentry_t      pte;=0A+    unsigned long     =
mfn;=0A+    unsigned int      addr_size =3D is_pv_32on64_domain(v->domain) =
?=0A+                                  32 : BITS_PER_LONG;=0A+    struct =
mmio_ro_emulate_ctxt mmio_ro_ctxt =3D {=0A+        .ctxt.regs =3D =
regs,=0A+        .ctxt.addr_size =3D addr_size,=0A+        .ctxt.sp_size =
=3D addr_size,=0A+        .cr2 =3D addr=0A+    };=0A+    int rc;=0A+=0A+   =
 /* Attempt to read the PTE that maps the VA being accessed. */=0A+    =
guest_get_eff_l1e(v, addr, &pte);=0A+=0A+    /* We are looking only for =
read-only mappings of MMIO pages. */=0A+    if ( ((l1e_get_flags(pte) & =
(_PAGE_PRESENT|_PAGE_RW)) !=3D _PAGE_PRESENT) )=0A+        return =
0;=0A+=0A+    mfn =3D l1e_get_pfn(pte);=0A+    if ( mfn_valid(mfn) )=0A+   =
 {=0A+        struct page_info *page =3D mfn_to_page(mfn);=0A+        =
struct domain *owner =3D page_get_owner_and_reference(page);=0A+=0A+       =
 if ( owner )=0A+            put_page(page);=0A+        if ( owner !=3D =
dom_io )=0A+            return 0;=0A+    }=0A+=0A+    if ( !rangeset_contai=
ns_singleton(mmio_ro_ranges, mfn) )=0A+        return 0;=0A+=0A+    rc =3D =
x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);=0A+=0A+    return =
rc !=3D X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;=0A+}=0A+#endif /* =
__x86_64__ */=0A+=0A void free_xen_pagetable(void *v)=0A {=0A     if ( =
system_state =3D=3D SYS_STATE_early_boot )=0A--- a/xen/arch/x86/traps.c=0A+=
++ b/xen/arch/x86/traps.c=0A@@ -1349,20 +1349,23 @@ static int fixup_page_f=
ault(unsigned lon=0A         return 0;=0A     }=0A =0A-    if ( VM_ASSIST(d=
, VMASST_TYPE_writable_pagetables) &&=0A-         guest_kernel_mode(v, =
regs) )=0A-    {=0A-        unsigned int mbs =3D PFEC_write_access;=0A-    =
    unsigned int mbz =3D PFEC_reserved_bit | PFEC_insn_fetch;=0A-=0A-      =
  /* Do not check if access-protection fault since the page may =0A-       =
    legitimately be not present in shadow page tables */=0A-        if ( =
!paging_mode_enabled(d) )=0A-            mbs |=3D PFEC_page_present;=0A-=0A=
-        if ( ((regs->error_code & (mbs | mbz)) =3D=3D mbs) &&=0A+    if ( =
guest_kernel_mode(v, regs) &&=0A+         !(regs->error_code & (PFEC_reserv=
ed_bit | PFEC_insn_fetch)) &&=0A+         (regs->error_code & PFEC_write_ac=
cess) )=0A+    {=0A+        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetabl=
es) &&=0A+             /* Do not check if access-protection fault since =
the page may=0A+                legitimately be not present in shadow page =
tables */=0A+             (paging_mode_enabled(d) ||=0A+              =
(regs->error_code & PFEC_page_present)) &&=0A              ptwr_do_page_fau=
lt(v, addr, regs) )=0A             return EXCRET_fault_fixed;=0A+=0A+#ifdef=
 __x86_64__=0A+        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_pre=
sent) &&=0A+             mmio_ro_do_page_fault(v, addr, regs) )=0A+        =
    return EXCRET_fault_fixed;=0A+#endif=0A     }=0A =0A     /* For =
non-external shadowed guests, we fix up both their own =0A@@ -1690,6 =
+1693,13 @@ static int pci_cfg_ok(struct domain *d, =0A         return =
0;=0A =0A     machine_bdf =3D (d->arch.pci_cf8 >> 8) & 0xFFFF;=0A+    if ( =
write )=0A+    {=0A+        const unsigned long *ro_map =3D pci_get_ro_map(=
0);=0A+=0A+        if ( ro_map && test_bit(machine_bdf, ro_map) )=0A+      =
      return 0;=0A+    }=0A     start =3D d->arch.pci_cf8 & 0xFF;=0A     =
end =3D start + size - 1;=0A     if (xsm_pci_config_permission(d, =
machine_bdf, start, end, write))=0A--- a/xen/arch/x86/x86_32/pci.c=0A+++ =
b/xen/arch/x86/x86_32/pci.c=0A@@ -6,6 +6,7 @@=0A =0A #include <xen/spinlock=
.h>=0A #include <xen/pci.h>=0A+#include <xen/init.h>=0A #include <asm/io.h>=
=0A =0A #define PCI_CONF_ADDRESS(bus, dev, func, reg) \=0A@@ -70,3 +71,7 =
@@ void pci_conf_write32(=0A     BUG_ON((bus > 255) || (dev > 31) || (func =
> 7) || (reg > 255));=0A     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, =
func, reg), 0, 4, data);=0A }=0A+=0A+void __init arch_pci_ro_device(int =
seg, int bdf)=0A+{=0A+}=0A--- a/xen/arch/x86/x86_64/mmconfig_64.c=0A+++ =
b/xen/arch/x86/x86_64/mmconfig_64.c=0A@@ -14,6 +14,8 @@=0A #include =
<xen/xmalloc.h>=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=0A+#in=
clude <xen/iommu.h>=0A+#include <xen/rangeset.h>=0A =0A #include "mmconfig.=
h"=0A =0A@@ -132,9 +134,30 @@ static void __iomem *mcfg_ioremap(const =0A  =
   return (void __iomem *) virt;=0A }=0A =0A+void arch_pci_ro_device(int =
seg, int bdf)=0A+{=0A+    unsigned int idx, bus =3D PCI_BUS(bdf);=0A+=0A+  =
  for (idx =3D 0; idx < pci_mmcfg_config_num; ++idx) {=0A+        const =
struct acpi_mcfg_allocation *cfg =3D pci_mmcfg_virt[idx].cfg;=0A+        =
unsigned long mfn =3D (cfg->address >> PAGE_SHIFT) + bdf;=0A+=0A+        =
if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment !=3D seg ||=0A+          =
  cfg->start_bus_number > bus || cfg->end_bus_number < bus)=0A+            =
continue;=0A+=0A+        if (rangeset_add_singleton(mmio_ro_ranges, =
mfn))=0A+            printk(XENLOG_ERR=0A+                   "%04x:%02x:%02=
x.%u: could not mark MCFG (mfn %#lx) read-only\n",=0A+                   =
cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),=0A+                   =
mfn);=0A+    }=0A+}=0A+=0A int pci_mmcfg_arch_enable(unsigned int idx)=0A =
{=0A     const typeof(pci_mmcfg_config[0]) *cfg =3D pci_mmcfg_virt[idx].cfg=
;=0A+    const unsigned long *ro_map =3D pci_get_ro_map(cfg->pci_segment);=
=0A =0A     if (pci_mmcfg_virt[idx].virt)=0A         return 0;=0A@@ -146,6 =
+169,16 @@ int pci_mmcfg_arch_enable(unsigned int i=0A     }=0A     =
printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",=0A    =
        cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);=0A+ =
   if (ro_map) {=0A+        unsigned int bdf =3D PCI_BDF(cfg->start_bus_num=
ber, 0, 0);=0A+        unsigned int end =3D PCI_BDF(cfg->end_bus_number, =
-1, -1);=0A+=0A+        while ((bdf =3D find_next_bit(ro_map, end + 1, =
bdf)) <=3D end) {=0A+            arch_pci_ro_device(cfg->pci_segment, =
bdf);=0A+            if (bdf++ =3D=3D end)=0A+                break;=0A+   =
     }=0A+    }=0A     return 0;=0A }=0A =0A--- a/xen/drivers/passthrough/a=
md/iommu_detect.c=0A+++ b/xen/drivers/passthrough/amd/iommu_detect.c=0A@@ =
-153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(=0A     if ( rt =
)=0A         return -ENODEV;=0A =0A+    rt =3D pci_ro_device(iommu->seg, =
bus, PCI_DEVFN(dev, func));=0A+    if ( rt )=0A+        printk(XENLOG_ERR=
=0A+               "Could not mark config space of %04x:%02x:%02x.%u =
read-only (%d)\n",=0A+               iommu->seg, bus, dev, func, =
rt);=0A+=0A     list_add_tail(&iommu->list, &amd_iommu_head);=0A =0A     =
return 0;=0A--- a/xen/drivers/passthrough/io.c=0A+++ b/xen/drivers/passthro=
ugh/io.c=0A@@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, =
unsi=0A unlock:=0A     spin_unlock(&d->event_lock);=0A }=0A-=0A-static int =
__init setup_mmio_ro_ranges(void)=0A-{=0A-    mmio_ro_ranges =3D rangeset_n=
ew(NULL, "r/o mmio ranges",=0A-                                  RANGESETF_=
prettyprint_hex);=0A-    return 0;=0A-}=0A-__initcall(setup_mmio_ro_ranges)=
;=0A--- a/xen/drivers/passthrough/pci.c=0A+++ b/xen/drivers/passthrough/pci=
.c=0A@@ -36,6 +36,7 @@=0A struct pci_seg {=0A     struct list_head =
alldevs_list;=0A     u16 nr;=0A+    unsigned long *ro_map;=0A     /* =
bus2bridge_lock protects bus2bridge array */=0A     spinlock_t bus2bridge_l=
ock;=0A #define MAX_BUSES 256=0A@@ -106,6 +107,8 @@ void __init pt_pci_init=
(void)=0A     radix_tree_init(&pci_segments);=0A     if ( !alloc_pseg(0) =
)=0A         panic("Could not initialize PCI segment 0\n");=0A+    =
mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",=0A+               =
                   RANGESETF_prettyprint_hex);=0A }=0A =0A int __init =
pci_add_segment(u16 seg)=0A@@ -113,6 +116,13 @@ int __init pci_add_segment(=
u16 seg)=0A     return alloc_pseg(seg) ? 0 : -ENOMEM;=0A }=0A =0A+const =
unsigned long *pci_get_ro_map(u16 seg)=0A+{=0A+    struct pci_seg *pseg =
=3D get_pseg(seg);=0A+=0A+    return pseg ? pseg->ro_map : NULL;=0A+}=0A+=
=0A static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 =
devfn)=0A {=0A     struct pci_dev *pdev;=0A@@ -198,6 +208,33 @@ static =
void free_pdev(struct pci_seg *ps=0A     xfree(pdev);=0A }=0A =0A+int =
__init pci_ro_device(int seg, int bus, int devfn)=0A+{=0A+    struct =
pci_seg *pseg =3D alloc_pseg(seg);=0A+    struct pci_dev *pdev;=0A+=0A+    =
if ( !pseg )=0A+        return -ENOMEM;=0A+    pdev =3D alloc_pdev(pseg, =
bus, devfn);=0A+    if ( !pdev )=0A+        return -ENOMEM;=0A+=0A+    if =
( !pseg->ro_map )=0A+    {=0A+        size_t sz =3D BITS_TO_LONGS(PCI_BDF(-=
1, -1, -1) + 1) * sizeof(long);=0A+=0A+        pseg->ro_map =3D alloc_xenhe=
ap_pages(get_order_from_bytes(sz), 0);=0A+        if ( !pseg->ro_map )=0A+ =
           return -ENOMEM;=0A+        memset(pseg->ro_map, 0, sz);=0A+    =
}=0A+=0A+    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);=0A+    =
arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));=0A+=0A+    return 0;=0A+}=0A=
+=0A struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)=0A {=0A     =
struct pci_seg *pseg =3D get_pseg(seg);=0A--- a/xen/include/asm-x86/mm.h=0A=
+++ b/xen/include/asm-x86/mm.h=0A@@ -555,6 +555,8 @@ void memguard_unguard_=
stack(void *p);=0A =0A int  ptwr_do_page_fault(struct vcpu *, unsigned =
long,=0A                         struct cpu_user_regs *);=0A+int  =
mmio_ro_do_page_fault(struct vcpu *, unsigned long,=0A+                    =
       struct cpu_user_regs *);=0A =0A int audit_adjust_pgtables(struct =
domain *d, int dir, int noisy);=0A =0A--- a/xen/include/xen/pci.h=0A+++ =
b/xen/include/xen/pci.h=0A@@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domai=
n_pdev(=0A void setup_dom0_pci_devices(struct domain *, void (*)(struct =
pci_dev *));=0A void pci_release_devices(struct domain *d);=0A int =
pci_add_segment(u16 seg);=0A+const unsigned long *pci_get_ro_map(u16 =
seg);=0A int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct =
pci_dev_info *);=0A int pci_remove_device(u16 seg, u8 bus, u8 devfn);=0A+in=
t pci_ro_device(int seg, int bus, int devfn);=0A+void arch_pci_ro_device(in=
t seg, int bdf);=0A struct pci_dev *pci_get_pdev(int seg, int bus, int =
devfn);=0A struct pci_dev *pci_get_pdev_by_domain(=0A     struct domain *, =
int seg, int bus, int devfn);=0A
--=__PartBE901857.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

--=__PartBE901857.1__=--


From xen-devel-bounces@lists.xen.org Fri Jun 22 08:20:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08:20: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 1Shz6V-0007Km-09; Fri, 22 Jun 2012 08:20: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 1Shz6T-0007Kf-KB
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:20:29 +0000
Received: from [85.158.143.99:9228] by server-2.bemta-4.messagelabs.com id
	E8/95-17938-CCA24EF4; Fri, 22 Jun 2012 08:20:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340353226!23327519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 22 Jun 2012 08:20:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:20:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13163165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:20:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 09:20:11 +0100
Message-ID: <1340353211.19647.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
Date: Fri, 22 Jun 2012 09:20:11 +0100
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C163@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C163@its-hcwnem04.ds.Vanderbilt.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding domctl hypercall from dom0 kernel...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 22:09 +0100, Tapdiya, Ashish wrote:
> added a system call to invoke hypercall from dom0 user space, system
> call code is as follows

Why not just make the hypercall from userspace (via libxenctrl)
directly? All the necessary infrastructure is in place and is known to
work because the toolstack uses it extensively.

domctls are not really supposed to be used from the kernel since they
are not stable across Xen releases.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 08:20:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08:20: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 1Shz6V-0007Km-09; Fri, 22 Jun 2012 08:20: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 1Shz6T-0007Kf-KB
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:20:29 +0000
Received: from [85.158.143.99:9228] by server-2.bemta-4.messagelabs.com id
	E8/95-17938-CCA24EF4; Fri, 22 Jun 2012 08:20:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340353226!23327519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 22 Jun 2012 08:20:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:20:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13163165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:20:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 09:20:11 +0100
Message-ID: <1340353211.19647.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
Date: Fri, 22 Jun 2012 09:20:11 +0100
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C163@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C163@its-hcwnem04.ds.Vanderbilt.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding domctl hypercall from dom0 kernel...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 22:09 +0100, Tapdiya, Ashish wrote:
> added a system call to invoke hypercall from dom0 user space, system
> call code is as follows

Why not just make the hypercall from userspace (via libxenctrl)
directly? All the necessary infrastructure is in place and is known to
work because the toolstack uses it extensively.

domctls are not really supposed to be used from the kernel since they
are not stable across Xen releases.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 08:27:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08:27: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 1ShzD6-0007jg-FK; Fri, 22 Jun 2012 08:27: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 1ShzD5-0007ja-0W
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:27:19 +0000
Received: from [85.158.143.99:15322] by server-1.bemta-4.messagelabs.com id
	E8/C8-24392-66C24EF4; Fri, 22 Jun 2012 08:27:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340353637!16991792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13667 invoked from network); 22 Jun 2012 08:27:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13163343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:26: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.213.0;
	Fri, 22 Jun 2012 09:26:50 +0100
Message-ID: <1340353609.19647.24.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Fri, 22 Jun 2012 09:26:49 +0100
In-Reply-To: <20120621184036.GD2640@US-SEA-R8XVZTX>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621184036.GD2640@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 19:43 +0100, Matt Wilson wrote:
> On Thu, Jun 21, 2012 at 01:33:25AM -0700, Ian Campbell wrote:
> > On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > >  SHAREDIR    ?= $(PREFIX)/share
> > >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > > @@ -67,7 +68,7 @@ endef
> > >  
> > >  ifneq ($(EXTRA_PREFIX),)
> > >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> > 
> > since we are sort of reverting 16950:0faf620bc749 here this could in
> > theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> > include Tools.mk though. :-/
> 
> That would result in looking in /some/extra/prefix/usr/lib, which is
> not what I'd expect is desired. 

Oh, right, yes!

> > > diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
> > > --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> > > +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> > > @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
> > >  PREFIX ?= /usr
> > >  BINDIR = $(PREFIX)/bin
> > >  INCLUDEDIR = $(PREFIX)/include
> > > -LIBLEAFDIR = lib
> > > -LIBLEAFDIR_x86_32 = lib
> > > -LIBLEAFDIR_x86_64 ?= lib64
> > > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > > -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > > -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > > -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> > > +LIBEXEC = $(PREFIX)/lib/xen/bin
> > 
> > Wouldn't this be $(LIBDIR)/xen/bin ?
> 
> No, the old behavior (which I retained) is to always install
> $(LIBEXEC) files to /usr/lib/xen/bin (since it was defined to
> $(LIBDIR_x86_32), which expands to /usr/lib),

OK.

> Confusingly, we also install "private" binaries to $(PRIVATE_BINDIR),
> which expands to $(PRIVATE_PREFIX)/bin which expands to $(LIBDIR)/xen/bin,
> which expands to /usr/lib64/xen/bin. This results in paths like:
> 
> /usr/lib64/xen/bin/lsevtchn

... weird!

[...]

> > I suppose configure defines a libexec but it isn't the one we want?
> 
> By default, configure will define libexec to be /usr/libexec, which I
> like. If we switched to using the value provided from configure, we
> people who don't like /usr/libexec could just provide a different
> value at ./configure time.

Lets leave that until 4.3, I'm already a little uncomfortable messing
with the build system at this stage in 4.2 (there's always unforeseen
consequences to these sorts of changes, no matter how diligent we all
are :-/). For the lib vs. lib64 breakage on multiarch I think the risk
is worth it, but for more "cosmetic" issues like libexec I'd rather pass
for now.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 08:27:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08:27: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 1ShzD6-0007jg-FK; Fri, 22 Jun 2012 08:27: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 1ShzD5-0007ja-0W
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:27:19 +0000
Received: from [85.158.143.99:15322] by server-1.bemta-4.messagelabs.com id
	E8/C8-24392-66C24EF4; Fri, 22 Jun 2012 08:27:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340353637!16991792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13667 invoked from network); 22 Jun 2012 08:27:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13163343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:26: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.213.0;
	Fri, 22 Jun 2012 09:26:50 +0100
Message-ID: <1340353609.19647.24.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Fri, 22 Jun 2012 09:26:49 +0100
In-Reply-To: <20120621184036.GD2640@US-SEA-R8XVZTX>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621184036.GD2640@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 19:43 +0100, Matt Wilson wrote:
> On Thu, Jun 21, 2012 at 01:33:25AM -0700, Ian Campbell wrote:
> > On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> > >  SHAREDIR    ?= $(PREFIX)/share
> > >  DOCDIR      ?= $(SHAREDIR)/doc/xen
> > > @@ -67,7 +68,7 @@ endef
> > >  
> > >  ifneq ($(EXTRA_PREFIX),)
> > >  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> > > -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> > > +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))
> > 
> > since we are sort of reverting 16950:0faf620bc749 here this could in
> > theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
> > include Tools.mk though. :-/
> 
> That would result in looking in /some/extra/prefix/usr/lib, which is
> not what I'd expect is desired. 

Oh, right, yes!

> > > diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
> > > --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> > > +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> > > @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
> > >  PREFIX ?= /usr
> > >  BINDIR = $(PREFIX)/bin
> > >  INCLUDEDIR = $(PREFIX)/include
> > > -LIBLEAFDIR = lib
> > > -LIBLEAFDIR_x86_32 = lib
> > > -LIBLEAFDIR_x86_64 ?= lib64
> > > -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> > > -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> > > -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> > > -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> > > +LIBEXEC = $(PREFIX)/lib/xen/bin
> > 
> > Wouldn't this be $(LIBDIR)/xen/bin ?
> 
> No, the old behavior (which I retained) is to always install
> $(LIBEXEC) files to /usr/lib/xen/bin (since it was defined to
> $(LIBDIR_x86_32), which expands to /usr/lib),

OK.

> Confusingly, we also install "private" binaries to $(PRIVATE_BINDIR),
> which expands to $(PRIVATE_PREFIX)/bin which expands to $(LIBDIR)/xen/bin,
> which expands to /usr/lib64/xen/bin. This results in paths like:
> 
> /usr/lib64/xen/bin/lsevtchn

... weird!

[...]

> > I suppose configure defines a libexec but it isn't the one we want?
> 
> By default, configure will define libexec to be /usr/libexec, which I
> like. If we switched to using the value provided from configure, we
> people who don't like /usr/libexec could just provide a different
> value at ./configure time.

Lets leave that until 4.3, I'm already a little uncomfortable messing
with the build system at this stage in 4.2 (there's always unforeseen
consequences to these sorts of changes, no matter how diligent we all
are :-/). For the lib vs. lib64 breakage on multiarch I think the risk
is worth it, but for more "cosmetic" issues like libexec I'd rather pass
for now.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 08:33:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1ShzIf-0007zG-81; Fri, 22 Jun 2012 08:33: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 1ShzIe-0007z4-5x
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:33:04 +0000
Received: from [193.109.254.147:15236] by server-3.bemta-14.messagelabs.com id
	67/EA-08687-FBD24EF4; Fri, 22 Jun 2012 08:33:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340353982!10179853!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23873 invoked from network); 22 Jun 2012 08:33:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	22 Jun 2012 08:33:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 09:33:02 +0100
Message-Id: <4FE44A0A020000780008B4AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 09:33:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE35452020000780008B274@nat28.tlf.novell.com>
	<1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part143AB2FA.0__="
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part143AB2FA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When attempting to use AMD's extension to access the extended PCI config
space, only the low byte of the register number was being passed to XSM.
Include the correct value of the register if this feature is enabled;
otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Don't fail the permission check except when the MSR can't be read.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1701,6 +1701,18 @@ static int pci_cfg_ok(struct domain *d,=20
             return 0;
     }
     start =3D d->arch.pci_cf8 & 0xFF;
+    /* AMD extended configuration space access? */
+    if ( (d->arch.pci_cf8 & 0x0F000000) &&
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_AMD &&
+         boot_cpu_data.x86 >=3D 0x10 && boot_cpu_data.x86 <=3D 0x17 )
+    {
+        uint64_t msr_val;
+
+        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
+            return 0;
+        if ( msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT) )
+            start |=3D (d->arch.pci_cf8 >> 16) & 0xF00;
+    }
     end =3D start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
         return 0;




--=__Part143AB2FA.0__=
Content-Type: text/plain; name="x86-PCI-xsm-AMD-ECS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-PCI-xsm-AMD-ECS.patch"

x86/PCI: pass correct register value to XSM=0A=0AWhen attempting to use =
AMD's extension to access the extended PCI config=0Aspace, only the low =
byte of the register number was being passed to XSM.=0AInclude the correct =
value of the register if this feature is enabled;=0Aotherwise, bits 24-30 =
of port cf8 are reserved, so disallow the invalid=0Aaccess.=0A=0ASigned-off=
-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>=0A=0ADon't fail the permission=
 check except when the MSR can't be read.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/tr=
aps.c=0A@@ -1701,6 +1701,18 @@ static int pci_cfg_ok(struct domain *d, =0A =
            return 0;=0A     }=0A     start =3D d->arch.pci_cf8 & =
0xFF;=0A+    /* AMD extended configuration space access? */=0A+    if ( =
(d->arch.pci_cf8 & 0x0F000000) &&=0A+         boot_cpu_data.x86_vendor =
=3D=3D X86_VENDOR_AMD &&=0A+         boot_cpu_data.x86 >=3D 0x10 && =
boot_cpu_data.x86 <=3D 0x17 )=0A+    {=0A+        uint64_t msr_val;=0A+=0A+=
        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )=0A+            return =
0;=0A+        if ( msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT) =
)=0A+            start |=3D (d->arch.pci_cf8 >> 16) & 0xF00;=0A+    }=0A   =
  end =3D start + size - 1;=0A     if (xsm_pci_config_permission(d, =
machine_bdf, start, end, write))=0A         return 0;=0A
--=__Part143AB2FA.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

--=__Part143AB2FA.0__=--


From xen-devel-bounces@lists.xen.org Fri Jun 22 08:33:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1ShzIf-0007zG-81; Fri, 22 Jun 2012 08:33: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 1ShzIe-0007z4-5x
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:33:04 +0000
Received: from [193.109.254.147:15236] by server-3.bemta-14.messagelabs.com id
	67/EA-08687-FBD24EF4; Fri, 22 Jun 2012 08:33:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340353982!10179853!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23873 invoked from network); 22 Jun 2012 08:33:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	22 Jun 2012 08:33:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 09:33:02 +0100
Message-Id: <4FE44A0A020000780008B4AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 09:33:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <4FE35452020000780008B274@nat28.tlf.novell.com>
	<1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1340298082-31338-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part143AB2FA.0__="
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part143AB2FA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When attempting to use AMD's extension to access the extended PCI config
space, only the low byte of the register number was being passed to XSM.
Include the correct value of the register if this feature is enabled;
otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Don't fail the permission check except when the MSR can't be read.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1701,6 +1701,18 @@ static int pci_cfg_ok(struct domain *d,=20
             return 0;
     }
     start =3D d->arch.pci_cf8 & 0xFF;
+    /* AMD extended configuration space access? */
+    if ( (d->arch.pci_cf8 & 0x0F000000) &&
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_AMD &&
+         boot_cpu_data.x86 >=3D 0x10 && boot_cpu_data.x86 <=3D 0x17 )
+    {
+        uint64_t msr_val;
+
+        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
+            return 0;
+        if ( msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT) )
+            start |=3D (d->arch.pci_cf8 >> 16) & 0xF00;
+    }
     end =3D start + size - 1;
     if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
         return 0;




--=__Part143AB2FA.0__=
Content-Type: text/plain; name="x86-PCI-xsm-AMD-ECS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-PCI-xsm-AMD-ECS.patch"

x86/PCI: pass correct register value to XSM=0A=0AWhen attempting to use =
AMD's extension to access the extended PCI config=0Aspace, only the low =
byte of the register number was being passed to XSM.=0AInclude the correct =
value of the register if this feature is enabled;=0Aotherwise, bits 24-30 =
of port cf8 are reserved, so disallow the invalid=0Aaccess.=0A=0ASigned-off=
-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>=0A=0ADon't fail the permission=
 check except when the MSR can't be read.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/tr=
aps.c=0A@@ -1701,6 +1701,18 @@ static int pci_cfg_ok(struct domain *d, =0A =
            return 0;=0A     }=0A     start =3D d->arch.pci_cf8 & =
0xFF;=0A+    /* AMD extended configuration space access? */=0A+    if ( =
(d->arch.pci_cf8 & 0x0F000000) &&=0A+         boot_cpu_data.x86_vendor =
=3D=3D X86_VENDOR_AMD &&=0A+         boot_cpu_data.x86 >=3D 0x10 && =
boot_cpu_data.x86 <=3D 0x17 )=0A+    {=0A+        uint64_t msr_val;=0A+=0A+=
        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )=0A+            return =
0;=0A+        if ( msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT) =
)=0A+            start |=3D (d->arch.pci_cf8 >> 16) & 0xF00;=0A+    }=0A   =
  end =3D start + size - 1;=0A     if (xsm_pci_config_permission(d, =
machine_bdf, start, end, write))=0A         return 0;=0A
--=__Part143AB2FA.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

--=__Part143AB2FA.0__=--


From xen-devel-bounces@lists.xen.org Fri Jun 22 08:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1Shzcz-0008KO-8E; Fri, 22 Jun 2012 08:54:05 +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 1Shzcx-0008KJ-Hh
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:54:03 +0000
Received: from [193.109.254.147:59349] by server-11.bemta-14.messagelabs.com
	id 6B/66-24843-AA234EF4; Fri, 22 Jun 2012 08:54:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340355239!3301577!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15476 invoked from network); 22 Jun 2012 08:54:01 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:54:01 -0000
Received: by pbbro12 with SMTP id ro12so3799171pbb.32
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 01:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=2l4nmpI9dfcPXCUhfiUUWWo2s8gLNEBH42qPcFMP/5g=;
	b=jJxQ7KpSMj2tKlxU8tjfBcNTmlNjabqN/+MNmH1E7SkNcHvMs/ll/uQOPDyA2Z1U3r
	1/mf7N10QL1bxLa3RykWKwE4ICCEhbxEspBBax1A0I80+lM1/GTIvINOKJ4Yb8zf6Ith
	DkMmrxEtHmjslsXpFODzVe1TPfdzzZ+X2qmFfIhUiqoH26LyxJ1Hh10qDyOP43o+U1sm
	SQEbyn+GxPlmtXH/PTIsOtrWTnnNW8WC+5iiFspGuNRAIGM/je5ni0dI+gP8Lf1jgP7B
	NAXKGV84JLCdEaU+MZsfLDVL3h3ll4XqctbccssFtLKi1EWqZ06ZGA6sOugRaF2Ml3ID
	jlOg==
Received: by 10.68.200.162 with SMTP id jt2mr8097803pbc.54.1340355238364;
	Fri, 22 Jun 2012 01:53:58 -0700 (PDT)
Received: from [192.168.1.54] ([198.162.59.100])
	by mx.google.com with ESMTPS id rv5sm38350516pbc.56.2012.06.22.01.53.50
	(version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 01:53:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 22 Jun 2012 09:53:37 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC09F121.4374C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] AMD IOMMU: add mechanism to protect their
	PCI devices' config spaces
Thread-Index: Ac1QVIMQEyJmHAu4hU+ssGFf/FA6zw==
In-Reply-To: <4FE44667020000780008B492@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU: add mechanism to protect their
 PCI devices' config spaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 09:18, "Jan Beulich" <JBeulich@suse.com> wrote:

> Recent Dom0 kernels want to disable PCI MSI on all devices, yet doing
> so on AMD IOMMUs (which get represented by a PCI device) disables part
> of the functionality set up by the hypervisor.
> 
> Add a mechanism to mark certain PCI devices as having write protected
> config spaces (both through port based [method 1] accesses and, for
> x86-64, mmconfig), and use that for AMD's IOMMUs.
> 
> Note that due to ptwr_do_page_fault() being run first, there'll be a
> MEM_LOG() issued for each such mmconfig based write attempt. If that's
> undesirable, the order of the calls in fixup_page_fault() would need
> to be swapped.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Wei Wang <wei.wang2@amd.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5209,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>      return 0;
>  }
>  
> +#ifdef __x86_64__
> +/*************************
> + * fault handling for read-only MMIO pages
> + */
> +
> +struct mmio_ro_emulate_ctxt {
> +    struct x86_emulate_ctxt ctxt;
> +    unsigned long cr2;
> +};
> +
> +static int mmio_ro_emulated_read(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    return X86EMUL_UNHANDLEABLE;
> +}
> +
> +static int mmio_ro_emulated_write(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
> +
> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
> +    if ( ((bytes | offset) & (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
> +    {
> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx, bytes=%u)",
> +                mmio_ro_ctxt->cr2, offset, bytes);
> +        return X86EMUL_UNHANDLEABLE;
> +    }
> +
> +    return X86EMUL_OKAY;
> +}
> +
> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
> +    .read       = mmio_ro_emulated_read,
> +    .insn_fetch = ptwr_emulated_read,
> +    .write      = mmio_ro_emulated_write,
> +};
> +
> +/* Check if guest is trying to modify a r/o MMIO page. */
> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
> +                          struct cpu_user_regs *regs)
> +{
> +    l1_pgentry_t      pte;
> +    unsigned long     mfn;
> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
> +                                  32 : BITS_PER_LONG;
> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
> +        .ctxt.regs = regs,
> +        .ctxt.addr_size = addr_size,
> +        .ctxt.sp_size = addr_size,
> +        .cr2 = addr
> +    };
> +    int rc;
> +
> +    /* Attempt to read the PTE that maps the VA being accessed. */
> +    guest_get_eff_l1e(v, addr, &pte);
> +
> +    /* We are looking only for read-only mappings of MMIO pages. */
> +    if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) )
> +        return 0;
> +
> +    mfn = l1e_get_pfn(pte);
> +    if ( mfn_valid(mfn) )
> +    {
> +        struct page_info *page = mfn_to_page(mfn);
> +        struct domain *owner = page_get_owner_and_reference(page);
> +
> +        if ( owner )
> +            put_page(page);
> +        if ( owner != dom_io )
> +            return 0;
> +    }
> +
> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
> +        return 0;
> +
> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);
> +
> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
> +}
> +#endif /* __x86_64__ */
> +
>  void free_xen_pagetable(void *v)
>  {
>      if ( system_state == SYS_STATE_early_boot )
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>          return 0;
>      }
>  
> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
> -         guest_kernel_mode(v, regs) )
> -    {
> -        unsigned int mbs = PFEC_write_access;
> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
> -
> -        /* Do not check if access-protection fault since the page may
> -           legitimately be not present in shadow page tables */
> -        if ( !paging_mode_enabled(d) )
> -            mbs |= PFEC_page_present;
> -
> -        if ( ((regs->error_code & (mbs | mbz)) == mbs) &&
> +    if ( guest_kernel_mode(v, regs) &&
> +         !(regs->error_code & (PFEC_reserved_bit | PFEC_insn_fetch)) &&
> +         (regs->error_code & PFEC_write_access) )
> +    {
> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
> +             /* Do not check if access-protection fault since the page may
> +                legitimately be not present in shadow page tables */
> +             (paging_mode_enabled(d) ||
> +              (regs->error_code & PFEC_page_present)) &&
>               ptwr_do_page_fault(v, addr, regs) )
>              return EXCRET_fault_fixed;
> +
> +#ifdef __x86_64__
> +        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_present) &&
> +             mmio_ro_do_page_fault(v, addr, regs) )
> +            return EXCRET_fault_fixed;
> +#endif
>      }
>  
>      /* For non-external shadowed guests, we fix up both their own
> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>          return 0;
>  
>      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
> +    if ( write )
> +    {
> +        const unsigned long *ro_map = pci_get_ro_map(0);
> +
> +        if ( ro_map && test_bit(machine_bdf, ro_map) )
> +            return 0;
> +    }
>      start = d->arch.pci_cf8 & 0xFF;
>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
> --- a/xen/arch/x86/x86_32/pci.c
> +++ b/xen/arch/x86/x86_32/pci.c
> @@ -6,6 +6,7 @@
>  
>  #include <xen/spinlock.h>
>  #include <xen/pci.h>
> +#include <xen/init.h>
>  #include <asm/io.h>
>  
>  #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
> @@ -70,3 +71,7 @@ void pci_conf_write32(
>      BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
>      pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>  }
> +
> +void __init arch_pci_ro_device(int seg, int bdf)
> +{
> +}
> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> @@ -14,6 +14,8 @@
>  #include <xen/xmalloc.h>
>  #include <xen/pci.h>
>  #include <xen/pci_regs.h>
> +#include <xen/iommu.h>
> +#include <xen/rangeset.h>
>  
>  #include "mmconfig.h"
>  
> @@ -132,9 +134,30 @@ static void __iomem *mcfg_ioremap(const
>      return (void __iomem *) virt;
>  }
>  
> +void arch_pci_ro_device(int seg, int bdf)
> +{
> +    unsigned int idx, bus = PCI_BUS(bdf);
> +
> +    for (idx = 0; idx < pci_mmcfg_config_num; ++idx) {
> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
> +        unsigned long mfn = (cfg->address >> PAGE_SHIFT) + bdf;
> +
> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
> +            cfg->start_bus_number > bus || cfg->end_bus_number < bus)
> +            continue;
> +
> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
> +            printk(XENLOG_ERR
> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx)
> read-only\n",
> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
> +                   mfn);
> +    }
> +}
> +
>  int pci_mmcfg_arch_enable(unsigned int idx)
>  {
>      const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>  
>      if (pci_mmcfg_virt[idx].virt)
>          return 0;
> @@ -146,6 +169,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>      }
>      printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>             cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
> +    if (ro_map) {
> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
> +
> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf)) <= end) {
> +            arch_pci_ro_device(cfg->pci_segment, bdf);
> +            if (bdf++ == end)
> +                break;
> +        }
> +    }
>      return 0;
>  }
>  
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>      if ( rt )
>          return -ENODEV;
>  
> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
> +    if ( rt )
> +        printk(XENLOG_ERR
> +               "Could not mark config space of %04x:%02x:%02x.%u read-only
> (%d)\n",
> +               iommu->seg, bus, dev, func, rt);
> +
>      list_add_tail(&iommu->list, &amd_iommu_head);
>  
>      return 0;
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>  unlock:
>      spin_unlock(&d->event_lock);
>  }
> -
> -static int __init setup_mmio_ro_ranges(void)
> -{
> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> -                                  RANGESETF_prettyprint_hex);
> -    return 0;
> -}
> -__initcall(setup_mmio_ro_ranges);
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -36,6 +36,7 @@
>  struct pci_seg {
>      struct list_head alldevs_list;
>      u16 nr;
> +    unsigned long *ro_map;
>      /* bus2bridge_lock protects bus2bridge array */
>      spinlock_t bus2bridge_lock;
>  #define MAX_BUSES 256
> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>      radix_tree_init(&pci_segments);
>      if ( !alloc_pseg(0) )
>          panic("Could not initialize PCI segment 0\n");
> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> +                                  RANGESETF_prettyprint_hex);
>  }
>  
>  int __init pci_add_segment(u16 seg)
> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>      return alloc_pseg(seg) ? 0 : -ENOMEM;
>  }
>  
> +const unsigned long *pci_get_ro_map(u16 seg)
> +{
> +    struct pci_seg *pseg = get_pseg(seg);
> +
> +    return pseg ? pseg->ro_map : NULL;
> +}
> +
>  static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>  {
>      struct pci_dev *pdev;
> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>      xfree(pdev);
>  }
>  
> +int __init pci_ro_device(int seg, int bus, int devfn)
> +{
> +    struct pci_seg *pseg = alloc_pseg(seg);
> +    struct pci_dev *pdev;
> +
> +    if ( !pseg )
> +        return -ENOMEM;
> +    pdev = alloc_pdev(pseg, bus, devfn);
> +    if ( !pdev )
> +        return -ENOMEM;
> +
> +    if ( !pseg->ro_map )
> +    {
> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
> +
> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
> +        if ( !pseg->ro_map )
> +            return -ENOMEM;
> +        memset(pseg->ro_map, 0, sz);
> +    }
> +
> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
> +
> +    return 0;
> +}
> +
>  struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>  {
>      struct pci_seg *pseg = get_pseg(seg);
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>  
>  int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>                          struct cpu_user_regs *);
> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
> +                           struct cpu_user_regs *);
>  
>  int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>  
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>  void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>  void pci_release_devices(struct domain *d);
>  int pci_add_segment(u16 seg);
> +const unsigned long *pci_get_ro_map(u16 seg);
>  int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
>  int pci_remove_device(u16 seg, u8 bus, u8 devfn);
> +int pci_ro_device(int seg, int bus, int devfn);
> +void arch_pci_ro_device(int seg, int bdf);
>  struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>  struct pci_dev *pci_get_pdev_by_domain(
>      struct domain *, int seg, int bus, int devfn);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 22 08:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08: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 1Shzcz-0008KO-8E; Fri, 22 Jun 2012 08:54:05 +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 1Shzcx-0008KJ-Hh
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:54:03 +0000
Received: from [193.109.254.147:59349] by server-11.bemta-14.messagelabs.com
	id 6B/66-24843-AA234EF4; Fri, 22 Jun 2012 08:54:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340355239!3301577!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15476 invoked from network); 22 Jun 2012 08:54:01 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:54:01 -0000
Received: by pbbro12 with SMTP id ro12so3799171pbb.32
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 01:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=2l4nmpI9dfcPXCUhfiUUWWo2s8gLNEBH42qPcFMP/5g=;
	b=jJxQ7KpSMj2tKlxU8tjfBcNTmlNjabqN/+MNmH1E7SkNcHvMs/ll/uQOPDyA2Z1U3r
	1/mf7N10QL1bxLa3RykWKwE4ICCEhbxEspBBax1A0I80+lM1/GTIvINOKJ4Yb8zf6Ith
	DkMmrxEtHmjslsXpFODzVe1TPfdzzZ+X2qmFfIhUiqoH26LyxJ1Hh10qDyOP43o+U1sm
	SQEbyn+GxPlmtXH/PTIsOtrWTnnNW8WC+5iiFspGuNRAIGM/je5ni0dI+gP8Lf1jgP7B
	NAXKGV84JLCdEaU+MZsfLDVL3h3ll4XqctbccssFtLKi1EWqZ06ZGA6sOugRaF2Ml3ID
	jlOg==
Received: by 10.68.200.162 with SMTP id jt2mr8097803pbc.54.1340355238364;
	Fri, 22 Jun 2012 01:53:58 -0700 (PDT)
Received: from [192.168.1.54] ([198.162.59.100])
	by mx.google.com with ESMTPS id rv5sm38350516pbc.56.2012.06.22.01.53.50
	(version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 01:53:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 22 Jun 2012 09:53:37 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC09F121.4374C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] AMD IOMMU: add mechanism to protect their
	PCI devices' config spaces
Thread-Index: Ac1QVIMQEyJmHAu4hU+ssGFf/FA6zw==
In-Reply-To: <4FE44667020000780008B492@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU: add mechanism to protect their
 PCI devices' config spaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 09:18, "Jan Beulich" <JBeulich@suse.com> wrote:

> Recent Dom0 kernels want to disable PCI MSI on all devices, yet doing
> so on AMD IOMMUs (which get represented by a PCI device) disables part
> of the functionality set up by the hypervisor.
> 
> Add a mechanism to mark certain PCI devices as having write protected
> config spaces (both through port based [method 1] accesses and, for
> x86-64, mmconfig), and use that for AMD's IOMMUs.
> 
> Note that due to ptwr_do_page_fault() being run first, there'll be a
> MEM_LOG() issued for each such mmconfig based write attempt. If that's
> undesirable, the order of the calls in fixup_page_fault() would need
> to be swapped.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Wei Wang <wei.wang2@amd.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5209,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>      return 0;
>  }
>  
> +#ifdef __x86_64__
> +/*************************
> + * fault handling for read-only MMIO pages
> + */
> +
> +struct mmio_ro_emulate_ctxt {
> +    struct x86_emulate_ctxt ctxt;
> +    unsigned long cr2;
> +};
> +
> +static int mmio_ro_emulated_read(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    return X86EMUL_UNHANDLEABLE;
> +}
> +
> +static int mmio_ro_emulated_write(
> +    enum x86_segment seg,
> +    unsigned long offset,
> +    void *p_data,
> +    unsigned int bytes,
> +    struct x86_emulate_ctxt *ctxt)
> +{
> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
> +
> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
> +    if ( ((bytes | offset) & (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
> +    {
> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx, bytes=%u)",
> +                mmio_ro_ctxt->cr2, offset, bytes);
> +        return X86EMUL_UNHANDLEABLE;
> +    }
> +
> +    return X86EMUL_OKAY;
> +}
> +
> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
> +    .read       = mmio_ro_emulated_read,
> +    .insn_fetch = ptwr_emulated_read,
> +    .write      = mmio_ro_emulated_write,
> +};
> +
> +/* Check if guest is trying to modify a r/o MMIO page. */
> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
> +                          struct cpu_user_regs *regs)
> +{
> +    l1_pgentry_t      pte;
> +    unsigned long     mfn;
> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
> +                                  32 : BITS_PER_LONG;
> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
> +        .ctxt.regs = regs,
> +        .ctxt.addr_size = addr_size,
> +        .ctxt.sp_size = addr_size,
> +        .cr2 = addr
> +    };
> +    int rc;
> +
> +    /* Attempt to read the PTE that maps the VA being accessed. */
> +    guest_get_eff_l1e(v, addr, &pte);
> +
> +    /* We are looking only for read-only mappings of MMIO pages. */
> +    if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) )
> +        return 0;
> +
> +    mfn = l1e_get_pfn(pte);
> +    if ( mfn_valid(mfn) )
> +    {
> +        struct page_info *page = mfn_to_page(mfn);
> +        struct domain *owner = page_get_owner_and_reference(page);
> +
> +        if ( owner )
> +            put_page(page);
> +        if ( owner != dom_io )
> +            return 0;
> +    }
> +
> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
> +        return 0;
> +
> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt, &mmio_ro_emulate_ops);
> +
> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
> +}
> +#endif /* __x86_64__ */
> +
>  void free_xen_pagetable(void *v)
>  {
>      if ( system_state == SYS_STATE_early_boot )
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>          return 0;
>      }
>  
> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
> -         guest_kernel_mode(v, regs) )
> -    {
> -        unsigned int mbs = PFEC_write_access;
> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
> -
> -        /* Do not check if access-protection fault since the page may
> -           legitimately be not present in shadow page tables */
> -        if ( !paging_mode_enabled(d) )
> -            mbs |= PFEC_page_present;
> -
> -        if ( ((regs->error_code & (mbs | mbz)) == mbs) &&
> +    if ( guest_kernel_mode(v, regs) &&
> +         !(regs->error_code & (PFEC_reserved_bit | PFEC_insn_fetch)) &&
> +         (regs->error_code & PFEC_write_access) )
> +    {
> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables) &&
> +             /* Do not check if access-protection fault since the page may
> +                legitimately be not present in shadow page tables */
> +             (paging_mode_enabled(d) ||
> +              (regs->error_code & PFEC_page_present)) &&
>               ptwr_do_page_fault(v, addr, regs) )
>              return EXCRET_fault_fixed;
> +
> +#ifdef __x86_64__
> +        if ( IS_PRIV(d) && (regs->error_code & PFEC_page_present) &&
> +             mmio_ro_do_page_fault(v, addr, regs) )
> +            return EXCRET_fault_fixed;
> +#endif
>      }
>  
>      /* For non-external shadowed guests, we fix up both their own
> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>          return 0;
>  
>      machine_bdf = (d->arch.pci_cf8 >> 8) & 0xFFFF;
> +    if ( write )
> +    {
> +        const unsigned long *ro_map = pci_get_ro_map(0);
> +
> +        if ( ro_map && test_bit(machine_bdf, ro_map) )
> +            return 0;
> +    }
>      start = d->arch.pci_cf8 & 0xFF;
>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
> --- a/xen/arch/x86/x86_32/pci.c
> +++ b/xen/arch/x86/x86_32/pci.c
> @@ -6,6 +6,7 @@
>  
>  #include <xen/spinlock.h>
>  #include <xen/pci.h>
> +#include <xen/init.h>
>  #include <asm/io.h>
>  
>  #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
> @@ -70,3 +71,7 @@ void pci_conf_write32(
>      BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
>      pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>  }
> +
> +void __init arch_pci_ro_device(int seg, int bdf)
> +{
> +}
> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> @@ -14,6 +14,8 @@
>  #include <xen/xmalloc.h>
>  #include <xen/pci.h>
>  #include <xen/pci_regs.h>
> +#include <xen/iommu.h>
> +#include <xen/rangeset.h>
>  
>  #include "mmconfig.h"
>  
> @@ -132,9 +134,30 @@ static void __iomem *mcfg_ioremap(const
>      return (void __iomem *) virt;
>  }
>  
> +void arch_pci_ro_device(int seg, int bdf)
> +{
> +    unsigned int idx, bus = PCI_BUS(bdf);
> +
> +    for (idx = 0; idx < pci_mmcfg_config_num; ++idx) {
> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
> +        unsigned long mfn = (cfg->address >> PAGE_SHIFT) + bdf;
> +
> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
> +            cfg->start_bus_number > bus || cfg->end_bus_number < bus)
> +            continue;
> +
> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
> +            printk(XENLOG_ERR
> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx)
> read-only\n",
> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
> +                   mfn);
> +    }
> +}
> +
>  int pci_mmcfg_arch_enable(unsigned int idx)
>  {
>      const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>  
>      if (pci_mmcfg_virt[idx].virt)
>          return 0;
> @@ -146,6 +169,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>      }
>      printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>             cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
> +    if (ro_map) {
> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
> +
> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf)) <= end) {
> +            arch_pci_ro_device(cfg->pci_segment, bdf);
> +            if (bdf++ == end)
> +                break;
> +        }
> +    }
>      return 0;
>  }
>  
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>      if ( rt )
>          return -ENODEV;
>  
> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
> +    if ( rt )
> +        printk(XENLOG_ERR
> +               "Could not mark config space of %04x:%02x:%02x.%u read-only
> (%d)\n",
> +               iommu->seg, bus, dev, func, rt);
> +
>      list_add_tail(&iommu->list, &amd_iommu_head);
>  
>      return 0;
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>  unlock:
>      spin_unlock(&d->event_lock);
>  }
> -
> -static int __init setup_mmio_ro_ranges(void)
> -{
> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> -                                  RANGESETF_prettyprint_hex);
> -    return 0;
> -}
> -__initcall(setup_mmio_ro_ranges);
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -36,6 +36,7 @@
>  struct pci_seg {
>      struct list_head alldevs_list;
>      u16 nr;
> +    unsigned long *ro_map;
>      /* bus2bridge_lock protects bus2bridge array */
>      spinlock_t bus2bridge_lock;
>  #define MAX_BUSES 256
> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>      radix_tree_init(&pci_segments);
>      if ( !alloc_pseg(0) )
>          panic("Could not initialize PCI segment 0\n");
> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> +                                  RANGESETF_prettyprint_hex);
>  }
>  
>  int __init pci_add_segment(u16 seg)
> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>      return alloc_pseg(seg) ? 0 : -ENOMEM;
>  }
>  
> +const unsigned long *pci_get_ro_map(u16 seg)
> +{
> +    struct pci_seg *pseg = get_pseg(seg);
> +
> +    return pseg ? pseg->ro_map : NULL;
> +}
> +
>  static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>  {
>      struct pci_dev *pdev;
> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>      xfree(pdev);
>  }
>  
> +int __init pci_ro_device(int seg, int bus, int devfn)
> +{
> +    struct pci_seg *pseg = alloc_pseg(seg);
> +    struct pci_dev *pdev;
> +
> +    if ( !pseg )
> +        return -ENOMEM;
> +    pdev = alloc_pdev(pseg, bus, devfn);
> +    if ( !pdev )
> +        return -ENOMEM;
> +
> +    if ( !pseg->ro_map )
> +    {
> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
> +
> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
> +        if ( !pseg->ro_map )
> +            return -ENOMEM;
> +        memset(pseg->ro_map, 0, sz);
> +    }
> +
> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
> +
> +    return 0;
> +}
> +
>  struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>  {
>      struct pci_seg *pseg = get_pseg(seg);
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>  
>  int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>                          struct cpu_user_regs *);
> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
> +                           struct cpu_user_regs *);
>  
>  int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>  
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>  void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>  void pci_release_devices(struct domain *d);
>  int pci_add_segment(u16 seg);
> +const unsigned long *pci_get_ro_map(u16 seg);
>  int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
>  int pci_remove_device(u16 seg, u8 bus, u8 devfn);
> +int pci_ro_device(int seg, int bus, int devfn);
> +void arch_pci_ro_device(int seg, int bdf);
>  struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>  struct pci_dev *pci_get_pdev_by_domain(
>      struct domain *, int seg, int bus, int devfn);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 22 08:54:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08:54: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 1Shzd3-0008Kh-Kb; Fri, 22 Jun 2012 08:54:09 +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 1Shzd2-0008KX-BE
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:54:08 +0000
Received: from [193.109.254.147:2193] by server-4.bemta-14.messagelabs.com id
	CE/74-02077-FA234EF4; Fri, 22 Jun 2012 08:54:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340355239!3301577!2
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15894 invoked from network); 22 Jun 2012 08:54:06 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:54:06 -0000
Received: by mail-pb0-f45.google.com with SMTP id ro12so3799171pbb.32
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 01:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WdsFk0s7sHa6mTOj88g/+160t6FtSK4P1yk7CKKzsbs=;
	b=U8INyH3XoyEl3YWbxyRurv3535nI5Viqz8un3W+l6YYpf/cCwePXEcb67XGVHAF99r
	jyqZ9s/Q2yPfiitjd0hvjUk6WUF0FwoOjCahlmr5a+ElyqaMf3QkQwRMveHimRMMv7rb
	ox8ufdNEO+myHGOp1CUNeXj+za6xnY1I4HoJ+bgw6gjfeFxEjWXYJ+aKqOVrEf+UYZDt
	KHliIF1/jDTpmM1bIwlagsDtai78g73Adei3wpWNstxteH9vRnCI5XjEFy3Nay9GtRRn
	5EJdPmTsaPk4s+6AstD/NKABG44wZ8gboLD9Mdna0yMwLujvwCgnL5Epl5gFPIwCgBp1
	/lGg==
Received: by 10.68.217.40 with SMTP id ov8mr7416075pbc.131.1340355246269;
	Fri, 22 Jun 2012 01:54:06 -0700 (PDT)
Received: from [192.168.1.54] ([198.162.59.100])
	by mx.google.com with ESMTPS id rv5sm38350516pbc.56.2012.06.22.01.54.02
	(version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 01:54:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 22 Jun 2012 09:53:51 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <CC09F12F.4374D%keir@xen.org>
Thread-Topic: [PATCH] x86/PCI: pass correct register value to XSM
Thread-Index: Ac1QVItoRHiVgV9JgUCkVsgQ8UNy7Q==
In-Reply-To: <4FE44A0A020000780008B4AC@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 09:33, "Jan Beulich" <JBeulich@suse.com> wrote:

> When attempting to use AMD's extension to access the extended PCI config
> space, only the low byte of the register number was being passed to XSM.
> Include the correct value of the register if this feature is enabled;
> otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
> access.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Don't fail the permission check except when the MSR can't be read.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1701,6 +1701,18 @@ static int pci_cfg_ok(struct domain *d,
>              return 0;
>      }
>      start = d->arch.pci_cf8 & 0xFF;
> +    /* AMD extended configuration space access? */
> +    if ( (d->arch.pci_cf8 & 0x0F000000) &&
> +         boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
> +         boot_cpu_data.x86 >= 0x10 && boot_cpu_data.x86 <= 0x17 )
> +    {
> +        uint64_t msr_val;
> +
> +        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
> +            return 0;
> +        if ( msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT) )
> +            start |= (d->arch.pci_cf8 >> 16) & 0xF00;
> +    }
>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>          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 Jun 22 08:54:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 08:54: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 1Shzd3-0008Kh-Kb; Fri, 22 Jun 2012 08:54:09 +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 1Shzd2-0008KX-BE
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 08:54:08 +0000
Received: from [193.109.254.147:2193] by server-4.bemta-14.messagelabs.com id
	CE/74-02077-FA234EF4; Fri, 22 Jun 2012 08:54:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340355239!3301577!2
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15894 invoked from network); 22 Jun 2012 08:54:06 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 08:54:06 -0000
Received: by mail-pb0-f45.google.com with SMTP id ro12so3799171pbb.32
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 01:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WdsFk0s7sHa6mTOj88g/+160t6FtSK4P1yk7CKKzsbs=;
	b=U8INyH3XoyEl3YWbxyRurv3535nI5Viqz8un3W+l6YYpf/cCwePXEcb67XGVHAF99r
	jyqZ9s/Q2yPfiitjd0hvjUk6WUF0FwoOjCahlmr5a+ElyqaMf3QkQwRMveHimRMMv7rb
	ox8ufdNEO+myHGOp1CUNeXj+za6xnY1I4HoJ+bgw6gjfeFxEjWXYJ+aKqOVrEf+UYZDt
	KHliIF1/jDTpmM1bIwlagsDtai78g73Adei3wpWNstxteH9vRnCI5XjEFy3Nay9GtRRn
	5EJdPmTsaPk4s+6AstD/NKABG44wZ8gboLD9Mdna0yMwLujvwCgnL5Epl5gFPIwCgBp1
	/lGg==
Received: by 10.68.217.40 with SMTP id ov8mr7416075pbc.131.1340355246269;
	Fri, 22 Jun 2012 01:54:06 -0700 (PDT)
Received: from [192.168.1.54] ([198.162.59.100])
	by mx.google.com with ESMTPS id rv5sm38350516pbc.56.2012.06.22.01.54.02
	(version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 01:54:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 22 Jun 2012 09:53:51 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <CC09F12F.4374D%keir@xen.org>
Thread-Topic: [PATCH] x86/PCI: pass correct register value to XSM
Thread-Index: Ac1QVItoRHiVgV9JgUCkVsgQ8UNy7Q==
In-Reply-To: <4FE44A0A020000780008B4AC@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/PCI: pass correct register value to XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 09:33, "Jan Beulich" <JBeulich@suse.com> wrote:

> When attempting to use AMD's extension to access the extended PCI config
> space, only the low byte of the register number was being passed to XSM.
> Include the correct value of the register if this feature is enabled;
> otherwise, bits 24-30 of port cf8 are reserved, so disallow the invalid
> access.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Don't fail the permission check except when the MSR can't be read.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1701,6 +1701,18 @@ static int pci_cfg_ok(struct domain *d,
>              return 0;
>      }
>      start = d->arch.pci_cf8 & 0xFF;
> +    /* AMD extended configuration space access? */
> +    if ( (d->arch.pci_cf8 & 0x0F000000) &&
> +         boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
> +         boot_cpu_data.x86 >= 0x10 && boot_cpu_data.x86 <= 0x17 )
> +    {
> +        uint64_t msr_val;
> +
> +        if ( rdmsr_safe(MSR_AMD64_NB_CFG, msr_val) )
> +            return 0;
> +        if ( msr_val & (1ULL << AMD64_NB_CFG_CF8_EXT_ENABLE_BIT) )
> +            start |= (d->arch.pci_cf8 >> 16) & 0xF00;
> +    }
>      end = start + size - 1;
>      if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>          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 Jun 22 09:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:04: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 1Shzn4-0000Hy-1E; Fri, 22 Jun 2012 09:04: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 1Shzn2-0000Ht-Rw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:04:28 +0000
Received: from [85.158.139.83:65263] by server-1.bemta-5.messagelabs.com id
	2A/87-19721-B1534EF4; Fri, 22 Jun 2012 09:04:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340355865!28420626!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjEyOTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26464 invoked from network); 22 Jun 2012 09:04:26 -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;
	22 Jun 2012 09:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199677992"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 05:04:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 05:04:24 -0400
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 1Shzmy-0005JC-HX;
	Fri, 22 Jun 2012 10:04:24 +0100
Message-ID: <4FE43518.9070106@citrix.com>
Date: Fri, 22 Jun 2012 10:04:24 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Wei Wang
	<wei.wang2@amd.com>, Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>, "xiantao.zhang@intel.com"
	<xiantao.zhang@intel.com>, Eddie Dong <eddie.dong@intel.com>
X-Enigmail-Version: 1.4.2
Subject: [Xen-devel] Other PCI devices to mark mark as read-only for 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

Following Jan's infrastructure to mark certain PCI devices as read only,
I think it wise to now consider what other PCI devices should really be
read only to dom0.

My preliminary thoughts include:

* PCI serial devices which Xen is configured to use
* Chipset devices (AMD IOMMU covered by previous patch)
* Cpu information

Are there any others I have overlooked, or reasons that dom0 should be
able to write to these areas?

On a related note, should there be a mechanism for dom0 to determine
which PCI configuration areas are read only to itself?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:04: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 1Shzn4-0000Hy-1E; Fri, 22 Jun 2012 09:04: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 1Shzn2-0000Ht-Rw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:04:28 +0000
Received: from [85.158.139.83:65263] by server-1.bemta-5.messagelabs.com id
	2A/87-19721-B1534EF4; Fri, 22 Jun 2012 09:04:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340355865!28420626!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjEyOTU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26464 invoked from network); 22 Jun 2012 09:04:26 -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;
	22 Jun 2012 09:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199677992"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 05:04:25 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 05:04:24 -0400
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 1Shzmy-0005JC-HX;
	Fri, 22 Jun 2012 10:04:24 +0100
Message-ID: <4FE43518.9070106@citrix.com>
Date: Fri, 22 Jun 2012 10:04:24 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Wei Wang
	<wei.wang2@amd.com>, Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>, "xiantao.zhang@intel.com"
	<xiantao.zhang@intel.com>, Eddie Dong <eddie.dong@intel.com>
X-Enigmail-Version: 1.4.2
Subject: [Xen-devel] Other PCI devices to mark mark as read-only for 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

Following Jan's infrastructure to mark certain PCI devices as read only,
I think it wise to now consider what other PCI devices should really be
read only to dom0.

My preliminary thoughts include:

* PCI serial devices which Xen is configured to use
* Chipset devices (AMD IOMMU covered by previous patch)
* Cpu information

Are there any others I have overlooked, or reasons that dom0 should be
able to write to these areas?

On a related note, should there be a mechanism for dom0 to determine
which PCI configuration areas are read only to itself?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:05:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Shzo5-0000Kt-Fl; Fri, 22 Jun 2012 09:05:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Shzo4-0000Kn-1V
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:05:32 +0000
Received: from [193.109.254.147:30900] by server-2.bemta-14.messagelabs.com id
	39/7B-01735-B5534EF4; Fri, 22 Jun 2012 09:05:31 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340355928!3989785!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4648 invoked from network); 22 Jun 2012 09:05:29 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Jun 2012 09:05:29 -0000
Received: from mail38-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Fri, 22 Jun 2012 09:03:58 +0000
Received: from mail38-ch1 (localhost [127.0.0.1])	by mail38-ch1-R.bigfish.com
	(Postfix) with ESMTP id 9B0963C04E2;
	Fri, 22 Jun 2012 09:03:58 +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: 0
X-BigFish: VPS0(zzbb2dI98dI9371I1432I8b9clzz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail38-ch1 (localhost.localdomain [127.0.0.1]) by mail38-ch1
	(MessageSwitch) id 1340355836531234_15796;
	Fri, 22 Jun 2012 09:03:56 +0000 (UTC)
Received: from CH1EHSMHS023.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.236])	by mail38-ch1.bigfish.com (Postfix) with ESMTP id
	7F813360132;	Fri, 22 Jun 2012 09:03:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 22 Jun 2012 09:03:55 +0000
X-WSS-ID: 0M60H8Y-02-0B7-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 21C19C8015;	Fri, 22 Jun 2012 04:05:21 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 22 Jun 2012 04:05:41 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 22 Jun 2012 04:05:20 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 22 Jun 2012
	05:05:12 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E02E249C20C; Fri, 22 Jun 2012
	10:05:11 +0100 (BST)
Message-ID: <4FE434D8.5030106@amd.com>
Date: Fri, 22 Jun 2012 11:03:20 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FE20C49020000780008AE25@nat28.tlf.novell.com>
	<4FE33DBC.4030104@amd.com>
	<4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
In-Reply-To: <4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
 disabled 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 06/21/2012 05:49 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 17:29, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/20/2012 05:45 PM, Jan Beulich wrote:
>>    >  Rather than submitting it for inclusion immediately, I'd rather see
>>> you first use it successfully. Below/attached what appears to
>>> work fine for me in contrived situations (i.e. hiding bridges with
>>> nothing connected, as I still don't have any AMD IOMMU system
>>> at hand).
>>
>> The patch works for me. IOMMU msi Capability is shown as enabled with
>> this patch.
>
> Keir,
>
> the question now arises whether we really want this, and
> particularly this late before 4.2. The Linux folks don't seem to
> be willing to take the strait forward workaround for the
> problem introduced at their end, so we will likely need
> something (the more that the questionable fix already made
> it into various stable trees) before 4.2 goes out (and even
> the older trees would be affected, just that putting a change
> like this there is even more questionable).
>
> There are obviously more potential problems in this area: If
> any of the MMIO addresses used by AMD's IOMMU is
> configurable through one of the BARs, and if Dom0 decides to
> re-assign MMIO space, neither allowing the writes nor simply
> dropping them as done here will work. Whether that's a real
> problem I don't know - Wei? And there might be other issues
> arising from dropping all writes - we might just currently not be
> aware of them.

AMD IOMMU does not have any PCI BARs, All address configuration should 
go to ACPI tables. So this should be fine at least for AMD IOMMU.

Thanks
Wei

> Jan
>
>> 00:00.2 Generic system peripheral [0806]: Advanced Micro Devices [AMD]
>> Device 1419
>>           Subsystem: Advanced Micro Devices [AMD] Device 1419
>>           Flags: bus master, fast devsel, latency 0, IRQ 11
>>           Capabilities: [40] Secure device<?>
>>           Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>
>>
>>> Jan
>>>
>>> Note that due to ptwr_do_page_fault() being run first, there'll be a
>>> MEM_LOG() issued for each such attempt. If that's undesirable, the
>>> order of the calls would need to be swapped.
>>>
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>>>                break;
>>>            case 1:
>>>                l1e_remove_flags(nl1e, _PAGE_RW);
>>> +            rc = 0;
>>>                break;
>>>            }
>>>            if ( page )
>>> @@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>>>        return 0;
>>>    }
>>>
>>> +#ifdef __x86_64__
>>> +/*************************
>>> + * fault handling for read-only MMIO pages
>>> + */
>>> +
>>> +struct mmio_ro_emulate_ctxt {
>>> +    struct x86_emulate_ctxt ctxt;
>>> +    unsigned long cr2;
>>> +};
>>> +
>>> +static int mmio_ro_emulated_read(
>>> +    enum x86_segment seg,
>>> +    unsigned long offset,
>>> +    void *p_data,
>>> +    unsigned int bytes,
>>> +    struct x86_emulate_ctxt *ctxt)
>>> +{
>>> +    return X86EMUL_UNHANDLEABLE;
>>> +}
>>> +
>>> +static int mmio_ro_emulated_write(
>>> +    enum x86_segment seg,
>>> +    unsigned long offset,
>>> +    void *p_data,
>>> +    unsigned int bytes,
>>> +    struct x86_emulate_ctxt *ctxt)
>>> +{
>>> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
>>> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
>>> +
>>> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
>>> +    if ( ((bytes | offset)&   (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
>>> +    {
>>> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx,
>> bytes=%u)",
>>> +                mmio_ro_ctxt->cr2, offset, bytes);
>>> +        return X86EMUL_UNHANDLEABLE;
>>> +    }
>>> +
>>> +    return X86EMUL_OKAY;
>>> +}
>>> +
>>> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
>>> +    .read       = mmio_ro_emulated_read,
>>> +    .insn_fetch = ptwr_emulated_read,
>>> +    .write      = mmio_ro_emulated_write,
>>> +};
>>> +
>>> +/* Check if guest is trying to modify a r/o MMIO page. */
>>> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
>>> +                          struct cpu_user_regs *regs)
>>> +{
>>> +    l1_pgentry_t      pte;
>>> +    unsigned long     mfn;
>>> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
>>> +                                  32 : BITS_PER_LONG;
>>> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
>>> +        .ctxt.regs = regs,
>>> +        .ctxt.addr_size = addr_size,
>>> +        .ctxt.sp_size = addr_size,
>>> +        .cr2 = addr
>>> +    };
>>> +    int rc;
>>> +
>>> +    /* Attempt to read the PTE that maps the VA being accessed. */
>>> +    guest_get_eff_l1e(v, addr,&pte);
>>> +
>>> +    /* We are looking only for read-only mappings of MMIO pages. */
>>> +    if ( ((l1e_get_flags(pte)&   (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT)
>> )
>>> +        return 0;
>>> +
>>> +    mfn = l1e_get_pfn(pte);
>>> +    if ( mfn_valid(mfn) )
>>> +    {
>>> +        struct page_info *page = mfn_to_page(mfn);
>>> +        struct domain *owner = page_get_owner_and_reference(page);
>>> +
>>> +        if ( owner )
>>> +            put_page(page);
>>> +        if ( owner != dom_io )
>>> +            return 0;
>>> +    }
>>> +
>>> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>> +        return 0;
>>> +
>>> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt,&mmio_ro_emulate_ops);
>>> +
>>> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
>>> +}
>>> +#endif /* __x86_64__ */
>>> +
>>>    void free_xen_pagetable(void *v)
>>>    {
>>>        if ( system_state == SYS_STATE_early_boot )
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>>>            return 0;
>>>        }
>>>
>>> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>>> -         guest_kernel_mode(v, regs) )
>>> -    {
>>> -        unsigned int mbs = PFEC_write_access;
>>> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
>>> -
>>> -        /* Do not check if access-protection fault since the page may
>>> -           legitimately be not present in shadow page tables */
>>> -        if ( !paging_mode_enabled(d) )
>>> -            mbs |= PFEC_page_present;
>>> -
>>> -        if ( ((regs->error_code&   (mbs | mbz)) == mbs)&&
>>> +    if ( guest_kernel_mode(v, regs)&&
>>> +         !(regs->error_code&   (PFEC_reserved_bit | PFEC_insn_fetch))&&
>>> +         (regs->error_code&   PFEC_write_access) )
>>> +    {
>>> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>>> +             /* Do not check if access-protection fault since the page may
>>> +                legitimately be not present in shadow page tables */
>>> +             (paging_mode_enabled(d) ||
>>> +              (regs->error_code&   PFEC_page_present))&&
>>>                 ptwr_do_page_fault(v, addr, regs) )
>>>                return EXCRET_fault_fixed;
>>> +
>>> +#ifdef __x86_64__
>>> +        if ( IS_PRIV(d)&&   (regs->error_code&   PFEC_page_present)&&
>>> +             mmio_ro_do_page_fault(v, addr, regs) )
>>> +            return EXCRET_fault_fixed;
>>> +#endif
>>>        }
>>>
>>>        /* For non-external shadowed guests, we fix up both their own
>>> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>>>            return 0;
>>>
>>>        machine_bdf = (d->arch.pci_cf8>>   8)&   0xFFFF;
>>> +    if ( write )
>>> +    {
>>> +        const unsigned long *ro_map = pci_get_ro_map(0);
>>> +
>>> +        if ( ro_map&&   test_bit(machine_bdf, ro_map) )
>>> +            return 0;
>>> +    }
>>>        start = d->arch.pci_cf8&   0xFF;
>>>        end = start + size - 1;
>>>        if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>>> --- a/xen/arch/x86/x86_32/pci.c
>>> +++ b/xen/arch/x86/x86_32/pci.c
>>> @@ -6,6 +6,7 @@
>>>
>>>    #include<xen/spinlock.h>
>>>    #include<xen/pci.h>
>>> +#include<xen/init.h>
>>>    #include<asm/io.h>
>>>
>>>    #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
>>> @@ -70,3 +71,7 @@ void pci_conf_write32(
>>>        BUG_ON((bus>   255) || (dev>   31) || (func>   7) || (reg>   255));
>>>        pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>>>    }
>>> +
>>> +void __init arch_pci_ro_device(int seg, int bdf)
>>> +{
>>> +}
>>> --- a/xen/arch/x86/x86_64/mmconfig_64.c
>>> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
>>> @@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const
>>>        return (void __iomem *) virt;
>>>    }
>>>
>>> +void arch_pci_ro_device(int seg, int bdf)
>>> +{
>>> +    unsigned int idx, bus = PCI_BUS(bdf);
>>> +
>>> +    for (idx = 0; idx<   pci_mmcfg_config_num; ++idx) {
>>> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
>>> +        unsigned long mfn = (cfg->address>>   PAGE_SHIFT) + bdf;
>>> +
>>> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
>>> +            cfg->start_bus_number>   bus || cfg->end_bus_number<   bus)
>>> +            continue;
>>> +
>>> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
>>> +            printk(XENLOG_ERR
>>> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx)
>> read-only\n",
>>> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
>>> +                   mfn);
>>> +    }
>>> +}
>>> +
>>>    int pci_mmcfg_arch_enable(unsigned int idx)
>>>    {
>>>        const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
>>> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>>>
>>>        if (pci_mmcfg_virt[idx].virt)
>>>            return 0;
>>> @@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>>>        }
>>>        printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>>>               cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
>>> +    if (ro_map) {
>>> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
>>> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
>>> +
>>> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf))<= end) {
>>> +            arch_pci_ro_device(cfg->pci_segment, bdf);
>>> +            if (bdf++ == end)
>>> +                break;
>>> +        }
>>> +    }
>>>        return 0;
>>>    }
>>>
>>> --- a/xen/drivers/passthrough/amd/iommu_detect.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
>>> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>>>        if ( rt )
>>>            return -ENODEV;
>>>
>>> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
>>> +    if ( rt )
>>> +        printk(XENLOG_ERR
>>> +               "Could not mark config space of %04x:%02x:%02x.%u read-only
>> (%d)\n",
>>> +               iommu->seg, bus, dev, func, rt);
>>> +
>>>        list_add_tail(&iommu->list,&amd_iommu_head);
>>>
>>>        return 0;
>>> --- a/xen/drivers/passthrough/io.c
>>> +++ b/xen/drivers/passthrough/io.c
>>> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>>>    unlock:
>>>        spin_unlock(&d->event_lock);
>>>    }
>>> -
>>> -static int __init setup_mmio_ro_ranges(void)
>>> -{
>>> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>> -                                  RANGESETF_prettyprint_hex);
>>> -    return 0;
>>> -}
>>> -__initcall(setup_mmio_ro_ranges);
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -36,6 +36,7 @@
>>>    struct pci_seg {
>>>        struct list_head alldevs_list;
>>>        u16 nr;
>>> +    unsigned long *ro_map;
>>>        /* bus2bridge_lock protects bus2bridge array */
>>>        spinlock_t bus2bridge_lock;
>>>    #define MAX_BUSES 256
>>> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>>>        radix_tree_init(&pci_segments);
>>>        if ( !alloc_pseg(0) )
>>>            panic("Could not initialize PCI segment 0\n");
>>> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>> +                                  RANGESETF_prettyprint_hex);
>>>    }
>>>
>>>    int __init pci_add_segment(u16 seg)
>>> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>>>        return alloc_pseg(seg) ? 0 : -ENOMEM;
>>>    }
>>>
>>> +const unsigned long *pci_get_ro_map(u16 seg)
>>> +{
>>> +    struct pci_seg *pseg = get_pseg(seg);
>>> +
>>> +    return pseg ? pseg->ro_map : NULL;
>>> +}
>>> +
>>>    static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>>>    {
>>>        struct pci_dev *pdev;
>>> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>>>        xfree(pdev);
>>>    }
>>>
>>> +int __init pci_ro_device(int seg, int bus, int devfn)
>>> +{
>>> +    struct pci_seg *pseg = alloc_pseg(seg);
>>> +    struct pci_dev *pdev;
>>> +
>>> +    if ( !pseg )
>>> +        return -ENOMEM;
>>> +    pdev = alloc_pdev(pseg, bus, devfn);
>>> +    if ( !pdev )
>>> +        return -ENOMEM;
>>> +
>>> +    if ( !pseg->ro_map )
>>> +    {
>>> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
>>> +
>>> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
>>> +        if ( !pseg->ro_map )
>>> +            return -ENOMEM;
>>> +        memset(pseg->ro_map, 0, sz);
>>> +    }
>>> +
>>> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
>>> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>    struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>>>    {
>>>        struct pci_seg *pseg = get_pseg(seg);
>>> --- a/xen/include/asm-x86/mm.h
>>> +++ b/xen/include/asm-x86/mm.h
>>> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>>>
>>>    int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>>>                            struct cpu_user_regs *);
>>> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
>>> +                           struct cpu_user_regs *);
>>>
>>>    int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>>>
>>> --- a/xen/include/xen/pci.h
>>> +++ b/xen/include/xen/pci.h
>>> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>>>    void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>>>    void pci_release_devices(struct domain *d);
>>>    int pci_add_segment(u16 seg);
>>> +const unsigned long *pci_get_ro_map(u16 seg);
>>>    int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info
>> *);
>>>    int pci_remove_device(u16 seg, u8 bus, u8 devfn);
>>> +int pci_ro_device(int seg, int bus, int devfn);
>>> +void arch_pci_ro_device(int seg, int bdf);
>>>    struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>>>    struct pci_dev *pci_get_pdev_by_domain(
>>>        struct domain *, int seg, int bus, int devfn);
>>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:05:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Shzo5-0000Kt-Fl; Fri, 22 Jun 2012 09:05:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Shzo4-0000Kn-1V
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:05:32 +0000
Received: from [193.109.254.147:30900] by server-2.bemta-14.messagelabs.com id
	39/7B-01735-B5534EF4; Fri, 22 Jun 2012 09:05:31 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340355928!3989785!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4648 invoked from network); 22 Jun 2012 09:05:29 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Jun 2012 09:05:29 -0000
Received: from mail38-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Fri, 22 Jun 2012 09:03:58 +0000
Received: from mail38-ch1 (localhost [127.0.0.1])	by mail38-ch1-R.bigfish.com
	(Postfix) with ESMTP id 9B0963C04E2;
	Fri, 22 Jun 2012 09:03:58 +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: 0
X-BigFish: VPS0(zzbb2dI98dI9371I1432I8b9clzz1202hzz8275bhz2dh668h839hd25he5bhf0ah)
Received: from mail38-ch1 (localhost.localdomain [127.0.0.1]) by mail38-ch1
	(MessageSwitch) id 1340355836531234_15796;
	Fri, 22 Jun 2012 09:03:56 +0000 (UTC)
Received: from CH1EHSMHS023.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.236])	by mail38-ch1.bigfish.com (Postfix) with ESMTP id
	7F813360132;	Fri, 22 Jun 2012 09:03:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 22 Jun 2012 09:03:55 +0000
X-WSS-ID: 0M60H8Y-02-0B7-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 21C19C8015;	Fri, 22 Jun 2012 04:05:21 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 22 Jun 2012 04:05:41 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 22 Jun 2012 04:05:20 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 22 Jun 2012
	05:05:12 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E02E249C20C; Fri, 22 Jun 2012
	10:05:11 +0100 (BST)
Message-ID: <4FE434D8.5030106@amd.com>
Date: Fri, 22 Jun 2012 11:03:20 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FD72FE4.80009@amd.com>
	<4FD778C802000078000897EF@nat28.tlf.novell.com>
	<4FD76976.2020203@citrix.com>
	<4FD78DE6020000780008986D@nat28.tlf.novell.com>
	<4FD9D559.9050206@amd.com>
	<4FE20C49020000780008AE25@nat28.tlf.novell.com>
	<4FE33DBC.4030104@amd.com>
	<4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
In-Reply-To: <4FE35EC7020000780008B2AD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0
 disabled 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 06/21/2012 05:49 PM, Jan Beulich wrote:
>>>> On 21.06.12 at 17:29, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 06/20/2012 05:45 PM, Jan Beulich wrote:
>>    >  Rather than submitting it for inclusion immediately, I'd rather see
>>> you first use it successfully. Below/attached what appears to
>>> work fine for me in contrived situations (i.e. hiding bridges with
>>> nothing connected, as I still don't have any AMD IOMMU system
>>> at hand).
>>
>> The patch works for me. IOMMU msi Capability is shown as enabled with
>> this patch.
>
> Keir,
>
> the question now arises whether we really want this, and
> particularly this late before 4.2. The Linux folks don't seem to
> be willing to take the strait forward workaround for the
> problem introduced at their end, so we will likely need
> something (the more that the questionable fix already made
> it into various stable trees) before 4.2 goes out (and even
> the older trees would be affected, just that putting a change
> like this there is even more questionable).
>
> There are obviously more potential problems in this area: If
> any of the MMIO addresses used by AMD's IOMMU is
> configurable through one of the BARs, and if Dom0 decides to
> re-assign MMIO space, neither allowing the writes nor simply
> dropping them as done here will work. Whether that's a real
> problem I don't know - Wei? And there might be other issues
> arising from dropping all writes - we might just currently not be
> aware of them.

AMD IOMMU does not have any PCI BARs, All address configuration should 
go to ACPI tables. So this should be fine at least for AMD IOMMU.

Thanks
Wei

> Jan
>
>> 00:00.2 Generic system peripheral [0806]: Advanced Micro Devices [AMD]
>> Device 1419
>>           Subsystem: Advanced Micro Devices [AMD] Device 1419
>>           Flags: bus master, fast devsel, latency 0, IRQ 11
>>           Capabilities: [40] Secure device<?>
>>           Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>
>>
>>> Jan
>>>
>>> Note that due to ptwr_do_page_fault() being run first, there'll be a
>>> MEM_LOG() issued for each such attempt. If that's undesirable, the
>>> order of the calls would need to be swapped.
>>>
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -1875,6 +1875,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
>>>                break;
>>>            case 1:
>>>                l1e_remove_flags(nl1e, _PAGE_RW);
>>> +            rc = 0;
>>>                break;
>>>            }
>>>            if ( page )
>>> @@ -5208,6 +5209,97 @@ int ptwr_do_page_fault(struct vcpu *v, u
>>>        return 0;
>>>    }
>>>
>>> +#ifdef __x86_64__
>>> +/*************************
>>> + * fault handling for read-only MMIO pages
>>> + */
>>> +
>>> +struct mmio_ro_emulate_ctxt {
>>> +    struct x86_emulate_ctxt ctxt;
>>> +    unsigned long cr2;
>>> +};
>>> +
>>> +static int mmio_ro_emulated_read(
>>> +    enum x86_segment seg,
>>> +    unsigned long offset,
>>> +    void *p_data,
>>> +    unsigned int bytes,
>>> +    struct x86_emulate_ctxt *ctxt)
>>> +{
>>> +    return X86EMUL_UNHANDLEABLE;
>>> +}
>>> +
>>> +static int mmio_ro_emulated_write(
>>> +    enum x86_segment seg,
>>> +    unsigned long offset,
>>> +    void *p_data,
>>> +    unsigned int bytes,
>>> +    struct x86_emulate_ctxt *ctxt)
>>> +{
>>> +    struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
>>> +        container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
>>> +
>>> +    /* Only allow naturally-aligned stores at the original %cr2 address. */
>>> +    if ( ((bytes | offset)&   (bytes - 1)) || offset != mmio_ro_ctxt->cr2 )
>>> +    {
>>> +        MEM_LOG("mmio_ro_emulate: bad access (cr2=%lx, addr=%lx,
>> bytes=%u)",
>>> +                mmio_ro_ctxt->cr2, offset, bytes);
>>> +        return X86EMUL_UNHANDLEABLE;
>>> +    }
>>> +
>>> +    return X86EMUL_OKAY;
>>> +}
>>> +
>>> +static const struct x86_emulate_ops mmio_ro_emulate_ops = {
>>> +    .read       = mmio_ro_emulated_read,
>>> +    .insn_fetch = ptwr_emulated_read,
>>> +    .write      = mmio_ro_emulated_write,
>>> +};
>>> +
>>> +/* Check if guest is trying to modify a r/o MMIO page. */
>>> +int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
>>> +                          struct cpu_user_regs *regs)
>>> +{
>>> +    l1_pgentry_t      pte;
>>> +    unsigned long     mfn;
>>> +    unsigned int      addr_size = is_pv_32on64_domain(v->domain) ?
>>> +                                  32 : BITS_PER_LONG;
>>> +    struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
>>> +        .ctxt.regs = regs,
>>> +        .ctxt.addr_size = addr_size,
>>> +        .ctxt.sp_size = addr_size,
>>> +        .cr2 = addr
>>> +    };
>>> +    int rc;
>>> +
>>> +    /* Attempt to read the PTE that maps the VA being accessed. */
>>> +    guest_get_eff_l1e(v, addr,&pte);
>>> +
>>> +    /* We are looking only for read-only mappings of MMIO pages. */
>>> +    if ( ((l1e_get_flags(pte)&   (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT)
>> )
>>> +        return 0;
>>> +
>>> +    mfn = l1e_get_pfn(pte);
>>> +    if ( mfn_valid(mfn) )
>>> +    {
>>> +        struct page_info *page = mfn_to_page(mfn);
>>> +        struct domain *owner = page_get_owner_and_reference(page);
>>> +
>>> +        if ( owner )
>>> +            put_page(page);
>>> +        if ( owner != dom_io )
>>> +            return 0;
>>> +    }
>>> +
>>> +    if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>> +        return 0;
>>> +
>>> +    rc = x86_emulate(&mmio_ro_ctxt.ctxt,&mmio_ro_emulate_ops);
>>> +
>>> +    return rc != X86EMUL_UNHANDLEABLE ? EXCRET_fault_fixed : 0;
>>> +}
>>> +#endif /* __x86_64__ */
>>> +
>>>    void free_xen_pagetable(void *v)
>>>    {
>>>        if ( system_state == SYS_STATE_early_boot )
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1349,20 +1349,23 @@ static int fixup_page_fault(unsigned lon
>>>            return 0;
>>>        }
>>>
>>> -    if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>>> -         guest_kernel_mode(v, regs) )
>>> -    {
>>> -        unsigned int mbs = PFEC_write_access;
>>> -        unsigned int mbz = PFEC_reserved_bit | PFEC_insn_fetch;
>>> -
>>> -        /* Do not check if access-protection fault since the page may
>>> -           legitimately be not present in shadow page tables */
>>> -        if ( !paging_mode_enabled(d) )
>>> -            mbs |= PFEC_page_present;
>>> -
>>> -        if ( ((regs->error_code&   (mbs | mbz)) == mbs)&&
>>> +    if ( guest_kernel_mode(v, regs)&&
>>> +         !(regs->error_code&   (PFEC_reserved_bit | PFEC_insn_fetch))&&
>>> +         (regs->error_code&   PFEC_write_access) )
>>> +    {
>>> +        if ( VM_ASSIST(d, VMASST_TYPE_writable_pagetables)&&
>>> +             /* Do not check if access-protection fault since the page may
>>> +                legitimately be not present in shadow page tables */
>>> +             (paging_mode_enabled(d) ||
>>> +              (regs->error_code&   PFEC_page_present))&&
>>>                 ptwr_do_page_fault(v, addr, regs) )
>>>                return EXCRET_fault_fixed;
>>> +
>>> +#ifdef __x86_64__
>>> +        if ( IS_PRIV(d)&&   (regs->error_code&   PFEC_page_present)&&
>>> +             mmio_ro_do_page_fault(v, addr, regs) )
>>> +            return EXCRET_fault_fixed;
>>> +#endif
>>>        }
>>>
>>>        /* For non-external shadowed guests, we fix up both their own
>>> @@ -1690,6 +1693,13 @@ static int pci_cfg_ok(struct domain *d,
>>>            return 0;
>>>
>>>        machine_bdf = (d->arch.pci_cf8>>   8)&   0xFFFF;
>>> +    if ( write )
>>> +    {
>>> +        const unsigned long *ro_map = pci_get_ro_map(0);
>>> +
>>> +        if ( ro_map&&   test_bit(machine_bdf, ro_map) )
>>> +            return 0;
>>> +    }
>>>        start = d->arch.pci_cf8&   0xFF;
>>>        end = start + size - 1;
>>>        if (xsm_pci_config_permission(d, machine_bdf, start, end, write))
>>> --- a/xen/arch/x86/x86_32/pci.c
>>> +++ b/xen/arch/x86/x86_32/pci.c
>>> @@ -6,6 +6,7 @@
>>>
>>>    #include<xen/spinlock.h>
>>>    #include<xen/pci.h>
>>> +#include<xen/init.h>
>>>    #include<asm/io.h>
>>>
>>>    #define PCI_CONF_ADDRESS(bus, dev, func, reg) \
>>> @@ -70,3 +71,7 @@ void pci_conf_write32(
>>>        BUG_ON((bus>   255) || (dev>   31) || (func>   7) || (reg>   255));
>>>        pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>>>    }
>>> +
>>> +void __init arch_pci_ro_device(int seg, int bdf)
>>> +{
>>> +}
>>> --- a/xen/arch/x86/x86_64/mmconfig_64.c
>>> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
>>> @@ -145,9 +145,30 @@ static void __iomem *mcfg_ioremap(const
>>>        return (void __iomem *) virt;
>>>    }
>>>
>>> +void arch_pci_ro_device(int seg, int bdf)
>>> +{
>>> +    unsigned int idx, bus = PCI_BUS(bdf);
>>> +
>>> +    for (idx = 0; idx<   pci_mmcfg_config_num; ++idx) {
>>> +        const struct acpi_mcfg_allocation *cfg = pci_mmcfg_virt[idx].cfg;
>>> +        unsigned long mfn = (cfg->address>>   PAGE_SHIFT) + bdf;
>>> +
>>> +        if (!pci_mmcfg_virt[idx].virt || cfg->pci_segment != seg ||
>>> +            cfg->start_bus_number>   bus || cfg->end_bus_number<   bus)
>>> +            continue;
>>> +
>>> +        if (rangeset_add_singleton(mmio_ro_ranges, mfn))
>>> +            printk(XENLOG_ERR
>>> +                   "%04x:%02x:%02x.%u: could not mark MCFG (mfn %#lx)
>> read-only\n",
>>> +                   cfg->pci_segment, bus, PCI_SLOT(bdf), PCI_FUNC(bdf),
>>> +                   mfn);
>>> +    }
>>> +}
>>> +
>>>    int pci_mmcfg_arch_enable(unsigned int idx)
>>>    {
>>>        const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
>>> +    const unsigned long *ro_map = pci_get_ro_map(cfg->pci_segment);
>>>
>>>        if (pci_mmcfg_virt[idx].virt)
>>>            return 0;
>>> @@ -159,6 +180,16 @@ int pci_mmcfg_arch_enable(unsigned int i
>>>        }
>>>        printk(KERN_INFO "PCI: Using MCFG for segment %04x bus %02x-%02x\n",
>>>               cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number);
>>> +    if (ro_map) {
>>> +        unsigned int bdf = PCI_BDF(cfg->start_bus_number, 0, 0);
>>> +        unsigned int end = PCI_BDF(cfg->end_bus_number, -1, -1);
>>> +
>>> +        while ((bdf = find_next_bit(ro_map, end + 1, bdf))<= end) {
>>> +            arch_pci_ro_device(cfg->pci_segment, bdf);
>>> +            if (bdf++ == end)
>>> +                break;
>>> +        }
>>> +    }
>>>        return 0;
>>>    }
>>>
>>> --- a/xen/drivers/passthrough/amd/iommu_detect.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
>>> @@ -153,6 +153,12 @@ int __init amd_iommu_detect_one_acpi(
>>>        if ( rt )
>>>            return -ENODEV;
>>>
>>> +    rt = pci_ro_device(iommu->seg, bus, PCI_DEVFN(dev, func));
>>> +    if ( rt )
>>> +        printk(XENLOG_ERR
>>> +               "Could not mark config space of %04x:%02x:%02x.%u read-only
>> (%d)\n",
>>> +               iommu->seg, bus, dev, func, rt);
>>> +
>>>        list_add_tail(&iommu->list,&amd_iommu_head);
>>>
>>>        return 0;
>>> --- a/xen/drivers/passthrough/io.c
>>> +++ b/xen/drivers/passthrough/io.c
>>> @@ -593,11 +593,3 @@ void hvm_dpci_eoi(struct domain *d, unsi
>>>    unlock:
>>>        spin_unlock(&d->event_lock);
>>>    }
>>> -
>>> -static int __init setup_mmio_ro_ranges(void)
>>> -{
>>> -    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>> -                                  RANGESETF_prettyprint_hex);
>>> -    return 0;
>>> -}
>>> -__initcall(setup_mmio_ro_ranges);
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -36,6 +36,7 @@
>>>    struct pci_seg {
>>>        struct list_head alldevs_list;
>>>        u16 nr;
>>> +    unsigned long *ro_map;
>>>        /* bus2bridge_lock protects bus2bridge array */
>>>        spinlock_t bus2bridge_lock;
>>>    #define MAX_BUSES 256
>>> @@ -106,6 +107,8 @@ void __init pt_pci_init(void)
>>>        radix_tree_init(&pci_segments);
>>>        if ( !alloc_pseg(0) )
>>>            panic("Could not initialize PCI segment 0\n");
>>> +    mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>> +                                  RANGESETF_prettyprint_hex);
>>>    }
>>>
>>>    int __init pci_add_segment(u16 seg)
>>> @@ -113,6 +116,13 @@ int __init pci_add_segment(u16 seg)
>>>        return alloc_pseg(seg) ? 0 : -ENOMEM;
>>>    }
>>>
>>> +const unsigned long *pci_get_ro_map(u16 seg)
>>> +{
>>> +    struct pci_seg *pseg = get_pseg(seg);
>>> +
>>> +    return pseg ? pseg->ro_map : NULL;
>>> +}
>>> +
>>>    static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
>>>    {
>>>        struct pci_dev *pdev;
>>> @@ -198,6 +208,33 @@ static void free_pdev(struct pci_seg *ps
>>>        xfree(pdev);
>>>    }
>>>
>>> +int __init pci_ro_device(int seg, int bus, int devfn)
>>> +{
>>> +    struct pci_seg *pseg = alloc_pseg(seg);
>>> +    struct pci_dev *pdev;
>>> +
>>> +    if ( !pseg )
>>> +        return -ENOMEM;
>>> +    pdev = alloc_pdev(pseg, bus, devfn);
>>> +    if ( !pdev )
>>> +        return -ENOMEM;
>>> +
>>> +    if ( !pseg->ro_map )
>>> +    {
>>> +        size_t sz = BITS_TO_LONGS(PCI_BDF(-1, -1, -1) + 1) * sizeof(long);
>>> +
>>> +        pseg->ro_map = alloc_xenheap_pages(get_order_from_bytes(sz), 0);
>>> +        if ( !pseg->ro_map )
>>> +            return -ENOMEM;
>>> +        memset(pseg->ro_map, 0, sz);
>>> +    }
>>> +
>>> +    __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
>>> +    arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>    struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
>>>    {
>>>        struct pci_seg *pseg = get_pseg(seg);
>>> --- a/xen/include/asm-x86/mm.h
>>> +++ b/xen/include/asm-x86/mm.h
>>> @@ -555,6 +555,8 @@ void memguard_unguard_stack(void *p);
>>>
>>>    int  ptwr_do_page_fault(struct vcpu *, unsigned long,
>>>                            struct cpu_user_regs *);
>>> +int  mmio_ro_do_page_fault(struct vcpu *, unsigned long,
>>> +                           struct cpu_user_regs *);
>>>
>>>    int audit_adjust_pgtables(struct domain *d, int dir, int noisy);
>>>
>>> --- a/xen/include/xen/pci.h
>>> +++ b/xen/include/xen/pci.h
>>> @@ -98,8 +98,11 @@ struct pci_dev *pci_lock_domain_pdev(
>>>    void setup_dom0_pci_devices(struct domain *, void (*)(struct pci_dev *));
>>>    void pci_release_devices(struct domain *d);
>>>    int pci_add_segment(u16 seg);
>>> +const unsigned long *pci_get_ro_map(u16 seg);
>>>    int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info
>> *);
>>>    int pci_remove_device(u16 seg, u8 bus, u8 devfn);
>>> +int pci_ro_device(int seg, int bus, int devfn);
>>> +void arch_pci_ro_device(int seg, int bdf);
>>>    struct pci_dev *pci_get_pdev(int seg, int bus, int devfn);
>>>    struct pci_dev *pci_get_pdev_by_domain(
>>>        struct domain *, int seg, int bus, int devfn);
>>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:19:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si00r-0000ep-TH; Fri, 22 Jun 2012 09:18: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 1Si00q-0000ek-BL
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:18:44 +0000
Received: from [193.109.254.147:44132] by server-9.bemta-14.messagelabs.com id
	83/D8-07693-37834EF4; Fri, 22 Jun 2012 09:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340356722!11036127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30836 invoked from network); 22 Jun 2012 09:18:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13164499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 09:18:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 10:18:42 +0100
Message-ID: <1340356720.26083.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 10:18:40 +0100
In-Reply-To: <osstest-13302-mainreport@xen.org>
References: <osstest-13302-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13302: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 04:00 +0100, xen.org wrote:
> flight 13302 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13302/
> 
> 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. 13025
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
>  build-i386                    4 xen-build                 fail REGR. vs. 13025

These all appear to be timeouts -- some sort of infrastructure problem?


>  test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
>  test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
>  test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
>  test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025

These are also timeouts but of the guest initial boot/install. Could be
related to the infrastructure issues?

I only looked closely at one case (test-amd64-amd64-xl-qemuu-win7-amd64)
since they all looked pretty similar.

The domain wasn't running when the logs were collect (xl list etc) and
the qemu log contains:
        Issued domain 1 reboot
        qemu: terminating on signal 1 from pid 3171

so it seems like the installer rebooted the vm but it's not clear if
that was after a successful or failed install. The xl log is:
        Waiting for domain win.guest.osstest (domid 1) to die [pid 3171]
        Domain 1 has shut down, reason code 1 0x1
        Action for shutdown reason code 1 is restart
        Domain 1 needs to be cleaned up: destroying the domain
Which makes me wonder if perhaps HVM virtualised reboot is knackered?
This seems plausible given that all the failures were xl related (xend
seems ok). I'll investigate this morning.

We should hold off on libxl/xl and perhaps HVM related commits until we
figure this one out.

> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  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-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-pv            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
> 
> version targeted for testing:
>  xen                  513d5e196e23
> baseline version:
>  xen                  32034d1914a6
> 
> jobs:
>  build-amd64                                                  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-i386-i386-xl                                            blocked 
>  test-amd64-i386-rhel6hvm-amd                                 blocked 
>  test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                blocked 
>  test-amd64-i386-xl-credit2                                   blocked 
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               blocked 
>  test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
>  test-amd64-i386-xl-multivcpu                                 blocked 
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         blocked 
>  test-i386-i386-pair                                          blocked 
>  test-amd64-amd64-xl-sedf-pin                                 pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           blocked 
>  test-i386-i386-pv                                            blocked 
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   blocked 
>  test-amd64-i386-xl-win-vcpus1                                blocked 
>  test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          blocked 
>  test-i386-i386-win                                           blocked 
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        blocked 
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-i386-i386-xl-qemuu-winxpsp3                             blocked 
>  test-amd64-i386-xend-winxpsp3                                blocked 
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   blocked 
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:19:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si00r-0000ep-TH; Fri, 22 Jun 2012 09:18: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 1Si00q-0000ek-BL
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:18:44 +0000
Received: from [193.109.254.147:44132] by server-9.bemta-14.messagelabs.com id
	83/D8-07693-37834EF4; Fri, 22 Jun 2012 09:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340356722!11036127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIwMjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30836 invoked from network); 22 Jun 2012 09:18:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13164499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 09:18:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 10:18:42 +0100
Message-ID: <1340356720.26083.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 10:18:40 +0100
In-Reply-To: <osstest-13302-mainreport@xen.org>
References: <osstest-13302-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13302: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 04:00 +0100, xen.org wrote:
> flight 13302 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13302/
> 
> 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. 13025
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 13025
>  build-i386                    4 xen-build                 fail REGR. vs. 13025

These all appear to be timeouts -- some sort of infrastructure problem?


>  test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
>  test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
>  test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
>  test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025

These are also timeouts but of the guest initial boot/install. Could be
related to the infrastructure issues?

I only looked closely at one case (test-amd64-amd64-xl-qemuu-win7-amd64)
since they all looked pretty similar.

The domain wasn't running when the logs were collect (xl list etc) and
the qemu log contains:
        Issued domain 1 reboot
        qemu: terminating on signal 1 from pid 3171

so it seems like the installer rebooted the vm but it's not clear if
that was after a successful or failed install. The xl log is:
        Waiting for domain win.guest.osstest (domid 1) to die [pid 3171]
        Domain 1 has shut down, reason code 1 0x1
        Action for shutdown reason code 1 is restart
        Domain 1 needs to be cleaned up: destroying the domain
Which makes me wonder if perhaps HVM virtualised reboot is knackered?
This seems plausible given that all the failures were xl related (xend
seems ok). I'll investigate this morning.

We should hold off on libxl/xl and perhaps HVM related commits until we
figure this one out.

> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  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-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-pv            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
> 
> version targeted for testing:
>  xen                  513d5e196e23
> baseline version:
>  xen                  32034d1914a6
> 
> jobs:
>  build-amd64                                                  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-i386-i386-xl                                            blocked 
>  test-amd64-i386-rhel6hvm-amd                                 blocked 
>  test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                blocked 
>  test-amd64-i386-xl-credit2                                   blocked 
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               blocked 
>  test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
>  test-amd64-i386-xl-multivcpu                                 blocked 
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         blocked 
>  test-i386-i386-pair                                          blocked 
>  test-amd64-amd64-xl-sedf-pin                                 pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           blocked 
>  test-i386-i386-pv                                            blocked 
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   blocked 
>  test-amd64-i386-xl-win-vcpus1                                blocked 
>  test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          blocked 
>  test-i386-i386-win                                           blocked 
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        blocked 
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-i386-i386-xl-qemuu-winxpsp3                             blocked 
>  test-amd64-i386-xend-winxpsp3                                blocked 
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   blocked 
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:25:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Si06g-000135-GS; Fri, 22 Jun 2012 09:24:46 +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 1Si06f-00012x-Aw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:24:45 +0000
Received: from [85.158.143.99:61115] by server-1.bemta-4.messagelabs.com id
	CB/32-24392-CD934EF4; Fri, 22 Jun 2012 09:24:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340357083!23314615!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11151 invoked from network); 22 Jun 2012 09:24:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Jun 2012 09:24:43 -0000
Received: from 225-68-ftth.onsneteindhoven.nl ([88.159.68.225]:51612
	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 1Si02c-0002sQ-SP; Fri, 22 Jun 2012 11:20:34 +0200
Date: Fri, 22 Jun 2012 11:24:36 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1783278186.20120622112436@eikelenboom.it>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <4FE43518.9070106@citrix.com>
References: <4FE43518.9070106@citrix.com>
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	Keir Fraser <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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

Friday, June 22, 2012, 11:04:24 AM, you wrote:

> Following Jan's infrastructure to mark certain PCI devices as read only,
> I think it wise to now consider what other PCI devices should really be
> read only to dom0.

> My preliminary thoughts include:

> * PCI serial devices which Xen is configured to use
> * Chipset devices (AMD IOMMU covered by previous patch)
> * Cpu information

> Are there any others I have overlooked, or reasons that dom0 should be
> able to write to these areas?

Make devices specified for pci passthrough be really hidden and "owned" by the hyperviso ?
     - which can in turn delegate ownership to a domain (including dom0)
     - If a domain is destroyed, the hypervisor resets the device and becomes the owner again instead of dom0 ?


> On a related note, should there be a mechanism for dom0 to determine
> which PCI configuration areas are read only to itself?




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:25:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Si06g-000135-GS; Fri, 22 Jun 2012 09:24:46 +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 1Si06f-00012x-Aw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:24:45 +0000
Received: from [85.158.143.99:61115] by server-1.bemta-4.messagelabs.com id
	CB/32-24392-CD934EF4; Fri, 22 Jun 2012 09:24:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340357083!23314615!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11151 invoked from network); 22 Jun 2012 09:24:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Jun 2012 09:24:43 -0000
Received: from 225-68-ftth.onsneteindhoven.nl ([88.159.68.225]:51612
	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 1Si02c-0002sQ-SP; Fri, 22 Jun 2012 11:20:34 +0200
Date: Fri, 22 Jun 2012 11:24:36 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1783278186.20120622112436@eikelenboom.it>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <4FE43518.9070106@citrix.com>
References: <4FE43518.9070106@citrix.com>
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	Keir Fraser <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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

Friday, June 22, 2012, 11:04:24 AM, you wrote:

> Following Jan's infrastructure to mark certain PCI devices as read only,
> I think it wise to now consider what other PCI devices should really be
> read only to dom0.

> My preliminary thoughts include:

> * PCI serial devices which Xen is configured to use
> * Chipset devices (AMD IOMMU covered by previous patch)
> * Cpu information

> Are there any others I have overlooked, or reasons that dom0 should be
> able to write to these areas?

Make devices specified for pci passthrough be really hidden and "owned" by the hyperviso ?
     - which can in turn delegate ownership to a domain (including dom0)
     - If a domain is destroyed, the hypervisor resets the device and becomes the owner again instead of dom0 ?


> On a related note, should there be a mechanism for dom0 to determine
> which PCI configuration areas are read only to itself?




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si0KA-0001QP-Fq; Fri, 22 Jun 2012 09:38:42 +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 1Si0K9-0001QJ-B8
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:38:41 +0000
Received: from [85.158.139.83:32673] by server-4.bemta-5.messagelabs.com id
	43/10-27831-02D34EF4; Fri, 22 Jun 2012 09:38:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340357918!28875216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11783 invoked from network); 22 Jun 2012 09:38:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199680062"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 05:38:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 05:38:37 -0400
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 1Si0K4-0006D0-WD;
	Fri, 22 Jun 2012 10:38:37 +0100
Message-ID: <4FE43D1C.8020600@citrix.com>
Date: Fri, 22 Jun 2012 10:38:36 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------060700000001020004030603"
Subject: [Xen-devel] Update xen-devel email address in the MAINTAINERS 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060700000001020004030603
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

I was looking through the maintainers file and noticed that the
xen-devel email address is out of date in certain places.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060700000001020004030603
Content-Type: text/x-patch; name="update-xen-devel-email.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="update-xen-devel-email.patch"

# HG changeset patch
# Parent 32034d1914a607d7b6f1f060352b4cac973600f8
MAINTAINTERS: update xen-devel email address

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 32034d1914a6 MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -102,7 +102,7 @@ M:	Ian Campbell <ian.campbell@citrix.com
 M:	Stefano Stabellini <stefano.stabellini@citrix.com>
 M:	Tim Deegan <tim@xen.org>
 S:	Supported
-L:	xen-devel@lists.xensource.com
+L:	xen-devel@lists.xen.org
 F:	xen/arch/arm/
 F:	xen/include/asm-arm/
 
@@ -246,7 +246,7 @@ X86 ARCHITECTURE
 M:	Keir Fraser <keir@xen.org>
 M:	Jan Beulich <jbeulich@suse.com>
 S:	Supported
-L:	xen-devel@lists.xensource.com
+L:	xen-devel@lists.xen.org
 F:	xen/arch/x86/
 F:	xen/include/asm-x86/
 
@@ -263,7 +263,7 @@ F:	xen/common/trace.c
 
 THE REST
 M:	Keir Fraser <keir@xen.org>
-L:	xen-devel@lists.xensource.com
+L:	xen-devel@lists.xen.org
 S:	Supported
 F:	*
 F:	*/

--------------060700000001020004030603
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060700000001020004030603--


From xen-devel-bounces@lists.xen.org Fri Jun 22 09:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si0KA-0001QP-Fq; Fri, 22 Jun 2012 09:38:42 +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 1Si0K9-0001QJ-B8
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:38:41 +0000
Received: from [85.158.139.83:32673] by server-4.bemta-5.messagelabs.com id
	43/10-27831-02D34EF4; Fri, 22 Jun 2012 09:38:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340357918!28875216!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11783 invoked from network); 22 Jun 2012 09:38:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199680062"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 05:38:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 05:38:37 -0400
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 1Si0K4-0006D0-WD;
	Fri, 22 Jun 2012 10:38:37 +0100
Message-ID: <4FE43D1C.8020600@citrix.com>
Date: Fri, 22 Jun 2012 10:38:36 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------060700000001020004030603"
Subject: [Xen-devel] Update xen-devel email address in the MAINTAINERS 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060700000001020004030603
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

I was looking through the maintainers file and noticed that the
xen-devel email address is out of date in certain places.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------060700000001020004030603
Content-Type: text/x-patch; name="update-xen-devel-email.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="update-xen-devel-email.patch"

# HG changeset patch
# Parent 32034d1914a607d7b6f1f060352b4cac973600f8
MAINTAINTERS: update xen-devel email address

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 32034d1914a6 MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -102,7 +102,7 @@ M:	Ian Campbell <ian.campbell@citrix.com
 M:	Stefano Stabellini <stefano.stabellini@citrix.com>
 M:	Tim Deegan <tim@xen.org>
 S:	Supported
-L:	xen-devel@lists.xensource.com
+L:	xen-devel@lists.xen.org
 F:	xen/arch/arm/
 F:	xen/include/asm-arm/
 
@@ -246,7 +246,7 @@ X86 ARCHITECTURE
 M:	Keir Fraser <keir@xen.org>
 M:	Jan Beulich <jbeulich@suse.com>
 S:	Supported
-L:	xen-devel@lists.xensource.com
+L:	xen-devel@lists.xen.org
 F:	xen/arch/x86/
 F:	xen/include/asm-x86/
 
@@ -263,7 +263,7 @@ F:	xen/common/trace.c
 
 THE REST
 M:	Keir Fraser <keir@xen.org>
-L:	xen-devel@lists.xensource.com
+L:	xen-devel@lists.xen.org
 S:	Supported
 F:	*
 F:	*/

--------------060700000001020004030603
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060700000001020004030603--


From xen-devel-bounces@lists.xen.org Fri Jun 22 09:41:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Si0M9-0001av-0G; Fri, 22 Jun 2012 09:40: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 1Si0M6-0001ag-TE
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:40:43 +0000
Received: from [193.109.254.147:57470] by server-2.bemta-14.messagelabs.com id
	8E/AF-01735-A9D34EF4; Fri, 22 Jun 2012 09:40:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340358040!11126993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31475 invoked from network); 22 Jun 2012 09:40:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 09: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.213.0; Fri, 22 Jun 2012 10:40:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si0M3-0002j1-G9; Fri, 22 Jun 2012 09:40:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si0M3-0005J8-Dn;
	Fri, 22 Jun 2012 10:40:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.15767.414152.627734@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 10:40:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340356720.26083.75.camel@zakaz.uk.xensource.com>
References: <osstest-13302-mainreport@xen.org>
	<1340356720.26083.75.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-unstable test] 13302: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13302: regressions - FAIL"):
> On Fri, 2012-06-22 at 04:00 +0100, xen.org wrote:
> > flight 13302 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13302/
> > 
> > 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. 13025
...
> These all appear to be timeouts -- some sort of infrastructure problem?

I think so.  It seems that the build host became unresponsive via the
network.  But the serial console log shows it apparently happy.
Well, no messages, anyway.  Perhaps it crashed.  That host has been
wiped since.

...
> >  test-amd64-amd64-xl-win       7 windows-install       fail REGR. vs. 13025
...
> 
> These are also timeouts but of the guest initial boot/install. Could be
> related to the infrastructure issues?

I don't think so.  There is no sign of anything along those lines and
the dom0 and tester keep talking to each other just fine.  If the
switch was broken or something, it wouldn't have had a dhcp server but
I would have expected the domain to still exist.

What seems to have happened here is that the guest tried to reboot but
xl didn't start the new instance.  The xl log says:

  Waiting for domain win.guest.osstest (domid 1) to die [pid 2679]
  Domain 1 has shut down, reason code 1 0x1
  Action for shutdown reason code 1 is restart
  Domain 1 needs to be cleaned up: destroying the domain

And the dom0 kernel log says:

 Jun 21 23:59:45 moss-bug kernel: [  789.115260] xl[2679]: segfault at
 7f346c000000 ip 00007f346e817919 sp 00007fffb95adcf0 error 4 in
 libc-2.11.3.so[7f346e7a1000+159000]

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:41:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Si0M9-0001av-0G; Fri, 22 Jun 2012 09:40: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 1Si0M6-0001ag-TE
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:40:43 +0000
Received: from [193.109.254.147:57470] by server-2.bemta-14.messagelabs.com id
	8E/AF-01735-A9D34EF4; Fri, 22 Jun 2012 09:40:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340358040!11126993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31475 invoked from network); 22 Jun 2012 09:40:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 09: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.213.0; Fri, 22 Jun 2012 10:40:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si0M3-0002j1-G9; Fri, 22 Jun 2012 09:40:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si0M3-0005J8-Dn;
	Fri, 22 Jun 2012 10:40:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.15767.414152.627734@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 10:40:39 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340356720.26083.75.camel@zakaz.uk.xensource.com>
References: <osstest-13302-mainreport@xen.org>
	<1340356720.26083.75.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-unstable test] 13302: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13302: regressions - FAIL"):
> On Fri, 2012-06-22 at 04:00 +0100, xen.org wrote:
> > flight 13302 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13302/
> > 
> > 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. 13025
...
> These all appear to be timeouts -- some sort of infrastructure problem?

I think so.  It seems that the build host became unresponsive via the
network.  But the serial console log shows it apparently happy.
Well, no messages, anyway.  Perhaps it crashed.  That host has been
wiped since.

...
> >  test-amd64-amd64-xl-win       7 windows-install       fail REGR. vs. 13025
...
> 
> These are also timeouts but of the guest initial boot/install. Could be
> related to the infrastructure issues?

I don't think so.  There is no sign of anything along those lines and
the dom0 and tester keep talking to each other just fine.  If the
switch was broken or something, it wouldn't have had a dhcp server but
I would have expected the domain to still exist.

What seems to have happened here is that the guest tried to reboot but
xl didn't start the new instance.  The xl log says:

  Waiting for domain win.guest.osstest (domid 1) to die [pid 2679]
  Domain 1 has shut down, reason code 1 0x1
  Action for shutdown reason code 1 is restart
  Domain 1 needs to be cleaned up: destroying the domain

And the dom0 kernel log says:

 Jun 21 23:59:45 moss-bug kernel: [  789.115260] xl[2679]: segfault at
 7f346c000000 ip 00007f346e817919 sp 00007fffb95adcf0 error 4 in
 libc-2.11.3.so[7f346e7a1000+159000]

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Si0OD-0001mR-I0; Fri, 22 Jun 2012 09:42: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 1Si0OC-0001mA-Db
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:42:52 +0000
Received: from [85.158.139.83:32184] by server-9.bemta-5.messagelabs.com id
	33/D0-01069-91E34EF4; Fri, 22 Jun 2012 09:42:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340358168!23829347!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13884 invoked from network); 22 Jun 2012 09:42:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 09:42:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 10:42:47 +0100
Message-Id: <4FE45A64020000780008B570@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 10:43:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
In-Reply-To: <4FE43518.9070106@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	Keir Fraser <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Following Jan's infrastructure to mark certain PCI devices as read only,
> I think it wise to now consider what other PCI devices should really be
> read only to dom0.
> 
> My preliminary thoughts include:
> 
> * PCI serial devices which Xen is configured to use

But only if they're single-function.

> * Chipset devices (AMD IOMMU covered by previous patch)
> * Cpu information

What are you thinking of here specifically.

> Are there any others I have overlooked, or reasons that dom0 should be
> able to write to these areas?
> 
> On a related note, should there be a mechanism for dom0 to determine
> which PCI configuration areas are read only to itself?

Perhaps, but that's not the only thing to deal with here. As
said previously, when we want to add devices with active BARs
here (luckily Wei confirmed that AMD IOMMUs have none),
Dom0 trying to re-configure them would get us into problems.
The issue exists today, but could become worse when we
disallow the updates (as that could lead to two devices sharing
resources they shouldn't share, whereas today a device in use
by Xen and getting re-assigned its resources would merely stop
working).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09: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 1Si0OD-0001mR-I0; Fri, 22 Jun 2012 09:42: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 1Si0OC-0001mA-Db
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:42:52 +0000
Received: from [85.158.139.83:32184] by server-9.bemta-5.messagelabs.com id
	33/D0-01069-91E34EF4; Fri, 22 Jun 2012 09:42:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340358168!23829347!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13884 invoked from network); 22 Jun 2012 09:42:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 09:42:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 10:42:47 +0100
Message-Id: <4FE45A64020000780008B570@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 10:43:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
In-Reply-To: <4FE43518.9070106@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	Keir Fraser <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Following Jan's infrastructure to mark certain PCI devices as read only,
> I think it wise to now consider what other PCI devices should really be
> read only to dom0.
> 
> My preliminary thoughts include:
> 
> * PCI serial devices which Xen is configured to use

But only if they're single-function.

> * Chipset devices (AMD IOMMU covered by previous patch)
> * Cpu information

What are you thinking of here specifically.

> Are there any others I have overlooked, or reasons that dom0 should be
> able to write to these areas?
> 
> On a related note, should there be a mechanism for dom0 to determine
> which PCI configuration areas are read only to itself?

Perhaps, but that's not the only thing to deal with here. As
said previously, when we want to add devices with active BARs
here (luckily Wei confirmed that AMD IOMMUs have none),
Dom0 trying to re-configure them would get us into problems.
The issue exists today, but could become worse when we
disallow the updates (as that could lead to two devices sharing
resources they shouldn't share, whereas today a device in use
by Xen and getting re-assigned its resources would merely stop
working).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:48:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:48: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 1Si0TQ-00025S-Fi; Fri, 22 Jun 2012 09: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.Jackson@eu.citrix.com>) id 1Si0TO-00025I-RJ
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:48:15 +0000
Received: from [85.158.138.51:37623] by server-7.bemta-3.messagelabs.com id
	B7/D2-10113-95F34EF4; Fri, 22 Jun 2012 09:48:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340358489!24949203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17639 invoked from network); 22 Jun 2012 09:48:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:48:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 09:48:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 10:48:08 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si0TI-0002lc-R6	for xen-devel@lists.xensource.com;
	Fri, 22 Jun 2012 09:48:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si0TI-0005JT-Oq	for
	xen-devel@lists.xensource.com; Fri, 22 Jun 2012 10:48:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.16216.758064.435942@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 10:48:08 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13312-mainreport@xen.org>
References: <osstest-13312-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] 13312: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13312: regressions - FAIL"):
> flight 13312 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13312/
> 
> 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. 13090

This is the same host at the same time as the other
apparently-transient build failures.

>  test-amd64-i386-xl-credit2   3 host-install(3) broken in 13113 REGR. vs. 13090

In 13113 this seems to have failed in the partitioner in
debian-installer.  Sadly d-i isn't very good at producing logs.  It's
a mystery, because later installs on the same host worked.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:48:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:48: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 1Si0TQ-00025S-Fi; Fri, 22 Jun 2012 09: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.Jackson@eu.citrix.com>) id 1Si0TO-00025I-RJ
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 09:48:15 +0000
Received: from [85.158.138.51:37623] by server-7.bemta-3.messagelabs.com id
	B7/D2-10113-95F34EF4; Fri, 22 Jun 2012 09:48:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340358489!24949203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17639 invoked from network); 22 Jun 2012 09:48:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:48:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 09:48:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 10:48:08 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si0TI-0002lc-R6	for xen-devel@lists.xensource.com;
	Fri, 22 Jun 2012 09:48:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si0TI-0005JT-Oq	for
	xen-devel@lists.xensource.com; Fri, 22 Jun 2012 10:48:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.16216.758064.435942@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 10:48:08 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13312-mainreport@xen.org>
References: <osstest-13312-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] 13312: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13312: regressions - FAIL"):
> flight 13312 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13312/
> 
> 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. 13090

This is the same host at the same time as the other
apparently-transient build failures.

>  test-amd64-i386-xl-credit2   3 host-install(3) broken in 13113 REGR. vs. 13090

In 13113 this seems to have failed in the partitioner in
debian-installer.  Sadly d-i isn't very good at producing logs.  It's
a mystery, because later installs on the same host worked.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:52: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 1Si0Wt-0002Fh-3n; Fri, 22 Jun 2012 09:51:51 +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 1Si0Wr-0002Fa-Mr
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:51:49 +0000
Received: from [85.158.139.83:44834] by server-8.bemta-5.messagelabs.com id
	24/3E-10278-43044EF4; Fri, 22 Jun 2012 09:51:48 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340358707!28959012!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31991 invoked from network); 22 Jun 2012 09:51:48 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:51:48 -0000
Received: by qcsd16 with SMTP id d16so869065qcs.28
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 02:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XJKjQrDiON7aTJZcj5proYBjoTfMtNgchvnpadPkXIU=;
	b=EL7KFzVvBWAmztrKKx7Wp9mVUtP1LD5ywlPiSs4oHRThaU6QDOtpaCMm/Bw/KdJ7B9
	0XuVx89zznYi3zd9HkrIMHV0RQsNMff5Gc9GMVqyXpSAt/VtCAHhIbJHm6FKHULUrAyU
	bfFSvz9cq9ju+/Blt75/XVUbyKREYrdQlQCHrzdaOFyA84BlGrQp7kd3rjK8LgrzewFW
	n1El4b6WERN+B/eEcGDGcdd8AWiVAGjAokQ6p49sl6qwVE9S68KcAj8nJLtTlf634Lqd
	yKCAjmYk2zzt+dNY99OH6+0smfpjYMyrXM3nGpNPSNIB9DrctOIQ5ayILk5CAKM8cTTd
	YuLQ==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr5119452qae.26.1340358706854; Fri,
	22 Jun 2012 02:51:46 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 02:51:46 -0700 (PDT)
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
Date: Fri, 22 Jun 2012 10:51:46 +0100
X-Google-Sender-Auth: 56-WN_pje7ECvv_OBNYOt36eVms
Message-ID: <CAFLBxZbTZh+eOsHhoUyrXE1OscobJYJ5ZyWq8u8Kq-MQSy8PpQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Tapdiya, Ashish" <ashish.tapdiya@vanderbilt.edu>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 10:10 PM, Tapdiya, Ashish
<ashish.tapdiya@vanderbilt.edu> wrote:
> Hi,
>
> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0. However, if I supply sched=credit (default) or sched=credit2, specified scheduler gets selected and dom0 boots perfectly fine. Not sure if it is a bug.

arinc653 is a custom scheduler written by a single company for a
specific purpose (something to do with a hard real-time scheduling
problem they had).  None of the regular xen.org developers use it or
know anything about it, including exactly what it's for, what kind of
hardware it's expected to run on, or what kind of parameters are
required for it to boot.  It may even be the case that the company
that wrote it also has a custom OS that runs as a dom0.  So unless you
know what you need it for, it's probably best to leave that one alone.
:-)

sedf should work; a proper bug report (including serial console output
and a hardware description) will make fixing that bug a lot quicker.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 09:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 09:52: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 1Si0Wt-0002Fh-3n; Fri, 22 Jun 2012 09:51:51 +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 1Si0Wr-0002Fa-Mr
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 09:51:49 +0000
Received: from [85.158.139.83:44834] by server-8.bemta-5.messagelabs.com id
	24/3E-10278-43044EF4; Fri, 22 Jun 2012 09:51:48 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340358707!28959012!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31991 invoked from network); 22 Jun 2012 09:51:48 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 09:51:48 -0000
Received: by qcsd16 with SMTP id d16so869065qcs.28
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 02:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XJKjQrDiON7aTJZcj5proYBjoTfMtNgchvnpadPkXIU=;
	b=EL7KFzVvBWAmztrKKx7Wp9mVUtP1LD5ywlPiSs4oHRThaU6QDOtpaCMm/Bw/KdJ7B9
	0XuVx89zznYi3zd9HkrIMHV0RQsNMff5Gc9GMVqyXpSAt/VtCAHhIbJHm6FKHULUrAyU
	bfFSvz9cq9ju+/Blt75/XVUbyKREYrdQlQCHrzdaOFyA84BlGrQp7kd3rjK8LgrzewFW
	n1El4b6WERN+B/eEcGDGcdd8AWiVAGjAokQ6p49sl6qwVE9S68KcAj8nJLtTlf634Lqd
	yKCAjmYk2zzt+dNY99OH6+0smfpjYMyrXM3nGpNPSNIB9DrctOIQ5ayILk5CAKM8cTTd
	YuLQ==
MIME-Version: 1.0
Received: by 10.224.42.146 with SMTP id s18mr5119452qae.26.1340358706854; Fri,
	22 Jun 2012 02:51:46 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 02:51:46 -0700 (PDT)
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>
Date: Fri, 22 Jun 2012 10:51:46 +0100
X-Google-Sender-Auth: 56-WN_pje7ECvv_OBNYOt36eVms
Message-ID: <CAFLBxZbTZh+eOsHhoUyrXE1OscobJYJ5ZyWq8u8Kq-MQSy8PpQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Tapdiya, Ashish" <ashish.tapdiya@vanderbilt.edu>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 21, 2012 at 10:10 PM, Tapdiya, Ashish
<ashish.tapdiya@vanderbilt.edu> wrote:
> Hi,
>
> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0. However, if I supply sched=credit (default) or sched=credit2, specified scheduler gets selected and dom0 boots perfectly fine. Not sure if it is a bug.

arinc653 is a custom scheduler written by a single company for a
specific purpose (something to do with a hard real-time scheduling
problem they had).  None of the regular xen.org developers use it or
know anything about it, including exactly what it's for, what kind of
hardware it's expected to run on, or what kind of parameters are
required for it to boot.  It may even be the case that the company
that wrote it also has a custom OS that runs as a dom0.  So unless you
know what you need it for, it's probably best to leave that one alone.
:-)

sedf should work; a proper bug report (including serial console output
and a hardware description) will make fixing that bug a lot quicker.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si0hU-0002Xh-8U; Fri, 22 Jun 2012 10: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.Jackson@eu.citrix.com>) id 1Si0hT-0002XZ-Dn
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 10:02:47 +0000
Received: from [85.158.143.99:12956] by server-1.bemta-4.messagelabs.com id
	75/28-24392-6C244EF4; Fri, 22 Jun 2012 10:02:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340359364!20898916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19666 invoked from network); 22 Jun 2012 10:02:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 10:02:45 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 10:01:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 11:01:58 +0100
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 1Si0gg-0002qH-KI;
	Fri, 22 Jun 2012 10:01:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Si0gg-0008KB-Jv;
	Fri, 22 Jun 2012 11:01:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13317-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 11:01:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13317: 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 13317 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13317/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13089
 test-amd64-i386-xl-credit2   13 guest-localmigrate.2     fail blocked in 13089

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           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  ffd1f786a7b5
baseline version:
 xen                  e231998f4e3a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=ffd1f786a7b5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing ffd1f786a7b5
+ branch=xen-4.0-testing
+ revision=ffd1f786a7b5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r ffd1f786a7b5 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 17 changes to 17 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si0hU-0002Xh-8U; Fri, 22 Jun 2012 10: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.Jackson@eu.citrix.com>) id 1Si0hT-0002XZ-Dn
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 10:02:47 +0000
Received: from [85.158.143.99:12956] by server-1.bemta-4.messagelabs.com id
	75/28-24392-6C244EF4; Fri, 22 Jun 2012 10:02:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340359364!20898916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19666 invoked from network); 22 Jun 2012 10:02:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 10:02:45 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 10:01:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 11:01:58 +0100
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 1Si0gg-0002qH-KI;
	Fri, 22 Jun 2012 10:01:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Si0gg-0008KB-Jv;
	Fri, 22 Jun 2012 11:01:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13317-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 11:01:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13317: 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 13317 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13317/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13089
 test-amd64-i386-xl-credit2   13 guest-localmigrate.2     fail blocked in 13089

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           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass

version targeted for testing:
 xen                  ffd1f786a7b5
baseline version:
 xen                  e231998f4e3a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.0-testing
+ revision=ffd1f786a7b5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.0-testing ffd1f786a7b5
+ branch=xen-4.0-testing
+ revision=ffd1f786a7b5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.0-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.0-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ info_linux_tree xen-4.0-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r ffd1f786a7b5 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 17 changes to 17 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:05:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:05: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 1Si0k4-0002gZ-W9; Fri, 22 Jun 2012 10:05:28 +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 1Si0k3-0002gR-7g
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:05:27 +0000
Received: from [85.158.138.51:23374] by server-2.bemta-3.messagelabs.com id
	7E/15-10266-66344EF4; Fri, 22 Jun 2012 10:05:26 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340359520!10308511!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12960 invoked from network); 22 Jun 2012 10:05:21 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 10:05:21 -0000
Received: by qcsd16 with SMTP id d16so874457qcs.28
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 03:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=z0eQWNjBcrO1PM0sa1Y7468ZKX07zWevaM304X/RoeQ=;
	b=J0PC97J+/7cfz3rJOCSxTYTKcw9Fv6lsrOmP2Hq2mZZ7qlgJiHZIKkuBfvk57Z6kHI
	ZR2FRNZR0BWcVEwNztrCCuVGS8a2xV6SyopKswyt0xGdaPopO53qMyxxVN/GrOkZLAZ0
	H4TuYT0elnOMMYSQh/2yGpIewlK66B4u9EqDEkCG+iIwZ78u9fc1WzpU7sPLqtbnl7ji
	iQFeCEauKvddSsckVTNtaBKGtdMOuUJfJni7zPXlOMkXz+YSW4q0NvdvNGnfkfbf220S
	AkWW4bEWDfxYsfxhzRmQn+DRkmmLFkr9RE4T7gF/pstWa9umLDhjPIWCZSO50CoVUpwo
	nu6g==
MIME-Version: 1.0
Received: by 10.229.135.68 with SMTP id m4mr741229qct.70.1340359519969; Fri,
	22 Jun 2012 03:05:19 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 03:05:19 -0700 (PDT)
In-Reply-To: <1340297032.4856.93.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
Date: Fri, 22 Jun 2012 11:05:19 +0100
X-Google-Sender-Auth: 4gzSE_Cd9z_iNmzkMhzNl97zrl4
Message-ID: <CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 21, 2012 at 5:43 PM, Dario Faggioli <raistlin@linux.it> wrote:
>> > + * =A0- candidates with greater amount of free memory come first. In
>> > + * =A0 =A0case two (or more) candidates differ in their amount of free
>> > + * =A0 =A0memory by less than 10%,
>> Interesting idea -- sounds pretty reasonable.
>>
> Time will tell... :-O

The only potential concern is that it seems likely that your
comparison function above will not actually generate an ordering,
because the relationship it generates isn't transitive.  That is, you
could have a situation where A > B, B > C, but C > A.  For example:
A: freemem 1000, domains 1
B: freemem 1090, domains 2
C: freemem 1110, domains 3

In this case, A>B, because memory is within 10% but has fewer domains.
 B > C, because B is within 10%, and has fewer domains.  But C > A,
because C has more than 10% more memory than A (so its domains are not
counted against it).

 This may give you strange results from your quicksort.  But it's
likely to give something *reasonable* anyway.  (And if it turns out to
cause problems, a bubble sort shouldn't be too expensive and will
likely to be more robust against this kind of quirkiness.)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:05:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:05: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 1Si0k4-0002gZ-W9; Fri, 22 Jun 2012 10:05:28 +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 1Si0k3-0002gR-7g
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:05:27 +0000
Received: from [85.158.138.51:23374] by server-2.bemta-3.messagelabs.com id
	7E/15-10266-66344EF4; Fri, 22 Jun 2012 10:05:26 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340359520!10308511!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12960 invoked from network); 22 Jun 2012 10:05:21 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 10:05:21 -0000
Received: by qcsd16 with SMTP id d16so874457qcs.28
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 03:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=z0eQWNjBcrO1PM0sa1Y7468ZKX07zWevaM304X/RoeQ=;
	b=J0PC97J+/7cfz3rJOCSxTYTKcw9Fv6lsrOmP2Hq2mZZ7qlgJiHZIKkuBfvk57Z6kHI
	ZR2FRNZR0BWcVEwNztrCCuVGS8a2xV6SyopKswyt0xGdaPopO53qMyxxVN/GrOkZLAZ0
	H4TuYT0elnOMMYSQh/2yGpIewlK66B4u9EqDEkCG+iIwZ78u9fc1WzpU7sPLqtbnl7ji
	iQFeCEauKvddSsckVTNtaBKGtdMOuUJfJni7zPXlOMkXz+YSW4q0NvdvNGnfkfbf220S
	AkWW4bEWDfxYsfxhzRmQn+DRkmmLFkr9RE4T7gF/pstWa9umLDhjPIWCZSO50CoVUpwo
	nu6g==
MIME-Version: 1.0
Received: by 10.229.135.68 with SMTP id m4mr741229qct.70.1340359519969; Fri,
	22 Jun 2012 03:05:19 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 03:05:19 -0700 (PDT)
In-Reply-To: <1340297032.4856.93.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
Date: Fri, 22 Jun 2012 11:05:19 +0100
X-Google-Sender-Auth: 4gzSE_Cd9z_iNmzkMhzNl97zrl4
Message-ID: <CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 21, 2012 at 5:43 PM, Dario Faggioli <raistlin@linux.it> wrote:
>> > + * =A0- candidates with greater amount of free memory come first. In
>> > + * =A0 =A0case two (or more) candidates differ in their amount of free
>> > + * =A0 =A0memory by less than 10%,
>> Interesting idea -- sounds pretty reasonable.
>>
> Time will tell... :-O

The only potential concern is that it seems likely that your
comparison function above will not actually generate an ordering,
because the relationship it generates isn't transitive.  That is, you
could have a situation where A > B, B > C, but C > A.  For example:
A: freemem 1000, domains 1
B: freemem 1090, domains 2
C: freemem 1110, domains 3

In this case, A>B, because memory is within 10% but has fewer domains.
 B > C, because B is within 10%, and has fewer domains.  But C > A,
because C has more than 10% more memory than A (so its domains are not
counted against it).

 This may give you strange results from your quicksort.  But it's
likely to give something *reasonable* anyway.  (And if it turns out to
cause problems, a bubble sort shouldn't be too expensive and will
likely to be more robust against this kind of quirkiness.)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si0mh-0002qp-Hz; Fri, 22 Jun 2012 10:08:11 +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 1Si0mf-0002qW-Nx
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:08:10 +0000
Received: from [85.158.139.83:50823] by server-11.bemta-5.messagelabs.com id
	AA/A0-20400-80444EF4; Fri, 22 Jun 2012 10:08:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340359686!28980606!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21983 invoked from network); 22 Jun 2012 10:08:07 -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;
	22 Jun 2012 10:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; 
	d="log'?scan'208";a="199682036"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:08:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:08:05 -0400
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 1Si0mb-0006xC-1c;
	Fri, 22 Jun 2012 11:08:05 +0100
Message-ID: <4FE44404.2020702@citrix.com>
Date: Fri, 22 Jun 2012 11:08:04 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
In-Reply-To: <4FE45A64020000780008B570@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------060002060806010002020608"
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060002060806010002020608
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 22/06/12 10:43, Jan Beulich wrote:
>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Following Jan's infrastructure to mark certain PCI devices as read only,
>> I think it wise to now consider what other PCI devices should really be
>> read only to dom0.
>>
>> My preliminary thoughts include:
>>
>> * PCI serial devices which Xen is configured to use
> But only if they're single-function.

Why only single function?  Should Xen not turn all the functions it is
using to read-only ?

>
>> * Chipset devices (AMD IOMMU covered by previous patch)
>> * Cpu information
> What are you thinking of here specifically.

See attached lspci from a new sandybridge machine we have gained.  Quite
a lot of that looks rather dangerous for dom0 to play around with.


>
>> Are there any others I have overlooked, or reasons that dom0 should be
>> able to write to these areas?
>>
>> On a related note, should there be a mechanism for dom0 to determine
>> which PCI configuration areas are read only to itself?
> Perhaps, but that's not the only thing to deal with here. As
> said previously, when we want to add devices with active BARs
> here (luckily Wei confirmed that AMD IOMMUs have none),
> Dom0 trying to re-configure them would get us into problems.
> The issue exists today, but could become worse when we
> disallow the updates (as that could lead to two devices sharing
> resources they shouldn't share, whereas today a device in use
> by Xen and getting re-assigned its resources would merely stop
> working).
>
> Jan
>

It is certainly not an easy problem, and perhaps I am needlessly
complicating the issue.

It occurs that we have 3 possible directions to fix this issue.

1) Continue the current method of fixing things up after they break,
which can cause a hassle for a user encountering the issue.
2) Mark as RO and provide an explicit hypercall interface to remap
BARs.  I don't know how well this would go with upstream Linux.
3) Extend current infrastructure to be able to tell when a write is
affecting the BARs and permit them.  This seems like the best option
going forward, but might be quite hard to implement.

I guess the real question is whether we should continue reactively
fixing problems, or start protectively fixing the root cause.  My gut
feeling is that we are going to start seeing more and more devices on
the PCI bus which Xen should be using, rather than dom0.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




--------------060002060806010002020608
Content-Type: text/x-log; name="sandybridge-lspci-tv.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="sandybridge-lspci-tv.log"

-+-[0000:ff]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:c0]-+-02.0-[c1]--
 |           +-03.0-[c2]--
 |           +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
 |           +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
 |           +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
 |           +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
 |           +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
 |           +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
 |           +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
 |           +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
 |           +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
 |           \-05.4  Intel Corporation Sandy Bridge I/O APIC
 +-[0000:bf]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-02.0-[81]--
 |           +-03.0-[82]--
 |           +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
 |           +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
 |           +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
 |           +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
 |           +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
 |           +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
 |           +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
 |           +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
 |           +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
 |           \-05.4  Intel Corporation Sandy Bridge I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:40]-+-01.0-[41]--
 |           +-02.0-[42]--
 |           +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
 |           +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
 |           +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
 |           +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
 |           +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
 |           +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
 |           +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
 |           +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
 |           +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
 |           \-05.4  Intel Corporation Sandy Bridge I/O APIC
 +-[0000:3f]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Sandy Bridge DMI2
             +-01.0-[01-03]----00.0-[02-03]----08.0-[03]--+-00.0  Intel Corporation Patsburg Dual 4-Port SATA/SAS Storage Control Unit
             |                                            +-00.3  Intel Corporation Patsburg SMBus Controller 0
             |                                            +-00.4  Intel Corporation Patsburg SMBus Controller 1
             |                                            \-00.5  Intel Corporation Patsburg SMBus Controller 2
             +-02.0-[04]--
             +-03.0-[05]--
             +-03.2-[06-07]--+-00.0  Intel Corporation Ethernet Controller 10 Gigabit X540-AT2
             |               \-00.1  Intel Corporation Ethernet Controller 10 Gigabit X540-AT2
             +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
             +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
             +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
             +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
             +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
             +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
             +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
             +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
             +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
             +-05.4  Intel Corporation Sandy Bridge I/O APIC
             +-16.0  Intel Corporation Patsburg MEI Controller #1
             +-16.1  Intel Corporation Patsburg MEI Controller #2
             +-1a.0  Intel Corporation Patsburg USB2 Enhanced Host Controller #2
             +-1c.0-[08]--
             +-1c.7-[09]----00.0  Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1)
             +-1d.0  Intel Corporation Patsburg USB2 Enhanced Host Controller #1
             +-1e.0-[0a]--
             +-1f.0  Intel Corporation Patsburg LPC Controller
             +-1f.2  Intel Corporation Patsburg 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation Patsburg SMBus Host Controller

--------------060002060806010002020608
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060002060806010002020608--


From xen-devel-bounces@lists.xen.org Fri Jun 22 10:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si0mh-0002qp-Hz; Fri, 22 Jun 2012 10:08:11 +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 1Si0mf-0002qW-Nx
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:08:10 +0000
Received: from [85.158.139.83:50823] by server-11.bemta-5.messagelabs.com id
	AA/A0-20400-80444EF4; Fri, 22 Jun 2012 10:08:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340359686!28980606!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21983 invoked from network); 22 Jun 2012 10:08:07 -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;
	22 Jun 2012 10:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; 
	d="log'?scan'208";a="199682036"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:08:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:08:05 -0400
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 1Si0mb-0006xC-1c;
	Fri, 22 Jun 2012 11:08:05 +0100
Message-ID: <4FE44404.2020702@citrix.com>
Date: Fri, 22 Jun 2012 11:08:04 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
In-Reply-To: <4FE45A64020000780008B570@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------060002060806010002020608"
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060002060806010002020608
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 22/06/12 10:43, Jan Beulich wrote:
>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Following Jan's infrastructure to mark certain PCI devices as read only,
>> I think it wise to now consider what other PCI devices should really be
>> read only to dom0.
>>
>> My preliminary thoughts include:
>>
>> * PCI serial devices which Xen is configured to use
> But only if they're single-function.

Why only single function?  Should Xen not turn all the functions it is
using to read-only ?

>
>> * Chipset devices (AMD IOMMU covered by previous patch)
>> * Cpu information
> What are you thinking of here specifically.

See attached lspci from a new sandybridge machine we have gained.  Quite
a lot of that looks rather dangerous for dom0 to play around with.


>
>> Are there any others I have overlooked, or reasons that dom0 should be
>> able to write to these areas?
>>
>> On a related note, should there be a mechanism for dom0 to determine
>> which PCI configuration areas are read only to itself?
> Perhaps, but that's not the only thing to deal with here. As
> said previously, when we want to add devices with active BARs
> here (luckily Wei confirmed that AMD IOMMUs have none),
> Dom0 trying to re-configure them would get us into problems.
> The issue exists today, but could become worse when we
> disallow the updates (as that could lead to two devices sharing
> resources they shouldn't share, whereas today a device in use
> by Xen and getting re-assigned its resources would merely stop
> working).
>
> Jan
>

It is certainly not an easy problem, and perhaps I am needlessly
complicating the issue.

It occurs that we have 3 possible directions to fix this issue.

1) Continue the current method of fixing things up after they break,
which can cause a hassle for a user encountering the issue.
2) Mark as RO and provide an explicit hypercall interface to remap
BARs.  I don't know how well this would go with upstream Linux.
3) Extend current infrastructure to be able to tell when a write is
affecting the BARs and permit them.  This seems like the best option
going forward, but might be quite hard to implement.

I guess the real question is whether we should continue reactively
fixing problems, or start protectively fixing the root cause.  My gut
feeling is that we are going to start seeing more and more devices on
the PCI bus which Xen should be using, rather than dom0.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




--------------060002060806010002020608
Content-Type: text/x-log; name="sandybridge-lspci-tv.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="sandybridge-lspci-tv.log"

-+-[0000:ff]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:c0]-+-02.0-[c1]--
 |           +-03.0-[c2]--
 |           +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
 |           +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
 |           +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
 |           +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
 |           +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
 |           +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
 |           +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
 |           +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
 |           +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
 |           \-05.4  Intel Corporation Sandy Bridge I/O APIC
 +-[0000:bf]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-02.0-[81]--
 |           +-03.0-[82]--
 |           +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
 |           +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
 |           +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
 |           +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
 |           +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
 |           +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
 |           +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
 |           +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
 |           +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
 |           \-05.4  Intel Corporation Sandy Bridge I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:40]-+-01.0-[41]--
 |           +-02.0-[42]--
 |           +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
 |           +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
 |           +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
 |           +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
 |           +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
 |           +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
 |           +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
 |           +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
 |           +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
 |           \-05.4  Intel Corporation Sandy Bridge I/O APIC
 +-[0000:3f]-+-08.0  Intel Corporation Sandy Bridge QPI Link 0
 |           +-09.0  Intel Corporation Sandy Bridge QPI Link 1
 |           +-0a.0  Intel Corporation Sandy Bridge Power Control Unit 0
 |           +-0a.1  Intel Corporation Sandy Bridge Power Control Unit 1
 |           +-0a.2  Intel Corporation Sandy Bridge Power Control Unit 2
 |           +-0a.3  Intel Corporation Sandy Bridge Power Control Unit 3
 |           +-0b.0  Intel Corporation Sandy Bridge Interrupt Control Registers
 |           +-0b.3  Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0c.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Sandy Bridge System Address Decoder
 |           +-0d.0  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.1  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.2  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.3  Intel Corporation Sandy Bridge Unicast Register 0
 |           +-0d.6  Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Sandy Bridge Processor Home Agent
 |           +-0e.1  Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Sandy Bridge Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Sandy Bridge Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Sandy Bridge DDRIO
 |           +-13.0  Intel Corporation Sandy Bridge R2PCIe
 |           +-13.1  Intel Corporation Sandy Bridge Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Sandy Bridge QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Sandy Bridge DMI2
             +-01.0-[01-03]----00.0-[02-03]----08.0-[03]--+-00.0  Intel Corporation Patsburg Dual 4-Port SATA/SAS Storage Control Unit
             |                                            +-00.3  Intel Corporation Patsburg SMBus Controller 0
             |                                            +-00.4  Intel Corporation Patsburg SMBus Controller 1
             |                                            \-00.5  Intel Corporation Patsburg SMBus Controller 2
             +-02.0-[04]--
             +-03.0-[05]--
             +-03.2-[06-07]--+-00.0  Intel Corporation Ethernet Controller 10 Gigabit X540-AT2
             |               \-00.1  Intel Corporation Ethernet Controller 10 Gigabit X540-AT2
             +-04.0  Intel Corporation Sandy Bridge DMA Channel 0
             +-04.1  Intel Corporation Sandy Bridge DMA Channel 1
             +-04.2  Intel Corporation Sandy Bridge DMA Channel 2
             +-04.3  Intel Corporation Sandy Bridge DMA Channel 3
             +-04.4  Intel Corporation Sandy Bridge DMA Channel 4
             +-04.5  Intel Corporation Sandy Bridge DMA Channel 5
             +-04.6  Intel Corporation Sandy Bridge DMA Channel 6
             +-04.7  Intel Corporation Sandy Bridge DMA Channel 7
             +-05.0  Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Sandy Bridge Control Status and Global Errors
             +-05.4  Intel Corporation Sandy Bridge I/O APIC
             +-16.0  Intel Corporation Patsburg MEI Controller #1
             +-16.1  Intel Corporation Patsburg MEI Controller #2
             +-1a.0  Intel Corporation Patsburg USB2 Enhanced Host Controller #2
             +-1c.0-[08]--
             +-1c.7-[09]----00.0  Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1)
             +-1d.0  Intel Corporation Patsburg USB2 Enhanced Host Controller #1
             +-1e.0-[0a]--
             +-1f.0  Intel Corporation Patsburg LPC Controller
             +-1f.2  Intel Corporation Patsburg 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation Patsburg SMBus Host Controller

--------------060002060806010002020608
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060002060806010002020608--


From xen-devel-bounces@lists.xen.org Fri Jun 22 10:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si0qN-00035i-Bq; Fri, 22 Jun 2012 10:11:59 +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 1Si0qL-00035Q-Lm
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:11:57 +0000
Received: from [85.158.143.99:3253] by server-1.bemta-4.messagelabs.com id
	8A/C9-24392-DE444EF4; Fri, 22 Jun 2012 10:11:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340359915!28570362!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10105 invoked from network); 22 Jun 2012 10:11:56 -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;
	22 Jun 2012 10:11:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="29043984"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:11:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:11:54 -0400
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 1Si0qH-00072J-UP;
	Fri, 22 Jun 2012 11:11:53 +0100
Message-ID: <4FE444E9.8080809@citrix.com>
Date: Fri, 22 Jun 2012 11:11:53 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <4FE43518.9070106@citrix.com>
	<1783278186.20120622112436@eikelenboom.it>
In-Reply-To: <1783278186.20120622112436@eikelenboom.it>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 10:24, Sander Eikelenboom wrote:
>
>> Are there any others I have overlooked, or reasons that dom0 should be
>> able to write to these areas?
> Make devices specified for pci passthrough be really hidden and "owned" by the hyperviso ?
>      - which can in turn delegate ownership to a domain (including dom0)
>      - If a domain is destroyed, the hypervisor resets the device and becomes the owner again instead of dom0 ?

Why?

Currently this is covered by unbinding the dom0 driver and binding
pciback to the device.  Well behaved device drivers will not cause problems.

This way, the toolstack has control of which domains own what.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si0qN-00035i-Bq; Fri, 22 Jun 2012 10:11:59 +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 1Si0qL-00035Q-Lm
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:11:57 +0000
Received: from [85.158.143.99:3253] by server-1.bemta-4.messagelabs.com id
	8A/C9-24392-DE444EF4; Fri, 22 Jun 2012 10:11:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340359915!28570362!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10105 invoked from network); 22 Jun 2012 10:11:56 -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;
	22 Jun 2012 10:11:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="29043984"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:11:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:11:54 -0400
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 1Si0qH-00072J-UP;
	Fri, 22 Jun 2012 11:11:53 +0100
Message-ID: <4FE444E9.8080809@citrix.com>
Date: Fri, 22 Jun 2012 11:11:53 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <4FE43518.9070106@citrix.com>
	<1783278186.20120622112436@eikelenboom.it>
In-Reply-To: <1783278186.20120622112436@eikelenboom.it>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>, Jan Beulich <JBeulich@suse.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 10:24, Sander Eikelenboom wrote:
>
>> Are there any others I have overlooked, or reasons that dom0 should be
>> able to write to these areas?
> Make devices specified for pci passthrough be really hidden and "owned" by the hyperviso ?
>      - which can in turn delegate ownership to a domain (including dom0)
>      - If a domain is destroyed, the hypervisor resets the device and becomes the owner again instead of dom0 ?

Why?

Currently this is covered by unbinding the dom0 driver and binding
pciback to the device.  Well behaved device drivers will not cause problems.

This way, the toolstack has control of which domains own what.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si0sb-0003G5-64; Fri, 22 Jun 2012 10:14: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 1Si0sY-0003Fv-S1
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:14:15 +0000
Received: from [193.109.254.147:44212] by server-3.bemta-14.messagelabs.com id
	9D/63-08687-67544EF4; Fri, 22 Jun 2012 10:14:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340360051!10990994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20846 invoked from network); 22 Jun 2012 10:14:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 10:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 10:14:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 11:14:11 +0100
Message-ID: <1340360049.26083.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 22 Jun 2012 11:14:09 +0100
In-Reply-To: <1340296452.4856.87.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 17:34 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-21 at 12:40 +0100, Ian Campbell wrote:

> > > +/*
> > > + * This function tries to figure out if the host has a consistent number
> > > + * of cpus along all its NUMA nodes. In fact, if that is the case, we can
> > > + * calculate the minimum number of nodes needed for a domain by just
> > > + * dividing its total number of vcpus by this value computed here.
> > > + * However, we are not allowed to assume that all the nodes have the
> > > + * same number of cpus. Therefore, in case discrepancies among different
> > > + * nodes are found, this function just returns 0 and the caller needs
> > > + * to sort out things in some other way.
> > 
> > If the caller has to deal with this anyway why bother with this check
> > and/or the other algorithm?
> > 
> Mmm... I'm not sure I get what you mean here. Perhaps my commenting
> about the whole thing was not so clear in the first place.
> 
> The (George's :-)) idea is, if we know each node has 8 CPUs, and our
> domain wants more than that, it does not make sense to start looking for
> placement solutions with just one node. Actually, if the domain wants
> fewer than 16 CPUs, starting looking from solutions with 2 nodes in them
> should be the right thing.
> 
> That being said, I think it's important we do not assume we won't ever
> find some architecture with different number of CPUs in different nodes,
> and that is what a zero return from that function means.
> 
> What was that you thought not to be worthwhile?

The comment said "this function just returns 0 and the caller needs to
sort out things in some other way" so I was wondering -- well if the
caller has some algorithm which can cope with this why not always use
it. 

I think I later observed that if it returns zero the caller in this case
does something basic instead, so I see how this makes sense now.

> 
> > > +/* Get all the placement candidates satisfying some specific conditions */
> > > +int libxl__get_numa_candidates(libxl__gc *gc,
> > > +                               uint32_t min_free_memkb, int min_cpus,
> > > +                               int min_nodes, int max_nodes,
> > > +                               libxl__numa_candidate *cndts[], int *nr_cndts)
> > > +{
> > > +    libxl__numa_candidate *new_cndts = NULL;
> > > +    libxl_cputopology *tinfo = NULL;
> > > +    libxl_numainfo *ninfo = NULL;
> > > +    libxl_bitmap nodemap;
> > > +    int nr_nodes, nr_cpus;
> > > +    int array_size, rc;
> > > +
> > > +    /* Get platform info and prepare the map for testing the combinations */
> > > +    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
> > > +    if (ninfo == NULL)
> > > +        return ERROR_FAIL;
> > > +    /* If we don't have at least 2 nodes, it is useless to proceed */
> > 
> > You don't want to return whichever of those 2 nodes meets the
> > constraints?
> > 
> I actually was meaning something like "hey, there's only _1_ node, go
> for it!" :-P

I misread sorry!

> 
> > ...
> > > +    *cndts = new_cndts;
> > > + out:
> > > +    libxl_bitmap_dispose(&nodemap);
> > 
> > nodemap might not have been initialised?
> >
> Mmm... Right. So I really think I need an init function. :-(

In general all libxl datastructures are supposed to have one, most of
them are just memset(.., 0)

> 
> > > +    libxl_cputopology_list_free(tinfo, nr_cpus);
> > > +    libxl_numainfo_list_free(ninfo, nr_nodes);
> > 
> > It looks like the nr_* may also not have been initialised, but maybe
> > list_free is safe in that case since the associated array must
> > necessarily be NULL?
> > 
> Well, probably, but as they both do a "for (i=0;i<nr_*;i++)" I think
> it's safer if I "=0" those twos, is that ok?

I think it would be a good idea.

The alternative is that anything which returns a list has to set nr ==
0.

> > > +    /* Bring the best candidate in front of the list --> candidates[0] */
> > > +    if (nr_candidates > 1)
> > > +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);
> > 
> > Is the start up cost of libxl__sort_numa_candidates significant enough
> > to make that if worthwhile?
> > 
> I'm not sure what you mean here, I'm afraid ... :-(

Is the cost of sorting the 1 element list so high it is worth avoiding.
Since the sort itself would be trivial the startup costs are what would
dominate.

> 
> > > +
> > > +    /*
> > > +     * 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 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,
> > > +     * whatever that turns out to be.
> > > +     */
> > > +    if (libxl_bitmap_is_full(&info->cpumap)) {
> > > +        int rc = numa_place_domain(gc, info);
> > > +        if (rc)
> > > +            return rc;
> > 
> > I'm not sure about this, if numa_place_domain fails for any reason would
> > we be not better off logging and continuing without placement? We
> > already do that explicitly in a couple of cases.
> > 
> Well, actually, if it "fails" in the sense it finds no candidates or
> does not manage in placing the domain, it returns 0, so we do right what
> you're suggesting. I'm sure this is stated in some comment but I guess I
> can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
> something, which I think has to be handled like this, hasn't it?

That makes sense.

> Perhaps I can also add some logging about "successfully failing", i.e.,
> not getting into any error but not being able to place the domain. If
> yes, that will happen _inside_ numa_place_domain() rather than here.

Logging in that case seems wise in any case since it will have
performance implications 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 Fri Jun 22 10:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si0sb-0003G5-64; Fri, 22 Jun 2012 10:14: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 1Si0sY-0003Fv-S1
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:14:15 +0000
Received: from [193.109.254.147:44212] by server-3.bemta-14.messagelabs.com id
	9D/63-08687-67544EF4; Fri, 22 Jun 2012 10:14:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340360051!10990994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20846 invoked from network); 22 Jun 2012 10:14:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 10:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13165901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 10:14:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 11:14:11 +0100
Message-ID: <1340360049.26083.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 22 Jun 2012 11:14:09 +0100
In-Reply-To: <1340296452.4856.87.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 17:34 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-21 at 12:40 +0100, Ian Campbell wrote:

> > > +/*
> > > + * This function tries to figure out if the host has a consistent number
> > > + * of cpus along all its NUMA nodes. In fact, if that is the case, we can
> > > + * calculate the minimum number of nodes needed for a domain by just
> > > + * dividing its total number of vcpus by this value computed here.
> > > + * However, we are not allowed to assume that all the nodes have the
> > > + * same number of cpus. Therefore, in case discrepancies among different
> > > + * nodes are found, this function just returns 0 and the caller needs
> > > + * to sort out things in some other way.
> > 
> > If the caller has to deal with this anyway why bother with this check
> > and/or the other algorithm?
> > 
> Mmm... I'm not sure I get what you mean here. Perhaps my commenting
> about the whole thing was not so clear in the first place.
> 
> The (George's :-)) idea is, if we know each node has 8 CPUs, and our
> domain wants more than that, it does not make sense to start looking for
> placement solutions with just one node. Actually, if the domain wants
> fewer than 16 CPUs, starting looking from solutions with 2 nodes in them
> should be the right thing.
> 
> That being said, I think it's important we do not assume we won't ever
> find some architecture with different number of CPUs in different nodes,
> and that is what a zero return from that function means.
> 
> What was that you thought not to be worthwhile?

The comment said "this function just returns 0 and the caller needs to
sort out things in some other way" so I was wondering -- well if the
caller has some algorithm which can cope with this why not always use
it. 

I think I later observed that if it returns zero the caller in this case
does something basic instead, so I see how this makes sense now.

> 
> > > +/* Get all the placement candidates satisfying some specific conditions */
> > > +int libxl__get_numa_candidates(libxl__gc *gc,
> > > +                               uint32_t min_free_memkb, int min_cpus,
> > > +                               int min_nodes, int max_nodes,
> > > +                               libxl__numa_candidate *cndts[], int *nr_cndts)
> > > +{
> > > +    libxl__numa_candidate *new_cndts = NULL;
> > > +    libxl_cputopology *tinfo = NULL;
> > > +    libxl_numainfo *ninfo = NULL;
> > > +    libxl_bitmap nodemap;
> > > +    int nr_nodes, nr_cpus;
> > > +    int array_size, rc;
> > > +
> > > +    /* Get platform info and prepare the map for testing the combinations */
> > > +    ninfo = libxl_get_numainfo(CTX, &nr_nodes);
> > > +    if (ninfo == NULL)
> > > +        return ERROR_FAIL;
> > > +    /* If we don't have at least 2 nodes, it is useless to proceed */
> > 
> > You don't want to return whichever of those 2 nodes meets the
> > constraints?
> > 
> I actually was meaning something like "hey, there's only _1_ node, go
> for it!" :-P

I misread sorry!

> 
> > ...
> > > +    *cndts = new_cndts;
> > > + out:
> > > +    libxl_bitmap_dispose(&nodemap);
> > 
> > nodemap might not have been initialised?
> >
> Mmm... Right. So I really think I need an init function. :-(

In general all libxl datastructures are supposed to have one, most of
them are just memset(.., 0)

> 
> > > +    libxl_cputopology_list_free(tinfo, nr_cpus);
> > > +    libxl_numainfo_list_free(ninfo, nr_nodes);
> > 
> > It looks like the nr_* may also not have been initialised, but maybe
> > list_free is safe in that case since the associated array must
> > necessarily be NULL?
> > 
> Well, probably, but as they both do a "for (i=0;i<nr_*;i++)" I think
> it's safer if I "=0" those twos, is that ok?

I think it would be a good idea.

The alternative is that anything which returns a list has to set nr ==
0.

> > > +    /* Bring the best candidate in front of the list --> candidates[0] */
> > > +    if (nr_candidates > 1)
> > > +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);
> > 
> > Is the start up cost of libxl__sort_numa_candidates significant enough
> > to make that if worthwhile?
> > 
> I'm not sure what you mean here, I'm afraid ... :-(

Is the cost of sorting the 1 element list so high it is worth avoiding.
Since the sort itself would be trivial the startup costs are what would
dominate.

> 
> > > +
> > > +    /*
> > > +     * 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 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,
> > > +     * whatever that turns out to be.
> > > +     */
> > > +    if (libxl_bitmap_is_full(&info->cpumap)) {
> > > +        int rc = numa_place_domain(gc, info);
> > > +        if (rc)
> > > +            return rc;
> > 
> > I'm not sure about this, if numa_place_domain fails for any reason would
> > we be not better off logging and continuing without placement? We
> > already do that explicitly in a couple of cases.
> > 
> Well, actually, if it "fails" in the sense it finds no candidates or
> does not manage in placing the domain, it returns 0, so we do right what
> you're suggesting. I'm sure this is stated in some comment but I guess I
> can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
> something, which I think has to be handled like this, hasn't it?

That makes sense.

> Perhaps I can also add some logging about "successfully failing", i.e.,
> not getting into any error but not being able to place the domain. If
> yes, that will happen _inside_ numa_place_domain() rather than here.

Logging in that case seems wise in any case since it will have
performance implications 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 Fri Jun 22 10:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si1Hf-0004EC-Sf; Fri, 22 Jun 2012 10:40:11 +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 1Si1He-0004E2-QJ
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 10:40:11 +0000
Received: from [85.158.143.35:64188] by server-3.bemta-4.messagelabs.com id
	7B/3B-05808-A8B44EF4; Fri, 22 Jun 2012 10:40:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340361607!15784635!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NjM1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30674 invoked from network); 22 Jun 2012 10:40:08 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-21.messagelabs.com with SMTP;
	22 Jun 2012 10:40:08 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 22 Jun 2012 03:40:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="161194864"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 22 Jun 2012 03:40:05 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Jun 2012 03:40:04 -0700
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; Fri, 22 Jun 2012 03:40:04 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 18:40:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: AQHNT8fhexbUH0BVTLGVMLMLWAtaJ5cGIWPg
Date: Fri, 22 Jun 2012 10:40:01 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
In-Reply-To: <4FE362C0020000780008B2CD@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 20.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Recently we design xen vMCE as attached.
>> Please kindly help me to review it, any comments/suggestions are
>> appreciated.
> 
> The concept looks quite okay, provided no OS has a problem with
> the limitations imposed (most notably the restriction to a single
> reporting bank, particularly in the context of e.g. Linux partly
> ignoring the first bank under some conditions iirc).

'bank0 skipping' quirks is only for older model cpus, I think we have 2 options:
1). still use 1 bank and simply ignore this issue. I mean, even if guest runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest skip bank0, then guest MCE logic would think it detect a spurious mce, then kill itself. Considering bank0 quirks is only for old cpus, this is acceptable;
2). use 32 banks

In fact, a third option is, use 1 bank, but hypervisor kill guest when it detect bank0 quirks. This would be same effect as option 1, so I prefer let guest kill itself.

> 
> As to not needing any migration specific adjustments - what if
> a migration is in progress when an event needs to be delivered?
> 
> Jan

If a migration is in progress while an event delivered, we abort the migration.

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 Jun 22 10:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si1Hf-0004EC-Sf; Fri, 22 Jun 2012 10:40:11 +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 1Si1He-0004E2-QJ
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 10:40:11 +0000
Received: from [85.158.143.35:64188] by server-3.bemta-4.messagelabs.com id
	7B/3B-05808-A8B44EF4; Fri, 22 Jun 2012 10:40:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340361607!15784635!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NjM1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30674 invoked from network); 22 Jun 2012 10:40:08 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-21.messagelabs.com with SMTP;
	22 Jun 2012 10:40:08 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 22 Jun 2012 03:40:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="161194864"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 22 Jun 2012 03:40:05 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Jun 2012 03:40:04 -0700
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; Fri, 22 Jun 2012 03:40:04 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 18:40:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: AQHNT8fhexbUH0BVTLGVMLMLWAtaJ5cGIWPg
Date: Fri, 22 Jun 2012 10:40:01 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
In-Reply-To: <4FE362C0020000780008B2CD@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 20.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Recently we design xen vMCE as attached.
>> Please kindly help me to review it, any comments/suggestions are
>> appreciated.
> 
> The concept looks quite okay, provided no OS has a problem with
> the limitations imposed (most notably the restriction to a single
> reporting bank, particularly in the context of e.g. Linux partly
> ignoring the first bank under some conditions iirc).

'bank0 skipping' quirks is only for older model cpus, I think we have 2 options:
1). still use 1 bank and simply ignore this issue. I mean, even if guest runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest skip bank0, then guest MCE logic would think it detect a spurious mce, then kill itself. Considering bank0 quirks is only for old cpus, this is acceptable;
2). use 32 banks

In fact, a third option is, use 1 bank, but hypervisor kill guest when it detect bank0 quirks. This would be same effect as option 1, so I prefer let guest kill itself.

> 
> As to not needing any migration specific adjustments - what if
> a migration is in progress when an event needs to be delivered?
> 
> Jan

If a migration is in progress while an event delivered, we abort the migration.

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 Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xu-0004VW-Ay; Fri, 22 Jun 2012 10:56: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 1Si1Xr-0004UY-TT
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:56 +0000
Received: from [85.158.143.99:5045] by server-2.bemta-4.messagelabs.com id
	72/4E-17938-77F44EF4; Fri, 22 Jun 2012 10:56:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14803 invoked from network); 22 Jun 2012 10:56:54 -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;
	22 Jun 2012 10:56:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685179"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-4m;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9190b57657f4b6def855fa22de905f45d22ef7de
Message-ID: <9190b57657f4b6def855.1340362614@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:54 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 5 of 5] xl: initialise domid to an explicitly
	invalid 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340362601 -3600
# Node ID 9190b57657f4b6def855fa22de905f45d22ef7de
# Parent  2829b66dfe19afd4537ea4b2cfcef0cf28b49472
xl: initialise domid to an explicitly invalid value

also ensure it is invalid whenever we destroy the domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2829b66dfe19 -r 9190b57657f4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:56:41 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:56:41 2012 +0100
@@ -68,7 +68,8 @@ libxl_ctx *ctx;
 xlchild children[child_max];
 
 /* when we operate on a domain, it is this one: */
-static uint32_t domid;
+#define INVALID_DOMID ~0
+static uint32_t domid = INVALID_DOMID;
 static const char *common_domname;
 static int fd_lock = -1;
 
@@ -1389,6 +1390,7 @@ static int handle_domain_death(uint32_t 
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1451,6 +1453,12 @@ static int preserve_domain(uint32_t domi
     LOG("Preserving domain %d %s with suffix%s", domid, d_config->c_info.name, stime);
     rc = libxl_domain_preserve(ctx, domid, &d_config->c_info, stime, new_uuid);
 
+    /*
+     * Although domid still exists it is no longer the one we are concerned
+     * with.
+     */
+    domid = INVALID_DOMID;
+
     return rc == 0 ? 1 : 0;
 }
 
@@ -1738,7 +1746,7 @@ static int create_domain(struct domain_c
         goto out;
 
 start:
-    domid = -1;
+    assert(domid == INVALID_DOMID);
 
     rc = acquire_lock();
     if (rc < 0)
@@ -1985,8 +1993,10 @@ start:
 
 error_out:
     release_lock();
-    if (libxl_domid_valid_guest(domid))
+    if (libxl_domid_valid_guest(domid)) {
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
+    }
 
 out:
     if (logfile != 2)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xu-0004VW-Ay; Fri, 22 Jun 2012 10:56: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 1Si1Xr-0004UY-TT
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:56 +0000
Received: from [85.158.143.99:5045] by server-2.bemta-4.messagelabs.com id
	72/4E-17938-77F44EF4; Fri, 22 Jun 2012 10:56:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14803 invoked from network); 22 Jun 2012 10:56:54 -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;
	22 Jun 2012 10:56:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685179"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-4m;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9190b57657f4b6def855fa22de905f45d22ef7de
Message-ID: <9190b57657f4b6def855.1340362614@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:54 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 5 of 5] xl: initialise domid to an explicitly
	invalid 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340362601 -3600
# Node ID 9190b57657f4b6def855fa22de905f45d22ef7de
# Parent  2829b66dfe19afd4537ea4b2cfcef0cf28b49472
xl: initialise domid to an explicitly invalid value

also ensure it is invalid whenever we destroy the domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2829b66dfe19 -r 9190b57657f4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:56:41 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:56:41 2012 +0100
@@ -68,7 +68,8 @@ libxl_ctx *ctx;
 xlchild children[child_max];
 
 /* when we operate on a domain, it is this one: */
-static uint32_t domid;
+#define INVALID_DOMID ~0
+static uint32_t domid = INVALID_DOMID;
 static const char *common_domname;
 static int fd_lock = -1;
 
@@ -1389,6 +1390,7 @@ static int handle_domain_death(uint32_t 
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1451,6 +1453,12 @@ static int preserve_domain(uint32_t domi
     LOG("Preserving domain %d %s with suffix%s", domid, d_config->c_info.name, stime);
     rc = libxl_domain_preserve(ctx, domid, &d_config->c_info, stime, new_uuid);
 
+    /*
+     * Although domid still exists it is no longer the one we are concerned
+     * with.
+     */
+    domid = INVALID_DOMID;
+
     return rc == 0 ? 1 : 0;
 }
 
@@ -1738,7 +1746,7 @@ static int create_domain(struct domain_c
         goto out;
 
 start:
-    domid = -1;
+    assert(domid == INVALID_DOMID);
 
     rc = acquire_lock();
     if (rc < 0)
@@ -1985,8 +1993,10 @@ start:
 
 error_out:
     release_lock();
-    if (libxl_domid_valid_guest(domid))
+    if (libxl_domid_valid_guest(domid)) {
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
+    }
 
 out:
     if (logfile != 2)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xs-0004V6-Go; Fri, 22 Jun 2012 10:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si1Xr-0004UY-EE
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:55 +0000
Received: from [85.158.143.99:5014] by server-2.bemta-4.messagelabs.com id
	B0/4E-17938-67F44EF4; Fri, 22 Jun 2012 10:56:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340362612!23331695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31147 invoked from network); 22 Jun 2012 10:56:54 -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;
	22 Jun 2012 10:56:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685178"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-3a;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: b63faf77bff33d7c9ebfe7260ecaffc26f3773a8
Message-ID: <b63faf77bff33d7c9ebf.1340362612@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:52 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 3 of 5] libxl: correct type of cpupool 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1340362529 -3600
# Node ID b63faf77bff33d7c9ebfe7260ecaffc26f3773a8
# Parent  b6a78743e13fb5b7f652f25a541eb425a21f1396
libxl: correct type of cpupool variable.

libxl__domain_cpupool returns int and can return ERROR_* so we need to
use a signed type.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b6a78743e13f -r b63faf77bff3 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:27 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:29 2012 +0100
@@ -76,7 +76,7 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
 libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid)
 {
-    uint32_t cpupool = libxl__domain_cpupool(gc, domid);
+    int cpupool = libxl__domain_cpupool(gc, domid);
     libxl_cpupoolinfo poolinfo;
     libxl_scheduler sched = LIBXL_SCHEDULER_UNKNOWN;
     int rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xs-0004V6-Go; Fri, 22 Jun 2012 10:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si1Xr-0004UY-EE
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:55 +0000
Received: from [85.158.143.99:5014] by server-2.bemta-4.messagelabs.com id
	B0/4E-17938-67F44EF4; Fri, 22 Jun 2012 10:56:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340362612!23331695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31147 invoked from network); 22 Jun 2012 10:56:54 -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;
	22 Jun 2012 10:56:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685178"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-3a;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: b63faf77bff33d7c9ebfe7260ecaffc26f3773a8
Message-ID: <b63faf77bff33d7c9ebf.1340362612@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:52 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 3 of 5] libxl: correct type of cpupool 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1340362529 -3600
# Node ID b63faf77bff33d7c9ebfe7260ecaffc26f3773a8
# Parent  b6a78743e13fb5b7f652f25a541eb425a21f1396
libxl: correct type of cpupool variable.

libxl__domain_cpupool returns int and can return ERROR_* so we need to
use a signed type.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b6a78743e13f -r b63faf77bff3 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:27 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:29 2012 +0100
@@ -76,7 +76,7 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
 libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid)
 {
-    uint32_t cpupool = libxl__domain_cpupool(gc, domid);
+    int cpupool = libxl__domain_cpupool(gc, domid);
     libxl_cpupoolinfo poolinfo;
     libxl_scheduler sched = LIBXL_SCHEDULER_UNKNOWN;
     int rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xs-0004Uz-4L; Fri, 22 Jun 2012 10:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si1Xq-0004UL-NX
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:54 +0000
Received: from [85.158.143.99:43261] by server-1.bemta-4.messagelabs.com id
	30/57-24392-67F44EF4; Fri, 22 Jun 2012 10:56:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14758 invoked from network); 22 Jun 2012 10:56:53 -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;
	22 Jun 2012 10:56:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685177"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-49;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2829b66dfe19afd4537ea4b2cfcef0cf28b49472
Message-ID: <2829b66dfe19afd4537e.1340362613@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:53 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 4 of 5] libxl: log on failure in cpupool_info
 and libxl__domain_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340362601 -3600
# Node ID 2829b66dfe19afd4537ea4b2cfcef0cf28b49472
# Parent  b63faf77bff33d7c9ebfe7260ecaffc26f3773a8
libxl: log on failure in cpupool_info and libxl__domain_cpupool

Also in cpupool_info propagate the failure value from
libxl_cpumap_alloc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b63faf77bff3 -r 2829b66dfe19 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jun 22 11:55:29 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jun 22 11:56:41 2012 +0100
@@ -562,16 +562,27 @@ static int cpupool_info(libxl__gc *gc,
 
     xcinfo = xc_cpupool_getinfo(CTX->xch, poolid);
     if (xcinfo == NULL)
+    {
+        LOGE(ERROR, "failed to get info for cpupool%d\n", poolid);
         return ERROR_FAIL;
+    }
 
     if (exact && xcinfo->cpupool_id != poolid)
+    {
+        LOG(ERROR, "got info for cpupool%d, wanted cpupool%d\n",
+            xcinfo->cpupool_id, poolid);
         goto out;
+    }
 
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap))
+    rc = libxl_cpumap_alloc(CTX, &info->cpumap);
+    if (rc)
+    {
+        LOG(ERROR, "unable to allocate cpumap %d\n", rc);
         goto out;
+    }
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
 
     rc = 0;
diff -r b63faf77bff3 -r 2829b66dfe19 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:29 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 22 11:56:41 2012 +0100
@@ -67,10 +67,15 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
     ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
     if (ret != 1)
+    {
+        LOGE(ERROR, "getinfolist failed %d\n", ret);
         return ERROR_FAIL;
+    }
     if (info.domain != domid)
+    {
+        LOGE(ERROR, "got info for dom%d, wanted dom%d\n", info.domain, domid);
         return ERROR_FAIL;
-
+    }
     return info.cpupool;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xs-0004Uz-4L; Fri, 22 Jun 2012 10:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si1Xq-0004UL-NX
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:54 +0000
Received: from [85.158.143.99:43261] by server-1.bemta-4.messagelabs.com id
	30/57-24392-67F44EF4; Fri, 22 Jun 2012 10:56:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14758 invoked from network); 22 Jun 2012 10:56:53 -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;
	22 Jun 2012 10:56:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685177"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-49;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2829b66dfe19afd4537ea4b2cfcef0cf28b49472
Message-ID: <2829b66dfe19afd4537e.1340362613@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:53 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 4 of 5] libxl: log on failure in cpupool_info
 and libxl__domain_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340362601 -3600
# Node ID 2829b66dfe19afd4537ea4b2cfcef0cf28b49472
# Parent  b63faf77bff33d7c9ebfe7260ecaffc26f3773a8
libxl: log on failure in cpupool_info and libxl__domain_cpupool

Also in cpupool_info propagate the failure value from
libxl_cpumap_alloc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b63faf77bff3 -r 2829b66dfe19 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jun 22 11:55:29 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jun 22 11:56:41 2012 +0100
@@ -562,16 +562,27 @@ static int cpupool_info(libxl__gc *gc,
 
     xcinfo = xc_cpupool_getinfo(CTX->xch, poolid);
     if (xcinfo == NULL)
+    {
+        LOGE(ERROR, "failed to get info for cpupool%d\n", poolid);
         return ERROR_FAIL;
+    }
 
     if (exact && xcinfo->cpupool_id != poolid)
+    {
+        LOG(ERROR, "got info for cpupool%d, wanted cpupool%d\n",
+            xcinfo->cpupool_id, poolid);
         goto out;
+    }
 
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap))
+    rc = libxl_cpumap_alloc(CTX, &info->cpumap);
+    if (rc)
+    {
+        LOG(ERROR, "unable to allocate cpumap %d\n", rc);
         goto out;
+    }
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
 
     rc = 0;
diff -r b63faf77bff3 -r 2829b66dfe19 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:29 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 22 11:56:41 2012 +0100
@@ -67,10 +67,15 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
     ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
     if (ret != 1)
+    {
+        LOGE(ERROR, "getinfolist failed %d\n", ret);
         return ERROR_FAIL;
+    }
     if (info.domain != domid)
+    {
+        LOGE(ERROR, "got info for dom%d, wanted dom%d\n", info.domain, domid);
         return ERROR_FAIL;
-
+    }
     return info.cpupool;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xt-0004VM-UG; Fri, 22 Jun 2012 10:56: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 1Si1Xr-0004UL-QJ
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:56 +0000
Received: from [85.158.143.99:5072] by server-1.bemta-4.messagelabs.com id
	0A/57-24392-77F44EF4; Fri, 22 Jun 2012 10:56:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340362612!23331695!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31185 invoked from network); 22 Jun 2012 10:56:54 -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;
	22 Jun 2012 10:56:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685180"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-2Q;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 998d48ccb8905907cb2f104b475e5ab6ad445348
Message-ID: <998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:50 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 1 of 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340361703 -3600
# Node ID 998d48ccb8905907cb2f104b475e5ab6ad445348
# Parent  5fb3c536b5a8810fb8be4149df609d272beff959
libxl: validate scheduler parameters

This was previously done by xl itself however the domain was not
created at that point so there was no domid to check. This happened to
work on first boot because xl's global domid was initialised to zero
so we would (incorrectly) validate the new domain to be against
domain0. On reboot though we would try to use the old domain's id and
fail.

sched_params_valid is moved and gains a gc+domid parameters and
s/ctx/CTX/. The call is placed after
libxl__domain_build_info_setdefault in the create path, because
set_defaults doesn't have access to the domid and there are other
callers which don't even have a domid to give it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jun 22 10:14:46 2012 +0100
+++ b/tools/libxl/libxl_create.c	Fri Jun 22 11:41:43 2012 +0100
@@ -72,6 +72,49 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
+static int sched_params_valid(libxl__gc *gc,
+                              uint32_t domid, libxl_domain_sched_params *scp)
+{
+    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
+    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
+    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    int has_extratime =
+                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
+    libxl_domain_sched_params sci;
+
+    libxl_domain_sched_params_get(CTX, domid, &sci);
+
+    /* The sedf scheduler needs some more consistency checking */
+    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+        if (has_weight && (has_period || has_slice))
+            return 0;
+        if (has_period != has_slice)
+            return 0;
+
+        /*
+         * Idea is, if we specify a weight, then both period and
+         * slice has to be zero. OTOH, if we do not specify a weight,
+         * that means we want a pure best effort domain or an actual
+         * real-time one. In the former case, it is period that needs
+         * to be zero, in the latter, weight should be.
+         */
+        if (has_weight) {
+            scp->slice = 0;
+            scp->period = 0;
+        }
+        else if (!has_period) {
+            /* We can setup a proper best effort domain (extra time only)
+             * iff we either already have or are asking for some extra time. */
+            scp->weight = has_extratime ? scp->extratime : sci.extratime;
+            scp->period = 0;
+        }
+        if (has_period && has_slice)
+            scp->weight = 0;
+    }
+
+    return 1;
+}
+
 int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info)
 {
@@ -622,6 +665,12 @@ static void initiate_domain_create(libxl
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
+    if (!sched_params_valid(gc, domid, &d_config->b_info.sched_params)) {
+        LOG(ERROR, "Invalid scheduling parameters\n");
+        ret = ERROR_INVAL;
+        goto error_out;
+    }
+
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
         if (ret) goto error_out;
diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jun 22 10:14:46 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:41:43 2012 +0100
@@ -550,48 +550,6 @@ vcpp_out:
     return rc;
 }
 
-static int sched_params_valid(libxl_domain_sched_params *scp)
-{
-    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
-    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
-    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
-    int has_extratime =
-                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
-    libxl_domain_sched_params sci;
-
-    libxl_domain_sched_params_get(ctx, domid, &sci);
-
-    /* The sedf scheduler needs some more consistency checking */
-    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
-        if (has_weight && (has_period || has_slice))
-            return 0;
-        if (has_period != has_slice)
-            return 0;
-
-        /*
-         * Idea is, if we specify a weight, then both period and
-         * slice has to be zero. OTOH, if we do not specify a weight,
-         * that means we want a pure best effort domain or an actual
-         * real-time one. In the former case, it is period that needs
-         * to be zero, in the latter, weight should be.
-         */
-        if (has_weight) {
-            scp->slice = 0;
-            scp->period = 0;
-        }
-        else if (!has_period) {
-            /* We can setup a proper best effort domain (extra time only)
-             * iff we either already have or are asking for some extra time. */
-            scp->weight = has_extratime ? scp->extratime : sci.extratime;
-            scp->period = 0;
-        }
-        if (has_period && has_slice)
-            scp->weight = 0;
-    }
-
-    return 1;
-}
-
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -686,10 +644,6 @@ static void parse_config_data(const char
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
-    if (!sched_params_valid(&b_info->sched_params)) {
-        fprintf(stderr, "Invalid scheduling parameters\n");
-        exit(1);
-    }
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xt-0004VM-UG; Fri, 22 Jun 2012 10:56: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 1Si1Xr-0004UL-QJ
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:56 +0000
Received: from [85.158.143.99:5072] by server-1.bemta-4.messagelabs.com id
	0A/57-24392-77F44EF4; Fri, 22 Jun 2012 10:56:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340362612!23331695!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31185 invoked from network); 22 Jun 2012 10:56:54 -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;
	22 Jun 2012 10:56:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685180"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-2Q;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 998d48ccb8905907cb2f104b475e5ab6ad445348
Message-ID: <998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:50 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 1 of 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340361703 -3600
# Node ID 998d48ccb8905907cb2f104b475e5ab6ad445348
# Parent  5fb3c536b5a8810fb8be4149df609d272beff959
libxl: validate scheduler parameters

This was previously done by xl itself however the domain was not
created at that point so there was no domid to check. This happened to
work on first boot because xl's global domid was initialised to zero
so we would (incorrectly) validate the new domain to be against
domain0. On reboot though we would try to use the old domain's id and
fail.

sched_params_valid is moved and gains a gc+domid parameters and
s/ctx/CTX/. The call is placed after
libxl__domain_build_info_setdefault in the create path, because
set_defaults doesn't have access to the domid and there are other
callers which don't even have a domid to give it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jun 22 10:14:46 2012 +0100
+++ b/tools/libxl/libxl_create.c	Fri Jun 22 11:41:43 2012 +0100
@@ -72,6 +72,49 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
+static int sched_params_valid(libxl__gc *gc,
+                              uint32_t domid, libxl_domain_sched_params *scp)
+{
+    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
+    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
+    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
+    int has_extratime =
+                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
+    libxl_domain_sched_params sci;
+
+    libxl_domain_sched_params_get(CTX, domid, &sci);
+
+    /* The sedf scheduler needs some more consistency checking */
+    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+        if (has_weight && (has_period || has_slice))
+            return 0;
+        if (has_period != has_slice)
+            return 0;
+
+        /*
+         * Idea is, if we specify a weight, then both period and
+         * slice has to be zero. OTOH, if we do not specify a weight,
+         * that means we want a pure best effort domain or an actual
+         * real-time one. In the former case, it is period that needs
+         * to be zero, in the latter, weight should be.
+         */
+        if (has_weight) {
+            scp->slice = 0;
+            scp->period = 0;
+        }
+        else if (!has_period) {
+            /* We can setup a proper best effort domain (extra time only)
+             * iff we either already have or are asking for some extra time. */
+            scp->weight = has_extratime ? scp->extratime : sci.extratime;
+            scp->period = 0;
+        }
+        if (has_period && has_slice)
+            scp->weight = 0;
+    }
+
+    return 1;
+}
+
 int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info)
 {
@@ -622,6 +665,12 @@ static void initiate_domain_create(libxl
     ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
     if (ret) goto error_out;
 
+    if (!sched_params_valid(gc, domid, &d_config->b_info.sched_params)) {
+        LOG(ERROR, "Invalid scheduling parameters\n");
+        ret = ERROR_INVAL;
+        goto error_out;
+    }
+
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
         if (ret) goto error_out;
diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jun 22 10:14:46 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:41:43 2012 +0100
@@ -550,48 +550,6 @@ vcpp_out:
     return rc;
 }
 
-static int sched_params_valid(libxl_domain_sched_params *scp)
-{
-    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
-    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
-    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
-    int has_extratime =
-                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
-    libxl_domain_sched_params sci;
-
-    libxl_domain_sched_params_get(ctx, domid, &sci);
-
-    /* The sedf scheduler needs some more consistency checking */
-    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
-        if (has_weight && (has_period || has_slice))
-            return 0;
-        if (has_period != has_slice)
-            return 0;
-
-        /*
-         * Idea is, if we specify a weight, then both period and
-         * slice has to be zero. OTOH, if we do not specify a weight,
-         * that means we want a pure best effort domain or an actual
-         * real-time one. In the former case, it is period that needs
-         * to be zero, in the latter, weight should be.
-         */
-        if (has_weight) {
-            scp->slice = 0;
-            scp->period = 0;
-        }
-        else if (!has_period) {
-            /* We can setup a proper best effort domain (extra time only)
-             * iff we either already have or are asking for some extra time. */
-            scp->weight = has_extratime ? scp->extratime : sci.extratime;
-            scp->period = 0;
-        }
-        if (has_period && has_slice)
-            scp->weight = 0;
-    }
-
-    return 1;
-}
-
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -686,10 +644,6 @@ static void parse_config_data(const char
         b_info->sched_params.latency = l;
     if (!xlu_cfg_get_long (config, "extratime", &l, 0))
         b_info->sched_params.extratime = l;
-    if (!sched_params_valid(&b_info->sched_params)) {
-        fprintf(stderr, "Invalid scheduling parameters\n");
-        exit(1);
-    }
 
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xr-0004Uk-OD; Fri, 22 Jun 2012 10:56: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 1Si1Xq-0004UL-1O
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:54 +0000
Received: from [85.158.143.99:43195] by server-1.bemta-4.messagelabs.com id
	98/47-24392-57F44EF4; Fri, 22 Jun 2012 10:56:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14716 invoked from network); 22 Jun 2012 10:56:52 -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;
	22 Jun 2012 10:56:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685176"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-34;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: b6a78743e13fb5b7f652f25a541eb425a21f1396
Message-ID: <b6a78743e13fb5b7f652.1340362611@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:51 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 2 of 5] libxl: initialise cpupoolinfo in
 libxl__domain_scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340362527 -3600
# Node ID b6a78743e13fb5b7f652f25a541eb425a21f1396
# Parent  998d48ccb8905907cb2f104b475e5ab6ad445348
libxl: initialise cpupoolinfo in libxl__domain_scheduler

If libxl_cpupool_info fails then we would call
libxl_cpupoolinfo_dispose on an uninitialised struct, and possibly
free an invalid pointer.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 998d48ccb890 -r b6a78743e13f tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 22 11:41:43 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:27 2012 +0100
@@ -84,6 +84,7 @@ libxl_scheduler libxl__domain_scheduler(
     if (cpupool < 0)
         return sched;
 
+    libxl_cpupoolinfo_init(&poolinfo);
     rc = libxl_cpupool_info(CTX, &poolinfo, cpupool);
     if (rc < 0)
         goto out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si1Xr-0004UZ-CS; Fri, 22 Jun 2012 10:56: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 1Si1Xp-0004UL-LT
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:53 +0000
Received: from [85.158.143.99:43139] by server-1.bemta-4.messagelabs.com id
	7F/37-24392-47F44EF4; Fri, 22 Jun 2012 10:56:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14674 invoked from network); 22 Jun 2012 10:56:52 -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;
	22 Jun 2012 10:56:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685175"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-1o;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:49 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 fixes recent test failures reboot a guest (e.g. flight
13302).

The main fix is the first patch which stops us from trying to validate
a domains scheduler paramters before it has been created.

The others are miscellaneous fixes I noticed while tracking that down.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1Xr-0004Uk-OD; Fri, 22 Jun 2012 10:56: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 1Si1Xq-0004UL-1O
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:54 +0000
Received: from [85.158.143.99:43195] by server-1.bemta-4.messagelabs.com id
	98/47-24392-57F44EF4; Fri, 22 Jun 2012 10:56:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14716 invoked from network); 22 Jun 2012 10:56:52 -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;
	22 Jun 2012 10:56:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685176"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-34;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: b6a78743e13fb5b7f652f25a541eb425a21f1396
Message-ID: <b6a78743e13fb5b7f652.1340362611@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:51 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 2 of 5] libxl: initialise cpupoolinfo in
 libxl__domain_scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340362527 -3600
# Node ID b6a78743e13fb5b7f652f25a541eb425a21f1396
# Parent  998d48ccb8905907cb2f104b475e5ab6ad445348
libxl: initialise cpupoolinfo in libxl__domain_scheduler

If libxl_cpupool_info fails then we would call
libxl_cpupoolinfo_dispose on an uninitialised struct, and possibly
free an invalid pointer.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 998d48ccb890 -r b6a78743e13f tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 22 11:41:43 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 22 11:55:27 2012 +0100
@@ -84,6 +84,7 @@ libxl_scheduler libxl__domain_scheduler(
     if (cpupool < 0)
         return sched;
 
+    libxl_cpupoolinfo_init(&poolinfo);
     rc = libxl_cpupool_info(CTX, &poolinfo, cpupool);
     if (rc < 0)
         goto out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 10:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 10: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 1Si1Xr-0004UZ-CS; Fri, 22 Jun 2012 10:56: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 1Si1Xp-0004UL-LT
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 10:56:53 +0000
Received: from [85.158.143.99:43139] by server-1.bemta-4.messagelabs.com id
	7F/37-24392-47F44EF4; Fri, 22 Jun 2012 10:56:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340362610!23356596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14674 invoked from network); 22 Jun 2012 10:56:52 -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;
	22 Jun 2012 10:56:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336363200"; d="scan'208";a="199685175"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 06:56:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 06:56:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Si1Xm-0008DF-1o;
	Fri, 22 Jun 2012 11:56:50 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340362609@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 22 Jun 2012 11:56:49 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 fixes recent test failures reboot a guest (e.g. flight
13302).

The main fix is the first patch which stops us from trying to validate
a domains scheduler paramters before it has been created.

The others are miscellaneous fixes I noticed while tracking that down.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1fc-0005eo-AX; Fri, 22 Jun 2012 11:04:56 +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 1Si1fa-0005ej-QW
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:04:55 +0000
Received: from [85.158.138.51:36082] by server-1.bemta-3.messagelabs.com id
	E2/52-14648-65154EF4; Fri, 22 Jun 2012 11:04:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340363092!27895451!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1212 invoked from network); 22 Jun 2012 11:04:53 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:04:53 -0000
Received: by qcsd16 with SMTP id d16so900341qcs.28
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 04:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=LUTgVWVQdDjbR4dA6dybmOWjXm0pzeFhsA/KWaR+zko=;
	b=vg06XucllOYEwS0wobeH71kwewZOaCNbDkLqpZeOE5trAxbuWNNN9E61zi/mBr5bzN
	9W6rPi6S7u6wk0Bi/3E/uLtCkVO6/vlqfjNy/x6RNEGnwCfSwWkvZdTwq/sG8ip5wPaX
	9tB7M9AcAgC6xXOmEpTogpMGgqov9iiHGo7HCJSes1GAldUYlRODQSg+lkSxbOfmtyJh
	yk+4aBaCUfmWSsueXWQLIoekdxK3HuV4qKd5Q+1af8+MBYmermSE/GZOBnSGARAqQ/Z7
	my8VzWTNjmYYL/oMbEd6etd0vUg7XapE7JhLKfE5oDLlxkrp6NKh+Bu2PmS9ltNNijaF
	TDMA==
MIME-Version: 1.0
Received: by 10.224.181.83 with SMTP id bx19mr5244802qab.79.1340363091692;
	Fri, 22 Jun 2012 04:04:51 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 04:04:51 -0700 (PDT)
Date: Fri, 22 Jun 2012 12:04:51 +0100
X-Google-Sender-Auth: _zv2u8cmw8OAhejTIo5-r_-CMHU
Message-ID: <CAFLBxZZL7D1W8bEPgdvP-e-yT8+yhnffpkGTK67EXht1oP_38w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Josh Holtrop <josh.holtrop@dornerworks.com>, 
	Kathy Hadley <kathy.hadley@dornerworks.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] arinc653 scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Josh / Kathy: Is Dornerworks still planning on maintaining the
arinc653 scheduler in-tree?  We're closing in on a 4.2 release, so if
you are, now might be a good time to test your scheduler again (and in
the 4.1 tree, as we have had a report of it not booting).  There have
been a number of changes to the scheduler lock design in the 4.2
development cycle, so it's quite possible something has broken.

If you're not interested in maintaining it in-tree, that's fine too;
just let us know.  In that case we'd probably remove it for the 4.2
release and you can carry it as an internal patch.

 -George

On Thu, Jun 21, 2012 at 10:10 PM, Tapdiya, Ashish
<ashish.tapdiya@vanderbilt.edu> wrote:
> Hi,
>
> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0. However, if I supply sched=credit (default) or sched=credit2, specified scheduler gets selected and dom0 boots perfectly fine. Not sure if it is a bug.
>
> Thanks,
> Ashish
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 22 11:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1fc-0005eo-AX; Fri, 22 Jun 2012 11:04:56 +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 1Si1fa-0005ej-QW
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:04:55 +0000
Received: from [85.158.138.51:36082] by server-1.bemta-3.messagelabs.com id
	E2/52-14648-65154EF4; Fri, 22 Jun 2012 11:04:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340363092!27895451!1
X-Originating-IP: [209.85.216.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1212 invoked from network); 22 Jun 2012 11:04:53 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:04:53 -0000
Received: by qcsd16 with SMTP id d16so900341qcs.28
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 04:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=LUTgVWVQdDjbR4dA6dybmOWjXm0pzeFhsA/KWaR+zko=;
	b=vg06XucllOYEwS0wobeH71kwewZOaCNbDkLqpZeOE5trAxbuWNNN9E61zi/mBr5bzN
	9W6rPi6S7u6wk0Bi/3E/uLtCkVO6/vlqfjNy/x6RNEGnwCfSwWkvZdTwq/sG8ip5wPaX
	9tB7M9AcAgC6xXOmEpTogpMGgqov9iiHGo7HCJSes1GAldUYlRODQSg+lkSxbOfmtyJh
	yk+4aBaCUfmWSsueXWQLIoekdxK3HuV4qKd5Q+1af8+MBYmermSE/GZOBnSGARAqQ/Z7
	my8VzWTNjmYYL/oMbEd6etd0vUg7XapE7JhLKfE5oDLlxkrp6NKh+Bu2PmS9ltNNijaF
	TDMA==
MIME-Version: 1.0
Received: by 10.224.181.83 with SMTP id bx19mr5244802qab.79.1340363091692;
	Fri, 22 Jun 2012 04:04:51 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 04:04:51 -0700 (PDT)
Date: Fri, 22 Jun 2012 12:04:51 +0100
X-Google-Sender-Auth: _zv2u8cmw8OAhejTIo5-r_-CMHU
Message-ID: <CAFLBxZZL7D1W8bEPgdvP-e-yT8+yhnffpkGTK67EXht1oP_38w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Josh Holtrop <josh.holtrop@dornerworks.com>, 
	Kathy Hadley <kathy.hadley@dornerworks.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] arinc653 scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Josh / Kathy: Is Dornerworks still planning on maintaining the
arinc653 scheduler in-tree?  We're closing in on a 4.2 release, so if
you are, now might be a good time to test your scheduler again (and in
the 4.1 tree, as we have had a report of it not booting).  There have
been a number of changes to the scheduler lock design in the 4.2
development cycle, so it's quite possible something has broken.

If you're not interested in maintaining it in-tree, that's fine too;
just let us know.  In that case we'd probably remove it for the 4.2
release and you can carry it as an internal patch.

 -George

On Thu, Jun 21, 2012 at 10:10 PM, Tapdiya, Ashish
<ashish.tapdiya@vanderbilt.edu> wrote:
> Hi,
>
> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0. However, if I supply sched=credit (default) or sched=credit2, specified scheduler gets selected and dom0 boots perfectly fine. Not sure if it is a bug.
>
> Thanks,
> Ashish
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 22 11:22:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:22: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 1Si1wi-0006sM-9J; Fri, 22 Jun 2012 11:22:36 +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 1Si1wh-0006s7-AV
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:22:35 +0000
Received: from [85.158.138.51:13056] by server-5.bemta-3.messagelabs.com id
	BA/CE-01572-A7554EF4; Fri, 22 Jun 2012 11:22:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340364153!27828755!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26600 invoked from network); 22 Jun 2012 11:22:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 11:22:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 12:22:33 +0100
Message-Id: <4FE471C4020000780008B5FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 12:23:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
In-Reply-To: <4FE44404.2020702@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/06/12 10:43, Jan Beulich wrote:
>>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> Following Jan's infrastructure to mark certain PCI devices as read only,
>>> I think it wise to now consider what other PCI devices should really be
>>> read only to dom0.
>>>
>>> My preliminary thoughts include:
>>>
>>> * PCI serial devices which Xen is configured to use
>> But only if they're single-function.
> 
> Why only single function?  Should Xen not turn all the functions it is
> using to read-only ?

Because, just like for normal, non-PCI based serial ones, ports
that Xen doesn't use should remain usable by Dom0. For
example, I have a PCI card with two serial and one parallel
ports, so with Xen using one serial port for itself, there's no
reason not to allow Dom0 to use the other or the parallel one.

>>> * Chipset devices (AMD IOMMU covered by previous patch)
>>> * Cpu information
>> What are you thinking of here specifically.
> 
> See attached lspci from a new sandybridge machine we have gained.  Quite
> a lot of that looks rather dangerous for dom0 to play around with.

But that can't be easily qualified into some rule, the more that
some of these - iirc - are needed e.g. by the EDAC drivers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:22:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:22: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 1Si1wi-0006sM-9J; Fri, 22 Jun 2012 11:22:36 +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 1Si1wh-0006s7-AV
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:22:35 +0000
Received: from [85.158.138.51:13056] by server-5.bemta-3.messagelabs.com id
	BA/CE-01572-A7554EF4; Fri, 22 Jun 2012 11:22:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340364153!27828755!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26600 invoked from network); 22 Jun 2012 11:22:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 11:22:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 12:22:33 +0100
Message-Id: <4FE471C4020000780008B5FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 12:23:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
In-Reply-To: <4FE44404.2020702@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/06/12 10:43, Jan Beulich wrote:
>>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> Following Jan's infrastructure to mark certain PCI devices as read only,
>>> I think it wise to now consider what other PCI devices should really be
>>> read only to dom0.
>>>
>>> My preliminary thoughts include:
>>>
>>> * PCI serial devices which Xen is configured to use
>> But only if they're single-function.
> 
> Why only single function?  Should Xen not turn all the functions it is
> using to read-only ?

Because, just like for normal, non-PCI based serial ones, ports
that Xen doesn't use should remain usable by Dom0. For
example, I have a PCI card with two serial and one parallel
ports, so with Xen using one serial port for itself, there's no
reason not to allow Dom0 to use the other or the parallel one.

>>> * Chipset devices (AMD IOMMU covered by previous patch)
>>> * Cpu information
>> What are you thinking of here specifically.
> 
> See attached lspci from a new sandybridge machine we have gained.  Quite
> a lot of that looks rather dangerous for dom0 to play around with.

But that can't be easily qualified into some rule, the more that
some of these - iirc - are needed e.g. by the EDAC drivers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:23:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1xO-0006xC-NV; Fri, 22 Jun 2012 11:23: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 1Si1xN-0006wu-4U
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:23:17 +0000
Received: from [85.158.139.83:52709] by server-11.bemta-5.messagelabs.com id
	84/26-20400-4A554EF4; Fri, 22 Jun 2012 11:23:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340364195!17724115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11081 invoked from network); 22 Jun 2012 11:23:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:23:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:23:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:23:15 +0100
Message-ID: <1340364194.26083.87.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 Jun 2012 12:23:14 +0100
In-Reply-To: <998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 11:56 +0100, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1340361703 -3600
> # Node ID 998d48ccb8905907cb2f104b475e5ab6ad445348
> # Parent  5fb3c536b5a8810fb8be4149df609d272beff959
> libxl: validate scheduler parameters
> 
> This was previously done by xl itself however the domain was not
> created at that point so there was no domid to check. This happened to
> work on first boot because xl's global domid was initialised to zero
> so we would (incorrectly) validate the new domain to be against
> domain0. On reboot though we would try to use the old domain's id and
> fail.
> 
> sched_params_valid is moved and gains a gc+domid parameters and
> s/ctx/CTX/. The call is placed after
> libxl__domain_build_info_setdefault in the create path, because
> set_defaults doesn't have access to the domid and there are other
> callers which don't even have a domid to give it.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

After consultation with Ian J and Dario I have committed this one in
order to get a test pass ASAP. I'll leave the remainder of this series
to get properly reviewed.

Ian.

> 
> diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Jun 22 10:14:46 2012 +0100
> +++ b/tools/libxl/libxl_create.c	Fri Jun 22 11:41:43 2012 +0100
> @@ -72,6 +72,49 @@ int libxl__domain_create_info_setdefault
>      return 0;
>  }
>  
> +static int sched_params_valid(libxl__gc *gc,
> +                              uint32_t domid, libxl_domain_sched_params *scp)
> +{
> +    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
> +    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
> +    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
> +    int has_extratime =
> +                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
> +    libxl_domain_sched_params sci;
> +
> +    libxl_domain_sched_params_get(CTX, domid, &sci);
> +
> +    /* The sedf scheduler needs some more consistency checking */
> +    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> +        if (has_weight && (has_period || has_slice))
> +            return 0;
> +        if (has_period != has_slice)
> +            return 0;
> +
> +        /*
> +         * Idea is, if we specify a weight, then both period and
> +         * slice has to be zero. OTOH, if we do not specify a weight,
> +         * that means we want a pure best effort domain or an actual
> +         * real-time one. In the former case, it is period that needs
> +         * to be zero, in the latter, weight should be.
> +         */
> +        if (has_weight) {
> +            scp->slice = 0;
> +            scp->period = 0;
> +        }
> +        else if (!has_period) {
> +            /* We can setup a proper best effort domain (extra time only)
> +             * iff we either already have or are asking for some extra time. */
> +            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> +            scp->period = 0;
> +        }
> +        if (has_period && has_slice)
> +            scp->weight = 0;
> +    }
> +
> +    return 1;
> +}
> +
>  int libxl__domain_build_info_setdefault(libxl__gc *gc,
>                                          libxl_domain_build_info *b_info)
>  {
> @@ -622,6 +665,12 @@ static void initiate_domain_create(libxl
>      ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
>      if (ret) goto error_out;
>  
> +    if (!sched_params_valid(gc, domid, &d_config->b_info.sched_params)) {
> +        LOG(ERROR, "Invalid scheduling parameters\n");
> +        ret = ERROR_INVAL;
> +        goto error_out;
> +    }
> +
>      for (i = 0; i < d_config->num_disks; i++) {
>          ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
>          if (ret) goto error_out;
> diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri Jun 22 10:14:46 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:41:43 2012 +0100
> @@ -550,48 +550,6 @@ vcpp_out:
>      return rc;
>  }
>  
> -static int sched_params_valid(libxl_domain_sched_params *scp)
> -{
> -    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
> -    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
> -    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
> -    int has_extratime =
> -                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
> -    libxl_domain_sched_params sci;
> -
> -    libxl_domain_sched_params_get(ctx, domid, &sci);
> -
> -    /* The sedf scheduler needs some more consistency checking */
> -    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> -        if (has_weight && (has_period || has_slice))
> -            return 0;
> -        if (has_period != has_slice)
> -            return 0;
> -
> -        /*
> -         * Idea is, if we specify a weight, then both period and
> -         * slice has to be zero. OTOH, if we do not specify a weight,
> -         * that means we want a pure best effort domain or an actual
> -         * real-time one. In the former case, it is period that needs
> -         * to be zero, in the latter, weight should be.
> -         */
> -        if (has_weight) {
> -            scp->slice = 0;
> -            scp->period = 0;
> -        }
> -        else if (!has_period) {
> -            /* We can setup a proper best effort domain (extra time only)
> -             * iff we either already have or are asking for some extra time. */
> -            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> -            scp->period = 0;
> -        }
> -        if (has_period && has_slice)
> -            scp->weight = 0;
> -    }
> -
> -    return 1;
> -}
> -
>  static void parse_config_data(const char *config_source,
>                                const char *config_data,
>                                int config_len,
> @@ -686,10 +644,6 @@ static void parse_config_data(const char
>          b_info->sched_params.latency = l;
>      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
>          b_info->sched_params.extratime = l;
> -    if (!sched_params_valid(&b_info->sched_params)) {
> -        fprintf(stderr, "Invalid scheduling parameters\n");
> -        exit(1);
> -    }
>  
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 22 11:23:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si1xO-0006xC-NV; Fri, 22 Jun 2012 11:23: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 1Si1xN-0006wu-4U
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:23:17 +0000
Received: from [85.158.139.83:52709] by server-11.bemta-5.messagelabs.com id
	84/26-20400-4A554EF4; Fri, 22 Jun 2012 11:23:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340364195!17724115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11081 invoked from network); 22 Jun 2012 11:23:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:23:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:23:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:23:15 +0100
Message-ID: <1340364194.26083.87.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 Jun 2012 12:23:14 +0100
In-Reply-To: <998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 11:56 +0100, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1340361703 -3600
> # Node ID 998d48ccb8905907cb2f104b475e5ab6ad445348
> # Parent  5fb3c536b5a8810fb8be4149df609d272beff959
> libxl: validate scheduler parameters
> 
> This was previously done by xl itself however the domain was not
> created at that point so there was no domid to check. This happened to
> work on first boot because xl's global domid was initialised to zero
> so we would (incorrectly) validate the new domain to be against
> domain0. On reboot though we would try to use the old domain's id and
> fail.
> 
> sched_params_valid is moved and gains a gc+domid parameters and
> s/ctx/CTX/. The call is placed after
> libxl__domain_build_info_setdefault in the create path, because
> set_defaults doesn't have access to the domid and there are other
> callers which don't even have a domid to give it.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

After consultation with Ian J and Dario I have committed this one in
order to get a test pass ASAP. I'll leave the remainder of this series
to get properly reviewed.

Ian.

> 
> diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Jun 22 10:14:46 2012 +0100
> +++ b/tools/libxl/libxl_create.c	Fri Jun 22 11:41:43 2012 +0100
> @@ -72,6 +72,49 @@ int libxl__domain_create_info_setdefault
>      return 0;
>  }
>  
> +static int sched_params_valid(libxl__gc *gc,
> +                              uint32_t domid, libxl_domain_sched_params *scp)
> +{
> +    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
> +    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
> +    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
> +    int has_extratime =
> +                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
> +    libxl_domain_sched_params sci;
> +
> +    libxl_domain_sched_params_get(CTX, domid, &sci);
> +
> +    /* The sedf scheduler needs some more consistency checking */
> +    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> +        if (has_weight && (has_period || has_slice))
> +            return 0;
> +        if (has_period != has_slice)
> +            return 0;
> +
> +        /*
> +         * Idea is, if we specify a weight, then both period and
> +         * slice has to be zero. OTOH, if we do not specify a weight,
> +         * that means we want a pure best effort domain or an actual
> +         * real-time one. In the former case, it is period that needs
> +         * to be zero, in the latter, weight should be.
> +         */
> +        if (has_weight) {
> +            scp->slice = 0;
> +            scp->period = 0;
> +        }
> +        else if (!has_period) {
> +            /* We can setup a proper best effort domain (extra time only)
> +             * iff we either already have or are asking for some extra time. */
> +            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> +            scp->period = 0;
> +        }
> +        if (has_period && has_slice)
> +            scp->weight = 0;
> +    }
> +
> +    return 1;
> +}
> +
>  int libxl__domain_build_info_setdefault(libxl__gc *gc,
>                                          libxl_domain_build_info *b_info)
>  {
> @@ -622,6 +665,12 @@ static void initiate_domain_create(libxl
>      ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
>      if (ret) goto error_out;
>  
> +    if (!sched_params_valid(gc, domid, &d_config->b_info.sched_params)) {
> +        LOG(ERROR, "Invalid scheduling parameters\n");
> +        ret = ERROR_INVAL;
> +        goto error_out;
> +    }
> +
>      for (i = 0; i < d_config->num_disks; i++) {
>          ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
>          if (ret) goto error_out;
> diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri Jun 22 10:14:46 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 22 11:41:43 2012 +0100
> @@ -550,48 +550,6 @@ vcpp_out:
>      return rc;
>  }
>  
> -static int sched_params_valid(libxl_domain_sched_params *scp)
> -{
> -    int has_weight = scp->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT;
> -    int has_period = scp->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT;
> -    int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
> -    int has_extratime =
> -                scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
> -    libxl_domain_sched_params sci;
> -
> -    libxl_domain_sched_params_get(ctx, domid, &sci);
> -
> -    /* The sedf scheduler needs some more consistency checking */
> -    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> -        if (has_weight && (has_period || has_slice))
> -            return 0;
> -        if (has_period != has_slice)
> -            return 0;
> -
> -        /*
> -         * Idea is, if we specify a weight, then both period and
> -         * slice has to be zero. OTOH, if we do not specify a weight,
> -         * that means we want a pure best effort domain or an actual
> -         * real-time one. In the former case, it is period that needs
> -         * to be zero, in the latter, weight should be.
> -         */
> -        if (has_weight) {
> -            scp->slice = 0;
> -            scp->period = 0;
> -        }
> -        else if (!has_period) {
> -            /* We can setup a proper best effort domain (extra time only)
> -             * iff we either already have or are asking for some extra time. */
> -            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> -            scp->period = 0;
> -        }
> -        if (has_period && has_slice)
> -            scp->weight = 0;
> -    }
> -
> -    return 1;
> -}
> -
>  static void parse_config_data(const char *config_source,
>                                const char *config_data,
>                                int config_len,
> @@ -686,10 +644,6 @@ static void parse_config_data(const char
>          b_info->sched_params.latency = l;
>      if (!xlu_cfg_get_long (config, "extratime", &l, 0))
>          b_info->sched_params.extratime = l;
> -    if (!sched_params_valid(&b_info->sched_params)) {
> -        fprintf(stderr, "Invalid scheduling parameters\n");
> -        exit(1);
> -    }
>  
>      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
>          b_info->max_vcpus = l;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 22 11:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si23T-0007Nj-H8; Fri, 22 Jun 2012 11:29: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 1Si23S-0007Nc-4e
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:29:34 +0000
Received: from [85.158.138.51:10843] by server-11.bemta-3.messagelabs.com id
	2F/67-02904-D1754EF4; Fri, 22 Jun 2012 11:29:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340364572!24968512!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 22 Jun 2012 11:29:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 11:29:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 12:29:32 +0100
Message-Id: <4FE47368020000780008B60F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 12:30:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
In-Reply-To: <4FE44404.2020702@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/06/12 10:43, Jan Beulich wrote:
>> Perhaps, but that's not the only thing to deal with here. As
>> said previously, when we want to add devices with active BARs
>> here (luckily Wei confirmed that AMD IOMMUs have none),
>> Dom0 trying to re-configure them would get us into problems.
>> The issue exists today, but could become worse when we
>> disallow the updates (as that could lead to two devices sharing
>> resources they shouldn't share, whereas today a device in use
>> by Xen and getting re-assigned its resources would merely stop
>> working).
> 
> It is certainly not an easy problem, and perhaps I am needlessly
> complicating the issue.
> 
> It occurs that we have 3 possible directions to fix this issue.
> 
> 1) Continue the current method of fixing things up after they break,
> which can cause a hassle for a user encountering the issue.
> 2) Mark as RO and provide an explicit hypercall interface to remap
> BARs.  I don't know how well this would go with upstream Linux.

And what would the hypercall do? You don't expect it to fix up
all the uses of the old address(es) to now use the new one(s),
do you? Leaving aside the difficulty in getting this right, in some
cases this might not even be possible in a seamless manner.

> 3) Extend current infrastructure to be able to tell when a write is
> affecting the BARs and permit them.  This seems like the best option
> going forward, but might be quite hard to implement.

Doing the mechanical trap-and-emulate part of this shouldn't
be that hard, namely on top of that other patch I'm about to
commit.

But the thing is that this has the same problems as the hypercall
one above.

> I guess the real question is whether we should continue reactively
> fixing problems, or start protectively fixing the root cause.

I agree with this position from a theoretical standpoint.

>  My gut
> feeling is that we are going to start seeing more and more devices on
> the PCI bus which Xen should be using, rather than dom0.

That would be bad - surfacing arbitrary devices on the PCI bus
is - in my opinion - rather questionable a design (which is also
why I consider this aspect of the AMD IOMMUs badly designed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si23T-0007Nj-H8; Fri, 22 Jun 2012 11:29: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 1Si23S-0007Nc-4e
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:29:34 +0000
Received: from [85.158.138.51:10843] by server-11.bemta-3.messagelabs.com id
	2F/67-02904-D1754EF4; Fri, 22 Jun 2012 11:29:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340364572!24968512!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 22 Jun 2012 11:29:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 11:29:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 12:29:32 +0100
Message-Id: <4FE47368020000780008B60F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 12:30:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
In-Reply-To: <4FE44404.2020702@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/06/12 10:43, Jan Beulich wrote:
>> Perhaps, but that's not the only thing to deal with here. As
>> said previously, when we want to add devices with active BARs
>> here (luckily Wei confirmed that AMD IOMMUs have none),
>> Dom0 trying to re-configure them would get us into problems.
>> The issue exists today, but could become worse when we
>> disallow the updates (as that could lead to two devices sharing
>> resources they shouldn't share, whereas today a device in use
>> by Xen and getting re-assigned its resources would merely stop
>> working).
> 
> It is certainly not an easy problem, and perhaps I am needlessly
> complicating the issue.
> 
> It occurs that we have 3 possible directions to fix this issue.
> 
> 1) Continue the current method of fixing things up after they break,
> which can cause a hassle for a user encountering the issue.
> 2) Mark as RO and provide an explicit hypercall interface to remap
> BARs.  I don't know how well this would go with upstream Linux.

And what would the hypercall do? You don't expect it to fix up
all the uses of the old address(es) to now use the new one(s),
do you? Leaving aside the difficulty in getting this right, in some
cases this might not even be possible in a seamless manner.

> 3) Extend current infrastructure to be able to tell when a write is
> affecting the BARs and permit them.  This seems like the best option
> going forward, but might be quite hard to implement.

Doing the mechanical trap-and-emulate part of this shouldn't
be that hard, namely on top of that other patch I'm about to
commit.

But the thing is that this has the same problems as the hypercall
one above.

> I guess the real question is whether we should continue reactively
> fixing problems, or start protectively fixing the root cause.

I agree with this position from a theoretical standpoint.

>  My gut
> feeling is that we are going to start seeing more and more devices on
> the PCI bus which Xen should be using, rather than dom0.

That would be bad - surfacing arbitrary devices on the PCI bus
is - in my opinion - rather questionable a design (which is also
why I consider this aspect of the AMD IOMMUs badly designed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:30:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:30: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 1Si24U-0007Si-03; Fri, 22 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1Si24S-0007SW-5j
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 11:30:36 +0000
Received: from [85.158.139.83:53864] by server-7.bemta-5.messagelabs.com id
	73/DC-28276-B5754EF4; Fri, 22 Jun 2012 11:30:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340364634!28896633!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28315 invoked from network); 22 Jun 2012 11:30:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:30:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:30:33 +0100
Message-ID: <1340364632.26083.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Fri, 22 Jun 2012 12:30:32 +0100
In-Reply-To: <CAGj-7pVyZZ=VQ566fvENhKJ58v=F+3Ub0hsTuY3d0ao7FtwZhQ@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<1340193230.4906.45.camel@zakaz.uk.xensource.com>
	<CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
	<CAGj-7pVyZZ=VQ566fvENhKJ58v=F+3Ub0hsTuY3d0ao7FtwZhQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post, makes it harder to follow the conversation.

On Thu, 2012-06-21 at 19:17 +0100, Shakeel Butt wrote:
> I have messed up my copy/paste on details of netback-domU and
> other-domU. So, for these two the clear details are below:
> 
> Detail of netback-domU:
> -----------------------
[...]
> Detail of other-domU:
> -----------------------
[...]

So if I understand correctly netback-domU's route to the outside world
if via a virtual interface connected to dom0 -- is that right?

If so then I'm afraid I think this doesn't work -- you can bridge
several netback devices together or you can bridge netfront devices
together but in the current implementation of netfront/netback I believe
it is not possible to bridge a mixture of the two.

The reason is that the netfront/back protocol currently does not make
use of "transitive grants" which are necessary for the netback-domU
domain to forward pages from a netfront to the netback running in dom0.
Trying to forward in this way without using a "transitive grant" is what
results in your original "grant_table.c:387:d0 Could not pin grant frame
9d44e" message. I'm afraid I don't know of anyone who is currently
working on implementing this feature.

The more normal configuration (which is what I thought you were using at
first) would be to pass a physical NIC to netback-domU using PCI
passthrough and then optionally create a VIF on dom0 in order to give it
access. Perhaps that would be suitable for your usecase?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:30:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:30: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 1Si24U-0007Si-03; Fri, 22 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1Si24S-0007SW-5j
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 11:30:36 +0000
Received: from [85.158.139.83:53864] by server-7.bemta-5.messagelabs.com id
	73/DC-28276-B5754EF4; Fri, 22 Jun 2012 11:30:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340364634!28896633!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28315 invoked from network); 22 Jun 2012 11:30:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:30:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:30:33 +0100
Message-ID: <1340364632.26083.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Fri, 22 Jun 2012 12:30:32 +0100
In-Reply-To: <CAGj-7pVyZZ=VQ566fvENhKJ58v=F+3Ub0hsTuY3d0ao7FtwZhQ@mail.gmail.com>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<1340193230.4906.45.camel@zakaz.uk.xensource.com>
	<CAGj-7pW7N-RmaFeD7htny-if0LyKZYUzfyt0VyYPB8TDHHeQsw@mail.gmail.com>
	<CAGj-7pVyZZ=VQ566fvENhKJ58v=F+3Ub0hsTuY3d0ao7FtwZhQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post, makes it harder to follow the conversation.

On Thu, 2012-06-21 at 19:17 +0100, Shakeel Butt wrote:
> I have messed up my copy/paste on details of netback-domU and
> other-domU. So, for these two the clear details are below:
> 
> Detail of netback-domU:
> -----------------------
[...]
> Detail of other-domU:
> -----------------------
[...]

So if I understand correctly netback-domU's route to the outside world
if via a virtual interface connected to dom0 -- is that right?

If so then I'm afraid I think this doesn't work -- you can bridge
several netback devices together or you can bridge netfront devices
together but in the current implementation of netfront/netback I believe
it is not possible to bridge a mixture of the two.

The reason is that the netfront/back protocol currently does not make
use of "transitive grants" which are necessary for the netback-domU
domain to forward pages from a netfront to the netback running in dom0.
Trying to forward in this way without using a "transitive grant" is what
results in your original "grant_table.c:387:d0 Could not pin grant frame
9d44e" message. I'm afraid I don't know of anyone who is currently
working on implementing this feature.

The more normal configuration (which is what I thought you were using at
first) would be to pass a physical NIC to netback-domU using PCI
passthrough and then optionally create a VIF on dom0 in order to give it
access. Perhaps that would be suitable for your usecase?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:33:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si27D-0007oY-D8; Fri, 22 Jun 2012 11:33:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si27B-0007oG-Gp
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:33:25 +0000
Received: from [85.158.143.35:41374] by server-1.bemta-4.messagelabs.com id
	EF/85-24392-40854EF4; Fri, 22 Jun 2012 11:33:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340364804!5694447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 22 Jun 2012 11:33:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:33:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11: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.213.0; Fri, 22 Jun 2012 12:33:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si270-0003R4-Sh; Fri, 22 Jun 2012 11:33:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si270-0005PB-Rq;
	Fri, 22 Jun 2012 12:33:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22522.766301.170343@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:33:14 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-7-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
	libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op"):
> This patch converts libxl_device_disk_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
                  ^^^^^^
later

> we reached the desired xenbus state.

Thanks, here are my review comments:


> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 85c21b4..937ab08 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
...
> +/* AO operation to connect a disk device, called by
> + * libxl_device_disk_add and libxl__add_disks. This function calls
> + * libxl__initiate_device_connection to wait for the device to
> + * finish the connection (might involve executing hotplug scripts).
> + */
> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
> +                                    xs_transaction_t t,
> +                                    libxl_device_disk *disk,
> +                                    libxl__ao_device *aodev);
> +

This is a confusing doc comment.  The reader doesn't want to know how
the function is implemented; we need to know what it does.
Particularly, we need to know what happens when it completes.  I infer
that it calls aodev->callback but this should be stated.

> +/* Waits for the passed device to reach state XenbusStateInitWait.
> + * This is not really useful by itself, but is important when executing
> + * hotplug scripts, since we need to be sure the device is in the correct
> + * state before executing them.
> + *
> + * Once finished, aodev->callback will be executed.
> + */
> +_hidden void libxl__initiate_device_connection(libxl__egc*,
> +                                               libxl__ao_device *aodev);

This function's name and its functionality seem not to correspond.  It
doesn't actually initiate anything, as far as I can tell.

>  /* First layer; wraps libxl__spawn_spawn. */
> @@ -2033,6 +2068,8 @@ typedef struct {
>      libxl__domain_build_state dm_state;
>      libxl__dm_spawn_state pvqemu;
>      libxl__destroy_domid_state dis;
> +    /* used to store the state of devices being connected */
> +    libxl__ao_devices aodevs;
>  } libxl__stub_dm_spawn_state;

I'm not sure how valuable these comments are.  libxl__ao_devices are
always used to store the state of devices being "<something>'d".
That's what a libxl__ao_devices is for.  And in the context of a spawn
or create that would obviously be "connected".

In general I'm a fan of comments which say things which aren't clear
from the code, but I'm not keen on ones which restate what the code
says.


> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 9243806..5d34ed5 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -442,6 +442,45 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>      return;
>  }
> 
> +/******************************************************************************/
> +
> +/* Macro for defining the functions that will add a bunch of disks when
> + * inside an async op.
> + *
> + * This macro is added to prevent repetition of code.
> + */
> +
> +/* Capatibility macro, since disk_add now takes a xs transaction parameter */
> +#define libxl__device_disk_add(egc, domid, disk, aodev)                       \
> +        libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)

Is it really safe to call libxl__device_disk_add without a real
transaction ?  I see that the current code does it but it seems wrong
to me.  We end up writing all of the individual settings in the
backend one at a time.

I think this applies to all the other device types too.  So I think
the right answer would be to make them take a transaction parameter
too.  Ie, insert a patch before this one which adds a transaction
parameter (ignored for now and always passed 0 if you don't want to
actually make it work properly) to libxl__add_nic etc.  Then you don't
need this unpleasant macro.

> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
> +{
> +    STATE_AO_GC(aodev->ao);
> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> +    int rc = 0;
...
> +out_fail:
> +    assert(rc);
> +    aodev->rc = rc;
> +    device_xsentries_remove(egc, aodev);
> +    return;
> +}

Firstly, I'm not convinced it's really proper for
libxl__initiate_device_connection to call device_xsentries_remove.
After all device_xsentries_remove is part of the implementation of
libxl__initiate_device_remove.

And, secondly, does device_xsentries_remove really do what you want ?
It has a test in it which makes it only do its work if action is
DISCONNECT.


> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 43affd1..5f09740 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c


> @@ -2027,15 +2046,17 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,

> +                dls->t = xs_transaction_start(ctx->xsh);
> +                if (dls->t == XBT_NULL) {
> +                    LOG(ERROR, "failed to start a xenstore transaction");
> +                    rc = ERROR_FAIL;
> +                    goto out;
> +                }
> +                disk->vdev = libxl__alloc_vdev(gc, blkdev_start, dls->t);
...
> +                libxl__device_disk_add(egc, LIBXL_TOOLSTACK_DOMID,
> +                                       dls->t, disk, &dls->aodev);
...
> +    xs_ret = xs_transaction_end(ctx->xsh, dls->t, 0);
> +    if (xs_ret == 0 && errno == EAGAIN) {
> +        libxl__device_disk_local_attach(egc, dls);
> +        return;

Isn't the effect of this that if the xs transaction gets a conflict,
we'll rerun the hotplug scripts, etc. ?  I think I may be confused
here, but I don't understand how this transaction loop is supposed to
work and how it is supposed to relate to the interaction with other
domains, scripts, etc.

Indeed it seems to me like your arrangements in libxl__device_disk_add
couldn't work if a non-null t was supplied.  libxl__device_disk_add
would do all the writes in the transaction, but not commit it, so that
none of them are visible to anyone, and then wait for the deivde state
to change, which will never happen.


>  static void libxl__device_disk_from_xs_be(libxl__gc *gc,
> @@ -1982,11 +1999,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>      ret = 0;
> 
>      libxl_device_disk_remove(ctx, domid, disks + i, 0);
> -    libxl_device_disk_add(ctx, domid, disk);
> +    /* fixme-ao */
> +    libxl_device_disk_add(ctx, domid, disk, 0);
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
>      if (stubdomid) {
>          libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
> -        libxl_device_disk_add(ctx, stubdomid, disk);
> +        /* fixme-ao */
> +        libxl_device_disk_add(ctx, stubdomid, disk, 0);

I think this code is a symptom of a problem elsewhere.  When adding a
disk to a domain, it should not be necessary to explicitly ask to add
it to the stubdom too.  But this is not your fault, or your problem
right now.


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 Jun 22 11:33:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si27D-0007oY-D8; Fri, 22 Jun 2012 11:33:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si27B-0007oG-Gp
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:33:25 +0000
Received: from [85.158.143.35:41374] by server-1.bemta-4.messagelabs.com id
	EF/85-24392-40854EF4; Fri, 22 Jun 2012 11:33:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340364804!5694447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 22 Jun 2012 11:33:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:33:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11: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.213.0; Fri, 22 Jun 2012 12:33:15 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si270-0003R4-Sh; Fri, 22 Jun 2012 11:33:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si270-0005PB-Rq;
	Fri, 22 Jun 2012 12:33:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22522.766301.170343@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:33:14 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-7-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
	libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op"):
> This patch converts libxl_device_disk_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
                  ^^^^^^
later

> we reached the desired xenbus state.

Thanks, here are my review comments:


> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 85c21b4..937ab08 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
...
> +/* AO operation to connect a disk device, called by
> + * libxl_device_disk_add and libxl__add_disks. This function calls
> + * libxl__initiate_device_connection to wait for the device to
> + * finish the connection (might involve executing hotplug scripts).
> + */
> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
> +                                    xs_transaction_t t,
> +                                    libxl_device_disk *disk,
> +                                    libxl__ao_device *aodev);
> +

This is a confusing doc comment.  The reader doesn't want to know how
the function is implemented; we need to know what it does.
Particularly, we need to know what happens when it completes.  I infer
that it calls aodev->callback but this should be stated.

> +/* Waits for the passed device to reach state XenbusStateInitWait.
> + * This is not really useful by itself, but is important when executing
> + * hotplug scripts, since we need to be sure the device is in the correct
> + * state before executing them.
> + *
> + * Once finished, aodev->callback will be executed.
> + */
> +_hidden void libxl__initiate_device_connection(libxl__egc*,
> +                                               libxl__ao_device *aodev);

This function's name and its functionality seem not to correspond.  It
doesn't actually initiate anything, as far as I can tell.

>  /* First layer; wraps libxl__spawn_spawn. */
> @@ -2033,6 +2068,8 @@ typedef struct {
>      libxl__domain_build_state dm_state;
>      libxl__dm_spawn_state pvqemu;
>      libxl__destroy_domid_state dis;
> +    /* used to store the state of devices being connected */
> +    libxl__ao_devices aodevs;
>  } libxl__stub_dm_spawn_state;

I'm not sure how valuable these comments are.  libxl__ao_devices are
always used to store the state of devices being "<something>'d".
That's what a libxl__ao_devices is for.  And in the context of a spawn
or create that would obviously be "connected".

In general I'm a fan of comments which say things which aren't clear
from the code, but I'm not keen on ones which restate what the code
says.


> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 9243806..5d34ed5 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -442,6 +442,45 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>      return;
>  }
> 
> +/******************************************************************************/
> +
> +/* Macro for defining the functions that will add a bunch of disks when
> + * inside an async op.
> + *
> + * This macro is added to prevent repetition of code.
> + */
> +
> +/* Capatibility macro, since disk_add now takes a xs transaction parameter */
> +#define libxl__device_disk_add(egc, domid, disk, aodev)                       \
> +        libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)

Is it really safe to call libxl__device_disk_add without a real
transaction ?  I see that the current code does it but it seems wrong
to me.  We end up writing all of the individual settings in the
backend one at a time.

I think this applies to all the other device types too.  So I think
the right answer would be to make them take a transaction parameter
too.  Ie, insert a patch before this one which adds a transaction
parameter (ignored for now and always passed 0 if you don't want to
actually make it work properly) to libxl__add_nic etc.  Then you don't
need this unpleasant macro.

> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
> +{
> +    STATE_AO_GC(aodev->ao);
> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> +    int rc = 0;
...
> +out_fail:
> +    assert(rc);
> +    aodev->rc = rc;
> +    device_xsentries_remove(egc, aodev);
> +    return;
> +}

Firstly, I'm not convinced it's really proper for
libxl__initiate_device_connection to call device_xsentries_remove.
After all device_xsentries_remove is part of the implementation of
libxl__initiate_device_remove.

And, secondly, does device_xsentries_remove really do what you want ?
It has a test in it which makes it only do its work if action is
DISCONNECT.


> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 43affd1..5f09740 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c


> @@ -2027,15 +2046,17 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,

> +                dls->t = xs_transaction_start(ctx->xsh);
> +                if (dls->t == XBT_NULL) {
> +                    LOG(ERROR, "failed to start a xenstore transaction");
> +                    rc = ERROR_FAIL;
> +                    goto out;
> +                }
> +                disk->vdev = libxl__alloc_vdev(gc, blkdev_start, dls->t);
...
> +                libxl__device_disk_add(egc, LIBXL_TOOLSTACK_DOMID,
> +                                       dls->t, disk, &dls->aodev);
...
> +    xs_ret = xs_transaction_end(ctx->xsh, dls->t, 0);
> +    if (xs_ret == 0 && errno == EAGAIN) {
> +        libxl__device_disk_local_attach(egc, dls);
> +        return;

Isn't the effect of this that if the xs transaction gets a conflict,
we'll rerun the hotplug scripts, etc. ?  I think I may be confused
here, but I don't understand how this transaction loop is supposed to
work and how it is supposed to relate to the interaction with other
domains, scripts, etc.

Indeed it seems to me like your arrangements in libxl__device_disk_add
couldn't work if a non-null t was supplied.  libxl__device_disk_add
would do all the writes in the transaction, but not commit it, so that
none of them are visible to anyone, and then wait for the deivde state
to change, which will never happen.


>  static void libxl__device_disk_from_xs_be(libxl__gc *gc,
> @@ -1982,11 +1999,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>      ret = 0;
> 
>      libxl_device_disk_remove(ctx, domid, disks + i, 0);
> -    libxl_device_disk_add(ctx, domid, disk);
> +    /* fixme-ao */
> +    libxl_device_disk_add(ctx, domid, disk, 0);
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
>      if (stubdomid) {
>          libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
> -        libxl_device_disk_add(ctx, stubdomid, disk);
> +        /* fixme-ao */
> +        libxl_device_disk_add(ctx, stubdomid, disk, 0);

I think this code is a symptom of a problem elsewhere.  When adding a
disk to a domain, it should not be necessary to explicitly ask to add
it to the stubdom too.  But this is not your fault, or your problem
right now.


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 Jun 22 11:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2Bu-0008Bo-4S; Fri, 22 Jun 2012 11:38: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 1Si2Bt-0008Bj-Fd
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:38:17 +0000
Received: from [85.158.143.35:10771] by server-1.bemta-4.messagelabs.com id
	6D/CD-24392-82954EF4; Fri, 22 Jun 2012 11:38:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340365094!15795819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11825 invoked from network); 22 Jun 2012 11:38:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:37:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:37:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2BW-0003Tb-GN; Fri, 22 Jun 2012 11:37:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2BW-0005PR-C3;
	Fri, 22 Jun 2012 12:37:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22802.102071.107153@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:37:54 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-8-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
> This patch converts libxl_device_nic_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.
> 
> Calls to libxl_device_nic_add have also been moved to occur after the
> device model has been launched, so when hotplug scripts are called
> from this functions the interfaces already exists.
> 
> As usual, libxl_device_nic_add callers have been modified, and the
> internal function libxl__device_disk_add has been used if the call was
> inside an already running ao.

This all looks reasonable to me.  But seeing this:

> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 5d34ed5..f7217aa 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -454,8 +454,8 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>  #define libxl__device_disk_add(egc, domid, disk, aodev)                       \
>          libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
> 
> -#define DEFINE_DEVICES_ADD(type)                                              \
> -    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
> +#define DEFINE_DEVICES_ADD(type, name)                                        \
> +    void libxl__add_##name##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
>                                libxl_domain_config *d_config,                  \
>                                libxl__ao_devices *aodevs,                      \
>                                libxl__devices_callback *callback)              \
> @@ -469,12 +469,13 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>                                                                                \
>          for (i = 0; i < aodevs->size; i++) {                                  \
>              aodevs->array[i].callback = libxl__ao_devices_callback;           \
> -            libxl__device_##type##_add(egc, domid, &d_config->type##s[i],     \
> +            libxl__device_##name##_add(egc, domid, &d_config->type##s[i],     \
>                                         &aodevs->array[i]);                    \
>          }                                                                     \
>      }
> 
> -DEFINE_DEVICES_ADD(disk)
> +DEFINE_DEVICES_ADD(disk, disk)
> +DEFINE_DEVICES_ADD(vif, nic)

it seems to me that this is an anomaly which might be better fixed
than worked around.

Should we rename the functions libxl_*nic* or the structures *vif* ?
Or should we rename both, to "net" perhaps ?


In any case,

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 Fri Jun 22 11:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2Bu-0008Bo-4S; Fri, 22 Jun 2012 11:38: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 1Si2Bt-0008Bj-Fd
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:38:17 +0000
Received: from [85.158.143.35:10771] by server-1.bemta-4.messagelabs.com id
	6D/CD-24392-82954EF4; Fri, 22 Jun 2012 11:38:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340365094!15795819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11825 invoked from network); 22 Jun 2012 11:38:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:37:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:37:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2BW-0003Tb-GN; Fri, 22 Jun 2012 11:37:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2BW-0005PR-C3;
	Fri, 22 Jun 2012 12:37:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22802.102071.107153@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:37:54 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-8-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
> This patch converts libxl_device_nic_add to an ao operation that
> waits for device backend to reach state XenbusStateInitWait and then
> marks the operation as completed. This is not really useful now, but
> will be used by latter patches that will launch hotplug scripts after
> we reached the desired xenbus state.
> 
> Calls to libxl_device_nic_add have also been moved to occur after the
> device model has been launched, so when hotplug scripts are called
> from this functions the interfaces already exists.
> 
> As usual, libxl_device_nic_add callers have been modified, and the
> internal function libxl__device_disk_add has been used if the call was
> inside an already running ao.

This all looks reasonable to me.  But seeing this:

> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 5d34ed5..f7217aa 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -454,8 +454,8 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>  #define libxl__device_disk_add(egc, domid, disk, aodev)                       \
>          libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
> 
> -#define DEFINE_DEVICES_ADD(type)                                              \
> -    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
> +#define DEFINE_DEVICES_ADD(type, name)                                        \
> +    void libxl__add_##name##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
>                                libxl_domain_config *d_config,                  \
>                                libxl__ao_devices *aodevs,                      \
>                                libxl__devices_callback *callback)              \
> @@ -469,12 +469,13 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>                                                                                \
>          for (i = 0; i < aodevs->size; i++) {                                  \
>              aodevs->array[i].callback = libxl__ao_devices_callback;           \
> -            libxl__device_##type##_add(egc, domid, &d_config->type##s[i],     \
> +            libxl__device_##name##_add(egc, domid, &d_config->type##s[i],     \
>                                         &aodevs->array[i]);                    \
>          }                                                                     \
>      }
> 
> -DEFINE_DEVICES_ADD(disk)
> +DEFINE_DEVICES_ADD(disk, disk)
> +DEFINE_DEVICES_ADD(vif, nic)

it seems to me that this is an anomaly which might be better fixed
than worked around.

Should we rename the functions libxl_*nic* or the structures *vif* ?
Or should we rename both, to "net" perhaps ?


In any case,

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 Fri Jun 22 11:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2Cr-0008GV-Id; Fri, 22 Jun 2012 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 <Ian.Jackson@eu.citrix.com>) id 1Si2Cq-0008GH-AO
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:39:16 +0000
Received: from [85.158.143.35:16960] by server-3.bemta-4.messagelabs.com id
	C7/FE-05808-36954EF4; Fri, 22 Jun 2012 11:39:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340365154!13566826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1225 invoked from network); 22 Jun 2012 11:39:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:39:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:39:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:39:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2Co-0003U0-Gx; Fri, 22 Jun 2012 11:39:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2Co-0005Pj-GG;
	Fri, 22 Jun 2012 12:39:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22882.490383.79784@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:39:14 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-10-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-10-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 09/13] libxl: rename _IOEMU nic type to
	VIF_IOEMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 09/13] libxl: rename _IOEMU nic type to VIF_IOEMU"):
> This change will avoid the confusion caused by the fact that IOEMU
> means both PV and TAP network interfaces.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2Cr-0008GV-Id; Fri, 22 Jun 2012 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 <Ian.Jackson@eu.citrix.com>) id 1Si2Cq-0008GH-AO
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:39:16 +0000
Received: from [85.158.143.35:16960] by server-3.bemta-4.messagelabs.com id
	C7/FE-05808-36954EF4; Fri, 22 Jun 2012 11:39:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340365154!13566826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1225 invoked from network); 22 Jun 2012 11:39:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:39:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:39:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:39:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2Co-0003U0-Gx; Fri, 22 Jun 2012 11:39:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2Co-0005Pj-GG;
	Fri, 22 Jun 2012 12:39:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22882.490383.79784@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:39:14 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-10-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-10-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 09/13] libxl: rename _IOEMU nic type to
	VIF_IOEMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 09/13] libxl: rename _IOEMU nic type to VIF_IOEMU"):
> This change will avoid the confusion caused by the fact that IOEMU
> means both PV and TAP network interfaces.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2D9-0008Iv-07; Fri, 22 Jun 2012 11:39:35 +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 1Si2D6-0008IY-RW
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 11:39:33 +0000
Received: from [193.109.254.147:16462] by server-2.bemta-14.messagelabs.com id
	0D/96-01735-47954EF4; Fri, 22 Jun 2012 11:39:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340365171!11149997!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23754 invoked from network); 22 Jun 2012 11:39:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	22 Jun 2012 11:39:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 12:39:30 +0100
Message-Id: <4FE475BE020000780008B624@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 12:40:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 12:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 20.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> Recently we design xen vMCE as attached.
>>> Please kindly help me to review it, any comments/suggestions are
>>> appreciated.
>> 
>> The concept looks quite okay, provided no OS has a problem with
>> the limitations imposed (most notably the restriction to a single
>> reporting bank, particularly in the context of e.g. Linux partly
>> ignoring the first bank under some conditions iirc).
> 
> 'bank0 skipping' quirks is only for older model cpus, I think we have 2 
> options:
> 1). still use 1 bank and simply ignore this issue. I mean, even if guest 
> runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest 
> skip bank0, then guest MCE logic would think it detect a spurious mce, then 
> kill itself. Considering bank0 quirks is only for old cpus, this is 
> acceptable;
> 2). use 32 banks
> 
> In fact, a third option is, use 1 bank, but hypervisor kill guest when it 
> detect bank0 quirks. This would be same effect as option 1, so I prefer let 
> guest kill itself.

Out of these, I'd actually favor using 32 banks. Using 2 banks
instead of 1 might be another option.

>> As to not needing any migration specific adjustments - what if
>> a migration is in progress when an event needs to be delivered?
> 
> If a migration is in progress while an event delivered, we abort the 
> migration.

Is there a way the hypervisor can tell the tools to abort a
migration? Or are you meaning to say such functionality would
need to be added?

One other concern that occurred to me after long having sent
the original response: Your proposal aims at a fixed,
unmodifiable vMCE interface. How is that going to be forward
compatible? I.e. consider you had made that proposal before
the SRAO/SRAR changes went in - would the same interface (with
the same set of capability bits set/clear) still be suitable?

I think that we minimally need to retain the MCG_CAP register
as being of potentially variable content (and hence needing
saving/restoring on migration). To support this in a forward
compatible manner, we may have to have a way to tell the
hypervisor e.g. via command line option which extra MSRs
have to be treated read-as-zero/writes-ignored upon guest
accesses.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2D9-0008Iv-07; Fri, 22 Jun 2012 11:39:35 +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 1Si2D6-0008IY-RW
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 11:39:33 +0000
Received: from [193.109.254.147:16462] by server-2.bemta-14.messagelabs.com id
	0D/96-01735-47954EF4; Fri, 22 Jun 2012 11:39:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340365171!11149997!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23754 invoked from network); 22 Jun 2012 11:39:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	22 Jun 2012 11:39:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 12:39:30 +0100
Message-Id: <4FE475BE020000780008B624@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 12:40:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 12:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 20.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> Recently we design xen vMCE as attached.
>>> Please kindly help me to review it, any comments/suggestions are
>>> appreciated.
>> 
>> The concept looks quite okay, provided no OS has a problem with
>> the limitations imposed (most notably the restriction to a single
>> reporting bank, particularly in the context of e.g. Linux partly
>> ignoring the first bank under some conditions iirc).
> 
> 'bank0 skipping' quirks is only for older model cpus, I think we have 2 
> options:
> 1). still use 1 bank and simply ignore this issue. I mean, even if guest 
> runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest 
> skip bank0, then guest MCE logic would think it detect a spurious mce, then 
> kill itself. Considering bank0 quirks is only for old cpus, this is 
> acceptable;
> 2). use 32 banks
> 
> In fact, a third option is, use 1 bank, but hypervisor kill guest when it 
> detect bank0 quirks. This would be same effect as option 1, so I prefer let 
> guest kill itself.

Out of these, I'd actually favor using 32 banks. Using 2 banks
instead of 1 might be another option.

>> As to not needing any migration specific adjustments - what if
>> a migration is in progress when an event needs to be delivered?
> 
> If a migration is in progress while an event delivered, we abort the 
> migration.

Is there a way the hypervisor can tell the tools to abort a
migration? Or are you meaning to say such functionality would
need to be added?

One other concern that occurred to me after long having sent
the original response: Your proposal aims at a fixed,
unmodifiable vMCE interface. How is that going to be forward
compatible? I.e. consider you had made that proposal before
the SRAO/SRAR changes went in - would the same interface (with
the same set of capability bits set/clear) still be suitable?

I think that we minimally need to retain the MCG_CAP register
as being of potentially variable content (and hence needing
saving/restoring on migration). To support this in a forward
compatible manner, we may have to have a way to tell the
hypervisor e.g. via command line option which extra MSRs
have to be treated read-as-zero/writes-ignored upon guest
accesses.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:40:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2EF-0008UG-El; Fri, 22 Jun 2012 11:40: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 1Si2EE-0008T7-6t
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:40:42 +0000
Received: from [85.158.139.83:25403] by server-6.bemta-5.messagelabs.com id
	38/4E-11348-9B954EF4; Fri, 22 Jun 2012 11:40:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340365240!28898157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20885 invoked from network); 22 Jun 2012 11:40:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11: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.213.0; Fri, 22 Jun 2012 12:40:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2EA-0003UU-4n; Fri, 22 Jun 2012 11:40:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2EA-0005Po-3x;
	Fri, 22 Jun 2012 12:40:38 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22966.110320.601890@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:40:38 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-11-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
> Set the default value for nic interfaces to VIF, since it used to be
> IOEMU, even for PV guests.

If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
HVM guests getting emulated network interfaces by default ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:40:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2EF-0008UG-El; Fri, 22 Jun 2012 11:40: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 1Si2EE-0008T7-6t
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:40:42 +0000
Received: from [85.158.139.83:25403] by server-6.bemta-5.messagelabs.com id
	38/4E-11348-9B954EF4; Fri, 22 Jun 2012 11:40:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340365240!28898157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20885 invoked from network); 22 Jun 2012 11:40:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11: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.213.0; Fri, 22 Jun 2012 12:40:38 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2EA-0003UU-4n; Fri, 22 Jun 2012 11:40:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2EA-0005Po-3x;
	Fri, 22 Jun 2012 12:40:38 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.22966.110320.601890@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:40:38 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-11-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
> Set the default value for nic interfaces to VIF, since it used to be
> IOEMU, even for PV guests.

If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
HVM guests getting emulated network interfaces by default ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:42:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si2Fq-0000HT-Ub; Fri, 22 Jun 2012 11:42: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 1Si2Fp-0000HB-RI
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:42:22 +0000
Received: from [193.109.254.147:23579] by server-10.bemta-14.messagelabs.com
	id AF/2C-05433-D1A54EF4; Fri, 22 Jun 2012 11:42:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340365334!4226963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 22 Jun 2012 11:42:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:42:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:42:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:42:13 +0100
Message-ID: <1340365332.26083.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:42:12 +0100
In-Reply-To: <1339761246-27641-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/21] libxl: further fixups re
 LIBXL_DOMAIN_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 Fri, 2012-06-15 at 12:54 +0100, Ian Jackson wrote:
> * Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
>   handlng.  At every call site, replace it with an open-coded call to

    handling

>   libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.
> 
> * This involves adding an `out:' to libxl_domain_unpause.
> 
> * In libxl_domain_destroy and do_pci_add, do not `default: abort();'
>   if the domain type cannot be found.  Instead switch on
>   LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
>   handling.
> 
> * In libxl__primary_console_find, remove a spurious default clause
>   from the domain type switch.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes in v4 of series:
>  * Hunk
>      In libxl_domain_suspend (as reorganised) error check, check for
>      LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
>    merged into the earlier patch where the slightly-wrong code was
>    introduced.
> ---
>  tools/libxl/libxl.c          |   30 +++++++++++++++++++++++-------
>  tools/libxl/libxl_internal.h |    5 +++--
>  tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
>  3 files changed, 39 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index d3b017b..cd2dbda 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
>          goto out;
>      }
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (type == LIBXL_DOMAIN_TYPE_HVM) {
>          rc = libxl__domain_resume_device_model(gc, domid);
>          if (rc) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> @@ -788,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>      char *state;
>      int ret, rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (type == LIBXL_DOMAIN_TYPE_HVM) {
>          path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
>          state = libxl__xs_read(gc, XBT_NULL, path);
>          if (state != NULL && !strcmp(state, "paused")) {
> @@ -802,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
>          rc = ERROR_FAIL;
>      }
> + out:
>      GC_FREE;
>      return rc;
>  }
> @@ -813,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
>      unsigned long pvdriver = 0;
>      int ret;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
> +    libxl_domain_type domtype = libxl__domain_type(gc, domid);
> +    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
> +        return ERROR_FAIL;
> +
> +    if (domtype == LIBXL_DOMAIN_TYPE_PV)
>          return 1;
>  
>      ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
> @@ -1213,8 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>          pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
>          dm_present = (pid != NULL);
>          break;
> -    default:
> -        abort();
> +    case LIBXL_DOMAIN_TYPE_INVALID:
> +        rc = ERROR_FAIL;
> +        goto out;
>      }
>  
>      dom_path = libxl__xs_get_dompath(gc, domid);
> @@ -1362,8 +1380,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
>          case LIBXL_DOMAIN_TYPE_INVALID:
>              rc = ERROR_INVAL;
>              goto out;
> -        default:
> -            abort();
>          }
>      }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 9df0db5..36c75ed 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
>  _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
>                                      libxl_domain_sched_params *scparams);
> -#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
> -    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
> +
>  typedef struct {
>      uint32_t store_port;
>      uint32_t store_domid;
> @@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
>  
>  _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
>  
> +/* returns 0 or 1, or a libxl error code */
>  _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
> +
>  _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
>                                              xs_transaction_t t, uint32_t domid);
>  _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index de1b79f..81438be 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
>      if (!num_devs)
>          return libxl__create_pci_backend(gc, domid, pcidev, 1);
>  
> -    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
> +    libxl_domain_type domtype = libxl__domain_type(gc, domid);
> +    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
> +        return ERROR_FAIL;
> +
> +    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
>          if (libxl__wait_for_backend(gc, be_path, "4") < 0)
>              return ERROR_FAIL;
>      }
> @@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
>          return ERROR_INVAL;
>      num = atoi(num_devs);
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
> +    libxl_domain_type domtype = libxl__domain_type(gc, domid);
> +    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
> +        return ERROR_FAIL;
> +
> +    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
>          if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
>              return ERROR_FAIL;
> @@ -199,7 +207,7 @@ retry_transaction:
>          if (errno == EAGAIN)
>              goto retry_transaction;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
> +    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
>          if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
>              return ERROR_FAIL;
> @@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
>          }
>          break;
>      }
> -    default:
> -        abort();
> +    case LIBXL_DOMAIN_TYPE_INVALID:
> +        return ERROR_FAIL;
>      }
>  out:
>      if (!libxl_is_stubdom(ctx, domid, NULL)) {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:42:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si2Fq-0000HT-Ub; Fri, 22 Jun 2012 11:42: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 1Si2Fp-0000HB-RI
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:42:22 +0000
Received: from [193.109.254.147:23579] by server-10.bemta-14.messagelabs.com
	id AF/2C-05433-D1A54EF4; Fri, 22 Jun 2012 11:42:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340365334!4226963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 22 Jun 2012 11:42:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:42:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:42:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:42:13 +0100
Message-ID: <1340365332.26083.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:42:12 +0100
In-Reply-To: <1339761246-27641-21-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-21-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/21] libxl: further fixups re
 LIBXL_DOMAIN_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 Fri, 2012-06-15 at 12:54 +0100, Ian Jackson wrote:
> * Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
>   handlng.  At every call site, replace it with an open-coded call to

    handling

>   libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.
> 
> * This involves adding an `out:' to libxl_domain_unpause.
> 
> * In libxl_domain_destroy and do_pci_add, do not `default: abort();'
>   if the domain type cannot be found.  Instead switch on
>   LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
>   handling.
> 
> * In libxl__primary_console_find, remove a spurious default clause
>   from the domain type switch.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Changes in v4 of series:
>  * Hunk
>      In libxl_domain_suspend (as reorganised) error check, check for
>      LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
>    merged into the earlier patch where the slightly-wrong code was
>    introduced.
> ---
>  tools/libxl/libxl.c          |   30 +++++++++++++++++++++++-------
>  tools/libxl/libxl_internal.h |    5 +++--
>  tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
>  3 files changed, 39 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index d3b017b..cd2dbda 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
>          goto out;
>      }
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (type == LIBXL_DOMAIN_TYPE_HVM) {
>          rc = libxl__domain_resume_device_model(gc, domid);
>          if (rc) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> @@ -788,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>      char *state;
>      int ret, rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    if (type == LIBXL_DOMAIN_TYPE_HVM) {
>          path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
>          state = libxl__xs_read(gc, XBT_NULL, path);
>          if (state != NULL && !strcmp(state, "paused")) {
> @@ -802,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
>          rc = ERROR_FAIL;
>      }
> + out:
>      GC_FREE;
>      return rc;
>  }
> @@ -813,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
>      unsigned long pvdriver = 0;
>      int ret;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
> +    libxl_domain_type domtype = libxl__domain_type(gc, domid);
> +    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
> +        return ERROR_FAIL;
> +
> +    if (domtype == LIBXL_DOMAIN_TYPE_PV)
>          return 1;
>  
>      ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
> @@ -1213,8 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
>          pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
>          dm_present = (pid != NULL);
>          break;
> -    default:
> -        abort();
> +    case LIBXL_DOMAIN_TYPE_INVALID:
> +        rc = ERROR_FAIL;
> +        goto out;
>      }
>  
>      dom_path = libxl__xs_get_dompath(gc, domid);
> @@ -1362,8 +1380,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
>          case LIBXL_DOMAIN_TYPE_INVALID:
>              rc = ERROR_INVAL;
>              goto out;
> -        default:
> -            abort();
>          }
>      }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 9df0db5..36c75ed 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
>  _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
>                                      libxl_domain_sched_params *scparams);
> -#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
> -    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
> +
>  typedef struct {
>      uint32_t store_port;
>      uint32_t store_domid;
> @@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
>  
>  _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
>  
> +/* returns 0 or 1, or a libxl error code */
>  _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
> +
>  _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
>                                              xs_transaction_t t, uint32_t domid);
>  _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index de1b79f..81438be 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
>      if (!num_devs)
>          return libxl__create_pci_backend(gc, domid, pcidev, 1);
>  
> -    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
> +    libxl_domain_type domtype = libxl__domain_type(gc, domid);
> +    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
> +        return ERROR_FAIL;
> +
> +    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
>          if (libxl__wait_for_backend(gc, be_path, "4") < 0)
>              return ERROR_FAIL;
>      }
> @@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
>          return ERROR_INVAL;
>      num = atoi(num_devs);
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
> +    libxl_domain_type domtype = libxl__domain_type(gc, domid);
> +    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
> +        return ERROR_FAIL;
> +
> +    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
>          if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
>              return ERROR_FAIL;
> @@ -199,7 +207,7 @@ retry_transaction:
>          if (errno == EAGAIN)
>              goto retry_transaction;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
> +    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
>          if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
>              return ERROR_FAIL;
> @@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
>          }
>          break;
>      }
> -    default:
> -        abort();
> +    case LIBXL_DOMAIN_TYPE_INVALID:
> +        return ERROR_FAIL;
>      }
>  out:
>      if (!libxl_is_stubdom(ctx, domid, NULL)) {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:43:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2Gn-0000Rv-Ix; Fri, 22 Jun 2012 11:43:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si2Gm-0000Re-7b
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:43:20 +0000
Received: from [85.158.143.99:32866] by server-2.bemta-4.messagelabs.com id
	12/CA-17938-75A54EF4; Fri, 22 Jun 2012 11:43:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340365399!23340005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29381 invoked from network); 22 Jun 2012 11:43:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:43:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:43:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2Gk-0003VR-KA; Fri, 22 Jun 2012 11:43:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2Gk-0005Q5-JS;
	Fri, 22 Jun 2012 12:43:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.23126.590296.567037@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:43:18 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-13-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-13-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 12/13] libxl: call hotplug scripts for
 disk devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 12/13] libxl: call hotplug scripts for disk devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for disk devices, that should be called when the device is added or
> removed from a guest.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:43:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2Gn-0000Rv-Ix; Fri, 22 Jun 2012 11:43:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si2Gm-0000Re-7b
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:43:20 +0000
Received: from [85.158.143.99:32866] by server-2.bemta-4.messagelabs.com id
	12/CA-17938-75A54EF4; Fri, 22 Jun 2012 11:43:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340365399!23340005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29381 invoked from network); 22 Jun 2012 11:43:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:43:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:43:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2Gk-0003VR-KA; Fri, 22 Jun 2012 11:43:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2Gk-0005Q5-JS;
	Fri, 22 Jun 2012 12:43:18 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.23126.590296.567037@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:43:18 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <1339676475-33265-13-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-13-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 12/13] libxl: call hotplug scripts for
 disk devices from libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 12/13] libxl: call hotplug scripts for disk devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for disk devices, that should be called when the device is added or
> removed from a guest.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2Iq-0000fx-6u; Fri, 22 Jun 2012 11:45:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si2Io-0000fn-Tw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:45:27 +0000
Received: from [193.109.254.147:40938] by server-6.bemta-14.messagelabs.com id
	5F/2A-08993-6DA54EF4; Fri, 22 Jun 2012 11:45:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340365522!11034800!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4171 invoked from network); 22 Jun 2012 11:45:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:45:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:45:22 +0100
Message-ID: <1340365521.26083.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:45:21 +0100
In-Reply-To: <1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce
 prohibition on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 12:54 +0100, Ian Jackson wrote:
> DO NOT APPLY THIS PATCH.
> It contains -Wno-error.  Without that it would break the build.

I'm happy with the shape of this patch, and apart from the above caveat
I'd be happy to Ack it, assuming it were preceded by fixes to those
issues.

I fear slightly that we will be continually forgetting to add the tag
during review. Is there a way we could augment with run time checking?
Perhaps LIBXL__INIT_EGC can tell if a CTX is not "outer" somehow?

> 
> Subject [PATCH] libxl: enforce prohibitions of internal callers
> 
> libxl_internal.h says:
> 
>  * Functions using LIBXL__INIT_EGC may *not* generally be called from
>  * within libxl, because libxl__egc_cleanup may call back into the
>  * application. ...
> 
> and
> 
>  *                    ...  [Functions which take an ao_how] MAY NOT
>  * be called from inside libxl, because they can cause reentrancy
>  * callbacks.
> 
> However, this was not enforced.  Particularly the latter restriction
> is easy to overlook, especially since during the transition period to
> the new event system we have bent this rule a couple of times, and the
> bad pattern simply involves passing 0 or NULL for the ao_how.
> 
> So use the compiler to enforce this property, as follows:
> 
>  - Mark all functions which take a libxl_asyncop_how, or which
>    use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
>    LIBXL_EXTERNAL_CALLERS_ONLY in the public header.
> 
>  - Change the documentation comment for asynch operations and egcs to
>    say that this should always be done.
> 
>  - Arrange that if libxl.h is included via libxl_internal.h,
>    LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
>    which generates a message like this:
>       libxl.c:1772: warning: call to 'libxl_device_disk_remove'
>              declared with attribute warning:
>              may not be called from within libxl
>    Otherwise, the annotation expands to nothing, so external
>    callers are unaffected.
> 
>  - Forbid inclusion of both libxl.h and libxl_internal.h unless
>    libxl_internal.h came first, so that the above check doesn't have
>    any loopholes.  Files which include libxl_internal.h should not
>    include libxl.h as well.
> 
>    This is enforced explicitly using #error.  However, in practice
>    with the current tree it just changes the error message when this
>    mistake is made; otherwise we would carry on to immediately
>    following #define which would cause the compiler to complain that
>    LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
>    might be tempted to add a #ifndef which would be wrong - it would
>    leave the affected translation unit unprotected by the new
>    enforcement regime.  So let's be explicit.
> 
>  - Fix the one source of files which violate the above principle, the
>    output from the idl compiler, by removing the redundant inclusion
>    of libxl.h from the output.
> 
> In the tree I am using as a base at the time of writing, this new
> restriction catches three errors: two in libxl_device_disk_remove and
> one in libxl__device_disk_local_detach.  To avoid entirely breaking my
> build I have also done this:
> 
>  - Temporarily change -Werror to -Wno-error in the libxl Makefile.
> 
> This patch should not be applied in this form.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Roger Pau Monne <roger.pau@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/libxl/Makefile         |    2 +-
>  tools/libxl/gentypes.py      |    1 -
>  tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
>  tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
>  tools/libxl/libxl_internal.h |   14 ++++++++++----
>  5 files changed, 50 insertions(+), 22 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index ddc2624..c238ac0 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -11,7 +11,7 @@ MINOR = 0
>  XLUMAJOR = 1.0
>  XLUMINOR = 0
> 
> -CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
> +CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
>         -Wno-declaration-after-statement -Wformat-nonliteral
>  CFLAGS += -I. -fPIC
> 
> diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
> index 3c561ba..6e83b21 100644
> --- a/tools/libxl/gentypes.py
> +++ b/tools/libxl/gentypes.py
> @@ -341,7 +341,6 @@ if __name__ == '__main__':
>  #include <stdlib.h>
>  #include <string.h>
> 
> -#include "libxl.h"
>  #include "libxl_internal.h"
> 
>  #define LIBXL_DTOR_POISON 0xa5
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 10d7115..1a32d9e 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -266,6 +266,13 @@
>  #endif
>  #endif
> 
> +/* 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. */
> +#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
> +#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
> +#endif
> +
>  typedef uint8_t libxl_mac[6];
>  #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
>  #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
> @@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
>  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
>                              uint32_t *domid,
>                              const libxl_asyncop_how *ao_how,
> -                            const libxl_asyncprogress_how *aop_console_how);
> +                            const libxl_asyncprogress_how *aop_console_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
>                                  uint32_t *domid, int restore_fd,
>                                  const libxl_asyncop_how *ao_how,
> -                                const libxl_asyncprogress_how *aop_console_how);
> +                                const libxl_asyncprogress_how *aop_console_how)
> +                                LIBXL_EXTERNAL_CALLERS_ONLY;
>    /* A progress report will be made via ao_console_how, of type
>     * domain_create_console_available, when the domain's primary
>     * console is available and can be connected to.
> @@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
> 
>  int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                           int flags, /* LIBXL_SUSPEND_* */
> -                         const libxl_asyncop_how *ao_how);
> +                         const libxl_asyncop_how *ao_how)
> +                         LIBXL_EXTERNAL_CALLERS_ONLY;
>  #define LIBXL_SUSPEND_DEBUG 1
>  #define LIBXL_SUSPEND_LIVE 2
> 
> @@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
> 
>  int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
>                               uint32_t domid, int send_fd, int recv_fd,
> -                             const libxl_asyncop_how *ao_how);
> +                             const libxl_asyncop_how *ao_how)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> @@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
> 
>  int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
>                             const char *filename,
> -                           const libxl_asyncop_how *ao_how);
> +                           const libxl_asyncop_how *ao_how)
> +                           LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
>  int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
> @@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
>  int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>                               libxl_device_disk *disk,
> -                             const libxl_asyncop_how *ao_how);
> +                             const libxl_asyncop_how *ao_how)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_disk *disk);
> 
> @@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
>  int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
>  int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_nic *nic,
> -                            const libxl_asyncop_how *ao_how);
> +                            const libxl_asyncop_how *ao_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
> 
>  libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
> @@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
>  int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
>  int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vkb *vkb,
> -                            const libxl_asyncop_how *ao_how);
> +                            const libxl_asyncop_how *ao_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
> 
>  /* Framebuffer */
>  int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
>  int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vfb *vfb,
> -                            const libxl_asyncop_how *ao_how);
> +                            const libxl_asyncop_how *ao_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
> 
>  /* PCI Passthrough */
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 713d96d..3344bc8 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
> 
>  int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
>                        uint64_t typemask,
> -                      libxl_event_predicate *predicate, void *predicate_user);
> +                      libxl_event_predicate *predicate, void *predicate_user)
> +                      LIBXL_EXTERNAL_CALLERS_ONLY;
>    /* Searches for an event, already-happened, which matches typemask
>     * and predicate.  predicate==0 matches any event.
>     * libxl_event_check returns the event, which must then later be
> @@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> 
>  int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
>                       uint64_t typemask,
> -                     libxl_event_predicate *predicate, void *predicate_user);
> +                     libxl_event_predicate *predicate, void *predicate_user)
> +                     LIBXL_EXTERNAL_CALLERS_ONLY;
>    /* Like libxl_event_check but blocks if no suitable events are
>     * available, until some are.  Uses libxl_osevent_beforepoll/
>     * _afterpoll so may be inefficient if very many domains are being
> @@ -256,7 +258,8 @@ struct pollfd;
>   */
>  int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
>                               struct pollfd *fds, int *timeout_upd,
> -                             struct timeval now);
> +                             struct timeval now)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  /* nfds and fds[0..nfds] must be from the most recent call to
>   * _beforepoll, as modified by poll.  (It is therefore not possible
> @@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
>   * libxl_event_check.
>   */
>  void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> -                             struct timeval now);
> +                             struct timeval now)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
> 
> 
>  typedef struct libxl_osevent_hooks {
> @@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
>   */
> 
>  void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
> -                               int fd, short events, short revents);
> +                               int fd, short events, short revents)
> +                               LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  /* Implicitly, on entry to this function the timeout has been
>   * deregistered.  If _occurred_timeout is called, libxl will not
>   * call timeout_deregister; if it wants to requeue the timeout it
>   * will call timeout_register again.
>   */
> -void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> +void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
> +                                    LIBXL_EXTERNAL_CALLERS_ONLY;
> 
> 
>  /*======================================================================*/
> @@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
>   * certainly need to use the self-pipe trick (or a working pselect or
>   * ppoll) to implement this.
>   */
> -int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
> +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
> +                           LIBXL_EXTERNAL_CALLERS_ONLY;
> 
> 
>  /*
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 36c75ed..6c859bc 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -52,6 +52,12 @@
> 
>  #include <xen/io/xenbus.h>
> 
> +#ifdef LIBXL_H
> +# error libxl.h should be included via libxl_internal.h, not separately
> +#endif
> +#define LIBXL_EXTERNAL_CALLERS_ONLY \
> +    __attribute__((warning("may not be called from within libxl")))
> +
>  #include "libxl.h"
>  #include "_paths.h"
>  #include "_libxl_save_msgs_callout.h"
> @@ -1538,10 +1544,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>   *
>   * Functions using LIBXL__INIT_EGC may *not* generally be called from
>   * within libxl, because libxl__egc_cleanup may call back into the
> - * application.  This should be documented near the function
> - * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
> - * should in any case not find it necessary to call egc-creators from
> - * within libxl.
> + * application.  This should be enforced by declaring all such
> + * functions in libxl.h or libxl_event.h with
> + * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
> + * necessary to call egc-creators from within libxl.
>   *
>   * The callbacks must all take place with the ctx unlocked because
>   * the application is entitled to reenter libxl from them.  This
> --
> 1.7.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 Jun 22 11:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2Iq-0000fx-6u; Fri, 22 Jun 2012 11:45:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si2Io-0000fn-Tw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:45:27 +0000
Received: from [193.109.254.147:40938] by server-6.bemta-14.messagelabs.com id
	5F/2A-08993-6DA54EF4; Fri, 22 Jun 2012 11:45:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340365522!11034800!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4171 invoked from network); 22 Jun 2012 11:45:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13167981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:45:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:45:22 +0100
Message-ID: <1340365521.26083.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:45:21 +0100
In-Reply-To: <1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce
 prohibition on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 12:54 +0100, Ian Jackson wrote:
> DO NOT APPLY THIS PATCH.
> It contains -Wno-error.  Without that it would break the build.

I'm happy with the shape of this patch, and apart from the above caveat
I'd be happy to Ack it, assuming it were preceded by fixes to those
issues.

I fear slightly that we will be continually forgetting to add the tag
during review. Is there a way we could augment with run time checking?
Perhaps LIBXL__INIT_EGC can tell if a CTX is not "outer" somehow?

> 
> Subject [PATCH] libxl: enforce prohibitions of internal callers
> 
> libxl_internal.h says:
> 
>  * Functions using LIBXL__INIT_EGC may *not* generally be called from
>  * within libxl, because libxl__egc_cleanup may call back into the
>  * application. ...
> 
> and
> 
>  *                    ...  [Functions which take an ao_how] MAY NOT
>  * be called from inside libxl, because they can cause reentrancy
>  * callbacks.
> 
> However, this was not enforced.  Particularly the latter restriction
> is easy to overlook, especially since during the transition period to
> the new event system we have bent this rule a couple of times, and the
> bad pattern simply involves passing 0 or NULL for the ao_how.
> 
> So use the compiler to enforce this property, as follows:
> 
>  - Mark all functions which take a libxl_asyncop_how, or which
>    use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
>    LIBXL_EXTERNAL_CALLERS_ONLY in the public header.
> 
>  - Change the documentation comment for asynch operations and egcs to
>    say that this should always be done.
> 
>  - Arrange that if libxl.h is included via libxl_internal.h,
>    LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
>    which generates a message like this:
>       libxl.c:1772: warning: call to 'libxl_device_disk_remove'
>              declared with attribute warning:
>              may not be called from within libxl
>    Otherwise, the annotation expands to nothing, so external
>    callers are unaffected.
> 
>  - Forbid inclusion of both libxl.h and libxl_internal.h unless
>    libxl_internal.h came first, so that the above check doesn't have
>    any loopholes.  Files which include libxl_internal.h should not
>    include libxl.h as well.
> 
>    This is enforced explicitly using #error.  However, in practice
>    with the current tree it just changes the error message when this
>    mistake is made; otherwise we would carry on to immediately
>    following #define which would cause the compiler to complain that
>    LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
>    might be tempted to add a #ifndef which would be wrong - it would
>    leave the affected translation unit unprotected by the new
>    enforcement regime.  So let's be explicit.
> 
>  - Fix the one source of files which violate the above principle, the
>    output from the idl compiler, by removing the redundant inclusion
>    of libxl.h from the output.
> 
> In the tree I am using as a base at the time of writing, this new
> restriction catches three errors: two in libxl_device_disk_remove and
> one in libxl__device_disk_local_detach.  To avoid entirely breaking my
> build I have also done this:
> 
>  - Temporarily change -Werror to -Wno-error in the libxl Makefile.
> 
> This patch should not be applied in this form.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Roger Pau Monne <roger.pau@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/libxl/Makefile         |    2 +-
>  tools/libxl/gentypes.py      |    1 -
>  tools/libxl/libxl.h          |   34 +++++++++++++++++++++++++---------
>  tools/libxl/libxl_event.h    |   21 ++++++++++++++-------
>  tools/libxl/libxl_internal.h |   14 ++++++++++----
>  5 files changed, 50 insertions(+), 22 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index ddc2624..c238ac0 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -11,7 +11,7 @@ MINOR = 0
>  XLUMAJOR = 1.0
>  XLUMINOR = 0
> 
> -CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
> +CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
>         -Wno-declaration-after-statement -Wformat-nonliteral
>  CFLAGS += -I. -fPIC
> 
> diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
> index 3c561ba..6e83b21 100644
> --- a/tools/libxl/gentypes.py
> +++ b/tools/libxl/gentypes.py
> @@ -341,7 +341,6 @@ if __name__ == '__main__':
>  #include <stdlib.h>
>  #include <string.h>
> 
> -#include "libxl.h"
>  #include "libxl_internal.h"
> 
>  #define LIBXL_DTOR_POISON 0xa5
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 10d7115..1a32d9e 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -266,6 +266,13 @@
>  #endif
>  #endif
> 
> +/* 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. */
> +#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
> +#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
> +#endif
> +
>  typedef uint8_t libxl_mac[6];
>  #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
>  #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
> @@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
>  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
>                              uint32_t *domid,
>                              const libxl_asyncop_how *ao_how,
> -                            const libxl_asyncprogress_how *aop_console_how);
> +                            const libxl_asyncprogress_how *aop_console_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
>                                  uint32_t *domid, int restore_fd,
>                                  const libxl_asyncop_how *ao_how,
> -                                const libxl_asyncprogress_how *aop_console_how);
> +                                const libxl_asyncprogress_how *aop_console_how)
> +                                LIBXL_EXTERNAL_CALLERS_ONLY;
>    /* A progress report will be made via ao_console_how, of type
>     * domain_create_console_available, when the domain's primary
>     * console is available and can be connected to.
> @@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
> 
>  int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                           int flags, /* LIBXL_SUSPEND_* */
> -                         const libxl_asyncop_how *ao_how);
> +                         const libxl_asyncop_how *ao_how)
> +                         LIBXL_EXTERNAL_CALLERS_ONLY;
>  #define LIBXL_SUSPEND_DEBUG 1
>  #define LIBXL_SUSPEND_LIVE 2
> 
> @@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
> 
>  int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
>                               uint32_t domid, int send_fd, int recv_fd,
> -                             const libxl_asyncop_how *ao_how);
> +                             const libxl_asyncop_how *ao_how)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> @@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
> 
>  int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
>                             const char *filename,
> -                           const libxl_asyncop_how *ao_how);
> +                           const libxl_asyncop_how *ao_how)
> +                           LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
>  int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
> @@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
>  int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
>                               libxl_device_disk *disk,
> -                             const libxl_asyncop_how *ao_how);
> +                             const libxl_asyncop_how *ao_how)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
>                                libxl_device_disk *disk);
> 
> @@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
>  int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
>  int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_nic *nic,
> -                            const libxl_asyncop_how *ao_how);
> +                            const libxl_asyncop_how *ao_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
> 
>  libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
> @@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
>  int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
>  int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vkb *vkb,
> -                            const libxl_asyncop_how *ao_how);
> +                            const libxl_asyncop_how *ao_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
> 
>  /* Framebuffer */
>  int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
>  int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_device_vfb *vfb,
> -                            const libxl_asyncop_how *ao_how);
> +                            const libxl_asyncop_how *ao_how)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;
>  int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
> 
>  /* PCI Passthrough */
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 713d96d..3344bc8 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
> 
>  int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
>                        uint64_t typemask,
> -                      libxl_event_predicate *predicate, void *predicate_user);
> +                      libxl_event_predicate *predicate, void *predicate_user)
> +                      LIBXL_EXTERNAL_CALLERS_ONLY;
>    /* Searches for an event, already-happened, which matches typemask
>     * and predicate.  predicate==0 matches any event.
>     * libxl_event_check returns the event, which must then later be
> @@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
> 
>  int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
>                       uint64_t typemask,
> -                     libxl_event_predicate *predicate, void *predicate_user);
> +                     libxl_event_predicate *predicate, void *predicate_user)
> +                     LIBXL_EXTERNAL_CALLERS_ONLY;
>    /* Like libxl_event_check but blocks if no suitable events are
>     * available, until some are.  Uses libxl_osevent_beforepoll/
>     * _afterpoll so may be inefficient if very many domains are being
> @@ -256,7 +258,8 @@ struct pollfd;
>   */
>  int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
>                               struct pollfd *fds, int *timeout_upd,
> -                             struct timeval now);
> +                             struct timeval now)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  /* nfds and fds[0..nfds] must be from the most recent call to
>   * _beforepoll, as modified by poll.  (It is therefore not possible
> @@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
>   * libxl_event_check.
>   */
>  void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
> -                             struct timeval now);
> +                             struct timeval now)
> +                             LIBXL_EXTERNAL_CALLERS_ONLY;
> 
> 
>  typedef struct libxl_osevent_hooks {
> @@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
>   */
> 
>  void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
> -                               int fd, short events, short revents);
> +                               int fd, short events, short revents)
> +                               LIBXL_EXTERNAL_CALLERS_ONLY;
> 
>  /* Implicitly, on entry to this function the timeout has been
>   * deregistered.  If _occurred_timeout is called, libxl will not
>   * call timeout_deregister; if it wants to requeue the timeout it
>   * will call timeout_register again.
>   */
> -void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> +void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
> +                                    LIBXL_EXTERNAL_CALLERS_ONLY;
> 
> 
>  /*======================================================================*/
> @@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
>   * certainly need to use the self-pipe trick (or a working pselect or
>   * ppoll) to implement this.
>   */
> -int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
> +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
> +                           LIBXL_EXTERNAL_CALLERS_ONLY;
> 
> 
>  /*
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 36c75ed..6c859bc 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -52,6 +52,12 @@
> 
>  #include <xen/io/xenbus.h>
> 
> +#ifdef LIBXL_H
> +# error libxl.h should be included via libxl_internal.h, not separately
> +#endif
> +#define LIBXL_EXTERNAL_CALLERS_ONLY \
> +    __attribute__((warning("may not be called from within libxl")))
> +
>  #include "libxl.h"
>  #include "_paths.h"
>  #include "_libxl_save_msgs_callout.h"
> @@ -1538,10 +1544,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>   *
>   * Functions using LIBXL__INIT_EGC may *not* generally be called from
>   * within libxl, because libxl__egc_cleanup may call back into the
> - * application.  This should be documented near the function
> - * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
> - * should in any case not find it necessary to call egc-creators from
> - * within libxl.
> + * application.  This should be enforced by declaring all such
> + * functions in libxl.h or libxl_event.h with
> + * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
> + * necessary to call egc-creators from within libxl.
>   *
>   * The callbacks must all take place with the ctx unlocked because
>   * the application is entitled to reenter libxl from them.  This
> --
> 1.7.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 Jun 22 11:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2LO-0000pk-PO; Fri, 22 Jun 2012 11:48: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 1Si2LN-0000pe-AS
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:48:05 +0000
Received: from [85.158.143.99:14038] by server-2.bemta-4.messagelabs.com id
	49/E1-17938-47B54EF4; Fri, 22 Jun 2012 11:48:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340365683!25245979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5837 invoked from network); 22 Jun 2012 11:48:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13168020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:47:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:47:37 +0100
Message-ID: <1340365656.26083.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:47:36 +0100
In-Reply-To: <1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> @@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
>      return ptr;
>  }
> 
> +static void remus_crashed_cb(libxl__egc *egc,
> +                             libxl__domain_suspend_state *dss, int rc);

I think you were going to rename this remus_failover_cb but
nevertheless:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Were you going to ping Shriram to test remus with this series applied?

> +
>  /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
>  int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> -                             uint32_t domid, int send_fd, int recv_fd)
> +                             uint32_t domid, int send_fd, int recv_fd,
> +                             const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> -    libxl_domain_type type = libxl__domain_type(gc, domid);
> -    int rc = 0;
> +    AO_CREATE(ctx, domid, ao_how);
> +    libxl__domain_suspend_state *dss;
> +    int rc;
> 
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
>      if (type == LIBXL_DOMAIN_TYPE_INVALID) {
>          rc = ERROR_FAIL;
> -        goto remus_fail;
> +        goto out;
>      }
> 
> -    if (info == NULL) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> -                   "No remus_info structure supplied for domain %d", domid);
> -        rc = ERROR_INVAL;
> -        goto remus_fail;
> -    }
> +    GCNEW(dss);
> +    dss->ao = ao;
> +    dss->callback = remus_crashed_cb;
> +    dss->domid = domid;
> +    dss->fd = send_fd;
> +    /* TODO do something with recv_fd */
> +    dss->type = type;
> +    dss->live = 1;
> +    dss->debug = 0;
> +    dss->remus = info;
> +
> +    assert(info);
> 
>      /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> 
>      /* Point of no return */
> -    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
> -                                      /* debug */ 0, info);
> +    libxl__domain_suspend(egc, dss);
> +    return AO_INPROGRESS;
> +
> + out:
> +    return AO_ABORT(rc);
> +}
> 
> +static void remus_crashed_cb(libxl__egc *egc,
> +                             libxl__domain_suspend_state *dss, int rc)
> +{
> +    STATE_AO_GC(dss->ao);
>      /*
>       * With Remus, if we reach this point, it means either
>       * backup died or some network error occurred preventing us
> @@ -683,27 +702,46 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
>      /* TBD: Remus cleanup - i.e. detach qdisc, release other
>       * resources.
>       */
> - remus_fail:
> -    GC_FREE;
> -    return rc;
> +    libxl__ao_complete(egc, ao, rc);
>  }
> 
> -int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> -                         uint32_t domid, int fd)
> +static void domain_suspend_cb(libxl__egc *egc,
> +                              libxl__domain_suspend_state *dss, int rc)
>  {
> -    GC_INIT(ctx);
> +    STATE_AO_GC(dss->ao);
> +    libxl__ao_complete(egc,ao,rc);
> +
> +}
> +
> +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
> +                         const libxl_asyncop_how *ao_how)
> +{
> +    AO_CREATE(ctx, domid, ao_how);
> +    int rc;
> +
>      libxl_domain_type type = libxl__domain_type(gc, domid);
> -    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
> -    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
> -    int rc = 0;
> +    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
> +        rc = ERROR_FAIL;
> +        goto out_err;
> +    }
> 
> -    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
> -                                      /* No Remus */ NULL);
> +    libxl__domain_suspend_state *dss;
> +    GCNEW(dss);
> 
> -    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
> -        rc = libxl__domain_save_device_model(gc, domid, fd);
> -    GC_FREE;
> -    return rc;
> +    dss->ao = ao;
> +    dss->callback = domain_suspend_cb;
> +
> +    dss->domid = domid;
> +    dss->fd = fd;
> +    dss->type = type;
> +    dss->live = flags & LIBXL_SUSPEND_LIVE;
> +    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
> +
> +    libxl__domain_suspend(egc, dss);
> +    return AO_INPROGRESS;
> +
> + out_err:
> +    return AO_ABORT(rc);
>  }
> 
>  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 05f0e01..10d7115 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
> 
>  const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
> 
> -typedef struct {
> -#define XL_SUSPEND_DEBUG 1
> -#define XL_SUSPEND_LIVE 2
> -    int flags;
> -    int (*suspend_callback)(void *, int);
> -} libxl_domain_suspend_info;
> -
>  enum {
>      ERROR_NONSPECIFIC = -1,
>      ERROR_VERSION = -2,
> @@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
> 
>  void libxl_domain_config_init(libxl_domain_config *d_config);
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> -int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> -                             uint32_t domid, int send_fd, int recv_fd);
> -int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> -                          uint32_t domid, int fd);
> +
> +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> +                         int flags, /* LIBXL_SUSPEND_* */
> +                         const libxl_asyncop_how *ao_how);
> +#define LIBXL_SUSPEND_DEBUG 1
> +#define LIBXL_SUSPEND_LIVE 2
> 
>  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
>   *   If this parameter is true, use co-operative resume. The guest
>   *   must support this.
>   */
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
> +
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int send_fd, int recv_fd,
> +                             const libxl_asyncop_how *ao_how);
> +
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 1d4e809..b48452c 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -17,13 +17,11 @@
> 
>  #include <glob.h>
> 
> -#include <xenctrl.h>
> -#include <xc_dom.h>
> +#include "libxl_internal.h"
> 
> +#include <xc_dom.h>
>  #include <xen/hvm/hvm_info_table.h>
> 
> -#include "libxl_internal.h"
> -
>  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> @@ -521,11 +519,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>      return 0;
>  }
> 
> -static int libxl__domain_suspend_common_switch_qemu_logdirty
> +/*==================== Domain suspend (save) ====================*/
> +
> +static void domain_suspend_done(libxl__egc *egc,
> +                        libxl__domain_suspend_state *dss, int rc);
> +
> +/*----- callbacks, called by xc_domain_save -----*/
> +
> +int libxl__domain_suspend_common_switch_qemu_logdirty
>                                 (int domid, unsigned int enable, void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
>      char *path;
>      bool rc;
> 
> @@ -590,10 +595,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
>      return 0;
>  }
> 
> -static int libxl__domain_suspend_common_callback(void *data)
> +int libxl__domain_suspend_common_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
>      unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
>      int ret;
>      char *state = "suspend";
> @@ -714,7 +719,7 @@ static int libxl__domain_suspend_common_callback(void *data)
> 
>   guest_suspended:
>      if (dss->hvm) {
> -        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
> +        ret = libxl__domain_suspend_device_model(gc, dss->domid);
>          if (ret) {
>              LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
>              return 0;
> @@ -731,11 +736,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
>              domid, phys_offset, node);
>  }
> 
> -static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
>          uint32_t *len, void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
>      int i = 0;
>      char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
>      unsigned int num = 0;
> @@ -806,6 +811,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
>      return 0;
>  }
> 
> +/*----- remus callbacks -----*/
> +
>  static int libxl__remus_domain_suspend_callback(void *data)
>  {
>      /* TODO: Issue disk and network checkpoint reqs. */
> @@ -815,7 +822,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
>  static int libxl__remus_domain_resume_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
> 
>      /* Resumes the domain and the device model */
>      if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
> @@ -828,10 +835,11 @@ static int libxl__remus_domain_resume_callback(void *data)
>  static int libxl__remus_domain_checkpoint_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> +    STATE_AO_GC(dss->ao);
> 
>      /* This would go into tailbuf. */
>      if (dss->hvm &&
> -        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
> +        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
>          return 0;
> 
>      /* TODO: Wait for disk and memory ack, release network buffer */
> @@ -839,17 +847,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
>      return 1;
>  }
> 
> -int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> -                                 libxl_domain_type type,
> -                                 int live, int debug,
> -                                 const libxl_domain_remus_info *r_info)
> +/*----- main code for suspending, in order of execution -----*/
> +
> +void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>  {
> +    STATE_AO_GC(dss->ao);
>      int port;
> -    struct save_callbacks callbacks[1];
> -    libxl__domain_suspend_state dss[1];
>      int rc = ERROR_FAIL;
>      unsigned long vm_generationid_addr;
> 
> +    /* Convenience aliases */
> +    const uint32_t domid = dss->domid;
> +    const libxl_domain_type type = dss->type;
> +    const int live = dss->live;
> +    const int debug = dss->debug;
> +    const libxl_domain_remus_info *const r_info = dss->remus;
> +    struct save_callbacks *const callbacks = &dss->callbacks;
> +
>      switch (type) {
>      case LIBXL_DOMAIN_TYPE_HVM: {
>          char *path;
> @@ -868,15 +882,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>          dss->hvm = 0;
>          break;
>      default:
> -        return ERROR_INVAL;
> +        abort();
>      }
> 
>      dss->xcflags = (live) ? XCFLAGS_LIVE : 0
>            | (debug) ? XCFLAGS_DEBUG : 0
>            | (dss->hvm) ? XCFLAGS_HVM : 0;
> 
> -    dss->domid = domid;
> -    dss->gc = gc;
>      dss->suspend_eventchn = -1;
>      dss->guest_responded = 0;
> 
> @@ -884,10 +896,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>          dss->interval = r_info->interval;
>          if (r_info->compression)
>              dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
> -        dss->save_fd = fd;
>      }
> -    else
> -        dss->save_fd = -1;
> 
>      dss->xce = xc_evtchn_open(NULL, 0);
>      if (dss->xce == NULL)
> @@ -917,10 +926,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>      callbacks->toolstack_save = libxl__toolstack_save;
>      callbacks->data = dss;
> 
> -    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
> -                        dss->hvm, vm_generationid_addr);
> -    if ( rc ) {
> -        LOGE(ERROR, "saving domain: %s",
> +    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
> +    return;
> +
> + out:
> +    domain_suspend_done(egc, dss, rc);
> +}
> +
> +void libxl__xc_domain_save_done(libxl__egc *egc,
> +                                libxl__domain_suspend_state *dss,
> +                                int rc, int retval, int errnoval)
> +{
> +    STATE_AO_GC(dss->ao);
> +
> +    /* Convenience aliases */
> +    const libxl_domain_type type = dss->type;
> +    const uint32_t domid = dss->domid;
> +
> +    if (rc)
> +        goto out;
> +
> +    if (retval) {
> +        LOGEV(ERROR, errnoval, "saving domain: %s",
>                           dss->guest_responded ?
>                           "domain responded to suspend request" :
>                           "domain did not respond to suspend request");
> @@ -928,16 +955,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>              rc = ERROR_GUEST_TIMEDOUT;
>          else
>              rc = ERROR_FAIL;
> +        goto out;
>      }
> 
> -    if (dss->suspend_eventchn > 0)
> -        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
> -                                  dss->suspend_eventchn);
> -    if (dss->xce != NULL)
> -        xc_evtchn_close(dss->xce);
> +    if (type == LIBXL_DOMAIN_TYPE_HVM) {
> +        rc = libxl__domain_suspend_device_model(gc, domid);
> +        if (rc) goto out;
> +
> +        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
> +        if (rc) goto out;
> +    }
> +
> +    rc = 0;
> 
>  out:
> -    return rc;
> +    domain_suspend_done(egc, dss, rc);
>  }
> 
>  int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
> @@ -992,6 +1024,25 @@ out:
>      return rc;
>  }
> 
> +static void domain_suspend_done(libxl__egc *egc,
> +                        libxl__domain_suspend_state *dss, int rc)
> +{
> +    STATE_AO_GC(dss->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = dss->domid;
> +
> +    if (dss->suspend_eventchn > 0)
> +        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
> +                                  dss->suspend_eventchn);
> +    if (dss->xce != NULL)
> +        xc_evtchn_close(dss->xce);
> +
> +    dss->callback(egc, dss, rc);
> +}
> +
> +/*==================== Miscellaneous ====================*/
> +
>  char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
>  {
>      char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 28478ea..7cf1b04 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
> 
>  typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
> 
> +typedef void libxl__domain_suspend_cb(libxl__egc*,
> +                                      libxl__domain_suspend_state*, int rc);
> +
>  struct libxl__domain_suspend_state {
> -    libxl__gc *gc;
> +    /* set by caller of libxl__domain_suspend */
> +    libxl__ao *ao;
> +    libxl__domain_suspend_cb *callback;
> +
> +    uint32_t domid;
> +    int fd;
> +    libxl_domain_type type;
> +    int live;
> +    int debug;
> +    const libxl_domain_remus_info *remus;
> +    /* private */
>      xc_evtchn *xce; /* event channel handle */
>      int suspend_eventchn;
> -    int domid;
>      int hvm;
> -    unsigned int xcflags;
> +    int xcflags;
>      int guest_responded;
> -    int save_fd; /* Migration stream fd (for Remus) */
>      int interval; /* checkpoint interval (for Remus) */
> +    struct save_callbacks callbacks;
>  };
> 
> 
> @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> 
>  /*----- Domain suspend (save) functions -----*/
> 
> -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> -                                         libxl_domain_type type,
> -                                         int live, int debug,
> -                                         const libxl_domain_remus_info *r_info);
> +/* calls dss->callback when done */
> +_hidden void libxl__domain_suspend(libxl__egc *egc,
> +                                   libxl__domain_suspend_state *dss);
> +
> +
> +/* calls libxl__xc_domain_suspend_done when done */
> +_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
> +                                   unsigned long vm_generationid_addr);
> +/* If rc==0 then retval is the return value from xc_domain_save
> + * and errnoval is the errno value it provided.
> + * If rc!=0, retval and errnoval are undefined. */
> +_hidden void libxl__xc_domain_save_done(libxl__egc*,
> +                                        libxl__domain_suspend_state*,
> +                                        int rc, int retval, int errnoval);
> +
> +_hidden int libxl__domain_suspend_common_callback(void *data);
> +_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
> +                               (int domid, unsigned int enable, void *data);
> +_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +        uint32_t *len, void *data);
> +
> 
>  /* calls libxl__xc_domain_restore_done when done */
>  _hidden void libxl__xc_domain_restore(libxl__egc *egc,
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> index 2f8db9f..1b481ab 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>                                &state->vm_generationid_addr, &dcs->callbacks);
>      libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
>  }
> +
> +void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
> +                           unsigned long vm_generationid_addr)
> +{
> +    STATE_AO_GC(dss->ao);
> +    int r;
> +
> +    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
> +                       &dss->callbacks, dss->hvm, vm_generationid_addr);
> +    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
> +}
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3ea95ef..19daa1c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
> 
>      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> 
> -    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
> +    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
>      close(fd);
> 
>      if (checkpoint)
> @@ -3008,7 +3008,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
>      pid_t child = -1;
>      int rc;
>      int send_fd = -1, recv_fd = -1;
> -    libxl_domain_suspend_info suspinfo;
>      char *away_domname;
>      char rc_buf;
>      uint8_t *config_data;
> @@ -3030,9 +3029,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
> 
>      xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
> 
> -    memset(&suspinfo, 0, sizeof(suspinfo));
> -    suspinfo.flags |= XL_SUSPEND_LIVE;
> -    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
> +    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
>      if (rc) {
>          fprintf(stderr, "migration sender: libxl_domain_suspend failed"
>                  " (rc=%d)\n", rc);
> @@ -6604,7 +6601,7 @@ int main_remus(int argc, char **argv)
>      }
> 
>      /* Point of no return */
> -    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
> +    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
> 
>      /* If we are here, it means backup has failed/domain suspend failed.
>       * Try to resume the domain and exit gracefully.
> --
> 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 Jun 22 11:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2LO-0000pk-PO; Fri, 22 Jun 2012 11:48: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 1Si2LN-0000pe-AS
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:48:05 +0000
Received: from [85.158.143.99:14038] by server-2.bemta-4.messagelabs.com id
	49/E1-17938-47B54EF4; Fri, 22 Jun 2012 11:48:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340365683!25245979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5837 invoked from network); 22 Jun 2012 11:48:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13168020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:47:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:47:37 +0100
Message-ID: <1340365656.26083.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:47:36 +0100
In-Reply-To: <1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> @@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
>      return ptr;
>  }
> 
> +static void remus_crashed_cb(libxl__egc *egc,
> +                             libxl__domain_suspend_state *dss, int rc);

I think you were going to rename this remus_failover_cb but
nevertheless:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Were you going to ping Shriram to test remus with this series applied?

> +
>  /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
>  int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> -                             uint32_t domid, int send_fd, int recv_fd)
> +                             uint32_t domid, int send_fd, int recv_fd,
> +                             const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> -    libxl_domain_type type = libxl__domain_type(gc, domid);
> -    int rc = 0;
> +    AO_CREATE(ctx, domid, ao_how);
> +    libxl__domain_suspend_state *dss;
> +    int rc;
> 
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
>      if (type == LIBXL_DOMAIN_TYPE_INVALID) {
>          rc = ERROR_FAIL;
> -        goto remus_fail;
> +        goto out;
>      }
> 
> -    if (info == NULL) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> -                   "No remus_info structure supplied for domain %d", domid);
> -        rc = ERROR_INVAL;
> -        goto remus_fail;
> -    }
> +    GCNEW(dss);
> +    dss->ao = ao;
> +    dss->callback = remus_crashed_cb;
> +    dss->domid = domid;
> +    dss->fd = send_fd;
> +    /* TODO do something with recv_fd */
> +    dss->type = type;
> +    dss->live = 1;
> +    dss->debug = 0;
> +    dss->remus = info;
> +
> +    assert(info);
> 
>      /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> 
>      /* Point of no return */
> -    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
> -                                      /* debug */ 0, info);
> +    libxl__domain_suspend(egc, dss);
> +    return AO_INPROGRESS;
> +
> + out:
> +    return AO_ABORT(rc);
> +}
> 
> +static void remus_crashed_cb(libxl__egc *egc,
> +                             libxl__domain_suspend_state *dss, int rc)
> +{
> +    STATE_AO_GC(dss->ao);
>      /*
>       * With Remus, if we reach this point, it means either
>       * backup died or some network error occurred preventing us
> @@ -683,27 +702,46 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
>      /* TBD: Remus cleanup - i.e. detach qdisc, release other
>       * resources.
>       */
> - remus_fail:
> -    GC_FREE;
> -    return rc;
> +    libxl__ao_complete(egc, ao, rc);
>  }
> 
> -int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> -                         uint32_t domid, int fd)
> +static void domain_suspend_cb(libxl__egc *egc,
> +                              libxl__domain_suspend_state *dss, int rc)
>  {
> -    GC_INIT(ctx);
> +    STATE_AO_GC(dss->ao);
> +    libxl__ao_complete(egc,ao,rc);
> +
> +}
> +
> +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
> +                         const libxl_asyncop_how *ao_how)
> +{
> +    AO_CREATE(ctx, domid, ao_how);
> +    int rc;
> +
>      libxl_domain_type type = libxl__domain_type(gc, domid);
> -    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
> -    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
> -    int rc = 0;
> +    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
> +        rc = ERROR_FAIL;
> +        goto out_err;
> +    }
> 
> -    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
> -                                      /* No Remus */ NULL);
> +    libxl__domain_suspend_state *dss;
> +    GCNEW(dss);
> 
> -    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
> -        rc = libxl__domain_save_device_model(gc, domid, fd);
> -    GC_FREE;
> -    return rc;
> +    dss->ao = ao;
> +    dss->callback = domain_suspend_cb;
> +
> +    dss->domid = domid;
> +    dss->fd = fd;
> +    dss->type = type;
> +    dss->live = flags & LIBXL_SUSPEND_LIVE;
> +    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
> +
> +    libxl__domain_suspend(egc, dss);
> +    return AO_INPROGRESS;
> +
> + out_err:
> +    return AO_ABORT(rc);
>  }
> 
>  int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 05f0e01..10d7115 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
> 
>  const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
> 
> -typedef struct {
> -#define XL_SUSPEND_DEBUG 1
> -#define XL_SUSPEND_LIVE 2
> -    int flags;
> -    int (*suspend_callback)(void *, int);
> -} libxl_domain_suspend_info;
> -
>  enum {
>      ERROR_NONSPECIFIC = -1,
>      ERROR_VERSION = -2,
> @@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
> 
>  void libxl_domain_config_init(libxl_domain_config *d_config);
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> -int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> -                             uint32_t domid, int send_fd, int recv_fd);
> -int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> -                          uint32_t domid, int fd);
> +
> +int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> +                         int flags, /* LIBXL_SUSPEND_* */
> +                         const libxl_asyncop_how *ao_how);
> +#define LIBXL_SUSPEND_DEBUG 1
> +#define LIBXL_SUSPEND_LIVE 2
> 
>  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
>   *   If this parameter is true, use co-operative resume. The guest
>   *   must support this.
>   */
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
> +
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int send_fd, int recv_fd,
> +                             const libxl_asyncop_how *ao_how);
> +
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 1d4e809..b48452c 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -17,13 +17,11 @@
> 
>  #include <glob.h>
> 
> -#include <xenctrl.h>
> -#include <xc_dom.h>
> +#include "libxl_internal.h"
> 
> +#include <xc_dom.h>
>  #include <xen/hvm/hvm_info_table.h>
> 
> -#include "libxl_internal.h"
> -
>  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> @@ -521,11 +519,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
>      return 0;
>  }
> 
> -static int libxl__domain_suspend_common_switch_qemu_logdirty
> +/*==================== Domain suspend (save) ====================*/
> +
> +static void domain_suspend_done(libxl__egc *egc,
> +                        libxl__domain_suspend_state *dss, int rc);
> +
> +/*----- callbacks, called by xc_domain_save -----*/
> +
> +int libxl__domain_suspend_common_switch_qemu_logdirty
>                                 (int domid, unsigned int enable, void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
>      char *path;
>      bool rc;
> 
> @@ -590,10 +595,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
>      return 0;
>  }
> 
> -static int libxl__domain_suspend_common_callback(void *data)
> +int libxl__domain_suspend_common_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
>      unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
>      int ret;
>      char *state = "suspend";
> @@ -714,7 +719,7 @@ static int libxl__domain_suspend_common_callback(void *data)
> 
>   guest_suspended:
>      if (dss->hvm) {
> -        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
> +        ret = libxl__domain_suspend_device_model(gc, dss->domid);
>          if (ret) {
>              LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
>              return 0;
> @@ -731,11 +736,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
>              domid, phys_offset, node);
>  }
> 
> -static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
>          uint32_t *len, void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
>      int i = 0;
>      char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
>      unsigned int num = 0;
> @@ -806,6 +811,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
>      return 0;
>  }
> 
> +/*----- remus callbacks -----*/
> +
>  static int libxl__remus_domain_suspend_callback(void *data)
>  {
>      /* TODO: Issue disk and network checkpoint reqs. */
> @@ -815,7 +822,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
>  static int libxl__remus_domain_resume_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> -    libxl__gc *gc = dss->gc;
> +    STATE_AO_GC(dss->ao);
> 
>      /* Resumes the domain and the device model */
>      if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
> @@ -828,10 +835,11 @@ static int libxl__remus_domain_resume_callback(void *data)
>  static int libxl__remus_domain_checkpoint_callback(void *data)
>  {
>      libxl__domain_suspend_state *dss = data;
> +    STATE_AO_GC(dss->ao);
> 
>      /* This would go into tailbuf. */
>      if (dss->hvm &&
> -        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
> +        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
>          return 0;
> 
>      /* TODO: Wait for disk and memory ack, release network buffer */
> @@ -839,17 +847,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
>      return 1;
>  }
> 
> -int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> -                                 libxl_domain_type type,
> -                                 int live, int debug,
> -                                 const libxl_domain_remus_info *r_info)
> +/*----- main code for suspending, in order of execution -----*/
> +
> +void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>  {
> +    STATE_AO_GC(dss->ao);
>      int port;
> -    struct save_callbacks callbacks[1];
> -    libxl__domain_suspend_state dss[1];
>      int rc = ERROR_FAIL;
>      unsigned long vm_generationid_addr;
> 
> +    /* Convenience aliases */
> +    const uint32_t domid = dss->domid;
> +    const libxl_domain_type type = dss->type;
> +    const int live = dss->live;
> +    const int debug = dss->debug;
> +    const libxl_domain_remus_info *const r_info = dss->remus;
> +    struct save_callbacks *const callbacks = &dss->callbacks;
> +
>      switch (type) {
>      case LIBXL_DOMAIN_TYPE_HVM: {
>          char *path;
> @@ -868,15 +882,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>          dss->hvm = 0;
>          break;
>      default:
> -        return ERROR_INVAL;
> +        abort();
>      }
> 
>      dss->xcflags = (live) ? XCFLAGS_LIVE : 0
>            | (debug) ? XCFLAGS_DEBUG : 0
>            | (dss->hvm) ? XCFLAGS_HVM : 0;
> 
> -    dss->domid = domid;
> -    dss->gc = gc;
>      dss->suspend_eventchn = -1;
>      dss->guest_responded = 0;
> 
> @@ -884,10 +896,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>          dss->interval = r_info->interval;
>          if (r_info->compression)
>              dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
> -        dss->save_fd = fd;
>      }
> -    else
> -        dss->save_fd = -1;
> 
>      dss->xce = xc_evtchn_open(NULL, 0);
>      if (dss->xce == NULL)
> @@ -917,10 +926,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>      callbacks->toolstack_save = libxl__toolstack_save;
>      callbacks->data = dss;
> 
> -    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
> -                        dss->hvm, vm_generationid_addr);
> -    if ( rc ) {
> -        LOGE(ERROR, "saving domain: %s",
> +    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
> +    return;
> +
> + out:
> +    domain_suspend_done(egc, dss, rc);
> +}
> +
> +void libxl__xc_domain_save_done(libxl__egc *egc,
> +                                libxl__domain_suspend_state *dss,
> +                                int rc, int retval, int errnoval)
> +{
> +    STATE_AO_GC(dss->ao);
> +
> +    /* Convenience aliases */
> +    const libxl_domain_type type = dss->type;
> +    const uint32_t domid = dss->domid;
> +
> +    if (rc)
> +        goto out;
> +
> +    if (retval) {
> +        LOGEV(ERROR, errnoval, "saving domain: %s",
>                           dss->guest_responded ?
>                           "domain responded to suspend request" :
>                           "domain did not respond to suspend request");
> @@ -928,16 +955,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>              rc = ERROR_GUEST_TIMEDOUT;
>          else
>              rc = ERROR_FAIL;
> +        goto out;
>      }
> 
> -    if (dss->suspend_eventchn > 0)
> -        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
> -                                  dss->suspend_eventchn);
> -    if (dss->xce != NULL)
> -        xc_evtchn_close(dss->xce);
> +    if (type == LIBXL_DOMAIN_TYPE_HVM) {
> +        rc = libxl__domain_suspend_device_model(gc, domid);
> +        if (rc) goto out;
> +
> +        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
> +        if (rc) goto out;
> +    }
> +
> +    rc = 0;
> 
>  out:
> -    return rc;
> +    domain_suspend_done(egc, dss, rc);
>  }
> 
>  int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
> @@ -992,6 +1024,25 @@ out:
>      return rc;
>  }
> 
> +static void domain_suspend_done(libxl__egc *egc,
> +                        libxl__domain_suspend_state *dss, int rc)
> +{
> +    STATE_AO_GC(dss->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = dss->domid;
> +
> +    if (dss->suspend_eventchn > 0)
> +        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
> +                                  dss->suspend_eventchn);
> +    if (dss->xce != NULL)
> +        xc_evtchn_close(dss->xce);
> +
> +    dss->callback(egc, dss, rc);
> +}
> +
> +/*==================== Miscellaneous ====================*/
> +
>  char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
>  {
>      char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 28478ea..7cf1b04 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
> 
>  typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
> 
> +typedef void libxl__domain_suspend_cb(libxl__egc*,
> +                                      libxl__domain_suspend_state*, int rc);
> +
>  struct libxl__domain_suspend_state {
> -    libxl__gc *gc;
> +    /* set by caller of libxl__domain_suspend */
> +    libxl__ao *ao;
> +    libxl__domain_suspend_cb *callback;
> +
> +    uint32_t domid;
> +    int fd;
> +    libxl_domain_type type;
> +    int live;
> +    int debug;
> +    const libxl_domain_remus_info *remus;
> +    /* private */
>      xc_evtchn *xce; /* event channel handle */
>      int suspend_eventchn;
> -    int domid;
>      int hvm;
> -    unsigned int xcflags;
> +    int xcflags;
>      int guest_responded;
> -    int save_fd; /* Migration stream fd (for Remus) */
>      int interval; /* checkpoint interval (for Remus) */
> +    struct save_callbacks callbacks;
>  };
> 
> 
> @@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
> 
>  /*----- Domain suspend (save) functions -----*/
> 
> -_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> -                                         libxl_domain_type type,
> -                                         int live, int debug,
> -                                         const libxl_domain_remus_info *r_info);
> +/* calls dss->callback when done */
> +_hidden void libxl__domain_suspend(libxl__egc *egc,
> +                                   libxl__domain_suspend_state *dss);
> +
> +
> +/* calls libxl__xc_domain_suspend_done when done */
> +_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
> +                                   unsigned long vm_generationid_addr);
> +/* If rc==0 then retval is the return value from xc_domain_save
> + * and errnoval is the errno value it provided.
> + * If rc!=0, retval and errnoval are undefined. */
> +_hidden void libxl__xc_domain_save_done(libxl__egc*,
> +                                        libxl__domain_suspend_state*,
> +                                        int rc, int retval, int errnoval);
> +
> +_hidden int libxl__domain_suspend_common_callback(void *data);
> +_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
> +                               (int domid, unsigned int enable, void *data);
> +_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> +        uint32_t *len, void *data);
> +
> 
>  /* calls libxl__xc_domain_restore_done when done */
>  _hidden void libxl__xc_domain_restore(libxl__egc *egc,
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> index 2f8db9f..1b481ab 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>                                &state->vm_generationid_addr, &dcs->callbacks);
>      libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
>  }
> +
> +void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
> +                           unsigned long vm_generationid_addr)
> +{
> +    STATE_AO_GC(dss->ao);
> +    int r;
> +
> +    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
> +                       &dss->callbacks, dss->hvm, vm_generationid_addr);
> +    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
> +}
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3ea95ef..19daa1c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2846,7 +2846,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
> 
>      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> 
> -    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
> +    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
>      close(fd);
> 
>      if (checkpoint)
> @@ -3008,7 +3008,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
>      pid_t child = -1;
>      int rc;
>      int send_fd = -1, recv_fd = -1;
> -    libxl_domain_suspend_info suspinfo;
>      char *away_domname;
>      char rc_buf;
>      uint8_t *config_data;
> @@ -3030,9 +3029,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
> 
>      xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
> 
> -    memset(&suspinfo, 0, sizeof(suspinfo));
> -    suspinfo.flags |= XL_SUSPEND_LIVE;
> -    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
> +    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
>      if (rc) {
>          fprintf(stderr, "migration sender: libxl_domain_suspend failed"
>                  " (rc=%d)\n", rc);
> @@ -6604,7 +6601,7 @@ int main_remus(int argc, char **argv)
>      }
> 
>      /* Point of no return */
> -    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
> +    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
> 
>      /* If we are here, it means backup has failed/domain suspend failed.
>       * Try to resume the domain and exit gracefully.
> --
> 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 Jun 22 11:51:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2OG-00017w-Lk; Fri, 22 Jun 2012 11:51:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si2OE-00017O-Kf
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:51:02 +0000
Received: from [193.109.254.147:58101] by server-5.bemta-14.messagelabs.com id
	F4/6B-04343-52C54EF4; Fri, 22 Jun 2012 11:51:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340365631!8938749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20525 invoked from network); 22 Jun 2012 11:47:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:47:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13168011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:47:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:47:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2KU-0003Wi-D7; Fri, 22 Jun 2012 11:47:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2KU-0005QO-CL;
	Fri, 22 Jun 2012 12:47:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.23358.366361.231273@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:47:10 +0100
To: Roger Pau Monne <roger.pau@citrix.com>,
In-Reply-To: <20432.48963.214910.33148@mariner.uk.xensource.com>,
	<1339676475-33265-14-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-14-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
	<20432.48963.214910.33148@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 13/13] libxl: call hotplug scripts for nic devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for nic devices, that should be called when the device is added or
> removed from a guest.

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

However, AFAICT you missed this comment of mine:
> Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
> > +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
> > +{
> ...
> > +    }
> > +
> > +out:
> > +    return rc;
> > +}
> > +
> 
> As a matter of good practice I think you should say
>       rc = 0;
> just before out, on the success path, and not rely on it having
> happened to be set to 0 by the previous successful call.

So IWBNI in the next version you did that too.

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 Jun 22 11:51:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2OG-00017w-Lk; Fri, 22 Jun 2012 11:51:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si2OE-00017O-Kf
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:51:02 +0000
Received: from [193.109.254.147:58101] by server-5.bemta-14.messagelabs.com id
	F4/6B-04343-52C54EF4; Fri, 22 Jun 2012 11:51:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340365631!8938749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20525 invoked from network); 22 Jun 2012 11:47:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:47:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,457,1336348800"; d="scan'208";a="13168011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:47:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 12:47:10 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Si2KU-0003Wi-D7; Fri, 22 Jun 2012 11:47:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Si2KU-0005QO-CL;
	Fri, 22 Jun 2012 12:47:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20452.23358.366361.231273@mariner.uk.xensource.com>
Date: Fri, 22 Jun 2012 12:47:10 +0100
To: Roger Pau Monne <roger.pau@citrix.com>,
In-Reply-To: <20432.48963.214910.33148@mariner.uk.xensource.com>,
	<1339676475-33265-14-git-send-email-roger.pau@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-14-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
	<20432.48963.214910.33148@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH v6 13/13] libxl: call hotplug scripts for nic devices from libxl"):
> Since most of the needed work is already done in previous patches,
> this patch only contains the necessary code to call hotplug scripts
> for nic devices, that should be called when the device is added or
> removed from a guest.

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

However, AFAICT you missed this comment of mine:
> Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
> > +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
> > +{
> ...
> > +    }
> > +
> > +out:
> > +    return rc;
> > +}
> > +
> 
> As a matter of good practice I think you should say
>       rc = 0;
> just before out, on the success path, and not rely on it having
> happened to be set to 0 by the previous successful call.

So IWBNI in the next version you did that too.

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 Jun 22 11:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2W7-0001e7-Qx; Fri, 22 Jun 2012 11:59: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 1Si2W6-0001e1-9n
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:59:10 +0000
Received: from [85.158.143.35:18691] by server-1.bemta-4.messagelabs.com id
	FA/BD-24392-D0E54EF4; Fri, 22 Jun 2012 11:59:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340366348!5699061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16615 invoked from network); 22 Jun 2012 11:59:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:59:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:59:08 +0100
Message-ID: <1340366346.26083.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:59:06 +0100
In-Reply-To: <1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> [...]
> +/* stream_fd is as from the caller (eventually, the application).
> + * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
> + * The actual fd value is not included in the supplied argnums; rather
> + * it will be automatically supplied by run_helper as the 2nd argument.
> + *
> + * preserve_fds are fds that the caller is intending to pass to the
> + * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
> + * An entry may be -1 in which case it will be ignored.
[...]
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int stream_fd,
> +                       const int *preserve_fds, int num_preserve_fds,
> +                       const unsigned long *argnums, int num_argnums)
> +{
> +    STATE_AO_GC(shs->ao);
> +    const char *args[4 + num_argnums];
> +    const char **arg = args;
> +    int i, rc;
> +
> +    /* Resources we must free */
> +    libxl__carefd *childs_pipes[2] = { 0,0 };
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    shs->rc = 0;
> +    shs->completed = 0;
> +    shs->pipes[0] = shs->pipes[1] = 0;
> +    libxl__ev_fd_init(&shs->readable);
> +    libxl__ev_child_init(&shs->child);
> +
> +    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                " stdin pipe", domid);
> +    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                 " stdout pipe", domid);
> +
> +    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
> +    *arg++ = mode_arg;
> +    const char **stream_fd_arg = arg++;
> +    for (i=0; i<num_argnums; i++)
> +        *arg++ = GCSPRINTF("%lu", argnums[i]);
> +    *arg++ = 0;
> +    assert(arg == args + ARRAY_SIZE(args));
> +
> +    libxl__carefd_begin();
> +    int childfd;
> +    for (childfd=0; childfd<2; childfd++) {
> +        /* Setting up the pipe for the child's fd childfd */
> +        int fds[2];
> +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> +        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
> +        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
> +        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
> +        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
> +    }
> +    libxl__carefd_unlock();
> +
> +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> +    if (!pid) {
> +        if (stream_fd <= 2) {
> +            stream_fd = dup(stream_fd);
> +            if (stream_fd < 0) {
> +                LOGE(ERROR,"dup migration stream fd");

LOGE uses CTX -- is that safe after fork, and will it go anywhere
anyway?

> +                exit(-1);
> +            }
> +        }
> +        libxl_fd_set_cloexec(CTX, stream_fd, 0);
> +        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
> +
> +        for (i=0; i<num_preserve_fds; i++)
> +            if (preserve_fds[i] >= 0)
> +                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);

The doc comment says these cannot be 0,1,2. Possibly not worth enforcing
though.

Other than those two nits:
Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 11:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 11: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 1Si2W7-0001e7-Qx; Fri, 22 Jun 2012 11:59: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 1Si2W6-0001e1-9n
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 11:59:10 +0000
Received: from [85.158.143.35:18691] by server-1.bemta-4.messagelabs.com id
	FA/BD-24392-D0E54EF4; Fri, 22 Jun 2012 11:59:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340366348!5699061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16615 invoked from network); 22 Jun 2012 11:59:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 11:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 11:59:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:59:08 +0100
Message-ID: <1340366346.26083.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 12:59:06 +0100
In-Reply-To: <1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> [...]
> +/* stream_fd is as from the caller (eventually, the application).
> + * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
> + * The actual fd value is not included in the supplied argnums; rather
> + * it will be automatically supplied by run_helper as the 2nd argument.
> + *
> + * preserve_fds are fds that the caller is intending to pass to the
> + * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
> + * An entry may be -1 in which case it will be ignored.
[...]
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int stream_fd,
> +                       const int *preserve_fds, int num_preserve_fds,
> +                       const unsigned long *argnums, int num_argnums)
> +{
> +    STATE_AO_GC(shs->ao);
> +    const char *args[4 + num_argnums];
> +    const char **arg = args;
> +    int i, rc;
> +
> +    /* Resources we must free */
> +    libxl__carefd *childs_pipes[2] = { 0,0 };
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    shs->rc = 0;
> +    shs->completed = 0;
> +    shs->pipes[0] = shs->pipes[1] = 0;
> +    libxl__ev_fd_init(&shs->readable);
> +    libxl__ev_child_init(&shs->child);
> +
> +    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                " stdin pipe", domid);
> +    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                 " stdout pipe", domid);
> +
> +    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
> +    *arg++ = mode_arg;
> +    const char **stream_fd_arg = arg++;
> +    for (i=0; i<num_argnums; i++)
> +        *arg++ = GCSPRINTF("%lu", argnums[i]);
> +    *arg++ = 0;
> +    assert(arg == args + ARRAY_SIZE(args));
> +
> +    libxl__carefd_begin();
> +    int childfd;
> +    for (childfd=0; childfd<2; childfd++) {
> +        /* Setting up the pipe for the child's fd childfd */
> +        int fds[2];
> +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> +        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
> +        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
> +        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
> +        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
> +    }
> +    libxl__carefd_unlock();
> +
> +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> +    if (!pid) {
> +        if (stream_fd <= 2) {
> +            stream_fd = dup(stream_fd);
> +            if (stream_fd < 0) {
> +                LOGE(ERROR,"dup migration stream fd");

LOGE uses CTX -- is that safe after fork, and will it go anywhere
anyway?

> +                exit(-1);
> +            }
> +        }
> +        libxl_fd_set_cloexec(CTX, stream_fd, 0);
> +        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
> +
> +        for (i=0; i<num_preserve_fds; i++)
> +            if (preserve_fds[i] >= 0)
> +                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);

The doc comment says these cannot be 0,1,2. Possibly not worth enforcing
though.

Other than those two nits:
Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:02:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:02: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 1Si2Ym-00026b-Ui; Fri, 22 Jun 2012 12:01: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 1Si2Ym-00026C-6t
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:01:56 +0000
Received: from [85.158.139.83:36932] by server-2.bemta-5.messagelabs.com id
	3B/0B-04598-3BE54EF4; Fri, 22 Jun 2012 12:01:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340366514!27718486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29033 invoked from network); 22 Jun 2012 12:01:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 12:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:01:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 13:01:54 +0100
Message-ID: <1340366513.26083.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 13:01:53 +0100
In-Reply-To: <20452.22802.102071.107153@mariner.uk.xensource.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 12:37 +0100, Ian Jackson wrote:
> 
> > -DEFINE_DEVICES_ADD(disk)
> > +DEFINE_DEVICES_ADD(disk, disk)
> > +DEFINE_DEVICES_ADD(vif, nic)
> 
> it seems to me that this is an anomaly which might be better fixed
> than worked around.
> 
> Should we rename the functions libxl_*nic* or the structures *vif* ?
> Or should we rename both, to "net" perhaps ?

If its a simple sed then I guess libxl_device_nic* is the answer -- but
if it turns into another yakk shaving exercise then perhaps we can just
live with it how it is.

libxl_device_net would also have been acceptable but doesn't seem as
analogous to libxl_device_disk to me and would have involved changing
both halves.

I don't like libxl_device_vif -- that's more an implementation thing --
cf. the TYOE_IOEMU vs TYPE_VIF conversation...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:02:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:02: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 1Si2Ym-00026b-Ui; Fri, 22 Jun 2012 12:01: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 1Si2Ym-00026C-6t
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:01:56 +0000
Received: from [85.158.139.83:36932] by server-2.bemta-5.messagelabs.com id
	3B/0B-04598-3BE54EF4; Fri, 22 Jun 2012 12:01:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340366514!27718486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29033 invoked from network); 22 Jun 2012 12:01:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 12:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:01:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 13:01:54 +0100
Message-ID: <1340366513.26083.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 13:01:53 +0100
In-Reply-To: <20452.22802.102071.107153@mariner.uk.xensource.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 12:37 +0100, Ian Jackson wrote:
> 
> > -DEFINE_DEVICES_ADD(disk)
> > +DEFINE_DEVICES_ADD(disk, disk)
> > +DEFINE_DEVICES_ADD(vif, nic)
> 
> it seems to me that this is an anomaly which might be better fixed
> than worked around.
> 
> Should we rename the functions libxl_*nic* or the structures *vif* ?
> Or should we rename both, to "net" perhaps ?

If its a simple sed then I guess libxl_device_nic* is the answer -- but
if it turns into another yakk shaving exercise then perhaps we can just
live with it how it is.

libxl_device_net would also have been acceptable but doesn't seem as
analogous to libxl_device_disk to me and would have involved changing
both halves.

I don't like libxl_device_vif -- that's more an implementation thing --
cf. the TYOE_IOEMU vs TYPE_VIF conversation...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:07:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2dj-00037b-7i; Fri, 22 Jun 2012 12:07:03 +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 1Si2dh-000373-BW
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:07:01 +0000
Received: from [193.109.254.147:41643] by server-6.bemta-14.messagelabs.com id
	83/5E-08993-4EF54EF4; Fri, 22 Jun 2012 12:07:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340366804!8942429!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10574 invoked from network); 22 Jun 2012 12:06:46 -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;
	22 Jun 2012 12:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336363200"; d="scan'208";a="199690819"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:06:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 08:06:43 -0400
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 1Si2dP-0001b1-Hm;
	Fri, 22 Jun 2012 13:06:43 +0100
Message-ID: <4FE45FD3.3060300@citrix.com>
Date: Fri, 22 Jun 2012 13:06:43 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
	<4FE471C4020000780008B5FA@nat28.tlf.novell.com>
In-Reply-To: <4FE471C4020000780008B5FA@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 12:23, Jan Beulich wrote:
>>>> On 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 22/06/12 10:43, Jan Beulich wrote:
>>>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> Following Jan's infrastructure to mark certain PCI devices as read only,
>>>> I think it wise to now consider what other PCI devices should really be
>>>> read only to dom0.
>>>>
>>>> My preliminary thoughts include:
>>>>
>>>> * PCI serial devices which Xen is configured to use
>>> But only if they're single-function.
>> Why only single function?  Should Xen not turn all the functions it is
>> using to read-only ?
> Because, just like for normal, non-PCI based serial ones, ports
> that Xen doesn't use should remain usable by Dom0. For
> example, I have a PCI card with two serial and one parallel
> ports, so with Xen using one serial port for itself, there's no
> reason not to allow Dom0 to use the other or the parallel one.

I apologize.  I originally used the term 'device' when I intended to use
'function', so I think we are arguing for the same point.

>
>>>> * Chipset devices (AMD IOMMU covered by previous patch)
>>>> * Cpu information
>>> What are you thinking of here specifically.
>> See attached lspci from a new sandybridge machine we have gained.  Quite
>> a lot of that looks rather dangerous for dom0 to play around with.
> But that can't be easily qualified into some rule, the more that
> some of these - iirc - are needed e.g. by the EDAC drivers.
>
> Jan
>

Which is why I am asking here, to see if there are some rules which
could help.  I agree that it is a sticky situation.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:07:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2dj-00037b-7i; Fri, 22 Jun 2012 12:07:03 +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 1Si2dh-000373-BW
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:07:01 +0000
Received: from [193.109.254.147:41643] by server-6.bemta-14.messagelabs.com id
	83/5E-08993-4EF54EF4; Fri, 22 Jun 2012 12:07:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340366804!8942429!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10574 invoked from network); 22 Jun 2012 12:06:46 -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;
	22 Jun 2012 12:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336363200"; d="scan'208";a="199690819"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:06:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 08:06:43 -0400
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 1Si2dP-0001b1-Hm;
	Fri, 22 Jun 2012 13:06:43 +0100
Message-ID: <4FE45FD3.3060300@citrix.com>
Date: Fri, 22 Jun 2012 13:06:43 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
	<4FE471C4020000780008B5FA@nat28.tlf.novell.com>
In-Reply-To: <4FE471C4020000780008B5FA@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 12:23, Jan Beulich wrote:
>>>> On 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 22/06/12 10:43, Jan Beulich wrote:
>>>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> Following Jan's infrastructure to mark certain PCI devices as read only,
>>>> I think it wise to now consider what other PCI devices should really be
>>>> read only to dom0.
>>>>
>>>> My preliminary thoughts include:
>>>>
>>>> * PCI serial devices which Xen is configured to use
>>> But only if they're single-function.
>> Why only single function?  Should Xen not turn all the functions it is
>> using to read-only ?
> Because, just like for normal, non-PCI based serial ones, ports
> that Xen doesn't use should remain usable by Dom0. For
> example, I have a PCI card with two serial and one parallel
> ports, so with Xen using one serial port for itself, there's no
> reason not to allow Dom0 to use the other or the parallel one.

I apologize.  I originally used the term 'device' when I intended to use
'function', so I think we are arguing for the same point.

>
>>>> * Chipset devices (AMD IOMMU covered by previous patch)
>>>> * Cpu information
>>> What are you thinking of here specifically.
>> See attached lspci from a new sandybridge machine we have gained.  Quite
>> a lot of that looks rather dangerous for dom0 to play around with.
> But that can't be easily qualified into some rule, the more that
> some of these - iirc - are needed e.g. by the EDAC drivers.
>
> Jan
>

Which is why I am asking here, to see if there are some rules which
could help.  I agree that it is a sticky situation.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:11:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si2ht-0003iR-UZ; Fri, 22 Jun 2012 12:11: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 1Si2hr-0003iC-Tv
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 12:11:20 +0000
Received: from [85.158.143.35:34450] by server-3.bemta-4.messagelabs.com id
	B9/EB-05808-7E064EF4; Fri, 22 Jun 2012 12:11:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340367078!12876584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14831 invoked from network); 22 Jun 2012 12:11:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 12:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:11:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 13:11:17 +0100
Message-ID: <1340367076.26083.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 22 Jun 2012 13:11:16 +0100
In-Reply-To: <1338551094.17466.103.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338551094.17466.103.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 12:44 +0100, Ian Campbell wrote:
> On Fri, 2012-06-01 at 03:48 +0100, Zhang, Yang Z wrote:
> > Change from v2:
> > Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> > According to Ian's comments, modified some codes to make the logic more reasonable.
> > 
> > In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
> > In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.
> > 
> > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

Hi Yang,

Have I missed a follow up posting of this patch somewhere? Or is it
still pending?

Thanks,
Ian.

> > 
> > diff -r 3b0eed731020 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
> > @@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(
> > 
> >      if (!b_info->max_vcpus)
> >          b_info->max_vcpus = 1;
> > -    if (!b_info->cur_vcpus)
> > -        b_info->cur_vcpus = 1;
> > +    if (!b_info->avail_vcpus.size) {
> > +        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
> > +            return ERROR_FAIL;
> > +        libxl_cpumap_set(&b_info->avail_vcpus, 0);
> > +    }
> > 
> >      if (!b_info->cpumap.size) {
> >          if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
> > diff -r 3b0eed731020 tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
> > @@ -160,6 +160,8 @@ static char ** libxl__build_device_model
> >      }
> >      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >          int ioemu_vifs = 0;
> > +        int nr_set_cpus = 0;
> > +        char *s;
> > 
> >          if (b_info->u.hvm.serial) {
> >              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
> > @@ -200,11 +202,14 @@ static char ** libxl__build_device_model
> >                                libxl__sprintf(gc, "%d", b_info->max_vcpus),
> >                                NULL);
> >          }
> > -        if (b_info->cur_vcpus) {
> > -            flexarray_vappend(dm_args, "-vcpu_avail",
> > -                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
> > -                              NULL);
> > -        }
> > +
> > +        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
> > +        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
> > +        flexarray_vappend(dm_args, "-vcpu_avail",
> > +                libxl__sprintf(gc, "0x%s", s),
> 
> You might as well make to_hex_string include the 0x?
> 
> > +                NULL);
> > +        free(s);
> > +
> >          for (i = 0; i < num_vifs; i++) {
> >              if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
> >                  char *smac = libxl__sprintf(gc,
> > diff -r 3b0eed731020 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
> > @@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
> >      ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
> > +        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus, i))
> >                              ? "offline" : "online";
> 
> Weren't you going to drop the "i &&" and invert the ternary?
> 
> >      }
> > 
> > @@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
> >      va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
> >      va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
> >      va_hvm->nr_vcpus = info->max_vcpus;
> > -    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
> > +    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
> 
> This needs some sort of limit check, probably in terms of HVM_MAX_VCPUS.
> otherwise a particularly large vcpus= in the config will cause mayhem...
> 
> I guess this should probably be done in
> libxl__domain_build_info_setdefaults.
> 
> > diff -r 3b0eed731020 tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
> > @@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
> >      cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
> >  }
> > 
> > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
> > +{
> > +    int i, nr_set_cpus = 0;
> > +    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))
> 
> Please stop this habit of yours of casting away the const to make the
> warning go away, it is almost always wrong and on the odd occasion that
> it is right it should have a comment explaining why...
> 
> In this case please make libxl_cpumap_test const correct instead.
> 
> > +        nr_set_cpus++;
> > +
> > +    return nr_set_cpus;
> > +}
> > +
> > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
> > +{
> > +    int i = cpumap->size;
> > +    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
> > +    char *q = p;
> > +    while(--i >= 0) {
> > +        sprintf((char *)p, "%02x", cpumap->map[i]);
> 
> Why this cast?
> 
> > +        p += 2;
> > +    }
> > +    *p = '\0';
> > +    return q;
> > +}
> > +
> >  int libxl_get_max_cpus(libxl_ctx *ctx)
> >  {
> >      return xc_get_max_cpus(ctx->xch);
> > diff -r 3b0eed731020 tools/libxl/libxl_utils.h
> > --- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
> > @@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
> >  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
> >  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
> >  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
> 
> Please add a comment describing this function, it should remind the
> caller that they are responsible for freeing the result.
> 
> > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
> >  static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
> >  {
> >      memset(cpumap->map, -1, cpumap->size);
> > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > 
> >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> >          b_info->max_vcpus = l;
> > -        b_info->cur_vcpus = (1 << l) - 1;
> > +
> > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > +            exit(1);
> > +        }
> > +        libxl_cpumap_set_none(&b_info->avail_vcpus);
> > +        while (l-- > 0)
> > +            libxl_cpumap_set((&b_info->avail_vcpus), l);
> 
> This while loop is == libxl_cpumap_set_any.
> 
> >      }
> > 
> >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 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 Fri Jun 22 12:11:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si2ht-0003iR-UZ; Fri, 22 Jun 2012 12:11: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 1Si2hr-0003iC-Tv
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 12:11:20 +0000
Received: from [85.158.143.35:34450] by server-3.bemta-4.messagelabs.com id
	B9/EB-05808-7E064EF4; Fri, 22 Jun 2012 12:11:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340367078!12876584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14831 invoked from network); 22 Jun 2012 12:11:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 12:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:11:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 13:11:17 +0100
Message-ID: <1340367076.26083.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 22 Jun 2012 13:11:16 +0100
In-Reply-To: <1338551094.17466.103.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338551094.17466.103.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-01 at 12:44 +0100, Ian Campbell wrote:
> On Fri, 2012-06-01 at 03:48 +0100, Zhang, Yang Z wrote:
> > Change from v2:
> > Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> > According to Ian's comments, modified some codes to make the logic more reasonable.
> > 
> > In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
> > In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.
> > 
> > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

Hi Yang,

Have I missed a follow up posting of this patch somewhere? Or is it
still pending?

Thanks,
Ian.

> > 
> > diff -r 3b0eed731020 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
> > @@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(
> > 
> >      if (!b_info->max_vcpus)
> >          b_info->max_vcpus = 1;
> > -    if (!b_info->cur_vcpus)
> > -        b_info->cur_vcpus = 1;
> > +    if (!b_info->avail_vcpus.size) {
> > +        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
> > +            return ERROR_FAIL;
> > +        libxl_cpumap_set(&b_info->avail_vcpus, 0);
> > +    }
> > 
> >      if (!b_info->cpumap.size) {
> >          if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
> > diff -r 3b0eed731020 tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
> > @@ -160,6 +160,8 @@ static char ** libxl__build_device_model
> >      }
> >      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >          int ioemu_vifs = 0;
> > +        int nr_set_cpus = 0;
> > +        char *s;
> > 
> >          if (b_info->u.hvm.serial) {
> >              flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
> > @@ -200,11 +202,14 @@ static char ** libxl__build_device_model
> >                                libxl__sprintf(gc, "%d", b_info->max_vcpus),
> >                                NULL);
> >          }
> > -        if (b_info->cur_vcpus) {
> > -            flexarray_vappend(dm_args, "-vcpu_avail",
> > -                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
> > -                              NULL);
> > -        }
> > +
> > +        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
> > +        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
> > +        flexarray_vappend(dm_args, "-vcpu_avail",
> > +                libxl__sprintf(gc, "0x%s", s),
> 
> You might as well make to_hex_string include the 0x?
> 
> > +                NULL);
> > +        free(s);
> > +
> >          for (i = 0; i < num_vifs; i++) {
> >              if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
> >                  char *smac = libxl__sprintf(gc,
> > diff -r 3b0eed731020 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
> > @@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
> >      ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
> > +        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus, i))
> >                              ? "offline" : "online";
> 
> Weren't you going to drop the "i &&" and invert the ternary?
> 
> >      }
> > 
> > @@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
> >      va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
> >      va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
> >      va_hvm->nr_vcpus = info->max_vcpus;
> > -    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
> > +    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
> 
> This needs some sort of limit check, probably in terms of HVM_MAX_VCPUS.
> otherwise a particularly large vcpus= in the config will cause mayhem...
> 
> I guess this should probably be done in
> libxl__domain_build_info_setdefaults.
> 
> > diff -r 3b0eed731020 tools/libxl/libxl_utils.c
> > --- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
> > @@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
> >      cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
> >  }
> > 
> > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
> > +{
> > +    int i, nr_set_cpus = 0;
> > +    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))
> 
> Please stop this habit of yours of casting away the const to make the
> warning go away, it is almost always wrong and on the odd occasion that
> it is right it should have a comment explaining why...
> 
> In this case please make libxl_cpumap_test const correct instead.
> 
> > +        nr_set_cpus++;
> > +
> > +    return nr_set_cpus;
> > +}
> > +
> > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
> > +{
> > +    int i = cpumap->size;
> > +    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
> > +    char *q = p;
> > +    while(--i >= 0) {
> > +        sprintf((char *)p, "%02x", cpumap->map[i]);
> 
> Why this cast?
> 
> > +        p += 2;
> > +    }
> > +    *p = '\0';
> > +    return q;
> > +}
> > +
> >  int libxl_get_max_cpus(libxl_ctx *ctx)
> >  {
> >      return xc_get_max_cpus(ctx->xch);
> > diff -r 3b0eed731020 tools/libxl/libxl_utils.h
> > --- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
> > @@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
> >  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
> >  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
> >  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
> 
> Please add a comment describing this function, it should remind the
> caller that they are responsible for freeing the result.
> 
> > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
> >  static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
> >  {
> >      memset(cpumap->map, -1, cpumap->size);
> > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > 
> >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> >          b_info->max_vcpus = l;
> > -        b_info->cur_vcpus = (1 << l) - 1;
> > +
> > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > +            exit(1);
> > +        }
> > +        libxl_cpumap_set_none(&b_info->avail_vcpus);
> > +        while (l-- > 0)
> > +            libxl_cpumap_set((&b_info->avail_vcpus), l);
> 
> This while loop is == libxl_cpumap_set_any.
> 
> >      }
> > 
> >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 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 Fri Jun 22 12:19:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si2pz-00048e-U5; Fri, 22 Jun 2012 12:19: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 1Si2py-00048Z-Kw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:19:42 +0000
Received: from [85.158.138.51:10509] by server-6.bemta-3.messagelabs.com id
	8E/E5-11602-DD264EF4; Fri, 22 Jun 2012 12:19:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340367581!27909104!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8261 invoked from network); 22 Jun 2012 12:19:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 12:19:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 13:19:40 +0100
Message-Id: <4FE47F28020000780008B686@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 13:20:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
	<4FE471C4020000780008B5FA@nat28.tlf.novell.com>
	<4FE45FD3.3060300@citrix.com>
In-Reply-To: <4FE45FD3.3060300@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 14:06, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/06/12 12:23, Jan Beulich wrote:
>>>>> On 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 22/06/12 10:43, Jan Beulich wrote:
>>>>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>> Following Jan's infrastructure to mark certain PCI devices as read only,
>>>>> I think it wise to now consider what other PCI devices should really be
>>>>> read only to dom0.
>>>>>
>>>>> My preliminary thoughts include:
>>>>>
>>>>> * PCI serial devices which Xen is configured to use
>>>> But only if they're single-function.
>>> Why only single function?  Should Xen not turn all the functions it is
>>> using to read-only ?
>> Because, just like for normal, non-PCI based serial ones, ports
>> that Xen doesn't use should remain usable by Dom0. For
>> example, I have a PCI card with two serial and one parallel
>> ports, so with Xen using one serial port for itself, there's no
>> reason not to allow Dom0 to use the other or the parallel one.
> 
> I apologize.  I originally used the term 'device' when I intended to use
> 'function', so I think we are arguing for the same point.

And I understood you meaning so - from a PCI terminology pov.
Multi-function here, however, means multiple serial/parallel ports
within a single PCI function (PCI_CLASS_COMMUNICATION_MULTISERIAL
or PCI_CLASS_COMMUNICATION_OTHER). Hence we shouldn't hide a
full S:B:D.F just because we use some portion of 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 Jun 22 12:19:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si2pz-00048e-U5; Fri, 22 Jun 2012 12:19: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 1Si2py-00048Z-Kw
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:19:42 +0000
Received: from [85.158.138.51:10509] by server-6.bemta-3.messagelabs.com id
	8E/E5-11602-DD264EF4; Fri, 22 Jun 2012 12:19:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340367581!27909104!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8261 invoked from network); 22 Jun 2012 12:19:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 12:19:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 13:19:40 +0100
Message-Id: <4FE47F28020000780008B686@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 13:20:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
	<4FE471C4020000780008B5FA@nat28.tlf.novell.com>
	<4FE45FD3.3060300@citrix.com>
In-Reply-To: <4FE45FD3.3060300@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22.06.12 at 14:06, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 22/06/12 12:23, Jan Beulich wrote:
>>>>> On 22.06.12 at 12:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 22/06/12 10:43, Jan Beulich wrote:
>>>>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>> Following Jan's infrastructure to mark certain PCI devices as read only,
>>>>> I think it wise to now consider what other PCI devices should really be
>>>>> read only to dom0.
>>>>>
>>>>> My preliminary thoughts include:
>>>>>
>>>>> * PCI serial devices which Xen is configured to use
>>>> But only if they're single-function.
>>> Why only single function?  Should Xen not turn all the functions it is
>>> using to read-only ?
>> Because, just like for normal, non-PCI based serial ones, ports
>> that Xen doesn't use should remain usable by Dom0. For
>> example, I have a PCI card with two serial and one parallel
>> ports, so with Xen using one serial port for itself, there's no
>> reason not to allow Dom0 to use the other or the parallel one.
> 
> I apologize.  I originally used the term 'device' when I intended to use
> 'function', so I think we are arguing for the same point.

And I understood you meaning so - from a PCI terminology pov.
Multi-function here, however, means multiple serial/parallel ports
within a single PCI function (PCI_CLASS_COMMUNICATION_MULTISERIAL
or PCI_CLASS_COMMUNICATION_OTHER). Hence we shouldn't hide a
full S:B:D.F just because we use some portion of 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 Jun 22 12:22:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:22: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 1Si2sZ-0004Fd-Fx; Fri, 22 Jun 2012 12:22:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si2sX-0004FS-NC
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 12:22:22 +0000
Received: from [85.158.143.35:45464] by server-3.bemta-4.messagelabs.com id
	9A/4A-05808-C7364EF4; Fri, 22 Jun 2012 12:22:20 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340367722!12878333!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22951 invoked from network); 22 Jun 2012 12:22:03 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 12:22:03 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A7B6F20BDB
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Jun 2012 08:22:02 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute4.internal (MEProxy); Fri, 22 Jun 2012 08:22:02 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:content-type; s=mesmtp; bh=aHa6mJEgj9sjqnJAJgvDEldL7
	34=; b=bSY39fIryFtjKbWixXZzhR8iCPcq//deGeXwaSNwWCqifSIOH9KyoJJ0K
	PENiEYxSPqZmnKXNd9/HoyhRTd18MgvqDKqN4jckals3J9llrjNMK45UJBAOrBXl
	rENYFaeyL/8Q5wiTLCXTWVE72YQuqbdA9I/pmR8y6LlqvleOCE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:content-type; s=smtpout; bh=aHa6mJEgj9sjqnJAJgvDEldL734
	=; b=j5LW6dFZVrcO/KkKN3tcygB08HB0CMNvR62rRnxN1ZRk6HtzktY90c0z2Mt
	pPfWjx8Q+dc0gBVD+h4t1IP60zQH4Qer8urriQ4DWF4XJ2mNadneuxbqcTE4zSRt
	9KSBdewECZ0Ybw17ckD2iv4Cpybwji3Xt/FizPVrbjDeD8Io=
X-Sasl-enc: tLRaBMtY0M7vzYSPfcIsY4US6j9vOwbgrEd6mCSCKinG 1340367722
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id 034338E0216;
	Fri, 22 Jun 2012 08:22:01 -0400 (EDT)
Message-ID: <4FE46366.8010104@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 14:21:58 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.2
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>
Subject: [Xen-devel] Strange kernel BUG() on PV DomU 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: multipart/mixed; boundary="===============0827160727928925549=="
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)
--===============0827160727928925549==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1AD961FB7F90801FC802C034"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1AD961FB7F90801FC802C034
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

=46rom time to time (every several weeks or even less) I run into a
strange Dom0 kernel BUG() that manifests itself with the following
message (see the end of the message). The Dom0 and VM kernels are 3.2.7
pvops, and the Xen hypervisor is 4.1.2 both with only some minor,
irrelevant (I think) modifications for Qubes.

The bug is very hard to reproduce, but once this BUG() starts being
signaled, it consistently prevents me from starting any new VMs in the
system (e.g. tried over a dozen of times now, and every time the VM boot
fails).

The following lines in the VM kernel are responsible for signaling the
BUG():

  if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
        BUG();

=2E..yet, there is nothing in the xl dmesg that would provide more info
why this hypercall fails. Ah, that's because there are not printk's in
the hypercall code:

   case VCPUOP_initialise:
        if ( v->vcpu_info =3D=3D &dummy_vcpu_info )
            return -EINVAL;

        if ( (ctxt =3D xmalloc(struct vcpu_guest_context)) =3D=3D NULL )
            return -ENOMEM;

        if ( copy_from_guest(ctxt, arg, 1) )
        {
            xfree(ctxt);
            return -EFAULT;
        }

        domain_lock(d);
        rc =3D -EEXIST;
        if ( !v->is_initialised )
            rc =3D boot_vcpu(d, vcpuid, ctxt);
        domain_unlock(d);

        xfree(ctxt);
        break;

So, looking at the above it seems like it might be failing because of
xmalloc() fails, however Xen seems to have enough memory as reported by
xl info:

total_memory           : 8074
free_memory            : 66
free_cpus              : 0

Any ideas what might be the cause?

FWIW, below the actual oops message.

Thanks,
joanna.




[    0.004356] ------------[ cut here ]------------
[    0.004361] kernel BUG at
/home/user/qubes-src/kernel/kernel-3.2.7/linux-3.2.7/arch/x86/xen/smp.c:3=
22!
[    0.004366] invalid opcode: 0000 [#1] SMP
[    0.004370] CPU 0
[    0.004372] Modules linked in:
[    0.004376]
[    0.004379] Pid: 1, comm: swapper/0 Not tainted
3.2.7-5.pvops.qubes.x86_64 #1
[    0.004385] RIP: e030:[<ffffffff8143a229>]  [<ffffffff8143a229>]
cpu_initialize_context+0x263/0x280
[    0.004396] RSP: e02b:ffff880018063e10  EFLAGS: 00010282
[    0.004399] RAX: fffffffffffffff4 RBX: ffff8800180c0000 RCX:
0000000000000000
[    0.004404] RDX: ffff8800180c0000 RSI: 0000000000000001 RDI:
0000000000000000
[    0.004408] RBP: ffff880018063e50 R08: 00003ffffffff000 R09:
ffff880000000000
[    0.004412] R10: ffff8800180c0000 R11: 0000000000002000 R12:
0000000000000001
[    0.004417] R13: ffff880018f82d30 R14: ffff88001806e0c0 R15:
00000000000a98ed
[    0.004429] FS:  0000000000000000(0000) GS:ffff880018f5c000(0000)
knlGS:0000000000000000
[    0.004436] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.004441] CR2: 0000000000000000 CR3: 0000000001805000 CR4:
0000000000002660
[    0.004447] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    0.004452] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[    0.004459] Process swapper/0 (pid: 1, threadinfo ffff880018062000,
task ffff880018060040)
[    0.004465] Stack:
[    0.004469]  ffff88001806e0c0 0000000000018f7b ffffffff81866c80
0000000000000001
[    0.004479]  ffff88001806e0c0 0000000000000001 ffffffff81866c80
0000000000000001
[    0.004490]  ffff880018063e80 ffffffff8143a2e1 ffff880018063e70
0000000000000000
[    0.004500] Call Trace:
[    0.004507]  [<ffffffff8143a2e1>] xen_cpu_up+0x9b/0x115
[    0.004513]  [<ffffffff81440ad8>] _cpu_up+0x9c/0x10e
[    0.004520]  [<ffffffff81440bbf>] cpu_up+0x75/0x85
[    0.004527]  [<ffffffff818998f1>] smp_init+0x46/0x9e
[    0.004533]  [<ffffffff8188263c>] kernel_init+0x89/0x142
[    0.004541]  [<ffffffff814518b4>] kernel_thread_helper+0x4/0x10
[    0.004549]  [<ffffffff8144f973>] ? int_ret_from_sys_call+0x7/0x1b
[    0.004558]  [<ffffffff81447d7c>] ? retint_restore_args+0x5/0x6
[    0.004565]  [<ffffffff814518b0>] ? gs_change+0x13/0x13
[    0.004570] Code: 74 0d 48 ba ff ff ff ff ff ff ff 3f 48 21 d0 48 c1
e0 0c 31 ff 49 63 f4 48 89 83 90 13 00 00 48 89 da e8 db 70 bc ff 85 c0
74 04 <0f> 0b eb fe 48 89 df e8 db f6 ce ff 31 c0 48 83 c4 18 5b 41 5c
[    0.004653] RIP  [<ffffffff8143a229>] cpu_initialize_context+0x263/0x2=
80
[    0.004661]  RSP <ffff880018063e10>
[    0.004672] ---[ end trace 4eaa2a86a8e2da22 ]---
[    0.004686] Kernel panic - not syncing: Attempted to kill init!
[    0.004692] Pid: 1, comm: swapper/0 Tainted: G      D
3.2.7-5.pvops.qubes.x86_64 #1
[    0.004698] Call Trace:
[    0.004704]  [<ffffffff81444c4a>] panic+0x8c/0x1a2
[    0.004712]  [<ffffffff81059814>] ? enqueue_entity+0x74/0x2f0
[    0.004719]  [<ffffffff8106113d>] forget_original_parent+0x34d/0x360
[    0.004728]  [<ffffffff8100a05f>] ? xen_restore_fl_direct_reloc+0x4/0x=
4
[    0.004735]  [<ffffffff814478b1>] ? _raw_spin_unlock_irqrestore+0x11/0=
x20
[    0.004743]  [<ffffffff8104acb3>] ? sched_move_task+0x93/0x150
[    0.004750]  [<ffffffff81061162>] exit_notify+0x12/0x190
[    0.004756]  [<ffffffff81062a3d>] do_exit+0x1ed/0x3e0
[    0.004763]  [<ffffffff814489e6>] oops_end+0xa6/0xf0
[    0.004770]  [<ffffffff81016476>] die+0x56/0x90
[    0.004776]  [<ffffffff81448584>] do_trap+0xc4/0x170
[    0.004783]  [<ffffffff81014440>] do_invalid_op+0x90/0xb0
[    0.004790]  [<ffffffff8143a229>] ? cpu_initialize_context+0x263/0x280=

[    0.004799]  [<ffffffff81128ce4>] ? cache_grow.clone.0+0x2b4/0x3b0
[    0.004805]  [<ffffffff8100a05f>] ? xen_restore_fl_direct_reloc+0x4/0x=
4
[    0.004812]  [<ffffffff810052f1>] ? pte_mfn_to_pfn+0x71/0xf0
[    0.004820]  [<ffffffff8145172b>] invalid_op+0x1b/0x20
[    0.004827]  [<ffffffff8143a229>] ? cpu_initialize_context+0x263/0x280=

[    0.004834]  [<ffffffff8143a2e1>] xen_cpu_up+0x9b/0x115
[    0.004840]  [<ffffffff81440ad8>] _cpu_up+0x9c/0x10e
[    0.004846]  [<ffffffff81440bbf>] cpu_up+0x75/0x85
[    0.004852]  [<ffffffff818998f1>] smp_init+0x46/0x9e
[    0.004858]  [<ffffffff8188263c>] kernel_init+0x89/0x142
[    0.004864]  [<ffffffff814518b4>] kernel_thread_helper+0x4/0x10
[    0.004871]  [<ffffffff8144f973>] ? int_ret_from_sys_call+0x7/0x1b
[    0.004878]  [<ffffffff81447d7c>] ? retint_restore_args+0x5/0x6
[    0.004885]  [<ffffffff814518b0>] ? gs_change+0x13/0x13




--------------enig1AD961FB7F90801FC802C034
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5GNmAAoJEDaIqHeRBUM01a8IAMEIVlHl7pQrhcEnFX4dEvqR
my/Vx6GrmyFHa8JrvkbrmF7Vb4LizRQu5MV9MIYxW40Cl8iyBAryJ/QlZDH+Rq+M
x6yoDiYvbjgsJftDVzQ2S9EPD988ms0wCH+7SxlFHgbi94m6VF3KUUT47vTP23UR
+rk8wgGnTH14zqxDPmuw6VkRhzm8i2/6zyUmY//puPJif0+oIdIEmKp+LWUOxsU9
TKjlr5njhYegDG+pUzaR7a2jWm5IAdS2Rvex5pLFaJXC9Iu9XJDhWGmHxPkHTsiZ
CKe7R/Wsgr8Dw4oGYA6ytVd69SZ73ZL0s1DyLw8JY7qSbAGOMxZUK+jxKrdhRoQ=
=VByX
-----END PGP SIGNATURE-----

--------------enig1AD961FB7F90801FC802C034--


--===============0827160727928925549==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0827160727928925549==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 12:22:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:22: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 1Si2sZ-0004Fd-Fx; Fri, 22 Jun 2012 12:22:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si2sX-0004FS-NC
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 12:22:22 +0000
Received: from [85.158.143.35:45464] by server-3.bemta-4.messagelabs.com id
	9A/4A-05808-C7364EF4; Fri, 22 Jun 2012 12:22:20 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340367722!12878333!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22951 invoked from network); 22 Jun 2012 12:22:03 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 12:22:03 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A7B6F20BDB
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Jun 2012 08:22:02 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute4.internal (MEProxy); Fri, 22 Jun 2012 08:22:02 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:content-type; s=mesmtp; bh=aHa6mJEgj9sjqnJAJgvDEldL7
	34=; b=bSY39fIryFtjKbWixXZzhR8iCPcq//deGeXwaSNwWCqifSIOH9KyoJJ0K
	PENiEYxSPqZmnKXNd9/HoyhRTd18MgvqDKqN4jckals3J9llrjNMK45UJBAOrBXl
	rENYFaeyL/8Q5wiTLCXTWVE72YQuqbdA9I/pmR8y6LlqvleOCE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:content-type; s=smtpout; bh=aHa6mJEgj9sjqnJAJgvDEldL734
	=; b=j5LW6dFZVrcO/KkKN3tcygB08HB0CMNvR62rRnxN1ZRk6HtzktY90c0z2Mt
	pPfWjx8Q+dc0gBVD+h4t1IP60zQH4Qer8urriQ4DWF4XJ2mNadneuxbqcTE4zSRt
	9KSBdewECZ0Ybw17ckD2iv4Cpybwji3Xt/FizPVrbjDeD8Io=
X-Sasl-enc: tLRaBMtY0M7vzYSPfcIsY4US6j9vOwbgrEd6mCSCKinG 1340367722
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id 034338E0216;
	Fri, 22 Jun 2012 08:22:01 -0400 (EDT)
Message-ID: <4FE46366.8010104@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 14:21:58 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.2
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>
Subject: [Xen-devel] Strange kernel BUG() on PV DomU 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: multipart/mixed; boundary="===============0827160727928925549=="
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)
--===============0827160727928925549==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1AD961FB7F90801FC802C034"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1AD961FB7F90801FC802C034
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

=46rom time to time (every several weeks or even less) I run into a
strange Dom0 kernel BUG() that manifests itself with the following
message (see the end of the message). The Dom0 and VM kernels are 3.2.7
pvops, and the Xen hypervisor is 4.1.2 both with only some minor,
irrelevant (I think) modifications for Qubes.

The bug is very hard to reproduce, but once this BUG() starts being
signaled, it consistently prevents me from starting any new VMs in the
system (e.g. tried over a dozen of times now, and every time the VM boot
fails).

The following lines in the VM kernel are responsible for signaling the
BUG():

  if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
        BUG();

=2E..yet, there is nothing in the xl dmesg that would provide more info
why this hypercall fails. Ah, that's because there are not printk's in
the hypercall code:

   case VCPUOP_initialise:
        if ( v->vcpu_info =3D=3D &dummy_vcpu_info )
            return -EINVAL;

        if ( (ctxt =3D xmalloc(struct vcpu_guest_context)) =3D=3D NULL )
            return -ENOMEM;

        if ( copy_from_guest(ctxt, arg, 1) )
        {
            xfree(ctxt);
            return -EFAULT;
        }

        domain_lock(d);
        rc =3D -EEXIST;
        if ( !v->is_initialised )
            rc =3D boot_vcpu(d, vcpuid, ctxt);
        domain_unlock(d);

        xfree(ctxt);
        break;

So, looking at the above it seems like it might be failing because of
xmalloc() fails, however Xen seems to have enough memory as reported by
xl info:

total_memory           : 8074
free_memory            : 66
free_cpus              : 0

Any ideas what might be the cause?

FWIW, below the actual oops message.

Thanks,
joanna.




[    0.004356] ------------[ cut here ]------------
[    0.004361] kernel BUG at
/home/user/qubes-src/kernel/kernel-3.2.7/linux-3.2.7/arch/x86/xen/smp.c:3=
22!
[    0.004366] invalid opcode: 0000 [#1] SMP
[    0.004370] CPU 0
[    0.004372] Modules linked in:
[    0.004376]
[    0.004379] Pid: 1, comm: swapper/0 Not tainted
3.2.7-5.pvops.qubes.x86_64 #1
[    0.004385] RIP: e030:[<ffffffff8143a229>]  [<ffffffff8143a229>]
cpu_initialize_context+0x263/0x280
[    0.004396] RSP: e02b:ffff880018063e10  EFLAGS: 00010282
[    0.004399] RAX: fffffffffffffff4 RBX: ffff8800180c0000 RCX:
0000000000000000
[    0.004404] RDX: ffff8800180c0000 RSI: 0000000000000001 RDI:
0000000000000000
[    0.004408] RBP: ffff880018063e50 R08: 00003ffffffff000 R09:
ffff880000000000
[    0.004412] R10: ffff8800180c0000 R11: 0000000000002000 R12:
0000000000000001
[    0.004417] R13: ffff880018f82d30 R14: ffff88001806e0c0 R15:
00000000000a98ed
[    0.004429] FS:  0000000000000000(0000) GS:ffff880018f5c000(0000)
knlGS:0000000000000000
[    0.004436] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.004441] CR2: 0000000000000000 CR3: 0000000001805000 CR4:
0000000000002660
[    0.004447] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    0.004452] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[    0.004459] Process swapper/0 (pid: 1, threadinfo ffff880018062000,
task ffff880018060040)
[    0.004465] Stack:
[    0.004469]  ffff88001806e0c0 0000000000018f7b ffffffff81866c80
0000000000000001
[    0.004479]  ffff88001806e0c0 0000000000000001 ffffffff81866c80
0000000000000001
[    0.004490]  ffff880018063e80 ffffffff8143a2e1 ffff880018063e70
0000000000000000
[    0.004500] Call Trace:
[    0.004507]  [<ffffffff8143a2e1>] xen_cpu_up+0x9b/0x115
[    0.004513]  [<ffffffff81440ad8>] _cpu_up+0x9c/0x10e
[    0.004520]  [<ffffffff81440bbf>] cpu_up+0x75/0x85
[    0.004527]  [<ffffffff818998f1>] smp_init+0x46/0x9e
[    0.004533]  [<ffffffff8188263c>] kernel_init+0x89/0x142
[    0.004541]  [<ffffffff814518b4>] kernel_thread_helper+0x4/0x10
[    0.004549]  [<ffffffff8144f973>] ? int_ret_from_sys_call+0x7/0x1b
[    0.004558]  [<ffffffff81447d7c>] ? retint_restore_args+0x5/0x6
[    0.004565]  [<ffffffff814518b0>] ? gs_change+0x13/0x13
[    0.004570] Code: 74 0d 48 ba ff ff ff ff ff ff ff 3f 48 21 d0 48 c1
e0 0c 31 ff 49 63 f4 48 89 83 90 13 00 00 48 89 da e8 db 70 bc ff 85 c0
74 04 <0f> 0b eb fe 48 89 df e8 db f6 ce ff 31 c0 48 83 c4 18 5b 41 5c
[    0.004653] RIP  [<ffffffff8143a229>] cpu_initialize_context+0x263/0x2=
80
[    0.004661]  RSP <ffff880018063e10>
[    0.004672] ---[ end trace 4eaa2a86a8e2da22 ]---
[    0.004686] Kernel panic - not syncing: Attempted to kill init!
[    0.004692] Pid: 1, comm: swapper/0 Tainted: G      D
3.2.7-5.pvops.qubes.x86_64 #1
[    0.004698] Call Trace:
[    0.004704]  [<ffffffff81444c4a>] panic+0x8c/0x1a2
[    0.004712]  [<ffffffff81059814>] ? enqueue_entity+0x74/0x2f0
[    0.004719]  [<ffffffff8106113d>] forget_original_parent+0x34d/0x360
[    0.004728]  [<ffffffff8100a05f>] ? xen_restore_fl_direct_reloc+0x4/0x=
4
[    0.004735]  [<ffffffff814478b1>] ? _raw_spin_unlock_irqrestore+0x11/0=
x20
[    0.004743]  [<ffffffff8104acb3>] ? sched_move_task+0x93/0x150
[    0.004750]  [<ffffffff81061162>] exit_notify+0x12/0x190
[    0.004756]  [<ffffffff81062a3d>] do_exit+0x1ed/0x3e0
[    0.004763]  [<ffffffff814489e6>] oops_end+0xa6/0xf0
[    0.004770]  [<ffffffff81016476>] die+0x56/0x90
[    0.004776]  [<ffffffff81448584>] do_trap+0xc4/0x170
[    0.004783]  [<ffffffff81014440>] do_invalid_op+0x90/0xb0
[    0.004790]  [<ffffffff8143a229>] ? cpu_initialize_context+0x263/0x280=

[    0.004799]  [<ffffffff81128ce4>] ? cache_grow.clone.0+0x2b4/0x3b0
[    0.004805]  [<ffffffff8100a05f>] ? xen_restore_fl_direct_reloc+0x4/0x=
4
[    0.004812]  [<ffffffff810052f1>] ? pte_mfn_to_pfn+0x71/0xf0
[    0.004820]  [<ffffffff8145172b>] invalid_op+0x1b/0x20
[    0.004827]  [<ffffffff8143a229>] ? cpu_initialize_context+0x263/0x280=

[    0.004834]  [<ffffffff8143a2e1>] xen_cpu_up+0x9b/0x115
[    0.004840]  [<ffffffff81440ad8>] _cpu_up+0x9c/0x10e
[    0.004846]  [<ffffffff81440bbf>] cpu_up+0x75/0x85
[    0.004852]  [<ffffffff818998f1>] smp_init+0x46/0x9e
[    0.004858]  [<ffffffff8188263c>] kernel_init+0x89/0x142
[    0.004864]  [<ffffffff814518b4>] kernel_thread_helper+0x4/0x10
[    0.004871]  [<ffffffff8144f973>] ? int_ret_from_sys_call+0x7/0x1b
[    0.004878]  [<ffffffff81447d7c>] ? retint_restore_args+0x5/0x6
[    0.004885]  [<ffffffff814518b0>] ? gs_change+0x13/0x13




--------------enig1AD961FB7F90801FC802C034
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5GNmAAoJEDaIqHeRBUM01a8IAMEIVlHl7pQrhcEnFX4dEvqR
my/Vx6GrmyFHa8JrvkbrmF7Vb4LizRQu5MV9MIYxW40Cl8iyBAryJ/QlZDH+Rq+M
x6yoDiYvbjgsJftDVzQ2S9EPD988ms0wCH+7SxlFHgbi94m6VF3KUUT47vTP23UR
+rk8wgGnTH14zqxDPmuw6VkRhzm8i2/6zyUmY//puPJif0+oIdIEmKp+LWUOxsU9
TKjlr5njhYegDG+pUzaR7a2jWm5IAdS2Rvex5pLFaJXC9Iu9XJDhWGmHxPkHTsiZ
CKe7R/Wsgr8Dw4oGYA6ytVd69SZ73ZL0s1DyLw8JY7qSbAGOMxZUK+jxKrdhRoQ=
=VByX
-----END PGP SIGNATURE-----

--------------enig1AD961FB7F90801FC802C034--


--===============0827160727928925549==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0827160727928925549==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 12:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2tS-0004LW-3f; Fri, 22 Jun 2012 12:23: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 1Si2tQ-0004LA-22
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:23:16 +0000
Received: from [85.158.138.51:32053] by server-5.bemta-3.messagelabs.com id
	4A/7E-01572-3B364EF4; Fri, 22 Jun 2012 12:23:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340367794!28982369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10298 invoked from network); 22 Jun 2012 12:23:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 12:23:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:23:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 13:23:00 +0100
Message-ID: <1340367778.26083.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 13:22:58 +0100
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gRnJpLCAyMDEyLTA2LTE1IGF0IDEyOjUzICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBU
aGlzIGlzIHY0IG9mIG15IHNlcmllcyB0byBhc3luY2lmeSBzYXZlL3Jlc3RvcmUuICBBbGwgY29t
bWVudHMgaGF2ZQo+IGJlZW4gYWRkcmVzc2VkLgoKQnVpbGRpbmcgd2l0aCB0aGlzIEkgZ2V0Ogog
ICAgICAgIGNjMTogd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKICAgICAgICBsaWJ4
bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9kb21haW5fZGVzdHJveeKAmToKICAgICAgICBsaWJ4
bC5jOjEyMjQ6IGVycm9yOiDigJhkbV9wcmVzZW504oCZIG1heSBiZSB1c2VkIHVuaW5pdGlhbGl6
ZWQgaW4gdGhpcyBmdW5jdGlvbgogICAgICAgIApJIGV4cGVjdCBiZWNhdXNlIGZvciBzb21lIHJl
YXNvbiBnY2MgZG9lc24ndCByZWFsaXNlIHRoYXQgdGhlIHN3aXRjaApjb3ZlcnMgYWxsIHBvc3Np
YmxlIGVudW0gdmFsdWVzIChzaW5jZSB0aGUgY2FzZXMgYWxsIGVpdGhlciBpbml0aWFsaXNlCm9y
IGp1bXAgdG8gb3V0IHdoaWNoIGRvZXMgbm90IHVzZSBkbV9wcmVzZW50KS4KCkluIG9yZGVyIHRo
YXQgSSBjb3VsZCBjb250aW51ZSB0byB0ZXN0IEkgZGlkIHRoaXM6CgpkaWZmIC1yIGZjYTEzMzBm
YTM2NyB0b29scy9saWJ4bC9saWJ4bC5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMJRnJpIEp1
biAyMiAxMzoxOToyMiAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMJRnJpIEp1
biAyMiAxMzoyMjoyNSAyMDEyICswMTAwCkBAIC0xMjQ0LDYgKzEyNDQsNyBAQCBpbnQgbGlieGxf
ZG9tYWluX2Rlc3Ryb3kobGlieGxfY3R4ICpjdHgsCiAgICAgY2FzZSBMSUJYTF9ET01BSU5fVFlQ
RV9JTlZBTElEOgogICAgICAgICByYyA9IEVSUk9SX0ZBSUw7CiAgICAgICAgIGdvdG8gb3V0Owor
ICAgIGRlZmF1bHQ6IGFib3J0KCk7CiAgICAgfQogCiAgICAgZG9tX3BhdGggPSBsaWJ4bF9feHNf
Z2V0X2RvbXBhdGgoZ2MsIGRvbWlkKTsKCmJ1dCB5b3UgbWlnaHQgaGF2ZSBhIGJldHRlciBwcmVm
ZXJlbmNlLgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si2tS-0004LW-3f; Fri, 22 Jun 2012 12:23: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 1Si2tQ-0004LA-22
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:23:16 +0000
Received: from [85.158.138.51:32053] by server-5.bemta-3.messagelabs.com id
	4A/7E-01572-3B364EF4; Fri, 22 Jun 2012 12:23:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340367794!28982369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10298 invoked from network); 22 Jun 2012 12:23:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 12:23:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13168916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:23:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 13:23:00 +0100
Message-ID: <1340367778.26083.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 13:22:58 +0100
In-Reply-To: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gRnJpLCAyMDEyLTA2LTE1IGF0IDEyOjUzICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBU
aGlzIGlzIHY0IG9mIG15IHNlcmllcyB0byBhc3luY2lmeSBzYXZlL3Jlc3RvcmUuICBBbGwgY29t
bWVudHMgaGF2ZQo+IGJlZW4gYWRkcmVzc2VkLgoKQnVpbGRpbmcgd2l0aCB0aGlzIEkgZ2V0Ogog
ICAgICAgIGNjMTogd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKICAgICAgICBsaWJ4
bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9kb21haW5fZGVzdHJveeKAmToKICAgICAgICBsaWJ4
bC5jOjEyMjQ6IGVycm9yOiDigJhkbV9wcmVzZW504oCZIG1heSBiZSB1c2VkIHVuaW5pdGlhbGl6
ZWQgaW4gdGhpcyBmdW5jdGlvbgogICAgICAgIApJIGV4cGVjdCBiZWNhdXNlIGZvciBzb21lIHJl
YXNvbiBnY2MgZG9lc24ndCByZWFsaXNlIHRoYXQgdGhlIHN3aXRjaApjb3ZlcnMgYWxsIHBvc3Np
YmxlIGVudW0gdmFsdWVzIChzaW5jZSB0aGUgY2FzZXMgYWxsIGVpdGhlciBpbml0aWFsaXNlCm9y
IGp1bXAgdG8gb3V0IHdoaWNoIGRvZXMgbm90IHVzZSBkbV9wcmVzZW50KS4KCkluIG9yZGVyIHRo
YXQgSSBjb3VsZCBjb250aW51ZSB0byB0ZXN0IEkgZGlkIHRoaXM6CgpkaWZmIC1yIGZjYTEzMzBm
YTM2NyB0b29scy9saWJ4bC9saWJ4bC5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMJRnJpIEp1
biAyMiAxMzoxOToyMiAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMJRnJpIEp1
biAyMiAxMzoyMjoyNSAyMDEyICswMTAwCkBAIC0xMjQ0LDYgKzEyNDQsNyBAQCBpbnQgbGlieGxf
ZG9tYWluX2Rlc3Ryb3kobGlieGxfY3R4ICpjdHgsCiAgICAgY2FzZSBMSUJYTF9ET01BSU5fVFlQ
RV9JTlZBTElEOgogICAgICAgICByYyA9IEVSUk9SX0ZBSUw7CiAgICAgICAgIGdvdG8gb3V0Owor
ICAgIGRlZmF1bHQ6IGFib3J0KCk7CiAgICAgfQogCiAgICAgZG9tX3BhdGggPSBsaWJ4bF9feHNf
Z2V0X2RvbXBhdGgoZ2MsIGRvbWlkKTsKCmJ1dCB5b3UgbWlnaHQgaGF2ZSBhIGJldHRlciBwcmVm
ZXJlbmNlLgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si2ww-0004b4-S3; Fri, 22 Jun 2012 12:26:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si2wv-0004au-Tw
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 12:26:54 +0000
Received: from [85.158.143.99:42148] by server-3.bemta-4.messagelabs.com id
	03/10-05808-D8464EF4; Fri, 22 Jun 2012 12:26:53 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340368011!18846516!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24986 invoked from network); 22 Jun 2012 12:26:52 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 12:26:52 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C458D207F0
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Jun 2012 08:26:50 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute1.internal (MEProxy); Fri, 22 Jun 2012 08:26:50 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=wQ
	Op/whRG2XFMlcdUHft9JmEqLA=; b=FlUjgSurlwgP9fZhT6HX+dqbF6x9D/ifQR
	/1SjkiKN1GzM1H+kB7zt/F0htz/wyzkgLveFcW5Xof0wSVHEkpulDiQqqieZTyzz
	xBfDuGsSFIrUA3zkr3LDtm7ENwKOYNeqBFD4QtJKF6rn91B7jthMA2+3jcSUZdJN
	FZZSzlp9E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=wQOp
	/whRG2XFMlcdUHft9JmEqLA=; b=FW7DWAckJsnwTb1MiyGvFO15+dVhilKGjnSn
	L7jn/kBTv6MK2iLLI2h6/Z08h6syBBcGGVixzqCMdg4YWfoHOQlhk5u82RZ/w2HW
	ORmCeyI258aRGrB7fddI7zA/inN1P6Sx+ji5VABqmKYtAPlbFUGbO37Tlt9uF617
	riHrtoA=
X-Sasl-enc: 8W6mbzBZKnY+Ujk3V479ukmGDZN5fZX12skXCv28+LY6 1340368010
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id 255598E0205;
	Fri, 22 Jun 2012 08:26:50 -0400 (EDT)
Message-ID: <4FE46486.8020502@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 14:26:46 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4FE46366.8010104@invisiblethingslab.com>
In-Reply-To: <4FE46366.8010104@invisiblethingslab.com>
X-Enigmail-Version: 1.4.2
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>
Subject: Re: [Xen-devel] Strange kernel BUG() on PV DomU 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: multipart/mixed; boundary="===============3010769908683817745=="
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)
--===============3010769908683817745==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig75F3E5CEB4B69EC053ACB8F1"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig75F3E5CEB4B69EC053ACB8F1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 14:21, Joanna Rutkowska wrote:
> Hello,
>=20
> From time to time (every several weeks or even less) I run into a
> strange Dom0 kernel BUG() that manifests itself with the following
> message (see the end of the message). The Dom0 and VM kernels are 3.2.7=

> pvops, and the Xen hypervisor is 4.1.2 both with only some minor,
> irrelevant (I think) modifications for Qubes.
>=20
> The bug is very hard to reproduce, but once this BUG() starts being
> signaled, it consistently prevents me from starting any new VMs in the
> system (e.g. tried over a dozen of times now, and every time the VM boo=
t
> fails).
>=20
> The following lines in the VM kernel are responsible for signaling the
> BUG():
>=20
>   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
>         BUG();
>=20
> ...yet, there is nothing in the xl dmesg that would provide more info
> why this hypercall fails. Ah, that's because there are not printk's in
> the hypercall code:
>=20
>    case VCPUOP_initialise:
>         if ( v->vcpu_info =3D=3D &dummy_vcpu_info )
>             return -EINVAL;
>=20
>         if ( (ctxt =3D xmalloc(struct vcpu_guest_context)) =3D=3D NULL =
)
>             return -ENOMEM;
>=20
>         if ( copy_from_guest(ctxt, arg, 1) )
>         {
>             xfree(ctxt);
>             return -EFAULT;
>         }
>=20
>         domain_lock(d);
>         rc =3D -EEXIST;
>         if ( !v->is_initialised )
>             rc =3D boot_vcpu(d, vcpuid, ctxt);
>         domain_unlock(d);
>=20
>         xfree(ctxt);
>         break;
>=20
> So, looking at the above it seems like it might be failing because of
> xmalloc() fails, however Xen seems to have enough memory as reported by=

> xl info:
>=20
> total_memory           : 8074
> free_memory            : 66
> free_cpus              : 0
>=20
> Any ideas what might be the cause?
>=20
> FWIW, below the actual oops message.
>=20

Ok, it seems like this was an out-of-memeory condition indeed, because
once I did:

xl mem-set 0 1800m

and then quickly started a VM, it booted fine...

Is there any proposal of how to handle out of memory conditions in Xen
(like this one, as well as e.g. SWIOTLB problem) in a more user friendly
way?

Any recommendations regarding the preferred minimum Xen free memory, as
reported by xl info, that should be preserved in order to assure Xen
runs smoothly?

joanna.


--------------enig75F3E5CEB4B69EC053ACB8F1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5GSGAAoJEDaIqHeRBUM0b+QIAK4TooH+Hq4aYwZ/uTiqfUcb
X4gpssHo5/96uPWNeqR19J3Hg5rm1+QHJjvRGaxOluBqZicTH0D9iypZAdYxlE87
5AYDbi2U3LChHEwoC4t+5N9N6e0yTd78Hy9m4MxVk/EpHEzhXmMbOqMEMV+q86ZY
9JTkB00RSex0viZqKyfMYXLKostGPPEOHh7W2oYYBVpiTa2AxQTTzCl6m9Cvkfn6
LXkwO6iCE3I/sNMgmwZlJxYzf+hVTJK/XTXYfJ9qnVMIukbdQN8A2mIcxPQ5C5do
6AWkMIzs6owOpkBwOFiB3sAkaj7mYIzneBpB8FC4jRIiNpuFCIF/IFtm8MREC+Y=
=ymiY
-----END PGP SIGNATURE-----

--------------enig75F3E5CEB4B69EC053ACB8F1--


--===============3010769908683817745==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3010769908683817745==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 12:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si2ww-0004b4-S3; Fri, 22 Jun 2012 12:26:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si2wv-0004au-Tw
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 12:26:54 +0000
Received: from [85.158.143.99:42148] by server-3.bemta-4.messagelabs.com id
	03/10-05808-D8464EF4; Fri, 22 Jun 2012 12:26:53 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340368011!18846516!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24986 invoked from network); 22 Jun 2012 12:26:52 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 12:26:52 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C458D207F0
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Jun 2012 08:26:50 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute1.internal (MEProxy); Fri, 22 Jun 2012 08:26:50 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=wQ
	Op/whRG2XFMlcdUHft9JmEqLA=; b=FlUjgSurlwgP9fZhT6HX+dqbF6x9D/ifQR
	/1SjkiKN1GzM1H+kB7zt/F0htz/wyzkgLveFcW5Xof0wSVHEkpulDiQqqieZTyzz
	xBfDuGsSFIrUA3zkr3LDtm7ENwKOYNeqBFD4QtJKF6rn91B7jthMA2+3jcSUZdJN
	FZZSzlp9E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=wQOp
	/whRG2XFMlcdUHft9JmEqLA=; b=FW7DWAckJsnwTb1MiyGvFO15+dVhilKGjnSn
	L7jn/kBTv6MK2iLLI2h6/Z08h6syBBcGGVixzqCMdg4YWfoHOQlhk5u82RZ/w2HW
	ORmCeyI258aRGrB7fddI7zA/inN1P6Sx+ji5VABqmKYtAPlbFUGbO37Tlt9uF617
	riHrtoA=
X-Sasl-enc: 8W6mbzBZKnY+Ujk3V479ukmGDZN5fZX12skXCv28+LY6 1340368010
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id 255598E0205;
	Fri, 22 Jun 2012 08:26:50 -0400 (EDT)
Message-ID: <4FE46486.8020502@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 14:26:46 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4FE46366.8010104@invisiblethingslab.com>
In-Reply-To: <4FE46366.8010104@invisiblethingslab.com>
X-Enigmail-Version: 1.4.2
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>
Subject: Re: [Xen-devel] Strange kernel BUG() on PV DomU 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: multipart/mixed; boundary="===============3010769908683817745=="
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)
--===============3010769908683817745==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig75F3E5CEB4B69EC053ACB8F1"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig75F3E5CEB4B69EC053ACB8F1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 14:21, Joanna Rutkowska wrote:
> Hello,
>=20
> From time to time (every several weeks or even less) I run into a
> strange Dom0 kernel BUG() that manifests itself with the following
> message (see the end of the message). The Dom0 and VM kernels are 3.2.7=

> pvops, and the Xen hypervisor is 4.1.2 both with only some minor,
> irrelevant (I think) modifications for Qubes.
>=20
> The bug is very hard to reproduce, but once this BUG() starts being
> signaled, it consistently prevents me from starting any new VMs in the
> system (e.g. tried over a dozen of times now, and every time the VM boo=
t
> fails).
>=20
> The following lines in the VM kernel are responsible for signaling the
> BUG():
>=20
>   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
>         BUG();
>=20
> ...yet, there is nothing in the xl dmesg that would provide more info
> why this hypercall fails. Ah, that's because there are not printk's in
> the hypercall code:
>=20
>    case VCPUOP_initialise:
>         if ( v->vcpu_info =3D=3D &dummy_vcpu_info )
>             return -EINVAL;
>=20
>         if ( (ctxt =3D xmalloc(struct vcpu_guest_context)) =3D=3D NULL =
)
>             return -ENOMEM;
>=20
>         if ( copy_from_guest(ctxt, arg, 1) )
>         {
>             xfree(ctxt);
>             return -EFAULT;
>         }
>=20
>         domain_lock(d);
>         rc =3D -EEXIST;
>         if ( !v->is_initialised )
>             rc =3D boot_vcpu(d, vcpuid, ctxt);
>         domain_unlock(d);
>=20
>         xfree(ctxt);
>         break;
>=20
> So, looking at the above it seems like it might be failing because of
> xmalloc() fails, however Xen seems to have enough memory as reported by=

> xl info:
>=20
> total_memory           : 8074
> free_memory            : 66
> free_cpus              : 0
>=20
> Any ideas what might be the cause?
>=20
> FWIW, below the actual oops message.
>=20

Ok, it seems like this was an out-of-memeory condition indeed, because
once I did:

xl mem-set 0 1800m

and then quickly started a VM, it booted fine...

Is there any proposal of how to handle out of memory conditions in Xen
(like this one, as well as e.g. SWIOTLB problem) in a more user friendly
way?

Any recommendations regarding the preferred minimum Xen free memory, as
reported by xl info, that should be preserved in order to assure Xen
runs smoothly?

joanna.


--------------enig75F3E5CEB4B69EC053ACB8F1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5GSGAAoJEDaIqHeRBUM0b+QIAK4TooH+Hq4aYwZ/uTiqfUcb
X4gpssHo5/96uPWNeqR19J3Hg5rm1+QHJjvRGaxOluBqZicTH0D9iypZAdYxlE87
5AYDbi2U3LChHEwoC4t+5N9N6e0yTd78Hy9m4MxVk/EpHEzhXmMbOqMEMV+q86ZY
9JTkB00RSex0viZqKyfMYXLKostGPPEOHh7W2oYYBVpiTa2AxQTTzCl6m9Cvkfn6
LXkwO6iCE3I/sNMgmwZlJxYzf+hVTJK/XTXYfJ9qnVMIukbdQN8A2mIcxPQ5C5do
6AWkMIzs6owOpkBwOFiB3sAkaj7mYIzneBpB8FC4jRIiNpuFCIF/IFtm8MREC+Y=
=ymiY
-----END PGP SIGNATURE-----

--------------enig75F3E5CEB4B69EC053ACB8F1--


--===============3010769908683817745==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3010769908683817745==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 12:27:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:27: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 1Si2xV-0004eB-AI; Fri, 22 Jun 2012 12:27:29 +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 1Si2xU-0004e2-3Z
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:27:28 +0000
Received: from [85.158.138.51:21753] by server-8.bemta-3.messagelabs.com id
	97/7A-06157-FA464EF4; Fri, 22 Jun 2012 12:27:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340368045!29093802!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26825 invoked from network); 22 Jun 2012 12:27:26 -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 Jun 2012 12:27:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336363200"; d="scan'208";a="199692542"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:27:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 08:27:23 -0400
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 1Si2xP-00026T-OR;
	Fri, 22 Jun 2012 13:27:23 +0100
Message-ID: <4FE464AB.2070402@citrix.com>
Date: Fri, 22 Jun 2012 13:27:23 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>	<4FE44404.2020702@citrix.com>
	<4FE47368020000780008B60F@nat28.tlf.novell.com>
In-Reply-To: <4FE47368020000780008B60F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 12:30, Jan Beulich wrote:
>> It is certainly not an easy problem, and perhaps I am needlessly
>> complicating the issue.
>>
>> It occurs that we have 3 possible directions to fix this issue.
>>
>> 1) Continue the current method of fixing things up after they break,
>> which can cause a hassle for a user encountering the issue.
>> 2) Mark as RO and provide an explicit hypercall interface to remap
>> BARs.  I don't know how well this would go with upstream Linux.
> And what would the hypercall do? You don't expect it to fix up
> all the uses of the old address(es) to now use the new one(s),
> do you? Leaving aside the difficulty in getting this right, in some
> cases this might not even be possible in a seamless manner.
>
>> 3) Extend current infrastructure to be able to tell when a write is
>> affecting the BARs and permit them.  This seems like the best option
>> going forward, but might be quite hard to implement.
> Doing the mechanical trap-and-emulate part of this shouldn't
> be that hard, namely on top of that other patch I'm about to
> commit.
>
> But the thing is that this has the same problems as the hypercall
> one above.

Currently my understanding is that dom0 has fairly free reign on the PCI
devices, meaning that if it decides to remap BARs and ends up with
conflicts, we already have a problem, especially if its a PCI device
that Xen is trying to use.

As Xen avoids using PCI devices as much as possible, it should be easier
(but doubtfully 'easy') to make Xen aware that PCI devices it is using
may move from under its feet.  ( I am just throwing ideas out here - it
might be that this is a stupid idea. )

>
>> I guess the real question is whether we should continue reactively
>> fixing problems, or start protectively fixing the root cause.
> I agree with this position from a theoretical standpoint.
>
>>  My gut
>> feeling is that we are going to start seeing more and more devices on
>> the PCI bus which Xen should be using, rather than dom0.
> That would be bad - surfacing arbitrary devices on the PCI bus
> is - in my opinion - rather questionable a design (which is also
> why I consider this aspect of the AMD IOMMUs badly designed).
>
> Jan

Agreed, but we now have a problem and need a solution.

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:27:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:27: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 1Si2xV-0004eB-AI; Fri, 22 Jun 2012 12:27:29 +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 1Si2xU-0004e2-3Z
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:27:28 +0000
Received: from [85.158.138.51:21753] by server-8.bemta-3.messagelabs.com id
	97/7A-06157-FA464EF4; Fri, 22 Jun 2012 12:27:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340368045!29093802!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26825 invoked from network); 22 Jun 2012 12:27:26 -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 Jun 2012 12:27:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336363200"; d="scan'208";a="199692542"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:27:24 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 08:27:23 -0400
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 1Si2xP-00026T-OR;
	Fri, 22 Jun 2012 13:27:23 +0100
Message-ID: <4FE464AB.2070402@citrix.com>
Date: Fri, 22 Jun 2012 13:27:23 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>	<4FE44404.2020702@citrix.com>
	<4FE47368020000780008B60F@nat28.tlf.novell.com>
In-Reply-To: <4FE47368020000780008B60F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 12:30, Jan Beulich wrote:
>> It is certainly not an easy problem, and perhaps I am needlessly
>> complicating the issue.
>>
>> It occurs that we have 3 possible directions to fix this issue.
>>
>> 1) Continue the current method of fixing things up after they break,
>> which can cause a hassle for a user encountering the issue.
>> 2) Mark as RO and provide an explicit hypercall interface to remap
>> BARs.  I don't know how well this would go with upstream Linux.
> And what would the hypercall do? You don't expect it to fix up
> all the uses of the old address(es) to now use the new one(s),
> do you? Leaving aside the difficulty in getting this right, in some
> cases this might not even be possible in a seamless manner.
>
>> 3) Extend current infrastructure to be able to tell when a write is
>> affecting the BARs and permit them.  This seems like the best option
>> going forward, but might be quite hard to implement.
> Doing the mechanical trap-and-emulate part of this shouldn't
> be that hard, namely on top of that other patch I'm about to
> commit.
>
> But the thing is that this has the same problems as the hypercall
> one above.

Currently my understanding is that dom0 has fairly free reign on the PCI
devices, meaning that if it decides to remap BARs and ends up with
conflicts, we already have a problem, especially if its a PCI device
that Xen is trying to use.

As Xen avoids using PCI devices as much as possible, it should be easier
(but doubtfully 'easy') to make Xen aware that PCI devices it is using
may move from under its feet.  ( I am just throwing ideas out here - it
might be that this is a stupid idea. )

>
>> I guess the real question is whether we should continue reactively
>> fixing problems, or start protectively fixing the root cause.
> I agree with this position from a theoretical standpoint.
>
>>  My gut
>> feeling is that we are going to start seeing more and more devices on
>> the PCI bus which Xen should be using, rather than dom0.
> That would be bad - surfacing arbitrary devices on the PCI bus
> is - in my opinion - rather questionable a design (which is also
> why I consider this aspect of the AMD IOMMUs badly designed).
>
> Jan

Agreed, but we now have a problem and need a solution.

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si30A-0004qf-TY; Fri, 22 Jun 2012 12:30:14 +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 1Si309-0004qP-Ge
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:30:13 +0000
Received: from [193.109.254.147:61863] by server-1.bemta-14.messagelabs.com id
	D2/A0-24612-45564EF4; Fri, 22 Jun 2012 12:30:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340368209!8946194!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30664 invoked from network); 22 Jun 2012 12:30:11 -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;
	22 Jun 2012 12:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336363200"; d="scan'208";a="29055442"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:30:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 08:30:08 -0400
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 1Si304-0002AH-ER;
	Fri, 22 Jun 2012 13:30:08 +0100
Message-ID: <4FE46550.20300@citrix.com>
Date: Fri, 22 Jun 2012 13:30:08 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
	<4FE471C4020000780008B5FA@nat28.tlf.novell.com>
	<4FE45FD3.3060300@citrix.com>
	<4FE47F28020000780008B686@nat28.tlf.novell.com>
In-Reply-To: <4FE47F28020000780008B686@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 13:20, Jan Beulich wrote:
>>> Because, just like for normal, non-PCI based serial ones, ports
>>> that Xen doesn't use should remain usable by Dom0. For
>>> example, I have a PCI card with two serial and one parallel
>>> ports, so with Xen using one serial port for itself, there's no
>>> reason not to allow Dom0 to use the other or the parallel one.
>> I apologize.  I originally used the term 'device' when I intended to use
>> 'function', so I think we are arguing for the same point.
> And I understood you meaning so - from a PCI terminology pov.
> Multi-function here, however, means multiple serial/parallel ports
> within a single PCI function (PCI_CLASS_COMMUNICATION_MULTISERIAL
> or PCI_CLASS_COMMUNICATION_OTHER). Hence we shouldn't hide a
> full S:B:D.F just because we use some portion of it.
>
> Jan
>

Ah right.  Yes.  Perhaps then a warning on the Xen console if Xen
encounters such a device.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si30A-0004qf-TY; Fri, 22 Jun 2012 12:30:14 +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 1Si309-0004qP-Ge
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:30:13 +0000
Received: from [193.109.254.147:61863] by server-1.bemta-14.messagelabs.com id
	D2/A0-24612-45564EF4; Fri, 22 Jun 2012 12:30:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340368209!8946194!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30664 invoked from network); 22 Jun 2012 12:30:11 -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;
	22 Jun 2012 12:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336363200"; d="scan'208";a="29055442"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 08:30:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 08:30:08 -0400
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 1Si304-0002AH-ER;
	Fri, 22 Jun 2012 13:30:08 +0100
Message-ID: <4FE46550.20300@citrix.com>
Date: Fri, 22 Jun 2012 13:30:08 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE43518.9070106@citrix.com>
	<4FE45A64020000780008B570@nat28.tlf.novell.com>
	<4FE44404.2020702@citrix.com>
	<4FE471C4020000780008B5FA@nat28.tlf.novell.com>
	<4FE45FD3.3060300@citrix.com>
	<4FE47F28020000780008B686@nat28.tlf.novell.com>
In-Reply-To: <4FE47F28020000780008B686@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Andre Przywara <andre.przywara@amd.com>,
	Christoph Egger <christoph.egger@amd.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Wang <wei.wang2@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Other PCI devices to mark mark as read-only for 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 22/06/12 13:20, Jan Beulich wrote:
>>> Because, just like for normal, non-PCI based serial ones, ports
>>> that Xen doesn't use should remain usable by Dom0. For
>>> example, I have a PCI card with two serial and one parallel
>>> ports, so with Xen using one serial port for itself, there's no
>>> reason not to allow Dom0 to use the other or the parallel one.
>> I apologize.  I originally used the term 'device' when I intended to use
>> 'function', so I think we are arguing for the same point.
> And I understood you meaning so - from a PCI terminology pov.
> Multi-function here, however, means multiple serial/parallel ports
> within a single PCI function (PCI_CLASS_COMMUNICATION_MULTISERIAL
> or PCI_CLASS_COMMUNICATION_OTHER). Hence we shouldn't hide a
> full S:B:D.F just because we use some portion of it.
>
> Jan
>

Ah right.  Yes.  Perhaps then a warning on the Xen console if Xen
encounters such a device.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 12:37:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si37M-0005AH-Qg; Fri, 22 Jun 2012 12:37: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 1Si37L-0005AC-D8
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:37:39 +0000
Received: from [85.158.143.99:39116] by server-3.bemta-4.messagelabs.com id
	91/3E-05808-21764EF4; Fri, 22 Jun 2012 12:37:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340368658!20925057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4891 invoked from network); 22 Jun 2012 12:37:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	22 Jun 2012 12:37:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 13:37:37 +0100
Message-Id: <4FE4835D020000780008B6B3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 13:38:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
In-Reply-To: <4FE46486.8020502@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange kernel BUG() on PV DomU 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 22.06.12 at 14:26, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> On 06/22/12 14:21, Joanna Rutkowska wrote:
>> Hello,
>> 
>> From time to time (every several weeks or even less) I run into a
>> strange Dom0 kernel BUG() that manifests itself with the following
>> message (see the end of the message). The Dom0 and VM kernels are 3.2.7
>> pvops, and the Xen hypervisor is 4.1.2 both with only some minor,
>> irrelevant (I think) modifications for Qubes.
>> 
>> The bug is very hard to reproduce, but once this BUG() starts being
>> signaled, it consistently prevents me from starting any new VMs in the
>> system (e.g. tried over a dozen of times now, and every time the VM boot
>> fails).
>> 
>> The following lines in the VM kernel are responsible for signaling the
>> BUG():
>> 
>>   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
>>         BUG();
>> 
>> ...yet, there is nothing in the xl dmesg that would provide more info
>> why this hypercall fails. Ah, that's because there are not printk's in
>> the hypercall code:
>> 
>>    case VCPUOP_initialise:
>>         if ( v->vcpu_info == &dummy_vcpu_info )
>>             return -EINVAL;
>> 
>>         if ( (ctxt = xmalloc(struct vcpu_guest_context)) == NULL )
>>             return -ENOMEM;
>> 
>>         if ( copy_from_guest(ctxt, arg, 1) )
>>         {
>>             xfree(ctxt);
>>             return -EFAULT;
>>         }
>> 
>>         domain_lock(d);
>>         rc = -EEXIST;
>>         if ( !v->is_initialised )
>>             rc = boot_vcpu(d, vcpuid, ctxt);
>>         domain_unlock(d);
>> 
>>         xfree(ctxt);
>>         break;
>> 
>> So, looking at the above it seems like it might be failing because of
>> xmalloc() fails, however Xen seems to have enough memory as reported by
>> xl info:
>> 
>> total_memory           : 8074
>> free_memory            : 66
>> free_cpus              : 0
>> 
>> Any ideas what might be the cause?
>> 
>> FWIW, below the actual oops message.
>> 
> 
> Ok, it seems like this was an out-of-memeory condition indeed, because
> once I did:
> 
> xl mem-set 0 1800m
> 
> and then quickly started a VM, it booted fine...

Had you looked at the error value in %rax, you would also
have seen that it's -ENOMEM. I suppose the problem here is
that a multi-page allocation was needed, yet only single
pages were available.

> Is there any proposal of how to handle out of memory conditions in Xen
> (like this one, as well as e.g. SWIOTLB problem) in a more user friendly
> way?

In 4.2, I hope we managed to remove all runtime allocations
larger than a page, so the particular situation here should arise
anymore.

As to more user-friendly - what do you think of? An error is an
error (and converting this to a meaningful, user visible message
is the responsibility of the entity receiving the error). In the
case at hand, printing an error message wouldn't meaningfully
increase user-friendliness imo.

> Any recommendations regarding the preferred minimum Xen free memory, as
> reported by xl info, that should be preserved in order to assure Xen
> runs smoothly?

In pre-4.2 Xen, there's not much you can do when memory gets
fragmented (otherwise you'd have to keep more than half the
memory in the box in the hypervisor). With multi-page runtime
allocations gone, you should be fine leaving just a minimal amount
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 Fri Jun 22 12:37:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si37M-0005AH-Qg; Fri, 22 Jun 2012 12:37: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 1Si37L-0005AC-D8
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:37:39 +0000
Received: from [85.158.143.99:39116] by server-3.bemta-4.messagelabs.com id
	91/3E-05808-21764EF4; Fri, 22 Jun 2012 12:37:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340368658!20925057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4891 invoked from network); 22 Jun 2012 12:37:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	22 Jun 2012 12:37:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 13:37:37 +0100
Message-Id: <4FE4835D020000780008B6B3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 13:38:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
In-Reply-To: <4FE46486.8020502@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange kernel BUG() on PV DomU 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 22.06.12 at 14:26, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> On 06/22/12 14:21, Joanna Rutkowska wrote:
>> Hello,
>> 
>> From time to time (every several weeks or even less) I run into a
>> strange Dom0 kernel BUG() that manifests itself with the following
>> message (see the end of the message). The Dom0 and VM kernels are 3.2.7
>> pvops, and the Xen hypervisor is 4.1.2 both with only some minor,
>> irrelevant (I think) modifications for Qubes.
>> 
>> The bug is very hard to reproduce, but once this BUG() starts being
>> signaled, it consistently prevents me from starting any new VMs in the
>> system (e.g. tried over a dozen of times now, and every time the VM boot
>> fails).
>> 
>> The following lines in the VM kernel are responsible for signaling the
>> BUG():
>> 
>>   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
>>         BUG();
>> 
>> ...yet, there is nothing in the xl dmesg that would provide more info
>> why this hypercall fails. Ah, that's because there are not printk's in
>> the hypercall code:
>> 
>>    case VCPUOP_initialise:
>>         if ( v->vcpu_info == &dummy_vcpu_info )
>>             return -EINVAL;
>> 
>>         if ( (ctxt = xmalloc(struct vcpu_guest_context)) == NULL )
>>             return -ENOMEM;
>> 
>>         if ( copy_from_guest(ctxt, arg, 1) )
>>         {
>>             xfree(ctxt);
>>             return -EFAULT;
>>         }
>> 
>>         domain_lock(d);
>>         rc = -EEXIST;
>>         if ( !v->is_initialised )
>>             rc = boot_vcpu(d, vcpuid, ctxt);
>>         domain_unlock(d);
>> 
>>         xfree(ctxt);
>>         break;
>> 
>> So, looking at the above it seems like it might be failing because of
>> xmalloc() fails, however Xen seems to have enough memory as reported by
>> xl info:
>> 
>> total_memory           : 8074
>> free_memory            : 66
>> free_cpus              : 0
>> 
>> Any ideas what might be the cause?
>> 
>> FWIW, below the actual oops message.
>> 
> 
> Ok, it seems like this was an out-of-memeory condition indeed, because
> once I did:
> 
> xl mem-set 0 1800m
> 
> and then quickly started a VM, it booted fine...

Had you looked at the error value in %rax, you would also
have seen that it's -ENOMEM. I suppose the problem here is
that a multi-page allocation was needed, yet only single
pages were available.

> Is there any proposal of how to handle out of memory conditions in Xen
> (like this one, as well as e.g. SWIOTLB problem) in a more user friendly
> way?

In 4.2, I hope we managed to remove all runtime allocations
larger than a page, so the particular situation here should arise
anymore.

As to more user-friendly - what do you think of? An error is an
error (and converting this to a meaningful, user visible message
is the responsibility of the entity receiving the error). In the
case at hand, printing an error message wouldn't meaningfully
increase user-friendliness imo.

> Any recommendations regarding the preferred minimum Xen free memory, as
> reported by xl info, that should be preserved in order to assure Xen
> runs smoothly?

In pre-4.2 Xen, there's not much you can do when memory gets
fragmented (otherwise you'd have to keep more than half the
memory in the box in the hypervisor). With multi-page runtime
allocations gone, you should be fine leaving just a minimal amount
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 Fri Jun 22 12:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si3Md-0005Ng-Au; Fri, 22 Jun 2012 12:53:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si3Mb-0005NX-CV
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:53:25 +0000
Received: from [85.158.143.35:40414] by server-1.bemta-4.messagelabs.com id
	2F/DF-24392-4CA64EF4; Fri, 22 Jun 2012 12:53:24 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340369603!13579769!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8345 invoked from network); 22 Jun 2012 12:53:24 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 12:53:24 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DA1CB20CED;
	Fri, 22 Jun 2012 08:53:22 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute6.internal (MEProxy); Fri, 22 Jun 2012 08:53:22 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=W6
	06i1bCrOZBxJmZvBSj+6U8/G4=; b=jCEDYYTjVVBmoaXiGwLwBH2zS1DasiRotL
	12uLQoBAXTDTd3XvplJQZFnBIxMKZsy+4M8KfFg2siFCqMMng38DAJLlK8HAVtX9
	RPRsS/S+zuJSwYQBeGAV3mgdC9ku+h4FxZglM4r5Dq15CvVu+xgVqx2KWdMjZ6pP
	NzdUjs55c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=W606
	i1bCrOZBxJmZvBSj+6U8/G4=; b=jiOViiwT9/LAHccd0Ge70BHnvZdskGMxjn1A
	dCxArw5jeVeLKLGbGeYskY5xiJXmbKUbdSotNtI1HOiwtkTl8WwDLFvjLKcYb3nR
	kbTRorhtZbIChioq2oU81LGNevyQIGZd+ljicgMK9pYrtZNt3tJ3KhcnW6qRVunz
	sHIsiIw=
X-Sasl-enc: fEHmG1OXDCOyTsJ9HGHwes2gI+WvLGFRbOcqAjv2ainv 1340369602
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id 158EA4837ED;
	Fri, 22 Jun 2012 08:53:21 -0400 (EDT)
Message-ID: <4FE46ABE.9010104@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 14:53:18 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
In-Reply-To: <4FE4835D020000780008B6B3@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Handling of out of memory conditions (was: Re: Strange
 kernel BUG() on PV DomU 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: multipart/mixed; boundary="===============4725527832337227313=="
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)
--===============4725527832337227313==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig651C6EC0550E9863C2A15CEA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig651C6EC0550E9863C2A15CEA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 14:38, Jan Beulich wrote:
>> Ok, it seems like this was an out-of-memeory condition indeed, because=

>> > once I did:
>> >=20
>> > xl mem-set 0 1800m
>> >=20
>> > and then quickly started a VM, it booted fine...
> Had you looked at the error value in %rax, you would also
> have seen that it's -ENOMEM. I suppose the problem here is
> that a multi-page allocation was needed, yet only single
> pages were available.
>=20

Ah, right, good point.

>> > Is there any proposal of how to handle out of memory conditions in X=
en
>> > (like this one, as well as e.g. SWIOTLB problem) in a more user frie=
ndly
>> > way?
> In 4.2, I hope we managed to remove all runtime allocations
> larger than a page, so the particular situation here should arise
> anymore.
>=20
> As to more user-friendly - what do you think of? An error is an
> error (and converting this to a meaningful, user visible message
> is the responsibility of the entity receiving the error). In the
> case at hand, printing an error message wouldn't meaningfully
> increase user-friendliness imo.
>=20

How would you suggest to let the user (in an interactive desktop system,
such as Qubes) know why his or her VM doesn't start? Certainly, some
savvy user might just analyze the guest's dmesg log but that's really
not a user friendly solution. And yet the out of memory errors are
something that might happen quite often and are not really "exception"
or "errors" in the same sense as e.g. traditional BUG() conditions that
suggest something really bad happened. The problem here is that this bug
occurs after the domain has been built, and is now running, so xl start
is not a good place to return the error. Same with SWIOTLB out of memory
errors, that again just prevent the domain from starting. Any other
ideas how to handle such situations more gracefully?

>> > Any recommendations regarding the preferred minimum Xen free memory,=
 as
>> > reported by xl info, that should be preserved in order to assure Xen=

>> > runs smoothly?
> In pre-4.2 Xen, there's not much you can do when memory gets
> fragmented (otherwise you'd have to keep more than half the
> memory in the box in the hypervisor). With multi-page runtime
> allocations gone, you should be fine leaving just a minimal amount
> to the hypervisor.

Right, but 4.2 will not be released until weeks or months :/ And we
would like to release Qubes 1.0 within weeks...

joanna.


--------------enig651C6EC0550E9863C2A15CEA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5Gq+AAoJEDaIqHeRBUM0bg0IAMdd2l0fBZSY0FSQtISCdqnu
nMw9w57F5PJ8lf591NPNGbWhsim+mE0mk9njz0O58m+5Eywg6JKWUel3jlrQwcsB
c7QC3q+cManbztPGXPp2rRs/sPIMEM+tW7RyGwyzEPjLmspoMSFUU+RZhScyY6+Y
3nhN4Mno7BdJ26hC+oO9Ok9WDt1dj09Gbvxug2XDIurzYfPXvUBD+V8NeWEiXwpf
qcJXOKSidhxOxTBQzG+8dFYD8dFYsvNKRvIGfNBogYYzq1WvUNGeQ9Q4hTb6lSZT
AbQHRWJMvQ3+jJnePHdcYwI9AWEsf3wqWyI0IrG7LPLFKY4amszro7ViTzrzmto=
=pM5I
-----END PGP SIGNATURE-----

--------------enig651C6EC0550E9863C2A15CEA--


--===============4725527832337227313==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4725527832337227313==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 12:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 12: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 1Si3Md-0005Ng-Au; Fri, 22 Jun 2012 12:53:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si3Mb-0005NX-CV
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 12:53:25 +0000
Received: from [85.158.143.35:40414] by server-1.bemta-4.messagelabs.com id
	2F/DF-24392-4CA64EF4; Fri, 22 Jun 2012 12:53:24 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340369603!13579769!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8345 invoked from network); 22 Jun 2012 12:53:24 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 12:53:24 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DA1CB20CED;
	Fri, 22 Jun 2012 08:53:22 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute6.internal (MEProxy); Fri, 22 Jun 2012 08:53:22 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=W6
	06i1bCrOZBxJmZvBSj+6U8/G4=; b=jCEDYYTjVVBmoaXiGwLwBH2zS1DasiRotL
	12uLQoBAXTDTd3XvplJQZFnBIxMKZsy+4M8KfFg2siFCqMMng38DAJLlK8HAVtX9
	RPRsS/S+zuJSwYQBeGAV3mgdC9ku+h4FxZglM4r5Dq15CvVu+xgVqx2KWdMjZ6pP
	NzdUjs55c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=W606
	i1bCrOZBxJmZvBSj+6U8/G4=; b=jiOViiwT9/LAHccd0Ge70BHnvZdskGMxjn1A
	dCxArw5jeVeLKLGbGeYskY5xiJXmbKUbdSotNtI1HOiwtkTl8WwDLFvjLKcYb3nR
	kbTRorhtZbIChioq2oU81LGNevyQIGZd+ljicgMK9pYrtZNt3tJ3KhcnW6qRVunz
	sHIsiIw=
X-Sasl-enc: fEHmG1OXDCOyTsJ9HGHwes2gI+WvLGFRbOcqAjv2ainv 1340369602
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id 158EA4837ED;
	Fri, 22 Jun 2012 08:53:21 -0400 (EDT)
Message-ID: <4FE46ABE.9010104@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 14:53:18 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
In-Reply-To: <4FE4835D020000780008B6B3@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Handling of out of memory conditions (was: Re: Strange
 kernel BUG() on PV DomU 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: multipart/mixed; boundary="===============4725527832337227313=="
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)
--===============4725527832337227313==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig651C6EC0550E9863C2A15CEA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig651C6EC0550E9863C2A15CEA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 14:38, Jan Beulich wrote:
>> Ok, it seems like this was an out-of-memeory condition indeed, because=

>> > once I did:
>> >=20
>> > xl mem-set 0 1800m
>> >=20
>> > and then quickly started a VM, it booted fine...
> Had you looked at the error value in %rax, you would also
> have seen that it's -ENOMEM. I suppose the problem here is
> that a multi-page allocation was needed, yet only single
> pages were available.
>=20

Ah, right, good point.

>> > Is there any proposal of how to handle out of memory conditions in X=
en
>> > (like this one, as well as e.g. SWIOTLB problem) in a more user frie=
ndly
>> > way?
> In 4.2, I hope we managed to remove all runtime allocations
> larger than a page, so the particular situation here should arise
> anymore.
>=20
> As to more user-friendly - what do you think of? An error is an
> error (and converting this to a meaningful, user visible message
> is the responsibility of the entity receiving the error). In the
> case at hand, printing an error message wouldn't meaningfully
> increase user-friendliness imo.
>=20

How would you suggest to let the user (in an interactive desktop system,
such as Qubes) know why his or her VM doesn't start? Certainly, some
savvy user might just analyze the guest's dmesg log but that's really
not a user friendly solution. And yet the out of memory errors are
something that might happen quite often and are not really "exception"
or "errors" in the same sense as e.g. traditional BUG() conditions that
suggest something really bad happened. The problem here is that this bug
occurs after the domain has been built, and is now running, so xl start
is not a good place to return the error. Same with SWIOTLB out of memory
errors, that again just prevent the domain from starting. Any other
ideas how to handle such situations more gracefully?

>> > Any recommendations regarding the preferred minimum Xen free memory,=
 as
>> > reported by xl info, that should be preserved in order to assure Xen=

>> > runs smoothly?
> In pre-4.2 Xen, there's not much you can do when memory gets
> fragmented (otherwise you'd have to keep more than half the
> memory in the box in the hypervisor). With multi-page runtime
> allocations gone, you should be fine leaving just a minimal amount
> to the hypervisor.

Right, but 4.2 will not be released until weeks or months :/ And we
would like to release Qubes 1.0 within weeks...

joanna.


--------------enig651C6EC0550E9863C2A15CEA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5Gq+AAoJEDaIqHeRBUM0bg0IAMdd2l0fBZSY0FSQtISCdqnu
nMw9w57F5PJ8lf591NPNGbWhsim+mE0mk9njz0O58m+5Eywg6JKWUel3jlrQwcsB
c7QC3q+cManbztPGXPp2rRs/sPIMEM+tW7RyGwyzEPjLmspoMSFUU+RZhScyY6+Y
3nhN4Mno7BdJ26hC+oO9Ok9WDt1dj09Gbvxug2XDIurzYfPXvUBD+V8NeWEiXwpf
qcJXOKSidhxOxTBQzG+8dFYD8dFYsvNKRvIGfNBogYYzq1WvUNGeQ9Q4hTb6lSZT
AbQHRWJMvQ3+jJnePHdcYwI9AWEsf3wqWyI0IrG7LPLFKY4amszro7ViTzrzmto=
=pM5I
-----END PGP SIGNATURE-----

--------------enig651C6EC0550E9863C2A15CEA--


--===============4725527832337227313==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4725527832337227313==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 13:02:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:02: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 1Si3VD-0005fD-Gz; Fri, 22 Jun 2012 13:02:19 +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 1Si3VB-0005f8-L7
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:02:17 +0000
Received: from [85.158.143.35:55627] by server-3.bemta-4.messagelabs.com id
	3B/7F-05808-8DC64EF4; Fri, 22 Jun 2012 13:02:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340370134!5878792!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28002 invoked from network); 22 Jun 2012 13:02:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	22 Jun 2012 13:02:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 14:02:13 +0100
Message-Id: <4FE48921020000780008B6D0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 14:02:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
In-Reply-To: <4FE46ABE.9010104@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Handling of out of memory conditions (was: Re: Strange
 kernel BUG() on PV DomU 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 22.06.12 at 14:53, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> On 06/22/12 14:38, Jan Beulich wrote:
>>> > Is there any proposal of how to handle out of memory conditions in Xen
>>> > (like this one, as well as e.g. SWIOTLB problem) in a more user friendly
>>> > way?
>> In 4.2, I hope we managed to remove all runtime allocations
>> larger than a page, so the particular situation here should arise
>> anymore.
>> 
>> As to more user-friendly - what do you think of? An error is an
>> error (and converting this to a meaningful, user visible message
>> is the responsibility of the entity receiving the error). In the
>> case at hand, printing an error message wouldn't meaningfully
>> increase user-friendliness imo.
> 
> How would you suggest to let the user (in an interactive desktop system,
> such as Qubes) know why his or her VM doesn't start? Certainly, some
> savvy user might just analyze the guest's dmesg log but that's really
> not a user friendly solution. And yet the out of memory errors are
> something that might happen quite often and are not really "exception"
> or "errors" in the same sense as e.g. traditional BUG() conditions that
> suggest something really bad happened. The problem here is that this bug
> occurs after the domain has been built, and is now running, so xl start
> is not a good place to return the error. Same with SWIOTLB out of memory
> errors, that again just prevent the domain from starting. Any other
> ideas how to handle such situations more gracefully?

In the case at hand, failing CPU bringup rather than invoking
BUG() would likely be possible. Then the guest would come up
single-CPU. (That's a more general theme though: Many BUG()
instances really don't need to be as harsh.)

SWIOTLB allocation is a different thing - if the guest really needs
it, yet fails to set it up, the most it could do is to defer the crash
until the first I/O needs to make use of it. Which likely doesn't buy
much to the user.

>>> > Any recommendations regarding the preferred minimum Xen free memory, as
>>> > reported by xl info, that should be preserved in order to assure Xen
>>> > runs smoothly?
>> In pre-4.2 Xen, there's not much you can do when memory gets
>> fragmented (otherwise you'd have to keep more than half the
>> memory in the box in the hypervisor). With multi-page runtime
>> allocations gone, you should be fine leaving just a minimal amount
>> to the hypervisor.
> 
> Right, but 4.2 will not be released until weeks or months :/ And we
> would like to release Qubes 1.0 within weeks...

If you're running your own hypervisor, you could go and backport
all those changes. If you running some vendor's, you could ask
them to (but if you asked us, we'd likely would [try to] refuse).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 13:02:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:02: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 1Si3VD-0005fD-Gz; Fri, 22 Jun 2012 13:02:19 +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 1Si3VB-0005f8-L7
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:02:17 +0000
Received: from [85.158.143.35:55627] by server-3.bemta-4.messagelabs.com id
	3B/7F-05808-8DC64EF4; Fri, 22 Jun 2012 13:02:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340370134!5878792!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28002 invoked from network); 22 Jun 2012 13:02:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	22 Jun 2012 13:02:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 14:02:13 +0100
Message-Id: <4FE48921020000780008B6D0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 14:02:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
In-Reply-To: <4FE46ABE.9010104@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Handling of out of memory conditions (was: Re: Strange
 kernel BUG() on PV DomU 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 22.06.12 at 14:53, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> On 06/22/12 14:38, Jan Beulich wrote:
>>> > Is there any proposal of how to handle out of memory conditions in Xen
>>> > (like this one, as well as e.g. SWIOTLB problem) in a more user friendly
>>> > way?
>> In 4.2, I hope we managed to remove all runtime allocations
>> larger than a page, so the particular situation here should arise
>> anymore.
>> 
>> As to more user-friendly - what do you think of? An error is an
>> error (and converting this to a meaningful, user visible message
>> is the responsibility of the entity receiving the error). In the
>> case at hand, printing an error message wouldn't meaningfully
>> increase user-friendliness imo.
> 
> How would you suggest to let the user (in an interactive desktop system,
> such as Qubes) know why his or her VM doesn't start? Certainly, some
> savvy user might just analyze the guest's dmesg log but that's really
> not a user friendly solution. And yet the out of memory errors are
> something that might happen quite often and are not really "exception"
> or "errors" in the same sense as e.g. traditional BUG() conditions that
> suggest something really bad happened. The problem here is that this bug
> occurs after the domain has been built, and is now running, so xl start
> is not a good place to return the error. Same with SWIOTLB out of memory
> errors, that again just prevent the domain from starting. Any other
> ideas how to handle such situations more gracefully?

In the case at hand, failing CPU bringup rather than invoking
BUG() would likely be possible. Then the guest would come up
single-CPU. (That's a more general theme though: Many BUG()
instances really don't need to be as harsh.)

SWIOTLB allocation is a different thing - if the guest really needs
it, yet fails to set it up, the most it could do is to defer the crash
until the first I/O needs to make use of it. Which likely doesn't buy
much to the user.

>>> > Any recommendations regarding the preferred minimum Xen free memory, as
>>> > reported by xl info, that should be preserved in order to assure Xen
>>> > runs smoothly?
>> In pre-4.2 Xen, there's not much you can do when memory gets
>> fragmented (otherwise you'd have to keep more than half the
>> memory in the box in the hypervisor). With multi-page runtime
>> allocations gone, you should be fine leaving just a minimal amount
>> to the hypervisor.
> 
> Right, but 4.2 will not be released until weeks or months :/ And we
> would like to release Qubes 1.0 within weeks...

If you're running your own hypervisor, you could go and backport
all those changes. If you running some vendor's, you could ask
them to (but if you asked us, we'd likely would [try to] refuse).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 13:12:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si3eO-0005vw-IP; Fri, 22 Jun 2012 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 <joanna@invisiblethingslab.com>) id 1Si3eN-0005vr-6e
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:11:47 +0000
Received: from [193.109.254.147:14804] by server-1.bemta-14.messagelabs.com id
	E2/98-24612-21F64EF4; Fri, 22 Jun 2012 13:11:46 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340370704!8675680!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18827 invoked from network); 22 Jun 2012 13:11:44 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 13:11:44 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C0FB3207A5;
	Fri, 22 Jun 2012 09:11:43 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Fri, 22 Jun 2012 09:11:43 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=tP
	ojkG55z7XF1Rqc+rOP10MGOSw=; b=JCz3jbf1YV1YgitKsgq7YVW0AVR3IIiOiL
	QYyb5oRC6I9T65gWNFC0Tk/173isijrf2iEhlE2LQlyQs4UOy90PRBvDiPEBH9LR
	jDwoUGf5PkThY980ZATAYlIEh8TQPvdaRgNonxI4xWyxEPl93M/gpGMo8Q7mNeDB
	sm+08k9VM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=tPoj
	kG55z7XF1Rqc+rOP10MGOSw=; b=p3T7yZWpFqMOq4Y9LOoNOYolVAEuoG3kUvOt
	zffHw7c6s6OJWMLmJGWbu+qCrjgx6R+Q2MlXUDzY9Sp8yihy/fhR9nRAJxC5r46d
	/eD2ylKkka+H70ondQ8cxmwqi1373yFDh1jy/GJUeBdgQY7cgfk7iLhoTPDcxV37
	yj+In58=
X-Sasl-enc: 7S90e591RNyIQjI/IGIb9y/pFYp9nHRJvTO27bByipsB 1340370703
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id DB7A64837F8;
	Fri, 22 Jun 2012 09:11:42 -0400 (EDT)
Message-ID: <4FE46F0B.7080601@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 15:11:39 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<4FE48921020000780008B6D0@nat28.tlf.novell.com>
In-Reply-To: <4FE48921020000780008B6D0@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2332624385856076604=="
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)
--===============2332624385856076604==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig69CE866BAF9066A9B31E8E85"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig69CE866BAF9066A9B31E8E85
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 15:02, Jan Beulich wrote:
>>>> On 22.06.12 at 14:53, Joanna Rutkowska <joanna@invisiblethingslab.co=
m> wrote:
>> > On 06/22/12 14:38, Jan Beulich wrote:
>>>>> >>> > Is there any proposal of how to handle out of memory conditio=
ns in Xen
>>>>> >>> > (like this one, as well as e.g. SWIOTLB problem) in a more us=
er friendly
>>>>> >>> > way?
>>> >> In 4.2, I hope we managed to remove all runtime allocations
>>> >> larger than a page, so the particular situation here should arise
>>> >> anymore.
>>> >>=20
>>> >> As to more user-friendly - what do you think of? An error is an
>>> >> error (and converting this to a meaningful, user visible message
>>> >> is the responsibility of the entity receiving the error). In the
>>> >> case at hand, printing an error message wouldn't meaningfully
>>> >> increase user-friendliness imo.
>> >=20
>> > How would you suggest to let the user (in an interactive desktop sys=
tem,
>> > such as Qubes) know why his or her VM doesn't start? Certainly, some=

>> > savvy user might just analyze the guest's dmesg log but that's reall=
y
>> > not a user friendly solution. And yet the out of memory errors are
>> > something that might happen quite often and are not really "exceptio=
n"
>> > or "errors" in the same sense as e.g. traditional BUG() conditions t=
hat
>> > suggest something really bad happened. The problem here is that this=
 bug
>> > occurs after the domain has been built, and is now running, so xl st=
art
>> > is not a good place to return the error. Same with SWIOTLB out of me=
mory
>> > errors, that again just prevent the domain from starting. Any other
>> > ideas how to handle such situations more gracefully?
> In the case at hand, failing CPU bringup rather than invoking
> BUG() would likely be possible. Then the guest would come up
> single-CPU. (That's a more general theme though: Many BUG()
> instances really don't need to be as harsh.)
>=20
> SWIOTLB allocation is a different thing - if the guest really needs
> it, yet fails to set it up, the most it could do is to defer the crash
> until the first I/O needs to make use of it. Which likely doesn't buy
> much to the user.
>=20

How about having the guest kernel (e.g. every time it is about to BUG())
write the cause of the Xen-related runtime errors (such as out of memory
conditions) to some predefined xenstore key, which would allow the
management tools/whatever other software to retrieve that easily and
display a meaningful message to the user? Hm... access to the xenstore
might not be easy at the early VM boot stage -- so perhaps writing it
into some predefined shared page, that could be easily read by the
toolstack?

joanna.


--------------enig69CE866BAF9066A9B31E8E85
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5G8LAAoJEDaIqHeRBUM0zzMH/jrW69qImpxiwpysyHCWrBo2
kq5bCS9Eept1z0490MvjKwS0jRw/NJ6hzkWgD6HcAV/d+5Hdn+CGxRQE0Ve4DOSH
xJ8JH7fVqzfMgAgnmumpkFIVgjEUhkxx+qmiRIJMAfM88NSrXzPiLxhrz/J3Jezz
wdJKFIrd5CyaDVcHFtyU6Zb6QYLMx4zWReuC1iq2syyJBpGxxg7IJ459mgCQBqAs
OUWHUuf5PvmTI6A2m9XokKHKxnJMhyYqadQpdwI1FrjJ83K5qarRXdmF3HxwWkXw
x2JmHV+brie2GzMucRZ44E9q+i2xSNFmu/LVun1yOpMjZJsrHJFiEiu2jTiBGjQ=
=OCpT
-----END PGP SIGNATURE-----

--------------enig69CE866BAF9066A9B31E8E85--


--===============2332624385856076604==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2332624385856076604==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 13:12:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si3eO-0005vw-IP; Fri, 22 Jun 2012 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 <joanna@invisiblethingslab.com>) id 1Si3eN-0005vr-6e
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:11:47 +0000
Received: from [193.109.254.147:14804] by server-1.bemta-14.messagelabs.com id
	E2/98-24612-21F64EF4; Fri, 22 Jun 2012 13:11:46 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340370704!8675680!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18827 invoked from network); 22 Jun 2012 13:11:44 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 13:11:44 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C0FB3207A5;
	Fri, 22 Jun 2012 09:11:43 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Fri, 22 Jun 2012 09:11:43 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=tP
	ojkG55z7XF1Rqc+rOP10MGOSw=; b=JCz3jbf1YV1YgitKsgq7YVW0AVR3IIiOiL
	QYyb5oRC6I9T65gWNFC0Tk/173isijrf2iEhlE2LQlyQs4UOy90PRBvDiPEBH9LR
	jDwoUGf5PkThY980ZATAYlIEh8TQPvdaRgNonxI4xWyxEPl93M/gpGMo8Q7mNeDB
	sm+08k9VM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=tPoj
	kG55z7XF1Rqc+rOP10MGOSw=; b=p3T7yZWpFqMOq4Y9LOoNOYolVAEuoG3kUvOt
	zffHw7c6s6OJWMLmJGWbu+qCrjgx6R+Q2MlXUDzY9Sp8yihy/fhR9nRAJxC5r46d
	/eD2ylKkka+H70ondQ8cxmwqi1373yFDh1jy/GJUeBdgQY7cgfk7iLhoTPDcxV37
	yj+In58=
X-Sasl-enc: 7S90e591RNyIQjI/IGIb9y/pFYp9nHRJvTO27bByipsB 1340370703
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id DB7A64837F8;
	Fri, 22 Jun 2012 09:11:42 -0400 (EDT)
Message-ID: <4FE46F0B.7080601@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 15:11:39 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<4FE48921020000780008B6D0@nat28.tlf.novell.com>
In-Reply-To: <4FE48921020000780008B6D0@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2332624385856076604=="
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)
--===============2332624385856076604==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig69CE866BAF9066A9B31E8E85"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig69CE866BAF9066A9B31E8E85
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 15:02, Jan Beulich wrote:
>>>> On 22.06.12 at 14:53, Joanna Rutkowska <joanna@invisiblethingslab.co=
m> wrote:
>> > On 06/22/12 14:38, Jan Beulich wrote:
>>>>> >>> > Is there any proposal of how to handle out of memory conditio=
ns in Xen
>>>>> >>> > (like this one, as well as e.g. SWIOTLB problem) in a more us=
er friendly
>>>>> >>> > way?
>>> >> In 4.2, I hope we managed to remove all runtime allocations
>>> >> larger than a page, so the particular situation here should arise
>>> >> anymore.
>>> >>=20
>>> >> As to more user-friendly - what do you think of? An error is an
>>> >> error (and converting this to a meaningful, user visible message
>>> >> is the responsibility of the entity receiving the error). In the
>>> >> case at hand, printing an error message wouldn't meaningfully
>>> >> increase user-friendliness imo.
>> >=20
>> > How would you suggest to let the user (in an interactive desktop sys=
tem,
>> > such as Qubes) know why his or her VM doesn't start? Certainly, some=

>> > savvy user might just analyze the guest's dmesg log but that's reall=
y
>> > not a user friendly solution. And yet the out of memory errors are
>> > something that might happen quite often and are not really "exceptio=
n"
>> > or "errors" in the same sense as e.g. traditional BUG() conditions t=
hat
>> > suggest something really bad happened. The problem here is that this=
 bug
>> > occurs after the domain has been built, and is now running, so xl st=
art
>> > is not a good place to return the error. Same with SWIOTLB out of me=
mory
>> > errors, that again just prevent the domain from starting. Any other
>> > ideas how to handle such situations more gracefully?
> In the case at hand, failing CPU bringup rather than invoking
> BUG() would likely be possible. Then the guest would come up
> single-CPU. (That's a more general theme though: Many BUG()
> instances really don't need to be as harsh.)
>=20
> SWIOTLB allocation is a different thing - if the guest really needs
> it, yet fails to set it up, the most it could do is to defer the crash
> until the first I/O needs to make use of it. Which likely doesn't buy
> much to the user.
>=20

How about having the guest kernel (e.g. every time it is about to BUG())
write the cause of the Xen-related runtime errors (such as out of memory
conditions) to some predefined xenstore key, which would allow the
management tools/whatever other software to retrieve that easily and
display a meaningful message to the user? Hm... access to the xenstore
might not be easy at the early VM boot stage -- so perhaps writing it
into some predefined shared page, that could be easily read by the
toolstack?

joanna.


--------------enig69CE866BAF9066A9B31E8E85
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5G8LAAoJEDaIqHeRBUM0zzMH/jrW69qImpxiwpysyHCWrBo2
kq5bCS9Eept1z0490MvjKwS0jRw/NJ6hzkWgD6HcAV/d+5Hdn+CGxRQE0Ve4DOSH
xJ8JH7fVqzfMgAgnmumpkFIVgjEUhkxx+qmiRIJMAfM88NSrXzPiLxhrz/J3Jezz
wdJKFIrd5CyaDVcHFtyU6Zb6QYLMx4zWReuC1iq2syyJBpGxxg7IJ459mgCQBqAs
OUWHUuf5PvmTI6A2m9XokKHKxnJMhyYqadQpdwI1FrjJ83K5qarRXdmF3HxwWkXw
x2JmHV+brie2GzMucRZ44E9q+i2xSNFmu/LVun1yOpMjZJsrHJFiEiu2jTiBGjQ=
=OCpT
-----END PGP SIGNATURE-----

--------------enig69CE866BAF9066A9B31E8E85--


--===============2332624385856076604==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2332624385856076604==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 13:21:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si3n5-00066n-KE; Fri, 22 Jun 2012 13:20: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 1Si3n4-00066f-0Z
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:20:46 +0000
Received: from [85.158.143.35:57302] by server-1.bemta-4.messagelabs.com id
	42/9E-24392-D2174EF4; Fri, 22 Jun 2012 13:20:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340371238!10453416!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27449 invoked from network); 22 Jun 2012 13:20:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	22 Jun 2012 13:20:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 14:20:37 +0100
Message-Id: <4FE48D70020000780008B6EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 14:21:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<4FE48921020000780008B6D0@nat28.tlf.novell.com>
	<4FE46F0B.7080601@invisiblethingslab.com>
In-Reply-To: <4FE46F0B.7080601@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:11, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> How about having the guest kernel (e.g. every time it is about to BUG())
> write the cause of the Xen-related runtime errors (such as out of memory
> conditions) to some predefined xenstore key, which would allow the
> management tools/whatever other software to retrieve that easily and
> display a meaningful message to the user? Hm... access to the xenstore
> might not be easy at the early VM boot stage -- so perhaps writing it
> into some predefined shared page, that could be easily read by the
> toolstack?

That's the console shared page, isn't 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 Jun 22 13:21:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si3n5-00066n-KE; Fri, 22 Jun 2012 13:20: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 1Si3n4-00066f-0Z
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:20:46 +0000
Received: from [85.158.143.35:57302] by server-1.bemta-4.messagelabs.com id
	42/9E-24392-D2174EF4; Fri, 22 Jun 2012 13:20:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340371238!10453416!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27449 invoked from network); 22 Jun 2012 13:20:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	22 Jun 2012 13:20:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 14:20:37 +0100
Message-Id: <4FE48D70020000780008B6EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 14:21:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<4FE48921020000780008B6D0@nat28.tlf.novell.com>
	<4FE46F0B.7080601@invisiblethingslab.com>
In-Reply-To: <4FE46F0B.7080601@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:11, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> How about having the guest kernel (e.g. every time it is about to BUG())
> write the cause of the Xen-related runtime errors (such as out of memory
> conditions) to some predefined xenstore key, which would allow the
> management tools/whatever other software to retrieve that easily and
> display a meaningful message to the user? Hm... access to the xenstore
> might not be easy at the early VM boot stage -- so perhaps writing it
> into some predefined shared page, that could be easily read by the
> toolstack?

That's the console shared page, isn't 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 Jun 22 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si3qm-0006Et-8t; Fri, 22 Jun 2012 13:24:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si3qk-0006Eh-I6
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:24:34 +0000
Received: from [85.158.143.99:55618] by server-3.bemta-4.messagelabs.com id
	B1/BF-05808-11274EF4; Fri, 22 Jun 2012 13:24:33 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340371469!21600542!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23472 invoked from network); 22 Jun 2012 13:24:32 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 13:24:32 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C7C9A20AEF;
	Fri, 22 Jun 2012 09:24:28 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute4.internal (MEProxy); Fri, 22 Jun 2012 09:24:28 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=tL
	Mn5qKcjd87Le+0YB6DSubuTPY=; b=KiElkPd1Uus1p0lEM34yWuTrgKTonp/6Zm
	r3WRHZLMmNTYUCFQgfFeXYTFmCb0UlcBK7MwKqpH244uV4HwNAgEJm12LAGZusUz
	88Y+tFvsramln/29YI8GMuQoa2+kcPoZ4Jkn8bP9Sdwb1TK9XDISpu/WFwJotX5K
	MZlpOPGXU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=tLMn
	5qKcjd87Le+0YB6DSubuTPY=; b=pDqvAYyAtwgGqnc7RfWZ4kVi5pRpdJGjhsEw
	qIhcfJQVXoW8ftySCS0T2mfe1QgV4Bel8Z9tUpSeQqs8Oi53l6l7KhCRBLztMrGq
	3QEZh0yZkglFnXQBWIUhnaCeoWLVe5FZM5dWJONsFpHa6v3dfPItR3SLEijaUsJO
	eRoPOu0=
X-Sasl-enc: N/p9LwbRA180fS1QNzrERB/lCLvD1Vk5t/MA+Sz171pb 1340371468
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id E5B2E482740;
	Fri, 22 Jun 2012 09:24:27 -0400 (EDT)
Message-ID: <4FE47208.7040207@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 15:24:24 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<4FE48921020000780008B6D0@nat28.tlf.novell.com>
	<4FE46F0B.7080601@invisiblethingslab.com>
	<4FE48D70020000780008B6EB@nat28.tlf.novell.com>
In-Reply-To: <4FE48D70020000780008B6EB@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1876564328121686516=="
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)
--===============1876564328121686516==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigFF57E6A938A00826B3874463"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFF57E6A938A00826B3874463
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 15:21, Jan Beulich wrote:
>>>> On 22.06.12 at 15:11, Joanna Rutkowska <joanna@invisiblethingslab.co=
m> wrote:
>> > How about having the guest kernel (e.g. every time it is about to BU=
G())
>> > write the cause of the Xen-related runtime errors (such as out of me=
mory
>> > conditions) to some predefined xenstore key, which would allow the
>> > management tools/whatever other software to retrieve that easily and=

>> > display a meaningful message to the user? Hm... access to the xensto=
re
>> > might not be easy at the early VM boot stage -- so perhaps writing i=
t
>> > into some predefined shared page, that could be easily read by the
>> > toolstack?
> That's the console shared page, isn't it?


Yeah, but parsing and interpreting the console output is problematic --
e.g. how should an automatic tool know from the oops message I quoted in
my first message, that the reason for not starting the VM was just an
out of memory? I'm thinking about some simple form of Xen-related
runtime error reporting (this would be mostly out of memory), that would
be easily parse'able by scripts. Again, the goal is display a simple
error message to the user, explaining why his or her VM doesn't start.

joanna.


--------------enigFF57E6A938A00826B3874463
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5HIIAAoJEDaIqHeRBUM073MIANVQrrXYzljrN5NXHKy8Cx8d
DvWdUejSTxSe3YtirluCLa5ZDhknNtUahFJAhc7BSXESxQR1WnN0JtJnmzI5ttx/
h9jbleIqx/vZWC3MSasGuBGgEMGz515CPqKpHgtE72Pykefp/Bdqqya02hMUNcnV
OAsQRs5XzzSQbXite7rD6aGI76EgVZ2fBLRBqRIHyNtdRxsMVFfp7OjDBPxkQ/Pe
uhnkcqZcinHrfinJv0pNd+AtjIivVrpVIaSo1MR70h8YGhHBbLqu0krxb6WJvh8w
Cc9VQ8pZp5Qd6Dm5TZxfNhwylatR2LUL8G2Rw4pkrIZamkq7Q8TbSphACC9ZkOU=
=732p
-----END PGP SIGNATURE-----

--------------enigFF57E6A938A00826B3874463--


--===============1876564328121686516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1876564328121686516==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si3qm-0006Et-8t; Fri, 22 Jun 2012 13:24:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1Si3qk-0006Eh-I6
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:24:34 +0000
Received: from [85.158.143.99:55618] by server-3.bemta-4.messagelabs.com id
	B1/BF-05808-11274EF4; Fri, 22 Jun 2012 13:24:33 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340371469!21600542!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMjA2MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23472 invoked from network); 22 Jun 2012 13:24:32 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jun 2012 13:24:32 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C7C9A20AEF;
	Fri, 22 Jun 2012 09:24:28 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute4.internal (MEProxy); Fri, 22 Jun 2012 09:24:28 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=tL
	Mn5qKcjd87Le+0YB6DSubuTPY=; b=KiElkPd1Uus1p0lEM34yWuTrgKTonp/6Zm
	r3WRHZLMmNTYUCFQgfFeXYTFmCb0UlcBK7MwKqpH244uV4HwNAgEJm12LAGZusUz
	88Y+tFvsramln/29YI8GMuQoa2+kcPoZ4Jkn8bP9Sdwb1TK9XDISpu/WFwJotX5K
	MZlpOPGXU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=tLMn
	5qKcjd87Le+0YB6DSubuTPY=; b=pDqvAYyAtwgGqnc7RfWZ4kVi5pRpdJGjhsEw
	qIhcfJQVXoW8ftySCS0T2mfe1QgV4Bel8Z9tUpSeQqs8Oi53l6l7KhCRBLztMrGq
	3QEZh0yZkglFnXQBWIUhnaCeoWLVe5FZM5dWJONsFpHa6v3dfPItR3SLEijaUsJO
	eRoPOu0=
X-Sasl-enc: N/p9LwbRA180fS1QNzrERB/lCLvD1Vk5t/MA+Sz171pb 1340371468
Received: from [10.137.2.24] (unknown [83.6.100.80])
	by mail.messagingengine.com (Postfix) with ESMTPA id E5B2E482740;
	Fri, 22 Jun 2012 09:24:27 -0400 (EDT)
Message-ID: <4FE47208.7040207@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 15:24:24 +0200
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<4FE48921020000780008B6D0@nat28.tlf.novell.com>
	<4FE46F0B.7080601@invisiblethingslab.com>
	<4FE48D70020000780008B6EB@nat28.tlf.novell.com>
In-Reply-To: <4FE48D70020000780008B6EB@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1876564328121686516=="
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)
--===============1876564328121686516==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigFF57E6A938A00826B3874463"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFF57E6A938A00826B3874463
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/22/12 15:21, Jan Beulich wrote:
>>>> On 22.06.12 at 15:11, Joanna Rutkowska <joanna@invisiblethingslab.co=
m> wrote:
>> > How about having the guest kernel (e.g. every time it is about to BU=
G())
>> > write the cause of the Xen-related runtime errors (such as out of me=
mory
>> > conditions) to some predefined xenstore key, which would allow the
>> > management tools/whatever other software to retrieve that easily and=

>> > display a meaningful message to the user? Hm... access to the xensto=
re
>> > might not be easy at the early VM boot stage -- so perhaps writing i=
t
>> > into some predefined shared page, that could be easily read by the
>> > toolstack?
> That's the console shared page, isn't it?


Yeah, but parsing and interpreting the console output is problematic --
e.g. how should an automatic tool know from the oops message I quoted in
my first message, that the reason for not starting the VM was just an
out of memory? I'm thinking about some simple form of Xen-related
runtime error reporting (this would be mostly out of memory), that would
be easily parse'able by scripts. Again, the goal is display a simple
error message to the user, explaining why his or her VM doesn't start.

joanna.


--------------enigFF57E6A938A00826B3874463
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJP5HIIAAoJEDaIqHeRBUM073MIANVQrrXYzljrN5NXHKy8Cx8d
DvWdUejSTxSe3YtirluCLa5ZDhknNtUahFJAhc7BSXESxQR1WnN0JtJnmzI5ttx/
h9jbleIqx/vZWC3MSasGuBGgEMGz515CPqKpHgtE72Pykefp/Bdqqya02hMUNcnV
OAsQRs5XzzSQbXite7rD6aGI76EgVZ2fBLRBqRIHyNtdRxsMVFfp7OjDBPxkQ/Pe
uhnkcqZcinHrfinJv0pNd+AtjIivVrpVIaSo1MR70h8YGhHBbLqu0krxb6WJvh8w
Cc9VQ8pZp5Qd6Dm5TZxfNhwylatR2LUL8G2Rw4pkrIZamkq7Q8TbSphACC9ZkOU=
=732p
-----END PGP SIGNATURE-----

--------------enigFF57E6A938A00826B3874463--


--===============1876564328121686516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1876564328121686516==--


From xen-devel-bounces@lists.xen.org Fri Jun 22 13:39:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si458-0006Ws-N4; Fri, 22 Jun 2012 13: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.Campbell@citrix.com>) id 1Si457-0006Wn-DE
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:39:25 +0000
Received: from [193.109.254.147:33398] by server-9.bemta-14.messagelabs.com id
	A8/8F-07693-C8574EF4; Fri, 22 Jun 2012 13:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340372364!4247987!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 22 Jun 2012 13:39:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 13:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13171147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 13:39:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 14:39:23 +0100
Message-ID: <1340372362.26083.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 22 Jun 2012 14:39:22 +0100
In-Reply-To: <alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 14:40 +0100, Stefano Stabellini wrote:
> On Fri, 15 Jun 2012, Ian Jackson wrote:
> > This is v4 of my series to asyncify save/restore.  All comments have
> > been addressed.
> > 
> > I have retested this with HVM (RHEL) and PV guests, for both localhost
> > migration and save/restore.  RHEL seems to have some unreliability
> > which occurs with the baseline too.  I was not able to test stub dms
> > at all because when trying to boot my RHEL guest with a stub dm the dm
> > domain immediately crashed.
> 
> IanC, didn't you test xen-unstable with stubdoms not too long ago?
> 
> In any case we should probably add "working stubdoms" to the blocker list.

FWIW I just netbooted my Debian HVM guest with a stubdom on latest tree
and it is indeed knackered.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 13:39:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si458-0006Ws-N4; Fri, 22 Jun 2012 13: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.Campbell@citrix.com>) id 1Si457-0006Wn-DE
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:39:25 +0000
Received: from [193.109.254.147:33398] by server-9.bemta-14.messagelabs.com id
	A8/8F-07693-C8574EF4; Fri, 22 Jun 2012 13:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340372364!4247987!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 22 Jun 2012 13:39:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 13:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13171147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 13:39:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 14:39:23 +0100
Message-ID: <1340372362.26083.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 22 Jun 2012 14:39:22 +0100
In-Reply-To: <alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-15 at 14:40 +0100, Stefano Stabellini wrote:
> On Fri, 15 Jun 2012, Ian Jackson wrote:
> > This is v4 of my series to asyncify save/restore.  All comments have
> > been addressed.
> > 
> > I have retested this with HVM (RHEL) and PV guests, for both localhost
> > migration and save/restore.  RHEL seems to have some unreliability
> > which occurs with the baseline too.  I was not able to test stub dms
> > at all because when trying to boot my RHEL guest with a stub dm the dm
> > domain immediately crashed.
> 
> IanC, didn't you test xen-unstable with stubdoms not too long ago?
> 
> In any case we should probably add "working stubdoms" to the blocker list.

FWIW I just netbooted my Debian HVM guest with a stubdom on latest tree
and it is indeed knackered.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 13:46:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si4C3-0006hV-JH; Fri, 22 Jun 2012 13:46:35 +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 1Si4C2-0006hQ-1T
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 13:46:34 +0000
Received: from [85.158.139.83:9311] by server-12.bemta-5.messagelabs.com id
	78/6F-25233-93774EF4; Fri, 22 Jun 2012 13:46:33 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340372792!29021883!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NjM1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3975 invoked from network); 22 Jun 2012 13:46:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 13:46:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 22 Jun 2012 06:46:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="161254570"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 22 Jun 2012 06:46:20 -0700
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, 22 Jun 2012 06:46:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 21:46:18 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: AQHNUGvJexbUH0BVTLGVMLMLWAtaJ5cGOLAg
Date: Fri, 22 Jun 2012 13:46:17 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
In-Reply-To: <4FE475BE020000780008B624@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 22.06.12 at 12:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 20.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Recently we design xen vMCE as attached.
>>>> Please kindly help me to review it, any comments/suggestions are
>>>> appreciated.
>>> 
>>> The concept looks quite okay, provided no OS has a problem with
>>> the limitations imposed (most notably the restriction to a single
>>> reporting bank, particularly in the context of e.g. Linux partly
>>> ignoring the first bank under some conditions iirc).
>> 
>> 'bank0 skipping' quirks is only for older model cpus, I think we
>> have 2 options: 1). still use 1 bank and simply ignore this issue. I
>> mean, even if guest runs at bank0 quirks platform, when hypervisor
>> inject vMCE# to guest, guest skip bank0, then guest MCE logic would
>> think it detect a spurious mce, then kill itself. Considering bank0
>> quirks is only for old cpus, this is acceptable; 2). use 32 banks
>> 
>> In fact, a third option is, use 1 bank, but hypervisor kill guest
>> when it detect bank0 quirks. This would be same effect as option 1,
>> so I prefer let guest kill itself.
> 
> Out of these, I'd actually favor using 32 banks. Using 2 banks
> instead of 1 might be another option.

Yes, 2 or 32 are both OK. Let's use 32.
(or, 2 is better for some other reasons, let me confirm inside Intel first).

> 
>>> As to not needing any migration specific adjustments - what if
>>> a migration is in progress when an event needs to be delivered?
>> 
>> If a migration is in progress while an event delivered, we abort the
>> migration.
> 
> Is there a way the hypervisor can tell the tools to abort a
> migration? Or are you meaning to say such functionality would
> need to be added?

I didn't check migration code, but I think it could be done by
1). set a flag indecating the case 'migration is in progress while event delivered'.
2). at the last shakehand stage of migration (i.e. A to B), checking the flag and if yes, abort migration.
So guest will continue run at A, and quit at B after timeout.

> 
> One other concern that occurred to me after long having sent
> the original response: Your proposal aims at a fixed,
> unmodifiable vMCE interface. How is that going to be forward
> compatible? I.e. consider you had made that proposal before
> the SRAO/SRAR changes went in - would the same interface (with
> the same set of capability bits set/clear) still be suitable?

Yes, since it's pure s/w emulated interface. At the case when SRAO or SRAR not supported by h/w platform, it's still OK, since under such case hypervisor don't need deliver SRAO or SRAR to guest at all. The emulated vMCE interface just tell the guest that it runs at a virtual platform with those well-defined capabilities.

> 
> I think that we minimally need to retain the MCG_CAP register
> as being of potentially variable content (and hence needing
> saving/restoring on migration). To support this in a forward
> compatible manner, we may have to have a way to tell the
> hypervisor e.g. via command line option which extra MSRs
> have to be treated read-as-zero/writes-ignored upon guest
> accesses.
> 
> Jan

Seems unnecessary, reason as above.

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 Jun 22 13:46:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si4C3-0006hV-JH; Fri, 22 Jun 2012 13:46:35 +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 1Si4C2-0006hQ-1T
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 13:46:34 +0000
Received: from [85.158.139.83:9311] by server-12.bemta-5.messagelabs.com id
	78/6F-25233-93774EF4; Fri, 22 Jun 2012 13:46:33 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340372792!29021883!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NjM1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3975 invoked from network); 22 Jun 2012 13:46:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 13:46:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 22 Jun 2012 06:46:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="161254570"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 22 Jun 2012 06:46:20 -0700
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, 22 Jun 2012 06:46:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 21:46:18 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: AQHNUGvJexbUH0BVTLGVMLMLWAtaJ5cGOLAg
Date: Fri, 22 Jun 2012 13:46:17 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
In-Reply-To: <4FE475BE020000780008B624@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 22.06.12 at 12:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 20.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Recently we design xen vMCE as attached.
>>>> Please kindly help me to review it, any comments/suggestions are
>>>> appreciated.
>>> 
>>> The concept looks quite okay, provided no OS has a problem with
>>> the limitations imposed (most notably the restriction to a single
>>> reporting bank, particularly in the context of e.g. Linux partly
>>> ignoring the first bank under some conditions iirc).
>> 
>> 'bank0 skipping' quirks is only for older model cpus, I think we
>> have 2 options: 1). still use 1 bank and simply ignore this issue. I
>> mean, even if guest runs at bank0 quirks platform, when hypervisor
>> inject vMCE# to guest, guest skip bank0, then guest MCE logic would
>> think it detect a spurious mce, then kill itself. Considering bank0
>> quirks is only for old cpus, this is acceptable; 2). use 32 banks
>> 
>> In fact, a third option is, use 1 bank, but hypervisor kill guest
>> when it detect bank0 quirks. This would be same effect as option 1,
>> so I prefer let guest kill itself.
> 
> Out of these, I'd actually favor using 32 banks. Using 2 banks
> instead of 1 might be another option.

Yes, 2 or 32 are both OK. Let's use 32.
(or, 2 is better for some other reasons, let me confirm inside Intel first).

> 
>>> As to not needing any migration specific adjustments - what if
>>> a migration is in progress when an event needs to be delivered?
>> 
>> If a migration is in progress while an event delivered, we abort the
>> migration.
> 
> Is there a way the hypervisor can tell the tools to abort a
> migration? Or are you meaning to say such functionality would
> need to be added?

I didn't check migration code, but I think it could be done by
1). set a flag indecating the case 'migration is in progress while event delivered'.
2). at the last shakehand stage of migration (i.e. A to B), checking the flag and if yes, abort migration.
So guest will continue run at A, and quit at B after timeout.

> 
> One other concern that occurred to me after long having sent
> the original response: Your proposal aims at a fixed,
> unmodifiable vMCE interface. How is that going to be forward
> compatible? I.e. consider you had made that proposal before
> the SRAO/SRAR changes went in - would the same interface (with
> the same set of capability bits set/clear) still be suitable?

Yes, since it's pure s/w emulated interface. At the case when SRAO or SRAR not supported by h/w platform, it's still OK, since under such case hypervisor don't need deliver SRAO or SRAR to guest at all. The emulated vMCE interface just tell the guest that it runs at a virtual platform with those well-defined capabilities.

> 
> I think that we minimally need to retain the MCG_CAP register
> as being of potentially variable content (and hence needing
> saving/restoring on migration). To support this in a forward
> compatible manner, we may have to have a way to tell the
> hypervisor e.g. via command line option which extra MSRs
> have to be treated read-as-zero/writes-ignored upon guest
> accesses.
> 
> Jan

Seems unnecessary, reason as above.

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 Jun 22 13:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si4FG-0006rC-Bm; Fri, 22 Jun 2012 13:49:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si4FF-0006r5-09
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:49:53 +0000
Received: from [193.109.254.147:14911] by server-4.bemta-14.messagelabs.com id
	FD/B5-02077-00874EF4; Fri, 22 Jun 2012 13:49:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340372991!5447855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29815 invoked from network); 22 Jun 2012 13:49:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 13:49:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13171407"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 13:49:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 14:49:51 +0100
Message-ID: <1340372990.26083.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 22 Jun 2012 14:49:50 +0100
In-Reply-To: <1340372362.26083.117.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
	<1340372362.26083.117.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 14:39 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 14:40 +0100, Stefano Stabellini wrote:
> > On Fri, 15 Jun 2012, Ian Jackson wrote:
> > > This is v4 of my series to asyncify save/restore.  All comments have
> > > been addressed.
> > > 
> > > I have retested this with HVM (RHEL) and PV guests, for both localhost
> > > migration and save/restore.  RHEL seems to have some unreliability
> > > which occurs with the baseline too.  I was not able to test stub dms
> > > at all because when trying to boot my RHEL guest with a stub dm the dm
> > > domain immediately crashed.
> > 
> > IanC, didn't you test xen-unstable with stubdoms not too long ago?
> > 
> > In any case we should probably add "working stubdoms" to the blocker list.
> 
> FWIW I just netbooted my Debian HVM guest with a stubdom on latest tree
> and it is indeed knackered.

BTW before I did that I ran it with modern toolstack but whatever old
stubdom I had lying around and it was fine so I guess this must be a
stubdom side issue for once!

I get these logs:
        xs_watch(/local/domain/0/backend/console/69, be:0x1470e9:69:0x15d3e0)
        xs_directory(/local/domain/0/backend/console/69): EACCES
        xs_watch(/local/domain/0/backend/vkbd/69, be:0x14211d:69:0x15d320)
        xs_directory(/local/domain/0/backend/vkbd/69): EACCES
        (XEN) event_channel.c:232:d70 EVTCHNOP failure: domain 69, error -22
        ERROR: bind_interdomain failed with rc=-22close(0)
        GPF rip: 0xff9a4, error_code=0
        Thread: main
        RIP: e030:[<00000000000ff9a4>]
        RSP: e02b:00000000005cf748  EFLAGS: 00010202
        RAX: 2f302f6e69616d6f RBX: 0000002002009e20 RCX: 0000000000000e09
        RDX: 0000000000000000 RSI: 00000000deadbeef RDI: 2f302f6e69616d6f
        RBP: 00000000005cf748 R08: 0000000000000608 R09: 000000000000000a
        R10: 000000000056f000 R11: fefefefefefefeff R12: 0000000000161980
        R13: 0000000000000000 R14: 0000000000162590 R15: 0000000000000000
        base is 0x5cf748 caller is 0xe587d
        base is 0x5cf798 caller is 0xe5a00
        base is 0x5cf7a8 caller is 0xe2686
        base is 0x5cf7c8 caller is 0x106e5d
        base is 0x5cf7e8 caller is 0xf7b60
        base is 0x5cf818 caller is 0xf9b75
        base is 0x5cf868 caller is 0xf7ab4
        base is 0x5cf888 caller is 0x2b6ee
        base is 0x5cf958 caller is 0x2c369
        base is 0x5cf978 caller is 0x1da01
        base is 0x5cf9e8 caller is 0x8cf9
        base is 0x5cfdf8 caller is 0xdabcb
        base is 0x5cffe8 caller is 0x33da

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 13:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13: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 1Si4FG-0006rC-Bm; Fri, 22 Jun 2012 13:49:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Si4FF-0006r5-09
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 13:49:53 +0000
Received: from [193.109.254.147:14911] by server-4.bemta-14.messagelabs.com id
	FD/B5-02077-00874EF4; Fri, 22 Jun 2012 13:49:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340372991!5447855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29815 invoked from network); 22 Jun 2012 13:49:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 13:49:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13171407"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 13:49:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 14:49:51 +0100
Message-ID: <1340372990.26083.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 22 Jun 2012 14:49:50 +0100
In-Reply-To: <1340372362.26083.117.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.02.1206151431240.3760@kaball.uk.xensource.com>
	<1340372362.26083.117.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 14:39 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 14:40 +0100, Stefano Stabellini wrote:
> > On Fri, 15 Jun 2012, Ian Jackson wrote:
> > > This is v4 of my series to asyncify save/restore.  All comments have
> > > been addressed.
> > > 
> > > I have retested this with HVM (RHEL) and PV guests, for both localhost
> > > migration and save/restore.  RHEL seems to have some unreliability
> > > which occurs with the baseline too.  I was not able to test stub dms
> > > at all because when trying to boot my RHEL guest with a stub dm the dm
> > > domain immediately crashed.
> > 
> > IanC, didn't you test xen-unstable with stubdoms not too long ago?
> > 
> > In any case we should probably add "working stubdoms" to the blocker list.
> 
> FWIW I just netbooted my Debian HVM guest with a stubdom on latest tree
> and it is indeed knackered.

BTW before I did that I ran it with modern toolstack but whatever old
stubdom I had lying around and it was fine so I guess this must be a
stubdom side issue for once!

I get these logs:
        xs_watch(/local/domain/0/backend/console/69, be:0x1470e9:69:0x15d3e0)
        xs_directory(/local/domain/0/backend/console/69): EACCES
        xs_watch(/local/domain/0/backend/vkbd/69, be:0x14211d:69:0x15d320)
        xs_directory(/local/domain/0/backend/vkbd/69): EACCES
        (XEN) event_channel.c:232:d70 EVTCHNOP failure: domain 69, error -22
        ERROR: bind_interdomain failed with rc=-22close(0)
        GPF rip: 0xff9a4, error_code=0
        Thread: main
        RIP: e030:[<00000000000ff9a4>]
        RSP: e02b:00000000005cf748  EFLAGS: 00010202
        RAX: 2f302f6e69616d6f RBX: 0000002002009e20 RCX: 0000000000000e09
        RDX: 0000000000000000 RSI: 00000000deadbeef RDI: 2f302f6e69616d6f
        RBP: 00000000005cf748 R08: 0000000000000608 R09: 000000000000000a
        R10: 000000000056f000 R11: fefefefefefefeff R12: 0000000000161980
        R13: 0000000000000000 R14: 0000000000162590 R15: 0000000000000000
        base is 0x5cf748 caller is 0xe587d
        base is 0x5cf798 caller is 0xe5a00
        base is 0x5cf7a8 caller is 0xe2686
        base is 0x5cf7c8 caller is 0x106e5d
        base is 0x5cf7e8 caller is 0xf7b60
        base is 0x5cf818 caller is 0xf9b75
        base is 0x5cf868 caller is 0xf7ab4
        base is 0x5cf888 caller is 0x2b6ee
        base is 0x5cf958 caller is 0x2c369
        base is 0x5cf978 caller is 0x1da01
        base is 0x5cf9e8 caller is 0x8cf9
        base is 0x5cfdf8 caller is 0xdabcb
        base is 0x5cffe8 caller is 0x33da

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 13:57:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:57: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 1Si4Mn-00076W-Df; Fri, 22 Jun 2012 13:57:41 +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 1Si4Mm-00076Q-ER
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 13:57:40 +0000
Received: from [193.109.254.147:60568] by server-7.bemta-14.messagelabs.com id
	AC/FA-29827-3D974EF4; Fri, 22 Jun 2012 13:57:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340373459!11059413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22089 invoked from network); 22 Jun 2012 13:57:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 13:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13171620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 13:57:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 14:57:39 +0100
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 1Si4Mk-0004S4-Nt;
	Fri, 22 Jun 2012 13:57:38 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Si4Mj-0008DG-NP;
	Fri, 22 Jun 2012 14:57:38 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13320-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 14:57:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13320: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13320 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13320/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  513d5e196e23
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 13:57:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 13:57: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 1Si4Mn-00076W-Df; Fri, 22 Jun 2012 13:57:41 +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 1Si4Mm-00076Q-ER
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 13:57:40 +0000
Received: from [193.109.254.147:60568] by server-7.bemta-14.messagelabs.com id
	AC/FA-29827-3D974EF4; Fri, 22 Jun 2012 13:57:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340373459!11059413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22089 invoked from network); 22 Jun 2012 13:57:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 13:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="13171620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 13:57:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 14:57:39 +0100
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 1Si4Mk-0004S4-Nt;
	Fri, 22 Jun 2012 13:57:38 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Si4Mj-0008DG-NP;
	Fri, 22 Jun 2012 14:57:38 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13320-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 14:57:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13320: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13320 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13320/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13025
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13025
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13025
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13025
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13025
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  513d5e196e23
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 14:47:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 14:47: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 1Si58W-00083q-BC; Fri, 22 Jun 2012 14:47:00 +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 1Si58U-00083l-Sm
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 14:46:59 +0000
Received: from [193.109.254.147:9702] by server-7.bemta-14.messagelabs.com id
	CC/DC-29827-26584EF4; Fri, 22 Jun 2012 14:46:58 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340376415!10251174!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17344 invoked from network); 22 Jun 2012 14:46:56 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 14:46:56 -0000
Received: by qaeb19 with SMTP id b19so429647qae.11
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 07:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=CrnrE5CX+rpkhEvs5y2ja+Ym6Ln5hx6FwIEgNvGA/Vw=;
	b=xxtLMdxG0OFQIoSK6S365zjGRpW/5VVUTdWpfcbNro8u6KTeFbse+o2+MldmtszRhs
	B9Qa/GMRnbGzVsxNIIBP+rpAmv1GJLuEB/2lDZDybf2qKMhjmAT4APCf6OZKqvuYkmpw
	Gg+wPIKP9+KrDXxo8UTjg4heoWebueGjc17llasdU+NRIcHYqSvN31Y7a1XdbgnD6tGg
	Q2yISGhocsympyOZrt5uZuMs0Q6WZsk5uqlfNl2FaFxFG8S+58nzXnpV7ARY8dL2kMKH
	CwlJnTKIfwJJXIhnQCtuyZYJlH9iAG2JKsq4uVgrxZyeVU8WmZzjr5X42vi5xKp65qoi
	GikQ==
MIME-Version: 1.0
Received: by 10.229.135.68 with SMTP id m4mr1250535qct.70.1340376415449; Fri,
	22 Jun 2012 07:46:55 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 07:46:55 -0700 (PDT)
In-Reply-To: <4FE46ABE.9010104@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 15:46:55 +0100
X-Google-Sender-Auth: ckG5Uiw3QLRa0FsIWslNfa_ADdY
Message-ID: <CAFLBxZbayaJcDjoVTe+fbRUSx76373+iv=cZ__EcbU18eC56Tg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>, 
	Jonathan Ludlam <jonathan.ludlam@eu.citrix.com>
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions (was: Re:
 Strange kernel BUG() on PV DomU 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 Fri, Jun 22, 2012 at 1:53 PM, Joanna Rutkowska
<joanna@invisiblethingslab.com> wrote:
>>> > Any recommendations regarding the preferred minimum Xen free memory, as
>>> > reported by xl info, that should be preserved in order to assure Xen
>>> > runs smoothly?
>> In pre-4.2 Xen, there's not much you can do when memory gets
>> fragmented (otherwise you'd have to keep more than half the
>> memory in the box in the hypervisor). With multi-page runtime
>> allocations gone, you should be fine leaving just a minimal amount
>> to the hypervisor.
>
> Right, but 4.2 will not be released until weeks or months :/ And we
> would like to release Qubes 1.0 within weeks...

FWIW, XenServer has had to tackle this same issue.  As I understand
it, what they ended up doing was to have a model of how much memory
they thought each VM was going to use (based on things like guest
memory, video ram size, number of vcpus, and so on).  They then
manually try to track how much memory they think each running VM was
using, and used that to figure out whether they would be able to start
a new VM or not.  Obviously that's a big pain to set up and keep
current; but it has actually seems to work tolerably well for them.

The XenServer toolstack is open source, so it shouldn't be a problem
to share that formula.  If you think that would work for you, I think
Jonathan Ludlam is probably the guy to help out with that.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 14:47:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 14:47: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 1Si58W-00083q-BC; Fri, 22 Jun 2012 14:47:00 +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 1Si58U-00083l-Sm
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 14:46:59 +0000
Received: from [193.109.254.147:9702] by server-7.bemta-14.messagelabs.com id
	CC/DC-29827-26584EF4; Fri, 22 Jun 2012 14:46:58 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340376415!10251174!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17344 invoked from network); 22 Jun 2012 14:46:56 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 14:46:56 -0000
Received: by qaeb19 with SMTP id b19so429647qae.11
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 07:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=CrnrE5CX+rpkhEvs5y2ja+Ym6Ln5hx6FwIEgNvGA/Vw=;
	b=xxtLMdxG0OFQIoSK6S365zjGRpW/5VVUTdWpfcbNro8u6KTeFbse+o2+MldmtszRhs
	B9Qa/GMRnbGzVsxNIIBP+rpAmv1GJLuEB/2lDZDybf2qKMhjmAT4APCf6OZKqvuYkmpw
	Gg+wPIKP9+KrDXxo8UTjg4heoWebueGjc17llasdU+NRIcHYqSvN31Y7a1XdbgnD6tGg
	Q2yISGhocsympyOZrt5uZuMs0Q6WZsk5uqlfNl2FaFxFG8S+58nzXnpV7ARY8dL2kMKH
	CwlJnTKIfwJJXIhnQCtuyZYJlH9iAG2JKsq4uVgrxZyeVU8WmZzjr5X42vi5xKp65qoi
	GikQ==
MIME-Version: 1.0
Received: by 10.229.135.68 with SMTP id m4mr1250535qct.70.1340376415449; Fri,
	22 Jun 2012 07:46:55 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 07:46:55 -0700 (PDT)
In-Reply-To: <4FE46ABE.9010104@invisiblethingslab.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
Date: Fri, 22 Jun 2012 15:46:55 +0100
X-Google-Sender-Auth: ckG5Uiw3QLRa0FsIWslNfa_ADdY
Message-ID: <CAFLBxZbayaJcDjoVTe+fbRUSx76373+iv=cZ__EcbU18eC56Tg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>, 
	Jonathan Ludlam <jonathan.ludlam@eu.citrix.com>
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions (was: Re:
 Strange kernel BUG() on PV DomU 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 Fri, Jun 22, 2012 at 1:53 PM, Joanna Rutkowska
<joanna@invisiblethingslab.com> wrote:
>>> > Any recommendations regarding the preferred minimum Xen free memory, as
>>> > reported by xl info, that should be preserved in order to assure Xen
>>> > runs smoothly?
>> In pre-4.2 Xen, there's not much you can do when memory gets
>> fragmented (otherwise you'd have to keep more than half the
>> memory in the box in the hypervisor). With multi-page runtime
>> allocations gone, you should be fine leaving just a minimal amount
>> to the hypervisor.
>
> Right, but 4.2 will not be released until weeks or months :/ And we
> would like to release Qubes 1.0 within weeks...

FWIW, XenServer has had to tackle this same issue.  As I understand
it, what they ended up doing was to have a model of how much memory
they thought each VM was going to use (based on things like guest
memory, video ram size, number of vcpus, and so on).  They then
manually try to track how much memory they think each running VM was
using, and used that to figure out whether they would be able to start
a new VM or not.  Obviously that's a big pain to set up and keep
current; but it has actually seems to work tolerably well for them.

The XenServer toolstack is open source, so it shouldn't be a problem
to share that formula.  If you think that would work for you, I think
Jonathan Ludlam is probably the guy to help out with that.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:06:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15:06: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 1Si5RH-0008Jp-3o; Fri, 22 Jun 2012 15:06:23 +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 1Si5RF-0008Jk-7K
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:06:21 +0000
Received: from [85.158.139.83:14311] by server-4.bemta-5.messagelabs.com id
	46/76-27831-CE984EF4; Fri, 22 Jun 2012 15:06:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340377579!24757711!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 22 Jun 2012 15:06:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 15:06:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 16:06:18 +0100
Message-Id: <4FE4A636020000780008B756@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 16:07:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:46, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>> One other concern that occurred to me after long having sent
>> the original response: Your proposal aims at a fixed,
>> unmodifiable vMCE interface. How is that going to be forward
>> compatible? I.e. consider you had made that proposal before
>> the SRAO/SRAR changes went in - would the same interface (with
>> the same set of capability bits set/clear) still be suitable?
> 
> Yes, since it's pure s/w emulated interface. At the case when SRAO or SRAR 
> not supported by h/w platform, it's still OK, since under such case 
> hypervisor don't need deliver SRAO or SRAR to guest at all. The emulated vMCE 
> interface just tell the guest that it runs at a virtual platform with those 
> well-defined capabilities.

I probably didn't express well enough what I want you to check:
Consider you had done the current re-design work without
SRAO/SRAR in mind (e.g. a couple of years ago). Would the
end result have been the same? Namely, would the bits you
nominate to be set/clear in MCG_CAP be the same?

>> I think that we minimally need to retain the MCG_CAP register
>> as being of potentially variable content (and hence needing
>> saving/restoring on migration). To support this in a forward
>> compatible manner, we may have to have a way to tell the
>> hypervisor e.g. via command line option which extra MSRs
>> have to be treated read-as-zero/writes-ignored upon guest
>> accesses.
> 
> Seems unnecessary, reason as above.

So going forward you see no possibility of additions to the
interface that might warrant allowing more bits to be set in
MCG_CAP than you define to be set here? That really looks
unrealistic 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 Jun 22 15:06:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15:06: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 1Si5RH-0008Jp-3o; Fri, 22 Jun 2012 15:06:23 +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 1Si5RF-0008Jk-7K
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:06:21 +0000
Received: from [85.158.139.83:14311] by server-4.bemta-5.messagelabs.com id
	46/76-27831-CE984EF4; Fri, 22 Jun 2012 15:06:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340377579!24757711!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 22 Jun 2012 15:06:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 15:06:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 16:06:18 +0100
Message-Id: <4FE4A636020000780008B756@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 16:07:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:46, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>> One other concern that occurred to me after long having sent
>> the original response: Your proposal aims at a fixed,
>> unmodifiable vMCE interface. How is that going to be forward
>> compatible? I.e. consider you had made that proposal before
>> the SRAO/SRAR changes went in - would the same interface (with
>> the same set of capability bits set/clear) still be suitable?
> 
> Yes, since it's pure s/w emulated interface. At the case when SRAO or SRAR 
> not supported by h/w platform, it's still OK, since under such case 
> hypervisor don't need deliver SRAO or SRAR to guest at all. The emulated vMCE 
> interface just tell the guest that it runs at a virtual platform with those 
> well-defined capabilities.

I probably didn't express well enough what I want you to check:
Consider you had done the current re-design work without
SRAO/SRAR in mind (e.g. a couple of years ago). Would the
end result have been the same? Namely, would the bits you
nominate to be set/clear in MCG_CAP be the same?

>> I think that we minimally need to retain the MCG_CAP register
>> as being of potentially variable content (and hence needing
>> saving/restoring on migration). To support this in a forward
>> compatible manner, we may have to have a way to tell the
>> hypervisor e.g. via command line option which extra MSRs
>> have to be treated read-as-zero/writes-ignored upon guest
>> accesses.
> 
> Seems unnecessary, reason as above.

So going forward you see no possibility of additions to the
interface that might warrant allowing more bits to be set in
MCG_CAP than you define to be set here? That really looks
unrealistic 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 Jun 22 15:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si5gP-00008r-Js; Fri, 22 Jun 2012 15:22:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1Si5gN-00008m-OP
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:21:59 +0000
Received: from [85.158.139.83:32395] by server-12.bemta-5.messagelabs.com id
	92/56-25233-69D84EF4; Fri, 22 Jun 2012 15:21:58 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340378517!21806222!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NjM1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3356 invoked from network); 22 Jun 2012 15:21:58 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 15:21:58 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Jun 2012 08:21:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="157158359"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by orsmga001.jf.intel.com with ESMTP; 22 Jun 2012 08:21:55 -0700
Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 22 Jun 2012 08:21:54 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.217]) by
	ORSMSX151.amr.corp.intel.com ([169.254.7.154]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 08:21:54 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJwBAufgAACbfvoAAAhphAAAEZvmAAALR9gAADp/WcA==
Date: Fri, 22 Jun 2012 15:21:53 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
In-Reply-To: <4FE4A636020000780008B756@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"Raj, Ashok" <ashok.raj@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> I think that we minimally need to retain the MCG_CAP register
>>> as being of potentially variable content (and hence needing
>>> saving/restoring on migration). To support this in a forward
>>> compatible manner, we may have to have a way to tell the
>>> hypervisor e.g. via command line option which extra MSRs
>>> have to be treated read-as-zero/writes-ignored upon guest
>>> accesses.
>> 
>> Seems unnecessary, reason as above.
>
> So going forward you see no possibility of additions to the
> interface that might warrant allowing more bits to be set in
> MCG_CAP than you define to be set here? That really looks
> unrealistic to me.

More bits can be added to MCG_CAP - but this becomes a hard
problem for migration because most OS guests only look at
MCG_CAP at boot time (linux certainly does) ... so if you migrate
and change MCG_CAP to match the new host, the guest will have
no idea that things changed.

MCG_SER_P bit is easy to deal with:
1) You already know about it
2) You can safely set it when the guest is running on a host that
does not support software error recover ... the guest will just
think that SRAO and SRAR events are possible, but they will never
actually occur. Setting it does make sure that the guest will be
ready should you migrate to a system that really does support it.

Future bits would have to be dealt with on a case by case basis.
The same general model would apply ... set the bit everywhere ...
but you might need some Xen changes to virtualize any new resources
and capabilities that were described by the new bit. Side question:
when a guest is migrated from one machine to another, does the version
of Xen running on source and target have to be the same? This tactic
will not work if you migrate a guest running on Xen version 99 that
does have the code to virtualize some new capability to a machine
running Xen version 98 that doesn't.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si5gP-00008r-Js; Fri, 22 Jun 2012 15:22:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1Si5gN-00008m-OP
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:21:59 +0000
Received: from [85.158.139.83:32395] by server-12.bemta-5.messagelabs.com id
	92/56-25233-69D84EF4; Fri, 22 Jun 2012 15:21:58 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340378517!21806222!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjg5NjM1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3356 invoked from network); 22 Jun 2012 15:21:58 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 15:21:58 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 22 Jun 2012 08:21:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="157158359"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by orsmga001.jf.intel.com with ESMTP; 22 Jun 2012 08:21:55 -0700
Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 22 Jun 2012 08:21:54 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.217]) by
	ORSMSX151.amr.corp.intel.com ([169.254.7.154]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 08:21:54 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJwBAufgAACbfvoAAAhphAAAEZvmAAALR9gAADp/WcA==
Date: Fri, 22 Jun 2012 15:21:53 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
In-Reply-To: <4FE4A636020000780008B756@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"Raj, Ashok" <ashok.raj@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> I think that we minimally need to retain the MCG_CAP register
>>> as being of potentially variable content (and hence needing
>>> saving/restoring on migration). To support this in a forward
>>> compatible manner, we may have to have a way to tell the
>>> hypervisor e.g. via command line option which extra MSRs
>>> have to be treated read-as-zero/writes-ignored upon guest
>>> accesses.
>> 
>> Seems unnecessary, reason as above.
>
> So going forward you see no possibility of additions to the
> interface that might warrant allowing more bits to be set in
> MCG_CAP than you define to be set here? That really looks
> unrealistic to me.

More bits can be added to MCG_CAP - but this becomes a hard
problem for migration because most OS guests only look at
MCG_CAP at boot time (linux certainly does) ... so if you migrate
and change MCG_CAP to match the new host, the guest will have
no idea that things changed.

MCG_SER_P bit is easy to deal with:
1) You already know about it
2) You can safely set it when the guest is running on a host that
does not support software error recover ... the guest will just
think that SRAO and SRAR events are possible, but they will never
actually occur. Setting it does make sure that the guest will be
ready should you migrate to a system that really does support it.

Future bits would have to be dealt with on a case by case basis.
The same general model would apply ... set the bit everywhere ...
but you might need some Xen changes to virtualize any new resources
and capabilities that were described by the new bit. Side question:
when a guest is migrated from one machine to another, does the version
of Xen running on source and target have to be the same? This tactic
will not work if you migrate a guest running on Xen version 99 that
does have the code to virtualize some new capability to a machine
running Xen version 98 that doesn't.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:23:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si5h6-0000B4-1U; Fri, 22 Jun 2012 15:22:44 +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 1Si5h5-0000Ar-7D
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 15:22:43 +0000
Received: from [85.158.138.51:3824] by server-9.bemta-3.messagelabs.com id
	C4/4A-10419-2CD84EF4; Fri, 22 Jun 2012 15:22:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340378560!26152001!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13590 invoked from network); 22 Jun 2012 15:22:41 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 15:22:41 -0000
Received: by qaeb19 with SMTP id b19so456318qae.11
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 08:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=c/pUpXFxAUO2hTpn8Ax0iQrHfdDKfv1+Mn0R+Sv7SmI=;
	b=z6Gv5q9jFwWAq0ezOv22hnjgBKBEaj/9qcI2dN9kHxQ9yEdQ/yze4HFEPTI9jw+LSA
	Ps6AdrWrmtjQhZdrokgTWA3wooIWuKRtSQD8+RQ9cu5mixi+vtMo7lgdlIEWeg/du6tm
	pOTMPy9WlRE8KGuSwS340wUS7qjUmA8o7+UTFjI9TUUms8Ioe7R3QDFas0uwURMY3NOz
	1QEc/YEVL3cDRAGAu73Rs6hhHrSZAGx7M9OJUmiL8QYns1pBDtaZa3atPs76tqdgXs+K
	Yzu5jO4Cnrf9jwn1JjkGc+auLzpM/9rH/37SkoKYaGd6OWrJyJHeotnzGbGt9pFgNjJL
	1kxw==
MIME-Version: 1.0
Received: by 10.224.185.130 with SMTP id co2mr7059607qab.25.1340378560453;
	Fri, 22 Jun 2012 08:22:40 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 08:22:40 -0700 (PDT)
In-Reply-To: <CAFLBxZbayaJcDjoVTe+fbRUSx76373+iv=cZ__EcbU18eC56Tg@mail.gmail.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<CAFLBxZbayaJcDjoVTe+fbRUSx76373+iv=cZ__EcbU18eC56Tg@mail.gmail.com>
Date: Fri, 22 Jun 2012 16:22:40 +0100
X-Google-Sender-Auth: 0pLbhSQeYGH3cMwuwCiGgJdlbCY
Message-ID: <CAFLBxZboMvKjzxh4rMQZPxRUoUrLcNgbhcmbKfCoH1ZKdw35Ag@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>, 
	Jonathan Ludlam <jonathan.ludlam@eu.citrix.com>
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions (was: Re:
 Strange kernel BUG() on PV DomU 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="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, Jun 22, 2012 at 3:46 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
>> Right, but 4.2 will not be released until weeks or months :/ And we
>> would like to release Qubes 1.0 within weeks...
>
> FWIW, XenServer has had to tackle this same issue. =A0As I understand
> it, what they ended up doing was to have a model of how much memory
> they thought each VM was going to use (based on things like guest
> memory, video ram size, number of vcpus, and so on). =A0They then
> manually try to track how much memory they think each running VM was
> using, and used that to figure out whether they would be able to start
> a new VM or not. =A0Obviously that's a big pain to set up and keep
> current; but it has actually seems to work tolerably well for them.

And I realize this is basically:
 Patient: "Doc it hurts when I do this" [demonstrates]
 Doctor: "Then don't do that."

It would be great to offer something better, but as Jan said, that's
unfortunately the best that 4.1 has to offer at the moment.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:23:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si5h6-0000B4-1U; Fri, 22 Jun 2012 15:22:44 +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 1Si5h5-0000Ar-7D
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 15:22:43 +0000
Received: from [85.158.138.51:3824] by server-9.bemta-3.messagelabs.com id
	C4/4A-10419-2CD84EF4; Fri, 22 Jun 2012 15:22:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340378560!26152001!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13590 invoked from network); 22 Jun 2012 15:22:41 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 15:22:41 -0000
Received: by qaeb19 with SMTP id b19so456318qae.11
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 08:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=c/pUpXFxAUO2hTpn8Ax0iQrHfdDKfv1+Mn0R+Sv7SmI=;
	b=z6Gv5q9jFwWAq0ezOv22hnjgBKBEaj/9qcI2dN9kHxQ9yEdQ/yze4HFEPTI9jw+LSA
	Ps6AdrWrmtjQhZdrokgTWA3wooIWuKRtSQD8+RQ9cu5mixi+vtMo7lgdlIEWeg/du6tm
	pOTMPy9WlRE8KGuSwS340wUS7qjUmA8o7+UTFjI9TUUms8Ioe7R3QDFas0uwURMY3NOz
	1QEc/YEVL3cDRAGAu73Rs6hhHrSZAGx7M9OJUmiL8QYns1pBDtaZa3atPs76tqdgXs+K
	Yzu5jO4Cnrf9jwn1JjkGc+auLzpM/9rH/37SkoKYaGd6OWrJyJHeotnzGbGt9pFgNjJL
	1kxw==
MIME-Version: 1.0
Received: by 10.224.185.130 with SMTP id co2mr7059607qab.25.1340378560453;
	Fri, 22 Jun 2012 08:22:40 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 22 Jun 2012 08:22:40 -0700 (PDT)
In-Reply-To: <CAFLBxZbayaJcDjoVTe+fbRUSx76373+iv=cZ__EcbU18eC56Tg@mail.gmail.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
	<CAFLBxZbayaJcDjoVTe+fbRUSx76373+iv=cZ__EcbU18eC56Tg@mail.gmail.com>
Date: Fri, 22 Jun 2012 16:22:40 +0100
X-Google-Sender-Auth: 0pLbhSQeYGH3cMwuwCiGgJdlbCY
Message-ID: <CAFLBxZboMvKjzxh4rMQZPxRUoUrLcNgbhcmbKfCoH1ZKdw35Ag@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>, 
	Jonathan Ludlam <jonathan.ludlam@eu.citrix.com>
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions (was: Re:
 Strange kernel BUG() on PV DomU 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="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, Jun 22, 2012 at 3:46 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
>> Right, but 4.2 will not be released until weeks or months :/ And we
>> would like to release Qubes 1.0 within weeks...
>
> FWIW, XenServer has had to tackle this same issue. =A0As I understand
> it, what they ended up doing was to have a model of how much memory
> they thought each VM was going to use (based on things like guest
> memory, video ram size, number of vcpus, and so on). =A0They then
> manually try to track how much memory they think each running VM was
> using, and used that to figure out whether they would be able to start
> a new VM or not. =A0Obviously that's a big pain to set up and keep
> current; but it has actually seems to work tolerably well for them.

And I realize this is basically:
 Patient: "Doc it hurts when I do this" [demonstrates]
 Doctor: "Then don't do that."

It would be great to offer something better, but as Jan said, that's
unfortunately the best that 4.1 has to offer at the moment.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:30:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15:30: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 1Si5ny-0000Sb-3V; Fri, 22 Jun 2012 15:29:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1Si5nw-0000SW-8X
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:29:48 +0000
Received: from [85.158.139.83:12361] by server-12.bemta-5.messagelabs.com id
	68/0A-25233-B6F84EF4; Fri, 22 Jun 2012 15:29:47 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340378983!29034503!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk5Mjc1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7703 invoked from network); 22 Jun 2012 15:29:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 15:29:46 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 22 Jun 2012 08:29:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="159608865"
Received: from orsmsx606.amr.corp.intel.com ([10.22.226.128])
	by azsmga001.ch.intel.com with ESMTP; 22 Jun 2012 08:29:42 -0700
Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by
	orsmsx606.amr.corp.intel.com (10.22.226.128) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 22 Jun 2012 08:29:42 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.217]) by
	ORSMSX153.amr.corp.intel.com ([169.254.13.115]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 08:29:41 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJwBAufgAACbfvoAAAhphAAAGzxWA
Date: Fri, 22 Jun 2012 15:29:41 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
In-Reply-To: <4FE475BE020000780008B624@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"Raj, Ashok" <ashok.raj@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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). still use 1 bank and simply ignore this issue. I mean, even if guest 
> runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest 
> skip bank0, then guest MCE logic would think it detect a spurious mce, then 
> kill itself. Considering bank0 quirks is only for old cpus, this is 
> acceptable;
> 2). use 32 banks
> 
> In fact, a third option is, use 1 bank, but hypervisor kill guest when it 
> detect bank0 quirks. This would be same effect as option 1, so I prefer let 
> guest kill itself.

Don't you control what CPUID is shown to the guest? Under what circumstances
would you tell the guest that it is running on an AMD-K7 or an Intel family
6 with model < 0x1A?   Surely for migration reasons you need to present the
same virtualized family/model all the time ... so just don't use ones that
cause problems.

If that isn't an option - then say there are 2 banks and have Xen ignore bank
0 (make MC0_STATUS always appear to contain 0) and put all the errors into
bank1.  If you tell the guest there are 32 banks it will read all of them.
Which means a lot of pointless exits to the hypervisor.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:30:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15:30: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 1Si5ny-0000Sb-3V; Fri, 22 Jun 2012 15:29:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1Si5nw-0000SW-8X
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:29:48 +0000
Received: from [85.158.139.83:12361] by server-12.bemta-5.messagelabs.com id
	68/0A-25233-B6F84EF4; Fri, 22 Jun 2012 15:29:47 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340378983!29034503!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjk5Mjc1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7703 invoked from network); 22 Jun 2012 15:29:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-182.messagelabs.com with SMTP;
	22 Jun 2012 15:29:46 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 22 Jun 2012 08:29:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="159608865"
Received: from orsmsx606.amr.corp.intel.com ([10.22.226.128])
	by azsmga001.ch.intel.com with ESMTP; 22 Jun 2012 08:29:42 -0700
Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by
	orsmsx606.amr.corp.intel.com (10.22.226.128) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 22 Jun 2012 08:29:42 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.217]) by
	ORSMSX153.amr.corp.intel.com ([169.254.13.115]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 08:29:41 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJwBAufgAACbfvoAAAhphAAAGzxWA
Date: Fri, 22 Jun 2012 15:29:41 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
In-Reply-To: <4FE475BE020000780008B624@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"Raj, Ashok" <ashok.raj@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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). still use 1 bank and simply ignore this issue. I mean, even if guest 
> runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest 
> skip bank0, then guest MCE logic would think it detect a spurious mce, then 
> kill itself. Considering bank0 quirks is only for old cpus, this is 
> acceptable;
> 2). use 32 banks
> 
> In fact, a third option is, use 1 bank, but hypervisor kill guest when it 
> detect bank0 quirks. This would be same effect as option 1, so I prefer let 
> guest kill itself.

Don't you control what CPUID is shown to the guest? Under what circumstances
would you tell the guest that it is running on an AMD-K7 or an Intel family
6 with model < 0x1A?   Surely for migration reasons you need to present the
same virtualized family/model all the time ... so just don't use ones that
cause problems.

If that isn't an option - then say there are 2 banks and have Xen ignore bank
0 (make MC0_STATUS always appear to contain 0) and put all the errors into
bank1.  If you tell the guest there are 32 banks it will read all of them.
Which means a lot of pointless exits to the hypervisor.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:48:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si65c-00013A-Sa; Fri, 22 Jun 2012 15:48: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 1Si65b-000131-5M
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:48:03 +0000
Received: from [85.158.138.51:41564] by server-11.bemta-3.messagelabs.com id
	09/31-02904-2B394EF4; Fri, 22 Jun 2012 15:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340380081!10369871!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20266 invoked from network); 22 Jun 2012 15:48:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 15:48:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 16:48:01 +0100
Message-Id: <4FE4AFFD020000780008B799@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 16:48:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Tony Luck" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yunhong Jiang <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Susie Li <susie.li@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:21, "Luck, Tony" <tony.luck@intel.com> wrote:
>>>> I think that we minimally need to retain the MCG_CAP register
>>>> as being of potentially variable content (and hence needing
>>>> saving/restoring on migration). To support this in a forward
>>>> compatible manner, we may have to have a way to tell the
>>>> hypervisor e.g. via command line option which extra MSRs
>>>> have to be treated read-as-zero/writes-ignored upon guest
>>>> accesses.
>>> 
>>> Seems unnecessary, reason as above.
>>
>> So going forward you see no possibility of additions to the
>> interface that might warrant allowing more bits to be set in
>> MCG_CAP than you define to be set here? That really looks
>> unrealistic to me.
> 
> More bits can be added to MCG_CAP - but this becomes a hard
> problem for migration because most OS guests only look at
> MCG_CAP at boot time (linux certainly does) ... so if you migrate
> and change MCG_CAP to match the new host, the guest will have
> no idea that things changed.

And it doesn't have to - respective events will just not occur
anymore. All we need to make sure is that if it accesses an MSR
that's no longer backed by anything in hardware, we don't
inject a #GP (but instead return e.g. all zeros to reads, and
drop all writes).

> MCG_SER_P bit is easy to deal with:
> 1) You already know about it
> 2) You can safely set it when the guest is running on a host that
> does not support software error recover ... the guest will just
> think that SRAO and SRAR events are possible, but they will never
> actually occur. Setting it does make sure that the guest will be
> ready should you migrate to a system that really does support it.

And so is likely going to be the case for at least some of the
additions to come.

> Future bits would have to be dealt with on a case by case basis.
> The same general model would apply ... set the bit everywhere ...
> but you might need some Xen changes to virtualize any new resources
> and capabilities that were described by the new bit. Side question:
> when a guest is migrated from one machine to another, does the version
> of Xen running on source and target have to be the same? This tactic
> will not work if you migrate a guest running on Xen version 99 that
> does have the code to virtualize some new capability to a machine
> running Xen version 98 that doesn't.

No, that's not a requirement, and hence we need to create a
model that will at least always allow upward (destination host
running higher version Xen than source) migration, and that
preserves as much functionality as possible when moved
between hosts with different MCA capabilities.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:48:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si65c-00013A-Sa; Fri, 22 Jun 2012 15:48: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 1Si65b-000131-5M
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:48:03 +0000
Received: from [85.158.138.51:41564] by server-11.bemta-3.messagelabs.com id
	09/31-02904-2B394EF4; Fri, 22 Jun 2012 15:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340380081!10369871!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20266 invoked from network); 22 Jun 2012 15:48:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 15:48:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 16:48:01 +0100
Message-Id: <4FE4AFFD020000780008B799@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 16:48:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Tony Luck" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yunhong Jiang <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Susie Li <susie.li@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:21, "Luck, Tony" <tony.luck@intel.com> wrote:
>>>> I think that we minimally need to retain the MCG_CAP register
>>>> as being of potentially variable content (and hence needing
>>>> saving/restoring on migration). To support this in a forward
>>>> compatible manner, we may have to have a way to tell the
>>>> hypervisor e.g. via command line option which extra MSRs
>>>> have to be treated read-as-zero/writes-ignored upon guest
>>>> accesses.
>>> 
>>> Seems unnecessary, reason as above.
>>
>> So going forward you see no possibility of additions to the
>> interface that might warrant allowing more bits to be set in
>> MCG_CAP than you define to be set here? That really looks
>> unrealistic to me.
> 
> More bits can be added to MCG_CAP - but this becomes a hard
> problem for migration because most OS guests only look at
> MCG_CAP at boot time (linux certainly does) ... so if you migrate
> and change MCG_CAP to match the new host, the guest will have
> no idea that things changed.

And it doesn't have to - respective events will just not occur
anymore. All we need to make sure is that if it accesses an MSR
that's no longer backed by anything in hardware, we don't
inject a #GP (but instead return e.g. all zeros to reads, and
drop all writes).

> MCG_SER_P bit is easy to deal with:
> 1) You already know about it
> 2) You can safely set it when the guest is running on a host that
> does not support software error recover ... the guest will just
> think that SRAO and SRAR events are possible, but they will never
> actually occur. Setting it does make sure that the guest will be
> ready should you migrate to a system that really does support it.

And so is likely going to be the case for at least some of the
additions to come.

> Future bits would have to be dealt with on a case by case basis.
> The same general model would apply ... set the bit everywhere ...
> but you might need some Xen changes to virtualize any new resources
> and capabilities that were described by the new bit. Side question:
> when a guest is migrated from one machine to another, does the version
> of Xen running on source and target have to be the same? This tactic
> will not work if you migrate a guest running on Xen version 99 that
> does have the code to virtualize some new capability to a machine
> running Xen version 98 that doesn't.

No, that's not a requirement, and hence we need to create a
model that will at least always allow upward (destination host
running higher version Xen than source) migration, and that
preserves as much functionality as possible when moved
between hosts with different MCA capabilities.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si6BZ-0001GN-Lr; Fri, 22 Jun 2012 15:54: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 1Si6BX-0001GH-Ol
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:54:11 +0000
Received: from [85.158.138.51:24242] by server-3.bemta-3.messagelabs.com id
	84/38-26490-22594EF4; Fri, 22 Jun 2012 15:54:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340380450!29127473!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 22 Jun 2012 15:54:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 15:54:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 16:54:10 +0100
Message-Id: <4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 16:54:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Tony Luck" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yunhong Jiang <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Susie Li <susie.li@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:29, "Luck, Tony" <tony.luck@intel.com> wrote:
>>  1). still use 1 bank and simply ignore this issue. I mean, even if guest 
>> runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest 
>> skip bank0, then guest MCE logic would think it detect a spurious mce, then 
>> kill itself. Considering bank0 quirks is only for old cpus, this is 
>> acceptable;
>> 2). use 32 banks
>> 
>> In fact, a third option is, use 1 bank, but hypervisor kill guest when it 
>> detect bank0 quirks. This would be same effect as option 1, so I prefer let 
>> guest kill itself.
> 
> Don't you control what CPUID is shown to the guest? Under what circumstances
> would you tell the guest that it is running on an AMD-K7 or an Intel family
> 6 with model < 0x1A?   Surely for migration reasons you need to present the
> same virtualized family/model all the time ... so just don't use ones that
> cause problems.

I don't think family/model/stepping are frequently faked, it's
normally just the various feature flags that get normalized to
the smallest common set.

> If that isn't an option - then say there are 2 banks and have Xen ignore bank
> 0 (make MC0_STATUS always appear to contain 0) and put all the errors into
> bank1.  If you tell the guest there are 32 banks it will read all of them.
> Which means a lot of pointless exits to the hypervisor.

Indeed, emulating too many banks can have its own downsides.
Yet I don't think we're really concerned about performance when
handling machine checks. But having more than one usable bank
must have advantages, else hardware wouldn't implement things
that way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si6BZ-0001GN-Lr; Fri, 22 Jun 2012 15:54: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 1Si6BX-0001GH-Ol
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 15:54:11 +0000
Received: from [85.158.138.51:24242] by server-3.bemta-3.messagelabs.com id
	84/38-26490-22594EF4; Fri, 22 Jun 2012 15:54:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340380450!29127473!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2ODA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 22 Jun 2012 15:54:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 15:54:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Jun 2012 16:54:10 +0100
Message-Id: <4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 22 Jun 2012 16:54:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Tony Luck" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yunhong Jiang <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Susie Li <susie.li@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:29, "Luck, Tony" <tony.luck@intel.com> wrote:
>>  1). still use 1 bank and simply ignore this issue. I mean, even if guest 
>> runs at bank0 quirks platform, when hypervisor inject vMCE# to guest, guest 
>> skip bank0, then guest MCE logic would think it detect a spurious mce, then 
>> kill itself. Considering bank0 quirks is only for old cpus, this is 
>> acceptable;
>> 2). use 32 banks
>> 
>> In fact, a third option is, use 1 bank, but hypervisor kill guest when it 
>> detect bank0 quirks. This would be same effect as option 1, so I prefer let 
>> guest kill itself.
> 
> Don't you control what CPUID is shown to the guest? Under what circumstances
> would you tell the guest that it is running on an AMD-K7 or an Intel family
> 6 with model < 0x1A?   Surely for migration reasons you need to present the
> same virtualized family/model all the time ... so just don't use ones that
> cause problems.

I don't think family/model/stepping are frequently faked, it's
normally just the various feature flags that get normalized to
the smallest common set.

> If that isn't an option - then say there are 2 banks and have Xen ignore bank
> 0 (make MC0_STATUS always appear to contain 0) and put all the errors into
> bank1.  If you tell the guest there are 32 banks it will read all of them.
> Which means a lot of pointless exits to the hypervisor.

Indeed, emulating too many banks can have its own downsides.
Yet I don't think we're really concerned about performance when
handling machine checks. But having more than one usable bank
must have advantages, else hardware wouldn't implement things
that way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 15:58:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si6Fo-0001SN-B9; Fri, 22 Jun 2012 15:58:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Si6Fn-0001SI-J3
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 15:58:35 +0000
Received: from [193.109.254.147:24715] by server-9.bemta-14.messagelabs.com id
	BF/0E-07693-A2694EF4; Fri, 22 Jun 2012 15:58:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340380712!5469424!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26785 invoked from network); 22 Jun 2012 15:58:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	22 Jun 2012 15:58:32 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79071589; Fri, 22 Jun 2012 17:58:32 +0200
Message-ID: <1340380698.4775.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 22 Jun 2012 17:58:18 +0200
In-Reply-To: <1340364194.26083.87.camel@zakaz.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
	<1340364194.26083.87.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
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 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6100274881828578320=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6100274881828578320==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-xxDfaBVpR6LDJgl0RaM3"


--=-xxDfaBVpR6LDJgl0RaM3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-22 at 12:23 +0100, Ian Campbell wrote:
> > sched_params_valid is moved and gains a gc+domid parameters and
> > s/ctx/CTX/. The call is placed after
> > libxl__domain_build_info_setdefault in the create path, because
> > set_defaults doesn't have access to the domid and there are other
> > callers which don't even have a domid to give it.
> >=20
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>=20
> After consultation with Ian J and Dario I have committed this one in
> order to get a test pass ASAP. I'll leave the remainder of this series
> to get properly reviewed.
>=20
This looked good at inspection, and it indeed works for the credit
scheduler. Unfortunately, sedf seems to require the domain's vcpus to be
properly setup (in the hypervisor), which is not true at this point (it
is still too early!).

In fact, what happens is it fails right here:

> > diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Fri Jun 22 10:14:46 2012 +0100
> > +++ b/tools/libxl/libxl_create.c	Fri Jun 22 11:41:43 2012 +0100
> > @@ -72,6 +72,49 @@ int libxl__domain_create_info_setdefault
> >      return 0;
> >  }
> > =20
> > +static int sched_params_valid(libxl__gc *gc,
> > +                              uint32_t domid, libxl_domain_sched_param=
s *scp)
> > +{
> > +    int has_weight =3D scp->weight !=3D LIBXL_DOMAIN_SCHED_PARAM_WEIGH=
T_DEFAULT;
> > +    int has_period =3D scp->period !=3D LIBXL_DOMAIN_SCHED_PARAM_PERIO=
D_DEFAULT;
> > +    int has_slice =3D scp->slice !=3D LIBXL_DOMAIN_SCHED_PARAM_SLICE_D=
EFAULT;
> > +    int has_extratime =3D
> > +                scp->extratime !=3D LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME=
_DEFAULT;
> > +    libxl_domain_sched_params sci;
> > +
> > +    libxl_domain_sched_params_get(CTX, domid, &sci);
> > +
With a splat like this:
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c480120d57>] sedf_adjust+0x8bd/0x9ad
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000001
(XEN) rdx: ffff82c4802b7e48   rsi: ffff83023e401000   rdi: ffff83031b3e34e4

Because of this code in xen/common/sched_sedf.c:

        if ( p->vcpu[0] =3D=3D NULL )
        {
            rc =3D -EINVAL;
            goto out;
        }

What I expect to happen, then, is the win7 HVM tests to restart being
successful, but the sedf-s ones restart failing. :-(

New patch against this patch coming. This time I tested it on both sedf
and credit and tested rebooting a domain as well... Let's hope this is
going to be the end of this!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-xxDfaBVpR6LDJgl0RaM3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/klhoACgkQk4XaBE3IOsT0WACgiKMaYBYWjfkLX/FiI6kMB9WG
m6wAnRgz/o8/ykO8FOxUOHqbTQTzDTS5
=vyzB
-----END PGP SIGNATURE-----

--=-xxDfaBVpR6LDJgl0RaM3--



--===============6100274881828578320==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6100274881828578320==--



From xen-devel-bounces@lists.xen.org Fri Jun 22 15:58:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 15: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 1Si6Fo-0001SN-B9; Fri, 22 Jun 2012 15:58:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Si6Fn-0001SI-J3
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 15:58:35 +0000
Received: from [193.109.254.147:24715] by server-9.bemta-14.messagelabs.com id
	BF/0E-07693-A2694EF4; Fri, 22 Jun 2012 15:58:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340380712!5469424!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26785 invoked from network); 22 Jun 2012 15:58:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	22 Jun 2012 15:58:32 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79071589; Fri, 22 Jun 2012 17:58:32 +0200
Message-ID: <1340380698.4775.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 22 Jun 2012 17:58:18 +0200
In-Reply-To: <1340364194.26083.87.camel@zakaz.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
	<1340364194.26083.87.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.2-1+b1 
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 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6100274881828578320=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6100274881828578320==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-xxDfaBVpR6LDJgl0RaM3"


--=-xxDfaBVpR6LDJgl0RaM3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-22 at 12:23 +0100, Ian Campbell wrote:
> > sched_params_valid is moved and gains a gc+domid parameters and
> > s/ctx/CTX/. The call is placed after
> > libxl__domain_build_info_setdefault in the create path, because
> > set_defaults doesn't have access to the domid and there are other
> > callers which don't even have a domid to give it.
> >=20
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>=20
> After consultation with Ian J and Dario I have committed this one in
> order to get a test pass ASAP. I'll leave the remainder of this series
> to get properly reviewed.
>=20
This looked good at inspection, and it indeed works for the credit
scheduler. Unfortunately, sedf seems to require the domain's vcpus to be
properly setup (in the hypervisor), which is not true at this point (it
is still too early!).

In fact, what happens is it fails right here:

> > diff -r 5fb3c536b5a8 -r 998d48ccb890 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Fri Jun 22 10:14:46 2012 +0100
> > +++ b/tools/libxl/libxl_create.c	Fri Jun 22 11:41:43 2012 +0100
> > @@ -72,6 +72,49 @@ int libxl__domain_create_info_setdefault
> >      return 0;
> >  }
> > =20
> > +static int sched_params_valid(libxl__gc *gc,
> > +                              uint32_t domid, libxl_domain_sched_param=
s *scp)
> > +{
> > +    int has_weight =3D scp->weight !=3D LIBXL_DOMAIN_SCHED_PARAM_WEIGH=
T_DEFAULT;
> > +    int has_period =3D scp->period !=3D LIBXL_DOMAIN_SCHED_PARAM_PERIO=
D_DEFAULT;
> > +    int has_slice =3D scp->slice !=3D LIBXL_DOMAIN_SCHED_PARAM_SLICE_D=
EFAULT;
> > +    int has_extratime =3D
> > +                scp->extratime !=3D LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME=
_DEFAULT;
> > +    libxl_domain_sched_params sci;
> > +
> > +    libxl_domain_sched_params_get(CTX, domid, &sci);
> > +
With a splat like this:
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c480120d57>] sedf_adjust+0x8bd/0x9ad
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000001
(XEN) rdx: ffff82c4802b7e48   rsi: ffff83023e401000   rdi: ffff83031b3e34e4

Because of this code in xen/common/sched_sedf.c:

        if ( p->vcpu[0] =3D=3D NULL )
        {
            rc =3D -EINVAL;
            goto out;
        }

What I expect to happen, then, is the win7 HVM tests to restart being
successful, but the sedf-s ones restart failing. :-(

New patch against this patch coming. This time I tested it on both sedf
and credit and tested rebooting a domain as well... Let's hope this is
going to be the end of this!

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-xxDfaBVpR6LDJgl0RaM3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/klhoACgkQk4XaBE3IOsT0WACgiKMaYBYWjfkLX/FiI6kMB9WG
m6wAnRgz/o8/ykO8FOxUOHqbTQTzDTS5
=vyzB
-----END PGP SIGNATURE-----

--=-xxDfaBVpR6LDJgl0RaM3--



--===============6100274881828578320==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6100274881828578320==--



From xen-devel-bounces@lists.xen.org Fri Jun 22 16:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6PS-000282-Eh; Fri, 22 Jun 2012 16:08:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6PQ-00027x-Ng
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:08:32 +0000
Received: from [85.158.138.51:6944] by server-3.bemta-3.messagelabs.com id
	3C/0B-26490-B7894EF4; Fri, 22 Jun 2012 16:08:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340381306!29107500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18133 invoked from network); 22 Jun 2012 16:08:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:08:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13174736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:08:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 17:08:26 +0100
Date: Fri, 22 Jun 2012 17:08:04 +0100
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.1206221634020.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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 0/5] xen/arm: dom1 PV console up and 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

Hi all,
this patch series is based upon Ian's "arm: boot a dom1 to "Calibrating
delay loop" then hang" (http://marc.info/?l=xen-devel&m=133856539418794)
and my "xen/arm: event channels and shared_info page"
(http://marc.info/?l=xen-devel&m=133796319005683) patches series.

It fixes few bugs and implements few missing pieces needed to get the
first PV console up and running. With this patch series applied I can
fully boot a Dom1 guest out of an initramfs and connect to its pv
console in dom0, using xenconsole.

Regarding the console and xenstore pfns, I have used the HVM way of
doing things (speaking in x86 gergo) because they fit naturally in our
scenario.

The corresponding Linux side patch series is going to be posted soon.


Stefano Stabellini (5):
      xen/arm: implement do_hvm_op for ARM
      xen/arm: gic and vgic fixes
      xen/arm: disable the event optimization in the gic
      libxc/arm: allocate xenstore and console pages
      xcbuild: add console and xenstore support

 tools/libxc/xc_dom_arm.c     |   32 +++++++++++++++-------
 tools/xcutils/Makefile       |    4 +-
 tools/xcutils/xcbuild.c      |   58 +++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/gic.c           |   48 ++-------------------------------
 xen/arch/arm/hvm.c           |   60 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c         |    1 +
 xen/arch/arm/vgic.c          |    3 +-
 xen/include/asm-arm/domain.h |    7 +++++
 9 files changed, 154 insertions(+), 60 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6PS-000282-Eh; Fri, 22 Jun 2012 16:08:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6PQ-00027x-Ng
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:08:32 +0000
Received: from [85.158.138.51:6944] by server-3.bemta-3.messagelabs.com id
	3C/0B-26490-B7894EF4; Fri, 22 Jun 2012 16:08:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340381306!29107500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18133 invoked from network); 22 Jun 2012 16:08:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:08:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13174736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:08:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 17:08:26 +0100
Date: Fri, 22 Jun 2012 17:08:04 +0100
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.1206221634020.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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 0/5] xen/arm: dom1 PV console up and 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

Hi all,
this patch series is based upon Ian's "arm: boot a dom1 to "Calibrating
delay loop" then hang" (http://marc.info/?l=xen-devel&m=133856539418794)
and my "xen/arm: event channels and shared_info page"
(http://marc.info/?l=xen-devel&m=133796319005683) patches series.

It fixes few bugs and implements few missing pieces needed to get the
first PV console up and running. With this patch series applied I can
fully boot a Dom1 guest out of an initramfs and connect to its pv
console in dom0, using xenconsole.

Regarding the console and xenstore pfns, I have used the HVM way of
doing things (speaking in x86 gergo) because they fit naturally in our
scenario.

The corresponding Linux side patch series is going to be posted soon.


Stefano Stabellini (5):
      xen/arm: implement do_hvm_op for ARM
      xen/arm: gic and vgic fixes
      xen/arm: disable the event optimization in the gic
      libxc/arm: allocate xenstore and console pages
      xcbuild: add console and xenstore support

 tools/libxc/xc_dom_arm.c     |   32 +++++++++++++++-------
 tools/xcutils/Makefile       |    4 +-
 tools/xcutils/xcbuild.c      |   58 +++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/gic.c           |   48 ++-------------------------------
 xen/arch/arm/hvm.c           |   60 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c         |    1 +
 xen/arch/arm/vgic.c          |    3 +-
 xen/include/asm-arm/domain.h |    7 +++++
 9 files changed, 154 insertions(+), 60 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si6Qh-0002Ci-Re; Fri, 22 Jun 2012 16:09:51 +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 1Si6Qg-0002CB-PY
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:09:50 +0000
Received: from [193.109.254.147:11857] by server-3.bemta-14.messagelabs.com id
	15/39-08687-EC894EF4; Fri, 22 Jun 2012 16:09:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340381387!3962588!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13318 invoked from network); 22 Jun 2012 16:09:49 -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;
	22 Jun 2012 16:09:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199721942"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-NA;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:32 +0100
Message-ID: <1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/5] libxc/arm: allocate xenstore and console
	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

Allocate two additional pages at the end of the guest physical memory
for xenstore and console.
Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
values.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
 1 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index bb86139..df2eefe 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -25,6 +25,10 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
+#define NR_MAGIC_PAGES 2
+#define CONSOLE_PFN_OFFSET 0
+#define XENSTORE_PFN_OFFSET 1
+
 /* ------------------------------------------------------------------------ */
 /*
  * arm guests are hybrid and start off with paging disabled, therefore no
@@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {
     DOMPRINTF_CALLED(dom->xch);
-    /* XXX
-     *   dom->p2m_guest
-     *   dom->start_info_pfn
-     *   dom->xenstore_pfn
-     *   dom->console_pfn
-     */
     return 0;
 }
 
@@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 {
     int rc;
     xen_pfn_t pfn, allocsz, i;
+    xen_pfn_t store_pfn, console_pfn;
 
     fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
             dom->total_pages, dom->rambase_pfn);
 
     dom->shadow_enabled = 1;
 
-    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
 
     fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
             dom->rambase_pfn, dom->total_pages );
     /* setup initial p2m */
-    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
         dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
 
     fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
@@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 
     /* allocate guest memory */
     for ( i = rc = allocsz = 0;
-          (i < dom->total_pages) && !rc;
+          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
           i += allocsz )
     {
-        allocsz = dom->total_pages - i;
+        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
         if ( allocsz > 1024*1024 )
             allocsz = 1024*1024;
         fprintf(stderr, "alloc %"PRI_xen_pfn" at offset %"PRI_xen_pfn" which is %"PRI_xen_pfn"\n",
@@ -168,6 +167,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
     fprintf(stderr, "%s: popl'd p2m_host[%"PRI_xen_pfn"] = %"PRI_xen_pfn"\n",
             __func__, dom->total_pages-1, dom->p2m_host[dom->total_pages-1]);
 
+    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
+    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
+            console_pfn);
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
+            store_pfn);
+
+    fprintf(stderr, "%s: console_pfn=%"PRI_xen_pfn" xenstore_pfn=%"PRI_xen_pfn"\n",
+            __func__, console_pfn, store_pfn);
+
     return 0;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si6Qh-0002Ci-Re; Fri, 22 Jun 2012 16:09:51 +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 1Si6Qg-0002CB-PY
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:09:50 +0000
Received: from [193.109.254.147:11857] by server-3.bemta-14.messagelabs.com id
	15/39-08687-EC894EF4; Fri, 22 Jun 2012 16:09:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340381387!3962588!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13318 invoked from network); 22 Jun 2012 16:09:49 -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;
	22 Jun 2012 16:09:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199721942"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-NA;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:32 +0100
Message-ID: <1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/5] libxc/arm: allocate xenstore and console
	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

Allocate two additional pages at the end of the guest physical memory
for xenstore and console.
Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
values.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
 1 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index bb86139..df2eefe 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -25,6 +25,10 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
+#define NR_MAGIC_PAGES 2
+#define CONSOLE_PFN_OFFSET 0
+#define XENSTORE_PFN_OFFSET 1
+
 /* ------------------------------------------------------------------------ */
 /*
  * arm guests are hybrid and start off with paging disabled, therefore no
@@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {
     DOMPRINTF_CALLED(dom->xch);
-    /* XXX
-     *   dom->p2m_guest
-     *   dom->start_info_pfn
-     *   dom->xenstore_pfn
-     *   dom->console_pfn
-     */
     return 0;
 }
 
@@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 {
     int rc;
     xen_pfn_t pfn, allocsz, i;
+    xen_pfn_t store_pfn, console_pfn;
 
     fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
             dom->total_pages, dom->rambase_pfn);
 
     dom->shadow_enabled = 1;
 
-    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
 
     fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
             dom->rambase_pfn, dom->total_pages );
     /* setup initial p2m */
-    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
         dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
 
     fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
@@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 
     /* allocate guest memory */
     for ( i = rc = allocsz = 0;
-          (i < dom->total_pages) && !rc;
+          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
           i += allocsz )
     {
-        allocsz = dom->total_pages - i;
+        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
         if ( allocsz > 1024*1024 )
             allocsz = 1024*1024;
         fprintf(stderr, "alloc %"PRI_xen_pfn" at offset %"PRI_xen_pfn" which is %"PRI_xen_pfn"\n",
@@ -168,6 +167,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
     fprintf(stderr, "%s: popl'd p2m_host[%"PRI_xen_pfn"] = %"PRI_xen_pfn"\n",
             __func__, dom->total_pages-1, dom->p2m_host[dom->total_pages-1]);
 
+    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
+    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
+            console_pfn);
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
+            store_pfn);
+
+    fprintf(stderr, "%s: console_pfn=%"PRI_xen_pfn" xenstore_pfn=%"PRI_xen_pfn"\n",
+            __func__, console_pfn, store_pfn);
+
     return 0;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si6Qh-0002Cb-EU; Fri, 22 Jun 2012 16:09:51 +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 1Si6Qg-0002C1-6J
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:09:50 +0000
Received: from [193.109.254.147:39962] by server-7.bemta-14.messagelabs.com id
	A9/B9-29827-DC894EF4; Fri, 22 Jun 2012 16:09:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340381387!3962588!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13295 invoked from network); 22 Jun 2012 16:09:48 -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;
	22 Jun 2012 16:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199721940"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-P3;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:33 +0100
Message-ID: <1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/5] xcbuild: add console and xenstore 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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xcutils/Makefile  |    4 +-
 tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 92c5a68..c88f286 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
 CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
-CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 
 .PHONY: all
 all: build
@@ -35,7 +35,7 @@ xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
 xcbuild: xcbuild.o
-	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
index a70c3ca..7b5c0f8 100644
--- a/tools/xcutils/xcbuild.c
+++ b/tools/xcutils/xcbuild.c
@@ -1,6 +1,7 @@
 #include <unistd.h>
 #include <stdio.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <errno.h>
 
@@ -8,6 +9,7 @@
 //#include <xenguest.h>
 #include <xentoollog.h>
 #include <xc_dom.h>
+#include <xenstore.h>
 
 int main(int argc, char **argv)
 {
@@ -15,11 +17,19 @@ int main(int argc, char **argv)
 	xc_interface *xch;
 	int rv;
 	const char *image;
-	uint32_t domid;
+	uint32_t domid = 1;
 	xen_domain_handle_t handle;
 	int maxmem = 128; /* MB */ //atoi(argv[2]);
 	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
 	struct xc_dom_image *dom;
+	unsigned long console_mfn;
+	unsigned long console_port;
+	unsigned long store_mfn;
+	unsigned long store_port;
+	struct xs_handle *xs;
+	char *dom_path;
+	char path[256];
+	char val[256];
 
 	image = (argc < 2) ? "guest.img" : argv[1];
 	printf("Image: %s\n", image);
@@ -103,6 +113,52 @@ int main(int argc, char **argv)
 	if (rv) return rv;
 	rv = xc_dom_build_image(dom);
 	if (rv) return rv;
+
+	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
+	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
+	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
+
+	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
+	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
+	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
+	xs = xs_daemon_open();
+	if (xs == NULL) {
+		printf("Could not contact XenStore");
+		return errno;
+	}
+	dom_path = xs_get_domain_path(xs, domid);
+
+	snprintf(path, sizeof(path), "%s/console/port", dom_path);
+	snprintf(val, sizeof(val), "%lu", console_port);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
+	snprintf(val, sizeof(val), "%lu", console_mfn);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/type", dom_path);
+	snprintf(val, sizeof(val), "xenconsoled");
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/output", dom_path);
+	snprintf(val, sizeof(val), "pty");
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
+	snprintf(val, sizeof(val), "%d", 1048576);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/store/port", dom_path);
+	snprintf(val, sizeof(val), "%lu", store_port);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
+	snprintf(val, sizeof(val), "%lu", store_mfn);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+	xs_introduce_domain(xs, domid, store_mfn, store_port);
+
+	xs_daemon_close(xs);
+
 	rv = xc_dom_boot_image(dom);
 	if (rv) return rv;
 
-- 
1.7.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 Jun 22 16:10:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si6Qh-0002Cb-EU; Fri, 22 Jun 2012 16:09:51 +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 1Si6Qg-0002C1-6J
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:09:50 +0000
Received: from [193.109.254.147:39962] by server-7.bemta-14.messagelabs.com id
	A9/B9-29827-DC894EF4; Fri, 22 Jun 2012 16:09:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340381387!3962588!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13295 invoked from network); 22 Jun 2012 16:09:48 -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;
	22 Jun 2012 16:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199721940"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-P3;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:33 +0100
Message-ID: <1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/5] xcbuild: add console and xenstore 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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xcutils/Makefile  |    4 +-
 tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 92c5a68..c88f286 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
 CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
-CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 
 .PHONY: all
 all: build
@@ -35,7 +35,7 @@ xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
 xcbuild: xcbuild.o
-	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
index a70c3ca..7b5c0f8 100644
--- a/tools/xcutils/xcbuild.c
+++ b/tools/xcutils/xcbuild.c
@@ -1,6 +1,7 @@
 #include <unistd.h>
 #include <stdio.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <errno.h>
 
@@ -8,6 +9,7 @@
 //#include <xenguest.h>
 #include <xentoollog.h>
 #include <xc_dom.h>
+#include <xenstore.h>
 
 int main(int argc, char **argv)
 {
@@ -15,11 +17,19 @@ int main(int argc, char **argv)
 	xc_interface *xch;
 	int rv;
 	const char *image;
-	uint32_t domid;
+	uint32_t domid = 1;
 	xen_domain_handle_t handle;
 	int maxmem = 128; /* MB */ //atoi(argv[2]);
 	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
 	struct xc_dom_image *dom;
+	unsigned long console_mfn;
+	unsigned long console_port;
+	unsigned long store_mfn;
+	unsigned long store_port;
+	struct xs_handle *xs;
+	char *dom_path;
+	char path[256];
+	char val[256];
 
 	image = (argc < 2) ? "guest.img" : argv[1];
 	printf("Image: %s\n", image);
@@ -103,6 +113,52 @@ int main(int argc, char **argv)
 	if (rv) return rv;
 	rv = xc_dom_build_image(dom);
 	if (rv) return rv;
+
+	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
+	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
+	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
+
+	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
+	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
+	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
+	xs = xs_daemon_open();
+	if (xs == NULL) {
+		printf("Could not contact XenStore");
+		return errno;
+	}
+	dom_path = xs_get_domain_path(xs, domid);
+
+	snprintf(path, sizeof(path), "%s/console/port", dom_path);
+	snprintf(val, sizeof(val), "%lu", console_port);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
+	snprintf(val, sizeof(val), "%lu", console_mfn);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/type", dom_path);
+	snprintf(val, sizeof(val), "xenconsoled");
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/output", dom_path);
+	snprintf(val, sizeof(val), "pty");
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
+	snprintf(val, sizeof(val), "%d", 1048576);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/store/port", dom_path);
+	snprintf(val, sizeof(val), "%lu", store_port);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+
+	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
+	snprintf(val, sizeof(val), "%lu", store_mfn);
+	xs_write(xs, XBT_NULL, path, val, strlen(val));
+	xs_introduce_domain(xs, domid, store_mfn, store_port);
+
+	xs_daemon_close(xs);
+
 	rv = xc_dom_boot_image(dom);
 	if (rv) return rv;
 
-- 
1.7.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 Jun 22 16:10:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6Qg-0002CG-Th; Fri, 22 Jun 2012 16:09:50 +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 1Si6Qf-0002Bx-JT
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:09:49 +0000
Received: from [193.109.254.147:39919] by server-4.bemta-14.messagelabs.com id
	D1/AB-02077-CC894EF4; Fri, 22 Jun 2012 16:09:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340381387!3962588!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13272 invoked from network); 22 Jun 2012 16:09:48 -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;
	22 Jun 2012 16:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199721939"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-LE;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:31 +0100
Message-ID: <1340381373-22177-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/5] xen/arm: disable the event optimization in
	the gic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we have an optimization in the GIC driver that allows us not
to request maintenance interrupts for Xen events. The basic idea is that
every time we are about to inject a new interrupt or event into a guest,
we check whether we can remove some old event irqs from one or more LRs.
We can do this because we know when a guest finishes processing event
notifications: it sets the evtchn_upcall_pending bit to 0.

However it is unsafe: the guest resets evtchn_upcall_pending before
EOI'ing the event irq, therefore a small window of time exists when Xen
could jump in and remove the event irq from the LR register before the
guest has EOI'ed it.

This is not a good practice according to the GIC manual.
Remove the optimization for now.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |   42 ------------------------------------------
 1 files changed, 0 insertions(+), 42 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 8190f84..c6cee4b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -37,7 +37,6 @@
                                      + (GIC_CR_OFFSET & 0xfff)))
 #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
                                      + (GIC_HR_OFFSET & 0xfff)))
-static void events_maintenance(struct vcpu *v);
 static void gic_restore_pending_irqs(struct vcpu *v);
 
 /* Global state */
@@ -48,7 +47,6 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
-    uint64_t event_mask;
     uint64_t lr_mask;
 } gic;
 
@@ -62,7 +60,6 @@ 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 = gic.lr_mask;
-    v->arch.event_mask = gic.event_mask;
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
     isb();
@@ -76,7 +73,6 @@ void gic_restore_state(struct vcpu *v)
         return;
 
     gic.lr_mask = v->arch.lr_mask;
-    gic.event_mask = v->arch.event_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     GICH[GICH_HCR] = GICH_HCR_EN;
@@ -318,7 +314,6 @@ int __init gic_init(void)
     gic_hyp_init();
 
     gic.lr_mask = 0ULL;
-    gic.event_mask = 0ULL;
 
     spin_unlock(&gic.lock);
 
@@ -421,9 +416,6 @@ static inline void gic_set_lr(int lr, unsigned int virtual_irq,
 
     BUG_ON(lr > nr_lrs);
 
-    if (virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK && nr_lrs > 1)
-        maintenance_int = 0;
-
     GICH[GICH_LR + lr] = state |
         maintenance_int |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
@@ -436,11 +428,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
     int i;
     struct pending_irq *iter, *n;
 
-    if ( v->is_running )
-    {
-        events_maintenance(v);
-    }
-
     spin_lock_irq(&gic.lock);
 
     if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
@@ -448,8 +435,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
         i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
         if (i < nr_lrs) {
             set_bit(i, &gic.lr_mask);
-            if ( virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK )
-                set_bit(i, &gic.event_mask);
             gic_set_lr(i, virtual_irq, state, priority);
             goto out;
         }
@@ -494,8 +479,6 @@ static void gic_restore_pending_irqs(struct vcpu *v)
         gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
         list_del_init(&p->lr_queue);
         set_bit(i, &gic.lr_mask);
-        if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
-            set_bit(i, &gic.event_mask);
     }
 
 }
@@ -584,27 +567,6 @@ void gicv_setup(struct domain *d)
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
 
-static void events_maintenance(struct vcpu *v)
-{
-    int i = 0;
-    int already_pending = test_bit(0,
-            (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
-
-    if (!already_pending && gic.event_mask != 0) {
-        spin_lock_irq(&gic.lock);
-        while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
-                        64, i)) < 64) {
-
-            GICH[GICH_LR + i] = 0;
-            clear_bit(i, &gic.lr_mask);
-            clear_bit(i, &gic.event_mask);
-
-            i++;
-        }
-        spin_unlock_irq(&gic.lock);
-    }
-}
-
 static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
     int i = 0, virq;
@@ -612,8 +574,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     struct vcpu *v = current;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    events_maintenance(v);
-
     while ((i = find_next_bit((const long unsigned int *) &eisr,
                               64, i)) < 64) {
         struct pending_irq *p;
@@ -629,8 +589,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
             gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
             list_del_init(&p->lr_queue);
             set_bit(i, &gic.lr_mask);
-            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
-                set_bit(i, &gic.event_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 Fri Jun 22 16:10:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6Qg-0002CG-Th; Fri, 22 Jun 2012 16:09:50 +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 1Si6Qf-0002Bx-JT
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:09:49 +0000
Received: from [193.109.254.147:39919] by server-4.bemta-14.messagelabs.com id
	D1/AB-02077-CC894EF4; Fri, 22 Jun 2012 16:09:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340381387!3962588!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13272 invoked from network); 22 Jun 2012 16:09:48 -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;
	22 Jun 2012 16:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199721939"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-LE;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:31 +0100
Message-ID: <1340381373-22177-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/5] xen/arm: disable the event optimization in
	the gic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently we have an optimization in the GIC driver that allows us not
to request maintenance interrupts for Xen events. The basic idea is that
every time we are about to inject a new interrupt or event into a guest,
we check whether we can remove some old event irqs from one or more LRs.
We can do this because we know when a guest finishes processing event
notifications: it sets the evtchn_upcall_pending bit to 0.

However it is unsafe: the guest resets evtchn_upcall_pending before
EOI'ing the event irq, therefore a small window of time exists when Xen
could jump in and remove the event irq from the LR register before the
guest has EOI'ed it.

This is not a good practice according to the GIC manual.
Remove the optimization for now.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |   42 ------------------------------------------
 1 files changed, 0 insertions(+), 42 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 8190f84..c6cee4b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -37,7 +37,6 @@
                                      + (GIC_CR_OFFSET & 0xfff)))
 #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
                                      + (GIC_HR_OFFSET & 0xfff)))
-static void events_maintenance(struct vcpu *v);
 static void gic_restore_pending_irqs(struct vcpu *v);
 
 /* Global state */
@@ -48,7 +47,6 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
-    uint64_t event_mask;
     uint64_t lr_mask;
 } gic;
 
@@ -62,7 +60,6 @@ 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 = gic.lr_mask;
-    v->arch.event_mask = gic.event_mask;
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
     isb();
@@ -76,7 +73,6 @@ void gic_restore_state(struct vcpu *v)
         return;
 
     gic.lr_mask = v->arch.lr_mask;
-    gic.event_mask = v->arch.event_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     GICH[GICH_HCR] = GICH_HCR_EN;
@@ -318,7 +314,6 @@ int __init gic_init(void)
     gic_hyp_init();
 
     gic.lr_mask = 0ULL;
-    gic.event_mask = 0ULL;
 
     spin_unlock(&gic.lock);
 
@@ -421,9 +416,6 @@ static inline void gic_set_lr(int lr, unsigned int virtual_irq,
 
     BUG_ON(lr > nr_lrs);
 
-    if (virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK && nr_lrs > 1)
-        maintenance_int = 0;
-
     GICH[GICH_LR + lr] = state |
         maintenance_int |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
@@ -436,11 +428,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
     int i;
     struct pending_irq *iter, *n;
 
-    if ( v->is_running )
-    {
-        events_maintenance(v);
-    }
-
     spin_lock_irq(&gic.lock);
 
     if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
@@ -448,8 +435,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
         i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
         if (i < nr_lrs) {
             set_bit(i, &gic.lr_mask);
-            if ( virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK )
-                set_bit(i, &gic.event_mask);
             gic_set_lr(i, virtual_irq, state, priority);
             goto out;
         }
@@ -494,8 +479,6 @@ static void gic_restore_pending_irqs(struct vcpu *v)
         gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
         list_del_init(&p->lr_queue);
         set_bit(i, &gic.lr_mask);
-        if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
-            set_bit(i, &gic.event_mask);
     }
 
 }
@@ -584,27 +567,6 @@ void gicv_setup(struct domain *d)
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
 
-static void events_maintenance(struct vcpu *v)
-{
-    int i = 0;
-    int already_pending = test_bit(0,
-            (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
-
-    if (!already_pending && gic.event_mask != 0) {
-        spin_lock_irq(&gic.lock);
-        while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
-                        64, i)) < 64) {
-
-            GICH[GICH_LR + i] = 0;
-            clear_bit(i, &gic.lr_mask);
-            clear_bit(i, &gic.event_mask);
-
-            i++;
-        }
-        spin_unlock_irq(&gic.lock);
-    }
-}
-
 static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
     int i = 0, virq;
@@ -612,8 +574,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     struct vcpu *v = current;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    events_maintenance(v);
-
     while ((i = find_next_bit((const long unsigned int *) &eisr,
                               64, i)) < 64) {
         struct pending_irq *p;
@@ -629,8 +589,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
             gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
             list_del_init(&p->lr_queue);
             set_bit(i, &gic.lr_mask);
-            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
-                set_bit(i, &gic.event_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 Fri Jun 22 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si6Qz-0002Gz-9F; Fri, 22 Jun 2012 16:10: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 1Si6Qx-0002Ft-6z
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:10:07 +0000
Received: from [85.158.143.35:41843] by server-3.bemta-4.messagelabs.com id
	55/3E-05808-ED894EF4; Fri, 22 Jun 2012 16:10:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340381403!6178953!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16670 invoked from network); 22 Jun 2012 16:10:05 -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;
	22 Jun 2012 16:10:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="29085840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-HD;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:29 +0100
Message-ID: <1340381373-22177-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.1206221634020.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@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 1/5] xen/arm: implement do_hvm_op 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/hvm.c           |   60 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c         |    1 +
 xen/include/asm-arm/domain.h |    7 +++++
 4 files changed, 69 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/hvm.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5a87ba6..634b620 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -26,6 +26,7 @@ obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
 obj-y += vpl011.o
+obj-y += hvm.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
new file mode 100644
index 0000000..c11378d
--- /dev/null
+++ b/xen/arch/arm/hvm.c
@@ -0,0 +1,60 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <xen/sched.h>
+
+#include <public/xen.h>
+#include <public/hvm/params.h>
+#include <public/hvm/hvm_op.h>
+
+#include <asm/hypercall.h>
+
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+
+{
+    long rc = 0;
+
+    switch ( op )
+    {
+    case HVMOP_set_param:
+    case HVMOP_get_param:
+    {
+        struct xen_hvm_param a;
+        struct domain *d;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        if ( a.index >= HVM_NR_PARAMS )
+            return -EINVAL;
+
+        rc = rcu_lock_target_domain_by_id(a.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( op == HVMOP_set_param )
+        {
+            d->arch.hvm_domain.params[a.index] = a.value;
+        }
+        else
+        {
+            a.value = d->arch.hvm_domain.params[a.index];
+            rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
+        }
+
+        rcu_unlock_domain(d);
+        break;
+    }
+
+    default:
+    {
+        printk("%s: Bad HVM op %ld.\n", __func__, op);
+        rc = -ENOSYS;
+        break;
+    }
+    }
+
+    return rc;
+}
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ec74298..3900545 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -430,6 +430,7 @@ static arm_hypercall_t *arm_hypercall_table[] = {
     HYPERCALL(memory_op),
     HYPERCALL(physdev_op),
     HYPERCALL(sysctl),
+    HYPERCALL(hvm_op),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2b14545..114a8f6 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -5,6 +5,7 @@
 #include <xen/cache.h>
 #include <asm/page.h>
 #include <asm/p2m.h>
+#include <public/hvm/params.h>
 
 /* Represents state corresponding to a block of 32 interrupts */
 struct vgic_irq_rank {
@@ -28,9 +29,15 @@ struct pending_irq
     struct list_head lr_queue;
 };
 
+struct hvm_domain
+{
+    uint64_t              params[HVM_NR_PARAMS];
+}  __cacheline_aligned;
+
 struct arch_domain
 {
     struct p2m_domain p2m;
+    struct hvm_domain hvm_domain;
 
     struct {
         /*
-- 
1.7.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 Jun 22 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Si6Qz-0002Gz-9F; Fri, 22 Jun 2012 16:10: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 1Si6Qx-0002Ft-6z
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:10:07 +0000
Received: from [85.158.143.35:41843] by server-3.bemta-4.messagelabs.com id
	55/3E-05808-ED894EF4; Fri, 22 Jun 2012 16:10:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340381403!6178953!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16670 invoked from network); 22 Jun 2012 16:10:05 -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;
	22 Jun 2012 16:10:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="29085840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-HD;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:29 +0100
Message-ID: <1340381373-22177-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.1206221634020.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@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 1/5] xen/arm: implement do_hvm_op 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/hvm.c           |   60 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c         |    1 +
 xen/include/asm-arm/domain.h |    7 +++++
 4 files changed, 69 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/hvm.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5a87ba6..634b620 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -26,6 +26,7 @@ obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
 obj-y += vpl011.o
+obj-y += hvm.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
new file mode 100644
index 0000000..c11378d
--- /dev/null
+++ b/xen/arch/arm/hvm.c
@@ -0,0 +1,60 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <xen/sched.h>
+
+#include <public/xen.h>
+#include <public/hvm/params.h>
+#include <public/hvm/hvm_op.h>
+
+#include <asm/hypercall.h>
+
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+
+{
+    long rc = 0;
+
+    switch ( op )
+    {
+    case HVMOP_set_param:
+    case HVMOP_get_param:
+    {
+        struct xen_hvm_param a;
+        struct domain *d;
+
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        if ( a.index >= HVM_NR_PARAMS )
+            return -EINVAL;
+
+        rc = rcu_lock_target_domain_by_id(a.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( op == HVMOP_set_param )
+        {
+            d->arch.hvm_domain.params[a.index] = a.value;
+        }
+        else
+        {
+            a.value = d->arch.hvm_domain.params[a.index];
+            rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
+        }
+
+        rcu_unlock_domain(d);
+        break;
+    }
+
+    default:
+    {
+        printk("%s: Bad HVM op %ld.\n", __func__, op);
+        rc = -ENOSYS;
+        break;
+    }
+    }
+
+    return rc;
+}
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ec74298..3900545 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -430,6 +430,7 @@ static arm_hypercall_t *arm_hypercall_table[] = {
     HYPERCALL(memory_op),
     HYPERCALL(physdev_op),
     HYPERCALL(sysctl),
+    HYPERCALL(hvm_op),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 2b14545..114a8f6 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -5,6 +5,7 @@
 #include <xen/cache.h>
 #include <asm/page.h>
 #include <asm/p2m.h>
+#include <public/hvm/params.h>
 
 /* Represents state corresponding to a block of 32 interrupts */
 struct vgic_irq_rank {
@@ -28,9 +29,15 @@ struct pending_irq
     struct list_head lr_queue;
 };
 
+struct hvm_domain
+{
+    uint64_t              params[HVM_NR_PARAMS];
+}  __cacheline_aligned;
+
 struct arch_domain
 {
     struct p2m_domain p2m;
+    struct hvm_domain hvm_domain;
 
     struct {
         /*
-- 
1.7.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 Jun 22 16:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6Qz-0002HB-Ne; Fri, 22 Jun 2012 16:10: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 1Si6Qy-0002Gf-Jo
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:10:08 +0000
Received: from [85.158.143.35:62294] by server-1.bemta-4.messagelabs.com id
	D4/52-24392-FD894EF4; Fri, 22 Jun 2012 16:10:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340381403!6178953!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16707 invoked from network); 22 Jun 2012 16:10:06 -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;
	22 Jun 2012 16:10:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="29085841"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-JI;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:30 +0100
Message-ID: <1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/5] xen/arm: gic and vgic 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

- the last argument of find_next_bit is the maximum number of bits, not
the maximum number of bytes;

- use list_for_each_entry_safe instead of list_for_each_entry in
gic_restore_pending_irqs because we are actually deleting entries in the
loop.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c  |    8 ++++----
 xen/arch/arm/vgic.c |    3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 87713c1..8190f84 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -480,13 +480,13 @@ out:
 static void gic_restore_pending_irqs(struct vcpu *v)
 {
     int i;
-    struct pending_irq *p;
+    struct pending_irq *p, *t;
 
     /* check for new pending irqs */
     if ( list_empty(&v->arch.vgic.lr_pending) )
         return;
 
-    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
+    list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
         i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
         if ( i >= nr_lrs ) return;
@@ -593,7 +593,7 @@ static void events_maintenance(struct vcpu *v)
     if (!already_pending && gic.event_mask != 0) {
         spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
-                        sizeof(uint64_t), i)) < sizeof(uint64_t)) {
+                        64, i)) < 64) {
 
             GICH[GICH_LR + i] = 0;
             clear_bit(i, &gic.lr_mask);
@@ -615,7 +615,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     events_maintenance(v);
 
     while ((i = find_next_bit((const long unsigned int *) &eisr,
-                              sizeof(eisr), i)) < sizeof(eisr)) {
+                              64, i)) < 64) {
         struct pending_irq *p;
 
         spin_lock_irq(&gic.lock);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 653e8e5..b383e01 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -355,8 +355,7 @@ static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
     unsigned int irq;
     int i = 0;
 
-    while ( (i = find_next_bit((const long unsigned int *) &r,
-                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
+    while ( (i = find_next_bit((const long unsigned int *) &r, 32, i)) < 32 ) {
         irq = i + (32 * n);
         p = irq_to_pending(v, irq);
         if ( !list_empty(&p->inflight) )
-- 
1.7.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 Jun 22 16:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6Qz-0002HB-Ne; Fri, 22 Jun 2012 16:10: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 1Si6Qy-0002Gf-Jo
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:10:08 +0000
Received: from [85.158.143.35:62294] by server-1.bemta-4.messagelabs.com id
	D4/52-24392-FD894EF4; Fri, 22 Jun 2012 16:10:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340381403!6178953!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16707 invoked from network); 22 Jun 2012 16:10:06 -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;
	22 Jun 2012 16:10:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="29085841"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:09:46 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:09:46 -0400
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 1Si6QW-0008Ds-JI;
	Fri, 22 Jun 2012 17:09:40 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 22 Jun 2012 17:09:30 +0100
Message-ID: <1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/5] xen/arm: gic and vgic 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

- the last argument of find_next_bit is the maximum number of bits, not
the maximum number of bytes;

- use list_for_each_entry_safe instead of list_for_each_entry in
gic_restore_pending_irqs because we are actually deleting entries in the
loop.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c  |    8 ++++----
 xen/arch/arm/vgic.c |    3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 87713c1..8190f84 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -480,13 +480,13 @@ out:
 static void gic_restore_pending_irqs(struct vcpu *v)
 {
     int i;
-    struct pending_irq *p;
+    struct pending_irq *p, *t;
 
     /* check for new pending irqs */
     if ( list_empty(&v->arch.vgic.lr_pending) )
         return;
 
-    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
+    list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
         i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
         if ( i >= nr_lrs ) return;
@@ -593,7 +593,7 @@ static void events_maintenance(struct vcpu *v)
     if (!already_pending && gic.event_mask != 0) {
         spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
-                        sizeof(uint64_t), i)) < sizeof(uint64_t)) {
+                        64, i)) < 64) {
 
             GICH[GICH_LR + i] = 0;
             clear_bit(i, &gic.lr_mask);
@@ -615,7 +615,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     events_maintenance(v);
 
     while ((i = find_next_bit((const long unsigned int *) &eisr,
-                              sizeof(eisr), i)) < sizeof(eisr)) {
+                              64, i)) < 64) {
         struct pending_irq *p;
 
         spin_lock_irq(&gic.lock);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 653e8e5..b383e01 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -355,8 +355,7 @@ static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
     unsigned int irq;
     int i = 0;
 
-    while ( (i = find_next_bit((const long unsigned int *) &r,
-                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
+    while ( (i = find_next_bit((const long unsigned int *) &r, 32, i)) < 32 ) {
         irq = i + (32 * n);
         p = irq_to_pending(v, irq);
         if ( !list_empty(&p->inflight) )
-- 
1.7.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 Jun 22 16:13:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si6UL-0002vb-Ci; Fri, 22 Jun 2012 16:13:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6UJ-0002vG-KQ
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:13:35 +0000
Received: from [85.158.139.83:49695] by server-6.bemta-5.messagelabs.com id
	8E/F0-11348-EA994EF4; Fri, 22 Jun 2012 16:13:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340381614!28945563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10167 invoked from network); 22 Jun 2012 16:13:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:13:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13174817"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:13:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 17:13:34 +0100
Date: Fri, 22 Jun 2012 17:13:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <linux-kernel@vger.kernel.org>
Message-ID: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 0/6] xen/arm: PV console 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

Hi all,
this patch series fixes few Xen on ARM bugs as well as one generic Xen PV
on HVM bug (I'll send out that patch separately).
It also implements a better way to initialize Xen on ARM and find out
whether we are a privileged or an unprivileged guest.

With this patch series applied to Linux and the corresponding Xen patch series
applied to Xen, I can boot a Linux guest up to userspace and connect to
it using a PV console in dom0.

The patch series is based on Ian's Linux for Xen on ARM tree
(git://xenbits.xen.org/people/ianc/linux-2.6.git devel/arm-hacks).


Stefano Stabellini (6):
      xen/arm: fix the shared_info and vcpu_info structs
      xen/arm: Introduce xen_guest_init
      xen/arm: get privilege status
      xen/arm: implement hvm_op
      xen: fix unmask_evtchn for HVM guests
      xen/arm: enable evtchn irqs

 arch/arm/include/asm/xen/hypercall.h |    2 +-
 arch/arm/include/asm/xen/interface.h |   15 +++------------
 arch/arm/xen/enlighten.c             |   21 ++++++++++++++++-----
 arch/x86/xen/enlighten.c             |    8 ++++++++
 drivers/tty/hvc/hvc_xen.c            |    3 +++
 drivers/xen/events.c                 |   10 ++++++++--
 include/xen/interface/features.h     |    3 +++
 include/xen/xen.h                    |    2 ++
 8 files changed, 44 insertions(+), 20 deletions(-)

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git xenarmv7-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:13:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si6UL-0002vb-Ci; Fri, 22 Jun 2012 16:13:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6UJ-0002vG-KQ
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:13:35 +0000
Received: from [85.158.139.83:49695] by server-6.bemta-5.messagelabs.com id
	8E/F0-11348-EA994EF4; Fri, 22 Jun 2012 16:13:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340381614!28945563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10167 invoked from network); 22 Jun 2012 16:13:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:13:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13174817"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:13:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 17:13:34 +0100
Date: Fri, 22 Jun 2012 17:13:12 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <linux-kernel@vger.kernel.org>
Message-ID: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 0/6] xen/arm: PV console 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

Hi all,
this patch series fixes few Xen on ARM bugs as well as one generic Xen PV
on HVM bug (I'll send out that patch separately).
It also implements a better way to initialize Xen on ARM and find out
whether we are a privileged or an unprivileged guest.

With this patch series applied to Linux and the corresponding Xen patch series
applied to Xen, I can boot a Linux guest up to userspace and connect to
it using a PV console in dom0.

The patch series is based on Ian's Linux for Xen on ARM tree
(git://xenbits.xen.org/people/ianc/linux-2.6.git devel/arm-hacks).


Stefano Stabellini (6):
      xen/arm: fix the shared_info and vcpu_info structs
      xen/arm: Introduce xen_guest_init
      xen/arm: get privilege status
      xen/arm: implement hvm_op
      xen: fix unmask_evtchn for HVM guests
      xen/arm: enable evtchn irqs

 arch/arm/include/asm/xen/hypercall.h |    2 +-
 arch/arm/include/asm/xen/interface.h |   15 +++------------
 arch/arm/xen/enlighten.c             |   21 ++++++++++++++++-----
 arch/x86/xen/enlighten.c             |    8 ++++++++
 drivers/tty/hvc/hvc_xen.c            |    3 +++
 drivers/xen/events.c                 |   10 ++++++++--
 include/xen/interface/features.h     |    3 +++
 include/xen/xen.h                    |    2 ++
 8 files changed, 44 insertions(+), 20 deletions(-)

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git xenarmv7-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vr-000346-SE; Fri, 22 Jun 2012 16:15: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 1Si6Vp-00033m-OI
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:10 +0000
Received: from [85.158.139.83:2315] by server-12.bemta-5.messagelabs.com id
	6F/05-25233-D0A94EF4; Fri, 22 Jun 2012 16:15:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340381705!23899494!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10416 invoked from network); 22 Jun 2012 16:15:08 -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;
	22 Jun 2012 16:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722605"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-8H;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:40 +0100
Message-ID: <1340381685-22529-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.1206221644370.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 1/6] xen/arm: fix the shared_info and
	vcpu_info structs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix the shared_info and vcpu_info struct definitions to match the ones
in Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h |   15 +++------------
 1 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 3ad2d4b..8ab7cebb 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -40,19 +40,10 @@ DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
-#define MAX_VIRT_CPUS 32
+#define MAX_VIRT_CPUS 1
 
-struct arch_vcpu_info {
-    unsigned long cr2;
-    unsigned long pad; /* sizeof(vcpu_info_t) == 64 */
-};
-
-struct arch_shared_info {
-    unsigned long max_pfn;                  /* max pfn that appears in table */
-    /* Frame containing list of mfns containing list of mfns containing p2m. */
-    unsigned long pfn_to_mfn_frame_list_list;
-    unsigned long nmi_reason;
-};
+struct arch_vcpu_info { };
+struct arch_shared_info { };
 
 /* XXX: Move pvclock definitions some place arch independent */
 struct pvclock_vcpu_time_info {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vr-000346-SE; Fri, 22 Jun 2012 16:15: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 1Si6Vp-00033m-OI
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:10 +0000
Received: from [85.158.139.83:2315] by server-12.bemta-5.messagelabs.com id
	6F/05-25233-D0A94EF4; Fri, 22 Jun 2012 16:15:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340381705!23899494!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10416 invoked from network); 22 Jun 2012 16:15:08 -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;
	22 Jun 2012 16:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722605"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-8H;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:40 +0100
Message-ID: <1340381685-22529-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.1206221644370.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 1/6] xen/arm: fix the shared_info and
	vcpu_info structs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix the shared_info and vcpu_info struct definitions to match the ones
in Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h |   15 +++------------
 1 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 3ad2d4b..8ab7cebb 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -40,19 +40,10 @@ DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
-#define MAX_VIRT_CPUS 32
+#define MAX_VIRT_CPUS 1
 
-struct arch_vcpu_info {
-    unsigned long cr2;
-    unsigned long pad; /* sizeof(vcpu_info_t) == 64 */
-};
-
-struct arch_shared_info {
-    unsigned long max_pfn;                  /* max pfn that appears in table */
-    /* Frame containing list of mfns containing list of mfns containing p2m. */
-    unsigned long pfn_to_mfn_frame_list_list;
-    unsigned long nmi_reason;
-};
+struct arch_vcpu_info { };
+struct arch_shared_info { };
 
 /* XXX: Move pvclock definitions some place arch independent */
 struct pvclock_vcpu_time_info {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vt-00035D-Jd; Fri, 22 Jun 2012 16:15:13 +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 1Si6Vs-00034F-K4
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:12 +0000
Received: from [85.158.143.99:42610] by server-2.bemta-4.messagelabs.com id
	38/3D-17938-F0A94EF4; Fri, 22 Jun 2012 16:15:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340381707!17073259!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7160 invoked from network); 22 Jun 2012 16:15:10 -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;
	22 Jun 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722625"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-Bw;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:43 +0100
Message-ID: <1340381685-22529-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 4/6] xen/arm: implement hvm_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 arch/arm/include/asm/xen/hypercall.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 2fe7434..7503256 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -189,7 +189,7 @@ HYPERVISOR_event_channel_op(int cmd, void *arg)
 
 static inline unsigned long HYPERVISOR_hvm_op(int op, void *arg)
 {
-	return -ENOSYS;
+	return _hypercall2(int, HYPERCALL(hvm_op), op, arg);
 }
 
 	static inline int
-- 
1.7.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 Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vt-00035D-Jd; Fri, 22 Jun 2012 16:15:13 +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 1Si6Vs-00034F-K4
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:12 +0000
Received: from [85.158.143.99:42610] by server-2.bemta-4.messagelabs.com id
	38/3D-17938-F0A94EF4; Fri, 22 Jun 2012 16:15:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340381707!17073259!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7160 invoked from network); 22 Jun 2012 16:15:10 -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;
	22 Jun 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722625"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-Bw;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:43 +0100
Message-ID: <1340381685-22529-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 4/6] xen/arm: implement hvm_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 arch/arm/include/asm/xen/hypercall.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 2fe7434..7503256 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -189,7 +189,7 @@ HYPERVISOR_event_channel_op(int cmd, void *arg)
 
 static inline unsigned long HYPERVISOR_hvm_op(int op, void *arg)
 {
-	return -ENOSYS;
+	return _hypercall2(int, HYPERCALL(hvm_op), op, arg);
 }
 
 	static inline int
-- 
1.7.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 Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vt-00034y-6o; Fri, 22 Jun 2012 16:15:13 +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 1Si6Vr-00033w-N5
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:11 +0000
Received: from [85.158.139.83:2443] by server-9.bemta-5.messagelabs.com id
	13/48-01069-E0A94EF4; Fri, 22 Jun 2012 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340381705!23899494!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10830 invoked from network); 22 Jun 2012 16:15:10 -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;
	22 Jun 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722624"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-EM;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:45 +0100
Message-ID: <1340381685-22529-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 6/6] xen/arm: enable evtchn irqs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 irqs are not enabled by default:

- call enable_percpu_irq for IRQ_EVTCHN_CALLBACK;

- set the IRQF_VALID flag for the other irqs bound to evtchns. It causes
IRQ_NOAUTOEN to be set and as a consequence irq_unmask is going to be
called when a xenbus driver calls request_irq.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0132505..ca92755 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -53,6 +53,7 @@
 #include <xen/interface/hvm/params.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/sched.h>
+#include <asm/hw_irq.h>
 
 /*
  * This lock protects updates to the following mapping and reference-count
@@ -827,6 +828,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 
 		xen_irq_info_evtchn_init(irq, evtchn);
 	}
+	set_irq_flags(irq, IRQF_VALID);
 
 out:
 	mutex_unlock(&irq_mapping_update_lock);
@@ -1751,6 +1753,7 @@ int __init xen_init_IRQ_arm(void)
 	if (rc) {
 		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
 	}
+	enable_percpu_irq(IRQ_EVTCHN_CALLBACK, 0);
 	return rc;
 }
 core_initcall(xen_init_IRQ_arm);
-- 
1.7.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 Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vt-00034y-6o; Fri, 22 Jun 2012 16:15:13 +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 1Si6Vr-00033w-N5
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:11 +0000
Received: from [85.158.139.83:2443] by server-9.bemta-5.messagelabs.com id
	13/48-01069-E0A94EF4; Fri, 22 Jun 2012 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340381705!23899494!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10830 invoked from network); 22 Jun 2012 16:15:10 -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;
	22 Jun 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722624"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-EM;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:45 +0100
Message-ID: <1340381685-22529-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 6/6] xen/arm: enable evtchn irqs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 irqs are not enabled by default:

- call enable_percpu_irq for IRQ_EVTCHN_CALLBACK;

- set the IRQF_VALID flag for the other irqs bound to evtchns. It causes
IRQ_NOAUTOEN to be set and as a consequence irq_unmask is going to be
called when a xenbus driver calls request_irq.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0132505..ca92755 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -53,6 +53,7 @@
 #include <xen/interface/hvm/params.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/sched.h>
+#include <asm/hw_irq.h>
 
 /*
  * This lock protects updates to the following mapping and reference-count
@@ -827,6 +828,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 
 		xen_irq_info_evtchn_init(irq, evtchn);
 	}
+	set_irq_flags(irq, IRQF_VALID);
 
 out:
 	mutex_unlock(&irq_mapping_update_lock);
@@ -1751,6 +1753,7 @@ int __init xen_init_IRQ_arm(void)
 	if (rc) {
 		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
 	}
+	enable_percpu_irq(IRQ_EVTCHN_CALLBACK, 0);
 	return rc;
 }
 core_initcall(xen_init_IRQ_arm);
-- 
1.7.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 Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vs-00034i-Qo; Fri, 22 Jun 2012 16:15:12 +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 1Si6Vr-00033s-9G
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:11 +0000
Received: from [85.158.139.83:2390] by server-10.bemta-5.messagelabs.com id
	21/29-02190-E0A94EF4; Fri, 22 Jun 2012 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340381705!23899494!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10487 invoked from network); 22 Jun 2012 16:15:09 -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;
	22 Jun 2012 16:15:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722616"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-Do;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:44 +0100
Message-ID: <1340381685-22529-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 5/6] xen: fix unmask_evtchn for HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When unmask_evtchn is called, if we already have an event pending, we
just set evtchn_pending_sel waiting for irq to be re-enabled. That is
because x86 pv guests overwrite the irq_enable pvops with
xen_irq_enable_direct that also handles pending events.

However x86 HVM guests and ARM guests do not change or do not have the
irq_enable pvop, so this scheme doesn't work properly for them.
Considering that having a pending irq when unmask_evtchn is called is
not very common, and it is better to keep the native_irq_enable
implementation for HVM guests and ARM guests, the best thing to do is
just using the EVTCHNOP_unmask callback (Xen re-injects pending
events in response).

Considering that this patch fixes a bug on x86 for current PV on HVM
guests, I'll resend it separately.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index eae0d0b..0132505 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -372,8 +372,11 @@ static void unmask_evtchn(int port)
 
 	BUG_ON(!irqs_disabled());
 
-	/* Slow path (hypercall) if this is a non-local port. */
-	if (unlikely(cpu != cpu_from_evtchn(port))) {
+	/* Slow path (hypercall) if this is a non-local port or if this is
+	 * an hvm domain and an event is pending (hvm domains don't have
+	 * their own implementation of irq_enable). */
+	if (unlikely((cpu != cpu_from_evtchn(port)) ||
+			(xen_hvm_domain() && sync_test_bit(port, &s->evtchn_pending[0])))) {
 		struct evtchn_unmask unmask = { .port = port };
 		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
 	} 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 Fri Jun 22 16:15:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vs-00034i-Qo; Fri, 22 Jun 2012 16:15:12 +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 1Si6Vr-00033s-9G
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:11 +0000
Received: from [85.158.139.83:2390] by server-10.bemta-5.messagelabs.com id
	21/29-02190-E0A94EF4; Fri, 22 Jun 2012 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340381705!23899494!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10487 invoked from network); 22 Jun 2012 16:15:09 -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;
	22 Jun 2012 16:15:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722616"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-Do;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:44 +0100
Message-ID: <1340381685-22529-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 5/6] xen: fix unmask_evtchn for HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When unmask_evtchn is called, if we already have an event pending, we
just set evtchn_pending_sel waiting for irq to be re-enabled. That is
because x86 pv guests overwrite the irq_enable pvops with
xen_irq_enable_direct that also handles pending events.

However x86 HVM guests and ARM guests do not change or do not have the
irq_enable pvop, so this scheme doesn't work properly for them.
Considering that having a pending irq when unmask_evtchn is called is
not very common, and it is better to keep the native_irq_enable
implementation for HVM guests and ARM guests, the best thing to do is
just using the EVTCHNOP_unmask callback (Xen re-injects pending
events in response).

Considering that this patch fixes a bug on x86 for current PV on HVM
guests, I'll resend it separately.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index eae0d0b..0132505 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -372,8 +372,11 @@ static void unmask_evtchn(int port)
 
 	BUG_ON(!irqs_disabled());
 
-	/* Slow path (hypercall) if this is a non-local port. */
-	if (unlikely(cpu != cpu_from_evtchn(port))) {
+	/* Slow path (hypercall) if this is a non-local port or if this is
+	 * an hvm domain and an event is pending (hvm domains don't have
+	 * their own implementation of irq_enable). */
+	if (unlikely((cpu != cpu_from_evtchn(port)) ||
+			(xen_hvm_domain() && sync_test_bit(port, &s->evtchn_pending[0])))) {
 		struct evtchn_unmask unmask = { .port = port };
 		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
 	} 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 Fri Jun 22 16:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vs-00034V-Du; Fri, 22 Jun 2012 16:15: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 1Si6Vr-00033u-7M
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:11 +0000
Received: from [85.158.143.99:42509] by server-1.bemta-4.messagelabs.com id
	71/D7-24392-E0A94EF4; Fri, 22 Jun 2012 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340381707!17073259!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7089 invoked from network); 22 Jun 2012 16:15:09 -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;
	22 Jun 2012 16:15:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722609"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-Ao;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:42 +0100
Message-ID: <1340381685-22529-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 3/6] xen/arm: get privilege status
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 features to figure out if we are privileged.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c         |    9 ++++++++-
 include/xen/interface/features.h |    3 +++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index e1c2e4d..ddacecf 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -3,6 +3,7 @@
 #include <xen/interface/memory.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
+#include <xen/features.h>
 
 #include <linux/module.h>
 
@@ -11,7 +12,7 @@
 
 #include <asm/pgtable.h>
 
-struct start_info _xen_start_info = { .flags = (SIF_INITDOMAIN|SIF_PRIVILEGED) };
+struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
 
@@ -133,6 +134,12 @@ static void __init xen_hvm_init_shared_info(void)
 	struct xen_add_to_physmap xatp;
 	static struct shared_info *shared_info_page = 0;
 
+	xen_setup_features();
+	if (xen_feature(XENFEAT_dom0))
+		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
+	else
+		xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+
 	/* already setup */
 	if (shared_info_page != 0 && HYPERVISOR_shared_info == shared_info_page)
 		return;
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index b6ca39a..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -50,6 +50,9 @@
 /* x86: pirq can be used by HVM guests */
 #define XENFEAT_hvm_pirqs           10
 
+/* operation as Dom0 is supported */
+#define XENFEAT_dom0                      11
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_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 Jun 22 16:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vs-00034V-Du; Fri, 22 Jun 2012 16:15: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 1Si6Vr-00033u-7M
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:11 +0000
Received: from [85.158.143.99:42509] by server-1.bemta-4.messagelabs.com id
	71/D7-24392-E0A94EF4; Fri, 22 Jun 2012 16:15:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340381707!17073259!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7089 invoked from network); 22 Jun 2012 16:15:09 -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;
	22 Jun 2012 16:15:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722609"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-Ao;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:42 +0100
Message-ID: <1340381685-22529-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 3/6] xen/arm: get privilege status
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 features to figure out if we are privileged.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c         |    9 ++++++++-
 include/xen/interface/features.h |    3 +++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index e1c2e4d..ddacecf 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -3,6 +3,7 @@
 #include <xen/interface/memory.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
+#include <xen/features.h>
 
 #include <linux/module.h>
 
@@ -11,7 +12,7 @@
 
 #include <asm/pgtable.h>
 
-struct start_info _xen_start_info = { .flags = (SIF_INITDOMAIN|SIF_PRIVILEGED) };
+struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
 
@@ -133,6 +134,12 @@ static void __init xen_hvm_init_shared_info(void)
 	struct xen_add_to_physmap xatp;
 	static struct shared_info *shared_info_page = 0;
 
+	xen_setup_features();
+	if (xen_feature(XENFEAT_dom0))
+		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
+	else
+		xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+
 	/* already setup */
 	if (shared_info_page != 0 && HYPERVISOR_shared_info == shared_info_page)
 		return;
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index b6ca39a..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -50,6 +50,9 @@
 /* x86: pirq can be used by HVM guests */
 #define XENFEAT_hvm_pirqs           10
 
+/* operation as Dom0 is supported */
+#define XENFEAT_dom0                      11
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_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 Jun 22 16:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vx-00036M-0C; Fri, 22 Jun 2012 16:15:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6Vw-00035p-1b
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:16 +0000
Received: from [193.109.254.147:26289] by server-12.bemta-14.messagelabs.com
	id F8/98-30461-21A94EF4; Fri, 22 Jun 2012 16:15:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340381708!11108855!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14928 invoked from network); 22 Jun 2012 16:15:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722628"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-90;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:41 +0100
Message-ID: <1340381685-22529-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 2/6] xen/arm: Introduce xen_guest_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We used to rely on a core_initcall to initialize Xen on ARM, however
core_initcalls are actually called after early consoles are initialized.
That means that hvc_xen.c is going to be initialized before Xen.

Given the lack of a better alternative, just call a new Xen
initialization function (xen_guest_init) from xen_cons_init.

xen_guest_init has to be arch independant, so write both an ARM and an
x86 implementation. The x86 implementation is currently empty because we
can be sure that xen_hvm_guest_init is called early enough.

Probably we can get rid of this as soon as we have better DT support.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c  |   12 ++++++++----
 arch/x86/xen/enlighten.c  |    8 ++++++++
 drivers/tty/hvc/hvc_xen.c |    3 +++
 include/xen/xen.h         |    2 ++
 4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 7d76962..e1c2e4d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -127,12 +127,16 @@ out:
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
-void __ref xen_hvm_init_shared_info(void)
+static void __init xen_hvm_init_shared_info(void)
 {
 	int cpu;
 	struct xen_add_to_physmap xatp;
 	static struct shared_info *shared_info_page = 0;
 
+	/* already setup */
+	if (shared_info_page != 0 && HYPERVISOR_shared_info == shared_info_page)
+		return;
+
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
 			get_zeroed_page(GFP_KERNEL);
@@ -161,11 +165,11 @@ void __ref xen_hvm_init_shared_info(void)
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 	}
 }
+core_initcall(xen_hvm_init_shared_info);
 
-static int __init xen_hvm_guest_init(void)
+int __init xen_guest_init(void)
 {
 	xen_hvm_init_shared_info();
 	return 0;
 }
-
-core_initcall(xen_hvm_guest_init);
+EXPORT_SYMBOL(xen_guest_init);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1f92865..0bad7b5 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1420,4 +1420,12 @@ const struct hypervisor_x86 x86_hyper_xen_hvm __refconst = {
 	.init_platform		= xen_hvm_guest_init,
 };
 EXPORT_SYMBOL(x86_hyper_xen_hvm);
+
+int __init xen_guest_init(void)
+{
+	/* do nothing: rely on x86_hyper_xen_hvm for the initialization */
+	return 0;
+	
+}
+EXPORT_SYMBOL(xen_guest_init);
 #endif
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 3ae96a9..52a98ff 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -578,6 +578,9 @@ static int xen_cons_init(void)
 	if (!xen_domain())
 		return 0;
 
+	/* retrieve xen infos  */
+	xen_guest_init();
+
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 2c0d3a5..792a4d2 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -9,8 +9,10 @@ enum xen_domain_type {
 
 #ifdef CONFIG_XEN
 extern enum xen_domain_type xen_domain_type;
+int xen_guest_init(void);
 #else
 #define xen_domain_type		XEN_NATIVE
+static inline int xen_guest_init(void) { return 0; }
 #endif
 
 #define xen_domain()		(xen_domain_type != XEN_NATIVE)
-- 
1.7.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 Jun 22 16:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:15: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 1Si6Vx-00036M-0C; Fri, 22 Jun 2012 16:15:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6Vw-00035p-1b
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:15:16 +0000
Received: from [193.109.254.147:26289] by server-12.bemta-14.messagelabs.com
	id F8/98-30461-21A94EF4; Fri, 22 Jun 2012 16:15:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340381708!11108855!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjE0ODQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14928 invoked from network); 22 Jun 2012 16:15:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="199722628"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 12:15:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 12:14:58 -0400
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 1Si6VZ-0008Lz-90;
	Fri, 22 Jun 2012 17:14:53 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 22 Jun 2012 17:14:41 +0100
Message-ID: <1340381685-22529-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH WIP 2/6] xen/arm: Introduce xen_guest_init
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We used to rely on a core_initcall to initialize Xen on ARM, however
core_initcalls are actually called after early consoles are initialized.
That means that hvc_xen.c is going to be initialized before Xen.

Given the lack of a better alternative, just call a new Xen
initialization function (xen_guest_init) from xen_cons_init.

xen_guest_init has to be arch independant, so write both an ARM and an
x86 implementation. The x86 implementation is currently empty because we
can be sure that xen_hvm_guest_init is called early enough.

Probably we can get rid of this as soon as we have better DT support.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c  |   12 ++++++++----
 arch/x86/xen/enlighten.c  |    8 ++++++++
 drivers/tty/hvc/hvc_xen.c |    3 +++
 include/xen/xen.h         |    2 ++
 4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 7d76962..e1c2e4d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -127,12 +127,16 @@ out:
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
-void __ref xen_hvm_init_shared_info(void)
+static void __init xen_hvm_init_shared_info(void)
 {
 	int cpu;
 	struct xen_add_to_physmap xatp;
 	static struct shared_info *shared_info_page = 0;
 
+	/* already setup */
+	if (shared_info_page != 0 && HYPERVISOR_shared_info == shared_info_page)
+		return;
+
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
 			get_zeroed_page(GFP_KERNEL);
@@ -161,11 +165,11 @@ void __ref xen_hvm_init_shared_info(void)
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 	}
 }
+core_initcall(xen_hvm_init_shared_info);
 
-static int __init xen_hvm_guest_init(void)
+int __init xen_guest_init(void)
 {
 	xen_hvm_init_shared_info();
 	return 0;
 }
-
-core_initcall(xen_hvm_guest_init);
+EXPORT_SYMBOL(xen_guest_init);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1f92865..0bad7b5 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1420,4 +1420,12 @@ const struct hypervisor_x86 x86_hyper_xen_hvm __refconst = {
 	.init_platform		= xen_hvm_guest_init,
 };
 EXPORT_SYMBOL(x86_hyper_xen_hvm);
+
+int __init xen_guest_init(void)
+{
+	/* do nothing: rely on x86_hyper_xen_hvm for the initialization */
+	return 0;
+	
+}
+EXPORT_SYMBOL(xen_guest_init);
 #endif
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 3ae96a9..52a98ff 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -578,6 +578,9 @@ static int xen_cons_init(void)
 	if (!xen_domain())
 		return 0;
 
+	/* retrieve xen infos  */
+	xen_guest_init();
+
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 2c0d3a5..792a4d2 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -9,8 +9,10 @@ enum xen_domain_type {
 
 #ifdef CONFIG_XEN
 extern enum xen_domain_type xen_domain_type;
+int xen_guest_init(void);
 #else
 #define xen_domain_type		XEN_NATIVE
+static inline int xen_guest_init(void) { return 0; }
 #endif
 
 #define xen_domain()		(xen_domain_type != XEN_NATIVE)
-- 
1.7.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 Jun 22 16:17:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:17: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 1Si6Xp-0003n8-73; Fri, 22 Jun 2012 16:17:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Si6Xn-0003mR-PR
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 16:17:12 +0000
Received: from [85.158.143.35:18481] by server-3.bemta-4.messagelabs.com id
	D1/35-05808-78A94EF4; Fri, 22 Jun 2012 16:17:11 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340381824!17606208!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24078 invoked from network); 22 Jun 2012 16:17:05 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:17:05 -0000
Received: by wibhm6 with SMTP id hm6so92219wib.14
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 09:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=TPiEzSnH2nVCymw4ZPQbo6JJUlvvbWZo51gGPyhBhCQ=;
	b=l4+Yck4sfHfdKiUkNslhPdZdTp4Cd38FCV24oSIy+Ndfa6Rp6PT0HxpwiuV1SNYWYg
	lHEzRdF6cwRA/7CPWqRYpiViawJgmizzzMO1h0NVuNgx0iMDnsMAIeNPwbaYKaiDsDX2
	0OubSj6Bd4oFH2utKa2rgbNAZGBkH6kZReuL0JHyPlqCrSNfZFD1NhSto7vrot2gulJ+
	XTBKMnXhcYRVQquHzUK0OMTi1uT0WbXIcVEET8GPmkpe1fIqjMkYoysCr/qL6CtrHlst
	ANbhkI3Y9UE/Bg4PofT4UCe04d8ZLvFBUeKX7vCd4NKu7pzDtP4WDyzrMIfbEWBriJxt
	Z6bw==
Received: by 10.216.142.167 with SMTP id i39mr1381505wej.94.1340381824653;
	Fri, 22 Jun 2012 09:17:04 -0700 (PDT)
Received: from [127.0.1.1] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id eb8sm52863058wib.11.2012.06.22.09.17.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 22 Jun 2012 09:17:03 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f5f29d8e2ccf642cad89e31afda11de03cd1125e
Message-Id: <f5f29d8e2ccf642cad89.1340381818@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 22 Jun 2012 18:16:58 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix validation of scheduling parameters
	for sedf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2205914617cb does its job in correcting the "wrong domain being
considered" issue introduced by 9d1fd58ff602. Unfortunately, when
dealing (again!) with the sedf scheduler, it is required for the
vCPUs of a domain to have been allocated and setup already (in
the hypervisor), when the first call to libxl_domain_sched_params_get()
happens, and that is not true.

This fixes that by avoiding calling that function at all, as we
only need to know which scheduler the domain is running under,
and that is provided by libxl__domain_scheduler() which is safe
to be called there.

While at it, also improve a bit the comments about the whole
sedf parameter validation and mangling process.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -80,36 +80,48 @@ static int sched_params_valid(libxl__gc 
     int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
     int has_extratime =
                 scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
-    libxl_domain_sched_params sci;
-
-    libxl_domain_sched_params_get(CTX, domid, &sci);
 
     /* The sedf scheduler needs some more consistency checking */
-    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+    if (libxl__domain_scheduler(gc, domid) == LIBXL_SCHEDULER_SEDF) {
         if (has_weight && (has_period || has_slice))
             return 0;
+        /* If you want a real-time domain, with its own period and
+         * slice, please, do provide both! */
         if (has_period != has_slice)
             return 0;
 
         /*
          * Idea is, if we specify a weight, then both period and
-         * slice has to be zero. OTOH, if we do not specify a weight,
-         * that means we want a pure best effort domain or an actual
-         * real-time one. In the former case, it is period that needs
-         * to be zero, in the latter, weight should be.
+         * slice has to be zero. OTOH, if we do specify a period and
+         * slice, it is weight that should be zeroed. See
+         * docs/misc/sedf_scheduler_mini-HOWTO.txt for more details
+         * on the meaningful combinations and their meanings.
          */
         if (has_weight) {
             scp->slice = 0;
             scp->period = 0;
         }
         else if (!has_period) {
+            /* No weight nor slice/period means best effort. Parameters needs
+             * some mangling in order to properly ask for that, though. */
+
+            /*
+             * Providing no weight does not make any sense if we do not allow
+             * the domain to run in extra time. On the other hand, if we have
+             * extra time, weight will be ignored (and zeroed) by Xen, but it
+             * can't be zero here, or the call for setting the scheduling
+             * parameters will fail. So, avoid the latter by setting a random
+             * weight (namely, 1), as it will be ignored anyway.
+             */
+
             /* We can setup a proper best effort domain (extra time only)
              * iff we either already have or are asking for some extra time. */
-            scp->weight = has_extratime ? scp->extratime : sci.extratime;
+            scp->weight = has_extratime ? scp->extratime : 1;
             scp->period = 0;
+        } else {
+            /* Real-time domain: will get slice CPU time over every period */
+            scp->weight = 0;
         }
-        if (has_period && has_slice)
-            scp->weight = 0;
     }
 
     return 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:17:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:17: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 1Si6Xp-0003n8-73; Fri, 22 Jun 2012 16:17:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Si6Xn-0003mR-PR
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 16:17:12 +0000
Received: from [85.158.143.35:18481] by server-3.bemta-4.messagelabs.com id
	D1/35-05808-78A94EF4; Fri, 22 Jun 2012 16:17:11 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340381824!17606208!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24078 invoked from network); 22 Jun 2012 16:17:05 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:17:05 -0000
Received: by wibhm6 with SMTP id hm6so92219wib.14
	for <xen-devel@lists.xen.org>; Fri, 22 Jun 2012 09:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=TPiEzSnH2nVCymw4ZPQbo6JJUlvvbWZo51gGPyhBhCQ=;
	b=l4+Yck4sfHfdKiUkNslhPdZdTp4Cd38FCV24oSIy+Ndfa6Rp6PT0HxpwiuV1SNYWYg
	lHEzRdF6cwRA/7CPWqRYpiViawJgmizzzMO1h0NVuNgx0iMDnsMAIeNPwbaYKaiDsDX2
	0OubSj6Bd4oFH2utKa2rgbNAZGBkH6kZReuL0JHyPlqCrSNfZFD1NhSto7vrot2gulJ+
	XTBKMnXhcYRVQquHzUK0OMTi1uT0WbXIcVEET8GPmkpe1fIqjMkYoysCr/qL6CtrHlst
	ANbhkI3Y9UE/Bg4PofT4UCe04d8ZLvFBUeKX7vCd4NKu7pzDtP4WDyzrMIfbEWBriJxt
	Z6bw==
Received: by 10.216.142.167 with SMTP id i39mr1381505wej.94.1340381824653;
	Fri, 22 Jun 2012 09:17:04 -0700 (PDT)
Received: from [127.0.1.1] (ip-181-222.sn1.eutelia.it. [62.94.181.222])
	by mx.google.com with ESMTPS id eb8sm52863058wib.11.2012.06.22.09.17.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 22 Jun 2012 09:17:03 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f5f29d8e2ccf642cad89e31afda11de03cd1125e
Message-Id: <f5f29d8e2ccf642cad89.1340381818@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 22 Jun 2012 18:16:58 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix validation of scheduling parameters
	for sedf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2205914617cb does its job in correcting the "wrong domain being
considered" issue introduced by 9d1fd58ff602. Unfortunately, when
dealing (again!) with the sedf scheduler, it is required for the
vCPUs of a domain to have been allocated and setup already (in
the hypervisor), when the first call to libxl_domain_sched_params_get()
happens, and that is not true.

This fixes that by avoiding calling that function at all, as we
only need to know which scheduler the domain is running under,
and that is provided by libxl__domain_scheduler() which is safe
to be called there.

While at it, also improve a bit the comments about the whole
sedf parameter validation and mangling process.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -80,36 +80,48 @@ static int sched_params_valid(libxl__gc 
     int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
     int has_extratime =
                 scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
-    libxl_domain_sched_params sci;
-
-    libxl_domain_sched_params_get(CTX, domid, &sci);
 
     /* The sedf scheduler needs some more consistency checking */
-    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
+    if (libxl__domain_scheduler(gc, domid) == LIBXL_SCHEDULER_SEDF) {
         if (has_weight && (has_period || has_slice))
             return 0;
+        /* If you want a real-time domain, with its own period and
+         * slice, please, do provide both! */
         if (has_period != has_slice)
             return 0;
 
         /*
          * Idea is, if we specify a weight, then both period and
-         * slice has to be zero. OTOH, if we do not specify a weight,
-         * that means we want a pure best effort domain or an actual
-         * real-time one. In the former case, it is period that needs
-         * to be zero, in the latter, weight should be.
+         * slice has to be zero. OTOH, if we do specify a period and
+         * slice, it is weight that should be zeroed. See
+         * docs/misc/sedf_scheduler_mini-HOWTO.txt for more details
+         * on the meaningful combinations and their meanings.
          */
         if (has_weight) {
             scp->slice = 0;
             scp->period = 0;
         }
         else if (!has_period) {
+            /* No weight nor slice/period means best effort. Parameters needs
+             * some mangling in order to properly ask for that, though. */
+
+            /*
+             * Providing no weight does not make any sense if we do not allow
+             * the domain to run in extra time. On the other hand, if we have
+             * extra time, weight will be ignored (and zeroed) by Xen, but it
+             * can't be zero here, or the call for setting the scheduling
+             * parameters will fail. So, avoid the latter by setting a random
+             * weight (namely, 1), as it will be ignored anyway.
+             */
+
             /* We can setup a proper best effort domain (extra time only)
              * iff we either already have or are asking for some extra time. */
-            scp->weight = has_extratime ? scp->extratime : sci.extratime;
+            scp->weight = has_extratime ? scp->extratime : 1;
             scp->period = 0;
+        } else {
+            /* Real-time domain: will get slice CPU time over every period */
+            scp->weight = 0;
         }
-        if (has_period && has_slice)
-            scp->weight = 0;
     }
 
     return 1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:21:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6bs-0004OT-3U; Fri, 22 Jun 2012 16:21:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1Si6bq-0004OH-AH
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:21:22 +0000
Received: from [85.158.143.99:10755] by server-2.bemta-4.messagelabs.com id
	11/93-17938-18B94EF4; Fri, 22 Jun 2012 16:21:21 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340382079!27761526!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1MTgw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 22 Jun 2012 16:21:19 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-216.messagelabs.com with SMTP;
	22 Jun 2012 16:21:19 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 22 Jun 2012 09:21:18 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="159626333"
Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87])
	by azsmga001.ch.intel.com with ESMTP; 22 Jun 2012 09:21:18 -0700
Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by
	orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 22 Jun 2012 09:21:17 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.217]) by
	ORSMSX102.amr.corp.intel.com ([169.254.1.237]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 09:21:17 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJwBAufgAACbfvoAAAhphAAAGzxWAAAIVhAAADioJcA==
Date: Fri, 22 Jun 2012 16:21:17 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F193234FE@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
	<4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
In-Reply-To: <4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"Raj, Ashok" <ashok.raj@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Yet I don't think we're really concerned about performance when handling machine
> checks. But having more than one usable bank must have advantages, else hardware
> wouldn't implement things that way.

Primary reason for multiple banks is h/w design ... the silicon implementing the bank
is generally included in the component that generates the error. E.g. there may be
multiple memory controllers on a die, each with its own bank. H/W designers hate
running long "wires" across the die as it messes up their layout options.

There may be some secondary side benefit that independent errors might be
reported to different banks, and so avoid some overwrite problems.  But I don't
think that Xen has a big worry with overwrite, does it? In general the errors that
you will show to the guest are ones that you expect the guest to handle immediately
(e.g. SRAO and SRAR signaled with a machine check). You do not log any corrected
errors to the guest (they can't do anything useful with them). You certainly don't
log any errors that are not signaled. So you should never have any errors hanging
around in banks for long periods that would get overwritten.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:21:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6bs-0004OT-3U; Fri, 22 Jun 2012 16:21:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1Si6bq-0004OH-AH
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:21:22 +0000
Received: from [85.158.143.99:10755] by server-2.bemta-4.messagelabs.com id
	11/93-17938-18B94EF4; Fri, 22 Jun 2012 16:21:21 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340382079!27761526!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1MTgw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 22 Jun 2012 16:21:19 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-216.messagelabs.com with SMTP;
	22 Jun 2012 16:21:19 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 22 Jun 2012 09:21:18 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="159626333"
Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87])
	by azsmga001.ch.intel.com with ESMTP; 22 Jun 2012 09:21:18 -0700
Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by
	orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 22 Jun 2012 09:21:17 -0700
Received: from orsmsx104.amr.corp.intel.com ([169.254.3.217]) by
	ORSMSX102.amr.corp.intel.com ([169.254.1.237]) with mapi id
	14.01.0355.002; Fri, 22 Jun 2012 09:21:17 -0700
From: "Luck, Tony" <tony.luck@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJwBAufgAACbfvoAAAhphAAAGzxWAAAIVhAAADioJcA==
Date: Fri, 22 Jun 2012 16:21:17 +0000
Message-ID: <3908561D78D1C84285E8C5FCA982C28F193234FE@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
	<4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
In-Reply-To: <4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
MIME-Version: 1.0
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	"Raj, Ashok" <ashok.raj@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Yet I don't think we're really concerned about performance when handling machine
> checks. But having more than one usable bank must have advantages, else hardware
> wouldn't implement things that way.

Primary reason for multiple banks is h/w design ... the silicon implementing the bank
is generally included in the component that generates the error. E.g. there may be
multiple memory controllers on a die, each with its own bank. H/W designers hate
running long "wires" across the die as it messes up their layout options.

There may be some secondary side benefit that independent errors might be
reported to different banks, and so avoid some overwrite problems.  But I don't
think that Xen has a big worry with overwrite, does it? In general the errors that
you will show to the guest are ones that you expect the guest to handle immediately
(e.g. SRAO and SRAR signaled with a machine check). You do not log any corrected
errors to the guest (they can't do anything useful with them). You certainly don't
log any errors that are not signaled. So you should never have any errors hanging
around in banks for long periods that would get overwritten.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:26:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6gq-0004f2-09; Fri, 22 Jun 2012 16:26:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6gp-0004ew-Ai
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:26:31 +0000
Received: from [85.158.143.99:31676] by server-2.bemta-4.messagelabs.com id
	9A/98-17938-6BC94EF4; Fri, 22 Jun 2012 16:26:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340382389!23386856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7620 invoked from network); 22 Jun 2012 16:26:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:26:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13175139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:26:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 17:26:29 +0100
Date: Fri, 22 Jun 2012 17:26:07 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1206221722040.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen/events: fix unmask_evtchn for PV on HVM
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When unmask_evtchn is called, if we already have an event pending, we
just set evtchn_pending_sel waiting for local_irq_enable to be called.
That is because PV guests set the irq_enable pvops to
xen_irq_enable_direct that also handles pending events.

However HVM guests (and ARM guests) do not change or do not have the
irq_enable pvop, so evtchn_unmask cannot work properly for them.

Considering that having the pending_irq bit set when unmask_evtchn is
called is not very common, and it is simpler to keep the
native_irq_enable implementation for HVM guests (and ARM guests), the
best thing to do is just use the EVTCHNOP_unmask hypercall (Xen
re-injects pending events in response).

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index eae0d0b..0132505 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -372,8 +372,11 @@ static void unmask_evtchn(int port)
 
 	BUG_ON(!irqs_disabled());
 
-	/* Slow path (hypercall) if this is a non-local port. */
-	if (unlikely(cpu != cpu_from_evtchn(port))) {
+	/* Slow path (hypercall) if this is a non-local port or if this is
+	 * an hvm domain and an event is pending (hvm domains don't have
+	 * their own implementation of irq_enable). */
+	if (unlikely((cpu != cpu_from_evtchn(port)) ||
+			(xen_hvm_domain() && sync_test_bit(port, &s->evtchn_pending[0])))) {
 		struct evtchn_unmask unmask = { .port = port };
 		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
 	} else {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:26:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16: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 1Si6gq-0004f2-09; Fri, 22 Jun 2012 16:26:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Si6gp-0004ew-Ai
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 16:26:31 +0000
Received: from [85.158.143.99:31676] by server-2.bemta-4.messagelabs.com id
	9A/98-17938-6BC94EF4; Fri, 22 Jun 2012 16:26:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340382389!23386856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7620 invoked from network); 22 Jun 2012 16:26:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:26:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13175139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:26:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 17:26:29 +0100
Date: Fri, 22 Jun 2012 17:26:07 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
In-Reply-To: <1340381685-22529-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1206221722040.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221644370.27860@kaball.uk.xensource.com>
	<1340381685-22529-1-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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen/events: fix unmask_evtchn for PV on HVM
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When unmask_evtchn is called, if we already have an event pending, we
just set evtchn_pending_sel waiting for local_irq_enable to be called.
That is because PV guests set the irq_enable pvops to
xen_irq_enable_direct that also handles pending events.

However HVM guests (and ARM guests) do not change or do not have the
irq_enable pvop, so evtchn_unmask cannot work properly for them.

Considering that having the pending_irq bit set when unmask_evtchn is
called is not very common, and it is simpler to keep the
native_irq_enable implementation for HVM guests (and ARM guests), the
best thing to do is just use the EVTCHNOP_unmask hypercall (Xen
re-injects pending events in response).

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index eae0d0b..0132505 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -372,8 +372,11 @@ static void unmask_evtchn(int port)
 
 	BUG_ON(!irqs_disabled());
 
-	/* Slow path (hypercall) if this is a non-local port. */
-	if (unlikely(cpu != cpu_from_evtchn(port))) {
+	/* Slow path (hypercall) if this is a non-local port or if this is
+	 * an hvm domain and an event is pending (hvm domains don't have
+	 * their own implementation of irq_enable). */
+	if (unlikely((cpu != cpu_from_evtchn(port)) ||
+			(xen_hvm_domain() && sync_test_bit(port, &s->evtchn_pending[0])))) {
 		struct evtchn_unmask unmask = { .port = port };
 		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
 	} else {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:29:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si6jp-0004sA-J7; Fri, 22 Jun 2012 16:29:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Si6jo-0004s4-S7
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 16:29:36 +0000
Received: from [85.158.138.51:13019] by server-4.bemta-3.messagelabs.com id
	48/7E-17105-07D94EF4; Fri, 22 Jun 2012 16:29:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340382572!10375820!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8933 invoked from network); 22 Jun 2012 16:29:33 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 16:29:33 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79072209; Fri, 22 Jun 2012 18:29:32 +0200
Message-ID: <1340382566.4775.8.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 22 Jun 2012 18:29:26 +0200
In-Reply-To: <1340380698.4775.5.camel@Solace>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
	<1340364194.26083.87.camel@zakaz.uk.xensource.com>
	<1340380698.4775.5.camel@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
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 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7874610198159341945=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7874610198159341945==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-qFmZax12B5h5YzVibGp4"


--=-qFmZax12B5h5YzVibGp4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-22 at 17:58 +0200, Dario Faggioli wrote:
> New patch against this patch coming. This time I tested it on both sedf
> and credit and tested rebooting a domain as well... Let's hope this is
> going to be the end of this!
>=20
Which just for the records is <f5f29d8e2ccf642cad89.1340381818@Solace>,
which I think Ian is checking in right now. Let's wait for some verdict
from OSStest during the weekend. :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-qFmZax12B5h5YzVibGp4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/knWYACgkQk4XaBE3IOsSc4QCgg3TAjc+P+kPulr+XOYj4r6MR
MfwAnR9b1/9+hCVPnWv7yGqH1xYJpRg6
=smmd
-----END PGP SIGNATURE-----

--=-qFmZax12B5h5YzVibGp4--



--===============7874610198159341945==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7874610198159341945==--



From xen-devel-bounces@lists.xen.org Fri Jun 22 16:29:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 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 1Si6jp-0004sA-J7; Fri, 22 Jun 2012 16:29:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Si6jo-0004s4-S7
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 16:29:36 +0000
Received: from [85.158.138.51:13019] by server-4.bemta-3.messagelabs.com id
	48/7E-17105-07D94EF4; Fri, 22 Jun 2012 16:29:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340382572!10375820!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8933 invoked from network); 22 Jun 2012 16:29:33 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	22 Jun 2012 16:29:33 -0000
Received: from [62.94.181.222] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79072209; Fri, 22 Jun 2012 18:29:32 +0200
Message-ID: <1340382566.4775.8.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 22 Jun 2012 18:29:26 +0200
In-Reply-To: <1340380698.4775.5.camel@Solace>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<998d48ccb8905907cb2f.1340362610@cosworth.uk.xensource.com>
	<1340364194.26083.87.camel@zakaz.uk.xensource.com>
	<1340380698.4775.5.camel@Solace>
X-Mailer: Evolution 3.2.2-1+b1 
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 5] libxl: validate scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7874610198159341945=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7874610198159341945==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-qFmZax12B5h5YzVibGp4"


--=-qFmZax12B5h5YzVibGp4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-22 at 17:58 +0200, Dario Faggioli wrote:
> New patch against this patch coming. This time I tested it on both sedf
> and credit and tested rebooting a domain as well... Let's hope this is
> going to be the end of this!
>=20
Which just for the records is <f5f29d8e2ccf642cad89.1340381818@Solace>,
which I think Ian is checking in right now. Let's wait for some verdict
from OSStest during the weekend. :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-qFmZax12B5h5YzVibGp4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/knWYACgkQk4XaBE3IOsSc4QCgg3TAjc+P+kPulr+XOYj4r6MR
MfwAnR9b1/9+hCVPnWv7yGqH1xYJpRg6
=smmd
-----END PGP SIGNATURE-----

--=-qFmZax12B5h5YzVibGp4--



--===============7874610198159341945==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7874610198159341945==--



From xen-devel-bounces@lists.xen.org Fri Jun 22 16:44:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:44: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 1Si6xr-0005IC-LX; Fri, 22 Jun 2012 16:44:07 +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 1Si6xq-0005I3-9U
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 16:44:06 +0000
Received: from [193.109.254.147:64654] by server-7.bemta-14.messagelabs.com id
	0E/21-29827-5D0A4EF4; Fri, 22 Jun 2012 16:44:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340383444!3386365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24767 invoked from network); 22 Jun 2012 16:44:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13175390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:44:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 17:44:04 +0100
Message-ID: <1340383443.26083.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 22 Jun 2012 17:44:03 +0100
In-Reply-To: <f5f29d8e2ccf642cad89.1340381818@Solace>
References: <f5f29d8e2ccf642cad89.1340381818@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix validation of scheduling
	parameters for sedf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 17:16 +0100, Dario Faggioli wrote:
> 2205914617cb does its job in correcting the "wrong domain being
> considered" issue introduced by 9d1fd58ff602. Unfortunately, when
> dealing (again!) with the sedf scheduler, it is required for the
> vCPUs of a domain to have been allocated and setup already (in
> the hypervisor), when the first call to libxl_domain_sched_params_get()
> happens, and that is not true.
> 
> This fixes that by avoiding calling that function at all, as we
> only need to know which scheduler the domain is running under,
> and that is provided by libxl__domain_scheduler() which is safe
> to be called there.
> 
> While at it, also improve a bit the comments about the whole
> sedf parameter validation and mangling process.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>

> 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
> @@ -80,36 +80,48 @@ static int sched_params_valid(libxl__gc 
>      int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
>      int has_extratime =
>                  scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
> -    libxl_domain_sched_params sci;
> -
> -    libxl_domain_sched_params_get(CTX, domid, &sci);
>  
>      /* The sedf scheduler needs some more consistency checking */
> -    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> +    if (libxl__domain_scheduler(gc, domid) == LIBXL_SCHEDULER_SEDF) {
>          if (has_weight && (has_period || has_slice))
>              return 0;
> +        /* If you want a real-time domain, with its own period and
> +         * slice, please, do provide both! */
>          if (has_period != has_slice)
>              return 0;
>  
>          /*
>           * Idea is, if we specify a weight, then both period and
> -         * slice has to be zero. OTOH, if we do not specify a weight,
> -         * that means we want a pure best effort domain or an actual
> -         * real-time one. In the former case, it is period that needs
> -         * to be zero, in the latter, weight should be.
> +         * slice has to be zero. OTOH, if we do specify a period and
> +         * slice, it is weight that should be zeroed. See
> +         * docs/misc/sedf_scheduler_mini-HOWTO.txt for more details
> +         * on the meaningful combinations and their meanings.
>           */
>          if (has_weight) {
>              scp->slice = 0;
>              scp->period = 0;
>          }
>          else if (!has_period) {
> +            /* No weight nor slice/period means best effort. Parameters needs
> +             * some mangling in order to properly ask for that, though. */
> +
> +            /*
> +             * Providing no weight does not make any sense if we do not allow
> +             * the domain to run in extra time. On the other hand, if we have
> +             * extra time, weight will be ignored (and zeroed) by Xen, but it
> +             * can't be zero here, or the call for setting the scheduling
> +             * parameters will fail. So, avoid the latter by setting a random
> +             * weight (namely, 1), as it will be ignored anyway.
> +             */
> +
>              /* We can setup a proper best effort domain (extra time only)
>               * iff we either already have or are asking for some extra time. */
> -            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> +            scp->weight = has_extratime ? scp->extratime : 1;
>              scp->period = 0;
> +        } else {
> +            /* Real-time domain: will get slice CPU time over every period */
> +            scp->weight = 0;
>          }
> -        if (has_period && has_slice)
> -            scp->weight = 0;
>      }
>  
>      return 1;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 16:44:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 16:44: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 1Si6xr-0005IC-LX; Fri, 22 Jun 2012 16:44:07 +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 1Si6xq-0005I3-9U
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 16:44:06 +0000
Received: from [193.109.254.147:64654] by server-7.bemta-14.messagelabs.com id
	0E/21-29827-5D0A4EF4; Fri, 22 Jun 2012 16:44:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340383444!3386365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24767 invoked from network); 22 Jun 2012 16:44:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 16:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13175390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 16:44:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 17:44:04 +0100
Message-ID: <1340383443.26083.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 22 Jun 2012 17:44:03 +0100
In-Reply-To: <f5f29d8e2ccf642cad89.1340381818@Solace>
References: <f5f29d8e2ccf642cad89.1340381818@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix validation of scheduling
	parameters for sedf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 17:16 +0100, Dario Faggioli wrote:
> 2205914617cb does its job in correcting the "wrong domain being
> considered" issue introduced by 9d1fd58ff602. Unfortunately, when
> dealing (again!) with the sedf scheduler, it is required for the
> vCPUs of a domain to have been allocated and setup already (in
> the hypervisor), when the first call to libxl_domain_sched_params_get()
> happens, and that is not true.
> 
> This fixes that by avoiding calling that function at all, as we
> only need to know which scheduler the domain is running under,
> and that is provided by libxl__domain_scheduler() which is safe
> to be called there.
> 
> While at it, also improve a bit the comments about the whole
> sedf parameter validation and mangling process.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>

> 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
> @@ -80,36 +80,48 @@ static int sched_params_valid(libxl__gc 
>      int has_slice = scp->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT;
>      int has_extratime =
>                  scp->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT;
> -    libxl_domain_sched_params sci;
> -
> -    libxl_domain_sched_params_get(CTX, domid, &sci);
>  
>      /* The sedf scheduler needs some more consistency checking */
> -    if (sci.sched == LIBXL_SCHEDULER_SEDF) {
> +    if (libxl__domain_scheduler(gc, domid) == LIBXL_SCHEDULER_SEDF) {
>          if (has_weight && (has_period || has_slice))
>              return 0;
> +        /* If you want a real-time domain, with its own period and
> +         * slice, please, do provide both! */
>          if (has_period != has_slice)
>              return 0;
>  
>          /*
>           * Idea is, if we specify a weight, then both period and
> -         * slice has to be zero. OTOH, if we do not specify a weight,
> -         * that means we want a pure best effort domain or an actual
> -         * real-time one. In the former case, it is period that needs
> -         * to be zero, in the latter, weight should be.
> +         * slice has to be zero. OTOH, if we do specify a period and
> +         * slice, it is weight that should be zeroed. See
> +         * docs/misc/sedf_scheduler_mini-HOWTO.txt for more details
> +         * on the meaningful combinations and their meanings.
>           */
>          if (has_weight) {
>              scp->slice = 0;
>              scp->period = 0;
>          }
>          else if (!has_period) {
> +            /* No weight nor slice/period means best effort. Parameters needs
> +             * some mangling in order to properly ask for that, though. */
> +
> +            /*
> +             * Providing no weight does not make any sense if we do not allow
> +             * the domain to run in extra time. On the other hand, if we have
> +             * extra time, weight will be ignored (and zeroed) by Xen, but it
> +             * can't be zero here, or the call for setting the scheduling
> +             * parameters will fail. So, avoid the latter by setting a random
> +             * weight (namely, 1), as it will be ignored anyway.
> +             */
> +
>              /* We can setup a proper best effort domain (extra time only)
>               * iff we either already have or are asking for some extra time. */
> -            scp->weight = has_extratime ? scp->extratime : sci.extratime;
> +            scp->weight = has_extratime ? scp->extratime : 1;
>              scp->period = 0;
> +        } else {
> +            /* Real-time domain: will get slice CPU time over every period */
> +            scp->weight = 0;
>          }
> -        if (has_period && has_slice)
> -            scp->weight = 0;
>      }
>  
>      return 1;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 17:44:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 17: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 1Si7tX-00067k-HK; Fri, 22 Jun 2012 17:43:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Si7tV-00067f-O6
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 17:43:41 +0000
Received: from [85.158.143.99:51907] by server-3.bemta-4.messagelabs.com id
	B9/F2-05808-CCEA4EF4; Fri, 22 Jun 2012 17:43:40 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340387018!21637603!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk0NzAx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28542 invoked from network); 22 Jun 2012 17:43:39 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 17:43:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340387019; x=1371923019;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=Sa1DMlO59HS4BRBQYZtnF8Cey4BuAbAu+zHOCV2MKNc=;
	b=hzsg338dndG/v8y56zS2FQlOlpcyb3UTFpVXV/u7/ErIEvx578JBS4HJ
	wfs1SjLaoz67HcDgiKY1gJob3WLxyg==;
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="986088212"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2012 17:43:36 +0000
Received: from US-SEA-R8XVZTX (us-sea-r806drk.ant.amazon.com [10.63.104.91])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5MHhZGu005549; Fri, 22 Jun 2012 17:43:35 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Fri, 22 Jun 2012 10:43:35 -0700
Date: Fri, 22 Jun 2012 10:43:35 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120622174335.GE2640@US-SEA-R8XVZTX>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621184036.GD2640@US-SEA-R8XVZTX>
	<1340353609.19647.24.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340353609.19647.24.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Olaf Hering <olaf@aepfle.de>,
	"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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 22, 2012 at 01:26:49AM -0700, Ian Campbell wrote:
> On Thu, 2012-06-21 at 19:43 +0100, Matt Wilson wrote:
> > Confusingly, we also install "private" binaries to $(PRIVATE_BINDIR),
> > which expands to $(PRIVATE_PREFIX)/bin which expands to $(LIBDIR)/xen/bin,
> > which expands to /usr/lib64/xen/bin. This results in paths like:
> > 
> > /usr/lib64/xen/bin/lsevtchn
> 
> ... weird!
> 
> [...]
> 
> > > I suppose configure defines a libexec but it isn't the one we want?
> > 
> > By default, configure will define libexec to be /usr/libexec, which I
> > like. If we switched to using the value provided from configure, we
> > people who don't like /usr/libexec could just provide a different
> > value at ./configure time.
> 
> Lets leave that until 4.3, I'm already a little uncomfortable messing
> with the build system at this stage in 4.2 (there's always unforeseen
> consequences to these sorts of changes, no matter how diligent we all
> are :-/). For the lib vs. lib64 breakage on multiarch I think the risk
> is worth it, but for more "cosmetic" issues like libexec I'd rather pass
> for now.

Agreed. It deserves a little extra attention, since some of the
binaries that might should move to /usr/libexec live outside the
tools/ tree.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 17:44:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 17: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 1Si7tX-00067k-HK; Fri, 22 Jun 2012 17:43:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Si7tV-00067f-O6
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 17:43:41 +0000
Received: from [85.158.143.99:51907] by server-3.bemta-4.messagelabs.com id
	B9/F2-05808-CCEA4EF4; Fri, 22 Jun 2012 17:43:40 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340387018!21637603!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk0NzAx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28542 invoked from network); 22 Jun 2012 17:43:39 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 17:43:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340387019; x=1371923019;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=Sa1DMlO59HS4BRBQYZtnF8Cey4BuAbAu+zHOCV2MKNc=;
	b=hzsg338dndG/v8y56zS2FQlOlpcyb3UTFpVXV/u7/ErIEvx578JBS4HJ
	wfs1SjLaoz67HcDgiKY1gJob3WLxyg==;
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="986088212"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2012 17:43:36 +0000
Received: from US-SEA-R8XVZTX (us-sea-r806drk.ant.amazon.com [10.63.104.91])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with SMTP id
	q5MHhZGu005549; Fri, 22 Jun 2012 17:43:35 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Fri, 22 Jun 2012 10:43:35 -0700
Date: Fri, 22 Jun 2012 10:43:35 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120622174335.GE2640@US-SEA-R8XVZTX>
References: <patchbomb.1340232708@kaos-source-31003.sea31.amazon.com>
	<4ba90ad045963033e72c.1340232709@kaos-source-31003.sea31.amazon.com>
	<1340267605.21872.10.camel@zakaz.uk.xensource.com>
	<20120621184036.GD2640@US-SEA-R8XVZTX>
	<1340353609.19647.24.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340353609.19647.24.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Olaf Hering <olaf@aepfle.de>,
	"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 1 of 1 v2] tools: honour --libdir when it is
 passed to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 22, 2012 at 01:26:49AM -0700, Ian Campbell wrote:
> On Thu, 2012-06-21 at 19:43 +0100, Matt Wilson wrote:
> > Confusingly, we also install "private" binaries to $(PRIVATE_BINDIR),
> > which expands to $(PRIVATE_PREFIX)/bin which expands to $(LIBDIR)/xen/bin,
> > which expands to /usr/lib64/xen/bin. This results in paths like:
> > 
> > /usr/lib64/xen/bin/lsevtchn
> 
> ... weird!
> 
> [...]
> 
> > > I suppose configure defines a libexec but it isn't the one we want?
> > 
> > By default, configure will define libexec to be /usr/libexec, which I
> > like. If we switched to using the value provided from configure, we
> > people who don't like /usr/libexec could just provide a different
> > value at ./configure time.
> 
> Lets leave that until 4.3, I'm already a little uncomfortable messing
> with the build system at this stage in 4.2 (there's always unforeseen
> consequences to these sorts of changes, no matter how diligent we all
> are :-/). For the lib vs. lib64 breakage on multiarch I think the risk
> is worth it, but for more "cosmetic" issues like libexec I'd rather pass
> for now.

Agreed. It deserves a little extra attention, since some of the
binaries that might should move to /usr/libexec live outside the
tools/ tree.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 18:37:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 18: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 1Si8jR-0006zO-Ft; Fri, 22 Jun 2012 18:37:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si8jP-0006zJ-Rg
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 18:37:20 +0000
Received: from [85.158.143.99:28101] by server-3.bemta-4.messagelabs.com id
	15/1D-05808-F5BB4EF4; Fri, 22 Jun 2012 18:37:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340390238!28102190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8739 invoked from network); 22 Jun 2012 18:37:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 18:37:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13176843"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 18:37:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 19:37:17 +0100
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 1Si8jN-00079O-5R;
	Fri, 22 Jun 2012 18:37:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Si8jM-0007Bg-Qg;
	Fri, 22 Jun 2012 19:37:17 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13334-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 19:37:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13334: 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 13334 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13334/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13090
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13090

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-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-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=ec75bfd8599c
+ . 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 ec75bfd8599c
+ branch=xen-4.1-testing
+ revision=ec75bfd8599c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r ec75bfd8599c 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 17 changes to 17 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 18:37:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 18: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 1Si8jR-0006zO-Ft; Fri, 22 Jun 2012 18:37:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Si8jP-0006zJ-Rg
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 18:37:20 +0000
Received: from [85.158.143.99:28101] by server-3.bemta-4.messagelabs.com id
	15/1D-05808-F5BB4EF4; Fri, 22 Jun 2012 18:37:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340390238!28102190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8739 invoked from network); 22 Jun 2012 18:37:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 18:37:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="13176843"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 18:37:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 19:37:17 +0100
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 1Si8jN-00079O-5R;
	Fri, 22 Jun 2012 18:37:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Si8jM-0007Bg-Qg;
	Fri, 22 Jun 2012 19:37:17 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13334-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 19:37:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13334: 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 13334 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13334/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13090
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13090

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-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-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ec75bfd8599c
baseline version:
 xen                  11dfb8e06343

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=ec75bfd8599c
+ . 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 ec75bfd8599c
+ branch=xen-4.1-testing
+ revision=ec75bfd8599c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r ec75bfd8599c 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 17 changes to 17 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 18:47:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 18: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 1Si8sk-0007Dl-Ma; Fri, 22 Jun 2012 18:46:58 +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 1Si8si-0007Dg-K5
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 18:46:56 +0000
Received: from [85.158.143.35:34950] by server-1.bemta-4.messagelabs.com id
	3D/0A-24392-F9DB4EF4; Fri, 22 Jun 2012 18:46:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340390813!15859364!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27420 invoked from network); 22 Jun 2012 18:46:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 18:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="29106673"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 14:46:31 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 14:46:31 -0400
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 1Si8jP-000466-BP	for
	xen-devel@lists.xen.org; Fri, 22 Jun 2012 19:37:19 +0100
Message-ID: <4FE4BB5F.5000103@citrix.com>
Date: Fri, 22 Jun 2012 19:37:19 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------050908090002070604040600"
Subject: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050908090002070604040600
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This patch has been sitting in the XenServer patch queue for an
embarrassingly long time.  I have formatted it suitably for upstreaming.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050908090002070604040600
Content-Type: text/x-patch; name="pygrub-bug-test-kernel-exists.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="pygrub-bug-test-kernel-exists.patch"

pygrub: verify chosen kernel really exists

Verify that the chosen kernel really exists, and fail with an informative error
if it does not.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 32034d1914a6 tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -821,10 +821,15 @@ if __name__ == "__main__":
     if not fs:
         raise RuntimeError, "Unable to find partition containing kernel"
 
+    # Does the chosen kernel really exist ?
+    try:
+        data = fs.open_file(chosencfg["kernel"]).read()
+    except:
+        raise RuntimeError, "The chosen kernel does not exist"
+
     if not_really:
         bootcfg["kernel"] = "<kernel:%s>" % chosencfg["kernel"]
     else:
-        data = fs.open_file(chosencfg["kernel"]).read()
         (tfd, bootcfg["kernel"]) = tempfile.mkstemp(prefix="boot_kernel.",
                                                     dir=output_directory)
         os.write(tfd, data)

--------------050908090002070604040600
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050908090002070604040600--


From xen-devel-bounces@lists.xen.org Fri Jun 22 18:47:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 18: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 1Si8sk-0007Dl-Ma; Fri, 22 Jun 2012 18:46:58 +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 1Si8si-0007Dg-K5
	for xen-devel@lists.xen.org; Fri, 22 Jun 2012 18:46:56 +0000
Received: from [85.158.143.35:34950] by server-1.bemta-4.messagelabs.com id
	3D/0A-24392-F9DB4EF4; Fri, 22 Jun 2012 18:46:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340390813!15859364!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27420 invoked from network); 22 Jun 2012 18:46:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 18:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,459,1336363200"; d="scan'208";a="29106673"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 14:46:31 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 22 Jun 2012 14:46:31 -0400
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 1Si8jP-000466-BP	for
	xen-devel@lists.xen.org; Fri, 22 Jun 2012 19:37:19 +0100
Message-ID: <4FE4BB5F.5000103@citrix.com>
Date: Fri, 22 Jun 2012 19:37:19 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------050908090002070604040600"
Subject: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050908090002070604040600
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This patch has been sitting in the XenServer patch queue for an
embarrassingly long time.  I have formatted it suitably for upstreaming.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050908090002070604040600
Content-Type: text/x-patch; name="pygrub-bug-test-kernel-exists.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="pygrub-bug-test-kernel-exists.patch"

pygrub: verify chosen kernel really exists

Verify that the chosen kernel really exists, and fail with an informative error
if it does not.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 32034d1914a6 tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -821,10 +821,15 @@ if __name__ == "__main__":
     if not fs:
         raise RuntimeError, "Unable to find partition containing kernel"
 
+    # Does the chosen kernel really exist ?
+    try:
+        data = fs.open_file(chosencfg["kernel"]).read()
+    except:
+        raise RuntimeError, "The chosen kernel does not exist"
+
     if not_really:
         bootcfg["kernel"] = "<kernel:%s>" % chosencfg["kernel"]
     else:
-        data = fs.open_file(chosencfg["kernel"]).read()
         (tfd, bootcfg["kernel"]) = tempfile.mkstemp(prefix="boot_kernel.",
                                                     dir=output_directory)
         os.write(tfd, data)

--------------050908090002070604040600
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050908090002070604040600--


From xen-devel-bounces@lists.xen.org Fri Jun 22 20:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 20: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 1SiAWw-0001rc-CU; Fri, 22 Jun 2012 20:32: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 1SiAWu-0001rJ-Rh
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 20:32:33 +0000
Received: from [85.158.138.51:21296] by server-4.bemta-3.messagelabs.com id
	B4/11-17105-066D4EF4; Fri, 22 Jun 2012 20:32:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340397150!27971058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25043 invoked from network); 22 Jun 2012 20:32:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 20:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="13177609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 20:32:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 21:32:30 +0100
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 1SiAWs-0007lL-2K;
	Fri, 22 Jun 2012 20:32:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiAWr-0007tO-TV;
	Fri, 22 Jun 2012 21:32:29 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13338-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 21:32:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13338: 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 13338 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13338/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4
baseline version:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=4e8785001421e97c4f1c18d27ce77d717f9561d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable 4e8785001421e97c4f1c18d27ce77d717f9561d4
+ branch=qemu-upstream-unstable
+ revision=4e8785001421e97c4f1c18d27ce77d717f9561d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git 4e8785001421e97c4f1c18d27ce77d717f9561d4:master
Counting objects: 1   
Counting objects: 4   
Counting objects: 8, done.
Compressing objects:  50% (1/2)   
Compressing objects: 100% (2/2)   
Compressing objects: 100% (2/2), 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), 1.11 KiB, done.
Total 6 (delta 4), reused 6 (delta 4)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   f7f8c33..4e87850  4e8785001421e97c4f1c18d27ce77d717f9561d4 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 20:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 20: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 1SiAWw-0001rc-CU; Fri, 22 Jun 2012 20:32: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 1SiAWu-0001rJ-Rh
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 20:32:33 +0000
Received: from [85.158.138.51:21296] by server-4.bemta-3.messagelabs.com id
	B4/11-17105-066D4EF4; Fri, 22 Jun 2012 20:32:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340397150!27971058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIyMzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25043 invoked from network); 22 Jun 2012 20:32:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 20:32:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="13177609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 20:32:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 22 Jun 2012 21:32:30 +0100
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 1SiAWs-0007lL-2K;
	Fri, 22 Jun 2012 20:32:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiAWr-0007tO-TV;
	Fri, 22 Jun 2012 21:32:29 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13338-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Jun 2012 21:32:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13338: 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 13338 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13338/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4
baseline version:
 qemuu                f7f8c33cd49885d69efc2e5f7f9a613d631762e2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=4e8785001421e97c4f1c18d27ce77d717f9561d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable 4e8785001421e97c4f1c18d27ce77d717f9561d4
+ branch=qemu-upstream-unstable
+ revision=4e8785001421e97c4f1c18d27ce77d717f9561d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git 4e8785001421e97c4f1c18d27ce77d717f9561d4:master
Counting objects: 1   
Counting objects: 4   
Counting objects: 8, done.
Compressing objects:  50% (1/2)   
Compressing objects: 100% (2/2)   
Compressing objects: 100% (2/2), 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), 1.11 KiB, done.
Total 6 (delta 4), reused 6 (delta 4)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   f7f8c33..4e87850  4e8785001421e97c4f1c18d27ce77d717f9561d4 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 23:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 23: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 1SiDQ3-00040I-6g; Fri, 22 Jun 2012 23:37:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SiDQ1-00040D-Le
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 23:37:37 +0000
Received: from [193.109.254.147:46343] by server-2.bemta-14.messagelabs.com id
	09/3B-01735-0C105EF4; Fri, 22 Jun 2012 23:37:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340408255!8742619!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3618 invoked from network); 22 Jun 2012 23:37:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 23:37:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="13178732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 23:37:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 00:37:35 +0100
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 1SiDPz-0000J8-0S;
	Fri, 22 Jun 2012 23:37:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiDPv-0005k7-5I;
	Sat, 23 Jun 2012 00:37:34 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13339-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 00:37:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13339: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13339 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13339/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  9c5e36af6ef3
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 22 23:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Jun 2012 23: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 1SiDQ3-00040I-6g; Fri, 22 Jun 2012 23:37:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SiDQ1-00040D-Le
	for xen-devel@lists.xensource.com; Fri, 22 Jun 2012 23:37:37 +0000
Received: from [193.109.254.147:46343] by server-2.bemta-14.messagelabs.com id
	09/3B-01735-0C105EF4; Fri, 22 Jun 2012 23:37:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340408255!8742619!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3618 invoked from network); 22 Jun 2012 23:37:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jun 2012 23:37:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="13178732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jun 2012 23:37:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 00:37:35 +0100
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 1SiDPz-0000J8-0S;
	Fri, 22 Jun 2012 23:37:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiDPv-0005k7-5I;
	Sat, 23 Jun 2012 00:37:34 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13339-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 00:37:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13339: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13339 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13339/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 13025

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 13025
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  9c5e36af6ef3
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 05:22:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 05: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 1SiImi-0003FR-St; Sat, 23 Jun 2012 05:21: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 1SiImh-0003FM-98
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 05:21:23 +0000
Received: from [85.158.139.83:41032] by server-10.bemta-5.messagelabs.com id
	30/7D-02190-25255EF4; Sat, 23 Jun 2012 05:21:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340428881!29080068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8798 invoked from network); 23 Jun 2012 05:21:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 05:21:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,462,1336348800"; d="scan'208";a="13179957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jun 2012 05:21:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 06:21:20 +0100
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 1SiIme-00027n-CW;
	Sat, 23 Jun 2012 05:21:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiImd-0008UT-VL;
	Sat, 23 Jun 2012 06:21:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13352-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 06:21:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13352: 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 13352 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13352/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=836db8c4b9f9
+ . 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 836db8c4b9f9
+ branch=xen-unstable
+ revision=836db8c4b9f9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 836db8c4b9f9 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 27 changesets with 49 changes to 39 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 05:22:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 05: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 1SiImi-0003FR-St; Sat, 23 Jun 2012 05:21: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 1SiImh-0003FM-98
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 05:21:23 +0000
Received: from [85.158.139.83:41032] by server-10.bemta-5.messagelabs.com id
	30/7D-02190-25255EF4; Sat, 23 Jun 2012 05:21:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340428881!29080068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDIzMTA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8798 invoked from network); 23 Jun 2012 05:21:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 05:21:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,462,1336348800"; d="scan'208";a="13179957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jun 2012 05:21:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 06:21:20 +0100
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 1SiIme-00027n-CW;
	Sat, 23 Jun 2012 05:21:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiImd-0008UT-VL;
	Sat, 23 Jun 2012 06:21:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13352-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 06:21:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13352: 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 13352 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13352/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  32034d1914a6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=836db8c4b9f9
+ . 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 836db8c4b9f9
+ branch=xen-unstable
+ revision=836db8c4b9f9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 836db8c4b9f9 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 27 changesets with 49 changes to 39 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 12:19:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 12:19: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 1SiPIX-0000v3-7D; Sat, 23 Jun 2012 12:18: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 1SiPIW-0000uy-4u
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 12:18:40 +0000
Received: from [85.158.139.83:41860] by server-9.bemta-5.messagelabs.com id
	57/82-01069-F14B5EF4; Sat, 23 Jun 2012 12:18:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340453917!29129593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0MzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20627 invoked from network); 23 Jun 2012 12:18:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 12:18:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,462,1336348800"; d="scan'208";a="13181470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jun 2012 12:18:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 13:18:37 +0100
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 1SiPIS-0004xO-JA;
	Sat, 23 Jun 2012 12:18:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiPIR-0004ot-Tj;
	Sat, 23 Jun 2012 13:18:36 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13354-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 13:18:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13354: 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 13354 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13354/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 13352

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13352

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  836db8c4b9f9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 12:19:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 12:19: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 1SiPIX-0000v3-7D; Sat, 23 Jun 2012 12:18: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 1SiPIW-0000uy-4u
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 12:18:40 +0000
Received: from [85.158.139.83:41860] by server-9.bemta-5.messagelabs.com id
	57/82-01069-F14B5EF4; Sat, 23 Jun 2012 12:18:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340453917!29129593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0MzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20627 invoked from network); 23 Jun 2012 12:18:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 12:18:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,462,1336348800"; d="scan'208";a="13181470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jun 2012 12:18:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 13:18:37 +0100
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 1SiPIS-0004xO-JA;
	Sat, 23 Jun 2012 12:18:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiPIR-0004ot-Tj;
	Sat, 23 Jun 2012 13:18:36 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13354-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 13:18:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13354: 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 13354 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13354/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 13352

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13352

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  836db8c4b9f9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 15:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 15: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 1SiSR6-0001vN-Sb; Sat, 23 Jun 2012 15:39:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SiSR6-0001vI-1L
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 15:39:44 +0000
Received: from [85.158.139.83:62901] by server-3.bemta-5.messagelabs.com id
	A8/5F-03367-E33E5EF4; Sat, 23 Jun 2012 15:39:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340465982!26423202!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25385 invoked from network); 23 Jun 2012 15:39:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Jun 2012 15:39:42 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79082791; Sat, 23 Jun 2012 17:39:41 +0200
Message-ID: <1340465972.5558.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>
Date: Sat, 23 Jun 2012 17:39:32 +0200
In-Reply-To: <osstest-13339-mainreport@xen.org>
References: <osstest-13339-mainreport@xen.org>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13339: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9129667637623988819=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============9129667637623988819==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-wwcumhVNhl39x2+9QqZA"


--=-wwcumhVNhl39x2+9QqZA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2012-06-23 at 00:37 +0100, xen.org wrote:=20
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs.=
 13025
>=20
Ok, that was expected as I guess this run benefited from Ian's patch
which fixed the "wrong domid" issue, but not by mine one fixing the NULL
pointer dereference in the hypervisor the above caused (although I call
it to be sedf's fault! :-P)

Also, it seems the build for flight 13352
(<osstest-13352-mainreport@xen.org>) included both, and the tests pass
(http://www.chiark.greenend.org.uk/~xensrcts/logs/13352/test-amd64-amd64-xl=
-sedf/info.html) in that case. :-)

> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs.=
 13025
>
As above.

> test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like =
13025
>=20
But what about this? Have we broken migration now?!?! :-O

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-wwcumhVNhl39x2+9QqZA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/l4zUACgkQk4XaBE3IOsQbNQCdG4OaigJqUji2S+lGRQYT6OuV
vJMAn0BJXZBdrA/bfyARNazJR5eai9Qh
=ErPB
-----END PGP SIGNATURE-----

--=-wwcumhVNhl39x2+9QqZA--



--===============9129667637623988819==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9129667637623988819==--



From xen-devel-bounces@lists.xen.org Sat Jun 23 15:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 15: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 1SiSR6-0001vN-Sb; Sat, 23 Jun 2012 15:39:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SiSR6-0001vI-1L
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 15:39:44 +0000
Received: from [85.158.139.83:62901] by server-3.bemta-5.messagelabs.com id
	A8/5F-03367-E33E5EF4; Sat, 23 Jun 2012 15:39:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340465982!26423202!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25385 invoked from network); 23 Jun 2012 15:39:42 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Jun 2012 15:39:42 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79082791; Sat, 23 Jun 2012 17:39:41 +0200
Message-ID: <1340465972.5558.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>
Date: Sat, 23 Jun 2012 17:39:32 +0200
In-Reply-To: <osstest-13339-mainreport@xen.org>
References: <osstest-13339-mainreport@xen.org>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13339: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9129667637623988819=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============9129667637623988819==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-wwcumhVNhl39x2+9QqZA"


--=-wwcumhVNhl39x2+9QqZA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2012-06-23 at 00:37 +0100, xen.org wrote:=20
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs.=
 13025
>=20
Ok, that was expected as I guess this run benefited from Ian's patch
which fixed the "wrong domid" issue, but not by mine one fixing the NULL
pointer dereference in the hypervisor the above caused (although I call
it to be sedf's fault! :-P)

Also, it seems the build for flight 13352
(<osstest-13352-mainreport@xen.org>) included both, and the tests pass
(http://www.chiark.greenend.org.uk/~xensrcts/logs/13352/test-amd64-amd64-xl=
-sedf/info.html) in that case. :-)

> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs.=
 13025
>
As above.

> test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like =
13025
>=20
But what about this? Have we broken migration now?!?! :-O

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-wwcumhVNhl39x2+9QqZA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/l4zUACgkQk4XaBE3IOsQbNQCdG4OaigJqUji2S+lGRQYT6OuV
vJMAn0BJXZBdrA/bfyARNazJR5eai9Qh
=ErPB
-----END PGP SIGNATURE-----

--=-wwcumhVNhl39x2+9QqZA--



--===============9129667637623988819==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9129667637623988819==--



From xen-devel-bounces@lists.xen.org Sat Jun 23 18:43:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 18: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 1SiVIQ-0005XA-Au; Sat, 23 Jun 2012 18:42:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SiVIP-0005X5-FV
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 18:42:57 +0000
Received: from [85.158.143.35:36192] by server-2.bemta-4.messagelabs.com id
	2D/FB-17938-03E06EF4; Sat, 23 Jun 2012 18:42:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340476975!14562504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0MzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26857 invoked from network); 23 Jun 2012 18:42:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 18:42:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="13182537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jun 2012 18:42:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 19:42:55 +0100
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 1SiVIM-00078J-Ox;
	Sat, 23 Jun 2012 18:42:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiVIM-0004Ww-Hs;
	Sat, 23 Jun 2012 19:42:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13356-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 19:42:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13356: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13356 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13356/

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. 13100

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 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-i386-i386-win           16 leak-check/check             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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
baseline version:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 18:43:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 18: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 1SiVIQ-0005XA-Au; Sat, 23 Jun 2012 18:42:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SiVIP-0005X5-FV
	for xen-devel@lists.xensource.com; Sat, 23 Jun 2012 18:42:57 +0000
Received: from [85.158.143.35:36192] by server-2.bemta-4.messagelabs.com id
	2D/FB-17938-03E06EF4; Sat, 23 Jun 2012 18:42:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340476975!14562504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0MzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26857 invoked from network); 23 Jun 2012 18:42:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 18:42:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="13182537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jun 2012 18:42:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 23 Jun 2012 19:42:55 +0100
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 1SiVIM-00078J-Ox;
	Sat, 23 Jun 2012 18:42:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SiVIM-0004Ww-Hs;
	Sat, 23 Jun 2012 19:42:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13356-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Jun 2012 19:42:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13356: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13356 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13356/

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. 13100

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 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-i386-i386-win           16 leak-check/check             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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
baseline version:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 19:43:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 19:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SiWDw-0006Bw-Og; Sat, 23 Jun 2012 19:42:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SiWDu-0006Bp-HT
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 19:42:22 +0000
Received: from [85.158.138.51:14695] by server-3.bemta-3.messagelabs.com id
	0C/D8-26490-D1C16EF4; Sat, 23 Jun 2012 19:42:21 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340480539!29221602!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1NDAyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29557 invoked from network); 23 Jun 2012 19:42:20 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 19:42:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340480540; x=1372016540;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:content-transfer-encoding:in-reply-to;
	bh=v4C9ubJLRelZKacLOGadm2ArTqQwWm0TQJ2UgvE0IFg=;
	b=HBWBu6Hton91MZASIf86YYld0CYHljw36g1B3kWZc5lUZUJpT7Yhf/lN
	IsH4O8bUw+zX4btEAjmVET/zJJdP/w==;
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="399404609"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2012 19:42:17 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-51-220.sea3.amazon.com [10.50.51.220])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with SMTP id
	q5NJgEIu023046; Sat, 23 Jun 2012 19:42:15 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Sat, 23 Jun 2012 12:42:14 -0700
Date: Sat, 23 Jun 2012 12:42:14 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120623194214.GF2640@US-SEA-R8XVZTX>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20448.49637.38489.246434@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCBKdW4gMTksIDIwMTIgYXQgMTE6MTY6MDVBTSAtMDcwMCwgSWFuIEphY2tzb24gd3Jv
dGU6Cj4gWy4uLl0KClRoYW5rIHlvdSBmb3Igd3JpdGluZyBhbGwgdGhpcyB1cCwgYW5kIGZvciBh
bGwgb2YgeW91ciBlZmZvcnRzIGFzIHBhcnQKb2YgWGVuLm9yZyBhbmQgdGhlIHNlY3VyaXR5IHJl
c3BvbnNlIHRlYW0sIElhbi4gWW91IGhhdmUgYWxyZWFkeQpjb3ZlcmVkIG1hbnkgb2YgbXkgY29u
Y2VybnMsIHN1Y2ggYXMgYXZvaWRpbmcgaG9saWRheXMuCgo+IFRoZSBiaWcgaXNzdWVzCj4gLS0t
LS0tLS0tLS0tLS0KPgo+IDEuIFB1cnBvc2Ugb2YgdGhlIHByb2Nlc3MKPgo+IFRoZSBmaXJzdCBw
b2ludCBpcyB0aGF0IHdlIHRoaW5rIHRoZSBzZWN1cml0eSB2dWxuZXJhYmlsaXR5IHByb2Nlc3MK
PiBkb2N1bWVudCBzaG91bGQgaGF2ZSBhbiBleHBsYW5hdGlvbiBvZiB3aGF0IGl0cyBnb2FscyBh
cmUuICBUaGlzIHdvdWxkCj4gaGF2ZSBncmVhdGx5IGFzc2lzdGVkIHVzIHdoZW4gbWFraW5nIHNv
bWUgb2YgdGhlIG1vcmUgZGlmZmljdWx0Cj4gZGVjaXNpb25zLgoKVGhlIHNlY3VyaXR5IHZ1bG5l
cmFiaWxpdHkgcHJvY2VzcyBkb2N1bWVudCBzaG91bGQgbW9zdCBkZWZpbml0ZWx5CmVuY2Fwc3Vs
YXRlIGJvdGggZXhwbGljaXQgZ3VpZGFuY2UgYW5kIGJyb2FkIHRlbmV0cyB0aGF0IGNhbiBiZSB1
c2VkCnRvIG1ha2UgdG91Z2ggY2FsbHMuIEkgdGhpbmsgdGhhdCB0aGVzZSBzaG91bGQgYmUgZXhw
bGljaXRseSBjYWxsZWQKb3V0IGluIGZyb250IG1hdHRlciBhcyBhbiBldm9sdXRpb25hcnkgcGFy
dCBvZiB0aGUgcHJvY2Vzcy4gVGVuZXRzCnNob3VsZCBhbHdheXMgYmUgb3BlbiB0byBiZWluZyBy
ZWZpbmVkIG9yIHJlZGVmaW5lZCBhcyBYZW4ub3JnCnByb2plY3RzIGdyb3cgYW5kIHVzYWdlIHNo
aWZ0cy4KCj4gSW4gcGFydGljdWxhciwgaWYgdGhlIHByb2Nlc3MgZXhwbGFpbmVkIGl0cyBwdXJw
b3NlLCB3ZSB3b3VsZCBiZSBhYmxlCj4gdG8gcmVmZXIgdG8gdGhlIHNwaXJpdCBvZiB0aGUgZG9j
dW1lbnQgd2hlbiBtYWtpbmcgaW50ZXJwcmV0YXRpb24KPiBkZWNpc2lvbnMgb3IgZGVhbGluZyB3
aXRoIGlzc3VlcyBub3QgY2xlYXJseSByZXNvbHZlZCBieSB0aGUgZG9jdW1lbnQuCj4KPiBJbiB0
aGlzIGNvbnRleHQgd2UgbmVlZCB0byBkZWNpZGUgd2hldGhlcjoKPiAgKGEpIHRoZSBwcmVkaXNj
bG9zdXJlIGFycmFuZ2VtZW50cyBhcmUganVzdCB0aGVyZSBzbyB0aGF0Cj4gICAgICBvcmdhbmlz
YXRpb25zIGNhbiBiYWNrcG9ydCBwYXRjaGVzLCBkZXZlbG9wIGFuZCB0ZXN0IHVwZGF0ZWQKPiAg
ICAgIHZlcnNpb25zLCBhbmQgc28gZm9ydGg7Cj4gIChiKSB0aGUgYXJyYW5nZW1lbnRzIGFyZSBh
bHNvIGludGVuZGVkIHRvIGFsbG93IG9wZXJhdG9ycyB0byBkZXBsb3kKPiAgICAgIGZpeGVkIHZl
cnNpb25zLgoKSSB0aGluayB0aGF0IHRoZXJlIG1heSBiZSBvdGhlciBhc3BlY3RzIG9mIHRoZSBw
cmVkaXNjbG9zdXJlIHBlcmlvZAp0aGF0IGRlc2VydmUgZXhwbGljaXQgY2FsbG91dHMsIHNvIEkg
ZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIGhlbHBmdWwgdG8KZnJhbWUgdGhpcyBkaXNjdXNzaW9uIGlu
IHBhcnRpY3VsYXIgY29udGV4dCB0aGF0IG9ubHkgZ2l2ZXMgdXMgY2hvaWNlcwooYSkgb3IgKGIp
LiBGb3IgZXhhbXBsZSwgd2UgbWlnaHQgd2FudCB0byBleHBsaWNpdGx5IGNhbGwgb3V0IHRoZQpw
dXJwb3NlIG9mIHRoZSBwcmVkaXNjbG9zdXJlIHBlcmlvZCB0byBpbmNsdWRlIGZ1cnRoZXIgdGVz
dGluZyBhbmQKdmFsaWRhdGlvbiBvZiBhIGZpeCBmcm9tIGEgZ3JvdXAgbW9yZSBicm9hZCB0aGFu
IHRoZSBzZWN1cml0eSByZXNwb25zZQp0ZWFtLgoKQnV0IHRha2luZyBhIHN0ZXAgYmFjaywgSSBw
cm9wb3NlIHRoYXQgYSBjb3JlIHRlbmV0IG9mIHRoZSBzZWN1cml0eQpyZXNwb25zZSBwcm9jZXNz
IHNob3VsZCBiZSB0byByZWR1Y2UgZGF5cy1vZi1yaXNrIGZvciBhbGwgY29uc3VtZXJzIG9mClhl
bi5vcmcgcHJvamVjdHMsIHdoZXRoZXIgZGlyZWN0IG9yIGluZGlyZWN0LCB0byB6ZXJvLiBEYXlz
LW9mLXJpc2sKY2FuIGJlIGZ1enp5IHRvIG1lYXN1cmUsIHNvIHdlIGNvdWxkIGRlZmluZSB0aGlz
IGFzIHRoZSBudW1iZXIgb2YgZGF5cwpiZXR3ZWVuIHdoZW4gYSBzZWN1cml0eSBwcm9ibGVtIGlz
IHB1YmxpY2x5IGtub3duIChlLmcuIHRocm91Z2gKZXZpZGVuY2Ugb2YgZXhwbG9pdGF0aW9uIGlu
IHRoZSB3aWxkIG9yIGEgcHVibGljIGFubm91bmNlbWVudCkgYW5kCndoZW4gdGhlIHByb2JsZW0g
aGFzIGJlZW4gYWRkcmVzc2VkIHN1Y2ggdGhhdCB0aGVyZSBpcyBubyBsb25nZXIgYW55CnJpc2sg
KGUuZy4sIHRocm91Z2ggYSBYZW4gY29uc3VtZXIgZGVwbG95aW5nIGEgZml4ZWQgdmVyc2lvbiBm
cm9tIGEKdmVuZG9yIG9yIGFuIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyIGRvaW5nIHRoZSBzYW1l
IG9uIGEgY29uc3VtZXLigJlzCmJlaGFsZi4pCgpUaGlzIG1lYXN1cmUgbWlnaHQgbm90IG1hdGNo
IHVwIHBlcmZlY3RseSB3aXRoIHR5cGljYWwgZGF5cy1vZi1yaXNrCmFzc2Vzc21lbnRzIHRoYXQg
c29tZSBzb2Z0d2FyZSB2ZW5kb3JzIG1ha2UuIEZvciBleGFtcGxlLCBSZWQgSGF0Cm1lYXN1cmVz
IGRheXMtb2YtcmlzayBmcm9tIHRoZSBkYXRlIG9mIHB1YmxpYyBkaXNjbG9zdXJlIHRvIHRoZSBk
YXRlCnRoYXQgYSBmaXhlZCBwYWNrYWdlIGlzIG1hZGUgYXZhaWxhYmxlLiBUaGV5IHB1Ymxpc2gg
bWV0cmljcyBvbiB0aGlzLAplLmcuOgogIGh0dHA6Ly93d3cucmVkaGF0LmNvbS9zZWN1cml0eS9k
YXRhL21ldHJpY3Mvc3VtbWFyeS1yaGVsNi1jcml0aWNhbC5odG1sCgo+IE9mIGNvdXJzZSB0aGlz
IG5lZWRzIHRvIGRlYWwgY2xlYXJseSB3aXRoIHRoZSBjb21tb24gc3RpdHVhdGlvbiBvZiBhbgo+
IG9yZ2FuaXNhdGlvbiBydW5uaW5nIFhlbiB3aGljaCBpcyBhIGRpcmVjdCBjb25zdW1lciBvZiBY
ZW4ub3JnIHNvdXJjZQo+IGNvZGUuCgpJbmRlZWQuIElmIGEgZ29hbCBvZiB0aGUgcHJvY2VzcyBp
cyB0byByZWR1Y2UgZGF5cy1vZi1yaXNrIGZvciBhbGwKY29uc3VtZXJzIG9mIFhlbi5vcmcgcHJv
amVjdHMgdG8gemVybywgY29vcmRpbmF0aW5nIHBhY2thZ2UgdXBkYXRlcwpvbmx5IGZyb20gc29m
dHdhcmUgdmVuZG9ycyB3aWxsIG5vdCBhY2hpZXZlIGl0LgoKWy4uLl0KPgo+IDIuIEV4dGVuc2lv
biBvZiBlbWJhcmdvIGRhdGVzCj4KPiBUaGUgbW9zdCBjb250cm92ZXJzaWFsIGRlY2lzaW9uIHdh
cyB3aGV0aGVyIHRoZSBlbWJhcmdvIGRhdGUgbWlnaHQgYmUKPiBleHRlbmRlZCBhZnRlciBpdCBo
YWQgb3JpZ2luYWxseSBiZWVuIHNldC4gIFdlIHJlc2lzdGVkIHRoZXNlCj4gc3VnZ2VzdGlvbnMs
IHJlZmVycmluZyB0byB0aGUgcHJvY2VzcyBkb2N1bWVudCwgd2hpY2ggZG9lcyBub3QKPiBjb250
ZW1wbGF0ZSBleHRlbmRpbmcgdGhlIGRpc2Nsb3N1cmUgcGVyaW9kLiAgSG93ZXZlciwgd2hlbiBh
Cj4gcHJlZGlzY2xvc3VyZSBsaXN0IG1lbWJlciBwcmVzc3VyZWQgdGhlIGRpc2NvdmVyZXIgaW50
byByZXF1ZXN0aW5nIGFuCj4gZXh0ZW5zaW9uLCB3ZSBmZWx0IHRoZSBiZXN0IGludGVycHJldGF0
aW9uIG9mIHRoZSBwcm9jZXNzIGRvY3VtZW50Cj4gcmVxdWlyZWQgdXMgdG8gYWNxdWllc2NlLgo+
Cj4gU3BlY2lmaWNhbGx5LCBvZiBjb3Vyc2UsIHdlIGFzIGEgdGVhbSB3b3VsZCBsaWtlIGNsZWFy
ZXIgZ3VpZGFuY2UgZnJvbQo+IHRoZSBwcm9jZXNzIGFib3V0IHdoZXRoZXIsIGFuZCBpZiBzbyB1
bmRlciB3aGF0IGNpcmN1bXN0YW5jZXMsIGEKPiBwcmVkaXNjbG9zdXJlIHBlcmlvZCBzaG91bGQg
YmUgZXh0ZW5kZWQuCgpJIHRoaW5rIHRoYXQgdGhlIGlzc3VlIG9mIGVzdGFibGlzaGluZyBhbmQg
Y2hhbmdpbmcgdGhlIGVtYmFyZ28gZW5kCmRhdGUsIHdoZXRoZXIgZXh0ZW5kaW5nIG9yIHNob3J0
aW5nLCBkZXNlcnZlcyBhIGxvdCBvZiBkaXNjdXNzaW9uLgpJdCdzIGdvb2QgdGhhdCB3ZSdyZSBu
b3QgbGltaXRpbmcgdGhlIGRpc2N1c3Npb24gb25seSB0byBleHRlbmRpbmcKZXh0ZW5kaW5nIGRp
c2Nsb3N1cmUgZGF0ZXMsIGJ1dCBhbHNvIGVzdGFibGlzaGluZyB0aGUgZGVmYXVsdCB0aW1lbGlu
ZQphcyB5b3UgY2FsbCBvdXQgaW4gNCBiZWxvdy4gIEkgdGhpbmsgdGhhdCBzb21lIGd1aWRlbGlu
ZXMgZm9yCmVzdGFibGlzaGluZyBhbiBhcHByb3ByaWF0ZSB0aW1lbGluZSBjYW4gYWRkcmVzcyBw
cm9ibGVtcyB0aGF0IGNhdXNlCmV4dGVuc2lvbiByZXF1ZXN0cy4KClRoZSBkZWZhdWx0IGRpc2Ns
b3N1cmUgcGVyaW9kLCBpZiBhZ3JlZWFibGUgdG8gdGhlIGRpc2NvdmVyZXIsIGlzCmN1cnJlbnRs
eSB0aHJlZSB3ZWVrczoKICAgMS4gT25lIHdvcmtpbmcgd2VlayBiZXR3ZWVuIG5vdGlmaWNhdGlv
biBhcnJpdmluZyBhdCBzZWN1cml0eUB4ZW4KICAgICAgYW5kIHRoZSBpc3N1ZSBvZiBvdXIgb3du
IGFkdmlzb3J5IHRvIG91ciBwcmVkaXNjbG9zdXJlIGxpc3QuIFdlCiAgICAgIHdpbGwgdXNlIHRo
aXMgdGltZSB0byBnYXRoZXIgaW5mb3JtYXRpb24gYW5kIHByZXBhcmUgb3VyCiAgICAgIGFkdmlz
b3J5LCBpbmNsdWRpbmcgcmVxdWlyZWQgcGF0Y2hlcy4KICAgMi4gVHdvIHdvcmtpbmcgd2Vla3Mg
YmV0d2VlbiBpc3N1ZSBvZiBvdXIgYWR2aXNvcnkgdG8gb3VyCiAgICAgIHByZWRpc2Nsb3N1cmUg
bGlzdCBhbmQgcHVibGljYXRpb24uCgpUaGlzIG1heSBiZSBhIHJlYXNvbmFibGUgc3RhcnRpbmcg
cG9pbnQgZm9yIGdlbmVyYWwgaXNzdWVzLCBidXQgSQp0aGluayB0aGF0IHRoZSBvdmVyYWxsIGlt
cGFjdCBhbmQgY29tcGxleGl0eSBvZiBhbiBpc3N1ZSBuZWVkcyB0byBiZQpjb25zaWRlcmVkIHdo
ZW4gZXN0YWJsaXNoaW5nIGEgdGltZWxpbmUuCgpGb3IgZXhhbXBsZSwgdGhlIG9DRVJUIERpc2Ns
b3N1cmUgUG9saWN5IGdpdmVzIHRoaXMgZ3VpZGFuY2U6CiAgaHR0cHM6Ly93d3cub2NlcnQub3Jn
L2Rpc2Nsb3N1cmVfcG9saWN5Lmh0bWwKIiIiCiAgIFRoZSBmb2xsb3dpbmcgdGltZSBmcmFtZXMg
cmVndWxhdGUgb0NFUlQgZW1iYXJnbyBwcm9wb3NhbHM6CgogICAtIDcgZGF5cywgaW4gY2FzZSB0
aGUgaXNzdWUgaXMgYWxyZWFkeSB3ZWxsIG5hcnJvd2VkIGRvd24gYW5kCiAgICAgdGVzdGVkLCBy
ZXF1aXJpbmcgdHJpdmlhbCBjb25maWd1cmF0aW9uIGFuZC9vciBjb2RlIGNoYW5nZQoKICAgLSAx
NCBkYXlzLCBzdGFuZGFyZCBlbWJhcmdvIGZvciBtb3N0IGNhc2VzCgogICAtIDMwIGRheXMsIGlu
IGNhc2Ugb2YgY3JpdGljYWwgYW5kIGNvbXBsZXggdnVsbmVyYWJpbGl0aWVzCiAgICAgKGV4YW1w
bGUsIHRyaXZpYWwgZXhwbG9pdGF0aW9uIG9mIGFkbWluaXN0cmF0aXZlIHByaXZpbGVnZXMgb24g
YQogICAgIHN0YXRpYyBsaWJyYXJ5IGFmZmVjdGluZyBhIGxhcmdlIG51bWJlciBvZiBwYWNrYWdl
cyksIGFuZCB3aXRoCiAgICAgdGhlIGFncmVlbWVudCBvZiBhbGwgcGFydGllcwoKICAgLSB1bmRl
ciBleHRyZW1lbHkgZXhjZXB0aW9uYWwgY2lyY3Vtc3RhbmNlcywgaWYgdGhlIG9DRVJUIFRlYW0g
YW5kCiAgICAgYWxsIHRoZSBwYXJ0aWVzIGludm9sdmVkIGZlZWwgdGhlIG5lZWQgZm9yIGxvbmdl
ciB0aW1lLCBhIDIKICAgICBtb250aHMgZW1iYXJnbyBjYW4gYmUgYXBwbGllZCwgaW4gdGhpcyBj
YXNlIHdlIHdvdWxkIGNsZWFybHkKICAgICBkb2N1bWVudCB0aGUgZGVjaXNpb24gZm9yIHB1Ymxp
YyByZXZpZXcKCiAgIC0gaW4gYW55IGNpcmN1bXN0YW5jZSByZXBvcnRlciBwcmVmZXJlbmNlIHdp
bGwgYWx3YXlzIGJlIGhvbm91cmVkCiAgICAgaW4gY2FzZSBhIGpvaW50IGFncmVlbWVudCBpcyBu
b3QgcmVhY2hlZCwgYXMgb0NFUlQgd291bGQgYmUKICAgICBhbnl3YXkgdW5hYmxlIHRvIGZvcmNl
IGl0cyBlbWJhcmdvCiIiIgoKVGhlIENFUlQgcHJvY2VzcyBkZWZhdWx0cyB0byA0NSBkYXlzLCB3
aXRoIGd1aWRhbmNlIHRvIHNob3J0ZW4gdGhlCnJlbGVhc2Ugc2NoZWR1bGUgaWYgdGhlcmUncyBl
dmlkZW5jZSBvZiBhY3RpdmUgZXhwbG9pdGF0aW9uOgogaHR0cDovL3d3dy5jZXJ0Lm9yZy9rYi92
dWxfZGlzY2xvc3VyZS5odG1sCiIiIgogICBROiBXaWxsIGFsbCB2dWxuZXJhYmlsaXRpZXMgYmUg
ZGlzY2xvc2VkIHdpdGhpbiA0NSBkYXlzPwoKICAgQTogTm8uIFRoZXJlIG1heSBvZnRlbiBiZSBj
aXJjdW1zdGFuY2VzIHRoYXQgd2lsbCBjYXVzZSB1cyB0bwogICAgICBhZGp1c3Qgb3VyIHB1Ymxp
Y2F0aW9uIHNjaGVkdWxlLiBUaHJlYXRzIHRoYXQgYXJlIGVzcGVjaWFsbHkKICAgICAgc2VyaW91
cyBvciBmb3Igd2hpY2ggd2UgaGF2ZSBldmlkZW5jZSBvZiBleHBsb2l0YXRpb24gd2lsbAogICAg
ICBsaWtlbHkgY2F1c2UgdXMgdG8gc2hvcnRlbiBvdXIgcmVsZWFzZSBzY2hlZHVsZS4gVGhyZWF0
cyB0aGF0CiAgICAgIHJlcXVpcmUgImhhcmQiIGNoYW5nZXMgKGNoYW5nZXMgdG8gc3RhbmRhcmRz
LCBjaGFuZ2VzIHRvIGNvcmUKICAgICAgb3BlcmF0aW5nIHN5c3RlbSBjb21wb25lbnRzKSB3aWxs
IGNhdXNlIHVzIHRvIGV4dGVuZCBvdXIKICAgICAgcHVibGljYXRpb24gc2NoZWR1bGUuCiIiIgoK
Rm9yIGFub3RoZXIgdGFrZSwgdGhlIFdlYktpdCBkZWZhdWx0IGVtYmFyZ28gcGVyaW9kLCBmb3Vu
ZCBoZXJlOgpodHRwOi8vd3d3LndlYmtpdC5vcmcvc2VjdXJpdHkvLCBpcyA2MCBkYXlzIHVubGVz
cyBhbGwgdmVuZG9ycyBoYXZlCmFkZHJlc3NlZCBhbiBpc3N1ZSwgaW4gd2hpY2ggY2FzZSBhbiBl
bWJhcmdvIG1heSBiZSBsaWZ0ZWQgc29vbmVyLgoKPiAzLiBEZWNpc2lvbm1ha2luZwo+Cj4gSXQg
d2FzIHN1Z2dlc3RlZCB0byB1cyBzZXZlcmFsIHRpbWVzLCBhbmQgaW5kZWVkIHNlZW1lZCB0byBi
ZSByZWdhcmRlZAo+IGJ5IHNvbWUgYXMgYW4gdW5kZXJseWluZyBwcmluY2lwbGUsIHRoYXQgdGhl
IHByZWRpc2Nsb3N1cmUgbGlzdAo+IG1lbWJlcnMgc2hvdWxkIGJlIG1ha2luZyB0aGUgZGVjaXNp
b25zIGFib3V0IGRpc2Nsb3N1cmUgc2NoZWR1bGUgZXRjLgo+Cj4gVGhlIHF1ZXN0aW9uIG9mIHdo
byBpcyB0byBtYWtlIHRoZSBkZWNpc2lvbnMsIGFuZCBvbiB3aGF0IGJhc2lzLCBuZWVkcwo+IHRv
IGJlIGFkZHJlc3NlZC4KCkkgZG8gbm90IHRoaW5rIHRoYXQgaXQgaXMgd2lzZSBmb3IgdGhlIHBv
bGljeSB0byBlc3RhYmxpc2ggZGVjaXNpb24KbWFraW5nIGJ5IGNvbW1pdHRlZS4gQWxsIGNvbmNl
cm5lZCBwYXJ0aWVzIHNob3VsZCB2b2ljZSBhbnkgY29uY2VybnMKcmVnYXJkaW5nIHRoZSBzZWN1
cml0eSByZXNwb25zZSBwcm9jZXNzIHNvIHRoYXQgdGhlIHJlc3VsdGluZyBkb2N1bWVudAp3aWxs
IGd1aWRlIHRob3NlIG1ha2luZyBkZWNpc2lvbnMuCgpUbyBwdXQgaXQgYW5vdGhlciB3YXksIHBy
ZWRpc2Nsb3N1cmUgbGlzdCBtZW1iZXJzIChhbmQgYW55IG90aGVyCmludGVyZXN0ZWQgcGFydHkp
IHNob3VsZCBtYWtlIGRlY2lzaW9ucyBvbiBob3cgdGhleSdkIGxpa2UgZm9yCmRpc2Nsb3N1cmUg
c2NoZWR1bGVzIHRvIGJlIGVzdGFibGlzaGVkIG5vdywgYW5kIHRoZSByYXRpZmllZCBwcm9jZXNz
CnNob3VsZCBhY3QgYXMgYSBwcm94eSB3aGVuIHNwZWNpZmljIHZ1bG5lcmFiaWxpdGllcyBhcmUg
aGFuZGxlZC4KCkluIHRoZSBpbnRlcmVzdCBvZiB0cmFuc3BhcmVuY3ksIHRob3NlIG1ha2luZyBk
ZWNpc2lvbnMsIGkuZS4gdGhlCm1lbWJlcnMgb2YgdGhlIHNlY3VyaXR5IHJlc3BvbnNlIHRlYW0g
YW5kIGFueSBvdGhlciBwZXJzb24gb3IgZW50aXR5Cm9uIHRoZSBzZWN1cml0eUB4ZW4ub3JnIGFs
aWFzLCBzaG91bGQgYmUgZGlzY2xvc2VkIGFuZCBkb2N1bWVudGVkIGluCnRoZSBwcm9jZXNzIGRv
Y3VtZW50LgoKVWx0aW1hdGVseSBJIHRoaW5rIHRoYXQsIGFzIGlzIGNvbW1vbiBwcmFjdGljZSBp
biBjb29yZGluYXRlZAp2dWxuZXJhYmlsaXR5IGRpc2Nsb3N1cmUsIHRoZSBkaXNjb3ZlcmVyIGlz
IHRoZSB1bHRpbWF0ZQpkZWNpc2lvbi1tYWtlciBhcyB0byB3aGF0IGluZm9ybWF0aW9uIGlzIGRp
c2Nsb3NlZCBhbmQgd2hlbiBpdCBpcwpkaXNjbG9zZWQuIFRoZSB4ZW5Ac2VjdXJpdHkgdGVhbSBt
YWtlcyBkZWNpc2lvbnMgcGVyIHRoZSBndWlkYW5jZSBpbgp0aGUgcHJvY2VzcyBhbmQgdGhlIGZh
Y3RzIGF0IGhhbmQuCgo+IDQuIExlbmd0aCBvZiAoZGVmYXVsdCkgcHJlZGlzY2xvc3VyZSBwZXJp
b2QKPgpbLi4uXQoKU2VlIGNvbW1lbnRzIGFib3ZlLgoKPiA1LiBDcml0ZXJpYSBmb3IgcHJlZGlz
Y2xvc3VyZSBsaXN0IG1lbWJlcnNoaXAKPgpbLi4uXQo+IFdlIG5lZWQgdG8gY2xhcmlmeSB3aGV0
aGVyIHVwc3RyZWFtcyBhbmQgaGFyZHdhcmUgdmVuZG9ycyBzaG91bGQgYmUgb24KPiB0aGUgcHJl
ZGlzY2xvc3VyZSBsaXN0LiAgQ3VycmVudGx5IHdlIGhhdmUgb25lIG5vdGFibGUgdXBzdHJlYW0g
dmVuZG9yCj4gb24gdGhhdCBsaXN0Lgo+Cj4gT3VyIHByZWxpbWluYXJ5IHZpZXcgaXMgdGhhdCB0
aGUgcHJlZGlzY2xvc3VyZSBsaXN0IHNob3VsZCBiZSB1c2VkIGZvcgo+IGRvd25zdHJlYW0gbm90
aWZpY2F0aW9ucy4gIFVwc3RyZWFtcywgaW5jbHVkaW5nIGhhcmR3YXJlCj4gbWFudWZhY3R1cmVy
cywgc2hvdWxkIGJlIGJyb3VnaHQgaW4gdG8gdGhlIGRpc2Nsb3N1cmUgcHJvY2VzcyBhcwo+IG5l
ZWRlZC4gIEFuZCBhcyBub3RlZCwgb3VyIHByb2Nlc3MgZm9yIG1ha2luZyBzdXJlIHdlIGRvIHRo
YXQgcHJvcGVybHkKPiBuZWVkcyB0byBiZSBmb3JtYWxpc2VkLgoKT3ZlcmFsbCBJIHRoaW5rIHRo
YXQsIGluIGEgY29vcmRpbmF0ZWQgZGlzY2xvc3VyZSByZXNwb25zZSwKaW5mb3JtYXRpb24gc2hv
dWxkIGJlIGRpc3RyaWJ1dGVkIG9uIGEgbmVlZC10by1rbm93IGJhc2lzLgoKWy4uLl0KPiA2LiBT
aGFyaW5nIG9mIGluZm9ybWF0aW9uIGFuZCBjb2RlIGJldHdlZW4gcHJlZGlzY2xvc3VyZSBwYXJ0
aWNpcGFudHMKPgo+IFdlIG5lZWQgdGhlIHByb2Nlc3MgZG9jdW1lbnQgdG8gYmUgY2xlYXJlciBh
Ym91dCB3aGF0IGtpbmRzIG9mCj4gY29tbXVuaWNhdGlvbnMgYXJlIGNvbnRlbXBsYXRlZCBfYmV0
d2Vlbl8gbWVtYmVycyBvZiB0aGUgcHJlZGlzY2xvc3VyZQo+IGxpc3QuCj4KPiBPbmUgcGFydGlj
dWxhciBpc3N1ZSBoZXJlIHdoaWNoIGFsc28gcmVsYXRlcyB0byB0aGUgcHJlZGlzY2xvc3VyZQo+
IG1lbWJlcnNoaXAgY3JpdGVyaWEsIGlzIHdoZXRoZXIgbGFyZ2UgaW5kaXJlY3QgY29uc3VtZXJz
IG9mIFhlbiBzaG91bGQKPiBiZSBvbiB0aGUgcHJlZGlzY2xvc3VyZSBsaXN0IGluIHRoZWlyIG93
biByaWdodC4gIFRoYXQgd291bGQgYWxsb3cKPiB0aGVtIHRvIGRlcGxveSB0aGUgZml4IGJlZm9y
ZSB0aGUgZW1iYXJnbyBkYXRlLiAgSXQgd291bGQgYWxzbyBhbGxvdwo+IHRoZW0gdG8gcHJlcGFy
ZSBmb3IgdGVzdGluZyBhbmQgZGVwbG95bWVudCwgYmVmb3JlIHRoZSBmaXggaXMKPiBhdmFpbGFi
bGUgZnJvbSB0aGVpciB2ZW5kb3IgKHdobyB3b3VsZCBpbiB0aGlzIHNjZW5hcmlvIGFsc28gYmUK
PiBlbnRpdGxlZCB0byBiZSBhIHByZWRpc2Nsb3N1cmUgbGlzdCBtZW1iZXIpLgo+Cj4gSW4gdGhp
cyBjb250ZXh0LCB0aGUgcHJvY2VzcyBuZWVkcyB0byBjbGFyaWZ5IHdoZXRoZXIgdmVuZG9ycyBt
YXkKPiByZWxlYXNlIGZpeGVkIGJpbmFyaWVzIGR1cmluZyB0aGUgcHJlZGlzY2xvc3VyZSBwZXJp
b2QuICBDZXJ0YWlubHkKPiB0aGVzZSBzaG91bGQgbm90IGJlIHJlbGVhc2VkIG90aGVyIHRoYW4g
dG8gcHJlZGlzY2xvc3VyZSBsaXN0IG1lbWJlcnMsCj4gc2luY2UgdGhlIG5hdHVyZSBvZiBhIGJ1
ZyBjYW4gb2Z0ZW4gYnkgZGlzY292ZXJlZCBieSByZXZlcnNlCj4gZW5naW5lZXJpbmcuICBCdXQg
Y2FuIHRoZXkgYmUgcmVsZWFzZWQgdG8gcHJlZGlzY2xvdXNyZSBsaXN0IG1lbWJlcnMgPwoKSW4g
bXkgb3BpbmlvbiwgdGhlcmUgaXMgbGVzcyBkaXN0aW5jdGlvbiBiZXR3ZWVuICJzb2Z0d2FyZSB2
ZW5kb3JzIgphbmQgImxhcmdlIGluZGlyZWN0IGNvbnN1bWVycyBvZiBYZW4iIHRoYW4geW91IHN1
Z2dlc3QuCgo+IE1vcmUgbWlub3IgcG9saWN5IHF1ZXN0aW9ucwo+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+ClsuLi5dCj4gOS4gVnVsbmVyYWJpbGl0eSBwcm9jZXNzIHNjb3BlCj4KPiBX
ZSBuZWVkIHRvIGNsYXJpZnkgdGhlIHNjb3BlIG9mIHRoZSBwcm9jZXNzIGRvY3VtZW50LiAgQ3Vy
cmVudGx5IGl0Cj4gbG9va3MgbGlrZSBpdCBjb3ZlcnMgZXZlcnkgWGVuLm9yZyBwcm9qZWN0Lgo+
Cj4gV2hpbGUgaXQgd291bGQgYmUgYSBuaWNlIGlkZWFsIHRvIHN1cHBvcnQgZXZlcnkgWGVuLm9y
ZyBwcm9qZWN0IHRoaXMKPiB3YXksIGluIHByYWN0aWNlIHRoZSB0ZWFtIGJlaGluZCBzZWN1cml0
eUB4ZW4gZG8gbm90IGhhdmUgdGhlCj4gZXhwZXJ0aXNlIG9yIHJlc291cmNlcyB0byBmaXggcHJv
YmxlbXMgaW4gKHNheSkgWENQLCBvciB0aGUgQVJNIFBWCj4gcG9ydC4gIE91ciBjYXBhYmlsaXR5
IGlzIGNvbmNlbnRyYXRlZCBvbiB0aGUgIlVwc3RyZWFtIFhlbiIgY29kZWJhc2UKPiAoeGVuLSou
aGcgYW5kIGl0cyBzdWItcmVwb3NpdG9yaWVzKSBhbmQgdGhlIFhlbiBzdXBwb3J0IGNvZGUgaW4g
TGludXguCj4KPiBQZXJoYXBzIHRoaXMgY291bGQgYmUgZGVhbHQgd2l0aCBieSBtYWtpbmcgaXQg
Y2xlYXIgdGhhdCBwcm9ibGVtcyBhcmUKPiBoYW5kbGVkIG9uIGEgYmVzdCBlZmZvcnQgYmFzaXMu
CgpJdCB3b3VsZCBzZWVtIHRoYXQgaW4gY2FzZXMgd2l0aCBtYXR1cmUgcHJvamVjdHMsIGFwcHJv
cHJpYXRlCm1haW50YWluZXJzIGFuZCBjb21taXR0ZXJzIHNob3VsZCBiZSBlbmdhZ2VkIGJ5IHNl
Y3VyaXR5QHhlbi5vcmcgdG8KYWRkcmVzcyBwcm9ibGVtcyBhbmQgcHJlcGFyZSBmaXhlcy4gc2Vj
dXJpdHlAeGVuLm9yZyBzaG91bGQsIEkgdGhpbmssCmNvbnRpbnVlIHRvIGNvb3JkaW5hdGUgdGhl
IG92ZXJhbGwgcmVzcG9uc2UuCgpJbiBvcmRlciB0byBncmFkdWF0ZSwgYSBwcm9qZWN0IHNob3Vs
ZCBtYWludGFpbiBzdWZmaWNpZW50IHNwb25zb3JzaGlwCnRvIGFkZHJlc3Mgc2VjdXJpdHkgcHJv
YmxlbXMgaW4gYSB0aW1lbHkgbWFubmVyLiBUaGF0IHNob3VsZCBiZSBwYXJ0Cm9mIHRoZSAiYmFz
aWMgY29uZGl0aW9ucyIgb2YgYmVpbmcgbGFiZWxlZCBhICJtYXR1cmUiIHByb2plY3QuIElmIGEK
bWF0dXJlIHByb2plY3QgZG9lcyBub3QgaGF2ZSBzdWZmaWNpZW50IHNwb25zb3JzaGlwIHRvIGFk
ZHJlc3MKc2VjdXJpdHkgY29uY2VybnMsIGl0IHNob3VsZCBiZSBjYWxsZWQgb3V0IGFuZCBhcmNo
aXZpbmcgdGhlIHByb2plY3QKc2hvdWxkIGJlIGNvbnNpZGVyZWQuCgpUaGUgQXBhY2hlIEluY3Vi
YXRvciBwcm9jZXNzIGhhcyBzb21lIGdvb2QgYWR2aWNlIHRvIHByb2plY3RzIHRoYXQgYXJlCmdy
YWR1YXRpbmc6IGh0dHA6Ly9pbmN1YmF0b3IuYXBhY2hlLm9yZy9ndWlkZXMvZ3JhZHVhdGlvbi5o
dG1sI3NlY3VyaXR5Cgo+IDEwLiBFeHBsb2l0cwo+Cj4gV2UgbmVlZCBhIGNsZWFyIHBvbGljeSBh
Ym91dCByZWxlYXNpbmcgcHJvb2Ygb2YgY29uY2VwdCBleHBsb2l0cyAtCj4gd2hldGhlciwgd2hl
biBhbmQgd2hvIHRvLgoKTGV0J3Mgbm90IGxpbWl0IHRoZSBkaXNjdXNzaW9uIG9ubHkgdG8gUG9D
IGV4cGxvaXQgY29kZS4gVGhlIHBvbGljeQpzaG91bGQgc3BlYWsgdG8gd2hvIGdldHMgYWNjZXNz
IHRvIHNwZWNpZmljIHRlY2huaWNhbCBkZXRhaWxzIG9mIGEKdnVsbmVyYWJpbGl0eSwgYW5kIHdo
ZW4gdGhleSBnYWluIGFjY2Vzcy4KClBhcnRpZXMgdGhhdCBhcmUgKmFjdGl2ZSogaW4gdGhlIGNv
b3JkaW5hdGVkIGRpc2Nsb3N1cmUsIGZvciBleGFtcGxlCmJ5IGJ1aWxkaW5nIHBhdGNoZWQgdmVy
c2lvbnMgb2YgcHJvZHVjdHMgb3Igc2VydmljZXMgYnVpbHQgb24gWGVuLApuZWVkIHRvIGhhdmUg
YWNjZXNzIHRvIGFzIG11Y2ggdGVjaG5pY2FsIGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIGluCm9y
ZGVyIHRvIHZhbGlkYXRlIHRoZSBmaXggYW5kIHRoZWlyIHBvcnRzLiBUaG9zZSB0aGF0IGFyZSBw
YXNzaXZlLCB3aG8KbWF5IGJlIGRlcGxveWluZyBhIHByZS1yZWxlYXNlIGZpeGVkIHZlcnNpb24g
ZnJvbSBhIHZlbmRvciwgZG8gbm90Cm5lZWQgYWNjZXNzIHRvIHRoZXNlIG1hdGVyaWFscy4KClsu
Li5dCj4KPiBMYWN1bmFlIGluIHRoZSBwcm9jZXNzCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+
Cj4gMTIuIEhvbGlkYXlzCj4KPiBUaGUgb3JpZ2luYWwgcGxhbm5lZCBkaXNjbG9zdXJlIGRhdGUs
IDIwMTItMDUtMDEsIHdhcyBhIHB1YmxpYyBob2xpZGF5Cj4gaW4gbWFueSBwbGFjZXMuICBXZSBz
aG91bGQgdHJ5IHRvIGF2b2lkIGhvbGlkYXlzLCBhbmQgRnJpZGF5cy4gIFdlCj4gbmVlZCB0byBk
aXNjdXNzIHdoaWNoIHRlcnJpdG9yaWVzJyBob2xpZGF5cyBzaG91bGQgYmUgY2hlY2tlZCBhbmQg
bWFrZQo+IGEgbGlzdCBmb3IgaW5jbHVzaW9uIGluIHRoZSBwcm9jZXNzLgoKVGhpcyBtYWtlcyBz
ZW5zZSwgYW5kIGlzIHNpbWlsYXIgdG8gb3RoZXIgY29vcmRpbmF0ZWQgcmVzcG9uc2UgZ3JvdXBz
Cmxpa2UgbGludXgtZGlzdHJvc0B2cy5vcGVud2FsbC5vcmcuCgo+IDEzLiBQYXRjaCBkZXZlbG9w
bWVudCBhbmQgcmV2aWV3Cj4KPiBUaGUgcGF0Y2ggZGV2ZWxvcG1lbnQgcHJvY2VzcyBpcyB0b28g
Y2xvc2VkIGFuZCBub3Qgcm9idXN0IGVub3VnaC4KPgo+IFdlIG5lZWQgdG8gYmUgbXVjaCBjbGVh
cmVyIGJvdGggYWJvdXQgdGhlIG5lZWQgZm9yIHNlY3VyaXR5IHBhdGNoZXMgdG8KPiBmaXggdGhp
bmdzIGluIHRoZSBzbWFsbGVzdCwgc2ltcGxlc3QgYW5kIG1vc3QgcmVsaWFibGUgd2F5LCBhbmQg
bm90Cj4gZml4IG9yICJpbXByb3ZlIiBtYXR0ZXJzIGluIHVucmVsYXRlZCB3YXlzLiAgT3VyIGlu
dGVybmFsIGNvZGUgcmV2aWV3Cj4gbmVlZHMgdG8gYmUgbXVjaCBiZXR0ZXIuCj4KPiBXZSBuZWVk
IHRvIGNsYXJpZnkgdGhhdCBvdGhlciBpc3N1ZXMgZGlzY292ZXJlZCBkdXJpbmcgdGhlIGNvdXJz
ZSBvZgo+IGludmVzdGlnYXRpbmcgYSBzZWN1cml0eSBkaXNjbG9zdXJlIHdpbGwgbm90IGJlIHB1
YmxpY2x5IGRpc2N1c3NlZAo+IHdpdGhvdXQgZmlyc3QgY29uc3VsdGluZyB0aGUgWGVuLm9yZyBz
ZWN1cml0eSB0ZWFtLCByZWdhcmRsZXNzIG9mCj4gdGhlaXIgYWN0dWFsIHJlbGF0aW9uc2hpcCB0
byB0aGUgdnVsbmVyYWJpbGl0eSBhdCBoYW5kIG9yIGV4cGVjdGVkCj4gc2VjdXJpdHkgaW1wYWN0
LiAgT3RoZXJ3aXNlIHRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgcmlzayB0aGF0IHN1Y2gKPiBjaGFu
Z2VzIHdpbGwgZHJhdyBhdHRlbnRpb24gdG8gZW1iYXJnb2VkIHByb2JsZW1zLgoKQWxsIG9mIHRo
aXMgbWFrZXMgc2Vuc2UgdG8gbWUuCgo+IEl0IG1heSBiZSB0aGF0IGl0IHdvdWxkIGJlIGEgYmV0
dGVyIGlkZWEgdG8gc2VuZCBvdXQgZWFybGllcgo+IGFkdmlzb3JpZXMgd2l0aG91dCBwYXRjaGVz
IHRvIHRoZSBwcmVkaXNjbG9zdXJlIGxpc3QsIHRvIGVuYWJsZSB0aG9zZQo+IHByZWRpc2Nsb3N1
cmUgbGlzdCBtZW1iZXJzIHdobyB3b3VsZCBsaWtlIHRvIGRvIHNvIHRvIGhlbHAgd2l0aAo+IGRl
dmVsb3BtZW50IGFuZCB0ZXN0aW5nIG9mIHRoZSBwYXRjaGVzLiAgSWYgc28gdGhpcyBuZWVkcyB0
byBiZQo+IGNhdGVyZWQgZm9yLgoKVGhpcyB3b3VsZCBiZSB0cmVtZW5kb3VzbHkgaGVscGZ1bCwg
c28gbG9uZyBhcyBhZGVxdWF0ZSB0ZWNobmljYWwKaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQuCgo+
IDE0LiBFYXJseSBjb25zaWRlcmF0aW9uIG9mIHdoaWNoIG90aGVyIG9yZ2FuaXNhdGlvbnMgdG8g
YnJpbmcgaW4KPgo+IE91ciBwcm9jZXNzIG5lZWRzIHRvIGhhdmUsIHZlcnkgZWFybHkgb24sIGFu
IGV4cGxpY2l0IHN0ZXAgdG8gb2YKPiBkZWNpZGluZyB3aGljaCBvdGhlciBwcm9qZWN0cy9vcmdh
bmlzYXRpb25zIG1heSBhbHNvIGJlIHZ1bG5lcmFibGUgYW5kCj4gbWF5IHRoZXJlZm9yZSBuZWVk
IHRvIGJlIHBhcnQgb2YgdGhlIHNhbWUgZGlzY2xvc3VyZSBwcm9jZXNzLiAgSXQgYWxzbwo+IG5l
ZWRzIHRvIG1ha2Ugc3VyZSB0aGF0IHdlIGFzayBmb3IgYW55IGhlbHAgKGZvciBleGFtcGxlIGZy
b20KPiB1cHN0cmVhbXMgb3IgaGFyZHdhcmUgdmVuZG9ycykgYXMgc29vbiBhcyBwb3NzaWJsZS4K
ClRoZSBleGlzdGluZyBwcm9jZXNzIGhhZCBhIHN0ZXAgZm9yIHRoaXM6CiIiIgogIGQuIElmIHdl
IHRoaW5rIG90aGVyIHNvZnR3YXJlIHN5c3RlbXMgKGZvciBleGFtcGxlLCBjb21wZXRpbmcKICAg
ICBoeXBlcnZpc29yIHN5c3RlbXMpIGFyZSBsaWtlbHkgdG8gYmUgYWZmZWN0ZWQgYnkgdGhlIHNh
bWUKICAgICB2dWxuZXJhYmlsaXR5LCB3ZSB3aWxsIHRyeSB0byBtYWtlIHRob3NlIG90aGVyIHBy
b2plY3RzIGF3YXJlIG9mCiAgICAgdGhlIHByb2JsZW0gYW5kIGluY2x1ZGUgdGhlbSBpbiB0aGUg
YWR2aXNvcnkgcHJlcGFyYXRpb24gcHJvY2Vzcy4KIiIiCgo+IFsuLi5dCgpUaGFuayB5b3UgYWdh
aW4gZm9yIGFjdGluZyBhcyB0aGUgZmFjaWxpdGF0b3IgZm9yIHRoaXMgZGlzY3Vzc2lvbiwgYW5k
Cm1hbnkgdGhhbmtzIHRvIGV2ZXJ5b25lIHdobyB3b3JrcyB0aXJlbGVzc2x5IGFzIHBhcnQgb2Yg
dGhlIFhlbi5vcmcKY29tbXVuaXR5IG9uIGlzc3VlcyBsaWtlIHRoZXNlLgoKTWF0dAoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sat Jun 23 19:43:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 19:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SiWDw-0006Bw-Og; Sat, 23 Jun 2012 19:42:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SiWDu-0006Bp-HT
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 19:42:22 +0000
Received: from [85.158.138.51:14695] by server-3.bemta-3.messagelabs.com id
	0C/D8-26490-D1C16EF4; Sat, 23 Jun 2012 19:42:21 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340480539!29221602!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1NDAyNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29557 invoked from network); 23 Jun 2012 19:42:20 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 19:42:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340480540; x=1372016540;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:content-transfer-encoding:in-reply-to;
	bh=v4C9ubJLRelZKacLOGadm2ArTqQwWm0TQJ2UgvE0IFg=;
	b=HBWBu6Hton91MZASIf86YYld0CYHljw36g1B3kWZc5lUZUJpT7Yhf/lN
	IsH4O8bUw+zX4btEAjmVET/zJJdP/w==;
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="399404609"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2012 19:42:17 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-51-220.sea3.amazon.com [10.50.51.220])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with SMTP id
	q5NJgEIu023046; Sat, 23 Jun 2012 19:42:15 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Sat, 23 Jun 2012 12:42:14 -0700
Date: Sat, 23 Jun 2012 12:42:14 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120623194214.GF2640@US-SEA-R8XVZTX>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20448.49637.38489.246434@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCBKdW4gMTksIDIwMTIgYXQgMTE6MTY6MDVBTSAtMDcwMCwgSWFuIEphY2tzb24gd3Jv
dGU6Cj4gWy4uLl0KClRoYW5rIHlvdSBmb3Igd3JpdGluZyBhbGwgdGhpcyB1cCwgYW5kIGZvciBh
bGwgb2YgeW91ciBlZmZvcnRzIGFzIHBhcnQKb2YgWGVuLm9yZyBhbmQgdGhlIHNlY3VyaXR5IHJl
c3BvbnNlIHRlYW0sIElhbi4gWW91IGhhdmUgYWxyZWFkeQpjb3ZlcmVkIG1hbnkgb2YgbXkgY29u
Y2VybnMsIHN1Y2ggYXMgYXZvaWRpbmcgaG9saWRheXMuCgo+IFRoZSBiaWcgaXNzdWVzCj4gLS0t
LS0tLS0tLS0tLS0KPgo+IDEuIFB1cnBvc2Ugb2YgdGhlIHByb2Nlc3MKPgo+IFRoZSBmaXJzdCBw
b2ludCBpcyB0aGF0IHdlIHRoaW5rIHRoZSBzZWN1cml0eSB2dWxuZXJhYmlsaXR5IHByb2Nlc3MK
PiBkb2N1bWVudCBzaG91bGQgaGF2ZSBhbiBleHBsYW5hdGlvbiBvZiB3aGF0IGl0cyBnb2FscyBh
cmUuICBUaGlzIHdvdWxkCj4gaGF2ZSBncmVhdGx5IGFzc2lzdGVkIHVzIHdoZW4gbWFraW5nIHNv
bWUgb2YgdGhlIG1vcmUgZGlmZmljdWx0Cj4gZGVjaXNpb25zLgoKVGhlIHNlY3VyaXR5IHZ1bG5l
cmFiaWxpdHkgcHJvY2VzcyBkb2N1bWVudCBzaG91bGQgbW9zdCBkZWZpbml0ZWx5CmVuY2Fwc3Vs
YXRlIGJvdGggZXhwbGljaXQgZ3VpZGFuY2UgYW5kIGJyb2FkIHRlbmV0cyB0aGF0IGNhbiBiZSB1
c2VkCnRvIG1ha2UgdG91Z2ggY2FsbHMuIEkgdGhpbmsgdGhhdCB0aGVzZSBzaG91bGQgYmUgZXhw
bGljaXRseSBjYWxsZWQKb3V0IGluIGZyb250IG1hdHRlciBhcyBhbiBldm9sdXRpb25hcnkgcGFy
dCBvZiB0aGUgcHJvY2Vzcy4gVGVuZXRzCnNob3VsZCBhbHdheXMgYmUgb3BlbiB0byBiZWluZyBy
ZWZpbmVkIG9yIHJlZGVmaW5lZCBhcyBYZW4ub3JnCnByb2plY3RzIGdyb3cgYW5kIHVzYWdlIHNo
aWZ0cy4KCj4gSW4gcGFydGljdWxhciwgaWYgdGhlIHByb2Nlc3MgZXhwbGFpbmVkIGl0cyBwdXJw
b3NlLCB3ZSB3b3VsZCBiZSBhYmxlCj4gdG8gcmVmZXIgdG8gdGhlIHNwaXJpdCBvZiB0aGUgZG9j
dW1lbnQgd2hlbiBtYWtpbmcgaW50ZXJwcmV0YXRpb24KPiBkZWNpc2lvbnMgb3IgZGVhbGluZyB3
aXRoIGlzc3VlcyBub3QgY2xlYXJseSByZXNvbHZlZCBieSB0aGUgZG9jdW1lbnQuCj4KPiBJbiB0
aGlzIGNvbnRleHQgd2UgbmVlZCB0byBkZWNpZGUgd2hldGhlcjoKPiAgKGEpIHRoZSBwcmVkaXNj
bG9zdXJlIGFycmFuZ2VtZW50cyBhcmUganVzdCB0aGVyZSBzbyB0aGF0Cj4gICAgICBvcmdhbmlz
YXRpb25zIGNhbiBiYWNrcG9ydCBwYXRjaGVzLCBkZXZlbG9wIGFuZCB0ZXN0IHVwZGF0ZWQKPiAg
ICAgIHZlcnNpb25zLCBhbmQgc28gZm9ydGg7Cj4gIChiKSB0aGUgYXJyYW5nZW1lbnRzIGFyZSBh
bHNvIGludGVuZGVkIHRvIGFsbG93IG9wZXJhdG9ycyB0byBkZXBsb3kKPiAgICAgIGZpeGVkIHZl
cnNpb25zLgoKSSB0aGluayB0aGF0IHRoZXJlIG1heSBiZSBvdGhlciBhc3BlY3RzIG9mIHRoZSBw
cmVkaXNjbG9zdXJlIHBlcmlvZAp0aGF0IGRlc2VydmUgZXhwbGljaXQgY2FsbG91dHMsIHNvIEkg
ZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIGhlbHBmdWwgdG8KZnJhbWUgdGhpcyBkaXNjdXNzaW9uIGlu
IHBhcnRpY3VsYXIgY29udGV4dCB0aGF0IG9ubHkgZ2l2ZXMgdXMgY2hvaWNlcwooYSkgb3IgKGIp
LiBGb3IgZXhhbXBsZSwgd2UgbWlnaHQgd2FudCB0byBleHBsaWNpdGx5IGNhbGwgb3V0IHRoZQpw
dXJwb3NlIG9mIHRoZSBwcmVkaXNjbG9zdXJlIHBlcmlvZCB0byBpbmNsdWRlIGZ1cnRoZXIgdGVz
dGluZyBhbmQKdmFsaWRhdGlvbiBvZiBhIGZpeCBmcm9tIGEgZ3JvdXAgbW9yZSBicm9hZCB0aGFu
IHRoZSBzZWN1cml0eSByZXNwb25zZQp0ZWFtLgoKQnV0IHRha2luZyBhIHN0ZXAgYmFjaywgSSBw
cm9wb3NlIHRoYXQgYSBjb3JlIHRlbmV0IG9mIHRoZSBzZWN1cml0eQpyZXNwb25zZSBwcm9jZXNz
IHNob3VsZCBiZSB0byByZWR1Y2UgZGF5cy1vZi1yaXNrIGZvciBhbGwgY29uc3VtZXJzIG9mClhl
bi5vcmcgcHJvamVjdHMsIHdoZXRoZXIgZGlyZWN0IG9yIGluZGlyZWN0LCB0byB6ZXJvLiBEYXlz
LW9mLXJpc2sKY2FuIGJlIGZ1enp5IHRvIG1lYXN1cmUsIHNvIHdlIGNvdWxkIGRlZmluZSB0aGlz
IGFzIHRoZSBudW1iZXIgb2YgZGF5cwpiZXR3ZWVuIHdoZW4gYSBzZWN1cml0eSBwcm9ibGVtIGlz
IHB1YmxpY2x5IGtub3duIChlLmcuIHRocm91Z2gKZXZpZGVuY2Ugb2YgZXhwbG9pdGF0aW9uIGlu
IHRoZSB3aWxkIG9yIGEgcHVibGljIGFubm91bmNlbWVudCkgYW5kCndoZW4gdGhlIHByb2JsZW0g
aGFzIGJlZW4gYWRkcmVzc2VkIHN1Y2ggdGhhdCB0aGVyZSBpcyBubyBsb25nZXIgYW55CnJpc2sg
KGUuZy4sIHRocm91Z2ggYSBYZW4gY29uc3VtZXIgZGVwbG95aW5nIGEgZml4ZWQgdmVyc2lvbiBm
cm9tIGEKdmVuZG9yIG9yIGFuIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyIGRvaW5nIHRoZSBzYW1l
IG9uIGEgY29uc3VtZXLigJlzCmJlaGFsZi4pCgpUaGlzIG1lYXN1cmUgbWlnaHQgbm90IG1hdGNo
IHVwIHBlcmZlY3RseSB3aXRoIHR5cGljYWwgZGF5cy1vZi1yaXNrCmFzc2Vzc21lbnRzIHRoYXQg
c29tZSBzb2Z0d2FyZSB2ZW5kb3JzIG1ha2UuIEZvciBleGFtcGxlLCBSZWQgSGF0Cm1lYXN1cmVz
IGRheXMtb2YtcmlzayBmcm9tIHRoZSBkYXRlIG9mIHB1YmxpYyBkaXNjbG9zdXJlIHRvIHRoZSBk
YXRlCnRoYXQgYSBmaXhlZCBwYWNrYWdlIGlzIG1hZGUgYXZhaWxhYmxlLiBUaGV5IHB1Ymxpc2gg
bWV0cmljcyBvbiB0aGlzLAplLmcuOgogIGh0dHA6Ly93d3cucmVkaGF0LmNvbS9zZWN1cml0eS9k
YXRhL21ldHJpY3Mvc3VtbWFyeS1yaGVsNi1jcml0aWNhbC5odG1sCgo+IE9mIGNvdXJzZSB0aGlz
IG5lZWRzIHRvIGRlYWwgY2xlYXJseSB3aXRoIHRoZSBjb21tb24gc3RpdHVhdGlvbiBvZiBhbgo+
IG9yZ2FuaXNhdGlvbiBydW5uaW5nIFhlbiB3aGljaCBpcyBhIGRpcmVjdCBjb25zdW1lciBvZiBY
ZW4ub3JnIHNvdXJjZQo+IGNvZGUuCgpJbmRlZWQuIElmIGEgZ29hbCBvZiB0aGUgcHJvY2VzcyBp
cyB0byByZWR1Y2UgZGF5cy1vZi1yaXNrIGZvciBhbGwKY29uc3VtZXJzIG9mIFhlbi5vcmcgcHJv
amVjdHMgdG8gemVybywgY29vcmRpbmF0aW5nIHBhY2thZ2UgdXBkYXRlcwpvbmx5IGZyb20gc29m
dHdhcmUgdmVuZG9ycyB3aWxsIG5vdCBhY2hpZXZlIGl0LgoKWy4uLl0KPgo+IDIuIEV4dGVuc2lv
biBvZiBlbWJhcmdvIGRhdGVzCj4KPiBUaGUgbW9zdCBjb250cm92ZXJzaWFsIGRlY2lzaW9uIHdh
cyB3aGV0aGVyIHRoZSBlbWJhcmdvIGRhdGUgbWlnaHQgYmUKPiBleHRlbmRlZCBhZnRlciBpdCBo
YWQgb3JpZ2luYWxseSBiZWVuIHNldC4gIFdlIHJlc2lzdGVkIHRoZXNlCj4gc3VnZ2VzdGlvbnMs
IHJlZmVycmluZyB0byB0aGUgcHJvY2VzcyBkb2N1bWVudCwgd2hpY2ggZG9lcyBub3QKPiBjb250
ZW1wbGF0ZSBleHRlbmRpbmcgdGhlIGRpc2Nsb3N1cmUgcGVyaW9kLiAgSG93ZXZlciwgd2hlbiBh
Cj4gcHJlZGlzY2xvc3VyZSBsaXN0IG1lbWJlciBwcmVzc3VyZWQgdGhlIGRpc2NvdmVyZXIgaW50
byByZXF1ZXN0aW5nIGFuCj4gZXh0ZW5zaW9uLCB3ZSBmZWx0IHRoZSBiZXN0IGludGVycHJldGF0
aW9uIG9mIHRoZSBwcm9jZXNzIGRvY3VtZW50Cj4gcmVxdWlyZWQgdXMgdG8gYWNxdWllc2NlLgo+
Cj4gU3BlY2lmaWNhbGx5LCBvZiBjb3Vyc2UsIHdlIGFzIGEgdGVhbSB3b3VsZCBsaWtlIGNsZWFy
ZXIgZ3VpZGFuY2UgZnJvbQo+IHRoZSBwcm9jZXNzIGFib3V0IHdoZXRoZXIsIGFuZCBpZiBzbyB1
bmRlciB3aGF0IGNpcmN1bXN0YW5jZXMsIGEKPiBwcmVkaXNjbG9zdXJlIHBlcmlvZCBzaG91bGQg
YmUgZXh0ZW5kZWQuCgpJIHRoaW5rIHRoYXQgdGhlIGlzc3VlIG9mIGVzdGFibGlzaGluZyBhbmQg
Y2hhbmdpbmcgdGhlIGVtYmFyZ28gZW5kCmRhdGUsIHdoZXRoZXIgZXh0ZW5kaW5nIG9yIHNob3J0
aW5nLCBkZXNlcnZlcyBhIGxvdCBvZiBkaXNjdXNzaW9uLgpJdCdzIGdvb2QgdGhhdCB3ZSdyZSBu
b3QgbGltaXRpbmcgdGhlIGRpc2N1c3Npb24gb25seSB0byBleHRlbmRpbmcKZXh0ZW5kaW5nIGRp
c2Nsb3N1cmUgZGF0ZXMsIGJ1dCBhbHNvIGVzdGFibGlzaGluZyB0aGUgZGVmYXVsdCB0aW1lbGlu
ZQphcyB5b3UgY2FsbCBvdXQgaW4gNCBiZWxvdy4gIEkgdGhpbmsgdGhhdCBzb21lIGd1aWRlbGlu
ZXMgZm9yCmVzdGFibGlzaGluZyBhbiBhcHByb3ByaWF0ZSB0aW1lbGluZSBjYW4gYWRkcmVzcyBw
cm9ibGVtcyB0aGF0IGNhdXNlCmV4dGVuc2lvbiByZXF1ZXN0cy4KClRoZSBkZWZhdWx0IGRpc2Ns
b3N1cmUgcGVyaW9kLCBpZiBhZ3JlZWFibGUgdG8gdGhlIGRpc2NvdmVyZXIsIGlzCmN1cnJlbnRs
eSB0aHJlZSB3ZWVrczoKICAgMS4gT25lIHdvcmtpbmcgd2VlayBiZXR3ZWVuIG5vdGlmaWNhdGlv
biBhcnJpdmluZyBhdCBzZWN1cml0eUB4ZW4KICAgICAgYW5kIHRoZSBpc3N1ZSBvZiBvdXIgb3du
IGFkdmlzb3J5IHRvIG91ciBwcmVkaXNjbG9zdXJlIGxpc3QuIFdlCiAgICAgIHdpbGwgdXNlIHRo
aXMgdGltZSB0byBnYXRoZXIgaW5mb3JtYXRpb24gYW5kIHByZXBhcmUgb3VyCiAgICAgIGFkdmlz
b3J5LCBpbmNsdWRpbmcgcmVxdWlyZWQgcGF0Y2hlcy4KICAgMi4gVHdvIHdvcmtpbmcgd2Vla3Mg
YmV0d2VlbiBpc3N1ZSBvZiBvdXIgYWR2aXNvcnkgdG8gb3VyCiAgICAgIHByZWRpc2Nsb3N1cmUg
bGlzdCBhbmQgcHVibGljYXRpb24uCgpUaGlzIG1heSBiZSBhIHJlYXNvbmFibGUgc3RhcnRpbmcg
cG9pbnQgZm9yIGdlbmVyYWwgaXNzdWVzLCBidXQgSQp0aGluayB0aGF0IHRoZSBvdmVyYWxsIGlt
cGFjdCBhbmQgY29tcGxleGl0eSBvZiBhbiBpc3N1ZSBuZWVkcyB0byBiZQpjb25zaWRlcmVkIHdo
ZW4gZXN0YWJsaXNoaW5nIGEgdGltZWxpbmUuCgpGb3IgZXhhbXBsZSwgdGhlIG9DRVJUIERpc2Ns
b3N1cmUgUG9saWN5IGdpdmVzIHRoaXMgZ3VpZGFuY2U6CiAgaHR0cHM6Ly93d3cub2NlcnQub3Jn
L2Rpc2Nsb3N1cmVfcG9saWN5Lmh0bWwKIiIiCiAgIFRoZSBmb2xsb3dpbmcgdGltZSBmcmFtZXMg
cmVndWxhdGUgb0NFUlQgZW1iYXJnbyBwcm9wb3NhbHM6CgogICAtIDcgZGF5cywgaW4gY2FzZSB0
aGUgaXNzdWUgaXMgYWxyZWFkeSB3ZWxsIG5hcnJvd2VkIGRvd24gYW5kCiAgICAgdGVzdGVkLCBy
ZXF1aXJpbmcgdHJpdmlhbCBjb25maWd1cmF0aW9uIGFuZC9vciBjb2RlIGNoYW5nZQoKICAgLSAx
NCBkYXlzLCBzdGFuZGFyZCBlbWJhcmdvIGZvciBtb3N0IGNhc2VzCgogICAtIDMwIGRheXMsIGlu
IGNhc2Ugb2YgY3JpdGljYWwgYW5kIGNvbXBsZXggdnVsbmVyYWJpbGl0aWVzCiAgICAgKGV4YW1w
bGUsIHRyaXZpYWwgZXhwbG9pdGF0aW9uIG9mIGFkbWluaXN0cmF0aXZlIHByaXZpbGVnZXMgb24g
YQogICAgIHN0YXRpYyBsaWJyYXJ5IGFmZmVjdGluZyBhIGxhcmdlIG51bWJlciBvZiBwYWNrYWdl
cyksIGFuZCB3aXRoCiAgICAgdGhlIGFncmVlbWVudCBvZiBhbGwgcGFydGllcwoKICAgLSB1bmRl
ciBleHRyZW1lbHkgZXhjZXB0aW9uYWwgY2lyY3Vtc3RhbmNlcywgaWYgdGhlIG9DRVJUIFRlYW0g
YW5kCiAgICAgYWxsIHRoZSBwYXJ0aWVzIGludm9sdmVkIGZlZWwgdGhlIG5lZWQgZm9yIGxvbmdl
ciB0aW1lLCBhIDIKICAgICBtb250aHMgZW1iYXJnbyBjYW4gYmUgYXBwbGllZCwgaW4gdGhpcyBj
YXNlIHdlIHdvdWxkIGNsZWFybHkKICAgICBkb2N1bWVudCB0aGUgZGVjaXNpb24gZm9yIHB1Ymxp
YyByZXZpZXcKCiAgIC0gaW4gYW55IGNpcmN1bXN0YW5jZSByZXBvcnRlciBwcmVmZXJlbmNlIHdp
bGwgYWx3YXlzIGJlIGhvbm91cmVkCiAgICAgaW4gY2FzZSBhIGpvaW50IGFncmVlbWVudCBpcyBu
b3QgcmVhY2hlZCwgYXMgb0NFUlQgd291bGQgYmUKICAgICBhbnl3YXkgdW5hYmxlIHRvIGZvcmNl
IGl0cyBlbWJhcmdvCiIiIgoKVGhlIENFUlQgcHJvY2VzcyBkZWZhdWx0cyB0byA0NSBkYXlzLCB3
aXRoIGd1aWRhbmNlIHRvIHNob3J0ZW4gdGhlCnJlbGVhc2Ugc2NoZWR1bGUgaWYgdGhlcmUncyBl
dmlkZW5jZSBvZiBhY3RpdmUgZXhwbG9pdGF0aW9uOgogaHR0cDovL3d3dy5jZXJ0Lm9yZy9rYi92
dWxfZGlzY2xvc3VyZS5odG1sCiIiIgogICBROiBXaWxsIGFsbCB2dWxuZXJhYmlsaXRpZXMgYmUg
ZGlzY2xvc2VkIHdpdGhpbiA0NSBkYXlzPwoKICAgQTogTm8uIFRoZXJlIG1heSBvZnRlbiBiZSBj
aXJjdW1zdGFuY2VzIHRoYXQgd2lsbCBjYXVzZSB1cyB0bwogICAgICBhZGp1c3Qgb3VyIHB1Ymxp
Y2F0aW9uIHNjaGVkdWxlLiBUaHJlYXRzIHRoYXQgYXJlIGVzcGVjaWFsbHkKICAgICAgc2VyaW91
cyBvciBmb3Igd2hpY2ggd2UgaGF2ZSBldmlkZW5jZSBvZiBleHBsb2l0YXRpb24gd2lsbAogICAg
ICBsaWtlbHkgY2F1c2UgdXMgdG8gc2hvcnRlbiBvdXIgcmVsZWFzZSBzY2hlZHVsZS4gVGhyZWF0
cyB0aGF0CiAgICAgIHJlcXVpcmUgImhhcmQiIGNoYW5nZXMgKGNoYW5nZXMgdG8gc3RhbmRhcmRz
LCBjaGFuZ2VzIHRvIGNvcmUKICAgICAgb3BlcmF0aW5nIHN5c3RlbSBjb21wb25lbnRzKSB3aWxs
IGNhdXNlIHVzIHRvIGV4dGVuZCBvdXIKICAgICAgcHVibGljYXRpb24gc2NoZWR1bGUuCiIiIgoK
Rm9yIGFub3RoZXIgdGFrZSwgdGhlIFdlYktpdCBkZWZhdWx0IGVtYmFyZ28gcGVyaW9kLCBmb3Vu
ZCBoZXJlOgpodHRwOi8vd3d3LndlYmtpdC5vcmcvc2VjdXJpdHkvLCBpcyA2MCBkYXlzIHVubGVz
cyBhbGwgdmVuZG9ycyBoYXZlCmFkZHJlc3NlZCBhbiBpc3N1ZSwgaW4gd2hpY2ggY2FzZSBhbiBl
bWJhcmdvIG1heSBiZSBsaWZ0ZWQgc29vbmVyLgoKPiAzLiBEZWNpc2lvbm1ha2luZwo+Cj4gSXQg
d2FzIHN1Z2dlc3RlZCB0byB1cyBzZXZlcmFsIHRpbWVzLCBhbmQgaW5kZWVkIHNlZW1lZCB0byBi
ZSByZWdhcmRlZAo+IGJ5IHNvbWUgYXMgYW4gdW5kZXJseWluZyBwcmluY2lwbGUsIHRoYXQgdGhl
IHByZWRpc2Nsb3N1cmUgbGlzdAo+IG1lbWJlcnMgc2hvdWxkIGJlIG1ha2luZyB0aGUgZGVjaXNp
b25zIGFib3V0IGRpc2Nsb3N1cmUgc2NoZWR1bGUgZXRjLgo+Cj4gVGhlIHF1ZXN0aW9uIG9mIHdo
byBpcyB0byBtYWtlIHRoZSBkZWNpc2lvbnMsIGFuZCBvbiB3aGF0IGJhc2lzLCBuZWVkcwo+IHRv
IGJlIGFkZHJlc3NlZC4KCkkgZG8gbm90IHRoaW5rIHRoYXQgaXQgaXMgd2lzZSBmb3IgdGhlIHBv
bGljeSB0byBlc3RhYmxpc2ggZGVjaXNpb24KbWFraW5nIGJ5IGNvbW1pdHRlZS4gQWxsIGNvbmNl
cm5lZCBwYXJ0aWVzIHNob3VsZCB2b2ljZSBhbnkgY29uY2VybnMKcmVnYXJkaW5nIHRoZSBzZWN1
cml0eSByZXNwb25zZSBwcm9jZXNzIHNvIHRoYXQgdGhlIHJlc3VsdGluZyBkb2N1bWVudAp3aWxs
IGd1aWRlIHRob3NlIG1ha2luZyBkZWNpc2lvbnMuCgpUbyBwdXQgaXQgYW5vdGhlciB3YXksIHBy
ZWRpc2Nsb3N1cmUgbGlzdCBtZW1iZXJzIChhbmQgYW55IG90aGVyCmludGVyZXN0ZWQgcGFydHkp
IHNob3VsZCBtYWtlIGRlY2lzaW9ucyBvbiBob3cgdGhleSdkIGxpa2UgZm9yCmRpc2Nsb3N1cmUg
c2NoZWR1bGVzIHRvIGJlIGVzdGFibGlzaGVkIG5vdywgYW5kIHRoZSByYXRpZmllZCBwcm9jZXNz
CnNob3VsZCBhY3QgYXMgYSBwcm94eSB3aGVuIHNwZWNpZmljIHZ1bG5lcmFiaWxpdGllcyBhcmUg
aGFuZGxlZC4KCkluIHRoZSBpbnRlcmVzdCBvZiB0cmFuc3BhcmVuY3ksIHRob3NlIG1ha2luZyBk
ZWNpc2lvbnMsIGkuZS4gdGhlCm1lbWJlcnMgb2YgdGhlIHNlY3VyaXR5IHJlc3BvbnNlIHRlYW0g
YW5kIGFueSBvdGhlciBwZXJzb24gb3IgZW50aXR5Cm9uIHRoZSBzZWN1cml0eUB4ZW4ub3JnIGFs
aWFzLCBzaG91bGQgYmUgZGlzY2xvc2VkIGFuZCBkb2N1bWVudGVkIGluCnRoZSBwcm9jZXNzIGRv
Y3VtZW50LgoKVWx0aW1hdGVseSBJIHRoaW5rIHRoYXQsIGFzIGlzIGNvbW1vbiBwcmFjdGljZSBp
biBjb29yZGluYXRlZAp2dWxuZXJhYmlsaXR5IGRpc2Nsb3N1cmUsIHRoZSBkaXNjb3ZlcmVyIGlz
IHRoZSB1bHRpbWF0ZQpkZWNpc2lvbi1tYWtlciBhcyB0byB3aGF0IGluZm9ybWF0aW9uIGlzIGRp
c2Nsb3NlZCBhbmQgd2hlbiBpdCBpcwpkaXNjbG9zZWQuIFRoZSB4ZW5Ac2VjdXJpdHkgdGVhbSBt
YWtlcyBkZWNpc2lvbnMgcGVyIHRoZSBndWlkYW5jZSBpbgp0aGUgcHJvY2VzcyBhbmQgdGhlIGZh
Y3RzIGF0IGhhbmQuCgo+IDQuIExlbmd0aCBvZiAoZGVmYXVsdCkgcHJlZGlzY2xvc3VyZSBwZXJp
b2QKPgpbLi4uXQoKU2VlIGNvbW1lbnRzIGFib3ZlLgoKPiA1LiBDcml0ZXJpYSBmb3IgcHJlZGlz
Y2xvc3VyZSBsaXN0IG1lbWJlcnNoaXAKPgpbLi4uXQo+IFdlIG5lZWQgdG8gY2xhcmlmeSB3aGV0
aGVyIHVwc3RyZWFtcyBhbmQgaGFyZHdhcmUgdmVuZG9ycyBzaG91bGQgYmUgb24KPiB0aGUgcHJl
ZGlzY2xvc3VyZSBsaXN0LiAgQ3VycmVudGx5IHdlIGhhdmUgb25lIG5vdGFibGUgdXBzdHJlYW0g
dmVuZG9yCj4gb24gdGhhdCBsaXN0Lgo+Cj4gT3VyIHByZWxpbWluYXJ5IHZpZXcgaXMgdGhhdCB0
aGUgcHJlZGlzY2xvc3VyZSBsaXN0IHNob3VsZCBiZSB1c2VkIGZvcgo+IGRvd25zdHJlYW0gbm90
aWZpY2F0aW9ucy4gIFVwc3RyZWFtcywgaW5jbHVkaW5nIGhhcmR3YXJlCj4gbWFudWZhY3R1cmVy
cywgc2hvdWxkIGJlIGJyb3VnaHQgaW4gdG8gdGhlIGRpc2Nsb3N1cmUgcHJvY2VzcyBhcwo+IG5l
ZWRlZC4gIEFuZCBhcyBub3RlZCwgb3VyIHByb2Nlc3MgZm9yIG1ha2luZyBzdXJlIHdlIGRvIHRo
YXQgcHJvcGVybHkKPiBuZWVkcyB0byBiZSBmb3JtYWxpc2VkLgoKT3ZlcmFsbCBJIHRoaW5rIHRo
YXQsIGluIGEgY29vcmRpbmF0ZWQgZGlzY2xvc3VyZSByZXNwb25zZSwKaW5mb3JtYXRpb24gc2hv
dWxkIGJlIGRpc3RyaWJ1dGVkIG9uIGEgbmVlZC10by1rbm93IGJhc2lzLgoKWy4uLl0KPiA2LiBT
aGFyaW5nIG9mIGluZm9ybWF0aW9uIGFuZCBjb2RlIGJldHdlZW4gcHJlZGlzY2xvc3VyZSBwYXJ0
aWNpcGFudHMKPgo+IFdlIG5lZWQgdGhlIHByb2Nlc3MgZG9jdW1lbnQgdG8gYmUgY2xlYXJlciBh
Ym91dCB3aGF0IGtpbmRzIG9mCj4gY29tbXVuaWNhdGlvbnMgYXJlIGNvbnRlbXBsYXRlZCBfYmV0
d2Vlbl8gbWVtYmVycyBvZiB0aGUgcHJlZGlzY2xvc3VyZQo+IGxpc3QuCj4KPiBPbmUgcGFydGlj
dWxhciBpc3N1ZSBoZXJlIHdoaWNoIGFsc28gcmVsYXRlcyB0byB0aGUgcHJlZGlzY2xvc3VyZQo+
IG1lbWJlcnNoaXAgY3JpdGVyaWEsIGlzIHdoZXRoZXIgbGFyZ2UgaW5kaXJlY3QgY29uc3VtZXJz
IG9mIFhlbiBzaG91bGQKPiBiZSBvbiB0aGUgcHJlZGlzY2xvc3VyZSBsaXN0IGluIHRoZWlyIG93
biByaWdodC4gIFRoYXQgd291bGQgYWxsb3cKPiB0aGVtIHRvIGRlcGxveSB0aGUgZml4IGJlZm9y
ZSB0aGUgZW1iYXJnbyBkYXRlLiAgSXQgd291bGQgYWxzbyBhbGxvdwo+IHRoZW0gdG8gcHJlcGFy
ZSBmb3IgdGVzdGluZyBhbmQgZGVwbG95bWVudCwgYmVmb3JlIHRoZSBmaXggaXMKPiBhdmFpbGFi
bGUgZnJvbSB0aGVpciB2ZW5kb3IgKHdobyB3b3VsZCBpbiB0aGlzIHNjZW5hcmlvIGFsc28gYmUK
PiBlbnRpdGxlZCB0byBiZSBhIHByZWRpc2Nsb3N1cmUgbGlzdCBtZW1iZXIpLgo+Cj4gSW4gdGhp
cyBjb250ZXh0LCB0aGUgcHJvY2VzcyBuZWVkcyB0byBjbGFyaWZ5IHdoZXRoZXIgdmVuZG9ycyBt
YXkKPiByZWxlYXNlIGZpeGVkIGJpbmFyaWVzIGR1cmluZyB0aGUgcHJlZGlzY2xvc3VyZSBwZXJp
b2QuICBDZXJ0YWlubHkKPiB0aGVzZSBzaG91bGQgbm90IGJlIHJlbGVhc2VkIG90aGVyIHRoYW4g
dG8gcHJlZGlzY2xvc3VyZSBsaXN0IG1lbWJlcnMsCj4gc2luY2UgdGhlIG5hdHVyZSBvZiBhIGJ1
ZyBjYW4gb2Z0ZW4gYnkgZGlzY292ZXJlZCBieSByZXZlcnNlCj4gZW5naW5lZXJpbmcuICBCdXQg
Y2FuIHRoZXkgYmUgcmVsZWFzZWQgdG8gcHJlZGlzY2xvdXNyZSBsaXN0IG1lbWJlcnMgPwoKSW4g
bXkgb3BpbmlvbiwgdGhlcmUgaXMgbGVzcyBkaXN0aW5jdGlvbiBiZXR3ZWVuICJzb2Z0d2FyZSB2
ZW5kb3JzIgphbmQgImxhcmdlIGluZGlyZWN0IGNvbnN1bWVycyBvZiBYZW4iIHRoYW4geW91IHN1
Z2dlc3QuCgo+IE1vcmUgbWlub3IgcG9saWN5IHF1ZXN0aW9ucwo+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+ClsuLi5dCj4gOS4gVnVsbmVyYWJpbGl0eSBwcm9jZXNzIHNjb3BlCj4KPiBX
ZSBuZWVkIHRvIGNsYXJpZnkgdGhlIHNjb3BlIG9mIHRoZSBwcm9jZXNzIGRvY3VtZW50LiAgQ3Vy
cmVudGx5IGl0Cj4gbG9va3MgbGlrZSBpdCBjb3ZlcnMgZXZlcnkgWGVuLm9yZyBwcm9qZWN0Lgo+
Cj4gV2hpbGUgaXQgd291bGQgYmUgYSBuaWNlIGlkZWFsIHRvIHN1cHBvcnQgZXZlcnkgWGVuLm9y
ZyBwcm9qZWN0IHRoaXMKPiB3YXksIGluIHByYWN0aWNlIHRoZSB0ZWFtIGJlaGluZCBzZWN1cml0
eUB4ZW4gZG8gbm90IGhhdmUgdGhlCj4gZXhwZXJ0aXNlIG9yIHJlc291cmNlcyB0byBmaXggcHJv
YmxlbXMgaW4gKHNheSkgWENQLCBvciB0aGUgQVJNIFBWCj4gcG9ydC4gIE91ciBjYXBhYmlsaXR5
IGlzIGNvbmNlbnRyYXRlZCBvbiB0aGUgIlVwc3RyZWFtIFhlbiIgY29kZWJhc2UKPiAoeGVuLSou
aGcgYW5kIGl0cyBzdWItcmVwb3NpdG9yaWVzKSBhbmQgdGhlIFhlbiBzdXBwb3J0IGNvZGUgaW4g
TGludXguCj4KPiBQZXJoYXBzIHRoaXMgY291bGQgYmUgZGVhbHQgd2l0aCBieSBtYWtpbmcgaXQg
Y2xlYXIgdGhhdCBwcm9ibGVtcyBhcmUKPiBoYW5kbGVkIG9uIGEgYmVzdCBlZmZvcnQgYmFzaXMu
CgpJdCB3b3VsZCBzZWVtIHRoYXQgaW4gY2FzZXMgd2l0aCBtYXR1cmUgcHJvamVjdHMsIGFwcHJv
cHJpYXRlCm1haW50YWluZXJzIGFuZCBjb21taXR0ZXJzIHNob3VsZCBiZSBlbmdhZ2VkIGJ5IHNl
Y3VyaXR5QHhlbi5vcmcgdG8KYWRkcmVzcyBwcm9ibGVtcyBhbmQgcHJlcGFyZSBmaXhlcy4gc2Vj
dXJpdHlAeGVuLm9yZyBzaG91bGQsIEkgdGhpbmssCmNvbnRpbnVlIHRvIGNvb3JkaW5hdGUgdGhl
IG92ZXJhbGwgcmVzcG9uc2UuCgpJbiBvcmRlciB0byBncmFkdWF0ZSwgYSBwcm9qZWN0IHNob3Vs
ZCBtYWludGFpbiBzdWZmaWNpZW50IHNwb25zb3JzaGlwCnRvIGFkZHJlc3Mgc2VjdXJpdHkgcHJv
YmxlbXMgaW4gYSB0aW1lbHkgbWFubmVyLiBUaGF0IHNob3VsZCBiZSBwYXJ0Cm9mIHRoZSAiYmFz
aWMgY29uZGl0aW9ucyIgb2YgYmVpbmcgbGFiZWxlZCBhICJtYXR1cmUiIHByb2plY3QuIElmIGEK
bWF0dXJlIHByb2plY3QgZG9lcyBub3QgaGF2ZSBzdWZmaWNpZW50IHNwb25zb3JzaGlwIHRvIGFk
ZHJlc3MKc2VjdXJpdHkgY29uY2VybnMsIGl0IHNob3VsZCBiZSBjYWxsZWQgb3V0IGFuZCBhcmNo
aXZpbmcgdGhlIHByb2plY3QKc2hvdWxkIGJlIGNvbnNpZGVyZWQuCgpUaGUgQXBhY2hlIEluY3Vi
YXRvciBwcm9jZXNzIGhhcyBzb21lIGdvb2QgYWR2aWNlIHRvIHByb2plY3RzIHRoYXQgYXJlCmdy
YWR1YXRpbmc6IGh0dHA6Ly9pbmN1YmF0b3IuYXBhY2hlLm9yZy9ndWlkZXMvZ3JhZHVhdGlvbi5o
dG1sI3NlY3VyaXR5Cgo+IDEwLiBFeHBsb2l0cwo+Cj4gV2UgbmVlZCBhIGNsZWFyIHBvbGljeSBh
Ym91dCByZWxlYXNpbmcgcHJvb2Ygb2YgY29uY2VwdCBleHBsb2l0cyAtCj4gd2hldGhlciwgd2hl
biBhbmQgd2hvIHRvLgoKTGV0J3Mgbm90IGxpbWl0IHRoZSBkaXNjdXNzaW9uIG9ubHkgdG8gUG9D
IGV4cGxvaXQgY29kZS4gVGhlIHBvbGljeQpzaG91bGQgc3BlYWsgdG8gd2hvIGdldHMgYWNjZXNz
IHRvIHNwZWNpZmljIHRlY2huaWNhbCBkZXRhaWxzIG9mIGEKdnVsbmVyYWJpbGl0eSwgYW5kIHdo
ZW4gdGhleSBnYWluIGFjY2Vzcy4KClBhcnRpZXMgdGhhdCBhcmUgKmFjdGl2ZSogaW4gdGhlIGNv
b3JkaW5hdGVkIGRpc2Nsb3N1cmUsIGZvciBleGFtcGxlCmJ5IGJ1aWxkaW5nIHBhdGNoZWQgdmVy
c2lvbnMgb2YgcHJvZHVjdHMgb3Igc2VydmljZXMgYnVpbHQgb24gWGVuLApuZWVkIHRvIGhhdmUg
YWNjZXNzIHRvIGFzIG11Y2ggdGVjaG5pY2FsIGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIGluCm9y
ZGVyIHRvIHZhbGlkYXRlIHRoZSBmaXggYW5kIHRoZWlyIHBvcnRzLiBUaG9zZSB0aGF0IGFyZSBw
YXNzaXZlLCB3aG8KbWF5IGJlIGRlcGxveWluZyBhIHByZS1yZWxlYXNlIGZpeGVkIHZlcnNpb24g
ZnJvbSBhIHZlbmRvciwgZG8gbm90Cm5lZWQgYWNjZXNzIHRvIHRoZXNlIG1hdGVyaWFscy4KClsu
Li5dCj4KPiBMYWN1bmFlIGluIHRoZSBwcm9jZXNzCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+
Cj4gMTIuIEhvbGlkYXlzCj4KPiBUaGUgb3JpZ2luYWwgcGxhbm5lZCBkaXNjbG9zdXJlIGRhdGUs
IDIwMTItMDUtMDEsIHdhcyBhIHB1YmxpYyBob2xpZGF5Cj4gaW4gbWFueSBwbGFjZXMuICBXZSBz
aG91bGQgdHJ5IHRvIGF2b2lkIGhvbGlkYXlzLCBhbmQgRnJpZGF5cy4gIFdlCj4gbmVlZCB0byBk
aXNjdXNzIHdoaWNoIHRlcnJpdG9yaWVzJyBob2xpZGF5cyBzaG91bGQgYmUgY2hlY2tlZCBhbmQg
bWFrZQo+IGEgbGlzdCBmb3IgaW5jbHVzaW9uIGluIHRoZSBwcm9jZXNzLgoKVGhpcyBtYWtlcyBz
ZW5zZSwgYW5kIGlzIHNpbWlsYXIgdG8gb3RoZXIgY29vcmRpbmF0ZWQgcmVzcG9uc2UgZ3JvdXBz
Cmxpa2UgbGludXgtZGlzdHJvc0B2cy5vcGVud2FsbC5vcmcuCgo+IDEzLiBQYXRjaCBkZXZlbG9w
bWVudCBhbmQgcmV2aWV3Cj4KPiBUaGUgcGF0Y2ggZGV2ZWxvcG1lbnQgcHJvY2VzcyBpcyB0b28g
Y2xvc2VkIGFuZCBub3Qgcm9idXN0IGVub3VnaC4KPgo+IFdlIG5lZWQgdG8gYmUgbXVjaCBjbGVh
cmVyIGJvdGggYWJvdXQgdGhlIG5lZWQgZm9yIHNlY3VyaXR5IHBhdGNoZXMgdG8KPiBmaXggdGhp
bmdzIGluIHRoZSBzbWFsbGVzdCwgc2ltcGxlc3QgYW5kIG1vc3QgcmVsaWFibGUgd2F5LCBhbmQg
bm90Cj4gZml4IG9yICJpbXByb3ZlIiBtYXR0ZXJzIGluIHVucmVsYXRlZCB3YXlzLiAgT3VyIGlu
dGVybmFsIGNvZGUgcmV2aWV3Cj4gbmVlZHMgdG8gYmUgbXVjaCBiZXR0ZXIuCj4KPiBXZSBuZWVk
IHRvIGNsYXJpZnkgdGhhdCBvdGhlciBpc3N1ZXMgZGlzY292ZXJlZCBkdXJpbmcgdGhlIGNvdXJz
ZSBvZgo+IGludmVzdGlnYXRpbmcgYSBzZWN1cml0eSBkaXNjbG9zdXJlIHdpbGwgbm90IGJlIHB1
YmxpY2x5IGRpc2N1c3NlZAo+IHdpdGhvdXQgZmlyc3QgY29uc3VsdGluZyB0aGUgWGVuLm9yZyBz
ZWN1cml0eSB0ZWFtLCByZWdhcmRsZXNzIG9mCj4gdGhlaXIgYWN0dWFsIHJlbGF0aW9uc2hpcCB0
byB0aGUgdnVsbmVyYWJpbGl0eSBhdCBoYW5kIG9yIGV4cGVjdGVkCj4gc2VjdXJpdHkgaW1wYWN0
LiAgT3RoZXJ3aXNlIHRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgcmlzayB0aGF0IHN1Y2gKPiBjaGFu
Z2VzIHdpbGwgZHJhdyBhdHRlbnRpb24gdG8gZW1iYXJnb2VkIHByb2JsZW1zLgoKQWxsIG9mIHRo
aXMgbWFrZXMgc2Vuc2UgdG8gbWUuCgo+IEl0IG1heSBiZSB0aGF0IGl0IHdvdWxkIGJlIGEgYmV0
dGVyIGlkZWEgdG8gc2VuZCBvdXQgZWFybGllcgo+IGFkdmlzb3JpZXMgd2l0aG91dCBwYXRjaGVz
IHRvIHRoZSBwcmVkaXNjbG9zdXJlIGxpc3QsIHRvIGVuYWJsZSB0aG9zZQo+IHByZWRpc2Nsb3N1
cmUgbGlzdCBtZW1iZXJzIHdobyB3b3VsZCBsaWtlIHRvIGRvIHNvIHRvIGhlbHAgd2l0aAo+IGRl
dmVsb3BtZW50IGFuZCB0ZXN0aW5nIG9mIHRoZSBwYXRjaGVzLiAgSWYgc28gdGhpcyBuZWVkcyB0
byBiZQo+IGNhdGVyZWQgZm9yLgoKVGhpcyB3b3VsZCBiZSB0cmVtZW5kb3VzbHkgaGVscGZ1bCwg
c28gbG9uZyBhcyBhZGVxdWF0ZSB0ZWNobmljYWwKaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQuCgo+
IDE0LiBFYXJseSBjb25zaWRlcmF0aW9uIG9mIHdoaWNoIG90aGVyIG9yZ2FuaXNhdGlvbnMgdG8g
YnJpbmcgaW4KPgo+IE91ciBwcm9jZXNzIG5lZWRzIHRvIGhhdmUsIHZlcnkgZWFybHkgb24sIGFu
IGV4cGxpY2l0IHN0ZXAgdG8gb2YKPiBkZWNpZGluZyB3aGljaCBvdGhlciBwcm9qZWN0cy9vcmdh
bmlzYXRpb25zIG1heSBhbHNvIGJlIHZ1bG5lcmFibGUgYW5kCj4gbWF5IHRoZXJlZm9yZSBuZWVk
IHRvIGJlIHBhcnQgb2YgdGhlIHNhbWUgZGlzY2xvc3VyZSBwcm9jZXNzLiAgSXQgYWxzbwo+IG5l
ZWRzIHRvIG1ha2Ugc3VyZSB0aGF0IHdlIGFzayBmb3IgYW55IGhlbHAgKGZvciBleGFtcGxlIGZy
b20KPiB1cHN0cmVhbXMgb3IgaGFyZHdhcmUgdmVuZG9ycykgYXMgc29vbiBhcyBwb3NzaWJsZS4K
ClRoZSBleGlzdGluZyBwcm9jZXNzIGhhZCBhIHN0ZXAgZm9yIHRoaXM6CiIiIgogIGQuIElmIHdl
IHRoaW5rIG90aGVyIHNvZnR3YXJlIHN5c3RlbXMgKGZvciBleGFtcGxlLCBjb21wZXRpbmcKICAg
ICBoeXBlcnZpc29yIHN5c3RlbXMpIGFyZSBsaWtlbHkgdG8gYmUgYWZmZWN0ZWQgYnkgdGhlIHNh
bWUKICAgICB2dWxuZXJhYmlsaXR5LCB3ZSB3aWxsIHRyeSB0byBtYWtlIHRob3NlIG90aGVyIHBy
b2plY3RzIGF3YXJlIG9mCiAgICAgdGhlIHByb2JsZW0gYW5kIGluY2x1ZGUgdGhlbSBpbiB0aGUg
YWR2aXNvcnkgcHJlcGFyYXRpb24gcHJvY2Vzcy4KIiIiCgo+IFsuLi5dCgpUaGFuayB5b3UgYWdh
aW4gZm9yIGFjdGluZyBhcyB0aGUgZmFjaWxpdGF0b3IgZm9yIHRoaXMgZGlzY3Vzc2lvbiwgYW5k
Cm1hbnkgdGhhbmtzIHRvIGV2ZXJ5b25lIHdobyB3b3JrcyB0aXJlbGVzc2x5IGFzIHBhcnQgb2Yg
dGhlIFhlbi5vcmcKY29tbXVuaXR5IG9uIGlzc3VlcyBsaWtlIHRoZXNlLgoKTWF0dAoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sat Jun 23 20:23:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 20:23: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 1SiWqv-0006ba-Bt; Sat, 23 Jun 2012 20:22:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1SiWqt-0006bV-IY
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 20:22:39 +0000
Received: from [85.158.138.51:2763] by server-11.bemta-3.messagelabs.com id
	E6/E3-02904-E8526EF4; Sat, 23 Jun 2012 20:22:38 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340482956!29223888!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3934 invoked from network); 23 Jun 2012 20:22:37 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 20:22:37 -0000
Received: by ggnp1 with SMTP id p1so2600903ggn.32
	for <xen-devel@lists.xen.org>; Sat, 23 Jun 2012 13:22:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=K0ybpU7Pom6YDloj5pEoisCnK6DgVjCt5IN8CK92BSk=;
	b=xQ/y0aZqQHF8jh0HeXfPkMNgj9TmcSAzztTrcRlH8J9GoGqEL4AOVF9cRooSiSu7aQ
	9RChelkCYOILLBq1oDQSkw0BDtFRvhAbQYWtYYcW/eOPoXkSkJxtZmuSaNkkVAyFiOqB
	QN11AywvRAiR7HzkNc5PyL80w5krjhIY1b+mFK6LCD070Q7U/dKU4sEbUEpaovCGLGP1
	hP+58TSxFdZKa+glguccuL0YXyELy2hDppU0oKI8RpVLxPfVvXy6YQCJSLbaTCNR0Y/A
	UIHI/SpjcrUlPPXqgN79qHYM8f+VRQRgoXjEvKWuQAlL2kW/XatcnmFMDmlYueX3Mp+y
	7vmw==
Received: by 10.236.79.6 with SMTP id h6mr7514271yhe.71.1340482955921;
	Sat, 23 Jun 2012 13:22:35 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id y10sm122913171yha.4.2012.06.23.13.22.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 23 Jun 2012 13:22:34 -0700 (PDT)
Message-ID: <4FE62585.10600@gmail.com>
Date: Sat, 23 Jun 2012 16:22:29 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
	<20120619161039.GB4296@US-SEA-R8XVZTX>
	<1340123764.24176.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340123764.24176.50.camel@zakaz.uk.xensource.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6/19/2012 12:36 PM, Ian Campbell wrote:
> On Tue, 2012-06-19 at 17:10 +0100, Matt Wilson wrote:
>> On Tue, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
>>>> # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
>>>> # Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
>>>> imported patch debian-lib-dir.patch
>>>>
>>>> diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
>>>> --- a/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
>>>> +++ b/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
>>>> @@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
>>>>   INCLUDEDIR = $(PREFIX)/include
>>>>   LIBLEAFDIR = lib
>>>>   LIBLEAFDIR_x86_32 = lib
>>>> -LIBLEAFDIR_x86_64 ?= lib64
>>>> +LIBLEAFDIR_x86_64 ?= lib
>>>>   LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>>>>   LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
>>>>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>>>>
>>>> Can you try a fresh build with this applied and see if that helps.
>>> I have applied this patch. I think libfsimage is somehow not being
>>> affected with this. Yet, linking /usr/lib64/fs ->  /usr/lib/fs solves
>>> the problem.
>> libfsimage is going to blindly look in /usr/lib64 on non-Itanium
>> 64-bit Linux platforms. See tools/libfsimage/common/fsimage_plugin.c:134
> Oh bloody hell, I hadn't spotted that.
>
> We should definitely be setting FSIMAGE_FSDIR to something sane based on
> LIBDIR and not letting all sorts of weird heuristics kick in.
>
> Ian.
>
>> #if defined(FSIMAGE_FSDIR)
>>          if (fsdir == NULL)
>>                  fsdir = FSIMAGE_FSDIR;
>> #elif defined(__sun__)
>>          if (fsdir == NULL)
>>                  fsdir = "/usr/lib/fs";
>>
>>          if (sizeof(void *) == 8)
>>                  isadir = "64/";
>> #elif defined(__ia64__)
>>          if (fsdir == NULL)
>>                  fsdir = "/usr/lib/fs";
>> #else
>>          if (fsdir == NULL) {
>>                  if (sizeof(void *) == 8)
>>                          fsdir = "/usr/lib64/fs";
>>                  else
>>                          fsdir = "/usr/lib/fs";
>>          }
>> #endif
>>
>> Matt

SOOO, just wondering, in the above patch, should these:

-LIBLEAFDIR_x86_64 ?= lib64
+LIBLEAFDIR_x86_64 ?= lib


be also changed if installing the latest Xen 4.2-unstable on like Debian 
Wheezy? OR is this something that is not important that important?



Just curious since even in the latest Xen 4.2-unstable rev-25494, it 
still has the

LIBLEAFDIR_x86_32 = lib
LIBLEAFDIR_x86_64 ?= lib64


in the StdGNU.mk file.

Thanks


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 20:23:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 20:23: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 1SiWqv-0006ba-Bt; Sat, 23 Jun 2012 20:22:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1SiWqt-0006bV-IY
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 20:22:39 +0000
Received: from [85.158.138.51:2763] by server-11.bemta-3.messagelabs.com id
	E6/E3-02904-E8526EF4; Sat, 23 Jun 2012 20:22:38 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340482956!29223888!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3934 invoked from network); 23 Jun 2012 20:22:37 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 20:22:37 -0000
Received: by ggnp1 with SMTP id p1so2600903ggn.32
	for <xen-devel@lists.xen.org>; Sat, 23 Jun 2012 13:22:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=K0ybpU7Pom6YDloj5pEoisCnK6DgVjCt5IN8CK92BSk=;
	b=xQ/y0aZqQHF8jh0HeXfPkMNgj9TmcSAzztTrcRlH8J9GoGqEL4AOVF9cRooSiSu7aQ
	9RChelkCYOILLBq1oDQSkw0BDtFRvhAbQYWtYYcW/eOPoXkSkJxtZmuSaNkkVAyFiOqB
	QN11AywvRAiR7HzkNc5PyL80w5krjhIY1b+mFK6LCD070Q7U/dKU4sEbUEpaovCGLGP1
	hP+58TSxFdZKa+glguccuL0YXyELy2hDppU0oKI8RpVLxPfVvXy6YQCJSLbaTCNR0Y/A
	UIHI/SpjcrUlPPXqgN79qHYM8f+VRQRgoXjEvKWuQAlL2kW/XatcnmFMDmlYueX3Mp+y
	7vmw==
Received: by 10.236.79.6 with SMTP id h6mr7514271yhe.71.1340482955921;
	Sat, 23 Jun 2012 13:22:35 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id y10sm122913171yha.4.2012.06.23.13.22.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 23 Jun 2012 13:22:34 -0700 (PDT)
Message-ID: <4FE62585.10600@gmail.com>
Date: Sat, 23 Jun 2012 16:22:29 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
	<20120619161039.GB4296@US-SEA-R8XVZTX>
	<1340123764.24176.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340123764.24176.50.camel@zakaz.uk.xensource.com>
Subject: Re: [Xen-devel] fsimage - no such file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6/19/2012 12:36 PM, Ian Campbell wrote:
> On Tue, 2012-06-19 at 17:10 +0100, Matt Wilson wrote:
>> On Tue, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
>>>> # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
>>>> # Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
>>>> imported patch debian-lib-dir.patch
>>>>
>>>> diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
>>>> --- a/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
>>>> +++ b/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
>>>> @@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
>>>>   INCLUDEDIR = $(PREFIX)/include
>>>>   LIBLEAFDIR = lib
>>>>   LIBLEAFDIR_x86_32 = lib
>>>> -LIBLEAFDIR_x86_64 ?= lib64
>>>> +LIBLEAFDIR_x86_64 ?= lib
>>>>   LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
>>>>   LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
>>>>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>>>>
>>>> Can you try a fresh build with this applied and see if that helps.
>>> I have applied this patch. I think libfsimage is somehow not being
>>> affected with this. Yet, linking /usr/lib64/fs ->  /usr/lib/fs solves
>>> the problem.
>> libfsimage is going to blindly look in /usr/lib64 on non-Itanium
>> 64-bit Linux platforms. See tools/libfsimage/common/fsimage_plugin.c:134
> Oh bloody hell, I hadn't spotted that.
>
> We should definitely be setting FSIMAGE_FSDIR to something sane based on
> LIBDIR and not letting all sorts of weird heuristics kick in.
>
> Ian.
>
>> #if defined(FSIMAGE_FSDIR)
>>          if (fsdir == NULL)
>>                  fsdir = FSIMAGE_FSDIR;
>> #elif defined(__sun__)
>>          if (fsdir == NULL)
>>                  fsdir = "/usr/lib/fs";
>>
>>          if (sizeof(void *) == 8)
>>                  isadir = "64/";
>> #elif defined(__ia64__)
>>          if (fsdir == NULL)
>>                  fsdir = "/usr/lib/fs";
>> #else
>>          if (fsdir == NULL) {
>>                  if (sizeof(void *) == 8)
>>                          fsdir = "/usr/lib64/fs";
>>                  else
>>                          fsdir = "/usr/lib/fs";
>>          }
>> #endif
>>
>> Matt

SOOO, just wondering, in the above patch, should these:

-LIBLEAFDIR_x86_64 ?= lib64
+LIBLEAFDIR_x86_64 ?= lib


be also changed if installing the latest Xen 4.2-unstable on like Debian 
Wheezy? OR is this something that is not important that important?



Just curious since even in the latest Xen 4.2-unstable rev-25494, it 
still has the

LIBLEAFDIR_x86_32 = lib
LIBLEAFDIR_x86_64 ?= lib64


in the StdGNU.mk file.

Thanks


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 20:56:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 20: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 1SiXNS-0006rE-49; Sat, 23 Jun 2012 20:56:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SiXNQ-0006r9-2i
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 20:56:16 +0000
Received: from [85.158.139.83:52101] by server-10.bemta-5.messagelabs.com id
	1C/03-02190-F6D26EF4; Sat, 23 Jun 2012 20:56:15 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340484972!24014592!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE5MDgyNQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21948 invoked from network); 23 Jun 2012 20:56:14 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 20:56:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340484974; x=1372020974;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=aDC76NNt5MDp6eNMBVuL+x1tvKnpqgKRx9heHrEYFnw=;
	b=mDTSH8o5zRd3Eu7T8agNi8Rj/DfzAeK0EQRmjivFoL8UBUov4Xybpjlj
	6GmOI2PpBUCeKqyxG7E4LNW9rqG4gg==;
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="755294548"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2012 20:56:11 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-51-220.sea3.amazon.com [10.50.51.220])
	by smtp-in-1104.vdc.amazon.com (8.13.8/8.13.8) with SMTP id
	q5NKuAbW005813; Sat, 23 Jun 2012 20:56:10 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Sat, 23 Jun 2012 13:56:01 -0700
Date: Sat, 23 Jun 2012 13:56:01 -0700
From: Matt Wilson <msw@amazon.com>
To: "cyberhawk001@gmail.com" <cyberhawk001@gmail.com>
Message-ID: <20120623205601.GG2640@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
	<20120619161039.GB4296@US-SEA-R8XVZTX>
	<1340123764.24176.50.camel@zakaz.uk.xensource.com>
	<4FE62585.10600@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE62585.10600@gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fsimage - no such 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, Jun 23, 2012 at 01:22:29PM -0700, cyberhawk001@gmail.com wrote:
> >> On Tue, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
> >>>> # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
> >>>> # Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
> >>>> imported patch debian-lib-dir.patch
> >>>>
> >>>> diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
> >>>> --- a/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> >>>> +++ b/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> >>>> @@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
> >>>>   INCLUDEDIR = $(PREFIX)/include
> >>>>   LIBLEAFDIR = lib
> >>>>   LIBLEAFDIR_x86_32 = lib
> >>>> -LIBLEAFDIR_x86_64 ?= lib64
> >>>> +LIBLEAFDIR_x86_64 ?= lib
> >>>>   LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> >>>>   LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> >>>>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> >>>>
> 
> SOOO, just wondering, in the above patch, should these:
> 
> -LIBLEAFDIR_x86_64 ?= lib64
> +LIBLEAFDIR_x86_64 ?= lib
> 
> 
> be also changed if installing the latest Xen 4.2-unstable on like Debian 
> Wheezy? OR is this something that is not important that important?

Ultimately the LIBLEAFDIR bits should go away entirely. The person
building Xen should specify where libraries live at ./configure time
with, for example, --libdir=/usr/lib64 (for 64-bit OSs like Fedora,
RHEL, OpenSUSE and SLES) or --libdir=/usr/lib/x86_64-linux-gnu (for
64-bit systems like Ubuntu 12.04). More specifically, on Debian based
multiarch platforms, you'd use:
 ./configure --libdir=/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)

> Just curious since even in the latest Xen 4.2-unstable rev-25494, it 
> still has the
> 
> LIBLEAFDIR_x86_32 = lib
> LIBLEAFDIR_x86_64 ?= lib64
> 
> 
> in the StdGNU.mk file.

Right, nothing has been committed while I've been working through the
feedback on the patch. I'll post v3 in just a moment which hopefully
has addressed all concerns.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 20:56:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 20: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 1SiXNS-0006rE-49; Sat, 23 Jun 2012 20:56:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SiXNQ-0006r9-2i
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 20:56:16 +0000
Received: from [85.158.139.83:52101] by server-10.bemta-5.messagelabs.com id
	1C/03-02190-F6D26EF4; Sat, 23 Jun 2012 20:56:15 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340484972!24014592!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE5MDgyNQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21948 invoked from network); 23 Jun 2012 20:56:14 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 20:56:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340484974; x=1372020974;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=aDC76NNt5MDp6eNMBVuL+x1tvKnpqgKRx9heHrEYFnw=;
	b=mDTSH8o5zRd3Eu7T8agNi8Rj/DfzAeK0EQRmjivFoL8UBUov4Xybpjlj
	6GmOI2PpBUCeKqyxG7E4LNW9rqG4gg==;
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="755294548"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2012 20:56:11 +0000
Received: from US-SEA-R8XVZTX (vpn-10-50-51-220.sea3.amazon.com [10.50.51.220])
	by smtp-in-1104.vdc.amazon.com (8.13.8/8.13.8) with SMTP id
	q5NKuAbW005813; Sat, 23 Jun 2012 20:56:10 GMT
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation);
	Sat, 23 Jun 2012 13:56:01 -0700
Date: Sat, 23 Jun 2012 13:56:01 -0700
From: Matt Wilson <msw@amazon.com>
To: "cyberhawk001@gmail.com" <cyberhawk001@gmail.com>
Message-ID: <20120623205601.GG2640@US-SEA-R8XVZTX>
References: <CABA5EEuVTVOHSPD6j1TvHivL8wtmS=NudAL=5wcQOm99qPPvBw@mail.gmail.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDEED66156583@LONPMAILBOX01.citrite.net>
	<1340103453.24176.7.camel@zakaz.uk.xensource.com>
	<CABA5EEtD32O+M2yA=WiHuGvBv0oF=VRd7WnisvpnHuau40Qj3Q@mail.gmail.com>
	<20120619161039.GB4296@US-SEA-R8XVZTX>
	<1340123764.24176.50.camel@zakaz.uk.xensource.com>
	<4FE62585.10600@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE62585.10600@gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fsimage - no such 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, Jun 23, 2012 at 01:22:29PM -0700, cyberhawk001@gmail.com wrote:
> >> On Tue, Jun 19, 2012 at 04:19:27AM -0700, Mohammad Hedayati wrote:
> >>>> # Node ID 6eabee6807b48c72bcc35a28170f0729500def85
> >>>> # Parent  80c0677f0f8370a4542aab81ab93380b0dab25db
> >>>> imported patch debian-lib-dir.patch
> >>>>
> >>>> diff -r 80c0677f0f83 -r 6eabee6807b4 config/StdGNU.mk
> >>>> --- a/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> >>>> +++ b/config/StdGNU.mk  Wed Jun 13 09:27:53 2012 +0100
> >>>> @@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
> >>>>   INCLUDEDIR = $(PREFIX)/include
> >>>>   LIBLEAFDIR = lib
> >>>>   LIBLEAFDIR_x86_32 = lib
> >>>> -LIBLEAFDIR_x86_64 ?= lib64
> >>>> +LIBLEAFDIR_x86_64 ?= lib
> >>>>   LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> >>>>   LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> >>>>   LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> >>>>
> 
> SOOO, just wondering, in the above patch, should these:
> 
> -LIBLEAFDIR_x86_64 ?= lib64
> +LIBLEAFDIR_x86_64 ?= lib
> 
> 
> be also changed if installing the latest Xen 4.2-unstable on like Debian 
> Wheezy? OR is this something that is not important that important?

Ultimately the LIBLEAFDIR bits should go away entirely. The person
building Xen should specify where libraries live at ./configure time
with, for example, --libdir=/usr/lib64 (for 64-bit OSs like Fedora,
RHEL, OpenSUSE and SLES) or --libdir=/usr/lib/x86_64-linux-gnu (for
64-bit systems like Ubuntu 12.04). More specifically, on Debian based
multiarch platforms, you'd use:
 ./configure --libdir=/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)

> Just curious since even in the latest Xen 4.2-unstable rev-25494, it 
> still has the
> 
> LIBLEAFDIR_x86_32 = lib
> LIBLEAFDIR_x86_64 ?= lib64
> 
> 
> in the StdGNU.mk file.

Right, nothing has been committed while I've been working through the
feedback on the patch. I'll post v3 in just a moment which hopefully
has addressed all concerns.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 21:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 21: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 1SiXdZ-0007Nj-9I; Sat, 23 Jun 2012 21:12:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SiXdX-0007NZ-HM
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 21:12:55 +0000
Received: from [85.158.139.83:51330] by server-2.bemta-5.messagelabs.com id
	F6/96-04598-65136EF4; Sat, 23 Jun 2012 21:12:54 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340485971!29061665!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU3ODg3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22981 invoked from network); 23 Jun 2012 21:12:53 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 21:12:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340485973; x=1372021973;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=JcJGx0eBlgvjJhf+saqM1IcNZlUHWKZbHVMqEi/hO74=;
	b=mUUi1DJodekEmWlKbgze4PbSev0giED8S8aq+T9EFLpNDmQxOm/SsITe
	uakAlYD8pbpEhAjE2mro2tTogsj7cg==;
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="319572082"
Received: from smtp-in-0191.sea3.amazon.com ([10.224.12.28])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2012 21:12:50 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-0191.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5NLCo9W001556; Sat, 23 Jun 2012 21:12:50 GMT
MIME-Version: 1.0
X-Mercurial-Node: 177d5f1e353fe4001f69a5ec18ccccab9d9dddea
Message-Id: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Sat, 23 Jun 2012 21:12:13 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shared libraries are automatically installed into /usr/lib
or /usr/lib64, depending on the supplied --prefix value and
$(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.

With this change, packagers can supply the desired location for shared
libraries on the ./configure command line. Packagers need to note that
the default behaviour on 64-bit Linux systems will be to install shared
libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
to ./configure.

Additionally, the libfsimage plugins are now loaded explicitly from
$LIBDIR/fs, removing platform-based decision trees in code.

Signed-off-by: Matt Wilson <msw@amazon.com>

Changes since v2:
 * Drop the #ifndef check for FSIMAGE_FSDIR, let the normal compiler
   error provide information that something is wrong.
 * Don't include config/Tools.mk from the top level Config.mk.
 * Just assume that libraries specified via EXTRA_PREFIX live in
   $(EXTRA_LIB)/lib. EXTRA_PREFIX should probably just go away one day.

diff -r 32034d1914a6 -r 177d5f1e353f Config.mk
--- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -67,7 +67,7 @@ endef
 
 ifneq ($(EXTRA_PREFIX),)
 EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
-EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
+EXTRA_LIB += $(EXTRA_PREFIX)/lib
 endif
 
 PYTHON      ?= python
diff -r 32034d1914a6 -r 177d5f1e353f config/NetBSD.mk
--- a/config/NetBSD.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/NetBSD.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,7 +1,6 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
 # Override settings for this OS
-LIBLEAFDIR_x86_64 = lib
 LIBEXEC = $(PREFIX)/libexec
 PRIVATE_BINDIR = $(BINDIR)
 
diff -r 32034d1914a6 -r 177d5f1e353f config/StdGNU.mk
--- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
-LIBEXEC = $(LIBDIR_x86_32)/xen/bin
+LIBEXEC = $(PREFIX)/lib/xen/bin
 SHAREDIR = $(PREFIX)/share
 MANDIR = $(SHAREDIR)/man
 MAN1DIR = $(MANDIR)/man1
diff -r 32034d1914a6 -r 177d5f1e353f config/SunOS.mk
--- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -22,10 +22,6 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_64 = lib/amd64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 MANDIR = $(PREFIX)/share/man
 MAN1DIR = $(MANDIR)/man1
 MAN8DIR = $(MANDIR)/man8
diff -r 32034d1914a6 -r 177d5f1e353f config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
@@ -1,6 +1,7 @@
 # Prefix and install folder
 PREFIX              := @prefix@
-LIBLEAFDIR_x86_64   := @LIB_PATH@
+exec_prefix         := @exec_prefix@
+LIBDIR              := @libdir@
 
 # A debug build of tools?
 debug               := @debug@
diff -r 32034d1914a6 -r 177d5f1e353f config/x86_64.mk
--- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -10,9 +10,6 @@ CONFIG_IOEMU := y
 
 CFLAGS += -m64
 
-LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
-LIBDIR = $(LIBDIR_x86_64)
-
 SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
 
 # Use only if calling $(LD) directly.
diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/Rules.mk
--- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,17 +1,12 @@
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
+CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
 CFLAGS += -Werror -D_GNU_SOURCE
 LDFLAGS += -L../common/
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
 
-FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
-FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
-FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
-FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
-FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
-FSDIR = $(FSDIR-y)
+FSDIR = $(LIBDIR)/fs
 
 FSLIB = fsimage.so
 
@@ -20,8 +15,8 @@ fs-all: $(FSLIB)
 
 .PHONY: fs-install
 fs-install: fs-all
-	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
-	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
+	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
 
 $(FSLIB): $(PIC_OBJS)
 	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/Makefile
--- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,5 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 MAJOR = 1.0
 MINOR = 0
diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/fsimage_plugin.c
--- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
@@ -122,7 +122,6 @@ fail:
 static int load_plugins(void)
 {
 	const char *fsdir = getenv("FSIMAGE_FSDIR");
-	const char *isadir = "";
 	struct dirent *dp = NULL;
 	struct dirent *dpp;
 	DIR *dir = NULL;
@@ -131,26 +130,8 @@ static int load_plugins(void)
 	int err;
 	int ret = -1;
 
-#if defined(FSIMAGE_FSDIR)
 	if (fsdir == NULL)
 		fsdir = FSIMAGE_FSDIR;
-#elif defined(__sun__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-
-	if (sizeof(void *) == 8)
-		isadir = "64/";
-#elif defined(__ia64__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-#else
-	if (fsdir == NULL) {
-		if (sizeof(void *) == 8)
-			fsdir = "/usr/lib64/fs";
-		else
-			fsdir = "/usr/lib/fs";
-	}
-#endif
 
 	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
 		goto fail;
@@ -172,8 +153,8 @@ static int load_plugins(void)
 		if (strcmp(dpp->d_name, "..") == 0)
 			continue;
 
-		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
-		    dpp->d_name, isadir);
+		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
+			dpp->d_name);
 
 		if (init_plugin(tmp) != 0)
 			goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 23 21:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Jun 2012 21: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 1SiXdZ-0007Nj-9I; Sat, 23 Jun 2012 21:12:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SiXdX-0007NZ-HM
	for xen-devel@lists.xen.org; Sat, 23 Jun 2012 21:12:55 +0000
Received: from [85.158.139.83:51330] by server-2.bemta-5.messagelabs.com id
	F6/96-04598-65136EF4; Sat, 23 Jun 2012 21:12:54 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340485971!29061665!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU3ODg3\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22981 invoked from network); 23 Jun 2012 21:12:53 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jun 2012 21:12:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340485973; x=1372021973;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=JcJGx0eBlgvjJhf+saqM1IcNZlUHWKZbHVMqEi/hO74=;
	b=mUUi1DJodekEmWlKbgze4PbSev0giED8S8aq+T9EFLpNDmQxOm/SsITe
	uakAlYD8pbpEhAjE2mro2tTogsj7cg==;
X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="319572082"
Received: from smtp-in-0191.sea3.amazon.com ([10.224.12.28])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2012 21:12:50 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-0191.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5NLCo9W001556; Sat, 23 Jun 2012 21:12:50 GMT
MIME-Version: 1.0
X-Mercurial-Node: 177d5f1e353fe4001f69a5ec18ccccab9d9dddea
Message-Id: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Sat, 23 Jun 2012 21:12:13 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] tools: honour --libdir when it is passed to
	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shared libraries are automatically installed into /usr/lib
or /usr/lib64, depending on the supplied --prefix value and
$(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.

With this change, packagers can supply the desired location for shared
libraries on the ./configure command line. Packagers need to note that
the default behaviour on 64-bit Linux systems will be to install shared
libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
to ./configure.

Additionally, the libfsimage plugins are now loaded explicitly from
$LIBDIR/fs, removing platform-based decision trees in code.

Signed-off-by: Matt Wilson <msw@amazon.com>

Changes since v2:
 * Drop the #ifndef check for FSIMAGE_FSDIR, let the normal compiler
   error provide information that something is wrong.
 * Don't include config/Tools.mk from the top level Config.mk.
 * Just assume that libraries specified via EXTRA_PREFIX live in
   $(EXTRA_LIB)/lib. EXTRA_PREFIX should probably just go away one day.

diff -r 32034d1914a6 -r 177d5f1e353f Config.mk
--- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -67,7 +67,7 @@ endef
 
 ifneq ($(EXTRA_PREFIX),)
 EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
-EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
+EXTRA_LIB += $(EXTRA_PREFIX)/lib
 endif
 
 PYTHON      ?= python
diff -r 32034d1914a6 -r 177d5f1e353f config/NetBSD.mk
--- a/config/NetBSD.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/NetBSD.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,7 +1,6 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
 # Override settings for this OS
-LIBLEAFDIR_x86_64 = lib
 LIBEXEC = $(PREFIX)/libexec
 PRIVATE_BINDIR = $(BINDIR)
 
diff -r 32034d1914a6 -r 177d5f1e353f config/StdGNU.mk
--- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
-LIBEXEC = $(LIBDIR_x86_32)/xen/bin
+LIBEXEC = $(PREFIX)/lib/xen/bin
 SHAREDIR = $(PREFIX)/share
 MANDIR = $(SHAREDIR)/man
 MAN1DIR = $(MANDIR)/man1
diff -r 32034d1914a6 -r 177d5f1e353f config/SunOS.mk
--- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -22,10 +22,6 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
 PREFIX ?= /usr
 BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
-LIBLEAFDIR = lib
-LIBLEAFDIR_x86_64 = lib/amd64
-LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
-LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
 MANDIR = $(PREFIX)/share/man
 MAN1DIR = $(MANDIR)/man1
 MAN8DIR = $(MANDIR)/man8
diff -r 32034d1914a6 -r 177d5f1e353f config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
@@ -1,6 +1,7 @@
 # Prefix and install folder
 PREFIX              := @prefix@
-LIBLEAFDIR_x86_64   := @LIB_PATH@
+exec_prefix         := @exec_prefix@
+LIBDIR              := @libdir@
 
 # A debug build of tools?
 debug               := @debug@
diff -r 32034d1914a6 -r 177d5f1e353f config/x86_64.mk
--- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -10,9 +10,6 @@ CONFIG_IOEMU := y
 
 CFLAGS += -m64
 
-LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
-LIBDIR = $(LIBDIR_x86_64)
-
 SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
 
 # Use only if calling $(LD) directly.
diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/Rules.mk
--- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
@@ -1,17 +1,12 @@
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
+CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
 CFLAGS += -Werror -D_GNU_SOURCE
 LDFLAGS += -L../common/
 
 PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
 
-FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
-FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
-FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
-FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
-FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
-FSDIR = $(FSDIR-y)
+FSDIR = $(LIBDIR)/fs
 
 FSLIB = fsimage.so
 
@@ -20,8 +15,8 @@ fs-all: $(FSLIB)
 
 .PHONY: fs-install
 fs-install: fs-all
-	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
-	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
+	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
 
 $(FSLIB): $(PIC_OBJS)
 	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/Makefile
--- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
@@ -1,5 +1,5 @@
 XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
 
 MAJOR = 1.0
 MINOR = 0
diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/fsimage_plugin.c
--- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
@@ -122,7 +122,6 @@ fail:
 static int load_plugins(void)
 {
 	const char *fsdir = getenv("FSIMAGE_FSDIR");
-	const char *isadir = "";
 	struct dirent *dp = NULL;
 	struct dirent *dpp;
 	DIR *dir = NULL;
@@ -131,26 +130,8 @@ static int load_plugins(void)
 	int err;
 	int ret = -1;
 
-#if defined(FSIMAGE_FSDIR)
 	if (fsdir == NULL)
 		fsdir = FSIMAGE_FSDIR;
-#elif defined(__sun__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-
-	if (sizeof(void *) == 8)
-		isadir = "64/";
-#elif defined(__ia64__)
-	if (fsdir == NULL)
-		fsdir = "/usr/lib/fs";
-#else
-	if (fsdir == NULL) {
-		if (sizeof(void *) == 8)
-			fsdir = "/usr/lib64/fs";
-		else
-			fsdir = "/usr/lib/fs";
-	}
-#endif
 
 	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
 		goto fail;
@@ -172,8 +153,8 @@ static int load_plugins(void)
 		if (strcmp(dpp->d_name, "..") == 0)
 			continue;
 
-		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
-		    dpp->d_name, isadir);
+		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
+			dpp->d_name);
 
 		if (init_plugin(tmp) != 0)
 			goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 02:22:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 02:22: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 1SicSu-0005Fm-G3; Sun, 24 Jun 2012 02:22:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SicSt-0005Fh-5U
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 02:22:15 +0000
Received: from [85.158.138.51:22605] by server-8.bemta-3.messagelabs.com id
	40/E0-06157-6D976EF4; Sun, 24 Jun 2012 02:22:14 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340504532!26295466!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12373 invoked from network); 24 Jun 2012 02:22:13 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 02:22:13 -0000
Received: by obbta14 with SMTP id ta14so5782917obb.32
	for <xen-devel@lists.xen.org>; Sat, 23 Jun 2012 19:22:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=R0h8vwrNwvskvHFhtq9oJtn2TkUY88LQcig1TDP5NmA=;
	b=CESNSQ/J1xToLScNzAjXGdk2Zgh5VqRpN3WCUQQHH1xz/tsnRC3a1Dn06OuJyCYmgG
	dNJHztsxSBMQZ3jDIOXR2IvOLSKxsBqxvhNXDB3wCDkyYcOdHuQTwY4h5pTuXkAW/T5R
	p7YR45nn+dTXVjOlmFnGwbcfarLd1JcelxilTtJIne9VoOk6rPNBKezX/UMbhgliO5Nn
	Z+Qqpn2mcbaQe3HV4/cc7zdBeoXUhQZi1xTypu5Vy/drwjDjPvO0t8tx/fWhfi7qbl18
	QteSYq47++Ka0VZbOcXAALcEpO38+GHrzWrmDehTYAmanog/N2yynPMb54FMX8KNwR1J
	VjEg==
Received: by 10.182.14.101 with SMTP id o5mr7736842obc.1.1340504531713; Sat,
	23 Jun 2012 19:22:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sat, 23 Jun 2012 19:21:50 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE21084020000780008AE60@nat28.tlf.novell.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
From: Rolu <rolu@roce.org>
Date: Sun, 24 Jun 2012 04:21:50 +0200
Message-ID: <CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQm5OVU51AwsVx5wrOi8cCIOps3CgBQ514ZvXo2Gnw7Y5BW/sA2tMHaEMSn6uYHWyiFmIFs+
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.06.12 at 15:58, Rolu <rolu@roce.org> wrote:
>> On Tue, Jun 19, 2012 at 11:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> Unless this is in the guest kernel, we'll likely need a code fix here,
>>> but for determining what and where, we'd need you to provide
>>> the qemu log for the domain as well (there ought to be entries
>>> starting with "Update msi with pirq", and the gflags value is of
>>> particular interest). Depending on what we see, we may then
>>> need you to do some further debugging.
>>>
>>
>> There are, these: (I've copied the full logs below)
>>
>> pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
>> pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
>> pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f
>
> Okay, so at that point the bad value is already there. I'd
> suggest taking it up the usage chain, so adding some logging
> in pt_msgdata_reg_write() (where the original value -
> ptdev->msi->data - is being computed) would likely be a
> good first step.
>

This took a while as I'm not very familiar with it all yet.

The write function gets passed a *value of 0x4300 and that is also
what gets assigned to ptdev->msi->data. The delivery mode is bit 8 to
10 of that value, which is indeed 3. lspci -vvv on the domU also shows
that the MSI data field is 4300, but I suppose it just reads that back
from qemu. Anyway, this seems in order, at least as far as I can see.

> At the same time, adding logging to the guest kernel would
> be nice, to see what value it actually writes (in a current
> kernel this would be in __write_msi_msg()).
>

Turns out that msg->data here is also 0x4300, so it seems the guest
kernel is producing these values. I caused it to make a stack trace
and this pointed back to xen_hvm_setup_msi_irqs. This function uses
the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
current data field and if it isn't equal to the macro it uses
xen_msi_compose_msg to make a new message, but that function just sets
the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
then gets passed to __write_msi_msg and that's that. There are no
other writes through __write_msi_msg (except for the same thing for
other devices).

The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
decoded as the delivery mode, so it seems the kernel is intentionally
setting it to 3.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 02:22:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 02:22: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 1SicSu-0005Fm-G3; Sun, 24 Jun 2012 02:22:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SicSt-0005Fh-5U
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 02:22:15 +0000
Received: from [85.158.138.51:22605] by server-8.bemta-3.messagelabs.com id
	40/E0-06157-6D976EF4; Sun, 24 Jun 2012 02:22:14 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340504532!26295466!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12373 invoked from network); 24 Jun 2012 02:22:13 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 02:22:13 -0000
Received: by obbta14 with SMTP id ta14so5782917obb.32
	for <xen-devel@lists.xen.org>; Sat, 23 Jun 2012 19:22:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=R0h8vwrNwvskvHFhtq9oJtn2TkUY88LQcig1TDP5NmA=;
	b=CESNSQ/J1xToLScNzAjXGdk2Zgh5VqRpN3WCUQQHH1xz/tsnRC3a1Dn06OuJyCYmgG
	dNJHztsxSBMQZ3jDIOXR2IvOLSKxsBqxvhNXDB3wCDkyYcOdHuQTwY4h5pTuXkAW/T5R
	p7YR45nn+dTXVjOlmFnGwbcfarLd1JcelxilTtJIne9VoOk6rPNBKezX/UMbhgliO5Nn
	Z+Qqpn2mcbaQe3HV4/cc7zdBeoXUhQZi1xTypu5Vy/drwjDjPvO0t8tx/fWhfi7qbl18
	QteSYq47++Ka0VZbOcXAALcEpO38+GHrzWrmDehTYAmanog/N2yynPMb54FMX8KNwR1J
	VjEg==
Received: by 10.182.14.101 with SMTP id o5mr7736842obc.1.1340504531713; Sat,
	23 Jun 2012 19:22:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sat, 23 Jun 2012 19:21:50 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE21084020000780008AE60@nat28.tlf.novell.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
From: Rolu <rolu@roce.org>
Date: Sun, 24 Jun 2012 04:21:50 +0200
Message-ID: <CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQm5OVU51AwsVx5wrOi8cCIOps3CgBQ514ZvXo2Gnw7Y5BW/sA2tMHaEMSn6uYHWyiFmIFs+
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.06.12 at 15:58, Rolu <rolu@roce.org> wrote:
>> On Tue, Jun 19, 2012 at 11:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> Unless this is in the guest kernel, we'll likely need a code fix here,
>>> but for determining what and where, we'd need you to provide
>>> the qemu log for the domain as well (there ought to be entries
>>> starting with "Update msi with pirq", and the gflags value is of
>>> particular interest). Depending on what we see, we may then
>>> need you to do some further debugging.
>>>
>>
>> There are, these: (I've copied the full logs below)
>>
>> pt_msi_update: Update msi with pirq 37 gvec 0 gflags 3031
>> pt_msi_update: Update msi with pirq 36 gvec 0 gflags 3030
>> pt_msi_update: Update msi with pirq 35 gvec 0 gflags 302f
>
> Okay, so at that point the bad value is already there. I'd
> suggest taking it up the usage chain, so adding some logging
> in pt_msgdata_reg_write() (where the original value -
> ptdev->msi->data - is being computed) would likely be a
> good first step.
>

This took a while as I'm not very familiar with it all yet.

The write function gets passed a *value of 0x4300 and that is also
what gets assigned to ptdev->msi->data. The delivery mode is bit 8 to
10 of that value, which is indeed 3. lspci -vvv on the domU also shows
that the MSI data field is 4300, but I suppose it just reads that back
from qemu. Anyway, this seems in order, at least as far as I can see.

> At the same time, adding logging to the guest kernel would
> be nice, to see what value it actually writes (in a current
> kernel this would be in __write_msi_msg()).
>

Turns out that msg->data here is also 0x4300, so it seems the guest
kernel is producing these values. I caused it to make a stack trace
and this pointed back to xen_hvm_setup_msi_irqs. This function uses
the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
current data field and if it isn't equal to the macro it uses
xen_msi_compose_msg to make a new message, but that function just sets
the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
then gets passed to __write_msi_msg and that's that. There are no
other writes through __write_msi_msg (except for the same thing for
other devices).

The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
decoded as the delivery mode, so it seems the kernel is intentionally
setting it to 3.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 07:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 07: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 1SihAk-0007SY-GW; Sun, 24 Jun 2012 07:23:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SihAi-0007ST-EN
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 07:23:48 +0000
Received: from [193.109.254.147:52368] by server-10.bemta-14.messagelabs.com
	id 67/56-05433-380C6EF4; Sun, 24 Jun 2012 07:23:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340522626!9139912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0MzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29819 invoked from network); 24 Jun 2012 07:23:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 07:23:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,466,1336348800"; d="scan'208";a="13185359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jun 2012 07:22:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 24 Jun 2012 08:22:43 +0100
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 1Sih9f-0002nG-K3;
	Sun, 24 Jun 2012 07:22:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sih9f-0001Jp-DN;
	Sun, 24 Jun 2012 08:22:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13359-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Jun 2012 08:22:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13359: 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 13359 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13359/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13354
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 13354 pass in 13359

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13354 like 13352

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  836db8c4b9f9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 07:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 07: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 1SihAk-0007SY-GW; Sun, 24 Jun 2012 07:23:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SihAi-0007ST-EN
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 07:23:48 +0000
Received: from [193.109.254.147:52368] by server-10.bemta-14.messagelabs.com
	id 67/56-05433-380C6EF4; Sun, 24 Jun 2012 07:23:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340522626!9139912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0MzQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29819 invoked from network); 24 Jun 2012 07:23:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 07:23:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,466,1336348800"; d="scan'208";a="13185359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jun 2012 07:22:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 24 Jun 2012 08:22:43 +0100
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 1Sih9f-0002nG-K3;
	Sun, 24 Jun 2012 07:22:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sih9f-0001Jp-DN;
	Sun, 24 Jun 2012 08:22:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13359-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Jun 2012 08:22:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13359: 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 13359 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13359/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13354
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 13354 pass in 13359

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13354 like 13352

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  836db8c4b9f9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 14:12:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 14: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 1SinXl-0001z4-RH; Sun, 24 Jun 2012 14:12:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bickys1986@gmail.com>) id 1SinXj-0001yz-S7
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 14:12:00 +0000
Received: from [85.158.143.99:30455] by server-3.bemta-4.messagelabs.com id
	15/B5-05808-F2027EF4; Sun, 24 Jun 2012 14:11:59 +0000
X-Env-Sender: bickys1986@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340547117!27935038!1
X-Originating-IP: [209.85.214.171]
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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9679 invoked from network); 24 Jun 2012 14:11:58 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 14:11:58 -0000
Received: by obbef5 with SMTP id ef5so7646256obb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Jun 2012 07:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=WBYgoTZud03m/BzV6ViyZFoGIZBLi4dFDWaiQc2CeWg=;
	b=BPFux6MUWxjaU8INKxBoN0Pkdg7aWmHfsvDVU2pN0nNh+/Zb6p6iMT6QXEVgj5eF+d
	65nAWhJWB68tLTe9CbdMSPKR4i6cVudZZzdHiM+0aiW0ecpjmPMwS7PbT1bHCLcdik+K
	tmon52u4t692Yi87pYd0Lhhi3GT7mFu7NKKv5viQ26428XSCHBAfPmqLaHtSNhEyf/CT
	cd9/ylv59/MbZCgc7KlAgKldPiALozu8XOAsO+3hxPGjiqFchxQsM9SBlAptyoKFnO0b
	WaKdSGC3ndXwu3Qq4UVSPkBjKNNRBnf6m+ylDjypZSkthlWJ0m1W8DlW+H6lzYFX6Wh7
	bBHg==
MIME-Version: 1.0
Received: by 10.60.3.102 with SMTP id b6mr8955223oeb.35.1340547116655; Sun, 24
	Jun 2012 07:11:56 -0700 (PDT)
Received: by 10.76.33.104 with HTTP; Sun, 24 Jun 2012 07:11:56 -0700 (PDT)
Date: Sun, 24 Jun 2012 22:11:56 +0800
Message-ID: <CACavRyCqe0O0p==+9j_7UrsjE69SOb9Zjvd44Do2pB+4G6Wx8Q@mail.gmail.com>
From: zhen shi <bickys1986@gmail.com>
To: david.vrabel@citrix.com, keir@xen.org
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to find out lea instruction causes skype crash when
	starting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3740956781120254043=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3740956781120254043==
Content-Type: multipart/alternative; boundary=e89a8ff1c25eb1634a04c33872b0

--e89a8ff1c25eb1634a04c33872b0
Content-Type: text/plain; charset=ISO-8859-1

Hi david,
    I find you signed off a patch about "x86: emulate lea with two register
operands correctly" .In this patch,you described skype does a lea
instruction and will crash when starting if it does not get the exception.I
have used a tool named mentorKG.exe to make a LICENSE.TXT.but the software
crashes when starting.I used your patch,and find it works well.I wonder how
can you find it's the lea instruction which cause the application software
crash when starting.Can you give me some methods?

--e89a8ff1c25eb1634a04c33872b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi david,<div>=A0=A0 =A0I find you signed off a patch about &quot;x86: emul=
ate lea with two register operands correctly&quot; .In this patch,you descr=
ibed skype does a lea instruction and will crash when starting if it does n=
ot get the exception.I have used a tool named mentorKG.exe to make a LICENS=
E.TXT.but=A0the software crashes when starting.I used your patch,and find i=
t works well.I wonder how can you find it&#39;s the lea instruction which c=
ause the=A0application software crash when starting.Can you give me some me=
thods?</div>

--e89a8ff1c25eb1634a04c33872b0--


--===============3740956781120254043==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3740956781120254043==--


From xen-devel-bounces@lists.xen.org Sun Jun 24 14:12:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 14: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 1SinXl-0001z4-RH; Sun, 24 Jun 2012 14:12:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bickys1986@gmail.com>) id 1SinXj-0001yz-S7
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 14:12:00 +0000
Received: from [85.158.143.99:30455] by server-3.bemta-4.messagelabs.com id
	15/B5-05808-F2027EF4; Sun, 24 Jun 2012 14:11:59 +0000
X-Env-Sender: bickys1986@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340547117!27935038!1
X-Originating-IP: [209.85.214.171]
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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9679 invoked from network); 24 Jun 2012 14:11:58 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 14:11:58 -0000
Received: by obbef5 with SMTP id ef5so7646256obb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Jun 2012 07:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=WBYgoTZud03m/BzV6ViyZFoGIZBLi4dFDWaiQc2CeWg=;
	b=BPFux6MUWxjaU8INKxBoN0Pkdg7aWmHfsvDVU2pN0nNh+/Zb6p6iMT6QXEVgj5eF+d
	65nAWhJWB68tLTe9CbdMSPKR4i6cVudZZzdHiM+0aiW0ecpjmPMwS7PbT1bHCLcdik+K
	tmon52u4t692Yi87pYd0Lhhi3GT7mFu7NKKv5viQ26428XSCHBAfPmqLaHtSNhEyf/CT
	cd9/ylv59/MbZCgc7KlAgKldPiALozu8XOAsO+3hxPGjiqFchxQsM9SBlAptyoKFnO0b
	WaKdSGC3ndXwu3Qq4UVSPkBjKNNRBnf6m+ylDjypZSkthlWJ0m1W8DlW+H6lzYFX6Wh7
	bBHg==
MIME-Version: 1.0
Received: by 10.60.3.102 with SMTP id b6mr8955223oeb.35.1340547116655; Sun, 24
	Jun 2012 07:11:56 -0700 (PDT)
Received: by 10.76.33.104 with HTTP; Sun, 24 Jun 2012 07:11:56 -0700 (PDT)
Date: Sun, 24 Jun 2012 22:11:56 +0800
Message-ID: <CACavRyCqe0O0p==+9j_7UrsjE69SOb9Zjvd44Do2pB+4G6Wx8Q@mail.gmail.com>
From: zhen shi <bickys1986@gmail.com>
To: david.vrabel@citrix.com, keir@xen.org
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to find out lea instruction causes skype crash when
	starting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3740956781120254043=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3740956781120254043==
Content-Type: multipart/alternative; boundary=e89a8ff1c25eb1634a04c33872b0

--e89a8ff1c25eb1634a04c33872b0
Content-Type: text/plain; charset=ISO-8859-1

Hi david,
    I find you signed off a patch about "x86: emulate lea with two register
operands correctly" .In this patch,you described skype does a lea
instruction and will crash when starting if it does not get the exception.I
have used a tool named mentorKG.exe to make a LICENSE.TXT.but the software
crashes when starting.I used your patch,and find it works well.I wonder how
can you find it's the lea instruction which cause the application software
crash when starting.Can you give me some methods?

--e89a8ff1c25eb1634a04c33872b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi david,<div>=A0=A0 =A0I find you signed off a patch about &quot;x86: emul=
ate lea with two register operands correctly&quot; .In this patch,you descr=
ibed skype does a lea instruction and will crash when starting if it does n=
ot get the exception.I have used a tool named mentorKG.exe to make a LICENS=
E.TXT.but=A0the software crashes when starting.I used your patch,and find i=
t works well.I wonder how can you find it&#39;s the lea instruction which c=
ause the=A0application software crash when starting.Can you give me some me=
thods?</div>

--e89a8ff1c25eb1634a04c33872b0--


--===============3740956781120254043==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3740956781120254043==--


From xen-devel-bounces@lists.xen.org Sun Jun 24 16:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 16:47: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 1Sipxu-0003ez-0b; Sun, 24 Jun 2012 16:47: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 1Sipxs-0003er-KP
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 16:47:08 +0000
Received: from [85.158.138.51:48675] by server-8.bemta-3.messagelabs.com id
	22/8E-06157-B8447EF4; Sun, 24 Jun 2012 16:47:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340556426!29249360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7245 invoked from network); 24 Jun 2012 16:47:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 16:47:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,467,1336348800"; d="scan'208";a="13187472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jun 2012 16:47:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 24 Jun 2012 17:47:05 +0100
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 1Sipxp-0005t0-LE;
	Sun, 24 Jun 2012 16:47:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sipxp-0007mw-9m;
	Sun, 24 Jun 2012 17:47:05 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13361-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Jun 2012 17:47:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13361: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13361 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/

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. 13100

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu 10 guest-saverestore           fail pass in 13356
 test-amd64-i386-xl            5 xen-boot                    fail pass in 13356

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail like 13100

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 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-i386-i386-win           16 leak-check/check             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-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 13356 never pass

version targeted for testing:
 linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
baseline version:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 16:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 16:47: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 1Sipxu-0003ez-0b; Sun, 24 Jun 2012 16:47: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 1Sipxs-0003er-KP
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 16:47:08 +0000
Received: from [85.158.138.51:48675] by server-8.bemta-3.messagelabs.com id
	22/8E-06157-B8447EF4; Sun, 24 Jun 2012 16:47:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340556426!29249360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7245 invoked from network); 24 Jun 2012 16:47:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 16:47:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,467,1336348800"; d="scan'208";a="13187472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jun 2012 16:47:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 24 Jun 2012 17:47:05 +0100
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 1Sipxp-0005t0-LE;
	Sun, 24 Jun 2012 16:47:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sipxp-0007mw-9m;
	Sun, 24 Jun 2012 17:47:05 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13361-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Jun 2012 17:47:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13361: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13361 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/

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. 13100

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-multivcpu 10 guest-saverestore           fail pass in 13356
 test-amd64-i386-xl            5 xen-boot                    fail pass in 13356

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail like 13100

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 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-i386-i386-win           16 leak-check/check             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-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 13356 never pass

version targeted for testing:
 linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
baseline version:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 18:43:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 18: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 1Sirlv-0004AM-4m; Sun, 24 Jun 2012 18:42:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sirlt-0004AH-Cp
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 18:42:53 +0000
Received: from [85.158.139.83:9969] by server-7.bemta-5.messagelabs.com id
	1E/A7-28276-CAF57EF4; Sun, 24 Jun 2012 18:42:52 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340563371!24094274!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 24 Jun 2012 18:42:51 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-6.tower-182.messagelabs.com with SMTP;
	24 Jun 2012 18:42:51 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id B3A495A0006
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 19:42:51 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id LXbMi-3-gSwz for <xen-devel@lists.xen.org>;
	Sun, 24 Jun 2012 19:42:49 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	74F535A0005
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 19:42:49 +0100 (BST)
Message-ID: <4FE75FAB.9040903@abpni.co.uk>
Date: Sun, 24 Jun 2012 19:42:51 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Intel Security 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-Transfer-Encoding: 7bit
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 Everyone,

Given that a lot of us run "untrusted" DomUs where the Domu 
administrator has full control over their PV kernel, could this Intel 
security issue impact the hypervisor and put other DomUs at risk?

http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64-intel-processor

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 18:43:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 18: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 1Sirlv-0004AM-4m; Sun, 24 Jun 2012 18:42:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sirlt-0004AH-Cp
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 18:42:53 +0000
Received: from [85.158.139.83:9969] by server-7.bemta-5.messagelabs.com id
	1E/A7-28276-CAF57EF4; Sun, 24 Jun 2012 18:42:52 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340563371!24094274!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 24 Jun 2012 18:42:51 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-6.tower-182.messagelabs.com with SMTP;
	24 Jun 2012 18:42:51 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id B3A495A0006
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 19:42:51 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id LXbMi-3-gSwz for <xen-devel@lists.xen.org>;
	Sun, 24 Jun 2012 19:42:49 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	74F535A0005
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 19:42:49 +0100 (BST)
Message-ID: <4FE75FAB.9040903@abpni.co.uk>
Date: Sun, 24 Jun 2012 19:42:51 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Intel Security 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-Transfer-Encoding: 7bit
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 Everyone,

Given that a lot of us run "untrusted" DomUs where the Domu 
administrator has full control over their PV kernel, could this Intel 
security issue impact the hypervisor and put other DomUs at risk?

http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64-intel-processor

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 19:02:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 19:02: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 1Sis4P-0004MP-Qy; Sun, 24 Jun 2012 19:02:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sis4O-0004MK-PX
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 19:02:00 +0000
Received: from [85.158.143.99:30641] by server-3.bemta-4.messagelabs.com id
	4A/6B-05808-82467EF4; Sun, 24 Jun 2012 19:02:00 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340564518!28282280!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7309 invoked from network); 24 Jun 2012 19:01:59 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 19:01:59 -0000
Received: by obbta14 with SMTP id ta14so7162623obb.32
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 12:01:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=PAXWDmaMoqXjN30DDVP2tsIjyMU/a+Xsw2DJBKdVwew=;
	b=WU/ADk+/IC+ah3+P8JIx7HrA5qriSLm5u2ceiTtibqwp0x7Pq0U4Ic7776jvmdvNdL
	brwJ1GQZCiRmbmILGY6+y438RVuvJKGuxom0jfwCzoXTVo2HUPEuMU3+qHV28PeIv+Uv
	VMW7ClY11oXvgY7naUj3PKD6FoHlsPLBAgucavB5+zH99xNCYWmnzFp2r6Lx2bIyk4EH
	IriC5FqQXw+KX0T2aT2pOAeyOQchEtmPmd47ieAfrVqhMUQZmxzH8cKhon6R02NDYOge
	vWc5DL8vtuvc7g3kIL89KTgp1gGfzoK5gMPug0nGaN2quwW58s0xDPCEA5uZan7l4LN1
	eSHg==
Received: by 10.60.30.194 with SMTP id u2mr9648384oeh.5.1340564517875; Sun, 24
	Jun 2012 12:01:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sun, 24 Jun 2012 12:01:37 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE75FAB.9040903@abpni.co.uk>
References: <4FE75FAB.9040903@abpni.co.uk>
From: Rolu <rolu@roce.org>
Date: Sun, 24 Jun 2012 21:01:37 +0200
Message-ID: <CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
X-Gm-Message-State: ALoCoQleMqdKGtq7G6ChyZ4oHle/dcmBpBTtgLcgR5mUHUBWKqHUzZAEmCUHSaVpuLZHg1kgKp1H
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Intel Security 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

On Sun, Jun 24, 2012 at 8:42 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> Hi Everyone,
>
> Given that a lot of us run "untrusted" DomUs where the Domu administrator
> has full control over their PV kernel, could this Intel security issue
> impact the hypervisor and put other DomUs at risk?
>
> http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64-intel-processor
>

That page links to http://www.kb.cert.org/vuls/id/649219 which links
to http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
which answers your question ;-)

Yes, it's an issue. There are patches.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 19:02:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 19:02: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 1Sis4P-0004MP-Qy; Sun, 24 Jun 2012 19:02:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sis4O-0004MK-PX
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 19:02:00 +0000
Received: from [85.158.143.99:30641] by server-3.bemta-4.messagelabs.com id
	4A/6B-05808-82467EF4; Sun, 24 Jun 2012 19:02:00 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340564518!28282280!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7309 invoked from network); 24 Jun 2012 19:01:59 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 19:01:59 -0000
Received: by obbta14 with SMTP id ta14so7162623obb.32
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 12:01:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=PAXWDmaMoqXjN30DDVP2tsIjyMU/a+Xsw2DJBKdVwew=;
	b=WU/ADk+/IC+ah3+P8JIx7HrA5qriSLm5u2ceiTtibqwp0x7Pq0U4Ic7776jvmdvNdL
	brwJ1GQZCiRmbmILGY6+y438RVuvJKGuxom0jfwCzoXTVo2HUPEuMU3+qHV28PeIv+Uv
	VMW7ClY11oXvgY7naUj3PKD6FoHlsPLBAgucavB5+zH99xNCYWmnzFp2r6Lx2bIyk4EH
	IriC5FqQXw+KX0T2aT2pOAeyOQchEtmPmd47ieAfrVqhMUQZmxzH8cKhon6R02NDYOge
	vWc5DL8vtuvc7g3kIL89KTgp1gGfzoK5gMPug0nGaN2quwW58s0xDPCEA5uZan7l4LN1
	eSHg==
Received: by 10.60.30.194 with SMTP id u2mr9648384oeh.5.1340564517875; Sun, 24
	Jun 2012 12:01:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sun, 24 Jun 2012 12:01:37 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FE75FAB.9040903@abpni.co.uk>
References: <4FE75FAB.9040903@abpni.co.uk>
From: Rolu <rolu@roce.org>
Date: Sun, 24 Jun 2012 21:01:37 +0200
Message-ID: <CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
X-Gm-Message-State: ALoCoQleMqdKGtq7G6ChyZ4oHle/dcmBpBTtgLcgR5mUHUBWKqHUzZAEmCUHSaVpuLZHg1kgKp1H
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Intel Security 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

On Sun, Jun 24, 2012 at 8:42 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> Hi Everyone,
>
> Given that a lot of us run "untrusted" DomUs where the Domu administrator
> has full control over their PV kernel, could this Intel security issue
> impact the hypervisor and put other DomUs at risk?
>
> http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64-intel-processor
>

That page links to http://www.kb.cert.org/vuls/id/649219 which links
to http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
which answers your question ;-)

Yes, it's an issue. There are patches.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 19:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 19:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sis8n-0004UG-GJ; Sun, 24 Jun 2012 19:06:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sis8m-0004UA-37
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 19:06:32 +0000
Received: from [85.158.143.99:26736] by server-2.bemta-4.messagelabs.com id
	9B/C0-17938-73567EF4; Sun, 24 Jun 2012 19:06:31 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340564790!27954258!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28722 invoked from network); 24 Jun 2012 19:06:30 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Jun 2012 19:06:30 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id CDF535A0006
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 20:06:30 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id cDM6PmKvtxE5 for <xen-devel@lists.xen.org>;
	Sun, 24 Jun 2012 20:06:28 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	62EB35A0005; Sun, 24 Jun 2012 20:06:27 +0100 (BST)
Message-ID: <4FE76535.1090801@abpni.co.uk>
Date: Sun, 24 Jun 2012 20:06:29 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Rolu <rolu@roce.org>
References: <4FE75FAB.9040903@abpni.co.uk>
	<CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
In-Reply-To: <CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Intel Security 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 24/06/2012 20:01, Rolu wrote:
> On Sun, Jun 24, 2012 at 8:42 PM, Jonathan Tripathy<jonnyt@abpni.co.uk>  wrote:
>> Hi Everyone,
>>
>> Given that a lot of us run "untrusted" DomUs where the Domu administrator
>> has full control over their PV kernel, could this Intel security issue
>> impact the hypervisor and put other DomUs at risk?
>>
>> http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64-intel-processor
>>
> That page links to http://www.kb.cert.org/vuls/id/649219 which links
> to http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
> which answers your question ;-)
>
> Yes, it's an issue. There are patches.
Silly me! I've been following the inclusion of that Xen patch as well! I just didn't put 2+2 together.

Thanks for your time!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 19:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 19:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sis8n-0004UG-GJ; Sun, 24 Jun 2012 19:06:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1Sis8m-0004UA-37
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 19:06:32 +0000
Received: from [85.158.143.99:26736] by server-2.bemta-4.messagelabs.com id
	9B/C0-17938-73567EF4; Sun, 24 Jun 2012 19:06:31 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340564790!27954258!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28722 invoked from network); 24 Jun 2012 19:06:30 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Jun 2012 19:06:30 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id CDF535A0006
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 20:06:30 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at mail1.mail.gosport.corp.uk.abpni.net
Received: from mail1.gosport.uk.corp.abpni.net ([127.0.0.1])
	by localhost (mail1.mail.gosport.corp.uk.abpni.net [127.0.0.1])
	(amavisd-new, port 10024)
	with ESMTP id cDM6PmKvtxE5 for <xen-devel@lists.xen.org>;
	Sun, 24 Jun 2012 20:06:28 +0100 (BST)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id
	62EB35A0005; Sun, 24 Jun 2012 20:06:27 +0100 (BST)
Message-ID: <4FE76535.1090801@abpni.co.uk>
Date: Sun, 24 Jun 2012 20:06:29 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Rolu <rolu@roce.org>
References: <4FE75FAB.9040903@abpni.co.uk>
	<CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
In-Reply-To: <CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Intel Security 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 24/06/2012 20:01, Rolu wrote:
> On Sun, Jun 24, 2012 at 8:42 PM, Jonathan Tripathy<jonnyt@abpni.co.uk>  wrote:
>> Hi Everyone,
>>
>> Given that a lot of us run "untrusted" DomUs where the Domu administrator
>> has full control over their PV kernel, could this Intel security issue
>> impact the hypervisor and put other DomUs at risk?
>>
>> http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64-intel-processor
>>
> That page links to http://www.kb.cert.org/vuls/id/649219 which links
> to http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
> which answers your question ;-)
>
> Yes, it's an issue. There are patches.
Silly me! I've been following the inclusion of that Xen patch as well! I just didn't put 2+2 together.

Thanks for your time!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 22:24:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 22:24:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SivDq-0005E8-AC; Sun, 24 Jun 2012 22:23:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SivDo-0005E3-TF
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 22:23:57 +0000
Received: from [85.158.143.99:23571] by server-3.bemta-4.messagelabs.com id
	11/68-05808-C7397EF4; Sun, 24 Jun 2012 22:23:56 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340576634!19235968!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4516 invoked from network); 24 Jun 2012 22:23:55 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 22:23:55 -0000
Received: by obbta14 with SMTP id ta14so7450968obb.32
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 15:23:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=hx+8ZUEH3JwjLBxXK7PgTB+q+kbaLXqV37Hz14KPjEo=;
	b=Df4lJL8MtV5F9KPsoCgX7B1Srz9Lqj6dEpLtU/ZIeqLkuGXc0S/Yg+Vtv3UfV79FCU
	vhpEtag9MFBYDLOKsbovq476gLrtEpFOx6Q8+ycyoXQphgrEYMLpQcPoOLOUwoulO2/e
	yJ7n8zmGc+P6V2zeJxGULzoR4QMhzXWKFVzsI7CbX6mVs60m1e2JcI8E0vWoE5C29X90
	YKG5NUguJgkUL2FsxF03UwlLbcQHY3OdJs5IUlGpX7Hv4guRBiZjtTnYii/lOg1BBXP0
	02Uw0l1o3sSMQaSn4CqoNpyUvnSPkXcZBnL4tQy5q7h9A/q4HuUcUr3fCEF0SJEjGmGY
	pSwg==
Received: by 10.182.92.16 with SMTP id ci16mr10105890obb.79.1340576633516;
	Sun, 24 Jun 2012 15:23:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sun, 24 Jun 2012 15:23:32 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Mon, 25 Jun 2012 00:23:32 +0200
Message-ID: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnThkUVzeYbC0FybssUCdMtQ1E5P47gIdMrpzhNDiJ71j0tfzBPc/u0t13QcqHu3qFg1V8q
Subject: [Xen-devel] pt_pci_read_config offset 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

Using Xen 4.2 unstable rev. 25483.

I get errors like this:

pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]

in my qemu log for a domU with some devices passed through to it.

I investigated and found that at hw/pass-through.c line 1717
(http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/pass-through.c;h=8581253bc86391d6e348e02464f9ed5d2e579a0d;hb=HEAD#l1717)
the code checks for an address >= 0xFF and then throws the above
error. This seems wrong. The PCI configuration space is 256 bytes long
(as far as I've seen anyway) so reading one byte at offset 0xFF should
work and return the very last byte.

pt_pci_write_config has the same code.

Is the check wrong and should it be address > 0xFF?
Or am I missing something?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 22:24:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 22:24:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SivDq-0005E8-AC; Sun, 24 Jun 2012 22:23:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SivDo-0005E3-TF
	for xen-devel@lists.xen.org; Sun, 24 Jun 2012 22:23:57 +0000
Received: from [85.158.143.99:23571] by server-3.bemta-4.messagelabs.com id
	11/68-05808-C7397EF4; Sun, 24 Jun 2012 22:23:56 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340576634!19235968!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4516 invoked from network); 24 Jun 2012 22:23:55 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jun 2012 22:23:55 -0000
Received: by obbta14 with SMTP id ta14so7450968obb.32
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 15:23:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=hx+8ZUEH3JwjLBxXK7PgTB+q+kbaLXqV37Hz14KPjEo=;
	b=Df4lJL8MtV5F9KPsoCgX7B1Srz9Lqj6dEpLtU/ZIeqLkuGXc0S/Yg+Vtv3UfV79FCU
	vhpEtag9MFBYDLOKsbovq476gLrtEpFOx6Q8+ycyoXQphgrEYMLpQcPoOLOUwoulO2/e
	yJ7n8zmGc+P6V2zeJxGULzoR4QMhzXWKFVzsI7CbX6mVs60m1e2JcI8E0vWoE5C29X90
	YKG5NUguJgkUL2FsxF03UwlLbcQHY3OdJs5IUlGpX7Hv4guRBiZjtTnYii/lOg1BBXP0
	02Uw0l1o3sSMQaSn4CqoNpyUvnSPkXcZBnL4tQy5q7h9A/q4HuUcUr3fCEF0SJEjGmGY
	pSwg==
Received: by 10.182.92.16 with SMTP id ci16mr10105890obb.79.1340576633516;
	Sun, 24 Jun 2012 15:23:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sun, 24 Jun 2012 15:23:32 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Mon, 25 Jun 2012 00:23:32 +0200
Message-ID: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnThkUVzeYbC0FybssUCdMtQ1E5P47gIdMrpzhNDiJ71j0tfzBPc/u0t13QcqHu3qFg1V8q
Subject: [Xen-devel] pt_pci_read_config offset 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

Using Xen 4.2 unstable rev. 25483.

I get errors like this:

pt_pci_read_config: [00:10:0] Error: Failed to read register with
offset exceeding FFh. [Offset:ffh][Length:1]

in my qemu log for a domU with some devices passed through to it.

I investigated and found that at hw/pass-through.c line 1717
(http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/pass-through.c;h=8581253bc86391d6e348e02464f9ed5d2e579a0d;hb=HEAD#l1717)
the code checks for an address >= 0xFF and then throws the above
error. This seems wrong. The PCI configuration space is 256 bytes long
(as far as I've seen anyway) so reading one byte at offset 0xFF should
work and return the very last byte.

pt_pci_write_config has the same code.

Is the check wrong and should it be address > 0xFF?
Or am I missing something?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Jun 24 23:36:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 23: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 1SiwLe-0005ZC-Vx; Sun, 24 Jun 2012 23:36:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SiwLd-0005Z7-Fk
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 23:36:05 +0000
Received: from [85.158.143.35:36809] by server-3.bemta-4.messagelabs.com id
	5E/49-05808-464A7EF4; Sun, 24 Jun 2012 23:36:04 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340580962!5963428!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NDYxMA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31781 invoked from network); 24 Jun 2012 23:36:03 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-21.messagelabs.com with SMTP;
	24 Jun 2012 23:36:03 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 24 Jun 2012 16:36:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="184371526"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 24 Jun 2012 16:35:53 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Jun 2012 16:35:53 -0700
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; Sun, 24 Jun 2012 16:35:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Mon, 25 Jun 2012 07:35:51 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
Thread-Index: AQHNUHAzfjuvjg0bUEG3IjgIEiIHGJcKIwiw
Date: Sun, 24 Jun 2012 23:35:50 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1B18EB@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338551094.17466.103.camel@zakaz.uk.xensource.com>
	<1340367076.26083.110.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340367076.26083.110.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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, I was on vacation on past two weeks and just backing to work now. :)
I will give you a modified patch ASAP.

best regards
yang


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, June 22, 2012 8:11 PM
> To: Zhang, Yang Z
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
> 
> On Fri, 2012-06-01 at 12:44 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-01 at 03:48 +0100, Zhang, Yang Z wrote:
> > > Change from v2:
> > > Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> > > According to Ian's comments, modified some codes to make the logic more
> reasonable.
> > >
> > > In current implementation, it uses integer to record current avail cpus and
> this only allows user to specify 31 vcpus.
> > > In following patch, it uses cpumap instead integer which make more sense
> than before. Also there is no limit to the max vcpus.
> > >
> > > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> 
> Hi Yang,
> 
> Have I missed a follow up posting of this patch somewhere? Or is it
> still pending?
> 
> Thanks,
> Ian.
> 
> > >
> > > diff -r 3b0eed731020 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
> > > @@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(
> > >
> > >      if (!b_info->max_vcpus)
> > >          b_info->max_vcpus = 1;
> > > -    if (!b_info->cur_vcpus)
> > > -        b_info->cur_vcpus = 1;
> > > +    if (!b_info->avail_vcpus.size) {
> > > +        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
> > > +            return ERROR_FAIL;
> > > +        libxl_cpumap_set(&b_info->avail_vcpus, 0);
> > > +    }
> > >
> > >      if (!b_info->cpumap.size) {
> > >          if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
> > > diff -r 3b0eed731020 tools/libxl/libxl_dm.c
> > > --- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
> > > @@ -160,6 +160,8 @@ static char ** libxl__build_device_model
> > >      }
> > >      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> > >          int ioemu_vifs = 0;
> > > +        int nr_set_cpus = 0;
> > > +        char *s;
> > >
> > >          if (b_info->u.hvm.serial) {
> > >              flexarray_vappend(dm_args, "-serial",
> b_info->u.hvm.serial, NULL);
> > > @@ -200,11 +202,14 @@ static char ** libxl__build_device_model
> > >                                libxl__sprintf(gc, "%d",
> b_info->max_vcpus),
> > >                                NULL);
> > >          }
> > > -        if (b_info->cur_vcpus) {
> > > -            flexarray_vappend(dm_args, "-vcpu_avail",
> > > -                              libxl__sprintf(gc, "0x%x",
> b_info->cur_vcpus),
> > > -                              NULL);
> > > -        }
> > > +
> > > +        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
> > > +        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
> > > +        flexarray_vappend(dm_args, "-vcpu_avail",
> > > +                libxl__sprintf(gc, "0x%s", s),
> >
> > You might as well make to_hex_string include the 0x?
> >
> > > +                NULL);
> > > +        free(s);
> > > +
> > >          for (i = 0; i < num_vifs; i++) {
> > >              if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
> > >                  char *smac = libxl__sprintf(gc,
> > > diff -r 3b0eed731020 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
> > > @@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
> > >      ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus &
> (1 << i)))
> > > +        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus,
> i))
> > >                              ? "offline" : "online";
> >
> > Weren't you going to drop the "i &&" and invert the ternary?
> >
> > >      }
> > >
> > > @@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
> > >      va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
> > >      va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
> > >      va_hvm->nr_vcpus = info->max_vcpus;
> > > -    memcpy(va_hvm->vcpu_online, &info->cur_vcpus,
> sizeof(info->cur_vcpus));
> > > +    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map,
> info->avail_vcpus.size);
> >
> > This needs some sort of limit check, probably in terms of HVM_MAX_VCPUS.
> > otherwise a particularly large vcpus= in the config will cause mayhem...
> >
> > I guess this should probably be done in
> > libxl__domain_build_info_setdefaults.
> >
> > > diff -r 3b0eed731020 tools/libxl/libxl_utils.c
> > > --- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
> > > @@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
> > >      cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
> > >  }
> > >
> > > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
> > > +{
> > > +    int i, nr_set_cpus = 0;
> > > +    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))
> >
> > Please stop this habit of yours of casting away the const to make the
> > warning go away, it is almost always wrong and on the odd occasion that
> > it is right it should have a comment explaining why...
> >
> > In this case please make libxl_cpumap_test const correct instead.
> >
> > > +        nr_set_cpus++;
> > > +
> > > +    return nr_set_cpus;
> > > +}
> > > +
> > > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
> > > +{
> > > +    int i = cpumap->size;
> > > +    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
> > > +    char *q = p;
> > > +    while(--i >= 0) {
> > > +        sprintf((char *)p, "%02x", cpumap->map[i]);
> >
> > Why this cast?
> >
> > > +        p += 2;
> > > +    }
> > > +    *p = '\0';
> > > +    return q;
> > > +}
> > > +
> > >  int libxl_get_max_cpus(libxl_ctx *ctx)
> > >  {
> > >      return xc_get_max_cpus(ctx->xch);
> > > diff -r 3b0eed731020 tools/libxl/libxl_utils.h
> > > --- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
> > > @@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
> > >  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
> > >  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
> > >  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> > > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
> >
> > Please add a comment describing this function, it should remind the
> > caller that they are responsible for freeing the result.
> >
> > > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
> > >  static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
> > >  {
> > >      memset(cpumap->map, -1, cpumap->size);
> > > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > >
> > >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> > >          b_info->max_vcpus = l;
> > > -        b_info->cur_vcpus = (1 << l) - 1;
> > > +
> > > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > > +            exit(1);
> > > +        }
> > > +        libxl_cpumap_set_none(&b_info->avail_vcpus);
> > > +        while (l-- > 0)
> > > +            libxl_cpumap_set((&b_info->avail_vcpus), l);
> >
> > This while loop is == libxl_cpumap_set_any.
> >
> > >      }
> > >
> > >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 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 Sun Jun 24 23:36:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Jun 2012 23: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 1SiwLe-0005ZC-Vx; Sun, 24 Jun 2012 23:36:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SiwLd-0005Z7-Fk
	for xen-devel@lists.xensource.com; Sun, 24 Jun 2012 23:36:05 +0000
Received: from [85.158.143.35:36809] by server-3.bemta-4.messagelabs.com id
	5E/49-05808-464A7EF4; Sun, 24 Jun 2012 23:36:04 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340580962!5963428!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NDYxMA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31781 invoked from network); 24 Jun 2012 23:36:03 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-21.messagelabs.com with SMTP;
	24 Jun 2012 23:36:03 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 24 Jun 2012 16:36:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="184371526"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 24 Jun 2012 16:35:53 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Jun 2012 16:35:53 -0700
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; Sun, 24 Jun 2012 16:35:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Mon, 25 Jun 2012 07:35:51 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
Thread-Index: AQHNUHAzfjuvjg0bUEG3IjgIEiIHGJcKIwiw
Date: Sun, 24 Jun 2012 23:35:50 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1B18EB@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E162576@SHSMSX101.ccr.corp.intel.com>
	<1338551094.17466.103.camel@zakaz.uk.xensource.com>
	<1340367076.26083.110.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340367076.26083.110.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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, I was on vacation on past two weeks and just backing to work now. :)
I will give you a modified patch ASAP.

best regards
yang


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, June 22, 2012 8:11 PM
> To: Zhang, Yang Z
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus
> 
> On Fri, 2012-06-01 at 12:44 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-01 at 03:48 +0100, Zhang, Yang Z wrote:
> > > Change from v2:
> > > Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
> > > According to Ian's comments, modified some codes to make the logic more
> reasonable.
> > >
> > > In current implementation, it uses integer to record current avail cpus and
> this only allows user to specify 31 vcpus.
> > > In following patch, it uses cpumap instead integer which make more sense
> than before. Also there is no limit to the max vcpus.
> > >
> > > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> 
> Hi Yang,
> 
> Have I missed a follow up posting of this patch somewhere? Or is it
> still pending?
> 
> Thanks,
> Ian.
> 
> > >
> > > diff -r 3b0eed731020 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c        Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_create.c        Fri Jun 01 10:34:13 2012 +0800
> > > @@ -146,8 +146,11 @@ int libxl__domain_build_info_setdefault(
> > >
> > >      if (!b_info->max_vcpus)
> > >          b_info->max_vcpus = 1;
> > > -    if (!b_info->cur_vcpus)
> > > -        b_info->cur_vcpus = 1;
> > > +    if (!b_info->avail_vcpus.size) {
> > > +        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
> > > +            return ERROR_FAIL;
> > > +        libxl_cpumap_set(&b_info->avail_vcpus, 0);
> > > +    }
> > >
> > >      if (!b_info->cpumap.size) {
> > >          if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
> > > diff -r 3b0eed731020 tools/libxl/libxl_dm.c
> > > --- a/tools/libxl/libxl_dm.c    Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_dm.c    Fri Jun 01 10:34:13 2012 +0800
> > > @@ -160,6 +160,8 @@ static char ** libxl__build_device_model
> > >      }
> > >      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> > >          int ioemu_vifs = 0;
> > > +        int nr_set_cpus = 0;
> > > +        char *s;
> > >
> > >          if (b_info->u.hvm.serial) {
> > >              flexarray_vappend(dm_args, "-serial",
> b_info->u.hvm.serial, NULL);
> > > @@ -200,11 +202,14 @@ static char ** libxl__build_device_model
> > >                                libxl__sprintf(gc, "%d",
> b_info->max_vcpus),
> > >                                NULL);
> > >          }
> > > -        if (b_info->cur_vcpus) {
> > > -            flexarray_vappend(dm_args, "-vcpu_avail",
> > > -                              libxl__sprintf(gc, "0x%x",
> b_info->cur_vcpus),
> > > -                              NULL);
> > > -        }
> > > +
> > > +        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
> > > +        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
> > > +        flexarray_vappend(dm_args, "-vcpu_avail",
> > > +                libxl__sprintf(gc, "0x%s", s),
> >
> > You might as well make to_hex_string include the 0x?
> >
> > > +                NULL);
> > > +        free(s);
> > > +
> > >          for (i = 0; i < num_vifs; i++) {
> > >              if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
> > >                  char *smac = libxl__sprintf(gc,
> > > diff -r 3b0eed731020 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c   Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_dom.c   Fri Jun 01 10:34:13 2012 +0800
> > > @@ -195,7 +195,7 @@ int libxl__build_post(libxl__gc *gc, uin
> > >      ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus &
> (1 << i)))
> > > +        ents[12+(i*2)+1] = (i && !libxl_cpumap_test(&info->avail_vcpus,
> i))
> > >                              ? "offline" : "online";
> >
> > Weren't you going to drop the "i &&" and invert the ternary?
> >
> > >      }
> > >
> > > @@ -350,7 +350,7 @@ static int hvm_build_set_params(xc_inter
> > >      va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
> > >      va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
> > >      va_hvm->nr_vcpus = info->max_vcpus;
> > > -    memcpy(va_hvm->vcpu_online, &info->cur_vcpus,
> sizeof(info->cur_vcpus));
> > > +    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map,
> info->avail_vcpus.size);
> >
> > This needs some sort of limit check, probably in terms of HVM_MAX_VCPUS.
> > otherwise a particularly large vcpus= in the config will cause mayhem...
> >
> > I guess this should probably be done in
> > libxl__domain_build_info_setdefaults.
> >
> > > diff -r 3b0eed731020 tools/libxl/libxl_utils.c
> > > --- a/tools/libxl/libxl_utils.c Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_utils.c Fri Jun 01 10:34:13 2012 +0800
> > > @@ -533,6 +533,28 @@ void libxl_cpumap_reset(libxl_cpumap *cp
> > >      cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
> > >  }
> > >
> > > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
> > > +{
> > > +    int i, nr_set_cpus = 0;
> > > +    libxl_for_each_set_cpu(i, *((libxl_cpumap *)cpumap))
> >
> > Please stop this habit of yours of casting away the const to make the
> > warning go away, it is almost always wrong and on the odd occasion that
> > it is right it should have a comment explaining why...
> >
> > In this case please make libxl_cpumap_test const correct instead.
> >
> > > +        nr_set_cpus++;
> > > +
> > > +    return nr_set_cpus;
> > > +}
> > > +
> > > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
> > > +{
> > > +    int i = cpumap->size;
> > > +    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 1);
> > > +    char *q = p;
> > > +    while(--i >= 0) {
> > > +        sprintf((char *)p, "%02x", cpumap->map[i]);
> >
> > Why this cast?
> >
> > > +        p += 2;
> > > +    }
> > > +    *p = '\0';
> > > +    return q;
> > > +}
> > > +
> > >  int libxl_get_max_cpus(libxl_ctx *ctx)
> > >  {
> > >      return xc_get_max_cpus(ctx->xch);
> > > diff -r 3b0eed731020 tools/libxl/libxl_utils.h
> > > --- a/tools/libxl/libxl_utils.h Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/libxl_utils.h Fri Jun 01 10:34:13 2012 +0800
> > > @@ -67,6 +67,8 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
> > >  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
> > >  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
> > >  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> > > +int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
> >
> > Please add a comment describing this function, it should remind the
> > caller that they are responsible for freeing the result.
> >
> > > +char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
> > >  static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
> > >  {
> > >      memset(cpumap->map, -1, cpumap->size);
> > > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c  Fri Jun 01 09:27:17 2012 +0800
> > > +++ b/tools/libxl/xl_cmdimpl.c  Fri Jun 01 10:34:13 2012 +0800
> > > @@ -650,7 +650,14 @@ static void parse_config_data(const char
> > >
> > >      if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> > >          b_info->max_vcpus = l;
> > > -        b_info->cur_vcpus = (1 << l) - 1;
> > > +
> > > +        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
> > > +            fprintf(stderr, "Unable to allocate cpumap\n");
> > > +            exit(1);
> > > +        }
> > > +        libxl_cpumap_set_none(&b_info->avail_vcpus);
> > > +        while (l-- > 0)
> > > +            libxl_cpumap_set((&b_info->avail_vcpus), l);
> >
> > This while loop is == libxl_cpumap_set_any.
> >
> > >      }
> > >
> > >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 04:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 04:06: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 1Sj0Ye-0003fq-HN; Mon, 25 Jun 2012 04:05:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sj0Yd-0003fk-2j
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 04:05:47 +0000
Received: from [85.158.138.51:55183] by server-2.bemta-3.messagelabs.com id
	33/DA-10266-A93E7EF4; Mon, 25 Jun 2012 04:05:46 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340597144!22939433!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15520 invoked from network); 25 Jun 2012 04:05:45 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 04:05:45 -0000
Received: by obbta14 with SMTP id ta14so7926136obb.32
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 21:05:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:content-type:x-gm-message-state;
	bh=PgG2kGtz7U25Bx+L1g+Cv7/RhU3oimkapCWXrl567xQ=;
	b=WnHTwTp+E9MCN/pLoYtQM2jI7UzTZrkP1eC5n4+AiDErYTnXjzACdGthtOP5W/8MKZ
	JVDs5HIQuhGGdyodQeZPTL029V82gu63ITqzny2qhkRvA3i1Jn/YI7kOMK5qW1cJFI55
	271WIbGZWgAVOKjwe5S2S7aSzXOFapdFq5gFpaeEN9TwzYH+aZEIBBDCMPwgeDzcx22F
	tWNUk3fd686mNacZ0aOTBLt+M+A1RNvNxfb2RbhyjiB5nx+mV4W4aHetSup5/8aL36Rz
	Nwhiuir0UnZAmJDjJN5XvYAlOx42TauHqxWA8LjDNbm4i+tBwMyo2V5G1P6fc5Sfwn/i
	XKhA==
Received: by 10.182.46.104 with SMTP id u8mr10746337obm.74.1340597143669; Sun,
	24 Jun 2012 21:05:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sun, 24 Jun 2012 21:05:23 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
References: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Mon, 25 Jun 2012 06:05:23 +0200
Message-ID: <CABs9EjkPAJoYzQdZLYeuwrytHD1whFeHtby5_sq8_fm-fAa8_g@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQltnUxnWqzG8zuMPnpNhura/pFj5J6OPX6mrci2WDvXmtJkJjywqWDkDXhcyJH4zMAveZDh
Subject: Re: [Xen-devel] pt_pci_read_config offset 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

On Mon, Jun 25, 2012 at 12:23 AM, Rolu <rolu@roce.org> wrote:
> Using Xen 4.2 unstable rev. 25483.
>
> I get errors like this:
>
> pt_pci_read_config: [00:10:0] Error: Failed to read register with
> offset exceeding FFh. [Offset:ffh][Length:1]
>
> in my qemu log for a domU with some devices passed through to it.
>
> I investigated and found that at hw/pass-through.c line 1717
> (http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/pass-through.c;h=8581253bc86391d6e348e02464f9ed5d2e579a0d;hb=HEAD#l1717)
> the code checks for an address >= 0xFF and then throws the above
> error. This seems wrong. The PCI configuration space is 256 bytes long
> (as far as I've seen anyway) so reading one byte at offset 0xFF should
> work and return the very last byte.
>
> pt_pci_write_config has the same code.
>
> Is the check wrong and should it be address > 0xFF?

I tried this out and the error is gone, and nothing seems to have broken.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 04:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 04:06: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 1Sj0Ye-0003fq-HN; Mon, 25 Jun 2012 04:05:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sj0Yd-0003fk-2j
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 04:05:47 +0000
Received: from [85.158.138.51:55183] by server-2.bemta-3.messagelabs.com id
	33/DA-10266-A93E7EF4; Mon, 25 Jun 2012 04:05:46 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340597144!22939433!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15520 invoked from network); 25 Jun 2012 04:05:45 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 04:05:45 -0000
Received: by obbta14 with SMTP id ta14so7926136obb.32
	for <xen-devel@lists.xen.org>; Sun, 24 Jun 2012 21:05:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:content-type:x-gm-message-state;
	bh=PgG2kGtz7U25Bx+L1g+Cv7/RhU3oimkapCWXrl567xQ=;
	b=WnHTwTp+E9MCN/pLoYtQM2jI7UzTZrkP1eC5n4+AiDErYTnXjzACdGthtOP5W/8MKZ
	JVDs5HIQuhGGdyodQeZPTL029V82gu63ITqzny2qhkRvA3i1Jn/YI7kOMK5qW1cJFI55
	271WIbGZWgAVOKjwe5S2S7aSzXOFapdFq5gFpaeEN9TwzYH+aZEIBBDCMPwgeDzcx22F
	tWNUk3fd686mNacZ0aOTBLt+M+A1RNvNxfb2RbhyjiB5nx+mV4W4aHetSup5/8aL36Rz
	Nwhiuir0UnZAmJDjJN5XvYAlOx42TauHqxWA8LjDNbm4i+tBwMyo2V5G1P6fc5Sfwn/i
	XKhA==
Received: by 10.182.46.104 with SMTP id u8mr10746337obm.74.1340597143669; Sun,
	24 Jun 2012 21:05:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Sun, 24 Jun 2012 21:05:23 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
References: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Mon, 25 Jun 2012 06:05:23 +0200
Message-ID: <CABs9EjkPAJoYzQdZLYeuwrytHD1whFeHtby5_sq8_fm-fAa8_g@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQltnUxnWqzG8zuMPnpNhura/pFj5J6OPX6mrci2WDvXmtJkJjywqWDkDXhcyJH4zMAveZDh
Subject: Re: [Xen-devel] pt_pci_read_config offset 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

On Mon, Jun 25, 2012 at 12:23 AM, Rolu <rolu@roce.org> wrote:
> Using Xen 4.2 unstable rev. 25483.
>
> I get errors like this:
>
> pt_pci_read_config: [00:10:0] Error: Failed to read register with
> offset exceeding FFh. [Offset:ffh][Length:1]
>
> in my qemu log for a domU with some devices passed through to it.
>
> I investigated and found that at hw/pass-through.c line 1717
> (http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/pass-through.c;h=8581253bc86391d6e348e02464f9ed5d2e579a0d;hb=HEAD#l1717)
> the code checks for an address >= 0xFF and then throws the above
> error. This seems wrong. The PCI configuration space is 256 bytes long
> (as far as I've seen anyway) so reading one byte at offset 0xFF should
> work and return the very last byte.
>
> pt_pci_write_config has the same code.
>
> Is the check wrong and should it be address > 0xFF?

I tried this out and the error is gone, and nothing seems to have broken.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 06:28:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 06:28: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 1Sj2ln-0004X0-T0; Mon, 25 Jun 2012 06:27:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1Sj2lm-0004Wt-4T
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 06:27:30 +0000
Received: from [85.158.143.35:65149] by server-1.bemta-4.messagelabs.com id
	43/3E-24392-1D408EF4; Mon, 25 Jun 2012 06:27:29 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340605648!17855073!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxOTk1OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14770 invoked from network); 25 Jun 2012 06:27:29 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 06:27:29 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 24 Jun 2012 23:27:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="184463106"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 24 Jun 2012 23:27:27 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Jun 2012 23:27:27 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Jun 2012 23:27:27 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Mon, 25 Jun 2012 14:27:24 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "JBeulich@suse.com"
	<JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>
Thread-Topic: [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNTogH/cNoDlcctUOuNFJAvIban5cKmdOw
Date: Mon, 25 Jun 2012 06:27:23 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE01EEE@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@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: "Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 and Jan

Any other comments for this series of patches?

Thanks,
-Xudong


> -----Original Message-----
> From: Hao, Xudong
> Sent: Wednesday, June 20, 2012 9:58 AM
> To: xen-devel@lists.xen.org
> Cc: JBeulich@suse.com; keir@xen.org; Zhang, Xiantao; Shan, Haitao; Hao,
> Xudong
> Subject: [PATCH v2 0/4] xen: enable EPT A/D bit feature
> 
> Changes from v1:
> - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to
> patch2.
> - define them as bool_t instead of int.
> 
> Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
> enable VMMs to efficiently implement memory management and page
> classification
> algorithms to optimize VM memory operations.
> 
> This series of patches enable EPT dirty bit feature for guest live migration.
> 
> PATCH 1/4: Add EPT A/D bits definitions.
> 
> PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.
> 
> PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will
> only update the log dirty bitmap, but won't clear the EPT page dirty bit.
> The function is used by live migration peek round with EPT D bit supported.
> 
> PATCH 4/4: enable EPT dirty bit for guest live migration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 06:28:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 06:28: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 1Sj2ln-0004X0-T0; Mon, 25 Jun 2012 06:27:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1Sj2lm-0004Wt-4T
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 06:27:30 +0000
Received: from [85.158.143.35:65149] by server-1.bemta-4.messagelabs.com id
	43/3E-24392-1D408EF4; Mon, 25 Jun 2012 06:27:29 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340605648!17855073!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxOTk1OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14770 invoked from network); 25 Jun 2012 06:27:29 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 06:27:29 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 24 Jun 2012 23:27:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="184463106"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 24 Jun 2012 23:27:27 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Jun 2012 23:27:27 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Jun 2012 23:27:27 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Mon, 25 Jun 2012 14:27:24 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "JBeulich@suse.com"
	<JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>
Thread-Topic: [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNTogH/cNoDlcctUOuNFJAvIban5cKmdOw
Date: Mon, 25 Jun 2012 06:27:23 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE01EEE@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@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: "Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 and Jan

Any other comments for this series of patches?

Thanks,
-Xudong


> -----Original Message-----
> From: Hao, Xudong
> Sent: Wednesday, June 20, 2012 9:58 AM
> To: xen-devel@lists.xen.org
> Cc: JBeulich@suse.com; keir@xen.org; Zhang, Xiantao; Shan, Haitao; Hao,
> Xudong
> Subject: [PATCH v2 0/4] xen: enable EPT A/D bit feature
> 
> Changes from v1:
> - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to
> patch2.
> - define them as bool_t instead of int.
> 
> Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
> enable VMMs to efficiently implement memory management and page
> classification
> algorithms to optimize VM memory operations.
> 
> This series of patches enable EPT dirty bit feature for guest live migration.
> 
> PATCH 1/4: Add EPT A/D bits definitions.
> 
> PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.
> 
> PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will
> only update the log dirty bitmap, but won't clear the EPT page dirty bit.
> The function is used by live migration peek round with EPT D bit supported.
> 
> PATCH 4/4: enable EPT dirty bit for guest live migration.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 07:14:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07:14: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 1Sj3V6-0005FT-Up; Mon, 25 Jun 2012 07:14: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 1Sj3V4-0005FO-RQ
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 07:14:19 +0000
Received: from [85.158.143.99:7881] by server-2.bemta-4.messagelabs.com id
	03/67-17938-ACF08EF4; Mon, 25 Jun 2012 07:14:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340608457!23658588!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9277 invoked from network); 25 Jun 2012 07:14:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	25 Jun 2012 07:14:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 08:14:16 +0100
Message-Id: <4FE82BE4020000780008B9E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 08:14:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Tony Luck" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
	<4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F193234FE@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F193234FE@ORSMSX104.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yunhong Jiang <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Susie Li <susie.li@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:21, "Luck, Tony" <tony.luck@intel.com> wrote:
> There may be some secondary side benefit that independent errors might be
> reported to different banks, and so avoid some overwrite problems.  But I 
> don't
> think that Xen has a big worry with overwrite, does it? In general the 
> errors that
> you will show to the guest are ones that you expect the guest to handle 
> immediately
> (e.g. SRAO and SRAR signaled with a machine check). You do not log any 
> corrected
> errors to the guest (they can't do anything useful with them). You certainly 
> don't
> log any errors that are not signaled. So you should never have any errors 
> hanging
> around in banks for long periods that would get overwritten.

The problem is the determination of what "long" means here. The
target vCPU may not get scheduled for extended periods of time
(raising its priority would have other undesirable implications), so
the risk over overwrite exists from that perspective. However,
assuming that reportable errors get associated with a particular
vCPU, and that such a vCPU won't be able to execute any further
guest code prior to the delivery of the exception, the only real
risk here would be if the vMCE handler itself raised another event.
That I agree with Jinsong can be well treated as fatal (killing the
guest, provided the event gets properly logged so the admin
isn't left in the dark regarding the unexpected death of the VM),
mostly matching would a single bank hardware implementation
would result in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 07:14:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07:14: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 1Sj3V6-0005FT-Up; Mon, 25 Jun 2012 07:14: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 1Sj3V4-0005FO-RQ
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 07:14:19 +0000
Received: from [85.158.143.99:7881] by server-2.bemta-4.messagelabs.com id
	03/67-17938-ACF08EF4; Mon, 25 Jun 2012 07:14:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340608457!23658588!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9277 invoked from network); 25 Jun 2012 07:14:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	25 Jun 2012 07:14:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 08:14:16 +0100
Message-Id: <4FE82BE4020000780008B9E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 08:14:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Tony Luck" <tony.luck@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F1932337D@ORSMSX104.amr.corp.intel.com>
	<4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F193234FE@ORSMSX104.amr.corp.intel.com>
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F193234FE@ORSMSX104.amr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yunhong Jiang <yunhong.jiang@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Susie Li <susie.li@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:21, "Luck, Tony" <tony.luck@intel.com> wrote:
> There may be some secondary side benefit that independent errors might be
> reported to different banks, and so avoid some overwrite problems.  But I 
> don't
> think that Xen has a big worry with overwrite, does it? In general the 
> errors that
> you will show to the guest are ones that you expect the guest to handle 
> immediately
> (e.g. SRAO and SRAR signaled with a machine check). You do not log any 
> corrected
> errors to the guest (they can't do anything useful with them). You certainly 
> don't
> log any errors that are not signaled. So you should never have any errors 
> hanging
> around in banks for long periods that would get overwritten.

The problem is the determination of what "long" means here. The
target vCPU may not get scheduled for extended periods of time
(raising its priority would have other undesirable implications), so
the risk over overwrite exists from that perspective. However,
assuming that reportable errors get associated with a particular
vCPU, and that such a vCPU won't be able to execute any further
guest code prior to the delivery of the exception, the only real
risk here would be if the vMCE handler itself raised another event.
That I agree with Jinsong can be well treated as fatal (killing the
guest, provided the event gets properly logged so the admin
isn't left in the dark regarding the unexpected death of the VM),
mostly matching would a single bank hardware implementation
would result in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 07:23:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07: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 1Sj3dE-0005O8-VB; Mon, 25 Jun 2012 07:22:44 +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 1Sj3dD-0005O3-Tq
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 07:22:44 +0000
Received: from [85.158.139.83:42833] by server-7.bemta-5.messagelabs.com id
	91/D8-28276-3C118EF4; Mon, 25 Jun 2012 07:22:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340608962!29292551!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24472 invoked from network); 25 Jun 2012 07:22:42 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 07:22:42 -0000
Received: by eaak12 with SMTP id k12so1213680eaa.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 00:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3vhASA5yAO/oA/UByNsefAbqwVA14SGJ8tAgF6n940A=;
	b=udrH89XEfN/YQwtw6y9jCRQLaoXy6s/DHf/E6Hoyy63EqUOiKIAIVWN0rX6bmu4bDJ
	EnjpZF7IFnp2MZVbX+80gEvJM7aDIFQQUmqQDqryhSN4jDzKPWp2UOaReXsTldmkj6T2
	CpvhqNPU2u93xEj0o8PldrnBfQu9VUgzYT0Kyxyu5fG0+RMBNtH6KH048MDubLMBwRDF
	ttDF7Wdqhgt8uQv4yKoDT1p2/X2Mlb1wvo0ku30IKCdert6BdVWOc9UgMAFhN91W7ZC2
	bGojHLl0qu4Zx1Oei4i9ULmLz3PMUroNKcD/rHQa9acP2DTzMdmfXGqT1fDjf/mzPNV7
	zPOg==
Received: by 10.14.95.136 with SMTP id p8mr2113695eef.131.1340608962199;
	Mon, 25 Jun 2012 00:22:42 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id p41sm135744433eef.5.2012.06.25.00.22.39
	(version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 00:22:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 25 Jun 2012 08:22:35 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Hao, Xudong" <xudong.hao@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Message-ID: <CC0DD04B.36700%keir.xen@gmail.com>
Thread-Topic: [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNTogH/cNoDlcctUOuNFJAvIban5cKmdOwgAAPsgk=
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FE01EEE@SHSMSX102.ccr.corp.intel.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Review will probably come from Tim Deegan. There's no rush as it is too late
for 4.2 now.

 -- Keir

On 25/06/2012 07:27, "Hao, Xudong" <xudong.hao@intel.com> wrote:

> Hi, Keir and Jan
> 
> Any other comments for this series of patches?
> 
> Thanks,
> -Xudong
> 
> 
>> -----Original Message-----
>> From: Hao, Xudong
>> Sent: Wednesday, June 20, 2012 9:58 AM
>> To: xen-devel@lists.xen.org
>> Cc: JBeulich@suse.com; keir@xen.org; Zhang, Xiantao; Shan, Haitao; Hao,
>> Xudong
>> Subject: [PATCH v2 0/4] xen: enable EPT A/D bit feature
>> 
>> Changes from v1:
>> - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to
>> patch2.
>> - define them as bool_t instead of int.
>> 
>> Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
>> enable VMMs to efficiently implement memory management and page
>> classification
>> algorithms to optimize VM memory operations.
>> 
>> This series of patches enable EPT dirty bit feature for guest live migration.
>> 
>> PATCH 1/4: Add EPT A/D bits definitions.
>> 
>> PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.
>> 
>> PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will
>> only update the log dirty bitmap, but won't clear the EPT page dirty bit.
>> The function is used by live migration peek round with EPT D bit supported.
>> 
>> PATCH 4/4: enable EPT dirty bit for guest live migration.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 07:23:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07: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 1Sj3dE-0005O8-VB; Mon, 25 Jun 2012 07:22:44 +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 1Sj3dD-0005O3-Tq
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 07:22:44 +0000
Received: from [85.158.139.83:42833] by server-7.bemta-5.messagelabs.com id
	91/D8-28276-3C118EF4; Mon, 25 Jun 2012 07:22:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340608962!29292551!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24472 invoked from network); 25 Jun 2012 07:22:42 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 07:22:42 -0000
Received: by eaak12 with SMTP id k12so1213680eaa.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 00:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3vhASA5yAO/oA/UByNsefAbqwVA14SGJ8tAgF6n940A=;
	b=udrH89XEfN/YQwtw6y9jCRQLaoXy6s/DHf/E6Hoyy63EqUOiKIAIVWN0rX6bmu4bDJ
	EnjpZF7IFnp2MZVbX+80gEvJM7aDIFQQUmqQDqryhSN4jDzKPWp2UOaReXsTldmkj6T2
	CpvhqNPU2u93xEj0o8PldrnBfQu9VUgzYT0Kyxyu5fG0+RMBNtH6KH048MDubLMBwRDF
	ttDF7Wdqhgt8uQv4yKoDT1p2/X2Mlb1wvo0ku30IKCdert6BdVWOc9UgMAFhN91W7ZC2
	bGojHLl0qu4Zx1Oei4i9ULmLz3PMUroNKcD/rHQa9acP2DTzMdmfXGqT1fDjf/mzPNV7
	zPOg==
Received: by 10.14.95.136 with SMTP id p8mr2113695eef.131.1340608962199;
	Mon, 25 Jun 2012 00:22:42 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id p41sm135744433eef.5.2012.06.25.00.22.39
	(version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 00:22:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 25 Jun 2012 08:22:35 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: "Hao, Xudong" <xudong.hao@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Message-ID: <CC0DD04B.36700%keir.xen@gmail.com>
Thread-Topic: [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNTogH/cNoDlcctUOuNFJAvIban5cKmdOwgAAPsgk=
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FE01EEE@SHSMSX102.ccr.corp.intel.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Review will probably come from Tim Deegan. There's no rush as it is too late
for 4.2 now.

 -- Keir

On 25/06/2012 07:27, "Hao, Xudong" <xudong.hao@intel.com> wrote:

> Hi, Keir and Jan
> 
> Any other comments for this series of patches?
> 
> Thanks,
> -Xudong
> 
> 
>> -----Original Message-----
>> From: Hao, Xudong
>> Sent: Wednesday, June 20, 2012 9:58 AM
>> To: xen-devel@lists.xen.org
>> Cc: JBeulich@suse.com; keir@xen.org; Zhang, Xiantao; Shan, Haitao; Hao,
>> Xudong
>> Subject: [PATCH v2 0/4] xen: enable EPT A/D bit feature
>> 
>> Changes from v1:
>> - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to
>> patch2.
>> - define them as bool_t instead of int.
>> 
>> Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
>> enable VMMs to efficiently implement memory management and page
>> classification
>> algorithms to optimize VM memory operations.
>> 
>> This series of patches enable EPT dirty bit feature for guest live migration.
>> 
>> PATCH 1/4: Add EPT A/D bits definitions.
>> 
>> PATCH 2/4: Add xen parameter to control A/D bits support, it on by default.
>> 
>> PATCH 3/4: Introduce a log_dirty new function update_dirty_bitmap, which will
>> only update the log dirty bitmap, but won't clear the EPT page dirty bit.
>> The function is used by live migration peek round with EPT D bit supported.
>> 
>> PATCH 4/4: enable EPT dirty bit for guest live migration.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 07:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07: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 1Sj43g-0005bC-9r; Mon, 25 Jun 2012 07:50:04 +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 1Sj43e-0005b7-IW
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 07:50:02 +0000
Received: from [85.158.143.35:59092] by server-2.bemta-4.messagelabs.com id
	00/0F-17938-82818EF4; Mon, 25 Jun 2012 07:50:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340610600!16788331!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27964 invoked from network); 25 Jun 2012 07:50:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 07:50:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 08:49:59 +0100
Message-Id: <4FE83444020000780008BA00@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 08:49:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
In-Reply-To: <CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> At the same time, adding logging to the guest kernel would
>> be nice, to see what value it actually writes (in a current
>> kernel this would be in __write_msi_msg()).
>>
> 
> Turns out that msg->data here is also 0x4300, so it seems the guest
> kernel is producing these values. I caused it to make a stack trace
> and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> current data field and if it isn't equal to the macro it uses
> xen_msi_compose_msg to make a new message, but that function just sets
> the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> then gets passed to __write_msi_msg and that's that. There are no
> other writes through __write_msi_msg (except for the same thing for
> other devices).
> 
> The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> decoded as the delivery mode, so it seems the kernel is intentionally
> setting it to 3.

So that can never have worked properly afaict. Stefano, the
code as it is currently - using literal (3 << 8) - is clearly bogus.
Your original commit at least had a comment saying that the
reserved delivery mode encoding is intentional here, but that
comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
In any case - the cooperation with qemu apparently doesn't
work, as the reserved encoding should never make it through
to the hypervisor. Could you explain what the intention here
was?

And regardless of anything, can the literal numbers please be
replaced by proper manifest constants - the "8" here already
has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
proper symbolic would permit locating where this is being (or
really, as it doesn't appear to work supposed to be) consumed
in qemu, provided it uses the same definition (i.e. that one
should go into one of the 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 Mon Jun 25 07:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07: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 1Sj43g-0005bC-9r; Mon, 25 Jun 2012 07:50:04 +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 1Sj43e-0005b7-IW
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 07:50:02 +0000
Received: from [85.158.143.35:59092] by server-2.bemta-4.messagelabs.com id
	00/0F-17938-82818EF4; Mon, 25 Jun 2012 07:50:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340610600!16788331!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27964 invoked from network); 25 Jun 2012 07:50:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 07:50:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 08:49:59 +0100
Message-Id: <4FE83444020000780008BA00@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 08:49:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
In-Reply-To: <CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> At the same time, adding logging to the guest kernel would
>> be nice, to see what value it actually writes (in a current
>> kernel this would be in __write_msi_msg()).
>>
> 
> Turns out that msg->data here is also 0x4300, so it seems the guest
> kernel is producing these values. I caused it to make a stack trace
> and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> current data field and if it isn't equal to the macro it uses
> xen_msi_compose_msg to make a new message, but that function just sets
> the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> then gets passed to __write_msi_msg and that's that. There are no
> other writes through __write_msi_msg (except for the same thing for
> other devices).
> 
> The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> decoded as the delivery mode, so it seems the kernel is intentionally
> setting it to 3.

So that can never have worked properly afaict. Stefano, the
code as it is currently - using literal (3 << 8) - is clearly bogus.
Your original commit at least had a comment saying that the
reserved delivery mode encoding is intentional here, but that
comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
In any case - the cooperation with qemu apparently doesn't
work, as the reserved encoding should never make it through
to the hypervisor. Could you explain what the intention here
was?

And regardless of anything, can the literal numbers please be
replaced by proper manifest constants - the "8" here already
has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
proper symbolic would permit locating where this is being (or
really, as it doesn't appear to work supposed to be) consumed
in qemu, provided it uses the same definition (i.e. that one
should go into one of the 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 Mon Jun 25 07:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07:51: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 1Sj44e-0005dV-O0; Mon, 25 Jun 2012 07:51: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 1Sj44c-0005dJ-Hp
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 07:51:02 +0000
Received: from [85.158.138.51:2773] by server-8.bemta-3.messagelabs.com id
	BB/EC-06157-56818EF4; Mon, 25 Jun 2012 07:51:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340610660!21226078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18819 invoked from network); 25 Jun 2012 07:51:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 07:51:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13191946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 07:51:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 08:51:00 +0100
Message-ID: <1340610659.19647.27.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 25 Jun 2012 08:50:59 +0100
In-Reply-To: <1340465972.5558.4.camel@Abyss>
References: <osstest-13339-mainreport@xen.org> <1340465972.5558.4.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
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] 13339: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-06-23 at 16:39 +0100, Dario Faggioli wrote:
> 
> > test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail
> like 13025
> > 
> But what about this? Have we broken migration now?!?! :-O

This is a long standing failure (fail like 13025 means it has been
failing since then) and isn't considered a push blocker.

We got the push we needed in flight 13352.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 07:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 07:51: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 1Sj44e-0005dV-O0; Mon, 25 Jun 2012 07:51: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 1Sj44c-0005dJ-Hp
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 07:51:02 +0000
Received: from [85.158.138.51:2773] by server-8.bemta-3.messagelabs.com id
	BB/EC-06157-56818EF4; Mon, 25 Jun 2012 07:51:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340610660!21226078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18819 invoked from network); 25 Jun 2012 07:51:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 07:51:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13191946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 07:51:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 08:51:00 +0100
Message-ID: <1340610659.19647.27.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 25 Jun 2012 08:50:59 +0100
In-Reply-To: <1340465972.5558.4.camel@Abyss>
References: <osstest-13339-mainreport@xen.org> <1340465972.5558.4.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
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] 13339: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-06-23 at 16:39 +0100, Dario Faggioli wrote:
> 
> > test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail
> like 13025
> > 
> But what about this? Have we broken migration now?!?! :-O

This is a long standing failure (fail like 13025 means it has been
failing since then) and isn't considered a push blocker.

We got the push we needed in flight 13352.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 08:15:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 08:15: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 1Sj4S4-0006OS-S1; Mon, 25 Jun 2012 08:15: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 1Sj4S3-0006ON-Bt
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 08:15:15 +0000
Received: from [85.158.139.83:63391] by server-1.bemta-5.messagelabs.com id
	15/CA-19721-21E18EF4; Mon, 25 Jun 2012 08:15:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340612113!18036645!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15563 invoked from network); 25 Jun 2012 08:15: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 SMTP;
	25 Jun 2012 08:15:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 09:15:13 +0100
Message-Id: <4FE83A2F020000780008BA1F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 09:15:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
In-Reply-To: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pt_pci_read_config offset 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

>>> On 25.06.12 at 00:23, Rolu <rolu@roce.org> wrote:
> Using Xen 4.2 unstable rev. 25483.
> 
> I get errors like this:
> 
> pt_pci_read_config: [00:10:0] Error: Failed to read register with
> offset exceeding FFh. [Offset:ffh][Length:1]
> 
> in my qemu log for a domU with some devices passed through to it.
> 
> I investigated and found that at hw/pass-through.c line 1717
> (http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/pass-throug 
> h.c;h=8581253bc86391d6e348e02464f9ed5d2e579a0d;hb=HEAD#l1717)
> the code checks for an address >= 0xFF and then throws the above
> error. This seems wrong. The PCI configuration space is 256 bytes long
> (as far as I've seen anyway) so reading one byte at offset 0xFF should
> work and return the very last byte.
> 
> pt_pci_write_config has the same code.
> 
> Is the check wrong and should it be address > 0xFF?
> Or am I missing something?

The check looks definitely wrong. Care to send a patch?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 08:15:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 08:15: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 1Sj4S4-0006OS-S1; Mon, 25 Jun 2012 08:15: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 1Sj4S3-0006ON-Bt
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 08:15:15 +0000
Received: from [85.158.139.83:63391] by server-1.bemta-5.messagelabs.com id
	15/CA-19721-21E18EF4; Mon, 25 Jun 2012 08:15:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340612113!18036645!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15563 invoked from network); 25 Jun 2012 08:15: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 SMTP;
	25 Jun 2012 08:15:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 09:15:13 +0100
Message-Id: <4FE83A2F020000780008BA1F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 09:15:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
In-Reply-To: <CABs9Ej=mQi+0rk8haZhw57+ksCQFTMEe53UhB=rJOdDmrdcBLA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pt_pci_read_config offset 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

>>> On 25.06.12 at 00:23, Rolu <rolu@roce.org> wrote:
> Using Xen 4.2 unstable rev. 25483.
> 
> I get errors like this:
> 
> pt_pci_read_config: [00:10:0] Error: Failed to read register with
> offset exceeding FFh. [Offset:ffh][Length:1]
> 
> in my qemu log for a domU with some devices passed through to it.
> 
> I investigated and found that at hw/pass-through.c line 1717
> (http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/pass-throug 
> h.c;h=8581253bc86391d6e348e02464f9ed5d2e579a0d;hb=HEAD#l1717)
> the code checks for an address >= 0xFF and then throws the above
> error. This seems wrong. The PCI configuration space is 256 bytes long
> (as far as I've seen anyway) so reading one byte at offset 0xFF should
> work and return the very last byte.
> 
> pt_pci_write_config has the same code.
> 
> Is the check wrong and should it be address > 0xFF?
> Or am I missing something?

The check looks definitely wrong. Care to send a patch?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 08:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 08:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj4gq-0006YF-GL; Mon, 25 Jun 2012 08:30:32 +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 1Sj4go-0006YA-RU
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 08:30:31 +0000
Received: from [85.158.143.35:46228] by server-1.bemta-4.messagelabs.com id
	18/CB-24392-6A128EF4; Mon, 25 Jun 2012 08:30:30 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340613021!6185561!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjQz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12143 invoked from network); 25 Jun 2012 08:30:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 08:30:22 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 25 Jun 2012 01:30:20 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="162182415"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 25 Jun 2012 01:30:19 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 01:30:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Mon, 25 Jun 2012 16:30:17 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: AQHNUIitexbUH0BVTLGVMLMLWAtaJ5cKtlBA
Date: Mon, 25 Jun 2012 08:30:17 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335258568@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
In-Reply-To: <4FE4A636020000780008B756@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 22.06.12 at 15:46, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>> One other concern that occurred to me after long having sent
>>> the original response: Your proposal aims at a fixed,
>>> unmodifiable vMCE interface. How is that going to be forward
>>> compatible? I.e. consider you had made that proposal before
>>> the SRAO/SRAR changes went in - would the same interface (with
>>> the same set of capability bits set/clear) still be suitable?
>> 
>> Yes, since it's pure s/w emulated interface. At the case when SRAO
>> or SRAR not supported by h/w platform, it's still OK, since under
>> such case hypervisor don't need deliver SRAO or SRAR to guest at
>> all. The emulated vMCE interface just tell the guest that it runs at
>> a virtual platform with those well-defined capabilities.
> 
> I probably didn't express well enough what I want you to check:
> Consider you had done the current re-design work without
> SRAO/SRAR in mind (e.g. a couple of years ago). Would the
> end result have been the same? Namely, would the bits you
> nominate to be set/clear in MCG_CAP be the same?
> 
>>> I think that we minimally need to retain the MCG_CAP register
>>> as being of potentially variable content (and hence needing
>>> saving/restoring on migration). To support this in a forward
>>> compatible manner, we may have to have a way to tell the
>>> hypervisor e.g. via command line option which extra MSRs
>>> have to be treated read-as-zero/writes-ignored upon guest
>>> accesses.
>> 
>> Seems unnecessary, reason as above.
> 
> So going forward you see no possibility of additions to the
> interface that might warrant allowing more bits to be set in
> MCG_CAP than you define to be set here? That really looks
> unrealistic to me.
> 
> Jan

Sorry for misunderstanding your meaning in my last email, please ignore it. 
I agree that MCG_CAP should be save/restore when migration, considering in the future some CAP bit may be added.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 08:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 08:31:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj4gq-0006YF-GL; Mon, 25 Jun 2012 08:30:32 +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 1Sj4go-0006YA-RU
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 08:30:31 +0000
Received: from [85.158.143.35:46228] by server-1.bemta-4.messagelabs.com id
	18/CB-24392-6A128EF4; Mon, 25 Jun 2012 08:30:30 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340613021!6185561!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkwMjQz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12143 invoked from network); 25 Jun 2012 08:30:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 08:30:22 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 25 Jun 2012 01:30:20 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="162182415"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 25 Jun 2012 01:30:19 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 01:30:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Mon, 25 Jun 2012 16:30:17 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: AQHNUIitexbUH0BVTLGVMLMLWAtaJ5cKtlBA
Date: Mon, 25 Jun 2012 08:30:17 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335258568@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
In-Reply-To: <4FE4A636020000780008B756@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 22.06.12 at 15:46, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>> One other concern that occurred to me after long having sent
>>> the original response: Your proposal aims at a fixed,
>>> unmodifiable vMCE interface. How is that going to be forward
>>> compatible? I.e. consider you had made that proposal before
>>> the SRAO/SRAR changes went in - would the same interface (with
>>> the same set of capability bits set/clear) still be suitable?
>> 
>> Yes, since it's pure s/w emulated interface. At the case when SRAO
>> or SRAR not supported by h/w platform, it's still OK, since under
>> such case hypervisor don't need deliver SRAO or SRAR to guest at
>> all. The emulated vMCE interface just tell the guest that it runs at
>> a virtual platform with those well-defined capabilities.
> 
> I probably didn't express well enough what I want you to check:
> Consider you had done the current re-design work without
> SRAO/SRAR in mind (e.g. a couple of years ago). Would the
> end result have been the same? Namely, would the bits you
> nominate to be set/clear in MCG_CAP be the same?
> 
>>> I think that we minimally need to retain the MCG_CAP register
>>> as being of potentially variable content (and hence needing
>>> saving/restoring on migration). To support this in a forward
>>> compatible manner, we may have to have a way to tell the
>>> hypervisor e.g. via command line option which extra MSRs
>>> have to be treated read-as-zero/writes-ignored upon guest
>>> accesses.
>> 
>> Seems unnecessary, reason as above.
> 
> So going forward you see no possibility of additions to the
> interface that might warrant allowing more bits to be set in
> MCG_CAP than you define to be set here? That really looks
> unrealistic to me.
> 
> Jan

Sorry for misunderstanding your meaning in my last email, please ignore it. 
I agree that MCG_CAP should be save/restore when migration, considering in the future some CAP bit may be added.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 08:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 08: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 1Sj548-00075C-DT; Mon, 25 Jun 2012 08:54: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 1Sj547-000757-0b
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 08:54:35 +0000
Received: from [85.158.143.35:60348] by server-1.bemta-4.messagelabs.com id
	29/70-24392-A4728EF4; Mon, 25 Jun 2012 08:54:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340614470!13894704!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21958 invoked from network); 25 Jun 2012 08:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 08:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13193696"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 08:54:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 09:54:29 +0100
Message-ID: <1340614467.3832.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 09:54:27 +0100
In-Reply-To: <osstest-13361-mainreport@xen.org>
References: <osstest-13361-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-3.0 test] 13361: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-06-24 at 17:47 +0100, xen.org wrote:
> flight 13361 linux-3.0 real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/
> 
> 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. 13100

This has failed a couple of time now.

[0] shows the test system waits from 2012-06-24 12:10:03 Z until
2012-06-24 12:16:46 Z for the machine to reappear on the network.

[1] shows that the system was fully booted at Jun 24 12:13:58.599838
which is in plenty of time. The brctl and route logs look sensible. The
ifconfig log shows an IP address in the right place and both TX and RX
packets being counted.

How synchronised are the clocks used in [0] and [1]?

Ian.

[0] http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/test-i386-i386-xl/5.ts-host-reboot.log 
[1] http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/test-i386-i386-xl/serial-woodlouse.log 


> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-xl-multivcpu 10 guest-saverestore           fail pass in 13356
>  test-amd64-i386-xl            5 xen-boot                    fail pass in 13356
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100
>  test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail like 13100
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
>  test-i386-i386-xl-qemuu-winxpsp3 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-i386-i386-win           16 leak-check/check             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-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 13356 never pass
> 
> version targeted for testing:
>  linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
> baseline version:
>  linux                839cf7a236278ae358ff12141a168c0982fa0cd9
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           fail    
>  test-i386-i386-xl                                            fail    
>  test-amd64-i386-rhel6hvm-amd                                 pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   pass    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  test-amd64-i386-xl-multivcpu                                 fail    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-xl-sedf-pin                                 pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-i386-i386-xl-qemuu-winxpsp3                             fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> 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 Mon Jun 25 08:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 08: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 1Sj548-00075C-DT; Mon, 25 Jun 2012 08:54: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 1Sj547-000757-0b
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 08:54:35 +0000
Received: from [85.158.143.35:60348] by server-1.bemta-4.messagelabs.com id
	29/70-24392-A4728EF4; Mon, 25 Jun 2012 08:54:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340614470!13894704!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21958 invoked from network); 25 Jun 2012 08:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 08:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13193696"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 08:54:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 09:54:29 +0100
Message-ID: <1340614467.3832.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 09:54:27 +0100
In-Reply-To: <osstest-13361-mainreport@xen.org>
References: <osstest-13361-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux-3.0 test] 13361: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-06-24 at 17:47 +0100, xen.org wrote:
> flight 13361 linux-3.0 real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/
> 
> 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. 13100

This has failed a couple of time now.

[0] shows the test system waits from 2012-06-24 12:10:03 Z until
2012-06-24 12:16:46 Z for the machine to reappear on the network.

[1] shows that the system was fully booted at Jun 24 12:13:58.599838
which is in plenty of time. The brctl and route logs look sensible. The
ifconfig log shows an IP address in the right place and both TX and RX
packets being counted.

How synchronised are the clocks used in [0] and [1]?

Ian.

[0] http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/test-i386-i386-xl/5.ts-host-reboot.log 
[1] http://www.chiark.greenend.org.uk/~xensrcts/logs/13361/test-i386-i386-xl/serial-woodlouse.log 


> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-xl-multivcpu 10 guest-saverestore           fail pass in 13356
>  test-amd64-i386-xl            5 xen-boot                    fail pass in 13356
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100
>  test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail like 13100
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
>  test-i386-i386-xl-qemuu-winxpsp3 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-i386-i386-win           16 leak-check/check             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-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 13356 never pass
> 
> version targeted for testing:
>  linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
> baseline version:
>  linux                839cf7a236278ae358ff12141a168c0982fa0cd9
> 
> jobs:
>  build-amd64                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          pass    
>  test-amd64-i386-xl                                           fail    
>  test-i386-i386-xl                                            fail    
>  test-amd64-i386-rhel6hvm-amd                                 pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
>  test-amd64-amd64-xl-win7-amd64                               fail    
>  test-amd64-i386-xl-win7-amd64                                fail    
>  test-amd64-i386-xl-credit2                                   pass    
>  test-amd64-amd64-xl-pcipt-intel                              fail    
>  test-amd64-i386-rhel6hvm-intel                               pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  test-amd64-i386-xl-multivcpu                                 fail    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-i386-i386-pair                                          pass    
>  test-amd64-amd64-xl-sedf-pin                                 pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           pass    
>  test-i386-i386-pv                                            pass    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-i386-i386-win                                           fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-i386-i386-xl-qemuu-winxpsp3                             fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
>  test-i386-i386-xl-winxpsp3                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> 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 Mon Jun 25 09:02:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 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 1Sj5Bc-0007H9-E6; Mon, 25 Jun 2012 09:02:20 +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 1Sj5Ba-0007H4-GL
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:02:18 +0000
Received: from [85.158.143.35:59133] by server-1.bemta-4.messagelabs.com id
	27/81-24392-91928EF4; Mon, 25 Jun 2012 09:02:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340614923!16804991!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30887 invoked from network); 25 Jun 2012 09:02:04 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 09:02:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5BJ-000CF7-GQ; Mon, 25 Jun 2012 09:02:01 +0000
Date: Mon, 25 Jun 2012 10:02:01 +0100
From: Tim Deegan <tim@xen.org>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20120625090201.GB1488@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, haitao.shan@intel.com, JBeulich@suse.com,
	xiantao.zhang@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
> Changes from v1:
> - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to patch2.
> - define them as bool_t instead of int.
> 
> Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
> enable VMMs to efficiently implement memory management and page classification
> algorithms to optimize VM memory operations.
> 
> This series of patches enable EPT dirty bit feature for guest live migration.

Thanks for this.  I have a few high-level questions:

- You're proposing this for after 4.2, right?

- Have you measured what difference this makes?  I take it it improves
  performance during live migration but it would be good to know how much
  before taking on extra code.

- Is this intended to replace the old log-dirty mechanism for vram
  tracking as well?  It looks like it does that, but the description
  doesn't mention it. 

I'll be reviewing te patches in more detail later in the week. 

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 Jun 25 09:02:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 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 1Sj5Bc-0007H9-E6; Mon, 25 Jun 2012 09:02:20 +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 1Sj5Ba-0007H4-GL
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:02:18 +0000
Received: from [85.158.143.35:59133] by server-1.bemta-4.messagelabs.com id
	27/81-24392-91928EF4; Mon, 25 Jun 2012 09:02:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340614923!16804991!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30887 invoked from network); 25 Jun 2012 09:02:04 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 09:02:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5BJ-000CF7-GQ; Mon, 25 Jun 2012 09:02:01 +0000
Date: Mon, 25 Jun 2012 10:02:01 +0100
From: Tim Deegan <tim@xen.org>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20120625090201.GB1488@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, haitao.shan@intel.com, JBeulich@suse.com,
	xiantao.zhang@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
> Changes from v1:
> - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to patch2.
> - define them as bool_t instead of int.
> 
> Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
> enable VMMs to efficiently implement memory management and page classification
> algorithms to optimize VM memory operations.
> 
> This series of patches enable EPT dirty bit feature for guest live migration.

Thanks for this.  I have a few high-level questions:

- You're proposing this for after 4.2, right?

- Have you measured what difference this makes?  I take it it improves
  performance during live migration but it would be good to know how much
  before taking on extra code.

- Is this intended to replace the old log-dirty mechanism for vram
  tracking as well?  It looks like it does that, but the description
  doesn't mention it. 

I'll be reviewing te patches in more detail later in the week. 

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 Jun 25 09:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:06: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 1Sj5Et-0007Pi-1W; Mon, 25 Jun 2012 09:05: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 1Sj5Er-0007Pb-8C
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:05:41 +0000
Received: from [85.158.143.99:24083] by server-2.bemta-4.messagelabs.com id
	C0/E9-17938-4E928EF4; Mon, 25 Jun 2012 09:05:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340615139!21231811!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18562 invoked from network); 25 Jun 2012 09:05:39 -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; 25 Jun 2012 09:05:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5En-000CIP-74; Mon, 25 Jun 2012 09:05:37 +0000
Date: Mon, 25 Jun 2012 10:05:37 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <20120625090537.GC1488@ocelot.phlegethon.org>
References: <20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> >> On 14/06 03:56, Tim Deegan wrote:
> >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> >> > > Are you talking about having different version of V4V driver runni=
ng
> >> > > in the same VM?
> >> >
> >> > Yes.
> >> >
> >> > > I don't think that is a problem they both interact with Xen via
> >> > > hypercall directly so if they follow the v4v hypercall interface i=
t's
> >> > > all fine.
> >> >
> >> > AFAICS if they both try to register the same port then one of them w=
ill
> >> > silently get its ring discarded. =A0And if they both try to communic=
ate
> >> > with the same remote port their entries on the pending lists will get
> >> > merged (which is probably not too bad). =A0I think the possibility f=
or
> >> > confusion depends on how you use the service. =A0Still, it seems bet=
ter
> >> > than the xenstore case, anyway. :)
> >> >
> >>
> >> Not silently, register_ring will return an error.
> >
> > Will it? =A0It looks to me like v4v_ring_add just clobbers the old MFN
> > list.
> >
> =

> Ha yes. It does that now but I think it should return an error
> informing up the stack that a ring has already been registered.

Actually, I think it's deliberate, to allow a guest to re-register all
its rings after a suspend/resume or migration, without having to worry
about whether it was actually migrated into a new domain or not. =


That raises the question of how a v4v client ought to handle migration;
doesn't it have to rely on other OS components to notify it that one has
happened?

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 Jun 25 09:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:06: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 1Sj5Et-0007Pi-1W; Mon, 25 Jun 2012 09:05: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 1Sj5Er-0007Pb-8C
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:05:41 +0000
Received: from [85.158.143.99:24083] by server-2.bemta-4.messagelabs.com id
	C0/E9-17938-4E928EF4; Mon, 25 Jun 2012 09:05:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340615139!21231811!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18562 invoked from network); 25 Jun 2012 09:05:39 -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; 25 Jun 2012 09:05:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5En-000CIP-74; Mon, 25 Jun 2012 09:05:37 +0000
Date: Mon, 25 Jun 2012 10:05:37 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <20120625090537.GC1488@ocelot.phlegethon.org>
References: <20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> >> On 14/06 03:56, Tim Deegan wrote:
> >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> >> > > Are you talking about having different version of V4V driver runni=
ng
> >> > > in the same VM?
> >> >
> >> > Yes.
> >> >
> >> > > I don't think that is a problem they both interact with Xen via
> >> > > hypercall directly so if they follow the v4v hypercall interface i=
t's
> >> > > all fine.
> >> >
> >> > AFAICS if they both try to register the same port then one of them w=
ill
> >> > silently get its ring discarded. =A0And if they both try to communic=
ate
> >> > with the same remote port their entries on the pending lists will get
> >> > merged (which is probably not too bad). =A0I think the possibility f=
or
> >> > confusion depends on how you use the service. =A0Still, it seems bet=
ter
> >> > than the xenstore case, anyway. :)
> >> >
> >>
> >> Not silently, register_ring will return an error.
> >
> > Will it? =A0It looks to me like v4v_ring_add just clobbers the old MFN
> > list.
> >
> =

> Ha yes. It does that now but I think it should return an error
> informing up the stack that a ring has already been registered.

Actually, I think it's deliberate, to allow a guest to re-register all
its rings after a suspend/resume or migration, without having to worry
about whether it was actually migrated into a new domain or not. =


That raises the question of how a v4v client ought to handle migration;
doesn't it have to rely on other OS components to notify it that one has
happened?

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 Jun 25 09:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:06: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 1Sj5Ew-0007Q1-EG; Mon, 25 Jun 2012 09:05: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 1Sj5Ev-0007Ps-Mv
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 09:05:45 +0000
Received: from [85.158.143.35:28158] by server-3.bemta-4.messagelabs.com id
	83/1A-05808-9E928EF4; Mon, 25 Jun 2012 09:05:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340615137!13201134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16938 invoked from network); 25 Jun 2012 09:05:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 09:05:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13194025"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 09:05:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 10:05:21 +0100
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 1Sj5EX-0003QO-6N;
	Mon, 25 Jun 2012 09:05:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sj5EW-0007U0-K8;
	Mon, 25 Jun 2012 10:05:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13365-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 10:05:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13365: 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 13365 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13365/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13354

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  836db8c4b9f9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 09:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:06: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 1Sj5Ew-0007Q1-EG; Mon, 25 Jun 2012 09:05: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 1Sj5Ev-0007Ps-Mv
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 09:05:45 +0000
Received: from [85.158.143.35:28158] by server-3.bemta-4.messagelabs.com id
	83/1A-05808-9E928EF4; Mon, 25 Jun 2012 09:05:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340615137!13201134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16938 invoked from network); 25 Jun 2012 09:05:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 09:05:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13194025"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 09:05:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 10:05:21 +0100
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 1Sj5EX-0003QO-6N;
	Mon, 25 Jun 2012 09:05:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sj5EW-0007U0-K8;
	Mon, 25 Jun 2012 10:05:20 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13365-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 10:05:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13365: 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 13365 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13365/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13354

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  836db8c4b9f9
baseline version:
 xen                  836db8c4b9f9

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 09:08:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09: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 1Sj5H3-0007bj-Vz; Mon, 25 Jun 2012 09:07: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 1Sj5H3-0007be-0o
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:07:57 +0000
Received: from [85.158.143.35:43582] by server-3.bemta-4.messagelabs.com id
	6E/ED-05808-C6A28EF4; Mon, 25 Jun 2012 09:07:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340615274!14736886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27254 invoked from network); 25 Jun 2012 09:07:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 09:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13194097"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 09:07:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 10:07:47 +0100
Message-ID: <1340615266.3832.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 25 Jun 2012 10:07:46 +0100
In-Reply-To: <4FE4BB5F.5000103@citrix.com>
References: <4FE4BB5F.5000103@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 19:37 +0100, Andrew Cooper wrote:
> 
> diff -r 32034d1914a6 tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -821,10 +821,15 @@ if __name__ == "__main__":
>      if not fs:
>          raise RuntimeError, "Unable to find partition containing
> kernel"
>  
> +    # Does the chosen kernel really exist ?
> +    try:
> +        data = fs.open_file(chosencfg["kernel"]).read()

If you make this use .exists() and left the open/read where it was that
would be more in keeping with the intended meaning of the not_really
flag.


> +    except:
> +        raise RuntimeError, "The chosen kernel does not exist"
> +
>      if not_really:
>          bootcfg["kernel"] = "<kernel:%s>" % chosencfg["kernel"]
>      else:
> -        data = fs.open_file(chosencfg["kernel"]).read()
>          (tfd, bootcfg["kernel"]) =
> tempfile.mkstemp(prefix="boot_kernel.",
> 
> dir=output_directory)
>          os.write(tfd, data) 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 09:08:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09: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 1Sj5H3-0007bj-Vz; Mon, 25 Jun 2012 09:07: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 1Sj5H3-0007be-0o
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:07:57 +0000
Received: from [85.158.143.35:43582] by server-3.bemta-4.messagelabs.com id
	6E/ED-05808-C6A28EF4; Mon, 25 Jun 2012 09:07:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340615274!14736886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27254 invoked from network); 25 Jun 2012 09:07:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 09:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13194097"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 09:07:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 10:07:47 +0100
Message-ID: <1340615266.3832.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 25 Jun 2012 10:07:46 +0100
In-Reply-To: <4FE4BB5F.5000103@citrix.com>
References: <4FE4BB5F.5000103@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 19:37 +0100, Andrew Cooper wrote:
> 
> diff -r 32034d1914a6 tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -821,10 +821,15 @@ if __name__ == "__main__":
>      if not fs:
>          raise RuntimeError, "Unable to find partition containing
> kernel"
>  
> +    # Does the chosen kernel really exist ?
> +    try:
> +        data = fs.open_file(chosencfg["kernel"]).read()

If you make this use .exists() and left the open/read where it was that
would be more in keeping with the intended meaning of the not_really
flag.


> +    except:
> +        raise RuntimeError, "The chosen kernel does not exist"
> +
>      if not_really:
>          bootcfg["kernel"] = "<kernel:%s>" % chosencfg["kernel"]
>      else:
> -        data = fs.open_file(chosencfg["kernel"]).read()
>          (tfd, bootcfg["kernel"]) =
> tempfile.mkstemp(prefix="boot_kernel.",
> 
> dir=output_directory)
>          os.write(tfd, data) 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 09:08:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj5HG-0007d1-CE; Mon, 25 Jun 2012 09:08:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sj5HE-0007ci-UT
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:08:09 +0000
Received: from [85.158.143.35:46478] by server-2.bemta-4.messagelabs.com id
	D6/6F-17938-87A28EF4; Mon, 25 Jun 2012 09:08:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340615287!10767209!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26234 invoked from network); 25 Jun 2012 09:08:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 09:08:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5Gs-000CJV-5b; Mon, 25 Jun 2012 09:07:46 +0000
Date: Mon, 25 Jun 2012 10:07:46 +0100
From: Tim Deegan <tim@xen.org>
To: palutke.ralph@gmx.de
Message-ID: <20120625090746.GD1488@ocelot.phlegethon.org>
References: <20120621004447.GA12981@mean_maschine.fritz.box>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120621004447.GA12981@mean_maschine.fritz.box>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] how to check for already existing 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 02:44 +0200 on 21 Jun (1340246688), palutke.ralph@gmx.de wrote:
> Hi guys, 
> 
> let me shortly introduce myself. I'm a student and recently work on my bachelor thesis. My goal is to write a little hypervisor.
> I'm not quite sure if this is the right mailing list, but i guess you'll gonna tell me.
> i have two quick questions:
> 
> 1. before i can use the vmxon instruction i do have to set vmxe flag in cr4 register. but what if some hypervisor is already running? is there a way to check 
> if one is running??

A lot of hypervisors report their presence in CPUID leaves - have a look
at xen-detect in the tools/ directory for how to spot Xen. 


Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 09:08:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj5HG-0007d1-CE; Mon, 25 Jun 2012 09:08:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Sj5HE-0007ci-UT
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:08:09 +0000
Received: from [85.158.143.35:46478] by server-2.bemta-4.messagelabs.com id
	D6/6F-17938-87A28EF4; Mon, 25 Jun 2012 09:08:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340615287!10767209!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26234 invoked from network); 25 Jun 2012 09:08:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 09:08:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5Gs-000CJV-5b; Mon, 25 Jun 2012 09:07:46 +0000
Date: Mon, 25 Jun 2012 10:07:46 +0100
From: Tim Deegan <tim@xen.org>
To: palutke.ralph@gmx.de
Message-ID: <20120625090746.GD1488@ocelot.phlegethon.org>
References: <20120621004447.GA12981@mean_maschine.fritz.box>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120621004447.GA12981@mean_maschine.fritz.box>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] how to check for already existing 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 02:44 +0200 on 21 Jun (1340246688), palutke.ralph@gmx.de wrote:
> Hi guys, 
> 
> let me shortly introduce myself. I'm a student and recently work on my bachelor thesis. My goal is to write a little hypervisor.
> I'm not quite sure if this is the right mailing list, but i guess you'll gonna tell me.
> i have two quick questions:
> 
> 1. before i can use the vmxon instruction i do have to set vmxe flag in cr4 register. but what if some hypervisor is already running? is there a way to check 
> if one is running??

A lot of hypervisors report their presence in CPUID leaves - have a look
at xen-detect in the tools/ directory for how to spot Xen. 


Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 09:23:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj5Vf-00081Z-P4; Mon, 25 Jun 2012 09:23:03 +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 1Sj5Vf-00081U-2U
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:23:03 +0000
Received: from [85.158.143.35:3327] by server-2.bemta-4.messagelabs.com id
	41/22-17938-6FD28EF4; Mon, 25 Jun 2012 09:23:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340616123!6030266!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 25 Jun 2012 09:22:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 09:22:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5Ug-000CMn-S7; Mon, 25 Jun 2012 09:22:02 +0000
Date: Mon, 25 Jun 2012 10:22:02 +0100
From: Tim Deegan <tim@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120625092202.GE1488@ocelot.phlegethon.org>
References: <4FE30B08.2010407@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE30B08.2010407@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] nsvm: fix check if guest enabled nested
	paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:52 +0200 on 21 Jun (1340286760), Christoph Egger wrote:
> 
> Fix check if guest enabled nested paging.
> Fixes crashes with Windows guests when shadow-on-nested is used.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.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 Mon Jun 25 09:23:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 09:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj5Vf-00081Z-P4; Mon, 25 Jun 2012 09:23:03 +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 1Sj5Vf-00081U-2U
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 09:23:03 +0000
Received: from [85.158.143.35:3327] by server-2.bemta-4.messagelabs.com id
	41/22-17938-6FD28EF4; Mon, 25 Jun 2012 09:23:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340616123!6030266!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 25 Jun 2012 09:22:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 09:22:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sj5Ug-000CMn-S7; Mon, 25 Jun 2012 09:22:02 +0000
Date: Mon, 25 Jun 2012 10:22:02 +0100
From: Tim Deegan <tim@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120625092202.GE1488@ocelot.phlegethon.org>
References: <4FE30B08.2010407@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE30B08.2010407@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] nsvm: fix check if guest enabled nested
	paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:52 +0200 on 21 Jun (1340286760), Christoph Egger wrote:
> 
> Fix check if guest enabled nested paging.
> Fixes crashes with Windows guests when shadow-on-nested is used.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.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 Mon Jun 25 10:14:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:14: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 1Sj6IP-0008Rj-Mg; Mon, 25 Jun 2012 10:13:25 +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 1Sj6IN-0008Re-Uw
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:13:24 +0000
Received: from [85.158.138.51:38040] by server-1.bemta-3.messagelabs.com id
	87/D5-14648-EB938EF4; Mon, 25 Jun 2012 10:13:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340619196!29399847!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27239 invoked from network); 25 Jun 2012 10:13:17 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 10:13:17 -0000
Received: by obbta14 with SMTP id ta14so8492390obb.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 03:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=LG++/opBApQ3Z2IwypXFuZcqu0bwC4me6IZTfc/CsUg=;
	b=w+lLDTUGH3oA+ZYb3ESpfW0PEWoM5qdi3fiDoptmbJixH0wcmTEGSYvsLBil8uVr2x
	kXSYrA49ptAQlEomLt7ZZEzNvN1D2f4ip0B/iMd3MvP2mwBqbdc23Zwo2owepgqb04+z
	wET5E2pZPzwVPCNPPh3aNewPdIBWo8A7Z5d7OThLMpO12JxCUvOORlXdbD6/AkBHy2uz
	yE++JfG0TPexuhhGdpWB+JaAtq+1li5IvIyrJTJu8mlDPYzX6i8071fvqaepfa7qRbNN
	zd0irgr2kxRv/SWLzOwy4evw/D/YesFszl5wWAR8ipjcoGDtnCQrAodzEL9yr4erez/k
	iiZg==
MIME-Version: 1.0
Received: by 10.182.174.68 with SMTP id bq4mr11685566obc.53.1340619196158;
	Mon, 25 Jun 2012 03:13:16 -0700 (PDT)
Received: by 10.182.176.36 with HTTP; Mon, 25 Jun 2012 03:13:16 -0700 (PDT)
In-Reply-To: <4FE76535.1090801@abpni.co.uk>
References: <4FE75FAB.9040903@abpni.co.uk>
	<CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
	<4FE76535.1090801@abpni.co.uk>
Date: Mon, 25 Jun 2012 11:13:16 +0100
X-Google-Sender-Auth: wi0xOCIQ-wRvyN00BNs4iuBHAFs
Message-ID: <CAFLBxZb2JkR=Fv=4GuB4hj3QxHjVJBpKiO42KVXBFEaWx-dd3g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
Cc: Rolu <rolu@roce.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Intel Security 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Jun 24, 2012 at 8:06 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wro=
te:
>
> On 24/06/2012 20:01, Rolu wrote:
>>
>> On Sun, Jun 24, 2012 at 8:42 PM, Jonathan Tripathy<jonnyt@abpni.co.uk>
>> =A0wrote:
>>>
>>> Hi Everyone,
>>>
>>> Given that a lot of us run "untrusted" DomUs where the Domu administrat=
or
>>> has full control over their PV kernel, could this Intel security issue
>>> impact the hypervisor and put other DomUs at risk?
>>>
>>>
>>> http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64=
-intel-processor
>>>
>> That page links to http://www.kb.cert.org/vuls/id/649219 which links
>> to http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
>> which answers your question ;-)
>>
>> Yes, it's an issue. There are patches.
>
> Silly me! I've been following the inclusion of that Xen patch as well! I
> just didn't put 2+2 together.
>
> Thanks for your time!

Thank you for checking though -- if someone had done the same with the
Linux vulnerability in 2006, Xen would have had it fixed a long time
ago...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 10:14:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:14: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 1Sj6IP-0008Rj-Mg; Mon, 25 Jun 2012 10:13:25 +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 1Sj6IN-0008Re-Uw
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:13:24 +0000
Received: from [85.158.138.51:38040] by server-1.bemta-3.messagelabs.com id
	87/D5-14648-EB938EF4; Mon, 25 Jun 2012 10:13:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340619196!29399847!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27239 invoked from network); 25 Jun 2012 10:13:17 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 10:13:17 -0000
Received: by obbta14 with SMTP id ta14so8492390obb.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 03:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=LG++/opBApQ3Z2IwypXFuZcqu0bwC4me6IZTfc/CsUg=;
	b=w+lLDTUGH3oA+ZYb3ESpfW0PEWoM5qdi3fiDoptmbJixH0wcmTEGSYvsLBil8uVr2x
	kXSYrA49ptAQlEomLt7ZZEzNvN1D2f4ip0B/iMd3MvP2mwBqbdc23Zwo2owepgqb04+z
	wET5E2pZPzwVPCNPPh3aNewPdIBWo8A7Z5d7OThLMpO12JxCUvOORlXdbD6/AkBHy2uz
	yE++JfG0TPexuhhGdpWB+JaAtq+1li5IvIyrJTJu8mlDPYzX6i8071fvqaepfa7qRbNN
	zd0irgr2kxRv/SWLzOwy4evw/D/YesFszl5wWAR8ipjcoGDtnCQrAodzEL9yr4erez/k
	iiZg==
MIME-Version: 1.0
Received: by 10.182.174.68 with SMTP id bq4mr11685566obc.53.1340619196158;
	Mon, 25 Jun 2012 03:13:16 -0700 (PDT)
Received: by 10.182.176.36 with HTTP; Mon, 25 Jun 2012 03:13:16 -0700 (PDT)
In-Reply-To: <4FE76535.1090801@abpni.co.uk>
References: <4FE75FAB.9040903@abpni.co.uk>
	<CABs9EjkmxHnFxuVZ=Mt2_vwuRPnboefG7G533nR_LjWFk1Ncdg@mail.gmail.com>
	<4FE76535.1090801@abpni.co.uk>
Date: Mon, 25 Jun 2012 11:13:16 +0100
X-Google-Sender-Auth: wi0xOCIQ-wRvyN00BNs4iuBHAFs
Message-ID: <CAFLBxZb2JkR=Fv=4GuB4hj3QxHjVJBpKiO42KVXBFEaWx-dd3g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
Cc: Rolu <rolu@roce.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Intel Security 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Jun 24, 2012 at 8:06 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wro=
te:
>
> On 24/06/2012 20:01, Rolu wrote:
>>
>> On Sun, Jun 24, 2012 at 8:42 PM, Jonathan Tripathy<jonnyt@abpni.co.uk>
>> =A0wrote:
>>>
>>> Hi Everyone,
>>>
>>> Given that a lot of us run "untrusted" DomUs where the Domu administrat=
or
>>> has full control over their PV kernel, could this Intel security issue
>>> impact the hypervisor and put other DomUs at risk?
>>>
>>>
>>> http://www.theverge.com/2012/6/18/3092949/security-vulnerability-x86-64=
-intel-processor
>>>
>> That page links to http://www.kb.cert.org/vuls/id/649219 which links
>> to http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html
>> which answers your question ;-)
>>
>> Yes, it's an issue. There are patches.
>
> Silly me! I've been following the inclusion of that Xen patch as well! I
> just didn't put 2+2 together.
>
> Thanks for your time!

Thank you for checking though -- if someone had done the same with the
Linux vulnerability in 2006, Xen would have had it fixed a long time
ago...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 10:19:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj6Nq-000081-F2; Mon, 25 Jun 2012 10:19:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Sj6No-00007u-NN
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:19:00 +0000
Received: from [193.109.254.147:44283] by server-5.bemta-14.messagelabs.com id
	D1/E9-04343-41B38EF4; Mon, 25 Jun 2012 10:19:00 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340619538!4572188!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDUxNTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11524 invoked from network); 25 Jun 2012 10:18:59 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 10:18:59 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5PAIVUZ015303;
	Mon, 25 Jun 2012 11:18:35 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5PAHlHf015134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 11:17:47 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5PAHkUx008066;
	Mon, 25 Jun 2012 11:17:46 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5PAHkBK008063; Mon, 25 Jun 2012 11:17:46 +0100 (BST)
Date: Mon, 25 Jun 2012 11:17:46 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340615266.3832.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.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: q5PAIVUZ015303
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Mon, 25 Jun 2012, Ian Campbell wrote:

> On Fri, 2012-06-22 at 19:37 +0100, Andrew Cooper wrote:
>>
>> diff -r 32034d1914a6 tools/pygrub/src/pygrub
>> --- a/tools/pygrub/src/pygrub
>> +++ b/tools/pygrub/src/pygrub
>> @@ -821,10 +821,15 @@ if __name__ == "__main__":
>>      if not fs:
>>          raise RuntimeError, "Unable to find partition containing
>> kernel"
>>
>> +    # Does the chosen kernel really exist ?
>> +    try:
>> +        data = fs.open_file(chosencfg["kernel"]).read()
>
> If you make this use .exists() and left the open/read where it was that
> would be more in keeping with the intended meaning of the not_really
> flag.

Also if you are checking for the kernel, shouldn't you also check for the 
ramdisk if one is requested for consistency.

It also hits the same area of code as the proposed protection against 
problems caused by huge kernels in the guests (eg. see
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01183.html
or http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
and it was suggested that it might be better to use a function to do this 
bit of the code rather than duplicating it for both kernel and ramdisk.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 10:19:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj6Nq-000081-F2; Mon, 25 Jun 2012 10:19:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Sj6No-00007u-NN
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:19:00 +0000
Received: from [193.109.254.147:44283] by server-5.bemta-14.messagelabs.com id
	D1/E9-04343-41B38EF4; Mon, 25 Jun 2012 10:19:00 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340619538!4572188!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDUxNTY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11524 invoked from network); 25 Jun 2012 10:18:59 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 10:18:59 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5PAIVUZ015303;
	Mon, 25 Jun 2012 11:18:35 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5PAHlHf015134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 11:17:47 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5PAHkUx008066;
	Mon, 25 Jun 2012 11:17:46 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5PAHkBK008063; Mon, 25 Jun 2012 11:17:46 +0100 (BST)
Date: Mon, 25 Jun 2012 11:17:46 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340615266.3832.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.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: q5PAIVUZ015303
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Mon, 25 Jun 2012, Ian Campbell wrote:

> On Fri, 2012-06-22 at 19:37 +0100, Andrew Cooper wrote:
>>
>> diff -r 32034d1914a6 tools/pygrub/src/pygrub
>> --- a/tools/pygrub/src/pygrub
>> +++ b/tools/pygrub/src/pygrub
>> @@ -821,10 +821,15 @@ if __name__ == "__main__":
>>      if not fs:
>>          raise RuntimeError, "Unable to find partition containing
>> kernel"
>>
>> +    # Does the chosen kernel really exist ?
>> +    try:
>> +        data = fs.open_file(chosencfg["kernel"]).read()
>
> If you make this use .exists() and left the open/read where it was that
> would be more in keeping with the intended meaning of the not_really
> flag.

Also if you are checking for the kernel, shouldn't you also check for the 
ramdisk if one is requested for consistency.

It also hits the same area of code as the proposed protection against 
problems caused by huge kernels in the guests (eg. see
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01183.html
or http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
and it was suggested that it might be better to use a function to do this 
bit of the code rather than duplicating it for both kernel and ramdisk.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 10:47:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10: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 1Sj6p7-0000M7-Qe; Mon, 25 Jun 2012 10:47:13 +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 1Sj6p6-0000Ly-5f
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:47:12 +0000
Received: from [85.158.143.35:12316] by server-3.bemta-4.messagelabs.com id
	ED/D6-05808-FA148EF4; Mon, 25 Jun 2012 10:47:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340621060!16142388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20890 invoked from network); 25 Jun 2012 10:44:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:44:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:44:20 +0100
Message-Id: <4FE85D22020000780008BA8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:44:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9CB23612.1__="
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-traditional/xendisk: set maximum number of
 grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part9CB23612.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Legacy (non-pvops) gntdev drivers may require this to be done when the
number of grants intended to be used simultaneously exceeds a certain
driver specific default limit.

Change in v2: Double the number requested, as we need to account for
the allocations needing to happen in contiguous chunks. The worst case
number would be max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
but in order to keep things simple just use 2 * max_req * max_seg.

upstream-commit: 64c27e5b1fdb6d94bdc0bda3b1869d7383a35c65

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -570,6 +570,15 @@ static void blk_bh(void *opaque)
     blk_handle_requests(blkdev);
 }
=20
+/*
+ * We need to account for the grant allocations requiring contiguous
+ * chunks; the worst case number would be
+ *     max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
+ * but in order to keep things simple just use
+ *     2 * max_req * max_seg.
+ */
+#define MAX_GRANTS(max_req, max_seg) (2 * (max_req) * (max_seg))
+
 static void blk_alloc(struct XenDevice *xendev)
 {
     struct XenBlkDev *blkdev =3D container_of(xendev, struct XenBlkDev, =
xendev);
@@ -580,6 +589,11 @@ static void blk_alloc(struct XenDevice *
     blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
     if (xen_mode !=3D XEN_EMULATE)
         batch_maps =3D 1;
+    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
+            MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < =
0) {
+        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
+                      strerror(errno));
+    }
 }
=20
 static int blk_init(struct XenDevice *xendev)




--=__Part9CB23612.1__=
Content-Type: text/plain; name="qemu-xendisk-set-max-grants.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-xendisk-set-max-grants.patch"

qemu-traditional/xendisk: set maximum number of grants to be used=0A=0ALega=
cy (non-pvops) gntdev drivers may require this to be done when the=0Anumber=
 of grants intended to be used simultaneously exceeds a certain=0Adriver =
specific default limit.=0A=0AChange in v2: Double the number requested, as =
we need to account for=0Athe allocations needing to happen in contiguous =
chunks. The worst case=0Anumber would be max_req * max_seg + (max_req - 1) =
* (max_seg - 1) + 1,=0Abut in order to keep things simple just use 2 * =
max_req * max_seg.=0A=0Aupstream-commit: 64c27e5b1fdb6d94bdc0bda3b1869d7383=
a35c65=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ASigned-off-by:=
 Stefano Stabellini <stefano.stabellini@eu.citrix.com>=0A=0A--- a/hw/xen_di=
sk.c=0A+++ b/hw/xen_disk.c=0A@@ -570,6 +570,15 @@ static void blk_bh(void =
*opaque)=0A     blk_handle_requests(blkdev);=0A }=0A =0A+/*=0A+ * We need =
to account for the grant allocations requiring contiguous=0A+ * chunks; =
the worst case number would be=0A+ *     max_req * max_seg + (max_req - 1) =
* (max_seg - 1) + 1,=0A+ * but in order to keep things simple just use=0A+ =
*     2 * max_req * max_seg.=0A+ */=0A+#define MAX_GRANTS(max_req, =
max_seg) (2 * (max_req) * (max_seg))=0A+=0A static void blk_alloc(struct =
XenDevice *xendev)=0A {=0A     struct XenBlkDev *blkdev =3D container_of(xe=
ndev, struct XenBlkDev, xendev);=0A@@ -580,6 +589,11 @@ static void =
blk_alloc(struct XenDevice *=0A     blkdev->bh =3D qemu_bh_new(blk_bh, =
blkdev);=0A     if (xen_mode !=3D XEN_EMULATE)=0A         batch_maps =3D =
1;=0A+    if (xc_gnttab_set_max_grants(xendev->gnttabdev,=0A+            =
MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < 0) {=0A+       =
 xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",=0A+     =
                 strerror(errno));=0A+    }=0A }=0A =0A static int =
blk_init(struct XenDevice *xendev)=0A
--=__Part9CB23612.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

--=__Part9CB23612.1__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:47:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10: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 1Sj6p7-0000M7-Qe; Mon, 25 Jun 2012 10:47:13 +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 1Sj6p6-0000Ly-5f
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:47:12 +0000
Received: from [85.158.143.35:12316] by server-3.bemta-4.messagelabs.com id
	ED/D6-05808-FA148EF4; Mon, 25 Jun 2012 10:47:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340621060!16142388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20890 invoked from network); 25 Jun 2012 10:44:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:44:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:44:20 +0100
Message-Id: <4FE85D22020000780008BA8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:44:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9CB23612.1__="
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-traditional/xendisk: set maximum number of
 grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part9CB23612.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Legacy (non-pvops) gntdev drivers may require this to be done when the
number of grants intended to be used simultaneously exceeds a certain
driver specific default limit.

Change in v2: Double the number requested, as we need to account for
the allocations needing to happen in contiguous chunks. The worst case
number would be max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
but in order to keep things simple just use 2 * max_req * max_seg.

upstream-commit: 64c27e5b1fdb6d94bdc0bda3b1869d7383a35c65

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -570,6 +570,15 @@ static void blk_bh(void *opaque)
     blk_handle_requests(blkdev);
 }
=20
+/*
+ * We need to account for the grant allocations requiring contiguous
+ * chunks; the worst case number would be
+ *     max_req * max_seg + (max_req - 1) * (max_seg - 1) + 1,
+ * but in order to keep things simple just use
+ *     2 * max_req * max_seg.
+ */
+#define MAX_GRANTS(max_req, max_seg) (2 * (max_req) * (max_seg))
+
 static void blk_alloc(struct XenDevice *xendev)
 {
     struct XenBlkDev *blkdev =3D container_of(xendev, struct XenBlkDev, =
xendev);
@@ -580,6 +589,11 @@ static void blk_alloc(struct XenDevice *
     blkdev->bh =3D qemu_bh_new(blk_bh, blkdev);
     if (xen_mode !=3D XEN_EMULATE)
         batch_maps =3D 1;
+    if (xc_gnttab_set_max_grants(xendev->gnttabdev,
+            MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < =
0) {
+        xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",
+                      strerror(errno));
+    }
 }
=20
 static int blk_init(struct XenDevice *xendev)




--=__Part9CB23612.1__=
Content-Type: text/plain; name="qemu-xendisk-set-max-grants.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-xendisk-set-max-grants.patch"

qemu-traditional/xendisk: set maximum number of grants to be used=0A=0ALega=
cy (non-pvops) gntdev drivers may require this to be done when the=0Anumber=
 of grants intended to be used simultaneously exceeds a certain=0Adriver =
specific default limit.=0A=0AChange in v2: Double the number requested, as =
we need to account for=0Athe allocations needing to happen in contiguous =
chunks. The worst case=0Anumber would be max_req * max_seg + (max_req - 1) =
* (max_seg - 1) + 1,=0Abut in order to keep things simple just use 2 * =
max_req * max_seg.=0A=0Aupstream-commit: 64c27e5b1fdb6d94bdc0bda3b1869d7383=
a35c65=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ASigned-off-by:=
 Stefano Stabellini <stefano.stabellini@eu.citrix.com>=0A=0A--- a/hw/xen_di=
sk.c=0A+++ b/hw/xen_disk.c=0A@@ -570,6 +570,15 @@ static void blk_bh(void =
*opaque)=0A     blk_handle_requests(blkdev);=0A }=0A =0A+/*=0A+ * We need =
to account for the grant allocations requiring contiguous=0A+ * chunks; =
the worst case number would be=0A+ *     max_req * max_seg + (max_req - 1) =
* (max_seg - 1) + 1,=0A+ * but in order to keep things simple just use=0A+ =
*     2 * max_req * max_seg.=0A+ */=0A+#define MAX_GRANTS(max_req, =
max_seg) (2 * (max_req) * (max_seg))=0A+=0A static void blk_alloc(struct =
XenDevice *xendev)=0A {=0A     struct XenBlkDev *blkdev =3D container_of(xe=
ndev, struct XenBlkDev, xendev);=0A@@ -580,6 +589,11 @@ static void =
blk_alloc(struct XenDevice *=0A     blkdev->bh =3D qemu_bh_new(blk_bh, =
blkdev);=0A     if (xen_mode !=3D XEN_EMULATE)=0A         batch_maps =3D =
1;=0A+    if (xc_gnttab_set_max_grants(xendev->gnttabdev,=0A+            =
MAX_GRANTS(max_requests, BLKIF_MAX_SEGMENTS_PER_REQUEST)) < 0) {=0A+       =
 xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n",=0A+     =
                 strerror(errno));=0A+    }=0A }=0A =0A static int =
blk_init(struct XenDevice *xendev)=0A
--=__Part9CB23612.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

--=__Part9CB23612.1__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:48:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:48: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 1Sj6pw-0000OV-86; Mon, 25 Jun 2012 10:48:04 +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 1Sj6pu-0000OO-UI
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:48:03 +0000
Received: from [85.158.143.35:20129] by server-3.bemta-4.messagelabs.com id
	2D/28-05808-2E148EF4; Mon, 25 Jun 2012 10:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340621281!13228631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23686 invoked from network); 25 Jun 2012 10:48:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:48:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:48:01 +0100
Message-Id: <4FE85DFF020000780008BA95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:47:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part416FEBCF.1__="
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-traditional/xendisk: properly update stats
 in ioreq_release()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part416FEBCF.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While for the "normal" case (called from blk_send_response_all())
decrementing requests_finished is correct, doing so in the parse error
case is wrong; requests_inflight needs to be decremented instead.

upstream-commit: ed5477664369c1e9de23b0e7e8f16a418573bd2a

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>

--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -151,7 +151,7 @@ static void ioreq_finish(struct ioreq *i
     blkdev->requests_finished++;
 }
=20
-static void ioreq_release(struct ioreq *ioreq)
+static void ioreq_release(struct ioreq *ioreq, bool finish)
 {
     struct XenBlkDev *blkdev =3D ioreq->blkdev;
=20
@@ -159,7 +159,11 @@ static void ioreq_release(struct ioreq *
     memset(ioreq, 0, sizeof(*ioreq));
     ioreq->blkdev =3D blkdev;
     LIST_INSERT_HEAD(&blkdev->freelist, ioreq, list);
-    blkdev->requests_finished--;
+    if (finish) {
+        blkdev->requests_finished--;
+    } else {
+        blkdev->requests_inflight--;
+    }
 }
=20
 /*
@@ -487,7 +491,7 @@ static void blk_send_response_all(struct
     while (!LIST_EMPTY(&blkdev->finished)) {
         ioreq =3D LIST_FIRST(&blkdev->finished);
 	send_notify +=3D blk_send_response_one(ioreq);
-	ioreq_release(ioreq);
+        ioreq_release(ioreq, true);
     }
     if (send_notify)
 	xen_be_send_notify(&blkdev->xendev);
@@ -539,7 +543,7 @@ static void blk_handle_requests(struct X
         if (ioreq_parse(ioreq) !=3D 0) {
             if (blk_send_response_one(ioreq))
                 xen_be_send_notify(&blkdev->xendev);
-            ioreq_release(ioreq);
+            ioreq_release(ioreq, false);
             continue;
         }
=20




--=__Part416FEBCF.1__=
Content-Type: text/plain; name="qemu-xendisk-accounting.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-xendisk-accounting.patch"

qemu-traditional/xendisk: properly update stats in ioreq_release()=0A=0AWhi=
le for the "normal" case (called from blk_send_response_all())=0Adecrementi=
ng requests_finished is correct, doing so in the parse error=0Acase is =
wrong; requests_inflight needs to be decremented instead.=0A=0Aupstream-com=
mit: ed5477664369c1e9de23b0e7e8f16a418573bd2a=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0ASigned-off-by: Stefano Stabellini <stefano.st=
abellini@eu.citrix.com>=0AReviewed-by: Kevin Wolf <kwolf@redhat.com>=0A=0A-=
-- a/hw/xen_disk.c=0A+++ b/hw/xen_disk.c=0A@@ -151,7 +151,7 @@ static void =
ioreq_finish(struct ioreq *i=0A     blkdev->requests_finished++;=0A }=0A =
=0A-static void ioreq_release(struct ioreq *ioreq)=0A+static void =
ioreq_release(struct ioreq *ioreq, bool finish)=0A {=0A     struct =
XenBlkDev *blkdev =3D ioreq->blkdev;=0A =0A@@ -159,7 +159,11 @@ static =
void ioreq_release(struct ioreq *=0A     memset(ioreq, 0, sizeof(*ioreq));=
=0A     ioreq->blkdev =3D blkdev;=0A     LIST_INSERT_HEAD(&blkdev->freelist=
, ioreq, list);=0A-    blkdev->requests_finished--;=0A+    if (finish) =
{=0A+        blkdev->requests_finished--;=0A+    } else {=0A+        =
blkdev->requests_inflight--;=0A+    }=0A }=0A =0A /*=0A@@ -487,7 +491,7 @@ =
static void blk_send_response_all(struct=0A     while (!LIST_EMPTY(&blkdev-=
>finished)) {=0A         ioreq =3D LIST_FIRST(&blkdev->finished);=0A 	=
send_notify +=3D blk_send_response_one(ioreq);=0A-	ioreq_release(ioreq=
);=0A+        ioreq_release(ioreq, true);=0A     }=0A     if (send_notify)=
=0A 	xen_be_send_notify(&blkdev->xendev);=0A@@ -539,7 +543,7 @@ static =
void blk_handle_requests(struct X=0A         if (ioreq_parse(ioreq) !=3D =
0) {=0A             if (blk_send_response_one(ioreq))=0A                 =
xen_be_send_notify(&blkdev->xendev);=0A-            ioreq_release(ioreq);=
=0A+            ioreq_release(ioreq, false);=0A             continue;=0A   =
      }=0A =0A
--=__Part416FEBCF.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

--=__Part416FEBCF.1__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:48:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:48: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 1Sj6pw-0000OV-86; Mon, 25 Jun 2012 10:48:04 +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 1Sj6pu-0000OO-UI
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:48:03 +0000
Received: from [85.158.143.35:20129] by server-3.bemta-4.messagelabs.com id
	2D/28-05808-2E148EF4; Mon, 25 Jun 2012 10:48:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340621281!13228631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23686 invoked from network); 25 Jun 2012 10:48:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:48:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:48:01 +0100
Message-Id: <4FE85DFF020000780008BA95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:47:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part416FEBCF.1__="
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-traditional/xendisk: properly update stats
 in ioreq_release()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part416FEBCF.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While for the "normal" case (called from blk_send_response_all())
decrementing requests_finished is correct, doing so in the parse error
case is wrong; requests_inflight needs to be decremented instead.

upstream-commit: ed5477664369c1e9de23b0e7e8f16a418573bd2a

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>

--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -151,7 +151,7 @@ static void ioreq_finish(struct ioreq *i
     blkdev->requests_finished++;
 }
=20
-static void ioreq_release(struct ioreq *ioreq)
+static void ioreq_release(struct ioreq *ioreq, bool finish)
 {
     struct XenBlkDev *blkdev =3D ioreq->blkdev;
=20
@@ -159,7 +159,11 @@ static void ioreq_release(struct ioreq *
     memset(ioreq, 0, sizeof(*ioreq));
     ioreq->blkdev =3D blkdev;
     LIST_INSERT_HEAD(&blkdev->freelist, ioreq, list);
-    blkdev->requests_finished--;
+    if (finish) {
+        blkdev->requests_finished--;
+    } else {
+        blkdev->requests_inflight--;
+    }
 }
=20
 /*
@@ -487,7 +491,7 @@ static void blk_send_response_all(struct
     while (!LIST_EMPTY(&blkdev->finished)) {
         ioreq =3D LIST_FIRST(&blkdev->finished);
 	send_notify +=3D blk_send_response_one(ioreq);
-	ioreq_release(ioreq);
+        ioreq_release(ioreq, true);
     }
     if (send_notify)
 	xen_be_send_notify(&blkdev->xendev);
@@ -539,7 +543,7 @@ static void blk_handle_requests(struct X
         if (ioreq_parse(ioreq) !=3D 0) {
             if (blk_send_response_one(ioreq))
                 xen_be_send_notify(&blkdev->xendev);
-            ioreq_release(ioreq);
+            ioreq_release(ioreq, false);
             continue;
         }
=20




--=__Part416FEBCF.1__=
Content-Type: text/plain; name="qemu-xendisk-accounting.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-xendisk-accounting.patch"

qemu-traditional/xendisk: properly update stats in ioreq_release()=0A=0AWhi=
le for the "normal" case (called from blk_send_response_all())=0Adecrementi=
ng requests_finished is correct, doing so in the parse error=0Acase is =
wrong; requests_inflight needs to be decremented instead.=0A=0Aupstream-com=
mit: ed5477664369c1e9de23b0e7e8f16a418573bd2a=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0ASigned-off-by: Stefano Stabellini <stefano.st=
abellini@eu.citrix.com>=0AReviewed-by: Kevin Wolf <kwolf@redhat.com>=0A=0A-=
-- a/hw/xen_disk.c=0A+++ b/hw/xen_disk.c=0A@@ -151,7 +151,7 @@ static void =
ioreq_finish(struct ioreq *i=0A     blkdev->requests_finished++;=0A }=0A =
=0A-static void ioreq_release(struct ioreq *ioreq)=0A+static void =
ioreq_release(struct ioreq *ioreq, bool finish)=0A {=0A     struct =
XenBlkDev *blkdev =3D ioreq->blkdev;=0A =0A@@ -159,7 +159,11 @@ static =
void ioreq_release(struct ioreq *=0A     memset(ioreq, 0, sizeof(*ioreq));=
=0A     ioreq->blkdev =3D blkdev;=0A     LIST_INSERT_HEAD(&blkdev->freelist=
, ioreq, list);=0A-    blkdev->requests_finished--;=0A+    if (finish) =
{=0A+        blkdev->requests_finished--;=0A+    } else {=0A+        =
blkdev->requests_inflight--;=0A+    }=0A }=0A =0A /*=0A@@ -487,7 +491,7 @@ =
static void blk_send_response_all(struct=0A     while (!LIST_EMPTY(&blkdev-=
>finished)) {=0A         ioreq =3D LIST_FIRST(&blkdev->finished);=0A 	=
send_notify +=3D blk_send_response_one(ioreq);=0A-	ioreq_release(ioreq=
);=0A+        ioreq_release(ioreq, true);=0A     }=0A     if (send_notify)=
=0A 	xen_be_send_notify(&blkdev->xendev);=0A@@ -539,7 +543,7 @@ static =
void blk_handle_requests(struct X=0A         if (ioreq_parse(ioreq) !=3D =
0) {=0A             if (blk_send_response_one(ioreq))=0A                 =
xen_be_send_notify(&blkdev->xendev);=0A-            ioreq_release(ioreq);=
=0A+            ioreq_release(ioreq, false);=0A             continue;=0A   =
      }=0A =0A
--=__Part416FEBCF.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

--=__Part416FEBCF.1__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj6s2-0000Wp-QM; Mon, 25 Jun 2012 10:50:14 +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 1Sj6s0-0000Wh-Tp
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:50:13 +0000
Received: from [85.158.143.35:34698] by server-2.bemta-4.messagelabs.com id
	EB/08-17938-46248EF4; Mon, 25 Jun 2012 10:50:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340621410!15428632!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5036 invoked from network); 25 Jun 2012 10:50:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:50:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:50:10 +0100
Message-Id: <4FE85E80020000780008BA99@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:50:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFDD35770.1__="
Cc: Rolu <rolu@roce.org>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] qemu-traditional/passthrough: fix off-by-one in
 PCI config space register index check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFDD35770.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Register 255 (0xff) is still valid to be accessed.

Reported-by: Rolu <rolu@roce.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1538,7 +1538,7 @@ static void pt_pci_write_config(PCIDevic
 #endif
=20
     /* check offset range */
-    if (address >=3D 0xFF)
+    if (address > 0xFF)
     {
         PT_LOG_DEV(d, "Error: Failed to write register with offset =
exceeding FFh. "
             "[Offset:%02xh][Length:%d]\n", address, len);
@@ -1714,7 +1714,7 @@ static uint32_t pt_pci_read_config(PCIDe
     int ret =3D 0;
=20
     /* check offset range */
-    if (address >=3D 0xFF)
+    if (address > 0xFF)
     {
         PT_LOG_DEV(d, "Error: Failed to read register with offset =
exceeding FFh. "
             "[Offset:%02xh][Length:%d]\n", address, len);




--=__PartFDD35770.1__=
Content-Type: text/plain; name="qemu-PCI-config-space-range.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-PCI-config-space-range.patch"

qemu-traditional/passthrough: fix off-by-one in PCI config space register =
index check=0A=0ARegister 255 (0xff) is still valid to be accessed.=0A=0ARe=
ported-by: Rolu <rolu@roce.org>=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/hw/pass-through.c=0A+++ b/hw/pass-through.c=0A@@ -1538,7 =
+1538,7 @@ static void pt_pci_write_config(PCIDevic=0A #endif=0A =0A     =
/* check offset range */=0A-    if (address >=3D 0xFF)=0A+    if (address =
> 0xFF)=0A     {=0A         PT_LOG_DEV(d, "Error: Failed to write register =
with offset exceeding FFh. "=0A             "[Offset:%02xh][Length:%d]\n", =
address, len);=0A@@ -1714,7 +1714,7 @@ static uint32_t pt_pci_read_config(P=
CIDe=0A     int ret =3D 0;=0A =0A     /* check offset range */=0A-    if =
(address >=3D 0xFF)=0A+    if (address > 0xFF)=0A     {=0A         =
PT_LOG_DEV(d, "Error: Failed to read register with offset exceeding FFh. =
"=0A             "[Offset:%02xh][Length:%d]\n", address, len);=0A
--=__PartFDD35770.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

--=__PartFDD35770.1__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj6s2-0000Wp-QM; Mon, 25 Jun 2012 10:50:14 +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 1Sj6s0-0000Wh-Tp
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:50:13 +0000
Received: from [85.158.143.35:34698] by server-2.bemta-4.messagelabs.com id
	EB/08-17938-46248EF4; Mon, 25 Jun 2012 10:50:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340621410!15428632!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5036 invoked from network); 25 Jun 2012 10:50:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:50:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:50:10 +0100
Message-Id: <4FE85E80020000780008BA99@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:50:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFDD35770.1__="
Cc: Rolu <rolu@roce.org>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] qemu-traditional/passthrough: fix off-by-one in
 PCI config space register index check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFDD35770.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Register 255 (0xff) is still valid to be accessed.

Reported-by: Rolu <rolu@roce.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1538,7 +1538,7 @@ static void pt_pci_write_config(PCIDevic
 #endif
=20
     /* check offset range */
-    if (address >=3D 0xFF)
+    if (address > 0xFF)
     {
         PT_LOG_DEV(d, "Error: Failed to write register with offset =
exceeding FFh. "
             "[Offset:%02xh][Length:%d]\n", address, len);
@@ -1714,7 +1714,7 @@ static uint32_t pt_pci_read_config(PCIDe
     int ret =3D 0;
=20
     /* check offset range */
-    if (address >=3D 0xFF)
+    if (address > 0xFF)
     {
         PT_LOG_DEV(d, "Error: Failed to read register with offset =
exceeding FFh. "
             "[Offset:%02xh][Length:%d]\n", address, len);




--=__PartFDD35770.1__=
Content-Type: text/plain; name="qemu-PCI-config-space-range.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-PCI-config-space-range.patch"

qemu-traditional/passthrough: fix off-by-one in PCI config space register =
index check=0A=0ARegister 255 (0xff) is still valid to be accessed.=0A=0ARe=
ported-by: Rolu <rolu@roce.org>=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/hw/pass-through.c=0A+++ b/hw/pass-through.c=0A@@ -1538,7 =
+1538,7 @@ static void pt_pci_write_config(PCIDevic=0A #endif=0A =0A     =
/* check offset range */=0A-    if (address >=3D 0xFF)=0A+    if (address =
> 0xFF)=0A     {=0A         PT_LOG_DEV(d, "Error: Failed to write register =
with offset exceeding FFh. "=0A             "[Offset:%02xh][Length:%d]\n", =
address, len);=0A@@ -1714,7 +1714,7 @@ static uint32_t pt_pci_read_config(P=
CIDe=0A     int ret =3D 0;=0A =0A     /* check offset range */=0A-    if =
(address >=3D 0xFF)=0A+    if (address > 0xFF)=0A     {=0A         =
PT_LOG_DEV(d, "Error: Failed to read register with offset exceeding FFh. =
"=0A             "[Offset:%02xh][Length:%d]\n", address, len);=0A
--=__PartFDD35770.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

--=__PartFDD35770.1__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:53:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:53: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 1Sj6v4-0000in-Ed; Mon, 25 Jun 2012 10:53: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 1Sj6v2-0000ia-Qx
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:53:20 +0000
Received: from [85.158.143.99:8300] by server-1.bemta-4.messagelabs.com id
	83/1F-24392-02348EF4; Mon, 25 Jun 2012 10:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340621599!28924942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1885 invoked from network); 25 Jun 2012 10:53:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 10:53:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13196903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 10:52:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 11:52:54 +0100
Message-ID: <1340621572.3832.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Mon, 25 Jun 2012 11:52:52 +0100
In-Reply-To: <alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 11:17 +0100, M A Young wrote:
> It also hits the same area of code as the proposed protection against 
> problems caused by huge kernels in the guests (eg. see
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01183.html
> or http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
> and it was suggested that it might be better to use a function to do this 
> bit of the code rather than duplicating it for both kernel and ramdisk.

BTW, what is the status of that patch?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 10:53:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:53: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 1Sj6v4-0000in-Ed; Mon, 25 Jun 2012 10:53: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 1Sj6v2-0000ia-Qx
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:53:20 +0000
Received: from [85.158.143.99:8300] by server-1.bemta-4.messagelabs.com id
	83/1F-24392-02348EF4; Mon, 25 Jun 2012 10:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340621599!28924942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1885 invoked from network); 25 Jun 2012 10:53:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 10:53:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13196903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 10:52:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 11:52:54 +0100
Message-ID: <1340621572.3832.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Mon, 25 Jun 2012 11:52:52 +0100
In-Reply-To: <alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 11:17 +0100, M A Young wrote:
> It also hits the same area of code as the proposed protection against 
> problems caused by huge kernels in the guests (eg. see
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01183.html
> or http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
> and it was suggested that it might be better to use a function to do this 
> bit of the code rather than duplicating it for both kernel and ramdisk.

BTW, what is the status of that patch?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 10:54:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj6w1-0000o7-Sl; Mon, 25 Jun 2012 10:54: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 1Sj6w1-0000o0-0U
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:54:21 +0000
Received: from [85.158.143.35:27254] by server-2.bemta-4.messagelabs.com id
	FA/00-17938-C5348EF4; Mon, 25 Jun 2012 10:54:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340621657!6486734!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13916 invoked from network); 25 Jun 2012 10:54:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:54:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:54:16 +0100
Message-Id: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:54:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCBE56147.0__="
Subject: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartCBE56147.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
as the whole function domain_pause_for_debugger() is pointless to be
compiled when there's no arch support, simply introduce another HAS_*
macro, enabled only on x86.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -51,6 +51,7 @@ CFLAGS-$(perfc)         +=3D -DPERF_COUNTE
 CFLAGS-$(perfc_arrays)  +=3D -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  +=3D -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      +=3D -DHAS_ACPI
+CFLAGS-$(HAS_GDBSX)     +=3D -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) +=3D -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) +=3D -fno-omit-frame-pointer -DCONFIG_FRAME_POINTE=
R
=20
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -9,6 +9,7 @@ HAS_PASSTHROUGH :=3D y
 HAS_NS16550 :=3D y
 HAS_EHCI :=3D y
 HAS_KEXEC :=3D y
+HAS_GDBSX :=3D y
 xenoprof :=3D y
=20
 #
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
         vcpu_check_shutdown(v);
 }
=20
+#ifdef HAS_GDBSX
 void domain_pause_for_debugger(void)
 {
     struct domain *d =3D current->domain;
@@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
     if (current->arch.gdbsx_vcpu_event =3D=3D 0)
         send_global_virq(VIRQ_DEBUGGER);
 }
+#endif
=20
 /* Complete domain destroy after RCU readers are not holding old =
references. */
 static void complete_domain_destroy(struct rcu_head *head)




--=__PartCBE56147.0__=
Content-Type: text/plain; name="arm-build-no-gdbsx.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arm-build-no-gdbsx.patch"

arm: fix build after c/s 25477:e12e0b038219=0A=0AOnly x86 currently has a =
struct vcpu field arch.gdbsx_vcpu_event. But=0Aas the whole function =
domain_pause_for_debugger() is pointless to be=0Acompiled when there's no =
arch support, simply introduce another HAS_*=0Amacro, enabled only on =
x86.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/Rules.mk=0A+++ b/xen/Rules.mk=0A@@ -51,6 +51,7 @@ CFLAGS-$(perfc)    =
     +=3D -DPERF_COUNTE=0A CFLAGS-$(perfc_arrays)  +=3D -DPERF_ARRAYS=0A =
CFLAGS-$(lock_profile)  +=3D -DLOCK_PROFILE=0A CFLAGS-$(HAS_ACPI)      =
+=3D -DHAS_ACPI=0A+CFLAGS-$(HAS_GDBSX)     +=3D -DHAS_GDBSX=0A CFLAGS-$(HAS=
_PASSTHROUGH) +=3D -DHAS_PASSTHROUGH=0A CFLAGS-$(frame_pointer) +=3D =
-fno-omit-frame-pointer -DCONFIG_FRAME_POINTER=0A =0A--- a/xen/arch/x86/Rul=
es.mk=0A+++ b/xen/arch/x86/Rules.mk=0A@@ -9,6 +9,7 @@ HAS_PASSTHROUGH :=3D =
y=0A HAS_NS16550 :=3D y=0A HAS_EHCI :=3D y=0A HAS_KEXEC :=3D y=0A+HAS_GDBSX=
 :=3D y=0A xenoprof :=3D y=0A =0A #=0A--- a/xen/common/domain.c=0A+++ =
b/xen/common/domain.c=0A@@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral=
(struct v=0A         vcpu_check_shutdown(v);=0A }=0A =0A+#ifdef =
HAS_GDBSX=0A void domain_pause_for_debugger(void)=0A {=0A     struct =
domain *d =3D current->domain;=0A@@ -628,6 +629,7 @@ void domain_pause_for_=
debugger(void)=0A     if (current->arch.gdbsx_vcpu_event =3D=3D 0)=0A      =
   send_global_virq(VIRQ_DEBUGGER);=0A }=0A+#endif=0A =0A /* Complete =
domain destroy after RCU readers are not holding old references. */=0A =
static void complete_domain_destroy(struct rcu_head *head)=0A
--=__PartCBE56147.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

--=__PartCBE56147.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:54:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj6w1-0000o7-Sl; Mon, 25 Jun 2012 10:54: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 1Sj6w1-0000o0-0U
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:54:21 +0000
Received: from [85.158.143.35:27254] by server-2.bemta-4.messagelabs.com id
	FA/00-17938-C5348EF4; Mon, 25 Jun 2012 10:54:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340621657!6486734!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13916 invoked from network); 25 Jun 2012 10:54:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	25 Jun 2012 10:54:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:54:16 +0100
Message-Id: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:54:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCBE56147.0__="
Subject: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartCBE56147.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
as the whole function domain_pause_for_debugger() is pointless to be
compiled when there's no arch support, simply introduce another HAS_*
macro, enabled only on x86.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -51,6 +51,7 @@ CFLAGS-$(perfc)         +=3D -DPERF_COUNTE
 CFLAGS-$(perfc_arrays)  +=3D -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  +=3D -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      +=3D -DHAS_ACPI
+CFLAGS-$(HAS_GDBSX)     +=3D -DHAS_GDBSX
 CFLAGS-$(HAS_PASSTHROUGH) +=3D -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) +=3D -fno-omit-frame-pointer -DCONFIG_FRAME_POINTE=
R
=20
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -9,6 +9,7 @@ HAS_PASSTHROUGH :=3D y
 HAS_NS16550 :=3D y
 HAS_EHCI :=3D y
 HAS_KEXEC :=3D y
+HAS_GDBSX :=3D y
 xenoprof :=3D y
=20
 #
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
         vcpu_check_shutdown(v);
 }
=20
+#ifdef HAS_GDBSX
 void domain_pause_for_debugger(void)
 {
     struct domain *d =3D current->domain;
@@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
     if (current->arch.gdbsx_vcpu_event =3D=3D 0)
         send_global_virq(VIRQ_DEBUGGER);
 }
+#endif
=20
 /* Complete domain destroy after RCU readers are not holding old =
references. */
 static void complete_domain_destroy(struct rcu_head *head)




--=__PartCBE56147.0__=
Content-Type: text/plain; name="arm-build-no-gdbsx.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arm-build-no-gdbsx.patch"

arm: fix build after c/s 25477:e12e0b038219=0A=0AOnly x86 currently has a =
struct vcpu field arch.gdbsx_vcpu_event. But=0Aas the whole function =
domain_pause_for_debugger() is pointless to be=0Acompiled when there's no =
arch support, simply introduce another HAS_*=0Amacro, enabled only on =
x86.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/Rules.mk=0A+++ b/xen/Rules.mk=0A@@ -51,6 +51,7 @@ CFLAGS-$(perfc)    =
     +=3D -DPERF_COUNTE=0A CFLAGS-$(perfc_arrays)  +=3D -DPERF_ARRAYS=0A =
CFLAGS-$(lock_profile)  +=3D -DLOCK_PROFILE=0A CFLAGS-$(HAS_ACPI)      =
+=3D -DHAS_ACPI=0A+CFLAGS-$(HAS_GDBSX)     +=3D -DHAS_GDBSX=0A CFLAGS-$(HAS=
_PASSTHROUGH) +=3D -DHAS_PASSTHROUGH=0A CFLAGS-$(frame_pointer) +=3D =
-fno-omit-frame-pointer -DCONFIG_FRAME_POINTER=0A =0A--- a/xen/arch/x86/Rul=
es.mk=0A+++ b/xen/arch/x86/Rules.mk=0A@@ -9,6 +9,7 @@ HAS_PASSTHROUGH :=3D =
y=0A HAS_NS16550 :=3D y=0A HAS_EHCI :=3D y=0A HAS_KEXEC :=3D y=0A+HAS_GDBSX=
 :=3D y=0A xenoprof :=3D y=0A =0A #=0A--- a/xen/common/domain.c=0A+++ =
b/xen/common/domain.c=0A@@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral=
(struct v=0A         vcpu_check_shutdown(v);=0A }=0A =0A+#ifdef =
HAS_GDBSX=0A void domain_pause_for_debugger(void)=0A {=0A     struct =
domain *d =3D current->domain;=0A@@ -628,6 +629,7 @@ void domain_pause_for_=
debugger(void)=0A     if (current->arch.gdbsx_vcpu_event =3D=3D 0)=0A      =
   send_global_virq(VIRQ_DEBUGGER);=0A }=0A+#endif=0A =0A /* Complete =
domain destroy after RCU readers are not holding old references. */=0A =
static void complete_domain_destroy(struct rcu_head *head)=0A
--=__PartCBE56147.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

--=__PartCBE56147.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10: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 1Sj6zb-00012J-NP; Mon, 25 Jun 2012 10:58: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 1Sj6za-00012B-Lk
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:58:02 +0000
Received: from [85.158.139.83:23067] by server-12.bemta-5.messagelabs.com id
	46/F9-25233-93448EF4; Mon, 25 Jun 2012 10:58:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340621881!18073492!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18248 invoked from network); 25 Jun 2012 10:58:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	25 Jun 2012 10:58:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:58:00 +0100
Message-Id: <4FE86056020000780008BABB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:57:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAD830726.0__="
Subject: [Xen-devel] [PATCH] arm: fix build with gcc 4.7.x
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartAD830726.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As was already pointed out months ago (see
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00826.html),
gcc 4.7.x (imo validly) refuses to take both -mcpu=3Dcortex-a15 and
-march=3Darmv7-a due to conflicting feature sets causing amibiguity in
instruction selection. Since the former implies the latter, just use
the former (and drop the -march=3D).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili
 CFLAGS +=3D -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
=20
-CFLAGS +=3D -march=3Darmv7-a -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=
=3Dsoftfp
+CFLAGS +=3D -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=3Dsoftfp
=20
 # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen =
headers)
 check-$(gcc) =3D $(call cc-ver-check,CC,0x030400,"Xen requires at least =
gcc-3.4")




--=__PartAD830726.0__=
Content-Type: text/plain; name="arm-build-gcc47.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arm-build-gcc47.patch"

arm: fix build with gcc 4.7.x=0A=0AAs was already pointed out months ago =
(see=0Ahttp://lists.xen.org/archives/html/xen-devel/2012-02/msg00826.html),=
=0Agcc 4.7.x (imo validly) refuses to take both -mcpu=3Dcortex-a15 =
and=0A-march=3Darmv7-a due to conflicting feature sets causing amibiguity =
in=0Ainstruction selection. Since the former implies the latter, just =
use=0Athe former (and drop the -march=3D).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/arm/Rules.mk=0A+++ b/xen/arch/arm/R=
ules.mk=0A@@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili=0A =
CFLAGS +=3D -DGCC_HAS_VISIBILITY_ATTRIBUTE=0A endif=0A =0A-CFLAGS +=3D =
-march=3Darmv7-a -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=3Dsoftfp=0A+C=
FLAGS +=3D -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=3Dsoftfp=0A =0A # =
Require GCC v3.4+ (to avoid issues with alignment constraints in Xen =
headers)=0A check-$(gcc) =3D $(call cc-ver-check,CC,0x030400,"Xen requires =
at least gcc-3.4")=0A
--=__PartAD830726.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

--=__PartAD830726.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 10: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 1Sj6zb-00012J-NP; Mon, 25 Jun 2012 10:58: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 1Sj6za-00012B-Lk
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 10:58:02 +0000
Received: from [85.158.139.83:23067] by server-12.bemta-5.messagelabs.com id
	46/F9-25233-93448EF4; Mon, 25 Jun 2012 10:58:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340621881!18073492!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18248 invoked from network); 25 Jun 2012 10:58:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	25 Jun 2012 10:58:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 11:58:00 +0100
Message-Id: <4FE86056020000780008BABB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 11:57:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAD830726.0__="
Subject: [Xen-devel] [PATCH] arm: fix build with gcc 4.7.x
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartAD830726.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As was already pointed out months ago (see
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00826.html),
gcc 4.7.x (imo validly) refuses to take both -mcpu=3Dcortex-a15 and
-march=3Darmv7-a due to conflicting feature sets causing amibiguity in
instruction selection. Since the former implies the latter, just use
the former (and drop the -march=3D).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili
 CFLAGS +=3D -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
=20
-CFLAGS +=3D -march=3Darmv7-a -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=
=3Dsoftfp
+CFLAGS +=3D -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=3Dsoftfp
=20
 # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen =
headers)
 check-$(gcc) =3D $(call cc-ver-check,CC,0x030400,"Xen requires at least =
gcc-3.4")




--=__PartAD830726.0__=
Content-Type: text/plain; name="arm-build-gcc47.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arm-build-gcc47.patch"

arm: fix build with gcc 4.7.x=0A=0AAs was already pointed out months ago =
(see=0Ahttp://lists.xen.org/archives/html/xen-devel/2012-02/msg00826.html),=
=0Agcc 4.7.x (imo validly) refuses to take both -mcpu=3Dcortex-a15 =
and=0A-march=3Darmv7-a due to conflicting feature sets causing amibiguity =
in=0Ainstruction selection. Since the former implies the latter, just =
use=0Athe former (and drop the -march=3D).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/arm/Rules.mk=0A+++ b/xen/arch/arm/R=
ules.mk=0A@@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili=0A =
CFLAGS +=3D -DGCC_HAS_VISIBILITY_ATTRIBUTE=0A endif=0A =0A-CFLAGS +=3D =
-march=3Darmv7-a -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=3Dsoftfp=0A+C=
FLAGS +=3D -mcpu=3Dcortex-a15 -mfpu=3Dvfpv3 -mfloat-abi=3Dsoftfp=0A =0A # =
Require GCC v3.4+ (to avoid issues with alignment constraints in Xen =
headers)=0A check-$(gcc) =3D $(call cc-ver-check,CC,0x030400,"Xen requires =
at least gcc-3.4")=0A
--=__PartAD830726.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

--=__PartAD830726.0__=--


From xen-devel-bounces@lists.xen.org Mon Jun 25 11:05:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj76u-0001Hi-LD; Mon, 25 Jun 2012 11:05:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Sj76s-0001Hd-RE
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:05:35 +0000
Received: from [85.158.138.51:9351] by server-1.bemta-3.messagelabs.com id
	A3/D7-14648-DF548EF4; Mon, 25 Jun 2012 11:05:33 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340622333!10682288!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4130 invoked from network); 25 Jun 2012 11:05:33 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 11:05:33 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5PB5Duf009982;
	Mon, 25 Jun 2012 12:05:17 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5PB4w6b018613
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 12:04:58 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5PB4wnD008108;
	Mon, 25 Jun 2012 12:04:58 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5PB4w4R008105; Mon, 25 Jun 2012 12:04:58 +0100 (BST)
Date: Mon, 25 Jun 2012 12:04:58 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340621572.3832.13.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1206251155190.7883@algedi.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
	<1340621572.3832.13.camel@zakaz.uk.xensource.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: q5PB5Duf009982
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Mon, 25 Jun 2012, Ian Campbell wrote:

> On Mon, 2012-06-25 at 11:17 +0100, M A Young wrote:
>> It also hits the same area of code as the proposed protection against
>> problems caused by huge kernels in the guests (eg. see
>> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01183.html
>> or http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
>> and it was suggested that it might be better to use a function to do this
>> bit of the code rather than duplicating it for both kernel and ramdisk.
>
> BTW, what is the status of that patch?

I left it drift a bit, but I was starting to look again at it when I saw 
this patch, particularly as it suggested to me a different way to cause 
problems from the guest - have a huge kernel file and a missing ramdisk so 
you might get pygrub to backtrace and is a good chance the temporary 
kernel file won't get deleted.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 11:05:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj76u-0001Hi-LD; Mon, 25 Jun 2012 11:05:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Sj76s-0001Hd-RE
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:05:35 +0000
Received: from [85.158.138.51:9351] by server-1.bemta-3.messagelabs.com id
	A3/D7-14648-DF548EF4; Mon, 25 Jun 2012 11:05:33 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340622333!10682288!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4130 invoked from network); 25 Jun 2012 11:05:33 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 11:05:33 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5PB5Duf009982;
	Mon, 25 Jun 2012 12:05:17 +0100
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5PB4w6b018613
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 12:04:58 +0100
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q5PB4wnD008108;
	Mon, 25 Jun 2012 12:04:58 +0100 (BST)
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q5PB4w4R008105; Mon, 25 Jun 2012 12:04:58 +0100 (BST)
Date: Mon, 25 Jun 2012 12:04:58 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340621572.3832.13.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1206251155190.7883@algedi.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
	<1340621572.3832.13.camel@zakaz.uk.xensource.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: q5PB5Duf009982
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] pygrub: verify chosen kernel really exists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Mon, 25 Jun 2012, Ian Campbell wrote:

> On Mon, 2012-06-25 at 11:17 +0100, M A Young wrote:
>> It also hits the same area of code as the proposed protection against
>> problems caused by huge kernels in the guests (eg. see
>> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01183.html
>> or http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
>> and it was suggested that it might be better to use a function to do this
>> bit of the code rather than duplicating it for both kernel and ramdisk.
>
> BTW, what is the status of that patch?

I left it drift a bit, but I was starting to look again at it when I saw 
this patch, particularly as it suggested to me a different way to cause 
problems from the guest - have a huge kernel file and a missing ramdisk so 
you might get pygrub to backtrace and is a good chance the temporary 
kernel file won't get deleted.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 11:05:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj76y-0001Hz-0r; Mon, 25 Jun 2012 11:05: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 1Sj76w-0001Hs-IO
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:05:38 +0000
Received: from [85.158.143.35:23451] by server-3.bemta-4.messagelabs.com id
	E7/16-05808-10648EF4; Mon, 25 Jun 2012 11:05:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340622309!13232870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20810 invoked from network); 25 Jun 2012 11:05:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 11:05:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13197229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:05:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 12:05:09 +0100
Message-ID: <1340622307.3832.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Jun 2012 12:05:07 +0100
In-Reply-To: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
References: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 11:54 +0100, Jan Beulich wrote:
> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
> as the whole function domain_pause_for_debugger() is pointless to be
> compiled when there's no arch support, simply introduce another HAS_*
> macro, enabled only on x86.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_EHCI := y
>  HAS_KEXEC := y
> +HAS_GDBSX := y
>  xenoprof := y
>  
>  #
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>          vcpu_check_shutdown(v);
>  }
>  
> +#ifdef HAS_GDBSX
>  void domain_pause_for_debugger(void)
>  {
>      struct domain *d = current->domain;
> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>      if (current->arch.gdbsx_vcpu_event == 0)
>          send_global_virq(VIRQ_DEBUGGER);
>  }
> +#endif
>  
>  /* Complete domain destroy after RCU readers are not holding old references. */
>  static void complete_domain_destroy(struct rcu_head *head)
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 11:05:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sj76y-0001Hz-0r; Mon, 25 Jun 2012 11:05: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 1Sj76w-0001Hs-IO
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:05:38 +0000
Received: from [85.158.143.35:23451] by server-3.bemta-4.messagelabs.com id
	E7/16-05808-10648EF4; Mon, 25 Jun 2012 11:05:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340622309!13232870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20810 invoked from network); 25 Jun 2012 11:05:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 11:05:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13197229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:05:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 12:05:09 +0100
Message-ID: <1340622307.3832.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Jun 2012 12:05:07 +0100
In-Reply-To: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
References: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 11:54 +0100, Jan Beulich wrote:
> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
> as the whole function domain_pause_for_debugger() is pointless to be
> compiled when there's no arch support, simply introduce another HAS_*
> macro, enabled only on x86.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_EHCI := y
>  HAS_KEXEC := y
> +HAS_GDBSX := y
>  xenoprof := y
>  
>  #
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>          vcpu_check_shutdown(v);
>  }
>  
> +#ifdef HAS_GDBSX
>  void domain_pause_for_debugger(void)
>  {
>      struct domain *d = current->domain;
> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>      if (current->arch.gdbsx_vcpu_event == 0)
>          send_global_virq(VIRQ_DEBUGGER);
>  }
> +#endif
>  
>  /* Complete domain destroy after RCU readers are not holding old references. */
>  static void complete_domain_destroy(struct rcu_head *head)
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 11:19:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11: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 1Sj7KF-0001Zz-GZ; Mon, 25 Jun 2012 11:19: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 1Sj7KE-0001Zu-Pn
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:19:22 +0000
Received: from [85.158.143.35:57841] by server-2.bemta-4.messagelabs.com id
	CC/23-17938-A3948EF4; Mon, 25 Jun 2012 11:19:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340623114!6492586!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11540 invoked from network); 25 Jun 2012 11:18:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 11:18:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13197556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:18:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 12:18:34 +0100
Message-ID: <1340623112.3832.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Jun 2012 12:18:32 +0100
In-Reply-To: <4FE86056020000780008BABB@nat28.tlf.novell.com>
References: <4FE86056020000780008BABB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build with gcc 4.7.x
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 11:57 +0100, Jan Beulich wrote:
> As was already pointed out months ago (see
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00826.html),
> gcc 4.7.x (imo validly) refuses to take both -mcpu=cortex-a15 and
> -march=armv7-a due to conflicting feature sets causing amibiguity in
> instruction selection. Since the former implies the latter, just use
> the former (and drop the -march=).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili
>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>  endif
>  
> -CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
> +CFLAGS += -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
>  
>  # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
>  check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 11:19:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11: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 1Sj7KF-0001Zz-GZ; Mon, 25 Jun 2012 11:19: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 1Sj7KE-0001Zu-Pn
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:19:22 +0000
Received: from [85.158.143.35:57841] by server-2.bemta-4.messagelabs.com id
	CC/23-17938-A3948EF4; Mon, 25 Jun 2012 11:19:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340623114!6492586!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11540 invoked from network); 25 Jun 2012 11:18:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 11:18:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13197556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:18:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 12:18:34 +0100
Message-ID: <1340623112.3832.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Jun 2012 12:18:32 +0100
In-Reply-To: <4FE86056020000780008BABB@nat28.tlf.novell.com>
References: <4FE86056020000780008BABB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build with gcc 4.7.x
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 11:57 +0100, Jan Beulich wrote:
> As was already pointed out months ago (see
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00826.html),
> gcc 4.7.x (imo validly) refuses to take both -mcpu=cortex-a15 and
> -march=armv7-a due to conflicting feature sets causing amibiguity in
> instruction selection. Since the former implies the latter, just use
> the former (and drop the -march=).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -24,7 +24,7 @@ ifneq ($(call cc-option,$(CC),-fvisibili
>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>  endif
>  
> -CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
> +CFLAGS += -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp
>  
>  # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
>  check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 11:39:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11:39: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 1Sj7dT-0001md-AQ; Mon, 25 Jun 2012 11:39:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Sj7dR-0001mY-Uj
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:39:14 +0000
Received: from [85.158.143.35:37932] by server-3.bemta-4.messagelabs.com id
	3B/3B-05808-1ED48EF4; Mon, 25 Jun 2012 11:39:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340624337!13921303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17156 invoked from network); 25 Jun 2012 11:38:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 11:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13198160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:38:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 12:38:57 +0100
Date: Mon, 25 Jun 2012 12:38:31 +0100
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: <4FE83444020000780008BA00@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Rolu <rolu@roce.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 25 Jun 2012, Jan Beulich wrote:
> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >> At the same time, adding logging to the guest kernel would
> >> be nice, to see what value it actually writes (in a current
> >> kernel this would be in __write_msi_msg()).
> >>
> > 
> > Turns out that msg->data here is also 0x4300, so it seems the guest
> > kernel is producing these values. I caused it to make a stack trace
> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> > current data field and if it isn't equal to the macro it uses
> > xen_msi_compose_msg to make a new message, but that function just sets
> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> > then gets passed to __write_msi_msg and that's that. There are no
> > other writes through __write_msi_msg (except for the same thing for
> > other devices).
> > 
> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> > decoded as the delivery mode, so it seems the kernel is intentionally
> > setting it to 3.
> 
> So that can never have worked properly afaict. Stefano, the
> code as it is currently - using literal (3 << 8) - is clearly bogus.
> Your original commit at least had a comment saying that the
> reserved delivery mode encoding is intentional here, but that
> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
> In any case - the cooperation with qemu apparently doesn't
> work, as the reserved encoding should never make it through
> to the hypervisor. Could you explain what the intention here
> was?
> 
> And regardless of anything, can the literal numbers please be
> replaced by proper manifest constants - the "8" here already
> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
> proper symbolic would permit locating where this is being (or
> really, as it doesn't appear to work supposed to be) consumed
> in qemu, provided it uses the same definition (i.e. that one
> should go into one of the public headers).

The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
because notifications are not supposed to be delivered as MSI anymore.

This is what should happen:

1) Linux configures the device with a 0 vector number and the pirq number
in the address field;

2) QEMU notices a vector number of 0 and reads the pirq number from the
address field, passing it to xc_domain_update_msi_irq;

3) Xen assignes the given pirq to the physical MSI;

4) The guest issues a EVTCHNOP_bind_pirq hypercall;

5) Xen sets the pirq as "IRQ_PT";

6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
returns true so Xen calls send_guest_pirq instead.


Obviously 6) is not happening. hvm_domain_use_pirq is:

is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND

My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
above).
So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
(__startup_pirq doesn't get called), or Xen is erroring out in
map_domain_emuirq_pirq.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 11:39:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 11:39: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 1Sj7dT-0001md-AQ; Mon, 25 Jun 2012 11:39:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Sj7dR-0001mY-Uj
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 11:39:14 +0000
Received: from [85.158.143.35:37932] by server-3.bemta-4.messagelabs.com id
	3B/3B-05808-1ED48EF4; Mon, 25 Jun 2012 11:39:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340624337!13921303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17156 invoked from network); 25 Jun 2012 11:38:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 11:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13198160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:38:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 12:38:57 +0100
Date: Mon, 25 Jun 2012 12:38:31 +0100
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: <4FE83444020000780008BA00@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Rolu <rolu@roce.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 25 Jun 2012, Jan Beulich wrote:
> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >> At the same time, adding logging to the guest kernel would
> >> be nice, to see what value it actually writes (in a current
> >> kernel this would be in __write_msi_msg()).
> >>
> > 
> > Turns out that msg->data here is also 0x4300, so it seems the guest
> > kernel is producing these values. I caused it to make a stack trace
> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> > current data field and if it isn't equal to the macro it uses
> > xen_msi_compose_msg to make a new message, but that function just sets
> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> > then gets passed to __write_msi_msg and that's that. There are no
> > other writes through __write_msi_msg (except for the same thing for
> > other devices).
> > 
> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> > decoded as the delivery mode, so it seems the kernel is intentionally
> > setting it to 3.
> 
> So that can never have worked properly afaict. Stefano, the
> code as it is currently - using literal (3 << 8) - is clearly bogus.
> Your original commit at least had a comment saying that the
> reserved delivery mode encoding is intentional here, but that
> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
> In any case - the cooperation with qemu apparently doesn't
> work, as the reserved encoding should never make it through
> to the hypervisor. Could you explain what the intention here
> was?
> 
> And regardless of anything, can the literal numbers please be
> replaced by proper manifest constants - the "8" here already
> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
> proper symbolic would permit locating where this is being (or
> really, as it doesn't appear to work supposed to be) consumed
> in qemu, provided it uses the same definition (i.e. that one
> should go into one of the public headers).

The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
because notifications are not supposed to be delivered as MSI anymore.

This is what should happen:

1) Linux configures the device with a 0 vector number and the pirq number
in the address field;

2) QEMU notices a vector number of 0 and reads the pirq number from the
address field, passing it to xc_domain_update_msi_irq;

3) Xen assignes the given pirq to the physical MSI;

4) The guest issues a EVTCHNOP_bind_pirq hypercall;

5) Xen sets the pirq as "IRQ_PT";

6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
returns true so Xen calls send_guest_pirq instead.


Obviously 6) is not happening. hvm_domain_use_pirq is:

is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND

My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
above).
So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
(__startup_pirq doesn't get called), or Xen is erroring out in
map_domain_emuirq_pirq.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 14:36:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 14:36: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 1SjAOI-0003Zj-N1; Mon, 25 Jun 2012 14:35:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Kane@dornerworks.com>) id 1SjAOH-0003Zb-Bi
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 14:35:45 +0000
Received: from [85.158.143.99:19584] by server-2.bemta-4.messagelabs.com id
	99/1B-17938-E3778EF4; Mon, 25 Jun 2012 14:35:42 +0000
X-Env-Sender: Andrew.Kane@dornerworks.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340634935!23733421!1
X-Originating-IP: [12.54.255.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25075 invoked from network); 25 Jun 2012 14:35:37 -0000
Received: from unknown (HELO mail.dornerworks.com) (12.54.255.21)
	by server-4.tower-216.messagelabs.com with SMTP;
	25 Jun 2012 14:35:37 -0000
Received: from med002051.med.strykercorp.com (172.27.12.95) by Quimby.dw.local
	(172.27.1.90) with Microsoft SMTP Server (TLS) id 14.1.218.12;
	Mon, 25 Jun 2012 10:35:23 -0400
MIME-Version: 1.0 (Apple Message framework v1278)
From: Andrew Kane <Andrew.Kane@dornerworks.com>
Date: Mon, 25 Jun 2012 10:35:22 -0400
Message-ID: <7D13EF28-7B8B-43E1-A6C3-D5F9FF0C4B0A@dornerworks.com>
To: <dunlapg@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-Originating-IP: [172.27.12.95]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arinc653 scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Yes, we would like to continue supporting it in-tree. We'll look
to make sure it is still working under 4.2. Is there a timeline for the release
of 4.2?

Thank you,

		Andrew Kane
		DornerWorks, Ltd.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 14:36:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 14:36: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 1SjAOI-0003Zj-N1; Mon, 25 Jun 2012 14:35:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Kane@dornerworks.com>) id 1SjAOH-0003Zb-Bi
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 14:35:45 +0000
Received: from [85.158.143.99:19584] by server-2.bemta-4.messagelabs.com id
	99/1B-17938-E3778EF4; Mon, 25 Jun 2012 14:35:42 +0000
X-Env-Sender: Andrew.Kane@dornerworks.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340634935!23733421!1
X-Originating-IP: [12.54.255.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25075 invoked from network); 25 Jun 2012 14:35:37 -0000
Received: from unknown (HELO mail.dornerworks.com) (12.54.255.21)
	by server-4.tower-216.messagelabs.com with SMTP;
	25 Jun 2012 14:35:37 -0000
Received: from med002051.med.strykercorp.com (172.27.12.95) by Quimby.dw.local
	(172.27.1.90) with Microsoft SMTP Server (TLS) id 14.1.218.12;
	Mon, 25 Jun 2012 10:35:23 -0400
MIME-Version: 1.0 (Apple Message framework v1278)
From: Andrew Kane <Andrew.Kane@dornerworks.com>
Date: Mon, 25 Jun 2012 10:35:22 -0400
Message-ID: <7D13EF28-7B8B-43E1-A6C3-D5F9FF0C4B0A@dornerworks.com>
To: <dunlapg@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-Originating-IP: [172.27.12.95]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arinc653 scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Yes, we would like to continue supporting it in-tree. We'll look
to make sure it is still working under 4.2. Is there a timeline for the release
of 4.2?

Thank you,

		Andrew Kane
		DornerWorks, Ltd.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 14:38:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 14:38: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 1SjAQs-0003hl-SG; Mon, 25 Jun 2012 14:38:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcm@mccr.org>) id 1SjAQr-0003ha-R1
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 14:38:26 +0000
Received: from [85.158.138.51:7411] by server-6.bemta-3.messagelabs.com id
	8E/98-11602-0E778EF4; Mon, 25 Jun 2012 14:38:24 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340635103!29486114!1
X-Originating-IP: [204.13.248.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC43MiA9PiAxNTQxNDM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9026 invoked from network); 25 Jun 2012 14:38:24 -0000
Received: from mho-02-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org)
	(204.13.248.72)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 14:38:24 -0000
Received: from [67.21.176.24] (helo=magnum.localnet)
	by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from <dcm@mccr.org>)
	id 1SjAQp-0001gd-Ar; Mon, 25 Jun 2012 14:38:23 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/mailhop/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX18HK8/vi2baqWJWTArFT31QSP7nKcciv6A=
From: Dave McCracken <dcm@mccr.org>
To: Xen Developers <xen-devel@lists.xen.org>
Date: Mon, 25 Jun 2012 09:38:21 -0500
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.8.3; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201206250938.21418.dcm@mccr.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Issue with PV superpage 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


Awhile back I added the domain config flag "superpages" to support Linux 
hugepages in PV domains.  When the flag is set, the PV domain is populated 
entirely with superpages.  If not enough superpage-sized chunks can be found, 
the domain creation fails.

At some time after my patch was accepted, the code I added to domain restore 
was removed because I broke page allocation batching.  I put it on my TODO 
list to reimplement it, then it got lost, for which I apologize.

Now I have gotten back to reimplementing PV superpage support in restore, I 
find that recently other code was added to restore that, while triggered by 
the superpage flag, only allocates superpages opportunistically and falls back 
to small pages if it fails.  This breaks the original semantics of the flag 
and could cause any OS that depends on the semantics to fail catastrophically.

I have a patch that implements the original semantics of the superpage flag 
while preserving the batch allocation behavior.  I can remove the competing 
code and submit mine, but I have a question.  What value is there in 
implementing opportunistic allocation of superpages for a PV (or an HVM) 
domain in restore?  It clearly can't be based on the superpages flag.  
Opportunistic superpage allocation is already the default behavior for HVM 
domain creation.  Should it also be a default on HVM restore?  What about for 
PV domains?  Is there any real benefit?

Thanks,
Dave McCracken
Oracle Corp.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 14:38:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 14:38: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 1SjAQs-0003hl-SG; Mon, 25 Jun 2012 14:38:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcm@mccr.org>) id 1SjAQr-0003ha-R1
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 14:38:26 +0000
Received: from [85.158.138.51:7411] by server-6.bemta-3.messagelabs.com id
	8E/98-11602-0E778EF4; Mon, 25 Jun 2012 14:38:24 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340635103!29486114!1
X-Originating-IP: [204.13.248.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC43MiA9PiAxNTQxNDM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9026 invoked from network); 25 Jun 2012 14:38:24 -0000
Received: from mho-02-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org)
	(204.13.248.72)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 14:38:24 -0000
Received: from [67.21.176.24] (helo=magnum.localnet)
	by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from <dcm@mccr.org>)
	id 1SjAQp-0001gd-Ar; Mon, 25 Jun 2012 14:38:23 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/mailhop/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX18HK8/vi2baqWJWTArFT31QSP7nKcciv6A=
From: Dave McCracken <dcm@mccr.org>
To: Xen Developers <xen-devel@lists.xen.org>
Date: Mon, 25 Jun 2012 09:38:21 -0500
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.8.3; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201206250938.21418.dcm@mccr.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Issue with PV superpage 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


Awhile back I added the domain config flag "superpages" to support Linux 
hugepages in PV domains.  When the flag is set, the PV domain is populated 
entirely with superpages.  If not enough superpage-sized chunks can be found, 
the domain creation fails.

At some time after my patch was accepted, the code I added to domain restore 
was removed because I broke page allocation batching.  I put it on my TODO 
list to reimplement it, then it got lost, for which I apologize.

Now I have gotten back to reimplementing PV superpage support in restore, I 
find that recently other code was added to restore that, while triggered by 
the superpage flag, only allocates superpages opportunistically and falls back 
to small pages if it fails.  This breaks the original semantics of the flag 
and could cause any OS that depends on the semantics to fail catastrophically.

I have a patch that implements the original semantics of the superpage flag 
while preserving the batch allocation behavior.  I can remove the competing 
code and submit mine, but I have a question.  What value is there in 
implementing opportunistic allocation of superpages for a PV (or an HVM) 
domain in restore?  It clearly can't be based on the superpages flag.  
Opportunistic superpage allocation is already the default behavior for HVM 
domain creation.  Should it also be a default on HVM restore?  What about for 
PV domains?  Is there any real benefit?

Thanks,
Dave McCracken
Oracle Corp.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 14:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 14: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 1SjAZK-0004CX-T3; Mon, 25 Jun 2012 14:47: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 1SjAZK-0004CO-21
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 14:47:10 +0000
Received: from [85.158.138.51:47245] by server-7.bemta-3.messagelabs.com id
	38/DF-10113-DE978EF4; Mon, 25 Jun 2012 14:47:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340635628!29465623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1972 invoked from network); 25 Jun 2012 14:47:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 14:47:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13203410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 14:47:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 15:47:07 +0100
Message-ID: <1340635626.3832.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Kane <Andrew.Kane@dornerworks.com>
Date: Mon, 25 Jun 2012 15:47:06 +0100
In-Reply-To: <7D13EF28-7B8B-43E1-A6C3-D5F9FF0C4B0A@dornerworks.com>
References: <7D13EF28-7B8B-43E1-A6C3-D5F9FF0C4B0A@dornerworks.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "dunlapg@gmail.com" <dunlapg@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] arinc653 scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 15:35 +0100, Andrew Kane wrote:
> George: Yes, we would like to continue supporting it in-tree. We'll look
> to make sure it is still working under 4.2. Is there a timeline for the release
> of 4.2?

We are waiting for the last couple of big patchsets to drop (see the
weekly 4.2 TODO list postings on xen-devel@) before we start to cut RC
releases, I hope this will be in a few weeks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 14:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 14: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 1SjAZK-0004CX-T3; Mon, 25 Jun 2012 14:47: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 1SjAZK-0004CO-21
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 14:47:10 +0000
Received: from [85.158.138.51:47245] by server-7.bemta-3.messagelabs.com id
	38/DF-10113-DE978EF4; Mon, 25 Jun 2012 14:47:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340635628!29465623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1972 invoked from network); 25 Jun 2012 14:47:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 14:47:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13203410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 14:47:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 15:47:07 +0100
Message-ID: <1340635626.3832.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Kane <Andrew.Kane@dornerworks.com>
Date: Mon, 25 Jun 2012 15:47:06 +0100
In-Reply-To: <7D13EF28-7B8B-43E1-A6C3-D5F9FF0C4B0A@dornerworks.com>
References: <7D13EF28-7B8B-43E1-A6C3-D5F9FF0C4B0A@dornerworks.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "dunlapg@gmail.com" <dunlapg@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] arinc653 scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-06-25 at 15:35 +0100, Andrew Kane wrote:
> George: Yes, we would like to continue supporting it in-tree. We'll look
> to make sure it is still working under 4.2. Is there a timeline for the release
> of 4.2?

We are waiting for the last couple of big patchsets to drop (see the
weekly 4.2 TODO list postings on xen-devel@) before we start to cut RC
releases, I hope this will be in a few weeks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:11:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjAwA-0004aj-Q9; Mon, 25 Jun 2012 15:10:46 +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 1SjAw9-0004ac-QC
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:10:46 +0000
Received: from [85.158.143.99:26562] by server-2.bemta-4.messagelabs.com id
	47/D5-17938-57F78EF4; Mon, 25 Jun 2012 15:10:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340637042!23740817!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI5NjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21645 invoked from network); 25 Jun 2012 15:10: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;
	25 Jun 2012 15:10:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336363200"; d="scan'208";a="29315712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:10:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 11:10:42 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SjAw6-00020Z-1G;
	Mon, 25 Jun 2012 16:10:42 +0100
Message-ID: <4FE87EEB.7060507@eu.citrix.com>
Date: Mon, 25 Jun 2012 16:08:27 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Dave McCracken <dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org>
In-Reply-To: <201206250938.21418.dcm@mccr.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Developers <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with PV superpage 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 25/06/12 15:38, Dave McCracken wrote:
> Awhile back I added the domain config flag "superpages" to support Linux
> hugepages in PV domains.  When the flag is set, the PV domain is populated
> entirely with superpages.  If not enough superpage-sized chunks can be found,
> the domain creation fails.
>
> At some time after my patch was accepted, the code I added to domain restore
> was removed because I broke page allocation batching.  I put it on my TODO
> list to reimplement it, then it got lost, for which I apologize.
>
> Now I have gotten back to reimplementing PV superpage support in restore, I
> find that recently other code was added to restore that, while triggered by
> the superpage flag, only allocates superpages opportunistically and falls back
> to small pages if it fails.  This breaks the original semantics of the flag
> and could cause any OS that depends on the semantics to fail catastrophically.
>
> I have a patch that implements the original semantics of the superpage flag
> while preserving the batch allocation behavior.  I can remove the competing
> code and submit mine, but I have a question.  What value is there in
> implementing opportunistic allocation of superpages for a PV (or an HVM)
> domain in restore?  It clearly can't be based on the superpages flag.
> Opportunistic superpage allocation is already the default behavior for HVM
> domain creation.  Should it also be a default on HVM restore?  What about for
> PV domains?  Is there any real benefit?
Well the value of having superpages for HVM guests is pretty obvious.  
When using hardware assisted pagetables (HAP), the number of memory 
reads on a TLB lookup is guest_levels * p2m_level -- so on a 64-bit 
guest, the one extra level of p2m could cause up to 4 extra memory reads 
for every TLB miss.  The reason to do it opportunistically instead of 
all-or-nothing is that there's no reason not to -- every little helps. :-)

My question is, what is the value of enforcing all-or-nothing for PV 
guests?  Is it the case that PV guests have to be entirely in either one 
mode or the other?

I'm not particularly fussed about having a way to disable the 
opportunistic superpage allocation for HVM guests, and just turning that 
on all the time.  I only really used the flag because I saw it was being 
passed but wasn't being used; I didn't realize it was meant to have the 
"use superpages or abort" semantics.  My only non-negotiable is that we 
have *a way* to get opportunistic superpages for HVM guests.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:11:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjAwA-0004aj-Q9; Mon, 25 Jun 2012 15:10:46 +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 1SjAw9-0004ac-QC
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:10:46 +0000
Received: from [85.158.143.99:26562] by server-2.bemta-4.messagelabs.com id
	47/D5-17938-57F78EF4; Mon, 25 Jun 2012 15:10:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340637042!23740817!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI5NjM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21645 invoked from network); 25 Jun 2012 15:10: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;
	25 Jun 2012 15:10:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336363200"; d="scan'208";a="29315712"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 11:10:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 11:10:42 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SjAw6-00020Z-1G;
	Mon, 25 Jun 2012 16:10:42 +0100
Message-ID: <4FE87EEB.7060507@eu.citrix.com>
Date: Mon, 25 Jun 2012 16:08:27 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Dave McCracken <dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org>
In-Reply-To: <201206250938.21418.dcm@mccr.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Developers <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with PV superpage 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 25/06/12 15:38, Dave McCracken wrote:
> Awhile back I added the domain config flag "superpages" to support Linux
> hugepages in PV domains.  When the flag is set, the PV domain is populated
> entirely with superpages.  If not enough superpage-sized chunks can be found,
> the domain creation fails.
>
> At some time after my patch was accepted, the code I added to domain restore
> was removed because I broke page allocation batching.  I put it on my TODO
> list to reimplement it, then it got lost, for which I apologize.
>
> Now I have gotten back to reimplementing PV superpage support in restore, I
> find that recently other code was added to restore that, while triggered by
> the superpage flag, only allocates superpages opportunistically and falls back
> to small pages if it fails.  This breaks the original semantics of the flag
> and could cause any OS that depends on the semantics to fail catastrophically.
>
> I have a patch that implements the original semantics of the superpage flag
> while preserving the batch allocation behavior.  I can remove the competing
> code and submit mine, but I have a question.  What value is there in
> implementing opportunistic allocation of superpages for a PV (or an HVM)
> domain in restore?  It clearly can't be based on the superpages flag.
> Opportunistic superpage allocation is already the default behavior for HVM
> domain creation.  Should it also be a default on HVM restore?  What about for
> PV domains?  Is there any real benefit?
Well the value of having superpages for HVM guests is pretty obvious.  
When using hardware assisted pagetables (HAP), the number of memory 
reads on a TLB lookup is guest_levels * p2m_level -- so on a 64-bit 
guest, the one extra level of p2m could cause up to 4 extra memory reads 
for every TLB miss.  The reason to do it opportunistically instead of 
all-or-nothing is that there's no reason not to -- every little helps. :-)

My question is, what is the value of enforcing all-or-nothing for PV 
guests?  Is it the case that PV guests have to be entirely in either one 
mode or the other?

I'm not particularly fussed about having a way to disable the 
opportunistic superpage allocation for HVM guests, and just turning that 
on all the time.  I only really used the flag because I saw it was being 
passed but wasn't being used; I didn't realize it was meant to have the 
"use superpages or abort" semantics.  My only non-negotiable is that we 
have *a way* to get opportunistic superpages for HVM guests.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:35:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:35: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 1SjBJc-000691-FU; Mon, 25 Jun 2012 15:35: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 1SjBJa-00068m-CH
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:34:58 +0000
Received: from [85.158.139.83:33377] by server-7.bemta-5.messagelabs.com id
	EC/32-28276-12588EF4; Mon, 25 Jun 2012 15:34:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340638495!29394064!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwNjk5NQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5189 invoked from network); 25 Jun 2012 15:34:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 15:34:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5PFYnjD028360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Jun 2012 15:34:50 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
	q5PFYl4i014990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 15:34:48 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
	q5PFYluT026895; Mon, 25 Jun 2012 10:34:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Jun 2012 08:34:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7477140299; Mon, 25 Jun 2012 11:27:05 -0400 (EDT)
Date: Mon, 25 Jun 2012 11:27:05 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120625152705.GB4210@phenom.dumpdata.com>
References: <4FE43D1C.8020600@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE43D1C.8020600@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS
 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 Fri, Jun 22, 2012 at 10:38:36AM +0100, Andrew Cooper wrote:
> I was looking through the maintainers file and noticed that the
> xen-devel email address is out of date in certain places.

Does it work - meaning had you tried to subscribe to the new mailing list
address? Last time I did that it didn't work.


> 
> -- 
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
> 

> # HG changeset patch
> # Parent 32034d1914a607d7b6f1f060352b4cac973600f8
> MAINTAINTERS: update xen-devel email address
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 32034d1914a6 MAINTAINERS
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -102,7 +102,7 @@ M:	Ian Campbell <ian.campbell@citrix.com
>  M:	Stefano Stabellini <stefano.stabellini@citrix.com>
>  M:	Tim Deegan <tim@xen.org>
>  S:	Supported
> -L:	xen-devel@lists.xensource.com
> +L:	xen-devel@lists.xen.org
>  F:	xen/arch/arm/
>  F:	xen/include/asm-arm/
>  
> @@ -246,7 +246,7 @@ X86 ARCHITECTURE
>  M:	Keir Fraser <keir@xen.org>
>  M:	Jan Beulich <jbeulich@suse.com>
>  S:	Supported
> -L:	xen-devel@lists.xensource.com
> +L:	xen-devel@lists.xen.org
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
>  
> @@ -263,7 +263,7 @@ F:	xen/common/trace.c
>  
>  THE REST
>  M:	Keir Fraser <keir@xen.org>
> -L:	xen-devel@lists.xensource.com
> +L:	xen-devel@lists.xen.org
>  S:	Supported
>  F:	*
>  F:	*/

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 25 15:35:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:35: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 1SjBJc-000691-FU; Mon, 25 Jun 2012 15:35: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 1SjBJa-00068m-CH
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:34:58 +0000
Received: from [85.158.139.83:33377] by server-7.bemta-5.messagelabs.com id
	EC/32-28276-12588EF4; Mon, 25 Jun 2012 15:34:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340638495!29394064!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwNjk5NQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5189 invoked from network); 25 Jun 2012 15:34:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 15:34:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5PFYnjD028360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Jun 2012 15:34:50 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
	q5PFYl4i014990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 15:34:48 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
	q5PFYluT026895; Mon, 25 Jun 2012 10:34:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Jun 2012 08:34:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7477140299; Mon, 25 Jun 2012 11:27:05 -0400 (EDT)
Date: Mon, 25 Jun 2012 11:27:05 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120625152705.GB4210@phenom.dumpdata.com>
References: <4FE43D1C.8020600@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE43D1C.8020600@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS
 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 Fri, Jun 22, 2012 at 10:38:36AM +0100, Andrew Cooper wrote:
> I was looking through the maintainers file and noticed that the
> xen-devel email address is out of date in certain places.

Does it work - meaning had you tried to subscribe to the new mailing list
address? Last time I did that it didn't work.


> 
> -- 
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
> 

> # HG changeset patch
> # Parent 32034d1914a607d7b6f1f060352b4cac973600f8
> MAINTAINTERS: update xen-devel email address
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 32034d1914a6 MAINTAINERS
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -102,7 +102,7 @@ M:	Ian Campbell <ian.campbell@citrix.com
>  M:	Stefano Stabellini <stefano.stabellini@citrix.com>
>  M:	Tim Deegan <tim@xen.org>
>  S:	Supported
> -L:	xen-devel@lists.xensource.com
> +L:	xen-devel@lists.xen.org
>  F:	xen/arch/arm/
>  F:	xen/include/asm-arm/
>  
> @@ -246,7 +246,7 @@ X86 ARCHITECTURE
>  M:	Keir Fraser <keir@xen.org>
>  M:	Jan Beulich <jbeulich@suse.com>
>  S:	Supported
> -L:	xen-devel@lists.xensource.com
> +L:	xen-devel@lists.xen.org
>  F:	xen/arch/x86/
>  F:	xen/include/asm-x86/
>  
> @@ -263,7 +263,7 @@ F:	xen/common/trace.c
>  
>  THE REST
>  M:	Keir Fraser <keir@xen.org>
> -L:	xen-devel@lists.xensource.com
> +L:	xen-devel@lists.xen.org
>  S:	Supported
>  F:	*
>  F:	*/

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 25 15:42:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:42: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 1SjBQu-0006aW-NS; Mon, 25 Jun 2012 15:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjBQt-0006aR-Mv
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:42:31 +0000
Received: from [85.158.143.99:26426] by server-1.bemta-4.messagelabs.com id
	0D/D8-24392-6E688EF4; Mon, 25 Jun 2012 15:42:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340638950!23776885!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1343 invoked from network); 25 Jun 2012 15:42:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 15:42:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13204748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 15:42:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 16:42:29 +0100
Message-ID: <1340638948.3832.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Jun 2012 16:42:28 +0100
In-Reply-To: <20120625152705.GB4210@phenom.dumpdata.com>
References: <4FE43D1C.8020600@citrix.com>
	<20120625152705.GB4210@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS
 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, 2012-06-25 at 16:27 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 22, 2012 at 10:38:36AM +0100, Andrew Cooper wrote:
> > I was looking through the maintainers file and noticed that the
> > xen-devel email address is out of date in certain places.
> 
> Does it work - meaning had you tried to subscribe to the new mailing list
> address? Last time I did that it didn't work.

Looks at the Cc: line -- you are receiving this thread through the new
name!

http://lists.xen.org/mailman/listinfo/xen-devel now refers to the new
name as well. I forget when this all changed over.

The original patch is:

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:42:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:42: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 1SjBQu-0006aW-NS; Mon, 25 Jun 2012 15:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjBQt-0006aR-Mv
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:42:31 +0000
Received: from [85.158.143.99:26426] by server-1.bemta-4.messagelabs.com id
	0D/D8-24392-6E688EF4; Mon, 25 Jun 2012 15:42:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340638950!23776885!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1343 invoked from network); 25 Jun 2012 15:42:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 15:42:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="13204748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 15:42:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 25 Jun 2012 16:42:29 +0100
Message-ID: <1340638948.3832.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Jun 2012 16:42:28 +0100
In-Reply-To: <20120625152705.GB4210@phenom.dumpdata.com>
References: <4FE43D1C.8020600@citrix.com>
	<20120625152705.GB4210@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS
 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, 2012-06-25 at 16:27 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 22, 2012 at 10:38:36AM +0100, Andrew Cooper wrote:
> > I was looking through the maintainers file and noticed that the
> > xen-devel email address is out of date in certain places.
> 
> Does it work - meaning had you tried to subscribe to the new mailing list
> address? Last time I did that it didn't work.

Looks at the Cc: line -- you are receiving this thread through the new
name!

http://lists.xen.org/mailman/listinfo/xen-devel now refers to the new
name as well. I forget when this all changed over.

The original patch is:

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:47:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 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 1SjBVY-0006l7-EK; Mon, 25 Jun 2012 15:47: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 1SjBVX-0006l0-3R
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:47:19 +0000
Received: from [85.158.138.51:8716] by server-6.bemta-3.messagelabs.com id
	D8/C4-11602-60888EF4; Mon, 25 Jun 2012 15:47:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340639237!29328038!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22356 invoked from network); 25 Jun 2012 15:47:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with SMTP;
	25 Jun 2012 15:47:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 16:47:16 +0100
Message-Id: <4FE8A450020000780008BBD1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 16:48:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>,
	"Dave McCracken" <dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
In-Reply-To: <4FE87EEB.7060507@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Developers <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with PV superpage 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 25.06.12 at 17:08, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 25/06/12 15:38, Dave McCracken wrote:
>> Awhile back I added the domain config flag "superpages" to support Linux
>> hugepages in PV domains.  When the flag is set, the PV domain is populated
>> entirely with superpages.  If not enough superpage-sized chunks can be found,
>> the domain creation fails.
>>
>> At some time after my patch was accepted, the code I added to domain restore
>> was removed because I broke page allocation batching.  I put it on my TODO
>> list to reimplement it, then it got lost, for which I apologize.
>>
>> Now I have gotten back to reimplementing PV superpage support in restore, I
>> find that recently other code was added to restore that, while triggered by
>> the superpage flag, only allocates superpages opportunistically and falls 
> back
>> to small pages if it fails.  This breaks the original semantics of the flag
>> and could cause any OS that depends on the semantics to fail 
> catastrophically.
>>
>> I have a patch that implements the original semantics of the superpage flag
>> while preserving the batch allocation behavior.  I can remove the competing
>> code and submit mine, but I have a question.  What value is there in
>> implementing opportunistic allocation of superpages for a PV (or an HVM)
>> domain in restore?  It clearly can't be based on the superpages flag.
>> Opportunistic superpage allocation is already the default behavior for HVM
>> domain creation.  Should it also be a default on HVM restore?  What about 
> for
>> PV domains?  Is there any real benefit?
> Well the value of having superpages for HVM guests is pretty obvious.  
> When using hardware assisted pagetables (HAP), the number of memory 
> reads on a TLB lookup is guest_levels * p2m_level -- so on a 64-bit 
> guest, the one extra level of p2m could cause up to 4 extra memory reads 
> for every TLB miss.  The reason to do it opportunistically instead of 
> all-or-nothing is that there's no reason not to -- every little helps. :-)
> 
> My question is, what is the value of enforcing all-or-nothing for PV 
> guests?  Is it the case that PV guests have to be entirely in either one 
> mode or the other?

Since I understand a PV guest's balloon driver must play with
this, I indeed think this is a strictly separated set.

> I'm not particularly fussed about having a way to disable the 
> opportunistic superpage allocation for HVM guests, and just turning that 
> on all the time.  I only really used the flag because I saw it was being 
> passed but wasn't being used; I didn't realize it was meant to have the 
> "use superpages or abort" semantics.  My only non-negotiable is that we 
> have *a way* to get opportunistic superpages for HVM guests.

Couldn't we have the setting be an override for the HVM
allocation behavior (defaulting to enabled there), and have
the originally intended meaning for PV (disabled by default)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:47:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 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 1SjBVY-0006l7-EK; Mon, 25 Jun 2012 15:47: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 1SjBVX-0006l0-3R
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:47:19 +0000
Received: from [85.158.138.51:8716] by server-6.bemta-3.messagelabs.com id
	D8/C4-11602-60888EF4; Mon, 25 Jun 2012 15:47:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340639237!29328038!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ3MzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22356 invoked from network); 25 Jun 2012 15:47:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with SMTP;
	25 Jun 2012 15:47:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Jun 2012 16:47:16 +0100
Message-Id: <4FE8A450020000780008BBD1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 25 Jun 2012 16:48:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>,
	"Dave McCracken" <dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
In-Reply-To: <4FE87EEB.7060507@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Developers <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with PV superpage 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 25.06.12 at 17:08, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 25/06/12 15:38, Dave McCracken wrote:
>> Awhile back I added the domain config flag "superpages" to support Linux
>> hugepages in PV domains.  When the flag is set, the PV domain is populated
>> entirely with superpages.  If not enough superpage-sized chunks can be found,
>> the domain creation fails.
>>
>> At some time after my patch was accepted, the code I added to domain restore
>> was removed because I broke page allocation batching.  I put it on my TODO
>> list to reimplement it, then it got lost, for which I apologize.
>>
>> Now I have gotten back to reimplementing PV superpage support in restore, I
>> find that recently other code was added to restore that, while triggered by
>> the superpage flag, only allocates superpages opportunistically and falls 
> back
>> to small pages if it fails.  This breaks the original semantics of the flag
>> and could cause any OS that depends on the semantics to fail 
> catastrophically.
>>
>> I have a patch that implements the original semantics of the superpage flag
>> while preserving the batch allocation behavior.  I can remove the competing
>> code and submit mine, but I have a question.  What value is there in
>> implementing opportunistic allocation of superpages for a PV (or an HVM)
>> domain in restore?  It clearly can't be based on the superpages flag.
>> Opportunistic superpage allocation is already the default behavior for HVM
>> domain creation.  Should it also be a default on HVM restore?  What about 
> for
>> PV domains?  Is there any real benefit?
> Well the value of having superpages for HVM guests is pretty obvious.  
> When using hardware assisted pagetables (HAP), the number of memory 
> reads on a TLB lookup is guest_levels * p2m_level -- so on a 64-bit 
> guest, the one extra level of p2m could cause up to 4 extra memory reads 
> for every TLB miss.  The reason to do it opportunistically instead of 
> all-or-nothing is that there's no reason not to -- every little helps. :-)
> 
> My question is, what is the value of enforcing all-or-nothing for PV 
> guests?  Is it the case that PV guests have to be entirely in either one 
> mode or the other?

Since I understand a PV guest's balloon driver must play with
this, I indeed think this is a strictly separated set.

> I'm not particularly fussed about having a way to disable the 
> opportunistic superpage allocation for HVM guests, and just turning that 
> on all the time.  I only really used the flag because I saw it was being 
> passed but wasn't being used; I didn't realize it was meant to have the 
> "use superpages or abort" semantics.  My only non-negotiable is that we 
> have *a way* to get opportunistic superpages for HVM guests.

Couldn't we have the setting be an override for the HVM
allocation behavior (defaulting to enabled there), and have
the originally intended meaning for PV (disabled by default)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:48:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:48: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 1SjBVw-0006mx-R0; Mon, 25 Jun 2012 15:47:44 +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 1SjBVv-0006mj-76
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:47:43 +0000
Received: from [85.158.143.99:49595] by server-1.bemta-4.messagelabs.com id
	33/EF-24392-E1888EF4; Mon, 25 Jun 2012 15:47:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340639259!29046792!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwNjk5NQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31093 invoked from network); 25 Jun 2012 15:47:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 15:47:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5PFlYiY010339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Jun 2012 15:47:35 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
	q5PFlXIL012289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 15:47: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
	q5PFlWVa004353; Mon, 25 Jun 2012 10:47:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Jun 2012 08:47:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2C67740299; Mon, 25 Jun 2012 11:39:49 -0400 (EDT)
Date: Mon, 25 Jun 2012 11:39:49 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120625153949.GD4210@phenom.dumpdata.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE46ABE.9010104@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions (was: Re:
 Strange kernel BUG() on PV DomU 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 Fri, Jun 22, 2012 at 02:53:18PM +0200, Joanna Rutkowska wrote:
> On 06/22/12 14:38, Jan Beulich wrote:
> >> Ok, it seems like this was an out-of-memeory condition indeed, because
> >> > once I did:
> >> > 
> >> > xl mem-set 0 1800m
> >> > 
> >> > and then quickly started a VM, it booted fine...
> > Had you looked at the error value in %rax, you would also
> > have seen that it's -ENOMEM. I suppose the problem here is
> > that a multi-page allocation was needed, yet only single
> > pages were available.
> > 
> 
> Ah, right, good point.
> 
> >> > Is there any proposal of how to handle out of memory conditions in Xen
> >> > (like this one, as well as e.g. SWIOTLB problem) in a more user friendly
> >> > way?
> > In 4.2, I hope we managed to remove all runtime allocations
> > larger than a page, so the particular situation here should arise
> > anymore.
> > 
> > As to more user-friendly - what do you think of? An error is an
> > error (and converting this to a meaningful, user visible message
> > is the responsibility of the entity receiving the error). In the
> > case at hand, printing an error message wouldn't meaningfully
> > increase user-friendliness imo.
> > 
> 
> How would you suggest to let the user (in an interactive desktop system,
> such as Qubes) know why his or her VM doesn't start? Certainly, some
> savvy user might just analyze the guest's dmesg log but that's really
> not a user friendly solution. And yet the out of memory errors are
> something that might happen quite often and are not really "exception"
> or "errors" in the same sense as e.g. traditional BUG() conditions that
> suggest something really bad happened. The problem here is that this bug
> occurs after the domain has been built, and is now running, so xl start
> is not a good place to return the error. Same with SWIOTLB out of memory
> errors, that again just prevent the domain from starting. Any other
> ideas how to handle such situations more gracefully?

Right now SWIOTLB retries with smaller sizes..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 15:48:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 15:48: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 1SjBVw-0006mx-R0; Mon, 25 Jun 2012 15:47:44 +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 1SjBVv-0006mj-76
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 15:47:43 +0000
Received: from [85.158.143.99:49595] by server-1.bemta-4.messagelabs.com id
	33/EF-24392-E1888EF4; Mon, 25 Jun 2012 15:47:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340639259!29046792!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwNjk5NQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31093 invoked from network); 25 Jun 2012 15:47:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 15:47:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5PFlYiY010339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Jun 2012 15:47:35 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
	q5PFlXIL012289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 15:47: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
	q5PFlWVa004353; Mon, 25 Jun 2012 10:47:32 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Jun 2012 08:47:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2C67740299; Mon, 25 Jun 2012 11:39:49 -0400 (EDT)
Date: Mon, 25 Jun 2012 11:39:49 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120625153949.GD4210@phenom.dumpdata.com>
References: <4FE46366.8010104@invisiblethingslab.com>
	<4FE46486.8020502@invisiblethingslab.com>
	<4FE4835D020000780008B6B3@nat28.tlf.novell.com>
	<4FE46ABE.9010104@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE46ABE.9010104@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Handling of out of memory conditions (was: Re:
 Strange kernel BUG() on PV DomU 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 Fri, Jun 22, 2012 at 02:53:18PM +0200, Joanna Rutkowska wrote:
> On 06/22/12 14:38, Jan Beulich wrote:
> >> Ok, it seems like this was an out-of-memeory condition indeed, because
> >> > once I did:
> >> > 
> >> > xl mem-set 0 1800m
> >> > 
> >> > and then quickly started a VM, it booted fine...
> > Had you looked at the error value in %rax, you would also
> > have seen that it's -ENOMEM. I suppose the problem here is
> > that a multi-page allocation was needed, yet only single
> > pages were available.
> > 
> 
> Ah, right, good point.
> 
> >> > Is there any proposal of how to handle out of memory conditions in Xen
> >> > (like this one, as well as e.g. SWIOTLB problem) in a more user friendly
> >> > way?
> > In 4.2, I hope we managed to remove all runtime allocations
> > larger than a page, so the particular situation here should arise
> > anymore.
> > 
> > As to more user-friendly - what do you think of? An error is an
> > error (and converting this to a meaningful, user visible message
> > is the responsibility of the entity receiving the error). In the
> > case at hand, printing an error message wouldn't meaningfully
> > increase user-friendliness imo.
> > 
> 
> How would you suggest to let the user (in an interactive desktop system,
> such as Qubes) know why his or her VM doesn't start? Certainly, some
> savvy user might just analyze the guest's dmesg log but that's really
> not a user friendly solution. And yet the out of memory errors are
> something that might happen quite often and are not really "exception"
> or "errors" in the same sense as e.g. traditional BUG() conditions that
> suggest something really bad happened. The problem here is that this bug
> occurs after the domain has been built, and is now running, so xl start
> is not a good place to return the error. Same with SWIOTLB out of memory
> errors, that again just prevent the domain from starting. Any other
> ideas how to handle such situations more gracefully?

Right now SWIOTLB retries with smaller sizes..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 16:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 16:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjBpM-0007bG-Re; Mon, 25 Jun 2012 16:07:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcm@mccr.org>) id 1SjBpL-0007b8-R2
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 16:07:48 +0000
Received: from [85.158.143.99:39216] by server-1.bemta-4.messagelabs.com id
	08/EF-24392-3DC88EF4; Mon, 25 Jun 2012 16:07:47 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340640466!21998413!1
X-Originating-IP: [204.13.248.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC43MiA9PiAxNTQxNDM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5454 invoked from network); 25 Jun 2012 16:07:46 -0000
Received: from mho-02-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org)
	(204.13.248.72)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 16:07:46 -0000
Received: from [67.21.176.24] (helo=magnum.localnet)
	by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from <dcm@mccr.org>)
	id 1SjBpJ-000735-Oh; Mon, 25 Jun 2012 16:07:45 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/mailhop/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX1/i62hkWGY4Ur4zkyfFcyBtoDIL7pItdCw=
From: Dave McCracken <dcm@mccr.org>
To: xen-devel@lists.xen.org, "Jan Beulich" <JBeulich@suse.com>,
	"George Dunlap" <george.dunlap@eu.citrix.com>
Date: Mon, 25 Jun 2012 11:07:43 -0500
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.8.3; x86_64; ; )
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
	<4FE8A450020000780008BBD1@nat28.tlf.novell.com>
In-Reply-To: <4FE8A450020000780008BBD1@nat28.tlf.novell.com>
MIME-Version: 1.0
Message-Id: <201206251107.44096.dcm@mccr.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Issue with PV superpage 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 Monday, June 25, 2012, Jan Beulich wrote:
> > My question is, what is the value of enforcing all-or-nothing for PV 
> > guests?  Is it the case that PV guests have to be entirely in either one 
> > mode or the other?
> 
> Since I understand a PV guest's balloon driver must play with
> this, I indeed think this is a strictly separated set.

I specifically need to be able to guarantee superpage-backed memory in PV 
guests to be able to map them as superpages (hugepages in Linux).  I'm trying 
to come up with some benefit for opportunistic superpages in PV guests, but 
nothing comes to mind.

> > I'm not particularly fussed about having a way to disable the 
> > opportunistic superpage allocation for HVM guests, and just turning that 
> > on all the time.  I only really used the flag because I saw it was being 
> > passed but wasn't being used; I didn't realize it was meant to have the 
> > "use superpages or abort" semantics.  My only non-negotiable is that we 
> > have a way to get opportunistic superpages for HVM guests.
> 
> Couldn't we have the setting be an override for the HVM
> allocation behavior (defaulting to enabled there), and have
> the originally intended meaning for PV (disabled by default)?

I like this idea.  It would be simple enough.

Is there any reason to allow disabling HVM superpage allocation?  HVM domain 
creation always allocates as many superpages as it can, then falls back to 
small pages for the rest.  Wouldn't it be reasonable to make restore always do 
this too?

Dave McCracken
Oracle Corp.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 16:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 16:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjBpM-0007bG-Re; Mon, 25 Jun 2012 16:07:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcm@mccr.org>) id 1SjBpL-0007b8-R2
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 16:07:48 +0000
Received: from [85.158.143.99:39216] by server-1.bemta-4.messagelabs.com id
	08/EF-24392-3DC88EF4; Mon, 25 Jun 2012 16:07:47 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340640466!21998413!1
X-Originating-IP: [204.13.248.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC43MiA9PiAxNTQxNDM=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5454 invoked from network); 25 Jun 2012 16:07:46 -0000
Received: from mho-02-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org)
	(204.13.248.72)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jun 2012 16:07:46 -0000
Received: from [67.21.176.24] (helo=magnum.localnet)
	by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from <dcm@mccr.org>)
	id 1SjBpJ-000735-Oh; Mon, 25 Jun 2012 16:07:45 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/mailhop/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX1/i62hkWGY4Ur4zkyfFcyBtoDIL7pItdCw=
From: Dave McCracken <dcm@mccr.org>
To: xen-devel@lists.xen.org, "Jan Beulich" <JBeulich@suse.com>,
	"George Dunlap" <george.dunlap@eu.citrix.com>
Date: Mon, 25 Jun 2012 11:07:43 -0500
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.8.3; x86_64; ; )
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
	<4FE8A450020000780008BBD1@nat28.tlf.novell.com>
In-Reply-To: <4FE8A450020000780008BBD1@nat28.tlf.novell.com>
MIME-Version: 1.0
Message-Id: <201206251107.44096.dcm@mccr.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Issue with PV superpage 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 Monday, June 25, 2012, Jan Beulich wrote:
> > My question is, what is the value of enforcing all-or-nothing for PV 
> > guests?  Is it the case that PV guests have to be entirely in either one 
> > mode or the other?
> 
> Since I understand a PV guest's balloon driver must play with
> this, I indeed think this is a strictly separated set.

I specifically need to be able to guarantee superpage-backed memory in PV 
guests to be able to map them as superpages (hugepages in Linux).  I'm trying 
to come up with some benefit for opportunistic superpages in PV guests, but 
nothing comes to mind.

> > I'm not particularly fussed about having a way to disable the 
> > opportunistic superpage allocation for HVM guests, and just turning that 
> > on all the time.  I only really used the flag because I saw it was being 
> > passed but wasn't being used; I didn't realize it was meant to have the 
> > "use superpages or abort" semantics.  My only non-negotiable is that we 
> > have a way to get opportunistic superpages for HVM guests.
> 
> Couldn't we have the setting be an override for the HVM
> allocation behavior (defaulting to enabled there), and have
> the originally intended meaning for PV (disabled by default)?

I like this idea.  It would be simple enough.

Is there any reason to allow disabling HVM superpage allocation?  HVM domain 
creation always allocates as many superpages as it can, then falls back to 
small pages for the rest.  Wouldn't it be reasonable to make restore always do 
this too?

Dave McCracken
Oracle Corp.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 16:57:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 16: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 1SjCay-0007xc-TY; Mon, 25 Jun 2012 16:57: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 1SjCax-0007xX-Df
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 16:56:59 +0000
Received: from [85.158.139.83:17389] by server-1.bemta-5.messagelabs.com id
	0D/FC-19721-A5898EF4; Mon, 25 Jun 2012 16:56:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340643417!29445459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14273 invoked from network); 25 Jun 2012 16:56:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 16:56:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,473,1336348800"; d="scan'208";a="13206336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 16:56:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 17:56:56 +0100
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 1SjCau-0000J0-Ja;
	Mon, 25 Jun 2012 16:56:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjCau-0006jg-4U;
	Mon, 25 Jun 2012 17:56:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13367-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 17:56:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13367: 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 13367 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13367/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13365

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  8c70ad9fd221
baseline version:
 xen                  836db8c4b9f9

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=8c70ad9fd221
+ . 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 8c70ad9fd221
+ branch=xen-unstable
+ revision=8c70ad9fd221
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 8c70ad9fd221 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 16:57:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 16: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 1SjCay-0007xc-TY; Mon, 25 Jun 2012 16:57: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 1SjCax-0007xX-Df
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 16:56:59 +0000
Received: from [85.158.139.83:17389] by server-1.bemta-5.messagelabs.com id
	0D/FC-19721-A5898EF4; Mon, 25 Jun 2012 16:56:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340643417!29445459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14273 invoked from network); 25 Jun 2012 16:56:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 16:56:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,473,1336348800"; d="scan'208";a="13206336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 16:56:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 17:56:56 +0100
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 1SjCau-0000J0-Ja;
	Mon, 25 Jun 2012 16:56:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjCau-0006jg-4U;
	Mon, 25 Jun 2012 17:56:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13367-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 17:56:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13367: 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 13367 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13367/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13365

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  8c70ad9fd221
baseline version:
 xen                  836db8c4b9f9

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=8c70ad9fd221
+ . 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 8c70ad9fd221
+ branch=xen-unstable
+ revision=8c70ad9fd221
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 8c70ad9fd221 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 17:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 17: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 1SjCks-0008Ia-Ks; Mon, 25 Jun 2012 17:07:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SjCkq-0008IP-Rb
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 17:07:13 +0000
Received: from [85.158.143.35:23667] by server-2.bemta-4.messagelabs.com id
	54/0E-17938-0CA98EF4; Mon, 25 Jun 2012 17:07:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340644029!17987387!1
X-Originating-IP: [209.85.216.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18464 invoked from network); 25 Jun 2012 17:07:10 -0000
Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com)
	(209.85.216.179)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 17:07:10 -0000
Received: by qcse14 with SMTP id e14so2376808qcs.38
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 10:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=QAy21NWeQ6hQysrylI9/iQvgul50msioLvjcsQhsdYY=;
	b=KKeXh/E2DtwJVG8kn9Tvk1wN0CLBr6U7N2p0NkK7Z79/8fzRHpJ+6qkFqLHE5ng8HY
	hHenbXE74+m5KArYTtkoZ4+FjcALvPTSxX81jtQ6nCRzb1IAbfaui2aYwt//pbbFPW+H
	tFuUpMY39xj9Lv1inwvPPuxc2P+IPaUFc0MQQpjaiKUbSpaWSJuucAHAV+LRezxRAkfz
	YOOxbvyk2PujpN3GLKmDkzrjDcDgzroYxwS5BsDsG/CGGUmMrcOp8TK8XkFqM3qJC/zQ
	suXJ7q9tvqbcueb2IPX26gFzZ3tQeyeM3aF4TQ9T5TJ7WrDaCHvmWbIQf6bd+qctb4nV
	CwkQ==
MIME-Version: 1.0
Received: by 10.224.188.140 with SMTP id da12mr21479282qab.42.1340644028686;
	Mon, 25 Jun 2012 10:07:08 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Mon, 25 Jun 2012 10:07:08 -0700 (PDT)
In-Reply-To: <201206251107.44096.dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
	<4FE8A450020000780008BBD1@nat28.tlf.novell.com>
	<201206251107.44096.dcm@mccr.org>
Date: Mon, 25 Jun 2012 18:07:08 +0100
X-Google-Sender-Auth: Jv9jKAUfUehmJVyvD3haNx_yBPA
Message-ID: <CAFLBxZapX5G8SwcotUx5=weg0FAiFRJDOFoFA0YNB5P11v3vRg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dave McCracken <dcm@mccr.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with PV superpage 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="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, Jun 25, 2012 at 5:07 PM, Dave McCracken <dcm@mccr.org> wrote:
>> Couldn't we have the setting be an override for the HVM
>> allocation behavior (defaulting to enabled there), and have
>> the originally intended meaning for PV (disabled by default)?
>
> I like this idea. =A0It would be simple enough.
>
> Is there any reason to allow disabling HVM superpage allocation? =A0HVM d=
omain
> creation always allocates as many superpages as it can, then falls back to
> small pages for the rest. =A0Wouldn't it be reasonable to make restore al=
ways do
> this too?

At this point, probably not.  Every toolstack that I know of (xend,
xl, xapi) always set it to '1' for HVM guests.

Is there any reason not to just have the "superpage" flag mean "try to
use superpages", and then have the allocation routine fail if
superpages && pv=3D=3Dtrue?  It seems like that might be the simplest
option.

Alternately, we could change the argument to "pv_superpages" or
something, and ignore it for HVM guests (always trying to allocate
superpages if available).  But I'm not sure that really buys us
anything.  The only trick would be trying to help people in the future
to not make the same mistake I did in interpreting what the
"superpages" flag means.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 17:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 17: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 1SjCks-0008Ia-Ks; Mon, 25 Jun 2012 17:07:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SjCkq-0008IP-Rb
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 17:07:13 +0000
Received: from [85.158.143.35:23667] by server-2.bemta-4.messagelabs.com id
	54/0E-17938-0CA98EF4; Mon, 25 Jun 2012 17:07:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340644029!17987387!1
X-Originating-IP: [209.85.216.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18464 invoked from network); 25 Jun 2012 17:07:10 -0000
Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com)
	(209.85.216.179)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 17:07:10 -0000
Received: by qcse14 with SMTP id e14so2376808qcs.38
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 10:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=QAy21NWeQ6hQysrylI9/iQvgul50msioLvjcsQhsdYY=;
	b=KKeXh/E2DtwJVG8kn9Tvk1wN0CLBr6U7N2p0NkK7Z79/8fzRHpJ+6qkFqLHE5ng8HY
	hHenbXE74+m5KArYTtkoZ4+FjcALvPTSxX81jtQ6nCRzb1IAbfaui2aYwt//pbbFPW+H
	tFuUpMY39xj9Lv1inwvPPuxc2P+IPaUFc0MQQpjaiKUbSpaWSJuucAHAV+LRezxRAkfz
	YOOxbvyk2PujpN3GLKmDkzrjDcDgzroYxwS5BsDsG/CGGUmMrcOp8TK8XkFqM3qJC/zQ
	suXJ7q9tvqbcueb2IPX26gFzZ3tQeyeM3aF4TQ9T5TJ7WrDaCHvmWbIQf6bd+qctb4nV
	CwkQ==
MIME-Version: 1.0
Received: by 10.224.188.140 with SMTP id da12mr21479282qab.42.1340644028686;
	Mon, 25 Jun 2012 10:07:08 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Mon, 25 Jun 2012 10:07:08 -0700 (PDT)
In-Reply-To: <201206251107.44096.dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
	<4FE8A450020000780008BBD1@nat28.tlf.novell.com>
	<201206251107.44096.dcm@mccr.org>
Date: Mon, 25 Jun 2012 18:07:08 +0100
X-Google-Sender-Auth: Jv9jKAUfUehmJVyvD3haNx_yBPA
Message-ID: <CAFLBxZapX5G8SwcotUx5=weg0FAiFRJDOFoFA0YNB5P11v3vRg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dave McCracken <dcm@mccr.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with PV superpage 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="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, Jun 25, 2012 at 5:07 PM, Dave McCracken <dcm@mccr.org> wrote:
>> Couldn't we have the setting be an override for the HVM
>> allocation behavior (defaulting to enabled there), and have
>> the originally intended meaning for PV (disabled by default)?
>
> I like this idea. =A0It would be simple enough.
>
> Is there any reason to allow disabling HVM superpage allocation? =A0HVM d=
omain
> creation always allocates as many superpages as it can, then falls back to
> small pages for the rest. =A0Wouldn't it be reasonable to make restore al=
ways do
> this too?

At this point, probably not.  Every toolstack that I know of (xend,
xl, xapi) always set it to '1' for HVM guests.

Is there any reason not to just have the "superpage" flag mean "try to
use superpages", and then have the allocation routine fail if
superpages && pv=3D=3Dtrue?  It seems like that might be the simplest
option.

Alternately, we could change the argument to "pv_superpages" or
something, and ignore it for HVM guests (always trying to allocate
superpages if available).  But I'm not sure that really buys us
anything.  The only trick would be trying to help people in the future
to not make the same mistake I did in interpreting what the
"superpages" flag means.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjCvL-0000B5-QD; Mon, 25 Jun 2012 17:18:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <okhalid.cern@gmail.com>) id 1SjCvJ-0000Ar-J7
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 17:18:01 +0000
Received: from [85.158.138.51:64558] by server-10.bemta-3.messagelabs.com id
	FD/3E-01753-84D98EF4; Mon, 25 Jun 2012 17:18:00 +0000
X-Env-Sender: okhalid.cern@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340644678!21353095!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4478 invoked from network); 25 Jun 2012 17:17:59 -0000
Received: from mail-gh0-f171.google.com (HELO mail-gh0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 17:17:59 -0000
Received: by ghy10 with SMTP id 10so4194197ghy.30
	for <multiple recipients>; Mon, 25 Jun 2012 10:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:date:message-id:subject:from:to:content-type;
	bh=+7/KZf8V/LzsHDwpWTNFcK6defDvedqKZQCYA/tUVyI=;
	b=wZATBB2D6XIvvLlWuehVvOpvj3xxRgboi6ZajVhNjdzN0NFqgalCsSpHGglCQynF4i
	WMUJhgZ6rtXWDAy4pOu/h4JJQH1trQSN/Ar0ztLYuBXYf9cLfm6kzJfADfSIjgDYauDJ
	9cXBnVqzXzCToV4VMK8vNJa26mrPa4dUNMesUa+j8EY753ZPmlb+5z0Haf0flDHwxVOj
	fOi5zfXwRKpOuUph7uRm3ane9r8cj8IxrU70wBUfpP7BWw7t3O0JLCZ8usF/+vwg/Xiz
	qeqeYK5rpeMiHwqp4jz5//4WzcDXrAMBWKxfqjhpvZsD94s6l/kOZWi8sfwSTa5/JQqO
	cWAQ==
MIME-Version: 1.0
Received: by 10.42.189.138 with SMTP id de10mr6182529icb.38.1340644678106;
	Mon, 25 Jun 2012 10:17:58 -0700 (PDT)
Received: by 10.231.174.84 with HTTP; Mon, 25 Jun 2012 10:17:58 -0700 (PDT)
Date: Mon, 25 Jun 2012 18:17:58 +0100
Message-ID: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
From: "Omer K." <okhalid.cern@gmail.com>
To: xen-users list <xen-users@lists.xensource.com>, 
	xen-devel list <xen-devel@lists.xensource.com>,
	xen-tools@lists.xensource.com
Subject: [Xen-devel] Unable to make xen tools from xen-unstable 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: okhalid.cern@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5826500262632678376=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5826500262632678376==
Content-Type: multipart/alternative; boundary=20cf303bfb4acefd9a04c34f295e

--20cf303bfb4acefd9a04c34f295e
Content-Type: text/plain; charset=UTF-8

Hi,

I have downloaded the latest  xen-unstable release using mercurial
repositories. After ./configure, "make xen" successfully builds but "make
tools" fails after building xen trace package, and fails to download
seabios.git repository. Following is the output, and any help would be much
appreciated. Thank you.

/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cross-install
-m0644 -p xentrace.8
/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/share/man/man8
make[3]: Leaving directory
`//scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace'
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make[2]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make -C xcutils install
make[3]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
-d -m0755 -p
/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
-m0755 -p xc_restore xc_save readnotes lsevtchn
/sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
make[3]: Leaving directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make[2]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make -C firmware install
make[3]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
GIT=git
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh
git://xenbits.xen.org/seabios.git rel-1.6.3.2 seabios-dir
Cloning into seabios-dir-remote.tmp...
make[3]: Leaving directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make[1]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools'
linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://
xenbits.xen.org/seabios.git
Cloning into seabios...
fatal: Unable to look up xenbits.xen.org (port 9418) (Name or service not
known)

--20cf303bfb4acefd9a04c34f295e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I have downloaded the latest=C2=A0 xen-unstable release using me=
rcurial repositories. After ./configure, &quot;make xen&quot; successfully =
builds but &quot;make tools&quot; fails after building xen trace package, a=
nd fails to download seabios.git repository. Following is the output, and a=
ny help would be much appreciated. Thank you.<br>
<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cr=
oss-install -m0644 -p xentrace.8 /scratch/xen-unstable4.2/xen-unstable-4.2/=
dist/install/usr/share/man/man8<br>make[3]: Leaving directory `//scratch/xe=
n-unstable4.2/xen-unstable-4.2/tools/xentrace&#39;<br>
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
&#39;<br>make[2]: Entering directory `/scratch/xen-unstable4.2/xen-unstable=
-4.2/tools&#39;<br>make -C xcutils install<br>make[3]: Entering directory `=
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils&#39;<br>
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-i=
nstall -d -m0755 -p /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/=
usr/lib/xen/bin<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/=
../../tools/cross-install -m0755 -p xc_restore xc_save readnotes lsevtchn /=
sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bi=
n<br>
make[3]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
/xcutils&#39;<br>make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-u=
nstable-4.2/tools&#39;<br>make[2]: Entering directory `/scratch/xen-unstabl=
e4.2/xen-unstable-4.2/tools&#39;<br>
make -C firmware install<br>make[3]: Entering directory `/scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware&#39;<br>GIT=3Dgit /scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh git://=
<a href=3D"http://xenbits.xen.org/seabios.git">xenbits.xen.org/seabios.git<=
/a> rel-1.6.3.2 seabios-dir<br>
Cloning into seabios-dir-remote.tmp...<br>make[3]: Leaving directory `/scra=
tch/xen-unstable4.2/xen-unstable-4.2/tools/firmware&#39;<br>make[2]: Leavin=
g directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<br>make[1=
]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<b=
r>
linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://<a h=
ref=3D"http://xenbits.xen.org/seabios.git">xenbits.xen.org/seabios.git</a><=
br>Cloning into seabios...<br><span style=3D"background-color:rgb(255,255,5=
1)">fatal: Unable to look up <a href=3D"http://xenbits.xen.org">xenbits.xen=
.org</a> (port 9418) (Name or service not known)</span><br>
<br>

--20cf303bfb4acefd9a04c34f295e--


--===============5826500262632678376==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5826500262632678376==--


From xen-devel-bounces@lists.xen.org Mon Jun 25 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjCvL-0000B5-QD; Mon, 25 Jun 2012 17:18:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <okhalid.cern@gmail.com>) id 1SjCvJ-0000Ar-J7
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 17:18:01 +0000
Received: from [85.158.138.51:64558] by server-10.bemta-3.messagelabs.com id
	FD/3E-01753-84D98EF4; Mon, 25 Jun 2012 17:18:00 +0000
X-Env-Sender: okhalid.cern@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340644678!21353095!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4478 invoked from network); 25 Jun 2012 17:17:59 -0000
Received: from mail-gh0-f171.google.com (HELO mail-gh0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 17:17:59 -0000
Received: by ghy10 with SMTP id 10so4194197ghy.30
	for <multiple recipients>; Mon, 25 Jun 2012 10:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:date:message-id:subject:from:to:content-type;
	bh=+7/KZf8V/LzsHDwpWTNFcK6defDvedqKZQCYA/tUVyI=;
	b=wZATBB2D6XIvvLlWuehVvOpvj3xxRgboi6ZajVhNjdzN0NFqgalCsSpHGglCQynF4i
	WMUJhgZ6rtXWDAy4pOu/h4JJQH1trQSN/Ar0ztLYuBXYf9cLfm6kzJfADfSIjgDYauDJ
	9cXBnVqzXzCToV4VMK8vNJa26mrPa4dUNMesUa+j8EY753ZPmlb+5z0Haf0flDHwxVOj
	fOi5zfXwRKpOuUph7uRm3ane9r8cj8IxrU70wBUfpP7BWw7t3O0JLCZ8usF/+vwg/Xiz
	qeqeYK5rpeMiHwqp4jz5//4WzcDXrAMBWKxfqjhpvZsD94s6l/kOZWi8sfwSTa5/JQqO
	cWAQ==
MIME-Version: 1.0
Received: by 10.42.189.138 with SMTP id de10mr6182529icb.38.1340644678106;
	Mon, 25 Jun 2012 10:17:58 -0700 (PDT)
Received: by 10.231.174.84 with HTTP; Mon, 25 Jun 2012 10:17:58 -0700 (PDT)
Date: Mon, 25 Jun 2012 18:17:58 +0100
Message-ID: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
From: "Omer K." <okhalid.cern@gmail.com>
To: xen-users list <xen-users@lists.xensource.com>, 
	xen-devel list <xen-devel@lists.xensource.com>,
	xen-tools@lists.xensource.com
Subject: [Xen-devel] Unable to make xen tools from xen-unstable 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: okhalid.cern@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5826500262632678376=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5826500262632678376==
Content-Type: multipart/alternative; boundary=20cf303bfb4acefd9a04c34f295e

--20cf303bfb4acefd9a04c34f295e
Content-Type: text/plain; charset=UTF-8

Hi,

I have downloaded the latest  xen-unstable release using mercurial
repositories. After ./configure, "make xen" successfully builds but "make
tools" fails after building xen trace package, and fails to download
seabios.git repository. Following is the output, and any help would be much
appreciated. Thank you.

/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cross-install
-m0644 -p xentrace.8
/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/share/man/man8
make[3]: Leaving directory
`//scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace'
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make[2]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make -C xcutils install
make[3]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
-d -m0755 -p
/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
-m0755 -p xc_restore xc_save readnotes lsevtchn
/sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
make[3]: Leaving directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make[2]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make -C firmware install
make[3]: Entering directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
GIT=git
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh
git://xenbits.xen.org/seabios.git rel-1.6.3.2 seabios-dir
Cloning into seabios-dir-remote.tmp...
make[3]: Leaving directory
`/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
make[1]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools'
linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://
xenbits.xen.org/seabios.git
Cloning into seabios...
fatal: Unable to look up xenbits.xen.org (port 9418) (Name or service not
known)

--20cf303bfb4acefd9a04c34f295e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I have downloaded the latest=C2=A0 xen-unstable release using me=
rcurial repositories. After ./configure, &quot;make xen&quot; successfully =
builds but &quot;make tools&quot; fails after building xen trace package, a=
nd fails to download seabios.git repository. Following is the output, and a=
ny help would be much appreciated. Thank you.<br>
<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cr=
oss-install -m0644 -p xentrace.8 /scratch/xen-unstable4.2/xen-unstable-4.2/=
dist/install/usr/share/man/man8<br>make[3]: Leaving directory `//scratch/xe=
n-unstable4.2/xen-unstable-4.2/tools/xentrace&#39;<br>
make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
&#39;<br>make[2]: Entering directory `/scratch/xen-unstable4.2/xen-unstable=
-4.2/tools&#39;<br>make -C xcutils install<br>make[3]: Entering directory `=
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils&#39;<br>
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-i=
nstall -d -m0755 -p /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/=
usr/lib/xen/bin<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/=
../../tools/cross-install -m0755 -p xc_restore xc_save readnotes lsevtchn /=
sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bi=
n<br>
make[3]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
/xcutils&#39;<br>make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-u=
nstable-4.2/tools&#39;<br>make[2]: Entering directory `/scratch/xen-unstabl=
e4.2/xen-unstable-4.2/tools&#39;<br>
make -C firmware install<br>make[3]: Entering directory `/scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware&#39;<br>GIT=3Dgit /scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh git://=
<a href=3D"http://xenbits.xen.org/seabios.git">xenbits.xen.org/seabios.git<=
/a> rel-1.6.3.2 seabios-dir<br>
Cloning into seabios-dir-remote.tmp...<br>make[3]: Leaving directory `/scra=
tch/xen-unstable4.2/xen-unstable-4.2/tools/firmware&#39;<br>make[2]: Leavin=
g directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<br>make[1=
]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<b=
r>
linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://<a h=
ref=3D"http://xenbits.xen.org/seabios.git">xenbits.xen.org/seabios.git</a><=
br>Cloning into seabios...<br><span style=3D"background-color:rgb(255,255,5=
1)">fatal: Unable to look up <a href=3D"http://xenbits.xen.org">xenbits.xen=
.org</a> (port 9418) (Name or service not known)</span><br>
<br>

--20cf303bfb4acefd9a04c34f295e--


--===============5826500262632678376==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5826500262632678376==--


From xen-devel-bounces@lists.xen.org Mon Jun 25 17:26:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 17:26: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 1SjD3g-0000mL-4k; Mon, 25 Jun 2012 17:26:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1SjD3e-0000mE-NU
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 17:26:38 +0000
Received: from [85.158.143.35:46630] by server-1.bemta-4.messagelabs.com id
	B5/91-24392-E4F98EF4; Mon, 25 Jun 2012 17:26:38 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340645195!6296753!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23807 invoked from network); 25 Jun 2012 17:26:36 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-4.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Jun 2012 17:26:36 -0000
Received: from mail59-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Jun 2012 17:24:57 +0000
Received: from mail59-va3 (localhost [127.0.0.1])	by mail59-va3-R.bigfish.com
	(Postfix) with ESMTP id 0B8C62200B8;
	Mon, 25 Jun 2012 17:24:57 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.30; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: -5
X-BigFish: VPS-5(zz98dI9371I936eI146fI1432I4015Izz1202hzz8275dhz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail59-va3 (localhost.localdomain [127.0.0.1]) by mail59-va3
	(MessageSwitch) id 1340645095330632_13424;
	Mon, 25 Jun 2012 17:24:55 +0000 (UTC)
Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.249])	by
	mail59-va3.bigfish.com (Postfix) with ESMTP id 4D6B5200086;
	Mon, 25 Jun 2012 17:24:55 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.30) by VA3EHSMHS023.bigfish.com
	(10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 25 Jun 2012 17:24:54 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM24.ds.Vanderbilt.edu ([::1]) with mapi;
	Mon, 25 Jun 2012 12:26:24 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>, Dario Faggioli
	<raistlin@linux.it>
Date: Mon, 25 Jun 2012 12:22:09 -0500
Thread-Topic: [Xen-devel] Regarding selecting scheduler at boot time...
Thread-Index: Ac1P+ZGw4u38l8d6R9WwEQUCxWmNhgAA/7V8AL5fOOg=
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A13D3699FF8@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>,
	<1340316146.2757.4.camel@Abyss>,
	<1F1024E4B5C96041BD62D52E05482F6A12EA62C166@its-hcwnem04.ds.Vanderbilt.edu>
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C166@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console

I removed the current xen installation from system and downloaded the newest release from http://xen.org/products/downloads.html. With the new release sched=sedf parameter works and it can select sedf scheduler.

~Ashish
________________________________________
From: Tapdiya, Ashish
Sent: Thursday, June 21, 2012 5:31 PM
To: Dario Faggioli
Cc: xen-devel@lists.xen.org
Subject: RE: [Xen-devel] Regarding selecting scheduler at boot time...

Dario,

I dont have a log currently, I will get it as soon as possible. I am using a single physical machine, Intel Xeon 2.4 Ghz Quad Core.

Thanks,
~Ashish
________________________________________
From: Dario Faggioli [raistlin@linux.it]
Sent: Thursday, June 21, 2012 5:02 PM
To: Tapdiya, Ashish
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...

On Thu, 2012-06-21 at 16:10 -0500, Tapdiya, Ashish wrote:
> Hi,
>
Hello,

> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0.
>
ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console (see this:
http://wiki.xen.org/wiki/Xen_Serial_Console).

Also, what machine are we talking about? E.g., how many and what kind of
CPUs?

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 Mon Jun 25 17:26:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 17:26: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 1SjD3g-0000mL-4k; Mon, 25 Jun 2012 17:26:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1SjD3e-0000mE-NU
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 17:26:38 +0000
Received: from [85.158.143.35:46630] by server-1.bemta-4.messagelabs.com id
	B5/91-24392-E4F98EF4; Mon, 25 Jun 2012 17:26:38 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340645195!6296753!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23807 invoked from network); 25 Jun 2012 17:26:36 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-4.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Jun 2012 17:26:36 -0000
Received: from mail59-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Jun 2012 17:24:57 +0000
Received: from mail59-va3 (localhost [127.0.0.1])	by mail59-va3-R.bigfish.com
	(Postfix) with ESMTP id 0B8C62200B8;
	Mon, 25 Jun 2012 17:24:57 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.30; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: -5
X-BigFish: VPS-5(zz98dI9371I936eI146fI1432I4015Izz1202hzz8275dhz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail59-va3 (localhost.localdomain [127.0.0.1]) by mail59-va3
	(MessageSwitch) id 1340645095330632_13424;
	Mon, 25 Jun 2012 17:24:55 +0000 (UTC)
Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.249])	by
	mail59-va3.bigfish.com (Postfix) with ESMTP id 4D6B5200086;
	Mon, 25 Jun 2012 17:24:55 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.30) by VA3EHSMHS023.bigfish.com
	(10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 25 Jun 2012 17:24:54 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM24.ds.Vanderbilt.edu ([::1]) with mapi;
	Mon, 25 Jun 2012 12:26:24 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>, Dario Faggioli
	<raistlin@linux.it>
Date: Mon, 25 Jun 2012 12:22:09 -0500
Thread-Topic: [Xen-devel] Regarding selecting scheduler at boot time...
Thread-Index: Ac1P+ZGw4u38l8d6R9WwEQUCxWmNhgAA/7V8AL5fOOg=
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A13D3699FF8@its-hcwnem04.ds.Vanderbilt.edu>
References: <1F1024E4B5C96041BD62D52E05482F6A12EA62C164@its-hcwnem04.ds.Vanderbilt.edu>,
	<1340316146.2757.4.camel@Abyss>,
	<1F1024E4B5C96041BD62D52E05482F6A12EA62C166@its-hcwnem04.ds.Vanderbilt.edu>
In-Reply-To: <1F1024E4B5C96041BD62D52E05482F6A12EA62C166@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console

I removed the current xen installation from system and downloaded the newest release from http://xen.org/products/downloads.html. With the new release sched=sedf parameter works and it can select sedf scheduler.

~Ashish
________________________________________
From: Tapdiya, Ashish
Sent: Thursday, June 21, 2012 5:31 PM
To: Dario Faggioli
Cc: xen-devel@lists.xen.org
Subject: RE: [Xen-devel] Regarding selecting scheduler at boot time...

Dario,

I dont have a log currently, I will get it as soon as possible. I am using a single physical machine, Intel Xeon 2.4 Ghz Quad Core.

Thanks,
~Ashish
________________________________________
From: Dario Faggioli [raistlin@linux.it]
Sent: Thursday, June 21, 2012 5:02 PM
To: Tapdiya, Ashish
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regarding selecting scheduler at boot time...

On Thu, 2012-06-21 at 16:10 -0500, Tapdiya, Ashish wrote:
> Hi,
>
Hello,

> My hypervisor version is 4.1.2 and dom0 is ubuntu oneiric 3.0.30.
>
> When I supply sched=sedf or sched=arinc653 as boot parameter I can't boot into dom0.
>
ARNIC653, I never tried. Anyway, can you tell us something more about
that inability to boot? Where does it hands? Do you have a log of some
sort? Maybe the output of a serial console (see this:
http://wiki.xen.org/wiki/Xen_Serial_Console).

Also, what machine are we talking about? E.g., how many and what kind of
CPUs?

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 Mon Jun 25 18:19:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 18: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 1SjDsb-0001W2-AT; Mon, 25 Jun 2012 18:19:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjDsZ-0001Vo-2N
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 18:19:15 +0000
Received: from [85.158.138.51:60189] by server-10.bemta-3.messagelabs.com id
	6A/7C-01753-2ABA8EF4; Mon, 25 Jun 2012 18:19:14 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340648351!21360613!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24359 invoked from network); 25 Jun 2012 18:19:13 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 18:19:13 -0000
Received: by obbef5 with SMTP id ef5so10384075obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 25 Jun 2012 11:19:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=VNpbU5yZJ/7vJZ1/Tt+Ft/nn4D2wZY5yma7egfp5gDI=;
	b=Bpmqrih7oDNMJQ2zbuWhaQ5b/Oau3JFutgUPNlOqwsXfi/2u4ketGn9SNxqgXvjjFY
	qGHqPepWL70hRZYnbGe2r9cdc/k/rBbQHhp1Cy1lv+CutV7iBV66KPvcB30KD1Q/Xd3h
	yY5HeUfmE83kUHmpi5iXYu5b/NM5+3P78sjENRBp6tEaa2gcnlwmraGryMLZcRh9vQ9G
	5rkzPNcEDtn4tJsNrtQvYmefpkc9+0Wdq3igxeJJ80/YaLpJ5AYLLfbrNdEe49joA1ai
	IkL+qOAnh/aLJJkR8I8DIadgt7D8/uPdcAbuSFq2uVvs0Pnyl/lcDbSbWG2BEGF9GEwy
	S5fQ==
Received: by 10.182.14.101 with SMTP id o5mr13376189obc.1.1340648351435; Mon,
	25 Jun 2012 11:19:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 25 Jun 2012 11:18:51 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
References: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Mon, 25 Jun 2012 20:18:51 +0200
Message-ID: <CABs9EjmSsSv7FpYgvZy6mc3TSvHq_e=LrCHoTouqCvg=6uOL1Q@mail.gmail.com>
To: okhalid.cern@gmail.com
X-Gm-Message-State: ALoCoQkWJZOI2dlhqOn2AKajfz0Ksunh5OfKzPV7d7HF2g7A4doj5u2RkrIOa3RouZAwueD0B+w3
Cc: xen-tools@lists.xensource.com,
	xen-devel list <xen-devel@lists.xensource.com>,
	xen-users list <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] Unable to make xen tools from xen-unstable 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="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, Jun 25, 2012 at 7:17 PM, Omer K. <okhalid.cern@gmail.com> wrote:
> Hi,
>
> I have downloaded the latest=A0 xen-unstable release using mercurial
> repositories. After ./configure, "make xen" successfully builds but "make
> tools" fails after building xen trace package, and fails to download
> seabios.git repository. Following is the output, and any help would be mu=
ch
> appreciated. Thank you.
>
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cros=
s-install
> -m0644 -p xentrace.8
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/share/man/man8
> make[3]: Leaving directory
> `//scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace'
> make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/too=
ls'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C xcutils install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross=
-install
> -d -m0755 -p
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross=
-install
> -m0755 -p xc_restore xc_save readnotes lsevtchn
> /sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen=
/bin
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/too=
ls'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C firmware install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> GIT=3Dgit
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware/../../scripts/gi=
t-checkout.sh
> git://xenbits.xen.org/seabios.git rel-1.6.3.2 seabios-dir
> Cloning into seabios-dir-remote.tmp...
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/too=
ls'
> make[1]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tool=
s'
> linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone
> git://xenbits.xen.org/seabios.git
> Cloning into seabios...
> fatal: Unable to look up xenbits.xen.org (port 9418) (Name or service not
> known)
>

Try to access http://xenbits.xen.org/ in your web browser. This
verifies that you can access the host it's trying to get additional
data from. If not, you probably have a network problem somewhere.

If that works, have a look at
http://wiki.xen.org/wiki/Compiling_Xen_From_Source#Use_http:.2F.2F_Rather_T=
han_git:.2F.2F_to_Clone_Additional_Repositories

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 18:19:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 18: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 1SjDsb-0001W2-AT; Mon, 25 Jun 2012 18:19:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjDsZ-0001Vo-2N
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 18:19:15 +0000
Received: from [85.158.138.51:60189] by server-10.bemta-3.messagelabs.com id
	6A/7C-01753-2ABA8EF4; Mon, 25 Jun 2012 18:19:14 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340648351!21360613!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_23,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24359 invoked from network); 25 Jun 2012 18:19:13 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 18:19:13 -0000
Received: by obbef5 with SMTP id ef5so10384075obb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 25 Jun 2012 11:19:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=VNpbU5yZJ/7vJZ1/Tt+Ft/nn4D2wZY5yma7egfp5gDI=;
	b=Bpmqrih7oDNMJQ2zbuWhaQ5b/Oau3JFutgUPNlOqwsXfi/2u4ketGn9SNxqgXvjjFY
	qGHqPepWL70hRZYnbGe2r9cdc/k/rBbQHhp1Cy1lv+CutV7iBV66KPvcB30KD1Q/Xd3h
	yY5HeUfmE83kUHmpi5iXYu5b/NM5+3P78sjENRBp6tEaa2gcnlwmraGryMLZcRh9vQ9G
	5rkzPNcEDtn4tJsNrtQvYmefpkc9+0Wdq3igxeJJ80/YaLpJ5AYLLfbrNdEe49joA1ai
	IkL+qOAnh/aLJJkR8I8DIadgt7D8/uPdcAbuSFq2uVvs0Pnyl/lcDbSbWG2BEGF9GEwy
	S5fQ==
Received: by 10.182.14.101 with SMTP id o5mr13376189obc.1.1340648351435; Mon,
	25 Jun 2012 11:19:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 25 Jun 2012 11:18:51 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
References: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Mon, 25 Jun 2012 20:18:51 +0200
Message-ID: <CABs9EjmSsSv7FpYgvZy6mc3TSvHq_e=LrCHoTouqCvg=6uOL1Q@mail.gmail.com>
To: okhalid.cern@gmail.com
X-Gm-Message-State: ALoCoQkWJZOI2dlhqOn2AKajfz0Ksunh5OfKzPV7d7HF2g7A4doj5u2RkrIOa3RouZAwueD0B+w3
Cc: xen-tools@lists.xensource.com,
	xen-devel list <xen-devel@lists.xensource.com>,
	xen-users list <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] Unable to make xen tools from xen-unstable 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="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, Jun 25, 2012 at 7:17 PM, Omer K. <okhalid.cern@gmail.com> wrote:
> Hi,
>
> I have downloaded the latest=A0 xen-unstable release using mercurial
> repositories. After ./configure, "make xen" successfully builds but "make
> tools" fails after building xen trace package, and fails to download
> seabios.git repository. Following is the output, and any help would be mu=
ch
> appreciated. Thank you.
>
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cros=
s-install
> -m0644 -p xentrace.8
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/share/man/man8
> make[3]: Leaving directory
> `//scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace'
> make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/too=
ls'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C xcutils install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross=
-install
> -d -m0755 -p
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross=
-install
> -m0755 -p xc_restore xc_save readnotes lsevtchn
> /sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen=
/bin
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/too=
ls'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C firmware install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> GIT=3Dgit
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware/../../scripts/gi=
t-checkout.sh
> git://xenbits.xen.org/seabios.git rel-1.6.3.2 seabios-dir
> Cloning into seabios-dir-remote.tmp...
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/too=
ls'
> make[1]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tool=
s'
> linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone
> git://xenbits.xen.org/seabios.git
> Cloning into seabios...
> fatal: Unable to look up xenbits.xen.org (port 9418) (Name or service not
> known)
>

Try to access http://xenbits.xen.org/ in your web browser. This
verifies that you can access the host it's trying to get additional
data from. If not, you probably have a network problem somewhere.

If that works, have a look at
http://wiki.xen.org/wiki/Compiling_Xen_From_Source#Use_http:.2F.2F_Rather_T=
han_git:.2F.2F_to_Clone_Additional_Repositories

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 18:51:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 18: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 1SjENF-0002Cs-67; Mon, 25 Jun 2012 18:50: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 1SjENE-0002Ce-6g
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 18:50:56 +0000
Received: from [85.158.138.51:42193] by server-7.bemta-3.messagelabs.com id
	5D/32-10113-F03B8EF4; Mon, 25 Jun 2012 18:50:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340650254!29353676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11022 invoked from network); 25 Jun 2012 18:50:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 18:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,473,1336348800"; d="scan'208";a="13207755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 18:50:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 19:50:54 +0100
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 1SjENB-00014p-NC;
	Mon, 25 Jun 2012 18:50:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjENB-0001eK-FZ;
	Mon, 25 Jun 2012 19:50:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13368-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 19:50:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13368: 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 13368 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13368/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 13361
 test-amd64-amd64-win         12 guest-localmigrate/x10      fail pass in 13361
 test-amd64-i386-xl-multivcpu 10 guest-saverestore  fail in 13361 pass in 13368
 test-amd64-i386-xl            5 xen-boot           fail in 13361 pass in 13368
 test-i386-i386-xl             5 xen-boot           fail in 13361 pass in 13368

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail like 13100

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 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-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 13361 never pass

version targeted for testing:
 linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
baseline version:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
+ . 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 c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
+ branch=linux-3.0
+ revision=c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb:tested/linux-3.0
Counting objects: 1   
Counting objects: 101   
Counting objects: 175, done.
Compressing objects:   4% (1/21)   
Compressing objects:   9% (2/21)   
Compressing objects:  14% (3/21)   
Compressing objects:  19% (4/21)   
Compressing objects:  23% (5/21)   
Compressing objects:  28% (6/21)   
Compressing objects:  33% (7/21)   
Compressing objects:  38% (8/21)   
Compressing objects:  42% (9/21)   
Compressing objects:  47% (10/21)   
Compressing objects:  52% (11/21)   
Compressing objects:  57% (12/21)   
Compressing objects:  61% (13/21)   
Compressing objects:  66% (14/21)   
Compressing objects:  71% (15/21)   
Compressing objects:  76% (16/21)   
Compressing objects:  80% (17/21)   
Compressing objects:  85% (18/21)   
Compressing objects:  90% (19/21)   
Compressing objects:  95% (20/21)   
Compressing objects: 100% (21/21)   
Compressing objects: 100% (21/21), done.
Writing objects:   0% (1/132)   
Writing objects:   1% (2/132)   
Writing objects:   2% (3/132)   
Writing objects:   3% (4/132)   
Writing objects:   4% (6/132)   
Writing objects:   5% (7/132)   
Writing objects:   6% (8/132)   
Writing objects:   7% (10/132)   
Writing objects:   8% (11/132)   
Writing objects:   9% (12/132)   
Writing objects:  10% (14/132)   
Writing objects:  11% (15/132)   
Writing objects:  12% (16/132)   
Writing objects:  13% (18/132)   
Writing objects:  14% (19/132)   
Writing objects:  15% (20/132)   
Writing objects:  16% (22/132)   
Writing objects:  17% (23/132)   
Writing objects:  18% (24/132)   
Writing objects:  19% (26/132)   
Writing objects:  20% (27/132)   
Writing objects:  21% (28/132)   
Writing objects:  22% (30/132)   
Writing objects:  23% (31/132)   
Writing objects:  24% (32/132)   
Writing objects:  25% (33/132)   
Writing objects:  26% (35/132)   
Writing objects:  27% (36/132)   
Writing objects:  28% (37/132)   
Writing objects:  29% (39/132)   
Writing objects:  30% (40/132)   
Writing objects:  31% (41/132)   
Writing objects:  32% (43/132)   
Writing objects:  33% (44/132)   
Writing objects:  34% (45/132)   
Writing objects:  35% (47/132)   
Writing objects:  36% (48/132)   
Writing objects:  37% (49/132)   
Writing objects:  38% (51/132)   
Writing objects:  39% (52/132)   
Writing objects:  40% (53/132)   
Writing objects:  41% (55/132)   
Writing objects:  42% (56/132)   
Writing objects:  43% (57/132)   
Writing objects:  44% (59/132)   
Writing objects:  45% (60/132)   
Writing objects:  46% (61/132)   
Writing objects:  47% (63/132)   
Writing objects:  48% (64/132)   
Writing objects:  49% (65/132)   
Writing objects:  50% (66/132)   
Writing objects:  51% (68/132)   
Writing objects:  52% (69/132)   
Writing objects:  53% (70/132)   
Writing objects:  54% (72/132)   
Writing objects:  55% (73/132)   
Writing objects:  56% (74/132)   
Writing objects:  57% (76/132)   
Writing objects:  58% (77/132)   
Writing objects:  59% (78/132)   
Writing objects:  60% (80/132)   
Writing objects:  61% (81/132)   
Writing objects:  62% (82/132)   
Writing objects:  63% (84/132)   
Writing objects:  64% (85/132)   
Writing objects:  65% (86/132)   
Writing objects:  66% (88/132)   
Writing objects:  67% (89/132)   
Writing objects:  68% (90/132)   
Writing objects:  69% (92/132)   
Writing objects:  70% (93/132)   
Writing objects:  71% (94/132)   
Writing objects:  72% (96/132)   
Writing objects:  73% (97/132)   
Writing objects:  74% (98/132)   
Writing objects:  75% (99/132)   
Writing objects:  76% (101/132)   
Writing objects:  77% (102/132)   
Writing objects:  78% (103/132)   
Writing objects:  79% (105/132)   
Writing objects:  80% (106/132)   
Writing objects:  81% (107/132)   
Writing objects:  82% (109/132)   
Writing objects:  83% (110/132)   
Writing objects:  84% (111/132)   
Writing objects:  85% (113/132)   
Writing objects:  86% (114/132)   
Writing objects:  87% (115/132)   
Writing objects:  88% (117/132)   
Writing objects:  89% (118/132)   
Writing objects:  90% (119/132)   
Writing objects:  91% (121/132)   
Writing objects:  92% (122/132)   
Writing objects:  93% (123/132)   
Writing objects:  94% (125/132)   
Writing objects:  95% (126/132)   
Writing objects:  96% (127/132)   
Writing objects:  97% (129/132)   
Writing objects:  98% (130/132)   
Writing objects:  99% (131/132)   
Writing objects: 100% (132/132)   
Writing objects: 100% (132/132), 21.27 KiB, done.
Total 132 (delta 111), reused 132 (delta 111)
To xen@xenbits.xensource.com:git/linux-pvops.git
   839cf7a..c0bd4b6  c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb -> 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 Jun 25 18:51:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 18: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 1SjENF-0002Cs-67; Mon, 25 Jun 2012 18:50: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 1SjENE-0002Ce-6g
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 18:50:56 +0000
Received: from [85.158.138.51:42193] by server-7.bemta-3.messagelabs.com id
	5D/32-10113-F03B8EF4; Mon, 25 Jun 2012 18:50:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340650254!29353676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11022 invoked from network); 25 Jun 2012 18:50:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 18:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,473,1336348800"; d="scan'208";a="13207755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 18:50:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 25 Jun 2012 19:50:54 +0100
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 1SjENB-00014p-NC;
	Mon, 25 Jun 2012 18:50:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjENB-0001eK-FZ;
	Mon, 25 Jun 2012 19:50:53 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13368-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Jun 2012 19:50:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13368: 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 13368 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13368/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 13361
 test-amd64-amd64-win         12 guest-localmigrate/x10      fail pass in 13361
 test-amd64-i386-xl-multivcpu 10 guest-saverestore  fail in 13361 pass in 13368
 test-amd64-i386-xl            5 xen-boot           fail in 13361 pass in 13368
 test-i386-i386-xl             5 xen-boot           fail in 13361 pass in 13368

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail   like 13100
 test-amd64-amd64-xl-qemuu-winxpsp3 12 guest-localmigrate/x10   fail like 13100

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 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-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 13361 never pass

version targeted for testing:
 linux                c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
baseline version:
 linux                839cf7a236278ae358ff12141a168c0982fa0cd9

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         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-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
+ . 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 c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
+ branch=linux-3.0
+ revision=c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb:tested/linux-3.0
Counting objects: 1   
Counting objects: 101   
Counting objects: 175, done.
Compressing objects:   4% (1/21)   
Compressing objects:   9% (2/21)   
Compressing objects:  14% (3/21)   
Compressing objects:  19% (4/21)   
Compressing objects:  23% (5/21)   
Compressing objects:  28% (6/21)   
Compressing objects:  33% (7/21)   
Compressing objects:  38% (8/21)   
Compressing objects:  42% (9/21)   
Compressing objects:  47% (10/21)   
Compressing objects:  52% (11/21)   
Compressing objects:  57% (12/21)   
Compressing objects:  61% (13/21)   
Compressing objects:  66% (14/21)   
Compressing objects:  71% (15/21)   
Compressing objects:  76% (16/21)   
Compressing objects:  80% (17/21)   
Compressing objects:  85% (18/21)   
Compressing objects:  90% (19/21)   
Compressing objects:  95% (20/21)   
Compressing objects: 100% (21/21)   
Compressing objects: 100% (21/21), done.
Writing objects:   0% (1/132)   
Writing objects:   1% (2/132)   
Writing objects:   2% (3/132)   
Writing objects:   3% (4/132)   
Writing objects:   4% (6/132)   
Writing objects:   5% (7/132)   
Writing objects:   6% (8/132)   
Writing objects:   7% (10/132)   
Writing objects:   8% (11/132)   
Writing objects:   9% (12/132)   
Writing objects:  10% (14/132)   
Writing objects:  11% (15/132)   
Writing objects:  12% (16/132)   
Writing objects:  13% (18/132)   
Writing objects:  14% (19/132)   
Writing objects:  15% (20/132)   
Writing objects:  16% (22/132)   
Writing objects:  17% (23/132)   
Writing objects:  18% (24/132)   
Writing objects:  19% (26/132)   
Writing objects:  20% (27/132)   
Writing objects:  21% (28/132)   
Writing objects:  22% (30/132)   
Writing objects:  23% (31/132)   
Writing objects:  24% (32/132)   
Writing objects:  25% (33/132)   
Writing objects:  26% (35/132)   
Writing objects:  27% (36/132)   
Writing objects:  28% (37/132)   
Writing objects:  29% (39/132)   
Writing objects:  30% (40/132)   
Writing objects:  31% (41/132)   
Writing objects:  32% (43/132)   
Writing objects:  33% (44/132)   
Writing objects:  34% (45/132)   
Writing objects:  35% (47/132)   
Writing objects:  36% (48/132)   
Writing objects:  37% (49/132)   
Writing objects:  38% (51/132)   
Writing objects:  39% (52/132)   
Writing objects:  40% (53/132)   
Writing objects:  41% (55/132)   
Writing objects:  42% (56/132)   
Writing objects:  43% (57/132)   
Writing objects:  44% (59/132)   
Writing objects:  45% (60/132)   
Writing objects:  46% (61/132)   
Writing objects:  47% (63/132)   
Writing objects:  48% (64/132)   
Writing objects:  49% (65/132)   
Writing objects:  50% (66/132)   
Writing objects:  51% (68/132)   
Writing objects:  52% (69/132)   
Writing objects:  53% (70/132)   
Writing objects:  54% (72/132)   
Writing objects:  55% (73/132)   
Writing objects:  56% (74/132)   
Writing objects:  57% (76/132)   
Writing objects:  58% (77/132)   
Writing objects:  59% (78/132)   
Writing objects:  60% (80/132)   
Writing objects:  61% (81/132)   
Writing objects:  62% (82/132)   
Writing objects:  63% (84/132)   
Writing objects:  64% (85/132)   
Writing objects:  65% (86/132)   
Writing objects:  66% (88/132)   
Writing objects:  67% (89/132)   
Writing objects:  68% (90/132)   
Writing objects:  69% (92/132)   
Writing objects:  70% (93/132)   
Writing objects:  71% (94/132)   
Writing objects:  72% (96/132)   
Writing objects:  73% (97/132)   
Writing objects:  74% (98/132)   
Writing objects:  75% (99/132)   
Writing objects:  76% (101/132)   
Writing objects:  77% (102/132)   
Writing objects:  78% (103/132)   
Writing objects:  79% (105/132)   
Writing objects:  80% (106/132)   
Writing objects:  81% (107/132)   
Writing objects:  82% (109/132)   
Writing objects:  83% (110/132)   
Writing objects:  84% (111/132)   
Writing objects:  85% (113/132)   
Writing objects:  86% (114/132)   
Writing objects:  87% (115/132)   
Writing objects:  88% (117/132)   
Writing objects:  89% (118/132)   
Writing objects:  90% (119/132)   
Writing objects:  91% (121/132)   
Writing objects:  92% (122/132)   
Writing objects:  93% (123/132)   
Writing objects:  94% (125/132)   
Writing objects:  95% (126/132)   
Writing objects:  96% (127/132)   
Writing objects:  97% (129/132)   
Writing objects:  98% (130/132)   
Writing objects:  99% (131/132)   
Writing objects: 100% (132/132)   
Writing objects: 100% (132/132), 21.27 KiB, done.
Total 132 (delta 111), reused 132 (delta 111)
To xen@xenbits.xensource.com:git/linux-pvops.git
   839cf7a..c0bd4b6  c0bd4b6a0c6c0d42235920fb7ddd7110c86e2adb -> 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 Jun 25 20:44:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 20:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjG8m-0003gA-9R; Mon, 25 Jun 2012 20:44:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1SjG8k-0003g5-Rc
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 20:44:07 +0000
Received: from [85.158.143.35:7331] by server-2.bemta-4.messagelabs.com id
	83/AA-17938-69DC8EF4; Mon, 25 Jun 2012 20:44:06 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340657043!16942789!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22291 invoked from network); 25 Jun 2012 20:44:05 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.14)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Jun 2012 20:44:05 -0000
Received: from mail157-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Jun 2012 20:42:25 +0000
Received: from mail157-tx2 (localhost [127.0.0.1])	by
	mail157-tx2-R.bigfish.com (Postfix) with ESMTP id E3B88260316	for
	<xen-devel@lists.xen.org>; Mon, 25 Jun 2012 20:42:24 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.38; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: 0
X-BigFish: VPS0(zz4015Izz1202hzzz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail157-tx2 (localhost.localdomain [127.0.0.1]) by mail157-tx2
	(MessageSwitch) id 1340656943195822_21116;
	Mon, 25 Jun 2012 20:42:23 +0000 (UTC)
Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.246])	by
	mail157-tx2.bigfish.com (Postfix) with ESMTP id 2BC2D3A00F7	for
	<xen-devel@lists.xen.org>; Mon, 25 Jun 2012 20:42:23 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.38) by TX2EHSMHS039.bigfish.com
	(10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 25 Jun 2012 20:42:22 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM26.ds.Vanderbilt.edu ([fe80::b8bb:fb81:d5ba:1d6%11]) with
	mapi; Mon, 25 Jun 2012 15:43:59 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Mon, 25 Jun 2012 15:43:58 -0500
Thread-Topic: sedf parameter setting from dom0 user space...
Thread-Index: AQHNUxIkumaPacJuFEeIWuTv/EkGBA==
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A13D3699FF9@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Subject: Re: [Xen-devel] sedf parameter setting from dom0 user space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I tried to set sedf parameters using domctl hypercall from user space (privcmd interface). If I specify both period and slice and zero out rest (extratime, latency, weight), I get a -1 (error) return value. However, If I specify weight then period and slice values are ignored and default values are assigned and return value is 0. Below is my hypercall code:

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <fcntl.h>
#include <string.h>
#include <xenctrl.h>
#include <xen/sys/privcmd.h>

int main (int argc, char **argv)
{
	int fd, ret;

	xen_domctl_t dom;

        dom.domain = 4;
        dom.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
        dom.cmd = XEN_DOMCTL_scheduler_op;
        dom.u.scheduler_op.sched_id = XEN_SCHEDULER_SEDF;
        dom.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
        dom.u.scheduler_op.u.sedf.period = 100;
        dom.u.scheduler_op.u.sedf.slice = 20;
	dom.u.scheduler_op.u.sedf.latency = 0;
	dom.u.scheduler_op.u.sedf.extratime = 0;
	dom.u.scheduler_op.u.sedf.weight = 0;

	privcmd_hypercall_t hcall = 
	{
		__HYPERVISOR_domctl,
		{(unsigned long)&dom, 0, 0, 0, 0}
	};

	fd = open ("/proc/xen/privcmd", O_RDWR);
	if (fd <0) 
		printf("in here\n");
	else
		printf("fd = %d\n", fd);

	ret = ioctl (fd,IOCTL_PRIVCMD_HYPERCALL, &hcall);

	printf ("ret = %d\n", ret);
} 

Although things work fine from xm tools.

Thanks,
~Ashish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 20:44:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 20:44:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjG8m-0003gA-9R; Mon, 25 Jun 2012 20:44:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashish.tapdiya@Vanderbilt.Edu>) id 1SjG8k-0003g5-Rc
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 20:44:07 +0000
Received: from [85.158.143.35:7331] by server-2.bemta-4.messagelabs.com id
	83/AA-17938-69DC8EF4; Mon, 25 Jun 2012 20:44:06 +0000
X-Env-Sender: ashish.tapdiya@Vanderbilt.Edu
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340657043!16942789!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22291 invoked from network); 25 Jun 2012 20:44:05 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.14)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Jun 2012 20:44:05 -0000
Received: from mail157-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Jun 2012 20:42:25 +0000
Received: from mail157-tx2 (localhost [127.0.0.1])	by
	mail157-tx2-R.bigfish.com (Postfix) with ESMTP id E3B88260316	for
	<xen-devel@lists.xen.org>; Mon, 25 Jun 2012 20:42:24 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.59.94.38; KIP:(null); UIP:(null); IPV:NLI;
	H:hub.vanderbilt.edu; RD:error; EFVD:FOP
X-SpamScore: 0
X-BigFish: VPS0(zz4015Izz1202hzzz2dh2a8h668h839h944hd25hf0ahbe9i)
Received: from mail157-tx2 (localhost.localdomain [127.0.0.1]) by mail157-tx2
	(MessageSwitch) id 1340656943195822_21116;
	Mon, 25 Jun 2012 20:42:23 +0000 (UTC)
Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.246])	by
	mail157-tx2.bigfish.com (Postfix) with ESMTP id 2BC2D3A00F7	for
	<xen-devel@lists.xen.org>; Mon, 25 Jun 2012 20:42:23 +0000 (UTC)
Received: from hub.vanderbilt.edu (129.59.94.38) by TX2EHSMHS039.bigfish.com
	(10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 25 Jun 2012 20:42:22 +0000
Received: from its-hcwnem04.ds.Vanderbilt.edu ([10.1.137.104]) by
	ITS-SCWNEM26.ds.Vanderbilt.edu ([fe80::b8bb:fb81:d5ba:1d6%11]) with
	mapi; Mon, 25 Jun 2012 15:43:59 -0500
From: "Tapdiya, Ashish" <ashish.tapdiya@Vanderbilt.Edu>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Mon, 25 Jun 2012 15:43:58 -0500
Thread-Topic: sedf parameter setting from dom0 user space...
Thread-Index: AQHNUxIkumaPacJuFEeIWuTv/EkGBA==
Message-ID: <1F1024E4B5C96041BD62D52E05482F6A13D3699FF9@its-hcwnem04.ds.Vanderbilt.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginatorOrg: vanderbilt.edu
Subject: Re: [Xen-devel] sedf parameter setting from dom0 user space...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I tried to set sedf parameters using domctl hypercall from user space (privcmd interface). If I specify both period and slice and zero out rest (extratime, latency, weight), I get a -1 (error) return value. However, If I specify weight then period and slice values are ignored and default values are assigned and return value is 0. Below is my hypercall code:

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <fcntl.h>
#include <string.h>
#include <xenctrl.h>
#include <xen/sys/privcmd.h>

int main (int argc, char **argv)
{
	int fd, ret;

	xen_domctl_t dom;

        dom.domain = 4;
        dom.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
        dom.cmd = XEN_DOMCTL_scheduler_op;
        dom.u.scheduler_op.sched_id = XEN_SCHEDULER_SEDF;
        dom.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
        dom.u.scheduler_op.u.sedf.period = 100;
        dom.u.scheduler_op.u.sedf.slice = 20;
	dom.u.scheduler_op.u.sedf.latency = 0;
	dom.u.scheduler_op.u.sedf.extratime = 0;
	dom.u.scheduler_op.u.sedf.weight = 0;

	privcmd_hypercall_t hcall = 
	{
		__HYPERVISOR_domctl,
		{(unsigned long)&dom, 0, 0, 0, 0}
	};

	fd = open ("/proc/xen/privcmd", O_RDWR);
	if (fd <0) 
		printf("in here\n");
	else
		printf("fd = %d\n", fd);

	ret = ioctl (fd,IOCTL_PRIVCMD_HYPERCALL, &hcall);

	printf ("ret = %d\n", ret);
} 

Although things work fine from xm tools.

Thanks,
~Ashish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 21:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 21: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 1SjGvg-000422-5z; Mon, 25 Jun 2012 21:34: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 1SjGve-00041x-MY
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 21:34:38 +0000
Received: from [85.158.143.99:5269] by server-3.bemta-4.messagelabs.com id
	59/C3-05808-C69D8EF4; Mon, 25 Jun 2012 21:34:36 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340660076!28163965!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4220 invoked from network); 25 Jun 2012 21:34:36 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 21:34:36 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5PLYJV3005276;
	Mon, 25 Jun 2012 22:34:23 +0100
Received: from vega-c.dur.ac.uk (vega-c.dur.ac.uk [129.234.250.135])
	by smtphost2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5PLY3Ul013869
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 22:34:03 +0100
Received: from vega-c.dur.ac.uk (localhost [127.0.0.1])
	by vega-c.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q5PLY3PE009018;
	Mon, 25 Jun 2012 22:34:03 +0100
Received: from localhost (dcl0may@localhost)
	by vega-c.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q5PLY2rq009013;
	Mon, 25 Jun 2012 22:34:03 +0100
Date: Mon, 25 Jun 2012 22:34:02 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340621572.3832.13.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1206252215180.4133@vega-c.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
	<1340621572.3832.13.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-952439597-1340660043=:4133"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q5PLYJV3005276
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] pygrub: avoid problems if guest files are large etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-952439597-1340660043=:4133
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 25 Jun 2012, Ian Campbell wrote:

> BTW, what is the status of that patch?

I am attaching version 4 of my patch. It moves handling of the kernel and 
ramdisk into a function along the lines of Miroslav Rezanina's patch
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
It adds checking for problems opening the kernel or ramdisk files and 
checks they exist in the not_really mode as discussed in this thread.

I still think it is a good idea to remove the temporary copies of the 
kernel and ramdisk if there are problems copying them because I am not 
convinced the calling process always removes them and it might be 
presented with truncated files if copying the files filled the filespace.

 	Michael Young
--8323329-952439597-1340660043=:4133
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=pygrub.size.limits.v4.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=pygrub.size.limits.v4.patch

TWFrZSBweWdydWIgY29wZSBiZXR0ZXIgd2l0aCBiaWcgZmlsZXMgaW4gdGhl
IGd1ZXN0Lg0KT25seSByZWFkIHRoZSBmaXJzdCBtZWdhYnl0ZSBvZiBhIGNv
bmZpZ3VyYXRpb24gZmlsZSAoZ3J1YiBldGMuKSBhbmQgcmVhZA0KdGhlIGtl
cm5lbCBhbmQgcmFtZGlzayBmaWxlcyBmcm9tIHRoZSBndWVzdCBpbiBvbmUg
bWVnYWJ5dGUgcGllY2VzDQpzbyBweWdydWIgZG9lc24ndCB1c2UgYSBsb3Qg
b2YgbWVtb3J5IGlmIHRoZSBmaWxlcyBhcmUgbGFyZ2UuDQpXaXRoIC0tbm90
LXJlYWxseSBvcHRpb24gY2hlY2sgdGhhdCB0aGUgY2hvc2VuIGtlcm5lbCBh
bmQgcmFtZGlzayBmaWxlcyBleGlzdC4NCklmIHRoZXJlIGFyZSBwcm9ibGVt
cyB3cml0aW5nIHRoZSBjb3B5IG9mIHRoZSBrZXJuZWwgb3IgcmFtZGlzaywg
ZGVsZXRlIHRoZQ0KY29waWVkIGZpbGVzIGFuZCBleGl0IGluIGNhc2UgdGhl
eSBoYXZlIGZpbGxlZCB0aGUgZmlsZXN5c3RlbS4NCg0KU2lnbmVkLW9mZi1i
eTogTWljaGFlbCBZb3VuZyA8bS5hLnlvdW5nQGR1cmhhbS5hYy51az4NCg0K
LS0tIHhlbi00LjIuMC90b29scy9weWdydWIvc3JjL3B5Z3J1Yi5vcmlnCTIw
MTItMDUtMTIgMTY6NDA6NDguMDAwMDAwMDAwICswMTAwDQorKysgeGVuLTQu
Mi4wL3Rvb2xzL3B5Z3J1Yi9zcmMvcHlncnViCTIwMTItMDYtMjUgMjE6NTM6
NDkuNTU2NDQ2MzY5ICswMTAwDQpAQCAtMjgsNiArMjgsNyBAQA0KIGltcG9y
dCBncnViLkV4dExpbnV4Q29uZg0KIA0KIFBZR1JVQl9WRVIgPSAwLjYNCitm
c19yZWFkX21heD0xMDQ4NTc2DQogDQogZGVmIGVuYWJsZV9jdXJzb3IoaXNv
bik6DQogICAgIGlmIGlzb246DQpAQCAtNDQ4LDcgKzQ0OSw4IEBADQogICAg
ICAgICBpZiBzZWxmLl9fZGljdF9fLmdldCgnY2YnLCBOb25lKSBpcyBOb25l
Og0KICAgICAgICAgICAgIHJhaXNlIFJ1bnRpbWVFcnJvciwgImNvdWxkbid0
IGZpbmQgYm9vdGxvYWRlciBjb25maWcgZmlsZSBpbiB0aGUgaW1hZ2UgcHJv
dmlkZWQuIg0KICAgICAgICAgZiA9IGZzLm9wZW5fZmlsZShzZWxmLmNmLmZp
bGVuYW1lKQ0KLSAgICAgICAgYnVmID0gZi5yZWFkKCkNCisgICAgICAgICMg
bGltaXQgcmVhZCBzaXplIHRvIGF2b2lkIHBhdGhvbG9naWNhbCBjYXNlcw0K
KyAgICAgICAgYnVmID0gZi5yZWFkKGZzX3JlYWRfbWF4KQ0KICAgICAgICAg
ZGVsIGYNCiAgICAgICAgIHNlbGYuY2YucGFyc2UoYnVmKQ0KIA0KQEAgLTY5
Nyw2ICs2OTksMzkgQEANCiAgICAgZGVmIHVzYWdlKCk6DQogICAgICAgICBw
cmludCA+PiBzeXMuc3RkZXJyLCAiVXNhZ2U6ICVzIFstcXwtLXF1aWV0XSBb
LWl8LS1pbnRlcmFjdGl2ZV0gWy1ufC0tbm90LXJlYWxseV0gWy0tb3V0cHV0
PV0gWy0ta2VybmVsPV0gWy0tcmFtZGlzaz1dIFstLWFyZ3M9XSBbLS1lbnRy
eT1dIFstLW91dHB1dC1kaXJlY3Rvcnk9XSBbLS1vdXRwdXQtZm9ybWF0PXN4
cHxzaW1wbGV8c2ltcGxlMF0gPGltYWdlPiIgJShzeXMuYXJndlswXSwpDQog
DQorICAgIGRlZiBjb3B5X2Zyb21faW1hZ2UoZnMsIGZpbGVfdG9fcmVhZCwg
ZmlsZV90eXBlLCBvdXRwdXRfZGlyZWN0b3J5LA0KKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3RfcmVhbGx5LCBj
bGVhbl9leHRyYV9maWxlKToNCisgICAgICAgIGlmIG5vdF9yZWFsbHk6DQor
ICAgICAgICAgICAgaWYgZnMuZmlsZV9leGlzdHMoZmlsZV90b19yZWFkKToN
CisgICAgICAgICAgICAgICAgcmV0dXJuICI8JXM6JXM+IiAlIChmaWxlX3R5
cGUsZmlsZV90b19yZWFkKQ0KKyAgICAgICAgICAgIGVsc2U6DQorICAgICAg
ICAgICAgICAgIHN5cy5leGl0KCJUaGUgcmVxdWVzdGVkICVzIGZpbGUgZG9l
cyBub3QgZXhpc3QiICUgZmlsZV90eXBlKQ0KKyAgICAgICAgdHJ5Og0KKyAg
ICAgICAgICAgIGRhdGFmaWxlID0gZnMub3Blbl9maWxlKGZpbGVfdG9fcmVh
ZCkNCisgICAgICAgIGV4Y2VwdDoNCisgICAgICAgICAgICBpZiBjbGVhbl9l
eHRyYV9maWxlOg0KKyAgICAgICAgICAgICAgICBvcy51bmxpbmsoY2xlYW5f
ZXh0cmFfZmlsZSkNCisgICAgICAgICAgICBzeXMuZXhpdCgiRXJyb3Igb3Bl
bmluZyAlcyIgJSBmaWxlX3RvX3JlYWQpDQorICAgICAgICAodGZkLCByZXQp
ID0gdGVtcGZpbGUubWtzdGVtcChwcmVmaXg9ImJvb3RfIitmaWxlX3R5cGUr
Ii4iLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBkaXI9b3V0cHV0X2RpcmVjdG9yeSkNCisgICAg
ICAgIGRhdGFvZmY9MA0KKyAgICAgICAgd2hpbGUgVHJ1ZToNCisgICAgICAg
ICAgICBkYXRhPWRhdGFmaWxlLnJlYWQoZnNfcmVhZF9tYXgsZGF0YW9mZikN
CisgICAgICAgICAgICBpZiBsZW4oZGF0YSkgPT0gMDoNCisgICAgICAgICAg
ICAgICAgb3MuY2xvc2UodGZkKQ0KKyAgICAgICAgICAgICAgICBkZWwgZGF0
YWZpbGUNCisgICAgICAgICAgICAgICAgcmV0dXJuIHJldA0KKyAgICAgICAg
ICAgIHRyeToNCisgICAgICAgICAgICAgICAgb3Mud3JpdGUodGZkLCBkYXRh
KQ0KKyAgICAgICAgICAgIGV4Y2VwdDoNCisgICAgICAgICAgICAgICAgb3Mu
Y2xvc2UodGZkKQ0KKyAgICAgICAgICAgICAgICBvcy51bmxpbmsocmV0KQ0K
KyAgICAgICAgICAgICAgICBkZWwgZGF0YWZpbGUNCisgICAgICAgICAgICAg
ICAgaWYgY2xlYW5fZXh0cmFfZmlsZToNCisgICAgICAgICAgICAgICAgICAg
IG9zLnVubGluayhjbGVhbl9leHRyYV9maWxlKQ0KKyAgICAgICAgICAgICAg
ICBzeXMuZXhpdCgiZXJyb3Igd3JpdGluZyB0ZW1wb3JhcnkgY29weSBvZiAi
K2ZpbGVfdHlwZSkNCisgICAgICAgICAgICBkYXRhb2ZmKz1sZW4oZGF0YSkN
CisNCiAgICAgdHJ5Og0KICAgICAgICAgb3B0cywgYXJncyA9IGdldG9wdC5n
bnVfZ2V0b3B0KHN5cy5hcmd2WzE6XSwgJ3Fpbmg6OicsDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBbInF1aWV0IiwgImludGVyYWN0
aXZlIiwgIm5vdC1yZWFsbHkiLCAiaGVscCIsIA0KQEAgLTgyMSwyNCArODU2
LDEyIEBADQogICAgIGlmIG5vdCBmczoNCiAgICAgICAgIHJhaXNlIFJ1bnRp
bWVFcnJvciwgIlVuYWJsZSB0byBmaW5kIHBhcnRpdGlvbiBjb250YWluaW5n
IGtlcm5lbCINCiANCi0gICAgaWYgbm90X3JlYWxseToNCi0gICAgICAgIGJv
b3RjZmdbImtlcm5lbCJdID0gIjxrZXJuZWw6JXM+IiAlIGNob3NlbmNmZ1si
a2VybmVsIl0NCi0gICAgZWxzZToNCi0gICAgICAgIGRhdGEgPSBmcy5vcGVu
X2ZpbGUoY2hvc2VuY2ZnWyJrZXJuZWwiXSkucmVhZCgpDQotICAgICAgICAo
dGZkLCBib290Y2ZnWyJrZXJuZWwiXSkgPSB0ZW1wZmlsZS5ta3N0ZW1wKHBy
ZWZpeD0iYm9vdF9rZXJuZWwuIiwNCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGlyPW91dHB1dF9kaXJl
Y3RvcnkpDQotICAgICAgICBvcy53cml0ZSh0ZmQsIGRhdGEpDQotICAgICAg
ICBvcy5jbG9zZSh0ZmQpDQorICAgIGJvb3RjZmdbImtlcm5lbCJdID0gY29w
eV9mcm9tX2ltYWdlKGZzLCBjaG9zZW5jZmdbImtlcm5lbCJdLCANCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAia2VybmVsIiwgb3V0cHV0X2Rp
cmVjdG9yeSwgbm90X3JlYWxseSwgIiIpDQogDQogICAgIGlmIGNob3NlbmNm
Z1sicmFtZGlzayJdOg0KLSAgICAgICAgaWYgbm90X3JlYWxseToNCi0gICAg
ICAgICAgICBib290Y2ZnWyJyYW1kaXNrIl0gPSAiPHJhbWRpc2s6JXM+IiAl
IGNob3NlbmNmZ1sicmFtZGlzayJdDQotICAgICAgICBlbHNlOg0KLSAgICAg
ICAgICAgIGRhdGEgPSBmcy5vcGVuX2ZpbGUoY2hvc2VuY2ZnWyJyYW1kaXNr
Il0sKS5yZWFkKCkNCi0gICAgICAgICAgICAodGZkLCBib290Y2ZnWyJyYW1k
aXNrIl0pID0gdGVtcGZpbGUubWtzdGVtcCgNCi0gICAgICAgICAgICAgICAg
cHJlZml4PSJib290X3JhbWRpc2suIiwgZGlyPW91dHB1dF9kaXJlY3Rvcnkp
DQotICAgICAgICAgICAgb3Mud3JpdGUodGZkLCBkYXRhKQ0KLSAgICAgICAg
ICAgIG9zLmNsb3NlKHRmZCkNCisgICAgICAgIGJvb3RjZmdbInJhbWRpc2si
XSA9IGNvcHlfZnJvbV9pbWFnZShmcywgY2hvc2VuY2ZnWyJyYW1kaXNrIl0s
DQorICAgICAgICAgICAgICAicmFtZGlzayIsIG91dHB1dF9kaXJlY3Rvcnks
IG5vdF9yZWFsbHksIGJvb3RjZmdbImtlcm5lbCJdKQ0KICAgICBlbHNlOg0K
ICAgICAgICAgaW5pdHJkID0gTm9uZQ0KIA0K

--8323329-952439597-1340660043=:4133
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-952439597-1340660043=:4133--


From xen-devel-bounces@lists.xen.org Mon Jun 25 21:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 21: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 1SjGvg-000422-5z; Mon, 25 Jun 2012 21:34: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 1SjGve-00041x-MY
	for xen-devel@lists.xen.org; Mon, 25 Jun 2012 21:34:38 +0000
Received: from [85.158.143.99:5269] by server-3.bemta-4.messagelabs.com id
	59/C3-05808-C69D8EF4; Mon, 25 Jun 2012 21:34:36 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340660076!28163965!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4220 invoked from network); 25 Jun 2012 21:34:36 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jun 2012 21:34:36 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q5PLYJV3005276;
	Mon, 25 Jun 2012 22:34:23 +0100
Received: from vega-c.dur.ac.uk (vega-c.dur.ac.uk [129.234.250.135])
	by smtphost2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q5PLY3Ul013869
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Jun 2012 22:34:03 +0100
Received: from vega-c.dur.ac.uk (localhost [127.0.0.1])
	by vega-c.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q5PLY3PE009018;
	Mon, 25 Jun 2012 22:34:03 +0100
Received: from localhost (dcl0may@localhost)
	by vega-c.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q5PLY2rq009013;
	Mon, 25 Jun 2012 22:34:03 +0100
Date: Mon, 25 Jun 2012 22:34:02 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340621572.3832.13.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1206252215180.4133@vega-c.dur.ac.uk>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
	<1340621572.3832.13.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-952439597-1340660043=:4133"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q5PLYJV3005276
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] pygrub: avoid problems if guest files are large etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-952439597-1340660043=:4133
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 25 Jun 2012, Ian Campbell wrote:

> BTW, what is the status of that patch?

I am attaching version 4 of my patch. It moves handling of the kernel and 
ramdisk into a function along the lines of Miroslav Rezanina's patch
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
It adds checking for problems opening the kernel or ramdisk files and 
checks they exist in the not_really mode as discussed in this thread.

I still think it is a good idea to remove the temporary copies of the 
kernel and ramdisk if there are problems copying them because I am not 
convinced the calling process always removes them and it might be 
presented with truncated files if copying the files filled the filespace.

 	Michael Young
--8323329-952439597-1340660043=:4133
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=pygrub.size.limits.v4.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=pygrub.size.limits.v4.patch

TWFrZSBweWdydWIgY29wZSBiZXR0ZXIgd2l0aCBiaWcgZmlsZXMgaW4gdGhl
IGd1ZXN0Lg0KT25seSByZWFkIHRoZSBmaXJzdCBtZWdhYnl0ZSBvZiBhIGNv
bmZpZ3VyYXRpb24gZmlsZSAoZ3J1YiBldGMuKSBhbmQgcmVhZA0KdGhlIGtl
cm5lbCBhbmQgcmFtZGlzayBmaWxlcyBmcm9tIHRoZSBndWVzdCBpbiBvbmUg
bWVnYWJ5dGUgcGllY2VzDQpzbyBweWdydWIgZG9lc24ndCB1c2UgYSBsb3Qg
b2YgbWVtb3J5IGlmIHRoZSBmaWxlcyBhcmUgbGFyZ2UuDQpXaXRoIC0tbm90
LXJlYWxseSBvcHRpb24gY2hlY2sgdGhhdCB0aGUgY2hvc2VuIGtlcm5lbCBh
bmQgcmFtZGlzayBmaWxlcyBleGlzdC4NCklmIHRoZXJlIGFyZSBwcm9ibGVt
cyB3cml0aW5nIHRoZSBjb3B5IG9mIHRoZSBrZXJuZWwgb3IgcmFtZGlzaywg
ZGVsZXRlIHRoZQ0KY29waWVkIGZpbGVzIGFuZCBleGl0IGluIGNhc2UgdGhl
eSBoYXZlIGZpbGxlZCB0aGUgZmlsZXN5c3RlbS4NCg0KU2lnbmVkLW9mZi1i
eTogTWljaGFlbCBZb3VuZyA8bS5hLnlvdW5nQGR1cmhhbS5hYy51az4NCg0K
LS0tIHhlbi00LjIuMC90b29scy9weWdydWIvc3JjL3B5Z3J1Yi5vcmlnCTIw
MTItMDUtMTIgMTY6NDA6NDguMDAwMDAwMDAwICswMTAwDQorKysgeGVuLTQu
Mi4wL3Rvb2xzL3B5Z3J1Yi9zcmMvcHlncnViCTIwMTItMDYtMjUgMjE6NTM6
NDkuNTU2NDQ2MzY5ICswMTAwDQpAQCAtMjgsNiArMjgsNyBAQA0KIGltcG9y
dCBncnViLkV4dExpbnV4Q29uZg0KIA0KIFBZR1JVQl9WRVIgPSAwLjYNCitm
c19yZWFkX21heD0xMDQ4NTc2DQogDQogZGVmIGVuYWJsZV9jdXJzb3IoaXNv
bik6DQogICAgIGlmIGlzb246DQpAQCAtNDQ4LDcgKzQ0OSw4IEBADQogICAg
ICAgICBpZiBzZWxmLl9fZGljdF9fLmdldCgnY2YnLCBOb25lKSBpcyBOb25l
Og0KICAgICAgICAgICAgIHJhaXNlIFJ1bnRpbWVFcnJvciwgImNvdWxkbid0
IGZpbmQgYm9vdGxvYWRlciBjb25maWcgZmlsZSBpbiB0aGUgaW1hZ2UgcHJv
dmlkZWQuIg0KICAgICAgICAgZiA9IGZzLm9wZW5fZmlsZShzZWxmLmNmLmZp
bGVuYW1lKQ0KLSAgICAgICAgYnVmID0gZi5yZWFkKCkNCisgICAgICAgICMg
bGltaXQgcmVhZCBzaXplIHRvIGF2b2lkIHBhdGhvbG9naWNhbCBjYXNlcw0K
KyAgICAgICAgYnVmID0gZi5yZWFkKGZzX3JlYWRfbWF4KQ0KICAgICAgICAg
ZGVsIGYNCiAgICAgICAgIHNlbGYuY2YucGFyc2UoYnVmKQ0KIA0KQEAgLTY5
Nyw2ICs2OTksMzkgQEANCiAgICAgZGVmIHVzYWdlKCk6DQogICAgICAgICBw
cmludCA+PiBzeXMuc3RkZXJyLCAiVXNhZ2U6ICVzIFstcXwtLXF1aWV0XSBb
LWl8LS1pbnRlcmFjdGl2ZV0gWy1ufC0tbm90LXJlYWxseV0gWy0tb3V0cHV0
PV0gWy0ta2VybmVsPV0gWy0tcmFtZGlzaz1dIFstLWFyZ3M9XSBbLS1lbnRy
eT1dIFstLW91dHB1dC1kaXJlY3Rvcnk9XSBbLS1vdXRwdXQtZm9ybWF0PXN4
cHxzaW1wbGV8c2ltcGxlMF0gPGltYWdlPiIgJShzeXMuYXJndlswXSwpDQog
DQorICAgIGRlZiBjb3B5X2Zyb21faW1hZ2UoZnMsIGZpbGVfdG9fcmVhZCwg
ZmlsZV90eXBlLCBvdXRwdXRfZGlyZWN0b3J5LA0KKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3RfcmVhbGx5LCBj
bGVhbl9leHRyYV9maWxlKToNCisgICAgICAgIGlmIG5vdF9yZWFsbHk6DQor
ICAgICAgICAgICAgaWYgZnMuZmlsZV9leGlzdHMoZmlsZV90b19yZWFkKToN
CisgICAgICAgICAgICAgICAgcmV0dXJuICI8JXM6JXM+IiAlIChmaWxlX3R5
cGUsZmlsZV90b19yZWFkKQ0KKyAgICAgICAgICAgIGVsc2U6DQorICAgICAg
ICAgICAgICAgIHN5cy5leGl0KCJUaGUgcmVxdWVzdGVkICVzIGZpbGUgZG9l
cyBub3QgZXhpc3QiICUgZmlsZV90eXBlKQ0KKyAgICAgICAgdHJ5Og0KKyAg
ICAgICAgICAgIGRhdGFmaWxlID0gZnMub3Blbl9maWxlKGZpbGVfdG9fcmVh
ZCkNCisgICAgICAgIGV4Y2VwdDoNCisgICAgICAgICAgICBpZiBjbGVhbl9l
eHRyYV9maWxlOg0KKyAgICAgICAgICAgICAgICBvcy51bmxpbmsoY2xlYW5f
ZXh0cmFfZmlsZSkNCisgICAgICAgICAgICBzeXMuZXhpdCgiRXJyb3Igb3Bl
bmluZyAlcyIgJSBmaWxlX3RvX3JlYWQpDQorICAgICAgICAodGZkLCByZXQp
ID0gdGVtcGZpbGUubWtzdGVtcChwcmVmaXg9ImJvb3RfIitmaWxlX3R5cGUr
Ii4iLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBkaXI9b3V0cHV0X2RpcmVjdG9yeSkNCisgICAg
ICAgIGRhdGFvZmY9MA0KKyAgICAgICAgd2hpbGUgVHJ1ZToNCisgICAgICAg
ICAgICBkYXRhPWRhdGFmaWxlLnJlYWQoZnNfcmVhZF9tYXgsZGF0YW9mZikN
CisgICAgICAgICAgICBpZiBsZW4oZGF0YSkgPT0gMDoNCisgICAgICAgICAg
ICAgICAgb3MuY2xvc2UodGZkKQ0KKyAgICAgICAgICAgICAgICBkZWwgZGF0
YWZpbGUNCisgICAgICAgICAgICAgICAgcmV0dXJuIHJldA0KKyAgICAgICAg
ICAgIHRyeToNCisgICAgICAgICAgICAgICAgb3Mud3JpdGUodGZkLCBkYXRh
KQ0KKyAgICAgICAgICAgIGV4Y2VwdDoNCisgICAgICAgICAgICAgICAgb3Mu
Y2xvc2UodGZkKQ0KKyAgICAgICAgICAgICAgICBvcy51bmxpbmsocmV0KQ0K
KyAgICAgICAgICAgICAgICBkZWwgZGF0YWZpbGUNCisgICAgICAgICAgICAg
ICAgaWYgY2xlYW5fZXh0cmFfZmlsZToNCisgICAgICAgICAgICAgICAgICAg
IG9zLnVubGluayhjbGVhbl9leHRyYV9maWxlKQ0KKyAgICAgICAgICAgICAg
ICBzeXMuZXhpdCgiZXJyb3Igd3JpdGluZyB0ZW1wb3JhcnkgY29weSBvZiAi
K2ZpbGVfdHlwZSkNCisgICAgICAgICAgICBkYXRhb2ZmKz1sZW4oZGF0YSkN
CisNCiAgICAgdHJ5Og0KICAgICAgICAgb3B0cywgYXJncyA9IGdldG9wdC5n
bnVfZ2V0b3B0KHN5cy5hcmd2WzE6XSwgJ3Fpbmg6OicsDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBbInF1aWV0IiwgImludGVyYWN0
aXZlIiwgIm5vdC1yZWFsbHkiLCAiaGVscCIsIA0KQEAgLTgyMSwyNCArODU2
LDEyIEBADQogICAgIGlmIG5vdCBmczoNCiAgICAgICAgIHJhaXNlIFJ1bnRp
bWVFcnJvciwgIlVuYWJsZSB0byBmaW5kIHBhcnRpdGlvbiBjb250YWluaW5n
IGtlcm5lbCINCiANCi0gICAgaWYgbm90X3JlYWxseToNCi0gICAgICAgIGJv
b3RjZmdbImtlcm5lbCJdID0gIjxrZXJuZWw6JXM+IiAlIGNob3NlbmNmZ1si
a2VybmVsIl0NCi0gICAgZWxzZToNCi0gICAgICAgIGRhdGEgPSBmcy5vcGVu
X2ZpbGUoY2hvc2VuY2ZnWyJrZXJuZWwiXSkucmVhZCgpDQotICAgICAgICAo
dGZkLCBib290Y2ZnWyJrZXJuZWwiXSkgPSB0ZW1wZmlsZS5ta3N0ZW1wKHBy
ZWZpeD0iYm9vdF9rZXJuZWwuIiwNCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGlyPW91dHB1dF9kaXJl
Y3RvcnkpDQotICAgICAgICBvcy53cml0ZSh0ZmQsIGRhdGEpDQotICAgICAg
ICBvcy5jbG9zZSh0ZmQpDQorICAgIGJvb3RjZmdbImtlcm5lbCJdID0gY29w
eV9mcm9tX2ltYWdlKGZzLCBjaG9zZW5jZmdbImtlcm5lbCJdLCANCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAia2VybmVsIiwgb3V0cHV0X2Rp
cmVjdG9yeSwgbm90X3JlYWxseSwgIiIpDQogDQogICAgIGlmIGNob3NlbmNm
Z1sicmFtZGlzayJdOg0KLSAgICAgICAgaWYgbm90X3JlYWxseToNCi0gICAg
ICAgICAgICBib290Y2ZnWyJyYW1kaXNrIl0gPSAiPHJhbWRpc2s6JXM+IiAl
IGNob3NlbmNmZ1sicmFtZGlzayJdDQotICAgICAgICBlbHNlOg0KLSAgICAg
ICAgICAgIGRhdGEgPSBmcy5vcGVuX2ZpbGUoY2hvc2VuY2ZnWyJyYW1kaXNr
Il0sKS5yZWFkKCkNCi0gICAgICAgICAgICAodGZkLCBib290Y2ZnWyJyYW1k
aXNrIl0pID0gdGVtcGZpbGUubWtzdGVtcCgNCi0gICAgICAgICAgICAgICAg
cHJlZml4PSJib290X3JhbWRpc2suIiwgZGlyPW91dHB1dF9kaXJlY3Rvcnkp
DQotICAgICAgICAgICAgb3Mud3JpdGUodGZkLCBkYXRhKQ0KLSAgICAgICAg
ICAgIG9zLmNsb3NlKHRmZCkNCisgICAgICAgIGJvb3RjZmdbInJhbWRpc2si
XSA9IGNvcHlfZnJvbV9pbWFnZShmcywgY2hvc2VuY2ZnWyJyYW1kaXNrIl0s
DQorICAgICAgICAgICAgICAicmFtZGlzayIsIG91dHB1dF9kaXJlY3Rvcnks
IG5vdF9yZWFsbHksIGJvb3RjZmdbImtlcm5lbCJdKQ0KICAgICBlbHNlOg0K
ICAgICAgICAgaW5pdHJkID0gTm9uZQ0KIA0K

--8323329-952439597-1340660043=:4133
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-952439597-1340660043=:4133--


From xen-devel-bounces@lists.xen.org Mon Jun 25 23:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 23: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 1SjINU-0005o9-Uo; Mon, 25 Jun 2012 23:07:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjINT-0005o1-EW
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 23:07:27 +0000
Received: from [85.158.143.35:44240] by server-2.bemta-4.messagelabs.com id
	72/20-17938-E2FE8EF4; Mon, 25 Jun 2012 23:07:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340665637!18024502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19228 invoked from network); 25 Jun 2012 23:07:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 23:07:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,474,1336348800"; d="scan'208";a="13210188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 23:07:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 00:07:16 +0100
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 1SjINI-0002Tx-Nj;
	Mon, 25 Jun 2012 23:07:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjINI-0002wA-9e;
	Tue, 26 Jun 2012 00:07:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13369-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 00:07:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13369: 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 13369 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13369/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13367

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e08cf97e76f0
baseline version:
 xen                  8c70ad9fd221

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e08cf97e76f0
+ . 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 e08cf97e76f0
+ branch=xen-unstable
+ revision=e08cf97e76f0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e08cf97e76f0 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Jun 25 23:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Jun 2012 23: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 1SjINU-0005o9-Uo; Mon, 25 Jun 2012 23:07:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjINT-0005o1-EW
	for xen-devel@lists.xensource.com; Mon, 25 Jun 2012 23:07:27 +0000
Received: from [85.158.143.35:44240] by server-2.bemta-4.messagelabs.com id
	72/20-17938-E2FE8EF4; Mon, 25 Jun 2012 23:07:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340665637!18024502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19228 invoked from network); 25 Jun 2012 23:07:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jun 2012 23:07:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,474,1336348800"; d="scan'208";a="13210188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jun 2012 23:07:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 00:07:16 +0100
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 1SjINI-0002Tx-Nj;
	Mon, 25 Jun 2012 23:07:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjINI-0002wA-9e;
	Tue, 26 Jun 2012 00:07:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13369-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 00:07:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13369: 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 13369 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13369/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13367

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e08cf97e76f0
baseline version:
 xen                  8c70ad9fd221

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e08cf97e76f0
+ . 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 e08cf97e76f0
+ branch=xen-unstable
+ revision=e08cf97e76f0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e08cf97e76f0 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 00:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 00: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 1SjJPm-0007kW-6X; Tue, 26 Jun 2012 00:13:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SjJPl-0007kR-22
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 00:13:53 +0000
Received: from [85.158.139.83:31154] by server-1.bemta-5.messagelabs.com id
	CD/84-19721-0CEF8EF4; Tue, 26 Jun 2012 00:13:52 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340669627!26748408!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk1MzU2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6810 invoked from network); 26 Jun 2012 00:13:50 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 00:13:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340669630; x=1372205630;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=jS1X2FifBsjwjSfkVgZHgXtSyfJpKW3FnPOrFO3t7Ks=;
	b=KUTUzxZGOPPVEY5aBX4ki0mhNvCPdunUVQHXDM7wcAdXls7O5Zyuedy7
	bWkmLcpXZP/tkScNFEGk8ZyO/mcV/Q==;
X-IronPort-AV: E=Sophos;i="4.77,475,1336348800"; d="scan'208";a="987451191"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2012 00:13:32 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5Q0DMgN031351
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 26 Jun 2012 00:13:22 GMT
Received: from US-SEA-R8XVZTX (10.224.80.34) by ex10-hub-31006.ant.amazon.com
	(10.185.176.13) with Microsoft SMTP Server id 14.2.247.3;
	Mon, 25 Jun 2012 17:13:21 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Mon, 25 Jun 2012
	17:13:21 -0700
Date: Mon, 25 Jun 2012 17:13:21 -0700
From: Matt Wilson <msw@amazon.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120626001321.GC8088@US-SEA-R8XVZTX>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
	<1340621572.3832.13.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1206252215180.4133@vega-c.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1206252215180.4133@vega-c.dur.ac.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
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] pygrub: avoid problems if guest files are large etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 25, 2012 at 02:34:02PM -0700, M A Young wrote:
> On Mon, 25 Jun 2012, Ian Campbell wrote:
> 
> > BTW, what is the status of that patch?
> 
> I am attaching version 4 of my patch. It moves handling of the kernel and 
> ramdisk into a function along the lines of Miroslav Rezanina's patch
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
> It adds checking for problems opening the kernel or ramdisk files and 
> checks they exist in the not_really mode as discussed in this thread.
> 
> I still think it is a good idea to remove the temporary copies of the 
> kernel and ramdisk if there are problems copying them because I am not 
> convinced the calling process always removes them and it might be 
> presented with truncated files if copying the files filled the filespace.
> 
>  	Michael Young
>
> Make pygrub cope better with big files in the guest.
> Only read the first megabyte of a configuration file (grub etc.) and read
> the kernel and ramdisk files from the guest in one megabyte pieces
> so pygrub doesn't use a lot of memory if the files are large.
> With --not-really option check that the chosen kernel and ramdisk files exist.
> If there are problems writing the copy of the kernel or ramdisk, delete the
> copied files and exit in case they have filled the filesystem.
> 
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> 
> --- xen-4.2.0/tools/pygrub/src/pygrub.orig	2012-05-12 16:40:48.000000000 +0100
> +++ xen-4.2.0/tools/pygrub/src/pygrub	2012-06-25 21:53:49.556446369 +0100
> @@ -28,6 +28,7 @@
>  import grub.ExtLinuxConf
>  
>  PYGRUB_VER = 0.6
> +fs_read_max=1048576

All other constants in the global scope are in all caps. "1024 * 1024"
is a bit more readable.

>  def enable_cursor(ison):
>      if ison:
> @@ -448,7 +449,8 @@
>          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)
>  
> @@ -697,6 +699,39 @@
>      def usage():
>          print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] [--output-directory=] [--output-format=sxp|simple|simple0] <image>" %(sys.argv[0],)
>  
> +    def copy_from_image(fs, file_to_read, file_type, output_directory,
> +                                              not_really, clean_extra_file):

Could the indention here follow PEP-8 [1] guidelines?

> +        if not_really:
> +            if fs.file_exists(file_to_read):
> +                return "<%s:%s>" % (file_type,file_to_read)

missing space after ,

> +            else:
> +                sys.exit("The requested %s file does not exist" % file_type)
> +        try:
> +            datafile = fs.open_file(file_to_read)
> +        except:

I personally don't like the pattern of:
    try:
        ...
    except:
        ...
There's a lot of opportunity to hide exceptions other than those that
you'd expect. At minimum, I'd capture the exception and try to add it
to the error message.

> +            if clean_extra_file:
> +                os.unlink(clean_extra_file)

It would seem that you're pushing a cleanup task to the innermost
function. Shouldn't it be the responsibility of the caller to clean up
on an exception?

> +            sys.exit("Error opening %s" % file_to_read)
> +        (tfd, ret) = tempfile.mkstemp(prefix="boot_"+file_type+".",
> +                                                       dir=output_directory)

Fix indention to be PEP-8.

> +        dataoff=0
> +        while True:
> +            data=datafile.read(fs_read_max,dataoff)

Missing space after ,
Missing spaces before and after =

> +            if len(data) == 0:
> +                os.close(tfd)
> +                del datafile
> +                return ret
> +            try:
> +                os.write(tfd, data)
> +            except:

try: ... except: again can make us blind to unexpected errors. At
minimum capture the error and include it in the exit string.

> +                os.close(tfd)
> +                os.unlink(ret)
> +                del datafile
> +                if clean_extra_file:
> +                    os.unlink(clean_extra_file)
> +                sys.exit("error writing temporary copy of "+file_type)
> +            dataoff+=len(data)

Spaces before and after +=

> +
>      try:
>          opts, args = getopt.gnu_getopt(sys.argv[1:], 'qinh::',
>                                     ["quiet", "interactive", "not-really", "help", 
> @@ -821,24 +856,12 @@
>      if not fs:
>          raise RuntimeError, "Unable to find partition containing kernel"
>  
> -    if not_really:
> -        bootcfg["kernel"] = "<kernel:%s>" % chosencfg["kernel"]
> -    else:
> -        data = fs.open_file(chosencfg["kernel"]).read()
> -        (tfd, bootcfg["kernel"]) = tempfile.mkstemp(prefix="boot_kernel.",
> -                                                    dir=output_directory)
> -        os.write(tfd, data)
> -        os.close(tfd)
> +    bootcfg["kernel"] = copy_from_image(fs, chosencfg["kernel"], 
> +                              "kernel", output_directory, not_really, "")

PEP-8 indention

>  
>      if chosencfg["ramdisk"]:
> -        if not_really:
> -            bootcfg["ramdisk"] = "<ramdisk:%s>" % chosencfg["ramdisk"]
> -        else:
> -            data = fs.open_file(chosencfg["ramdisk"],).read()
> -            (tfd, bootcfg["ramdisk"]) = tempfile.mkstemp(
> -                prefix="boot_ramdisk.", dir=output_directory)
> -            os.write(tfd, data)
> -            os.close(tfd)
> +        bootcfg["ramdisk"] = copy_from_image(fs, chosencfg["ramdisk"],
> +              "ramdisk", output_directory, not_really, bootcfg["kernel"])

PEP-8 indention. This seems to be the place that should be cleaning up
images on error. E.g.:

    try:
        bootcfg["ramdisk"] = copy_from_image(fs, chosencfg["ramdisk"],
                                             "ramdisk", output_directory,
                                             not_really)
    except Exception, e:
        exc_info = sys.exc_info()
        try:
	    os.unlink(bootcfg["kernel"])
        except Exception, e:
	    # log an error
        # re-raise original exception
        raise exc_info[0], exc_info[1], exc_into[2]


Re-raising the exception is the fancy thing to do. If we don't care
if os.unlink() raises an exception, you could leave off the inner
try: and just use "raise" to re-raise.

>      else:
>          initrd = None
>  

Matt

[1] http://www.python.org/dev/peps/pep-0008/#indentation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 00:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 00: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 1SjJPm-0007kW-6X; Tue, 26 Jun 2012 00:13:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SjJPl-0007kR-22
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 00:13:53 +0000
Received: from [85.158.139.83:31154] by server-1.bemta-5.messagelabs.com id
	CD/84-19721-0CEF8EF4; Tue, 26 Jun 2012 00:13:52 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340669627!26748408!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk1MzU2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6810 invoked from network); 26 Jun 2012 00:13:50 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 00:13:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340669630; x=1372205630;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=jS1X2FifBsjwjSfkVgZHgXtSyfJpKW3FnPOrFO3t7Ks=;
	b=KUTUzxZGOPPVEY5aBX4ki0mhNvCPdunUVQHXDM7wcAdXls7O5Zyuedy7
	bWkmLcpXZP/tkScNFEGk8ZyO/mcV/Q==;
X-IronPort-AV: E=Sophos;i="4.77,475,1336348800"; d="scan'208";a="987451191"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2012 00:13:32 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5Q0DMgN031351
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 26 Jun 2012 00:13:22 GMT
Received: from US-SEA-R8XVZTX (10.224.80.34) by ex10-hub-31006.ant.amazon.com
	(10.185.176.13) with Microsoft SMTP Server id 14.2.247.3;
	Mon, 25 Jun 2012 17:13:21 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Mon, 25 Jun 2012
	17:13:21 -0700
Date: Mon, 25 Jun 2012 17:13:21 -0700
From: Matt Wilson <msw@amazon.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120626001321.GC8088@US-SEA-R8XVZTX>
References: <4FE4BB5F.5000103@citrix.com>
	<1340615266.3832.12.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1206251111430.7883@algedi.dur.ac.uk>
	<1340621572.3832.13.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1206252215180.4133@vega-c.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1206252215180.4133@vega-c.dur.ac.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
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] pygrub: avoid problems if guest files are large etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 25, 2012 at 02:34:02PM -0700, M A Young wrote:
> On Mon, 25 Jun 2012, Ian Campbell wrote:
> 
> > BTW, what is the status of that patch?
> 
> I am attaching version 4 of my patch. It moves handling of the kernel and 
> ramdisk into a function along the lines of Miroslav Rezanina's patch
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg01499.html
> It adds checking for problems opening the kernel or ramdisk files and 
> checks they exist in the not_really mode as discussed in this thread.
> 
> I still think it is a good idea to remove the temporary copies of the 
> kernel and ramdisk if there are problems copying them because I am not 
> convinced the calling process always removes them and it might be 
> presented with truncated files if copying the files filled the filespace.
> 
>  	Michael Young
>
> Make pygrub cope better with big files in the guest.
> Only read the first megabyte of a configuration file (grub etc.) and read
> the kernel and ramdisk files from the guest in one megabyte pieces
> so pygrub doesn't use a lot of memory if the files are large.
> With --not-really option check that the chosen kernel and ramdisk files exist.
> If there are problems writing the copy of the kernel or ramdisk, delete the
> copied files and exit in case they have filled the filesystem.
> 
> Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
> 
> --- xen-4.2.0/tools/pygrub/src/pygrub.orig	2012-05-12 16:40:48.000000000 +0100
> +++ xen-4.2.0/tools/pygrub/src/pygrub	2012-06-25 21:53:49.556446369 +0100
> @@ -28,6 +28,7 @@
>  import grub.ExtLinuxConf
>  
>  PYGRUB_VER = 0.6
> +fs_read_max=1048576

All other constants in the global scope are in all caps. "1024 * 1024"
is a bit more readable.

>  def enable_cursor(ison):
>      if ison:
> @@ -448,7 +449,8 @@
>          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)
>  
> @@ -697,6 +699,39 @@
>      def usage():
>          print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] [--output-directory=] [--output-format=sxp|simple|simple0] <image>" %(sys.argv[0],)
>  
> +    def copy_from_image(fs, file_to_read, file_type, output_directory,
> +                                              not_really, clean_extra_file):

Could the indention here follow PEP-8 [1] guidelines?

> +        if not_really:
> +            if fs.file_exists(file_to_read):
> +                return "<%s:%s>" % (file_type,file_to_read)

missing space after ,

> +            else:
> +                sys.exit("The requested %s file does not exist" % file_type)
> +        try:
> +            datafile = fs.open_file(file_to_read)
> +        except:

I personally don't like the pattern of:
    try:
        ...
    except:
        ...
There's a lot of opportunity to hide exceptions other than those that
you'd expect. At minimum, I'd capture the exception and try to add it
to the error message.

> +            if clean_extra_file:
> +                os.unlink(clean_extra_file)

It would seem that you're pushing a cleanup task to the innermost
function. Shouldn't it be the responsibility of the caller to clean up
on an exception?

> +            sys.exit("Error opening %s" % file_to_read)
> +        (tfd, ret) = tempfile.mkstemp(prefix="boot_"+file_type+".",
> +                                                       dir=output_directory)

Fix indention to be PEP-8.

> +        dataoff=0
> +        while True:
> +            data=datafile.read(fs_read_max,dataoff)

Missing space after ,
Missing spaces before and after =

> +            if len(data) == 0:
> +                os.close(tfd)
> +                del datafile
> +                return ret
> +            try:
> +                os.write(tfd, data)
> +            except:

try: ... except: again can make us blind to unexpected errors. At
minimum capture the error and include it in the exit string.

> +                os.close(tfd)
> +                os.unlink(ret)
> +                del datafile
> +                if clean_extra_file:
> +                    os.unlink(clean_extra_file)
> +                sys.exit("error writing temporary copy of "+file_type)
> +            dataoff+=len(data)

Spaces before and after +=

> +
>      try:
>          opts, args = getopt.gnu_getopt(sys.argv[1:], 'qinh::',
>                                     ["quiet", "interactive", "not-really", "help", 
> @@ -821,24 +856,12 @@
>      if not fs:
>          raise RuntimeError, "Unable to find partition containing kernel"
>  
> -    if not_really:
> -        bootcfg["kernel"] = "<kernel:%s>" % chosencfg["kernel"]
> -    else:
> -        data = fs.open_file(chosencfg["kernel"]).read()
> -        (tfd, bootcfg["kernel"]) = tempfile.mkstemp(prefix="boot_kernel.",
> -                                                    dir=output_directory)
> -        os.write(tfd, data)
> -        os.close(tfd)
> +    bootcfg["kernel"] = copy_from_image(fs, chosencfg["kernel"], 
> +                              "kernel", output_directory, not_really, "")

PEP-8 indention

>  
>      if chosencfg["ramdisk"]:
> -        if not_really:
> -            bootcfg["ramdisk"] = "<ramdisk:%s>" % chosencfg["ramdisk"]
> -        else:
> -            data = fs.open_file(chosencfg["ramdisk"],).read()
> -            (tfd, bootcfg["ramdisk"]) = tempfile.mkstemp(
> -                prefix="boot_ramdisk.", dir=output_directory)
> -            os.write(tfd, data)
> -            os.close(tfd)
> +        bootcfg["ramdisk"] = copy_from_image(fs, chosencfg["ramdisk"],
> +              "ramdisk", output_directory, not_really, bootcfg["kernel"])

PEP-8 indention. This seems to be the place that should be cleaning up
images on error. E.g.:

    try:
        bootcfg["ramdisk"] = copy_from_image(fs, chosencfg["ramdisk"],
                                             "ramdisk", output_directory,
                                             not_really)
    except Exception, e:
        exc_info = sys.exc_info()
        try:
	    os.unlink(bootcfg["kernel"])
        except Exception, e:
	    # log an error
        # re-raise original exception
        raise exc_info[0], exc_info[1], exc_into[2]


Re-raising the exception is the fancy thing to do. If we don't care
if os.unlink() raises an exception, you could leave off the inner
try: and just use "raise" to re-raise.

>      else:
>          initrd = None
>  

Matt

[1] http://www.python.org/dev/peps/pep-0008/#indentation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 02:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 02: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 1SjLZC-0005On-Cx; Tue, 26 Jun 2012 02:31:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjLZA-0005Oi-DN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 02:31:44 +0000
Received: from [85.158.139.83:3467] by server-1.bemta-5.messagelabs.com id
	08/C5-19721-F0F19EF4; Tue, 26 Jun 2012 02:31:43 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340677901!18212142!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8719 invoked from network); 26 Jun 2012 02:31:42 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 02:31:42 -0000
Received: by obbta14 with SMTP id ta14so9913501obb.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 19:31:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=LDG4wEhC0pndVsaGBDYhOY/Pg9hag5qsEPxOkYcC9qQ=;
	b=R2MEKcEIueGYj4H6ZSS0WXw9s3MOQx/7WulinnJOuyF3X/3QZ8Igl10ELxQy81iB6L
	P/u1JhnlxQpUFO6Q58e8my9xQByk2tHdZ6rSvpbVokZC9HnVjyKt8yXv2j5QZMM5PJpp
	4qhTXAYmIM+DuGycq1n0VzEP00DxLNtI197UB8GK7Yg1T8C3ktu6ArV7MnQT1Kf6tAAn
	ZmXXOVeoZISYHuNXi+4OYbc7ayOifVci75RYvkboCrc2PnVun0YkFdshFAjykVFc3W3r
	pUxNgZaJQFhNmHGsOU5pso43pmGiCWf4ohMzUi3LgPpXp9MahLFbclT0V/v087NF9jdr
	zTuw==
Received: by 10.60.29.72 with SMTP id i8mr14501124oeh.26.1340677900961; Mon,
	25 Jun 2012 19:31:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 25 Jun 2012 19:31:20 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Tue, 26 Jun 2012 04:31:20 +0200
Message-ID: <CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQluDQvpzpwCEt6wZxTicZU9AaD6Wlk185V5tEVHv/3GBYfj5xJlnhyLbkPyG2mnf4BJGnyQ
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 25 Jun 2012, Jan Beulich wrote:
>> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
>> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> At the same time, adding logging to the guest kernel would
>> >> be nice, to see what value it actually writes (in a current
>> >> kernel this would be in __write_msi_msg()).
>> >>
>> >
>> > Turns out that msg->data here is also 0x4300, so it seems the guest
>> > kernel is producing these values. I caused it to make a stack trace
>> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
>> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
>> > current data field and if it isn't equal to the macro it uses
>> > xen_msi_compose_msg to make a new message, but that function just sets
>> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
>> > then gets passed to __write_msi_msg and that's that. There are no
>> > other writes through __write_msi_msg (except for the same thing for
>> > other devices).
>> >
>> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
>> > decoded as the delivery mode, so it seems the kernel is intentionally
>> > setting it to 3.
>>
>> So that can never have worked properly afaict. Stefano, the
>> code as it is currently - using literal (3 << 8) - is clearly bogus.
>> Your original commit at least had a comment saying that the
>> reserved delivery mode encoding is intentional here, but that
>> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
>> In any case - the cooperation with qemu apparently doesn't
>> work, as the reserved encoding should never make it through
>> to the hypervisor. Could you explain what the intention here
>> was?
>>
>> And regardless of anything, can the literal numbers please be
>> replaced by proper manifest constants - the "8" here already
>> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
>> proper symbolic would permit locating where this is being (or
>> really, as it doesn't appear to work supposed to be) consumed
>> in qemu, provided it uses the same definition (i.e. that one
>> should go into one of the public headers).
>
> The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
> because notifications are not supposed to be delivered as MSI anymore.
>
> This is what should happen:
>
> 1) Linux configures the device with a 0 vector number and the pirq number
> in the address field;
>
> 2) QEMU notices a vector number of 0 and reads the pirq number from the
> address field, passing it to xc_domain_update_msi_irq;
>
> 3) Xen assignes the given pirq to the physical MSI;
>
> 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>
> 5) Xen sets the pirq as "IRQ_PT";
>
> 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
> returns true so Xen calls send_guest_pirq instead.
>
>
> Obviously 6) is not happening. hvm_domain_use_pirq is:
>
> is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
>
> My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
> above).

This appears to be true. I added logging to hvm_pci_msi_assert in
xen/drivers/passthrough/io.c and it indicates that
pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
before an unsupported delivery mode message.

I also log pirq->pirq but I found that most of the time I can't find
this value anywhere else (I'm not sure how to interpret the value,
though). For example, in my last try:

* I get an unsupported delivery mode error for pirq->pirq 55, 54 and
53. The vast majority are for 54.
* I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
but complains it's already mapped.
* I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
22, 52, 48, 47. Also never 54 or 53.
* map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
* The qemu log mentions pirq 35, 36 and 37

It seems pirq values don't always mean the same? Is it a coincidence
that 55 occurs almost everywhere, or is something going wrong with the
other two values (53 and 54 versus 16 and 17)?

I have three MSI capable devices passed through to the domU, and I do
see groups of three distinct pirqs in the data above - just not the
same ones in every place I look.

> So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
> (__startup_pirq doesn't get called), or Xen is erroring out in
> map_domain_emuirq_pirq.

evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.

map_domain_emuirq_pirq always gets past the checks in the top half
(i.e. up to the line /* do not store emuirq mappings for pt devices
*/), except for one time with pirq=49,emuirq=23 where it finds they
are already mapped.
It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
This implies their info->arch.hvm.emuirq is also set to -2 (haven't
directly logged that but it's the only assignment there).

Interestingly, I get an unsupported delivery mode error for pirq 55
where my logging says pirq->arch.hvm.emuirq is -1, *after*
map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 02:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 02: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 1SjLZC-0005On-Cx; Tue, 26 Jun 2012 02:31:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjLZA-0005Oi-DN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 02:31:44 +0000
Received: from [85.158.139.83:3467] by server-1.bemta-5.messagelabs.com id
	08/C5-19721-F0F19EF4; Tue, 26 Jun 2012 02:31:43 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340677901!18212142!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8719 invoked from network); 26 Jun 2012 02:31:42 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 02:31:42 -0000
Received: by obbta14 with SMTP id ta14so9913501obb.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 19:31:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=LDG4wEhC0pndVsaGBDYhOY/Pg9hag5qsEPxOkYcC9qQ=;
	b=R2MEKcEIueGYj4H6ZSS0WXw9s3MOQx/7WulinnJOuyF3X/3QZ8Igl10ELxQy81iB6L
	P/u1JhnlxQpUFO6Q58e8my9xQByk2tHdZ6rSvpbVokZC9HnVjyKt8yXv2j5QZMM5PJpp
	4qhTXAYmIM+DuGycq1n0VzEP00DxLNtI197UB8GK7Yg1T8C3ktu6ArV7MnQT1Kf6tAAn
	ZmXXOVeoZISYHuNXi+4OYbc7ayOifVci75RYvkboCrc2PnVun0YkFdshFAjykVFc3W3r
	pUxNgZaJQFhNmHGsOU5pso43pmGiCWf4ohMzUi3LgPpXp9MahLFbclT0V/v087NF9jdr
	zTuw==
Received: by 10.60.29.72 with SMTP id i8mr14501124oeh.26.1340677900961; Mon,
	25 Jun 2012 19:31:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 25 Jun 2012 19:31:20 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Tue, 26 Jun 2012 04:31:20 +0200
Message-ID: <CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQluDQvpzpwCEt6wZxTicZU9AaD6Wlk185V5tEVHv/3GBYfj5xJlnhyLbkPyG2mnf4BJGnyQ
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 25 Jun 2012, Jan Beulich wrote:
>> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
>> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> At the same time, adding logging to the guest kernel would
>> >> be nice, to see what value it actually writes (in a current
>> >> kernel this would be in __write_msi_msg()).
>> >>
>> >
>> > Turns out that msg->data here is also 0x4300, so it seems the guest
>> > kernel is producing these values. I caused it to make a stack trace
>> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
>> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
>> > current data field and if it isn't equal to the macro it uses
>> > xen_msi_compose_msg to make a new message, but that function just sets
>> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
>> > then gets passed to __write_msi_msg and that's that. There are no
>> > other writes through __write_msi_msg (except for the same thing for
>> > other devices).
>> >
>> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
>> > decoded as the delivery mode, so it seems the kernel is intentionally
>> > setting it to 3.
>>
>> So that can never have worked properly afaict. Stefano, the
>> code as it is currently - using literal (3 << 8) - is clearly bogus.
>> Your original commit at least had a comment saying that the
>> reserved delivery mode encoding is intentional here, but that
>> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
>> In any case - the cooperation with qemu apparently doesn't
>> work, as the reserved encoding should never make it through
>> to the hypervisor. Could you explain what the intention here
>> was?
>>
>> And regardless of anything, can the literal numbers please be
>> replaced by proper manifest constants - the "8" here already
>> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
>> proper symbolic would permit locating where this is being (or
>> really, as it doesn't appear to work supposed to be) consumed
>> in qemu, provided it uses the same definition (i.e. that one
>> should go into one of the public headers).
>
> The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
> because notifications are not supposed to be delivered as MSI anymore.
>
> This is what should happen:
>
> 1) Linux configures the device with a 0 vector number and the pirq number
> in the address field;
>
> 2) QEMU notices a vector number of 0 and reads the pirq number from the
> address field, passing it to xc_domain_update_msi_irq;
>
> 3) Xen assignes the given pirq to the physical MSI;
>
> 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>
> 5) Xen sets the pirq as "IRQ_PT";
>
> 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
> returns true so Xen calls send_guest_pirq instead.
>
>
> Obviously 6) is not happening. hvm_domain_use_pirq is:
>
> is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
>
> My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
> above).

This appears to be true. I added logging to hvm_pci_msi_assert in
xen/drivers/passthrough/io.c and it indicates that
pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
before an unsupported delivery mode message.

I also log pirq->pirq but I found that most of the time I can't find
this value anywhere else (I'm not sure how to interpret the value,
though). For example, in my last try:

* I get an unsupported delivery mode error for pirq->pirq 55, 54 and
53. The vast majority are for 54.
* I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
but complains it's already mapped.
* I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
22, 52, 48, 47. Also never 54 or 53.
* map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
* The qemu log mentions pirq 35, 36 and 37

It seems pirq values don't always mean the same? Is it a coincidence
that 55 occurs almost everywhere, or is something going wrong with the
other two values (53 and 54 versus 16 and 17)?

I have three MSI capable devices passed through to the domU, and I do
see groups of three distinct pirqs in the data above - just not the
same ones in every place I look.

> So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
> (__startup_pirq doesn't get called), or Xen is erroring out in
> map_domain_emuirq_pirq.

evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.

map_domain_emuirq_pirq always gets past the checks in the top half
(i.e. up to the line /* do not store emuirq mappings for pt devices
*/), except for one time with pirq=49,emuirq=23 where it finds they
are already mapped.
It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
This implies their info->arch.hvm.emuirq is also set to -2 (haven't
directly logged that but it's the only assignment there).

Interestingly, I get an unsupported delivery mode error for pirq 55
where my logging says pirq->arch.hvm.emuirq is -1, *after*
map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 02:39:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 02:39: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 1SjLfr-0005ZN-8W; Tue, 26 Jun 2012 02:38:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1SjLfp-0005ZG-0f
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 02:38:37 +0000
Received: from [85.158.143.99:33004] by server-2.bemta-4.messagelabs.com id
	E6/07-17938-CA029EF4; Tue, 26 Jun 2012 02:38:36 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340678315!19312551!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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16557 invoked from network); 26 Jun 2012 02:38:35 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 02:38:35 -0000
Received: by lbok6 with SMTP id k6so9210136lbo.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 19:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=NOLqTDg3NwumVgjrbL2CcZKOavZUBrx4AznloVjCaIM=;
	b=zmh1iAo/4UKedochUqJCS6txC1tqAz67OAzGopjuvytWdZsa/iSSRwXOPzoZqt7ki9
	gRuns6nIqbVHgQTwYCFUO+mkZmqLtvlYqLMxWB65xSYfYdA8KmIPV+r97h2Nk9uWg/+Z
	YKj7Q/Q/Re6IKZqru1gY/XWNJbsPWiFzM3aM8VnR/udjWLZMYEI0N8gRNhzRlvGGT9IW
	1+vrq0cMOWJsp94DZqKgJo8F7LwWLI2ApLa1Hf5UE0Ix9A7zMZkbk7ptCFSN5IBu0pnS
	kechEU/ZFi9n/z5s10tIGYD+/E4lhWpijkx56pmZeBhDM/rrG4D+etuW5+k62IPaWs9S
	EI5Q==
MIME-Version: 1.0
Received: by 10.152.104.77 with SMTP id gc13mr14199288lab.31.1340678314623;
	Mon, 25 Jun 2012 19:38:34 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Mon, 25 Jun 2012 19:38:34 -0700 (PDT)
Date: Mon, 25 Jun 2012 19:38:34 -0700
Message-ID: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] MSI message data register configuration in Xen 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, I was playing around with a MSI capable virtual device (so far
submitted as patches only) in the upstream qemu tree but having
trouble getting it to work on a Xen hvm guest. The device happens to
be a QEMU implementation of VMWare's pvscsi controller.=A0The device
works fine in a Xen guest when I switch the device's=A0code to force
usage of legacy interrupts with upstream QEMU. With MSI based
interrupts, the device works fine on a KVM guest but as stated before,
not on a Xen guest. After digging a bit, it appears, the reason for
the failure in Xen guests is that the MSI data register in the Xen
guest ends up with a value of 4300 where the Deliver Mode value of 3
happens to be reserved (per spec) and therefore illegal. The
vmsi_deliver routine in Xen rejects MSI interrupts with such data as
illegal (per expectation) causing all commands issued by the guest OS
on the device to timeout.

Given this above scenario, I was wondering if anyone can shed some
light on how to debug this further for Xen. Something I would
specifically like to know is where the MSI data register configuration
actually happens. Is it done by some code specific to Xen and within
the Xen codebase or it all done within QEMU?

Thanks,
Deep

P.S. some details on the device's PCI configuration:

lspci output for a working instance in KVM:

00:07.0 SCSI storage controller: VMware PVSCSI SCSI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 255
Interrupt: pin A routed to IRQ 45
Region 0: Memory at febf0000 (32-bit, non-prefetchable) [size=3D32K]
Capabilities: [50] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Address: 00000000fee0300c =A0Data: 4161
Kernel driver in use: vmw_pvscsi
Kernel modules: vmw_pvscsi

Here is the lspci output for the scenario where it's failing to work in Xen:

00:04.0 SCSI storage controller: VMware PVSCSI SCSI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 255
Interrupt: pin A routed to IRQ 80
Region 0: Memory at f3020000 (32-bit, non-prefetchable) [size=3D32K]
Capabilities: [50] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Address: 00000000fee36000 =A0Data: 4300
Kernel driver in use: vmw_pvscsi
Kernel modules: vmw_pvscsi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 02:39:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 02:39: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 1SjLfr-0005ZN-8W; Tue, 26 Jun 2012 02:38:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1SjLfp-0005ZG-0f
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 02:38:37 +0000
Received: from [85.158.143.99:33004] by server-2.bemta-4.messagelabs.com id
	E6/07-17938-CA029EF4; Tue, 26 Jun 2012 02:38:36 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340678315!19312551!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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16557 invoked from network); 26 Jun 2012 02:38:35 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 02:38:35 -0000
Received: by lbok6 with SMTP id k6so9210136lbo.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 19:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=NOLqTDg3NwumVgjrbL2CcZKOavZUBrx4AznloVjCaIM=;
	b=zmh1iAo/4UKedochUqJCS6txC1tqAz67OAzGopjuvytWdZsa/iSSRwXOPzoZqt7ki9
	gRuns6nIqbVHgQTwYCFUO+mkZmqLtvlYqLMxWB65xSYfYdA8KmIPV+r97h2Nk9uWg/+Z
	YKj7Q/Q/Re6IKZqru1gY/XWNJbsPWiFzM3aM8VnR/udjWLZMYEI0N8gRNhzRlvGGT9IW
	1+vrq0cMOWJsp94DZqKgJo8F7LwWLI2ApLa1Hf5UE0Ix9A7zMZkbk7ptCFSN5IBu0pnS
	kechEU/ZFi9n/z5s10tIGYD+/E4lhWpijkx56pmZeBhDM/rrG4D+etuW5+k62IPaWs9S
	EI5Q==
MIME-Version: 1.0
Received: by 10.152.104.77 with SMTP id gc13mr14199288lab.31.1340678314623;
	Mon, 25 Jun 2012 19:38:34 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Mon, 25 Jun 2012 19:38:34 -0700 (PDT)
Date: Mon, 25 Jun 2012 19:38:34 -0700
Message-ID: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] MSI message data register configuration in Xen 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, I was playing around with a MSI capable virtual device (so far
submitted as patches only) in the upstream qemu tree but having
trouble getting it to work on a Xen hvm guest. The device happens to
be a QEMU implementation of VMWare's pvscsi controller.=A0The device
works fine in a Xen guest when I switch the device's=A0code to force
usage of legacy interrupts with upstream QEMU. With MSI based
interrupts, the device works fine on a KVM guest but as stated before,
not on a Xen guest. After digging a bit, it appears, the reason for
the failure in Xen guests is that the MSI data register in the Xen
guest ends up with a value of 4300 where the Deliver Mode value of 3
happens to be reserved (per spec) and therefore illegal. The
vmsi_deliver routine in Xen rejects MSI interrupts with such data as
illegal (per expectation) causing all commands issued by the guest OS
on the device to timeout.

Given this above scenario, I was wondering if anyone can shed some
light on how to debug this further for Xen. Something I would
specifically like to know is where the MSI data register configuration
actually happens. Is it done by some code specific to Xen and within
the Xen codebase or it all done within QEMU?

Thanks,
Deep

P.S. some details on the device's PCI configuration:

lspci output for a working instance in KVM:

00:07.0 SCSI storage controller: VMware PVSCSI SCSI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 255
Interrupt: pin A routed to IRQ 45
Region 0: Memory at febf0000 (32-bit, non-prefetchable) [size=3D32K]
Capabilities: [50] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Address: 00000000fee0300c =A0Data: 4161
Kernel driver in use: vmw_pvscsi
Kernel modules: vmw_pvscsi

Here is the lspci output for the scenario where it's failing to work in Xen:

00:04.0 SCSI storage controller: VMware PVSCSI SCSI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 255
Interrupt: pin A routed to IRQ 80
Region 0: Memory at f3020000 (32-bit, non-prefetchable) [size=3D32K]
Capabilities: [50] MSI: Enable+ Count=3D1/1 Maskable- 64bit+
Address: 00000000fee36000 =A0Data: 4300
Kernel driver in use: vmw_pvscsi
Kernel modules: vmw_pvscsi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 02:52:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 02:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjLsg-0005m6-Oy; Tue, 26 Jun 2012 02:51:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjLsf-0005m1-T0
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 02:51:54 +0000
Received: from [85.158.138.51:44624] by server-3.bemta-3.messagelabs.com id
	AC/6B-26490-9C329EF4; Tue, 26 Jun 2012 02:51:53 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340679111!29395832!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5379 invoked from network); 26 Jun 2012 02:51:52 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 02:51:52 -0000
Received: by obbta14 with SMTP id ta14so9942340obb.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 19:51:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=ItH9+JrKKmZMLR7mU56RVvl/mJcrjGMj9Z6HsQYHq+s=;
	b=PSR/kV6VBXaDpNoYAEazmIIzE8QMKB/4UMYR9E5EQRkDy7A9lAyVqkuTRpOI0HlJQl
	QiDfxEyu1fLR5L0Oks6yy+WN98A48M1yyfTBRMA/vRacQ1c1OukVg9uVcbb5w+3znIEc
	kWWfUyVoVbR3HlJZsiy7Aku20zDRSGOcaGdlRLPo31gm1Jtta5hvAHGwhme1Dd4oZyQ1
	W+UHFkC9SarBQtp8VUEJYplX2PpkhjVsEr6oxnUaJfxyRXK0YCwTU0bSFVTU0uLdr7Pr
	E7IiuysUIUwt6E0B0wbryxauKzouTduq4ZXHhdz5A7SjHN5sJS1uU8lydlU0cggT2D7K
	cekw==
Received: by 10.60.19.226 with SMTP id i2mr14475781oee.20.1340679110642; Mon,
	25 Jun 2012 19:51:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 25 Jun 2012 19:51:29 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Tue, 26 Jun 2012 04:51:29 +0200
Message-ID: <CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
To: Deep Debroy <ddebroy@gmail.com>
X-Gm-Message-State: ALoCoQn0u8nKZT1IfLOKfXNJ0gpBsufztkaMgReuSS0scWATt+ICKk174OHku0FwSIRldr2/quch
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> Hi, I was playing around with a MSI capable virtual device (so far
> submitted as patches only) in the upstream qemu tree but having
> trouble getting it to work on a Xen hvm guest. The device happens to
> be a QEMU implementation of VMWare's pvscsi controller.=A0The device
> works fine in a Xen guest when I switch the device's=A0code to force
> usage of legacy interrupts with upstream QEMU. With MSI based
> interrupts, the device works fine on a KVM guest but as stated before,
> not on a Xen guest. After digging a bit, it appears, the reason for
> the failure in Xen guests is that the MSI data register in the Xen
> guest ends up with a value of 4300 where the Deliver Mode value of 3
> happens to be reserved (per spec) and therefore illegal. The
> vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> illegal (per expectation) causing all commands issued by the guest OS
> on the device to timeout.
>
> Given this above scenario, I was wondering if anyone can shed some
> light on how to debug this further for Xen. Something I would
> specifically like to know is where the MSI data register configuration
> actually happens. Is it done by some code specific to Xen and within
> the Xen codebase or it all done within QEMU?
>

This seems like the same issue I ran into, though in my case it is
with passed through physical devices. See
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
the older messages in that thread for more info on what's going on. No
fix yet but help debugging is very welcome.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 02:52:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 02:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjLsg-0005m6-Oy; Tue, 26 Jun 2012 02:51:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjLsf-0005m1-T0
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 02:51:54 +0000
Received: from [85.158.138.51:44624] by server-3.bemta-3.messagelabs.com id
	AC/6B-26490-9C329EF4; Tue, 26 Jun 2012 02:51:53 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340679111!29395832!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5379 invoked from network); 26 Jun 2012 02:51:52 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 02:51:52 -0000
Received: by obbta14 with SMTP id ta14so9942340obb.32
	for <xen-devel@lists.xen.org>; Mon, 25 Jun 2012 19:51:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=ItH9+JrKKmZMLR7mU56RVvl/mJcrjGMj9Z6HsQYHq+s=;
	b=PSR/kV6VBXaDpNoYAEazmIIzE8QMKB/4UMYR9E5EQRkDy7A9lAyVqkuTRpOI0HlJQl
	QiDfxEyu1fLR5L0Oks6yy+WN98A48M1yyfTBRMA/vRacQ1c1OukVg9uVcbb5w+3znIEc
	kWWfUyVoVbR3HlJZsiy7Aku20zDRSGOcaGdlRLPo31gm1Jtta5hvAHGwhme1Dd4oZyQ1
	W+UHFkC9SarBQtp8VUEJYplX2PpkhjVsEr6oxnUaJfxyRXK0YCwTU0bSFVTU0uLdr7Pr
	E7IiuysUIUwt6E0B0wbryxauKzouTduq4ZXHhdz5A7SjHN5sJS1uU8lydlU0cggT2D7K
	cekw==
Received: by 10.60.19.226 with SMTP id i2mr14475781oee.20.1340679110642; Mon,
	25 Jun 2012 19:51:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Mon, 25 Jun 2012 19:51:29 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
From: Rolu <rolu@roce.org>
Date: Tue, 26 Jun 2012 04:51:29 +0200
Message-ID: <CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
To: Deep Debroy <ddebroy@gmail.com>
X-Gm-Message-State: ALoCoQn0u8nKZT1IfLOKfXNJ0gpBsufztkaMgReuSS0scWATt+ICKk174OHku0FwSIRldr2/quch
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> Hi, I was playing around with a MSI capable virtual device (so far
> submitted as patches only) in the upstream qemu tree but having
> trouble getting it to work on a Xen hvm guest. The device happens to
> be a QEMU implementation of VMWare's pvscsi controller.=A0The device
> works fine in a Xen guest when I switch the device's=A0code to force
> usage of legacy interrupts with upstream QEMU. With MSI based
> interrupts, the device works fine on a KVM guest but as stated before,
> not on a Xen guest. After digging a bit, it appears, the reason for
> the failure in Xen guests is that the MSI data register in the Xen
> guest ends up with a value of 4300 where the Deliver Mode value of 3
> happens to be reserved (per spec) and therefore illegal. The
> vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> illegal (per expectation) causing all commands issued by the guest OS
> on the device to timeout.
>
> Given this above scenario, I was wondering if anyone can shed some
> light on how to debug this further for Xen. Something I would
> specifically like to know is where the MSI data register configuration
> actually happens. Is it done by some code specific to Xen and within
> the Xen codebase or it all done within QEMU?
>

This seems like the same issue I ran into, though in my case it is
with passed through physical devices. See
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
the older messages in that thread for more info on what's going on. No
fix yet but help debugging is very welcome.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 05:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 05: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 1SjONE-0006lT-EU; Tue, 26 Jun 2012 05:31:36 +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 1SjONC-0006lO-Or
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 05:31:34 +0000
Received: from [85.158.138.51:42875] by server-12.bemta-3.messagelabs.com id
	D0/0D-30206-53949EF4; Tue, 26 Jun 2012 05:31:33 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340688692!29409548!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NTExMw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16358 invoked from network); 26 Jun 2012 05:31:33 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 05:31:33 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 25 Jun 2012 22:31:28 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="184973666"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 25 Jun 2012 22:31:28 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 22:31:28 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 22:31:28 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 13:31:27 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNUrFAT/njWom2N0+Is+zDJD5/bZcMEOKQ
Date: Tue, 26 Jun 2012 05:31:26 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
In-Reply-To: <20120625090201.GB1488@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Monday, June 25, 2012 5:02 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> 
> At 09:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
> > Changes from v1:
> > - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to
> patch2.
> > - define them as bool_t instead of int.
> >
> > Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
> > enable VMMs to efficiently implement memory management and page
> classification
> > algorithms to optimize VM memory operations.
> >
> > This series of patches enable EPT dirty bit feature for guest live migration.
> 
> Thanks for this.  I have a few high-level questions:
> 
> - You're proposing this for after 4.2, right?
> 

Yes, they are not targeted to 4.2.

> - Have you measured what difference this makes?  I take it it improves
>   performance during live migration but it would be good to know how much
>   before taking on extra code.
> 

We did live migration performance testing with patches, it's embarrassed to say but the result show there is no performance gain and no performance loss indeed.

> - Is this intended to replace the old log-dirty mechanism for vram
>   tracking as well?  It looks like it does that, but the description
>   doesn't mention it.
> 

Yes, it changes log-dirty mechanism for vram tracking when EPT dirty bit support, but it does not replace old log-dirty if no EPT dirty bit feature.
I'll add description after you further review.

> I'll be reviewing te patches in more detail later in the week.
> 

Thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 05:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 05: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 1SjONE-0006lT-EU; Tue, 26 Jun 2012 05:31:36 +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 1SjONC-0006lO-Or
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 05:31:34 +0000
Received: from [85.158.138.51:42875] by server-12.bemta-3.messagelabs.com id
	D0/0D-30206-53949EF4; Tue, 26 Jun 2012 05:31:33 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340688692!29409548!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NTExMw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16358 invoked from network); 26 Jun 2012 05:31:33 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 05:31:33 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 25 Jun 2012 22:31:28 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="184973666"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 25 Jun 2012 22:31:28 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 22:31:28 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 22:31:28 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.47]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.87]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 13:31:27 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNUrFAT/njWom2N0+Is+zDJD5/bZcMEOKQ
Date: Tue, 26 Jun 2012 05:31:26 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
In-Reply-To: <20120625090201.GB1488@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Monday, June 25, 2012 5:02 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> 
> At 09:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
> > Changes from v1:
> > - Move hap_has_dirty_bit and hap_has_access_bit definition from patch 3 to
> patch2.
> > - define them as bool_t instead of int.
> >
> > Extended Page Tables introduce two bit: access bit and dirty bit, A/D bits
> > enable VMMs to efficiently implement memory management and page
> classification
> > algorithms to optimize VM memory operations.
> >
> > This series of patches enable EPT dirty bit feature for guest live migration.
> 
> Thanks for this.  I have a few high-level questions:
> 
> - You're proposing this for after 4.2, right?
> 

Yes, they are not targeted to 4.2.

> - Have you measured what difference this makes?  I take it it improves
>   performance during live migration but it would be good to know how much
>   before taking on extra code.
> 

We did live migration performance testing with patches, it's embarrassed to say but the result show there is no performance gain and no performance loss indeed.

> - Is this intended to replace the old log-dirty mechanism for vram
>   tracking as well?  It looks like it does that, but the description
>   doesn't mention it.
> 

Yes, it changes log-dirty mechanism for vram tracking when EPT dirty bit support, but it does not replace old log-dirty if no EPT dirty bit feature.
I'll add description after you further review.

> I'll be reviewing te patches in more detail later in the week.
> 

Thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 06:02:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjOr3-00073Z-Uo; Tue, 26 Jun 2012 06:02:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SjOr2-00073U-KW
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:02:24 +0000
Received: from [193.109.254.147:50941] by server-8.bemta-14.messagelabs.com id
	DB/C3-30743-F6059EF4; Tue, 26 Jun 2012 06:02:23 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340690539!8551363!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1ODcz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14134 invoked from network); 26 Jun 2012 06:02:20 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 06:02:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 25 Jun 2012 23:02:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="116025729"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 25 Jun 2012 23:02:16 -0700
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; Mon, 25 Jun 2012 23:02:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 14:02:10 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 0/2] use standard VGA card with VBE by default when
	creating a hvm guest
Thread-Index: Ac1TYTbQW0nZ4tGkQNST0v7B/XTb4w==
Date: Tue, 26 Jun 2012 06:02:10 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FEA3D@SHSMSX101.ccr.corp.intel.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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] use standard VGA card with VBE by default
 when creating a hvm 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

libxl: set stdvga=1 by default when creating a hvm guest
Also, update the document: man page for xl.cfg


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 06:02:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjOr3-00073Z-Uo; Tue, 26 Jun 2012 06:02:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SjOr2-00073U-KW
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:02:24 +0000
Received: from [193.109.254.147:50941] by server-8.bemta-14.messagelabs.com id
	DB/C3-30743-F6059EF4; Tue, 26 Jun 2012 06:02:23 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340690539!8551363!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1ODcz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14134 invoked from network); 26 Jun 2012 06:02:20 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 06:02:20 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 25 Jun 2012 23:02:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="116025729"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 25 Jun 2012 23:02:16 -0700
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; Mon, 25 Jun 2012 23:02:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 14:02:10 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 0/2] use standard VGA card with VBE by default when
	creating a hvm guest
Thread-Index: Ac1TYTbQW0nZ4tGkQNST0v7B/XTb4w==
Date: Tue, 26 Jun 2012 06:02:10 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FEA3D@SHSMSX101.ccr.corp.intel.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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] use standard VGA card with VBE by default
 when creating a hvm 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

libxl: set stdvga=1 by default when creating a hvm guest
Also, update the document: man page for xl.cfg


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 06:03:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjOrK-00074G-Ai; Tue, 26 Jun 2012 06:02:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SjOrI-000744-NA
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:02:40 +0000
Received: from [85.158.143.99:49435] by server-3.bemta-4.messagelabs.com id
	26/A1-05808-08059EF4; Tue, 26 Jun 2012 06:02:40 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340690558!29081283!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1ODcz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17032 invoked from network); 26 Jun 2012 06:02:39 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-216.messagelabs.com with SMTP;
	26 Jun 2012 06:02:39 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Jun 2012 23:02:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="160717482"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by azsmga001.ch.intel.com with ESMTP; 25 Jun 2012 23:02:38 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 23:02:37 -0700
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; Mon, 25 Jun 2012 23:02:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 14:02:35 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
	guest
Thread-Index: Ac1TYUb9qkj/ISJ7SGCLemLA1RFKQg==
Date: Tue, 26 Jun 2012 06:02:35 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
	creating a hvm guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

libxl: set stdvga=3D1 by default when creating a hvm guest

Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x, Ubuntu, Fedor=
a) support VBE 2.0 or later.
So, select a standard VGA card with VBE as the default emulated graphics de=
vice.
It's also a workaround for the following bug.
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1812

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>

diff -r e08cf97e76f0 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jun 25 13:41:32 2012 +0200
+++ b/tools/libxl/libxl_create.c	Tue Jun 26 12:41:46 2012 +0800
@@ -248,7 +248,7 @@
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }
=20
-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, true);
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);


--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="stdvga-libxl.patch"
Content-Description: stdvga-libxl.patch
Content-Disposition: attachment; filename="stdvga-libxl.patch"; size=600;
	creation-date="Tue, 26 Jun 2012 04:42:51 GMT";
	modification-date="Tue, 26 Jun 2012 04:42:13 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBlMDhjZjk3ZTc2ZjAgdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMKLS0tIGEvdG9v
bHMvbGlieGwvbGlieGxfY3JlYXRlLmMJTW9uIEp1biAyNSAxMzo0MTozMiAyMDEyICswMjAwCisr
KyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCVR1ZSBKdW4gMjYgMTI6NDE6NDYgMjAxMiAr
MDgwMApAQCAtMjQ4LDcgKzI0OCw3IEBACiAgICAgICAgICAgICBpZiAoIWJfaW5mby0+dS5odm0u
Ym9vdCkgcmV0dXJuIEVSUk9SX05PTUVNOwogICAgICAgICB9CiAKLSAgICAgICAgbGlieGxfZGVm
Ym9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnN0ZHZnYSwgZmFsc2UpOworICAgICAgICBs
aWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJfaW5mby0+dS5odm0uc3RkdmdhLCB0cnVlKTsKICAg
ICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUs
IHRydWUpOwogICAgICAgICBpZiAobGlieGxfZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS52bmMu
ZW5hYmxlKSkgewogICAgICAgICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8t
PnUuaHZtLnZuYy5maW5kdW51c2VkLCB0cnVlKTsK

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 26 06:03:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjOrK-00074G-Ai; Tue, 26 Jun 2012 06:02:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SjOrI-000744-NA
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:02:40 +0000
Received: from [85.158.143.99:49435] by server-3.bemta-4.messagelabs.com id
	26/A1-05808-08059EF4; Tue, 26 Jun 2012 06:02:40 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340690558!29081283!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1ODcz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17032 invoked from network); 26 Jun 2012 06:02:39 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-216.messagelabs.com with SMTP;
	26 Jun 2012 06:02:39 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Jun 2012 23:02:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="160717482"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by azsmga001.ch.intel.com with ESMTP; 25 Jun 2012 23:02:38 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 23:02:37 -0700
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; Mon, 25 Jun 2012 23:02:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 14:02:35 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
	guest
Thread-Index: Ac1TYUb9qkj/ISJ7SGCLemLA1RFKQg==
Date: Tue, 26 Jun 2012 06:02:35 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
	creating a hvm guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

libxl: set stdvga=3D1 by default when creating a hvm guest

Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x, Ubuntu, Fedor=
a) support VBE 2.0 or later.
So, select a standard VGA card with VBE as the default emulated graphics de=
vice.
It's also a workaround for the following bug.
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=3D1812

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>

diff -r e08cf97e76f0 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jun 25 13:41:32 2012 +0200
+++ b/tools/libxl/libxl_create.c	Tue Jun 26 12:41:46 2012 +0800
@@ -248,7 +248,7 @@
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }
=20
-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, true);
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);


--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="stdvga-libxl.patch"
Content-Description: stdvga-libxl.patch
Content-Disposition: attachment; filename="stdvga-libxl.patch"; size=600;
	creation-date="Tue, 26 Jun 2012 04:42:51 GMT";
	modification-date="Tue, 26 Jun 2012 04:42:13 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBlMDhjZjk3ZTc2ZjAgdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMKLS0tIGEvdG9v
bHMvbGlieGwvbGlieGxfY3JlYXRlLmMJTW9uIEp1biAyNSAxMzo0MTozMiAyMDEyICswMjAwCisr
KyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCVR1ZSBKdW4gMjYgMTI6NDE6NDYgMjAxMiAr
MDgwMApAQCAtMjQ4LDcgKzI0OCw3IEBACiAgICAgICAgICAgICBpZiAoIWJfaW5mby0+dS5odm0u
Ym9vdCkgcmV0dXJuIEVSUk9SX05PTUVNOwogICAgICAgICB9CiAKLSAgICAgICAgbGlieGxfZGVm
Ym9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnN0ZHZnYSwgZmFsc2UpOworICAgICAgICBs
aWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJfaW5mby0+dS5odm0uc3RkdmdhLCB0cnVlKTsKICAg
ICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUs
IHRydWUpOwogICAgICAgICBpZiAobGlieGxfZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS52bmMu
ZW5hYmxlKSkgewogICAgICAgICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8t
PnUuaHZtLnZuYy5maW5kdW51c2VkLCB0cnVlKTsK

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA45SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 26 06:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjOwr-0007NG-3e; Tue, 26 Jun 2012 06:08:25 +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 1SjOwq-0007N7-3H
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:08:24 +0000
Received: from [85.158.138.51:10403] by server-3.bemta-3.messagelabs.com id
	B0/FE-26490-7D159EF4; Tue, 26 Jun 2012 06:08:23 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340690901!26619710!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1ODcz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19757 invoked from network); 26 Jun 2012 06:08:22 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 06:08:22 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Jun 2012 23:03:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="160717600"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 25 Jun 2012 23:03:09 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 23:03:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 14:03:00 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 2/2] document update in xl.cfg.pod.5 for 'stdvga=1' by
	default
Thread-Index: Ac1TYU+KSsUpoCEWRxuuSp0C1aD4CA==
Date: Tue, 26 Jun 2012 06:02:59 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FEA5C@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] document update in xl.cfg.pod.5 for
 'stdvga=1' 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

document update in xl.cfg.pod.5 for 'stdvga=3D1' by default

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>

diff -r b98feb4d6359 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Jun 26 12:56:31 2012 +0800
+++ b/docs/man/xl.cfg.pod.5	Tue Jun 26 13:27:19 2012 +0800
@@ -718,9 +718,10 @@
 =3Ditem B<stdvga=3DBOOLEAN>
=20
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
-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.
+emulated graphics device. The default is to enable this (set to 1).
+"stdvga=3D0" means to emulate a Cirrus Logic GD5446 VGA card. If your
+guest supports VBE 2.0 or later (e.g. Windows XP onwards), you
+should enable this (or leave it as default).
=20
 =3Ditem B<vnc=3DBOOLEAN>


--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="stdvga-doc-update.patch"
Content-Description: stdvga-doc-update.patch
Content-Disposition: attachment; filename="stdvga-doc-update.patch"; size=750;
	creation-date="Tue, 26 Jun 2012 05:51:39 GMT";
	modification-date="Tue, 26 Jun 2012 05:29:20 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBiOThmZWI0ZDYzNTkgZG9jcy9tYW4veGwuY2ZnLnBvZC41Ci0tLSBhL2RvY3MvbWFu
L3hsLmNmZy5wb2QuNQlUdWUgSnVuIDI2IDEyOjU2OjMxIDIwMTIgKzA4MDAKKysrIGIvZG9jcy9t
YW4veGwuY2ZnLnBvZC41CVR1ZSBKdW4gMjYgMTM6Mjc6MTkgMjAxMiArMDgwMApAQCAtNzE4LDkg
KzcxOCwxMCBAQAogPWl0ZW0gQjxzdGR2Z2E9Qk9PTEVBTj4KIAogU2VsZWN0IGEgc3RhbmRhcmQg
VkdBIGNhcmQgd2l0aCBWQkUgKFZFU0EgQklPUyBFeHRlbnNpb25zKSBhcyB0aGUKLWVtdWxhdGVk
IGdyYXBoaWNzIGRldmljZS4gVGhlIGRlZmF1bHQgaXMgZmFsc2Ugd2hpY2ggbWVhbnMgdG8gZW11
bGF0ZQotYSBDaXJydXMgTG9naWMgR0Q1NDQ2IFZHQSBjYXJkLiBJZiB5b3VyIGd1ZXN0IHN1cHBv
cnRzIFZCRSAyLjAgb3IKLWxhdGVyIChlLmcuIFdpbmRvd3MgWFAgb253YXJkcykgdGhlbiB5b3Ug
c2hvdWxkIGVuYWJsZSB0aGlzLgorZW11bGF0ZWQgZ3JhcGhpY3MgZGV2aWNlLiBUaGUgZGVmYXVs
dCBpcyB0byBlbmFibGUgdGhpcyAoc2V0IHRvIDEpLgorInN0ZHZnYT0wIiBtZWFucyB0byBlbXVs
YXRlIGEgQ2lycnVzIExvZ2ljIEdENTQ0NiBWR0EgY2FyZC4gSWYgeW91cgorZ3Vlc3Qgc3VwcG9y
dHMgVkJFIDIuMCBvciBsYXRlciAoZS5nLiBXaW5kb3dzIFhQIG9ud2FyZHMpLCB5b3UKK3Nob3Vs
ZCBlbmFibGUgdGhpcyAob3IgbGVhdmUgaXQgYXMgZGVmYXVsdCkuCiAKID1pdGVtIEI8dm5jPUJP
T0xFQU4+CiAK

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 26 06:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjOwr-0007NG-3e; Tue, 26 Jun 2012 06:08:25 +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 1SjOwq-0007N7-3H
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:08:24 +0000
Received: from [85.158.138.51:10403] by server-3.bemta-3.messagelabs.com id
	B0/FE-26490-7D159EF4; Tue, 26 Jun 2012 06:08:23 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340690901!26619710!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1ODcz\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19757 invoked from network); 26 Jun 2012 06:08:22 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 06:08:22 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Jun 2012 23:03:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="160717600"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 25 Jun 2012 23:03:09 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Jun 2012 23:03:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Tue, 26 Jun 2012 14:03:00 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 2/2] document update in xl.cfg.pod.5 for 'stdvga=1' by
	default
Thread-Index: Ac1TYU+KSsUpoCEWRxuuSp0C1aD4CA==
Date: Tue, 26 Jun 2012 06:02:59 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100FEA5C@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] document update in xl.cfg.pod.5 for
 'stdvga=1' 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

document update in xl.cfg.pod.5 for 'stdvga=3D1' by default

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>

diff -r b98feb4d6359 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Jun 26 12:56:31 2012 +0800
+++ b/docs/man/xl.cfg.pod.5	Tue Jun 26 13:27:19 2012 +0800
@@ -718,9 +718,10 @@
 =3Ditem B<stdvga=3DBOOLEAN>
=20
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
-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.
+emulated graphics device. The default is to enable this (set to 1).
+"stdvga=3D0" means to emulate a Cirrus Logic GD5446 VGA card. If your
+guest supports VBE 2.0 or later (e.g. Windows XP onwards), you
+should enable this (or leave it as default).
=20
 =3Ditem B<vnc=3DBOOLEAN>


--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="stdvga-doc-update.patch"
Content-Description: stdvga-doc-update.patch
Content-Disposition: attachment; filename="stdvga-doc-update.patch"; size=750;
	creation-date="Tue, 26 Jun 2012 05:51:39 GMT";
	modification-date="Tue, 26 Jun 2012 05:29:20 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBiOThmZWI0ZDYzNTkgZG9jcy9tYW4veGwuY2ZnLnBvZC41Ci0tLSBhL2RvY3MvbWFu
L3hsLmNmZy5wb2QuNQlUdWUgSnVuIDI2IDEyOjU2OjMxIDIwMTIgKzA4MDAKKysrIGIvZG9jcy9t
YW4veGwuY2ZnLnBvZC41CVR1ZSBKdW4gMjYgMTM6Mjc6MTkgMjAxMiArMDgwMApAQCAtNzE4LDkg
KzcxOCwxMCBAQAogPWl0ZW0gQjxzdGR2Z2E9Qk9PTEVBTj4KIAogU2VsZWN0IGEgc3RhbmRhcmQg
VkdBIGNhcmQgd2l0aCBWQkUgKFZFU0EgQklPUyBFeHRlbnNpb25zKSBhcyB0aGUKLWVtdWxhdGVk
IGdyYXBoaWNzIGRldmljZS4gVGhlIGRlZmF1bHQgaXMgZmFsc2Ugd2hpY2ggbWVhbnMgdG8gZW11
bGF0ZQotYSBDaXJydXMgTG9naWMgR0Q1NDQ2IFZHQSBjYXJkLiBJZiB5b3VyIGd1ZXN0IHN1cHBv
cnRzIFZCRSAyLjAgb3IKLWxhdGVyIChlLmcuIFdpbmRvd3MgWFAgb253YXJkcykgdGhlbiB5b3Ug
c2hvdWxkIGVuYWJsZSB0aGlzLgorZW11bGF0ZWQgZ3JhcGhpY3MgZGV2aWNlLiBUaGUgZGVmYXVs
dCBpcyB0byBlbmFibGUgdGhpcyAoc2V0IHRvIDEpLgorInN0ZHZnYT0wIiBtZWFucyB0byBlbXVs
YXRlIGEgQ2lycnVzIExvZ2ljIEdENTQ0NiBWR0EgY2FyZC4gSWYgeW91cgorZ3Vlc3Qgc3VwcG9y
dHMgVkJFIDIuMCBvciBsYXRlciAoZS5nLiBXaW5kb3dzIFhQIG9ud2FyZHMpLCB5b3UKK3Nob3Vs
ZCBlbmFibGUgdGhpcyAob3IgbGVhdmUgaXQgYXMgZGVmYXVsdCkuCiAKID1pdGVtIEI8dm5jPUJP
T0xFQU4+CiAK

--_002_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_1B4B44D9196EFF41AE41FDA404FC0A100FEA5CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 26 06:14:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjP2S-0007hk-0u; Tue, 26 Jun 2012 06:14: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 1SjP2Q-0007hb-OM
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 06:14:10 +0000
Received: from [85.158.138.51:48238] by server-2.bemta-3.messagelabs.com id
	03/16-10266-13359EF4; Tue, 26 Jun 2012 06:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340691249!21355816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22059 invoked from network); 26 Jun 2012 06:14:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 06:14:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13212707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:14:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 07:14:08 +0100
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 1SjP2O-0004kS-Gz;
	Tue, 26 Jun 2012 06:14:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjP2N-0008VH-Tk;
	Tue, 26 Jun 2012 07:14:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13370-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 07:14:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13370: 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 13370 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13370/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13369

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e08cf97e76f0
baseline version:
 xen                  e08cf97e76f0

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 06:14:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjP2S-0007hk-0u; Tue, 26 Jun 2012 06:14: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 1SjP2Q-0007hb-OM
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 06:14:10 +0000
Received: from [85.158.138.51:48238] by server-2.bemta-3.messagelabs.com id
	03/16-10266-13359EF4; Tue, 26 Jun 2012 06:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340691249!21355816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22059 invoked from network); 26 Jun 2012 06:14:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 06:14:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13212707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:14:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 07:14:08 +0100
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 1SjP2O-0004kS-Gz;
	Tue, 26 Jun 2012 06:14:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjP2N-0008VH-Tk;
	Tue, 26 Jun 2012 07:14:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13370-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 07:14:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13370: 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 13370 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13370/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13369

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e08cf97e76f0
baseline version:
 xen                  e08cf97e76f0

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 06:52:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjPd1-00087Z-O8; Tue, 26 Jun 2012 06:51:59 +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 1SjPcz-00087U-LJ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:51:57 +0000
Received: from [85.158.138.51:8523] by server-10.bemta-3.messagelabs.com id
	67/5C-01753-C0C59EF4; Tue, 26 Jun 2012 06:51:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340693516!10844813!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17207 invoked from network); 26 Jun 2012 06:51:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 06:51:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 07:51:59 +0100
Message-Id: <4FE97857020000780008BD2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 07:52:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dave McCracken" <dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
	<4FE8A450020000780008BBD1@nat28.tlf.novell.com>
	<201206251107.44096.dcm@mccr.org>
In-Reply-To: <201206251107.44096.dcm@mccr.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with PV superpage 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 25.06.12 at 18:07, Dave McCracken <dcm@mccr.org> wrote:
> On Monday, June 25, 2012, Jan Beulich wrote:
>> > My question is, what is the value of enforcing all-or-nothing for PV 
>> > guests?  Is it the case that PV guests have to be entirely in either one 
>> > mode or the other?
>> 
>> Since I understand a PV guest's balloon driver must play with
>> this, I indeed think this is a strictly separated set.
> 
> I specifically need to be able to guarantee superpage-backed memory in PV 
> guests to be able to map them as superpages (hugepages in Linux).  I'm 
> trying 
> to come up with some benefit for opportunistic superpages in PV guests, but 
> nothing comes to mind.
> 
>> > I'm not particularly fussed about having a way to disable the 
>> > opportunistic superpage allocation for HVM guests, and just turning that 
>> > on all the time.  I only really used the flag because I saw it was being 
>> > passed but wasn't being used; I didn't realize it was meant to have the 
>> > "use superpages or abort" semantics.  My only non-negotiable is that we 
>> > have a way to get opportunistic superpages for HVM guests.
>> 
>> Couldn't we have the setting be an override for the HVM
>> allocation behavior (defaulting to enabled there), and have
>> the originally intended meaning for PV (disabled by default)?
> 
> I like this idea.  It would be simple enough.
> 
> Is there any reason to allow disabling HVM superpage allocation?

Debugging of certain code paths? Or discriminating certain
(unimportant) VMs?

>  HVM domain 
> creation always allocates as many superpages as it can, then falls back to 
> small pages for the rest.  Wouldn't it be reasonable to make restore always 
> do this too?

Absolutely imo - not having done so from the beginning was
likely just an oversight (but that would need confirmation by
someone more familiar with that code than 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 Jun 26 06:52:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 06: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 1SjPd1-00087Z-O8; Tue, 26 Jun 2012 06:51:59 +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 1SjPcz-00087U-LJ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 06:51:57 +0000
Received: from [85.158.138.51:8523] by server-10.bemta-3.messagelabs.com id
	67/5C-01753-C0C59EF4; Tue, 26 Jun 2012 06:51:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340693516!10844813!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17207 invoked from network); 26 Jun 2012 06:51:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 06:51:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 07:51:59 +0100
Message-Id: <4FE97857020000780008BD2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 07:52:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dave McCracken" <dcm@mccr.org>
References: <201206250938.21418.dcm@mccr.org> <4FE87EEB.7060507@eu.citrix.com>
	<4FE8A450020000780008BBD1@nat28.tlf.novell.com>
	<201206251107.44096.dcm@mccr.org>
In-Reply-To: <201206251107.44096.dcm@mccr.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issue with PV superpage 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 25.06.12 at 18:07, Dave McCracken <dcm@mccr.org> wrote:
> On Monday, June 25, 2012, Jan Beulich wrote:
>> > My question is, what is the value of enforcing all-or-nothing for PV 
>> > guests?  Is it the case that PV guests have to be entirely in either one 
>> > mode or the other?
>> 
>> Since I understand a PV guest's balloon driver must play with
>> this, I indeed think this is a strictly separated set.
> 
> I specifically need to be able to guarantee superpage-backed memory in PV 
> guests to be able to map them as superpages (hugepages in Linux).  I'm 
> trying 
> to come up with some benefit for opportunistic superpages in PV guests, but 
> nothing comes to mind.
> 
>> > I'm not particularly fussed about having a way to disable the 
>> > opportunistic superpage allocation for HVM guests, and just turning that 
>> > on all the time.  I only really used the flag because I saw it was being 
>> > passed but wasn't being used; I didn't realize it was meant to have the 
>> > "use superpages or abort" semantics.  My only non-negotiable is that we 
>> > have a way to get opportunistic superpages for HVM guests.
>> 
>> Couldn't we have the setting be an override for the HVM
>> allocation behavior (defaulting to enabled there), and have
>> the originally intended meaning for PV (disabled by default)?
> 
> I like this idea.  It would be simple enough.
> 
> Is there any reason to allow disabling HVM superpage allocation?

Debugging of certain code paths? Or discriminating certain
(unimportant) VMs?

>  HVM domain 
> creation always allocates as many superpages as it can, then falls back to 
> small pages for the rest.  Wouldn't it be reasonable to make restore always 
> do this too?

Absolutely imo - not having done so from the beginning was
likely just an oversight (but that would need confirmation by
someone more familiar with that code than 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 Jun 26 07:42:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 07: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 1SjQPC-0000Bt-M9; Tue, 26 Jun 2012 07:41: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 1SjQPB-0000Bn-AD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 07:41:45 +0000
Received: from [85.158.139.83:33961] by server-6.bemta-5.messagelabs.com id
	1C/04-11348-8B769EF4; Tue, 26 Jun 2012 07:41:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340696503!29496165!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14834 invoked from network); 26 Jun 2012 07:41:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	26 Jun 2012 07:41:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 08:41:52 +0100
Message-Id: <4FE98402020000780008BD7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 08:42:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
In-Reply-To: <CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.06.12 at 04:31, Rolu <rolu@roce.org> wrote:
> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>> This is what should happen:
>>
>> 1) Linux configures the device with a 0 vector number and the pirq number
>> in the address field;
>>
>> 2) QEMU notices a vector number of 0 and reads the pirq number from the
>> address field, passing it to xc_domain_update_msi_irq;
>>
>> 3) Xen assignes the given pirq to the physical MSI;
>>
>> 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>>
>> 5) Xen sets the pirq as "IRQ_PT";
>>
>> 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
>> returns true so Xen calls send_guest_pirq instead.
>>
>>
>> Obviously 6) is not happening. hvm_domain_use_pirq is:
>>
>> is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
>>
>> My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
>> above).
> 
> This appears to be true. I added logging to hvm_pci_msi_assert in
> xen/drivers/passthrough/io.c and it indicates that
> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
> before an unsupported delivery mode message.
> 
> I also log pirq->pirq but I found that most of the time I can't find
> this value anywhere else (I'm not sure how to interpret the value,
> though). For example, in my last try:
> 
> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
> 53. The vast majority are for 54.
> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
> but complains it's already mapped.
> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
> 22, 52, 48, 47. Also never 54 or 53.
> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 
> 55.
> * The qemu log mentions pirq 35, 36 and 37
> 
> It seems pirq values don't always mean the same? Is it a coincidence
> that 55 occurs almost everywhere, or is something going wrong with the
> other two values (53 and 54 versus 16 and 17)?
> 
> I have three MSI capable devices passed through to the domU, and I do
> see groups of three distinct pirqs in the data above - just not the
> same ones in every place I look.
> 
>> So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
>> (__startup_pirq doesn't get called), or Xen is erroring out in
>> map_domain_emuirq_pirq.
> 
> evtchn_bind_pirq gets called, though I'm not sure if it is with the right 
> data.
> 
> map_domain_emuirq_pirq always gets past the checks in the top half
> (i.e. up to the line /* do not store emuirq mappings for pt devices
> */), except for one time with pirq=49,emuirq=23 where it finds they
> are already mapped.
> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
> directly logged that but it's the only assignment there).
> 
> Interestingly, I get an unsupported delivery mode error for pirq 55
> where my logging says pirq->arch.hvm.emuirq is -1, *after*
> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.

Adding some logging at the kernel side would seem much more
promising to me based on Stefano's analysis 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 Jun 26 07:42:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 07: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 1SjQPC-0000Bt-M9; Tue, 26 Jun 2012 07:41: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 1SjQPB-0000Bn-AD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 07:41:45 +0000
Received: from [85.158.139.83:33961] by server-6.bemta-5.messagelabs.com id
	1C/04-11348-8B769EF4; Tue, 26 Jun 2012 07:41:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340696503!29496165!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14834 invoked from network); 26 Jun 2012 07:41:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	26 Jun 2012 07:41:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 08:41:52 +0100
Message-Id: <4FE98402020000780008BD7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 08:42:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
In-Reply-To: <CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.06.12 at 04:31, Rolu <rolu@roce.org> wrote:
> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>> This is what should happen:
>>
>> 1) Linux configures the device with a 0 vector number and the pirq number
>> in the address field;
>>
>> 2) QEMU notices a vector number of 0 and reads the pirq number from the
>> address field, passing it to xc_domain_update_msi_irq;
>>
>> 3) Xen assignes the given pirq to the physical MSI;
>>
>> 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>>
>> 5) Xen sets the pirq as "IRQ_PT";
>>
>> 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
>> returns true so Xen calls send_guest_pirq instead.
>>
>>
>> Obviously 6) is not happening. hvm_domain_use_pirq is:
>>
>> is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
>>
>> My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
>> above).
> 
> This appears to be true. I added logging to hvm_pci_msi_assert in
> xen/drivers/passthrough/io.c and it indicates that
> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
> before an unsupported delivery mode message.
> 
> I also log pirq->pirq but I found that most of the time I can't find
> this value anywhere else (I'm not sure how to interpret the value,
> though). For example, in my last try:
> 
> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
> 53. The vast majority are for 54.
> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
> but complains it's already mapped.
> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
> 22, 52, 48, 47. Also never 54 or 53.
> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 
> 55.
> * The qemu log mentions pirq 35, 36 and 37
> 
> It seems pirq values don't always mean the same? Is it a coincidence
> that 55 occurs almost everywhere, or is something going wrong with the
> other two values (53 and 54 versus 16 and 17)?
> 
> I have three MSI capable devices passed through to the domU, and I do
> see groups of three distinct pirqs in the data above - just not the
> same ones in every place I look.
> 
>> So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
>> (__startup_pirq doesn't get called), or Xen is erroring out in
>> map_domain_emuirq_pirq.
> 
> evtchn_bind_pirq gets called, though I'm not sure if it is with the right 
> data.
> 
> map_domain_emuirq_pirq always gets past the checks in the top half
> (i.e. up to the line /* do not store emuirq mappings for pt devices
> */), except for one time with pirq=49,emuirq=23 where it finds they
> are already mapped.
> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
> directly logged that but it's the only assignment there).
> 
> Interestingly, I get an unsupported delivery mode error for pirq 55
> where my logging says pirq->arch.hvm.emuirq is -1, *after*
> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.

Adding some logging at the kernel side would seem much more
promising to me based on Stefano's analysis 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 Jun 26 08:17:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08: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 1SjQwt-0001HI-HF; Tue, 26 Jun 2012 08:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjQws-0001HC-8m
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:16:34 +0000
Received: from [85.158.143.99:63175] by server-1.bemta-4.messagelabs.com id
	63/AD-24392-1EF69EF4; Tue, 26 Jun 2012 08:16:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340698592!21434873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17874 invoked from network); 26 Jun 2012 08:16:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13215293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 08:16:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 09:16:28 +0100
Message-ID: <1340698587.3832.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 26 Jun 2012 09:16:27 +0100
In-Reply-To: <4FE224AF.2060107@citrix.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>
	<4FE1E718020000780008AD65@nat28.tlf.novell.com>
	<4FE1CDCD.4090009@citrix.com> <4FE224AF.2060107@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 20:29 +0100, Andrew Cooper wrote:
> > I have not investigated yet as I am just wrapping up a more important
> > issue, but the issue was a constant console spam saying no handler for
> > vector 0xe5, which was causing the server to run like treacle.  The
> > issue started occurring shortly after I backported c/s 25336 to
> > XenServer, which is why I suspect it as the culprit.  Having said that,
> > the patch appears to work fine on every other server we have, so I
> > suspect its some motherboard quirk; it is a slightly old AMD box we
> > have, and is 100% reproducible.  I am hoping to have time to start
> > looking at the problem this afternoon.
> >
> 
> After some investigation, it appears that the server in question is not
> old (as the bug report I received said).  It appears to be a fairly-new
> evaluation dual socket AMD box, with a beta-looking BIOS, which can't
> reliably boot Xen 3.4 or Xen 4.1 (with or without the changeset), can't
> reliably reboot via ACPI, and cant reliably turn back on after you cut
> its power.
> 
> As such, I would say that the server is rather more suspect than Xen
> 4.2, so this IRQ issue should probably not be considered a blocker.

Thanks, I won't include this issue on the list this week then.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 08:17:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08: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 1SjQwt-0001HI-HF; Tue, 26 Jun 2012 08:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjQws-0001HC-8m
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:16:34 +0000
Received: from [85.158.143.99:63175] by server-1.bemta-4.messagelabs.com id
	63/AD-24392-1EF69EF4; Tue, 26 Jun 2012 08:16:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340698592!21434873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17874 invoked from network); 26 Jun 2012 08:16:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13215293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 08:16:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 09:16:28 +0100
Message-ID: <1340698587.3832.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 26 Jun 2012 09:16:27 +0100
In-Reply-To: <4FE224AF.2060107@citrix.com>
References: <1340191788.4906.30.camel@zakaz.uk.xensource.com>
	<4FE1B777.4010407@citrix.com>
	<4FE1E718020000780008AD65@nat28.tlf.novell.com>
	<4FE1CDCD.4090009@citrix.com> <4FE224AF.2060107@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-20 at 20:29 +0100, Andrew Cooper wrote:
> > I have not investigated yet as I am just wrapping up a more important
> > issue, but the issue was a constant console spam saying no handler for
> > vector 0xe5, which was causing the server to run like treacle.  The
> > issue started occurring shortly after I backported c/s 25336 to
> > XenServer, which is why I suspect it as the culprit.  Having said that,
> > the patch appears to work fine on every other server we have, so I
> > suspect its some motherboard quirk; it is a slightly old AMD box we
> > have, and is 100% reproducible.  I am hoping to have time to start
> > looking at the problem this afternoon.
> >
> 
> After some investigation, it appears that the server in question is not
> old (as the bug report I received said).  It appears to be a fairly-new
> evaluation dual socket AMD box, with a beta-looking BIOS, which can't
> reliably boot Xen 3.4 or Xen 4.1 (with or without the changeset), can't
> reliably reboot via ACPI, and cant reliably turn back on after you cut
> its power.
> 
> As such, I would say that the server is rather more suspect than Xen
> 4.2, so this IRQ issue should probably not be considered a blocker.

Thanks, I won't include this issue on the list this week then.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 08:40:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjRJM-0001Vd-Iq; Tue, 26 Jun 2012 08:39: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 1SjRJK-0001VY-Tp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:39:47 +0000
Received: from [85.158.143.35:47731] by server-3.bemta-4.messagelabs.com id
	5F/62-05808-25579EF4; Tue, 26 Jun 2012 08:39:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340699984!14949566!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 26 Jun 2012 08:39:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:39:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13216102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 08:39:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 09:39:44 +0100
Message-ID: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 09:39:42 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QSBkYXkgbGF0ZSBkdWUgdG8gdGhlIFhlbi5vcmcgZG9jcyBkYXkgeWVzdGVyZGF5LiBUaGFua3Mg
dG8gYWxsIHdobwp0b29rIHBhcnQgLS0gbmV4dCBvbmUgaXMgSnVseSAzMCEKClBsYW4gZm9yIGEg
NC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVs
LzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhlIHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgoKMTkg
TWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAgLS0g
RmVhdHVyZSBGcmVlemUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJdCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2UgY2Fu
ZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCByZWxlYXNlCgpUaGUgdXBkYXRl
ZCBUT0RPIGxpc3QgZm9sbG93cy4KCklmIHlvdSBhcmUgYXdhcmUgb2YgYW55IGJ1Z3Mgd2hpY2gg
bXVzdC9zaG91bGQgYmUgZml4ZWQgZm9yIDQuMiB0aGVuCnBsZWFzZSByZXBseSB0byB0aGlzIHRo
cmVhZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJlciB0byBwaWNrIHRoZW0KdXAgbmV4dCB3
ZWVrKQoKUGVyIHRoZSByZWxlYXNlIHBsYW4gYSBzdHJvbmcgY2FzZSB3aWxsIG5vdyBoYXZlIHRv
IGJlIG1hZGUgYXMgdG8gd2h5Cm5ldyBpdGVtcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3Qs
IGVzcGVjaWFsbHkgYXMgYSBibG9ja2VyLCByYXRoZXIKdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpo
eXBlcnZpc29yLCBibG9ja2VyczoKCiAgICAqIE5vbmUKIAp0b29scywgYmxvY2tlcnM6CgogICAg
KiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJs
ZSBBUEkKICAgICAgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBj
aGFuZ2luZy4gQXNwZWN0cyBvZgogICAgICB0aGlzIGFyZToKCiAgICAgICAgKiBJbnRlcmZhY2Vz
IHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgoKICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5f
c3VzcGVuZC4gTW92ZSB4Y19kb21haW5fc2F2ZS9yZXN0b3JlIGludG8gYQogICAgICAgICAgICAg
IHNlcGFyYXRlIHByb2Nlc3MgKElhbiBKYWNrc29uLCBwYXRjaGVzIHJldmlld2VkIGFuZCByZXBv
c3RlZCkuCgogICAgICAgICAgICAqIGxpYnhsX2RldmljZV97ZGlzayxuaWMsdmtiLGFkZCxwY2l9
X2FkZCAoYW5kCiAgICAgICAgICAgICAgcmVtb3ZlKS4gKFJvZ2VyIFBhdSBNb25uw6ksIHBhdGNo
ZXMgcG9zdGVkIGZvciBkaXNrICYgbmljLCB2a2IKICAgICAgICAgICAgICB0cml2aWFsLCBub3Qg
bG9va2VkIGF0IHBjaSB5ZXQpCgogICAgICAgICogTElCWExfTklDX1RZUEUgZW51bSBuYW1lcyBh
cmUgY29uZnVzaW5nLiAoUm9nZXIsIGluY2x1ZGVkIGluCiAgICAgICAgICBjYWxsaW5nIGhvdHBs
dWcgc2NyaXB0cyBzZXJpZXMpCgogICAgICAgICogdXNlIGxpYnhsX2NwdW1hcCBmb3IgYl9pbmZv
LmF2YWlsX2NwdXMgaW5zdGVhZCBvZiBhbiBpbnQsCiAgICAgICAgICB0aGlzIGFsbG93cyBzZXR0
aW5nIG1vcmUgdGhhbiAzMSBDUFVTIChZYW5nIFogWmhhbmcsIHBhdGNoZXMKICAgICAgICAgIHBv
c3RlZCwgYXdhaXRpbmcgYSByZXBvc3QpCgogICAgICAgICogdXNlIGFuIGVudW0gZm9yIFZHQSBp
bnRlcmZhY2UgdHlwZSAoZS5nLiBDaXJydXMsCiAgICAgICAgICBTdGRWR0EpLiBBbGxvd3MgZm9y
IFFYTCBzdXBwb3J0IChpbiA0LjMpLiAoWmhvdSBQZW5nLAogICAgICAgICAgYXdhaXRpbmcgcmVw
b3N0KQoKICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgoKICAgICAgICAqIFtCVUddIGNh
bm5vdCBjcmVhdGUgYW4gZW1wdHkgQ0QtUk9NIGRyaXZlIG9uIEhWTSBndWVzdCwKICAgICAgICAg
IHJlcG9ydGVkIGJ5IEZhYmlvIEZhbnRvbmkgaW4gPDRGOTY3MkRELjIwODA5MDJAdGlzY2FsaS5p
dD4KCiAgICAgICAgKiBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IHRyeSB0byBzZWxlY3QgYSAoc2V0
IG9mKSBub2RlKHMpIG9uCiAgICAgICAgICB3aGljaCB0byBjcmVhdGUgYSBWTSBhbmQgcGluIGl0
cyB2Y3B1cyB0aGVyZS4gKERhcmlvCiAgICAgICAgICBGYWdnaW9saSwgcG9zdGVkIGFuZCByZXZp
ZXdlZCwgYXdhaXRpbmcgYSByZXBvc3QpCgogICAgKiBbQ0hFQ0tdIE1vcmUgZm9ybWFsbHkgZGVw
cmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5CiAgICAgIGluIHRyZWUuIE5l
ZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCiAgICAg
IHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KCiAgICAqIGNhbGxpbmcgaG90cGx1ZyBzY3JpcHRz
IGZyb20geGwgKExpbnV4IGFuZCBOZXRCU0QpIChSb2dlciBQYXUKICAgICAgTW9ubsOpLCBwb3N0
ZWQsIGF3YWl0aW5nIHJldmlldykKCiAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxv
d3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKICAgICAgUGF1IE1vbm7DqSwgImp1c3Qg
YmUgYSBtYXR0ZXIgb2YgcmVtb3ZpbmcgYW4gImlmIiIpCgogICAgKiBBZGp1c3RtZW50cyBuZWVk
ZWQgZm9yIHFkaXNrIGJhY2tlbmQgdG8gd29yayBvbiBub24tcHZvcHMgTGludXguCiAgICAgICJx
ZW11L3hlbmRpc2s6IHNldCBtYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8gYmUgdXNlZCIgKEph
bgogICAgICBCZXVsaWNoLCBwYXRjaCBjb21taXR0ZWQgdG8gcWVtdS14ZW4tdXBzdHJlYW0sIHBl
bmRpbmcgZm9yCiAgICAgIHFlbXUteGVuLXRyYWRpdGlvbmFsKQoKICAgICogW0NIRUNLXSBDb25m
aXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAtPiA0LjIgd29ya3MuCgogICAgKiBbQlVH
XSBMSUJMRUFGRElSIGV0IGFsIGFuZCBsaWJmc2ltYWdlIGRvIHRoZSB3cm9uZyB0aGluZyBvbgog
ICAgICBtb2Rlcm4gRGViaWFuL1VidW50dSB3LyBtdWx0aWFyY2ggY2FwYWJpbGl0aWVzIChNYXR0
IFdpbHNvbiwKICAgICAgcGF0Y2ggcG9zdGVkKQoKICAgICogW0JVR10gc3R1YiBkb21haW5zIGJy
b2tlbi4gSFZNX1BBUkFNX0RNX0RPTUFJTiBuZWVkcyB0byByZXNldAogICAgICBIVk1fUEFSQU1f
QlVGSU9SRVFfRVZUQ0hOIChJYW4gQ2FtcGJlbGwsIEFudGhvbnkgUGVyYXJkKQoKaHlwZXJ2aXNv
ciwgbmljZSB0byBoYXZlOgoKICAgICogUG9EIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyAoR2Vv
cmdlIER1bmxhcCwgYW5kIHJldmlld2VkCiAgICAgIGF3YWl0aW5nIHJlcG9zdCkKCnRvb2xzLCBu
aWNlIHRvIGhhdmU6CgogICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06CgogICAgICAgICog
QWNjZXB0ICJ4bCBjciAvZGV2L251bGwgcGFyYW09dmFsdWUiIHRvIHByb3ZpZGUgYWxsIGNvbmZp
ZwogICAgICAgICAgb24gdGhlIGNvbW1hbmQgbGluZSAoVy4gTWljaGFlbCBQZXR1bGxvLCBwYXRj
aCBwb3N0ZWQpCgogICAgKiBsaWJ4bCBzdGFibGUgQVBJCgogICAgICAgICogbGlieGxfd2FpdF9m
b3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5X3RhcmdldC4KICAgICAgICAgIElu
dGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRlZCB0bwogICAgICAgICAgbG9ja2luZy9z
ZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0ZS4gSWFuSiB0byBhZGQgbm90ZQogICAgICAg
ICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVpbmcgc3Vic3RhbmRhcmQgYnV0IG90aGVyd2lzZSBk
ZWZlcgogICAgICAgICAgdG8gNC4zLgoKICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5l
ZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAgICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxk
IGJlIGVhc3kgb25jZQogICAgICAgICAgICAgIGRpc2tfe2FkZCxyZW1vdmV9IGRvbmUuIFRoaXMg
aXMgYmFzaWNhbGx5IGEgaGVscGVyCiAgICAgICAgICAgICAgZnVuY3Rpb24gYW5kIGl0cyBmdW5j
dGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRlZCBpbgogICAgICAgICAgICAgIHRlcm1zIG9mIHRo
ZSBsaWJ4bF9kaXNrXyogaW50ZXJmYWNlcy4gSWYgdGhpcyBpcyBub3QKICAgICAgICAgICAgICBk
b25lIGluIHRpbWUgd2Ugc2hvdWxkIGRvY3VtZW50IGFzIGEgc3Vic3RhbmRhcmQKICAgICAgICAg
ICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3ViamVjdCB0byBjaGFuZ2UgcG9zdCA0LjIuCgogICAg
KiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBwYXRjaCBmb3IgcWVtdS11cHN0cmVhbQogICAgICB2
aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0OgogICAgICBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1L21zZzAwMjUwLmh0bWwKICAgICAgcWVtdS11cHN0
cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lmeWluZyB2aWRlb21lbSBzaXplIGZvciB0aGUKICAg
ICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29ya3Mgd2l0aAogICAgICBx
ZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNpIEvDpHJra8OkaW5lbikKCiAgICAqIFtCVUddIGxv
bmcgc3RvcCBkdXJpbmcgdGhlIGd1ZXN0IGJvb3QgcHJvY2VzcyB3aXRoIHFjb3cgaW1hZ2UsCiAg
ICAgIHJlcG9ydGVkIGJ5IEludGVsOiBodHRwOi8vYnVnemlsbGEueGVuLm9yZy9idWd6aWxsYS9z
aG93X2J1Zy5jZ2k/aWQ9MTgyMQoKICAgICogW0JVR10gdmNwdS1zZXQgZG9lc24ndCB0YWtlIGVm
ZmVjdCBvbiBndWVzdCwgcmVwb3J0ZWQgYnkgSW50ZWw6CiAgICAgIGh0dHA6Ly9idWd6aWxsYS54
ZW4ub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0xODIyCgogICAgKiBMb2FkIGJsa3RhcCBk
cml2ZXIgZnJvbSB4ZW5jb21tb25zIGluaXRzY3JpcHQgaWYgYXZhaWxhYmxlLCB0aHJlYWQgYXQ6
CiAgICAgIDxkYjYxNGU5MmZhZjc0M2UyMGIzZi4xMzM3MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4
ZWQgbW9yZQogICAgICBwcm9wZXJseSBpbiA0LjMuIChQYXRjaCBwb3N0ZWQsIGRpc2N1c3Npb24s
IHBsYW4gdG8gdGFrZSBzaW1wbGUKICAgICAgeGVuY29tbW9ucyBwYXRjaCBmb3IgNC4yIGFuZCBy
ZXZpc3QgZm9yIDQuMykKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 26 08:40:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjRJM-0001Vd-Iq; Tue, 26 Jun 2012 08:39: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 1SjRJK-0001VY-Tp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:39:47 +0000
Received: from [85.158.143.35:47731] by server-3.bemta-4.messagelabs.com id
	5F/62-05808-25579EF4; Tue, 26 Jun 2012 08:39:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340699984!14949566!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 26 Jun 2012 08:39:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:39:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13216102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 08:39:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 09:39:44 +0100
Message-ID: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 09:39:42 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QSBkYXkgbGF0ZSBkdWUgdG8gdGhlIFhlbi5vcmcgZG9jcyBkYXkgeWVzdGVyZGF5LiBUaGFua3Mg
dG8gYWxsIHdobwp0b29rIHBhcnQgLS0gbmV4dCBvbmUgaXMgSnVseSAzMCEKClBsYW4gZm9yIGEg
NC4yIHJlbGVhc2U6Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVs
LzIwMTItMDMvbXNnMDA3OTMuaHRtbAoKVGhlIHRpbWUgbGluZSBpcyBhcyBmb2xsb3dzOgoKMTkg
TWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAgLS0g
RmVhdHVyZSBGcmVlemUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPDwgV0UgQVJFIEhFUkUKV2hlbiBJdCdzIFJlYWR5IC0tIEZpcnN0IHJlbGVhc2UgY2Fu
ZGlkYXRlCldlZWtseSAgICAgICAgICAtLSBSQ04rMSB1bnRpbCByZWxlYXNlCgpUaGUgdXBkYXRl
ZCBUT0RPIGxpc3QgZm9sbG93cy4KCklmIHlvdSBhcmUgYXdhcmUgb2YgYW55IGJ1Z3Mgd2hpY2gg
bXVzdC9zaG91bGQgYmUgZml4ZWQgZm9yIDQuMiB0aGVuCnBsZWFzZSByZXBseSB0byB0aGlzIHRo
cmVhZCAob3RoZXJ3aXNlIEkgbWF5IG5vdCByZW1lbWJlciB0byBwaWNrIHRoZW0KdXAgbmV4dCB3
ZWVrKQoKUGVyIHRoZSByZWxlYXNlIHBsYW4gYSBzdHJvbmcgY2FzZSB3aWxsIG5vdyBoYXZlIHRv
IGJlIG1hZGUgYXMgdG8gd2h5Cm5ldyBpdGVtcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3Qs
IGVzcGVjaWFsbHkgYXMgYSBibG9ja2VyLCByYXRoZXIKdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpo
eXBlcnZpc29yLCBibG9ja2VyczoKCiAgICAqIE5vbmUKIAp0b29scywgYmxvY2tlcnM6CgogICAg
KiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJs
ZSBBUEkKICAgICAgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBj
aGFuZ2luZy4gQXNwZWN0cyBvZgogICAgICB0aGlzIGFyZToKCiAgICAgICAgKiBJbnRlcmZhY2Vz
IHdoaWNoIG1heSBuZWVkIHRvIGJlIGFzeW5jOgoKICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5f
c3VzcGVuZC4gTW92ZSB4Y19kb21haW5fc2F2ZS9yZXN0b3JlIGludG8gYQogICAgICAgICAgICAg
IHNlcGFyYXRlIHByb2Nlc3MgKElhbiBKYWNrc29uLCBwYXRjaGVzIHJldmlld2VkIGFuZCByZXBv
c3RlZCkuCgogICAgICAgICAgICAqIGxpYnhsX2RldmljZV97ZGlzayxuaWMsdmtiLGFkZCxwY2l9
X2FkZCAoYW5kCiAgICAgICAgICAgICAgcmVtb3ZlKS4gKFJvZ2VyIFBhdSBNb25uw6ksIHBhdGNo
ZXMgcG9zdGVkIGZvciBkaXNrICYgbmljLCB2a2IKICAgICAgICAgICAgICB0cml2aWFsLCBub3Qg
bG9va2VkIGF0IHBjaSB5ZXQpCgogICAgICAgICogTElCWExfTklDX1RZUEUgZW51bSBuYW1lcyBh
cmUgY29uZnVzaW5nLiAoUm9nZXIsIGluY2x1ZGVkIGluCiAgICAgICAgICBjYWxsaW5nIGhvdHBs
dWcgc2NyaXB0cyBzZXJpZXMpCgogICAgICAgICogdXNlIGxpYnhsX2NwdW1hcCBmb3IgYl9pbmZv
LmF2YWlsX2NwdXMgaW5zdGVhZCBvZiBhbiBpbnQsCiAgICAgICAgICB0aGlzIGFsbG93cyBzZXR0
aW5nIG1vcmUgdGhhbiAzMSBDUFVTIChZYW5nIFogWmhhbmcsIHBhdGNoZXMKICAgICAgICAgIHBv
c3RlZCwgYXdhaXRpbmcgYSByZXBvc3QpCgogICAgICAgICogdXNlIGFuIGVudW0gZm9yIFZHQSBp
bnRlcmZhY2UgdHlwZSAoZS5nLiBDaXJydXMsCiAgICAgICAgICBTdGRWR0EpLiBBbGxvd3MgZm9y
IFFYTCBzdXBwb3J0IChpbiA0LjMpLiAoWmhvdSBQZW5nLAogICAgICAgICAgYXdhaXRpbmcgcmVw
b3N0KQoKICAgICogeGwgY29tcGF0aWJpbGl0eSB3aXRoIHhtOgoKICAgICAgICAqIFtCVUddIGNh
bm5vdCBjcmVhdGUgYW4gZW1wdHkgQ0QtUk9NIGRyaXZlIG9uIEhWTSBndWVzdCwKICAgICAgICAg
IHJlcG9ydGVkIGJ5IEZhYmlvIEZhbnRvbmkgaW4gPDRGOTY3MkRELjIwODA5MDJAdGlzY2FsaS5p
dD4KCiAgICAgICAgKiBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IHRyeSB0byBzZWxlY3QgYSAoc2V0
IG9mKSBub2RlKHMpIG9uCiAgICAgICAgICB3aGljaCB0byBjcmVhdGUgYSBWTSBhbmQgcGluIGl0
cyB2Y3B1cyB0aGVyZS4gKERhcmlvCiAgICAgICAgICBGYWdnaW9saSwgcG9zdGVkIGFuZCByZXZp
ZXdlZCwgYXdhaXRpbmcgYSByZXBvc3QpCgogICAgKiBbQ0hFQ0tdIE1vcmUgZm9ybWFsbHkgZGVw
cmVjYXRlIHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5CiAgICAgIGluIHRyZWUuIE5l
ZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCiAgICAg
IHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KCiAgICAqIGNhbGxpbmcgaG90cGx1ZyBzY3JpcHRz
IGZyb20geGwgKExpbnV4IGFuZCBOZXRCU0QpIChSb2dlciBQYXUKICAgICAgTW9ubsOpLCBwb3N0
ZWQsIGF3YWl0aW5nIHJldmlldykKCiAgICAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxv
d3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKICAgICAgUGF1IE1vbm7DqSwgImp1c3Qg
YmUgYSBtYXR0ZXIgb2YgcmVtb3ZpbmcgYW4gImlmIiIpCgogICAgKiBBZGp1c3RtZW50cyBuZWVk
ZWQgZm9yIHFkaXNrIGJhY2tlbmQgdG8gd29yayBvbiBub24tcHZvcHMgTGludXguCiAgICAgICJx
ZW11L3hlbmRpc2s6IHNldCBtYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8gYmUgdXNlZCIgKEph
bgogICAgICBCZXVsaWNoLCBwYXRjaCBjb21taXR0ZWQgdG8gcWVtdS14ZW4tdXBzdHJlYW0sIHBl
bmRpbmcgZm9yCiAgICAgIHFlbXUteGVuLXRyYWRpdGlvbmFsKQoKICAgICogW0NIRUNLXSBDb25m
aXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAtPiA0LjIgd29ya3MuCgogICAgKiBbQlVH
XSBMSUJMRUFGRElSIGV0IGFsIGFuZCBsaWJmc2ltYWdlIGRvIHRoZSB3cm9uZyB0aGluZyBvbgog
ICAgICBtb2Rlcm4gRGViaWFuL1VidW50dSB3LyBtdWx0aWFyY2ggY2FwYWJpbGl0aWVzIChNYXR0
IFdpbHNvbiwKICAgICAgcGF0Y2ggcG9zdGVkKQoKICAgICogW0JVR10gc3R1YiBkb21haW5zIGJy
b2tlbi4gSFZNX1BBUkFNX0RNX0RPTUFJTiBuZWVkcyB0byByZXNldAogICAgICBIVk1fUEFSQU1f
QlVGSU9SRVFfRVZUQ0hOIChJYW4gQ2FtcGJlbGwsIEFudGhvbnkgUGVyYXJkKQoKaHlwZXJ2aXNv
ciwgbmljZSB0byBoYXZlOgoKICAgICogUG9EIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyAoR2Vv
cmdlIER1bmxhcCwgYW5kIHJldmlld2VkCiAgICAgIGF3YWl0aW5nIHJlcG9zdCkKCnRvb2xzLCBu
aWNlIHRvIGhhdmU6CgogICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06CgogICAgICAgICog
QWNjZXB0ICJ4bCBjciAvZGV2L251bGwgcGFyYW09dmFsdWUiIHRvIHByb3ZpZGUgYWxsIGNvbmZp
ZwogICAgICAgICAgb24gdGhlIGNvbW1hbmQgbGluZSAoVy4gTWljaGFlbCBQZXR1bGxvLCBwYXRj
aCBwb3N0ZWQpCgogICAgKiBsaWJ4bCBzdGFibGUgQVBJCgogICAgICAgICogbGlieGxfd2FpdF9m
b3JfZnJlZV9tZW1vcnkvbGlieGxfd2FpdF9mb3JfbWVtb3J5X3RhcmdldC4KICAgICAgICAgIElu
dGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRlZCB0bwogICAgICAgICAgbG9ja2luZy9z
ZXJpYWxpemF0aW9uIG92ZXIgZG9tYWluIGNyZWF0ZS4gSWFuSiB0byBhZGQgbm90ZQogICAgICAg
ICAgYWJvdXQgdGhpcyBpbnRlcmZhY2UgYmVpbmcgc3Vic3RhbmRhcmQgYnV0IG90aGVyd2lzZSBk
ZWZlcgogICAgICAgICAgdG8gNC4zLgoKICAgICAgICAqIEludGVyZmFjZXMgd2hpY2ggbWF5IG5l
ZWQgdG8gYmUgYXN5bmM6CgogICAgICAgICAgICAqIGxpYnhsX2Nkcm9tX2luc2VydC4gU2hvdWxk
IGJlIGVhc3kgb25jZQogICAgICAgICAgICAgIGRpc2tfe2FkZCxyZW1vdmV9IGRvbmUuIFRoaXMg
aXMgYmFzaWNhbGx5IGEgaGVscGVyCiAgICAgICAgICAgICAgZnVuY3Rpb24gYW5kIGl0cyBmdW5j
dGlvbmFsaXR5IGNhbiBiZSBpbXBsZW1lbnRlZCBpbgogICAgICAgICAgICAgIHRlcm1zIG9mIHRo
ZSBsaWJ4bF9kaXNrXyogaW50ZXJmYWNlcy4gSWYgdGhpcyBpcyBub3QKICAgICAgICAgICAgICBk
b25lIGluIHRpbWUgd2Ugc2hvdWxkIGRvY3VtZW50IGFzIGEgc3Vic3RhbmRhcmQKICAgICAgICAg
ICAgICBpbnRlcmZhY2Ugd2hpY2ggaXMgc3ViamVjdCB0byBjaGFuZ2UgcG9zdCA0LjIuCgogICAg
KiB4bC5jZmcoNSkgZG9jdW1lbnRhdGlvbiBwYXRjaCBmb3IgcWVtdS11cHN0cmVhbQogICAgICB2
aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0OgogICAgICBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTA1L21zZzAwMjUwLmh0bWwKICAgICAgcWVtdS11cHN0
cmVhbSBkb2Vzbid0IHN1cHBvcnQgc3BlY2lmeWluZyB2aWRlb21lbSBzaXplIGZvciB0aGUKICAg
ICAgSFZNIGd1ZXN0IGNpcnJ1cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29ya3Mgd2l0aAogICAgICBx
ZW11LXhlbi10cmFkaXRpb25hbCkuIChQYXNpIEvDpHJra8OkaW5lbikKCiAgICAqIFtCVUddIGxv
bmcgc3RvcCBkdXJpbmcgdGhlIGd1ZXN0IGJvb3QgcHJvY2VzcyB3aXRoIHFjb3cgaW1hZ2UsCiAg
ICAgIHJlcG9ydGVkIGJ5IEludGVsOiBodHRwOi8vYnVnemlsbGEueGVuLm9yZy9idWd6aWxsYS9z
aG93X2J1Zy5jZ2k/aWQ9MTgyMQoKICAgICogW0JVR10gdmNwdS1zZXQgZG9lc24ndCB0YWtlIGVm
ZmVjdCBvbiBndWVzdCwgcmVwb3J0ZWQgYnkgSW50ZWw6CiAgICAgIGh0dHA6Ly9idWd6aWxsYS54
ZW4ub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0xODIyCgogICAgKiBMb2FkIGJsa3RhcCBk
cml2ZXIgZnJvbSB4ZW5jb21tb25zIGluaXRzY3JpcHQgaWYgYXZhaWxhYmxlLCB0aHJlYWQgYXQ6
CiAgICAgIDxkYjYxNGU5MmZhZjc0M2UyMGIzZi4xMzM3MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4
ZWQgbW9yZQogICAgICBwcm9wZXJseSBpbiA0LjMuIChQYXRjaCBwb3N0ZWQsIGRpc2N1c3Npb24s
IHBsYW4gdG8gdGFrZSBzaW1wbGUKICAgICAgeGVuY29tbW9ucyBwYXRjaCBmb3IgNC4yIGFuZCBy
ZXZpc3QgZm9yIDQuMykKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 26 08:49:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:49: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 1SjRS2-0001f7-Jz; Tue, 26 Jun 2012 08:48:46 +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 1SjRS1-0001f2-8A
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:48:45 +0000
Received: from [193.109.254.147:57534] by server-11.bemta-14.messagelabs.com
	id D0/27-24843-C6779EF4; Tue, 26 Jun 2012 08:48:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340700522!8584378!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28405 invoked from network); 26 Jun 2012 08:48:43 -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 Jun 2012 08:48:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200042379"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 04:48:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 04:48:41 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SjRRx-0003GA-LD;
	Tue, 26 Jun 2012 09:48:41 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Jun 2012 09:48:41 +0100
Message-ID: <1340700521-13012-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: netdev@vger.kernel.org, stable@kernel.org, 675190@bugs.debian.org,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/netfront: teardown the device before
	unregistering it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fixes:
[   15.470311] WARNING: at /local/scratch/ianc/devel/kernels/linux/fs/sysfs/file.c:498 sysfs_attr_ns+0x95/0xa0()
[   15.470326] sysfs: kobject eth0 without dirent
[   15.470333] Modules linked in:
[   15.470342] Pid: 12, comm: xenwatch Not tainted 3.4.0-x86_32p-xenU #93
and
[    9.150554] BUG: unable to handle kernel paging request at 2b359000
[    9.150577] IP: [<c1279561>] linkwatch_do_dev+0x81/0xc0
[    9.150592] *pdpt = 000000002c3c9027 *pde = 0000000000000000
[    9.150604] Oops: 0002 [#1] SMP
[    9.150613] Modules linked in:

This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675190

Reported-by: George Shuklin <george.shuklin@gmail.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: William Dauchy <wdauchy@gmail.com>
Cc: stable@kernel.org
Cc: 675190@bugs.debian.org
---
 drivers/net/xen-netfront.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0ebbb19..796afbf 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1935,14 +1935,14 @@ static int __devexit xennet_remove(struct xenbus_device *dev)
 
 	dev_dbg(&dev->dev, "%s\n", dev->nodename);
 
-	unregister_netdev(info->netdev);
-
 	xennet_disconnect_backend(info);
 
-	del_timer_sync(&info->rx_refill_timer);
-
 	xennet_sysfs_delif(info->netdev);
 
+	unregister_netdev(info->netdev);
+
+	del_timer_sync(&info->rx_refill_timer);
+
 	free_percpu(info->stats);
 
 	free_netdev(info->netdev);
-- 
1.7.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 Jun 26 08:49:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:49: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 1SjRS2-0001f7-Jz; Tue, 26 Jun 2012 08:48:46 +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 1SjRS1-0001f2-8A
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:48:45 +0000
Received: from [193.109.254.147:57534] by server-11.bemta-14.messagelabs.com
	id D0/27-24843-C6779EF4; Tue, 26 Jun 2012 08:48:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340700522!8584378!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28405 invoked from network); 26 Jun 2012 08:48:43 -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 Jun 2012 08:48:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200042379"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 04:48:42 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 04:48:41 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SjRRx-0003GA-LD;
	Tue, 26 Jun 2012 09:48:41 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Jun 2012 09:48:41 +0100
Message-ID: <1340700521-13012-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: netdev@vger.kernel.org, stable@kernel.org, 675190@bugs.debian.org,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/netfront: teardown the device before
	unregistering it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fixes:
[   15.470311] WARNING: at /local/scratch/ianc/devel/kernels/linux/fs/sysfs/file.c:498 sysfs_attr_ns+0x95/0xa0()
[   15.470326] sysfs: kobject eth0 without dirent
[   15.470333] Modules linked in:
[   15.470342] Pid: 12, comm: xenwatch Not tainted 3.4.0-x86_32p-xenU #93
and
[    9.150554] BUG: unable to handle kernel paging request at 2b359000
[    9.150577] IP: [<c1279561>] linkwatch_do_dev+0x81/0xc0
[    9.150592] *pdpt = 000000002c3c9027 *pde = 0000000000000000
[    9.150604] Oops: 0002 [#1] SMP
[    9.150613] Modules linked in:

This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675190

Reported-by: George Shuklin <george.shuklin@gmail.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: William Dauchy <wdauchy@gmail.com>
Cc: stable@kernel.org
Cc: 675190@bugs.debian.org
---
 drivers/net/xen-netfront.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0ebbb19..796afbf 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1935,14 +1935,14 @@ static int __devexit xennet_remove(struct xenbus_device *dev)
 
 	dev_dbg(&dev->dev, "%s\n", dev->nodename);
 
-	unregister_netdev(info->netdev);
-
 	xennet_disconnect_backend(info);
 
-	del_timer_sync(&info->rx_refill_timer);
-
 	xennet_sysfs_delif(info->netdev);
 
+	unregister_netdev(info->netdev);
+
+	del_timer_sync(&info->rx_refill_timer);
+
 	free_percpu(info->stats);
 
 	free_netdev(info->netdev);
-- 
1.7.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 Jun 26 08:57:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:57:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjRZy-0001sM-S8; Tue, 26 Jun 2012 08:56:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SjRZx-0001s4-5V
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:56:57 +0000
Received: from [85.158.143.35:56560] by server-1.bemta-4.messagelabs.com id
	4B/A9-24392-75979EF4; Tue, 26 Jun 2012 08:56:55 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340701010!18056881!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5293 invoked from network); 26 Jun 2012 08:56:51 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:56:51 -0000
Received: by ghrr14 with SMTP id r14so4206807ghr.32
	for <multiple recipients>; Tue, 26 Jun 2012 01:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=30bjfpgPI9SRBQa0EAwbs/iYruGKvstA+8h8LT+VJK0=;
	b=vBYr1Rgfrmg9w5/Acj4v9GKfOusbxPuQthiLH8TiY5PnDccpsrvcAao5DEgdtA32ID
	mBR5hYzZS5czdZ19kdCDUWiP2Z4uRWxxtA2rqHn2m15NPqpTH9mHa37ur0myi7Pk72KB
	g55nkmCETddDk4lXsbOaGQBVJhWti+NI3/W+9Muk9JT+lM/z/tIMbKdRvPTPs9ejGOMm
	d+GcRVLbQLgyPkUwtkmrc+uNXHy6e32FlVX2fTSajlYWHpJNArNz55Wnz5+myXDlp+55
	5owWXOihbd+8wwQLLrA1u0T6oFpbj5IeomY8JWzEAQo1bCl0NKn8vY4JuHR7NM7GY91B
	BLuw==
MIME-Version: 1.0
Received: by 10.42.20.201 with SMTP id h9mr7436257icb.36.1340701009707; Tue,
	26 Jun 2012 01:56:49 -0700 (PDT)
Received: by 10.231.45.13 with HTTP; Tue, 26 Jun 2012 01:56:49 -0700 (PDT)
Date: Tue, 26 Jun 2012 09:56:49 +0100
Message-ID: <CAOqnZH6fob7Wp-xS6c4cp5xPmL7WDZKp2kdgqcDyL+D8wxh2hw@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-api@lists.xen.org, xen-users@lists.xen.org, xen-devel@lists.xen.org
Subject: [Xen-devel] Document Day : Thank you and Stats
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4893789370344120580=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4893789370344120580==
Content-Type: multipart/alternative; boundary=20cf30266e386f019604c35c47f0

--20cf30266e386f019604c35c47f0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good morning,

I wanted to thank everybody who made contributions to the Xen Document Day
yesterday. In particular Dariof, Dunlapg, Ijc, Peetaur, Royger,
StefanoStabellini and Ijackson. On the Xen wiki we changed approximately
11K words in more than 200 changesets.

I am aware of the following changes to the following pages, which include a
few pages outside the Xen wiki (but the list is probably not complete).
Some were new pages with lots of content, some were minor changes.

   - http://en.wikipedia.org/wiki/Xen
   - https://help.ubuntu.com/community/Xen
   - ArchLinuxasXenGuest
   - ArchLinuxasXenHost=E2=80=8E
   - CategoriesforAuthors=E2=80=8E
   - CategoriesforUsers=E2=80=8E
   - Category:AlpineLinux=E2=80=8E
   - Category:ArchLinux=E2=80=8E
   - Category:Events=E2=80=8E
   - Category:Fedora=E2=80=8E
   - Category:FreeBSD=E2=80=8E
   - Category:GuestInstall=E2=80=8E
   - Category:Manual=E2=80=8E
   - Category:Networking=E2=80=8E
   - Category:OCaml=E2=80=8E
   - Category:OpenIndiana=E2=80=8E
   - Category:Performance=E2=80=8E
   - Category:RefToExternalArticle=E2=80=8E
   - Category:Solaris=E2=80=8E
   - Category:Ubuntu=E2=80=8E
   - Category:VGA=E2=80=8E
   - Categorytalk:RefToExternalArticle=E2=80=8E
   - Distros=E2=80=8E
   - Dom0KernelsforXen=E2=80=8E
   - DomUSupportforXen=E2=80=8E
   - Fedora16Dom0=E2=80=8E
   - FedoraHostInstallation=E2=80=8E
   - FreeBSD9.064-bitHVMonXCP1.1=E2=80=8E
   - GettingStarted=E2=80=8E
   - Hackathon=E2=80=8E
   - Help:Contents=E2=80=8E
   - HostConfiguration/Networking=E2=80=8E
   - HowtoinstallaopenSuSEdomUonaDebiandom0=E2=80=8E
   - Linux3.0bugsimpactingXen=E2=80=8E
   - LiveCD=E2=80=8E
   - MainPage=E2=80=8E
   - MediaWiki:Sidebar=E2=80=8E
   - NetworkingwiththeXCPtoolstack=E2=80=8E
   - NetworkThroughputandPerformanceGuide=E2=80=8E
   - NTemplate:HalfDone=E2=80=8E
   - ReportingBugsagainstXCP=E2=80=8E
   - ReportingBugsagainstXen=E2=80=8E
   - Storageoptions=E2=80=8E
   - Talk:FedoraHostInstallation=E2=80=8E
   - Talk:XenDocumentDays/TODO=E2=80=8E
   - Template:DistroResources=E2=80=8E
   - Template:Tick=E2=80=8E
   - Template:Tick/doc=E2=80=8E
   - Tuning=E2=80=8E
   - WikiCommunity=E2=80=8E
   - Xen4.xManuals=E2=80=8E
   - XenDocumentDays=E2=80=8E
   - XenDocumentDays/TODO=E2=80=8E
   - XenFAQHelp=E2=80=8E
   - XenFAQNetworking=E2=80=8E
   - XenMaintainer,CommitterandDeveloperMeeting=E2=80=8E
   - XenMaintainer,CommitterandDeveloperMeeting/June2012Minutes=E2=80=8E
   - XenMaintainer,CommitterandDeveloperMeeting/XenSummitNA2012=E2=80=8E
   - XenNetworking=E2=80=8E
   - XenOverview=E2=80=8E
   - XenPCIPassthrough=E2=80=8E
   - XenReleaseFeatures=E2=80=8E
   - XenStorageManagement=E2=80=8E

Thank you again
Lars

--20cf30266e386f019604c35c47f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good morning,<br><br>I wanted to thank everybody who made contributions to =
the Xen Document Day yesterday. In particular Dariof, Dunlapg, Ijc, Peetaur=
, Royger, StefanoStabellini and Ijackson. On the Xen wiki we changed approx=
imately 11K words in more than 200 changesets.<br>
<br>I am aware of the following changes to the following pages, which inclu=
de a few pages outside the Xen wiki (but the list is probably not complete)=
. Some were new pages with lots of content, some were minor changes.<br>
<ul><li><a href=3D"http://en.wikipedia.org/wiki/Xen">http://en.wikipedia.or=
g/wiki/Xen</a></li><li>
<a href=3D"https://help.ubuntu.com/community/Xen">https://help.ubuntu.com/c=
ommunity/Xen</a></li><li>ArchLinuxasXenGuest</li><li>ArchLinuxasXenHost=E2=
=80=8E</li><li>CategoriesforAuthors=E2=80=8E</li><li>CategoriesforUsers=E2=
=80=8E</li><li>Category:AlpineLinux=E2=80=8E</li>
<li>Category:ArchLinux=E2=80=8E</li><li>Category:Events=E2=80=8E</li><li>Ca=
tegory:Fedora=E2=80=8E</li><li>Category:FreeBSD=E2=80=8E</li><li>Category:G=
uestInstall=E2=80=8E</li><li>Category:Manual=E2=80=8E</li><li>Category:Netw=
orking=E2=80=8E</li><li>Category:OCaml=E2=80=8E</li><li>Category:OpenIndian=
a=E2=80=8E</li>
<li>Category:Performance=E2=80=8E</li><li>Category:RefToExternalArticle=E2=
=80=8E</li><li>Category:Solaris=E2=80=8E</li><li>Category:Ubuntu=E2=80=8E</=
li><li>Category:VGA=E2=80=8E</li><li>Categorytalk:RefToExternalArticle=E2=
=80=8E</li><li>Distros=E2=80=8E</li><li>Dom0KernelsforXen=E2=80=8E</li>
<li>DomUSupportforXen=E2=80=8E</li><li>Fedora16Dom0=E2=80=8E</li><li>Fedora=
HostInstallation=E2=80=8E</li><li>FreeBSD9.064-bitHVMonXCP1.1=E2=80=8E</li>=
<li>GettingStarted=E2=80=8E</li><li>Hackathon=E2=80=8E</li><li>Help:Content=
s=E2=80=8E</li><li>HostConfiguration/Networking=E2=80=8E</li>
<li>HowtoinstallaopenSuSEdomUonaDebiandom0=E2=80=8E</li><li>Linux3.0bugsimp=
actingXen=E2=80=8E</li><li>LiveCD=E2=80=8E</li><li>MainPage=E2=80=8E</li><l=
i>MediaWiki:Sidebar=E2=80=8E</li><li>NetworkingwiththeXCPtoolstack=E2=80=8E=
</li><li>NetworkThroughputandPerformanceGuide=E2=80=8E</li>
<li>NTemplate:HalfDone=E2=80=8E</li><li>ReportingBugsagainstXCP=E2=80=8E</l=
i><li>ReportingBugsagainstXen=E2=80=8E</li><li>Storageoptions=E2=80=8E</li>=
<li>Talk:FedoraHostInstallation=E2=80=8E</li><li>Talk:XenDocumentDays/TODO=
=E2=80=8E</li><li>Template:DistroResources=E2=80=8E</li>
<li>Template:Tick=E2=80=8E</li><li>Template:Tick/doc=E2=80=8E</li><li>Tunin=
g=E2=80=8E</li><li>WikiCommunity=E2=80=8E</li><li>Xen4.xManuals=E2=80=8E</l=
i><li>XenDocumentDays=E2=80=8E</li><li>XenDocumentDays/TODO=E2=80=8E</li><l=
i>XenFAQHelp=E2=80=8E</li><li>XenFAQNetworking=E2=80=8E</li><li>XenMaintain=
er,CommitterandDeveloperMeeting=E2=80=8E</li>
<li>XenMaintainer,CommitterandDeveloperMeeting/June2012Minutes=E2=80=8E</li=
><li>XenMaintainer,CommitterandDeveloperMeeting/XenSummitNA2012=E2=80=8E</l=
i><li>XenNetworking=E2=80=8E</li><li>XenOverview=E2=80=8E</li><li>XenPCIPas=
sthrough=E2=80=8E</li><li>XenReleaseFeatures=E2=80=8E</li>
<li>XenStorageManagement=E2=80=8E</li></ul>
Thank you again<br>Lars<br>

--20cf30266e386f019604c35c47f0--


--===============4893789370344120580==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4893789370344120580==--


From xen-devel-bounces@lists.xen.org Tue Jun 26 08:57:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:57:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjRZy-0001sM-S8; Tue, 26 Jun 2012 08:56:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1SjRZx-0001s4-5V
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:56:57 +0000
Received: from [85.158.143.35:56560] by server-1.bemta-4.messagelabs.com id
	4B/A9-24392-75979EF4; Tue, 26 Jun 2012 08:56:55 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340701010!18056881!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5293 invoked from network); 26 Jun 2012 08:56:51 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:56:51 -0000
Received: by ghrr14 with SMTP id r14so4206807ghr.32
	for <multiple recipients>; Tue, 26 Jun 2012 01:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=30bjfpgPI9SRBQa0EAwbs/iYruGKvstA+8h8LT+VJK0=;
	b=vBYr1Rgfrmg9w5/Acj4v9GKfOusbxPuQthiLH8TiY5PnDccpsrvcAao5DEgdtA32ID
	mBR5hYzZS5czdZ19kdCDUWiP2Z4uRWxxtA2rqHn2m15NPqpTH9mHa37ur0myi7Pk72KB
	g55nkmCETddDk4lXsbOaGQBVJhWti+NI3/W+9Muk9JT+lM/z/tIMbKdRvPTPs9ejGOMm
	d+GcRVLbQLgyPkUwtkmrc+uNXHy6e32FlVX2fTSajlYWHpJNArNz55Wnz5+myXDlp+55
	5owWXOihbd+8wwQLLrA1u0T6oFpbj5IeomY8JWzEAQo1bCl0NKn8vY4JuHR7NM7GY91B
	BLuw==
MIME-Version: 1.0
Received: by 10.42.20.201 with SMTP id h9mr7436257icb.36.1340701009707; Tue,
	26 Jun 2012 01:56:49 -0700 (PDT)
Received: by 10.231.45.13 with HTTP; Tue, 26 Jun 2012 01:56:49 -0700 (PDT)
Date: Tue, 26 Jun 2012 09:56:49 +0100
Message-ID: <CAOqnZH6fob7Wp-xS6c4cp5xPmL7WDZKp2kdgqcDyL+D8wxh2hw@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-api@lists.xen.org, xen-users@lists.xen.org, xen-devel@lists.xen.org
Subject: [Xen-devel] Document Day : Thank you and Stats
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4893789370344120580=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4893789370344120580==
Content-Type: multipart/alternative; boundary=20cf30266e386f019604c35c47f0

--20cf30266e386f019604c35c47f0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good morning,

I wanted to thank everybody who made contributions to the Xen Document Day
yesterday. In particular Dariof, Dunlapg, Ijc, Peetaur, Royger,
StefanoStabellini and Ijackson. On the Xen wiki we changed approximately
11K words in more than 200 changesets.

I am aware of the following changes to the following pages, which include a
few pages outside the Xen wiki (but the list is probably not complete).
Some were new pages with lots of content, some were minor changes.

   - http://en.wikipedia.org/wiki/Xen
   - https://help.ubuntu.com/community/Xen
   - ArchLinuxasXenGuest
   - ArchLinuxasXenHost=E2=80=8E
   - CategoriesforAuthors=E2=80=8E
   - CategoriesforUsers=E2=80=8E
   - Category:AlpineLinux=E2=80=8E
   - Category:ArchLinux=E2=80=8E
   - Category:Events=E2=80=8E
   - Category:Fedora=E2=80=8E
   - Category:FreeBSD=E2=80=8E
   - Category:GuestInstall=E2=80=8E
   - Category:Manual=E2=80=8E
   - Category:Networking=E2=80=8E
   - Category:OCaml=E2=80=8E
   - Category:OpenIndiana=E2=80=8E
   - Category:Performance=E2=80=8E
   - Category:RefToExternalArticle=E2=80=8E
   - Category:Solaris=E2=80=8E
   - Category:Ubuntu=E2=80=8E
   - Category:VGA=E2=80=8E
   - Categorytalk:RefToExternalArticle=E2=80=8E
   - Distros=E2=80=8E
   - Dom0KernelsforXen=E2=80=8E
   - DomUSupportforXen=E2=80=8E
   - Fedora16Dom0=E2=80=8E
   - FedoraHostInstallation=E2=80=8E
   - FreeBSD9.064-bitHVMonXCP1.1=E2=80=8E
   - GettingStarted=E2=80=8E
   - Hackathon=E2=80=8E
   - Help:Contents=E2=80=8E
   - HostConfiguration/Networking=E2=80=8E
   - HowtoinstallaopenSuSEdomUonaDebiandom0=E2=80=8E
   - Linux3.0bugsimpactingXen=E2=80=8E
   - LiveCD=E2=80=8E
   - MainPage=E2=80=8E
   - MediaWiki:Sidebar=E2=80=8E
   - NetworkingwiththeXCPtoolstack=E2=80=8E
   - NetworkThroughputandPerformanceGuide=E2=80=8E
   - NTemplate:HalfDone=E2=80=8E
   - ReportingBugsagainstXCP=E2=80=8E
   - ReportingBugsagainstXen=E2=80=8E
   - Storageoptions=E2=80=8E
   - Talk:FedoraHostInstallation=E2=80=8E
   - Talk:XenDocumentDays/TODO=E2=80=8E
   - Template:DistroResources=E2=80=8E
   - Template:Tick=E2=80=8E
   - Template:Tick/doc=E2=80=8E
   - Tuning=E2=80=8E
   - WikiCommunity=E2=80=8E
   - Xen4.xManuals=E2=80=8E
   - XenDocumentDays=E2=80=8E
   - XenDocumentDays/TODO=E2=80=8E
   - XenFAQHelp=E2=80=8E
   - XenFAQNetworking=E2=80=8E
   - XenMaintainer,CommitterandDeveloperMeeting=E2=80=8E
   - XenMaintainer,CommitterandDeveloperMeeting/June2012Minutes=E2=80=8E
   - XenMaintainer,CommitterandDeveloperMeeting/XenSummitNA2012=E2=80=8E
   - XenNetworking=E2=80=8E
   - XenOverview=E2=80=8E
   - XenPCIPassthrough=E2=80=8E
   - XenReleaseFeatures=E2=80=8E
   - XenStorageManagement=E2=80=8E

Thank you again
Lars

--20cf30266e386f019604c35c47f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good morning,<br><br>I wanted to thank everybody who made contributions to =
the Xen Document Day yesterday. In particular Dariof, Dunlapg, Ijc, Peetaur=
, Royger, StefanoStabellini and Ijackson. On the Xen wiki we changed approx=
imately 11K words in more than 200 changesets.<br>
<br>I am aware of the following changes to the following pages, which inclu=
de a few pages outside the Xen wiki (but the list is probably not complete)=
. Some were new pages with lots of content, some were minor changes.<br>
<ul><li><a href=3D"http://en.wikipedia.org/wiki/Xen">http://en.wikipedia.or=
g/wiki/Xen</a></li><li>
<a href=3D"https://help.ubuntu.com/community/Xen">https://help.ubuntu.com/c=
ommunity/Xen</a></li><li>ArchLinuxasXenGuest</li><li>ArchLinuxasXenHost=E2=
=80=8E</li><li>CategoriesforAuthors=E2=80=8E</li><li>CategoriesforUsers=E2=
=80=8E</li><li>Category:AlpineLinux=E2=80=8E</li>
<li>Category:ArchLinux=E2=80=8E</li><li>Category:Events=E2=80=8E</li><li>Ca=
tegory:Fedora=E2=80=8E</li><li>Category:FreeBSD=E2=80=8E</li><li>Category:G=
uestInstall=E2=80=8E</li><li>Category:Manual=E2=80=8E</li><li>Category:Netw=
orking=E2=80=8E</li><li>Category:OCaml=E2=80=8E</li><li>Category:OpenIndian=
a=E2=80=8E</li>
<li>Category:Performance=E2=80=8E</li><li>Category:RefToExternalArticle=E2=
=80=8E</li><li>Category:Solaris=E2=80=8E</li><li>Category:Ubuntu=E2=80=8E</=
li><li>Category:VGA=E2=80=8E</li><li>Categorytalk:RefToExternalArticle=E2=
=80=8E</li><li>Distros=E2=80=8E</li><li>Dom0KernelsforXen=E2=80=8E</li>
<li>DomUSupportforXen=E2=80=8E</li><li>Fedora16Dom0=E2=80=8E</li><li>Fedora=
HostInstallation=E2=80=8E</li><li>FreeBSD9.064-bitHVMonXCP1.1=E2=80=8E</li>=
<li>GettingStarted=E2=80=8E</li><li>Hackathon=E2=80=8E</li><li>Help:Content=
s=E2=80=8E</li><li>HostConfiguration/Networking=E2=80=8E</li>
<li>HowtoinstallaopenSuSEdomUonaDebiandom0=E2=80=8E</li><li>Linux3.0bugsimp=
actingXen=E2=80=8E</li><li>LiveCD=E2=80=8E</li><li>MainPage=E2=80=8E</li><l=
i>MediaWiki:Sidebar=E2=80=8E</li><li>NetworkingwiththeXCPtoolstack=E2=80=8E=
</li><li>NetworkThroughputandPerformanceGuide=E2=80=8E</li>
<li>NTemplate:HalfDone=E2=80=8E</li><li>ReportingBugsagainstXCP=E2=80=8E</l=
i><li>ReportingBugsagainstXen=E2=80=8E</li><li>Storageoptions=E2=80=8E</li>=
<li>Talk:FedoraHostInstallation=E2=80=8E</li><li>Talk:XenDocumentDays/TODO=
=E2=80=8E</li><li>Template:DistroResources=E2=80=8E</li>
<li>Template:Tick=E2=80=8E</li><li>Template:Tick/doc=E2=80=8E</li><li>Tunin=
g=E2=80=8E</li><li>WikiCommunity=E2=80=8E</li><li>Xen4.xManuals=E2=80=8E</l=
i><li>XenDocumentDays=E2=80=8E</li><li>XenDocumentDays/TODO=E2=80=8E</li><l=
i>XenFAQHelp=E2=80=8E</li><li>XenFAQNetworking=E2=80=8E</li><li>XenMaintain=
er,CommitterandDeveloperMeeting=E2=80=8E</li>
<li>XenMaintainer,CommitterandDeveloperMeeting/June2012Minutes=E2=80=8E</li=
><li>XenMaintainer,CommitterandDeveloperMeeting/XenSummitNA2012=E2=80=8E</l=
i><li>XenNetworking=E2=80=8E</li><li>XenOverview=E2=80=8E</li><li>XenPCIPas=
sthrough=E2=80=8E</li><li>XenReleaseFeatures=E2=80=8E</li>
<li>XenStorageManagement=E2=80=8E</li></ul>
Thank you again<br>Lars<br>

--20cf30266e386f019604c35c47f0--


--===============4893789370344120580==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4893789370344120580==--


From xen-devel-bounces@lists.xen.org Tue Jun 26 08:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:58: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 1SjRbY-000260-CS; Tue, 26 Jun 2012 08:58:36 +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 1SjRbW-00025n-9x
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:58:34 +0000
Received: from [85.158.143.35:22011] by server-2.bemta-4.messagelabs.com id
	29/B8-17938-9B979EF4; Tue, 26 Jun 2012 08:58:33 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340701111!13841274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24869 invoked from network); 26 Jun 2012 08:58:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:58:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13216619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 08:57:51 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 09:57:50 +0100
Message-ID: <4FE9798C.90203@citrix.com>
Date: Tue, 26 Jun 2012 09:57:48 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-14-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
	<20432.48963.214910.33148@mariner.uk.xensource.com>
	<20452.23358.366361.231273@mariner.uk.xensource.com>
In-Reply-To: <20452.23358.366361.231273@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl [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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 13/13] libxl: call hotplug scripts for nic devices from libxl"):
>> Since most of the needed work is already done in previous patches,
>> this patch only contains the necessary code to call hotplug scripts
>> for nic devices, that should be called when the device is added or
>> removed from a guest.
>
> Thanks.
>
> Acked-by: Ian Jackson<ian.jackson@eu.citrix.com>
>
> However, AFAICT you missed this comment of mine:
>> Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
>>> +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
>>> +{
>> ...
>>> +    }
>>> +
>>> +out:
>>> +    return rc;
>>> +}
>>> +
>> As a matter of good practice I think you should say
>>        rc = 0;
>> just before out, on the success path, and not rely on it having
>> happened to be set to 0 by the previous successful call.
>
> So IWBNI in the next version you did that too.

Sorry, I will add that and the acked-by on the next repost.

> 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 Jun 26 08:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 08:58: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 1SjRbY-000260-CS; Tue, 26 Jun 2012 08:58:36 +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 1SjRbW-00025n-9x
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 08:58:34 +0000
Received: from [85.158.143.35:22011] by server-2.bemta-4.messagelabs.com id
	29/B8-17938-9B979EF4; Tue, 26 Jun 2012 08:58:33 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340701111!13841274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24869 invoked from network); 26 Jun 2012 08:58:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 08:58:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13216619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 08:57:51 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 09:57:50 +0100
Message-ID: <4FE9798C.90203@citrix.com>
Date: Tue, 26 Jun 2012 09:57:48 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-14-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-1-git-send-email-roger.pau@citrix.com>
	<1338383275-21315-10-git-send-email-roger.pau@citrix.com>
	<20432.48963.214910.33148@mariner.uk.xensource.com>
	<20452.23358.366361.231273@mariner.uk.xensource.com>
In-Reply-To: <20452.23358.366361.231273@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 09/10] libxl: call hotplug scripts for
 nic devices from libxl [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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 13/13] libxl: call hotplug scripts for nic devices from libxl"):
>> Since most of the needed work is already done in previous patches,
>> this patch only contains the necessary code to call hotplug scripts
>> for nic devices, that should be called when the device is added or
>> removed from a guest.
>
> Thanks.
>
> Acked-by: Ian Jackson<ian.jackson@eu.citrix.com>
>
> However, AFAICT you missed this comment of mine:
>> Roger Pau Monne writes ("[PATCH v5 09/10] libxl: call hotplug scripts for nic devices from libxl"):
>>> +int libxl__nic_type(libxl__gc *gc, libxl__device *dev, libxl_nic_type *nictype)
>>> +{
>> ...
>>> +    }
>>> +
>>> +out:
>>> +    return rc;
>>> +}
>>> +
>> As a matter of good practice I think you should say
>>        rc = 0;
>> just before out, on the success path, and not rely on it having
>> happened to be set to 0 by the previous successful call.
>
> So IWBNI in the next version you did that too.

Sorry, I will add that and the acked-by on the next repost.

> 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 Jun 26 09:04:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09: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 1SjRgc-0002Yu-8u; Tue, 26 Jun 2012 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 1SjRgb-0002Yo-JV
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:03:49 +0000
Received: from [85.158.139.83:25895] by server-12.bemta-5.messagelabs.com id
	0E/BC-25233-4FA79EF4; Tue, 26 Jun 2012 09:03:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340701427!24379471!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28966 invoked from network); 26 Jun 2012 09:03:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13216814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:03:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:03:01 +0100
Message-ID: <1340701380.3832.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 10:03:00 +0100
In-Reply-To: <alpine.DEB.2.02.1206071131370.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-27-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071131370.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 27/38] arm: split pending SPIs (global) out
 from pending PPIs and SGIs (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

On Thu, 2012-06-07 at 11:35 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
> > seems more logical.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/vgic.c          |   17 ++++++++++-------
> >  xen/include/asm-arm/domain.h |   10 ++++++++++
> >  2 files changed, 20 insertions(+), 7 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 629a0da..91d6166 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
> >      d->arch.vgic.shared_irqs =
> >          xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
> >      d->arch.vgic.pending_irqs =
> > -        xmalloc_array(struct pending_irq,
> > -                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
> > -    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
> > +        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> > +    for (i=0; i<d->arch.vgic.nr_lines; i++)
> >          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> >      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
> >          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> > @@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
> >  
> >      spin_lock_init(&v->arch.vgic.private_irqs.lock);
> >  
> > +    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> > +    for (i = 0; i < 32; i++)
> > +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> > +
> >      /* For SGI and PPI the target is always this CPU */
> >      for ( i = 0 ; i < 8 ; i++ )
> >          v->arch.vgic.private_irqs.itargets[i] =
> > @@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
> >      /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
> >       * are used for SPIs; the rests are used for per cpu irqs */
> >      if ( irq < 32 )
> > -        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
> > -            + v->domain->arch.vgic.nr_lines];
> > +        n = &v->arch.vgic.pending_irqs[irq];
> >      else
> >          n = &v->domain->arch.vgic.pending_irqs[irq - 32];
> >      return n;
> > @@ -548,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
> >      uint8_t priority;
> >      struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
> >      struct pending_irq *iter, *n = irq_to_pending(v, irq);
> > +    unsigned long flags;
> >  
> >      /* irq still pending */
> >      if (!list_empty(&n->inflight))
> > @@ -564,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
> >  
> >      gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
> >  
> > -    spin_lock(&v->arch.vgic.lock);
> > +    spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
> >      {
> >          if ( iter->priority > priority )
> > @@ -575,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
> >          }
> >      }
> >      list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
> > -    spin_unlock(&v->arch.vgic.lock);
> > +    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> >      /* we have a new higher priority irq, inject it into the guest */
> >  }
> 
> Besides moving PPIs and SGIs to struct vcpu, this patch also turns
> spin_lock into spin_lock_irqsave in vgic_vcpu_inject_irq: I think it is
> correct because it can be called in IRQ context,

good point.

> but it needs to be explicitly stated in the commit message.

I've split it into its own patch instead:

8<----------------------------------------

>From 6d4f199127488480f9a9cc2a94bb73734a75ff88 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 26 Jun 2012 09:00:55 +0000
Subject: [PATCH] arm: use interrupt safe spin locks in vgic_vcpu_inject_irq

This function can be called in both interrupt and regular context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..91d6166 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
@@ -577,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Jun 26 09:04:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09: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 1SjRgc-0002Yu-8u; Tue, 26 Jun 2012 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 1SjRgb-0002Yo-JV
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:03:49 +0000
Received: from [85.158.139.83:25895] by server-12.bemta-5.messagelabs.com id
	0E/BC-25233-4FA79EF4; Tue, 26 Jun 2012 09:03:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340701427!24379471!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI0NTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28966 invoked from network); 26 Jun 2012 09:03:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13216814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:03:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:03:01 +0100
Message-ID: <1340701380.3832.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 10:03:00 +0100
In-Reply-To: <alpine.DEB.2.02.1206071131370.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-27-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071131370.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 27/38] arm: split pending SPIs (global) out
 from pending PPIs and SGIs (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

On Thu, 2012-06-07 at 11:35 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
> > seems more logical.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/vgic.c          |   17 ++++++++++-------
> >  xen/include/asm-arm/domain.h |   10 ++++++++++
> >  2 files changed, 20 insertions(+), 7 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 629a0da..91d6166 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
> >      d->arch.vgic.shared_irqs =
> >          xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
> >      d->arch.vgic.pending_irqs =
> > -        xmalloc_array(struct pending_irq,
> > -                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
> > -    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
> > +        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> > +    for (i=0; i<d->arch.vgic.nr_lines; i++)
> >          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> >      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
> >          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> > @@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
> >  
> >      spin_lock_init(&v->arch.vgic.private_irqs.lock);
> >  
> > +    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> > +    for (i = 0; i < 32; i++)
> > +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> > +
> >      /* For SGI and PPI the target is always this CPU */
> >      for ( i = 0 ; i < 8 ; i++ )
> >          v->arch.vgic.private_irqs.itargets[i] =
> > @@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
> >      /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
> >       * are used for SPIs; the rests are used for per cpu irqs */
> >      if ( irq < 32 )
> > -        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
> > -            + v->domain->arch.vgic.nr_lines];
> > +        n = &v->arch.vgic.pending_irqs[irq];
> >      else
> >          n = &v->domain->arch.vgic.pending_irqs[irq - 32];
> >      return n;
> > @@ -548,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
> >      uint8_t priority;
> >      struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
> >      struct pending_irq *iter, *n = irq_to_pending(v, irq);
> > +    unsigned long flags;
> >  
> >      /* irq still pending */
> >      if (!list_empty(&n->inflight))
> > @@ -564,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
> >  
> >      gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
> >  
> > -    spin_lock(&v->arch.vgic.lock);
> > +    spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
> >      {
> >          if ( iter->priority > priority )
> > @@ -575,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
> >          }
> >      }
> >      list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
> > -    spin_unlock(&v->arch.vgic.lock);
> > +    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> >      /* we have a new higher priority irq, inject it into the guest */
> >  }
> 
> Besides moving PPIs and SGIs to struct vcpu, this patch also turns
> spin_lock into spin_lock_irqsave in vgic_vcpu_inject_irq: I think it is
> correct because it can be called in IRQ context,

good point.

> but it needs to be explicitly stated in the commit message.

I've split it into its own patch instead:

8<----------------------------------------

>From 6d4f199127488480f9a9cc2a94bb73734a75ff88 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 26 Jun 2012 09:00:55 +0000
Subject: [PATCH] arm: use interrupt safe spin locks in vgic_vcpu_inject_irq

This function can be called in both interrupt and regular context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..91d6166 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
@@ -577,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Jun 26 09:26:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09: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 1SjS1w-0002pq-Fg; Tue, 26 Jun 2012 09:25:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjS1v-0002pl-6v
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:25:51 +0000
Received: from [85.158.139.83:35995] by server-11.bemta-5.messagelabs.com id
	23/DB-20400-E1089EF4; Tue, 26 Jun 2012 09:25:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340702749!29532568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6316 invoked from network); 26 Jun 2012 09:25:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:25:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13217586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:25:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:25:49 +0100
Message-ID: <1340702747.3832.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 10:25:47 +0100
In-Reply-To: <20120607095128.GI70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
	<20120607095128.GI70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
 not just 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, 2012-06-07 at 10:51 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565197), Ian Campbell wrote:
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index a7fb227..e15c1e8 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >  
> >          if ( (rc = p2m_alloc_table(d)) != 0 )
> >              goto fail;
> > -    }
> >  
> > -    if ( (rc = domain_vgic_init(d)) != 0 )
> > -        goto fail;
> > +        if ( (rc = gicv_setup(d)) != 0 )
> > +            goto fail;
> > +
> > +        if ( (rc = domain_vgic_init(d)) != 0 )
> > +            goto fail;
> > +    }
> >  
> >      rc = 0;
> >  fail:
> > +    /*XXX unwind allocations etc */
> 
> Ahem. :)

Indeed ;-)

I've added the following to the end of the series:

8<------------------------------------------------

>From 9b12490d654683b1c3c65eb41ab35e20cd7682db Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 7 Jun 2012 16:59:57 +0000
Subject: [PATCH] arm: unwind allocations etc on arch_domain_create_failure

This involves adding the necessary teardown/free functions for some modules.

Don't initialise full arch domain state for the idle domain, it's not needed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c     |   42 +++++++++++++++++++++++++-----------------
 xen/arch/arm/gic.h        |    3 +++
 xen/arch/arm/p2m.c        |   15 +++++++++++++++
 xen/arch/arm/vgic.c       |    6 ++++++
 xen/arch/arm/vpl011.c     |    5 +++++
 xen/arch/arm/vpl011.h     |    1 +
 xen/include/asm-arm/p2m.h |    3 +++
 7 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index c16fa02..f61568b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -317,37 +317,45 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    /* Idle domains do not need this setup */
+    if ( is_idle_domain(d) )
+        return 0;
+
     rc = -ENOMEM;
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
-    if ( !is_idle_domain(d) )
-    {
-        rc = -ENOMEM;
-        if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
-            goto fail;
+    if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
+        goto fail;
 
-        clear_page(d->shared_info);
-        share_xen_page_with_guest(
-                virt_to_page(d->shared_info), d, XENSHARE_writable);
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+        virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-        if ( (rc = p2m_alloc_table(d)) != 0 )
-            goto fail;
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        goto fail;
 
-        if ( (rc = gicv_setup(d)) != 0 )
-            goto fail;
+    if ( (rc = gicv_setup(d)) != 0 )
+        goto fail;
 
-        if ( (rc = domain_vgic_init(d)) != 0 )
-            goto fail;
-    }
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
         goto fail;
 
-    rc = 0;
+    return 0;
+
 fail:
-    /*XXX unwind allocations etc */
+    d->is_dying = DOMDYING_dead;
+    free_xenheap_page(d->shared_info);
+
+    p2m_teardown(d);
+
+    domain_vgic_free(d);
+    domain_uart0_free(d);
+
     return rc;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 018d820..e36d6ad 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -125,7 +125,10 @@
 #define VGIC_IRQ_EVTCHN_CALLBACK 31
 
 extern int domain_vgic_init(struct domain *d);
+extern void domain_vgic_free(struct domain *d);
+
 extern int vcpu_vgic_init(struct vcpu *v);
+
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 67bfeba..073216b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -288,6 +288,21 @@ int p2m_alloc_table(struct domain *d)
     return 0;
 }
 
+void p2m_teardown(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *pg;
+
+    spin_lock(&p2m->lock);
+
+    while ( (pg = page_list_remove_head(&p2m->pages)) )
+        free_domheap_page(pg);
+
+    p2m->first_level = NULL;
+
+    spin_unlock(&p2m->lock);
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 91d6166..06bbd0c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,12 @@ int domain_vgic_init(struct domain *d)
     return 0;
 }
 
+void domain_vgic_free(struct domain *d)
+{
+    xfree(d->arch.vgic.shared_irqs);
+    xfree(d->arch.vgic.pending_irqs);
+}
+
 int vcpu_vgic_init(struct vcpu *v)
 {
     int i;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dc8b28..1522667 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -56,6 +56,11 @@ int domain_uart0_init(struct domain *d)
 
 }
 
+void domain_uart0_free(struct domain *d)
+{
+    xfree(d->arch.uart0.buf);
+}
+
 static void uart0_print_char(char c)
 {
     struct vpl011 *uart = &current->domain->arch.uart0;
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
index 952d812..eabd99d 100644
--- a/xen/arch/arm/vpl011.h
+++ b/xen/arch/arm/vpl011.h
@@ -21,6 +21,7 @@
 #define __ARCH_ARM_VPL011_H__
 
 extern int domain_uart0_init(struct domain *d);
+extern void domain_uart0_free(struct domain *d);
 
 #endif
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 666bb88..14e71bf 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,6 +23,9 @@ struct p2m_domain {
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 
+/* Return all the p2m resources to Xen. */
+void p2m_teardown(struct domain *d);
+
 /* Allocate a new p2m table for a domain.
  *
  * Returns 0 for success or -errno.
-- 
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 Jun 26 09:26:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09: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 1SjS1w-0002pq-Fg; Tue, 26 Jun 2012 09:25:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjS1v-0002pl-6v
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:25:51 +0000
Received: from [85.158.139.83:35995] by server-11.bemta-5.messagelabs.com id
	23/DB-20400-E1089EF4; Tue, 26 Jun 2012 09:25:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340702749!29532568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6316 invoked from network); 26 Jun 2012 09:25:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:25:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13217586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:25:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:25:49 +0100
Message-ID: <1340702747.3832.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 10:25:47 +0100
In-Reply-To: <20120607095128.GI70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
	<20120607095128.GI70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
 not just 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, 2012-06-07 at 10:51 +0100, Tim Deegan wrote:
> At 15:39 +0000 on 01 Jun (1338565197), Ian Campbell wrote:
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index a7fb227..e15c1e8 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -329,13 +329,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >  
> >          if ( (rc = p2m_alloc_table(d)) != 0 )
> >              goto fail;
> > -    }
> >  
> > -    if ( (rc = domain_vgic_init(d)) != 0 )
> > -        goto fail;
> > +        if ( (rc = gicv_setup(d)) != 0 )
> > +            goto fail;
> > +
> > +        if ( (rc = domain_vgic_init(d)) != 0 )
> > +            goto fail;
> > +    }
> >  
> >      rc = 0;
> >  fail:
> > +    /*XXX unwind allocations etc */
> 
> Ahem. :)

Indeed ;-)

I've added the following to the end of the series:

8<------------------------------------------------

>From 9b12490d654683b1c3c65eb41ab35e20cd7682db Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 7 Jun 2012 16:59:57 +0000
Subject: [PATCH] arm: unwind allocations etc on arch_domain_create_failure

This involves adding the necessary teardown/free functions for some modules.

Don't initialise full arch domain state for the idle domain, it's not needed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c     |   42 +++++++++++++++++++++++++-----------------
 xen/arch/arm/gic.h        |    3 +++
 xen/arch/arm/p2m.c        |   15 +++++++++++++++
 xen/arch/arm/vgic.c       |    6 ++++++
 xen/arch/arm/vpl011.c     |    5 +++++
 xen/arch/arm/vpl011.h     |    1 +
 xen/include/asm-arm/p2m.h |    3 +++
 7 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index c16fa02..f61568b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -317,37 +317,45 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    /* Idle domains do not need this setup */
+    if ( is_idle_domain(d) )
+        return 0;
+
     rc = -ENOMEM;
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
-    if ( !is_idle_domain(d) )
-    {
-        rc = -ENOMEM;
-        if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
-            goto fail;
+    if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
+        goto fail;
 
-        clear_page(d->shared_info);
-        share_xen_page_with_guest(
-                virt_to_page(d->shared_info), d, XENSHARE_writable);
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+        virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-        if ( (rc = p2m_alloc_table(d)) != 0 )
-            goto fail;
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        goto fail;
 
-        if ( (rc = gicv_setup(d)) != 0 )
-            goto fail;
+    if ( (rc = gicv_setup(d)) != 0 )
+        goto fail;
 
-        if ( (rc = domain_vgic_init(d)) != 0 )
-            goto fail;
-    }
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
         goto fail;
 
-    rc = 0;
+    return 0;
+
 fail:
-    /*XXX unwind allocations etc */
+    d->is_dying = DOMDYING_dead;
+    free_xenheap_page(d->shared_info);
+
+    p2m_teardown(d);
+
+    domain_vgic_free(d);
+    domain_uart0_free(d);
+
     return rc;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 018d820..e36d6ad 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -125,7 +125,10 @@
 #define VGIC_IRQ_EVTCHN_CALLBACK 31
 
 extern int domain_vgic_init(struct domain *d);
+extern void domain_vgic_free(struct domain *d);
+
 extern int vcpu_vgic_init(struct vcpu *v);
+
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 67bfeba..073216b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -288,6 +288,21 @@ int p2m_alloc_table(struct domain *d)
     return 0;
 }
 
+void p2m_teardown(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *pg;
+
+    spin_lock(&p2m->lock);
+
+    while ( (pg = page_list_remove_head(&p2m->pages)) )
+        free_domheap_page(pg);
+
+    p2m->first_level = NULL;
+
+    spin_unlock(&p2m->lock);
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 91d6166..06bbd0c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,12 @@ int domain_vgic_init(struct domain *d)
     return 0;
 }
 
+void domain_vgic_free(struct domain *d)
+{
+    xfree(d->arch.vgic.shared_irqs);
+    xfree(d->arch.vgic.pending_irqs);
+}
+
 int vcpu_vgic_init(struct vcpu *v)
 {
     int i;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dc8b28..1522667 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -56,6 +56,11 @@ int domain_uart0_init(struct domain *d)
 
 }
 
+void domain_uart0_free(struct domain *d)
+{
+    xfree(d->arch.uart0.buf);
+}
+
 static void uart0_print_char(char c)
 {
     struct vpl011 *uart = &current->domain->arch.uart0;
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
index 952d812..eabd99d 100644
--- a/xen/arch/arm/vpl011.h
+++ b/xen/arch/arm/vpl011.h
@@ -21,6 +21,7 @@
 #define __ARCH_ARM_VPL011_H__
 
 extern int domain_uart0_init(struct domain *d);
+extern void domain_uart0_free(struct domain *d);
 
 #endif
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 666bb88..14e71bf 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,6 +23,9 @@ struct p2m_domain {
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 
+/* Return all the p2m resources to Xen. */
+void p2m_teardown(struct domain *d);
+
 /* Allocate a new p2m table for a domain.
  *
  * Returns 0 for success or -errno.
-- 
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 Jun 26 09:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjS6f-0002xa-61; Tue, 26 Jun 2012 09:30: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 1SjS6d-0002xT-Nr
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:30:43 +0000
Received: from [85.158.143.35:62774] by server-2.bemta-4.messagelabs.com id
	8E/87-17938-34189EF4; Tue, 26 Jun 2012 09:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340703038!13416038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6817 invoked from network); 26 Jun 2012 09:30:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:30:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13217708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:30:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:30:37 +0100
Message-ID: <1340703036.3832.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 10:30:36 +0100
In-Reply-To: <20120607135930.GW70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
	<20120601170514.GD77921@ocelot.phlegethon.org>
	<1338577461.14877.61.camel@dagon.hellion.org.uk>
	<20120607135930.GW70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
 paging 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 Thu, 2012-06-07 at 14:59 +0100, Tim Deegan wrote:
> At 20:04 +0100 on 01 Jun (1338581061), Ian Campbell wrote:
> > On Fri, 2012-06-01 at 18:05 +0100, Tim Deegan wrote:
> > > At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> > > > With enough warnings enabled the model seemed to be complaining that pages
> > > > cached before paging was enabled had been mapped with to inconsistent sets of
> > > > attributes. I'm not convinced that isn't a model issue, nor am I convinced
> > > > this has really fixed anything, but it seems sensible enough.
> > > 
> > > This might be what breaks secondary CPU bringup: pagetables built by CPU
> > > 0 may not have been flushed all the way to RAM when CPU 1 comes up, and
> > > CPU 1 isn't participating in cache coherence protocols when it
> > > starts to need them.
> > 
> > The issue here is the lack of the necessary flush, rather than this
> > change particularly, right?
> 
> It turns out to be much more prosaic - the patch to delete the identity
> mapping from the boot pagetables was scuppering non-boot CPUs.
> 
> So this is OK, but can I suggest this to tidy it up?

Seems sensible. With this and Stefano's spelling fix it becomes:

>From fe5304fb1d1e6e607b125ccfbdc59b25e1d84b34 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 15:49:27 +0100
Subject: [PATCH] arm: enable data-cache at the same time as enabling the MMU,
 not before

With enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..cdbe011 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache disabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -210,7 +211,7 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
-- 
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 Jun 26 09:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjS6f-0002xa-61; Tue, 26 Jun 2012 09:30: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 1SjS6d-0002xT-Nr
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:30:43 +0000
Received: from [85.158.143.35:62774] by server-2.bemta-4.messagelabs.com id
	8E/87-17938-34189EF4; Tue, 26 Jun 2012 09:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340703038!13416038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6817 invoked from network); 26 Jun 2012 09:30:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:30:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13217708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:30:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:30:37 +0100
Message-ID: <1340703036.3832.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 10:30:36 +0100
In-Reply-To: <20120607135930.GW70339@ocelot.phlegethon.org>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-29-git-send-email-ian.campbell@citrix.com>
	<20120601170514.GD77921@ocelot.phlegethon.org>
	<1338577461.14877.61.camel@dagon.hellion.org.uk>
	<20120607135930.GW70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 29/38] arm: delay enabling data-cache until
 paging 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 Thu, 2012-06-07 at 14:59 +0100, Tim Deegan wrote:
> At 20:04 +0100 on 01 Jun (1338581061), Ian Campbell wrote:
> > On Fri, 2012-06-01 at 18:05 +0100, Tim Deegan wrote:
> > > At 15:39 +0000 on 01 Jun (1338565198), Ian Campbell wrote:
> > > > With enough warnings enabled the model seemed to be complaining that pages
> > > > cached before paging was enabled had been mapped with to inconsistent sets of
> > > > attributes. I'm not convinced that isn't a model issue, nor am I convinced
> > > > this has really fixed anything, but it seems sensible enough.
> > > 
> > > This might be what breaks secondary CPU bringup: pagetables built by CPU
> > > 0 may not have been flushed all the way to RAM when CPU 1 comes up, and
> > > CPU 1 isn't participating in cache coherence protocols when it
> > > starts to need them.
> > 
> > The issue here is the lack of the necessary flush, rather than this
> > change particularly, right?
> 
> It turns out to be much more prosaic - the patch to delete the identity
> mapping from the boot pagetables was scuppering non-boot CPUs.
> 
> So this is OK, but can I suggest this to tidy it up?

Seems sensible. With this and Stefano's spelling fix it becomes:

>From fe5304fb1d1e6e607b125ccfbdc59b25e1d84b34 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 May 2012 15:49:27 +0100
Subject: [PATCH] arm: enable data-cache at the same time as enabling the MMU,
 not before

With enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..cdbe011 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache disabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -210,7 +211,7 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
-- 
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 Jun 26 09:36:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09:36: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 1SjSBg-0003B8-TY; Tue, 26 Jun 2012 09:35:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjSBf-0003B2-NE
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:35:55 +0000
Received: from [85.158.143.99:30698] by server-1.bemta-4.messagelabs.com id
	DD/C9-24392-B7289EF4; Tue, 26 Jun 2012 09:35:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340703353!25784853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6342 invoked from network); 26 Jun 2012 09:35:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:35:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13217877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:35:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:35:52 +0100
Message-ID: <1340703351.3832.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 10:35:51 +0100
In-Reply-To: <alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 11:49 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > In particular it is taken by gic_set_guest_irq which is called by
> > vgic_vcpu_inject_irq
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/gic.c |   20 ++++++++++----------
> >  1 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index a398f92..ededa99 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -329,19 +329,19 @@ int __init gic_init(void)
> >  /* Set up the per-CPU parts of the GIC for a secondary CPU */
> >  void __cpuinit gic_init_secondary_cpu(void)
> >  {
> > -    spin_lock(&gic.lock);
> > +    spin_lock_irq(&gic.lock);
> >      gic_cpu_init();
> >      gic_hyp_init();
> > -    spin_unlock(&gic.lock);
> > +    spin_unlock_irq(&gic.lock);
> >  }
> >  
> >  /* Shut down the per-CPU GIC interface */
> >  void gic_disable_cpu(void)
> >  {
> > -    spin_lock(&gic.lock);
> > +    spin_lock_irq(&gic.lock);
> >      gic_cpu_disable();
> >      gic_hyp_disable();
> > -    spin_unlock(&gic.lock);
> > +    spin_unlock_irq(&gic.lock);
> >  }
> >  
> >  void gic_route_irqs(void)
> > @@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
> >  
> >      events_maintenance(current);
> >  
> > -    spin_lock(&gic.lock);
> > +    spin_lock_irq(&gic.lock);
> >  
> >      if ( list_empty(&gic.lr_pending) )
> >      {
> > @@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
> >      list_add_tail(&n->lr_queue, &gic.lr_pending);
> >  
> >  out:
> > -    spin_unlock(&gic.lock);
> > +    spin_unlock_irq(&gic.lock);
> >      return;
> >  }
> >  
> > @@ -559,7 +559,7 @@ static void events_maintenance(struct vcpu *v)
> >              (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> >  
> >      if (!already_pending && gic.event_mask != 0) {
> > -        spin_lock(&gic.lock);
> > +        spin_lock_irq(&gic.lock);
> >          while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> >                          sizeof(uint64_t), i)) < sizeof(uint64_t)) {
> >  
> > @@ -569,7 +569,7 @@ static void events_maintenance(struct vcpu *v)
> >  
> >              i++;
> >          }
> > -        spin_unlock(&gic.lock);
> > +        spin_unlock_irq(&gic.lock);
> >      }
> >  }
> >  
> > @@ -585,7 +585,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >                                sizeof(eisr), i)) < sizeof(eisr)) {
> >          struct pending_irq *p;
> >  
> > -        spin_lock(&gic.lock);
> > +        spin_lock_irq(&gic.lock);
> >          lr = GICH[GICH_LR + i];
> >          virq = lr & GICH_LR_VIRTUAL_MASK;
> >          GICH[GICH_LR + i] = 0;
> > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >          } else {
> >              gic_inject_irq_stop();
> >          }
> > -        spin_unlock(&gic.lock);
> > +        spin_unlock_irq(&gic.lock);
> >  
> >          spin_lock(&current->arch.vgic.lock);
>                ^
> shouldn't you change this into spin_lock_irq too?


If so then that should be in "arm: use interrupt safe spin locks in
vgic_vcpu_inject_irq" rather than here?

I think you've reworked this stuff a bit in one of your follow up series
-- is it worth me changing this here or do you handle it / make it
irrelevant?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 09:36:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09:36: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 1SjSBg-0003B8-TY; Tue, 26 Jun 2012 09:35:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjSBf-0003B2-NE
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:35:55 +0000
Received: from [85.158.143.99:30698] by server-1.bemta-4.messagelabs.com id
	DD/C9-24392-B7289EF4; Tue, 26 Jun 2012 09:35:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340703353!25784853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6342 invoked from network); 26 Jun 2012 09:35:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 09:35:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13217877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 09:35:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 10:35:52 +0100
Message-ID: <1340703351.3832.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 10:35:51 +0100
In-Reply-To: <alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 11:49 +0100, Stefano Stabellini wrote:
> On Fri, 1 Jun 2012, Ian Campbell wrote:
> > In particular it is taken by gic_set_guest_irq which is called by
> > vgic_vcpu_inject_irq
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/gic.c |   20 ++++++++++----------
> >  1 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index a398f92..ededa99 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -329,19 +329,19 @@ int __init gic_init(void)
> >  /* Set up the per-CPU parts of the GIC for a secondary CPU */
> >  void __cpuinit gic_init_secondary_cpu(void)
> >  {
> > -    spin_lock(&gic.lock);
> > +    spin_lock_irq(&gic.lock);
> >      gic_cpu_init();
> >      gic_hyp_init();
> > -    spin_unlock(&gic.lock);
> > +    spin_unlock_irq(&gic.lock);
> >  }
> >  
> >  /* Shut down the per-CPU GIC interface */
> >  void gic_disable_cpu(void)
> >  {
> > -    spin_lock(&gic.lock);
> > +    spin_lock_irq(&gic.lock);
> >      gic_cpu_disable();
> >      gic_hyp_disable();
> > -    spin_unlock(&gic.lock);
> > +    spin_unlock_irq(&gic.lock);
> >  }
> >  
> >  void gic_route_irqs(void)
> > @@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
> >  
> >      events_maintenance(current);
> >  
> > -    spin_lock(&gic.lock);
> > +    spin_lock_irq(&gic.lock);
> >  
> >      if ( list_empty(&gic.lr_pending) )
> >      {
> > @@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
> >      list_add_tail(&n->lr_queue, &gic.lr_pending);
> >  
> >  out:
> > -    spin_unlock(&gic.lock);
> > +    spin_unlock_irq(&gic.lock);
> >      return;
> >  }
> >  
> > @@ -559,7 +559,7 @@ static void events_maintenance(struct vcpu *v)
> >              (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> >  
> >      if (!already_pending && gic.event_mask != 0) {
> > -        spin_lock(&gic.lock);
> > +        spin_lock_irq(&gic.lock);
> >          while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> >                          sizeof(uint64_t), i)) < sizeof(uint64_t)) {
> >  
> > @@ -569,7 +569,7 @@ static void events_maintenance(struct vcpu *v)
> >  
> >              i++;
> >          }
> > -        spin_unlock(&gic.lock);
> > +        spin_unlock_irq(&gic.lock);
> >      }
> >  }
> >  
> > @@ -585,7 +585,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >                                sizeof(eisr), i)) < sizeof(eisr)) {
> >          struct pending_irq *p;
> >  
> > -        spin_lock(&gic.lock);
> > +        spin_lock_irq(&gic.lock);
> >          lr = GICH[GICH_LR + i];
> >          virq = lr & GICH_LR_VIRTUAL_MASK;
> >          GICH[GICH_LR + i] = 0;
> > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >          } else {
> >              gic_inject_irq_stop();
> >          }
> > -        spin_unlock(&gic.lock);
> > +        spin_unlock_irq(&gic.lock);
> >  
> >          spin_lock(&current->arch.vgic.lock);
>                ^
> shouldn't you change this into spin_lock_irq too?


If so then that should be in "arm: use interrupt safe spin locks in
vgic_vcpu_inject_irq" rather than here?

I think you've reworked this stuff a bit in one of your follow up series
-- is it worth me changing this here or do you handle it / make it
irrelevant?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 09:47:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09: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 1SjSMa-0003N8-DL; Tue, 26 Jun 2012 09:47: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 1SjSMY-0003N3-Pr
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:47:10 +0000
Received: from [85.158.143.99:62581] by server-3.bemta-4.messagelabs.com id
	28/BC-05808-E1589EF4; Tue, 26 Jun 2012 09:47:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340704028!29126788!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13242 invoked from network); 26 Jun 2012 09:47:09 -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;
	26 Jun 2012 09:47:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29422349"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 05:47:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 05:47:08 -0400
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 1SjSMV-0004or-7x;
	Tue, 26 Jun 2012 10:47:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 09:47:06 +0000
Message-ID: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen: add assertions in default_vcpu0_location
	to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 setting up the cpu sibling/etc masks on ARM I accidentally and
incorrectly omitted a CPU from it's own sibling mask which caused this
function to scribble over the heap. Add a couple of asserts to catch this in
the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/common/domctl.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..c1acd1d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
      */
     cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
     cpu = cpumask_first(&cpu_exclude_map);
+    ASSERT(cpu < nr_cpus);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
     for_each_cpu(i, online)
     {
+        ASSERT(i < nr_cpus);
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
             continue;
         if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&
-- 
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 Jun 26 09:47:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 09: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 1SjSMa-0003N8-DL; Tue, 26 Jun 2012 09:47: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 1SjSMY-0003N3-Pr
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 09:47:10 +0000
Received: from [85.158.143.99:62581] by server-3.bemta-4.messagelabs.com id
	28/BC-05808-E1589EF4; Tue, 26 Jun 2012 09:47:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340704028!29126788!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13242 invoked from network); 26 Jun 2012 09:47:09 -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;
	26 Jun 2012 09:47:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29422349"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 05:47:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 05:47:08 -0400
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 1SjSMV-0004or-7x;
	Tue, 26 Jun 2012 10:47:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 09:47:06 +0000
Message-ID: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen: add assertions in default_vcpu0_location
	to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 setting up the cpu sibling/etc masks on ARM I accidentally and
incorrectly omitted a CPU from it's own sibling mask which caused this
function to scribble over the heap. Add a couple of asserts to catch this in
the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/common/domctl.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..c1acd1d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
      */
     cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
     cpu = cpumask_first(&cpu_exclude_map);
+    ASSERT(cpu < nr_cpus);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
     for_each_cpu(i, online)
     {
+        ASSERT(i < nr_cpus);
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
             continue;
         if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&
-- 
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 Jun 26 10:15:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjSo4-0003gD-RX; Tue, 26 Jun 2012 10:15: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 1SjSo3-0003g8-9P
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:15:35 +0000
Received: from [85.158.143.35:11645] by server-1.bemta-4.messagelabs.com id
	86/15-24392-6CB89EF4; Tue, 26 Jun 2012 10:15:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340705730!13862623!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15954 invoked from network); 26 Jun 2012 10:15:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	26 Jun 2012 10:15:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 11:15:29 +0100
Message-Id: <4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 11:16:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
> When setting up the cpu sibling/etc masks on ARM I accidentally and
> incorrectly omitted a CPU from it's own sibling mask which caused this
> function to scribble over the heap. Add a couple of asserts to catch this in
> the future.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
>  xen/common/domctl.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9f1a9ad..c1acd1d 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
> *online)
>       */
>      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>      cpu = cpumask_first(&cpu_exclude_map);
> +    ASSERT(cpu < nr_cpus);
>      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>          cpu = cpumask_next(cpu, &cpu_exclude_map);

You may want to add another ASSERT() here in case you care
about the difference between nr_cpus and nr_cpu_ids. Or move
the ASSERT() here if the difference is insignificant (as I would
think), as cpumask_next() invokes cpumask_check() (see also
below).

>      for_each_cpu(i, online)
>      {
> +        ASSERT(i < nr_cpus);

This one is almost redundant with the one in cpumask_check()
called from cpumask_test_cpu() (and the difference between
using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
I'd recommend going with just the single earlier addition.

Jan

>          if ( cpumask_test_cpu(i, &cpu_exclude_map) )
>              continue;
>          if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&
> -- 
> 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 Jun 26 10:15:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjSo4-0003gD-RX; Tue, 26 Jun 2012 10:15: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 1SjSo3-0003g8-9P
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:15:35 +0000
Received: from [85.158.143.35:11645] by server-1.bemta-4.messagelabs.com id
	86/15-24392-6CB89EF4; Tue, 26 Jun 2012 10:15:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340705730!13862623!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15954 invoked from network); 26 Jun 2012 10:15:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with SMTP;
	26 Jun 2012 10:15:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 11:15:29 +0100
Message-Id: <4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 11:16:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
> When setting up the cpu sibling/etc masks on ARM I accidentally and
> incorrectly omitted a CPU from it's own sibling mask which caused this
> function to scribble over the heap. Add a couple of asserts to catch this in
> the future.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
>  xen/common/domctl.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9f1a9ad..c1acd1d 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
> *online)
>       */
>      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>      cpu = cpumask_first(&cpu_exclude_map);
> +    ASSERT(cpu < nr_cpus);
>      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>          cpu = cpumask_next(cpu, &cpu_exclude_map);

You may want to add another ASSERT() here in case you care
about the difference between nr_cpus and nr_cpu_ids. Or move
the ASSERT() here if the difference is insignificant (as I would
think), as cpumask_next() invokes cpumask_check() (see also
below).

>      for_each_cpu(i, online)
>      {
> +        ASSERT(i < nr_cpus);

This one is almost redundant with the one in cpumask_check()
called from cpumask_test_cpu() (and the difference between
using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
I'd recommend going with just the single earlier addition.

Jan

>          if ( cpumask_test_cpu(i, &cpu_exclude_map) )
>              continue;
>          if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&
> -- 
> 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 Jun 26 10:19:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjSrI-0003lw-F9; Tue, 26 Jun 2012 10:18:56 +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 1SjSrH-0003lq-MP
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:18:55 +0000
Received: from [193.109.254.147:55395] by server-3.bemta-14.messagelabs.com id
	97/80-08687-E8C89EF4; Tue, 26 Jun 2012 10:18:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340705934!3418837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4678 invoked from network); 26 Jun 2012 10:18:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13219160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:18:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:18:27 +0100
Message-ID: <1340705906.3832.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 11:18:26 +0100
In-Reply-To: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
	not just 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 Fri, 2012-06-01 at 16:39 +0100, Ian Campbell wrote:
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 339c327..a398f92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -541,14 +541,13 @@ void gic_interrupt(struct cpu_user_regs *regs,
> int is_fiq)
>      do_IRQ(regs, irq, is_fiq);
>  }
>  
> -void gicv_setup(struct domain *d)
> +int gicv_setup(struct domain *d)
>  {
> +    printk("GICV setup for DOM%d\n", d->domain_id);

This print was a bit verbose/pointless -- I've 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 Tue Jun 26 10:19:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjSrI-0003lw-F9; Tue, 26 Jun 2012 10:18:56 +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 1SjSrH-0003lq-MP
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:18:55 +0000
Received: from [193.109.254.147:55395] by server-3.bemta-14.messagelabs.com id
	97/80-08687-E8C89EF4; Tue, 26 Jun 2012 10:18:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340705934!3418837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4678 invoked from network); 26 Jun 2012 10:18:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13219160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:18:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:18:27 +0100
Message-ID: <1340705906.3832.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 11:18:26 +0100
In-Reply-To: <1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-28-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 28/38] arm: map GICV in all domains,
	not just 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 Fri, 2012-06-01 at 16:39 +0100, Ian Campbell wrote:
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 339c327..a398f92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -541,14 +541,13 @@ void gic_interrupt(struct cpu_user_regs *regs,
> int is_fiq)
>      do_IRQ(regs, irq, is_fiq);
>  }
>  
> -void gicv_setup(struct domain *d)
> +int gicv_setup(struct domain *d)
>  {
> +    printk("GICV setup for DOM%d\n", d->domain_id);

This print was a bit verbose/pointless -- I've 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 Tue Jun 26 10:28:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:28: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 1SjT0g-0003y9-Ha; Tue, 26 Jun 2012 10:28: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 1SjT0e-0003y4-Ts
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:28:37 +0000
Received: from [85.158.143.35:41652] by server-3.bemta-4.messagelabs.com id
	DF/46-05808-4DE89EF4; Tue, 26 Jun 2012 10:28:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340706436!14072467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2946 invoked from network); 26 Jun 2012 10:27:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13219408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:27:16 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 11:27:16 +0100
Message-ID: <4FE98E82.9060801@citrix.com>
Date: Tue, 26 Jun 2012 11:27:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-6-git-send-email-roger.pau@citrix.com>
	<20451.24777.528406.191318@mariner.uk.xensource.com>
In-Reply-To: <20451.24777.528406.191318@mariner.uk.xensource.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 05/13] libxl: convert
 libxl__device_disk_local_attach to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 05/13] libxl: convert libxl__device_disk_local_attach to an async op"):
>> This will be needed in future patches, when libxl__device_disk_add
>> becomes async also. Create a new status structure that defines the
>> local attach of a disk device and use it in
>> libxl__device_disk_local_attach.
>
> This is looking good.  I have a couple of comments:

Thanks for the review!

>
>> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
>> index 7ebc0df..182a975 100644
>> --- a/tools/libxl/libxl_bootloader.c
>> +++ b/tools/libxl/libxl_bootloader.c
> ...
>> +static void bootloader_fisnihed_cb(libxl__egc *egc,
>                            ^^^^^^^^
> `finished'.  You have apparently managed to misspell this everywhere
> you mention it!

Probably copy-pasted it wrong everywhere, fixed.

>> +                                   libxl__disk_local_state *dls,
>> +                                   int rc);
>> +
>>   static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
>>                                   int rc)
>>   {
>>       bootloader_cleanup(egc, bl);
>> +
>> +    if (bl->diskpath) {
>> +        bl->dls.callback = bootloader_fisnihed_cb;
>> +        libxl__device_disk_local_detach(egc,&bl->dls);
>> +        return;
>> +    }
>
> Can we make libxl__device_disk_local_detach idempotent (and perhaps
> call it `libxl__device_disk_local_attached_initiate_cleanup' or
> something, if you can think of a name that's less than a paragraph) ?

I'm not sure the "attached" in the name is correct, because the device 
might have failed to attach, and still we are going to call this 
function. How about "libxl__device_disk_local_initiate_detach"? (still 
quite long). Then the attach function should be renamed to 
libxl__device_disk_local_initiate_attach.

> If so then this would be simpler and wouldn't need to test
> bl->diskpath.

Ok, I've moved the test for bl->dls.diskpath to 
libxl__device_disk_local_detach, so we have a more linear flow of callbacks.

>
>> +static void bootloader_disk_attached_cb(libxl__egc *egc,
>> +                                        libxl__disk_local_state *dls,
>> +                                        int rc)
> ...
>> +    bl->diskpath = bl->dls.diskpath;
>
> Now that we have a bl->dls.diskpath, surely we can do away with
> bl->diskpath ?  I'm not a fan of having multiple variables with the
> same information in them, unless it's essential.  It just leads to
> confusion and error.

Done.

>> +/*
>> + * Make a disk available in this (the control) domain. Calls dls->callback
>> + * when finished.
>> + */
>> +_hidden void libxl__device_disk_local_attach(libxl__egc *egc,
>> +                                             libxl__disk_local_state *dls);
>> +_hidden void libxl__device_disk_local_detach(libxl__egc *egc,
>> +                                             libxl__disk_local_state *dls);
>
> You really need to explain the rules for one of these dls's.
>
> Is it something like this:
>
>       * A libxl__disk_local_state may be in the following states:
>       *    Undefined, Idle, Attaching, Attached, Detaching

Ok, I've added the init function and the description of what this 
functions do, together with the rename it should be a little bit more clear.

>      typedef void libxl__disk_local_state_callback(libxl__egc*,
>                                                    libxl__disk_local_state*,
>                                                    int rc);
>
>     _hidden void libxl__device_disk_local_attach(libxl__egc *egc,
>                                                  libxl__disk_local_state *dls);
>         /* Undefined/Idle ->  Attaching.  Will call callback.
>          * On entry to callback, if rc!=0 dls is Idle;
>          * if rc==0 it is Attached and dls->diskpath is usable. */
>
>     _hidden void libxl__device_disk_local_detach(libxl__egc *egc,
>                                                  libxl__disk_local_state *dls);
>         /* Attached ->  Detaching.  Will call callback.
>          * On entry to callback, dls is Idle, regardless of
>          * success or failure. */
>
> And my suggestion about idempotency would change this latter comment
> to:
>         /* Idle/Attached ->  Detaching.  Will call callback.
>          * On entry to callback, dls is Idle, regardless of
>          * success or failure. */
>
> And the bootloader code might want this:
>
>     _hidden void libxl__device_disk_local_init(libxl__disk_local_state *dls);
>         /* Undefined/Idle ->  Idle */
>
> Or you can explain it in prose if you like.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 10:28:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:28: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 1SjT0g-0003y9-Ha; Tue, 26 Jun 2012 10:28: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 1SjT0e-0003y4-Ts
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:28:37 +0000
Received: from [85.158.143.35:41652] by server-3.bemta-4.messagelabs.com id
	DF/46-05808-4DE89EF4; Tue, 26 Jun 2012 10:28:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340706436!14072467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2946 invoked from network); 26 Jun 2012 10:27:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13219408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:27:16 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 11:27:16 +0100
Message-ID: <4FE98E82.9060801@citrix.com>
Date: Tue, 26 Jun 2012 11:27:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-6-git-send-email-roger.pau@citrix.com>
	<20451.24777.528406.191318@mariner.uk.xensource.com>
In-Reply-To: <20451.24777.528406.191318@mariner.uk.xensource.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 05/13] libxl: convert
 libxl__device_disk_local_attach to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 05/13] libxl: convert libxl__device_disk_local_attach to an async op"):
>> This will be needed in future patches, when libxl__device_disk_add
>> becomes async also. Create a new status structure that defines the
>> local attach of a disk device and use it in
>> libxl__device_disk_local_attach.
>
> This is looking good.  I have a couple of comments:

Thanks for the review!

>
>> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
>> index 7ebc0df..182a975 100644
>> --- a/tools/libxl/libxl_bootloader.c
>> +++ b/tools/libxl/libxl_bootloader.c
> ...
>> +static void bootloader_fisnihed_cb(libxl__egc *egc,
>                            ^^^^^^^^
> `finished'.  You have apparently managed to misspell this everywhere
> you mention it!

Probably copy-pasted it wrong everywhere, fixed.

>> +                                   libxl__disk_local_state *dls,
>> +                                   int rc);
>> +
>>   static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl,
>>                                   int rc)
>>   {
>>       bootloader_cleanup(egc, bl);
>> +
>> +    if (bl->diskpath) {
>> +        bl->dls.callback = bootloader_fisnihed_cb;
>> +        libxl__device_disk_local_detach(egc,&bl->dls);
>> +        return;
>> +    }
>
> Can we make libxl__device_disk_local_detach idempotent (and perhaps
> call it `libxl__device_disk_local_attached_initiate_cleanup' or
> something, if you can think of a name that's less than a paragraph) ?

I'm not sure the "attached" in the name is correct, because the device 
might have failed to attach, and still we are going to call this 
function. How about "libxl__device_disk_local_initiate_detach"? (still 
quite long). Then the attach function should be renamed to 
libxl__device_disk_local_initiate_attach.

> If so then this would be simpler and wouldn't need to test
> bl->diskpath.

Ok, I've moved the test for bl->dls.diskpath to 
libxl__device_disk_local_detach, so we have a more linear flow of callbacks.

>
>> +static void bootloader_disk_attached_cb(libxl__egc *egc,
>> +                                        libxl__disk_local_state *dls,
>> +                                        int rc)
> ...
>> +    bl->diskpath = bl->dls.diskpath;
>
> Now that we have a bl->dls.diskpath, surely we can do away with
> bl->diskpath ?  I'm not a fan of having multiple variables with the
> same information in them, unless it's essential.  It just leads to
> confusion and error.

Done.

>> +/*
>> + * Make a disk available in this (the control) domain. Calls dls->callback
>> + * when finished.
>> + */
>> +_hidden void libxl__device_disk_local_attach(libxl__egc *egc,
>> +                                             libxl__disk_local_state *dls);
>> +_hidden void libxl__device_disk_local_detach(libxl__egc *egc,
>> +                                             libxl__disk_local_state *dls);
>
> You really need to explain the rules for one of these dls's.
>
> Is it something like this:
>
>       * A libxl__disk_local_state may be in the following states:
>       *    Undefined, Idle, Attaching, Attached, Detaching

Ok, I've added the init function and the description of what this 
functions do, together with the rename it should be a little bit more clear.

>      typedef void libxl__disk_local_state_callback(libxl__egc*,
>                                                    libxl__disk_local_state*,
>                                                    int rc);
>
>     _hidden void libxl__device_disk_local_attach(libxl__egc *egc,
>                                                  libxl__disk_local_state *dls);
>         /* Undefined/Idle ->  Attaching.  Will call callback.
>          * On entry to callback, if rc!=0 dls is Idle;
>          * if rc==0 it is Attached and dls->diskpath is usable. */
>
>     _hidden void libxl__device_disk_local_detach(libxl__egc *egc,
>                                                  libxl__disk_local_state *dls);
>         /* Attached ->  Detaching.  Will call callback.
>          * On entry to callback, dls is Idle, regardless of
>          * success or failure. */
>
> And my suggestion about idempotency would change this latter comment
> to:
>         /* Idle/Attached ->  Detaching.  Will call callback.
>          * On entry to callback, dls is Idle, regardless of
>          * success or failure. */
>
> And the bootloader code might want this:
>
>     _hidden void libxl__device_disk_local_init(libxl__disk_local_state *dls);
>         /* Undefined/Idle ->  Idle */
>
> Or you can explain it in prose if you like.
>
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 10:29:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjT1e-00041E-Vj; Tue, 26 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1SjT1d-000414-Gq
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:29:37 +0000
Received: from [193.109.254.147:7008] by server-1.bemta-14.messagelabs.com id
	AA/09-24612-01F89EF4; Tue, 26 Jun 2012 10:29:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340706576!8596783!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20314 invoked from network); 26 Jun 2012 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13219460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:29:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:29:36 +0100
Message-ID: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 11:29:34 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 00/40 V2] arm: boot a dom1 to "Calibrating delay
 loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 (I think) addressed all review comments against non-HACK and
non-toolstack (which I've left till later) patches in this series, as
noted in my various replies to the review.

In the list:
        An "A" in the list below indicates that I think the patch has
        sufficient Acked-by's to be committed (assuming the
        prerequisites can go in).

        An "X" means I don't consider this patch for committing.

        A "!" means I didn't consider review comments yet.

Currently this requires Jan's "arm: fix build after c/s
25477:e12e0b038219" patch, which I have not included here, in order to
build.

I intend to commit those patches which are acked and which do not depend
on non-acked patches shortly.

A     01 arm: allocate top level p2m page for all non-idle domains
A     02 arm: handy function to print a walk of a page table
A     03 arm: correct and expand TLB flush CP15 registers
A     04 arm: restore stack on return from trap.
A     05 arm: enable interrupts while handling traps
A     06 arm: hook up domctl and memory_op
A     07 arm: allocate and setup a guest vcpu.
A     08 arm: print domid as part of debug trap
A     09 arm: remove unnecessarily verbose print from p2m_load_VTTBR
A     10 arm: implement p2m lookup
A     11 arm: remove hard tabs from init_idle_domain
A     12 arm: stub out sync_vcpu_execstate
A     13 arm: implement stub version of flush_tlb_mask.
A     14 arm: do not set max_vcpus = 8 in arch_domain_create.
A     15 arm: Add simple cpu_{sibling,core}_mask
      16 arm: allow p2m to be created with specific MATTR.
      17 arm: implement vpl011 (UART) emulator.
A     18 arm: context switch a bunch of guest state.
A     19 arm: dump a page table walk when va_to_par fails.
A     20 arm: dump guest s1 walk on data abort which is not a stage 2 issue.
      21 arm: implement vcpu_show_execution_state
A     22 arm: use correct attributes for mappings in copy_from_paddr()
A     23 arm: map fixmaps non-executable.
A     24 arm: fix locking in create_p2m_entries
      25 arm: split pending SPIs (global) out from pending PPIs and SGIs (per CPU)
      26 arm: use interrupt safe spin locks in vgic_vcpu_inject_irq
A     27 arm: map GICV in all domains, not just dom0.
      28 arm: enable data-cache at the same time as enabling the MMU, not before
A     29 arm: Upgrade guest barriers to Outer-Shareable. Enable Protected Table Walk.
A     30 arm: gic.lock can be taken in interrupt context, so lock appropriately.
A     31 arm: context switch virtual timer registers
A     32 arm: the hyp timer seems to work in newer model versions, default to using it.
      33 arm: unwind allocations etc on arch_domain_create_failure
 X!   34 HACK: arm: initial XENMAPSPACE_gmfn_foreign
A     35 arm: move PSR flag definitions into interface, for tools use.
 X!   36 libxc: add ARM support to xc_dom (PV domain building)
      37 arm: implement VGCF_online
A     38 arm: fix typo s/approprately/appropriately/g
 X!   39 HACK: add simple xcbuild
 X!   40 HACK: arm: disable hypercall continuations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 10:29:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjT1e-00041E-Vj; Tue, 26 Jun 2012 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 <Ian.Campbell@citrix.com>) id 1SjT1d-000414-Gq
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:29:37 +0000
Received: from [193.109.254.147:7008] by server-1.bemta-14.messagelabs.com id
	AA/09-24612-01F89EF4; Tue, 26 Jun 2012 10:29:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340706576!8596783!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20314 invoked from network); 26 Jun 2012 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13219460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:29:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:29:36 +0100
Message-ID: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 11:29:34 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 00/40 V2] arm: boot a dom1 to "Calibrating delay
 loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 (I think) addressed all review comments against non-HACK and
non-toolstack (which I've left till later) patches in this series, as
noted in my various replies to the review.

In the list:
        An "A" in the list below indicates that I think the patch has
        sufficient Acked-by's to be committed (assuming the
        prerequisites can go in).

        An "X" means I don't consider this patch for committing.

        A "!" means I didn't consider review comments yet.

Currently this requires Jan's "arm: fix build after c/s
25477:e12e0b038219" patch, which I have not included here, in order to
build.

I intend to commit those patches which are acked and which do not depend
on non-acked patches shortly.

A     01 arm: allocate top level p2m page for all non-idle domains
A     02 arm: handy function to print a walk of a page table
A     03 arm: correct and expand TLB flush CP15 registers
A     04 arm: restore stack on return from trap.
A     05 arm: enable interrupts while handling traps
A     06 arm: hook up domctl and memory_op
A     07 arm: allocate and setup a guest vcpu.
A     08 arm: print domid as part of debug trap
A     09 arm: remove unnecessarily verbose print from p2m_load_VTTBR
A     10 arm: implement p2m lookup
A     11 arm: remove hard tabs from init_idle_domain
A     12 arm: stub out sync_vcpu_execstate
A     13 arm: implement stub version of flush_tlb_mask.
A     14 arm: do not set max_vcpus = 8 in arch_domain_create.
A     15 arm: Add simple cpu_{sibling,core}_mask
      16 arm: allow p2m to be created with specific MATTR.
      17 arm: implement vpl011 (UART) emulator.
A     18 arm: context switch a bunch of guest state.
A     19 arm: dump a page table walk when va_to_par fails.
A     20 arm: dump guest s1 walk on data abort which is not a stage 2 issue.
      21 arm: implement vcpu_show_execution_state
A     22 arm: use correct attributes for mappings in copy_from_paddr()
A     23 arm: map fixmaps non-executable.
A     24 arm: fix locking in create_p2m_entries
      25 arm: split pending SPIs (global) out from pending PPIs and SGIs (per CPU)
      26 arm: use interrupt safe spin locks in vgic_vcpu_inject_irq
A     27 arm: map GICV in all domains, not just dom0.
      28 arm: enable data-cache at the same time as enabling the MMU, not before
A     29 arm: Upgrade guest barriers to Outer-Shareable. Enable Protected Table Walk.
A     30 arm: gic.lock can be taken in interrupt context, so lock appropriately.
A     31 arm: context switch virtual timer registers
A     32 arm: the hyp timer seems to work in newer model versions, default to using it.
      33 arm: unwind allocations etc on arch_domain_create_failure
 X!   34 HACK: arm: initial XENMAPSPACE_gmfn_foreign
A     35 arm: move PSR flag definitions into interface, for tools use.
 X!   36 libxc: add ARM support to xc_dom (PV domain building)
      37 arm: implement VGCF_online
A     38 arm: fix typo s/approprately/appropriately/g
 X!   39 HACK: add simple xcbuild
 X!   40 HACK: arm: disable hypercall continuations.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2I-00047A-FV; Tue, 26 Jun 2012 10:30: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 1SjT2G-00044h-19
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:16 +0000
Received: from [85.158.143.99:31652] by server-3.bemta-4.messagelabs.com id
	B4/39-05808-73F89EF4; Tue, 26 Jun 2012 10:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340706610!23915013!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3603 invoked from network); 26 Jun 2012 10:30:14 -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;
	26 Jun 2012 10:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425988"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT25-00064E-3k;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:34 +0000
Message-ID: <1340706604-1313-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 10/40] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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        |   45 +++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h |    3 +++
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6df5b62..ec41d38 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -32,6 +32,51 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+/*
+ * Lookup the MFN corresponding to a domain's PFN.
+ *
+ * There are no processor functions to do a stage 2 only lookup therefore we
+ * do a a software walk.
+ */
+paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
+    paddr_t maddr = INVALID_PADDR;
+
+    spin_lock(&p2m->lock);
+
+    first = __map_domain_page(p2m->first_level);
+
+    pte = first[first_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    second = map_domain_page(pte.p2m.base);
+    pte = second[second_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    third = map_domain_page(pte.p2m.base);
+    pte = third[third_table_offset(paddr)];
+
+    /* This bit must be one in the level 3 entry */
+    if ( !pte.p2m.table )
+        pte.bits = 0;
+
+done:
+    if ( pte.p2m.valid )
+        maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return maddr;
+}
+
 int guest_physmap_mark_populate_on_demand(struct domain *d,
                                           unsigned long gfn,
                                           unsigned int order)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 349923a..666bb88 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
 /* */
 void p2m_load_VTTBR(struct domain *d);
 
+/* Look up the MFN corresponding to a domain's PFN. */
+paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
+
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2I-00047A-FV; Tue, 26 Jun 2012 10:30: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 1SjT2G-00044h-19
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:16 +0000
Received: from [85.158.143.99:31652] by server-3.bemta-4.messagelabs.com id
	B4/39-05808-73F89EF4; Tue, 26 Jun 2012 10:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340706610!23915013!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3603 invoked from network); 26 Jun 2012 10:30:14 -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;
	26 Jun 2012 10:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425988"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT25-00064E-3k;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:34 +0000
Message-ID: <1340706604-1313-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 10/40] arm: implement p2m lookup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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        |   45 +++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/p2m.h |    3 +++
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6df5b62..ec41d38 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -32,6 +32,51 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+/*
+ * Lookup the MFN corresponding to a domain's PFN.
+ *
+ * There are no processor functions to do a stage 2 only lookup therefore we
+ * do a a software walk.
+ */
+paddr_t p2m_lookup(struct domain *d, paddr_t paddr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t pte, *first = NULL, *second = NULL, *third = NULL;
+    paddr_t maddr = INVALID_PADDR;
+
+    spin_lock(&p2m->lock);
+
+    first = __map_domain_page(p2m->first_level);
+
+    pte = first[first_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    second = map_domain_page(pte.p2m.base);
+    pte = second[second_table_offset(paddr)];
+    if ( !pte.p2m.valid || !pte.p2m.table )
+        goto done;
+
+    third = map_domain_page(pte.p2m.base);
+    pte = third[third_table_offset(paddr)];
+
+    /* This bit must be one in the level 3 entry */
+    if ( !pte.p2m.table )
+        pte.bits = 0;
+
+done:
+    if ( pte.p2m.valid )
+        maddr = (pte.bits & PADDR_MASK & PAGE_MASK) | (paddr & ~PAGE_MASK);
+
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+
+    spin_unlock(&p2m->lock);
+
+    return maddr;
+}
+
 int guest_physmap_mark_populate_on_demand(struct domain *d,
                                           unsigned long gfn,
                                           unsigned int order)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 349923a..666bb88 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ int p2m_alloc_table(struct domain *d);
 /* */
 void p2m_load_VTTBR(struct domain *d);
 
+/* Look up the MFN corresponding to a domain's PFN. */
+paddr_t p2m_lookup(struct domain *d, paddr_t gpfn);
+
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 /* Map MMIO regions in the p2m: start_gaddr and end_gaddr is the range
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2G-00046C-Qh; Tue, 26 Jun 2012 10:30:16 +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 1SjT2E-00044i-Gf
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:14 +0000
Received: from [193.109.254.147:15003] by server-4.bemta-14.messagelabs.com id
	49/A5-02077-53F89EF4; Tue, 26 Jun 2012 10:30:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340706605!8430703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15826 invoked from network); 26 Jun 2012 10:30:06 -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;
	26 Jun 2012 10:30:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200050549"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:04 -0400
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 1SjT24-00064E-HL;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:25 +0000
Message-ID: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 01/40] arm: allocate top level p2m page for
	all non-idle 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

Not just dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c |    3 +++
 xen/arch/arm/p2m.c    |    2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5702399..4b38790 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -201,6 +201,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         clear_page(d->shared_info);
         share_xen_page_with_guest(
                 virt_to_page(d->shared_info), d, XENSHARE_writable);
+
+        if ( (rc = p2m_alloc_table(d)) != 0 )
+            goto fail;
     }
 
     d->max_vcpus = 8;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 051a0e8..4f624d8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -203,7 +203,7 @@ int p2m_alloc_table(struct domain *d)
     void *p;
 
     /* First level P2M is 2 consecutive pages */
-    page = alloc_domheap_pages(d, 1, 0);
+    page = alloc_domheap_pages(NULL, 1, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2G-00046C-Qh; Tue, 26 Jun 2012 10:30:16 +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 1SjT2E-00044i-Gf
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:14 +0000
Received: from [193.109.254.147:15003] by server-4.bemta-14.messagelabs.com id
	49/A5-02077-53F89EF4; Tue, 26 Jun 2012 10:30:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340706605!8430703!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15826 invoked from network); 26 Jun 2012 10:30:06 -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;
	26 Jun 2012 10:30:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200050549"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:04 -0400
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 1SjT24-00064E-HL;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:25 +0000
Message-ID: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 01/40] arm: allocate top level p2m page for
	all non-idle 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

Not just dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c |    3 +++
 xen/arch/arm/p2m.c    |    2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5702399..4b38790 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -201,6 +201,9 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         clear_page(d->shared_info);
         share_xen_page_with_guest(
                 virt_to_page(d->shared_info), d, XENSHARE_writable);
+
+        if ( (rc = p2m_alloc_table(d)) != 0 )
+            goto fail;
     }
 
     d->max_vcpus = 8;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 051a0e8..4f624d8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -203,7 +203,7 @@ int p2m_alloc_table(struct domain *d)
     void *p;
 
     /* First level P2M is 2 consecutive pages */
-    page = alloc_domheap_pages(d, 1, 0);
+    page = alloc_domheap_pages(NULL, 1, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2F-00045f-Vq; Tue, 26 Jun 2012 10:30:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjT2D-00044V-Sx
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:14 +0000
Received: from [85.158.143.35:54345] by server-1.bemta-4.messagelabs.com id
	F3/C3-24392-53F89EF4; Tue, 26 Jun 2012 10:30:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340706609!15649665!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29082 invoked from network); 26 Jun 2012 10:30:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:30:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-Lj;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:27 +0000
Message-ID: <1340706604-1313-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 03/40] arm: correct and expand TLB flush CP15
	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

Correct spelling of TLBIALLHIS and correct definition of TLBIALLNSNHIS.

Add a few more.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/asm-arm/cpregs.h |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ee8a287..7a0b49a 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -172,12 +172,19 @@
 #define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
 #define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
 #define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define ITLBIALL        p15,0,c8,c5,0   /* Invalidate instruction TLB */
+#define ITLBIMVA        p15,0,c8,c5,1   /* Invalidate instruction TLB entry by MVA */
+#define ITLBIASID       p15,0,c8,c5,2   /* Invalidate instruction TLB by ASID match */
 #define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
 #define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
 #define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
-#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIALL         p15,0,c8,c7,0   /* invalidate unified TLB */
+#define TLBIMVA         p15,0,c8,c7,1   /* invalidate unified TLB entry by MVA */
+#define TLBIASID        p15,0,c8,c7,2   /* invalid unified TLB by ASID match */
+#define TLBIMVAA        p15,0,c8,c7,3   /* invalidate unified TLB entries by MVA all ASID */
+#define TLBIALLHIS      p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
 #define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
-#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c3,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
 #define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
 #define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
 #define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2F-00045f-Vq; Tue, 26 Jun 2012 10:30:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjT2D-00044V-Sx
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:14 +0000
Received: from [85.158.143.35:54345] by server-1.bemta-4.messagelabs.com id
	F3/C3-24392-53F89EF4; Tue, 26 Jun 2012 10:30:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340706609!15649665!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29082 invoked from network); 26 Jun 2012 10:30:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:30:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-Lj;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:27 +0000
Message-ID: <1340706604-1313-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 03/40] arm: correct and expand TLB flush CP15
	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

Correct spelling of TLBIALLHIS and correct definition of TLBIALLNSNHIS.

Add a few more.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/asm-arm/cpregs.h |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ee8a287..7a0b49a 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -172,12 +172,19 @@
 #define TLBIMVAIS       p15,0,c8,c3,1   /* Invalidate unified TLB entry by MVA inner shareable */
 #define TLBIASIDIS      p15,0,c8,c3,2   /* Invalidate unified TLB by ASID match inner shareable */
 #define TLBIMVAAIS      p15,0,c8,c3,3   /* Invalidate unified TLB entry by MVA all ASID inner shareable */
+#define ITLBIALL        p15,0,c8,c5,0   /* Invalidate instruction TLB */
+#define ITLBIMVA        p15,0,c8,c5,1   /* Invalidate instruction TLB entry by MVA */
+#define ITLBIASID       p15,0,c8,c5,2   /* Invalidate instruction TLB by ASID match */
 #define DTLBIALL        p15,0,c8,c6,0   /* Invalidate data TLB */
 #define DTLBIMVA        p15,0,c8,c6,1   /* Invalidate data TLB entry by MVA */
 #define DTLBIASID       p15,0,c8,c6,2   /* Invalidate data TLB by ASID match */
-#define TLBILLHIS       p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
+#define TLBIALL         p15,0,c8,c7,0   /* invalidate unified TLB */
+#define TLBIMVA         p15,0,c8,c7,1   /* invalidate unified TLB entry by MVA */
+#define TLBIASID        p15,0,c8,c7,2   /* invalid unified TLB by ASID match */
+#define TLBIMVAA        p15,0,c8,c7,3   /* invalidate unified TLB entries by MVA all ASID */
+#define TLBIALLHIS      p15,4,c8,c3,0   /* Invalidate Entire Hyp. Unified TLB inner shareable */
 #define TLBIMVAHIS      p15,4,c8,c3,1   /* Invalidate Unified Hyp. TLB by MVA inner shareable */
-#define TLBIALLNSNHIS   p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
+#define TLBIALLNSNHIS   p15,4,c8,c3,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */
 #define TLBIALLH        p15,4,c8,c7,0   /* Invalidate Entire Hyp. Unified TLB */
 #define TLBIMVAH        p15,4,c8,c7,1   /* Invalidate Unified Hyp. TLB by MVA */
 #define TLBIALLNSNH     p15,4,c8,c7,4   /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2G-000462-Cm; Tue, 26 Jun 2012 10:30: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 1SjT2E-00044h-6C
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:14 +0000
Received: from [85.158.143.99:31438] by server-3.bemta-4.messagelabs.com id
	A7/29-05808-53F89EF4; Tue, 26 Jun 2012 10:30:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340706610!23915013!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3348 invoked from network); 26 Jun 2012 10:30:11 -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;
	26 Jun 2012 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425984"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-SF;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:30 +0000
Message-ID: <1340706604-1313-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 06/40] arm: hook up domctl and memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5ed754f..5d8b7f9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -373,6 +373,8 @@ typedef unsigned long arm_hypercall_t(
     [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
 
 static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(memory_op),
+    HYPERCALL(domctl),
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2H-00046T-88; Tue, 26 Jun 2012 10:30:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjT2F-00045F-CN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:15 +0000
Received: from [85.158.143.99:44319] by server-2.bemta-4.messagelabs.com id
	67/FA-17938-63F89EF4; Tue, 26 Jun 2012 10:30:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340706610!23915013!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3510 invoked from network); 26 Jun 2012 10:30:13 -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;
	26 Jun 2012 10:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425986"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-Ul;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:31 +0000
Message-ID: <1340706604-1313-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 07/40] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/domain.c         |   67 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/dummy.S          |    3 --
 xen/include/public/arch-arm.h |    9 -----
 3 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9339a11..b099d91 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
     free_xenheap_page(v);
 }
 
+struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+{
+    return xmalloc(struct vcpu_guest_context);
+
+}
+
+void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
+{
+    xfree(vgc);
+}
+
 int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
@@ -212,6 +223,62 @@ void arch_domain_destroy(struct domain *d)
     /* domain_vgic_destroy */
 }
 
+static int is_guest_psr(uint32_t psr)
+{
+    switch (psr & PSR_MODE_MASK)
+    {
+    case PSR_MODE_USR:
+    case PSR_MODE_FIQ:
+    case PSR_MODE_IRQ:
+    case PSR_MODE_SVC:
+    case PSR_MODE_ABT:
+    case PSR_MODE_UND:
+    case PSR_MODE_SYS:
+        return 1;
+    case PSR_MODE_MON:
+    case PSR_MODE_HYP:
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Initialise VCPU state. The context can be supplied by either the
+ * toolstack (XEN_DOMCTL_setvcpucontext) or the guest
+ * (VCPUOP_initialise) and therefore must be properly validated.
+ */
+int arch_set_info_guest(
+    struct vcpu *v, vcpu_guest_context_u c)
+{
+    struct cpu_user_regs *regs = &c.nat->user_regs;
+
+    if ( !is_guest_psr(regs->cpsr) )
+        return -EINVAL;
+
+    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
+        return -EINVAL;
+    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
+        return -EINVAL;
+    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
+        return -EINVAL;
+    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
+        return -EINVAL;
+    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
+        return -EINVAL;
+
+    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+
+    /* XXX other state:
+     * - SCTLR
+     * - TTBR0/1
+     * - TTBCR
+     */
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
+
 void arch_dump_domain_info(struct domain *d)
 {
 }
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 016340c..3b48917 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
 DUMMY(pirq_set_affinity);
 
 /* VCPU */
-DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1b1bcf3..e439727 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
-    union {
-        uint32_t reg[16];
-        struct {
-            uint32_t __pad[12];
-            uint32_t sp; /* r13 */
-            uint32_t lr; /* r14 */
-            uint32_t pc; /* r15 */
-        };
-    };
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2G-000462-Cm; Tue, 26 Jun 2012 10:30: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 1SjT2E-00044h-6C
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:14 +0000
Received: from [85.158.143.99:31438] by server-3.bemta-4.messagelabs.com id
	A7/29-05808-53F89EF4; Tue, 26 Jun 2012 10:30:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340706610!23915013!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3348 invoked from network); 26 Jun 2012 10:30:11 -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;
	26 Jun 2012 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425984"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-SF;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:30 +0000
Message-ID: <1340706604-1313-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 06/40] arm: hook up domctl and memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5ed754f..5d8b7f9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -373,6 +373,8 @@ typedef unsigned long arm_hypercall_t(
     [ __HYPERVISOR_ ## x ] = (arm_hypercall_t *) do_ ## x
 
 static arm_hypercall_t *arm_hypercall_table[] = {
+    HYPERCALL(memory_op),
+    HYPERCALL(domctl),
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2H-00046T-88; Tue, 26 Jun 2012 10:30:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjT2F-00045F-CN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:15 +0000
Received: from [85.158.143.99:44319] by server-2.bemta-4.messagelabs.com id
	67/FA-17938-63F89EF4; Tue, 26 Jun 2012 10:30:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340706610!23915013!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3510 invoked from network); 26 Jun 2012 10:30:13 -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;
	26 Jun 2012 10:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425986"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-Ul;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:31 +0000
Message-ID: <1340706604-1313-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 07/40] arm: allocate and setup a guest vcpu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/domain.c         |   67 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/dummy.S          |    3 --
 xen/include/public/arch-arm.h |    9 -----
 3 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9339a11..b099d91 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -144,6 +144,17 @@ void free_vcpu_struct(struct vcpu *v)
     free_xenheap_page(v);
 }
 
+struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+{
+    return xmalloc(struct vcpu_guest_context);
+
+}
+
+void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
+{
+    xfree(vgc);
+}
+
 int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
@@ -212,6 +223,62 @@ void arch_domain_destroy(struct domain *d)
     /* domain_vgic_destroy */
 }
 
+static int is_guest_psr(uint32_t psr)
+{
+    switch (psr & PSR_MODE_MASK)
+    {
+    case PSR_MODE_USR:
+    case PSR_MODE_FIQ:
+    case PSR_MODE_IRQ:
+    case PSR_MODE_SVC:
+    case PSR_MODE_ABT:
+    case PSR_MODE_UND:
+    case PSR_MODE_SYS:
+        return 1;
+    case PSR_MODE_MON:
+    case PSR_MODE_HYP:
+    default:
+        return 0;
+    }
+}
+
+/*
+ * Initialise VCPU state. The context can be supplied by either the
+ * toolstack (XEN_DOMCTL_setvcpucontext) or the guest
+ * (VCPUOP_initialise) and therefore must be properly validated.
+ */
+int arch_set_info_guest(
+    struct vcpu *v, vcpu_guest_context_u c)
+{
+    struct cpu_user_regs *regs = &c.nat->user_regs;
+
+    if ( !is_guest_psr(regs->cpsr) )
+        return -EINVAL;
+
+    if ( regs->spsr_svc && !is_guest_psr(regs->spsr_svc) )
+        return -EINVAL;
+    if ( regs->spsr_abt && !is_guest_psr(regs->spsr_abt) )
+        return -EINVAL;
+    if ( regs->spsr_und && !is_guest_psr(regs->spsr_und) )
+        return -EINVAL;
+    if ( regs->spsr_irq && !is_guest_psr(regs->spsr_irq) )
+        return -EINVAL;
+    if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
+        return -EINVAL;
+
+    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+
+    /* XXX other state:
+     * - SCTLR
+     * - TTBR0/1
+     * - TTBCR
+     */
+
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
+
 void arch_dump_domain_info(struct domain *d)
 {
 }
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 016340c..3b48917 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,11 +20,8 @@ DUMMY(pirq_guest_unbind);
 DUMMY(pirq_set_affinity);
 
 /* VCPU */
-DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1b1bcf3..e439727 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,15 +124,6 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
-    union {
-        uint32_t reg[16];
-        struct {
-            uint32_t __pad[12];
-            uint32_t sp; /* r13 */
-            uint32_t lr; /* r14 */
-            uint32_t pc; /* r15 */
-        };
-    };
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2H-00046j-L8; Tue, 26 Jun 2012 10:30:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjT2F-00045F-Ra
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:15 +0000
Received: from [85.158.143.35:54482] by server-2.bemta-4.messagelabs.com id
	EF/FA-17938-73F89EF4; Tue, 26 Jun 2012 10:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340706609!15649665!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29193 invoked from network); 26 Jun 2012 10:30:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425987"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT25-00064E-1D;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:33 +0000
Message-ID: <1340706604-1313-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 09/40] arm: remove unnecessarily verbose
	print from p2m_load_VTTBR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/p2m.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ea385a6..6df5b62 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -28,8 +28,6 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
-
     WRITE_CP64(vttbr, VTTBR);
     isb(); /* Ensure update is visible */
 }
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2H-00046j-L8; Tue, 26 Jun 2012 10:30:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjT2F-00045F-Ra
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:15 +0000
Received: from [85.158.143.35:54482] by server-2.bemta-4.messagelabs.com id
	EF/FA-17938-73F89EF4; Tue, 26 Jun 2012 10:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340706609!15649665!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29193 invoked from network); 26 Jun 2012 10:30:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425987"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT25-00064E-1D;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:33 +0000
Message-ID: <1340706604-1313-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 09/40] arm: remove unnecessarily verbose
	print from p2m_load_VTTBR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/p2m.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ea385a6..6df5b62 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -28,8 +28,6 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    printk("VTTBR dom%d = %"PRIx64"\n", d->domain_id, vttbr);
-
     WRITE_CP64(vttbr, VTTBR);
     isb(); /* Ensure update is visible */
 }
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2I-00046v-2g; Tue, 26 Jun 2012 10:30: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 1SjT2F-00045T-Qu
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:16 +0000
Received: from [85.158.138.51:51563] by server-4.bemta-3.messagelabs.com id
	15/0A-17105-73F89EF4; Tue, 26 Jun 2012 10:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340706612!25530966!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28724 invoked from network); 26 Jun 2012 10:30:13 -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;
	26 Jun 2012 10:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425985"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-W7;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:32 +0000
Message-ID: <1340706604-1313-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 08/40] arm: print domid as part of debug trap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5d8b7f9..40bb375 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -388,25 +388,26 @@ static arm_hypercall_t *arm_hypercall_table[] = {
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
     uint32_t reg, *r;
-
+    uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = &regs->r0 + reg;
-        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+               domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("Reached %08"PRIx32"\n", regs->pc);
+        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
         break;
     case 0xfe:
         printk("%c", (char)(regs->r0 & 0xff));
         break;
     case 0xff:
-        printk("DEBUG\n");
+        printk("DOM%d: DEBUG\n", domid);
         show_execution_state(regs);
         break;
     default:
-        panic("Unhandled debug trap %#x\n", code);
+        panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
         break;
     }
 }
-- 
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 Jun 26 10:30:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjT2E-00044v-DR; Tue, 26 Jun 2012 10:30: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 1SjT2D-00044V-9S
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:13 +0000
Received: from [85.158.143.35:54276] by server-1.bemta-4.messagelabs.com id
	D1/B3-24392-43F89EF4; Tue, 26 Jun 2012 10:30:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340706609!15649665!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28936 invoked from network); 26 Jun 2012 10:30:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425983"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-J0;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:26 +0000
Message-ID: <1340706604-1313-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 02/40] arm: handy function to print a walk of
	a page 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

Include helpers for dumping hypervisor walks and guest p2m walks.

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/mm.c          |   49 +++++++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/p2m.c         |   15 +++++++++++++
 xen/include/asm-arm/page.h |   26 +++++++++++++++++++++++
 3 files changed, 89 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 10ff883..715a98a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -26,6 +26,7 @@
 #include <xen/preempt.h>
 #include <xen/errno.h>
 #include <xen/guest_access.h>
+#include <xen/domain_page.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <public/memory.h>
@@ -42,6 +43,8 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t boot_httbr;
 
+static paddr_t phys_offset;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -53,6 +56,50 @@ unsigned long max_page;
 
 extern char __init_begin[], __init_end[];
 
+void dump_pt_walk(lpae_t *first, paddr_t addr)
+{
+    lpae_t *second = NULL, *third = NULL;
+
+    if ( first_table_offset(addr) >= LPAE_ENTRIES )
+        return;
+
+    printk("1ST[0x%llx] = 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),
+           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),
+           third[third_table_offset(addr)].bits);
+
+done:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+
+}
+
+void dump_hyp_walk(uint32_t addr)
+{
+    uint64_t httbr = READ_CP64(HTTBR);
+
+    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
+           addr, httbr);
+
+    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    dump_pt_walk(xen_pgtable, addr);
+}
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
@@ -159,7 +206,7 @@ void unmap_domain_page(const void *va)
  * Changes here may need matching changes in head.S */
 void __init setup_pagetables(unsigned long boot_phys_offset)
 {
-    paddr_t xen_paddr, phys_offset;
+    paddr_t xen_paddr;
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 4f624d8..ea385a6 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -5,6 +5,21 @@
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
 
+void dump_p2m_lookup(struct domain *d, paddr_t addr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first;
+
+    printk("dom%d IPA 0x%"PRIpaddr"\n", d->domain_id, addr);
+
+    printk("P2M @ %p mfn:0x%lx\n",
+           p2m->first_level, page_to_mfn(p2m->first_level));
+
+    first = __map_domain_page(p2m->first_level);
+    dump_pt_walk(first, addr);
+    unmap_domain_page(first);
+}
+
 void p2m_load_VTTBR(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b6df64e..183ba5f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -132,10 +132,28 @@ typedef struct {
     unsigned long sbz1:5;
 } __attribute__((__packed__)) lpae_p2m_t;
 
+/*
+ * Walk is the common bits of p2m and pt entries which are needed to
+ * simply walk the table (e.g. for debug).
+ */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    unsigned long pad2:10;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+
+    unsigned long pad1:24;
+} __attribute__((__packed__)) lpae_walk_t;
+
 typedef union {
     uint64_t bits;
     lpae_pt_t pt;
     lpae_p2m_t p2m;
+    lpae_walk_t walk;
 } lpae_t;
 
 /* Standard entry type that we'll use to build Xen's own pagetables.
@@ -252,6 +270,14 @@ static inline void flush_guest_tlb(void)
     WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
 }
 
+/* Print a walk of an arbitrary page table */
+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);
+/* 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)
 {
-- 
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 Jun 26 10:30:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjT2E-00044v-DR; Tue, 26 Jun 2012 10:30: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 1SjT2D-00044V-9S
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:13 +0000
Received: from [85.158.143.35:54276] by server-1.bemta-4.messagelabs.com id
	D1/B3-24392-43F89EF4; Tue, 26 Jun 2012 10:30:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340706609!15649665!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28936 invoked from network); 26 Jun 2012 10:30:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425983"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-J0;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:26 +0000
Message-ID: <1340706604-1313-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 02/40] arm: handy function to print a walk of
	a page 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

Include helpers for dumping hypervisor walks and guest p2m walks.

Useful for debug but not actually used in this patch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/mm.c          |   49 +++++++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/p2m.c         |   15 +++++++++++++
 xen/include/asm-arm/page.h |   26 +++++++++++++++++++++++
 3 files changed, 89 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 10ff883..715a98a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -26,6 +26,7 @@
 #include <xen/preempt.h>
 #include <xen/errno.h>
 #include <xen/guest_access.h>
+#include <xen/domain_page.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <public/memory.h>
@@ -42,6 +43,8 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t boot_httbr;
 
+static paddr_t phys_offset;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -53,6 +56,50 @@ unsigned long max_page;
 
 extern char __init_begin[], __init_end[];
 
+void dump_pt_walk(lpae_t *first, paddr_t addr)
+{
+    lpae_t *second = NULL, *third = NULL;
+
+    if ( first_table_offset(addr) >= LPAE_ENTRIES )
+        return;
+
+    printk("1ST[0x%llx] = 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),
+           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),
+           third[third_table_offset(addr)].bits);
+
+done:
+    if (third) unmap_domain_page(third);
+    if (second) unmap_domain_page(second);
+
+}
+
+void dump_hyp_walk(uint32_t addr)
+{
+    uint64_t httbr = READ_CP64(HTTBR);
+
+    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
+           addr, httbr);
+
+    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    dump_pt_walk(xen_pgtable, addr);
+}
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
@@ -159,7 +206,7 @@ void unmap_domain_page(const void *va)
  * Changes here may need matching changes in head.S */
 void __init setup_pagetables(unsigned long boot_phys_offset)
 {
-    paddr_t xen_paddr, phys_offset;
+    paddr_t xen_paddr;
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 4f624d8..ea385a6 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -5,6 +5,21 @@
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
 
+void dump_p2m_lookup(struct domain *d, paddr_t addr)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    lpae_t *first;
+
+    printk("dom%d IPA 0x%"PRIpaddr"\n", d->domain_id, addr);
+
+    printk("P2M @ %p mfn:0x%lx\n",
+           p2m->first_level, page_to_mfn(p2m->first_level));
+
+    first = __map_domain_page(p2m->first_level);
+    dump_pt_walk(first, addr);
+    unmap_domain_page(first);
+}
+
 void p2m_load_VTTBR(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b6df64e..183ba5f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -132,10 +132,28 @@ typedef struct {
     unsigned long sbz1:5;
 } __attribute__((__packed__)) lpae_p2m_t;
 
+/*
+ * Walk is the common bits of p2m and pt entries which are needed to
+ * simply walk the table (e.g. for debug).
+ */
+typedef struct {
+    /* These are used in all kinds of entry. */
+    unsigned long valid:1;      /* Valid mapping */
+    unsigned long table:1;      /* == 1 in 4k map entries too */
+
+    unsigned long pad2:10;
+
+    /* The base address must be approprately aligned for Block entries */
+    unsigned long base:28;      /* Base address of block or next table */
+
+    unsigned long pad1:24;
+} __attribute__((__packed__)) lpae_walk_t;
+
 typedef union {
     uint64_t bits;
     lpae_pt_t pt;
     lpae_p2m_t p2m;
+    lpae_walk_t walk;
 } lpae_t;
 
 /* Standard entry type that we'll use to build Xen's own pagetables.
@@ -252,6 +270,14 @@ static inline void flush_guest_tlb(void)
     WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
 }
 
+/* Print a walk of an arbitrary page table */
+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);
+/* 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)
 {
-- 
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 Jun 26 10:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30: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 1SjT2I-00046v-2g; Tue, 26 Jun 2012 10:30: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 1SjT2F-00045T-Qu
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:16 +0000
Received: from [85.158.138.51:51563] by server-4.bemta-3.messagelabs.com id
	15/0A-17105-73F89EF4; Tue, 26 Jun 2012 10:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340706612!25530966!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28724 invoked from network); 26 Jun 2012 10:30:13 -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;
	26 Jun 2012 10:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29425985"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-W7;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:32 +0000
Message-ID: <1340706604-1313-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 08/40] arm: print domid as part of debug trap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5d8b7f9..40bb375 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -388,25 +388,26 @@ static arm_hypercall_t *arm_hypercall_table[] = {
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
     uint32_t reg, *r;
-
+    uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = &regs->r0 + reg;
-        printk("R%d = %#010"PRIx32" at %#010"PRIx32"\n", reg, *r, regs->pc);
+        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+               domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("Reached %08"PRIx32"\n", regs->pc);
+        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
         break;
     case 0xfe:
         printk("%c", (char)(regs->r0 & 0xff));
         break;
     case 0xff:
-        printk("DEBUG\n");
+        printk("DOM%d: DEBUG\n", domid);
         show_execution_state(regs);
         break;
     default:
-        panic("Unhandled debug trap %#x\n", code);
+        panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
         break;
     }
 }
-- 
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 Jun 26 10:30:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjT2S-0004CR-3W; Tue, 26 Jun 2012 10:30: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 1SjT2R-0004Bi-22
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:27 +0000
Received: from [85.158.143.35:26640] by server-3.bemta-4.messagelabs.com id
	3F/79-05808-24F89EF4; Tue, 26 Jun 2012 10:30:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340706609!18079545!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21928 invoked from network); 26 Jun 2012 10:30:11 -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;
	26 Jun 2012 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200050551"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-Pd;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:29 +0000
Message-ID: <1340706604-1313-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 05/40] arm: enable interrupts while handling
	traps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 most traps we can do this as soon as we have saved the necessary state.
For IRQs and FIQs we must wait until we have acked the interrupt with the GIC.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/entry.S |   17 ++++++++++++++---
 xen/arch/arm/gic.c   |    2 ++
 xen/arch/arm/traps.c |    1 -
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 7a22e2d..5bc3906 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -46,6 +46,17 @@ save_guest_regs:
 	ALIGN;												\
 trap_##trap:												\
 	SAVE_ALL;											\
+	cpsie i; 	/* local_irq_enable */								\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+#define DEFINE_TRAP_ENTRY_NOIRQ(trap)									\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
 	adr lr, return_from_trap;									\
 	mov r0, sp;											\
 	mov r11, sp;											\
@@ -69,8 +80,8 @@ DEFINE_TRAP_ENTRY(supervisor_call)
 DEFINE_TRAP_ENTRY(prefetch_abort)
 DEFINE_TRAP_ENTRY(data_abort)
 DEFINE_TRAP_ENTRY(hypervisor)
-DEFINE_TRAP_ENTRY(irq)
-DEFINE_TRAP_ENTRY(fiq)
+DEFINE_TRAP_ENTRY_NOIRQ(irq)
+DEFINE_TRAP_ENTRY_NOIRQ(fiq)
 
 return_from_trap:
 	mov sp, r11
@@ -83,7 +94,7 @@ ENTRY(return_to_new_vcpu)
 ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
-	bl leave_hypervisor_tail
+	bl leave_hypervisor_tail /* Disables interrupts on return */
 	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index cc9d37b..1a2b95f 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -509,6 +509,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     uint32_t intack = GICC[GICC_IAR];
     unsigned int irq = intack & GICC_IA_IRQ;
 
+    local_irq_enable();
+
     if ( irq == 1023 )
         /* Spurious interrupt */
         return;
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index abc26a3..5ed754f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -412,7 +412,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     arm_hypercall_t *call = NULL;
-    local_irq_enable();
 
     if ( iss != XEN_HYPERCALL_TAG )
     {
-- 
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 Jun 26 10:30:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjT2S-0004CR-3W; Tue, 26 Jun 2012 10:30: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 1SjT2R-0004Bi-22
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:27 +0000
Received: from [85.158.143.35:26640] by server-3.bemta-4.messagelabs.com id
	3F/79-05808-24F89EF4; Tue, 26 Jun 2012 10:30:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340706609!18079545!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21928 invoked from network); 26 Jun 2012 10:30:11 -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;
	26 Jun 2012 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200050551"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-Pd;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:29 +0000
Message-ID: <1340706604-1313-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 05/40] arm: enable interrupts while handling
	traps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 most traps we can do this as soon as we have saved the necessary state.
For IRQs and FIQs we must wait until we have acked the interrupt with the GIC.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/entry.S |   17 ++++++++++++++---
 xen/arch/arm/gic.c   |    2 ++
 xen/arch/arm/traps.c |    1 -
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 7a22e2d..5bc3906 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -46,6 +46,17 @@ save_guest_regs:
 	ALIGN;												\
 trap_##trap:												\
 	SAVE_ALL;											\
+	cpsie i; 	/* local_irq_enable */								\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
+
+#define DEFINE_TRAP_ENTRY_NOIRQ(trap)									\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
 	adr lr, return_from_trap;									\
 	mov r0, sp;											\
 	mov r11, sp;											\
@@ -69,8 +80,8 @@ DEFINE_TRAP_ENTRY(supervisor_call)
 DEFINE_TRAP_ENTRY(prefetch_abort)
 DEFINE_TRAP_ENTRY(data_abort)
 DEFINE_TRAP_ENTRY(hypervisor)
-DEFINE_TRAP_ENTRY(irq)
-DEFINE_TRAP_ENTRY(fiq)
+DEFINE_TRAP_ENTRY_NOIRQ(irq)
+DEFINE_TRAP_ENTRY_NOIRQ(fiq)
 
 return_from_trap:
 	mov sp, r11
@@ -83,7 +94,7 @@ ENTRY(return_to_new_vcpu)
 ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
-	bl leave_hypervisor_tail
+	bl leave_hypervisor_tail /* Disables interrupts on return */
 	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index cc9d37b..1a2b95f 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -509,6 +509,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     uint32_t intack = GICC[GICC_IAR];
     unsigned int irq = intack & GICC_IA_IRQ;
 
+    local_irq_enable();
+
     if ( irq == 1023 )
         /* Spurious interrupt */
         return;
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index abc26a3..5ed754f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -412,7 +412,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     arm_hypercall_t *call = NULL;
-    local_irq_enable();
 
     if ( iss != XEN_HYPERCALL_TAG )
     {
-- 
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 Jun 26 10:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjT2f-0004OT-I5; Tue, 26 Jun 2012 10:30: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 1SjT2e-0004Mj-66
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:40 +0000
Received: from [193.109.254.147:9242] by server-3.bemta-14.messagelabs.com id
	88/BD-08687-F4F89EF4; Tue, 26 Jun 2012 10:30:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340706605!8430703!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16043 invoked from network); 26 Jun 2012 10:30:09 -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;
	26 Jun 2012 10:30:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200050550"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-OH;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:28 +0000
Message-ID: <1340706604-1313-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 04/40] arm: restore stack on return from trap.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 align the stack before calling into C code but we weren't undoing this on
return.

Collapse continue_(non)idle_domain into continue_new_vcpu.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |   16 +++-------------
 xen/arch/arm/entry.S  |    5 ++++-
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4b38790..9339a11 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -16,17 +16,6 @@
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
-static void continue_idle_domain(struct vcpu *v)
-{
-    reset_stack_and_jump(idle_loop);
-}
-
-static void continue_nonidle_domain(struct vcpu *v)
-{
-    /* check_wakeup_from_wait(); */
-    reset_stack_and_jump(return_from_trap);
-}
-
 void idle_loop(void)
 {
     for ( ; ; )
@@ -72,9 +61,10 @@ static void continue_new_vcpu(struct vcpu *prev)
     schedule_tail(prev);
 
     if ( is_idle_vcpu(current) )
-        continue_idle_domain(current);
+        reset_stack_and_jump(idle_loop);
     else
-        continue_nonidle_domain(current);
+        /* check_wakeup_from_wait(); */
+        reset_stack_and_jump(return_to_new_vcpu);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index f261a9f..7a22e2d 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -72,7 +72,9 @@ DEFINE_TRAP_ENTRY(hypervisor)
 DEFINE_TRAP_ENTRY(irq)
 DEFINE_TRAP_ENTRY(fiq)
 
-ENTRY(return_from_trap)
+return_from_trap:
+	mov sp, r11
+ENTRY(return_to_new_vcpu)
 	ldr r11, [sp, #UREGS_cpsr]
 	and r11, #PSR_MODE_MASK
 	cmp r11, #PSR_MODE_HYP
@@ -82,6 +84,7 @@ ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
 	bl leave_hypervisor_tail
+	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
 	RESTORE_BANKED(svc)
-- 
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 Jun 26 10:30:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjT2f-0004OT-I5; Tue, 26 Jun 2012 10:30: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 1SjT2e-0004Mj-66
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:30:40 +0000
Received: from [193.109.254.147:9242] by server-3.bemta-14.messagelabs.com id
	88/BD-08687-F4F89EF4; Tue, 26 Jun 2012 10:30:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340706605!8430703!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16043 invoked from network); 26 Jun 2012 10:30:09 -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;
	26 Jun 2012 10:30:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200050550"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:30:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:30:05 -0400
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 1SjT24-00064E-OH;
	Tue, 26 Jun 2012 11:30:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:28 +0000
Message-ID: <1340706604-1313-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 04/40] arm: restore stack on return from trap.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 align the stack before calling into C code but we weren't undoing this on
return.

Collapse continue_(non)idle_domain into continue_new_vcpu.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |   16 +++-------------
 xen/arch/arm/entry.S  |    5 ++++-
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4b38790..9339a11 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -16,17 +16,6 @@
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
-static void continue_idle_domain(struct vcpu *v)
-{
-    reset_stack_and_jump(idle_loop);
-}
-
-static void continue_nonidle_domain(struct vcpu *v)
-{
-    /* check_wakeup_from_wait(); */
-    reset_stack_and_jump(return_from_trap);
-}
-
 void idle_loop(void)
 {
     for ( ; ; )
@@ -72,9 +61,10 @@ static void continue_new_vcpu(struct vcpu *prev)
     schedule_tail(prev);
 
     if ( is_idle_vcpu(current) )
-        continue_idle_domain(current);
+        reset_stack_and_jump(idle_loop);
     else
-        continue_nonidle_domain(current);
+        /* check_wakeup_from_wait(); */
+        reset_stack_and_jump(return_to_new_vcpu);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index f261a9f..7a22e2d 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -72,7 +72,9 @@ DEFINE_TRAP_ENTRY(hypervisor)
 DEFINE_TRAP_ENTRY(irq)
 DEFINE_TRAP_ENTRY(fiq)
 
-ENTRY(return_from_trap)
+return_from_trap:
+	mov sp, r11
+ENTRY(return_to_new_vcpu)
 	ldr r11, [sp, #UREGS_cpsr]
 	and r11, #PSR_MODE_MASK
 	cmp r11, #PSR_MODE_HYP
@@ -82,6 +84,7 @@ ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
 	bl leave_hypervisor_tail
+	mov sp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	/* LR_usr is the same physical register as lr and is restored below */
 	RESTORE_BANKED(svc)
-- 
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 Jun 26 10:41:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTDQ-0006Ez-HM; Tue, 26 Jun 2012 10:41:48 +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 1ShNXg-0001Gq-EF
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 16:14:05 +0000
Received: from [85.158.143.99:44428] by server-3.bemta-4.messagelabs.com id
	DF/11-05808-BC6F1EF4; Wed, 20 Jun 2012 16:14:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340208832!21915062!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=Known-good attachment 
  (ppt)
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29049 invoked from network); 20 Jun 2012 16:13:52 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 16:13:52 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 20 Jun 2012 09:13:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="ppt'32?scan'32,208,32";a="114261987"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Jun 2012 09:13:49 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Jun 2012 09:13:48 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Jun 2012 09:13:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 21 Jun 2012 00:13:39 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJw==
Date: Wed, 20 Jun 2012 16:13:38 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233524C532@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_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 26 Jun 2012 10:41:46 +0000
Cc: "Luck, Tony" <tony.luck@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan, Keir,

Recently we design xen vMCE as attached.
Please kindly help me to review it, any comments/suggestions are appreciate=
d.

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_
Content-Type: application/vnd.ms-powerpoint; name="xen vMCE design.ppt"
Content-Description: xen vMCE design.ppt
Content-Disposition: attachment; filename="xen vMCE design.ppt"; size=493568;
	creation-date="Mon, 04 Jun 2012 04:50:51 GMT";
	modification-date="Wed, 20 Jun 2012 15:52:00 GMT"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAIAAAAwQMAAAAAAAAA
EAAA/v///wAAAAD+////AAAAALkDAAC6AwAAuwMAALwDAAC9AwAAvgMAAL8DAADAAwAA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////+g
Rh3wBHIAAE0MqhifuUzfr0xZhpKngAb//9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAE
AAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgDAAQAAwERAAIR
AQMRAf/EANAAAQABBAMBAQAAAAAAAAAAAAAIAQcJCgIDBgULAQEAAQUBAQEAAAAAAAAAAAAABwEC
BQYIBAMJEAEAAAUDAQYDBAcFBQUJAAAAAQIDBAUGBwgRIRKWV9caMRMJQVEiFGFxMhUWFwqBkaGy
U9FCkjMnwSMmGBnwseFSYnJzKDkRAQABAgMGAwUDBwgHBAoDAAABAgQRAwUhk1TUBgcxEhhBUWEi
E3EyCIGRobHRUhRCcrIjMxVVFvDBYpLCJJRDNHQX8YKiU2Oz0yV1N0RFNv/aAAwDAQACEQMRAD8A
3+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQnuVOdPlRxN8C7weuzv70q9veM1nfW3KOBvVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3
wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5
U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4P
Rt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tu
UPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7
e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wL
vB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U5
0+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt
1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUP
VP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8
ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB
67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+
VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c
82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3
wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5
U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4P
Rt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tu
UPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7
e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wL
vB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U5
0+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt
1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUP
VP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8
ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB
67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+
VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c
82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3
wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5
U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4P
Rt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tu
UPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7
e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wL
vB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U5
0+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt
1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUP
VP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8
ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB
67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+
VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c
82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c8216XTLmkAAAABTrD74f3gdYffD++AHWH3w/vgB1h98P74ArCMI/bD
+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHCtPGnRnnhCEYySTTQ/DGEP97snn
6x+MZezpDsh1KKPNX5oqxmmqnGn3xMT+XapXX5afLVThFVM4VfGJj9Sa24GD4sbR3GjNL6h2h3b1
rqDK7Zbca2zeobTeCw01YXF/rbTttm7qjYYmGk76FnbWU9eNKSWNWeM0JO917ekI40+76s13Jzrz
Try3ybei6qpiiq3qrqpppqmnyzVFURPh4xHh8UjXtv0XoWfk2WqWt5m3VVtTVM0Z1FNNVVVEVeam
Jy5mI24YTV4xPsweDhrTh5GEI/8Al43l7YQj2b82cYdv3R/giHVmq9O6y804anZxGPh/CV7Ph99j
Kbzo3CMLC7mMPGbmiJn4/wBmR1pw8hCMf/LzvJ2ffvxZ9P7f/BPwUp03rSaoinU7OapnZH8JXOM/
Z9RWbzo2Ixq0+6in2/8AM0f/AE5/U6Ya74cTRjJJx83hqVYdny6O/VpVn6/d8qloaeaX+0zLDrbJ
riq41TT6Yj+T/BVxj+Wc7Y++Xd9D1UY0aZf1R7/4uif0RkOUdc8OaUYS1uPu81Cebtllq79WVD8P
2xj+Y0LSmmh1+yEOsV1Ondb10/Uy9T06aP8Aw1X+rNmXxrvuiYqnzabqFMR/8enx3GH6XdZY3ipu
NcRw+ByG4vH/AFJdzy0sHlNwszjNxdrrq8mnhLb2epMxh8ZitUaXs7qb8M2Qhb3Nvbd7vVZO5Dq+
Oddda6RlVXV3l2uoW9OGOXkZdeVnTTH3qqJqrqiryxtmnDHBXKtuitXzKbSzrubC4qxwzM7MpzMq
KvZTXFNFMx5p2RO3asjrnRGp9t9W5zQ2ssXUw+pNO3cLXIWc1ehd0aklejSvLHIWF9aT1bPJYvJ2
VxTuLS6oTz0Li3qSTyTRhFsmn6lY6va03+nVzXaVxsmYw2/yqZpnbE0zsnHxnwaxqGnXulXM2OoU
xRd0eMROOyfCrHwmKo2xh7PF5R7nhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfUwWDzmqcvb6e0vhMzqbP3c
0klpg9O4q/zmXuZ6kYS05aGNxlvdXlWaeMeyEJO157m7tbOMbzNy8mnDHGuqmiMI9uNUxH+ufZD0
2tnd3s4WeVmZtWOGFFM1Tj7sKYn/AE8WT/Zb6Ln1Dt6be2ydPZSba7T9zCSpLnN4M5j9FRltZ4d7
81+4Z5r7Ufy4SdvSe1pzfoRJ1B397XdP5n8P/GZl9dYzHltafPFMx765+XCfCMJ8Ur6D2I7l69kx
dRaZdnaTEVea4r8mMT7qfvbPbjCYFj9CPSei6Hz+Rn1FONe11xS6RvsTiL/EXV7Y93rCalNU1TqX
CTVqnX4xhQhDr/c0jN/ENqV7X5Om+l9Vusv2V1UV0xt8MPJRVHht8Ybvk/h/0yzp8/UnUulWtX7l
OZTVPxn5q6J2T7Iifi+lT+mT9IvCwjQ1T9WDGX15LGElWbDVdCULaSrHs/BG2jl5fl9ftjPGH6Xx
/wDNfvbnz9Sz6Mr/AIf2TXObFWPt2eWnZ4Pdldouz0U+XP6ty6s3Hb5JysP6U/reisPpKfS717N+
Q2z+qxpj97VId22o53KbXzyVKs0IfLpxkvMrgZ6nej9kse88ud3o7u6dPm1TpDMpo/2Yzpn9FNWL
7ZfZTtTe1+TT+rMuc33V1ZMR+mqmf0vM67/p09+5sRV1Fx55FbJ764r5dStZ2lSrc6Zvb6WEYxp0
rbM4+51Dp2aM9OMPxTTySxj9vR6tO/FF07l5v8P1ZpeoafnRsny0TmbY8flqiiqIifhLxaj+GfW6
6Pq9MajYahlzhMfP5JwnwnGJrpnGPbjEfnYZeQfE3kdxVzkmA3/2h1dtxWuKk1PHZjJ2cLzSWajL
9uE1djZrnAZKM0O35ctaWvD/AHqcE99M9ZdK9ZW03XTN/kXdEeNMVeXNp/nZc/NH6UE9S9GdUdI5
3k6gsc+1y6p+WqqMaZ2/vUx5f9SPDZWrgAAAAAAAAAAOFXspzfplnhH9MO5NDpH74dI9F2VERc5c
x4z4/HCqI2+/ZMrKpmcquJ2xE7Ph8lU7PdtiEm+WsIfzC0LGEIdY8edg4xj07Yx/l5jO2P3xal0H
VNNhc00zMU/3pcxhHujNrwj7I9jcOt5mdRtpmdsaXbzH2zlUYz9s+1aTQm0+vtx7HVud0ppfPZbS
W3mNsNQ7lapxeKrZPGaC0tdZGXG1NS6ikoz060cfbXEZoRlpR70e70iyeq63pukZtrk6leUUXN3m
TTb0/v5ntoq9/tjb4eLG6Zoup6vRd5+n2tddvaZcVXFWP3MufCun3Y+Oxf8Axm5fFDaCSEuhNjq/
I/Vlv0kqa+5AZbJ4TQclxGEJp62A2f0ZeWdS6s4Tfsxy2TnjGEO2Tp2NautK601mfLqWpZel20xM
TkWMRnZuE7J81zmY0U7MdtMYx4xthsmTqfRmjZcTplhmajdxOzOuJmMrGIxifoU/PhjswqqnH3Lh
Xn1C+YGh6lvjdN47bDYChVsbTIY3BaI4zbZ6LjNh7rrLY3lnX1Lo/KZnJ2d5ShH5dzNWrQmhDr34
vDb9r+jL6nM/is651HN/lznXtzOGE+ynLzIoxx98Pfc9zus7acvJtcm306ifuRk2dtGOzxmczLmv
DD/a2rm7T87efu9uXzun7bSu2PKahpzSGb1zqzQ+4mwW0mo7eXQem6MK2ocpfXtjgNNZSztcdZT9
6NS2rwrSd78EIxYTW+3vbjQbWLnPus/R6czMpyaM/KvLqK/qZuNNGXTFVc0zNU7cJifuszovcTuD
rtx/dv8AD5WreXLqza8nMtLWafJl4VVZkzTRFUeWNmOMfefX3g477K8iuOW4XJzj9thc8d929kMX
pHU3InjPQzc2oNCZHbbXMJKWC3i2evL+rcZTGYO5uq8PzWLr1Kk1CXvSy9IQh183T3U/UXR/VVr0
T1Ne5Wq6Rf05lFjexT5M36uTTGORmx+9MTjNfjX4S9XUPTXTPU3S131f0za5um6zYVZeZe2k1TXl
/SzqpmM7KmfCmJ2RR4UeMbEMdxLubV/G7j/rXKVpLrU2lc3r3ZOrkqkY1L/K6P05LjdVaNtb2pGM
Y1Y6XhmbuyoTTRjNLbRlk7ISwgkTRacqx6s1DTsqf6nPyqMzD+TTmRTNOZhHhHzYeHijnW8+q86U
sNRzKYjPyc2rLmcPmqomYqomqfGdmPj7Ea/v+6MY/wBnbGEYR/VNCLaaa4ropw9kYfmatXHz1T7J
nGPskXLQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAFJppZIRmm692WHWPdljNN0/RLDtmj90PtXUxFVURM4U4+PuU
nHwpjGv2R759zLFoTiJw+4/ad05uJ9QDkFTymd1FgMVqfT3FPjbeUNYbj3WOy9rC/wAZLuLrS1+b
gdGRu7epJ8y1hPJcSyRjDr1Qfd9cdd9WXOdpfbzSa8nKyM6rKzL+9+TKoqpnDzZWV/2vhsxiY2xP
xTXZdFdDdMZGTqfX+qUZ2bXlU5tFlZ/NmVxVH3c7N8MrxjGInHZP2LlXf1jK2y2JqaN+n/xS2Y4o
6W7la2k1jlMPQ3G3cy1vGSNCWvmc7eU4UZchUklhPGWvUuYU5+vSHT4eDJ7IxruZ/GdztW1DW7uZ
iYyqa6re3omPDDLpny1YYzETs2Mjn9640OmLbtrpNlpNtETE5k0U5+fXE+PmzKomqPCMY2xMsee7
nNfl3vzcV626/I/dzV9vdRqRrYuXV2Rw2n6ctTpGNGnp/T8+MwlOnCHZ8v5UekPiknQ+3nRPTtPk
0nSbLJnCPmmiivMnDbtqmmZ+OOKOdb7idbdQVebU9Yu86PNM/Tprroppx2fdiYpmPZhgi3PTp1qs
9StLPXrRmjNPcXU81xWqzTfimnmqVozzzRjH7Yx7W6U/JTFFGymnwiNkR9mHg0yuqrMqmrMmaqp8
ZmZnH85ChQh8KNKHX49Kcnb/AIKzMztnbKzy0+6FJra3n7JqFGb9dOSP/Yr5qsPLjPlIiKfu7F1t
qt9t5di87b5/ZrdrX+2OXtK1OpJX0dqjIYilVmhDstbvEyXE+IyttU+2lXt55Y/bBhNX6e0DqKzq
sdftsjPmZnyzmZdFcxHsiJqpmYZzR+ouodAzP47Qbm4ycJ+aKMyujGfbj5ZjFsncIfrZaY3/AKeP
4o/Um0nobWOmtfTUdM4/di/wdlLp67vb2EtrYWm5eAmp1bLF1rurP/3WXs/y8tGrHvTy0+nfhyh3
C/D9cdMxPV3ae4z8nUMqJzMy2prqpqopojzVTRnRMVVThT92ZmJ8HVPb/v3bdR4dLdzsjJzLXP8A
6ui4mimaaqq58kRXl4TTEfN96IiafGfegt9Xv6WdPhJqPH7xbLyZHLcZ9wsxLj7S3r158jdbWaqv
pat7a6busjUjNWyOlsxbSxjirqpGapLGSajUnmjCWMZE7Hd46+vrOvQuo4jL6wtYwmKYwjNoj/tY
j/Z+7XHj5piUdd7e0dHQ11l6709jX0ndbYmZx+lXPhl4+6r71M+GETHxnCU6EQAAAAAAAAAAA66v
/Lj+qf8AyxXZf/eMr/T+XS+dX9nmfb/wVJ8a52kyG/HK3jZsxibr8pfbo7c8YtFwvpYR72Mtsxof
E08hkYdP24Y/GyV6/SHxjJ0RnY6zbdM9Gapr2fEzRk3Oo1VRhtmfqVfTw+yvDFJ9/pGd1F1hpmi2
my5zbaxpiZ8MPpUzXt9ny+HvwTL25tNt92NO/VTkwWAucJt7xw472eh9hsPhcxnMDQx2n9Mbi/w/
++dTUMHlcbbaxz+s7ihWyV9+85byhG5uYxlkh3JEfavmaxoV70bVfZn19V1TVP4i7ivCI/rbeK5p
jGNkU1VTGzD7uHvx3/TMnSNVo6u/g6JyrDTLDKyrWaJxmfp53kivZO3zRETP87FLfeDizwnyOp99
eMGA4maM0Lndufp5YzlZp7fXTGuNfR1xU15Jo6hma1hc6cymYu9OVcTdXcIwrS9JZoyzRhCEOsOm
maD1f3Apt9O6vvNYuMzT7vqirT67X6WT9OMqczy401RlxOOGyMJ+za3HX+kug6K9Q6XtNKt6L206
b/jqbn6ufOZObTlRXhNM5k04YzjhMbPGdi827GyWw/Jnk3tJp7d/bLSFWhx2+mZtdv8AZfO5nVms
cLabvRn0zTxOnND6/ucLLcwxu3Whr2nXvrutiaH7xrS3Ee/N3ekGuaN1L1R0n0xfXWh6hcRdan1T
c21VGXTRX/D4z5szOyYrwoqzc2mIpppqq8sxGMRjjjn9X0DQOqeqLK11yyt5p07pm1z6aq68yiM6
ryxEZedVlY5lGXTNWM1UxjExhM+WcFvtidCcTcFvTn9d8acntbidT63+nNy2k3t2z2P1HrbV+1Wm
c/h8Nj6WIz2jM9r3HY3PxxedtakYVIR78JLmSMvYy3Ul71tmaBkWHWNN3Xp+R1Dp1VlnXNGTk52b
RVXX5/qZORNVMzHsmduH2yxnT1l0pk9RZ2o9KVWdGo5nT+o/xdvbV5ubl5WZTRTFH068yIxifbHv
8IY+uNejs/w/+nxyw5Fb0ULjS2R5e7Z47jvxv0DqLrQ1Hr7G5K/p5XU+4VHE3NSW9t9KYfHxjC1r
TU/lxh0nhN0nl6yb1Te2fXPdHQ+mumvLmWei3VV5dZ1HzZWXXhMU5VddONNOZMxONFUxMe2Eb9Ma
dddFdtdd6j6hn6dzrVrTbW2VX8uZXFVWNWZTROFVdEU4fNTGE+xjuy0vc4jbby9e90393J6dZZZZ
5YfwbpqHdm7nWWPXp3v1zRStbYf51uP35sMiqftqzpRZcUzT0Xke2iL7OiPspyo/aj3H4x/VL/kl
bNT7f51X65arPhT/ADKf6MKLloAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRux3FvdXfvTG7+vNJY+0xu3OxWh8vr
fcrX2frxx+nMLJYWc11i9MW13U7lO/1dqatCWjaWck0an44TRh0jL11XqDrPSemr+x0q6xzNW1G6
oyMjLpmJqmats1zRHzTTTGGM4YRPi2jQOjtW6l0++1W0jyaXp2V9TOzKowp8vuiqdmPw8fd4Mnux
ukPpL5D6bmd1HuzqHQdlzkl0BuTc4bF5DV2s7PU82rLS6ykdCUYYSyrS6enu5reFvCnJNJGSeEfx
R7sYxhEnUOod6cru1lWuk5VzT0HNzb/Un6OX5Iy/JH1MavGI8vm2x8J9iYNB0ztBV2ozrnVa8iet
qbe48kfVzPNOZFU/TmI+7jM+XZPjhLBXLUoUYzRr1JadxHuT1Y1Z4Sz9YyyQhGbvTd7p1m7Ps7XR
E5deOyJ8vj4exztGFURPjLnLdW00ektxRjH7oVZOv2/pV+lmz/Jq/Mr4JxfT64dyc6OSGL4/1deV
9tpclo/Veq/4ot8NTztSl/DVKxqzWUMdVubSnPLeS3fSM8Z4QlhBHfc7rrO7cdL5nUOVkRn3FObl
0RTOyYjMq8vm+z2Y4N/7ZdEZXcPqijp7Mz5ycmrKzK5qjbtojGIn4+6HxueXFOjwo5M6u47U9dVN
xf4Ww2l8rLqivh6eBr3f8RYmXJxs442nc3UkkMfJHu96E8YTQj1fftv1fn9fdI5PVWdb/wAPVnZm
ZRMRtifp1eWNv2fofPuP0dT0J1TndNZWdOfk5NFFUTMeHnpiqf1whzUrUqPSNWpJT6w6w780JesP
vhCMesYN78lXlivCfJV4T7J+yfa0OJiappj70eMe2HKSpTq0p5qc8s8Iwj2yTQm/ZljNN8Ix/Zlh
GMf0QXVZObTX5KqaorwxwwnHD3/Z8VJqpifLjHmbW2zHD7i/m/oYag5BZfY7by/3qtdkNzs5R3Mu
cNGfVdLN4rUmYtcZk4ZH5sJ4XljbUJJKcYfCEsIQ+1xjr/XPVFr+ILK6etdSvqdBqv7bzZVNX+zG
ymPd+774w8XZGgdHdM3PYDN164scqrW6bC58uZPj9+cJmccPd4/Fr/5vcnjZf8R9Lbb4rauey5DW
Woat9m9xpbCWlXyNlVuJp5Zp8/JeVKtxYz4+MJJLeajLGnP8XS9tpnUtt1xca3dX9VfS9VE/Tyvb
FXx90Y+Lm661PpfP6Kt9Hs7eunqenMxrzJj5aqcfCPjMbG1fxSzlxz7+hnrrR+5k8+c1Pozbrcnb
v98X8v5rIXOd2fsYah0DmY15oRmhe29nQsaMZodvSSaH2x68ZdZ5FHbH8QdtqOmbLa5uMq5pjwwp
uqvJm0T8fNM1Ye51/wBKZ89yuwlxpuoRjd22RXbzV441W0U15dcT7Y8sRTj4YxLSYozTTUqc037U
ZJe9+mPTtj/bF+gmdEfVqmnDyzOMYeGE7YcFR4Ye7Z+bY7HzVAAAAAAAAAddX/lx/VP/AJYrsv8A
7xlf6fy6Xzq/s8z7f+CpkMzm8MePvMfi3vbGxmylvthoPi5rDI4yn3YVL/D4/RWJkzNpbRh3Zvzl
ziKteSn1j0780EYW2hx1P0Vq/T3mw/is6+y6av3cyrNrmI+3GI+HxSlca3V051ppOvR//FyLKuaf
3qKcqiJn80zHvSm5G8ReS+1t1vFv5wSv9Sb28L+W2CzV1d5zai0o6vvcborVeb/izJba7laSpUbz
O4zKaYzdeNOndSUoTU4U4yz9ybrK0TpLrLo/WsjTenu48Tp3XGhVxTk5dxV9Pz10U+WrNyq6sKK5
rmJq21+Xb8szG1vnVHRvVOk5mpdS9ua41DpLWqZnNqyI8800V1eanKzMun+soiiJiNlGOEYzhMoO
ZvlpzTm1/q7XWfz2srTXmtdmKfHfV9/fbbS2Ne+2ilsZsXT0hUxtTAUaFpLJZw7v5mjTp3EYzde9
CPaka36K6By9NybOyy7f6Ntf/wAdlRGfE+S4irzxVtq8vy1bdvyo3u+sevs+/wA67va8+c65sJss
zHKw8+RNPkmn7uPzUz5feu1tjyG+qPrfJbI2u1VXfvWGX2HxFzpvam8wO1d1mL3E6Wyllb4m+0jl
svPpf5ep9O1MdaU6H5fLVbi2kpSw6Syxl77E6r012gs8vVKtUjS7a1v8ynMz/wDmaaqapjCfPRRF
eOXm+fDGqjCds4Sz9h1J3avc7T6NNp1HPurL5LeZyfLNMeWafJVXFM+fLiiZiKa8Y8JZM8Jw5+qb
utqClyX5nciNG8NNJ6b211boC61LqmO3+BzdHbjVGOvI6t0Vi9vdLW9npySlqGhUjCpC+rVK89Tu
xlpxnklgiPO687PaFZ/5Y6H0vP1zPzLrKzvJEZtdFOdl1x5K/q5vzRNO3DyxNHvmISfl9E92tYuq
uqOtb+30jKy7bNysa5y8uurLronzU/TyowmK/CfNhV8Jwa+G628G6G8eSwt5ubr7UGvamjsBYaI0
bUzd78yzwGjdPUJsdhMPp/HUJKGNxWNksLWnNNLRpwjVnjGaaefsi6c0bQdI0S3zZ0iyyLab2a7n
Nqox8015mH9XXjEfd8fbtc1a5rmp6vcZWTf5+Zm5FnTl5GXEzM0xFGzzU/bGz7HvcxD/APUjbiP2
R393I6eDdNsbbf8A+5u//AW//wA1k7iYnoa1w43P/wDlwj1H4x/VL/klbRT7f51X65anPhT/ADKf
6MKLloAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAC4e0u1+rt7NztBbR6CtIX2sdx9V4XSGn7eaXv05b7M3clv8AnLiX
rL0s8db9+vWmjGEsKdOPWLG61q1p0/ol3r1/VFNpZ5FWZVM44TMR8tOzGds/Bk9E0m61/WrXQrKm
arq6zqaIw8YiZ2zt90bWY36sWsdJcYtIbXfS52CrfldA7QYTD635B521nmp5DdTeHOWlPIUK2pK9
OElTIU8VLUjdwt6kYyU57ijJ0jLQhCED9ldNu+sdTv8Au31NT9W5vJryrLKqw/qMumcPPkzP3asI
iJnGMcMfbKdO8eoW3RunWXafpuYyrW0ijNu82J/t8yuMZpzYj71MTM4RhOGOGzBkY4kcetidRfQp
1lunndm9s8zuVa7Sb739rrzJ6LwF5q+3vsXk89Txt7Q1DWsZ8nQu7KW1p/KqS1ITU+7DuxgjDrrq
XqXI/EHkaRY31zRpk3lrH0vPPlqjy040zGOHzbYn4SlLo7pzQbnsBcatdWlvmalFndTGb5I80TFV
WExOGONOETH2O76D2ynH3WHBHdjcjdfZPbnc7J6T3R11fxyOq9E6d1FnpsRgtK4jLzYy0vsvZ160
I9lSWlLGeEvem7exb+I/XupNO7k2eldPX11b/wARbZMR5cyqiiKsyryxj5ZxiPjELPw/aH09qPbu
41HXbG2uarfPrmZqoiqqaaKPN4zHvx2e7H4Lw8OOTP0svqK7nah456a4IaX0fm62jM5qiFXVG2Gg
LHH5PEYW7s7DKW9rldMfLyOMyEkchTnpxhNLGMOsYTQjDo1vr3pHvJ2y0XL6puOoc3Pyqq6KKqIz
86vCrMiaopmnM+X+TO2PD8rP9DdU9pu5Gt5nTNtoWRkZtOXXVTX5MuMaaMImqJopiY+9GyUPuCnG
/TPEv69uvNjNC1bqfQ+nNuNwcxpChd3c91d4zTuptMaezVjg69xVhGrdQxMLuahJPPGM0aUsv2t+
7idV3fWX4crbWr2nC8m4yaK6/fOXmeWr44TVDQ+33S9t0j+IbP0S1ny2tGTn100++MyiJp8PhOK4
X1qd9+Pu5G5Gq+DeleO1O75e631LspicFvjNprScJKtTUOQx01hZXeooSx1VC1oWF38qaXtljLCM
OyDG9hOneqdE0rJ7j3OpzPRWR/E11WczVhTNETjV5fuzt27Nuz4st3013p3V9Sze31vp8T1hn1Wt
FN18sVV+aaZ8mP3o2TEbZw2z7l5tfaY+m99EPZ7a7D7lbHUeQW/G4ltXnusve6X0/qrV+qb3GUre
Op8/+b1fJc4TSOmLO/ufk2lChL82aWMIdJvxTQ1nS7nuh391y9/uy/8A7t6dtavkirMnLy4xmZoj
5J801VR4+7ZjEbGyapads+yeh2VOq6dRqGuZ9EzXjRFVUzERFc41RNMRE7I984zGzFavmjxN4g/U
I4C5Xntw528x21+4uiNP57Vd7iMNp6z0lNnbDRleP8eaD1xpvDSQw376xVnb1bmzvKFOM0e5LNCM
ZasYQzPQnWvWna/uHHbnrTPm6sM7MoppqiurMima8PJXRmTtnLmZwqoqwnHHCNm3A9ddGdE9ye3V
XX/SlvTZXdvRVXXl00xEz5JmJpmIiImYiMYmn5ZifFeLYWMsf6cnU80sY92PHzdiMsY/Hp/Fmc6d
f0sb1NFUfipy6asJq/vSz8PDHyUeHw9zMdO4x+Ga4ifH+AuP6ctLWnNCS3pzTR7sJaMkYx+6HcjG
EYff17sen39HeVfl+pOVV47cfs+3wcJ0RX5Iro8fZ78fs8fFu5cLtPXXBv6Hevdb7kUK+DzWr9tt
192a+OvqcbO+tL7dKwhgtFYuehWj3pLq6oVbGpLJGEJoS1vxQhHr0/Pvry6/8wfxC2+m6XH1cnKu
MnKxjCaccmZzMyImZ8IimrGZwjGJ9uGPevRFvPQPYK4vdR/qrrNts3NwqxxwzcMujwx2zNUYR4/N
jPtw0j6UZ405PmTTTzxlhGaaaWEsZu9+LrCEPhDpN2P0Fqw80xT92NkfZEOCKfuxM/enbP24y7FF
QAAAAAAAAHCpDrSmj90Jv8sV2X/3jK/0/l0vnV/Z5n2/8FSaXJvQF3ntZbe5KjrTZXEyXHHzYSEM
fq7fjZ7Reet4Sbf46TvX2ndV60xGbse/GSMZZatCSaaSMs0IRlmhGMG6N3Z7d9K5t5ouvarb2+qZ
Wp3FVeXMZkzTFWZXhFWFExjMTE4RM7JTnrHanuH1RRaazoWl3FxpmZptvTRmROXFNWGXREzGNcTh
jExtiNsKcft4uUHFfLXGX4/8q9ott5r2pJVyWIxfLTj5daWzFSlPCaT966Wym4V3hLzrCM3Wepb/
ADYdeyaDFdS9wvw9daWv8J1Rf6fcxHhXVlZk51Me6jNiiJpiPZHshk+n+334gOlbn+I6d0/UbSir
DzUUZmX5avjVTNcxOP2MkWO+tN9RO1t5KGX3V+n9qq5pyQlhl89uRxrnyVSMIdk9aex3Vs6NSpLH
4R+XCCKszRvwuVY/w2t3NvHujOzqon4T/VeH5UsZet/ibpn/AJnQ8m4p/wBrIyon88Z0fpifyvJa
1+sJ9THWFnXx1jyh4h7f2lWSNOX+X+7fFbEXdGWMO35F9kdwsvcUanWHZPL0jD7Hu0/Tvwm2mZGb
cX1OfnxP3q8y4qj8tPlwmPhLH6jqP4pbzLqybbTK7bKq/wDd0ZFMxtjwnzYxP2YMae6mf3430y1X
O70codrd0spUhCMlfW3MjY7N0rWaE/fhCyx91uZHF2VKE3+5Soyyw+5Kmjd1Ow3TmRGRoF/plrlx
s+XIr82E+M+byf8ApRXrfa/vz1LnTca9p+p3Gb8c7L8v+759i1v8rL7vxhLuNxw7v45od3lJx97v
ejLN1hLJDcWEsvejHr1mj2fD4M9R357S/N5tct6qppnbNOZHj8PIwlXYnuxVFMUaHc0xFUTh5sv2
fHzrxa607V05xS2ys62d0Lnp6u+25Nb8zoLcLRO4uOo9NIabpxo3uT0Pnc9YWN1GMOstKrUkqTyf
ilhGHWL3dHdXdNda9VXupdL3mVeWmXaZFFc0eaPLV9THCqKqafGNsYY7Hk6u6P6l6L6UstN6os82
zu8y5zq6Ir8vzU/TiJmny1VbInZOOCLH2/2S/wCSVJcRhMxP71X65RjV4U/zKf6MCq0AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAABnK/p7ttcdrfn/S1Rk6FO6l2o2m1hq7GU55JY/KzmYuLDS1ldwnm/37a0yFx3ez8M0/
WEXO/wCJ7Vrix7Z/weRVVRVd3uVlzMeE0R81UTP5PD2uhfw16Vk3vcSL3Mimqm1s8yuInxiucKYm
I+GPj7GM7mbrXJ7icueTOss5Vq1sjmN79xJa1SaeMJ6dDG6jyGGxksO9GMZaVtYY+lSjLDslgmLo
izttK6Q0nTLCmKbHL07L2x4zXXl0zEzHx8Z+KJOtb/P1XqzVNRv6qqr6vUMyMPZFNGZVGET8PCI9
0Nq/hdUl9vdrqEIwjGGzXIaEYQjCHSP721H0lm70Ze5NNCeHSEekY9YdjjXryKqPxMWmMT815aVf
kwpna7D6Fron8Nt1hMYU2l3TP241+H53w/oHdn0xuRsOsI/+M93Y9ev4Ywm26x0YRhGPTs7en631
/EZFX/m9pM4YxGXaR/u5kY/reb8Pc+btRqkRj5v6/Z7f7Kpil/p3f/6KXM32fyO3Ul7Iyxj1p5rS
/eh8f/qh+tMX4m5irthTtiKv4+22T4/czNuHu+KH/wANExHc+qmfvfwNz/Ty2U7RFSSl/Uo7ixqT
ySRqbFX0lOWaeSE1WP8ALrS8Ywpyxm61JoQkj+GHWbp2wh0hHpD2oxM/hWt4piZn+Onwj/49X6va
l21qiPxQ51VU4RFl7f8Aw9P6/Yhf9RnFap2r+t3tpv5rDReq8bs/itweOOUvNw7nT2U/gmTH0fyW
Gvq9bUsLWbDU/wB33k8YVJJ6sJ5J5e2DfO1+fZ6z+H+40GyuMudZqyr6iMnzR9SZqxwnyROOHxaV
3NyLnSu+tvrl3k1/3TTn2dc5vlnyUxHl2TVhhFU4ThGPsZvfqkcp91uLeN2419oXhfpflnoTNUcr
i9SaivbK6zmQ0HfxntLnEUPyGM03qS6lwmoLapNPLcwlhThVkhCbpCMIueuzvR2hdY3F3pWp69ma
PqOTNM0UzhRRX5dlXmrqrpwqpmNkbfF0F3W6r1vpa3tdR0vRcrVrDNpmK6p81VVPm+75aaaasYmN
szs8MMWKbcz6unLqy4oav1Tk/pmY/a7YTcKz1TtdPrKTKZ/TuIxmT1bp++xVzkaunv4Wxl7Ssrj8
10pX1SjSta9aHchVmmTJo/ZXoy56xybC06u/jtfyJpz5y4imuafpVxV5JzPqTE7MJ+SavveEId1j
vN1lk9HXF5ndMRY6Hn5VWRNc+aI+emaZnyeWmdmM4Yx7PGUiuP1WjU/pydUU6VanVmpcf93KNTuT
yzRp1aWrc58ylUhJGaMk8kYwhGH2dYdWvdS052Z+KfJrimqqrM1K0mNmE1R9OnbENi6fmI/DPc1R
to/gbnb7NldX6/Z7WOj6QP0d7zf+noLlryOjirfj9Y1o6j0Ft7TvqV3ebo3WFv69rDIapqSVPlYb
RWMyFlNGpRnnhcX08k0KkJKfxknvp3wq6bpuOielvPV1BHmys+uadlE5kYRFFWMzVXMVfLsiInCc
UY9luyf9/V5PWfVHko0LGMzJoivbP06sZ88YYU0bMapx2xjGD6311vqT6W3zyWP4fbB5qyzW1O32
doX+6WrcLNLHAat1pg6c1LE6KwFa27tC+07o2FSNS5q04xt615NLTljH5UIx+f4c+1dzoeVmdedS
0z/fNzRNGRTVtqppmcasyvHbTmTtj2/LPxl6PxCd0bPW5o6H6cq/+2W1cVZ1VOyma6PlpopmNlVE
ROPhG2I90NcOMYxjGMe2Me2MeyHb+qHSEHVbldQAAAAAAAAAFKn/ACan/wBk83+HT/tXZf8Ab5f+
n8uFJpxycyfj/wAFTHL9XiSEOXlnCMkkIx4+8cY96MsYQml/lJp2WNSaMOv4oxhD9fSEOj8ou6GH
/mNrU1TM/wD3HN/X+p+rHbCfL270aIinH+7sr3+77UGtecft6drtLaS1vuNtfq/ROlNd28t3pHN6
jw9xjbTN0KlvRvKUbaFxCStTq3FjcSXFGnVlpz1qE0KkkJpPxNF+X4/ob15p91P6f2vg4rafcbOa
JuNxsPovO5LQ9tquy0N/EdlY1LixuNYZCwr5W003YwpxmuL/ADFTF21S4jRoSVIyUpYzT92HSMXy
/E80+6n9P7XgflSSz9ypNJT6RhCeMfxRkh2wm6yyxjGM8sYfs/E+X4/oPN8Kf0/tUmpywj+GMk/W
PSXu9etTpHu9ZJYw70YdYdnXp1+ztPl+J5p91P6f2uEI0+sYdzv/AB6Qh2R7IRj1+MenSHb0/sPl
+P6P2KTVM+yn9P7Wf3g9CWHAHE9ISQjHlLrrvd3r3o9Nt9MQl7/b3esIfDp9jsz8ImPn1vbP3rb8
m2XHX4spxytG2RGy48Psj/SF4/8AZL/lldkz96r+dV+uXG9XhT/Mp/owCwAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Bm//AKfTcvHaD+oNjtN5S4pW1Ldba3WejcfPVmhL83O4+pj9T4y0kjNGWE01zQxdzCWHxjNCHT4u
e/xN6Vnaj2ynPt4xrtb2jMq2TOFOGGOz2Rjj+R0D+GzVcqx7jxbZ84U3NpXRTt8asYnD7dn6UbPq
3ca87xs5z7y4m+x1SjpTc7UWQ3d27yk1OrC1yeB1lffvHK2tnWjCFGtVwuoate3rUoRjGTrLGPSW
aEW3dk+q7Tq7t3aZ9pMVX+RTRkZlHmjzZf06Yp+pPvpqw80U/ewna1PvR0ledJ9fZ2Xdx/yNzmV5
uXXFM+WucyqavJ/OjHyzPhjHxh8Dj59SvfXj/wAad4OJdjjNP642c3a0/qvD08bqGa7tcxt/faws
Kthlsrpi+tJoyVrat35a01pcSxp/Nl6yxh1iv6p7S9PdUdVWXWmdXm5Wv2mZlVzVTPyZk5UbImPH
CZjHx8MYWdMd2Nf6Z6XvOjcqjKzdBusvNoimqPnojNxiqYnw80RP2Y4T7Fw+Gf1Xd2OFfHzW/HfR
O1u3+sNOa7y2qcvks9qbKagtMxZVtV4W3wd5TsqGNj+Tmp21vR71KE/ZCaPa8PX/AGZ0Dr3qq26r
us+4ybm3+n8lMx5apy64q27NkTETEYYYbGQ6G7x6z0R0zcdMW2RlZltn/U+fwrp89E07Nu2YnCZm
fijjwc5la04Kb51d99DaP01rnO1dG6k0XNg9U3eTssZLY6lvMfe3F1C7xXdvZq9rVxskJIR7JoRj
3o/BtfcPobTe42g/5c1PMzciwi4y82mvKw+rH04mIpmZiYwnzTj8Yhqnb/ri+7e67/mDTcnKzryc
jMy6ozMfLPnmJ80RExMT8se3bGPvel3Z+oFvfuPzMhzj03SxG1G79vXwFxjbfS1S8yOBtY4PC0cB
VtbihlY/PyWOzOMkmpXdCrGEtSWfrDpGEIvBo3bHp/Tehqe397Xn3ehx9TZX5cYqrrmuKomI8Yx/
Pth79Y7ma5qXXH+fLajKttWxo+55sJiiiKZicZnxwxSs5b/Wr365k8c85x13I2k2nweL1Hdadvcr
qzS13qaTJT3ensjQyklW1xGRrXONtIXd1R6TSwmm7sk0ekerSeh/w/8ATPQHVeX1TotzdVZmXVVh
lZkxNE0VxMVxMREbZmdnsw8Ybd1n356j656bzenNXt7anKzYpn6lETFcVUVRNM4zVOzZhOGHw2Pc
8T/r48sON23uF2w1ppXSHIHS2l8fQxGmclq6/wAngtb47E2VGWjj8ZeZ7HSXNvm7ayoywp06lxQj
WlklhCM03SDx9Y/hu6N6nv69TsM64067za5qrjLimrLmqZmZmKZ8JnHbhMR8GQ6S/Ed1j01p+Xpl
5k5F/b5URTTOZNVNcUxERFPmjHGIw2YxP2vC80vrbcoeYu3+V2hk01ovZXa3U9GnZ6rwGk4Xed1D
qnG0K8lzDF5PUuZkhNZ4mepTh36VnQoT1OkIxqQh2PZ0P+HzojofU6NduM65vNWy/wCzrriKaaf5
tOXt/wB6Z/S8PXXfvq7rnTszQ8nIt7PS8zDzU01TVVP/AK9eydu3wj9EIycf+dfKHQexG43Cbbm0
p7ibc7347N6dtdAVcBktQ6n09kNUUZJcre6A/dMf3haz3ctOE81CelPbfM6z9IRbb1N286M1TqSx
681LMzLXWbKuJnNiqnLy64p+5FVdWymYjZOO32NW6b6+6x0vpu96G0+KrrSr2iafpTT9SuiavvzT
RTtmJnGfl2e12Zr6jfKq04v6I4XaY1PT2u2l2+xGV0tm7bRtK7xOstYy3OcyWRydjqzUUa8b2jaQ
vLypSntbP8vTmpy92fvQ6wXWnano2nqvP65usqbvW7iuK6fqYVZWThh/Z04fDxqxn2xMLbvup1fP
S2T0TaZsWuj5FM01fTxpzM3H/wB5Vj+iMI2YTigHCEssISywhLLCHSEssIQhCHWMekIQ7IdsYx/X
Hqk3HZERhFMeERsiPshGmG3GZmap8ZnbM/bM+KqgAAAAAAAAAApU/wCTV/8AxT/++C/L/t8r/T+X
Suj+wzPt/wCCWOX6u/STl/Z92M8sY7Acc5u9ThNCeEZdp9OT96H/AM0ZYywj1h06dH5Q90f/ANja
1/8AkM39b9VO2X/680b/APH5X9FLLA768YMriNB7gbt707LZrmBf7eZvQukd5sHt5rHO6K01Na7a
4XCbe625KaF1bpK90vcbl6Fr4+phrHKYDHX8KtGaS4uqNWelJVm0NvK42D+ots1oncvYvDaC3S03
p3QGieWub1zqe/xmz+CtNM21rn+PmhNBa53WweHqaNr32M07rPdy1zeUo46jS/N2tjcdlGSEZacA
8bojfr6c02jtHZbd+32u1JvpNpXJa21pq/H7WZWfGWe5nGq+1dT2y0RjrXH4ewwuSwvK6nqC0uMx
cT2X5enLjKUt18qPxDsyXKPh7onjt3NIaz0Pqve/D7X60obQ6my21Om8lrXTOW1XoLbSnd4LO4mf
a/D6R0zf43WdPP2uNhGtmoUKEn5uFzTmqwhEIw8/d+eNu520W2WC2OxG1cbeS/0Rl8TJhMFU07uf
tzbWO1+HwmutH6hs7LQOmMRVw+f17Ld5Geeplc5Wr3XStLVpU5u4CRvB7s+n/iIdY9nKbXcOkfs6
bbaW+H2dvV2d+EX7+t/zrb9cuO/xZf2WjfZcfqheL/ZL/lldkz96r+dV+uXG9XhT/Mp/owCwAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAh1+3/C
HTs/vitmKp+7MR+TH/XCsYY7fA+//D9H6/v/AMFYxw2+Knt+AqAAAAAAAAAAAAAAAAAAPY7d7gar
2n1/ovdDQl/HF6z2+1NiNW6ZyEIx6W+Vw15Tu6MKkITSwqULmSSalUkjHuz06kYR7Isfq2l2etaZ
n6TqFEV2dxlVUVRMY7KowxiPfHsZDSdTu9G1PI1Wxqmi6t8yK6ZicMcJxwmfHCfbg3gNP5Dh99ef
iVi8dqypLpTd/RlvQny9DFVLOnuNs1rypYyUb/JYWStNCtmNCZ2rDvdybra3NLuyVIyVZOsPz2vM
jrP8OnWv1raivN6fzsyryTHm+jcZXmnyUZk0xPkzIpw82zCJxwmYd/2Vx0b+IXo7LyLqqjK13Ipj
Gfl+rlZ0Ux55y6asPPlzVjhjhswxwlrgcpPom84+N+QyV5gdC19/9vrarXqWOtdpberlsrCwk781
ObPaGjNDUGNupackPmfIluqUIx7Jujqzozv92+6syYy7y4/uvVJmI+lcYYTM4YRTXGzGcfbh8Yct
9X9huu+mK6s60yY1LTYpmfqW+M4RETtqpnb7PCMftYptQac1JpO+r4zVem9RaUyNtUjSuMdqfBZX
BZChPJHu1IVrPI2dtWkjCeHTshH9KY7S9s9Rjz2Gfk5uT+9TXTV+iJxn8iHLmzvbCfJqGRnZWb7q
qJp/TOyHwYXNCEey4ofCPX/vYR7Ozt7Jez+17Yyc3HGdtPwpqx/1vL54mMKaaoq+M04f6v1uMbyh
2xmr0ZoQ7JZZJ5YzTR69vwjHuwh+l8pmuJw8tWH2T/riH2jLxiNtOM++Y/1YvSae0rqvVtzLZ6U0
rqbVF3PGWEltpvT2YzlepNN+zTpUsbZXM1SeP9kHnur+ws8v611cZORREeGbVFFU/GmJnbHvl6Lb
T9Qu6/p2uRnZ9eOH9VTNcR8KsIxifd8E7tn/AKUX1BN8KlvPpPjTrfTuOuPlxhntzIW23uJp06nd
jLVj+/qtHIVacJZ+90pW880YfBHGud5+22g5dU3Wp5NefTO3Ly/6yv8A9jGPz/lSDofZ3uLruZTT
babnUZFX/aZnyUf+1hLMtx2/pps/d1rLL8p9+LPH2Ms9OrdaG2bx89xe3MZZ5Yz2d7rbUVGWS3kq
SRjCM1raTRhH4R+1BPU34s7WnLzLboywzK6p8M+4nyeX400RjjH2zH2Jz6a/CvmV10XPWd7RTh4Z
WTE1z4+FVU4Rt+ET9seLNrpPZL6c30r9ub3U9Cz202Rt5cZcW95uFrPIWuT3N1LUhQmlmo2+ZyUL
vU2Wuq803X8rj6UlGM0evyoQQBf9Sd0+7mpU22fXeX1pExjRl0+W2pnGPvxTsmdmOM7dkzCebLp7
tf2nsas/KptLO6mJwzc2qKs6dmzCqr5qfsp2ex+eVq++tcpq7VuUsak1axymqdRZSzrTde9Vtcjm
b29t6k0I9IwjPRrwj0+x+nlllVZNpl5Ve2qmiIn7cH5o32ZRnXmZm0fcqrmYeeep5AAAAAAAAAAA
HCpN+CeSEIxmmo1u7LCH7cZZe/GEs3+p0l7JftVomYzsuufuU1RE/l2x+mFfmiiujZhVTjH5Nk/o
lab6hHA7k9yQ36wm6ezGh9Pa20LlNjdicXaZy33Q2tw8s+SwG22DxOYs62O1FrLFZe0uLLI2tSlU
p1aFObvSx6dYdIx/MjuR0b1ddde6tc2+l6jn5GZeV1U5mXkzVRV5sJxpn2x7Ptxj2P017c9Y9G2/
QmlZFxqlhkZ1Fnl0zl5mdFNdPlxjCqPZM+P2YT7UG/8A0nuefSEP5P4OPSEYd6O8myEYxhGHTpGM
24XejDp8IR+DSf8AI3Wn+Dat/wBPU3X/ADt0R/jOl/8AUUqf+k7zy69f5P4SEfwx6w3n2S69Zf2Y
9f5idessPh90D/I3Wn+Dat/09R/nboj/ABnS9/SrH6T3PKMYxhs7gZevTrCXeTZCEIwhDpCHT+Yf
w7vZ/wDHtP8AI3Wn+Dat/wBPUf516I/xnS9/SpD6TvPKEY/9HsHHvdk8I7z7J9KkOyMIVOm4sO9C
EYdT/I3Wn+Dat/08n+duiP8AGdL39KsPpOc9Jox/6P4WeMYxnj/1l2Smm6xjCE00I/zDjCEesesY
n+RutP8ABtW/6eo/zt0RH/8Ac6Xv6WT/AGU2G3Q43cNtK7b7wYfEaY1pkuRGu9U22n7PV2kdV338
O1NCaexsmWrT6RzectbW3mv7SanCFaenPNHtlhGHbDrr8K+g61o2Zq06xaXNpTmVZWEZ1E5c1RRE
1RNOPjEThFU+/Y5H/FLr+i6tl6VTot3bXc0U5uM5NcZkUzXVFOFWHhM07Yj8rl2dJYyx70Jpe9Cb
p0hNDrGEsZfvh3YOsKZmY80/ysZ/PLk6r73l/diI/NEQouWgAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi7U7ubnb
Ga6w+5e0GudRbea5wVSE9hqHTV/Usrmal35Z6lhkKH47PK4u47vSpbXNOrRnhGPWXr2sRrWhaT1D
Y16brGRRn2WZGFVNUROMR4Rj4/mwn3Mto2uar09e06jo+fXkXlPhVTMxLZM4xf1J+rMHZ2GneWuz
MurfkSUrevuXtDcW2Ky1eSSMks13ldD5erLZ1rmanLGaf8neU5ZpvhJD4OUOqvwpZVxnzndG3cZe
NP8AZ584zPwiuIiYx8Pbh4up+k/xR3GTTTb9YWv1Maoj6mTHlwjwxmnGYnDx24YssWlvq+fSm3/t
aFPV+42icVWq05I1sPvltvVsq9CeaEJo0Jq+UweZxE88k8O2MK/d6w+PXoiDUOyPevpXM8un21xV
bxO2q1uJxiPZMRExM4+HvhL9n3i7O9RzE6hc20VVfybm3jb8JqmJiPfi97S1h9GbW0s1/wDnuBGW
lrTS1pqtzabR21eaeHbCapb3lrbV5Zu37ZGMzbDvrpvyTl9QURGzGmrOmfs+WrH9ODJ06n2Mvvn8
+g5ke6aMmfy4TGH6H3KO4H0f9EU5b22zXAvCyUevcrW9DZuNeXpDvRhShStatxPNCHb+GEYvJOn9
7tSn6OZl9RZ0Rtwrqz4iMdmMY1fnwfeNW7J2H9Zk5mg5Uz7Yy8iMcPZspj7XwM/9V36WGz1rPDDb
87U0Y28JpY47bLSd7k6/SWEYfLoyac09LZQjN06Qh82HWHw7Hqt+0Xd/X8+Mu6sb2r3Tc5tURGP7
vmqxw97y3HdztJoVONpe2lM1bf8AlsqJxmNm3y0xt9yEW7X9SVxM0zJcW20m1G7+7eRklqflLvI2
uJ2/wk1WEs0IVI3WWur/ACX5aM3T9m2lmnh8G/aN+FHrLNzqZ1u5s9PidsxTM5uZ5ffh4bft9jSN
Z/E/0XbZVVGkZd1fZuzbMRlUY+6cNuyPh7WIrf7+oS5u7rW97htq7DQfHbA3MJpJLzS9jU1breFO
aHd/DqPUcscfY1IwjGM01Cx78Jv2ZodE39Mfhl6D0aqM7XKs/VLuiYmKqqvp5dXt+bKiMcI8MJrn
HD4oU6j/ABJ9aapl122i0ZOn2lWyIojzZlMfDMmfGds4+SPHD2bcLe4e5m4+7upLnWO6uvNXbjaq
vKk1SvntZZ7IZ6/6zR692hNfV6tKzpS9ekJKMlOWEOzp0T1pWj6ToVt/B6LbZNra4RHlyqfLTOHv
QPqmsarrefNzq1xnXGdMzOOZVNW2fHx2PEMkxoAAAAAAAAAAACsI92PWHZHrLHr90ZfhGH3Rh1+M
DH5Zp/kzMT+WPD8ys7cMfZEx+Srx/O6vk0ow6RpyRh2/GWEe2MesY9sOyPWCtM1UR5aZmKduyJnD
btn9Kmz3R4YeEew+TS/05P8Ahgr9TM/eq/3p/ars91P5o/Yp8ml/pyf8MD6mZ+9X/vT+02e6n80f
sPk0v9OT/hgfUzP3q/8Aen9ps91P5o/YfJpf6cn/AAwPqZn71f8AvT+02e6n80fsPkUftpSR/XLC
MP7owPqZn71X55/abPdH5o/Y5S06cnXuSSy9evWMIdI9Izd6MOvxhCMfs+7s+C3GZq88zM1eWYxm
cdk+MGOzy+yKon8seEuf/t0+yH29IQ+EIfogRsiKY8IjCPsUnbM1T4zOMgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAKTSyzdO9CE3d7ZesOvdj98v3RImY8JmPs2KTET96In7drqjbW8Y9Y0KUY9evX5cvWMfvj2ds
V0V5keFVX55Vwj3QQtreEYxhQo9Y/b8uT/Yr9TM/eq/PKmEO2EsssYTSyyyxh8IwhCEYfqjCHVbN
VU+MzP2kU0xGEREQqorERGyPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAB//9mgRh3wjl4BAHrruhb8ZULEwLGTC/0XcCv//9j/4AAQSkZJRgABAgEASABIAAD/
4QX4RXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEo
AAMAAAABAAIAAAExAAIAAAAUAAAAcgEyAAIAAAAUAAAAhodpAAQAAAABAAAAnAAAAMgAAABIAAAA
AQAAAEgAAAABQWRvYmUgUGhvdG9zaG9wIDcuMAAyMDA2OjAyOjIzIDE0OjM5OjQwAAAAAAOgAQAD
AAAAAf//AACgAgAEAAAAAQAABACgAwAEAAAAAQAAAwAAAAAAAAAABgEDAAMAAAABAAYAAAEaAAUA
AAABAAABFgEbAAUAAAABAAABHgEoAAMAAAABAAIAAAIBAAQAAAABAAABJgICAAQAAAABAAAEygAA
AAAAAABIAAAAAQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5B
ZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwM
DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAGAAgAMBIgACEQEDEQH/3QAEAAj/
xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYH
CAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFD
ByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2
hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGR
FKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSk
hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOeCSQSW+4Sk
kkklKSSSSUpJJJJSkkkklKSSSSUpJJa3TOl020+vba2uw1faWbmtsArFl1B20WuYzIu/VbvY/wDR
s/QpspCIsroxMjQckGQS0FwHJAkBIEESDIXWfsrKa5ljutXtqp2m4te5rCPWup/R+hZtwq/QprY/
cy1mPk31f4BZHX9nqY+8tdmEW+u9rmuc6r1P8nWZT6vY/Nsx/fc/+d9H7N6/6VNjlEjQXyxGMTK3
/9DngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKVvH6g1lLMbLxas/GrcXVMtL2PrLtbG4+Rjv
rsrrtd77KXepV6n6RVEkCAd0xkYmw6B6l0+t2/D6PiUvggPudblQT+e2vJs9De3+XTYqD3Oe99jo
L7HF7iAAJcdzvaza1v8AZTJJCIG34ni/6SZTMt/w0f/R54JJBJb7hKSSSSUpJJJJSkkkklKSSSSU
pJJJJSkkkklKSSSSU//S54JJBJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//T54JJ
BJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkklJrdwc7c1rWwCXTyZj6Id+6kpikj/YryCQWmBJEm
QBruczbvaz/hHN2IMEEgiCNCPAhCwqi//9TngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKRaM
3FwT9oyjFTXtH0S4ztthzWbX7nV/znv9n/CVoSjbW21rWlz2Fj22sfU4NcHMDmt1c1/+kTMnFwS4
QDKtLXY+HjHFYj1pv5H1u6N6JZRdWLj9GwYYx9rSd3Nf2i2z6X6Nv6Or/CfpVUsgW2RxudHwlV3Y
xfW6p+XmOreIe03Ahw/dd+i930kcmXF3EmYUeAZRxe4Ijtwsuc4jw+2ZHvxP/9n/7QqyUGhvdG9z
aG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAAAAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAEA
SAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0EGQAA
AAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoA
AQAAAAAAAAABOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAAB
ADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////
////////////////////A+gAAAAA/////////////////////////////wPoAAAAAP//////////
//////////////////8D6AAAAAD/////////////////////////////A+gAADhCSU0EAAAAAAAA
AgABOEJJTQQCAAAAAAAEAAAAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAA
AAQAAAAAOEJJTQQaAAAAAANJAAAABgAAAAAAAAAAAAADAAAABAAAAAAKAFUAbgB0AGkAdABsAGUA
ZAAtADIAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAABAAAAAMAAAAAAAAAAAAAAAAA
AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpj
AAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRv
bWxvbmcAAAMAAAAAAFJnaHRsb25nAAAEAAAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAF
c2xpY2UAAAASAAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2lu
ZW51bQAAAAxFU2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xp
Y2VUeXBlAAAAAEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9u
ZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAADAAAAAABSZ2h0bG9uZwAABAAAAAAD
dXJsVEVYVAAAAAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRU
YWdURVhUAAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAA
AAAACWhvcnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFs
aWduZW51bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0A
AAARRVNsaWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0
T3V0c2V0bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25n
AAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAI4QklNBAwAAAAABOYAAAABAAAAgAAA
AGAAAAGAAACQAAAABMoAGAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5B
ZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwM
DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAGAAgAMBIgACEQEDEQH/3QAEAAj/
xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYH
CAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFD
ByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2
hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGR
FKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSk
hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOeCSQSW+4Sk
kkklKSSSSUpJJJJSkkkklKSSSSUpJJa3TOl020+vba2uw1faWbmtsArFl1B20WuYzIu/VbvY/wDR
s/QpspCIsroxMjQckGQS0FwHJAkBIEESDIXWfsrKa5ljutXtqp2m4te5rCPWup/R+hZtwq/QprY/
cy1mPk31f4BZHX9nqY+8tdmEW+u9rmuc6r1P8nWZT6vY/Nsx/fc/+d9H7N6/6VNjlEjQXyxGMTK3
/9DngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKVvH6g1lLMbLxas/GrcXVMtL2PrLtbG4+Rjv
rsrrtd77KXepV6n6RVEkCAd0xkYmw6B6l0+t2/D6PiUvggPudblQT+e2vJs9De3+XTYqD3Oe99jo
L7HF7iAAJcdzvaza1v8AZTJJCIG34ni/6SZTMt/w0f/R54JJBJb7hKSSSSUpJJJJSkkkklKSSSSU
pJJJJSkkkklKSSSSU//S54JJBJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//T54JJ
BJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkklJrdwc7c1rWwCXTyZj6Id+6kpikj/YryCQWmBJEm
QBruczbvaz/hHN2IMEEgiCNCPAhCwqi//9TngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKRaM
3FwT9oyjFTXtH0S4ztthzWbX7nV/znv9n/CVoSjbW21rWlz2Fj22sfU4NcHMDmt1c1/+kTMnFwS4
QDKtLXY+HjHFYj1pv5H1u6N6JZRdWLj9GwYYx9rSd3Nf2i2z6X6Nv6Or/CfpVUsgW2RxudHwlV3Y
xfW6p+XmOreIe03Ahw/dd+i930kcmXF3EmYUeAZRxe4Ijtwsuc4jw+2ZHvxP/9k4QklNBCEAAAAA
AFUAAAABAQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAg
AFAAaABvAHQAbwBzAGgAbwBwACAANwAuADAAAAABADhCSU0EBgAAAAAABwAIAAAAAQEA/+ESSGh0
dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0w
TXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSIj8+Cjx4
OnhhcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eGFwdGs9J1hNUCB0b29sa2l0IDIu
OC4yLTMzLCBmcmFtZXdvcmsgMS41Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3Lncz
Lm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2Jl
LmNvbS9pWC8xLjAvJz4KCiA8cmRmOkRlc2NyaXB0aW9uIGFib3V0PSd1dWlkOjI0NDU3MjljLWE0
YmQtMTFkYS05MTk1LWJiYWQ2N2IwMjQxMycKICB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2Jl
LmNvbS94YXAvMS4wL21tLyc+CiAgPHhhcE1NOkRvY3VtZW50SUQ+YWRvYmU6ZG9jaWQ6cGhvdG9z
aG9wOjg2OWI5MTA5LWE0YmMtMTFkYS05MTk1LWJiYWQ2N2IwMjQxMzwveGFwTU06RG9jdW1lbnRJ
RD4KIDwvcmRmOkRlc2NyaXB0aW9uPgoKPC9yZGY6UkRGPgo8L3g6eGFwbWV0YT4KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cn
Pz7/7gAOQWRvYmUAZEAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAgICAgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAMABAADAREAAhEBAxEB
/90ABACA/8QBogAAAAYCAwEAAAAAAAAAAAAABwgGBQQJAwoCAQALAQAABgMBAQEAAAAAAAAAAAAG
BQQDBwIIAQkACgsQAAIBAwQBAwMCAwMDAgYJdQECAwQRBRIGIQcTIgAIMRRBMiMVCVFCFmEkMxdS
cYEYYpElQ6Gx8CY0cgoZwdE1J+FTNoLxkqJEVHNFRjdHYyhVVlcassLS4vJkg3SThGWjs8PT4yk4
ZvN1Kjk6SElKWFlaZ2hpanZ3eHl6hYaHiImKlJWWl5iZmqSlpqeoqaq0tba3uLm6xMXGx8jJytTV
1tfY2drk5ebn6Onq9PX29/j5+hEAAgEDAgQEAwUEBAQGBgVtAQIDEQQhEgUxBgAiE0FRBzJhFHEI
QoEjkRVSoWIWMwmxJMHRQ3LwF+GCNCWSUxhjRPGisiY1GVQ2RWQnCnODk0Z0wtLi8lVldVY3hIWj
s8PT4/MpGpSktMTU5PSVpbXF1eX1KEdXZjh2hpamtsbW5vZnd4eXp7fH1+f3SFhoeIiYqLjI2Oj4
OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6/9oADAMBAAIRAxEAPwCmhvr/AMgr/wBCj32YPXG8
cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Qpob6/wDIK/8AQo99mD1xvHD8z1x96631
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691//0aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvdf/9Kmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//
1KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Wmhvr/AMgr
/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Wpob6/wDIK/8AQo99mD1x
vHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3XRIAuSAP6k2H+3Pv3XuuEcscziKFhPKfpFBeaQ
/wCtHEHc/wC297IIFWwPnjrwzSgrXpf4jqvtTcKq+A6t7Lzsbi6yYfr/AHdk42B+hWSiw80ZH+x9
lk+87Naki53i0jP9KaNf8LDo0g2TebpQ1ttNzIv9GJ2/wKelWfjf8jFBZvj53kAoJJPUm/wAALkk
/wB3+AB7Sf1p5X/6aXb/APsph/6D6U/1X5n/AOma3D/smm/6A6RWb667G2yrPuXrvsDbqILvJntk
7ow8ai17tJkcVToBY/19rrfdNruyBabpbSk/wSxt/wAdY9I7naN1sxqu9suIh/Sjdf8ACB0iRPCW
KeWPWCVMZYB1YfUFCQwI/pb2YaTStMdF3WX3rr3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvdf/9emhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvddqGeWKCNXlnqJEhp4IkaWeomkYLH
DBDGGlmlkY2VVBYn6D3okAMxNFAqT5AepPl1sAsQqgljwA4nqy745fyhvnz8mY6DK7W6TyOwNnV6
xTRb57jqf9HuFeklYBaugxWRhl3dmISpurUuOkRgP1D3FPNHvZ7ccqGSG739Lm+XHhWw8Zq+hZSI
1P8ApnB+XUq8r+ynuLzUI5rTYmtrJhUS3J8FaeoVv1GHzVCPn1c51t/wnF6i6/xdPuj5gfLc0ePg
YSZLG7Cj2/13tuNUUPLC++ewJMlVSxi9i60NK1uePxBO6/ej3vcpmtOSeS9Up+Fptcz/AG+FDpH/
ABtup02v7sGybZEt5zrznpiGSsWiFB8vFm1VH+0U9C1Bsz/hON8UNdPmc70/2buTFSWklzGc3v8A
ITMzVEJ5DUOBTcG2FlLgXAp4kB/oL+yVr/70XOVGgt760tXHBUis1APzfRJ/xono7Wx+7FyeGE89
ld3CnJZpbxiR8k1xg/7UDp8H88L+U705EtL0x0BuqdqQaKZ9gdBbE2FRMEsFZKvKZDAV4LWHqaC5
+p9p/wDgfveXfSX33mSEA8fGvJpj+xVcfz6e/wBf32c2JQux8uSmnDwbSGIftLIf2r0lcj/wpx6N
p28eE+LHb1dApsjZDeGyMM2nm37VMMuq/jjV+f8ADlZF90zmFhW45wslb+jHK3+HT0kk+9dy8ppB
ylesv9KSJf5DX0z0v/CnnrB3tW/ETsinj1L66XtDalY+kk6z45MBRC6j6DVz/Ue33+6Vu4H6fOtq
T84JB/z+emV+9hs9f1OTrkD5Tof8MY6Ffan/AApT+H+cdaXfXS3fe0qeWyTSwYrZW8KRA3BLx025
6ColiF+bRFrfRT7Jrz7qvO9uC+3b9t07DgC0sZ/nGR/Po3s/vTck3LBNw2LcYVPEhYpB/KRT/LoZ
8X83v5H3zFRMNvmT4/8A8Zysgh/h3eHUtN1/nDLMbaU3XndvUNDHIzH6xZS+rn/H2QzcgfeA5HJn
28bl4CCuq1uDMlB/wtHJ/bH0exc++wXO/wChuB23xmNKXVuIWqf+GugX9knSP7h/kC/ADvrBybs+
P24tx9NVWVRqnDZvrTdsHYvWlUXBZX/gGfrMulRSMxFhQ5OkAH09rtj+8j7k8uXAsuZbWK+RMMk8
ZhnH+3QLQ/6eNukW9/dy9uOY7c3nLlzLYu+VaCQTQH/auWqP9JIo612/mX/Jj+Y/xApcru9dvU3e
PUWNSWqqexurKatrqrCUEdmNTvDZEyvuLBRRI15aiFa2hj51Tj3k7yL77cjc7PDZG5O3705oILgg
Bz6Ryjsevkp0uf4esZeefYvnfkpJb0Ww3DZkFTNACSg9ZIj3p8yNSDzbqpVWV1DKwZTyGUgg/wCs
R7milOPUMdd+/de697917r3v3Xuve/de697917r/0KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3WWGGa
pmhpqaGapqaiWOCnpqeKSeoqJ5nEcMEEESvLNNLIwVEUFmYgAEn3VmVFZ3YBAKkk0AA4kk8APXqy
qzsqIpLk0AGSSeAA8yerr/i1/JM7m7G2tB3P8t97YL4Y/H+CniydXm+yKjGY7sHK4tomqEkpNvZ2
sx+O2lFVQr+3NmJY6ixDJSSjgwHzf7+7Ftd42w8lWEm+8yE6QsAZoVbhl0DNJQ8RECvkXHU9coew
u+bnaLvvOd/HsfLYAYtOVWZlpXCOVEdfWQg+YRuju4z5y/ydv5cEL4v4c9F5H5UdxY2JqWXuPcMU
Jgmr41Umqg7K3jipqmkh+5Xldu4aKmdRZZCLH2AJfb33w90mE3PHMK7Psbmv0yVrT0METAE0/wB/
ylh5jy6H0XuB7Je1ymHknl9t33xKj6l+GqnETSKSM/75iCnyPREu/wD+fV8/+6HraHZ+7ds/HzbN
SSsWM6pwySbhSHkKJt8bnGWzS1BX9UlGlECeQq8WkTlv7uftvsIjkvrOXc7sfiuG7K/KKPStPk2v
7eo85k+8V7jb6ZI7G8i220JwsCd9PnK+p6/NdPyA6qS392Z2T2tlps92j2HvnsfNVEjSzZPfW7M7
umraRzqYq+arqwRAn+ygVR+B7mnbdp2rZoVt9o2y3tYAKBYo0jH/ABkDqGdy3fdt4mNxu253F1OT
XVLI8hz82J6QyqqDSiqoH4UBR/thYezAkniei7rl7917r3v3Xuve/de697917rplVgVYBgfqGAIP
+uDx78CRw690Yr49fLT5IfFTcMG4+ge3949eTRzxzVmCoMnLW7Mzaxurmnz+y8kavbWXgk02Plpv
IB+l1Nj7C/M3JfK3ONq1rzJskFypFA5WkqfNJVpIp+xqeoPQo5Z505o5PuVuuXd6ntjWpUNWN+GH
jaqMMean5UPW3x/LY/nm9e/KTKYPpH5LY7A9Rd55U0uK21uOjneDrHtLJSKIFx9G2Rmlm2huzISW
8ePqZZaWskYpTzaykHvCb3V+73ufKENxzBypLJe8vJVpEIrPbrxqdIpJGPN1AZRllpVus1faz7wO
283S2+w80xR2W/vRUcGkE7HFBqJMchPBGJVjhWqQvQWfzb/5Ku1ezMBuv5LfELalJtjtvEQVm4N/
9P7dooaPb3aVFCr1OTy20sVTiKmwnYMEatKaeBFp8xYroSqIeU39lvfq82m5s+VOdrxpdlchIbly
S9uThVkY5eE8NROqLjUphSj3n9iLPdra75q5Ks1i3lAXmtkFEnAyzRqMLMOOkDTJwoHy2mmyujPH
IjxSRu0ckUqNHLFIjFJI5Y3CvHJG4IZWAKkWPPvOkEEAggg9YNEEEgihHXH3vrXXvfuvde9+6917
37r3X//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Q/8Axw+L3eHy235W9ZdA7OTe+9cftuv3dWYiTOYXb6xb
fxtbjcdW1332draCiYxVmXp08YcyN5LgEA2DXNPN3L/Je3R7tzJfG3sGlEYbQ71dgzAUQE8FY1pT
HQk5W5S3/nPcZNp5csvHv1iMhXUqdilVJq5A4sopWuehw7j+GfzI/l75jqfuPuXrXH7BqI9/47I9
e11VuPau7qOs3dsyal3TTQ1uOwGXrZDSwmkR3WXQkqgqDf2H9j565G9zIN52PYt1a5U2zLMAkkZE
coMZIZ1GTUgUqRx6EG+cjc7+2s+zb5vm1rbsLlWhJeOQGSIiQAqjHAoCa0B4dAn8h/lZ8iPlduiT
dvyA7Y3X2NXfcTT47FZKt+02lt5ZpHk+121s/HLS7cwdNGXIXwU6yEfqdjc+z/lnk3ljk60Fly3s
0NrHQBmUVkennJK1Xc/a1PQDoh5m5x5m5xuzecx7xNcyVJVWNI0rXCRrREGadqivnU9F89iboM9e
9+69176e/de6xiWIkASRkngAOpJP9AL8+96T6HrVR6jrJ711vr3v3Xuve/de697917qxT4K/yy++
P5guK7Iy/TW5+s9vU3V+S25i8+nYGVz+Omqqjc9JlKygfFrhcBmlliiixEglMhjIZlte5tGHuH7s
cu+2k21Q77aXcrXiOyeCqMAIyoOrW6ZOoUpXz6k7299qOYfcmHdJtju7SJLR0V/GZ1JMgYjToR8U
U1rTy6Dz5s/BXt74H9m7S6o7ZzOytzbm3ps+l3rh5Ova3MZSh/h1Znsrt2nopzl8RhqoZOTIYiS0
axspRkIa5sDPkH3D2T3F2m93nZoLiK0gnMTeMFU6giuSNLMNNGGa8a46LOffb3evbvdrLZ95nt5r
ueASr4JZhpLsgB1Kp1alOKcCOuHcfwa7n6K6y2721ufL7HrcblIochPjNq7knrdw7cWKtxlDNUzN
9pS0ta2DzWWpKWskoZpvtKqdOWW7r7Y/cLYeYt2utltILhZUJAaRAEfDEDiSNaqzKHA1KD5461vf
t/vvL202u9XU9u0TipWN6umVBJwAdLMqsUJ0sR5Z63Af5Hnz5zXy9+PWT647RzL5fu/4/nEYLOZq
tmD5PfGxMlHPHs7eFcWOupy9P9hLjsjNYmWenjnc66g+8I/vA+28HJHM0O6bRBo5f3LU6KB2xTLT
xYh6Kah0HkGKjC9Zs+wPuNPzty1Nte7z69/23SjsT3SxNXw5D5lhQo58yoY5brXy/nzfEDE/G35c
xdlbIxUOK66+SeMyG+4MfRUwp8dhuxcbWRUvYOOpUQCGKHKVFXS5ZUUALJXyqoCqPeS/3dOd5uau
SjtW4TF902p1hJJqzQMCYWPnVQGjr6IDxPWNf3ieSYeVudBuu3whNs3VGlCgUVZlIEyjyGolZKer
kDA6o995A9QB1737r3Xvfuvde9+691//0qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdW9/y2f5a1H8l8Tur5N/JTOyd
V/CvqCmymW3hu+tq2wtX2HVbfjafI7d21kXQtS4ShdPFkshEHl8rCkpQ1S7NDCXup7qvypNZ8p8q
24vOfb0qsUYGsQh8K7r5ueKIaCne9FA1TX7We1kfNUN5zXzTcGz5EsgzSyE6DMUyyI3ko4O4zXsS
rE6Q8/lWfNvq34F/Jrc3dPZ+3t57j2nlusN07Dx+P2NS4irzEdfmtybXy1BUTQ5/MYSm+xSiwMiu
fMZQ7r6SL2M/eHkDd/cblO02HabqCK8S7jmZpSwWipIpFUVzWrimKUrnos9n+fNo9u+bLvfd1tZ5
bN7SSFVhClqs8bAkOyilENc14Y6NR/N4/mq9D/zC+u+nNndRbN7P2xkuud8Z/dGYn39j9sUVJVUG
W2+uIghx7YHc2emkqUqBqYSJGoT6Enj2D/ZP2e5i9s9z32+3q+tJorq3SNRC0hIKvqOrXGgpT0J6
GHvX7vcv+5W2bHY7NYXcMtrcPIxmVACGTSAuiRzWvGoGOqG3mhjOl5Yka19LyKpt/WxINveRYBPA
HrHfrj9zTf8AKxB/1Nj/AOjvftLfwnr3XJJYpDaOWNyPqEdWP+8E+/EEcR16o6EDqujpMj2j1njs
hTQVtBkOw9kUNdRVUazU1ZRVm58VT1dJUwuCktPUwSMjqeGViD7Ld4keLaN2licrItrKQRggiNiC
D5EHI6MdojSXd9qilQNG1zECDkEGRQQR6EYPW+988fhH8Odk/DD5Sbt2r8Yuittbk230b2LmMFuD
D9a7VxmVwuUoduVs9FksdkKXHQ1FFWUc6h45EZWVgDf3zj9uuf8Anm/575Qsrzm3cZbWXcIFdGnk
ZWUyAFWUsQQRgg9dFvcTkHkiw5F5uvbPlPborqLb5mR1gjVlYISGUhQQQcgjr58EUscqjRKkhCqW
0OrEXH50k2v76XEEcR1zY6yMyqCzMFUfUsQAP9cnge9ceHXusP3VMbf5RDzwD5EsT/QG9j9PdtLf
wnr1eI8+s/191691t2f8Jhv+PJ+Yf/h3dQf+6PevvCn723+53I//ADQuf+PxdZpfdN/3A53/AOa9
t/xyXooP/ClOSSL5kdIywyPDNF8dcVLDLExSWKWPsjfLxyxupDJJG6gqRyCL+xt91QA8jb+GFVO5
tUf82IugV96cleedgZTRhta0P/N+bqojtr5rd190dc43rPeT7WGIo0poqzJ4vD1NPmMlDBJjKmop
ofusjWYvbNFncphaOvy1Ph6aghymRpY6idWdbGa9l5B2DYd0l3ax8bx2JIVmBVSdQBNFDSFFZkjM
rOY0YqpAPULbzz5vu+7XFtN94PgqACyqQzAaSRlisYdlV5BEqCR1DMCerAP+E/PYeS2b/MT2ztmm
qJI8X2p1l2Ns/M06sfFUDFYqLe2LeRPoz0+Q2yoQ/VRI39T7jb7yu2RX3thd3bqDNZ3cEin01N4T
ftEn8upI+7buctj7m2lojkQ3lpPGw8jpUSr+wx/z6uk/4Up7Losr8Qund9vGhyWy++8fiKaYgeRK
DeWzd0JXxqx58clTgaUso+pUH8e4G+6pfyQ87b5twP6U+2sx+2KWPT/J26nb709gk3JWybiR+rBu
KqD8pYpK/wA0XrSk9579YG9e9+691737r3Xvfuvdf//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdHf/AJevwy3J86fk1s/p
fGyVuM2fADuztfdNHHqfbHXWIqadcvNTyMrRJmc3PPFj8eGBH3VSrkFI39x/7mc92nt5ynfb9KFe
+P6dvGf9EnYHSD/RQAu/9FSOJHQ/9tORbr3B5rsdiiLJYj9S4kH+hwqRqp5anJCJX8TA8AerYP56
nyt23taTYv8ALT+O0FHtHpXobC7bk7Iw+3SKegyG5qehhrNp7GneBz95RbUx08eRr9ZZqrL1avNq
mpyfcNfd55Nurwbj7rczs0+/bjI/gM+SsZJEkorwMjAolPhjUhe1upj+8Hzja2Z2/wBq+WVWHYdu
jTx1TALgAxxGnERqQ71+KRgW7lr0DP8Awnw642D2X80d9YnsTZe09+YWg6A3VkKfCbz23ht0YhMg
d47Gp469cdnKKupEraeCSRElVA6rI4Bsx9nv3l903LaeQ9um2y/mt523KNS8TtG2nwpjTUhBoTSo
rTA6Ivu17Xt26897hDudjDcQLtshCSosi18WIV0uCKgVoaVyej8/8KN+neousumPjTXdbdV9cde1
uU7U3dSZOs2PsfbO06rI0kOz0mhpa+owOMoJaynim9apIWVW5AB9xx91zfN63bfea4913i6uY0s4
yollkkCky0JAdiAaYqOpG+9Bsey7TsXKsm17Pa20j3cgYxRRxlgI6gEooqK5oeh3/wCE/vRvSXY3
wXzW4Owuneq9+Z6PvvsHHJm959fbT3Rl0x9Pg9mSU9CuSzeJrqxaOneZ2SIOEUuxAuT7Dv3lOYd/
2v3Dgtts3y8t7Y7bC2iKaSNdReWp0owFTQVNKmg6EP3buX9h3T2+nudz2SzuLgbjMuuWGORqBYqD
U6k0FTQVpnqw/tPd/wDKN6l3hl+te3qT4PbH3tgP4fLmtobt2T1Tjc1jP4lj6bK416zH1OBEsP3e
NrYp4yR6o5FI4PuMdnsverebGDddkfmC4sJNWmSOW4ZW0sVajB80YEH5jqTd4vfZfZr2bat7TYLe
/j0lo5IrdWXUoZagpiqkEfI9TM98Gf5aHzP6iFbtbp7oHc2x9yUtbT4Dsro3EbT25k8ZWRs9PLWY
HduxqakaDK4ypHqhn8qB10zRMpKmlv7he6/Im9+Heb5uUW4REF4LtpHVhxo8cpNVYeYoaZUg56vc
e3/tVz1soks9k22Xb5QQk9osaMp4VSSICjKfI1FcMpGOtHnub425r4i/PV/j1msi2aPXveOwKbCZ
+SFaeTcG08tuLb2b2pm56eMmOnq67BZCE1EaEpHUiRVNgPfQLYuaoOdfbkczQReH9Tt8xdK10SKj
pIgPmA6nSTkrQnrALfeVp+S/cU8tTy+J9NuEIR6U1xs6PGxHkShGoDAao6+jz2Rk9g4XYm8Mv2pP
tqm62xu3spWb5qN4xUU+1IdsU9I8mYk3FDko5qCXELRqxnWZWjKX1C3vlttUO5T7jZQ7Osp3V5VE
QiqJDIT26CtG1V4UzXrqFuk23W+3Xs27tENrWJjKZaGMRgd2sNUaaca4px606v55W/PhJ2dtX40Y
j4XV3x/3HuYb33rTbox3QeH2jTZiojyuL27R7ZpcvFtPHUc9WlZkzJHSJLqvMWCC5PvOP7ve3c/b
Tec2T8+R7lFafTxGNrxpCoKs5kK+IxAotCxHlx6wh+8BuHIW7WfKsHIsm2y3f1EokW0WMMdSoEDe
GoJq1QoPnw6tO/l3/wAk748fHHrbBdqfK3ae1+1e9KvDx7n3HS78FHkusuo4PtVr5cHj8JkD/Acn
X4OnVv4jlsgsyGZW8AiiQPJD/ud7+czc07rcbPydeTWfLyv4aGGqz3JrQOzjvUOfgjShoRqqxoJe
9svYblrlfarfd+cLOK85gZPEcS0aC3FK6Ap7GKD45HqKg6aAVJ4Nl/IH+Vr3tu2T4/bK3f8AE3sP
c1UanFQddUmB2RW0uXenWRJ8fgoanDR4bOzRojaY6GSZ7KSosL+4/v8Alv3e5dshzLf2W82toKMZ
i8oK14F6NrQfNwPn1IFjzF7ScwXf9XLG72e5uWqohCREPTiqVXQ5HohPVAv86f8AlCde9EbJrPlt
8V9vvtfYuMyVFTdxdU0L1FTg9sU+Yqo6Gg33sxJmmmxeGGUnip8jj9ZggM6TQBIxKi5I+w3vbufM
V/HyXzhc+NuLoTbXBoHkKirQy0oGbSCyPSpoVapIPWOHvv7K7by9YPznyhbeDt6MBc24qUjDGgmi
rUquohXStBUMtACOh2/4TDf8eT8w/wDw7uoP/dHvX2Hvvbf7ncj/APNC5/4/F0IPum/7gc7/APNe
2/45L0T/AP4Ur/8AZYvSv/iuON/9+Nvr2Nvup/8AKj79/wBLRv8AqxD0CfvUf8rxsP8A0q1/6vzd
a6fvKDrGPq9//hPB1Nk98fPObsSOmdsF0r1VvDPZGtKEwR5feUcWysDQF7aRU1cGSrp0X6lKRz+P
eO33nN5i2/25XbC/+MX95Eijz0xVlc/YCqA/Nh1kP92bZptw9xG3MJ/i1hZyOx8tUv6SD7SGcj5K
erb/APhSvvyixPxS6T66MyDJb37zi3BDBqHkfG7G2fn1rZdN7+JK3c9KCf8AVMP8fcK/dT26SbnH
f900/pW+3lCf6UsqU/OkbdTP96jcUh5O2HbNQ8W43APT+jFE9f5yL1pY+88+sEeve/de697917r3
v3Xuv//Upob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvdbp/8j3qnbnxP/l29r/MzeOPiizXY+L3v2ZWVtQkcdSnVvUOPzkG3cXB
M48sUOVymOyVWFBAlNTEbGy+8DPvA7xdc5e5+zci2MpMFq8UAA4fUXJQuxHAlVZF+Wlvn1nd7A7N
a8m+2W8c830QE90ks5J4/T2wcIoPEamV2+epfl1pxdi7/wBx9rb/AN7dnbvrJa/dPYW689vPcFXM
7SSS5XceTqcrVjU5LeOGSp8aD+yigDge85Nr2212bbdv2iyQLZ20KRIB5KihR+2lT8+sIN03K63j
ctw3a9ctd3MzyuT/ABOxY/4aD5dXuf8ACbn/ALLf7H/8V13R/wC9vsT3jv8Aen/6d/tX/S0j/wCr
U3WQv3XP+V/3T/pWP/1di6sK/wCFN3/Mjvi3/wCJc3n/AO8UnuM/umf8rBzf/wA8UX/V3qS/vX/8
kDlD/ntl/wCrXRg/+E5X/ZAGd/8AFh+x/wD3Q7H9hn70X/Tybf8A6VkH/H5uhJ92D/p3Fx/0s5/+
ORda5n88pVP8z35GEqpP2vUvJAJ/5k/sb3lF93wn/Wk5Xz+K5/7SZesYfvAAf67PM+Pw23/aNF1s
H/8ACbKWV/g32ZC0jtFT/JreaU8TMTHAknXnV08iRITpjV5pWcgWuzE/U+8aPvUqB7g7SwA1HaYq
/P8AWuBn8sdZK/daZjyBuoJNBustPl+jb8OqXv5xn/b5CX/tbfGD/wB120/c7+xv/TjF/wBJf/8A
HpOoJ98P+n4H/T2H/HY+tuj+YuAfgj8vQeR/svvZ31/8Nev94U+1/wD08Tkr/pZwf9XB1mj7nf8A
TvOdP+lbP/1bPWiz/KM69xHZX8xb4sbezVJBWYzH75qd5z0k8aPDPPsTbea3djlljf0uiZPEQvY3
vp+nvob71bnPtXtfzhc27lZWtxECOIE0ixt/xliOufPsvtsO6e5/KFtOgaJbgykHgTCjSL/xpQet
5v8AmC/Gjsj5ffGDefx+6z7QoOpclvzI7fg3HufIYvI5aCs2fj8imSze2zTYqux9YseeemhhmIlC
PT+SNwVcj3z19tOa9q5J5tsOZd22lr2K2VykYZVIlZdKPVgR2VJGKhqEZHXQX3I5V3PnXlO+5b2v
dls5LhkDuQWrGDqZKKQe4gA5oVqDg9a7m3P+E1Pfm0dwbf3Vtz5gdd4jP7WzWK3DgMnRdbbtpqvG
ZfC1sGQxtbSTQ7nSSGamqqdGVlIIt7yduvvV8t3ttc2d1yTcvbTRsjqZ4yGVwVYEGPIIJ6xltfus
cw2Vzb3lrzrbpcxOrowhkBVlIKkEPxBAPWzr8kdi0/YPxZ7t2BvQUmUTcnR2+8HnZlpylJPXy7Ly
KSZGmgfUYRFkkFRCDdo2VfyPeJfKu4ttvOGwblYEoYtwhdBXIAlXtJ86rg+uessOadvTcuUd+22+
o4l2+ZHNMEmJu4D5NkemOteL/hMCSdifL4sbsd19O6j/AFb+A70uf9ifeTn3t/8Akockf80bn/j8
XWM33S/+Sfzt/wA17b/jkvRQ/wDhSv8A9li9K/8AiuON/wDfjb69jX7qf/Kj79/0tG/6sQ9Ar71H
/K8bD/0q1/6vzda8GNxuSzWSx2Gw2PrcvmMxX0eKxGJxtNLW5LKZTIVEdJQY7H0cCvPV1tbVSrHF
GgLO7AAe8nJZYoIpZ55VSBFLMzEBVVRUsxOAABUk8B1jPFFLPLFBBGzzuwVVUEszE0CgDJJOABx6
+hB/KC+BtR8G/jHTUO9aOCPvHt6qot8dsFNEjYGUUjQ7Y2DHUozLNHtHGVDCoZSUfI1NSVJTQffN
D3t9xl9wubXksHJ5fsgYrf8ApitZJqeXiMMeYRUrmvXSn2U9u29v+U0S/QDf70iW4/oGlI4a/wDC
1Pd5a2elRTrV4/nqfLnG/Jn5lVuzNm5SLKdb/HPF1XWeHraOYTUGX3tJXfe9i5mldHeGaKHLQw4t
JEJV1xpdTZ/eXX3eeSpeU+RY7++hKbpujidgRQrFSkCnzFVJkIPDxKeXWJP3hOdIua+eZLGxmD7X
taGBSODS1rMw8jRgIwfPw6jj1Sz7nnqCOve/de697917r3v3Xuv/1aaG+v8AyCv/AEKPfZg9cbxw
/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691jlYpFI4+qRuw/11
Un/iPewKkD59aPA9b6nybwqdTfyGcvtzb2mmTFfDfqrCloLoHTclBsqkzcvp+r1ozFQz/wCqaQ/1
985uUrg7194yC5usl99uGz/QMpT9mlf2ddE+bIBs33d5rW2wE2O3XH9MRBj+eo1+3rQv99GOudvW
wT/wm8miT5ydgwvIqyz/AB13Z4UJs0ni3rsJpNA/OhWBP+HvGn70ysfb7bGAwN0jr+cU3WSX3XGA
9wNzUnJ2ySn5Sw9WH/8ACm7/AJkd8W//ABLm8/8A3ik9xl90z/lYOb/+eKL/AKu9Sb96/wD5IHKH
/PbL/wBWujB/8Jyv+yAM7/4sP2P/AO6HY/sM/ei/6eTb/wDSsg/4/N0JPuwf9O4uP+lnP/xyLrXO
/nlf9vPPkX/1C9S/++f2N7yh+75/06Tlf/TXP/aTL1jD94D/AKezzP8A6W2/7Routgn/AITY/wDZ
D/aX/izm8P8A32/VfvGr71X/AE8DZ/8ApUxf9X7jrJP7rP8AyoO7/wDS2k/6sW/VLv8AOUnhpf5x
NXU1MscFPT5H4yTzzysEihhhxm1ZJZZHPCxxopJJ4AHud/YtWf2OREBLFL8AepLSY6gr3xZV97nZ
jRQ1iSfQBY+txf5ubK3P2X8P/kzsTY+Kn3Du3d/SHYuF2zhKLS1Xm8xXbXr0x+MoQSFlrMhPpihW
41yOovz7wc5Av7Taud+VNx3CYRWUG4QPI54KokFWPyAyfl1m9z7YXe68k817dt8JlvZtvnVEHFmM
bUUfMnA9T1ocfBNuxPhl85vix2f3n1t2J1NtiLtGn2xk8n2FsvcWzqT+H7lo6naGdngqNwY/Hw1I
wkO4FnqRGzeKJdTWBv76Le4g2vnv295w2nl7dbW9u/ozIqwypKdUZEqAhGYjWUoteJ654e3v7z5G
9weUd25g2q5s7QXgjZponiGmQGNyC6qDoD6mpwHW8L/MW2J8luwPihv+h+IW/Nx7F74wU2H3dtCo
2pk6bE5XddNg6vzZvZdPkatXpopdwYaWb7cPZJKuOFGZVYsOfntfuPKm285bbJztt0Vxy7IGjlEi
lljLiiSlRnsamrzCliM9Z/e5lhzTuPJ+4pyXfyQcwxlZI9DaWkCnuiDYoWUnTkAsFBwT1pXj5bfz
nG3a2wV7O+brb3SvOLfaa7V3Y2cXICY05pTRDaZcN5hbV/m/zqtz7zy/qX7E/RDcf3VsH0GnV4ni
R6NNK1r4np+fWC39c/fP6w7f+8d8+v1afD0S661pTTpr/qr0Mnyw3Z/O1+KGw9j7j+RXfHeuI2T2
5gnpzNTbwoc9j8HXZSCpjn2Bvyegxj0uA3XU4omX7VpHSWN2SOVpYpUQj5NsvYLnLcdwteWOXtve
/spK0MRQuFIpNCC1XjDY1UBBAJADKSdc5X/vzyft1hdczb5fJYXsdKiXWELA1hlIwkhXOmpBFQCS
rAWW/wDCYWWEbO+YVMJIxMN1dPyiHUPIIf4LvaMSaL6vHrFr/S/HuKvvbA/W8jtTHg3Ofnri6lD7
ppUWPO61GrxrY0+WiXPRS/8AhSZTTVvzP6KoqcK1RW/HvC0dOrMEVp6rsze8EIZzwimSQXJ+g59j
P7q7rHyJzDI3wrubE/YIIiegZ96VGk575ejX4m2xQPtM8oHVvP8AK3/kwbB+HsuE7z7srsL2r8jX
oYazb7UlO8+xepDXU15RtKOtjSXN7rEMxjkzE0cfiBK0scYvLJCfu9777lzutxy9sEclnyvqIepp
Nc0OPEphI8VEQJr+MngJr9pPYvbeSWt+YN9kjvOZ9IKUFYreoz4dfikzQyECnBAPiLB/OU/mw4L4
v7L3B8cOhdyUmU+Su88ZPitxZnEVUVQvSG3MnTFKnKVs8Rkji3/k6OYrjKS/low/3coXTCsqn2L9
mrjm6/tuaeY7Vk5UgcMisKfVupwoB/0FSP1G4NTQK1Yqm98feO35SsLnlfl26V+aZ0Kuymv0qMMs
SP8ARmB7F4r8Zp2htHRmd2Z5HeSSRmkklldpJZZHYvJJLI5LySSOSWYklibnn30EAAAAFAOsACSS
STUnrj731rr3v3Xuve/de697917r/9amhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3XvfuvdY5V1xSIPq0bqP+QlI/4n3sGhB68cg9fRFbaQ+X
f8nzFbR24Fq8h2j8KNu0eAhiAYSbsxfXOOmxNDZbgSLujCxwNa+lgf6e+Yovf6le9819ddsdnv7l
z6RtOwY/842J66ZGz/rr7JQ2Vr3SXewoEH/DFgUqP+cigdfPAeOWJ3hqIpIKiF3hqIJVKSwTxMY5
oZUYBklikUqwPIII99OAVYBlYFTkEcCPIj7euZxDKSrCjDBHofMdGl+F/wAsN7/Cn5EbI+QGxaGm
zdVts1+L3Ftaunemod3bOztP9luDb1RVIkrUc1RBpmpajQ/29ZBFIVYKVIQ585N2/n3ljcOWtwkM
aS0ZJAKmOVDVHA8wDhhUalJFRWvQu5F5xv8AkPmaw5k2+MSPFVXjJoJInFHQnyJGVNDRgDQ0p1a1
/N//AJnfx4/mBdH/AB9xPUtBv3bm9tk76z24t6bR3tt+OiOHpsptdMan2Ofx9bkMNm4hkAUVopFk
ZPU0afT3Dnsj7S8z+2vMHMs29SW0thcW6JFJE9dRWTVlGCsvbnIpXAJ6mL3s92OWvcjl/lqHZo7i
K/guHeWOVANIaPTh1LK3dwpQ0zQdDf8Aygv5sPxH+E/xSyfT3eFf2PTbzq+2947zji2psGt3Li/4
Jm8XtmkoGOSp6yGMVTTYqbXHpugC8m/sPe93s3zpz7zlFvnL8dqbBbKKL9SYI2tGkJ7SDjuFD59C
H2S94OTeROTptl36W5F8b2WXsj1LpdYwM6hntNRTqoX+Zt8iutflf81u3e+eop87U7A3rT7Bjwk2
5MLLt/MNJt3r3bG28oKrEzTTy06plcTMIyW/cjCvYarCbfabljdeTeQtk5d3pYxuVuZtYRta980j
rRqCvawrjBqOoT92OZdr5v593vmHZmkO3TiHSXXS3ZDGjVFTTuU0zkZ6tg/k4/zUfid8HfjNvbqr
vWv7Fpt3Z/uvcW+6CLaWw6zc+N/u/ktnbFwlG8uRpqyFI61q/b9SHhK3RAjXOuwhr3z9n+cvcDmz
b945eitjZR2CQkyShG1rLM57SDijrQ1419Opl9jfdzk/kLlTcNo5gkuBeyX7ygRx6xoaKFRnUM1R
sU9PXqrj+ab8musPl58z9+97dN1G4Ztibi2117i8ZPuTCz7bzIrts7WocRkjJjZpppoEStpz4n1e
oWYW9y77P8p7vyTyHtvLu+LENxilmZgjB1pJIWXuoAcHI6iL3f5q2nnPnvct/wBkeQ7fJFCql10N
VI1VsVPmMGvV3fwh/wCFEuxNpdV7U61+YuyewKvdmzMNRbfpe2eusdi9yU+8MbiqaKjxtburblXl
MNkcZuIUsKrVT0rVUNXIPLoiLMvuAfcD7sW43u8Xm68j39stlPIXNvMzIYmY1YRuFYMlT2htJUYq
aV6nzkD7zO32e0We1c72Nw17AgQXEIVxIqgBTIjMhV6fEVLBjmi16Jf/ADpf5lPxs+fGzehMD0R/
pENZ1xujfGX3Ku+NoDbNOaPcOHwlBjzQSjKZD7ubzY+TWtl0LY3N/Y79hvavmr24v+Y7nmL6bRdQ
xLH4UniGqM5avatBQinQF99/dHlf3EseXLbl/wCo8S1mlZ/FjCCjqgFKM1TUGvDocf5en/CgSp6a
2Htvpf5h7X3bv/b21KOlwm1O4tmLR5TedFt+ihWmx2J3ttzIVWO/vH/C6eNIo8jTVAq3hUCWGaQG
Rg/7m/drTfdxut+5Hu4ba5mYvJbS1WIuTVmidQ2jUclGXTXgyjHR/wC2f3kH2Pb7XYedrSa5toQE
juY6NKEAoqyoxXXpGA4bVSmpWOerhZv5+38tKLEfxJe2N71FT49f8Dg6j7A/jOrTfxaZcNFjvJfj
/gTpv+bc+4QX7t/usZvCOzW4Wvxm5h0/8f1f8Z6m0/eM9qhF4g3icv8AwC3m1fzUL/xqnz6o0/ma
/wA81Plj1xuT48fHzrWp2r1LusxU28t8dnY7D1u9Nz46kqY6uCh25tuGbK43ZsMlTCjtWvPPkQFA
i+3JYnIP2m+72eTN0tOZ+Zd1E28w5iigZhFGxFCXchWlNCRpoE9dWOsfvdf7wI5x2u65Z5b2sw7N
NiWWdVMrgGtEQFliFQDrqz+mjqtX+Xh/MB7F/l79yV3Ym1MJS722ZvDFU+3OzOu6+tbGRblw1LV/
e4+vxWVWCq/hG5sFUPI1JUNFLEUmlikQpJdZW9zvbXa/czYo9svLg29/A5eCYDVoYijBlqNUbimo
VBqAQajMV+2XuRuftrvkm52cAnsJ0CTwk6Q6g1Uq1DpdDXSaEUJBFDgY/wCaX89+sfnn8gume5uv
Np742XjNk9bYDae58LvSnw38QhzGN31nty1T4mbCZTJU2Sxwx+UjVJWMEjyqwMaixJF7Qe3G7+3X
LW+7Fud5bzzXF08kbRFqFWhSMag6qVbUpqMgCmT0ee7vuLtPuJzLsW+7ZZ3EENvapHIsoWupZnkO
kqzBl0sKE0NfLo+nzN/4UOdkdg7dqetPhztXKdPbfnxyYnIdvbv+wqezqymFMaWZto4OjmrsLsp5
U/TVyzV1anDxCnkAIjnkT7sm1bbdJu3PF4l9chtQto6iAGtR4jkB5f8ASgIh4HUOpF56+8vue5Wz
7VyRZvZWxXSbmShnIpQ+GoJWKv8AES7eY0HrW5yORyOYyNfmMxkK7LZfLVlTkcrlcpV1GQyeTyNZ
K09XX5Cvq5JaqsrKqZy8ksjM7sbkn3lPFFFBFHBBEqQIoVVUAKqjACgUAAHADA6xblllnlknnlZ5
nYszMSWYnJJJqSScknJ6h+3Om+ve/de697917r3v3Xuve/de6//Xpob6/wDIK/8AQo99mD1xvHD8
z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdbxH/CeT5P4z
tP4j5D4+5PJRnfPxy3BW0lLjppFFVVda70yNdn9tZKnRj5JqfHZubIUEhAIhEUINta35+fea5Rm2
fnWPmaGL/dfukYJYcBPEoR1PoWUI49at6HrP/wC7RzbFvHJcnLU0v+7Da5SAp4mCVi6MPUBi6H0o
vqOqYf53v8tzcHxo7k3D8l+sdvVNV8d+4twTZnNNjafyU3VXZGbnaozGFykcCWoNtbpyTyVeMqGC
wxzTSUhIKQ+Sdvu/+6ltzXsVtypu90BzNYxBU1HNxAgorLXi8a0WQcSAH82pBXv77W3PKu+XPNW0
2xPLV9KWfSMW875ZWpwSRqsh4Akp5LWhX3kb1jr1737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+69176e/de6H/AOPvxX+Q/wAqdyR7X+P/AFLu7smu88cFbksTQfbbVwnkdU824d35
JqPbeEgjLgsZ6lWt9FJ49hrmXnDljk+1N3zJvUFrHSoVjWR/kka1dz9i/b0JeW+T+Zub7oWfLmzT
XUlaFlFI04ZeRqIgzXuYfLqzv5cfybdy/CL4UVHyI7m7Lo8527W7/wBibUpOv9kRCXZW18fuT+Iv
kv4ruLIU8eR3LmohRhFNPFSUkJvYzghhEvJXvnac/wDPycsbFtTR7IttNIZpf7WRkpp0op0xoa17
izH+jw6ljnT2OuuQeQ25m3zdFk3prmKMQxf2UavXVqcirsKUGkKo/pceqRfc/wDUBde9+691737r
3Xvfuvde9+691737r3Xvfuvdf//Qpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdGt+Fvy57F+EvyA2j3r14fvmxTviN57SmqHp
8bvvYuSlg/j+1sg4DrE9QkKT0c5VjSV0MUwB0lSDefOStr5+5bveXtz7dfdFIBVoZlB0SL60qQw/
EhZfPoY8ic6bnyFzJZcw7YdWjtljJossTU1xt9tKqc6XCt5U6+hn0P3z8d/n18fY96bKkwPY3WO/
cTNgt6bI3LRUNfU4esnhCZnZO/NtVX3C0eTonYq0cimOZNM0LPE8ch5l8xcucz+2/MpsL8SWu7Wz
h4pYyQGAPbLDIKVU+oyDVWAII66X8vcw8s+43LYvrEx3W1XCFJYnAJUkd0UqGtGHocEUZSQQeten
5uf8Jznrcll9/wDwa3Zj8fBVyzVs3RHY2SmgoaSWRg7Uuw9/SioenpCzERUWXUrEBb7y1lGTPIH3
oRHFBtvuDZMzKABdwKCT85oRSp9Wj4/778+saefvuxeJLPuXIF4qqxJNpMxoPlFMa0HosnD/AH55
da3Hd3xP+S/xuyc+L7y6N7I65aB3Rcpmtt1s+2KxUcoZsbu3FpX7ZyNOzLw8NW4I/p7yn5f5z5U5
qiWbl7mC1uq/hVwJB8mjakin5FR1i3v/ACZzVytK0XMGwXNsR+JkJjP+lkFUYfMMei8pLHILxyJI
P9odW/3on2JyCOI6DPy8+ufvXXuve/de697917r3v3XusYliaRYldXlchUiQ65XYmwVIk1OxJ/AH
vdCBUjHXhnhnoy/U/wAN/lj3pNDF1H8ce4t8QzFNOUx2xszRbfRZDZJJ9yZmnxmAp4j/AKt6lV9h
PeeeuTOXlY71zRY27D8LSqX/ACRSzn8l6Fezci85cwsBs3LN7OpHxCJgn5uwCD82HVtPRv8AwnT+
afYbUdd3BuXrPoLCy+GSopa7KP2JvJIJCpdYsNtWRdvpUohPplyqgH6/09wxzD95/kLbNceyWl3u
U4rQhfBir/ppO+n2R9TLy/8Adj563PRJvV3a7dAaVBbxpR/tY+yv2yDq8D45f8J+/g50xJQ5jsyl
3V8kt1UpWRpux6xMVslahbFZKbYW22paKaIML+PIVWQUjg35vj9zR95T3B30SQbU8O1WZ8oBqlp8
5nqfzRUPU/csfdv9v9iMc+6xzbpeD/fx0xV+UKUBHydnHV1W0tm7S2FgaDamxdrbe2ZtjFxiLG7d
2rhcdt/CUEYCropMXiqelooAQovpQXtz7gW9vr3crmS83G8lnu3NWeRmdz9rMST+3qd7Kxsttto7
Pb7OKC0QUVI1VEH2KoAH7OtdD/hQj8qvj3lvjC3xqwXam1tx92ydpbG3PWbD25WjO5HBYbb4zJyV
RuWpxgqcdt6dDUoEpqqaOqlLXWMrdhlD92fk7maHm0c13GzzRbALOWMTONCuz6dIjDUZxg1ZQVHm
a9YxfeV5v5am5SPK1vu8Uu/G8icxIdZRU1ai5WqociisQx8h1pke87OsF+ve/de697917r3v3Xuv
e/de697917r3v3Xuv//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+690Zr4r/AC/7/wDhn2HH2R0Jviq21kKgQ0+5NuVi
tktl73xkL6xit3bclkSlyUA58U6GKspWOqGWM3uE+cOSOW+e9sO1cx7essYqUcdssTH8Ub8VPqMq
3BlPQs5Q525j5G3Mbpy7fmKQ0Doe6KVR+GRODD0OGXirA9bf/wAOv+FAHxW7zpMVtj5CA/Gfs2VY
qaoqs9PNk+pszWEKhnxG9Y4vLt+OolJIgy8VOsI4+4l/V7wi54+7Zzjy8813yz/u22kVICALcKPR
ovx09Yy1f4Rw6zY5I+8fyhzCkNpzJ/uq3U4Jclrdj6rLTsr6SAAfxnj1eViczszsbbceSwWV2vv3
aGag/Zr8TXYndO28tSuA37dTSS12MroHUg8MykH3j5NBf7XdGK4hmtr2M5DBo3U/YaMD1kBDPYbp
aiW3mhuLKQYKlZEYfaKqR+3oqXZX8uX4I9u1Etbv/wCKHSWWr57mbJY7ZWN2vlZWIsXkym1FwmQe
Q/6oyFr/AJ9jHavdH3E2RRHtvOV+kY4K0rSL/vMmtf5dBDc/bH2+3h2kv+ULFpTxZYhGx+1o9Dfz
6KTuP+Q3/LNz8sktN0ruLbGskiPbHafYdHFGSCP246/cGSUAE3ANx/sPY1tfvF+69soV9+im/wCa
lvCf8CL0C7r7u/tVcsWXYpYif4LiYf8AHnbpAy/8J5f5ckjs6YTueBT9Iou2cmY04A9Jmx80pv8A
Xlj7Ml+817ogAG4sSf8AnnX/ACMOi8/dq9sSSRb3o/6iD/lU9PeN/wCE/f8ALYoJEefr/srMadN0
ynbm8PG+kWOtMfVUAOs8n6c/Sw9p5fvKe6kgIXcrVP8AS20f/PwPT0f3b/a1CC223T/6a4k/59K9
DXtf+TD/ACzNq+N6b4rbSzM8ZUibdm4t9bp1lTcGSlze6Kugf/W8VvZBee+3uve1D84TIp8o0hj/
AJpGD/Po/svY32rsaGLlKJ29Xkmf9oaQj+XRwOvvif8AF/qdIV61+PHS2yZINJiqtu9a7Rx2QUqA
AxyMWKFez8fUyEn2CNz5z5u3ksd15mv7gHiHnkYf7yWp/LoabbybylswX91cs2FuRwKQRqf96C1/
n0YFF0oscahI0UIiIoRFRRZVVVAVVUCwA4A9hompJPHoSgAAADHRZu5vmb8UPj1TzT9zfIPqrYU8
AYth8pu7F1O5ZNAJIp9q4uav3HVNxYCOlYk8fX2LNi5E5y5mZV2Llq8uVP4ljYR/nIwCD82HQU3z
nnk/ltWO+cyWduw/C0imT8o1Jc/kvVMHyD/4Uh/GPZEddi/jz1pv3vLOos0VNns6i9abBWcXWKoF
RlIchuzJU4bkouNp9Y+kg4Pud+Wfus82X5jm5m3W22+3NKon681PSilY1Pz8RqenUF8y/ei5TsFk
i5a2u43C4ph3/Qhr61YNIR8tC1Hnw61/vlJ/OT+dfyljyWDyPZY6f6+yHmik2D0ulXtGmqaKbhqP
M7r+6qd5ZqFkFnjatip35vFz7yT5Q9i/bzlAxXEW0/XbktD411SQgjzWOgiU+h0Fh69Y383e+XuD
zcJbeTdPottav6VtWMEejSVMrfMF9J/h6qwYlnkldmklmkeaaWRmklmmkYtJLNK5aSWWRjdmYlie
SfcwjAAAoAKAeg+XUQEkkkmpPXXv3Wuve/de697917r3v3Xuve/de697917r3v3Xuv/Spob6/wDI
K/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3XiARYgEH6g8g+/de6FrqbvvvDobJjL9K9u9i9WVwk8rtsjduYwVJUP8A1rMX
S1IxVcG+hE0Dgj6+yXeeW+X+YovA37ZLW8jpT9WNXI+xiNQ/Ijo72bmXmDl2YT7FvV1aSVr+lIyA
/aoND+YPVoPWf8/D+Y917DSUeZ7B2F2xQUgVBH2R11iHyMsa/UT5rZ0u0shPIR/blMjf4+4j3b7u
PtbubO8G23NnIf8AfE7UH2LL4ij7BTqWtp+8Z7n7YiRz7jb3iD/f8K1I+bReGxPzJPRyttf8KbO/
KWOJN4fGDqLOOoUSzbc3lvDbZksLM4iyNLuVUZvrbVb2Bbr7p3Ljkmy5tvYx6PFHJ/NTH0Obb713
MKBRecqWch8ykkkf8j4nQsUX/CnucJ/uS+HBaTSvNB3JGsevnXxU7ELaf6fn+vsmk+6Stf0uecfO
1/zTdHEf3sjT9XkjPyuf88PUbI/8KesmQ/8ACPhzTI1h4/4n3GzqDpOryfabFUkF/pb8e7RfdJhx
4/PB/wBrbf55uqS/eylz4HJAr/Suf80PQSbi/wCFNHyLq0lTanxo6YwTMGEc2d3RvXcbxXvpYpRf
3djkI/xsD7OrX7p3K6EG85rv5B/QjiT/AA6+ia5+9bzK4YWnK1jGfLU8sn+Ax9FU33/woD/mPbwW
phwW7+res6eoBUDZXWGLrKuFT/xyrt7Ve7HVwP7QQN/S3sY7d92v2tsSjXFleXbD/fs7AH8ohH0D
9w+8j7n3qutveWlpX/fUCkj85TIfz6IF2l87/mh3Wk1P2d8oO6NzUE+ry4dN65Pb+CYOSWT+B7Yf
C4rxm/6fFa3uSdo9uuQ9hKttPKNhFIPxeErv/vcmpv59Rxu/uJz1voK7rzZfSxn8Pisif7wmlf5d
FNceSaSplLTVMzF5qmZmmqJnY3Z5p5C0srsTcliSfYzGFCrhRwAwP2dA0ksdTGrfPPXfv3Wuve/d
e697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuv/9Omhvr/AMgr/wBCj32YPXG8cPzP
XH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Upob6/wDIK/8AQo99mD1xvHD8z1x96631737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691//1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvdf/9amhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3X//Xpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//0KaG
+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Gmhvr/AMgr/wBC
j32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Spob6/wDIK/8AQo99mD1xvHD8
z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691//06aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvdf/9Smhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3X//Vpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691//1qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9em
hvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Qpob6/wDIK/8A
Qo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//0aaG+v8AyCv/AEKPfZg9cbxw
/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Kmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691//1KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvdf/9Wmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//W
pob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//16aG+v8AyCv/
AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Cmhvr/AMgr/wBCj32YPXG8
cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691//0qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvdf/9Omhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3X//Upob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//
1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9amhvr/AMgr
/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Xpob6/wDIK/8AQo99mD1x
vHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//0KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut
9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvdf/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3X//Spob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691//06aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf
/9Smhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Vpob6/wDI
K/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//1qaG+v8AyCv/AEKPfZg9
cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9emhvr/AMgr/wBCj32YPXG8cPzPXH3r
rfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3X//Qpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691//0aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvdf/9Kmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//1KaG+v8A
yCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Wmhvr/AMgr/wBCj32Y
PXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Wpob6/wDIK/8AQo99mD1xvHD8z1x9
6631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691//16aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvdf/9Cmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3X//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91//0qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Omhvr/
AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Upob6/wDIK/8AQo99
mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//1aaG+v8AyCv/AEKPfZg9cbxw/M9c
feut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvdf/9amhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3X//Xpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691//0KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvdf/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Spob6
/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//06aG+v8AyCv/AEKP
fZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Smhvr/AMgr/wBCj32YPXG8cPzP
XH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdG
k+Hfx+258mO6U613hvrK9b7WouvO0ux9wbtwm2Yd4ZagxHV2xszvjIQY/b1RlMLFkaqupMM8SKam
OzMPr7CHPPMt1ynsB3ax25Lq8a6t4EjeQxKWuJViUlwraQCwJ7T0L+R+W7TmrfhtV9uD2tmttcTv
IieIwW3iaUgIWTUSFoO4dDEvVv8ALBZVYfNH5Q2YBh/zh9gvoRcf81m9kP7592/+mE2j/uZP/wBs
vQg/cvtN/wBN1un/AHLk/wC2vrl/or/lhf8AeaPyh/8ASPsF/wDbl9+/fPu3/wBMJtH/AHMn/wC2
Xr37l9pv+m63T/uXJ/219e/0V/ywv+80flD/AOkfYL/7cvv37592/wDphNo/7mT/APbL179y+03/
AE3W6f8AcuT/ALa+vf6K/wCWF/3mj8of/SPsF/8Abl9+/fPu3/0wm0f9zJ/+2Xr37l9pv+m63T/u
XJ/219e/0V/ywv8AvNH5Q/8ApH2C/wDty+/fvn3b/wCmE2j/ALmT/wDbL179y+03/Tdbp/3Lk/7a
+vf6K/5YX/eaPyh/9I+wX/25ffv3z7t/9MJtH/cyf/tl69+5fab/AKbrdP8AuXJ/219e/wBFf8sL
/vNH5Q/+kfYL/wC3L79++fdv/phNo/7mT/8AbL179y+03/Tdbp/3Lk/7a+vf6K/5YX/eaPyh/wDS
PsF/9uX3798+7f8A0wm0f9zJ/wDtl69+5fab/put0/7lyf8AbX17/RX/ACwvx80flDf8X+H2Ctf/
AB/4zN79++fdv/phNo/7mT/9svXv3L7Tf9N1un/cuT/tr6mUvw1+O3akiY/4x/PXqjeO8KkBcZ1t
8hdlbm+Mm6M7VtxHjMFufcVXuPrOsydQ5CRRT5el8j8BvdG575n2cGTm325vILIfFPZSx38aD+J4
0CThR5kRNTracics7v8Ap8qe4lnPenhDeRPYux/hSRzJAWPAAyrU4r0TTtrp3tPofe+S637k2HuP
rre+KWOWpwG5aFqWaejnuaXK4qrjabHZvC1yeqnraOaelnQ3SRh7Hey75s/Me3xbrsW4xXW3vgPG
agEcVYfEjj8SMAw8x0BN62Pd+Xdwl2vfNultb9KEo4oSDwZTwZT5MpKnyJ6Db2a9FXXvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvdf/1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691Yb/LG/7KO3j/4qj8wP
/get9+4x92v+VVsv+lztv/abD1JntP8A8rTff9Kbcv8AtDl6rlg/zEP/ACyj/wChB7k9viP29RkO
A6y+9db697917r3v3XuslPFNV1UFDRwT1ldUusVNRUcMtVWVMrmyR09LTpJUTSMeAFUkn3pmVEaR
2CxgVJJoB9pOB1ZFaR1jjUs5NAAKkn5AdHN6v/lzfO7uSmp6/r74o9z5LF1RX7bM5vak+ysLOrWt
JDlN6ybfpJorG+pGZbewJu3uh7d7G7R7lzjYLMOKpIJWH2rFrIP2jodbT7X+4W9oJNt5QvmiJwzR
mJT8w0uhSPmD0b3CfyFf5l+XpkqqrqfYu21cXEW4u3dkQVA4Bs8ONrsoUNzbk/X2Cbj7xntTA5RN
5uJT/QtpaftYL0Nbf7u3ulOgd9ogi+T3EVf+Ms3WDcf8hv8AmZbfpHrKfp3aG6I0BPi2v2xserqn
sL2jpslkcU8hP04/Pu1r94r2ouXCNvc8J9ZLeUD9qq3Vbr7u/unbIXTZYZvkk8RP7GZeiEd0fDz5
U/HUNN3d8fe1euccl/8Ac/mtp5CfaraW0kpuzFJkdtsL/wDTUPcj7DzxyfzPRdg5ls7qX+BZAJP+
cbaX/wCM9R1vvI/N/LILb9y5d20QHxtG3h/85BVD+TdFsIjlTkJIjC/NnRh+P6gj2Kcg/PoK9WUf
G35A7Z7r2vhPhZ8wM4+T6szc5w/QPeWdc5DefxS7EybCn2/VUeeqWbI5Ho/PZN46XP4GeVqalhl+
8phFJCQ0V808tXewXk/PnJFvo3eMary0Tti3CFcuCg7Vu0WrQzAamI0PUNiVOVuZLTf7ODkTnW41
bTIdNndv3S2EzfAQ5ybV2os0JOlVOtNLLkkXa3WG9Oleyt89SdiYpsLvfrvc2U2puXHFvJFHksVU
NC1RRz2C1WOr4dFRSzL6ZqeVHHDD3IOzbvYb/tW371tc3ibfdRLJG39FhWhHkwNQw8mBHl1Hu8bT
f7Duu4bLucPh7haytHIv9JTSoPmp4qfNSD59B/7M+i3r3v3Xuve/de697917r3v3Xuve/de69791
7r//1qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691Yb/LG/7KO3j/4qj8wP/get9+4x92v+VVsv+lztv/abD1Jn
tP8A8rTff9Kbcv8AtDl6rlg/zEP/ACyj/wChB7k9viP29RkOA6y+9db6yQxSVE0NPCvknqJooIYw
VBkmmkWKJAWKqNbsBckAfk296YhVZ2NFAqfsHW1UsyqvxE0H2nqzPEfGz4afG+OPJfNbvjI9n9iw
IJm+LXxErcTunJ4yo0ErjO0++qt/7g7YqUlKrU0WGfI1cQDDyhxYRPNzVz1zSxi5C5dW02s4/eG5
Bo1YfxW9oP1pB/C8uhTjtp1LNvytyNysFm575ha73MZ+g24rIVP8M92f0UORqSLxGGcg46EGD+bJ
WdMUzYT4L/Ez47fE/FwSMKXelXtodzd1VcaIsVPUZbsDfCPFLXBV1sftJU8jG3FvZY3sym+sLj3C
5z3PeZiMxB/pbUeoWGLgPL4hjoyX3kbYlMHIHJu27REOEpT6m6NMAtNNWp/2nRUuyP5iXzr7bab+
/fyw7tyFNPI8r4zD7zrtn4ZWe4KxYjZ38Bx8Uek20iO1uPYy2r2x9vNlC/u7k2wVwPiaISt/vUus
/wA+gbuvub7g71UbhzhfspPBJWjX/eY9C/y6LNX9jdjZWV6jKdi9gZKdzqeav3tuisldvrdpKjKy
MTf2K49q2qFQsO12yL6CKMD+S9BaTd91mOqXc7hm9TIxP8z0+7a7u7r2bVxV+0e5O2NsVsLrJFU4
HsbeGMlR0OpWBpczGDY/1BB/PtPdcv7BfIY73YrOaM+TwxsP5r0/bcw7/ZMr2e+XcLg4KTSKf5MO
rNPjr/PH+cXTNRFh+wt6Yv5O9aTAUu4Njd0UdHl8lXYuRDDU01HvilpUz0EskN9Irv4jTEj1wsL+
4n5n+797f76hn2yxfad1GUltSVUN5ExE6CP9Job0YdStyz7/APP2xsId0vV3Xazh4rkBiVpQgS01
1P8ATLr6qej99vfCP4jfzTPjvur5ffy49uRdT9+7NjmrO2vjTEtJQ4/L5haWbI1WHpcFQt/C8HuT
KwQSy4bI41YsXmtHikhhqPIYo42Tn/nT2h5ns+SfdC6N5y3OQLe+NSyrUKGLnudFJAlR6yRcQzLp
1SNvfIPJnu5yzd86e2NsLPmKAE3FiKBWahYqFHartQmJ0pHJlSqvq06wc0MkbTU1TDLBNG8tPUU8
8bwzwTRs0U0E0ThZIZoZFKsrAMrAg8j3lqrAhWRgVOQRkEeRHqD1iYylSyspDA0IOCCOIPzHVjHz
sq27J2F8I/ktWSNU7n7m+NcG0OxMg6gTZjfvx53ZlepqnO1kg5qK/LbUx2JM8hu0kkZYkk+4x9u0
/de48/8AKiClnYbqZYR5LDexrcBB6BZGkoPIEDqTfcN/3pt3IXNTtW7vtqEcx82mspGti5PmWjWO
p8yK9V2+5P6jHr3v3Xuve/de697917r3v3Xuve/de697917r/9emhvr/AMgr/wBCj32YPXG8cPzP
XH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdW
G/yxv+yjt4/+Ko/MD/4HrffuMfdr/lVbL/pc7b/2mw9SZ7T/APK033/Sm3L/ALQ5eq5YP8xD/wAs
o/8AoQe5Pb4j9vUZDgOjTfF/4t7n+Sma3pWfx/F9c9RdRbVqt+929y7njlba/XO0qVJRTK0cWmXN
bs3NWxCjw+KgJqK2qbgBEdgEObub7TlSCwT6Z7rer2YQ2trHTxJ5Dx44WOMd0sh7UX5kDoX8pcoX
fNU9+/1KWuzWUJmurl/7OGMcPm0jntjjHc7cMAkHN6lynxJi/lm9t4/dXxF7Z3h8lJK/eX90Pk7i
+pcxlOuNqU75nBnCxZjsqHNQYzDy4aiE0MyPSSeB51U3LXAE3qLnM+7GyyWfOlnBytpi8Swa4VZ5
DpfVpgKFm1GhHcKgE+XQ72abk0e1G9R3fJl5NzOWk8O+W3ZoI+5NOqbWAukVB7TQkDqu7bPx47+3
fg6DcezOh+5N1bZycckuLz+1+r96ZzBZGKKaSnlkx+VxWEqqCsjjqInRjHIwDqQeQR7k675n5bsb
iS1v+YrGG7Q9ySXESOuK9ys4IwQcjh1GNry1zJfQR3Vly9fTWr5V44JXRs0qGVSDkUwePSX3x1n2
X1nLSU/Y/XO/evanIxSzY2DfOz9w7TkyMcP+dehTPY6gNWsRI1ePVp/PtZt+7bTuwdtq3S2ukUgM
YZUk019dDGn59JNw2nddqKLum13FszglRLG8ZanprAr+XVzHyy/lQbX6j+Cnxe+TnRkPe/afY/cu
O2BmN/bXpcRT7t2/tjEbo60yG8szlaLHbU2pHmMXjcfl6aKCOerqJYlieztrIPuCuTfeS73r3D5u
5T5hbbrPa7FplhkLGN5GjnWJVLSSaWZlJJCqDUYx1OHOPs7abN7e8pc2cvruN5ul8kLTRhRIkayQ
GVmCxx6lUMAAWYihznqm7r7qzs/tvLzYDqrrnfPZWbpoRU1WK2JtXNbpraSnYkLUVkOGo6s0cLML
BpdCk8C/uctz3jaNlgW53jdLe0tyaBppFjBPoCxFT9nUI7Zs+7b1M1vs+13F1OBUrFG0hA9SFBoP
mem7fGwt99aZ6o2p2PsrdmwN0Uscc9Rt7ee38rtrNRQSkiKoOPy9LSVLU8pU6ZFUo1uD7e27ctu3
a3W82u/hubQmgeJ1kWvpqUkV+XHprcNt3HarlrPdLCa2uwKlJUZGp66WANPn1sq/zsuqei+heq/5
du9th9HdZbfkydRk8vvai2xtLBbYbfUGM2d13kRj9x1WLx0bZON5qiZgahZhrlYsG1MDip7CbxzD
zHvHudYbjzBdyBAqxGSR5PCLSzrVAzHTgD4aYA6ym9+dn5e5d2f2zv8AbuX7SMuWaUJGkfihY4Wo
5Ve7JPGuSeisfyYfkVX0H803BNsvAU+yNj/ITFby2duTYeIZBh4KWi21V7rwlStPTxU9IlRjM9t4
So6Rjxx1EyA2kYsMPfXleOT2guPr7k3G4bY8UqTN8RJkEbCpJNGR6EE5KqfIdBH2M5nkj93Lf6C3
Fvt+5JLG8K/CAEMimgAFVdKjGAzDzPRPf5tfWuD6o/mKfKPau26eGjw1Xvql3nTUVNGsNPRT7/25
hd6ZKmgiQBI4Y8pm5iqgAAG3sb+zG63G8+2HKN5dMWnW3MRJySIXaJST66UHQJ95tqt9n9zebbO1
ULA1wJQBgAzIsrAfLU56bfkR/wBkKfy5v8Kf5Ygf63+mPGm3+tc+3uVv+nh+6P27d/2jHpjmf/p3
3tj9m4/9pK9EC9yV1G/Xvfuvde9+691737r3Xvfuvde9+691737r3X//0KaG+v8AyCv/AEKPfZg9
cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691Yb/LG/7KO3j/4qj8wP/get9+4x92v+VVsv+lztv/abD1JntP8A8rTff9Kbcv8AtDl6rlhv
4IdKl2MUYVFF2diqhUUflmPA/wAfcnn4jU4r1GQ4Cgz1eN/MLwcfws+GfxG+B+2fHjt19o7ZpflV
8psjSFI67dG8c7potkbVysqIk82H2aYaqKGndjEWoYJQofUTj97Z3B5856509xLurWdnKdv29Twj
iTMsi+QaWqkkZ72WtKUn/wBy4ByJyNyZ7eWgC3l3ENwv2HGSR8RRtTJWKjAA47Falej0/FRj/wBA
4Pyp5PGZ7bA5PAO7tlXA/wADqP8At/cec4f+JScn/wDNO3/6ty9SFyj/AOIwc3f6e4/6uRdD9sj5
MdufEv8A4T79Fd1dKZjF4bf+CfDYfG1+bwdFuPHxUG4O6txY3JxNisiGpZGlpahgrEXRjcc+w5f8
qbLzn95TmHYd+geTbZNTMEcoapaoy9y54j8+hHt/NW8cm/dv5f37YplTcY9CqWUOKPdOrdrAjgfT
pLdx9ybr+d38gTsnvz5E0O19w9p7U3BWV+E3Dhtv0uDXH5ba3beG23QZagooDJDjayq29kpqOpEB
SOaJ2uvJ9q9k2Oz9u/vIbVy5yxJNFtE0QDIzl6rJbM5Uk5YB1DLWpBAz0k3ve7v3D+7punMXM0cU
u7Qyko6oF0tHcogYAYUlGKtpoCCcdCB81vl13f8AD7+UZ8Ed29GZvC4PNb82L1H17uWbN7cx+44q
na+T6KylfV01LDkQUoqtqnHxFZ09agED6+y3kPkrYOd/er3DsuYLeSSC3uLmZArslJFu1AJK8RRj
g46MOeudN+5J9mPby92CdI5ri3toX1Ir1ja0YkDVWhqBkZ6HnrX48fJf4z/y3vjjsT+XNS9JbU7i
7GwO0ewe3+zu1amgo566o3XtePc2XyVHFW4vJ0ufzTZDKQ0FIKpJIKDGwaY01FWAc3XmflTmv3S5
o3H3Pe/m2S1kkhtoLcEgCOTw1U0ZSi6VLtpILyNUmlR0JNp5a5o5U9r+WNv9s47GHerqOOa5nnKg
sZIw7MNSsHarBF1AhI1oBUggAv5qfTPYHbP8qKLtH5d0nUf+zg/HvIYLLzbr6xyNHXY7MYrKb8x+
0MlR0E6QUM1PR7m27m4K6roEj+3hyNKGiVVHAk9nt923ZveM7RyU97/Unc1dRHOpDKywtIpIqQTG
6FFcnUUahJPQb939j3HePZ/9785pZ/10211bxIGDBlaYRkA0XDo4dkA0h1qAB0XP/hRB/wBk4/y7
v+1Vuj/333XHsUfdk/5Wn3O/08f/AFen6C/3mP8AlV/bP/SSf9WYegi/4T5/EXKP2Puz57doQDan
TnTm1N24vY+4s8P4fjc5uWrxs9NvHdEFTUhYm21sXayVcdRVX8RrKkKrE08oU6+8rzrD+67L252h
vG3y+mjaVE7mRAwMUZA/HLJpIXjpXI7lqTfdt5Ll/ed57ibuvg7JYwyLE74VnKkSSAn8EUeoM3DU
2D2tSlX5vd+wfKH5ad9d7UHmGD3/ANgZSr2qtQCs6bOxKQYDaXmQgGOWTb2Kp3ZSLqzke565A5cb
lHkzlzl2Sn1FtbKJKcPFaryU/wBuzD8uoH5+5jXm3nLmLmGOvgXNyxjrx8JaJHX56FBPQu/If/sh
T+XN/wBQ/wAsf/fx432S8rf9PD90ft27/tGPRzzP/wBO+9sfs3H/ALSV6IF7krqN+ve/de697917
r3v3Xuve/de697917r3v3Xuv/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdWG/yxv+yjt4/+Ko/MD/4Hrffu
Mfdr/lVbL/pc7b/2mw9SZ7T/APK033/Sm3L/ALQ5eiBbPmpafcW0aiu0/Ywbg25NWl7aBRxZSikq
S9+NAgVr/wCHuRr5Xa1vVj/tDE4H2lTT+fUd2TIt3ZtJ/ZiVCfsDCv8ALq+X/hRZtLJY75ldZ77W
IttLsD49bPG1ayNW+1cbZzWfpclRQvzFrp48nTTFFNwlQpI9QJx2+7BexS8jbttxP+O225yeIPP9
REKk/bpYV9VPp1kP95uyli542rcQP8Sudtj8M+X6buGA+wMp+wj16ZvjF85ehNv/AMnX5ZfDDeO5
TtTufIvu3O9f43JUdc+O7Co915jaeQWhwmTpaaejgzmMnxtQstNUvCXiCPGXuwV/m32+5juffDkz
nuxtPG2JfDSZlI1QmNZBV1JBKMGWjLXNQaYqxyn7gcu2/sjzlyNfXXg743iNCpB0zCRozRWAIDgq
QVamKEE5ouuyvl18bcz/ACHutfi1i+29t1nyBw2R2tNlOr4osuNwUcdD3DltwVbSySY1MWRBhJ0q
W01B9DAfq49l21clc0wfeJ3Xm+bZZV5bkWTTcVXQa2yoPxassNPDj0Y7rznyvP8Ad42vlOLeI25i
Ro9UFG1ilyznOnThe74uHz64dYfLj424X+Q/2t8Wst23tyh+QOdye5p8R1fLFlzn66Ot7d2/n6Vo
pI8a+LAmwtLJUDVUD0IQfVx73u/JfNNx94nZ+b4dllblqNIw1wCugUtnQ/i1YYhfh49a2jnPli3+
7zvHKk28RrzFI7lYKNrNblHGdOnKgn4uHz6HmH5Yfy2/nN/Lc6N+Ofym7w3H0F2d8dtvYCGlwtDR
ZKnlz26dh7Jy+zMLWYrJrtjc2FzG3dz4yoSSSJmp6mmqJCh0hA7h1uTfdP2+90+YeaOUOX4ty2nc
5XJclTojmlWVgy+JG6vGwIB7lYCua0AiTm/2v9wPa3YOWebd+l27ddsiQBQG75IYmiUq3hyIySKa
kHSyk0xSpaeovmL8CPn38HepPiZ86e3NzfG7troCDE4/Z/Z+Oq6zGY7OUW2sW228Nl8ZnIsZlsMX
yO1pI6XKYvJxxXqKcTwSG6BHt75H9xvbj3A3vnP292WLdNl3Is0kDAMyGRvEZWTUr9slWjkjJ7W0
sONWdj529vPcbkHZuTuf94l2zettCrHOpIDBF8NWVtLLmMhXSQDuGpTwpXr8/dgfywerOpNlbK+H
3yC7c7670gz81VvDeNTl67Mdd5bbFWrmSj3A9VRYPCUeRxU9PEcdFh4Khm8kpq5D+2Vkv223L3a3
fer+/wCduWrLbuXjHSKIKFmWQeaULuVYE6zKV4DQONY29yNu9qNo2ax2/kvmK83DmASVkkJJhaM1
w9VRQykDQIw1anxD8NDkfLn5+/C/5rYj+VtQb7r6ui2v1PvunpPlbsDcOI3FTf3b2pHhNh4zPyRZ
HDwE7gwGX/gdWKd8dM1S8NgyRu2kAbkv23585Cn93ZdujVru9tydvmRkOuTVMyVVj2Outa6xpB4E
gV6G/OXuPyLz3B7Sx7hKy2tncAX8Tq40IFhV6Mo70bS1Ch1U4gE06C7+ZV/OFx3fvXsHxL+HG0qj
pv4qYeipcDlKqDG021812Hg8WVFFtvHbdxwWLZ3XqNGrvSEmsyBUecRRloXOPar2Ql5c3Nuc+ebw
X3ODsXUFjIsLtxdnb+1m9G+FPw1NGBN7p+9kXMW2rybyRZmx5PRQjEKI2mVeCBF/soeBK/E/4qCq
mhT3kZ1jt1YL8h/+yFP5c3/UP8sf/fx433GvK3/Tw/dH7du/7Rj1JHM//TvvbH7Nx/7SV6IF7krq
N+ve/de697917r3v3Xuve/de697917r3v3Xuv//Spob6/wDIK/8AQo99mD1xvHD8z1x96631737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Vhv8sb/so7eP
/iqPzA/+B6337jH3a/5VWy/6XO2/9psPUme0/wDytN9/0pty/wC0OXquSIBqeJT9GhQGxsbFAOD+
D7k84Yn59RkOA62/uhoemv54X8vnaXx531u+h2X8yfi7haOh2/uOsCT5L/cZjocBh95vjUaKqz+w
99YejpaTPxwky0eTgWXhhTiXCXmJt9+7/wC5d7zNt9k0/I27yEugwvcxdotWQk0TFmhJw0ZI4aqZ
rcvDY/f322s+WtwvVg532mMBHOW7QEWSnF4pVCrMBlZAG/g1a4vyh+Bvys+HmercT3j1HuPEYWnq
Xgx/YmBoqvcnWmeiHMVVi94Y2nkoIBPH6hT1n2tXHezxKQR7yi5R9xeTud7eObl/eonnIqYXISdP
k0TGpp/EupT5MesYObfbvnDkm4kh3/ZpUgU4mQF4H+ayKKZ/hbS481HRPVmhf9Esb/8ABXU/70fY
4II4joE8D8+udx9bj/X9669jrg00KfrljX/gzqv+9ke90J4A9eGcDj0JHXPUHbXcOTiwvU3V/YPZ
eUmdUSj2Ns/PbmYMxABllxdDUU1Ol2F2kdFH5Psq3TfNl2OIz7zu9taQjzllSP8A48QT+XRrtex7
1vcog2fabm6lJpSKN3P56QaD5nHVwvxy/wCE/nzn7lmoMl2fRbU+N2z5zHLUVW+8jFn97vTMy+Ra
DY22Jqsw1gQmyZGtoLH63+nuEOaPvJ+32xLJFtEk26Xo4CJSkVfnLIBUfNFfqbOWPu38/wC+NHLu
yQ7ZZHiZW1y0/oxJXPydk6NB/My/lffEL+X18EjWbZz1Rvf5Hbp7G2DQU+9t+5+jpd15HAxT5STc
0Wxdh0NVBQYjA6FiNW6Q1k6KFWSpsQCEvaj3b529yvcMJd24t+V4bWYmKFCYw5C+H40xBLPx0glQ
ckJ0LPdb2n5L9t/b3XaXBn5nmuoQJZXAkZAWLiKEEBU4ajR2AoC/Wst7yw6xS697917qwX5D/wDZ
Cn8ub/qH+WP/AL+PG+415W/6eH7o/bt3/aMepI5n/wCnfe2P2bj/ANpK9EC9yV1G/Xvfuvde9+69
1737r3Xvfuvde9+691737r3X/9Omhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdWG/yxv+yjt4/+Ko/MD/4Hrffu
Mfdr/lVbL/pc7b/2mw9SZ7T/APK033/Sm3L/ALQ5eq5YP8xD/wAso/8AoQe5Pb4j9vUZDgOl71v2
X2D09vbA9kdWbxz+wd97YqxW4LdO2q+XHZWgm+kkYkjvHU0dVH6J6eZZIJ4yUkRlJHsu3Xads3yw
uNr3ixjudulFHjkGpT/mI4hhQg5BB6Mdq3bctjv7fdNovpLfcIjVJEOlgf8AKDwINQRggjrZV+M3
/CkndGMw1Js75jdJ0vYtKKdKGu7F6sOOxWWydOfTLUbi67zrrt3IVUqf5w0VZRQv+KdfocVea/us
Wks733I+/m1etRDcamVT6JMneB6a1c/0usqOVfvR3UUCWXO+xC5SlDNBRWYf04X7GNOOlkHovRyo
PnD/AMJ9vkIf4j2JsHpzaeZqjrqIeyfjhX7Yyvkb1O9Vmdp7XyGLmlLHlxWuSfyfYEbkD7ynLP6W
2blfTQDgYL0SL+SySKw+zQOhyvPn3cOZW17lttjFcHiJrIo35vFGyk/PWep8A/4TZaxkom+JWq7S
6Zpd4FLjkg4yofx244QxW/oPbbH709PCP75pwx4f/Hh/hr0+qfdir4lNo+w+L/x0/wCCnT1B8sv+
E8/TK/f7Wxnxmra2mGuFNp/H3Nb0rzJGLr4KiXYWQhExI4czLz/a9sNyb95jfv07ubdljPHxLxYl
/MeMpp8qfl07/W77tmwfqW1vtZkHDRZvI35EwkV+dfz6Re/P+FHPwx66xX8F6H6O7U3ytLGY6GkG
D2x1LtOMhSIzEZarJZKKAWHAxqtbiw+vtft33Xue90m8fmLmCzt68TrkuJPzwq1/5udINx+87yLt
cX0/L+w3dxQYGmO3j/LLNT/adVM/IP8A4UN/N3tiCuw3VOO2D8dNv1SzQrV7Vx8m8d+mnkJ06917
rSXGUdQq2/co8XTyKfo/uZuWvuzcg7M0c+8y3O6XIzSQ+FDX/mnHRiPk0jD5dQ1zL95bnzeFkg2a
K32y2YUrGviS/wDOSSqjHmsan59Uk787C372nujIb27N3rursHeGVdnyG5t5Z3I7izVSWYtoauyd
RUTRwIT6YkKxIOFUD3Pu3bZtuz2kVhtNhDbWKDtjiRUUfkoAr8zk9QJuW57jvF3Jf7rfzXN65y8j
s7H82JPngeXSP9rukPXvfuvdWC/If/shT+XN/wBQ/wAsf/fx433GvK3/AE8P3R+3bv8AtGPUkcz/
APTvvbH7Nx/7SV6IF7krqN+ve/de697917r3v3Xuve/de697917r3v3Xuv/Upob6/wDIK/8AQo99
mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Vjf8rOmoKz5Q7ho8ruDB7TxdX8X/AJa02S3Vuiqlods7ZoJ+gd8RVe4NxV0EFVPR4LDU
7NUVcqRSNHBGzBWIsYl97L+Ha+RG3O5DG3ttysJWC5YrHdxO1BipoDTPHqWPZWwm3TnkbZbFRcXG
238S6jRdUlrIq1OaCpFcHHQAx9E/GhY41/4dZ/llelEX/mdfYH4UD89UA+wQfvTe3BJP0O6/84U/
629Dj/gXPcX/AJTtr/5zP/1q6yf6CvjR/wB7Wf5ZX/o6uwP/ALVHvX/BTe3H/KDuv/OFP+tvXv8A
gXPcX/lP2v8A5zP/ANauvf6CvjR/3tZ/llf+jq7A/wDtUe/f8FN7cf8AKDuv/OFP+tvXv+Bc9xf+
U/a/+cz/APWrr3+gr40f97Wf5ZX/AKOrsD/7VHv3/BTe3H/KDuv/ADhT/rb17/gXPcX/AJT9r/5z
P/1q66/0FfGf/vax/LK/9HV2B/8Aao9+/wCCm9uP+UHdf+cKf9bevf8AAue4v/Kdtf8Azmf/AK1d
d/6CvjR/3tZ/llf+jq7A/wDtUe/f8FN7cf8AKDuv/OFP+tvXv+Bc9xf+U/a/+cz/APWrr3+gr40f
97Wf5ZX/AKOrsD/7VHv3/BTe3H/KDuv/ADhT/rb17/gXPcX/AJT9r/5zP/1q69/oK+NH/e1n+WV/
6OrsD/7VHv3/AAU3tx/yg7r/AM4U/wCtvXv+Bc9xf+U/a/8AnM//AFq69/oK+NH/AHtZ/llf+jq7
A/8AtUe/f8FN7cf8oO6/84U/629e/wCBc9xf+U/a/wDnM/8A1q69/oK+NH/e1n+WV/6OrsD/AO1R
79/wU3tx/wAoO6/84U/629e/4Fz3F/5T9r/5zP8A9auvf6CvjR/3tZ/llf8Ao6uwP/tUe/f8FN7c
f8oO6/8AOFP+tvXv+Bc9xf8AlP2v/nM//WroxfzB2/tPa/w5/l54XZXcXU/fG36Wj+U70/ZXSeey
W5evMtPP21iZquhxeXy2HwNdPWYeZzT1atTII50ZQWAuT/2k5u2vnnmP3H5k2aOZbCaSxVRKoV6x
wMjVALDiMZ4dEHuzyjunI/Lvt1y5vEkLX8Ud8xMTFkpJOjLQkKeBzjj1Wn7nPqDuve/de697917r
3v3Xuve/de697917r3v3Xuv/1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+690dj4If8zI7w/wDFHPnR/wDAv9ke
4O+8Z/06bff+a9t/1fTqb/u6/wDT2Ni/5oXP/VlutMD3zZ66Qde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691tdda/9ulP5YH/AGsfm3/7/wCp/ebf3Sv+SVzt/wA9Nv8A
8cfrCn72X/JU5K/55rj/AKuR9BZ7y86xG697917r3v3Xuve/de697917r3v3Xuve/de6/9amhvr/
AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3XvfuvdHZ+CH/Mye8P8AxRz50f8AwL/ZHuDvvGf9Om33/mvbf9X06m/7uv8A09jY
v+aFz/1ZbrS/982eukHR+Pih/Lz7P+VPW3YfeD9q/Hr45dBdY7q27sDcfd3yd7Ll642HWdj7rx1f
mcH11tZcTt/d26d17xqcHjJ6+SmocbMlLRRmaeSNSt/de6AX5KfH3J/GjsyXrbI9o9Hdyo2Bwu5c
Z2F8eOzcV2v1nnMTnYpZaNsfufGQUUtPkYDCyVVDW01JXUrgCWFbrf3XukL1D1bu/vDtbrTpfr+k
pa/ffbW/to9bbMoq2six9HV7p3vn6DbWBp6uvn/ZoqWbKZKJZJWuI0Jaxt7917oznb/wR7F2F392
L8dup99dc/K7eHUGxewN+dpZn4+T7wyO1Nk4/qCkztd2/BkMl2HtDr2rrh1xR7dqZ66rpKeooZac
K9PNNq0j3XuiP+/de697917r3v3Xuve/de697917r3v3XutrrrX/ALdKfywP+1h82/8A3/1P7zb+
6V/ySudv+em3/wCOP1hT97L/AJKnJX/PNcf9XI+gs95edYjde9+691737r3Xvfuvde9+691737r3
Xvfuvdf/16aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+690dn4If8zJ7w/wDFHPnR/wDAv9ke4O+8Z/06bff+a9t/
1fTqb/u6/wDT2Ni/5oXP/VlutL/3zZ66QdWWfCX517B6S627H+J/ys6Io/k18KO6t4bf3/vLYOPz
02xu2er+0tt4iv21he7OhOxKeOoh272Bi9uZaejqKPI01XicxR6aapRELP7917q3vrf4ZdSfy/ov
mZ8yOi6/BfJnA4T+W9038yv5fu4+++rNvZbO7GwXyE+Q+3elsjvbtDp3OU+c2ZW9p9OU1PlqWCeS
CswTVE0ORij0skcfuvdDD8Xvkf2PvvPfyUPnnXYPq/Zfyi74+fO//hb3bv3aPSnUu1aHv/o3bG/f
jtn8PuDcWy8dsym2dS77wFVvWtw395sLQY/KCKCJWqPLFq9+691j+Gn8xP5WZr+Zr/NNp8hu/r/7
Pb3xk/mO5WgpIOh+iaGkGQ6A2Z2dP1jWVoouuqaavOKYWr1nkkjzcZK5JasfT3XugV+LPW2yv5mf
x6+FPaPee1dn5LJ9K/zLfklN8ytxbc2ZtPr2Ldfx73T0nQfL/MHcy7DxW2qWhwKY7pHd2LoUp0po
aCOqaKmEV19+6906dy9EdBdV9J/zHvmP0d0vs7aPUnzB+F/wIwXxL69agh3Ji+tt8fMjfdCe49q7
JyW5zlK3Gbg2FmPjtvGiSpSYVVNBNoWRVYj37r3Rj6/bM1V1T/MP+B3y5+RXxV7p7T+Mf8vbvDsG
P4w9NfBzaPXWN+OfdfR2ztrbqwe4Nk/J/b/XOwajNbo2TVlcfnft2q6XNtVVEbTT2Zz7r3TPuDcK
9ifzM/5Zv8rPP7e6qwvwV7N6Z/lzby7F6X230v1Ltv8Av7uLM9AbD7g3E+5ewMJsim7TyVTv3fdM
RkmjzCz1sVXJDyJCD7r3RYvml8o/il2/8VPl91x3z8sPiT332xiazamU+D+zfjn8D+wPjhunobeW
3+y8dQ7t6/o97v0d1vjH6lyHVs+QpKjG5rIZR2raOlmjkE6l5Pde61d/fuvdbXXWv/bpT+WB/wBr
D5t/+/8Aqf3m390r/klc7f8APTb/APHH6wp+9l/yVOSv+ea4/wCrkfQWe8vOsRuve/de697917r3
v3Xuve/de697917r3v3Xuv/Qpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3R2fgh/zMnvD/AMUc+dH/AMC/2R7g
77xn/Tpt9/5r23/V9Opv+7r/ANPY2L/mhc/9WW60v/fNnrpB0ef4ofzEfkb8N9t7o2P1bH0xunYG
8c5BujO7D7x+PvTHe+15Nz0tDDjKfcOOpe09lbnrMJlI6CmjiLUU9OkioutWIBHuvdLBf5r3zsPy
hyXy9q+5o8n25mdgf6H8xj8psXYFf1Pk+khSxUKdHVnSdRtluqZOn4aOBFj2+MQKCORBOqCoHm9+
690w9qfzMPlx293b0H3vuPeW08HuH4s5fBZr47bK696x6+646c6eq8Buil3pCNl9QbL27hthY9cn
umjStyLvRSTZKVR9y8ioir7r3QcdLfNr5C9A/JHcfys663PhKftvelR2W2+JNw7N2ruzZu98X3FD
l6bszbG7NhbhxWQ2pm9qbvpM5Uw1WPlpTB45AFC6VI917oR9k/zK/lT1ltn5dbJ6xz2wut9kfNmj
NB3XszYvVmwttbWp6N8fuLCT0/WeFx2Diouqo6vbe7cni5Rg1o/Jjq2WA+ki3uvdInd3zx+Te+Pi
J1Z8HNxb7pqr479Nb5q+wtibch27gqPcFDn56jd1bRw5DelLQxbozGFwNfv/ADc+Noqmpkp6GXKT
mJVuoX3XujH7y/nKfN7f2x+xtq7my/SVZuruLqzK9J9td703xt6Ox3yQ7L6vz2Iptv57au9e8cfs
em35nYs5hKOKmrKqWqNdVRxIZJ2ZVYe690UjsX5h/Ijs/ubrb5B7h7Er6DuLqDa/Te0et99bUpaH
aOZ2ni+gdt4HavVc+Ll2/T0CRZfbOJ21RgVhBqJ5ovJKzOzE+690YT5F/wA1b5bfKDrncvWXZMnR
GLw+/wCux2V7T3B1l8Yvj/1V2B23mMXkqfNU2W7I7C2F15gt37irnzVKlZOfu4kqaka5lck+/de6
rg9+691tdda/9ulP5YH/AGsPm3/7/wCp/ebf3Sv+SVzt/wA9Nv8A8cfrCn72X/JU5K/55rj/AKuR
9BZ7y86xG697917r3v3Xuve/de697917r3v3Xuve/de6/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3r
rfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdHZ+CH
/Mye8P8AxRz50f8AwL/ZHuDvvGf9Om33/mvbf9X06m/7uv8A09jYv+aFz/1ZbrS/982eukHXvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdbXXWv/bpT+WB/wBrD5t/+/8A
qf3m390r/klc7f8APTb/APHH6wp+9l/yVOSv+ea4/wCrkfQWe8vOsRuve/de697917r3v3Xuve/d
e697917r3v3Xuv/Spob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Q7/HLvjI/HLsl+xKDY+zOyaeu2R2D13uDYvY
MeXm2jufaPZu0spsrdmIzEeCyOJypgrcDmJ4/wBqoib1fX2Eud+T9v585cvOWd0uZorOZ42LRaQ4
MbhxTUGGSM1HDoWckc33/IvMdpzLtlvFLeQpIoWQMUIkUoa6SpwDjPHpWf6UvhH/AN6g/gB/yR8h
P/ty+4J/4FDkf/pot1/bB/1q6nT/AIKrnX/owbX/ALzN/wBbevf6UvhH/wB6g/gB/wAkfIT/AO3L
79/wKHI//TRbr+2D/rV17/gqudf+jBtf+8zf9buvf6UvhH/3qD+AH/JHyE/+3L79/wAChyP/ANNF
uv7YP+tXXv8Agqudf+jBtf8AvM3/AFu69/pS+Ef/AHqD+AH/ACR8hP8A7cvv3/Aocj/9NFuv7YP+
tXXv+Cq51/6MG1/7zN/1u69/pS+Ef/eoP4Af8kfIT/7cvv3/AAKHI/8A00W6/tg/61de/wCCq51/
6MG1/wC8zf8AW7r3+lL4R/8AeoP4Af8AJHyE/wDty+/f8ChyP/00W6/tg/61de/4KrnX/owbX/vM
3/W7r3+lL4R/96g/gB/yR8hP/ty+/f8AAocj/wDTRbr+2D/rV17/AIKrnX/owbX/ALzN/wBbuvf6
UvhH/wB6g/gB/wAkfIT/AO3L79/wKHI//TRbr+2D/rV17/gqudf+jBtf+8zf9buvf6UvhH/3qD+A
H/JHyE/+3L79/wAChyP/ANNFuv7YP+tXXv8Agqudf+jBtf8AvM3/AFu69/pS+Ef/AHqD+AH/ACR8
hP8A7cvv3/Aocj/9NFuv7YP+tXXv+Cq51/6MG1/7zN/1u69/pS+Ef/eoP4Af8kfIT/7cvv3/AAKH
I/8A00W6/tg/61de/wCCq51/6MG1/wC8zf8AW7pt7u+QWE7W2R091fsXoDp344dX9IU++4tldf8A
TEe8EwCVPY2fpdzboyFY289ybnyUlXWZel8txOFBkbgCwEse2/tfsvtjbbrbbNf3U63bozmYoSCg
IGnQqilGzXqKfcf3P3n3Mudrud4sbaBrRHVBCHAIcqTq1s3AqKUp59Fu9yX1GvXvfuvde9+69173
7r3Xvfuvde9+691737r3X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691//1KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf
/9Wmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Wpob6/wDI
K/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//2aBGHfAEngAABE0yIY2T
pTBiwhzVISqmUf//2P/gABBKRklGAAECAQEsASwAAP/hFANFeGlmAABNTQAqAAAACAAHARIAAwAA
AAEAAQAAARoABQAAAAEAAABiARsABQAAAAEAAABqASgAAwAAAAEAAgAAATEAAgAAABwAAAByATIA
AgAAABQAAACOh2kABAAAAAEAAACkAAAA0AAtxsAAACcQAC3GwAAAJxBBZG9iZSBQaG90b3Nob3Ag
Q1MyIFdpbmRvd3MAMjAwNjowNDoyMCAxMjo0MzowMAAAAAADoAEAAwAAAAH//wAAoAIABAAAAAEA
AADUoAMABAAAAAEAAABxAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAR4BGwAFAAAAAQAA
ASYBKAADAAAAAQACAAACAQAEAAAAAQAAAS4CAgAEAAAAAQAAEs0AAAAAAAAASAAAAAEAAABIAAAA
Af/Y/+AAEEpGSUYAAQIAAEgASAAA/+0ADEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAM
CAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwM
DAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDAz/wAARCABVAKADASIAAhEBAxEB/90ABAAK/8QBPwAAAQUBAQEBAQEAAAAA
AAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYI
BQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkST
VGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3
x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJD
UxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaG
lqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDnnOduOp5PdLc7xP3pO+kfiUy33BX3O8T9
6W53ifvTJJIX3O8T96W53ifvTcalTfTdXWy2yp9ddv8ANWPY5rXf8W9wDX/2UtE0WO53ifvS3O8T
96ZJJC+53ifvS3O8T96ZSrrstsbXUx1lj9GsYC5x/qsZLnJJ1W3O8T96W53ifvSex9bzXY11djdH
MeC1w/rNfDkyStV9zvE/elud4n70ySSF9zvE/elud4n70ySSl9zvE/elud4n70ySSl9zvE/ek1zt
w1PI7pk7fpD4hJL/AP/Q5530j8SrNfTy6mu1+RRULQXMbY5wdAc6vsx35zFWP0j8SrOV/RcH/iXf
+fbVs5zO8UYS4OOfCZUJekYsuT9L/ZuNhEP1kpx4+GNgXw68cIfo/wB5l+z2f9zcX/Pd/wCkkd3S
KG9Nsy/tTHvYTGwyzT/B67X+o5ZiYlo5IHxTJ4OYlwcPMyjwzjKXoxy9yEfmx/1eP95fDNgHFfLi
VxMY+ufokfln/gup9WManL+sXT8e9ofU+0ucw6g+mx9zWuH5zd9bUujdX6t1G7Kr6jl25dOdh5Tr
qbXF1Yeyp+XVZTSf0dD6bqmej6Oz01nY+XbiZFWXjWBl+O8WVO0I3N/eH5zXfRerOR1fHZi5Temd
LrwcnLpfTbeLn3NbXaP1lmFjWMbXi+v9H6d3o1fo6U7NAmRPDxXGo/1JfvJwSAiBxcNSuX9ePZvW
9P6Uc2zotNV7c1mL9pqzX2tdW+z7O3qBpuxvSZ6VLml9fqV2eorlv1VNe/E+yZQLMc3ftk21jGNg
p+0+icXbvbjbv0Hqb/W9VVeu9YwKuqZR6diMszX41eOOqDIc9gD8evHufRiVtFLL66j6G/1/Z/o1
nZfUMDNa67O6TXkdTsqFb8032tY5zGimvIswWDZ63pMbu/WPT9T9J6ahBzkRI4qrX+93+b5WYjAC
QeG+n93t/edPE6b0jJ6njdCFWQzLy8Zl7M43NLG2PxjnbHYgp/mPbs/nfVVDofVqMfHyqbrrcAdR
qqYzqOOC63HLH+t9GtzLnY1/0Mn0Xep7GJ8Prz6OuY3WhQLHYtTKfQ9SA7ZjuwN5t9P2bt/rbfS/
4P8A4RVOnW4eJWa8zCGewta1o9Z9D2Fv59dlXqN9/wCeyyqxSCMzGQnxEGMT48d61xMfHjEomHCC
CR/gOm/p+S37Vn9dyLOo0YONVZTbTeLPtDLrfQxm0Zloe5mM251vrez1q01vTsB/TH9Wx22VUXYd
99WPY/e6q7HyMbEsb6rWV+tjury/0ft3oH7dJAxfsDP2MKPs/wCzPWsmDb9t+0fbv537X9q/Sep6
Xpf4P0Uh1yHtpHT2DpLMazE/ZxueSW3PZk33/btvq/an5FNT/V9HZsZ6fpJo94VQIo7D5eDtX764
+wbsg33+bi73+63cTpHTX9Ix+pZAuf8AqfUM26uuwM3nCuoopqa91dnpMfXe71FWyn9BxsPFzH4e
U/8AaVdlzKGZLR9nrrf9nbttfQ/7VbdZXbZ+kaxlTP0f8tJ/1inFODjdPbjYgwsrCrYb32vacx9N
9+Q+6ytvq7H43sp2Vfzn84q9HVcQ4VGHn9OZ1AYYe3FsF9lDmstJsfTf6DXfaavVd6lfvp2JAZiS
ZcVcWwOvAonAAIx4brWVfpO5j/VTe7Gw34eW45FLLLOsNsrbj1W2Vm5lYxCC+3Frca6rbH2V3f6N
ctU/1K2viJEwrr+pYGSK7eo9Iqzc+uptP2o321seK2iuh+TiUj9NYytu1/6xV6qpMbtaB4KXB7ly
47+v7GHmPbqPBX0ZJJJKZrqTt+kPiEydv0h8Qkp//9Hnj9I/Eqzlf0XB/wCJd/59tVY/SPxKs5X9
Fwf+Jd/59tWzl+fB/tD/AO6+dxcfyZv7g/8ASuNqq/0vr/7GqyD+zsfqBt2uByB9HYHaN9j/AKW5
UFG3+af/AFT+RSTgJxMTsVuOZjISD331o63i9Exek30dGwr3dSqdZa17GtDNrabIYW1nd/PrFxPq
V9Yurss6mKaMJmU991WPY5zSGvPqMZWxlb/Tr936P1Nis/X/AGfZPqv6kemanB86Dbtw9+7+yrf+
MH/muet4x65kdTpyK6A/E+yFgqb737rqfUa5zMvexnqvb+Z9nWdCcscY8HzTMrJ9WkP6rpSxxyGQ
n8sOHb0/M8oei9TZ1T9kHGcOoEwKARqCN3qCz+b9Hb7vVV/rP1L630zpeTnXOx7K8esuuZVYS9gI
5c19dbf+kun6F9YOl/WD66VZeC2yKumW1l9zQwucL6S304c7d7Tb9FeZZFQLsyy8n7W593rlx/SF
+5/qi387dv8Ap7lYhmy5JCIAhwgGQI3YJYMWMcR4p3Ko1+i+n/XP6rdW6z1fGuwzRVjVUem6y55a
C8vJbW1tbLH/AEVx9n1b6xV1lnRHVN+22NL6vfFb2AEm1lhH0fY78z1Fo/42qWXdZxRZ7g3CeWg6
gHe73NH7y6PLJ/56fVcky52FlbnHUn9GzkqHHmyY8cdjEiXD4GLLkwY8mSW4kDHi+rztn+L36wsY
4sdi3WsEmhlrhZ/4JWyv/OsWT0jofU+s5L8bCq99P8+632Nq1Ldt2hd6m5v81t9RaH1dqaz/ABm2
2M9rn5+e18aSNuU7a795u5rXLVyDc36qfXJ2NuZd+08kPdXo705xvWnb+Z9ndbv/AODTzzOWOh4S
ZCJia+XjWDlsUtY8QETISH73C8/9Yvqp1roeE/Jy2Msxo2m+hxc1rnaM9UPbXYzc7279np71uf4w
8fJy/rN07CxKzbddjFtdTeSd7v7LWNb7nvd7K1S+rTNv1B+s9bjOE2qw0A6sFno7n+l/K9T0Xf11
2FwYf8YmNuiR0m0snx9evdt/sqOeeYyDioyxcW20uIMkMGM4zw2I5K33FPHZX1A+smNinJ2U5G0b
nUUvLrYHO1r62Msd/Irf/UWd0T6v9T665/2BjfSrj1L7Xba2kjc1sgPe9+39xn9dXPqF9t/57Pe9
1hyLDlDqId9KGl39JH5uzI9LatHq2wfUXrjcaG1nrGQ2/ZEbPtYbD/3Wen6Lf+L/AJCkPM5YngPC
ZS4TGXbjYxy2KXqHEIxMhKPfhaGZ9SetYdTL7LMV+O+yuo3stOxpte3HY9++tn6P1bGb9izOsdJz
OjZ5wMva6/Y2xpqJLXNeXNZs3trd/OMfX9FauBTWz/FX1tlMN/WpG3T3bsKOFs9Qxh1/qn1R6w0S
MsRlGPaDS39oemf+u05NaI5nJGRE6IiZRJA6xjxBB5XHKIMLBIEhZ8dXleudEyuh5VWJmW0vuuZ6
obS5zobOwF/qMq+m7dtVBv0h8QtL62Zx6h9a+oXAk147xiVT2FPst/8AZn11mt+kPiFZwylLHGUv
mIauaMY5JRjsH//S54/SPxKs5X9Fwf8AiXf+fbVWP0j8Srr8d2RiYhrsqGytzXh9rGEH1LHfRe5r
vouWxzE4wlglIiMRkNyloP5jO42GJkMoiLJhsP8Aa42imcNzS09wR96t/s67/SUf9v1f+TS/Z13+
ko/7fq/8mj965f8AzuP/AB4o+75v83L7GXV+tdQ61Xh0ZtdLKunsdXT6QcC5rxWx3q+o+z82lv0F
fxvrx17GxK8O+nF6lVSAKX5TCbBA2s3va7bZtb+fs9X9+xZ37Ou/0lH/AG/V/wCTS/Z1/wDpKP8A
t+r/AMmojLkzER9zHQNj1x6sw+9CRlwy1FH09kt/1k67k9Xq6259dObjsFdIqZFYr926l1b3PdYx
/qP3bnqz1X66db6pg5GDZi4mO3NZ6eVfSx3qPHHtNj3bfb+/6qo/s67/AElH/b9X/k0dnRMh2HZk
+rX+jkhrXB4Ib9L9KwljVHkzchDgMssBrHHGpcXql8o9C/HHnZGQjCR0MzpWkfm+ZD13rXUPrBlN
yeoMqqfXUaWigOA2kl8u9V9vu1Vmz649Xt6pgdS9LF9fptVlWOwCza5trW1vdb+l3O2tb7djlD6u
UY+R1zFryaxdSPVtdU76LvSqtvYx/wDI9Stm9APWevdXqrxszLOQ3IsrLK3tYGtscdlfplrN1Ffv
/wAEp5Y4WMfBpEXv8omxxyT4Tk46MjwgAbyith9WzsPrB65Wyo5rrrsjY4O9LdeLG2N2h4s2N9d+
z9Ij9O+s3XOm9SzOp4pq9TqFhtysZzXGlziSQWt3i1np7vY71f8AjN6v5v1bqqrz2Y9fUGXdLqsu
tysrHFeHe2k/rDcSyN7HbP0mN+ku9f0/+uIVHS+ib+l4eVdmDO6xVXbTZU2o0VG5zqaW2ss/T2+9
n6Xa5NJ5eQur04Nv0R6lwjzMTVga8e/UtXrn1m6z13C/ZlrKcHp0y7HxWlu4j3N9RznH2Ns/SbGM
Z70uo/WbrfUOr43WHGrFzMJhZQ+hrtsEku9Rlz7d+/dse1WumVdD/YPWLeoU5D8rBfRXZbS6v2l9
z6WfY/Vb7N+zbler/OV/zWxSwPq/VdjYJyKuo2XdTa19d+Hji3Gx2ve6qt2XYQfU+j617GWVelSm
gcvG7jXCa/vcUeJd/SZVUh6hdD9HhZZX+MD6y3021004mHdkDbdl0sd6pA9rXM9R7mte1v0fU9ZT
+pNX1groyqei34VtbzGR0zOc79JLWg5Fba/d72fobH/Qs/wqo04HTsXGy8jrDsgnEzv2cacL05Ng
a+19psyf8H+hesiymq4yWyATsJ+kB+bx+cnezjlGUcY7akWFpzZYSjLIdNfSDq+g9fdlVfVSzo3U
mYGF1PquTVRg4eGS1kOtoiy3cN3s22PvvbX6ez0/8Ii9HPWPqf0LMPW7MUYOI17unsYXOtfc8vs9
AOIq9llv81Xs9b9LZ+k9Ji83biUNJO0Eu0JOshIYlIcHRJHE6x8Ez7nLh4TIUTxS0/6K/wC+Q4uI
RNgcI1XxmvFQNh3WO9z3HUlx9zz/AJyM36Q+ITJ2/SHxCugUAOzRJsk9y//T5530j8SmTu+kfiUy
33AVASgJJI2VKgJQEkkrKlQFIW2trdU17hW7VzASGk/ymqKSBAO+vXXuEgkbGumifAzr+nZ1Gfjt
a+3HcSGP1a5rmuqtqf8AybKrHsStyel1tYel42Tj5DHtsY7IuZZXXsd6ja6WV1Vvtb9H35D0BJNl
jBlxa3VHxC+OWUY8OhF2L/RPg3eodR6bm2ZOT9mzGZmWXPfW7KBxWWP1fbTU2v17G7tz/Qtf6f8A
YT/tZn7Q6Nl+i7b0irHqe2RNhosfc51f7u/f+eqKSYMEAK1XS5iZ7dPwbuD1LFqo6niZlFz8bqr2
WE0PY22t1Vr8qofpmuqexzrNlqTep4duLi1dRpzH3YNXoVOxMkU12Vhzra68muyuzY6ve9nq0e/Y
qSSRwQPfofs9KRzMx269O/qSnLYel2dPbU5ptzm5rXbtwa1tVmP6LnO/SPf+l/nUJJJPjARuuurH
OZnV9BSkkkk5YpO36Q+ITJ2/SHxCSn//1OecBuOvc9v9qUDxP3f7VxaS33Be0geJ+7/alA8T93+1
cWkkp7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJKe0geJ+7/AGpQPE/d/tXFpJKe0geJ
+7/alA8T93+1cWkkp7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJKe0geJ+7/AGpQPE/d
/tXFpJKe0geJ+7/ak0DcNe47f7VxaSSn/9n/7Ro8UGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAcc
AgAAAgACADhCSU0EJQAAAAAAEEYM8okmuFbasJwBobCnkHc4QklNA+0AAAAAABABLAAAAAEAAQEs
AAAAAQABOEJJTQQmAAAAAAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAAB4OEJJTQQZAAAA
AAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB
AAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA
MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP//////////
//////////////////8D6AAAAAD/////////////////////////////A+gAAAAA////////////
/////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAAC
AAM4QklNBAIAAAAAAAoAAAAAAAAAAAAAOEJJTQQwAAAAAAAFAQEBAQEAOEJJTQQtAAAAAAAGAAEA
AAAKOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAA
A00AAAAGAAAAAAAAAAAAAABxAAAA1AAAAAwAbwB0AGMAXwBsAG8AZwBvAF8AbgBlAHcAAAABAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAANQAAABxAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA
AAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj
dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAABxAAAA
AFJnaHRsb25nAAAA1AAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA
B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp
Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt
ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm
dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAcQAAAABSZ2h0bG9uZwAAANQAAAADdXJsVEVYVAAAAAEA
AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA
AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln
bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F
U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD
b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA
AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklNBCgA
AAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAABI4QklNBAwAAAAA
EukAAAABAAAAoAAAAFUAAAHgAACfYAAAEs0AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRv
YmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgR
DAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4U
EQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAFUAoAMBIgAC
EQEDEQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAA
AAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFC
IyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE
1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyEx
EgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl
4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhED
EQA/AOec5246nk90tzvE/ek76R+JTLfcFfc7xP3pbneJ+9Mkkhfc7xP3pbneJ+9NxqVN9N1dbLbK
n112/wA1Y9jmtd/xb3ANf/ZS0TRY7neJ+9Lc7xP3pkkkL7neJ+9Lc7xP3plKuuy2xtdTHWWP0axg
LnH+qxkucknVbc7xP3pbneJ+9J7H1vNdjXV2N0cx4LXD+s18OTJK1X3O8T96W53ifvTJJIX3O8T9
6W53ifvTJJKX3O8T96W53ifvTJJKX3O8T96TXO3DU8jumTt+kPiEkv8A/9DnnfSPxKs19PLqa7X5
FFQtBcxtjnB0Bzq+zHfnMVY/SPxKs5X9Fwf+Jd/59tWznM7xRhLg458JlQl6Riy5P0v9m42EQ/WS
nHj4Y2BfDrxwh+j/AHmX7PZ/3Nxf893/AKSR3dIob02zL+1Me9hMbDLNP8Hrtf6jlmJiWjkgfFMn
g5iXBw8zKPDOMpejHL3IR+bH/V4/3l8M2AcV8uJXExj65+iR+Wf+C6n1Yxqcv6xdPx72h9T7S5zD
qD6bH3Na4fnN31tS6N1fq3UbsqvqOXbl052HlOuptcXVh7Kn5dVlNJ/R0PpuqZ6Po7PTWdj5duJk
VZeNYGX47xZU7Qjc394fnNd9F6s5HV8dmLlN6Z0uvBycul9Nt4ufc1tdo/WWYWNYxteL6/0fp3ej
V+jpTs0CZE8PFcaj/Ul+8nBICIHFw1K5f149m9b0/pRzbOi01XtzWYv2mrNfa11b7Ps7eoGm7G9J
npUuaX1+pXZ6iuW/VU178T7JlAsxzd+2TbWMY2Cn7T6Jxdu9uNu/Qepv9b1VV671jAq6plHp2Iyz
NfjV446oMhz2APx68e59GJW0UsvrqPob/X9n+jWdl9QwM1rrs7pNeR1OyoVvzTfa1jnMaKa8izBY
Nnrekxu79Y9P1P0npqEHOREjiqtf73f5vlZiMAJB4b6f3e39508TpvSMnqeN0IVZDMvLxmXszjc0
sbY/GOdsdiCn+Y9uz+d9VUOh9Wox8fKpuutwB1GqpjOo44Lrccsf630a3MudjX/QyfRd6nsYnw+v
Po65jdaFAsdi1Mp9D1IDtmO7A3m30/Zu3+tt9L/g/wDhFU6dbh4lZrzMIZ7C1rWj1n0PYW/n12Ve
o33/AJ7LKrFIIzMZCfEQYxPjx3rXEx8eMSiYcIIJH+A6b+n5LftWf13Is6jRg41VlNtN4s+0Mut9
DGbRmWh7mYzbnW+t7PWrTW9OwH9Mf1bHbZVRdh331Y9j97qrsfIxsSxvqtZX62O6vL/R+3egft0k
DF+wM/Ywo+z/ALM9ayYNv237R9u/nftf2r9J6npel/g/RSHXIe2kdPYOksxrMT9nG55Jbc9mTff9
u2+r9qfkU1P9X0dmxnp+kmj3hVAijsPl4O1fvrj7BuyDff5uLvf7rdxOkdNf0jH6lkC5/wCp9Qzb
q67AzecK6iimpr3V2ekx9d7vUVbKf0HGw8XMfh5T/wBpV2XMoZktH2eut/2du219D/tVt1ldtn6R
rGVM/R/y0n/WKcU4ON09uNiDCysKthvfa9pzH0335D7rK2+rsfjeynZV/Ofzir0dVxDhUYef05nU
Bhh7cWwX2UOay0mx9N/oNd9pq9V3qV++nYkBmJJlxVxbA68CicAAjHhutZV+k7mP9VN7sbDfh5bj
kUsss6w2ytuPVbZWbmVjEIL7cWtxrqtsfZXd/o1y1T/Ura+IkTCuv6lgZIrt6j0irNz66m0/ajfb
Wx4raK6H5OJSP01jK27X/rFXqqkxu1oHgpcHuXLjv6/sYeY9uo8FfRkkkkpmupO36Q+ITJ2/SHxC
Sn//0eeP0j8SrOV/RcH/AIl3/n21Vj9I/Eqzlf0XB/4l3/n21bOX58H+0P8A7r53Fx/Jm/uD/wBK
42qr/S+v/sarIP7Ox+oG3a4HIH0dgdo32P8ApblQUbf5p/8AVP5FJOAnExOxW45mMhIPffWjreL0
TF6TfR0bCvd1Kp1lrXsa0M2tpshhbWd38+sXE+pX1i6uyzqYpowmZT33VY9jnNIa8+oxlbGVv9Ov
3fo/U2Kz9f8AZ9k+q/qR6ZqcHzoNu3D37v7Kt/4wf+a563jHrmR1OnIroD8T7IWCpvvfuup9RrnM
y97Geq9v5n2dZ0JyxxjwfNMysn1aQ/qulLHHIZCfyw4dvT8zyh6L1NnVP2QcZw6gTAoBGoI3eoLP
5v0dvu9VX+s/UvrfTOl5Odc7Hsrx6y65lVhL2AjlzX11t/6S6foX1g6X9YPrpVl4LbIq6ZbWX3ND
C5wvpLfThzt3tNv0V5lkVAuzLLyftbn3euXH9IX7n+qLfzt2/wCnuViGbLkkIgCHCAZAjdglgxYx
xHincqjX6L6f9c/qt1brPV8a7DNFWNVR6brLnloLy8ltbW1ssf8ARXH2fVvrFXWWdEdU37bY0vq9
8VvYASbWWEfR9jvzPUWj/japZd1nFFnuDcJ5aDqAd7vc0fvLo8sn/np9VyTLnYWVucdSf0bOSoce
bJjxx2MSJcPgYsuTBjyZJbiQMeL6vO2f4vfrCxjix2LdawSaGWuFn/glbK/86xZPSOh9T6zkvxsK
r30/z7rfY2rUt23aF3qbm/zW31FofV2prP8AGbbYz2ufn57XxpI25Ttrv3m7mtctXINzfqp9cnY2
5l37TyQ91ejvTnG9adv5n2d1u/8A4NPPM5Y6HhJkImJr5eNYOWxS1jxARMhIfvcLz/1i+qnWuh4T
8nLYyzGjab6HFzWudoz1Q9tdjNzvbv2envW5/jDx8nL+s3TsLErNt12MW11N5J3u/stY1vue93sr
VL6tM2/UH6z1uM4TarDQDqwWejuf6X8r1PRd/XXYXBh/xiY26JHSbSyfH16923+yo555jIOKjLFx
bbS4gyQwYzjPDYjkrfcU8dlfUD6yY2KcnZTkbRudRS8utgc7WvrYyx38it/9RZ3RPq/1Prrn/YGN
9KuPUvtdtraSNzWyA9737f3Gf11c+oX23/ns973WHIsOUOoh30oaXf0kfm7Mj0tq0erbB9ReuNxo
bWesZDb9kRs+1hsP/dZ6fot/4v8AkKQ8zlieA8JlLhMZduNjHLYpeocQjEyEo9+FoZn1J61h1Mvs
sxX477K6jey07Gm17cdj3762fo/VsZv2LM6x0nM6NnnAy9rr9jbGmoktc15c1mze2t384x9f0Vq4
FNbP8VfW2Uw39akbdPduwo4Wz1DGHX+qfVHrDRIyxGUY9oNLf2h6Z/67Tk1ojmckZEToiJlEkDrG
PEEHlccogwsEgSFnx1eV650TK6HlVYmZbS+65nqhtLnOhs7AX+oyr6bt21UG/SHxC0vrZnHqH1r6
hcCTXjvGJVPYU+y3/wBmfXWa36Q+IVnDKUscZS+Yhq5oxjklGOwf/9Lnj9I/Eqzlf0XB/wCJd/59
tVY/SPxKuvx3ZGJiGuyobK3NeH2sYQfUsd9F7mu+i5bHMTjCWCUiIxGQ3KWg/mM7jYYmQyiIsmGw
/wBrjaKZw3NLT3BH3q3+zrv9JR/2/V/5NL9nXf6Sj/t+r/yaP3rl/wDO4/8AHij7vm/zcvsZdX61
1DrVeHRm10sq6ex1dPpBwLmvFbHer6j7PzaW/QV/G+vHXsbErw76cXqVVIApflMJsEDaze9rttm1
v5+z1f37Fnfs67/SUf8Ab9X/AJNL9nX/AOko/wC36v8AyaiMuTMRH3MdA2PXHqzD70JGXDLUUfT2
S3/WTruT1errbn105uOwV0ipkViv3bqXVvc91jH+o/duerPVfrp1vqmDkYNmLiY7c1np5V9LHeo8
ce02Pdt9v7/qqj+zrv8ASUf9v1f+TR2dEyHYdmT6tf6OSGtcHghv0v0rCWNUeTNyEOAyywGsccal
xeqXyj0L8cedkZCMJHQzOlaR+b5kPXetdQ+sGU3J6gyqp9dRpaKA4DaSXy71X2+7VWbPrj1e3qmB
1L0sX1+m1WVY7ALNrm2tbW91v6Xc7a1vt2OUPq5Rj5HXMWvJrF1I9W11Tvou9Kq29jH/AMj1K2b0
A9Z691eqvGzMs5Dciyssre1ga2xx2V+mWs3UV+//AASnljhYx8GkRe/yibHHJPhOTjoyPCABvKK2
H1bOw+sHrlbKjmuuuyNjg70t14sbY3aHizY3137P0iP076zdc6b1LM6nimr1OoWG3KxnNcaXOJJB
a3eLWenu9jvV/wCM3q/m/VuqqvPZj19QZd0uqy63KyscV4d7aT+sNxLI3sds/SY36S71/T/64hUd
L6Jv6Xh5V2YM7rFVdtNlTajRUbnOppbayz9Pb72fpdrk0nl5C6vTg2/RHqXCPMxNWBrx79S1eufW
brPXcL9mWspwenTLsfFaW7iPc31HOcfY2z9JsYxnvS6j9Zut9Q6vjdYcasXMwmFlD6Gu2wSS71GX
Pt3792x7Va6ZV0P9g9Yt6hTkPysF9FdltLq/aX3PpZ9j9Vvs37NuV6v85X/NbFLA+r9V2NgnIq6j
Zd1NrX134eOLcbHa97qq3ZdhB9T6PrXsZZV6VKaBy8buNcJr+9xR4l39JlVSHqF0P0eFllf4wPrL
fTbXTTiYd2QNt2XSx3qkD2tcz1Hua17W/R9T1lP6k1fWCujKp6LfhW1vMZHTM5zv0ktaDkVtr93v
Z+hsf9Cz/CqjTgdOxcbLyOsOyCcTO/ZxpwvTk2Br7X2mzJ/wf6F6yLKarjJbIBOwn6QH5vH5yd7O
OUZRxjtqRYWnNlhKMsh019IOr6D192VV9VLOjdSZgYXU+q5NVGDh4ZLWQ62iLLdw3ezbY++9tfp7
PT/wiL0c9Y+p/Qsw9bsxRg4jXu6exhc619zy+z0A4ir2WW/zVez1v0tn6T0mLzduJQ0k7QS7Qk6y
EhiUhwdEkcTrHwTPucuHhMhRPFLT/or/AL5Di4hE2BwjVfGa8VA2HdY73PcdSXH3PP8AnIzfpD4h
Mnb9IfEK6BQA7NEmyT3L/9PnnfSPxKZO76R+JTLfcBUBKAkkjZUqAlASSSsqVAUhba2t1TXuFbtX
MBIaT/KaopIEA769de4SCRsa6aJ8DOv6dnUZ+O1r7cdxIY/Vrmua6q2p/wDJsqsexK3J6XW1h6Xj
ZOPkMe2xjsi5lldex3qNrpZXVW+1v0ffkPQEk2WMGXFrdUfEL45ZRjw6EXYv9E+Dd6h1HpubZk5P
2bMZmZZc99bsoHFZY/V9tNTa/Xsbu3P9C1/p/wBhP+1mftDo2X6LtvSKsep7ZE2Gix9znV/u79/5
6opJgwQArVdLmJnt0/Bu4PUsWqjqeJmUXPxuqvZYTQ9jba3VWvyqh+ma6p7HOs2WpN6nh24uLV1G
nMfdg1ehU7EyRTXZWHOtrrya7K7Njq972erR79ipJJHBA9+h+z0pHMzHbr07+pKcth6XZ09tTmm3
Obmtdu3BrW1WY/ouc79I9/6X+dQkkk+MBG666sc5mdX0FKSSSTlik7fpD4hMnb9IfEJKf//U55wG
469z2/2pQPE/d/tXFpLfcF7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJKe0geJ+7/alA
8T93+1cWkkp7SB4n7v8AalA8T93+1cWkkp7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJ
Ke0geJ+7/alA8T93+1cWkkp7SB4n7v8AalA8T93+1cWkkp7SB4n7v9qTQNw17jt/tXFpJKf/2QA4
QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEA
ZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwACAAQwBTADIAAAABADhCSU0PoAAAAAAA+G1hbmlJ
UkZSAAAA7DhCSU1BbkRzAAAAzAAAABAAAAABAAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAA
AAAAAEZySW5WbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAEAAAAARnJJRGxvbmcwj+N7AAAA
AEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAQAAAAARnNJRGxvbmcAAAAAAAAAAEFG
cm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFsb25nMI/jewAAAABMQ250bG9uZwAAAAAAADhCSU1S
b2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAcbWZyaQAAAAIAAAAQAAAAAQAAAAAAAAABAAAAADhC
SU0EBgAAAAAABwAGAAAAAQEA/+E6eGh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFj
a2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0
YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLjEtMTExIj4KICAgPHJkZjpS
REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMj
Ij4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6
eGFwTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iCiAgICAgICAgICAgIHhtbG5z
OnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIj4K
ICAgICAgICAgPHhhcE1NOkRvY3VtZW50SUQ+dXVpZDo1N0E4RTc0OEE1RDBEQTExOUM3QzgyMUIy
NDFDQTQzQjwveGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVp
ZDo1OEE4RTc0OEE1RDBEQTExOUM3QzgyMUIyNDFDQTQzQjwveGFwTU06SW5zdGFuY2VJRD4KICAg
ICAgICAgPHhhcE1NOkRlcml2ZWRGcm9tIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAg
ICAgICAgPHN0UmVmOmluc3RhbmNlSUQ+dXVpZDoyNEFDNTFGMUEwRDBEQTExOUM3QzgyMUIyNDFD
QTQzQjwvc3RSZWY6aW5zdGFuY2VJRD4KICAgICAgICAgICAgPHN0UmVmOmRvY3VtZW50SUQ+YWRv
YmU6ZG9jaWQ6cGhvdG9zaG9wOjk1ZTc3MDIwLThjZTYtMTFkOS1iYjI5LWUyYjM5MzI0MjA0NDwv
c3RSZWY6ZG9jdW1lbnRJRD4KICAgICAgICAgPC94YXBNTTpEZXJpdmVkRnJvbT4KICAgICAgPC9y
ZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAg
ICAgICAgIHhtbG5zOnRpZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgICAg
ICAgPHRpZmY6T3JpZW50YXRpb24+MTwvdGlmZjpPcmllbnRhdGlvbj4KICAgICAgICAgPHRpZmY6
WFJlc29sdXRpb24+MzAwMDAwMC8xMDAwMDwvdGlmZjpYUmVzb2x1dGlvbj4KICAgICAgICAgPHRp
ZmY6WVJlc29sdXRpb24+MzAwMDAwMC8xMDAwMDwvdGlmZjpZUmVzb2x1dGlvbj4KICAgICAgICAg
PHRpZmY6UmVzb2x1dGlvblVuaXQ+MjwvdGlmZjpSZXNvbHV0aW9uVW5pdD4KICAgICAgICAgPHRp
ZmY6TmF0aXZlRGlnZXN0PjI1NiwyNTcsMjU4LDI1OSwyNjIsMjc0LDI3NywyODQsNTMwLDUzMSwy
ODIsMjgzLDI5NiwzMDEsMzE4LDMxOSw1MjksNTMyLDMwNiwyNzAsMjcxLDI3MiwzMDUsMzE1LDMz
NDMyO0JFNzhDMUVFM0QxQUM1OEFBQUJBMjIwNjVBQTQxM0ExPC90aWZmOk5hdGl2ZURpZ2VzdD4K
ICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0
PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+
CiAgICAgICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDA2LTA0LTIwVDEyOjQzLTA3OjAwPC94YXA6TW9k
aWZ5RGF0ZT4KICAgICAgICAgPHhhcDpDcmVhdG9yVG9vbD5BZG9iZSBQaG90b3Nob3AgQ1MyIFdp
bmRvd3M8L3hhcDpDcmVhdG9yVG9vbD4KICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDYtMDQt
MjBUMTI6NDMtMDc6MDA8L3hhcDpDcmVhdGVEYXRlPgogICAgICAgICA8eGFwOk1ldGFkYXRhRGF0
ZT4yMDA2LTA0LTIwVDEyOjQzLTA3OjAwPC94YXA6TWV0YWRhdGFEYXRlPgogICAgICA8L3JkZjpE
ZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAg
ICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8
ZXhpZjpDb2xvclNwYWNlPi0xPC9leGlmOkNvbG9yU3BhY2U+CiAgICAgICAgIDxleGlmOlBpeGVs
WERpbWVuc2lvbj4yMTI8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhl
bFlEaW1lbnNpb24+MTEzPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6TmF0
aXZlRGlnZXN0PjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3NTEw
LDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2LDM3
Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3Mzg2
LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1LDQx
NzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQxOTkx
LDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwxMCwx
MSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDsyRDhDNUQ0
MkY1QjFFRDAyN0RBOTMzQ0QxMzFGQTJBNjwvZXhpZjpOYXRpdmVEaWdlc3Q+CiAgICAgIDwvcmRm
OkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAg
ICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAg
ICA8ZGM6Zm9ybWF0PmltYWdlL2pwZWc8L2RjOmZvcm1hdD4KICAgICAgPC9yZGY6RGVzY3JpcHRp
b24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5z
OnBob3Rvc2hvcD0iaHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyI+CiAgICAgICAg
IDxwaG90b3Nob3A6Q29sb3JNb2RlPjM8L3Bob3Rvc2hvcDpDb2xvck1vZGU+CiAgICAgICAgIDxw
aG90b3Nob3A6SGlzdG9yeS8+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+
CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4A
DkFkb2JlAGRAAAAAAf/bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYFBQUFBQUGBgcH
CAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQoJCg0PDg4ODg8PDAwMDAwPDwwM
DAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAcQDUAwERAAIRAQMRAf/dAAQA
G//EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAAAQACAwQF
BgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPBUtHhMxZi
8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE1OT0ZXWF
laW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZqbnJ2en5
KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEyobHwFMHR
4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp0+PzhJSk
tMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+DlJWWl5
iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A8f3FxcfWJ/38n94/7R8T759CxiKf
n2Ujaj9ZuP8Af8n/AAR/rh4Qx4j3u+s3H+/5P+CP9ceELxHvd9ZuP9/yf8Ef648IXiPe76zcf7/k
/wCCP9ceELxHvd9ZuP8Af8n/AAR/rjwheI97vrNx/v8Ak/4I/wBceELxHvd9ZuP9/wAn/BH+uPCF
4j3u+s3H+/5P+CP9ceELxHvd9ZuP9/yf8Ef648IXiPe76zcf7/k/4I/1x4QvEe931m4/3/J/wR/r
jwheI97vrNx/v+T/AII/1x4QvEe931m4/wB/yf8ABH+uPCF4j3u+s3H+/wCT/gj/AFx4QvEe931m
4/3/ACf8Ef648IXiPe76zcf7/k/4I/1x4QvEe931m4/3/J/wR/rjwheI97vrNx/v+T/gj/XHhC8R
73fWbj/f8n/BH+uPCF4j3u+s3H+/5P8Agj/XHhC8R73fWbj/AH/J/wAEf648IXiPe76zcf7/AJP+
CP8AXHhC8R73fWbj/f8AJ/wR/rjwheI97vrNx/v+T/gj/XHhC8R73fWbj/f8n/BH+uPCF4j3oz6x
cfo/+/k/3p/mP8nzyPCOL4M+I8Pxf//Q8c3P+9E//GRv1nPoaPJ+e5cyo5JDsVdirsVdirsVdirs
VdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdiqM/6V/wD0cf8AGmQ/i+DP+H4v/9Hxzc/7
0T/8ZG/Wc+ho8n57lzKjkkOxV2KuxV2KvWvy0/KHVvzFsvMPmG41/R/I3kXygIT5o89eYZ2gsbZ7
huMNvGI1eSaeTfjGi79yKrXU9o9rY9GYx4TOcuUY89uvkPN2vZ3ZM9YJS4hCEecpcvd5nyTbzj+S
Umi+Srv8yfI/n/y7+a/kbSLyGw8y6poDXEdzpU9weMBvbO6iiljjlb4UkoQTtmNpO3Y5sow5ISxz
O4Bqpe4jr5OTq+wpYsRzY5xyQGxq7HvB6ebwwOpAII3zfWHREFdUeONodUeONq6o8Rjaaeh/ll+W
mv8A5q+ZJfLmg3Nhpq2GnXWs69ruqzG3sNN02yUNcXd1KquVjTkASFO5GYPaPaGPRY+OdmyAAOZJ
5AOd2f2fk1uTghQoEknkAOZLJfOP5YeStC8uap5i8rfn35I8+SaO0S3fl20a9stSmEs8cANnDdW6
LccDJzfi2yBm3CnMDSdszzZBCeGcL67Ecr3o7frc7V9jQw4zOGaE66bg862sb/qeKhlIBqN83gLo
yF1R44bQ6o8cbVrkviMbTTdR4jG0U6o8Rja03hV2KuxV2KuxV2Koz/pX/wDRx/xpkP4vgz/h+L//
0vHNz/vRP/xkb9Zz6GjyfnuXMsw8i+UrXzffavb32tfoGy0XSbjVry/+rNdUitmjDj01dG+y5O1T
tSm+cZ7ce1mb2d0+nyYNP+ZyajPDBGHGMXqyCRj6zGQ5xEd6G9mQp6z2P9mcXbufPDNn/L48GGea
U+A5PTjMRL0iUTyle1nagDbIf8I/lf8A+Xf/APDfvf8AmvOf/wBFvtf/ANED/r8w/wDEu8/0Mey/
/Ra/69M3/FO/wj+V/wD5d/8A8N+9/wCa8f8ARb7X/wDRA/6/MP8AxK/6GPZf/otf9emb/insn5f/
AJf/AJP3mgarNLrlv5raNmF5qs6y6c1tGFBHGGRwygbnma16dqZ477fe3/txpu0sEI6aeiBA4ccT
HUDLK+uSMSJd3AKIG9bgvqfsV7E+x+o0GaUtRHVkE8WSQlgOMV0hIgx7+M3fK9qfJt7HbxXl3FZy
me0jmkW1nYULxhiEYj3FDn1bop5cmDHLNHhyGIMh3SIHEPgdn5r1cMcM044jxQEiInvjex+IfQ/m
YyR/84O+VobcmGHVfzmvH1PgKes8Gi8YuZ78RWg6Zy2X19ryvpjH+6epxejsiNdch/3Kj/zjdAYP
y9/5y0tDV7GT8pb28ltyPgNxaXMT28h90LMRke3sYxZNPIc/EH3M+wchy49RE8uA/e91/Nb80NG/
LD8/fLv5M2f5Pfl7qX5WXNv5Zg1vSJPL1ot9PHq1pbPdSrfqomWYNKWR67ELWuajRY8uo00s/i5B
kHFR4jW11tyrydtrMmLT6mODwoGB4bHCL3q9+dswu/yauvyf8t+fdS/KHyF5T8/ec5vzJ1jy7pep
+e7vSVt9G0GwjV4Y7aLWbq2hluHMvF5AWYr1UDIy7Zlq5QjmnKMRAEiF+qR7+EXXkzj2NHSRnLDC
MpGZAM69MR3cRq/NH+Xfy58n65+Y35B+Y/PHkHyTpfnfzFovnIfmZ+XWhXGn6hokl3olm8+mX/1X
T7m5t0MyHlIgbiWH2QQchPtTPjwZccMkzEGPDI2JAE+oWQD7mUOy8GTNiyThASIlxRFGJIHpNAke
94F+WX5jwf8AOQ/lH8+/LHnj8tPI2kHyP+Wetee/Jev+WtDt9IvNOu9EMBS2jkt6FoZRKAysTsor
XNhmjk0GTDkhkmeKYjISkZAiV779XX4ZY9djzY544DhgZAxiIkGNbbdHz5+Tn5t3n5T+ZbjzH+gL
bzboHmDRr3y3528p3btFFqej6iqrdWxlQEoW4KQ1DuNwRXOj7V0X57AADwyiRIHukORed7L1v5HO
SRxAgxI74nmHofmT8jPy881+VdR/NT/nHbzPc6v5Z0me2Xzv+XWvKI9f8sreSiKOZ2Qlbu1DmnqJ
UqOpajldRo+08mnyeDqo1I/TIfTKvuP47nb6vs3HqMfjaWVxH1RP1Rv7w9g/M/8ANLyz+Sf51D8h
PLv5MeRdc/LfyjPpWi+aJdZ0eK81jWmure3ku7uXUHYyxS8pmMRQ0QgGlPhGBpsebW4PzMssxM2R
UiIx50BHlXf3udqcmHR5/wAtHFAwFA3EGUuVky533dy7/nIb8uPKv5W/kl+ZGj6HplsZvL//ADka
2jaRrEkSNfRaVc+VI9RisTdMDK0cZlGxahYcjvvlnZHauXUayEpk74dx04uOrrlbX2t2Vi0+knGA
G2bY9eHg5XzpnP8Azj75L8k+atL/AOcJrHzF5S0nWLfzZ5i/MVfMKXNpE5vl03T7ie1W6bjWVYnj
UqrkgUpSmUdsdoZsWXVcEyKjjqjysi67rb+yOz8OXFpeOANyyXtz2NX308v/ACr/ADYh/MbyZ+cX
5n+evyv8hahF+Reg22peSvKenaBbadpz6jq1wLK3a9itwpuYLcLURSMR/sqES1MMmCePHjyTHimp
EyJNDc1fInvDHTTx54ZMmTHA+ELAEQBZ23rmB3FQ/IbX4v8AnJT80bC38+/lr5KZPIfl3XPMwsdC
0+Dy+NcmtIYxa2WpTRyRwGFZWUhmC0FQ7FKjMjXnJ2dpiceSfrIjuTLhvmY3vf4G7j6AY+0dQBkx
w9AMtgI8XcJVtX45M/vtB81eePy//OIfnh+Wv5V/l+nljylqHmP8tPMvk++8uw3sOp6bwmTSli0n
UbiSaK4hDqBIhoR9rkVzDwa7wM+M4MmSVyAkJcRBB/i9Q2I8nNz6Lx8OQZ8eONRJiY8III/h9J3B
8355WspmhVz3z0XHLiFvneSPCaROWNbsVdirsVdiqM/6V/8A0cf8aZD+L4M/4fi//9Pxzc/70T/8
ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab/fvpH/A4/wCdp/2ztR/vHlGeqvmz
sVdirsVeyfl3+avlHRfJHmn8oPzZ8t6r5j/LHzNqtv5gs7vQJ4odX0bWbeMW/wBdsxcgwSepB+7d
HpUAbjfOY7V7Oyyzx1GAgTiK35Sjzo1vzem7K7RxRwS0+cEwkb25xlysXtyVfNv5u/lZ5Z/LDzj+
Wf5C+X/NYk/Mj6rB5689edGskvzp9nL6yWFlbaezxRI7gGR2clhUU3HDAOj1Wpyxyakx9H0xjdWe
pJc8avS6bFLHpxL1/VKVXQ6AB9Qf85EeZv8AnGryb/zkLa+aPP2jfmH5l/MDy7pflrUF8s6b+i4/
Lt5JbadbSWiy3Eji7RaBfUAjapBoaGg0nZcdZk0xx4jARkZCzfENzfk7rtOWjx6kZMokZRETQrhO
wrzfPL/85AeSPzW0Lzh5W/5yN8r+YpNN1rztfeevKvmTyVLa/pDSLnUUEc9j9XvysM1uVVaFmDCn
ypsP5Fz6eUZ6cixHhIldGuu3V1/8tYNRGUM4O8jIGNWL6b9G/wAuvzU/5x9/KT81vK3mz8v/ACf5
6Pl/RtH8wWOu6vrdzYXOrajNqti1tacbOA29tbxwOSTSVmIfuUHK3Udm6vVYDHIY8RMaABAFGzvu
TfuatP2lpNNmEsYlwgGySCTY222Ar3vPfyM/MXR/yutvzhXXLC/vT+Yn5XeYfI+j/UEif0b/AFcW
/oSz+rLFSFfSPMrybpRTm07R7OyaiOLhr0ZIyN9wvl57us7O7Rx6eWXis8eOURXea5+THfy2vfy7
0y/nX80tC1zW/LV1ZSQJ/h28hs9QtLkvGyXMf1mKWKXiquhRwAeXKvw0Ox1MdQMI8AgSB/iFgju2
II97rtNLTnMfHBMSP4TRB79wQfc9evPzb/JP8ufI/wCY3l/8hNG8+Xvm78ztMTQdU81+c2062j07
TfWSaZLS3055fUkl4U5uw47EDYhucy6LV6vLGWfgAgbqN7nzJeixa3SaTFKODjJmKuVbDyAZNqv5
2/8AOOHn/wA3ab+cX5o+QvPn/K1UjsJvNHlvQZ9MHlrWtR02KOFLiSWYJc2yziJTIiI3gCTVmrxd
n67TYzgxSjwG6JviiD9h8m3Jr9Dqcgz5Yy4xVgVwyI+0eaW23/OR/k78ydD/ADS8qf8AOQ3l7zJ+
g/Pvn3/lYmh6x5La0kvtK1IWY08W3pagUSWFbVEiBLggAmlTURHY2fTThk05Fxjw1K6Iu+nW0ntj
BqYTx6gGpS4rjVg8uvSmbeTv+cpfyc/L3zd/zjtbeUPKnnm5/L78kb7zZf3t/rDabLrN8/mPT5rV
RHb27w26hJZeRrLsu1WIqaNR2PqtSMspmPHkEeV8I4T57t+n7Y0umOKMBLgxmXOuI8Q8qD54/In8
zNF/LWLzv5b89eXLzzP+XH5n6GND85abpsyQahCI5BNbXlm8gMZlgkBKh/hNd83faHZmTNCE8Zqc
DYvl5g+RdL2f2ljwznDILhMUa5+RHmGfeV/zc/JT8ovOeha5+VXljzt5q0K7sdT0X8ybDznPYWj6
jpOqQrBJbWsenCQRMm782kbkQBRRmNn0er1uEwzGIIIMeEHYjqb/AFORg1mk0eYTwiRBBEuIjcHo
KYVr7/8AOJdnousf4C8t/mjrHmjUIHj0aPzRd6TaadpsslOMpNgss10Yt6BvTDftDfaWl0+uMwMh
gIg70CSfnsPtRqs+hECcYmZEbWQAPlufseW2qcIVXpnX4xQeRyGyiMsa3Yq7FXYq7FUZ/wBK/wD6
OP8AjTIfxfBn/D8X/9Txzc/70T/8ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab
/fvpH/A4/wCdp/2ztR/vHlGeqvmzsVe/f847flZ5D/NrzXrmhef/AMx7X8ttN0zSTf2eqXM1rCJ5
hPFF6Qa7kjU/C5agNds0PbvambQY4yxQ4yTXXbbyd72F2Zh12SUcs+AAX033833PoX/PvX8oPNNn
d6l5Y/P+XzHp1i5jvr/Sxp15DC6qHKySQzOqkKQaE9N85GfttqoGpYgD529bD2K00xccpPup4L+c
n/OMX5C+Qfyz81ecvK3/ADkXpXnTXtDhgk03y1DeaVK920tzFCUVLe4aQkK5b4QembDs/wBp9Tqc
8cc8NRPM77bOBr/ZnTabBLJDNchyG2+74GWGCWGqoBzGdqIRIeKM5RKZ65qeu+bNam8w+a9ZvPMW
szxwwyalfzNPMYreNYok5OSaIihQOwzG0+gx4BUIgDycnUa/Jm3nIk+aEMMRFCopmaYBwuMvqn/n
Dv8AJHyT+ev5pa35N86PqEOlad5WutagOmTpBKbiG9srdQzPHKCvG5aoA6038eb9pe0snZ2CM8QF
mQG++1E/oek9m+zcfaOeUMpNCJO229gfpeI/mx5b0byV+bf5k+RdEaeTSPKPmG/0vTnunWSYw28z
InqOqoCaDqAMz+yNYdXp4TlVkC/e4Ha+jGk1E4RugTXuYOUQjiQCPDNtwh1NlTFvApqEAOREIhkZ
yLjBCxqUBOEwiVE5BswxEUKCmJgEcZWi3gUGiDBwRCeORfdtt/zjd+W83/OEVz/zkNNcayPO8Vtd
TCFbmIWHKDXn0xR6PolqGJBX4/tb+2cVn7fz4+1PytR8OwOW+8b533vaYOwcM+y/zNy8Sj122lXK
u58G26QyRLIEHxDOzxiJFvG5DIGlYW8INQgrkhCLHxJKwAHTbJsHVHjirqjFXYVdgVvCqM/6V/8A
0cf8aZD+L4M/4fi//9Xxzc/70T/8ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab
/fvpH/A4/wCdp/2ztR/vHlGeqvmzsVQV5ZRXicJBUHKcuEZBRbsWY4zYfr1/z7dsIrD8g/zthiFF
fXrtj8/0TAM8r9rMAxauAH839JfUvZTOcukmT3/oD83/APnDL/nHCw/P38ybHy5qdzNYeW9GsX1n
zTdW1BM1tDJHEsETMCFeaSRVqQaLyYA0pnQa/VR7O0gyRFzJoe/v+DoNBppdo6s45GoAWfd3fF+i
OufmT/z7m8m/mLP+QV9+WSS3Gn366Bq/nNLEz6fZ3qsIZIp9Te8F8GikHCSREKqwarfaOc3DU9rZ
IeMMp76v/e1wvRz03ZWOfgnEO66/318TwX/nIH/nEYeRPz+/LX8vPIt5LF5T/Oa79Hy1Lekzvpsk
Eka38buSDKkEciyqSeRU8TUjkel7J9qDk0mSebeeMb1/F3e6+TzXavswMeqhDDtHIdr/AIe/31ze
9fm9rX/OEX/OIuo6D+WHmT8oLz8yvNV7psN/q176FvqF1HBIzxLNcTXdxCkckpRmEcKqAKH4Rxrz
2LXdqdoyOSOUxF7AbD7P0vQ5dD2Z2dEY5YuI1uTuft/QgP8AnDzzL+Tnmr/nMPzbq/5F6DqHlnyR
e/lTPNPomoo8ckGonV9M+sKqNNcBVpw2Vyta8dsn21LVfkIR1J4pDJz8qNdzDsWOl/PylphwxMOX
nYvvUPzI/Pn/AJwN8ifnV538r+ZPyS1LzT5rufMt2n5jedLmxivLWHUJp6XMkf1y89QpG1SwiiVQ
B8AYnMXRw7RlhBxZDGIGwBr7g5Wsn2dHMRlxiUidyRf3liH/ADk3/wA4z+Qfy4/5yG/5x/sfL2nS
WX5e/nV5psdG1ny1HNJwtZRqFlBdJbylvURJ4rsFRyJVg3EheKjedke0efJpMwmbnjiSD8DV+4h0
fa3s7gx6vCYCoTkAR8Rde8F69+f/AJi/5wu/5xO1/wAveStf/wCcd5fNGqa9pS6nay21vBfxJaia
WACSfUrwymTnGa/Cainxds0ul1naevuQzEUfd/uQ7rVaPszQ1E4QbHv/AN0Xl3/ORn5Nfkh5w/5x
v0z/AJym/ITRZfKmmqILrVNEAaKOe0mvRp86SWpklSGe1uPhb0m4EK/2vhbNr2L25qsOq/LamXFf
U8wavn1BHe6rtrsPS5tL+Z00eHyHIi65dCPJkfkb8m/+cd/+cd/+cftA/Pv/AJyQ0iXzZqnmqGyu
NN0ExtcBG1KP6xaWFrZ+rFFLM0KmSRpmCrRh8IU8q+1O39ZrNTLBppcEY2LHM1zN867qbOzOwdJp
NNHPqY8UpUaPIXyFcr77TiH8qP8AnGL/AJzH/KXzV5x/5x28sz/l/wCfPK5kih0mSAWD/W1i9WG2
vLOKaa2Mdyq0SWJqhqkk8WTMfT9t67s7NGOolxwPfvt3g89u5yNR2Joe0cMpaePBMd22/cRy370t
0+cTf8+mr2fccrDUSQeop5xmByjVZBPtni8x/uQ36XGYdjcPkf8AdFAfl3+S3/OPH/OOP/OO3lv8
+P8AnJHSZfNureaYLG407QTG1wI31KP6xaWFrZ+rHFLMYVMkjTMAtGHwhTyy9d27rNVnODTS4Ix2
sczXM3zrupxND2Ho9LgGfUx4pS3o8hfIVyvvtkUH5Uf84xf85jflN5p84/8AOO3lmf8AL/z55WLx
RaTJALB/raxerDbXlnFNNbGO5VaJLE1Q1SSeLJlen7b13ZueMdRLjged77d4PPbubNR2Joe0cMpa
ePBMd22/cRy373j/APziH+Q35X6/+WHnL/nIr88Fa88j+T/rrWehtI6QvFpkAmu7mdYirynkeEUQ
YcmUhlaqjNv7Q+0OeGSOn0xqUgLPXfkB+kuo9n/Z/BPHLUakXEE0Om3Mn9Aeu/kj+ZP/ADhL/wA5
JefYvyu8u/8AOOE+h3dzaXV5p+rXljZ2kbxWi1b1JLK8MysymoA5b9T3zQ6nN2npIeLLOSPeT94p
32mw9maqfhDCAfcB9xtnX5M/kv8A84/+ZPPH/OUf5HSfl/pBvPy/1y3Hl/UruM3eoWmm67pURjEN
xcFpW+r3EcrKxcleS1PQmOr7b1ojhzeJLcbgbAmJ7htuKZaTsTRGWbD4Y2OxO5AkO877G35sf84y
/l0/nv8A5yH8lfl35j05LyDTNcuG826dKOULQ6MJJrmGUEbpI0HpkEb8qd87ntPtXw+zpZoGiRt7
5bfZdvD9mdleJ2hHDMWAd/dHf9FPSP8AnO+L8vfK/wCell+Xn5ceU9J8rWnlXQbWTzHHpdvHb+pq
F+zXAEgj68bcwkV3+I9s1/snqs+bEZZZmRJ2s3sP227D2r0uDDlEcUBGhvQrc/sp8i52rxSM/wCl
f/0cf8aZH+L4M/4fi//W8c3P+9E//GRv1nPoaPJ+e5cy9R/Kr/ypH/gC6x/zJzyz/gp/86j/ALam
m/376R/wOP8Anaf9s7Uf7x5Rnqr5s7FXYq/Xz/n3Z/5Ij86v+25d/wDdJgzyv2z/AMdh/VH3l9S9
jf8AE5/1j9weAf8APqS9to/zD/MLT5J0S7uvKkM9tbE/E8cN5EsjKO4UyrX55d7Ug/lsR6X+hp9l
yPzOUda/Sv8AzT/5yT/5xu8lfmf+YXlHzd/zg5pFx5m0TXr+DWNRupLNJL+T12YXtHsSStypEymp
qGBqa1zA0Wg1WbEJQzEAjz/W5+t1+lw5TGeEEg+X6mVaT/zl7B/zkj/zkp/zimx/Ly9/L/T/AC15
g1lodQvb4Xcd6+oWBtY0i428I+GVApNTuQME+yJ6TTZiZXYH3ph2vDV6nCBGqJ+54j/z8X0C8s/+
cpbjVdSsXh0/XvLOlS6ReOv7udYBJBKFbpVHQgjqNj0Izeex/BLEQeYJdJ7X8ccoI5EBn/8Az7St
kt/+cg/NNIzH6n5d37pUU5KdV0mhHiDl3tsIjTQ4f54+6TT7FGR1M7/mH74vjn/nJC1gk/5yK/P5
3QFj501jf/o4fMz2fxxOjiT/ADXD7fySGskB/Ofrn/znESPzn/5wTp3/ADXtK/8AcQ0nOC7J/us/
9Q/cXvO1f73B/XH3h8mf8/RIY5fz1/Lf1FDU8kilf+2jd50PsdESEr7/ANDz3thIxMa7v0vWolEP
/PprU1jHELp+o8QP/AxmzX9oDh7ZNd4/3AdhoDxdjC+4/wC6Lf8AznjpVx5p/wCcP/8AnHvzNo8J
1XQdKn8v32o6hB8aRW15oskUM7EdEaR1WviyjvlfYPCNfKM+t/ez7d4joIyhyFfciv8An1rok+j6
L+d/mm4t/qXl/UpdBtrbVZfggeTTY9RluhzagpEt1GWNdq5ne2fAMmKEeYBv41X3FwvY3j8PLOXI
kV8Lv7wl9vdx3/8Az6b12+t2LwXkWtzwOQQSknni5ZTQ7jY5qBY7RHw/3IduaPZx+P8Auirf854a
Vceaf+cP/wDnHvzNo8J1XQdKn8v32o38HxpFbXmiyRQzsR0RpHVa+LKO+ZPYPCNfKM+t/e4vbvEd
BGUOQr7kV/z610SfR9F/O/zTcW/1Ly/qUug21tqsvwQPJpseoy3Q5tQUiW6jLGu1czvbPgGTFCPM
A38ar7i4Xsbx+HlnLkSK+F394Qn5UM3nn/n2f+a1l5bjk1e9R/NTSWcKlpaLqTagV4U5cvq7q9KV
3zVZvT2hAz2+n7qdph9XZ8xDf6vvt8yf8+44beP/AJyQ8ttEFDfoDV9x/wAYBnWe1EIjs8V3h5X2
YnI9oG+4vob8v/Pp8lf8/Q/zU0mecxaZ+Y5/w/dA1Mf1hdLs7y0YgH7Rkt/SU0NPUPYkjmsml8Ts
uMxzjv8AaQXpMeq8PtSUDylt9gIe9fkd+S6+Tf8AnNT/AJye883NsltoVrZWeoaJeSUSL1PNJ+v3
sqk7Axy2sysa7BvfMbWdoHJoMWHre/8Am7D73I0nZ4x6/Lm6Vt/nbn7n4wef/Osn5p/m5+Zf5lSS
NLD5s8wXt5ppapK2IkMdlHVgD8Fuka9B06DPRPZ7SeDgiO4PnntDq/GzyPeUqzpXnEZ/0r/+jj/j
TIfxfBn/AA/F/9fxzc/70T/8ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab/fvp
H/A4/wCdp/2ztR/vHlGeqvmzsVdir6m/IX/nL27/AOcePI3nXyRB+Wo86Dzjey3g1Q6v+jvqxltE
teJi+pXPqU4cvtr4e+cX2/2DLXZ45BKqFVV9b7w9l2B29HRYJYzG7N3ddK7i+Yvyv85+c/yj8w6F
568jal+jPMugsWt2dfUhmjdeEsFxHUB45FJDD6QQwBG11HZcdTpvCmHV6ftSWm1PiQL9Df8Aoptp
eoWtrc+ef+cZNL8xea7CMLHqUWpQ+g7j4gY/rOn3EsC8u3OSnWpziZ+y+fHIiGQge79r2sPajBki
DPGCff8AsfIn53f85LefPz988+VfPcuh2X5f3PkOONPJlvpDyPLaNDcC5ileeSgaRJAvEqiAUHw5
0fZPYY0+GWM3Lj537qed7W7bOfNHIKHByr5vrbSv+fm13LothYfmp+QemeeNe0ni1trVpexwQSzB
aGX6rc2dz6DkgElHI32VQKZz+f2Vy4pnwpkA/joRbv8AB7U4ssB4sASPx3PKPL//ADnj5lsf+cgt
c/P3U/yqs75dR8nHybpvky01R7Nba1F5BeJM929rceo4MJU0hQEHYCm+dL2cnPSDAJEVLiur3quV
hwY+0cIas5zEG48NXW13zp8o+e/NU/5kefvzA/MGXSf0G/njWr3WP0OJvrP1b63K0gi9b04vU41p
y4LXwGdN2VoZabTjGd6FPNdq60anUHINrNvqX88v+c2L/wDObzt+Rfmz/lVA8uf8qS81ReZxZfps
3g1NoriznEHP6hB6AP1WnKkn2um2/MaT2Ynpxkjx3xxrlVc/Pzem1ftNDOccuGuA3z58vLyeY/8A
OSf/ADkJdf8AOTXn/wAu+cpvI/8AgVfL2iDRhp36S/SfrUuZrj1fV+q2nH+948eJ6VrvQbXsDsaW
gsE3ZvlX6S6vt7tiOuogVQ77/QGVzf8AOV15B/zitc/84tL+XAmjuoZ4P8d/pbjxFxrDasT+j/qZ
rTl6f9//AJX+TmNq/Z+U9f8AmRLYkbV3Cud/ocjSdvxx6D8tw7gHe+83yr9LIP8AnH7/AJzi89/k
X5Nh/LfzR5MtPzT/AC9tVki0vT7i4+qXlnBMSZLcStDcRzQ1YkRvHUVI58aKMftT2Y8Wfi4zwycn
sv2m8KHh5BxRTP8AOz/n4J53/M7yTf8A5Yflj+Xlr+UHlPWLZrHV72G6FzeyWk1fXgtxDBbRWyS8
ir0V2Kk0ZeRzE0PsxIZBPKTI/j5uVrvaaJxmGMCI/Hyef2v/ADlNd6b/AM4lN/zikn5biaKW3uLc
ee/0tx4i41l9XJ/R/wBSNaczH/f/AOV/k5m5PZyX5wZxLbbavKud/ocLH7Rx/JnAY777353yr9LL
f+cfv+c4vPf5F+TYfy380eTLT80/y9tVki0vT7i4+qXlnBMSZLcStDcRzQ1YkRvHUVI58aKI9qez
Hiz8XGeGTPsv2m8KHh5BxRTT86/+fgnnf8zvJN9+WH5Y/l3a/lD5T1e2ax1i9guhc3slpNX17e2E
MFtFbJKGKvRXYgmjLyOYmg9mJDKJ5SZH8fNytd7TROIwxgRH4+SG/wCcNvO//OSf5S6f5l1D8ofy
1n/Nr8vZL2H/ABd5SikCvHe+l8E1syF5YpHjUKzCF1YKARVVple0PZ2kPCMkxCdbe78ebjez/aGr
HEccDOF7jz/Hk/SL/nHj81PMPnj8w5NPl/5wn1H8ibEWFxdaz+YOqWi6cfWBAS3iD6XaPcGVnNSJ
NhUkHOP12Lgx/wB/4ncAb/Saeu0WXjn/AHHh95Ir9At+aH50+WvzV8yf85Yfmz+a35PeSPMHnCHy
R57tI7PXNF0u61K3h1jRbe0LwP8AVUepjkiHNa9CK0qM63snJpxoRhzzjHiidiQNjfe8n2tj1B1p
y4ISlwyG4BO4rufpL+d356eb9K/5wo82/mP568mt+Vf5h+c9Ik8u6d5TlmeW7judTlexjf8AeQwv
G/otJdCJgTGooSWBzk9Po4nWjFCXHEHn7vxT1eo1khojknHgkRy9/wCLfgpoVsLaxiWlDQZ7Losf
BjD45rMnHkKdZmOIjP8ApX/9HH/GmQ/i+DP+H4v/0PHNz/vRP/xkb9Zz6GjyfnuXMvUfyq/8qR/4
Ausf8yc8s/4Kf/Oo/wC2ppv9++kf8Dj/AJ2n/bO1H+8eUZ6q+bOxV2KrSqt1AOCgkEhsADYDbGkL
DFG25QE4DEFkJELgqrsqgYQAEEkrWjjb7SA4DEFIkQ36aDbgB7Ux4Qtl7D+SX5Y6d+ZvmnVrXX9Z
fy15L8maBqHmvz3rsEYlnt9K0xVMot0b4WldnVFr0qWo1OJ1PbHaJ0WIGEeKcpCMR04j3+TteyOz
xrcpE5cMIxMpHrQ7vNd5n82f84wavour2nkzyH5/8t6/bRH/AA3rV5qtjfQXUoKgfpC2MMfpqy1J
9FyQadRtmv0mTtDxAckoSj1AiRX9U397sNVDs/wyMcZxkOR4gb94r7mJ+Tfyv/Mbz9a3d75I8ha9
5rtbA8L270rT57qKN6V4M8aFeRG4WtfbNzn7Q02mIGWcYk95AdPg7P1Ops4oSkB3AljP6F1U6udB
Oj3g19bj6o2iG3k+uC4rx9H0OPqc67caVzI8bGYcdjh53e3zcfwcglwUeLlXX5M6138lvzc8t6HL
5j8xflb5p0XQLded1qt9pF3BDClacpmeMemte70H35iY+1dHlnwRywMu4EfY5WTsrWYoccsUhHvI
LNPyq/5xq/MP81vLXmnzZoOhX8Wj6Ho11qWiXaWEs6azd2sgiOn2joQDKWr40odsw+0O3NNoskcc
iLJAO/0g/wAR8nM7P7D1OtxyyAEAAkbfUR/CPN5Vb+Q/Ol55rn8jW3k/V7rzpaStBdeVoLOaW/jk
QAsrwIpccQamo2HXNh+e0/heMZgQ772+br/yOo8XwhEmfdW/yW+b/I3nDyHfQ6X548p6r5TvrmP1
bW21azltTNGKVeL1VUOBWhK1oduuS0+swakXikJDyNsdRo8+mNZImJ8xTINH/Jf81tc0V/Mui/ll
5lvvLyW5u/07Fpdz9TaAKXMqTlAjqFBJKkgDKcnaejxT4JZIiXKrF37m7H2Zq8sOOOORjzujVe9D
/l9+dn5v/k7Pd3f5Wec7ny4moOkmpacYobqzuWjBVTJbXMcsZPFiOQAanQigzF7V7Jw68DjjZHI9
fscrsrtbNoSeCVA8x0em+ZP+c6/+cuPM+m3Gj/46tPLsN2pjnvtF0y2tbvgeojuCjvGf8qMqw7HO
ex+yWGMrq/eXocntZmlGrr3Bg/5Qf85J/nx+Quh6toH5e+ZLVdK1zUpdZ1Kz1Oxgvi+oTxxxTXBm
kX1uTrCgIL02rSpJObrfZrDnoyG4FbHo4Wj9pc2CxE7E3uOrHfzW/O386fz+vdLl/NXzWdV07RHM
uk6DawRWdjBIwIMoghVQ8lCRzcswGwNMs7M9n8ellYDV2l7QZNVGpFhcaCNFQbADOqiKFPLSNm1T
JIRn/Sv/AOjj/jTIfxfBn/D8X//R8c3P+9E//GRv1nPoaPJ+e5cyzDyL5ttfKF9q9xfaL+nrLWtJ
uNJvLD6y1rWK5aMufUVHb7KEbUO9a7Zxntx7J5vaLT6fHg1H5bJp88M8Z8Ay+rGJCPoMojnIS3sb
UYm3rPY/2mxdhZ8882D8xjz4Z4ZQ4zj9OQxMvUIyPKNbUd7BFMh/xd+V/wD5aD/w4L3/AJozn/8A
Ql7X/wDRf/688P8AxTvP9E/sv/0Rf+vvN/xLv8Xflf8A+Wg/8OC9/wCaMf8AQl7X/wDRf/688P8A
xS/6J/Zf/oi/9feb/iXf4u/K/wD8tB/4cF7/AM0Y/wChL2v/AOi//wBeeH/il/0T+y//AERf+vvN
/wAS7/F35X/+Wg/8OC9/5ox/0Je1/wD0X/8Arzw/8Uv+if2X/wCiL/195v8AiXf4u/K//wAtB/4c
F7/zRj/oS9r/APov/wDXnh/4pf8ARP7L/wDRF/6+83/Eu/xd+V//AJaD/wAOC9/5ox/0Je1//Rf/
AOvPD/xS/wCif2X/AOiL/wBfeb/iXf4u/K//AMtB/wCHBe/80Y/6Eva//ov/APXnh/4pf9E/sv8A
9EX/AK+83/Esp8l+ePyns/Men3Fx+Xa+XVjLcNZfUrnUUgcqQrNBIlD/AK1CV65y/tl7E+2ep7Ly
48fax1RNXiGDFpzMXuBkhK/83YS5E9HovZT2u9k8HaWOc+zBpgLrIc2TOIGticchX+duY8wkv51+
Y/KPmPzHb3PldUnaK2VNQ1OJDGkz1YgUIUsVBA5U9u2bn/gL+z3bfY3Zc8faZMQZkwxyPFKEaHUE
8IJs8N+exLqf+Cz272R2t2jHJ2cBKogTmBwiRs9CBZAr1V5b0zj/AJxrSS/0P/nKDRLNGuNU1H8m
9cksLFBWSYW8tu8ojH7TBTUKPiPYHO49pdpaeR5DKPuLyvs1vHURHM4z94fI+nRwLaBgByA650GC
MRC3n88pcdP0K/M6/wDJ2jflF/zjDod7+fPmf8mrGTyTHrlvo3ljQZtRgvdQurmR7m8mubbU7D98
sg48WVivWo5HOBjPJPV6iQxRyHjq5GqA5DcHZ76UMcNLp4nJLGOC6iLsnmdiN0Jov5l+TPzM/wCc
zf8AnHDXfJWr33mN7bTdA0jzt5p1GxOnXGq65p6XMFxfPAZJiDNEsJ3dqfZ5Glcs8LNp+zc8JigT
IgA3UTW3ztq8XDqO0sE4GyBEEkVche/ypKf+cZ/OXnbXf+covPXl3XPNusaz5b8xWPnOx1rRL6+n
uLa5gitbto0eKR2WiFBx2qBsNq49p6eENFDJGIBBgQQOW4XszUSnrZ45SJBEwQTz2LAP+cWNZ1uH
yL/zlMltq97apaflHqtxZJFPIiwzi4gpLGFYcXFT8Q3zK7cgJzwEjnkA+xxexJmEM4B5YyftZb/z
jXqVpY/84/f85Qeb9c/MPV/IesTTeVtK1P8AMjTrKTWdWtLK9upVeNEFzbSgXTqsbv6o2p1KjKO1
xKOfT4xESA4iIk0CQB5Hl7m/sgxODUTMjEnhBkBZAJPmOfvYf54/M/8ALR/+cer38r7D82vMf5w+
ZrfzXa695S1PX9Cm01tLtzC0F7bwzS3983CQEPwDKvKppXfLdDh1EdWM3AIAxING77ugatbm08tI
cPGZniBFiq7+pTX/AJyp8zea7NP+cXtJ0vzJqmm6XN+QPky4m021vJobdpZlu0kcxI4Us6xqrGlS
FAPQZZ2JgjlyZyQCfGn09zDtvNLFjwAEgeDDr73yxChjQKTWmdvCNB4iZsqmSYuxV2Kt4VdiqM/6
V/8A0cf8aZD+L4M/4fi//9Lxzc/70T/8ZG/Wc+ho8n57lzKjkkOxV2KuxV2KuxV2KuxV2KuxVPvK
XnPzb+XXmfSvOvkfV5NE8yaM7NZ3iKrqyupSSKWNwySI6kqysCCM1/aGhhq8ZxzFguf2frZ6TIJw
NEM/8z/85DeYfM+h6xoEH5Tflh5Nl8wRGDWvMnlzy0lpqc6Oys4E8s0wh5lat6KpXNNpexpYpgnJ
kkByBl6fl1+Nu51XbAywIGPHEnmRH1fPevgpeVv+cgvOflXyjpPkXWvJXkf81vK3l2aafyrp3nnR
v0odKa5YPMtnLHNbyKjtuUZmX26UGs7BjkynLGUoSPPhNX7+adH27LHiGKUYziOXELr3ckqtfzr8
6x/mn5Z/N9NH8uWuveT3tz5f8v2Wlx6fo1vFbB/TgW0sjAeAMjE/HyNftUpl8exoHTSwEyqXM3cv
mbaJdsTGpjnAjceQqo/IUlvkH80PNf5c/mBefmboVnplx5hvV1VZbS9imksx+l4pYp+KRzRv8ImJ
T49iBXkKg26jsmOfTjDImhXLn6fg1aftaWDOc0QLN8+Xq+KH/K38yfM35Q3uu32haZo+v2XmnRbj
y/5m8t6/bPdaff6fcsjSRSxxSwuDWMEMjqR47nHXdlR1WOIJIMSCCNiCF0PastNORABEhRB3BBTf
yn+dPnHyL5m81+YvK3l7yxp+jedrf6l5n/LSXTjd+WruzFONtJZXUsrlFIqCZeQJb4qMQcfUdixz
4oxmZEx5Sv1X7x+pyNP2zLBllKAiBLnGvTXuP61Pzz+ceu+ftCi8qw/l/wCQ/wAuvLiXSX1xpnk3
QYtONzcRK6RyT3Mr3Fy/EStRfV479NhQ6HsjwJ8ZlOZqvUb+zYfYjXdr+PDgEYRF36RX27n7Up89
ef8AzH+ZNz5Ek8w2thbD8vPJ+l+SdD+oRyR+pp2ker6Elx6ksvKY+s3Jl4qdqKMzNB2bHSymY365
GRvvPOvJw9d2lLVRgJV6IiIruH6WM5uXTuxV2KuxV2KuxVGf9K//AKOP+NMh/F8Gf8Pxf//T8c3P
+9E//GRv1nPoaPJ+e5cyo5JDsVdirsVdirsVdirsVdirsVdirVB4YFdTFXYq7FXYq6gxV1B4Yq7C
reKuxV2KuxV2KuxVGf8ASv8A+jj/AI0yH8XwZ/w/F//U8c3P+9E//GRv1nPoaPJ+e5cyo5JDsVdi
rsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdiqM/6V/wD0cf8AGmQ/i+DP
+H4v/9XzTP8A38//ABlf/iRz30cnwU81PCh2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2
KuxV2KuxV2KuxV2KuxVE/wDHj/0df8y8j/F8GXT4v//ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAOgD4RsAAAEA6QMoAAAAgBYAAOAQAACYEQAA
QBcAAAUAAAAKAAAAAgAAAAAAAAABAAAAAAEAAQ8A8gOYAgAALwDIDwwAAAAwANIPBAAAAAAAAAAP
ANUHyAEAAAAAtw9EAAAAVgBlAHIAZABhAG4AYQAAAGkAYwAAABMAAAAAADAA0g9UqRMAVKkTAFgu
ywDclhMAMvIMMNyWEwAAAAAADwDVBwAABCIQALcPRAAAAEEAcgBpAGEAbAAAAGEAAABpAGMAAAAT
AAAAAAAwANIPVKkTAFSpEwBYLssA3JYTADLyDDDclhMAAAAAAA8A1QcAAAQAIAC3D0QAAABXAGkA
bgBnAGQAaQBuAGcAcwAAAAAAEwAAAAAAMADSD1SpEwBUqRMAWC7LANyWEwAy8gww3JYTAAAAAAAP
ANUHAgAGAjAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAABMAAAAAADAA0g9UqRMAVKkTAFgu
ywDclhMAMvIMMNyWEwAAAAAADwDVB4AABiJAALcPRAAAAItbU08AAFAARwBvAHQAaABpAGMAAAAT
AAAAAAAwANIPVKkTAFSpEwBYLssA3JYTADLyDDDclhMAAAAAAA8A1QeGAAQCUAC3D0QAAABDAGEA
bABpAGIAcgBpAAAAaQBjAAAAEwAAAAAAMADSD1SpEwBUqRMAWC7LANyWEwAy8gww3JYTAAAAAAAP
ANUHAAAEIgAApA8KAAAAgABgAAAABAAAAAAApQ8SAAAAAAARGC4AAQAAAAAAWgAHAAAAAACpDwoA
AAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAQBkAAAAAP8BAGQAAAAAAAAAAABAAgAAAAAC
AAAA///vAAAAAAD//wAA//8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2AD
AAAAAAAFAACABIAEAAAAAA8ACwS2CgAADwAA8K4KAAAAAAbwwAEAAATYAAA3AAAAHQEAABgAAAAB
AAAACgAAAA0AAAAHAAAADgAAACEAAAAPAAAAMAEAABEAAAAHAAAAAAAAAAcAAAAAAAAABgAAAAAA
AAAyAAAAAAAAABQAAAAMAAAACAAAABAAAAAGAAAAEgAAAAYAAAAAAAAABgAAAAsAAAABAAAACgAA
AAEAAAAJAAAAAQAAAAgAAAABAAAABwAAAAEAAAAGAAAAAQAAAAUAAAABAAAABAAAAAEAAAADAAAA
AQAAAAIAAAABAAAAAAAAAAYAAAAAAAAABgAAABoAAAAGAAAAAAAAACgAAAAAAAAABQAAAB0AAAAG
AAAAHgAAAAYAAAAfAAAABQAAAAAAAABYAAAAAAAAAAUAAAAAAAAAOgAAACAAAAA2AAAAIQAAAAUA
AAAiAAAABgAAACMAAAAFAAAAJAAAAAYAAAAlAAAABAAAAAAAAAAEAAAAJwAAAAQAAAAAAAAANAAA
AAAAAAAFAAAAAAAAAAYAAAAAAAAABQAAACwAAAAFAAAALQAAADgAAAAuAAAABQAAAAAAAAAFAAAA
LwAAABMAAAAwAAAABAAAAAAAAAAGAAAAAAAAAAQAAAA/AAHwhAAAAFIAB/AkAAAABQVNDKoYn7lM
369MWYaSp4AG/wAMcgAAAQAAAAAAAAAAAAAAUgAH8CQAAAAFBXrruhb8ZULEwLGTC/0XcCv/AJZe
AQACAAAADHIAAAAAAABSAAfwJAAAAAUFBE0yIY2TpTBiwhzVISqmUf8ADJ4AAAEAAACi0AEAAAAA
AAMIC/AAAwAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAiQAAAAAA
vwAEAA8ADAH0AAAQDQEAAAAgDgEAAAAggAEAAAAAgQH///8AggEAAAEAgwH///8AhAEAAAEAhQEA
AAAghkEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAA
jwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEA
AAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEMAB4AwAEAAAAAwQEAAAEAwgH///8AwwEAAAAg
xAEAAAAAxUEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEA
AAAAzgEAAAAAz8EAAAAA1wECAAAA/wEGAA4AAAIAAAAAAQKAgIAAAgLLy8sAAwIAAAAgBAIAAAEA
BQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIA
AAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAA
hQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIA
AAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkA
zgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKw
PP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEA
RQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAcw0i8QoFAACMAAEAAACNADBlAQB/
AQAAQACeAf////+fAf////+gAQAAACChwQAAAACiAf////+jAf////+kAQAAACClwQAAAACmAf//
//+nAf////+/AQAAIADZAf/////aAf/////bAQAAACDcwQAAAADdAf/////eAf/////fAQAAACDg
wQAAAADhAf/////iAf//////AQAAwAASAv////8TAv////8UAgAAACAVwgAAAAAWAv////8XAv//
//8YAgAAACAZwgAAAAAaAv////8bAv////+JAv////+KAv////+LAgAAACCMwgAAAACNAv////+P
AwAAAACQAwIAAACRAwAAAACSAwIAAAC/AwCCAIJABQAAAABBBQAAAQBCBf///wBDBQAAACBEBQAA
AABFRQAAAABGxQAAAABHBQAAAABIBQAAAABJBQAAAABKBQAAAABLBTUlAABMBQAACABNBQAAAABO
BQAAAABPxQAAAABQBQAAAABRBQAAAABSBQEAAABTBQEAAABUBQEAAABVBQEAAABXBQIAAABZBf//
//9aBf////9bBQAAACBcxQAAAABdBf////9eBf////9fBQAAACBgxQAAAABhBf////9iBf////9/
BQYATgCABQAAAACBBQAAAQCCBf///wCDBQAAACCEBQAAAACFRQAAAACGxQAAAACHBQAAAACIBQAA
AACJBQAAAACKBQAAAACLBTUlAACMBQAACACNBQAAAACOBQAAAACPxQAAAACQBQAAAACRBQAAAACS
BQEAAACTBQEAAACUBQEAAACVBQEAAACXBQIAAACZBf////+aBf////+bBQAAACCcxQAAAACdBf//
//+eBf////+fBQAAACCgxQAAAAChBf////+iBf////+/BQYATgDABQAAAADBBQAAAQDCBf///wDD
BQAAACDEBQAAAADFRQAAAADGxQAAAADHBQAAAADIBQAAAADJBQAAAADKBQAAAADLBTUlAADMBQAA
CADNBQAAAADOBQAAAADPxQAAAADQBQAAAADRBQAAAADSBQEAAADTBQEAAADUBQEAAADVBQEAAADX
BQIAAADZBf/////aBf/////bBQAAACDcxQAAAADdBf/////eBf/////fBQAAACDgxQAAAADhBf//
///iBf//////BQYATgAABgAAAAABBgAAAQACBv///wADBgAAACAEBgAAAAAFRgAAAAAGxgAAAAAH
BgAAAAAIBgAAAAAJBgAAAAAKBgAAAAALBjUlAAAMBgAACAANBgAAAAAOBgAAAAAPxgAAAAAQBgAA
AAARBgAAAAASBgEAAAATBgEAAAAUBgEAAAAVBgEAAAAXBgIAAAAZBv////8aBv////8bBgAAACAc
xgAAAAAdBv////8eBv////8fBgAAACAgxgAAAAAhBv////8iBv////8/BgYATgBABgAAAABBBgAA
AQBCBv///wBDBgAAACBEBgAAAABFRgAAAABGxgAAAABHBgAAAABIBgAAAABJBgAAAABKBgAAAABL
BjUlAABMBgAACABNBgAAAABOBgAAAABPxgAAAABQBgAAAABRBgAAAABSBgEAAABTBgEAAABUBgEA
AABVBgEAAABXBgIAAABZBv////9aBv////9bBgAAACBcxgAAAABdBv////9eBv////9fBgAAACBg
xgAAAABhBv////9iBv////9/BgYADgCAABrxIAAAAJaWlgD///8A8gAXAGEBeQACIDoA/5kAALKy
sgBNTU0AQAAe8RAAAACWlpYAAgAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAMAAAAEAAAAAAAA
AAAAAIAAAAAADwDQB7UDAAAfABQEHAAAAAAAFQQUAAAAiZidFADKmjuOmwo1AMqaOwIBAAAfABME
PAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAACCXEwCRogwwIJcTAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAETAA8A+gOXAAAAAAD+AwMAAAAAAAAAAP0DNAAAAFQAAABkAAAAVAAAAGQAAAAAAAAAVHHL
APSWEwAy8gwwAAAAAAAAAAAW+///rv///wEAEwBwAPsDCAAAAAAAAADnAAAAcAD7AwgAAAAAAAAA
FA4AAHAA+wMIAAAAAQAAAGsVAABwAPsDCAAAAAEAAAAWAQAAcAD7AwgAAAABAAAAKRUAAB8A+gNH
AAAAAAD+AwMAAAAAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAABAAAAnHLLAPSWEwAy8gwwAAAA
AAAAAAAAAAAAAAAAAAEAEwAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAACCXEwAWogww
VKkTADQuywAAAAAAAAAAAAAAAAAAAAAAAAATAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAf
AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAAIAAAAglxMAOKMMMFSpEwAAAAAAAAAAAAAA
AAAAAAAAAAETAA8AiBOzAQAADwCKE2gAAAAAALoPFAAAAF8AXwBfAFAAUABUADIAMAAwADEAAACL
E0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAAAQEBAAEAAAAAAAAA
ANAAAAAAAAAAAAAAgAIB4A8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAA
ACUEAQAAAAEPAIoT0AAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixOwAAAADwDWB5gAAAAA
ALcPRAAAAItbU08AAGEAbAAAAAAAAAAAAAAAMKgTANCVEwDQlRMAVKkTAFSpEwAclxMA1JUTADLy
DDDUlRMAAAAAAA8A1geGAAQCEAC3D0QAAABBAHIAaQBhAGwAAAAAAAAAAAAAADCoEwDQlRMA0JUT
AFSpEwBUqRMAHJcTANSVEwAy8gww1JUTAAAAAAAPANYHAAAEAAAADQQIAAAAAMAAAADAAAAPAIoT
MgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAC8AyA8MAAAAMADSDwQAAAAAAAAAPwDZ
DwwAAAAAANoPBAAAAAAAAgBPANkPDAAAAAAA2g8EAAAADQACAA8A8A+IAQAAAADzAxQAAAAEAAAA
BAAAAAAAAABgAQAAAAAAAAAA8wMUAAAAFAAAAAQAAAAAAAAAbAEAAAAAAAAAAPMDFAAAAA8AAAAE
AAAAAAAAAGkBAAAAAAAAAADzAxQAAAAFAAAABAAAAAAAAABnAQAAAAAAAAAA8wMUAAAAFgAAAAQA
AAAAAAAAbQEAAAAAAAAAAPMDFAAAABcAAAAEAAAAAAAAAG4BAAAAAAAAAADzAxQAAAAGAAAABAAA
AAAAAABoAQAAAAAAAAAA8wMUAAAAGAAAAAQAAAAAAAAAbwEAAAAAAAAAAPMDFAAAABAAAAAEAAAA
AAAAAGoBAAAAAAAAAADzAxQAAAAHAAAABAAAAAAAAABZAQAAAAAAAAAA8wMUAAAAEQAAAAQAAAAA
AAAAawEAAAAAAAAAAPMDFAAAAB0AAAAEAAAAAAAAAHIBAAAAAAAAAADzAxQAAAAjAAAABAAAAAAA
AAB0AQAAAAAAAAAA8wMUAAAAIQAAAAQAAAAAAAAAcwEAAAAAAAAvAPAP4AAAAAAA8wMUAAAADAAA
AAQAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAA0AAAAEAAAAAAAAAAEBAAAAAAAAAADzAxQAAAASAAAA
BAAAAAAAAAADAQAAAAAAAAAA8wMUAAAAFQAAAAQAAAAAAAAABAEAAAAAAAAAAPMDFAAAABkAAAAA
AAAAAAAAAAUBAAAAAAAAAADzAxQAAAAbAAAAAAAAAAAAAAAHAQAAAAAAAAAA8wMUAAAAIgAAAAQA
AAAAAAAACgEAAAAAAAAAAPMDFAAAACQAAAAAAAAAAAAAAAsBAAAAAAAAAADqAwAAAAAAACgEwgcA
AFBLAwQUAAYACAAAACEAVq4Hw/cAAACpAQAAEwAIAltDb250ZW50X1R5cGVzXS54bWwgogQCKKAA
AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
fJDNTsMwEITvSLyD5SuKHTgghJr0wM8RkCgPsDibxKr/5N1WzdvjpEVCqHCy1rsz82lW64N3Yo+Z
bAyNvFa1FBhM7GwYGvmxea7upCCG0IGLARs5Icl1e3mx2kwJSRR1oEaOzOleazIjeiAVE4ay6WP2
wGXMg05gtjCgvqnrW21iYAxc8ewh29Uj9rBzLJ4O5ftIktGRFA/HwzmrkZCSswa4kOp96H6lVKcE
VZTLDY020VXBkPpswrz5O+Ckey3VZNuheIPML+ALhmb4dPjOk0NS/5ucoYx9bw120ex8aUCljFTe
Bdg79cP6m1wvRbdfAAAA//8DAFBLAwQUAAYACAAAACEA7eQMS7sAAAAmAQAACwAIAl9yZWxzLy5y
ZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAISPzQrCMBCE74LvEPZuUz2ISNNeRPCq9QHWdPuDaRKSVezbm2MLgsfZYb7ZKarP
aMSbQhycVbDNchBktWsG2ym41+fNAURktA0aZ0nBRBGqcr0qrmSQUyj2g48iUWxU0DP7o5RR9zRi
zJwnm5zWhRE5ydBJj/qJHcldnu9lmDOgXDDFpVEQLs0WRD351Pyf7dp20HRy+jWS5R8VkvFh6MaT
SStEjaEjVjA7ZulbkGUhF+vKLwAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAAA8AAAB0
YWJsZVN0eWxlcy54bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/
SqKXWOxkNAP/4AESujXdpAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KI
bUehuD2YWejt9WZR3G25DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5
qf0qLH5Asj8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAFauB8P3AAAAqQEAABMAAAAAAAAAAAAAAAAA
AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA7eQMS7sAAAAmAQAACwAAAAAA
AAAAAAAAAAAwAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAADwAAAAAA
AAAAAAAAAAAcBgAAdGFibGVTdHlsZXMueG1sUEsFBgAAAAADAAMAtwAAAPUGAAAAAA8A+APgdgAA
AgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAIADDBgAPAHIAAAAAwuhgD///8A/1wAAPXmRwCm
yuEAVn65AAhgqACqAUwAYADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAAAA
ow8+AAAAAQD//T8AAAAiIAEAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wABAAAA//8A
AP//HAAAAAABAAAQAKMPlAAAAAUA//0/AAkAIiABAG4AAAAA/wAAZAAoAAAAjgAAAEACAAAAAAIA
AAD//+8AAQAAAP//AAD//xQAAAAAAQAA0iUAAAsA2AACAGkACgBCAdkAAQACAAAAEgDaBQAAAQAi
IAEAZABAAt4BAAACABAASAUAAAkAXwD0AqkCAAACAA4AyAUAAAEAEyBkAIIDPgMAAAIADAAgAKMP
fAAAAAUA//0/AAAAIiABAGQAAAAA/wAAZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP//AAD/
/wwAAAAAAQAAAQUAAAEAkgABAAAAAACSBQAAAwATIAAAIwGTAAAAAACABQAAIiCPASQBAAACAAoA
gAUAABMg+gGQAQAAAABAAKMPbgAAAAUA//0/AAAAIiABAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAA
AAcAAAD//+8AAAAAAP//AAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD
YAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAgAAQAAAAAAAAABAAEJAAAKAAEA2QAA
AAAAAgABCQAAAAABAN4BAAAAAAMAAQkAAAgAAQCpAgAAAAAEAAEJAAAAAAEAPgMAAAAAYACjDwwA
AAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABIAAQAAAAAAAAACABAAAgAAAAAAAAAC
AA4AAwAAAAAAAAACAAwABAAAAAAAAAACAAoAgACjDz4AAAAFAAAAAAAAAAAAAgAQAAEAAAAAAAAA
AgAOAAIAAAAAAAAAAgAMAAMAAAAAAAAAAgAKAAQAAAAAAAAAAgAJAA8ADAR3GQAADwAC8G8ZAAAQ
AAjwCAAAAAkAAAAJBAAADwAD8AcZAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA
CvAIAAAAAAQAAAUAAAAPAATwlgAAALIECvAIAAAAAgQAAAAKAACzAAvwYAAAAH8AgAD7Ab8ABAAE
AARBAQAAAAXBBAAAAD8BAAAGAL8BAAARAP8BAAAYAD8DEAAYAIDDFgAAAIHDBAAAAL8DAAACADIA
AABQAGkAYwB0AHUAcgBlACAANAA2AAAAMgAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAAAAAAfhbe
EA8ABPAAAQAAEgAK8AgAAAADBAAAAAoAAMMAC/BgAAAAfwABAO8BgACwscsAgQAAAAAAggAAAAAA
gwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABh
AG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADLAA4BaxVZAg8AEfAQAAAAAADDCwgAAAAAAAAAAQDLAA8A
DfBYAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHls
ZQAAog8GAAAAIQAAAAAAAACqDw4AAAAhAAAABwAAAAAACQQRBA8ABPBKAQAAEgAK8AgAAAAEBAAA
AAoAAMMAC/BgAAAAfwABAO8BgADMtMsAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEB
ABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgA
AAAsAg4BaxWwDg8AEfAQAAAAAADDCwgAAAABAAAAAgDLAA8ADfCiAAAAAACfDwQAAAABAAAAAACo
D1IAAABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQg
bGV2ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgAN
AAAAAwAMAAAABAAAAKoPDgAAAFMAAAAHAAAAAAAJBBEEDwAE8KgAAACyBArwCAAAAAUEAAAACgAA
4wAL8HIAAAB/AIAA+wG/AAQABAAAAdMHAAABAeDgAAADAfTtAAAEQQIAAAAFwQQAAAA/AQAABgC/
AQAAEQD/AQAAGAA/AxAAGACAwxYAAACBwwQAAAC/AwAAAgA0AAAAUABpAGMAdAB1AHIAZQAgADQA
OAAAADQAAAATACLxBgAAAL8DAAQABAAAEPAIAAAADw//AJUCmBAPAATwrgAAALIECvAIAAAABgQA
AAAKAADzAAvweAAAAH8AgAD7Ab8ABAAEAAAB2M0AAAEBrgsAAAIBytgAAAMBcw4AAARBAgAAAAXB
BAAAAD8BAAAGAL8BAAARAP8BAAAYAD8DEAAYAIDDFgAAAIHDBAAAAL8DAAACADQAAABQAGkAYwB0
AHUAcgBlACAANQAwAAAANAAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAGDzEAqwG+EA8ABPCtCQAA
EgAK8AgAAAAHBAAAAAoAAMMAC/BiAAAAfwABAO8BgAA4vMsAgQAAAAAAggAAAAAAgwAAAAAAhAAA
AAAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAA1ADMAAAATACLxkQgAAKmDiwgAAFBLAwQUAAYACAAAACEAWuMRZv4AAADiAQAAEwAAAFtDb250
ZW50X1R5cGVzXS54bWyUkU1PxCAQhu8m/gcyV9NSPRhjSvdg9ahG1x8wgWlLtgXCYN3999L9uBjX
xCPMvM/7BOrVdhrFTJGtdwquywoEOe2Ndb2Cj/VTcQeCEzqDo3ekYEcMq+byol7vArHIaccKhpTC
vZSsB5qQSx/I5Unn44QpH2MvA+oN9iRvqupWau8SuVSkhQFN3VKHn2MSj9t8fTCJNDKIh8Pi0qUA
QxitxpRN5ezMj5bi2FDm5H6HBxv4KmuA/LVhmZwvOOZe8tNEa0i8YkzPOGUNaSJL479cpLn8G7JY
Tlz4rrOayjZym2NvNJ+sztF5wEAZ/V/8+5I7weX+h5pvAAAA//8DAFBLAwQUAAYACAAAACEAMd1f
YdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tY
Jm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRh
qUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyH
HbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8A
AAD//wMAUEsDBBQABgAIAAAAIQBLoo+PIQQAAL4MAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxW247b
NhB9L9B/IPhaOJbvXiPawPZemsJZGGunfR5LlKWYIlWSvm3Rf+8MKa+zQRIEcfoWG7BH0pBz5syc
oV6/OZSS7YSxhVYxb72KOBMq0Wmh1jF/v7xrDDmzDlQKUisR86Ow/M31r7+8rka2YrhY2VEV89y5
atRs2iQXJdhXuhIKn2XalODw0qyblRFWKAcOA5Wy2Y6ifrOEQvFr3ErtFtXckJU87OaGFSliiQYD
zhSUGPVRJIhhLQXrdXiz9gtLAHHMdLKxNRj4FjCpgT1m+AIHU/reYCotDKqnOYYTY2P0PheQWrqN
cZse4AmrQqiEpcqZO1YIM3VI1hMCAJlxTOIQ83a9LPji+nOqFlNmq/07neJS2DqNVMDokJny0lRo
H51lDOP3O1eDfrvH2RHtfnfY7UWECEbi4FiCDoNeuzvA5wk6tNqdIfpSogEIOVbGunuhLwbFaKOY
GyylTxR2M+tCqFMICqf0XSHlpQz4FKW6dBu2j/lVDyk5I/M7l4UThsmijPkwok/glFrlVqXexUEh
g41cSuUpzzJMHrO+FBaxRvoL7ecOE50eKcAK/7Gngiq/Xwg4DrBQuTZPnO0NoCbs31swgjP5VqEU
cEa4k2FOxupkqG051dLrCFSCu8QcZRHMqcMrXJ7osgI3U4sqIUfCTj2wPPwFpqobxWGHPuhFDpX4
XL8EX9+pIW3aRFq3cEccExdS4PfayRYpFOQaJ6P0GFKRPeIt0jjWnbPVCb3VskipcWmlNevVVBq2
A6Rh0qZvrakXbgL82MggQf2/W7D5vXZ5kXBWFS7J76AsJGqy00W6cjBWYE0arfaw3ipA8fnLgDTY
NQOe0h9BA1FQgpn5uqHx6A0M6f8LleJQ9+aJJ4bIlrBaIEdXrW6XaDIueAuYqYnZePdMKzf21K7A
UmvhyaDOj2n+4oSeb1Xit/cVoX7xBFfJPHGB39az/rzOzh4TkX3q62WKbrZKzk/HmfuKX/10tcWC
Lg9e2avt4unZvMM0ni8e8Iisxb8Kww1GoU6kWOxxEiyMMpn6E+6faNKNeu3optEf3941usNppzHu
34wb7dveILpp3fajzvRfFJs/XPLsBpxYFmWQg8G6bLZlUeoPRSgJMhbzD9D4Y45yk27mr4VqvF+E
U+ncsSys2MZcIWI64E2xwSZUeuEtzjbC0OsAntLYfTQBakfSK95SdLDL4kn87i+pgrKg1wP/bG60
zrxtSzeVAnCryOsnzMEw4gMl4c4LXXyrfE7T1DO+nam6DFuSYW37pvpIZX8Kk4KCr0nsdDx+vzhh
lNiPYv5WqkZia9Vi1agDfoqKWPihonLXjCSGWsZfVBgFECqdgwEa2Z+RSi2NZ6nU0nk53H9K5cun
0f8rlXPxwuzE32p0etfxrz/X/wEAAP//AwBQSwMEFAAGAAgAAAAhAE4PjN7aAAAA/AAAAA8AAABk
cnMvZG93bnJldi54bWxEj09rAjEQR++FfocwQi+lZi3Fla1RqlAshR78U6G3cTPuLm4maRJ19dM3
9NAehze8H2887UwrTuRDY1nBoJ+BIC6tbrhSsFm/PoxAhIissbVMCi4UYDq5vRljoe2Zl3RaxUok
CYcCFdQxukLKUNZkMPStI05sb73BmE5fSe3xnOSmlY9ZNpQGG04LNTqa11QeVkejwD3NnHs/XLfb
wdenzj/oavm4Vuqu1708g4jUxf/ndqjvF99/8Ff1plNLlucg9ovLzjd6iSGSV5DyUmyCICc/AAAA
//8DAFBLAQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEuij48hBAAAvgwAABAAAAAAAAAAAAAAAAAAKgIA
AGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEATg+M3toAAAD8AAAADwAAAAAAAAAAAAAA
AAB5BgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIAHAAAAAAAAEPAIAAAAXBC+D5gR
qhAPABHwEAAAAAAAwwsIAAAAAgAAAAcBywAPAA3wagAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAA
AKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA+A8EAAAAAAAAAAAAqg8aAAAA
AQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQPAATwrgkAABIACvAIAAAACAQAAAAKAADDAAvwYgAA
AH8AAQDvAYAA3MLLAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BAQAZAD8D
AAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANQA0AAAAEwAi8ZIIAACpg4wIAABQ
SwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFNT8QgEIbv
Jv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS/bgY18QjzLzP+wTq1XYaxUyRrXcKrssKBDnt
jXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnHCoaUwr2UrAeakEsfyOVJ5+OEKR9jLwPqDfYk
b6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD4tKlAEMYrcaUTeXszI+W4thQ5uR+hwcb+Cpr
gPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5/BuyWE5c+K6zmso2cptjbzSfrM7RecBAGf1f
/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVs
c6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4
jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZN
zzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAP
VAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEA8aFp
ZCMEAADDDAAAEAAAAGRycy9zaGFwZXhtbC54bWzsVlFv2zYQfh+w/0DwdXBt2bFjG1UKO6uzDm5g
xOn2TEtUrIYiNZJynAz77/uOlONm6Ipi7t5qA/ZJOh6/++6+o16/2VeK7aR1pdEpT171OJM6M3mp
71L+4XbRGXPmvNC5UEbLlD9Kx99c/PjD63rqaobF2k3rlG+9r6fdrsu2shLulamlxrPC2Ep4XNq7
bm2lk9oLj40q1e33eqNuJUrNLxBK79b1ypKVXe9WlpU5sPTOsbcWFXa9kRkw3CnJhme82/rFJQI4
lia7dy0Y8TVgcisekOELHEybK4tUEmxqLrfYTs6sNQ9bKXJHt7FvNwA8YNWASljqLfOPNWA6lV83
FQh7SvkfjbBeWo5c9ikPqLE6LgnGIYpD5mzz8N7kiCAab8CImO4LW52aEcUxRcGw/3AyTs57KO5j
ykejYa83GFM+Yir3nmUEMBlO+kPOMjgk/X5/cB7yjUDIsbbOX0lzMihGgVJuUdGQqNgtnSdqj1vQ
dtosSqVOZSCkqPSpYdhDyidD0HNEFiJXJSrMVFmlfNyjT+SUOuatzoOLF6WKNhJUOlBeFEgeWZ8K
i1gjGcYu9Pu5yR9pgw3+0VNRnP9dD5gKKNTW2CfOHqyANBw1teRMvdNQBLrJHwx7MDYHQzfVpVFB
TkJniJJyz1k0Lz2usDwzVS38Uq/rjBwJO3XH7f53Yeu2UTw69Nqst6KWn+uX6BvaJ6ZNQZTza/+I
aXEiBSHWTiWkUKHuMCBVwJDL4ga3SOaoO2ebA3pnVJlT49JKZ+82l8qynQAN8z59W029cJMiTI9C
ZND/+zVbXRm/LTPO6tJn24WoSgVNDs5A11ZYJ1GTTtIP8kVLRSghfxWRRrtlIFD6LWggCiphl6Fu
MG6CgS3Df6lzzPZgHnhiQHYrNmtwNEnOzogm66O3FEs9t/fBvTDazwK1G+GotXBA6ONjGsMY1KtG
ZyF8qAj1SyC4zlaZj/wmz/oLOjt6zGXxT98gU7i5Ojs+nRX+C37t002Dgt7ug7I3zfrp2VwgjeeL
a5yUrfg3cbgd6kSKRY+TYMW0UHk46P5MJr2fF8PBojOYzGads3l/0pnNYSX9t6PBaDQezgbjvyC2
9owpwTVOGQphUZX7pior87GMBQFfKf8oOr+uIDbll+Fa6s6HdTyWjv3K4oom5Rp46ZS35T1aUJt1
sDi7l5beCXBUo/dI/60jqRW3NJ3uqnySv4RLqp8q6R0hPFtZY4pgu8pfKikQqhdAxykYB3wkJN55
oYqvFc9hlga+m6Vui9CQCFs7tNQnGvtN2lxo8SWBtYP8BGmKaeY+2fOnSncy18ofVaPifZcUsfBN
JeUvGAkMSsYv9EUbSJ2vhBU0sD8jlVYaz1JppfNytH+Xyr+fRf+vVI7Fi5MTv/X08KYTXn4u/gYA
AP//AwBQSwMEFAAGAAgAAAAhAHkelHzZAAAA/AAAAA8AAABkcnMvZG93bnJldi54bWxEj01LAzEQ
QO+C/yGM4M1mK2JlbVps8aMUPHSrBW/jZrobupmEJG23/fUGD3oc3vBm3nja204cKETjWMFwUIAg
rp023Cj4WL/cPICICVlj55gUnCjCdHJ5McZSuyOv6FClRmQJxxIVtCn5UspYt2QxDpwnzmzrgsWU
x9BIHfCY5baTt0VxLy0azhda9DRvqd5Ve6vA3828X+7Om83w61OP3unseL9W6vqqf3oEkahP/8vP
1Wz+av7gr2qhc0sxyr9v307fwegVxkRBQc7LsRmCnPwAAAD//wMAUEsBAi0AFAAGAAgAAAAhAFrj
EWb+AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEA8aFpZCMEAADDDAAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBleG1sLnhtbFBLAQIt
ABQABgAIAAAAIQB5HpR82QAAAPwAAAAPAAAAAAAAAAAAAAAAAHsGAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAQABAD1AAAAgQcAAAAAAAAQ8AgAAABdELgOvg+qEA8AEfAQAAAAAADDCwgAAAAEAAAA
CALLAA8ADfBqAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAA
AAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAA
CQQRBA8ABPAGAQAAsgQK8AgAAAAJBAAAAAoAAPMAC/DQAAAAfwCAAPsBvwAEAAQAAAHTCQAAAQEE
GAAAAgEqCAAAAwHVBQAABEEDAAAABcEwAAAAPwEAAAYAvwEAABEA/wEAABgAPwMQABgAgMMWAAAA
gcMwAAAAvwMAAAIAbwB0AGMAXwBuAGUAdwBfAGIAbAB1AGUAXwBkAHIAbwBwAHMAaABhAGQAbwB3
AAAAUABpAGMAdAB1AHIAZQAgADUANgAAAG8AdABjAF8AbgBlAHcAXwBiAGwAdQBlAF8AZAByAG8A
cABzAGgAYQBkAG8AdwAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAQDwoTSBanEA8ABPBIAAAAEgAK
8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEBAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA
BAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAA8AiBOy
AAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJAQBAAAACQ8AihN5
AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE1kAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAA
J/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAFQJ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkA
AAAPAAIrAAAAAAAAIwQVBwAAUEsDBBQABgAIAAAAIQAo12LI+QAAALsBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbJSQu27DMAxF9wL9B0FrEcnpUBSF7Qx9bH0M6QcQEm0L1QuiEiR/X9rJEHQI0Emg
JN5zyHZzCF7ssZBLsZNr1UiB0STr4tjJ7+3b6lEKqhAt+BSxk0ckuelvb9rtMSMJ7o7UyanW/KQ1
mQkDkEoZI78MqQSoXJZRZzA/MKK+b5oHbVKsGOuqzhmybz9ZoDiL4gtK/YDAHG0LafJ8+Q5U2e+y
WCtOl+L5FDObdBJy9s5A5Tn0Pto/Dqs0DM6gTWYXmKxyQeJz+R68ugDdzdG6b19wgJ2v4vXAqqft
FPT0P+p5asWdC4oml+kK4fpYZzO9rL7/BQAA//8DAFBLAwQUAAYACAAAACEAjuoq+r4AAAA4AQAA
CwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2I0IMX0Q9Ykm0bbJOQjaJ/b44WBI/D
MG9m6vY1T+JJka13CqqiBEFOe2PdoOB2PW32IDihMzh5RwrexNA261V9oQlTDvFoA4tMcaxgTCkc
pGQ90oxc+EAuO72PM6Ys4yAD6jsOJLdluZPxmwHNgik6oyB2pgJxfYfc/J/t+95qOnr9mMmlHxWS
J2vojJwoZizGgZICE/nbWIiqyPtBNrVc/G0+AAAA//8DAFBLAwQUAAYACAAAACEADec5NOYDAACC
IgAAIQAAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOyawXLaMBCG753pO3h07VCQ
jbFhMJkkHU6ZTqZJ27MwAtzIsscWacip79BLz32VvkmfpCtZgI0hYWjo0LFvTiStpW/X2n836Z89
hMy4p0kaRNxD+G0LGZT70TjgUw99vB02XGSkgvAxYRGnHlrQFJ0NXr/qxz3xcCMWjKYGmOBpj3ho
JkTcazZTf0ZDkr6NYsphbBIlIRHwYzJtjhPyFUyHrGm2Wp1mSAKO9Ppkn/XRZBL49F3kz0PKRWYk
oYwI2H46C+J0aS3ex1qc0BTMqNWFLQ3k8QLBqDrhoE967J7h+DoxCJsCJ4aMRDAPSVrkil8kd+p5
EnFxriaMSEqRMSN8Cqe9nnNfyAnSUBr7F3Sin659YdwTZag56Dc3Rs8n4ol5enRMJx9gX+mjh0y3
BRsagRuzN0UsGA8DxpQR6RN6yZLsfeIBI/3G/CwJkhtiEdMJ8cHbb8IvDSbkTNKjZGOAkmzATzcG
/FTbzvamDqb5SUPwaFYP5SeajAknyIgD4c+GJAzYwkNWGxn+jCQpVQGSuaSITbLS2Kwa297YJCuN
rV1j2xubZKWx2TW2vbFJVhpbR2ILSXLlobbtQJpD5aSxkSjkyv8qLxx8mUk4mpOz5tTF7XbNSebx
Za6UcDQnd80JWw7u1KDyoCQdDaqbA+WarhJDJblW2S9P0oHoKurauDeKxouSyM1uL9O026aNjICP
QSR7qLH8RQnqy2hguAIgtg/VwaP5zeNKTmO8tEV6o/klCCylsjz0+9vPTLTmZbN87QvLZr5LNvPG
DtnMG3vK5sw5NsbYyTsHdzodF4q1IzlnBfSgIqXonJatHS2dM4SaKVc/fIZ6SRafUMgVhLKZ08lm
5sKCY3/9yPtVJdR8YaNK0gPKn6Uf4dRPq/LMK8tEtvpksG3b0k0n6pVnvgyVbI7PclOqZywxSCds
w5e5hom7rY51sjBz9083H+HPQZbS5/iQN4W9hgw3vArQNeSWA7s/WcgFmN/z37xqgcig+Qcwt8t9
7LqmU7yUd8HcW4b87b17Gry2y37TsrrdmpfS/MXssl3+m07X2Uj6dXypfuL2KsACAWvV8bUlvlbF
QE7+x71IzGiyKgYgIq+z2kprZQbdbA89zhqX7+W9m0kiPWXZHs+ySj59wOJbMrqB9vRSHJU65xgZ
qvG8bqQXG+dZO1vvQja6sart7mgi/2RxlBu/1O5+Kd1eaglVls9mX7uooFeCubJ8dqjiUguosoB2
KNpS66eygLarVNN0oYdYX9GQsnbIUqdtFdv2lY2g7TpU0in26ysLaIfw7NhOsU9fWUArpZkXl7IL
rf95ZPAHAAD//wMAUEsBAi0AFAAGAAgAAAAhACjXYsj5AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAA
AAAAAAAqAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEADec5NOYDAACCIgAAIQAAAAAAAAAA
AAAAAAARAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAA
ADYGAAAAAAAADgQaDQAAUEsDBBQABgAIAAAAIQCCirwT+gAAABwCAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqJJd30s0g8Y5LEtao+ENAnJ33fsuFC6CC10IxBi
zpl7Va6P46AOGJPzVOlVXmiFZH3jqKv0++4pu9cqMVADgyes9AmTXtfXV+XuFDApmaZU6Z45PBiT
bI8jpNwHJHlpfRyB5Ro7E8B+QIfmtijujPXESJzxxNB1+SoLRNegeoPILzCKx7Cg8Pv5DCSAmAtY
q8czYVqi0hDC4CywRDAHan7oM9+2zmLj7X4UaT6DF9jNBDO/XGD1P+ov5wZb2A+stkfp4lx/xCH9
LdtSay6Tc/7Uu5AuGC6Xt7Rh5r+tPwEAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsA
AABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsI
hKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYw
lRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzl
RQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACK
AAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLL
rrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0
jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQU
AAYACAAAACEAhJdIX6cHAABbIgAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsWW1v2zYQ/j5g
/0HQ9y5+zwvqDq5jbwO6LYiz7eNAS7SlhqIEiU6c/vo9dyRlKbbbtA22YUsLONTp0R3vlUfy9ffb
TAV3sqzSXI/D7nedMJA6yuNUr8fhbzfzV2dhUBmhY6FyLcfhg6zC7998+81rcWESmckA3+vqQozD
xJji4uSkikAW1Xd5ITXerfIyEwaP5fokLsU9+GbqpNfpjE4ykeow0CID2/skNfLPVBup/sy1egjf
eAEzBSnaVESIVLkg9vLIV0GPv4tvu4SuyvVyqsrgTqhx2DkbdSZn4cmb1yfiwgGU2cfN+Z/DOUB8
29vjNx/ORoPTmh8DlDmAmw+nNc4BRBRBo33Zk9F0Mus6ng2QHe7zHo5OZ2/PW3gGWXx/f85N3Rog
Oxzs4TujYfds3uLPIIsf7uEvO7PubNbCM8jiR3v4weVpb+Jt2AAlKtW3e+jOtDc7GznuNWSVqx8P
wieTTncwdfAdCt6vo4hErHJtPhpTIaEy8T4v54DSgxIm1YF5KORKRIjd32UZCy1IlLiQovHGkqLq
EQlzaDHMUv3M3HcMIWunIiuctfX9dbVKI8larlKlFuZByXcVK1rlKo3nINJ3nNeyzqciwdBZt4Vb
l4K/Ccrc/JGaZJGIAkbqsoR15Vivq6DIK6Qlkw/yJqEwtLH5O+zgn7VnJczPeWzJfSIzHYrWbDjJ
11wyvKA+MXiqsP6pYwqeXyKsS5N6srQuT42jpyWtVvmgaiDW1kQCBIIKdneEykqigyoSSsZkd1vy
vFvIqn78LC6qEhFL5yPSe99HXXaSjxWu34idAz4646kfDTZ+sZN2Tmy/QtpTnNRQ7nxwRJz33td4
yUew9wwb53E6Kt1MTqWD+3F4PuwNwyASxThcoS5hmBXweqXXYSDUGkt6ZEob9p9M5sf29Yq1k6Db
8fQ9hVt1oCgrcymqxIYGv3IhoDRJsvPvDWHW51LARvoXzKJ/hmD4x2YBO7ZdK1crGZmmsxsUsp19
dKU03xhZLpL4PliqTXkt4H4KVegTp5UZh1wR6KEch2RtftUuzq5UtfolCyRpQhWJcOWWUtRnsoVz
qNZz4KfG9KDbwbmzcp+vCqf8M6nSDOP/mSq0VEot+zF5IEIDXoqA8nUc5qVJclShIkmjeYmGh2sH
oiVAdaHlOsA2gP+W8o7+2pyzPIibSteJuU7XQZliPTJJKeUVyhJH3yeYdd3aZVl6RhxRjelWhZ32
Ut5JdUM1cERrexgkCHWuJq4MMO5x/LWfXQYt19TkNPOtVUPqtsLmwN/d+dhkhlLtOswNjbd/PUW2
Vrvzsd/z537tbSpCL3Zt1sBnBYQ1ltpzl/ZfOIXPXGptxdrTuDf0k4MX9zUGsW6ICmGSgH6w/qVl
pHb97U1+jdoaYEdIzBA2iOpXtvEIqEBa4hKNkyXaYCJW1rSuuyWr+cX6WdqonQtquY+MTTN7ir8/
09h1c9YW18rF5zS2s3DL1pZ21NTw7OMUBWnlNzLsGD6MaJ4V5Mv3cPQl9mgbZU8PqgJPnAfFVRks
77GJwMZEbEzORW67KjN6m69WwZZL3IMrcFjDtiaIQOyiSQDVN9X+k2hTmR9kzp+LO1QVjt117Eci
8aNoq/2wdHFoYxC/MAl+EXrsZXFBQWfB0LYp4mPVyW6j/QRbSNtxDTsIsK/vdcz2oIwjXZ+4KPON
jtksiRTxTMe8Jx6HGqdKIVXxTMZYXCQWFxox0ohUPQUJ89iesm48bChV8DN5dJnHD/A4TrmQ7Ele
foBALHFeuPpJYyd63h0MyBX8MBie9sgjzTfL5hu9yaY5iggCQugIPG2j7R6mxvoyyjM48Z1eFBFB
aS5koJvtH6Is3IprEFu/5LxLZoCPHyi1w3KIWzWIiapsd0jjWK6uoFwmynccPxhc8yDVMU6ZeLjb
CQSA34jl4oNTmJQ0dDyGYz/xTr8tb3lMRwYT3j4sRQX/8JHH7nWCzSYO8q42OmIBPCfSkgZVEV2h
wvKpm6tF1h1ocmvEW5+JO2xd24po93aysicRDZ4NnHu73GA/ebPlmFluFh/qIZ3Y1A+/INJcWC19
DsIa1zDe7SZLs/x9yror3klL/eq3BbbRMFQPK6jLy8BCNj50KlOmtygiOl/wyOWVDWoc6mRCpR/k
j8yXLImNOtDgVmVmqqTgVspaj351To2ItxYb8yO7tiMp2EwChMqRw6qgSE2UzEWWKhS0/gAzT0RZ
SfannYE1DoeeDTIe7mIPEVqXVKUvvUdfauvXbsePOPaltlKhfamtL7UVt0b//drqSiqq7H4ri56h
FFj0Fryjw2pGa0WbSJTII47dl9me5NB92Rz3VvV24xnuy1q3N+5C7eB9WfNe7R++L5tMJpfTvjvi
sI01X6rZ4YDX5+aZ2eWE/rfwDLL4v/2+rHnj+Wz3ZQipn0URLNfdcQg3omHeYoSLUnRI6x7RMDJb
jOA8NMf2qhPbLDvwFLy3lBrT95S+xww8Bc2JM6Gn4MzbUkaeMsIBEN0DosGnP2Hgr/xwMO6uCJ1j
9tNkn/LJxHm5aKbotz54uWh+ykVzM3E4XThxOF04cThdOHE4raxpkVpu4AP+X5Q4WJnamcPrEKh8
FvPmLwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVs
cy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs
7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYk
UiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04Goln
Lx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQCCirwT+gAA
ABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
AGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFAIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54
bWxQSwECLQAUAAYACAAAACEAhJdIX6cHAABbIgAAFgAAAAAAAAAAAAAAAADRAgAAdGhlbWUvdGhl
bWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAAKwK
AAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAA
pwsAAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRh
bG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv
cm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJs
dDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQz
PSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJh
Y2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAADSsEAAAAgCYfmgAA
CyvyAwAAUEsDBBQABgAIAAAAIQBCPNB49gAAAKsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSQ
TUvEMBCG74L/IeQqTaoHEWm7Bz/Ai3pYf0BIpm0wX2Rml91/77S7IHhY8BRC8r7PM9NtDjGIPVT0
OfXyVrVSQLLZ+TT18mv72jxIgWSSMyEn6OURUG6G66tueyyAgtMJezkTlUet0c4QDapcIPHLmGs0
xNc66WLst5lA37XtvbY5ESRqaOmQQ/fBAtU7EJ+m0ruJzNGuoiYf2eMtjVlxnRRPp9yC7qUpJXhr
iMX1Prk/0CaPo7fgst1FRqlSAflcv8egfptvlmY9dM8wml0g8XJgtdM2KgT8H/Q8peLkSsLZF7xA
uDzV2Uyvqx5+AAAA//8DAFBLAwQUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAF9yZWxzLy5yZWxz
hI/BCsIwEETvgv8Q9m5TPYhIUy8i9Cr1A0KybYPNJmSj6N+bYwXB4+wwb3aa08vP4omJXSAF26oG
gWSCdTQquPWXzQEEZ01Wz4FQwRsZTu161Vxx1rmEeHKRRaEQK5hyjkcp2UzoNVchIhVnCMnrXGQa
ZdTmrkeUu7rey7RkQPvFFJ1VkDq7BdG/Y2n+zw7D4Ayeg3l4pPyjQmbny7COhlCoOo2YFdjEi3tV
/gXZNvJrX/sBAAD//wMAUEsDBBQABgAIAAAAIQBHKtdt6AAAAIUBAAASAAAAZHJzL3RpbWluZ0lu
Zm8ueG1sjJAxbsMwDEX3Ar2DwL2R26EoDNtZgk6ZCvcAgkTHBCxKkJi0uX3p1B26ZSIJ8j98/m7/
HRdzwVIpcQ/PuwYMsk+B+NTD5/j+9AamiuPglsTYwxUr7IfHhy63QlGvjAK4tq6HWSS31lY/Y3R1
lzKy7qZUohMdy8mG4r5UEhf70jSvNjpi2PTlHn2aJvJ4SP4ckeUXUnBxoubrTLn+0fI9tFywKuam
/mdpWJ/jY5W1ya6sxY9sKGhCYMJZzRIHnIhJEIxyxBXpgVGTBMMp4HjNmpbEj5QE7NDZjaR1Q6/d
LcHhBwAA//8DAFBLAQItABQABgAIAAAAIQBCPNB49gAAAKsBAAATAAAAAAAAAAAAAAAAAAAAAABb
Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAAAAAAAAAA
AAAAJwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEcq123oAAAAhQEAABIAAAAAAAAAAAAA
AAAACgIAAGRycy90aW1pbmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAAAiAwAAAACgAB4E+AUAAFBL
AwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI
/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW0
8UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8
rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KD
y7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXf
QF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOE
j8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQg
yGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2
MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9j
Iaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQA9yYcCxQIAADYIAAAhAAAAZHJzL3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDEueG1stFVNbxoxEL1X6n+wfE8WFliiFRC1tOklHyiQ3l2vyVrx
2pbtbKG/vmN7TRRKJQTtZT/smTcz783Yk+tNI1DLjOVKTnH/socRk1RVXD5P8dPq5uIKI+uIrIhQ
kk3xlll8Pfv4YaJLK6pbslWvDgGGtCWZ4to5XWaZpTVriL1UmknYWyvTEAe/5jmrDPkJ2I3I8l6v
yBrCJe78zTH+ar3mlH1R9LVh0kUQwwRxkL+tubYJTR+Dpg2zABO836fkthqqBWLcijvBPslqtcEo
2JsWdvp4BhTQpaiQJA0sfAdTTolAwR4BY2jFNi6YWb0yjHkH2X4zeqkXJnjftwuDeOXROhScdRud
WfiVYAYf2Z77c0Ii5WZtmtmElMAO2kwxiLj1T3AiJSSBaFykb6u0fjhgS+uvB6yzFAAy2AUF/XWs
6M9y8lTOHin9XXnRhwDGraIvFkkFBXseYp30vk2ovngfR9coauK8Hhgpw0G5KFHnFU0DTcnbBqpT
/juCimIwGo8iTYM8z4vBe67yXnE16g8w8oyNimExHoxDkIQEQSK0Lt3ms6q2nukf8AZBfdNMMSO+
+AgrrFu6rWBBD2CNlFASPMBYED9oTF48LTEiwt2G/1/1xfweBq9xc8EIDGanpZvNBacvyCnEKu7Q
HbGOGRQogTGFEBMQy0GvdCGYrBbEkMddpA55FylG9qyTEjKDulI9oUTP/N91BoL2m99320IQymol
Kkgt9wzAoCRBT5LcE7unOIwN9HTql+OVH+ZXRT4K83FI+KI3Go79/v8SHvoRiVbsFP3HjeDpD31g
3zVCFDcoDI+UQmDvjF5cMqrgmBOsZeKIcKEVzgi3qrk5Plo30Sfze6NejauPLm4YJ/30cHx9MBqc
32ePcJjkeAPBp7+zwkgKc0f0QxtShtsaDpJ5WNJwP3fH8JuJx0j3/ew3AAAA//8DAFBLAQItABQA
BgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAD3JhwLFAgAANggAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxh
eW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAAZBQAAAACQAB4ErwUAAFBLAwQU
AAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOU
LWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL
33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusb
qYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OE
pfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3
yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EK
wjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlv
rOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+
YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi
7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQCea64LfAIAAFYHAAAhAAAAZHJzL3NsaWRlTGF5
b3V0cy9zbGlkZUxheW91dDEueG1srFXLbtswELwX6D8QvDtykqIoBNsB6ja95GHUTu9biraEUCRB
Mqrdr++QlBykdQG3zkUPand2Z4ZLTa62rWKddL4xesrPz8acSS1M1ejNlD+srkcfOPOBdEXKaDnl
O+n51eztm4ktvapuaGeeAgOG9iVNeR2CLYvCi1q25M+MlRrf1sa1FPDqNkXl6AewW1VcjMfvi5Ya
zft8d0y+Wa8bIT8Z8dRKHTKIk4oC+vd1Y/2AZo9Bs056wKTsly2FnQVbCBNWW85SnOuwcs5noC6W
qmKaWiysmqAkg0DsG4IbQYqt5DakMG9XTsqYoLsvzi7twqXsu27hWFNFtB6FF/2HPiy9aoThofgt
fTMgUbldu3Y2oRKqsO2Uw7xdvCKJSjTBRF4Uz6uivj8QK+rPB6KLoQA62BeF7zYz+pPOxUAni3K+
Z5VDCak3Rjx6pg14RvqZnrjrBrDIOcLbmmULQtS3j8sfkx5DvIemSayw/WiqXST+Hfe0SKXyYRl2
SiZB0DaVAMcF8iuKO1zq0cOSM1LhJr3/rEfzO+z4NsyVJExEL2aYzVUjHlkwTFZNYLfkg3QsNYf5
QIkJ1Aowqy8hdbUgR1/3lXrkfaVcOfKnEp2B1MAAj1nivwt9OQj9Ys+xhSIha6MqtHbxGuJHKTkz
rsGQ5Gng2LfYVINz/+JIPGaAIik2Hbs75A/sZKpTe+Ff2a84FMku/8Kv7EEyApehhUTyhC2zlMLg
XFCyk+qIcsmxE8qt6sYdX+0yO/Df+l6bJxfqo8m9O7Vcsz5YDefcyZOWBi6f1HiMZ3s6jJW7JXvf
JYXwN8O8z9OSxf8rzi1Cn0MixvA/nP0CAAD//wMAUEsBAi0AFAAGAAgAAAAhAE2O8/z9AAAAuwEA
ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA4
3L4AAAA4AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAnmuu
C3wCAABWBwAAIQAAAAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEu
eG1sUEsFBgAAAAADAAMAyQAAANAEAAAAAIAAHgSECAAAUEsDBBQABgAIAAAAIQBNjvP8/QAAALsB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5QtatJhgRBqOwseKwQshg+wEreN
yEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vfd0/VLWeUwWuwwWPLZyS+7S4v
mt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xupgs/oc5WXHbxrHrCHyWb2eCjl
o5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl8zfgpHstr0lGI3uDlF/AFRtS
J5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI9fXdJwAAAP//AwBQSwMEFAAG
AAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4
Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxt
s17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA
3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwME
FAAGAAgAAAAhAKTtb5JRBQAA7xAAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54
bWysWNtu4zYQfS/QfyD0WmQd+R4jzmLjNm0Bb9ZYe9FnWqIiNRSpkpTj5Os7w4sludnC8PrFoajh
IWfmzBwqtx/3JSc7pnQhxTyKP1xHhIlEpoV4mkffNg9X04hoQ0VKuRRsHr0yHX28+/mn22qmebqk
r7I2BDCEntF5lBtTzXo9neSspPqDrJiAd5lUJTXwqJ56qaIvgF3yXv/6etwraSEiv16dsl5mWZGw
X2VSl0wYB6IYpwbOr/Oi0gGtOgWtUkwDjF3dPZJ5rcDbqkg2+4hYM7WDiTi6A8+TNU+JoCVMrIrE
1IqRl8LkZEErPIe10dVGMYbWYve7qtbVStmlj7uVIkWKUB4i6vkX3sw+CjCDQe9o+VNAorN9psq7
WzqDiJD9PILEveIvLKIztjckcZNJM5vkX96xTfLf3rHuhQ3gBIdNIeeV8+i/7vSDO5vCcEbig1fO
lMLSpUyeNRES/ET3nXvJ4y6Aoc8IX+XEhd8glLdzL208gr22MQ0HPUQintz0+1PgLXg+nALLro+i
MhpOx0OYJBib0Xg8GUztJgEJNnHQ1czs72X6iiHdwl/IHBVJLoGpW1xBZ1ybtXnlkGcY73gMJyKU
P0EpcWABnaUs+wpT+m0eAd9hy23w/GAPSe7iQIjpDAIBP7CUU6xEJq6+rSOANkv7/JZfLR6hMkuz
4IzCdt5Fc7fgRfJMjCQsLQz5TLVhithAQh3DSXE3Y/e0WzCRrqiieEi3k0c+7OR2xlzRGZwMYhNi
YsOE+fo+KQaBFKFMVpwmLJc8hUP1MYRQTIEAZ1EEKjSCcgKuB0KdR5Rx3J9MRi6poXo6PBnGMZLp
ZKJATzXQgqR6i8iLosB4/U9NFYsI/1NoW68mDFQYbMNA1OVCctskAuMMpN+Sb2GAf8heWVbULMW6
StAQCVMpbTb7v6iqoGdp2N+AL49yndOKWQO6W2rjk3mwtbl1/EaQ9zhdUrW0mxYihYaJQzTd1o+g
CrYSWkwfANV9nHxNWNgd72N5OKjhaIJW5BS8fhN3wEMQjzdo8G7ioS3pk/DQ0gUB8BDE4w0bvHgw
ibFxnHZALO0DIKJ4wFELcAo96TxARPGA4wYQehwc8KwTIooHnLQAJ0ObuTNcRhQPOG0AEe30pHRi
iCge8KYFOB5NzkwKoliet9ltO20DD7EEcn61PAdiHPH90NcJUH1Dt2vo6YF1yjhrRpfiXj3blZkU
5pOVgi3VWPZwyxDN6xz6OFyEVrVIDuXEsZbRbV0lq8SQHcUWAIFp6NWyuGfZsS1E+2AKGI3Fpwx6
fhc3MBbs/NttveBqs7flvK3Xb80R7BmQ4VjyD+DYwepQ/4ZuXWsJoufqweexJTPPdVmU8u/Chbmt
ZkeaY1XTMdKqJnFL6nkkoOngtVQVz3AFE3JtRxF5ZspKIUmw33or7I6QWYGXUF68sT/sI+aEF3ij
te9WSsrMjtuSiv5ygb9CPhSc+xK3M1ryIsVJG1e88DKInkuZ2TsxgoC3rViWscSEKNVL4aNYI4wf
W5bY608GSjmPfinFFTcu9IwevWDUvUj00YtE+3bUxP08AR8GAd+gKLbVe4A7/Kh6o+hAIqGScsoz
L+T2XgCXi/OEfDSA+5y70DX34I6ST6/h/uc2OeHGZ0nfbhpe0ryOndh/447k4DXRcutsSYw7Evvj
kogF7ilzGUm8aeNdQBE7eBcQxA7eBfSwg3cBOezgXUANO3j/L4Ze+izxLU0v9xmCTcR+hejOZ8j3
Pi3sF4b7jIYhfnXblsPVZ1p92dmzwb8Z4AMHOi9MVaCn2KLBtDFBjPCPirt/AQAA//8DAFBLAQIt
ABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAKTtb5JRBQAA7xAAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlk
ZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAClBwAAAABwAB4ENgcAAFBL
AwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI
/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW0
8UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8
rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KD
y7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXf
QF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOE
j8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQg
yGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2
MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9j
Iaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQABkvB/AwQAAFsOAAAhAAAAZHJzL3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDEueG1szFddk9o2FH3vTP6Dxu8bsI2B9SxkpqTpy2azE8gPELZY
u5Flj6wlkF/fI8libZcGd2lm8gJGHJ37oXPvle/eHQpO9kzWeSkWnv927BEmkjLNxdPC+7L5cDP3
SK2oSCkvBVt4R1Z775Zvfrur4pqn9/RYPisCDlHHdOFlSlXxaFQnGSto/basmMB/u1IWVOGnfBql
kn4Dd8FHwXg8HRU0F16zXw7ZX+52ecLel8lzwYSyJJJxquB/neVV7diqIWyVZDVozO6uS+pYIdpy
+9fm4BEDk3ss+N4SkSdrnhJBCyysSqHAQL7lKiMrWmk/DKauNpIxjRb7P2W1rh6l2fqwf5QkTzVV
Q+GNmj8amPkpAMPDqLf9yTHR+LCTxfKOxsgIOSw8HNxRf2ITjdlBkcQuJi+rSfbpDDbJ/jiDHjkD
8OBkFGde2Yj+GU7gwtnkijPin6KyUIqt92XytSaiRJw6fBte8rB3ZDpmTV9lxKZfaaoGZ/80+XD4
2uTUOXrKxCSaQVsmHcEsHEe9nITj8Tz0Q4/ozPj+NGgQ7YgtcxWrw+9letQZ3eIbB0dFkpUQ6tbm
mddqrY4cx0xjvuc+HCKUP6GSOERA45TtPmOp/r7w4BJ82rrAT3icMZ5bPMgwjZEHfGArp7oQmbj5
svZAre7N7+/ZzeoBhVmoFWcU5poY1XLF8+QrUSVhaa7IR1orJonJI8oYnmprytg0JphIH6mk2klr
qWE+WbKW9VHRGJ4h/y4neLRq+HdNIMndKnnkNGFZyVM4FVynkDyFvp2IhosjjGaRPnBdLOfUEfm+
D4RVRzSPQh9SseHbgjNhW526TDh1mNJrH2UjiZ4SQq1OS9kC4DFo9NxWzbyNdQBgwzPYSRvrAMBO
zmC1Gk8+OACw0SWsAwA7vYR1AGBnl7AOAOz8EtYBgL29hLWAczWGnQQMp+L5n2tO92BTcnWn5mwd
mWLCh3PBCPmKsl+zpBQp4WzP+ABzpvauMLfJcjncmimgK6x9KJ8lpuvQ4CZa2NeYy3dnrWGs/tRu
OXHdcqOl026VJoG4drhR+aphqicYRgZGUUb5zsMdBA3UCMEMVd3SzMPaVJRu7nrpR9PVn4SRb/vI
y5WjM14n01t/PL26gZKCyntzxclFituWftSubZ8fcCk1p93qmX6nD+qZrLGodN0+Gyp3RxjE1+nX
vR7c8N36E22VDOLr9N5en274/HDmT4cS3v6glzu+eTDXo2SQgx2+Xr9v+IJgDvdew9ebCY5vNjFj
8b/715sbDZ8mG3wgnXh7s8XxTaPZ687j15w/qHR3ezEXGlP77pUFK/oNx7yVcPmRVp/2poTwSofb
5MosVXiJ0/cHQF8gmsq9FC7/BgAA//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAA
AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAA
OAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAGS8H8DBAAA
Ww4AACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBL
BQYAAAAAAwADAMkAAABXBgAAAABgAB4EdQQAAFBLAwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAA
AFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa
/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFY
UXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4
uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvx
GeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAA
IQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZ
tsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1Vca
MeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/
s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAI
AAAAIQD/7vRhQgEAAHACAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sjFLL
TsMwELwj8Q+W79QtB4SiJpV4XoBWavmAxXGaCL+0dkPy92zcBATqoRdrPZ4Z73i9XHVGs1ZhaJzN
+WI250xZ6crG7nP+vnu6uuUsRLAlaGdVznsV+Kq4vFj6LOjyBXp3iIw8bMgg53WMPhMiyFoZCDPn
laWzyqGBSFvcixLhi7yNFtfz+Y0w0Fg+6vEcvauqRqoHJw9G2Xg0QaUhUv+hbnyY3Pw5bh5VIJuk
/ttS7D2l/dBgPzlLNGwJWPCCksutLpkFQ8BdYgxg8DtUaqhs+4x+6zeYuG/tBllTDtpRw8V4MNLS
1hKNCvFPvp+cIOsqNMUSMnoC1uWcJtUPK4kgU11k8gjKX1TW6xNcWT+eYIvpAurg51Kqp1hUDrFT
5xpfwa9bygcZzTkqvE+Qp8keM8hfyuAx/ZTiGwAA//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAA
ALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
AP/u9GFCAQAAcAIAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlv
dXQxLnhtbFBLBQYAAAAAAwADAMkAAACWAwAAAABQAB4EHwUAAFBLAwQUAAYACAAAACEATY7z/P0A
AAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsLHisELIYP
sBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFrsMFjy2ck
vu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28ax6wh8lm
9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9JRiN7g5Rf
wBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD//wMAUEsD
BBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGm
vYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9I
wUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwU
xLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMA
UEsDBBQABgAIAAAAIQBz0UX17AEAAOIDAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91
dDEueG1sjFNNb9swDL0P2H8QdE+d9DAMRuwCyz4uaRIs6Q/gZCY2KkuCxHr2fv0o2U63todeLIl6
fOR7ptZ3fatFhz401hRydbOUAo2yVWMuhXw4fV98liIQmAq0NVjIAYO8Kz9+WLs86GoLg30iwRwm
5FDImsjlWRZUjS2EG+vQ8N3Z+haIj/6SVR5+M3ers9vl8lPWQmPklO/fk2/P50bhV6ueWjQ0knjU
QNx/qBsXZjb3HjbnMTBNyv6/JRocq6WGNO6NHqRIUN9xcCVLVq+OuhIGWg6cIkokWLwJ7uQR4850
P7w7uoNPCbvu4EVTRYIpUWbTxQRLR8Mw3mQv0i8zE+T92bflGnL2QvSF5F82xC8nQY49CTUG1XNU
1fs3sKr+9gY6mwtwB9eiUdWo6LWc21nO6MPqqmqEAqdurXoMwljWGeWP8tSum8mi5kjvavGP8RNu
vEx+zPjAniazqP9iqyEK/8VrCkKuAx1p0JgM4bYhZ3L+sP0a4lyjWTwcpQBN23T+Uy82O57zljYa
gd/BZCaVG92oR0FWYNWQuIdA6EWaCn4VXGLNbhH/rKkEmuoAHn5eK03M10pj5agfcu6MRc0KeBst
Tss4P7yNQ5ZGRPt7cPsu6eCXxV1sUsjxW5rcfIZEjvltln8BAAD//wMAUEsBAi0AFAAGAAgAAAAh
AE2O8/z9AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU
AAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAU
AAYACAAAACEAc9FF9ewBAADiAwAAIQAAAAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRlTGF5b3V0cy9z
bGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAAAEAEAAAAAEAAHgTLBwAAUEsDBBQABgAIAAAA
IQBNjvP8/QAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5QtatJhgRBq
OwseKwQshg+wEreNyEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vfd0/VLWeU
wWuwwWPLZyS+7S4vmt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xupgs/oc5WX
HbxrHrCHyWb2eCjlo5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl8zfgpHst
r0lGI3uDlF/AFRtSJ5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI9fXdJwAA
AP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/
EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fN
HgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZ
vxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3
+QAAAP//AwBQSwMEFAAGAAgAAAAhAAkaYlmYBAAAmRgAACEAAABkcnMvc2xpZGVMYXlvdXRzL3Ns
aWRlTGF5b3V0MS54bWzsWW2P4jYQ/l6p/8HK9z3ICxCihZNKe/2yt7sq3A/wJmaTXhKnjpeF+/U3
M7EhsHBKs61UVXwBkzx+PDOeeTwJtx+3Rc42QtWZLGeO+2HoMFHGMsnK55nzZfXpJnRYrXmZ8FyW
YubsRO18nP/8020V1Xlyx3fyRTPgKOuIz5xU6yoaDOo4FQWvP8hKlHBvLVXBNfxUz4NE8VfgLvKB
NxyOBwXPSsfMV13my/U6i8WvMn4pRKkbEiVyrsH+Os2q2rJVXdgqJWqgodnHJuldBd7qV7narl7l
w9OfDiOw2sBl15mD//EyT1jJC7iwkEXFVVbLku7U1UoJgZhy87uqltWjogn3m0fFsgQJzERnYG4Y
GP0sAQaDwcn0Z8vEo+1aFfNbHkE02HbmwKbt8BMm8UhsNYubi/Hhapw+nMHG6W9n0AO7AFiwXxT2
u2o8euuOZ91ZZToXzN171UA5TL2T8dealRL8RPcb9+L7jSVDn5G+SpkJPVIZXHOT4mHxNcXUGrqP
RDCaQF5ROLxJMPbD45iEnjcd432MjOsG/hB+oC2WCNZomKtIb3+RyQ4j+gTftCM8ymu91Lsc9hbG
m9w1ViRi/UezZ63LQNqGQ/R4BD7CB2RBzrHARHnzZekwnus7+v0tvVncQ8EVepELDgVp9lTPF3kW
f2VaMpFkmn3mtRaKaQp3jQahC5ocoSVEmTxyxcEos5Jh3q/UrNy4DpaB39ZfCgFuxeX99vf7jcn2
mPNYpDJPwCIPowmlYTe219ZjvB2oE0himym9MsAd+SPX9Y9TIBgGQzcEVcMUGPvTyZhs7pIBjJdx
KkGmnhrK9u6aZGAFV3dUkFmZgLLgkFLo5R7kE2LDoyZXWP1t5ngB5uKTdbOVOzT0ILsMoc3rTqyY
1CesSIWLg5n+gXXqBmRBF1Y3fMuKVIY1OLC6/sSlIutES8jjECCXoR21aEMvJBv60iKXoR0faD0v
BBMgYH1pkcvQTlq0k8AnJepLi1yGNjzQImf3LTsTW+QytNMW7Xg0edeWIRepT7smSPFwEci6vZTR
6v+cAqIAkQDWRwoI5fy3VS2wqraQpYbaPRI2UpH+wobVnvJ8bWStkRw83ylsOFhSBO3xY8+jsweb
OwnCyegHsuZPRy4UCyK66BrJUnvj3pxsB7VqKFsAGFpxaSvb4WBtAWBoJaOFJWXZ81oAYK0OtLGY
pXusBQDWFvdFrAUA1lbsRawFANaW4UWsBQDW1tZFrAUAtimYo9OARHPv23+zoqis4MMWNZ3P72hr
liKWZcJysRH5mQI+XY7q5h3LrdJMdV/NdA69FeuTfFE67exc0FR0/+Wy9dnV4JHgX+0GR1Y3V6fd
IHnUXzSbB4GmG0QB/euFK2h7jYbS7tAzQWcNHQejoQfmYvN/oTd0J6Cs195w5lx7Q+jPr73hzPGv
vSE8KFqNO9cbUivWX+beShvpZm9p8y70hwdpu/aHGPPjfuvaH3Z85/TDJ67Thu3aHzqX3+n9j/pD
emnYvPSGIb4Zp9eAufrMq4cNtbTwhwA0bwu6VMFfAPikA9ADBDnsXwrz7wAAAP//AwBQSwECLQAU
AAYACAAAACEATY7z/P0AAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht
bFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVs
c1BLAQItABQABgAIAAAAIQAJGmJZmAQAAJkYAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVM
YXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAA7AYAAAAAMAAeBGoGAABQSwME
FAAGAAgAAAAhAE2O8/z9AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsQwDEX3SPxD
lC1q0mGBEGo7Cx4rBCyGD7ASt43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdEJviWb0TNGXoVtPFD
y993T9UtZ5TBa7DBY8tnJL7tLi+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc5JKmQUZQHzCgvK7r
G6mCz+hzlZcdvGsesIfJZvZ4KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0IoijXGRpNpKtig8uz
hKXzN+Ckey2vSUYje4OUX8AVG1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLlJyImpBLXE5wV30Bf
t8j19d0nAAAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/B
CsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhp
b6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKg
fmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGq
Iu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEAACYRaDcDAABPDgAAIQAAAGRycy9zbGlkZUxh
eW91dHMvc2xpZGVMYXlvdXQxLnhtbOyXzXLaMBCA753pO2h8T2yMoa4HyExp00t+mEAeQLFF7EaW
PJLiQJ6+u7JFgJBCh/bGBWTp0652tbuSBheLkpOaKV1IMfQ654FHmEhlVojHoXc/uzyLPaINFRnl
UrCht2Tauxh9/jSoEs2zK7qUz4aADKETOvRyY6rE93Was5Lqc1kxAWNzqUpq4FM9+pmiLyC75H4Y
BH2/pIXw2vnqkPlyPi9S9l2mzyUTphGiGKcG1q/zotJOWnWItEoxDWLs7M0lmWUF1poXefvwyyOW
UzX0dLwRmJ5OeUYELaFj9iLJWAoDYuyQrmaKMYRE/VNV02qi7IybeqJIkaGEdqbntwMtZj8FYNDw
t6Y/Okk0WcxVORrQBDxBFkMPNmyJvzCJJmxhSNp0pm+9aX67g03zHzto3ymAFayUwl5XjUXvzQmd
ObPCcEY6K6salMLUK5k+aSIk2InmN+alN7UThjaj+ConrdtRVMs1g9YfjtfgU+sss/gmsyUa/gD/
tpMmXJupWXJmHQLLpgkIhx9wP6cY1Uyc3U89Qrm5st+v+dn4BqK8NGPOKGRB60wzGvMifSJGEpYV
hlxTbZgixtqpUcUAvGVgs1oVTGQTqujdSlMreaWp0Yz20wRWBkY5C6DZuPhjR3edo9toIxNOU5ZL
nsGiwuPcrl8hWyifexChED5ujz7wPbpzKwqjMO6HPRuKcRz2e1vxGAX9IMZxjMpeEPe7DbEebbir
GAXOJTs3FVXzmncsS5OMzdHbuPwwDqxSELkGQDPcwUbrrAOA7e5gg3XWAcBG79nOxhocAGxvH+sA
YPv7WAcA+2Uf6wBg432sA4D9uo9tAPR1m224MTbZYCYBCass+sfJhxXO5p7eSL4mobaXYOP4iPyf
slSKjHBWM36AOpuER6ib5YU6XFsXU/4IbZfyWZn8YOOiY9UV853a4ND6r2Uz+lPZtD6E49ydRX95
Wm2VTbv/9qTCSvbuyNpVNvtRJ4ZSiEf4B3UzjDpQ+U9109X5zRp7qpsHXlpOddOdS6e6aWsTXjTt
rbN5rkATHzX2RcLVNa1ua3tywzMOLr1j21XBww0vr4C+ISjDPQRHvwEAAP//AwBQSwECLQAUAAYA
CAAAACEATY7z/P0AAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL
AQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BL
AQItABQABgAIAAAAIQAAJhFoNwMAAE8OAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVMYXlv
dXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAiwUAAAAAIAAeBHEGAABQSwMEFAAG
AAgAAAAhAE2O8/z9AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsQwDEX3SPxDlC1q
0mGBEGo7Cx4rBCyGD7ASt43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdEJviWb0TNGXoVtPFDy993
T9UtZ5TBa7DBY8tnJL7tLi+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc5JKmQUZQHzCgvK7rG6mC
z+hzlZcdvGsesIfJZvZ4KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0IoijXGRpNpKtig8uzhKXz
N+Ckey2vSUYje4OUX8AVG1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLlJyImpBLXE5wV30Bft8j1
9d0nAAAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIw
EETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zr
Fdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBP
cluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H
2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA5KZS/D4DAAAwCQAAIQAAAGRycy9zbGlkZUxheW91
dHMvc2xpZGVMYXlvdXQxLnhtbKyWW2+bMBTH3yftO1i8twFyIUVNKq27PXRptbQfwDVOQDUG2W6W
9NPvfwzk0qVSFO0lMfbx79wPXN+sS8VW0tii0pMgugwDJrWoskIvJ8HT4/eLccCs4zrjqtJyEmyk
DW6mnz9d16lV2R3fVK+OgaFtyidB7lyd9npW5LLk9rKqpcbZojIld3g0y15m+B+wS9WLw3DUK3mh
g/a+OeV+tVgUQn6txGsptWsgRiruYL/Ni9p2tPoUWm2kBcbfPjTJbWp4a6X4KXkWMC9oVtiKgil8
F3OVMc1LbMylIOWMBKXxp7Z+NFKSnF79MPW8fjD+0mz1YFiREaS9HPTag1bMP2qIYdF7d33ZkXi6
Xphyes1TRIOtJwGStqFfXOKpXDsmmk2x2xX5/RFZkX87It3rFMCCrVLku248+teduHPnsXBKsmjr
VSPKcfWuEi+W6Qp+kvuNe2K26mDkM+HrnDWhd4Rq5ZpDH49O3vqYdoZuI5HEcT/q+3AMBuHoKnwX
lCRJ4gE2GYUm6o/iMBl6JR0JShp0nbr1lyrbUEif8e9TwlNl3dxtFJKL9UpFMINxtUTvKKSep5lc
/MaWfZsE0ANFzz7bgsNtrlSrq72JHB8SEWGeIg74AURxakKpL57mAZS4O//8ll/cztCUpbtVkkNx
66Kb3qpCvDBXMZkVjv3i1knDfBzRwrCZtDmv06uQOnvghpO5jaaWvNXUaKZU8RSWITRdSHyUKF0f
1wSS0PTHIxXkg+JC5pVCh7CYgoAW6pJ/VnlQSgL0Egq9q6azqiS+CkcJKuagdQ6rZBiG0Tg5tUoY
1yKvMMueG+axgim5ufNdW+gM44eWlPPn1xlmrLdkr4wwJ32GqVSagiNZLGOqvQY1GCYQQzxO4EXj
fR5BWl5/x7uK0D2n8kb7PIK0vMGOF/WTiMROM5BUN1UHL4nSAod7wHE8Jj/OABKlBY52wDgew8Cz
gERpgckeMBn0T8/JgctEaYHjHZBopyflAEiUFni1BxwNkzOTQpTjw4vwyNp2Knm9/2+Y0Szxs8we
DLOPBpSfU827GEt6afvJo8wvXt+vvG34TsGYvPVbNb5MqPAguhMhRvelM/0LAAD//wMAUEsBAi0A
FAAGAAgAAAAhAE2O8/z9AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEA5KZS/D4DAAAwCQAAIQAAAAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAAAJIFAAAAABAAHgSTBQAAUEsD
BBQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8
Q5QtatJhgRBqOwseKwQshg+wEreNyEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTx
Q8vfd0/VLWeUwWuwwWPLZyS+7S4vmt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu
6xupgs/oc5WXHbxrHrCHyWb2eCjlo5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPL
s4Sl8zfgpHstr0lGI3uDlF/AFRtSJ5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9A
X7fI9fXdJwAAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SP
wQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDI
aW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYy
oH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2Mh
qiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhABHQsehgAgAAHwcAACEAAABkcnMvc2xpZGVM
YXlvdXRzL3NsaWRlTGF5b3V0MS54bWysVcFu2zAMvQ/YPwi6p07SYRiMJAWWrbukbbCkH8DKTOxV
lgRJ8eJ9/SjJTtEuAwK4F9uSyUe+R1Ka3RxryRq0rtJqzidXY85QCV1Uaj/nj9vb0RfOnAdVgNQK
57xFx28WHz/MTO5ksYJWHzwjDOVymPPSe5NnmRMl1uCutEFF/3ba1uBpafdZYeE3Ydcym47Hn7Ma
KsU7f3uJv97tKoHftDjUqHwCsSjBU/6urIzr0cwlaMaiI5jo/Tol3xpiq59+cRaNbEPLCV8Qb7GR
BVNQ08a28hIZqcOWWnlCigbObC1iMFXND2s2Zm2j332ztqwqAk7nz7PuR2cWl4rM6CN7477vkSA/
7my9mEFOYrDjnFPN2vAkJ8jx6JlIm+JlV5QPZ2xF+f2MddYHoAxOQancJjH6l860p5PkmJxYJVMg
15UWz44pTTwD/URP3Dc9WOAc4E3JkvI+KNvZpZ9Rj97ekaZRLH/8qos2EH+id9yEXDq/8a3EKAil
DTmB04PklxAaG9XoccMZSL+K6z/laHlPjV77pUSgQejE9IulrMQz85phUXl2B86jZTE5GgsKMSO1
PBWrC4GqWIOFn6dIHfIpUooc+ENOmRGpngF9Jon/L/R1L3TXbWwtQWCpZUFJTYfJXhXUNH1l3kFx
KhCTjTxJ+c4VCG0eC+BeVSCpGqWlR59CpDWgCTYoNM24xAblBeFiJQaE25aVvTzadaj7gGi3+mB9
eTG5T0PDVbuz0ejkGjw7cYTS2Uuf4ZyOx6u0d2AemtiBdC3RBC/jlqGLKEwimb6YBIz+Ylv8BQAA
//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhABHQsehgAgAAHwcAACEAAAAAAAAAAAAAAAAAFQIA
AGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAC0BAAAAAAA
ABwEBAAAAAEAAAAgALoPIAAAAHcAaABpAHQAZQBfAGkAbgB0AGUAbABfAG8AbgBsAHkADwDwA9FD
AAABAPEDCAAAAAAAAIACAA0wDwAMBHQwAAAPAALwbDAAAMAACPAIAAAABwAAAAcoAAAPAAPwBDAA
AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAKAAABQAAAA8ABPAPCQAA
EgAK8AgAAAACKAAAAAoAAMMAC/BgAAAAfwABAO8BgABoIMMKgQCDcgEAggBBuQAAgwCDcgEAhABB
uQAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAAyAAAAEwAi8QcIAACpgwEIAABQSwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABbQ29udGVu
dF9UeXBlc10ueG1slJFNT8QgEIbvJv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS/bgY18Qj
zLzP+wTq1XYaxUyRrXcKrssKBDntjXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnHCoaUwr2U
rAeakEsfyOVJ5+OEKR9jLwPqDfYkb6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD4tKlAEMY
rcaUTeXszI+W4thQ5uR+hwcb+CprgPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5/BuyWE5c
+K6zmso2cptjbzSfrM7RecBAGf1f/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HS
AAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt
376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalH
MvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28
zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA
//8DAFBLAwQUAAYACAAAACEAdVoXjpgDAADDCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVW1v2zYQ
/j5g/4Hg1yL1S+zZMaoUidF0A9zAiNPt80miIs0UqZKU3359746ynRVbUcz1B/lIHu+ee3mO797v
ai02yvnKmkQO3valUCazeWVeEvn5+eFqKoUPYHLQ1qhE7pWX729//eVdM/ONwMvGz5pEliE0s17P
Z6Wqwb+1jTJ4VlhXQ8Cle+k1TnllAgR0VOvesN//rVdDZeQtmjKbVbN0JGWPm6UTVZ7I8WA4lMJA
jV6fVIYYXrQSQ9nr1OINQBgLm619hwV+BEvuYIsB/gOGMPajw0gG6NPOS/Sm7pyz21JB7mkb/fYY
3xGqQaSEpSlF2DeIsswdJuuQyC8tuKBcdyXq4d1zlB6jFen2k83xGrTBYhZgtitcfWkYZMcWhdgl
Eku5py8Ch5naBZHh5nX/Zjrt41GGZ6PJdX8yZpjRO2k2zoePyl6MRJChRDosHUcHm4UPlMSzC3Jn
7EOl9aVhc4zaXGpGbBN5Mx6OGXBExpbrCsspdFUnEpOHv5hU6o0PJmeVAJWOMgaoDee8KDB4jPpS
WJQ14lvst7C7t/meHKT4j40UWfj/Ox/pj4UqrTtIsXWAJPDUwUoK/YfB3r8ZTcdIi8CL0WSE+RHu
9Un6+sS09dxqJhKYDK0mMkgRxXnAFTWfrRsIC7NqMlI8tt3z7i9wTdc4AVv20a5KaNS/9U/U5XaK
aSAj2odV2OOYuDAlbGujB0RT0C84GbUUuSqeIV0hv29Gk8n1lFHh5hMqEesHONM6Lul4l9EdMXGQ
PwMYgarBLTiTKDyxgC75vzI5jlkW/xu5cCFqK1iYe7dm9cKacMfBpuCp+DirzfmYRiIOzWVrMjbP
OaIKkuCbbJkFsQEq/IkhzISzxr0qvtU9Jgzvn0/vivAdve40befaPe+Ye2m7OpzEBwzjtHjER6uj
Z4pEZDGWjDiFk4gohdPR5EtwQJVct3VV27+rmFSMOZHKXH1eYQvrsOD1obyaP8ZJzzUXacw8f9tE
GnRKr6ar1jjejV2xJMVaOXpjqU1ERjTrFIkEuGXotdTVQf3OSyqCrujN5bOls7Zg2ddhrhWgqT63
YBw2p2l1Gj/e6iqn4crJpJdZYcpijcIuPmhYudda6jixOFHtwnSJbMlMJ3Nb8ItXQIbo/lQuBwNS
NFXIygeoK41Py/UIYyzBecXNwvYUvLr2pjZXCuIczfw3B5nviHQuTCwXfpvZcQDyTLz9CgAA//8D
AFBLAwQUAAYACAAAACEAedCQv9kAAAD8AAAADwAAAGRycy9kb3ducmV2LnhtbESPS2vCQBSF94X+
h+EWuqsTU5SSOoooknYhJVFxe83cPOg8wsxUk3/fwUW7PJzDd/gWq0ErdiXnO2sETCcJMDKVlZ1p
BBwPu5c3YD6gkaisIQEjeVgtHx8WmEl7MwVdy9CwCDE+QwFtCH3Gua9a0ugnticTu9o6jSFG13Dp
8BbhWvE0SeZcY2fiQ4s9bVqqvssfLaCY7T+Pm/Fc87L52uJ8rc6qPAnx/DSs34EFGsL/OH/tk0v+
V95RH1LAbJqmwOp8vLhOFugDOQFRL8pGUeDLXwAAAP//AwBQSwECLQAUAAYACAAAACEAWuMRZv4A
AADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA
IQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA
IQB1WheOmAMAAMMIAAAQAAAAAAAAAAAAAAAAACoCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAG
AAgAAAAhAHnQkL/ZAAAA/AAAAA8AAAAAAAAAAAAAAAAA8AUAAGRycy9kb3ducmV2LnhtbFBLBQYA
AAAABAAEAPUAAAD2BgAAAAAAABDwCAAAAAAAAACgByoBDwAR8BAAAAAAAMMLCAAAAAAAAAAKAsgK
DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEPGAAAAAEAAAAAAAAIAAAAAAEAAAAAACIABAAMAAAAqg8O
AAAAAQAAAAcAAAAAAAkEBAgAAKYPDgAAAPEAAABVAtQB0ALwAxAFDwAE8AwJAAASAArwCAAAAAMo
AAAACgAAwwAL8GAAAAB/AAEA7wGAAMQKyAqBAINyAQCCAEG5AACDAINyAQCEAEG5AAC/AAQABAC/
AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAATACLx
BAgAAKmD/gcAAFBLAwQUAAYACAAAACEAWuMRZv4AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54
bWyUkU1PxCAQhu8m/gcyV9NSPRhjSvdg9ahG1x8wgWlLtgXCYN3999L9uBjXxCPMvM/7BOrVdhrF
TJGtdwquywoEOe2Ndb2Cj/VTcQeCEzqDo3ekYEcMq+byol7vArHIaccKhpTCvZSsB5qQSx/I5Unn
44QpH2MvA+oN9iRvqupWau8SuVSkhQFN3VKHn2MSj9t8fTCJNDKIh8Pi0qUAQxitxpRN5ezMj5bi
2FDm5H6HBxv4KmuA/LVhmZwvOOZe8tNEa0i8YkzPOGUNaSJL479cpLn8G7JYTlz4rrOayjZym2Nv
NJ+sztF5wEAZ/V/8+5I7weX+h5pvAAAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAA
AF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX
+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJ
n1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3Pfe
vqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQA
BgAIAAAAIQDq61StlAMAAMMIAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxV3W/jNgx/H7D/QdDr0IvT
JEsanHtog/U2ICuCprc907Zce5ElT5Lz9dePpJykO2zDsCwPDiVS5I/fHz/tGy22yvnamlQOPyRS
KJPbojZvqfzy+nQzk8IHMAVoa1QqD8rLT/fffvOxnftW4GPj520qqxDa+WDg80o14D/YVhnkldY1
EPDo3gatU16ZAAENNXpwmyTfDxqojbxHVWa7bleOqPx5u3KiLlI5Gd6OpDDQoNUXlSOGN63ESA56
sfgCEMbS5hvfY4F/g6VwsEMH/wRDGPvZoSdDtGkXFVpTD87ZXaWg8HSNdgeM7wTVIFLC0lYiHFpE
WQSJyPcX4SiBry7+efRTZLufbYEPoAsW/Yf5vnTNtQ6QHluWAu2Pk8lwlGAqD6lMCDjM1T6IHFmj
5G42I1aOvPF0lEwn7FnEQJKt8+GzslfjEaQolQ5Txz7CdukDBfFigswZ+1Rrfa3z7KM216oRu1Te
TW4nDDgiY81NHZQTum5SicHDXwwq1cYPpmCRALWONDqoDce8LNF59PpaWBQ16rdYb2H/aIsDGcjw
H8spduF/r3xsf0xUZd1Rip0DbAL/ewdOSaF/Mlj7d+PZBNsi8GE8HWN8hHvPyd5zTNcsrOZGApOj
1lRiX0RyEfBExWebFsLSrNucBE9l97r/FVzbF07Akn226wpa9Vf1E2W5nGIYSIn2YR0OOCauDAnr
2uohNSvoN5yMTopCla+QrY8UkOl0NGNUePmCQh5vhzjT+l7S8S2jO2FiJ/8PYASqAbfkSCLxwgSa
5P/aFDhmmfx75MKFKK1gaR7dhsVLa8IDO5uBp+TjrDYXNo1EHJqrzuSsnmNEGSTCt/kqD2ILlPhz
h3AnXCQeVfm17Clg+P7CfSjDP8j13KxbaPe6597LuvXxTD6hG+fDMy6tvj0zbEQmY8qop3ASUUvh
dDTFChxQJjddUzf2tzoGFX1OpTI3X9ZYwjos+XysbhbPuBZPORdZjDx/u1QaNEpb09UbHPLGrpmS
YqMc7VgqE5FTm/WC1AR4ZWhb6vqofuQjJUHXtHOZt3LWlkz7Jiy0AlSVcAnGYXOeVufx462uCxqu
HEzazApDFnMU9nGhYebeS6nTxOJAdUvTB7IjNT3NZcEbr4Qc0f2iXAEGpGjrkFdP0NQaV8tojD5W
4LziYmF9Ct49+64xNwriHM39V4zc9410SUxMF37b+WkA8ky8/wMAAP//AwBQSwMEFAAGAAgAAAAh
AOF8pW7aAAAA/AAAAA8AAABkcnMvZG93bnJldi54bWxEj0trAjEUhfeF/odwC93VjBZFpkYRpdRC
S5mposvr5M4D85gmqc78+4YudHk4h+/wzRadVuxMzjfWCBgOEmBkCisbUwnYfr8+TYH5gEaisoYE
9ORhMb+/m2Eq7cVkdM5DxSLE+BQF1CG0Kee+qEmjH9iWTOxK6zSGGF3FpcNLhGvFR0ky4RobEx9q
bGlVU3HKf7WAbPz5vl31+5Ln1dcaJ0u1V/lOiMeHbvkCLFAXbuPpZvfxc7iW/6iNFDAejp6BlW/9
0TUyQx/ICYh6UTaKAp//AQAA//8DAFBLAQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAA
AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEA
AAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAOrrVK2UAwAAwwgA
ABAAAAAAAAAAAAAAAAAAKgIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA4XylbtoA
AAD8AAAADwAAAAAAAAAAAAAAAADsBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAPMG
AAAAAAAAEPAIAAAAAAD4CZgRKgEPABHwEAAAAAAAwwsIAAAAAQAAAAcAyAoPAA3wWAAAAAAAnw8E
AAAABAAAAAAAoQ8YAAAAAQAAAAAAAAgAAAIAAQAAAAAAIgAEAAwAAACqDw4AAAABAAAABwAAAAAA
CQQECAAApg8OAAAA8QAAAFUC1AHQAvADEAUPAATwiAAAABIACvAIAAAABCgAAAAKAACDAAvwSAAA
AH8ABADvAYcAAQAAAL8ABAAEAL8BAQARAP8BCQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQA
YQBuAGcAbABlACAANAAAAAAAEPAIAAAAvgH8ApwOdgoPABHwEAAAAAAAwwsIAAAAAgAAAAUAyAoP
AATwLwoAABIACvAIAAAABSgAAAAKAADDAAvwYAAAAH8AAQDvAYAArFXICoEAg3IBAIIAQbkAAIMA
g3IBAIQAQbkAAL8ABAAEAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBu
AGcAbABlACAANQAAABMAIvHdCAAAqYPXCAAAUEsDBBQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCBaUu2BcJg3f33
0v24GNfEI8y8z/sE6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr5vKiXu8Cschp
xwqGlMK9lKwHmpBLH8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP23x9MIk0MoiH
w+LSpQBDGK3GlE3l7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84ZQ1pIkvjv1yk
ufwbslhOXPius5rKNnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsDBBQABgAIAAAA
IQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpb
SUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9
v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPq
fE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9ces
FzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhANbvZutuBAAABRcAABAAAABkcnMvc2hhcGV4bWwueG1s
7FjNbhs3EL4X6DsQvBaOtKsfS0LWgS3UaQHVECynPRrULtfamktuuZQs+9R36Bv00fIk+YZcW4qS
gxslBtrKh/WsOBzOz/fNUHr9Zl0qtpK2LoxOePSqzZnUqckKfZPwd1fnRwPOaid0JpTRMuH3suZv
Tr7/7nU1qiuGzboeVQlfOFeNWq06XchS1K9MJTXWcmNL4fBqb1qVlbXUTjgcVKpW3G73W6UoND+B
Kb2aVVNLUnqxmlpWZAnvRXGPMy1KnHopU/hwoyTr8VajFnYIuDEx6W3d+CKe40tmxR0C/MgNps1b
i0ginGnGC5wmT601dwspspo+xrkt79+jqxqeki/Vgrn7Cl7OTXaPbD0k/I+lsE5ajkDWCe80e8MG
GNmEWyNsNr/7xWTYL5bOIB1itM5tuW88ZMfkOcP5w163PUAd7xPe7Q6OB33vkBjJtWMp1ntxNxpS
slPSiHvxMIq9y8ETslTZ2r2VZm+vGBlKuEU9faRiNakdZXZzBB2nzXmh1L4pgF0xUnpfM+yOUoj8
bDzzlssCJWaqKBM+aNMf5UyMCDA/6szLThQqyAhQaVqWeY7gEfW+buEAQIkARCB06zOgjw4gFAJU
gZpfTgf0BBRqYewDZ3dWgBk1oVpypn7WIMSwO+iBK86/dI8BG87s9sp8e0Uvy7FRnl1Cp7CacMdZ
EMcOb+g7qSkr4SZ6VqWkSLEQWq7WvwlbNcBxwOyFmS1EJT+Hn6Dr4RTSQEZU7WbuHr1jz5T4ij72
vC9OrA8L9SmFnfiwIVx6Qa2QIOSh0BkapReFukFXVpxlMr8S8xlayzDqdgE1Zl3QlmKiz+ytV8+N
dqd+y1zUVCl0W71ZpqaGtjdd6tSb98mhdJNQV+k0dWwlqEpPcPaw3WicyXxXt/OIfKjCxkbjNHe7
up4hQa9ZnS/Hyl6tfWrny9nDk3iOUJ5eLjB6Gj7NQ78QI2TkcmqJBIAJcUCMwgO5vV2WRWl+L0Ja
EXXCpT56NwPilJv494fF0fgiNOsIs4izeci9fy4TrnEkTT5b3KIzazPzEme30tKc9FtSYkWjSJiF
FU0TTxUP8if/SmVQBc1Nvza1xuRerks3VlLAVNvjOPSG0PZCTOGT2qgio17oU0nTVSJhoUpuHYYS
8r6t9dRgfMaWE92kcUlmGtkDw0+tXKTw7ldpM6EFZ1Xh0sW5KAuFUdDpgpQLYWvp4eLtSbG17YdS
H0kR2l5a7yykdTNDbKiOO2HX+MMj/PfPRqaF62sqJTCDJypJZaWgvzLh4k50fIxW9THr0MgeWXcU
d9oRTcsD95B98BMA8ChI+Ps//w61duJAw385DQPxXoRy3X40xJVzh3LxNuXiQZ968P+bclv98/n9
eIegfx0IinH4H5mTLzQS+51ON/qEn/jgaSRG/SF9aTzws5L/9L60w89vOkDpK+jhHvtC99gXHKCD
dif+9M6Ky/kWQQde4zBA9yXoNx2gB4I+/2LzNb5ofn6A4lezx1/L/A9oJx8AAAD//wMAUEsDBBQA
BgAIAAAAIQBZVv0s2QAAAPwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9LS8NAFIX3gv9huEJ3dtJC
isROS20orQuRxEq318zNA+cRZqZp8u8dXOjycA7f4VtvR63YQM531ghYzBNgZCorO9MIOH8cHp+A
+YBGorKGBEzkYbu5v1tjJu3NFDSUoWERYnyGAtoQ+oxzX7Wk0c9tTyZ2tXUaQ4yu4dLhLcK14ssk
WXGNnYkPLfa0b6n6Lq9aQJG+vZ7306XmZfOe42qnLqr8FGL2MO6egQUaw//4JT8NRf5X/qJOUkC6
WKbA6uP05TpZoA/kBES9KBtFgW9+AAAA//8DAFBLAQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAAT
AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HS
AAAAjwEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhANbvZutu
BAAABRcAABAAAAAAAAAAAAAAAAAAKgIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA
WVb9LNkAAAD8AAAADwAAAAAAAAAAAAAAAADGBgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA
9QAAAMwHAAAAAAAAEPAIAAAACwtZAj8PghUPABHwEAAAAAAAwwsIAAAAAwAAAAYCyAoPAA3wogAA
AAAAnw8EAAAAAgAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vj
b25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAA
AAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDw4AAABTAAAABwAAAAAACQQECA8ABPAjCQAA
EgAK8AgAAAAGKAAAAAoAANMAC/BmAAAAfwABAO8BgACgXcgKgQCDcgEAggBBuQAAgwCDcgEAhABB
uQAAhwACAAAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4A
ZwBsAGUAIAA2AAAAEwAi8RUIAACpgw8IAABQSwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABb
Q29udGVudF9UeXBlc10ueG1slJFNT8QgEIbvJv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS
/bgY18QjzLzP+wTq1XYaxUyRrXcKrssKBDntjXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnH
CoaUwr2UrAeakEsfyOVJ5+OEKR9jLwPqDfYkb6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD
4tKlAEMYrcaUTeXszI+W4thQ5uR+hwcb+CprgPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5
/BuyWE5c+K6zmso2cptjbzSfrM7RecBAGf1f/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAh
ADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJ
TGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/
7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8
T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wX
NXYPAAAA//8DAFBLAwQUAAYACAAAACEAcYJdWqQDAADRCAAAEAAAAGRycy9zaGFwZXhtbC54bWys
Vdtu2zgQfV+g/0DwtUhtJ3Z8QZUiMZruAm5gxOnu80iiItUUqSUp376+M0M5Tot2sVivH+QhOZw5
cznD9x92tRYb5XxlTSIH7/pSKJPZvDLPifzydH8xkcIHMDloa1Qi98rLDzdvfnvfzHwj8LLxsyaR
ZQjNrNfzWalq8O9sowyeFdbVEHDpnnuNU16ZAAEd1bp32e9f92qojLxBU2azapaOpOxhs3SiyhM5
GlxeS2GgRq+PKkMMz1qJa9nr1OINQBgLm619hwX+DZbcwRYD/A6GMPaTw0gG6NPOS/Smbp2z21JB
7mkb/fYY3xGqQaSEpSlF2DeIsggOk3VI5N8tuKBwUeW7RA67q1EfbZyi9Ri1SLefbY7XoQ0WswGz
XeHqc8MhO7YoBPrHku4TOZmOR+PLEWGBmdoFkeHRVX86mfRRIUON4fiqP2aFXsRAmo3z4ZOyZ+MR
ZCiRDgvJMcJm4QOl9OSC3Bl7X2l9bvAcozbnmhHbRE5HmLMTMrZcV1hcoasas9qnX0wqdcpHk7NK
gEpHGQPUhnNeFBg8Rn0uLMoasS92X9jd2XxPDlL8x3aKnPzvPMBhgIUqrTtIsXWAlPDUz0oK/YdB
JkyHkxGSJPBiOB5ifoR7fZK+PjFtPbeaaQUmQ6uJTKWI4jzgiprP1g2EhVk1GSlSLNQtT7u/wDVd
4wRs2Qe7KqFRP+ufqMvtFNNARrQPq7DHoXFmStjWRg+IrKCfcU5qKXJVPEG6QrZPh+Px1YRR4eYj
KtEMGOCEY+IjjniX0R0xcZD/BzACVYNbcCZReGQBXfJ/ZXIcuiz+GrlwIWorWJg7t2b1wppwy8Gm
4Kn4OLnN6ZgGJI7QZWsyNs85ogqS4JtsmQWxASr8C0OYCSeNO1X8qHtMGN4/nd4W4R/0utO0nWv3
tGPupe3q8CLeYxgviwd8wjp6pkhEFmPJiFPYdUQpnI4mX4IDquS6ravafq1iUjHmRCpz8WWFLazD
gteH8mL+EOc+11ykMfP8bRNp0Cm9oa5a45A3dsWSFGvl6MWlNhEZ0axTJBLglqG3U1cH9TsvqQi6
oheYz5bO2oJlX4e5VoCm+tyCcdjEORqjijve6iqn4crJpHdaYcpijcIuPm9Yudda6jixOFHtwnSJ
bMlMJ3Nb8PtXQIbo/lQuBwNSNFXIynuoK41Py9UQYyzBecXNwvYUvLr2tjYXCuIczfwPB5nviHQq
TCwXfpvZcQDyTLz5BgAA//8DAFBLAwQUAAYACAAAACEAIop1z9sAAAD8AAAADwAAAGRycy9kb3du
cmV2LnhtbESP30vDMBSF3wX/h3AF31y6iVPqsiHKrAj+2BTx8a65a+uam5hkbfffG3zQx8M5fIdv
thhMKzryobGsYDzKQBCXVjdcKXh/W55dgQgRWWNrmRQcKMBifnw0w1zbnlfUrWMlEoRDjgrqGF0u
ZShrMhhG1hGnbmu9wZiir6T22Ce4aeUky6bSYMPpoUZHtzWVu/XeKHga+ur1cd/dfXxfOv+53Mmv
5/sXpU5PhptrEJGG+D8uzl22Kf7KX9SDVnAxnkxBbIvDxjd6hSGSV5D0kmwSBTn/AQAA//8DAFBL
AQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAHGCXVqkAwAA0QgAABAAAAAAAAAAAAAAAAAAKgIAAGRycy9z
aGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAIop1z9sAAAD8AAAADwAAAAAAAAAAAAAAAAD8BQAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAAQHAAAAAAAAEPAIAAAAFhYAAKAHQBcPABHw
EAAAAAAAwwsIAAAABAAAAAkCyAoPAA3wWAAAAAAAnw8EAAAABAAAAAAAoQ8YAAAAAQAAAAAAAAgA
AAAAAQAAAAAAIgAEAAwAAACqDw4AAAABAAAABwAAAAAACQQECAAApg8OAAAA8QAAAFUC1AHQAvAD
EAUPAATwrwkAABIACvAIAAAABygAAAAKAADTAAvwZgAAAH8AAQDvAYAAWGPICoEAg3IBAIIAQbkA
AIMAg3IBAIQAQbkAAIcAAgAAAL8ABAAEAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIA
ZQBjAHQAYQBuAGcAbABlACAANwAAABMAIvF9CAAAqYN3CAAAUEsDBBQABgAIAAAAIQBa4xFm/gAA
AOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCB
aUu2BcJg3f330v24GNfEI8y8z/sE6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr
5vKiXu8CschpxwqGlMK9lKwHmpBLH8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP
23x9MIk0MoiHw+LSpQBDGK3GlE3l7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84
ZQ1pIkvjv1ykufwbslhOXPius5rKNnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsD
BBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmj
Tm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR
4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3
YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9
V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAG8rdTULBAAAHQwAABAAAABkcnMvc2hh
cGV4bWwueG1s7Fbbjts2EH0v0H8g+Fo4lm/1BdEGu042LeAujPWmfaYlaq2aIlWS8mWL/nvOkFp7
E6RFUadv8YM9EoczZy5nxq/fHCrFdtK60uiU914lnEmdmbzUjyn/8HDbmXDmvNC5UEbLlB+l42+u
vv/udT1zNcNl7WZ1yjfe17Nu12UbWQn3ytRS46wwthIej/axW1vppPbCw1Gluv0k+bFbiVLzK5jS
u1W9tCRld7ulZWWe8lGvP+ZMiwpe72UGDI9KsjHvtmrxhgCMhcm2rsUi/g2W3Io9AvwEBtPmvUUk
Pfg08w28yWtrzX4jRe7oNfx2A75nqBpICUu9Yf5YA6VT+V1TIV9PKf+jEdZLyxHKAbG0t+MVmDkH
7BA4W+9/MTksiMYbJETMDoWtLo2I7JiiYPA/TEa9QYLaHlM+mY5H435AJGby4FkGhUEynUxIIYPG
cDxIxhFyREKWauv8e2kuRsXIUMotKhoiFbuF85Tbswtyp81tqdSlKYBdMVP6UjNsn/LpCDk7IwuW
qxIlZqqskNWEPlRmMaOWeafzIHtRqigjQKXpWBYFgkfUl8KCA7QSNRC1oT/cmPxIDtb4RVNFcv53
QmAqoFAbY58421sBbjjqasmZ+lmDEtPhZAS2+PAwHA+RH2ZfnqxfnuimmhsV+CV0BqspX3MWxbnH
EzWfqWrhF3pVZ6RIsVC3PBx+E7ZuG8ejZe/MaiNq+aX+ibqhnWIayIhyfuWPmB4XpiTY2qkeUVao
RwxMEDyXxYNYr8D56XA8HkwCKry8hxJNgh5GXaA/cMS7Ad0zphDk1wBGoCphFyGTEO6DAJfht9Q5
pm8Q/x45sz5qS7HQN3Yb1Auj/XUIdi0cFR8jXJ+PaVJili4bnQXzIUdUQRJcnS0zz3aCCn9iSGDC
WeNGFp/rPicM98+n14X/B732dN3MlX04BO6tm9XTSbxFGKeHO+yylp5rEDGIsWTEKXQdUUrMCpWH
VfQn1bA37yWd3ujd284wuUk6N9PrUWfQH42ubyeTt6P++C9QoV0DJXKNRUAmLKqybaqyMr+XsSDI
V8qfNp35Hdpf+UV4lrrzYRU3R+gXto5VC99NyjUA0yK25RZrQptVkDjbSktrm1qMZUTRVpEIhFea
FrAqn+RP4ZEKqEpa4+FsaY0pguwqP1dSwFQSUMdBFWdwzEh844wqcxrMoRC07CXSHevrD3FHouov
tU7TLiS5Wei2CA2ZaeXQUiF7hciA7ldpc6EFZ3Xps82tqEqFtTQYIsaNsE6GRgv2pHhx7YdKd6SI
Mzhznx1kriUhKkLov9GFsvBV6eKvGJEHLMU3uEMOpM6Xwgoahl+gQdv2Jxq0tDiNzW80+N9ocC5M
nHj4Pv+HCH8rrj4CAAD//wMAUEsDBBQABgAIAAAAIQAhxnCi3AAAAPwAAAAPAAAAZHJzL2Rvd25y
ZXYueG1sRI9NS8NAFEX3gv9heII7O2lpbYmdFrFURaj9UMTlM/OaxGbexJlpkvrrHVzo8nIv53Km
885UoiHnS8sK+r0EBHFmdcm5gteX5dUEhA/IGivLpOBEHuaz87Mpptq2vKVmF3IRIexTVFCEUKdS
+qwgg75na+LY7a0zGGJ0udQO2wg3lRwkybU0WHJ8KLCmu4Kyw+5oFKy6Nt88HZvF29e4du/Lg/x8
vl8rdXnR3d6ACNSF//F6OFp8D//KX9SjVjDqD8Yg9g+nD1fqLfpATkHUi7JRFOTsBwAA//8DAFBL
AQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAG8rdTULBAAAHQwAABAAAAAAAAAAAAAAAAAAKgIAAGRycy9z
aGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAIcZwotwAAAD8AAAADwAAAAAAAAAAAAAAAABjBgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAGwHAAAAAAAAEPAIAAAAFhb4CZgRQBcPABHw
EAAAAAAAwwsIAAAABQAAAAgCyAoPAA3wfAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGAAA
AAIAAAAAAAAIAAACAAIAAAAAACIABAAMAAAA2A8EAAAAAAAAAAAAqg8cAAAAAQAAAAcAAAAAAAQI
CQQBAAAABwAAAAAACQQECAAApg8OAAAA8QAAAFUC1AHQAvADEAUPAATwSAAAABIACvAIAAAAASgA
AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQAL8BEgASAP8BAAAIAAQDCQAAAD8D
AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMw
AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAANK4xQFgdVy3AAAOBNML
AABQSwMEFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHLasMw
EEX3hf6D0LbYcroopdjOokl3fSzSDxjksS1qj4Q0Ccnfd+y4ULoILXQjEGLOmXtVro/joA4Yk/NU
6VVeaIVkfeOoq/T77im71yoxUAODJ6z0CZNe19dX5e4UMCmZplTpnjk8GJNsjyOk3AckeWl9HIHl
GjsTwH5Ah+a2KO6M9cRInPHE0HX5KgtE16B6g8gvMIrHsKDw+/kMJICYC1irxzNhWqLSEMLgLLBE
MAdqfugz37bOYuPtfhRpPoMX2M0EM79cYPU/6i/nBlvYD6y2R+niXH/EIf0t21JrLpNz/tS7kC4Y
Lpe3tGHmv60/AQAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz
hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn
IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ
ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j
U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv
dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b
1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt
td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQB0sUij
YAYAADIbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28cNRS/I/EdrLm32T9NyEbdVMnu
poE2bZTdFvXonfXOuOsZj2xv0r2h9oiEhCiICxI3Dgio1EpcyqcJFEGR+hV4tmd27cwsSdoIEHQj
ZWfsn9//9/zsvXrtQcLQIRGS8rQd1C/XAkTSkI9oGrWDO4OdS+sBkgqnI8x4StrBjMjg2ua771zF
GyomCUGwPpUbuB3ESmUbKysyhGEsL/OMpDA35iLBCl5FtDIS+AjoJmylUautrSSYpgFKcQJkb4/H
NCRooEkGmwXxHoPXVEk9EDLR16RJvsKgRpO6npMiGnaYQIeYtYOa+QQrm1dX8EYOYKqM2zGfHJcD
RpPGafQMgKkybr2m/+b0DACHIchf5r293av1mjnWAdnHMu0mfFotD+/Qb5Zk9nSzRA3IPl4p4T2b
OSD7uFrCd7d63d6OJ48BWfxaCd/oNrrrWx7egGJG00kJXau14JOj55AxZ7uV8Far06kVhl+gwPvz
mNEsxjxVXgTZmAv0XILvc7EDAP3CsKIpUrOMjHEIsdnBjA4F1fLgDYKdGTsUytKQ5oVkKGim2sEH
GYY4X9B79fy7V8+folfPnxw/fHb88MfjR4+OH/5gaXkLd3EauQtffvPpH199hH5/+vXLx59X46WL
/+X7j3/+6bNqoHKBL7548uuzJy++/OS3bx9XwLcEHrrwAU2IRLfIETrgCehmDONLTobifCsGMabu
iq00kjjFmksF/Z6KPfStGWa4ArdNfAveFRQqWQXw+vS+J3A/FlOVu9zT7EaceMA9ztk2F5VWuKF5
OY4fTNOomrmYurgDjA+reHdw6vm3N82gINIqkp2YeGLuM5wqHJGUKKTn+ISQCjPco9Sz6x4NBZd8
rNA9irYxrTTJgA69aFos2qUJ+GVWJSD427PN3l20zVmV1l1y6CMhKzCrEH5AmGfG63iqcFJFcoAT
5hr8JlZxlZD9mQhdXE8q8HREGEe9EZGyas1tAfo6Tr8B1aPa7XtslvhIoeikiuZNzLmL7PJJJ8ZJ
VoXt0zR2se/LCYQoRvtcVcH3uJ8h+h38gNOl7r5Liefu06vBHRp5Ii0CRM9MhfYlVGuvCCc0fVuR
z1yRtwStTIndE3V4Ge5k9e1wMaL//uLbxdN0n0C8l3egt7X3be0N/vO1d1k+n7XiLoos1F/d59gG
2bTLydJueUwZ66sZIzelaZglbBijHRjU68z5j8xPY1kMj3mB93CRwGYNElx9SFXcj3EGzXbd9OOR
zElHEmVcwqHODFfS1kyhYVf29LeqjzK2Hkis9vjIDjfdQ+GcjNl2InO8LBg1NYGzMmu+92bM6laq
pWbzVasb0Uyp81Sbqww+LKsGg3NrQieCoH8BK6/BCVzLDocUzMhI291uwoVbNOvi+UJcJGM8IrmP
tN5lH9WNk4pYMWd9iJ0KH60b0f/Sag63lib7BtzO4iSX3ZUl7ArvvYmXilNu4RljnJPpyFI3OVmK
jtpBa7WxGqAQZ+1gDOdbeEwy8LrUzR9mEVz9hErYsD81mY3hF95sFYpB9DkZV68V4yWFvTqQCam6
WMY2NMxUHgIs1Zys/I1VMOtFKWAj/TWkaK5DMPxjUoAdfdeS8ZiEynW2M6JtZ1/zUsqnioh+PDpC
QzYVBxjcr0MV9BlRCdcUpiLoF9EOtLXNlF+c88JYcdumuWGWxTgvtzpFi0y2cBOqcxnMmyMe6FYp
u1Hu/KqYlL8gVdww/p+povcTuDJojrQHQrioFRjpfG0HXKiYQxXKYhruCGgcTO2AaEFQXfR2jeC6
2HwLcqi/bc5ZGpoag5OfOqAREhT2IxULQvahLJnoO4VYPd+7LMmCkIkoR1yZWbGH5JCwga6Ba3pv
D1AMoW6qSV4GDO5k/PnveQYNI93kuPnm1ZD53mtz4O/ufGwyg1J+HTYNTWH/uYjGWn7nY9eb5cXe
6yqiJxZt1pUiK4CZsxW08rR/TRHOudXailXSuLFaCAdeLGsMg/OGKIOLH6T/wf5HRcjsbw96Qx3w
A6itCH5P0MQgbCCqL9nGA+kCaQeH0DjZQRtMmpQ1bd7daqsVm/WFtFELF8z5njC2luws/j6nsefN
mc/Oy8WLNHZuYc/WdmypqcGzJ1MUhsbFQcY4xvxo5f6uxIf3wdFduOufMiVNMJEHcM0HrWff5AEk
v+Volm7+CQAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19y
ZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8k
UeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhN
JiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/Tga
iWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAIKKvBP6
AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAUAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2Vy
LnhtbFBLAQItABQABgAIAAAAIQB0sUijYAYAADIbAAAWAAAAAAAAAAAAAAAAANECAAB0aGVtZS90
aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAA
ZQkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0B
AABgCgAAAAAAAA8EOgEAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFu
ZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1s
Zm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9
Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2Vu
dDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9
ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+AAAnBLgFAABQSwME
FAAGAAgAAAAhACjXYsj5AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJC7bsMwDEX3Av0H
QWsRyelQFIXtDH1sfQzpBxASbQvVC6ISJH9f2skQdAjQSaAk3nPIdnMIXuyxkEuxk2vVSIHRJOvi
2Mnv7dvqUQqqEC34FLGTRyS56W9v2u0xIwnujtTJqdb8pDWZCQOQShkjvwypBKhcllFnMD8wor5v
mgdtUqwY66rOGbJvP1mgOIviC0r9gMAcbQtp8nz5DlTZ77JYK06X4vkUM5t0EnL2zkDlOfQ+2j8O
qzQMzqBNZheYrHJB4nP5Hry6AN3N0bpvX3CAna/i9cCqp+0U9PQ/6nlqxZ0LiiaX6Qrh+lhnM72s
vv8FAAD//wMAUEsDBBQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQ
RO+C/xD2btN6EJGmvYjQgxfRD1iSbRtsk5CNon9vjhYEj8Mwb2bq9jVP4kmRrXcKqqIEQU57Y92g
4HY9bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgDi0xxrGBMKRykZD3SjFz4QC47vY8zpizjIAPqOw4k
t2W5k/GbAc2CKTqjIHamAnF9h9z8n+373mo6ev2YyaUfFZIna+iMnChmLMaBkgIT+dtYiKrI+0E2
tVz8bT4AAAD//wMAUEsDBBQABgAIAAAAIQB1EVzOiQIAAKYOAAAhAAAAZHJzL3NsaWRlTWFzdGVy
cy9zbGlkZU1hc3RlcjEueG1s7JdLbtswEIb3BXoHgtsikfWILAuRgySFV1kETdr9WKIsIRQlkEwa
d9U79AY9Wk+SGVquZTcLAwWKxKlXpDkckv83HA1Pzx4byR6ENnWrMu4fjzgTKm+LWi0y/vl2dpRw
ZiyoAmSrRMaXwvCz6ft3p11qH2/sUgrD0IUyKWS8srZLPc/klWjAHLedUDhWtroBi1298AoNX9F1
I71gNIq9BmrF+/l6n/ltWda5+Njm941QduVECwkWt2+qujNrb90+3jotDLpxs7e2NKXj1VYKd0KP
uvO2WLre9BRS+SD97lozkAtUTXKmrcw4aQdX6kLfuXbZKnvuDOZgBGcVqAWe/fpe5ZYMyJHp8gtR
9q3r3LIHQEfhCH8cl/V2LM5Lu2s7sOtHC1F+wr2Zb8gTVebsTmhiS203u5V1MauldB1iJS6lXq1s
H/31ukMrElgxu+xECTlGwRehC1DAWVfbvJpBU8slbjviLK9AG+HOh/uHVMBg2odGHQmgBSDNzc5A
bvqVV/t3h+91JntsBiR5A/oq40Hoj8cnnNWqQIAZPwrCkZ9grL5IIvP7S5TFaZPxX99/rhQ4LE4E
p+cUbjhFsT+JwyGnIIkpJl8opxne2UFc7h/nO4h/HCJi4tojjjaI4zCM/CFiP54kxPzAET9ziylr
v+5sS1x7xCcbxMkoDLayrR8n7o8DR/zMLX79iIlrjzjeIA5cXh4mZvw83cL8BquIiR9FFNl/FDk+
Z64y2NQ82zWOz2mhf/Cdo8JC2lXO/euKg1TpBRoPBBpHoaumfsf8mxWIVOkFSjYCkTouTP4LRKr0
Ak0GAsUn4+3a581GEKmCBf7Wq6pLW1sJvX5x4eD6gTl9AgAA//8DAFBLAQItABQABgAIAAAAIQAo
12LI+QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG
AAgAAAAhAI7qKvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAAKgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG
AAgAAAAhAHURXM6JAgAApg4AACEAAAAAAAAAAAAAAAAAEQIAAGRycy9zbGlkZU1hc3RlcnMvc2xp
ZGVNYXN0ZXIxLnhtbFBLBQYAAAAAAwADAMkAAADZBAAAAAAPAO4D8wYAAAIA7wMYAAAAEAAAAAAA
AAAAAAAAAAAAgAAAAAAHAAwwDwAMBPoFAAAPAALw8gUAANAACPAIAAAABQAAAAYIAAAPAAPwigUA
AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPAgAQAA
ogwK8AgAAAACCAAAAAoAAMMAC/BuAAAAfwABAO8BgAAgU9gJgQAAAAAAggAAAAAAgwAAAAAAhAAA
AAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMA
ZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8PBAAAAAQAAAAA
AKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcPCAAAAAAA
AAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALw
AxAFDwAE8CwBAACiDArwCAAAAAMIAAAACgAAwwAL8H4AAAB/AAEA7wGAADhg2AmBAAAAAACCAAAA
AACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwAaQBk
AGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDwCAAAAF0Q
uA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAAC
AAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYA
AAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwQwEAABIACvAIAAAABAgAACACAAADAQvweAAA
AAQAAAAAAH8AAQDvAYAAxF3YCYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgA
AAAAAL8ABAAEAP8BAAARAAEDAwQAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABl
ACAAMgAAAAAAEPAIAAAAiwXxAE4VGQcPABHwEAAAAAAAwwsIAAAA/////w0A2AkPAA3wgwAAAAAA
nw8EAAAAAAAAAAAAqA8PAAAAWGVuIHZNQ0UgRGVzaWduAAChDxwAAAAQAAAAAAAACAoAAQAHABAA
AAABACIAAAAEACAAAACqDzQAAAADAAAABwAAAAMACQQECAEAAAAGAAAACQQECAQAAAAHAAAAAwAJ
BAQICAAAAAYAAAAJBAQIDwAE8KsBAAASAArwCAAAAAUIAAAgAgAAAwEL8HgAAAAEAAAAAAB/AAEA
7wGAANBw2AmBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAAAACHAAAAAACIAAAAAAC/AAQABAD/
AQAAEQABAwQEAAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAAAABDw
CAAAAGYK0ASqEfIMDwAR8BAAAAAAAMMLCAAAAP////8OANgJDwAN8OsAAAAAAJ8PBAAAAAEAAAAA
AKgPTQAAAExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPg1KaWFuZywgWXVuaG9u
ZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+AAChDx4AAABOAAAAAAABCAoACAABAAcATgAAAAEA
IgAAAAQAEgAAAKoPQAAAAA4AAAAGAAAACQQECBUAAAAHAAAAAwAJBAQIEgAAAAYAAAAJBAQIFwAA
AAcAAAADAAkEBAgCAAAABgAAAAkEBAgAAKYPFAAAAPAeAADUASAB0AJAAvADYAMQBYAEDwAE8EgA
AAASAArwCAAAAAYIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/
AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAIYKgA/1xHAPXmRwCmyuEAVn65AAwuhgCqAUwA
DwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAC/
+scB0KOF6wAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA
VAn/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAAiBAgAAAABAAAABgAAAA8A
7gN/IgEAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACABAEAAAcADDAAAPkDEAAAAAAAAAAAAAAAAgAB
AAK9TjAPAAwE4NwAAA8AAvDY3AAAAAII8AgAAAAzAAAANYwAAA8AA/Bw3AAADwAE8CgAAAABAAnw
EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACMAAAFAAAADwAE8BwKAAASAArwCAAAAAKMAAAA
CgAAswEL8LoAAAB/AAAA7wGAAKzL2AmFAAIAAACHAAEAAAC/AAQABACAAQcAAACBAQQAAAiCAczM
AACDAU1daACEATOzAACMAWQAAAC/ARAAEAD/AQgAGACFAuCMAQCHAgQAAAi/AgoADgDBAgIABQDM
AtASEwDPAgCAAADQAgAAhwDTArA8///UArA8///XAlDDAAD/AhYAFwA/AwAACACAwxgAAAC/AwAA
AgBSAGUAYwB0AGEAbgBnAGwAZQAgADQAAAAjACLx2AgAAL8BAAAgAKmDzAgAAFBLAwQUAAYACAAA
ACEAWuMRZv4AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkU1PxCAQhu8m/gcyV9NSPRhj
Svdg9ahG1x8wgWlLtgXCYN3999L9uBjXxCPMvM/7BOrVdhrFTJGtdwquywoEOe2Ndb2Cj/VTcQeC
EzqDo3ekYEcMq+byol7vArHIaccKhpTCvZSsB5qQSx/I5Unn44QpH2MvA+oN9iRvqupWau8SuVSk
hQFN3VKHn2MSj9t8fTCJNDKIh8Pi0qUAQxitxpRN5ezMj5bi2FDm5H6HBxv4KmuA/LVhmZwvOOZe
8tNEa0i8YkzPOGUNaSJL479cpLn8G7JYTlz4rrOayjZym2NvNJ+sztF5wEAZ/V/8+5I7weX+h5pv
AAAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbv
g72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefj
YODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvB
gfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTn
QL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQDqFWJaYQQAAPwKAAAQ
AAAAZHJzL3NoYXBleG1sLnhtbKRWS3LjNhDdpyp3QHGb8kiUZdmjGnrKdsWThcdRWZ5k3SJBETEI
MAAkS75ClrlHbpDbJPfIQ0M/T6qSqZEWFEg00K/7NV7j3ftVq8VSOq+sKbL8TT8T0pS2UmZeZJ8e
b08uMuEDmYq0NbLI1tJn7y+//eZdN/adwGLjx12RNSF0417Pl41syb+xnTSYq61rKeDVzXudk16a
QAGOWt0b9PujXkvKZJfYyiyn3cTFUXm/nDihqiIbnI36w0wYauH2QZYAMddSDLPexi4tIeC4s+WT
34ChLwFTOXpGhK9wCGNvGviQV87Z50ZS5ZGQ6K3HsLYIDQCmj3vUHujF7PmjrYCVFsEiKhqvatce
iyruY+tarIpslOf5BehYF9lpPsxHo9MIjsZyFUSJ+fPz88GwDwJLWMTpc7xEpAlJNO2cDx+kPRqV
iBsVmQMrHCkt73xIrrYuoru5o+pWaX1sEoSz4WcVmmlDHRLcZ59zD5/sxYvOgqv0mUtQ3mgnlqRB
Rlmi6vKEUncNpc8Xffw2ydmt4FTN/eGeebT7343n1LbEXPiGKplcDEeD87PEkDLLDzsT2qMAQf+B
ArztYtTKCNRmkZ2B4bhI+JK0xDFJFbrPdUSvzdEZf8YBvDhDAIL0HMpQBsc5NDYSyrG2KkgntGqL
jNPJ+aRxPDnfm4pNAimdxghGm4hN1jWqBtQdCzHlG+zK0+rYvSKwEkLjaFPZWs6pXP840+rXhby2
Idj2Qc2bVO2oRqEJ9T/IB2/jLxMQx1iAwsll/Ac2BJx2ZELiWmwgnAKHafNbbDHIRKVckYVdKXI4
cYnvjg9LQBrcIkr7D5CH4SjWTTyfHwnMqXg8EhS8B8n0zuRS6kcB9vPTs2je7EbpyLMIp6pm2+sv
s90BwcHk6GKj+PcpTXl7bYxExlywDEedjeofVte2WseNZviH9qZG9PXa/+wIXcygxaHgTdlYkLIt
+RpEPa4StOSOKfVhGtZoSEe65jLedtKvDiAiij2oJXfHhYjBAw/0EjSDSGUqCCEP9ydaVLJ+pNn0
pcje5kNuHi4ke0l35to98YLamnDFMjAjjwwhIcrsp2PXRDedLEzJDjg9ZtqVceC7clKGJIkbNU2p
1AcW17L+3HZ7iLB+P3tVs+If7nlgt5mdLVBkTBjKYzF92Q1vEcbu5R5cc+4DzVLzojGy8ZCaO2cz
QpKmmpAjfBZPi1a19heV0spq/NKc3NxHiQx3/C7NyacptBn5TK14lnLPz8W2wHxw6gl9zNgpjzLx
JF28feFShO69r0TEyStNvEdp9SJxjGERSUBD4E6IW8vEWVvzhG/DjZbEUpRIiM+dZO802FutuDFz
0l8fxbDadpRXVjvZ5pwt7swmkYvYDjZjLgsR1p2sqQS6n6SryBA0R4WyuaVW6Xh3waWubMh5ycXC
+0k6WPb3H7/99efvn62CUu4WneSDQZKg0h+s+641J6XfKOmeN5bijuVjKxu40Pnu8h8AAAD//wMA
UEsDBBQABgAIAAAAIQCvnAmu2wAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9NawIxFEX3gv8h
PKE7TZR2lKlRpLRYuyg4lYK718lzZjAf0yR1xv76hi7a5eVezuUs173R7EI+NM5KmE4EMLKlU42t
JBzensYLYCGiVaidJQlXCrBeDQdLzJXr7J4uRaxYgtiQo4Q6xjbnPJQ1GQwT15JN3cl5gzFFX3Hl
sUtwo/lMiIwbbGx6qLGlh5rKc/FlJBTfuzPNF4/di/aB07s+zI9cSHkz6jf3wCL18X+8PX6+Zru/
8hf1rCTM7jJxC+y0vX74Ru0xRPISkl+yTabAVz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAFrjEWb+
AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEA6hViWmEEAAD8CgAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQA
BgAIAAAAIQCvnAmu2wAAAP0AAAAPAAAAAAAAAAAAAAAAALkGAABkcnMvZG93bnJldi54bWxQSwUG
AAAAAAQABAD1AAAAwQcAAAAAAAAQ8AgAAAC7B4EBoRTTCw8ADfBSAAAAAACfDwQAAAAEAAAAAACh
DxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPDAAAAPAA
AADUAdAC8AMQBQ8ABPAZBQAAEgAK8AgAAAADjAAAAAoAAOMAC/BsAAAAfwAAAO8BgAAI1dgJhQAC
AAAAhwABAAAAvwAEAAQAgQEBAAAIggEAAAAAvwEQABAAwAEMpCkAywHRVgAA/wEIABgAPwMAAAgA
gMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAIwAi8eQDAAD/AQAAQACpg9gDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAFKi5HnXAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj81KxDAU
hfeC7xCu4M5JLMwwUyczSMEfcDU/D3Btbptqk5Tc2Gl9eoMLXR7O4Tt82/3kejFS5C54DfcLBYJ8
HUznWw3n09PdGgQn9Ab74EnDTAz73fXVFksTLv5A4zG1IkM8l6jBpjSUUnJtySEvwkA+d02IDlOO
sZUm4iXDXS8LpVbSYefzg8WBKkv15/HLafhQ6yo+OzsPb2pTkK243zSs9e3N9PgAItGU/sfL0xj5
+6/8Rb0aDcVypQoQzcv8HjtzQE4UNWS/bJtNQe5+AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA
AAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA
AAAhAFKi5HnXAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA
AwADALcAAAALAwAAAAAAABDwCAAAAAgK0gYZEXMLDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAA
BwRAAAAAAAAAAAAAAAYAAQABAAAAAAANMA8ADfBdAAAAAACfDwQAAAAEAAAAAACoDwMAAAANDQ0A
AKEPFgAAAAQAAAAAAAAAAAAEAAAAAAAiAAQADAAAAKoPDAAAAAQAAAAGAAAACQQECAAApg8MAAAA
8AAAANQB0ALwAxAFDwAE8BsFAACiDArwCAAAAASMAAAACgAA0wAL8GQAAAB/AAAA7wGAALDc2AmB
AAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/AwAACACAwxYA
AAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAzAAAAIwAi8ecDAAD/AQAAQACpg9sDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhAAU9f3LaAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tOwzAURPdI/IN1
kdgg6mBohULdCiEQrChp+IBLfBMHYju1TR58fS0WsBzN6IzOejuZjg3kQ+ushKtFBoxs5VRrGwnv
5dPlLbAQ0SrsnCUJMwXYbk5P1pgrN9qChn1sWILYkKMEHWOfcx4qTQbDwvVkU1c7bzCm6BuuPI4J
bjousmzFDbY2PWjs6UFT9bX/NhLqn9INN8Or/ix386M4LN96cTFKeX423d8BizTF/3EhdofG/JW/
qBclQSxX2TWw+nn+8K0qMETyEpJfsk2mwDdHAAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
AAU9f3LaAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwAD
ALcAAAAOAwAAAAAAABDwCAAAACwKMQqDDbIKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwQA
AAAAAAAAAAAAAAUAAQABAAAAAAANMA8ADfBkAAAAAACfDwQAAAAEAAAAAACoDwgAAABIb3N0IE1D
RQAAoQ8YAAAACQAAAAAAAAAAAAkAAAABACIAAQAEAA4AAACqDwwAAAAJAAAABgAAAAkEBAgAAKYP
DAAAAPAAAADUAdAC8AMQBQ8ABPAwAQAAEgAK8AgAAAAFjAAAIAIAABMBC/B+AAAABAAAAAAAfwAB
AO8BgADk39gJgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA
/wEAABEAAQMDBAAAPwMAAAgAgMMYAAAAiAMAAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA1
AAAAAAAQ8AgAAADLAA4BaxVZAg8AEfAQAAAAAADDCwgAAAD/////DQDYCQ8ADfBqAAAAAACfDwQA
AAAAAAAAAACoDxQAAABYZW4gTUNFIEFyY2hpdGVjdHVyZQAAoQ8YAAAAFQAAAAAAAAgAAAEAFQAA
AAEAIAAAAAQAAACqDxoAAAADAAAABwAAAAMACQQECBIAAAAGAAAACQQECA8ABPBACQAAEgAK8AgA
AAAGjAAAAAoAACMBC/CEAAAAfwAAAO8BgADM7NgJhQACAAAAhwABAAAAvwAEAAQAgAEHAAAAgQEE
AAAIggEzswAAgwFNXWgAhAFlZgAAjAFkAAAAvwEQABAAwAEEAAAIywGfbwAA/wEIABgAPwMAAAgA
gMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA2AAAAMwAi8TIIAAC/ASAAIAD/AQAAQACp
gyAIAABQSwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFN
T8QgEIbvJv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS/bgY18QjzLzP+wTq1XYaxUyRrXcK
rssKBDntjXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnHCoaUwr2UrAeakEsfyOVJ5+OEKR9j
LwPqDfYkb6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD4tKlAEMYrcaUTeXszI+W4thQ5uR+
hwcb+CprgPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5/BuyWE5c+K6zmso2cptjbzSfrM7R
ecBAGf1f/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVs
cy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2
tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0p
oDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfX
eKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAA
ACEApcuiibYDAAAkCQAAEAAAAGRycy9zaGFwZXhtbC54bWykVUtuIzcQ3QfIHYjeBhp9xvpYmPbA
NuLJQmMIlidZl9hsNSM22SCpn6+QZe6RG+Q2M/dIVVE/GwgSjLSwq7uLVa9eVT1++LitjVgrH7Sz
edZ918mEstIV2i7y7MvzQ2uUiRDBFmCcVXm2UyH7ePPjDx+acWgEHrZh3ORZFWMzbreDrFQN4Z1r
lMVvpfM1RHz0i3bjVVA2QsREtWn3Op1BuwZtsxsMZdezZurJko/rqRe6yLNef9AZZMJCjWmflEQQ
C6PEIGvv/dIRQBwTJ5dhDwb+D5jCwwYrfIVDWHdfYQ51673bVAqKgIRQtjbDOiC0CDC9PKEOiF7M
N59dgVhhFR1WBeNt6etLUVEcV5Zim2eDzvWgg/3Z5Vm/O+qSjThgrLZRSPw+HA57V+Qg0WMw6o+S
QzsBIc/Gh/hJuYtBCQqUZx6bwoXCehIicXJKQekWHooHbcylHAjv4m86VrMKGuS3yzkXAXNyliAa
h63q8GueQHVvvFiDwV5IiUOXToBpKkivhx38cWtxfGhm6QTjX4TzmF3y+8/AC6hr4FaECgqVUlwN
esN+apC2609HlzMU76/x968okMxjjUZbgaOJjccGEyIRJBiFW5IG9MQ1oTf2YsY3uH+jPhYgwCxQ
GGT0iV5nNPeU8hyZe811GoRw7lnrqLwwus4znEoqgOmiJfvZFmxH0CbZWLixFF+VJU4YtvnScggR
6VWSmLi9c8WOEszxPy5uUrHvF46NB5RAi/qIdFlZOZ8I47pMiLO4Q+G6MAsHOyjud2OlqkmravAT
Whkyntgwa1wXfKFtgRvD5qn1olDlM8xnL3l23b1ikfEx+SuY2Du/5AOls/GW52UOAckwqPb29JnU
FVV3urKSExAYY2eNJCM0cipjmqT92lHbXnvcqfKt73GNG3n6eluyNJzHPPPbf52vcOmft0zsfDV7
OZoPWMbx4RHbyi4R5jiKbCIbT+kSYDYJkrLFFDzga7Fc1bp2v+tEK6/tS9W6f6RdihN+Vrb1ZYZL
jHwmyZ4n7vnv6jBLIXq9RMGzbsZWJpbK0y2Nlyeq/GnosE4+aem+NfpF/cKP1ARUDoyA7tZNvXMl
26GO90YBhkraltbNOhLrA+nM8/kOv9n2uD1Iz6tNP+4sE7Wa2D2RK4q9t3ksRNw1qgSJ6H5VvgAL
mWh0lNUD1NrgDfb+CmuswAfFw8LxFJwd+/bXH1///vPNqd7ZoVa310tCI8PZuZ9q25Jhr7unvqXr
i5XioBAsGjf/AAAA//8DAFBLAwQUAAYACAAAACEAAk4aydoAAAD9AAAADwAAAGRycy9kb3ducmV2
LnhtbESPTUsDMRRF94L/ITzBnc100Chj0yIFmRZEaLWL7p6T18noJJkmcT7+vcGFLi/3ci5nsRpN
y3ryoXFWwnyWASNbOdXYWsL72/PNA7AQ0SpsnSUJEwVYLS8vFlgoN9gd9ftYswSxoUAJOsau4DxU
mgyGmevIpu7kvMGYoq+58jgkuGl5nmWCG2xsetDY0VpT9bX/NhLOL5v55/3ttht0nztRlevSHSYp
r6/Gp0dgkcb4Py6P51ex/St/URslIb8TmQB2KqcP36gdhkheQvJLtskU+PIHAAD//wMAUEsBAi0A
FAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEApcuiibYDAAAkCQAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBl
eG1sLnhtbFBLAQItABQABgAIAAAAIQACThrJ2gAAAP0AAAAPAAAAAAAAAAAAAAAAAA4GAABkcnMv
ZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAFQcAAAAAAAAQ8AgAAADADIABoBRwDg8ADfBSAAAA
AACfDwQAAAAEAAAAAAChDxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAA
AAQICQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPD+AAAAogwK8AgAAAAHjAAAAAoAANMAC/BkAAAA
fwAAAO8BgABQ9NgJgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAAYAvwEAABEAywFwxgAA/wEA
ABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwAAABMAIvEGAAAA/wEAAEAA
AAAQ8AgAAADeDIQSrRNkDQ8ADfBcAAAAAACfDwQAAAAEAAAAAACoDwIAAABIVwAAoQ8WAAAAAwAA
AAAAAAAAAAMAAAAAACIABAAOAAAAqg8MAAAAAwAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvAD
EAUPAATwCAoAABIACvAIAAAACIwAAAAKAADDAQvwwAAAAH8AAADvAYAAEACXCoUAAgAAAIcAAQAA
AL8ABAAEAIABBwAAAIEBBAAACIIBzMwAAIMBTV1oAIQBM7MAAIwBZAAAAL8BEAAQAP8BCAAYAIAC
gDgBAIECwKoAAIUC4IwBAIcCBAAACL8CDgAOAMwC0BITAM8CAIAAANACAACHANMCsDz//9QCsDz/
/9cCUMMAAP8CAgAHAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAOQAAACMA
IvG+CAAAvwEgACAAqYOyCAAAUEsDBBQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCBaUu2BcJg3f330v24GNfEI8y8
z/sE6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr5vKiXu8CschpxwqGlMK9lKwH
mpBLH8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP23x9MIk0MoiHw+LSpQBDGK3G
lE3l7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84ZQ1pIkvjv1ykufwbslhOXPiu
s5rKNnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAA
AI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++
pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6
JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s
3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//
AwBQSwMEFAAGAAgAAAAhAOxCQwtGBAAAwwoAABAAAABkcnMvc2hhcGV4bWwueG1spFZLbiM3EN0H
yB2I3gYefWzJtjDyYGzEk4VtCJYnWZfYbDVjNtkgKVnyFbLMPXKD3Ca5Rx6L+nmCIIPRRqruLrJe
vSq+4vsPq8aIpfJBOzsueu+6hVBWulLb+bj4/HR7clGIEMmWZJxV42KtQvHh6vvv3rej0AostmHU
jos6xnbU6QRZq4bCO9cqi2+V8w1FPPp5p/UqKBspIlBjOv1ud9hpSNviClvZ5bSd+GTJh+XEC12O
i/5g2L0shKUGYR+VBIi5UeKy6Gz88hICjjsnn8MGDH0NmNLTCzJ8g0NYd1MjhvrovXupFZUBhKRo
HYa1RWgBML/cow5AL2Yv964EVlpEh6xotKp8cyyqtI+rKrEaF6Bj2EV91uPisnvRHXQTNhqpVRQS
nwe9i+Hp8LQQEg69i2633x8w+gwkubY+xE/KHQ1KpI3GhUdROFFa3oWYONmHSOHmnspbbcyxHAjv
4i861tOaWvDb45jzgJgcJYjWoVRdfs0dqG6MF0syqIWUaLq8gkxbU34NdsBkRrxbwfjn4XDPXvL7
343n1DTEtQg1lSqHOBv2z5l/Gmm7/LRzOUBxzpv/FwqQucvRaCvQmijyWUYkgiSjcEpyg+65TuiN
PZrxF5y/iwESEGTmEAYZPdPb6Ki8MLoZF8zhpgfTafnRlsxBJG2yjQyMTYBUVaFVUK9jcWWSUVJ1
Wh67VwImIS6eNu1s1JzkegItbIFWL9W1i9E1j3pex3zUTDLxLLxGLbL/raHYL0Sp/bhgN2QdMsIU
IbTHIxU44n6RFPqncXF+xiKQTuA9oRg6tXmGcq8iGS7TTC2VeRKoYu90kDSj3ln56LKW5qTY9/rr
fHdAcMA4u6T3/z5tuaXfOidawAWraZLLJOJxde3Kddpohn9IaJ4n3y7hL54wjCwmFRrXytqhKNvW
rVCop1WGlsOlwCbEaVxjrhwZmjtzOxC/OYGEKI2ShvxdUrRkPLJhligzXmhbQtDY3J9MUarqiWbT
V0yG3hkkohA+Zn9Fd/baP/OCytn4kY/zjAIYAiHa7j+n4YehOFlYyQGYHjttZTJCKycyZmnbqGKm
0hx4XKvqS9+dyrZy//Vjxcp9uOeB3+brbIEm44KhPRbT1515izR2Dw+oNXMfaQaBYRNsPOYZzWwm
SMqWE/KE1+J50ejG/aozrayqr/XJzUOSunjHz8qefJ7i3gM++8zmLHPPv4ttg4Xo9TPmkXVTtgrx
rHy6ROFugym870TkySttug4Z/apwjOGRigBhxw54sG7inavYDk28MYqwVR49WUStS7N0Szrz7Izm
AcsPb49iXG0nQzj02ikxE7W4sxsiF2nvjc1tIeK6VRVJoPtZ+ZIsFaLVUda31GiDG8bpGXKsyQfF
zcL7KTpY9vcfv/315+9frIJS7had9Pr9LEEyHKz7obEnMmyG875u+XbB8rGVDdzLQnv1DwAAAP//
AwBQSwMEFAAGAAgAAAAhAINfInHcAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8FOAjEURfcm
/kPzTNwY6UhwgJFCjAYHNiaALtw9p2+mhWk7thWGv7dxocube3NuzmzRm5YdyQftrIC7QQaMbOWk
to2At93ydgIsRLQSW2dJwJkCLOaXFzMspDvZDR23sWEJYkOBAlSMXcF5qBQZDAPXkU1d7bzBmKJv
uPR4SnDT8mGW5dygtulBYUdPiqrD9tsICPvx8mX0rPfjsrmpp7QeqfeDE+L6qn98ABapj//j8uPr
NV//lb+olRQwvM+zKbC6PH96LTcYInkByS/ZJlPg8x8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAFrj
EWb+AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEA7EJDC0YEAADDCgAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBleG1sLnhtbFBLAQIt
ABQABgAIAAAAIQCDXyJx3AAAAP0AAAAPAAAAAAAAAAAAAAAAAJ4GAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAQABAD1AAAApwcAAAAAAAAQ8AgAAAA8AoABQw6qBg8ADfBSAAAAAACfDwQAAAAEAAAA
AAChDxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPDAAA
APAAAADUAdAC8AMQBQ8ABPACAQAAogwK8AgAAAAJjAAAAAoAANMAC/BmAAAAfwAAAO8BgACoCpcK
gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMAAAgAgMMY
AAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQAwAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAJcC
rwEvAzEDDwAN8F4AAAAAAJ8PBAAAAAQAAAAAAKgPBAAAAGRvbTAAAKEPFgAAAAUAAAAAAAAAAAAF
AAAAAAAiAAQAEAAAAKoPDAAAAAUAAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8EMJ
AAASAArwCAAAAAqMAAAACgAAIwEL8IYAAAB/AAAA7wGAAAAOlwqFAAIAAACHAAEAAAC/AAQABACA
AQcAAACBAQQAAAiCAczMAACDAU1daACEATOzAACMAWQAAAC/ARAAEADAAQQAAAjLAZ9vAAD/AQgA
GAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADEAMQAAADMAIvEzCAAAvwEg
ACAA/wEAAEAAqYMhCAAAUEsDBBQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCBaUu2BcJg3f330v24GNfEI8y8z/sE
6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr5vKiXu8CschpxwqGlMK9lKwHmpBL
H8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP23x9MIk0MoiHw+LSpQBDGK3GlE3l
7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84ZQ1pIkvjv1ykufwbslhOXPius5rK
NnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8B
AAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBY
Rm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpS
ohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfG
ctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQ
SwMEFAAGAAgAAAAhAF4JdJK2AwAAJgkAABAAAABkcnMvc2hhcGV4bWwueG1spFVLbiM3EN0HyB0I
bgONWrJsa4RpD2wjniw0hmB5knWJzVYzYpMNkvr5ClnmHrlBbjNzjxSLrZbsLBKMvJDZZLHq1auq
xw8fd7VmG+m8sibng3cZZ9IIWyizzPmX54femDMfwBSgrZE530vPP978+MOHZuIbhpeNnzQ5r0Jo
Jv2+F5Wswb+zjTR4VlpXQ8BPt+w3TnppAgQMVOv+MMuu+jUow2/QldnMm5mLK/G4mTmmipwPL68G
A84M1Bj2SQoEsdSS4V6/NUx3AIFMrVj5Fg38HzSFgy2m+AoIM/a+wiDy1jm7rSQUHhmJ0fqE6wDR
IMK0eYTtET5bbD/bAsHCOlhMCya70tXnoop+bFmyXc6vsvFoPMaC7HP+fjAaZVkEBxO5C0zg+fAi
uxhdDTkTaDC4fn8xvr4k+AlJNG2cD5+kPRsVi45y7rAslClspj5EUo4hYrilg+JBaX0uCczZ8JsK
1byCBgkeUMylx5gUxbPGYq0y2qYelPfasQ1oLIYQ2HbpBuimgrQ9zvCvJae7QfiX/tTnINr9p+Ml
1DVQLXwFhUwhsBSJf5gos/nUmZyguCbnibd/o0Ayuxy1Mgx7M+eXWPaIiHkBWuKcpA49ch3Ra3M2
41vsp/ElJsBAL1EaRHCJXqsV1TTG6TC/5rpN6NSyVkE6plWdc6K+bd04ZT+bgqgLoHRaY+LaRP+y
LLHDsMznphMRRcVKIhN2d7bYxwAL/I+Tm3Ts+5Vj6wBF0KBCIl1GVNYlwigv7cM87FG6zoxCzg6a
+91YY9ZRrGpw0zgycfFEC73BccENZQqcGFoeS88KWT7DYv7SSQ9zIdlLmJo7t6ILpTXhlvplAR7J
0Kj35ngc5RVld7Y2ggJEMNrMGxEXvhEzEVIntWMXy/ba4k6Wb227MW7E8fS2JGk49Xli154u1igT
zzsidrGev3TLB0yj+3jEspJJgAW2Ii2Rjaf0ChCbEZI0xQwc4DZbrWtV299VopXG9qXq3T/GWQpT
+pam92WOQ4x8DqOQs0Xinn7Xh17ywakVCp6xc1pxtpIuvtP4fKLMH5sO86SbJr64Wr3IX+gzFgGV
Az2gubEzZ21Ja1+Hey0BXSVtS+NmbBTrA+nE8+kMv5n2sDtIjz+16maWiFpPTUvkOvpu19QWLOwb
WYJAdL9KV4ABzhoVRPUAtdL4hF2MMMcKnJfULORPwsm1b3/98fXvP9/ciu/f4VJvMBymN1L4k3s/
1aYnfKv+x7ql54uU4qAQJBo3/wAAAP//AwBQSwMEFAAGAAgAAAAhAP6g8PrbAAAA/QAAAA8AAABk
cnMvZG93bnJldi54bWxEj1FLwzAUhd8F/0O4gm8u7aZ11GVDirLJQOi2F9+uzW0b2iQ1ybbOX2/w
QR8P5/AdvsVq1D07kfPKGgHpJAFGprJSmUbAYf96NwfmAxqJvTUk4EIeVsvrqwXm0p5NSaddaFiE
GJ+jgDaEIefcVy1p9BM7kIldbZ3GEKNruHR4jnDd82mSZFyjMvGhxYGKlqpud9TxtzDFuJ0fN4/d
TM6+le3uy/pFiNub8fkJWKAx/I/XH1/v2dtf+YvaSAHThyxNgdXry6dTskQfyAmIftE2mgJf/gAA
AP//AwBQSwECLQAUAAYACAAAACEAWuMRZv4AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC8B
AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBeCXSStgMAACYJAAAQAAAAAAAAAAAAAAAAACoC
AABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAP6g8PrbAAAA/QAAAA8AAAAAAAAAAAAA
AAAADgYAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAAAWBwAAAAAAABDwCAAAAEAC+Q6k
FKoGDwAN8FIAAAAAAJ8PBAAAAAQAAAAAAKEPFAAAAAEAAAAAAAAAAAABAAAAAAAgAAQAAACqDw4A
AAABAAAABwAAAAAABAgJBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BABAACiDArwCAAAAAuMAAAA
CgAA0wAL8GYAAAB/AAAA7wGAABgclwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAA
EQDLAXDGAAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADIAAAAT
ACLxBgAAAP8BAABAAAAAEPAIAAAAxQLsEGwSXwMPAA3wbAAAAAAAnw8EAAAABAAAAAAAqA8EAAAA
ZG9tVQAAoQ8WAAAABQAAAAAAAAAAAAUAAAAAACIABAAQAAAAqg8aAAAABAAAAAcAAAADAAkEBAgB
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCaBAAAQgEK8AgAAAAMjAAAwAoAANMA
C/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAIywE4YwAA0QEB
AAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADEAMwAAABMAIvHYAwAAqYPSAwAA
UEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH
70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23
jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3
VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0
r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//
AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0
X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8w
Wl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXR
gPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8A
AAD//wMAUEsDBBQABgAIAAAAIQBPj6TP0QAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/NSgMx
FIX3gu8QruBGbNKKQxmbliJIXbhprfvr5M5MNLkZktjO9OnNQnB5OH98q83onThRTDawhvlMgSBu
grHcaTi+v9wvQaSMbNAFJg0TJdisr69WWJtw5j2dDrkTZYRTjRr6nIdaytT05DHNwkBcvDZEj7nI
2EkT8VzGvZMLpSrp0XJ56HGg556a78OP13BpLyoe7xS73XKy49v2o/oanNa3N+P2CUSmMf+H/9qv
RsPisZo/gGh302e0Zo8pU9RQkApggQO5/gUAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBP
j6TP0QAAAPAAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAABQMAAAAAAAAQ8AgAAAAiBloHWgcICg8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcAQAAA
AAAAAAAAAAAeAAEAAQAAAAAADTAPAATwgAAAAEIBCvAIAAAADYwAAAAKAADDAAvwWAAAAH8AAADv
AYUAAgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAQAACM4BBgAAAP8BGAAYAD8DCAAIAIDD
EAAAAL8DAAACAEwAaQBuAGUAIAAxADQAAAAAABDwCAAAAIoECQK7DYoEDwAE8FQFAAASAArwCAAA
AA6MAAAACgAA4wAL8G4AAAB/AAAA7wGAADAnlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQA
BACBAQQAAAi/ARAAEADAAQykKQD/AQgAGAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBn
AGwAZQAgADEANQAAACMAIvHnAwAA/wEAAEAAqYPbAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCH+As/
2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9RS8MwFIXfBf9DuIJvLl1xU+qyMQWp4Itrdfh4
19ylxeZmJHHt/PWGPejj4Ry+w7dYjbYXR/Khc6xgOslAEDdOd2wUvNfPN/cgQkTW2DsmBScKsFpe
Xiyw0G7gDR2raESCcChQQRvjoZAyNC1ZDBN3IE7d3nmLMUVvpPY4JLjtZZ5lc2mx4/TQ4oGeWmq+
qm+r4MP0Jh/q8vPnrW7cuqx2d9v4qtT11bh+ABFpjP/jR7Pl2+GvPKNetIJ8Np/OQOzL0853eoMh
kleQ/JJtMgW5/AUAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAA
AAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCH+As/2gAAAP0AAAAPAAAA
AAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADgMAAAAAAAAQ8AgA
AADFAkcDuw0CBA8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcERAAAAAAAAAAAAAAlAAEAAQAA
AAAADTAPAA3wkwAAAAAAnw8EAAAABAAAAAAAqA8dAAAAVXNlciBzcGFjZSB0b29scyAoRk1BL21j
ZWxvZykAAKEPGAAAAB4AAAAAAAAAAAAeAAAAAQAiAAEABAAOAAAAqg8mAAAAFgAAAAYAAAAJBAQI
BgAAAAcAAAADAAkEBAgCAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCbBAAAQgEK
8AgAAAAPjAAAAAoAANMAC/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEA
wAEBAAAIywE4YwAA0AEBAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADEANgAA
ABMAIvHZAwAAqYPTAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv
9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q
50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9
QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhd
jr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVs
c2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnC
ruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ
1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB
9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCsVTpU0gAAAPAAAAAPAAAAZHJzL2Rv
d25yZXYueG1sRI/NasJAFIX3Bd9huEJ3daJgkNRRilhMcVESu3F3zVyT0MydMDM1ydt3FoUuD+eP
b7sfTSce5HxrWcFykYAgrqxuuVbwdXl/2YDwAVljZ5kUTORhv5s9bTHTduCCHmWoRRxhn6GCJoQ+
k9JXDRn0C9sTR+9uncEQpauldjjEcdPJVZKk0mDL8aHBng4NVd/lj1HwwfY83MrNOT/y53RaX8dr
nhZKPc/Ht1cQgcbwH/5r51rBap0uUxD303RzrS7QB3IKIlIEjHAgd78AAAD//wMAUEsBAi0AFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ
SwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQ
SwECLQAUAAYACAAAACEArFU6VNIAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYu
eG1sUEsFBgAAAAADAAMAtwAAAAYDAAAAAAAAEPAIAAAAcAuBD4IPEw0PABHwLAAAAA8AFBAkAAAA
AQDxDxwAAAAAAAAHAEAAAAAAAAAAAAAAAgABAAEAAAAAAA0wDwAE8JwEAABCAQrwCAAAABGMAACA
CgAA0wAL8F4AAAB/AAAA7wGFAAIAAACHAAEAAAC/AAQABAB/AQAAAQC/AQAAEQDAAQIAAAjLAThj
AADQAQEAAAD/ARgAGAA/AwgACACAwxAAAAC/AwAAAgBMAGkAbgBlACAAMQA4AAAAEwAi8doDAACp
g9QDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDP
TsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3Bd
VqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdAB
zQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6
IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/
AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg
+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1c
L8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+
9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg
0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAIXok+zTAAAA8AAAAA8AAABkcnMvZG93bnJldi54bWxE
j8FOwzAMhu9IvENkJG4sXSUm6JZNExKDI9uA7Wgarw1tnCpJ1+7tCRISR+v3/9nfYjXaVpzJB+NY
wXSSgSAunTZcKXjfP989gAgRWWPrmBRcKMBqeX21wEK7gbd03sVKJAiHAhXUMXaFlKGsyWKYuI44
ZSfnLcY0+kpqj0OC21bmWTaTFg2nCzV29FRT2ex6qyBb9/33R7M5vA3RbPJPd3zsmqNStzfjeg4i
0hj/l//ar1pBfj+bpn9PL5cvb/QWQySfaPArmORALn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh
9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEAheiT7NMAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA
AAADAAMAtwAAAAcDAAAAAAAAEPAIAAAAIgbYDNgMcAgPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAA
AAAHBEAAAAAAAAAAAAAAGQABAAEAAAAAAA0wDwAE8JsEAABCAQrwCAAAABKMAACACgAA0wAL8F4A
AAB/AAAA7wGFAAIAAACHAAEAAAC/AAQABAB/AQAAAQC/AQAAEQDAAQIAAAjLAThjAADRAQEAAAD/
ARgAGAA/AwgACACAwxAAAAC/AwAAAgBMAGkAbgBlACAAMQA5AAAAEwAi8dkDAACpg9MDAABQSwME
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD
5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbe
t0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN
50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXy
N+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBL
AwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5Q
xojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u
5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0
p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//
AwBQSwMEFAAGAAgAAAAhAIUiVAvSAAAA8AAAAA8AAABkcnMvZG93bnJldi54bWxEj11LwzAUhu8F
/0M4gncu7aDF1WVDikMvBN0Udntsztpoc1KSuLb/3lwIu3x5v3jW28n24kw+GMcK8kUGgrhx2nCr
4PNjd3cPIkRkjb1jUjBTgO3m+mqNlXYj7+l8iK1IIxwqVNDFOFRShqYji2HhBuLknZy3GJP0rdQe
xzRue7nMslJaNJweOhyo7qj5OfxaBXW5a+a37+Pq+GoK98Tle50Xo1K3N9PjA4hIU7yE/9svWsGy
KPMViNPz/OWN3mOI5BUkpASY4EBu/gAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCFIlQL
0gAAAPAAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAA
BgMAAAAAAAAQ8AgAAAAiBpEQkRAICg8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcAQAAAAAAA
AAAAAAAPAAEAAQAAAAAADTAPAATwmwQAAEIBCvAIAAAAE4wAAMAKAADTAAvwXgAAAH8AAADvAYUA
AgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAQAACMsBOGMAANEBAQAAAP8BGAAYAD8DCAAI
AIDDEAAAAL8DAAACAEwAaQBuAGUAIAAyADAAAAATACLx2QMAAKmD0wMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEAJJMtmNIAAADwAAAADwAAAGRycy9kb3ducmV2LnhtbESPwUoDMRCG74LvEEbwIjZxwaWs
TUsRpB68tNb7uJndjSaTJYntbp/eHASPM/P/3/CtNpN34kQx2cAaHhYKBHEbjOVew/H95X4JImVk
gy4waZgpwWZ9fbXCxoQz7+l0yL0oEE4NahhyHhspUzuQx7QII3G5dSF6zGWMvTQRzwXunayUqqVH
y+XDgCM9D9R+H368hkt3UfF4p9jtlrOd3rYf9dfotL69mbZPIDJN+T/81341GqrHuioC3W7+jNbs
MWWKGsqmCBY5kOtfAAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAA
AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACSTLZjSAAAA8AAAAA8A
AAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAGAwAAAAAAABDw
CAAAAAIEEAgQCBIFDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBAAAAAAAAAAAAAACQAAQAB
AAAAAAANMA8ABPA7BQAAEgAK8AgAAAAUjAAAAAoAAOMAC/BuAAAAfwAAAO8BgACQM5cKgQAAAAAA
ggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAgQEEAAAIvwEQABAAwAEMpCkA/wEIABgAPwMAAAgAgMMa
AAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyADEAAAAjACLx5wMAAP8BAABAAKmD2wMAAFBL
AwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9I
vEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46H
Bt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1
q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+E
dfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMA
UEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U
7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpd
Dm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDx
yTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA
//8DAFBLAwQUAAYACAAAACEALM+wstoAAAD9AAAADwAAAGRycy9kb3ducmV2LnhtbESPTUsDMRRF
94L/ITzBjdhMB6wyNi1FkBHd2BkVl6+T12QwH0MSO1N/vaELXV7u5VzOcj1Zww4UYu+dgPmsAEau
87J3SsBb+3h9BywmdBKNdyTgSBHWq/OzJVbSj25LhyYpliEuVihApzRUnMdOk8U48wO53O19sJhy
DIrLgGOGW8PLolhwi73LDxoHetDUfTXfVsC7Mqoc2/rz57Xt/KZudrcf6UWIy4tpcw8s0ZT+x1d6
eDb6rzyhnqSA8mZRzoHt6+Mu9HKLMVEQkP2ybTYFvvoFAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh
9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEALM+wstoAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA
AAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAEgV3Bk0JIgYPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAA
AAAHBEQAAAAAAAAAAAAAIAABAAEAAAAAAA0wDwAN8HoAAAAAAJ8PBAAAAAQAAAAAAKgPEAAAAG1j
ZWxvZyBpbnRlcmZhY2UAAKEPGAAAABEAAAAAAAAAAAARAAAAAQAiAAEABAAOAAAAqg8aAAAABgAA
AAcAAAADAAkEBAgLAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPA8BQAAEgAK8AgA
AAAVjAAAAAoAANMAC/BoAAAAfwAAAO8BgABUPpcKhQACAAAAhwABAAAAvwAEAAQAgQEEAAAIvwEA
ABAAwAEMpCkAywHRVgAA/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAAyADQAAAAjACLx5wMAAP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAA
AFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr2
9qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMs
DYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0
uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8
/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S
+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63l
E1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/
UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAUlbTLdoAAAD9
AAAADwAAAGRycy9kb3ducmV2LnhtbESPwUrDQBRF94L/MDzBjdiJIQ0SOy0ilGYRkLZWt8/MaxLM
vIkzY5r+vYOLurzcy7mcxWoyvRjJ+c6ygodZAoK4trrjRsHbfn3/CMIHZI29ZVJwJg+r5fXVAgtt
T7ylcRcaESHsC1TQhjAUUvq6JYN+Zgfi2B2tMxhidI3UDk8RbnqZJkkuDXYcH1oc6KWl+mv3YxRk
73n//XrIdvuPkTmpynV5pw9K3d5Mz08gAk3hfzyvsk1eXco/VKkVpPM8zUAcN+dP1+kt+kBOQfSL
ttEU5PIXAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAA
AAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAUlbTLdoAAAD9AAAADwAAAAAAAAAA
AAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAkAou
B1wKRgsPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAAAwABAAEAAAAAAA0w
DwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAE1DRSBTb2Z0aXJxAAChDxgAAAAMAAAAAAAAAAAA
DAAAAAEAIgABAAQADgAAAKoPJgAAAAQAAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIAQAAAAYAAAAJ
BAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwHwUAABIACvAIAAAAFowAAAAKAADTAAvwaAAAAH8A
AADvAYAAcEmXCoUAAgAAAIcAAQAAAL8ABAAEAIEBBAAACL8BAAAQAMABDKQpAMsB0VYAAP8BCAAY
AD8DAAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAzAAAAIwAi8egDAAD/AQAA
QACpg9wDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1s
fJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8
N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmX
cdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMieP
OzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWP
T2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMw
DAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxi
ni1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkv
NxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc
4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhADxwkpLbAAAA/QAAAA8AAABkcnMvZG93bnJldi54
bWxEj1FLwzAUhd8F/0O4gi/iUussUpcNEYYVhLHOzddrc9eWNTc1iV337xd80MfDOXyHb7YYTScG
cr61rOBukoAgrqxuuVbwsVnePoLwAVljZ5kUnMjDYn55McNc2yOvaShDLSKEfY4KmhD6XEpfNWTQ
T2xPHLu9dQZDjK6W2uExwk0n0yTJpMGW40ODPb00VB3KH6Ngusu679V2Wm4+B+bkvVgWN3qr1PXV
+PwEItAY/seH3duqNn/lL6rQCtKHLL0HsX89fblWr9EHcgqiX7SNpiDnZwAAAP//AwBQSwECLQAU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht
bFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVs
c1BLAQItABQABgAIAAAAIQA8cJKS2wAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJl
di54bWxQSwUGAAAAAAMAAwC3AAAADwMAAAAAAAAQ8AgAAACQCkcO3RBFCw8AEfAsAAAADwAUECQA
AAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAAEAAEAAQAAAAAADTAPAA3wYwAAAAAAnw8EAAAABAAA
AAAAqA8HAAAATUNFIElTUgAAoQ8YAAAACAAAAAAAAAAAAAgAAAABACIAAQAEAA4AAACqDwwAAAAI
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCcBAAAQgEK8AgAAAAXjAAAAAoAANMA
C/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAIywGcMQAA0AEB
AAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADIANQAAABMAIvHaAwAAqYPUAwAA
UEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH
70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23
jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3
VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0
r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//
AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0
X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8w
Wl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXR
gPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8A
AAD//wMAUEsDBBQABgAIAAAAIQC1OAPK0wAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9fS8Mw
FMXfBb9DuIIvwyVWWka3bAzBP4gI6wRfr81dW9bc1CR23bc3guDj4ZzzO5zVZrK9GMmHzrGG27kC
QVw703Gj4X3/cLMAESKywd4xaThTgM368mKFpXEn3tFYxUYkCIcSNbQxDqWUoW7JYpi7gTh5B+ct
xiR9I43HU4LbXmZKFdJix2mhxYHuW6qP1bfVoKovVbzExzDKuzf+ePUz3OYzra+vpu0SRKQp/of/
2s9GQ5YXWQ7i8HT+9J3ZYYjkEw1+D6ZzINc/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
ALU4A8rTAAAA8AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwAD
ALcAAAAHAwAAAAAAABDwCAAAAOsKXQpDDusKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwRE
AAAAAAAAAAAAAAcAAQABAAAAAAANMA8ABPApBQAAEgAK8AgAAAAYjAAAAAoAAOMAC/BuAAAAfwAA
AO8BgAAUVJcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAgQEEAAAIvwEQABAAwAEMpCkA
/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyADYAAAAjACLx5gMA
AP8BAABAAKmD2gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA/tdT9NkAAAD9AAAADwAAAGRycy9kb3du
cmV2LnhtbESPTUvDQBRF94L/YXiCOzsxYJS001IEiSKITVS6fM28fGBmJsw8m9Rf7+BCl5d7OZez
2sxmEEfyoXdWwfUiAUG2drq3rYK36uHqDkRgtBoHZ0nBiQJs1udnK8y1m+yOjiW3IkJsyFFBxzzm
Uoa6I4Nh4UaysWucN8gx+lZqj1OEm0GmSZJJg72NDx2OdN9R/Vl+GQXv7dCmU1Xsv1+r2m2L8nD7
wc9KXV7M2yUIppn/x0/8wg3/lb+oR60gvcnSDERTnA6+1zsMTF5B9Iu20RTk+gcAAP//AwBQSwEC
LQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8u
cmVsc1BLAQItABQABgAIAAAAIQD+11P02QAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93
bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADQMAAAAAAAAQ8AgAAAASBTAKuw0jBg8AEfAsAAAADwAU
ECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAARAAEAAQAAAAAADTAPAA3waQAAAAAAnw8EAAAA
BAAAAAAAqA8NAAAAUFYgR3Vlc3QgIE1DRQAAoQ8YAAAADgAAAAAAAAAAAA4AAAABACIAAQAEAA4A
AACqDwwAAAAOAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPA4BQAAEgAK8AgAAAAZ
jAAAAAoAAPMAC/B0AAAAfwAAAO8BgAC8XpcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQA
gQECAAAIvwEQABAAwAECAAAIywHRVgAA/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABh
AG4AZwBsAGUAIAAyADcAAAAjACLx5gMAAP8BAABAAKmD2gMAAFBLAwQUAAYACAAAACEA2+H2y+4A
AACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQew
EreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt
5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9
bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a
2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxk
svXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAu
sahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+s
PNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA
Gm/kMNkAAAD9AAAADwAAAGRycy9kb3ducmV2LnhtbESPUUvDMBSF3wX/Q7iCby5t1U3qsuEU0SnC
OgVfY3LXhDU3JYlr9+8NPujj4Ry+wzdfjq5jBwzRehJQTgpgSMprS62Aj/fHixtgMUnSsvOEAo4Y
Ybk4PZnLWvuBGjxsU8syhGItBZiU+przqAw6GSe+R8rdzgcnU46h5TrIIcNdx6uimHInLeUHI3u8
N6j2228nwK2uHjakL60yzWv3WRr19rJSQpyfjXe3wBKO6X+8bk25H/7KX9SzFlBdT6sZsN3T8StY
3ciYMAjIftk2mwJf/AAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAA
AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAab+Qw2QAAAP0AAAAP
AAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADQMAAAAAAAAQ
8AgAAABwCCMMNhAlCQ8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAATAAEA
AQAAAAAADTAPAA3wcgAAAAAAnw8EAAAABAAAAAAAqA8EAAAAdk1DRQAAoQ8cAAAABQAAAAAAAAAA
AAUAAAABACYAAQAEAA4AAAAAAwAAqg8aAAAABAAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgAAKYP
DAAAAPAAAADUAdAC8AMQBQ8ABPCdBAAAQgEK8AgAAAAajAAAAAoAANMAC/BeAAAAfwAAAO8BhQAC
AAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAIywE4YwAA0QEBAAAA/wEYABgAPwMIAAgA
gMMQAAAAvwMAAAIATABpAG4AZQAgADIAOAAAABMAIvHbAwAAqYPVAwAAUEsDBBQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDh
CAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/U
wIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjH
jympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrF
mJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGV
xCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yz
ra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23z
HztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAI
AAAAIQD6+z7E1AAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8MwDIbvg/0Ho0Fvq5OUdCOr
W8pY2RcM0g161WI1CY1lY3tt8u/nw2DHF716pGe1Gc0gzuRDb1lBPs9AEDdW99wq+Prc3d6DCBFZ
42CZFEwUYLO+vlphpe2FazrvYysShEOFCroYXSVlaDoyGObWEafZ0XqDMUXfSu3xkuBmkEWWLaXB
ntOFDh09dtSc9j9Gwdv0keuFKcu6fXJ3783i8Oryg1Kzm3H7ACLSGP/Lf9svWkFRLov07/F5+va9
rjFE8gqSUhJMciDXvwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAA
AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQD6+z7E1AAAAPAAAAAP
AAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACAMAAAAAAAAQ
8AgAAAAYCxkRKRIYCw8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAAJAAEA
AQAAAAAADTAPAATwJgUAABIACvAIAAAAG4wAAAAKAADjAAvwbgAAAH8AAADvAYAArEqXCoEAAAAA
AIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAAARAMABDKQpAMsB0VYAAP8BCAAYAD8DAAAIAIDD
GgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgA5AAAAIwAi8eQDAAD/AQAAQACpg9gDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAP6S5JzXAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj01LAzEU
RfeC/yE8wZ1NHLDotGlRwdaddFSsu+fkzQdNXoYkTqf/3uBCl5d7OZezXE/OipFC7D1ruJ4pEMS1
Nz23Gt5en65uQcSEbNB6Jg0nirBenZ8tsTT+yDsaq9SKDOFYooYupaGUMtYdOYwzPxDnrvHBYcox
tNIEPGa4s7JQai4d9pwfOhzosaP6UH07DZvaje8Phj+sMeFzM4222b9YrS8vpvsFiERT+h/jQW0r
9Vf+op6NhuJmXtyBaLanr9CbHcZEQUP2y7bZFOTqBwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA
AAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA
AAAhAP6S5JzXAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA
AwADALcAAAALAwAAAAAAABDwCAAAADYKVhIcFHMLDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAA
BwBAAAAAAAAAAAAAAAgAAQABAAAAAAANMA8ADfBoAAAAAACfDwQAAAAEAAAAAACoDwwAAABSZXNl
dCBzeXN0ZW0AAKEPGAAAAA0AAAAAAAAAAAANAAAAAQAiAAEABAAMAAAAqg8MAAAADQAAAAYAAAAJ
BAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwMgUAAKIMCvAIAAAAHIwAAAAKAADTAAvwZgAAAH8A
AADvAYAAnHOXCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABgAGAL8BAAARAMsBcMYAAP8BAAAY
AD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADMAMgAAACMAIvHnAwAA/wEAAEAA
qYPbAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQ
z07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdw
XVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQ
Ac0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsy
uiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09s
vwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG
4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4t
XC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcT
vvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA4
4NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQB03VUh2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1s
RI/LTsMwFET3SPyDdZHYIOpgaIVC3QrxEKwKTfiAS3wTh8Z2sE0efD0WC1iOZnRGZ72dTMcG8qF1
VsLFIgNGtnKqtY2Et/Lx/BpYiGgVds6ShJkCbDfHR2vMlRvtnoYiNixBbMhRgo6xzzkPlSaDYeF6
sqmrnTcYU/QNVx7HBDcdF1m24gZbmx409nSnqToUX0ZC/V264WrY6Y/yZX4Qn8vXXpyNUp6eTLc3
wCJN8X98fxAFz/7KX9SzkiCWq0sBrH6a332r9hgieQnJL9kmU+CbHwAAAP//AwBQSwECLQAUAAYA
CAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL
AQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BL
AQItABQABgAIAAAAIQB03VUh2gAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54
bWxQSwUGAAAAAAMAAwC3AAAADgMAAAAAAAAQ8AgAAADYBnIQZRKYBw8AEfAsAAAADwAUECQAAAAB
APEPHAAAAAAAAAcEAAAAAAAAAAAAAAAVAAEAAQAAAAAADTAPAA3weQAAAAAAnw8EAAAABAAAAAAA
qA8RAAAAaHZtIE1DRSBpbmplY3Rpb24AAKEPFgAAABIAAAAAAAAAAAASAAAAAAAiAAQACgAAAKoP
GgAAAAMAAAAHAAAAAwAJBAQIDwAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwMQUA
AKIMCvAIAAAAHYwAAAAKAADTAAvwZgAAAH8AAADvAYAAyH2XCoEAAAAAAIIAAAAAAIMAAAAAAIQA
AAAAAL8ABgAGAL8BAAARAMsBcMYAAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABC
AG8AeAAgADMAMwAAACMAIvHnAwAA/wEAAEAAqYPbAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQB8PjUd
2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LTsMwFET3SPyDdZHYIOrg0gqFuhXiIVgBTfiA
S3wTh8Z2sE0efD0WC1iOZnRGZ7ObTMcG8qF1VsLFIgNGtnKqtY2Et/Lh/ApYiGgVds6ShJkC7LbH
RxvMlRvtnoYiNixBbMhRgo6xzzkPlSaDYeF6sqmrnTcYU/QNVx7HBDcdF1m25gZbmx409nSrqToU
X0ZC/V264XJ41h/ly3wvPlevvTgbpTw9mW6ugUWa4v/47iAKnv2Vv6gnJUGs1sslsPpxfvet2mOI
5CUkv2SbTIFvfwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAA
AAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQB8PjUd2gAAAP0AAAAPAAAA
AAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADgMAAAAAAAAQ8AgA
AADgBioK1QugBw8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEBAAAAAAAAAAAAAAWAAEAAQAA
AAAADTAPAA3weAAAAAAAnw8EAAAABAAAAAAAqA8QAAAAcHYgTUNFIGluamVjdGlvbgAAoQ8WAAAA
EQAAAAAAAAAAABEAAAAAACIABAAKAAAAqg8aAAAAAgAAAAcAAAADAAkEBAgPAAAABgAAAAkEBAgA
AKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAmBQAAogwK8AgAAAAejAAAAAoAANMAC/BmAAAAfwAAAO8B
gACUhpcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMA
AAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMwA0AAAAIwAi8egDAAD/AQAAQACpg9wD
AABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMw
DIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCI
jbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H
0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZ
A/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA
//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2Dv
YHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3
DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e
5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPj
LwAAAP//AwBQSwMEFAAGAAgAAAAhAC3+LxbbAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tO
wzAURPeV+g/WRWJTUYfQVlWoWyEEAjZAGj7gEt/EKbEdbJMHX4/FApajGZ3R2R1G3bKenG+sEXC5
TICRKa1sTC3grbi/2ALzAY3E1hoSMJGHw34+22Em7WBy6o+hZhFifIYCVAhdxrkvFWn0S9uRiV1l
ncYQo6u5dDhEuG55miQbrrEx8UFhR7eKyo/jlxZQfRe2X/XP6lS8THfp5/q1SxeDEOdn4801sEBj
+B/npVNP27/yF/UoBaTrzdUKWPUwvbtG5ugDOQHRL9pGU+D7HwAAAP//AwBQSwECLQAUAAYACAAA
ACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt
ABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQIt
ABQABgAIAAAAIQAt/i8W2wAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAMAAwC3AAAADwMAAAAAAAAQ8AgAAAAXByoGlQd3Bw8AEfAsAAAADwAUECQAAAABAPEP
HAAAAAAAAAcEAAAAAAAAAAAAAAAfAAEAAQAAAAAADTAPAA3wbAAAAAAAnw8EAAAABAAAAAAAqA8E
AAAAdklSUQAAoQ8WAAAABQAAAAAAAAAAAAUAAAAAACIABAAKAAAAqg8aAAAABAAAAAcAAAADAAkE
BAgBAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAHBQAAEgAK8AgAAAAfjAAAAAoA
AMMAC/BiAAAAfwAAAO8BgACYkZcKhQACAAAAhwABAAAAvwAEAAQAvwEAABEAwAEMpCkAywGfbwAA
/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzADUAAAAjACLx5wMA
AP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA64atKtoAAAD9AAAADwAAAGRycy9kb3du
cmV2LnhtbESPUWvCMBSF3wf+h3CFvc1US510RimDzSGzYrcfcG2uTbFJuiTT+u8X9rA9Hs7hO3zL
9aA7diHnW2sETCcJMDK1la1pBHx+vDwsgPmARmJnDQm4kYf1anS3xFzaqznQpQoNixDjcxSgQuhz
zn2tSKOf2J5M7E7WaQwxuoZLh9cI1x2fJcmca2xNfFDY07Oi+lx9awFlzct9xb+yYps+9u/qdVMs
ZCrE/XgonoAFGsL/eB+O23L3V/6i3qSAWTZPM2Cnze3oWnlAH8gJiH7RNpoCX/0AAAD//wMAUEsB
Ai0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz
XS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMv
LnJlbHNQSwECLQAUAAYACAAAACEA64atKtoAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rv
d25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAQwg3AmcFcwsPABHwLAAAAA8A
FBAkAAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAADQABAAEAAAAAAA0wDwAN8FIAAAAAAJ8PBAAA
AAQAAAAAAKEPFgAAAAEAAAAAAAAAAAABAAAAAAAiAAQADAAAAKoPDAAAAAEAAAAGAAAACQQECAAA
pg8MAAAA8AAAANQB0ALwAxAFDwAE8DUFAAASAArwCAAAACCMAAAACgAA4wAL8G4AAAB/AAAA7wGA
AEySlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQAAEQDAAQykKQDLAdFWAAD/AQgA
GAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMANgAAACMAIvHmAwAA/wEA
AEAAqYPaAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnht
bHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkFori
PDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wp
l3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDIn
jzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2l
j09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrD
MAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYc
Yp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5
LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2
HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQD4vJiS2QAAAP0AAAAPAAAAZHJzL2Rvd25yZXYu
eG1sRI9NSwMxFEX3gv8hPMGdzVjpIGPTooLVxYC0Kurumbz5wORlSOJ0+u8NXejyci/ncpbryVkx
Uoi9ZwWXswIEsfam51bB68vDxTWImJANWs+k4EAR1qvTkyVWxu95S+MutSJDOFaooEtpqKSMuiOH
ceYH4tw1PjhMOYZWmoD7DHdWzouilA57zg8dDnTfkf7e/TgFG+3GtzvD79aY8LmZRtt8PFulzs+m
2xsQiab0P651nRb1X3lEPRkF80V5VYJoHg9foTdbjImCguyXbbMpyNUvAAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAPi8mJLZAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAANAwAAAAAAABDwCAAAAGMKZAI6BUYLDwAR8CwAAAAPABQQJAAA
AAEA8Q8cAAAAAAAABwRAAAAAAAAAAAAAAAwAAQABAAAAAAANMA8ADfB1AAAAAACfDwQAAAAEAAAA
AACoDwsAAABjcHUgb2ZmbGluZQAAoQ8YAAAADAAAAAAAAAAAAAwAAAABACIAAQAEAA4AAACqDxoA
AAADAAAABwAAAAMACQQECAkAAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CgFAAAS
AArwCAAAACGMAAAACgAA4wAL8G4AAAB/AAAA7wGAAHyklwqBAAAAAACCAAAAAACDAAAAAACEAAAA
AAC/AAQABAC/AQAAEQDAAQykKQDLAdFWAAD/AQgAGAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0
AGEAbgBnAGwAZQAgADMANwAAACMAIvHmAwAA/wEAAEAAqYPaAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQDE5fXy2QAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9LSwMxFIX3gv8hXMGdzVi1lbFpUcFq
V9LWvnbXyZ0HJjdDEqfTf29wocvDOXyHbzLrrREd+dA4VnA9yEAQF043XCn4WL9c3YMIEVmjcUwK
ThRgNj0/m2Cu3ZGX1K1iJRKEQ44K6hjbXMpQ1GQxDFxLnLrSeYsxRV9J7fGY4NbIYZaNpMWG00ON
LT3XVHytvq2CeWG7zZPmndHaH+Z9Z8r9u1Hq8qJ/fAARqY//4wMvbrf8V/6i3rSC4d3oZgyifD19
+kYvMUTyCpJfsk2mIKc/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAA
AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAMTl9fLZAAAA/QAA
AA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAANAwAAAAAA
ABDwCAAAAFMJZAI6BTYKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwRAAAAAAAAAAAAAAAsA
AQABAAAAAAANMA8ADfBoAAAAAACfDwQAAAAEAAAAAACoDwwAAABwYWdlIG9mZmxpbmUAAKEPGAAA
AA0AAAAAAAAAAAANAAAAAQAiAAEABAAMAAAAqg8MAAAADQAAAAYAAAAJBAQIAACmDwwAAADwAAAA
1AHQAvADEAUPAATwEgUAAKIMCvAIAAAAIowAAAAKAACjAAvwVAAAAH8AAADvAYAA/K2XCoUAAgAA
AL8ABgAGAL8BAAARAMsBcMYAAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8A
eAAgADMAOAAAACMAIvHoAwAA/wEAAEAAqYPcAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQA96Tmd2wAA
AP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9LS8NAFIX3gv9huIIbsRMjLSXttPhA6kY0sRTc3WZu
MiGZBzNjmv57Bxe6vJzLd8633k56YCP50Fkj4G6WASNTW9mZVsD+8+V2CSxENBIHa0jAmQJsN5cX
ayykPZmSxiq2LEFMKFCAitEVnIdakcYws45MyhrrNcZ0+pZLj6cE1wPPs2zBNXYmNSh09KSo7qtv
LeBdlfuseWvHXodqvrv5cv3j0glxfTU9rIBFmuL/8/Ph8IH5X/iLepUC8vniPo1vduej72SJIZIX
kPySbTIFvvkBAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAA
AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAA
AAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAPek5ndsAAAD9AAAADwAAAAAA
AAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA8DAAAAAAAAEPAIAAAA
QwgLAp4F8AgPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBAQAAAAAAAAAAAAADgABAAEAAAAA
AA0wDwAN8GoAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFJlY292ZXIgYWN0aW9uAAChDxgAAAAPAAAA
AAAAAAAADwAAAAEAIgABAAQADAAAAKoPDAAAAA8AAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALw
AxAFDwAE8JsEAABCAQrwCAAAACOMAACACgAA0wAL8F4AAAB/AAAA7wGFAAIAAACHAAEAAAC/AAQA
BAB/AQAAAQC/AQAAEQDAAQIAAAjLAThjAADRAQEAAAD/ARgAGAA/AwgACACAwxAAAAC/AwAAAgBM
AGkAbgBlACAAMwA5AAAAEwAi8dkDAACpg9MDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMA
AABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK
9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXT
LA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurh
tLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl
/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAA
CwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseO
kvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut
5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo
/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAHAT0D/SAAAA
8AAAAA8AAABkcnMvZG93bnJldi54bWxEjz1PwzAQhnck/oN1SCyIOimkglC3QnyoHVhaGDoe8TWJ
iM/BPpL03+MBifHV+6VnuZ5cpwYKsfVsIJ9loIgrb1uuDXy8v17fgYqCbLHzTAZOFGG9Oj9bYmn9
yDsa9lKrNMKxRAONSF9qHauGHMaZ74mTd/TBoSQZam0DjmncdXqeZQvtsOX00GBPTw1VX/sfZyDk
b8NtzsXBv3h5zscNHb6LK2MuL6bHB1BCk/yH/9pba2BeLG7uQR03p8/Q2h1GoWAgISXABAd69QsA
AP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8B
AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBwE9A/0gAAAPAAAAAPAAAAAAAAAAAAAAAAAAcC
AABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABgMAAAAAAAAQ8AgAAAAiBsYLxgsICg8A
EfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAAQAAEAAQAAAAAADTAPAATwmwQA
AEIBCvAIAAAAJIwAAIAKAADTAAvwXgAAAH8AAADvAYUAAgAAAIcAAQAAAL8ABAAEAH8BAAABAL8B
AAARAMABAgAACMsBOGMAANABAQAAAP8BGAAYAD8DCAAIAIDDEAAAAL8DAAACAEwAaQBuAGUAIAA0
ADAAAAATACLx2QMAAKmD0wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50
X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/
f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0
o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBl
U72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94Z
KrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMv
LnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj
0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vy
m0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQn
M1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEArQcm99IAAADwAAAADwAAAGRy
cy9kb3ducmV2LnhtbESPwU7DMAyG70i8Q2QkLoilDJhYWTYBEhq7sXYPYBqvrUicKglbt6fHBySO
tv//s77FavROHSimPrCBu0kBirgJtufWwK5+v30ClTKyRReYDJwowWp5ebHA0oYjb+lQ5VYJhFOJ
Brqch1Lr1HTkMU3CQCy3fYges4yx1TbiUeDe6WlRzLTHnuVDhwO9ddR8Vz/eQDrHzc1ru652uq4H
d+/m9HmeG3N9Nb48g8o05v/wX/vDGpg+zh5EYL8+fcXebjFligZkI4IiB3r5CwAA//8DAFBLAQIt
ABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAK0HJvfSAAAA8AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3du
cmV2LnhtbFBLBQYAAAAAAwADALcAAAAGAwAAAAAAABDwCAAAACIGrg+uD3AIDwAR8CwAAAAPABQQ
JAAAAAEA8Q8cAAAAAAAABwBAAAAAAAAAAAAAABcAAQABAAAAAAANMA8ABPCVBAAAQgEK8AgAAAAl
jAAAgAoAAMMAC/BYAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAI
0QEBAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADQAMQAAABMAIvHZAwAAqYPT
AwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07D
MAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVag
iI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0O
B9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBX
WQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAA
AP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg
72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/H
tw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9
HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz
4y8AAAD//wMAUEsDBBQABgAIAAAAIQBwrIJI0gAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9B
S8QwFITvgv8hPMGbm+6iRepmlyKsiuihqwePz+Y1DTYvJYm7rb/eCMIeh5n5hllvJzeIA4VoPStY
LgoQxK3Xlo2C97fd1S2ImJA1Dp5JwUwRtpvzszVW2h+5ocM+GZEhHCtU0Kc0VlLGtieHceFH4ux1
PjhMWQYjdcBjhrtBroqilA4t54UeR7rvqf3afzsFxUNnTL0r5xf7YX5C3ejZPr8qdXkx1XcgEk3p
FP5vP2kFq5vyegmie5w/g9UNxkQh0+DvYD4HcvMLAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAcKyCSNIAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAYDAAAAAAAAEPAIAAAAUwnyCPIICAoPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAH
AEAAAAAAAAAAAAAAHAABAAEAAAAAAA0wDwAE8BcFAACiDArwCAAAACaMAAAACgAA0wAL8GYAAAB/
AAAA7wGAAIy5lwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDGAAD/AQAA
GAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0ADIAAAAjACLx6AMAAP8BAABA
AKmD3AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8
kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3
cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx
0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487
MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9P
bL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAM
BuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKe
LVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83
E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzg
OODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEALAlj79sAAAD9AAAADwAAAGRycy9kb3ducmV2Lnht
bESPy07DMBRE90j8g3WR2CDqYLUFhboVQiBYUdqw6c7EN3FofB1skwdfj8UClqMZndFZbUbbsh59
aBxJuJplwJBKpxuqJbwVj5c3wEJUpFXrCCVMGGCzPj1ZqVy7gXbY72PNEoRCriSYGLuc81AatCrM
XIeUusp5q2KKvubaqyHBbctFli25VQ2lB6M6vDdYHvdfVkL1Xbh+3r+Yj2I7PYjPxWsnLgYpz8/G
u1tgEcf4Pz4eyFwf/spf1LOWIBbLuQBWPU3vvtE7FSJ6Cckv2SZT4OsfAAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhACwJY+/bAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAPAwAAAAAAABDwCAAAAAUHqwzoDWUHDwAR8CwAAAAPABQQJAAA
AAEA8Q8cAAAAAAAABwQAAAAAAAAAAAAAABoAAQABAAAAAAANMA8ADfBdAAAAAACfDwQAAAAEAAAA
AACoDwMAAAAjR1AAAKEPFgAAAAQAAAAAAAAAAAAEAAAAAAAiAAQACgAAAKoPDAAAAAQAAAAGAAAA
CQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CgFAACiDArwCAAAACeMAAAACgAA0wAL8GYAAAB/
AAAA7wGAAMjDlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDGAAD/AQAA
GAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0ADMAAAAjACLx6AMAAP8BAABA
AKmD3AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8
kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3
cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx
0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487
MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9P
bL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAM
BuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKe
LVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83
E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzg
OODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAHvQw7dsAAAD9AAAADwAAAGRycy9kb3ducmV2Lnht
bESPXUvDMBiF7wX/Q3gFb2RLrevQumyIKDoQ51Z/wGvztqk2SU1iP/z1Bi/08nAOz+FZbUbdsp6c
b6wRcD5PgJEprWxMLeC1uJ9dAvMBjcTWGhIwkYfN+vhohbm0g9lTfwg1ixDjcxSgQuhyzn2pSKOf
245M7CrrNIYYXc2lwyHCdcvTJFlyjY2JDwo7ulVUfhy+tIDqu7D9on9W78Vuuks/s5cuPRuEOD0Z
b66BBRrD//hpq65M9lf+oh6lgDRbLi6AVQ/Tm2vkHn0gJyD6RdtoCnz9AwAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAB70MO3bAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAPAwAAAAAAABDwCAAAAP8GZA6hD18HDwAR8CwAAAAPABQQJAAA
AAEA8Q8cAAAAAAAABwQAAAAAAAAAAAAAABgAAQABAAAAAAANMA8ADfBuAAAAAACfDwQAAAAEAAAA
AACoDwYAAABWTUV4aXQAAKEPFgAAAAcAAAAAAAAAAAAHAAAAAAAiAAQACgAAAKoPGgAAAAYAAAAH
AAAAAwAJBAQIAQAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwKQUAABIACvAIAAAA
KIwAAAAKAADjAAvwbgAAAH8AAADvAYAANM+XCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAE
AL8BAAARAMABDKQpAMsB0VYAAP8BCAAYAD8DAAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcA
bABlACAANAA0AAAAIwAi8eYDAAD/AQAAQACpg9oDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6
URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0E
EpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJN
AurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/
cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6
aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpW
C0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNC
nqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhADQW18HZ
AAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj0tLAzEUhfeC/yFcwZ3NWGrRsWlRwepC0D5E3V2T
Ow9MboYkzkz/vcGFLg/n8B2+xWp0VvQUYutZwfmkAEGsvWm5VrDf3Z9dgogJ2aD1TAoOFGG1PD5a
YGn8wBvqt6kWGcKxRAVNSl0pZdQNOYwT3xHnrvLBYcox1NIEHDLcWTktirl02HJ+aLCju4b01/bb
KVhr17/eGn6zxoSP9djb6v3ZKnV6Mt5cg0g0pv+xfrlyT8Nf+Yt6NAqmF/PZDET1cPgMrdlgTBQU
ZL9sm01BLn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAA
AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAA
AAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEANBbXwdkAAAD9AAAADwAAAAAA
AAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA0DAAAAAAAAEPAIAAAA
Qwi1B+QKUwkPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBEQAAAAAAAAAAAAAHQABAAEAAAAA
AA0wDwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAE1TUiB0ZWxlbWV0cnkAAKEPGAAAAA4AAAAA
AAAAAAAOAAAAAQAiAAEABAAOAAAAqg8MAAAADgAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvAD
EAUPAATwmwQAAEIBCvAIAAAAKYwAAMAKAADTAAvwXgAAAH8AAADvAYUAAgAAAIcAAQAAAL8ABAAE
AH8BAAABAL8BAAARAMABAQAACMsBOGMAANABAQAAAP8BGAAYAD8DCAAIAIDDEAAAAL8DAAACAEwA
aQBuAGUAIAA0ADUAAAATACLx2QMAAKmD0wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAA
AFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr2
9qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMs
DYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0
uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8
/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S
+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63l
E1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/
UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAOZNmmtIAAADw
AAAADwAAAGRycy9kb3ducmV2LnhtbESPT2vCMBjG7wO/Q3gHu820oiKdUUQYK7ts1l28vWte027N
m5Jktn775SB4fHj+8VtvR9uJC/nQOlaQTzMQxLXTLRsFX8fX5xWIEJE1do5JwZUCbDeThzUW2g18
oEsVjUgjHApU0MTYF1KGuiGLYep64uSdnbcYk/RGao9DGrednGXZUlpsOT002NO+ofq3+rMKTquP
064yJn+f/2RdmXP5GYdSqafHcfcCItIY7+Fbu9QKZovlfAHi/Hb99q0+YIjkFSSkBJjgQG7+AQAA
//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADmTZprSAAAA8AAAAA8AAAAAAAAAAAAAAAAABwIA
AGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAGAwAAAAAAABDwCAAAACIGmAiYCEMIDwAR
8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBAAAAAAAAAAAAAACEAAQABAAAAAAANMA8ABPCbBAAA
QgEK8AgAAAAqjAAAgAoAANMAC/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEA
ABEAwAECAAAIywGfbwAA0QEBAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADQA
NwAAABMAIvHZAwAAqYPTAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/
n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSj
lD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVT
vbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkq
uyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8u
cmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPR
yNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKb
TCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCcz
VQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAMjE1Z0gAAAPAAAAAPAAAAZHJz
L2Rvd25yZXYueG1sRI/fasIwFMbvB75DOMLuZqpsdXQeRQSZN6Ooe4Cz5tgGm6RLMtv69MvFYJcf
3z9+q81gWnFjH7SzCPNZBoJt5ZS2NcLnef/0CiJEsopaZxlh5ACb9eRhRYVyvT3y7RRrkUZsKAih
ibErpAxVw4bCzHVsk3dx3lBM0tdSeerTuGnlIstyaUjb9NBQx7uGq+vpxyBsd3lvlsbcD9f5/SPf
6/K7HEvEx+mwfQMReYj/4b/2QSEsXvLnJYjL+/jltTpSiOwRElICTHAg178AAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEADIxNWdIAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAYDAAAAAAAAEPAIAAAAJQkeDh4OCAoPABHwLAAAAA8AFBAk
AAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAAFAABAAEAAAAAAA0wDwAE8JwEAABCAQrwCAAAACuM
AADACgAA0wAL8F4AAAB/AAAA7wGFAAIAAACHAAEAAAC/AAQABAB/AQAAAQC/AQAAEQDAAQEAAAjL
AThjAADRAQEAAAD/ARgAGAA/AwgACACAwxAAAAC/AwAAAgBMAGkAbgBlACAANAA4AAAAEwAi8doD
AACpg9QDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1s
fJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8
N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmX
cdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMieP
OzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWP
T2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMw
DAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxi
ni1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkv
NxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc
4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAMP/C4bTAAAA8AAAAA8AAABkcnMvZG93bnJldi54
bWxEj01LAzEQhu+C/yGM4EVsYtGlrE1LEaQevPTD+7iZ3Y0mkyWJ7W5/vTkIHl/mnWfmWa5H78SJ
YrKBNTzMFAjiJhjLnYbj4fV+ASJlZIMuMGmYKMF6dX21xNqEM+/otM+dKBBONWrocx5qKVPTk8c0
CwNxmbUheswlxk6aiOcC907OlaqkR8vlQo8DvfTUfO9/vIZLe1HxeKfYbReTHd83H9XX4LS+vRk3
zyAyjfm//Lf9ZjTMn6rH8m+7nT6jNTtMmaKGolQEixzI1S8AAAD//wMAUEsBAi0AFAAGAAgAAAAh
ANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAU
AAYACAAAACEAw/8LhtMAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsF
BgAAAAADAAMAtwAAAAcDAAAAAAAAEPAIAAAAvgpnBdIGvgoPABHwLAAAAA8AFBAkAAAAAQDxDxwA
AAAAAAAHBEAAAAAAAAAAAAAACgABAAEAAAAAAA0wDwAE8BUFAACiDArwCAAAACyMAAAACgAA0wAL
8GYAAAB/AAAA7wGAANjYlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDG
AAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0ADkAAAAjACLx5wMA
AP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAD8LNC9oAAAD9AAAADwAAAGRycy9kb3du
cmV2LnhtbESPy07DMBBF90j8gzVIbBB1iNqqhLoVQuWxKrThA4Z48oB4HGyTB1+PxQKWV/fqXJ31
djSt6Mn5xrKCq1kCgriwuuFKwWt+f7kC4QOyxtYyKZjIw3ZzerLGTNuBD9QfQyUihH2GCuoQukxK
X9Rk0M9sRxy70jqDIUZXSe1wiHDTyjRJltJgw/Ghxo7uaio+jl9GQfmd237e7+v3/HnapZ+Lly69
GJQ6Pxtvb0AEGsP/eLfiB+P/yl/Uk1aQLpbzaxDl4/TmGn1AH8gpiH7RNpqC3PwAAAD//wMAUEsB
Ai0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz
XS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMv
LnJlbHNQSwECLQAUAAYACAAAACEAD8LNC9oAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rv
d25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAGgdQCI0JegcPABHwLAAAAA8A
FBAkAAAAAQDxDxwAAAAAAAAHBAAAAAAAAAAAAAAAIgABAAEAAAAAAA0wDwAN8FwAAAAAAJ8PBAAA
AAQAAAAAAKgPAgAAAEhDAAChDxYAAAADAAAAAAAAAAAAAwAAAAAAIgAEAAoAAACqDwwAAAADAAAA
BgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAqBQAAEgAK8AgAAAAtjAAAAAoAAOMAC/Bu
AAAAfwAAAO8BgACQ4pcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAgQEEAAAIvwEQABAA
wAEBAAAI/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA1ADAAAAAj
ACLx5wMAAP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50
X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/
f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0
o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBl
U72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94Z
KrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMv
LnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj
0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vy
m0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQn
M1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAeHdkx9oAAAD9AAAADwAAAGRy
cy9kb3ducmV2LnhtbESPXUvDQBBF3wX/wzKCL2I3raRI7LaIED8KBZOWPo/ZabKa3Q27Y5v+excf
9PHOHc7lLFaj7cWRQjTeKZhOMhDkGq+NaxXstuXtPYjI6DT23pGCM0VYLS8vFlhof3IVHWtuRYK4
WKCCjnkopIxNRxbjxA/kUnfwwSKnGFqpA54S3PZylmVzadG4tNDhQE8dNV/1t1UwW988r7lsy7vp
uC8NVvnu831Q6vpqfHwAwTTy//Mbb+rIf+Uv6lUnSD7Pk83h5fwRjK4wMgUF6ZJskynI5Q8AAAD/
/wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50
X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAA
X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAeHdkx9oAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAEgVTD94SIwYPABHw
LAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAAEgABAAEAAAAAAA0wDwAN8GkAAAAA
AJ8PBAAAAAQAAAAAAKgPDQAAAEhWTSBHdWVzdCBNQ0UAAKEPGAAAAA4AAAAAAAAAAAAOAAAAAQAi
AAEABAAOAAAAqg8MAAAADgAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwCQEAAKIM
CvAIAAAALowAAAAKAADjAAvwbAAAAH8AAADvAYAAQO2XCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA
AL8ABAAEAL8BAAARAMABAQAACMsB0VYAAP8BCAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQA
IABCAG8AeAAgADUANAAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAAALDX4N+Q9LDg8ADfBfAAAAAACf
DwQAAAAEAAAAAACoDwMAAABDUFUAAKEPGAAAAAQAAAAAAAAAAAAEAAAAAQAiAAEABAAOAAAAqg8M
AAAABAAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwDwEAAKIMCvAIAAAAMIwAAAAK
AADTAAvwZgAAAH8AAADvAYAAVAGaCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABgAGAL8BAAAR
AMsBcMYAAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADUANgAAABMA
IvEGAAAA/wEAAEAAAAAQ8AgAAAAVCAwTNRSvCA8ADfBrAAAAAACfDwQAAAAEAAAAAACoDwMAAABY
ZW4AAKEPFgAAAAQAAAAAAAAAAAAEAAAAAAAiAAQAEAAAAKoPGgAAAAMAAAAHAAAAAwAJBAQIAQAA
AAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwtAAAADIACvAIAAAAMYwAAAAKAADTAAvw
TgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8ABAAPAL8BDAAeAMABAgAA
CM4BBgAAAP8BDgAOAD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCC
fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAACvBy8LSRGBCQ8ABPD+AAAAogwK
8AgAAAAyjAAAAAoAAKMAC/A8AAAAgADAA5oKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAA8A
vwEMAB4A/wEGAA4APwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/
BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAACkMtA8GErQMDwAN8FQAAAAAAJ8P
BAAAAAQAAAAAAKgPBAAAAE1DRSMAAKEPIAAAAAUAAAAAABA4CgAAAAAAWgAyAAcABQAAAAAAIgAE
ABAAAACqDwwAAAAFAAAABgAAAAkEBAgPAATwCwEAAKIMCvAIAAAAM4wAAAAKAACjAAvwPAAAAIAA
KAqaCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABgAPAL8BDAAeAP8BBgAOAD8CAAADAH8DAAAP
AJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4A
fwYGAA4AAAAQ8AgAAADUB+wMxRBNCA8ADfBhAAAAAACfDwQAAAAEAAAAAACoDwsAAABXZSBhcmUg
aGVyZQAAoQ8mAAAADAAAAAAAEDgKAAAAAABaADIABwAMAAAAAgAmAAIABAAOAAAAAAIAAKoPDAAA
AAwAAAAGAAAACQQECA8ABPAgAQAAogwK8AgAAAA0jAAAAAoAAMMAC/BuAAAAfwABAO8BgACIDpoK
gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMA
AAIARABhAHQAZQAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQ
DwAN8IIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAm
AAEAAwAIALKysv4AAPcPCAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAA
CQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CwBAACiDArwCAAAADWMAAAACgAAwwAL8H4AAAB/
AAEA7wGAAHQWmgqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAA
CACAwzYAAAC/AwAAAgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABk
AGUAcgAgADQAAAAAABDwCAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA
AAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAA
AAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwSAAAABIA
CvAIAAAAAYwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI
AAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgT
L0UAAA8AihMnRQAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLEwdFAAAAAOsuCAAAAGTtyAHg
KCbcAAAAKwQAAABf7xTSHwBE8dM/AAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAPfYCf//
//8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAAHwBE8Y4/AAAAACfxIAAAAAAAAAAAAAAAAQAAAAAA
AAAAAAAAAJUTAP////8YAAAADwA98Q0AAABAAULxBQAAAAEEAAAAAABB8RQAAAABAAAAAQAAAAAA
AAAAAAAAAwAAAD8AJfEsAAAAAAAo8RAAAAABAAAACQAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAA
AAEAAABPACXxLAAAAAAAKPEQAAAAAQAAAAoAAAAAAAAAAAAAAA8APPEMAAAAAAABKwQAAAABAAAA
HwBE8SQKAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPHMCQAAAAAn8SAAAAAAAAAAAAAAAAAA
AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x
NAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMA
AAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC
8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+
8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAA
APsqFAAAAAAAAAABAAAAD4wAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA
AAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAA
AEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULx
BQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAA
AAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAAB
AAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAA
AAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAA
AA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAABWMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAA
AAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAB
AAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAA
AAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgA
AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAA
AAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAA
AAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBp
AGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAWjAAA//////////8fACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA
AAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEA
AAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA
AAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEA
AAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFv
AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2
AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAABIwAAP//////////
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAA
AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAA
oABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAA
AAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAA
ABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBs
AGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0
AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAAOM
AAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAA
AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAECAAAAkABC
8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA
AAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkA
AAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUA
AAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkA
bABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAABeMAAD/
/////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8b0LAAAAACfxIAAAAAAA
AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAA
AAAAAAAAAAAA/////x8ARPFlCwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA
AQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/Eg
AAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQ
AELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgA
AAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAA
AAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAA
A3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAA
AABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQA
AAAAAAAAAQAAABuMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE
8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULx
BQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAA
ACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAA
AAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YA
aQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC
8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAA
AAAAAQAAABqMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQB
AAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAA
AAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjx
EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAA
AAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBz
AGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMA
AAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAA
AQAAACuMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAA
ACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAEC
AAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8A
JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAA
AAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELx
EQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7x
KwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA
+yoUAAAAAAAAAAEAAAAhjAAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAA
AB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAA
QAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAADABQvEF
AAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAA
AAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEA
AAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAA
AAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAA
DwA88RwAAAAAAPsqFAAAAAAAAAABAAAAIIwAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAA
AAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEA
AAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAA
AQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAA
AAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAA
AAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAA
BAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkA
bABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAB+MAAD//////////x8AJfEYAAAAAAAo
8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAA
AAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAA
AACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA
AAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAA
AAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8A
AAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYA
aQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAijAAA//////////8f
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPFJDQAAAAAn8SAAAAAAAAAAAAAAAAAA
AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AP////8fAETx8QwAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x
AAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAA
AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUAAAAB
AQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3x
AAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrx
bwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4A
dgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAABKMAAD/////////
/x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAA
AAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAA
AKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA
AAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAA
AA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAA
AAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBp
AHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACOMAAD//////////x8A
JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAA
AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAA
QvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAA
AAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZ
AAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABl
AAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5
AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAYjAAA
//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAA
AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEF
AAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAA
AAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBp
AHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELx
IwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAA
AAABAAAALYwAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEA
AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAA
AQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAA
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAAD
AAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAA
QvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8A
PvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAA
AAD7KhQAAAAAAAAAAQAAABmMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA
AAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQA
AABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl
8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAA
AwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvER
AAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvEr
AAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7
KhQAAAAAAAAAAQAAACqMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA
HwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABA
AULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUA
AAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAA
AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAA
AAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAA
AAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAP
ADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAcjAAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAA
AAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA
AA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAAB
AQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAA
AAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAA
ADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAE
AAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBs
AGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAHYwAAP//////////HwAl8RgAAAAAACjx
EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxzAgAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA
AAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8XQI
AAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAA
AAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAA
AAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAA
AAEAAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgA
AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAA
AAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAA
AAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBp
AGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAkjAAA//////////8fACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA
AAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEA
AAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA
AAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEA
AAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFv
AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2
AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAJ4wAAP//////////
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAA
AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAA
oABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAA
AB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAA
DwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAA
AAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkA
cwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAEYwAAP//////////HwAl
8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAA
AwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC
8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA
AAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkA
AAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUA
AAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkA
bABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACaMAAD/
/////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8dIBAAAAACfxIAAAAAAA
AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUA
AAABIwAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEDAAAAMAFC8QUAAAABAQAAAB8AJfEYAAAAAAAo
8RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAp8QgAAAAAAAAAAACAQB8ARPEpAQAAAAAn8SAAAAAAAAAA
AAAAAAMAAAADAAAAAAAAAAAAAADoAwAAGQAAAA8APfEAAAAADwAr8fEAAAAAADTxDAAAAAAAAAA4
AAAAAAAAAA8AP/FeAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADaABpAGQAZABlAG4AAAAQAELxAwAA
AAMAAAAAQ/EEAAAA9AEAAAAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAQAELxAwAAAAMAAA8AKvFv
AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2
AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAGYwAAP//////////
HwBE8c0DAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPF1AwAAAAAn8SAAAAAAAAAAAAAAAAAA
AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x
NAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMA
AAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC
8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+
8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAA
APsqFAAAAAAAAAABAAAAJYwAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA
AAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAA
AEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULx
BQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAA
AAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAAB
AAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAA
AAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAA
AA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACiMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAA
AAAAAAAAAAAAAAAAHwBE8WYFAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAB
AAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPEOBQAAAAAn8SAA
AAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAA
AAAAAAAAAAAAAAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAA
AAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAA
QvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAA
AAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAA
AAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAA
AAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5
AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAADIwAAP//////////HwAl8RgAAAAAACjxEAAAAAAA
AAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA
AAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEF
AAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx
+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGg
AAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQ
AAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBi
AGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAB6MAAD//////////x8AJfEYAAAA
AAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAA
AAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAA
AQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA
AAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA9
8QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq
8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAu
AHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAUjAAA////////
//8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGXBQAAAAAn8SAAAAAAAAAAAAAA
AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA
AAAAAP////8fAETxPwUAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP
AD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAA
AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUA
AAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA
AAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAP
AD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAP
ACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABl
AC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACmMAAD/////
/////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAA
AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAAB
AQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAA
AAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAA
AAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBp
AGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAA
A3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEA
AAAsjAAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPHCAQAAAAAn
8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAA
AJAAQvEFAAAAASMAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAwAAADABQvEFAAAAAQEAAAAfACXx
GAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPEpAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAAD
AAAAAAAAAAAAAADoAwAAGQAAAA8APfEAAAAADwAr8fEAAAAAADTxDAAAAAAAAAA4AAAAAAAAAA8A
P/FeAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADaABpAGQAZABlAG4AAAAQAELxAwAAAAMAAAAAQ/EE
AAAA9AEAAAAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAQAELxAwAAAAMAAA8AKvFvAAAAAAAz8RAA
AAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIA
aQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAKIwAAP//////////HwBE8c0DAAAA
ACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPF1AwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA
AAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx
hAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEF
AAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAfACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAA
AAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBp
AHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELx
IwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAA
AAABAAAAE4wAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEA
AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAA
AQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAA
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAAD
AAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAA
QvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8A
PvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAA
AAD7KhQAAAAAAAAAAQAAAA6MAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA
AAAADwACKwgFAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAADjAAAAQABMAEACSsQAAAAAwAAAAEA
AAABAAAAAAAAAA8ACCswAAAAAAADKxAAAAABAAAAAAAAAASMAAABAAEwAQAJKxAAAAADAAAAAQAA
AAAAAAAAAAAADwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAADowAAAEAATABAAkrEAAAAAMAAAABAAAA
AQAAAAAAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAUjAAAAQABMAEACSsQAAAAAwAAAAEAAAAB
AAAAAAAAAA8ACCswAAAAAAADKxAAAAABAAAAAAAAABWMAAABAAEwAQAJKxAAAAADAAAAAQAAAAEA
AAAAAAAADwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAAFowAAAEAATABAAkrEAAAAAMAAAABAAAAAQAA
AAAAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAYjAAAAQABMAEACSsQAAAAAwAAAAEAAAABAAAA
AAAAAA8ACCswAAAAAAADKxAAAAABAAAAAAAAABmMAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAA
AAAADwAIKzAAAAAAAAMrEAAAAAEAAAABAAAAGYwAAAEAATABAAkrEAAAAAMAAAABAAAAAQAAAAAA
AAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAbjAAAAQABMAEACSsQAAAAAwAAAAEAAAABAAAAAAAA
AA8ACCswAAAAAAADKxAAAAABAAAAAAAAAByMAAABAAEwAQAJKxAAAAADAAAAAQAAAAAAAAAAAAAA
DwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAAHYwAAAEAATABAAkrEAAAAAMAAAABAAAAAAAAAAAAAAAP
AAgrMAAAAAAAAysQAAAAAQAAAAAAAAAejAAAAQABMAEACSsQAAAAAwAAAAEAAAAAAAAAAAAAAA8A
CCswAAAAAAADKxAAAAABAAAAAAAAAB+MAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwAI
KzAAAAAAAAMrEAAAAAEAAAAAAAAAIIwAAAEAATABAAkrEAAAAAMAAAABAAAAAQAAAAAAAAAPAAgr
MAAAAAAAAysQAAAAAQAAAAAAAAAhjAAAAQABMAEACSsQAAAAAwAAAAEAAAABAAAAAAAAAA8ACCsw
AAAAAAADKxAAAAABAAAAAAAAACKMAAABAAEwAQAJKxAAAAADAAAAAQAAAAAAAAAAAAAADwAIKzAA
AAAAAAMrEAAAAAEAAAAAAAAAJowAAAEAATABAAkrEAAAAAMAAAABAAAAAAAAAAAAAAAPAAgrMAAA
AAAAAysQAAAAAQAAAAAAAAAnjAAAAQABMAEACSsQAAAAAwAAAAEAAAAAAAAAAAAAAA8ACCswAAAA
AAADKxAAAAABAAAAAAAAACiMAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwAIKzAAAAAA
AAMrEAAAAAEAAAABAAAAKIwAAAEAATABAAkrEAAAAAMAAAABAAAAAQAAAAAAAAAPAAgrMAAAAAAA
AysQAAAAAQAAAAAAAAAsjAAAAQABMAEACSsQAAAAAwAAAAEAAAAAAAAAAAAAAA8ACCswAAAAAAAD
KxAAAAABAAAAAAAAAC2MAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwDuA8IJAAACAO8D
GAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAMMA8ADATZCAAADwAC8NEIAACgAQjwCAAAAAUAAAAF
aAAADwAD8GkIAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAGgAAAUA
AAAPAATwIAEAAKIMCvAIAAAAAmgAAAAKAADDAAvwbgAAAH8AAQDvAYAAxGqaCoEAAAAAAIIAAAAA
AIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0AGUA
IABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4PmBGqEA8ADfCCAAAAAACf
DwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+
AAD3DwgAAAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAA
APAAAADUAdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADaAAAAAoAAMMAC/B+AAAAfwABAO8BgAAEdJoK
gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMM2AAAAvwMA
AAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA0AAAA
AAAQ8AgAAABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAA
AAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAA
EQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BoBAAASAArwCAAAAARoAAAg
AgAAEwEL8H4AAAAEAAAAAAB/AAEA7wGAACyBmgqBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAA
AACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgAAACIAwAAAAC/AwAAAgBS
AGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR8BAAAAAAAMMLCAAAAP//
//8NAJoKDwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAEJhY2tncm91bmQAAKEPGgAAAAsAAAAA
AAAICgABAAcACwAAAAEAIAAAAAQAAACqDwwAAAALAAAABgAAAAkEBAgPAATwswQAABIACvAIAAAA
BWgAACACAAATAQvwfgAAAAQAAAAAAH8AAQDvAYAAZJ+aCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA
AIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDBAQAAD8DAAAIAIDDGAAAAIgDAAAAAL8D
AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAXAKZAOwVsA4PABHwEAAAAAAAwwsI
AAAA/////w4AmgoPAA3w7QMAAAAAnw8EAAAAAQAAAAAAqA9pAQAAWGVuIG1jZSBjb21wb25lbnRz
DVhlbiBNQ0UgSVNSDVhlbiBNQ0Ugc29mdGlycQ12TUNFDURvbTAgbWNlbG9nIGludGVyZmFjZQ0N
MyBtYWpvciBwb2ludHMgb2Ygdk1DRSBsb2dpYw1Ib3cgdG8gaW5qZWN0IE1DRQ1Ib3cgdG8gZW11
bGF0ZSBNU1JzDUhvdyB0byBsaXZlIG1pZ3JhdGUNDU1ham9yIGNvbnN0cmFpbnRzIG9mIGN1cnJl
bnQgdk1DRQ1Cb3VuZCB0byBob3N0DUhvc3QgaGV0ZXJvZ2VuZW91cyBicmVhayBtaWdyYXRpb24s
IGNhbm5vdCBjb250cm9sIHZpYSBjcHVpZA1Ob24tYXJjaCBpc3N1ZXMgb2YgTVNScyBlbXVsYXRp
b24NV2VpcmQgcGVyLWRvbWFpbiBNU1JzDVVubmF0dXJhbCBNQ0UgaW5qZWN0aW9uIHNlbWFudGlj
cwAAoQ/yAAAAEwAAAAAAABAKAFoABwA4AAAAAQAAEAoAWgAHAB0AAAAAAAAQCgBaAAcAOwAAAAEA
ABAKAFoABwAiAAAAAAAAEAoAWgAHAA4AAAABAAAQCgBaAAcAXwAAAAIAABAKAFoABwA4AAAAAQAA
EAoAWgAHABMAAAABACAAAAAEABwAAAAAACAABAAFAAAAAAAkAAQAAAAAAhcAAAAAACAABAAdAAAA
AQQgAAAEBAA6AAAAAAQgAAAEBAABAAAAAQQgAAEEBAAiAAAAAQggAAAIBAAOAAAAAAwgAAAMBABf
AAAAAAwgAAAMBAA4AAAAAAwgAAAMBAAAAKoPUgEAAAMAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQI
AwAAAAcAAAADAAkEBAgMAAAABgAAAAkEBAgDAAAABwAAAAMACQQECAkAAAAGAAAACQQECAMAAAAH
AAAAAwAJBAQIBQAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgEAAAABwAAAAMA
CQQECAYAAAAGAAAACQQECAYAAAAHAAAAAwAJBAQIHgAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgo
AAAABgAAAAkEBAgEAAAABwAAAAMACQQECDMAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIRgAAAAYA
AAAJBAQIBQAAAAcAAAADAAkEBAgUAAAABgAAAAkEBAgEAAAABwAAAAMACQQECBwAAAAGAAAACQQE
CAQAAAAHAAAAAwAJBAQIIwAAAAYAAAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2ADEAWABA8A
BPBIAAAAEgAK8AgAAAABaAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES
ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYA
qgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4I
AAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAA
AAAAAFQJ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gMbJAAAAgDvAxgA
AAAQAAAAAAAAAAAAAAAAAACABwEAAAcADDAPAAwEIiMAAA8AAvAaIwAA4AAI8AgAAAAZAAAAIAwA
AA8AA/CKIgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAA
DwAE8CABAACiDArwCAAAAAIMAAAACgAAwwAL8G4AAAB/AAEA7wGAAIiWmgqBAAAAAACCAAAAAACD
AAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAA
UABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXBC+D5gRqhAPAA3wggAAAAAAnw8E
AAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA
9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACmDwwAAADw
AAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAAwwAAAAKAADDAAvwfgAAAH8AAQDvAYAAZNaaCoEA
AAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDNgAAAL8DAAAC
AFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANAAAAAAA
EPAIAAAAXRC4Dr4PqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAA
AAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAAAAAAqg8aAAAAAQAAAAcAAAAAABEE
CQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPBNAQAAEgAK8AgAAAAEDAAAIAIA
ABMBC/B+AAAABAAAAAAAfwABAO8BgACw2JoKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAA
hwAAAAAAiAAAAAAAvwAEAAQAvwEAAAEA/wEAABEAAQMDBAAAPwMAAAgAgMMYAAAAvwMAAAIAUgBl
AGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADLAA4BaxVZAg8AEfAQAAAAAADDCwgAAAD/////
DQCaCg8ADfCHAAAAAACfDwQAAAAAAAAAAACoDxUAAABYZW4gdk1DRSBhcHByb2FjaCAoMSkAAKEP
GgAAABYAAAAAAAAICgABAAcAFgAAAAEAIAAAAAQAAACqDzQAAAADAAAABwAAAAMACQQECAEAAAAG
AAAACQQECAQAAAAHAAAAAwAJBAQIDgAAAAYAAAAJBAQIDwAE8OIJAAASAArwCAAAAAUMAAAgAgAA
AwEL8HgAAAAEAAAAAAB/AAEA7wGAABAAxAqBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAAAACH
AAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwQEAAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEA
bgBnAGwAZQAgADMAAAAAABDwCAAAAJkCXQBKDa0ODwAR8BAAAAAAAMMLCAAAAP////8OAJoKDwAN
8CIJAAAAAJ8PBAAAAAEAAAAAAKAPCgYAAFMAZQBwAGEAcgBhAHQAZQAgAGcAdQBlAHMAdAAgAE0A
QwBFACAAdwAvACAAaABvAHMAdAAgAE0AQwBFAA0AVQBuAGwAaQBrAGUAIABjAHAAdQBpAGQADQB2
AE0AQwBFACAAYwBhAG4AIABmAGEAawBlACAAYwBhAHAAYQBiAGkAbABpAHQAaQBlAHMAIAB0AG8A
IABnAHUAZQBzAHQAIABpAGYAIABuAGUAZQBkAA0AdgBNAEMARQAgAGMAYQBuACAAbQBhAHMAawAg
AGMAYQBwAGEAYgBpAGwAaQB0AGkAZQBzACAAaQBmACAAdQBuAG4AZQBjAGUAcwBzAGEAcgB5AA0A
RQBtAHUAbABhAHQAZQAgAGEAIAB3AGUAbABsAC0AZABlAGYAaQBuAGUAZAAgAE0AQwBFACAAaQBu
AHQAZQByAGYAYQBjAGUAIAB0AG8AIABnAHUAZQBzAHQALAAgAGMAbwBuAHMAaQBzAHQAcwAgAG8A
ZgANAEkAbgBpAHQAJgBwAHIAbwBiAGUAIABpAG4AdABlAHIAYQBjAGUADQBCAGEAcwBpAGMAYQBs
AGwAeQAgAGYAbwByACAAZwB1AGUAcwB0ACAAaQBuAGkAdAAgACYAIABwAHIAbwBiAGUADQBkAGkA
cwBhAGIAbABlACAAUwBSAEEATwAvAFMAUgBBAFIALQB1AG4AcgBlAGwAYQB0AGUAZAAgAGMAYQBw
AGEAYgBpAGwAaQB0AGkAZQBzAA0AUABvAGkAbgB0AGwAZQBzAHMAIAB0AG8AIABpAG4AagBlAGMA
dAAgAHQAaABvAHMAZQAgAGUAcgByAG8AcgAgAHQAbwAgAGcAdQBlAHMAdAANAGUAbgBhAGIAbABl
ACAAUwBSAEEATwAvAFMAUgBBAFIALQByAGUAbABhAHQAZQBkACAAYwBhAHAAYQBiAGkAbABpAHQA
aQBlAHMADQBOAG8AIABtAGEAdAB0AGUAcgAgAGgAbwBzAHQAIABzAHUAcABwAG8AcgB0ACAAbwBy
ACAAbgBvAHQADQBkAGkAcwBhAGIAbABlACAATQBDAEcAXwBDAFQATAAsACAAcwB0AGkAYwBrACAA
YQBsAGwAIAAxABkgcwAgAGYAbwByACAATQBDAGkAXwBDAFQATAANAEcAZQBuAGUAcgBhAGwAbAB5
ACAAZgBvAHIAIABoAC8AdwAgAGQAZQBiAHUAZwAgAHAAdQByAHAAbwBzAGUADQBBAHYAbwBpAGQA
IABtAG8AZABlAGwAIABzAHAAZQBjAGkAZgBpAGMAIABpAHMAcwB1AGUADQBFAHIAcgBvAHIALQBp
AG4AZgBvACAAaQBuAHQAZQByAGYAYQBjAGUADQBPAG4AbAB5ACAAbQBlAGEAbgBpAG4AZwBmAHUA
bAAgAHcAaABlAG4AIAByAGUAYQBsACAAZQByAHIAbwByACAAZwBlAG4AZQByAGEAdABlAGQADQBG
AGkAbAB0AGUAcgAgACYAIABkAGUAbABpAHYAZQByACAAdABvACAAZwB1AGUAcwB0ACAAbwBuACAA
ZABlAG0AYQBuAGQADQBMAGUAYQB2AGUAIABoAG8AcwB0ACAAZgBsAGUAeABpAGIAaQBsAGkAdAB5
AA0ADQBFAHIAcgBvAHIAIABpAG4AagBlAGMAdAAgAHQAbwAgAGcAdQBlAHMAdAANAEEAIAB0AHIA
YQBuAHMAZgBlAHIAIABsAGEAeQBlAHIADQBGAGkAbAB0AGUAcgAgAG4AbwBuAC0AUwBSAEEATwAv
AFMAUgBBAFIAIABiAGEAbgBrAHMADQBUAHIAYQBuAHMAbABhAHQAZQAgAGgAbwBzAHQAIABhAGQA
ZAByAGUAcwBzACAAdABvACAAZwB1AGUAcwB0ACAAYQBkAGQAcgBlAHMAcwANAEQAZQBsAGkAdgBl
AHIADQBFAHYAYQBsAHUAYQB0AGUAIABhAG4AZAAgAGQAZQBsAGkAdgBlAHIAIAB0AGgAZQAgAG0A
bwBzAHQAIABzAGUAdgBlAHIAZQAgAGUAcgByAG8AcgAAAKEPFgIAAB8AAAAAAAAQCgBQAAcADQAA
AAEAABAKAFAABwBWAAAAAgAAEAoAUAAHADsAAAABAAAQCgBQAAcAFAAAAAIAABAKAFAABwBKAAAA
AwAAEAoAUAAHACkAAAAEAAAQCgBQAAcAJgAAAAMAABAKAFAABwAeAAAABAAAEAoAUAAHACsAAAAD
AAAQCgBQAAcAOwAAAAQAABAKAFAABwAVAAAAAgAAEAoAUAAHAE4AAAADAAAQCgBQAAcAFwAAAAEA
ABAKAFAABwABAAAAAQABEAoACgBQAAcAFgAAAAAAABAKAFAABwARAAAAAQAAEAoAUAAHAEsAAAAC
AAAQCgBQAAcAKwAAAAMAABAKAFAABwAfAAAAAQAiAAAABAASAA0AAAAABCIAAAQEABAAVgAAAAAE
IgAABAQADgA7AAAAAAgiAAAIBAAQABQAAAAADCIAAAwEAA4ASgAAAAAQIgAAEAQADAApAAAAABAi
AAAQBAAKACYAAAAAFCIAABQEAAwAHgAAAAAUIgAAFAQACgArAAAAABgiAAAYBAAMADsAAAAAHCIA
ABwEAAoAFQAAAAAgIgAAIAQADgBOAAAAACQiAAAkBAAMABcAAAAAKCIAACgEABAAAQAAAAAsIgAA
LAQAEAAWAAAAASwiAAAsBAASABEAAAAAMCIAADAEABAASwAAAAA0IgAANAQADgArAAAAADgiAAA4
BAAMAAAAqg/CAAAAJgAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgEAAAABwAA
AAMACQQECCgAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIYQAAAAYAAAAJBAQICgAAAAcAAAADAAkE
BAgBAAAABgAAAAkEBAgIAAAABwAAAAMACQQECNsAAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIDwAA
AAYAAAAJBAQIAwAAAAcAAAADAAkEBAhCAQAABgAAAAkEBAgAAKYPFAAAAPAeAADUASAB0AJAAvAD
YAMQBYAEDwAE8P8AAACiDArwCAAAAAYMAAAACgAAswAL8FgAAAB/AAAA7wGAAKwBxAq/AAYABgCB
AQEAAAi/ARAAEADAAQEAAAjLAXDGAAD/AQgAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0ACAA
QgBvAHgAIAA2AAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAK4C2Q5/FKIDDwAN8GkAAAAAAJ8PBAAA
AAQAAAAAAKgPCQAAAEd1ZXN0IE1DRQAAoQ8cAAAACgAAAAAAACAAADIACgAAAAAAJgAEABAAAAAA
AgAAqg8MAAAACgAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATw/gAAAKIMCvAIAAAA
BwwAAAAKAACzAAvwWAAAAH8AAADvAYAAJO6aCr8ABgAGAIEBAQAACL8BEAAQAMABAQAACMsBcMYA
AP8BCAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADcAAAATACLxBgAAAP8B
AABAAAAAEPAIAAAAGw2iDr4UDw4PAA3waAAAAAAAnw8EAAAABAAAAAAAqA8IAAAASG9zdCBNQ0UA
AKEPHAAAAAkAAAAAAAAgAAAyAAkAAAAAACYABAAQAAAAAAIAAKoPDAAAAAkAAAAGAAAACQQECAAA
pg8MAAAA8AAAANQB0ALwAxAFDwAE8PgAAAASAArwCAAAAAgMAAAACgAA0wAL8GgAAAB/AAAA7wGA
ANTumgqFAAIAAACHAAEAAAC/AAQABACBAQEAAAi/ARAAEADAAQEAAAjLAXDGAAD/AQgAGAA/AwAA
CACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADEAMwAAABMAIvEGAAAA/wEAAEAAAAAQ
8AgAAABMB0UNcxEtCw8ADfBSAAAAAACfDwQAAAAEAAAAAAChDxQAAAABAAAAAAAAAAAAAQAAAAAA
IAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCGAAAAQgEK
8AgAAAAKDAAAgAoAANMAC/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEA
wAEAAAAIywFqSgAAzgEGAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADEANQAA
AAAAEPAIAAAA+Ak2DYER+AkPAATwhgAAAEIBCvAIAAAACwwAAMAKAADTAAvwXgAAAH8AAADvAYUA
AgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAgAACMsBakoAANEBAQAAAP8BGAAYAD8DCAAI
AIDDEAAAAL8DAAACAEwAaQBuAGUAIAAxADYAAAAAABDwCAAAAMMD2BHvEegMDwAE8BABAACiDArw
CAAAAAwMAAAACgAAkwAL8E4AAAB/AAAA7wGAADxB2Am/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/
AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADkAAAATACLxBgAAAP8BAABAAAAA
EPAIAAAAgQemDdEQLggPAA3whAAAAAAAnw8EAAAABAAAAAAAqA8KAAAAR3Vlc3QgTVNScwAAoQ8c
AAAACwAAAAAAACAAADIACwAAAAAAJgAEAAwAAAAAAgAAqg8mAAAABgAAAAYAAAAJBAQIBAAAAAcA
AAADAAkEBAgBAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAPAQAAogwK8AgAAAAN
DAAAAAoAAJMAC/BOAAAAfwAAAO8BgACIQMQKvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMAAAgA
gMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMgAwAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAA
AD4KlQ2/EOsKDwAN8IMAAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEhvc3QgTVNScwAAoQ8cAAAACgAA
AAAAACAAADIACgAAAAAAJgAEAAwAAAAAAgAAqg8mAAAABQAAAAYAAAAJBAQIBAAAAAcAAAADAAkE
BAgBAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPD6AAAAogwK8AgAAAAODAAAAAoA
AJMAC/BOAAAAfwAAAO8BgACcTMQKvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMAAAgAgMMYAAAA
vwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMgAxAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAPEIRw1N
EZ4JDwAN8G4AAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFRyYW5zZmVyIGxheWVyAAChDxwAAAAPAAAA
AAAAIAAAMgAPAAAAAAAmAAQADAAAAAACAACqDwwAAAAPAAAABgAAAAkEBAgAAKYPDAAAAPAAAADU
AdAC8AMQBQ8ABPDoAQAAAgAK8AgAAAAPDAAAwAoAAFMCC/CaAQAABAAAAAAAfwAAAO8BhQACAAAA
hwABAAAAiAAAAAAAvwAEAAQAQAEAAAAAQQEAAAAAQgFgVAAAQwHCSAAARAEEAAAARcFOAAAARsEa
AAAAUcEeAAAAUsESAAAAVcEAAAAAVsEAAAAAV8EWAAAAWAECAAAAfwEJABkAvwEAABEAwAECAAAI
wQEAAAEAxAEAAAAAywHUlAAAzQEAAAAAzgEGAAAA0QEBAAAA1AEBAAAA1QEBAAAA1gECAAAA1wEC
AAAA/wEYABgABAMBAAAAPwMAAAgAgMMOAAAAvwMAAAIACQAMAAgAuSoAAP////+GRAAAJg8AAGBU
AADVKgAAYFQAAMJIAAC5KgAA/////4ZEAAAmDwAAYFQAANUqAABgVAAAwkgAAAAAAADCSAAACgAM
AAIAAEAAqgEgAIAAQACrASABAAFgAIADAAQACABmGgMAAAAAAOUgBgArswsAAAAAACuzCwADAAQA
BAAAAAAAAAAAAAAAAAABAAQAEAAAAAAAAAAAAGBUAADCSAAAQQByAGMAIAAyADIAAABTACLxHgAA
ANkB/////9oB/////9sBAAAAINzBAAAAAOEB/////wAAEPAIAAAAQwu4Dq4P+wwPAATwhgAAAEIB
CvAIAAAAEAwAAAAKAADTAAvwXgAAAH8AAADvAYUAAgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAAR
AMABAgAACMsBakoAANEBAQAAAP8BGAAYAD8DCAAIAIDDEAAAAL8DAAACAEwAaQBuAGUAIAAyADMA
AAAAABDwCAAAAMwDOhFAEUAHDwAE8NwBAAACAArwCAAAABEMAABACgAAMwIL8I4BAAAEAAAAAAB/
AAAA7wGFAAIAAACHAAEAAACIAAAAAAC/AAQABABAAQAAAABBAQAAAABCAWBUAABDAWBUAABEAQQA
AABFwU4AAABGwRoAAABRwR4AAABSwRIAAABVwQAAAABWwQAAAABXwRYAAABYAQIAAAB/AQkAGQC/
AQAAEQDAAQIAAAjBAQAAAQDEAQAAAADLAdSUAADNAQAAAADQAQEAAADSAQEAAADTAQEAAADWAQIA
AAD/ARgAGAAEAwEAAAA/AwAACACAww4AAAC/AwAAAgAJAAwACAD/////AAAAAJkuAAAAAAAAYFQA
AMYlAABgVAAAYFQAAP////8AAAAAmS4AAAAAAABgVAAAxiUAAGBUAABgVAAAAAAAAGBUAAAKAAwA
AgAAQACqASAAgABAAKsBIAEAAWAAgAMABAAIAAAAAAAAAAAAaEMEAGIWDAAAAAAAYhYMAAMABAAE
AAAAAAAAAAAAAAAAAAEABAAQAAAAAAAAAAAAYFQAAGBUAABBAHIAYwAgADIANQAAAFMAIvEeAAAA
2QH/////2gH/////2wEAAAAg3MEAAAAA4QH/////AAAQ8AgAAADPA5UOjg8+Bw8ABPAOAQAAogwK
8AgAAAATDAAAAAoAAJMAC/BOAAAAfwAAAO8BgABwU8QKvwAGAAYAvwEAABEAywFwxgAA/wEAABgA
PwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMgA4AAAAEwAi8QYAAAD/AQAAQAAA
ABDwCAAAANkDpxGYEzMFDwAN8IIAAAAAAJ8PBAAAAAQAAAAAAKgPFAAAAHB2L2h2bSBNQ0UgaW5q
ZWN0aW9uAAChDxwAAAAVAAAAAAAAIAAAMgAVAAAAAAAmAAQACgAAAAACAACqDxoAAAAGAAAABwAA
AAMACQQECA8AAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8AQBAACiDArwCAAAABQM
AAAACgAAkwAL8E4AAAB/AAAA7wGAAARexAq/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/AwAACACA
wxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAyADkAAAATACLxBgAAAP8BAABAAAAAEPAIAAAA
HASND5URFgUPAA3weAAAAAAAnw8EAAAABAAAAAAAqA8KAAAAVk1FeGl0IEdQIwAAoQ8cAAAACwAA
AAAAACAAADIACwAAAAAAJgAEAAoAAAAAAgAAqg8aAAAABgAAAAcAAAADAAkEBAgFAAAABgAAAAkE
BAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAeAQAAogwK8AgAAAAWDAAAAAoAALMAC/BYAAAAfwAA
AO8BgABEaMQKvwAGAAYAgQEBAAAIvwEQABAAwAEBAAAIywFwxgAA/wEIABgAPwMAAAgAgMMWAAAA
vwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAABTB5gS3xWT
CA8ADfCIAAAAAACfDwQAAAAEAAAAAACoDw4AAABDQVAgJiBDVEwgTVNScwAAoQ8cAAAADwAAAAAA
ACAAADIADwAAAAAAJgAEAAwADKQp/gAAqg8mAAAACgAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgB
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPARAQAAogwK8AgAAAAZDAAAAAoAANMA
C/BOAAAAgACUcsQKvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywFwxgAA/wEGAA4AAQIC
AAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCC
AIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAD8KrhOwFYYLDwAN8FUAAAAA
AJ8PBAAAAAQAAAAAAKgPAQAAAHgAAKEPJAAAAAIAAAAAADAgAAAAAAAAAAAyAAIAAAABACYAAQAE
ABwADKQp/gAAqg8MAAAAAgAAAAYAAAAJBAQIDwAE8CIBAACiDArwCAAAABoMAAAACgAA0wAL8E4A
AACAABR2xAq/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAjLAXDGAAD/AQYADgABAgIAAAg/
AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8F
BgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAowWLDQoR6QYPAA3wZgAAAAAAnw8E
AAAABAAAAAAAqA8UAAAARXJyb3ItaW5mbyBpbnRlcmZhY2UAAKEPIgAAABUAAAAAADAgAAAAAAAA
AAAyABUAAAAAACYABAAOAAAAAAIAAKoPDAAAABUAAAAGAAAACQQECA8ABPAwAQAAogwK8AgAAAAb
DAAAAAoAANMAC/BOAAAAgAB0esQKvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywFwxgAA
/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/
AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKwFHBIgFvIG
DwAN8HQAAAAAAJ8PBAAAAAQAAAAAAKgPFAAAAEluaXQmcHJvYmUgaW50ZXJmYWNlAAChDyIAAAAV
AAAAAAAwIAAAAAAAAAAAMgAVAAAAAAAmAAQADgAMpCn+AACqDxoAAAAKAAAABwAAAAMACQQECAsA
AAAGAAAACQQECA8ABPC6AAAAQgEK8AgAAAAdDAAAAAoAAPMAC/BaAAAAhQACAAAAhwABAAAAvwAA
AA8ARAEEAAAAfwEAAAEAvwEAABAAwAEDAAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMA
vwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/
BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKAIpAweFqAIDwAE8LoAAAAyAQrwCAAAAB4MAACACgAA
4wAL8FQAAACFAAIAAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQykKQDLAdSUAADO
AQYAAADRAQEAAAD/AQ4ADgABAgIAAAg/AgAAAwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8B
AACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAsQj2E7sUAA0P
AATwtAAAADIBCvAIAAAAIAwAAAAKAADTAAvwTgAAAIUAAgAAAIcAAQAAAL8AAAAPAIEBBAAACIMB
AAAACL8BDAAeAMABDKQpAMsB1JQAANABAQAAAP8BDgAOAAECAgAACD8CAAADAH8DAAAPAJMAIvE2
AAAAfwEAAEAAvwEAACAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4A
AAAQ8AgAAADOA8ATrhRGBw8ABPBIAAAAEgAK8AgAAAAVDAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF
AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEALwAF8CAAAAAAABTwCAAAAAQA
AAAeDAAAAAAU8AgAAAAIAAAAIAwAABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6G
AKoBTAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu
CAAAAL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA
AAAAAABUCf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAACIECAAAAAEAAAAG
AAAADwDuA4INAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAFAQAABwAMMA8ADASZDAAADwAC8JEM
AAAgAgjwCAAAAAUAAAAFlAAADwAD8CkMAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA
AAIACvAIAAAAAJQAAAUAAAAPAATwIAEAAKIMCvAIAAAAApQAAAAKAADDAAvwbgAAAH8AAQDvAYAA
PJHECoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAA
AL8DAAACAEQAYQB0AGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4P
mBGqEA8ADfCCAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAA
AAEAJgABAAMACACysrL+AAD3DwgAAAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAA
BgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADlAAAAAoAAMMAC/B+
AAAAfwABAO8BgADEnMQKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgA
PwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABv
AGwAZABlAHIAIAA0AAAAAAAQ8AgAAABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIA
AAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACq
DxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8E0B
AAASAArwCAAAAASUAAAgAgAAEwEL8H4AAAAEAAAAAAB/AAEA7wGAAMSjxAqBAAAAAACCAAAAAACD
AAAAAACEAAAAAACFAAAAAACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgA
AACIAwAAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR
8BAAAAAAAMMLCAAAAP////8NAMQKDwAN8IcAAAAAAJ8PBAAAAAAAAAAAAKgPFQAAAFhlbiB2TUNF
IGFwcHJvYWNoICgyKQAAoQ8aAAAAFgAAAAAAAAgKAAEABwAWAAAAAQAgAAAABAAAAKoPNAAAAAMA
AAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgOAAAABgAAAAkEBAgPAATwQAgA
ABIACvAIAAAABZQAACACAAAjAQvwhAAAAAQAAAAAAH8AAQDvAYAAXKnECoEAAAAAAIIAAAAAAIMA
AAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAL8BAAABAP8BAAARAAEDBAQAAD8DAAAI
AIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAXAL7AC4V
sA4PABHwEAAAAAAAwwsIAAAA/////w4AxAoPAA3wdAcAAAAAnw8EAAAAAQAAAAAAoA+QBAAATQBT
AFIAcwAgAGUAbQB1AGwAYQB0AGkAbwBuAA0AUAB1AHIAZQAgAHMALwB3ACAAZQBtAHUAbABhAHQA
aQBvAG4ADQBOAG8AIABuAG8AbgAtAGEAcgBjAGgAIABpAHMAcwB1AGUAcwAgAGEAZwBhAGkAbgAN
AEYAbwByACAAZgBhAG0AaQBsAHkALQBtAG8AZABlAGwAIABpAHMAcwB1AGUAIAByAG8AbwB0ACAA
ZgByAG8AbQAgAGwAZQBnAGEAYwB5ACAAcAByAG8AYwBlAHMAcwBvAHIADQBEAG8AbgAZIHQAIABj
AGEAcgBlAA0ARwB1AGUAcwB0ACAAcAByAG8AYgBlACAAbQBjAGUAIABjAGEAcABhAGIAaQBsAGkA
dABpAGUAcwAgAHYAaQBhACAATQBDAEcAXwBDAEEAUAAsACAAbgBvAHQAIABjAHAAdQBpAGQADQBG
AG8AcgAgAG0AbwBkAGUAbAAtAHMAcABlAGMAaQBmAGkAYwAgAGkAcwBzAHUAZQANAEYAbwByACAA
TQBDAGkAXwBDAFQATAAsACAAcwB0AGkAYwBrACAAdABvACAAYQBsAGwAIAAxABkgcwAgAGEAbgBk
ACAAdAByAGUAYQB0ACAAZwB1AGUAcwB0ACAAdwByAGkAdABlACAAYgBpAHQAIABhAHMAIAAYIG4A
bwB0ACAAaQBtAHAAbABlAG0AZQBuAHQAGSANAEYAbwByACAATQBTAEMATwBEACAAbwBmACAATQBD
AGkAXwBTAFQAQQBUAFUAUwAsACAAZQB4AHAAbwBzAGUAIABhAGwAbAAgADAAGSBzAA0ADQB2AE0A
QwBFACAAbABpAHYAZQAgAG0AaQBnAHIAYQB0AGkAbwBuAA0ATgBvAHQAaABpAG4AZwAgAHMAcABl
AGMAaQBhAGwAIABuAGUAZQBkACAAdABvACAAZABvACAAYQBuAHkAIABtAG8AcgBlAA0ARQByAHIA
bwByAC0AaQBuAGYAbwAgAE0AUwBSAHMAOgAgAHAAbwBpAG4AdABsAGUAcwBzACAAdABvACAAYgBl
ACAAbQBpAGcAcgBhAHQAZQBkAA0ASQBuAGkAdAAmAHAAcgBvAGIAZQAgAE0AUwBSAHMAOgAgAHcA
ZQBsAGwALQBkAGUAZgBpAG4AZQBkACAAYQBuAGQAIAB1AG4AaQBmAGkAZQBkACAAYQB0ACAAYQBs
AGwAIABwAGwAYQB0AGYAbwByAG0AcwANAA0ATQBDAEUAIABpAG4AagBlAGMAdABpAG8AbgANAEIA
cgBvAGEAZABjAGEAcwB0ACAAdABvACAAYQBsAGwAIAB2AGMAcAB1AHMADQBDAG8AcgBuAGUAcgAg
AGMAYQBzAGUADQB2AGMAcAB1AHMAIAA+ACAAcABjAHAAdQBzACwAIABpAG4AagBlAGMAdABpAG8A
bgAgAG8AYwBjAHUAcgAgAGEAdAAgAGEAIABsAG8AbgBnACAAdABpAG0AZQAgAHcAaQBuAGQAbwB3
AA0AVABvAGwAZQByAGEAdABlACAAaQB0AAAAoQ9SAQAADwAAAAAAAAAKAAcALAAAAAEAAAAKAAcA
MgAAAAIAAAAKAAcAPwAAAAMAAAAKAAcAGQAAAAIAAAAKAAcAdAAAAAMAAAAKAAcAFAAAAAAAAAAK
AAcAJAAAAAEAAAAKAAcAZgAAAAIAAAAKAAcADgAAAAAAAAAKAAcAIwAAAAEAAAAKAAcANQAAAAIA
AAAKAAcADAAAAAMAAAAKAAcADwAAAAEAIgAAAAQAEgAsAAAAAAQiAAAEBAAQADIAAAAACCIAAAgE
AA4APwAAAAAIIgAACAQADAAZAAAAAAwiAAAMBAAOAHQAAAAAECIAABAEAAwAFAAAAAEUIgAAFAQA
EgAkAAAAABgiAAAYBAAQAGYAAAAAHCIAABwEAA4ADgAAAAEgIgAAIAQAEgAjAAAAACQiAAAkBAAQ
ADUAAAAAKCIAACgEAA4ADAAAAAAsIgAALAQADAAAAKoPUgEAAAQAAAAHAAAAAwAJBAQIEAAAAAYA
AAAJBAQIAwAAAAcAAAADAAkEBAhtAAAABgAAAAkEBAgDAAAABwAAAAMACQQECB8AAAAGAAAACQQE
CAUAAAAHAAAAAwAJBAQIHgAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAhNAAAABgAAAAkEBAgKAAAA
BwAAAAMACQQECBIAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIPwAAAAYAAAAJBAQIBAAAAAcAAAAD
AAkEBAgbAAAABgAAAAkEBAgKAAAABwAAAAMACQQECAEAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQI
TAAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgNAAAABgAAAAkEBAgFAAAABwAAAAMACQQECAMAAAAG
AAAACQQECAUAAAAHAAAAAwAJBAQINAAAAAYAAAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2AD
EAWABA8ABPBIAAAAEgAK8AgAAAABlAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHe
vWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+
uQAMLoYAqgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAA
AAAA6y4IAAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAA
AAAAAAAAAAAAAMkK/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gNLBQAA
AgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcADDAPAAwEYgQAAA8AAvBaBAAAMAII8AgAAAAE
AAAABJgAAA8AA/DyAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACY
AAAFAAAADwAE8CABAACiDArwCAAAAAKYAAAACgAAwwAL8G4AAAB/AAEA7wGAAEj/xAqBAAAAAACC
AAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwyYAAAC/AwAAAgBEAGEA
dABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXBC+D5gRqhAPAA3wggAA
AAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgA
srKy/gAA9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACm
DwwAAADwAAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAA5gAAAAKAADDAAvwfgAAAH8AAQDvAYAA
vJGuCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDNgAA
AL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAA
NAAAAAAAEPAIAAAAXRC4Dr4PqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAA
AAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAAAAAAqg8aAAAAAQAAAAcA
AAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPBeAQAAEgAK8AgAAAAE
mAAAIAIAABMBC/B+AAAABAAAAAAAfwABAO8BgABkm64KgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA
hQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA/wEAABEAAQMEBAAAPwMAAAgAgMMYAAAAiAMAAAAAvwMA
AAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgAAABjBJ8A8hWoCQ8AEfAQAAAAAADDCwgA
AAD/////DgCuCg8ADfCYAAAAAACfDwQAAAABAAAAAACoDwgAAABEZXRhaWxzDQAAoQ9EAAAACAAA
AAAAAQgKAAgAAQAHAAEAAAABAAAACgAHAAcAAAABACIAAAAEACQAAQAAAAAAIgAEACQAAQAAAAAE
IgAABAQAJAAAAKoPDAAAAAkAAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQP
AATwSAAAABIACvAIAAAAAZgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B
EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6G
AKoBTAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu
CAAAAL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA
AAAAAADJCv////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DhasAAAIA7wMY
AAAAEAAAAAAAAAAAAAAAAAAAgAABAAAHAAwwDwAMBIyqAAAPAALwhKoAAPAACPAIAAAAKwAAAC8R
AAAPAAPwHKoAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAEAAABQAA
AA8ABPAgAQAAogwK8AgAAAACEAAAAAoAAMMAC/BuAAAAfwABAO8BgADIrK4KgQAAAAAAggAAAAAA
gwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAg
AFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8P
BAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4A
APcPCAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA
8AAAANQB0ALwAxAFDwAE8CwBAACiDArwCAAAAAMQAAAACgAAwwAL8H4AAAB/AAEA7wGAAMi3rgqB
AAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAA
AgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAA
ABDwCAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAA
AAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAAR
BAkEAQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwJAEAABIACvAIAAAABBAAACAC
AAADAQvweAAAAAQAAAAAAH8AAQDvAYAAfLmuCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAA
AIcAAAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDAwQAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQA
YQBuAGcAbABlACAAMgAAAAAAEPAIAAAASQAOAWsVwAEPABHwEAAAAAAAwwsIAAAA/////w0ArgoP
AA3wZAAAAAAAnw8EAAAAAAAAAAAAqA8aAAAAUG9pbnQgMTogTVNSIGVtdWxhdGlvbiAoMSkAAKEP
GgAAABsAAAAAAAAICgABAAcAGwAAAAEAIAAAAAQAAACqDwwAAAAbAAAABgAAAAkEBAgPAAPwIpoA
AA8ABPCAAAAAAQAJ8BAAAADTCwAAVgIAAAkWAAANDgAAAgAK8AgAAAAvEQAAAQIAABMAC/AGAAAA
fwAAAQABIwAi8TIAAACfAwEAAACgwyYAAAAIAAgABABuAQAAbQEAAG4BAABuAQAAbgEAAG4BAABu
AQAAbgEAAAAAEPAIAAAAVgLTCwkWDQ4PAATwxAQAABIACvAIAAAAIBEAAAIKAABzAAvwKgAAAH8A
AAAEAIAAZMeuCr8ABAAEAIEBBAAACL8BGAAfAP8BAAAIAL8DAAACACMAIvHjAwAAvwEAAGAAqYPX
AwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07D
MAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVag
iI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0O
B9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBX
WQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAA
AP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg
72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/H
tw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9
HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz
4y8AAAD//wMAUEsDBBQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/L
bsIwEEX3lfgHayp1UxWnLApKMagiaou64yGR5TQektB4nNpuEv6+FgtY3rmjc3Xmy8E0oiPna8sK
nscJCOLC6ppLBfvd+9MMhA/IGhvLpOBMHpaL0d0cU2173lC3DaWIEPYpKqhCaFMpfVGRQT+2LXHs
jtYZDDG6UmqHfYSbRk6S5EUarDkuVNjSqqLiZ/tnFNhm12fTL/c4m+qJOeRZdjr0J6Ue7oe3VxCB
hnB7/s3X3Ud+LS+otVYQTY6f529X6w36QO5yiabREuTiHwAA//8DAFBLAQItABQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG
AAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG
AAgAAAAhAFj08AXWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYA
AAAAAwADALcAAAAKAwAAAAAAAA/wEAAAAGMTAAAxCwAACRYAAJ8MAAAPAA3wdwAAAAAAnw8EAAAA
BwAAAAAAqA8JAAAAMDAwMCwwMDAwAAChDyAAAAAKAAAAAAABCAAACAABAAoAAAABACYAAAAEAAwA
AAAAAwAAqg8MAAAACgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE
8OYEAAASAArwCAAAAB4RAAACCgAAcwAL8CoAAAB/AAAABACAAJDRrgq/AAQABACBAQQAAAi/ARgA
HwD/AQAACAC/AwAAAgAjACLx4wMAAL8BAABgAKmD1wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN
1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9
PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9M
Ik0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR
1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAA
ABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXt
Z3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahp
SlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXO
c0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAWPTw
BdYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4B2sqdVMVpywKSjGoImqLuuMh
keU0HpLQeJzabhL+vhYLWN65o3N15svBNKIj52vLCp7HCQjiwuqaSwX73fvTDIQPyBoby6TgTB6W
i9HdHFNte95Qtw2liBD2KSqoQmhTKX1RkUE/ti1x7I7WGQwxulJqh32Em0ZOkuRFGqw5LlTY0qqi
4mf7ZxTYZtdn0y/3OJvqiTnkWXY69CelHu6Ht1cQgYZwe/7N191Hfi0vqLVWEE2On+dvV+sN+kDu
comm0RLk4h8AAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAA
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAA
AAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAAAAA
AAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACgMAAAAAAAAP8BAAAAA5
DwAAMQsAAGMTAACfDAAADwAN8JkAAAAAAJ8PBAAAAAcAAAAAAKgPHQAAAG1lYW5pbmdmdWwgd2hl
biBNQ0dfRVhUX1Agc2V0AAChDyAAAAAeAAAAAAABCAAACAABAB4AAAABACYAAAAEAAwAAAAAAwAA
qg8aAAAAHQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANg
AxAFgAQPAATw0gQAABIACvAIAAAAHBEAAAIKAABzAAvwKgAAAH8AAAAEAIAAnNuuCr8ABAAEAIEB
BAAACL8BGAAfAP8BAAAIAL8DAAACACMAIvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDh
CAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/U
wIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjH
jympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrF
mJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGV
xCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yz
ra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23z
HztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAI
AAAAIQBIgT8Q1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BT8JAEIXvJP6HzZB4IbKVRCCV
hRiKUbwBGjwO3aEtdGeb3ZWWf++Ggx7fvMn38s0WnanFhZyvLCt4HCYgiHOrKy4UfO5eH6YgfEDW
WFsmBVfysJjf9WaYatvyhi7bUIgIYZ+igjKEJpXS5yUZ9EPbEMfuaJ3BEKMrpHbYRrip5ShJxtJg
xXGhxIaWJeXn7Y9RYOtdm00+3GA60SOz/86y0749KXXf716eQQTqwv/z19PKrNZ/5Q31rhVEk+Pb
9eAqvUEfyN0u0TRagpz/AgAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAA
AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEiBPxDWAAAA+QAA
AA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAA
AA/wEAAAANMLAAAxCwAAOQ8AAJ8MAAAPAA3whQAAAAAAnw8EAAAABwAAAAAAqA8LAAAATUNHX0VY
VF9DTlQAAKEPHgAAAAwAAAAAAAEAAAAIAAwAAAABACYAAAAEAAwAAAAAAwAAqg8aAAAACwAAAAYA
AAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwvAQA
ABIACvAIAAAAGBEAAAIKAABzAAvwKgAAAH8AAAAEAIAAwOWuCr8ABAAEAIEBBAAACL8BGAAfAP8B
AAAIAL8DAAACACMAIvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBY9PAF1gAA
APkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfgHayp1UxWnLApKMagiaou64yGR5TQe
ktB4nNpuEv6+FgtY3rmjc3Xmy8E0oiPna8sKnscJCOLC6ppLBfvd+9MMhA/IGhvLpOBMHpaL0d0c
U2173lC3DaWIEPYpKqhCaFMpfVGRQT+2LXHsjtYZDDG6UmqHfYSbRk6S5EUarDkuVNjSqqLiZ/tn
FNhm12fTL/c4m+qJOeRZdjr0J6Ue7oe3VxCBhnB7/s3X3Ud+LS+otVYQTY6f529X6w36QO5yiabR
EuTiHwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABb
Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAA
AAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAAAAAAAAAAAA
AAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAAGMTAACf
DAAACRYAAA0OAAAPAA3wbwAAAAAAnw8EAAAABwAAAAAAqA8BAAAAMQAAoQ8gAAAAAgAAAAAAAQgA
AAgAAQACAAAAAQAmAAAABAAMAAykKf4AAKoPDAAAAAIAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA
1AEgAdACQALwA2ADEAWABA8ABPDvBAAAEgAK8AgAAAAWEQAAAgoAAHMAC/AqAAAAfwAAAAQAgAC8
764KvwAEAAQAgQEEAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eMDAAC/AQAAYACpg9cDAABQSwME
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD
5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbe
t0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN
50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXy
N+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBL
AwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5Q
xojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u
5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0
p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//
AwBQSwMEFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfeV
+AdrKnVTFacsCkoxqCJqi7rjIZHlNB6S0Hic2m4S/r4WC1jeuaNzdebLwTSiI+drywqexwkI4sLq
mksF+9370wyED8gaG8uk4EwelovR3RxTbXveULcNpYgQ9ikqqEJoUyl9UZFBP7YtceyO1hkMMbpS
aod9hJtGTpLkRRqsOS5U2NKqouJn+2cU2GbXZ9Mv9zib6ok55Fl2OvQnpR7uh7dXEIGGcHv+zdfd
R34tL6i1VhBNjp/nb1frDfpA7nKJptES5OIfAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAA
hQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA
WvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA
WPTwBdYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMA
twAAAAoDAAAAAAAAD/AQAAAAOQ8AAJ8MAABjEwAADQ4AAA8ADfCiAAAAAACfDwQAAAAHAAAAAACo
DxoAAABzdXBwb3J0IHMvdyBlcnJvciByZWNvdmVyeQAAoQ8gAAAAGwAAAAAAAQgAAAgAAQAbAAAA
AQAmAAAABAAMAAykKf4AAKoPJgAAAAgAAAAGAAAACQQECAMAAAAHAAAAAwAJBAQIEAAAAAYAAAAJ
BAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8NAEAAASAArwCAAAABQRAAACCgAA
cwAL8CoAAAB/AAAABACAADAFvgq/AAQABACBAQQAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx4wMA
AL8BAABgAKmD1wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEASIE/ENYAAAD5AAAADwAAAGRycy9kb3du
cmV2LnhtbESPQU/CQBCF7yT+h82QeCGylUQglYUYilG8ARo8Dt2hLXRnm92Vln/vhoMe37zJ9/LN
Fp2pxYWcrywreBwmIIhzqysuFHzuXh+mIHxA1lhbJgVX8rCY3/VmmGrb8oYu21CICGGfooIyhCaV
0uclGfRD2xDH7midwRCjK6R22Ea4qeUoScbSYMVxocSGliXl5+2PUWDrXZtNPtxgOtEjs//OstO+
PSl13+9enkEE6sL/89fTyqzWf+UN9a4VRJPj2/XgKr1BH8jdLtE0WoKc/wIAAP//AwBQSwECLQAU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht
bFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVs
c1BLAQItABQABgAIAAAAIQBIgT8Q1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJl
di54bWxQSwUGAAAAAAMAAwC3AAAACgMAAAAAAAAP8BAAAADTCwAAnwwAADkPAAANDgAADwAN8IMA
AAAAAJ8PBAAAAAcAAAAAAKgPCQAAAE1DR19TRVJfUAAAoQ8eAAAACgAAAAAAAQAAAAgACgAAAAEA
JgAAAAQADAAMpCn+AACqDxoAAAAJAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAApg8WAAAA+B4A
AAAA1AEgAdACQALwA2ADEAWABA8ABPC8BAAAEgAK8AgAAAAQEQAAAgoAAHMAC/AqAAAAfwAAAAQA
gAC4+q4KvwAEAAQAgQEEAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eMDAAC/AQAAYACpg9cDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQ
RfeV+AdrKnVTFacsCkoxqCJqi7rjIZHlNB6S0Hic2m4S/r4WC1jeuaNzdebLwTSiI+drywqexwkI
4sLqmksF+9370wyED8gaG8uk4EwelovR3RxTbXveULcNpYgQ9ikqqEJoUyl9UZFBP7YtceyO1hkM
MbpSaod9hJtGTpLkRRqsOS5U2NKqouJn+2cU2GbXZ9Mv9zib6ok55Fl2OvQnpR7uh7dXEIGGcHv+
zdfdR34tL6i1VhBNjp/nb1frDfpA7nKJptES5OIfAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAWPTwBdYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAoDAAAAAAAAD/AQAAAAYxMAAJ8JAAAJFgAAMQsAAA8ADfBvAAAAAACfDwQAAAAHAAAA
AACoDwEAAAAxAAChDyAAAAACAAAAAAABCAAACAABAAIAAAABACYAAAAEAAwADKQp/gAAqg8MAAAA
AgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8O4EAAASAArwCAAA
AA4RAAACCgAAcwAL8CoAAAB/AAAABACAAOwXvgq/AAQABACBAQQAAAi/ARgAHwD/AQAACAC/AwAA
AgAjACLx4wMAAL8BAABgAKmD1wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250
ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg
6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXut
xYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAm
ZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh
+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3Jl
bHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+En
rWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslp
x4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T
1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAWPTwBdYAAAD5AAAADwAA
AGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4B2sqdVMVpywKSjGoImqLuuMhkeU0HpLQeJzabhL+
vhYLWN65o3N15svBNKIj52vLCp7HCQjiwuqaSwX73fvTDIQPyBoby6TgTB6Wi9HdHFNte95Qtw2l
iBD2KSqoQmhTKX1RkUE/ti1x7I7WGQwxulJqh32Em0ZOkuRFGqw5LlTY0qqi4mf7ZxTYZtdn0y/3
OJvqiTnkWXY69CelHu6Ht1cQgYZwe/7N191Hfi0vqLVWEE2On+dvV+sN+kDucomm0RLk4h8AAP//
AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABf
cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABk
cnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACgMAAAAAAAAP8BAAAAA5DwAAnwkAAGMTAAAx
CwAADwAN8KEAAAAAAJ8PBAAAAAcAAAAAAKgPJQAAAE1DaV9zdGF0dXMgYml0NTY6NTMgYXJlIGFy
Y2ggd2hlbiBzZXQAAKEPIAAAACYAAAAAAAEIAAAIAAEAJgAAAAEAJgAAAAQADAAMpCn+AACqDxoA
AAAKAAAABwAAAAMACQQECBwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWA
BA8ABPDQBAAAEgAK8AgAAAAMEQAAAgoAAHMAC/AqAAAAfwAAAAQAgABwGb4KvwAEAAQAgQEEAAAI
vwEYAB8A/wEAAAgAvwMAAAIAIwAi8eMDAAC/AQAAYACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0H
sBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ2
7eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanH
fW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHO
GtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQs
W78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaM
ZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQ
LrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0Uv
rDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAh
AEiBPxDWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FPwkAQhe8k/ofNkHghspVEIJWFGIpR
vAEaPA7doS10Z5vdlZZ/74aDHt+8yffyzRadqcWFnK8sK3gcJiCIc6srLhR87l4fpiB8QNZYWyYF
V/KwmN/1Zphq2/KGLttQiAhhn6KCMoQmldLnJRn0Q9sQx+5oncEQoyukdthGuKnlKEnG0mDFcaHE
hpYl5eftj1Fg612bTT7cYDrRI7P/zrLTvj0pdd/vXp5BBOrC//PX08qs1n/lDfWuFUST49v14Cq9
QR/I3S7RNFqCnP8CAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEASIE/ENYAAAD5AAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQ
AAAA0wsAAJ8JAAA5DwAAMQsAAA8ADfCDAAAAAACfDwQAAAAHAAAAAACoDwkAAABNQ0dfVEVTX1AA
AKEPHgAAAAoAAAAAAAEAAAAIAAoAAAABACYAAAAEAAwADKQp/gAAqg8aAAAACQAAAAYAAAAJBAQI
AQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwvgQAABIACvAI
AAAAABEAAAIKAABzAAvwKgAAAH8AAAAEAIAAzCK+Cr8ABAAEAIEBBAAACL8BGAAfAP8BAAAIAL8D
AAACACMAIvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0Nv
bnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4
IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmF
e63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrA
ECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5
S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABf
cmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD
4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1C
yWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3
PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBY9PAF1gAAAPkAAAAP
AAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfgHayp1UxWnLApKMagiaou64yGR5TQektB4nNpu
Ev6+FgtY3rmjc3Xmy8E0oiPna8sKnscJCOLC6ppLBfvd+9MMhA/IGhvLpOBMHpaL0d0cU2173lC3
DaWIEPYpKqhCaFMpfVGRQT+2LXHsjtYZDDG6UmqHfYSbRk6S5EUarDkuVNjSqqLiZ/tnFNhm12fT
L/c4m+qJOeRZdjr0J6Ue7oe3VxCBhnB7/s3X3Ud+LS+otVYQTY6f529X6w36QO5yiabREuTiHwAA
//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIA
AGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAAGMTAAAxCAAACRYA
AJ8JAAAPAA3wcQAAAAAAnw8EAAAABwAAAAAAqA8DAAAAMC8xAAChDyAAAAAEAAAAAAABCAAACAAB
AAQAAAABACYAAAAEAAwAAAAAAwAAqg8MAAAABAAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB
0AJAAvADYAMQBYAEDwAE8L8EAAASAArwCAAAAP4QAAACCgAAcwAL8CoAAAB/AAAABACAANgkvgq/
AAQABACBAQQAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx4wMAAL8BAABgAKmD1wMAAFBLAwQUAAYA
CAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pT
OCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8Ud
KEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyK
tN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7
ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNb
odfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZu
pHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFO
YQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBL
AwQUAAYACAAAACEAWPTwBdYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4B2sq
dVMVpywKSjGoImqLuuMhkeU0HpLQeJzabhL+vhYLWN65o3N15svBNKIj52vLCp7HCQjiwuqaSwX7
3fvTDIQPyBoby6TgTB6Wi9HdHFNte95Qtw2liBD2KSqoQmhTKX1RkUE/ti1x7I7WGQwxulJqh32E
m0ZOkuRFGqw5LlTY0qqi4mf7ZxTYZtdn0y/3OJvqiTnkWXY69CelHu6Ht1cQgYZwe/7N191Hfi0v
qLVWEE2On+dvV+sN+kDucomm0RLk4h8AAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY9PAF
1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAA
CgMAAAAAAAAP8BAAAAA5DwAAMQgAAGMTAACfCQAADwAN8HIAAAAAAJ8PBAAAAAcAAAAAAKgPBAAA
AENNQ0kAAKEPIAAAAAUAAAAAAAEIAAAIAAEABQAAAAEAJgAAAAQADAAAAAADAACqDwwAAAAFAAAA
BgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATw0QQAABIACvAIAAAA/BAA
AAIKAABzAAvwKgAAAH8AAAAEAIAAdDa+Cr8ABAAEAIEBBAAACL8BGAAfAP8BAAAIAL8DAAACACMA
IvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/
n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSj
lD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVT
vbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkq
uyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8u
cmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPR
yNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKb
TCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCcz
VQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBIgT8Q1gAAAPkAAAAPAAAAZHJz
L2Rvd25yZXYueG1sRI9BT8JAEIXvJP6HzZB4IbKVRCCVhRiKUbwBGjwO3aEtdGeb3ZWWf++Ggx7f
vMn38s0WnanFhZyvLCt4HCYgiHOrKy4UfO5eH6YgfEDWWFsmBVfysJjf9WaYatvyhi7bUIgIYZ+i
gjKEJpXS5yUZ9EPbEMfuaJ3BEKMrpHbYRrip5ShJxtJgxXGhxIaWJeXn7Y9RYOtdm00+3GA60SOz
/86y0749KXXf716eQQTqwv/z19PKrNZ/5Q31rhVEk+Pb9eAqvUEfyN0u0TRagpz/AgAA//8DAFBL
AQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAEiBPxDWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9k
b3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAANMLAAAxCAAAOQ8AAJ8JAAAP
AA3whAAAAAAAnw8EAAAABwAAAAAAqA8KAAAATUNHX0NNQ0lfUAAAoQ8eAAAACwAAAAAAAQAAAAgA
CwAAAAEAJgAAAAQADAAAAAADAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAApg8W
AAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPDcBAAAEgAK8AgAAADTEAAAAgoAAHMAC/AqAAAA
fwAAAAQAgABwQL4KvwAEAAQAgQEEAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8d0DAACpg9cDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQ
RfeV+AdrKnVTFacsCkoxqCJqi7rjIZHlNB6S0Hic2m4S/r4WC1jeuaNzdebLwTSiI+drywqexwkI
4sLqmksF+9370wyED8gaG8uk4EwelovR3RxTbXveULcNpYgQ9ikqqEJoUyl9UZFBP7YtceyO1hkM
MbpSaod9hJtGTpLkRRqsOS5U2NKqouJn+2cU2GbXZ9Mv9zib6ok55Fl2OvQnpR7uh7dXEIGGcHv+
zdfdR34tL6i1VhBNjp/nb1frDfpA7nKJptES5OIfAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAWPTwBdYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAoDAAAAAAAAD/AQAAAAOQ8AAMMGAABjEwAAMQgAAA8ADfCVAAAAAACfDwQAAAAHAAAA
AACoDw0AAABleHRlbmRlZCByZWdzAAChDyAAAAAOAAAAAAABCAAACAABAA4AAAABACYAAAAEAAwA
AAAAAwAAqg8mAAAACQAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgAAKYPFgAA
APgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwzwQAABIACvAIAAAA0RAAAAIKAABzAAvwKgAAAH8A
AAAEAIAAKEu+Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsD
BBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8
Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG
3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWr
jedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R1
8jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQ
SwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5Tu
UMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0O
buVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJ
NKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD/
/wMAUEsDBBQABgAIAAAAIQAkLAro1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3
lfoP1lTqJioOLAoKGFQ1QlTd8ZCguyEekkBsR/aUhL+vxaIs79zRuTqzRW8acSUfamcVDAcpCLKF
07UtFey2y7cJiMBoNTbOkoIbBVjMn59mmGnX2TVdN1yKCLEhQwUVc5tJGYqKDIaBa8nG7uS8QY7R
l1J77CLcNHKUpu/SYG3jQoUtfVZUXDa/RoFrtl0+/vbJZKxHZn/I8/O+Oyv1+tJ/TEEw9fx4viQ/
S07+yzvqSyuIJqfV7ehrvcbA5O+XaBotQc7/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
ACQsCujWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwAD
ALcAAAAKAwAAAAAAAA/wEAAAADkPAABVBQAAYxMAAMMGAAAPAA3wiAAAAAAAnw8EAAAABwAAAAAA
qA8aAAAAZGlzYWJsZSBNQ0dfQ1RMIHdoZW4gY2xlYXIAAKEPIAAAABsAAAAAAAEIAAAIAAEAGwAA
AAEAJgAAAAQADAAAAAADAACqDwwAAAAbAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC
8ANgAxAFgAQPAATwwwQAABIACvAIAAAAzxAAAAIKAABzAAvwKgAAAH8AAAAEAIAAcEy+Cr8ABAAE
AIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHcAwAAqYPWAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQABf6RM1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8JAEIbvBf/DMkIvRTdVUEldpRhK
xZsfYI/T7JjEZmfD7tbEf+/iQY/vvMPz8syXnanFhZyvLCt4HyYgiHOrKy4UHPZfgxkIH5A11pZJ
wZU8LBe9lzmm2ra8pcsuFCJC2KeooAyhSaX0eUkG/dA2xLE7WWcwxOgKqR22EW5qOUqSiTRYcVwo
saFVSfnf7t8osPW+zaYb9zab6pE5/mTZ+dielXrtd58fIAJ14fncIK3Gk0d5R621gmhy+r7+ukpv
0Qdy90s0jZYgFzcAAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAX+kTNUAAAD5AAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAkDAAAAAAAAD/AQ
AAAAOQ8AAOgDAABjEwAAVQUAAA8ADfB9AAAAAACfDwQAAAAHAAAAAACoDw8AAABDUFUgYmFuayBu
dW1iZXIAAKEPIAAAABAAAAAAAAEIAAAIAAEAEAAAAAEAJgAAAAQADAAMpCn+AACqDwwAAAAQAAAA
BgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwxgQAABIACvAIAAAAyxAA
AAIKAACDAAvwMAAAAH8AAAAEAIAAjF6+Cr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8D
AAACABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/
n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSj
lD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVT
vbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkq
uyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8u
cmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPR
yNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKb
TCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCcz
VQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQDgjhIb1gAAAPkAAAAPAAAAZHJz
L2Rvd25yZXYueG1sRI/LasMwEEX3hf6DmEI2JZEbShLcKKHULQ3Z5QHucmpN/Kg1MpISO39fkUW7
vHOHcznL9WBacSHna8sKniYJCOLC6ppLBcfDx3gBwgdkja1lUnAlD+vV/d0SU2173tFlH0oRIexT
VFCF0KVS+qIig35iO+LYnawzGGJ0pdQO+wg3rZwmyUwarDkuVNjRW0XFz/5sFNj20GfzrXtczPXU
5F9Z1uR9o9ToYXh9ARFoCP/PG9vk789/5Q210Qqiyenz+u1qvUMfyN0u0TRaglz9AgAA//8DAFBL
AQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAOCOEhvWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9k
b3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAADkPAABWAgAAYxMAAOgDAAAP
AA3weQAAAAAAnw8EAAAABwAAAAAAqA8LAAAARGVzY3JpcHRpb24AAKEPIAAAAAwAAAAAAAEIAAAI
AAEADAAAAAEAJgAAAAQADAD/mQD+AACqDwwAAAAMAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQB
IAHQAkAC8ANgAxAFgAQPAATw1gQAABIACvAIAAAAsxAAAAIKAACDAAvwMAAAAH8AAAAEAIAA4GC+
Cr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQDgjhIb1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LasMwEEX3hf6D
mEI2JZEbShLcKKHULQ3Z5QHucmpN/Kg1MpISO39fkUW7vHOHcznL9WBacSHna8sKniYJCOLC6ppL
BcfDx3gBwgdkja1lUnAlD+vV/d0SU2173tFlH0oRIexTVFCF0KVS+qIig35iO+LYnawzGGJ0pdQO
+wg3rZwmyUwarDkuVNjRW0XFz/5sFNj20GfzrXtczPXU5F9Z1uR9o9ToYXh9ARFoCP/PG9vk789/
5Q210Qqiyenz+u1qvUMfyN0u0TRaglz9AgAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAOCO
EhvWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAKAwAAAAAAAA/wEAAAAGMTAABWAgAACRYAAOgDAAAPAA3wiQAAAAAAnw8EAAAABwAAAAAAqA8b
AAAARGVmaW5lZCBpbnRlcmZhY2UgZm9yIGd1ZXN0AAChDyAAAAAcAAAAAAABCAAACAABABwAAAAB
ACYAAAAEAAwA/5kA/gAAqg8MAAAAHAAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvAD
YAMQBYAEDwAE8NAEAAASAArwCAAAAK8QAAACCgAAgwAL8DAAAAB/AAAABACAABRqvgq/AAQABACB
AZaWlgCDAQAAAAi/ARAAFAD/AQAACAC/AwAAAgATACLx3gMAAKmD2AMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEAbxN4ktcAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPQUvDQBCF74L/YRnBi9iNPdgS
uy1iKIp4aFqhHsfsJJuanQ27a5P++y496PHNG77Ht1iNthNH8qF1rOBhkoEgrpxuuVHwuVvfz0GE
iKyxc0wKThRgtby+WmCu3cAlHbexEQnCIUcFJsY+lzJUhiyGieuJU1c7bzGm6BupPQ4Jbjs5zbJH
abHltGCwpxdD1c/21ypw3W4oZu/+bj7TU7v/KorDfjgodXszPj+BiDTG/+e1qTcf5V95Qb1pBcmk
fj19+1aXGCL5yyWZJkuQyzMAAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAA
AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAbxN4ktcAAAD5
AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAsDAAAA
AAAAD/AQAAAA0wsAAFYCAAA5DwAA6AMAAA8ADfCCAAAAAACfDwQAAAAHAAAAAACoDxQAAABNQ0df
Q0FQIGNhcGFiaWxpdGllcwAAoQ8gAAAAFQAAAAAAAQgAAAgAAQAVAAAAAQAmAAAABAAMAP+ZAP4A
AKoPDAAAABUAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPC+BAAA
EgAK8AgAAAAJEAAAAgoAAHMAC/AqAAAAfwAAAAQAgAAkdL4KvwAEAAQAgQEEAAAIvwEQABQA/wEA
AAgAvwMAAAIAEwAi8d0DAACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29u
dGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg
4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7
rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQ
JmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL
4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9y
ZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPh
J61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJ
aceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+
09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAI6TYwTWAAAA+QAAAA8A
AABkcnMvZG93bnJldi54bWxEj0FrAjEQhe8F/0MYoZdSs+6hytYoxUVaeilqQY/Tzbgbu5ksSequ
/77BQ3t884bv8S1Wg23FhXwwjhVMJxkI4sppw7WCz/3mcQ4iRGSNrWNScKUAq+XoboGFdj1v6bKL
tUgQDgUqaGLsCilD1ZDFMHEdcepOzluMKfpaao99gttW5ln2JC0aTgsNdrRuqPre/VgFrt335ezd
P8xnOreHY1meD/1Zqfvx8PIMItIQ/5+PJseP9V95Q71pBcnk9Hr98kZvMUTyt0syTZYgl78AAAD/
/wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50
X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAA
X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAjpNjBNYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQAAAA0wsAAOgDAAA5DwAA
VQUAAA8ADfB3AAAAAACfDwQAAAAHAAAAAACoDwsAAABDb3VudCBmaWVsZAAAoQ8eAAAADAAAAAAA
AQAAAAgADAAAAAEAJgAAAAQADAAMpCn+AACqDwwAAAAMAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAA
ANQBIAHQAkAC8ANgAxAFgAQPAATwvQQAABIACvAIAAAACxAAAAIKAABzAAvwKgAAAH8AAAAEAIAA
JHy+Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHcAwAAqYPWAwAAUEsDBBQABgAI
AAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4
IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0o
ScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq0
3oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJ
r4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAG
AAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh
19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6k
cBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5h
B+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsD
BBQABgAIAAAAIQABf6RM1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8JAEIbvBf/DMkIv
RTdVUEldpRhKxZsfYI/T7JjEZmfD7tbEf+/iQY/vvMPz8syXnanFhZyvLCt4HyYgiHOrKy4UHPZf
gxkIH5A11pZJwZU8LBe9lzmm2ra8pcsuFCJC2KeooAyhSaX0eUkG/dA2xLE7WWcwxOgKqR22EW5q
OUqSiTRYcVwosaFVSfnf7t8osPW+zaYb9zab6pE5/mTZ+dielXrtd58fIAJ14fncIK3Gk0d5R621
gmhy+r7+ukpv0Qdy90s0jZYgFzcAAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMA
AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78A
AAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAX+kTNUA
AAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAkD
AAAAAAAAD/AQAAAAYxMAAOgDAAAJFgAAVQUAAA8ADfB3AAAAAACfDwQAAAAHAAAAAACoDwkAAAAw
MDAwLDAwMDEAAKEPIAAAAAoAAAAAAAEIAAAIAAEACgAAAAEAJgAAAAQADAAMpCn+AACqDwwAAAAK
AAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwygQAABIACvAIAAAA
DBAAAAIKAABzAAvwKgAAAH8AAAAEAIAAUI++Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAAC
ABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv
9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q
50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9
QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhd
jr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVs
c2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnC
ruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ
1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB
9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCnua/d1gAAAPkAAAAPAAAAZHJzL2Rv
d25yZXYueG1sRI/LbsIwEEX3lfgHayp1UxUHFgUFDKoaqlZdlYdEl0M8eUA8jmyXhL+vxQKWd+7o
XJ35sjeNOJPztWUFo2ECgji3uuZSwW778TIF4QOyxsYyKbiQh+Vi8DDHVNuO13TehFJECPsUFVQh
tKmUPq/IoB/aljh2hXUGQ4yulNphF+GmkeMkeZUGa44LFbb0XlF+2vwZBbbZdtnk2z1PJ3ps9r9Z
dtx3R6WeHvu3GYhAfbg/j5Ji9bO6lVfUl1YQTYrPy8HVeo0+kLteomm0BLn4BwAA//8DAFBLAQIt
ABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAKe5r93WAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3du
cmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAANMLAABVBQAAOQ8AAMMGAAAPAA3w
gwAAAAAAnw8EAAAABwAAAAAAqA8JAAAATUNHX0NUTF9QAAChDx4AAAAKAAAAAAABAAAACAAKAAAA
AQAmAAAABAAMAAAAAAMAAKoPGgAAAAkAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEAACmDxYAAAD4
HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8LcEAAASAArwCAAAAA4QAAACCgAAcwAL8CoAAAB/AAAA
BACAABCavgq/AAQABACBAQQAAAi/ARAAFAD/AQAACAC/AwAAAgATACLx3QMAAKmD1wMAAFBLAwQU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPk
K2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63
T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43n
RJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI3
4Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsD
BBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDG
iNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7l
TBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSn
YEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8D
AFBLAwQUAAYACAAAACEAJCwK6NYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X6
D9ZU6iYqDiwKChhUNUJU3fGQoLshHpJAbEf2lIS/r8WiLO/c0bk6s0VvGnElH2pnFQwHKQiyhdO1
LRXstsu3CYjAaDU2zpKCGwVYzJ+fZphp19k1XTdcigixIUMFFXObSRmKigyGgWvJxu7kvEGO0ZdS
e+wi3DRylKbv0mBt40KFLX1WVFw2v0aBa7ZdPv72yWSsR2Z/yPPzvjsr9frSf0xBMPX8eL4kP0tO
/ss76ksriCan1e3oa73GwOTvl2gaLUHO/wAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAk
LAro1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAACgMAAAAAAAAP8BAAAABjEwAAVQUAAAkWAADDBgAADwAN8HAAAAAAAJ8PBAAAAAcAAAAAAKgP
AgAAADAgAAChDyAAAAADAAAAAAABCAAACAABAAMAAAABACYAAAAEAAwAAAAAAwAAqg8MAAAAAwAA
AAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8MsEAAASAArwCAAAAA8Q
AAACCgAAcwAL8CoAAAB/AAAABACAABijvgq/AAQABACBAQQAAAi/ARAAFAD/AQAACAC/AwAAAgAT
ACLx3gMAAKmD2AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA6XcmENcAAAD5AAAADwAAAGRycy9kb3du
cmV2LnhtbESPQU8CMRCF7yT+h2ZMvBDpSiKQlUKMi9GYeABM8Dhuh93F7XRpK13+vQ0HPb55k+/l
my9704oTOd9YVnA3ykAQl1Y3XCn42D7fzkD4gKyxtUwKzuRhubgazDHXNvKaTptQiQRhn6OCOoQu
l9KXNRn0I9sRp25vncGQoqukdhgT3LRynGUTabDhtFBjR081ld+bH6PAtttYTN/ccDbVY7P7LIrD
Lh6UurnuHx9ABOrD//PqeP8eJ3/lBfWqFSST/cv5yzV6jT6Qu1ySabIEufgFAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEA6XcmENcAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAsDAAAAAAAAD/AQAAAA0wsAAMMGAAA5DwAAMQgAAA8ADfCD
AAAAAACfDwQAAAAHAAAAAACoDwkAAABNQ0dfRVhUX1AAAKEPHgAAAAoAAAAAAAEAAAAIAAoAAAAB
ACYAAAAEAAwAAAAAAwAAqg8aAAAACQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPge
AAAAANQBIAHQAkAC8ANgAxAFgAQPAATwtgQAABIACvAIAAAAERAAAAIKAABzAAvwKgAAAH8AAAAE
AIAAvK2+Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfgH
ayp1UxWnLApKMagiaou64yGR5TQektB4nNpuEv6+FgtY3rmjc3Xmy8E0oiPna8sKnscJCOLC6ppL
Bfvd+9MMhA/IGhvLpOBMHpaL0d0cU2173lC3DaWIEPYpKqhCaFMpfVGRQT+2LXHsjtYZDDG6UmqH
fYSbRk6S5EUarDkuVNjSqqLiZ/tnFNhm12fTL/c4m+qJOeRZdjr0J6Ue7oe3VxCBhnB7/s3X3Ud+
LS+otVYQTY6f529X6w36QO5yiabREuTiHwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFj0
8AXWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAKAwAAAAAAAA/wEAAAAGMTAADDBgAACRYAADEIAAAPAA3wbwAAAAAAnw8EAAAABwAAAAAAqA8B
AAAAMAAAoQ8gAAAAAgAAAAAAAQgAAAgAAQACAAAAAQAmAAAABAAMAAAAAAMAAKoPDAAAAAIAAAAG
AAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPA9BAAAQgEK8AgAAAAbEAAA
AgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEBAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi
8dsDAAD/AQAAQACpg88DAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAOBQGabOAAAA7AAAAA8AAABkcnMv
ZG93bnJldi54bWxEj91qAjEQhe8LvkMYoXc1q0gpq1FEEAVbiz8PMG5mN4ubyZLEdX37hlLo5cyc
Oed882VvG9GRD7VjBeNRBoK4cLrmSsHlvHn7ABEissbGMSl4UoDlYvAyx1y7Bx+pO8VKJBMOOSow
Mba5lKEwZDGMXEucbqXzFmMafSW1x0cyt42cZNm7tFhzSjDY0tpQcTvdrYL1Z1VOeH8opxu2Xwez
6trL9lup12G/moGI1Md/8d/3TitI5cvt8+prfcQQyf9uElwCA7n4AQAA//8DAFBLAQItABQABgAI
AAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB
Ai0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsB
Ai0AFAAGAAgAAAAhAOBQGabOAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2Lnht
bFBLBQYAAAAAAwADALcAAAACAwAAAAAAAA/wEAAAADkPAABWAgAAOQ8AAA0OAAAPAATwPQQAAEIB
CvAIAAAAHhAAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAQAACMsBnDEAAP8BGAAY
AL8DAAACACMAIvHbAwAA/wEAAEAAqYPPAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2
pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywN
jCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4
shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/
yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4
P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUT
Uf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9T
MfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQDgUBmmzgAAAOwA
AAAPAAAAZHJzL2Rvd25yZXYueG1sRI/dagIxEIXvC75DGKF3NatIKatRRBAFW4s/DzBuZjeLm8mS
xHV9+4ZS6OXMnDnnfPNlbxvRkQ+1YwXjUQaCuHC65krB5bx5+wARIrLGxjEpeFKA5WLwMsdcuwcf
qTvFSiQTDjkqMDG2uZShMGQxjFxLnG6l8xZjGn0ltcdHMreNnGTZu7RYc0ow2NLaUHE73a2C9WdV
Tnh/KKcbtl8Hs+ray/Zbqddhv5qBiNTHf/Hf904rSOXL7fPqa33EEMn/bhJcAgO5+AEAAP//AwBQ
SwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVs
cy8ucmVsc1BLAQItABQABgAIAAAAIQDgUBmmzgAAAOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMv
ZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAAAgMAAAAAAAAP8BAAAADTCwAAVQUAAAkWAABVBQAA
DwAE8D0EAABCAQrwCAAAAB8QAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADAAQEAAAjL
AZwxAAD/ARgAGAC/AwAAAgAjACLx2wMAAP8BAABAAKmDzwMAAFBLAwQUAAYACAAAACEA2+H2y+4A
AACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQew
EreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt
5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9
bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a
2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxk
svXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAu
sahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+s
PNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA
4FAZps4AAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESP3WoCMRCF7wu+QxihdzWrSCmrUUQQBVuL
Pw8wbmY3i5vJksR1ffuGUujlzJw553zzZW8b0ZEPtWMF41EGgrhwuuZKweW8efsAESKyxsYxKXhS
gOVi8DLHXLsHH6k7xUokEw45KjAxtrmUoTBkMYxcS5xupfMWYxp9JbXHRzK3jZxk2bu0WHNKMNjS
2lBxO92tgvVnVU54fyinG7ZfB7Pq2sv2W6nXYb+agYjUx3/x3/dOK0jly+3z6mt9xBDJ/24SXAID
ufgBAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtD
b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAA
AAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA4FAZps4AAADsAAAADwAAAAAAAAAAAAAA
AAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAIDAAAAAAAAD/AQAAAA0wsAAMMG
AAAJFgAAwwYAAA8ABPA9BAAAQgEK8AgAAAAgEAAAAgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEA
ABAAwAEBAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi8dsDAAD/AQAAQACpg88DAABQSwMEFAAGAAgA
AAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgg
hNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJ
yBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTe
gLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mv
ic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYA
CAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX
0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRw
GF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH
5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwME
FAAGAAgAAAAhAOBQGabOAAAA7AAAAA8AAABkcnMvZG93bnJldi54bWxEj91qAjEQhe8LvkMYoXc1
q0gpq1FEEAVbiz8PMG5mN4ubyZLEdX37hlLo5cycOed882VvG9GRD7VjBeNRBoK4cLrmSsHlvHn7
ABEissbGMSl4UoDlYvAyx1y7Bx+pO8VKJBMOOSowMba5lKEwZDGMXEucbqXzFmMafSW1x0cyt42c
ZNm7tFhzSjDY0tpQcTvdrYL1Z1VOeH8opxu2Xwez6trL9lup12G/moGI1Md/8d/3TitI5cvt8+pr
fcQQyf9uElwCA7n4AQAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAA
AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAOBQGabOAAAA7AAAAA8A
AAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAACAwAAAAAAAA/w
EAAAANMLAAAxCAAACRYAADEIAAAPAATwPgQAAEIBCvAIAAAAIxAAAAIKAABzAAvwKgAAAL8ABAAE
AH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BGAAYAL8DAAACACMAIvHcAwAA/wEAAEAAqYPQAwAA
UEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH
70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23
jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3
VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0
r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//
AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0
X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8w
Wl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXR
gPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8A
AAD//wMAUEsDBBQABgAIAAAAIQAG5sQ4zwAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BSwMx
EIXvQv9DmEJvNqsUkbVpKZWieNGuXryNm+lmcTNZkmm7219vEMHjzLx5733L9eA7daKY2sAGbuYF
KOI62JYbAx/vu+t7UEmQLXaBycBICdarydUSSxvOvKdTJY3KJpxKNOBE+lLrVDvymOahJ863Q4ge
JY+x0TbiOZv7Tt8WxZ322HJOcNjT1lH9XR29gcouXt62l+LzUY58cZvxdWcrbcxsOmweQAkN8i/+
+362BnL5w9P4FVu7xyQUfzcZLoOBXv0AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQs
W78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEABubE
OM8AAADsAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAA
AAMDAAAAAAAAD/AQAAAA0wsAAFYCAADTCwAADQ4AAA8ABPA+BAAAQgEK8AgAAAAkEAAAAgoAAHMA
C/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEYABgAvwMAAAIAIwAi8dwDAAD/
AQAAQACpg9ADAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10u
eG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QW
iuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/j
jCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6E
MiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHy
baWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/B
asMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ
9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqM
xfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTa
unYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAAbmxDjPAAAA7AAAAA8AAABkcnMvZG93bnJl
di54bWxEj0FLAzEQhe9C/0OYQm82qxSRtWkplaJ40a5evI2b6WZxM1mSabvbX28QwePMvHnvfcv1
4Dt1opjawAZu5gUo4jrYlhsDH++763tQSZAtdoHJwEgJ1qvJ1RJLG868p1MljcomnEo04ET6UutU
O/KY5qEnzrdDiB4lj7HRNuI5m/tO3xbFnfbYck5w2NPWUf1dHb2Byi5e3raX4vNRjnxxm/F1Zytt
zGw6bB5ACQ3yL/77frYGcvnD0/gVW7vHJBR/Nxkug4Fe/QAAAP//AwBQSwECLQAUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQA
BgAIAAAAIQAG5sQ4zwAAAOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUG
AAAAAAMAAwC3AAAAAwMAAAAAAAAP8BAAAAAJFgAAVgIAAAkWAAANDgAADwAE8D4EAABCAQrwCAAA
ACUQAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/ARgAGAC/AwAA
AgAjACLx3AMAAP8BAABAAKmD0AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250
ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg
6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXut
xYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAm
ZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh
+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3Jl
bHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+En
rWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslp
x4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T
1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEABubEOM8AAADsAAAADwAA
AGRycy9kb3ducmV2LnhtbESPQUsDMRCF70L/Q5hCbzarFJG1aSmVonjRrl68jZvpZnEzWZJpu9tf
bxDB48y8ee99y/XgO3WimNrABm7mBSjiOtiWGwMf77vre1BJkC12gcnASAnWq8nVEksbzrynUyWN
yiacSjTgRPpS61Q78pjmoSfOt0OIHiWPsdE24jmb+07fFsWd9thyTnDY09ZR/V0dvYHKLl7etpfi
81GOfHGb8XVnK23MbDpsHkAJDfIv/vt+tgZy+cPT+BVbu8ckFH83GS6DgV79AAAA//8DAFBLAQIt
ABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAAbmxDjPAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3du
cmV2LnhtbFBLBQYAAAAAAwADALcAAAADAwAAAAAAAA/wEAAAANMLAABWAgAACRYAAFYCAAAPAATw
PgQAAEIBCvAIAAAAJhAAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAQAACMsBn28A
AP8BGAAYAL8DAAACACMAIvHcAwAA/wEAAEAAqYPQAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAG5sQ4
zwAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BSwMxEIXvQv9DmEJvNqsUkbVpKZWieNGuXryN
m+lmcTNZkmm7219vEMHjzLx5733L9eA7daKY2sAGbuYFKOI62JYbAx/vu+t7UEmQLXaBycBICdar
ydUSSxvOvKdTJY3KJpxKNOBE+lLrVDvymOahJ863Q4geJY+x0TbiOZv7Tt8WxZ322HJOcNjT1lH9
XR29gcouXt62l+LzUY58cZvxdWcrbcxsOmweQAkN8i/++362BnL5w9P4FVu7xyQUfzcZLoOBXv0A
AAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250
ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAf
AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEABubEOM8AAADsAAAADwAAAAAAAAAAAAAAAAAH
AgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAMDAAAAAAAAD/AQAAAA0wsAAA0OAAAJ
FgAADQ4AAA8ABPCwAAAAQgEK8AgAAACwEAAAAgoAAMMAC/BIAAAAhQACAAAAhwABAAAAvwAAAA8A
vwEAABAAwAEBAAAIywGcMQAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi
8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/w
EAAAANMLAADoAwAACRYAAOgDAAAPAATwsAAAAEIBCvAIAAAAzBAAAAIKAADDAAvwSAAAAIEAAAAA
AIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAPAL8BAAAQAMABAQAACMsBnDEAAP8BDAAOAD8CAAADAL8C
AAAIAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG
AE4AfwYGAA4AAAAP8BAAAABjEwAAVgIAAGMTAAANDgAADwAE8LAAAABCAQrwCAAAAP0QAAACCgAA
wwAL8EgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQADwC/AQAAEADAAQEAAAjLAZwxAAD/
AQwADgA/AgAAAwC/AgAACAB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8F
BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA0wsAAJ8JAAAJFgAAnwkAAA8ABPCwAAAAQgEK
8AgAAAANEQAAAgoAAMMAC/BIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAA8AvwEAABAA
wAEBAAAIywGcMQAA/wEMAA4APwIAAAMAvwIAAAgAfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/
AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAANMLAAAxCwAACRYAADEL
AAAPAATwsAAAAEIBCvAIAAAAHREAAAIKAADDAAvwSAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA
AL8ABAAPAL8BAAAQAMABAQAACMsBnDEAAP8BDAAOAD8CAAADAL8CAAAIAH8DAAAPAIMAIvEwAAAA
fwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAADT
CwAAnwwAAAkWAACfDAAADwAE8DIMAAASAArwCAAAACcQAAAACgAAwwAL8GAAAAB/AAAA7wGAAEQI
wAqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQAAEQD/AQAAGAA/AwAACACAwxgAAAC/
AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAAAABDwCAAAAEUBVAChC80ODwAN8KILAAAAAJ8P
BAAAAAQAAAAAAKAPOggAAEkAbgBpAHQAJgBwAHIAbwBiAGUAIABpAG4AdABlAHIAZgBhAGMAZQA6
AA0ATQBDAEcAXwBDAEEAUAANAFIAZQBhAGQALQBvAG4AbAB5ACAATQBTAFIALAAgAGUAbQB1AGwA
YQB0AGUAZAAgAGEAcwAgABggdwByAGkAdABlACAAbgBvAHQAIABjAGgAYQBuAGcAZQBzABkgIABz
AGkAbgBjAGUAIAB3AHIAaQB0AGUAIABlAGYAZgBlAGMAdAAgAGkAcwAgAHUAbgBkAGUAZgBpAG4A
ZQBkAA0ARABpAHMAYQBiAGwAZQAgAFMAUgBBAE8ALwBTAFIAQQBSAC0AdQBuAHIAZQBsAGEAdABl
AGQAIABjAGEAcAAgACAAKAAwACkADQBNAEMARwBfAEMAVABMAF8AUAA9ADAAIAB0AG8AIABkAGkA
cwBhAGIAbABlACAATQBDAEcAXwBDAFQATAANAE0AQwBHAF8ARQBYAFQAXwBQAD0AMAAsACAAbgBv
ACAAZQB4AHQAIAByAGUAZwBzACwAIAByAGQAbQBzAHIALwB3AHIAbQBzAHIAIABmAG8AcgAgADEA
OAAwAEgALQAxADgANQBIAC8AMQA4ADgASAAtADEAOQA3AEgAIABjAGEAdQBzAGUAIABHAFAAIwAN
AEUAbgBhAGIAbABlACAAUwBSAEEATwAvAFMAUgBBAFIALQByAGUAbABhAHQAZQBkACAAYwBhAHAA
IAAgACAAIAAgACAAKAAxACkADQBFAG4AYQBiAGwAZQAgAE0AQwBHAF8AVABFAFMAXwBQACAAdABv
ACAAYQB2AG8AaQBkACAAbQBvAGQAZQBsACAAcwBwAGUAYwBpAGYAaQBjAA0ARQBuAGEAYgBsAGUA
IABNAEMARwBfAFMARQBSAF8AUAAgAHQAbwAgAHMAdQBwAHAAbwByAHQAIABzAC8AdwAgAHIAZQBj
AG8AdgBlAHIAeQANAEUAbQB1AGwAYQB0AGUAIABvAG4AbAB5ACAAMQAgAGIAYQBuAGsAIAB0AG8A
IABnAHUAZQBzAHQADQBNAGkAZwByAGEAdABpAG8AbgAgAHcAbwB1AGwAZAAgAG4AbwB0ACAAYgBs
AG8AYwBrAGUAZAAgAHQAaABlAG4ADQBJAGYAIAByAGUAYQBsAGwAeQAgADIAIABwAGgAeQBzAGkA
YwBhAGwAIABlAHIAcgBvAHIAIABvAGMAYwB1AHIAIABhAHQAIAAxACAATQBDAEUAIwAsACAAaAB5
AHAAZQByAHYAaQBzAG8AcgAgAHcAbwB1AGwAZAAgAGMAcgBhAHMAaAA7AA0ARABlAGwAaQB2AGUA
cgAgAHQAaABlACAAYgBhAG4AawAgAGkAbgBkAGkAYwBhAHQAZQAgAFMAUgBBAE8ALwBTAFIAQQBS
ACAAZQByAHIAbwByACAAdABvACAAZwB1AGUAcwB0AA0AQwB1AHIAcgBlAG4AdABsAHkAIAB3AGUA
IABkAGkAcwBhAGIAbABlACAATQBDAEcAXwBDAE0AQwBJAF8AUAAsACAAYgB1AHQAIABlAG4AYQBi
AGwAaQBuAGcAIABpAHQAIABtAGEAeQAgAGIAZQBuAGUAZgBpAHQAIAB0AGgAYQB0ACAAZwB1AGUA
cwB0ACAAbQBhAHkAIABuAG8AdAAgAHAAbwBsAGwAIABiAGEAbgBrAHMAIABwAGUAcgBpAG8AZABp
AGMAYQBsAGwAeQAgACoADQBNAEMARwBfAEMAVABMAA0ARABpAHMAYQBiAGwAZQAgAGkAdAAgAHYA
aQBhACAATQBDAEcAXwBDAFQATABfAFAAIAA9ACAAMAANAE4AbwAgAG0AbwBkAGUAbAAgAHMAcABl
AGMAaQBmAGkAYwAgAGkAcwBzAHUAZQANAE0AQwBpAF8AQwBUAEwADQBTAHQAaQBjAGsAIABhAGwA
bAAgADEAGSBzAA0AUAByAGUAdgBlAG4AdAAgAG0AbwBkAGUAbAAgAHMAcABlAGMAaQBmAGkAYwAg
AGkAcwBzAHUAZQANAE4AYQB0AGkAdgBlAGwAeQAgAG0AbwBzAHQAIABNAEMAaQBfAEMAVABMACAA
YgBpAHQAcwAgAGEAcgBlACAAGCBuAG8AdAAgAGkAbQBwAGwAZQBtAGUAbgB0ABkgLgAgAFAAcgBv
AGMAZQBzAHMAbwByACAAZABvAGUAcwAgAG4AbwB0ACAAdwByAGkAdABlACAAYwBoAGEAbgBnAGUA
cwAgAHQAbwAgAGIAaQB0AHMAIAB0AGgAYQB0ACAAYQByAGUAIABuAG8AdAAgAGkAbQBwAGwAZQBt
AGUAbgB0AHMADQBNAEMAaQBfAEMAVABMACAAYgBpAHQAcwAgAGEAcgBlACAAdQBzAHUAYQBsAGwA
eQAgAGYAbwByACAAaAAvAHcAIABkAGUAYgB1AGcAIABwAHUAcgBwAG8AcwBlACwAIABvAHMAIABu
AG8AcgBtAGEAbABsAHkAIABzAGUAdAAgAHQAaABlAG0AIABhAGwAbAAgADEAGSBzAC4ADQBJAGYA
IABnAHUAZQBzAHQAIABjAHIAYQB6AHkAIABjAGwAZQBhAHIAIABhAG4AeQAgAGIAaQB0ACwAIABq
AHUAcwB0ACAAdAByAGUAYQB0ACAAdABoAGUAIABiAGkAdAAgAGEAcwAgABggbgBvAHQAIABpAG0A
cABsAGUAbQBlAG4AdAAZIC4AIABHAHUAZQBzAHQAIAB3AG8AdQBsAGQAIABuAG8AdAAgAHMAdQBy
AHAAcgBpAHMAZQAuAAAAoQ9EAgAAFgAAAAAASTgKAAkAbgAAAFoAKAAHAAgAAAABANs4CgALANgA
AgBpAAAAWgAKAAcAdAAAAAIA2zgKAAsA2AACAGkAAABaAAoABwBnAAAAAwDbOAoACwDYAAIAaQAA
AFoACgAHACYAAAACANs4CgALANgAAgBpAAAAWgAKAAcAbwAAAAMAATgKAAEAAABaAAoABwCYAAAA
BAABOAoAAQAAAFoACgAHAGoAAAACANs4CgALANgAAgBpAAAAWgAKAAcACAAAAAEA2zgKAAsA2AAC
AGkAAABaAAoABwA1AAAAAgDbOAoACwDYAAIAaQAAAFoACgAHAAgAAAABANs4CgALANgAAgBpAAAA
WgAKAAcAKwAAAAIA2zgKAAsA2AACAGkAAABaAAoABwAeAQAAAwDbOAoACwDYAAIAaQAAAFoACgAH
ABYAAAAAACIABAAQAAgAAAAABCIAAAQEAA4AcQAAAAAIIgAACAQADAABAAAAAAgmAAAIBAAMAAAA
AAMCAAAAAAgiAAAIBAAMAGcAAAAACCIAAAgEAAoAIwAAAAAMIgAADAQADAABAAAAAAwmAAAMBAAM
AAykKf4CAAAAAAwiAAAMBAAMAG8AAAAAECIAABAEAAoAmAAAAAAUIgAAFAQACgBpAAAAABgiAAAY
BAAMAAEAAAAAGCIAABgEAAoACAAAAAAYIgAAGAQADgA1AAAAABwiAAAcBAAMAAgAAAAAHCIAABwE
AA4AKwAAAAAgIgAAIAQADAAeAQAAACQiAAAkBAAKAAAAqg/qAAAACgAAAAcAAAADAAkEBAi7AAAA
BgAAAAkEBAgEAAAABwAAAAMACQQECAIAAAAGAAAACQQECAsAAAAHAAAAAwAJBAQIjgAAAAYAAAAJ
BAQIAwAAAAcAAAADAAkEBAhmAQAABgAAAAkEBAgHAAAABwAAAAMACQQECDoAAAAGAAAACQQECAcA
AAAHAAAAAwAJBAQIXAAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAgWAAAABgAAAAkEBAgDAAAABwAA
AAMACQQECBAAAAAGAAAACQQECAIAAAAHAAAAAwAJBAQIewAAAAYAAAAJBAQIAACmDw4AAAD4AAAA
jgDUAdAC8AMQBQ8ABPBIAAAAEgAK8AgAAAAoEAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO
n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcA
psrhAFZ+uQAMLoYAqgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA
AIsTaQAAAAAA6y4IAAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMA
AAAAAAAAAAAAAAAAAAAAAMkK/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAA
IgQIAAAAAQAAAAYAAAAPAO4DaAoAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAHAAwwDwAM
BH8JAAAPAALwdwkAAEACCPAIAAAABQAAAAWcAAAPAAPwDwkAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA
AAAAAAAAAAAAAAAAAgAK8AgAAAAAnAAABQAAAA8ABPAgAQAAogwK8AgAAAACnAAAAAoAAMMAC/Bu
AAAAfwABAO8BgABENb4KgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgA
PwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAA
ABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAA
AAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcPCAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAA
AAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CwBAACiDArwCAAAAAOc
AAAACgAAwwAL8H4AAAB/AAEA7wGAAMzurgqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/
AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAA
bABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDwCAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAA
AAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgP
BAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQ
AvADEAUPAATwKgEAABIACvAIAAAABJwAACACAAATAQvwfgAAAAQAAAAAAH8AAQDvAYAAVBLACoEA
AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDAwQA
AD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAA
ywAOAWsVWQIPABHwEAAAAAAAwwsIAAAA/////w0AvgoPAA3wZAAAAAAAnw8EAAAAAAAAAAAAqA8a
AAAAUG9pbnQgMTogTVNSIGVtdWxhdGlvbiAoMikAAKEPGgAAABsAAAAAAAAICgABAAcAGwAAAAEA
IAAAAAQAAACqDwwAAAAbAAAABgAAAAkEBAgPAATwSQUAABIACvAIAAAABZwAACACAAATAQvwfgAA
AAQAAAAAAH8AAQDvAYAAGBTACoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgA
AAAAAL8ABAAEAP8BAAARAAEDBAQAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBu
AGcAbABlACAAMwAAAAAAEPAIAAAAZQJNAC0WsA4PABHwEAAAAAAAwwsIAAAA/////w4AwAoPAA3w
gwQAAAAAnw8EAAAAAQAAAAAAqA81AgAARXJyb3ItaW5mbyBpbnRlcmZhY2UNQSB0cmFuc2ZlciBs
YXllcg1GaWx0ZXIgbm9uLVNSQU8vU1JBUiBiYW5rcw1UcmFuc2xhdGUgaG9zdCBhZGRyZXNzIHRv
IGd1ZXN0IGFkZHJlc3MNRGVsaXZlcjoNRXZhbHVhdGUgYW5kIGRlbGl2ZXIgdGhlIG1vc3Qgc2V2
ZXJlIGVycm9yIHRvIHZjcHUwDQ1NQ0dfU1RBVFVTDUJpdDYzOjMgcmVzZXJ2ZWQsIHdybXNyIHNo
b3VsZCBiZSBzYW1lIGFzIHJkbXNyIG90aGVyd2lzZSBHUCMNDU1DaV9TVEFUVVMNQ2xlYXIgYnkg
d3JpdGluZyAwcywgd3JpdGluZyAxcyBjYXVzZXMgR1AjDQ1NQ2lfQUREUi9NQ2lfTUlTQw1FbXVs
YXRlZCBhcyBhbHdheXMgaW1wbGVtZW50ZWQgKG5vIHJkbXNyL3dybXNyIEdQIyBpc3N1ZSksIEFE
RFJWL01JU0NWPTAgbWVhbnMgbm8gYWRkci9pbmZvDUNsZWFyIGJ5IHdyaXRpbmcgMHMsIHdyaXRp
bmcgMXMgY2F1c2VzIEdQIw1UcmFuc2xhdGUgaG9zdCBhZGRyZXNzIHRvIGd1ZXN0IGFkZHJlc3MN
DU1DaV9DTFQyDUN1cnJlbnRseSBkZXNpZ25lZCBhcyBkaXNhYmxlZCBieSBNQ0dfQ01DSV9QPTAs
IHJkL3dybXNyIGNhdXNlIEdQIwAAoQ9MAQAAFQAAAAAAABAAAFoAEQAAAAEAABAKAFoABwBMAAAA
AgAAEAoAWgAHADUAAAADAAAQCgBaAAcACwAAAAEAABAKAFoABwA/AAAAAgAAEAoAWgAHAAsAAAAB
AAAQCgBaAAcALAAAAAIAABAAAFoAEgAAAAEAABAKAFoABwCwAAAAAgAAEAoAWgAHAAkAAAABAAAQ
CgBaAAcAQwAAAAIAABAKAFoABwAVAAAAAQAiAAAABAASABEAAAAABCIAAAQEABAATAAAAAAIIgAA
CAQADgA1AAAAAAwiAAAMBAAMAAsAAAAAECIAABAEABAAPwAAAAAQIgAAEAQADgALAAAAABQiAAAU
BAAQACwAAAAAFCIAABQEAA4AEgAAAAAYIgAAGAQAEACwAAAAABgiAAAYBAAOAAkAAAAAHCIAABwE
ABAAQwAAAAAgIgAAIAQADgAAAKoPwgAAAMQAAAAGAAAACQQECAUAAAAHAAAAAwAJBAQIEwAAAAYA
AAAJBAQIBQAAAAcAAAADAAkEBAgQAAAABgAAAAkEBAgKAAAABwAAAAMACQQECC0AAAAGAAAACQQE
CBEAAAAHAAAAAwAJBAQIJAAAAAYAAAAJBAQICwAAAAcAAAADAAkEBAgkAAAABgAAAAkEBAgEAAAA
BwAAAAMACQQECJYAAAAGAAAACQQECAUAAAAHAAAAAwAJBAQICwAAAAYAAAAJBAQIAACmDxQAAADw
HgAA1AEgAdACQALwA2ADEAWABA8ABPBIAAAAEgAK8AgAAAABnAAAAAwAAIMAC/AwAAAAgQEAAAAI
gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCo
AP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAA
UABUADEAMAAAAIsTaQAAAAAA6y4IAAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/Eg
AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAMkK/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAP
AAIrAAAAAA8A7gNXDAAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcADDAPAAwEbgsAAA8A
AvBmCwAA0AEI8AgAAAAFAAAABXQAAA8AA/D+CgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA
AAAAAAACAArwCAAAAAB0AAAFAAAADwAE8CABAACiDArwCAAAAAJ0AAAACgAAwwAL8G4AAAB/AAEA
7wGAALQWwAqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACA
wyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAA
XBC+D5gRqhAPAA3wggAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAA
AAIAAAABACYAAQADAAgAsrKy/gAA9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkE
AQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAA3QAAAAKAADD
AAvwfgAAAH8AAQDvAYAAFE/ACoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8B
EAAYAD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBl
AGgAbwBsAGQAZQByACAANAAAAAAAEPAIAAAAXRC4Dr4PqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAA
oA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAA
AAAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8A
BPAqAQAAEgAK8AgAAAAEdAAAIAIAABMBC/B+AAAABAAAAAAAfwABAO8BgAC8JMAKgQAAAAAAggAA
AAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA/wEAABEAAQMDBAAAPwMAAAgA
gMMYAAAAiAMAAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADLAA4BaxVZ
Ag8AEfAQAAAAAADDCwgAAAD/////DQDACg8ADfBkAAAAAACfDwQAAAAAAAAAAACoDxoAAABQb2lu
dCAxOiBNU1IgZW11bGF0aW9uICgzKQAAoQ8aAAAAGwAAAAAAAAgKAAEABwAbAAAAAQAgAAAABAAA
AKoPDAAAABsAAAAGAAAACQQECA8ABPA4BwAAEgAK8AgAAAAFdAAAIAIAABMBC/B+AAAABAAAAAAA
fwABAO8BgAA8XMAKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAE
AAQA/wEAABEAAQMEBAAAPwMAAAgAgMMYAAAAiAMAAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAAzAAAAAAAQ8AgAAABlAk0ALRawDg8AEfAQAAAAAADDCwgAAAD/////DgDACg8ADfByBgAAAACf
DwQAAAABAAAAAACgDxwEAABOAG8AIABuAG8AbgAtAGEAcgBjAGgAIABpAHMAcwB1AGUAcwAgAGEA
ZwBhAGkAbgANAEYAbwByACAAZgBhAG0AaQBsAHkALQBtAG8AZABlAGwAIABpAHMAcwB1AGUAcwAg
AHIAbwBvAHQAIABmAHIAbwBtACAAbABlAGcAYQBjAHkAIABwAHIAbwBjAGUAcwBzAG8AcgBzAA0A
RABvAG4AGSB0ACAAYwBhAHIAZQAsACAAZwB1AGUAcwB0ACAAdwBvAHUAbABkACAAbgBvAHQAIABz
AHUAcgBwAHIAaQBzAGUADQBHAHUAZQBzAHQAIABwAHIAbwBiAGUAIABtAGMAZQAgAGMAYQBwAGEA
YgBpAGwAaQB0AGkAZQBzACAAdgBpAGEAIABNAEMARwBfAEMAQQBQACwAIABuAG8AdAAgAGMAcAB1
AGkAZAANAA0ARgBvAHIAIABtAG8AZABlAGwALQBzAHAAZQBjAGkAZgBpAGMAIABpAHMAcwB1AGUA
cwANADIAIABtAG8AZABlAGwALQBzAHAAZQBjAGkAZgBpAGMAIABmAGkAZQBsAGQAcwANAE0AQwBH
AF8AQwBUAEwALwBNAEMAaQBfAEMAVABMAA0ATQBDAGkAXwBTAFQAQQBUAFUAUwAgABMgIABNAFMA
QwBPAEQAIABtAG8AZABlAGwAIABzAHAAZQBjAGkAZgBpAGMAIABlAHIAcgBvAHIAIABjAG8AZABl
AA0ADQBGAG8AcgAgAE0AQwBHAF8AQwBUAEwALwBNAEMAaQBfAEMAVABMAA0ARgBvAHIAIABNAEMA
RwBfAEMAVABMACwAIABkAGkAcwBhAGIAbABlACAAaQB0ACAAdgBpAGEAIABNAEMARwBfAEMAVABM
AF8AUAAgAD0AIAAwAA0ARgBvAHIAIABNAEMAaQBfAEMAVABMAA0AUwB0AGkAYwBrACAAYQBsAGwA
IAAxABkgcwANAEkAZgAgAGcAdQBlAHMAdAAgAGMAcgBhAHoAeQAgAHcAcgBpAHQAZQAgAGIAaQB0
ACAAdABvACAAMAAsACAAdAByAGUAYQB0ACAAaQB0ACAAYQBzACAAGCBuAG8AdAAgAGkAbQBwAGwA
ZQBtAGUAbgB0ABkgIABiAGkAdAAgAGEAbgBkACAAcwBpAG0AcABsAHkAIABpAGcAbgBvAHIAZQAg
AHcAcgBpAHQAZQANAA0ARgBvAHIAIABNAEMAaQBfAFMAVABBAFQAVQBTACAAGCBNAFMAQwBPAEQA
GSAgAG0AbwBkAGUAbAAgAHMAcABlAGMAaQBmAGkAYwAgAGUAcgByAG8AcgAgAGMAbwBkAGUADQBT
AHQAaQBjAGsAIABhAGwAbAAgADAAGSBzACAAdABvACAAZwB1AGUAcwB0AAAAoQ9UAQAAGQAAAAAA
AAAKAAcANAAAAAEAAAAKAAcAWQAAAAIAAAAKAAcAAQAAAAIAAQAKAAAABwAaAAAAAQAAAAoABwAY
AAAAAgAAAAoABwA9AAAAAwAAAAoABwABAAAABAABAAoAAAAHABQAAAACAAAACgAHADYAAAADAAAA
CgAHAGUAAAAEAAAACgAHAAEAAAAEAAEACgAAAAcAMQAAAAIAAAAKAAcAFwAAAAMAAAAAABkAAAAB
ACAAAAAEADQAAAAABCAAAAQEAFkAAAAACCAAAAgEAAEAAAAADCAAAAwEABoAAAAADCAAAAwEABgA
AAAAECAAABAEAD0AAAAAFCAAABQEAAEAAAAAGCAAABgEABQAAAAAHCAAABwEADYAAAAAICAAACAE
AGUAAAAAJCAAACQEAAEAAAAAKCAAACgEADEAAAAALCAAACwEABcAAAAAMCAAADAEAAAAqg/CAAAA
fgAAAAYAAAAJBAQIAwAAAAcAAAADAAkEBAgfAAAABgAAAAkEBAgFAAAABwAAAAMACQQECDwAAAAG
AAAACQQECAcAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQICgAAAAcAAAADAAkEBAgwAAAABgAAAAkE
BAgHAAAABwAAAAMACQQECC8AAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIawAAAAYAAAAJBAQICgAA
AAcAAAADAAkEBAg6AAAABgAAAAkEBAgAAKYPFAAAAPAeAADUASAB0AJAAvADYAMQBYAEDwAE8EgA
AAASAArwCAAAAAF0AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/
AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAIYKgA/1xHAPXmRwCmyuEAVn65AAwuhgCqAUwA
DwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAC/
+scB0KOF6wAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA
yQr/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuA84LAAACAO8DGAAAABAA
AAAAAAAAAAAAAAAAAIABAQAABwAMMA8ADATVCgAADwAC8M0KAAAQAQjwCAAAAAUAAAAGFAAADwAD
8GUKAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABQAAAUAAAAPAATw
IAEAAKIMCvAIAAAAAhQAAAAKAADDAAvwbgAAAH8AAQDvAYAAgGbACoEAAAAAAIIAAAAAAIMAAAAA
AIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0AGUAIABQAGwA
YQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4PmBGqEA8ADfCCAAAAAACfDwQAAAAE
AAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AAD3DwgA
AAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADU
AdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADFAAAAAoAAMMAC/B+AAAAfwABAO8BgAAMbcAKgQAAAAAA
ggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMM2AAAAvwMAAAIAUwBs
AGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA0AAAAAAAQ8AgA
AABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgA
AAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAAEQQJBAEA
AAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CEBAAASAArwCAAAAAQUAAAgAgAAAwEL
8HgAAAAEAAAAAAB/AAEA7wGAAIymwAqBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAAAACHAAAA
AACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBn
AGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR8BAAAAAAAMMLCAAAAP////8NAMAKDwAN8GEA
AAAAAJ8PBAAAAAAAAAAAAKgPFwAAAFBvaW50IDI6IGxpdmUgbWlncmF0aW9uAAChDxoAAAAYAAAA
AAAACAoAAQAHABgAAAABACAAAAAEAAAAqg8MAAAAGAAAAAYAAAAJBAQIDwAE8KgGAAASAArwCAAA
AAUUAAAgAgAAAwEL8HgAAAAEAAAAAAB/AAEA7wGAACiqwAqBAAAAAACCAAAAAACDAAAAAACEAAAA
AACFAAAAAACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwQEAAA/AwAACACAwxgAAAC/AwAAAgBS
AGUAYwB0AGEAbgBnAGwAZQAgADMAAAAAABDwCAAAAIQCmQDsFZcODwAR8BAAAAAAAMMLCAAAAP//
//8OAMAKDwAN8OgFAAAAAJ8PBAAAAAEAAAAAAKAPngMAAGwAaQB2AGUAIABtAGkAZwByAGEAdABp
AG8AbgAgAGkAcwBzAHUAZQA6AA0AaQBmACAAbQBpAGcAcgBhAHQAZQAgAGYAcgBvAG0AIABBACAA
KABsAGEAcgBnAGUAIABiAGEAbgBrACkAIAB0AG8AIABCACAAKABzAG0AYQBsAGwAIABiAGEAbgBr
ACkADQB3AGkAbABsACAARwBQACMAIABhAHQAIABCACAAdwBoAGUAbgAgAGEAYwBjAGUAcwBzACAA
TQBDAGkAXwBDAFQATAANAEoAYQBuABkgcwAgAHAAYQB0AGMAaAAgAHAAYQByAHQAbAB5ACAAcwBv
AGwAdgBlACAAcAByAG8AYgBsAGUAbQAgAGIAeQAgAHMAYQB2AGUALwByAGUAcwB0AG8AcgBlACAA
TQBDAEcAXwBDAEEAUAAsACAAYQB2AG8AaQBkACAARwBQACMADQBCAHUAdAAgAEIAIABjAGEAbgAg
AG8AbgBsAHkAIAByAC8AdwAgAHMAbwBtAGUAIABNAEMAaQBfAEMAVABMACAAYQBmAHQAZQByACAA
bQBpAGcAcgBhAHQAZQANAA0AYQBwAHAAcgBvAGEAYwBoADoADQBOAG8AdABoAGkAbgBnACAAcwBw
AGUAYwBpAGEAbAAgAG4AZQBlAGQAIAB0AG8AIABkAG8ADQBGAG8AcgAgAGUAcgByAG8AcgAtAGkA
bgBmAG8AIABNAFMAUgBzAA0AcABvAGkAbgB0AGwAZQBzAHMAIAB0AG8AIABiAGUAIABtAGkAZwBy
AGEAdABlAGQADQBGAG8AcgAgAGkAbgBpAHQAJgBwAHIAbwBiAGUAIABNAFMAUgBzAA0ATQBDAEcA
XwBDAEEAUAAgAGkAcwAgAHUAbgBpAGYAaQBlAGQAIABhAHQAIABhAG4AeQAgAHAAbABhAHQAZgBv
AHIAbQANADEAIABiAGEAbgBrACwAIABuAG8AIABHAFAAIwAgAHAAcgBvAGIAbABlAG0AIABjAGEA
dQBzAGUAZAAgAGIAeQAgAGIAYQBuAGsAIABuAHUAbQBiAGUAcgANAEYAbwByACAATQBDAEcAXwBD
AFQATAAvAE0AQwBpAF8AQwBUAEwADQBNAEMARwBfAEMAVABMACAAZABpAHMAYQBiAGwAZQBkAA0A
TQBDAGkAXwBDAFQATAAgAHMAdABpAGMAawAgAHQAbwAgAGEAbABsACAAMQAZIHMAAAChDy4BAAAW
AAAAAAAAAAoABwAxAAAAAQAAAAoABwCVAAAAAgAAAAoABwAKAAAAAAAAAAoABwAbAAAAAQAAAAoA
BwAUAAAAAgAAAAoABwAZAAAAAwAAAAoABwAUAAAAAgAAAAoABwAjAAAAAwAAAAoABwAtAAAABAAA
AAoABwAUAAAAAwAAAAoABwAqAAAABAAAAAoABwAWAAAAAQAgAAAABAAxAAAAAAQgAAAEBACVAAAA
AAggAAAIBAAJAAAAAQwgAAAMBAABAAAAAAwgAAEMBAAbAAAAABAgAAAQBAAUAAAAABQgAAAUBAAZ
AAAAABQgAAAUBAAUAAAAABggAAAYBAAjAAAAABwgAAAcBAAtAAAAABwgAAAcBAAUAAAAACAgAAAg
BAAqAAAAACSgAAAkBAACAAAAqg/cAAAAYQAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAhUAAAABgAA
AAkEBAgDAAAABwAAAAMACQQECAYAAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIRAAAAAYAAAAJBAQI
BAAAAAcAAAADAAkEBAgeAAAABgAAAAkEBAgKAAAABwAAAAMACQQECAEAAAAGAAAACQQECAQAAAAH
AAAAAwAJBAQIXQAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAgSAAAABgAAAAkEBAgHAAAABwAAAAMA
CQQECBIAAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQPAATwSAAAABIACvAI
AAAABhQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD
CQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgTkQAA
AA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAL/6xwHQo4Xr
AAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADACv////8S
AAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAACIECAAAAAEAAAAGAAAADwDuA9kIAAAC
AO8DGAAAABAAAAAAAAAAAAAAAAAAAIADAQAABwAMMA8ADATwBwAADwAC8OgHAADgAQjwCAAAAAUA
AAAFeAAADwAD8IAHAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAHgA
AAUAAAAPAATwIAEAAKIMCvAIAAAAAngAAAAKAADDAAvwbgAAAH8AAQDvAYAA8MTACoEAAAAAAIIA
AAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0
AGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4PmBGqEA8ADfCCAAAA
AACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACy
srL+AAD3DwgAAAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYP
DAAAAPAAAADUAdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADeAAAAAoAAMMAC/B+AAAAfwABAO8BgAAU
4L4KgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMM2AAAA
vwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA0
AAAAAAAQ8AgAAABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAA
AgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAA
AAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CYBAAASAArwCAAAAAR4
AAAgAgAAEwEL8H4AAAAEAAAAAAB/AAEA7wGAAOTxwAqBAAAAAACCAAAAAACDAAAAAACEAAAAAACF
AAAAAACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgAAACIAwAAAAC/AwAA
AgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR8BAAAAAAAMMLCAAA
AP////8NAMAKDwAN8GAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFBvaW50IDM6IE1DRSBpbmplY3Rp
b24AAKEPGgAAABcAAAAAAAAICgABAAcAFwAAAAEAIAAAAAQAAACqDwwAAAAXAAAABgAAAAkEBAgP
AATwvgMAABIACvAIAAAABXgAACACAAAjAQvwhAAAAAQAAAAAAH8AAQDvAYAAEADBCoEAAAAAAIIA
AAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAL8BAAABAP8BAAARAAEDBAQA
AD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAA
hAJRASEVlw4PABHwEAAAAAAAwwsIAAAA/////w4AwAoPAA3w8gIAAAAAnw8EAAAAAQAAAAAAqA9Q
AQAASW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzDUFueSByaXNrIHdoZW4gdmNwdXMgPiBwY3B1cywg
YW5kIGluamVjdGlvbnMgb2NjdXIgYXQgYSBsb25nIHRpbWUgd2luZG93Pw1Gb3Igd2luOCwgdGVz
dCBpbmRpY2F0ZSBvaw1Gb3IgbGludXgsIGl0IGNhbiB0b2xlcmF0ZSB0aGlzIGNhc2UgKFRvbnkg
THVjaykNRm9yIFNvbGFyaXMsIGl0IGNhbiB0b2xlcmF0ZSB0aGlzIGNhc2UgKEFzaG9rKQ1Db25j
ZXJuOiBoeXBlcnZpc29yIHNob3VsZCBiZSBndWVzdCBhZ25vc3RpYw1BcHByb2FjaCBmb3IgdmNw
dXMgPiBwY3B1cw1Ub2xlcmF0ZSBpdA1Xb3JzdCBjYXNlIGlzIGd1ZXN0IGtpbGwgaXRzZWxmAACh
D6AAAAAZAAAAAAAAAAoABwBJAAAAAQAAAAoABwCoAAAAAgAAAAoABwAbAAAAAQAAAAoABwAMAAAA
AgAAAAoABwAgAAAAAwAAAAoABwAZAAAAAQAgAAAABABJAAAAAAQgAAAEBACoAAAAAAQgAAAEBAAa
AAAAAAggAAAIBAABAAAAAAgkAAAIBAAAAAACDAAAAAAMIAAADAQAIAAAAAAQIAAAEAQAAACqD8IA
AAAHAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAgAAAAGAAAACQQECAUAAAAHAAAAAwAJBAQIDwAA
AAYAAAAJBAQIBQAAAAcAAAADAAkEBAgDAAAABgAAAAkEBAgFAAAABwAAAAMACQQECE0AAAAGAAAA
CQQECAUAAAAHAAAAAwAJBAQIkQAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgDAAAABgAAAAkEBAgF
AAAABwAAAAMACQQECC0AAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQPAATw
SAAAABIACvAIAAAAAXgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS
AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoB
TAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAA
AL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA
AADACv////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DSgUAAAIA7wMYAAAA
EAAAAAAAAAAAAAAAAAAAgAAAAAAHAAwwDwAMBGEEAAAPAALwWQQAAMACCPAIAAAABAAAAAS8AAAP
AAPw8QMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAvAAABQAAAA8A
BPAgAQAAogwK8AgAAAACvAAAAAoAAMMAC/BuAAAAfwABAO8BgACYJcEKgQAAAAAAggAAAAAAgwAA
AAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAA
bABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8PBAAA
AAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcP
CAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAA
ANQB0ALwAxAFDwAE8CwBAACiDArwCAAAAAO8AAAACgAAwwAL8H4AAAB/AAEA7wGAAJT9wAqBAAAA
AACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBT
AGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDw
CAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAA
CAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkE
AQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwXQEAABIACvAIAAAABLwAACACAAAT
AQvwfgAAAAQAAAAAAH8AAQDvAYAAMDLBCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcA
AAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDBAQAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBj
AHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAYwSfAPIVqAkPABHwEAAAAAAAwwsIAAAA/////w4A
wQoPAA3wlwAAAAAAnw8EAAAAAQAAAAAAqA8HAAAAQmFja3VwDQAAoQ9EAAAABwAAAAAAAQgKAAgA
AQAHAAEAAAABAAAACgAHAAYAAAABACIAAAAEACQAAQAAAAAAIgAEACQAAQAAAAAEIgAABAQAJAAA
AKoPDAAAAAgAAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQPAATwSAAAABIA
CvAIAAAAAbwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI
AAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgT
kQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAL/6xwHQ
o4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADACv//
//8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfhMAAAIA7wMYAAAAEAAAAAAA
AAAAAAAAAAAAgAsBAAAHAAwwDwAMBJUSAAAPAALwjRIAAPACCPAIAAAAEgAAABLMAAAPAAPwJRIA
AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAzAAABQAAAA8ABPAgAQAA
ogwK8AgAAAACzAAAAAoAAMMAC/BuAAAAfwABAO8BgAAIQcEKgQAAAAAAggAAAAAAgwAAAAAAhAAA
AAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMA
ZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQ5Aq+DKoQDwAN8IIAAAAAAJ8PBAAAAAQAAAAA
AKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcPCAAAAAAA
AAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALw
AxAFDwAE8CwBAACiDArwCAAAAAPMAAAACgAAwwAL8H4AAAB/AAEA7wGAAHBMwQqBAAAAAACCAAAA
AACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwAaQBk
AGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDwCAAAAF0Q
3gnkCqoQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAAC
AAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYA
AAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwMgEAABIACvAIAAAABMwAACACAAATAQvwfgAA
AAQAAAAAAH8AAQDvAYAAFFbBCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgA
AAAAAL8ABAAEAP8BAAARAAEDAwQAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBu
AGcAbABlACAAMgAAAAAAEPAIAAAAywAOAWsVQgIPABHwEAAAAAAAwwsIAAAA/////w0AwQoPAA3w
bAAAAAAAnw8EAAAAAAAAAAAAqA8IAAAATUNFIE1TUnMAAKEPGgAAAAkAAAAAAAAICgABAAcACQAA
AAEAIAAAAAQAAACqDyYAAAAEAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAGAAAACQQECA8A
BPD9AAAAogwK8AgAAAAFzAAAAAoAALMAC/BYAAAAfwAAAO8BgABsWsEKvwAGAAYAgQEMpCkAvwEQ
ABAAwAEMpCkAywFwxgAA/wEIABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAA
NgAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAADJB6cERAnQCA8ADfBnAAAAAACfDwQAAAAEAAAAAACo
DwcAAABNQ0dfQ0FQAAChDxwAAAAIAAAAAAAAIAAAMgAIAAAAAAAmAAQAEgAAAAADAACqDwwAAAAI
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPD9AAAAogwK8AgAAAAGzAAAAAoAALMA
C/BYAAAAfwAAAO8BgACoZMEKvwAGAAYAgQEMpCkAvwEQABAAwAEMpCkAywFwxgAA/wEIABgAPwMA
AAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwAAABMAIvEGAAAA/wEAAEAAAAAQ8AgA
AAB0CakERgl7Cg8ADfBnAAAAAACfDwQAAAAEAAAAAACoDwcAAABNQ0dfQ1RMAAChDxwAAAAIAAAA
AAAAIAAAMgAIAAAAAAAmAAQAEgAAAAADAACqDwwAAAAIAAAABgAAAAkEBAgAAKYPDAAAAPAAAADU
AdAC8AMQBQ8ABPAAAQAAogwK8AgAAAAHzAAAAAoAALMAC/BYAAAAfwAAAO8BgABEb8EKvwAGAAYA
gQECAAAIvwEQABAAwAECAAAIywFwxgAA/wEIABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAg
AEIAbwB4ACAAOAAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAAApC60ESgkwDA8ADfBqAAAAAACfDwQA
AAAEAAAAAACoDwoAAABNQ0dfU1RBVFVTAAChDxwAAAALAAAAAAAAIAAAMgALAAAAAAAmAAQAEgAA
AAADAACqDwwAAAALAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPALAQAAogwK8AgA
AAAIzAAAAAoAALMAC/BYAAAAfwAAAO8BgAAkeMEKvwAGAAYAgQEMpCkAvwEQABAAwAEMpCkAywFw
xgAA/wEIABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAOQAAABMAIvEGAAAA
/wEAAEAAAAAQ8AgAAAAcBvYJkw4jBw8ADfB1AAAAAACfDwQAAAAEAAAAAACoDwcAAABNQ2lfQ1RM
AAChDxwAAAAIAAAAAAAAIAAAMgAIAAAAAAAmAAQAEgAAAAADAACqDxoAAAAHAAAABwAAAAMACQQE
CAEAAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BABAACiDArwCAAAAAnMAAAACgAA
swAL8FoAAAB/AAAA7wGAABiCwQq/AAYABgCBAQIAAAi/ARAAEADAAQIAAAjLAXDGAAD/AQgAGAA/
AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADAAAAATACLxBgAAAP8BAABAAAAA
EPAIAAAAyQfzCZAO0AgPAA3weAAAAAAAnw8EAAAABAAAAAAAqA8KAAAATUNpX1NUQVRVUwAAoQ8c
AAAACwAAAAAAACAAADIACwAAAAAAJgAEABIAAAAAAwAAqg8aAAAACgAAAAcAAAADAAkEBAgBAAAA
BgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAOAQAAogwK8AgAAAAKzAAAAAoAALMAC/Ba
AAAAfwAAAO8BgAAMjMEKvwAGAAYAgQECAAAIvwEQABAAwAECAAAIywFwxgAA/wEIABgAPwMAAAgA
gMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQAxAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAA
AHQJ9QmSDnsKDwAN8HYAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAE1DaV9BRERSAAChDxwAAAAJAAAA
AAAAIAAAMgAJAAAAAAAmAAQAEgAAAAADAACqDxoAAAAIAAAABwAAAAMACQQECAEAAAAGAAAACQQE
CAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8A4BAACiDArwCAAAAAvMAAAACgAAswAL8FoAAAB/AAAA
7wGAAFCWwQq/AAYABgCBAQIAAAi/ARAAEADAAQIAAAjLAXDGAAD/AQgAGAA/AwAACACAwxgAAAC/
AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADIAAAATACLxBgAAAP8BAABAAAAAEPAIAAAAKQv5CZYO
MAwPAA3wdgAAAAAAnw8EAAAABAAAAAAAqA8IAAAATUNpX01JU0MAAKEPHAAAAAkAAAAAAAAgAAAy
AAkAAAAAACYABAASAAAAAAMAAKoPGgAAAAgAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIAACmDwwA
AADwAAAA1AHQAvADEAUPAATwhgAAAEIBCvAIAAAADMwAAAAKAADTAAvwXgAAAH8AAADvAYUAAgAA
AIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAQAACMsBcMYAAM4BBgAAAP8BGAAYAD8DCAAIAIDD
EAAAAL8DAAACAEwAaQBuAGUAIAAxADMAAAAAABDwCAAAABgEqAmoCa4MDwAE8OwAAACiDArwCAAA
AA3MAAAACgAAkwAL8E4AAAB/AAAA7wGAALShwQq/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/AwAA
CACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADQAAAATACLxBgAAAP8BAABAAAAAEPAI
AAAA/wxbBMwJHw4PAA3wYAAAAAAAnw8EAAAABAAAAAAAqA8GAAAAZ2xvYmFsAAChDxYAAAAHAAAA
AAAAIAAAMgAHAAAAAAAgAAQAAACqDwwAAAAHAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQ
BQ8ABPDuAAAAogwK8AgAAAAOzAAAAAoAAJMAC/BOAAAAfwAAAO8BgADgqsEKvwAGAAYAvwEAABEA
ywFwxgAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQA1AAAAEwAi
8QYAAAD/AQAAQAAAABDwCAAAANwM6Ql7DvwNDwAN8GIAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAHBl
ci1iYW5rAAChDxYAAAAJAAAAAAAAIAAAMgAJAAAAAAAgAAQAAACqDwwAAAAJAAAABgAAAAkEBAgA
AKYPDAAAAPAAAADUAdAC8AMQBQ8ABPADAQAAogwK8AgAAAAPzAAAAAoAALMAC/BaAAAAfwAAAO8B
gABAtsEKvwAGAAYAvwEAABEAwAECAAAIywFwxgAAzgECAAAA/wEIABgAPwMAAAgAgMMYAAAAvwMA
AAIAVABlAHgAdAAgAEIAbwB4ACAAMQA2AAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAHEE+AmVDngF
DwAN8GsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAE1DaV9DVEwyICoqAAChDxwAAAAMAAAAAAAAIAAA
MgAMAAAAAAAmAAQAEgAAAAADAACqDwwAAAAMAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQ
BQ8ABPAHAQAAogwK8AgAAAAQzAAAAAoAAJMAC/BOAAAAfwAAAO8BgABgwMEKvwAGAAYAvwEAABEA
ywFwxgAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQA3AAAAEwAi
8QYAAAD/AQAAQAAAABDwCAAAAOECuQYqDAEEDwAN8HsAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAAHBl
ci1jcHUAAKEPFgAAAAgAAAAAAAAgAAAyAAgAAAAAACAABAAAAKoPJgAAAAQAAAAGAAAACQQECAMA
AAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwMQEAAKIMCvAI
AAAAEcwAAAAKAACzAAvwWgAAAH8AAADvAYAA1MrBCr8ABgAGAIEBDKQpAL8BEAAQAMABDKQpAMsB
cMYAAP8BCAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADEAMAAAABMAIvEG
AAAA/wEAAEAAAAAQ8AgAAAAPCNQRXRVPCQ8ADfCZAAAAAACfDwQAAAAEAAAAAACoDxEAAABJbml0
JnByb2JlIE1TUnMgKgAAoQ8cAAAAEgAAAAAAACAAADIAEgAAAAAAJgAEAAwAAAAAAwAAqg80AAAA
CgAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAMAAAAGAAAACQQECAAApg8M
AAAA8AAAANQB0ALwAxAFDwAE8CMBAACiDArwCAAAABLMAAAACgAAswAL8FoAAAB/AAAA7wGAAHDV
wQq/AAYABgCBAQIAAAi/ARAAEADAAQIAAAjLAXDGAAD/AQgAGAA/AwAACACAwxgAAAC/AwAAAgBU
AGUAeAB0ACAAQgBvAHgAIAAxADAAAAATACLxBgAAAP8BAABAAAAAEPAIAAAAzwnYEWEVDwsPAA3w
iwAAAAAAnw8EAAAABAAAAAAAqA8RAAAARXJyb3ItaW5mbyBNU1JzICoAAKEPHAAAABIAAAAAAAAg
AAAyABIAAAAAACYABAAMAAAAAAMAAKoPJgAAAAsAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIAwAA
AAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwSAAAABIACvAIAAAAAcwAAAAMAACDAAvw
MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg
AAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgTkQAAAA8AihOJAAAAAAC6DxAA
AABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE
8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADACv////8SAAAADwA98Q0AAABAAULx
BQAAAAEJAAAADwACKwAAAAAPAO4DndwAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAoBAAAHAAww
AAD5AxAAAAAAAAAAAAAAAAIAAQACvU4wDwAMBKzbAAAPAALwpNsAANACCPAIAAAAMgAAADfAAAAP
AAPwPNsAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAwAAABQAAAA8A
BPAwAQAAEgAK8AgAAAACwAAAIAIAABMBC/B2AAAABAAAAAAAfwABAO8BgADA4cEKgQAAAAAAggAA
AAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA/wEQABEAAQMDBAAAPwMAAAgA
gMMQAAAAiAMAAAAAvwMAAAIAVABpAHQAbABlACAAMwAAAAAAEPAIAAAAbAACAV8V+gEPABHwEAAA
AAAAwwsIAAAA/////w0AwQoPAA3wcgAAAAAAnw8EAAAAAAAAAAAAqA8OAAAAWGVuIFJBUyBzdGF0
dXMAAKEPGAAAAA8AAAAAAAAIAAABAA8AAAABACAAAAAEAAAAqg8oAAAAAwAAAAcAAAADAAkEBAgL
AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBA8AA/Bw1wAADwAE8IgAAAABAAnwEAAAANIAAACcAQAA
EhYAACcPAAACAArwCAAAADfAAAABAgAAEwAL8AYAAAB/AAABAAEjACLxOgAAAJ8DAQAAAKDDLgAA
AAoADAAEAO8AAAB7AQAAcAEAAHABAABcAQAATAEAAGYBAABnAQAAZgEAAGYBAAAAABDwCAAAAJwB
0gASFicPDwAE8GIFAAASAArwCAAAAATAAAACCgAAgwAL8DAAAAB/AAAABACAAHTwwQq/AAQABACB
AUWCywCDAQAAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx5QMAAL8BAABgAKmD2QMAAFBLAwQUAAYA
CAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pT
OCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8Ud
KEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyK
tN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7
ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNb
odfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZu
pHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFO
YQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBL
AwQUAAYACAAAACEAieLxydgAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X6D9ZU
6qYqTquKVCkGIfoAITaELtrdEE/iqPE4sg2Ev6/Fol3euaNzdSazwXbiSD60jhU8jDIQxJXTLTcK
Pnfv988gQkTW2DkmBWcKMJteX02w0O7EWzqWsREJwqFABSbGvpAyVIYshpHriVNXO28xpugbqT2e
Etx28jHLxtJiy2nBYE8LQ9VPebAK3r7K/O4jX+j5xnwfxvvdalm/Pil1ezPMX0BEGuL/8zrm5Ub/
lRfUSitIJvXyvPet3mKI5C+XZJosQU5/AQAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAIni
8cnYAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAMAwAAAAAAAA/wEAAAAGQMAABbDAAAEhYAAMENAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAA
ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAA
ug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfCH
AAAAAACfDwQAAAAHAAAAAACoDxsAAABEb20wIGFuZCBoeXBlcnZpc29yIGNvLXdvcmsAAKEPHgAA
ABwAAAAAAAEgAAAIAAAAHAAAAAAAJgAEAA4ABgkO/gAAqg8MAAAAHAAAAAYAAAAJBAQIAACmDxYA
AAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8EoFAAASAArwCAAAAAXAAAACCgAAgwAL8DAAAAB/
AAAABACAANjwwQq/AAQABACBAUWCywCDAQAAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx5QMAAL8B
AABgAKmD2QMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54
bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK
4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OM
KZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQy
J487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJt
pY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8Fq
wzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2
HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF
+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6
dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAtLPQJtgAAAD5AAAADwAAAGRycy9kb3ducmV2
LnhtbESPy27CMBBF90j8gzVI3VTFoaqgTTEI0QdU6obAot0N8SS2iO3INhD+vhaLsrxzR+fqTOed
adiJfNDOChgNM2BkSye1rQXsth8Pz8BCRCuxcZYEXCjAfNbvTTGX7mw3dCpizRLEhhwFqBjbnPNQ
KjIYhq4lm7rKeYMxRV9z6fGc4Kbhj1k25ga1TQsKW1oqKg/F0Qh4/ykm95+TpVx8q9/jeL9dr6q3
JyHuBt3iFVikLt6eg/562RX/5RW1lgKSSbW67L2WGwyR/PWSTJMl8NkfAAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhALSz0CbYAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAMAwAAAAAAAA/wEAAAALAHAABbDAAAZAwAAMENAAAPABHwfgAA
AA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAA
AAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAA
AAAAEAAAAAAAAAAAAA8ADfBvAAAAAACfDwQAAAAHAAAAAACoDwMAAABOL0EAAKEPHgAAAAQAAAAA
AAEgAAAIAAAABAAAAAAAJgAEAA4ABgkO/gAAqg8MAAAABAAAAAYAAAAJBAQIAACmDxYAAAD4HgAA
AADUASAB0AJAAvADYAMQBYAEDwAE8FQFAAASAArwCAAAAAbAAAACCgAAgwAL8DAAAAB/AAAABACA
AFAEwwq/AAQABACBAUWCywCDAQAAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx5AMAAL8BAABgAKmD
2AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9O
wzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1W
oIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHN
DgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487Mrog
V1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8A
AAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7
YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwv
x7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773
/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODT
M+MvAAAA//8DAFBLAwQUAAYACAAAACEAt6V+AdcAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESP
y07DMBBF90j8gzVIbBB1ilCLQt2qKo92waYpC9hN4kkcEY8j22nTv8fqApZ37uhcncVqtJ04kg+t
YwXTSQaCuHK65UbB5+Ht/glEiMgaO8ek4EwBVsvrqwXm2p14T8ciNiJBOOSowMTY51KGypDFMHE9
cepq5y3GFH0jtcdTgttOPmTZTFpsOS0Y7GljqPopBqvg9auY373PN3r9Yb6HWXnYbeuXR6Vub8b1
M4hIY/x/xqGcEv2VF9ROK0gm9fZc+lbvMUTyl0syTZYgl78AAAD//wMAUEsBAi0AFAAGAAgAAAAh
ANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAU
AAYACAAAACEAt6V+AdcAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsF
BgAAAAADAAMAtwAAAAsDAAAAAAAAD/AQAAAA0gAAAFsMAACwBwAAwQ0AAA8AEfB+AAAADwCIE3YA
AAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAAB
AA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAA
AAAAAAAADwAN8HoAAAAAAJ8PBAAAAAcAAAAAAKgPDgAAAEFQRUkgSEVTVC9HSEVTAAChDx4AAAAP
AAAAAAABIAAACAAAAA8AAAAAACYABAAOAAYJDv4AAKoPDAAAAA8AAAAGAAAACQQECAAApg8WAAAA
+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPD/BQAAEgAK8AgAAAAHwAAAAgoAAIMAC/AwAAAAfwAA
AAQAgADoE8MKvwAEAAQAgQGWlpYAgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8d8DAACpg9kD
AABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMw
DIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCI
jbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H
0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZ
A/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA
//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2Dv
YHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3
DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e
5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPj
LwAAAP//AwBQSwMEFAAGAAgAAAAhAIni8cnYAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tu
wjAQRfeV+g/WVOqmKk6rilQpBiH6ACE2hC7a3RBP4qjxOLINhL+vxaJd3rmjc3Ums8F24kg+tI4V
PIwyEMSV0y03Cj537/fPIEJE1tg5JgVnCjCbXl9NsNDuxFs6lrERCcKhQAUmxr6QMlSGLIaR64lT
VztvMaboG6k9nhLcdvIxy8bSYstpwWBPC0PVT3mwCt6+yvzuI1/o+cZ8H8b73WpZvz4pdXszzF9A
RBri//M65uVG/5UX1EorSCb18rz3rd5iiOQvl2SaLEFOfwEAAP//AwBQSwECLQAUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQA
BgAIAAAAIQCJ4vHJ2AAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUG
AAAAAAMAAwC3AAAADAMAAAAAAAAP8BAAAABkDAAAwQ0AABIWAAAnDwAADwAR8H4AAAAPAIgTdgAA
AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEA
DwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAA
AAAAAAAPAA3wKgEAAAAAnw8EAAAABwAAAAAAqA9IAAAAbWNlbG9nLCBjcHUgb25saW5lL29mZmxp
bmUgZG9uZTsgICAgICAgY3B1IGhvdGFkZCwgbWVtb3J5IGhvdGFkZCBvbmdvaW5nAAChDx4AAABJ
AAAAAAABIAAACAAAAEkAAAAAACYABAAOAAYJDv4AAKoPggAAAAYAAAAHAAAAAwAJBAQIAgAAAAYA
AAAJBAQIAwAAAAcAAAADAAkEBAgcAAAABgAAAAkEBAgDAAAABwAAAAMACQQECAEAAAAGAAAACQQE
CAYAAAAHAAAAAwAJBAQICQAAAAYAAAAJBAQIBgAAAAcAAAADAAkEBAgJAAAABgAAAAkEBAgAAKYP
FgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwRAUAABIACvAIAAAACMAAAAIKAACDAAvwMAAA
AH8AAAAEAIAAMA7DCr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHfAwAA
qYPZAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQ
z07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdw
XVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQ
Ac0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsy
uiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09s
vwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG
4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4t
XC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcT
vvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA4
4NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC0s9Am2AAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1s
RI/LbsIwEEX3SPyDNUjdVMWhqqBNMQjRB1TqhsCi3Q3xJLaI7cg2EP6+FouyvHNH5+pM551p2Il8
0M4KGA0zYGRLJ7WtBey2Hw/PwEJEK7FxlgRcKMB81u9NMZfubDd0KmLNEsSGHAWoGNuc81AqMhiG
riWbusp5gzFFX3Pp8ZzgpuGPWTbmBrVNCwpbWioqD8XRCHj/KSb3n5OlXHyr3+N4v12vqrcnIe4G
3eIVWKQu3p6D/nrZFf/lFbWWApJJtbrsvZYbDJH89ZJMkyXw2R8AAAD//wMAUEsBAi0AFAAGAAgA
AAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC
LQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwEC
LQAUAAYACAAAACEAtLPQJtgAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1s
UEsFBgAAAAADAAMAtwAAAAwDAAAAAAAAD/AQAAAAsAcAAMENAABkDAAAJw8AAA8AEfB+AAAADwCI
E3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgAAAAAAAAD
AAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQ
AAAAAAAAAAAADwAN8G8AAAAAAJ8PBAAAAAcAAAAAAKgPAwAAAFdJUAAAoQ8eAAAABAAAAAAAASAA
AAgAAAAEAAAAAAAmAAQADgAGCQ7+AACqDwwAAAAEAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQB
IAHQAkAC8ANgAxAFgAQPAATwcAUAABIACvAIAAAACcAAAAIKAACDAAvwMAAAAH8AAAAEAIAA6CfD
Cr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQC3pX4B1wAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LTsMwEEX3SPyD
NUhsEHWKUItC3aoqj3bBpikL2E3iSRwRjyPbadO/x+oClnfu6FydxWq0nTiSD61jBdNJBoK4crrl
RsHn4e3+CUSIyBo7x6TgTAFWy+urBebanXhPxyI2IkE45KjAxNjnUobKkMUwcT1x6mrnLcYUfSO1
x1OC204+ZNlMWmw5LRjsaWOo+ikGq+D1q5jfvc83ev1hvodZedht65dHpW5vxvUziEhj/H/GoZwS
/ZUX1E4rSCb19lz6Vu8xRPKXSzJNliCXvwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC3
pX4B1wAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAACwMAAAAAAAAP8BAAAADSAAAAwQ0AALAHAAAnDwAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAA
AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAA
ALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3w
nAAAAAAAnw8EAAAABwAAAAAAqA8WAAAARG9tMCBYZW4gUkFTIGludGVyZmFjZQAAoQ8eAAAAFwAA
AAAAASAAAAgAAAAXAAAAAAAmAAQADgAGCQ7+AACqDyYAAAAFAAAABgAAAAkEBAgDAAAABwAAAAMA
CQQECA8AAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBiBQAAEgAK
8AgAAAAKwAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAEM8MKvwAEAAQAgQFFgssAgwEAAAAIvwEYAB8A
/wEAAAgAvwMAAAIAIwAi8eUDAAC/AQAAYACpg9kDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6
URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0E
EpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJN
AurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/
cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6
aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpW
C0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNC
nqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAIni8cnY
AAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfeV+g/WVOqmKk6rilQpBiH6ACE2hC7a
3RBP4qjxOLINhL+vxaJd3rmjc3Ums8F24kg+tI4VPIwyEMSV0y03Cj537/fPIEJE1tg5JgVnCjCb
Xl9NsNDuxFs6lrERCcKhQAUmxr6QMlSGLIaR64lTVztvMaboG6k9nhLcdvIxy8bSYstpwWBPC0PV
T3mwCt6+yvzuI1/o+cZ8H8b73WpZvz4pdXszzF9ARBri//M65uVG/5UX1EorSCb18rz3rd5iiOQv
l2SaLEFOfwEAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAA
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAA
AAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCJ4vHJ2AAAAPkAAAAPAAAAAAAA
AAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADAMAAAAAAAAP8BAAAABk
DAAAjgkAABIWAAD0CgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAA
VAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABU
ADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3whwAAAAAAnw8EAAAABwAAAAAA
qA8bAAAARG9tMCBhbmQgaHlwZXJ2aXNvciBjby13b3JrAAChDx4AAAAcAAAAAAABIAAACAAAABwA
AAAAACYABAAOAAYJDv4AAKoPDAAAABwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALw
A2ADEAWABA8ABPBQBQAAEgAK8AgAAAALwAAAAgoAAIMAC/AwAAAAfwAAAAQAgACkPcMKvwAEAAQA
gQFFgssAgwEAAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eUDAAC/AQAAYACpg9kDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhALSz0CbYAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfdI/IM1
SN1UxaGqoE0xCNEHVOqGwKLdDfEktojtyDYQ/r4Wi7K8c0fn6kznnWnYiXzQzgoYDTNgZEsnta0F
7LYfD8/AQkQrsXGWBFwowHzW700xl+5sN3QqYs0SxIYcBagY25zzUCoyGIauJZu6ynmDMUVfc+nx
nOCm4Y9ZNuYGtU0LCltaKioPxdEIeP8pJvefk6VcfKvf43i/Xa+qtych7gbd4hVYpC7enoP+etkV
/+UVtZYCkkm1uuy9lhsMkfz1kkyTJfDZHwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC0
s9Am2AAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAADAMAAAAAAAAP8BAAAACwBwAAjgkAAGQMAAD0CgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAA
AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAA
ALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3w
dQAAAAAAnw8EAAAABwAAAAAAqA8JAAAAc3VwcG9ydGVkAAChDx4AAAAKAAAAAAABIAAACAAAAAoA
AAAAACYABAAOAAYJDv4AAKoPDAAAAAoAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALw
A2ADEAWABA8ABPBPBQAAEgAK8AgAAAAMwAAAAgoAAIMAC/AwAAAAfwAAAAQAgACkR8MKvwAEAAQA
gQFFgssAgwEAAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eQDAAC/AQAAYACpg9gDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhALelfgHXAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tOwzAQRfdI/IM1
SGwQdYpQi0LdqiqPdsGmKQvYTeJJHBGPI9tp07/H6gKWd+7oXJ3FarSdOJIPrWMF00kGgrhyuuVG
wefh7f4JRIjIGjvHpOBMAVbL66sF5tqdeE/HIjYiQTjkqMDE2OdShsqQxTBxPXHqauctxhR9I7XH
U4LbTj5k2UxabDktGOxpY6j6KQar4PWrmN+9zzd6/WG+h1l52G3rl0elbm/G9TOISGP8f8ahnBL9
lRfUTitIJvX2XPpW7zFE8pdLMk2WIJe/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALel
fgHXAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAALAwAAAAAAAA/wEAAAANIAAACOCQAAsAcAAPQKAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAA
ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAA
ug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfB1
AAAAAACfDwQAAAAHAAAAAACoDwkAAABBUEVJIEVSU1QAAKEPHgAAAAoAAAAAAAEgAAAIAAAACgAA
AAAAJgAEAA4ABgkO/gAAqg8MAAAACgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvAD
YAMQBYAEDwAE8EkFAAASAArwCAAAAA3AAAACCgAAgwAL8DAAAAB/AAAABACAACBKwwq/AAQABACB
AUWCywCDAQAAAAi/ARAAFAD/AQAACAC/AwAAAgATACLx3wMAAKmD2QMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEAieLxydgAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X6D9ZU6qYqTquK
VCkGIfoAITaELtrdEE/iqPE4sg2Ev6/Fol3euaNzdSazwXbiSD60jhU8jDIQxJXTLTcKPnfv988g
QkTW2DkmBWcKMJteX02w0O7EWzqWsREJwqFABSbGvpAyVIYshpHriVNXO28xpugbqT2eEtx28jHL
xtJiy2nBYE8LQ9VPebAK3r7K/O4jX+j5xnwfxvvdalm/Pil1ezPMX0BEGuL/8zrm5Ub/lRfUSitI
JvXyvPet3mKI5C+XZJosQU5/AQAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAA
AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAIni8cnYAAAA
+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAMAwAA
AAAAAA/wEAAAAGQMAAD0CgAAEhYAAFsMAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAA
AF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAA
XwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfB0AAAAAACf
DwQAAAAHAAAAAACoDwgAAABEb20wIG93bgAAoQ8eAAAACQAAAAAAASAAAAgAAAAJAAAAAAAmAAQA
DgAGCQ7+AACqDwwAAAAJAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQP
AATwSgUAABIACvAIAAAADsAAAAIKAACDAAvwMAAAAH8AAAAEAIAArFvDCr8ABAAEAIEBRYLLAIMB
AAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHfAwAAqYPZAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7AS
t43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3l
Rb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31u
n0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhra
RtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/
AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy
9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6x
qGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w8
1c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC0
s9Am2AAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3SPyDNUjdVMWhqqBNMQjRB1Tq
hsCi3Q3xJLaI7cg2EP6+FouyvHNH5+pM551p2Il80M4KGA0zYGRLJ7WtBey2Hw/PwEJEK7FxlgRc
KMB81u9NMZfubDd0KmLNEsSGHAWoGNuc81AqMhiGriWbusp5gzFFX3Pp8ZzgpuGPWTbmBrVNCwpb
WioqD8XRCHj/KSb3n5OlXHyr3+N4v12vqrcnIe4G3eIVWKQu3p6D/nrZFf/lFbWWApJJtbrsvZYb
DJH89ZJMkyXw2R8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAtLPQJtgAAAD5AAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAwDAAAAAAAAD/AQ
AAAAsAcAAPQKAABkDAAAWwwAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8A
UABQAFQAMQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQ
AFAAVAA5AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8HUAAAAAAJ8PBAAAAAcA
AAAAAKgPCQAAAHN1cHBvcnRlZAAAoQ8eAAAACgAAAAAAASAAAAgAAAAKAAAAAAAmAAQADgAGCQ7+
AACqDwwAAAAKAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwSQUA
ABIACvAIAAAAD8AAAAIKAACDAAvwMAAAAH8AAAAEAIAA7GbDCr8ABAAEAIEBRYLLAIMBAAAACL8B
EAAUAP8BAAAIAL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC3pX4B1wAA
APkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LTsMwEEX3SPyDNUhsEHWKUItC3aoqj3bBpikL2E3i
SRwRjyPbadO/x+oClnfu6FydxWq0nTiSD61jBdNJBoK4crrlRsHn4e3+CUSIyBo7x6TgTAFWy+ur
BebanXhPxyI2IkE45KjAxNjnUobKkMUwcT1x6mrnLcYUfSO1x1OC204+ZNlMWmw5LRjsaWOo+ikG
q+D1q5jfvc83ev1hvodZedht65dHpW5vxvUziEhj/H/GoZwS/ZUX1E4rSCb19lz6Vu8xRPKXSzJN
liCXvwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAA
AAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC3pX4B1wAAAPkAAAAPAAAAAAAAAAAA
AAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAADSAAAA
9AoAALAHAABbDAAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx
ADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkA
AACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wdQAAAAAAnw8EAAAABwAAAAAAqA8J
AAAAQVBFSSBFSU5KAAChDx4AAAAKAAAAAAABIAAACAAAAAoAAAAAACYABAAOAAYJDv4AAKoPDAAA
AAoAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBRBQAAEgAK8AgA
AAAQwAAAAgoAAIMAC/AwAAAAfwAAAAQAgABQZ8MKvwAEAAQAgQGvk/UAgwEAAAAIvwEQABQA/wEA
AAgAvwMAAAIAEwAi8d0DAACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29u
dGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg
4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7
rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQ
JmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL
4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9y
ZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPh
J61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJ
aceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+
09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAOutUfjWAAAA+QAAAA8A
AABkcnMvZG93bnJldi54bWxEj0FPwkAQhe8k/ofNmHghshWCkMJCDI2R4AnQ4HHoDm2xO9vsrrT8
ezcc9PjmTb6Xb77sTC0u5HxlWcHTIAFBnFtdcaHgY//6OAXhA7LG2jIpuJKH5eKuN8dU25a3dNmF
QkQI+xQVlCE0qZQ+L8mgH9iGOHYn6wyGGF0htcM2wk0th0nyLA1WHBdKbGhVUv69+zEKbL1vs8nG
9acTPTSHryw7H9qzUg/33csMRKAu/D+/jz7HK/4rb6i1VhBNTm/Xo6v0Fn0gd7tE02gJcvELAAD/
/wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50
X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAA
X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA661R+NYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQAAAA0gAAAJwBAACwBwAA
iwIAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQ
AAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAA
AACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8H4AAAAAAJ8PBAAAAAcAAAAAAKgPBAAAAEl0ZW0A
AKEPHgAAAAUAAAAAAAEgAAAIAAAABQAAAAEAJAAAAAQA/////gAAqg8aAAAABAAAAAYAAAAJBAQI
AQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwUwUAABIACvAI
AAAAEcAAAAIKAACDAAvwMAAAAH8AAAAEAIAABHvDCr8ABAAEAIEBr5P1AIMBAAAACL8BEAAUAP8B
AAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0Nv
bnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4
IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmF
e63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrA
ECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5
S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABf
cmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD
4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1C
yWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3
PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAYpfi91gAAAPkAAAAP
AAAAZHJzL2Rvd25yZXYueG1sRI9Ba8JAEIXvQv/DMoVepG70UCW6ihhKi6dqCnocs2MSzc6G3a2J
/76Lh/b45g3f41usetOIGzlfW1YwHiUgiAuray4VfOfvrzMQPiBrbCyTgjt5WC2fBgtMte14R7d9
KEWEsE9RQRVCm0rpi4oM+pFtiWN3ts5giNGVUjvsItw0cpIkb9JgzXGhwpY2FRXX/Y9RYJu8y6Zb
N5xN9cQcjll2OXQXpV6e+/UcRKA+/D9f19v8+PVXPlCfWkE0OX/cT67WO/SB3OMSTaMlyOUvAAAA
//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhABil+L3WAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIA
AGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAALAHAACcAQAAZAwA
AIsCAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT
EAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAA
AAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfCAAAAAAACfDwQAAAAHAAAAAACoDwYAAABTdGF0
dXMAAKEPHgAAAAcAAAAAAAEgAAAIAAAABwAAAAEAJAAAAAQA/////gAAqg8aAAAABgAAAAYAAAAJ
BAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwVgUAABIA
CvAIAAAAEsAAAAIKAACDAAvwMAAAAH8AAAAEAIAAoIfDCr8ABAAEAIEBr5P1AIMBAAAACL8BEAAU
AP8BAAAIAL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2
pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywN
jCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4
shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/
yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4
P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUT
Uf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9T
MfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBYFYo/1wAAAPkA
AAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8JAEIbvBf/DMoVepG4qRSV1ldJQKvbkB9jeptkxiWZn
w+7WxH/v4kGP77zD8/JM552pxYmcrywreBkkIIhzqysuFGw3n88TED4ga6wtk4IzeZjPeg9TTLVt
eUWndShEhLBPUUEZQpNK6fOSDPqBbYhjt7fOYIjRFVI7bCPc1HKYJCNpsOK4UGJDHyXlx/W/UWDr
TZuNl64/Geuh2f1k2WHXHpR6euze30AE6sL9+fv1tz9a3MoraqEVRJP91/nPVXqFPpC7XqJptAQ5
uwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv
bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAA
AB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBYFYo/1wAAAPkAAAAPAAAAAAAAAAAAAAAA
AAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAABkDAAAnAEA
ABIWAACLAgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA
AACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACL
ExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wggAAAAAAnw8EAAAABwAAAAAAqA8IAAAA
Q29tbWVudHMAAKEPHgAAAAkAAAAAAAEgAAAIAAAACQAAAAEAJAAAAAQA/////gAAqg8aAAAACAAA
AAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATw
TAUAABIACvAIAAAAE8AAAAIKAACDAAvwMAAAAH8AAAAEAIAAVIDDCr8ABAAEAIEBBAAACIMBAAAA
CL8BEAAUAP8BAAAIAL8DAAACABMAIvHcAwAAqYPWAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQA2EFtH
1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Ba8JAEIXvhf6HZQq91Y21lRJdpSilCiokLT2P
2TEJZmfD7tYk/76Lh3p884bv8c2XvWnEhZyvLSsYjxIQxIXVNZcKvr8+nt5A+ICssbFMCgbysFzc
380x1bbjjC55KEWEsE9RQRVCm0rpi4oM+pFtiWN3ss5giNGVUjvsItw08jlJptJgzXGhwpZWFRXn
/Nco6LOfycTuXwiHboOv6/X2cDxslXp86N9nIAL14fZ8zovdbvVfXlEbrSCanD6Ho6t1hj6Qu16i
abQEufgDAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAA
AAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEANhBbR9UAAAD5AAAADwAAAAAAAAAA
AAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAkDAAAAAAAAD/AQAAAA0gAA
AIsCAACwBwAABgQAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQA
MQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5
AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8HoAAAAAAJ8PBAAAAAcAAAAAAKgP
EgAAAE1DQSBpbmZyYXN0cnVjdHVyZQAAoQ8aAAAAEwAAAAAAASAAAAgAAAATAAAAAAAiAAQADgAA
AKoPDAAAABMAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBCBQAA
EgAK8AgAAAAUwAAAAgoAAIMAC/AwAAAAfwAAAAQAgAA8ksMKvwAEAAQAgQEEAAAIgwEAAAAIvwEQ
ABQA/wEAAAgAvwMAAAIAEwAi8dsDAACpg9UDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMA
AABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK
9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXT
LA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurh
tLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl
/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAA
CwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseO
kvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut
5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo
/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAMOAXfTUAAAA
+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAQhe8F/8MyQm9109qWEl1FlKIeKiQtnsfsmIRm
d8PuaJJ/38VDPb55w/f45sveNOJKPtTOKnieJCDIFk7XtlTw8/359AEiMFqNjbOkYKAAy8XoYY6p
dp3N6JpzKSLEhhQVVMxtKmUoKjIYJq4lG7uz8wY5Rl9K7bGLcNPIlyR5lwZrGxcqbGldUfGbX4yC
PjtOp+7rlXDodvi22ewPp8Neqcdxv5qBYOr5/pwNF97m/+UNtdMKosl5O5x8rTMMTP52iabREuTi
DwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29u
dGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAA
HwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAMOAXfTUAAAA+QAAAA8AAAAAAAAAAAAAAAAA
BwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAIAwAAAAAAAA/wEAAAALAHAACLAgAA
ZAwAAAYEAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA
AIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsT
GAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfBxAAAAAACfDwQAAAAHAAAAAACoDwkAAABz
dXBwb3J0ZWQAAKEPGgAAAAoAAAAAAAEgAAAIAAAACgAAAAAAIgAEAA4AAACqDwwAAAAKAAAABgAA
AAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwVgUAABIACvAIAAAAFcAAAAIK
AACDAAvwMAAAAH8AAAAEAIAA3KTDCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAIAL8DAAAC
ABMAIvHcAwAAqYPWAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv
9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q
50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9
QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhd
jr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVs
c2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnC
ruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ
1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB
9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBdhdh11QAAAPkAAAAPAAAAZHJzL2Rv
d25yZXYueG1sRI9Ba8JAEIXvhf6HZYTe6sbalhpdpVRKzUEhtojHMTsmodnZsLs1yb/v4sXjmzd8
j2+x6k0jLuR8bVnBZJyAIC6srrlU8PP9+fgGwgdkjY1lUjCQh9Xy/m6BqbYd53TZh1JECPsUFVQh
tKmUvqjIoB/bljh2Z+sMhhhdKbXDLsJNI5+S5FUarDkuVNjSR0XF7/7PKOjzw3Rqt8+EQ7fBl/U6
2512mVIPo/59DiJQH27Ps6w7DrfyitpoBdHk/DWcXK1z9IHc9RJNoyXI5T8AAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEAXYXYddUAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAkDAAAAAAAAD/AQAAAAZAwAAIsCAAASFgAABgQAAA8AEfB+
AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgA
AAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAA
AAAAAAAQAAAAAAAAAAAADwAN8IQAAAAAAJ8PBAAAAAcAAAAAAKgPHAAAAE1vdmUgZnJvbSBkb20w
IHRvIGh5cGVydmlzb3IAAKEPGgAAAB0AAAAAAAEgAAAIAAAAHQAAAAAAIgAEAA4AAACqDwwAAAAd
AAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwRwUAABIACvAIAAAA
FsAAAAIKAACDAAvwMAAAAH8AAAAEAIAAUJ7DCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAI
AL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODo
Pz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63F
jDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZn
MGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H7
3hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVs
cy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4Set
ZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnH
hXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPW
FCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCOBAr+1wAAAPkAAAAPAAAA
ZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfoP1iB1UxWnVQVVwCBEH2TBhtAF7IZ4EkeN7ch2IPl7
LBZ0eeeOztWZL3vdsDM5X1sj4HWcACNTWFmbSsDv/vvlA5gPaCQ21pCAgTwsF48Pc0ylvZgdnfNQ
sQgxPkUBKoQ25dwXijT6sW3JxK60TmOI0VVcOrxEuG74W5JMuMbaxAWFLa0VFX95pwV8HfLp8890
LVdbdewmp322KT/fhXga9asZsEB9+H8eeJfx8l7eUJkUEE3KzXBytdyhD+Rul2gaLYEvrgAAAP//
AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABf
cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCOBAr+1wAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABk
cnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAADSAAAABgQAALAHAAB2
BQAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAA
AAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAA
AKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wcwAAAAAAnw8EAAAABwAAAAAAqA8LAAAAQ0UgYW5k
IFVDTkEAAKEPGgAAAAwAAAAAAAEgAAAIAAAADAAAAAAAIgAEAA4AAACqDwwAAAAMAAAABgAAAAkE
BAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwRgUAABIACvAIAAAAF8AAAAIKAACD
AAvwMAAAAH8AAAAEAIAAQLrDCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMA
IvHfAwAAqYPZAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOk
ForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv
44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnO
hDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R
8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zP
wWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvB
UPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbK
jMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U
2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC0s9Am2AAAAPkAAAAPAAAAZHJzL2Rvd25y
ZXYueG1sRI/LbsIwEEX3SPyDNUjdVMWhqqBNMQjRB1TqhsCi3Q3xJLaI7cg2EP6+FouyvHNH5+pM
551p2Il80M4KGA0zYGRLJ7WtBey2Hw/PwEJEK7FxlgRcKMB81u9NMZfubDd0KmLNEsSGHAWoGNuc
81AqMhiGriWbusp5gzFFX3Pp8ZzgpuGPWTbmBrVNCwpbWioqD8XRCHj/KSb3n5OlXHyr3+N4v12v
qrcnIe4G3eIVWKQu3p6D/nrZFf/lFbWWApJJtbrsvZYbDJH89ZJMkyXw2R8AAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEAtLPQJtgAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAwDAAAAAAAAD/AQAAAAsAcAAAYEAABkDAAAdgUAAA8AEfB+
AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgA
AAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAA
AAAAAAAQAAAAAAAAAAAADwAN8HEAAAAAAJ8PBAAAAAcAAAAAAKgPCQAAAHN1cHBvcnRlZAAAoQ8a
AAAACgAAAAAAASAAAAgAAAAKAAAAAAAiAAQADgAAAKoPDAAAAAoAAAAGAAAACQQECAAApg8WAAAA
+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBuBQAAEgAK8AgAAAAYwAAAAgoAAIMAC/AwAAAAfwAA
AAQAgADoxMMKvwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8d4DAACpg9gD
AABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMw
DIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCI
jbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H
0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZ
A/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA
//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2Dv
YHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3
DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e
5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPj
LwAAAP//AwBQSwMEFAAGAAgAAAAhAFletlrXAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEjzFv
wjAQhfdK/Q/WVepSFYeqApRiEEpbYGAhdCjbEV/iiNiObAPm39diKOO7d/qevuk86o6dyfnWGgHD
QQaMTGVlaxoBP7vv1wkwH9BI7KwhAVfyMJ89Pkwxl/ZitnQuQ8MSxPgcBagQ+pxzXynS6Ae2J5O6
2jqNIUXXcOnwkuC6429ZNuIaW5MWFPZUKKqO5UkL+Potxy/LcSEXG7U/jQ679ar+fBfi+SkuPoAF
iuH+vIxFtY//5Q21lgKSSb26Hlwrt+gDudslmSZL4LM/AAAA//8DAFBLAQItABQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG
AAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG
AAgAAAAhAFletlrXAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYA
AAAAAwADALcAAAALAwAAAAAAAA/wEAAAAGQMAAAGBAAAEhYAAHYFAAAPABHwfgAAAA8AiBN2AAAA
DwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAP
AIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAA
AAAAAA8ADfCaAAAAAACfDwQAAAAHAAAAAACoDyQAAABVc2Vyc3BhY2UgdG9vbHMgbG9nZ2luZyBh
bmQgYW5hbHlzaXMAAKEPGgAAACUAAAAAAAEgAAAIAAAAJQAAAAAAIgAEAA4AAACqDxoAAAAJAAAA
BwAAAAMACQQECBwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBi
BQAAEgAK8AgAAAAZwAAAAgoAAIMAC/AwAAAAfwAAAAQAgADsz8MKvwAEAAQAgQEEAAAIgwEAAAAI
vwEQABQA/wEAAAgAvwMAAAIAEwAi8d0DAACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6
URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0E
EpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJN
AurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/
cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6
aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpW
C0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNC
nqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAHym03fW
AAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FLAzEQhe+C/yGM4M1mta3I2rSIRdoeLGwtBW/T
zXR3cTNZk9jN/ntDD3p884bv8c0W0bTiTM43lhXcjzIQxKXVDVcK9h9vd08gfEDW2FomBQN5WMyv
r2aYa9tzQeddqESCsM9RQR1Cl0vpy5oM+pHtiFN3ss5gSNFVUjvsE9y08iHLHqXBhtNCjR291lR+
7X6MglgcxmP7PiEc+jVOl8vN9rjdKHV7E1+eQQSK4f95NZ3E78+/8oJaawXJ5LQajq7RBfpA7nJJ
pskS5PwXAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAA
AAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAfKbTd9YAAAD5AAAADwAAAAAAAAAA
AAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQAAAA0gAA
AHYFAACwBwAA5gYAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQA
MQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5
AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8I8AAAAAAJ8PBAAAAAcAAAAAAKgP
FQAAAFVuY29yZSBlcnJvciByZWNvdmVyeQAAoQ8eAAAAFgAAAAAAASAAAAgAAAAWAAAAAAAmAAQA
DgAIYKj+AACqDxoAAAAGAAAABwAAAAMACQQECBAAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEg
AdACQALwA2ADEAWABA8ABPBHBQAAEgAK8AgAAAAawAAAAgoAAIMAC/AwAAAAfwAAAAQAgACM2sMK
vwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8dwDAACpg9YDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhAKzsYVrVAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAQhe8F/8My
hd7qprWVkrqKVEr10EBUep5kxyQ0Oxt2V5P8+y4e6vHNG77Ht1gNphUXcr6xrOBpmoAgLq1uuFJw
PHw+voHwAVlja5kUjORhtZzcLTDVtuecLvtQiQhhn6KCOoQuldKXNRn0U9sRx+5kncEQo6ukdthH
uGnlc5LMpcGG40KNHX3UVP7uz0bBkP/MZvb7hXDst/i62eyyItsp9XA/rN9BBBrC7fmYFV17/i+v
qK1WEE1OX2PhGp2jD+Sul2gaLUEu/wAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCs7GFa
1QAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAA
CQMAAAAAAAAP8BAAAACwBwAAdgUAAGQMAADmBgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6
DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoP
DgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wdQAA
AAAAnw8EAAAABwAAAAAAqA8JAAAAc3VwcG9ydGVkAAChDx4AAAAKAAAAAAABIAAACAAAAAoAAAAA
ACYABAAOAAhgqP4AAKoPDAAAAAoAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2AD
EAWABA8ABPBxBQAAEgAK8AgAAAAbwAAAAgoAAIMAC/AwAAAAfwAAAAQAgADI5MMKvwAEAAQAgQEE
AAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8dwDAACpg9YDAABQSwMEFAAGAAgAAAAhANvh
9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEI
CI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TA
gQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMeP
KanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWY
nnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEA
WvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXE
LLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOt
rraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMf
O0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgA
AAAhAGHS2SDVAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FPAjEQhe8k/odmTLxBV1EwK4UY
CREOkiwSz0M77G7cTjdtZXf/vQ0HPb55k+/lW6x624gL+VA7VnA/yUAQa2dqLhUcPzfjZxAhIhts
HJOCgQKsljejBebGdVzQ5RBLkSAcclRQxdjmUgZdkcUwcS1x6s7OW4wp+lIaj12C20Y+ZNlMWqw5
LVTY0ltF+vvwYxX0xdd06j4eCYdui0/r9W5/2u+UurvtX19AROrj//NGH7O5/iuvqK1RkEzO78PJ
16bAEMlfL8k0WYJc/gIAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAA
AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBh0tkg1QAAAPkAAAAP
AAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACQMAAAAAAAAP
8BAAAABkDAAAdgUAABIWAADmBgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8A
XwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBf
AFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wnwAAAAAAnw8EAAAA
BwAAAAAAqA8zAAAATWVtb3J5IHNjcnViYmluZyBlcnJvcg1MMyBleHBsaWNpdCB3cml0ZS1iYWNr
IGVycm9yAAChDx4AAAA0AAAAAAABIAAACAAAADQAAAAAACYABAAOAAhgqP4AAKoPDAAAADQAAAAG
AAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBUBQAAEgAK8AgAAAAcwAAA
AgoAAIMAC/AwAAAAfwAAAAQAgAB878MKvwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMA
AAIAEwAi8d8DAACpg9kDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAGd5WHvYAAAA+QAAAA8AAABkcnMv
ZG93bnJldi54bWxEj8tuwjAQRfeV+g/WVOqmKk6rCqoUgxB9wIINgUW7G+JJnDYeR7YJ4e9rsWiX
d+7oXJ3pfLCt6MmHxrGCh1EGgrh0uuFawX73fv8MIkRkja1jUnCmAPPZ9dUUc+1OvKW+iLVIEA45
KjAxdrmUoTRkMYxcR5y6ynmLMUVfS+3xlOC2lY9ZNpYWG04LBjtaGip/iqNV8PZZTO4+Jku92Jiv
4/iwW6+q1yelbm+GxQuISEP8f/Zy/933f+UFtdYKkkm1Oh98o7cYIvnLJZkmS5CzXwAAAP//AwBQ
SwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVs
cy8ucmVsc1BLAQItABQABgAIAAAAIQBneVh72AAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMv
ZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADAMAAAAAAAAP8BAAAADSAAAA5gYAALAHAABCCAAA
DwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA
ALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwP
EAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wfwAAAAAAnw8EAAAABwAAAAAAqA8TAAAAQ29yZSBlcnJv
ciByZWNvdmVyeQAAoQ8eAAAAFAAAAAAAASAAAAgAAAAUAAAAAAAmAAQADgAIYKj+AACqDwwAAAAU
AAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwSQUAABIACvAIAAAA
HcAAAAIKAACDAAvwMAAAAH8AAAAEAIAAHPrDCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAI
AL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODo
Pz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63F
jDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZn
MGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H7
3hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVs
cy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4Set
ZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnH
hXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPW
FCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAo5sMa1wAAAPkAAAAPAAAA
ZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfoP1iB1UxWnVQUoYBCij7Bgk9BFuxviSRw1tiPbgeTv
a7Eoyzt3dK7OajPolp3J+cYaAc/TBBiZ0srG1AK+jh9PC2A+oJHYWkMCRvKwWd/frTCV9mJyOheh
ZhFifIoCVAhdyrkvFWn0U9uRiV1lncYQo6u5dHiJcN3ylySZcY2NiQsKO9opKn+LXgt4/y7mj5/z
ndwe1E8/Ox33WfX2KsTDZNgugQUawu05H/uQFf/lFbWXAqJJlY0n18gcfSB3vUTTaAl8/QcAAP//
AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABf
cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAo5sMa1wAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABk
cnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAACwBwAA5gYAAGQMAABC
CAAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAA
AAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAA
AKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wdQAAAAAAnw8EAAAABwAAAAAAqA8JAAAAc3VwcG9y
dGVkAAChDx4AAAAKAAAAAAABIAAACAAAAAoAAAAAACYABAAOAAhgqP4AAKoPDAAAAAoAAAAGAAAA
CQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBpBQAAEgAK8AgAAAAewAAAAgoA
AIMAC/AwAAAAfwAAAAQAgABQBMgKvwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIA
EwAi8eADAACpg9oDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBl
c10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/2
86QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDn
Se/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1B
Kc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2O
vdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxz
bM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu
68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnV
VsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H0
3hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAJa9Qg7ZAAAA+QAAAA8AAABkcnMvZG93
bnJldi54bWxEj11rwjAUhu8H/odwhN2MmW4MHZ1RivtQUATrhO3u2Jw2ZU1SklTrv1/wYrt8z3t4
Xp7pvNcNO5HztTUCHkYJMDKFlbWpBHzu3++fgfmARmJjDQm4kIf5bHAzxVTas9nRKQ8VixDjUxSg
QmhTzn2hSKMf2ZZM7ErrNIYYXcWlw3OE64Y/JsmYa6xNXFDY0kJR8ZN3WsDbVz65+5gsZLZR3934
uF8ty9cnIW6HffYCLFAf/p/Xh22XHf7KK2olBUSTcnk5ulru0Ady10s0jZbAZ78AAAD//wMAUEsB
Ai0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz
XS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMv
LnJlbHNQSwECLQAUAAYACAAAACEAlr1CDtkAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rv
d25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA0DAAAAAAAAD/AQAAAAZAwAAOYGAAASFgAAQggAAA8A
EfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACx
DwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAA
AAAAAAAAAAAQAAAAAAAAAAAADwAN8JMAAAAAAJ8PBAAAAAcAAAAAAKgPJwAAAERhdGEgbG9hZCBl
cnJvcg1JbnN0cnVjdGlvbiBmZXRjaCBlcnJvcgAAoQ8eAAAAKAAAAAAAASAAAAgAAAAoAAAAAAAm
AAQADgAIYKj+AACqDwwAAAAoAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAF
gAQPAATwSAUAABIACvAIAAAAH8AAAAIKAACDAAvwMAAAAH8AAAAEAIAAsA/ICr8ABAAEAIEBRYLL
AIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQBsd1ck1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9dSwMxEEXfhf6HMAXfbFarpaxNi1jE
ltLiVvF5upnuLm4mSxL3498b+mAf79zhXM5i1ZtatOR8ZVnB/SQBQZxbXXGh4Ovz7W4OwgdkjbVl
UjCQh9VydLPAVNuOM2qPoRARwj5FBWUITSqlz0sy6Ce2IY7d2TqDIUZXSO2wi3BTy4ckmUmDFceF
Eht6LSn/Of4aBX32PZ3a/SPh0G3wab3eHk6HrVK34/7lGUSgPlyf57u2/dj9lxfURiuIJuf34eQq
naEP5C6XaBotQS7/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAA
AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGx3VyTWAAAA+QAAAA8A
AAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/w
EAAAANIAAABCCAAAsAcAAI4JAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf
AFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8A
UABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfB1AAAAAACfDwQAAAAH
AAAAAACoDwkAAABBUEVJIEJFUlQAAKEPHgAAAAoAAAAAAAEgAAAIAAAACgAAAAAAJgAEAA4ABgkO
/gAAqg8MAAAACgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8EIF
AAASAArwCAAAACDAAAACCgAAgwAL8DAAAAB/AAAABACAANAayAq/AAQABACBAUWCywCDAQAAAAi/
ARAAFAD/AQAACAC/AwAAAgATACLx3AMAAKmD1gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpR
HMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQS
ldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C
6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9y
pKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUB
AAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pq
x46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYL
S63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Ke
puj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAw0JGcNUA
AAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPQUvDQBCF74L/YRnBm91oVSR2W4pFbIQW0xbPk+w0
Cc3Oht21Sf69Sw96fPOG7/HNFoNpxZmcbywruJ8kIIhLqxuuFBz273cvIHxA1thaJgUjeVjMr69m
mGrbc07nXahEhLBPUUEdQpdK6cuaDPqJ7Yhjd7TOYIjRVVI77CPctPIhSZ6lwYbjQo0dvdVUnnY/
RsGQf0+ndvNIOPZrfFqtsm2xzZS6vRmWryACDeH/ufg6fWbLv/KCWmsF0eT4MRau0Tn6QO5yiabR
EuT8FwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABb
Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAA
AAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAMNCRnDVAAAA+QAAAA8AAAAAAAAAAAAA
AAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAJAwAAAAAAAA/wEAAAALAHAABC
CAAAZAwAAI4JAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEA
MAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAA
AIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfBwAAAAAACfDwQAAAAHAAAAAACoDwQA
AABXQUlUAAChDx4AAAAFAAAAAAABIAAACAAAAAUAAAAAACYABAAOAAYJDv4AAKoPDAAAAAUAAAAG
AAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBZBQAAEgAK8AgAAAAhwAAA
AgoAAIMAC/AwAAAAfwAAAAQAgAAIJMgKvwAEAAQAgQFFgssAgwEAAAAIvwEQABQA/wEAAAgAvwMA
AAIAEwAi8dwDAACpg9YDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhABvQZUDVAAAA+QAAAA8AAABkcnMv
ZG93bnJldi54bWxEj0FPwkAQhe8m/ofNmHiDrSKGVBZiJEaIASkQz0N3aBu7s83uStt/74YDHt+8
yffyTeedqcWZnK8sK3gYJiCIc6srLhQc9u+DCQgfkDXWlklBTx7ms9ubKabatpzReRcKESHsU1RQ
htCkUvq8JIN+aBvi2J2sMxhidIXUDtsIN7V8TJJnabDiuFBiQ28l5T+7X6Ogy75HI7t+IuzbJY4X
i9XmuFkpdX/Xvb6ACNSF/2f5lW0/5bW8oJZaQTQ5ffRHV+kMfSB3uUTTaAly9gcAAP//AwBQSwEC
LQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8u
cmVsc1BLAQItABQABgAIAAAAIQAb0GVA1QAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93
bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACQMAAAAAAAAP8BAAAABkDAAAQggAABIWAACOCQAADwAR
8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEP
CAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAA
AAAAAAAAABAAAAAAAAAAAAAPAA3whwAAAAAAnw8EAAAABwAAAAAAqA8bAAAARG9tMCBvd24sIHdh
aXQga2VybmVsIHJlYWR5AAChDx4AAAAcAAAAAAABIAAACAAAABwAAAAAACYABAAOAAYJDv4AAKoP
DAAAABwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBABAAAQgEK
8AgAAAAiwAAAAgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEAAAAIywGcMQAA/wEYABgA
vwMAAAIAIwAi8d4DAAD/AQAAQACpg9IDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABb
Q29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak
27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2M
KYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiy
GsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/I
ajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/
ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR
/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx
8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAK4TAcjRAAAA7AAA
AA8AAABkcnMvZG93bnJldi54bWxEj0FrAjEQhe9C/0OYQm+abaEqW6NsC8VeelgVqbfpZtws3UyW
JHVXf31DETzOzJv33rdYDbYVJ/KhcazgcZKBIK6cbrhWsNu+j+cgQkTW2DomBWcKsFrejRaYa9dz
SadNrEUy4ZCjAhNjl0sZKkMWw8R1xOl2dN5iTKOvpfbYJ3Pbyqcsm0qLDacEgx29Gap+Nr9Wwee6
OLxedF9uy72Rz7NdvT98FUo93A/FC4hIQ7yJr98fWkEqf1yfv32jSwyR/P8mwSUwkMs/AAAA//8D
AFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U
eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9y
ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRy
cy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAFAwAAAAAAAA/wEAAAALAHAACcAQAAsAcAACcP
AAAPAATwQAQAAEIBCvAIAAAAI8AAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAAAA
CMsBnDEAAP8BGAAYAL8DAAACACMAIvHeAwAA/wEAAEAAqYPSAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQCuEwHI0QAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BawIxEIXvQv9DmEJvmm2hKlujbAvF
XnpYFam36WbcLN1MliR1V399QxE8zsyb9963WA22FSfyoXGs4HGSgSCunG64VrDbvo/nIEJE1tg6
JgVnCrBa3o0WmGvXc0mnTaxFMuGQowITY5dLGSpDFsPEdcTpdnTeYkyjr6X22Cdz28qnLJtKiw2n
BIMdvRmqfja/VsHnuji8XnRfbsu9kc+zXb0/fBVKPdwPxQuISEO8ia/fH1pBKn9cn799o0sMkfz/
JsElMJDLPwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAA
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAA
AAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAAAAA
AAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABQMAAAAAAAAP8BAAAABk
DAAAnAEAAGQMAAAnDwAADwAE8DwEAABCAQrwCAAAACTAAAACCgAAcwAL8CoAAAC/AAQABAB/AQAA
AQC/AQAAEADAAQAAAAjLAdSUAAD/ARgAGAC/AwAAAgAjACLx2gMAAP8BAABAAKmDzgMAAFBLAwQU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPk
K2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63
T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43n
RJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI3
4Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsD
BBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDG
iNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7l
TBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSn
YEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8D
AFBLAwQUAAYACAAAACEAR10jPs0AAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWvDMAyF74X9
B6PBbq2zDcLI6pYx6NrDLk1LzmqsxGGxHGyvdf/9TCnsKOnpvfct18mO4kw+DI4VPC8KEMSt0wP3
Co6HzfwNRIjIGkfHpOBKAdarh9kSK+0uvKdzHXuRTThUqMDEOFVShtaQxbBwE3G+dc5bjHn0vdQe
L9ncjvKlKEppceCcYHCiT0PtT/1rFXy/OtvU3VcyTdqObDZledihUk+P6eMdRKQU/8X3751WkMt3
2+vJD3qPIZK/bTJcBgO5+gMAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAA
AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUB
AAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBHXSM+zQAAAOwA
AAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAAAQMAAAAA
AAAP8BAAAADSAAAAiwIAABIWAACLAgAADwAE8EAEAABCAQrwCAAAACXAAAACCgAAcwAL8CoAAAC/
AAQABAB/AQAAAQC/AQAAEADAAQAAAAjLAZwxAAD/ARgAGAC/AwAAAgAjACLx3gMAAP8BAABAAKmD
0gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9O
wzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1W
oIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHN
DgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487Mrog
V1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8A
AAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7
YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwv
x7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773
/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODT
M+MvAAAA//8DAFBLAwQUAAYACAAAACEArhMByNEAAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESP
QWsCMRCF70L/Q5hCb5ptoSpbo2wLxV56WBWpt+lm3CzdTJYkdVd/fUMRPM7Mm/fet1gNthUn8qFx
rOBxkoEgrpxuuFaw276P5yBCRNbYOiYFZwqwWt6NFphr13NJp02sRTLhkKMCE2OXSxkqQxbDxHXE
6XZ03mJMo6+l9tgnc9vKpyybSosNpwSDHb0Zqn42v1bB57o4vF50X27LvZHPs129P3wVSj3cD8UL
iEhDvImv3x9aQSp/XJ+/faNLDJH8/ybBJTCQyz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEArhMByNEAAADsAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAUDAAAAAAAAD/AQAAAA0gAAAAYEAAASFgAABgQAAA8ABPBABAAAQgEK8AgAAAAmwAAA
AgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEAAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi
8d4DAAD/AQAAQACpg9IDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAABkcnMv
ZG93bnJldi54bWxEj0FrAjEQhe9C/0OYQm+abaEqW6NsC8VeelgVqbfpZtws3UyWJHVXf31DETzO
zJv33rdYDbYVJ/KhcazgcZKBIK6cbrhWsNu+j+cgQkTW2DomBWcKsFrejRaYa9dzSadNrEUy4ZCj
AhNjl0sZKkMWw8R1xOl2dN5iTKOvpfbYJ3Pbyqcsm0qLDacEgx29Gap+Nr9Wwee6OLxedF9uy72R
z7NdvT98FUo93A/FC4hIQ7yJr98fWkEqf1yfv32jSwyR/P8mwSUwkMs/AAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAFAwAAAAAAAA/wEAAAANIAAAB2BQAAEhYAAHYFAAAPAATwQAQA
AEIBCvAIAAAAJ8AAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAAAACMsBnDEAAP8B
GAAYAL8DAAACACMAIvHeAwAA/wEAAEAAqYPSAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCuEwHI0QAA
AOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BawIxEIXvQv9DmEJvmm2hKlujbAvFXnpYFam36Wbc
LN1MliR1V399QxE8zsyb9963WA22FSfyoXGs4HGSgSCunG64VrDbvo/nIEJE1tg6JgVnCrBa3o0W
mGvXc0mnTaxFMuGQowITY5dLGSpDFsPEdcTpdnTeYkyjr6X22Cdz28qnLJtKiw2nBIMdvRmqfja/
VsHnuji8XnRfbsu9kc+zXb0/fBVKPdwPxQuISEO8ia/fH1pBKn9cn799o0sMkfz/JsElMJDLPwAA
AP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8B
AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAAAAAAAAAAAAAAAcC
AABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABQMAAAAAAAAP8BAAAADSAAAA5gYAABIW
AADmBgAADwAE8EAEAABCAQrwCAAAACjAAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADA
AQAAAAjLAZwxAAD/ARgAGAC/AwAAAgAjACLx3gMAAP8BAABAAKmD0gMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEArhMByNEAAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWsCMRCF70L/Q5hCb5ptoSpb
o2wLxV56WBWpt+lm3CzdTJYkdVd/fUMRPM7Mm/fet1gNthUn8qFxrOBxkoEgrpxuuFaw276P5yBC
RNbYOiYFZwqwWt6NFphr13NJp02sRTLhkKMCE2OXSxkqQxbDxHXE6XZ03mJMo6+l9tgnc9vKpyyb
SosNpwSDHb0Zqn42v1bB57o4vF50X27LvZHPs129P3wVSj3cD8ULiEhDvImv3x9aQSp/XJ+/faNL
DJH8/ybBJTCQyz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEArhMByNEAAADsAAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAUDAAAAAAAAD/AQ
AAAA0gAAAEIIAAASFgAAQggAAA8ABPBABAAAQgEK8AgAAAApwAAAAgoAAHMAC/AqAAAAvwAEAAQA
fwEAAAEAvwEAABAAwAEAAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi8d4DAAD/AQAAQACpg9IDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrAjEQ
he9C/0OYQm+abaEqW6NsC8VeelgVqbfpZtws3UyWJHVXf31DETzOzJv33rdYDbYVJ/KhcazgcZKB
IK6cbrhWsNu+j+cgQkTW2DomBWcKsFrejRaYa9dzSadNrEUy4ZCjAhNjl0sZKkMWw8R1xOl2dN5i
TKOvpfbYJ3Pbyqcsm0qLDacEgx29Gap+Nr9Wwee6OLxedF9uy72Rz7NdvT98FUo93A/FC4hIQ7yJ
r98fWkEqf1yfv32jSwyR/P8mwSUwkMs/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAK4T
AcjRAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAFAwAAAAAAAA/wEAAAANIAAACOCQAAEhYAAI4JAAAPAATwQAQAAEIBCvAIAAAAKsAAAAIKAABz
AAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAAAACMsBnDEAAP8BGAAYAL8DAAACACMAIvHeAwAA
/wEAAEAAqYPSAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOk
ForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv
44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnO
hDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R
8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zP
wWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvB
UPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbK
jMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U
2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAZHJzL2Rvd25y
ZXYueG1sRI9BawIxEIXvQv9DmEJvmm2hKlujbAvFXnpYFam36WbcLN1MliR1V399QxE8zsyb9963
WA22FSfyoXGs4HGSgSCunG64VrDbvo/nIEJE1tg6JgVnCrBa3o0WmGvXc0mnTaxFMuGQowITY5dL
GSpDFsPEdcTpdnTeYkyjr6X22Cdz28qnLJtKiw2nBIMdvRmqfja/VsHnuji8XnRfbsu9kc+zXb0/
fBVKPdwPxQuISEO8ia/fH1pBKn9cn799o0sMkfz/JsElMJDLPwAAAP//AwBQSwECLQAUAAYACAAA
ACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt
ABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQIt
ABQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAMAAwC3AAAABQMAAAAAAAAP8BAAAADSAAAAnAEAANIAAAAnDwAADwAE8EAEAABCAQrw
CAAAACvAAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADAAQAAAAjLAZwxAAD/ARgAGAC/
AwAAAgAjACLx3gMAAP8BAABAAKmD0gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtD
b250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTb
uCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwp
hXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIa
wBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hq
OUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAA
X3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9J
w+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9
Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHw
dz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEArhMByNEAAADsAAAA
DwAAAGRycy9kb3ducmV2LnhtbESPQWsCMRCF70L/Q5hCb5ptoSpbo2wLxV56WBWpt+lm3CzdTJYk
dVd/fUMRPM7Mm/fet1gNthUn8qFxrOBxkoEgrpxuuFaw276P5yBCRNbYOiYFZwqwWt6NFphr13NJ
p02sRTLhkKMCE2OXSxkqQxbDxHXE6XZ03mJMo6+l9tgnc9vKpyybSosNpwSDHb0Zqn42v1bB57o4
vF50X27LvZHPs129P3wVSj3cD8ULiEhDvImv3x9aQSp/XJ+/faNLDJH8/ybBJTCQyz8AAAD//wMA
UEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5
cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3Jl
bHMvLnJlbHNQSwECLQAUAAYACAAAACEArhMByNEAAADsAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJz
L2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAUDAAAAAAAAD/AQAAAAEhYAAJwBAAASFgAAJw8A
AA8ABPBABAAAQgEK8AgAAAAswAAAAgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEAAAAI
ywGcMQAA/wEYABgAvwMAAAIAIwAi8d4DAAD/AQAAQACpg9IDAABQSwMEFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0H
sBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ2
7eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanH
fW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHO
GtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQs
W78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaM
ZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQ
LrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0Uv
rDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAh
AK4TAcjRAAAA7AAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrAjEQhe9C/0OYQm+abaEqW6NsC8Ve
elgVqbfpZtws3UyWJHVXf31DETzOzJv33rdYDbYVJ/KhcazgcZKBIK6cbrhWsNu+j+cgQkTW2Dom
BWcKsFrejRaYa9dzSadNrEUy4ZCjAhNjl0sZKkMWw8R1xOl2dN5iTKOvpfbYJ3Pbyqcsm0qLDacE
gx29Gap+Nr9Wwee6OLxedF9uy72Rz7NdvT98FUo93A/FC4hIQ7yJr98fWkEqf1yfv32jSwyR/P8m
wSUwkMs/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAA
AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAA
AAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAAAAAAAA
AAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAFAwAAAAAAAA/wEAAAANIA
AACcAQAAEhYAAJwBAAAPAATwQAQAAEIBCvAIAAAALcAAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAAB
AL8BAAAQAMABAAAACMsBnDEAAP8BGAAYAL8DAAACACMAIvHeAwAA/wEAAEAAqYPSAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BawIxEIXvQv9D
mEJvmm2hKlujbAvFXnpYFam36WbcLN1MliR1V399QxE8zsyb9963WA22FSfyoXGs4HGSgSCunG64
VrDbvo/nIEJE1tg6JgVnCrBa3o0WmGvXc0mnTaxFMuGQowITY5dLGSpDFsPEdcTpdnTeYkyjr6X2
2Cdz28qnLJtKiw2nBIMdvRmqfja/VsHnuji8XnRfbsu9kc+zXb0/fBVKPdwPxQuISEO8ia/fH1pB
Kn9cn799o0sMkfz/JsElMJDLPwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAA
AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAA
ABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCuEwHI0QAA
AOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABQMA
AAAAAAAP8BAAAADSAAAAJw8AABIWAAAnDwAADwAE8LAAAABCAQrwCAAAAC7AAAACCgAAwwAL8EgA
AACFAAIAAACHAAEAAAC/AAAADwC/AQAAEADAAQAAAAjLAZwxAAD/AQwADgABAgIAAAg/AgAAAwC/
AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8F
BgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA0gAAAFsMAAASFgAAWwwAAA8ABPCwAAAAQgEK8AgAAAAv
wAAAAgoAAMMAC/BIAAAAhQACAAAAhwABAAAAvwAAAA8AvwEAABAAwAEAAAAIywGcMQAA/wEMAA4A
AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/
BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAANIAAAD0CgAAEhYAAPQKAAAPAATw
sAAAAEIBCvAIAAAAMMAAAAIKAADDAAvwSAAAAIUAAgAAAIcAAQAAAL8AAAAPAL8BAAAQAMABAAAA
CMsBnDEAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA
/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAADSAAAAwQ0A
ABIWAADBDQAADwAE8CABAACiDArwCAAAADLAAAAACgAAwwAL8G4AAAB/AAEA7wGAADwsyAqBAAAA
AACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwyYAAAC/AwAAAgBE
AGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXBDkCr4MqhAPAA3w
ggAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQAD
AAgAsrKy/gAA9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEE
AACmDwwAAADwAAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAM8AAAAAKAADDAAvwfgAAAH8AAQDv
AYAAADXICoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDD
NgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQBy
ACAANAAAAAAAEPAIAAAAXRDeCeQKqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEP
HgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAAAAAAqg8aAAAAAQAA
AAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPBIAAAAEgAK8AgA
AAABwAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ
AAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAA8AiBOBAAAA
DwCKE3kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTWQAAAAAAACsEAAAAAAAAAB8ARPE9
AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAwwr/////EgAAAA8APfENAAAAQAFC8QUA
AAABCQAAAA8AAisAAAAADwDwA5kGAAABAPEDCAAAAGgBAAAHAA0wDwAMBBkGAAAPAALwEQYAAAAB
CPAIAAAABAAAAAUsAAAPAAPwqQUAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK
8AgAAAAALAAABQAAAA8ABPDOAAAAEgAK8AgAAAACLAAAIAIAAPMAC/COAAAABAAAAAAAfwCFAe8B
gQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAEAAQA/wERABEAAQME
KAAAPwMAAAgAgMM0AAAAvwMAAAIAUwBsAGkAZABlACAASQBtAGEAZwBlACAAUABsAGEAYwBlAGgA
bwBsAGQAZQByACAAMQAAAAAAEPAIAAAAvgH8ApwOdgoPABHwEAAAAAAAwwsIAAAAAAAAAAsAyAoP
AATwVAMAABIACvAIAAAAAywAACACAAATAQvwjgAAAAQAAAAAAH8AAQDvAYAAgCPICoEAg3IBAIIA
QbkAAIMAg3IBAIQAQbkAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAL8BAAABAP8BEAARAAEDBSgA
AD8DAAAIAIDDKAAAAL8DAAACAE4AbwB0AGUAcwAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIA
AAAAABDwCAAAAAsLWQI/D4IVDwAR8BAAAAAAAMMLCAAAAAEAAAAMAMgKDwAN8H4CAAAAAJ8PBAAA
AAIAAAAAAKAPBAIAACoAIABXAGUAIABuAGUAZQBkACAAZABvAHUAYgBsAGUAIABjAGgAZQBjAGsA
OgAgAEkAZgAgAE0AQwBHAF8AQwBNAEMASQBfAFAAPQAxACAAYQBuAGQAIABlAG4AYQBiAGwAZQAg
AGEAbABsACAATQBDAGkAXwBDAFQATAAyACwAIABpAHQAIAB3AG8AdQBsAGQAIABiAGUAbgBlAGYA
aQB0ACAAdABoAGEAdAAgAGcAdQBlAHMAdAAgAG0AYQB5ACAAbgBvAHQAIABwAG8AbABsACAAcABl
AHIAaQBvAGQAaQBjAGEAbABsAHkAIABmAG8AcgAgAEMARQAvAFUAQwBOAEEAIABlAHIAcgBvAHIA
LgANACAAIABFAHYAZQBuACAAdwBlACAAcwBlAHQAIABNAEMARwBfAEMATQBDAEkAXwBQAD0AMQAg
AGEAbgBkACAAZQBuAGEAYgBsAGUAIABhAGwAbAAgAE0AQwBpAF8AQwBUAEwAMgAsACAAaAB5AHAA
ZQByAHYAaQBzAG8AcgAgAHMAdABpAGwAbAAgAGQAbwBlAHMAIABuAG8AdAAgAGkAbgBqAGUAYwB0
ACAAQwBNAEMASQAgAHQAbwAgAGcAdQBlAHMAdAAgAHMAaQBuAGMAZQAgAGkAdAAZIHMAIABwAG8A
aQBuAHQAbABlAHMAcwAuAAAAoQ8UAAAAAwEAAAAAAAAAAAMBAAAAACAABAAAAKoPJgAAAF0AAAAG
AAAACQQECAMAAAAHAAAAAAAJBAQIowAAAAYAAAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2AD
EAWABA8ABPA/AQAAogwK8AgAAAAELAAAAAoAANMAC/CEAAAAfwABAO8BgADol8gKgQCDcgEAggBB
uQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQAvwEAABAA/wEQABgAPwMAAAgAgMM2AAAAvwMAAAIA
UwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ
8AgAAAAWFvgJmBFAFw8AEfAJAAAAAAAgBAEAAAAIDwAN8HoAAAAAAJ8PBAAAAAQAAAAAAKAPAgAA
ACoAAAChDxgAAAACAAAAAAAACAAAAgACAAAAAAAiAAQADAAAANgPBAAAAAAAAAAAAKoPGgAAAAEA
AAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIAACmDw4AAADxAAAAVQLUAdAC8AMQBQ8ABPBIAAAAEgAK
8AgAAAAFLAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHiMm0AlAEuRpAAvwESABIA/wEAAAgA
BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4
AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAQzXNAWCE
xrwPAPADdQQAAAEA8QMIAAAAWQEAAAcADTAPAAwE9QMAAA8AAvDtAwAAIAEI8AgAAAAEAAAABTAA
AA8AA/CFAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAwAAAFAAAA
DwAE8M4AAAASAArwCAAAAAIwAAAgAgAA8wAL8I4AAAAEAAAAAAB/AIUB7wGBADBlAQCCAJiyAACD
ADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAQABAD/AREAEQABAwQoAAA/AwAACACAwzQA
AAC/AwAAAgBTAGwAaQBkAGUAIABJAG0AYQBnAGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAx
AAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDICg8ABPAwAQAAEgAK8AgA
AAADMAAAIAIAABMBC/COAAAABAAAAAAAfwABAO8BgACEgMgKgQCDcgEAggBBuQAAgwCDcgEAhABB
uQAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQAvwEBAAEA/wERABEAAQMFKAAAPwMAAAgAgMMoAAAA
vwMAAAIATgBvAHQAZQBzACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAACwtZ
Aj8PghUPABHwEAAAAAAAwwsIAAAAAQAAAAwAyAoPAA3wWgAAAAAAnw8EAAAAAgAAAAAAoQ8UAAAA
AQAAAAAAAAAAAAEAAAAAACAABAAAAKoPDgAAAAEAAAAHAAAAAAAJBAQIAACmDxQAAADwHgAA1AEg
AdACQALwA2ADEAWABA8ABPA/AQAAogwK8AgAAAAEMAAAAAoAANMAC/CEAAAAfwABAO8BgACgscgK
gQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQAvwEAABAA/wEQABgAPwMAAAgAgMM2
AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIA
IAAzAAAAAAAQ8AgAAAAWFvgJmBFAFw8AEfAJAAAAAAAgBAEAAAAIDwAN8HoAAAAAAJ8PBAAAAAQA
AAAAAKAPAgAAACoAAAChDxgAAAACAAAAAAAACAAAAgACAAAAAAAiAAQADAAAANgPBAAAAAAAAAAA
AKoPGgAAAAEAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIAACmDw4AAADxAAAAVQLUAdAC8AMQBQ8A
BPBIAAAAEgAK8AgAAAAFMAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHiMm0AlAEuRpAAvwES
ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkA
mcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4I
AAAARDXNAbAwpaQPAPADcAQAAAEA8QMIAAAAawEAAAcADTAPAAwE8AMAAA8AAvDoAwAA8AEI8AgA
AAAEAAAABHwAAA8AA/CAAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA
AAB8AAAFAAAADwAE8NQAAAASAArwCAAAAAJ8AAAgAgAAAwEL8JQAAAAEAAAAAAB/AIUB7wGBADBl
AQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAQABAD/AREAEQABAwQoAAA/
AwAACACAwzQAAACIAwAAAAC/AwAAAgBTAGwAaQBkAGUAIABJAG0AYQBnAGUAIABQAGwAYQBjAGUA
aABvAGwAZABlAHIAIAAxAAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDI
Cg8ABPA2AQAAEgAK8AgAAAADfAAAIAIAACMBC/CUAAAABAAAAAAAfwABAO8BgAAcFMgKgQCDcgEA
ggBBuQAAgwCDcgEAhABBuQAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQAvwEBAAEA/wERABEAAQMF
KAAAPwMAAAgAgMMoAAAAiAMAAAAAvwMAAAIATgBvAHQAZQBzACAAUABsAGEAYwBlAGgAbwBsAGQA
ZQByACAAMgAAAAAAEPAIAAAACwtZAj8PghUPABHwEAAAAAAAwwsIAAAAAQAAAAwAyAoPAA3wWgAA
AAAAnw8EAAAAAgAAAAAAoQ8UAAAAAQAAAAAAAAAAAAEAAAAAACAABAAAAKoPDgAAAAEAAAAHAAAA
AAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2ADEAWABA8ABPAuAQAAogwK8AgAAAAEfAAAAAoA
ANMAC/CEAAAAfwABAO8BgADUyMgKgQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQA
vwEAABAA/wEQABgAPwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQ
AGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAAAWFvgJmBFAFw8ADfB6AAAAAACfDwQA
AAAEAAAAAACgDwIAAAAqAAAAoQ8YAAAAAgAAAAAAAAgAAAIAAgAAAAAAIgAEAAwAAADYDwQAAAAA
AAAAAACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECAAApg8OAAAA8QAAAFUC1AHQAvAD
EAUPAATwSAAAABIACvAIAAAAAXwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQ
AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA
AJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA
AOsuCAAAAEQ1zQGwMKWkDwDwAzAEAAABAPEDCAAAAGwBAAAHAA0wDwAMBLADAAAPAALwqAMAABAC
CPAIAAAABAAAAASQAAAPAAPwQAMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK
8AgAAAAAkAAABQAAAA8ABPAWAQAAogwK8AgAAAACkAAAAAoAANMAC/BmAAAAfwABAO8BgABY2MgK
gQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQAvwEAABEA/wEAABgAPwMAAAgAgMMY
AAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA3AAAAAAAQ8AgAAAAVFvcJlxE/Fw8ADfCAAAAA
AACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgKAAIABwACAAAAAABjAAEABAAB
AAwAAADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAACQQECAEAAAAGAAAACQQECAAApg8OAAAA
8QAAAFUC1AHQAvADEAUPAATwuAAAABIACvAIAAAAA5AAACACAAADAQvweAAAAAQAAAAAAH8ABAHv
AYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8ABAAEAP8BAQARAAED
BCgAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAI
AAAAvgH8ApwOdgoPABHwEAAAAAAAwwsIAAAAAAAAAAsAyAoPAATwKgEAABIACvAIAAAABJAAACAC
AAAjAQvwhAAAAAQAAAAAAH8AAQDvAYAA6OLICoEAg3IBAIIAQbkAAIMAg3IBAIQAQbkAAIUAAAAA
AIcAAAAAAIgAAAAAAL8ABAAEAL8BAQARAP8BAQARAAEDBSgAAD8DAAAIAIDDGAAAAIgDAAAAAL8D
AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAACwvCAdYPghUPABHwEAAAAAAAwwsI
AAAAAQAAAAwAyAoPAA3wXgAAAAAAnw8EAAAAAgAAAAAAoQ8WAAAAAQAAAAAAACAAAAAAAQAAAAAA
IAAEAAAAqg8OAAAAAQAAAAcAAAAAAAkEBAgAAKYPFgAAAPgeAACQANQBIAHQAkAC8ANgAxAFgAQP
AATwSAAAABIACvAIAAAAAZAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQAL8B
EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ
AJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsu
CAAAAHHtyAFQwOTMDwDwAywCAAABAPEDCAAAAG0BAAAHAA0wDwAMBKwBAAAPAALwpAEAAFACCPAI
AAAAAwAAAAOgAAAPAAPwPAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA
AAAAoAAABQAAAA8ABPBYAAAAEgAK8AgAAAACoAAAIAIAAEMAC/AYAAAAfwAEAAQAvwEBAAEA/wEB
AAEAAQMEKAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDICg8ABPCkAAAA
EgAK8AgAAAADoAAAIAIAAFMAC/AeAAAAfwAAAAQAgABM48gKvwEBAAEA/wEBAAEAAQMFKAAAAAAQ
8AgAAAALC1kCPw+CFQ8AEfAQAAAAAADDCwgAAAABAAAADADICg8ADfA+AAAAAACfDwQAAAACAAAA
AAChDxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQPAATwSAAA
ABIACvAIAAAAAaAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQAL8BEgASAP8B
AAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAP
AIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAANw/
zQFwleIYDwDwA+EDAAABAPEDCAAAAGcBAAAHAA0wDwAMBGEDAAAPAALwWQMAAHACCPAIAAAAAwAA
AAOoAAAPAAPw8QIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAqAAA
BQAAAA8ABPBYAAAAEgAK8AgAAAACqAAAIAIAAEMAC/AYAAAAfwAEAAQAvwEBAAEA/wEBAAEAAQME
KAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDICg8ABPBZAgAAEgAK8AgA
AAADqAAAIAIAAFMAC/AeAAAAfwAAAAQAgADY88gKvwEAAAEA/wEAAAEAAQMFKAAAAAAQ8AgAAAAL
C1kCPw+CFQ8AEfAQAAAAAADDCwgAAAABAAAADADICg8ADfDzAQAAAACfDwQAAAACAAAAAACoD90A
AABJbml0JnByb2JlIGludGVyZmFjZSByZWZlciB0byB0aG9zZSBNU1JzIHdoaWNoIGluZGljYXRl
IG1jZSBjYXBhYml0aWVzL2NvbnRyb2wgcmVnczsNRXJyb3ItaW5mbyBpbnRlcmZhY2UgcmVmZXIg
dG8gdGhvc2UgTVNScyB3aGljaCBjb250YWluIGVycm9yIGluZm8gYW5kIG9ubHkgbWVhbmluZ2Z1
bCB3aGVuIGVycm9yIHJlYWwgb2NjdXIsIGUuZy4gTUNpX1NUQVRVUywgTUNpX0FERFI7DQAAoQ8U
AAAA3gAAAAAAAAAAAN4AAAAAACAABAAAAKoP3gAAAAoAAAAHAAAAAQAJBAQIGgAAAAYAAAAJBAQI
BAAAAAcAAAABAAkEBAgQAAAABgAAAAkEBAgDAAAABwAAAAEACQQECAEAAAAGAAAACQQECAoAAAAH
AAAAAQAJBAQICQAAAAYAAAAJBAQIBAAAAAcAAAABAAkEBAgmAAAABgAAAAkEBAgEAAAABwAAAAEA
CQQECEoAAAAGAAAACQQECAoAAAAHAAAAAQAJBAQIAgAAAAYAAAAJBAQICAAAAAcAAAABAAkEBAgC
AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBA8ABPBIAAAAEgAK8AgAAAABqAAAAAwAAIMAC/AwAAAA
gQEAAAAIgwEFAAAIkwHiMm0AlAEuRpAAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/
//8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8A
XwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA3D/NAcCfW0UPAPADwAQAAAEA8QMIAAAAcwEA
AAcADTAPAAwEgAQAAA8AAvB4BAAA4AII8AgAAAAEAAAABMQAAA8AA/AQBAAADwAE8CgAAAABAAnw
EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADEAAAFAAAADwAE8NQAAAASAArwCAAAAALEAAAg
AgAAAwEL8JQAAAAEAAAAAAB/AIUB7wGBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEA
AACIAAAAAAC/AAQABAD/AREAEQABAwQoAAA/AwAACACAwzQAAACIAwAAAAC/AwAAAgBTAGwAaQBk
AGUAIABJAG0AYQBnAGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAxAAAAAAAQ8AgAAAC+AfwC
nA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDJCg8ABPAyAQAAEgAK8AgAAAADxAAAIAIAABMBC/CO
AAAABAAAAAAAfwABAO8BgABkBskKgQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhQAAAAAAhwAAAAAA
iAAAAAAAvwAEAAQA/wERABEAAQMFKAAAPwMAAAgAgMMoAAAAiAMAAAAAvwMAAAIATgBvAHQAZQBz
ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAACwvCAdYPghUPABHwEAAAAAAA
wwsIAAAAAQAAAAwAyQoPAA3wXAAAAAAAnw8EAAAAAgAAAAAAoQ8WAAAAAQAAAAAAACAAAAAAAQAA
AAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPFAAAAPAeAADUASAB0AJAAvADYAMQBYAE
DwAE8MIBAACiDArwCAAAAATEAAAACgAA0wAL8IQAAAB/AAEA7wGAADAIyQqBAINyAQCCAEG5AACD
AINyAQCEAEG5AACHAAIAAAC/ABQAHwC/AQAAEAD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwA
aQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAA
ABUW9wmXET8XDwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA
AACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACL
ExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wiAAAAAAAnw8EAAAABAAAAAAAoA8CAAAA
KgAAAKEPHgAAAAIAAAAAAAAICgACAAcAAgAAAAAAYwAFAAQABQAMAAAA2A8EAAAAAAAAAAAAqg8a
AAAAAQAAAAcAAAAAAAQICQQBAAAABgAAAAkEBAgAAKYPFgAAAPEeAABVAuUBKwHrAlUCFgSAA0AF
qwQPAATwSAAAABIACvAIAAAAAcQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQ
AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDAUE0A
AAD/AIAAgAAPAPADEgYAAAEA8QMIAAAAdAEAAAcADTAPAAwEkgUAAA8AAvCKBQAAAAMI8AgAAAAD
AAAAA9AAAA8AA/AiBQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADQ
AAAFAAAADwAE8F4AAAASAArwCAAAAALQAAAgAgAAUwAL8B4AAAB/AAQABAC/AQEAAQD/AQEAAQAB
AwQoAACIAwAAAAAAABDwCAAAAL4B/AKcDnYKDwAR8BAAAAAAAMMLCAAAAAAAAAALAMkKDwAE8IQE
AAASAArwCAAAAAPQAAAgAgAAYwAL8CQAAAB/AAAABACAABwfyQq/AQAAAQD/AQAAAQABAwUoAACI
AwAAAAAAABDwCAAAAAsLWQI/D4IVDwAR8BAAAAAAAMMLCAAAAAEAAAAMAMkKDwAN8BgEAAAAAJ8P
BAAAAAIAAAAAAKAP6gIAACoAIABJAG4AaQB0ACYAcAByAG8AYgBlACAAaQBuAHQAZQByAGYAYQBj
AGUAIAByAGUAZgBlAHIAIAB0AG8AIAB0AGgAbwBzAGUAIABNAFMAUgBzACAAdwBoAGkAYwBoACAA
aQBuAGQAaQBjAGEAdABlACAAbQBjAGUAIABjAGEAcABhAGIAaQB0AGkAZQBzAC8AYwBvAG4AdABy
AG8AbAAgAHIAZQBnAHMAOwANACoAIABFAHIAcgBvAHIALQBpAG4AZgBvACAAaQBuAHQAZQByAGYA
YQBjAGUAIAByAGUAZgBlAHIAIAB0AG8AIAB0AGgAbwBzAGUAIABNAFMAUgBzACAAdwBoAGkAYwBo
ACAAYwBvAG4AdABhAGkAbgAgAGUAcgByAG8AcgAgAGkAbgBmAG8AIABhAG4AZAAgAG8AbgBsAHkA
IABtAGUAYQBuAGkAbgBnAGYAdQBsACAAdwBoAGUAbgAgAGUAcgByAG8AcgAgAHIAZQBhAGwAIABv
AGMAYwB1AHIALAAgAGUALgBnAC4AIABNAEMAaQBfAFMAVABBAFQAVQBTACwAIABNAEMAaQBfAEEA
RABEAFIAOwANAA0AKgAqACAASQBmACAAdwBlACAAcwBlAHQAIABNAEMARwBfAEMATQBDAEkAXwBQ
AD0AMQAsACAATQBDAGkAXwBDAFQATAAyACAAdwBvAHUAbABkACAAYQBsAHMAbwAgAGIAZQAgAGUA
bQB1AGwAYQB0AGUAZAAgAGEAcwAgAEMATQBDAEkAIABlAG4AYQBiAGwAZQBkACwAIABiAHUAdAAg
AGgAeQBwAGUAcgB2AGkAcwBvAHIAIABzAHQAaQBsAGwAIABkAG8AZQBzACAAbgBvAHQAIABpAG4A
agBlAGMAdAAgAEMATQBDAEkAIAB0AG8AIABnAHUAZQBzAHQAIABzAGkAbgBjAGUAIABpAHQAGSBz
ACAAcABvAGkAbgB0AGwAZQBzAHMAAAChDxQAAAB2AQAAAAAAAAAAdgEAAAAAIAAEAAAAqg/2AAAA
AgAAAAYAAAAJBAQICgAAAAcAAAABAAkEBAgaAAAABgAAAAkEBAgEAAAABwAAAAEACQQECBAAAAAG
AAAACQQECAMAAAAHAAAAAQAJBAQIAQAAAAYAAAAJBAQICgAAAAcAAAABAAkEBAgJAAAABgAAAAkE
BAgEAAAABwAAAAEACQQECCgAAAAGAAAACQQECAQAAAAHAAAAAQAJBAQISgAAAAYAAAAJBAQICgAA
AAcAAAABAAkEBAgCAAAABgAAAAkEBAgIAAAABwAAAAEACQQECAIAAAAGAAAACQQECAQAAAAHAAAA
AAAECAkEkQAAAAYAAAAJBAQIDwAE8EgAAAASAArwCAAAAAHQAAAADAAAgwAL8DAAAACBAQAAAAiD
AQUAAAiTAeIybQCUAS5GkAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA
gICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQ
AFQAMQAwAAAAixMQAAAAAADrLggAAADcP80BsO7dMwAAcheAAAAAAQBwAAAAAADRkgAA6RsAAKrW
AAD2CQIA9kACAFIDAwAMACAAhg0EACcUBAAPAEAALAACAPP2AgAoDwMApBgEABQAYACl3QAAHB0E
ABkuAgCjOwIAg+wCAFQhBAAbABAAiCMEAB0AEAAJGAMAIQBAAOEwAwBxJwQAWx0DADksBAAAAPUP
HAAAAHMBAACPIAADAAAAAFMyBAABAAAAJgAAAAEAxTEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJytAAAM
AAAAAQAAAGgAAAACAAAAcAAAAAQAAACIAAAABwAAAKQAAAAIAAAAwAAAAAkAAADQAAAAEgAAANwA
AAAKAAAAAAEAAAwAAAAMAQAADQAAABgBAAAPAAAAJAEAABEAAAAsAQAAAgAAAKgDAAAeAAAAEAAA
AFZlcmRhbmEgQm9sZCAzMAAeAAAAFAAAAEludGVsIENvcnBvcmF0aW9uAAAAHgAAABQAAAB3aGl0
ZV9pbnRlbF9vbmx5AAAAAB4AAAAIAAAAamxpdTE0AAAeAAAABAAAADMzMwAeAAAAHAAAAE1pY3Jv
c29mdCBPZmZpY2UgUG93ZXJQb2ludABAAAAAQKMwKzwHAABAAAAAsG+pB+4oxgFAAAAAQAtUoPxO
zQEDAAAAgAQAAEcAAABorAAA/////wMAAAAIADsN7AkAAAEACQAAAyxWAAABAKEnAAAAABYQAAAm
Bg8AIiBXTUZDAQAAAAAAAQBV8QAAAAADAAAAACAAADw4AAA8WAAAAQAAAGwAAAAAAAAAAAAAAP8C
AAA/AgAAAAAAAAAAAAAAMgAAADIAACBFTUYAAAEAPFgAAAYAAAACAAAAAAAAAAAAAAAAAQAAgAcA
ADgEAABAAQAA8AAAAAAAAAAAAAAAAAAAAADiBACAqQMAMQAAABAEAAABAAAAAAMAAQAAAACAAAAA
AIAAAICAAAAAAIAAgACAAACAgADAwMAAwNzAAKbK8AAEBAQACAgIAAwMDAAREREAFhYWABwcHAAi
IiIAKSkpAFVVVQBNTU0AQkJCADk5OQD/fIAA/1BQANYAkwDM7P8A79bGAOfn1gCtqZAAMwAAAGYA
AACZAAAAzAAAAAAzAAAzMwAAZjMAAJkzAADMMwAA/zMAAABmAAAzZgAAZmYAAJlmAADMZgAA/2YA
AACZAAAzmQAAZpkAAJmZAADMmQAA/5kAAADMAAAzzAAAZswAAJnMAADMzAAA/8wAAGb/AACZ/wAA
zP8AAAAAMwAzADMAZgAzAJkAMwDMADMA/wAzAAAzMwAzMzMAZjMzAJkzMwDMMzMA/zMzAABmMwAz
ZjMAZmYzAJlmMwDMZjMA/2YzAACZMwAzmTMAZpkzAJmZMwDMmTMA/5kzAADMMwAzzDMAZswzAJnM
MwDMzDMA/8wzADP/MwBm/zMAmf8zAMz/MwD//zMAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYAADNm
ADMzZgBmM2YAmTNmAMwzZgD/M2YAAGZmADNmZgBmZmYAmWZmAMxmZgAAmWYAM5lmAGaZZgCZmWYA
zJlmAP+ZZgAAzGYAM8xmAJnMZgDMzGYA/8xmAAD/ZgAz/2YAmf9mAMz/ZgD/AMwAzAD/AACZmQCZ
M5kAmQCZAMwAmQAAAJkAMzOZAGYAmQDMM5kA/wCZAABmmQAzZpkAZjOZAJlmmQDMZpkA/zOZADOZ
mQBmmZkAmZmZAMyZmQD/mZkAAMyZADPMmQBmzGYAmcyZAMzMmQD/zJkAAP+ZADP/mQBmzJkAmf+Z
AMz/mQD//5kAAADMADMAmQBmAMwAmQDMAMwAzAAAM5kAMzPMAGYzzACZM8wAzDPMAP8zzAAAZswA
M2bMAGZmmQCZZswAzGbMAP9mmQAAmcwAM5nMAGaZzACZmcwAzJnMAP+ZzAAAzMwAM8zMAGbMzACZ
zMwAzMzMAP/MzAAA/8wAM//MAGb/mQCZ/8wAzP/MAP//zAAzAMwAZgD/AJkA/wAAM8wAMzP/AGYz
/wCZM/8AzDP/AP8z/wAAZv8AM2b/AGZmzACZZv8AzGb/AP9mzAAAmf8AM5n/AGaZ/wCZmf8AzJn/
AP+Z/wAAzP8AM8z/AGbM/wCZzP8AzMz/AP/M/wAz//8AZv/MAJn//wDM//8A/2ZmAGb/ZgD//2YA
Zmb/AP9m/wBm//8ApQAhAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx
8fEA+Pj4AP/78ACgoKQAgICAAP8AAAAA/wAA//8AAAAA/wD/AP8AAP//AP///wAwAAAADAAAAAEA
AAAVAAAADAAAAAMAAABNAAAAlE8AAAAAAAAAAAAA/wIAAD8CAAAAAAAAAAAAAAADAABAAgAAIADM
AAAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAA////AAAAAABsAAAAKAQAAJQEAAAASwAA
oAAAAHgAAAAoAAAAoAAAAHgAAAABAAgAAAAAAABLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAA
gAAAAICAAIAAAACAAIAAgIAAAMDAwADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIi
IgApKSkAVVVVAE1NTQBCQkIAOTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMAAABm
AAAAmQAAAMwAADMAAAAzMwAAM2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABmzAAAZv8A
AJkAAACZMwAAmWYAAJmZAACZzAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8AAP9mAAD/mQAA
/8wAMwAAADMAMwAzAGYAMwCZADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMzzAAzM/8AM2YAADNm
MwAzZmYAM2aZADNmzAAzZv8AM5kAADOZMwAzmWYAM5mZADOZzAAzmf8AM8wAADPMMwAzzGYAM8yZ
ADPMzAAzzP8AM/8zADP/ZgAz/5kAM//MADP//wBmAAAAZgAzAGYAZgBmAJkAZgDMAGYA/wBmMwAA
ZjMzAGYzZgBmM5kAZjPMAGYz/wBmZgAAZmYzAGZmZgBmZpkAZmbMAGaZAABmmTMAZplmAGaZmQBm
mcwAZpn/AGbMAABmzDMAZsyZAGbMzABmzP8AZv8AAGb/MwBm/5kAZv/MAMwA/wD/AMwAmZkAAJkz
mQCZAJkAmQDMAJkAAACZMzMAmQBmAJkzzACZAP8AmWYAAJlmMwCZM2YAmWaZAJlmzACZM/8AmZkz
AJmZZgCZmZkAmZnMAJmZ/wCZzAAAmcwzAGbMZgCZzJkAmczMAJnM/wCZ/wAAmf8zAJnMZgCZ/5kA
mf/MAJn//wDMAAAAmQAzAMwAZgDMAJkAzADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADM
ZjMAmWZmAMxmmQDMZswAmWb/AMyZAADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzM
mQDMzMwAzMz/AMz/AADM/zMAmf9mAMz/mQDM/8wAzP//AMwAMwD/AGYA/wCZAMwzAAD/MzMA/zNm
AP8zmQD/M8wA/zP/AP9mAAD/ZjMAzGZmAP9mmQD/ZswAzGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA
/5n/AP/MAAD/zDMA/8xmAP/MmQD/zMwA/8z/AP//MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/
ZmYA/2b/AP//ZgAhAKUAX19fAHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx
8QD4+PgA8Pv/AKSgoACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AKaKpoqmioqKpoqm
iqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaK
poqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqm
ioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqsimVDPEMAQzxDAGysiqyKrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqt
iqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqzvrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrIqKpqyKrIqtiqyKrYqsiq2KiopsAEMAQwBDAB1Ciq2KrIqtpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqK
poqKiqaKioqmioqKpoqKiqaKioqmiu/v7+/viu/v7++mioqKpoqKiqaKioqmrIqtiqyKrIqsiqyK
rIqsiqyKrYqsiq2miq2KZUNDbUNtQ20AQ4qmioqspqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqt
iqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqspoqKrKaKiouKi4uLiouLi6aKioqm
rIqmimwAIgBDAAAAAEOKrIqtiqyKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqK
poqKiqaKioqmioqKpoqKiqaKioqmioqLi4uLi4uLi5GLs4u0i7SRtIusiq2KrIqKrIpmQzxDPEJC
QzxsioqKpoqmrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqt
iqyKrYqsiq2KrIqtbIuKi6aKiotliouLpouKi4qKi5GLi6atioqss4q0tLu0tIqti4qtiqyKraaK
ioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqK
iqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqK
pouKrIq0kbWRtIu1kbSRtZG0kbu1u5GspoqtioqzkK2Ls7S0pq2KpoqKiqasiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqxsi6aKkbWStYu1
kbWRu5G7kbuRtbS0pqyKpoqzs7S0tLS0tLOLiqyKrYqspoqmioqKpoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqm
iqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKi4qsi7uLs4q0tLOLs4uzkLOLs4uz
i62KiqyKiq20tbS1tLSLs4qKiqaKiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrWyLiouKi4uRi4uKi4uLi4uLi6aKpoqKrYqKirOKs4uz
iq2ztIuKrYqsiq2mioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaLi4tti4u0kbSLs4u0kbSLtIutiqyKraaKrYqLiqati7OLs4uziqaKiqym
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiqymioqtioqKrIqLioqmioqspoqKiqasiqaKs62zi7Ots4uzioqsiq2KrIqKpoqmiqaKioqm
iqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqspoqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyK
iqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqK
pqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqm
rIqKpqyKtLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0
tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1
tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tf//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////4qK/4r/////////
/////////////4qK//////////////////////////+Kiv//iv///////4qK////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////iv+KioqK//+Kiv//////ior/iv//iv//ioqK//+K
iv////+K/4qKiv+K/4r//4qKiv//iooWEAAAJgYPACIgV01GQwEAAAAAAAEAAAAAAAAAAwAAAAAg
AAA8GAAAPFgAAP+KioqKior//4qK//+Kiv+Kiv+K/4qKioqKioqKiv//iv+K////////////////
////////////////////////////////////////////////////////////////////////////
////iv+K/4qKiv+Kiv////+Kiv//ior/ior/ioqKiv+Kiv///4r/iv+K//+KioqK/4qKior/ior/
/4qK/4qKiv+Kiv+K/4qKioqKiv+Kior/iv+KioqKior//4r/////////////////////////////
/////////////////////////////////////////////////////////////////4r/////////
//////+K/////////4r///////////////////////////+K////////////////////////////
/4qKiv///4r///+K////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////+K//////////////////+Kiv//////iv//////
////////ior/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////iv+Kior///+K/4qK//+KioqKiv//ior/////ioqKiv//ioqKior//4qK/4qK
ioqK//+Kiv+Kiv//iv+KioqKioqKior//4r/iv//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/4r/ior/////iv+Kior/iv+KioqK/4qK////iv+KioqK/4r/ioqKiv+Kiv//ioqK//+K/4qKioqK
/4r/ioqK/4r/ioqKioqK//+K////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////+K/////////4r/
/////////////////////////////////////////////4r//////4qKiv////+K////iv//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////4qK////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////4r//4r//4qKiv///4r/////iv//////////ioqKiv//ioqK////
/4qKiv//ioqKioqK//+K/4qKiv////+K////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////iv+K/4r/////iv+K////ior//4r//4r/iv///////4r///////+K//+Kiv////+K
iv//ior//4r//4r/iv//////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////+K
//+KioqK/4r/iv///4r/iv+KioqK/4r///////+Kior/////iv//ioqKioqK/////4qK//+K//+K
/4r/////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////+K/4r//4qK//+Kior/
/4r//4r/iv+Kiv+K////////iv///////4r//4r/ior//4qK//+K/4qKiv//ioqK////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////iv+K/////////////////////4r//4r/
/4qKior//4qKiv////+Kior/////////////iv//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////NAwAACYG
DwBeGFdNRkMBAAAAAAABAAAAAAAAAAMAAAA8GAAAAAAAADxYAAD/////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8OAAAAFAQAAAABAAAQAAAAAAAAAIAAAAAAgAAAgIAAAAAAgACAAIAAAICAAMDA
wADA3MAApsrwAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIiIgApKSkAVVVVAE1NTQBCQkIAOTk5
AP98gAD/UFAA1gCTAMzs/wDv1sYA5+fWAK2pkAAzAAAAZgAAAJkAAADMAAAAADMAADMzAABmMwAA
mTMAAMwzAAD/MwAAAGYAADNmAABmZgAAmWYAAMxmAAD/ZgAAAJkAADOZAABmmQAAmZkAAMyZAAD/
mQAAAMwAADPMAABmzAAAmcwAAMzMAAD/zAAAZv8AAJn/AADM/wAAAAAzADMAMwBmADMAmQAzAMwA
MwD/ADMAADMzADMzMwBmMzMAmTMzAMwzMwD/MzMAAGYzADNmMwBmZjMAmWYzAMxmMwD/ZjMAAJkz
ADOZMwBmmTMAmZkzAMyZMwD/mTMAAMwzADPMMwBmzDMAmcwzAMzMMwD/zDMAM/8zAGb/MwCZ/zMA
zP8zAP//MwAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZgAAM2YAMzNmAGYzZgCZM2YAzDNmAP8zZgAA
ZmYAM2ZmAGZmZgCZZmYAzGZmAACZZgAzmWYAZplmAJmZZgDMmWYA/5lmAADMZgAzzGYAmcxmAMzM
ZgD/zGYAAP9mADP/ZgCZ/2YAzP9mAP8AzADMAP8AAJmZAJkzmQCZAJkAzACZAAAAmQAzM5kAZgCZ
AMwzmQD/AJkAAGaZADNmmQBmM5kAmWaZAMxmmQD/M5kAM5mZAGaZmQCZmZkAzJmZAP+ZmQAAzJkA
M8yZAGbMZgCZzJkAzMyZAP/MmQAA/5kAM/+ZAGbMmQCZ/5kAzP+ZAP//mQAAAMwAMwCZAGYAzACZ
AMwAzADMAAAzmQAzM8wAZjPMAJkzzADMM8wA/zPMAABmzAAzZswAZmaZAJlmzADMZswA/2aZAACZ
zAAzmcwAZpnMAJmZzADMmcwA/5nMAADMzAAzzMwAZszMAJnMzADMzMwA/8zMAAD/zAAz/8wAZv+Z
AJn/zADM/8wA///MADMAzABmAP8AmQD/AAAzzAAzM/8AZjP/AJkz/wDMM/8A/zP/AABm/wAzZv8A
ZmbMAJlm/wDMZv8A/2bMAACZ/wAzmf8AZpn/AJmZ/wDMmf8A/5n/AADM/wAzzP8AZsz/AJnM/wDM
zP8A/8z/ADP//wBm/8wAmf//AMz//wD/ZmYAZv9mAP//ZgBmZv8A/2b/AGb//wClACEAX19fAHd3
dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx8QD4+PgA//vwAKCgpACAgIAA/wAA
AAD/AAD//wAAAAD/AP8A/wAA//8A////ABQEAAAEAAAAAwEIAAUAAAALAgAAAAAFAAAADAJAAgAD
CQIAAPcAAAMCAQAAAACAAAAAAIAAAICAAAAAAIAAgACAAACAgADAwMAAwNzAAKbK8AAEBAQACAgI
AAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQD/fIAA/1BQANYAkwDM7P8A
79bGAOfn1gCtqZAAMwAAAGYAAACZAAAAzAAAAAAzAAAzMwAAZjMAAJkzAADMMwAA/zMAAABmAAAz
ZgAAZmYAAJlmAADMZgAA/2YAAACZAAAzmQAAZpkAAJmZAADMmQAA/5kAAADMAAAzzAAAZswAAJnM
AADMzAAA/8wAAGb/AACZ/wAAzP8AAAAAMwAzADMAZgAzAJkAMwDMADMA/wAzAAAzMwAzMzMAZjMz
AJkzMwDMMzMA/zMzAABmMwAzZjMAZmYzAJlmMwDMZjMA/2YzAACZMwAzmTMAZpkzAJmZMwDMmTMA
/5kzAADMMwAzzDMAZswzAJnMMwDMzDMA/8wzADP/MwBm/zMAmf8zAMz/MwD//zMAAABmADMAZgBm
AGYAmQBmAMwAZgD/AGYAADNmADMzZgBmM2YAmTNmAMwzZgD/M2YAAGZmADNmZgBmZmYAmWZmAMxm
ZgAAmWYAM5lmAGaZZgCZmWYAzJlmAP+ZZgAAzGYAM8xmAJnMZgDMzGYA/8xmAAD/ZgAz/2YAmf9m
AMz/ZgD/AMwAzAD/AACZmQCZM5kAmQCZAMwAmQAAAJkAMzOZAGYAmQDMM5kA/wCZAABmmQAzZpkA
ZjOZAJlmmQDMZpkA/zOZADOZmQBmmZkAmZmZAMyZmQD/mZkAAMyZADPMmQBmzGYAmcyZAMzMmQD/
zJkAAP+ZADP/mQBmzJkAmf+ZAMz/mQD//5kAAADMADMAmQBmAMwAmQDMAMwAzAAAM5kAMzPMAGYz
zACZM8wAzDPMAP8zzAAAZswAM2bMAGZmmQCZZswAzGbMAP9mmQAAmcwAM5nMAGaZzACZmcwAzJnM
AP+ZzAAAzMwAM8zMAGbMzACZzMwAzMzMAP/MzAAA/8wAM//MAGb/mQCZ/8wAzP/MAP//zAAzAMwA
ZgD/AJkA/wAAM8wAMzP/AGYz/wCZM/8AzDP/AP8z/wAAZv8AM2b/AGZmzACZZv8AzGb/AP9mzAAA
mf8AM5n/AGaZ/wCZmf8AzJn/AP+Z/wAAzP8AM8z/AGbM/wCZzP8AzMz/AP/M/wAz//8AZv/MAJn/
/wDM//8A/2ZmAGb/ZgD//2YAZmb/AP9m/wBm//8ApQAhAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKy
ANfX1wDd3d0A4+PjAOrq6gDx8fEA+Pj4AP/78ACgoKQAgICAAP8AAAAA/wAA//8AAAAA/wD/AP8A
AP//AP///wD///8AAAAAAAQAAAA0AgAABAAAAAcBAwChJwAAQQsgAMwAeACgAAAAAABAAgADAAAA
ACgAAACgAAAAeAAAAAEACAAAAAAAAEsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA
gAAAAIAAgACAgAAAwMDAAMDcwADwyqYABAQEAAgICAAMDAwAERERABYWFgAcHBwAIiIiACkpKQBV
VVUATU1NAEJCQgA5OTkAgHz/AFBQ/wCTANYA/+zMAMbW7wDW5+cAkKmtAAAAMwAAAGYAAACZAAAA
zAAAMwAAADMzAAAzZgAAM5kAADPMAAAz/wAAZgAAAGYzAABmZgAAZpkAAGbMAABm/wAAmQAAAJkz
AACZZgAAmZkAAJnMAACZ/wAAzAAAAMwzAADMZgAAzJkAAMzMAADM/wAA/2YAAP+ZAAD/zAAzAAAA
MwAzADMAZgAzAJkAMwDMADMA/wAzMwAAMzMzADMzZgAzM5kAMzPMADMz/wAzZgAAM2YzADNmZgAz
ZpkAM2bMADNm/wAzmQAAM5kzADOZZgAzmZkAM5nMADOZ/wAzzAAAM8wzADPMZgAzzJkAM8zMADPM
/wAz/zMAM/9mADP/mQAz/8wAM///AGYAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYzAABmMzMAZjNm
AGYzmQBmM8wAZjP/AGZmAABmZjMAZmZmAGZmmQBmZswAZpkAAGaZMwBmmWYAZpmZAGaZzABmmf8A
ZswAAGbMMwBmzJkAZszMAGbM/wBm/wAAZv8zAGb/mQBm/8wAzAD/AP8AzACZmQAAmTOZAJkAmQCZ
AMwAmQAAAJkzMwCZAGYAmTPMAJkA/wCZZgAAmWYzAJkzZgCZZpkAmWbMAJkz/wCZmTMAmZlmAJmZ
mQCZmcwAmZn/AJnMAACZzDMAZsxmAJnMmQCZzMwAmcz/AJn/AACZ/zMAmcxmAJn/mQCZ/8wAmf//
AMwAAACZADMAzABmAMwAmQDMAMwAmTMAAMwzMwDMM2YAzDOZAMwzzADMM/8AzGYAAMxmMwCZZmYA
zGaZAMxmzACZZv8AzJkAAMyZMwDMmWYAzJmZAMyZzADMmf8AzMwAAMzMMwDMzGYAzMyZAMzMzADM
zP8AzP8AAMz/MwCZ/2YAzP+ZAMz/zADM//8AzAAzAP8AZgD/AJkAzDMAAP8zMwD/M2YA/zOZAP8z
zAD/M/8A/2YAAP9mMwDMZmYA/2aZAP9mzADMZv8A/5kAAP+ZMwD/mWYA/5mZAP+ZzAD/mf8A/8wA
AP/MMwD/zGYA/8yZAP/MzAD/zP8A//8zAMz/ZgD//5kA///MAGZm/wBm/2YAZv//AP9mZgD/Zv8A
//9mACEApQBfX18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAPj4+ADw
+/8ApKCgAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8ApoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqm
iqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaK
poqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqyKZUM8QwBDPEMAbKyKrIqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrO+tiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqs
ioqmrIqsiq2KrIqtiqyKrYqKimwAQwBDAEMAHUKKrYqsiq2mioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaK7+/v7++K7+/v76aKioqmioqKpoqKiqasiq2KrIqsiqyKrIqsiqyKrIqt
iqyKraaKrYplQ0NtQ21DbQBDiqaKiqymrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiqymioqspoqKi4qLi4uKi4uLpoqKiqasiqaKbAAi
AEMAAAAAQ4qsiq2KrIqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaKiouLi4uLi4uLkYuzi7SLtJG0i6yKrYqsioqsimZDPEM8QkJDPGyKioqm
iqatiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq1si4qLpoqKi2WKi4umi4qLioqLkYuLpq2KiqyzirS0u7S0iq2Liq2KrIqtpoqKiqaKiqym
ioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaK
ioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmi4qsirSR
tZG0i7WRtJG1kbSRu7W7kaymiq2KirOQrYuztLSmrYqmioqKpqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrGyLpoqRtZK1i7WRtZG7kbuR
u5G1tLSmrIqmirOztLS0tLS0s4uKrIqtiqymiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqm
iqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqLiqyLu4uzirS0s4uzi7OQs4uzi7OLrYqKrIqK
rbS1tLW0tIuzioqKpoqKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtbIuKi4qLi5GLi4qLi4uLi4uLpoqmioqtioqKs4qzi7OKrbO0i4qt
iqyKraaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqm
ioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpouLi22Li7SRtIuzi7SRtIu0i62KrIqtpoqtiouKpq2Ls4uzi7OKpoqKrKasiq2KrIqt
iqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrKaK
iq2KioqsiouKiqaKiqymioqKpqyKpoqzrbOLs62zi7OKiqyKrYqsioqmiqaKpoqKiqaKpoqmioqK
poqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqm
iqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqymioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqas
ioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyK
iqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIq0
u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7
tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0
tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////ior/iv//////////////////
////ior//////////////////////////4qK//+K////////ior/////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////+K/4qKior//4qK//////+Kiv+K//+K//+Kior//4qK/////4r/
ioqK/4r/iv//ioqK//+Kiv+KioqKior//4qK//+Kiv+Kiv+K/4qKioqKioqKiv//iv+K////////
////////////////////////////////////////////////////////////////////////////
////////////iv+K/4qKiv+Kiv////+Kiv//ior/ior/ioqKiv+Kiv///4r/iv+K//+KioqK/4qK
ior/ior//4qK/4qKiv+Kiv+K/4qKioqKiv+Kior/iv+KioqKior//4r/////////////////////
/////////////////////////////////////////////////////////////////////////4r/
//////////////+K/////////4r///////////////////////////+K////////////////////
/////////4qKiv///4r///+K////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////+K//////////////////+Kiv//////
iv//////////////ior/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////iv+Kior///+K/4qK//+KioqKiv//ior/////ioqKiv//ioqKior/
/4qK/4qKioqK//+Kiv+Kiv//iv+KioqKioqKior//4r/iv//////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////4r/ior/////iv+Kior/iv+KioqK/4qK////iv+KioqK/4r/ioqKiv+Kiv//ioqK//+K
/4qKioqK/4r/ioqK/4r/ioqKioqK//+K////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////+K////
/////4r//////////////////////////////////////////////4r//////4qKiv////+K////
iv//////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////4qK////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////4r//4r//4qKiv///4r/////iv//////////ioqKiv//
ioqK/////4qKiv//ioqKioqK//+K/4qKiv////+K////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////iv+K/4r/////iv+K////ior//4r//4r/iv///////4r///////+K//+K
iv////+Kiv//ior//4r//4r/iv//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////+K//+KioqK/4r/iv///4r/iv+KioqK/4r///////+Kior/////iv//ioqKioqK/////4qK
//+K//+K/4r/////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////+K/4r//4qK
//+Kior//4r//4r/iv+Kiv+K////////iv///////4r//4r/ior//4qK//+K/4qKiv//ioqK////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////iv+K////////////////////
/4r//4r//4qKior//4qKiv////+Kior/////////////iv//////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIA
AAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5kAwAAIAMAABAAAAABAAAAiAAA
AAMAAACQAAAADwAAAKgAAAAEAAAAxAAAAAYAAADMAAAABwAAANQAAAAIAAAA3AAAAAkAAADkAAAA
CgAAAOwAAAAXAAAA9AAAAAsAAAD8AAAAEAAAAAQBAAATAAAADAEAABYAAAAUAQAADQAAABwBAAAM
AAAAvgIAAAIAAACoAwAAHgAAABAAAABPbi1zY3JlZW4gU2hvdwAAHgAAABQAAABJbnRlbCBDb3Jw
b3JhdGlvbgAAAAMAAACtoQYAAwAAADkBAAADAAAADgAAAAMAAAAIAAAAAwAAAAAAAAADAAAAAAAA
AAMAAAAPJwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAFQAAAAgAAABWZXJk
YW5hAAYAAABBcmlhbAAKAAAAV2luZ2RpbmdzAAsAAABNUyBQR290aGljAAUAAADLzszlAAgAAABD
YWxpYnJpABEAAAB3aGl0ZV9pbnRlbF9vbmx5ABAAAABYZW4gdk1DRSBEZXNpZ24AFQAAAFhlbiBN
Q0UgQXJjaGl0ZWN0dXJlAAsAAABCYWNrZ3JvdW5kABYAAABYZW4gdk1DRSBhcHByb2FjaCAoMSkA
FgAAAFhlbiB2TUNFIGFwcHJvYWNoICgyKQAIAAAAU2xpZGUgNgAbAAAAUG9pbnQgMTogTVNSIGVt
dWxhdGlvbiAoMSkAGwAAAFBvaW50IDE6IE1TUiBlbXVsYXRpb24gKDIpABsAAABQb2ludCAxOiBN
U1IgZW11bGF0aW9uICgzKQAYAAAAUG9pbnQgMjogbGl2ZSBtaWdyYXRpb24AFwAAAFBvaW50IDM6
IE1DRSBpbmplY3Rpb24ACQAAAFNsaWRlIDEyAAkAAABNQ0UgTVNScwAPAAAAWGVuIFJBUyBzdGF0
dXMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAYAAAAeAAAAEAAAAERlc2lnbiBUZW1w
bGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAAOAAAAAACUAAAABQAAAAAAAAAw
AAAAAQAAAGgAAAACAAAAcAAAAAMAAAB8AAAABAAAAIgAAAADAAAAAgAAAA8AAABTUFNEZXNjcmlw
dGlvbgADAAAABgAAAE93bmVyAAQAAAAHAAAAU3RhdHVzAAIAAACoAwAAHgAAAAQAAAAAAAAAHgAA
AAQAAAAAAAAAHgAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPHgAAABQAAABfwJHj2zIEAAYA9AMDAL8KamxpdTE0
CAAAAGoAbABpAHUAMQA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA
AAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAA
ABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA
KAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2
AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQA
AABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAA
AFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAA
YQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABv
AAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0A
AAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAA
AIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAA
mgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACo
AAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAAtQAAALYA
AAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAAxAAA
AMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA0AAAANEAAADSAAAA
0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA3wAAAOAAAADh
AAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAOwAAADtAAAA7gAAAO8A
AADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgAAAD5AAAA+gAAAPsAAAD8AAAA/QAA
AP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcBAAAIAQAACQEAAAoBAAALAQAA
DAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAa
AQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAACgB
AAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAAMAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEA
ADcBAAD+////OQEAADoBAAA7AQAAPAEAAD0BAAA+AQAAPwEAAEABAABBAQAAQgEAAEMBAABEAQAA
RQEAAEYBAABHAQAASAEAAEkBAABKAQAASwEAAEwBAABNAQAATgEAAE8BAABQAQAAUQEAAFIBAABT
AQAAVAEAAFUBAABWAQAAVwEAAFgBAABZAQAAWgEAAFsBAABcAQAAXQEAAF4BAABfAQAAYAEAAGEB
AABiAQAAYwEAAGQBAABlAQAAZgEAAGcBAABoAQAAaQEAAGoBAABrAQAAbAEAAG0BAABuAQAAbwEA
AHABAABxAQAAcgEAAHMBAAB0AQAAdQEAAHYBAAB3AQAAeAEAAHkBAAB6AQAAewEAAHwBAAB9AQAA
fgEAAH8BAACAAQAAgQEAAIIBAACDAQAAhAEAAIUBAACGAQAAhwEAAIgBAACJAQAAigEAAIsBAACM
AQAAjQEAAI4BAACPAQAAkAEAAJEBAACSAQAAkwEAAJQBAACVAQAAlgEAAJcBAACYAQAAmQEAAJoB
AACbAQAAnAEAAJ0BAACeAQAAnwEAAKABAAChAQAAogEAAKMBAACkAQAApQEAAKYBAACnAQAAqAEA
AKkBAACqAQAAqwEAAKwBAACtAQAArgEAAK8BAACwAQAAsQEAALIBAACzAQAAtAEAALUBAAC2AQAA
twEAALgBAAC5AQAAugEAALsBAAC8AQAAvQEAAL4BAAC/AQAAwAEAAMEBAADCAQAAwwEAAMQBAADF
AQAAxgEAAMcBAADIAQAAyQEAAMoBAADLAQAAzAEAAM0BAADOAQAAzwEAANABAADRAQAA0gEAANMB
AADUAQAA1QEAANYBAADXAQAA2AEAANkBAADaAQAA2wEAANwBAADdAQAA3gEAAN8BAADgAQAA4QEA
AOIBAADjAQAA5AEAAOUBAADmAQAA5wEAAOgBAADpAQAA6gEAAOsBAADsAQAA7QEAAO4BAADvAQAA
8AEAAPEBAADyAQAA8wEAAPQBAAD1AQAA9gEAAPcBAAD4AQAA+QEAAPoBAAD7AQAA/AEAAP0BAAD+
AQAA/wEAAAACAAABAgAAAgIAAAMCAAAEAgAABQIAAAYCAAAHAgAACAIAAAkCAAAKAgAACwIAAAwC
AAANAgAADgIAAA8CAAAQAgAAEQIAABICAAATAgAAFAIAABUCAAAWAgAAFwIAABgCAAAZAgAAGgIA
ABsCAAAcAgAAHQIAAB4CAAAfAgAAIAIAACECAAAiAgAAIwIAACQCAAAlAgAAJgIAACcCAAAoAgAA
KQIAACoCAAArAgAALAIAAC0CAAAuAgAALwIAADACAAAxAgAAMgIAADMCAAA0AgAANQIAADYCAAA3
AgAAOAIAADkCAAA6AgAAOwIAADwCAAA9AgAAPgIAAD8CAABAAgAAQQIAAEICAABDAgAARAIAAEUC
AABGAgAARwIAAEgCAABJAgAASgIAAEsCAABMAgAATQIAAE4CAABPAgAAUAIAAFECAABSAgAAUwIA
AFQCAABVAgAAVgIAAFcCAABYAgAAWQIAAFoCAABbAgAAXAIAAF0CAABeAgAAXwIAAGACAABhAgAA
YgIAAGMCAABkAgAAZQIAAGYCAABnAgAAaAIAAGkCAABqAgAAawIAAGwCAABtAgAAbgIAAG8CAABw
AgAAcQIAAHICAABzAgAAdAIAAHUCAAB2AgAAdwIAAHgCAAB5AgAAegIAAHsCAAB8AgAAfQIAAH4C
AAB/AgAAgAIAAIECAACCAgAAgwIAAIQCAACFAgAAhgIAAIcCAACIAgAAiQIAAIoCAACLAgAAjAIA
AI0CAACOAgAAjwIAAJACAACRAgAAkgIAAJMCAACUAgAAlQIAAJYCAACXAgAAmAIAAJkCAACaAgAA
mwIAAJwCAACdAgAAngIAAJ8CAACgAgAAoQIAAKICAACjAgAApAIAAKUCAACmAgAApwIAAKgCAACp
AgAAqgIAAKsCAACsAgAArQIAAK4CAACvAgAAsAIAALECAACyAgAAswIAALQCAAC1AgAAtgIAALcC
AAC4AgAAuQIAALoCAAC7AgAAvAIAAL0CAAC+AgAAvwIAAMACAADBAgAAwgIAAMMCAADEAgAAxQIA
AMYCAADHAgAAyAIAAMkCAADKAgAAywIAAMwCAADNAgAAzgIAAM8CAADQAgAA0QIAANICAADTAgAA
1AIAANUCAADWAgAA1wIAANgCAADZAgAA2gIAANsCAADcAgAA3QIAAN4CAADfAgAA4AIAAOECAADi
AgAA4wIAAOQCAADlAgAA5gIAAOcCAADoAgAA6QIAAOoCAADrAgAA7AIAAO0CAADuAgAA7wIAAPAC
AADxAgAA8gIAAPMCAAD0AgAA9QIAAPYCAAD3AgAA+AIAAPkCAAD6AgAA+wIAAPwCAAD9AgAA/gIA
AP8CAAAAAwAAAQMAAAIDAAADAwAABAMAAAUDAAAGAwAABwMAAAgDAAAJAwAACgMAAAsDAAAMAwAA
DQMAAA4DAAAPAwAAEAMAABEDAAASAwAAEwMAABQDAAAVAwAAFgMAABcDAAAYAwAAGQMAABoDAAAb
AwAAHAMAAB0DAAAeAwAAHwMAACADAAAhAwAAIgMAACMDAAAkAwAAJQMAACYDAAAnAwAAKAMAACkD
AAAqAwAAKwMAACwDAAAtAwAALgMAAC8DAAAwAwAAMQMAADIDAAAzAwAANAMAADUDAAA2AwAANwMA
ADgDAAA5AwAAOgMAADsDAAA8AwAAPQMAAD4DAAA/AwAAQAMAAEEDAABCAwAAQwMAAEQDAABFAwAA
RgMAAEcDAABIAwAASQMAAEoDAABLAwAATAMAAE0DAABOAwAATwMAAFADAABRAwAA/v///1MDAABU
AwAAVQMAAFYDAABXAwAAWAMAAFkDAABaAwAAWwMAAFwDAABdAwAAXgMAAF8DAABgAwAAYQMAAGID
AABjAwAAZAMAAGUDAABmAwAAZwMAAGgDAABpAwAAagMAAGsDAABsAwAAbQMAAG4DAABvAwAAcAMA
AHEDAAByAwAAcwMAAHQDAAB1AwAAdgMAAHcDAAB4AwAAeQMAAHoDAAB7AwAAfAMAAH0DAAB+AwAA
fwMAAIADAACBAwAAggMAAIMDAACEAwAAhQMAAIYDAACHAwAAiAMAAIkDAACKAwAAiwMAAIwDAACN
AwAAjgMAAI8DAACQAwAAkQMAAJIDAACTAwAAlAMAAJUDAACWAwAAlwMAAJgDAACZAwAAmgMAAJsD
AACcAwAAnQMAAJ4DAACfAwAAoAMAAKEDAACiAwAAowMAAKQDAAClAwAApgMAAKcDAACoAwAA/v//
/6oDAACrAwAArAMAAK0DAACuAwAArwMAALADAAD+////sgMAALMDAAC0AwAAtQMAALYDAAC3AwAA
uAMAAP7////9/////f////3////9/////f////3////9/////f///8IDAAD+////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAA
AAAAAAAAAAAA/v///wAAAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArm4CAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUA
cgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD/////////
/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALEDAAAAEAAAAAAAAAUAUwB1AG0A
bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo
AAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgMAAMyt
AAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA4AQAA/zIEAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm
AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKkDAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA=

--_002_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 26 10:41:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTDQ-0006Ez-HM; Tue, 26 Jun 2012 10:41:48 +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 1ShNXg-0001Gq-EF
	for xen-devel@lists.xensource.com; Wed, 20 Jun 2012 16:14:05 +0000
Received: from [85.158.143.99:44428] by server-3.bemta-4.messagelabs.com id
	DF/11-05808-BC6F1EF4; Wed, 20 Jun 2012 16:14:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340208832!21915062!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=Known-good attachment 
  (ppt)
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29049 invoked from network); 20 Jun 2012 16:13:52 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 16:13:52 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 20 Jun 2012 09:13:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="ppt'32?scan'32,208,32";a="114261987"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Jun 2012 09:13:49 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Jun 2012 09:13:48 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Jun 2012 09:13:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 21 Jun 2012 00:13:39 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Thread-Topic: [vMCE design RFC] Xen vMCE design
Thread-Index: Ac1O/6XAexbUH0BVTLGVMLMLWAtaJw==
Date: Wed, 20 Jun 2012 16:13:38 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233524C532@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_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 26 Jun 2012 10:41:46 +0000
Cc: "Luck, Tony" <tony.luck@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan, Keir,

Recently we design xen vMCE as attached.
Please kindly help me to review it, any comments/suggestions are appreciate=
d.

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_
Content-Type: application/vnd.ms-powerpoint; name="xen vMCE design.ppt"
Content-Description: xen vMCE design.ppt
Content-Disposition: attachment; filename="xen vMCE design.ppt"; size=493568;
	creation-date="Mon, 04 Jun 2012 04:50:51 GMT";
	modification-date="Wed, 20 Jun 2012 15:52:00 GMT"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAIAAAAwQMAAAAAAAAA
EAAA/v///wAAAAD+////AAAAALkDAAC6AwAAuwMAALwDAAC9AwAAvgMAAL8DAADAAwAA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////+g
Rh3wBHIAAE0MqhifuUzfr0xZhpKngAb//9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAE
AAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgDAAQAAwERAAIR
AQMRAf/EANAAAQABBAMBAQAAAAAAAAAAAAAIAQcJCgIDBgULAQEAAQUBAQEAAAAAAAAAAAAABwEC
BQYIBAMJEAEAAAUDAQYDBAcFBQUJAAAAAQIDBAUGBwgRIRKWV9caMRMJQVEiFGFxMhUWFwqBkaGy
U9FCkjMnwSMmGBnwseFSYnJzKDkRAQABAgMGAwUDBwgHBAoDAAABAgQRAwUhk1TUBgcxEhhBUWEi
E3EyCIGRobHRUhRCcrIjMxVVFvDBYpLCJJRDNHQX8YKiU2Oz0yV1N0RFNv/aAAwDAQACEQMRAD8A
3+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQnuVOdPlRxN8C7weuzv70q9veM1nfW3KOBvVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3
wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5
U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4P
Rt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tu
UPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7
e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wL
vB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U5
0+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt
1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUP
VP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8
ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB
67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+
VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c
82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3
wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5
U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4P
Rt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tu
UPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7
e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wL
vB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U5
0+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt
1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUP
VP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8
ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB
67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+
VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c
82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3
wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5
U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4P
Rt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tu
UPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7
e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wL
vB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U5
0+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt
1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUP
VP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8
ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB
67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+
VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c
82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP
3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8Zr
O+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67
HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VH
E3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82
e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B
4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+
tuUPVP3B4PRt1c82e5U50+VHE3wLvB67HpV7e8ZrO+tuUPVP3B4PRt1c82e5U50+VHE3wLvB67Hp
V7e8ZrO+tuUPVP3B4PRt1c8216XTLmkAAAABTrD74f3gdYffD++AHWH3w/vgB1h98P74ArCMI/bD
+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHCtPGnRnnhCEYySTTQ/DGEP97snn
6x+MZezpDsh1KKPNX5oqxmmqnGn3xMT+XapXX5afLVThFVM4VfGJj9Sa24GD4sbR3GjNL6h2h3b1
rqDK7Zbca2zeobTeCw01YXF/rbTttm7qjYYmGk76FnbWU9eNKSWNWeM0JO917ekI40+76s13Jzrz
Try3ybei6qpiiq3qrqpppqmnyzVFURPh4xHh8UjXtv0XoWfk2WqWt5m3VVtTVM0Z1FNNVVVEVeam
Jy5mI24YTV4xPsweDhrTh5GEI/8Al43l7YQj2b82cYdv3R/giHVmq9O6y804anZxGPh/CV7Ph99j
Kbzo3CMLC7mMPGbmiJn4/wBmR1pw8hCMf/LzvJ2ffvxZ9P7f/BPwUp03rSaoinU7OapnZH8JXOM/
Z9RWbzo2Ixq0+6in2/8AM0f/AE5/U6Ya74cTRjJJx83hqVYdny6O/VpVn6/d8qloaeaX+0zLDrbJ
riq41TT6Yj+T/BVxj+Wc7Y++Xd9D1UY0aZf1R7/4uif0RkOUdc8OaUYS1uPu81Cebtllq79WVD8P
2xj+Y0LSmmh1+yEOsV1Ondb10/Uy9T06aP8Aw1X+rNmXxrvuiYqnzabqFMR/8enx3GH6XdZY3ipu
NcRw+ByG4vH/AFJdzy0sHlNwszjNxdrrq8mnhLb2epMxh8ZitUaXs7qb8M2Qhb3Nvbd7vVZO5Dq+
Oddda6RlVXV3l2uoW9OGOXkZdeVnTTH3qqJqrqiryxtmnDHBXKtuitXzKbSzrubC4qxwzM7MpzMq
KvZTXFNFMx5p2RO3asjrnRGp9t9W5zQ2ssXUw+pNO3cLXIWc1ehd0aklejSvLHIWF9aT1bPJYvJ2
VxTuLS6oTz0Li3qSTyTRhFsmn6lY6va03+nVzXaVxsmYw2/yqZpnbE0zsnHxnwaxqGnXulXM2OoU
xRd0eMROOyfCrHwmKo2xh7PF5R7nhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfUwWDzmqcvb6e0vhMzqbP3c
0klpg9O4q/zmXuZ6kYS05aGNxlvdXlWaeMeyEJO157m7tbOMbzNy8mnDHGuqmiMI9uNUxH+ufZD0
2tnd3s4WeVmZtWOGFFM1Tj7sKYn/AE8WT/Zb6Ln1Dt6be2ydPZSba7T9zCSpLnN4M5j9FRltZ4d7
81+4Z5r7Ufy4SdvSe1pzfoRJ1B397XdP5n8P/GZl9dYzHltafPFMx765+XCfCMJ8Ur6D2I7l69kx
dRaZdnaTEVea4r8mMT7qfvbPbjCYFj9CPSei6Hz+Rn1FONe11xS6RvsTiL/EXV7Y93rCalNU1TqX
CTVqnX4xhQhDr/c0jN/ENqV7X5Om+l9Vusv2V1UV0xt8MPJRVHht8Ybvk/h/0yzp8/UnUulWtX7l
OZTVPxn5q6J2T7Iifi+lT+mT9IvCwjQ1T9WDGX15LGElWbDVdCULaSrHs/BG2jl5fl9ftjPGH6Xx
/wDNfvbnz9Sz6Mr/AIf2TXObFWPt2eWnZ4Pdldouz0U+XP6ty6s3Hb5JysP6U/reisPpKfS717N+
Q2z+qxpj97VId22o53KbXzyVKs0IfLpxkvMrgZ6nej9kse88ud3o7u6dPm1TpDMpo/2Yzpn9FNWL
7ZfZTtTe1+TT+rMuc33V1ZMR+mqmf0vM67/p09+5sRV1Fx55FbJ764r5dStZ2lSrc6Zvb6WEYxp0
rbM4+51Dp2aM9OMPxTTySxj9vR6tO/FF07l5v8P1ZpeoafnRsny0TmbY8flqiiqIifhLxaj+GfW6
6Pq9MajYahlzhMfP5JwnwnGJrpnGPbjEfnYZeQfE3kdxVzkmA3/2h1dtxWuKk1PHZjJ2cLzSWajL
9uE1djZrnAZKM0O35ctaWvD/AHqcE99M9ZdK9ZW03XTN/kXdEeNMVeXNp/nZc/NH6UE9S9GdUdI5
3k6gsc+1y6p+WqqMaZ2/vUx5f9SPDZWrgAAAAAAAAAAOFXspzfplnhH9MO5NDpH74dI9F2VERc5c
x4z4/HCqI2+/ZMrKpmcquJ2xE7Ph8lU7PdtiEm+WsIfzC0LGEIdY8edg4xj07Yx/l5jO2P3xal0H
VNNhc00zMU/3pcxhHujNrwj7I9jcOt5mdRtpmdsaXbzH2zlUYz9s+1aTQm0+vtx7HVud0ppfPZbS
W3mNsNQ7lapxeKrZPGaC0tdZGXG1NS6ikoz060cfbXEZoRlpR70e70iyeq63pukZtrk6leUUXN3m
TTb0/v5ntoq9/tjb4eLG6Zoup6vRd5+n2tddvaZcVXFWP3MufCun3Y+Oxf8Axm5fFDaCSEuhNjq/
I/Vlv0kqa+5AZbJ4TQclxGEJp62A2f0ZeWdS6s4Tfsxy2TnjGEO2Tp2NautK601mfLqWpZel20xM
TkWMRnZuE7J81zmY0U7MdtMYx4xthsmTqfRmjZcTplhmajdxOzOuJmMrGIxifoU/PhjswqqnH3Lh
Xn1C+YGh6lvjdN47bDYChVsbTIY3BaI4zbZ6LjNh7rrLY3lnX1Lo/KZnJ2d5ShH5dzNWrQmhDr34
vDb9r+jL6nM/is651HN/lznXtzOGE+ynLzIoxx98Pfc9zus7acvJtcm306ifuRk2dtGOzxmczLmv
DD/a2rm7T87efu9uXzun7bSu2PKahpzSGb1zqzQ+4mwW0mo7eXQem6MK2ocpfXtjgNNZSztcdZT9
6NS2rwrSd78EIxYTW+3vbjQbWLnPus/R6czMpyaM/KvLqK/qZuNNGXTFVc0zNU7cJifuszovcTuD
rtx/dv8AD5WreXLqza8nMtLWafJl4VVZkzTRFUeWNmOMfefX3g477K8iuOW4XJzj9thc8d929kMX
pHU3InjPQzc2oNCZHbbXMJKWC3i2evL+rcZTGYO5uq8PzWLr1Kk1CXvSy9IQh183T3U/UXR/VVr0
T1Ne5Wq6Rf05lFjexT5M36uTTGORmx+9MTjNfjX4S9XUPTXTPU3S131f0za5um6zYVZeZe2k1TXl
/SzqpmM7KmfCmJ2RR4UeMbEMdxLubV/G7j/rXKVpLrU2lc3r3ZOrkqkY1L/K6P05LjdVaNtb2pGM
Y1Y6XhmbuyoTTRjNLbRlk7ISwgkTRacqx6s1DTsqf6nPyqMzD+TTmRTNOZhHhHzYeHijnW8+q86U
sNRzKYjPyc2rLmcPmqomYqomqfGdmPj7Ea/v+6MY/wBnbGEYR/VNCLaaa4ropw9kYfmatXHz1T7J
nGPskXLQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAFJppZIRmm692WHWPdljNN0/RLDtmj90PtXUxFVURM4U4+PuU
nHwpjGv2R759zLFoTiJw+4/ad05uJ9QDkFTymd1FgMVqfT3FPjbeUNYbj3WOy9rC/wAZLuLrS1+b
gdGRu7epJ8y1hPJcSyRjDr1Qfd9cdd9WXOdpfbzSa8nKyM6rKzL+9+TKoqpnDzZWV/2vhsxiY2xP
xTXZdFdDdMZGTqfX+qUZ2bXlU5tFlZ/NmVxVH3c7N8MrxjGInHZP2LlXf1jK2y2JqaN+n/xS2Y4o
6W7la2k1jlMPQ3G3cy1vGSNCWvmc7eU4UZchUklhPGWvUuYU5+vSHT4eDJ7IxruZ/GdztW1DW7uZ
iYyqa6re3omPDDLpny1YYzETs2Mjn9640OmLbtrpNlpNtETE5k0U5+fXE+PmzKomqPCMY2xMsee7
nNfl3vzcV626/I/dzV9vdRqRrYuXV2Rw2n6ctTpGNGnp/T8+MwlOnCHZ8v5UekPiknQ+3nRPTtPk
0nSbLJnCPmmiivMnDbtqmmZ+OOKOdb7idbdQVebU9Yu86PNM/Tprroppx2fdiYpmPZhgi3PTp1qs
9StLPXrRmjNPcXU81xWqzTfimnmqVozzzRjH7Yx7W6U/JTFFGymnwiNkR9mHg0yuqrMqmrMmaqp8
ZmZnH85ChQh8KNKHX49Kcnb/AIKzMztnbKzy0+6FJra3n7JqFGb9dOSP/Yr5qsPLjPlIiKfu7F1t
qt9t5di87b5/ZrdrX+2OXtK1OpJX0dqjIYilVmhDstbvEyXE+IyttU+2lXt55Y/bBhNX6e0DqKzq
sdftsjPmZnyzmZdFcxHsiJqpmYZzR+ouodAzP47Qbm4ycJ+aKMyujGfbj5ZjFsncIfrZaY3/AKeP
4o/Um0nobWOmtfTUdM4/di/wdlLp67vb2EtrYWm5eAmp1bLF1rurP/3WXs/y8tGrHvTy0+nfhyh3
C/D9cdMxPV3ae4z8nUMqJzMy2prqpqopojzVTRnRMVVThT92ZmJ8HVPb/v3bdR4dLdzsjJzLXP8A
6ui4mimaaqq58kRXl4TTEfN96IiafGfegt9Xv6WdPhJqPH7xbLyZHLcZ9wsxLj7S3r158jdbWaqv
pat7a6busjUjNWyOlsxbSxjirqpGapLGSajUnmjCWMZE7Hd46+vrOvQuo4jL6wtYwmKYwjNoj/tY
j/Z+7XHj5piUdd7e0dHQ11l6709jX0ndbYmZx+lXPhl4+6r71M+GETHxnCU6EQAAAAAAAAAAA66v
/Lj+qf8AyxXZf/eMr/T+XS+dX9nmfb/wVJ8a52kyG/HK3jZsxibr8pfbo7c8YtFwvpYR72Mtsxof
E08hkYdP24Y/GyV6/SHxjJ0RnY6zbdM9Gapr2fEzRk3Oo1VRhtmfqVfTw+yvDFJ9/pGd1F1hpmi2
my5zbaxpiZ8MPpUzXt9ny+HvwTL25tNt92NO/VTkwWAucJt7xw472eh9hsPhcxnMDQx2n9Mbi/w/
++dTUMHlcbbaxz+s7ihWyV9+85byhG5uYxlkh3JEfavmaxoV70bVfZn19V1TVP4i7ivCI/rbeK5p
jGNkU1VTGzD7uHvx3/TMnSNVo6u/g6JyrDTLDKyrWaJxmfp53kivZO3zRETP87FLfeDizwnyOp99
eMGA4maM0Lndufp5YzlZp7fXTGuNfR1xU15Jo6hma1hc6cymYu9OVcTdXcIwrS9JZoyzRhCEOsOm
maD1f3Apt9O6vvNYuMzT7vqirT67X6WT9OMqczy401RlxOOGyMJ+za3HX+kug6K9Q6XtNKt6L206
b/jqbn6ufOZObTlRXhNM5k04YzjhMbPGdi827GyWw/Jnk3tJp7d/bLSFWhx2+mZtdv8AZfO5nVms
cLabvRn0zTxOnND6/ucLLcwxu3Whr2nXvrutiaH7xrS3Ee/N3ekGuaN1L1R0n0xfXWh6hcRdan1T
c21VGXTRX/D4z5szOyYrwoqzc2mIpppqq8sxGMRjjjn9X0DQOqeqLK11yyt5p07pm1z6aq68yiM6
ryxEZedVlY5lGXTNWM1UxjExhM+WcFvtidCcTcFvTn9d8acntbidT63+nNy2k3t2z2P1HrbV+1Wm
c/h8Nj6WIz2jM9r3HY3PxxedtakYVIR78JLmSMvYy3Ul71tmaBkWHWNN3Xp+R1Dp1VlnXNGTk52b
RVXX5/qZORNVMzHsmduH2yxnT1l0pk9RZ2o9KVWdGo5nT+o/xdvbV5ubl5WZTRTFH068yIxifbHv
8IY+uNejs/w/+nxyw5Fb0ULjS2R5e7Z47jvxv0DqLrQ1Hr7G5K/p5XU+4VHE3NSW9t9KYfHxjC1r
TU/lxh0nhN0nl6yb1Te2fXPdHQ+mumvLmWei3VV5dZ1HzZWXXhMU5VddONNOZMxONFUxMe2Eb9Ma
dddFdtdd6j6hn6dzrVrTbW2VX8uZXFVWNWZTROFVdEU4fNTGE+xjuy0vc4jbby9e90393J6dZZZZ
5YfwbpqHdm7nWWPXp3v1zRStbYf51uP35sMiqftqzpRZcUzT0Xke2iL7OiPspyo/aj3H4x/VL/kl
bNT7f51X65arPhT/ADKf6MKLloAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRux3FvdXfvTG7+vNJY+0xu3OxWh8vr
fcrX2frxx+nMLJYWc11i9MW13U7lO/1dqatCWjaWck0an44TRh0jL11XqDrPSemr+x0q6xzNW1G6
oyMjLpmJqmats1zRHzTTTGGM4YRPi2jQOjtW6l0++1W0jyaXp2V9TOzKowp8vuiqdmPw8fd4Mnux
ukPpL5D6bmd1HuzqHQdlzkl0BuTc4bF5DV2s7PU82rLS6ykdCUYYSyrS6enu5reFvCnJNJGSeEfx
R7sYxhEnUOod6cru1lWuk5VzT0HNzb/Un6OX5Iy/JH1MavGI8vm2x8J9iYNB0ztBV2ozrnVa8iet
qbe48kfVzPNOZFU/TmI+7jM+XZPjhLBXLUoUYzRr1JadxHuT1Y1Z4Sz9YyyQhGbvTd7p1m7Ps7XR
E5deOyJ8vj4exztGFURPjLnLdW00ektxRjH7oVZOv2/pV+lmz/Jq/Mr4JxfT64dyc6OSGL4/1deV
9tpclo/Veq/4ot8NTztSl/DVKxqzWUMdVubSnPLeS3fSM8Z4QlhBHfc7rrO7cdL5nUOVkRn3FObl
0RTOyYjMq8vm+z2Y4N/7ZdEZXcPqijp7Mz5ycmrKzK5qjbtojGIn4+6HxueXFOjwo5M6u47U9dVN
xf4Ww2l8rLqivh6eBr3f8RYmXJxs442nc3UkkMfJHu96E8YTQj1fftv1fn9fdI5PVWdb/wAPVnZm
ZRMRtifp1eWNv2fofPuP0dT0J1TndNZWdOfk5NFFUTMeHnpiqf1whzUrUqPSNWpJT6w6w780JesP
vhCMesYN78lXlivCfJV4T7J+yfa0OJiappj70eMe2HKSpTq0p5qc8s8Iwj2yTQm/ZljNN8Ix/Zlh
GMf0QXVZObTX5KqaorwxwwnHD3/Z8VJqpifLjHmbW2zHD7i/m/oYag5BZfY7by/3qtdkNzs5R3Mu
cNGfVdLN4rUmYtcZk4ZH5sJ4XljbUJJKcYfCEsIQ+1xjr/XPVFr+ILK6etdSvqdBqv7bzZVNX+zG
ymPd+774w8XZGgdHdM3PYDN164scqrW6bC58uZPj9+cJmccPd4/Fr/5vcnjZf8R9Lbb4rauey5DW
Woat9m9xpbCWlXyNlVuJp5Zp8/JeVKtxYz4+MJJLeajLGnP8XS9tpnUtt1xca3dX9VfS9VE/Tyvb
FXx90Y+Lm661PpfP6Kt9Hs7eunqenMxrzJj5aqcfCPjMbG1fxSzlxz7+hnrrR+5k8+c1Pozbrcnb
v98X8v5rIXOd2fsYah0DmY15oRmhe29nQsaMZodvSSaH2x68ZdZ5FHbH8QdtqOmbLa5uMq5pjwwp
uqvJm0T8fNM1Ye51/wBKZ89yuwlxpuoRjd22RXbzV441W0U15dcT7Y8sRTj4YxLSYozTTUqc037U
ZJe9+mPTtj/bF+gmdEfVqmnDyzOMYeGE7YcFR4Ye7Z+bY7HzVAAAAAAAAAddX/lx/VP/AJYrsv8A
7xlf6fy6Xzq/s8z7f+CpkMzm8MePvMfi3vbGxmylvthoPi5rDI4yn3YVL/D4/RWJkzNpbRh3Zvzl
ziKteSn1j0780EYW2hx1P0Vq/T3mw/is6+y6av3cyrNrmI+3GI+HxSlca3V051ppOvR//FyLKuaf
3qKcqiJn80zHvSm5G8ReS+1t1vFv5wSv9Sb28L+W2CzV1d5zai0o6vvcborVeb/izJba7laSpUbz
O4zKaYzdeNOndSUoTU4U4yz9ybrK0TpLrLo/WsjTenu48Tp3XGhVxTk5dxV9Pz10U+WrNyq6sKK5
rmJq21+Xb8szG1vnVHRvVOk5mpdS9ua41DpLWqZnNqyI8800V1eanKzMun+soiiJiNlGOEYzhMoO
ZvlpzTm1/q7XWfz2srTXmtdmKfHfV9/fbbS2Ne+2ilsZsXT0hUxtTAUaFpLJZw7v5mjTp3EYzde9
CPaka36K6By9NybOyy7f6Ntf/wAdlRGfE+S4irzxVtq8vy1bdvyo3u+sevs+/wA67va8+c65sJss
zHKw8+RNPkmn7uPzUz5feu1tjyG+qPrfJbI2u1VXfvWGX2HxFzpvam8wO1d1mL3E6Wyllb4m+0jl
svPpf5ep9O1MdaU6H5fLVbi2kpSw6Syxl77E6r012gs8vVKtUjS7a1v8ynMz/wDmaaqapjCfPRRF
eOXm+fDGqjCds4Sz9h1J3avc7T6NNp1HPurL5LeZyfLNMeWafJVXFM+fLiiZiKa8Y8JZM8Jw5+qb
utqClyX5nciNG8NNJ6b211boC61LqmO3+BzdHbjVGOvI6t0Vi9vdLW9npySlqGhUjCpC+rVK89Tu
xlpxnklgiPO687PaFZ/5Y6H0vP1zPzLrKzvJEZtdFOdl1x5K/q5vzRNO3DyxNHvmISfl9E92tYuq
uqOtb+30jKy7bNysa5y8uurLronzU/TyowmK/CfNhV8Jwa+G628G6G8eSwt5ubr7UGvamjsBYaI0
bUzd78yzwGjdPUJsdhMPp/HUJKGNxWNksLWnNNLRpwjVnjGaaefsi6c0bQdI0S3zZ0iyyLab2a7n
Nqox8015mH9XXjEfd8fbtc1a5rmp6vcZWTf5+Zm5FnTl5GXEzM0xFGzzU/bGz7HvcxD/APUjbiP2
R393I6eDdNsbbf8A+5u//AW//wA1k7iYnoa1w43P/wDlwj1H4x/VL/klbRT7f51X65anPhT/ADKf
6MKLloAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAC4e0u1+rt7NztBbR6CtIX2sdx9V4XSGn7eaXv05b7M3clv8AnLiX
rL0s8db9+vWmjGEsKdOPWLG61q1p0/ol3r1/VFNpZ5FWZVM44TMR8tOzGds/Bk9E0m61/WrXQrKm
arq6zqaIw8YiZ2zt90bWY36sWsdJcYtIbXfS52CrfldA7QYTD635B521nmp5DdTeHOWlPIUK2pK9
OElTIU8VLUjdwt6kYyU57ijJ0jLQhCED9ldNu+sdTv8Au31NT9W5vJryrLKqw/qMumcPPkzP3asI
iJnGMcMfbKdO8eoW3RunWXafpuYyrW0ijNu82J/t8yuMZpzYj71MTM4RhOGOGzBkY4kcetidRfQp
1lunndm9s8zuVa7Sb739rrzJ6LwF5q+3vsXk89Txt7Q1DWsZ8nQu7KW1p/KqS1ITU+7DuxgjDrrq
XqXI/EHkaRY31zRpk3lrH0vPPlqjy040zGOHzbYn4SlLo7pzQbnsBcatdWlvmalFndTGb5I80TFV
WExOGONOETH2O76D2ynH3WHBHdjcjdfZPbnc7J6T3R11fxyOq9E6d1FnpsRgtK4jLzYy0vsvZ160
I9lSWlLGeEvem7exb+I/XupNO7k2eldPX11b/wARbZMR5cyqiiKsyryxj5ZxiPjELPw/aH09qPbu
41HXbG2uarfPrmZqoiqqaaKPN4zHvx2e7H4Lw8OOTP0svqK7nah456a4IaX0fm62jM5qiFXVG2Gg
LHH5PEYW7s7DKW9rldMfLyOMyEkchTnpxhNLGMOsYTQjDo1vr3pHvJ2y0XL6puOoc3Pyqq6KKqIz
86vCrMiaopmnM+X+TO2PD8rP9DdU9pu5Gt5nTNtoWRkZtOXXVTX5MuMaaMImqJopiY+9GyUPuCnG
/TPEv69uvNjNC1bqfQ+nNuNwcxpChd3c91d4zTuptMaezVjg69xVhGrdQxMLuahJPPGM0aUsv2t+
7idV3fWX4crbWr2nC8m4yaK6/fOXmeWr44TVDQ+33S9t0j+IbP0S1ny2tGTn100++MyiJp8PhOK4
X1qd9+Pu5G5Gq+DeleO1O75e631LspicFvjNprScJKtTUOQx01hZXeooSx1VC1oWF38qaXtljLCM
OyDG9hOneqdE0rJ7j3OpzPRWR/E11WczVhTNETjV5fuzt27Nuz4st3013p3V9Sze31vp8T1hn1Wt
FN18sVV+aaZ8mP3o2TEbZw2z7l5tfaY+m99EPZ7a7D7lbHUeQW/G4ltXnusve6X0/qrV+qb3GUre
Op8/+b1fJc4TSOmLO/ufk2lChL82aWMIdJvxTQ1nS7nuh391y9/uy/8A7t6dtavkirMnLy4xmZoj
5J801VR4+7ZjEbGyapads+yeh2VOq6dRqGuZ9EzXjRFVUzERFc41RNMRE7I984zGzFavmjxN4g/U
I4C5Xntw528x21+4uiNP57Vd7iMNp6z0lNnbDRleP8eaD1xpvDSQw376xVnb1bmzvKFOM0e5LNCM
ZasYQzPQnWvWna/uHHbnrTPm6sM7MoppqiurMima8PJXRmTtnLmZwqoqwnHHCNm3A9ddGdE9ye3V
XX/SlvTZXdvRVXXl00xEz5JmJpmIiImYiMYmn5ZifFeLYWMsf6cnU80sY92PHzdiMsY/Hp/Fmc6d
f0sb1NFUfipy6asJq/vSz8PDHyUeHw9zMdO4x+Ga4ifH+AuP6ctLWnNCS3pzTR7sJaMkYx+6HcjG
EYff17sen39HeVfl+pOVV47cfs+3wcJ0RX5Iro8fZ78fs8fFu5cLtPXXBv6Hevdb7kUK+DzWr9tt
192a+OvqcbO+tL7dKwhgtFYuehWj3pLq6oVbGpLJGEJoS1vxQhHr0/Pvry6/8wfxC2+m6XH1cnKu
MnKxjCaccmZzMyImZ8IimrGZwjGJ9uGPevRFvPQPYK4vdR/qrrNts3NwqxxwzcMujwx2zNUYR4/N
jPtw0j6UZ405PmTTTzxlhGaaaWEsZu9+LrCEPhDpN2P0Fqw80xT92NkfZEOCKfuxM/enbP24y7FF
QAAAAAAAAHCpDrSmj90Jv8sV2X/3jK/0/l0vnV/Z5n2/8FSaXJvQF3ntZbe5KjrTZXEyXHHzYSEM
fq7fjZ7Reet4Sbf46TvX2ndV60xGbse/GSMZZatCSaaSMs0IRlmhGMG6N3Z7d9K5t5ouvarb2+qZ
Wp3FVeXMZkzTFWZXhFWFExjMTE4RM7JTnrHanuH1RRaazoWl3FxpmZptvTRmROXFNWGXREzGNcTh
jExtiNsKcft4uUHFfLXGX4/8q9ott5r2pJVyWIxfLTj5daWzFSlPCaT966Wym4V3hLzrCM3Wepb/
ADYdeyaDFdS9wvw9daWv8J1Rf6fcxHhXVlZk51Me6jNiiJpiPZHshk+n+334gOlbn+I6d0/UbSir
DzUUZmX5avjVTNcxOP2MkWO+tN9RO1t5KGX3V+n9qq5pyQlhl89uRxrnyVSMIdk9aex3Vs6NSpLH
4R+XCCKszRvwuVY/w2t3NvHujOzqon4T/VeH5UsZet/ibpn/AJnQ8m4p/wBrIyon88Z0fpifyvJa
1+sJ9THWFnXx1jyh4h7f2lWSNOX+X+7fFbEXdGWMO35F9kdwsvcUanWHZPL0jD7Hu0/Tvwm2mZGb
cX1OfnxP3q8y4qj8tPlwmPhLH6jqP4pbzLqybbTK7bKq/wDd0ZFMxtjwnzYxP2YMae6mf3430y1X
O70codrd0spUhCMlfW3MjY7N0rWaE/fhCyx91uZHF2VKE3+5Soyyw+5Kmjd1Ow3TmRGRoF/plrlx
s+XIr82E+M+byf8ApRXrfa/vz1LnTca9p+p3Gb8c7L8v+759i1v8rL7vxhLuNxw7v45od3lJx97v
ejLN1hLJDcWEsvejHr1mj2fD4M9R357S/N5tct6qppnbNOZHj8PIwlXYnuxVFMUaHc0xFUTh5sv2
fHzrxa607V05xS2ys62d0Lnp6u+25Nb8zoLcLRO4uOo9NIabpxo3uT0Pnc9YWN1GMOstKrUkqTyf
ilhGHWL3dHdXdNda9VXupdL3mVeWmXaZFFc0eaPLV9THCqKqafGNsYY7Hk6u6P6l6L6UstN6os82
zu8y5zq6Ir8vzU/TiJmny1VbInZOOCLH2/2S/wCSVJcRhMxP71X65RjV4U/zKf6MCq0AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAABnK/p7ttcdrfn/S1Rk6FO6l2o2m1hq7GU55JY/KzmYuLDS1ldwnm/37a0yFx3ez8M0/
WEXO/wCJ7Vrix7Z/weRVVRVd3uVlzMeE0R81UTP5PD2uhfw16Vk3vcSL3Mimqm1s8yuInxiucKYm
I+GPj7GM7mbrXJ7icueTOss5Vq1sjmN79xJa1SaeMJ6dDG6jyGGxksO9GMZaVtYY+lSjLDslgmLo
izttK6Q0nTLCmKbHL07L2x4zXXl0zEzHx8Z+KJOtb/P1XqzVNRv6qqr6vUMyMPZFNGZVGET8PCI9
0Nq/hdUl9vdrqEIwjGGzXIaEYQjCHSP721H0lm70Ze5NNCeHSEekY9YdjjXryKqPxMWmMT815aVf
kwpna7D6Fron8Nt1hMYU2l3TP241+H53w/oHdn0xuRsOsI/+M93Y9ev4Ywm26x0YRhGPTs7en631
/EZFX/m9pM4YxGXaR/u5kY/reb8Pc+btRqkRj5v6/Z7f7Kpil/p3f/6KXM32fyO3Ul7Iyxj1p5rS
/eh8f/qh+tMX4m5irthTtiKv4+22T4/czNuHu+KH/wANExHc+qmfvfwNz/Ty2U7RFSSl/Uo7ixqT
ySRqbFX0lOWaeSE1WP8ALrS8Ywpyxm61JoQkj+GHWbp2wh0hHpD2oxM/hWt4piZn+Onwj/49X6va
l21qiPxQ51VU4RFl7f8Aw9P6/Yhf9RnFap2r+t3tpv5rDReq8bs/itweOOUvNw7nT2U/gmTH0fyW
Gvq9bUsLWbDU/wB33k8YVJJ6sJ5J5e2DfO1+fZ6z+H+40GyuMudZqyr6iMnzR9SZqxwnyROOHxaV
3NyLnSu+tvrl3k1/3TTn2dc5vlnyUxHl2TVhhFU4ThGPsZvfqkcp91uLeN2419oXhfpflnoTNUcr
i9SaivbK6zmQ0HfxntLnEUPyGM03qS6lwmoLapNPLcwlhThVkhCbpCMIueuzvR2hdY3F3pWp69ma
PqOTNM0UzhRRX5dlXmrqrpwqpmNkbfF0F3W6r1vpa3tdR0vRcrVrDNpmK6p81VVPm+75aaaasYmN
szs8MMWKbcz6unLqy4oav1Tk/pmY/a7YTcKz1TtdPrKTKZ/TuIxmT1bp++xVzkaunv4Wxl7Ssrj8
10pX1SjSta9aHchVmmTJo/ZXoy56xybC06u/jtfyJpz5y4imuafpVxV5JzPqTE7MJ+SavveEId1j
vN1lk9HXF5ndMRY6Hn5VWRNc+aI+emaZnyeWmdmM4Yx7PGUiuP1WjU/pydUU6VanVmpcf93KNTuT
yzRp1aWrc58ylUhJGaMk8kYwhGH2dYdWvdS052Z+KfJrimqqrM1K0mNmE1R9OnbENi6fmI/DPc1R
to/gbnb7NldX6/Z7WOj6QP0d7zf+noLlryOjirfj9Y1o6j0Ft7TvqV3ebo3WFv69rDIapqSVPlYb
RWMyFlNGpRnnhcX08k0KkJKfxknvp3wq6bpuOielvPV1BHmys+uadlE5kYRFFWMzVXMVfLsiInCc
UY9luyf9/V5PWfVHko0LGMzJoivbP06sZ88YYU0bMapx2xjGD6311vqT6W3zyWP4fbB5qyzW1O32
doX+6WrcLNLHAat1pg6c1LE6KwFa27tC+07o2FSNS5q04xt615NLTljH5UIx+f4c+1dzoeVmdedS
0z/fNzRNGRTVtqppmcasyvHbTmTtj2/LPxl6PxCd0bPW5o6H6cq/+2W1cVZ1VOyma6PlpopmNlVE
ROPhG2I90NcOMYxjGMe2Me2MeyHb+qHSEHVbldQAAAAAAAAAFKn/ACan/wBk83+HT/tXZf8Ab5f+
n8uFJpxycyfj/wAFTHL9XiSEOXlnCMkkIx4+8cY96MsYQml/lJp2WNSaMOv4oxhD9fSEOj8ou6GH
/mNrU1TM/wD3HN/X+p+rHbCfL270aIinH+7sr3+77UGtecft6drtLaS1vuNtfq/ROlNd28t3pHN6
jw9xjbTN0KlvRvKUbaFxCStTq3FjcSXFGnVlpz1qE0KkkJpPxNF+X4/ob15p91P6f2vg4rafcbOa
JuNxsPovO5LQ9tquy0N/EdlY1LixuNYZCwr5W003YwpxmuL/ADFTF21S4jRoSVIyUpYzT92HSMXy
/E80+6n9P7XgflSSz9ypNJT6RhCeMfxRkh2wm6yyxjGM8sYfs/E+X4/oPN8Kf0/tUmpywj+GMk/W
PSXu9etTpHu9ZJYw70YdYdnXp1+ztPl+J5p91P6f2uEI0+sYdzv/AB6Qh2R7IRj1+MenSHb0/sPl
+P6P2KTVM+yn9P7Wf3g9CWHAHE9ISQjHlLrrvd3r3o9Nt9MQl7/b3esIfDp9jsz8ImPn1vbP3rb8
m2XHX4spxytG2RGy48Psj/SF4/8AZL/lldkz96r+dV+uXG9XhT/Mp/owCwAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Bm//AKfTcvHaD+oNjtN5S4pW1Ldba3WejcfPVmhL83O4+pj9T4y0kjNGWE01zQxdzCWHxjNCHT4u
e/xN6Vnaj2ynPt4xrtb2jMq2TOFOGGOz2Rjj+R0D+GzVcqx7jxbZ84U3NpXRTt8asYnD7dn6UbPq
3ca87xs5z7y4m+x1SjpTc7UWQ3d27yk1OrC1yeB1lffvHK2tnWjCFGtVwuoate3rUoRjGTrLGPSW
aEW3dk+q7Tq7t3aZ9pMVX+RTRkZlHmjzZf06Yp+pPvpqw80U/ewna1PvR0ledJ9fZ2Xdx/yNzmV5
uXXFM+WucyqavJ/OjHyzPhjHxh8Dj59SvfXj/wAad4OJdjjNP642c3a0/qvD08bqGa7tcxt/faws
Kthlsrpi+tJoyVrat35a01pcSxp/Nl6yxh1iv6p7S9PdUdVWXWmdXm5Wv2mZlVzVTPyZk5UbImPH
CZjHx8MYWdMd2Nf6Z6XvOjcqjKzdBusvNoimqPnojNxiqYnw80RP2Y4T7Fw+Gf1Xd2OFfHzW/HfR
O1u3+sNOa7y2qcvks9qbKagtMxZVtV4W3wd5TsqGNj+Tmp21vR71KE/ZCaPa8PX/AGZ0Dr3qq26r
us+4ybm3+n8lMx5apy64q27NkTETEYYYbGQ6G7x6z0R0zcdMW2RlZltn/U+fwrp89E07Nu2YnCZm
fijjwc5la04Kb51d99DaP01rnO1dG6k0XNg9U3eTssZLY6lvMfe3F1C7xXdvZq9rVxskJIR7JoRj
3o/BtfcPobTe42g/5c1PMzciwi4y82mvKw+rH04mIpmZiYwnzTj8Yhqnb/ri+7e67/mDTcnKzryc
jMy6ozMfLPnmJ80RExMT8se3bGPvel3Z+oFvfuPzMhzj03SxG1G79vXwFxjbfS1S8yOBtY4PC0cB
VtbihlY/PyWOzOMkmpXdCrGEtSWfrDpGEIvBo3bHp/Tehqe397Xn3ehx9TZX5cYqrrmuKomI8Yx/
Pth79Y7ma5qXXH+fLajKttWxo+55sJiiiKZicZnxwxSs5b/Wr365k8c85x13I2k2nweL1Hdadvcr
qzS13qaTJT3ensjQyklW1xGRrXONtIXd1R6TSwmm7sk0ekerSeh/w/8ATPQHVeX1TotzdVZmXVVh
lZkxNE0VxMVxMREbZmdnsw8Ybd1n356j656bzenNXt7anKzYpn6lETFcVUVRNM4zVOzZhOGHw2Pc
8T/r48sON23uF2w1ppXSHIHS2l8fQxGmclq6/wAngtb47E2VGWjj8ZeZ7HSXNvm7ayoywp06lxQj
WlklhCM03SDx9Y/hu6N6nv69TsM64067za5qrjLimrLmqZmZmKZ8JnHbhMR8GQ6S/Ed1j01p+Xpl
5k5F/b5URTTOZNVNcUxERFPmjHGIw2YxP2vC80vrbcoeYu3+V2hk01ovZXa3U9GnZ6rwGk4Xed1D
qnG0K8lzDF5PUuZkhNZ4mepTh36VnQoT1OkIxqQh2PZ0P+HzojofU6NduM65vNWy/wCzrriKaaf5
tOXt/wB6Z/S8PXXfvq7rnTszQ8nIt7PS8zDzU01TVVP/AK9eydu3wj9EIycf+dfKHQexG43Cbbm0
p7ibc7347N6dtdAVcBktQ6n09kNUUZJcre6A/dMf3haz3ctOE81CelPbfM6z9IRbb1N286M1TqSx
681LMzLXWbKuJnNiqnLy64p+5FVdWymYjZOO32NW6b6+6x0vpu96G0+KrrSr2iafpTT9SuiavvzT
RTtmJnGfl2e12Zr6jfKq04v6I4XaY1PT2u2l2+xGV0tm7bRtK7xOstYy3OcyWRydjqzUUa8b2jaQ
vLypSntbP8vTmpy92fvQ6wXWnano2nqvP65usqbvW7iuK6fqYVZWThh/Z04fDxqxn2xMLbvup1fP
S2T0TaZsWuj5FM01fTxpzM3H/wB5Vj+iMI2YTigHCEssISywhLLCHSEssIQhCHWMekIQ7IdsYx/X
Hqk3HZERhFMeERsiPshGmG3GZmap8ZnbM/bM+KqgAAAAAAAAAApU/wCTV/8AxT/++C/L/t8r/T+X
Suj+wzPt/wCCWOX6u/STl/Z92M8sY7Acc5u9ThNCeEZdp9OT96H/AM0ZYywj1h06dH5Q90f/ANja
1/8AkM39b9VO2X/680b/APH5X9FLLA768YMriNB7gbt707LZrmBf7eZvQukd5sHt5rHO6K01Na7a
4XCbe625KaF1bpK90vcbl6Fr4+phrHKYDHX8KtGaS4uqNWelJVm0NvK42D+ots1oncvYvDaC3S03
p3QGieWub1zqe/xmz+CtNM21rn+PmhNBa53WweHqaNr32M07rPdy1zeUo46jS/N2tjcdlGSEZacA
8bojfr6c02jtHZbd+32u1JvpNpXJa21pq/H7WZWfGWe5nGq+1dT2y0RjrXH4ewwuSwvK6nqC0uMx
cT2X5enLjKUt18qPxDsyXKPh7onjt3NIaz0Pqve/D7X60obQ6my21Om8lrXTOW1XoLbSnd4LO4mf
a/D6R0zf43WdPP2uNhGtmoUKEn5uFzTmqwhEIw8/d+eNu520W2WC2OxG1cbeS/0Rl8TJhMFU07uf
tzbWO1+HwmutH6hs7LQOmMRVw+f17Ld5Geeplc5Wr3XStLVpU5u4CRvB7s+n/iIdY9nKbXcOkfs6
bbaW+H2dvV2d+EX7+t/zrb9cuO/xZf2WjfZcfqheL/ZL/lldkz96r+dV+uXG9XhT/Mp/owCwAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAh1+3/C
HTs/vitmKp+7MR+TH/XCsYY7fA+//D9H6/v/AMFYxw2+Knt+AqAAAAAAAAAAAAAAAAAAPY7d7gar
2n1/ovdDQl/HF6z2+1NiNW6ZyEIx6W+Vw15Tu6MKkITSwqULmSSalUkjHuz06kYR7Isfq2l2etaZ
n6TqFEV2dxlVUVRMY7KowxiPfHsZDSdTu9G1PI1Wxqmi6t8yK6ZicMcJxwmfHCfbg3gNP5Dh99ef
iVi8dqypLpTd/RlvQny9DFVLOnuNs1rypYyUb/JYWStNCtmNCZ2rDvdybra3NLuyVIyVZOsPz2vM
jrP8OnWv1raivN6fzsyryTHm+jcZXmnyUZk0xPkzIpw82zCJxwmYd/2Vx0b+IXo7LyLqqjK13Ipj
Gfl+rlZ0Ux55y6asPPlzVjhjhswxwlrgcpPom84+N+QyV5gdC19/9vrarXqWOtdpberlsrCwk781
ObPaGjNDUGNupackPmfIluqUIx7Jujqzozv92+6syYy7y4/uvVJmI+lcYYTM4YRTXGzGcfbh8Yct
9X9huu+mK6s60yY1LTYpmfqW+M4RETtqpnb7PCMftYptQac1JpO+r4zVem9RaUyNtUjSuMdqfBZX
BZChPJHu1IVrPI2dtWkjCeHTshH9KY7S9s9Rjz2Gfk5uT+9TXTV+iJxn8iHLmzvbCfJqGRnZWb7q
qJp/TOyHwYXNCEey4ofCPX/vYR7Ozt7Jez+17Yyc3HGdtPwpqx/1vL54mMKaaoq+M04f6v1uMbyh
2xmr0ZoQ7JZZJ5YzTR69vwjHuwh+l8pmuJw8tWH2T/riH2jLxiNtOM++Y/1YvSae0rqvVtzLZ6U0
rqbVF3PGWEltpvT2YzlepNN+zTpUsbZXM1SeP9kHnur+ws8v611cZORREeGbVFFU/GmJnbHvl6Lb
T9Qu6/p2uRnZ9eOH9VTNcR8KsIxifd8E7tn/AKUX1BN8KlvPpPjTrfTuOuPlxhntzIW23uJp06nd
jLVj+/qtHIVacJZ+90pW880YfBHGud5+22g5dU3Wp5NefTO3Ly/6yv8A9jGPz/lSDofZ3uLruZTT
babnUZFX/aZnyUf+1hLMtx2/pps/d1rLL8p9+LPH2Ms9OrdaG2bx89xe3MZZ5Yz2d7rbUVGWS3kq
SRjCM1raTRhH4R+1BPU34s7WnLzLboywzK6p8M+4nyeX400RjjH2zH2Jz6a/CvmV10XPWd7RTh4Z
WTE1z4+FVU4Rt+ET9seLNrpPZL6c30r9ub3U9Cz202Rt5cZcW95uFrPIWuT3N1LUhQmlmo2+ZyUL
vU2Wuq803X8rj6UlGM0evyoQQBf9Sd0+7mpU22fXeX1pExjRl0+W2pnGPvxTsmdmOM7dkzCebLp7
tf2nsas/KptLO6mJwzc2qKs6dmzCqr5qfsp2ex+eVq++tcpq7VuUsak1axymqdRZSzrTde9Vtcjm
b29t6k0I9IwjPRrwj0+x+nlllVZNpl5Ve2qmiIn7cH5o32ZRnXmZm0fcqrmYeeep5AAAAAAAAAAA
HCpN+CeSEIxmmo1u7LCH7cZZe/GEs3+p0l7JftVomYzsuufuU1RE/l2x+mFfmiiujZhVTjH5Nk/o
lab6hHA7k9yQ36wm6ezGh9Pa20LlNjdicXaZy33Q2tw8s+SwG22DxOYs62O1FrLFZe0uLLI2tSlU
p1aFObvSx6dYdIx/MjuR0b1ddde6tc2+l6jn5GZeV1U5mXkzVRV5sJxpn2x7Ptxj2P017c9Y9G2/
QmlZFxqlhkZ1Fnl0zl5mdFNdPlxjCqPZM+P2YT7UG/8A0nuefSEP5P4OPSEYd6O8myEYxhGHTpGM
24XejDp8IR+DSf8AI3Wn+Dat/wBPU3X/ADt0R/jOl/8AUUqf+k7zy69f5P4SEfwx6w3n2S69Zf2Y
9f5idessPh90D/I3Wn+Dat/09R/nboj/ABnS9/SrH6T3PKMYxhs7gZevTrCXeTZCEIwhDpCHT+Yf
w7vZ/wDHtP8AI3Wn+Dat/wBPUf516I/xnS9/SpD6TvPKEY/9HsHHvdk8I7z7J9KkOyMIVOm4sO9C
EYdT/I3Wn+Dat/08n+duiP8AGdL39KsPpOc9Jox/6P4WeMYxnj/1l2Smm6xjCE00I/zDjCEesesY
n+RutP8ABtW/6eo/zt0RH/8Ac6Xv6WT/AGU2G3Q43cNtK7b7wYfEaY1pkuRGu9U22n7PV2kdV338
O1NCaexsmWrT6RzectbW3mv7SanCFaenPNHtlhGHbDrr8K+g61o2Zq06xaXNpTmVZWEZ1E5c1RRE
1RNOPjEThFU+/Y5H/FLr+i6tl6VTot3bXc0U5uM5NcZkUzXVFOFWHhM07Yj8rl2dJYyx70Jpe9Cb
p0hNDrGEsZfvh3YOsKZmY80/ysZ/PLk6r73l/diI/NEQouWgAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi7U7ubnb
Ga6w+5e0GudRbea5wVSE9hqHTV/Usrmal35Z6lhkKH47PK4u47vSpbXNOrRnhGPWXr2sRrWhaT1D
Y16brGRRn2WZGFVNUROMR4Rj4/mwn3Mto2uar09e06jo+fXkXlPhVTMxLZM4xf1J+rMHZ2GneWuz
MurfkSUrevuXtDcW2Ky1eSSMks13ldD5erLZ1rmanLGaf8neU5ZpvhJD4OUOqvwpZVxnzndG3cZe
NP8AZ584zPwiuIiYx8Pbh4up+k/xR3GTTTb9YWv1Maoj6mTHlwjwxmnGYnDx24YssWlvq+fSm3/t
aFPV+42icVWq05I1sPvltvVsq9CeaEJo0Jq+UweZxE88k8O2MK/d6w+PXoiDUOyPevpXM8un21xV
bxO2q1uJxiPZMRExM4+HvhL9n3i7O9RzE6hc20VVfybm3jb8JqmJiPfi97S1h9GbW0s1/wDnuBGW
lrTS1pqtzabR21eaeHbCapb3lrbV5Zu37ZGMzbDvrpvyTl9QURGzGmrOmfs+WrH9ODJ06n2Mvvn8
+g5ke6aMmfy4TGH6H3KO4H0f9EU5b22zXAvCyUevcrW9DZuNeXpDvRhShStatxPNCHb+GEYvJOn9
7tSn6OZl9RZ0Rtwrqz4iMdmMY1fnwfeNW7J2H9Zk5mg5Uz7Yy8iMcPZspj7XwM/9V36WGz1rPDDb
87U0Y28JpY47bLSd7k6/SWEYfLoyac09LZQjN06Qh82HWHw7Hqt+0Xd/X8+Mu6sb2r3Tc5tURGP7
vmqxw97y3HdztJoVONpe2lM1bf8AlsqJxmNm3y0xt9yEW7X9SVxM0zJcW20m1G7+7eRklqflLvI2
uJ2/wk1WEs0IVI3WWur/ACX5aM3T9m2lmnh8G/aN+FHrLNzqZ1u5s9PidsxTM5uZ5ffh4bft9jSN
Z/E/0XbZVVGkZd1fZuzbMRlUY+6cNuyPh7WIrf7+oS5u7rW97htq7DQfHbA3MJpJLzS9jU1breFO
aHd/DqPUcscfY1IwjGM01Cx78Jv2ZodE39Mfhl6D0aqM7XKs/VLuiYmKqqvp5dXt+bKiMcI8MJrn
HD4oU6j/ABJ9aapl122i0ZOn2lWyIojzZlMfDMmfGds4+SPHD2bcLe4e5m4+7upLnWO6uvNXbjaq
vKk1SvntZZ7IZ6/6zR692hNfV6tKzpS9ekJKMlOWEOzp0T1pWj6ToVt/B6LbZNra4RHlyqfLTOHv
QPqmsarrefNzq1xnXGdMzOOZVNW2fHx2PEMkxoAAAAAAAAAAACsI92PWHZHrLHr90ZfhGH3Rh1+M
DH5Zp/kzMT+WPD8ys7cMfZEx+Srx/O6vk0ow6RpyRh2/GWEe2MesY9sOyPWCtM1UR5aZmKduyJnD
btn9Kmz3R4YeEew+TS/05P8Ahgr9TM/eq/3p/ars91P5o/Yp8ml/pyf8MD6mZ+9X/vT+02e6n80f
sPk0v9OT/hgfUzP3q/8Aen9ps91P5o/YfJpf6cn/AAwPqZn71f8AvT+02e6n80fsPkUftpSR/XLC
MP7owPqZn71X55/abPdH5o/Y5S06cnXuSSy9evWMIdI9Izd6MOvxhCMfs+7s+C3GZq88zM1eWYxm
cdk+MGOzy+yKon8seEuf/t0+yH29IQ+EIfogRsiKY8IjCPsUnbM1T4zOMgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAKTSyzdO9CE3d7ZesOvdj98v3RImY8JmPs2KTET96In7drqjbW8Y9Y0KUY9evX5cvWMfvj2ds
V0V5keFVX55Vwj3QQtreEYxhQo9Y/b8uT/Yr9TM/eq/PKmEO2EsssYTSyyyxh8IwhCEYfqjCHVbN
VU+MzP2kU0xGEREQqorERGyPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAB//9mgRh3wjl4BAHrruhb8ZULEwLGTC/0XcCv//9j/4AAQSkZJRgABAgEASABIAAD/
4QX4RXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEo
AAMAAAABAAIAAAExAAIAAAAUAAAAcgEyAAIAAAAUAAAAhodpAAQAAAABAAAAnAAAAMgAAABIAAAA
AQAAAEgAAAABQWRvYmUgUGhvdG9zaG9wIDcuMAAyMDA2OjAyOjIzIDE0OjM5OjQwAAAAAAOgAQAD
AAAAAf//AACgAgAEAAAAAQAABACgAwAEAAAAAQAAAwAAAAAAAAAABgEDAAMAAAABAAYAAAEaAAUA
AAABAAABFgEbAAUAAAABAAABHgEoAAMAAAABAAIAAAIBAAQAAAABAAABJgICAAQAAAABAAAEygAA
AAAAAABIAAAAAQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5B
ZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwM
DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAGAAgAMBIgACEQEDEQH/3QAEAAj/
xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYH
CAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFD
ByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2
hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGR
FKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSk
hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOeCSQSW+4Sk
kkklKSSSSUpJJJJSkkkklKSSSSUpJJa3TOl020+vba2uw1faWbmtsArFl1B20WuYzIu/VbvY/wDR
s/QpspCIsroxMjQckGQS0FwHJAkBIEESDIXWfsrKa5ljutXtqp2m4te5rCPWup/R+hZtwq/QprY/
cy1mPk31f4BZHX9nqY+8tdmEW+u9rmuc6r1P8nWZT6vY/Nsx/fc/+d9H7N6/6VNjlEjQXyxGMTK3
/9DngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKVvH6g1lLMbLxas/GrcXVMtL2PrLtbG4+Rjv
rsrrtd77KXepV6n6RVEkCAd0xkYmw6B6l0+t2/D6PiUvggPudblQT+e2vJs9De3+XTYqD3Oe99jo
L7HF7iAAJcdzvaza1v8AZTJJCIG34ni/6SZTMt/w0f/R54JJBJb7hKSSSSUpJJJJSkkkklKSSSSU
pJJJJSkkkklKSSSSU//S54JJBJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//T54JJ
BJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkklJrdwc7c1rWwCXTyZj6Id+6kpikj/YryCQWmBJEm
QBruczbvaz/hHN2IMEEgiCNCPAhCwqi//9TngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKRaM
3FwT9oyjFTXtH0S4ztthzWbX7nV/znv9n/CVoSjbW21rWlz2Fj22sfU4NcHMDmt1c1/+kTMnFwS4
QDKtLXY+HjHFYj1pv5H1u6N6JZRdWLj9GwYYx9rSd3Nf2i2z6X6Nv6Or/CfpVUsgW2RxudHwlV3Y
xfW6p+XmOreIe03Ahw/dd+i930kcmXF3EmYUeAZRxe4Ijtwsuc4jw+2ZHvxP/9n/7QqyUGhvdG9z
aG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAAAAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAEA
SAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0EGQAA
AAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoA
AQAAAAAAAAABOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAAB
ADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////
////////////////////A+gAAAAA/////////////////////////////wPoAAAAAP//////////
//////////////////8D6AAAAAD/////////////////////////////A+gAADhCSU0EAAAAAAAA
AgABOEJJTQQCAAAAAAAEAAAAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAA
AAQAAAAAOEJJTQQaAAAAAANJAAAABgAAAAAAAAAAAAADAAAABAAAAAAKAFUAbgB0AGkAdABsAGUA
ZAAtADIAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAABAAAAAMAAAAAAAAAAAAAAAAA
AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpj
AAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRv
bWxvbmcAAAMAAAAAAFJnaHRsb25nAAAEAAAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAF
c2xpY2UAAAASAAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2lu
ZW51bQAAAAxFU2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xp
Y2VUeXBlAAAAAEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9u
ZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAADAAAAAABSZ2h0bG9uZwAABAAAAAAD
dXJsVEVYVAAAAAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRU
YWdURVhUAAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAA
AAAACWhvcnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFs
aWduZW51bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0A
AAARRVNsaWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0
T3V0c2V0bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25n
AAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAI4QklNBAwAAAAABOYAAAABAAAAgAAA
AGAAAAGAAACQAAAABMoAGAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5B
ZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwM
DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAGAAgAMBIgACEQEDEQH/3QAEAAj/
xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYH
CAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFD
ByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2
hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGR
FKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSk
hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOeCSQSW+4Sk
kkklKSSSSUpJJJJSkkkklKSSSSUpJJa3TOl020+vba2uw1faWbmtsArFl1B20WuYzIu/VbvY/wDR
s/QpspCIsroxMjQckGQS0FwHJAkBIEESDIXWfsrKa5ljutXtqp2m4te5rCPWup/R+hZtwq/QprY/
cy1mPk31f4BZHX9nqY+8tdmEW+u9rmuc6r1P8nWZT6vY/Nsx/fc/+d9H7N6/6VNjlEjQXyxGMTK3
/9DngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKVvH6g1lLMbLxas/GrcXVMtL2PrLtbG4+Rjv
rsrrtd77KXepV6n6RVEkCAd0xkYmw6B6l0+t2/D6PiUvggPudblQT+e2vJs9De3+XTYqD3Oe99jo
L7HF7iAAJcdzvaza1v8AZTJJCIG34ni/6SZTMt/w0f/R54JJBJb7hKSSSSUpJJJJSkkkklKSSSSU
pJJJJSkkkklKSSSSU//S54JJBJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU//T54JJ
BJb7hKSSSSUpJJJJSkkkklKSSSSUpJJJJSkklJrdwc7c1rWwCXTyZj6Id+6kpikj/YryCQWmBJEm
QBruczbvaz/hHN2IMEEgiCNCPAhCwqi//9TngkkElvuEpJJJJSkkkklKSSSSUpJJJJSkkkklKRaM
3FwT9oyjFTXtH0S4ztthzWbX7nV/znv9n/CVoSjbW21rWlz2Fj22sfU4NcHMDmt1c1/+kTMnFwS4
QDKtLXY+HjHFYj1pv5H1u6N6JZRdWLj9GwYYx9rSd3Nf2i2z6X6Nv6Or/CfpVUsgW2RxudHwlV3Y
xfW6p+XmOreIe03Ahw/dd+i930kcmXF3EmYUeAZRxe4Ijtwsuc4jw+2ZHvxP/9k4QklNBCEAAAAA
AFUAAAABAQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAg
AFAAaABvAHQAbwBzAGgAbwBwACAANwAuADAAAAABADhCSU0EBgAAAAAABwAIAAAAAQEA/+ESSGh0
dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0w
TXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSIj8+Cjx4
OnhhcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eGFwdGs9J1hNUCB0b29sa2l0IDIu
OC4yLTMzLCBmcmFtZXdvcmsgMS41Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3Lncz
Lm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2Jl
LmNvbS9pWC8xLjAvJz4KCiA8cmRmOkRlc2NyaXB0aW9uIGFib3V0PSd1dWlkOjI0NDU3MjljLWE0
YmQtMTFkYS05MTk1LWJiYWQ2N2IwMjQxMycKICB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2Jl
LmNvbS94YXAvMS4wL21tLyc+CiAgPHhhcE1NOkRvY3VtZW50SUQ+YWRvYmU6ZG9jaWQ6cGhvdG9z
aG9wOjg2OWI5MTA5LWE0YmMtMTFkYS05MTk1LWJiYWQ2N2IwMjQxMzwveGFwTU06RG9jdW1lbnRJ
RD4KIDwvcmRmOkRlc2NyaXB0aW9uPgoKPC9yZGY6UkRGPgo8L3g6eGFwbWV0YT4KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cn
Pz7/7gAOQWRvYmUAZEAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAgICAgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAMABAADAREAAhEBAxEB
/90ABACA/8QBogAAAAYCAwEAAAAAAAAAAAAABwgGBQQJAwoCAQALAQAABgMBAQEAAAAAAAAAAAAG
BQQDBwIIAQkACgsQAAIBAwQBAwMCAwMDAgYJdQECAwQRBRIGIQcTIgAIMRRBMiMVCVFCFmEkMxdS
cYEYYpElQ6Gx8CY0cgoZwdE1J+FTNoLxkqJEVHNFRjdHYyhVVlcassLS4vJkg3SThGWjs8PT4yk4
ZvN1Kjk6SElKWFlaZ2hpanZ3eHl6hYaHiImKlJWWl5iZmqSlpqeoqaq0tba3uLm6xMXGx8jJytTV
1tfY2drk5ebn6Onq9PX29/j5+hEAAgEDAgQEAwUEBAQGBgVtAQIDEQQhEgUxBgAiE0FRBzJhFHEI
QoEjkRVSoWIWMwmxJMHRQ3LwF+GCNCWSUxhjRPGisiY1GVQ2RWQnCnODk0Z0wtLi8lVldVY3hIWj
s8PT4/MpGpSktMTU5PSVpbXF1eX1KEdXZjh2hpamtsbW5vZnd4eXp7fH1+f3SFhoeIiYqLjI2Oj4
OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6/9oADAMBAAIRAxEAPwCmhvr/AMgr/wBCj32YPXG8
cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Qpob6/wDIK/8AQo99mD1xvHD8z1x96631
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691//0aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvdf/9Kmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//
1KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Wmhvr/AMgr
/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Wpob6/wDIK/8AQo99mD1x
vHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3XRIAuSAP6k2H+3Pv3XuuEcscziKFhPKfpFBeaQ
/wCtHEHc/wC297IIFWwPnjrwzSgrXpf4jqvtTcKq+A6t7Lzsbi6yYfr/AHdk42B+hWSiw80ZH+x9
lk+87Naki53i0jP9KaNf8LDo0g2TebpQ1ttNzIv9GJ2/wKelWfjf8jFBZvj53kAoJJPUm/wAALkk
/wB3+AB7Sf1p5X/6aXb/APsph/6D6U/1X5n/AOma3D/smm/6A6RWb667G2yrPuXrvsDbqILvJntk
7ow8ai17tJkcVToBY/19rrfdNruyBabpbSk/wSxt/wAdY9I7naN1sxqu9suIh/Sjdf8ACB0iRPCW
KeWPWCVMZYB1YfUFCQwI/pb2YaTStMdF3WX3rr3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvdf/9emhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvddqGeWKCNXlnqJEhp4IkaWeomkYLH
DBDGGlmlkY2VVBYn6D3okAMxNFAqT5AepPl1sAsQqgljwA4nqy745fyhvnz8mY6DK7W6TyOwNnV6
xTRb57jqf9HuFeklYBaugxWRhl3dmISpurUuOkRgP1D3FPNHvZ7ccqGSG739Lm+XHhWw8Zq+hZSI
1P8ApnB+XUq8r+ynuLzUI5rTYmtrJhUS3J8FaeoVv1GHzVCPn1c51t/wnF6i6/xdPuj5gfLc0ePg
YSZLG7Cj2/13tuNUUPLC++ewJMlVSxi9i60NK1uePxBO6/ej3vcpmtOSeS9Up+Fptcz/AG+FDpH/
ABtup02v7sGybZEt5zrznpiGSsWiFB8vFm1VH+0U9C1Bsz/hON8UNdPmc70/2buTFSWklzGc3v8A
ITMzVEJ5DUOBTcG2FlLgXAp4kB/oL+yVr/70XOVGgt760tXHBUis1APzfRJ/xono7Wx+7FyeGE89
ld3CnJZpbxiR8k1xg/7UDp8H88L+U705EtL0x0BuqdqQaKZ9gdBbE2FRMEsFZKvKZDAV4LWHqaC5
+p9p/wDgfveXfSX33mSEA8fGvJpj+xVcfz6e/wBf32c2JQux8uSmnDwbSGIftLIf2r0lcj/wpx6N
p28eE+LHb1dApsjZDeGyMM2nm37VMMuq/jjV+f8ADlZF90zmFhW45wslb+jHK3+HT0kk+9dy8ppB
ylesv9KSJf5DX0z0v/CnnrB3tW/ETsinj1L66XtDalY+kk6z45MBRC6j6DVz/Ue33+6Vu4H6fOtq
T84JB/z+emV+9hs9f1OTrkD5Tof8MY6Ffan/AApT+H+cdaXfXS3fe0qeWyTSwYrZW8KRA3BLx025
6ColiF+bRFrfRT7Jrz7qvO9uC+3b9t07DgC0sZ/nGR/Po3s/vTck3LBNw2LcYVPEhYpB/KRT/LoZ
8X83v5H3zFRMNvmT4/8A8Zysgh/h3eHUtN1/nDLMbaU3XndvUNDHIzH6xZS+rn/H2QzcgfeA5HJn
28bl4CCuq1uDMlB/wtHJ/bH0exc++wXO/wChuB23xmNKXVuIWqf+GugX9knSP7h/kC/ADvrBybs+
P24tx9NVWVRqnDZvrTdsHYvWlUXBZX/gGfrMulRSMxFhQ5OkAH09rtj+8j7k8uXAsuZbWK+RMMk8
ZhnH+3QLQ/6eNukW9/dy9uOY7c3nLlzLYu+VaCQTQH/auWqP9JIo612/mX/Jj+Y/xApcru9dvU3e
PUWNSWqqexurKatrqrCUEdmNTvDZEyvuLBRRI15aiFa2hj51Tj3k7yL77cjc7PDZG5O3705oILgg
Bz6Ryjsevkp0uf4esZeefYvnfkpJb0Ww3DZkFTNACSg9ZIj3p8yNSDzbqpVWV1DKwZTyGUgg/wCs
R7milOPUMdd+/de697917r3v3Xuve/de697917r/0KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3WWGGa
pmhpqaGapqaiWOCnpqeKSeoqJ5nEcMEEESvLNNLIwVEUFmYgAEn3VmVFZ3YBAKkk0AA4kk8APXqy
qzsqIpLk0AGSSeAA8yerr/i1/JM7m7G2tB3P8t97YL4Y/H+CniydXm+yKjGY7sHK4tomqEkpNvZ2
sx+O2lFVQr+3NmJY6ixDJSSjgwHzf7+7Ftd42w8lWEm+8yE6QsAZoVbhl0DNJQ8RECvkXHU9coew
u+bnaLvvOd/HsfLYAYtOVWZlpXCOVEdfWQg+YRuju4z5y/ydv5cEL4v4c9F5H5UdxY2JqWXuPcMU
Jgmr41Umqg7K3jipqmkh+5Xldu4aKmdRZZCLH2AJfb33w90mE3PHMK7Psbmv0yVrT0METAE0/wB/
ylh5jy6H0XuB7Je1ymHknl9t33xKj6l+GqnETSKSM/75iCnyPREu/wD+fV8/+6HraHZ+7ds/HzbN
SSsWM6pwySbhSHkKJt8bnGWzS1BX9UlGlECeQq8WkTlv7uftvsIjkvrOXc7sfiuG7K/KKPStPk2v
7eo85k+8V7jb6ZI7G8i220JwsCd9PnK+p6/NdPyA6qS392Z2T2tlps92j2HvnsfNVEjSzZPfW7M7
umraRzqYq+arqwRAn+ygVR+B7mnbdp2rZoVt9o2y3tYAKBYo0jH/ABkDqGdy3fdt4mNxu253F1OT
XVLI8hz82J6QyqqDSiqoH4UBR/thYezAkniei7rl7917r3v3Xuve/de697917rplVgVYBgfqGAIP
+uDx78CRw690Yr49fLT5IfFTcMG4+ge3949eTRzxzVmCoMnLW7Mzaxurmnz+y8kavbWXgk02Plpv
IB+l1Nj7C/M3JfK3ONq1rzJskFypFA5WkqfNJVpIp+xqeoPQo5Z505o5PuVuuXd6ntjWpUNWN+GH
jaqMMean5UPW3x/LY/nm9e/KTKYPpH5LY7A9Rd55U0uK21uOjneDrHtLJSKIFx9G2Rmlm2huzISW
8ePqZZaWskYpTzaykHvCb3V+73ufKENxzBypLJe8vJVpEIrPbrxqdIpJGPN1AZRllpVus1faz7wO
283S2+w80xR2W/vRUcGkE7HFBqJMchPBGJVjhWqQvQWfzb/5Ku1ezMBuv5LfELalJtjtvEQVm4N/
9P7dooaPb3aVFCr1OTy20sVTiKmwnYMEatKaeBFp8xYroSqIeU39lvfq82m5s+VOdrxpdlchIbly
S9uThVkY5eE8NROqLjUphSj3n9iLPdra75q5Ks1i3lAXmtkFEnAyzRqMLMOOkDTJwoHy2mmyujPH
IjxSRu0ckUqNHLFIjFJI5Y3CvHJG4IZWAKkWPPvOkEEAggg9YNEEEgihHXH3vrXXvfuvde9+6917
37r3X//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Q/8Axw+L3eHy235W9ZdA7OTe+9cftuv3dWYiTOYXb6xb
fxtbjcdW1332draCiYxVmXp08YcyN5LgEA2DXNPN3L/Je3R7tzJfG3sGlEYbQ71dgzAUQE8FY1pT
HQk5W5S3/nPcZNp5csvHv1iMhXUqdilVJq5A4sopWuehw7j+GfzI/l75jqfuPuXrXH7BqI9/47I9
e11VuPau7qOs3dsyal3TTQ1uOwGXrZDSwmkR3WXQkqgqDf2H9j565G9zIN52PYt1a5U2zLMAkkZE
coMZIZ1GTUgUqRx6EG+cjc7+2s+zb5vm1rbsLlWhJeOQGSIiQAqjHAoCa0B4dAn8h/lZ8iPlduiT
dvyA7Y3X2NXfcTT47FZKt+02lt5ZpHk+121s/HLS7cwdNGXIXwU6yEfqdjc+z/lnk3ljk60Fly3s
0NrHQBmUVkennJK1Xc/a1PQDoh5m5x5m5xuzecx7xNcyVJVWNI0rXCRrREGadqivnU9F89iboM9e
9+69176e/de6xiWIkASRkngAOpJP9AL8+96T6HrVR6jrJ711vr3v3Xuve/de697917qxT4K/yy++
P5guK7Iy/TW5+s9vU3V+S25i8+nYGVz+Omqqjc9JlKygfFrhcBmlliiixEglMhjIZlte5tGHuH7s
cu+2k21Q77aXcrXiOyeCqMAIyoOrW6ZOoUpXz6k7299qOYfcmHdJtju7SJLR0V/GZ1JMgYjToR8U
U1rTy6Dz5s/BXt74H9m7S6o7ZzOytzbm3ps+l3rh5Ova3MZSh/h1Znsrt2nopzl8RhqoZOTIYiS0
axspRkIa5sDPkH3D2T3F2m93nZoLiK0gnMTeMFU6giuSNLMNNGGa8a46LOffb3evbvdrLZ95nt5r
ueASr4JZhpLsgB1Kp1alOKcCOuHcfwa7n6K6y2721ufL7HrcblIochPjNq7knrdw7cWKtxlDNUzN
9pS0ta2DzWWpKWskoZpvtKqdOWW7r7Y/cLYeYt2utltILhZUJAaRAEfDEDiSNaqzKHA1KD5461vf
t/vvL202u9XU9u0TipWN6umVBJwAdLMqsUJ0sR5Z63Af5Hnz5zXy9+PWT647RzL5fu/4/nEYLOZq
tmD5PfGxMlHPHs7eFcWOupy9P9hLjsjNYmWenjnc66g+8I/vA+28HJHM0O6bRBo5f3LU6KB2xTLT
xYh6Kah0HkGKjC9Zs+wPuNPzty1Nte7z69/23SjsT3SxNXw5D5lhQo58yoY5brXy/nzfEDE/G35c
xdlbIxUOK66+SeMyG+4MfRUwp8dhuxcbWRUvYOOpUQCGKHKVFXS5ZUUALJXyqoCqPeS/3dOd5uau
SjtW4TF902p1hJJqzQMCYWPnVQGjr6IDxPWNf3ieSYeVudBuu3whNs3VGlCgUVZlIEyjyGolZKer
kDA6o995A9QB1737r3Xvfuvde9+691//0qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdW9/y2f5a1H8l8Tur5N/JTOyd
V/CvqCmymW3hu+tq2wtX2HVbfjafI7d21kXQtS4ShdPFkshEHl8rCkpQ1S7NDCXup7qvypNZ8p8q
24vOfb0qsUYGsQh8K7r5ueKIaCne9FA1TX7We1kfNUN5zXzTcGz5EsgzSyE6DMUyyI3ko4O4zXsS
rE6Q8/lWfNvq34F/Jrc3dPZ+3t57j2nlusN07Dx+P2NS4irzEdfmtybXy1BUTQ5/MYSm+xSiwMiu
fMZQ7r6SL2M/eHkDd/cblO02HabqCK8S7jmZpSwWipIpFUVzWrimKUrnos9n+fNo9u+bLvfd1tZ5
bN7SSFVhClqs8bAkOyilENc14Y6NR/N4/mq9D/zC+u+nNndRbN7P2xkuud8Z/dGYn39j9sUVJVUG
W2+uIghx7YHc2emkqUqBqYSJGoT6Enj2D/ZP2e5i9s9z32+3q+tJorq3SNRC0hIKvqOrXGgpT0J6
GHvX7vcv+5W2bHY7NYXcMtrcPIxmVACGTSAuiRzWvGoGOqG3mhjOl5Yka19LyKpt/WxINveRYBPA
HrHfrj9zTf8AKxB/1Nj/AOjvftLfwnr3XJJYpDaOWNyPqEdWP+8E+/EEcR16o6EDqujpMj2j1njs
hTQVtBkOw9kUNdRVUazU1ZRVm58VT1dJUwuCktPUwSMjqeGViD7Ld4keLaN2licrItrKQRggiNiC
D5EHI6MdojSXd9qilQNG1zECDkEGRQQR6EYPW+988fhH8Odk/DD5Sbt2r8Yuittbk230b2LmMFuD
D9a7VxmVwuUoduVs9FksdkKXHQ1FFWUc6h45EZWVgDf3zj9uuf8Anm/575Qsrzm3cZbWXcIFdGnk
ZWUyAFWUsQQRgg9dFvcTkHkiw5F5uvbPlPborqLb5mR1gjVlYISGUhQQQcgjr58EUscqjRKkhCqW
0OrEXH50k2v76XEEcR1zY6yMyqCzMFUfUsQAP9cnge9ceHXusP3VMbf5RDzwD5EsT/QG9j9PdtLf
wnr1eI8+s/191691t2f8Jhv+PJ+Yf/h3dQf+6PevvCn723+53I//ADQuf+PxdZpfdN/3A53/AOa9
t/xyXooP/ClOSSL5kdIywyPDNF8dcVLDLExSWKWPsjfLxyxupDJJG6gqRyCL+xt91QA8jb+GFVO5
tUf82IugV96cleedgZTRhta0P/N+bqojtr5rd190dc43rPeT7WGIo0poqzJ4vD1NPmMlDBJjKmop
ofusjWYvbNFncphaOvy1Ph6aghymRpY6idWdbGa9l5B2DYd0l3ax8bx2JIVmBVSdQBNFDSFFZkjM
rOY0YqpAPULbzz5vu+7XFtN94PgqACyqQzAaSRlisYdlV5BEqCR1DMCerAP+E/PYeS2b/MT2ztmm
qJI8X2p1l2Ns/M06sfFUDFYqLe2LeRPoz0+Q2yoQ/VRI39T7jb7yu2RX3thd3bqDNZ3cEin01N4T
ftEn8upI+7buctj7m2lojkQ3lpPGw8jpUSr+wx/z6uk/4Up7Losr8Qund9vGhyWy++8fiKaYgeRK
DeWzd0JXxqx58clTgaUso+pUH8e4G+6pfyQ87b5twP6U+2sx+2KWPT/J26nb709gk3JWybiR+rBu
KqD8pYpK/wA0XrSk9579YG9e9+691737r3Xvfuvdf//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdHf/AJevwy3J86fk1s/p
fGyVuM2fADuztfdNHHqfbHXWIqadcvNTyMrRJmc3PPFj8eGBH3VSrkFI39x/7mc92nt5ynfb9KFe
+P6dvGf9EnYHSD/RQAu/9FSOJHQ/9tORbr3B5rsdiiLJYj9S4kH+hwqRqp5anJCJX8TA8AerYP56
nyt23taTYv8ALT+O0FHtHpXobC7bk7Iw+3SKegyG5qehhrNp7GneBz95RbUx08eRr9ZZqrL1avNq
mpyfcNfd55Nurwbj7rczs0+/bjI/gM+SsZJEkorwMjAolPhjUhe1upj+8Hzja2Z2/wBq+WVWHYdu
jTx1TALgAxxGnERqQ71+KRgW7lr0DP8Awnw642D2X80d9YnsTZe09+YWg6A3VkKfCbz23ht0YhMg
d47Gp469cdnKKupEraeCSRElVA6rI4Bsx9nv3l903LaeQ9um2y/mt523KNS8TtG2nwpjTUhBoTSo
rTA6Ivu17Xt26897hDudjDcQLtshCSosi18WIV0uCKgVoaVyej8/8KN+neousumPjTXdbdV9cde1
uU7U3dSZOs2PsfbO06rI0kOz0mhpa+owOMoJaynim9apIWVW5AB9xx91zfN63bfea4913i6uY0s4
yollkkCky0JAdiAaYqOpG+9Bsey7TsXKsm17Pa20j3cgYxRRxlgI6gEooqK5oeh3/wCE/vRvSXY3
wXzW4Owuneq9+Z6PvvsHHJm959fbT3Rl0x9Pg9mSU9CuSzeJrqxaOneZ2SIOEUuxAuT7Dv3lOYd/
2v3Dgtts3y8t7Y7bC2iKaSNdReWp0owFTQVNKmg6EP3buX9h3T2+nudz2SzuLgbjMuuWGORqBYqD
U6k0FTQVpnqw/tPd/wDKN6l3hl+te3qT4PbH3tgP4fLmtobt2T1Tjc1jP4lj6bK416zH1OBEsP3e
NrYp4yR6o5FI4PuMdnsverebGDddkfmC4sJNWmSOW4ZW0sVajB80YEH5jqTd4vfZfZr2bat7TYLe
/j0lo5IrdWXUoZagpiqkEfI9TM98Gf5aHzP6iFbtbp7oHc2x9yUtbT4Dsro3EbT25k8ZWRs9PLWY
HduxqakaDK4ypHqhn8qB10zRMpKmlv7he6/Im9+Heb5uUW4REF4LtpHVhxo8cpNVYeYoaZUg56vc
e3/tVz1soks9k22Xb5QQk9osaMp4VSSICjKfI1FcMpGOtHnub425r4i/PV/j1msi2aPXveOwKbCZ
+SFaeTcG08tuLb2b2pm56eMmOnq67BZCE1EaEpHUiRVNgPfQLYuaoOdfbkczQReH9Tt8xdK10SKj
pIgPmA6nSTkrQnrALfeVp+S/cU8tTy+J9NuEIR6U1xs6PGxHkShGoDAao6+jz2Rk9g4XYm8Mv2pP
tqm62xu3spWb5qN4xUU+1IdsU9I8mYk3FDko5qCXELRqxnWZWjKX1C3vlttUO5T7jZQ7Osp3V5VE
QiqJDIT26CtG1V4UzXrqFuk23W+3Xs27tENrWJjKZaGMRgd2sNUaaca4px606v55W/PhJ2dtX40Y
j4XV3x/3HuYb33rTbox3QeH2jTZiojyuL27R7ZpcvFtPHUc9WlZkzJHSJLqvMWCC5PvOP7ve3c/b
Tec2T8+R7lFafTxGNrxpCoKs5kK+IxAotCxHlx6wh+8BuHIW7WfKsHIsm2y3f1EokW0WMMdSoEDe
GoJq1QoPnw6tO/l3/wAk748fHHrbBdqfK3ae1+1e9KvDx7n3HS78FHkusuo4PtVr5cHj8JkD/Acn
X4OnVv4jlsgsyGZW8AiiQPJD/ud7+czc07rcbPydeTWfLyv4aGGqz3JrQOzjvUOfgjShoRqqxoJe
9svYblrlfarfd+cLOK85gZPEcS0aC3FK6Ap7GKD45HqKg6aAVJ4Nl/IH+Vr3tu2T4/bK3f8AE3sP
c1UanFQddUmB2RW0uXenWRJ8fgoanDR4bOzRojaY6GSZ7KSosL+4/v8Alv3e5dshzLf2W82toKMZ
i8oK14F6NrQfNwPn1IFjzF7ScwXf9XLG72e5uWqohCREPTiqVXQ5HohPVAv86f8AlCde9EbJrPlt
8V9vvtfYuMyVFTdxdU0L1FTg9sU+Yqo6Gg33sxJmmmxeGGUnip8jj9ZggM6TQBIxKi5I+w3vbufM
V/HyXzhc+NuLoTbXBoHkKirQy0oGbSCyPSpoVapIPWOHvv7K7by9YPznyhbeDt6MBc24qUjDGgmi
rUquohXStBUMtACOh2/4TDf8eT8w/wDw7uoP/dHvX2Hvvbf7ncj/APNC5/4/F0IPum/7gc7/APNe
2/45L0T/AP4Ur/8AZYvSv/iuON/9+Nvr2Nvup/8AKj79/wBLRv8AqxD0CfvUf8rxsP8A0q1/6vzd
a6fvKDrGPq9//hPB1Nk98fPObsSOmdsF0r1VvDPZGtKEwR5feUcWysDQF7aRU1cGSrp0X6lKRz+P
eO33nN5i2/25XbC/+MX95Eijz0xVlc/YCqA/Nh1kP92bZptw9xG3MJ/i1hZyOx8tUv6SD7SGcj5K
erb/APhSvvyixPxS6T66MyDJb37zi3BDBqHkfG7G2fn1rZdN7+JK3c9KCf8AVMP8fcK/dT26SbnH
f900/pW+3lCf6UsqU/OkbdTP96jcUh5O2HbNQ8W43APT+jFE9f5yL1pY+88+sEeve/de697917r3
v3Xuv//Upob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvdbp/8j3qnbnxP/l29r/MzeOPiizXY+L3v2ZWVtQkcdSnVvUOPzkG3cXB
M48sUOVymOyVWFBAlNTEbGy+8DPvA7xdc5e5+zci2MpMFq8UAA4fUXJQuxHAlVZF+Wlvn1nd7A7N
a8m+2W8c830QE90ks5J4/T2wcIoPEamV2+epfl1pxdi7/wBx9rb/AN7dnbvrJa/dPYW689vPcFXM
7SSS5XceTqcrVjU5LeOGSp8aD+yigDge85Nr2212bbdv2iyQLZ20KRIB5KihR+2lT8+sIN03K63j
ctw3a9ctd3MzyuT/ABOxY/4aD5dXuf8ACbn/ALLf7H/8V13R/wC9vsT3jv8Aen/6d/tX/S0j/wCr
U3WQv3XP+V/3T/pWP/1di6sK/wCFN3/Mjvi3/wCJc3n/AO8UnuM/umf8rBzf/wA8UX/V3qS/vX/8
kDlD/ntl/wCrXRg/+E5X/ZAGd/8AFh+x/wD3Q7H9hn70X/Tybf8A6VkH/H5uhJ92D/p3Fx/0s5/+
ORda5n88pVP8z35GEqpP2vUvJAJ/5k/sb3lF93wn/Wk5Xz+K5/7SZesYfvAAf67PM+Pw23/aNF1s
H/8ACbKWV/g32ZC0jtFT/JreaU8TMTHAknXnV08iRITpjV5pWcgWuzE/U+8aPvUqB7g7SwA1HaYq
/P8AWuBn8sdZK/daZjyBuoJNBustPl+jb8OqXv5xn/b5CX/tbfGD/wB120/c7+xv/TjF/wBJf/8A
HpOoJ98P+n4H/T2H/HY+tuj+YuAfgj8vQeR/svvZ31/8Nev94U+1/wD08Tkr/pZwf9XB1mj7nf8A
TvOdP+lbP/1bPWiz/KM69xHZX8xb4sbezVJBWYzH75qd5z0k8aPDPPsTbea3djlljf0uiZPEQvY3
vp+nvob71bnPtXtfzhc27lZWtxECOIE0ixt/xliOufPsvtsO6e5/KFtOgaJbgykHgTCjSL/xpQet
5v8AmC/Gjsj5ffGDefx+6z7QoOpclvzI7fg3HufIYvI5aCs2fj8imSze2zTYqux9YseeemhhmIlC
PT+SNwVcj3z19tOa9q5J5tsOZd22lr2K2VykYZVIlZdKPVgR2VJGKhqEZHXQX3I5V3PnXlO+5b2v
dls5LhkDuQWrGDqZKKQe4gA5oVqDg9a7m3P+E1Pfm0dwbf3Vtz5gdd4jP7WzWK3DgMnRdbbtpqvG
ZfC1sGQxtbSTQ7nSSGamqqdGVlIIt7yduvvV8t3ttc2d1yTcvbTRsjqZ4yGVwVYEGPIIJ6xltfus
cw2Vzb3lrzrbpcxOrowhkBVlIKkEPxBAPWzr8kdi0/YPxZ7t2BvQUmUTcnR2+8HnZlpylJPXy7Ly
KSZGmgfUYRFkkFRCDdo2VfyPeJfKu4ttvOGwblYEoYtwhdBXIAlXtJ86rg+uessOadvTcuUd+22+
o4l2+ZHNMEmJu4D5NkemOteL/hMCSdifL4sbsd19O6j/AFb+A70uf9ifeTn3t/8Akockf80bn/j8
XWM33S/+Sfzt/wA17b/jkvRQ/wDhSv8A9li9K/8AiuON/wDfjb69jX7qf/Kj79/0tG/6sQ9Ar71H
/K8bD/0q1/6vzda8GNxuSzWSx2Gw2PrcvmMxX0eKxGJxtNLW5LKZTIVEdJQY7H0cCvPV1tbVSrHF
GgLO7AAe8nJZYoIpZ55VSBFLMzEBVVRUsxOAABUk8B1jPFFLPLFBBGzzuwVVUEszE0CgDJJOABx6
+hB/KC+BtR8G/jHTUO9aOCPvHt6qot8dsFNEjYGUUjQ7Y2DHUozLNHtHGVDCoZSUfI1NSVJTQffN
D3t9xl9wubXksHJ5fsgYrf8ApitZJqeXiMMeYRUrmvXSn2U9u29v+U0S/QDf70iW4/oGlI4a/wDC
1Pd5a2elRTrV4/nqfLnG/Jn5lVuzNm5SLKdb/HPF1XWeHraOYTUGX3tJXfe9i5mldHeGaKHLQw4t
JEJV1xpdTZ/eXX3eeSpeU+RY7++hKbpujidgRQrFSkCnzFVJkIPDxKeXWJP3hOdIua+eZLGxmD7X
taGBSODS1rMw8jRgIwfPw6jj1Sz7nnqCOve/de697917r3v3Xuv/1aaG+v8AyCv/AEKPfZg9cbxw
/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691jlYpFI4+qRuw/11
Un/iPewKkD59aPA9b6nybwqdTfyGcvtzb2mmTFfDfqrCloLoHTclBsqkzcvp+r1ozFQz/wCqaQ/1
985uUrg7194yC5usl99uGz/QMpT9mlf2ddE+bIBs33d5rW2wE2O3XH9MRBj+eo1+3rQv99GOudvW
wT/wm8miT5ydgwvIqyz/AB13Z4UJs0ni3rsJpNA/OhWBP+HvGn70ysfb7bGAwN0jr+cU3WSX3XGA
9wNzUnJ2ySn5Sw9WH/8ACm7/AJkd8W//ABLm8/8A3ik9xl90z/lYOb/+eKL/AKu9Sb96/wD5IHKH
/PbL/wBWujB/8Jyv+yAM7/4sP2P/AO6HY/sM/ei/6eTb/wDSsg/4/N0JPuwf9O4uP+lnP/xyLrXO
/nlf9vPPkX/1C9S/++f2N7yh+75/06Tlf/TXP/aTL1jD94D/AKezzP8A6W2/7Routgn/AITY/wDZ
D/aX/izm8P8A32/VfvGr71X/AE8DZ/8ApUxf9X7jrJP7rP8AyoO7/wDS2k/6sW/VLv8AOUnhpf5x
NXU1MscFPT5H4yTzzysEihhhxm1ZJZZHPCxxopJJ4AHud/YtWf2OREBLFL8AepLSY6gr3xZV97nZ
jRQ1iSfQBY+txf5ubK3P2X8P/kzsTY+Kn3Du3d/SHYuF2zhKLS1Xm8xXbXr0x+MoQSFlrMhPpihW
41yOovz7wc5Av7Taud+VNx3CYRWUG4QPI54KokFWPyAyfl1m9z7YXe68k817dt8JlvZtvnVEHFmM
bUUfMnA9T1ocfBNuxPhl85vix2f3n1t2J1NtiLtGn2xk8n2FsvcWzqT+H7lo6naGdngqNwY/Hw1I
wkO4FnqRGzeKJdTWBv76Le4g2vnv295w2nl7dbW9u/ozIqwypKdUZEqAhGYjWUoteJ654e3v7z5G
9weUd25g2q5s7QXgjZponiGmQGNyC6qDoD6mpwHW8L/MW2J8luwPihv+h+IW/Nx7F74wU2H3dtCo
2pk6bE5XddNg6vzZvZdPkatXpopdwYaWb7cPZJKuOFGZVYsOfntfuPKm285bbJztt0Vxy7IGjlEi
lljLiiSlRnsamrzCliM9Z/e5lhzTuPJ+4pyXfyQcwxlZI9DaWkCnuiDYoWUnTkAsFBwT1pXj5bfz
nG3a2wV7O+brb3SvOLfaa7V3Y2cXICY05pTRDaZcN5hbV/m/zqtz7zy/qX7E/RDcf3VsH0GnV4ni
R6NNK1r4np+fWC39c/fP6w7f+8d8+v1afD0S661pTTpr/qr0Mnyw3Z/O1+KGw9j7j+RXfHeuI2T2
5gnpzNTbwoc9j8HXZSCpjn2Bvyegxj0uA3XU4omX7VpHSWN2SOVpYpUQj5NsvYLnLcdwteWOXtve
/spK0MRQuFIpNCC1XjDY1UBBAJADKSdc5X/vzyft1hdczb5fJYXsdKiXWELA1hlIwkhXOmpBFQCS
rAWW/wDCYWWEbO+YVMJIxMN1dPyiHUPIIf4LvaMSaL6vHrFr/S/HuKvvbA/W8jtTHg3Ofnri6lD7
ppUWPO61GrxrY0+WiXPRS/8AhSZTTVvzP6KoqcK1RW/HvC0dOrMEVp6rsze8EIZzwimSQXJ+g59j
P7q7rHyJzDI3wrubE/YIIiegZ96VGk575ejX4m2xQPtM8oHVvP8AK3/kwbB+HsuE7z7srsL2r8jX
oYazb7UlO8+xepDXU15RtKOtjSXN7rEMxjkzE0cfiBK0scYvLJCfu9777lzutxy9sEclnyvqIepp
Nc0OPEphI8VEQJr+MngJr9pPYvbeSWt+YN9kjvOZ9IKUFYreoz4dfikzQyECnBAPiLB/OU/mw4L4
v7L3B8cOhdyUmU+Su88ZPitxZnEVUVQvSG3MnTFKnKVs8Rkji3/k6OYrjKS/low/3coXTCsqn2L9
mrjm6/tuaeY7Vk5UgcMisKfVupwoB/0FSP1G4NTQK1Yqm98feO35SsLnlfl26V+aZ0Kuymv0qMMs
SP8ARmB7F4r8Zp2htHRmd2Z5HeSSRmkklldpJZZHYvJJLI5LySSOSWYklibnn30EAAAAFAOsACSS
STUnrj731rr3v3Xuve/de697917r/9amhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3XvfuvdY5V1xSIPq0bqP+QlI/4n3sGhB68cg9fRFbaQ+X
f8nzFbR24Fq8h2j8KNu0eAhiAYSbsxfXOOmxNDZbgSLujCxwNa+lgf6e+Yovf6le9819ddsdnv7l
z6RtOwY/842J66ZGz/rr7JQ2Vr3SXewoEH/DFgUqP+cigdfPAeOWJ3hqIpIKiF3hqIJVKSwTxMY5
oZUYBklikUqwPIII99OAVYBlYFTkEcCPIj7euZxDKSrCjDBHofMdGl+F/wAsN7/Cn5EbI+QGxaGm
zdVts1+L3Ftaunemod3bOztP9luDb1RVIkrUc1RBpmpajQ/29ZBFIVYKVIQ585N2/n3ljcOWtwkM
aS0ZJAKmOVDVHA8wDhhUalJFRWvQu5F5xv8AkPmaw5k2+MSPFVXjJoJInFHQnyJGVNDRgDQ0p1a1
/N//AJnfx4/mBdH/AB9xPUtBv3bm9tk76z24t6bR3tt+OiOHpsptdMan2Ofx9bkMNm4hkAUVopFk
ZPU0afT3Dnsj7S8z+2vMHMs29SW0thcW6JFJE9dRWTVlGCsvbnIpXAJ6mL3s92OWvcjl/lqHZo7i
K/guHeWOVANIaPTh1LK3dwpQ0zQdDf8Aygv5sPxH+E/xSyfT3eFf2PTbzq+2947zji2psGt3Li/4
Jm8XtmkoGOSp6yGMVTTYqbXHpugC8m/sPe93s3zpz7zlFvnL8dqbBbKKL9SYI2tGkJ7SDjuFD59C
H2S94OTeROTptl36W5F8b2WXsj1LpdYwM6hntNRTqoX+Zt8iutflf81u3e+eop87U7A3rT7Bjwk2
5MLLt/MNJt3r3bG28oKrEzTTy06plcTMIyW/cjCvYarCbfabljdeTeQtk5d3pYxuVuZtYRta980j
rRqCvawrjBqOoT92OZdr5v593vmHZmkO3TiHSXXS3ZDGjVFTTuU0zkZ6tg/k4/zUfid8HfjNvbqr
vWv7Fpt3Z/uvcW+6CLaWw6zc+N/u/ktnbFwlG8uRpqyFI61q/b9SHhK3RAjXOuwhr3z9n+cvcDmz
b945eitjZR2CQkyShG1rLM57SDijrQ1419Opl9jfdzk/kLlTcNo5gkuBeyX7ygRx6xoaKFRnUM1R
sU9PXqrj+ab8musPl58z9+97dN1G4Ztibi2117i8ZPuTCz7bzIrts7WocRkjJjZpppoEStpz4n1e
oWYW9y77P8p7vyTyHtvLu+LENxilmZgjB1pJIWXuoAcHI6iL3f5q2nnPnvct/wBkeQ7fJFCql10N
VI1VsVPmMGvV3fwh/wCFEuxNpdV7U61+YuyewKvdmzMNRbfpe2eusdi9yU+8MbiqaKjxtburblXl
MNkcZuIUsKrVT0rVUNXIPLoiLMvuAfcD7sW43u8Xm68j39stlPIXNvMzIYmY1YRuFYMlT2htJUYq
aV6nzkD7zO32e0We1c72Nw17AgQXEIVxIqgBTIjMhV6fEVLBjmi16Jf/ADpf5lPxs+fGzehMD0R/
pENZ1xujfGX3Ku+NoDbNOaPcOHwlBjzQSjKZD7ubzY+TWtl0LY3N/Y79hvavmr24v+Y7nmL6bRdQ
xLH4UniGqM5avatBQinQF99/dHlf3EseXLbl/wCo8S1mlZ/FjCCjqgFKM1TUGvDocf5en/CgSp6a
2Htvpf5h7X3bv/b21KOlwm1O4tmLR5TedFt+ihWmx2J3ttzIVWO/vH/C6eNIo8jTVAq3hUCWGaQG
Rg/7m/drTfdxut+5Hu4ba5mYvJbS1WIuTVmidQ2jUclGXTXgyjHR/wC2f3kH2Pb7XYedrSa5toQE
juY6NKEAoqyoxXXpGA4bVSmpWOerhZv5+38tKLEfxJe2N71FT49f8Dg6j7A/jOrTfxaZcNFjvJfj
/gTpv+bc+4QX7t/usZvCOzW4Wvxm5h0/8f1f8Z6m0/eM9qhF4g3icv8AwC3m1fzUL/xqnz6o0/ma
/wA81Plj1xuT48fHzrWp2r1LusxU28t8dnY7D1u9Nz46kqY6uCh25tuGbK43ZsMlTCjtWvPPkQFA
i+3JYnIP2m+72eTN0tOZ+Zd1E28w5iigZhFGxFCXchWlNCRpoE9dWOsfvdf7wI5x2u65Z5b2sw7N
NiWWdVMrgGtEQFliFQDrqz+mjqtX+Xh/MB7F/l79yV3Ym1MJS722ZvDFU+3OzOu6+tbGRblw1LV/
e4+vxWVWCq/hG5sFUPI1JUNFLEUmlikQpJdZW9zvbXa/czYo9svLg29/A5eCYDVoYijBlqNUbimo
VBqAQajMV+2XuRuftrvkm52cAnsJ0CTwk6Q6g1Uq1DpdDXSaEUJBFDgY/wCaX89+sfnn8gume5uv
Np742XjNk9bYDae58LvSnw38QhzGN31nty1T4mbCZTJU2Sxwx+UjVJWMEjyqwMaixJF7Qe3G7+3X
LW+7Fud5bzzXF08kbRFqFWhSMag6qVbUpqMgCmT0ee7vuLtPuJzLsW+7ZZ3EENvapHIsoWupZnkO
kqzBl0sKE0NfLo+nzN/4UOdkdg7dqetPhztXKdPbfnxyYnIdvbv+wqezqymFMaWZto4OjmrsLsp5
U/TVyzV1anDxCnkAIjnkT7sm1bbdJu3PF4l9chtQto6iAGtR4jkB5f8ASgIh4HUOpF56+8vue5Wz
7VyRZvZWxXSbmShnIpQ+GoJWKv8AES7eY0HrW5yORyOYyNfmMxkK7LZfLVlTkcrlcpV1GQyeTyNZ
K09XX5Cvq5JaqsrKqZy8ksjM7sbkn3lPFFFBFHBBEqQIoVVUAKqjACgUAAHADA6xblllnlknnlZ5
nYszMSWYnJJJqSScknJ6h+3Om+ve/de697917r3v3Xuve/de6//Xpob6/wDIK/8AQo99mD1xvHD8
z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdbxH/CeT5P4z
tP4j5D4+5PJRnfPxy3BW0lLjppFFVVda70yNdn9tZKnRj5JqfHZubIUEhAIhEUINta35+fea5Rm2
fnWPmaGL/dfukYJYcBPEoR1PoWUI49at6HrP/wC7RzbFvHJcnLU0v+7Da5SAp4mCVi6MPUBi6H0o
vqOqYf53v8tzcHxo7k3D8l+sdvVNV8d+4twTZnNNjafyU3VXZGbnaozGFykcCWoNtbpyTyVeMqGC
wxzTSUhIKQ+Sdvu/+6ltzXsVtypu90BzNYxBU1HNxAgorLXi8a0WQcSAH82pBXv77W3PKu+XPNW0
2xPLV9KWfSMW875ZWpwSRqsh4Akp5LWhX3kb1jr1737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+69176e/de6H/AOPvxX+Q/wAqdyR7X+P/AFLu7smu88cFbksTQfbbVwnkdU824d35
JqPbeEgjLgsZ6lWt9FJ49hrmXnDljk+1N3zJvUFrHSoVjWR/kka1dz9i/b0JeW+T+Zub7oWfLmzT
XUlaFlFI04ZeRqIgzXuYfLqzv5cfybdy/CL4UVHyI7m7Lo8527W7/wBibUpOv9kRCXZW18fuT+Iv
kv4ruLIU8eR3LmohRhFNPFSUkJvYzghhEvJXvnac/wDPycsbFtTR7IttNIZpf7WRkpp0op0xoa17
izH+jw6ljnT2OuuQeQ25m3zdFk3prmKMQxf2UavXVqcirsKUGkKo/pceqRfc/wDUBde9+691737r
3Xvfuvde9+691737r3Xvfuvdf//Qpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdGt+Fvy57F+EvyA2j3r14fvmxTviN57SmqHp
8bvvYuSlg/j+1sg4DrE9QkKT0c5VjSV0MUwB0lSDefOStr5+5bveXtz7dfdFIBVoZlB0SL60qQw/
EhZfPoY8ic6bnyFzJZcw7YdWjtljJossTU1xt9tKqc6XCt5U6+hn0P3z8d/n18fY96bKkwPY3WO/
cTNgt6bI3LRUNfU4esnhCZnZO/NtVX3C0eTonYq0cimOZNM0LPE8ch5l8xcucz+2/MpsL8SWu7Wz
h4pYyQGAPbLDIKVU+oyDVWAII66X8vcw8s+43LYvrEx3W1XCFJYnAJUkd0UqGtGHocEUZSQQeten
5uf8Jznrcll9/wDwa3Zj8fBVyzVs3RHY2SmgoaSWRg7Uuw9/SioenpCzERUWXUrEBb7y1lGTPIH3
oRHFBtvuDZMzKABdwKCT85oRSp9Wj4/778+saefvuxeJLPuXIF4qqxJNpMxoPlFMa0HosnD/AH55
da3Hd3xP+S/xuyc+L7y6N7I65aB3Rcpmtt1s+2KxUcoZsbu3FpX7ZyNOzLw8NW4I/p7yn5f5z5U5
qiWbl7mC1uq/hVwJB8mjakin5FR1i3v/ACZzVytK0XMGwXNsR+JkJjP+lkFUYfMMei8pLHILxyJI
P9odW/3on2JyCOI6DPy8+ufvXXuve/de697917r3v3XusYliaRYldXlchUiQ65XYmwVIk1OxJ/AH
vdCBUjHXhnhnoy/U/wAN/lj3pNDF1H8ce4t8QzFNOUx2xszRbfRZDZJJ9yZmnxmAp4j/AKt6lV9h
PeeeuTOXlY71zRY27D8LSqX/ACRSzn8l6Fezci85cwsBs3LN7OpHxCJgn5uwCD82HVtPRv8AwnT+
afYbUdd3BuXrPoLCy+GSopa7KP2JvJIJCpdYsNtWRdvpUohPplyqgH6/09wxzD95/kLbNceyWl3u
U4rQhfBir/ppO+n2R9TLy/8Adj563PRJvV3a7dAaVBbxpR/tY+yv2yDq8D45f8J+/g50xJQ5jsyl
3V8kt1UpWRpux6xMVslahbFZKbYW22paKaIML+PIVWQUjg35vj9zR95T3B30SQbU8O1WZ8oBqlp8
5nqfzRUPU/csfdv9v9iMc+6xzbpeD/fx0xV+UKUBHydnHV1W0tm7S2FgaDamxdrbe2ZtjFxiLG7d
2rhcdt/CUEYCropMXiqelooAQovpQXtz7gW9vr3crmS83G8lnu3NWeRmdz9rMST+3qd7Kxsttto7
Pb7OKC0QUVI1VEH2KoAH7OtdD/hQj8qvj3lvjC3xqwXam1tx92ydpbG3PWbD25WjO5HBYbb4zJyV
RuWpxgqcdt6dDUoEpqqaOqlLXWMrdhlD92fk7maHm0c13GzzRbALOWMTONCuz6dIjDUZxg1ZQVHm
a9YxfeV5v5am5SPK1vu8Uu/G8icxIdZRU1ai5WqociisQx8h1pke87OsF+ve/de697917r3v3Xuv
e/de697917r3v3Xuv//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+690Zr4r/AC/7/wDhn2HH2R0Jviq21kKgQ0+5NuVi
tktl73xkL6xit3bclkSlyUA58U6GKspWOqGWM3uE+cOSOW+e9sO1cx7essYqUcdssTH8Ub8VPqMq
3BlPQs5Q525j5G3Mbpy7fmKQ0Doe6KVR+GRODD0OGXirA9bf/wAOv+FAHxW7zpMVtj5CA/Gfs2VY
qaoqs9PNk+pszWEKhnxG9Y4vLt+OolJIgy8VOsI4+4l/V7wi54+7Zzjy8813yz/u22kVICALcKPR
ovx09Yy1f4Rw6zY5I+8fyhzCkNpzJ/uq3U4Jclrdj6rLTsr6SAAfxnj1eViczszsbbceSwWV2vv3
aGag/Zr8TXYndO28tSuA37dTSS12MroHUg8MykH3j5NBf7XdGK4hmtr2M5DBo3U/YaMD1kBDPYbp
aiW3mhuLKQYKlZEYfaKqR+3oqXZX8uX4I9u1Etbv/wCKHSWWr57mbJY7ZWN2vlZWIsXkym1FwmQe
Q/6oyFr/AJ9jHavdH3E2RRHtvOV+kY4K0rSL/vMmtf5dBDc/bH2+3h2kv+ULFpTxZYhGx+1o9Dfz
6KTuP+Q3/LNz8sktN0ruLbGskiPbHafYdHFGSCP246/cGSUAE3ANx/sPY1tfvF+69soV9+im/wCa
lvCf8CL0C7r7u/tVcsWXYpYif4LiYf8AHnbpAy/8J5f5ckjs6YTueBT9Iou2cmY04A9Jmx80pv8A
Xlj7Ml+817ogAG4sSf8AnnX/ACMOi8/dq9sSSRb3o/6iD/lU9PeN/wCE/f8ALYoJEefr/srMadN0
ynbm8PG+kWOtMfVUAOs8n6c/Sw9p5fvKe6kgIXcrVP8AS20f/PwPT0f3b/a1CC223T/6a4k/59K9
DXtf+TD/ACzNq+N6b4rbSzM8ZUibdm4t9bp1lTcGSlze6Kugf/W8VvZBee+3uve1D84TIp8o0hj/
AJpGD/Po/svY32rsaGLlKJ29Xkmf9oaQj+XRwOvvif8AF/qdIV61+PHS2yZINJiqtu9a7Rx2QUqA
AxyMWKFez8fUyEn2CNz5z5u3ksd15mv7gHiHnkYf7yWp/LoabbybylswX91cs2FuRwKQRqf96C1/
n0YFF0oscahI0UIiIoRFRRZVVVAVVUCwA4A9hompJPHoSgAAADHRZu5vmb8UPj1TzT9zfIPqrYU8
AYth8pu7F1O5ZNAJIp9q4uav3HVNxYCOlYk8fX2LNi5E5y5mZV2Llq8uVP4ljYR/nIwCD82HQU3z
nnk/ltWO+cyWduw/C0imT8o1Jc/kvVMHyD/4Uh/GPZEddi/jz1pv3vLOos0VNns6i9abBWcXWKoF
RlIchuzJU4bkouNp9Y+kg4Pud+Wfus82X5jm5m3W22+3NKon681PSilY1Pz8RqenUF8y/ei5TsFk
i5a2u43C4ph3/Qhr61YNIR8tC1Hnw61/vlJ/OT+dfyljyWDyPZY6f6+yHmik2D0ulXtGmqaKbhqP
M7r+6qd5ZqFkFnjatip35vFz7yT5Q9i/bzlAxXEW0/XbktD411SQgjzWOgiU+h0Fh69Y383e+XuD
zcJbeTdPottav6VtWMEejSVMrfMF9J/h6qwYlnkldmklmkeaaWRmklmmkYtJLNK5aSWWRjdmYlie
SfcwjAAAoAKAeg+XUQEkkkmpPXXv3Wuve/de697917r3v3Xuve/de697917r3v3Xuv/Spob6/wDI
K/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3XiARYgEH6g8g+/de6FrqbvvvDobJjL9K9u9i9WVwk8rtsjduYwVJUP8A1rMX
S1IxVcG+hE0Dgj6+yXeeW+X+YovA37ZLW8jpT9WNXI+xiNQ/Ijo72bmXmDl2YT7FvV1aSVr+lIyA
/aoND+YPVoPWf8/D+Y917DSUeZ7B2F2xQUgVBH2R11iHyMsa/UT5rZ0u0shPIR/blMjf4+4j3b7u
PtbubO8G23NnIf8AfE7UH2LL4ij7BTqWtp+8Z7n7YiRz7jb3iD/f8K1I+bReGxPzJPRyttf8KbO/
KWOJN4fGDqLOOoUSzbc3lvDbZksLM4iyNLuVUZvrbVb2Bbr7p3Ljkmy5tvYx6PFHJ/NTH0Obb713
MKBRecqWch8ykkkf8j4nQsUX/CnucJ/uS+HBaTSvNB3JGsevnXxU7ELaf6fn+vsmk+6Stf0uecfO
1/zTdHEf3sjT9XkjPyuf88PUbI/8KesmQ/8ACPhzTI1h4/4n3GzqDpOryfabFUkF/pb8e7RfdJhx
4/PB/wBrbf55uqS/eylz4HJAr/Suf80PQSbi/wCFNHyLq0lTanxo6YwTMGEc2d3RvXcbxXvpYpRf
3djkI/xsD7OrX7p3K6EG85rv5B/QjiT/AA6+ia5+9bzK4YWnK1jGfLU8sn+Ax9FU33/woD/mPbwW
phwW7+res6eoBUDZXWGLrKuFT/xyrt7Ve7HVwP7QQN/S3sY7d92v2tsSjXFleXbD/fs7AH8ohH0D
9w+8j7n3qutveWlpX/fUCkj85TIfz6IF2l87/mh3Wk1P2d8oO6NzUE+ry4dN65Pb+CYOSWT+B7Yf
C4rxm/6fFa3uSdo9uuQ9hKttPKNhFIPxeErv/vcmpv59Rxu/uJz1voK7rzZfSxn8Pisif7wmlf5d
FNceSaSplLTVMzF5qmZmmqJnY3Z5p5C0srsTcliSfYzGFCrhRwAwP2dA0ksdTGrfPPXfv3Wuve/d
e697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuv/9Omhvr/AMgr/wBCj32YPXG8cPzP
XH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Upob6/wDIK/8AQo99mD1xvHD8z1x96631737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691//1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvdf/9amhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3X//Xpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//0KaG
+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Gmhvr/AMgr/wBC
j32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Spob6/wDIK/8AQo99mD1xvHD8
z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691//06aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvdf/9Smhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3X//Vpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691//1qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9em
hvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Qpob6/wDIK/8A
Qo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//0aaG+v8AyCv/AEKPfZg9cbxw
/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Kmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691//1KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvdf/9Wmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//W
pob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//16aG+v8AyCv/
AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Cmhvr/AMgr/wBCj32YPXG8
cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691//0qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvdf/9Omhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3X//Upob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//
1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9amhvr/AMgr
/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Xpob6/wDIK/8AQo99mD1x
vHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//0KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut
9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvdf/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3X//Spob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691//06aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf
/9Smhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Vpob6/wDI
K/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//1qaG+v8AyCv/AEKPfZg9
cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9emhvr/AMgr/wBCj32YPXG8cPzPXH3r
rfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3X//Qpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691//0aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvdf/9Kmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//1KaG+v8A
yCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Wmhvr/AMgr/wBCj32Y
PXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Wpob6/wDIK/8AQo99mD1xvHD8z1x9
6631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691//16aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvdf/9Cmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3X//Rpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91//0qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Omhvr/
AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Upob6/wDIK/8AQo99
mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//1aaG+v8AyCv/AEKPfZg9cbxw/M9c
feut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvdf/9amhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3X//Xpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691//0KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvdf/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Spob6
/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//06aG+v8AyCv/AEKP
fZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf/9Smhvr/AMgr/wBCj32YPXG8cPzP
XH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdG
k+Hfx+258mO6U613hvrK9b7WouvO0ux9wbtwm2Yd4ZagxHV2xszvjIQY/b1RlMLFkaqupMM8SKam
OzMPr7CHPPMt1ynsB3ax25Lq8a6t4EjeQxKWuJViUlwraQCwJ7T0L+R+W7TmrfhtV9uD2tmttcTv
IieIwW3iaUgIWTUSFoO4dDEvVv8ALBZVYfNH5Q2YBh/zh9gvoRcf81m9kP7592/+mE2j/uZP/wBs
vQg/cvtN/wBN1un/AHLk/wC2vrl/or/lhf8AeaPyh/8ASPsF/wDbl9+/fPu3/wBMJtH/AHMn/wC2
Xr37l9pv+m63T/uXJ/219e/0V/ywv+80flD/AOkfYL/7cvv37592/wDphNo/7mT/APbL179y+03/
AE3W6f8AcuT/ALa+vf6K/wCWF/3mj8of/SPsF/8Abl9+/fPu3/0wm0f9zJ/+2Xr37l9pv+m63T/u
XJ/219e/0V/ywv8AvNH5Q/8ApH2C/wDty+/fvn3b/wCmE2j/ALmT/wDbL179y+03/Tdbp/3Lk/7a
+vf6K/5YX/eaPyh/9I+wX/25ffv3z7t/9MJtH/cyf/tl69+5fab/AKbrdP8AuXJ/219e/wBFf8sL
/vNH5Q/+kfYL/wC3L79++fdv/phNo/7mT/8AbL179y+03/Tdbp/3Lk/7a+vf6K/5YX/eaPyh/wDS
PsF/9uX3798+7f8A0wm0f9zJ/wDtl69+5fab/put0/7lyf8AbX17/RX/ACwvx80flDf8X+H2Ctf/
AB/4zN79++fdv/phNo/7mT/9svXv3L7Tf9N1un/cuT/tr6mUvw1+O3akiY/4x/PXqjeO8KkBcZ1t
8hdlbm+Mm6M7VtxHjMFufcVXuPrOsydQ5CRRT5el8j8BvdG575n2cGTm325vILIfFPZSx38aD+J4
0CThR5kRNTracics7v8Ap8qe4lnPenhDeRPYux/hSRzJAWPAAyrU4r0TTtrp3tPofe+S637k2HuP
rre+KWOWpwG5aFqWaejnuaXK4qrjabHZvC1yeqnraOaelnQ3SRh7Hey75s/Me3xbrsW4xXW3vgPG
agEcVYfEjj8SMAw8x0BN62Pd+Xdwl2vfNultb9KEo4oSDwZTwZT5MpKnyJ6Db2a9FXXvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvdf/1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691Yb/LG/7KO3j/4qj8wP
/get9+4x92v+VVsv+lztv/abD1JntP8A8rTff9Kbcv8AtDl6rlg/zEP/ACyj/wChB7k9viP29RkO
A6y+9db697917r3v3XuslPFNV1UFDRwT1ldUusVNRUcMtVWVMrmyR09LTpJUTSMeAFUkn3pmVEaR
2CxgVJJoB9pOB1ZFaR1jjUs5NAAKkn5AdHN6v/lzfO7uSmp6/r74o9z5LF1RX7bM5vak+ysLOrWt
JDlN6ybfpJorG+pGZbewJu3uh7d7G7R7lzjYLMOKpIJWH2rFrIP2jodbT7X+4W9oJNt5QvmiJwzR
mJT8w0uhSPmD0b3CfyFf5l+XpkqqrqfYu21cXEW4u3dkQVA4Bs8ONrsoUNzbk/X2Cbj7xntTA5RN
5uJT/QtpaftYL0Nbf7u3ulOgd9ogi+T3EVf+Ms3WDcf8hv8AmZbfpHrKfp3aG6I0BPi2v2xserqn
sL2jpslkcU8hP04/Pu1r94r2ouXCNvc8J9ZLeUD9qq3Vbr7u/unbIXTZYZvkk8RP7GZeiEd0fDz5
U/HUNN3d8fe1euccl/8Ac/mtp5CfaraW0kpuzFJkdtsL/wDTUPcj7DzxyfzPRdg5ls7qX+BZAJP+
cbaX/wCM9R1vvI/N/LILb9y5d20QHxtG3h/85BVD+TdFsIjlTkJIjC/NnRh+P6gj2Kcg/PoK9WUf
G35A7Z7r2vhPhZ8wM4+T6szc5w/QPeWdc5DefxS7EybCn2/VUeeqWbI5Ho/PZN46XP4GeVqalhl+
8phFJCQ0V808tXewXk/PnJFvo3eMary0Tti3CFcuCg7Vu0WrQzAamI0PUNiVOVuZLTf7ODkTnW41
bTIdNndv3S2EzfAQ5ybV2os0JOlVOtNLLkkXa3WG9Oleyt89SdiYpsLvfrvc2U2puXHFvJFHksVU
NC1RRz2C1WOr4dFRSzL6ZqeVHHDD3IOzbvYb/tW371tc3ibfdRLJG39FhWhHkwNQw8mBHl1Hu8bT
f7Duu4bLucPh7haytHIv9JTSoPmp4qfNSD59B/7M+i3r3v3Xuve/de697917r3v3Xuve/de69791
7r//1qaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691Yb/LG/7KO3j/4qj8wP/get9+4x92v+VVsv+lztv/abD1Jn
tP8A8rTff9Kbcv8AtDl6rlg/zEP/ACyj/wChB7k9viP29RkOA6y+9db6yQxSVE0NPCvknqJooIYw
VBkmmkWKJAWKqNbsBckAfk296YhVZ2NFAqfsHW1UsyqvxE0H2nqzPEfGz4afG+OPJfNbvjI9n9iw
IJm+LXxErcTunJ4yo0ErjO0++qt/7g7YqUlKrU0WGfI1cQDDyhxYRPNzVz1zSxi5C5dW02s4/eG5
Bo1YfxW9oP1pB/C8uhTjtp1LNvytyNysFm575ha73MZ+g24rIVP8M92f0UORqSLxGGcg46EGD+bJ
WdMUzYT4L/Ez47fE/FwSMKXelXtodzd1VcaIsVPUZbsDfCPFLXBV1sftJU8jG3FvZY3sym+sLj3C
5z3PeZiMxB/pbUeoWGLgPL4hjoyX3kbYlMHIHJu27REOEpT6m6NMAtNNWp/2nRUuyP5iXzr7bab+
/fyw7tyFNPI8r4zD7zrtn4ZWe4KxYjZ38Bx8Uek20iO1uPYy2r2x9vNlC/u7k2wVwPiaISt/vUus
/wA+gbuvub7g71UbhzhfspPBJWjX/eY9C/y6LNX9jdjZWV6jKdi9gZKdzqeav3tuisldvrdpKjKy
MTf2K49q2qFQsO12yL6CKMD+S9BaTd91mOqXc7hm9TIxP8z0+7a7u7r2bVxV+0e5O2NsVsLrJFU4
HsbeGMlR0OpWBpczGDY/1BB/PtPdcv7BfIY73YrOaM+TwxsP5r0/bcw7/ZMr2e+XcLg4KTSKf5MO
rNPjr/PH+cXTNRFh+wt6Yv5O9aTAUu4Njd0UdHl8lXYuRDDU01HvilpUz0EskN9Irv4jTEj1wsL+
4n5n+797f76hn2yxfad1GUltSVUN5ExE6CP9Job0YdStyz7/APP2xsId0vV3Xazh4rkBiVpQgS01
1P8ATLr6qej99vfCP4jfzTPjvur5ffy49uRdT9+7NjmrO2vjTEtJQ4/L5haWbI1WHpcFQt/C8HuT
KwQSy4bI41YsXmtHikhhqPIYo42Tn/nT2h5ns+SfdC6N5y3OQLe+NSyrUKGLnudFJAlR6yRcQzLp
1SNvfIPJnu5yzd86e2NsLPmKAE3FiKBWahYqFHartQmJ0pHJlSqvq06wc0MkbTU1TDLBNG8tPUU8
8bwzwTRs0U0E0ThZIZoZFKsrAMrAg8j3lqrAhWRgVOQRkEeRHqD1iYylSyspDA0IOCCOIPzHVjHz
sq27J2F8I/ktWSNU7n7m+NcG0OxMg6gTZjfvx53ZlepqnO1kg5qK/LbUx2JM8hu0kkZYkk+4x9u0
/de48/8AKiClnYbqZYR5LDexrcBB6BZGkoPIEDqTfcN/3pt3IXNTtW7vtqEcx82mspGti5PmWjWO
p8yK9V2+5P6jHr3v3Xuve/de697917r3v3Xuve/de697917r/9emhvr/AMgr/wBCj32YPXG8cPzP
XH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdW
G/yxv+yjt4/+Ko/MD/4HrffuMfdr/lVbL/pc7b/2mw9SZ7T/APK033/Sm3L/ALQ5eq5YP8xD/wAs
o/8AoQe5Pb4j9vUZDgOjTfF/4t7n+Sma3pWfx/F9c9RdRbVqt+929y7njlba/XO0qVJRTK0cWmXN
bs3NWxCjw+KgJqK2qbgBEdgEObub7TlSCwT6Z7rer2YQ2trHTxJ5Dx44WOMd0sh7UX5kDoX8pcoX
fNU9+/1KWuzWUJmurl/7OGMcPm0jntjjHc7cMAkHN6lynxJi/lm9t4/dXxF7Z3h8lJK/eX90Pk7i
+pcxlOuNqU75nBnCxZjsqHNQYzDy4aiE0MyPSSeB51U3LXAE3qLnM+7GyyWfOlnBytpi8Swa4VZ5
DpfVpgKFm1GhHcKgE+XQ72abk0e1G9R3fJl5NzOWk8O+W3ZoI+5NOqbWAukVB7TQkDqu7bPx47+3
fg6DcezOh+5N1bZycckuLz+1+r96ZzBZGKKaSnlkx+VxWEqqCsjjqInRjHIwDqQeQR7k675n5bsb
iS1v+YrGG7Q9ySXESOuK9ys4IwQcjh1GNry1zJfQR3Vly9fTWr5V44JXRs0qGVSDkUwePSX3x1n2
X1nLSU/Y/XO/evanIxSzY2DfOz9w7TkyMcP+dehTPY6gNWsRI1ePVp/PtZt+7bTuwdtq3S2ukUgM
YZUk019dDGn59JNw2nddqKLum13FszglRLG8ZanprAr+XVzHyy/lQbX6j+Cnxe+TnRkPe/afY/cu
O2BmN/bXpcRT7t2/tjEbo60yG8szlaLHbU2pHmMXjcfl6aKCOerqJYlieztrIPuCuTfeS73r3D5u
5T5hbbrPa7FplhkLGN5GjnWJVLSSaWZlJJCqDUYx1OHOPs7abN7e8pc2cvruN5ul8kLTRhRIkayQ
GVmCxx6lUMAAWYihznqm7r7qzs/tvLzYDqrrnfPZWbpoRU1WK2JtXNbpraSnYkLUVkOGo6s0cLML
BpdCk8C/uctz3jaNlgW53jdLe0tyaBppFjBPoCxFT9nUI7Zs+7b1M1vs+13F1OBUrFG0hA9SFBoP
mem7fGwt99aZ6o2p2PsrdmwN0Uscc9Rt7ee38rtrNRQSkiKoOPy9LSVLU8pU6ZFUo1uD7e27ctu3
a3W82u/hubQmgeJ1kWvpqUkV+XHprcNt3HarlrPdLCa2uwKlJUZGp66WANPn1sq/zsuqei+heq/5
du9th9HdZbfkydRk8vvai2xtLBbYbfUGM2d13kRj9x1WLx0bZON5qiZgahZhrlYsG1MDip7CbxzD
zHvHudYbjzBdyBAqxGSR5PCLSzrVAzHTgD4aYA6ym9+dn5e5d2f2zv8AbuX7SMuWaUJGkfihY4Wo
5Ve7JPGuSeisfyYfkVX0H803BNsvAU+yNj/ITFby2duTYeIZBh4KWi21V7rwlStPTxU9IlRjM9t4
So6Rjxx1EyA2kYsMPfXleOT2guPr7k3G4bY8UqTN8RJkEbCpJNGR6EE5KqfIdBH2M5nkj93Lf6C3
Fvt+5JLG8K/CAEMimgAFVdKjGAzDzPRPf5tfWuD6o/mKfKPau26eGjw1Xvql3nTUVNGsNPRT7/25
hd6ZKmgiQBI4Y8pm5iqgAAG3sb+zG63G8+2HKN5dMWnW3MRJySIXaJST66UHQJ95tqt9n9zebbO1
ULA1wJQBgAzIsrAfLU56bfkR/wBkKfy5v8Kf5Ygf63+mPGm3+tc+3uVv+nh+6P27d/2jHpjmf/p3
3tj9m4/9pK9EC9yV1G/Xvfuvde9+691737r3Xvfuvde9+691737r3X//0KaG+v8AyCv/AEKPfZg9
cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691Yb/LG/7KO3j/4qj8wP/get9+4x92v+VVsv+lztv/abD1JntP8A8rTff9Kbcv8AtDl6rlhv
4IdKl2MUYVFF2diqhUUflmPA/wAfcnn4jU4r1GQ4Cgz1eN/MLwcfws+GfxG+B+2fHjt19o7ZpflV
8psjSFI67dG8c7potkbVysqIk82H2aYaqKGndjEWoYJQofUTj97Z3B5856509xLurWdnKdv29Twj
iTMsi+QaWqkkZ72WtKUn/wBy4ByJyNyZ7eWgC3l3ENwv2HGSR8RRtTJWKjAA47Falej0/FRj/wBA
4Pyp5PGZ7bA5PAO7tlXA/wADqP8At/cec4f+JScn/wDNO3/6ty9SFyj/AOIwc3f6e4/6uRdD9sj5
MdufEv8A4T79Fd1dKZjF4bf+CfDYfG1+bwdFuPHxUG4O6txY3JxNisiGpZGlpahgrEXRjcc+w5f8
qbLzn95TmHYd+geTbZNTMEcoapaoy9y54j8+hHt/NW8cm/dv5f37YplTcY9CqWUOKPdOrdrAjgfT
pLdx9ybr+d38gTsnvz5E0O19w9p7U3BWV+E3Dhtv0uDXH5ba3beG23QZagooDJDjayq29kpqOpEB
SOaJ2uvJ9q9k2Oz9u/vIbVy5yxJNFtE0QDIzl6rJbM5Uk5YB1DLWpBAz0k3ve7v3D+7punMXM0cU
u7Qyko6oF0tHcogYAYUlGKtpoCCcdCB81vl13f8AD7+UZ8Ed29GZvC4PNb82L1H17uWbN7cx+44q
na+T6KylfV01LDkQUoqtqnHxFZ09agED6+y3kPkrYOd/er3DsuYLeSSC3uLmZArslJFu1AJK8RRj
g46MOeudN+5J9mPby92CdI5ri3toX1Ir1ja0YkDVWhqBkZ6HnrX48fJf4z/y3vjjsT+XNS9JbU7i
7GwO0ewe3+zu1amgo566o3XtePc2XyVHFW4vJ0ufzTZDKQ0FIKpJIKDGwaY01FWAc3XmflTmv3S5
o3H3Pe/m2S1kkhtoLcEgCOTw1U0ZSi6VLtpILyNUmlR0JNp5a5o5U9r+WNv9s47GHerqOOa5nnKg
sZIw7MNSsHarBF1AhI1oBUggAv5qfTPYHbP8qKLtH5d0nUf+zg/HvIYLLzbr6xyNHXY7MYrKb8x+
0MlR0E6QUM1PR7m27m4K6roEj+3hyNKGiVVHAk9nt923ZveM7RyU97/Unc1dRHOpDKywtIpIqQTG
6FFcnUUahJPQb939j3HePZ/9785pZ/10211bxIGDBlaYRkA0XDo4dkA0h1qAB0XP/hRB/wBk4/y7
v+1Vuj/333XHsUfdk/5Wn3O/08f/AFen6C/3mP8AlV/bP/SSf9WYegi/4T5/EXKP2Puz57doQDan
TnTm1N24vY+4s8P4fjc5uWrxs9NvHdEFTUhYm21sXayVcdRVX8RrKkKrE08oU6+8rzrD+67L252h
vG3y+mjaVE7mRAwMUZA/HLJpIXjpXI7lqTfdt5Ll/ed57ibuvg7JYwyLE74VnKkSSAn8EUeoM3DU
2D2tSlX5vd+wfKH5ad9d7UHmGD3/ANgZSr2qtQCs6bOxKQYDaXmQgGOWTb2Kp3ZSLqzke565A5cb
lHkzlzl2Sn1FtbKJKcPFaryU/wBuzD8uoH5+5jXm3nLmLmGOvgXNyxjrx8JaJHX56FBPQu/If/sh
T+XN/wBQ/wAsf/fx432S8rf9PD90ft27/tGPRzzP/wBO+9sfs3H/ALSV6IF7krqN+ve/de697917
r3v3Xuve/de697917r3v3Xuv/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdWG/yxv+yjt4/+Ko/MD/4Hrffu
Mfdr/lVbL/pc7b/2mw9SZ7T/APK033/Sm3L/ALQ5eiBbPmpafcW0aiu0/Ywbg25NWl7aBRxZSikq
S9+NAgVr/wCHuRr5Xa1vVj/tDE4H2lTT+fUd2TIt3ZtJ/ZiVCfsDCv8ALq+X/hRZtLJY75ldZ77W
IttLsD49bPG1ayNW+1cbZzWfpclRQvzFrp48nTTFFNwlQpI9QJx2+7BexS8jbttxP+O225yeIPP9
REKk/bpYV9VPp1kP95uyli542rcQP8Sudtj8M+X6buGA+wMp+wj16ZvjF85ehNv/AMnX5ZfDDeO5
TtTufIvu3O9f43JUdc+O7Co915jaeQWhwmTpaaejgzmMnxtQstNUvCXiCPGXuwV/m32+5juffDkz
nuxtPG2JfDSZlI1QmNZBV1JBKMGWjLXNQaYqxyn7gcu2/sjzlyNfXXg743iNCpB0zCRozRWAIDgq
QVamKEE5ouuyvl18bcz/ACHutfi1i+29t1nyBw2R2tNlOr4osuNwUcdD3DltwVbSySY1MWRBhJ0q
W01B9DAfq49l21clc0wfeJ3Xm+bZZV5bkWTTcVXQa2yoPxassNPDj0Y7rznyvP8Ad42vlOLeI25i
Ro9UFG1ilyznOnThe74uHz64dYfLj424X+Q/2t8Wst23tyh+QOdye5p8R1fLFlzn66Ot7d2/n6Vo
pI8a+LAmwtLJUDVUD0IQfVx73u/JfNNx94nZ+b4dllblqNIw1wCugUtnQ/i1YYhfh49a2jnPli3+
7zvHKk28RrzFI7lYKNrNblHGdOnKgn4uHz6HmH5Yfy2/nN/Lc6N+Ofym7w3H0F2d8dtvYCGlwtDR
ZKnlz26dh7Jy+zMLWYrJrtjc2FzG3dz4yoSSSJmp6mmqJCh0hA7h1uTfdP2+90+YeaOUOX4ty2nc
5XJclTojmlWVgy+JG6vGwIB7lYCua0AiTm/2v9wPa3YOWebd+l27ddsiQBQG75IYmiUq3hyIySKa
kHSyk0xSpaeovmL8CPn38HepPiZ86e3NzfG7troCDE4/Z/Z+Oq6zGY7OUW2sW228Nl8ZnIsZlsMX
yO1pI6XKYvJxxXqKcTwSG6BHt75H9xvbj3A3vnP292WLdNl3Is0kDAMyGRvEZWTUr9slWjkjJ7W0
sONWdj529vPcbkHZuTuf94l2zettCrHOpIDBF8NWVtLLmMhXSQDuGpTwpXr8/dgfywerOpNlbK+H
3yC7c7670gz81VvDeNTl67Mdd5bbFWrmSj3A9VRYPCUeRxU9PEcdFh4Khm8kpq5D+2Vkv223L3a3
fer+/wCduWrLbuXjHSKIKFmWQeaULuVYE6zKV4DQONY29yNu9qNo2ax2/kvmK83DmASVkkJJhaM1
w9VRQykDQIw1anxD8NDkfLn5+/C/5rYj+VtQb7r6ui2v1PvunpPlbsDcOI3FTf3b2pHhNh4zPyRZ
HDwE7gwGX/gdWKd8dM1S8NgyRu2kAbkv23585Cn93ZdujVru9tydvmRkOuTVMyVVj2Outa6xpB4E
gV6G/OXuPyLz3B7Sx7hKy2tncAX8Tq40IFhV6Mo70bS1Ch1U4gE06C7+ZV/OFx3fvXsHxL+HG0qj
pv4qYeipcDlKqDG021812Hg8WVFFtvHbdxwWLZ3XqNGrvSEmsyBUecRRloXOPar2Ql5c3Nuc+ebw
X3ODsXUFjIsLtxdnb+1m9G+FPw1NGBN7p+9kXMW2rybyRZmx5PRQjEKI2mVeCBF/soeBK/E/4qCq
mhT3kZ1jt1YL8h/+yFP5c3/UP8sf/fx433GvK3/Tw/dH7du/7Rj1JHM//TvvbH7Nx/7SV6IF7krq
N+ve/de697917r3v3Xuve/de697917r3v3Xuv//Spob6/wDIK/8AQo99mD1xvHD8z1x96631737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Vhv8sb/so7eP
/iqPzA/+B6337jH3a/5VWy/6XO2/9psPUme0/wDytN9/0pty/wC0OXquSIBqeJT9GhQGxsbFAOD+
D7k84Yn59RkOA62/uhoemv54X8vnaXx531u+h2X8yfi7haOh2/uOsCT5L/cZjocBh95vjUaKqz+w
99YejpaTPxwky0eTgWXhhTiXCXmJt9+7/wC5d7zNt9k0/I27yEugwvcxdotWQk0TFmhJw0ZI4aqZ
rcvDY/f322s+WtwvVg532mMBHOW7QEWSnF4pVCrMBlZAG/g1a4vyh+Bvys+HmercT3j1HuPEYWnq
Xgx/YmBoqvcnWmeiHMVVi94Y2nkoIBPH6hT1n2tXHezxKQR7yi5R9xeTud7eObl/eonnIqYXISdP
k0TGpp/EupT5MesYObfbvnDkm4kh3/ZpUgU4mQF4H+ayKKZ/hbS481HRPVmhf9Esb/8ABXU/70fY
4II4joE8D8+udx9bj/X9669jrg00KfrljX/gzqv+9ke90J4A9eGcDj0JHXPUHbXcOTiwvU3V/YPZ
eUmdUSj2Ns/PbmYMxABllxdDUU1Ol2F2kdFH5Psq3TfNl2OIz7zu9taQjzllSP8A48QT+XRrtex7
1vcog2fabm6lJpSKN3P56QaD5nHVwvxy/wCE/nzn7lmoMl2fRbU+N2z5zHLUVW+8jFn97vTMy+Ra
DY22Jqsw1gQmyZGtoLH63+nuEOaPvJ+32xLJFtEk26Xo4CJSkVfnLIBUfNFfqbOWPu38/wC+NHLu
yQ7ZZHiZW1y0/oxJXPydk6NB/My/lffEL+X18EjWbZz1Rvf5Hbp7G2DQU+9t+5+jpd15HAxT5STc
0Wxdh0NVBQYjA6FiNW6Q1k6KFWSpsQCEvaj3b529yvcMJd24t+V4bWYmKFCYw5C+H40xBLPx0glQ
ckJ0LPdb2n5L9t/b3XaXBn5nmuoQJZXAkZAWLiKEEBU4ajR2AoC/Wst7yw6xS697917qwX5D/wDZ
Cn8ub/qH+WP/AL+PG+415W/6eH7o/bt3/aMepI5n/wCnfe2P2bj/ANpK9EC9yV1G/Xvfuvde9+69
1737r3Xvfuvde9+691737r3X/9Omhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdWG/yxv+yjt4/+Ko/MD/4Hrffu
Mfdr/lVbL/pc7b/2mw9SZ7T/APK033/Sm3L/ALQ5eq5YP8xD/wAso/8AoQe5Pb4j9vUZDgOl71v2
X2D09vbA9kdWbxz+wd97YqxW4LdO2q+XHZWgm+kkYkjvHU0dVH6J6eZZIJ4yUkRlJHsu3Xads3yw
uNr3ixjudulFHjkGpT/mI4hhQg5BB6Mdq3bctjv7fdNovpLfcIjVJEOlgf8AKDwINQRggjrZV+M3
/CkndGMw1Js75jdJ0vYtKKdKGu7F6sOOxWWydOfTLUbi67zrrt3IVUqf5w0VZRQv+KdfocVea/us
Wks733I+/m1etRDcamVT6JMneB6a1c/0usqOVfvR3UUCWXO+xC5SlDNBRWYf04X7GNOOlkHovRyo
PnD/AMJ9vkIf4j2JsHpzaeZqjrqIeyfjhX7Yyvkb1O9Vmdp7XyGLmlLHlxWuSfyfYEbkD7ynLP6W
2blfTQDgYL0SL+SySKw+zQOhyvPn3cOZW17lttjFcHiJrIo35vFGyk/PWep8A/4TZaxkom+JWq7S
6Zpd4FLjkg4yofx244QxW/oPbbH709PCP75pwx4f/Hh/hr0+qfdir4lNo+w+L/x0/wCCnT1B8sv+
E8/TK/f7Wxnxmra2mGuFNp/H3Nb0rzJGLr4KiXYWQhExI4czLz/a9sNyb95jfv07ubdljPHxLxYl
/MeMpp8qfl07/W77tmwfqW1vtZkHDRZvI35EwkV+dfz6Re/P+FHPwx66xX8F6H6O7U3ytLGY6GkG
D2x1LtOMhSIzEZarJZKKAWHAxqtbiw+vtft33Xue90m8fmLmCzt68TrkuJPzwq1/5udINx+87yLt
cX0/L+w3dxQYGmO3j/LLNT/adVM/IP8A4UN/N3tiCuw3VOO2D8dNv1SzQrV7Vx8m8d+mnkJ06917
rSXGUdQq2/co8XTyKfo/uZuWvuzcg7M0c+8y3O6XIzSQ+FDX/mnHRiPk0jD5dQ1zL95bnzeFkg2a
K32y2YUrGviS/wDOSSqjHmsan59Uk787C372nujIb27N3rursHeGVdnyG5t5Z3I7izVSWYtoauyd
RUTRwIT6YkKxIOFUD3Pu3bZtuz2kVhtNhDbWKDtjiRUUfkoAr8zk9QJuW57jvF3Jf7rfzXN65y8j
s7H82JPngeXSP9rukPXvfuvdWC/If/shT+XN/wBQ/wAsf/fx433GvK3/AE8P3R+3bv8AtGPUkcz/
APTvvbH7Nx/7SV6IF7krqN+ve/de697917r3v3Xuve/de697917r3v3Xuv/Upob6/wDIK/8AQo99
mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Vjf8rOmoKz5Q7ho8ruDB7TxdX8X/AJa02S3Vuiqlods7ZoJ+gd8RVe4NxV0EFVPR4LDU
7NUVcqRSNHBGzBWIsYl97L+Ha+RG3O5DG3ttysJWC5YrHdxO1BipoDTPHqWPZWwm3TnkbZbFRcXG
238S6jRdUlrIq1OaCpFcHHQAx9E/GhY41/4dZ/llelEX/mdfYH4UD89UA+wQfvTe3BJP0O6/84U/
629Dj/gXPcX/AJTtr/5zP/1q6yf6CvjR/wB7Wf5ZX/o6uwP/ALVHvX/BTe3H/KDuv/OFP+tvXv8A
gXPcX/lP2v8A5zP/ANauvf6CvjR/3tZ/llf+jq7A/wDtUe/f8FN7cf8AKDuv/OFP+tvXv+Bc9xf+
U/a/+cz/APWrr3+gr40f97Wf5ZX/AKOrsD/7VHv3/BTe3H/KDuv/ADhT/rb17/gXPcX/AJT9r/5z
P/1q66/0FfGf/vax/LK/9HV2B/8Aao9+/wCCm9uP+UHdf+cKf9bevf8AAue4v/Kdtf8Azmf/AK1d
d/6CvjR/3tZ/llf+jq7A/wDtUe/f8FN7cf8AKDuv/OFP+tvXv+Bc9xf+U/a/+cz/APWrr3+gr40f
97Wf5ZX/AKOrsD/7VHv3/BTe3H/KDuv/ADhT/rb17/gXPcX/AJT9r/5zP/1q69/oK+NH/e1n+WV/
6OrsD/7VHv3/AAU3tx/yg7r/AM4U/wCtvXv+Bc9xf+U/a/8AnM//AFq69/oK+NH/AHtZ/llf+jq7
A/8AtUe/f8FN7cf8oO6/84U/629e/wCBc9xf+U/a/wDnM/8A1q69/oK+NH/e1n+WV/6OrsD/AO1R
79/wU3tx/wAoO6/84U/629e/4Fz3F/5T9r/5zP8A9auvf6CvjR/3tZ/llf8Ao6uwP/tUe/f8FN7c
f8oO6/8AOFP+tvXv+Bc9xf8AlP2v/nM//WroxfzB2/tPa/w5/l54XZXcXU/fG36Wj+U70/ZXSeey
W5evMtPP21iZquhxeXy2HwNdPWYeZzT1atTII50ZQWAuT/2k5u2vnnmP3H5k2aOZbCaSxVRKoV6x
wMjVALDiMZ4dEHuzyjunI/Lvt1y5vEkLX8Ud8xMTFkpJOjLQkKeBzjj1Wn7nPqDuve/de697917r
3v3Xuve/de697917r3v3Xuv/1aaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+690dj4If8zI7w/wDFHPnR/wDAv9ke
4O+8Z/06bff+a9t/1fTqb/u6/wDT2Ni/5oXP/VlutMD3zZ66Qde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691tdda/9ulP5YH/AGsfm3/7/wCp/ebf3Sv+SVzt/wA9Nv8A
8cfrCn72X/JU5K/55rj/AKuR9BZ7y86xG697917r3v3Xuve/de697917r3v3Xuve/de6/9amhvr/
AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3XvfuvdHZ+CH/Mye8P8AxRz50f8AwL/ZHuDvvGf9Om33/mvbf9X06m/7uv8A09jY
v+aFz/1ZbrS/982eukHR+Pih/Lz7P+VPW3YfeD9q/Hr45dBdY7q27sDcfd3yd7Ll642HWdj7rx1f
mcH11tZcTt/d26d17xqcHjJ6+SmocbMlLRRmaeSNSt/de6AX5KfH3J/GjsyXrbI9o9Hdyo2Bwu5c
Z2F8eOzcV2v1nnMTnYpZaNsfufGQUUtPkYDCyVVDW01JXUrgCWFbrf3XukL1D1bu/vDtbrTpfr+k
pa/ffbW/to9bbMoq2six9HV7p3vn6DbWBp6uvn/ZoqWbKZKJZJWuI0Jaxt7917oznb/wR7F2F392
L8dup99dc/K7eHUGxewN+dpZn4+T7wyO1Nk4/qCkztd2/BkMl2HtDr2rrh1xR7dqZ66rpKeooZac
K9PNNq0j3XuiP+/de697917r3v3Xuve/de697917r3v3XutrrrX/ALdKfywP+1h82/8A3/1P7zb+
6V/ySudv+em3/wCOP1hT97L/AJKnJX/PNcf9XI+gs95edYjde9+691737r3Xvfuvde9+691737r3
Xvfuvdf/16aG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+690dn4If8zJ7w/wDFHPnR/wDAv9ke4O+8Z/06bff+a9t/
1fTqb/u6/wDT2Ni/5oXP/VlutL/3zZ66QdWWfCX517B6S627H+J/ys6Io/k18KO6t4bf3/vLYOPz
02xu2er+0tt4iv21he7OhOxKeOoh272Bi9uZaejqKPI01XicxR6aapRELP7917q3vrf4ZdSfy/ov
mZ8yOi6/BfJnA4T+W9038yv5fu4+++rNvZbO7GwXyE+Q+3elsjvbtDp3OU+c2ZW9p9OU1PlqWCeS
CswTVE0ORij0skcfuvdDD8Xvkf2PvvPfyUPnnXYPq/Zfyi74+fO//hb3bv3aPSnUu1aHv/o3bG/f
jtn8PuDcWy8dsym2dS77wFVvWtw395sLQY/KCKCJWqPLFq9+691j+Gn8xP5WZr+Zr/NNp8hu/r/7
Pb3xk/mO5WgpIOh+iaGkGQ6A2Z2dP1jWVoouuqaavOKYWr1nkkjzcZK5JasfT3XugV+LPW2yv5mf
x6+FPaPee1dn5LJ9K/zLfklN8ytxbc2ZtPr2Ldfx73T0nQfL/MHcy7DxW2qWhwKY7pHd2LoUp0po
aCOqaKmEV19+6906dy9EdBdV9J/zHvmP0d0vs7aPUnzB+F/wIwXxL69agh3Ji+tt8fMjfdCe49q7
JyW5zlK3Gbg2FmPjtvGiSpSYVVNBNoWRVYj37r3Rj6/bM1V1T/MP+B3y5+RXxV7p7T+Mf8vbvDsG
P4w9NfBzaPXWN+OfdfR2ztrbqwe4Nk/J/b/XOwajNbo2TVlcfnft2q6XNtVVEbTT2Zz7r3TPuDcK
9ifzM/5Zv8rPP7e6qwvwV7N6Z/lzby7F6X230v1Ltv8Av7uLM9AbD7g3E+5ewMJsim7TyVTv3fdM
RkmjzCz1sVXJDyJCD7r3RYvml8o/il2/8VPl91x3z8sPiT332xiazamU+D+zfjn8D+wPjhunobeW
3+y8dQ7t6/o97v0d1vjH6lyHVs+QpKjG5rIZR2raOlmjkE6l5Pde61d/fuvdbXXWv/bpT+WB/wBr
D5t/+/8Aqf3m390r/klc7f8APTb/APHH6wp+9l/yVOSv+ea4/wCrkfQWe8vOsRuve/de697917r3
v3Xuve/de697917r3v3Xuv/Qpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3R2fgh/zMnvD/AMUc+dH/AMC/2R7g
77xn/Tpt9/5r23/V9Opv+7r/ANPY2L/mhc/9WW60v/fNnrpB0ef4ofzEfkb8N9t7o2P1bH0xunYG
8c5BujO7D7x+PvTHe+15Nz0tDDjKfcOOpe09lbnrMJlI6CmjiLUU9OkioutWIBHuvdLBf5r3zsPy
hyXy9q+5o8n25mdgf6H8xj8psXYFf1Pk+khSxUKdHVnSdRtluqZOn4aOBFj2+MQKCORBOqCoHm9+
690w9qfzMPlx293b0H3vuPeW08HuH4s5fBZr47bK696x6+646c6eq8Buil3pCNl9QbL27hthY9cn
umjStyLvRSTZKVR9y8ioir7r3QcdLfNr5C9A/JHcfys663PhKftvelR2W2+JNw7N2ruzZu98X3FD
l6bszbG7NhbhxWQ2pm9qbvpM5Uw1WPlpTB45AFC6VI917oR9k/zK/lT1ltn5dbJ6xz2wut9kfNmj
NB3XszYvVmwttbWp6N8fuLCT0/WeFx2Diouqo6vbe7cni5Rg1o/Jjq2WA+ki3uvdInd3zx+Te+Pi
J1Z8HNxb7pqr479Nb5q+wtibch27gqPcFDn56jd1bRw5DelLQxbozGFwNfv/ADc+Noqmpkp6GXKT
mJVuoX3XujH7y/nKfN7f2x+xtq7my/SVZuruLqzK9J9td703xt6Ox3yQ7L6vz2Iptv57au9e8cfs
em35nYs5hKOKmrKqWqNdVRxIZJ2ZVYe690UjsX5h/Ijs/ubrb5B7h7Er6DuLqDa/Te0et99bUpaH
aOZ2ni+gdt4HavVc+Ll2/T0CRZfbOJ21RgVhBqJ5ovJKzOzE+690YT5F/wA1b5bfKDrncvWXZMnR
GLw+/wCux2V7T3B1l8Yvj/1V2B23mMXkqfNU2W7I7C2F15gt37irnzVKlZOfu4kqaka5lck+/de6
rg9+691tdda/9ulP5YH/AGsPm3/7/wCp/ebf3Sv+SVzt/wA9Nv8A8cfrCn72X/JU5K/55rj/AKuR
9BZ7y86xG697917r3v3Xuve/de697917r3v3Xuve/de6/9Gmhvr/AMgr/wBCj32YPXG8cPzPXH3r
rfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdHZ+CH
/Mye8P8AxRz50f8AwL/ZHuDvvGf9Om33/mvbf9X06m/7uv8A09jYv+aFz/1ZbrS/982eukHXvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdbXXWv/bpT+WB/wBrD5t/+/8A
qf3m390r/klc7f8APTb/APHH6wp+9l/yVOSv+ea4/wCrkfQWe8vOsRuve/de697917r3v3Xuve/d
e697917r3v3Xuv/Spob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Q7/HLvjI/HLsl+xKDY+zOyaeu2R2D13uDYvY
MeXm2jufaPZu0spsrdmIzEeCyOJypgrcDmJ4/wBqoib1fX2Eud+T9v585cvOWd0uZorOZ42LRaQ4
MbhxTUGGSM1HDoWckc33/IvMdpzLtlvFLeQpIoWQMUIkUoa6SpwDjPHpWf6UvhH/AN6g/gB/yR8h
P/ty+4J/4FDkf/pot1/bB/1q6nT/AIKrnX/owbX/ALzN/wBbevf6UvhH/wB6g/gB/wAkfIT/AO3L
79/wKHI//TRbr+2D/rV17/gqudf+jBtf+8zf9buvf6UvhH/3qD+AH/JHyE/+3L79/wAChyP/ANNF
uv7YP+tXXv8Agqudf+jBtf8AvM3/AFu69/pS+Ef/AHqD+AH/ACR8hP8A7cvv3/Aocj/9NFuv7YP+
tXXv+Cq51/6MG1/7zN/1u69/pS+Ef/eoP4Af8kfIT/7cvv3/AAKHI/8A00W6/tg/61de/wCCq51/
6MG1/wC8zf8AW7r3+lL4R/8AeoP4Af8AJHyE/wDty+/f8ChyP/00W6/tg/61de/4KrnX/owbX/vM
3/W7r3+lL4R/96g/gB/yR8hP/ty+/f8AAocj/wDTRbr+2D/rV17/AIKrnX/owbX/ALzN/wBbuvf6
UvhH/wB6g/gB/wAkfIT/AO3L79/wKHI//TRbr+2D/rV17/gqudf+jBtf+8zf9buvf6UvhH/3qD+A
H/JHyE/+3L79/wAChyP/ANNFuv7YP+tXXv8Agqudf+jBtf8AvM3/AFu69/pS+Ef/AHqD+AH/ACR8
hP8A7cvv3/Aocj/9NFuv7YP+tXXv+Cq51/6MG1/7zN/1u69/pS+Ef/eoP4Af8kfIT/7cvv3/AAKH
I/8A00W6/tg/61de/wCCq51/6MG1/wC8zf8AW7pt7u+QWE7W2R091fsXoDp344dX9IU++4tldf8A
TEe8EwCVPY2fpdzboyFY289ybnyUlXWZel8txOFBkbgCwEse2/tfsvtjbbrbbNf3U63bozmYoSCg
IGnQqilGzXqKfcf3P3n3Mudrud4sbaBrRHVBCHAIcqTq1s3AqKUp59Fu9yX1GvXvfuvde9+69173
7r3Xvfuvde9+691737r3X//Tpob6/wDIK/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691//1KaG+v8AyCv/AEKPfZg9cbxw/M9cfeut9e9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3
Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvdf
/9Wmhvr/AMgr/wBCj32YPXG8cPzPXH3rrfXvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9
+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd
e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173
7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv
de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X//Wpob6/wDI
K/8AQo99mD1xvHD8z1x96631737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6917
37r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xv
fuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+6
91737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X
vfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+
691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//2aBGHfAEngAABE0yIY2T
pTBiwhzVISqmUf//2P/gABBKRklGAAECAQEsASwAAP/hFANFeGlmAABNTQAqAAAACAAHARIAAwAA
AAEAAQAAARoABQAAAAEAAABiARsABQAAAAEAAABqASgAAwAAAAEAAgAAATEAAgAAABwAAAByATIA
AgAAABQAAACOh2kABAAAAAEAAACkAAAA0AAtxsAAACcQAC3GwAAAJxBBZG9iZSBQaG90b3Nob3Ag
Q1MyIFdpbmRvd3MAMjAwNjowNDoyMCAxMjo0MzowMAAAAAADoAEAAwAAAAH//wAAoAIABAAAAAEA
AADUoAMABAAAAAEAAABxAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAR4BGwAFAAAAAQAA
ASYBKAADAAAAAQACAAACAQAEAAAAAQAAAS4CAgAEAAAAAQAAEs0AAAAAAAAASAAAAAEAAABIAAAA
Af/Y/+AAEEpGSUYAAQIAAEgASAAA/+0ADEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAM
CAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwM
DAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDAz/wAARCABVAKADASIAAhEBAxEB/90ABAAK/8QBPwAAAQUBAQEBAQEAAAAA
AAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYI
BQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkST
VGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3
x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJD
UxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaG
lqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDnnOduOp5PdLc7xP3pO+kfiUy33BX3O8T9
6W53ifvTJJIX3O8T96W53ifvTcalTfTdXWy2yp9ddv8ANWPY5rXf8W9wDX/2UtE0WO53ifvS3O8T
96ZJJC+53ifvS3O8T96ZSrrstsbXUx1lj9GsYC5x/qsZLnJJ1W3O8T96W53ifvSex9bzXY11djdH
MeC1w/rNfDkyStV9zvE/elud4n70ySSF9zvE/elud4n70ySSl9zvE/elud4n70ySSl9zvE/ek1zt
w1PI7pk7fpD4hJL/AP/Q5530j8SrNfTy6mu1+RRULQXMbY5wdAc6vsx35zFWP0j8SrOV/RcH/iXf
+fbVs5zO8UYS4OOfCZUJekYsuT9L/ZuNhEP1kpx4+GNgXw68cIfo/wB5l+z2f9zcX/Pd/wCkkd3S
KG9Nsy/tTHvYTGwyzT/B67X+o5ZiYlo5IHxTJ4OYlwcPMyjwzjKXoxy9yEfmx/1eP95fDNgHFfLi
VxMY+ufokfln/gup9WManL+sXT8e9ofU+0ucw6g+mx9zWuH5zd9bUujdX6t1G7Kr6jl25dOdh5Tr
qbXF1Yeyp+XVZTSf0dD6bqmej6Oz01nY+XbiZFWXjWBl+O8WVO0I3N/eH5zXfRerOR1fHZi5Temd
LrwcnLpfTbeLn3NbXaP1lmFjWMbXi+v9H6d3o1fo6U7NAmRPDxXGo/1JfvJwSAiBxcNSuX9ePZvW
9P6Uc2zotNV7c1mL9pqzX2tdW+z7O3qBpuxvSZ6VLml9fqV2eorlv1VNe/E+yZQLMc3ftk21jGNg
p+0+icXbvbjbv0Hqb/W9VVeu9YwKuqZR6diMszX41eOOqDIc9gD8evHufRiVtFLL66j6G/1/Z/o1
nZfUMDNa67O6TXkdTsqFb8032tY5zGimvIswWDZ63pMbu/WPT9T9J6ahBzkRI4qrX+93+b5WYjAC
QeG+n93t/edPE6b0jJ6njdCFWQzLy8Zl7M43NLG2PxjnbHYgp/mPbs/nfVVDofVqMfHyqbrrcAdR
qqYzqOOC63HLH+t9GtzLnY1/0Mn0Xep7GJ8Prz6OuY3WhQLHYtTKfQ9SA7ZjuwN5t9P2bt/rbfS/
4P8A4RVOnW4eJWa8zCGewta1o9Z9D2Fv59dlXqN9/wCeyyqxSCMzGQnxEGMT48d61xMfHjEomHCC
CR/gOm/p+S37Vn9dyLOo0YONVZTbTeLPtDLrfQxm0Zloe5mM251vrez1q01vTsB/TH9Wx22VUXYd
99WPY/e6q7HyMbEsb6rWV+tjury/0ft3oH7dJAxfsDP2MKPs/wCzPWsmDb9t+0fbv537X9q/Sep6
Xpf4P0Uh1yHtpHT2DpLMazE/ZxueSW3PZk33/btvq/an5FNT/V9HZsZ6fpJo94VQIo7D5eDtX764
+wbsg33+bi73+63cTpHTX9Ix+pZAuf8AqfUM26uuwM3nCuoopqa91dnpMfXe71FWyn9BxsPFzH4e
U/8AaVdlzKGZLR9nrrf9nbttfQ/7VbdZXbZ+kaxlTP0f8tJ/1inFODjdPbjYgwsrCrYb32vacx9N
9+Q+6ytvq7H43sp2Vfzn84q9HVcQ4VGHn9OZ1AYYe3FsF9lDmstJsfTf6DXfaavVd6lfvp2JAZiS
ZcVcWwOvAonAAIx4brWVfpO5j/VTe7Gw34eW45FLLLOsNsrbj1W2Vm5lYxCC+3Frca6rbH2V3f6N
ctU/1K2viJEwrr+pYGSK7eo9Iqzc+uptP2o321seK2iuh+TiUj9NYytu1/6xV6qpMbtaB4KXB7ly
47+v7GHmPbqPBX0ZJJJKZrqTt+kPiEydv0h8Qkp//9Hnj9I/Eqzlf0XB/wCJd/59tVY/SPxKs5X9
Fwf+Jd/59tWzl+fB/tD/AO6+dxcfyZv7g/8ASuNqq/0vr/7GqyD+zsfqBt2uByB9HYHaN9j/AKW5
UFG3+af/AFT+RSTgJxMTsVuOZjISD331o63i9Exek30dGwr3dSqdZa17GtDNrabIYW1nd/PrFxPq
V9Yurss6mKaMJmU991WPY5zSGvPqMZWxlb/Tr936P1Nis/X/AGfZPqv6kemanB86Dbtw9+7+yrf+
MH/muet4x65kdTpyK6A/E+yFgqb737rqfUa5zMvexnqvb+Z9nWdCcscY8HzTMrJ9WkP6rpSxxyGQ
n8sOHb0/M8oei9TZ1T9kHGcOoEwKARqCN3qCz+b9Hb7vVV/rP1L630zpeTnXOx7K8esuuZVYS9gI
5c19dbf+kun6F9YOl/WD66VZeC2yKumW1l9zQwucL6S304c7d7Tb9FeZZFQLsyy8n7W593rlx/SF
+5/qi387dv8Ap7lYhmy5JCIAhwgGQI3YJYMWMcR4p3Ko1+i+n/XP6rdW6z1fGuwzRVjVUem6y55a
C8vJbW1tbLH/AEVx9n1b6xV1lnRHVN+22NL6vfFb2AEm1lhH0fY78z1Fo/42qWXdZxRZ7g3CeWg6
gHe73NH7y6PLJ/56fVcky52FlbnHUn9GzkqHHmyY8cdjEiXD4GLLkwY8mSW4kDHi+rztn+L36wsY
4sdi3WsEmhlrhZ/4JWyv/OsWT0jofU+s5L8bCq99P8+632Nq1Ldt2hd6m5v81t9RaH1dqaz/ABm2
2M9rn5+e18aSNuU7a795u5rXLVyDc36qfXJ2NuZd+08kPdXo705xvWnb+Z9ndbv/AODTzzOWOh4S
ZCJia+XjWDlsUtY8QETISH73C8/9Yvqp1roeE/Jy2Msxo2m+hxc1rnaM9UPbXYzc7279np71uf4w
8fJy/rN07CxKzbddjFtdTeSd7v7LWNb7nvd7K1S+rTNv1B+s9bjOE2qw0A6sFno7n+l/K9T0Xf11
2FwYf8YmNuiR0m0snx9evdt/sqOeeYyDioyxcW20uIMkMGM4zw2I5K33FPHZX1A+smNinJ2U5G0b
nUUvLrYHO1r62Msd/Irf/UWd0T6v9T665/2BjfSrj1L7Xba2kjc1sgPe9+39xn9dXPqF9t/57Pe9
1hyLDlDqId9KGl39JH5uzI9LatHq2wfUXrjcaG1nrGQ2/ZEbPtYbD/3Wen6Lf+L/AJCkPM5YngPC
ZS4TGXbjYxy2KXqHEIxMhKPfhaGZ9SetYdTL7LMV+O+yuo3stOxpte3HY9++tn6P1bGb9izOsdJz
OjZ5wMva6/Y2xpqJLXNeXNZs3trd/OMfX9FauBTWz/FX1tlMN/WpG3T3bsKOFs9Qxh1/qn1R6w0S
MsRlGPaDS39oemf+u05NaI5nJGRE6IiZRJA6xjxBB5XHKIMLBIEhZ8dXleudEyuh5VWJmW0vuuZ6
obS5zobOwF/qMq+m7dtVBv0h8QtL62Zx6h9a+oXAk147xiVT2FPst/8AZn11mt+kPiFZwylLHGUv
mIauaMY5JRjsH//S54/SPxKs5X9Fwf8AiXf+fbVWP0j8Srr8d2RiYhrsqGytzXh9rGEH1LHfRe5r
vouWxzE4wlglIiMRkNyloP5jO42GJkMoiLJhsP8Aa42imcNzS09wR96t/s67/SUf9v1f+TS/Z13+
ko/7fq/8mj965f8AzuP/AB4o+75v83L7GXV+tdQ61Xh0ZtdLKunsdXT6QcC5rxWx3q+o+z82lv0F
fxvrx17GxK8O+nF6lVSAKX5TCbBA2s3va7bZtb+fs9X9+xZ37Ou/0lH/AG/V/wCTS/Z1/wDpKP8A
t+r/AMmojLkzER9zHQNj1x6sw+9CRlwy1FH09kt/1k67k9Xq6259dObjsFdIqZFYr926l1b3PdYx
/qP3bnqz1X66db6pg5GDZi4mO3NZ6eVfSx3qPHHtNj3bfb+/6qo/s67/AElH/b9X/k0dnRMh2HZk
+rX+jkhrXB4Ib9L9KwljVHkzchDgMssBrHHGpcXql8o9C/HHnZGQjCR0MzpWkfm+ZD13rXUPrBlN
yeoMqqfXUaWigOA2kl8u9V9vu1Vmz649Xt6pgdS9LF9fptVlWOwCza5trW1vdb+l3O2tb7djlD6u
UY+R1zFryaxdSPVtdU76LvSqtvYx/wDI9Stm9APWevdXqrxszLOQ3IsrLK3tYGtscdlfplrN1Ffv
/wAEp5Y4WMfBpEXv8omxxyT4Tk46MjwgAbyith9WzsPrB65Wyo5rrrsjY4O9LdeLG2N2h4s2N9d+
z9Ij9O+s3XOm9SzOp4pq9TqFhtysZzXGlziSQWt3i1np7vY71f8AjN6v5v1bqqrz2Y9fUGXdLqsu
tysrHFeHe2k/rDcSyN7HbP0mN+ku9f0/+uIVHS+ib+l4eVdmDO6xVXbTZU2o0VG5zqaW2ss/T2+9
n6Xa5NJ5eQur04Nv0R6lwjzMTVga8e/UtXrn1m6z13C/ZlrKcHp0y7HxWlu4j3N9RznH2Ns/SbGM
Z70uo/WbrfUOr43WHGrFzMJhZQ+hrtsEku9Rlz7d+/dse1WumVdD/YPWLeoU5D8rBfRXZbS6v2l9
z6WfY/Vb7N+zbler/OV/zWxSwPq/VdjYJyKuo2XdTa19d+Hji3Gx2ve6qt2XYQfU+j617GWVelSm
gcvG7jXCa/vcUeJd/SZVUh6hdD9HhZZX+MD6y3021004mHdkDbdl0sd6pA9rXM9R7mte1v0fU9ZT
+pNX1groyqei34VtbzGR0zOc79JLWg5Fba/d72fobH/Qs/wqo04HTsXGy8jrDsgnEzv2cacL05Ng
a+19psyf8H+hesiymq4yWyATsJ+kB+bx+cnezjlGUcY7akWFpzZYSjLIdNfSDq+g9fdlVfVSzo3U
mYGF1PquTVRg4eGS1kOtoiy3cN3s22PvvbX6ez0/8Ii9HPWPqf0LMPW7MUYOI17unsYXOtfc8vs9
AOIq9llv81Xs9b9LZ+k9Ji83biUNJO0Eu0JOshIYlIcHRJHE6x8Ez7nLh4TIUTxS0/6K/wC+Q4uI
RNgcI1XxmvFQNh3WO9z3HUlx9zz/AJyM36Q+ITJ2/SHxCugUAOzRJsk9y//T5530j8SmTu+kfiUy
33AVASgJJI2VKgJQEkkrKlQFIW2trdU17hW7VzASGk/ymqKSBAO+vXXuEgkbGumifAzr+nZ1Gfjt
a+3HcSGP1a5rmuqtqf8AybKrHsStyel1tYel42Tj5DHtsY7IuZZXXsd6ja6WV1Vvtb9H35D0BJNl
jBlxa3VHxC+OWUY8OhF2L/RPg3eodR6bm2ZOT9mzGZmWXPfW7KBxWWP1fbTU2v17G7tz/Qtf6f8A
YT/tZn7Q6Nl+i7b0irHqe2RNhosfc51f7u/f+eqKSYMEAK1XS5iZ7dPwbuD1LFqo6niZlFz8bqr2
WE0PY22t1Vr8qofpmuqexzrNlqTep4duLi1dRpzH3YNXoVOxMkU12Vhzra68muyuzY6ve9nq0e/Y
qSSRwQPfofs9KRzMx269O/qSnLYel2dPbU5ptzm5rXbtwa1tVmP6LnO/SPf+l/nUJJJPjARuuurH
OZnV9BSkkkk5YpO36Q+ITJ2/SHxCSn//1OecBuOvc9v9qUDxP3f7VxaS33Be0geJ+7/alA8T93+1
cWkkp7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJKe0geJ+7/AGpQPE/d/tXFpJKe0geJ
+7/alA8T93+1cWkkp7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJKe0geJ+7/AGpQPE/d
/tXFpJKe0geJ+7/ak0DcNe47f7VxaSSn/9n/7Ro8UGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAcc
AgAAAgACADhCSU0EJQAAAAAAEEYM8okmuFbasJwBobCnkHc4QklNA+0AAAAAABABLAAAAAEAAQEs
AAAAAQABOEJJTQQmAAAAAAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAAB4OEJJTQQZAAAA
AAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB
AAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA
MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP//////////
//////////////////8D6AAAAAD/////////////////////////////A+gAAAAA////////////
/////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAAC
AAM4QklNBAIAAAAAAAoAAAAAAAAAAAAAOEJJTQQwAAAAAAAFAQEBAQEAOEJJTQQtAAAAAAAGAAEA
AAAKOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAA
A00AAAAGAAAAAAAAAAAAAABxAAAA1AAAAAwAbwB0AGMAXwBsAG8AZwBvAF8AbgBlAHcAAAABAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAANQAAABxAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA
AAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj
dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAABxAAAA
AFJnaHRsb25nAAAA1AAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA
B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp
Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt
ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm
dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAcQAAAABSZ2h0bG9uZwAAANQAAAADdXJsVEVYVAAAAAEA
AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA
AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln
bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F
U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD
b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA
AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklNBCgA
AAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAABI4QklNBAwAAAAA
EukAAAABAAAAoAAAAFUAAAHgAACfYAAAEs0AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRv
YmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgR
DAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4U
EQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAFUAoAMBIgAC
EQEDEQH/3QAEAAr/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAA
AAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFC
IyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE
1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyEx
EgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl
4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhED
EQA/AOec5246nk90tzvE/ek76R+JTLfcFfc7xP3pbneJ+9Mkkhfc7xP3pbneJ+9NxqVN9N1dbLbK
n112/wA1Y9jmtd/xb3ANf/ZS0TRY7neJ+9Lc7xP3pkkkL7neJ+9Lc7xP3plKuuy2xtdTHWWP0axg
LnH+qxkucknVbc7xP3pbneJ+9J7H1vNdjXV2N0cx4LXD+s18OTJK1X3O8T96W53ifvTJJIX3O8T9
6W53ifvTJJKX3O8T96W53ifvTJJKX3O8T96TXO3DU8jumTt+kPiEkv8A/9DnnfSPxKs19PLqa7X5
FFQtBcxtjnB0Bzq+zHfnMVY/SPxKs5X9Fwf+Jd/59tWznM7xRhLg458JlQl6Riy5P0v9m42EQ/WS
nHj4Y2BfDrxwh+j/AHmX7PZ/3Nxf893/AKSR3dIob02zL+1Me9hMbDLNP8Hrtf6jlmJiWjkgfFMn
g5iXBw8zKPDOMpejHL3IR+bH/V4/3l8M2AcV8uJXExj65+iR+Wf+C6n1Yxqcv6xdPx72h9T7S5zD
qD6bH3Na4fnN31tS6N1fq3UbsqvqOXbl052HlOuptcXVh7Kn5dVlNJ/R0PpuqZ6Po7PTWdj5duJk
VZeNYGX47xZU7Qjc394fnNd9F6s5HV8dmLlN6Z0uvBycul9Nt4ufc1tdo/WWYWNYxteL6/0fp3ej
V+jpTs0CZE8PFcaj/Ul+8nBICIHFw1K5f149m9b0/pRzbOi01XtzWYv2mrNfa11b7Ps7eoGm7G9J
npUuaX1+pXZ6iuW/VU178T7JlAsxzd+2TbWMY2Cn7T6Jxdu9uNu/Qepv9b1VV671jAq6plHp2Iyz
NfjV446oMhz2APx68e59GJW0UsvrqPob/X9n+jWdl9QwM1rrs7pNeR1OyoVvzTfa1jnMaKa8izBY
Nnrekxu79Y9P1P0npqEHOREjiqtf73f5vlZiMAJB4b6f3e39508TpvSMnqeN0IVZDMvLxmXszjc0
sbY/GOdsdiCn+Y9uz+d9VUOh9Wox8fKpuutwB1GqpjOo44Lrccsf630a3MudjX/QyfRd6nsYnw+v
Po65jdaFAsdi1Mp9D1IDtmO7A3m30/Zu3+tt9L/g/wDhFU6dbh4lZrzMIZ7C1rWj1n0PYW/n12Ve
o33/AJ7LKrFIIzMZCfEQYxPjx3rXEx8eMSiYcIIJH+A6b+n5LftWf13Is6jRg41VlNtN4s+0Mut9
DGbRmWh7mYzbnW+t7PWrTW9OwH9Mf1bHbZVRdh331Y9j97qrsfIxsSxvqtZX62O6vL/R+3egft0k
DF+wM/Ywo+z/ALM9ayYNv237R9u/nftf2r9J6npel/g/RSHXIe2kdPYOksxrMT9nG55Jbc9mTff9
u2+r9qfkU1P9X0dmxnp+kmj3hVAijsPl4O1fvrj7BuyDff5uLvf7rdxOkdNf0jH6lkC5/wCp9Qzb
q67AzecK6iimpr3V2ekx9d7vUVbKf0HGw8XMfh5T/wBpV2XMoZktH2eut/2du219D/tVt1ldtn6R
rGVM/R/y0n/WKcU4ON09uNiDCysKthvfa9pzH0335D7rK2+rsfjeynZV/Ofzir0dVxDhUYef05nU
Bhh7cWwX2UOay0mx9N/oNd9pq9V3qV++nYkBmJJlxVxbA68CicAAjHhutZV+k7mP9VN7sbDfh5bj
kUsss6w2ytuPVbZWbmVjEIL7cWtxrqtsfZXd/o1y1T/Ura+IkTCuv6lgZIrt6j0irNz66m0/ajfb
Wx4raK6H5OJSP01jK27X/rFXqqkxu1oHgpcHuXLjv6/sYeY9uo8FfRkkkkpmupO36Q+ITJ2/SHxC
Sn//0eeP0j8SrOV/RcH/AIl3/n21Vj9I/Eqzlf0XB/4l3/n21bOX58H+0P8A7r53Fx/Jm/uD/wBK
42qr/S+v/sarIP7Ox+oG3a4HIH0dgdo32P8ApblQUbf5p/8AVP5FJOAnExOxW45mMhIPffWjreL0
TF6TfR0bCvd1Kp1lrXsa0M2tpshhbWd38+sXE+pX1i6uyzqYpowmZT33VY9jnNIa8+oxlbGVv9Ov
3fo/U2Kz9f8AZ9k+q/qR6ZqcHzoNu3D37v7Kt/4wf+a563jHrmR1OnIroD8T7IWCpvvfuup9RrnM
y97Geq9v5n2dZ0JyxxjwfNMysn1aQ/qulLHHIZCfyw4dvT8zyh6L1NnVP2QcZw6gTAoBGoI3eoLP
5v0dvu9VX+s/UvrfTOl5Odc7Hsrx6y65lVhL2AjlzX11t/6S6foX1g6X9YPrpVl4LbIq6ZbWX3ND
C5wvpLfThzt3tNv0V5lkVAuzLLyftbn3euXH9IX7n+qLfzt2/wCnuViGbLkkIgCHCAZAjdglgxYx
xHincqjX6L6f9c/qt1brPV8a7DNFWNVR6brLnloLy8ltbW1ssf8ARXH2fVvrFXWWdEdU37bY0vq9
8VvYASbWWEfR9jvzPUWj/japZd1nFFnuDcJ5aDqAd7vc0fvLo8sn/np9VyTLnYWVucdSf0bOSoce
bJjxx2MSJcPgYsuTBjyZJbiQMeL6vO2f4vfrCxjix2LdawSaGWuFn/glbK/86xZPSOh9T6zkvxsK
r30/z7rfY2rUt23aF3qbm/zW31FofV2prP8AGbbYz2ufn57XxpI25Ttrv3m7mtctXINzfqp9cnY2
5l37TyQ91ejvTnG9adv5n2d1u/8A4NPPM5Y6HhJkImJr5eNYOWxS1jxARMhIfvcLz/1i+qnWuh4T
8nLYyzGjab6HFzWudoz1Q9tdjNzvbv2envW5/jDx8nL+s3TsLErNt12MW11N5J3u/stY1vue93sr
VL6tM2/UH6z1uM4TarDQDqwWejuf6X8r1PRd/XXYXBh/xiY26JHSbSyfH16923+yo555jIOKjLFx
bbS4gyQwYzjPDYjkrfcU8dlfUD6yY2KcnZTkbRudRS8utgc7WvrYyx38it/9RZ3RPq/1Prrn/YGN
9KuPUvtdtraSNzWyA9737f3Gf11c+oX23/ns973WHIsOUOoh30oaXf0kfm7Mj0tq0erbB9ReuNxo
bWesZDb9kRs+1hsP/dZ6fot/4v8AkKQ8zlieA8JlLhMZduNjHLYpeocQjEyEo9+FoZn1J61h1Mvs
sxX477K6jey07Gm17cdj3762fo/VsZv2LM6x0nM6NnnAy9rr9jbGmoktc15c1mze2t384x9f0Vq4
FNbP8VfW2Uw39akbdPduwo4Wz1DGHX+qfVHrDRIyxGUY9oNLf2h6Z/67Tk1ojmckZEToiJlEkDrG
PEEHlccogwsEgSFnx1eV650TK6HlVYmZbS+65nqhtLnOhs7AX+oyr6bt21UG/SHxC0vrZnHqH1r6
hcCTXjvGJVPYU+y3/wBmfXWa36Q+IVnDKUscZS+Yhq5oxjklGOwf/9Lnj9I/Eqzlf0XB/wCJd/59
tVY/SPxKuvx3ZGJiGuyobK3NeH2sYQfUsd9F7mu+i5bHMTjCWCUiIxGQ3KWg/mM7jYYmQyiIsmGw
/wBrjaKZw3NLT3BH3q3+zrv9JR/2/V/5NL9nXf6Sj/t+r/yaP3rl/wDO4/8AHij7vm/zcvsZdX61
1DrVeHRm10sq6ex1dPpBwLmvFbHer6j7PzaW/QV/G+vHXsbErw76cXqVVIApflMJsEDaze9rttm1
v5+z1f37Fnfs67/SUf8Ab9X/AJNL9nX/AOko/wC36v8AyaiMuTMRH3MdA2PXHqzD70JGXDLUUfT2
S3/WTruT1errbn105uOwV0ipkViv3bqXVvc91jH+o/duerPVfrp1vqmDkYNmLiY7c1np5V9LHeo8
ce02Pdt9v7/qqj+zrv8ASUf9v1f+TR2dEyHYdmT6tf6OSGtcHghv0v0rCWNUeTNyEOAyywGsccal
xeqXyj0L8cedkZCMJHQzOlaR+b5kPXetdQ+sGU3J6gyqp9dRpaKA4DaSXy71X2+7VWbPrj1e3qmB
1L0sX1+m1WVY7ALNrm2tbW91v6Xc7a1vt2OUPq5Rj5HXMWvJrF1I9W11Tvou9Kq29jH/AMj1K2b0
A9Z691eqvGzMs5Dciyssre1ga2xx2V+mWs3UV+//AASnljhYx8GkRe/yibHHJPhOTjoyPCABvKK2
H1bOw+sHrlbKjmuuuyNjg70t14sbY3aHizY3137P0iP076zdc6b1LM6nimr1OoWG3KxnNcaXOJJB
a3eLWenu9jvV/wCM3q/m/VuqqvPZj19QZd0uqy63KyscV4d7aT+sNxLI3sds/SY36S71/T/64hUd
L6Jv6Xh5V2YM7rFVdtNlTajRUbnOppbayz9Pb72fpdrk0nl5C6vTg2/RHqXCPMxNWBrx79S1eufW
brPXcL9mWspwenTLsfFaW7iPc31HOcfY2z9JsYxnvS6j9Zut9Q6vjdYcasXMwmFlD6Gu2wSS71GX
Pt3792x7Va6ZV0P9g9Yt6hTkPysF9FdltLq/aX3PpZ9j9Vvs37NuV6v85X/NbFLA+r9V2NgnIq6j
Zd1NrX134eOLcbHa97qq3ZdhB9T6PrXsZZV6VKaBy8buNcJr+9xR4l39JlVSHqF0P0eFllf4wPrL
fTbXTTiYd2QNt2XSx3qkD2tcz1Hua17W/R9T1lP6k1fWCujKp6LfhW1vMZHTM5zv0ktaDkVtr93v
Z+hsf9Cz/CqjTgdOxcbLyOsOyCcTO/ZxpwvTk2Br7X2mzJ/wf6F6yLKarjJbIBOwn6QH5vH5yd7O
OUZRxjtqRYWnNlhKMsh019IOr6D192VV9VLOjdSZgYXU+q5NVGDh4ZLWQ62iLLdw3ezbY++9tfp7
PT/wiL0c9Y+p/Qsw9bsxRg4jXu6exhc619zy+z0A4ir2WW/zVez1v0tn6T0mLzduJQ0k7QS7Qk6y
EhiUhwdEkcTrHwTPucuHhMhRPFLT/or/AL5Di4hE2BwjVfGa8VA2HdY73PcdSXH3PP8AnIzfpD4h
Mnb9IfEK6BQA7NEmyT3L/9PnnfSPxKZO76R+JTLfcBUBKAkkjZUqAlASSSsqVAUhba2t1TXuFbtX
MBIaT/KaopIEA769de4SCRsa6aJ8DOv6dnUZ+O1r7cdxIY/Vrmua6q2p/wDJsqsexK3J6XW1h6Xj
ZOPkMe2xjsi5lldex3qNrpZXVW+1v0ffkPQEk2WMGXFrdUfEL45ZRjw6EXYv9E+Dd6h1HpubZk5P
2bMZmZZc99bsoHFZY/V9tNTa/Xsbu3P9C1/p/wBhP+1mftDo2X6LtvSKsep7ZE2Gix9znV/u79/5
6opJgwQArVdLmJnt0/Bu4PUsWqjqeJmUXPxuqvZYTQ9jba3VWvyqh+ma6p7HOs2WpN6nh24uLV1G
nMfdg1ehU7EyRTXZWHOtrrya7K7Njq972erR79ipJJHBA9+h+z0pHMzHbr07+pKcth6XZ09tTmm3
Obmtdu3BrW1WY/ouc79I9/6X+dQkkk+MBG666sc5mdX0FKSSSTlik7fpD4hMnb9IfEJKf//U55wG
469z2/2pQPE/d/tXFpLfcF7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJKe0geJ+7/alA
8T93+1cWkkp7SB4n7v8AalA8T93+1cWkkp7SB4n7v9qUDxP3f7VxaSSntIHifu/2pQPE/d/tXFpJ
Ke0geJ+7/alA8T93+1cWkkp7SB4n7v8AalA8T93+1cWkkp7SB4n7v9qTQNw17jt/tXFpJKf/2QA4
QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEA
ZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwACAAQwBTADIAAAABADhCSU0PoAAAAAAA+G1hbmlJ
UkZSAAAA7DhCSU1BbkRzAAAAzAAAABAAAAABAAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAA
AAAAAEZySW5WbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAEAAAAARnJJRGxvbmcwj+N7AAAA
AEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAAbnVsbAAAAAQAAAAARnNJRGxvbmcAAAAAAAAAAEFG
cm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFsb25nMI/jewAAAABMQ250bG9uZwAAAAAAADhCSU1S
b2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAcbWZyaQAAAAIAAAAQAAAAAQAAAAAAAAABAAAAADhC
SU0EBgAAAAAABwAGAAAAAQEA/+E6eGh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFj
a2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0
YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLjEtMTExIj4KICAgPHJkZjpS
REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMj
Ij4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6
eGFwTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iCiAgICAgICAgICAgIHhtbG5z
OnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIj4K
ICAgICAgICAgPHhhcE1NOkRvY3VtZW50SUQ+dXVpZDo1N0E4RTc0OEE1RDBEQTExOUM3QzgyMUIy
NDFDQTQzQjwveGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVp
ZDo1OEE4RTc0OEE1RDBEQTExOUM3QzgyMUIyNDFDQTQzQjwveGFwTU06SW5zdGFuY2VJRD4KICAg
ICAgICAgPHhhcE1NOkRlcml2ZWRGcm9tIHJkZjpwYXJzZVR5cGU9IlJlc291cmNlIj4KICAgICAg
ICAgICAgPHN0UmVmOmluc3RhbmNlSUQ+dXVpZDoyNEFDNTFGMUEwRDBEQTExOUM3QzgyMUIyNDFD
QTQzQjwvc3RSZWY6aW5zdGFuY2VJRD4KICAgICAgICAgICAgPHN0UmVmOmRvY3VtZW50SUQ+YWRv
YmU6ZG9jaWQ6cGhvdG9zaG9wOjk1ZTc3MDIwLThjZTYtMTFkOS1iYjI5LWUyYjM5MzI0MjA0NDwv
c3RSZWY6ZG9jdW1lbnRJRD4KICAgICAgICAgPC94YXBNTTpEZXJpdmVkRnJvbT4KICAgICAgPC9y
ZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAg
ICAgICAgIHhtbG5zOnRpZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgICAg
ICAgPHRpZmY6T3JpZW50YXRpb24+MTwvdGlmZjpPcmllbnRhdGlvbj4KICAgICAgICAgPHRpZmY6
WFJlc29sdXRpb24+MzAwMDAwMC8xMDAwMDwvdGlmZjpYUmVzb2x1dGlvbj4KICAgICAgICAgPHRp
ZmY6WVJlc29sdXRpb24+MzAwMDAwMC8xMDAwMDwvdGlmZjpZUmVzb2x1dGlvbj4KICAgICAgICAg
PHRpZmY6UmVzb2x1dGlvblVuaXQ+MjwvdGlmZjpSZXNvbHV0aW9uVW5pdD4KICAgICAgICAgPHRp
ZmY6TmF0aXZlRGlnZXN0PjI1NiwyNTcsMjU4LDI1OSwyNjIsMjc0LDI3NywyODQsNTMwLDUzMSwy
ODIsMjgzLDI5NiwzMDEsMzE4LDMxOSw1MjksNTMyLDMwNiwyNzAsMjcxLDI3MiwzMDUsMzE1LDMz
NDMyO0JFNzhDMUVFM0QxQUM1OEFBQUJBMjIwNjVBQTQxM0ExPC90aWZmOk5hdGl2ZURpZ2VzdD4K
ICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0
PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+
CiAgICAgICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDA2LTA0LTIwVDEyOjQzLTA3OjAwPC94YXA6TW9k
aWZ5RGF0ZT4KICAgICAgICAgPHhhcDpDcmVhdG9yVG9vbD5BZG9iZSBQaG90b3Nob3AgQ1MyIFdp
bmRvd3M8L3hhcDpDcmVhdG9yVG9vbD4KICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDYtMDQt
MjBUMTI6NDMtMDc6MDA8L3hhcDpDcmVhdGVEYXRlPgogICAgICAgICA8eGFwOk1ldGFkYXRhRGF0
ZT4yMDA2LTA0LTIwVDEyOjQzLTA3OjAwPC94YXA6TWV0YWRhdGFEYXRlPgogICAgICA8L3JkZjpE
ZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAg
ICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8
ZXhpZjpDb2xvclNwYWNlPi0xPC9leGlmOkNvbG9yU3BhY2U+CiAgICAgICAgIDxleGlmOlBpeGVs
WERpbWVuc2lvbj4yMTI8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhl
bFlEaW1lbnNpb24+MTEzPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6TmF0
aXZlRGlnZXN0PjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3NTEw
LDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2LDM3
Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3Mzg2
LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1LDQx
NzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQxOTkx
LDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwxMCwx
MSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDsyRDhDNUQ0
MkY1QjFFRDAyN0RBOTMzQ0QxMzFGQTJBNjwvZXhpZjpOYXRpdmVEaWdlc3Q+CiAgICAgIDwvcmRm
OkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAg
ICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAg
ICA8ZGM6Zm9ybWF0PmltYWdlL2pwZWc8L2RjOmZvcm1hdD4KICAgICAgPC9yZGY6RGVzY3JpcHRp
b24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5z
OnBob3Rvc2hvcD0iaHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyI+CiAgICAgICAg
IDxwaG90b3Nob3A6Q29sb3JNb2RlPjM8L3Bob3Rvc2hvcDpDb2xvck1vZGU+CiAgICAgICAgIDxw
aG90b3Nob3A6SGlzdG9yeS8+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+
CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4A
DkFkb2JlAGRAAAAAAf/bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYFBQUFBQUGBgcH
CAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQoJCg0PDg4ODg8PDAwMDAwPDwwM
DAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAcQDUAwERAAIRAQMRAf/dAAQA
G//EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAAAQACAwQF
BgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPBUtHhMxZi
8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE1OT0ZXWF
laW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZqbnJ2en5
KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEyobHwFMHR
4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp0+PzhJSk
tMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+DlJWWl5
iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A8f3FxcfWJ/38n94/7R8T759CxiKf
n2Ujaj9ZuP8Af8n/AAR/rh4Qx4j3u+s3H+/5P+CP9ceELxHvd9ZuP9/yf8Ef648IXiPe76zcf7/k
/wCCP9ceELxHvd9ZuP8Af8n/AAR/rjwheI97vrNx/v8Ak/4I/wBceELxHvd9ZuP9/wAn/BH+uPCF
4j3u+s3H+/5P+CP9ceELxHvd9ZuP9/yf8Ef648IXiPe76zcf7/k/4I/1x4QvEe931m4/3/J/wR/r
jwheI97vrNx/v+T/AII/1x4QvEe931m4/wB/yf8ABH+uPCF4j3u+s3H+/wCT/gj/AFx4QvEe931m
4/3/ACf8Ef648IXiPe76zcf7/k/4I/1x4QvEe931m4/3/J/wR/rjwheI97vrNx/v+T/gj/XHhC8R
73fWbj/f8n/BH+uPCF4j3u+s3H+/5P8Agj/XHhC8R73fWbj/AH/J/wAEf648IXiPe76zcf7/AJP+
CP8AXHhC8R73fWbj/f8AJ/wR/rjwheI97vrNx/v+T/gj/XHhC8R73fWbj/f8n/BH+uPCF4j3oz6x
cfo/+/k/3p/mP8nzyPCOL4M+I8Pxf//Q8c3P+9E//GRv1nPoaPJ+e5cyo5JDsVdirsVdirsVdirs
VdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdiqM/6V/wD0cf8AGmQ/i+DP+H4v/9Hxzc/7
0T/8ZG/Wc+ho8n57lzKjkkOxV2KuxV2KvWvy0/KHVvzFsvMPmG41/R/I3kXygIT5o89eYZ2gsbZ7
huMNvGI1eSaeTfjGi79yKrXU9o9rY9GYx4TOcuUY89uvkPN2vZ3ZM9YJS4hCEecpcvd5nyTbzj+S
Umi+Srv8yfI/n/y7+a/kbSLyGw8y6poDXEdzpU9weMBvbO6iiljjlb4UkoQTtmNpO3Y5sow5ISxz
O4Bqpe4jr5OTq+wpYsRzY5xyQGxq7HvB6ebwwOpAII3zfWHREFdUeONodUeONq6o8Rjaaeh/ll+W
mv8A5q+ZJfLmg3Nhpq2GnXWs69ruqzG3sNN02yUNcXd1KquVjTkASFO5GYPaPaGPRY+OdmyAAOZJ
5AOd2f2fk1uTghQoEknkAOZLJfOP5YeStC8uap5i8rfn35I8+SaO0S3fl20a9stSmEs8cANnDdW6
LccDJzfi2yBm3CnMDSdszzZBCeGcL67Ecr3o7frc7V9jQw4zOGaE66bg862sb/qeKhlIBqN83gLo
yF1R44bQ6o8cbVrkviMbTTdR4jG0U6o8Rja03hV2KuxV2KuxV2Koz/pX/wDRx/xpkP4vgz/h+L//
0vHNz/vRP/xkb9Zz6GjyfnuXMsw8i+UrXzffavb32tfoGy0XSbjVry/+rNdUitmjDj01dG+y5O1T
tSm+cZ7ce1mb2d0+nyYNP+ZyajPDBGHGMXqyCRj6zGQ5xEd6G9mQp6z2P9mcXbufPDNn/L48GGea
U+A5PTjMRL0iUTyle1nagDbIf8I/lf8A+Xf/APDfvf8AmvOf/wBFvtf/ANED/r8w/wDEu8/0Mey/
/Ra/69M3/FO/wj+V/wD5d/8A8N+9/wCa8f8ARb7X/wDRA/6/MP8AxK/6GPZf/otf9emb/insn5f/
AJf/AJP3mgarNLrlv5raNmF5qs6y6c1tGFBHGGRwygbnma16dqZ477fe3/txpu0sEI6aeiBA4ccT
HUDLK+uSMSJd3AKIG9bgvqfsV7E+x+o0GaUtRHVkE8WSQlgOMV0hIgx7+M3fK9qfJt7HbxXl3FZy
me0jmkW1nYULxhiEYj3FDn1bop5cmDHLNHhyGIMh3SIHEPgdn5r1cMcM044jxQEiInvjex+IfQ/m
YyR/84O+VobcmGHVfzmvH1PgKes8Gi8YuZ78RWg6Zy2X19ryvpjH+6epxejsiNdch/3Kj/zjdAYP
y9/5y0tDV7GT8pb28ltyPgNxaXMT28h90LMRke3sYxZNPIc/EH3M+wchy49RE8uA/e91/Nb80NG/
LD8/fLv5M2f5Pfl7qX5WXNv5Zg1vSJPL1ot9PHq1pbPdSrfqomWYNKWR67ELWuajRY8uo00s/i5B
kHFR4jW11tyrydtrMmLT6mODwoGB4bHCL3q9+dswu/yauvyf8t+fdS/KHyF5T8/ec5vzJ1jy7pep
+e7vSVt9G0GwjV4Y7aLWbq2hluHMvF5AWYr1UDIy7Zlq5QjmnKMRAEiF+qR7+EXXkzj2NHSRnLDC
MpGZAM69MR3cRq/NH+Xfy58n65+Y35B+Y/PHkHyTpfnfzFovnIfmZ+XWhXGn6hokl3olm8+mX/1X
T7m5t0MyHlIgbiWH2QQchPtTPjwZccMkzEGPDI2JAE+oWQD7mUOy8GTNiyThASIlxRFGJIHpNAke
94F+WX5jwf8AOQ/lH8+/LHnj8tPI2kHyP+Wetee/Jev+WtDt9IvNOu9EMBS2jkt6FoZRKAysTsor
XNhmjk0GTDkhkmeKYjISkZAiV779XX4ZY9djzY544DhgZAxiIkGNbbdHz5+Tn5t3n5T+ZbjzH+gL
bzboHmDRr3y3528p3btFFqej6iqrdWxlQEoW4KQ1DuNwRXOj7V0X57AADwyiRIHukORed7L1v5HO
SRxAgxI74nmHofmT8jPy881+VdR/NT/nHbzPc6v5Z0me2Xzv+XWvKI9f8sreSiKOZ2Qlbu1DmnqJ
UqOpajldRo+08mnyeDqo1I/TIfTKvuP47nb6vs3HqMfjaWVxH1RP1Rv7w9g/M/8ANLyz+Sf51D8h
PLv5MeRdc/LfyjPpWi+aJdZ0eK81jWmure3ku7uXUHYyxS8pmMRQ0QgGlPhGBpsebW4PzMssxM2R
UiIx50BHlXf3udqcmHR5/wAtHFAwFA3EGUuVky533dy7/nIb8uPKv5W/kl+ZGj6HplsZvL//ADka
2jaRrEkSNfRaVc+VI9RisTdMDK0cZlGxahYcjvvlnZHauXUayEpk74dx04uOrrlbX2t2Vi0+knGA
G2bY9eHg5XzpnP8Azj75L8k+atL/AOcJrHzF5S0nWLfzZ5i/MVfMKXNpE5vl03T7ie1W6bjWVYnj
UqrkgUpSmUdsdoZsWXVcEyKjjqjysi67rb+yOz8OXFpeOANyyXtz2NX308v/ACr/ADYh/MbyZ+cX
5n+evyv8hahF+Reg22peSvKenaBbadpz6jq1wLK3a9itwpuYLcLURSMR/sqES1MMmCePHjyTHimp
EyJNDc1fInvDHTTx54ZMmTHA+ELAEQBZ23rmB3FQ/IbX4v8AnJT80bC38+/lr5KZPIfl3XPMwsdC
0+Dy+NcmtIYxa2WpTRyRwGFZWUhmC0FQ7FKjMjXnJ2dpiceSfrIjuTLhvmY3vf4G7j6AY+0dQBkx
w9AMtgI8XcJVtX45M/vtB81eePy//OIfnh+Wv5V/l+nljylqHmP8tPMvk++8uw3sOp6bwmTSli0n
UbiSaK4hDqBIhoR9rkVzDwa7wM+M4MmSVyAkJcRBB/i9Q2I8nNz6Lx8OQZ8eONRJiY8III/h9J3B
8355WspmhVz3z0XHLiFvneSPCaROWNbsVdirsVdiqM/6V/8A0cf8aZD+L4M/4fi//9Pxzc/70T/8
ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab/fvpH/A4/wCdp/2ztR/vHlGeqvmz
sVdirsVeyfl3+avlHRfJHmn8oPzZ8t6r5j/LHzNqtv5gs7vQJ4odX0bWbeMW/wBdsxcgwSepB+7d
HpUAbjfOY7V7Oyyzx1GAgTiK35Sjzo1vzem7K7RxRwS0+cEwkb25xlysXtyVfNv5u/lZ5Z/LDzj+
Wf5C+X/NYk/Mj6rB5689edGskvzp9nL6yWFlbaezxRI7gGR2clhUU3HDAOj1Wpyxyakx9H0xjdWe
pJc8avS6bFLHpxL1/VKVXQ6AB9Qf85EeZv8AnGryb/zkLa+aPP2jfmH5l/MDy7pflrUF8s6b+i4/
Lt5JbadbSWiy3Eji7RaBfUAjapBoaGg0nZcdZk0xx4jARkZCzfENzfk7rtOWjx6kZMokZRETQrhO
wrzfPL/85AeSPzW0Lzh5W/5yN8r+YpNN1rztfeevKvmTyVLa/pDSLnUUEc9j9XvysM1uVVaFmDCn
ypsP5Fz6eUZ6cixHhIldGuu3V1/8tYNRGUM4O8jIGNWL6b9G/wAuvzU/5x9/KT81vK3mz8v/ACf5
6Pl/RtH8wWOu6vrdzYXOrajNqti1tacbOA29tbxwOSTSVmIfuUHK3Udm6vVYDHIY8RMaABAFGzvu
TfuatP2lpNNmEsYlwgGySCTY222Ar3vPfyM/MXR/yutvzhXXLC/vT+Yn5XeYfI+j/UEif0b/AFcW
/oSz+rLFSFfSPMrybpRTm07R7OyaiOLhr0ZIyN9wvl57us7O7Rx6eWXis8eOURXea5+THfy2vfy7
0y/nX80tC1zW/LV1ZSQJ/h28hs9QtLkvGyXMf1mKWKXiquhRwAeXKvw0Ox1MdQMI8AgSB/iFgju2
II97rtNLTnMfHBMSP4TRB79wQfc9evPzb/JP8ufI/wCY3l/8hNG8+Xvm78ztMTQdU81+c2062j07
TfWSaZLS3055fUkl4U5uw47EDYhucy6LV6vLGWfgAgbqN7nzJeixa3SaTFKODjJmKuVbDyAZNqv5
2/8AOOHn/wA3ab+cX5o+QvPn/K1UjsJvNHlvQZ9MHlrWtR02KOFLiSWYJc2yziJTIiI3gCTVmrxd
n67TYzgxSjwG6JviiD9h8m3Jr9Dqcgz5Yy4xVgVwyI+0eaW23/OR/k78ydD/ADS8qf8AOQ3l7zJ+
g/Pvn3/lYmh6x5La0kvtK1IWY08W3pagUSWFbVEiBLggAmlTURHY2fTThk05Fxjw1K6Iu+nW0ntj
BqYTx6gGpS4rjVg8uvSmbeTv+cpfyc/L3zd/zjtbeUPKnnm5/L78kb7zZf3t/rDabLrN8/mPT5rV
RHb27w26hJZeRrLsu1WIqaNR2PqtSMspmPHkEeV8I4T57t+n7Y0umOKMBLgxmXOuI8Q8qD54/In8
zNF/LWLzv5b89eXLzzP+XH5n6GND85abpsyQahCI5BNbXlm8gMZlgkBKh/hNd83faHZmTNCE8Zqc
DYvl5g+RdL2f2ljwznDILhMUa5+RHmGfeV/zc/JT8ovOeha5+VXljzt5q0K7sdT0X8ybDznPYWj6
jpOqQrBJbWsenCQRMm782kbkQBRRmNn0er1uEwzGIIIMeEHYjqb/AFORg1mk0eYTwiRBBEuIjcHo
KYVr7/8AOJdnousf4C8t/mjrHmjUIHj0aPzRd6TaadpsslOMpNgss10Yt6BvTDftDfaWl0+uMwMh
gIg70CSfnsPtRqs+hECcYmZEbWQAPlufseW2qcIVXpnX4xQeRyGyiMsa3Yq7FXYq7FUZ/wBK/wD6
OP8AjTIfxfBn/D8X/9Txzc/70T/8ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab
/fvpH/A4/wCdp/2ztR/vHlGeqvmzsVe/f847flZ5D/NrzXrmhef/AMx7X8ttN0zSTf2eqXM1rCJ5
hPFF6Qa7kjU/C5agNds0PbvambQY4yxQ4yTXXbbyd72F2Zh12SUcs+AAX033833PoX/PvX8oPNNn
d6l5Y/P+XzHp1i5jvr/Sxp15DC6qHKySQzOqkKQaE9N85GfttqoGpYgD529bD2K00xccpPup4L+c
n/OMX5C+Qfyz81ecvK3/ADkXpXnTXtDhgk03y1DeaVK920tzFCUVLe4aQkK5b4QembDs/wBp9Tqc
8cc8NRPM77bOBr/ZnTabBLJDNchyG2+74GWGCWGqoBzGdqIRIeKM5RKZ65qeu+bNam8w+a9ZvPMW
szxwwyalfzNPMYreNYok5OSaIihQOwzG0+gx4BUIgDycnUa/Jm3nIk+aEMMRFCopmaYBwuMvqn/n
Dv8AJHyT+ev5pa35N86PqEOlad5WutagOmTpBKbiG9srdQzPHKCvG5aoA6038eb9pe0snZ2CM8QF
mQG++1E/oek9m+zcfaOeUMpNCJO229gfpeI/mx5b0byV+bf5k+RdEaeTSPKPmG/0vTnunWSYw28z
InqOqoCaDqAMz+yNYdXp4TlVkC/e4Ha+jGk1E4RugTXuYOUQjiQCPDNtwh1NlTFvApqEAOREIhkZ
yLjBCxqUBOEwiVE5BswxEUKCmJgEcZWi3gUGiDBwRCeORfdtt/zjd+W83/OEVz/zkNNcayPO8Vtd
TCFbmIWHKDXn0xR6PolqGJBX4/tb+2cVn7fz4+1PytR8OwOW+8b533vaYOwcM+y/zNy8Sj122lXK
u58G26QyRLIEHxDOzxiJFvG5DIGlYW8INQgrkhCLHxJKwAHTbJsHVHjirqjFXYVdgVvCqM/6V/8A
0cf8aZD+L4M/4fi//9Xxzc/70T/8ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab
/fvpH/A4/wCdp/2ztR/vHlGeqvmzsVQV5ZRXicJBUHKcuEZBRbsWY4zYfr1/z7dsIrD8g/zthiFF
fXrtj8/0TAM8r9rMAxauAH839JfUvZTOcukmT3/oD83/APnDL/nHCw/P38ybHy5qdzNYeW9GsX1n
zTdW1BM1tDJHEsETMCFeaSRVqQaLyYA0pnQa/VR7O0gyRFzJoe/v+DoNBppdo6s45GoAWfd3fF+i
OufmT/z7m8m/mLP+QV9+WSS3Gn366Bq/nNLEz6fZ3qsIZIp9Te8F8GikHCSREKqwarfaOc3DU9rZ
IeMMp76v/e1wvRz03ZWOfgnEO66/318TwX/nIH/nEYeRPz+/LX8vPIt5LF5T/Oa79Hy1Lekzvpsk
Eka38buSDKkEciyqSeRU8TUjkel7J9qDk0mSebeeMb1/F3e6+TzXavswMeqhDDtHIdr/AIe/31ze
9fm9rX/OEX/OIuo6D+WHmT8oLz8yvNV7psN/q176FvqF1HBIzxLNcTXdxCkckpRmEcKqAKH4Rxrz
2LXdqdoyOSOUxF7AbD7P0vQ5dD2Z2dEY5YuI1uTuft/QgP8AnDzzL+Tnmr/nMPzbq/5F6DqHlnyR
e/lTPNPomoo8ckGonV9M+sKqNNcBVpw2Vyta8dsn21LVfkIR1J4pDJz8qNdzDsWOl/PylphwxMOX
nYvvUPzI/Pn/AJwN8ifnV538r+ZPyS1LzT5rufMt2n5jedLmxivLWHUJp6XMkf1y89QpG1SwiiVQ
B8AYnMXRw7RlhBxZDGIGwBr7g5Wsn2dHMRlxiUidyRf3liH/ADk3/wA4z+Qfy4/5yG/5x/sfL2nS
WX5e/nV5psdG1ny1HNJwtZRqFlBdJbylvURJ4rsFRyJVg3EheKjedke0efJpMwmbnjiSD8DV+4h0
fa3s7gx6vCYCoTkAR8Rde8F69+f/AJi/5wu/5xO1/wAveStf/wCcd5fNGqa9pS6nay21vBfxJaia
WACSfUrwymTnGa/Cainxds0ul1naevuQzEUfd/uQ7rVaPszQ1E4QbHv/AN0Xl3/ORn5Nfkh5w/5x
v0z/AJym/ITRZfKmmqILrVNEAaKOe0mvRp86SWpklSGe1uPhb0m4EK/2vhbNr2L25qsOq/LamXFf
U8wavn1BHe6rtrsPS5tL+Z00eHyHIi65dCPJkfkb8m/+cd/+cd/+cftA/Pv/AJyQ0iXzZqnmqGyu
NN0ExtcBG1KP6xaWFrZ+rFFLM0KmSRpmCrRh8IU8q+1O39ZrNTLBppcEY2LHM1zN867qbOzOwdJp
NNHPqY8UpUaPIXyFcr77TiH8qP8AnGL/AJzH/KXzV5x/5x28sz/l/wCfPK5kih0mSAWD/W1i9WG2
vLOKaa2Mdyq0SWJqhqkk8WTMfT9t67s7NGOolxwPfvt3g89u5yNR2Joe0cMpaePBMd22/cRy370t
0+cTf8+mr2fccrDUSQeop5xmByjVZBPtni8x/uQ36XGYdjcPkf8AdFAfl3+S3/OPH/OOP/OO3lv8
+P8AnJHSZfNureaYLG407QTG1wI31KP6xaWFrZ+rHFLMYVMkjTMAtGHwhTyy9d27rNVnODTS4Ix2
sczXM3zrupxND2Ho9LgGfUx4pS3o8hfIVyvvtkUH5Uf84xf85jflN5p84/8AOO3lmf8AL/z55WLx
RaTJALB/raxerDbXlnFNNbGO5VaJLE1Q1SSeLJlen7b13ZueMdRLjged77d4PPbubNR2Joe0cMpa
ePBMd22/cRy373j/APziH+Q35X6/+WHnL/nIr88Fa88j+T/rrWehtI6QvFpkAmu7mdYirynkeEUQ
YcmUhlaqjNv7Q+0OeGSOn0xqUgLPXfkB+kuo9n/Z/BPHLUakXEE0Om3Mn9Aeu/kj+ZP/ADhL/wA5
JefYvyu8u/8AOOE+h3dzaXV5p+rXljZ2kbxWi1b1JLK8MysymoA5b9T3zQ6nN2npIeLLOSPeT94p
32mw9maqfhDCAfcB9xtnX5M/kv8A84/+ZPPH/OUf5HSfl/pBvPy/1y3Hl/UruM3eoWmm67pURjEN
xcFpW+r3EcrKxcleS1PQmOr7b1ojhzeJLcbgbAmJ7htuKZaTsTRGWbD4Y2OxO5AkO877G35sf84y
/l0/nv8A5yH8lfl35j05LyDTNcuG826dKOULQ6MJJrmGUEbpI0HpkEb8qd87ntPtXw+zpZoGiRt7
5bfZdvD9mdleJ2hHDMWAd/dHf9FPSP8AnO+L8vfK/wCell+Xn5ceU9J8rWnlXQbWTzHHpdvHb+pq
F+zXAEgj68bcwkV3+I9s1/snqs+bEZZZmRJ2s3sP227D2r0uDDlEcUBGhvQrc/sp8i52rxSM/wCl
f/0cf8aZH+L4M/4fi//W8c3P+9E//GRv1nPoaPJ+e5cy9R/Kr/ypH/gC6x/zJzyz/gp/86j/ALam
m/376R/wOP8Anaf9s7Uf7x5Rnqr5s7FXYq/Xz/n3Z/5Ij86v+25d/wDdJgzyv2z/AMdh/VH3l9S9
jf8AE5/1j9weAf8APqS9to/zD/MLT5J0S7uvKkM9tbE/E8cN5EsjKO4UyrX55d7Ug/lsR6X+hp9l
yPzOUda/Sv8AzT/5yT/5xu8lfmf+YXlHzd/zg5pFx5m0TXr+DWNRupLNJL+T12YXtHsSStypEymp
qGBqa1zA0Wg1WbEJQzEAjz/W5+t1+lw5TGeEEg+X6mVaT/zl7B/zkj/zkp/zimx/Ly9/L/T/AC15
g1lodQvb4Xcd6+oWBtY0i428I+GVApNTuQME+yJ6TTZiZXYH3ph2vDV6nCBGqJ+54j/z8X0C8s/+
cpbjVdSsXh0/XvLOlS6ReOv7udYBJBKFbpVHQgjqNj0Izeex/BLEQeYJdJ7X8ccoI5EBn/8Az7St
kt/+cg/NNIzH6n5d37pUU5KdV0mhHiDl3tsIjTQ4f54+6TT7FGR1M7/mH74vjn/nJC1gk/5yK/P5
3QFj501jf/o4fMz2fxxOjiT/ADXD7fySGskB/Ofrn/znESPzn/5wTp3/ADXtK/8AcQ0nOC7J/us/
9Q/cXvO1f73B/XH3h8mf8/RIY5fz1/Lf1FDU8kilf+2jd50PsdESEr7/ANDz3thIxMa7v0vWolEP
/PprU1jHELp+o8QP/AxmzX9oDh7ZNd4/3AdhoDxdjC+4/wC6Lf8AznjpVx5p/wCcP/8AnHvzNo8J
1XQdKn8v32o6hB8aRW15oskUM7EdEaR1WviyjvlfYPCNfKM+t/ez7d4joIyhyFfciv8An1rok+j6
L+d/mm4t/qXl/UpdBtrbVZfggeTTY9RluhzagpEt1GWNdq5ne2fAMmKEeYBv41X3FwvY3j8PLOXI
kV8Lv7wl9vdx3/8Az6b12+t2LwXkWtzwOQQSknni5ZTQ7jY5qBY7RHw/3IduaPZx+P8Auirf854a
Vceaf+cP/wDnHvzNo8J1XQdKn8v32o38HxpFbXmiyRQzsR0RpHVa+LKO+ZPYPCNfKM+t/e4vbvEd
BGUOQr7kV/z610SfR9F/O/zTcW/1Ly/qUug21tqsvwQPJpseoy3Q5tQUiW6jLGu1czvbPgGTFCPM
A38ar7i4Xsbx+HlnLkSK+F394Qn5UM3nn/n2f+a1l5bjk1e9R/NTSWcKlpaLqTagV4U5cvq7q9KV
3zVZvT2hAz2+n7qdph9XZ8xDf6vvt8yf8+44beP/AJyQ8ttEFDfoDV9x/wAYBnWe1EIjs8V3h5X2
YnI9oG+4vob8v/Pp8lf8/Q/zU0mecxaZ+Y5/w/dA1Mf1hdLs7y0YgH7Rkt/SU0NPUPYkjmsml8Ts
uMxzjv8AaQXpMeq8PtSUDylt9gIe9fkd+S6+Tf8AnNT/AJye883NsltoVrZWeoaJeSUSL1PNJ+v3
sqk7Axy2sysa7BvfMbWdoHJoMWHre/8Am7D73I0nZ4x6/Lm6Vt/nbn7n4wef/Osn5p/m5+Zf5lSS
NLD5s8wXt5ppapK2IkMdlHVgD8Fuka9B06DPRPZ7SeDgiO4PnntDq/GzyPeUqzpXnEZ/0r/+jj/j
TIfxfBn/AA/F/9fxzc/70T/8ZG/Wc+ho8n57lzL1H8qv/Kkf+ALrH/MnPLP+Cn/zqP8Atqab/fvp
H/A4/wCdp/2ztR/vHlGeqvmzsVdir6m/IX/nL27/AOcePI3nXyRB+Wo86Dzjey3g1Q6v+jvqxltE
teJi+pXPqU4cvtr4e+cX2/2DLXZ45BKqFVV9b7w9l2B29HRYJYzG7N3ddK7i+Yvyv85+c/yj8w6F
568jal+jPMugsWt2dfUhmjdeEsFxHUB45FJDD6QQwBG11HZcdTpvCmHV6ftSWm1PiQL9Df8Aoptp
eoWtrc+ef+cZNL8xea7CMLHqUWpQ+g7j4gY/rOn3EsC8u3OSnWpziZ+y+fHIiGQge79r2sPajBki
DPGCff8AsfIn53f85LefPz988+VfPcuh2X5f3PkOONPJlvpDyPLaNDcC5ileeSgaRJAvEqiAUHw5
0fZPYY0+GWM3Lj537qed7W7bOfNHIKHByr5vrbSv+fm13LothYfmp+QemeeNe0ni1trVpexwQSzB
aGX6rc2dz6DkgElHI32VQKZz+f2Vy4pnwpkA/joRbv8AB7U4ssB4sASPx3PKPL//ADnj5lsf+cgt
c/P3U/yqs75dR8nHybpvky01R7Nba1F5BeJM929rceo4MJU0hQEHYCm+dL2cnPSDAJEVLiur3quV
hwY+0cIas5zEG48NXW13zp8o+e/NU/5kefvzA/MGXSf0G/njWr3WP0OJvrP1b63K0gi9b04vU41p
y4LXwGdN2VoZabTjGd6FPNdq60anUHINrNvqX88v+c2L/wDObzt+Rfmz/lVA8uf8qS81ReZxZfps
3g1NoriznEHP6hB6AP1WnKkn2um2/MaT2Ynpxkjx3xxrlVc/Pzem1ftNDOccuGuA3z58vLyeY/8A
OSf/ADkJdf8AOTXn/wAu+cpvI/8AgVfL2iDRhp36S/SfrUuZrj1fV+q2nH+948eJ6VrvQbXsDsaW
gsE3ZvlX6S6vt7tiOuogVQ77/QGVzf8AOV15B/zitc/84tL+XAmjuoZ4P8d/pbjxFxrDasT+j/qZ
rTl6f9//AJX+TmNq/Z+U9f8AmRLYkbV3Cud/ocjSdvxx6D8tw7gHe+83yr9LIP8AnH7/AJzi89/k
X5Nh/LfzR5MtPzT/AC9tVki0vT7i4+qXlnBMSZLcStDcRzQ1YkRvHUVI58aKMftT2Y8Wfi4zwycn
sv2m8KHh5BxRTP8AOz/n4J53/M7yTf8A5Yflj+Xlr+UHlPWLZrHV72G6FzeyWk1fXgtxDBbRWyS8
ir0V2Kk0ZeRzE0PsxIZBPKTI/j5uVrvaaJxmGMCI/Hyef2v/ADlNd6b/AM4lN/zikn5biaKW3uLc
ee/0tx4i41l9XJ/R/wBSNaczH/f/AOV/k5m5PZyX5wZxLbbavKud/ocLH7Rx/JnAY777353yr9LL
f+cfv+c4vPf5F+TYfy380eTLT80/y9tVki0vT7i4+qXlnBMSZLcStDcRzQ1YkRvHUVI58aKI9qez
Hiz8XGeGTPsv2m8KHh5BxRTT86/+fgnnf8zvJN9+WH5Y/l3a/lD5T1e2ax1i9guhc3slpNX17e2E
MFtFbJKGKvRXYgmjLyOYmg9mJDKJ5SZH8fNytd7TROIwxgRH4+SG/wCcNvO//OSf5S6f5l1D8ofy
1n/Nr8vZL2H/ABd5SikCvHe+l8E1syF5YpHjUKzCF1YKARVVple0PZ2kPCMkxCdbe78ebjez/aGr
HEccDOF7jz/Hk/SL/nHj81PMPnj8w5NPl/5wn1H8ibEWFxdaz+YOqWi6cfWBAS3iD6XaPcGVnNSJ
NhUkHOP12Lgx/wB/4ncAb/Saeu0WXjn/AHHh95Ir9At+aH50+WvzV8yf85Yfmz+a35PeSPMHnCHy
R57tI7PXNF0u61K3h1jRbe0LwP8AVUepjkiHNa9CK0qM63snJpxoRhzzjHiidiQNjfe8n2tj1B1p
y4ISlwyG4BO4rufpL+d356eb9K/5wo82/mP568mt+Vf5h+c9Ik8u6d5TlmeW7judTlexjf8AeQwv
G/otJdCJgTGooSWBzk9Po4nWjFCXHEHn7vxT1eo1khojknHgkRy9/wCLfgpoVsLaxiWlDQZ7Losf
BjD45rMnHkKdZmOIjP8ApX/9HH/GmQ/i+DP+H4v/0PHNz/vRP/xkb9Zz6GjyfnuXMvUfyq/8qR/4
Ausf8yc8s/4Kf/Oo/wC2ppv9++kf8Dj/AJ2n/bO1H+8eUZ6q+bOxV2KrSqt1AOCgkEhsADYDbGkL
DFG25QE4DEFkJELgqrsqgYQAEEkrWjjb7SA4DEFIkQ36aDbgB7Ux4Qtl7D+SX5Y6d+ZvmnVrXX9Z
fy15L8maBqHmvz3rsEYlnt9K0xVMot0b4WldnVFr0qWo1OJ1PbHaJ0WIGEeKcpCMR04j3+TteyOz
xrcpE5cMIxMpHrQ7vNd5n82f84wavour2nkzyH5/8t6/bRH/AA3rV5qtjfQXUoKgfpC2MMfpqy1J
9FyQadRtmv0mTtDxAckoSj1AiRX9U397sNVDs/wyMcZxkOR4gb94r7mJ+Tfyv/Mbz9a3d75I8ha9
5rtbA8L270rT57qKN6V4M8aFeRG4WtfbNzn7Q02mIGWcYk95AdPg7P1Ops4oSkB3AljP6F1U6udB
Oj3g19bj6o2iG3k+uC4rx9H0OPqc67caVzI8bGYcdjh53e3zcfwcglwUeLlXX5M6138lvzc8t6HL
5j8xflb5p0XQLded1qt9pF3BDClacpmeMemte70H35iY+1dHlnwRywMu4EfY5WTsrWYoccsUhHvI
LNPyq/5xq/MP81vLXmnzZoOhX8Wj6Ho11qWiXaWEs6azd2sgiOn2joQDKWr40odsw+0O3NNoskcc
iLJAO/0g/wAR8nM7P7D1OtxyyAEAAkbfUR/CPN5Vb+Q/Ol55rn8jW3k/V7rzpaStBdeVoLOaW/jk
QAsrwIpccQamo2HXNh+e0/heMZgQ772+br/yOo8XwhEmfdW/yW+b/I3nDyHfQ6X548p6r5TvrmP1
bW21azltTNGKVeL1VUOBWhK1oduuS0+swakXikJDyNsdRo8+mNZImJ8xTINH/Jf81tc0V/Mui/ll
5lvvLyW5u/07Fpdz9TaAKXMqTlAjqFBJKkgDKcnaejxT4JZIiXKrF37m7H2Zq8sOOOORjzujVe9D
/l9+dn5v/k7Pd3f5Wec7ny4moOkmpacYobqzuWjBVTJbXMcsZPFiOQAanQigzF7V7Jw68DjjZHI9
fscrsrtbNoSeCVA8x0em+ZP+c6/+cuPM+m3Gj/46tPLsN2pjnvtF0y2tbvgeojuCjvGf8qMqw7HO
ex+yWGMrq/eXocntZmlGrr3Bg/5Qf85J/nx+Quh6toH5e+ZLVdK1zUpdZ1Kz1Oxgvi+oTxxxTXBm
kX1uTrCgIL02rSpJObrfZrDnoyG4FbHo4Wj9pc2CxE7E3uOrHfzW/O386fz+vdLl/NXzWdV07RHM
uk6DawRWdjBIwIMoghVQ8lCRzcswGwNMs7M9n8ellYDV2l7QZNVGpFhcaCNFQbADOqiKFPLSNm1T
JIRn/Sv/AOjj/jTIfxfBn/D8X//R8c3P+9E//GRv1nPoaPJ+e5cyzDyL5ttfKF9q9xfaL+nrLWtJ
uNJvLD6y1rWK5aMufUVHb7KEbUO9a7Zxntx7J5vaLT6fHg1H5bJp88M8Z8Ay+rGJCPoMojnIS3sb
UYm3rPY/2mxdhZ8882D8xjz4Z4ZQ4zj9OQxMvUIyPKNbUd7BFMh/xd+V/wD5aD/w4L3/AJozn/8A
Ql7X/wDRf/688P8AxTvP9E/sv/0Rf+vvN/xLv8Xflf8A+Wg/8OC9/wCaMf8AQl7X/wDRf/688P8A
xS/6J/Zf/oi/9feb/iXf4u/K/wD8tB/4cF7/AM0Y/wChL2v/AOi//wBeeH/il/0T+y//AERf+vvN
/wAS7/F35X/+Wg/8OC9/5ox/0Je1/wD0X/8Arzw/8Uv+if2X/wCiL/195v8AiXf4u/K//wAtB/4c
F7/zRj/oS9r/APov/wDXnh/4pf8ARP7L/wDRF/6+83/Eu/xd+V//AJaD/wAOC9/5ox/0Je1//Rf/
AOvPD/xS/wCif2X/AOiL/wBfeb/iXf4u/K//AMtB/wCHBe/80Y/6Eva//ov/APXnh/4pf9E/sv8A
9EX/AK+83/Esp8l+ePyns/Men3Fx+Xa+XVjLcNZfUrnUUgcqQrNBIlD/AK1CV65y/tl7E+2ep7Ly
48fax1RNXiGDFpzMXuBkhK/83YS5E9HovZT2u9k8HaWOc+zBpgLrIc2TOIGticchX+duY8wkv51+
Y/KPmPzHb3PldUnaK2VNQ1OJDGkz1YgUIUsVBA5U9u2bn/gL+z3bfY3Zc8faZMQZkwxyPFKEaHUE
8IJs8N+exLqf+Cz272R2t2jHJ2cBKogTmBwiRs9CBZAr1V5b0zj/AJxrSS/0P/nKDRLNGuNU1H8m
9cksLFBWSYW8tu8ojH7TBTUKPiPYHO49pdpaeR5DKPuLyvs1vHURHM4z94fI+nRwLaBgByA650GC
MRC3n88pcdP0K/M6/wDJ2jflF/zjDod7+fPmf8mrGTyTHrlvo3ljQZtRgvdQurmR7m8mubbU7D98
sg48WVivWo5HOBjPJPV6iQxRyHjq5GqA5DcHZ76UMcNLp4nJLGOC6iLsnmdiN0Jov5l+TPzM/wCc
zf8AnHDXfJWr33mN7bTdA0jzt5p1GxOnXGq65p6XMFxfPAZJiDNEsJ3dqfZ5Glcs8LNp+zc8JigT
IgA3UTW3ztq8XDqO0sE4GyBEEkVche/ypKf+cZ/OXnbXf+covPXl3XPNusaz5b8xWPnOx1rRL6+n
uLa5gitbto0eKR2WiFBx2qBsNq49p6eENFDJGIBBgQQOW4XszUSnrZ45SJBEwQTz2LAP+cWNZ1uH
yL/zlMltq97apaflHqtxZJFPIiwzi4gpLGFYcXFT8Q3zK7cgJzwEjnkA+xxexJmEM4B5YyftZb/z
jXqVpY/84/f85Qeb9c/MPV/IesTTeVtK1P8AMjTrKTWdWtLK9upVeNEFzbSgXTqsbv6o2p1KjKO1
xKOfT4xESA4iIk0CQB5Hl7m/sgxODUTMjEnhBkBZAJPmOfvYf54/M/8ALR/+cer38r7D82vMf5w+
ZrfzXa695S1PX9Cm01tLtzC0F7bwzS3983CQEPwDKvKppXfLdDh1EdWM3AIAxING77ugatbm08tI
cPGZniBFiq7+pTX/AJyp8zea7NP+cXtJ0vzJqmm6XN+QPky4m021vJobdpZlu0kcxI4Us6xqrGlS
FAPQZZ2JgjlyZyQCfGn09zDtvNLFjwAEgeDDr73yxChjQKTWmdvCNB4iZsqmSYuxV2Kt4VdiqM/6
V/8A0cf8aZD+L4M/4fi//9Lxzc/70T/8ZG/Wc+ho8n57lzKjkkOxV2KuxV2KuxV2KuxV2KuxVPvK
XnPzb+XXmfSvOvkfV5NE8yaM7NZ3iKrqyupSSKWNwySI6kqysCCM1/aGhhq8ZxzFguf2frZ6TIJw
NEM/8z/85DeYfM+h6xoEH5Tflh5Nl8wRGDWvMnlzy0lpqc6Oys4E8s0wh5lat6KpXNNpexpYpgnJ
kkByBl6fl1+Nu51XbAywIGPHEnmRH1fPevgpeVv+cgvOflXyjpPkXWvJXkf81vK3l2aafyrp3nnR
v0odKa5YPMtnLHNbyKjtuUZmX26UGs7BjkynLGUoSPPhNX7+adH27LHiGKUYziOXELr3ckqtfzr8
6x/mn5Z/N9NH8uWuveT3tz5f8v2Wlx6fo1vFbB/TgW0sjAeAMjE/HyNftUpl8exoHTSwEyqXM3cv
mbaJdsTGpjnAjceQqo/IUlvkH80PNf5c/mBefmboVnplx5hvV1VZbS9imksx+l4pYp+KRzRv8ImJ
T49iBXkKg26jsmOfTjDImhXLn6fg1aftaWDOc0QLN8+Xq+KH/K38yfM35Q3uu32haZo+v2XmnRbj
y/5m8t6/bPdaff6fcsjSRSxxSwuDWMEMjqR47nHXdlR1WOIJIMSCCNiCF0PastNORABEhRB3BBTf
yn+dPnHyL5m81+YvK3l7yxp+jedrf6l5n/LSXTjd+WruzFONtJZXUsrlFIqCZeQJb4qMQcfUdixz
4oxmZEx5Sv1X7x+pyNP2zLBllKAiBLnGvTXuP61Pzz+ceu+ftCi8qw/l/wCQ/wAuvLiXSX1xpnk3
QYtONzcRK6RyT3Mr3Fy/EStRfV479NhQ6HsjwJ8ZlOZqvUb+zYfYjXdr+PDgEYRF36RX27n7Up89
ef8AzH+ZNz5Ek8w2thbD8vPJ+l+SdD+oRyR+pp2ker6Elx6ksvKY+s3Jl4qdqKMzNB2bHSymY365
GRvvPOvJw9d2lLVRgJV6IiIruH6WM5uXTuxV2KuxV2KuxVGf9K//AKOP+NMh/F8Gf8Pxf//T8c3P
+9E//GRv1nPoaPJ+e5cyo5JDsVdirsVdirsVdirsVdirsVdirVB4YFdTFXYq7FXYq6gxV1B4Yq7C
reKuxV2KuxV2KuxVGf8ASv8A+jj/AI0yH8XwZ/w/F//U8c3P+9E//GRv1nPoaPJ+e5cyo5JDsVdi
rsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdiqM/6V/wD0cf8AGmQ/i+DP
+H4v/9XzTP8A38//ABlf/iRz30cnwU81PCh2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2
KuxV2KuxV2KuxV2KuxVE/wDHj/0df8y8j/F8GXT4v//ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAOgD4RsAAAEA6QMoAAAAgBYAAOAQAACYEQAA
QBcAAAUAAAAKAAAAAgAAAAAAAAABAAAAAAEAAQ8A8gOYAgAALwDIDwwAAAAwANIPBAAAAAAAAAAP
ANUHyAEAAAAAtw9EAAAAVgBlAHIAZABhAG4AYQAAAGkAYwAAABMAAAAAADAA0g9UqRMAVKkTAFgu
ywDclhMAMvIMMNyWEwAAAAAADwDVBwAABCIQALcPRAAAAEEAcgBpAGEAbAAAAGEAAABpAGMAAAAT
AAAAAAAwANIPVKkTAFSpEwBYLssA3JYTADLyDDDclhMAAAAAAA8A1QcAAAQAIAC3D0QAAABXAGkA
bgBnAGQAaQBuAGcAcwAAAAAAEwAAAAAAMADSD1SpEwBUqRMAWC7LANyWEwAy8gww3JYTAAAAAAAP
ANUHAgAGAjAAtw9EAAAATQBTACAAUABHAG8AdABoAGkAYwAAABMAAAAAADAA0g9UqRMAVKkTAFgu
ywDclhMAMvIMMNyWEwAAAAAADwDVB4AABiJAALcPRAAAAItbU08AAFAARwBvAHQAaABpAGMAAAAT
AAAAAAAwANIPVKkTAFSpEwBYLssA3JYTADLyDDDclhMAAAAAAA8A1QeGAAQCUAC3D0QAAABDAGEA
bABpAGIAcgBpAAAAaQBjAAAAEwAAAAAAMADSD1SpEwBUqRMAWC7LANyWEwAy8gww3JYTAAAAAAAP
ANUHAAAEIgAApA8KAAAAgABgAAAABAAAAAAApQ8SAAAAAAARGC4AAQAAAAAAWgAHAAAAAACpDwoA
AAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAQBkAAAAAP8BAGQAAAAAAAAAAABAAgAAAAAC
AAAA///vAAAAAAD//wAA//8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2AD
AAAAAAAFAACABIAEAAAAAA8ACwS2CgAADwAA8K4KAAAAAAbwwAEAAATYAAA3AAAAHQEAABgAAAAB
AAAACgAAAA0AAAAHAAAADgAAACEAAAAPAAAAMAEAABEAAAAHAAAAAAAAAAcAAAAAAAAABgAAAAAA
AAAyAAAAAAAAABQAAAAMAAAACAAAABAAAAAGAAAAEgAAAAYAAAAAAAAABgAAAAsAAAABAAAACgAA
AAEAAAAJAAAAAQAAAAgAAAABAAAABwAAAAEAAAAGAAAAAQAAAAUAAAABAAAABAAAAAEAAAADAAAA
AQAAAAIAAAABAAAAAAAAAAYAAAAAAAAABgAAABoAAAAGAAAAAAAAACgAAAAAAAAABQAAAB0AAAAG
AAAAHgAAAAYAAAAfAAAABQAAAAAAAABYAAAAAAAAAAUAAAAAAAAAOgAAACAAAAA2AAAAIQAAAAUA
AAAiAAAABgAAACMAAAAFAAAAJAAAAAYAAAAlAAAABAAAAAAAAAAEAAAAJwAAAAQAAAAAAAAANAAA
AAAAAAAFAAAAAAAAAAYAAAAAAAAABQAAACwAAAAFAAAALQAAADgAAAAuAAAABQAAAAAAAAAFAAAA
LwAAABMAAAAwAAAABAAAAAAAAAAGAAAAAAAAAAQAAAA/AAHwhAAAAFIAB/AkAAAABQVNDKoYn7lM
369MWYaSp4AG/wAMcgAAAQAAAAAAAAAAAAAAUgAH8CQAAAAFBXrruhb8ZULEwLGTC/0XcCv/AJZe
AQACAAAADHIAAAAAAABSAAfwJAAAAAUFBE0yIY2TpTBiwhzVISqmUf8ADJ4AAAEAAACi0AEAAAAA
AAMIC/AAAwAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAiQAAAAAA
vwAEAA8ADAH0AAAQDQEAAAAgDgEAAAAggAEAAAAAgQH///8AggEAAAEAgwH///8AhAEAAAEAhQEA
AAAghkEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAA
jwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEA
AAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEMAB4AwAEAAAAAwQEAAAEAwgH///8AwwEAAAAg
xAEAAAAAxUEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEA
AAAAzgEAAAAAz8EAAAAA1wECAAAA/wEGAA4AAAIAAAAAAQKAgIAAAgLLy8sAAwIAAAAgBAIAAAEA
BQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIA
AAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAA
hQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIA
AAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkA
zgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKw
PP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEA
RQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAcw0i8QoFAACMAAEAAACNADBlAQB/
AQAAQACeAf////+fAf////+gAQAAACChwQAAAACiAf////+jAf////+kAQAAACClwQAAAACmAf//
//+nAf////+/AQAAIADZAf/////aAf/////bAQAAACDcwQAAAADdAf/////eAf/////fAQAAACDg
wQAAAADhAf/////iAf//////AQAAwAASAv////8TAv////8UAgAAACAVwgAAAAAWAv////8XAv//
//8YAgAAACAZwgAAAAAaAv////8bAv////+JAv////+KAv////+LAgAAACCMwgAAAACNAv////+P
AwAAAACQAwIAAACRAwAAAACSAwIAAAC/AwCCAIJABQAAAABBBQAAAQBCBf///wBDBQAAACBEBQAA
AABFRQAAAABGxQAAAABHBQAAAABIBQAAAABJBQAAAABKBQAAAABLBTUlAABMBQAACABNBQAAAABO
BQAAAABPxQAAAABQBQAAAABRBQAAAABSBQEAAABTBQEAAABUBQEAAABVBQEAAABXBQIAAABZBf//
//9aBf////9bBQAAACBcxQAAAABdBf////9eBf////9fBQAAACBgxQAAAABhBf////9iBf////9/
BQYATgCABQAAAACBBQAAAQCCBf///wCDBQAAACCEBQAAAACFRQAAAACGxQAAAACHBQAAAACIBQAA
AACJBQAAAACKBQAAAACLBTUlAACMBQAACACNBQAAAACOBQAAAACPxQAAAACQBQAAAACRBQAAAACS
BQEAAACTBQEAAACUBQEAAACVBQEAAACXBQIAAACZBf////+aBf////+bBQAAACCcxQAAAACdBf//
//+eBf////+fBQAAACCgxQAAAAChBf////+iBf////+/BQYATgDABQAAAADBBQAAAQDCBf///wDD
BQAAACDEBQAAAADFRQAAAADGxQAAAADHBQAAAADIBQAAAADJBQAAAADKBQAAAADLBTUlAADMBQAA
CADNBQAAAADOBQAAAADPxQAAAADQBQAAAADRBQAAAADSBQEAAADTBQEAAADUBQEAAADVBQEAAADX
BQIAAADZBf/////aBf/////bBQAAACDcxQAAAADdBf/////eBf/////fBQAAACDgxQAAAADhBf//
///iBf//////BQYATgAABgAAAAABBgAAAQACBv///wADBgAAACAEBgAAAAAFRgAAAAAGxgAAAAAH
BgAAAAAIBgAAAAAJBgAAAAAKBgAAAAALBjUlAAAMBgAACAANBgAAAAAOBgAAAAAPxgAAAAAQBgAA
AAARBgAAAAASBgEAAAATBgEAAAAUBgEAAAAVBgEAAAAXBgIAAAAZBv////8aBv////8bBgAAACAc
xgAAAAAdBv////8eBv////8fBgAAACAgxgAAAAAhBv////8iBv////8/BgYATgBABgAAAABBBgAA
AQBCBv///wBDBgAAACBEBgAAAABFRgAAAABGxgAAAABHBgAAAABIBgAAAABJBgAAAABKBgAAAABL
BjUlAABMBgAACABNBgAAAABOBgAAAABPxgAAAABQBgAAAABRBgAAAABSBgEAAABTBgEAAABUBgEA
AABVBgEAAABXBgIAAABZBv////9aBv////9bBgAAACBcxgAAAABdBv////9eBv////9fBgAAACBg
xgAAAABhBv////9iBv////9/BgYADgCAABrxIAAAAJaWlgD///8A8gAXAGEBeQACIDoA/5kAALKy
sgBNTU0AQAAe8RAAAACWlpYAAgAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAMAAAAEAAAAAAAA
AAAAAIAAAAAADwDQB7UDAAAfABQEHAAAAAAAFQQUAAAAiZidFADKmjuOmwo1AMqaOwIBAAAfABME
PAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAACCXEwCRogwwIJcTAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAETAA8A+gOXAAAAAAD+AwMAAAAAAAAAAP0DNAAAAFQAAABkAAAAVAAAAGQAAAAAAAAAVHHL
APSWEwAy8gwwAAAAAAAAAAAW+///rv///wEAEwBwAPsDCAAAAAAAAADnAAAAcAD7AwgAAAAAAAAA
FA4AAHAA+wMIAAAAAQAAAGsVAABwAPsDCAAAAAEAAAAWAQAAcAD7AwgAAAABAAAAKRUAAB8A+gNH
AAAAAAD+AwMAAAAAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAABAAAAnHLLAPSWEwAy8gwwAAAA
AAAAAAAAAAAAAAAAAAEAEwAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAACCXEwAWogww
VKkTADQuywAAAAAAAAAAAAAAAAAAAAAAAAATAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAf
AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAAIAAAAglxMAOKMMMFSpEwAAAAAAAAAAAAAA
AAAAAAAAAAETAA8AiBOzAQAADwCKE2gAAAAAALoPFAAAAF8AXwBfAFAAUABUADIAMAAwADEAAACL
E0QAAAAPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAAAQEBAAEAAAAAAAAA
ANAAAAAAAAAAAAAAgAIB4A8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAA
ACUEAQAAAAEPAIoT0AAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixOwAAAADwDWB5gAAAAA
ALcPRAAAAItbU08AAGEAbAAAAAAAAAAAAAAAMKgTANCVEwDQlRMAVKkTAFSpEwAclxMA1JUTADLy
DDDUlRMAAAAAAA8A1geGAAQCEAC3D0QAAABBAHIAaQBhAGwAAAAAAAAAAAAAADCoEwDQlRMA0JUT
AFSpEwBUqRMAHJcTANSVEwAy8gww1JUTAAAAAAAPANYHAAAEAAAADQQIAAAAAMAAAADAAAAPAIoT
MgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFAAAAC8AyA8MAAAAMADSDwQAAAAAAAAAPwDZ
DwwAAAAAANoPBAAAAAAAAgBPANkPDAAAAAAA2g8EAAAADQACAA8A8A+IAQAAAADzAxQAAAAEAAAA
BAAAAAAAAABgAQAAAAAAAAAA8wMUAAAAFAAAAAQAAAAAAAAAbAEAAAAAAAAAAPMDFAAAAA8AAAAE
AAAAAAAAAGkBAAAAAAAAAADzAxQAAAAFAAAABAAAAAAAAABnAQAAAAAAAAAA8wMUAAAAFgAAAAQA
AAAAAAAAbQEAAAAAAAAAAPMDFAAAABcAAAAEAAAAAAAAAG4BAAAAAAAAAADzAxQAAAAGAAAABAAA
AAAAAABoAQAAAAAAAAAA8wMUAAAAGAAAAAQAAAAAAAAAbwEAAAAAAAAAAPMDFAAAABAAAAAEAAAA
AAAAAGoBAAAAAAAAAADzAxQAAAAHAAAABAAAAAAAAABZAQAAAAAAAAAA8wMUAAAAEQAAAAQAAAAA
AAAAawEAAAAAAAAAAPMDFAAAAB0AAAAEAAAAAAAAAHIBAAAAAAAAAADzAxQAAAAjAAAABAAAAAAA
AAB0AQAAAAAAAAAA8wMUAAAAIQAAAAQAAAAAAAAAcwEAAAAAAAAvAPAP4AAAAAAA8wMUAAAADAAA
AAQAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAA0AAAAEAAAAAAAAAAEBAAAAAAAAAADzAxQAAAASAAAA
BAAAAAAAAAADAQAAAAAAAAAA8wMUAAAAFQAAAAQAAAAAAAAABAEAAAAAAAAAAPMDFAAAABkAAAAA
AAAAAAAAAAUBAAAAAAAAAADzAxQAAAAbAAAAAAAAAAAAAAAHAQAAAAAAAAAA8wMUAAAAIgAAAAQA
AAAAAAAACgEAAAAAAAAAAPMDFAAAACQAAAAAAAAAAAAAAAsBAAAAAAAAAADqAwAAAAAAACgEwgcA
AFBLAwQUAAYACAAAACEAVq4Hw/cAAACpAQAAEwAIAltDb250ZW50X1R5cGVzXS54bWwgogQCKKAA
AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
fJDNTsMwEITvSLyD5SuKHTgghJr0wM8RkCgPsDibxKr/5N1WzdvjpEVCqHCy1rsz82lW64N3Yo+Z
bAyNvFa1FBhM7GwYGvmxea7upCCG0IGLARs5Icl1e3mx2kwJSRR1oEaOzOleazIjeiAVE4ay6WP2
wGXMg05gtjCgvqnrW21iYAxc8ewh29Uj9rBzLJ4O5ftIktGRFA/HwzmrkZCSswa4kOp96H6lVKcE
VZTLDY020VXBkPpswrz5O+Ckey3VZNuheIPML+ALhmb4dPjOk0NS/5ucoYx9bw120ex8aUCljFTe
Bdg79cP6m1wvRbdfAAAA//8DAFBLAwQUAAYACAAAACEA7eQMS7sAAAAmAQAACwAIAl9yZWxzLy5y
ZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAISPzQrCMBCE74LvEPZuUz2ISNNeRPCq9QHWdPuDaRKSVezbm2MLgsfZYb7ZKarP
aMSbQhycVbDNchBktWsG2ym41+fNAURktA0aZ0nBRBGqcr0qrmSQUyj2g48iUWxU0DP7o5RR9zRi
zJwnm5zWhRE5ydBJj/qJHcldnu9lmDOgXDDFpVEQLs0WRD351Pyf7dp20HRy+jWS5R8VkvFh6MaT
SStEjaEjVjA7ZulbkGUhF+vKLwAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAAA8AAAB0
YWJsZVN0eWxlcy54bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/
SqKXWOxkNAP/4AESujXdpAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KI
bUehuD2YWejt9WZR3G25DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5
qf0qLH5Asj8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAFauB8P3AAAAqQEAABMAAAAAAAAAAAAAAAAA
AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA7eQMS7sAAAAmAQAACwAAAAAA
AAAAAAAAAAAwAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAADwAAAAAA
AAAAAAAAAAAcBgAAdGFibGVTdHlsZXMueG1sUEsFBgAAAAADAAMAtwAAAPUGAAAAAA8A+APgdgAA
AgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAIADDBgAPAHIAAAAAwuhgD///8A/1wAAPXmRwCm
yuEAVn65AAhgqACqAUwAYADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAAAA
ow8+AAAAAQD//T8AAAAiIAEAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wABAAAA//8A
AP//HAAAAAABAAAQAKMPlAAAAAUA//0/AAkAIiABAG4AAAAA/wAAZAAoAAAAjgAAAEACAAAAAAIA
AAD//+8AAQAAAP//AAD//xQAAAAAAQAA0iUAAAsA2AACAGkACgBCAdkAAQACAAAAEgDaBQAAAQAi
IAEAZABAAt4BAAACABAASAUAAAkAXwD0AqkCAAACAA4AyAUAAAEAEyBkAIIDPgMAAAIADAAgAKMP
fAAAAAUA//0/AAAAIiABAGQAAAAA/wAAZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP//AAD/
/wwAAAAAAQAAAQUAAAEAkgABAAAAAACSBQAAAwATIAAAIwGTAAAAAACABQAAIiCPASQBAAACAAoA
gAUAABMg+gGQAQAAAABAAKMPbgAAAAUA//0/AAAAIiABAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAA
AAcAAAD//+8AAAAAAP//AAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD
YAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAgAAQAAAAAAAAABAAEJAAAKAAEA2QAA
AAAAAgABCQAAAAABAN4BAAAAAAMAAQkAAAgAAQCpAgAAAAAEAAEJAAAAAAEAPgMAAAAAYACjDwwA
AAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABIAAQAAAAAAAAACABAAAgAAAAAAAAAC
AA4AAwAAAAAAAAACAAwABAAAAAAAAAACAAoAgACjDz4AAAAFAAAAAAAAAAAAAgAQAAEAAAAAAAAA
AgAOAAIAAAAAAAAAAgAMAAMAAAAAAAAAAgAKAAQAAAAAAAAAAgAJAA8ADAR3GQAADwAC8G8ZAAAQ
AAjwCAAAAAkAAAAJBAAADwAD8AcZAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA
CvAIAAAAAAQAAAUAAAAPAATwlgAAALIECvAIAAAAAgQAAAAKAACzAAvwYAAAAH8AgAD7Ab8ABAAE
AARBAQAAAAXBBAAAAD8BAAAGAL8BAAARAP8BAAAYAD8DEAAYAIDDFgAAAIHDBAAAAL8DAAACADIA
AABQAGkAYwB0AHUAcgBlACAANAA2AAAAMgAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAAAAAAfhbe
EA8ABPAAAQAAEgAK8AgAAAADBAAAAAoAAMMAC/BgAAAAfwABAO8BgACwscsAgQAAAAAAggAAAAAA
gwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABh
AG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADLAA4BaxVZAg8AEfAQAAAAAADDCwgAAAAAAAAAAQDLAA8A
DfBYAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHls
ZQAAog8GAAAAIQAAAAAAAACqDw4AAAAhAAAABwAAAAAACQQRBA8ABPBKAQAAEgAK8AgAAAAEBAAA
AAoAAMMAC/BgAAAAfwABAO8BgADMtMsAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEB
ABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgA
AAAsAg4BaxWwDg8AEfAQAAAAAADDCwgAAAABAAAAAgDLAA8ADfCiAAAAAACfDwQAAAABAAAAAACo
D1IAAABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQg
bGV2ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgAN
AAAAAwAMAAAABAAAAKoPDgAAAFMAAAAHAAAAAAAJBBEEDwAE8KgAAACyBArwCAAAAAUEAAAACgAA
4wAL8HIAAAB/AIAA+wG/AAQABAAAAdMHAAABAeDgAAADAfTtAAAEQQIAAAAFwQQAAAA/AQAABgC/
AQAAEQD/AQAAGAA/AxAAGACAwxYAAACBwwQAAAC/AwAAAgA0AAAAUABpAGMAdAB1AHIAZQAgADQA
OAAAADQAAAATACLxBgAAAL8DAAQABAAAEPAIAAAADw//AJUCmBAPAATwrgAAALIECvAIAAAABgQA
AAAKAADzAAvweAAAAH8AgAD7Ab8ABAAEAAAB2M0AAAEBrgsAAAIBytgAAAMBcw4AAARBAgAAAAXB
BAAAAD8BAAAGAL8BAAARAP8BAAAYAD8DEAAYAIDDFgAAAIHDBAAAAL8DAAACADQAAABQAGkAYwB0
AHUAcgBlACAANQAwAAAANAAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAGDzEAqwG+EA8ABPCtCQAA
EgAK8AgAAAAHBAAAAAoAAMMAC/BiAAAAfwABAO8BgAA4vMsAgQAAAAAAggAAAAAAgwAAAAAAhAAA
AAAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAA1ADMAAAATACLxkQgAAKmDiwgAAFBLAwQUAAYACAAAACEAWuMRZv4AAADiAQAAEwAAAFtDb250
ZW50X1R5cGVzXS54bWyUkU1PxCAQhu8m/gcyV9NSPRhjSvdg9ahG1x8wgWlLtgXCYN3999L9uBjX
xCPMvM/7BOrVdhrFTJGtdwquywoEOe2Ndb2Cj/VTcQeCEzqDo3ekYEcMq+byol7vArHIaccKhpTC
vZSsB5qQSx/I5Unn44QpH2MvA+oN9iRvqupWau8SuVSkhQFN3VKHn2MSj9t8fTCJNDKIh8Pi0qUA
QxitxpRN5ezMj5bi2FDm5H6HBxv4KmuA/LVhmZwvOOZe8tNEa0i8YkzPOGUNaSJL479cpLn8G7JY
Tlz4rrOayjZym2NvNJ+sztF5wEAZ/V/8+5I7weX+h5pvAAAA//8DAFBLAwQUAAYACAAAACEAMd1f
YdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tY
Jm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRh
qUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyH
HbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8A
AAD//wMAUEsDBBQABgAIAAAAIQBLoo+PIQQAAL4MAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxW247b
NhB9L9B/IPhaOJbvXiPawPZemsJZGGunfR5LlKWYIlWSvm3Rf+8MKa+zQRIEcfoWG7BH0pBz5syc
oV6/OZSS7YSxhVYxb72KOBMq0Wmh1jF/v7xrDDmzDlQKUisR86Ow/M31r7+8rka2YrhY2VEV89y5
atRs2iQXJdhXuhIKn2XalODw0qyblRFWKAcOA5Wy2Y6ifrOEQvFr3ErtFtXckJU87OaGFSliiQYD
zhSUGPVRJIhhLQXrdXiz9gtLAHHMdLKxNRj4FjCpgT1m+AIHU/reYCotDKqnOYYTY2P0PheQWrqN
cZse4AmrQqiEpcqZO1YIM3VI1hMCAJlxTOIQ83a9LPji+nOqFlNmq/07neJS2DqNVMDokJny0lRo
H51lDOP3O1eDfrvH2RHtfnfY7UWECEbi4FiCDoNeuzvA5wk6tNqdIfpSogEIOVbGunuhLwbFaKOY
GyylTxR2M+tCqFMICqf0XSHlpQz4FKW6dBu2j/lVDyk5I/M7l4UThsmijPkwok/glFrlVqXexUEh
g41cSuUpzzJMHrO+FBaxRvoL7ecOE50eKcAK/7Gngiq/Xwg4DrBQuTZPnO0NoCbs31swgjP5VqEU
cEa4k2FOxupkqG051dLrCFSCu8QcZRHMqcMrXJ7osgI3U4sqIUfCTj2wPPwFpqobxWGHPuhFDpX4
XL8EX9+pIW3aRFq3cEccExdS4PfayRYpFOQaJ6P0GFKRPeIt0jjWnbPVCb3VskipcWmlNevVVBq2
A6Rh0qZvrakXbgL82MggQf2/W7D5vXZ5kXBWFS7J76AsJGqy00W6cjBWYE0arfaw3ipA8fnLgDTY
NQOe0h9BA1FQgpn5uqHx6A0M6f8LleJQ9+aJJ4bIlrBaIEdXrW6XaDIueAuYqYnZePdMKzf21K7A
UmvhyaDOj2n+4oSeb1Xit/cVoX7xBFfJPHGB39az/rzOzh4TkX3q62WKbrZKzk/HmfuKX/10tcWC
Lg9e2avt4unZvMM0ni8e8Iisxb8Kww1GoU6kWOxxEiyMMpn6E+6faNKNeu3optEf3941usNppzHu
34wb7dveILpp3fajzvRfFJs/XPLsBpxYFmWQg8G6bLZlUeoPRSgJMhbzD9D4Y45yk27mr4VqvF+E
U+ncsSys2MZcIWI64E2xwSZUeuEtzjbC0OsAntLYfTQBakfSK95SdLDL4kn87i+pgrKg1wP/bG60
zrxtSzeVAnCryOsnzMEw4gMl4c4LXXyrfE7T1DO+nam6DFuSYW37pvpIZX8Kk4KCr0nsdDx+vzhh
lNiPYv5WqkZia9Vi1agDfoqKWPihonLXjCSGWsZfVBgFECqdgwEa2Z+RSi2NZ6nU0nk53H9K5cun
0f8rlXPxwuzE32p0etfxrz/X/wEAAP//AwBQSwMEFAAGAAgAAAAhAE4PjN7aAAAA/AAAAA8AAABk
cnMvZG93bnJldi54bWxEj09rAjEQR++FfocwQi+lZi3Fla1RqlAshR78U6G3cTPuLm4maRJ19dM3
9NAehze8H2887UwrTuRDY1nBoJ+BIC6tbrhSsFm/PoxAhIissbVMCi4UYDq5vRljoe2Zl3RaxUok
CYcCFdQxukLKUNZkMPStI05sb73BmE5fSe3xnOSmlY9ZNpQGG04LNTqa11QeVkejwD3NnHs/XLfb
wdenzj/oavm4Vuqu1708g4jUxf/ndqjvF99/8Ff1plNLlucg9ovLzjd6iSGSV5DyUmyCICc/AAAA
//8DAFBLAQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEuij48hBAAAvgwAABAAAAAAAAAAAAAAAAAAKgIA
AGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEATg+M3toAAAD8AAAADwAAAAAAAAAAAAAA
AAB5BgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIAHAAAAAAAAEPAIAAAAXBC+D5gR
qhAPABHwEAAAAAAAwwsIAAAAAgAAAAcBywAPAA3wagAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAA
AKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA+A8EAAAAAAAAAAAAqg8aAAAA
AQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQPAATwrgkAABIACvAIAAAACAQAAAAKAADDAAvwYgAA
AH8AAQDvAYAA3MLLAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BAQAZAD8D
AAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANQA0AAAAEwAi8ZIIAACpg4wIAABQ
SwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFNT8QgEIbv
Jv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS/bgY18QjzLzP+wTq1XYaxUyRrXcKrssKBDnt
jXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnHCoaUwr2UrAeakEsfyOVJ5+OEKR9jLwPqDfYk
b6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD4tKlAEMYrcaUTeXszI+W4thQ5uR+hwcb+Cpr
gPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5/BuyWE5c+K6zmso2cptjbzSfrM7RecBAGf1f
/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVs
c6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4
jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZN
zzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAP
VAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEA8aFp
ZCMEAADDDAAAEAAAAGRycy9zaGFwZXhtbC54bWzsVlFv2zYQfh+w/0DwdXBt2bFjG1UKO6uzDm5g
xOn2TEtUrIYiNZJynAz77/uOlONm6Ipi7t5qA/ZJOh6/++6+o16/2VeK7aR1pdEpT171OJM6M3mp
71L+4XbRGXPmvNC5UEbLlD9Kx99c/PjD63rqaobF2k3rlG+9r6fdrsu2shLulamlxrPC2Ep4XNq7
bm2lk9oLj40q1e33eqNuJUrNLxBK79b1ypKVXe9WlpU5sPTOsbcWFXa9kRkw3CnJhme82/rFJQI4
lia7dy0Y8TVgcisekOELHEybK4tUEmxqLrfYTs6sNQ9bKXJHt7FvNwA8YNWASljqLfOPNWA6lV83
FQh7SvkfjbBeWo5c9ikPqLE6LgnGIYpD5mzz8N7kiCAab8CImO4LW52aEcUxRcGw/3AyTs57KO5j
ykejYa83GFM+Yir3nmUEMBlO+kPOMjgk/X5/cB7yjUDIsbbOX0lzMihGgVJuUdGQqNgtnSdqj1vQ
dtosSqVOZSCkqPSpYdhDyidD0HNEFiJXJSrMVFmlfNyjT+SUOuatzoOLF6WKNhJUOlBeFEgeWZ8K
i1gjGcYu9Pu5yR9pgw3+0VNRnP9dD5gKKNTW2CfOHqyANBw1teRMvdNQBLrJHwx7MDYHQzfVpVFB
TkJniJJyz1k0Lz2usDwzVS38Uq/rjBwJO3XH7f53Yeu2UTw69Nqst6KWn+uX6BvaJ6ZNQZTza/+I
aXEiBSHWTiWkUKHuMCBVwJDL4ga3SOaoO2ebA3pnVJlT49JKZ+82l8qynQAN8z59W029cJMiTI9C
ZND/+zVbXRm/LTPO6tJn24WoSgVNDs5A11ZYJ1GTTtIP8kVLRSghfxWRRrtlIFD6LWggCiphl6Fu
MG6CgS3Df6lzzPZgHnhiQHYrNmtwNEnOzogm66O3FEs9t/fBvTDazwK1G+GotXBA6ONjGsMY1KtG
ZyF8qAj1SyC4zlaZj/wmz/oLOjt6zGXxT98gU7i5Ojs+nRX+C37t002Dgt7ug7I3zfrp2VwgjeeL
a5yUrfg3cbgd6kSKRY+TYMW0UHk46P5MJr2fF8PBojOYzGads3l/0pnNYSX9t6PBaDQezgbjvyC2
9owpwTVOGQphUZX7pior87GMBQFfKf8oOr+uIDbll+Fa6s6HdTyWjv3K4oom5Rp46ZS35T1aUJt1
sDi7l5beCXBUo/dI/60jqRW3NJ3uqnySv4RLqp8q6R0hPFtZY4pgu8pfKikQqhdAxykYB3wkJN55
oYqvFc9hlga+m6Vui9CQCFs7tNQnGvtN2lxo8SWBtYP8BGmKaeY+2fOnSncy18ofVaPifZcUsfBN
JeUvGAkMSsYv9EUbSJ2vhBU0sD8jlVYaz1JppfNytH+Xyr+fRf+vVI7Fi5MTv/X08KYTXn4u/gYA
AP//AwBQSwMEFAAGAAgAAAAhAHkelHzZAAAA/AAAAA8AAABkcnMvZG93bnJldi54bWxEj01LAzEQ
QO+C/yGM4M1mK2JlbVps8aMUPHSrBW/jZrobupmEJG23/fUGD3oc3vBm3nja204cKETjWMFwUIAg
rp023Cj4WL/cPICICVlj55gUnCjCdHJ5McZSuyOv6FClRmQJxxIVtCn5UspYt2QxDpwnzmzrgsWU
x9BIHfCY5baTt0VxLy0azhda9DRvqd5Ve6vA3828X+7Om83w61OP3unseL9W6vqqf3oEkahP/8vP
1Wz+av7gr2qhc0sxyr9v307fwegVxkRBQc7LsRmCnPwAAAD//wMAUEsBAi0AFAAGAAgAAAAhAFrj
EWb+AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEA8aFpZCMEAADDDAAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBleG1sLnhtbFBLAQIt
ABQABgAIAAAAIQB5HpR82QAAAPwAAAAPAAAAAAAAAAAAAAAAAHsGAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAQABAD1AAAAgQcAAAAAAAAQ8AgAAABdELgOvg+qEA8AEfAQAAAAAADDCwgAAAAEAAAA
CALLAA8ADfBqAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAA
AAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAA
CQQRBA8ABPAGAQAAsgQK8AgAAAAJBAAAAAoAAPMAC/DQAAAAfwCAAPsBvwAEAAQAAAHTCQAAAQEE
GAAAAgEqCAAAAwHVBQAABEEDAAAABcEwAAAAPwEAAAYAvwEAABEA/wEAABgAPwMQABgAgMMWAAAA
gcMwAAAAvwMAAAIAbwB0AGMAXwBuAGUAdwBfAGIAbAB1AGUAXwBkAHIAbwBwAHMAaABhAGQAbwB3
AAAAUABpAGMAdAB1AHIAZQAgADUANgAAAG8AdABjAF8AbgBlAHcAXwBiAGwAdQBlAF8AZAByAG8A
cABzAGgAYQBkAG8AdwAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAQDwoTSBanEA8ABPBIAAAAEgAK
8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEBAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA
BAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAA8AiBOy
AAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJAQBAAAACQ8AihN5
AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE1kAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAA
J/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAFQJ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkA
AAAPAAIrAAAAAAAAIwQVBwAAUEsDBBQABgAIAAAAIQAo12LI+QAAALsBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbJSQu27DMAxF9wL9B0FrEcnpUBSF7Qx9bH0M6QcQEm0L1QuiEiR/X9rJEHQI0Emg
JN5zyHZzCF7ssZBLsZNr1UiB0STr4tjJ7+3b6lEKqhAt+BSxk0ckuelvb9rtMSMJ7o7UyanW/KQ1
mQkDkEoZI78MqQSoXJZRZzA/MKK+b5oHbVKsGOuqzhmybz9ZoDiL4gtK/YDAHG0LafJ8+Q5U2e+y
WCtOl+L5FDObdBJy9s5A5Tn0Pto/Dqs0DM6gTWYXmKxyQeJz+R68ugDdzdG6b19wgJ2v4vXAqqft
FPT0P+p5asWdC4oml+kK4fpYZzO9rL7/BQAA//8DAFBLAwQUAAYACAAAACEAjuoq+r4AAAA4AQAA
CwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2I0IMX0Q9Ykm0bbJOQjaJ/b44WBI/D
MG9m6vY1T+JJka13CqqiBEFOe2PdoOB2PW32IDihMzh5RwrexNA261V9oQlTDvFoA4tMcaxgTCkc
pGQ90oxc+EAuO72PM6Ys4yAD6jsOJLdluZPxmwHNgik6oyB2pgJxfYfc/J/t+95qOnr9mMmlHxWS
J2vojJwoZizGgZICE/nbWIiqyPtBNrVc/G0+AAAA//8DAFBLAwQUAAYACAAAACEADec5NOYDAACC
IgAAIQAAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOyawXLaMBCG753pO3h07VCQ
jbFhMJkkHU6ZTqZJ27MwAtzIsscWacip79BLz32VvkmfpCtZgI0hYWjo0LFvTiStpW/X2n836Z89
hMy4p0kaRNxD+G0LGZT70TjgUw99vB02XGSkgvAxYRGnHlrQFJ0NXr/qxz3xcCMWjKYGmOBpj3ho
JkTcazZTf0ZDkr6NYsphbBIlIRHwYzJtjhPyFUyHrGm2Wp1mSAKO9Ppkn/XRZBL49F3kz0PKRWYk
oYwI2H46C+J0aS3ex1qc0BTMqNWFLQ3k8QLBqDrhoE967J7h+DoxCJsCJ4aMRDAPSVrkil8kd+p5
EnFxriaMSEqRMSN8Cqe9nnNfyAnSUBr7F3Sin659YdwTZag56Dc3Rs8n4ol5enRMJx9gX+mjh0y3
BRsagRuzN0UsGA8DxpQR6RN6yZLsfeIBI/3G/CwJkhtiEdMJ8cHbb8IvDSbkTNKjZGOAkmzATzcG
/FTbzvamDqb5SUPwaFYP5SeajAknyIgD4c+GJAzYwkNWGxn+jCQpVQGSuaSITbLS2Kwa297YJCuN
rV1j2xubZKWx2TW2vbFJVhpbR2ILSXLlobbtQJpD5aSxkSjkyv8qLxx8mUk4mpOz5tTF7XbNSebx
Za6UcDQnd80JWw7u1KDyoCQdDaqbA+WarhJDJblW2S9P0oHoKurauDeKxouSyM1uL9O026aNjICP
QSR7qLH8RQnqy2hguAIgtg/VwaP5zeNKTmO8tEV6o/klCCylsjz0+9vPTLTmZbN87QvLZr5LNvPG
DtnMG3vK5sw5NsbYyTsHdzodF4q1IzlnBfSgIqXonJatHS2dM4SaKVc/fIZ6SRafUMgVhLKZ08lm
5sKCY3/9yPtVJdR8YaNK0gPKn6Uf4dRPq/LMK8tEtvpksG3b0k0n6pVnvgyVbI7PclOqZywxSCds
w5e5hom7rY51sjBz9083H+HPQZbS5/iQN4W9hgw3vArQNeSWA7s/WcgFmN/z37xqgcig+Qcwt8t9
7LqmU7yUd8HcW4b87b17Gry2y37TsrrdmpfS/MXssl3+m07X2Uj6dXypfuL2KsACAWvV8bUlvlbF
QE7+x71IzGiyKgYgIq+z2kprZQbdbA89zhqX7+W9m0kiPWXZHs+ySj59wOJbMrqB9vRSHJU65xgZ
qvG8bqQXG+dZO1vvQja6sart7mgi/2RxlBu/1O5+Kd1eaglVls9mX7uooFeCubJ8dqjiUguosoB2
KNpS66eygLarVNN0oYdYX9GQsnbIUqdtFdv2lY2g7TpU0in26ysLaIfw7NhOsU9fWUArpZkXl7IL
rf95ZPAHAAD//wMAUEsBAi0AFAAGAAgAAAAhACjXYsj5AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAA
AAAAAAAqAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEADec5NOYDAACCIgAAIQAAAAAAAAAA
AAAAAAARAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAA
ADYGAAAAAAAADgQaDQAAUEsDBBQABgAIAAAAIQCCirwT+gAAABwCAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqJJd30s0g8Y5LEtao+ENAnJ33fsuFC6CC10IxBi
zpl7Va6P46AOGJPzVOlVXmiFZH3jqKv0++4pu9cqMVADgyes9AmTXtfXV+XuFDApmaZU6Z45PBiT
bI8jpNwHJHlpfRyB5Ro7E8B+QIfmtijujPXESJzxxNB1+SoLRNegeoPILzCKx7Cg8Pv5DCSAmAtY
q8czYVqi0hDC4CywRDAHan7oM9+2zmLj7X4UaT6DF9jNBDO/XGD1P+ov5wZb2A+stkfp4lx/xCH9
LdtSay6Tc/7Uu5AuGC6Xt7Rh5r+tPwEAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsA
AABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsI
hKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYw
lRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzl
RQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACK
AAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLL
rrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0
jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQU
AAYACAAAACEAhJdIX6cHAABbIgAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsWW1v2zYQ/j5g
/0HQ9y5+zwvqDq5jbwO6LYiz7eNAS7SlhqIEiU6c/vo9dyRlKbbbtA22YUsLONTp0R3vlUfy9ffb
TAV3sqzSXI/D7nedMJA6yuNUr8fhbzfzV2dhUBmhY6FyLcfhg6zC7998+81rcWESmckA3+vqQozD
xJji4uSkikAW1Xd5ITXerfIyEwaP5fokLsU9+GbqpNfpjE4ykeow0CID2/skNfLPVBup/sy1egjf
eAEzBSnaVESIVLkg9vLIV0GPv4tvu4SuyvVyqsrgTqhx2DkbdSZn4cmb1yfiwgGU2cfN+Z/DOUB8
29vjNx/ORoPTmh8DlDmAmw+nNc4BRBRBo33Zk9F0Mus6ng2QHe7zHo5OZ2/PW3gGWXx/f85N3Rog
Oxzs4TujYfds3uLPIIsf7uEvO7PubNbCM8jiR3v4weVpb+Jt2AAlKtW3e+jOtDc7GznuNWSVqx8P
wieTTncwdfAdCt6vo4hErHJtPhpTIaEy8T4v54DSgxIm1YF5KORKRIjd32UZCy1IlLiQovHGkqLq
EQlzaDHMUv3M3HcMIWunIiuctfX9dbVKI8larlKlFuZByXcVK1rlKo3nINJ3nNeyzqciwdBZt4Vb
l4K/Ccrc/JGaZJGIAkbqsoR15Vivq6DIK6Qlkw/yJqEwtLH5O+zgn7VnJczPeWzJfSIzHYrWbDjJ
11wyvKA+MXiqsP6pYwqeXyKsS5N6srQuT42jpyWtVvmgaiDW1kQCBIIKdneEykqigyoSSsZkd1vy
vFvIqn78LC6qEhFL5yPSe99HXXaSjxWu34idAz4646kfDTZ+sZN2Tmy/QtpTnNRQ7nxwRJz33td4
yUew9wwb53E6Kt1MTqWD+3F4PuwNwyASxThcoS5hmBXweqXXYSDUGkt6ZEob9p9M5sf29Yq1k6Db
8fQ9hVt1oCgrcymqxIYGv3IhoDRJsvPvDWHW51LARvoXzKJ/hmD4x2YBO7ZdK1crGZmmsxsUsp19
dKU03xhZLpL4PliqTXkt4H4KVegTp5UZh1wR6KEch2RtftUuzq5UtfolCyRpQhWJcOWWUtRnsoVz
qNZz4KfG9KDbwbmzcp+vCqf8M6nSDOP/mSq0VEot+zF5IEIDXoqA8nUc5qVJclShIkmjeYmGh2sH
oiVAdaHlOsA2gP+W8o7+2pyzPIibSteJuU7XQZliPTJJKeUVyhJH3yeYdd3aZVl6RhxRjelWhZ32
Ut5JdUM1cERrexgkCHWuJq4MMO5x/LWfXQYt19TkNPOtVUPqtsLmwN/d+dhkhlLtOswNjbd/PUW2
Vrvzsd/z537tbSpCL3Zt1sBnBYQ1ltpzl/ZfOIXPXGptxdrTuDf0k4MX9zUGsW6ICmGSgH6w/qVl
pHb97U1+jdoaYEdIzBA2iOpXtvEIqEBa4hKNkyXaYCJW1rSuuyWr+cX6WdqonQtquY+MTTN7ir8/
09h1c9YW18rF5zS2s3DL1pZ21NTw7OMUBWnlNzLsGD6MaJ4V5Mv3cPQl9mgbZU8PqgJPnAfFVRks
77GJwMZEbEzORW67KjN6m69WwZZL3IMrcFjDtiaIQOyiSQDVN9X+k2hTmR9kzp+LO1QVjt117Eci
8aNoq/2wdHFoYxC/MAl+EXrsZXFBQWfB0LYp4mPVyW6j/QRbSNtxDTsIsK/vdcz2oIwjXZ+4KPON
jtksiRTxTMe8Jx6HGqdKIVXxTMZYXCQWFxox0ohUPQUJ89iesm48bChV8DN5dJnHD/A4TrmQ7Ele
foBALHFeuPpJYyd63h0MyBX8MBie9sgjzTfL5hu9yaY5iggCQugIPG2j7R6mxvoyyjM48Z1eFBFB
aS5koJvtH6Is3IprEFu/5LxLZoCPHyi1w3KIWzWIiapsd0jjWK6uoFwmynccPxhc8yDVMU6ZeLjb
CQSA34jl4oNTmJQ0dDyGYz/xTr8tb3lMRwYT3j4sRQX/8JHH7nWCzSYO8q42OmIBPCfSkgZVEV2h
wvKpm6tF1h1ocmvEW5+JO2xd24po93aysicRDZ4NnHu73GA/ebPlmFluFh/qIZ3Y1A+/INJcWC19
DsIa1zDe7SZLs/x9yror3klL/eq3BbbRMFQPK6jLy8BCNj50KlOmtygiOl/wyOWVDWoc6mRCpR/k
j8yXLImNOtDgVmVmqqTgVspaj351To2ItxYb8yO7tiMp2EwChMqRw6qgSE2UzEWWKhS0/gAzT0RZ
SfannYE1DoeeDTIe7mIPEVqXVKUvvUdfauvXbsePOPaltlKhfamtL7UVt0b//drqSiqq7H4ri56h
FFj0Fryjw2pGa0WbSJTII47dl9me5NB92Rz3VvV24xnuy1q3N+5C7eB9WfNe7R++L5tMJpfTvjvi
sI01X6rZ4YDX5+aZ2eWE/rfwDLL4v/2+rHnj+Wz3ZQipn0URLNfdcQg3omHeYoSLUnRI6x7RMDJb
jOA8NMf2qhPbLDvwFLy3lBrT95S+xww8Bc2JM6Gn4MzbUkaeMsIBEN0DosGnP2Hgr/xwMO6uCJ1j
9tNkn/LJxHm5aKbotz54uWh+ykVzM3E4XThxOF04cThdOHE4raxpkVpu4AP+X5Q4WJnamcPrEKh8
FvPmLwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVs
cy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs
7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYk
UiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04Goln
Lx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQCCirwT+gAA
ABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
AGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFAIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54
bWxQSwECLQAUAAYACAAAACEAhJdIX6cHAABbIgAAFgAAAAAAAAAAAAAAAADRAgAAdGhlbWUvdGhl
bWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAAKwK
AAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAA
pwsAAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRh
bG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv
cm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJs
dDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQz
PSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJh
Y2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAADSsEAAAAgCYfmgAA
CyvyAwAAUEsDBBQABgAIAAAAIQBCPNB49gAAAKsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSQ
TUvEMBCG74L/IeQqTaoHEWm7Bz/Ai3pYf0BIpm0wX2Rml91/77S7IHhY8BRC8r7PM9NtDjGIPVT0
OfXyVrVSQLLZ+TT18mv72jxIgWSSMyEn6OURUG6G66tueyyAgtMJezkTlUet0c4QDapcIPHLmGs0
xNc66WLst5lA37XtvbY5ESRqaOmQQ/fBAtU7EJ+m0ruJzNGuoiYf2eMtjVlxnRRPp9yC7qUpJXhr
iMX1Prk/0CaPo7fgst1FRqlSAflcv8egfptvlmY9dM8wml0g8XJgtdM2KgT8H/Q8peLkSsLZF7xA
uDzV2Uyvqx5+AAAA//8DAFBLAwQUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAF9yZWxzLy5yZWxz
hI/BCsIwEETvgv8Q9m5TPYhIUy8i9Cr1A0KybYPNJmSj6N+bYwXB4+wwb3aa08vP4omJXSAF26oG
gWSCdTQquPWXzQEEZ01Wz4FQwRsZTu161Vxx1rmEeHKRRaEQK5hyjkcp2UzoNVchIhVnCMnrXGQa
ZdTmrkeUu7rey7RkQPvFFJ1VkDq7BdG/Y2n+zw7D4Ayeg3l4pPyjQmbny7COhlCoOo2YFdjEi3tV
/gXZNvJrX/sBAAD//wMAUEsDBBQABgAIAAAAIQBHKtdt6AAAAIUBAAASAAAAZHJzL3RpbWluZ0lu
Zm8ueG1sjJAxbsMwDEX3Ar2DwL2R26EoDNtZgk6ZCvcAgkTHBCxKkJi0uX3p1B26ZSIJ8j98/m7/
HRdzwVIpcQ/PuwYMsk+B+NTD5/j+9AamiuPglsTYwxUr7IfHhy63QlGvjAK4tq6HWSS31lY/Y3R1
lzKy7qZUohMdy8mG4r5UEhf70jSvNjpi2PTlHn2aJvJ4SP4ckeUXUnBxoubrTLn+0fI9tFywKuam
/mdpWJ/jY5W1ya6sxY9sKGhCYMJZzRIHnIhJEIxyxBXpgVGTBMMp4HjNmpbEj5QE7NDZjaR1Q6/d
LcHhBwAA//8DAFBLAQItABQABgAIAAAAIQBCPNB49gAAAKsBAAATAAAAAAAAAAAAAAAAAAAAAABb
Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAAAAAAAAAA
AAAAJwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEcq123oAAAAhQEAABIAAAAAAAAAAAAA
AAAACgIAAGRycy90aW1pbmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAAAiAwAAAACgAB4E+AUAAFBL
AwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI
/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW0
8UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8
rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KD
y7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXf
QF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOE
j8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQg
yGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2
MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9j
Iaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQA9yYcCxQIAADYIAAAhAAAAZHJzL3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDEueG1stFVNbxoxEL1X6n+wfE8WFliiFRC1tOklHyiQ3l2vyVrx
2pbtbKG/vmN7TRRKJQTtZT/smTcz783Yk+tNI1DLjOVKTnH/socRk1RVXD5P8dPq5uIKI+uIrIhQ
kk3xlll8Pfv4YaJLK6pbslWvDgGGtCWZ4to5XWaZpTVriL1UmknYWyvTEAe/5jmrDPkJ2I3I8l6v
yBrCJe78zTH+ar3mlH1R9LVh0kUQwwRxkL+tubYJTR+Dpg2zABO836fkthqqBWLcijvBPslqtcEo
2JsWdvp4BhTQpaiQJA0sfAdTTolAwR4BY2jFNi6YWb0yjHkH2X4zeqkXJnjftwuDeOXROhScdRud
WfiVYAYf2Z77c0Ii5WZtmtmElMAO2kwxiLj1T3AiJSSBaFykb6u0fjhgS+uvB6yzFAAy2AUF/XWs
6M9y8lTOHin9XXnRhwDGraIvFkkFBXseYp30vk2ovngfR9coauK8Hhgpw0G5KFHnFU0DTcnbBqpT
/juCimIwGo8iTYM8z4vBe67yXnE16g8w8oyNimExHoxDkIQEQSK0Lt3ms6q2nukf8AZBfdNMMSO+
+AgrrFu6rWBBD2CNlFASPMBYED9oTF48LTEiwt2G/1/1xfweBq9xc8EIDGanpZvNBacvyCnEKu7Q
HbGOGRQogTGFEBMQy0GvdCGYrBbEkMddpA55FylG9qyTEjKDulI9oUTP/N91BoL2m99320IQymol
Kkgt9wzAoCRBT5LcE7unOIwN9HTql+OVH+ZXRT4K83FI+KI3Go79/v8SHvoRiVbsFP3HjeDpD31g
3zVCFDcoDI+UQmDvjF5cMqrgmBOsZeKIcKEVzgi3qrk5Plo30Sfze6NejauPLm4YJ/30cHx9MBqc
32ePcJjkeAPBp7+zwkgKc0f0QxtShtsaDpJ5WNJwP3fH8JuJx0j3/ew3AAAA//8DAFBLAQItABQA
BgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAD3JhwLFAgAANggAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxh
eW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAAZBQAAAACQAB4ErwUAAFBLAwQU
AAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOU
LWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL
33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusb
qYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OE
pfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3
yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EK
wjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlv
rOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+
YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi
7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQCea64LfAIAAFYHAAAhAAAAZHJzL3NsaWRlTGF5
b3V0cy9zbGlkZUxheW91dDEueG1srFXLbtswELwX6D8QvDtykqIoBNsB6ja95GHUTu9biraEUCRB
Mqrdr++QlBykdQG3zkUPand2Z4ZLTa62rWKddL4xesrPz8acSS1M1ejNlD+srkcfOPOBdEXKaDnl
O+n51eztm4ktvapuaGeeAgOG9iVNeR2CLYvCi1q25M+MlRrf1sa1FPDqNkXl6AewW1VcjMfvi5Ya
zft8d0y+Wa8bIT8Z8dRKHTKIk4oC+vd1Y/2AZo9Bs056wKTsly2FnQVbCBNWW85SnOuwcs5noC6W
qmKaWiysmqAkg0DsG4IbQYqt5DakMG9XTsqYoLsvzi7twqXsu27hWFNFtB6FF/2HPiy9aoThofgt
fTMgUbldu3Y2oRKqsO2Uw7xdvCKJSjTBRF4Uz6uivj8QK+rPB6KLoQA62BeF7zYz+pPOxUAni3K+
Z5VDCak3Rjx6pg14RvqZnrjrBrDIOcLbmmULQtS3j8sfkx5DvIemSayw/WiqXST+Hfe0SKXyYRl2
SiZB0DaVAMcF8iuKO1zq0cOSM1LhJr3/rEfzO+z4NsyVJExEL2aYzVUjHlkwTFZNYLfkg3QsNYf5
QIkJ1Aowqy8hdbUgR1/3lXrkfaVcOfKnEp2B1MAAj1nivwt9OQj9Ys+xhSIha6MqtHbxGuJHKTkz
rsGQ5Gng2LfYVINz/+JIPGaAIik2Hbs75A/sZKpTe+Ff2a84FMku/8Kv7EEyApehhUTyhC2zlMLg
XFCyk+qIcsmxE8qt6sYdX+0yO/Df+l6bJxfqo8m9O7Vcsz5YDefcyZOWBi6f1HiMZ3s6jJW7JXvf
JYXwN8O8z9OSxf8rzi1Cn0MixvA/nP0CAAD//wMAUEsBAi0AFAAGAAgAAAAhAE2O8/z9AAAAuwEA
ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA4
3L4AAAA4AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAnmuu
C3wCAABWBwAAIQAAAAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEu
eG1sUEsFBgAAAAADAAMAyQAAANAEAAAAAIAAHgSECAAAUEsDBBQABgAIAAAAIQBNjvP8/QAAALsB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5QtatJhgRBqOwseKwQshg+wEreN
yEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vfd0/VLWeUwWuwwWPLZyS+7S4v
mt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xupgs/oc5WXHbxrHrCHyWb2eCjl
o5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl8zfgpHstr0lGI3uDlF/AFRtS
J5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI9fXdJwAAAP//AwBQSwMEFAAG
AAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4
Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxt
s17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA
3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwME
FAAGAAgAAAAhAKTtb5JRBQAA7xAAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54
bWysWNtu4zYQfS/QfyD0WmQd+R4jzmLjNm0Bb9ZYe9FnWqIiNRSpkpTj5Os7w4sludnC8PrFoajh
IWfmzBwqtx/3JSc7pnQhxTyKP1xHhIlEpoV4mkffNg9X04hoQ0VKuRRsHr0yHX28+/mn22qmebqk
r7I2BDCEntF5lBtTzXo9neSspPqDrJiAd5lUJTXwqJ56qaIvgF3yXv/6etwraSEiv16dsl5mWZGw
X2VSl0wYB6IYpwbOr/Oi0gGtOgWtUkwDjF3dPZJ5rcDbqkg2+4hYM7WDiTi6A8+TNU+JoCVMrIrE
1IqRl8LkZEErPIe10dVGMYbWYve7qtbVStmlj7uVIkWKUB4i6vkX3sw+CjCDQe9o+VNAorN9psq7
WzqDiJD9PILEveIvLKIztjckcZNJM5vkX96xTfLf3rHuhQ3gBIdNIeeV8+i/7vSDO5vCcEbig1fO
lMLSpUyeNRES/ET3nXvJ4y6Aoc8IX+XEhd8glLdzL208gr22MQ0HPUQintz0+1PgLXg+nALLro+i
MhpOx0OYJBib0Xg8GUztJgEJNnHQ1czs72X6iiHdwl/IHBVJLoGpW1xBZ1ybtXnlkGcY73gMJyKU
P0EpcWABnaUs+wpT+m0eAd9hy23w/GAPSe7iQIjpDAIBP7CUU6xEJq6+rSOANkv7/JZfLR6hMkuz
4IzCdt5Fc7fgRfJMjCQsLQz5TLVhithAQh3DSXE3Y/e0WzCRrqiieEi3k0c+7OR2xlzRGZwMYhNi
YsOE+fo+KQaBFKFMVpwmLJc8hUP1MYRQTIEAZ1EEKjSCcgKuB0KdR5Rx3J9MRi6poXo6PBnGMZLp
ZKJATzXQgqR6i8iLosB4/U9NFYsI/1NoW68mDFQYbMNA1OVCctskAuMMpN+Sb2GAf8heWVbULMW6
StAQCVMpbTb7v6iqoGdp2N+AL49yndOKWQO6W2rjk3mwtbl1/EaQ9zhdUrW0mxYihYaJQzTd1o+g
CrYSWkwfANV9nHxNWNgd72N5OKjhaIJW5BS8fhN3wEMQjzdo8G7ioS3pk/DQ0gUB8BDE4w0bvHgw
ibFxnHZALO0DIKJ4wFELcAo96TxARPGA4wYQehwc8KwTIooHnLQAJ0ObuTNcRhQPOG0AEe30pHRi
iCge8KYFOB5NzkwKoliet9ltO20DD7EEcn61PAdiHPH90NcJUH1Dt2vo6YF1yjhrRpfiXj3blZkU
5pOVgi3VWPZwyxDN6xz6OFyEVrVIDuXEsZbRbV0lq8SQHcUWAIFp6NWyuGfZsS1E+2AKGI3Fpwx6
fhc3MBbs/NttveBqs7flvK3Xb80R7BmQ4VjyD+DYwepQ/4ZuXWsJoufqweexJTPPdVmU8u/Chbmt
ZkeaY1XTMdKqJnFL6nkkoOngtVQVz3AFE3JtRxF5ZspKIUmw33or7I6QWYGXUF68sT/sI+aEF3ij
te9WSsrMjtuSiv5ygb9CPhSc+xK3M1ryIsVJG1e88DKInkuZ2TsxgoC3rViWscSEKNVL4aNYI4wf
W5bY608GSjmPfinFFTcu9IwevWDUvUj00YtE+3bUxP08AR8GAd+gKLbVe4A7/Kh6o+hAIqGScsoz
L+T2XgCXi/OEfDSA+5y70DX34I6ST6/h/uc2OeHGZ0nfbhpe0ryOndh/447k4DXRcutsSYw7Evvj
kogF7ilzGUm8aeNdQBE7eBcQxA7eBfSwg3cBOezgXUANO3j/L4Ze+izxLU0v9xmCTcR+hejOZ8j3
Pi3sF4b7jIYhfnXblsPVZ1p92dmzwb8Z4AMHOi9MVaCn2KLBtDFBjPCPirt/AQAA//8DAFBLAQIt
ABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAKTtb5JRBQAA7xAAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlk
ZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAClBwAAAABwAB4ENgcAAFBL
AwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI
/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW0
8UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8
rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KD
y7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXf
QF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOE
j8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQg
yGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2
MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9j
Iaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAIAAAAIQABkvB/AwQAAFsOAAAhAAAAZHJzL3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDEueG1szFddk9o2FH3vTP6Dxu8bsI2B9SxkpqTpy2azE8gPELZY
u5Flj6wlkF/fI8libZcGd2lm8gJGHJ37oXPvle/eHQpO9kzWeSkWnv927BEmkjLNxdPC+7L5cDP3
SK2oSCkvBVt4R1Z775Zvfrur4pqn9/RYPisCDlHHdOFlSlXxaFQnGSto/basmMB/u1IWVOGnfBql
kn4Dd8FHwXg8HRU0F16zXw7ZX+52ecLel8lzwYSyJJJxquB/neVV7diqIWyVZDVozO6uS+pYIdpy
+9fm4BEDk3ss+N4SkSdrnhJBCyysSqHAQL7lKiMrWmk/DKauNpIxjRb7P2W1rh6l2fqwf5QkTzVV
Q+GNmj8amPkpAMPDqLf9yTHR+LCTxfKOxsgIOSw8HNxRf2ITjdlBkcQuJi+rSfbpDDbJ/jiDHjkD
8OBkFGde2Yj+GU7gwtnkijPin6KyUIqt92XytSaiRJw6fBte8rB3ZDpmTV9lxKZfaaoGZ/80+XD4
2uTUOXrKxCSaQVsmHcEsHEe9nITj8Tz0Q4/ozPj+NGgQ7YgtcxWrw+9letQZ3eIbB0dFkpUQ6tbm
mddqrY4cx0xjvuc+HCKUP6GSOERA45TtPmOp/r7w4BJ82rrAT3icMZ5bPMgwjZEHfGArp7oQmbj5
svZAre7N7+/ZzeoBhVmoFWcU5poY1XLF8+QrUSVhaa7IR1orJonJI8oYnmprytg0JphIH6mk2klr
qWE+WbKW9VHRGJ4h/y4neLRq+HdNIMndKnnkNGFZyVM4FVynkDyFvp2IhosjjGaRPnBdLOfUEfm+
D4RVRzSPQh9SseHbgjNhW526TDh1mNJrH2UjiZ4SQq1OS9kC4DFo9NxWzbyNdQBgwzPYSRvrAMBO
zmC1Gk8+OACw0SWsAwA7vYR1AGBnl7AOAOz8EtYBgL29hLWAczWGnQQMp+L5n2tO92BTcnWn5mwd
mWLCh3PBCPmKsl+zpBQp4WzP+ABzpvauMLfJcjncmimgK6x9KJ8lpuvQ4CZa2NeYy3dnrWGs/tRu
OXHdcqOl026VJoG4drhR+aphqicYRgZGUUb5zsMdBA3UCMEMVd3SzMPaVJRu7nrpR9PVn4SRb/vI
y5WjM14n01t/PL26gZKCyntzxclFituWftSubZ8fcCk1p93qmX6nD+qZrLGodN0+Gyp3RxjE1+nX
vR7c8N36E22VDOLr9N5en274/HDmT4cS3v6glzu+eTDXo2SQgx2+Xr9v+IJgDvdew9ebCY5vNjFj
8b/715sbDZ8mG3wgnXh7s8XxTaPZ687j15w/qHR3ezEXGlP77pUFK/oNx7yVcPmRVp/2poTwSofb
5MosVXiJ0/cHQF8gmsq9FC7/BgAA//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAA
AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAA
OAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAGS8H8DBAAA
Ww4AACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBL
BQYAAAAAAwADAMkAAABXBgAAAABgAB4EdQQAAFBLAwQUAAYACAAAACEATY7z/P0AAAC7AQAAEwAA
AFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsLHisELIYPsBK3jchLcTqa
/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFrsMFjy2ckvu0uL5rdHJFY
UXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28ax6wh8lm9ngo5aOThJY4
uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9JRiN7g5RfwBUbUieSZEvx
GeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD//wMAUEsDBBQABgAIAAAA
IQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYggeBL9gCXZ
tsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwMbbNe1Vca
MeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOpQNzmkJv/
s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsDBBQABgAI
AAAAIQD/7vRhQgEAAHACAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sjFLL
TsMwELwj8Q+W79QtB4SiJpV4XoBWavmAxXGaCL+0dkPy92zcBATqoRdrPZ4Z73i9XHVGs1ZhaJzN
+WI250xZ6crG7nP+vnu6uuUsRLAlaGdVznsV+Kq4vFj6LOjyBXp3iIw8bMgg53WMPhMiyFoZCDPn
laWzyqGBSFvcixLhi7yNFtfz+Y0w0Fg+6vEcvauqRqoHJw9G2Xg0QaUhUv+hbnyY3Pw5bh5VIJuk
/ttS7D2l/dBgPzlLNGwJWPCCksutLpkFQ8BdYgxg8DtUaqhs+4x+6zeYuG/tBllTDtpRw8V4MNLS
1hKNCvFPvp+cIOsqNMUSMnoC1uWcJtUPK4kgU11k8gjKX1TW6xNcWT+eYIvpAurg51Kqp1hUDrFT
5xpfwa9bygcZzTkqvE+Qp8keM8hfyuAx/ZTiGwAA//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAA
ALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
AP/u9GFCAQAAcAIAACEAAAAAAAAAAAAAAAAAFQIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlv
dXQxLnhtbFBLBQYAAAAAAwADAMkAAACWAwAAAABQAB4EHwUAAFBLAwQUAAYACAAAACEATY7z/P0A
AAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOxDAMRfdI/EOULWrSYYEQajsLHisELIYP
sBK3jchLcTqa/j1pZ5AADawsP67PtZvtwVm2x0Qm+JZvRM0ZehW08UPL33dP1S1nlMFrsMFjy2ck
vu0uL5rdHJFYUXtq+ZhzvJOS1IgOSISIvnT6kBzkkqZBRlAfMKC8rusbqYLP6HOVlx28ax6wh8lm
9ngo5aOThJY4uz8OLqyWQ4zWKMjFqdx7/YtSnQiiKNcZGk2kq2KDy7OEpfM34KR7La9JRiN7g5Rf
wBUbUieSZEvxGeYw5R/JRvy/9ozv0PdGoQ5qcuUnIiakEtcTnBXfQF+3yPX13ScAAAD//wMAUEsD
BBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGm
vYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9I
wUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwU
xLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMA
UEsDBBQABgAIAAAAIQBz0UX17AEAAOIDAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91
dDEueG1sjFNNb9swDL0P2H8QdE+d9DAMRuwCyz4uaRIs6Q/gZCY2KkuCxHr2fv0o2U63todeLIl6
fOR7ptZ3fatFhz401hRydbOUAo2yVWMuhXw4fV98liIQmAq0NVjIAYO8Kz9+WLs86GoLg30iwRwm
5FDImsjlWRZUjS2EG+vQ8N3Z+haIj/6SVR5+M3ers9vl8lPWQmPklO/fk2/P50bhV6ueWjQ0knjU
QNx/qBsXZjb3HjbnMTBNyv6/JRocq6WGNO6NHqRIUN9xcCVLVq+OuhIGWg6cIkokWLwJ7uQR4850
P7w7uoNPCbvu4EVTRYIpUWbTxQRLR8Mw3mQv0i8zE+T92bflGnL2QvSF5F82xC8nQY49CTUG1XNU
1fs3sKr+9gY6mwtwB9eiUdWo6LWc21nO6MPqqmqEAqdurXoMwljWGeWP8tSum8mi5kjvavGP8RNu
vEx+zPjAniazqP9iqyEK/8VrCkKuAx1p0JgM4bYhZ3L+sP0a4lyjWTwcpQBN23T+Uy82O57zljYa
gd/BZCaVG92oR0FWYNWQuIdA6EWaCn4VXGLNbhH/rKkEmuoAHn5eK03M10pj5agfcu6MRc0KeBst
Tss4P7yNQ5ZGRPt7cPsu6eCXxV1sUsjxW5rcfIZEjvltln8BAAD//wMAUEsBAi0AFAAGAAgAAAAh
AE2O8/z9AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU
AAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAU
AAYACAAAACEAc9FF9ewBAADiAwAAIQAAAAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRlTGF5b3V0cy9z
bGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAAAEAEAAAAAEAAHgTLBwAAUEsDBBQABgAIAAAA
IQBNjvP8/QAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8Q5QtatJhgRBq
OwseKwQshg+wEreNyEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTxQ8vfd0/VLWeU
wWuwwWPLZyS+7S4vmt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu6xupgs/oc5WX
HbxrHrCHyWb2eCjlo5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPLs4Sl8zfgpHst
r0lGI3uDlF/AFRtSJ5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9AX7fI9fXdJwAA
AP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/
EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fN
HgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZ
vxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3
+QAAAP//AwBQSwMEFAAGAAgAAAAhAAkaYlmYBAAAmRgAACEAAABkcnMvc2xpZGVMYXlvdXRzL3Ns
aWRlTGF5b3V0MS54bWzsWW2P4jYQ/l6p/8HK9z3ICxCihZNKe/2yt7sq3A/wJmaTXhKnjpeF+/U3
M7EhsHBKs61UVXwBkzx+PDOeeTwJtx+3Rc42QtWZLGeO+2HoMFHGMsnK55nzZfXpJnRYrXmZ8FyW
YubsRO18nP/8020V1Xlyx3fyRTPgKOuIz5xU6yoaDOo4FQWvP8hKlHBvLVXBNfxUz4NE8VfgLvKB
NxyOBwXPSsfMV13my/U6i8WvMn4pRKkbEiVyrsH+Os2q2rJVXdgqJWqgodnHJuldBd7qV7narl7l
w9OfDiOw2sBl15mD//EyT1jJC7iwkEXFVVbLku7U1UoJgZhy87uqltWjogn3m0fFsgQJzERnYG4Y
GP0sAQaDwcn0Z8vEo+1aFfNbHkE02HbmwKbt8BMm8UhsNYubi/Hhapw+nMHG6W9n0AO7AFiwXxT2
u2o8euuOZ91ZZToXzN171UA5TL2T8dealRL8RPcb9+L7jSVDn5G+SpkJPVIZXHOT4mHxNcXUGrqP
RDCaQF5ROLxJMPbD45iEnjcd432MjOsG/hB+oC2WCNZomKtIb3+RyQ4j+gTftCM8ymu91Lsc9hbG
m9w1ViRi/UezZ63LQNqGQ/R4BD7CB2RBzrHARHnzZekwnus7+v0tvVncQ8EVepELDgVp9lTPF3kW
f2VaMpFkmn3mtRaKaQp3jQahC5ocoSVEmTxyxcEos5Jh3q/UrNy4DpaB39ZfCgFuxeX99vf7jcn2
mPNYpDJPwCIPowmlYTe219ZjvB2oE0himym9MsAd+SPX9Y9TIBgGQzcEVcMUGPvTyZhs7pIBjJdx
KkGmnhrK9u6aZGAFV3dUkFmZgLLgkFLo5R7kE2LDoyZXWP1t5ngB5uKTdbOVOzT0ILsMoc3rTqyY
1CesSIWLg5n+gXXqBmRBF1Y3fMuKVIY1OLC6/sSlIutES8jjECCXoR21aEMvJBv60iKXoR0faD0v
BBMgYH1pkcvQTlq0k8AnJepLi1yGNjzQImf3LTsTW+QytNMW7Xg0edeWIRepT7smSPFwEci6vZTR
6v+cAqIAkQDWRwoI5fy3VS2wqraQpYbaPRI2UpH+wobVnvJ8bWStkRw83ylsOFhSBO3xY8+jsweb
OwnCyegHsuZPRy4UCyK66BrJUnvj3pxsB7VqKFsAGFpxaSvb4WBtAWBoJaOFJWXZ81oAYK0OtLGY
pXusBQDWFvdFrAUA1lbsRawFANaW4UWsBQDW1tZFrAUAtimYo9OARHPv23+zoqis4MMWNZ3P72hr
liKWZcJysRH5mQI+XY7q5h3LrdJMdV/NdA69FeuTfFE67exc0FR0/+Wy9dnV4JHgX+0GR1Y3V6fd
IHnUXzSbB4GmG0QB/euFK2h7jYbS7tAzQWcNHQejoQfmYvN/oTd0J6Cs195w5lx7Q+jPr73hzPGv
vSE8KFqNO9cbUivWX+beShvpZm9p8y70hwdpu/aHGPPjfuvaH3Z85/TDJ67Thu3aHzqX3+n9j/pD
emnYvPSGIb4Zp9eAufrMq4cNtbTwhwA0bwu6VMFfAPikA9ADBDnsXwrz7wAAAP//AwBQSwECLQAU
AAYACAAAACEATY7z/P0AAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht
bFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVs
c1BLAQItABQABgAIAAAAIQAJGmJZmAQAAJkYAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVM
YXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAA7AYAAAAAMAAeBGoGAABQSwME
FAAGAAgAAAAhAE2O8/z9AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsQwDEX3SPxD
lC1q0mGBEGo7Cx4rBCyGD7ASt43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdEJviWb0TNGXoVtPFD
y993T9UtZ5TBa7DBY8tnJL7tLi+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc5JKmQUZQHzCgvK7r
G6mCz+hzlZcdvGsesIfJZvZ4KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0IoijXGRpNpKtig8uz
hKXzN+Ckey2vSUYje4OUX8AVG1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLlJyImpBLXE5wV30Bf
t8j19d0nAAAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/B
CsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhp
b6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKg
fmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGq
Iu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEAACYRaDcDAABPDgAAIQAAAGRycy9zbGlkZUxh
eW91dHMvc2xpZGVMYXlvdXQxLnhtbOyXzXLaMBCA753pO2h8T2yMoa4HyExp00t+mEAeQLFF7EaW
PJLiQJ6+u7JFgJBCh/bGBWTp0652tbuSBheLkpOaKV1IMfQ654FHmEhlVojHoXc/uzyLPaINFRnl
UrCht2Tauxh9/jSoEs2zK7qUz4aADKETOvRyY6rE93Was5Lqc1kxAWNzqUpq4FM9+pmiLyC75H4Y
BH2/pIXw2vnqkPlyPi9S9l2mzyUTphGiGKcG1q/zotJOWnWItEoxDWLs7M0lmWUF1poXefvwyyOW
UzX0dLwRmJ5OeUYELaFj9iLJWAoDYuyQrmaKMYRE/VNV02qi7IybeqJIkaGEdqbntwMtZj8FYNDw
t6Y/Okk0WcxVORrQBDxBFkMPNmyJvzCJJmxhSNp0pm+9aX67g03zHzto3ymAFayUwl5XjUXvzQmd
ObPCcEY6K6salMLUK5k+aSIk2InmN+alN7UThjaj+ConrdtRVMs1g9YfjtfgU+sss/gmsyUa/gD/
tpMmXJupWXJmHQLLpgkIhx9wP6cY1Uyc3U89Qrm5st+v+dn4BqK8NGPOKGRB60wzGvMifSJGEpYV
hlxTbZgixtqpUcUAvGVgs1oVTGQTqujdSlMreaWp0Yz20wRWBkY5C6DZuPhjR3edo9toIxNOU5ZL
nsGiwuPcrl8hWyifexChED5ujz7wPbpzKwqjMO6HPRuKcRz2e1vxGAX9IMZxjMpeEPe7DbEebbir
GAXOJTs3FVXzmncsS5OMzdHbuPwwDqxSELkGQDPcwUbrrAOA7e5gg3XWAcBG79nOxhocAGxvH+sA
YPv7WAcA+2Uf6wBg432sA4D9uo9tAPR1m224MTbZYCYBCass+sfJhxXO5p7eSL4mobaXYOP4iPyf
slSKjHBWM36AOpuER6ib5YU6XFsXU/4IbZfyWZn8YOOiY9UV853a4ND6r2Uz+lPZtD6E49ydRX95
Wm2VTbv/9qTCSvbuyNpVNvtRJ4ZSiEf4B3UzjDpQ+U9109X5zRp7qpsHXlpOddOdS6e6aWsTXjTt
rbN5rkATHzX2RcLVNa1ua3tywzMOLr1j21XBww0vr4C+ISjDPQRHvwEAAP//AwBQSwECLQAUAAYA
CAAAACEATY7z/P0AAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL
AQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BL
AQItABQABgAIAAAAIQAAJhFoNwMAAE8OAAAhAAAAAAAAAAAAAAAAABUCAABkcnMvc2xpZGVMYXlv
dXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAiwUAAAAAIAAeBHEGAABQSwMEFAAG
AAgAAAAhAE2O8/z9AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsQwDEX3SPxDlC1q
0mGBEGo7Cx4rBCyGD7ASt43IS3E6mv49aWeQAA2sLD+uz7Wb7cFZtsdEJviWb0TNGXoVtPFDy993
T9UtZ5TBa7DBY8tnJL7tLi+a3RyRWFF7avmYc7yTktSIDkiEiL50+pAc5JKmQUZQHzCgvK7rG6mC
z+hzlZcdvGsesIfJZvZ4KOWjk4SWOLs/Di6slkOM1ijIxance/2LUp0IoijXGRpNpKtig8uzhKXz
N+Ckey2vSUYje4OUX8AVG1InkmRL8RnmMOUfyUb8v/aM79D3RqEOanLlJyImpBLXE5wV30Bft8j1
9d0nAAAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIw
EETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zr
Fdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBP
cluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H
2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA5KZS/D4DAAAwCQAAIQAAAGRycy9zbGlkZUxheW91
dHMvc2xpZGVMYXlvdXQxLnhtbKyWW2+bMBTH3yftO1i8twFyIUVNKq27PXRptbQfwDVOQDUG2W6W
9NPvfwzk0qVSFO0lMfbx79wPXN+sS8VW0tii0pMgugwDJrWoskIvJ8HT4/eLccCs4zrjqtJyEmyk
DW6mnz9d16lV2R3fVK+OgaFtyidB7lyd9npW5LLk9rKqpcbZojIld3g0y15m+B+wS9WLw3DUK3mh
g/a+OeV+tVgUQn6txGsptWsgRiruYL/Ni9p2tPoUWm2kBcbfPjTJbWp4a6X4KXkWMC9oVtiKgil8
F3OVMc1LbMylIOWMBKXxp7Z+NFKSnF79MPW8fjD+0mz1YFiREaS9HPTag1bMP2qIYdF7d33ZkXi6
Xphyes1TRIOtJwGStqFfXOKpXDsmmk2x2xX5/RFZkX87It3rFMCCrVLku248+teduHPnsXBKsmjr
VSPKcfWuEi+W6Qp+kvuNe2K26mDkM+HrnDWhd4Rq5ZpDH49O3vqYdoZuI5HEcT/q+3AMBuHoKnwX
lCRJ4gE2GYUm6o/iMBl6JR0JShp0nbr1lyrbUEif8e9TwlNl3dxtFJKL9UpFMINxtUTvKKSep5lc
/MaWfZsE0ANFzz7bgsNtrlSrq72JHB8SEWGeIg74AURxakKpL57mAZS4O//8ll/cztCUpbtVkkNx
66Kb3qpCvDBXMZkVjv3i1knDfBzRwrCZtDmv06uQOnvghpO5jaaWvNXUaKZU8RSWITRdSHyUKF0f
1wSS0PTHIxXkg+JC5pVCh7CYgoAW6pJ/VnlQSgL0Egq9q6azqiS+CkcJKuagdQ6rZBiG0Tg5tUoY
1yKvMMueG+axgim5ufNdW+gM44eWlPPn1xlmrLdkr4wwJ32GqVSagiNZLGOqvQY1GCYQQzxO4EXj
fR5BWl5/x7uK0D2n8kb7PIK0vMGOF/WTiMROM5BUN1UHL4nSAod7wHE8Jj/OABKlBY52wDgew8Cz
gERpgckeMBn0T8/JgctEaYHjHZBopyflAEiUFni1BxwNkzOTQpTjw4vwyNp2Knm9/2+Y0Szxs8we
DLOPBpSfU827GEt6afvJo8wvXt+vvG34TsGYvPVbNb5MqPAguhMhRvelM/0LAAD//wMAUEsBAi0A
FAAGAAgAAAAhAE2O8/z9AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEA5KZS/D4DAAAwCQAAIQAAAAAAAAAAAAAAAAAVAgAAZHJzL3NsaWRl
TGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAAAJIFAAAAABAAHgSTBQAAUEsD
BBQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07EMAxF90j8
Q5QtatJhgRBqOwseKwQshg+wEreNyEtxOpr+PWlnkAANrCw/rs+1m+3BWbbHRCb4lm9EzRl6FbTx
Q8vfd0/VLWeUwWuwwWPLZyS+7S4vmt0ckVhRe2r5mHO8k5LUiA5IhIi+dPqQHOSSpkFGUB8woLyu
6xupgs/oc5WXHbxrHrCHyWb2eCjlo5OElji7Pw4urJZDjNYoyMWp3Hv9i1KdCKIo1xkaTaSrYoPL
s4Sl8zfgpHstr0lGI3uDlF/AFRtSJ5JkS/EZ5jDlH8lG/L/2jO/Q90ahDmpy5SciJqQS1xOcFd9A
X7fI9fXdJwAAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SP
wQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDI
aW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYy
oH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2Mh
qiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhABHQsehgAgAAHwcAACEAAABkcnMvc2xpZGVM
YXlvdXRzL3NsaWRlTGF5b3V0MS54bWysVcFu2zAMvQ/YPwi6p07SYRiMJAWWrbukbbCkH8DKTOxV
lgRJ8eJ9/SjJTtEuAwK4F9uSyUe+R1Ka3RxryRq0rtJqzidXY85QCV1Uaj/nj9vb0RfOnAdVgNQK
57xFx28WHz/MTO5ksYJWHzwjDOVymPPSe5NnmRMl1uCutEFF/3ba1uBpafdZYeE3Ydcym47Hn7Ma
KsU7f3uJv97tKoHftDjUqHwCsSjBU/6urIzr0cwlaMaiI5jo/Tol3xpiq59+cRaNbEPLCV8Qb7GR
BVNQ08a28hIZqcOWWnlCigbObC1iMFXND2s2Zm2j332ztqwqAk7nz7PuR2cWl4rM6CN7477vkSA/
7my9mEFOYrDjnFPN2vAkJ8jx6JlIm+JlV5QPZ2xF+f2MddYHoAxOQancJjH6l860p5PkmJxYJVMg
15UWz44pTTwD/URP3Dc9WOAc4E3JkvI+KNvZpZ9Rj97ekaZRLH/8qos2EH+id9yEXDq/8a3EKAil
DTmB04PklxAaG9XoccMZSL+K6z/laHlPjV77pUSgQejE9IulrMQz85phUXl2B86jZTE5GgsKMSO1
PBWrC4GqWIOFn6dIHfIpUooc+ENOmRGpngF9Jon/L/R1L3TXbWwtQWCpZUFJTYfJXhXUNH1l3kFx
KhCTjTxJ+c4VCG0eC+BeVSCpGqWlR59CpDWgCTYoNM24xAblBeFiJQaE25aVvTzadaj7gGi3+mB9
eTG5T0PDVbuz0ejkGjw7cYTS2Uuf4ZyOx6u0d2AemtiBdC3RBC/jlqGLKEwimb6YBIz+Ylv8BQAA
//8DAFBLAQItABQABgAIAAAAIQBNjvP8/QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsAAAAAAAAAAAAAAAAALgEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhABHQsehgAgAAHwcAACEAAAAAAAAAAAAAAAAAFQIA
AGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAAAwADAMkAAAC0BAAAAAAA
ABwEBAAAAAEAAAAgALoPIAAAAHcAaABpAHQAZQBfAGkAbgB0AGUAbABfAG8AbgBsAHkADwDwA9FD
AAABAPEDCAAAAAAAAIACAA0wDwAMBHQwAAAPAALwbDAAAMAACPAIAAAABwAAAAcoAAAPAAPwBDAA
AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAKAAABQAAAA8ABPAPCQAA
EgAK8AgAAAACKAAAAAoAAMMAC/BgAAAAfwABAO8BgABoIMMKgQCDcgEAggBBuQAAgwCDcgEAhABB
uQAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAAyAAAAEwAi8QcIAACpgwEIAABQSwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABbQ29udGVu
dF9UeXBlc10ueG1slJFNT8QgEIbvJv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS/bgY18Qj
zLzP+wTq1XYaxUyRrXcKrssKBDntjXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnHCoaUwr2U
rAeakEsfyOVJ5+OEKR9jLwPqDfYkb6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD4tKlAEMY
rcaUTeXszI+W4thQ5uR+hwcb+CprgPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5/BuyWE5c
+K6zmso2cptjbzSfrM7RecBAGf1f/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HS
AAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt
376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalH
MvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28
zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA
//8DAFBLAwQUAAYACAAAACEAdVoXjpgDAADDCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVW1v2zYQ
/j5g/4Hg1yL1S+zZMaoUidF0A9zAiNPt80miIs0UqZKU3359746ynRVbUcz1B/lIHu+ee3mO797v
ai02yvnKmkQO3valUCazeWVeEvn5+eFqKoUPYHLQ1qhE7pWX729//eVdM/ONwMvGz5pEliE0s17P
Z6Wqwb+1jTJ4VlhXQ8Cle+k1TnllAgR0VOvesN//rVdDZeQtmjKbVbN0JGWPm6UTVZ7I8WA4lMJA
jV6fVIYYXrQSQ9nr1OINQBgLm619hwV+BEvuYIsB/gOGMPajw0gG6NPOS/Sm7pyz21JB7mkb/fYY
3xGqQaSEpSlF2DeIsswdJuuQyC8tuKBcdyXq4d1zlB6jFen2k83xGrTBYhZgtitcfWkYZMcWhdgl
Eku5py8Ch5naBZHh5nX/Zjrt41GGZ6PJdX8yZpjRO2k2zoePyl6MRJChRDosHUcHm4UPlMSzC3Jn
7EOl9aVhc4zaXGpGbBN5Mx6OGXBExpbrCsspdFUnEpOHv5hU6o0PJmeVAJWOMgaoDee8KDB4jPpS
WJQ14lvst7C7t/meHKT4j40UWfj/Ox/pj4UqrTtIsXWAJPDUwUoK/YfB3r8ZTcdIi8CL0WSE+RHu
9Un6+sS09dxqJhKYDK0mMkgRxXnAFTWfrRsIC7NqMlI8tt3z7i9wTdc4AVv20a5KaNS/9U/U5XaK
aSAj2odV2OOYuDAlbGujB0RT0C84GbUUuSqeIV0hv29Gk8n1lFHh5hMqEesHONM6Lul4l9EdMXGQ
PwMYgarBLTiTKDyxgC75vzI5jlkW/xu5cCFqK1iYe7dm9cKacMfBpuCp+DirzfmYRiIOzWVrMjbP
OaIKkuCbbJkFsQEq/IkhzISzxr0qvtU9Jgzvn0/vivAdve40befaPe+Ye2m7OpzEBwzjtHjER6uj
Z4pEZDGWjDiFk4gohdPR5EtwQJVct3VV27+rmFSMOZHKXH1eYQvrsOD1obyaP8ZJzzUXacw8f9tE
GnRKr6ar1jjejV2xJMVaOXpjqU1ERjTrFIkEuGXotdTVQf3OSyqCrujN5bOls7Zg2ddhrhWgqT63
YBw2p2l1Gj/e6iqn4crJpJdZYcpijcIuPmhYudda6jixOFHtwnSJbMlMJ3Nb8ItXQIbo/lQuBwNS
NFXIygeoK41Py/UIYyzBecXNwvYUvLr2pjZXCuIczfw3B5nviHQuTCwXfpvZcQDyTLz9CgAA//8D
AFBLAwQUAAYACAAAACEAedCQv9kAAAD8AAAADwAAAGRycy9kb3ducmV2LnhtbESPS2vCQBSF94X+
h+EWuqsTU5SSOoooknYhJVFxe83cPOg8wsxUk3/fwUW7PJzDd/gWq0ErdiXnO2sETCcJMDKVlZ1p
BBwPu5c3YD6gkaisIQEjeVgtHx8WmEl7MwVdy9CwCDE+QwFtCH3Gua9a0ugnticTu9o6jSFG13Dp
8BbhWvE0SeZcY2fiQ4s9bVqqvssfLaCY7T+Pm/Fc87L52uJ8rc6qPAnx/DSs34EFGsL/OH/tk0v+
V95RH1LAbJqmwOp8vLhOFugDOQFRL8pGUeDLXwAAAP//AwBQSwECLQAUAAYACAAAACEAWuMRZv4A
AADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA
IQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA
IQB1WheOmAMAAMMIAAAQAAAAAAAAAAAAAAAAACoCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAG
AAgAAAAhAHnQkL/ZAAAA/AAAAA8AAAAAAAAAAAAAAAAA8AUAAGRycy9kb3ducmV2LnhtbFBLBQYA
AAAABAAEAPUAAAD2BgAAAAAAABDwCAAAAAAAAACgByoBDwAR8BAAAAAAAMMLCAAAAAAAAAAKAsgK
DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEPGAAAAAEAAAAAAAAIAAAAAAEAAAAAACIABAAMAAAAqg8O
AAAAAQAAAAcAAAAAAAkEBAgAAKYPDgAAAPEAAABVAtQB0ALwAxAFDwAE8AwJAAASAArwCAAAAAMo
AAAACgAAwwAL8GAAAAB/AAEA7wGAAMQKyAqBAINyAQCCAEG5AACDAINyAQCEAEG5AAC/AAQABAC/
AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAATACLx
BAgAAKmD/gcAAFBLAwQUAAYACAAAACEAWuMRZv4AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54
bWyUkU1PxCAQhu8m/gcyV9NSPRhjSvdg9ahG1x8wgWlLtgXCYN3999L9uBjXxCPMvM/7BOrVdhrF
TJGtdwquywoEOe2Ndb2Cj/VTcQeCEzqDo3ekYEcMq+byol7vArHIaccKhpTCvZSsB5qQSx/I5Unn
44QpH2MvA+oN9iRvqupWau8SuVSkhQFN3VKHn2MSj9t8fTCJNDKIh8Pi0qUAQxitxpRN5ezMj5bi
2FDm5H6HBxv4KmuA/LVhmZwvOOZe8tNEa0i8YkzPOGUNaSJL479cpLn8G7JYTlz4rrOayjZym2Nv
NJ+sztF5wEAZ/V/8+5I7weX+h5pvAAAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAA
AF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX
+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJ
n1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3Pfe
vqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQA
BgAIAAAAIQDq61StlAMAAMMIAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxV3W/jNgx/H7D/QdDr0IvT
JEsanHtog/U2ICuCprc907Zce5ElT5Lz9dePpJykO2zDsCwPDiVS5I/fHz/tGy22yvnamlQOPyRS
KJPbojZvqfzy+nQzk8IHMAVoa1QqD8rLT/fffvOxnftW4GPj520qqxDa+WDg80o14D/YVhnkldY1
EPDo3gatU16ZAAENNXpwmyTfDxqojbxHVWa7bleOqPx5u3KiLlI5Gd6OpDDQoNUXlSOGN63ESA56
sfgCEMbS5hvfY4F/g6VwsEMH/wRDGPvZoSdDtGkXFVpTD87ZXaWg8HSNdgeM7wTVIFLC0lYiHFpE
WQSJyPcX4SiBry7+efRTZLufbYEPoAsW/Yf5vnTNtQ6QHluWAu2Pk8lwlGAqD6lMCDjM1T6IHFmj
5G42I1aOvPF0lEwn7FnEQJKt8+GzslfjEaQolQ5Txz7CdukDBfFigswZ+1Rrfa3z7KM216oRu1Te
TW4nDDgiY81NHZQTum5SicHDXwwq1cYPpmCRALWONDqoDce8LNF59PpaWBQ16rdYb2H/aIsDGcjw
H8spduF/r3xsf0xUZd1Rip0DbAL/ewdOSaF/Mlj7d+PZBNsi8GE8HWN8hHvPyd5zTNcsrOZGApOj
1lRiX0RyEfBExWebFsLSrNucBE9l97r/FVzbF07Akn226wpa9Vf1E2W5nGIYSIn2YR0OOCauDAnr
2uohNSvoN5yMTopCla+QrY8UkOl0NGNUePmCQh5vhzjT+l7S8S2jO2FiJ/8PYASqAbfkSCLxwgSa
5P/aFDhmmfx75MKFKK1gaR7dhsVLa8IDO5uBp+TjrDYXNo1EHJqrzuSsnmNEGSTCt/kqD2ILlPhz
h3AnXCQeVfm17Clg+P7CfSjDP8j13KxbaPe6597LuvXxTD6hG+fDMy6tvj0zbEQmY8qop3ASUUvh
dDTFChxQJjddUzf2tzoGFX1OpTI3X9ZYwjos+XysbhbPuBZPORdZjDx/u1QaNEpb09UbHPLGrpmS
YqMc7VgqE5FTm/WC1AR4ZWhb6vqofuQjJUHXtHOZt3LWlkz7Jiy0AlSVcAnGYXOeVufx462uCxqu
HEzazApDFnMU9nGhYebeS6nTxOJAdUvTB7IjNT3NZcEbr4Qc0f2iXAEGpGjrkFdP0NQaV8tojD5W
4LziYmF9Ct49+64xNwriHM39V4zc9410SUxMF37b+WkA8ky8/wMAAP//AwBQSwMEFAAGAAgAAAAh
AOF8pW7aAAAA/AAAAA8AAABkcnMvZG93bnJldi54bWxEj0trAjEUhfeF/odwC93VjBZFpkYRpdRC
S5mposvr5M4D85gmqc78+4YudHk4h+/wzRadVuxMzjfWCBgOEmBkCisbUwnYfr8+TYH5gEaisoYE
9ORhMb+/m2Eq7cVkdM5DxSLE+BQF1CG0Kee+qEmjH9iWTOxK6zSGGF3FpcNLhGvFR0ky4RobEx9q
bGlVU3HKf7WAbPz5vl31+5Ln1dcaJ0u1V/lOiMeHbvkCLFAXbuPpZvfxc7iW/6iNFDAejp6BlW/9
0TUyQx/ICYh6UTaKAp//AQAA//8DAFBLAQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAA
AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEA
AAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAOrrVK2UAwAAwwgA
ABAAAAAAAAAAAAAAAAAAKgIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA4XylbtoA
AAD8AAAADwAAAAAAAAAAAAAAAADsBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAPMG
AAAAAAAAEPAIAAAAAAD4CZgRKgEPABHwEAAAAAAAwwsIAAAAAQAAAAcAyAoPAA3wWAAAAAAAnw8E
AAAABAAAAAAAoQ8YAAAAAQAAAAAAAAgAAAIAAQAAAAAAIgAEAAwAAACqDw4AAAABAAAABwAAAAAA
CQQECAAApg8OAAAA8QAAAFUC1AHQAvADEAUPAATwiAAAABIACvAIAAAABCgAAAAKAACDAAvwSAAA
AH8ABADvAYcAAQAAAL8ABAAEAL8BAQARAP8BCQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQA
YQBuAGcAbABlACAANAAAAAAAEPAIAAAAvgH8ApwOdgoPABHwEAAAAAAAwwsIAAAAAgAAAAUAyAoP
AATwLwoAABIACvAIAAAABSgAAAAKAADDAAvwYAAAAH8AAQDvAYAArFXICoEAg3IBAIIAQbkAAIMA
g3IBAIQAQbkAAL8ABAAEAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBu
AGcAbABlACAANQAAABMAIvHdCAAAqYPXCAAAUEsDBBQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCBaUu2BcJg3f33
0v24GNfEI8y8z/sE6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr5vKiXu8Cschp
xwqGlMK9lKwHmpBLH8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP23x9MIk0MoiH
w+LSpQBDGK3GlE3l7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84ZQ1pIkvjv1yk
ufwbslhOXPius5rKNnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsDBBQABgAIAAAA
IQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpb
SUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9
v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPq
fE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9ces
FzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhANbvZutuBAAABRcAABAAAABkcnMvc2hhcGV4bWwueG1s
7FjNbhs3EL4X6DsQvBaOtKsfS0LWgS3UaQHVECynPRrULtfamktuuZQs+9R36Bv00fIk+YZcW4qS
gxslBtrKh/WsOBzOz/fNUHr9Zl0qtpK2LoxOePSqzZnUqckKfZPwd1fnRwPOaid0JpTRMuH3suZv
Tr7/7nU1qiuGzboeVQlfOFeNWq06XchS1K9MJTXWcmNL4fBqb1qVlbXUTjgcVKpW3G73W6UoND+B
Kb2aVVNLUnqxmlpWZAnvRXGPMy1KnHopU/hwoyTr8VajFnYIuDEx6W3d+CKe40tmxR0C/MgNps1b
i0ginGnGC5wmT601dwspspo+xrkt79+jqxqeki/Vgrn7Cl7OTXaPbD0k/I+lsE5ajkDWCe80e8MG
GNmEWyNsNr/7xWTYL5bOIB1itM5tuW88ZMfkOcP5w163PUAd7xPe7Q6OB33vkBjJtWMp1ntxNxpS
slPSiHvxMIq9y8ETslTZ2r2VZm+vGBlKuEU9faRiNakdZXZzBB2nzXmh1L4pgF0xUnpfM+yOUoj8
bDzzlssCJWaqKBM+aNMf5UyMCDA/6szLThQqyAhQaVqWeY7gEfW+buEAQIkARCB06zOgjw4gFAJU
gZpfTgf0BBRqYewDZ3dWgBk1oVpypn7WIMSwO+iBK86/dI8BG87s9sp8e0Uvy7FRnl1Cp7CacMdZ
EMcOb+g7qSkr4SZ6VqWkSLEQWq7WvwlbNcBxwOyFmS1EJT+Hn6Dr4RTSQEZU7WbuHr1jz5T4ij72
vC9OrA8L9SmFnfiwIVx6Qa2QIOSh0BkapReFukFXVpxlMr8S8xlayzDqdgE1Zl3QlmKiz+ytV8+N
dqd+y1zUVCl0W71ZpqaGtjdd6tSb98mhdJNQV+k0dWwlqEpPcPaw3WicyXxXt/OIfKjCxkbjNHe7
up4hQa9ZnS/Hyl6tfWrny9nDk3iOUJ5eLjB6Gj7NQ78QI2TkcmqJBIAJcUCMwgO5vV2WRWl+L0Ja
EXXCpT56NwPilJv494fF0fgiNOsIs4izeci9fy4TrnEkTT5b3KIzazPzEme30tKc9FtSYkWjSJiF
FU0TTxUP8if/SmVQBc1Nvza1xuRerks3VlLAVNvjOPSG0PZCTOGT2qgio17oU0nTVSJhoUpuHYYS
8r6t9dRgfMaWE92kcUlmGtkDw0+tXKTw7ldpM6EFZ1Xh0sW5KAuFUdDpgpQLYWvp4eLtSbG17YdS
H0kR2l5a7yykdTNDbKiOO2HX+MMj/PfPRqaF62sqJTCDJypJZaWgvzLh4k50fIxW9THr0MgeWXcU
d9oRTcsD95B98BMA8ChI+Ps//w61duJAw385DQPxXoRy3X40xJVzh3LxNuXiQZ968P+bclv98/n9
eIegfx0IinH4H5mTLzQS+51ON/qEn/jgaSRG/SF9aTzws5L/9L60w89vOkDpK+jhHvtC99gXHKCD
dif+9M6Ky/kWQQde4zBA9yXoNx2gB4I+/2LzNb5ofn6A4lezx1/L/A9oJx8AAAD//wMAUEsDBBQA
BgAIAAAAIQBZVv0s2QAAAPwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9LS8NAFIX3gv9huEJ3dtJC
isROS20orQuRxEq318zNA+cRZqZp8u8dXOjycA7f4VtvR63YQM531ghYzBNgZCorO9MIOH8cHp+A
+YBGorKGBEzkYbu5v1tjJu3NFDSUoWERYnyGAtoQ+oxzX7Wk0c9tTyZ2tXUaQ4yu4dLhLcK14ssk
WXGNnYkPLfa0b6n6Lq9aQJG+vZ7306XmZfOe42qnLqr8FGL2MO6egQUaw//4JT8NRf5X/qJOUkC6
WKbA6uP05TpZoA/kBES9KBtFgW9+AAAA//8DAFBLAQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAAT
AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HS
AAAAjwEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhANbvZutu
BAAABRcAABAAAAAAAAAAAAAAAAAAKgIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA
WVb9LNkAAAD8AAAADwAAAAAAAAAAAAAAAADGBgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA
9QAAAMwHAAAAAAAAEPAIAAAACwtZAj8PghUPABHwEAAAAAAAwwsIAAAAAwAAAAYCyAoPAA3wogAA
AAAAnw8EAAAAAgAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vj
b25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAA
AAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDw4AAABTAAAABwAAAAAACQQECA8ABPAjCQAA
EgAK8AgAAAAGKAAAAAoAANMAC/BmAAAAfwABAO8BgACgXcgKgQCDcgEAggBBuQAAgwCDcgEAhABB
uQAAhwACAAAAvwAEAAQAvwEBABEA/wEBABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4A
ZwBsAGUAIAA2AAAAEwAi8RUIAACpgw8IAABQSwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABb
Q29udGVudF9UeXBlc10ueG1slJFNT8QgEIbvJv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS
/bgY18QjzLzP+wTq1XYaxUyRrXcKrssKBDntjXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnH
CoaUwr2UrAeakEsfyOVJ5+OEKR9jLwPqDfYkb6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD
4tKlAEMYrcaUTeXszI+W4thQ5uR+hwcb+CprgPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5
/BuyWE5c+K6zmso2cptjbzSfrM7RecBAGf1f/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAh
ADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJ
TGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/
7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8
T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wX
NXYPAAAA//8DAFBLAwQUAAYACAAAACEAcYJdWqQDAADRCAAAEAAAAGRycy9zaGFwZXhtbC54bWys
Vdtu2zgQfV+g/0DwtUhtJ3Z8QZUiMZruAm5gxOnu80iiItUUqSUp376+M0M5Tot2sVivH+QhOZw5
cznD9x92tRYb5XxlTSIH7/pSKJPZvDLPifzydH8xkcIHMDloa1Qi98rLDzdvfnvfzHwj8LLxsyaR
ZQjNrNfzWalq8O9sowyeFdbVEHDpnnuNU16ZAAEd1bp32e9f92qojLxBU2azapaOpOxhs3SiyhM5
GlxeS2GgRq+PKkMMz1qJa9nr1OINQBgLm619hwX+DZbcwRYD/A6GMPaTw0gG6NPOS/Smbp2z21JB
7mkb/fYY3xGqQaSEpSlF2DeIsggOk3VI5N8tuKBwUeW7RA67q1EfbZyi9Ri1SLefbY7XoQ0WswGz
XeHqc8MhO7YoBPrHku4TOZmOR+PLEWGBmdoFkeHRVX86mfRRIUON4fiqP2aFXsRAmo3z4ZOyZ+MR
ZCiRDgvJMcJm4QOl9OSC3Bl7X2l9bvAcozbnmhHbRE5HmLMTMrZcV1hcoasas9qnX0wqdcpHk7NK
gEpHGQPUhnNeFBg8Rn0uLMoasS92X9jd2XxPDlL8x3aKnPzvPMBhgIUqrTtIsXWAlPDUz0oK/YdB
JkyHkxGSJPBiOB5ifoR7fZK+PjFtPbeaaQUmQ6uJTKWI4jzgiprP1g2EhVk1GSlSLNQtT7u/wDVd
4wRs2Qe7KqFRP+ufqMvtFNNARrQPq7DHoXFmStjWRg+IrKCfcU5qKXJVPEG6QrZPh+Px1YRR4eYj
KtEMGOCEY+IjjniX0R0xcZD/BzACVYNbcCZReGQBXfJ/ZXIcuiz+GrlwIWorWJg7t2b1wppwy8Gm
4Kn4OLnN6ZgGJI7QZWsyNs85ogqS4JtsmQWxASr8C0OYCSeNO1X8qHtMGN4/nd4W4R/0utO0nWv3
tGPupe3q8CLeYxgviwd8wjp6pkhEFmPJiFPYdUQpnI4mX4IDquS6ravafq1iUjHmRCpz8WWFLazD
gteH8mL+EOc+11ykMfP8bRNp0Cm9oa5a45A3dsWSFGvl6MWlNhEZ0axTJBLglqG3U1cH9TsvqQi6
oheYz5bO2oJlX4e5VoCm+tyCcdjEORqjijve6iqn4crJpHdaYcpijcIuPm9Yudda6jixOFHtwnSJ
bMlMJ3Nb8PtXQIbo/lQuBwNSNFXIynuoK41Py9UQYyzBecXNwvYUvLr2tjYXCuIczfwPB5nviHQq
TCwXfpvZcQDyTLz5BgAA//8DAFBLAwQUAAYACAAAACEAIop1z9sAAAD8AAAADwAAAGRycy9kb3du
cmV2LnhtbESP30vDMBSF3wX/h3AF31y6iVPqsiHKrAj+2BTx8a65a+uam5hkbfffG3zQx8M5fIdv
thhMKzryobGsYDzKQBCXVjdcKXh/W55dgQgRWWNrmRQcKMBifnw0w1zbnlfUrWMlEoRDjgrqGF0u
ZShrMhhG1hGnbmu9wZiir6T22Ce4aeUky6bSYMPpoUZHtzWVu/XeKHga+ur1cd/dfXxfOv+53Mmv
5/sXpU5PhptrEJGG+D8uzl22Kf7KX9SDVnAxnkxBbIvDxjd6hSGSV5D0kmwSBTn/AQAA//8DAFBL
AQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAHGCXVqkAwAA0QgAABAAAAAAAAAAAAAAAAAAKgIAAGRycy9z
aGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAIop1z9sAAAD8AAAADwAAAAAAAAAAAAAAAAD8BQAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAAQHAAAAAAAAEPAIAAAAFhYAAKAHQBcPABHw
EAAAAAAAwwsIAAAABAAAAAkCyAoPAA3wWAAAAAAAnw8EAAAABAAAAAAAoQ8YAAAAAQAAAAAAAAgA
AAAAAQAAAAAAIgAEAAwAAACqDw4AAAABAAAABwAAAAAACQQECAAApg8OAAAA8QAAAFUC1AHQAvAD
EAUPAATwrwkAABIACvAIAAAABygAAAAKAADTAAvwZgAAAH8AAQDvAYAAWGPICoEAg3IBAIIAQbkA
AIMAg3IBAIQAQbkAAIcAAgAAAL8ABAAEAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIA
ZQBjAHQAYQBuAGcAbABlACAANwAAABMAIvF9CAAAqYN3CAAAUEsDBBQABgAIAAAAIQBa4xFm/gAA
AOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCB
aUu2BcJg3f330v24GNfEI8y8z/sE6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr
5vKiXu8CschpxwqGlMK9lKwHmpBLH8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP
23x9MIk0MoiHw+LSpQBDGK3GlE3l7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84
ZQ1pIkvjv1ykufwbslhOXPius5rKNnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsD
BBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmj
Tm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR
4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3
YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9
V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhAG8rdTULBAAAHQwAABAAAABkcnMvc2hh
cGV4bWwueG1s7Fbbjts2EH0v0H8g+Fo4lm/1BdEGu042LeAujPWmfaYlaq2aIlWS8mWL/nvOkFp7
E6RFUadv8YM9EoczZy5nxq/fHCrFdtK60uiU914lnEmdmbzUjyn/8HDbmXDmvNC5UEbLlB+l42+u
vv/udT1zNcNl7WZ1yjfe17Nu12UbWQn3ytRS46wwthIej/axW1vppPbCw1Gluv0k+bFbiVLzK5jS
u1W9tCRld7ulZWWe8lGvP+ZMiwpe72UGDI9KsjHvtmrxhgCMhcm2rsUi/g2W3Io9AvwEBtPmvUUk
Pfg08w28yWtrzX4jRe7oNfx2A75nqBpICUu9Yf5YA6VT+V1TIV9PKf+jEdZLyxHKAbG0t+MVmDkH
7BA4W+9/MTksiMYbJETMDoWtLo2I7JiiYPA/TEa9QYLaHlM+mY5H435AJGby4FkGhUEynUxIIYPG
cDxIxhFyREKWauv8e2kuRsXIUMotKhoiFbuF85Tbswtyp81tqdSlKYBdMVP6UjNsn/LpCDk7IwuW
qxIlZqqskNWEPlRmMaOWeafzIHtRqigjQKXpWBYFgkfUl8KCA7QSNRC1oT/cmPxIDtb4RVNFcv53
QmAqoFAbY58421sBbjjqasmZ+lmDEtPhZAS2+PAwHA+RH2ZfnqxfnuimmhsV+CV0BqspX3MWxbnH
EzWfqWrhF3pVZ6RIsVC3PBx+E7ZuG8ejZe/MaiNq+aX+ibqhnWIayIhyfuWPmB4XpiTY2qkeUVao
RwxMEDyXxYNYr8D56XA8HkwCKry8hxJNgh5GXaA/cMS7Ad0zphDk1wBGoCphFyGTEO6DAJfht9Q5
pm8Q/x45sz5qS7HQN3Yb1Auj/XUIdi0cFR8jXJ+PaVJili4bnQXzIUdUQRJcnS0zz3aCCn9iSGDC
WeNGFp/rPicM98+n14X/B732dN3MlX04BO6tm9XTSbxFGKeHO+yylp5rEDGIsWTEKXQdUUrMCpWH
VfQn1bA37yWd3ujd284wuUk6N9PrUWfQH42ubyeTt6P++C9QoV0DJXKNRUAmLKqybaqyMr+XsSDI
V8qfNp35Hdpf+UV4lrrzYRU3R+gXto5VC99NyjUA0yK25RZrQptVkDjbSktrm1qMZUTRVpEIhFea
FrAqn+RP4ZEKqEpa4+FsaY0pguwqP1dSwFQSUMdBFWdwzEh844wqcxrMoRC07CXSHevrD3FHouov
tU7TLiS5Wei2CA2ZaeXQUiF7hciA7ldpc6EFZ3Xps82tqEqFtTQYIsaNsE6GRgv2pHhx7YdKd6SI
Mzhznx1kriUhKkLov9GFsvBV6eKvGJEHLMU3uEMOpM6Xwgoahl+gQdv2Jxq0tDiNzW80+N9ocC5M
nHj4Pv+HCH8rrj4CAAD//wMAUEsDBBQABgAIAAAAIQAhxnCi3AAAAPwAAAAPAAAAZHJzL2Rvd25y
ZXYueG1sRI9NS8NAFEX3gv9heII7O2lpbYmdFrFURaj9UMTlM/OaxGbexJlpkvrrHVzo8nIv53Km
885UoiHnS8sK+r0EBHFmdcm5gteX5dUEhA/IGivLpOBEHuaz87Mpptq2vKVmF3IRIexTVFCEUKdS
+qwgg75na+LY7a0zGGJ0udQO2wg3lRwkybU0WHJ8KLCmu4Kyw+5oFKy6Nt88HZvF29e4du/Lg/x8
vl8rdXnR3d6ACNSF//F6OFp8D//KX9SjVjDqD8Yg9g+nD1fqLfpATkHUi7JRFOTsBwAA//8DAFBL
AQItABQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAG8rdTULBAAAHQwAABAAAAAAAAAAAAAAAAAAKgIAAGRycy9z
aGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAIcZwotwAAAD8AAAADwAAAAAAAAAAAAAAAABjBgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAGwHAAAAAAAAEPAIAAAAFhb4CZgRQBcPABHw
EAAAAAAAwwsIAAAABQAAAAgCyAoPAA3wfAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGAAA
AAIAAAAAAAAIAAACAAIAAAAAACIABAAMAAAA2A8EAAAAAAAAAAAAqg8cAAAAAQAAAAcAAAAAAAQI
CQQBAAAABwAAAAAACQQECAAApg8OAAAA8QAAAFUC1AHQAvADEAUPAATwSAAAABIACvAIAAAAASgA
AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQAL8BEgASAP8BAAAIAAQDCQAAAD8D
AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMw
AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAANK4xQFgdVy3AAAOBNML
AABQSwMEFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHLasMw
EEX3hf6D0LbYcroopdjOokl3fSzSDxjksS1qj4Q0Ccnfd+y4ULoILXQjEGLOmXtVro/joA4Yk/NU
6VVeaIVkfeOoq/T77im71yoxUAODJ6z0CZNe19dX5e4UMCmZplTpnjk8GJNsjyOk3AckeWl9HIHl
GjsTwH5Ah+a2KO6M9cRInPHE0HX5KgtE16B6g8gvMIrHsKDw+/kMJICYC1irxzNhWqLSEMLgLLBE
MAdqfugz37bOYuPtfhRpPoMX2M0EM79cYPU/6i/nBlvYD6y2R+niXH/EIf0t21JrLpNz/tS7kC4Y
Lpe3tGHmv60/AQAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz
hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn
IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ
ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j
U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv
dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b
1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt
td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQB0sUij
YAYAADIbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28cNRS/I/EdrLm32T9NyEbdVMnu
poE2bZTdFvXonfXOuOsZj2xv0r2h9oiEhCiICxI3Dgio1EpcyqcJFEGR+hV4tmd27cwsSdoIEHQj
ZWfsn9//9/zsvXrtQcLQIRGS8rQd1C/XAkTSkI9oGrWDO4OdS+sBkgqnI8x4StrBjMjg2ua771zF
GyomCUGwPpUbuB3ESmUbKysyhGEsL/OMpDA35iLBCl5FtDIS+AjoJmylUautrSSYpgFKcQJkb4/H
NCRooEkGmwXxHoPXVEk9EDLR16RJvsKgRpO6npMiGnaYQIeYtYOa+QQrm1dX8EYOYKqM2zGfHJcD
RpPGafQMgKkybr2m/+b0DACHIchf5r293av1mjnWAdnHMu0mfFotD+/Qb5Zk9nSzRA3IPl4p4T2b
OSD7uFrCd7d63d6OJ48BWfxaCd/oNrrrWx7egGJG00kJXau14JOj55AxZ7uV8Far06kVhl+gwPvz
mNEsxjxVXgTZmAv0XILvc7EDAP3CsKIpUrOMjHEIsdnBjA4F1fLgDYKdGTsUytKQ5oVkKGim2sEH
GYY4X9B79fy7V8+folfPnxw/fHb88MfjR4+OH/5gaXkLd3EauQtffvPpH199hH5/+vXLx59X46WL
/+X7j3/+6bNqoHKBL7548uuzJy++/OS3bx9XwLcEHrrwAU2IRLfIETrgCehmDONLTobifCsGMabu
iq00kjjFmksF/Z6KPfStGWa4ArdNfAveFRQqWQXw+vS+J3A/FlOVu9zT7EaceMA9ztk2F5VWuKF5
OY4fTNOomrmYurgDjA+reHdw6vm3N82gINIqkp2YeGLuM5wqHJGUKKTn+ISQCjPco9Sz6x4NBZd8
rNA9irYxrTTJgA69aFos2qUJ+GVWJSD427PN3l20zVmV1l1y6CMhKzCrEH5AmGfG63iqcFJFcoAT
5hr8JlZxlZD9mQhdXE8q8HREGEe9EZGyas1tAfo6Tr8B1aPa7XtslvhIoeikiuZNzLmL7PJJJ8ZJ
VoXt0zR2se/LCYQoRvtcVcH3uJ8h+h38gNOl7r5Liefu06vBHRp5Ii0CRM9MhfYlVGuvCCc0fVuR
z1yRtwStTIndE3V4Ge5k9e1wMaL//uLbxdN0n0C8l3egt7X3be0N/vO1d1k+n7XiLoos1F/d59gG
2bTLydJueUwZ66sZIzelaZglbBijHRjU68z5j8xPY1kMj3mB93CRwGYNElx9SFXcj3EGzXbd9OOR
zElHEmVcwqHODFfS1kyhYVf29LeqjzK2Hkis9vjIDjfdQ+GcjNl2InO8LBg1NYGzMmu+92bM6laq
pWbzVasb0Uyp81Sbqww+LKsGg3NrQieCoH8BK6/BCVzLDocUzMhI291uwoVbNOvi+UJcJGM8IrmP
tN5lH9WNk4pYMWd9iJ0KH60b0f/Sag63lib7BtzO4iSX3ZUl7ArvvYmXilNu4RljnJPpyFI3OVmK
jtpBa7WxGqAQZ+1gDOdbeEwy8LrUzR9mEVz9hErYsD81mY3hF95sFYpB9DkZV68V4yWFvTqQCam6
WMY2NMxUHgIs1Zys/I1VMOtFKWAj/TWkaK5DMPxjUoAdfdeS8ZiEynW2M6JtZ1/zUsqnioh+PDpC
QzYVBxjcr0MV9BlRCdcUpiLoF9EOtLXNlF+c88JYcdumuWGWxTgvtzpFi0y2cBOqcxnMmyMe6FYp
u1Hu/KqYlL8gVdww/p+povcTuDJojrQHQrioFRjpfG0HXKiYQxXKYhruCGgcTO2AaEFQXfR2jeC6
2HwLcqi/bc5ZGpoag5OfOqAREhT2IxULQvahLJnoO4VYPd+7LMmCkIkoR1yZWbGH5JCwga6Ba3pv
D1AMoW6qSV4GDO5k/PnveQYNI93kuPnm1ZD53mtz4O/ufGwyg1J+HTYNTWH/uYjGWn7nY9eb5cXe
6yqiJxZt1pUiK4CZsxW08rR/TRHOudXailXSuLFaCAdeLGsMg/OGKIOLH6T/wf5HRcjsbw96Qx3w
A6itCH5P0MQgbCCqL9nGA+kCaQeH0DjZQRtMmpQ1bd7daqsVm/WFtFELF8z5njC2luws/j6nsefN
mc/Oy8WLNHZuYc/WdmypqcGzJ1MUhsbFQcY4xvxo5f6uxIf3wdFduOufMiVNMJEHcM0HrWff5AEk
v+Volm7+CQAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19y
ZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8k
UeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhN
JiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/Tga
iWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAIKKvBP6
AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAUAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2Vy
LnhtbFBLAQItABQABgAIAAAAIQB0sUijYAYAADIbAAAWAAAAAAAAAAAAAAAAANECAAB0aGVtZS90
aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAA
ZQkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0B
AABgCgAAAAAAAA8EOgEAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFu
ZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1s
Zm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9
Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2Vu
dDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9
ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+AAAnBLgFAABQSwME
FAAGAAgAAAAhACjXYsj5AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJC7bsMwDEX3Av0H
QWsRyelQFIXtDH1sfQzpBxASbQvVC6ISJH9f2skQdAjQSaAk3nPIdnMIXuyxkEuxk2vVSIHRJOvi
2Mnv7dvqUQqqEC34FLGTRyS56W9v2u0xIwnujtTJqdb8pDWZCQOQShkjvwypBKhcllFnMD8wor5v
mgdtUqwY66rOGbJvP1mgOIviC0r9gMAcbQtp8nz5DlTZ77JYK06X4vkUM5t0EnL2zkDlOfQ+2j8O
qzQMzqBNZheYrHJB4nP5Hry6AN3N0bpvX3CAna/i9cCqp+0U9PQ/6nlqxZ0LiiaX6Qrh+lhnM72s
vv8FAAD//wMAUEsDBBQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQ
RO+C/xD2btN6EJGmvYjQgxfRD1iSbRtsk5CNon9vjhYEj8Mwb2bq9jVP4kmRrXcKqqIEQU57Y92g
4HY9bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgDi0xxrGBMKRykZD3SjFz4QC47vY8zpizjIAPqOw4k
t2W5k/GbAc2CKTqjIHamAnF9h9z8n+373mo6ev2YyaUfFZIna+iMnChmLMaBkgIT+dtYiKrI+0E2
tVz8bT4AAAD//wMAUEsDBBQABgAIAAAAIQB1EVzOiQIAAKYOAAAhAAAAZHJzL3NsaWRlTWFzdGVy
cy9zbGlkZU1hc3RlcjEueG1s7JdLbtswEIb3BXoHgtsikfWILAuRgySFV1kETdr9WKIsIRQlkEwa
d9U79AY9Wk+SGVquZTcLAwWKxKlXpDkckv83HA1Pzx4byR6ENnWrMu4fjzgTKm+LWi0y/vl2dpRw
ZiyoAmSrRMaXwvCz6ft3p11qH2/sUgrD0IUyKWS8srZLPc/klWjAHLedUDhWtroBi1298AoNX9F1
I71gNIq9BmrF+/l6n/ltWda5+Njm941QduVECwkWt2+qujNrb90+3jotDLpxs7e2NKXj1VYKd0KP
uvO2WLre9BRS+SD97lozkAtUTXKmrcw4aQdX6kLfuXbZKnvuDOZgBGcVqAWe/fpe5ZYMyJHp8gtR
9q3r3LIHQEfhCH8cl/V2LM5Lu2s7sOtHC1F+wr2Zb8gTVebsTmhiS203u5V1MauldB1iJS6lXq1s
H/31ukMrElgxu+xECTlGwRehC1DAWVfbvJpBU8slbjviLK9AG+HOh/uHVMBg2odGHQmgBSDNzc5A
bvqVV/t3h+91JntsBiR5A/oq40Hoj8cnnNWqQIAZPwrCkZ9grL5IIvP7S5TFaZPxX99/rhQ4LE4E
p+cUbjhFsT+JwyGnIIkpJl8opxne2UFc7h/nO4h/HCJi4tojjjaI4zCM/CFiP54kxPzAET9ziylr
v+5sS1x7xCcbxMkoDLayrR8n7o8DR/zMLX79iIlrjzjeIA5cXh4mZvw83cL8BquIiR9FFNl/FDk+
Z64y2NQ82zWOz2mhf/Cdo8JC2lXO/euKg1TpBRoPBBpHoaumfsf8mxWIVOkFSjYCkTouTP4LRKr0
Ak0GAsUn4+3a581GEKmCBf7Wq6pLW1sJvX5x4eD6gTl9AgAA//8DAFBLAQItABQABgAIAAAAIQAo
12LI+QAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG
AAgAAAAhAI7qKvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAAKgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG
AAgAAAAhAHURXM6JAgAApg4AACEAAAAAAAAAAAAAAAAAEQIAAGRycy9zbGlkZU1hc3RlcnMvc2xp
ZGVNYXN0ZXIxLnhtbFBLBQYAAAAAAwADAMkAAADZBAAAAAAPAO4D8wYAAAIA7wMYAAAAEAAAAAAA
AAAAAAAAAAAAgAAAAAAHAAwwDwAMBPoFAAAPAALw8gUAANAACPAIAAAABQAAAAYIAAAPAAPwigUA
AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPAgAQAA
ogwK8AgAAAACCAAAAAoAAMMAC/BuAAAAfwABAO8BgAAgU9gJgQAAAAAAggAAAAAAgwAAAAAAhAAA
AAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMA
ZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8PBAAAAAQAAAAA
AKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcPCAAAAAAA
AAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALw
AxAFDwAE8CwBAACiDArwCAAAAAMIAAAACgAAwwAL8H4AAAB/AAEA7wGAADhg2AmBAAAAAACCAAAA
AACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwAaQBk
AGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDwCAAAAF0Q
uA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAAC
AAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYA
AAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwQwEAABIACvAIAAAABAgAACACAAADAQvweAAA
AAQAAAAAAH8AAQDvAYAAxF3YCYEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgA
AAAAAL8ABAAEAP8BAAARAAEDAwQAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABl
ACAAMgAAAAAAEPAIAAAAiwXxAE4VGQcPABHwEAAAAAAAwwsIAAAA/////w0A2AkPAA3wgwAAAAAA
nw8EAAAAAAAAAAAAqA8PAAAAWGVuIHZNQ0UgRGVzaWduAAChDxwAAAAQAAAAAAAACAoAAQAHABAA
AAABACIAAAAEACAAAACqDzQAAAADAAAABwAAAAMACQQECAEAAAAGAAAACQQECAQAAAAHAAAAAwAJ
BAQICAAAAAYAAAAJBAQIDwAE8KsBAAASAArwCAAAAAUIAAAgAgAAAwEL8HgAAAAEAAAAAAB/AAEA
7wGAANBw2AmBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAAAACHAAAAAACIAAAAAAC/AAQABAD/
AQAAEQABAwQEAAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAAAABDw
CAAAAGYK0ASqEfIMDwAR8BAAAAAAAMMLCAAAAP////8OANgJDwAN8OsAAAAAAJ8PBAAAAAEAAAAA
AKgPTQAAAExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPg1KaWFuZywgWXVuaG9u
ZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+AAChDx4AAABOAAAAAAABCAoACAABAAcATgAAAAEA
IgAAAAQAEgAAAKoPQAAAAA4AAAAGAAAACQQECBUAAAAHAAAAAwAJBAQIEgAAAAYAAAAJBAQIFwAA
AAcAAAADAAkEBAgCAAAABgAAAAkEBAgAAKYPFAAAAPAeAADUASAB0AJAAvADYAMQBYAEDwAE8EgA
AAASAArwCAAAAAYIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/
AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAIYKgA/1xHAPXmRwCmyuEAVn65AAwuhgCqAUwA
DwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAC/
+scB0KOF6wAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA
VAn/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAAiBAgAAAABAAAABgAAAA8A
7gN/IgEAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACABAEAAAcADDAAAPkDEAAAAAAAAAAAAAAAAgAB
AAK9TjAPAAwE4NwAAA8AAvDY3AAAAAII8AgAAAAzAAAANYwAAA8AA/Bw3AAADwAE8CgAAAABAAnw
EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACMAAAFAAAADwAE8BwKAAASAArwCAAAAAKMAAAA
CgAAswEL8LoAAAB/AAAA7wGAAKzL2AmFAAIAAACHAAEAAAC/AAQABACAAQcAAACBAQQAAAiCAczM
AACDAU1daACEATOzAACMAWQAAAC/ARAAEAD/AQgAGACFAuCMAQCHAgQAAAi/AgoADgDBAgIABQDM
AtASEwDPAgCAAADQAgAAhwDTArA8///UArA8///XAlDDAAD/AhYAFwA/AwAACACAwxgAAAC/AwAA
AgBSAGUAYwB0AGEAbgBnAGwAZQAgADQAAAAjACLx2AgAAL8BAAAgAKmDzAgAAFBLAwQUAAYACAAA
ACEAWuMRZv4AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkU1PxCAQhu8m/gcyV9NSPRhj
Svdg9ahG1x8wgWlLtgXCYN3999L9uBjXxCPMvM/7BOrVdhrFTJGtdwquywoEOe2Ndb2Cj/VTcQeC
EzqDo3ekYEcMq+byol7vArHIaccKhpTCvZSsB5qQSx/I5Unn44QpH2MvA+oN9iRvqupWau8SuVSk
hQFN3VKHn2MSj9t8fTCJNDKIh8Pi0qUAQxitxpRN5ezMj5bi2FDm5H6HBxv4KmuA/LVhmZwvOOZe
8tNEa0i8YkzPOGUNaSJL479cpLn8G7JYTlz4rrOayjZym2NvNJ+sztF5wEAZ/V/8+5I7weX+h5pv
AAAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbv
g72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefj
YODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvB
gfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTn
QL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQDqFWJaYQQAAPwKAAAQ
AAAAZHJzL3NoYXBleG1sLnhtbKRWS3LjNhDdpyp3QHGb8kiUZdmjGnrKdsWThcdRWZ5k3SJBETEI
MAAkS75ClrlHbpDbJPfIQ0M/T6qSqZEWFEg00K/7NV7j3ftVq8VSOq+sKbL8TT8T0pS2UmZeZJ8e
b08uMuEDmYq0NbLI1tJn7y+//eZdN/adwGLjx12RNSF0417Pl41syb+xnTSYq61rKeDVzXudk16a
QAGOWt0b9PujXkvKZJfYyiyn3cTFUXm/nDihqiIbnI36w0wYauH2QZYAMddSDLPexi4tIeC4s+WT
34ChLwFTOXpGhK9wCGNvGviQV87Z50ZS5ZGQ6K3HsLYIDQCmj3vUHujF7PmjrYCVFsEiKhqvatce
iyruY+tarIpslOf5BehYF9lpPsxHo9MIjsZyFUSJ+fPz88GwDwJLWMTpc7xEpAlJNO2cDx+kPRqV
iBsVmQMrHCkt73xIrrYuoru5o+pWaX1sEoSz4WcVmmlDHRLcZ59zD5/sxYvOgqv0mUtQ3mgnlqRB
Rlmi6vKEUncNpc8Xffw2ydmt4FTN/eGeebT7343n1LbEXPiGKplcDEeD87PEkDLLDzsT2qMAQf+B
ArztYtTKCNRmkZ2B4bhI+JK0xDFJFbrPdUSvzdEZf8YBvDhDAIL0HMpQBsc5NDYSyrG2KkgntGqL
jNPJ+aRxPDnfm4pNAimdxghGm4hN1jWqBtQdCzHlG+zK0+rYvSKwEkLjaFPZWs6pXP840+rXhby2
Idj2Qc2bVO2oRqEJ9T/IB2/jLxMQx1iAwsll/Ac2BJx2ZELiWmwgnAKHafNbbDHIRKVckYVdKXI4
cYnvjg9LQBrcIkr7D5CH4SjWTTyfHwnMqXg8EhS8B8n0zuRS6kcB9vPTs2je7EbpyLMIp6pm2+sv
s90BwcHk6GKj+PcpTXl7bYxExlywDEedjeofVte2WseNZviH9qZG9PXa/+wIXcygxaHgTdlYkLIt
+RpEPa4StOSOKfVhGtZoSEe65jLedtKvDiAiij2oJXfHhYjBAw/0EjSDSGUqCCEP9ydaVLJ+pNn0
pcje5kNuHi4ke0l35to98YLamnDFMjAjjwwhIcrsp2PXRDedLEzJDjg9ZtqVceC7clKGJIkbNU2p
1AcW17L+3HZ7iLB+P3tVs+If7nlgt5mdLVBkTBjKYzF92Q1vEcbu5R5cc+4DzVLzojGy8ZCaO2cz
QpKmmpAjfBZPi1a19heV0spq/NKc3NxHiQx3/C7NyacptBn5TK14lnLPz8W2wHxw6gl9zNgpjzLx
JF28feFShO69r0TEyStNvEdp9SJxjGERSUBD4E6IW8vEWVvzhG/DjZbEUpRIiM+dZO802FutuDFz
0l8fxbDadpRXVjvZ5pwt7swmkYvYDjZjLgsR1p2sqQS6n6SryBA0R4WyuaVW6Xh3waWubMh5ycXC
+0k6WPb3H7/99efvn62CUu4WneSDQZKg0h+s+641J6XfKOmeN5bijuVjKxu40Pnu8h8AAAD//wMA
UEsDBBQABgAIAAAAIQCvnAmu2wAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9NawIxFEX3gv8h
PKE7TZR2lKlRpLRYuyg4lYK718lzZjAf0yR1xv76hi7a5eVezuUs173R7EI+NM5KmE4EMLKlU42t
JBzensYLYCGiVaidJQlXCrBeDQdLzJXr7J4uRaxYgtiQo4Q6xjbnPJQ1GQwT15JN3cl5gzFFX3Hl
sUtwo/lMiIwbbGx6qLGlh5rKc/FlJBTfuzPNF4/di/aB07s+zI9cSHkz6jf3wCL18X+8PX6+Zru/
8hf1rCTM7jJxC+y0vX74Ru0xRPISkl+yTabAVz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAFrjEWb+
AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEA6hViWmEEAAD8CgAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQA
BgAIAAAAIQCvnAmu2wAAAP0AAAAPAAAAAAAAAAAAAAAAALkGAABkcnMvZG93bnJldi54bWxQSwUG
AAAAAAQABAD1AAAAwQcAAAAAAAAQ8AgAAAC7B4EBoRTTCw8ADfBSAAAAAACfDwQAAAAEAAAAAACh
DxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPDAAAAPAA
AADUAdAC8AMQBQ8ABPAZBQAAEgAK8AgAAAADjAAAAAoAAOMAC/BsAAAAfwAAAO8BgAAI1dgJhQAC
AAAAhwABAAAAvwAEAAQAgQEBAAAIggEAAAAAvwEQABAAwAEMpCkAywHRVgAA/wEIABgAPwMAAAgA
gMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAIwAi8eQDAAD/AQAAQACpg9gDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAFKi5HnXAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj81KxDAU
hfeC7xCu4M5JLMwwUyczSMEfcDU/D3Btbptqk5Tc2Gl9eoMLXR7O4Tt82/3kejFS5C54DfcLBYJ8
HUznWw3n09PdGgQn9Ab74EnDTAz73fXVFksTLv5A4zG1IkM8l6jBpjSUUnJtySEvwkA+d02IDlOO
sZUm4iXDXS8LpVbSYefzg8WBKkv15/HLafhQ6yo+OzsPb2pTkK243zSs9e3N9PgAItGU/sfL0xj5
+6/8Rb0aDcVypQoQzcv8HjtzQE4UNWS/bJtNQe5+AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA
AAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA
AAAhAFKi5HnXAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA
AwADALcAAAALAwAAAAAAABDwCAAAAAgK0gYZEXMLDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAA
BwRAAAAAAAAAAAAAAAYAAQABAAAAAAANMA8ADfBdAAAAAACfDwQAAAAEAAAAAACoDwMAAAANDQ0A
AKEPFgAAAAQAAAAAAAAAAAAEAAAAAAAiAAQADAAAAKoPDAAAAAQAAAAGAAAACQQECAAApg8MAAAA
8AAAANQB0ALwAxAFDwAE8BsFAACiDArwCAAAAASMAAAACgAA0wAL8GQAAAB/AAAA7wGAALDc2AmB
AAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/AwAACACAwxYA
AAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAzAAAAIwAi8ecDAAD/AQAAQACpg9sDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhAAU9f3LaAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tOwzAURPdI/IN1
kdgg6mBohULdCiEQrChp+IBLfBMHYju1TR58fS0WsBzN6IzOejuZjg3kQ+ushKtFBoxs5VRrGwnv
5dPlLbAQ0SrsnCUJMwXYbk5P1pgrN9qChn1sWILYkKMEHWOfcx4qTQbDwvVkU1c7bzCm6BuuPI4J
bjousmzFDbY2PWjs6UFT9bX/NhLqn9INN8Or/ix386M4LN96cTFKeX423d8BizTF/3EhdofG/JW/
qBclQSxX2TWw+nn+8K0qMETyEpJfsk2mwDdHAAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
AAU9f3LaAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwAD
ALcAAAAOAwAAAAAAABDwCAAAACwKMQqDDbIKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwQA
AAAAAAAAAAAAAAUAAQABAAAAAAANMA8ADfBkAAAAAACfDwQAAAAEAAAAAACoDwgAAABIb3N0IE1D
RQAAoQ8YAAAACQAAAAAAAAAAAAkAAAABACIAAQAEAA4AAACqDwwAAAAJAAAABgAAAAkEBAgAAKYP
DAAAAPAAAADUAdAC8AMQBQ8ABPAwAQAAEgAK8AgAAAAFjAAAIAIAABMBC/B+AAAABAAAAAAAfwAB
AO8BgADk39gJgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA
/wEAABEAAQMDBAAAPwMAAAgAgMMYAAAAiAMAAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA1
AAAAAAAQ8AgAAADLAA4BaxVZAg8AEfAQAAAAAADDCwgAAAD/////DQDYCQ8ADfBqAAAAAACfDwQA
AAAAAAAAAACoDxQAAABYZW4gTUNFIEFyY2hpdGVjdHVyZQAAoQ8YAAAAFQAAAAAAAAgAAAEAFQAA
AAEAIAAAAAQAAACqDxoAAAADAAAABwAAAAMACQQECBIAAAAGAAAACQQECA8ABPBACQAAEgAK8AgA
AAAGjAAAAAoAACMBC/CEAAAAfwAAAO8BgADM7NgJhQACAAAAhwABAAAAvwAEAAQAgAEHAAAAgQEE
AAAIggEzswAAgwFNXWgAhAFlZgAAjAFkAAAAvwEQABAAwAEEAAAIywGfbwAA/wEIABgAPwMAAAgA
gMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA2AAAAMwAi8TIIAAC/ASAAIAD/AQAAQACp
gyAIAABQSwMEFAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFN
T8QgEIbvJv4HMlfTUj0YY0r3YPWoRtcfMIFpS7YFwmDd/ffS/bgY18QjzLzP+wTq1XYaxUyRrXcK
rssKBDntjXW9go/1U3EHghM6g6N3pGBHDKvm8qJe7wKxyGnHCoaUwr2UrAeakEsfyOVJ5+OEKR9j
LwPqDfYkb6rqVmrvErlUpIUBTd1Sh59jEo/bfH0wiTQyiIfD4tKlAEMYrcaUTeXszI+W4thQ5uR+
hwcb+CprgPy1YZmcLzjmXvLTRGtIvGJMzzhlDWkiS+O/XKS5/BuyWE5c+K6zmso2cptjbzSfrM7R
ecBAGf1f/PuSO8Hl/oeabwAAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVs
cy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2
tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0p
oDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfX
eKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAA
ACEApcuiibYDAAAkCQAAEAAAAGRycy9zaGFwZXhtbC54bWykVUtuIzcQ3QfIHYjeBhp9xvpYmPbA
NuLJQmMIlidZl9hsNSM22SCpn6+QZe6RG+Q2M/dIVVE/GwgSjLSwq7uLVa9eVT1++LitjVgrH7Sz
edZ918mEstIV2i7y7MvzQ2uUiRDBFmCcVXm2UyH7ePPjDx+acWgEHrZh3ORZFWMzbreDrFQN4Z1r
lMVvpfM1RHz0i3bjVVA2QsREtWn3Op1BuwZtsxsMZdezZurJko/rqRe6yLNef9AZZMJCjWmflEQQ
C6PEIGvv/dIRQBwTJ5dhDwb+D5jCwwYrfIVDWHdfYQ51673bVAqKgIRQtjbDOiC0CDC9PKEOiF7M
N59dgVhhFR1WBeNt6etLUVEcV5Zim2eDzvWgg/3Z5Vm/O+qSjThgrLZRSPw+HA57V+Qg0WMw6o+S
QzsBIc/Gh/hJuYtBCQqUZx6bwoXCehIicXJKQekWHooHbcylHAjv4m86VrMKGuS3yzkXAXNyliAa
h63q8GueQHVvvFiDwV5IiUOXToBpKkivhx38cWtxfGhm6QTjX4TzmF3y+8/AC6hr4FaECgqVUlwN
esN+apC2609HlzMU76/x968okMxjjUZbgaOJjccGEyIRJBiFW5IG9MQ1oTf2YsY3uH+jPhYgwCxQ
GGT0iV5nNPeU8hyZe811GoRw7lnrqLwwus4znEoqgOmiJfvZFmxH0CbZWLixFF+VJU4YtvnScggR
6VWSmLi9c8WOEszxPy5uUrHvF46NB5RAi/qIdFlZOZ8I47pMiLO4Q+G6MAsHOyjud2OlqkmravAT
Whkyntgwa1wXfKFtgRvD5qn1olDlM8xnL3l23b1ikfEx+SuY2Du/5AOls/GW52UOAckwqPb29JnU
FVV3urKSExAYY2eNJCM0cipjmqT92lHbXnvcqfKt73GNG3n6eluyNJzHPPPbf52vcOmft0zsfDV7
OZoPWMbx4RHbyi4R5jiKbCIbT+kSYDYJkrLFFDzga7Fc1bp2v+tEK6/tS9W6f6RdihN+Vrb1ZYZL
jHwmyZ4n7vnv6jBLIXq9RMGzbsZWJpbK0y2Nlyeq/GnosE4+aem+NfpF/cKP1ARUDoyA7tZNvXMl
26GO90YBhkraltbNOhLrA+nM8/kOv9n2uD1Iz6tNP+4sE7Wa2D2RK4q9t3ksRNw1qgSJ6H5VvgAL
mWh0lNUD1NrgDfb+CmuswAfFw8LxFJwd+/bXH1///vPNqd7ZoVa310tCI8PZuZ9q25Jhr7unvqXr
i5XioBAsGjf/AAAA//8DAFBLAwQUAAYACAAAACEAAk4aydoAAAD9AAAADwAAAGRycy9kb3ducmV2
LnhtbESPTUsDMRRF94L/ITzBnc100Chj0yIFmRZEaLWL7p6T18noJJkmcT7+vcGFLi/3ci5nsRpN
y3ryoXFWwnyWASNbOdXYWsL72/PNA7AQ0SpsnSUJEwVYLS8vFlgoN9gd9ftYswSxoUAJOsau4DxU
mgyGmevIpu7kvMGYoq+58jgkuGl5nmWCG2xsetDY0VpT9bX/NhLOL5v55/3ttht0nztRlevSHSYp
r6/Gp0dgkcb4Py6P51ex/St/URslIb8TmQB2KqcP36gdhkheQvJLtskU+PIHAAD//wMAUEsBAi0A
FAAGAAgAAAAhAFrjEWb+AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEApcuiibYDAAAkCQAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBl
eG1sLnhtbFBLAQItABQABgAIAAAAIQACThrJ2gAAAP0AAAAPAAAAAAAAAAAAAAAAAA4GAABkcnMv
ZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAFQcAAAAAAAAQ8AgAAADADIABoBRwDg8ADfBSAAAA
AACfDwQAAAAEAAAAAAChDxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAA
AAQICQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPD+AAAAogwK8AgAAAAHjAAAAAoAANMAC/BkAAAA
fwAAAO8BgABQ9NgJgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAAYAvwEAABEAywFwxgAA/wEA
ABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwAAABMAIvEGAAAA/wEAAEAA
AAAQ8AgAAADeDIQSrRNkDQ8ADfBcAAAAAACfDwQAAAAEAAAAAACoDwIAAABIVwAAoQ8WAAAAAwAA
AAAAAAAAAAMAAAAAACIABAAOAAAAqg8MAAAAAwAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvAD
EAUPAATwCAoAABIACvAIAAAACIwAAAAKAADDAQvwwAAAAH8AAADvAYAAEACXCoUAAgAAAIcAAQAA
AL8ABAAEAIABBwAAAIEBBAAACIIBzMwAAIMBTV1oAIQBM7MAAIwBZAAAAL8BEAAQAP8BCAAYAIAC
gDgBAIECwKoAAIUC4IwBAIcCBAAACL8CDgAOAMwC0BITAM8CAIAAANACAACHANMCsDz//9QCsDz/
/9cCUMMAAP8CAgAHAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAOQAAACMA
IvG+CAAAvwEgACAAqYOyCAAAUEsDBBQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCBaUu2BcJg3f330v24GNfEI8y8
z/sE6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr5vKiXu8CschpxwqGlMK9lKwH
mpBLH8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP23x9MIk0MoiHw+LSpQBDGK3G
lE3l7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84ZQ1pIkvjv1ykufwbslhOXPiu
s5rKNnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAA
AI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++
pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6
JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s
3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//
AwBQSwMEFAAGAAgAAAAhAOxCQwtGBAAAwwoAABAAAABkcnMvc2hhcGV4bWwueG1spFZLbiM3EN0H
yB2I3gYefWzJtjDyYGzEk4VtCJYnWZfYbDVjNtkgKVnyFbLMPXKD3Ca5Rx6L+nmCIIPRRqruLrJe
vSq+4vsPq8aIpfJBOzsueu+6hVBWulLb+bj4/HR7clGIEMmWZJxV42KtQvHh6vvv3rej0AostmHU
jos6xnbU6QRZq4bCO9cqi2+V8w1FPPp5p/UqKBspIlBjOv1ud9hpSNviClvZ5bSd+GTJh+XEC12O
i/5g2L0shKUGYR+VBIi5UeKy6Gz88hICjjsnn8MGDH0NmNLTCzJ8g0NYd1MjhvrovXupFZUBhKRo
HYa1RWgBML/cow5AL2Yv964EVlpEh6xotKp8cyyqtI+rKrEaF6Bj2EV91uPisnvRHXQTNhqpVRQS
nwe9i+Hp8LQQEg69i2633x8w+gwkubY+xE/KHQ1KpI3GhUdROFFa3oWYONmHSOHmnspbbcyxHAjv
4i861tOaWvDb45jzgJgcJYjWoVRdfs0dqG6MF0syqIWUaLq8gkxbU34NdsBkRrxbwfjn4XDPXvL7
343n1DTEtQg1lSqHOBv2z5l/Gmm7/LRzOUBxzpv/FwqQucvRaCvQmijyWUYkgiSjcEpyg+65TuiN
PZrxF5y/iwESEGTmEAYZPdPb6Ki8MLoZF8zhpgfTafnRlsxBJG2yjQyMTYBUVaFVUK9jcWWSUVJ1
Wh67VwImIS6eNu1s1JzkegItbIFWL9W1i9E1j3pex3zUTDLxLLxGLbL/raHYL0Sp/bhgN2QdMsIU
IbTHIxU44n6RFPqncXF+xiKQTuA9oRg6tXmGcq8iGS7TTC2VeRKoYu90kDSj3ln56LKW5qTY9/rr
fHdAcMA4u6T3/z5tuaXfOidawAWraZLLJOJxde3Kddpohn9IaJ4n3y7hL54wjCwmFRrXytqhKNvW
rVCop1WGlsOlwCbEaVxjrhwZmjtzOxC/OYGEKI2ShvxdUrRkPLJhligzXmhbQtDY3J9MUarqiWbT
V0yG3hkkohA+Zn9Fd/baP/OCytn4kY/zjAIYAiHa7j+n4YehOFlYyQGYHjttZTJCKycyZmnbqGKm
0hx4XKvqS9+dyrZy//Vjxcp9uOeB3+brbIEm44KhPRbT1515izR2Dw+oNXMfaQaBYRNsPOYZzWwm
SMqWE/KE1+J50ejG/aozrayqr/XJzUOSunjHz8qefJ7i3gM++8zmLHPPv4ttg4Xo9TPmkXVTtgrx
rHy6ROFugym870TkySttug4Z/apwjOGRigBhxw54sG7inavYDk28MYqwVR49WUStS7N0Szrz7Izm
AcsPb49iXG0nQzj02ikxE7W4sxsiF2nvjc1tIeK6VRVJoPtZ+ZIsFaLVUda31GiDG8bpGXKsyQfF
zcL7KTpY9vcfv/315+9frIJS7had9Pr9LEEyHKz7obEnMmyG875u+XbB8rGVDdzLQnv1DwAAAP//
AwBQSwMEFAAGAAgAAAAhAINfInHcAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8FOAjEURfcm
/kPzTNwY6UhwgJFCjAYHNiaALtw9p2+mhWk7thWGv7dxocube3NuzmzRm5YdyQftrIC7QQaMbOWk
to2At93ydgIsRLQSW2dJwJkCLOaXFzMspDvZDR23sWEJYkOBAlSMXcF5qBQZDAPXkU1d7bzBmKJv
uPR4SnDT8mGW5dygtulBYUdPiqrD9tsICPvx8mX0rPfjsrmpp7QeqfeDE+L6qn98ABapj//j8uPr
NV//lb+olRQwvM+zKbC6PH96LTcYInkByS/ZJlPg8x8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAFrj
EWb+AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAvAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEA7EJDC0YEAADDCgAAEAAAAAAAAAAAAAAAAAAqAgAAZHJzL3NoYXBleG1sLnhtbFBLAQIt
ABQABgAIAAAAIQCDXyJx3AAAAP0AAAAPAAAAAAAAAAAAAAAAAJ4GAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAQABAD1AAAApwcAAAAAAAAQ8AgAAAA8AoABQw6qBg8ADfBSAAAAAACfDwQAAAAEAAAA
AAChDxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPDAAA
APAAAADUAdAC8AMQBQ8ABPACAQAAogwK8AgAAAAJjAAAAAoAANMAC/BmAAAAfwAAAO8BgACoCpcK
gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMAAAgAgMMY
AAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQAwAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAJcC
rwEvAzEDDwAN8F4AAAAAAJ8PBAAAAAQAAAAAAKgPBAAAAGRvbTAAAKEPFgAAAAUAAAAAAAAAAAAF
AAAAAAAiAAQAEAAAAKoPDAAAAAUAAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8EMJ
AAASAArwCAAAAAqMAAAACgAAIwEL8IYAAAB/AAAA7wGAAAAOlwqFAAIAAACHAAEAAAC/AAQABACA
AQcAAACBAQQAAAiCAczMAACDAU1daACEATOzAACMAWQAAAC/ARAAEADAAQQAAAjLAZ9vAAD/AQgA
GAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADEAMQAAADMAIvEzCAAAvwEg
ACAA/wEAAEAAqYMhCAAAUEsDBBQABgAIAAAAIQBa4xFm/gAAAOIBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbJSRTU/EIBCG7yb+BzJX01I9GGNK92D1qEbXHzCBaUu2BcJg3f330v24GNfEI8y8z/sE
6tV2GsVMka13Cq7LCgQ57Y11vYKP9VNxB4ITOoOjd6RgRwyr5vKiXu8CschpxwqGlMK9lKwHmpBL
H8jlSefjhCkfYy8D6g32JG+q6lZq7xK5VKSFAU3dUoefYxKP23x9MIk0MoiHw+LSpQBDGK3GlE3l
7MyPluLYUObkfocHG/gqa4D8tWGZnC845l7y00RrSLxiTM84ZQ1pIkvjv1ykufwbslhOXPius5rK
NnKbY280n6zO0XnAQBn9X/z7kjvB5f6Hmm8AAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8B
AAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBY
Rm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpS
ohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfG
ctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQ
SwMEFAAGAAgAAAAhAF4JdJK2AwAAJgkAABAAAABkcnMvc2hhcGV4bWwueG1spFVLbiM3EN0HyB0I
bgONWrJsa4RpD2wjniw0hmB5knWJzVYzYpMNkvr5ClnmHrlBbjNzjxSLrZbsLBKMvJDZZLHq1auq
xw8fd7VmG+m8sibng3cZZ9IIWyizzPmX54femDMfwBSgrZE530vPP978+MOHZuIbhpeNnzQ5r0Jo
Jv2+F5Wswb+zjTR4VlpXQ8BPt+w3TnppAgQMVOv+MMuu+jUow2/QldnMm5mLK/G4mTmmipwPL68G
A84M1Bj2SQoEsdSS4V6/NUx3AIFMrVj5Fg38HzSFgy2m+AoIM/a+wiDy1jm7rSQUHhmJ0fqE6wDR
IMK0eYTtET5bbD/bAsHCOlhMCya70tXnoop+bFmyXc6vsvFoPMaC7HP+fjAaZVkEBxO5C0zg+fAi
uxhdDTkTaDC4fn8xvr4k+AlJNG2cD5+kPRsVi45y7rAslClspj5EUo4hYrilg+JBaX0uCczZ8JsK
1byCBgkeUMylx5gUxbPGYq0y2qYelPfasQ1oLIYQ2HbpBuimgrQ9zvCvJae7QfiX/tTnINr9p+Ml
1DVQLXwFhUwhsBSJf5gos/nUmZyguCbnibd/o0Ayuxy1Mgx7M+eXWPaIiHkBWuKcpA49ch3Ra3M2
41vsp/ElJsBAL1EaRHCJXqsV1TTG6TC/5rpN6NSyVkE6plWdc6K+bd04ZT+bgqgLoHRaY+LaRP+y
LLHDsMznphMRRcVKIhN2d7bYxwAL/I+Tm3Ts+5Vj6wBF0KBCIl1GVNYlwigv7cM87FG6zoxCzg6a
+91YY9ZRrGpw0zgycfFEC73BccENZQqcGFoeS88KWT7DYv7SSQ9zIdlLmJo7t6ILpTXhlvplAR7J
0Kj35ngc5RVld7Y2ggJEMNrMGxEXvhEzEVIntWMXy/ba4k6Wb227MW7E8fS2JGk49Xli154u1igT
zzsidrGev3TLB0yj+3jEspJJgAW2Ii2Rjaf0ChCbEZI0xQwc4DZbrWtV299VopXG9qXq3T/GWQpT
+pam92WOQ4x8DqOQs0Xinn7Xh17ywakVCp6xc1pxtpIuvtP4fKLMH5sO86SbJr64Wr3IX+gzFgGV
Az2gubEzZ21Ja1+Hey0BXSVtS+NmbBTrA+nE8+kMv5n2sDtIjz+16maWiFpPTUvkOvpu19QWLOwb
WYJAdL9KV4ABzhoVRPUAtdL4hF2MMMcKnJfULORPwsm1b3/98fXvP9/ciu/f4VJvMBymN1L4k3s/
1aYnfKv+x7ql54uU4qAQJBo3/wAAAP//AwBQSwMEFAAGAAgAAAAhAP6g8PrbAAAA/QAAAA8AAABk
cnMvZG93bnJldi54bWxEj1FLwzAUhd8F/0O4gm8u7aZ11GVDirLJQOi2F9+uzW0b2iQ1ybbOX2/w
QR8P5/AdvsVq1D07kfPKGgHpJAFGprJSmUbAYf96NwfmAxqJvTUk4EIeVsvrqwXm0p5NSaddaFiE
GJ+jgDaEIefcVy1p9BM7kIldbZ3GEKNruHR4jnDd82mSZFyjMvGhxYGKlqpud9TxtzDFuJ0fN4/d
TM6+le3uy/pFiNub8fkJWKAx/I/XH1/v2dtf+YvaSAHThyxNgdXry6dTskQfyAmIftE2mgJf/gAA
AP//AwBQSwECLQAUAAYACAAAACEAWuMRZv4AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC8B
AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBeCXSStgMAACYJAAAQAAAAAAAAAAAAAAAAACoC
AABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAP6g8PrbAAAA/QAAAA8AAAAAAAAAAAAA
AAAADgYAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAAAWBwAAAAAAABDwCAAAAEAC+Q6k
FKoGDwAN8FIAAAAAAJ8PBAAAAAQAAAAAAKEPFAAAAAEAAAAAAAAAAAABAAAAAAAgAAQAAACqDw4A
AAABAAAABwAAAAAABAgJBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BABAACiDArwCAAAAAuMAAAA
CgAA0wAL8GYAAAB/AAAA7wGAABgclwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAA
EQDLAXDGAAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADIAAAAT
ACLxBgAAAP8BAABAAAAAEPAIAAAAxQLsEGwSXwMPAA3wbAAAAAAAnw8EAAAABAAAAAAAqA8EAAAA
ZG9tVQAAoQ8WAAAABQAAAAAAAAAAAAUAAAAAACIABAAQAAAAqg8aAAAABAAAAAcAAAADAAkEBAgB
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCaBAAAQgEK8AgAAAAMjAAAwAoAANMA
C/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAIywE4YwAA0QEB
AAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADEAMwAAABMAIvHYAwAAqYPSAwAA
UEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH
70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23
jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3
VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0
r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//
AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0
X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8w
Wl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXR
gPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8A
AAD//wMAUEsDBBQABgAIAAAAIQBPj6TP0QAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/NSgMx
FIX3gu8QruBGbNKKQxmbliJIXbhprfvr5M5MNLkZktjO9OnNQnB5OH98q83onThRTDawhvlMgSBu
grHcaTi+v9wvQaSMbNAFJg0TJdisr69WWJtw5j2dDrkTZYRTjRr6nIdaytT05DHNwkBcvDZEj7nI
2EkT8VzGvZMLpSrp0XJ56HGg556a78OP13BpLyoe7xS73XKy49v2o/oanNa3N+P2CUSmMf+H/9qv
RsPisZo/gGh302e0Zo8pU9RQkApggQO5/gUAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBP
j6TP0QAAAPAAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAABQMAAAAAAAAQ8AgAAAAiBloHWgcICg8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcAQAAA
AAAAAAAAAAAeAAEAAQAAAAAADTAPAATwgAAAAEIBCvAIAAAADYwAAAAKAADDAAvwWAAAAH8AAADv
AYUAAgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAQAACM4BBgAAAP8BGAAYAD8DCAAIAIDD
EAAAAL8DAAACAEwAaQBuAGUAIAAxADQAAAAAABDwCAAAAIoECQK7DYoEDwAE8FQFAAASAArwCAAA
AA6MAAAACgAA4wAL8G4AAAB/AAAA7wGAADAnlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQA
BACBAQQAAAi/ARAAEADAAQykKQD/AQgAGAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBn
AGwAZQAgADEANQAAACMAIvHnAwAA/wEAAEAAqYPbAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCH+As/
2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9RS8MwFIXfBf9DuIJvLl1xU+qyMQWp4Itrdfh4
19ylxeZmJHHt/PWGPejj4Ry+w7dYjbYXR/Khc6xgOslAEDdOd2wUvNfPN/cgQkTW2DsmBScKsFpe
Xiyw0G7gDR2raESCcChQQRvjoZAyNC1ZDBN3IE7d3nmLMUVvpPY4JLjtZZ5lc2mx4/TQ4oGeWmq+
qm+r4MP0Jh/q8vPnrW7cuqx2d9v4qtT11bh+ABFpjP/jR7Pl2+GvPKNetIJ8Np/OQOzL0853eoMh
kleQ/JJtMgW5/AUAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAA
AAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCH+As/2gAAAP0AAAAPAAAA
AAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADgMAAAAAAAAQ8AgA
AADFAkcDuw0CBA8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcERAAAAAAAAAAAAAAlAAEAAQAA
AAAADTAPAA3wkwAAAAAAnw8EAAAABAAAAAAAqA8dAAAAVXNlciBzcGFjZSB0b29scyAoRk1BL21j
ZWxvZykAAKEPGAAAAB4AAAAAAAAAAAAeAAAAAQAiAAEABAAOAAAAqg8mAAAAFgAAAAYAAAAJBAQI
BgAAAAcAAAADAAkEBAgCAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCbBAAAQgEK
8AgAAAAPjAAAAAoAANMAC/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEA
wAEBAAAIywE4YwAA0AEBAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADEANgAA
ABMAIvHZAwAAqYPTAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv
9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q
50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9
QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhd
jr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVs
c2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnC
ruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ
1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB
9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCsVTpU0gAAAPAAAAAPAAAAZHJzL2Rv
d25yZXYueG1sRI/NasJAFIX3Bd9huEJ3daJgkNRRilhMcVESu3F3zVyT0MydMDM1ydt3FoUuD+eP
b7sfTSce5HxrWcFykYAgrqxuuVbwdXl/2YDwAVljZ5kUTORhv5s9bTHTduCCHmWoRRxhn6GCJoQ+
k9JXDRn0C9sTR+9uncEQpauldjjEcdPJVZKk0mDL8aHBng4NVd/lj1HwwfY83MrNOT/y53RaX8dr
nhZKPc/Ht1cQgcbwH/5r51rBap0uUxD303RzrS7QB3IKIlIEjHAgd78AAAD//wMAUEsBAi0AFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ
SwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQ
SwECLQAUAAYACAAAACEArFU6VNIAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYu
eG1sUEsFBgAAAAADAAMAtwAAAAYDAAAAAAAAEPAIAAAAcAuBD4IPEw0PABHwLAAAAA8AFBAkAAAA
AQDxDxwAAAAAAAAHAEAAAAAAAAAAAAAAAgABAAEAAAAAAA0wDwAE8JwEAABCAQrwCAAAABGMAACA
CgAA0wAL8F4AAAB/AAAA7wGFAAIAAACHAAEAAAC/AAQABAB/AQAAAQC/AQAAEQDAAQIAAAjLAThj
AADQAQEAAAD/ARgAGAA/AwgACACAwxAAAAC/AwAAAgBMAGkAbgBlACAAMQA4AAAAEwAi8doDAACp
g9QDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDP
TsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3Bd
VqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdAB
zQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6
IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/
AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg
+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1c
L8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+
9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg
0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAIXok+zTAAAA8AAAAA8AAABkcnMvZG93bnJldi54bWxE
j8FOwzAMhu9IvENkJG4sXSUm6JZNExKDI9uA7Wgarw1tnCpJ1+7tCRISR+v3/9nfYjXaVpzJB+NY
wXSSgSAunTZcKXjfP989gAgRWWPrmBRcKMBqeX21wEK7gbd03sVKJAiHAhXUMXaFlKGsyWKYuI44
ZSfnLcY0+kpqj0OC21bmWTaTFg2nCzV29FRT2ex6qyBb9/33R7M5vA3RbPJPd3zsmqNStzfjeg4i
0hj/l//ar1pBfj+bpn9PL5cvb/QWQySfaPArmORALn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh
9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEAheiT7NMAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA
AAADAAMAtwAAAAcDAAAAAAAAEPAIAAAAIgbYDNgMcAgPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAA
AAAHBEAAAAAAAAAAAAAAGQABAAEAAAAAAA0wDwAE8JsEAABCAQrwCAAAABKMAACACgAA0wAL8F4A
AAB/AAAA7wGFAAIAAACHAAEAAAC/AAQABAB/AQAAAQC/AQAAEQDAAQIAAAjLAThjAADRAQEAAAD/
ARgAGAA/AwgACACAwxAAAAC/AwAAAgBMAGkAbgBlACAAMQA5AAAAEwAi8dkDAACpg9MDAABQSwME
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD
5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbe
t0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN
50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXy
N+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBL
AwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5Q
xojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u
5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0
p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//
AwBQSwMEFAAGAAgAAAAhAIUiVAvSAAAA8AAAAA8AAABkcnMvZG93bnJldi54bWxEj11LwzAUhu8F
/0M4gncu7aDF1WVDikMvBN0Udntsztpoc1KSuLb/3lwIu3x5v3jW28n24kw+GMcK8kUGgrhx2nCr
4PNjd3cPIkRkjb1jUjBTgO3m+mqNlXYj7+l8iK1IIxwqVNDFOFRShqYji2HhBuLknZy3GJP0rdQe
xzRue7nMslJaNJweOhyo7qj5OfxaBXW5a+a37+Pq+GoK98Tle50Xo1K3N9PjA4hIU7yE/9svWsGy
KPMViNPz/OWN3mOI5BUkpASY4EBu/gAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCFIlQL
0gAAAPAAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAA
BgMAAAAAAAAQ8AgAAAAiBpEQkRAICg8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcAQAAAAAAA
AAAAAAAPAAEAAQAAAAAADTAPAATwmwQAAEIBCvAIAAAAE4wAAMAKAADTAAvwXgAAAH8AAADvAYUA
AgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAQAACMsBOGMAANEBAQAAAP8BGAAYAD8DCAAI
AIDDEAAAAL8DAAACAEwAaQBuAGUAIAAyADAAAAATACLx2QMAAKmD0wMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEAJJMtmNIAAADwAAAADwAAAGRycy9kb3ducmV2LnhtbESPwUoDMRCG74LvEEbwIjZxwaWs
TUsRpB68tNb7uJndjSaTJYntbp/eHASPM/P/3/CtNpN34kQx2cAaHhYKBHEbjOVew/H95X4JImVk
gy4waZgpwWZ9fbXCxoQz7+l0yL0oEE4NahhyHhspUzuQx7QII3G5dSF6zGWMvTQRzwXunayUqqVH
y+XDgCM9D9R+H368hkt3UfF4p9jtlrOd3rYf9dfotL69mbZPIDJN+T/81341GqrHuioC3W7+jNbs
MWWKGsqmCBY5kOtfAAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAA
AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACSTLZjSAAAA8AAAAA8A
AAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAGAwAAAAAAABDw
CAAAAAIEEAgQCBIFDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBAAAAAAAAAAAAAACQAAQAB
AAAAAAANMA8ABPA7BQAAEgAK8AgAAAAUjAAAAAoAAOMAC/BuAAAAfwAAAO8BgACQM5cKgQAAAAAA
ggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAgQEEAAAIvwEQABAAwAEMpCkA/wEIABgAPwMAAAgAgMMa
AAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyADEAAAAjACLx5wMAAP8BAABAAKmD2wMAAFBL
AwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9I
vEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46H
Bt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1
q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+E
dfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMA
UEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U
7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpd
Dm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDx
yTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA
//8DAFBLAwQUAAYACAAAACEALM+wstoAAAD9AAAADwAAAGRycy9kb3ducmV2LnhtbESPTUsDMRRF
94L/ITzBjdhMB6wyNi1FkBHd2BkVl6+T12QwH0MSO1N/vaELXV7u5VzOcj1Zww4UYu+dgPmsAEau
87J3SsBb+3h9BywmdBKNdyTgSBHWq/OzJVbSj25LhyYpliEuVihApzRUnMdOk8U48wO53O19sJhy
DIrLgGOGW8PLolhwi73LDxoHetDUfTXfVsC7Mqoc2/rz57Xt/KZudrcf6UWIy4tpcw8s0ZT+x1d6
eDb6rzyhnqSA8mZRzoHt6+Mu9HKLMVEQkP2ybTYFvvoFAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh
9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA
CAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA
CAAAACEALM+wstoAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA
AAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAEgV3Bk0JIgYPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAA
AAAHBEQAAAAAAAAAAAAAIAABAAEAAAAAAA0wDwAN8HoAAAAAAJ8PBAAAAAQAAAAAAKgPEAAAAG1j
ZWxvZyBpbnRlcmZhY2UAAKEPGAAAABEAAAAAAAAAAAARAAAAAQAiAAEABAAOAAAAqg8aAAAABgAA
AAcAAAADAAkEBAgLAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPA8BQAAEgAK8AgA
AAAVjAAAAAoAANMAC/BoAAAAfwAAAO8BgABUPpcKhQACAAAAhwABAAAAvwAEAAQAgQEEAAAIvwEA
ABAAwAEMpCkAywHRVgAA/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAAyADQAAAAjACLx5wMAAP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAA
AFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr2
9qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMs
DYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0
uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8
/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S
+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63l
E1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/
UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAUlbTLdoAAAD9
AAAADwAAAGRycy9kb3ducmV2LnhtbESPwUrDQBRF94L/MDzBjdiJIQ0SOy0ilGYRkLZWt8/MaxLM
vIkzY5r+vYOLurzcy7mcxWoyvRjJ+c6ygodZAoK4trrjRsHbfn3/CMIHZI29ZVJwJg+r5fXVAgtt
T7ylcRcaESHsC1TQhjAUUvq6JYN+Zgfi2B2tMxhidI3UDk8RbnqZJkkuDXYcH1oc6KWl+mv3YxRk
73n//XrIdvuPkTmpynV5pw9K3d5Mz08gAk3hfzyvsk1eXco/VKkVpPM8zUAcN+dP1+kt+kBOQfSL
ttEU5PIXAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAA
AAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAUlbTLdoAAAD9AAAADwAAAAAAAAAA
AAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAkAou
B1wKRgsPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAAAwABAAEAAAAAAA0w
DwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAE1DRSBTb2Z0aXJxAAChDxgAAAAMAAAAAAAAAAAA
DAAAAAEAIgABAAQADgAAAKoPJgAAAAQAAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIAQAAAAYAAAAJ
BAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwHwUAABIACvAIAAAAFowAAAAKAADTAAvwaAAAAH8A
AADvAYAAcEmXCoUAAgAAAIcAAQAAAL8ABAAEAIEBBAAACL8BAAAQAMABDKQpAMsB0VYAAP8BCAAY
AD8DAAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAzAAAAIwAi8egDAAD/AQAA
QACpg9wDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1s
fJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8
N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmX
cdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMieP
OzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWP
T2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMw
DAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxi
ni1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkv
NxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc
4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhADxwkpLbAAAA/QAAAA8AAABkcnMvZG93bnJldi54
bWxEj1FLwzAUhd8F/0O4gi/iUussUpcNEYYVhLHOzddrc9eWNTc1iV337xd80MfDOXyHb7YYTScG
cr61rOBukoAgrqxuuVbwsVnePoLwAVljZ5kUnMjDYn55McNc2yOvaShDLSKEfY4KmhD6XEpfNWTQ
T2xPHLu9dQZDjK6W2uExwk0n0yTJpMGW40ODPb00VB3KH6Ngusu679V2Wm4+B+bkvVgWN3qr1PXV
+PwEItAY/seH3duqNn/lL6rQCtKHLL0HsX89fblWr9EHcgqiX7SNpiDnZwAAAP//AwBQSwECLQAU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht
bFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVs
c1BLAQItABQABgAIAAAAIQA8cJKS2wAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJl
di54bWxQSwUGAAAAAAMAAwC3AAAADwMAAAAAAAAQ8AgAAACQCkcO3RBFCw8AEfAsAAAADwAUECQA
AAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAAEAAEAAQAAAAAADTAPAA3wYwAAAAAAnw8EAAAABAAA
AAAAqA8HAAAATUNFIElTUgAAoQ8YAAAACAAAAAAAAAAAAAgAAAABACIAAQAEAA4AAACqDwwAAAAI
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCcBAAAQgEK8AgAAAAXjAAAAAoAANMA
C/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAIywGcMQAA0AEB
AAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADIANQAAABMAIvHaAwAAqYPUAwAA
UEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH
70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23
jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3
VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0
r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//
AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0
X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8w
Wl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXR
gPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8A
AAD//wMAUEsDBBQABgAIAAAAIQC1OAPK0wAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9fS8Mw
FMXfBb9DuIIvwyVWWka3bAzBP4gI6wRfr81dW9bc1CR23bc3guDj4ZzzO5zVZrK9GMmHzrGG27kC
QVw703Gj4X3/cLMAESKywd4xaThTgM368mKFpXEn3tFYxUYkCIcSNbQxDqWUoW7JYpi7gTh5B+ct
xiR9I43HU4LbXmZKFdJix2mhxYHuW6qP1bfVoKovVbzExzDKuzf+ePUz3OYzra+vpu0SRKQp/of/
2s9GQ5YXWQ7i8HT+9J3ZYYjkEw1+D6ZzINc/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
ALU4A8rTAAAA8AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwAD
ALcAAAAHAwAAAAAAABDwCAAAAOsKXQpDDusKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwRE
AAAAAAAAAAAAAAcAAQABAAAAAAANMA8ABPApBQAAEgAK8AgAAAAYjAAAAAoAAOMAC/BuAAAAfwAA
AO8BgAAUVJcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAgQEEAAAIvwEQABAAwAEMpCkA
/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyADYAAAAjACLx5gMA
AP8BAABAAKmD2gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA/tdT9NkAAAD9AAAADwAAAGRycy9kb3du
cmV2LnhtbESPTUvDQBRF94L/YXiCOzsxYJS001IEiSKITVS6fM28fGBmJsw8m9Rf7+BCl5d7OZez
2sxmEEfyoXdWwfUiAUG2drq3rYK36uHqDkRgtBoHZ0nBiQJs1udnK8y1m+yOjiW3IkJsyFFBxzzm
Uoa6I4Nh4UaysWucN8gx+lZqj1OEm0GmSZJJg72NDx2OdN9R/Vl+GQXv7dCmU1Xsv1+r2m2L8nD7
wc9KXV7M2yUIppn/x0/8wg3/lb+oR60gvcnSDERTnA6+1zsMTF5B9Iu20RTk+gcAAP//AwBQSwEC
LQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8u
cmVsc1BLAQItABQABgAIAAAAIQD+11P02QAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93
bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADQMAAAAAAAAQ8AgAAAASBTAKuw0jBg8AEfAsAAAADwAU
ECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAARAAEAAQAAAAAADTAPAA3waQAAAAAAnw8EAAAA
BAAAAAAAqA8NAAAAUFYgR3Vlc3QgIE1DRQAAoQ8YAAAADgAAAAAAAAAAAA4AAAABACIAAQAEAA4A
AACqDwwAAAAOAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPA4BQAAEgAK8AgAAAAZ
jAAAAAoAAPMAC/B0AAAAfwAAAO8BgAC8XpcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQA
gQECAAAIvwEQABAAwAECAAAIywHRVgAA/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABh
AG4AZwBsAGUAIAAyADcAAAAjACLx5gMAAP8BAABAAKmD2gMAAFBLAwQUAAYACAAAACEA2+H2y+4A
AACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQew
EreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt
5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9
bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a
2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxk
svXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAu
sahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+s
PNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA
Gm/kMNkAAAD9AAAADwAAAGRycy9kb3ducmV2LnhtbESPUUvDMBSF3wX/Q7iCby5t1U3qsuEU0SnC
OgVfY3LXhDU3JYlr9+8NPujj4Ry+wzdfjq5jBwzRehJQTgpgSMprS62Aj/fHixtgMUnSsvOEAo4Y
Ybk4PZnLWvuBGjxsU8syhGItBZiU+przqAw6GSe+R8rdzgcnU46h5TrIIcNdx6uimHInLeUHI3u8
N6j2228nwK2uHjakL60yzWv3WRr19rJSQpyfjXe3wBKO6X+8bk25H/7KX9SzFlBdT6sZsN3T8StY
3ciYMAjIftk2mwJf/AAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAA
AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAab+Qw2QAAAP0AAAAP
AAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADQMAAAAAAAAQ
8AgAAABwCCMMNhAlCQ8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAATAAEA
AQAAAAAADTAPAA3wcgAAAAAAnw8EAAAABAAAAAAAqA8EAAAAdk1DRQAAoQ8cAAAABQAAAAAAAAAA
AAUAAAABACYAAQAEAA4AAAAAAwAAqg8aAAAABAAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgAAKYP
DAAAAPAAAADUAdAC8AMQBQ8ABPCdBAAAQgEK8AgAAAAajAAAAAoAANMAC/BeAAAAfwAAAO8BhQAC
AAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAIywE4YwAA0QEBAAAA/wEYABgAPwMIAAgA
gMMQAAAAvwMAAAIATABpAG4AZQAgADIAOAAAABMAIvHbAwAAqYPVAwAAUEsDBBQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDh
CAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/U
wIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjH
jympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrF
mJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGV
xCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yz
ra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23z
HztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAI
AAAAIQD6+z7E1AAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8MwDIbvg/0Ho0Fvq5OUdCOr
W8pY2RcM0g161WI1CY1lY3tt8u/nw2DHF716pGe1Gc0gzuRDb1lBPs9AEDdW99wq+Prc3d6DCBFZ
42CZFEwUYLO+vlphpe2FazrvYysShEOFCroYXSVlaDoyGObWEafZ0XqDMUXfSu3xkuBmkEWWLaXB
ntOFDh09dtSc9j9Gwdv0keuFKcu6fXJ3783i8Oryg1Kzm3H7ACLSGP/Lf9svWkFRLov07/F5+va9
rjFE8gqSUhJMciDXvwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAA
AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQD6+z7E1AAAAPAAAAAP
AAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACAMAAAAAAAAQ
8AgAAAAYCxkRKRIYCw8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAAJAAEA
AQAAAAAADTAPAATwJgUAABIACvAIAAAAG4wAAAAKAADjAAvwbgAAAH8AAADvAYAArEqXCoEAAAAA
AIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAAARAMABDKQpAMsB0VYAAP8BCAAYAD8DAAAIAIDD
GgAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgA5AAAAIwAi8eQDAAD/AQAAQACpg9gDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAP6S5JzXAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj01LAzEU
RfeC/yE8wZ1NHLDotGlRwdaddFSsu+fkzQdNXoYkTqf/3uBCl5d7OZezXE/OipFC7D1ruJ4pEMS1
Nz23Gt5en65uQcSEbNB6Jg0nirBenZ8tsTT+yDsaq9SKDOFYooYupaGUMtYdOYwzPxDnrvHBYcox
tNIEPGa4s7JQai4d9pwfOhzosaP6UH07DZvaje8Phj+sMeFzM4222b9YrS8vpvsFiERT+h/jQW0r
9Vf+op6NhuJmXtyBaLanr9CbHcZEQUP2y7bZFOTqBwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA
AAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA
AAAhAP6S5JzXAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA
AwADALcAAAALAwAAAAAAABDwCAAAADYKVhIcFHMLDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAA
BwBAAAAAAAAAAAAAAAgAAQABAAAAAAANMA8ADfBoAAAAAACfDwQAAAAEAAAAAACoDwwAAABSZXNl
dCBzeXN0ZW0AAKEPGAAAAA0AAAAAAAAAAAANAAAAAQAiAAEABAAMAAAAqg8MAAAADQAAAAYAAAAJ
BAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwMgUAAKIMCvAIAAAAHIwAAAAKAADTAAvwZgAAAH8A
AADvAYAAnHOXCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABgAGAL8BAAARAMsBcMYAAP8BAAAY
AD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADMAMgAAACMAIvHnAwAA/wEAAEAA
qYPbAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQ
z07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdw
XVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQ
Ac0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsy
uiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09s
vwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG
4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4t
XC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcT
vvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA4
4NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQB03VUh2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1s
RI/LTsMwFET3SPyDdZHYIOpgaIVC3QrxEKwKTfiAS3wTh8Z2sE0efD0WC1iOZnRGZ72dTMcG8qF1
VsLFIgNGtnKqtY2Et/Lx/BpYiGgVds6ShJkCbDfHR2vMlRvtnoYiNixBbMhRgo6xzzkPlSaDYeF6
sqmrnTcYU/QNVx7HBDcdF1m24gZbmx409nSnqToUX0ZC/V264WrY6Y/yZX4Qn8vXXpyNUp6eTLc3
wCJN8X98fxAFz/7KX9SzkiCWq0sBrH6a332r9hgieQnJL9kmU+CbHwAAAP//AwBQSwECLQAUAAYA
CAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL
AQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BL
AQItABQABgAIAAAAIQB03VUh2gAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54
bWxQSwUGAAAAAAMAAwC3AAAADgMAAAAAAAAQ8AgAAADYBnIQZRKYBw8AEfAsAAAADwAUECQAAAAB
APEPHAAAAAAAAAcEAAAAAAAAAAAAAAAVAAEAAQAAAAAADTAPAA3weQAAAAAAnw8EAAAABAAAAAAA
qA8RAAAAaHZtIE1DRSBpbmplY3Rpb24AAKEPFgAAABIAAAAAAAAAAAASAAAAAAAiAAQACgAAAKoP
GgAAAAMAAAAHAAAAAwAJBAQIDwAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwMQUA
AKIMCvAIAAAAHYwAAAAKAADTAAvwZgAAAH8AAADvAYAAyH2XCoEAAAAAAIIAAAAAAIMAAAAAAIQA
AAAAAL8ABgAGAL8BAAARAMsBcMYAAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABC
AG8AeAAgADMAMwAAACMAIvHnAwAA/wEAAEAAqYPbAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQB8PjUd
2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LTsMwFET3SPyDdZHYIOrg0gqFuhXiIVgBTfiA
S3wTh8Z2sE0efD0WC1iOZnRGZ7ObTMcG8qF1VsLFIgNGtnKqtY2Et/Lh/ApYiGgVds6ShJkC7LbH
RxvMlRvtnoYiNixBbMhRgo6xzzkPlSaDYeF6sqmrnTcYU/QNVx7HBDcdF1m25gZbmx409nSrqToU
X0ZC/V264XJ41h/ly3wvPlevvTgbpTw9mW6ugUWa4v/47iAKnv2Vv6gnJUGs1sslsPpxfvet2mOI
5CUkv2SbTIFvfwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAA
AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAA
AAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQB8PjUd2gAAAP0AAAAPAAAA
AAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADgMAAAAAAAAQ8AgA
AADgBioK1QugBw8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEBAAAAAAAAAAAAAAWAAEAAQAA
AAAADTAPAA3weAAAAAAAnw8EAAAABAAAAAAAqA8QAAAAcHYgTUNFIGluamVjdGlvbgAAoQ8WAAAA
EQAAAAAAAAAAABEAAAAAACIABAAKAAAAqg8aAAAAAgAAAAcAAAADAAkEBAgPAAAABgAAAAkEBAgA
AKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAmBQAAogwK8AgAAAAejAAAAAoAANMAC/BmAAAAfwAAAO8B
gACUhpcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMA
AAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMwA0AAAAIwAi8egDAAD/AQAAQACpg9wD
AABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMw
DIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCI
jbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H
0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZ
A/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA
//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2Dv
YHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3
DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e
5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPj
LwAAAP//AwBQSwMEFAAGAAgAAAAhAC3+LxbbAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tO
wzAURPeV+g/WRWJTUYfQVlWoWyEEAjZAGj7gEt/EKbEdbJMHX4/FApajGZ3R2R1G3bKenG+sEXC5
TICRKa1sTC3grbi/2ALzAY3E1hoSMJGHw34+22Em7WBy6o+hZhFifIYCVAhdxrkvFWn0S9uRiV1l
ncYQo6u5dDhEuG55miQbrrEx8UFhR7eKyo/jlxZQfRe2X/XP6lS8THfp5/q1SxeDEOdn4801sEBj
+B/npVNP27/yF/UoBaTrzdUKWPUwvbtG5ugDOQHRL9pGU+D7HwAAAP//AwBQSwECLQAUAAYACAAA
ACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt
ABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQIt
ABQABgAIAAAAIQAt/i8W2wAAAP0AAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAMAAwC3AAAADwMAAAAAAAAQ8AgAAAAXByoGlQd3Bw8AEfAsAAAADwAUECQAAAABAPEP
HAAAAAAAAAcEAAAAAAAAAAAAAAAfAAEAAQAAAAAADTAPAA3wbAAAAAAAnw8EAAAABAAAAAAAqA8E
AAAAdklSUQAAoQ8WAAAABQAAAAAAAAAAAAUAAAAAACIABAAKAAAAqg8aAAAABAAAAAcAAAADAAkE
BAgBAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAHBQAAEgAK8AgAAAAfjAAAAAoA
AMMAC/BiAAAAfwAAAO8BgACYkZcKhQACAAAAhwABAAAAvwAEAAQAvwEAABEAwAEMpCkAywGfbwAA
/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzADUAAAAjACLx5wMA
AP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA64atKtoAAAD9AAAADwAAAGRycy9kb3du
cmV2LnhtbESPUWvCMBSF3wf+h3CFvc1US510RimDzSGzYrcfcG2uTbFJuiTT+u8X9rA9Hs7hO3zL
9aA7diHnW2sETCcJMDK1la1pBHx+vDwsgPmARmJnDQm4kYf1anS3xFzaqznQpQoNixDjcxSgQuhz
zn2tSKOf2J5M7E7WaQwxuoZLh9cI1x2fJcmca2xNfFDY07Oi+lx9awFlzct9xb+yYps+9u/qdVMs
ZCrE/XgonoAFGsL/eB+O23L3V/6i3qSAWTZPM2Cnze3oWnlAH8gJiH7RNpoCX/0AAAD//wMAUEsB
Ai0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz
XS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMv
LnJlbHNQSwECLQAUAAYACAAAACEA64atKtoAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rv
d25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAQwg3AmcFcwsPABHwLAAAAA8A
FBAkAAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAADQABAAEAAAAAAA0wDwAN8FIAAAAAAJ8PBAAA
AAQAAAAAAKEPFgAAAAEAAAAAAAAAAAABAAAAAAAiAAQADAAAAKoPDAAAAAEAAAAGAAAACQQECAAA
pg8MAAAA8AAAANQB0ALwAxAFDwAE8DUFAAASAArwCAAAACCMAAAACgAA4wAL8G4AAAB/AAAA7wGA
AEySlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQAAEQDAAQykKQDLAdFWAAD/AQgA
GAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMANgAAACMAIvHmAwAA/wEA
AEAAqYPaAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnht
bHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkFori
PDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wp
l3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDIn
jzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2l
j09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrD
MAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYc
Yp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5
LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2
HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQD4vJiS2QAAAP0AAAAPAAAAZHJzL2Rvd25yZXYu
eG1sRI9NSwMxFEX3gv8hPMGdzVjpIGPTooLVxYC0Kurumbz5wORlSOJ0+u8NXejyci/ncpbryVkx
Uoi9ZwWXswIEsfam51bB68vDxTWImJANWs+k4EAR1qvTkyVWxu95S+MutSJDOFaooEtpqKSMuiOH
ceYH4tw1PjhMOYZWmoD7DHdWzouilA57zg8dDnTfkf7e/TgFG+3GtzvD79aY8LmZRtt8PFulzs+m
2xsQiab0P651nRb1X3lEPRkF80V5VYJoHg9foTdbjImCguyXbbMpyNUvAAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAPi8mJLZAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAANAwAAAAAAABDwCAAAAGMKZAI6BUYLDwAR8CwAAAAPABQQJAAA
AAEA8Q8cAAAAAAAABwRAAAAAAAAAAAAAAAwAAQABAAAAAAANMA8ADfB1AAAAAACfDwQAAAAEAAAA
AACoDwsAAABjcHUgb2ZmbGluZQAAoQ8YAAAADAAAAAAAAAAAAAwAAAABACIAAQAEAA4AAACqDxoA
AAADAAAABwAAAAMACQQECAkAAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CgFAAAS
AArwCAAAACGMAAAACgAA4wAL8G4AAAB/AAAA7wGAAHyklwqBAAAAAACCAAAAAACDAAAAAACEAAAA
AAC/AAQABAC/AQAAEQDAAQykKQDLAdFWAAD/AQgAGAA/AwAACACAwxoAAAC/AwAAAgBSAGUAYwB0
AGEAbgBnAGwAZQAgADMANwAAACMAIvHmAwAA/wEAAEAAqYPaAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQDE5fXy2QAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9LSwMxFIX3gv8hXMGdzVi1lbFpUcFq
V9LWvnbXyZ0HJjdDEqfTf29wocvDOXyHbzLrrREd+dA4VnA9yEAQF043XCn4WL9c3YMIEVmjcUwK
ThRgNj0/m2Cu3ZGX1K1iJRKEQ44K6hjbXMpQ1GQxDFxLnLrSeYsxRV9J7fGY4NbIYZaNpMWG00ON
LT3XVHytvq2CeWG7zZPmndHaH+Z9Z8r9u1Hq8qJ/fAARqY//4wMvbrf8V/6i3rSC4d3oZgyifD19
+kYvMUTyCpJfsk2mIKc/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAA
AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAMTl9fLZAAAA/QAA
AA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAANAwAAAAAA
ABDwCAAAAFMJZAI6BTYKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwRAAAAAAAAAAAAAAAsA
AQABAAAAAAANMA8ADfBoAAAAAACfDwQAAAAEAAAAAACoDwwAAABwYWdlIG9mZmxpbmUAAKEPGAAA
AA0AAAAAAAAAAAANAAAAAQAiAAEABAAMAAAAqg8MAAAADQAAAAYAAAAJBAQIAACmDwwAAADwAAAA
1AHQAvADEAUPAATwEgUAAKIMCvAIAAAAIowAAAAKAACjAAvwVAAAAH8AAADvAYAA/K2XCoUAAgAA
AL8ABgAGAL8BAAARAMsBcMYAAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8A
eAAgADMAOAAAACMAIvHoAwAA/wEAAEAAqYPcAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQA96Tmd2wAA
AP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9LS8NAFIX3gv9huIIbsRMjLSXttPhA6kY0sRTc3WZu
MiGZBzNjmv57Bxe6vJzLd8633k56YCP50Fkj4G6WASNTW9mZVsD+8+V2CSxENBIHa0jAmQJsN5cX
ayykPZmSxiq2LEFMKFCAitEVnIdakcYws45MyhrrNcZ0+pZLj6cE1wPPs2zBNXYmNSh09KSo7qtv
LeBdlfuseWvHXodqvrv5cv3j0glxfTU9rIBFmuL/8/Ph8IH5X/iLepUC8vniPo1vduej72SJIZIX
kPySbTIFvvkBAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAA
AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAA
AAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAPek5ndsAAAD9AAAADwAAAAAA
AAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA8DAAAAAAAAEPAIAAAA
QwgLAp4F8AgPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBAQAAAAAAAAAAAAADgABAAEAAAAA
AA0wDwAN8GoAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFJlY292ZXIgYWN0aW9uAAChDxgAAAAPAAAA
AAAAAAAADwAAAAEAIgABAAQADAAAAKoPDAAAAA8AAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALw
AxAFDwAE8JsEAABCAQrwCAAAACOMAACACgAA0wAL8F4AAAB/AAAA7wGFAAIAAACHAAEAAAC/AAQA
BAB/AQAAAQC/AQAAEQDAAQIAAAjLAThjAADRAQEAAAD/ARgAGAA/AwgACACAwxAAAAC/AwAAAgBM
AGkAbgBlACAAMwA5AAAAEwAi8dkDAACpg9MDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMA
AABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK
9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXT
LA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurh
tLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl
/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAA
CwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseO
kvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut
5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo
/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAHAT0D/SAAAA
8AAAAA8AAABkcnMvZG93bnJldi54bWxEjz1PwzAQhnck/oN1SCyIOimkglC3QnyoHVhaGDoe8TWJ
iM/BPpL03+MBifHV+6VnuZ5cpwYKsfVsIJ9loIgrb1uuDXy8v17fgYqCbLHzTAZOFGG9Oj9bYmn9
yDsa9lKrNMKxRAONSF9qHauGHMaZ74mTd/TBoSQZam0DjmncdXqeZQvtsOX00GBPTw1VX/sfZyDk
b8NtzsXBv3h5zscNHb6LK2MuL6bHB1BCk/yH/9pba2BeLG7uQR03p8/Q2h1GoWAgISXABAd69QsA
AP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8B
AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBwE9A/0gAAAPAAAAAPAAAAAAAAAAAAAAAAAAcC
AABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABgMAAAAAAAAQ8AgAAAAiBsYLxgsICg8A
EfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcEQAAAAAAAAAAAAAAQAAEAAQAAAAAADTAPAATwmwQA
AEIBCvAIAAAAJIwAAIAKAADTAAvwXgAAAH8AAADvAYUAAgAAAIcAAQAAAL8ABAAEAH8BAAABAL8B
AAARAMABAgAACMsBOGMAANABAQAAAP8BGAAYAD8DCAAIAIDDEAAAAL8DAAACAEwAaQBuAGUAIAA0
ADAAAAATACLx2QMAAKmD0wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50
X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/
f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0
o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBl
U72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94Z
KrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMv
LnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj
0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vy
m0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQn
M1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEArQcm99IAAADwAAAADwAAAGRy
cy9kb3ducmV2LnhtbESPwU7DMAyG70i8Q2QkLoilDJhYWTYBEhq7sXYPYBqvrUicKglbt6fHBySO
tv//s77FavROHSimPrCBu0kBirgJtufWwK5+v30ClTKyRReYDJwowWp5ebHA0oYjb+lQ5VYJhFOJ
Brqch1Lr1HTkMU3CQCy3fYges4yx1TbiUeDe6WlRzLTHnuVDhwO9ddR8Vz/eQDrHzc1ru652uq4H
d+/m9HmeG3N9Nb48g8o05v/wX/vDGpg+zh5EYL8+fcXebjFligZkI4IiB3r5CwAA//8DAFBLAQIt
ABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAK0HJvfSAAAA8AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3du
cmV2LnhtbFBLBQYAAAAAAwADALcAAAAGAwAAAAAAABDwCAAAACIGrg+uD3AIDwAR8CwAAAAPABQQ
JAAAAAEA8Q8cAAAAAAAABwBAAAAAAAAAAAAAABcAAQABAAAAAAANMA8ABPCVBAAAQgEK8AgAAAAl
jAAAgAoAAMMAC/BYAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEAwAEBAAAI
0QEBAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADQAMQAAABMAIvHZAwAAqYPT
AwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07D
MAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVag
iI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0O
B9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBX
WQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAA
AP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg
72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/H
tw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9
HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz
4y8AAAD//wMAUEsDBBQABgAIAAAAIQBwrIJI0gAAAPAAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9B
S8QwFITvgv8hPMGbm+6iRepmlyKsiuihqwePz+Y1DTYvJYm7rb/eCMIeh5n5hllvJzeIA4VoPStY
LgoQxK3Xlo2C97fd1S2ImJA1Dp5JwUwRtpvzszVW2h+5ocM+GZEhHCtU0Kc0VlLGtieHceFH4ux1
PjhMWQYjdcBjhrtBroqilA4t54UeR7rvqf3afzsFxUNnTL0r5xf7YX5C3ejZPr8qdXkx1XcgEk3p
FP5vP2kFq5vyegmie5w/g9UNxkQh0+DvYD4HcvMLAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAcKyCSNIAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAYDAAAAAAAAEPAIAAAAUwnyCPIICAoPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAH
AEAAAAAAAAAAAAAAHAABAAEAAAAAAA0wDwAE8BcFAACiDArwCAAAACaMAAAACgAA0wAL8GYAAAB/
AAAA7wGAAIy5lwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDGAAD/AQAA
GAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0ADIAAAAjACLx6AMAAP8BAABA
AKmD3AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8
kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3
cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx
0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487
MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9P
bL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAM
BuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKe
LVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83
E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzg
OODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEALAlj79sAAAD9AAAADwAAAGRycy9kb3ducmV2Lnht
bESPy07DMBRE90j8g3WR2CDqYLUFhboVQiBYUdqw6c7EN3FofB1skwdfj8UClqMZndFZbUbbsh59
aBxJuJplwJBKpxuqJbwVj5c3wEJUpFXrCCVMGGCzPj1ZqVy7gXbY72PNEoRCriSYGLuc81AatCrM
XIeUusp5q2KKvubaqyHBbctFli25VQ2lB6M6vDdYHvdfVkL1Xbh+3r+Yj2I7PYjPxWsnLgYpz8/G
u1tgEcf4Pz4eyFwf/spf1LOWIBbLuQBWPU3vvtE7FSJ6Cckv2SZT4OsfAAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhACwJY+/bAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAPAwAAAAAAABDwCAAAAAUHqwzoDWUHDwAR8CwAAAAPABQQJAAA
AAEA8Q8cAAAAAAAABwQAAAAAAAAAAAAAABoAAQABAAAAAAANMA8ADfBdAAAAAACfDwQAAAAEAAAA
AACoDwMAAAAjR1AAAKEPFgAAAAQAAAAAAAAAAAAEAAAAAAAiAAQACgAAAKoPDAAAAAQAAAAGAAAA
CQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CgFAACiDArwCAAAACeMAAAACgAA0wAL8GYAAAB/
AAAA7wGAAMjDlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDGAAD/AQAA
GAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0ADMAAAAjACLx6AMAAP8BAABA
AKmD3AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8
kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3
cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx
0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487
MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9P
bL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAM
BuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKe
LVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83
E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzg
OODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAHvQw7dsAAAD9AAAADwAAAGRycy9kb3ducmV2Lnht
bESPXUvDMBiF7wX/Q3gFb2RLrevQumyIKDoQ51Z/wGvztqk2SU1iP/z1Bi/08nAOz+FZbUbdsp6c
b6wRcD5PgJEprWxMLeC1uJ9dAvMBjcTWGhIwkYfN+vhohbm0g9lTfwg1ixDjcxSgQuhyzn2pSKOf
245M7CrrNIYYXc2lwyHCdcvTJFlyjY2JDwo7ulVUfhy+tIDqu7D9on9W78Vuuks/s5cuPRuEOD0Z
b66BBRrD//hpq65M9lf+oh6lgDRbLi6AVQ/Tm2vkHn0gJyD6RdtoCnz9AwAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAB70MO3bAAAA/QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAPAwAAAAAAABDwCAAAAP8GZA6hD18HDwAR8CwAAAAPABQQJAAA
AAEA8Q8cAAAAAAAABwQAAAAAAAAAAAAAABgAAQABAAAAAAANMA8ADfBuAAAAAACfDwQAAAAEAAAA
AACoDwYAAABWTUV4aXQAAKEPFgAAAAcAAAAAAAAAAAAHAAAAAAAiAAQACgAAAKoPGgAAAAYAAAAH
AAAAAwAJBAQIAQAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwKQUAABIACvAIAAAA
KIwAAAAKAADjAAvwbgAAAH8AAADvAYAANM+XCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAE
AL8BAAARAMABDKQpAMsB0VYAAP8BCAAYAD8DAAAIAIDDGgAAAL8DAAACAFIAZQBjAHQAYQBuAGcA
bABlACAANAA0AAAAIwAi8eYDAAD/AQAAQACpg9oDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6
URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0E
EpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJN
AurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/
cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6
aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpW
C0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNC
nqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhADQW18HZ
AAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj0tLAzEUhfeC/yFcwZ3NWGrRsWlRwepC0D5E3V2T
Ow9MboYkzkz/vcGFLg/n8B2+xWp0VvQUYutZwfmkAEGsvWm5VrDf3Z9dgogJ2aD1TAoOFGG1PD5a
YGn8wBvqt6kWGcKxRAVNSl0pZdQNOYwT3xHnrvLBYcox1NIEHDLcWTktirl02HJ+aLCju4b01/bb
KVhr17/eGn6zxoSP9djb6v3ZKnV6Mt5cg0g0pv+xfrlyT8Nf+Yt6NAqmF/PZDET1cPgMrdlgTBQU
ZL9sm01BLn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAA
AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAA
AAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEANBbXwdkAAAD9AAAADwAAAAAA
AAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA0DAAAAAAAAEPAIAAAA
Qwi1B+QKUwkPABHwLAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBEQAAAAAAAAAAAAAHQABAAEAAAAA
AA0wDwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAE1TUiB0ZWxlbWV0cnkAAKEPGAAAAA4AAAAA
AAAAAAAOAAAAAQAiAAEABAAOAAAAqg8MAAAADgAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvAD
EAUPAATwmwQAAEIBCvAIAAAAKYwAAMAKAADTAAvwXgAAAH8AAADvAYUAAgAAAIcAAQAAAL8ABAAE
AH8BAAABAL8BAAARAMABAQAACMsBOGMAANABAQAAAP8BGAAYAD8DCAAIAIDDEAAAAL8DAAACAEwA
aQBuAGUAIAA0ADUAAAATACLx2QMAAKmD0wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAA
AFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr2
9qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMs
DYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0
uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8
/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S
+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63l
E1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/
UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAOZNmmtIAAADw
AAAADwAAAGRycy9kb3ducmV2LnhtbESPT2vCMBjG7wO/Q3gHu820oiKdUUQYK7ts1l28vWte027N
m5Jktn775SB4fHj+8VtvR9uJC/nQOlaQTzMQxLXTLRsFX8fX5xWIEJE1do5JwZUCbDeThzUW2g18
oEsVjUgjHApU0MTYF1KGuiGLYep64uSdnbcYk/RGao9DGrednGXZUlpsOT002NO+ofq3+rMKTquP
064yJn+f/2RdmXP5GYdSqafHcfcCItIY7+Fbu9QKZovlfAHi/Hb99q0+YIjkFSSkBJjgQG7+AQAA
//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADmTZprSAAAA8AAAAA8AAAAAAAAAAAAAAAAABwIA
AGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAGAwAAAAAAABDwCAAAACIGmAiYCEMIDwAR
8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBAAAAAAAAAAAAAACEAAQABAAAAAAANMA8ABPCbBAAA
QgEK8AgAAAAqjAAAgAoAANMAC/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEA
ABEAwAECAAAIywGfbwAA0QEBAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADQA
NwAAABMAIvHZAwAAqYPTAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/
n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSj
lD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVT
vbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkq
uyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8u
cmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPR
yNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKb
TCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCcz
VQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAMjE1Z0gAAAPAAAAAPAAAAZHJz
L2Rvd25yZXYueG1sRI/fasIwFMbvB75DOMLuZqpsdXQeRQSZN6Ooe4Cz5tgGm6RLMtv69MvFYJcf
3z9+q81gWnFjH7SzCPNZBoJt5ZS2NcLnef/0CiJEsopaZxlh5ACb9eRhRYVyvT3y7RRrkUZsKAih
ibErpAxVw4bCzHVsk3dx3lBM0tdSeerTuGnlIstyaUjb9NBQx7uGq+vpxyBsd3lvlsbcD9f5/SPf
6/K7HEvEx+mwfQMReYj/4b/2QSEsXvLnJYjL+/jltTpSiOwRElICTHAg178AAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEADIxNWdIAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAYDAAAAAAAAEPAIAAAAJQkeDh4OCAoPABHwLAAAAA8AFBAk
AAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAAFAABAAEAAAAAAA0wDwAE8JwEAABCAQrwCAAAACuM
AADACgAA0wAL8F4AAAB/AAAA7wGFAAIAAACHAAEAAAC/AAQABAB/AQAAAQC/AQAAEQDAAQEAAAjL
AThjAADRAQEAAAD/ARgAGAA/AwgACACAwxAAAAC/AwAAAgBMAGkAbgBlACAANAA4AAAAEwAi8doD
AACpg9QDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1s
fJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8
N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmX
cdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMieP
OzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWP
T2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMw
DAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxi
ni1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkv
NxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc
4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAMP/C4bTAAAA8AAAAA8AAABkcnMvZG93bnJldi54
bWxEj01LAzEQhu+C/yGM4EVsYtGlrE1LEaQevPTD+7iZ3Y0mkyWJ7W5/vTkIHl/mnWfmWa5H78SJ
YrKBNTzMFAjiJhjLnYbj4fV+ASJlZIMuMGmYKMF6dX21xNqEM+/otM+dKBBONWrocx5qKVPTk8c0
CwNxmbUheswlxk6aiOcC907OlaqkR8vlQo8DvfTUfO9/vIZLe1HxeKfYbReTHd83H9XX4LS+vRk3
zyAyjfm//Lf9ZjTMn6rH8m+7nT6jNTtMmaKGolQEixzI1S8AAAD//wMAUEsBAi0AFAAGAAgAAAAh
ANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAU
AAYACAAAACEAw/8LhtMAAADwAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsF
BgAAAAADAAMAtwAAAAcDAAAAAAAAEPAIAAAAvgpnBdIGvgoPABHwLAAAAA8AFBAkAAAAAQDxDxwA
AAAAAAAHBEAAAAAAAAAAAAAACgABAAEAAAAAAA0wDwAE8BUFAACiDArwCAAAACyMAAAACgAA0wAL
8GYAAAB/AAAA7wGAANjYlwqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAYABgC/AQAAEQDLAXDG
AAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0ADkAAAAjACLx5wMA
AP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAD8LNC9oAAAD9AAAADwAAAGRycy9kb3du
cmV2LnhtbESPy07DMBBF90j8gzVIbBB1iNqqhLoVQuWxKrThA4Z48oB4HGyTB1+PxQKWV/fqXJ31
djSt6Mn5xrKCq1kCgriwuuFKwWt+f7kC4QOyxtYyKZjIw3ZzerLGTNuBD9QfQyUihH2GCuoQukxK
X9Rk0M9sRxy70jqDIUZXSe1wiHDTyjRJltJgw/Ghxo7uaio+jl9GQfmd237e7+v3/HnapZ+Lly69
GJQ6Pxtvb0AEGsP/eLfiB+P/yl/Uk1aQLpbzaxDl4/TmGn1AH8gpiH7RNpqC3PwAAAD//wMAUEsB
Ai0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz
XS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMv
LnJlbHNQSwECLQAUAAYACAAAACEAD8LNC9oAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rv
d25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAGgdQCI0JegcPABHwLAAAAA8A
FBAkAAAAAQDxDxwAAAAAAAAHBAAAAAAAAAAAAAAAIgABAAEAAAAAAA0wDwAN8FwAAAAAAJ8PBAAA
AAQAAAAAAKgPAgAAAEhDAAChDxYAAAADAAAAAAAAAAAAAwAAAAAAIgAEAAoAAACqDwwAAAADAAAA
BgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAqBQAAEgAK8AgAAAAtjAAAAAoAAOMAC/Bu
AAAAfwAAAO8BgACQ4pcKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAgQEEAAAIvwEQABAA
wAEBAAAI/wEIABgAPwMAAAgAgMMaAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA1ADAAAAAj
ACLx5wMAAP8BAABAAKmD2wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50
X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/
f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0
o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBl
U72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94Z
KrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMv
LnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj
0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vy
m0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQn
M1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAeHdkx9oAAAD9AAAADwAAAGRy
cy9kb3ducmV2LnhtbESPXUvDQBBF3wX/wzKCL2I3raRI7LaIED8KBZOWPo/ZabKa3Q27Y5v+excf
9PHOHc7lLFaj7cWRQjTeKZhOMhDkGq+NaxXstuXtPYjI6DT23pGCM0VYLS8vFlhof3IVHWtuRYK4
WKCCjnkopIxNRxbjxA/kUnfwwSKnGFqpA54S3PZylmVzadG4tNDhQE8dNV/1t1UwW988r7lsy7vp
uC8NVvnu831Q6vpqfHwAwTTy//Mbb+rIf+Uv6lUnSD7Pk83h5fwRjK4wMgUF6ZJskynI5Q8AAAD/
/wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50
X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAA
X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAeHdkx9oAAAD9AAAADwAAAAAAAAAAAAAAAAAHAgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA4DAAAAAAAAEPAIAAAAEgVTD94SIwYPABHw
LAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHBEAAAAAAAAAAAAAAEgABAAEAAAAAAA0wDwAN8GkAAAAA
AJ8PBAAAAAQAAAAAAKgPDQAAAEhWTSBHdWVzdCBNQ0UAAKEPGAAAAA4AAAAAAAAAAAAOAAAAAQAi
AAEABAAOAAAAqg8MAAAADgAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwCQEAAKIM
CvAIAAAALowAAAAKAADjAAvwbAAAAH8AAADvAYAAQO2XCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA
AL8ABAAEAL8BAAARAMABAQAACMsB0VYAAP8BCAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQA
IABCAG8AeAAgADUANAAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAAALDX4N+Q9LDg8ADfBfAAAAAACf
DwQAAAAEAAAAAACoDwMAAABDUFUAAKEPGAAAAAQAAAAAAAAAAAAEAAAAAQAiAAEABAAOAAAAqg8M
AAAABAAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwDwEAAKIMCvAIAAAAMIwAAAAK
AADTAAvwZgAAAH8AAADvAYAAVAGaCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABgAGAL8BAAAR
AMsBcMYAAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADUANgAAABMA
IvEGAAAA/wEAAEAAAAAQ8AgAAAAVCAwTNRSvCA8ADfBrAAAAAACfDwQAAAAEAAAAAACoDwMAAABY
ZW4AAKEPFgAAAAQAAAAAAAAAAAAEAAAAAAAiAAQAEAAAAKoPGgAAAAMAAAAHAAAAAwAJBAQIAQAA
AAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwtAAAADIACvAIAAAAMYwAAAAKAADTAAvw
TgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIcAAQAAAL8ABAAPAL8BDAAeAMABAgAA
CM4BBgAAAP8BDgAOAD8CAAADAH8DAAAPAJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCC
fwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAACvBy8LSRGBCQ8ABPD+AAAAogwK
8AgAAAAyjAAAAAoAAKMAC/A8AAAAgADAA5oKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAGAA8A
vwEMAB4A/wEGAA4APwIAAAMAfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCCAIJ/
BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAACkMtA8GErQMDwAN8FQAAAAAAJ8P
BAAAAAQAAAAAAKgPBAAAAE1DRSMAAKEPIAAAAAUAAAAAABA4CgAAAAAAWgAyAAcABQAAAAAAIgAE
ABAAAACqDwwAAAAFAAAABgAAAAkEBAgPAATwCwEAAKIMCvAIAAAAM4wAAAAKAACjAAvwPAAAAIAA
KAqaCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABgAPAL8BDAAeAP8BBgAOAD8CAAADAH8DAAAP
AJMAIvE2AAAAfwEAAEAAvwEAACAA/wEAAMAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4A
fwYGAA4AAAAQ8AgAAADUB+wMxRBNCA8ADfBhAAAAAACfDwQAAAAEAAAAAACoDwsAAABXZSBhcmUg
aGVyZQAAoQ8mAAAADAAAAAAAEDgKAAAAAABaADIABwAMAAAAAgAmAAIABAAOAAAAAAIAAKoPDAAA
AAwAAAAGAAAACQQECA8ABPAgAQAAogwK8AgAAAA0jAAAAAoAAMMAC/BuAAAAfwABAO8BgACIDpoK
gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMA
AAIARABhAHQAZQAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQ
DwAN8IIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAm
AAEAAwAIALKysv4AAPcPCAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAA
CQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CwBAACiDArwCAAAADWMAAAACgAAwwAL8H4AAAB/
AAEA7wGAAHQWmgqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAA
CACAwzYAAAC/AwAAAgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABk
AGUAcgAgADQAAAAAABDwCAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA
AAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAA
AAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwSAAAABIA
CvAIAAAAAYwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI
AAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgT
L0UAAA8AihMnRQAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLEwdFAAAAAOsuCAAAAGTtyAHg
KCbcAAAAKwQAAABf7xTSHwBE8dM/AAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAPfYCf//
//8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAAHwBE8Y4/AAAAACfxIAAAAAAAAAAAAAAAAQAAAAAA
AAAAAAAAAJUTAP////8YAAAADwA98Q0AAABAAULxBQAAAAEEAAAAAABB8RQAAAABAAAAAQAAAAAA
AAAAAAAAAwAAAD8AJfEsAAAAAAAo8RAAAAABAAAACQAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAA
AAEAAABPACXxLAAAAAAAKPEQAAAAAQAAAAoAAAAAAAAAAAAAAA8APPEMAAAAAAABKwQAAAABAAAA
HwBE8SQKAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPHMCQAAAAAn8SAAAAAAAAAAAAAAAAAA
AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x
NAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMA
AAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC
8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+
8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAA
APsqFAAAAAAAAAABAAAAD4wAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA
AAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAA
AEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULx
BQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAA
AAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAAB
AAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAA
AAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAA
AA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAABWMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAA
AAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAB
AAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAA
AAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgA
AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAA
AAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAA
AAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBp
AGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAWjAAA//////////8fACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA
AAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEA
AAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA
AAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEA
AAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFv
AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2
AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAABIwAAP//////////
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAA
AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAA
oABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAA
AAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAA
ABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBs
AGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0
AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAAOM
AAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAA
AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAECAAAAkABC
8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA
AAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkA
AAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUA
AAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkA
bABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAABeMAAD/
/////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8b0LAAAAACfxIAAAAAAA
AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAA
AAAAAAAAAAAA/////x8ARPFlCwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA
AQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/Eg
AAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQ
AELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgA
AAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAA
AAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAA
A3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAA
AABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQA
AAAAAAAAAQAAABuMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE
8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULx
BQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAA
ACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAA
AAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YA
aQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC
8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAA
AAAAAQAAABqMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQB
AAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAA
AAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjx
EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAA
AAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBz
AGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMA
AAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAA
AQAAACuMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAA
ACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAEC
AAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8A
JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAA
AAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELx
EQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7x
KwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA
+yoUAAAAAAAAAAEAAAAhjAAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAA
AB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAA
QAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAADABQvEF
AAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAA
AAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEA
AAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAA
AAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAA
DwA88RwAAAAAAPsqFAAAAAAAAAABAAAAIIwAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAA
AAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEA
AAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAA
AQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAA
AAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAA
AAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAA
BAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkA
bABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAB+MAAD//////////x8AJfEYAAAAAAAo
8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAA
AAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAA
AACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA
AAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAA
AAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8A
AAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYA
aQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAijAAA//////////8f
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPFJDQAAAAAn8SAAAAAAAAAAAAAAAAAA
AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AP////8fAETx8QwAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x
AAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAA
AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUAAAAB
AQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3x
AAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrx
bwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4A
dgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAABKMAAD/////////
/x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAA
AAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAA
AKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA
AAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAA
AA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAA
AAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBp
AHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACOMAAD//////////x8A
JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAA
AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAA
QvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAA
AAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZ
AAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABl
AAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5
AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAYjAAA
//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAA
AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEF
AAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAA
AAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBp
AHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELx
IwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAA
AAABAAAALYwAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEA
AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAA
AQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAA
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAAD
AAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAA
QvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8A
PvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAA
AAD7KhQAAAAAAAAAAQAAABmMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA
AAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQA
AABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl
8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAA
AwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvER
AAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvEr
AAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7
KhQAAAAAAAAAAQAAACqMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA
HwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABA
AULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUA
AAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAA
AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAA
AAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAA
AAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAP
ADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAcjAAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAA
AAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA
AA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAAB
AQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAA
AAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAA
ADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAE
AAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBs
AGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAHYwAAP//////////HwAl8RgAAAAAACjx
EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxzAgAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA
AAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8XQI
AAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAA
AAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAA
AAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAA
AAEAAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgA
AAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAA
AAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAA
AAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBp
AGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAkjAAA//////////8fACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA
AAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEA
AAAAsABC8QUAAAABAQAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA
AAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEA
AAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFv
AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2
AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAJ4wAAP//////////
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAA
AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAA
oABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAA
AB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAA
DwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAA
AAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkA
cwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAEYwAAP//////////HwAl
8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAA
AwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC
8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA
AAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkA
AAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUA
AAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkA
bABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACaMAAD/
/////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8dIBAAAAACfxIAAAAAAA
AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUA
AAABIwAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEDAAAAMAFC8QUAAAABAQAAAB8AJfEYAAAAAAAo
8RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAp8QgAAAAAAAAAAACAQB8ARPEpAQAAAAAn8SAAAAAAAAAA
AAAAAAMAAAADAAAAAAAAAAAAAADoAwAAGQAAAA8APfEAAAAADwAr8fEAAAAAADTxDAAAAAAAAAA4
AAAAAAAAAA8AP/FeAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADaABpAGQAZABlAG4AAAAQAELxAwAA
AAMAAAAAQ/EEAAAA9AEAAAAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAQAELxAwAAAAMAAA8AKvFv
AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2
AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAGYwAAP//////////
HwBE8c0DAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPF1AwAAAAAn8SAAAAAAAAAAAAAAAAAA
AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA
AAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x
NAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAf
ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMA
AAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC
8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+
8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAA
APsqFAAAAAAAAAABAAAAJYwAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA
AAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAA
AEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULx
BQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAA
AAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAAB
AAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAA
AAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAA
AA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACiMAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAA
AAAAAAAAAAAAAAAAHwBE8WYFAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAB
AAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPEOBQAAAAAn8SAA
AAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAA
AAAAAAAAAAAAAAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAA
AAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAA
QvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAA
AAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAA
AAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAA
AAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5
AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAADIwAAP//////////HwAl8RgAAAAAACjxEAAAAAAA
AAAAAAAAAAAAAAAAAAAfAETxkQEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA
AAEAAAAPAD3xQQAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEF
AAAAAQEAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx
+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGg
AAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQ
AAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBi
AGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAB6MAAD//////////x8AJfEYAAAA
AAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAA
AAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAABAQAAAKAAQvEFAAAA
AQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA
AAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA9
8QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq
8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAu
AHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAUjAAA////////
//8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGXBQAAAAAn8SAAAAAAAAAAAAAA
AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA
AAAAAP////8fAETxPwUAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP
AD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAA
AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUA
AAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA
AAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAP
AD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAP
ACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABl
AC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACmMAAD/////
/////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8ZEBAAAAACfxIAAAAAAAAAAA
AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAECAAAAkABC8QUAAAAB
AQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo8RAA
AAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAA
AAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBp
AGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAA
A3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEA
AAAsjAAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPHCAQAAAAAn
8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAgAA
AJAAQvEFAAAAASMAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAwAAADABQvEFAAAAAQEAAAAfACXx
GAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPEpAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAAD
AAAAAAAAAAAAAADoAwAAGQAAAA8APfEAAAAADwAr8fEAAAAAADTxDAAAAAAAAAA4AAAAAAAAAA8A
P/FeAAAAAABD8QQAAAAAAAAAAABC8Q8AAAADaABpAGQAZABlAG4AAAAQAELxAwAAAAMAAAAAQ/EE
AAAA9AEAAAAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAQAELxAwAAAAMAAA8AKvFvAAAAAAAz8RAA
AAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIA
aQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAKIwAAP//////////HwBE8c0DAAAA
ACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPF1AwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA
AAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx
hAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEF
AAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAfACXxGAAAAAAA
KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAA
AAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBp
AHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELx
IwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAA
AAABAAAAE4wAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxkQEA
AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAA
AQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAwAULxBQAAAAEAAAAA
HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAAD
AAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAA
QvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8A
PvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAA
AAD7KhQAAAAAAAAAAQAAAA6MAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA
AAAADwACKwgFAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAADjAAAAQABMAEACSsQAAAAAwAAAAEA
AAABAAAAAAAAAA8ACCswAAAAAAADKxAAAAABAAAAAAAAAASMAAABAAEwAQAJKxAAAAADAAAAAQAA
AAAAAAAAAAAADwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAADowAAAEAATABAAkrEAAAAAMAAAABAAAA
AQAAAAAAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAUjAAAAQABMAEACSsQAAAAAwAAAAEAAAAB
AAAAAAAAAA8ACCswAAAAAAADKxAAAAABAAAAAAAAABWMAAABAAEwAQAJKxAAAAADAAAAAQAAAAEA
AAAAAAAADwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAAFowAAAEAATABAAkrEAAAAAMAAAABAAAAAQAA
AAAAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAYjAAAAQABMAEACSsQAAAAAwAAAAEAAAABAAAA
AAAAAA8ACCswAAAAAAADKxAAAAABAAAAAAAAABmMAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAA
AAAADwAIKzAAAAAAAAMrEAAAAAEAAAABAAAAGYwAAAEAATABAAkrEAAAAAMAAAABAAAAAQAAAAAA
AAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAbjAAAAQABMAEACSsQAAAAAwAAAAEAAAABAAAAAAAA
AA8ACCswAAAAAAADKxAAAAABAAAAAAAAAByMAAABAAEwAQAJKxAAAAADAAAAAQAAAAAAAAAAAAAA
DwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAAHYwAAAEAATABAAkrEAAAAAMAAAABAAAAAAAAAAAAAAAP
AAgrMAAAAAAAAysQAAAAAQAAAAAAAAAejAAAAQABMAEACSsQAAAAAwAAAAEAAAAAAAAAAAAAAA8A
CCswAAAAAAADKxAAAAABAAAAAAAAAB+MAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwAI
KzAAAAAAAAMrEAAAAAEAAAAAAAAAIIwAAAEAATABAAkrEAAAAAMAAAABAAAAAQAAAAAAAAAPAAgr
MAAAAAAAAysQAAAAAQAAAAAAAAAhjAAAAQABMAEACSsQAAAAAwAAAAEAAAABAAAAAAAAAA8ACCsw
AAAAAAADKxAAAAABAAAAAAAAACKMAAABAAEwAQAJKxAAAAADAAAAAQAAAAAAAAAAAAAADwAIKzAA
AAAAAAMrEAAAAAEAAAAAAAAAJowAAAEAATABAAkrEAAAAAMAAAABAAAAAAAAAAAAAAAPAAgrMAAA
AAAAAysQAAAAAQAAAAAAAAAnjAAAAQABMAEACSsQAAAAAwAAAAEAAAAAAAAAAAAAAA8ACCswAAAA
AAADKxAAAAABAAAAAAAAACiMAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwAIKzAAAAAA
AAMrEAAAAAEAAAABAAAAKIwAAAEAATABAAkrEAAAAAMAAAABAAAAAQAAAAAAAAAPAAgrMAAAAAAA
AysQAAAAAQAAAAAAAAAsjAAAAQABMAEACSsQAAAAAwAAAAEAAAAAAAAAAAAAAA8ACCswAAAAAAAD
KxAAAAABAAAAAAAAAC2MAAABAAEwAQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwDuA8IJAAACAO8D
GAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAMMA8ADATZCAAADwAC8NEIAACgAQjwCAAAAAUAAAAF
aAAADwAD8GkIAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAGgAAAUA
AAAPAATwIAEAAKIMCvAIAAAAAmgAAAAKAADDAAvwbgAAAH8AAQDvAYAAxGqaCoEAAAAAAIIAAAAA
AIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0AGUA
IABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4PmBGqEA8ADfCCAAAAAACf
DwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+
AAD3DwgAAAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAA
APAAAADUAdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADaAAAAAoAAMMAC/B+AAAAfwABAO8BgAAEdJoK
gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMM2AAAAvwMA
AAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA0AAAA
AAAQ8AgAAABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAA
AAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAA
EQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BoBAAASAArwCAAAAARoAAAg
AgAAEwEL8H4AAAAEAAAAAAB/AAEA7wGAACyBmgqBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAA
AACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgAAACIAwAAAAC/AwAAAgBS
AGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR8BAAAAAAAMMLCAAAAP//
//8NAJoKDwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAEJhY2tncm91bmQAAKEPGgAAAAsAAAAA
AAAICgABAAcACwAAAAEAIAAAAAQAAACqDwwAAAALAAAABgAAAAkEBAgPAATwswQAABIACvAIAAAA
BWgAACACAAATAQvwfgAAAAQAAAAAAH8AAQDvAYAAZJ+aCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA
AIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDBAQAAD8DAAAIAIDDGAAAAIgDAAAAAL8D
AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAXAKZAOwVsA4PABHwEAAAAAAAwwsI
AAAA/////w4AmgoPAA3w7QMAAAAAnw8EAAAAAQAAAAAAqA9pAQAAWGVuIG1jZSBjb21wb25lbnRz
DVhlbiBNQ0UgSVNSDVhlbiBNQ0Ugc29mdGlycQ12TUNFDURvbTAgbWNlbG9nIGludGVyZmFjZQ0N
MyBtYWpvciBwb2ludHMgb2Ygdk1DRSBsb2dpYw1Ib3cgdG8gaW5qZWN0IE1DRQ1Ib3cgdG8gZW11
bGF0ZSBNU1JzDUhvdyB0byBsaXZlIG1pZ3JhdGUNDU1ham9yIGNvbnN0cmFpbnRzIG9mIGN1cnJl
bnQgdk1DRQ1Cb3VuZCB0byBob3N0DUhvc3QgaGV0ZXJvZ2VuZW91cyBicmVhayBtaWdyYXRpb24s
IGNhbm5vdCBjb250cm9sIHZpYSBjcHVpZA1Ob24tYXJjaCBpc3N1ZXMgb2YgTVNScyBlbXVsYXRp
b24NV2VpcmQgcGVyLWRvbWFpbiBNU1JzDVVubmF0dXJhbCBNQ0UgaW5qZWN0aW9uIHNlbWFudGlj
cwAAoQ/yAAAAEwAAAAAAABAKAFoABwA4AAAAAQAAEAoAWgAHAB0AAAAAAAAQCgBaAAcAOwAAAAEA
ABAKAFoABwAiAAAAAAAAEAoAWgAHAA4AAAABAAAQCgBaAAcAXwAAAAIAABAKAFoABwA4AAAAAQAA
EAoAWgAHABMAAAABACAAAAAEABwAAAAAACAABAAFAAAAAAAkAAQAAAAAAhcAAAAAACAABAAdAAAA
AQQgAAAEBAA6AAAAAAQgAAAEBAABAAAAAQQgAAEEBAAiAAAAAQggAAAIBAAOAAAAAAwgAAAMBABf
AAAAAAwgAAAMBAA4AAAAAAwgAAAMBAAAAKoPUgEAAAMAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQI
AwAAAAcAAAADAAkEBAgMAAAABgAAAAkEBAgDAAAABwAAAAMACQQECAkAAAAGAAAACQQECAMAAAAH
AAAAAwAJBAQIBQAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgEAAAABwAAAAMA
CQQECAYAAAAGAAAACQQECAYAAAAHAAAAAwAJBAQIHgAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgo
AAAABgAAAAkEBAgEAAAABwAAAAMACQQECDMAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIRgAAAAYA
AAAJBAQIBQAAAAcAAAADAAkEBAgUAAAABgAAAAkEBAgEAAAABwAAAAMACQQECBwAAAAGAAAACQQE
CAQAAAAHAAAAAwAJBAQIIwAAAAYAAAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2ADEAWABA8A
BPBIAAAAEgAK8AgAAAABaAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES
ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYA
qgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4I
AAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAA
AAAAAFQJ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gMbJAAAAgDvAxgA
AAAQAAAAAAAAAAAAAAAAAACABwEAAAcADDAPAAwEIiMAAA8AAvAaIwAA4AAI8AgAAAAZAAAAIAwA
AA8AA/CKIgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAA
DwAE8CABAACiDArwCAAAAAIMAAAACgAAwwAL8G4AAAB/AAEA7wGAAIiWmgqBAAAAAACCAAAAAACD
AAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAA
UABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXBC+D5gRqhAPAA3wggAAAAAAnw8E
AAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA
9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACmDwwAAADw
AAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAAwwAAAAKAADDAAvwfgAAAH8AAQDvAYAAZNaaCoEA
AAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDNgAAAL8DAAAC
AFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANAAAAAAA
EPAIAAAAXRC4Dr4PqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAA
AAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAAAAAAqg8aAAAAAQAAAAcAAAAAABEE
CQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPBNAQAAEgAK8AgAAAAEDAAAIAIA
ABMBC/B+AAAABAAAAAAAfwABAO8BgACw2JoKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAA
hwAAAAAAiAAAAAAAvwAEAAQAvwEAAAEA/wEAABEAAQMDBAAAPwMAAAgAgMMYAAAAvwMAAAIAUgBl
AGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADLAA4BaxVZAg8AEfAQAAAAAADDCwgAAAD/////
DQCaCg8ADfCHAAAAAACfDwQAAAAAAAAAAACoDxUAAABYZW4gdk1DRSBhcHByb2FjaCAoMSkAAKEP
GgAAABYAAAAAAAAICgABAAcAFgAAAAEAIAAAAAQAAACqDzQAAAADAAAABwAAAAMACQQECAEAAAAG
AAAACQQECAQAAAAHAAAAAwAJBAQIDgAAAAYAAAAJBAQIDwAE8OIJAAASAArwCAAAAAUMAAAgAgAA
AwEL8HgAAAAEAAAAAAB/AAEA7wGAABAAxAqBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAAAACH
AAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwQEAAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEA
bgBnAGwAZQAgADMAAAAAABDwCAAAAJkCXQBKDa0ODwAR8BAAAAAAAMMLCAAAAP////8OAJoKDwAN
8CIJAAAAAJ8PBAAAAAEAAAAAAKAPCgYAAFMAZQBwAGEAcgBhAHQAZQAgAGcAdQBlAHMAdAAgAE0A
QwBFACAAdwAvACAAaABvAHMAdAAgAE0AQwBFAA0AVQBuAGwAaQBrAGUAIABjAHAAdQBpAGQADQB2
AE0AQwBFACAAYwBhAG4AIABmAGEAawBlACAAYwBhAHAAYQBiAGkAbABpAHQAaQBlAHMAIAB0AG8A
IABnAHUAZQBzAHQAIABpAGYAIABuAGUAZQBkAA0AdgBNAEMARQAgAGMAYQBuACAAbQBhAHMAawAg
AGMAYQBwAGEAYgBpAGwAaQB0AGkAZQBzACAAaQBmACAAdQBuAG4AZQBjAGUAcwBzAGEAcgB5AA0A
RQBtAHUAbABhAHQAZQAgAGEAIAB3AGUAbABsAC0AZABlAGYAaQBuAGUAZAAgAE0AQwBFACAAaQBu
AHQAZQByAGYAYQBjAGUAIAB0AG8AIABnAHUAZQBzAHQALAAgAGMAbwBuAHMAaQBzAHQAcwAgAG8A
ZgANAEkAbgBpAHQAJgBwAHIAbwBiAGUAIABpAG4AdABlAHIAYQBjAGUADQBCAGEAcwBpAGMAYQBs
AGwAeQAgAGYAbwByACAAZwB1AGUAcwB0ACAAaQBuAGkAdAAgACYAIABwAHIAbwBiAGUADQBkAGkA
cwBhAGIAbABlACAAUwBSAEEATwAvAFMAUgBBAFIALQB1AG4AcgBlAGwAYQB0AGUAZAAgAGMAYQBw
AGEAYgBpAGwAaQB0AGkAZQBzAA0AUABvAGkAbgB0AGwAZQBzAHMAIAB0AG8AIABpAG4AagBlAGMA
dAAgAHQAaABvAHMAZQAgAGUAcgByAG8AcgAgAHQAbwAgAGcAdQBlAHMAdAANAGUAbgBhAGIAbABl
ACAAUwBSAEEATwAvAFMAUgBBAFIALQByAGUAbABhAHQAZQBkACAAYwBhAHAAYQBiAGkAbABpAHQA
aQBlAHMADQBOAG8AIABtAGEAdAB0AGUAcgAgAGgAbwBzAHQAIABzAHUAcABwAG8AcgB0ACAAbwBy
ACAAbgBvAHQADQBkAGkAcwBhAGIAbABlACAATQBDAEcAXwBDAFQATAAsACAAcwB0AGkAYwBrACAA
YQBsAGwAIAAxABkgcwAgAGYAbwByACAATQBDAGkAXwBDAFQATAANAEcAZQBuAGUAcgBhAGwAbAB5
ACAAZgBvAHIAIABoAC8AdwAgAGQAZQBiAHUAZwAgAHAAdQByAHAAbwBzAGUADQBBAHYAbwBpAGQA
IABtAG8AZABlAGwAIABzAHAAZQBjAGkAZgBpAGMAIABpAHMAcwB1AGUADQBFAHIAcgBvAHIALQBp
AG4AZgBvACAAaQBuAHQAZQByAGYAYQBjAGUADQBPAG4AbAB5ACAAbQBlAGEAbgBpAG4AZwBmAHUA
bAAgAHcAaABlAG4AIAByAGUAYQBsACAAZQByAHIAbwByACAAZwBlAG4AZQByAGEAdABlAGQADQBG
AGkAbAB0AGUAcgAgACYAIABkAGUAbABpAHYAZQByACAAdABvACAAZwB1AGUAcwB0ACAAbwBuACAA
ZABlAG0AYQBuAGQADQBMAGUAYQB2AGUAIABoAG8AcwB0ACAAZgBsAGUAeABpAGIAaQBsAGkAdAB5
AA0ADQBFAHIAcgBvAHIAIABpAG4AagBlAGMAdAAgAHQAbwAgAGcAdQBlAHMAdAANAEEAIAB0AHIA
YQBuAHMAZgBlAHIAIABsAGEAeQBlAHIADQBGAGkAbAB0AGUAcgAgAG4AbwBuAC0AUwBSAEEATwAv
AFMAUgBBAFIAIABiAGEAbgBrAHMADQBUAHIAYQBuAHMAbABhAHQAZQAgAGgAbwBzAHQAIABhAGQA
ZAByAGUAcwBzACAAdABvACAAZwB1AGUAcwB0ACAAYQBkAGQAcgBlAHMAcwANAEQAZQBsAGkAdgBl
AHIADQBFAHYAYQBsAHUAYQB0AGUAIABhAG4AZAAgAGQAZQBsAGkAdgBlAHIAIAB0AGgAZQAgAG0A
bwBzAHQAIABzAGUAdgBlAHIAZQAgAGUAcgByAG8AcgAAAKEPFgIAAB8AAAAAAAAQCgBQAAcADQAA
AAEAABAKAFAABwBWAAAAAgAAEAoAUAAHADsAAAABAAAQCgBQAAcAFAAAAAIAABAKAFAABwBKAAAA
AwAAEAoAUAAHACkAAAAEAAAQCgBQAAcAJgAAAAMAABAKAFAABwAeAAAABAAAEAoAUAAHACsAAAAD
AAAQCgBQAAcAOwAAAAQAABAKAFAABwAVAAAAAgAAEAoAUAAHAE4AAAADAAAQCgBQAAcAFwAAAAEA
ABAKAFAABwABAAAAAQABEAoACgBQAAcAFgAAAAAAABAKAFAABwARAAAAAQAAEAoAUAAHAEsAAAAC
AAAQCgBQAAcAKwAAAAMAABAKAFAABwAfAAAAAQAiAAAABAASAA0AAAAABCIAAAQEABAAVgAAAAAE
IgAABAQADgA7AAAAAAgiAAAIBAAQABQAAAAADCIAAAwEAA4ASgAAAAAQIgAAEAQADAApAAAAABAi
AAAQBAAKACYAAAAAFCIAABQEAAwAHgAAAAAUIgAAFAQACgArAAAAABgiAAAYBAAMADsAAAAAHCIA
ABwEAAoAFQAAAAAgIgAAIAQADgBOAAAAACQiAAAkBAAMABcAAAAAKCIAACgEABAAAQAAAAAsIgAA
LAQAEAAWAAAAASwiAAAsBAASABEAAAAAMCIAADAEABAASwAAAAA0IgAANAQADgArAAAAADgiAAA4
BAAMAAAAqg/CAAAAJgAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgEAAAABwAA
AAMACQQECCgAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIYQAAAAYAAAAJBAQICgAAAAcAAAADAAkE
BAgBAAAABgAAAAkEBAgIAAAABwAAAAMACQQECNsAAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIDwAA
AAYAAAAJBAQIAwAAAAcAAAADAAkEBAhCAQAABgAAAAkEBAgAAKYPFAAAAPAeAADUASAB0AJAAvAD
YAMQBYAEDwAE8P8AAACiDArwCAAAAAYMAAAACgAAswAL8FgAAAB/AAAA7wGAAKwBxAq/AAYABgCB
AQEAAAi/ARAAEADAAQEAAAjLAXDGAAD/AQgAGAA/AwAACACAwxYAAAC/AwAAAgBUAGUAeAB0ACAA
QgBvAHgAIAA2AAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAK4C2Q5/FKIDDwAN8GkAAAAAAJ8PBAAA
AAQAAAAAAKgPCQAAAEd1ZXN0IE1DRQAAoQ8cAAAACgAAAAAAACAAADIACgAAAAAAJgAEABAAAAAA
AgAAqg8MAAAACgAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATw/gAAAKIMCvAIAAAA
BwwAAAAKAACzAAvwWAAAAH8AAADvAYAAJO6aCr8ABgAGAIEBAQAACL8BEAAQAMABAQAACMsBcMYA
AP8BCAAYAD8DAAAIAIDDFgAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADcAAAATACLxBgAAAP8B
AABAAAAAEPAIAAAAGw2iDr4UDw4PAA3waAAAAAAAnw8EAAAABAAAAAAAqA8IAAAASG9zdCBNQ0UA
AKEPHAAAAAkAAAAAAAAgAAAyAAkAAAAAACYABAAQAAAAAAIAAKoPDAAAAAkAAAAGAAAACQQECAAA
pg8MAAAA8AAAANQB0ALwAxAFDwAE8PgAAAASAArwCAAAAAgMAAAACgAA0wAL8GgAAAB/AAAA7wGA
ANTumgqFAAIAAACHAAEAAAC/AAQABACBAQEAAAi/ARAAEADAAQEAAAjLAXDGAAD/AQgAGAA/AwAA
CACAwxoAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADEAMwAAABMAIvEGAAAA/wEAAEAAAAAQ
8AgAAABMB0UNcxEtCw8ADfBSAAAAAACfDwQAAAAEAAAAAAChDxQAAAABAAAAAAAAAAAAAQAAAAAA
IAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCGAAAAQgEK
8AgAAAAKDAAAgAoAANMAC/BeAAAAfwAAAO8BhQACAAAAhwABAAAAvwAEAAQAfwEAAAEAvwEAABEA
wAEAAAAIywFqSgAAzgEGAAAA/wEYABgAPwMIAAgAgMMQAAAAvwMAAAIATABpAG4AZQAgADEANQAA
AAAAEPAIAAAA+Ak2DYER+AkPAATwhgAAAEIBCvAIAAAACwwAAMAKAADTAAvwXgAAAH8AAADvAYUA
AgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAgAACMsBakoAANEBAQAAAP8BGAAYAD8DCAAI
AIDDEAAAAL8DAAACAEwAaQBuAGUAIAAxADYAAAAAABDwCAAAAMMD2BHvEegMDwAE8BABAACiDArw
CAAAAAwMAAAACgAAkwAL8E4AAAB/AAAA7wGAADxB2Am/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/
AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADkAAAATACLxBgAAAP8BAABAAAAA
EPAIAAAAgQemDdEQLggPAA3whAAAAAAAnw8EAAAABAAAAAAAqA8KAAAAR3Vlc3QgTVNScwAAoQ8c
AAAACwAAAAAAACAAADIACwAAAAAAJgAEAAwAAAAAAgAAqg8mAAAABgAAAAYAAAAJBAQIBAAAAAcA
AAADAAkEBAgBAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAPAQAAogwK8AgAAAAN
DAAAAAoAAJMAC/BOAAAAfwAAAO8BgACIQMQKvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMAAAgA
gMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMgAwAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAA
AD4KlQ2/EOsKDwAN8IMAAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEhvc3QgTVNScwAAoQ8cAAAACgAA
AAAAACAAADIACgAAAAAAJgAEAAwAAAAAAgAAqg8mAAAABQAAAAYAAAAJBAQIBAAAAAcAAAADAAkE
BAgBAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPD6AAAAogwK8AgAAAAODAAAAAoA
AJMAC/BOAAAAfwAAAO8BgACcTMQKvwAGAAYAvwEAABEAywFwxgAA/wEAABgAPwMAAAgAgMMYAAAA
vwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMgAxAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAPEIRw1N
EZ4JDwAN8G4AAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFRyYW5zZmVyIGxheWVyAAChDxwAAAAPAAAA
AAAAIAAAMgAPAAAAAAAmAAQADAAAAAACAACqDwwAAAAPAAAABgAAAAkEBAgAAKYPDAAAAPAAAADU
AdAC8AMQBQ8ABPDoAQAAAgAK8AgAAAAPDAAAwAoAAFMCC/CaAQAABAAAAAAAfwAAAO8BhQACAAAA
hwABAAAAiAAAAAAAvwAEAAQAQAEAAAAAQQEAAAAAQgFgVAAAQwHCSAAARAEEAAAARcFOAAAARsEa
AAAAUcEeAAAAUsESAAAAVcEAAAAAVsEAAAAAV8EWAAAAWAECAAAAfwEJABkAvwEAABEAwAECAAAI
wQEAAAEAxAEAAAAAywHUlAAAzQEAAAAAzgEGAAAA0QEBAAAA1AEBAAAA1QEBAAAA1gECAAAA1wEC
AAAA/wEYABgABAMBAAAAPwMAAAgAgMMOAAAAvwMAAAIACQAMAAgAuSoAAP////+GRAAAJg8AAGBU
AADVKgAAYFQAAMJIAAC5KgAA/////4ZEAAAmDwAAYFQAANUqAABgVAAAwkgAAAAAAADCSAAACgAM
AAIAAEAAqgEgAIAAQACrASABAAFgAIADAAQACABmGgMAAAAAAOUgBgArswsAAAAAACuzCwADAAQA
BAAAAAAAAAAAAAAAAAABAAQAEAAAAAAAAAAAAGBUAADCSAAAQQByAGMAIAAyADIAAABTACLxHgAA
ANkB/////9oB/////9sBAAAAINzBAAAAAOEB/////wAAEPAIAAAAQwu4Dq4P+wwPAATwhgAAAEIB
CvAIAAAAEAwAAAAKAADTAAvwXgAAAH8AAADvAYUAAgAAAIcAAQAAAL8ABAAEAH8BAAABAL8BAAAR
AMABAgAACMsBakoAANEBAQAAAP8BGAAYAD8DCAAIAIDDEAAAAL8DAAACAEwAaQBuAGUAIAAyADMA
AAAAABDwCAAAAMwDOhFAEUAHDwAE8NwBAAACAArwCAAAABEMAABACgAAMwIL8I4BAAAEAAAAAAB/
AAAA7wGFAAIAAACHAAEAAACIAAAAAAC/AAQABABAAQAAAABBAQAAAABCAWBUAABDAWBUAABEAQQA
AABFwU4AAABGwRoAAABRwR4AAABSwRIAAABVwQAAAABWwQAAAABXwRYAAABYAQIAAAB/AQkAGQC/
AQAAEQDAAQIAAAjBAQAAAQDEAQAAAADLAdSUAADNAQAAAADQAQEAAADSAQEAAADTAQEAAADWAQIA
AAD/ARgAGAAEAwEAAAA/AwAACACAww4AAAC/AwAAAgAJAAwACAD/////AAAAAJkuAAAAAAAAYFQA
AMYlAABgVAAAYFQAAP////8AAAAAmS4AAAAAAABgVAAAxiUAAGBUAABgVAAAAAAAAGBUAAAKAAwA
AgAAQACqASAAgABAAKsBIAEAAWAAgAMABAAIAAAAAAAAAAAAaEMEAGIWDAAAAAAAYhYMAAMABAAE
AAAAAAAAAAAAAAAAAAEABAAQAAAAAAAAAAAAYFQAAGBUAABBAHIAYwAgADIANQAAAFMAIvEeAAAA
2QH/////2gH/////2wEAAAAg3MEAAAAA4QH/////AAAQ8AgAAADPA5UOjg8+Bw8ABPAOAQAAogwK
8AgAAAATDAAAAAoAAJMAC/BOAAAAfwAAAO8BgABwU8QKvwAGAAYAvwEAABEAywFwxgAA/wEAABgA
PwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMgA4AAAAEwAi8QYAAAD/AQAAQAAA
ABDwCAAAANkDpxGYEzMFDwAN8IIAAAAAAJ8PBAAAAAQAAAAAAKgPFAAAAHB2L2h2bSBNQ0UgaW5q
ZWN0aW9uAAChDxwAAAAVAAAAAAAAIAAAMgAVAAAAAAAmAAQACgAAAAACAACqDxoAAAAGAAAABwAA
AAMACQQECA8AAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8AQBAACiDArwCAAAABQM
AAAACgAAkwAL8E4AAAB/AAAA7wGAAARexAq/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/AwAACACA
wxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAyADkAAAATACLxBgAAAP8BAABAAAAAEPAIAAAA
HASND5URFgUPAA3weAAAAAAAnw8EAAAABAAAAAAAqA8KAAAAVk1FeGl0IEdQIwAAoQ8cAAAACwAA
AAAAACAAADIACwAAAAAAJgAEAAoAAAAAAgAAqg8aAAAABgAAAAcAAAADAAkEBAgFAAAABgAAAAkE
BAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAeAQAAogwK8AgAAAAWDAAAAAoAALMAC/BYAAAAfwAA
AO8BgABEaMQKvwAGAAYAgQEBAAAIvwEQABAAwAEBAAAIywFwxgAA/wEIABgAPwMAAAgAgMMWAAAA
vwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAABTB5gS3xWT
CA8ADfCIAAAAAACfDwQAAAAEAAAAAACoDw4AAABDQVAgJiBDVEwgTVNScwAAoQ8cAAAADwAAAAAA
ACAAADIADwAAAAAAJgAEAAwADKQp/gAAqg8mAAAACgAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgB
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPARAQAAogwK8AgAAAAZDAAAAAoAANMA
C/BOAAAAgACUcsQKvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywFwxgAA/wEGAA4AAQIC
AAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/AQAAwAC/AwCC
AIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAD8KrhOwFYYLDwAN8FUAAAAA
AJ8PBAAAAAQAAAAAAKgPAQAAAHgAAKEPJAAAAAIAAAAAADAgAAAAAAAAAAAyAAIAAAABACYAAQAE
ABwADKQp/gAAqg8MAAAAAgAAAAYAAAAJBAQIDwAE8CIBAACiDArwCAAAABoMAAAACgAA0wAL8E4A
AACAABR2xAq/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAjLAXDGAAD/AQYADgABAgIAAAg/
AgAAAwC/AgEADwD/AhYAHwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8BAADAAL8DAIIAgn8F
BgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAowWLDQoR6QYPAA3wZgAAAAAAnw8E
AAAABAAAAAAAqA8UAAAARXJyb3ItaW5mbyBpbnRlcmZhY2UAAKEPIgAAABUAAAAAADAgAAAAAAAA
AAAyABUAAAAAACYABAAOAAAAAAIAAKoPDAAAABUAAAAGAAAACQQECA8ABPAwAQAAogwK8AgAAAAb
DAAAAAoAANMAC/BOAAAAgAB0esQKvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywFwxgAA
/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AkwAi8TYAAAB/AQAAQAC/AQAAIAD/
AQAAwAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKwFHBIgFvIG
DwAN8HQAAAAAAJ8PBAAAAAQAAAAAAKgPFAAAAEluaXQmcHJvYmUgaW50ZXJmYWNlAAChDyIAAAAV
AAAAAAAwIAAAAAAAAAAAMgAVAAAAAAAmAAQADgAMpCn+AACqDxoAAAAKAAAABwAAAAMACQQECAsA
AAAGAAAACQQECA8ABPC6AAAAQgEK8AgAAAAdDAAAAAoAAPMAC/BaAAAAhQACAAAAhwABAAAAvwAA
AA8ARAEEAAAAfwEAAAEAvwEAABAAwAEDAAAIywGfbwAAzgEGAAAA/wEeAB4AAQICAAAIPwIAAAMA
vwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/
BQYATgA/BgYATgB/BgYADgAAABDwCAAAAKAIpAweFqAIDwAE8LoAAAAyAQrwCAAAAB4MAACACgAA
4wAL8FQAAACFAAIAAACHAAEAAAC/AAAADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQykKQDLAdSUAADO
AQYAAADRAQEAAAD/AQ4ADgABAgIAAAg/AgAAAwB/AwAADwCTACLxNgAAAH8BAABAAL8BAAAgAP8B
AACAAL8DAIIAgn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAAsQj2E7sUAA0P
AATwtAAAADIBCvAIAAAAIAwAAAAKAADTAAvwTgAAAIUAAgAAAIcAAQAAAL8AAAAPAIEBBAAACIMB
AAAACL8BDAAeAMABDKQpAMsB1JQAANABAQAAAP8BDgAOAAECAgAACD8CAAADAH8DAAAPAJMAIvE2
AAAAfwEAAEAAvwEAACAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4A
AAAQ8AgAAADOA8ATrhRGBw8ABPBIAAAAEgAK8AgAAAAVDAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF
AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEALwAF8CAAAAAAABTwCAAAAAQA
AAAeDAAAAAAU8AgAAAAIAAAAIAwAABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6G
AKoBTAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu
CAAAAL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA
AAAAAABUCf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAACIECAAAAAEAAAAG
AAAADwDuA4INAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAFAQAABwAMMA8ADASZDAAADwAC8JEM
AAAgAgjwCAAAAAUAAAAFlAAADwAD8CkMAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA
AAIACvAIAAAAAJQAAAUAAAAPAATwIAEAAKIMCvAIAAAAApQAAAAKAADDAAvwbgAAAH8AAQDvAYAA
PJHECoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAA
AL8DAAACAEQAYQB0AGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4P
mBGqEA8ADfCCAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAA
AAEAJgABAAMACACysrL+AAD3DwgAAAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAA
BgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADlAAAAAoAAMMAC/B+
AAAAfwABAO8BgADEnMQKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgA
PwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABv
AGwAZABlAHIAIAA0AAAAAAAQ8AgAAABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIA
AAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACq
DxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8E0B
AAASAArwCAAAAASUAAAgAgAAEwEL8H4AAAAEAAAAAAB/AAEA7wGAAMSjxAqBAAAAAACCAAAAAACD
AAAAAACEAAAAAACFAAAAAACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgA
AACIAwAAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR
8BAAAAAAAMMLCAAAAP////8NAMQKDwAN8IcAAAAAAJ8PBAAAAAAAAAAAAKgPFQAAAFhlbiB2TUNF
IGFwcHJvYWNoICgyKQAAoQ8aAAAAFgAAAAAAAAgKAAEABwAWAAAAAQAgAAAABAAAAKoPNAAAAAMA
AAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgOAAAABgAAAAkEBAgPAATwQAgA
ABIACvAIAAAABZQAACACAAAjAQvwhAAAAAQAAAAAAH8AAQDvAYAAXKnECoEAAAAAAIIAAAAAAIMA
AAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAL8BAAABAP8BAAARAAEDBAQAAD8DAAAI
AIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAXAL7AC4V
sA4PABHwEAAAAAAAwwsIAAAA/////w4AxAoPAA3wdAcAAAAAnw8EAAAAAQAAAAAAoA+QBAAATQBT
AFIAcwAgAGUAbQB1AGwAYQB0AGkAbwBuAA0AUAB1AHIAZQAgAHMALwB3ACAAZQBtAHUAbABhAHQA
aQBvAG4ADQBOAG8AIABuAG8AbgAtAGEAcgBjAGgAIABpAHMAcwB1AGUAcwAgAGEAZwBhAGkAbgAN
AEYAbwByACAAZgBhAG0AaQBsAHkALQBtAG8AZABlAGwAIABpAHMAcwB1AGUAIAByAG8AbwB0ACAA
ZgByAG8AbQAgAGwAZQBnAGEAYwB5ACAAcAByAG8AYwBlAHMAcwBvAHIADQBEAG8AbgAZIHQAIABj
AGEAcgBlAA0ARwB1AGUAcwB0ACAAcAByAG8AYgBlACAAbQBjAGUAIABjAGEAcABhAGIAaQBsAGkA
dABpAGUAcwAgAHYAaQBhACAATQBDAEcAXwBDAEEAUAAsACAAbgBvAHQAIABjAHAAdQBpAGQADQBG
AG8AcgAgAG0AbwBkAGUAbAAtAHMAcABlAGMAaQBmAGkAYwAgAGkAcwBzAHUAZQANAEYAbwByACAA
TQBDAGkAXwBDAFQATAAsACAAcwB0AGkAYwBrACAAdABvACAAYQBsAGwAIAAxABkgcwAgAGEAbgBk
ACAAdAByAGUAYQB0ACAAZwB1AGUAcwB0ACAAdwByAGkAdABlACAAYgBpAHQAIABhAHMAIAAYIG4A
bwB0ACAAaQBtAHAAbABlAG0AZQBuAHQAGSANAEYAbwByACAATQBTAEMATwBEACAAbwBmACAATQBD
AGkAXwBTAFQAQQBUAFUAUwAsACAAZQB4AHAAbwBzAGUAIABhAGwAbAAgADAAGSBzAA0ADQB2AE0A
QwBFACAAbABpAHYAZQAgAG0AaQBnAHIAYQB0AGkAbwBuAA0ATgBvAHQAaABpAG4AZwAgAHMAcABl
AGMAaQBhAGwAIABuAGUAZQBkACAAdABvACAAZABvACAAYQBuAHkAIABtAG8AcgBlAA0ARQByAHIA
bwByAC0AaQBuAGYAbwAgAE0AUwBSAHMAOgAgAHAAbwBpAG4AdABsAGUAcwBzACAAdABvACAAYgBl
ACAAbQBpAGcAcgBhAHQAZQBkAA0ASQBuAGkAdAAmAHAAcgBvAGIAZQAgAE0AUwBSAHMAOgAgAHcA
ZQBsAGwALQBkAGUAZgBpAG4AZQBkACAAYQBuAGQAIAB1AG4AaQBmAGkAZQBkACAAYQB0ACAAYQBs
AGwAIABwAGwAYQB0AGYAbwByAG0AcwANAA0ATQBDAEUAIABpAG4AagBlAGMAdABpAG8AbgANAEIA
cgBvAGEAZABjAGEAcwB0ACAAdABvACAAYQBsAGwAIAB2AGMAcAB1AHMADQBDAG8AcgBuAGUAcgAg
AGMAYQBzAGUADQB2AGMAcAB1AHMAIAA+ACAAcABjAHAAdQBzACwAIABpAG4AagBlAGMAdABpAG8A
bgAgAG8AYwBjAHUAcgAgAGEAdAAgAGEAIABsAG8AbgBnACAAdABpAG0AZQAgAHcAaQBuAGQAbwB3
AA0AVABvAGwAZQByAGEAdABlACAAaQB0AAAAoQ9SAQAADwAAAAAAAAAKAAcALAAAAAEAAAAKAAcA
MgAAAAIAAAAKAAcAPwAAAAMAAAAKAAcAGQAAAAIAAAAKAAcAdAAAAAMAAAAKAAcAFAAAAAAAAAAK
AAcAJAAAAAEAAAAKAAcAZgAAAAIAAAAKAAcADgAAAAAAAAAKAAcAIwAAAAEAAAAKAAcANQAAAAIA
AAAKAAcADAAAAAMAAAAKAAcADwAAAAEAIgAAAAQAEgAsAAAAAAQiAAAEBAAQADIAAAAACCIAAAgE
AA4APwAAAAAIIgAACAQADAAZAAAAAAwiAAAMBAAOAHQAAAAAECIAABAEAAwAFAAAAAEUIgAAFAQA
EgAkAAAAABgiAAAYBAAQAGYAAAAAHCIAABwEAA4ADgAAAAEgIgAAIAQAEgAjAAAAACQiAAAkBAAQ
ADUAAAAAKCIAACgEAA4ADAAAAAAsIgAALAQADAAAAKoPUgEAAAQAAAAHAAAAAwAJBAQIEAAAAAYA
AAAJBAQIAwAAAAcAAAADAAkEBAhtAAAABgAAAAkEBAgDAAAABwAAAAMACQQECB8AAAAGAAAACQQE
CAUAAAAHAAAAAwAJBAQIHgAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAhNAAAABgAAAAkEBAgKAAAA
BwAAAAMACQQECBIAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIPwAAAAYAAAAJBAQIBAAAAAcAAAAD
AAkEBAgbAAAABgAAAAkEBAgKAAAABwAAAAMACQQECAEAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQI
TAAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgNAAAABgAAAAkEBAgFAAAABwAAAAMACQQECAMAAAAG
AAAACQQECAUAAAAHAAAAAwAJBAQINAAAAAYAAAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2AD
EAWABA8ABPBIAAAAEgAK8AgAAAABlAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHe
vWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+
uQAMLoYAqgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAA
AAAA6y4IAAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAA
AAAAAAAAAAAAAMkK/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gNLBQAA
AgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcADDAPAAwEYgQAAA8AAvBaBAAAMAII8AgAAAAE
AAAABJgAAA8AA/DyAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACY
AAAFAAAADwAE8CABAACiDArwCAAAAAKYAAAACgAAwwAL8G4AAAB/AAEA7wGAAEj/xAqBAAAAAACC
AAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwyYAAAC/AwAAAgBEAGEA
dABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXBC+D5gRqhAPAA3wggAA
AAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgA
srKy/gAA9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACm
DwwAAADwAAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAA5gAAAAKAADDAAvwfgAAAH8AAQDvAYAA
vJGuCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDNgAA
AL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAA
NAAAAAAAEPAIAAAAXRC4Dr4PqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAA
AAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAAAAAAqg8aAAAAAQAAAAcA
AAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPBeAQAAEgAK8AgAAAAE
mAAAIAIAABMBC/B+AAAABAAAAAAAfwABAO8BgABkm64KgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA
hQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA/wEAABEAAQMEBAAAPwMAAAgAgMMYAAAAiAMAAAAAvwMA
AAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgAAABjBJ8A8hWoCQ8AEfAQAAAAAADDCwgA
AAD/////DgCuCg8ADfCYAAAAAACfDwQAAAABAAAAAACoDwgAAABEZXRhaWxzDQAAoQ9EAAAACAAA
AAAAAQgKAAgAAQAHAAEAAAABAAAACgAHAAcAAAABACIAAAAEACQAAQAAAAAAIgAEACQAAQAAAAAE
IgAABAQAJAAAAKoPDAAAAAkAAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQP
AATwSAAAABIACvAIAAAAAZgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B
EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6G
AKoBTAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu
CAAAAL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA
AAAAAADJCv////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DhasAAAIA7wMY
AAAAEAAAAAAAAAAAAAAAAAAAgAABAAAHAAwwDwAMBIyqAAAPAALwhKoAAPAACPAIAAAAKwAAAC8R
AAAPAAPwHKoAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAEAAABQAA
AA8ABPAgAQAAogwK8AgAAAACEAAAAAoAAMMAC/BuAAAAfwABAO8BgADIrK4KgQAAAAAAggAAAAAA
gwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAg
AFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8P
BAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4A
APcPCAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA
8AAAANQB0ALwAxAFDwAE8CwBAACiDArwCAAAAAMQAAAACgAAwwAL8H4AAAB/AAEA7wGAAMi3rgqB
AAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAA
AgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAA
ABDwCAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAA
AAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAAR
BAkEAQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwJAEAABIACvAIAAAABBAAACAC
AAADAQvweAAAAAQAAAAAAH8AAQDvAYAAfLmuCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAA
AIcAAAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDAwQAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQA
YQBuAGcAbABlACAAMgAAAAAAEPAIAAAASQAOAWsVwAEPABHwEAAAAAAAwwsIAAAA/////w0ArgoP
AA3wZAAAAAAAnw8EAAAAAAAAAAAAqA8aAAAAUG9pbnQgMTogTVNSIGVtdWxhdGlvbiAoMSkAAKEP
GgAAABsAAAAAAAAICgABAAcAGwAAAAEAIAAAAAQAAACqDwwAAAAbAAAABgAAAAkEBAgPAAPwIpoA
AA8ABPCAAAAAAQAJ8BAAAADTCwAAVgIAAAkWAAANDgAAAgAK8AgAAAAvEQAAAQIAABMAC/AGAAAA
fwAAAQABIwAi8TIAAACfAwEAAACgwyYAAAAIAAgABABuAQAAbQEAAG4BAABuAQAAbgEAAG4BAABu
AQAAbgEAAAAAEPAIAAAAVgLTCwkWDQ4PAATwxAQAABIACvAIAAAAIBEAAAIKAABzAAvwKgAAAH8A
AAAEAIAAZMeuCr8ABAAEAIEBBAAACL8BGAAfAP8BAAAIAL8DAAACACMAIvHjAwAAvwEAAGAAqYPX
AwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07D
MAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVag
iI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0O
B9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBX
WQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAA
AP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg
72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/H
tw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9
HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz
4y8AAAD//wMAUEsDBBQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/L
bsIwEEX3lfgHayp1UxWnLApKMagiaou64yGR5TQektB4nNpuEv6+FgtY3rmjc3Xmy8E0oiPna8sK
nscJCOLC6ppLBfvd+9MMhA/IGhvLpOBMHpaL0d0cU2173lC3DaWIEPYpKqhCaFMpfVGRQT+2LXHs
jtYZDDG6UmqHfYSbRk6S5EUarDkuVNjSqqLiZ/tnFNhm12fTL/c4m+qJOeRZdjr0J6Ue7oe3VxCB
hnB7/s3X3Ud+LS+otVYQTY6f529X6w36QO5yiabREuTiHwAA//8DAFBLAQItABQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG
AAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG
AAgAAAAhAFj08AXWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYA
AAAAAwADALcAAAAKAwAAAAAAAA/wEAAAAGMTAAAxCwAACRYAAJ8MAAAPAA3wdwAAAAAAnw8EAAAA
BwAAAAAAqA8JAAAAMDAwMCwwMDAwAAChDyAAAAAKAAAAAAABCAAACAABAAoAAAABACYAAAAEAAwA
AAAAAwAAqg8MAAAACgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE
8OYEAAASAArwCAAAAB4RAAACCgAAcwAL8CoAAAB/AAAABACAAJDRrgq/AAQABACBAQQAAAi/ARgA
HwD/AQAACAC/AwAAAgAjACLx4wMAAL8BAABgAKmD1wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN
1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9
PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9M
Ik0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR
1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAA
ABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXt
Z3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahp
SlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXO
c0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAWPTw
BdYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4B2sqdVMVpywKSjGoImqLuuMh
keU0HpLQeJzabhL+vhYLWN65o3N15svBNKIj52vLCp7HCQjiwuqaSwX73fvTDIQPyBoby6TgTB6W
i9HdHFNte95Qtw2liBD2KSqoQmhTKX1RkUE/ti1x7I7WGQwxulJqh32Em0ZOkuRFGqw5LlTY0qqi
4mf7ZxTYZtdn0y/3OJvqiTnkWXY69CelHu6Ht1cQgYZwe/7N191Hfi0vqLVWEE2On+dvV+sN+kDu
comm0RLk4h8AAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAA
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAA
AAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAAAAA
AAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACgMAAAAAAAAP8BAAAAA5
DwAAMQsAAGMTAACfDAAADwAN8JkAAAAAAJ8PBAAAAAcAAAAAAKgPHQAAAG1lYW5pbmdmdWwgd2hl
biBNQ0dfRVhUX1Agc2V0AAChDyAAAAAeAAAAAAABCAAACAABAB4AAAABACYAAAAEAAwAAAAAAwAA
qg8aAAAAHQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANg
AxAFgAQPAATw0gQAABIACvAIAAAAHBEAAAIKAABzAAvwKgAAAH8AAAAEAIAAnNuuCr8ABAAEAIEB
BAAACL8BGAAfAP8BAAAIAL8DAAACACMAIvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDh
CAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/U
wIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjH
jympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrF
mJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGV
xCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yz
ra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23z
HztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAI
AAAAIQBIgT8Q1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BT8JAEIXvJP6HzZB4IbKVRCCV
hRiKUbwBGjwO3aEtdGeb3ZWWf++Ggx7fvMn38s0WnanFhZyvLCt4HCYgiHOrKy4UfO5eH6YgfEDW
WFsmBVfysJjf9WaYatvyhi7bUIgIYZ+igjKEJpXS5yUZ9EPbEMfuaJ3BEKMrpHbYRrip5ShJxtJg
xXGhxIaWJeXn7Y9RYOtdm00+3GA60SOz/86y0749KXXf716eQQTqwv/z19PKrNZ/5Q31rhVEk+Pb
9eAqvUEfyN0u0TRagpz/AgAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAA
AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAEiBPxDWAAAA+QAA
AA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAA
AA/wEAAAANMLAAAxCwAAOQ8AAJ8MAAAPAA3whQAAAAAAnw8EAAAABwAAAAAAqA8LAAAATUNHX0VY
VF9DTlQAAKEPHgAAAAwAAAAAAAEAAAAIAAwAAAABACYAAAAEAAwAAAAAAwAAqg8aAAAACwAAAAYA
AAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwvAQA
ABIACvAIAAAAGBEAAAIKAABzAAvwKgAAAH8AAAAEAIAAwOWuCr8ABAAEAIEBBAAACL8BGAAfAP8B
AAAIAL8DAAACACMAIvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBY9PAF1gAA
APkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfgHayp1UxWnLApKMagiaou64yGR5TQe
ktB4nNpuEv6+FgtY3rmjc3Xmy8E0oiPna8sKnscJCOLC6ppLBfvd+9MMhA/IGhvLpOBMHpaL0d0c
U2173lC3DaWIEPYpKqhCaFMpfVGRQT+2LXHsjtYZDDG6UmqHfYSbRk6S5EUarDkuVNjSqqLiZ/tn
FNhm12fTL/c4m+qJOeRZdjr0J6Ue7oe3VxCBhnB7/s3X3Ud+LS+otVYQTY6f529X6w36QO5yiabR
EuTiHwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABb
Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAA
AAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAAAAAAAAAAAA
AAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAAGMTAACf
DAAACRYAAA0OAAAPAA3wbwAAAAAAnw8EAAAABwAAAAAAqA8BAAAAMQAAoQ8gAAAAAgAAAAAAAQgA
AAgAAQACAAAAAQAmAAAABAAMAAykKf4AAKoPDAAAAAIAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA
1AEgAdACQALwA2ADEAWABA8ABPDvBAAAEgAK8AgAAAAWEQAAAgoAAHMAC/AqAAAAfwAAAAQAgAC8
764KvwAEAAQAgQEEAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eMDAAC/AQAAYACpg9cDAABQSwME
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD
5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbe
t0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN
50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXy
N+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBL
AwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5Q
xojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u
5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0
p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//
AwBQSwMEFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfeV
+AdrKnVTFacsCkoxqCJqi7rjIZHlNB6S0Hic2m4S/r4WC1jeuaNzdebLwTSiI+drywqexwkI4sLq
mksF+9370wyED8gaG8uk4EwelovR3RxTbXveULcNpYgQ9ikqqEJoUyl9UZFBP7YtceyO1hkMMbpS
aod9hJtGTpLkRRqsOS5U2NKqouJn+2cU2GbXZ9Mv9zib6ok55Fl2OvQnpR7uh7dXEIGGcHv+zdfd
R34tL6i1VhBNjp/nb1frDfpA7nKJptES5OIfAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAA
hQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA
WvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA
WPTwBdYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMA
twAAAAoDAAAAAAAAD/AQAAAAOQ8AAJ8MAABjEwAADQ4AAA8ADfCiAAAAAACfDwQAAAAHAAAAAACo
DxoAAABzdXBwb3J0IHMvdyBlcnJvciByZWNvdmVyeQAAoQ8gAAAAGwAAAAAAAQgAAAgAAQAbAAAA
AQAmAAAABAAMAAykKf4AAKoPJgAAAAgAAAAGAAAACQQECAMAAAAHAAAAAwAJBAQIEAAAAAYAAAAJ
BAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8NAEAAASAArwCAAAABQRAAACCgAA
cwAL8CoAAAB/AAAABACAADAFvgq/AAQABACBAQQAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx4wMA
AL8BAABgAKmD1wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEASIE/ENYAAAD5AAAADwAAAGRycy9kb3du
cmV2LnhtbESPQU/CQBCF7yT+h82QeCGylUQglYUYilG8ARo8Dt2hLXRnm92Vln/vhoMe37zJ9/LN
Fp2pxYWcrywreBwmIIhzqysuFHzuXh+mIHxA1lhbJgVX8rCY3/VmmGrb8oYu21CICGGfooIyhCaV
0uclGfRD2xDH7midwRCjK6R22Ea4qeUoScbSYMVxocSGliXl5+2PUWDrXZtNPtxgOtEjs//OstO+
PSl13+9enkEE6sL/89fTyqzWf+UN9a4VRJPj2/XgKr1BH8jdLtE0WoKc/wIAAP//AwBQSwECLQAU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht
bFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVs
c1BLAQItABQABgAIAAAAIQBIgT8Q1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJl
di54bWxQSwUGAAAAAAMAAwC3AAAACgMAAAAAAAAP8BAAAADTCwAAnwwAADkPAAANDgAADwAN8IMA
AAAAAJ8PBAAAAAcAAAAAAKgPCQAAAE1DR19TRVJfUAAAoQ8eAAAACgAAAAAAAQAAAAgACgAAAAEA
JgAAAAQADAAMpCn+AACqDxoAAAAJAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAApg8WAAAA+B4A
AAAA1AEgAdACQALwA2ADEAWABA8ABPC8BAAAEgAK8AgAAAAQEQAAAgoAAHMAC/AqAAAAfwAAAAQA
gAC4+q4KvwAEAAQAgQEEAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eMDAAC/AQAAYACpg9cDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQ
RfeV+AdrKnVTFacsCkoxqCJqi7rjIZHlNB6S0Hic2m4S/r4WC1jeuaNzdebLwTSiI+drywqexwkI
4sLqmksF+9370wyED8gaG8uk4EwelovR3RxTbXveULcNpYgQ9ikqqEJoUyl9UZFBP7YtceyO1hkM
MbpSaod9hJtGTpLkRRqsOS5U2NKqouJn+2cU2GbXZ9Mv9zib6ok55Fl2OvQnpR7uh7dXEIGGcHv+
zdfdR34tL6i1VhBNjp/nb1frDfpA7nKJptES5OIfAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAWPTwBdYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAoDAAAAAAAAD/AQAAAAYxMAAJ8JAAAJFgAAMQsAAA8ADfBvAAAAAACfDwQAAAAHAAAA
AACoDwEAAAAxAAChDyAAAAACAAAAAAABCAAACAABAAIAAAABACYAAAAEAAwADKQp/gAAqg8MAAAA
AgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8O4EAAASAArwCAAA
AA4RAAACCgAAcwAL8CoAAAB/AAAABACAAOwXvgq/AAQABACBAQQAAAi/ARgAHwD/AQAACAC/AwAA
AgAjACLx4wMAAL8BAABgAKmD1wMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250
ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg
6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXut
xYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAm
ZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh
+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3Jl
bHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+En
rWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslp
x4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T
1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAWPTwBdYAAAD5AAAADwAA
AGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4B2sqdVMVpywKSjGoImqLuuMhkeU0HpLQeJzabhL+
vhYLWN65o3N15svBNKIj52vLCp7HCQjiwuqaSwX73fvTDIQPyBoby6TgTB6Wi9HdHFNte95Qtw2l
iBD2KSqoQmhTKX1RkUE/ti1x7I7WGQwxulJqh32Em0ZOkuRFGqw5LlTY0qqi4mf7ZxTYZtdn0y/3
OJvqiTnkWXY69CelHu6Ht1cQgYZwe/7N191Hfi0vqLVWEE2On+dvV+sN+kDucomm0RLk4h8AAP//
AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABf
cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABk
cnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACgMAAAAAAAAP8BAAAAA5DwAAnwkAAGMTAAAx
CwAADwAN8KEAAAAAAJ8PBAAAAAcAAAAAAKgPJQAAAE1DaV9zdGF0dXMgYml0NTY6NTMgYXJlIGFy
Y2ggd2hlbiBzZXQAAKEPIAAAACYAAAAAAAEIAAAIAAEAJgAAAAEAJgAAAAQADAAMpCn+AACqDxoA
AAAKAAAABwAAAAMACQQECBwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWA
BA8ABPDQBAAAEgAK8AgAAAAMEQAAAgoAAHMAC/AqAAAAfwAAAAQAgABwGb4KvwAEAAQAgQEEAAAI
vwEYAB8A/wEAAAgAvwMAAAIAIwAi8eMDAAC/AQAAYACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0H
sBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ2
7eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanH
fW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHO
GtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQs
W78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaM
ZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQ
LrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0Uv
rDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAh
AEiBPxDWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FPwkAQhe8k/ofNkHghspVEIJWFGIpR
vAEaPA7doS10Z5vdlZZ/74aDHt+8yffyzRadqcWFnK8sK3gcJiCIc6srLhR87l4fpiB8QNZYWyYF
V/KwmN/1Zphq2/KGLttQiAhhn6KCMoQmldLnJRn0Q9sQx+5oncEQoyukdthGuKnlKEnG0mDFcaHE
hpYl5eftj1Fg612bTT7cYDrRI7P/zrLTvj0pdd/vXp5BBOrC//PX08qs1n/lDfWuFUST49v14Cq9
QR/I3S7RNFqCnP8CAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEASIE/ENYAAAD5AAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQ
AAAA0wsAAJ8JAAA5DwAAMQsAAA8ADfCDAAAAAACfDwQAAAAHAAAAAACoDwkAAABNQ0dfVEVTX1AA
AKEPHgAAAAoAAAAAAAEAAAAIAAoAAAABACYAAAAEAAwADKQp/gAAqg8aAAAACQAAAAYAAAAJBAQI
AQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwvgQAABIACvAI
AAAAABEAAAIKAABzAAvwKgAAAH8AAAAEAIAAzCK+Cr8ABAAEAIEBBAAACL8BGAAfAP8BAAAIAL8D
AAACACMAIvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0Nv
bnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4
IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmF
e63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrA
ECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5
S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABf
cmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD
4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1C
yWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3
PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBY9PAF1gAAAPkAAAAP
AAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfgHayp1UxWnLApKMagiaou64yGR5TQektB4nNpu
Ev6+FgtY3rmjc3Xmy8E0oiPna8sKnscJCOLC6ppLBfvd+9MMhA/IGhvLpOBMHpaL0d0cU2173lC3
DaWIEPYpKqhCaFMpfVGRQT+2LXHsjtYZDDG6UmqHfYSbRk6S5EUarDkuVNjSqqLiZ/tnFNhm12fT
L/c4m+qJOeRZdjr0J6Ue7oe3VxCBhnB7/s3X3Ud+LS+otVYQTY6f529X6w36QO5yiabREuTiHwAA
//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIA
AGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAAGMTAAAxCAAACRYA
AJ8JAAAPAA3wcQAAAAAAnw8EAAAABwAAAAAAqA8DAAAAMC8xAAChDyAAAAAEAAAAAAABCAAACAAB
AAQAAAABACYAAAAEAAwAAAAAAwAAqg8MAAAABAAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB
0AJAAvADYAMQBYAEDwAE8L8EAAASAArwCAAAAP4QAAACCgAAcwAL8CoAAAB/AAAABACAANgkvgq/
AAQABACBAQQAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx4wMAAL8BAABgAKmD1wMAAFBLAwQUAAYA
CAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pT
OCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8Ud
KEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyK
tN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7
ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNb
odfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZu
pHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFO
YQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBL
AwQUAAYACAAAACEAWPTwBdYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4B2sq
dVMVpywKSjGoImqLuuMhkeU0HpLQeJzabhL+vhYLWN65o3N15svBNKIj52vLCp7HCQjiwuqaSwX7
3fvTDIQPyBoby6TgTB6Wi9HdHFNte95Qtw2liBD2KSqoQmhTKX1RkUE/ti1x7I7WGQwxulJqh32E
m0ZOkuRFGqw5LlTY0qqi4mf7ZxTYZtdn0y/3OJvqiTnkWXY69CelHu6Ht1cQgYZwe/7N191Hfi0v
qLVWEE2On+dvV+sN+kDucomm0RLk4h8AAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY9PAF
1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAA
CgMAAAAAAAAP8BAAAAA5DwAAMQgAAGMTAACfCQAADwAN8HIAAAAAAJ8PBAAAAAcAAAAAAKgPBAAA
AENNQ0kAAKEPIAAAAAUAAAAAAAEIAAAIAAEABQAAAAEAJgAAAAQADAAAAAADAACqDwwAAAAFAAAA
BgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATw0QQAABIACvAIAAAA/BAA
AAIKAABzAAvwKgAAAH8AAAAEAIAAdDa+Cr8ABAAEAIEBBAAACL8BGAAfAP8BAAAIAL8DAAACACMA
IvHjAwAAvwEAAGAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/
n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSj
lD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVT
vbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkq
uyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8u
cmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPR
yNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKb
TCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCcz
VQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBIgT8Q1gAAAPkAAAAPAAAAZHJz
L2Rvd25yZXYueG1sRI9BT8JAEIXvJP6HzZB4IbKVRCCVhRiKUbwBGjwO3aEtdGeb3ZWWf++Ggx7f
vMn38s0WnanFhZyvLCt4HCYgiHOrKy4UfO5eH6YgfEDWWFsmBVfysJjf9WaYatvyhi7bUIgIYZ+i
gjKEJpXS5yUZ9EPbEMfuaJ3BEKMrpHbYRrip5ShJxtJgxXGhxIaWJeXn7Y9RYOtdm00+3GA60SOz
/86y0749KXXf716eQQTqwv/z19PKrNZ/5Q31rhVEk+Pb9eAqvUEfyN0u0TRagpz/AgAA//8DAFBL
AQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAEiBPxDWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9k
b3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAANMLAAAxCAAAOQ8AAJ8JAAAP
AA3whAAAAAAAnw8EAAAABwAAAAAAqA8KAAAATUNHX0NNQ0lfUAAAoQ8eAAAACwAAAAAAAQAAAAgA
CwAAAAEAJgAAAAQADAAAAAADAACqDxoAAAAKAAAABgAAAAkEBAgBAAAABwAAAAAABAgJBAAApg8W
AAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPDcBAAAEgAK8AgAAADTEAAAAgoAAHMAC/AqAAAA
fwAAAAQAgABwQL4KvwAEAAQAgQEEAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8d0DAACpg9cDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAFj08AXWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQ
RfeV+AdrKnVTFacsCkoxqCJqi7rjIZHlNB6S0Hic2m4S/r4WC1jeuaNzdebLwTSiI+drywqexwkI
4sLqmksF+9370wyED8gaG8uk4EwelovR3RxTbXveULcNpYgQ9ikqqEJoUyl9UZFBP7YtceyO1hkM
MbpSaod9hJtGTpLkRRqsOS5U2NKqouJn+2cU2GbXZ9Mv9zib6ok55Fl2OvQnpR7uh7dXEIGGcHv+
zdfdR34tL6i1VhBNjp/nb1frDfpA7nKJptES5OIfAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEAWPTwBdYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAoDAAAAAAAAD/AQAAAAOQ8AAMMGAABjEwAAMQgAAA8ADfCVAAAAAACfDwQAAAAHAAAA
AACoDw0AAABleHRlbmRlZCByZWdzAAChDyAAAAAOAAAAAAABCAAACAABAA4AAAABACYAAAAEAAwA
AAAAAwAAqg8mAAAACQAAAAYAAAAJBAQIBAAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgAAKYPFgAA
APgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwzwQAABIACvAIAAAA0RAAAAIKAABzAAvwKgAAAH8A
AAAEAIAAKEu+Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsD
BBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8
Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG
3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWr
jedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R1
8jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQ
SwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5Tu
UMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0O
buVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJ
NKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD/
/wMAUEsDBBQABgAIAAAAIQAkLAro1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3
lfoP1lTqJioOLAoKGFQ1QlTd8ZCguyEekkBsR/aUhL+vxaIs79zRuTqzRW8acSUfamcVDAcpCLKF
07UtFey2y7cJiMBoNTbOkoIbBVjMn59mmGnX2TVdN1yKCLEhQwUVc5tJGYqKDIaBa8nG7uS8QY7R
l1J77CLcNHKUpu/SYG3jQoUtfVZUXDa/RoFrtl0+/vbJZKxHZn/I8/O+Oyv1+tJ/TEEw9fx4viQ/
S07+yzvqSyuIJqfV7ehrvcbA5O+XaBotQc7/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh
AFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh
ACQsCujWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwAD
ALcAAAAKAwAAAAAAAA/wEAAAADkPAABVBQAAYxMAAMMGAAAPAA3wiAAAAAAAnw8EAAAABwAAAAAA
qA8aAAAAZGlzYWJsZSBNQ0dfQ1RMIHdoZW4gY2xlYXIAAKEPIAAAABsAAAAAAAEIAAAIAAEAGwAA
AAEAJgAAAAQADAAAAAADAACqDwwAAAAbAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC
8ANgAxAFgAQPAATwwwQAABIACvAIAAAAzxAAAAIKAABzAAvwKgAAAH8AAAAEAIAAcEy+Cr8ABAAE
AIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHcAwAAqYPWAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQABf6RM1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8JAEIbvBf/DMkIvRTdVUEldpRhK
xZsfYI/T7JjEZmfD7tbEf+/iQY/vvMPz8syXnanFhZyvLCt4HyYgiHOrKy4UHPZfgxkIH5A11pZJ
wZU8LBe9lzmm2ra8pcsuFCJC2KeooAyhSaX0eUkG/dA2xLE7WWcwxOgKqR22EW5qOUqSiTRYcVwo
saFVSfnf7t8osPW+zaYb9zab6pE5/mTZ+dielXrtd58fIAJ14fncIK3Gk0d5R621gmhy+r7+ukpv
0Qdy90s0jZYgFzcAAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAX+kTNUAAAD5AAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAkDAAAAAAAAD/AQ
AAAAOQ8AAOgDAABjEwAAVQUAAA8ADfB9AAAAAACfDwQAAAAHAAAAAACoDw8AAABDUFUgYmFuayBu
dW1iZXIAAKEPIAAAABAAAAAAAAEIAAAIAAEAEAAAAAEAJgAAAAQADAAMpCn+AACqDwwAAAAQAAAA
BgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwxgQAABIACvAIAAAAyxAA
AAIKAACDAAvwMAAAAH8AAAAEAIAAjF6+Cr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8D
AAACABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/
n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSj
lD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVT
vbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkq
uyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8u
cmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPR
yNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKb
TCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCcz
VQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQDgjhIb1gAAAPkAAAAPAAAAZHJz
L2Rvd25yZXYueG1sRI/LasMwEEX3hf6DmEI2JZEbShLcKKHULQ3Z5QHucmpN/Kg1MpISO39fkUW7
vHOHcznL9WBacSHna8sKniYJCOLC6ppLBcfDx3gBwgdkja1lUnAlD+vV/d0SU2173tFlH0oRIexT
VFCF0KVS+qIig35iO+LYnawzGGJ0pdQO+wg3rZwmyUwarDkuVNjRW0XFz/5sFNj20GfzrXtczPXU
5F9Z1uR9o9ToYXh9ARFoCP/PG9vk789/5Q210Qqiyenz+u1qvUMfyN0u0TRaglz9AgAA//8DAFBL
AQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl
c10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxz
Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAOCOEhvWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9k
b3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAADkPAABWAgAAYxMAAOgDAAAP
AA3weQAAAAAAnw8EAAAABwAAAAAAqA8LAAAARGVzY3JpcHRpb24AAKEPIAAAAAwAAAAAAAEIAAAI
AAEADAAAAAEAJgAAAAQADAD/mQD+AACqDwwAAAAMAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQB
IAHQAkAC8ANgAxAFgAQPAATw1gQAABIACvAIAAAAsxAAAAIKAACDAAvwMAAAAH8AAAAEAIAA4GC+
Cr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQDgjhIb1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LasMwEEX3hf6D
mEI2JZEbShLcKKHULQ3Z5QHucmpN/Kg1MpISO39fkUW7vHOHcznL9WBacSHna8sKniYJCOLC6ppL
BcfDx3gBwgdkja1lUnAlD+vV/d0SU2173tFlH0oRIexTVFCF0KVS+qIig35iO+LYnawzGGJ0pdQO
+wg3rZwmyUwarDkuVNjRW0XFz/5sFNj20GfzrXtczPXU5F9Z1uR9o9ToYXh9ARFoCP/PG9vk789/
5Q210Qqiyenz+u1qvUMfyN0u0TRaglz9AgAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAOCO
EhvWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAKAwAAAAAAAA/wEAAAAGMTAABWAgAACRYAAOgDAAAPAA3wiQAAAAAAnw8EAAAABwAAAAAAqA8b
AAAARGVmaW5lZCBpbnRlcmZhY2UgZm9yIGd1ZXN0AAChDyAAAAAcAAAAAAABCAAACAABABwAAAAB
ACYAAAAEAAwA/5kA/gAAqg8MAAAAHAAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvAD
YAMQBYAEDwAE8NAEAAASAArwCAAAAK8QAAACCgAAgwAL8DAAAAB/AAAABACAABRqvgq/AAQABACB
AZaWlgCDAQAAAAi/ARAAFAD/AQAACAC/AwAAAgATACLx3gMAAKmD2AMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEAbxN4ktcAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPQUvDQBCF74L/YRnBi9iNPdgS
uy1iKIp4aFqhHsfsJJuanQ27a5P++y496PHNG77Ht1iNthNH8qF1rOBhkoEgrpxuuVHwuVvfz0GE
iKyxc0wKThRgtby+WmCu3cAlHbexEQnCIUcFJsY+lzJUhiyGieuJU1c7bzGm6BupPQ4Jbjs5zbJH
abHltGCwpxdD1c/21ypw3W4oZu/+bj7TU7v/KorDfjgodXszPj+BiDTG/+e1qTcf5V95Qb1pBcmk
fj19+1aXGCL5yyWZJkuQyzMAAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAA
AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAbxN4ktcAAAD5
AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAsDAAAA
AAAAD/AQAAAA0wsAAFYCAAA5DwAA6AMAAA8ADfCCAAAAAACfDwQAAAAHAAAAAACoDxQAAABNQ0df
Q0FQIGNhcGFiaWxpdGllcwAAoQ8gAAAAFQAAAAAAAQgAAAgAAQAVAAAAAQAmAAAABAAMAP+ZAP4A
AKoPDAAAABUAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPC+BAAA
EgAK8AgAAAAJEAAAAgoAAHMAC/AqAAAAfwAAAAQAgAAkdL4KvwAEAAQAgQEEAAAIvwEQABQA/wEA
AAgAvwMAAAIAEwAi8d0DAACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29u
dGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg
4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7
rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQ
JmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL
4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9y
ZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPh
J61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJ
aceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+
09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAI6TYwTWAAAA+QAAAA8A
AABkcnMvZG93bnJldi54bWxEj0FrAjEQhe8F/0MYoZdSs+6hytYoxUVaeilqQY/Tzbgbu5ksSequ
/77BQ3t884bv8S1Wg23FhXwwjhVMJxkI4sppw7WCz/3mcQ4iRGSNrWNScKUAq+XoboGFdj1v6bKL
tUgQDgUqaGLsCilD1ZDFMHEdcepOzluMKfpaao99gttW5ln2JC0aTgsNdrRuqPre/VgFrt335ezd
P8xnOreHY1meD/1Zqfvx8PIMItIQ/5+PJseP9V95Q71pBcnk9Hr98kZvMUTyt0syTZYgl78AAAD/
/wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50
X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAA
X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAjpNjBNYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQAAAA0wsAAOgDAAA5DwAA
VQUAAA8ADfB3AAAAAACfDwQAAAAHAAAAAACoDwsAAABDb3VudCBmaWVsZAAAoQ8eAAAADAAAAAAA
AQAAAAgADAAAAAEAJgAAAAQADAAMpCn+AACqDwwAAAAMAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAA
ANQBIAHQAkAC8ANgAxAFgAQPAATwvQQAABIACvAIAAAACxAAAAIKAABzAAvwKgAAAH8AAAAEAIAA
JHy+Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHcAwAAqYPWAwAAUEsDBBQABgAI
AAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4
IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0o
ScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq0
3oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJ
r4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAG
AAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh
19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6k
cBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5h
B+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsD
BBQABgAIAAAAIQABf6RM1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8JAEIbvBf/DMkIv
RTdVUEldpRhKxZsfYI/T7JjEZmfD7tbEf+/iQY/vvMPz8syXnanFhZyvLCt4HyYgiHOrKy4UHPZf
gxkIH5A11pZJwZU8LBe9lzmm2ra8pcsuFCJC2KeooAyhSaX0eUkG/dA2xLE7WWcwxOgKqR22EW5q
OUqSiTRYcVwosaFVSfnf7t8osPW+zaYb9zab6pE5/mTZ+dielXrtd58fIAJ14fncIK3Gk0d5R621
gmhy+r7+ukpv0Qdy90s0jZYgFzcAAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMA
AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78A
AAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAX+kTNUA
AAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAkD
AAAAAAAAD/AQAAAAYxMAAOgDAAAJFgAAVQUAAA8ADfB3AAAAAACfDwQAAAAHAAAAAACoDwkAAAAw
MDAwLDAwMDEAAKEPIAAAAAoAAAAAAAEIAAAIAAEACgAAAAEAJgAAAAQADAAMpCn+AACqDwwAAAAK
AAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwygQAABIACvAIAAAA
DBAAAAIKAABzAAvwKgAAAH8AAAAEAIAAUI++Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAAC
ABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv
9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q
50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9
QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhd
jr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVs
c2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnC
ruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ
1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB
9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCnua/d1gAAAPkAAAAPAAAAZHJzL2Rv
d25yZXYueG1sRI/LbsIwEEX3lfgHayp1UxUHFgUFDKoaqlZdlYdEl0M8eUA8jmyXhL+vxQKWd+7o
XJ35sjeNOJPztWUFo2ECgji3uuZSwW778TIF4QOyxsYyKbiQh+Vi8DDHVNuO13TehFJECPsUFVQh
tKmUPq/IoB/aljh2hXUGQ4yulNphF+GmkeMkeZUGa44LFbb0XlF+2vwZBbbZdtnk2z1PJ3ps9r9Z
dtx3R6WeHvu3GYhAfbg/j5Ji9bO6lVfUl1YQTYrPy8HVeo0+kLteomm0BLn4BwAA//8DAFBLAQIt
ABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAKe5r93WAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3du
cmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAANMLAABVBQAAOQ8AAMMGAAAPAA3w
gwAAAAAAnw8EAAAABwAAAAAAqA8JAAAATUNHX0NUTF9QAAChDx4AAAAKAAAAAAABAAAACAAKAAAA
AQAmAAAABAAMAAAAAAMAAKoPGgAAAAkAAAAGAAAACQQECAEAAAAHAAAAAAAECAkEAACmDxYAAAD4
HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8LcEAAASAArwCAAAAA4QAAACCgAAcwAL8CoAAAB/AAAA
BACAABCavgq/AAQABACBAQQAAAi/ARAAFAD/AQAACAC/AwAAAgATACLx3QMAAKmD1wMAAFBLAwQU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPk
K2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63
T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43n
RJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI3
4Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsD
BBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDG
iNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7l
TBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSn
YEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8D
AFBLAwQUAAYACAAAACEAJCwK6NYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X6
D9ZU6iYqDiwKChhUNUJU3fGQoLshHpJAbEf2lIS/r8WiLO/c0bk6s0VvGnElH2pnFQwHKQiyhdO1
LRXstsu3CYjAaDU2zpKCGwVYzJ+fZphp19k1XTdcigixIUMFFXObSRmKigyGgWvJxu7kvEGO0ZdS
e+wi3DRylKbv0mBt40KFLX1WVFw2v0aBa7ZdPv72yWSsR2Z/yPPzvjsr9frSf0xBMPX8eL4kP0tO
/ss76ksriCan1e3oa73GwOTvl2gaLUHO/wAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAk
LAro1gAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAACgMAAAAAAAAP8BAAAABjEwAAVQUAAAkWAADDBgAADwAN8HAAAAAAAJ8PBAAAAAcAAAAAAKgP
AgAAADAgAAChDyAAAAADAAAAAAABCAAACAABAAMAAAABACYAAAAEAAwAAAAAAwAAqg8MAAAAAwAA
AAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8MsEAAASAArwCAAAAA8Q
AAACCgAAcwAL8CoAAAB/AAAABACAABijvgq/AAQABACBAQQAAAi/ARAAFAD/AQAACAC/AwAAAgAT
ACLx3gMAAKmD2AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVz
XS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bz
pBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ
7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEp
zoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY69
0fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNs
z8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7r
wVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVW
yozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTe
FNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA6XcmENcAAAD5AAAADwAAAGRycy9kb3du
cmV2LnhtbESPQU8CMRCF7yT+h2ZMvBDpSiKQlUKMi9GYeABM8Dhuh93F7XRpK13+vQ0HPb55k+/l
my9704oTOd9YVnA3ykAQl1Y3XCn42D7fzkD4gKyxtUwKzuRhubgazDHXNvKaTptQiQRhn6OCOoQu
l9KXNRn0I9sRp25vncGQoqukdhgT3LRynGUTabDhtFBjR081ld+bH6PAtttYTN/ccDbVY7P7LIrD
Lh6UurnuHx9ABOrD//PqeP8eJ3/lBfWqFSST/cv5yzV6jT6Qu1ySabIEufgFAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEA6XcmENcAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAsDAAAAAAAAD/AQAAAA0wsAAMMGAAA5DwAAMQgAAA8ADfCD
AAAAAACfDwQAAAAHAAAAAACoDwkAAABNQ0dfRVhUX1AAAKEPHgAAAAoAAAAAAAEAAAAIAAoAAAAB
ACYAAAAEAAwAAAAAAwAAqg8aAAAACQAAAAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPge
AAAAANQBIAHQAkAC8ANgAxAFgAQPAATwtgQAABIACvAIAAAAERAAAAIKAABzAAvwKgAAAH8AAAAE
AIAAvK2+Cr8ABAAEAIEBBAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQBY9PAF1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfgH
ayp1UxWnLApKMagiaou64yGR5TQektB4nNpuEv6+FgtY3rmjc3Xmy8E0oiPna8sKnscJCOLC6ppL
Bfvd+9MMhA/IGhvLpOBMHpaL0d0cU2173lC3DaWIEPYpKqhCaFMpfVGRQT+2LXHsjtYZDDG6UmqH
fYSbRk6S5EUarDkuVNjSqqLiZ/tnFNhm12fTL/c4m+qJOeRZdjr0J6Ue7oe3VxCBhnB7/s3X3Ud+
LS+otVYQTY6f529X6w36QO5yiabREuTiHwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFj0
8AXWAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAKAwAAAAAAAA/wEAAAAGMTAADDBgAACRYAADEIAAAPAA3wbwAAAAAAnw8EAAAABwAAAAAAqA8B
AAAAMAAAoQ8gAAAAAgAAAAAAAQgAAAgAAQACAAAAAQAmAAAABAAMAAAAAAMAAKoPDAAAAAIAAAAG
AAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPA9BAAAQgEK8AgAAAAbEAAA
AgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEBAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi
8dsDAAD/AQAAQACpg88DAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAOBQGabOAAAA7AAAAA8AAABkcnMv
ZG93bnJldi54bWxEj91qAjEQhe8LvkMYoXc1q0gpq1FEEAVbiz8PMG5mN4ubyZLEdX37hlLo5cyc
Oed882VvG9GRD7VjBeNRBoK4cLrmSsHlvHn7ABEissbGMSl4UoDlYvAyx1y7Bx+pO8VKJBMOOSow
Mba5lKEwZDGMXEucbqXzFmMafSW1x0cyt42cZNm7tFhzSjDY0tpQcTvdrYL1Z1VOeH8opxu2Xwez
6trL9lup12G/moGI1Md/8d/3TitI5cvt8+prfcQQyf9uElwCA7n4AQAA//8DAFBLAQItABQABgAI
AAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB
Ai0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsB
Ai0AFAAGAAgAAAAhAOBQGabOAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2Lnht
bFBLBQYAAAAAAwADALcAAAACAwAAAAAAAA/wEAAAADkPAABWAgAAOQ8AAA0OAAAPAATwPQQAAEIB
CvAIAAAAHhAAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAQAACMsBnDEAAP8BGAAY
AL8DAAACACMAIvHbAwAA/wEAAEAAqYPPAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2
pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywN
jCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4
shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/
yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4
P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUT
Uf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9T
MfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQDgUBmmzgAAAOwA
AAAPAAAAZHJzL2Rvd25yZXYueG1sRI/dagIxEIXvC75DGKF3NatIKatRRBAFW4s/DzBuZjeLm8mS
xHV9+4ZS6OXMnDnnfPNlbxvRkQ+1YwXjUQaCuHC65krB5bx5+wARIrLGxjEpeFKA5WLwMsdcuwcf
qTvFSiQTDjkqMDG2uZShMGQxjFxLnG6l8xZjGn0ltcdHMreNnGTZu7RYc0ow2NLaUHE73a2C9WdV
Tnh/KKcbtl8Hs+ray/Zbqddhv5qBiNTHf/Hf904rSOXL7fPqa33EEMn/bhJcAgO5+AEAAP//AwBQ
SwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVs
cy8ucmVsc1BLAQItABQABgAIAAAAIQDgUBmmzgAAAOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMv
ZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAAAgMAAAAAAAAP8BAAAADTCwAAVQUAAAkWAABVBQAA
DwAE8D0EAABCAQrwCAAAAB8QAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADAAQEAAAjL
AZwxAAD/ARgAGAC/AwAAAgAjACLx2wMAAP8BAABAAKmDzwMAAFBLAwQUAAYACAAAACEA2+H2y+4A
AACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQew
EreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt
5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9
bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a
2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxk
svXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAu
sahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+s
PNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEA
4FAZps4AAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESP3WoCMRCF7wu+QxihdzWrSCmrUUQQBVuL
Pw8wbmY3i5vJksR1ffuGUujlzJw553zzZW8b0ZEPtWMF41EGgrhwuuZKweW8efsAESKyxsYxKXhS
gOVi8DLHXLsHH6k7xUokEw45KjAxtrmUoTBkMYxcS5xupfMWYxp9JbXHRzK3jZxk2bu0WHNKMNjS
2lBxO92tgvVnVU54fyinG7ZfB7Pq2sv2W6nXYb+agYjUx3/x3/dOK0jly+3z6mt9xBDJ/24SXAID
ufgBAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtD
b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAA
AAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA4FAZps4AAADsAAAADwAAAAAAAAAAAAAA
AAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAIDAAAAAAAAD/AQAAAA0wsAAMMG
AAAJFgAAwwYAAA8ABPA9BAAAQgEK8AgAAAAgEAAAAgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEA
ABAAwAEBAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi8dsDAAD/AQAAQACpg88DAABQSwMEFAAGAAgA
AAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgg
hNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJ
yBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTe
gLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mv
ic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYA
CAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX
0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRw
GF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH
5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwME
FAAGAAgAAAAhAOBQGabOAAAA7AAAAA8AAABkcnMvZG93bnJldi54bWxEj91qAjEQhe8LvkMYoXc1
q0gpq1FEEAVbiz8PMG5mN4ubyZLEdX37hlLo5cycOed882VvG9GRD7VjBeNRBoK4cLrmSsHlvHn7
ABEissbGMSl4UoDlYvAyx1y7Bx+pO8VKJBMOOSowMba5lKEwZDGMXEucbqXzFmMafSW1x0cyt42c
ZNm7tFhzSjDY0tpQcTvdrYL1Z1VOeH8opxu2Xwez6trL9lup12G/moGI1Md/8d/3TitI5cvt8+pr
fcQQyf9uElwCA7n4AQAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAA
AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAOBQGabOAAAA7AAAAA8A
AAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAACAwAAAAAAAA/w
EAAAANMLAAAxCAAACRYAADEIAAAPAATwPgQAAEIBCvAIAAAAIxAAAAIKAABzAAvwKgAAAL8ABAAE
AH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BGAAYAL8DAAACACMAIvHcAwAA/wEAAEAAqYPQAwAA
UEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH
70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23
jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3
VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0
r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//
AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0
X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8w
Wl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXR
gPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8A
AAD//wMAUEsDBBQABgAIAAAAIQAG5sQ4zwAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BSwMx
EIXvQv9DmEJvNqsUkbVpKZWieNGuXryNm+lmcTNZkmm7219vEMHjzLx5733L9eA7daKY2sAGbuYF
KOI62JYbAx/vu+t7UEmQLXaBycBICdarydUSSxvOvKdTJY3KJpxKNOBE+lLrVDvymOahJ863Q4ge
JY+x0TbiOZv7Tt8WxZ322HJOcNjT1lH9XR29gcouXt62l+LzUY58cZvxdWcrbcxsOmweQAkN8i/+
+362BnL5w9P4FVu7xyQUfzcZLoOBXv0AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQs
W78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEABubE
OM8AAADsAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAA
AAMDAAAAAAAAD/AQAAAA0wsAAFYCAADTCwAADQ4AAA8ABPA+BAAAQgEK8AgAAAAkEAAAAgoAAHMA
C/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEYABgAvwMAAAIAIwAi8dwDAAD/
AQAAQACpg9ADAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10u
eG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QW
iuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/j
jCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6E
MiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHy
baWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/B
asMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ
9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqM
xfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTa
unYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAAbmxDjPAAAA7AAAAA8AAABkcnMvZG93bnJl
di54bWxEj0FLAzEQhe9C/0OYQm82qxSRtWkplaJ40a5evI2b6WZxM1mSabvbX28QwePMvHnvfcv1
4Dt1opjawAZu5gUo4jrYlhsDH++763tQSZAtdoHJwEgJ1qvJ1RJLG868p1MljcomnEo04ET6UutU
O/KY5qEnzrdDiB4lj7HRNuI5m/tO3xbFnfbYck5w2NPWUf1dHb2Byi5e3raX4vNRjnxxm/F1Zytt
zGw6bB5ACQ3yL/77frYGcvnD0/gVW7vHJBR/Nxkug4Fe/QAAAP//AwBQSwECLQAUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQA
BgAIAAAAIQAG5sQ4zwAAAOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUG
AAAAAAMAAwC3AAAAAwMAAAAAAAAP8BAAAAAJFgAAVgIAAAkWAAANDgAADwAE8D4EAABCAQrwCAAA
ACUQAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/ARgAGAC/AwAA
AgAjACLx3AMAAP8BAABAAKmD0AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250
ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg
6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXut
xYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAm
ZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh
+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3Jl
bHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+En
rWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslp
x4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T
1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEABubEOM8AAADsAAAADwAA
AGRycy9kb3ducmV2LnhtbESPQUsDMRCF70L/Q5hCbzarFJG1aSmVonjRrl68jZvpZnEzWZJpu9tf
bxDB48y8ee99y/XgO3WimNrABm7mBSjiOtiWGwMf77vre1BJkC12gcnASAnWq8nVEksbzrynUyWN
yiacSjTgRPpS61Q78pjmoSfOt0OIHiWPsdE24jmb+07fFsWd9thyTnDY09ZR/V0dvYHKLl7etpfi
81GOfHGb8XVnK23MbDpsHkAJDfIv/vt+tgZy+cPT+BVbu8ckFH83GS6DgV79AAAA//8DAFBLAQIt
ABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u
eG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5y
ZWxzUEsBAi0AFAAGAAgAAAAhAAbmxDjPAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3du
cmV2LnhtbFBLBQYAAAAAAwADALcAAAADAwAAAAAAAA/wEAAAANMLAABWAgAACRYAAFYCAAAPAATw
PgQAAEIBCvAIAAAAJhAAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAQAACMsBn28A
AP8BGAAYAL8DAAACACMAIvHcAwAA/wEAAEAAqYPQAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAG5sQ4
zwAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BSwMxEIXvQv9DmEJvNqsUkbVpKZWieNGuXryN
m+lmcTNZkmm7219vEMHjzLx5733L9eA7daKY2sAGbuYFKOI62JYbAx/vu+t7UEmQLXaBycBICdar
ydUSSxvOvKdTJY3KJpxKNOBE+lLrVDvymOahJ863Q4geJY+x0TbiOZv7Tt8WxZ322HJOcNjT1lH9
XR29gcouXt62l+LzUY58cZvxdWcrbcxsOmweQAkN8i/++362BnL5w9P4FVu7xyQUfzcZLoOBXv0A
AAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250
ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAf
AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEABubEOM8AAADsAAAADwAAAAAAAAAAAAAAAAAH
AgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAMDAAAAAAAAD/AQAAAA0wsAAA0OAAAJ
FgAADQ4AAA8ABPCwAAAAQgEK8AgAAACwEAAAAgoAAMMAC/BIAAAAhQACAAAAhwABAAAAvwAAAA8A
vwEAABAAwAEBAAAIywGcMQAA/wEMAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi
8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/w
EAAAANMLAADoAwAACRYAAOgDAAAPAATwsAAAAEIBCvAIAAAAzBAAAAIKAADDAAvwSAAAAIEAAAAA
AIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAPAL8BAAAQAMABAQAACMsBnDEAAP8BDAAOAD8CAAADAL8C
AAAIAH8DAAAPAIMAIvEwAAAAfwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYG
AE4AfwYGAA4AAAAP8BAAAABjEwAAVgIAAGMTAAANDgAADwAE8LAAAABCAQrwCAAAAP0QAAACCgAA
wwAL8EgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQADwC/AQAAEADAAQEAAAjLAZwxAAD/
AQwADgA/AgAAAwC/AgAACAB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8F
BgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA0wsAAJ8JAAAJFgAAnwkAAA8ABPCwAAAAQgEK
8AgAAAANEQAAAgoAAMMAC/BIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAA8AvwEAABAA
wAEBAAAIywGcMQAA/wEMAA4APwIAAAMAvwIAAAgAfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/
AwCCAIJ/BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAANMLAAAxCwAACRYAADEL
AAAPAATwsAAAAEIBCvAIAAAAHREAAAIKAADDAAvwSAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA
AL8ABAAPAL8BAAAQAMABAQAACMsBnDEAAP8BDAAOAD8CAAADAL8CAAAIAH8DAAAPAIMAIvEwAAAA
fwEAAEAA/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAADT
CwAAnwwAAAkWAACfDAAADwAE8DIMAAASAArwCAAAACcQAAAACgAAwwAL8GAAAAB/AAAA7wGAAEQI
wAqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQAAEQD/AQAAGAA/AwAACACAwxgAAAC/
AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAAAABDwCAAAAEUBVAChC80ODwAN8KILAAAAAJ8P
BAAAAAQAAAAAAKAPOggAAEkAbgBpAHQAJgBwAHIAbwBiAGUAIABpAG4AdABlAHIAZgBhAGMAZQA6
AA0ATQBDAEcAXwBDAEEAUAANAFIAZQBhAGQALQBvAG4AbAB5ACAATQBTAFIALAAgAGUAbQB1AGwA
YQB0AGUAZAAgAGEAcwAgABggdwByAGkAdABlACAAbgBvAHQAIABjAGgAYQBuAGcAZQBzABkgIABz
AGkAbgBjAGUAIAB3AHIAaQB0AGUAIABlAGYAZgBlAGMAdAAgAGkAcwAgAHUAbgBkAGUAZgBpAG4A
ZQBkAA0ARABpAHMAYQBiAGwAZQAgAFMAUgBBAE8ALwBTAFIAQQBSAC0AdQBuAHIAZQBsAGEAdABl
AGQAIABjAGEAcAAgACAAKAAwACkADQBNAEMARwBfAEMAVABMAF8AUAA9ADAAIAB0AG8AIABkAGkA
cwBhAGIAbABlACAATQBDAEcAXwBDAFQATAANAE0AQwBHAF8ARQBYAFQAXwBQAD0AMAAsACAAbgBv
ACAAZQB4AHQAIAByAGUAZwBzACwAIAByAGQAbQBzAHIALwB3AHIAbQBzAHIAIABmAG8AcgAgADEA
OAAwAEgALQAxADgANQBIAC8AMQA4ADgASAAtADEAOQA3AEgAIABjAGEAdQBzAGUAIABHAFAAIwAN
AEUAbgBhAGIAbABlACAAUwBSAEEATwAvAFMAUgBBAFIALQByAGUAbABhAHQAZQBkACAAYwBhAHAA
IAAgACAAIAAgACAAKAAxACkADQBFAG4AYQBiAGwAZQAgAE0AQwBHAF8AVABFAFMAXwBQACAAdABv
ACAAYQB2AG8AaQBkACAAbQBvAGQAZQBsACAAcwBwAGUAYwBpAGYAaQBjAA0ARQBuAGEAYgBsAGUA
IABNAEMARwBfAFMARQBSAF8AUAAgAHQAbwAgAHMAdQBwAHAAbwByAHQAIABzAC8AdwAgAHIAZQBj
AG8AdgBlAHIAeQANAEUAbQB1AGwAYQB0AGUAIABvAG4AbAB5ACAAMQAgAGIAYQBuAGsAIAB0AG8A
IABnAHUAZQBzAHQADQBNAGkAZwByAGEAdABpAG8AbgAgAHcAbwB1AGwAZAAgAG4AbwB0ACAAYgBs
AG8AYwBrAGUAZAAgAHQAaABlAG4ADQBJAGYAIAByAGUAYQBsAGwAeQAgADIAIABwAGgAeQBzAGkA
YwBhAGwAIABlAHIAcgBvAHIAIABvAGMAYwB1AHIAIABhAHQAIAAxACAATQBDAEUAIwAsACAAaAB5
AHAAZQByAHYAaQBzAG8AcgAgAHcAbwB1AGwAZAAgAGMAcgBhAHMAaAA7AA0ARABlAGwAaQB2AGUA
cgAgAHQAaABlACAAYgBhAG4AawAgAGkAbgBkAGkAYwBhAHQAZQAgAFMAUgBBAE8ALwBTAFIAQQBS
ACAAZQByAHIAbwByACAAdABvACAAZwB1AGUAcwB0AA0AQwB1AHIAcgBlAG4AdABsAHkAIAB3AGUA
IABkAGkAcwBhAGIAbABlACAATQBDAEcAXwBDAE0AQwBJAF8AUAAsACAAYgB1AHQAIABlAG4AYQBi
AGwAaQBuAGcAIABpAHQAIABtAGEAeQAgAGIAZQBuAGUAZgBpAHQAIAB0AGgAYQB0ACAAZwB1AGUA
cwB0ACAAbQBhAHkAIABuAG8AdAAgAHAAbwBsAGwAIABiAGEAbgBrAHMAIABwAGUAcgBpAG8AZABp
AGMAYQBsAGwAeQAgACoADQBNAEMARwBfAEMAVABMAA0ARABpAHMAYQBiAGwAZQAgAGkAdAAgAHYA
aQBhACAATQBDAEcAXwBDAFQATABfAFAAIAA9ACAAMAANAE4AbwAgAG0AbwBkAGUAbAAgAHMAcABl
AGMAaQBmAGkAYwAgAGkAcwBzAHUAZQANAE0AQwBpAF8AQwBUAEwADQBTAHQAaQBjAGsAIABhAGwA
bAAgADEAGSBzAA0AUAByAGUAdgBlAG4AdAAgAG0AbwBkAGUAbAAgAHMAcABlAGMAaQBmAGkAYwAg
AGkAcwBzAHUAZQANAE4AYQB0AGkAdgBlAGwAeQAgAG0AbwBzAHQAIABNAEMAaQBfAEMAVABMACAA
YgBpAHQAcwAgAGEAcgBlACAAGCBuAG8AdAAgAGkAbQBwAGwAZQBtAGUAbgB0ABkgLgAgAFAAcgBv
AGMAZQBzAHMAbwByACAAZABvAGUAcwAgAG4AbwB0ACAAdwByAGkAdABlACAAYwBoAGEAbgBnAGUA
cwAgAHQAbwAgAGIAaQB0AHMAIAB0AGgAYQB0ACAAYQByAGUAIABuAG8AdAAgAGkAbQBwAGwAZQBt
AGUAbgB0AHMADQBNAEMAaQBfAEMAVABMACAAYgBpAHQAcwAgAGEAcgBlACAAdQBzAHUAYQBsAGwA
eQAgAGYAbwByACAAaAAvAHcAIABkAGUAYgB1AGcAIABwAHUAcgBwAG8AcwBlACwAIABvAHMAIABu
AG8AcgBtAGEAbABsAHkAIABzAGUAdAAgAHQAaABlAG0AIABhAGwAbAAgADEAGSBzAC4ADQBJAGYA
IABnAHUAZQBzAHQAIABjAHIAYQB6AHkAIABjAGwAZQBhAHIAIABhAG4AeQAgAGIAaQB0ACwAIABq
AHUAcwB0ACAAdAByAGUAYQB0ACAAdABoAGUAIABiAGkAdAAgAGEAcwAgABggbgBvAHQAIABpAG0A
cABsAGUAbQBlAG4AdAAZIC4AIABHAHUAZQBzAHQAIAB3AG8AdQBsAGQAIABuAG8AdAAgAHMAdQBy
AHAAcgBpAHMAZQAuAAAAoQ9EAgAAFgAAAAAASTgKAAkAbgAAAFoAKAAHAAgAAAABANs4CgALANgA
AgBpAAAAWgAKAAcAdAAAAAIA2zgKAAsA2AACAGkAAABaAAoABwBnAAAAAwDbOAoACwDYAAIAaQAA
AFoACgAHACYAAAACANs4CgALANgAAgBpAAAAWgAKAAcAbwAAAAMAATgKAAEAAABaAAoABwCYAAAA
BAABOAoAAQAAAFoACgAHAGoAAAACANs4CgALANgAAgBpAAAAWgAKAAcACAAAAAEA2zgKAAsA2AAC
AGkAAABaAAoABwA1AAAAAgDbOAoACwDYAAIAaQAAAFoACgAHAAgAAAABANs4CgALANgAAgBpAAAA
WgAKAAcAKwAAAAIA2zgKAAsA2AACAGkAAABaAAoABwAeAQAAAwDbOAoACwDYAAIAaQAAAFoACgAH
ABYAAAAAACIABAAQAAgAAAAABCIAAAQEAA4AcQAAAAAIIgAACAQADAABAAAAAAgmAAAIBAAMAAAA
AAMCAAAAAAgiAAAIBAAMAGcAAAAACCIAAAgEAAoAIwAAAAAMIgAADAQADAABAAAAAAwmAAAMBAAM
AAykKf4CAAAAAAwiAAAMBAAMAG8AAAAAECIAABAEAAoAmAAAAAAUIgAAFAQACgBpAAAAABgiAAAY
BAAMAAEAAAAAGCIAABgEAAoACAAAAAAYIgAAGAQADgA1AAAAABwiAAAcBAAMAAgAAAAAHCIAABwE
AA4AKwAAAAAgIgAAIAQADAAeAQAAACQiAAAkBAAKAAAAqg/qAAAACgAAAAcAAAADAAkEBAi7AAAA
BgAAAAkEBAgEAAAABwAAAAMACQQECAIAAAAGAAAACQQECAsAAAAHAAAAAwAJBAQIjgAAAAYAAAAJ
BAQIAwAAAAcAAAADAAkEBAhmAQAABgAAAAkEBAgHAAAABwAAAAMACQQECDoAAAAGAAAACQQECAcA
AAAHAAAAAwAJBAQIXAAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAgWAAAABgAAAAkEBAgDAAAABwAA
AAMACQQECBAAAAAGAAAACQQECAIAAAAHAAAAAwAJBAQIewAAAAYAAAAJBAQIAACmDw4AAAD4AAAA
jgDUAdAC8AMQBQ8ABPBIAAAAEgAK8AgAAAAoEAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO
n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcA
psrhAFZ+uQAMLoYAqgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA
AIsTaQAAAAAA6y4IAAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMA
AAAAAAAAAAAAAAAAAAAAAMkK/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAA
IgQIAAAAAQAAAAYAAAAPAO4DaAoAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAHAAwwDwAM
BH8JAAAPAALwdwkAAEACCPAIAAAABQAAAAWcAAAPAAPwDwkAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA
AAAAAAAAAAAAAAAAAgAK8AgAAAAAnAAABQAAAA8ABPAgAQAAogwK8AgAAAACnAAAAAoAAMMAC/Bu
AAAAfwABAO8BgABENb4KgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgA
PwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAA
ABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAA
AAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcPCAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAA
AAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CwBAACiDArwCAAAAAOc
AAAACgAAwwAL8H4AAAB/AAEA7wGAAMzurgqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/
AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAA
bABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDwCAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAA
AAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgP
BAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQ
AvADEAUPAATwKgEAABIACvAIAAAABJwAACACAAATAQvwfgAAAAQAAAAAAH8AAQDvAYAAVBLACoEA
AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDAwQA
AD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAA
ywAOAWsVWQIPABHwEAAAAAAAwwsIAAAA/////w0AvgoPAA3wZAAAAAAAnw8EAAAAAAAAAAAAqA8a
AAAAUG9pbnQgMTogTVNSIGVtdWxhdGlvbiAoMikAAKEPGgAAABsAAAAAAAAICgABAAcAGwAAAAEA
IAAAAAQAAACqDwwAAAAbAAAABgAAAAkEBAgPAATwSQUAABIACvAIAAAABZwAACACAAATAQvwfgAA
AAQAAAAAAH8AAQDvAYAAGBTACoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgA
AAAAAL8ABAAEAP8BAAARAAEDBAQAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBu
AGcAbABlACAAMwAAAAAAEPAIAAAAZQJNAC0WsA4PABHwEAAAAAAAwwsIAAAA/////w4AwAoPAA3w
gwQAAAAAnw8EAAAAAQAAAAAAqA81AgAARXJyb3ItaW5mbyBpbnRlcmZhY2UNQSB0cmFuc2ZlciBs
YXllcg1GaWx0ZXIgbm9uLVNSQU8vU1JBUiBiYW5rcw1UcmFuc2xhdGUgaG9zdCBhZGRyZXNzIHRv
IGd1ZXN0IGFkZHJlc3MNRGVsaXZlcjoNRXZhbHVhdGUgYW5kIGRlbGl2ZXIgdGhlIG1vc3Qgc2V2
ZXJlIGVycm9yIHRvIHZjcHUwDQ1NQ0dfU1RBVFVTDUJpdDYzOjMgcmVzZXJ2ZWQsIHdybXNyIHNo
b3VsZCBiZSBzYW1lIGFzIHJkbXNyIG90aGVyd2lzZSBHUCMNDU1DaV9TVEFUVVMNQ2xlYXIgYnkg
d3JpdGluZyAwcywgd3JpdGluZyAxcyBjYXVzZXMgR1AjDQ1NQ2lfQUREUi9NQ2lfTUlTQw1FbXVs
YXRlZCBhcyBhbHdheXMgaW1wbGVtZW50ZWQgKG5vIHJkbXNyL3dybXNyIEdQIyBpc3N1ZSksIEFE
RFJWL01JU0NWPTAgbWVhbnMgbm8gYWRkci9pbmZvDUNsZWFyIGJ5IHdyaXRpbmcgMHMsIHdyaXRp
bmcgMXMgY2F1c2VzIEdQIw1UcmFuc2xhdGUgaG9zdCBhZGRyZXNzIHRvIGd1ZXN0IGFkZHJlc3MN
DU1DaV9DTFQyDUN1cnJlbnRseSBkZXNpZ25lZCBhcyBkaXNhYmxlZCBieSBNQ0dfQ01DSV9QPTAs
IHJkL3dybXNyIGNhdXNlIEdQIwAAoQ9MAQAAFQAAAAAAABAAAFoAEQAAAAEAABAKAFoABwBMAAAA
AgAAEAoAWgAHADUAAAADAAAQCgBaAAcACwAAAAEAABAKAFoABwA/AAAAAgAAEAoAWgAHAAsAAAAB
AAAQCgBaAAcALAAAAAIAABAAAFoAEgAAAAEAABAKAFoABwCwAAAAAgAAEAoAWgAHAAkAAAABAAAQ
CgBaAAcAQwAAAAIAABAKAFoABwAVAAAAAQAiAAAABAASABEAAAAABCIAAAQEABAATAAAAAAIIgAA
CAQADgA1AAAAAAwiAAAMBAAMAAsAAAAAECIAABAEABAAPwAAAAAQIgAAEAQADgALAAAAABQiAAAU
BAAQACwAAAAAFCIAABQEAA4AEgAAAAAYIgAAGAQAEACwAAAAABgiAAAYBAAOAAkAAAAAHCIAABwE
ABAAQwAAAAAgIgAAIAQADgAAAKoPwgAAAMQAAAAGAAAACQQECAUAAAAHAAAAAwAJBAQIEwAAAAYA
AAAJBAQIBQAAAAcAAAADAAkEBAgQAAAABgAAAAkEBAgKAAAABwAAAAMACQQECC0AAAAGAAAACQQE
CBEAAAAHAAAAAwAJBAQIJAAAAAYAAAAJBAQICwAAAAcAAAADAAkEBAgkAAAABgAAAAkEBAgEAAAA
BwAAAAMACQQECJYAAAAGAAAACQQECAUAAAAHAAAAAwAJBAQICwAAAAYAAAAJBAQIAACmDxQAAADw
HgAA1AEgAdACQALwA2ADEAWABA8ABPBIAAAAEgAK8AgAAAABnAAAAAwAAIMAC/AwAAAAgQEAAAAI
gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8ACGCo
AP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAA
UABUADEAMAAAAIsTaQAAAAAA6y4IAAAAv/rHAdCjhesAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/Eg
AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAMkK/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAP
AAIrAAAAAA8A7gNXDAAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcADDAPAAwEbgsAAA8A
AvBmCwAA0AEI8AgAAAAFAAAABXQAAA8AA/D+CgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA
AAAAAAACAArwCAAAAAB0AAAFAAAADwAE8CABAACiDArwCAAAAAJ0AAAACgAAwwAL8G4AAAB/AAEA
7wGAALQWwAqBAAAAAACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACA
wyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAA
XBC+D5gRqhAPAA3wggAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAA
AAIAAAABACYAAQADAAgAsrKy/gAA9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkE
AQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAA3QAAAAKAADD
AAvwfgAAAH8AAQDvAYAAFE/ACoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8B
EAAYAD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBl
AGgAbwBsAGQAZQByACAANAAAAAAAEPAIAAAAXRC4Dr4PqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAA
oA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAA
AAAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8A
BPAqAQAAEgAK8AgAAAAEdAAAIAIAABMBC/B+AAAABAAAAAAAfwABAO8BgAC8JMAKgQAAAAAAggAA
AAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA/wEAABEAAQMDBAAAPwMAAAgA
gMMYAAAAiAMAAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADLAA4BaxVZ
Ag8AEfAQAAAAAADDCwgAAAD/////DQDACg8ADfBkAAAAAACfDwQAAAAAAAAAAACoDxoAAABQb2lu
dCAxOiBNU1IgZW11bGF0aW9uICgzKQAAoQ8aAAAAGwAAAAAAAAgKAAEABwAbAAAAAQAgAAAABAAA
AKoPDAAAABsAAAAGAAAACQQECA8ABPA4BwAAEgAK8AgAAAAFdAAAIAIAABMBC/B+AAAABAAAAAAA
fwABAO8BgAA8XMAKgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAE
AAQA/wEAABEAAQMEBAAAPwMAAAgAgMMYAAAAiAMAAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA
IAAzAAAAAAAQ8AgAAABlAk0ALRawDg8AEfAQAAAAAADDCwgAAAD/////DgDACg8ADfByBgAAAACf
DwQAAAABAAAAAACgDxwEAABOAG8AIABuAG8AbgAtAGEAcgBjAGgAIABpAHMAcwB1AGUAcwAgAGEA
ZwBhAGkAbgANAEYAbwByACAAZgBhAG0AaQBsAHkALQBtAG8AZABlAGwAIABpAHMAcwB1AGUAcwAg
AHIAbwBvAHQAIABmAHIAbwBtACAAbABlAGcAYQBjAHkAIABwAHIAbwBjAGUAcwBzAG8AcgBzAA0A
RABvAG4AGSB0ACAAYwBhAHIAZQAsACAAZwB1AGUAcwB0ACAAdwBvAHUAbABkACAAbgBvAHQAIABz
AHUAcgBwAHIAaQBzAGUADQBHAHUAZQBzAHQAIABwAHIAbwBiAGUAIABtAGMAZQAgAGMAYQBwAGEA
YgBpAGwAaQB0AGkAZQBzACAAdgBpAGEAIABNAEMARwBfAEMAQQBQACwAIABuAG8AdAAgAGMAcAB1
AGkAZAANAA0ARgBvAHIAIABtAG8AZABlAGwALQBzAHAAZQBjAGkAZgBpAGMAIABpAHMAcwB1AGUA
cwANADIAIABtAG8AZABlAGwALQBzAHAAZQBjAGkAZgBpAGMAIABmAGkAZQBsAGQAcwANAE0AQwBH
AF8AQwBUAEwALwBNAEMAaQBfAEMAVABMAA0ATQBDAGkAXwBTAFQAQQBUAFUAUwAgABMgIABNAFMA
QwBPAEQAIABtAG8AZABlAGwAIABzAHAAZQBjAGkAZgBpAGMAIABlAHIAcgBvAHIAIABjAG8AZABl
AA0ADQBGAG8AcgAgAE0AQwBHAF8AQwBUAEwALwBNAEMAaQBfAEMAVABMAA0ARgBvAHIAIABNAEMA
RwBfAEMAVABMACwAIABkAGkAcwBhAGIAbABlACAAaQB0ACAAdgBpAGEAIABNAEMARwBfAEMAVABM
AF8AUAAgAD0AIAAwAA0ARgBvAHIAIABNAEMAaQBfAEMAVABMAA0AUwB0AGkAYwBrACAAYQBsAGwA
IAAxABkgcwANAEkAZgAgAGcAdQBlAHMAdAAgAGMAcgBhAHoAeQAgAHcAcgBpAHQAZQAgAGIAaQB0
ACAAdABvACAAMAAsACAAdAByAGUAYQB0ACAAaQB0ACAAYQBzACAAGCBuAG8AdAAgAGkAbQBwAGwA
ZQBtAGUAbgB0ABkgIABiAGkAdAAgAGEAbgBkACAAcwBpAG0AcABsAHkAIABpAGcAbgBvAHIAZQAg
AHcAcgBpAHQAZQANAA0ARgBvAHIAIABNAEMAaQBfAFMAVABBAFQAVQBTACAAGCBNAFMAQwBPAEQA
GSAgAG0AbwBkAGUAbAAgAHMAcABlAGMAaQBmAGkAYwAgAGUAcgByAG8AcgAgAGMAbwBkAGUADQBT
AHQAaQBjAGsAIABhAGwAbAAgADAAGSBzACAAdABvACAAZwB1AGUAcwB0AAAAoQ9UAQAAGQAAAAAA
AAAKAAcANAAAAAEAAAAKAAcAWQAAAAIAAAAKAAcAAQAAAAIAAQAKAAAABwAaAAAAAQAAAAoABwAY
AAAAAgAAAAoABwA9AAAAAwAAAAoABwABAAAABAABAAoAAAAHABQAAAACAAAACgAHADYAAAADAAAA
CgAHAGUAAAAEAAAACgAHAAEAAAAEAAEACgAAAAcAMQAAAAIAAAAKAAcAFwAAAAMAAAAAABkAAAAB
ACAAAAAEADQAAAAABCAAAAQEAFkAAAAACCAAAAgEAAEAAAAADCAAAAwEABoAAAAADCAAAAwEABgA
AAAAECAAABAEAD0AAAAAFCAAABQEAAEAAAAAGCAAABgEABQAAAAAHCAAABwEADYAAAAAICAAACAE
AGUAAAAAJCAAACQEAAEAAAAAKCAAACgEADEAAAAALCAAACwEABcAAAAAMCAAADAEAAAAqg/CAAAA
fgAAAAYAAAAJBAQIAwAAAAcAAAADAAkEBAgfAAAABgAAAAkEBAgFAAAABwAAAAMACQQECDwAAAAG
AAAACQQECAcAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQICgAAAAcAAAADAAkEBAgwAAAABgAAAAkE
BAgHAAAABwAAAAMACQQECC8AAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIawAAAAYAAAAJBAQICgAA
AAcAAAADAAkEBAg6AAAABgAAAAkEBAgAAKYPFAAAAPAeAADUASAB0AJAAvADYAMQBYAEDwAE8EgA
AAASAArwCAAAAAF0AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/
AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAIYKgA/1xHAPXmRwCmyuEAVn65AAwuhgCqAUwA
DwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAC/
+scB0KOF6wAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA
yQr/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuA84LAAACAO8DGAAAABAA
AAAAAAAAAAAAAAAAAIABAQAABwAMMA8ADATVCgAADwAC8M0KAAAQAQjwCAAAAAUAAAAGFAAADwAD
8GUKAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABQAAAUAAAAPAATw
IAEAAKIMCvAIAAAAAhQAAAAKAADDAAvwbgAAAH8AAQDvAYAAgGbACoEAAAAAAIIAAAAAAIMAAAAA
AIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0AGUAIABQAGwA
YQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4PmBGqEA8ADfCCAAAAAACfDwQAAAAE
AAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AAD3DwgA
AAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADU
AdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADFAAAAAoAAMMAC/B+AAAAfwABAO8BgAAMbcAKgQAAAAAA
ggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMM2AAAAvwMAAAIAUwBs
AGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA0AAAAAAAQ8AgA
AABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgA
AAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAAEQQJBAEA
AAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CEBAAASAArwCAAAAAQUAAAgAgAAAwEL
8HgAAAAEAAAAAAB/AAEA7wGAAIymwAqBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAAAACHAAAA
AACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBn
AGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR8BAAAAAAAMMLCAAAAP////8NAMAKDwAN8GEA
AAAAAJ8PBAAAAAAAAAAAAKgPFwAAAFBvaW50IDI6IGxpdmUgbWlncmF0aW9uAAChDxoAAAAYAAAA
AAAACAoAAQAHABgAAAABACAAAAAEAAAAqg8MAAAAGAAAAAYAAAAJBAQIDwAE8KgGAAASAArwCAAA
AAUUAAAgAgAAAwEL8HgAAAAEAAAAAAB/AAEA7wGAACiqwAqBAAAAAACCAAAAAACDAAAAAACEAAAA
AACFAAAAAACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwQEAAA/AwAACACAwxgAAAC/AwAAAgBS
AGUAYwB0AGEAbgBnAGwAZQAgADMAAAAAABDwCAAAAIQCmQDsFZcODwAR8BAAAAAAAMMLCAAAAP//
//8OAMAKDwAN8OgFAAAAAJ8PBAAAAAEAAAAAAKAPngMAAGwAaQB2AGUAIABtAGkAZwByAGEAdABp
AG8AbgAgAGkAcwBzAHUAZQA6AA0AaQBmACAAbQBpAGcAcgBhAHQAZQAgAGYAcgBvAG0AIABBACAA
KABsAGEAcgBnAGUAIABiAGEAbgBrACkAIAB0AG8AIABCACAAKABzAG0AYQBsAGwAIABiAGEAbgBr
ACkADQB3AGkAbABsACAARwBQACMAIABhAHQAIABCACAAdwBoAGUAbgAgAGEAYwBjAGUAcwBzACAA
TQBDAGkAXwBDAFQATAANAEoAYQBuABkgcwAgAHAAYQB0AGMAaAAgAHAAYQByAHQAbAB5ACAAcwBv
AGwAdgBlACAAcAByAG8AYgBsAGUAbQAgAGIAeQAgAHMAYQB2AGUALwByAGUAcwB0AG8AcgBlACAA
TQBDAEcAXwBDAEEAUAAsACAAYQB2AG8AaQBkACAARwBQACMADQBCAHUAdAAgAEIAIABjAGEAbgAg
AG8AbgBsAHkAIAByAC8AdwAgAHMAbwBtAGUAIABNAEMAaQBfAEMAVABMACAAYQBmAHQAZQByACAA
bQBpAGcAcgBhAHQAZQANAA0AYQBwAHAAcgBvAGEAYwBoADoADQBOAG8AdABoAGkAbgBnACAAcwBw
AGUAYwBpAGEAbAAgAG4AZQBlAGQAIAB0AG8AIABkAG8ADQBGAG8AcgAgAGUAcgByAG8AcgAtAGkA
bgBmAG8AIABNAFMAUgBzAA0AcABvAGkAbgB0AGwAZQBzAHMAIAB0AG8AIABiAGUAIABtAGkAZwBy
AGEAdABlAGQADQBGAG8AcgAgAGkAbgBpAHQAJgBwAHIAbwBiAGUAIABNAFMAUgBzAA0ATQBDAEcA
XwBDAEEAUAAgAGkAcwAgAHUAbgBpAGYAaQBlAGQAIABhAHQAIABhAG4AeQAgAHAAbABhAHQAZgBv
AHIAbQANADEAIABiAGEAbgBrACwAIABuAG8AIABHAFAAIwAgAHAAcgBvAGIAbABlAG0AIABjAGEA
dQBzAGUAZAAgAGIAeQAgAGIAYQBuAGsAIABuAHUAbQBiAGUAcgANAEYAbwByACAATQBDAEcAXwBD
AFQATAAvAE0AQwBpAF8AQwBUAEwADQBNAEMARwBfAEMAVABMACAAZABpAHMAYQBiAGwAZQBkAA0A
TQBDAGkAXwBDAFQATAAgAHMAdABpAGMAawAgAHQAbwAgAGEAbABsACAAMQAZIHMAAAChDy4BAAAW
AAAAAAAAAAoABwAxAAAAAQAAAAoABwCVAAAAAgAAAAoABwAKAAAAAAAAAAoABwAbAAAAAQAAAAoA
BwAUAAAAAgAAAAoABwAZAAAAAwAAAAoABwAUAAAAAgAAAAoABwAjAAAAAwAAAAoABwAtAAAABAAA
AAoABwAUAAAAAwAAAAoABwAqAAAABAAAAAoABwAWAAAAAQAgAAAABAAxAAAAAAQgAAAEBACVAAAA
AAggAAAIBAAJAAAAAQwgAAAMBAABAAAAAAwgAAEMBAAbAAAAABAgAAAQBAAUAAAAABQgAAAUBAAZ
AAAAABQgAAAUBAAUAAAAABggAAAYBAAjAAAAABwgAAAcBAAtAAAAABwgAAAcBAAUAAAAACAgAAAg
BAAqAAAAACSgAAAkBAACAAAAqg/cAAAAYQAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAhUAAAABgAA
AAkEBAgDAAAABwAAAAMACQQECAYAAAAGAAAACQQECAcAAAAHAAAAAwAJBAQIRAAAAAYAAAAJBAQI
BAAAAAcAAAADAAkEBAgeAAAABgAAAAkEBAgKAAAABwAAAAMACQQECAEAAAAGAAAACQQECAQAAAAH
AAAAAwAJBAQIXQAAAAYAAAAJBAQIBwAAAAcAAAADAAkEBAgSAAAABgAAAAkEBAgHAAAABwAAAAMA
CQQECBIAAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQPAATwSAAAABIACvAI
AAAABhQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD
CQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgTkQAA
AA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAL/6xwHQo4Xr
AAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADACv////8S
AAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAACIECAAAAAEAAAAGAAAADwDuA9kIAAAC
AO8DGAAAABAAAAAAAAAAAAAAAAAAAIADAQAABwAMMA8ADATwBwAADwAC8OgHAADgAQjwCAAAAAUA
AAAFeAAADwAD8IAHAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAHgA
AAUAAAAPAATwIAEAAKIMCvAIAAAAAngAAAAKAADDAAvwbgAAAH8AAQDvAYAA8MTACoEAAAAAAIIA
AAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0
AGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAABcEL4PmBGqEA8ADfCCAAAA
AACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACy
srL+AAD3DwgAAAAAAAAAAFLYCQAAqg8aAAAAAQAAAAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYP
DAAAAPAAAADUAdAC8AMQBQ8ABPAsAQAAogwK8AgAAAADeAAAAAoAAMMAC/B+AAAAfwABAO8BgAAU
4L4KgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMM2AAAA
vwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA0
AAAAAAAQ8AgAAABdELgOvg+qEA8ADfB+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAA
AgAAAAAAAAgAAAAAAgAAAAEAJgABAAMACACysrL+AADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAA
AAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8CYBAAASAArwCAAAAAR4
AAAgAgAAEwEL8H4AAAAEAAAAAAB/AAEA7wGAAOTxwAqBAAAAAACCAAAAAACDAAAAAACEAAAAAACF
AAAAAACHAAAAAACIAAAAAAC/AAQABAD/AQAAEQABAwMEAAA/AwAACACAwxgAAACIAwAAAAC/AwAA
AgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAMsADgFrFVkCDwAR8BAAAAAAAMMLCAAA
AP////8NAMAKDwAN8GAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFBvaW50IDM6IE1DRSBpbmplY3Rp
b24AAKEPGgAAABcAAAAAAAAICgABAAcAFwAAAAEAIAAAAAQAAACqDwwAAAAXAAAABgAAAAkEBAgP
AATwvgMAABIACvAIAAAABXgAACACAAAjAQvwhAAAAAQAAAAAAH8AAQDvAYAAEADBCoEAAAAAAIIA
AAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAL8BAAABAP8BAAARAAEDBAQA
AD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAA
hAJRASEVlw4PABHwEAAAAAAAwwsIAAAA/////w4AwAoPAA3w8gIAAAAAnw8EAAAAAQAAAAAAqA9Q
AQAASW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzDUFueSByaXNrIHdoZW4gdmNwdXMgPiBwY3B1cywg
YW5kIGluamVjdGlvbnMgb2NjdXIgYXQgYSBsb25nIHRpbWUgd2luZG93Pw1Gb3Igd2luOCwgdGVz
dCBpbmRpY2F0ZSBvaw1Gb3IgbGludXgsIGl0IGNhbiB0b2xlcmF0ZSB0aGlzIGNhc2UgKFRvbnkg
THVjaykNRm9yIFNvbGFyaXMsIGl0IGNhbiB0b2xlcmF0ZSB0aGlzIGNhc2UgKEFzaG9rKQ1Db25j
ZXJuOiBoeXBlcnZpc29yIHNob3VsZCBiZSBndWVzdCBhZ25vc3RpYw1BcHByb2FjaCBmb3IgdmNw
dXMgPiBwY3B1cw1Ub2xlcmF0ZSBpdA1Xb3JzdCBjYXNlIGlzIGd1ZXN0IGtpbGwgaXRzZWxmAACh
D6AAAAAZAAAAAAAAAAoABwBJAAAAAQAAAAoABwCoAAAAAgAAAAoABwAbAAAAAQAAAAoABwAMAAAA
AgAAAAoABwAgAAAAAwAAAAoABwAZAAAAAQAgAAAABABJAAAAAAQgAAAEBACoAAAAAAQgAAAEBAAa
AAAAAAggAAAIBAABAAAAAAgkAAAIBAAAAAACDAAAAAAMIAAADAQAIAAAAAAQIAAAEAQAAACqD8IA
AAAHAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAgAAAAGAAAACQQECAUAAAAHAAAAAwAJBAQIDwAA
AAYAAAAJBAQIBQAAAAcAAAADAAkEBAgDAAAABgAAAAkEBAgFAAAABwAAAAMACQQECE0AAAAGAAAA
CQQECAUAAAAHAAAAAwAJBAQIkQAAAAYAAAAJBAQIBQAAAAcAAAADAAkEBAgDAAAABgAAAAkEBAgF
AAAABwAAAAMACQQECC0AAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQPAATw
SAAAABIACvAIAAAAAXgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS
AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoB
TAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAA
AL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA
AADACv////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DSgUAAAIA7wMYAAAA
EAAAAAAAAAAAAAAAAAAAgAAAAAAHAAwwDwAMBGEEAAAPAALwWQQAAMACCPAIAAAABAAAAAS8AAAP
AAPw8QMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAvAAABQAAAA8A
BPAgAQAAogwK8AgAAAACvAAAAAoAAMMAC/BuAAAAfwABAO8BgACYJcEKgQAAAAAAggAAAAAAgwAA
AAAAhAAAAAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAA
bABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQvg+YEaoQDwAN8IIAAAAAAJ8PBAAA
AAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcP
CAAAAAAAAAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAA
ANQB0ALwAxAFDwAE8CwBAACiDArwCAAAAAO8AAAACgAAwwAL8H4AAAB/AAEA7wGAAJT9wAqBAAAA
AACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBT
AGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDw
CAAAAF0QuA6+D6oQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAA
CAAAAAACAAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkE
AQAAAAYAAAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwXQEAABIACvAIAAAABLwAACACAAAT
AQvwfgAAAAQAAAAAAH8AAQDvAYAAMDLBCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcA
AAAAAIgAAAAAAL8ABAAEAP8BAAARAAEDBAQAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBj
AHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAYwSfAPIVqAkPABHwEAAAAAAAwwsIAAAA/////w4A
wQoPAA3wlwAAAAAAnw8EAAAAAQAAAAAAqA8HAAAAQmFja3VwDQAAoQ9EAAAABwAAAAAAAQgKAAgA
AQAHAAEAAAABAAAACgAHAAYAAAABACIAAAAEACQAAQAAAAAAIgAEACQAAQAAAAAEIgAABAQAJAAA
AKoPDAAAAAgAAAAGAAAACQQECAAApg8UAAAA8B4AANQBIAHQAkAC8ANgAxAFgAQPAATwSAAAABIA
CvAIAAAAAbwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI
AAQDCQAAAD8DAQABABAA8AcgAAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgT
kQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAL/6xwHQ
o4XrAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADACv//
//8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfhMAAAIA7wMYAAAAEAAAAAAA
AAAAAAAAAAAAgAsBAAAHAAwwDwAMBJUSAAAPAALwjRIAAPACCPAIAAAAEgAAABLMAAAPAAPwJRIA
AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAzAAABQAAAA8ABPAgAQAA
ogwK8AgAAAACzAAAAAoAAMMAC/BuAAAAfwABAO8BgAAIQcEKgQAAAAAAggAAAAAAgwAAAAAAhAAA
AAAAvwAEAAQAvwEBABEA/wEQABgAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMA
ZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAAAFwQ5Aq+DKoQDwAN8IIAAAAAAJ8PBAAAAAQAAAAA
AKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAACAAAAAQAmAAEAAwAIALKysv4AAPcPCAAAAAAA
AAAAUtgJAACqDxoAAAABAAAABwAAAAAAEQQJBAEAAAAGAAAACQQRBAAApg8MAAAA8AAAANQB0ALw
AxAFDwAE8CwBAACiDArwCAAAAAPMAAAACgAAwwAL8H4AAAB/AAEA7wGAAHBMwQqBAAAAAACCAAAA
AACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwAaQBk
AGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDwCAAAAF0Q
3gnkCqoQDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDx4AAAACAAAAAAAACAAAAAAC
AAAAAQAmAAEAAwAIALKysv4AANgPBAAAAAAAAAAAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYA
AAAJBBEEAACmDwwAAADwAAAA1AHQAvADEAUPAATwMgEAABIACvAIAAAABMwAACACAAATAQvwfgAA
AAQAAAAAAH8AAQDvAYAAFFbBCoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAAAAAIcAAAAAAIgA
AAAAAL8ABAAEAP8BAAARAAEDAwQAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBu
AGcAbABlACAAMgAAAAAAEPAIAAAAywAOAWsVQgIPABHwEAAAAAAAwwsIAAAA/////w0AwQoPAA3w
bAAAAAAAnw8EAAAAAAAAAAAAqA8IAAAATUNFIE1TUnMAAKEPGgAAAAkAAAAAAAAICgABAAcACQAA
AAEAIAAAAAQAAACqDyYAAAAEAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAEAAAAGAAAACQQECA8A
BPD9AAAAogwK8AgAAAAFzAAAAAoAALMAC/BYAAAAfwAAAO8BgABsWsEKvwAGAAYAgQEMpCkAvwEQ
ABAAwAEMpCkAywFwxgAA/wEIABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAA
NgAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAADJB6cERAnQCA8ADfBnAAAAAACfDwQAAAAEAAAAAACo
DwcAAABNQ0dfQ0FQAAChDxwAAAAIAAAAAAAAIAAAMgAIAAAAAAAmAAQAEgAAAAADAACqDwwAAAAI
AAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPD9AAAAogwK8AgAAAAGzAAAAAoAALMA
C/BYAAAAfwAAAO8BgACoZMEKvwAGAAYAgQEMpCkAvwEQABAAwAEMpCkAywFwxgAA/wEIABgAPwMA
AAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwAAABMAIvEGAAAA/wEAAEAAAAAQ8AgA
AAB0CakERgl7Cg8ADfBnAAAAAACfDwQAAAAEAAAAAACoDwcAAABNQ0dfQ1RMAAChDxwAAAAIAAAA
AAAAIAAAMgAIAAAAAAAmAAQAEgAAAAADAACqDwwAAAAIAAAABgAAAAkEBAgAAKYPDAAAAPAAAADU
AdAC8AMQBQ8ABPAAAQAAogwK8AgAAAAHzAAAAAoAALMAC/BYAAAAfwAAAO8BgABEb8EKvwAGAAYA
gQECAAAIvwEQABAAwAECAAAIywFwxgAA/wEIABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAg
AEIAbwB4ACAAOAAAABMAIvEGAAAA/wEAAEAAAAAQ8AgAAAApC60ESgkwDA8ADfBqAAAAAACfDwQA
AAAEAAAAAACoDwoAAABNQ0dfU1RBVFVTAAChDxwAAAALAAAAAAAAIAAAMgALAAAAAAAmAAQAEgAA
AAADAACqDwwAAAALAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPALAQAAogwK8AgA
AAAIzAAAAAoAALMAC/BYAAAAfwAAAO8BgAAkeMEKvwAGAAYAgQEMpCkAvwEQABAAwAEMpCkAywFw
xgAA/wEIABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAOQAAABMAIvEGAAAA
/wEAAEAAAAAQ8AgAAAAcBvYJkw4jBw8ADfB1AAAAAACfDwQAAAAEAAAAAACoDwcAAABNQ2lfQ1RM
AAChDxwAAAAIAAAAAAAAIAAAMgAIAAAAAAAmAAQAEgAAAAADAACqDxoAAAAHAAAABwAAAAMACQQE
CAEAAAAGAAAACQQECAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BABAACiDArwCAAAAAnMAAAACgAA
swAL8FoAAAB/AAAA7wGAABiCwQq/AAYABgCBAQIAAAi/ARAAEADAAQIAAAjLAXDGAAD/AQgAGAA/
AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADAAAAATACLxBgAAAP8BAABAAAAA
EPAIAAAAyQfzCZAO0AgPAA3weAAAAAAAnw8EAAAABAAAAAAAqA8KAAAATUNpX1NUQVRVUwAAoQ8c
AAAACwAAAAAAACAAADIACwAAAAAAJgAEABIAAAAAAwAAqg8aAAAACgAAAAcAAAADAAkEBAgBAAAA
BgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAOAQAAogwK8AgAAAAKzAAAAAoAALMAC/Ba
AAAAfwAAAO8BgAAMjMEKvwAGAAYAgQECAAAIvwEQABAAwAECAAAIywFwxgAA/wEIABgAPwMAAAgA
gMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQAxAAAAEwAi8QYAAAD/AQAAQAAAABDwCAAA
AHQJ9QmSDnsKDwAN8HYAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAE1DaV9BRERSAAChDxwAAAAJAAAA
AAAAIAAAMgAJAAAAAAAmAAQAEgAAAAADAACqDxoAAAAIAAAABwAAAAMACQQECAEAAAAGAAAACQQE
CAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8A4BAACiDArwCAAAAAvMAAAACgAAswAL8FoAAAB/AAAA
7wGAAFCWwQq/AAYABgCBAQIAAAi/ARAAEADAAQIAAAjLAXDGAAD/AQgAGAA/AwAACACAwxgAAAC/
AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADIAAAATACLxBgAAAP8BAABAAAAAEPAIAAAAKQv5CZYO
MAwPAA3wdgAAAAAAnw8EAAAABAAAAAAAqA8IAAAATUNpX01JU0MAAKEPHAAAAAkAAAAAAAAgAAAy
AAkAAAAAACYABAASAAAAAAMAAKoPGgAAAAgAAAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIAACmDwwA
AADwAAAA1AHQAvADEAUPAATwhgAAAEIBCvAIAAAADMwAAAAKAADTAAvwXgAAAH8AAADvAYUAAgAA
AIcAAQAAAL8ABAAEAH8BAAABAL8BAAARAMABAQAACMsBcMYAAM4BBgAAAP8BGAAYAD8DCAAIAIDD
EAAAAL8DAAACAEwAaQBuAGUAIAAxADMAAAAAABDwCAAAABgEqAmoCa4MDwAE8OwAAACiDArwCAAA
AA3MAAAACgAAkwAL8E4AAAB/AAAA7wGAALShwQq/AAYABgC/AQAAEQDLAXDGAAD/AQAAGAA/AwAA
CACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAxADQAAAATACLxBgAAAP8BAABAAAAAEPAI
AAAA/wxbBMwJHw4PAA3wYAAAAAAAnw8EAAAABAAAAAAAqA8GAAAAZ2xvYmFsAAChDxYAAAAHAAAA
AAAAIAAAMgAHAAAAAAAgAAQAAACqDwwAAAAHAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQ
BQ8ABPDuAAAAogwK8AgAAAAOzAAAAAoAAJMAC/BOAAAAfwAAAO8BgADgqsEKvwAGAAYAvwEAABEA
ywFwxgAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQA1AAAAEwAi
8QYAAAD/AQAAQAAAABDwCAAAANwM6Ql7DvwNDwAN8GIAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAHBl
ci1iYW5rAAChDxYAAAAJAAAAAAAAIAAAMgAJAAAAAAAgAAQAAACqDwwAAAAJAAAABgAAAAkEBAgA
AKYPDAAAAPAAAADUAdAC8AMQBQ8ABPADAQAAogwK8AgAAAAPzAAAAAoAALMAC/BaAAAAfwAAAO8B
gABAtsEKvwAGAAYAvwEAABEAwAECAAAIywFwxgAAzgECAAAA/wEIABgAPwMAAAgAgMMYAAAAvwMA
AAIAVABlAHgAdAAgAEIAbwB4ACAAMQA2AAAAEwAi8QYAAAD/AQAAQAAAABDwCAAAAHEE+AmVDngF
DwAN8GsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAE1DaV9DVEwyICoqAAChDxwAAAAMAAAAAAAAIAAA
MgAMAAAAAAAmAAQAEgAAAAADAACqDwwAAAAMAAAABgAAAAkEBAgAAKYPDAAAAPAAAADUAdAC8AMQ
BQ8ABPAHAQAAogwK8AgAAAAQzAAAAAoAAJMAC/BOAAAAfwAAAO8BgABgwMEKvwAGAAYAvwEAABEA
ywFwxgAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQA3AAAAEwAi
8QYAAAD/AQAAQAAAABDwCAAAAOECuQYqDAEEDwAN8HsAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAAHBl
ci1jcHUAAKEPFgAAAAgAAAAAAAAgAAAyAAgAAAAAACAABAAAAKoPJgAAAAQAAAAGAAAACQQECAMA
AAAHAAAAAwAJBAQIAQAAAAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwMQEAAKIMCvAI
AAAAEcwAAAAKAACzAAvwWgAAAH8AAADvAYAA1MrBCr8ABgAGAIEBDKQpAL8BEAAQAMABDKQpAMsB
cMYAAP8BCAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADEAMAAAABMAIvEG
AAAA/wEAAEAAAAAQ8AgAAAAPCNQRXRVPCQ8ADfCZAAAAAACfDwQAAAAEAAAAAACoDxEAAABJbml0
JnByb2JlIE1TUnMgKgAAoQ8cAAAAEgAAAAAAACAAADIAEgAAAAAAJgAEAAwAAAAAAwAAqg80AAAA
CgAAAAcAAAADAAkEBAgBAAAABgAAAAkEBAgEAAAABwAAAAMACQQECAMAAAAGAAAACQQECAAApg8M
AAAA8AAAANQB0ALwAxAFDwAE8CMBAACiDArwCAAAABLMAAAACgAAswAL8FoAAAB/AAAA7wGAAHDV
wQq/AAYABgCBAQIAAAi/ARAAEADAAQIAAAjLAXDGAAD/AQgAGAA/AwAACACAwxgAAAC/AwAAAgBU
AGUAeAB0ACAAQgBvAHgAIAAxADAAAAATACLxBgAAAP8BAABAAAAAEPAIAAAAzwnYEWEVDwsPAA3w
iwAAAAAAnw8EAAAABAAAAAAAqA8RAAAARXJyb3ItaW5mbyBNU1JzICoAAKEPHAAAABIAAAAAAAAg
AAAyABIAAAAAACYABAAMAAAAAAMAAKoPJgAAAAsAAAAGAAAACQQECAQAAAAHAAAAAwAJBAQIAwAA
AAYAAAAJBAQIAACmDwwAAADwAAAA1AHQAvADEAUPAATwSAAAABIACvAIAAAAAcwAAAAMAACDAAvw
MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg
AAAA////AAhgqAD/XEcA9eZHAKbK4QBWfrkADC6GAKoBTAAPAIgTkQAAAA8AihOJAAAAAAC6DxAA
AABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAL/6xwHQo4XrAAAAKwQAAAAAAAAAHwBE
8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADACv////8SAAAADwA98Q0AAABAAULx
BQAAAAEJAAAADwACKwAAAAAPAO4DndwAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAoBAAAHAAww
AAD5AxAAAAAAAAAAAAAAAAIAAQACvU4wDwAMBKzbAAAPAALwpNsAANACCPAIAAAAMgAAADfAAAAP
AAPwPNsAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAwAAABQAAAA8A
BPAwAQAAEgAK8AgAAAACwAAAIAIAABMBC/B2AAAABAAAAAAAfwABAO8BgADA4cEKgQAAAAAAggAA
AAAAgwAAAAAAhAAAAAAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQA/wEQABEAAQMDBAAAPwMAAAgA
gMMQAAAAiAMAAAAAvwMAAAIAVABpAHQAbABlACAAMwAAAAAAEPAIAAAAbAACAV8V+gEPABHwEAAA
AAAAwwsIAAAA/////w0AwQoPAA3wcgAAAAAAnw8EAAAAAAAAAAAAqA8OAAAAWGVuIFJBUyBzdGF0
dXMAAKEPGAAAAA8AAAAAAAAIAAABAA8AAAABACAAAAAEAAAAqg8oAAAAAwAAAAcAAAADAAkEBAgL
AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBA8AA/Bw1wAADwAE8IgAAAABAAnwEAAAANIAAACcAQAA
EhYAACcPAAACAArwCAAAADfAAAABAgAAEwAL8AYAAAB/AAABAAEjACLxOgAAAJ8DAQAAAKDDLgAA
AAoADAAEAO8AAAB7AQAAcAEAAHABAABcAQAATAEAAGYBAABnAQAAZgEAAGYBAAAAABDwCAAAAJwB
0gASFicPDwAE8GIFAAASAArwCAAAAATAAAACCgAAgwAL8DAAAAB/AAAABACAAHTwwQq/AAQABACB
AUWCywCDAQAAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx5QMAAL8BAABgAKmD2QMAAFBLAwQUAAYA
CAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pT
OCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8Ud
KEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyK
tN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7
ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNb
odfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZu
pHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFO
YQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBL
AwQUAAYACAAAACEAieLxydgAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X6D9ZU
6qYqTquKVCkGIfoAITaELtrdEE/iqPE4sg2Ev6/Fol3euaNzdSazwXbiSD60jhU8jDIQxJXTLTcK
Pnfv988gQkTW2DkmBWcKMJteX02w0O7EWzqWsREJwqFABSbGvpAyVIYshpHriVNXO28xpugbqT2e
Etx28jHLxtJiy2nBYE8LQ9VPebAK3r7K/O4jX+j5xnwfxvvdalm/Pil1ezPMX0BEGuL/8zrm5Ub/
lRfUSitIJvXyvPet3mKI5C+XZJosQU5/AQAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAIni
8cnYAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAMAwAAAAAAAA/wEAAAAGQMAABbDAAAEhYAAMENAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAA
ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAA
ug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfCH
AAAAAACfDwQAAAAHAAAAAACoDxsAAABEb20wIGFuZCBoeXBlcnZpc29yIGNvLXdvcmsAAKEPHgAA
ABwAAAAAAAEgAAAIAAAAHAAAAAAAJgAEAA4ABgkO/gAAqg8MAAAAHAAAAAYAAAAJBAQIAACmDxYA
AAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8EoFAAASAArwCAAAAAXAAAACCgAAgwAL8DAAAAB/
AAAABACAANjwwQq/AAQABACBAUWCywCDAQAAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx5QMAAL8B
AABgAKmD2QMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54
bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK
4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OM
KZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQy
J487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJt
pY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8Fq
wzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2
HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF
+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6
dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAtLPQJtgAAAD5AAAADwAAAGRycy9kb3ducmV2
LnhtbESPy27CMBBF90j8gzVI3VTFoaqgTTEI0QdU6obAot0N8SS2iO3INhD+vhaLsrxzR+fqTOed
adiJfNDOChgNM2BkSye1rQXsth8Pz8BCRCuxcZYEXCjAfNbvTTGX7mw3dCpizRLEhhwFqBjbnPNQ
KjIYhq4lm7rKeYMxRV9z6fGc4Kbhj1k25ga1TQsKW1oqKg/F0Qh4/ykm95+TpVx8q9/jeL9dr6q3
JyHuBt3iFVikLt6eg/562RX/5RW1lgKSSbW67L2WGwyR/PWSTJMl8NkfAAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhALSz0CbYAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAMAwAAAAAAAA/wEAAAALAHAABbDAAAZAwAAMENAAAPABHwfgAA
AA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAA
AAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAA
AAAAEAAAAAAAAAAAAA8ADfBvAAAAAACfDwQAAAAHAAAAAACoDwMAAABOL0EAAKEPHgAAAAQAAAAA
AAEgAAAIAAAABAAAAAAAJgAEAA4ABgkO/gAAqg8MAAAABAAAAAYAAAAJBAQIAACmDxYAAAD4HgAA
AADUASAB0AJAAvADYAMQBYAEDwAE8FQFAAASAArwCAAAAAbAAAACCgAAgwAL8DAAAAB/AAAABACA
AFAEwwq/AAQABACBAUWCywCDAQAAAAi/ARgAHwD/AQAACAC/AwAAAgAjACLx5AMAAL8BAABgAKmD
2AMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9O
wzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1W
oIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHN
DgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487Mrog
V1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8A
AAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7
YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwv
x7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773
/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODT
M+MvAAAA//8DAFBLAwQUAAYACAAAACEAt6V+AdcAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESP
y07DMBBF90j8gzVIbBB1ilCLQt2qKo92waYpC9hN4kkcEY8j22nTv8fqApZ37uhcncVqtJ04kg+t
YwXTSQaCuHK65UbB5+Ht/glEiMgaO8ek4EwBVsvrqwXm2p14T8ciNiJBOOSowMTY51KGypDFMHE9
cepq5y3GFH0jtcdTgttOPmTZTFpsOS0Y7GljqPopBqvg9auY373PN3r9Yb6HWXnYbeuXR6Vub8b1
M4hIY/x/xqGcEv2VF9ROK0gm9fZc+lbvMUTyl0syTZYgl78AAAD//wMAUEsBAi0AFAAGAAgAAAAh
ANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAU
AAYACAAAACEAt6V+AdcAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsF
BgAAAAADAAMAtwAAAAsDAAAAAAAAD/AQAAAA0gAAAFsMAACwBwAAwQ0AAA8AEfB+AAAADwCIE3YA
AAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAAB
AA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAA
AAAAAAAADwAN8HoAAAAAAJ8PBAAAAAcAAAAAAKgPDgAAAEFQRUkgSEVTVC9HSEVTAAChDx4AAAAP
AAAAAAABIAAACAAAAA8AAAAAACYABAAOAAYJDv4AAKoPDAAAAA8AAAAGAAAACQQECAAApg8WAAAA
+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPD/BQAAEgAK8AgAAAAHwAAAAgoAAIMAC/AwAAAAfwAA
AAQAgADoE8MKvwAEAAQAgQGWlpYAgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8d8DAACpg9kD
AABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMw
DIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCI
jbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H
0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZ
A/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA
//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2Dv
YHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3
DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e
5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPj
LwAAAP//AwBQSwMEFAAGAAgAAAAhAIni8cnYAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tu
wjAQRfeV+g/WVOqmKk6rilQpBiH6ACE2hC7a3RBP4qjxOLINhL+vxaJd3rmjc3Ums8F24kg+tI4V
PIwyEMSV0y03Cj537/fPIEJE1tg5JgVnCjCbXl9NsNDuxFs6lrERCcKhQAUmxr6QMlSGLIaR64lT
VztvMaboG6k9nhLcdvIxy8bSYstpwWBPC0PVT3mwCt6+yvzuI1/o+cZ8H8b73WpZvz4pdXszzF9A
RBri//M65uVG/5UX1EorSCb18rz3rd5iiOQvl2SaLEFOfwEAAP//AwBQSwECLQAUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA
BgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQA
BgAIAAAAIQCJ4vHJ2AAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUG
AAAAAAMAAwC3AAAADAMAAAAAAAAP8BAAAABkDAAAwQ0AABIWAAAnDwAADwAR8H4AAAAPAIgTdgAA
AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEA
DwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAA
AAAAAAAPAA3wKgEAAAAAnw8EAAAABwAAAAAAqA9IAAAAbWNlbG9nLCBjcHUgb25saW5lL29mZmxp
bmUgZG9uZTsgICAgICAgY3B1IGhvdGFkZCwgbWVtb3J5IGhvdGFkZCBvbmdvaW5nAAChDx4AAABJ
AAAAAAABIAAACAAAAEkAAAAAACYABAAOAAYJDv4AAKoPggAAAAYAAAAHAAAAAwAJBAQIAgAAAAYA
AAAJBAQIAwAAAAcAAAADAAkEBAgcAAAABgAAAAkEBAgDAAAABwAAAAMACQQECAEAAAAGAAAACQQE
CAYAAAAHAAAAAwAJBAQICQAAAAYAAAAJBAQIBgAAAAcAAAADAAkEBAgJAAAABgAAAAkEBAgAAKYP
FgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwRAUAABIACvAIAAAACMAAAAIKAACDAAvwMAAA
AH8AAAAEAIAAMA7DCr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHfAwAA
qYPZAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQ
z07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdw
XVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQ
Ac0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsy
uiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09s
vwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG
4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4t
XC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcT
vvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA4
4NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC0s9Am2AAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1s
RI/LbsIwEEX3SPyDNUjdVMWhqqBNMQjRB1TqhsCi3Q3xJLaI7cg2EP6+FouyvHNH5+pM551p2Il8
0M4KGA0zYGRLJ7WtBey2Hw/PwEJEK7FxlgRcKMB81u9NMZfubDd0KmLNEsSGHAWoGNuc81AqMhiG
riWbusp5gzFFX3Pp8ZzgpuGPWTbmBrVNCwpbWioqD8XRCHj/KSb3n5OlXHyr3+N4v12vqrcnIe4G
3eIVWKQu3p6D/nrZFf/lFbWWApJJtbrsvZYbDJH89ZJMkyXw2R8AAAD//wMAUEsBAi0AFAAGAAgA
AAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC
LQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwEC
LQAUAAYACAAAACEAtLPQJtgAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1s
UEsFBgAAAAADAAMAtwAAAAwDAAAAAAAAD/AQAAAAsAcAAMENAABkDAAAJw8AAA8AEfB+AAAADwCI
E3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgAAAAAAAAD
AAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQ
AAAAAAAAAAAADwAN8G8AAAAAAJ8PBAAAAAcAAAAAAKgPAwAAAFdJUAAAoQ8eAAAABAAAAAAAASAA
AAgAAAAEAAAAAAAmAAQADgAGCQ7+AACqDwwAAAAEAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQB
IAHQAkAC8ANgAxAFgAQPAATwcAUAABIACvAIAAAACcAAAAIKAACDAAvwMAAAAH8AAAAEAIAA6CfD
Cr8ABAAEAIEBlpaWAIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQC3pX4B1wAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LTsMwEEX3SPyD
NUhsEHWKUItC3aoqj3bBpikL2E3iSRwRjyPbadO/x+oClnfu6FydxWq0nTiSD61jBdNJBoK4crrl
RsHn4e3+CUSIyBo7x6TgTAFWy+urBebanXhPxyI2IkE45KjAxNjnUobKkMUwcT1x6mrnLcYUfSO1
x1OC204+ZNlMWmw5LRjsaWOo+ikGq+D1q5jfvc83ev1hvodZedht65dHpW5vxvUziEhj/H/GoZwS
/ZUX1E4rSCb19lz6Vu8xRPKXSzJNliCXvwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC3
pX4B1wAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAACwMAAAAAAAAP8BAAAADSAAAAwQ0AALAHAAAnDwAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAA
AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAA
ALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3w
nAAAAAAAnw8EAAAABwAAAAAAqA8WAAAARG9tMCBYZW4gUkFTIGludGVyZmFjZQAAoQ8eAAAAFwAA
AAAAASAAAAgAAAAXAAAAAAAmAAQADgAGCQ7+AACqDyYAAAAFAAAABgAAAAkEBAgDAAAABwAAAAMA
CQQECA8AAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBiBQAAEgAK
8AgAAAAKwAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAEM8MKvwAEAAQAgQFFgssAgwEAAAAIvwEYAB8A
/wEAAAgAvwMAAAIAIwAi8eUDAAC/AQAAYACpg9kDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6
URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0E
EpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJN
AurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/
cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6
aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpW
C0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNC
nqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAIni8cnY
AAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfeV+g/WVOqmKk6rilQpBiH6ACE2hC7a
3RBP4qjxOLINhL+vxaJd3rmjc3Ums8F24kg+tI4VPIwyEMSV0y03Cj537/fPIEJE1tg5JgVnCjCb
Xl9NsNDuxFs6lrERCcKhQAUmxr6QMlSGLIaR64lTVztvMaboG6k9nhLcdvIxy8bSYstpwWBPC0PV
T3mwCt6+yvzuI1/o+cZ8H8b73WpZvz4pdXszzF9ARBri//M65uVG/5UX1EorSCb18rz3rd5iiOQv
l2SaLEFOfwEAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAA
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAA
AAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCJ4vHJ2AAAAPkAAAAPAAAAAAAA
AAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADAMAAAAAAAAP8BAAAABk
DAAAjgkAABIWAAD0CgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAA
VAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABU
ADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3whwAAAAAAnw8EAAAABwAAAAAA
qA8bAAAARG9tMCBhbmQgaHlwZXJ2aXNvciBjby13b3JrAAChDx4AAAAcAAAAAAABIAAACAAAABwA
AAAAACYABAAOAAYJDv4AAKoPDAAAABwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALw
A2ADEAWABA8ABPBQBQAAEgAK8AgAAAALwAAAAgoAAIMAC/AwAAAAfwAAAAQAgACkPcMKvwAEAAQA
gQFFgssAgwEAAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eUDAAC/AQAAYACpg9kDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhALSz0CbYAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfdI/IM1
SN1UxaGqoE0xCNEHVOqGwKLdDfEktojtyDYQ/r4Wi7K8c0fn6kznnWnYiXzQzgoYDTNgZEsnta0F
7LYfD8/AQkQrsXGWBFwowHzW700xl+5sN3QqYs0SxIYcBagY25zzUCoyGIauJZu6ynmDMUVfc+nx
nOCm4Y9ZNuYGtU0LCltaKioPxdEIeP8pJvefk6VcfKvf43i/Xa+qtych7gbd4hVYpC7enoP+etkV
/+UVtZYCkkm1uuy9lhsMkfz1kkyTJfDZHwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACF
AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa
9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC0
s9Am2AAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3
AAAADAMAAAAAAAAP8BAAAACwBwAAjgkAAGQMAAD0CgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAA
AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAA
ALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3w
dQAAAAAAnw8EAAAABwAAAAAAqA8JAAAAc3VwcG9ydGVkAAChDx4AAAAKAAAAAAABIAAACAAAAAoA
AAAAACYABAAOAAYJDv4AAKoPDAAAAAoAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALw
A2ADEAWABA8ABPBPBQAAEgAK8AgAAAAMwAAAAgoAAIMAC/AwAAAAfwAAAAQAgACkR8MKvwAEAAQA
gQFFgssAgwEAAAAIvwEYAB8A/wEAAAgAvwMAAAIAIwAi8eQDAAC/AQAAYACpg9gDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhALelfgHXAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tOwzAQRfdI/IM1
SGwQdYpQi0LdqiqPdsGmKQvYTeJJHBGPI9tp07/H6gKWd+7oXJ3FarSdOJIPrWMF00kGgrhyuuVG
wefh7f4JRIjIGjvHpOBMAVbL66sF5tqdeE/HIjYiQTjkqMDE2OdShsqQxTBxPXHqauctxhR9I7XH
U4LbTj5k2UxabDktGOxpY6j6KQar4PWrmN+9zzd6/WG+h1l52G3rl0elbm/G9TOISGP8f8ahnBL9
lRfUTitIJvX2XPpW7zFE8pdLMk2WIJe/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALel
fgHXAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAALAwAAAAAAAA/wEAAAANIAAACOCQAAsAcAAPQKAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAA
ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAA
ug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfB1
AAAAAACfDwQAAAAHAAAAAACoDwkAAABBUEVJIEVSU1QAAKEPHgAAAAoAAAAAAAEgAAAIAAAACgAA
AAAAJgAEAA4ABgkO/gAAqg8MAAAACgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvAD
YAMQBYAEDwAE8EkFAAASAArwCAAAAA3AAAACCgAAgwAL8DAAAAB/AAAABACAACBKwwq/AAQABACB
AUWCywCDAQAAAAi/ARAAFAD/AQAACAC/AwAAAgATACLx3wMAAKmD2QMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEAieLxydgAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X6D9ZU6qYqTquK
VCkGIfoAITaELtrdEE/iqPE4sg2Ev6/Fol3euaNzdSazwXbiSD60jhU8jDIQxJXTLTcKPnfv988g
QkTW2DkmBWcKMJteX02w0O7EWzqWsREJwqFABSbGvpAyVIYshpHriVNXO28xpugbqT2eEtx28jHL
xtJiy2nBYE8LQ9VPebAK3r7K/O4jX+j5xnwfxvvdalm/Pil1ezPMX0BEGuL/8zrm5Ub/lRfUSitI
JvXyvPet3mKI5C+XZJosQU5/AQAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAA
AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAIni8cnYAAAA
+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAMAwAA
AAAAAA/wEAAAAGQMAAD0CgAAEhYAAFsMAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAA
AF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAA
XwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfB0AAAAAACf
DwQAAAAHAAAAAACoDwgAAABEb20wIG93bgAAoQ8eAAAACQAAAAAAASAAAAgAAAAJAAAAAAAmAAQA
DgAGCQ7+AACqDwwAAAAJAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQP
AATwSgUAABIACvAIAAAADsAAAAIKAACDAAvwMAAAAH8AAAAEAIAArFvDCr8ABAAEAIEBRYLLAIMB
AAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHfAwAAqYPZAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAA
AIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7AS
t43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3l
Rb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31u
n0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhra
RtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/
AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy
9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6x
qGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w8
1c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC0
s9Am2AAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3SPyDNUjdVMWhqqBNMQjRB1Tq
hsCi3Q3xJLaI7cg2EP6+FouyvHNH5+pM551p2Il80M4KGA0zYGRLJ7WtBey2Hw/PwEJEK7FxlgRc
KMB81u9NMZfubDd0KmLNEsSGHAWoGNuc81AqMhiGriWbusp5gzFFX3Pp8ZzgpuGPWTbmBrVNCwpb
WioqD8XRCHj/KSb3n5OlXHyr3+N4v12vqrcnIe4G3eIVWKQu3p6D/nrZFf/lFbWWApJJtbrsvZYb
DJH89ZJMkyXw2R8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAtLPQJtgAAAD5AAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAwDAAAAAAAAD/AQ
AAAAsAcAAPQKAABkDAAAWwwAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8A
UABQAFQAMQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQ
AFAAVAA5AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8HUAAAAAAJ8PBAAAAAcA
AAAAAKgPCQAAAHN1cHBvcnRlZAAAoQ8eAAAACgAAAAAAASAAAAgAAAAKAAAAAAAmAAQADgAGCQ7+
AACqDwwAAAAKAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwSQUA
ABIACvAIAAAAD8AAAAIKAACDAAvwMAAAAH8AAAAEAIAA7GbDCr8ABAAEAIEBRYLLAIMBAAAACL8B
EAAUAP8BAAAIAL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC3pX4B1wAA
APkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LTsMwEEX3SPyDNUhsEHWKUItC3aoqj3bBpikL2E3i
SRwRjyPbadO/x+oClnfu6FydxWq0nTiSD61jBdNJBoK4crrlRsHn4e3+CUSIyBo7x6TgTAFWy+ur
BebanXhPxyI2IkE45KjAxNjnUobKkMUwcT1x6mrnLcYUfSO1x1OC204+ZNlMWmw5LRjsaWOo+ikG
q+D1q5jfvc83ev1hvodZedht65dHpW5vxvUziEhj/H/GoZwS/ZUX1E4rSCb19lz6Vu8xRPKXSzJN
liCXvwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAA
AAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQC3pX4B1wAAAPkAAAAPAAAAAAAAAAAA
AAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAADSAAAA
9AoAALAHAABbDAAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx
ADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkA
AACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wdQAAAAAAnw8EAAAABwAAAAAAqA8J
AAAAQVBFSSBFSU5KAAChDx4AAAAKAAAAAAABIAAACAAAAAoAAAAAACYABAAOAAYJDv4AAKoPDAAA
AAoAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBRBQAAEgAK8AgA
AAAQwAAAAgoAAIMAC/AwAAAAfwAAAAQAgABQZ8MKvwAEAAQAgQGvk/UAgwEAAAAIvwEQABQA/wEA
AAgAvwMAAAIAEwAi8d0DAACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29u
dGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg
4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7
rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQ
JmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL
4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9y
ZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPh
J61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJ
aceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+
09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAOutUfjWAAAA+QAAAA8A
AABkcnMvZG93bnJldi54bWxEj0FPwkAQhe8k/ofNmHghshWCkMJCDI2R4AnQ4HHoDm2xO9vsrrT8
ezcc9PjmTb6Xb77sTC0u5HxlWcHTIAFBnFtdcaHgY//6OAXhA7LG2jIpuJKH5eKuN8dU25a3dNmF
QkQI+xQVlCE0qZQ+L8mgH9iGOHYn6wyGGF0htcM2wk0th0nyLA1WHBdKbGhVUv69+zEKbL1vs8nG
9acTPTSHryw7H9qzUg/33csMRKAu/D+/jz7HK/4rb6i1VhBNTm/Xo6v0Fn0gd7tE02gJcvELAAD/
/wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50
X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAA
X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA661R+NYAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAA
ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQAAAA0gAAAJwBAACwBwAA
iwIAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQ
AAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAA
AACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8H4AAAAAAJ8PBAAAAAcAAAAAAKgPBAAAAEl0ZW0A
AKEPHgAAAAUAAAAAAAEgAAAIAAAABQAAAAEAJAAAAAQA/////gAAqg8aAAAABAAAAAYAAAAJBAQI
AQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwUwUAABIACvAI
AAAAEcAAAAIKAACDAAvwMAAAAH8AAAAEAIAABHvDCr8ABAAEAIEBr5P1AIMBAAAACL8BEAAUAP8B
AAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0Nv
bnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4
IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmF
e63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrA
ECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5
S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABf
cmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD
4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1C
yWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3
PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAYpfi91gAAAPkAAAAP
AAAAZHJzL2Rvd25yZXYueG1sRI9Ba8JAEIXvQv/DMoVepG70UCW6ihhKi6dqCnocs2MSzc6G3a2J
/76Lh/b45g3f41usetOIGzlfW1YwHiUgiAuray4VfOfvrzMQPiBrbCyTgjt5WC2fBgtMte14R7d9
KEWEsE9RQRVCm0rpi4oM+pFtiWN3ts5giNGVUjvsItw0cpIkb9JgzXGhwpY2FRXX/Y9RYJu8y6Zb
N5xN9cQcjll2OXQXpV6e+/UcRKA+/D9f19v8+PVXPlCfWkE0OX/cT67WO/SB3OMSTaMlyOUvAAAA
//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu
dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEA
AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhABil+L3WAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIA
AGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/wEAAAALAHAACcAQAAZAwA
AIsCAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT
EAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAA
AAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfCAAAAAAACfDwQAAAAHAAAAAACoDwYAAABTdGF0
dXMAAKEPHgAAAAcAAAAAAAEgAAAIAAAABwAAAAEAJAAAAAQA/////gAAqg8aAAAABgAAAAYAAAAJ
BAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwVgUAABIA
CvAIAAAAEsAAAAIKAACDAAvwMAAAAH8AAAAEAIAAoIfDCr8ABAAEAIEBr5P1AIMBAAAACL8BEAAU
AP8BAAAIAL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAA
W0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2
pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywN
jCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4
shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/
yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4
P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUT
Uf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9T
MfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBYFYo/1wAAAPkA
AAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Na8JAEIbvBf/DMoVepG4qRSV1ldJQKvbkB9jeptkxiWZn
w+7WxH/v4kGP77zD8/JM552pxYmcrywreBkkIIhzqysuFGw3n88TED4ga6wtk4IzeZjPeg9TTLVt
eUWndShEhLBPUUEZQpNK6fOSDPqBbYhjt7fOYIjRFVI7bCPc1HKYJCNpsOK4UGJDHyXlx/W/UWDr
TZuNl64/Geuh2f1k2WHXHpR6euze30AE6sL9+fv1tz9a3MoraqEVRJP91/nPVXqFPpC7XqJptAQ5
uwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv
bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAA
AB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBYFYo/1wAAAPkAAAAPAAAAAAAAAAAAAAAA
AAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAABkDAAAnAEA
ABIWAACLAgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA
AACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACL
ExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wggAAAAAAnw8EAAAABwAAAAAAqA8IAAAA
Q29tbWVudHMAAKEPHgAAAAkAAAAAAAEgAAAIAAAACQAAAAEAJAAAAAQA/////gAAqg8aAAAACAAA
AAYAAAAJBAQIAQAAAAcAAAAAAAQICQQAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATw
TAUAABIACvAIAAAAE8AAAAIKAACDAAvwMAAAAH8AAAAEAIAAVIDDCr8ABAAEAIEBBAAACIMBAAAA
CL8BEAAUAP8BAAAIAL8DAAACABMAIvHcAwAAqYPWAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43W
OlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09
BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wi
TQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHW
f3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAA
FQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1n
emrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlK
VgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5z
Qp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQA2EFtH
1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Ba8JAEIXvhf6HZQq91Y21lRJdpSilCiokLT2P
2TEJZmfD7tYk/76Lh3p884bv8c2XvWnEhZyvLSsYjxIQxIXVNZcKvr8+nt5A+ICssbFMCgbysFzc
380x1bbjjC55KEWEsE9RQRVCm0rpi4oM+pFtiWN3ss5giNGVUjvsItw08jlJptJgzXGhwpZWFRXn
/Nco6LOfycTuXwiHboOv6/X2cDxslXp86N9nIAL14fZ8zovdbvVfXlEbrSCanD6Ho6t1hj6Qu16i
abQEufgDAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAA
AAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEANhBbR9UAAAD5AAAADwAAAAAAAAAA
AAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAkDAAAAAAAAD/AQAAAA0gAA
AIsCAACwBwAABgQAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQA
MQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5
AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8HoAAAAAAJ8PBAAAAAcAAAAAAKgP
EgAAAE1DQSBpbmZyYXN0cnVjdHVyZQAAoQ8aAAAAEwAAAAAAASAAAAgAAAATAAAAAAAiAAQADgAA
AKoPDAAAABMAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBCBQAA
EgAK8AgAAAAUwAAAAgoAAIMAC/AwAAAAfwAAAAQAgAA8ksMKvwAEAAQAgQEEAAAIgwEAAAAIvwEQ
ABQA/wEAAAgAvwMAAAIAEwAi8dsDAACpg9UDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMA
AABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK
9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXT
LA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurh
tLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl
/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAA
CwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseO
kvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut
5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo
/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAMOAXfTUAAAA
+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAQhe8F/8MyQm9109qWEl1FlKIeKiQtnsfsmIRm
d8PuaJJ/38VDPb55w/f45sveNOJKPtTOKnieJCDIFk7XtlTw8/359AEiMFqNjbOkYKAAy8XoYY6p
dp3N6JpzKSLEhhQVVMxtKmUoKjIYJq4lG7uz8wY5Rl9K7bGLcNPIlyR5lwZrGxcqbGldUfGbX4yC
PjtOp+7rlXDodvi22ewPp8Neqcdxv5qBYOr5/pwNF97m/+UNtdMKosl5O5x8rTMMTP52iabREuTi
DwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29u
dGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAA
HwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAMOAXfTUAAAA+QAAAA8AAAAAAAAAAAAAAAAA
BwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAIAwAAAAAAAA/wEAAAALAHAACLAgAA
ZAwAAAYEAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA
AIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsT
GAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfBxAAAAAACfDwQAAAAHAAAAAACoDwkAAABz
dXBwb3J0ZWQAAKEPGgAAAAoAAAAAAAEgAAAIAAAACgAAAAAAIgAEAA4AAACqDwwAAAAKAAAABgAA
AAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwVgUAABIACvAIAAAAFcAAAAIK
AACDAAvwMAAAAH8AAAAEAIAA3KTDCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAIAL8DAAAC
ABMAIvHcAwAAqYPWAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv
9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q
50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9
QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhd
jr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVs
c2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnC
ruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ
1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB
9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQBdhdh11QAAAPkAAAAPAAAAZHJzL2Rv
d25yZXYueG1sRI9Ba8JAEIXvhf6HZYTe6sbalhpdpVRKzUEhtojHMTsmodnZsLs1yb/v4sXjmzd8
j2+x6k0jLuR8bVnBZJyAIC6srrlU8PP9+fgGwgdkjY1lUjCQh9Xy/m6BqbYd53TZh1JECPsUFVQh
tKmUvqjIoB/bljh2Z+sMhhhdKbXDLsJNI5+S5FUarDkuVNjSR0XF7/7PKOjzw3Rqt8+EQ7fBl/U6
2512mVIPo/59DiJQH27Ps6w7DrfyitpoBdHk/DWcXK1z9IHc9RJNoyXI5T8AAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEAXYXYddUAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAkDAAAAAAAAD/AQAAAAZAwAAIsCAAASFgAABgQAAA8AEfB+
AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgA
AAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAA
AAAAAAAQAAAAAAAAAAAADwAN8IQAAAAAAJ8PBAAAAAcAAAAAAKgPHAAAAE1vdmUgZnJvbSBkb20w
IHRvIGh5cGVydmlzb3IAAKEPGgAAAB0AAAAAAAEgAAAIAAAAHQAAAAAAIgAEAA4AAACqDwwAAAAd
AAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwRwUAABIACvAIAAAA
FsAAAAIKAACDAAvwMAAAAH8AAAAEAIAAUJ7DCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAI
AL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODo
Pz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63F
jDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZn
MGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H7
3hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVs
cy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4Set
ZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnH
hXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPW
FCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCOBAr+1wAAAPkAAAAPAAAA
ZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfoP1iB1UxWnVQVVwCBEH2TBhtAF7IZ4EkeN7ch2IPl7
LBZ0eeeOztWZL3vdsDM5X1sj4HWcACNTWFmbSsDv/vvlA5gPaCQ21pCAgTwsF48Pc0ylvZgdnfNQ
sQgxPkUBKoQ25dwXijT6sW3JxK60TmOI0VVcOrxEuG74W5JMuMbaxAWFLa0VFX95pwV8HfLp8890
LVdbdewmp322KT/fhXga9asZsEB9+H8eeJfx8l7eUJkUEE3KzXBytdyhD+Rul2gaLYEvrgAAAP//
AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABf
cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCOBAr+1wAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABk
cnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAADSAAAABgQAALAHAAB2
BQAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAA
AAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAA
AKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wcwAAAAAAnw8EAAAABwAAAAAAqA8LAAAAQ0UgYW5k
IFVDTkEAAKEPGgAAAAwAAAAAAAEgAAAIAAAADAAAAAAAIgAEAA4AAACqDwwAAAAMAAAABgAAAAkE
BAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwRgUAABIACvAIAAAAF8AAAAIKAACD
AAvwMAAAAH8AAAAEAIAAQLrDCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMA
IvHfAwAAqYPZAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOk
ForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv
44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnO
hDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R
8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zP
wWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvB
UPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbK
jMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U
2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQC0s9Am2AAAAPkAAAAPAAAAZHJzL2Rvd25y
ZXYueG1sRI/LbsIwEEX3SPyDNUjdVMWhqqBNMQjRB1TqhsCi3Q3xJLaI7cg2EP6+FouyvHNH5+pM
551p2Il80M4KGA0zYGRLJ7WtBey2Hw/PwEJEK7FxlgRcKMB81u9NMZfubDd0KmLNEsSGHAWoGNuc
81AqMhiGriWbusp5gzFFX3Pp8ZzgpuGPWTbmBrVNCwpbWioqD8XRCHj/KSb3n5OlXHyr3+N4v12v
qrcnIe4G3eIVWKQu3p6D/nrZFf/lFbWWApJJtbrsvZYbDJH89ZJMkyXw2R8AAAD//wMAUEsBAi0A
FAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54
bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJl
bHNQSwECLQAUAAYACAAAACEAtLPQJtgAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25y
ZXYueG1sUEsFBgAAAAADAAMAtwAAAAwDAAAAAAAAD/AQAAAAsAcAAAYEAABkDAAAdgUAAA8AEfB+
AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACxDwgA
AAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAAAAAA
AAAAAAAQAAAAAAAAAAAADwAN8HEAAAAAAJ8PBAAAAAcAAAAAAKgPCQAAAHN1cHBvcnRlZAAAoQ8a
AAAACgAAAAAAASAAAAgAAAAKAAAAAAAiAAQADgAAAKoPDAAAAAoAAAAGAAAACQQECAAApg8WAAAA
+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBuBQAAEgAK8AgAAAAYwAAAAgoAAIMAC/AwAAAAfwAA
AAQAgADoxMMKvwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8d4DAACpg9gD
AABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMw
DIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCI
jbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H
0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZ
A/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA
//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2Dv
YHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3
DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e
5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPj
LwAAAP//AwBQSwMEFAAGAAgAAAAhAFletlrXAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEjzFv
wjAQhfdK/Q/WVepSFYeqApRiEEpbYGAhdCjbEV/iiNiObAPm39diKOO7d/qevuk86o6dyfnWGgHD
QQaMTGVlaxoBP7vv1wkwH9BI7KwhAVfyMJ89Pkwxl/ZitnQuQ8MSxPgcBagQ+pxzXynS6Ae2J5O6
2jqNIUXXcOnwkuC6429ZNuIaW5MWFPZUKKqO5UkL+Potxy/LcSEXG7U/jQ679ar+fBfi+SkuPoAF
iuH+vIxFtY//5Q21lgKSSb26Hlwrt+gDudslmSZL4LM/AAAA//8DAFBLAQItABQABgAIAAAAIQDb
4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG
AAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG
AAgAAAAhAFletlrXAAAA+QAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYA
AAAAAwADALcAAAALAwAAAAAAAA/wEAAAAGQMAAAGBAAAEhYAAHYFAAAPABHwfgAAAA8AiBN2AAAA
DwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAP
AIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAA
AAAAAA8ADfCaAAAAAACfDwQAAAAHAAAAAACoDyQAAABVc2Vyc3BhY2UgdG9vbHMgbG9nZ2luZyBh
bmQgYW5hbHlzaXMAAKEPGgAAACUAAAAAAAEgAAAIAAAAJQAAAAAAIgAEAA4AAACqDxoAAAAJAAAA
BwAAAAMACQQECBwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBi
BQAAEgAK8AgAAAAZwAAAAgoAAIMAC/AwAAAAfwAAAAQAgADsz8MKvwAEAAQAgQEEAAAIgwEAAAAI
vwEQABQA/wEAAAgAvwMAAAIAEwAi8d0DAACpg9cDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEA
ABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6
URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0E
EpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJN
AurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/
cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAV
AQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6
aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpW
C0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNC
nqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAHym03fW
AAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FLAzEQhe+C/yGM4M1mta3I2rSIRdoeLGwtBW/T
zXR3cTNZk9jN/ntDD3p884bv8c0W0bTiTM43lhXcjzIQxKXVDVcK9h9vd08gfEDW2FomBQN5WMyv
r2aYa9tzQeddqESCsM9RQR1Cl0vpy5oM+pHtiFN3ss5gSNFVUjvsE9y08iHLHqXBhtNCjR291lR+
7X6MglgcxmP7PiEc+jVOl8vN9rjdKHV7E1+eQQSK4f95NZ3E78+/8oJaawXJ5LQajq7RBfpA7nJJ
pskS5PwXAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAA
AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAA
AAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAfKbTd9YAAAD5AAAADwAAAAAAAAAA
AAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAoDAAAAAAAAD/AQAAAA0gAA
AHYFAACwBwAA5gYAAA8AEfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQA
MQAwAAAAixMQAAAAAACxDwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5
AAAAixMYAAAAAACsDxAAAAAAAAAAAAAQAAAAAAAAAAAADwAN8I8AAAAAAJ8PBAAAAAcAAAAAAKgP
FQAAAFVuY29yZSBlcnJvciByZWNvdmVyeQAAoQ8eAAAAFgAAAAAAASAAAAgAAAAWAAAAAAAmAAQA
DgAIYKj+AACqDxoAAAAGAAAABwAAAAMACQQECBAAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEg
AdACQALwA2ADEAWABA8ABPBHBQAAEgAK8AgAAAAawAAAAgoAAIMAC/AwAAAAfwAAAAQAgACM2sMK
vwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8dwDAACpg9YDAABQSwMEFAAG
AAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5Ctq
UzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/F
HShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50Sc
irTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cc
e8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQU
AAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojT
W6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwW
bqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BB
TmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQ
SwMEFAAGAAgAAAAhAKzsYVrVAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAQhe8F/8My
hd7qprWVkrqKVEr10EBUep5kxyQ0Oxt2V5P8+y4e6vHNG77Ht1gNphUXcr6xrOBpmoAgLq1uuFJw
PHw+voHwAVlja5kUjORhtZzcLTDVtuecLvtQiQhhn6KCOoQuldKXNRn0U9sRx+5kncEQo6ukdthH
uGnlc5LMpcGG40KNHX3UVP7uz0bBkP/MZvb7hXDst/i62eyyItsp9XA/rN9BBBrC7fmYFV17/i+v
qK1WEE1OX2PhGp2jD+Sul2gaLUEu/wAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9Cxb
vwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCs7GFa
1QAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAA
CQMAAAAAAAAP8BAAAACwBwAAdgUAAGQMAADmBgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6
DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoP
DgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wdQAA
AAAAnw8EAAAABwAAAAAAqA8JAAAAc3VwcG9ydGVkAAChDx4AAAAKAAAAAAABIAAACAAAAAoAAAAA
ACYABAAOAAhgqP4AAKoPDAAAAAoAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2AD
EAWABA8ABPBxBQAAEgAK8AgAAAAbwAAAAgoAAIMAC/AwAAAAfwAAAAQAgADI5MMKvwAEAAQAgQEE
AAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIAEwAi8dwDAACpg9YDAABQSwMEFAAGAAgAAAAhANvh
9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEI
CI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TA
gQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMeP
KanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWY
nnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEA
WvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXE
LLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOt
rraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMf
O0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgA
AAAhAGHS2SDVAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj0FPAjEQhe8k/odmTLxBV1EwK4UY
CREOkiwSz0M77G7cTjdtZXf/vQ0HPb55k+/lW6x624gL+VA7VnA/yUAQa2dqLhUcPzfjZxAhIhts
HJOCgQKsljejBebGdVzQ5RBLkSAcclRQxdjmUgZdkcUwcS1x6s7OW4wp+lIaj12C20Y+ZNlMWqw5
LVTY0ltF+vvwYxX0xdd06j4eCYdui0/r9W5/2u+UurvtX19AROrj//NGH7O5/iuvqK1RkEzO78PJ
16bAEMlfL8k0WYJc/gIAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAA
AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAAL
AAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBh0tkg1QAAAPkAAAAP
AAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACQMAAAAAAAAP
8BAAAABkDAAAdgUAABIWAADmBgAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8A
XwBQAFAAVAAxADAAAACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBf
AFAAUABUADkAAACLExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wnwAAAAAAnw8EAAAA
BwAAAAAAqA8zAAAATWVtb3J5IHNjcnViYmluZyBlcnJvcg1MMyBleHBsaWNpdCB3cml0ZS1iYWNr
IGVycm9yAAChDx4AAAA0AAAAAAABIAAACAAAADQAAAAAACYABAAOAAhgqP4AAKoPDAAAADQAAAAG
AAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBUBQAAEgAK8AgAAAAcwAAA
AgoAAIMAC/AwAAAAfwAAAAQAgAB878MKvwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMA
AAIAEwAi8d8DAACpg9kDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAGd5WHvYAAAA+QAAAA8AAABkcnMv
ZG93bnJldi54bWxEj8tuwjAQRfeV+g/WVOqmKk6rCqoUgxB9wIINgUW7G+JJnDYeR7YJ4e9rsWiX
d+7oXJ3pfLCt6MmHxrGCh1EGgrh0uuFawX73fv8MIkRkja1jUnCmAPPZ9dUUc+1OvKW+iLVIEA45
KjAxdrmUoTRkMYxcR5y6ynmLMUVfS+3xlOC2lY9ZNpYWG04LBjtaGip/iqNV8PZZTO4+Jku92Jiv
4/iwW6+q1yelbm+GxQuISEP8f/Zy/933f+UFtdYKkkm1Oh98o7cYIvnLJZkmS5CzXwAAAP//AwBQ
SwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw
ZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVs
cy8ucmVsc1BLAQItABQABgAIAAAAIQBneVh72AAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMv
ZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAADAMAAAAAAAAP8BAAAADSAAAA5gYAALAHAABCCAAA
DwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA
ALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwP
EAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wfwAAAAAAnw8EAAAABwAAAAAAqA8TAAAAQ29yZSBlcnJv
ciByZWNvdmVyeQAAoQ8eAAAAFAAAAAAAASAAAAgAAAAUAAAAAAAmAAQADgAIYKj+AACqDwwAAAAU
AAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAFgAQPAATwSQUAABIACvAIAAAA
HcAAAAIKAACDAAvwMAAAAH8AAAAEAIAAHPrDCr8ABAAEAIEBBAAACIMBAAAACL8BEAAUAP8BAAAI
AL8DAAACABMAIvHeAwAAqYPYAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODo
Pz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63F
jDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZn
MGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H7
3hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVs
cy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4Set
ZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnH
hXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPW
FCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQAo5sMa1wAAAPkAAAAPAAAA
ZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfoP1iB1UxWnVQUoYBCij7Bgk9BFuxviSRw1tiPbgeTv
a7Eoyzt3dK7OajPolp3J+cYaAc/TBBiZ0srG1AK+jh9PC2A+oJHYWkMCRvKwWd/frTCV9mJyOheh
ZhFifIoCVAhdyrkvFWn0U9uRiV1lncYQo6u5dHiJcN3ylySZcY2NiQsKO9opKn+LXgt4/y7mj5/z
ndwe1E8/Ox33WfX2KsTDZNgugQUawu05H/uQFf/lFbWXAqJJlY0n18gcfSB3vUTTaAl8/QcAAP//
AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf
VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABf
cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAo5sMa1wAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABk
cnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACwMAAAAAAAAP8BAAAACwBwAA5gYAAGQMAABC
CAAADwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAA
AAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAA
AKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wdQAAAAAAnw8EAAAABwAAAAAAqA8JAAAAc3VwcG9y
dGVkAAChDx4AAAAKAAAAAAABIAAACAAAAAoAAAAAACYABAAOAAhgqP4AAKoPDAAAAAoAAAAGAAAA
CQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBpBQAAEgAK8AgAAAAewAAAAgoA
AIMAC/AwAAAAfwAAAAQAgABQBMgKvwAEAAQAgQEEAAAIgwEAAAAIvwEQABQA/wEAAAgAvwMAAAIA
EwAi8eADAACpg9oDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBl
c10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/2
86QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDn
Se/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1B
Kc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2O
vdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxz
bM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu
68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnV
VsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H0
3hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAJa9Qg7ZAAAA+QAAAA8AAABkcnMvZG93
bnJldi54bWxEj11rwjAUhu8H/odwhN2MmW4MHZ1RivtQUATrhO3u2Jw2ZU1SklTrv1/wYrt8z3t4
Xp7pvNcNO5HztTUCHkYJMDKFlbWpBHzu3++fgfmARmJjDQm4kIf5bHAzxVTas9nRKQ8VixDjUxSg
QmhTzn2hSKMf2ZZM7ErrNIYYXcWlw3OE64Y/JsmYa6xNXFDY0kJR8ZN3WsDbVz65+5gsZLZR3934
uF8ty9cnIW6HffYCLFAf/p/Xh22XHf7KK2olBUSTcnk5ulru0Ady10s0jZbAZ78AAAD//wMAUEsB
Ai0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz
XS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMv
LnJlbHNQSwECLQAUAAYACAAAACEAlr1CDtkAAAD5AAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rv
d25yZXYueG1sUEsFBgAAAAADAAMAtwAAAA0DAAAAAAAAD/AQAAAAZAwAAOYGAAASFgAAQggAAA8A
EfB+AAAADwCIE3YAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAACx
DwgAAAAAAAADAAABAA8AihM2AAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMYAAAAAACsDxAA
AAAAAAAAAAAQAAAAAAAAAAAADwAN8JMAAAAAAJ8PBAAAAAcAAAAAAKgPJwAAAERhdGEgbG9hZCBl
cnJvcg1JbnN0cnVjdGlvbiBmZXRjaCBlcnJvcgAAoQ8eAAAAKAAAAAAAASAAAAgAAAAoAAAAAAAm
AAQADgAIYKj+AACqDwwAAAAoAAAABgAAAAkEBAgAAKYPFgAAAPgeAAAAANQBIAHQAkAC8ANgAxAF
gAQPAATwSAUAABIACvAIAAAAH8AAAAIKAACDAAvwMAAAAH8AAAAEAIAAsA/ICr8ABAAEAIEBRYLL
AIMBAAAACL8BEAAUAP8BAAAIAL8DAAACABMAIvHdAwAAqYPXAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQBsd1ck1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9dSwMxEEXfhf6HMAXfbFarpaxNi1jE
ltLiVvF5upnuLm4mSxL3498b+mAf79zhXM5i1ZtatOR8ZVnB/SQBQZxbXXGh4Ovz7W4OwgdkjbVl
UjCQh9VydLPAVNuOM2qPoRARwj5FBWUITSqlz0sy6Ce2IY7d2TqDIUZXSO2wi3BTy4ckmUmDFceF
Eht6LSn/Of4aBX32PZ3a/SPh0G3wab3eHk6HrVK34/7lGUSgPlyf57u2/dj9lxfURiuIJuf34eQq
naEP5C6XaBotQS7/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAA
AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsA
AAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGx3VyTWAAAA+QAAAA8A
AAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAKAwAAAAAAAA/w
EAAAANIAAABCCAAAsAcAAI4JAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf
AFAAUABUADEAMAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8A
UABQAFQAOQAAAIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfB1AAAAAACfDwQAAAAH
AAAAAACoDwkAAABBUEVJIEJFUlQAAKEPHgAAAAoAAAAAAAEgAAAIAAAACgAAAAAAJgAEAA4ABgkO
/gAAqg8MAAAACgAAAAYAAAAJBAQIAACmDxYAAAD4HgAAAADUASAB0AJAAvADYAMQBYAEDwAE8EIF
AAASAArwCAAAACDAAAACCgAAgwAL8DAAAAB/AAAABACAANAayAq/AAQABACBAUWCywCDAQAAAAi/
ARAAFAD/AQAACAC/AwAAAgATACLx3AMAAKmD1gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAA
EwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpR
HMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQS
ldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C
6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9y
pKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUB
AAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pq
x46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYL
S63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Ke
puj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEAw0JGcNUA
AAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPQUvDQBCF74L/YRnBm91oVSR2W4pFbIQW0xbPk+w0
Cc3Oht21Sf69Sw96fPOG7/HNFoNpxZmcbywruJ8kIIhLqxuuFBz273cvIHxA1thaJgUjeVjMr69m
mGrbc07nXahEhLBPUUEdQpdK6cuaDPqJ7Yhjd7TOYIjRVVI77CPctPIhSZ6lwYbjQo0dvdVUnnY/
RsGQf0+ndvNIOPZrfFqtsm2xzZS6vRmWryACDeH/ufg6fWbLv/KCWmsF0eT4MRau0Tn6QO5yiabR
EuT8FwAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABb
Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAA
AAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAMNCRnDVAAAA+QAAAA8AAAAAAAAAAAAA
AAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAJAwAAAAAAAA/wEAAAALAHAABC
CAAAZAwAAI4JAAAPABHwfgAAAA8AiBN2AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEA
MAAAAIsTEAAAAAAAsQ8IAAAAAAAAAwAAAQAPAIoTNgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAA
AIsTGAAAAAAArA8QAAAAAAAAAAAAEAAAAAAAAAAAAA8ADfBwAAAAAACfDwQAAAAHAAAAAACoDwQA
AABXQUlUAAChDx4AAAAFAAAAAAABIAAACAAAAAUAAAAAACYABAAOAAYJDv4AAKoPDAAAAAUAAAAG
AAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBZBQAAEgAK8AgAAAAhwAAA
AgoAAIMAC/AwAAAAfwAAAAQAgAAIJMgKvwAEAAQAgQFFgssAgwEAAAAIvwEQABQA/wEAAAgAvwMA
AAIAEwAi8dwDAACpg9YDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhABvQZUDVAAAA+QAAAA8AAABkcnMv
ZG93bnJldi54bWxEj0FPwkAQhe8m/ofNmHiDrSKGVBZiJEaIASkQz0N3aBu7s83uStt/74YDHt+8
yffyTeedqcWZnK8sK3gYJiCIc6srLhQc9u+DCQgfkDXWlklBTx7ms9ubKabatpzReRcKESHsU1RQ
htCkUvq8JIN+aBvi2J2sMxhidIXUDtsIN7V8TJJnabDiuFBiQ28l5T+7X6Ogy75HI7t+IuzbJY4X
i9XmuFkpdX/Xvb6ACNSF/2f5lW0/5bW8oJZaQTQ5ffRHV+kMfSB3uUTTaAly9gcAAP//AwBQSwEC
LQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8u
cmVsc1BLAQItABQABgAIAAAAIQAb0GVA1QAAAPkAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93
bnJldi54bWxQSwUGAAAAAAMAAwC3AAAACQMAAAAAAAAP8BAAAABkDAAAQggAABIWAACOCQAADwAR
8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAALEP
CAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgAAAAAAKwPEAAA
AAAAAAAAABAAAAAAAAAAAAAPAA3whwAAAAAAnw8EAAAABwAAAAAAqA8bAAAARG9tMCBvd24sIHdh
aXQga2VybmVsIHJlYWR5AAChDx4AAAAcAAAAAAABIAAACAAAABwAAAAAACYABAAOAAYJDv4AAKoP
DAAAABwAAAAGAAAACQQECAAApg8WAAAA+B4AAAAA1AEgAdACQALwA2ADEAWABA8ABPBABAAAQgEK
8AgAAAAiwAAAAgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEAAAAIywGcMQAA/wEYABgA
vwMAAAIAIwAi8d4DAAD/AQAAQACpg9IDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABb
Q29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak
27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2M
KYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiy
GsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/I
ajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/
ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR
/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx
8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAK4TAcjRAAAA7AAA
AA8AAABkcnMvZG93bnJldi54bWxEj0FrAjEQhe9C/0OYQm+abaEqW6NsC8VeelgVqbfpZtws3UyW
JHVXf31DETzOzJv33rdYDbYVJ/KhcazgcZKBIK6cbrhWsNu+j+cgQkTW2DomBWcKsFrejRaYa9dz
SadNrEUy4ZCjAhNjl0sZKkMWw8R1xOl2dN5iTKOvpfbYJ3Pbyqcsm0qLDacEgx29Gap+Nr9Wwee6
OLxedF9uy72Rz7NdvT98FUo93A/FC4hIQ7yJr98fWkEqf1yfv32jSwyR/P8mwSUwkMs/AAAA//8D
AFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U
eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9y
ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRy
cy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAFAwAAAAAAAA/wEAAAALAHAACcAQAAsAcAACcP
AAAPAATwQAQAAEIBCvAIAAAAI8AAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAAAA
CMsBnDEAAP8BGAAYAL8DAAACACMAIvHeAwAA/wEAAEAAqYPSAwAAUEsDBBQABgAIAAAAIQDb4fbL
7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiN
B7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEE
Nu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjymp
x31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5x
zhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2
jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62
kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztF
L6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAA
IQCuEwHI0QAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BawIxEIXvQv9DmEJvmm2hKlujbAvF
XnpYFam36WbcLN1MliR1V399QxE8zsyb9963WA22FSfyoXGs4HGSgSCunG64VrDbvo/nIEJE1tg6
JgVnCrBa3o0WmGvXc0mnTaxFMuGQowITY5dLGSpDFsPEdcTpdnTeYkyjr6X22Cdz28qnLJtKiw2n
BIMdvRmqfja/VsHnuji8XnRfbsu9kc+zXb0/fBVKPdwPxQuISEO8ia/fH1pBKn9cn799o0sMkfz/
JsElMJDLPwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAA
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAA
AAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAAAAA
AAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABQMAAAAAAAAP8BAAAABk
DAAAnAEAAGQMAAAnDwAADwAE8DwEAABCAQrwCAAAACTAAAACCgAAcwAL8CoAAAC/AAQABAB/AQAA
AQC/AQAAEADAAQAAAAjLAdSUAAD/ARgAGAC/AwAAAgAjACLx2gMAAP8BAABAAKmDzgMAAFBLAwQU
AAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPk
K2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63
T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43n
RJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI3
4Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsD
BBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDG
iNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7l
TBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSn
YEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8D
AFBLAwQUAAYACAAAACEAR10jPs0AAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWvDMAyF74X9
B6PBbq2zDcLI6pYx6NrDLk1LzmqsxGGxHGyvdf/9TCnsKOnpvfct18mO4kw+DI4VPC8KEMSt0wP3
Co6HzfwNRIjIGkfHpOBKAdarh9kSK+0uvKdzHXuRTThUqMDEOFVShtaQxbBwE3G+dc5bjHn0vdQe
L9ncjvKlKEppceCcYHCiT0PtT/1rFXy/OtvU3VcyTdqObDZledihUk+P6eMdRKQU/8X3751WkMt3
2+vJD3qPIZK/bTJcBgO5+gMAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAA
AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUB
AAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBHXSM+zQAAAOwA
AAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAAAQMAAAAA
AAAP8BAAAADSAAAAiwIAABIWAACLAgAADwAE8EAEAABCAQrwCAAAACXAAAACCgAAcwAL8CoAAAC/
AAQABAB/AQAAAQC/AQAAEADAAQAAAAjLAZwxAAD/ARgAGAC/AwAAAgAjACLx3gMAAP8BAABAAKmD
0gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9O
wzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1W
oIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHN
DgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487Mrog
V1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8A
AAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7
YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwv
x7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773
/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODT
M+MvAAAA//8DAFBLAwQUAAYACAAAACEArhMByNEAAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESP
QWsCMRCF70L/Q5hCb5ptoSpbo2wLxV56WBWpt+lm3CzdTJYkdVd/fUMRPM7Mm/fet1gNthUn8qFx
rOBxkoEgrpxuuFaw276P5yBCRNbYOiYFZwqwWt6NFphr13NJp02sRTLhkKMCE2OXSxkqQxbDxHXE
6XZ03mJMo6+l9tgnc9vKpyybSosNpwSDHb0Zqn42v1bB57o4vF50X27LvZHPs129P3wVSj3cD8UL
iEhDvImv3x9aQSp/XJ+/faNLDJH8/ybBJTCQyz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA
ACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA
ACEArhMByNEAAADsAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAD
AAMAtwAAAAUDAAAAAAAAD/AQAAAA0gAAAAYEAAASFgAABgQAAA8ABPBABAAAQgEK8AgAAAAmwAAA
AgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEAAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi
8d4DAAD/AQAAQACpg9IDAABQSwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9U
eXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+f
XG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOU
PhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9
sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7
KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5y
ZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI
2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptM
LMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNV
C0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAABkcnMv
ZG93bnJldi54bWxEj0FrAjEQhe9C/0OYQm+abaEqW6NsC8VeelgVqbfpZtws3UyWJHVXf31DETzO
zJv33rdYDbYVJ/KhcazgcZKBIK6cbrhWsNu+j+cgQkTW2DomBWcKsFrejRaYa9dzSadNrEUy4ZCj
AhNjl0sZKkMWw8R1xOl2dN5iTKOvpfbYJ3Pbyqcsm0qLDacEgx29Gap+Nr9Wwee6OLxedF9uy72R
z7NdvT98FUo93A/FC4hIQ7yJr98fWkEqf1yfv32jSwyR/P8mwSUwkMs/AAAA//8DAFBLAQItABQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2
LnhtbFBLBQYAAAAAAwADALcAAAAFAwAAAAAAAA/wEAAAANIAAAB2BQAAEhYAAHYFAAAPAATwQAQA
AEIBCvAIAAAAJ8AAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAAAACMsBnDEAAP8B
GAAYAL8DAAACACMAIvHeAwAA/wEAAEAAqYPSAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAAT
AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEc
yvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV
0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq
4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kk
pfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEA
AAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrH
jpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtL
reUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m
6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCuEwHI0QAA
AOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BawIxEIXvQv9DmEJvmm2hKlujbAvFXnpYFam36Wbc
LN1MliR1V399QxE8zsyb9963WA22FSfyoXGs4HGSgSCunG64VrDbvo/nIEJE1tg6JgVnCrBa3o0W
mGvXc0mnTaxFMuGQowITY5dLGSpDFsPEdcTpdnTeYkyjr6X22Cdz28qnLJtKiw2nBIMdvRmqfja/
VsHnuji8XnRfbsu9kc+zXb0/fBVKPdwPxQuISEO8ia/fH1pBKn9cn799o0sMkfz/JsElMJDLPwAA
AP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl
bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8B
AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAAAAAAAAAAAAAAAcC
AABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABQMAAAAAAAAP8BAAAADSAAAA5gYAABIW
AADmBgAADwAE8EAEAABCAQrwCAAAACjAAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADA
AQAAAAjLAZwxAAD/ARgAGAC/AwAAAgAjACLx3gMAAP8BAABAAKmD0gMAAFBLAwQUAAYACAAAACEA
2+H2y+4AAACFAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A
4QgIjQewEreN1jpRHMr29qTbuCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP
1MCBBDbt5UW9PQQSldMsDYwphXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6o
x48pqcd9bp9MIk0C6uG0uLIawBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6
xZiecc4a2kbR1n9ypKX8/8hqOUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAA
IQBa9CxbvwAAABUBAAALAAAAX3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCx
lcQstoxksvXtZ3pqx46S+D9Jw+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+G
M62utpAusahpSlYLS63lE1H9Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt
8x87RS+sPNXOc0Kepuj/UzHwdz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYA
CAAAACEArhMByNEAAADsAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWsCMRCF70L/Q5hCb5ptoSpb
o2wLxV56WBWpt+lm3CzdTJYkdVd/fUMRPM7Mm/fet1gNthUn8qFxrOBxkoEgrpxuuFaw276P5yBC
RNbYOiYFZwqwWt6NFphr13NJp02sRTLhkKMCE2OXSxkqQxbDxHXE6XZ03mJMo6+l9tgnc9vKpyyb
SosNpwSDHb0Zqn42v1bB57o4vF50X27LvZHPs129P3wVSj3cD8ULiEhDvImv3x9aQSp/XJ+/faNL
DJH8/ybBJTCQyz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAA
AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAA
AAAAAAAAAAAAAAAfAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEArhMByNEAAADsAAAADwAA
AAAAAAAAAAAAAAAHAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAUDAAAAAAAAD/AQ
AAAA0gAAAEIIAAASFgAAQggAAA8ABPBABAAAQgEK8AgAAAApwAAAAgoAAHMAC/AqAAAAvwAEAAQA
fwEAAAEAvwEAABAAwAEAAAAIywGcMQAA/wEYABgAvwMAAAIAIwAi8d4DAAD/AQAAQACpg9IDAABQ
SwMEFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfv
SLxD5CtqUzgghNruQOEICI0HsBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeO
hwbet0/FHShJyBYnz9TAgQQ27eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdV
dauN50ScirTegLbuqMePKanHfW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/Sv
hHXyN+Cce8mvic6SesWYnnHOGtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8D
AFBLAwQUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRf
lO5QxojTW6HX0j6AsZXELLaMZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBa
XQ5u5UwWbqRwGF9fhjOtrraQLrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA
8ck0p2BBTmEH5nIrbfMfO0UvrDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAA
AP//AwBQSwMEFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrAjEQ
he9C/0OYQm+abaEqW6NsC8VeelgVqbfpZtws3UyWJHVXf31DETzOzJv33rdYDbYVJ/KhcazgcZKB
IK6cbrhWsNu+j+cgQkTW2DomBWcKsFrejRaYa9dzSadNrEUy4ZCjAhNjl0sZKkMWw8R1xOl2dN5i
TKOvpfbYJ3Pbyqcsm0qLDacEgx29Gap+Nr9Wwee6OLxedF9uy72Rz7NdvT98FUo93A/FC4hIQ7yJ
r98fWkEqf1yfv32jSwyR/P8mwSUwkMs/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUB
AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0
LFu/AAAAFQEAAAsAAAAAAAAAAAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAK4T
AcjRAAAA7AAAAA8AAAAAAAAAAAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcA
AAAFAwAAAAAAAA/wEAAAANIAAACOCQAAEhYAAI4JAAAPAATwQAQAAEIBCvAIAAAAKsAAAAIKAABz
AAvwKgAAAL8ABAAEAH8BAAABAL8BAAAQAMABAAAACMsBnDEAAP8BGAAYAL8DAAACACMAIvHeAwAA
/wEAAEAAqYPSAwAAUEsDBBQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNd
LnhtbHyQz07DMAyH70i8Q+QralM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOk
ForiPDdwXVagiI23jocG3rdPxR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv
44wpl3HQAc0OB9I3VXWrjedEnIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnO
hDInjzsyuiBXWQP0r4R18jfgnHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R
8m2lj09svwAAAP//AwBQSwMEFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zP
wWrDMAwG4Ptg72B0X5TuUMaI01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvB
UPYcYp4tXC/Htw8wWl0ObuVMFm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbK
jMX5LzcTvvf9HuXRgPHJNKdgQU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U
2rp2HOA44NMz4y8AAAD//wMAUEsDBBQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAZHJzL2Rvd25y
ZXYueG1sRI9BawIxEIXvQv9DmEJvmm2hKlujbAvFXnpYFam36WbcLN1MliR1V399QxE8zsyb9963
WA22FSfyoXGs4HGSgSCunG64VrDbvo/nIEJE1tg6JgVnCrBa3o0WmGvXc0mnTaxFMuGQowITY5dL
GSpDFsPEdcTpdnTeYkyjr6X22Cdz28qnLJtKiw2nBIMdvRmqfja/VsHnuji8XnRfbsu9kc+zXb0/
fBVKPdwPxQuISEO8ia/fH1pBKn9cn799o0sMkfz/JsElMJDLPwAAAP//AwBQSwECLQAUAAYACAAA
ACEA2+H2y+4AAACFAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt
ABQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQIt
ABQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQ
SwUGAAAAAAMAAwC3AAAABQMAAAAAAAAP8BAAAADSAAAAnAEAANIAAAAnDwAADwAE8EAEAABCAQrw
CAAAACvAAAACCgAAcwAL8CoAAAC/AAQABAB/AQAAAQC/AQAAEADAAQAAAAjLAZwxAAD/ARgAGAC/
AwAAAgAjACLx3gMAAP8BAABAAKmD0gMAAFBLAwQUAAYACAAAACEA2+H2y+4AAACFAQAAEwAAAFtD
b250ZW50X1R5cGVzXS54bWx8kM9OwzAMh+9IvEPkK2pTOCCE2u5A4QgIjQewEreN1jpRHMr29qTb
uCDg6D8/f59cb/bzpBaK4jw3cF1WoIiNt46HBt63T8UdKEnIFifP1MCBBDbt5UW9PQQSldMsDYwp
hXutxYw0o5Q+EOdJ7+OMKZdx0AHNDgfSN1V1q43nRJyKtN6Atu6ox48pqcd9bp9MIk0C6uG0uLIa
wBAmZzBlU72w/UEpzoQyJ487MrogV1kD9K+EdfI34Jx7ya+JzpJ6xZiecc4a2kbR1n9ypKX8/8hq
OUvh+94ZKrsoXY690fJtpY9PbL8AAAD//wMAUEsDBBQABgAIAAAAIQBa9CxbvwAAABUBAAALAAAA
X3JlbHMvLnJlbHNsz8FqwzAMBuD7YO9gdF+U7lDGiNNbodfSPoCxlcQstoxksvXtZ3pqx46S+D9J
w+EnrWYj0cjZwq7rwVD2HGKeLVwvx7cPMFpdDm7lTBZupHAYX1+GM62utpAusahpSlYLS63lE1H9
Qslpx4Vym0wsydVWyozF+S83E773/R7l0YDxyTSnYEFOYQfmcitt8x87RS+sPNXOc0Kepuj/UzHw
dz7T1hQnM1ULQfTeFNq6dhzgOODTM+MvAAAA//8DAFBLAwQUAAYACAAAACEArhMByNEAAADsAAAA
DwAAAGRycy9kb3ducmV2LnhtbESPQWsCMRCF70L/Q5hCb5ptoSpbo2wLxV56WBWpt+lm3CzdTJYk
dVd/fUMRPM7Mm/fet1gNthUn8qFxrOBxkoEgrpxuuFaw276P5yBCRNbYOiYFZwqwWt6NFphr13NJ
p02sRTLhkKMCE2OXSxkqQxbDxHXE6XZ03mJMo6+l9tgnc9vKpyybSosNpwSDHb0Zqn42v1bB57o4
vF50X27LvZHPs129P3wVSj3cD8ULiEhDvImv3x9aQSp/XJ+/faNLDJH8/ybBJTCQyz8AAAD//wMA
UEsBAi0AFAAGAAgAAAAhANvh9svuAAAAhQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5
cGVzXS54bWxQSwECLQAUAAYACAAAACEAWvQsW78AAAAVAQAACwAAAAAAAAAAAAAAAAAfAQAAX3Jl
bHMvLnJlbHNQSwECLQAUAAYACAAAACEArhMByNEAAADsAAAADwAAAAAAAAAAAAAAAAAHAgAAZHJz
L2Rvd25yZXYueG1sUEsFBgAAAAADAAMAtwAAAAUDAAAAAAAAD/AQAAAAEhYAAJwBAAASFgAAJw8A
AA8ABPBABAAAQgEK8AgAAAAswAAAAgoAAHMAC/AqAAAAvwAEAAQAfwEAAAEAvwEAABAAwAEAAAAI
ywGcMQAA/wEYABgAvwMAAAIAIwAi8d4DAAD/AQAAQACpg9IDAABQSwMEFAAGAAgAAAAhANvh9svu
AAAAhQEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDPTsMwDIfvSLxD5CtqUzgghNruQOEICI0H
sBK3jdY6URzK9vak27gg4Og/P3+fXG/286QWiuI8N3BdVqCIjbeOhwbet0/FHShJyBYnz9TAgQQ2
7eVFvT0EEpXTLA2MKYV7rcWMNKOUPhDnSe/jjCmXcdABzQ4H0jdVdauN50ScirTegLbuqMePKanH
fW6fTCJNAurhtLiyGsAQJmcwZVO9sP1BKc6EMiePOzK6IFdZA/SvhHXyN+Cce8mvic6SesWYnnHO
GtpG0dZ/cqSl/P/IajlL4fveGSq7KF2OvdHybaWPT2y/AAAA//8DAFBLAwQUAAYACAAAACEAWvQs
W78AAAAVAQAACwAAAF9yZWxzLy5yZWxzbM/BasMwDAbg+2DvYHRflO5QxojTW6HX0j6AsZXELLaM
ZLL17Wd6aseOkvg/ScPhJ61mI9HI2cKu68FQ9hxini1cL8e3DzBaXQ5u5UwWbqRwGF9fhjOtrraQ
LrGoaUpWC0ut5RNR/ULJaceFcptMLMnVVsqMxfkvNxO+9/0e5dGA8ck0p2BBTmEH5nIrbfMfO0Uv
rDzVznNCnqbo/1Mx8Hc+09YUJzNVC0H03hTaunYc4Djg0zPjLwAAAP//AwBQSwMEFAAGAAgAAAAh
AK4TAcjRAAAA7AAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrAjEQhe9C/0OYQm+abaEqW6NsC8Ve
elgVqbfpZtws3UyWJHVXf31DETzOzJv33rdYDbYVJ/KhcazgcZKBIK6cbrhWsNu+j+cgQkTW2Dom
BWcKsFrejRaYa9dzSadNrEUy4ZCjAhNjl0sZKkMWw8R1xOl2dN5iTKOvpfbYJ3Pbyqcsm0qLDacE
gx29Gap+Nr9Wwee6OLxedF9uy72Rz7NdvT98FUo93A/FC4hIQ7yJr98fWkEqf1yfv32jSwyR/P8m
wSUwkMs/AAAA//8DAFBLAQItABQABgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAAAAAAAAAAAAAAAAA
AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAAAAAAAA
AAAAAAAAHwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAK4TAcjRAAAA7AAAAA8AAAAAAAAA
AAAAAAAABwIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAAAwADALcAAAAFAwAAAAAAAA/wEAAAANIA
AACcAQAAEhYAAJwBAAAPAATwQAQAAEIBCvAIAAAALcAAAAIKAABzAAvwKgAAAL8ABAAEAH8BAAAB
AL8BAAAQAMABAAAACMsBnDEAAP8BGAAYAL8DAAACACMAIvHeAwAA/wEAAEAAqYPSAwAAUEsDBBQA
BgAIAAAAIQDb4fbL7gAAAIUBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQz07DMAyH70i8Q+Qr
alM4IITa7kDhCAiNB7ASt43WOlEcyvb2pNu4IODoPz9/n1xv9vOkForiPDdwXVagiI23jocG3rdP
xR0oScgWJ8/UwIEENu3lRb09BBKV0ywNjCmFe63FjDSjlD4Q50nv44wpl3HQAc0OB9I3VXWrjedE
nIq03oC27qjHjympx31un0wiTQLq4bS4shrAECZnMGVTvbD9QSnOhDInjzsyuiBXWQP0r4R18jfg
nHvJr4nOknrFmJ5xzhraRtHWf3Kkpfz/yGo5S+H73hkquyhdjr3R8m2lj09svwAAAP//AwBQSwME
FAAGAAgAAAAhAFr0LFu/AAAAFQEAAAsAAABfcmVscy8ucmVsc2zPwWrDMAwG4Ptg72B0X5TuUMaI
01uh19I+gLGVxCy2jGSy9e1nemrHjpL4P0nD4SetZiPRyNnCruvBUPYcYp4tXC/Htw8wWl0ObuVM
Fm6kcBhfX4Yzra62kC6xqGlKVgtLreUTUf1CyWnHhXKbTCzJ1VbKjMX5LzcTvvf9HuXRgPHJNKdg
QU5hB+ZyK23zHztFL6w81c5zQp6m6P9TMfB3PtPWFCczVQtB9N4U2rp2HOA44NMz4y8AAAD//wMA
UEsDBBQABgAIAAAAIQCuEwHI0QAAAOwAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9BawIxEIXvQv9D
mEJvmm2hKlujbAvFXnpYFam36WbcLN1MliR1V399QxE8zsyb9963WA22FSfyoXGs4HGSgSCunG64
VrDbvo/nIEJE1tg6JgVnCrBa3o0WmGvXc0mnTaxFMuGQowITY5dLGSpDFsPEdcTpdnTeYkyjr6X2
2Cdz28qnLJtKiw2nBIMdvRmqfja/VsHnuji8XnRfbsu9kc+zXb0/fBVKPdwPxQuISEO8ia/fH1pB
Kn9cn799o0sMkfz/JsElMJDLPwAAAP//AwBQSwECLQAUAAYACAAAACEA2+H2y+4AAACFAQAAEwAA
AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBa9CxbvwAA
ABUBAAALAAAAAAAAAAAAAAAAAB8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCuEwHI0QAA
AOwAAAAPAAAAAAAAAAAAAAAAAAcCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAMAAwC3AAAABQMA
AAAAAAAP8BAAAADSAAAAJw8AABIWAAAnDwAADwAE8LAAAABCAQrwCAAAAC7AAAACCgAAwwAL8EgA
AACFAAIAAACHAAEAAAC/AAAADwC/AQAAEADAAQAAAAjLAZwxAAD/AQwADgABAgIAAAg/AgAAAwC/
AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAH8BAABAAP8BAACAAL8DAIIAgn8FBgBOAL8FBgBOAP8F
BgBOAD8GBgBOAH8GBgAOAAAAD/AQAAAA0gAAAFsMAAASFgAAWwwAAA8ABPCwAAAAQgEK8AgAAAAv
wAAAAgoAAMMAC/BIAAAAhQACAAAAhwABAAAAvwAAAA8AvwEAABAAwAEAAAAIywGcMQAA/wEMAA4A
AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAB/AQAAQAD/AQAAgAC/AwCCAIJ/
BQYATgC/BQYATgD/BQYATgA/BgYATgB/BgYADgAAAA/wEAAAANIAAAD0CgAAEhYAAPQKAAAPAATw
sAAAAEIBCvAIAAAAMMAAAAIKAADDAAvwSAAAAIUAAgAAAIcAAQAAAL8AAAAPAL8BAAAQAMABAAAA
CMsBnDEAAP8BDAAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAAfwEAAEAA
/wEAAIAAvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAP8BAAAADSAAAAwQ0A
ABIWAADBDQAADwAE8CABAACiDArwCAAAADLAAAAACgAAwwAL8G4AAAB/AAEA7wGAADwsyAqBAAAA
AACCAAAAAACDAAAAAACEAAAAAAC/AAQABAC/AQEAEQD/ARAAGAA/AwAACACAwyYAAAC/AwAAAgBE
AGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAAAAAEPAIAAAAXBDkCr4MqhAPAA3w
ggAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQAD
AAgAsrKy/gAA9w8IAAAAAAAAAABS2AkAAKoPGgAAAAEAAAAHAAAAAAARBAkEAQAAAAYAAAAJBBEE
AACmDwwAAADwAAAA1AHQAvADEAUPAATwLAEAAKIMCvAIAAAAM8AAAAAKAADDAAvwfgAAAH8AAQDv
AYAAADXICoEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8ABAAEAL8BAQARAP8BEAAYAD8DAAAIAIDD
NgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQBy
ACAANAAAAAAAEPAIAAAAXRDeCeQKqhAPAA3wfgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEP
HgAAAAIAAAAAAAAIAAAAAAIAAAABACYAAQADAAgAsrKy/gAA2A8EAAAAAAAAAAAAqg8aAAAAAQAA
AAcAAAAAABEECQQBAAAABgAAAAkEEQQAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPBIAAAAEgAK8AgA
AAABwAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ
AAAAPwMBAAEAEADwByAAAAD///8ACGCoAP9cRwD15kcApsrhAFZ+uQAMLoYAqgFMAA8AiBOBAAAA
DwCKE3kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTWQAAAAAAACsEAAAAAAAAAB8ARPE9
AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAwwr/////EgAAAA8APfENAAAAQAFC8QUA
AAABCQAAAA8AAisAAAAADwDwA5kGAAABAPEDCAAAAGgBAAAHAA0wDwAMBBkGAAAPAALwEQYAAAAB
CPAIAAAABAAAAAUsAAAPAAPwqQUAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK
8AgAAAAALAAABQAAAA8ABPDOAAAAEgAK8AgAAAACLAAAIAIAAPMAC/COAAAABAAAAAAAfwCFAe8B
gQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAEAAQA/wERABEAAQME
KAAAPwMAAAgAgMM0AAAAvwMAAAIAUwBsAGkAZABlACAASQBtAGEAZwBlACAAUABsAGEAYwBlAGgA
bwBsAGQAZQByACAAMQAAAAAAEPAIAAAAvgH8ApwOdgoPABHwEAAAAAAAwwsIAAAAAAAAAAsAyAoP
AATwVAMAABIACvAIAAAAAywAACACAAATAQvwjgAAAAQAAAAAAH8AAQDvAYAAgCPICoEAg3IBAIIA
QbkAAIMAg3IBAIQAQbkAAIUAAAAAAIcAAAAAAIgAAAAAAL8ABAAEAL8BAAABAP8BEAARAAEDBSgA
AD8DAAAIAIDDKAAAAL8DAAACAE4AbwB0AGUAcwAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIA
AAAAABDwCAAAAAsLWQI/D4IVDwAR8BAAAAAAAMMLCAAAAAEAAAAMAMgKDwAN8H4CAAAAAJ8PBAAA
AAIAAAAAAKAPBAIAACoAIABXAGUAIABuAGUAZQBkACAAZABvAHUAYgBsAGUAIABjAGgAZQBjAGsA
OgAgAEkAZgAgAE0AQwBHAF8AQwBNAEMASQBfAFAAPQAxACAAYQBuAGQAIABlAG4AYQBiAGwAZQAg
AGEAbABsACAATQBDAGkAXwBDAFQATAAyACwAIABpAHQAIAB3AG8AdQBsAGQAIABiAGUAbgBlAGYA
aQB0ACAAdABoAGEAdAAgAGcAdQBlAHMAdAAgAG0AYQB5ACAAbgBvAHQAIABwAG8AbABsACAAcABl
AHIAaQBvAGQAaQBjAGEAbABsAHkAIABmAG8AcgAgAEMARQAvAFUAQwBOAEEAIABlAHIAcgBvAHIA
LgANACAAIABFAHYAZQBuACAAdwBlACAAcwBlAHQAIABNAEMARwBfAEMATQBDAEkAXwBQAD0AMQAg
AGEAbgBkACAAZQBuAGEAYgBsAGUAIABhAGwAbAAgAE0AQwBpAF8AQwBUAEwAMgAsACAAaAB5AHAA
ZQByAHYAaQBzAG8AcgAgAHMAdABpAGwAbAAgAGQAbwBlAHMAIABuAG8AdAAgAGkAbgBqAGUAYwB0
ACAAQwBNAEMASQAgAHQAbwAgAGcAdQBlAHMAdAAgAHMAaQBuAGMAZQAgAGkAdAAZIHMAIABwAG8A
aQBuAHQAbABlAHMAcwAuAAAAoQ8UAAAAAwEAAAAAAAAAAAMBAAAAACAABAAAAKoPJgAAAF0AAAAG
AAAACQQECAMAAAAHAAAAAAAJBAQIowAAAAYAAAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2AD
EAWABA8ABPA/AQAAogwK8AgAAAAELAAAAAoAANMAC/CEAAAAfwABAO8BgADol8gKgQCDcgEAggBB
uQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQAvwEAABAA/wEQABgAPwMAAAgAgMM2AAAAvwMAAAIA
UwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ
8AgAAAAWFvgJmBFAFw8AEfAJAAAAAAAgBAEAAAAIDwAN8HoAAAAAAJ8PBAAAAAQAAAAAAKAPAgAA
ACoAAAChDxgAAAACAAAAAAAACAAAAgACAAAAAAAiAAQADAAAANgPBAAAAAAAAAAAAKoPGgAAAAEA
AAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIAACmDw4AAADxAAAAVQLUAdAC8AMQBQ8ABPBIAAAAEgAK
8AgAAAAFLAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHiMm0AlAEuRpAAvwESABIA/wEAAAgA
BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4
AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAQzXNAWCE
xrwPAPADdQQAAAEA8QMIAAAAWQEAAAcADTAPAAwE9QMAAA8AAvDtAwAAIAEI8AgAAAAEAAAABTAA
AA8AA/CFAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAwAAAFAAAA
DwAE8M4AAAASAArwCAAAAAIwAAAgAgAA8wAL8I4AAAAEAAAAAAB/AIUB7wGBADBlAQCCAJiyAACD
ADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAQABAD/AREAEQABAwQoAAA/AwAACACAwzQA
AAC/AwAAAgBTAGwAaQBkAGUAIABJAG0AYQBnAGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAx
AAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDICg8ABPAwAQAAEgAK8AgA
AAADMAAAIAIAABMBC/COAAAABAAAAAAAfwABAO8BgACEgMgKgQCDcgEAggBBuQAAgwCDcgEAhABB
uQAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQAvwEBAAEA/wERABEAAQMFKAAAPwMAAAgAgMMoAAAA
vwMAAAIATgBvAHQAZQBzACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAACwtZ
Aj8PghUPABHwEAAAAAAAwwsIAAAAAQAAAAwAyAoPAA3wWgAAAAAAnw8EAAAAAgAAAAAAoQ8UAAAA
AQAAAAAAAAAAAAEAAAAAACAABAAAAKoPDgAAAAEAAAAHAAAAAAAJBAQIAACmDxQAAADwHgAA1AEg
AdACQALwA2ADEAWABA8ABPA/AQAAogwK8AgAAAAEMAAAAAoAANMAC/CEAAAAfwABAO8BgACgscgK
gQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQAvwEAABAA/wEQABgAPwMAAAgAgMM2
AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIA
IAAzAAAAAAAQ8AgAAAAWFvgJmBFAFw8AEfAJAAAAAAAgBAEAAAAIDwAN8HoAAAAAAJ8PBAAAAAQA
AAAAAKAPAgAAACoAAAChDxgAAAACAAAAAAAACAAAAgACAAAAAAAiAAQADAAAANgPBAAAAAAAAAAA
AKoPGgAAAAEAAAAHAAAAAAAECAkEAQAAAAYAAAAJBAQIAACmDw4AAADxAAAAVQLUAdAC8AMQBQ8A
BPBIAAAAEgAK8AgAAAAFMAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHiMm0AlAEuRpAAvwES
ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkA
mcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4I
AAAARDXNAbAwpaQPAPADcAQAAAEA8QMIAAAAawEAAAcADTAPAAwE8AMAAA8AAvDoAwAA8AEI8AgA
AAAEAAAABHwAAA8AA/CAAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA
AAB8AAAFAAAADwAE8NQAAAASAArwCAAAAAJ8AAAgAgAAAwEL8JQAAAAEAAAAAAB/AIUB7wGBADBl
AQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAQABAD/AREAEQABAwQoAAA/
AwAACACAwzQAAACIAwAAAAC/AwAAAgBTAGwAaQBkAGUAIABJAG0AYQBnAGUAIABQAGwAYQBjAGUA
aABvAGwAZABlAHIAIAAxAAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDI
Cg8ABPA2AQAAEgAK8AgAAAADfAAAIAIAACMBC/CUAAAABAAAAAAAfwABAO8BgAAcFMgKgQCDcgEA
ggBBuQAAgwCDcgEAhABBuQAAhQAAAAAAhwAAAAAAiAAAAAAAvwAEAAQAvwEBAAEA/wERABEAAQMF
KAAAPwMAAAgAgMMoAAAAiAMAAAAAvwMAAAIATgBvAHQAZQBzACAAUABsAGEAYwBlAGgAbwBsAGQA
ZQByACAAMgAAAAAAEPAIAAAACwtZAj8PghUPABHwEAAAAAAAwwsIAAAAAQAAAAwAyAoPAA3wWgAA
AAAAnw8EAAAAAgAAAAAAoQ8UAAAAAQAAAAAAAAAAAAEAAAAAACAABAAAAKoPDgAAAAEAAAAHAAAA
AAAJBAQIAACmDxQAAADwHgAA1AEgAdACQALwA2ADEAWABA8ABPAuAQAAogwK8AgAAAAEfAAAAAoA
ANMAC/CEAAAAfwABAO8BgADUyMgKgQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQA
vwEAABAA/wEQABgAPwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQ
AGwAYQBjAGUAaABvAGwAZABlAHIAIAAzAAAAAAAQ8AgAAAAWFvgJmBFAFw8ADfB6AAAAAACfDwQA
AAAEAAAAAACgDwIAAAAqAAAAoQ8YAAAAAgAAAAAAAAgAAAIAAgAAAAAAIgAEAAwAAADYDwQAAAAA
AAAAAACqDxoAAAABAAAABwAAAAAABAgJBAEAAAAGAAAACQQECAAApg8OAAAA8QAAAFUC1AHQAvAD
EAUPAATwSAAAABIACvAIAAAAAXwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQ
AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA
AJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA
AOsuCAAAAEQ1zQGwMKWkDwDwAzAEAAABAPEDCAAAAGwBAAAHAA0wDwAMBLADAAAPAALwqAMAABAC
CPAIAAAABAAAAASQAAAPAAPwQAMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK
8AgAAAAAkAAABQAAAA8ABPAWAQAAogwK8AgAAAACkAAAAAoAANMAC/BmAAAAfwABAO8BgABY2MgK
gQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhwACAAAAvwAEAAQAvwEAABEA/wEAABgAPwMAAAgAgMMY
AAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA3AAAAAAAQ8AgAAAAVFvcJlxE/Fw8ADfCAAAAA
AACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAAAgKAAIABwACAAAAAABjAAEABAAB
AAwAAADYDwQAAAAAAAAAAACqDxoAAAABAAAABwAAAAAACQQECAEAAAAGAAAACQQECAAApg8OAAAA
8QAAAFUC1AHQAvADEAUPAATwuAAAABIACvAIAAAAA5AAACACAAADAQvweAAAAAQAAAAAAH8ABAHv
AYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8ABAAEAP8BAQARAAED
BCgAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAI
AAAAvgH8ApwOdgoPABHwEAAAAAAAwwsIAAAAAAAAAAsAyAoPAATwKgEAABIACvAIAAAABJAAACAC
AAAjAQvwhAAAAAQAAAAAAH8AAQDvAYAA6OLICoEAg3IBAIIAQbkAAIMAg3IBAIQAQbkAAIUAAAAA
AIcAAAAAAIgAAAAAAL8ABAAEAL8BAQARAP8BAQARAAEDBSgAAD8DAAAIAIDDGAAAAIgDAAAAAL8D
AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAACwvCAdYPghUPABHwEAAAAAAAwwsI
AAAAAQAAAAwAyAoPAA3wXgAAAAAAnw8EAAAAAgAAAAAAoQ8WAAAAAQAAAAAAACAAAAAAAQAAAAAA
IAAEAAAAqg8OAAAAAQAAAAcAAAAAAAkEBAgAAKYPFgAAAPgeAACQANQBIAHQAkAC8ANgAxAFgAQP
AATwSAAAABIACvAIAAAAAZAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQAL8B
EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ
AJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsu
CAAAAHHtyAFQwOTMDwDwAywCAAABAPEDCAAAAG0BAAAHAA0wDwAMBKwBAAAPAALwpAEAAFACCPAI
AAAAAwAAAAOgAAAPAAPwPAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA
AAAAoAAABQAAAA8ABPBYAAAAEgAK8AgAAAACoAAAIAIAAEMAC/AYAAAAfwAEAAQAvwEBAAEA/wEB
AAEAAQMEKAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDICg8ABPCkAAAA
EgAK8AgAAAADoAAAIAIAAFMAC/AeAAAAfwAAAAQAgABM48gKvwEBAAEA/wEBAAEAAQMFKAAAAAAQ
8AgAAAALC1kCPw+CFQ8AEfAQAAAAAADDCwgAAAABAAAADADICg8ADfA+AAAAAACfDwQAAAACAAAA
AAChDxQAAAABAAAAAAAAAAAAAQAAAAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQPAATwSAAA
ABIACvAIAAAAAaAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQAL8BEgASAP8B
AAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAP
AIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAANw/
zQFwleIYDwDwA+EDAAABAPEDCAAAAGcBAAAHAA0wDwAMBGEDAAAPAALwWQMAAHACCPAIAAAAAwAA
AAOoAAAPAAPw8QIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAqAAA
BQAAAA8ABPBYAAAAEgAK8AgAAAACqAAAIAIAAEMAC/AYAAAAfwAEAAQAvwEBAAEA/wEBAAEAAQME
KAAAAAAQ8AgAAAC+AfwCnA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDICg8ABPBZAgAAEgAK8AgA
AAADqAAAIAIAAFMAC/AeAAAAfwAAAAQAgADY88gKvwEAAAEA/wEAAAEAAQMFKAAAAAAQ8AgAAAAL
C1kCPw+CFQ8AEfAQAAAAAADDCwgAAAABAAAADADICg8ADfDzAQAAAACfDwQAAAACAAAAAACoD90A
AABJbml0JnByb2JlIGludGVyZmFjZSByZWZlciB0byB0aG9zZSBNU1JzIHdoaWNoIGluZGljYXRl
IG1jZSBjYXBhYml0aWVzL2NvbnRyb2wgcmVnczsNRXJyb3ItaW5mbyBpbnRlcmZhY2UgcmVmZXIg
dG8gdGhvc2UgTVNScyB3aGljaCBjb250YWluIGVycm9yIGluZm8gYW5kIG9ubHkgbWVhbmluZ2Z1
bCB3aGVuIGVycm9yIHJlYWwgb2NjdXIsIGUuZy4gTUNpX1NUQVRVUywgTUNpX0FERFI7DQAAoQ8U
AAAA3gAAAAAAAAAAAN4AAAAAACAABAAAAKoP3gAAAAoAAAAHAAAAAQAJBAQIGgAAAAYAAAAJBAQI
BAAAAAcAAAABAAkEBAgQAAAABgAAAAkEBAgDAAAABwAAAAEACQQECAEAAAAGAAAACQQECAoAAAAH
AAAAAQAJBAQICQAAAAYAAAAJBAQIBAAAAAcAAAABAAkEBAgmAAAABgAAAAkEBAgEAAAABwAAAAEA
CQQECEoAAAAGAAAACQQECAoAAAAHAAAAAQAJBAQIAgAAAAYAAAAJBAQICAAAAAcAAAABAAkEBAgC
AAAABgAAAAkEBAgBAAAABwAAAAAABAgJBA8ABPBIAAAAEgAK8AgAAAABqAAAAAwAAIMAC/AwAAAA
gQEAAAAIgwEFAAAIkwHiMm0AlAEuRpAAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/
//8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8A
XwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA3D/NAcCfW0UPAPADwAQAAAEA8QMIAAAAcwEA
AAcADTAPAAwEgAQAAA8AAvB4BAAA4AII8AgAAAAEAAAABMQAAA8AA/AQBAAADwAE8CgAAAABAAnw
EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADEAAAFAAAADwAE8NQAAAASAArwCAAAAALEAAAg
AgAAAwEL8JQAAAAEAAAAAAB/AIUB7wGBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEA
AACIAAAAAAC/AAQABAD/AREAEQABAwQoAAA/AwAACACAwzQAAACIAwAAAAC/AwAAAgBTAGwAaQBk
AGUAIABJAG0AYQBnAGUAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAAxAAAAAAAQ8AgAAAC+AfwC
nA52Cg8AEfAQAAAAAADDCwgAAAAAAAAACwDJCg8ABPAyAQAAEgAK8AgAAAADxAAAIAIAABMBC/CO
AAAABAAAAAAAfwABAO8BgABkBskKgQCDcgEAggBBuQAAgwCDcgEAhABBuQAAhQAAAAAAhwAAAAAA
iAAAAAAAvwAEAAQA/wERABEAAQMFKAAAPwMAAAgAgMMoAAAAiAMAAAAAvwMAAAIATgBvAHQAZQBz
ACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMgAAAAAAEPAIAAAACwvCAdYPghUPABHwEAAAAAAA
wwsIAAAAAQAAAAwAyQoPAA3wXAAAAAAAnw8EAAAAAgAAAAAAoQ8WAAAAAQAAAAAAACAAAAAAAQAA
AAAAIAAEAAAAqg8OAAAAAQAAAAcAAAAAAAQICQQAAKYPFAAAAPAeAADUASAB0AJAAvADYAMQBYAE
DwAE8MIBAACiDArwCAAAAATEAAAACgAA0wAL8IQAAAB/AAEA7wGAADAIyQqBAINyAQCCAEG5AACD
AINyAQCEAEG5AACHAAIAAAC/ABQAHwC/AQAAEAD/ARAAGAA/AwAACACAwzYAAAC/AwAAAgBTAGwA
aQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAAAABDwCAAA
ABUW9wmXET8XDwAR8H4AAAAPAIgTdgAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA
AACLExAAAAAAALEPCAAAAAAAAAMAAAEADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACL
ExgAAAAAAKwPEAAAAAAAAAAAABAAAAAAAAAAAAAPAA3wiAAAAAAAnw8EAAAABAAAAAAAoA8CAAAA
KgAAAKEPHgAAAAIAAAAAAAAICgACAAcAAgAAAAAAYwAFAAQABQAMAAAA2A8EAAAAAAAAAAAAqg8a
AAAAAQAAAAcAAAAAAAQICQQBAAAABgAAAAkEBAgAAKYPFgAAAPEeAABVAuUBKwHrAlUCFgSAA0AF
qwQPAATwSAAAABIACvAIAAAAAcQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB4jJtAJQBLkaQ
AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAADu7OEAH0l9AE+BvQDAUE0A
AAD/AIAAgAAPAPADEgYAAAEA8QMIAAAAdAEAAAcADTAPAAwEkgUAAA8AAvCKBQAAAAMI8AgAAAAD
AAAAA9AAAA8AA/AiBQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAADQ
AAAFAAAADwAE8F4AAAASAArwCAAAAALQAAAgAgAAUwAL8B4AAAB/AAQABAC/AQEAAQD/AQEAAQAB
AwQoAACIAwAAAAAAABDwCAAAAL4B/AKcDnYKDwAR8BAAAAAAAMMLCAAAAAAAAAALAMkKDwAE8IQE
AAASAArwCAAAAAPQAAAgAgAAYwAL8CQAAAB/AAAABACAABwfyQq/AQAAAQD/AQAAAQABAwUoAACI
AwAAAAAAABDwCAAAAAsLWQI/D4IVDwAR8BAAAAAAAMMLCAAAAAEAAAAMAMkKDwAN8BgEAAAAAJ8P
BAAAAAIAAAAAAKAP6gIAACoAIABJAG4AaQB0ACYAcAByAG8AYgBlACAAaQBuAHQAZQByAGYAYQBj
AGUAIAByAGUAZgBlAHIAIAB0AG8AIAB0AGgAbwBzAGUAIABNAFMAUgBzACAAdwBoAGkAYwBoACAA
aQBuAGQAaQBjAGEAdABlACAAbQBjAGUAIABjAGEAcABhAGIAaQB0AGkAZQBzAC8AYwBvAG4AdABy
AG8AbAAgAHIAZQBnAHMAOwANACoAIABFAHIAcgBvAHIALQBpAG4AZgBvACAAaQBuAHQAZQByAGYA
YQBjAGUAIAByAGUAZgBlAHIAIAB0AG8AIAB0AGgAbwBzAGUAIABNAFMAUgBzACAAdwBoAGkAYwBo
ACAAYwBvAG4AdABhAGkAbgAgAGUAcgByAG8AcgAgAGkAbgBmAG8AIABhAG4AZAAgAG8AbgBsAHkA
IABtAGUAYQBuAGkAbgBnAGYAdQBsACAAdwBoAGUAbgAgAGUAcgByAG8AcgAgAHIAZQBhAGwAIABv
AGMAYwB1AHIALAAgAGUALgBnAC4AIABNAEMAaQBfAFMAVABBAFQAVQBTACwAIABNAEMAaQBfAEEA
RABEAFIAOwANAA0AKgAqACAASQBmACAAdwBlACAAcwBlAHQAIABNAEMARwBfAEMATQBDAEkAXwBQ
AD0AMQAsACAATQBDAGkAXwBDAFQATAAyACAAdwBvAHUAbABkACAAYQBsAHMAbwAgAGIAZQAgAGUA
bQB1AGwAYQB0AGUAZAAgAGEAcwAgAEMATQBDAEkAIABlAG4AYQBiAGwAZQBkACwAIABiAHUAdAAg
AGgAeQBwAGUAcgB2AGkAcwBvAHIAIABzAHQAaQBsAGwAIABkAG8AZQBzACAAbgBvAHQAIABpAG4A
agBlAGMAdAAgAEMATQBDAEkAIAB0AG8AIABnAHUAZQBzAHQAIABzAGkAbgBjAGUAIABpAHQAGSBz
ACAAcABvAGkAbgB0AGwAZQBzAHMAAAChDxQAAAB2AQAAAAAAAAAAdgEAAAAAIAAEAAAAqg/2AAAA
AgAAAAYAAAAJBAQICgAAAAcAAAABAAkEBAgaAAAABgAAAAkEBAgEAAAABwAAAAEACQQECBAAAAAG
AAAACQQECAMAAAAHAAAAAQAJBAQIAQAAAAYAAAAJBAQICgAAAAcAAAABAAkEBAgJAAAABgAAAAkE
BAgEAAAABwAAAAEACQQECCgAAAAGAAAACQQECAQAAAAHAAAAAQAJBAQISgAAAAYAAAAJBAQICgAA
AAcAAAABAAkEBAgCAAAABgAAAAkEBAgIAAAABwAAAAEACQQECAIAAAAGAAAACQQECAQAAAAHAAAA
AAAECAkEkQAAAAYAAAAJBAQIDwAE8EgAAAASAArwCAAAAAHQAAAADAAAgwAL8DAAAACBAQAAAAiD
AQUAAAiTAeIybQCUAS5GkAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA
gICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQ
AFQAMQAwAAAAixMQAAAAAADrLggAAADcP80BsO7dMwAAcheAAAAAAQBwAAAAAADRkgAA6RsAAKrW
AAD2CQIA9kACAFIDAwAMACAAhg0EACcUBAAPAEAALAACAPP2AgAoDwMApBgEABQAYACl3QAAHB0E
ABkuAgCjOwIAg+wCAFQhBAAbABAAiCMEAB0AEAAJGAMAIQBAAOEwAwBxJwQAWx0DADksBAAAAPUP
HAAAAHMBAACPIAADAAAAAFMyBAABAAAAJgAAAAEAxTEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJytAAAM
AAAAAQAAAGgAAAACAAAAcAAAAAQAAACIAAAABwAAAKQAAAAIAAAAwAAAAAkAAADQAAAAEgAAANwA
AAAKAAAAAAEAAAwAAAAMAQAADQAAABgBAAAPAAAAJAEAABEAAAAsAQAAAgAAAKgDAAAeAAAAEAAA
AFZlcmRhbmEgQm9sZCAzMAAeAAAAFAAAAEludGVsIENvcnBvcmF0aW9uAAAAHgAAABQAAAB3aGl0
ZV9pbnRlbF9vbmx5AAAAAB4AAAAIAAAAamxpdTE0AAAeAAAABAAAADMzMwAeAAAAHAAAAE1pY3Jv
c29mdCBPZmZpY2UgUG93ZXJQb2ludABAAAAAQKMwKzwHAABAAAAAsG+pB+4oxgFAAAAAQAtUoPxO
zQEDAAAAgAQAAEcAAABorAAA/////wMAAAAIADsN7AkAAAEACQAAAyxWAAABAKEnAAAAABYQAAAm
Bg8AIiBXTUZDAQAAAAAAAQBV8QAAAAADAAAAACAAADw4AAA8WAAAAQAAAGwAAAAAAAAAAAAAAP8C
AAA/AgAAAAAAAAAAAAAAMgAAADIAACBFTUYAAAEAPFgAAAYAAAACAAAAAAAAAAAAAAAAAQAAgAcA
ADgEAABAAQAA8AAAAAAAAAAAAAAAAAAAAADiBACAqQMAMQAAABAEAAABAAAAAAMAAQAAAACAAAAA
AIAAAICAAAAAAIAAgACAAACAgADAwMAAwNzAAKbK8AAEBAQACAgIAAwMDAAREREAFhYWABwcHAAi
IiIAKSkpAFVVVQBNTU0AQkJCADk5OQD/fIAA/1BQANYAkwDM7P8A79bGAOfn1gCtqZAAMwAAAGYA
AACZAAAAzAAAAAAzAAAzMwAAZjMAAJkzAADMMwAA/zMAAABmAAAzZgAAZmYAAJlmAADMZgAA/2YA
AACZAAAzmQAAZpkAAJmZAADMmQAA/5kAAADMAAAzzAAAZswAAJnMAADMzAAA/8wAAGb/AACZ/wAA
zP8AAAAAMwAzADMAZgAzAJkAMwDMADMA/wAzAAAzMwAzMzMAZjMzAJkzMwDMMzMA/zMzAABmMwAz
ZjMAZmYzAJlmMwDMZjMA/2YzAACZMwAzmTMAZpkzAJmZMwDMmTMA/5kzAADMMwAzzDMAZswzAJnM
MwDMzDMA/8wzADP/MwBm/zMAmf8zAMz/MwD//zMAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYAADNm
ADMzZgBmM2YAmTNmAMwzZgD/M2YAAGZmADNmZgBmZmYAmWZmAMxmZgAAmWYAM5lmAGaZZgCZmWYA
zJlmAP+ZZgAAzGYAM8xmAJnMZgDMzGYA/8xmAAD/ZgAz/2YAmf9mAMz/ZgD/AMwAzAD/AACZmQCZ
M5kAmQCZAMwAmQAAAJkAMzOZAGYAmQDMM5kA/wCZAABmmQAzZpkAZjOZAJlmmQDMZpkA/zOZADOZ
mQBmmZkAmZmZAMyZmQD/mZkAAMyZADPMmQBmzGYAmcyZAMzMmQD/zJkAAP+ZADP/mQBmzJkAmf+Z
AMz/mQD//5kAAADMADMAmQBmAMwAmQDMAMwAzAAAM5kAMzPMAGYzzACZM8wAzDPMAP8zzAAAZswA
M2bMAGZmmQCZZswAzGbMAP9mmQAAmcwAM5nMAGaZzACZmcwAzJnMAP+ZzAAAzMwAM8zMAGbMzACZ
zMwAzMzMAP/MzAAA/8wAM//MAGb/mQCZ/8wAzP/MAP//zAAzAMwAZgD/AJkA/wAAM8wAMzP/AGYz
/wCZM/8AzDP/AP8z/wAAZv8AM2b/AGZmzACZZv8AzGb/AP9mzAAAmf8AM5n/AGaZ/wCZmf8AzJn/
AP+Z/wAAzP8AM8z/AGbM/wCZzP8AzMz/AP/M/wAz//8AZv/MAJn//wDM//8A/2ZmAGb/ZgD//2YA
Zmb/AP9m/wBm//8ApQAhAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx
8fEA+Pj4AP/78ACgoKQAgICAAP8AAAAA/wAA//8AAAAA/wD/AP8AAP//AP///wAwAAAADAAAAAEA
AAAVAAAADAAAAAMAAABNAAAAlE8AAAAAAAAAAAAA/wIAAD8CAAAAAAAAAAAAAAADAABAAgAAIADM
AAAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAA////AAAAAABsAAAAKAQAAJQEAAAASwAA
oAAAAHgAAAAoAAAAoAAAAHgAAAABAAgAAAAAAABLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAA
gAAAAICAAIAAAACAAIAAgIAAAMDAwADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIi
IgApKSkAVVVVAE1NTQBCQkIAOTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMAAABm
AAAAmQAAAMwAADMAAAAzMwAAM2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABmzAAAZv8A
AJkAAACZMwAAmWYAAJmZAACZzAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8AAP9mAAD/mQAA
/8wAMwAAADMAMwAzAGYAMwCZADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMzzAAzM/8AM2YAADNm
MwAzZmYAM2aZADNmzAAzZv8AM5kAADOZMwAzmWYAM5mZADOZzAAzmf8AM8wAADPMMwAzzGYAM8yZ
ADPMzAAzzP8AM/8zADP/ZgAz/5kAM//MADP//wBmAAAAZgAzAGYAZgBmAJkAZgDMAGYA/wBmMwAA
ZjMzAGYzZgBmM5kAZjPMAGYz/wBmZgAAZmYzAGZmZgBmZpkAZmbMAGaZAABmmTMAZplmAGaZmQBm
mcwAZpn/AGbMAABmzDMAZsyZAGbMzABmzP8AZv8AAGb/MwBm/5kAZv/MAMwA/wD/AMwAmZkAAJkz
mQCZAJkAmQDMAJkAAACZMzMAmQBmAJkzzACZAP8AmWYAAJlmMwCZM2YAmWaZAJlmzACZM/8AmZkz
AJmZZgCZmZkAmZnMAJmZ/wCZzAAAmcwzAGbMZgCZzJkAmczMAJnM/wCZ/wAAmf8zAJnMZgCZ/5kA
mf/MAJn//wDMAAAAmQAzAMwAZgDMAJkAzADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADM
ZjMAmWZmAMxmmQDMZswAmWb/AMyZAADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzM
mQDMzMwAzMz/AMz/AADM/zMAmf9mAMz/mQDM/8wAzP//AMwAMwD/AGYA/wCZAMwzAAD/MzMA/zNm
AP8zmQD/M8wA/zP/AP9mAAD/ZjMAzGZmAP9mmQD/ZswAzGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA
/5n/AP/MAAD/zDMA/8xmAP/MmQD/zMwA/8z/AP//MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/
ZmYA/2b/AP//ZgAhAKUAX19fAHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx
8QD4+PgA8Pv/AKSgoACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AKaKpoqmioqKpoqm
iqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaK
poqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqm
ioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqsimVDPEMAQzxDAGysiqyKrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqt
iqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqzvrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrIqKpqyKrIqtiqyKrYqsiq2KiopsAEMAQwBDAB1Ciq2KrIqtpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqK
poqKiqaKioqmioqKpoqKiqaKioqmiu/v7+/viu/v7++mioqKpoqKiqaKioqmrIqtiqyKrIqsiqyK
rIqsiqyKrYqsiq2miq2KZUNDbUNtQ20AQ4qmioqspqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqt
iqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqspoqKrKaKiouKi4uLiouLi6aKioqm
rIqmimwAIgBDAAAAAEOKrIqtiqyKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqK
poqKiqaKioqmioqKpoqKiqaKioqmioqLi4uLi4uLi5GLs4u0i7SRtIusiq2KrIqKrIpmQzxDPEJC
QzxsioqKpoqmrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqt
iqyKrYqsiq2KrIqtbIuKi6aKiotliouLpouKi4qKi5GLi6atioqss4q0tLu0tIqti4qtiqyKraaK
ioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqK
iqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqK
pouKrIq0kbWRtIu1kbSRtZG0kbu1u5GspoqtioqzkK2Ls7S0pq2KpoqKiqasiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqxsi6aKkbWStYu1
kbWRu5G7kbuRtbS0pqyKpoqzs7S0tLS0tLOLiqyKrYqspoqmioqKpoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqm
iqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKi4qsi7uLs4q0tLOLs4uzkLOLs4uz
i62KiqyKiq20tbS1tLSLs4qKiqaKiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrWyLiouKi4uRi4uKi4uLi4uLi6aKpoqKrYqKirOKs4uz
iq2ztIuKrYqsiq2mioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaLi4tti4u0kbSLs4u0kbSLtIutiqyKraaKrYqLiqati7OLs4uziqaKiqym
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiqymioqtioqKrIqLioqmioqspoqKiqasiqaKs62zi7Ots4uzioqsiq2KrIqKpoqmiqaKioqm
iqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqspoqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyK
iqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqK
pqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqm
rIqKpqyKtLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0
tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1
tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tf//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////4qK/4r/////////
/////////////4qK//////////////////////////+Kiv//iv///////4qK////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////iv+KioqK//+Kiv//////ior/iv//iv//ioqK//+K
iv////+K/4qKiv+K/4r//4qKiv//iooWEAAAJgYPACIgV01GQwEAAAAAAAEAAAAAAAAAAwAAAAAg
AAA8GAAAPFgAAP+KioqKior//4qK//+Kiv+Kiv+K/4qKioqKioqKiv//iv+K////////////////
////////////////////////////////////////////////////////////////////////////
////iv+K/4qKiv+Kiv////+Kiv//ior/ior/ioqKiv+Kiv///4r/iv+K//+KioqK/4qKior/ior/
/4qK/4qKiv+Kiv+K/4qKioqKiv+Kior/iv+KioqKior//4r/////////////////////////////
/////////////////////////////////////////////////////////////////4r/////////
//////+K/////////4r///////////////////////////+K////////////////////////////
/4qKiv///4r///+K////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////+K//////////////////+Kiv//////iv//////
////////ior/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////iv+Kior///+K/4qK//+KioqKiv//ior/////ioqKiv//ioqKior//4qK/4qK
ioqK//+Kiv+Kiv//iv+KioqKioqKior//4r/iv//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/4r/ior/////iv+Kior/iv+KioqK/4qK////iv+KioqK/4r/ioqKiv+Kiv//ioqK//+K/4qKioqK
/4r/ioqK/4r/ioqKioqK//+K////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////+K/////////4r/
/////////////////////////////////////////////4r//////4qKiv////+K////iv//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////4qK////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////4r//4r//4qKiv///4r/////iv//////////ioqKiv//ioqK////
/4qKiv//ioqKioqK//+K/4qKiv////+K////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////iv+K/4r/////iv+K////ior//4r//4r/iv///////4r///////+K//+Kiv////+K
iv//ior//4r//4r/iv//////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////+K
//+KioqK/4r/iv///4r/iv+KioqK/4r///////+Kior/////iv//ioqKioqK/////4qK//+K//+K
/4r/////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////+K/4r//4qK//+Kior/
/4r//4r/iv+Kiv+K////////iv///////4r//4r/ior//4qK//+K/4qKiv//ioqK////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////iv+K/////////////////////4r//4r/
/4qKior//4qKiv////+Kior/////////////iv//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////NAwAACYG
DwBeGFdNRkMBAAAAAAABAAAAAAAAAAMAAAA8GAAAAAAAADxYAAD/////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8OAAAAFAQAAAABAAAQAAAAAAAAAIAAAAAAgAAAgIAAAAAAgACAAIAAAICAAMDA
wADA3MAApsrwAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIiIgApKSkAVVVVAE1NTQBCQkIAOTk5
AP98gAD/UFAA1gCTAMzs/wDv1sYA5+fWAK2pkAAzAAAAZgAAAJkAAADMAAAAADMAADMzAABmMwAA
mTMAAMwzAAD/MwAAAGYAADNmAABmZgAAmWYAAMxmAAD/ZgAAAJkAADOZAABmmQAAmZkAAMyZAAD/
mQAAAMwAADPMAABmzAAAmcwAAMzMAAD/zAAAZv8AAJn/AADM/wAAAAAzADMAMwBmADMAmQAzAMwA
MwD/ADMAADMzADMzMwBmMzMAmTMzAMwzMwD/MzMAAGYzADNmMwBmZjMAmWYzAMxmMwD/ZjMAAJkz
ADOZMwBmmTMAmZkzAMyZMwD/mTMAAMwzADPMMwBmzDMAmcwzAMzMMwD/zDMAM/8zAGb/MwCZ/zMA
zP8zAP//MwAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZgAAM2YAMzNmAGYzZgCZM2YAzDNmAP8zZgAA
ZmYAM2ZmAGZmZgCZZmYAzGZmAACZZgAzmWYAZplmAJmZZgDMmWYA/5lmAADMZgAzzGYAmcxmAMzM
ZgD/zGYAAP9mADP/ZgCZ/2YAzP9mAP8AzADMAP8AAJmZAJkzmQCZAJkAzACZAAAAmQAzM5kAZgCZ
AMwzmQD/AJkAAGaZADNmmQBmM5kAmWaZAMxmmQD/M5kAM5mZAGaZmQCZmZkAzJmZAP+ZmQAAzJkA
M8yZAGbMZgCZzJkAzMyZAP/MmQAA/5kAM/+ZAGbMmQCZ/5kAzP+ZAP//mQAAAMwAMwCZAGYAzACZ
AMwAzADMAAAzmQAzM8wAZjPMAJkzzADMM8wA/zPMAABmzAAzZswAZmaZAJlmzADMZswA/2aZAACZ
zAAzmcwAZpnMAJmZzADMmcwA/5nMAADMzAAzzMwAZszMAJnMzADMzMwA/8zMAAD/zAAz/8wAZv+Z
AJn/zADM/8wA///MADMAzABmAP8AmQD/AAAzzAAzM/8AZjP/AJkz/wDMM/8A/zP/AABm/wAzZv8A
ZmbMAJlm/wDMZv8A/2bMAACZ/wAzmf8AZpn/AJmZ/wDMmf8A/5n/AADM/wAzzP8AZsz/AJnM/wDM
zP8A/8z/ADP//wBm/8wAmf//AMz//wD/ZmYAZv9mAP//ZgBmZv8A/2b/AGb//wClACEAX19fAHd3
dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx8QD4+PgA//vwAKCgpACAgIAA/wAA
AAD/AAD//wAAAAD/AP8A/wAA//8A////ABQEAAAEAAAAAwEIAAUAAAALAgAAAAAFAAAADAJAAgAD
CQIAAPcAAAMCAQAAAACAAAAAAIAAAICAAAAAAIAAgACAAACAgADAwMAAwNzAAKbK8AAEBAQACAgI
AAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQD/fIAA/1BQANYAkwDM7P8A
79bGAOfn1gCtqZAAMwAAAGYAAACZAAAAzAAAAAAzAAAzMwAAZjMAAJkzAADMMwAA/zMAAABmAAAz
ZgAAZmYAAJlmAADMZgAA/2YAAACZAAAzmQAAZpkAAJmZAADMmQAA/5kAAADMAAAzzAAAZswAAJnM
AADMzAAA/8wAAGb/AACZ/wAAzP8AAAAAMwAzADMAZgAzAJkAMwDMADMA/wAzAAAzMwAzMzMAZjMz
AJkzMwDMMzMA/zMzAABmMwAzZjMAZmYzAJlmMwDMZjMA/2YzAACZMwAzmTMAZpkzAJmZMwDMmTMA
/5kzAADMMwAzzDMAZswzAJnMMwDMzDMA/8wzADP/MwBm/zMAmf8zAMz/MwD//zMAAABmADMAZgBm
AGYAmQBmAMwAZgD/AGYAADNmADMzZgBmM2YAmTNmAMwzZgD/M2YAAGZmADNmZgBmZmYAmWZmAMxm
ZgAAmWYAM5lmAGaZZgCZmWYAzJlmAP+ZZgAAzGYAM8xmAJnMZgDMzGYA/8xmAAD/ZgAz/2YAmf9m
AMz/ZgD/AMwAzAD/AACZmQCZM5kAmQCZAMwAmQAAAJkAMzOZAGYAmQDMM5kA/wCZAABmmQAzZpkA
ZjOZAJlmmQDMZpkA/zOZADOZmQBmmZkAmZmZAMyZmQD/mZkAAMyZADPMmQBmzGYAmcyZAMzMmQD/
zJkAAP+ZADP/mQBmzJkAmf+ZAMz/mQD//5kAAADMADMAmQBmAMwAmQDMAMwAzAAAM5kAMzPMAGYz
zACZM8wAzDPMAP8zzAAAZswAM2bMAGZmmQCZZswAzGbMAP9mmQAAmcwAM5nMAGaZzACZmcwAzJnM
AP+ZzAAAzMwAM8zMAGbMzACZzMwAzMzMAP/MzAAA/8wAM//MAGb/mQCZ/8wAzP/MAP//zAAzAMwA
ZgD/AJkA/wAAM8wAMzP/AGYz/wCZM/8AzDP/AP8z/wAAZv8AM2b/AGZmzACZZv8AzGb/AP9mzAAA
mf8AM5n/AGaZ/wCZmf8AzJn/AP+Z/wAAzP8AM8z/AGbM/wCZzP8AzMz/AP/M/wAz//8AZv/MAJn/
/wDM//8A/2ZmAGb/ZgD//2YAZmb/AP9m/wBm//8ApQAhAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKy
ANfX1wDd3d0A4+PjAOrq6gDx8fEA+Pj4AP/78ACgoKQAgICAAP8AAAAA/wAA//8AAAAA/wD/AP8A
AP//AP///wD///8AAAAAAAQAAAA0AgAABAAAAAcBAwChJwAAQQsgAMwAeACgAAAAAABAAgADAAAA
ACgAAACgAAAAeAAAAAEACAAAAAAAAEsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA
gAAAAIAAgACAgAAAwMDAAMDcwADwyqYABAQEAAgICAAMDAwAERERABYWFgAcHBwAIiIiACkpKQBV
VVUATU1NAEJCQgA5OTkAgHz/AFBQ/wCTANYA/+zMAMbW7wDW5+cAkKmtAAAAMwAAAGYAAACZAAAA
zAAAMwAAADMzAAAzZgAAM5kAADPMAAAz/wAAZgAAAGYzAABmZgAAZpkAAGbMAABm/wAAmQAAAJkz
AACZZgAAmZkAAJnMAACZ/wAAzAAAAMwzAADMZgAAzJkAAMzMAADM/wAA/2YAAP+ZAAD/zAAzAAAA
MwAzADMAZgAzAJkAMwDMADMA/wAzMwAAMzMzADMzZgAzM5kAMzPMADMz/wAzZgAAM2YzADNmZgAz
ZpkAM2bMADNm/wAzmQAAM5kzADOZZgAzmZkAM5nMADOZ/wAzzAAAM8wzADPMZgAzzJkAM8zMADPM
/wAz/zMAM/9mADP/mQAz/8wAM///AGYAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYzAABmMzMAZjNm
AGYzmQBmM8wAZjP/AGZmAABmZjMAZmZmAGZmmQBmZswAZpkAAGaZMwBmmWYAZpmZAGaZzABmmf8A
ZswAAGbMMwBmzJkAZszMAGbM/wBm/wAAZv8zAGb/mQBm/8wAzAD/AP8AzACZmQAAmTOZAJkAmQCZ
AMwAmQAAAJkzMwCZAGYAmTPMAJkA/wCZZgAAmWYzAJkzZgCZZpkAmWbMAJkz/wCZmTMAmZlmAJmZ
mQCZmcwAmZn/AJnMAACZzDMAZsxmAJnMmQCZzMwAmcz/AJn/AACZ/zMAmcxmAJn/mQCZ/8wAmf//
AMwAAACZADMAzABmAMwAmQDMAMwAmTMAAMwzMwDMM2YAzDOZAMwzzADMM/8AzGYAAMxmMwCZZmYA
zGaZAMxmzACZZv8AzJkAAMyZMwDMmWYAzJmZAMyZzADMmf8AzMwAAMzMMwDMzGYAzMyZAMzMzADM
zP8AzP8AAMz/MwCZ/2YAzP+ZAMz/zADM//8AzAAzAP8AZgD/AJkAzDMAAP8zMwD/M2YA/zOZAP8z
zAD/M/8A/2YAAP9mMwDMZmYA/2aZAP9mzADMZv8A/5kAAP+ZMwD/mWYA/5mZAP+ZzAD/mf8A/8wA
AP/MMwD/zGYA/8yZAP/MzAD/zP8A//8zAMz/ZgD//5kA///MAGZm/wBm/2YAZv//AP9mZgD/Zv8A
//9mACEApQBfX18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAPj4+ADw
+/8ApKCgAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8ApoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqm
iqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaK
poqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqyKZUM8QwBDPEMAbKyKrIqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrO+tiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqs
ioqmrIqsiq2KrIqtiqyKrYqKimwAQwBDAEMAHUKKrYqsiq2mioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaK7+/v7++K7+/v76aKioqmioqKpoqKiqasiq2KrIqsiqyKrIqsiqyKrIqt
iqyKraaKrYplQ0NtQ21DbQBDiqaKiqymrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiqymioqspoqKi4qLi4uKi4uLpoqKiqasiqaKbAAi
AEMAAAAAQ4qsiq2KrIqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqK
iqaKioqmioqKpoqKiqaKiouLi4uLi4uLkYuzi7SLtJG0i6yKrYqsioqsimZDPEM8QkJDPGyKioqm
iqatiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyK
rYqsiq1si4qLpoqKi2WKi4umi4qLioqLkYuLpq2KiqyzirS0u7S0iq2Liq2KrIqtpoqKiqaKiqym
ioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaK
ioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmioqspoqKiqaKiqymioqKpoqKrKaKioqmi4qsirSR
tZG0i7WRtJG1kbSRu7W7kaymiq2KirOQrYuztLSmrYqmioqKpqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrGyLpoqRtZK1i7WRtZG7kbuR
u5G1tLSmrIqmirOztLS0tLS0s4uKrIqtiqymiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqm
iqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaK
poqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqLiqyLu4uzirS0s4uzi7OQs4uzi7OLrYqKrIqK
rbS1tLW0tIuzioqKpoqKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqyKrYqsiq2KrIqtbIuKi4qLi5GLi4qLi4uLi4uLpoqmioqtioqKs4qzi7OKrbO0i4qt
iqyKraaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqm
ioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaKioqmioqKpoqKiqaK
ioqmioqKpouLi22Li7SRtIuzi7SRtIu0i62KrIqtpoqtiouKpq2Ls4uzi7OKpoqKrKasiq2KrIqt
iqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2K
rIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrYqsiq2KrIqtiqyKrKaK
iq2KioqsiouKiqaKiqymioqKpqyKpoqzrbOLs62zi7OKiqyKrYqsioqmiqaKpoqKiqaKpoqmioqK
poqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmiqaKioqm
iqaKpoqKiqaKpoqmioqKpoqmiqaKioqmiqaKpoqKiqaKpoqmioqKpoqmrYqsiq2KrIqtiqyKrYqs
iq2KrIqtiqymioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqas
ioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyK
iqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIqKpqyKiqasioqmrIq0
u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7
tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0
tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1tLu0tbS7tLW0u7S1////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////ior/iv//////////////////
////ior//////////////////////////4qK//+K////////ior/////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////+K/4qKior//4qK//////+Kiv+K//+K//+Kior//4qK/////4r/
ioqK/4r/iv//ioqK//+Kiv+KioqKior//4qK//+Kiv+Kiv+K/4qKioqKioqKiv//iv+K////////
////////////////////////////////////////////////////////////////////////////
////////////iv+K/4qKiv+Kiv////+Kiv//ior/ior/ioqKiv+Kiv///4r/iv+K//+KioqK/4qK
ior/ior//4qK/4qKiv+Kiv+K/4qKioqKiv+Kior/iv+KioqKior//4r/////////////////////
/////////////////////////////////////////////////////////////////////////4r/
//////////////+K/////////4r///////////////////////////+K////////////////////
/////////4qKiv///4r///+K////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////+K//////////////////+Kiv//////
iv//////////////ior/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////iv+Kior///+K/4qK//+KioqKiv//ior/////ioqKiv//ioqKior/
/4qK/4qKioqK//+Kiv+Kiv//iv+KioqKioqKior//4r/iv//////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////4r/ior/////iv+Kior/iv+KioqK/4qK////iv+KioqK/4r/ioqKiv+Kiv//ioqK//+K
/4qKioqK/4r/ioqK/4r/ioqKioqK//+K////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////+K////
/////4r//////////////////////////////////////////////4r//////4qKiv////+K////
iv//////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////4qK////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////4r//4r//4qKiv///4r/////iv//////////ioqKiv//
ioqK/////4qKiv//ioqKioqK//+K/4qKiv////+K////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////iv+K/4r/////iv+K////ior//4r//4r/iv///////4r///////+K//+K
iv////+Kiv//ior//4r//4r/iv//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////+K//+KioqK/4r/iv///4r/iv+KioqK/4r///////+Kior/////iv//ioqKioqK/////4qK
//+K//+K/4r/////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////+K/4r//4qK
//+Kior//4r//4r/iv+Kiv+K////////iv///////4r//4r/ior//4qK//+K/4qKiv//ioqK////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////iv+K////////////////////
/4r//4r//4qKior//4qKiv////+Kior/////////////iv//////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIA
AAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5kAwAAIAMAABAAAAABAAAAiAAA
AAMAAACQAAAADwAAAKgAAAAEAAAAxAAAAAYAAADMAAAABwAAANQAAAAIAAAA3AAAAAkAAADkAAAA
CgAAAOwAAAAXAAAA9AAAAAsAAAD8AAAAEAAAAAQBAAATAAAADAEAABYAAAAUAQAADQAAABwBAAAM
AAAAvgIAAAIAAACoAwAAHgAAABAAAABPbi1zY3JlZW4gU2hvdwAAHgAAABQAAABJbnRlbCBDb3Jw
b3JhdGlvbgAAAAMAAACtoQYAAwAAADkBAAADAAAADgAAAAMAAAAIAAAAAwAAAAAAAAADAAAAAAAA
AAMAAAAPJwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAFQAAAAgAAABWZXJk
YW5hAAYAAABBcmlhbAAKAAAAV2luZ2RpbmdzAAsAAABNUyBQR290aGljAAUAAADLzszlAAgAAABD
YWxpYnJpABEAAAB3aGl0ZV9pbnRlbF9vbmx5ABAAAABYZW4gdk1DRSBEZXNpZ24AFQAAAFhlbiBN
Q0UgQXJjaGl0ZWN0dXJlAAsAAABCYWNrZ3JvdW5kABYAAABYZW4gdk1DRSBhcHByb2FjaCAoMSkA
FgAAAFhlbiB2TUNFIGFwcHJvYWNoICgyKQAIAAAAU2xpZGUgNgAbAAAAUG9pbnQgMTogTVNSIGVt
dWxhdGlvbiAoMSkAGwAAAFBvaW50IDE6IE1TUiBlbXVsYXRpb24gKDIpABsAAABQb2ludCAxOiBN
U1IgZW11bGF0aW9uICgzKQAYAAAAUG9pbnQgMjogbGl2ZSBtaWdyYXRpb24AFwAAAFBvaW50IDM6
IE1DRSBpbmplY3Rpb24ACQAAAFNsaWRlIDEyAAkAAABNQ0UgTVNScwAPAAAAWGVuIFJBUyBzdGF0
dXMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAYAAAAeAAAAEAAAAERlc2lnbiBUZW1w
bGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAAOAAAAAACUAAAABQAAAAAAAAAw
AAAAAQAAAGgAAAACAAAAcAAAAAMAAAB8AAAABAAAAIgAAAADAAAAAgAAAA8AAABTUFNEZXNjcmlw
dGlvbgADAAAABgAAAE93bmVyAAQAAAAHAAAAU3RhdHVzAAIAAACoAwAAHgAAAAQAAAAAAAAAHgAA
AAQAAAAAAAAAHgAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPHgAAABQAAABfwJHj2zIEAAYA9AMDAL8KamxpdTE0
CAAAAGoAbABpAHUAMQA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA
AAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAA
ABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA
KAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2
AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQA
AABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAA
AFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAA
YQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABv
AAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0A
AAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAA
AIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAA
mgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACo
AAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAAtQAAALYA
AAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAAxAAA
AMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA0AAAANEAAADSAAAA
0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA3wAAAOAAAADh
AAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAOwAAADtAAAA7gAAAO8A
AADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgAAAD5AAAA+gAAAPsAAAD8AAAA/QAA
AP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcBAAAIAQAACQEAAAoBAAALAQAA
DAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAa
AQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAACgB
AAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAAMAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEA
ADcBAAD+////OQEAADoBAAA7AQAAPAEAAD0BAAA+AQAAPwEAAEABAABBAQAAQgEAAEMBAABEAQAA
RQEAAEYBAABHAQAASAEAAEkBAABKAQAASwEAAEwBAABNAQAATgEAAE8BAABQAQAAUQEAAFIBAABT
AQAAVAEAAFUBAABWAQAAVwEAAFgBAABZAQAAWgEAAFsBAABcAQAAXQEAAF4BAABfAQAAYAEAAGEB
AABiAQAAYwEAAGQBAABlAQAAZgEAAGcBAABoAQAAaQEAAGoBAABrAQAAbAEAAG0BAABuAQAAbwEA
AHABAABxAQAAcgEAAHMBAAB0AQAAdQEAAHYBAAB3AQAAeAEAAHkBAAB6AQAAewEAAHwBAAB9AQAA
fgEAAH8BAACAAQAAgQEAAIIBAACDAQAAhAEAAIUBAACGAQAAhwEAAIgBAACJAQAAigEAAIsBAACM
AQAAjQEAAI4BAACPAQAAkAEAAJEBAACSAQAAkwEAAJQBAACVAQAAlgEAAJcBAACYAQAAmQEAAJoB
AACbAQAAnAEAAJ0BAACeAQAAnwEAAKABAAChAQAAogEAAKMBAACkAQAApQEAAKYBAACnAQAAqAEA
AKkBAACqAQAAqwEAAKwBAACtAQAArgEAAK8BAACwAQAAsQEAALIBAACzAQAAtAEAALUBAAC2AQAA
twEAALgBAAC5AQAAugEAALsBAAC8AQAAvQEAAL4BAAC/AQAAwAEAAMEBAADCAQAAwwEAAMQBAADF
AQAAxgEAAMcBAADIAQAAyQEAAMoBAADLAQAAzAEAAM0BAADOAQAAzwEAANABAADRAQAA0gEAANMB
AADUAQAA1QEAANYBAADXAQAA2AEAANkBAADaAQAA2wEAANwBAADdAQAA3gEAAN8BAADgAQAA4QEA
AOIBAADjAQAA5AEAAOUBAADmAQAA5wEAAOgBAADpAQAA6gEAAOsBAADsAQAA7QEAAO4BAADvAQAA
8AEAAPEBAADyAQAA8wEAAPQBAAD1AQAA9gEAAPcBAAD4AQAA+QEAAPoBAAD7AQAA/AEAAP0BAAD+
AQAA/wEAAAACAAABAgAAAgIAAAMCAAAEAgAABQIAAAYCAAAHAgAACAIAAAkCAAAKAgAACwIAAAwC
AAANAgAADgIAAA8CAAAQAgAAEQIAABICAAATAgAAFAIAABUCAAAWAgAAFwIAABgCAAAZAgAAGgIA
ABsCAAAcAgAAHQIAAB4CAAAfAgAAIAIAACECAAAiAgAAIwIAACQCAAAlAgAAJgIAACcCAAAoAgAA
KQIAACoCAAArAgAALAIAAC0CAAAuAgAALwIAADACAAAxAgAAMgIAADMCAAA0AgAANQIAADYCAAA3
AgAAOAIAADkCAAA6AgAAOwIAADwCAAA9AgAAPgIAAD8CAABAAgAAQQIAAEICAABDAgAARAIAAEUC
AABGAgAARwIAAEgCAABJAgAASgIAAEsCAABMAgAATQIAAE4CAABPAgAAUAIAAFECAABSAgAAUwIA
AFQCAABVAgAAVgIAAFcCAABYAgAAWQIAAFoCAABbAgAAXAIAAF0CAABeAgAAXwIAAGACAABhAgAA
YgIAAGMCAABkAgAAZQIAAGYCAABnAgAAaAIAAGkCAABqAgAAawIAAGwCAABtAgAAbgIAAG8CAABw
AgAAcQIAAHICAABzAgAAdAIAAHUCAAB2AgAAdwIAAHgCAAB5AgAAegIAAHsCAAB8AgAAfQIAAH4C
AAB/AgAAgAIAAIECAACCAgAAgwIAAIQCAACFAgAAhgIAAIcCAACIAgAAiQIAAIoCAACLAgAAjAIA
AI0CAACOAgAAjwIAAJACAACRAgAAkgIAAJMCAACUAgAAlQIAAJYCAACXAgAAmAIAAJkCAACaAgAA
mwIAAJwCAACdAgAAngIAAJ8CAACgAgAAoQIAAKICAACjAgAApAIAAKUCAACmAgAApwIAAKgCAACp
AgAAqgIAAKsCAACsAgAArQIAAK4CAACvAgAAsAIAALECAACyAgAAswIAALQCAAC1AgAAtgIAALcC
AAC4AgAAuQIAALoCAAC7AgAAvAIAAL0CAAC+AgAAvwIAAMACAADBAgAAwgIAAMMCAADEAgAAxQIA
AMYCAADHAgAAyAIAAMkCAADKAgAAywIAAMwCAADNAgAAzgIAAM8CAADQAgAA0QIAANICAADTAgAA
1AIAANUCAADWAgAA1wIAANgCAADZAgAA2gIAANsCAADcAgAA3QIAAN4CAADfAgAA4AIAAOECAADi
AgAA4wIAAOQCAADlAgAA5gIAAOcCAADoAgAA6QIAAOoCAADrAgAA7AIAAO0CAADuAgAA7wIAAPAC
AADxAgAA8gIAAPMCAAD0AgAA9QIAAPYCAAD3AgAA+AIAAPkCAAD6AgAA+wIAAPwCAAD9AgAA/gIA
AP8CAAAAAwAAAQMAAAIDAAADAwAABAMAAAUDAAAGAwAABwMAAAgDAAAJAwAACgMAAAsDAAAMAwAA
DQMAAA4DAAAPAwAAEAMAABEDAAASAwAAEwMAABQDAAAVAwAAFgMAABcDAAAYAwAAGQMAABoDAAAb
AwAAHAMAAB0DAAAeAwAAHwMAACADAAAhAwAAIgMAACMDAAAkAwAAJQMAACYDAAAnAwAAKAMAACkD
AAAqAwAAKwMAACwDAAAtAwAALgMAAC8DAAAwAwAAMQMAADIDAAAzAwAANAMAADUDAAA2AwAANwMA
ADgDAAA5AwAAOgMAADsDAAA8AwAAPQMAAD4DAAA/AwAAQAMAAEEDAABCAwAAQwMAAEQDAABFAwAA
RgMAAEcDAABIAwAASQMAAEoDAABLAwAATAMAAE0DAABOAwAATwMAAFADAABRAwAA/v///1MDAABU
AwAAVQMAAFYDAABXAwAAWAMAAFkDAABaAwAAWwMAAFwDAABdAwAAXgMAAF8DAABgAwAAYQMAAGID
AABjAwAAZAMAAGUDAABmAwAAZwMAAGgDAABpAwAAagMAAGsDAABsAwAAbQMAAG4DAABvAwAAcAMA
AHEDAAByAwAAcwMAAHQDAAB1AwAAdgMAAHcDAAB4AwAAeQMAAHoDAAB7AwAAfAMAAH0DAAB+AwAA
fwMAAIADAACBAwAAggMAAIMDAACEAwAAhQMAAIYDAACHAwAAiAMAAIkDAACKAwAAiwMAAIwDAACN
AwAAjgMAAI8DAACQAwAAkQMAAJIDAACTAwAAlAMAAJUDAACWAwAAlwMAAJgDAACZAwAAmgMAAJsD
AACcAwAAnQMAAJ4DAACfAwAAoAMAAKEDAACiAwAAowMAAKQDAAClAwAApgMAAKcDAACoAwAA/v//
/6oDAACrAwAArAMAAK0DAACuAwAArwMAALADAAD+////sgMAALMDAAC0AwAAtQMAALYDAAC3AwAA
uAMAAP7////9/////f////3////9/////f////3////9/////f///8IDAAD+////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAA
AAAAAAAAAAAA/v///wAAAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArm4CAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUA
cgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD/////////
/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALEDAAAAEAAAAAAAAAUAUwB1AG0A
bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo
AAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgMAAMyt
AAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA4AQAA/zIEAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm
AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKkDAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA=

--_002_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233524C532SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Jun 26 10:41:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTDR-0006FG-8D; Tue, 26 Jun 2012 10:41:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <palutke.ralph@gmx.de>) id 1ShTtZ-00088H-BU
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 23:01:05 +0000
Received: from [85.158.143.99:26296] by server-1.bemta-4.messagelabs.com id
	FC/29-24392-03652EF4; Wed, 20 Jun 2012 23:01:04 +0000
X-Env-Sender: palutke.ralph@gmx.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340233263!23090840!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyMTU0NQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyMTU0NQ==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9501 invoked from network); 20 Jun 2012 23:01:04 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-12.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 23:01:04 -0000
Received: (qmail invoked by alias); 20 Jun 2012 23:01:02 -0000
Received: from p5DD7DA53.dip.t-dialin.net (EHLO gmx.de) [93.215.218.83]
	by mail.gmx.net (mp002) with SMTP; 21 Jun 2012 01:01:02 +0200
X-Authenticated: #110968699
X-Provags-ID: V01U2FsdGVkX1/KlUJzZd7Kbaw0e4L79z/WJr9v7PGmlJL7VtWZH7
	3NBvbSXp6rLfvu
Received: by gmx.de (sSMTP sendmail emulation); Thu, 21 Jun 2012 01:00:54 +0200
From: palutke.ralph@gmx.de
Date: Thu, 21 Jun 2012 01:00:54 +0200
To: xen-devel@lists.xen.org
Message-ID: <20120620230054.GA8864@mean_maschine.fritz.box>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Tue, 26 Jun 2012 10:41:46 +0000
Subject: [Xen-devel] how to check for already existing 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 guys, 

let me shortly introduce myself. I'm a student and recently work on my bachelor thesis. My goal is to write a little hypervisor.
I'm not quite sure if this is the right mailing list, but i guess you'll gonna tell me.
i have two quick questions:

1. before i can use the vmxon instruction i do have to set vmxe flag in cr4 register. but what if some hypervisor is already running? is there a way to check 
if one is running??

2. before i set the vmxe bit in cr4, i check if it is already enabled. i do this while my module gets loaded. but i observed a strange thing. sometimes
the vmxe bit seems to be set while the other time it isn't. do you have any explanation for that behaviour? do i have to check if the bit is set before 
actually setting it? I've looked at a few hypervisor projects and it seems that no one does it. my primary thought was, if the bit is set a hypervisor is running, 
but i don't think that's true anymore. so do i need the check?

greetings 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 10:41:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTDR-0006FG-8D; Tue, 26 Jun 2012 10:41:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <palutke.ralph@gmx.de>) id 1ShTtZ-00088H-BU
	for xen-devel@lists.xen.org; Wed, 20 Jun 2012 23:01:05 +0000
Received: from [85.158.143.99:26296] by server-1.bemta-4.messagelabs.com id
	FC/29-24392-03652EF4; Wed, 20 Jun 2012 23:01:04 +0000
X-Env-Sender: palutke.ralph@gmx.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340233263!23090840!1
X-Originating-IP: [213.165.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyMTU0NQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuMTY1LjY0LjIyID0+IDMyMTU0NQ==\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9501 invoked from network); 20 Jun 2012 23:01:04 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22)
	by server-12.tower-216.messagelabs.com with SMTP;
	20 Jun 2012 23:01:04 -0000
Received: (qmail invoked by alias); 20 Jun 2012 23:01:02 -0000
Received: from p5DD7DA53.dip.t-dialin.net (EHLO gmx.de) [93.215.218.83]
	by mail.gmx.net (mp002) with SMTP; 21 Jun 2012 01:01:02 +0200
X-Authenticated: #110968699
X-Provags-ID: V01U2FsdGVkX1/KlUJzZd7Kbaw0e4L79z/WJr9v7PGmlJL7VtWZH7
	3NBvbSXp6rLfvu
Received: by gmx.de (sSMTP sendmail emulation); Thu, 21 Jun 2012 01:00:54 +0200
From: palutke.ralph@gmx.de
Date: Thu, 21 Jun 2012 01:00:54 +0200
To: xen-devel@lists.xen.org
Message-ID: <20120620230054.GA8864@mean_maschine.fritz.box>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Tue, 26 Jun 2012 10:41:46 +0000
Subject: [Xen-devel] how to check for already existing 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 guys, 

let me shortly introduce myself. I'm a student and recently work on my bachelor thesis. My goal is to write a little hypervisor.
I'm not quite sure if this is the right mailing list, but i guess you'll gonna tell me.
i have two quick questions:

1. before i can use the vmxon instruction i do have to set vmxe flag in cr4 register. but what if some hypervisor is already running? is there a way to check 
if one is running??

2. before i set the vmxe bit in cr4, i check if it is already enabled. i do this while my module gets loaded. but i observed a strange thing. sometimes
the vmxe bit seems to be set while the other time it isn't. do you have any explanation for that behaviour? do i have to check if the bit is set before 
actually setting it? I've looked at a few hypervisor projects and it seems that no one does it. my primary thought was, if the bit is set a hypervisor is running, 
but i don't think that's true anymore. so do i need the check?

greetings 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 10:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTH7-0007LC-KF; Tue, 26 Jun 2012 10:45:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SjTH6-0007Ku-RT
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:37 +0000
Received: from [193.109.254.147:12896] by server-10.bemta-14.messagelabs.com
	id C1/ED-05433-0D299EF4; Tue, 26 Jun 2012 10:45:36 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340707534!1747881!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3084 invoked from network); 26 Jun 2012 10:45:35 -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;
	26 Jun 2012 10:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427160"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:33 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SjTH2-0006Ro-Tp;
	Tue, 26 Jun 2012 11:45:32 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 11:45:24 +0100
Message-ID: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
parameter. This patch changes the ownership of the buifioreq event channel to
the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).

This fix the initialization of QEMU inside the stubdomain.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 xen/arch/x86/hvm/hvm.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..9ff1ded 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3788,6 +3788,22 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                     /* xchg() ensures that only we free_xen_event_channel() */
                     old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
                     free_xen_event_channel(v, old_port);
+
+                    if ( v->vcpu_id == 0 )
+                    {
+                        new_port = alloc_unbound_xen_event_channel(
+                            v, a.value, NULL);
+                        if ( new_port < 0 )
+                        {
+                            rc = new_port;
+                            break;
+                        }
+                        old_port = xchg(
+                            &v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN],
+                            new_port);
+                        free_xen_event_channel(v, old_port);
+                    }
+
                     spin_lock(&iorp->lock);
                     if ( iorp->va != NULL )
                         get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
-- 
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 Jun 26 10:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTH7-0007LC-KF; Tue, 26 Jun 2012 10:45:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1SjTH6-0007Ku-RT
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:37 +0000
Received: from [193.109.254.147:12896] by server-10.bemta-14.messagelabs.com
	id C1/ED-05433-0D299EF4; Tue, 26 Jun 2012 10:45:36 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340707534!1747881!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3084 invoked from network); 26 Jun 2012 10:45:35 -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;
	26 Jun 2012 10:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427160"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:33 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SjTH2-0006Ro-Tp;
	Tue, 26 Jun 2012 11:45:32 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 11:45:24 +0100
Message-ID: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
parameter. This patch changes the ownership of the buifioreq event channel to
the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).

This fix the initialization of QEMU inside the stubdomain.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 xen/arch/x86/hvm/hvm.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..9ff1ded 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3788,6 +3788,22 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                     /* xchg() ensures that only we free_xen_event_channel() */
                     old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
                     free_xen_event_channel(v, old_port);
+
+                    if ( v->vcpu_id == 0 )
+                    {
+                        new_port = alloc_unbound_xen_event_channel(
+                            v, a.value, NULL);
+                        if ( new_port < 0 )
+                        {
+                            rc = new_port;
+                            break;
+                        }
+                        old_port = xchg(
+                            &v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN],
+                            new_port);
+                        free_xen_event_channel(v, old_port);
+                    }
+
                     spin_lock(&iorp->lock);
                     if ( iorp->va != NULL )
                         get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
-- 
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 Jun 26 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHO-0007PD-1o; Tue, 26 Jun 2012 10:45: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 1SjTHM-0007Oo-S5
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:52 +0000
Received: from [85.158.143.35:42990] by server-2.bemta-4.messagelabs.com id
	1A/1C-17938-0E299EF4; Tue, 26 Jun 2012 10:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340707549!13435099!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23502 invoked from network); 26 Jun 2012 10:45:50 -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;
	26 Jun 2012 10:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051796"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:48 -0400
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 1SjT26-00064E-Ny;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:02 +0000
Message-ID: <1340706604-1313-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 38/40] arm: fix typo
	s/approprately/appropriately/g
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index f3e4d1a..9511c45 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -102,7 +102,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long ng:1;         /* Not-Global */
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz:12;       /* Must be zero */
 
@@ -137,7 +137,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long sbz4:1;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz3:12;
 
@@ -162,7 +162,7 @@ typedef struct {
 
     unsigned long pad2:10;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
 
     unsigned long pad1:24;
-- 
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 Jun 26 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHO-0007PD-1o; Tue, 26 Jun 2012 10:45: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 1SjTHM-0007Oo-S5
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:52 +0000
Received: from [85.158.143.35:42990] by server-2.bemta-4.messagelabs.com id
	1A/1C-17938-0E299EF4; Tue, 26 Jun 2012 10:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340707549!13435099!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23502 invoked from network); 26 Jun 2012 10:45:50 -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;
	26 Jun 2012 10:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051796"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:48 -0400
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 1SjT26-00064E-Ny;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:02 +0000
Message-ID: <1340706604-1313-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 38/40] arm: fix typo
	s/approprately/appropriately/g
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index f3e4d1a..9511c45 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -102,7 +102,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long ng:1;         /* Not-Global */
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz:12;       /* Must be zero */
 
@@ -137,7 +137,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long sbz4:1;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz3:12;
 
@@ -162,7 +162,7 @@ typedef struct {
 
     unsigned long pad2:10;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
 
     unsigned long pad1:24;
-- 
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 Jun 26 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHP-0007Po-Eg; Tue, 26 Jun 2012 10:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTHN-0007P1-L3
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:53 +0000
Received: from [85.158.143.35:43053] by server-3.bemta-4.messagelabs.com id
	B3/B3-05808-0E299EF4; Tue, 26 Jun 2012 10:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340707550!6271714!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19040 invoked from network); 26 Jun 2012 10:45:51 -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;
	26 Jun 2012 10:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427174"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:49 -0400
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 1SjT26-00064E-6C;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:54 +0000
Message-ID: <1340706604-1313-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 30/40] arm: gic.lock can be taken in
	interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 particular it is taken by gic_set_guest_irq which is called by
vgic_vcpu_inject_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 47995b4..1baccba 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -329,19 +329,19 @@ int __init gic_init(void)
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
 void __cpuinit gic_init_secondary_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_init();
     gic_hyp_init();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 /* Shut down the per-CPU GIC interface */
 void gic_disable_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_disable();
     gic_hyp_disable();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 void gic_route_irqs(void)
@@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
 
     events_maintenance(current);
 
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
 
     if ( list_empty(&gic.lr_pending) )
     {
@@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &gic.lr_pending);
 
 out:
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
     return;
 }
 
@@ -557,7 +557,7 @@ static void events_maintenance(struct vcpu *v)
             (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
 
     if (!already_pending && gic.event_mask != 0) {
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
                         sizeof(uint64_t), i)) < sizeof(uint64_t)) {
 
@@ -567,7 +567,7 @@ static void events_maintenance(struct vcpu *v)
 
             i++;
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
     }
 }
 
@@ -583,7 +583,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                               sizeof(eisr), i)) < sizeof(eisr)) {
         struct pending_irq *p;
 
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
@@ -599,7 +599,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         } else {
             gic_inject_irq_stop();
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
 
         spin_lock(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
-- 
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 Jun 26 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHP-0007Po-Eg; Tue, 26 Jun 2012 10:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTHN-0007P1-L3
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:53 +0000
Received: from [85.158.143.35:43053] by server-3.bemta-4.messagelabs.com id
	B3/B3-05808-0E299EF4; Tue, 26 Jun 2012 10:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340707550!6271714!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19040 invoked from network); 26 Jun 2012 10:45:51 -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;
	26 Jun 2012 10:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427174"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:49 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:49 -0400
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 1SjT26-00064E-6C;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:54 +0000
Message-ID: <1340706604-1313-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 30/40] arm: gic.lock can be taken in
	interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 particular it is taken by gic_set_guest_irq which is called by
vgic_vcpu_inject_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 47995b4..1baccba 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -329,19 +329,19 @@ int __init gic_init(void)
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
 void __cpuinit gic_init_secondary_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_init();
     gic_hyp_init();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 /* Shut down the per-CPU GIC interface */
 void gic_disable_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_disable();
     gic_hyp_disable();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 void gic_route_irqs(void)
@@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
 
     events_maintenance(current);
 
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
 
     if ( list_empty(&gic.lr_pending) )
     {
@@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &gic.lr_pending);
 
 out:
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
     return;
 }
 
@@ -557,7 +557,7 @@ static void events_maintenance(struct vcpu *v)
             (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
 
     if (!already_pending && gic.event_mask != 0) {
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
                         sizeof(uint64_t), i)) < sizeof(uint64_t)) {
 
@@ -567,7 +567,7 @@ static void events_maintenance(struct vcpu *v)
 
             i++;
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
     }
 }
 
@@ -583,7 +583,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                               sizeof(eisr), i)) < sizeof(eisr)) {
         struct pending_irq *p;
 
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
@@ -599,7 +599,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         } else {
             gic_inject_irq_stop();
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
 
         spin_lock(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
-- 
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 Jun 26 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHQ-0007QJ-6v; Tue, 26 Jun 2012 10:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTHO-0007PI-JD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:54 +0000
Received: from [85.158.143.35:14038] by server-1.bemta-4.messagelabs.com id
	66/34-24392-1E299EF4; Tue, 26 Jun 2012 10:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340707549!13435099!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23878 invoked from network); 26 Jun 2012 10:45:52 -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;
	26 Jun 2012 10:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051798"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:50 -0400
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 1SjT25-00064E-UO;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:49 +0000
Message-ID: <1340706604-1313-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 25/40] arm: split pending SPIs (global) out
	from pending PPIs and SGIs (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

This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
seems more logical.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c          |   12 +++++++-----
 xen/include/asm-arm/domain.h |   10 ++++++++++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 629a0da..af3523f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.shared_irqs =
         xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     d->arch.vgic.pending_irqs =
-        xmalloc_array(struct pending_irq,
-                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
-    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+    for (i=0; i<d->arch.vgic.nr_lines; i++)
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
@@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     spin_lock_init(&v->arch.vgic.private_irqs.lock);
 
+    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
+    for (i = 0; i < 32; i++)
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+
     /* For SGI and PPI the target is always this CPU */
     for ( i = 0 ; i < 8 ; i++ )
         v->arch.vgic.private_irqs.itargets[i] =
@@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
     /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
-        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
-            + v->domain->arch.vgic.nr_lines];
+        n = &v->arch.vgic.pending_irqs[irq];
     else
         n = &v->domain->arch.vgic.pending_irqs[irq - 32];
     return n;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 620b26e..32deb52 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -46,6 +46,10 @@ struct arch_domain
         int ctlr;
         int nr_lines;
         struct vgic_irq_rank *shared_irqs;
+        /*
+         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
+         * struct arch_vcpu.
+         */
         struct pending_irq *pending_irqs;
     } vgic;
 
@@ -114,7 +118,13 @@ struct arch_vcpu
     uint32_t gic_lr[64];
 
     struct {
+        /*
+         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
+         * struct arch_domain.
+         */
+        struct pending_irq pending_irqs[32];
         struct vgic_irq_rank private_irqs;
+
         /* This list is ordered by IRQ priority and it is used to keep
          * track of the IRQs that the VGIC injected into the guest.
          * Depending on the availability of LR registers, the IRQs might
-- 
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 Jun 26 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHQ-0007QJ-6v; Tue, 26 Jun 2012 10:45:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTHO-0007PI-JD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:54 +0000
Received: from [85.158.143.35:14038] by server-1.bemta-4.messagelabs.com id
	66/34-24392-1E299EF4; Tue, 26 Jun 2012 10:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340707549!13435099!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23878 invoked from network); 26 Jun 2012 10:45:52 -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;
	26 Jun 2012 10:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051798"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:50 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:50 -0400
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 1SjT25-00064E-UO;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:49 +0000
Message-ID: <1340706604-1313-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 25/40] arm: split pending SPIs (global) out
	from pending PPIs and SGIs (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

This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
seems more logical.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c          |   12 +++++++-----
 xen/include/asm-arm/domain.h |   10 ++++++++++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 629a0da..af3523f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.shared_irqs =
         xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     d->arch.vgic.pending_irqs =
-        xmalloc_array(struct pending_irq,
-                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
-    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+    for (i=0; i<d->arch.vgic.nr_lines; i++)
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
@@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     spin_lock_init(&v->arch.vgic.private_irqs.lock);
 
+    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
+    for (i = 0; i < 32; i++)
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+
     /* For SGI and PPI the target is always this CPU */
     for ( i = 0 ; i < 8 ; i++ )
         v->arch.vgic.private_irqs.itargets[i] =
@@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
     /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
-        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
-            + v->domain->arch.vgic.nr_lines];
+        n = &v->arch.vgic.pending_irqs[irq];
     else
         n = &v->domain->arch.vgic.pending_irqs[irq - 32];
     return n;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 620b26e..32deb52 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -46,6 +46,10 @@ struct arch_domain
         int ctlr;
         int nr_lines;
         struct vgic_irq_rank *shared_irqs;
+        /*
+         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
+         * struct arch_vcpu.
+         */
         struct pending_irq *pending_irqs;
     } vgic;
 
@@ -114,7 +118,13 @@ struct arch_vcpu
     uint32_t gic_lr[64];
 
     struct {
+        /*
+         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
+         * struct arch_domain.
+         */
+        struct pending_irq pending_irqs[32];
         struct vgic_irq_rank private_irqs;
+
         /* This list is ordered by IRQ priority and it is used to keep
          * track of the IRQs that the VGIC injected into the guest.
          * Depending on the availability of LR registers, the IRQs might
-- 
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 Jun 26 10:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHP-0007Q7-R0; Tue, 26 Jun 2012 10:45: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 1SjTHO-0007PJ-J1
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:54 +0000
Received: from [193.109.254.147:14892] by server-12.bemta-14.messagelabs.com
	id 15/8E-30461-1E299EF4; Tue, 26 Jun 2012 10:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340707548!890969!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9602 invoked from network); 26 Jun 2012 10:45:49 -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;
	26 Jun 2012 10:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427171"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:48 -0400
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 1SjT25-00064E-PC;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:46 +0000
Message-ID: <1340706604-1313-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 22/40] arm: use correct attributes for
	mappings in copy_from_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

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/page.h  |   15 +++++++++++++++
 xen/include/asm-arm/setup.h |    2 +-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..2d56130 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, attrindx);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d6c0178..fd70553 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 6efe23c..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,13 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
 #define MATTR_DEV     0x1
 #define MATTR_MEM     0xf
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..6433b4e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Jun 26 10:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHP-0007Q7-R0; Tue, 26 Jun 2012 10:45: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 1SjTHO-0007PJ-J1
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:54 +0000
Received: from [193.109.254.147:14892] by server-12.bemta-14.messagelabs.com
	id 15/8E-30461-1E299EF4; Tue, 26 Jun 2012 10:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340707548!890969!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9602 invoked from network); 26 Jun 2012 10:45:49 -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;
	26 Jun 2012 10:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427171"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:48 -0400
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 1SjT25-00064E-PC;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:46 +0000
Message-ID: <1340706604-1313-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 22/40] arm: use correct attributes for
	mappings in copy_from_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

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/page.h  |   15 +++++++++++++++
 xen/include/asm-arm/setup.h |    2 +-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..2d56130 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, attrindx);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d6c0178..fd70553 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 6efe23c..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,13 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
 #define MATTR_DEV     0x1
 #define MATTR_MEM     0xf
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..6433b4e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Jun 26 10:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHR-0007Qt-LO; Tue, 26 Jun 2012 10:45: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 1SjTHP-0007PI-GJ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:55 +0000
Received: from [85.158.143.35:43241] by server-1.bemta-4.messagelabs.com id
	71/44-24392-3E299EF4; Tue, 26 Jun 2012 10:45:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340707550!6271714!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19150 invoked from network); 26 Jun 2012 10:45:54 -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;
	26 Jun 2012 10:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427179"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:53 -0400
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 1SjT25-00064E-MO;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:44 +0000
Message-ID: <1340706604-1313-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 20/40] arm: dump guest s1 walk on data abort
	which is not a stage 2 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   75 +++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/processor.h |    1 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 40bb375..d8eb5a9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -28,6 +28,7 @@
 #include <xen/errno.h>
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
+#include <xen/domain_page.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -528,6 +529,62 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
+void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+{
+    uint32_t ttbcr = READ_CP32(TTBCR);
+    uint32_t ttbr0 = READ_CP32(TTBR0);
+    paddr_t paddr;
+    uint32_t offset;
+    uint32_t *first = NULL, *second = NULL;
+
+    printk("dom%d VA 0x%08"PRIx32"\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));
+
+    if ( ttbcr & TTBCR_EAE )
+    {
+        printk("Cannot handle LPAE guest PT walk\n");
+        return;
+    }
+    if ( (ttbcr & TTBCR_N_MASK) != 0 )
+    {
+        printk("Cannot handle TTBR1 guest walks\n");
+        return;
+    }
+
+    paddr = p2m_lookup(d, ttbr0 & PAGE_MASK);
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed TTBR0 maddr lookup\n");
+        goto done;
+    }
+    first = map_domain_page(paddr>>PAGE_SHIFT);
+
+    offset = addr >> (12+10);
+    printk("1ST[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, first[offset]);
+    if ( !(first[offset] & 0x1) ||
+         !(first[offset] & 0x2) )
+        goto done;
+
+    paddr = p2m_lookup(d, first[offset] & PAGE_MASK);
+
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed L1 entry maddr lookup\n");
+        goto done;
+    }
+    second = map_domain_page(paddr>>PAGE_SHIFT);
+    offset = (addr >> 12) & 0x3FF;
+    printk("2ND[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, second[offset]);
+
+done:
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
                                      struct hsr_dabt dabt)
 {
@@ -535,11 +592,12 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     int level = -1;
     mmio_info_t info;
 
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+
     if (dabt.s1ptw)
         goto bad_data_abort;
 
-    info.dabt = dabt;
-    info.gva = READ_CP32(HDFAR);
     info.gpa = gva_to_ipa(info.gva);
 
     if (handle_mmio(&info))
@@ -553,18 +611,23 @@ bad_data_abort:
     msg = decode_fsc( dabt.dfsc, &level);
 
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           "    gva=%"PRIx32"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
-           info.gva, info.gpa);
-    if (dabt.valid)
+           info.gva);
+    if ( !dabt.s1ptw )
+        printk("    gpa=%"PRIpaddr"\n", info.gpa);
+    if ( dabt.valid )
         printk("    size=%d sign=%d write=%d reg=%d\n",
                dabt.size, dabt.sign, dabt.write, dabt.reg);
     else
         printk("    instruction syndrome invalid\n");
     printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
            dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
-
+    if ( !dabt.s1ptw )
+        dump_p2m_lookup(current->domain, info.gpa);
+    else
+        dump_guest_s1_walk(current->domain, info.gva);
     show_execution_state(regs);
     panic("Unhandled guest data abort\n");
 }
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ec6fb48..81924a4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -25,6 +25,7 @@
 #define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
+#define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
 #define TTBCR_N_16KB 0x00
 #define TTBCR_N_8KB  0x01
-- 
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 Jun 26 10:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHR-0007Qt-LO; Tue, 26 Jun 2012 10:45: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 1SjTHP-0007PI-GJ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:55 +0000
Received: from [85.158.143.35:43241] by server-1.bemta-4.messagelabs.com id
	71/44-24392-3E299EF4; Tue, 26 Jun 2012 10:45:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340707550!6271714!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19150 invoked from network); 26 Jun 2012 10:45:54 -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;
	26 Jun 2012 10:45:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427179"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:53 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:53 -0400
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 1SjT25-00064E-MO;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:44 +0000
Message-ID: <1340706604-1313-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 20/40] arm: dump guest s1 walk on data abort
	which is not a stage 2 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   75 +++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/processor.h |    1 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 40bb375..d8eb5a9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -28,6 +28,7 @@
 #include <xen/errno.h>
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
+#include <xen/domain_page.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -528,6 +529,62 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
+void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+{
+    uint32_t ttbcr = READ_CP32(TTBCR);
+    uint32_t ttbr0 = READ_CP32(TTBR0);
+    paddr_t paddr;
+    uint32_t offset;
+    uint32_t *first = NULL, *second = NULL;
+
+    printk("dom%d VA 0x%08"PRIx32"\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));
+
+    if ( ttbcr & TTBCR_EAE )
+    {
+        printk("Cannot handle LPAE guest PT walk\n");
+        return;
+    }
+    if ( (ttbcr & TTBCR_N_MASK) != 0 )
+    {
+        printk("Cannot handle TTBR1 guest walks\n");
+        return;
+    }
+
+    paddr = p2m_lookup(d, ttbr0 & PAGE_MASK);
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed TTBR0 maddr lookup\n");
+        goto done;
+    }
+    first = map_domain_page(paddr>>PAGE_SHIFT);
+
+    offset = addr >> (12+10);
+    printk("1ST[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, first[offset]);
+    if ( !(first[offset] & 0x1) ||
+         !(first[offset] & 0x2) )
+        goto done;
+
+    paddr = p2m_lookup(d, first[offset] & PAGE_MASK);
+
+    if ( paddr == INVALID_PADDR )
+    {
+        printk("Failed L1 entry maddr lookup\n");
+        goto done;
+    }
+    second = map_domain_page(paddr>>PAGE_SHIFT);
+    offset = (addr >> 12) & 0x3FF;
+    printk("2ND[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
+           offset, paddr, second[offset]);
+
+done:
+    if (second) unmap_domain_page(second);
+    if (first) unmap_domain_page(first);
+}
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
                                      struct hsr_dabt dabt)
 {
@@ -535,11 +592,12 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     int level = -1;
     mmio_info_t info;
 
+    info.dabt = dabt;
+    info.gva = READ_CP32(HDFAR);
+
     if (dabt.s1ptw)
         goto bad_data_abort;
 
-    info.dabt = dabt;
-    info.gva = READ_CP32(HDFAR);
     info.gpa = gva_to_ipa(info.gva);
 
     if (handle_mmio(&info))
@@ -553,18 +611,23 @@ bad_data_abort:
     msg = decode_fsc( dabt.dfsc, &level);
 
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32" gpa=%"PRIpaddr"\n",
+           "    gva=%"PRIx32"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
-           info.gva, info.gpa);
-    if (dabt.valid)
+           info.gva);
+    if ( !dabt.s1ptw )
+        printk("    gpa=%"PRIpaddr"\n", info.gpa);
+    if ( dabt.valid )
         printk("    size=%d sign=%d write=%d reg=%d\n",
                dabt.size, dabt.sign, dabt.write, dabt.reg);
     else
         printk("    instruction syndrome invalid\n");
     printk("    eat=%d cm=%d s1ptw=%d dfsc=%d\n",
            dabt.eat, dabt.cache, dabt.s1ptw, dabt.dfsc);
-
+    if ( !dabt.s1ptw )
+        dump_p2m_lookup(current->domain, info.gpa);
+    else
+        dump_guest_s1_walk(current->domain, info.gva);
     show_execution_state(regs);
     panic("Unhandled guest data abort\n");
 }
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ec6fb48..81924a4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -25,6 +25,7 @@
 #define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
+#define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
 #define TTBCR_N_16KB 0x00
 #define TTBCR_N_8KB  0x01
-- 
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 Jun 26 10:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHU-0007SW-7i; Tue, 26 Jun 2012 10:46: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 1SjTHT-0007PI-AH
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:59 +0000
Received: from [85.158.143.99:24932] by server-1.bemta-4.messagelabs.com id
	32/64-24392-7E299EF4; Tue, 26 Jun 2012 10:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340707555!28846324!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 26 Jun 2012 10:45:56 -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;
	26 Jun 2012 10:45:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:54 -0400
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 1SjT25-00064E-6K;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:35 +0000
Message-ID: <1340706604-1313-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 11/40] arm: remove hard tabs from
	init_idle_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.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 0df3c1a..81ababb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,9 +47,9 @@ static __attribute_used__ void init_done(void)
 
 static void __init init_idle_domain(void)
 {
-        scheduler_init();
-        set_current(idle_vcpu[0]);
-        /* TODO: setup_idle_pagetable(); */
+    scheduler_init();
+    set_current(idle_vcpu[0]);
+    /* TODO: setup_idle_pagetable(); */
 }
 
 static void __init processor_id(void)
-- 
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 Jun 26 10:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHU-0007SW-7i; Tue, 26 Jun 2012 10:46: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 1SjTHT-0007PI-AH
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:59 +0000
Received: from [85.158.143.99:24932] by server-1.bemta-4.messagelabs.com id
	32/64-24392-7E299EF4; Tue, 26 Jun 2012 10:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340707555!28846324!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 26 Jun 2012 10:45:56 -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;
	26 Jun 2012 10:45:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:54 -0400
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 1SjT25-00064E-6K;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:35 +0000
Message-ID: <1340706604-1313-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 11/40] arm: remove hard tabs from
	init_idle_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.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 0df3c1a..81ababb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,9 +47,9 @@ static __attribute_used__ void init_done(void)
 
 static void __init init_idle_domain(void)
 {
-        scheduler_init();
-        set_current(idle_vcpu[0]);
-        /* TODO: setup_idle_pagetable(); */
+    scheduler_init();
+    set_current(idle_vcpu[0]);
+    /* TODO: setup_idle_pagetable(); */
 }
 
 static void __init processor_id(void)
-- 
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 Jun 26 10:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHU-0007TE-L5; Tue, 26 Jun 2012 10:46: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 1SjTHT-0007PI-Mp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:59 +0000
Received: from [85.158.143.99:25032] by server-1.bemta-4.messagelabs.com id
	67/64-24392-7E299EF4; Tue, 26 Jun 2012 10:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340707555!28846324!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20547 invoked from network); 26 Jun 2012 10:45:58 -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;
	26 Jun 2012 10:45:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427186"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:56 -0400
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 1SjT25-00064E-Jr;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:43 +0000
Message-ID: <1340706604-1313-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 19/40] arm: dump a page table walk when
	va_to_par 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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/page.h |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 2783c30..6efe23c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -296,7 +296,11 @@ static inline uint64_t va_to_par(uint32_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
-    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    if ( par & PAR_F )
+    {
+        dump_hyp_walk(va);
+        panic_PAR(par, "Hypervisor");
+    }
     return par;
 }
 
-- 
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 Jun 26 10:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHU-0007TE-L5; Tue, 26 Jun 2012 10:46: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 1SjTHT-0007PI-Mp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:45:59 +0000
Received: from [85.158.143.99:25032] by server-1.bemta-4.messagelabs.com id
	67/64-24392-7E299EF4; Tue, 26 Jun 2012 10:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340707555!28846324!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20547 invoked from network); 26 Jun 2012 10:45:58 -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;
	26 Jun 2012 10:45:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427186"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:56 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:56 -0400
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 1SjT25-00064E-Jr;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:43 +0000
Message-ID: <1340706604-1313-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 19/40] arm: dump a page table walk when
	va_to_par 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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/page.h |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 2783c30..6efe23c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -296,7 +296,11 @@ static inline uint64_t va_to_par(uint32_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
-    if ( par & PAR_F ) panic_PAR(par, "Hypervisor");
+    if ( par & PAR_F )
+    {
+        dump_hyp_walk(va);
+        panic_PAR(par, "Hypervisor");
+    }
     return par;
 }
 
-- 
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 Jun 26 10:46:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTHY-0007Xj-Te; Tue, 26 Jun 2012 10:46: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 1SjTHX-0007Vo-Dj
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:03 +0000
Received: from [85.158.143.99:45249] by server-3.bemta-4.messagelabs.com id
	38/F3-05808-AE299EF4; Tue, 26 Jun 2012 10:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340707560!25800940!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32277 invoked from network); 26 Jun 2012 10:46:01 -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;
	26 Jun 2012 10:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427195"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:59 -0400
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 1SjT26-00064E-0g;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:50 +0000
Message-ID: <1340706604-1313-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 26/40] arm: use interrupt safe spin locks in
	vgic_vcpu_inject_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

This function can be called in both interrupt and regular context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..91d6166 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
@@ -577,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Jun 26 10:46:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTHY-0007Xj-Te; Tue, 26 Jun 2012 10:46: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 1SjTHX-0007Vo-Dj
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:03 +0000
Received: from [85.158.143.99:45249] by server-3.bemta-4.messagelabs.com id
	38/F3-05808-AE299EF4; Tue, 26 Jun 2012 10:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340707560!25800940!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32277 invoked from network); 26 Jun 2012 10:46:01 -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;
	26 Jun 2012 10:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427195"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:59 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:59 -0400
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 1SjT26-00064E-0g;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:50 +0000
Message-ID: <1340706604-1313-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 26/40] arm: use interrupt safe spin locks in
	vgic_vcpu_inject_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

This function can be called in both interrupt and regular context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/vgic.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..91d6166 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
@@ -577,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Jun 26 10:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHY-0007XG-F3; Tue, 26 Jun 2012 10:46: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 1SjTHV-0007S4-QI
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:01 +0000
Received: from [85.158.138.51:24000] by server-3.bemta-3.messagelabs.com id
	6B/42-26490-7E299EF4; Tue, 26 Jun 2012 10:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340707556!28465970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21164 invoked from network); 26 Jun 2012 10:45:58 -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;
	26 Jun 2012 10:45:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427188"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:57 -0400
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 1SjT25-00064E-QW;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:47 +0000
Message-ID: <1340706604-1313-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 23/40] arm: map fixmaps non-executable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/mm.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 715a98a..40ac176 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -106,6 +106,7 @@ void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
     lpae_t pte = mfn_to_xen_entry(mfn);
     pte.pt.table = 1; /* 4k mappings always have this bit set */
     pte.pt.ai = attributes;
+    pte.pt.xn = 1;
     write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
     flush_xen_data_tlb_va(FIXMAP_ADDR(map));
 }
-- 
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 Jun 26 10:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHY-0007XG-F3; Tue, 26 Jun 2012 10:46: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 1SjTHV-0007S4-QI
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:01 +0000
Received: from [85.158.138.51:24000] by server-3.bemta-3.messagelabs.com id
	6B/42-26490-7E299EF4; Tue, 26 Jun 2012 10:45:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340707556!28465970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21164 invoked from network); 26 Jun 2012 10:45:58 -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;
	26 Jun 2012 10:45:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427188"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:57 -0400
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 1SjT25-00064E-QW;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:47 +0000
Message-ID: <1340706604-1313-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 23/40] arm: map fixmaps non-executable.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/mm.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 715a98a..40ac176 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -106,6 +106,7 @@ void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
     lpae_t pte = mfn_to_xen_entry(mfn);
     pte.pt.table = 1; /* 4k mappings always have this bit set */
     pte.pt.ai = attributes;
+    pte.pt.xn = 1;
     write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
     flush_xen_data_tlb_va(FIXMAP_ADDR(map));
 }
-- 
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 Jun 26 10:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHX-0007Vt-25; Tue, 26 Jun 2012 10:46:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTHV-0007Tl-FO
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:01 +0000
Received: from [193.109.254.147:15600] by server-12.bemta-14.messagelabs.com
	id 90/BE-30461-8E299EF4; Tue, 26 Jun 2012 10:46:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340707548!890969!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9821 invoked from network); 26 Jun 2012 10:45:52 -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;
	26 Jun 2012 10:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427177"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:51 -0400
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 1SjT26-00064E-D2;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:57 +0000
Message-ID: <1340706604-1313-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 33/40] arm: unwind allocations etc on
	arch_domain_create_failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding the necessary teardown/free functions for some modules.

Don't initialise full arch domain state for the idle domain, it's not needed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c     |   42 +++++++++++++++++++++++++-----------------
 xen/arch/arm/gic.h        |    3 +++
 xen/arch/arm/p2m.c        |   15 +++++++++++++++
 xen/arch/arm/vgic.c       |    6 ++++++
 xen/arch/arm/vpl011.c     |    5 +++++
 xen/arch/arm/vpl011.h     |    1 +
 xen/include/asm-arm/p2m.h |    3 +++
 7 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2b5515d..ac6a30d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -317,37 +317,45 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    /* Idle domains do not need this setup */
+    if ( is_idle_domain(d) )
+        return 0;
+
     rc = -ENOMEM;
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
-    if ( !is_idle_domain(d) )
-    {
-        rc = -ENOMEM;
-        if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
-            goto fail;
+    if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
+        goto fail;
 
-        clear_page(d->shared_info);
-        share_xen_page_with_guest(
-                virt_to_page(d->shared_info), d, XENSHARE_writable);
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+        virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-        if ( (rc = p2m_alloc_table(d)) != 0 )
-            goto fail;
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        goto fail;
 
-        if ( (rc = gicv_setup(d)) != 0 )
-            goto fail;
+    if ( (rc = gicv_setup(d)) != 0 )
+        goto fail;
 
-        if ( (rc = domain_vgic_init(d)) != 0 )
-            goto fail;
-    }
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
         goto fail;
 
-    rc = 0;
+    return 0;
+
 fail:
-    /*XXX unwind allocations etc */
+    d->is_dying = DOMDYING_dead;
+    free_xenheap_page(d->shared_info);
+
+    p2m_teardown(d);
+
+    domain_vgic_free(d);
+    domain_uart0_free(d);
+
     return rc;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 018d820..e36d6ad 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -125,7 +125,10 @@
 #define VGIC_IRQ_EVTCHN_CALLBACK 31
 
 extern int domain_vgic_init(struct domain *d);
+extern void domain_vgic_free(struct domain *d);
+
 extern int vcpu_vgic_init(struct vcpu *v);
+
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 67bfeba..073216b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -288,6 +288,21 @@ int p2m_alloc_table(struct domain *d)
     return 0;
 }
 
+void p2m_teardown(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *pg;
+
+    spin_lock(&p2m->lock);
+
+    while ( (pg = page_list_remove_head(&p2m->pages)) )
+        free_domheap_page(pg);
+
+    p2m->first_level = NULL;
+
+    spin_unlock(&p2m->lock);
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 91d6166..06bbd0c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,12 @@ int domain_vgic_init(struct domain *d)
     return 0;
 }
 
+void domain_vgic_free(struct domain *d)
+{
+    xfree(d->arch.vgic.shared_irqs);
+    xfree(d->arch.vgic.pending_irqs);
+}
+
 int vcpu_vgic_init(struct vcpu *v)
 {
     int i;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dc8b28..1522667 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -56,6 +56,11 @@ int domain_uart0_init(struct domain *d)
 
 }
 
+void domain_uart0_free(struct domain *d)
+{
+    xfree(d->arch.uart0.buf);
+}
+
 static void uart0_print_char(char c)
 {
     struct vpl011 *uart = &current->domain->arch.uart0;
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
index 952d812..eabd99d 100644
--- a/xen/arch/arm/vpl011.h
+++ b/xen/arch/arm/vpl011.h
@@ -21,6 +21,7 @@
 #define __ARCH_ARM_VPL011_H__
 
 extern int domain_uart0_init(struct domain *d);
+extern void domain_uart0_free(struct domain *d);
 
 #endif
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 666bb88..14e71bf 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,6 +23,9 @@ struct p2m_domain {
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 
+/* Return all the p2m resources to Xen. */
+void p2m_teardown(struct domain *d);
+
 /* Allocate a new p2m table for a domain.
  *
  * Returns 0 for success or -errno.
-- 
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 Jun 26 10:46:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHX-0007Vt-25; Tue, 26 Jun 2012 10:46:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTHV-0007Tl-FO
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:01 +0000
Received: from [193.109.254.147:15600] by server-12.bemta-14.messagelabs.com
	id 90/BE-30461-8E299EF4; Tue, 26 Jun 2012 10:46:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340707548!890969!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9821 invoked from network); 26 Jun 2012 10:45:52 -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;
	26 Jun 2012 10:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427177"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:51 -0400
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 1SjT26-00064E-D2;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:57 +0000
Message-ID: <1340706604-1313-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 33/40] arm: unwind allocations etc on
	arch_domain_create_failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding the necessary teardown/free functions for some modules.

Don't initialise full arch domain state for the idle domain, it's not needed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c     |   42 +++++++++++++++++++++++++-----------------
 xen/arch/arm/gic.h        |    3 +++
 xen/arch/arm/p2m.c        |   15 +++++++++++++++
 xen/arch/arm/vgic.c       |    6 ++++++
 xen/arch/arm/vpl011.c     |    5 +++++
 xen/arch/arm/vpl011.h     |    1 +
 xen/include/asm-arm/p2m.h |    3 +++
 7 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2b5515d..ac6a30d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -317,37 +317,45 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    /* Idle domains do not need this setup */
+    if ( is_idle_domain(d) )
+        return 0;
+
     rc = -ENOMEM;
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
-    if ( !is_idle_domain(d) )
-    {
-        rc = -ENOMEM;
-        if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
-            goto fail;
+    if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
+        goto fail;
 
-        clear_page(d->shared_info);
-        share_xen_page_with_guest(
-                virt_to_page(d->shared_info), d, XENSHARE_writable);
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+        virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-        if ( (rc = p2m_alloc_table(d)) != 0 )
-            goto fail;
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        goto fail;
 
-        if ( (rc = gicv_setup(d)) != 0 )
-            goto fail;
+    if ( (rc = gicv_setup(d)) != 0 )
+        goto fail;
 
-        if ( (rc = domain_vgic_init(d)) != 0 )
-            goto fail;
-    }
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
         goto fail;
 
-    rc = 0;
+    return 0;
+
 fail:
-    /*XXX unwind allocations etc */
+    d->is_dying = DOMDYING_dead;
+    free_xenheap_page(d->shared_info);
+
+    p2m_teardown(d);
+
+    domain_vgic_free(d);
+    domain_uart0_free(d);
+
     return rc;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 018d820..e36d6ad 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -125,7 +125,10 @@
 #define VGIC_IRQ_EVTCHN_CALLBACK 31
 
 extern int domain_vgic_init(struct domain *d);
+extern void domain_vgic_free(struct domain *d);
+
 extern int vcpu_vgic_init(struct vcpu *v);
+
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 67bfeba..073216b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -288,6 +288,21 @@ int p2m_alloc_table(struct domain *d)
     return 0;
 }
 
+void p2m_teardown(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *pg;
+
+    spin_lock(&p2m->lock);
+
+    while ( (pg = page_list_remove_head(&p2m->pages)) )
+        free_domheap_page(pg);
+
+    p2m->first_level = NULL;
+
+    spin_unlock(&p2m->lock);
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 91d6166..06bbd0c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,12 @@ int domain_vgic_init(struct domain *d)
     return 0;
 }
 
+void domain_vgic_free(struct domain *d)
+{
+    xfree(d->arch.vgic.shared_irqs);
+    xfree(d->arch.vgic.pending_irqs);
+}
+
 int vcpu_vgic_init(struct vcpu *v)
 {
     int i;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dc8b28..1522667 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -56,6 +56,11 @@ int domain_uart0_init(struct domain *d)
 
 }
 
+void domain_uart0_free(struct domain *d)
+{
+    xfree(d->arch.uart0.buf);
+}
+
 static void uart0_print_char(char c)
 {
     struct vpl011 *uart = &current->domain->arch.uart0;
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
index 952d812..eabd99d 100644
--- a/xen/arch/arm/vpl011.h
+++ b/xen/arch/arm/vpl011.h
@@ -21,6 +21,7 @@
 #define __ARCH_ARM_VPL011_H__
 
 extern int domain_uart0_init(struct domain *d);
+extern void domain_uart0_free(struct domain *d);
 
 #endif
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 666bb88..14e71bf 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,6 +23,9 @@ struct p2m_domain {
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 
+/* Return all the p2m resources to Xen. */
+void p2m_teardown(struct domain *d);
+
 /* Allocate a new p2m table for a domain.
  *
  * Returns 0 for success or -errno.
-- 
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 Jun 26 10:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHa-0007ZU-AU; Tue, 26 Jun 2012 10:46: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 1SjTHY-0007XE-RI
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:05 +0000
Received: from [85.158.143.99:25480] by server-2.bemta-4.messagelabs.com id
	72/7C-17938-CE299EF4; Tue, 26 Jun 2012 10:46:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340707560!25800940!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32442 invoked from network); 26 Jun 2012 10:46:03 -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;
	26 Jun 2012 10:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427202"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:01 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:01 -0400
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 1SjT25-00064E-FS;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:40 +0000
Message-ID: <1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 16/40] arm: allow p2m to be created with
	specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename p2m_create_entry to p2m_create_table since it can now only be used to
insert non-leaf entries into the page table.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c         |   22 ++++++++++++----------
 xen/include/asm-arm/page.h |    6 ++++--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ec41d38..35bfa2f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
     return -ENOSYS;
 }
 
-static int p2m_create_entry(struct domain *d,
+/* Allocate a new page table page and hook it in via the given entry */
+static int p2m_create_table(struct domain *d,
                             lpae_t *entry)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -140,7 +142,7 @@ static int create_p2m_entries(struct domain *d,
     {
         if ( !first[first_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L1 failed\n");
                 goto out;
@@ -159,7 +161,7 @@ static int create_p2m_entries(struct domain *d,
 
         if ( !second[second_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L2 failed\n");
                 goto out;
@@ -198,11 +200,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 183ba5f..2783c30 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -46,6 +46,8 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -187,7 +189,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -196,7 +198,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Jun 26 10:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHa-0007ZU-AU; Tue, 26 Jun 2012 10:46: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 1SjTHY-0007XE-RI
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:05 +0000
Received: from [85.158.143.99:25480] by server-2.bemta-4.messagelabs.com id
	72/7C-17938-CE299EF4; Tue, 26 Jun 2012 10:46:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340707560!25800940!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32442 invoked from network); 26 Jun 2012 10:46:03 -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;
	26 Jun 2012 10:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427202"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:01 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:01 -0400
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 1SjT25-00064E-FS;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:40 +0000
Message-ID: <1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 16/40] arm: allow p2m to be created with
	specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename p2m_create_entry to p2m_create_table since it can now only be used to
insert non-leaf entries into the page table.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/p2m.c         |   22 ++++++++++++----------
 xen/include/asm-arm/page.h |    6 ++++--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ec41d38..35bfa2f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
     return -ENOSYS;
 }
 
-static int p2m_create_entry(struct domain *d,
+/* Allocate a new page table page and hook it in via the given entry */
+static int p2m_create_table(struct domain *d,
                             lpae_t *entry)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -140,7 +142,7 @@ static int create_p2m_entries(struct domain *d,
     {
         if ( !first[first_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L1 failed\n");
                 goto out;
@@ -159,7 +161,7 @@ static int create_p2m_entries(struct domain *d,
 
         if ( !second[second_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L2 failed\n");
                 goto out;
@@ -198,11 +200,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 183ba5f..2783c30 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -46,6 +46,8 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -187,7 +189,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -196,7 +198,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Jun 26 10:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTHb-0007bm-O4; Tue, 26 Jun 2012 10:46: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 1SjTHa-0007Yx-9o
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:06 +0000
Received: from [85.158.143.99:45447] by server-1.bemta-4.messagelabs.com id
	0F/94-24392-DE299EF4; Tue, 26 Jun 2012 10:46:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340707560!25800940!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32716 invoked from network); 26 Jun 2012 10:46:04 -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;
	26 Jun 2012 10:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427214"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:03 -0400
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 1SjT25-00064E-AB;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:37 +0000
Message-ID: <1340706604-1313-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 13/40] arm: implement stub version of
	flush_tlb_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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/smp.c   |    9 +++++++++
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 8eddd15..c001e8d 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -48,7 +48,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(flush_tlb_mask);
 DUMMY(gmfn_to_mfn);
 DUMMY(hypercall_create_continuation);
 DUMMY(send_timer_event);
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
index cad84f5..824c8c8 100644
--- a/xen/arch/arm/smp.c
+++ b/xen/arch/arm/smp.c
@@ -1,5 +1,14 @@
 #include <xen/config.h>
+#include <asm/system.h>
 #include <asm/smp.h>
+#include <asm/cpregs.h>
+#include <asm/page.h>
+
+void flush_tlb_mask(const cpumask_t *mask)
+{
+    /* XXX IPI other processors */
+    flush_xen_data_tlb();
+}
 
 void smp_call_function(
     void (*func) (void *info),
-- 
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 Jun 26 10:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTHb-0007bm-O4; Tue, 26 Jun 2012 10:46: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 1SjTHa-0007Yx-9o
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:06 +0000
Received: from [85.158.143.99:45447] by server-1.bemta-4.messagelabs.com id
	0F/94-24392-DE299EF4; Tue, 26 Jun 2012 10:46:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340707560!25800940!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32716 invoked from network); 26 Jun 2012 10:46:04 -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;
	26 Jun 2012 10:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427214"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:03 -0400
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 1SjT25-00064E-AB;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:37 +0000
Message-ID: <1340706604-1313-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 13/40] arm: implement stub version of
	flush_tlb_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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/smp.c   |    9 +++++++++
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 8eddd15..c001e8d 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -48,7 +48,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(flush_tlb_mask);
 DUMMY(gmfn_to_mfn);
 DUMMY(hypercall_create_continuation);
 DUMMY(send_timer_event);
diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
index cad84f5..824c8c8 100644
--- a/xen/arch/arm/smp.c
+++ b/xen/arch/arm/smp.c
@@ -1,5 +1,14 @@
 #include <xen/config.h>
+#include <asm/system.h>
 #include <asm/smp.h>
+#include <asm/cpregs.h>
+#include <asm/page.h>
+
+void flush_tlb_mask(const cpumask_t *mask)
+{
+    /* XXX IPI other processors */
+    flush_xen_data_tlb();
+}
 
 void smp_call_function(
     void (*func) (void *info),
-- 
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 Jun 26 10:46:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTHe-0007gU-E6; Tue, 26 Jun 2012 10:46: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 1SjTHc-0007cB-HM
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:08 +0000
Received: from [85.158.138.51:25027] by server-9.bemta-3.messagelabs.com id
	B3/0F-10419-FE299EF4; Tue, 26 Jun 2012 10:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340707562!25533891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2214 invoked from network); 26 Jun 2012 10:46:03 -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;
	26 Jun 2012 10:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427211"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:03 -0400
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 1SjT25-00064E-Gr;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:41 +0000
Message-ID: <1340706604-1313-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 17/40] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    5 ++
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  145 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 ++++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 63bad07..931261b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    /* Domain 0 gets a real UART not an emulated one */
+    if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..5dc8b28
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,145 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_START 0x1c090000
+#define UART0_END   (UART0_START+65536)
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    ASSERT( d->domain_id );
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        return -ENOMEM;
+
+    return 0;
+
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= UART0_START && addr < UART0_END;
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        /* ignore any status bits */
+        uart0_print_char((int)((*r) & 0xFF));
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 10ed540..f295a82 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Jun 26 10:46:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTHe-0007gU-E6; Tue, 26 Jun 2012 10:46: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 1SjTHc-0007cB-HM
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:08 +0000
Received: from [85.158.138.51:25027] by server-9.bemta-3.messagelabs.com id
	B3/0F-10419-FE299EF4; Tue, 26 Jun 2012 10:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340707562!25533891!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2214 invoked from network); 26 Jun 2012 10:46:03 -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;
	26 Jun 2012 10:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427211"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:03 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:03 -0400
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 1SjT25-00064E-Gr;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:41 +0000
Message-ID: <1340706604-1313-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 17/40] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    5 ++
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  145 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 ++++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 63bad07..931261b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -215,6 +216,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    /* Domain 0 gets a real UART not an emulated one */
+    if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..5dc8b28
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,145 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_START 0x1c090000
+#define UART0_END   (UART0_START+65536)
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    ASSERT( d->domain_id );
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        return -ENOMEM;
+
+    return 0;
+
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= UART0_START && addr < UART0_END;
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        /* ignore any status bits */
+        uart0_print_char((int)((*r) & 0xFF));
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 10ed540..f295a82 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Jun 26 10:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHf-0007iC-AG; Tue, 26 Jun 2012 10:46: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 1SjTHd-0007cB-Ci
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:09 +0000
Received: from [85.158.138.51:3851] by server-9.bemta-3.messagelabs.com id
	55/1F-10419-1F299EF4; Tue, 26 Jun 2012 10:46:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340707566!21483443!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7509 invoked from network); 26 Jun 2012 10:46:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427224"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:05 -0400
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 1SjT26-00064E-4n;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:53 +0000
Message-ID: <1340706604-1313-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 29/40] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Upgrading barriers is conservative and may not be necessary.

Protected Table Walk traps stage 1 page tables which refer to device memory
(per stage 2) using a non-device mapping. This generally indicates a guest
error but trapping it as a fault for now helps us know if something odd is
going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c     |    2 +-
 xen/include/asm-arm/processor.h |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1b19e54..a9e7f43 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -333,7 +333,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 81924a4..9b3c9dd 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -76,6 +76,10 @@
 #define HCR_TWI         (1<<13)
 #define HCR_DC          (1<<12)
 #define HCR_BSU_MASK    (3<<10)
+#define HCR_BSU_NONE     (0<<10)
+#define HCR_BSU_INNER    (1<<10)
+#define HCR_BSU_OUTER    (2<<10)
+#define HCR_BSU_FULL     (3<<10)
 #define HCR_FB          (1<<9)
 #define HCR_VA          (1<<8)
 #define HCR_VI          (1<<7)
-- 
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 Jun 26 10:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHf-0007iC-AG; Tue, 26 Jun 2012 10:46: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 1SjTHd-0007cB-Ci
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:09 +0000
Received: from [85.158.138.51:3851] by server-9.bemta-3.messagelabs.com id
	55/1F-10419-1F299EF4; Tue, 26 Jun 2012 10:46:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340707566!21483443!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7509 invoked from network); 26 Jun 2012 10:46:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427224"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:05 -0400
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 1SjT26-00064E-4n;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:53 +0000
Message-ID: <1340706604-1313-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 29/40] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Upgrading barriers is conservative and may not be necessary.

Protected Table Walk traps stage 1 page tables which refer to device memory
(per stage 2) using a non-device mapping. This generally indicates a guest
error but trapping it as a fault for now helps us know if something odd is
going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c     |    2 +-
 xen/include/asm-arm/processor.h |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1b19e54..a9e7f43 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -333,7 +333,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 81924a4..9b3c9dd 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -76,6 +76,10 @@
 #define HCR_TWI         (1<<13)
 #define HCR_DC          (1<<12)
 #define HCR_BSU_MASK    (3<<10)
+#define HCR_BSU_NONE     (0<<10)
+#define HCR_BSU_INNER    (1<<10)
+#define HCR_BSU_OUTER    (2<<10)
+#define HCR_BSU_FULL     (3<<10)
 #define HCR_FB          (1<<9)
 #define HCR_VA          (1<<8)
 #define HCR_VI          (1<<7)
-- 
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 Jun 26 10:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHe-0007hI-Sk; Tue, 26 Jun 2012 10:46: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 1SjTHd-0007dd-7j
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:09 +0000
Received: from [85.158.138.51:25111] by server-2.bemta-3.messagelabs.com id
	C0/27-10266-0F299EF4; Tue, 26 Jun 2012 10:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340707566!21483443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7463 invoked from network); 26 Jun 2012 10:46:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427223"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:05 -0400
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 1SjT26-00064E-PK;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:03 +0000
Message-ID: <1340706604-1313-39-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 39/40] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on init-xenstore-domain.c.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xcutils/Makefile  |    6 ++-
 tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 tools/xcutils/xcbuild.c

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 6c502f1..dcd2c84 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -11,7 +11,7 @@
 XEN_ROOT	= $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-PROGRAMS = xc_restore xc_save readnotes lsevtchn
+PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
 
 CFLAGS += -Werror
 
@@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 
 .PHONY: all
 all: build
@@ -32,6 +33,9 @@ xc_restore: xc_restore.o
 xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xcbuild: xcbuild.o
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
 
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
new file mode 100644
index 0000000..54f5c38
--- /dev/null
+++ b/tools/xcutils/xcbuild.c
@@ -0,0 +1,100 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#include <errno.h>
+
+#include <xenctrl.h>
+#include <xentoollog.h>
+#include <xc_dom.h>
+
+int main(int argc, char **argv)
+{
+	xentoollog_logger *logger;
+	xc_interface *xch;
+	int rv;
+	const char *image;
+	uint32_t domid;
+	xen_domain_handle_t handle;
+	int maxmem = 128; /* MB */
+	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
+	struct xc_dom_image *dom;
+
+	image = (argc < 2) ? "guest.img" : argv[1];
+	printf("Image: %s\n", image);
+	printf("Memory: %dKB\n", memory_kb);
+
+	logger = (xentoollog_logger*)
+		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
+	if ( logger == NULL )
+	{
+		perror("xtl_createlogger_stdiostream");
+		exit(1);
+	}
+
+	xch = xc_interface_open(logger, logger, 0);
+	if ( xch == NULL )
+	{
+		perror("xc_interface_open");
+		exit(1);
+	}
+
+	rv = xc_dom_loginit(xch);
+	if (rv) return rv;
+
+	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	//if (rv) return rv;
+
+	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
+	printf("xc_domain_create: %d (%d)\n", rv, errno);
+	if ( rv < 0 )
+	{
+		perror("xc_domain_create");
+		exit(1);
+	}
+
+	printf("building dom%d\n", domid);
+
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if ( rv < 0)
+	{
+		perror("xc_domain_max_vcpus");
+		exit(1);
+	}
+
+	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
+	if ( rv < 0)
+	{
+		perror("xc_domain_setmaxmem");
+		exit(1);
+	}
+
+	dom = xc_dom_allocate(xch, "", NULL);
+	rv = xc_dom_kernel_file(dom, image);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_unpause(xch, domid);
+	if ( rv )
+	{
+		perror("xc_domain_unpause");
+		exit(1);
+	}
+
+	xc_interface_close(xch);
+
+	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 Tue Jun 26 10:46:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTHe-0007hI-Sk; Tue, 26 Jun 2012 10:46: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 1SjTHd-0007dd-7j
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:09 +0000
Received: from [85.158.138.51:25111] by server-2.bemta-3.messagelabs.com id
	C0/27-10266-0F299EF4; Tue, 26 Jun 2012 10:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340707566!21483443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7463 invoked from network); 26 Jun 2012 10:46:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427223"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:05 -0400
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 1SjT26-00064E-PK;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:03 +0000
Message-ID: <1340706604-1313-39-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 39/40] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on init-xenstore-domain.c.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xcutils/Makefile  |    6 ++-
 tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 tools/xcutils/xcbuild.c

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 6c502f1..dcd2c84 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -11,7 +11,7 @@
 XEN_ROOT	= $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-PROGRAMS = xc_restore xc_save readnotes lsevtchn
+PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
 
 CFLAGS += -Werror
 
@@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 
 .PHONY: all
 all: build
@@ -32,6 +33,9 @@ xc_restore: xc_restore.o
 xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xcbuild: xcbuild.o
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
 
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
new file mode 100644
index 0000000..54f5c38
--- /dev/null
+++ b/tools/xcutils/xcbuild.c
@@ -0,0 +1,100 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#include <errno.h>
+
+#include <xenctrl.h>
+#include <xentoollog.h>
+#include <xc_dom.h>
+
+int main(int argc, char **argv)
+{
+	xentoollog_logger *logger;
+	xc_interface *xch;
+	int rv;
+	const char *image;
+	uint32_t domid;
+	xen_domain_handle_t handle;
+	int maxmem = 128; /* MB */
+	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
+	struct xc_dom_image *dom;
+
+	image = (argc < 2) ? "guest.img" : argv[1];
+	printf("Image: %s\n", image);
+	printf("Memory: %dKB\n", memory_kb);
+
+	logger = (xentoollog_logger*)
+		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
+	if ( logger == NULL )
+	{
+		perror("xtl_createlogger_stdiostream");
+		exit(1);
+	}
+
+	xch = xc_interface_open(logger, logger, 0);
+	if ( xch == NULL )
+	{
+		perror("xc_interface_open");
+		exit(1);
+	}
+
+	rv = xc_dom_loginit(xch);
+	if (rv) return rv;
+
+	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	//if (rv) return rv;
+
+	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
+	printf("xc_domain_create: %d (%d)\n", rv, errno);
+	if ( rv < 0 )
+	{
+		perror("xc_domain_create");
+		exit(1);
+	}
+
+	printf("building dom%d\n", domid);
+
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if ( rv < 0)
+	{
+		perror("xc_domain_max_vcpus");
+		exit(1);
+	}
+
+	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
+	if ( rv < 0)
+	{
+		perror("xc_domain_setmaxmem");
+		exit(1);
+	}
+
+	dom = xc_dom_allocate(xch, "", NULL);
+	rv = xc_dom_kernel_file(dom, image);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_unpause(xch, domid);
+	if ( rv )
+	{
+		perror("xc_domain_unpause");
+		exit(1);
+	}
+
+	xc_interface_close(xch);
+
+	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 Tue Jun 26 10:46:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHg-0007kT-PP; Tue, 26 Jun 2012 10:46: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 1SjTHe-0007gN-ST
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:11 +0000
Received: from [85.158.138.51:25265] by server-6.bemta-3.messagelabs.com id
	72/2A-11602-1F299EF4; Tue, 26 Jun 2012 10:46:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340707566!21483443!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7837 invoked from network); 26 Jun 2012 10:46:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427229"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:07 -0400
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 1SjT26-00064E-Jk;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:00 +0000
Message-ID: <1340706604-1313-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 36/40] libxc: add ARM support to xc_dom (PV
	domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Includes ARM zImage support.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 6 files changed, 315 insertions(+), 9 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ca38cbd..a01d457 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
 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_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 2aef64a..4db8fad 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -93,6 +93,7 @@ struct xc_dom_image {
     void *p2m_guest;
 
     /* physical memory */
+    xen_pfn_t rambase_pfn;
     xen_pfn_t total_pages;
     struct xc_dom_phys *phys_pages;
     int realmodearea_log;
@@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
@@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
 {
     if (xc_dom_feature_translated(dom))
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 /* --- arch bits --------------------------------------------------- */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 122d0e8..9099cad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -18,14 +18,138 @@
  * Copyright (c) 2011, Citrix Systems
  */
 #include <inttypes.h>
+
 #include <xen/xen.h>
+#include <xen/io/protocols.h>
+
 #include "xg_private.h"
 #include "xc_dom.h"
 
+/* ------------------------------------------------------------------------ */
+/*
+ * arm guests are hybrid and start off with paging disabled, therefore no
+ * pagetables and nothing to do here.
+ */
+static int count_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+static int setup_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX
+     *   dom->p2m_guest
+     *   dom->start_info_pfn
+     *   dom->xenstore_pfn
+     *   dom->console_pfn
+     */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int start_info_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
+{
+    vcpu_guest_context_t *ctxt = ptr;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    /* clear everything */
+    memset(ctxt, 0, sizeof(*ctxt));
+
+    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
+
+    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
+    ctxt->user_regs.r3 = 0xdeadbeef;
+    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
+    ctxt->ttbr0 = 0;
+    ctxt->ttbr1 = 0;
+    ctxt->ttbcr = 0; /* Defined Reset Value */
+
+    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static struct xc_dom_arch xc_dom_32 = {
+    .guest_type = "xen-3.0-armv7l",
+    .native_protocol = XEN_IO_PROTO_ABI_ARM,
+    .page_shift = PAGE_SHIFT_ARM,
+    .sizeof_pfn = 8,
+    .alloc_magic_pages = alloc_magic_pages,
+    .count_pgtables = count_pgtables_arm,
+    .setup_pgtables = setup_pgtables_arm,
+    .start_info = start_info_arm,
+    .shared_info = shared_info_arm,
+    .vcpu = vcpu_arm,
+};
+
+static void __init register_arch_hooks(void)
+{
+    xc_dom_register_arch_hooks(&xc_dom_32);
+}
+
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
-    errno = ENOSYS;
-    return -1;
+    int rc;
+    xen_pfn_t pfn, allocsz, i;
+
+    dom->shadow_enabled = 1;
+
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+
+    /* setup initial p2m */
+    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
+
+    /* allocate guest memory */
+    for ( i = rc = allocsz = 0;
+          (i < dom->total_pages) && !rc;
+          i += allocsz )
+    {
+        allocsz = dom->total_pages - i;
+        if ( allocsz > 1024*1024 )
+            allocsz = 1024*1024;
+
+        rc = xc_domain_populate_physmap_exact(
+            dom->xch, dom->guest_domid, allocsz,
+            0, 0, &dom->p2m_host[i]);
+    }
+
+    return 0;
 }
 
 int arch_setup_bootearly(struct xc_dom_image *dom)
@@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
 
 int arch_setup_bootlate(struct xc_dom_image *dom)
 {
-    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    /* XXX
+     *   map shared info
+     *   map grant tables
+     *   setup shared info
+     */
     return 0;
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
new file mode 100644
index 0000000..220176d
--- /dev/null
+++ b/tools/libxc/xc_dom_armzimageloader.c
@@ -0,0 +1,167 @@
+/*
+ * Xen domain builder -- ARM zImage bits
+ *
+ * Parse and load ARM zImage kernel images.
+ *
+ * Copyright (C) 2012, Citrix Systems.
+ *
+ * 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
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#include <arpa/inet.h> /* XXX ntohl is not the right function... */
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t end;
+
+    if ( dom->kernel_blob == NULL )
+    {
+        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                     "%s: no kernel image loaded", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    zimage = (uint32_t *)dom->kernel_blob;
+    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    /*
+     * Check for an appended DTB.
+     */
+    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
+        struct minimal_dtb_header *dtb_hdr;
+        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
+        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
+            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
+            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
+        }
+    }
+
+    dom->kernel_size = end;
+
+    return 0;
+}
+
+static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t start, entry_addr;
+    uint64_t v_start, v_end;
+    uint64_t rambase = 0x80000000; /* XXX */
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    zimage = (uint32_t *)dom->kernel_blob;
+
+    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
+
+    v_start = rambase + 0x8000; /* XXX */
+    v_end = v_start + dom->kernel_size;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+
+    if (start == 0)
+        entry_addr = v_start;
+    else
+        entry_addr = start;
+
+    /* find kernel segment */
+    dom->kernel_seg.vstart = v_start;
+    dom->kernel_seg.vend   = v_end;
+
+    dom->parms.virt_entry = entry_addr;
+
+    dom->guest_type = "xen-3.0-armv7l";
+    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
+              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
+    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
+              __FUNCTION__, dom->guest_type,
+              dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    return 0;
+}
+
+static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
+{
+    void *dst;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
+
+    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
+              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
+              __func__, dom->kernel_size, dom->kernel_blob, dst);
+
+    memcpy(dst, dom->kernel_blob, dom->kernel_size);
+
+    return 0;
+}
+
+static struct xc_dom_loader zimage_loader = {
+    .name = "Linux zImage (ARM)",
+    .probe = xc_dom_probe_zimage_kernel,
+    .parser = xc_dom_parse_zimage_kernel,
+    .loader = xc_dom_load_zimage_kernel,
+};
+
+static void __init register_loader(void)
+{
+    xc_dom_register_loader(&zimage_loader);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fea9de5..b0d48d5 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
                         xen_pfn_t count)
 {
     struct xc_dom_phys *phys;
+    xen_pfn_t offset;
     unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
     char *mode = "unset";
 
-    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
+    offset = pfn-dom->rambase_pfn;
+    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
          count > dom->total_pages ||
-         pfn > dom->total_pages - count )
+         offset > dom->total_pages - count )
     {
-        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
-                  __FUNCTION__, pfn, dom->total_pages);
+        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
+                  __FUNCTION__, pfn, offset, dom->total_pages);
         return NULL;
     }
 
@@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
     dom->parms.virt_hv_start_low = UNSET_ADDR;
     dom->parms.elf_paddr_offset = UNSET_ADDR;
 
+    dom->rambase_pfn = 0;
+
     dom->alloc_malloc += sizeof(*dom);
     return dom;
 
diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
index a29fa26..a271942 100644
--- a/tools/libxc/xg_private.h
+++ b/tools/libxc/xg_private.h
@@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
+#define PAGE_SHIFT_ARM          12
+#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
+#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
+
 #define PAGE_SHIFT_X86          12
 #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
 #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-- 
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 Jun 26 10:46:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTHg-0007kT-PP; Tue, 26 Jun 2012 10:46: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 1SjTHe-0007gN-ST
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:11 +0000
Received: from [85.158.138.51:25265] by server-6.bemta-3.messagelabs.com id
	72/2A-11602-1F299EF4; Tue, 26 Jun 2012 10:46:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340707566!21483443!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7837 invoked from network); 26 Jun 2012 10:46:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427229"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:07 -0400
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 1SjT26-00064E-Jk;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:00 +0000
Message-ID: <1340706604-1313-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 36/40] libxc: add ARM support to xc_dom (PV
	domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Includes ARM zImage support.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 6 files changed, 315 insertions(+), 9 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ca38cbd..a01d457 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
 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_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 2aef64a..4db8fad 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -93,6 +93,7 @@ struct xc_dom_image {
     void *p2m_guest;
 
     /* physical memory */
+    xen_pfn_t rambase_pfn;
     xen_pfn_t total_pages;
     struct xc_dom_phys *phys_pages;
     int realmodearea_log;
@@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
@@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
 {
     if (xc_dom_feature_translated(dom))
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 /* --- arch bits --------------------------------------------------- */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 122d0e8..9099cad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -18,14 +18,138 @@
  * Copyright (c) 2011, Citrix Systems
  */
 #include <inttypes.h>
+
 #include <xen/xen.h>
+#include <xen/io/protocols.h>
+
 #include "xg_private.h"
 #include "xc_dom.h"
 
+/* ------------------------------------------------------------------------ */
+/*
+ * arm guests are hybrid and start off with paging disabled, therefore no
+ * pagetables and nothing to do here.
+ */
+static int count_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+static int setup_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX
+     *   dom->p2m_guest
+     *   dom->start_info_pfn
+     *   dom->xenstore_pfn
+     *   dom->console_pfn
+     */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int start_info_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
+{
+    vcpu_guest_context_t *ctxt = ptr;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    /* clear everything */
+    memset(ctxt, 0, sizeof(*ctxt));
+
+    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
+
+    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
+    ctxt->user_regs.r3 = 0xdeadbeef;
+    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
+    ctxt->ttbr0 = 0;
+    ctxt->ttbr1 = 0;
+    ctxt->ttbcr = 0; /* Defined Reset Value */
+
+    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static struct xc_dom_arch xc_dom_32 = {
+    .guest_type = "xen-3.0-armv7l",
+    .native_protocol = XEN_IO_PROTO_ABI_ARM,
+    .page_shift = PAGE_SHIFT_ARM,
+    .sizeof_pfn = 8,
+    .alloc_magic_pages = alloc_magic_pages,
+    .count_pgtables = count_pgtables_arm,
+    .setup_pgtables = setup_pgtables_arm,
+    .start_info = start_info_arm,
+    .shared_info = shared_info_arm,
+    .vcpu = vcpu_arm,
+};
+
+static void __init register_arch_hooks(void)
+{
+    xc_dom_register_arch_hooks(&xc_dom_32);
+}
+
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
-    errno = ENOSYS;
-    return -1;
+    int rc;
+    xen_pfn_t pfn, allocsz, i;
+
+    dom->shadow_enabled = 1;
+
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+
+    /* setup initial p2m */
+    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
+
+    /* allocate guest memory */
+    for ( i = rc = allocsz = 0;
+          (i < dom->total_pages) && !rc;
+          i += allocsz )
+    {
+        allocsz = dom->total_pages - i;
+        if ( allocsz > 1024*1024 )
+            allocsz = 1024*1024;
+
+        rc = xc_domain_populate_physmap_exact(
+            dom->xch, dom->guest_domid, allocsz,
+            0, 0, &dom->p2m_host[i]);
+    }
+
+    return 0;
 }
 
 int arch_setup_bootearly(struct xc_dom_image *dom)
@@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
 
 int arch_setup_bootlate(struct xc_dom_image *dom)
 {
-    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    /* XXX
+     *   map shared info
+     *   map grant tables
+     *   setup shared info
+     */
     return 0;
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
new file mode 100644
index 0000000..220176d
--- /dev/null
+++ b/tools/libxc/xc_dom_armzimageloader.c
@@ -0,0 +1,167 @@
+/*
+ * Xen domain builder -- ARM zImage bits
+ *
+ * Parse and load ARM zImage kernel images.
+ *
+ * Copyright (C) 2012, Citrix Systems.
+ *
+ * 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
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#include <arpa/inet.h> /* XXX ntohl is not the right function... */
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t end;
+
+    if ( dom->kernel_blob == NULL )
+    {
+        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                     "%s: no kernel image loaded", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    zimage = (uint32_t *)dom->kernel_blob;
+    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    /*
+     * Check for an appended DTB.
+     */
+    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
+        struct minimal_dtb_header *dtb_hdr;
+        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
+        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
+            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
+            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
+        }
+    }
+
+    dom->kernel_size = end;
+
+    return 0;
+}
+
+static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t start, entry_addr;
+    uint64_t v_start, v_end;
+    uint64_t rambase = 0x80000000; /* XXX */
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    zimage = (uint32_t *)dom->kernel_blob;
+
+    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
+
+    v_start = rambase + 0x8000; /* XXX */
+    v_end = v_start + dom->kernel_size;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+
+    if (start == 0)
+        entry_addr = v_start;
+    else
+        entry_addr = start;
+
+    /* find kernel segment */
+    dom->kernel_seg.vstart = v_start;
+    dom->kernel_seg.vend   = v_end;
+
+    dom->parms.virt_entry = entry_addr;
+
+    dom->guest_type = "xen-3.0-armv7l";
+    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
+              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
+    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
+              __FUNCTION__, dom->guest_type,
+              dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    return 0;
+}
+
+static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
+{
+    void *dst;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
+
+    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
+              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
+              __func__, dom->kernel_size, dom->kernel_blob, dst);
+
+    memcpy(dst, dom->kernel_blob, dom->kernel_size);
+
+    return 0;
+}
+
+static struct xc_dom_loader zimage_loader = {
+    .name = "Linux zImage (ARM)",
+    .probe = xc_dom_probe_zimage_kernel,
+    .parser = xc_dom_parse_zimage_kernel,
+    .loader = xc_dom_load_zimage_kernel,
+};
+
+static void __init register_loader(void)
+{
+    xc_dom_register_loader(&zimage_loader);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fea9de5..b0d48d5 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
                         xen_pfn_t count)
 {
     struct xc_dom_phys *phys;
+    xen_pfn_t offset;
     unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
     char *mode = "unset";
 
-    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
+    offset = pfn-dom->rambase_pfn;
+    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
          count > dom->total_pages ||
-         pfn > dom->total_pages - count )
+         offset > dom->total_pages - count )
     {
-        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
-                  __FUNCTION__, pfn, dom->total_pages);
+        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
+                  __FUNCTION__, pfn, offset, dom->total_pages);
         return NULL;
     }
 
@@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
     dom->parms.virt_hv_start_low = UNSET_ADDR;
     dom->parms.elf_paddr_offset = UNSET_ADDR;
 
+    dom->rambase_pfn = 0;
+
     dom->alloc_malloc += sizeof(*dom);
     return dom;
 
diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
index a29fa26..a271942 100644
--- a/tools/libxc/xg_private.h
+++ b/tools/libxc/xg_private.h
@@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
+#define PAGE_SHIFT_ARM          12
+#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
+#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
+
 #define PAGE_SHIFT_X86          12
 #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
 #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-- 
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 Jun 26 10:46:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTI5-0008LQ-2l; Tue, 26 Jun 2012 10:46: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 1SjTI4-0008JK-6h
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:36 +0000
Received: from [85.158.138.51:29297] by server-10.bemta-3.messagelabs.com id
	D4/5C-01753-B0399EF4; Tue, 26 Jun 2012 10:46:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1072 invoked from network); 26 Jun 2012 10:46:34 -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;
	26 Jun 2012 10:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051799"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:51 -0400
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 1SjT26-00064E-8s;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:55 +0000
Message-ID: <1340706604-1313-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 31/40] arm: context switch virtual timer
	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/domain.c        |   10 ++++++++++
 xen/include/asm-arm/cpregs.h |    3 +++
 xen/include/asm-arm/domain.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a7b7d4a..2b5515d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -49,6 +49,11 @@ static void ctxt_switch_from(struct vcpu *p)
     p->arch.tpidruro = READ_CP32(TPIDRURO);
     p->arch.tpidrprw = READ_CP32(TPIDRPRW);
 
+    /* Arch timer */
+    p->arch.cntvoff = READ_CP64(CNTVOFF);
+    p->arch.cntv_cval = READ_CP64(CNTV_CVAL);
+    p->arch.cntv_ctl = READ_CP32(CNTV_CTL);
+
     /* 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);
@@ -128,6 +133,11 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_CP32(n->arch.mair1, MAIR1);
     isb();
 
+    /* Arch timer */
+    WRITE_CP64(n->arch.cntvoff, CNTVOFF);
+    WRITE_CP64(n->arch.cntv_cval, CNTV_CVAL);
+    WRITE_CP32(n->arch.cntv_ctl, CNTV_CTL);
+
     /* Control Registers */
     WRITE_CP32(n->arch.actlr, ACTLR);
     WRITE_CP32(n->arch.sctlr, SCTLR);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index bd46942..34a9e93 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -238,10 +238,13 @@
 #define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
 #define CNTVCT          p15,1,c14       /* Time counter value + offset */
 #define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTV_CVAL       p15,3,c14       /* Virt. Timer comparator */
 #define CNTVOFF         p15,4,c14       /* Time counter offset */
 #define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
 #define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
 #define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTV_TVAL       p15,0,c14,c3,0  /* Virt. Timer value */
+#define CNTV_CTL        p15,0,c14,c3,1  /* Virt. TImer control register */
 #define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
 
 /* CP15 CR15: Implementation Defined Registers */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 32deb52..230ea8c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,11 @@ struct arch_vcpu
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
 
+    /* Arch timers */
+    uint64_t cntvoff;
+    uint64_t cntv_cval;
+    uint32_t cntv_ctl;
+
     /* CP 15 */
     uint32_t csselr;
 
-- 
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 Jun 26 10:46:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTI5-0008LQ-2l; Tue, 26 Jun 2012 10:46: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 1SjTI4-0008JK-6h
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:36 +0000
Received: from [85.158.138.51:29297] by server-10.bemta-3.messagelabs.com id
	D4/5C-01753-B0399EF4; Tue, 26 Jun 2012 10:46:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1072 invoked from network); 26 Jun 2012 10:46:34 -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;
	26 Jun 2012 10:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051799"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:51 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:51 -0400
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 1SjT26-00064E-8s;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:55 +0000
Message-ID: <1340706604-1313-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 31/40] arm: context switch virtual timer
	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/domain.c        |   10 ++++++++++
 xen/include/asm-arm/cpregs.h |    3 +++
 xen/include/asm-arm/domain.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a7b7d4a..2b5515d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -49,6 +49,11 @@ static void ctxt_switch_from(struct vcpu *p)
     p->arch.tpidruro = READ_CP32(TPIDRURO);
     p->arch.tpidrprw = READ_CP32(TPIDRPRW);
 
+    /* Arch timer */
+    p->arch.cntvoff = READ_CP64(CNTVOFF);
+    p->arch.cntv_cval = READ_CP64(CNTV_CVAL);
+    p->arch.cntv_ctl = READ_CP32(CNTV_CTL);
+
     /* 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);
@@ -128,6 +133,11 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_CP32(n->arch.mair1, MAIR1);
     isb();
 
+    /* Arch timer */
+    WRITE_CP64(n->arch.cntvoff, CNTVOFF);
+    WRITE_CP64(n->arch.cntv_cval, CNTV_CVAL);
+    WRITE_CP32(n->arch.cntv_ctl, CNTV_CTL);
+
     /* Control Registers */
     WRITE_CP32(n->arch.actlr, ACTLR);
     WRITE_CP32(n->arch.sctlr, SCTLR);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index bd46942..34a9e93 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -238,10 +238,13 @@
 #define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
 #define CNTVCT          p15,1,c14       /* Time counter value + offset */
 #define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTV_CVAL       p15,3,c14       /* Virt. Timer comparator */
 #define CNTVOFF         p15,4,c14       /* Time counter offset */
 #define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
 #define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
 #define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTV_TVAL       p15,0,c14,c3,0  /* Virt. Timer value */
+#define CNTV_CTL        p15,0,c14,c3,1  /* Virt. TImer control register */
 #define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
 
 /* CP15 CR15: Implementation Defined Registers */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 32deb52..230ea8c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,11 @@ struct arch_vcpu
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
 
+    /* Arch timers */
+    uint64_t cntvoff;
+    uint64_t cntv_cval;
+    uint32_t cntv_ctl;
+
     /* CP 15 */
     uint32_t csselr;
 
-- 
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 Jun 26 10:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTI4-0008Kh-Mf; Tue, 26 Jun 2012 10:46: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 1SjTI3-0008I3-9T
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:35 +0000
Received: from [85.158.138.51:29044] by server-9.bemta-3.messagelabs.com id
	96/50-10419-A0399EF4; Tue, 26 Jun 2012 10:46:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 966 invoked from network); 26 Jun 2012 10:46:34 -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;
	26 Jun 2012 10:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051817"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:58 -0400
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 1SjT26-00064E-3R;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:52 +0000
Message-ID: <1340706604-1313-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 28/40] arm: enable data-cache at the same
	time as enabling the MMU, not before
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..cdbe011 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache disabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -210,7 +211,7 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
-- 
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 Jun 26 10:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTI4-0008Kh-Mf; Tue, 26 Jun 2012 10:46: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 1SjTI3-0008I3-9T
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:35 +0000
Received: from [85.158.138.51:29044] by server-9.bemta-3.messagelabs.com id
	96/50-10419-A0399EF4; Tue, 26 Jun 2012 10:46:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 966 invoked from network); 26 Jun 2012 10:46:34 -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;
	26 Jun 2012 10:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051817"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:58 -0400
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 1SjT26-00064E-3R;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:52 +0000
Message-ID: <1340706604-1313-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 28/40] arm: enable data-cache at the same
	time as enabling the MMU, not before
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..cdbe011 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache disabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -210,7 +211,7 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
-- 
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 Jun 26 10:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTI6-0008O8-IW; Tue, 26 Jun 2012 10:46: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 1SjTI4-0008KI-RK
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:29502] by server-2.bemta-3.messagelabs.com id
	C6/E7-10266-C0399EF4; Tue, 26 Jun 2012 10:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1201 invoked from network); 26 Jun 2012 10:46:35 -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;
	26 Jun 2012 10:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051804"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:54 -0400
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 1SjT26-00064E-MY;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:01 +0000
Message-ID: <1340706604-1313-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 37/40] arm: implement VGCF_online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 tools/libxc/xc_dom_arm.c      |    2 ++
 xen/arch/arm/domain.c         |    5 ++++-
 xen/include/public/arch-arm.h |    4 ++++
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 9099cad..bea409b 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -96,6 +96,8 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
 
     ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
+    ctxt->flags = VGCF_online;
+
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
            ctxt->user_regs.cpsr, ctxt->user_regs.pc);
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ac6a30d..f61568b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -416,7 +416,10 @@ int arch_set_info_guest(
     v->arch.ttbr1 = ctxt->ttbr1;
     v->arch.ttbcr = ctxt->ttbcr;
 
-    clear_bit(_VPF_down, &v->pause_flags);
+    if ( ctxt->flags & VGCF_online )
+        clear_bit(_VPF_down, &v->pause_flags);
+    else
+        set_bit(_VPF_down, &v->pause_flags);
 
     return 0;
 }
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7ebe966..6e0fe47 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,10 @@ typedef uint32_t xen_ulong_t;
 #define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
+#define _VGCF_online                   0
+#define VGCF_online                    (1<<_VGCF_online)
+    uint32_t flags;                         /* VGCF_* */
+
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
 
     uint32_t sctlr;
-- 
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 Jun 26 10:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjTI6-0008O8-IW; Tue, 26 Jun 2012 10:46: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 1SjTI4-0008KI-RK
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:29502] by server-2.bemta-3.messagelabs.com id
	C6/E7-10266-C0399EF4; Tue, 26 Jun 2012 10:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1201 invoked from network); 26 Jun 2012 10:46:35 -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;
	26 Jun 2012 10:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051804"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:54 -0400
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 1SjT26-00064E-MY;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:01 +0000
Message-ID: <1340706604-1313-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 37/40] arm: implement VGCF_online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 tools/libxc/xc_dom_arm.c      |    2 ++
 xen/arch/arm/domain.c         |    5 ++++-
 xen/include/public/arch-arm.h |    4 ++++
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 9099cad..bea409b 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -96,6 +96,8 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
 
     ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
+    ctxt->flags = VGCF_online;
+
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
            ctxt->user_regs.cpsr, ctxt->user_regs.pc);
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ac6a30d..f61568b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -416,7 +416,10 @@ int arch_set_info_guest(
     v->arch.ttbr1 = ctxt->ttbr1;
     v->arch.ttbcr = ctxt->ttbcr;
 
-    clear_bit(_VPF_down, &v->pause_flags);
+    if ( ctxt->flags & VGCF_online )
+        clear_bit(_VPF_down, &v->pause_flags);
+    else
+        set_bit(_VPF_down, &v->pause_flags);
 
     return 0;
 }
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7ebe966..6e0fe47 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,10 @@ typedef uint32_t xen_ulong_t;
 #define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
+#define _VGCF_online                   0
+#define VGCF_online                    (1<<_VGCF_online)
+    uint32_t flags;                         /* VGCF_* */
+
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
 
     uint32_t sctlr;
-- 
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 Jun 26 10:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjTI7-0008Qf-Ro; Tue, 26 Jun 2012 10:46: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 1SjTI4-0008JK-O7
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:5877] by server-10.bemta-3.messagelabs.com id
	5C/5C-01753-B0399EF4; Tue, 26 Jun 2012 10:46:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15650 invoked from network); 26 Jun 2012 10:46:35 -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;
	26 Jun 2012 10:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051801"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:52 -0400
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 1SjT25-00064E-IN;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:42 +0000
Message-ID: <1340706604-1313-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 18/40] arm: context switch a bunch of 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

I haven't investigated what if any of this could be done lazily.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c         |  122 +++++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/gic.c            |   25 ++++++++-
 xen/arch/arm/gic.h            |    9 ++-
 xen/include/asm-arm/cpregs.h  |   29 +++++++++-
 xen/include/asm-arm/domain.h  |   33 ++++++++++-
 xen/include/public/arch-arm.h |    3 +
 6 files changed, 208 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 931261b..d11be78 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -36,12 +36,124 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
+    /* CP 15 */
+    p->arch.csselr = READ_CP32(CSSELR);
+
+    /* Control Registers */
+    p->arch.actlr = READ_CP32(ACTLR);
+    p->arch.sctlr = READ_CP32(SCTLR);
+    p->arch.cpacr = READ_CP32(CPACR);
+
+    p->arch.contextidr = READ_CP32(CONTEXTIDR);
+    p->arch.tpidrurw = READ_CP32(TPIDRURW);
+    p->arch.tpidruro = READ_CP32(TPIDRURO);
+    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+
+    /* 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);
+
+    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.mair0 = READ_CP32(MAIR0);
+    p->arch.mair1 = READ_CP32(MAIR1);
+
+    /* Fault Status */
+    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);
+
+    /* XXX MPU */
+
+    /* XXX VFP */
+
+    /* XXX VGIC */
+    gic_save_state(p);
+
+    isb();
     context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
 {
+    uint32_t hcr;
+
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    isb();
+
     p2m_load_VTTBR(n->domain);
+    isb();
+
+    /* XXX VGIC */
+    gic_restore_state(n);
+
+    /* XXX VFP */
+
+    /* XXX MPU */
+
+    /* Fault Status */
+    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);
+
+    /* 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_CP32(n->arch.mair0, MAIR0);
+    WRITE_CP32(n->arch.mair1, MAIR1);
+    isb();
+
+    /* Control Registers */
+    WRITE_CP32(n->arch.actlr, ACTLR);
+    WRITE_CP32(n->arch.sctlr, SCTLR);
+    WRITE_CP32(n->arch.cpacr, CPACR);
+
+    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
+    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
+    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
+    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+
+    /* 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);
+
+    isb();
+
+    /* CP 15 */
+    WRITE_CP32(n->arch.csselr, CSSELR);
+
+    isb();
+
+    WRITE_CP32(hcr, HCR);
+    isb();
 }
 
 static void schedule_tail(struct vcpu *prev)
@@ -258,6 +370,7 @@ static int is_guest_psr(uint32_t psr)
 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;
 
     if ( !is_guest_psr(regs->cpsr) )
@@ -276,11 +389,10 @@ int arch_set_info_guest(
 
     v->arch.cpu_info->guest_cpu_user_regs = *regs;
 
-    /* XXX other state:
-     * - SCTLR
-     * - TTBR0/1
-     * - TTBCR
-     */
+    v->arch.sctlr = ctxt->sctlr;
+    v->arch.ttbr0 = ctxt->ttbr0;
+    v->arch.ttbr1 = ctxt->ttbr1;
+    v->arch.ttbcr = ctxt->ttbcr;
 
     clear_bit(_VPF_down, &v->pause_flags);
 
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1a2b95f..339c327 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -61,6 +61,30 @@ static struct {
 irq_desc_t irq_desc[NR_IRQS];
 unsigned nr_lrs;
 
+void gic_save_state(struct vcpu *v)
+{
+    int i;
+
+    for ( i=0; i<nr_lrs; i++)
+        v->arch.gic_lr[i] = GICH[GICH_LR + i];
+    /* Disable until next VCPU scheduled */
+    GICH[GICH_HCR] = 0;
+    isb();
+}
+
+void gic_restore_state(struct vcpu *v)
+{
+    int i;
+
+    if ( is_idle_vcpu(v) )
+        return;
+
+    for ( i=0; i<nr_lrs; i++)
+        GICH[GICH_LR + i] = v->arch.gic_lr[i];
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    isb();
+}
+
 static unsigned int gic_irq_startup(struct irq_desc *desc)
 {
     uint32_t enabler;
@@ -263,7 +287,6 @@ static void __cpuinit gic_hyp_init(void)
     vtr = GICH[GICH_VTR];
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
 
-    GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ff8d0a2..ac9cf3a 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -70,8 +70,8 @@
 #define GICH_MISR       (0x10/4)
 #define GICH_EISR0      (0x20/4)
 #define GICH_EISR1      (0x24/4)
-#define GICH_ELRSR0     (0x30/4)
-#define GICH_ELRSR1     (0x34/4)
+#define GICH_ELSR0      (0x30/4)
+#define GICH_ELSR1      (0x34/4)
 #define GICH_APR        (0xF0/4)
 #define GICH_LR         (0x100/4)
 
@@ -149,6 +149,11 @@ extern void gic_init_secondary_cpu(void);
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
+
+/* Context switch */
+extern void gic_save_state(struct vcpu *v);
+extern void gic_restore_state(struct vcpu *v);
+
 #endif
 
 /*
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7a0b49a..bd46942 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -88,6 +88,19 @@
  * arguments, which are cp,opc1,crn,crm,opc2.
  */
 
+/* Coprocessor 14 */
+
+/* CP14 CR0: */
+#define TEECR           p14,6,c0,c0,0   /* ThumbEE Configuration Register */
+
+/* CP14 CR1: */
+#define TEEHBR          p14,6,c1,c0,0   /* ThumbEE Handler Base Register */
+#define JOSCR           p14,7,c1,c0,0   /* Jazelle OS Control Register */
+
+/* CP14 CR2: */
+#define JMCR            p14,7,c2,c0,0   /* Jazelle Main Configuration Register */
+
+
 /* Coprocessor 15 */
 
 /* CP15 CR0: CPUID and Cache Type Registers */
@@ -112,6 +125,8 @@
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define ACTLR           p15,0,c1,c0,1   /* Auxiliary Control Register */
+#define CPACR           p15,0,c1,c0,2   /* Coprocessor Access Control Register */
 #define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
 #define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
 #define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
@@ -127,12 +142,15 @@
 #define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
 
 /* CP15 CR3: Domain Access Control Register */
+#define DACR            p15,0,c3,c0,0   /* Domain Access Control Register */
 
 /* CP15 CR4: */
 
 /* CP15 CR5: Fault Status Registers */
 #define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
 #define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define ADFSR           p15,0,c5,c1,0   /* Auxiliary Data Fault Status Register */
+#define AIFSR           p15,0,c5,c1,1   /* Auxiliary Instruction Fault Status Register */
 #define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
 
 /* CP15 CR6: Fault Address Registers */
@@ -144,6 +162,7 @@
 
 /* CP15 CR7: Cache and address translation operations */
 #define PAR             p15,0,c7        /* Physical Address Register */
+
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
@@ -192,20 +211,24 @@
 /* CP15 CR9: */
 
 /* CP15 CR10: */
-#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
-#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 AKA NMRR */
 #define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
 #define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
 
 /* CP15 CR11: DMA Operations for TCM Access */
 
 /* CP15 CR12:  */
+#define VBAR            p15,0,c12,c0,0  /* Vector Base Address Register */
 #define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
 
 /* CP15 CR13:  */
 #define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
 #define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
-#define HTPIDR          p15,4,c13,c0,2  /* Hyp. Software Thread ID Register */
+#define TPIDRURW        p15,0,c13,c0,2  /* Software Thread ID, User, R/W */
+#define TPIDRURO        p15,0,c13,c0,3  /* Software Thread ID, User, R/O */
+#define TPIDRPRW        p15,0,c13,c0,4  /* Software Thread ID, Priveleged */
+#define HTPIDR          p15,4,c13,c0,2  /* HYp Software Thread Id Register */
 
 /* CP15 CR14:  */
 #define CNTPCT          p15,0,c14       /* Time counter value */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index f295a82..620b26e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -81,8 +81,37 @@ struct arch_vcpu
      */
     struct cpu_info *cpu_info;
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    /* Fault Status */
+    uint32_t dfar, ifar;
+    uint32_t dfsr, ifsr;
+    uint32_t adfsr, aifsr;
+
+    /* MMU */
+    uint32_t vbar;
+    uint32_t ttbcr;
+    uint32_t ttbr0, ttbr1;
+
+    uint32_t dacr;
+    uint64_t par;
+    uint32_t mair0, mair1;
+
+    /* Control Registers */
+    uint32_t actlr, sctlr;
+    uint32_t cpacr;
+
+    uint32_t contextidr;
+    uint32_t tpidrurw;
+    uint32_t tpidruro;
+    uint32_t tpidrprw;
+
+    uint32_t teecr, teehbr;
+    uint32_t joscr, jmcr;
+
+    /* CP 15 */
+    uint32_t csselr;
+
+    uint32_t gic_hcr, gic_vmcr, gic_apr;
+    uint32_t gic_lr[64];
 
     struct {
         struct vgic_irq_rank private_irqs;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e439727..e915cbf 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,9 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 26 10:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjTI7-0008Qf-Ro; Tue, 26 Jun 2012 10:46: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 1SjTI4-0008JK-O7
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:5877] by server-10.bemta-3.messagelabs.com id
	5C/5C-01753-B0399EF4; Tue, 26 Jun 2012 10:46:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15650 invoked from network); 26 Jun 2012 10:46:35 -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;
	26 Jun 2012 10:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051801"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:52 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:52 -0400
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 1SjT25-00064E-IN;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:42 +0000
Message-ID: <1340706604-1313-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 18/40] arm: context switch a bunch of 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

I haven't investigated what if any of this could be done lazily.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c         |  122 +++++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/gic.c            |   25 ++++++++-
 xen/arch/arm/gic.h            |    9 ++-
 xen/include/asm-arm/cpregs.h  |   29 +++++++++-
 xen/include/asm-arm/domain.h  |   33 ++++++++++-
 xen/include/public/arch-arm.h |    3 +
 6 files changed, 208 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 931261b..d11be78 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -36,12 +36,124 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
+    /* CP 15 */
+    p->arch.csselr = READ_CP32(CSSELR);
+
+    /* Control Registers */
+    p->arch.actlr = READ_CP32(ACTLR);
+    p->arch.sctlr = READ_CP32(SCTLR);
+    p->arch.cpacr = READ_CP32(CPACR);
+
+    p->arch.contextidr = READ_CP32(CONTEXTIDR);
+    p->arch.tpidrurw = READ_CP32(TPIDRURW);
+    p->arch.tpidruro = READ_CP32(TPIDRURO);
+    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+
+    /* 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);
+
+    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.mair0 = READ_CP32(MAIR0);
+    p->arch.mair1 = READ_CP32(MAIR1);
+
+    /* Fault Status */
+    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);
+
+    /* XXX MPU */
+
+    /* XXX VFP */
+
+    /* XXX VGIC */
+    gic_save_state(p);
+
+    isb();
     context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
 {
+    uint32_t hcr;
+
+    hcr = READ_CP32(HCR);
+    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    isb();
+
     p2m_load_VTTBR(n->domain);
+    isb();
+
+    /* XXX VGIC */
+    gic_restore_state(n);
+
+    /* XXX VFP */
+
+    /* XXX MPU */
+
+    /* Fault Status */
+    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);
+
+    /* 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_CP32(n->arch.mair0, MAIR0);
+    WRITE_CP32(n->arch.mair1, MAIR1);
+    isb();
+
+    /* Control Registers */
+    WRITE_CP32(n->arch.actlr, ACTLR);
+    WRITE_CP32(n->arch.sctlr, SCTLR);
+    WRITE_CP32(n->arch.cpacr, CPACR);
+
+    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
+    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
+    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
+    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+
+    /* 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);
+
+    isb();
+
+    /* CP 15 */
+    WRITE_CP32(n->arch.csselr, CSSELR);
+
+    isb();
+
+    WRITE_CP32(hcr, HCR);
+    isb();
 }
 
 static void schedule_tail(struct vcpu *prev)
@@ -258,6 +370,7 @@ static int is_guest_psr(uint32_t psr)
 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;
 
     if ( !is_guest_psr(regs->cpsr) )
@@ -276,11 +389,10 @@ int arch_set_info_guest(
 
     v->arch.cpu_info->guest_cpu_user_regs = *regs;
 
-    /* XXX other state:
-     * - SCTLR
-     * - TTBR0/1
-     * - TTBCR
-     */
+    v->arch.sctlr = ctxt->sctlr;
+    v->arch.ttbr0 = ctxt->ttbr0;
+    v->arch.ttbr1 = ctxt->ttbr1;
+    v->arch.ttbcr = ctxt->ttbcr;
 
     clear_bit(_VPF_down, &v->pause_flags);
 
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1a2b95f..339c327 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -61,6 +61,30 @@ static struct {
 irq_desc_t irq_desc[NR_IRQS];
 unsigned nr_lrs;
 
+void gic_save_state(struct vcpu *v)
+{
+    int i;
+
+    for ( i=0; i<nr_lrs; i++)
+        v->arch.gic_lr[i] = GICH[GICH_LR + i];
+    /* Disable until next VCPU scheduled */
+    GICH[GICH_HCR] = 0;
+    isb();
+}
+
+void gic_restore_state(struct vcpu *v)
+{
+    int i;
+
+    if ( is_idle_vcpu(v) )
+        return;
+
+    for ( i=0; i<nr_lrs; i++)
+        GICH[GICH_LR + i] = v->arch.gic_lr[i];
+    GICH[GICH_HCR] = GICH_HCR_EN;
+    isb();
+}
+
 static unsigned int gic_irq_startup(struct irq_desc *desc)
 {
     uint32_t enabler;
@@ -263,7 +287,6 @@ static void __cpuinit gic_hyp_init(void)
     vtr = GICH[GICH_VTR];
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
 
-    GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ff8d0a2..ac9cf3a 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -70,8 +70,8 @@
 #define GICH_MISR       (0x10/4)
 #define GICH_EISR0      (0x20/4)
 #define GICH_EISR1      (0x24/4)
-#define GICH_ELRSR0     (0x30/4)
-#define GICH_ELRSR1     (0x34/4)
+#define GICH_ELSR0      (0x30/4)
+#define GICH_ELSR1      (0x34/4)
 #define GICH_APR        (0xF0/4)
 #define GICH_LR         (0x100/4)
 
@@ -149,6 +149,11 @@ extern void gic_init_secondary_cpu(void);
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
+
+/* Context switch */
+extern void gic_save_state(struct vcpu *v);
+extern void gic_restore_state(struct vcpu *v);
+
 #endif
 
 /*
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7a0b49a..bd46942 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -88,6 +88,19 @@
  * arguments, which are cp,opc1,crn,crm,opc2.
  */
 
+/* Coprocessor 14 */
+
+/* CP14 CR0: */
+#define TEECR           p14,6,c0,c0,0   /* ThumbEE Configuration Register */
+
+/* CP14 CR1: */
+#define TEEHBR          p14,6,c1,c0,0   /* ThumbEE Handler Base Register */
+#define JOSCR           p14,7,c1,c0,0   /* Jazelle OS Control Register */
+
+/* CP14 CR2: */
+#define JMCR            p14,7,c2,c0,0   /* Jazelle Main Configuration Register */
+
+
 /* Coprocessor 15 */
 
 /* CP15 CR0: CPUID and Cache Type Registers */
@@ -112,6 +125,8 @@
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
+#define ACTLR           p15,0,c1,c0,1   /* Auxiliary Control Register */
+#define CPACR           p15,0,c1,c0,2   /* Coprocessor Access Control Register */
 #define SCR             p15,0,c1,c1,0   /* Secure Configuration Register */
 #define NSACR           p15,0,c1,c1,2   /* Non-Secure Access Control Register */
 #define HSCTLR          p15,4,c1,c0,0   /* Hyp. System Control Register */
@@ -127,12 +142,15 @@
 #define VTTBR           p15,6,c2        /* Virtualization Translation Table Base Register */
 
 /* CP15 CR3: Domain Access Control Register */
+#define DACR            p15,0,c3,c0,0   /* Domain Access Control Register */
 
 /* CP15 CR4: */
 
 /* CP15 CR5: Fault Status Registers */
 #define DFSR            p15,0,c5,c0,0   /* Data Fault Status Register */
 #define IFSR            p15,0,c5,c0,1   /* Instruction Fault Status Register */
+#define ADFSR           p15,0,c5,c1,0   /* Auxiliary Data Fault Status Register */
+#define AIFSR           p15,0,c5,c1,1   /* Auxiliary Instruction Fault Status Register */
 #define HSR             p15,4,c5,c2,0   /* Hyp. Syndrome Register */
 
 /* CP15 CR6: Fault Address Registers */
@@ -144,6 +162,7 @@
 
 /* CP15 CR7: Cache and address translation operations */
 #define PAR             p15,0,c7        /* Physical Address Register */
+
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
@@ -192,20 +211,24 @@
 /* CP15 CR9: */
 
 /* CP15 CR10: */
-#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 */
-#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 */
+#define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
+#define MAIR1           p15,0,c10,c2,1  /* Memory Attribute Indirection Register 1 AKA NMRR */
 #define HMAIR0          p15,4,c10,c2,0  /* Hyp. Memory Attribute Indirection Register 0 */
 #define HMAIR1          p15,4,c10,c2,1  /* Hyp. Memory Attribute Indirection Register 1 */
 
 /* CP15 CR11: DMA Operations for TCM Access */
 
 /* CP15 CR12:  */
+#define VBAR            p15,0,c12,c0,0  /* Vector Base Address Register */
 #define HVBAR           p15,4,c12,c0,0  /* Hyp. Vector Base Address Register */
 
 /* CP15 CR13:  */
 #define FCSEIDR         p15,0,c13,c0,0  /* FCSE Process ID Register */
 #define CONTEXTIDR      p15,0,c13,c0,1  /* Context ID Register */
-#define HTPIDR          p15,4,c13,c0,2  /* Hyp. Software Thread ID Register */
+#define TPIDRURW        p15,0,c13,c0,2  /* Software Thread ID, User, R/W */
+#define TPIDRURO        p15,0,c13,c0,3  /* Software Thread ID, User, R/O */
+#define TPIDRPRW        p15,0,c13,c0,4  /* Software Thread ID, Priveleged */
+#define HTPIDR          p15,4,c13,c0,2  /* HYp Software Thread Id Register */
 
 /* CP15 CR14:  */
 #define CNTPCT          p15,0,c14       /* Time counter value */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index f295a82..620b26e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -81,8 +81,37 @@ struct arch_vcpu
      */
     struct cpu_info *cpu_info;
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    /* Fault Status */
+    uint32_t dfar, ifar;
+    uint32_t dfsr, ifsr;
+    uint32_t adfsr, aifsr;
+
+    /* MMU */
+    uint32_t vbar;
+    uint32_t ttbcr;
+    uint32_t ttbr0, ttbr1;
+
+    uint32_t dacr;
+    uint64_t par;
+    uint32_t mair0, mair1;
+
+    /* Control Registers */
+    uint32_t actlr, sctlr;
+    uint32_t cpacr;
+
+    uint32_t contextidr;
+    uint32_t tpidrurw;
+    uint32_t tpidruro;
+    uint32_t tpidrprw;
+
+    uint32_t teecr, teehbr;
+    uint32_t joscr, jmcr;
+
+    /* CP 15 */
+    uint32_t csselr;
+
+    uint32_t gic_hcr, gic_vmcr, gic_apr;
+    uint32_t gic_lr[64];
 
     struct {
         struct vgic_irq_rank private_irqs;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e439727..e915cbf 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,9 @@ typedef uint32_t xen_ulong_t;
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
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 Jun 26 10:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjTI8-0008SU-Lt; Tue, 26 Jun 2012 10:46:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTI5-0008JK-Fh
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:7992] by server-10.bemta-3.messagelabs.com id
	F0/7C-01753-C0399EF4; Tue, 26 Jun 2012 10:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15805 invoked from network); 26 Jun 2012 10:46:35 -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;
	26 Jun 2012 10:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051824"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:00 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:00 -0400
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 1SjT26-00064E-Bb;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:56 +0000
Message-ID: <1340706604-1313-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 32/40] arm: the hyp timer seems to work in
	newer model versions, default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 437dc71..1587fa2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -27,8 +27,12 @@
 #include <xen/time.h>
 #include <asm/system.h>
 
-/* Unfortunately the hypervisor timer interrupt appears to be buggy */
-#define USE_HYP_TIMER 0
+/*
+ * Unfortunately the hypervisor timer interrupt appears to be buggy in
+ * some versions of the model. Disable this to use the physical timer
+ * instead.
+ */
+#define USE_HYP_TIMER 1
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-- 
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 Jun 26 10:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjTI8-0008SU-Lt; Tue, 26 Jun 2012 10:46:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTI5-0008JK-Fh
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:7992] by server-10.bemta-3.messagelabs.com id
	F0/7C-01753-C0399EF4; Tue, 26 Jun 2012 10:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15805 invoked from network); 26 Jun 2012 10:46:35 -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;
	26 Jun 2012 10:46:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051824"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:00 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:00 -0400
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 1SjT26-00064E-Bb;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:56 +0000
Message-ID: <1340706604-1313-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 32/40] arm: the hyp timer seems to work in
	newer model versions, default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 437dc71..1587fa2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -27,8 +27,12 @@
 #include <xen/time.h>
 #include <asm/system.h>
 
-/* Unfortunately the hypervisor timer interrupt appears to be buggy */
-#define USE_HYP_TIMER 0
+/*
+ * Unfortunately the hypervisor timer interrupt appears to be buggy in
+ * some versions of the model. Disable this to use the physical timer
+ * instead.
+ */
+#define USE_HYP_TIMER 1
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-- 
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 Jun 26 10:46:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTI9-0008Ta-7M; Tue, 26 Jun 2012 10:46: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 1SjTI5-0008LH-Ft
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:29664] by server-6.bemta-3.messagelabs.com id
	34/FA-11602-C0399EF4; Tue, 26 Jun 2012 10:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1320 invoked from network); 26 Jun 2012 10:46:36 -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;
	26 Jun 2012 10:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051810"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:55 -0400
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 1SjT25-00064E-8t;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:36 +0000
Message-ID: <1340706604-1313-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 12/40] arm: stub out sync_vcpu_execstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 do lazy exec state switching so there isn't actually anything to do.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/dummy.S  |    1 -
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index b099d91..2c3fc90 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -96,6 +96,11 @@ void sync_local_execstate(void)
     /* Nothing to do -- no lazy switching */
 }
 
+void sync_vcpu_execstate(struct vcpu *v)
+{
+    /* Nothing to do -- no lazy switching */
+}
+
 void startup_cpu_idle_loop(void)
 {
     struct vcpu *v = current;
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3b48917..8eddd15 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -22,7 +22,6 @@ DUMMY(pirq_set_affinity);
 /* VCPU */
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
 
-- 
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 Jun 26 10:46:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTI9-0008Ta-7M; Tue, 26 Jun 2012 10:46: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 1SjTI5-0008LH-Ft
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:37 +0000
Received: from [85.158.138.51:29664] by server-6.bemta-3.messagelabs.com id
	34/FA-11602-C0399EF4; Tue, 26 Jun 2012 10:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1320 invoked from network); 26 Jun 2012 10:46:36 -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;
	26 Jun 2012 10:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051810"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:55 -0400
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 1SjT25-00064E-8t;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:36 +0000
Message-ID: <1340706604-1313-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 12/40] arm: stub out sync_vcpu_execstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 do lazy exec state switching so there isn't actually anything to do.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/dummy.S  |    1 -
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index b099d91..2c3fc90 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -96,6 +96,11 @@ void sync_local_execstate(void)
     /* Nothing to do -- no lazy switching */
 }
 
+void sync_vcpu_execstate(struct vcpu *v)
+{
+    /* Nothing to do -- no lazy switching */
+}
+
 void startup_cpu_idle_loop(void)
 {
     struct vcpu *v = current;
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3b48917..8eddd15 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -22,7 +22,6 @@ DUMMY(pirq_set_affinity);
 /* VCPU */
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
-DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
 DUMMY(vcpu_show_execution_state);
 
-- 
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 Jun 26 10:46:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTIA-0008VN-2v; Tue, 26 Jun 2012 10:46:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTI6-0008LH-2k
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:38 +0000
Received: from [85.158.138.51:8107] by server-6.bemta-3.messagelabs.com id
	F7/FA-11602-D0399EF4; Tue, 26 Jun 2012 10:46:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15929 invoked from network); 26 Jun 2012 10:46:36 -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;
	26 Jun 2012 10:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051819"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:00 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:00 -0400
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 1SjT25-00064E-Cn;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:39 +0000
Message-ID: <1340706604-1313-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 15/40] arm: Add simple cpu_{sibling,
	core}_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

This needs to be done for all cpus. The allocations require smp_prepare_cpus
to be called a bit later on.

In a previous version of this patch these maps were being zeroed (instead of
setting the CPU itself in them). This in turn causes cpumask_first to return
NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
read off the end of its cnt array.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/dummy.S   |    2 --
 xen/arch/arm/setup.c   |    4 ++--
 xen/arch/arm/smpboot.c |   21 +++++++++++++++++++++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index c001e8d..03f7489 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 81ababb..d6c0178 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -173,8 +173,6 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    smp_prepare_cpus(cpus);
-
     init_xen_time();
 
     setup_mm(atag_paddr, fdt_size);
@@ -214,6 +212,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     local_irq_enable();
 
+    smp_prepare_cpus(cpus);
+
     initialize_keytable();
 
     console_init_postirq();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ea05afc..6463a8d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,6 +52,23 @@ unsigned long __initdata ready_cpus = 0;
 
 /* ID of the PCPU we're running on */
 DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awfully x86ish... */
+/* representing HT siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
+/* representing HT and core siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
+
+static void setup_cpu_sibling_map(int cpu)
+{
+    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) ||
+         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) )
+        panic("No memory for CPU sibling/core maps\n");
+
+    /* A CPU is a sibling with itself and is always on its own core. */
+    cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
+    cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
+}
+
 
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
@@ -65,6 +82,8 @@ smp_prepare_cpus (unsigned int max_cpus)
     for ( i = 0; i < max_cpus; i++ )
         cpumask_set_cpu(i, &cpu_possible_map);
     cpumask_copy(&cpu_present_map, &cpu_possible_map);
+
+    setup_cpu_sibling_map(0);
 }
 
 void __init
@@ -115,6 +134,8 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
 
     set_current(idle_vcpu[cpuid]);
 
+    setup_cpu_sibling_map(cpuid);
+
     /* Run local notifiers */
     notify_cpu_starting(cpuid);
     wmb();
-- 
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 Jun 26 10:46:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTIA-0008VN-2v; Tue, 26 Jun 2012 10:46:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTI6-0008LH-2k
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:38 +0000
Received: from [85.158.138.51:8107] by server-6.bemta-3.messagelabs.com id
	F7/FA-11602-D0399EF4; Tue, 26 Jun 2012 10:46:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15929 invoked from network); 26 Jun 2012 10:46:36 -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;
	26 Jun 2012 10:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051819"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:00 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:00 -0400
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 1SjT25-00064E-Cn;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:39 +0000
Message-ID: <1340706604-1313-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 15/40] arm: Add simple cpu_{sibling,
	core}_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

This needs to be done for all cpus. The allocations require smp_prepare_cpus
to be called a bit later on.

In a previous version of this patch these maps were being zeroed (instead of
setting the CPU itself in them). This in turn causes cpumask_first to return
NR_CPUS, which in turn was causing default_vcpu0_location to misbehave and
read off the end of its cnt array.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/dummy.S   |    2 --
 xen/arch/arm/setup.c   |    4 ++--
 xen/arch/arm/smpboot.c |   21 +++++++++++++++++++++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index c001e8d..03f7489 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -7,8 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 81ababb..d6c0178 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -173,8 +173,6 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    smp_prepare_cpus(cpus);
-
     init_xen_time();
 
     setup_mm(atag_paddr, fdt_size);
@@ -214,6 +212,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     local_irq_enable();
 
+    smp_prepare_cpus(cpus);
+
     initialize_keytable();
 
     console_init_postirq();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ea05afc..6463a8d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,6 +52,23 @@ unsigned long __initdata ready_cpus = 0;
 
 /* ID of the PCPU we're running on */
 DEFINE_PER_CPU(unsigned int, cpu_id);
+/* XXX these seem awfully x86ish... */
+/* representing HT siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
+/* representing HT and core siblings of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
+
+static void setup_cpu_sibling_map(int cpu)
+{
+    if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) ||
+         !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) )
+        panic("No memory for CPU sibling/core maps\n");
+
+    /* A CPU is a sibling with itself and is always on its own core. */
+    cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
+    cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
+}
+
 
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
@@ -65,6 +82,8 @@ smp_prepare_cpus (unsigned int max_cpus)
     for ( i = 0; i < max_cpus; i++ )
         cpumask_set_cpu(i, &cpu_possible_map);
     cpumask_copy(&cpu_present_map, &cpu_possible_map);
+
+    setup_cpu_sibling_map(0);
 }
 
 void __init
@@ -115,6 +134,8 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
 
     set_current(idle_vcpu[cpuid]);
 
+    setup_cpu_sibling_map(cpuid);
+
     /* Run local notifiers */
     notify_cpu_starting(cpuid);
     wmb();
-- 
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 Jun 26 10:46:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIA-00005L-Nz; Tue, 26 Jun 2012 10:46:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTI6-0008I3-B3
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:38 +0000
Received: from [85.158.138.51:8203] by server-9.bemta-3.messagelabs.com id
	96/80-10419-E0399EF4; Tue, 26 Jun 2012 10:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15996 invoked from network); 26 Jun 2012 10:46:37 -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;
	26 Jun 2012 10:46:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:04 -0400
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 1SjT25-00064E-T2;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:48 +0000
Message-ID: <1340706604-1313-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 24/40] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For some reason we were holding the lock over only the unmaps at the end of
the function, rather than for the whole walk.

We might want to be more clever in the future, but for now lets just lock for
the whole walk+create process.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/p2m.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 35bfa2f..5f20246 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -132,6 +132,8 @@ static int create_p2m_entries(struct domain *d,
     paddr_t addr;
     unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
 
+    spin_lock(&p2m->lock);
+
     /* XXX Don't actually handle 40 bit guest physical addresses */
     BUG_ON(start_gpaddr & 0x8000000000ULL);
     BUG_ON(end_gpaddr   & 0x8000000000ULL);
@@ -213,8 +215,6 @@ static int create_p2m_entries(struct domain *d,
     rc = 0;
 
 out:
-    spin_lock(&p2m->lock);
-
     if (third) unmap_domain_page(third);
     if (second) unmap_domain_page(second);
     if (first) unmap_domain_page(first);
-- 
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 Jun 26 10:46:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIA-00005L-Nz; Tue, 26 Jun 2012 10:46:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjTI6-0008I3-B3
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:38 +0000
Received: from [85.158.138.51:8203] by server-9.bemta-3.messagelabs.com id
	96/80-10419-E0399EF4; Tue, 26 Jun 2012 10:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15996 invoked from network); 26 Jun 2012 10:46:37 -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;
	26 Jun 2012 10:46:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:04 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:04 -0400
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 1SjT25-00064E-T2;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:48 +0000
Message-ID: <1340706604-1313-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 24/40] arm: fix locking in create_p2m_entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For some reason we were holding the lock over only the unmaps at the end of
the function, rather than for the whole walk.

We might want to be more clever in the future, but for now lets just lock for
the whole walk+create process.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/p2m.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 35bfa2f..5f20246 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -132,6 +132,8 @@ static int create_p2m_entries(struct domain *d,
     paddr_t addr;
     unsigned long cur_first_offset = ~0, cur_second_offset = ~0;
 
+    spin_lock(&p2m->lock);
+
     /* XXX Don't actually handle 40 bit guest physical addresses */
     BUG_ON(start_gpaddr & 0x8000000000ULL);
     BUG_ON(end_gpaddr   & 0x8000000000ULL);
@@ -213,8 +215,6 @@ static int create_p2m_entries(struct domain *d,
     rc = 0;
 
 out:
-    spin_lock(&p2m->lock);
-
     if (third) unmap_domain_page(third);
     if (second) unmap_domain_page(second);
     if (first) unmap_domain_page(first);
-- 
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 Jun 26 10:46:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIB-00006T-7o; Tue, 26 Jun 2012 10:46: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 1SjTI6-0008Mm-91
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:38 +0000
Received: from [85.158.138.51:29829] by server-11.bemta-3.messagelabs.com id
	B6/9C-02904-D0399EF4; Tue, 26 Jun 2012 10:46:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1407 invoked from network); 26 Jun 2012 10:46:36 -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;
	26 Jun 2012 10:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051827"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:02 -0400
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 1SjT26-00064E-II;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:59 +0000
Message-ID: <1340706604-1313-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 35/40] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/entry.S            |    1 +
 xen/include/asm-arm/page.h      |    2 ++
 xen/include/asm-arm/processor.h |   21 ---------------------
 xen/include/asm-arm/system.h    |    2 +-
 xen/include/public/arch-arm.h   |   23 ++++++++++++++++++++++-
 5 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 5bc3906..2ff32a1 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
+#include <public/xen.h>
 
 #define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
 #define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 2b6c1780..f3e4d1a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -2,6 +2,8 @@
 #define __ARM_PAGE_H__
 
 #include <xen/config.h>
+#include <public/xen.h>
+#include <asm/processor.h>
 
 #define PADDR_BITS              40
 #define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9b3c9dd..3849b23 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -3,27 +3,6 @@
 
 #include <asm/cpregs.h>
 
-/* PSR bits (CPSR, SPSR)*/
-
-/* 0-4: Mode */
-#define PSR_MODE_MASK 0x1f
-#define PSR_MODE_USR 0x10
-#define PSR_MODE_FIQ 0x11
-#define PSR_MODE_IRQ 0x12
-#define PSR_MODE_SVC 0x13
-#define PSR_MODE_MON 0x16
-#define PSR_MODE_ABT 0x17
-#define PSR_MODE_HYP 0x1a
-#define PSR_MODE_UND 0x1b
-#define PSR_MODE_SYS 0x1f
-
-#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 */
-#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
-
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 7963ea5..216ef1f 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -3,7 +3,7 @@
 #define __ASM_SYSTEM_H
 
 #include <xen/lib.h>
-#include <asm/processor.h>
+#include <public/arch-arm.h>
 
 #define nop() \
     asm volatile ( "nop" )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index b52bfc7..7ebe966 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -139,7 +139,28 @@ struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif
+#endif /* ifndef __ASSEMBLY __ */
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#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 */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
-- 
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 Jun 26 10:46:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIB-00006T-7o; Tue, 26 Jun 2012 10:46: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 1SjTI6-0008Mm-91
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:38 +0000
Received: from [85.158.138.51:29829] by server-11.bemta-3.messagelabs.com id
	B6/9C-02904-D0399EF4; Tue, 26 Jun 2012 10:46:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1407 invoked from network); 26 Jun 2012 10:46:36 -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;
	26 Jun 2012 10:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051827"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:02 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:02 -0400
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 1SjT26-00064E-II;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:59 +0000
Message-ID: <1340706604-1313-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 35/40] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/entry.S            |    1 +
 xen/include/asm-arm/page.h      |    2 ++
 xen/include/asm-arm/processor.h |   21 ---------------------
 xen/include/asm-arm/system.h    |    2 +-
 xen/include/public/arch-arm.h   |   23 ++++++++++++++++++++++-
 5 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 5bc3906..2ff32a1 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
+#include <public/xen.h>
 
 #define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
 #define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 2b6c1780..f3e4d1a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -2,6 +2,8 @@
 #define __ARM_PAGE_H__
 
 #include <xen/config.h>
+#include <public/xen.h>
+#include <asm/processor.h>
 
 #define PADDR_BITS              40
 #define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9b3c9dd..3849b23 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -3,27 +3,6 @@
 
 #include <asm/cpregs.h>
 
-/* PSR bits (CPSR, SPSR)*/
-
-/* 0-4: Mode */
-#define PSR_MODE_MASK 0x1f
-#define PSR_MODE_USR 0x10
-#define PSR_MODE_FIQ 0x11
-#define PSR_MODE_IRQ 0x12
-#define PSR_MODE_SVC 0x13
-#define PSR_MODE_MON 0x16
-#define PSR_MODE_ABT 0x17
-#define PSR_MODE_HYP 0x1a
-#define PSR_MODE_UND 0x1b
-#define PSR_MODE_SYS 0x1f
-
-#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 */
-#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
-
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 7963ea5..216ef1f 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -3,7 +3,7 @@
 #define __ASM_SYSTEM_H
 
 #include <xen/lib.h>
-#include <asm/processor.h>
+#include <public/arch-arm.h>
 
 #define nop() \
     asm volatile ( "nop" )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index b52bfc7..7ebe966 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -139,7 +139,28 @@ struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif
+#endif /* ifndef __ASSEMBLY __ */
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#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 */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
-- 
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 Jun 26 10:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTIC-00009g-LS; Tue, 26 Jun 2012 10:46: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 1SjTI7-0008LH-70
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:39 +0000
Received: from [85.158.138.51:29984] by server-6.bemta-3.messagelabs.com id
	F5/0B-11602-E0399EF4; Tue, 26 Jun 2012 10:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340707595!21415337!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7949 invoked from network); 26 Jun 2012 10:46:38 -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;
	26 Jun 2012 10:46:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051854"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:08 -0400
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 1SjT25-00064E-Np;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:45 +0000
Message-ID: <1340706604-1313-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 21/40] arm: implement
	vcpu_show_execution_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 03f7489..cab9522 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
 DUMMY(get_page);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d8eb5a9..f5f43da 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
     panic("Error during %s-to-physical address translation\n", when);
 }
 
-void show_registers(struct cpu_user_regs *regs)
+struct reg_ctxt {
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+};
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
     print_xen_info();
     printk("CPU:    %d\n", smp_processor_id());
     printk("PC:     %08"PRIx32, regs->pc);
-    if ( !guest_mode(regs) )
+    if ( !guest_mode )
             print_symbol(" %s", regs->pc);
     printk("\n");
     printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
@@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
     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);
 
-    if ( guest_mode(regs) )
+    if ( guest_mode )
     {
         printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
                regs->sp_usr, regs->lr_usr, regs->cpsr);
@@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
                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",
-               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
-        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
         printk("\n");
     }
@@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
     printk("\n");
 }
 
+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);
+    _show_registers(regs, &ctxt, guest_mode(regs));
+}
+
+void vcpu_show_registers(const struct vcpu *v)
+{
+    struct reg_ctxt ctxt;
+    ctxt.sctlr = v->arch.sctlr;
+    ctxt.ttbcr = 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);
+}
+
 static void show_guest_stack(struct cpu_user_regs *regs)
 {
     printk("GUEST STACK GOES HERE\n");
@@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
     show_stack(regs);
 }
 
+void vcpu_show_execution_state(struct vcpu *v)
+{
+    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
+           v->domain->domain_id, v->vcpu_id);
+
+    if ( v == current )
+    {
+        show_execution_state(guest_cpu_user_regs());
+        return;
+    }
+
+    vcpu_pause(v); /* acceptably dangerous */
+
+    vcpu_show_registers(v);
+    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
+        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
+
+    vcpu_unpause(v);
+}
+
 static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
-- 
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 Jun 26 10:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTIC-00009g-LS; Tue, 26 Jun 2012 10:46: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 1SjTI7-0008LH-70
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:39 +0000
Received: from [85.158.138.51:29984] by server-6.bemta-3.messagelabs.com id
	F5/0B-11602-E0399EF4; Tue, 26 Jun 2012 10:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340707595!21415337!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7949 invoked from network); 26 Jun 2012 10:46:38 -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;
	26 Jun 2012 10:46:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051854"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:08 -0400
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 1SjT25-00064E-Np;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:45 +0000
Message-ID: <1340706604-1313-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 21/40] arm: implement
	vcpu_show_execution_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 03f7489..cab9522 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
 DUMMY(get_page);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d8eb5a9..f5f43da 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
     panic("Error during %s-to-physical address translation\n", when);
 }
 
-void show_registers(struct cpu_user_regs *regs)
+struct reg_ctxt {
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+};
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
     print_xen_info();
     printk("CPU:    %d\n", smp_processor_id());
     printk("PC:     %08"PRIx32, regs->pc);
-    if ( !guest_mode(regs) )
+    if ( !guest_mode )
             print_symbol(" %s", regs->pc);
     printk("\n");
     printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
@@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
     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);
 
-    if ( guest_mode(regs) )
+    if ( guest_mode )
     {
         printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
                regs->sp_usr, regs->lr_usr, regs->cpsr);
@@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
                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",
-               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
-        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
         printk("\n");
     }
@@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
     printk("\n");
 }
 
+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);
+    _show_registers(regs, &ctxt, guest_mode(regs));
+}
+
+void vcpu_show_registers(const struct vcpu *v)
+{
+    struct reg_ctxt ctxt;
+    ctxt.sctlr = v->arch.sctlr;
+    ctxt.ttbcr = 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);
+}
+
 static void show_guest_stack(struct cpu_user_regs *regs)
 {
     printk("GUEST STACK GOES HERE\n");
@@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
     show_stack(regs);
 }
 
+void vcpu_show_execution_state(struct vcpu *v)
+{
+    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
+           v->domain->domain_id, v->vcpu_id);
+
+    if ( v == current )
+    {
+        show_execution_state(guest_cpu_user_regs());
+        return;
+    }
+
+    vcpu_pause(v); /* acceptably dangerous */
+
+    vcpu_show_registers(v);
+    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
+        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
+
+    vcpu_unpause(v);
+}
+
 static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
-- 
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 Jun 26 10:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIB-00007i-Q8; Tue, 26 Jun 2012 10:46: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 1SjTI6-0008NU-Lk
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:39 +0000
Received: from [85.158.138.51:29870] by server-1.bemta-3.messagelabs.com id
	F2/6B-14648-D0399EF4; Tue, 26 Jun 2012 10:46:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340707595!21415337!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7869 invoked from network); 26 Jun 2012 10:46: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;
	26 Jun 2012 10:46:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051812"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:57 -0400
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 1SjT26-00064E-24;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:51 +0000
Message-ID: <1340706604-1313-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 27/40] arm: map GICV in all domains,
	not just 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

This requires that we allocate all p2m pages from domheap without a particular
dom because max pages is not setup yet so there is no allocation available to
us.

At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.

Also we seem to have been calling p2m_alloc_table twice for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c       |   10 +++++++---
 xen/arch/arm/domain_build.c |    5 -----
 xen/arch/arm/gic.c          |    7 ++-----
 xen/arch/arm/gic.h          |    2 +-
 xen/arch/arm/p2m.c          |    3 ++-
 5 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d11be78..a7b7d4a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -323,10 +323,13 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         if ( (rc = p2m_alloc_table(d)) != 0 )
             goto fail;
-    }
 
-    if ( (rc = domain_vgic_init(d)) != 0 )
-        goto fail;
+        if ( (rc = gicv_setup(d)) != 0 )
+            goto fail;
+
+        if ( (rc = domain_vgic_init(d)) != 0 )
+            goto fail;
+    }
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
@@ -334,6 +337,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     rc = 0;
 fail:
+    /*XXX unwind allocations etc */
     return rc;
 }
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72e775c..1b19e54 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
 
     d->max_pages = ~0U;
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
-        return rc;
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
@@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
     printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
     map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
 
-    gicv_setup(d);
-
     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
     gic_route_irq_to_guest(d, 34, "timer0");
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..47995b4 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -541,14 +541,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     do_IRQ(regs, irq, is_fiq);
 }
 
-void gicv_setup(struct domain *d)
+int gicv_setup(struct domain *d)
 {
     /* map the gic virtual cpu interface in the gic cpu interface region of
      * the guest */
-    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
-           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
-           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
-    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
                         GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..018d820 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
-extern void gicv_setup(struct domain *d);
+extern int gicv_setup(struct domain *d);
 
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5f20246..67bfeba 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
+#include "gic.h"
 
 void dump_p2m_lookup(struct domain *d, paddr_t addr)
 {
@@ -102,7 +103,7 @@ static int p2m_create_table(struct domain *d,
 
     BUG_ON(entry->p2m.valid);
 
-    page = alloc_domheap_page(d, 0);
+    page = alloc_domheap_page(NULL, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 26 10:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIB-00007i-Q8; Tue, 26 Jun 2012 10:46: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 1SjTI6-0008NU-Lk
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:39 +0000
Received: from [85.158.138.51:29870] by server-1.bemta-3.messagelabs.com id
	F2/6B-14648-D0399EF4; Tue, 26 Jun 2012 10:46:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340707595!21415337!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7869 invoked from network); 26 Jun 2012 10:46: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;
	26 Jun 2012 10:46:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051812"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:45:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:45:57 -0400
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 1SjT26-00064E-24;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:51 +0000
Message-ID: <1340706604-1313-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 27/40] arm: map GICV in all domains,
	not just 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

This requires that we allocate all p2m pages from domheap without a particular
dom because max pages is not setup yet so there is no allocation available to
us.

At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.

Also we seem to have been calling p2m_alloc_table twice for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c       |   10 +++++++---
 xen/arch/arm/domain_build.c |    5 -----
 xen/arch/arm/gic.c          |    7 ++-----
 xen/arch/arm/gic.h          |    2 +-
 xen/arch/arm/p2m.c          |    3 ++-
 5 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d11be78..a7b7d4a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -323,10 +323,13 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         if ( (rc = p2m_alloc_table(d)) != 0 )
             goto fail;
-    }
 
-    if ( (rc = domain_vgic_init(d)) != 0 )
-        goto fail;
+        if ( (rc = gicv_setup(d)) != 0 )
+            goto fail;
+
+        if ( (rc = domain_vgic_init(d)) != 0 )
+            goto fail;
+    }
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
@@ -334,6 +337,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     rc = 0;
 fail:
+    /*XXX unwind allocations etc */
     return rc;
 }
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72e775c..1b19e54 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
 
     d->max_pages = ~0U;
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
-        return rc;
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
@@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
     printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
     map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
 
-    gicv_setup(d);
-
     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
     gic_route_irq_to_guest(d, 34, "timer0");
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..47995b4 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -541,14 +541,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     do_IRQ(regs, irq, is_fiq);
 }
 
-void gicv_setup(struct domain *d)
+int gicv_setup(struct domain *d)
 {
     /* map the gic virtual cpu interface in the gic cpu interface region of
      * the guest */
-    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
-           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
-           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
-    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
                         GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..018d820 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
-extern void gicv_setup(struct domain *d);
+extern int gicv_setup(struct domain *d);
 
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5f20246..67bfeba 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
+#include "gic.h"
 
 void dump_p2m_lookup(struct domain *d, paddr_t addr)
 {
@@ -102,7 +103,7 @@ static int p2m_create_table(struct domain *d,
 
     BUG_ON(entry->p2m.valid);
 
-    page = alloc_domheap_page(d, 0);
+    page = alloc_domheap_page(NULL, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Jun 26 10:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTID-0000CB-M5; Tue, 26 Jun 2012 10:46: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 1SjTI7-0008Oy-SR
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:40 +0000
Received: from [85.158.138.51:29958] by server-3.bemta-3.messagelabs.com id
	64/73-26490-E0399EF4; Tue, 26 Jun 2012 10:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16055 invoked from network); 26 Jun 2012 10:46:38 -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;
	26 Jun 2012 10:46:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:09 -0400
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 1SjT26-00064E-Fh;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:58 +0000
Message-ID: <1340706604-1313-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 34/40] HACK: arm: initial
	XENMAPSPACE_gmfn_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

Should use same interface as hybrid x86.
---
 xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
 xen/arch/x86/mm.c             |    2 ++
 xen/include/public/arch-arm.h |    1 +
 xen/include/public/memory.h   |   12 +++++++-----
 4 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 40ac176..d369ee3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -470,12 +470,32 @@ static int xenmem_add_to_physmap_once(
 
     switch ( xatp->space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( xatp->idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+
+        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            printk("bad p2m lookup\n");
+            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+        mfn = maddr >> PAGE_SHIFT;
+        rcu_unlock_domain(od);
+        break;
+    }
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c543f03..8190fa0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4573,6 +4573,8 @@ static int xenmem_add_to_physmap_once(
             mfn = idx;
             page = mfn_to_page(mfn);
             break;
+        case XENMAPSPACE_gmfn_foreign:
+            return -ENOSYS;
         }
         default:
             break;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e915cbf..b52bfc7 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
 #define XEN_LEGACY_MAX_VCPUS 1
 
 typedef uint32_t xen_ulong_t;
+#define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-- 
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 Jun 26 10:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTID-0000CB-M5; Tue, 26 Jun 2012 10:46: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 1SjTI7-0008Oy-SR
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:40 +0000
Received: from [85.158.138.51:29958] by server-3.bemta-3.messagelabs.com id
	64/73-26490-E0399EF4; Tue, 26 Jun 2012 10:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340707593!20669886!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16055 invoked from network); 26 Jun 2012 10:46:38 -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;
	26 Jun 2012 10:46:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:09 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:09 -0400
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 1SjT26-00064E-Fh;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:58 +0000
Message-ID: <1340706604-1313-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 34/40] HACK: arm: initial
	XENMAPSPACE_gmfn_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

Should use same interface as hybrid x86.
---
 xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
 xen/arch/x86/mm.c             |    2 ++
 xen/include/public/arch-arm.h |    1 +
 xen/include/public/memory.h   |   12 +++++++-----
 4 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 40ac176..d369ee3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -470,12 +470,32 @@ static int xenmem_add_to_physmap_once(
 
     switch ( xatp->space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( xatp->idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+
+        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            printk("bad p2m lookup\n");
+            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+        mfn = maddr >> PAGE_SHIFT;
+        rcu_unlock_domain(od);
+        break;
+    }
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c543f03..8190fa0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4573,6 +4573,8 @@ static int xenmem_add_to_physmap_once(
             mfn = idx;
             page = mfn_to_page(mfn);
             break;
+        case XENMAPSPACE_gmfn_foreign:
+            return -ENOSYS;
         }
         default:
             break;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e915cbf..b52bfc7 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
 #define XEN_LEGACY_MAX_VCPUS 1
 
 typedef uint32_t xen_ulong_t;
+#define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-- 
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 Jun 26 10:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIE-0000FQ-Sf; Tue, 26 Jun 2012 10:46: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 1SjTI8-0008Oy-Eg
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:40 +0000
Received: from [85.158.138.51:30089] by server-3.bemta-3.messagelabs.com id
	A9/73-26490-F0399EF4; Tue, 26 Jun 2012 10:46:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1500 invoked from network); 26 Jun 2012 10:46:37 -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;
	26 Jun 2012 10:46:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051850"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:06 -0400
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 1SjT26-00064E-Qh;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:04 +0000
Message-ID: <1340706604-1313-40-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 40/40] HACK: arm: disable hypercall
	continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/sched.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..15fa6b4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
 
+#ifdef CONFIG_ARM
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
-- 
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 Jun 26 10:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:46: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 1SjTIE-0000FQ-Sf; Tue, 26 Jun 2012 10:46: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 1SjTI8-0008Oy-Eg
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:46:40 +0000
Received: from [85.158.138.51:30089] by server-3.bemta-3.messagelabs.com id
	A9/73-26490-F0399EF4; Tue, 26 Jun 2012 10:46:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340707592!29472199!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjIyNjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1500 invoked from network); 26 Jun 2012 10:46:37 -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;
	26 Jun 2012 10:46:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="200051850"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:06 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:06 -0400
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 1SjT26-00064E-Qh;
	Tue, 26 Jun 2012 11:30:06 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:30:04 +0000
Message-ID: <1340706604-1313-40-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 40/40] HACK: arm: disable hypercall
	continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/sched.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..15fa6b4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
 
+#ifdef CONFIG_ARM
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
-- 
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 Jun 26 10:47:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTJ4-0001eR-SJ; Tue, 26 Jun 2012 10:47: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 1SjTJ3-0001cU-GC
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:47:37 +0000
Received: from [85.158.143.35:54291] by server-2.bemta-4.messagelabs.com id
	28/3F-17938-84399EF4; Tue, 26 Jun 2012 10:47:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340707567!6696361!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16902 invoked from network); 26 Jun 2012 10:46:09 -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;
	26 Jun 2012 10:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427231"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:08 -0400
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 1SjT25-00064E-BU;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:38 +0000
Message-ID: <1340706604-1313-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 14/40] arm: do not set max_vcpus = 8 in
	arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
smaller guest.

The limit of 8 (due to GIC limits) should be expressed in MAX_VIRT_CPUS.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c        |    2 --
 xen/include/asm-arm/config.h |    2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2c3fc90..63bad07 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,8 +212,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
     }
 
-    d->max_vcpus = 8;
-
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 91e87e1..7d02cc7 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -27,7 +27,7 @@
 #define NR_CPUS 128
 #endif
 
-#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_VIRT_CPUS 8
 #define MAX_HVM_VCPUS MAX_VIRT_CPUS
 
 #define asmlinkage /* Nothing needed */
-- 
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 Jun 26 10:47:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10: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 1SjTJ4-0001eR-SJ; Tue, 26 Jun 2012 10:47: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 1SjTJ3-0001cU-GC
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:47:37 +0000
Received: from [85.158.143.35:54291] by server-2.bemta-4.messagelabs.com id
	28/3F-17938-84399EF4; Tue, 26 Jun 2012 10:47:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340707567!6696361!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16902 invoked from network); 26 Jun 2012 10:46:09 -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;
	26 Jun 2012 10:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336363200"; d="scan'208";a="29427231"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 06:46:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 06:46:08 -0400
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 1SjT25-00064E-BU;
	Tue, 26 Jun 2012 11:30:05 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 10:29:38 +0000
Message-ID: <1340706604-1313-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 14/40] arm: do not set max_vcpus = 8 in
	arch_domain_create.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XEN_DOMCTL_max_vcpus cannot reduce max_vcpus and therefore we can't create a
smaller guest.

The limit of 8 (due to GIC limits) should be expressed in MAX_VIRT_CPUS.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c        |    2 --
 xen/include/asm-arm/config.h |    2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2c3fc90..63bad07 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -212,8 +212,6 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
     }
 
-    d->max_vcpus = 8;
-
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 91e87e1..7d02cc7 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -27,7 +27,7 @@
 #define NR_CPUS 128
 #endif
 
-#define MAX_VIRT_CPUS 128 /* XXX */
+#define MAX_VIRT_CPUS 8
 #define MAX_HVM_VCPUS MAX_VIRT_CPUS
 
 #define asmlinkage /* Nothing needed */
-- 
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 Jun 26 10:54:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:54: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 1SjTPo-0004MG-0G; Tue, 26 Jun 2012 10:54: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 1SjTPm-0004Lx-Dd
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:54:34 +0000
Received: from [85.158.143.99:25779] by server-1.bemta-4.messagelabs.com id
	42/45-24392-9E499EF4; Tue, 26 Jun 2012 10:54:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340708072!22133899!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32748 invoked from network); 26 Jun 2012 10:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13220254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:54:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:54:32 +0100
Message-ID: <1340708071.3832.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 11:54:31 +0100
In-Reply-To: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
> parameter. This patch changes the ownership of the buifioreq event channel to
> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
> 
> This fix the initialization of QEMU inside the stubdomain.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

This fixes stub domains for me, thanks.

The user of this field (hvm_buffered_io_send) takes iorp->lock so we
probably want to put the update inside that too, just like for the
non-buffered case?

It would be nice to extract the alloc&replace functionality into a
helper.

Ian.


> ---
>  xen/arch/x86/hvm/hvm.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e0d495d..9ff1ded 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3788,6 +3788,22 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>                      /* xchg() ensures that only we free_xen_event_channel() */
>                      old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
>                      free_xen_event_channel(v, old_port);
> +
> +                    if ( v->vcpu_id == 0 )
> +                    {
> +                        new_port = alloc_unbound_xen_event_channel(
> +                            v, a.value, NULL);
> +                        if ( new_port < 0 )
> +                        {
> +                            rc = new_port;
> +                            break;
> +                        }
> +                        old_port = xchg(
> +                            &v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN],
> +                            new_port);
> +                        free_xen_event_channel(v, old_port);
> +                    }
> +
>                      spin_lock(&iorp->lock);
>                      if ( iorp->va != NULL )
>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 10:54:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 10:54: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 1SjTPo-0004MG-0G; Tue, 26 Jun 2012 10:54: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 1SjTPm-0004Lx-Dd
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 10:54:34 +0000
Received: from [85.158.143.99:25779] by server-1.bemta-4.messagelabs.com id
	42/45-24392-9E499EF4; Tue, 26 Jun 2012 10:54:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340708072!22133899!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32748 invoked from network); 26 Jun 2012 10:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 10:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13220254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 10:54:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:54:32 +0100
Message-ID: <1340708071.3832.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 11:54:31 +0100
In-Reply-To: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
> parameter. This patch changes the ownership of the buifioreq event channel to
> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
> 
> This fix the initialization of QEMU inside the stubdomain.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

This fixes stub domains for me, thanks.

The user of this field (hvm_buffered_io_send) takes iorp->lock so we
probably want to put the update inside that too, just like for the
non-buffered case?

It would be nice to extract the alloc&replace functionality into a
helper.

Ian.


> ---
>  xen/arch/x86/hvm/hvm.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e0d495d..9ff1ded 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3788,6 +3788,22 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>                      /* xchg() ensures that only we free_xen_event_channel() */
>                      old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
>                      free_xen_event_channel(v, old_port);
> +
> +                    if ( v->vcpu_id == 0 )
> +                    {
> +                        new_port = alloc_unbound_xen_event_channel(
> +                            v, a.value, NULL);
> +                        if ( new_port < 0 )
> +                        {
> +                            rc = new_port;
> +                            break;
> +                        }
> +                        old_port = xchg(
> +                            &v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN],
> +                            new_port);
> +                        free_xen_event_channel(v, old_port);
> +                    }
> +
>                      spin_lock(&iorp->lock);
>                      if ( iorp->va != NULL )
>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 11:04:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 11:04: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 1SjTZ4-0004q7-2U; Tue, 26 Jun 2012 11: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.Jackson@eu.citrix.com>) id 1SjTZ2-0004q2-E2
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 11:04:08 +0000
Received: from [85.158.139.83:7693] by server-6.bemta-5.messagelabs.com id
	D1/E5-11348-72799EF4; Tue, 26 Jun 2012 11:04:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340708646!18294511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26709 invoked from network); 26 Jun 2012 11:04:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 11:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13220611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 11:03:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 12:03:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjTYO-0006Oj-P9; Tue, 26 Jun 2012 11:03:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjTYO-0000Lf-Mt;
	Tue, 26 Jun 2012 12:03:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.38656.696529.142496@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 12:03:28 +0100
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
	<CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic placement of guests on NUMA nodes"):
> The only potential concern is that it seems likely that your
> comparison function above will not actually generate an ordering,
> because the relationship it generates isn't transitive.  That is, you
> could have a situation where A > B, B > C, but C > A.  For example:
> A: freemem 1000, domains 1
> B: freemem 1090, domains 2
> C: freemem 1110, domains 3
> 
> In this case, A>B, because memory is within 10% but has fewer domains.
>  B > C, because B is within 10%, and has fewer domains.  But C > A,
> because C has more than 10% more memory than A (so its domains are not
> counted against it).

The conventional approach to this kind of thing is to invent a score
for sorting etc.  Something like
    score = tuning_parameter * log(freemem) - number_of_domains
which does sort of roughly the same as your 10% rule if you squint.

Or maybe you want to take the log of the number_of_domains too, which
would be equivalent for sorting to
    score = freemem / (number_of_domains + other_tuning_parameter)

>  This may give you strange results from your quicksort.  But it's
> likely to give something *reasonable* anyway.  (And if it turns out to
> cause problems, a bubble sort shouldn't be too expensive and will
> likely to be more robust against this kind of quirkiness.)

The behaviour of sorting functions when giving broken comparison
functions may be entirely arbitrary and is not guaranteed to be
anything near the plausible intended orderings.  If you're using qsort
you're not guaranteed that any particular algorithm will be used, so
you can't make any assumptions about its behaviour in this case.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 11:04:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 11:04: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 1SjTZ4-0004q7-2U; Tue, 26 Jun 2012 11: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.Jackson@eu.citrix.com>) id 1SjTZ2-0004q2-E2
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 11:04:08 +0000
Received: from [85.158.139.83:7693] by server-6.bemta-5.messagelabs.com id
	D1/E5-11348-72799EF4; Tue, 26 Jun 2012 11:04:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340708646!18294511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26709 invoked from network); 26 Jun 2012 11:04:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 11:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,476,1336348800"; d="scan'208";a="13220611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 11:03:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 12:03:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjTYO-0006Oj-P9; Tue, 26 Jun 2012 11:03:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjTYO-0000Lf-Mt;
	Tue, 26 Jun 2012 12:03:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.38656.696529.142496@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 12:03:28 +0100
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
	<CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic placement of guests on NUMA nodes"):
> The only potential concern is that it seems likely that your
> comparison function above will not actually generate an ordering,
> because the relationship it generates isn't transitive.  That is, you
> could have a situation where A > B, B > C, but C > A.  For example:
> A: freemem 1000, domains 1
> B: freemem 1090, domains 2
> C: freemem 1110, domains 3
> 
> In this case, A>B, because memory is within 10% but has fewer domains.
>  B > C, because B is within 10%, and has fewer domains.  But C > A,
> because C has more than 10% more memory than A (so its domains are not
> counted against it).

The conventional approach to this kind of thing is to invent a score
for sorting etc.  Something like
    score = tuning_parameter * log(freemem) - number_of_domains
which does sort of roughly the same as your 10% rule if you squint.

Or maybe you want to take the log of the number_of_domains too, which
would be equivalent for sorting to
    score = freemem / (number_of_domains + other_tuning_parameter)

>  This may give you strange results from your quicksort.  But it's
> likely to give something *reasonable* anyway.  (And if it turns out to
> cause problems, a bubble sort shouldn't be too expensive and will
> likely to be more robust against this kind of quirkiness.)

The behaviour of sorting functions when giving broken comparison
functions may be entirely arbitrary and is not guaranteed to be
anything near the plausible intended orderings.  If you're using qsort
you're not guaranteed that any particular algorithm will be used, so
you can't make any assumptions about its behaviour in this case.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 11:05:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 11:05: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 1SjTaQ-0004ug-IE; Tue, 26 Jun 2012 11:05:34 +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 1SjTaO-0004uS-EX
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 11:05:32 +0000
Received: from [85.158.139.83:23784] by server-6.bemta-5.messagelabs.com id
	52/69-11348-B7799EF4; Tue, 26 Jun 2012 11:05:31 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340708726!29461553!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14630 invoked from network); 26 Jun 2012 11:05:27 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 11:05:27 -0000
Received: by qadb33 with SMTP id b33so2105641qad.9
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Jun 2012 04:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=JgTTfLjHwG00Q6CaVRPL1u+oNCFUxS4mp9DD8viO4R8=;
	b=E8QRM7WVcC2Oogga9i2RsnXwCbTlov9I6eAkHaLidV3pCkTac4+BeDCw1IlWTbewpD
	Vv7Oy0DbzxljXS5JVJdcgThAN6VZTGCzUzikXn06X+Nzp98Bz7eTIB18lYeYmTNiCbVx
	s3f5IJvb6d1JWj8hoU6wZ9o2KtLOSlmSuMqgMYXNSaAeP9i88f7pbNgP5PXdvWrN//Sl
	Gnde+I9UNdc8q2OBBYcKa1qHbnEF3mZsk4X+zOoJGvHSXKVAkLQOWWO2JewPQtJQdghC
	SsA0SsduOl36QsXQED9BRdpb22ojpdTMO3NO6gaGBnsDbbD3gho+ncy8+/QTPIgrOILW
	ST/g==
MIME-Version: 1.0
Received: by 10.224.185.130 with SMTP id co2mr24845827qab.25.1340708725687;
	Tue, 26 Jun 2012 04:05:25 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Tue, 26 Jun 2012 04:05:25 -0700 (PDT)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
Date: Tue, 26 Jun 2012 12:05:25 +0100
X-Google-Sender-Auth: 3prl5DUgWXzn1tm7cc0URBMNNSk
Message-ID: <CAFLBxZaqvqNZK0CutdVO2KMZ7CfnwS5Mp99WTwyKp_hkToKrYg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "Li, Susie" <susie.li@intel.com>,
	Keir Fraser <keir@xen.org>, "Raj, Ashok" <ashok.raj@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 22, 2012 at 4:21 PM, Luck, Tony <tony.luck@intel.com> wrote:
>>>> I think that we minimally need to retain the MCG_CAP register
>>>> as being of potentially variable content (and hence needing
>>>> saving/restoring on migration). To support this in a forward
>>>> compatible manner, we may have to have a way to tell the
>>>> hypervisor e.g. via command line option which extra MSRs
>>>> have to be treated read-as-zero/writes-ignored upon guest
>>>> accesses.
>>>
>>> Seems unnecessary, reason as above.
>>
>> So going forward you see no possibility of additions to the
>> interface that might warrant allowing more bits to be set in
>> MCG_CAP than you define to be set here? That really looks
>> unrealistic to me.
>
> More bits can be added to MCG_CAP - but this becomes a hard
> problem for migration because most OS guests only look at
> MCG_CAP at boot time (linux certainly does) ... so if you migrate
> and change MCG_CAP to match the new host, the guest will have
> no idea that things changed.

Typically if you have a heterogeneous pool (i.e., different processors
with different CPUID bits) you typically have to calculate the minimum
subset of features available on all processors and only expose those
to the guest.  It wouldn't be too hard to extend that to vMCEs if we
had to.  Alternately, as Jan says, we could just fake things out when
we need to.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 11:05:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 11:05: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 1SjTaQ-0004ug-IE; Tue, 26 Jun 2012 11:05:34 +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 1SjTaO-0004uS-EX
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 11:05:32 +0000
Received: from [85.158.139.83:23784] by server-6.bemta-5.messagelabs.com id
	52/69-11348-B7799EF4; Tue, 26 Jun 2012 11:05:31 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340708726!29461553!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14630 invoked from network); 26 Jun 2012 11:05:27 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 11:05:27 -0000
Received: by qadb33 with SMTP id b33so2105641qad.9
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Jun 2012 04:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=JgTTfLjHwG00Q6CaVRPL1u+oNCFUxS4mp9DD8viO4R8=;
	b=E8QRM7WVcC2Oogga9i2RsnXwCbTlov9I6eAkHaLidV3pCkTac4+BeDCw1IlWTbewpD
	Vv7Oy0DbzxljXS5JVJdcgThAN6VZTGCzUzikXn06X+Nzp98Bz7eTIB18lYeYmTNiCbVx
	s3f5IJvb6d1JWj8hoU6wZ9o2KtLOSlmSuMqgMYXNSaAeP9i88f7pbNgP5PXdvWrN//Sl
	Gnde+I9UNdc8q2OBBYcKa1qHbnEF3mZsk4X+zOoJGvHSXKVAkLQOWWO2JewPQtJQdghC
	SsA0SsduOl36QsXQED9BRdpb22ojpdTMO3NO6gaGBnsDbbD3gho+ncy8+/QTPIgrOILW
	ST/g==
MIME-Version: 1.0
Received: by 10.224.185.130 with SMTP id co2mr24845827qab.25.1340708725687;
	Tue, 26 Jun 2012 04:05:25 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Tue, 26 Jun 2012 04:05:25 -0700 (PDT)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233524C532@SHSMSX101.ccr.corp.intel.com>
	<4FE362C0020000780008B2CD@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923352542BD@SHSMSX101.ccr.corp.intel.com>
	<4FE475BE020000780008B624@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335254989@SHSMSX101.ccr.corp.intel.com>
	<4FE4A636020000780008B756@nat28.tlf.novell.com>
	<3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
Date: Tue, 26 Jun 2012 12:05:25 +0100
X-Google-Sender-Auth: 3prl5DUgWXzn1tm7cc0URBMNNSk
Message-ID: <CAFLBxZaqvqNZK0CutdVO2KMZ7CfnwS5Mp99WTwyKp_hkToKrYg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "Li, Susie" <susie.li@intel.com>,
	Keir Fraser <keir@xen.org>, "Raj, Ashok" <ashok.raj@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 22, 2012 at 4:21 PM, Luck, Tony <tony.luck@intel.com> wrote:
>>>> I think that we minimally need to retain the MCG_CAP register
>>>> as being of potentially variable content (and hence needing
>>>> saving/restoring on migration). To support this in a forward
>>>> compatible manner, we may have to have a way to tell the
>>>> hypervisor e.g. via command line option which extra MSRs
>>>> have to be treated read-as-zero/writes-ignored upon guest
>>>> accesses.
>>>
>>> Seems unnecessary, reason as above.
>>
>> So going forward you see no possibility of additions to the
>> interface that might warrant allowing more bits to be set in
>> MCG_CAP than you define to be set here? That really looks
>> unrealistic to me.
>
> More bits can be added to MCG_CAP - but this becomes a hard
> problem for migration because most OS guests only look at
> MCG_CAP at boot time (linux certainly does) ... so if you migrate
> and change MCG_CAP to match the new host, the guest will have
> no idea that things changed.

Typically if you have a heterogeneous pool (i.e., different processors
with different CPUID bits) you typically have to calculate the minimum
subset of features available on all processors and only expose those
to the guest.  It wouldn't be too hard to extend that to vMCEs if we
had to.  Alternately, as Jan says, we could just fake things out when
we need to.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 11:42:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 11:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjU9h-0006Ak-Am; Tue, 26 Jun 2012 11:42: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 1SjU9g-0006Af-6T
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 11:42:00 +0000
Received: from [85.158.143.99:7715] by server-3.bemta-4.messagelabs.com id
	E3/8F-05808-700A9EF4; Tue, 26 Jun 2012 11:41:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340710918!19550201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19530 invoked from network); 26 Jun 2012 11:41:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 11:41:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13221701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 11:41:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 12:41:58 +0100
Date: Tue, 26 Jun 2012 12:41:33 +0100
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: <1340703351.3832.42.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
	<1340703351.3832.42.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] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> > > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> > >          } else {
> > >              gic_inject_irq_stop();
> > >          }
> > > -        spin_unlock(&gic.lock);
> > > +        spin_unlock_irq(&gic.lock);
> > >  
> > >          spin_lock(&current->arch.vgic.lock);
> >                ^
> > shouldn't you change this into spin_lock_irq too?
> 
> 
> If so then that should be in "arm: use interrupt safe spin locks in
> vgic_vcpu_inject_irq" rather than here?
> 
> I think you've reworked this stuff a bit in one of your follow up series
> -- is it worth me changing this here or do you handle it / make it
> irrelevant?
 
No, I am not, I am only removing everything related to
events_maintenance. I think it is worth fixing it in one of your patches
or in a follow up patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 11:42:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 11:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjU9h-0006Ak-Am; Tue, 26 Jun 2012 11:42: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 1SjU9g-0006Af-6T
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 11:42:00 +0000
Received: from [85.158.143.99:7715] by server-3.bemta-4.messagelabs.com id
	E3/8F-05808-700A9EF4; Tue, 26 Jun 2012 11:41:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340710918!19550201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19530 invoked from network); 26 Jun 2012 11:41:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 11:41:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13221701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 11:41:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 12:41:58 +0100
Date: Tue, 26 Jun 2012 12:41:33 +0100
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: <1340703351.3832.42.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
	<1340703351.3832.42.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] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> > > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> > >          } else {
> > >              gic_inject_irq_stop();
> > >          }
> > > -        spin_unlock(&gic.lock);
> > > +        spin_unlock_irq(&gic.lock);
> > >  
> > >          spin_lock(&current->arch.vgic.lock);
> >                ^
> > shouldn't you change this into spin_lock_irq too?
> 
> 
> If so then that should be in "arm: use interrupt safe spin locks in
> vgic_vcpu_inject_irq" rather than here?
> 
> I think you've reworked this stuff a bit in one of your follow up series
> -- is it worth me changing this here or do you handle it / make it
> irrelevant?
 
No, I am not, I am only removing everything related to
events_maintenance. I think it is worth fixing it in one of your patches
or in a follow up patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 12:26:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 12:26: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 1SjUq0-0006py-MQ; Tue, 26 Jun 2012 12:25: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 1SjUpy-0006pt-VI
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 12:25:43 +0000
Received: from [193.109.254.147:53212] by server-11.bemta-14.messagelabs.com
	id D8/DB-24843-64AA9EF4; Tue, 26 Jun 2012 12:25:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340713540!8454529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30253 invoked from network); 26 Jun 2012 12:25:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 12:25:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13222914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 12:25:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 13:25:39 +0100
Message-ID: <1340713538.3832.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 13:25:38 +0100
In-Reply-To: <alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
	<1340703351.3832.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 12:41 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> > > >          } else {
> > > >              gic_inject_irq_stop();
> > > >          }
> > > > -        spin_unlock(&gic.lock);
> > > > +        spin_unlock_irq(&gic.lock);
> > > >  
> > > >          spin_lock(&current->arch.vgic.lock);
> > >                ^
> > > shouldn't you change this into spin_lock_irq too?
> > 
> > 
> > If so then that should be in "arm: use interrupt safe spin locks in
> > vgic_vcpu_inject_irq" rather than here?
> > 
> > I think you've reworked this stuff a bit in one of your follow up series
> > -- is it worth me changing this here or do you handle it / make it
> > irrelevant?
>  
> No, I am not, I am only removing everything related to
> events_maintenance. I think it is worth fixing it in one of your patches
> or in a follow up patch.

OK, I'll do it in another patch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 12:26:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 12:26: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 1SjUq0-0006py-MQ; Tue, 26 Jun 2012 12:25: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 1SjUpy-0006pt-VI
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 12:25:43 +0000
Received: from [193.109.254.147:53212] by server-11.bemta-14.messagelabs.com
	id D8/DB-24843-64AA9EF4; Tue, 26 Jun 2012 12:25:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340713540!8454529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30253 invoked from network); 26 Jun 2012 12:25:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 12:25:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13222914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 12:25:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 13:25:39 +0100
Message-ID: <1340713538.3832.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 13:25:38 +0100
In-Reply-To: <alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
	<1340703351.3832.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 12:41 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> > > >          } else {
> > > >              gic_inject_irq_stop();
> > > >          }
> > > > -        spin_unlock(&gic.lock);
> > > > +        spin_unlock_irq(&gic.lock);
> > > >  
> > > >          spin_lock(&current->arch.vgic.lock);
> > >                ^
> > > shouldn't you change this into spin_lock_irq too?
> > 
> > 
> > If so then that should be in "arm: use interrupt safe spin locks in
> > vgic_vcpu_inject_irq" rather than here?
> > 
> > I think you've reworked this stuff a bit in one of your follow up series
> > -- is it worth me changing this here or do you handle it / make it
> > irrelevant?
>  
> No, I am not, I am only removing everything related to
> events_maintenance. I think it is worth fixing it in one of your patches
> or in a follow up patch.

OK, I'll do it in another patch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 12:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 12:46: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 1SjV9w-0007A4-IH; Tue, 26 Jun 2012 12:46: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 1SjV9u-00079z-TZ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 12:46:19 +0000
Received: from [85.158.143.35:42627] by server-2.bemta-4.messagelabs.com id
	1F/75-17938-A1FA9EF4; Tue, 26 Jun 2012 12:46:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340714776!12664730!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16077 invoked from network); 26 Jun 2012 12:46:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 12:46:17 -0000
Received: by eekd41 with SMTP id d41so1825600eek.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 05:46:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=R0fJaKA5EnftaRGuJFIpzthO947txX+A96mekOc51k8=;
	b=h7bUaBmaRMikN3j4PQ83a5B0pAl1viLkKqS2yVPBjvdNrHNtojWxFVUaQpuzNiWjk1
	Uqgsz0M0E/ZCqJO+x+5T9wLRaFVpsa1IDMrPTX1THl4elHpX/6f+1Mv1cHwcrnW+N66s
	wHFGfaJzEhJt+D5Up6ighkhLg/sPn2VBXfTFIXO7FzPunYdoUCN39tlsdGeRXsk85ubO
	M5i3Kslf5xd7tTYDWu30SrFHGKcfLfuqzpsy8e+LxRG3sxgm3a/yp0VMnMH8EWagWjmT
	Xr9YFz8MAyNeaW+3HJnSTfuRFUNUIVd5sl53Ucxj7WxF7O6JnVaVKZMpk52QvGRo2XW0
	Xyiw==
Received: by 10.14.94.142 with SMTP id n14mr3180251eef.147.1340714776041;
	Tue, 26 Jun 2012 05:46:16 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id u14sm148718920eem.4.2012.06.26.05.46.14
	(version=SSLv3 cipher=OTHER); Tue, 26 Jun 2012 05:46:15 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 26 Jun 2012 13:46:08 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC0F6DA0.43F2C%keir@xen.org>
Thread-Topic: [PATCH] xen: add assertions in default_vcpu0_location to protect
	against broken masks
Thread-Index: Ac1TmagpwZ0XN39q3E6mjO/HmcVHFA==
In-Reply-To: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 10:47, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> When setting up the cpu sibling/etc masks on ARM I accidentally and
> incorrectly omitted a CPU from it's own sibling mask which caused this
> function to scribble over the heap. Add a couple of asserts to catch this in
> the future.

I'm happy with either or both the assertions you add.

Acked-by: Keir Fraser <keir@xen.org>

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
>  xen/common/domctl.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9f1a9ad..c1acd1d 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t
> *online)
>       */
>      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>      cpu = cpumask_first(&cpu_exclude_map);
> +    ASSERT(cpu < nr_cpus);
>      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>          cpu = cpumask_next(cpu, &cpu_exclude_map);
>      for_each_cpu(i, online)
>      {
> +        ASSERT(i < nr_cpus);
>          if ( cpumask_test_cpu(i, &cpu_exclude_map) )
>              continue;
>          if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 12:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 12:46: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 1SjV9w-0007A4-IH; Tue, 26 Jun 2012 12:46: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 1SjV9u-00079z-TZ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 12:46:19 +0000
Received: from [85.158.143.35:42627] by server-2.bemta-4.messagelabs.com id
	1F/75-17938-A1FA9EF4; Tue, 26 Jun 2012 12:46:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340714776!12664730!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16077 invoked from network); 26 Jun 2012 12:46:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 12:46:17 -0000
Received: by eekd41 with SMTP id d41so1825600eek.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 05:46:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=R0fJaKA5EnftaRGuJFIpzthO947txX+A96mekOc51k8=;
	b=h7bUaBmaRMikN3j4PQ83a5B0pAl1viLkKqS2yVPBjvdNrHNtojWxFVUaQpuzNiWjk1
	Uqgsz0M0E/ZCqJO+x+5T9wLRaFVpsa1IDMrPTX1THl4elHpX/6f+1Mv1cHwcrnW+N66s
	wHFGfaJzEhJt+D5Up6ighkhLg/sPn2VBXfTFIXO7FzPunYdoUCN39tlsdGeRXsk85ubO
	M5i3Kslf5xd7tTYDWu30SrFHGKcfLfuqzpsy8e+LxRG3sxgm3a/yp0VMnMH8EWagWjmT
	Xr9YFz8MAyNeaW+3HJnSTfuRFUNUIVd5sl53Ucxj7WxF7O6JnVaVKZMpk52QvGRo2XW0
	Xyiw==
Received: by 10.14.94.142 with SMTP id n14mr3180251eef.147.1340714776041;
	Tue, 26 Jun 2012 05:46:16 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id u14sm148718920eem.4.2012.06.26.05.46.14
	(version=SSLv3 cipher=OTHER); Tue, 26 Jun 2012 05:46:15 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 26 Jun 2012 13:46:08 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC0F6DA0.43F2C%keir@xen.org>
Thread-Topic: [PATCH] xen: add assertions in default_vcpu0_location to protect
	against broken masks
Thread-Index: Ac1TmagpwZ0XN39q3E6mjO/HmcVHFA==
In-Reply-To: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 10:47, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> When setting up the cpu sibling/etc masks on ARM I accidentally and
> incorrectly omitted a CPU from it's own sibling mask which caused this
> function to scribble over the heap. Add a couple of asserts to catch this in
> the future.

I'm happy with either or both the assertions you add.

Acked-by: Keir Fraser <keir@xen.org>

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
>  xen/common/domctl.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9f1a9ad..c1acd1d 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t
> *online)
>       */
>      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>      cpu = cpumask_first(&cpu_exclude_map);
> +    ASSERT(cpu < nr_cpus);
>      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>          cpu = cpumask_next(cpu, &cpu_exclude_map);
>      for_each_cpu(i, online)
>      {
> +        ASSERT(i < nr_cpus);
>          if ( cpumask_test_cpu(i, &cpu_exclude_map) )
>              continue;
>          if ( (i == cpumask_first(per_cpu(cpu_sibling_mask, i))) &&



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:00:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:00: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 1SjVNK-0007Nj-4R; Tue, 26 Jun 2012 13:00:10 +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 1SjVNI-0007Ne-Jm
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:00:08 +0000
Received: from [193.109.254.147:26069] by server-3.bemta-14.messagelabs.com id
	95/BF-08687-752B9EF4; Tue, 26 Jun 2012 13:00:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340715596!919522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17612 invoked from network); 26 Jun 2012 12:59:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 12:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13223945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 12:59:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 13:59:35 +0100
Date: Tue, 26 Jun 2012 13:59:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 26 Jun 2012, Rolu wrote:
> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 25 Jun 2012, Jan Beulich wrote:
> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> At the same time, adding logging to the guest kernel would
> >> >> be nice, to see what value it actually writes (in a current
> >> >> kernel this would be in __write_msi_msg()).
> >> >>
> >> >
> >> > Turns out that msg->data here is also 0x4300, so it seems the guest
> >> > kernel is producing these values. I caused it to make a stack trace
> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> >> > current data field and if it isn't equal to the macro it uses
> >> > xen_msi_compose_msg to make a new message, but that function just sets
> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> >> > then gets passed to __write_msi_msg and that's that. There are no
> >> > other writes through __write_msi_msg (except for the same thing for
> >> > other devices).
> >> >
> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> >> > decoded as the delivery mode, so it seems the kernel is intentionally
> >> > setting it to 3.
> >>
> >> So that can never have worked properly afaict. Stefano, the
> >> code as it is currently - using literal (3 << 8) - is clearly bogus.
> >> Your original commit at least had a comment saying that the
> >> reserved delivery mode encoding is intentional here, but that
> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
> >> In any case - the cooperation with qemu apparently doesn't
> >> work, as the reserved encoding should never make it through
> >> to the hypervisor. Could you explain what the intention here
> >> was?
> >>
> >> And regardless of anything, can the literal numbers please be
> >> replaced by proper manifest constants - the "8" here already
> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
> >> proper symbolic would permit locating where this is being (or
> >> really, as it doesn't appear to work supposed to be) consumed
> >> in qemu, provided it uses the same definition (i.e. that one
> >> should go into one of the public headers).
> >
> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
> > because notifications are not supposed to be delivered as MSI anymore.
> >
> > This is what should happen:
> >
> > 1) Linux configures the device with a 0 vector number and the pirq number
> > in the address field;
> >
> > 2) QEMU notices a vector number of 0 and reads the pirq number from the
> > address field, passing it to xc_domain_update_msi_irq;
> >
> > 3) Xen assignes the given pirq to the physical MSI;
> >
> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
> >
> > 5) Xen sets the pirq as "IRQ_PT";
> >
> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
> > returns true so Xen calls send_guest_pirq instead.
> >
> >
> > Obviously 6) is not happening. hvm_domain_use_pirq is:
> >
> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
> >
> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
> > above).
> 
> This appears to be true. I added logging to hvm_pci_msi_assert in
> xen/drivers/passthrough/io.c and it indicates that
> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
> before an unsupported delivery mode message.
> 
> I also log pirq->pirq but I found that most of the time I can't find
> this value anywhere else (I'm not sure how to interpret the value,
> though). For example, in my last try:
> 
> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
> 53. The vast majority are for 54.
> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
> but complains it's already mapped.
> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
> 22, 52, 48, 47. Also never 54 or 53.
> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
> * The qemu log mentions pirq 35, 36 and 37
> 
> It seems pirq values don't always mean the same? Is it a coincidence
> that 55 occurs almost everywhere, or is something going wrong with the
> other two values (53 and 54 versus 16 and 17)?
> 
> I have three MSI capable devices passed through to the domU, and I do
> see groups of three distinct pirqs in the data above - just not the
> same ones in every place I look.
> 
> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
> > (__startup_pirq doesn't get called), or Xen is erroring out in
> > map_domain_emuirq_pirq.
> 
> evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.
> 
> map_domain_emuirq_pirq always gets past the checks in the top half
> (i.e. up to the line /* do not store emuirq mappings for pt devices
> */), except for one time with pirq=49,emuirq=23 where it finds they
> are already mapped.
> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
> directly logged that but it's the only assignment there).
> 
> Interestingly, I get an unsupported delivery mode error for pirq 55
> where my logging says pirq->arch.hvm.emuirq is -1, *after*
> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.

Looking back at your QEMU logs, it seems that pt_msi_setup is not
called (or it is not called at the right time), otherwise you should
get:

pt_msi_setup requested pirq = %d

in your logs.
Could you try disabling msitranslate? You can do that adding

pci_msitranslate=0

to your VM config file.
If that works, probably this (untested) QEMU patch could fix your problem:



diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..09b1391 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -59,6 +59,26 @@ static void msix_set_enable(struct pt_dev *dev, int en)
 
 /* MSI virtuailization functions */
 
+int pt_msi_pirq(struct pt_dev *d, int *pirq)
+{
+    int gvec = d->msi->data & 0xFF;
+    if (gvec != 0) {
+        return -1;
+    }
+
+    /* if gvec is 0, the guest is asking for a particular pirq that
+     * is passed as dest_id */
+    *pirq = (dev->msi->addr_hi & 0xffffff00) |
+        ((dev->msi->addr_lo >> MSI_TARGET_CPU_SHIFT) & 0xff);
+    if (!pirq) {
+        /* this probably identifies an misconfiguration of the guest,
+         * try the emulated path */
+        *pirq = -1;
+        return -1;
+    } else {
+        PT_LOG("%s requested pirq = %d\n", __func__, *pirq);
+    }
+}
 /*
  * setup physical msi, but didn't enable it
  */
@@ -74,18 +94,7 @@ int pt_msi_setup(struct pt_dev *dev)
     }
 
     gvec = dev->msi->data & 0xFF;
-    if (!gvec) {
-        /* if gvec is 0, the guest is asking for a particular pirq that
-         * is passed as dest_id */
-        pirq = (dev->msi->addr_hi & 0xffffff00) |
-               ((dev->msi->addr_lo >> MSI_TARGET_CPU_SHIFT) & 0xff);
-        if (!pirq)
-            /* this probably identifies an misconfiguration of the guest,
-             * try the emulated path */
-            pirq = -1;
-        else
-            PT_LOG("pt_msi_setup requested pirq = %d\n", pirq);
-    }
+    pt_msi_pirq(d, &pirq);
 
     if ( xc_physdev_map_pirq_msi(xc_handle, domid, AUTO_ASSIGN, &pirq,
                                  PCI_DEVFN(dev->pci_dev->dev,
@@ -138,6 +147,8 @@ int pt_msi_update(struct pt_dev *d)
     addr = (uint64_t)d->msi->addr_hi << 32 | d->msi->addr_lo;
     gflags = __get_msi_gflags(d->msi->data, addr);
 
+    pt_msi_pirq(d, &d->msi->pirq);
+
     PT_LOG("Update msi with pirq %x gvec %x gflags %x\n",
            d->msi->pirq, gvec, gflags);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:00:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:00: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 1SjVNK-0007Nj-4R; Tue, 26 Jun 2012 13:00:10 +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 1SjVNI-0007Ne-Jm
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:00:08 +0000
Received: from [193.109.254.147:26069] by server-3.bemta-14.messagelabs.com id
	95/BF-08687-752B9EF4; Tue, 26 Jun 2012 13:00:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340715596!919522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17612 invoked from network); 26 Jun 2012 12:59:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 12:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13223945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 12:59:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 13:59:35 +0100
Date: Tue, 26 Jun 2012 13:59:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 26 Jun 2012, Rolu wrote:
> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 25 Jun 2012, Jan Beulich wrote:
> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> At the same time, adding logging to the guest kernel would
> >> >> be nice, to see what value it actually writes (in a current
> >> >> kernel this would be in __write_msi_msg()).
> >> >>
> >> >
> >> > Turns out that msg->data here is also 0x4300, so it seems the guest
> >> > kernel is producing these values. I caused it to make a stack trace
> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> >> > current data field and if it isn't equal to the macro it uses
> >> > xen_msi_compose_msg to make a new message, but that function just sets
> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> >> > then gets passed to __write_msi_msg and that's that. There are no
> >> > other writes through __write_msi_msg (except for the same thing for
> >> > other devices).
> >> >
> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> >> > decoded as the delivery mode, so it seems the kernel is intentionally
> >> > setting it to 3.
> >>
> >> So that can never have worked properly afaict. Stefano, the
> >> code as it is currently - using literal (3 << 8) - is clearly bogus.
> >> Your original commit at least had a comment saying that the
> >> reserved delivery mode encoding is intentional here, but that
> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
> >> In any case - the cooperation with qemu apparently doesn't
> >> work, as the reserved encoding should never make it through
> >> to the hypervisor. Could you explain what the intention here
> >> was?
> >>
> >> And regardless of anything, can the literal numbers please be
> >> replaced by proper manifest constants - the "8" here already
> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
> >> proper symbolic would permit locating where this is being (or
> >> really, as it doesn't appear to work supposed to be) consumed
> >> in qemu, provided it uses the same definition (i.e. that one
> >> should go into one of the public headers).
> >
> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
> > because notifications are not supposed to be delivered as MSI anymore.
> >
> > This is what should happen:
> >
> > 1) Linux configures the device with a 0 vector number and the pirq number
> > in the address field;
> >
> > 2) QEMU notices a vector number of 0 and reads the pirq number from the
> > address field, passing it to xc_domain_update_msi_irq;
> >
> > 3) Xen assignes the given pirq to the physical MSI;
> >
> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
> >
> > 5) Xen sets the pirq as "IRQ_PT";
> >
> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
> > returns true so Xen calls send_guest_pirq instead.
> >
> >
> > Obviously 6) is not happening. hvm_domain_use_pirq is:
> >
> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
> >
> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
> > above).
> 
> This appears to be true. I added logging to hvm_pci_msi_assert in
> xen/drivers/passthrough/io.c and it indicates that
> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
> before an unsupported delivery mode message.
> 
> I also log pirq->pirq but I found that most of the time I can't find
> this value anywhere else (I'm not sure how to interpret the value,
> though). For example, in my last try:
> 
> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
> 53. The vast majority are for 54.
> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
> but complains it's already mapped.
> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
> 22, 52, 48, 47. Also never 54 or 53.
> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
> * The qemu log mentions pirq 35, 36 and 37
> 
> It seems pirq values don't always mean the same? Is it a coincidence
> that 55 occurs almost everywhere, or is something going wrong with the
> other two values (53 and 54 versus 16 and 17)?
> 
> I have three MSI capable devices passed through to the domU, and I do
> see groups of three distinct pirqs in the data above - just not the
> same ones in every place I look.
> 
> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
> > (__startup_pirq doesn't get called), or Xen is erroring out in
> > map_domain_emuirq_pirq.
> 
> evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.
> 
> map_domain_emuirq_pirq always gets past the checks in the top half
> (i.e. up to the line /* do not store emuirq mappings for pt devices
> */), except for one time with pirq=49,emuirq=23 where it finds they
> are already mapped.
> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
> directly logged that but it's the only assignment there).
> 
> Interestingly, I get an unsupported delivery mode error for pirq 55
> where my logging says pirq->arch.hvm.emuirq is -1, *after*
> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.

Looking back at your QEMU logs, it seems that pt_msi_setup is not
called (or it is not called at the right time), otherwise you should
get:

pt_msi_setup requested pirq = %d

in your logs.
Could you try disabling msitranslate? You can do that adding

pci_msitranslate=0

to your VM config file.
If that works, probably this (untested) QEMU patch could fix your problem:



diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..09b1391 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -59,6 +59,26 @@ static void msix_set_enable(struct pt_dev *dev, int en)
 
 /* MSI virtuailization functions */
 
+int pt_msi_pirq(struct pt_dev *d, int *pirq)
+{
+    int gvec = d->msi->data & 0xFF;
+    if (gvec != 0) {
+        return -1;
+    }
+
+    /* if gvec is 0, the guest is asking for a particular pirq that
+     * is passed as dest_id */
+    *pirq = (dev->msi->addr_hi & 0xffffff00) |
+        ((dev->msi->addr_lo >> MSI_TARGET_CPU_SHIFT) & 0xff);
+    if (!pirq) {
+        /* this probably identifies an misconfiguration of the guest,
+         * try the emulated path */
+        *pirq = -1;
+        return -1;
+    } else {
+        PT_LOG("%s requested pirq = %d\n", __func__, *pirq);
+    }
+}
 /*
  * setup physical msi, but didn't enable it
  */
@@ -74,18 +94,7 @@ int pt_msi_setup(struct pt_dev *dev)
     }
 
     gvec = dev->msi->data & 0xFF;
-    if (!gvec) {
-        /* if gvec is 0, the guest is asking for a particular pirq that
-         * is passed as dest_id */
-        pirq = (dev->msi->addr_hi & 0xffffff00) |
-               ((dev->msi->addr_lo >> MSI_TARGET_CPU_SHIFT) & 0xff);
-        if (!pirq)
-            /* this probably identifies an misconfiguration of the guest,
-             * try the emulated path */
-            pirq = -1;
-        else
-            PT_LOG("pt_msi_setup requested pirq = %d\n", pirq);
-    }
+    pt_msi_pirq(d, &pirq);
 
     if ( xc_physdev_map_pirq_msi(xc_handle, domid, AUTO_ASSIGN, &pirq,
                                  PCI_DEVFN(dev->pci_dev->dev,
@@ -138,6 +147,8 @@ int pt_msi_update(struct pt_dev *d)
     addr = (uint64_t)d->msi->addr_hi << 32 | d->msi->addr_lo;
     gflags = __get_msi_gflags(d->msi->data, addr);
 
+    pt_msi_pirq(d, &d->msi->pirq);
+
     PT_LOG("Update msi with pirq %x gvec %x gflags %x\n",
            d->msi->pirq, gvec, gflags);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:17:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjVdk-0007is-VY; Tue, 26 Jun 2012 13:17: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 1SjVdj-0007in-NN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:17:07 +0000
Received: from [85.158.143.35:63480] by server-1.bemta-4.messagelabs.com id
	F8/6F-24392-256B9EF4; Tue, 26 Jun 2012 13:17:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340716625!6733186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17153 invoked from network); 26 Jun 2012 13:17:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:17:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13224556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:17:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:17:05 +0100
Message-ID: <1340716623.3832.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Jun 2012 14:17:03 +0100
In-Reply-To: <4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
	<4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:16 +0100, Jan Beulich wrote:
> >>> On 26.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
> > When setting up the cpu sibling/etc masks on ARM I accidentally and
> > incorrectly omitted a CPU from it's own sibling mask which caused this
> > function to scribble over the heap. Add a couple of asserts to catch this in
> > the future.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > ---
> >  xen/common/domctl.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> > index 9f1a9ad..c1acd1d 100644
> > --- a/xen/common/domctl.c
> > +++ b/xen/common/domctl.c
> > @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
> > *online)
> >       */
> >      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
> >      cpu = cpumask_first(&cpu_exclude_map);
> > +    ASSERT(cpu < nr_cpus);
> >      if ( cpumask_weight(&cpu_exclude_map) > 1 )
> >          cpu = cpumask_next(cpu, &cpu_exclude_map);
> 
> You may want to add another ASSERT() here in case you care
> about the difference between nr_cpus and nr_cpu_ids. Or move
> the ASSERT() here if the difference is insignificant (as I would
> think), as cpumask_next() invokes cpumask_check() (see also
> below).

It is possible to get through this code without calling
cpumask_next(cpu, ..) though, I think, due to the if.

Perhaps
	ASSERT(cpu < nr_cpu_ids);
after the if would be the best option?

> 
> >      for_each_cpu(i, online)
> >      {
> > +        ASSERT(i < nr_cpus);
> 
> This one is almost redundant with the one in cpumask_check()
> called from cpumask_test_cpu() (and the difference between
> using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
> I'd recommend going with just the single earlier addition.

If mask is invalid you can the first iteration with the bad i (from
cpumask_first, which doesn't have any checks), which may scribble off
the end of the cnt array.

I'm not sure why I wasn't hitting an assert from the subsequent
cpumask_next, but I wasn't.

If you are still convinced this ASSERT isn't worth it I'll drop it, I've
found my bug now and it'd be a pretty uncommon one to repeat...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:17:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjVdk-0007is-VY; Tue, 26 Jun 2012 13:17: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 1SjVdj-0007in-NN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:17:07 +0000
Received: from [85.158.143.35:63480] by server-1.bemta-4.messagelabs.com id
	F8/6F-24392-256B9EF4; Tue, 26 Jun 2012 13:17:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340716625!6733186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17153 invoked from network); 26 Jun 2012 13:17:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:17:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13224556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:17:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:17:05 +0100
Message-ID: <1340716623.3832.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Jun 2012 14:17:03 +0100
In-Reply-To: <4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
	<4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:16 +0100, Jan Beulich wrote:
> >>> On 26.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
> > When setting up the cpu sibling/etc masks on ARM I accidentally and
> > incorrectly omitted a CPU from it's own sibling mask which caused this
> > function to scribble over the heap. Add a couple of asserts to catch this in
> > the future.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > ---
> >  xen/common/domctl.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> > index 9f1a9ad..c1acd1d 100644
> > --- a/xen/common/domctl.c
> > +++ b/xen/common/domctl.c
> > @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
> > *online)
> >       */
> >      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
> >      cpu = cpumask_first(&cpu_exclude_map);
> > +    ASSERT(cpu < nr_cpus);
> >      if ( cpumask_weight(&cpu_exclude_map) > 1 )
> >          cpu = cpumask_next(cpu, &cpu_exclude_map);
> 
> You may want to add another ASSERT() here in case you care
> about the difference between nr_cpus and nr_cpu_ids. Or move
> the ASSERT() here if the difference is insignificant (as I would
> think), as cpumask_next() invokes cpumask_check() (see also
> below).

It is possible to get through this code without calling
cpumask_next(cpu, ..) though, I think, due to the if.

Perhaps
	ASSERT(cpu < nr_cpu_ids);
after the if would be the best option?

> 
> >      for_each_cpu(i, online)
> >      {
> > +        ASSERT(i < nr_cpus);
> 
> This one is almost redundant with the one in cpumask_check()
> called from cpumask_test_cpu() (and the difference between
> using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
> I'd recommend going with just the single earlier addition.

If mask is invalid you can the first iteration with the bad i (from
cpumask_first, which doesn't have any checks), which may scribble off
the end of the cnt array.

I'm not sure why I wasn't hitting an assert from the subsequent
cpumask_next, but I wasn't.

If you are still convinced this ASSERT isn't worth it I'll drop it, I've
found my bug now and it'd be a pretty uncommon one to repeat...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:33:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjVsk-0007sv-Ec; Tue, 26 Jun 2012 13:32: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 1SjVsj-0007sq-Fo
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:32:37 +0000
Received: from [85.158.143.99:9464] by server-1.bemta-4.messagelabs.com id
	CB/C0-24392-4F9B9EF4; Tue, 26 Jun 2012 13:32:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340717556!29224603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6958 invoked from network); 26 Jun 2012 13:32:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:32:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:32:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:32:36 +0100
Message-ID: <1340717554.3832.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Tue, 26 Jun 2012 14:32:34 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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 Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> libxl: set stdvga=1 by default when creating a hvm guest
> 
> Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x, Ubuntu, Fedora) support VBE 2.0 or later.
> So, select a standard VGA card with VBE as the default emulated graphics device.

I'm not expert on the graphics side of HVM, but on the face of it
switching the default to something more modern seems like a reasonable
idea, although I'm not sure if we should be doing this for 4.2 at this
point.

I've CCd Tim and Stefano for input from the HVM and QEMU sides.

> It's also a workaround for the following bug.
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812

Do you understand the root cause of that bug?

It's hard to see how detaching a VF relates to the VGA emulation in use.
Can you explain it? Are you sure you aren't just masking the real issue
here?

> Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> diff -r e08cf97e76f0 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Jun 25 13:41:32 2012 +0200
> +++ b/tools/libxl/libxl_create.c	Tue Jun 26 12:41:46 2012 +0800
> @@ -248,7 +248,7 @@
>              if (!b_info->u.hvm.boot) return ERROR_NOMEM;
>          }
>  
> -        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, true);
>          libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
>          if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>              libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:33:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjVsk-0007sv-Ec; Tue, 26 Jun 2012 13:32: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 1SjVsj-0007sq-Fo
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:32:37 +0000
Received: from [85.158.143.99:9464] by server-1.bemta-4.messagelabs.com id
	CB/C0-24392-4F9B9EF4; Tue, 26 Jun 2012 13:32:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340717556!29224603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6958 invoked from network); 26 Jun 2012 13:32:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:32:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:32:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:32:36 +0100
Message-ID: <1340717554.3832.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Tue, 26 Jun 2012 14:32:34 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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 Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> libxl: set stdvga=1 by default when creating a hvm guest
> 
> Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x, Ubuntu, Fedora) support VBE 2.0 or later.
> So, select a standard VGA card with VBE as the default emulated graphics device.

I'm not expert on the graphics side of HVM, but on the face of it
switching the default to something more modern seems like a reasonable
idea, although I'm not sure if we should be doing this for 4.2 at this
point.

I've CCd Tim and Stefano for input from the HVM and QEMU sides.

> It's also a workaround for the following bug.
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812

Do you understand the root cause of that bug?

It's hard to see how detaching a VF relates to the VGA emulation in use.
Can you explain it? Are you sure you aren't just masking the real issue
here?

> Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> diff -r e08cf97e76f0 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Jun 25 13:41:32 2012 +0200
> +++ b/tools/libxl/libxl_create.c	Tue Jun 26 12:41:46 2012 +0800
> @@ -248,7 +248,7 @@
>              if (!b_info->u.hvm.boot) return ERROR_NOMEM;
>          }
>  
> -        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, true);
>          libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
>          if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>              libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:33:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjVtZ-00083A-J0; Tue, 26 Jun 2012 13:33: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 1SjVtY-000832-Jr
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:33:28 +0000
Received: from [85.158.143.99:35013] by server-2.bemta-4.messagelabs.com id
	DB/19-17938-72AB9EF4; Tue, 26 Jun 2012 13:33:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340717607!25836276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9667 invoked from network); 26 Jun 2012 13:33:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:33:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225029"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:33:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:33:27 +0100
Message-ID: <1340717605.3832.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Tue, 26 Jun 2012 14:33:25 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100FEA5C@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA5C@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] document update in xl.cfg.pod.5 for
 'stdvga=1' by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> document update in xl.cfg.pod.5 for 'stdvga=1' by default

Thanks for remembering to update the docs. 

In general we are quite happy to have the docs update in the same patch
as the functional change so no need to separate it out.

> Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> diff -r b98feb4d6359 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Tue Jun 26 12:56:31 2012 +0800
> +++ b/docs/man/xl.cfg.pod.5	Tue Jun 26 13:27:19 2012 +0800
> @@ -718,9 +718,10 @@
>  =item B<stdvga=BOOLEAN>
>  
>  Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> -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.
> +emulated graphics device. The default is to enable this (set to 1).
> +"stdvga=0" means to emulate a Cirrus Logic GD5446 VGA card. If your
> +guest supports VBE 2.0 or later (e.g. Windows XP onwards), you
> +should enable this (or leave it as default).
>  
>  =item B<vnc=BOOLEAN>
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:33:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjVtZ-00083A-J0; Tue, 26 Jun 2012 13:33: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 1SjVtY-000832-Jr
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:33:28 +0000
Received: from [85.158.143.99:35013] by server-2.bemta-4.messagelabs.com id
	DB/19-17938-72AB9EF4; Tue, 26 Jun 2012 13:33:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340717607!25836276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9667 invoked from network); 26 Jun 2012 13:33:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:33:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225029"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:33:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:33:27 +0100
Message-ID: <1340717605.3832.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Tue, 26 Jun 2012 14:33:25 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100FEA5C@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA5C@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] document update in xl.cfg.pod.5 for
 'stdvga=1' by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> document update in xl.cfg.pod.5 for 'stdvga=1' by default

Thanks for remembering to update the docs. 

In general we are quite happy to have the docs update in the same patch
as the functional change so no need to separate it out.

> Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> diff -r b98feb4d6359 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Tue Jun 26 12:56:31 2012 +0800
> +++ b/docs/man/xl.cfg.pod.5	Tue Jun 26 13:27:19 2012 +0800
> @@ -718,9 +718,10 @@
>  =item B<stdvga=BOOLEAN>
>  
>  Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> -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.
> +emulated graphics device. The default is to enable this (set to 1).
> +"stdvga=0" means to emulate a Cirrus Logic GD5446 VGA card. If your
> +guest supports VBE 2.0 or later (e.g. Windows XP onwards), you
> +should enable this (or leave it as default).
>  
>  =item B<vnc=BOOLEAN>
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjW59-0000Fw-Cl; Tue, 26 Jun 2012 13:45: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 1SjW57-0000Fk-78
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:45:25 +0000
Received: from [85.158.143.35:48989] by server-1.bemta-4.messagelabs.com id
	82/9C-24392-4FCB9EF4; Tue, 26 Jun 2012 13:45:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340718321!11059332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19611 invoked from network); 26 Jun 2012 13:45:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225411"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:45:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:45:21 +0100
Message-ID: <1340718320.3832.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:45:20 +0100
In-Reply-To: <1340713538.3832.72.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
	<1340703351.3832.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
	<1340713538.3832.72.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 13:25 +0100, Ian Campbell wrote:
> On Tue, 2012-06-26 at 12:41 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> > > > >          } else {
> > > > >              gic_inject_irq_stop();
> > > > >          }
> > > > > -        spin_unlock(&gic.lock);
> > > > > +        spin_unlock_irq(&gic.lock);
> > > > >  
> > > > >          spin_lock(&current->arch.vgic.lock);
> > > >                ^
> > > > shouldn't you change this into spin_lock_irq too?
> > > 
> > > 
> > > If so then that should be in "arm: use interrupt safe spin locks in
> > > vgic_vcpu_inject_irq" rather than here?
> > > 
> > > I think you've reworked this stuff a bit in one of your follow up series
> > > -- is it worth me changing this here or do you handle it / make it
> > > irrelevant?
> >  
> > No, I am not, I am only removing everything related to
> > events_maintenance. I think it is worth fixing it in one of your patches
> > or in a follow up patch.
> 
> OK, I'll do it in another patch.

Actually, this should have been in "arm: use interrupt safe spin locks
in vgic_vcpu_inject_irq" after all. I also noticed a bug in that patch
(using spin_unlock_irq not irqrestore in one exit path from
vgic_vcpu_inject_irq).

The new combined patch is (this is against my v2 series and replaces
"arm: use interrupt safe spin locks in vgic_vcpu_inject_irq" there):

8<--------------------------------------------------------------

>From 33832172c77d72cd87505f4926f380ee800ff0c7 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 26 Jun 2012 09:00:55 +0000
Subject: [PATCH] arm: make vgic lock safe for use in interrupt context.

In particular vgic_vcpu_inject_irq can be called in both interupt and regular
context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/gic.c  |    4 ++--
 xen/arch/arm/vgic.c |   11 ++++++-----
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..1e60d3b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -604,14 +604,14 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         }
         spin_unlock(&gic.lock);
 
-        spin_lock(&current->arch.vgic.lock);
+        spin_lock_irq(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
         if ( p->desc != NULL ) {
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
         list_del_init(&p->inflight);
-        spin_unlock(&current->arch.vgic.lock);
+        spin_unlock_irq(&current->arch.vgic.lock);
 
         i++;
     }
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..a217151 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -114,8 +114,8 @@ int vcpu_vgic_init(struct vcpu *v)
     return 0;
 }
 
-#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
-#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+#define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
 
 #define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
 #define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,18 +567,18 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
         {
             list_add_tail(&n->inflight, &iter->inflight);
-            spin_unlock(&v->arch.vgic.lock);
+            spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
             return;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Jun 26 13:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjW59-0000Fw-Cl; Tue, 26 Jun 2012 13:45: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 1SjW57-0000Fk-78
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:45:25 +0000
Received: from [85.158.143.35:48989] by server-1.bemta-4.messagelabs.com id
	82/9C-24392-4FCB9EF4; Tue, 26 Jun 2012 13:45:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340718321!11059332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19611 invoked from network); 26 Jun 2012 13:45:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225411"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:45:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:45:21 +0100
Message-ID: <1340718320.3832.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:45:20 +0100
In-Reply-To: <1340713538.3832.72.camel@zakaz.uk.xensource.com>
References: <1338565113.17466.141.camel@zakaz.uk.xensource.com>
	<1338565207-2888-1-git-send-email-ian.campbell@citrix.com>
	<1338565207-2888-31-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1206071146180.2415@kaball.uk.xensource.com>
	<1340703351.3832.42.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261238560.27860@kaball.uk.xensource.com>
	<1340713538.3832.72.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 31/38] arm: gic.lock can be taken in
 interrupt context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 13:25 +0100, Ian Campbell wrote:
> On Tue, 2012-06-26 at 12:41 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > @@ -601,7 +601,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> > > > >          } else {
> > > > >              gic_inject_irq_stop();
> > > > >          }
> > > > > -        spin_unlock(&gic.lock);
> > > > > +        spin_unlock_irq(&gic.lock);
> > > > >  
> > > > >          spin_lock(&current->arch.vgic.lock);
> > > >                ^
> > > > shouldn't you change this into spin_lock_irq too?
> > > 
> > > 
> > > If so then that should be in "arm: use interrupt safe spin locks in
> > > vgic_vcpu_inject_irq" rather than here?
> > > 
> > > I think you've reworked this stuff a bit in one of your follow up series
> > > -- is it worth me changing this here or do you handle it / make it
> > > irrelevant?
> >  
> > No, I am not, I am only removing everything related to
> > events_maintenance. I think it is worth fixing it in one of your patches
> > or in a follow up patch.
> 
> OK, I'll do it in another patch.

Actually, this should have been in "arm: use interrupt safe spin locks
in vgic_vcpu_inject_irq" after all. I also noticed a bug in that patch
(using spin_unlock_irq not irqrestore in one exit path from
vgic_vcpu_inject_irq).

The new combined patch is (this is against my v2 series and replaces
"arm: use interrupt safe spin locks in vgic_vcpu_inject_irq" there):

8<--------------------------------------------------------------

>From 33832172c77d72cd87505f4926f380ee800ff0c7 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 26 Jun 2012 09:00:55 +0000
Subject: [PATCH] arm: make vgic lock safe for use in interrupt context.

In particular vgic_vcpu_inject_irq can be called in both interupt and regular
context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/gic.c  |    4 ++--
 xen/arch/arm/vgic.c |   11 ++++++-----
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..1e60d3b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -604,14 +604,14 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         }
         spin_unlock(&gic.lock);
 
-        spin_lock(&current->arch.vgic.lock);
+        spin_lock_irq(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
         if ( p->desc != NULL ) {
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
         list_del_init(&p->inflight);
-        spin_unlock(&current->arch.vgic.lock);
+        spin_unlock_irq(&current->arch.vgic.lock);
 
         i++;
     }
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..a217151 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -114,8 +114,8 @@ int vcpu_vgic_init(struct vcpu *v)
     return 0;
 }
 
-#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
-#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+#define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
 
 #define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
 #define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,18 +567,18 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
         {
             list_add_tail(&n->inflight, &iter->inflight);
-            spin_unlock(&v->arch.vgic.lock);
+            spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
             return;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Jun 26 13:51:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:51: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 1SjWAA-0000Zb-5u; Tue, 26 Jun 2012 13:50: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 1SjWA9-0000ZV-1h
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 13:50:37 +0000
Received: from [85.158.138.51:22110] by server-9.bemta-3.messagelabs.com id
	23/CA-10419-C2EB9EF4; Tue, 26 Jun 2012 13:50:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340718634!26718572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10950 invoked from network); 26 Jun 2012 13:50:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:50:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:50:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:50:34 +0100
Message-ID: <1340718633.3832.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:50:33 +0100
In-Reply-To: <1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] xcbuild: add console and xenstore
	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

Do you not have libxl and friends up and running sufficiently to use?
This xcbuild was really just intended to tide us over until that stuff
worked, not to be an actual thing...

On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/xcutils/Makefile  |    4 +-
>  tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 59 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> index 92c5a68..c88f286 100644
> --- a/tools/xcutils/Makefile
> +++ b/tools/xcutils/Makefile
> @@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
>  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
>  CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
> -CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
>  
>  .PHONY: all
>  all: build
> @@ -35,7 +35,7 @@ xc_save: xc_save.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
>  
>  xcbuild: xcbuild.o
> -	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
>  
>  readnotes: readnotes.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> index a70c3ca..7b5c0f8 100644
> --- a/tools/xcutils/xcbuild.c
> +++ b/tools/xcutils/xcbuild.c
> @@ -1,6 +1,7 @@
>  #include <unistd.h>
>  #include <stdio.h>
>  #include <stdlib.h>
> +#include <string.h>
>  
>  #include <errno.h>
>  
> @@ -8,6 +9,7 @@
>  //#include <xenguest.h>
>  #include <xentoollog.h>
>  #include <xc_dom.h>
> +#include <xenstore.h>
>  
>  int main(int argc, char **argv)
>  {
> @@ -15,11 +17,19 @@ int main(int argc, char **argv)
>  	xc_interface *xch;
>  	int rv;
>  	const char *image;
> -	uint32_t domid;
> +	uint32_t domid = 1;
>  	xen_domain_handle_t handle;
>  	int maxmem = 128; /* MB */ //atoi(argv[2]);
>  	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
>  	struct xc_dom_image *dom;
> +	unsigned long console_mfn;
> +	unsigned long console_port;
> +	unsigned long store_mfn;
> +	unsigned long store_port;
> +	struct xs_handle *xs;
> +	char *dom_path;
> +	char path[256];
> +	char val[256];
>  
>  	image = (argc < 2) ? "guest.img" : argv[1];
>  	printf("Image: %s\n", image);
> @@ -103,6 +113,52 @@ int main(int argc, char **argv)
>  	if (rv) return rv;
>  	rv = xc_dom_build_image(dom);
>  	if (rv) return rv;
> +
> +	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
> +	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> +	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
> +
> +	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
> +	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> +	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
> +	xs = xs_daemon_open();
> +	if (xs == NULL) {
> +		printf("Could not contact XenStore");
> +		return errno;
> +	}
> +	dom_path = xs_get_domain_path(xs, domid);
> +
> +	snprintf(path, sizeof(path), "%s/console/port", dom_path);
> +	snprintf(val, sizeof(val), "%lu", console_port);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
> +	snprintf(val, sizeof(val), "%lu", console_mfn);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/type", dom_path);
> +	snprintf(val, sizeof(val), "xenconsoled");
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/output", dom_path);
> +	snprintf(val, sizeof(val), "pty");
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
> +	snprintf(val, sizeof(val), "%d", 1048576);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/store/port", dom_path);
> +	snprintf(val, sizeof(val), "%lu", store_port);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
> +	snprintf(val, sizeof(val), "%lu", store_mfn);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +	xs_introduce_domain(xs, domid, store_mfn, store_port);
> +
> +	xs_daemon_close(xs);
> +
>  	rv = xc_dom_boot_image(dom);
>  	if (rv) return rv;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:51:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:51: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 1SjWAA-0000Zb-5u; Tue, 26 Jun 2012 13:50: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 1SjWA9-0000ZV-1h
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 13:50:37 +0000
Received: from [85.158.138.51:22110] by server-9.bemta-3.messagelabs.com id
	23/CA-10419-C2EB9EF4; Tue, 26 Jun 2012 13:50:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340718634!26718572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10950 invoked from network); 26 Jun 2012 13:50:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:50:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:50:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:50:34 +0100
Message-ID: <1340718633.3832.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:50:33 +0100
In-Reply-To: <1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] xcbuild: add console and xenstore
	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

Do you not have libxl and friends up and running sufficiently to use?
This xcbuild was really just intended to tide us over until that stuff
worked, not to be an actual thing...

On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/xcutils/Makefile  |    4 +-
>  tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 59 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> index 92c5a68..c88f286 100644
> --- a/tools/xcutils/Makefile
> +++ b/tools/xcutils/Makefile
> @@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
>  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
>  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
>  CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
> -CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
>  
>  .PHONY: all
>  all: build
> @@ -35,7 +35,7 @@ xc_save: xc_save.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
>  
>  xcbuild: xcbuild.o
> -	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
>  
>  readnotes: readnotes.o
>  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> index a70c3ca..7b5c0f8 100644
> --- a/tools/xcutils/xcbuild.c
> +++ b/tools/xcutils/xcbuild.c
> @@ -1,6 +1,7 @@
>  #include <unistd.h>
>  #include <stdio.h>
>  #include <stdlib.h>
> +#include <string.h>
>  
>  #include <errno.h>
>  
> @@ -8,6 +9,7 @@
>  //#include <xenguest.h>
>  #include <xentoollog.h>
>  #include <xc_dom.h>
> +#include <xenstore.h>
>  
>  int main(int argc, char **argv)
>  {
> @@ -15,11 +17,19 @@ int main(int argc, char **argv)
>  	xc_interface *xch;
>  	int rv;
>  	const char *image;
> -	uint32_t domid;
> +	uint32_t domid = 1;
>  	xen_domain_handle_t handle;
>  	int maxmem = 128; /* MB */ //atoi(argv[2]);
>  	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
>  	struct xc_dom_image *dom;
> +	unsigned long console_mfn;
> +	unsigned long console_port;
> +	unsigned long store_mfn;
> +	unsigned long store_port;
> +	struct xs_handle *xs;
> +	char *dom_path;
> +	char path[256];
> +	char val[256];
>  
>  	image = (argc < 2) ? "guest.img" : argv[1];
>  	printf("Image: %s\n", image);
> @@ -103,6 +113,52 @@ int main(int argc, char **argv)
>  	if (rv) return rv;
>  	rv = xc_dom_build_image(dom);
>  	if (rv) return rv;
> +
> +	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
> +	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> +	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
> +
> +	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
> +	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> +	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
> +	xs = xs_daemon_open();
> +	if (xs == NULL) {
> +		printf("Could not contact XenStore");
> +		return errno;
> +	}
> +	dom_path = xs_get_domain_path(xs, domid);
> +
> +	snprintf(path, sizeof(path), "%s/console/port", dom_path);
> +	snprintf(val, sizeof(val), "%lu", console_port);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
> +	snprintf(val, sizeof(val), "%lu", console_mfn);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/type", dom_path);
> +	snprintf(val, sizeof(val), "xenconsoled");
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/output", dom_path);
> +	snprintf(val, sizeof(val), "pty");
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
> +	snprintf(val, sizeof(val), "%d", 1048576);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/store/port", dom_path);
> +	snprintf(val, sizeof(val), "%lu", store_port);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +
> +	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
> +	snprintf(val, sizeof(val), "%lu", store_mfn);
> +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> +	xs_introduce_domain(xs, domid, store_mfn, store_port);
> +
> +	xs_daemon_close(xs);
> +
>  	rv = xc_dom_boot_image(dom);
>  	if (rv) return rv;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjWCv-0000ho-OQ; Tue, 26 Jun 2012 13:53: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 1SjWCu-0000hi-Cv
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:53:28 +0000
Received: from [85.158.143.99:63693] by server-2.bemta-4.messagelabs.com id
	4B/E2-17938-7DEB9EF4; Tue, 26 Jun 2012 13:53:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340718806!29178335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10512 invoked from network); 26 Jun 2012 13:53:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	26 Jun 2012 13:53:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 14:53:26 +0100
Message-Id: <4FE9DB23020000780008BF61@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 14:54:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
	<4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
	<1340716623.3832.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340716623.3832.96.camel@zakaz.uk.xensource.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] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-06-26 at 11:16 +0100, Jan Beulich wrote:
>> >>> On 26.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > When setting up the cpu sibling/etc masks on ARM I accidentally and
>> > incorrectly omitted a CPU from it's own sibling mask which caused this
>> > function to scribble over the heap. Add a couple of asserts to catch this 
> in
>> > the future.
>> > 
>> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> > Cc: Keir (Xen.org) <keir@xen.org>
>> > Cc: Jan Beulich <JBeulich@suse.com>
>> > ---
>> >  xen/common/domctl.c |    2 ++
>> >  1 files changed, 2 insertions(+), 0 deletions(-)
>> > 
>> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> > index 9f1a9ad..c1acd1d 100644
>> > --- a/xen/common/domctl.c
>> > +++ b/xen/common/domctl.c
>> > @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
>> > *online)
>> >       */
>> >      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>> >      cpu = cpumask_first(&cpu_exclude_map);
>> > +    ASSERT(cpu < nr_cpus);
>> >      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>> >          cpu = cpumask_next(cpu, &cpu_exclude_map);
>> 
>> You may want to add another ASSERT() here in case you care
>> about the difference between nr_cpus and nr_cpu_ids. Or move
>> the ASSERT() here if the difference is insignificant (as I would
>> think), as cpumask_next() invokes cpumask_check() (see also
>> below).
> 
> It is possible to get through this code without calling
> cpumask_next(cpu, ..) though, I think, due to the if.
> 
> Perhaps
> 	ASSERT(cpu < nr_cpu_ids);
> after the if would be the best option?

That's what I meant with "here" in my first response.

>> >      for_each_cpu(i, online)
>> >      {
>> > +        ASSERT(i < nr_cpus);
>> 
>> This one is almost redundant with the one in cpumask_check()
>> called from cpumask_test_cpu() (and the difference between
>> using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
>> I'd recommend going with just the single earlier addition.
> 
> If mask is invalid you can the first iteration with the bad i (from
> cpumask_first, which doesn't have any checks), which may scribble off
> the end of the cnt array.

Immediately after the ASSERT() here there is an invocation of
cpumask_test_cpu(), which itself uses cpumask_check(). That's
what the added ASSERT() is redundant with.

> I'm not sure why I wasn't hitting an assert from the subsequent
> cpumask_next, but I wasn't.
> 
> If you are still convinced this ASSERT isn't worth it I'll drop it, I've
> found my bug now and it'd be a pretty uncommon one to repeat...

Please do.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjWCv-0000ho-OQ; Tue, 26 Jun 2012 13:53: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 1SjWCu-0000hi-Cv
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 13:53:28 +0000
Received: from [85.158.143.99:63693] by server-2.bemta-4.messagelabs.com id
	4B/E2-17938-7DEB9EF4; Tue, 26 Jun 2012 13:53:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340718806!29178335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10512 invoked from network); 26 Jun 2012 13:53:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	26 Jun 2012 13:53:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 14:53:26 +0100
Message-Id: <4FE9DB23020000780008BF61@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 14:54:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
	<4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
	<1340716623.3832.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340716623.3832.96.camel@zakaz.uk.xensource.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] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-06-26 at 11:16 +0100, Jan Beulich wrote:
>> >>> On 26.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > When setting up the cpu sibling/etc masks on ARM I accidentally and
>> > incorrectly omitted a CPU from it's own sibling mask which caused this
>> > function to scribble over the heap. Add a couple of asserts to catch this 
> in
>> > the future.
>> > 
>> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> > Cc: Keir (Xen.org) <keir@xen.org>
>> > Cc: Jan Beulich <JBeulich@suse.com>
>> > ---
>> >  xen/common/domctl.c |    2 ++
>> >  1 files changed, 2 insertions(+), 0 deletions(-)
>> > 
>> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> > index 9f1a9ad..c1acd1d 100644
>> > --- a/xen/common/domctl.c
>> > +++ b/xen/common/domctl.c
>> > @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
>> > *online)
>> >       */
>> >      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
>> >      cpu = cpumask_first(&cpu_exclude_map);
>> > +    ASSERT(cpu < nr_cpus);
>> >      if ( cpumask_weight(&cpu_exclude_map) > 1 )
>> >          cpu = cpumask_next(cpu, &cpu_exclude_map);
>> 
>> You may want to add another ASSERT() here in case you care
>> about the difference between nr_cpus and nr_cpu_ids. Or move
>> the ASSERT() here if the difference is insignificant (as I would
>> think), as cpumask_next() invokes cpumask_check() (see also
>> below).
> 
> It is possible to get through this code without calling
> cpumask_next(cpu, ..) though, I think, due to the if.
> 
> Perhaps
> 	ASSERT(cpu < nr_cpu_ids);
> after the if would be the best option?

That's what I meant with "here" in my first response.

>> >      for_each_cpu(i, online)
>> >      {
>> > +        ASSERT(i < nr_cpus);
>> 
>> This one is almost redundant with the one in cpumask_check()
>> called from cpumask_test_cpu() (and the difference between
>> using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
>> I'd recommend going with just the single earlier addition.
> 
> If mask is invalid you can the first iteration with the bad i (from
> cpumask_first, which doesn't have any checks), which may scribble off
> the end of the cnt array.

Immediately after the ASSERT() here there is an invocation of
cpumask_test_cpu(), which itself uses cpumask_check(). That's
what the added ASSERT() is redundant with.

> I'm not sure why I wasn't hitting an assert from the subsequent
> cpumask_next, but I wasn't.
> 
> If you are still convinced this ASSERT isn't worth it I'll drop it, I've
> found my bug now and it'd be a pretty uncommon one to repeat...

Please do.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:55: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 1SjWEh-0000qv-8e; Tue, 26 Jun 2012 13:55: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 1SjWEf-0000ql-LN
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 13:55:17 +0000
Received: from [85.158.139.83:9279] by server-3.bemta-5.messagelabs.com id
	16/EF-03367-44FB9EF4; Tue, 26 Jun 2012 13:55:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340718915!25633682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25228 invoked from network); 26 Jun 2012 13:55:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:55:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225666"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13: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.213.0;
	Tue, 26 Jun 2012 14:55:15 +0100
Message-ID: <1340718914.3832.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:55:14 +0100
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm/vtimer: do not let the guest
 interact with the physical 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 Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> The guest can read the physical counter but it shouldn't be able to
> cause interrupts of the physical timer to go to the hypervisor.
> Trap physical timer reads/writes in vtimer.c instead.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/time.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 1587fa2..d5b71d7 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -160,8 +160,8 @@ void __cpuinit init_timer_interrupt(void)
>      WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
>      WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
>  #if USE_HYP_TIMER
> -    /* Let the VMs read the physical counter and timer so they can tell time */
> -    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
> +    /* Do not the VMs program the physical timer, only read the physical counter */

"Do not *let* the VMs..." ?

> +    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
>  #else
>      /* Cannot let VMs access physical counter if we are using it */
>      WRITE_CP32(0, CNTHCTL);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13:55: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 1SjWEh-0000qv-8e; Tue, 26 Jun 2012 13:55: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 1SjWEf-0000ql-LN
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 13:55:17 +0000
Received: from [85.158.139.83:9279] by server-3.bemta-5.messagelabs.com id
	16/EF-03367-44FB9EF4; Tue, 26 Jun 2012 13:55:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340718915!25633682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25228 invoked from network); 26 Jun 2012 13:55:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:55:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225666"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13: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.213.0;
	Tue, 26 Jun 2012 14:55:15 +0100
Message-ID: <1340718914.3832.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:55:14 +0100
In-Reply-To: <1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm/vtimer: do not let the guest
 interact with the physical 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 Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> The guest can read the physical counter but it shouldn't be able to
> cause interrupts of the physical timer to go to the hypervisor.
> Trap physical timer reads/writes in vtimer.c instead.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/time.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 1587fa2..d5b71d7 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -160,8 +160,8 @@ void __cpuinit init_timer_interrupt(void)
>      WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
>      WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
>  #if USE_HYP_TIMER
> -    /* Let the VMs read the physical counter and timer so they can tell time */
> -    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
> +    /* Do not the VMs program the physical timer, only read the physical counter */

"Do not *let* the VMs..." ?

> +    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
>  #else
>      /* Cannot let VMs access physical counter if we are using it */
>      WRITE_CP32(0, CNTHCTL);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:56:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjWFA-0000u4-Li; Tue, 26 Jun 2012 13:55: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 1SjWF9-0000tp-FF
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 13:55:47 +0000
Received: from [85.158.143.99:19264] by server-1.bemta-4.messagelabs.com id
	48/C1-24392-26FB9EF4; Tue, 26 Jun 2012 13:55:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340718945!25841407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6825 invoked from network); 26 Jun 2012 13:55:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:55:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:55:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:55:45 +0100
Message-ID: <1340718943.3832.121.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:55:43 +0100
In-Reply-To: <1338981730-14816-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] arm/gic: fix gic 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

On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> gic_save/restore_state should also save and restore lr_mask and
> event_mask too.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/gic.c           |    4 ++++
>  xen/include/asm-arm/domain.h |    2 ++
>  2 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 3f9a061..c73f274 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -67,6 +67,8 @@ 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 = gic.lr_mask;
> +    v->arch.event_mask = gic.event_mask;
>      /* Disable until next VCPU scheduled */
>      GICH[GICH_HCR] = 0;
>      isb();
> @@ -79,6 +81,8 @@ void gic_restore_state(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic.lr_mask = v->arch.lr_mask;
> +    gic.event_mask = v->arch.event_mask;
>      for ( i=0; i<nr_lrs; i++)
>          GICH[GICH_LR + i] = v->arch.gic_lr[i];
>      GICH[GICH_HCR] = GICH_HCR_EN;
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 230ea8c..3576d50 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -121,6 +121,8 @@ struct arch_vcpu
>  
>      uint32_t gic_hcr, gic_vmcr, gic_apr;
>      uint32_t gic_lr[64];
> +    uint64_t event_mask;
> +    uint64_t lr_mask;
>  
>      struct {
>          /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 13:56:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 13: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 1SjWFA-0000u4-Li; Tue, 26 Jun 2012 13:55: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 1SjWF9-0000tp-FF
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 13:55:47 +0000
Received: from [85.158.143.99:19264] by server-1.bemta-4.messagelabs.com id
	48/C1-24392-26FB9EF4; Tue, 26 Jun 2012 13:55:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340718945!25841407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6825 invoked from network); 26 Jun 2012 13:55:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 13:55:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 13:55:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 14:55:45 +0100
Message-ID: <1340718943.3832.121.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 14:55:43 +0100
In-Reply-To: <1338981730-14816-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] arm/gic: fix gic 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

On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> gic_save/restore_state should also save and restore lr_mask and
> event_mask too.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/gic.c           |    4 ++++
>  xen/include/asm-arm/domain.h |    2 ++
>  2 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 3f9a061..c73f274 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -67,6 +67,8 @@ 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 = gic.lr_mask;
> +    v->arch.event_mask = gic.event_mask;
>      /* Disable until next VCPU scheduled */
>      GICH[GICH_HCR] = 0;
>      isb();
> @@ -79,6 +81,8 @@ void gic_restore_state(struct vcpu *v)
>      if ( is_idle_vcpu(v) )
>          return;
>  
> +    gic.lr_mask = v->arch.lr_mask;
> +    gic.event_mask = v->arch.event_mask;
>      for ( i=0; i<nr_lrs; i++)
>          GICH[GICH_LR + i] = v->arch.gic_lr[i];
>      GICH[GICH_HCR] = GICH_HCR_EN;
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 230ea8c..3576d50 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -121,6 +121,8 @@ struct arch_vcpu
>  
>      uint32_t gic_hcr, gic_vmcr, gic_apr;
>      uint32_t gic_lr[64];
> +    uint64_t event_mask;
> +    uint64_t lr_mask;
>  
>      struct {
>          /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:05: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 1SjWOF-0001TT-PS; Tue, 26 Jun 2012 14:05:11 +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 1SjWOE-0001TL-13
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:05:10 +0000
Received: from [193.109.254.147:11325] by server-10.bemta-14.messagelabs.com
	id C1/3F-05433-591C9EF4; Tue, 26 Jun 2012 14:05:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340719508!1810945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28020 invoked from network); 26 Jun 2012 14:05:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:05:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:05:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:05:07 +0100
Message-ID: <1340719506.3832.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:05:06 +0100
In-Reply-To: <1338981730-14816-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/vgic: vgic: support irq
	enable/disable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> If vgic_vcpu_inject_irq is called (for example by a device emulator like
> vtimer.c) but the corresponding irq is not enabled in the virtual gicd
> just queue it in the inflight_irqs list.


> When the irq is enabled make sure to call gic_set_guest_irq.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I had to go reread the comments on inflight_irqs and lr_pending again
(I'm perpetually confused by that stuff) but I think this makes sense.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/vgic.c |   23 ++++++++++++++++++++++-
>  1 files changed, 22 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 5a624bd..4cdfec5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -343,6 +343,22 @@ read_as_zero:
>      return 1;
>  }
>  
> +static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> +{
> +    struct pending_irq *p;
> +    unsigned int irq;
> +    int i = 0;
> +
> +    while ( (i = find_next_bit((const long unsigned int *) &r,
> +                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
> +        irq = i + (32 * n);
> +        p = irq_to_pending(v, irq);
> +        if ( !list_empty(&p->inflight) )
> +            gic_set_guest_irq(v, irq, GICH_LR_PENDING, p->priority);
> +        i++;

what you have here is a for loop ;-)

> +    }
> +}
> +
>  static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
> @@ -351,6 +367,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> +    uint32_t tr;
>  
>      switch ( gicd_reg )
>      {
> @@ -378,8 +395,10 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>          rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
>          if ( rank == NULL) goto write_ignore;
>          vgic_lock_rank(v, rank);
> +        tr = rank->ienable;
>          rank->ienable |= *r;
>          vgic_unlock_rank(v, rank);
> +        vgic_enable_irqs(v, (*r) & (~tr), gicd_reg - GICD_ISENABLER);
>          return 1;
>  
>      case GICD_ICENABLER ... GICD_ICENABLERN:
> @@ -569,7 +588,9 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      else
>          n->desc = NULL;
>  
> -    gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
> +    /* the irq is enabled */
> +    if ( rank->ienable & (1 << (irq % 32)) )
> +        gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
>  
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:05: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 1SjWOF-0001TT-PS; Tue, 26 Jun 2012 14:05:11 +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 1SjWOE-0001TL-13
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:05:10 +0000
Received: from [193.109.254.147:11325] by server-10.bemta-14.messagelabs.com
	id C1/3F-05433-591C9EF4; Tue, 26 Jun 2012 14:05:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340719508!1810945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28020 invoked from network); 26 Jun 2012 14:05:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:05:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13225963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:05:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:05:07 +0100
Message-ID: <1340719506.3832.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:05:06 +0100
In-Reply-To: <1338981730-14816-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/vgic: vgic: support irq
	enable/disable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> If vgic_vcpu_inject_irq is called (for example by a device emulator like
> vtimer.c) but the corresponding irq is not enabled in the virtual gicd
> just queue it in the inflight_irqs list.


> When the irq is enabled make sure to call gic_set_guest_irq.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I had to go reread the comments on inflight_irqs and lr_pending again
(I'm perpetually confused by that stuff) but I think this makes sense.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/vgic.c |   23 ++++++++++++++++++++++-
>  1 files changed, 22 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 5a624bd..4cdfec5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -343,6 +343,22 @@ read_as_zero:
>      return 1;
>  }
>  
> +static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> +{
> +    struct pending_irq *p;
> +    unsigned int irq;
> +    int i = 0;
> +
> +    while ( (i = find_next_bit((const long unsigned int *) &r,
> +                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
> +        irq = i + (32 * n);
> +        p = irq_to_pending(v, irq);
> +        if ( !list_empty(&p->inflight) )
> +            gic_set_guest_irq(v, irq, GICH_LR_PENDING, p->priority);
> +        i++;

what you have here is a for loop ;-)

> +    }
> +}
> +
>  static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
> @@ -351,6 +367,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> +    uint32_t tr;
>  
>      switch ( gicd_reg )
>      {
> @@ -378,8 +395,10 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>          rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
>          if ( rank == NULL) goto write_ignore;
>          vgic_lock_rank(v, rank);
> +        tr = rank->ienable;
>          rank->ienable |= *r;
>          vgic_unlock_rank(v, rank);
> +        vgic_enable_irqs(v, (*r) & (~tr), gicd_reg - GICD_ISENABLER);
>          return 1;
>  
>      case GICD_ICENABLER ... GICD_ICENABLERN:
> @@ -569,7 +588,9 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      else
>          n->desc = NULL;
>  
> -    gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
> +    /* the irq is enabled */
> +    if ( rank->ienable & (1 << (irq % 32)) )
> +        gic_set_guest_irq(v, irq, GICH_LR_PENDING, priority);
>  
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWQg-0001b9-I3; Tue, 26 Jun 2012 14:07:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjWQe-0001b2-Jv
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:07:40 +0000
Received: from [85.158.143.99:5072] by server-3.bemta-4.messagelabs.com id
	5C/93-05808-B22C9EF4; Tue, 26 Jun 2012 14:07:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340719659!19581037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24682 invoked from network); 26 Jun 2012 14:07:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:07:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:07:39 +0100
Message-ID: <1340719657.3832.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 15:07:37 +0100
In-Reply-To: <20120607124606.GT70339@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120607124606.GT70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
 VCPUs not currently running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 13:46 +0100, Tim Deegan wrote:
> At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> > +static void gic_restore_pending_irqs(struct vcpu *v)
> > +{
> > +    int i;
> > +    struct pending_irq *p;
> > +
> > +    /* check for new pending irqs */
> > +    if ( list_empty(&v->arch.vgic.lr_pending) )
> > +        return;
> > +
> > +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )

Is list_for_each_entry on an empty list somehow wrong/buggy/slow?

> > +    {
> > +        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
> > +        if ( i < nr_lrs )
> > +        {
> > +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +            list_del_init(&p->lr_queue);
> > +            set_bit(i, &gic.lr_mask);
> > +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> > +                set_bit(i, &gic.event_mask);
> > +        } else
> > +        {
> > +            return;
> > +        }
> 
> This is a bit ugly - maybe "if ( i >= nr_lrs ) return" above and don't
> indent the block?
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWQg-0001b9-I3; Tue, 26 Jun 2012 14:07:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjWQe-0001b2-Jv
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:07:40 +0000
Received: from [85.158.143.99:5072] by server-3.bemta-4.messagelabs.com id
	5C/93-05808-B22C9EF4; Tue, 26 Jun 2012 14:07:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340719659!19581037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24682 invoked from network); 26 Jun 2012 14:07:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:07:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:07:39 +0100
Message-ID: <1340719657.3832.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 15:07:37 +0100
In-Reply-To: <20120607124606.GT70339@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120607124606.GT70339@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
 VCPUs not currently running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-07 at 13:46 +0100, Tim Deegan wrote:
> At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> > +static void gic_restore_pending_irqs(struct vcpu *v)
> > +{
> > +    int i;
> > +    struct pending_irq *p;
> > +
> > +    /* check for new pending irqs */
> > +    if ( list_empty(&v->arch.vgic.lr_pending) )
> > +        return;
> > +
> > +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )

Is list_for_each_entry on an empty list somehow wrong/buggy/slow?

> > +    {
> > +        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
> > +        if ( i < nr_lrs )
> > +        {
> > +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +            list_del_init(&p->lr_queue);
> > +            set_bit(i, &gic.lr_mask);
> > +            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> > +                set_bit(i, &gic.event_mask);
> > +        } else
> > +        {
> > +            return;
> > +        }
> 
> This is a bit ugly - maybe "if ( i >= nr_lrs ) return" above and don't
> indent the block?
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:08:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWRb-0001fd-WD; Tue, 26 Jun 2012 14:08: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 1SjWRb-0001fR-CY
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:08:39 +0000
Received: from [85.158.143.35:35739] by server-3.bemta-4.messagelabs.com id
	BB/45-05808-662C9EF4; Tue, 26 Jun 2012 14:08:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340719715!6744505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31441 invoked from network); 26 Jun 2012 14:08:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:08:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:08:33 +0100
Message-ID: <1340719712.3832.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:08:32 +0100
In-Reply-To: <1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> Properly initialize all the pending_irqs.lr_queue like we do for
> inflight.
> Check whether we already have the irq in lr_queue before adding it.

Should this be a fatal error? Can a guest make this happen?

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c  |    6 ++++++
>  xen/arch/arm/vgic.c |    6 ++++++
>  2 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 2e41d75..998033a 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>      }
>  
>      n = irq_to_pending(v, virtual_irq);
> +    if ( !list_empty(&n->lr_queue) )
> +    {
> +        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
> +                virtual_irq);
> +        goto out;
> +    }
>      list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
>      {
>          if ( iter->priority > priority )
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 4cdfec5..653e8e5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
>      d->arch.vgic.pending_irqs =
>          xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
>      for (i=0; i<d->arch.vgic.nr_lines; i++)
> +    {
>          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> +        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
> +    }
>      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
>          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
>      return 0;
> @@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
>  
>      memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
>      for (i = 0; i < 32; i++)
> +    {
>          INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
> +    }
>      printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
>             &v->arch.vgic.pending_irqs[0],
>             v->arch.vgic.pending_irqs[0].desc);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:08:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWRb-0001fd-WD; Tue, 26 Jun 2012 14:08: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 1SjWRb-0001fR-CY
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:08:39 +0000
Received: from [85.158.143.35:35739] by server-3.bemta-4.messagelabs.com id
	BB/45-05808-662C9EF4; Tue, 26 Jun 2012 14:08:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340719715!6744505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31441 invoked from network); 26 Jun 2012 14:08:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:08:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:08:33 +0100
Message-ID: <1340719712.3832.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:08:32 +0100
In-Reply-To: <1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> Properly initialize all the pending_irqs.lr_queue like we do for
> inflight.
> Check whether we already have the irq in lr_queue before adding it.

Should this be a fatal error? Can a guest make this happen?

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c  |    6 ++++++
>  xen/arch/arm/vgic.c |    6 ++++++
>  2 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 2e41d75..998033a 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>      }
>  
>      n = irq_to_pending(v, virtual_irq);
> +    if ( !list_empty(&n->lr_queue) )
> +    {
> +        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
> +                virtual_irq);
> +        goto out;
> +    }
>      list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
>      {
>          if ( iter->priority > priority )
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 4cdfec5..653e8e5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
>      d->arch.vgic.pending_irqs =
>          xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
>      for (i=0; i<d->arch.vgic.nr_lines; i++)
> +    {
>          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> +        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
> +    }
>      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
>          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
>      return 0;
> @@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
>  
>      memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
>      for (i = 0; i < 32; i++)
> +    {
>          INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
> +    }
>      printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
>             &v->arch.vgic.pending_irqs[0],
>             v->arch.vgic.pending_irqs[0].desc);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:13:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWWP-0001vM-O2; Tue, 26 Jun 2012 14:13:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1SjWWO-0001vH-1n
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:13:36 +0000
Received: from [85.158.143.99:9387] by server-2.bemta-4.messagelabs.com id
	9B/FD-17938-F83C9EF4; Tue, 26 Jun 2012 14:13:35 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340720013!28631826!1
X-Originating-IP: [209.85.213.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26370 invoked from network); 26 Jun 2012 14:13:34 -0000
Received: from mail-yw0-f41.google.com (HELO mail-yw0-f41.google.com)
	(209.85.213.41)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:13:34 -0000
Received: by yhr47 with SMTP id 47so4538003yhr.28
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 07:13:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=phOQnrYjC9DG7gyjWjWX/jpUCLs0KN0TaFeTjtVY5MY=;
	b=ah7G5ClXHBJcda85wsgxw1TI41E4vYJdEKYA/t45wd5cCtt942bCFM4t5f/CnTfdg1
	kHedUo5kD6Io5oEIvYu+VqGMfvOVaGJDryK0jPyA8oVt6o9h9uGEZixpyBn6mVZH4QA9
	uP7nxO6mxNUD8/tPhi4jVMobsp742WU972y30BDD7yR40J5rAAwKAU3YSsFCGXZQXhcs
	tPMepMq9cs9Z8cyng4Coe5xvP/BBpJpS9SYD0blIvFos006ffEFcLsQ9E7Kj+/9eCdyM
	trkhTYn3otIBnA7zIF1OMc2o9jZ1Hcy7X503mNuLGk0m7O/o0W+wT0kfSZct9v11OWwZ
	Xcxw==
Received: by 10.50.181.232 with SMTP id dz8mr11400755igc.72.1340720013064;
	Tue, 26 Jun 2012 07:13:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.58.83 with HTTP; Tue, 26 Jun 2012 07:13:02 -0700 (PDT)
In-Reply-To: <1340708071.3832.68.camel@zakaz.uk.xensource.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
	<1340708071.3832.68.camel@zakaz.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 15:13:02 +0100
X-Google-Sender-Auth: A8Kbbm9bi6W5aohCBx6dTaf_9bc
Message-ID: <CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 11:54 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
>> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
>> parameter. This patch changes the ownership of the buifioreq event channel to
>> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
>>
>> This fix the initialization of QEMU inside the stubdomain.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>
> This fixes stub domains for me, thanks.
>
> The user of this field (hvm_buffered_io_send) takes iorp->lock so we
> probably want to put the update inside that too, just like for the
> non-buffered case?

Will do.

> It would be nice to extract the alloc&replace functionality into a
> helper.

I tried but it does not work well.
xen_port is an it (non-buffer case) and params[bufioreq...] is an
uint64_t. Both should be argument of the helper, as a pointer to be
pass to xchg().

The prototype of the not working helper:
static int hvm_replace_event_channel(struct vcpu *v, uint64_t
remote_domid, int *port)

So unless there is another way to create this helper, there won't be any.

-- 
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 Jun 26 14:13:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWWP-0001vM-O2; Tue, 26 Jun 2012 14:13:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1SjWWO-0001vH-1n
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:13:36 +0000
Received: from [85.158.143.99:9387] by server-2.bemta-4.messagelabs.com id
	9B/FD-17938-F83C9EF4; Tue, 26 Jun 2012 14:13:35 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340720013!28631826!1
X-Originating-IP: [209.85.213.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26370 invoked from network); 26 Jun 2012 14:13:34 -0000
Received: from mail-yw0-f41.google.com (HELO mail-yw0-f41.google.com)
	(209.85.213.41)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:13:34 -0000
Received: by yhr47 with SMTP id 47so4538003yhr.28
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 07:13:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=phOQnrYjC9DG7gyjWjWX/jpUCLs0KN0TaFeTjtVY5MY=;
	b=ah7G5ClXHBJcda85wsgxw1TI41E4vYJdEKYA/t45wd5cCtt942bCFM4t5f/CnTfdg1
	kHedUo5kD6Io5oEIvYu+VqGMfvOVaGJDryK0jPyA8oVt6o9h9uGEZixpyBn6mVZH4QA9
	uP7nxO6mxNUD8/tPhi4jVMobsp742WU972y30BDD7yR40J5rAAwKAU3YSsFCGXZQXhcs
	tPMepMq9cs9Z8cyng4Coe5xvP/BBpJpS9SYD0blIvFos006ffEFcLsQ9E7Kj+/9eCdyM
	trkhTYn3otIBnA7zIF1OMc2o9jZ1Hcy7X503mNuLGk0m7O/o0W+wT0kfSZct9v11OWwZ
	Xcxw==
Received: by 10.50.181.232 with SMTP id dz8mr11400755igc.72.1340720013064;
	Tue, 26 Jun 2012 07:13:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.58.83 with HTTP; Tue, 26 Jun 2012 07:13:02 -0700 (PDT)
In-Reply-To: <1340708071.3832.68.camel@zakaz.uk.xensource.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
	<1340708071.3832.68.camel@zakaz.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 15:13:02 +0100
X-Google-Sender-Auth: A8Kbbm9bi6W5aohCBx6dTaf_9bc
Message-ID: <CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 11:54 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
>> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
>> parameter. This patch changes the ownership of the buifioreq event channel to
>> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
>>
>> This fix the initialization of QEMU inside the stubdomain.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>
> This fixes stub domains for me, thanks.
>
> The user of this field (hvm_buffered_io_send) takes iorp->lock so we
> probably want to put the update inside that too, just like for the
> non-buffered case?

Will do.

> It would be nice to extract the alloc&replace functionality into a
> helper.

I tried but it does not work well.
xen_port is an it (non-buffer case) and params[bufioreq...] is an
uint64_t. Both should be argument of the helper, as a pointer to be
pass to xchg().

The prototype of the not working helper:
static int hvm_replace_event_channel(struct vcpu *v, uint64_t
remote_domid, int *port)

So unless there is another way to create this helper, there won't be any.

-- 
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 Jun 26 14:17:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWZc-00022R-Ba; Tue, 26 Jun 2012 14:16:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjWZa-00022L-Vt
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:16:55 +0000
Received: from [85.158.143.99:55166] by server-1.bemta-4.messagelabs.com id
	91/AF-24392-654C9EF4; Tue, 26 Jun 2012 14:16:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340720213!23935253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3584 invoked from network); 26 Jun 2012 14:16:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:16:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:16:50 +0100
Message-ID: <1340720209.3832.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Jun 2012 15:16:49 +0100
In-Reply-To: <4FE9DB23020000780008BF61@nat28.tlf.novell.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
	<4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
	<1340716623.3832.96.camel@zakaz.uk.xensource.com>
	<4FE9DB23020000780008BF61@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 14:54 +0100, Jan Beulich wrote:
> >>> On 26.06.12 at 15:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-26 at 11:16 +0100, Jan Beulich wrote:
> >> >>> On 26.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > When setting up the cpu sibling/etc masks on ARM I accidentally and
> >> > incorrectly omitted a CPU from it's own sibling mask which caused this
> >> > function to scribble over the heap. Add a couple of asserts to catch this 
> > in
> >> > the future.
> >> > 
> >> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> > Cc: Keir (Xen.org) <keir@xen.org>
> >> > Cc: Jan Beulich <JBeulich@suse.com>
> >> > ---
> >> >  xen/common/domctl.c |    2 ++
> >> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >> > 
> >> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> >> > index 9f1a9ad..c1acd1d 100644
> >> > --- a/xen/common/domctl.c
> >> > +++ b/xen/common/domctl.c
> >> > @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
> >> > *online)
> >> >       */
> >> >      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
> >> >      cpu = cpumask_first(&cpu_exclude_map);
> >> > +    ASSERT(cpu < nr_cpus);
> >> >      if ( cpumask_weight(&cpu_exclude_map) > 1 )
> >> >          cpu = cpumask_next(cpu, &cpu_exclude_map);
> >> 
> >> You may want to add another ASSERT() here in case you care
> >> about the difference between nr_cpus and nr_cpu_ids. Or move
> >> the ASSERT() here if the difference is insignificant (as I would
> >> think), as cpumask_next() invokes cpumask_check() (see also
> >> below).
> > 
> > It is possible to get through this code without calling
> > cpumask_next(cpu, ..) though, I think, due to the if.
> > 
> > Perhaps
> > 	ASSERT(cpu < nr_cpu_ids);
> > after the if would be the best option?
> 
> That's what I meant with "here" in my first response.

Sorry, I thought you meant inside the if, for some reason...

> 
> >> >      for_each_cpu(i, online)
> >> >      {
> >> > +        ASSERT(i < nr_cpus);
> >> 
> >> This one is almost redundant with the one in cpumask_check()
> >> called from cpumask_test_cpu() (and the difference between
> >> using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
> >> I'd recommend going with just the single earlier addition.
> > 
> > If mask is invalid you can the first iteration with the bad i (from
> > cpumask_first, which doesn't have any checks), which may scribble off
> > the end of the cnt array.
> 
> Immediately after the ASSERT() here there is an invocation of
> cpumask_test_cpu(), which itself uses cpumask_check(). That's
> what the added ASSERT() is redundant with.

Ah, I was confused because it was on a different mask -- but of course
for the purposes of that assert it doesn't matter which mask it is.

> > I'm not sure why I wasn't hitting an assert from the subsequent
> > cpumask_next, but I wasn't.
> > 
> > If you are still convinced this ASSERT isn't worth it I'll drop it, I've
> > found my bug now and it'd be a pretty uncommon one to repeat...
> 
> Please do.

Patch below.

My memory wrt heap corruption was faulty -- actually it was just that
this function was returning a cpu > nr_cpu_ids which caused a later
function to access an invalid per-cpu segment -- which just looked like
heap corruption when I first started investigating it. I've updated the
comment to reflect that.

8<---------------------------------------------------------------

>From 02d59965931509b9eb8e1e69504a0b09cc9765c5 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 26 Jun 2012 09:44:34 +0000
Subject: [PATCH] xen: add assertion in default_vcpu0_location to protect
 against broken masks

When setting up the cpu sibling/etc masks on ARM I accidentally and
incorrectly omitted a CPU from it's own sibling mask which caused this
function to return an invalid cpu number which caused errors later when we
tried to access per_cpu data for that invalid cpu.

Add an assert to catch this in the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/common/domctl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..7ca6b08 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -192,6 +192,7 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
     cpu = cpumask_first(&cpu_exclude_map);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
+    ASSERT(cpu < nr_cpu_ids);
     for_each_cpu(i, online)
     {
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
-- 
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 Jun 26 14:17:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWZc-00022R-Ba; Tue, 26 Jun 2012 14:16:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjWZa-00022L-Vt
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:16:55 +0000
Received: from [85.158.143.99:55166] by server-1.bemta-4.messagelabs.com id
	91/AF-24392-654C9EF4; Tue, 26 Jun 2012 14:16:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340720213!23935253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3584 invoked from network); 26 Jun 2012 14:16:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:16:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:16:50 +0100
Message-ID: <1340720209.3832.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Jun 2012 15:16:49 +0100
In-Reply-To: <4FE9DB23020000780008BF61@nat28.tlf.novell.com>
References: <1340704026-20406-1-git-send-email-ian.campbell@citrix.com>
	<4FE9A80D020000780008BE0B@nat28.tlf.novell.com>
	<1340716623.3832.96.camel@zakaz.uk.xensource.com>
	<4FE9DB23020000780008BF61@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: add assertions in
 default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 14:54 +0100, Jan Beulich wrote:
> >>> On 26.06.12 at 15:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-26 at 11:16 +0100, Jan Beulich wrote:
> >> >>> On 26.06.12 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > When setting up the cpu sibling/etc masks on ARM I accidentally and
> >> > incorrectly omitted a CPU from it's own sibling mask which caused this
> >> > function to scribble over the heap. Add a couple of asserts to catch this 
> > in
> >> > the future.
> >> > 
> >> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> > Cc: Keir (Xen.org) <keir@xen.org>
> >> > Cc: Jan Beulich <JBeulich@suse.com>
> >> > ---
> >> >  xen/common/domctl.c |    2 ++
> >> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >> > 
> >> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> >> > index 9f1a9ad..c1acd1d 100644
> >> > --- a/xen/common/domctl.c
> >> > +++ b/xen/common/domctl.c
> >> > @@ -190,10 +190,12 @@ static unsigned int default_vcpu0_location(cpumask_t 
> >> > *online)
> >> >       */
> >> >      cpumask_copy(&cpu_exclude_map, per_cpu(cpu_sibling_mask, 0));
> >> >      cpu = cpumask_first(&cpu_exclude_map);
> >> > +    ASSERT(cpu < nr_cpus);
> >> >      if ( cpumask_weight(&cpu_exclude_map) > 1 )
> >> >          cpu = cpumask_next(cpu, &cpu_exclude_map);
> >> 
> >> You may want to add another ASSERT() here in case you care
> >> about the difference between nr_cpus and nr_cpu_ids. Or move
> >> the ASSERT() here if the difference is insignificant (as I would
> >> think), as cpumask_next() invokes cpumask_check() (see also
> >> below).
> > 
> > It is possible to get through this code without calling
> > cpumask_next(cpu, ..) though, I think, due to the if.
> > 
> > Perhaps
> > 	ASSERT(cpu < nr_cpu_ids);
> > after the if would be the best option?
> 
> That's what I meant with "here" in my first response.

Sorry, I thought you meant inside the if, for some reason...

> 
> >> >      for_each_cpu(i, online)
> >> >      {
> >> > +        ASSERT(i < nr_cpus);
> >> 
> >> This one is almost redundant with the one in cpumask_check()
> >> called from cpumask_test_cpu() (and the difference between
> >> using nr_cpu_ids and nr_cpus doesn't seem relevant here), so
> >> I'd recommend going with just the single earlier addition.
> > 
> > If mask is invalid you can the first iteration with the bad i (from
> > cpumask_first, which doesn't have any checks), which may scribble off
> > the end of the cnt array.
> 
> Immediately after the ASSERT() here there is an invocation of
> cpumask_test_cpu(), which itself uses cpumask_check(). That's
> what the added ASSERT() is redundant with.

Ah, I was confused because it was on a different mask -- but of course
for the purposes of that assert it doesn't matter which mask it is.

> > I'm not sure why I wasn't hitting an assert from the subsequent
> > cpumask_next, but I wasn't.
> > 
> > If you are still convinced this ASSERT isn't worth it I'll drop it, I've
> > found my bug now and it'd be a pretty uncommon one to repeat...
> 
> Please do.

Patch below.

My memory wrt heap corruption was faulty -- actually it was just that
this function was returning a cpu > nr_cpu_ids which caused a later
function to access an invalid per-cpu segment -- which just looked like
heap corruption when I first started investigating it. I've updated the
comment to reflect that.

8<---------------------------------------------------------------

>From 02d59965931509b9eb8e1e69504a0b09cc9765c5 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 26 Jun 2012 09:44:34 +0000
Subject: [PATCH] xen: add assertion in default_vcpu0_location to protect
 against broken masks

When setting up the cpu sibling/etc masks on ARM I accidentally and
incorrectly omitted a CPU from it's own sibling mask which caused this
function to return an invalid cpu number which caused errors later when we
tried to access per_cpu data for that invalid cpu.

Add an assert to catch this in the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Jan Beulich <JBeulich@suse.com>
---
 xen/common/domctl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..7ca6b08 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -192,6 +192,7 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
     cpu = cpumask_first(&cpu_exclude_map);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
+    ASSERT(cpu < nr_cpu_ids);
     for_each_cpu(i, online)
     {
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
-- 
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 Jun 26 14:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:21: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 1SjWeG-0002Cr-2B; Tue, 26 Jun 2012 14: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 1SjWeE-0002Cl-IT
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:21:42 +0000
Received: from [85.158.139.83:5249] by server-9.bemta-5.messagelabs.com id
	8A/09-01069-575C9EF4; Tue, 26 Jun 2012 14:21:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340720500!29600997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13102 invoked from network); 26 Jun 2012 14:21:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:21:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:21:40 +0100
Message-ID: <1340720499.3832.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 15:21:39 +0100
In-Reply-To: <CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
	<1340708071.3832.68.camel@zakaz.uk.xensource.com>
	<CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 15:13 +0100, Anthony PERARD wrote:
> On Tue, Jun 26, 2012 at 11:54 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
> >> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
> >> parameter. This patch changes the ownership of the buifioreq event channel to
> >> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
> >>
> >> This fix the initialization of QEMU inside the stubdomain.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >
> > This fixes stub domains for me, thanks.
> >
> > The user of this field (hvm_buffered_io_send) takes iorp->lock so we
> > probably want to put the update inside that too, just like for the
> > non-buffered case?
> 
> Will do.
> 
> > It would be nice to extract the alloc&replace functionality into a
> > helper.
> 
> I tried but it does not work well.
> xen_port is an it (non-buffer case) and params[bufioreq...] is an
> uint64_t. Both should be argument of the helper, as a pointer to be
> pass to xchg().
> 
> The prototype of the not working helper:
> static int hvm_replace_event_channel(struct vcpu *v, uint64_t
> remote_domid, int *port)
> 
> So unless there is another way to create this helper, there won't be any.

Although params[...] are generally uint64_t the params[BUFIOREQ_EVTCHN]
is really an int (or more properly an evtchn_port_t, although this is
only used in include/public). Perhaps a cast is appropriate in this
case?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:21: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 1SjWeG-0002Cr-2B; Tue, 26 Jun 2012 14: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 1SjWeE-0002Cl-IT
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:21:42 +0000
Received: from [85.158.139.83:5249] by server-9.bemta-5.messagelabs.com id
	8A/09-01069-575C9EF4; Tue, 26 Jun 2012 14:21:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340720500!29600997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13102 invoked from network); 26 Jun 2012 14:21:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:21:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:21:40 +0100
Message-ID: <1340720499.3832.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 15:21:39 +0100
In-Reply-To: <CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
	<1340708071.3832.68.camel@zakaz.uk.xensource.com>
	<CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 15:13 +0100, Anthony PERARD wrote:
> On Tue, Jun 26, 2012 at 11:54 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
> >> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
> >> parameter. This patch changes the ownership of the buifioreq event channel to
> >> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
> >>
> >> This fix the initialization of QEMU inside the stubdomain.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >
> > This fixes stub domains for me, thanks.
> >
> > The user of this field (hvm_buffered_io_send) takes iorp->lock so we
> > probably want to put the update inside that too, just like for the
> > non-buffered case?
> 
> Will do.
> 
> > It would be nice to extract the alloc&replace functionality into a
> > helper.
> 
> I tried but it does not work well.
> xen_port is an it (non-buffer case) and params[bufioreq...] is an
> uint64_t. Both should be argument of the helper, as a pointer to be
> pass to xchg().
> 
> The prototype of the not working helper:
> static int hvm_replace_event_channel(struct vcpu *v, uint64_t
> remote_domid, int *port)
> 
> So unless there is another way to create this helper, there won't be any.

Although params[...] are generally uint64_t the params[BUFIOREQ_EVTCHN]
is really an int (or more properly an evtchn_port_t, although this is
only used in include/public). Perhaps a cast is appropriate in this
case?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjWjw-0002MB-S0; Tue, 26 Jun 2012 14:27: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 1SjWjv-0002M6-S8
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:27:36 +0000
Received: from [85.158.139.83:64443] by server-8.bemta-5.messagelabs.com id
	7C/62-10278-7D6C9EF4; Tue, 26 Jun 2012 14:27:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340720844!29505815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16004 invoked from network); 26 Jun 2012 14:27:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:27:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:27:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:27:24 +0100
Message-ID: <1340720842.3832.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:27:22 +0100
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen/arm: implement do_hvm_op 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

We need to device how hybrid our hybrid arm guests are going to be.

The particular hvm params you are using here (evtchn port etc) typically
live in start_info for a PV guest. In principal we could define a start
info for ARM too but that leaves the question of how the guest can find
it (which loops up back to hvm_params...).

Looking at the other stuff in start_info, it has stuff like modules (aka
ramdisks) and command lines which ARM guest get via the normal ARM boot
protocol stuff (i.e. the domain builder does it) and a bunch of stuff
which seems to only make sense for proper-PV guests.

So maybe HVM PARAM is the right answer?

sinfo does have flags which contains stuff like SIF_INITIAL_DOMAIN.
Might we want that?

On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/Makefile        |    1 +
>  xen/arch/arm/hvm.c           |   60 ++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/traps.c         |    1 +
>  xen/include/asm-arm/domain.h |    7 +++++
>  4 files changed, 69 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/hvm.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 5a87ba6..634b620 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -26,6 +26,7 @@ obj-y += traps.o
>  obj-y += vgic.o
>  obj-y += vtimer.o
>  obj-y += vpl011.o
> +obj-y += hvm.o
>  
>  #obj-bin-y += ....o
>  
> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
> new file mode 100644
> index 0000000..c11378d
> --- /dev/null
> +++ b/xen/arch/arm/hvm.c
> @@ -0,0 +1,60 @@
> +#include <xen/config.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/errno.h>
> +#include <xen/guest_access.h>
> +#include <xen/sched.h>
> +
> +#include <public/xen.h>
> +#include <public/hvm/params.h>
> +#include <public/hvm/hvm_op.h>
> +
> +#include <asm/hypercall.h>
> +
> +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
> +
> +{
> +    long rc = 0;
> +
> +    switch ( op )
> +    {
> +    case HVMOP_set_param:
> +    case HVMOP_get_param:
> +    {
> +        struct xen_hvm_param a;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&a, arg, 1) )
> +            return -EFAULT;
> +
> +        if ( a.index >= HVM_NR_PARAMS )
> +            return -EINVAL;
> +
> +        rc = rcu_lock_target_domain_by_id(a.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( op == HVMOP_set_param )
> +        {
> +            d->arch.hvm_domain.params[a.index] = a.value;
> +        }
> +        else
> +        {
> +            a.value = d->arch.hvm_domain.params[a.index];
> +            rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
> +        }
> +
> +        rcu_unlock_domain(d);
> +        break;
> +    }
> +
> +    default:
> +    {
> +        printk("%s: Bad HVM op %ld.\n", __func__, op);
> +        rc = -ENOSYS;
> +        break;
> +    }
> +    }
> +
> +    return rc;
> +}
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index ec74298..3900545 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -430,6 +430,7 @@ static arm_hypercall_t *arm_hypercall_table[] = {
>      HYPERCALL(memory_op),
>      HYPERCALL(physdev_op),
>      HYPERCALL(sysctl),
> +    HYPERCALL(hvm_op),
>  };
>  
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 2b14545..114a8f6 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -5,6 +5,7 @@
>  #include <xen/cache.h>
>  #include <asm/page.h>
>  #include <asm/p2m.h>
> +#include <public/hvm/params.h>
>  
>  /* Represents state corresponding to a block of 32 interrupts */
>  struct vgic_irq_rank {
> @@ -28,9 +29,15 @@ struct pending_irq
>      struct list_head lr_queue;
>  };
>  
> +struct hvm_domain
> +{
> +    uint64_t              params[HVM_NR_PARAMS];
> +}  __cacheline_aligned;
> +
>  struct arch_domain
>  {
>      struct p2m_domain p2m;
> +    struct hvm_domain hvm_domain;
>  
>      struct {
>          /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjWjw-0002MB-S0; Tue, 26 Jun 2012 14:27: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 1SjWjv-0002M6-S8
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:27:36 +0000
Received: from [85.158.139.83:64443] by server-8.bemta-5.messagelabs.com id
	7C/62-10278-7D6C9EF4; Tue, 26 Jun 2012 14:27:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340720844!29505815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16004 invoked from network); 26 Jun 2012 14:27:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:27:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:27:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:27:24 +0100
Message-ID: <1340720842.3832.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:27:22 +0100
In-Reply-To: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen/arm: implement do_hvm_op 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

We need to device how hybrid our hybrid arm guests are going to be.

The particular hvm params you are using here (evtchn port etc) typically
live in start_info for a PV guest. In principal we could define a start
info for ARM too but that leaves the question of how the guest can find
it (which loops up back to hvm_params...).

Looking at the other stuff in start_info, it has stuff like modules (aka
ramdisks) and command lines which ARM guest get via the normal ARM boot
protocol stuff (i.e. the domain builder does it) and a bunch of stuff
which seems to only make sense for proper-PV guests.

So maybe HVM PARAM is the right answer?

sinfo does have flags which contains stuff like SIF_INITIAL_DOMAIN.
Might we want that?

On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/Makefile        |    1 +
>  xen/arch/arm/hvm.c           |   60 ++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/traps.c         |    1 +
>  xen/include/asm-arm/domain.h |    7 +++++
>  4 files changed, 69 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/hvm.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 5a87ba6..634b620 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -26,6 +26,7 @@ obj-y += traps.o
>  obj-y += vgic.o
>  obj-y += vtimer.o
>  obj-y += vpl011.o
> +obj-y += hvm.o
>  
>  #obj-bin-y += ....o
>  
> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
> new file mode 100644
> index 0000000..c11378d
> --- /dev/null
> +++ b/xen/arch/arm/hvm.c
> @@ -0,0 +1,60 @@
> +#include <xen/config.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/errno.h>
> +#include <xen/guest_access.h>
> +#include <xen/sched.h>
> +
> +#include <public/xen.h>
> +#include <public/hvm/params.h>
> +#include <public/hvm/hvm_op.h>
> +
> +#include <asm/hypercall.h>
> +
> +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
> +
> +{
> +    long rc = 0;
> +
> +    switch ( op )
> +    {
> +    case HVMOP_set_param:
> +    case HVMOP_get_param:
> +    {
> +        struct xen_hvm_param a;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&a, arg, 1) )
> +            return -EFAULT;
> +
> +        if ( a.index >= HVM_NR_PARAMS )
> +            return -EINVAL;
> +
> +        rc = rcu_lock_target_domain_by_id(a.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( op == HVMOP_set_param )
> +        {
> +            d->arch.hvm_domain.params[a.index] = a.value;
> +        }
> +        else
> +        {
> +            a.value = d->arch.hvm_domain.params[a.index];
> +            rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
> +        }
> +
> +        rcu_unlock_domain(d);
> +        break;
> +    }
> +
> +    default:
> +    {
> +        printk("%s: Bad HVM op %ld.\n", __func__, op);
> +        rc = -ENOSYS;
> +        break;
> +    }
> +    }
> +
> +    return rc;
> +}
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index ec74298..3900545 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -430,6 +430,7 @@ static arm_hypercall_t *arm_hypercall_table[] = {
>      HYPERCALL(memory_op),
>      HYPERCALL(physdev_op),
>      HYPERCALL(sysctl),
> +    HYPERCALL(hvm_op),
>  };
>  
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 2b14545..114a8f6 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -5,6 +5,7 @@
>  #include <xen/cache.h>
>  #include <asm/page.h>
>  #include <asm/p2m.h>
> +#include <public/hvm/params.h>
>  
>  /* Represents state corresponding to a block of 32 interrupts */
>  struct vgic_irq_rank {
> @@ -28,9 +29,15 @@ struct pending_irq
>      struct list_head lr_queue;
>  };
>  
> +struct hvm_domain
> +{
> +    uint64_t              params[HVM_NR_PARAMS];
> +}  __cacheline_aligned;
> +
>  struct arch_domain
>  {
>      struct p2m_domain p2m;
> +    struct hvm_domain hvm_domain;
>  
>      struct {
>          /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWlH-0002SM-Gf; Tue, 26 Jun 2012 14:28: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 1SjWlG-0002SC-7N
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:28:58 +0000
Received: from [85.158.139.83:57087] by server-10.bemta-5.messagelabs.com id
	32/0D-02190-927C9EF4; Tue, 26 Jun 2012 14:28:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340720936!29586963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27730 invoked from network); 26 Jun 2012 14:28:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:28:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:28:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:28:56 +0100
Message-ID: <1340720935.3832.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:28:55 +0100
In-Reply-To: <1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/arm: gic and vgic 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, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> - the last argument of find_next_bit is the maximum number of bits, not
> the maximum number of bytes;

I guess 8*sizeof(...) is pretty ugly too so just using the hardcoded
numbers is acceptable in this case.

> 
> - use list_for_each_entry_safe instead of list_for_each_entry in
> gic_restore_pending_irqs because we are actually deleting entries in the
> loop.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c  |    8 ++++----
>  xen/arch/arm/vgic.c |    3 +--
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 87713c1..8190f84 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -480,13 +480,13 @@ out:
>  static void gic_restore_pending_irqs(struct vcpu *v)
>  {
>      int i;
> -    struct pending_irq *p;
> +    struct pending_irq *p, *t;
>  
>      /* check for new pending irqs */
>      if ( list_empty(&v->arch.vgic.lr_pending) )
>          return;
>  
> -    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> +    list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>      {
>          i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
>          if ( i >= nr_lrs ) return;
> @@ -593,7 +593,7 @@ static void events_maintenance(struct vcpu *v)
>      if (!already_pending && gic.event_mask != 0) {
>          spin_lock_irq(&gic.lock);
>          while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> -                        sizeof(uint64_t), i)) < sizeof(uint64_t)) {
> +                        64, i)) < 64) {
>  
>              GICH[GICH_LR + i] = 0;
>              clear_bit(i, &gic.lr_mask);
> @@ -615,7 +615,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      events_maintenance(v);
>  
>      while ((i = find_next_bit((const long unsigned int *) &eisr,
> -                              sizeof(eisr), i)) < sizeof(eisr)) {
> +                              64, i)) < 64) {
>          struct pending_irq *p;
>  
>          spin_lock_irq(&gic.lock);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 653e8e5..b383e01 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -355,8 +355,7 @@ static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>      unsigned int irq;
>      int i = 0;
>  
> -    while ( (i = find_next_bit((const long unsigned int *) &r,
> -                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
> +    while ( (i = find_next_bit((const long unsigned int *) &r, 32, i)) < 32 ) {
>          irq = i + (32 * n);
>          p = irq_to_pending(v, irq);
>          if ( !list_empty(&p->inflight) )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14: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 1SjWlH-0002SM-Gf; Tue, 26 Jun 2012 14:28: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 1SjWlG-0002SC-7N
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:28:58 +0000
Received: from [85.158.139.83:57087] by server-10.bemta-5.messagelabs.com id
	32/0D-02190-927C9EF4; Tue, 26 Jun 2012 14:28:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340720936!29586963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27730 invoked from network); 26 Jun 2012 14:28:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:28:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:28:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:28:56 +0100
Message-ID: <1340720935.3832.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:28:55 +0100
In-Reply-To: <1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/arm: gic and vgic 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, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> - the last argument of find_next_bit is the maximum number of bits, not
> the maximum number of bytes;

I guess 8*sizeof(...) is pretty ugly too so just using the hardcoded
numbers is acceptable in this case.

> 
> - use list_for_each_entry_safe instead of list_for_each_entry in
> gic_restore_pending_irqs because we are actually deleting entries in the
> loop.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c  |    8 ++++----
>  xen/arch/arm/vgic.c |    3 +--
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 87713c1..8190f84 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -480,13 +480,13 @@ out:
>  static void gic_restore_pending_irqs(struct vcpu *v)
>  {
>      int i;
> -    struct pending_irq *p;
> +    struct pending_irq *p, *t;
>  
>      /* check for new pending irqs */
>      if ( list_empty(&v->arch.vgic.lr_pending) )
>          return;
>  
> -    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> +    list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>      {
>          i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
>          if ( i >= nr_lrs ) return;
> @@ -593,7 +593,7 @@ static void events_maintenance(struct vcpu *v)
>      if (!already_pending && gic.event_mask != 0) {
>          spin_lock_irq(&gic.lock);
>          while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> -                        sizeof(uint64_t), i)) < sizeof(uint64_t)) {
> +                        64, i)) < 64) {
>  
>              GICH[GICH_LR + i] = 0;
>              clear_bit(i, &gic.lr_mask);
> @@ -615,7 +615,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      events_maintenance(v);
>  
>      while ((i = find_next_bit((const long unsigned int *) &eisr,
> -                              sizeof(eisr), i)) < sizeof(eisr)) {
> +                              64, i)) < 64) {
>          struct pending_irq *p;
>  
>          spin_lock_irq(&gic.lock);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 653e8e5..b383e01 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -355,8 +355,7 @@ static void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>      unsigned int irq;
>      int i = 0;
>  
> -    while ( (i = find_next_bit((const long unsigned int *) &r,
> -                        sizeof(uint32_t), i)) < sizeof(uint32_t) ) {
> +    while ( (i = find_next_bit((const long unsigned int *) &r, 32, i)) < 32 ) {
>          irq = i + (32 * n);
>          p = irq_to_pending(v, irq);
>          if ( !list_empty(&p->inflight) )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:30:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:30: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 1SjWmP-0002YL-Uu; Tue, 26 Jun 2012 14: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.Campbell@citrix.com>) id 1SjWmO-0002Y8-Fo
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:30:08 +0000
Received: from [85.158.139.83:29563] by server-1.bemta-5.messagelabs.com id
	CD/C7-19721-E67C9EF4; Tue, 26 Jun 2012 14:30:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340721005!28911750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9323 invoked from network); 26 Jun 2012 14:30:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:30:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:29:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:29:41 +0100
Message-ID: <1340720980.3832.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:29:40 +0100
In-Reply-To: <1340381373-22177-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/arm: disable the event optimization
	in the gic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Currently we have an optimization in the GIC driver that allows us not
> to request maintenance interrupts for Xen events. The basic idea is that
> every time we are about to inject a new interrupt or event into a guest,
> we check whether we can remove some old event irqs from one or more LRs.
> We can do this because we know when a guest finishes processing event
> notifications: it sets the evtchn_upcall_pending bit to 0.
> 
> However it is unsafe: the guest resets evtchn_upcall_pending before
> EOI'ing the event irq, therefore a small window of time exists when Xen
> could jump in and remove the event irq from the LR register before the
> guest has EOI'ed it.
> 
> This is not a good practice according to the GIC manual.
> Remove the optimization for now.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/gic.c |   42 ------------------------------------------
>  1 files changed, 0 insertions(+), 42 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 8190f84..c6cee4b 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -37,7 +37,6 @@
>                                       + (GIC_CR_OFFSET & 0xfff)))
>  #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
>                                       + (GIC_HR_OFFSET & 0xfff)))
> -static void events_maintenance(struct vcpu *v);
>  static void gic_restore_pending_irqs(struct vcpu *v);
>  
>  /* Global state */
> @@ -48,7 +47,6 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> -    uint64_t event_mask;
>      uint64_t lr_mask;
>  } gic;
>  
> @@ -62,7 +60,6 @@ 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 = gic.lr_mask;
> -    v->arch.event_mask = gic.event_mask;
>      /* Disable until next VCPU scheduled */
>      GICH[GICH_HCR] = 0;
>      isb();
> @@ -76,7 +73,6 @@ void gic_restore_state(struct vcpu *v)
>          return;
>  
>      gic.lr_mask = v->arch.lr_mask;
> -    gic.event_mask = v->arch.event_mask;
>      for ( i=0; i<nr_lrs; i++)
>          GICH[GICH_LR + i] = v->arch.gic_lr[i];
>      GICH[GICH_HCR] = GICH_HCR_EN;
> @@ -318,7 +314,6 @@ int __init gic_init(void)
>      gic_hyp_init();
>  
>      gic.lr_mask = 0ULL;
> -    gic.event_mask = 0ULL;
>  
>      spin_unlock(&gic.lock);
>  
> @@ -421,9 +416,6 @@ static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>  
>      BUG_ON(lr > nr_lrs);
>  
> -    if (virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK && nr_lrs > 1)
> -        maintenance_int = 0;
> -
>      GICH[GICH_LR + lr] = state |
>          maintenance_int |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> @@ -436,11 +428,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>      int i;
>      struct pending_irq *iter, *n;
>  
> -    if ( v->is_running )
> -    {
> -        events_maintenance(v);
> -    }
> -
>      spin_lock_irq(&gic.lock);
>  
>      if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
> @@ -448,8 +435,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>          i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
>          if (i < nr_lrs) {
>              set_bit(i, &gic.lr_mask);
> -            if ( virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK )
> -                set_bit(i, &gic.event_mask);
>              gic_set_lr(i, virtual_irq, state, priority);
>              goto out;
>          }
> @@ -494,8 +479,6 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>          gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
>          list_del_init(&p->lr_queue);
>          set_bit(i, &gic.lr_mask);
> -        if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> -            set_bit(i, &gic.event_mask);
>      }
>  
>  }
> @@ -584,27 +567,6 @@ void gicv_setup(struct domain *d)
>                          GIC_BASE_ADDRESS + GIC_VR_OFFSET);
>  }
>  
> -static void events_maintenance(struct vcpu *v)
> -{
> -    int i = 0;
> -    int already_pending = test_bit(0,
> -            (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> -
> -    if (!already_pending && gic.event_mask != 0) {
> -        spin_lock_irq(&gic.lock);
> -        while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> -                        64, i)) < 64) {
> -
> -            GICH[GICH_LR + i] = 0;
> -            clear_bit(i, &gic.lr_mask);
> -            clear_bit(i, &gic.event_mask);
> -
> -            i++;
> -        }
> -        spin_unlock_irq(&gic.lock);
> -    }
> -}
> -
>  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
>      int i = 0, virq;
> @@ -612,8 +574,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      struct vcpu *v = current;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    events_maintenance(v);
> -
>      while ((i = find_next_bit((const long unsigned int *) &eisr,
>                                64, i)) < 64) {
>          struct pending_irq *p;
> @@ -629,8 +589,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>              gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
>              list_del_init(&p->lr_queue);
>              set_bit(i, &gic.lr_mask);
> -            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> -                set_bit(i, &gic.event_mask);
>          } else {
>              gic_inject_irq_stop();
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:30:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:30: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 1SjWmP-0002YL-Uu; Tue, 26 Jun 2012 14: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.Campbell@citrix.com>) id 1SjWmO-0002Y8-Fo
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:30:08 +0000
Received: from [85.158.139.83:29563] by server-1.bemta-5.messagelabs.com id
	CD/C7-19721-E67C9EF4; Tue, 26 Jun 2012 14:30:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340721005!28911750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9323 invoked from network); 26 Jun 2012 14:30:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:30:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:29:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:29:41 +0100
Message-ID: <1340720980.3832.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:29:40 +0100
In-Reply-To: <1340381373-22177-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/arm: disable the event optimization
	in the gic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Currently we have an optimization in the GIC driver that allows us not
> to request maintenance interrupts for Xen events. The basic idea is that
> every time we are about to inject a new interrupt or event into a guest,
> we check whether we can remove some old event irqs from one or more LRs.
> We can do this because we know when a guest finishes processing event
> notifications: it sets the evtchn_upcall_pending bit to 0.
> 
> However it is unsafe: the guest resets evtchn_upcall_pending before
> EOI'ing the event irq, therefore a small window of time exists when Xen
> could jump in and remove the event irq from the LR register before the
> guest has EOI'ed it.
> 
> This is not a good practice according to the GIC manual.
> Remove the optimization for now.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/gic.c |   42 ------------------------------------------
>  1 files changed, 0 insertions(+), 42 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 8190f84..c6cee4b 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -37,7 +37,6 @@
>                                       + (GIC_CR_OFFSET & 0xfff)))
>  #define GICH ((volatile uint32_t *) (FIXMAP_ADDR(FIXMAP_GICH)  \
>                                       + (GIC_HR_OFFSET & 0xfff)))
> -static void events_maintenance(struct vcpu *v);
>  static void gic_restore_pending_irqs(struct vcpu *v);
>  
>  /* Global state */
> @@ -48,7 +47,6 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> -    uint64_t event_mask;
>      uint64_t lr_mask;
>  } gic;
>  
> @@ -62,7 +60,6 @@ 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 = gic.lr_mask;
> -    v->arch.event_mask = gic.event_mask;
>      /* Disable until next VCPU scheduled */
>      GICH[GICH_HCR] = 0;
>      isb();
> @@ -76,7 +73,6 @@ void gic_restore_state(struct vcpu *v)
>          return;
>  
>      gic.lr_mask = v->arch.lr_mask;
> -    gic.event_mask = v->arch.event_mask;
>      for ( i=0; i<nr_lrs; i++)
>          GICH[GICH_LR + i] = v->arch.gic_lr[i];
>      GICH[GICH_HCR] = GICH_HCR_EN;
> @@ -318,7 +314,6 @@ int __init gic_init(void)
>      gic_hyp_init();
>  
>      gic.lr_mask = 0ULL;
> -    gic.event_mask = 0ULL;
>  
>      spin_unlock(&gic.lock);
>  
> @@ -421,9 +416,6 @@ static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>  
>      BUG_ON(lr > nr_lrs);
>  
> -    if (virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK && nr_lrs > 1)
> -        maintenance_int = 0;
> -
>      GICH[GICH_LR + lr] = state |
>          maintenance_int |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> @@ -436,11 +428,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>      int i;
>      struct pending_irq *iter, *n;
>  
> -    if ( v->is_running )
> -    {
> -        events_maintenance(v);
> -    }
> -
>      spin_lock_irq(&gic.lock);
>  
>      if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
> @@ -448,8 +435,6 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>          i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
>          if (i < nr_lrs) {
>              set_bit(i, &gic.lr_mask);
> -            if ( virtual_irq == VGIC_IRQ_EVTCHN_CALLBACK )
> -                set_bit(i, &gic.event_mask);
>              gic_set_lr(i, virtual_irq, state, priority);
>              goto out;
>          }
> @@ -494,8 +479,6 @@ static void gic_restore_pending_irqs(struct vcpu *v)
>          gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
>          list_del_init(&p->lr_queue);
>          set_bit(i, &gic.lr_mask);
> -        if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> -            set_bit(i, &gic.event_mask);
>      }
>  
>  }
> @@ -584,27 +567,6 @@ void gicv_setup(struct domain *d)
>                          GIC_BASE_ADDRESS + GIC_VR_OFFSET);
>  }
>  
> -static void events_maintenance(struct vcpu *v)
> -{
> -    int i = 0;
> -    int already_pending = test_bit(0,
> -            (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> -
> -    if (!already_pending && gic.event_mask != 0) {
> -        spin_lock_irq(&gic.lock);
> -        while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
> -                        64, i)) < 64) {
> -
> -            GICH[GICH_LR + i] = 0;
> -            clear_bit(i, &gic.lr_mask);
> -            clear_bit(i, &gic.event_mask);
> -
> -            i++;
> -        }
> -        spin_unlock_irq(&gic.lock);
> -    }
> -}
> -
>  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
>      int i = 0, virq;
> @@ -612,8 +574,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      struct vcpu *v = current;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    events_maintenance(v);
> -
>      while ((i = find_next_bit((const long unsigned int *) &eisr,
>                                64, i)) < 64) {
>          struct pending_irq *p;
> @@ -629,8 +589,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>              gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
>              list_del_init(&p->lr_queue);
>              set_bit(i, &gic.lr_mask);
> -            if ( p->irq == VGIC_IRQ_EVTCHN_CALLBACK )
> -                set_bit(i, &gic.event_mask);
>          } else {
>              gic_inject_irq_stop();
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:35:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:35: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 1SjWrQ-0002tm-Mi; Tue, 26 Jun 2012 14:35: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 1SjWrP-0002tg-1t
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:35:19 +0000
Received: from [85.158.139.83:19643] by server-6.bemta-5.messagelabs.com id
	DC/0E-11348-6A8C9EF4; Tue, 26 Jun 2012 14:35:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340721316!28912886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32357 invoked from network); 26 Jun 2012 14:35:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:34:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:34:40 +0100
Message-ID: <1340721279.3832.143.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:34:39 +0100
In-Reply-To: <1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] libxc/arm: allocate xenstore and
	console 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, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Allocate two additional pages at the end of the guest physical memory
> for xenstore and console.
> Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> values.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
>  1 files changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index bb86139..df2eefe 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -25,6 +25,10 @@
>  #include "xg_private.h"
>  #include "xc_dom.h"
>  
> +#define NR_MAGIC_PAGES 2
> +#define CONSOLE_PFN_OFFSET 0
> +#define XENSTORE_PFN_OFFSET 1
> +
>  /* ------------------------------------------------------------------------ */
>  /*
>   * arm guests are hybrid and start off with paging disabled, therefore no
> @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
>  static int alloc_magic_pages(struct xc_dom_image *dom)
>  {
>      DOMPRINTF_CALLED(dom->xch);
> -    /* XXX
> -     *   dom->p2m_guest
> -     *   dom->start_info_pfn
> -     *   dom->xenstore_pfn
> -     *   dom->console_pfn
> -     */
>      return 0;
>  }
>  
> @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>  {
>      int rc;
>      xen_pfn_t pfn, allocsz, i;
> +    xen_pfn_t store_pfn, console_pfn;
>  
>      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
>              dom->total_pages, dom->rambase_pfn);
>  
>      dom->shadow_enabled = 1;
>  
> -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
>  
>      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
>              dom->rambase_pfn, dom->total_pages );
>      /* setup initial p2m */
> -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
>          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
>  
>      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>  
>      /* allocate guest memory */
>      for ( i = rc = allocsz = 0;
> -          (i < dom->total_pages) && !rc;
> +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
>            i += allocsz )
>      {
> -        allocsz = dom->total_pages - i;
> +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;

All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.

Do these pages need to be in p2m_host or would it be fine to just insert
them into the guest p2m individually outside the main allocation logic?

Otherwise perhaps simply int total_pages = dom->total_pages + NR... and
use throughout?

>          if ( allocsz > 1024*1024 )
>              allocsz = 1024*1024;
>          fprintf(stderr, "alloc %"PRI_xen_pfn" at offset %"PRI_xen_pfn" which is %"PRI_xen_pfn"\n",
> @@ -168,6 +167,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>      fprintf(stderr, "%s: popl'd p2m_host[%"PRI_xen_pfn"] = %"PRI_xen_pfn"\n",
>              __func__, dom->total_pages-1, dom->p2m_host[dom->total_pages-1]);

I really need to scrub the debug printfs from my patch...

>  
> +    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
> +    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
> +            console_pfn);
> +    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
> +            store_pfn);
> +
> +    fprintf(stderr, "%s: console_pfn=%"PRI_xen_pfn" xenstore_pfn=%"PRI_xen_pfn"\n",
> +            __func__, console_pfn, store_pfn);

... and so do you ;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:35:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:35: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 1SjWrQ-0002tm-Mi; Tue, 26 Jun 2012 14:35: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 1SjWrP-0002tg-1t
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 14:35:19 +0000
Received: from [85.158.139.83:19643] by server-6.bemta-5.messagelabs.com id
	DC/0E-11348-6A8C9EF4; Tue, 26 Jun 2012 14:35:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340721316!28912886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32357 invoked from network); 26 Jun 2012 14:35:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:34:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:34:40 +0100
Message-ID: <1340721279.3832.143.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Jun 2012 15:34:39 +0100
In-Reply-To: <1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] libxc/arm: allocate xenstore and
	console 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, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> Allocate two additional pages at the end of the guest physical memory
> for xenstore and console.
> Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> values.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
>  1 files changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index bb86139..df2eefe 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -25,6 +25,10 @@
>  #include "xg_private.h"
>  #include "xc_dom.h"
>  
> +#define NR_MAGIC_PAGES 2
> +#define CONSOLE_PFN_OFFSET 0
> +#define XENSTORE_PFN_OFFSET 1
> +
>  /* ------------------------------------------------------------------------ */
>  /*
>   * arm guests are hybrid and start off with paging disabled, therefore no
> @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
>  static int alloc_magic_pages(struct xc_dom_image *dom)
>  {
>      DOMPRINTF_CALLED(dom->xch);
> -    /* XXX
> -     *   dom->p2m_guest
> -     *   dom->start_info_pfn
> -     *   dom->xenstore_pfn
> -     *   dom->console_pfn
> -     */
>      return 0;
>  }
>  
> @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>  {
>      int rc;
>      xen_pfn_t pfn, allocsz, i;
> +    xen_pfn_t store_pfn, console_pfn;
>  
>      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
>              dom->total_pages, dom->rambase_pfn);
>  
>      dom->shadow_enabled = 1;
>  
> -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
>  
>      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
>              dom->rambase_pfn, dom->total_pages );
>      /* setup initial p2m */
> -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
>          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
>  
>      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>  
>      /* allocate guest memory */
>      for ( i = rc = allocsz = 0;
> -          (i < dom->total_pages) && !rc;
> +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
>            i += allocsz )
>      {
> -        allocsz = dom->total_pages - i;
> +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;

All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.

Do these pages need to be in p2m_host or would it be fine to just insert
them into the guest p2m individually outside the main allocation logic?

Otherwise perhaps simply int total_pages = dom->total_pages + NR... and
use throughout?

>          if ( allocsz > 1024*1024 )
>              allocsz = 1024*1024;
>          fprintf(stderr, "alloc %"PRI_xen_pfn" at offset %"PRI_xen_pfn" which is %"PRI_xen_pfn"\n",
> @@ -168,6 +167,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>      fprintf(stderr, "%s: popl'd p2m_host[%"PRI_xen_pfn"] = %"PRI_xen_pfn"\n",
>              __func__, dom->total_pages-1, dom->p2m_host[dom->total_pages-1]);

I really need to scrub the debug printfs from my patch...

>  
> +    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
> +    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
> +            console_pfn);
> +    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
> +            store_pfn);
> +
> +    fprintf(stderr, "%s: console_pfn=%"PRI_xen_pfn" xenstore_pfn=%"PRI_xen_pfn"\n",
> +            __func__, console_pfn, store_pfn);

... and so do you ;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjWuI-00031E-SL; Tue, 26 Jun 2012 14:38: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 1SjWuI-000312-0g
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:38:18 +0000
Received: from [85.158.138.51:33178] by server-10.bemta-3.messagelabs.com id
	53/07-01753-359C9EF4; Tue, 26 Jun 2012 14:38:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340721488!28447441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26158 invoked from network); 26 Jun 2012 14:38:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:38:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:38:07 +0100
Message-ID: <1340721486.3832.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 15:38:06 +0100
In-Reply-To: <20120625090537.GC1488@ocelot.phlegethon.org>
References: <20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Jean Guyader \(3P\)" <jean.guyader@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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,

Sorry it's taken me so long to get round to responding to this.

On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > >> On 14/06 03:56, Tim Deegan wrote:
> > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > >> > > Are you talking about having different version of V4V driver running
> > >> > > in the same VM?
> > >> >
> > >> > Yes.
> > >> >
> > >> > > I don't think that is a problem they both interact with Xen via
> > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > >> > > all fine.
> > >> >
> > >> > AFAICS if they both try to register the same port then one of them will
> > >> > silently get its ring discarded.  And if they both try to communicate
> > >> > with the same remote port their entries on the pending lists will get
> > >> > merged (which is probably not too bad).  I think the possibility for
> > >> > confusion depends on how you use the service.  Still, it seems better
> > >> > than the xenstore case, anyway. :)
> > >> >
> > >>
> > >> Not silently, register_ring will return an error.
> > >
> > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > list.
> > >
> > 
> > Ha yes. It does that now but I think it should return an error
> > informing up the stack that a ring has already been registered.
> 
> Actually, I think it's deliberate, to allow a guest to re-register all
> its rings after a suspend/resume or migration, without having to worry
> about whether it was actually migrated into a new domain or not. 

Which takes us back to the original issue Tim asked about with
cohabitation of multiple (perhaps just plain buggy or even malicious)
v4v clients in a single domain, doesn't it?

If one of the reasons for not using xenstore is the inability for
multiple clients to co-exist then there is no point moving to a
different scheme with the same (even if lesser) issue. Up until now v4v
has only been used by XenClient so it has avoided this issue but if we
take it upstream then presumably the potential for this sort of problem
to creep in comes back.

Some other things from my notes...

Can you remind me of the reasoning behind using VIRQ_V4V instead of
regular event channels? I can't see any reason why these
shouldn't/couldn't be regular event channels demuxed in the usual way.

Are you going to submit any client code? I think the most important of
these would be code to make libvchan able to use v4v if it is available
(and both ends agree), but any other client code (like the sockets
interface overlay I've heard about) would be interesting to see too.

Have you had any contact from any one else who is interested in building
stuff with these interfaces? (This is just curiosity about potential
wider usage)

I think you and Tim have been discussing access control -- can we get a
summary of what this is going to look like going forward. I suppose
there will be tools for manipulating this stuff -- can you post them?

The patches need plenty of documentation adding to them, both in the
interface docs in xen/include/public (marked up such that it comes out
nicely in docs/html aka
http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
design docs and any other useful material you have under docs itself.

Are we generally happy that we could run e.g. block or net traffic over
this channel? As it stands for example the single VIRQ would seem to
provide a scalability limit to how many disks and nics a domain could
have. Are there any other considerations we need to take into account
here?

Lastly -- have you given any thoughts to making the copy operation
asynchronous? This might allow us to take advantage of copy offload
hardware in the future?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 14:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 14:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjWuI-00031E-SL; Tue, 26 Jun 2012 14:38: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 1SjWuI-000312-0g
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 14:38:18 +0000
Received: from [85.158.138.51:33178] by server-10.bemta-3.messagelabs.com id
	53/07-01753-359C9EF4; Tue, 26 Jun 2012 14:38:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340721488!28447441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26158 invoked from network); 26 Jun 2012 14:38:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 14:38:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13226853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 14:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 15:38:07 +0100
Message-ID: <1340721486.3832.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 26 Jun 2012 15:38:06 +0100
In-Reply-To: <20120625090537.GC1488@ocelot.phlegethon.org>
References: <20120607094225.GB15139@spongy.cam.xci-test.com>
	<20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Jean Guyader \(3P\)" <jean.guyader@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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,

Sorry it's taken me so long to get round to responding to this.

On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > >> On 14/06 03:56, Tim Deegan wrote:
> > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > >> > > Are you talking about having different version of V4V driver running
> > >> > > in the same VM?
> > >> >
> > >> > Yes.
> > >> >
> > >> > > I don't think that is a problem they both interact with Xen via
> > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > >> > > all fine.
> > >> >
> > >> > AFAICS if they both try to register the same port then one of them will
> > >> > silently get its ring discarded.  And if they both try to communicate
> > >> > with the same remote port their entries on the pending lists will get
> > >> > merged (which is probably not too bad).  I think the possibility for
> > >> > confusion depends on how you use the service.  Still, it seems better
> > >> > than the xenstore case, anyway. :)
> > >> >
> > >>
> > >> Not silently, register_ring will return an error.
> > >
> > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > list.
> > >
> > 
> > Ha yes. It does that now but I think it should return an error
> > informing up the stack that a ring has already been registered.
> 
> Actually, I think it's deliberate, to allow a guest to re-register all
> its rings after a suspend/resume or migration, without having to worry
> about whether it was actually migrated into a new domain or not. 

Which takes us back to the original issue Tim asked about with
cohabitation of multiple (perhaps just plain buggy or even malicious)
v4v clients in a single domain, doesn't it?

If one of the reasons for not using xenstore is the inability for
multiple clients to co-exist then there is no point moving to a
different scheme with the same (even if lesser) issue. Up until now v4v
has only been used by XenClient so it has avoided this issue but if we
take it upstream then presumably the potential for this sort of problem
to creep in comes back.

Some other things from my notes...

Can you remind me of the reasoning behind using VIRQ_V4V instead of
regular event channels? I can't see any reason why these
shouldn't/couldn't be regular event channels demuxed in the usual way.

Are you going to submit any client code? I think the most important of
these would be code to make libvchan able to use v4v if it is available
(and both ends agree), but any other client code (like the sockets
interface overlay I've heard about) would be interesting to see too.

Have you had any contact from any one else who is interested in building
stuff with these interfaces? (This is just curiosity about potential
wider usage)

I think you and Tim have been discussing access control -- can we get a
summary of what this is going to look like going forward. I suppose
there will be tools for manipulating this stuff -- can you post them?

The patches need plenty of documentation adding to them, both in the
interface docs in xen/include/public (marked up such that it comes out
nicely in docs/html aka
http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
design docs and any other useful material you have under docs itself.

Are we generally happy that we could run e.g. block or net traffic over
this channel? As it stands for example the single VIRQ would seem to
provide a scalability limit to how many disks and nics a domain could
have. Are there any other considerations we need to take into account
here?

Lastly -- have you given any thoughts to making the copy operation
asynchronous? This might allow us to take advantage of copy offload
hardware in the future?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXKV-0003sY-Tt; Tue, 26 Jun 2012 15:05:23 +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 1SjXKT-0003sK-S1
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:05:22 +0000
Received: from [85.158.138.51:56720] by server-11.bemta-3.messagelabs.com id
	C9/86-02904-BAFC9EF4; Tue, 26 Jun 2012 15:05:15 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340723115!21539204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25166 invoked from network); 26 Jun 2012 15:05:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13227772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:04:32 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 16:04:32 +0100
Message-ID: <4FE9CF7D.3060403@citrix.com>
Date: Tue, 26 Jun 2012 16:04:29 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
In-Reply-To: <20452.22522.766301.170343@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>                    ^^^^^^
> later

Thanks

>> we reached the desired xenbus state.
>
> Thanks, here are my review comments:
>
>
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 85c21b4..937ab08 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
> ...
>> +/* AO operation to connect a disk device, called by
>> + * libxl_device_disk_add and libxl__add_disks. This function calls
>> + * libxl__initiate_device_connection to wait for the device to
>> + * finish the connection (might involve executing hotplug scripts).
>> + */
>> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
>> +                                    xs_transaction_t t,
>> +                                    libxl_device_disk *disk,
>> +                                    libxl__ao_device *aodev);
>> +
>
> This is a confusing doc comment.  The reader doesn't want to know how
> the function is implemented; we need to know what it does.
> Particularly, we need to know what happens when it completes.  I infer
> that it calls aodev->callback but this should be stated.

Yes, fixed comment.

>> +/* Waits for the passed device to reach state XenbusStateInitWait.
>> + * This is not really useful by itself, but is important when executing
>> + * hotplug scripts, since we need to be sure the device is in the correct
>> + * state before executing them.
>> + *
>> + * Once finished, aodev->callback will be executed.
>> + */
>> +_hidden void libxl__initiate_device_connection(libxl__egc*,
>> +                                               libxl__ao_device *aodev);
>
> This function's name and its functionality seem not to correspond.  It
> doesn't actually initiate anything, as far as I can tell.

I've renamed it to libxl__wait_device_connection

>>   /* First layer; wraps libxl__spawn_spawn. */
>> @@ -2033,6 +2068,8 @@ typedef struct {
>>       libxl__domain_build_state dm_state;
>>       libxl__dm_spawn_state pvqemu;
>>       libxl__destroy_domid_state dis;
>> +    /* used to store the state of devices being connected */
>> +    libxl__ao_devices aodevs;
>>   } libxl__stub_dm_spawn_state;
>
> I'm not sure how valuable these comments are.  libxl__ao_devices are
> always used to store the state of devices being "<something>'d".
> That's what a libxl__ao_devices is for.  And in the context of a spawn
> or create that would obviously be "connected".
>
> In general I'm a fan of comments which say things which aren't clear
> from the code, but I'm not keen on ones which restate what the code
> says.

I've removed both occurrences of this comment.

>
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index 9243806..5d34ed5 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -442,6 +442,45 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>>       return;
>>   }
>>
>> +/******************************************************************************/
>> +
>> +/* Macro for defining the functions that will add a bunch of disks when
>> + * inside an async op.
>> + *
>> + * This macro is added to prevent repetition of code.
>> + */
>> +
>> +/* Capatibility macro, since disk_add now takes a xs transaction parameter */
>> +#define libxl__device_disk_add(egc, domid, disk, aodev)                       \
>> +        libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
>
> Is it really safe to call libxl__device_disk_add without a real
> transaction ?  I see that the current code does it but it seems wrong
> to me.  We end up writing all of the individual settings in the
> backend one at a time.

Well, this is not really my code, this was part of Stefanos series about 
local disk attach. However, I don't see how we end up writing them one 
at a time, libxl__device_generic_add creates a transaction if none is 
given, so all backend and frontend entries are added at the same 
transaction. Calling libxl__device_disk_add without a transaction 
behaves just like it did previously.

> I think this applies to all the other device types too.  So I think
> the right answer would be to make them take a transaction parameter
> too.  Ie, insert a patch before this one which adds a transaction
> parameter (ignored for now and always passed 0 if you don't want to
> actually make it work properly) to libxl__add_nic etc.  Then you don't
> need this unpleasant macro.

Ok, I will add this patch that makes all device_*_add take a transaction 
parameter, although it will be ignored right now.

>> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
>> +{
>> +    STATE_AO_GC(aodev->ao);
>> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
>> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>> +    int rc = 0;
> ...
>> +out_fail:
>> +    assert(rc);
>> +    aodev->rc = rc;
>> +    device_xsentries_remove(egc, aodev);
>> +    return;
>> +}
>
> Firstly, I'm not convinced it's really proper for
> libxl__initiate_device_connection to call device_xsentries_remove.
> After all device_xsentries_remove is part of the implementation of
> libxl__initiate_device_remove.

This is part of both flows, both device connection and disconnection.

> And, secondly, does device_xsentries_remove really do what you want ?
> It has a test in it which makes it only do its work if action is
> DISCONNECT.

Yes, that's because it's called by both flows.

>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 43affd1..5f09740 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>
>
>> @@ -2027,15 +2046,17 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,
>
>> +                dls->t = xs_transaction_start(ctx->xsh);
>> +                if (dls->t == XBT_NULL) {
>> +                    LOG(ERROR, "failed to start a xenstore transaction");
>> +                    rc = ERROR_FAIL;
>> +                    goto out;
>> +                }
>> +                disk->vdev = libxl__alloc_vdev(gc, blkdev_start, dls->t);
> ...
>> +                libxl__device_disk_add(egc, LIBXL_TOOLSTACK_DOMID,
>> +                                       dls->t, disk,&dls->aodev);
> ...
>> +    xs_ret = xs_transaction_end(ctx->xsh, dls->t, 0);
>> +    if (xs_ret == 0&&  errno == EAGAIN) {
>> +        libxl__device_disk_local_attach(egc, dls);
>> +        return;
>
> Isn't the effect of this that if the xs transaction gets a conflict,
> we'll rerun the hotplug scripts, etc. ?  I think I may be confused
> here, but I don't understand how this transaction loop is supposed to
> work and how it is supposed to relate to the interaction with other
> domains, scripts, etc.

Yes I see your point. We should disconnect the device (execute hotplug 
scripts) but since the xenstore entries are already gone (because the 
transaction is not committed successfully) I don't see anyway to do it, 
we cannot execute those scripts if the backend entries have been lost.

> Indeed it seems to me like your arrangements in libxl__device_disk_add
> couldn't work if a non-null t was supplied.  libxl__device_disk_add
> would do all the writes in the transaction, but not commit it, so that
> none of them are visible to anyone, and then wait for the deivde state
> to change, which will never happen.

I'm not so sure, is it possible to add a watch to a xenstore path that 
is inside of a not yet committed transaction? If so this will work fine, 
the transaction will be finished correctly, and the path will be updated 
to the correct state (2).

If the transaction is not committed successfully, we will get a timeout 
from the devstate event and exit.

>
>>   static void libxl__device_disk_from_xs_be(libxl__gc *gc,
>> @@ -1982,11 +1999,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>>       ret = 0;
>>
>>       libxl_device_disk_remove(ctx, domid, disks + i, 0);
>> -    libxl_device_disk_add(ctx, domid, disk);
>> +    /* fixme-ao */
>> +    libxl_device_disk_add(ctx, domid, disk, 0);
>>       stubdomid = libxl_get_stubdom_id(ctx, domid);
>>       if (stubdomid) {
>>           libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
>> -        libxl_device_disk_add(ctx, stubdomid, disk);
>> +        /* fixme-ao */
>> +        libxl_device_disk_add(ctx, stubdomid, disk, 0);
>
> I think this code is a symptom of a problem elsewhere.  When adding a
> disk to a domain, it should not be necessary to explicitly ask to add
> it to the stubdom too.  But this is not your fault, or your problem
> right now.

So I assume we can leave this for later.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXKV-0003sY-Tt; Tue, 26 Jun 2012 15:05:23 +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 1SjXKT-0003sK-S1
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:05:22 +0000
Received: from [85.158.138.51:56720] by server-11.bemta-3.messagelabs.com id
	C9/86-02904-BAFC9EF4; Tue, 26 Jun 2012 15:05:15 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340723115!21539204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25166 invoked from network); 26 Jun 2012 15:05:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13227772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:04:32 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 16:04:32 +0100
Message-ID: <4FE9CF7D.3060403@citrix.com>
Date: Tue, 26 Jun 2012 16:04:29 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
In-Reply-To: <20452.22522.766301.170343@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op"):
>> This patch converts libxl_device_disk_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>                    ^^^^^^
> later

Thanks

>> we reached the desired xenbus state.
>
> Thanks, here are my review comments:
>
>
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 85c21b4..937ab08 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
> ...
>> +/* AO operation to connect a disk device, called by
>> + * libxl_device_disk_add and libxl__add_disks. This function calls
>> + * libxl__initiate_device_connection to wait for the device to
>> + * finish the connection (might involve executing hotplug scripts).
>> + */
>> +_hidden void libxl__device_disk_add(libxl__egc *egc, uint32_t domid,
>> +                                    xs_transaction_t t,
>> +                                    libxl_device_disk *disk,
>> +                                    libxl__ao_device *aodev);
>> +
>
> This is a confusing doc comment.  The reader doesn't want to know how
> the function is implemented; we need to know what it does.
> Particularly, we need to know what happens when it completes.  I infer
> that it calls aodev->callback but this should be stated.

Yes, fixed comment.

>> +/* Waits for the passed device to reach state XenbusStateInitWait.
>> + * This is not really useful by itself, but is important when executing
>> + * hotplug scripts, since we need to be sure the device is in the correct
>> + * state before executing them.
>> + *
>> + * Once finished, aodev->callback will be executed.
>> + */
>> +_hidden void libxl__initiate_device_connection(libxl__egc*,
>> +                                               libxl__ao_device *aodev);
>
> This function's name and its functionality seem not to correspond.  It
> doesn't actually initiate anything, as far as I can tell.

I've renamed it to libxl__wait_device_connection

>>   /* First layer; wraps libxl__spawn_spawn. */
>> @@ -2033,6 +2068,8 @@ typedef struct {
>>       libxl__domain_build_state dm_state;
>>       libxl__dm_spawn_state pvqemu;
>>       libxl__destroy_domid_state dis;
>> +    /* used to store the state of devices being connected */
>> +    libxl__ao_devices aodevs;
>>   } libxl__stub_dm_spawn_state;
>
> I'm not sure how valuable these comments are.  libxl__ao_devices are
> always used to store the state of devices being "<something>'d".
> That's what a libxl__ao_devices is for.  And in the context of a spawn
> or create that would obviously be "connected".
>
> In general I'm a fan of comments which say things which aren't clear
> from the code, but I'm not keen on ones which restate what the code
> says.

I've removed both occurrences of this comment.

>
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index 9243806..5d34ed5 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -442,6 +442,45 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>>       return;
>>   }
>>
>> +/******************************************************************************/
>> +
>> +/* Macro for defining the functions that will add a bunch of disks when
>> + * inside an async op.
>> + *
>> + * This macro is added to prevent repetition of code.
>> + */
>> +
>> +/* Capatibility macro, since disk_add now takes a xs transaction parameter */
>> +#define libxl__device_disk_add(egc, domid, disk, aodev)                       \
>> +        libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
>
> Is it really safe to call libxl__device_disk_add without a real
> transaction ?  I see that the current code does it but it seems wrong
> to me.  We end up writing all of the individual settings in the
> backend one at a time.

Well, this is not really my code, this was part of Stefanos series about 
local disk attach. However, I don't see how we end up writing them one 
at a time, libxl__device_generic_add creates a transaction if none is 
given, so all backend and frontend entries are added at the same 
transaction. Calling libxl__device_disk_add without a transaction 
behaves just like it did previously.

> I think this applies to all the other device types too.  So I think
> the right answer would be to make them take a transaction parameter
> too.  Ie, insert a patch before this one which adds a transaction
> parameter (ignored for now and always passed 0 if you don't want to
> actually make it work properly) to libxl__add_nic etc.  Then you don't
> need this unpleasant macro.

Ok, I will add this patch that makes all device_*_add take a transaction 
parameter, although it will be ignored right now.

>> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
>> +{
>> +    STATE_AO_GC(aodev->ao);
>> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
>> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>> +    int rc = 0;
> ...
>> +out_fail:
>> +    assert(rc);
>> +    aodev->rc = rc;
>> +    device_xsentries_remove(egc, aodev);
>> +    return;
>> +}
>
> Firstly, I'm not convinced it's really proper for
> libxl__initiate_device_connection to call device_xsentries_remove.
> After all device_xsentries_remove is part of the implementation of
> libxl__initiate_device_remove.

This is part of both flows, both device connection and disconnection.

> And, secondly, does device_xsentries_remove really do what you want ?
> It has a test in it which makes it only do its work if action is
> DISCONNECT.

Yes, that's because it's called by both flows.

>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 43affd1..5f09740 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>
>
>> @@ -2027,15 +2046,17 @@ static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start,
>
>> +                dls->t = xs_transaction_start(ctx->xsh);
>> +                if (dls->t == XBT_NULL) {
>> +                    LOG(ERROR, "failed to start a xenstore transaction");
>> +                    rc = ERROR_FAIL;
>> +                    goto out;
>> +                }
>> +                disk->vdev = libxl__alloc_vdev(gc, blkdev_start, dls->t);
> ...
>> +                libxl__device_disk_add(egc, LIBXL_TOOLSTACK_DOMID,
>> +                                       dls->t, disk,&dls->aodev);
> ...
>> +    xs_ret = xs_transaction_end(ctx->xsh, dls->t, 0);
>> +    if (xs_ret == 0&&  errno == EAGAIN) {
>> +        libxl__device_disk_local_attach(egc, dls);
>> +        return;
>
> Isn't the effect of this that if the xs transaction gets a conflict,
> we'll rerun the hotplug scripts, etc. ?  I think I may be confused
> here, but I don't understand how this transaction loop is supposed to
> work and how it is supposed to relate to the interaction with other
> domains, scripts, etc.

Yes I see your point. We should disconnect the device (execute hotplug 
scripts) but since the xenstore entries are already gone (because the 
transaction is not committed successfully) I don't see anyway to do it, 
we cannot execute those scripts if the backend entries have been lost.

> Indeed it seems to me like your arrangements in libxl__device_disk_add
> couldn't work if a non-null t was supplied.  libxl__device_disk_add
> would do all the writes in the transaction, but not commit it, so that
> none of them are visible to anyone, and then wait for the deivde state
> to change, which will never happen.

I'm not so sure, is it possible to add a watch to a xenstore path that 
is inside of a not yet committed transaction? If so this will work fine, 
the transaction will be finished correctly, and the path will be updated 
to the correct state (2).

If the transaction is not committed successfully, we will get a timeout 
from the devstate event and exit.

>
>>   static void libxl__device_disk_from_xs_be(libxl__gc *gc,
>> @@ -1982,11 +1999,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
>>       ret = 0;
>>
>>       libxl_device_disk_remove(ctx, domid, disks + i, 0);
>> -    libxl_device_disk_add(ctx, domid, disk);
>> +    /* fixme-ao */
>> +    libxl_device_disk_add(ctx, domid, disk, 0);
>>       stubdomid = libxl_get_stubdom_id(ctx, domid);
>>       if (stubdomid) {
>>           libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
>> -        libxl_device_disk_add(ctx, stubdomid, disk);
>> +        /* fixme-ao */
>> +        libxl_device_disk_add(ctx, stubdomid, disk, 0);
>
> I think this code is a symptom of a problem elsewhere.  When adding a
> disk to a domain, it should not be necessary to explicitly ask to add
> it to the stubdom too.  But this is not your fault, or your problem
> right now.

So I assume we can leave this for later.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:06:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXLF-0003xI-I2; Tue, 26 Jun 2012 15:06: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 1SjXLE-0003x7-84
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:06:08 +0000
Received: from [85.158.138.51:4159] by server-4.bemta-3.messagelabs.com id
	72/E7-17105-FDFC9EF4; Tue, 26 Jun 2012 15:06:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340723166!10951509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17849 invoked from network); 26 Jun 2012 15:06:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:06:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13227820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:06:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 16:06:06 +0100
Message-ID: <1340723164.3832.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 26 Jun 2012 16:06:04 +0100
In-Reply-To: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
References: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] tools: honour --libdir when it is passed
 to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-06-23 at 22:12 +0100, Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks Matt.

Ian.

> 
> Changes since v2:
>  * Drop the #ifndef check for FSIMAGE_FSDIR, let the normal compiler
>    error provide information that something is wrong.
>  * Don't include config/Tools.mk from the top level Config.mk.
>  * Just assume that libraries specified via EXTRA_PREFIX live in
>    $(EXTRA_LIB)/lib. EXTRA_PREFIX should probably just go away one day.
> 
> diff -r 32034d1914a6 -r 177d5f1e353f Config.mk
> --- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -67,7 +67,7 @@ endef
>  
>  ifneq ($(EXTRA_PREFIX),)
>  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> +EXTRA_LIB += $(EXTRA_PREFIX)/lib
>  endif
>  
>  PYTHON      ?= python
> diff -r 32034d1914a6 -r 177d5f1e353f config/NetBSD.mk
> --- a/config/NetBSD.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/NetBSD.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,7 +1,6 @@
>  include $(XEN_ROOT)/config/StdGNU.mk
>  
>  # Override settings for this OS
> -LIBLEAFDIR_x86_64 = lib
>  LIBEXEC = $(PREFIX)/libexec
>  PRIVATE_BINDIR = $(BINDIR)
>  
> diff -r 32034d1914a6 -r 177d5f1e353f config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
>  PREFIX ?= /usr
>  BINDIR = $(PREFIX)/bin
>  INCLUDEDIR = $(PREFIX)/include
> -LIBLEAFDIR = lib
> -LIBLEAFDIR_x86_32 = lib
> -LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> +LIBEXEC = $(PREFIX)/lib/xen/bin
>  SHAREDIR = $(PREFIX)/share
>  MANDIR = $(SHAREDIR)/man
>  MAN1DIR = $(MANDIR)/man1
> diff -r 32034d1914a6 -r 177d5f1e353f config/SunOS.mk
> --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -22,10 +22,6 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
>  PREFIX ?= /usr
>  BINDIR = $(PREFIX)/bin
>  INCLUDEDIR = $(PREFIX)/include
> -LIBLEAFDIR = lib
> -LIBLEAFDIR_x86_64 = lib/amd64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>  MANDIR = $(PREFIX)/share/man
>  MAN1DIR = $(MANDIR)/man1
>  MAN8DIR = $(MANDIR)/man8
> diff -r 32034d1914a6 -r 177d5f1e353f config/Tools.mk.in
> --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,6 +1,7 @@
>  # Prefix and install folder
>  PREFIX              := @prefix@
> -LIBLEAFDIR_x86_64   := @LIB_PATH@
> +exec_prefix         := @exec_prefix@
> +LIBDIR              := @libdir@
>  
>  # A debug build of tools?
>  debug               := @debug@
> diff -r 32034d1914a6 -r 177d5f1e353f config/x86_64.mk
> --- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -10,9 +10,6 @@ CONFIG_IOEMU := y
>  
>  CFLAGS += -m64
>  
> -LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
> -LIBDIR = $(LIBDIR_x86_64)
> -
>  SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
>  
>  # Use only if calling $(LD) directly.
> diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/Rules.mk
> --- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,17 +1,12 @@
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> -CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
> +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
>  CFLAGS += -Werror -D_GNU_SOURCE
>  LDFLAGS += -L../common/
>  
>  PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
>  
> -FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
> -FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
> -FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
> -FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
> -FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
> -FSDIR = $(FSDIR-y)
> +FSDIR = $(LIBDIR)/fs
>  
>  FSLIB = fsimage.so
>  
> @@ -20,8 +15,8 @@ fs-all: $(FSLIB)
>  
>  .PHONY: fs-install
>  fs-install: fs-all
> -	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
> -	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
> +	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
> +	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
>  
>  $(FSLIB): $(PIC_OBJS)
>  	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
> diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/Makefile
> --- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,5 @@
>  XEN_ROOT = $(CURDIR)/../../..
> -include $(XEN_ROOT)/tools/Rules.mk
> +include $(XEN_ROOT)/tools/libfsimage/Rules.mk
>  
>  MAJOR = 1.0
>  MINOR = 0
> diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/fsimage_plugin.c
> --- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
> @@ -122,7 +122,6 @@ fail:
>  static int load_plugins(void)
>  {
>  	const char *fsdir = getenv("FSIMAGE_FSDIR");
> -	const char *isadir = "";
>  	struct dirent *dp = NULL;
>  	struct dirent *dpp;
>  	DIR *dir = NULL;
> @@ -131,26 +130,8 @@ static int load_plugins(void)
>  	int err;
>  	int ret = -1;
>  
> -#if defined(FSIMAGE_FSDIR)
>  	if (fsdir == NULL)
>  		fsdir = FSIMAGE_FSDIR;
> -#elif defined(__sun__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -
> -	if (sizeof(void *) == 8)
> -		isadir = "64/";
> -#elif defined(__ia64__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -#else
> -	if (fsdir == NULL) {
> -		if (sizeof(void *) == 8)
> -			fsdir = "/usr/lib64/fs";
> -		else
> -			fsdir = "/usr/lib/fs";
> -	}
> -#endif
>  
>  	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
>  		goto fail;
> @@ -172,8 +153,8 @@ static int load_plugins(void)
>  		if (strcmp(dpp->d_name, "..") == 0)
>  			continue;
>  
> -		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
> -		    dpp->d_name, isadir);
> +		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
> +			dpp->d_name);
>  
>  		if (init_plugin(tmp) != 0)
>  			goto fail;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:06:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXLF-0003xI-I2; Tue, 26 Jun 2012 15:06: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 1SjXLE-0003x7-84
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:06:08 +0000
Received: from [85.158.138.51:4159] by server-4.bemta-3.messagelabs.com id
	72/E7-17105-FDFC9EF4; Tue, 26 Jun 2012 15:06:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340723166!10951509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17849 invoked from network); 26 Jun 2012 15:06:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:06:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13227820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:06:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 16:06:06 +0100
Message-ID: <1340723164.3832.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 26 Jun 2012 16:06:04 +0100
In-Reply-To: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
References: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] tools: honour --libdir when it is passed
 to ./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-06-23 at 22:12 +0100, Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks Matt.

Ian.

> 
> Changes since v2:
>  * Drop the #ifndef check for FSIMAGE_FSDIR, let the normal compiler
>    error provide information that something is wrong.
>  * Don't include config/Tools.mk from the top level Config.mk.
>  * Just assume that libraries specified via EXTRA_PREFIX live in
>    $(EXTRA_LIB)/lib. EXTRA_PREFIX should probably just go away one day.
> 
> diff -r 32034d1914a6 -r 177d5f1e353f Config.mk
> --- a/Config.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/Config.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -67,7 +67,7 @@ endef
>  
>  ifneq ($(EXTRA_PREFIX),)
>  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> +EXTRA_LIB += $(EXTRA_PREFIX)/lib
>  endif
>  
>  PYTHON      ?= python
> diff -r 32034d1914a6 -r 177d5f1e353f config/NetBSD.mk
> --- a/config/NetBSD.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/NetBSD.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,7 +1,6 @@
>  include $(XEN_ROOT)/config/StdGNU.mk
>  
>  # Override settings for this OS
> -LIBLEAFDIR_x86_64 = lib
>  LIBEXEC = $(PREFIX)/libexec
>  PRIVATE_BINDIR = $(BINDIR)
>  
> diff -r 32034d1914a6 -r 177d5f1e353f config/StdGNU.mk
> --- a/config/StdGNU.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
>  PREFIX ?= /usr
>  BINDIR = $(PREFIX)/bin
>  INCLUDEDIR = $(PREFIX)/include
> -LIBLEAFDIR = lib
> -LIBLEAFDIR_x86_32 = lib
> -LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> +LIBEXEC = $(PREFIX)/lib/xen/bin
>  SHAREDIR = $(PREFIX)/share
>  MANDIR = $(SHAREDIR)/man
>  MAN1DIR = $(MANDIR)/man1
> diff -r 32034d1914a6 -r 177d5f1e353f config/SunOS.mk
> --- a/config/SunOS.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/SunOS.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -22,10 +22,6 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
>  PREFIX ?= /usr
>  BINDIR = $(PREFIX)/bin
>  INCLUDEDIR = $(PREFIX)/include
> -LIBLEAFDIR = lib
> -LIBLEAFDIR_x86_64 = lib/amd64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
>  MANDIR = $(PREFIX)/share/man
>  MAN1DIR = $(MANDIR)/man1
>  MAN8DIR = $(MANDIR)/man8
> diff -r 32034d1914a6 -r 177d5f1e353f config/Tools.mk.in
> --- a/config/Tools.mk.in	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/Tools.mk.in	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,6 +1,7 @@
>  # Prefix and install folder
>  PREFIX              := @prefix@
> -LIBLEAFDIR_x86_64   := @LIB_PATH@
> +exec_prefix         := @exec_prefix@
> +LIBDIR              := @libdir@
>  
>  # A debug build of tools?
>  debug               := @debug@
> diff -r 32034d1914a6 -r 177d5f1e353f config/x86_64.mk
> --- a/config/x86_64.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/x86_64.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -10,9 +10,6 @@ CONFIG_IOEMU := y
>  
>  CFLAGS += -m64
>  
> -LIBLEAFDIR = $(LIBLEAFDIR_x86_64)
> -LIBDIR = $(LIBDIR_x86_64)
> -
>  SunOS_LIBDIR = $(SunOS_LIBDIR_x86_64)
>  
>  # Use only if calling $(LD) directly.
> diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/Rules.mk
> --- a/tools/libfsimage/Rules.mk	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/Rules.mk	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,17 +1,12 @@
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> -CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/
> +CFLAGS += -Wno-unknown-pragmas -I$(XEN_ROOT)/tools/libfsimage/common/ -DFSIMAGE_FSDIR=\"$(FSDIR)\"
>  CFLAGS += -Werror -D_GNU_SOURCE
>  LDFLAGS += -L../common/
>  
>  PIC_OBJS := $(patsubst %.c,%.opic,$(LIB_SRCS-y))
>  
> -FSDIR-$(CONFIG_Linux) = $(LIBDIR)/fs/$(FS)
> -FSDIR-$(CONFIG_SunOS)-x86_64 = $(PREFIX)/lib/fs/$(FS)/64
> -FSDIR-$(CONFIG_SunOS)-x86_32 = $(PREFIX)/lib/fs/$(FS)/
> -FSDIR-$(CONFIG_SunOS) = $(FSDIR-$(CONFIG_SunOS)-$(XEN_TARGET_ARCH))
> -FSDIR-$(CONFIG_NetBSD) = $(LIBDIR)/fs/$(FS)
> -FSDIR = $(FSDIR-y)
> +FSDIR = $(LIBDIR)/fs
>  
>  FSLIB = fsimage.so
>  
> @@ -20,8 +15,8 @@ fs-all: $(FSLIB)
>  
>  .PHONY: fs-install
>  fs-install: fs-all
> -	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)
> -	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)
> +	$(INSTALL_DIR) $(DESTDIR)$(FSDIR)/$(FS)
> +	$(INSTALL_PROG) $(FSLIB) $(DESTDIR)$(FSDIR)/$(FS)
>  
>  $(FSLIB): $(PIC_OBJS)
>  	$(CC) $(LDFLAGS) $(SHLIB_LDFLAGS) -o $@ $^ -lfsimage $(FS_LIBDEPS) $(APPEND_LDFLAGS)
> diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/Makefile
> --- a/tools/libfsimage/common/Makefile	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/Makefile	Wed Jun 20 00:40:15 2012 +0000
> @@ -1,5 +1,5 @@
>  XEN_ROOT = $(CURDIR)/../../..
> -include $(XEN_ROOT)/tools/Rules.mk
> +include $(XEN_ROOT)/tools/libfsimage/Rules.mk
>  
>  MAJOR = 1.0
>  MINOR = 0
> diff -r 32034d1914a6 -r 177d5f1e353f tools/libfsimage/common/fsimage_plugin.c
> --- a/tools/libfsimage/common/fsimage_plugin.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libfsimage/common/fsimage_plugin.c	Wed Jun 20 00:40:15 2012 +0000
> @@ -122,7 +122,6 @@ fail:
>  static int load_plugins(void)
>  {
>  	const char *fsdir = getenv("FSIMAGE_FSDIR");
> -	const char *isadir = "";
>  	struct dirent *dp = NULL;
>  	struct dirent *dpp;
>  	DIR *dir = NULL;
> @@ -131,26 +130,8 @@ static int load_plugins(void)
>  	int err;
>  	int ret = -1;
>  
> -#if defined(FSIMAGE_FSDIR)
>  	if (fsdir == NULL)
>  		fsdir = FSIMAGE_FSDIR;
> -#elif defined(__sun__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -
> -	if (sizeof(void *) == 8)
> -		isadir = "64/";
> -#elif defined(__ia64__)
> -	if (fsdir == NULL)
> -		fsdir = "/usr/lib/fs";
> -#else
> -	if (fsdir == NULL) {
> -		if (sizeof(void *) == 8)
> -			fsdir = "/usr/lib64/fs";
> -		else
> -			fsdir = "/usr/lib/fs";
> -	}
> -#endif
>  
>  	if ((name_max = pathconf(fsdir, _PC_NAME_MAX)) == -1)
>  		goto fail;
> @@ -172,8 +153,8 @@ static int load_plugins(void)
>  		if (strcmp(dpp->d_name, "..") == 0)
>  			continue;
>  
> -		(void) snprintf(tmp, name_max, "%s/%s/%sfsimage.so", fsdir,
> -		    dpp->d_name, isadir);
> +		(void) snprintf(tmp, name_max, "%s/%s/fsimage.so", fsdir,
> +			dpp->d_name);
>  
>  		if (init_plugin(tmp) != 0)
>  			goto fail;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:07:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXM0-00043U-H3; Tue, 26 Jun 2012 15:06:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1SjXLz-00043J-JD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:06:55 +0000
Received: from [193.109.254.147:62819] by server-2.bemta-14.messagelabs.com id
	93/5A-01735-E00D9EF4; Tue, 26 Jun 2012 15:06:54 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340723200!8657716!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23572 invoked from network); 26 Jun 2012 15:06:41 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:06:41 -0000
Received: by ggnp1 with SMTP id p1so4556271ggn.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 08:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=CstBTOYObWMROte4YKdhgnN0NRZIRhP/fdpYD9QfYPs=;
	b=1I28iM7lcD/PC4dTLTnNX+9ReqKFYlNQk1bHNg60UfpV6ZWt/XN6hqdTLG5umzIi2V
	8eTbrmF9HcrXRWPYLnjTktLtWSj9vJGLK4Kw/s6T/WHa6ShkiJZf+95nYgWkHwV1872k
	nL2a1gOoAmgnx0xVyLXqoD/iZdg4oB63nCugen+jXRHmqR010VsIqQYefupWlCP6rVEC
	2Cp2cehqEVfbDVE82NvPV+1k/OR/ZlEcZMURqDsA7UDBga1MgIJnV5xkX8EXLaXP1BPh
	pyZnNc0TX7LUlYEHD0K++qSCbcHirbT2I+VNOYZJ0Aqq0ncOul2dUyaSJqx+f+ORtmNx
	/M8A==
Received: by 10.50.209.102 with SMTP id ml6mr11461705igc.60.1340723199806;
	Tue, 26 Jun 2012 08:06:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.58.83 with HTTP; Tue, 26 Jun 2012 08:06:09 -0700 (PDT)
In-Reply-To: <1340720499.3832.132.camel@zakaz.uk.xensource.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
	<1340708071.3832.68.camel@zakaz.uk.xensource.com>
	<CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
	<1340720499.3832.132.camel@zakaz.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 16:06:09 +0100
X-Google-Sender-Auth: xKcGLCXWBgQ1SS3_D0P49k6BcHA
Message-ID: <CAJJyHjKMisPam2b2m-_tRHno9rC+UUBHdPRAnqGR_E3MfxYXBg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 3:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-06-26 at 15:13 +0100, Anthony PERARD wrote:
>> On Tue, Jun 26, 2012 at 11:54 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
>> >> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
>> >> parameter. This patch changes the ownership of the buifioreq event channel to
>> >> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
>> >>
>> >> This fix the initialization of QEMU inside the stubdomain.
>> >>
>> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> >
>> > This fixes stub domains for me, thanks.
>> >
>> > The user of this field (hvm_buffered_io_send) takes iorp->lock so we
>> > probably want to put the update inside that too, just like for the
>> > non-buffered case?
>>
>> Will do.
>>
>> > It would be nice to extract the alloc&replace functionality into a
>> > helper.
>>
>> I tried but it does not work well.
>> xen_port is an it (non-buffer case) and params[bufioreq...] is an
>> uint64_t. Both should be argument of the helper, as a pointer to be
>> pass to xchg().
>>
>> The prototype of the not working helper:
>> static int hvm_replace_event_channel(struct vcpu *v, uint64_t
>> remote_domid, int *port)
>>
>> So unless there is another way to create this helper, there won't be any.
>
> Although params[...] are generally uint64_t the params[BUFIOREQ_EVTCHN]
> is really an int (or more properly an evtchn_port_t, although this is
> only used in include/public). Perhaps a cast is appropriate in this
> case?

All right, I will cast.

-- 
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 Jun 26 15:07:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXM0-00043U-H3; Tue, 26 Jun 2012 15:06:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1SjXLz-00043J-JD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:06:55 +0000
Received: from [193.109.254.147:62819] by server-2.bemta-14.messagelabs.com id
	93/5A-01735-E00D9EF4; Tue, 26 Jun 2012 15:06:54 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340723200!8657716!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23572 invoked from network); 26 Jun 2012 15:06:41 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:06:41 -0000
Received: by ggnp1 with SMTP id p1so4556271ggn.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 08:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=CstBTOYObWMROte4YKdhgnN0NRZIRhP/fdpYD9QfYPs=;
	b=1I28iM7lcD/PC4dTLTnNX+9ReqKFYlNQk1bHNg60UfpV6ZWt/XN6hqdTLG5umzIi2V
	8eTbrmF9HcrXRWPYLnjTktLtWSj9vJGLK4Kw/s6T/WHa6ShkiJZf+95nYgWkHwV1872k
	nL2a1gOoAmgnx0xVyLXqoD/iZdg4oB63nCugen+jXRHmqR010VsIqQYefupWlCP6rVEC
	2Cp2cehqEVfbDVE82NvPV+1k/OR/ZlEcZMURqDsA7UDBga1MgIJnV5xkX8EXLaXP1BPh
	pyZnNc0TX7LUlYEHD0K++qSCbcHirbT2I+VNOYZJ0Aqq0ncOul2dUyaSJqx+f+ORtmNx
	/M8A==
Received: by 10.50.209.102 with SMTP id ml6mr11461705igc.60.1340723199806;
	Tue, 26 Jun 2012 08:06:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.58.83 with HTTP; Tue, 26 Jun 2012 08:06:09 -0700 (PDT)
In-Reply-To: <1340720499.3832.132.camel@zakaz.uk.xensource.com>
References: <1340707524-27665-1-git-send-email-anthony.perard@citrix.com>
	<1340708071.3832.68.camel@zakaz.uk.xensource.com>
	<CAJJyHj+heAS6YTfQx4QZg3TDgUGZ7T-76AtmJ=zQ6Y8LfWi-UQ@mail.gmail.com>
	<1340720499.3832.132.camel@zakaz.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 26 Jun 2012 16:06:09 +0100
X-Google-Sender-Auth: xKcGLCXWBgQ1SS3_D0P49k6BcHA
Message-ID: <CAJJyHjKMisPam2b2m-_tRHno9rC+UUBHdPRAnqGR_E3MfxYXBg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 3:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-06-26 at 15:13 +0100, Anthony PERARD wrote:
>> On Tue, Jun 26, 2012 at 11:54 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2012-06-26 at 11:45 +0100, Anthony PERARD wrote:
>> >> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
>> >> parameter. This patch changes the ownership of the buifioreq event channel to
>> >> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
>> >>
>> >> This fix the initialization of QEMU inside the stubdomain.
>> >>
>> >> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> >
>> > This fixes stub domains for me, thanks.
>> >
>> > The user of this field (hvm_buffered_io_send) takes iorp->lock so we
>> > probably want to put the update inside that too, just like for the
>> > non-buffered case?
>>
>> Will do.
>>
>> > It would be nice to extract the alloc&replace functionality into a
>> > helper.
>>
>> I tried but it does not work well.
>> xen_port is an it (non-buffer case) and params[bufioreq...] is an
>> uint64_t. Both should be argument of the helper, as a pointer to be
>> pass to xchg().
>>
>> The prototype of the not working helper:
>> static int hvm_replace_event_channel(struct vcpu *v, uint64_t
>> remote_domid, int *port)
>>
>> So unless there is another way to create this helper, there won't be any.
>
> Although params[...] are generally uint64_t the params[BUFIOREQ_EVTCHN]
> is really an int (or more properly an evtchn_port_t, although this is
> only used in include/public). Perhaps a cast is appropriate in this
> case?

All right, I will cast.

-- 
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 Jun 26 15:15:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:15: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 1SjXTf-0004UH-FQ; Tue, 26 Jun 2012 15:14: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 1SjXTd-0004U9-NR
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:14:49 +0000
Received: from [193.109.254.147:36804] by server-5.bemta-14.messagelabs.com id
	2D/96-04343-8E1D9EF4; Tue, 26 Jun 2012 15:14:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340723688!8610287!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28051 invoked from network); 26 Jun 2012 15:14:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 15:14:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 16:14:47 +0100
Message-Id: <4FE9EE33020000780008BFC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 16:15:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
	<1340622307.3832.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340622307.3832.16.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-06-25 at 11:54 +0100, Jan Beulich wrote:
>> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
>> as the whole function domain_pause_for_debugger() is pointless to be
>> compiled when there's no arch support, simply introduce another HAS_*
>> macro, enabled only on x86.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Hi Keir,

the subject was probably badly chosen to catch your attention,
but as the patch touches only non-ARM code (in order to make
ARM build again) it needs your approval for me to commit.

Jan

>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>>  
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>>  HAS_NS16550 := y
>>  HAS_EHCI := y
>>  HAS_KEXEC := y
>> +HAS_GDBSX := y
>>  xenoprof := y
>>  
>>  #
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>>          vcpu_check_shutdown(v);
>>  }
>>  
>> +#ifdef HAS_GDBSX
>>  void domain_pause_for_debugger(void)
>>  {
>>      struct domain *d = current->domain;
>> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>>      if (current->arch.gdbsx_vcpu_event == 0)
>>          send_global_virq(VIRQ_DEBUGGER);
>>  }
>> +#endif
>>  
>>  /* Complete domain destroy after RCU readers are not holding old 
> references. */
>>  static void complete_domain_destroy(struct rcu_head *head)
>> 
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:15:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:15: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 1SjXTf-0004UH-FQ; Tue, 26 Jun 2012 15:14: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 1SjXTd-0004U9-NR
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:14:49 +0000
Received: from [193.109.254.147:36804] by server-5.bemta-14.messagelabs.com id
	2D/96-04343-8E1D9EF4; Tue, 26 Jun 2012 15:14:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340723688!8610287!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28051 invoked from network); 26 Jun 2012 15:14:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 15:14:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 16:14:47 +0100
Message-Id: <4FE9EE33020000780008BFC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 16:15:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
	<1340622307.3832.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340622307.3832.16.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 13:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-06-25 at 11:54 +0100, Jan Beulich wrote:
>> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
>> as the whole function domain_pause_for_debugger() is pointless to be
>> compiled when there's no arch support, simply introduce another HAS_*
>> macro, enabled only on x86.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Hi Keir,

the subject was probably badly chosen to catch your attention,
but as the patch touches only non-ARM code (in order to make
ARM build again) it needs your approval for me to commit.

Jan

>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>>  
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>>  HAS_NS16550 := y
>>  HAS_EHCI := y
>>  HAS_KEXEC := y
>> +HAS_GDBSX := y
>>  xenoprof := y
>>  
>>  #
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>>          vcpu_check_shutdown(v);
>>  }
>>  
>> +#ifdef HAS_GDBSX
>>  void domain_pause_for_debugger(void)
>>  {
>>      struct domain *d = current->domain;
>> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>>      if (current->arch.gdbsx_vcpu_event == 0)
>>          send_global_virq(VIRQ_DEBUGGER);
>>  }
>> +#endif
>>  
>>  /* Complete domain destroy after RCU readers are not holding old 
> references. */
>>  static void complete_domain_destroy(struct rcu_head *head)
>> 
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:15:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:15: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 1SjXUa-0004Xp-Tv; Tue, 26 Jun 2012 15:15:48 +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 1SjXUZ-0004Xh-Sm
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:15:48 +0000
Received: from [85.158.139.83:42716] by server-10.bemta-5.messagelabs.com id
	32/89-02190-322D9EF4; Tue, 26 Jun 2012 15:15:47 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340723746!24461274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32721 invoked from network); 26 Jun 2012 15:15:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:15:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13228069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:14:08 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 16:14:08 +0100
Message-ID: <4FE9D1BD.7040204@citrix.com>
Date: Tue, 26 Jun 2012 16:14:05 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
	<4FE9CF7D.3060403@citrix.com>
In-Reply-To: <4FE9CF7D.3060403@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
>> Isn't the effect of this that if the xs transaction gets a conflict,
>> we'll rerun the hotplug scripts, etc. ?  I think I may be confused
>> here, but I don't understand how this transaction loop is supposed to
>> work and how it is supposed to relate to the interaction with other
>> domains, scripts, etc.
>
> Yes I see your point. We should disconnect the device (execute hotplug
> scripts) but since the xenstore entries are already gone (because the
> transaction is not committed successfully) I don't see anyway to do it,
> we cannot execute those scripts if the backend entries have been lost.

Sorry, I've made a mistake here, since the transaction is not committed, 
we never reach the desired state (2), so if the transaction fails no 
scripts are executed, and we can carry on trying to add the device again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:15:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:15: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 1SjXUa-0004Xp-Tv; Tue, 26 Jun 2012 15:15:48 +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 1SjXUZ-0004Xh-Sm
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:15:48 +0000
Received: from [85.158.139.83:42716] by server-10.bemta-5.messagelabs.com id
	32/89-02190-322D9EF4; Tue, 26 Jun 2012 15:15:47 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340723746!24461274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32721 invoked from network); 26 Jun 2012 15:15:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:15:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13228069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:14:08 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 16:14:08 +0100
Message-ID: <4FE9D1BD.7040204@citrix.com>
Date: Tue, 26 Jun 2012 16:14:05 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
	<4FE9CF7D.3060403@citrix.com>
In-Reply-To: <4FE9CF7D.3060403@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
>> Isn't the effect of this that if the xs transaction gets a conflict,
>> we'll rerun the hotplug scripts, etc. ?  I think I may be confused
>> here, but I don't understand how this transaction loop is supposed to
>> work and how it is supposed to relate to the interaction with other
>> domains, scripts, etc.
>
> Yes I see your point. We should disconnect the device (execute hotplug
> scripts) but since the xenstore entries are already gone (because the
> transaction is not committed successfully) I don't see anyway to do it,
> we cannot execute those scripts if the backend entries have been lost.

Sorry, I've made a mistake here, since the transaction is not committed, 
we never reach the desired state (2), so if the transaction fails no 
scripts are executed, and we can carry on trying to add the device again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:21:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXZd-0004mU-Qu; Tue, 26 Jun 2012 15:21:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjXZc-0004mN-9n
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:21:00 +0000
Received: from [85.158.143.35:62293] by server-2.bemta-4.messagelabs.com id
	3F/0C-17938-B53D9EF4; Tue, 26 Jun 2012 15:20:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340724044!6759485!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23727 invoked from network); 26 Jun 2012 15:20:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-21.messagelabs.com with SMTP;
	26 Jun 2012 15:20:45 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79144549; Tue, 26 Jun 2012 17:20:44 +0200
Message-ID: <1340724030.9444.14.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 17:20:30 +0200
In-Reply-To: <20457.38656.696529.142496@mariner.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
	<CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
	<20457.38656.696529.142496@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5009972362432083280=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5009972362432083280==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-DfGoO+eRhF5z11b6DAjW"


--=-DfGoO+eRhF5z11b6DAjW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 12:03 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable =
automatic placement of guests on NUMA nodes"):
> > The only potential concern is that it seems likely that your
> > comparison function above will not actually generate an ordering,
> > because the relationship it generates isn't transitive.  That is, you
> > could have a situation where A > B, B > C, but C > A.  For example:
> > A: freemem 1000, domains 1
> > B: freemem 1090, domains 2
> > C: freemem 1110, domains 3
> >=20
> > In this case, A>B, because memory is within 10% but has fewer domains.
> >  B > C, because B is within 10%, and has fewer domains.  But C > A,
> > because C has more than 10% more memory than A (so its domains are not
> > counted against it).
>=20
> The conventional approach to this kind of thing is to invent a score
> for sorting etc.  Something like
>     score =3D tuning_parameter * log(freemem) - number_of_domains
> which does sort of roughly the same as your 10% rule if you squint.
>=20
Right, I thought about this, but then got a bit scared about properly
mixing apple, oranges and melons (as I have number of nodes, amount of
free memory and number of domains), giving the proper "weight" to each
of them.

Anyway, I see the potential issue George is reporting, so I'll try to
come up with some formula...

Thanks and regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-DfGoO+eRhF5z11b6DAjW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p0z4ACgkQk4XaBE3IOsRwdwCfRZqsnzfrPdEYCVpxrsl633LF
BFoAoIGTCrA641EQz8KhdQ8XF+vSYUQr
=M1lC
-----END PGP SIGNATURE-----

--=-DfGoO+eRhF5z11b6DAjW--



--===============5009972362432083280==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5009972362432083280==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 15:21:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjXZd-0004mU-Qu; Tue, 26 Jun 2012 15:21:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjXZc-0004mN-9n
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:21:00 +0000
Received: from [85.158.143.35:62293] by server-2.bemta-4.messagelabs.com id
	3F/0C-17938-B53D9EF4; Tue, 26 Jun 2012 15:20:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340724044!6759485!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23727 invoked from network); 26 Jun 2012 15:20:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-21.messagelabs.com with SMTP;
	26 Jun 2012 15:20:45 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79144549; Tue, 26 Jun 2012 17:20:44 +0200
Message-ID: <1340724030.9444.14.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 17:20:30 +0200
In-Reply-To: <20457.38656.696529.142496@mariner.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
	<CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
	<20457.38656.696529.142496@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5009972362432083280=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5009972362432083280==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-DfGoO+eRhF5z11b6DAjW"


--=-DfGoO+eRhF5z11b6DAjW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 12:03 +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable =
automatic placement of guests on NUMA nodes"):
> > The only potential concern is that it seems likely that your
> > comparison function above will not actually generate an ordering,
> > because the relationship it generates isn't transitive.  That is, you
> > could have a situation where A > B, B > C, but C > A.  For example:
> > A: freemem 1000, domains 1
> > B: freemem 1090, domains 2
> > C: freemem 1110, domains 3
> >=20
> > In this case, A>B, because memory is within 10% but has fewer domains.
> >  B > C, because B is within 10%, and has fewer domains.  But C > A,
> > because C has more than 10% more memory than A (so its domains are not
> > counted against it).
>=20
> The conventional approach to this kind of thing is to invent a score
> for sorting etc.  Something like
>     score =3D tuning_parameter * log(freemem) - number_of_domains
> which does sort of roughly the same as your 10% rule if you squint.
>=20
Right, I thought about this, but then got a bit scared about properly
mixing apple, oranges and melons (as I have number of nodes, amount of
free memory and number of domains), giving the proper "weight" to each
of them.

Anyway, I see the potential issue George is reporting, so I'll try to
come up with some formula...

Thanks and regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-DfGoO+eRhF5z11b6DAjW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p0z4ACgkQk4XaBE3IOsRwdwCfRZqsnzfrPdEYCVpxrsl633LF
BFoAoIGTCrA641EQz8KhdQ8XF+vSYUQr
=M1lC
-----END PGP SIGNATURE-----

--=-DfGoO+eRhF5z11b6DAjW--



--===============5009972362432083280==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5009972362432083280==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 15:25:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:25: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 1SjXdk-0004uU-4i; Tue, 26 Jun 2012 15:25:16 +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 1SjXdi-0004uG-AO
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:25:14 +0000
Received: from [85.158.143.99:23439] by server-3.bemta-4.messagelabs.com id
	90/10-05808-954D9EF4; Tue, 26 Jun 2012 15:25:13 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340724310!28645972!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32304 invoked from network); 26 Jun 2012 15:25:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336363200"; d="scan'208";a="29469308"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 11:21:29 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:21:29 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SjXa4-0005Va-VL;
	Tue, 26 Jun 2012 16:21:29 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 16:21:27 +0100
Message-ID: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
parameter. This patch changes the ownership of the buifioreq event channel to
the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).

This patch introduces an helper to replace a xen port.

This fix the initialization of QEMU inside the stubdomain.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Change:
  - an helper
  - the replacement of the buferioreq evtchn is inside iorp->lock now.

 xen/arch/x86/hvm/hvm.c |   37 ++++++++++++++++++++++++++++---------
 1 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..e8e86c0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3664,6 +3664,21 @@ static int hvmop_flush_tlb_all(void)
     return 0;
 }
 
+static int hvm_replace_event_channel(struct vcpu *v, uint64_t remote_domid,
+                                     int *port)
+{
+    int old_port, new_port;
+
+    new_port = alloc_unbound_xen_event_channel(v, remote_domid, NULL);
+    if ( new_port < 0 )
+        return new_port;
+
+    /* xchg() ensures that only we free_xen_event_channel() */
+    old_port = xchg(port, new_port);
+    free_xen_event_channel(v, old_port);
+    return 0;
+}
+
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
 
 {
@@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                 iorp = &d->arch.hvm_domain.ioreq;
                 for_each_vcpu ( d, v )
                 {
-                    int old_port, new_port;
-                    new_port = alloc_unbound_xen_event_channel(
-                        v, a.value, NULL);
-                    if ( new_port < 0 )
-                    {
-                        rc = new_port;
+                    rc = hvm_replace_event_channel(v, a.value,
+                                                   &v->arch.hvm_vcpu.xen_port);
+                    if ( rc )
                         break;
+
+                    if ( v->vcpu_id == 0 )
+                    {
+                        spin_lock(&iorp->lock);
+                        rc = hvm_replace_event_channel(v, a.value,
+                            (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
+                        spin_unlock(&iorp->lock);
+                        if ( rc )
+                            break;
                     }
-                    /* xchg() ensures that only we free_xen_event_channel() */
-                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
-                    free_xen_event_channel(v, old_port);
+
                     spin_lock(&iorp->lock);
                     if ( iorp->va != NULL )
                         get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
-- 
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 Jun 26 15:25:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:25: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 1SjXdk-0004uU-4i; Tue, 26 Jun 2012 15:25:16 +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 1SjXdi-0004uG-AO
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:25:14 +0000
Received: from [85.158.143.99:23439] by server-3.bemta-4.messagelabs.com id
	90/10-05808-954D9EF4; Tue, 26 Jun 2012 15:25:13 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340724310!28645972!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTMyOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32304 invoked from network); 26 Jun 2012 15:25:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336363200"; d="scan'208";a="29469308"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 11:21:29 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 11:21:29 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1SjXa4-0005Va-VL;
	Tue, 26 Jun 2012 16:21:29 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 16:21:27 +0100
Message-ID: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
parameter. This patch changes the ownership of the buifioreq event channel to
the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).

This patch introduces an helper to replace a xen port.

This fix the initialization of QEMU inside the stubdomain.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
Change:
  - an helper
  - the replacement of the buferioreq evtchn is inside iorp->lock now.

 xen/arch/x86/hvm/hvm.c |   37 ++++++++++++++++++++++++++++---------
 1 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..e8e86c0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3664,6 +3664,21 @@ static int hvmop_flush_tlb_all(void)
     return 0;
 }
 
+static int hvm_replace_event_channel(struct vcpu *v, uint64_t remote_domid,
+                                     int *port)
+{
+    int old_port, new_port;
+
+    new_port = alloc_unbound_xen_event_channel(v, remote_domid, NULL);
+    if ( new_port < 0 )
+        return new_port;
+
+    /* xchg() ensures that only we free_xen_event_channel() */
+    old_port = xchg(port, new_port);
+    free_xen_event_channel(v, old_port);
+    return 0;
+}
+
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
 
 {
@@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                 iorp = &d->arch.hvm_domain.ioreq;
                 for_each_vcpu ( d, v )
                 {
-                    int old_port, new_port;
-                    new_port = alloc_unbound_xen_event_channel(
-                        v, a.value, NULL);
-                    if ( new_port < 0 )
-                    {
-                        rc = new_port;
+                    rc = hvm_replace_event_channel(v, a.value,
+                                                   &v->arch.hvm_vcpu.xen_port);
+                    if ( rc )
                         break;
+
+                    if ( v->vcpu_id == 0 )
+                    {
+                        spin_lock(&iorp->lock);
+                        rc = hvm_replace_event_channel(v, a.value,
+                            (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
+                        spin_unlock(&iorp->lock);
+                        if ( rc )
+                            break;
                     }
-                    /* xchg() ensures that only we free_xen_event_channel() */
-                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
-                    free_xen_event_channel(v, old_port);
+
                     spin_lock(&iorp->lock);
                     if ( iorp->va != NULL )
                         get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
-- 
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 Jun 26 15:26:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjXem-00053p-PT; Tue, 26 Jun 2012 15:26: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 1SjXel-00053P-4u
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:26:19 +0000
Received: from [85.158.138.51:37941] by server-10.bemta-3.messagelabs.com id
	D9/61-01753-A94D9EF4; Tue, 26 Jun 2012 15:26:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340724377!21473618!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20451 invoked from network); 26 Jun 2012 15:26:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13228458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:26:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 16:26:16 +0100
Message-ID: <1340724375.3832.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 16:26:15 +0100
In-Reply-To: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/40 V2] arm: boot a dom1 to "Calibrating
 delay loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:29 +0100, Ian Campbell wrote:
> I intend to commit those patches which are acked and which do not depend
> on non-acked patches shortly.
> 
> A     01 arm: allocate top level p2m page for all non-idle domains
> A     02 arm: handy function to print a walk of a page table
> A     03 arm: correct and expand TLB flush CP15 registers
> A     04 arm: restore stack on return from trap.
> A     05 arm: enable interrupts while handling traps
> A     06 arm: hook up domctl and memory_op
> A     07 arm: allocate and setup a guest vcpu.
> A     08 arm: print domid as part of debug trap
> A     09 arm: remove unnecessarily verbose print from p2m_load_VTTBR
> A     10 arm: implement p2m lookup
> A     11 arm: remove hard tabs from init_idle_domain
> A     12 arm: stub out sync_vcpu_execstate
> A     13 arm: implement stub version of flush_tlb_mask.
> A     14 arm: do not set max_vcpus = 8 in arch_domain_create.
> A     15 arm: Add simple cpu_{sibling,core}_mask

I have applied these.

[...]
> A     18 arm: context switch a bunch of guest state.
> A     19 arm: dump a page table walk when va_to_par fails.
> A     20 arm: dump guest s1 walk on data abort which is not a stage 2 issue.

And these.

[...]
> A     22 arm: use correct attributes for mappings in copy_from_paddr()

This didn't apply without "16 arm: allow p2m to be created with specific
MATTR.", skipped.

> A     23 arm: map fixmaps non-executable.
> A     24 arm: fix locking in create_p2m_entries

Applied these too.

After this point there were increasingly more rejects due to missing
patches, so I stopped.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:26:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjXem-00053p-PT; Tue, 26 Jun 2012 15:26: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 1SjXel-00053P-4u
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:26:19 +0000
Received: from [85.158.138.51:37941] by server-10.bemta-3.messagelabs.com id
	D9/61-01753-A94D9EF4; Tue, 26 Jun 2012 15:26:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340724377!21473618!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20451 invoked from network); 26 Jun 2012 15:26:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13228458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:26:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 16:26:16 +0100
Message-ID: <1340724375.3832.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 16:26:15 +0100
In-Reply-To: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 00/40 V2] arm: boot a dom1 to "Calibrating
 delay loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:29 +0100, Ian Campbell wrote:
> I intend to commit those patches which are acked and which do not depend
> on non-acked patches shortly.
> 
> A     01 arm: allocate top level p2m page for all non-idle domains
> A     02 arm: handy function to print a walk of a page table
> A     03 arm: correct and expand TLB flush CP15 registers
> A     04 arm: restore stack on return from trap.
> A     05 arm: enable interrupts while handling traps
> A     06 arm: hook up domctl and memory_op
> A     07 arm: allocate and setup a guest vcpu.
> A     08 arm: print domid as part of debug trap
> A     09 arm: remove unnecessarily verbose print from p2m_load_VTTBR
> A     10 arm: implement p2m lookup
> A     11 arm: remove hard tabs from init_idle_domain
> A     12 arm: stub out sync_vcpu_execstate
> A     13 arm: implement stub version of flush_tlb_mask.
> A     14 arm: do not set max_vcpus = 8 in arch_domain_create.
> A     15 arm: Add simple cpu_{sibling,core}_mask

I have applied these.

[...]
> A     18 arm: context switch a bunch of guest state.
> A     19 arm: dump a page table walk when va_to_par fails.
> A     20 arm: dump guest s1 walk on data abort which is not a stage 2 issue.

And these.

[...]
> A     22 arm: use correct attributes for mappings in copy_from_paddr()

This didn't apply without "16 arm: allow p2m to be created with specific
MATTR.", skipped.

> A     23 arm: map fixmaps non-executable.
> A     24 arm: fix locking in create_p2m_entries

Applied these too.

After this point there were increasingly more rejects due to missing
patches, so I stopped.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:42:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjXtn-00061m-Mg; Tue, 26 Jun 2012 15:41:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjXtm-00061O-Nm
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:41:50 +0000
Received: from [193.109.254.147:57014] by server-8.bemta-14.messagelabs.com id
	61/47-30743-D38D9EF4; Tue, 26 Jun 2012 15:41:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340725302!1782035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4934 invoked from network); 26 Jun 2012 15:41:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13228927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:41:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 16:41:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjXtd-0008AL-M5; Tue, 26 Jun 2012 15:41:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjXtd-000548-Kk;
	Tue, 26 Jun 2012 16:41:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.55349.605914.829151@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 16:41:41 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340365521.26083.97.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
	<1340365521.26083.97.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce
 prohibition on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 21/21] libxl: DO NOT APPLY enforce prohibition on internal"):
> On Fri, 2012-06-15 at 12:54 +0100, Ian Jackson wrote:
> > DO NOT APPLY THIS PATCH.
> > It contains -Wno-error.  Without that it would break the build.
> 
> I'm happy with the shape of this patch, and apart from the above caveat
> I'd be happy to Ack it, assuming it were preceded by fixes to those
> issues.
> 
> I fear slightly that we will be continually forgetting to add the tag
> during review. Is there a way we could augment with run time checking?
> Perhaps LIBXL__INIT_EGC can tell if a CTX is not "outer" somehow?

No, I think it can't without doing a lot of very tiresome things at
runtime with thread-local variables.

It would be possible via a tangle of #defines to arrange that the
_definition_ of such a function would have to have a weird type:

So you would do:

   /* libxl.h */

   int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk,
                               const libxl_asyncop_how *ao_how)
                               LIBXL_EXTERNAL_CALLERS_ONLY;

   /* libxl.c */

   int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                                libxl_device_disk *disk,
                                MAGIC_SPEEDBUMP_MACRO_TYPE *ao_how)
   {

This would stop you from accidentally writing an entirely new function
which took an ao_how, and just c&p'ing its declaration into libxl.h.
But there would still be nothing stopping you simply forgetting to add
the LIBXL_EXTERNAL_CALLERS_ONLY to the declaration.  That doesn't seem
worthwhile.


The only other thing would be to write a small Perl script to check
for obvious abuses.

[a bit later]

How about this:

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index c238ac0..1c8b62b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -74,7 +74,8 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
-	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h \
+        libxl.api-ok
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
@@ -113,6 +114,15 @@ $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 genpath-target = $(call buildmakevars2file,_paths.h.tmp)
 $(eval $(genpath-target))
 
+libxl.api-ok: check-libxl-api-rules libxl.api-for-check
+	perl $^
+
+%.api-for-check: %.h
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
+		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
+		>$@.new
+	$(call move-if-changed,$@.new,$@)
+
 _paths.h: genpath
 	sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" $@.tmp >$@.2.tmp
 	rm -f $@.tmp
@@ -200,7 +210,7 @@ install: all
 .PHONY: clean
 clean:
 	$(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS)
-	$(RM) -f _*.c *.pyc _paths.*.tmp
+	$(RM) -f _*.c *.pyc _paths.*.tmp *.api-for-check
 	$(RM) -f testidl.c.new testidl.c
 #	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
 
diff --git a/tools/libxl/check-libxl-api-rules b/tools/libxl/check-libxl-api-rules
new file mode 100755
index 0000000..e056573
--- /dev/null
+++ b/tools/libxl/check-libxl-api-rules
@@ -0,0 +1,15 @@
+#!/usr/bin/perl -w
+use strict;
+our $needed=0;
+while (<>) {
+      if (m/libxl_asyncop_how[^;]/) {
+         $needed=1;
+      }      
+      if (m/LIBXL_EXTERNAL_CALLERS_ONLY/) {
+          $needed=0;
+      }
+      next unless $needed;
+      if (m/\;/) {
+          die "$ARGV:$.:missing LIBXL_EXTERNAL_CALLERS_ONLY";
+      }
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:42:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjXtn-00061m-Mg; Tue, 26 Jun 2012 15:41:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjXtm-00061O-Nm
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:41:50 +0000
Received: from [193.109.254.147:57014] by server-8.bemta-14.messagelabs.com id
	61/47-30743-D38D9EF4; Tue, 26 Jun 2012 15:41:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340725302!1782035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4934 invoked from network); 26 Jun 2012 15:41:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13228927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:41:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 16:41:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjXtd-0008AL-M5; Tue, 26 Jun 2012 15:41:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjXtd-000548-Kk;
	Tue, 26 Jun 2012 16:41:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.55349.605914.829151@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 16:41:41 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340365521.26083.97.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-22-git-send-email-ian.jackson@eu.citrix.com>
	<1340365521.26083.97.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce
 prohibition on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 21/21] libxl: DO NOT APPLY enforce prohibition on internal"):
> On Fri, 2012-06-15 at 12:54 +0100, Ian Jackson wrote:
> > DO NOT APPLY THIS PATCH.
> > It contains -Wno-error.  Without that it would break the build.
> 
> I'm happy with the shape of this patch, and apart from the above caveat
> I'd be happy to Ack it, assuming it were preceded by fixes to those
> issues.
> 
> I fear slightly that we will be continually forgetting to add the tag
> during review. Is there a way we could augment with run time checking?
> Perhaps LIBXL__INIT_EGC can tell if a CTX is not "outer" somehow?

No, I think it can't without doing a lot of very tiresome things at
runtime with thread-local variables.

It would be possible via a tangle of #defines to arrange that the
_definition_ of such a function would have to have a weird type:

So you would do:

   /* libxl.h */

   int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk,
                               const libxl_asyncop_how *ao_how)
                               LIBXL_EXTERNAL_CALLERS_ONLY;

   /* libxl.c */

   int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                                libxl_device_disk *disk,
                                MAGIC_SPEEDBUMP_MACRO_TYPE *ao_how)
   {

This would stop you from accidentally writing an entirely new function
which took an ao_how, and just c&p'ing its declaration into libxl.h.
But there would still be nothing stopping you simply forgetting to add
the LIBXL_EXTERNAL_CALLERS_ONLY to the declaration.  That doesn't seem
worthwhile.


The only other thing would be to write a small Perl script to check
for obvious abuses.

[a bit later]

How about this:

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index c238ac0..1c8b62b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -74,7 +74,8 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
-	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h \
+        libxl.api-ok
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
@@ -113,6 +114,15 @@ $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 genpath-target = $(call buildmakevars2file,_paths.h.tmp)
 $(eval $(genpath-target))
 
+libxl.api-ok: check-libxl-api-rules libxl.api-for-check
+	perl $^
+
+%.api-for-check: %.h
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
+		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
+		>$@.new
+	$(call move-if-changed,$@.new,$@)
+
 _paths.h: genpath
 	sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" $@.tmp >$@.2.tmp
 	rm -f $@.tmp
@@ -200,7 +210,7 @@ install: all
 .PHONY: clean
 clean:
 	$(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS)
-	$(RM) -f _*.c *.pyc _paths.*.tmp
+	$(RM) -f _*.c *.pyc _paths.*.tmp *.api-for-check
 	$(RM) -f testidl.c.new testidl.c
 #	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
 
diff --git a/tools/libxl/check-libxl-api-rules b/tools/libxl/check-libxl-api-rules
new file mode 100755
index 0000000..e056573
--- /dev/null
+++ b/tools/libxl/check-libxl-api-rules
@@ -0,0 +1,15 @@
+#!/usr/bin/perl -w
+use strict;
+our $needed=0;
+while (<>) {
+      if (m/libxl_asyncop_how[^;]/) {
+         $needed=1;
+      }      
+      if (m/LIBXL_EXTERNAL_CALLERS_ONLY/) {
+          $needed=0;
+      }
+      next unless $needed;
+      if (m/\;/) {
+          die "$ARGV:$.:missing LIBXL_EXTERNAL_CALLERS_ONLY";
+      }
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:53:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:53: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 1SjY51-0006Z7-J1; Tue, 26 Jun 2012 15:53: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 1SjY50-0006Yx-4K
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:53:26 +0000
Received: from [85.158.138.51:60445] by server-3.bemta-3.messagelabs.com id
	4F/44-26490-5FAD9EF4; Tue, 26 Jun 2012 15:53:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340726004!21478523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12831 invoked from network); 26 Jun 2012 15:53:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:53:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:53:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 16:53:14 +0100
Message-ID: <1340725992.3832.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Date: Tue, 26 Jun 2012 16:53:12 +0100
In-Reply-To: <20120621122022.GO21124@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<20120621122022.GO21124@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 13:20 +0100, Daniel P. Berrange wrote:
> On Thu, Jun 21, 2012 at 12:49:24PM +0100, Ian Campbell wrote:
> > I wonder if there were any followup fixes or changes, especially wrt to
> > your point 1 above (the lack of a timeout now) requiring xend (or now
> > libxl) changes?
> 
> Removing any kind of timeout was in fact the point of this change.
> We do not want hotplug scripts stealing each others locks, or
> timing out, because the timeouts cause alot of problems when
> launching guests on a highly loaded machine where execution time
> can be alot longer than a timeout setting may expect.

Agreed.

What I meant was if there was any code in xend which had inadvertently
come to rely on the existence of the timeout which needed fixing. I'd
guess not -- it'd be a pretty strange pattern...

> I expect you can't see the original BZ ticket quoted, since it
> has customer information in it.  Here is my description of
> what the problem we weere solving was:
> 
> [quote]
> In the normal case of a single domain booting with one disk, the disk hotplug
> script will fire once. In this case taking out the lock will never cause a sleep
> because there's no other concurrent invocations. If a domain has 4 disks
> configured, then the hotplug script will fire 4 times, all 4 invocations at
> pretty much the same time. If there is even a little load on the system, the
> locking function in the shell script will sleep for a few seconds - as many as 5
> seconds, or potentially even time out & fail completely.
> 
> If say 4 or even more domains each with 4 disks start up at once, that's 16
> invocations of the hotplug script running at once. There will be alot of sleep's
> done & because of the very coarse 1 second granularity the delay can add up
> significantly. 
> 
> The change to using flock() removes the arbitrary 1 second sleep, so the very
> instant once hotplug script finishes, another can start & there is no repeated
> attempts & failures to lock which would add more delay.
> [/quote]

Thanks, this description makes sense. I'd be inclined to use it verbatim
as the commit message.

> Usually it was our policy to send all these kind of patches upstream,
> so I'm not really sure why this was not already merged. Possibly I
> forgot to submit it, or maybe it was rejected - I honestly can't
> remember.
> 
> Below is the original patch I wrote, to which I apply:
> 
>   Signed-off-by: Daniel P. Berrange.

Cheers. By my analysis the result is that the claim_lock(),
release_lock() and _setlockfd() functions (i.e. all the actual code) are
identical to those in the patch which Zhigang sent (the differences are
in the removed code, which I presume has changed since you wrote the
original patch).

Therefore I think it is appropriate to include your S-o-b on the new
patch -- assuming you are OK with that?

Also the patch is:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 15:53:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 15:53: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 1SjY51-0006Z7-J1; Tue, 26 Jun 2012 15:53: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 1SjY50-0006Yx-4K
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 15:53:26 +0000
Received: from [85.158.138.51:60445] by server-3.bemta-3.messagelabs.com id
	4F/44-26490-5FAD9EF4; Tue, 26 Jun 2012 15:53:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340726004!21478523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12831 invoked from network); 26 Jun 2012 15:53:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 15:53:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 15:53:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 16:53:14 +0100
Message-ID: <1340725992.3832.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Date: Tue, 26 Jun 2012 16:53:12 +0100
In-Reply-To: <20120621122022.GO21124@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<20120621122022.GO21124@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 13:20 +0100, Daniel P. Berrange wrote:
> On Thu, Jun 21, 2012 at 12:49:24PM +0100, Ian Campbell wrote:
> > I wonder if there were any followup fixes or changes, especially wrt to
> > your point 1 above (the lack of a timeout now) requiring xend (or now
> > libxl) changes?
> 
> Removing any kind of timeout was in fact the point of this change.
> We do not want hotplug scripts stealing each others locks, or
> timing out, because the timeouts cause alot of problems when
> launching guests on a highly loaded machine where execution time
> can be alot longer than a timeout setting may expect.

Agreed.

What I meant was if there was any code in xend which had inadvertently
come to rely on the existence of the timeout which needed fixing. I'd
guess not -- it'd be a pretty strange pattern...

> I expect you can't see the original BZ ticket quoted, since it
> has customer information in it.  Here is my description of
> what the problem we weere solving was:
> 
> [quote]
> In the normal case of a single domain booting with one disk, the disk hotplug
> script will fire once. In this case taking out the lock will never cause a sleep
> because there's no other concurrent invocations. If a domain has 4 disks
> configured, then the hotplug script will fire 4 times, all 4 invocations at
> pretty much the same time. If there is even a little load on the system, the
> locking function in the shell script will sleep for a few seconds - as many as 5
> seconds, or potentially even time out & fail completely.
> 
> If say 4 or even more domains each with 4 disks start up at once, that's 16
> invocations of the hotplug script running at once. There will be alot of sleep's
> done & because of the very coarse 1 second granularity the delay can add up
> significantly. 
> 
> The change to using flock() removes the arbitrary 1 second sleep, so the very
> instant once hotplug script finishes, another can start & there is no repeated
> attempts & failures to lock which would add more delay.
> [/quote]

Thanks, this description makes sense. I'd be inclined to use it verbatim
as the commit message.

> Usually it was our policy to send all these kind of patches upstream,
> so I'm not really sure why this was not already merged. Possibly I
> forgot to submit it, or maybe it was rejected - I honestly can't
> remember.
> 
> Below is the original patch I wrote, to which I apply:
> 
>   Signed-off-by: Daniel P. Berrange.

Cheers. By my analysis the result is that the claim_lock(),
release_lock() and _setlockfd() functions (i.e. all the actual code) are
identical to those in the patch which Zhigang sent (the differences are
in the removed code, which I presume has changed since you wrote the
original patch).

Therefore I think it is appropriate to include your S-o-b on the new
patch -- assuming you are OK with that?

Also the patch is:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYC7-0007Be-Gh; Tue, 26 Jun 2012 16:00: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 1SjYC6-0007BW-JE
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:00:46 +0000
Received: from [193.109.254.147:29920] by server-6.bemta-14.messagelabs.com id
	8F/B4-08993-DACD9EF4; Tue, 26 Jun 2012 16:00:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340726445!1833663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18368 invoked from network); 26 Jun 2012 16:00:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:00:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:00:22 +0100
Message-ID: <1340726421.3832.160.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 26 Jun 2012 17:00:21 +0100
In-Reply-To: <1340268784.21872.15.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<6c32fcbbd4896a55b73e.1339779869@Solace>
	<1340268784.21872.15.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
 GCREALLOC_ARRAY 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 Thu, 2012-06-21 at 09:53 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > Causing a build failure when trying to use it:
> > 
> > xxx: error: expected ';' before ')' token
> > xxx: error: expected statement before ')' token
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

This bugfix was mostly independent from the rest of the series, so I've
committed it.

> 
> > 
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
> >  #define GCREALLOC_ARRAY(var, nmemb)                                     \
> >      (assert(nmemb > 0),                                                 \
> >       assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
> > -     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
> > +     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
> >  
> > 
> >  /*
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 26 16:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYC7-0007Be-Gh; Tue, 26 Jun 2012 16:00: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 1SjYC6-0007BW-JE
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:00:46 +0000
Received: from [193.109.254.147:29920] by server-6.bemta-14.messagelabs.com id
	8F/B4-08993-DACD9EF4; Tue, 26 Jun 2012 16:00:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340726445!1833663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18368 invoked from network); 26 Jun 2012 16:00:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:00:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:00:22 +0100
Message-ID: <1340726421.3832.160.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 26 Jun 2012 17:00:21 +0100
In-Reply-To: <1340268784.21872.15.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<6c32fcbbd4896a55b73e.1339779869@Solace>
	<1340268784.21872.15.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
 GCREALLOC_ARRAY 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 Thu, 2012-06-21 at 09:53 +0100, Ian Campbell wrote:
> On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > Causing a build failure when trying to use it:
> > 
> > xxx: error: expected ';' before ')' token
> > xxx: error: expected statement before ')' token
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

This bugfix was mostly independent from the rest of the series, so I've
committed it.

> 
> > 
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -1972,7 +1972,7 @@ struct libxl__domain_create_state {
> >  #define GCREALLOC_ARRAY(var, nmemb)                                     \
> >      (assert(nmemb > 0),                                                 \
> >       assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
> > -     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
> > +     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var))))
> >  
> > 
> >  /*
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 26 16:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYCV-0007D5-CK; Tue, 26 Jun 2012 16:01:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SjYCS-0007Cs-Ut
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:01:09 +0000
Received: from [85.158.139.83:52507] by server-1.bemta-5.messagelabs.com id
	99/BF-19721-4CCD9EF4; Tue, 26 Jun 2012 16:01:08 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340726466!18356748!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 793 invoked from network); 26 Jun 2012 16:01:07 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:01:07 -0000
Received: by wibhq4 with SMTP id hq4so56243wib.14
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 09:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=mIwdz0dBCf4IUY2rPo4eeWb/a/5TfaG4wia4F2tKO2M=;
	b=OSPWRcwCyT4MRfwarqTxFK7AKJy2hy1a+tYzCus9BUjUJYOCXv4C9IFSDiGHcaaEQF
	Hicp4m1l/jHI3omiu0QgB2EcUQ6+hXwfkwtbHz62EhwfFF97s70arla79WQB5sWauUOH
	GxbxD5pa19HnReev/9i9wnc4NYHHW24c7Pe1LkJo2JCbzu5+zGabBkvAGTf3s8SmWBcA
	iz+3THj2EO/6I44brM5VBKZDWHGRv5NxQH0jUl79wVRtW+RemcjD/vOMtVHeqv6oq2td
	OxaToMuWNOdg0BYt6BBhkDW+dDmXqqVVchUOPjikavezKiqyQ+nL+R6bgrXAfbU4hdxx
	PoNg==
Received: by 10.216.214.155 with SMTP id c27mr8815128wep.116.1340726466516;
	Tue, 26 Jun 2012 09:01:06 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-88.sn1.eutelia.it. [62.94.182.88])
	by mx.google.com with ESMTPS id eb8sm4843916wib.11.2012.06.26.09.01.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 26 Jun 2012 09:01:05 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e764d52618f736bdc58aa858a828f4f7a6aee5d9
Message-Id: <e764d52618f736bdc58a.1340726463@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 26 Jun 2012 18:01:03 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v2] libxl: document the memory ownership of some
	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

Specifying they allocate dynamic memory that needs to be explicitly freed.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Changes from v1:
 * Functions are gathered together under a unique comment describing
   them all.
 * nr_THING output parameter renamed nr_THING_out.

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -508,7 +508,7 @@ static void xcinfo2xlinfo(const xc_domai
     xlinfo->cpupool = xcinfo->cpupool;
 }
 
-libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain)
+libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
 {
     libxl_dominfo *ptr;
     int i, ret;
@@ -531,7 +531,7 @@ libxl_dominfo * libxl_list_domain(libxl_
     for (i = 0; i < ret; i++) {
         xcinfo2xlinfo(&info[i], &ptr[i]);
     }
-    *nb_domain = ret;
+    *nb_domain_out = ret;
     return ptr;
 }
 
@@ -589,7 +589,7 @@ int libxl_cpupool_info(libxl_ctx *ctx,
     return rc;
 }
 
-libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool)
+libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool_out)
 {
     GC_INIT(ctx);
     libxl_cpupoolinfo info, *ptr, *tmp;
@@ -613,14 +613,15 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         poolid = info.poolid + 1;
     }
 
-    *nb_pool = i;
+    *nb_pool_out = i;
 out:
     GC_FREE;
     return ptr;
 }
 
-/* this API call only list VM running on this host. a VM can be an aggregate of multiple domains. */
-libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
+/* this API call only list VM running on this host. A VM can
+ * be an aggregate of multiple domains. */
+libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
     int index, i, ret;
@@ -644,7 +645,7 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
 
         index++;
     }
-    *nb_vm = index;
+    *nb_vm_out = index;
     return ptr;
 }
 
@@ -3161,7 +3162,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
-libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
 {
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
@@ -3219,7 +3220,7 @@ fail:
     xc_hypercall_buffer_free(ctx->xch, nodemap);
 
     if (ret)
-        *nr = max_cpus;
+        *nb_cpu_out = max_cpus;
     return ret;
 }
 
@@ -3270,7 +3271,7 @@ const libxl_version_info* libxl_get_vers
 }
 
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
-                                       int *nb_vcpu, int *nrcpus)
+                                       int *nb_vcpu, int *nr_vcpus_out)
 {
     libxl_vcpuinfo *ptr, *ret;
     xc_domaininfo_t domaininfo;
@@ -3280,7 +3281,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting infolist");
         return NULL;
     }
-    *nrcpus = libxl_get_max_cpus(ctx);
+    *nr_vcpus_out = libxl_get_max_cpus(ctx);
     ret = ptr = calloc(domaininfo.max_vcpu_id + 1, sizeof (libxl_vcpuinfo));
     if (!ptr) {
         return NULL;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -585,12 +585,28 @@ int libxl_primary_console_get_tty(libxl_
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);
-libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
-void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
-libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
-void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr);
-libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
-void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
+
+/* These functions each return (on success) an array of elements,
+ * and the length via the int* out parameter.  These arrays and
+ * their contents come from malloc, and must be freed with the
+ * corresponding libxl_THING_list_free function.
+ */
+libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain_out);
+void libxl_dominfo_list_free(libxl_dominfo *list, int nb_domain);
+
+libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
+void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nb_pool);
+
+libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out);
+void libxl_vminfo_list_free(libxl_vminfo *list, int nb_vm);
+
+#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out);
+void libxl_cputopology_list_free(libxl_cputopology *, int nb_cpu);
+
+libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
+                                int *nb_vcpu, int *nr_vcpus_out);
+void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr_vcpus);
 
 /*
  * Devices
@@ -766,12 +782,6 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
-#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
-libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
-void libxl_cputopology_list_free(libxl_cputopology *, int nr);
-libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
-                                       int *nb_vcpu, int *nrcpus);
-void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
                            libxl_cpumap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:01:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYCV-0007D5-CK; Tue, 26 Jun 2012 16:01:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1SjYCS-0007Cs-Ut
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:01:09 +0000
Received: from [85.158.139.83:52507] by server-1.bemta-5.messagelabs.com id
	99/BF-19721-4CCD9EF4; Tue, 26 Jun 2012 16:01:08 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340726466!18356748!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 793 invoked from network); 26 Jun 2012 16:01:07 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:01:07 -0000
Received: by wibhq4 with SMTP id hq4so56243wib.14
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 09:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=mIwdz0dBCf4IUY2rPo4eeWb/a/5TfaG4wia4F2tKO2M=;
	b=OSPWRcwCyT4MRfwarqTxFK7AKJy2hy1a+tYzCus9BUjUJYOCXv4C9IFSDiGHcaaEQF
	Hicp4m1l/jHI3omiu0QgB2EcUQ6+hXwfkwtbHz62EhwfFF97s70arla79WQB5sWauUOH
	GxbxD5pa19HnReev/9i9wnc4NYHHW24c7Pe1LkJo2JCbzu5+zGabBkvAGTf3s8SmWBcA
	iz+3THj2EO/6I44brM5VBKZDWHGRv5NxQH0jUl79wVRtW+RemcjD/vOMtVHeqv6oq2td
	OxaToMuWNOdg0BYt6BBhkDW+dDmXqqVVchUOPjikavezKiqyQ+nL+R6bgrXAfbU4hdxx
	PoNg==
Received: by 10.216.214.155 with SMTP id c27mr8815128wep.116.1340726466516;
	Tue, 26 Jun 2012 09:01:06 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-88.sn1.eutelia.it. [62.94.182.88])
	by mx.google.com with ESMTPS id eb8sm4843916wib.11.2012.06.26.09.01.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 26 Jun 2012 09:01:05 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: e764d52618f736bdc58aa858a828f4f7a6aee5d9
Message-Id: <e764d52618f736bdc58a.1340726463@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 26 Jun 2012 18:01:03 +0200
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v2] libxl: document the memory ownership of some
	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

Specifying they allocate dynamic memory that needs to be explicitly freed.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Changes from v1:
 * Functions are gathered together under a unique comment describing
   them all.
 * nr_THING output parameter renamed nr_THING_out.

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -508,7 +508,7 @@ static void xcinfo2xlinfo(const xc_domai
     xlinfo->cpupool = xcinfo->cpupool;
 }
 
-libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain)
+libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain_out)
 {
     libxl_dominfo *ptr;
     int i, ret;
@@ -531,7 +531,7 @@ libxl_dominfo * libxl_list_domain(libxl_
     for (i = 0; i < ret; i++) {
         xcinfo2xlinfo(&info[i], &ptr[i]);
     }
-    *nb_domain = ret;
+    *nb_domain_out = ret;
     return ptr;
 }
 
@@ -589,7 +589,7 @@ int libxl_cpupool_info(libxl_ctx *ctx,
     return rc;
 }
 
-libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool)
+libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool_out)
 {
     GC_INIT(ctx);
     libxl_cpupoolinfo info, *ptr, *tmp;
@@ -613,14 +613,15 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         poolid = info.poolid + 1;
     }
 
-    *nb_pool = i;
+    *nb_pool_out = i;
 out:
     GC_FREE;
     return ptr;
 }
 
-/* this API call only list VM running on this host. a VM can be an aggregate of multiple domains. */
-libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
+/* this API call only list VM running on this host. A VM can
+ * be an aggregate of multiple domains. */
+libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
     int index, i, ret;
@@ -644,7 +645,7 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
 
         index++;
     }
-    *nb_vm = index;
+    *nb_vm_out = index;
     return ptr;
 }
 
@@ -3161,7 +3162,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
-libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
 {
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
@@ -3219,7 +3220,7 @@ fail:
     xc_hypercall_buffer_free(ctx->xch, nodemap);
 
     if (ret)
-        *nr = max_cpus;
+        *nb_cpu_out = max_cpus;
     return ret;
 }
 
@@ -3270,7 +3271,7 @@ const libxl_version_info* libxl_get_vers
 }
 
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
-                                       int *nb_vcpu, int *nrcpus)
+                                       int *nb_vcpu, int *nr_vcpus_out)
 {
     libxl_vcpuinfo *ptr, *ret;
     xc_domaininfo_t domaininfo;
@@ -3280,7 +3281,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting infolist");
         return NULL;
     }
-    *nrcpus = libxl_get_max_cpus(ctx);
+    *nr_vcpus_out = libxl_get_max_cpus(ctx);
     ret = ptr = calloc(domaininfo.max_vcpu_id + 1, sizeof (libxl_vcpuinfo));
     if (!ptr) {
         return NULL;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -585,12 +585,28 @@ int libxl_primary_console_get_tty(libxl_
 /* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);
-libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
-void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
-libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
-void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nr);
-libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
-void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
+
+/* These functions each return (on success) an array of elements,
+ * and the length via the int* out parameter.  These arrays and
+ * their contents come from malloc, and must be freed with the
+ * corresponding libxl_THING_list_free function.
+ */
+libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain_out);
+void libxl_dominfo_list_free(libxl_dominfo *list, int nb_domain);
+
+libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
+void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nb_pool);
+
+libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out);
+void libxl_vminfo_list_free(libxl_vminfo *list, int nb_vm);
+
+#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out);
+void libxl_cputopology_list_free(libxl_cputopology *, int nb_cpu);
+
+libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
+                                int *nb_vcpu, int *nr_vcpus_out);
+void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr_vcpus);
 
 /*
  * Devices
@@ -766,12 +782,6 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
-#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
-libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
-void libxl_cputopology_list_free(libxl_cputopology *, int nr);
-libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
-                                       int *nb_vcpu, int *nrcpus);
-void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
                            libxl_cpumap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYHT-0007Ts-3Q; Tue, 26 Jun 2012 16:06: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 1SjYHR-0007Tk-CD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:06:17 +0000
Received: from [85.158.139.83:56191] by server-7.bemta-5.messagelabs.com id
	07/1B-28276-8FDD9EF4; Tue, 26 Jun 2012 16:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340726775!28928932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32455 invoked from network); 26 Jun 2012 16:06:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:06:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:06:15 +0100
Message-ID: <1340726773.3832.162.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 26 Jun 2012 17:06:13 +0100
In-Reply-To: <e764d52618f736bdc58a.1340726463@Solace>
References: <e764d52618f736bdc58a.1340726463@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: document the memory ownership of
 some functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 17:01 +0100, Dario Faggioli wrote:
> Specifying they allocate dynamic memory that needs to be explicitly freed.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYHT-0007Ts-3Q; Tue, 26 Jun 2012 16:06: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 1SjYHR-0007Tk-CD
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:06:17 +0000
Received: from [85.158.139.83:56191] by server-7.bemta-5.messagelabs.com id
	07/1B-28276-8FDD9EF4; Tue, 26 Jun 2012 16:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340726775!28928932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32455 invoked from network); 26 Jun 2012 16:06:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:06:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:06:15 +0100
Message-ID: <1340726773.3832.162.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 26 Jun 2012 17:06:13 +0100
In-Reply-To: <e764d52618f736bdc58a.1340726463@Solace>
References: <e764d52618f736bdc58a.1340726463@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: document the memory ownership of
 some functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 17:01 +0100, Dario Faggioli wrote:
> Specifying they allocate dynamic memory that needs to be explicitly freed.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:14:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:14: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 1SjYPX-0007i0-8y; Tue, 26 Jun 2012 16:14:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <berrange@redhat.com>) id 1SjYPV-0007hv-Bp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:14:37 +0000
Received: from [85.158.143.99:64145] by server-1.bemta-4.messagelabs.com id
	2D/98-24392-CEFD9EF4; Tue, 26 Jun 2012 16:14:36 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340727275!22854382!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyMzg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29956 invoked from network); 26 Jun 2012 16:14:35 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	26 Jun 2012 16:14:35 -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 q5QGESAg025817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Jun 2012 12:14:28 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q5QGEO2L021423
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 26 Jun 2012 12:14:26 -0400
Date: Tue, 26 Jun 2012 17:14:23 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120626161423.GV14451@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<20120621122022.GO21124@redhat.com>
	<1340725992.3832.159.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340725992.3832.159.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Andrew Jones <drjones@redhat.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" <berrange@redhat.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 Tue, Jun 26, 2012 at 04:53:12PM +0100, Ian Campbell wrote:
> On Thu, 2012-06-21 at 13:20 +0100, Daniel P. Berrange wrote:
> > On Thu, Jun 21, 2012 at 12:49:24PM +0100, Ian Campbell wrote:
> > > I wonder if there were any followup fixes or changes, especially wrt to
> > > your point 1 above (the lack of a timeout now) requiring xend (or now
> > > libxl) changes?
> > 
> > Removing any kind of timeout was in fact the point of this change.
> > We do not want hotplug scripts stealing each others locks, or
> > timing out, because the timeouts cause alot of problems when
> > launching guests on a highly loaded machine where execution time
> > can be alot longer than a timeout setting may expect.
> 
> Agreed.
> 
> What I meant was if there was any code in xend which had inadvertently
> come to rely on the existence of the timeout which needed fixing. I'd
> guess not -- it'd be a pretty strange pattern...

It has been a while, but I don't recall any issues in the Xend
layer in this respect.

> > I expect you can't see the original BZ ticket quoted, since it
> > has customer information in it.  Here is my description of
> > what the problem we weere solving was:
> > 
> > [quote]
> > In the normal case of a single domain booting with one disk, the disk hotplug
> > script will fire once. In this case taking out the lock will never cause a sleep
> > because there's no other concurrent invocations. If a domain has 4 disks
> > configured, then the hotplug script will fire 4 times, all 4 invocations at
> > pretty much the same time. If there is even a little load on the system, the
> > locking function in the shell script will sleep for a few seconds - as many as 5
> > seconds, or potentially even time out & fail completely.
> > 
> > If say 4 or even more domains each with 4 disks start up at once, that's 16
> > invocations of the hotplug script running at once. There will be alot of sleep's
> > done & because of the very coarse 1 second granularity the delay can add up
> > significantly. 
> > 
> > The change to using flock() removes the arbitrary 1 second sleep, so the very
> > instant once hotplug script finishes, another can start & there is no repeated
> > attempts & failures to lock which would add more delay.
> > [/quote]
> 
> Thanks, this description makes sense. I'd be inclined to use it verbatim
> as the commit message.
> 
> > Usually it was our policy to send all these kind of patches upstream,
> > so I'm not really sure why this was not already merged. Possibly I
> > forgot to submit it, or maybe it was rejected - I honestly can't
> > remember.
> > 
> > Below is the original patch I wrote, to which I apply:
> > 
> >   Signed-off-by: Daniel P. Berrange.
> 
> Cheers. By my analysis the result is that the claim_lock(),
> release_lock() and _setlockfd() functions (i.e. all the actual code) are
> identical to those in the patch which Zhigang sent (the differences are
> in the removed code, which I presume has changed since you wrote the
> original patch).
> 
> Therefore I think it is appropriate to include your S-o-b on the new
> patch -- assuming you are OK with that?

Yes, that's fine with me

> 
> Also the patch is:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Ian.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:14:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:14: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 1SjYPX-0007i0-8y; Tue, 26 Jun 2012 16:14:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <berrange@redhat.com>) id 1SjYPV-0007hv-Bp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:14:37 +0000
Received: from [85.158.143.99:64145] by server-1.bemta-4.messagelabs.com id
	2D/98-24392-CEFD9EF4; Tue, 26 Jun 2012 16:14:36 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340727275!22854382!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyMzg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29956 invoked from network); 26 Jun 2012 16:14:35 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	26 Jun 2012 16:14:35 -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 q5QGESAg025817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Jun 2012 12:14:28 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q5QGEO2L021423
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 26 Jun 2012 12:14:26 -0400
Date: Tue, 26 Jun 2012 17:14:23 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120626161423.GV14451@redhat.com>
References: <650b03f412143c3057ab.1339608555@zhigang.us.oracle.com>
	<1340206463.4906.72.camel@zakaz.uk.xensource.com>
	<4FE20E27.8000108@oracle.com>
	<1340278976.21872.114.camel@zakaz.uk.xensource.com>
	<1340279364.21872.118.camel@zakaz.uk.xensource.com>
	<20120621122022.GO21124@redhat.com>
	<1340725992.3832.159.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340725992.3832.159.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Andrew Jones <drjones@redhat.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: fix locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" <berrange@redhat.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 Tue, Jun 26, 2012 at 04:53:12PM +0100, Ian Campbell wrote:
> On Thu, 2012-06-21 at 13:20 +0100, Daniel P. Berrange wrote:
> > On Thu, Jun 21, 2012 at 12:49:24PM +0100, Ian Campbell wrote:
> > > I wonder if there were any followup fixes or changes, especially wrt to
> > > your point 1 above (the lack of a timeout now) requiring xend (or now
> > > libxl) changes?
> > 
> > Removing any kind of timeout was in fact the point of this change.
> > We do not want hotplug scripts stealing each others locks, or
> > timing out, because the timeouts cause alot of problems when
> > launching guests on a highly loaded machine where execution time
> > can be alot longer than a timeout setting may expect.
> 
> Agreed.
> 
> What I meant was if there was any code in xend which had inadvertently
> come to rely on the existence of the timeout which needed fixing. I'd
> guess not -- it'd be a pretty strange pattern...

It has been a while, but I don't recall any issues in the Xend
layer in this respect.

> > I expect you can't see the original BZ ticket quoted, since it
> > has customer information in it.  Here is my description of
> > what the problem we weere solving was:
> > 
> > [quote]
> > In the normal case of a single domain booting with one disk, the disk hotplug
> > script will fire once. In this case taking out the lock will never cause a sleep
> > because there's no other concurrent invocations. If a domain has 4 disks
> > configured, then the hotplug script will fire 4 times, all 4 invocations at
> > pretty much the same time. If there is even a little load on the system, the
> > locking function in the shell script will sleep for a few seconds - as many as 5
> > seconds, or potentially even time out & fail completely.
> > 
> > If say 4 or even more domains each with 4 disks start up at once, that's 16
> > invocations of the hotplug script running at once. There will be alot of sleep's
> > done & because of the very coarse 1 second granularity the delay can add up
> > significantly. 
> > 
> > The change to using flock() removes the arbitrary 1 second sleep, so the very
> > instant once hotplug script finishes, another can start & there is no repeated
> > attempts & failures to lock which would add more delay.
> > [/quote]
> 
> Thanks, this description makes sense. I'd be inclined to use it verbatim
> as the commit message.
> 
> > Usually it was our policy to send all these kind of patches upstream,
> > so I'm not really sure why this was not already merged. Possibly I
> > forgot to submit it, or maybe it was rejected - I honestly can't
> > remember.
> > 
> > Below is the original patch I wrote, to which I apply:
> > 
> >   Signed-off-by: Daniel P. Berrange.
> 
> Cheers. By my analysis the result is that the claim_lock(),
> release_lock() and _setlockfd() functions (i.e. all the actual code) are
> identical to those in the patch which Zhigang sent (the differences are
> in the removed code, which I presume has changed since you wrote the
> original patch).
> 
> Therefore I think it is appropriate to include your S-o-b on the new
> patch -- assuming you are OK with that?

Yes, that's fine with me

> 
> Also the patch is:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Ian.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:16:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjYRQ-0007mk-PO; Tue, 26 Jun 2012 16:16: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 1SjYRP-0007mc-NL
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:16:35 +0000
Received: from [85.158.143.35:28749] by server-2.bemta-4.messagelabs.com id
	D1/01-17938-360E9EF4; Tue, 26 Jun 2012 16:16:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340727391!6504788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18104 invoked from network); 26 Jun 2012 16:16:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:16:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:16:30 +0100
Message-ID: <1340727389.3832.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:16:29 +0100
In-Reply-To: <0dfe08c91739527eb454.1339593048@probook.site>
References: <patchbomb.1339593047@probook.site>
	<0dfe08c91739527eb454.1339593048@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTEzIGF0IDE0OjEwICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiAj
IEhHIGNoYW5nZXNldCBwYXRjaAo+ICMgVXNlciBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+
Cj4gIyBEYXRlIDEzMzk1OTMwMDAgLTcyMDAKPiAjIE5vZGUgSUQgMGRmZTA4YzkxNzM5NTI3ZWI0
NTRkNWU0OTU3NjM1Y2I4YjkwZTFlMQo+ICMgUGFyZW50ICBhNzBiMzVkZWIyYjU1OTJjYzFiMjM2
Mzg2MGYyMWJiMmM3MDQ5ODg1Cj4gdG9vbHMvY29uZmlndXJlLmFjOiBhZGQgdmVyc2lvbiBjaGVj
ayBmb3IgZ2xpYjIKPiAKPiB4ZW4tdW5zdGFibGUgZmFpbHMgdG8gYnVpbGQgaW4gYSBTTEVTMTBT
UDQgZW52aXJvbm1lbnQgc2luY2UgYSBsb25nIHRpbWUKPiBiZWNhdXNlIHRoZSBpbmNsdWRlZCB2
ZXJzaW9uIG9mIGdsaWIgaXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0aGUgcmVxdWlyZWQKPiBnbGli
IHZlcnNpb24uIEFjY29yZGluZyB0byB0aGUgZ2xpYiBkb2NzIHZlcnNpb24gMi4xMiBpbmNsdWRl
cyBiYXNlNjQKPiBzdXBwb3J0LCBidXQgU0xFUzEwIGlzIHNoaXBwZWQgd2l0aCBnbGliIDIuOC42
Ogo+IAo+IHFlbXUtdGltZXItY29tbW9uLm86IEluIGZ1bmN0aW9uIGBpbml0X2dldF9jbG9jayc6
Cj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJTEQveGVuLTQuMi4yNTQzMi9ub24tZGJnL3Rvb2xzL3Fl
bXUteGVuLWRpci9xZW11LXRpbWVyLWNvbW1vbi5jOjU3Ogo+IHVuZGVmaW5lZCByZWZlcmVuY2Ug
dG8gYGNsb2NrX2dldHRpbWUnCj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0
aW9uIGBxbXBfZ3Vlc3RfZmlsZV93cml0ZSc6Cj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6
MjQ5OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9kZWNvZGUnCj4gcWdhL2d1ZXN0
LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0aW9uIGBxbXBfZ3Vlc3RfZmlsZV9yZWFkJzoKPiBx
Z2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyMjQ6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdf
YmFzZTY0X2VuY29kZScKPiBjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+IG1h
a2VbM106ICoqKiBbcWVtdS1nYV0gRXJyb3IgMQo+IAo+IEFkZCBhIHZlcnNpb24gY2hlY2sgdG8g
dG9wbGV2ZWwgY29uZmlndXJlIHRvIHJlcXVpcmUgYXQgbGVhc3QgZ2xpYiAyLjEyLgo+IFRoaXMg
bWFrZXMgc3VyZSBjb25maWd1cmUgY2FuIGRldGVjdCB0aGUgY29uZGl0aW9uIGVhcmx5IGluc3Rl
YWQgb2YKPiBmYWlsaW5nIGxhdGVyIGluIHRoZSBtaWRkbGUgb2YgdG9vbHMgYnVpbGQgd2hlbiBx
ZW11LXVwc3RyZWFtIGVycm9ycwo+IG91dC4KPiAKPiBQbGVhc2UgcmVydW4gYXV0b2NvbmYgYWZ0
ZXIgYXBwbHlpbmcgdGhpcy4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBh
ZXBmbGUuZGU+Cj4gQWNrZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKQWNrZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cgo+
IAo+IGRpZmYgLXIgYTcwYjM1ZGViMmI1IC1yIDBkZmUwOGM5MTczOSB0b29scy9jb25maWd1cmUu
YWMKPiAtLS0gYS90b29scy9jb25maWd1cmUuYWMKPiArKysgYi90b29scy9jb25maWd1cmUuYWMK
PiBAQCAtMTE1LDcgKzExNSw3IEBAIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtCQ0NdLCBbYmNjXSkK
PiAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lBU0xdLCBbaWFzbF0pCj4gIEFYX0NIRUNLX1VVSUQK
PiAgQVhfQ0hFQ0tfQ1VSU0VTCj4gLVBLR19DSEVDS19NT0RVTEVTKGdsaWIsIGdsaWItMi4wKQo+
ICtQS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBbZ2xpYi0yLjAgPj0gMi4xMl0pCj4gIAo+ICAjIENo
ZWNrIGxpYnJhcnkgcGF0aAo+ICBBWF9ERUZBVUxUX0xJQgo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:16:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjYRQ-0007mk-PO; Tue, 26 Jun 2012 16:16: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 1SjYRP-0007mc-NL
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:16:35 +0000
Received: from [85.158.143.35:28749] by server-2.bemta-4.messagelabs.com id
	D1/01-17938-360E9EF4; Tue, 26 Jun 2012 16:16:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340727391!6504788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18104 invoked from network); 26 Jun 2012 16:16:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:16:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:16:30 +0100
Message-ID: <1340727389.3832.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:16:29 +0100
In-Reply-To: <0dfe08c91739527eb454.1339593048@probook.site>
References: <patchbomb.1339593047@probook.site>
	<0dfe08c91739527eb454.1339593048@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/configure.ac: add version
 check for glib2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTA2LTEzIGF0IDE0OjEwICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiAj
IEhHIGNoYW5nZXNldCBwYXRjaAo+ICMgVXNlciBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+
Cj4gIyBEYXRlIDEzMzk1OTMwMDAgLTcyMDAKPiAjIE5vZGUgSUQgMGRmZTA4YzkxNzM5NTI3ZWI0
NTRkNWU0OTU3NjM1Y2I4YjkwZTFlMQo+ICMgUGFyZW50ICBhNzBiMzVkZWIyYjU1OTJjYzFiMjM2
Mzg2MGYyMWJiMmM3MDQ5ODg1Cj4gdG9vbHMvY29uZmlndXJlLmFjOiBhZGQgdmVyc2lvbiBjaGVj
ayBmb3IgZ2xpYjIKPiAKPiB4ZW4tdW5zdGFibGUgZmFpbHMgdG8gYnVpbGQgaW4gYSBTTEVTMTBT
UDQgZW52aXJvbm1lbnQgc2luY2UgYSBsb25nIHRpbWUKPiBiZWNhdXNlIHRoZSBpbmNsdWRlZCB2
ZXJzaW9uIG9mIGdsaWIgaXMgc2xpZ2h0bHkgb2xkZXIgdGhhbiB0aGUgcmVxdWlyZWQKPiBnbGli
IHZlcnNpb24uIEFjY29yZGluZyB0byB0aGUgZ2xpYiBkb2NzIHZlcnNpb24gMi4xMiBpbmNsdWRl
cyBiYXNlNjQKPiBzdXBwb3J0LCBidXQgU0xFUzEwIGlzIHNoaXBwZWQgd2l0aCBnbGliIDIuOC42
Ogo+IAo+IHFlbXUtdGltZXItY29tbW9uLm86IEluIGZ1bmN0aW9uIGBpbml0X2dldF9jbG9jayc6
Cj4gL3Vzci9zcmMvcGFja2FnZXMvQlVJTEQveGVuLTQuMi4yNTQzMi9ub24tZGJnL3Rvb2xzL3Fl
bXUteGVuLWRpci9xZW11LXRpbWVyLWNvbW1vbi5jOjU3Ogo+IHVuZGVmaW5lZCByZWZlcmVuY2Ug
dG8gYGNsb2NrX2dldHRpbWUnCj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0
aW9uIGBxbXBfZ3Vlc3RfZmlsZV93cml0ZSc6Cj4gcWdhL2d1ZXN0LWFnZW50LWNvbW1hbmRzLmM6
MjQ5OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnX2Jhc2U2NF9kZWNvZGUnCj4gcWdhL2d1ZXN0
LWFnZW50LWNvbW1hbmRzLm86IEluIGZ1bmN0aW9uIGBxbXBfZ3Vlc3RfZmlsZV9yZWFkJzoKPiBx
Z2EvZ3Vlc3QtYWdlbnQtY29tbWFuZHMuYzoyMjQ6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdf
YmFzZTY0X2VuY29kZScKPiBjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cwo+IG1h
a2VbM106ICoqKiBbcWVtdS1nYV0gRXJyb3IgMQo+IAo+IEFkZCBhIHZlcnNpb24gY2hlY2sgdG8g
dG9wbGV2ZWwgY29uZmlndXJlIHRvIHJlcXVpcmUgYXQgbGVhc3QgZ2xpYiAyLjEyLgo+IFRoaXMg
bWFrZXMgc3VyZSBjb25maWd1cmUgY2FuIGRldGVjdCB0aGUgY29uZGl0aW9uIGVhcmx5IGluc3Rl
YWQgb2YKPiBmYWlsaW5nIGxhdGVyIGluIHRoZSBtaWRkbGUgb2YgdG9vbHMgYnVpbGQgd2hlbiBx
ZW11LXVwc3RyZWFtIGVycm9ycwo+IG91dC4KPiAKPiBQbGVhc2UgcmVydW4gYXV0b2NvbmYgYWZ0
ZXIgYXBwbHlpbmcgdGhpcy4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBh
ZXBmbGUuZGU+Cj4gQWNrZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKQWNrZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cgo+
IAo+IGRpZmYgLXIgYTcwYjM1ZGViMmI1IC1yIDBkZmUwOGM5MTczOSB0b29scy9jb25maWd1cmUu
YWMKPiAtLS0gYS90b29scy9jb25maWd1cmUuYWMKPiArKysgYi90b29scy9jb25maWd1cmUuYWMK
PiBAQCAtMTE1LDcgKzExNSw3IEBAIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtCQ0NdLCBbYmNjXSkK
PiAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lBU0xdLCBbaWFzbF0pCj4gIEFYX0NIRUNLX1VVSUQK
PiAgQVhfQ0hFQ0tfQ1VSU0VTCj4gLVBLR19DSEVDS19NT0RVTEVTKGdsaWIsIGdsaWItMi4wKQo+
ICtQS0dfQ0hFQ0tfTU9EVUxFUyhnbGliLCBbZ2xpYi0yLjAgPj0gMi4xMl0pCj4gIAo+ICAjIENo
ZWNrIGxpYnJhcnkgcGF0aAo+ICBBWF9ERUZBVUxUX0xJQgo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:17:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYRr-0007pJ-5v; Tue, 26 Jun 2012 16:17:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjYRp-0007p5-Ed
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:17:01 +0000
Received: from [85.158.143.99:17000] by server-1.bemta-4.messagelabs.com id
	A7/BB-24392-C70E9EF4; Tue, 26 Jun 2012 16:17:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340727420!25867149!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21783 invoked from network); 26 Jun 2012 16:17:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:17:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:16:59 +0100
Message-ID: <1340727418.3832.164.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:16:58 +0100
In-Reply-To: <59762b446ab4e6d9a851.1339593049@probook.site>
References: <patchbomb.1339593047@probook.site>
	<59762b446ab4e6d9a851.1339593049@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/m4: add AC_LANG_SOURCE to fix
 autoconf warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 14:10 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339593008 -7200
> # Node ID 59762b446ab4e6d9a851a91d1457c11f6c828d49
> # Parent  0dfe08c91739527eb454d5e4957635cb8b90e1e1
> tools/m4: add AC_LANG_SOURCE to fix autoconf warnings
> 
> I see these warnings with autoconf 2.68, add AC_LANG_SOURCE as suggested
> by upstream documentation.
> 
> ...
>  # bash autogen.sh
> configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
> configure.ac:141: the top level
> configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
> configure.ac:142: the top level
> configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
> configure.ac:141: the top level
> configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
> configure.ac:142: the top level
> 
> 
> Please rerun autoconf after applying this.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/pthread.m4
> --- a/tools/m4/pthread.m4
> +++ b/tools/m4/pthread.m4
> @@ -24,13 +24,13 @@ AC_DEFUN([AX_CHECK_PTHREAD],[
>          AX_PTHREAD_CV2VARS
>          AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
>          AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
> -        AC_LINK_IFELSE([
> +        AC_LINK_IFELSE([AC_LANG_SOURCE([
>  #include <pthread.h>
>  int main(void) {
>    pthread_atfork(0,0,0);
>    pthread_create(0,0,0,0);
>  }
> -],[],[ax_cv_pthread_flags=failed])
> +])],[],[ax_cv_pthread_flags=failed])
>          AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
>      ])
>      if test "x$ax_cv_pthread_flags" = xfailed; then
> diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/ptyfuncs.m4
> --- a/tools/m4/ptyfuncs.m4
> +++ b/tools/m4/ptyfuncs.m4
> @@ -9,7 +9,7 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [
>              fi
>              AX_SAVEVAR_SAVE(LIBS)
>              LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> -            AC_LINK_IFELSE([
> +            AC_LINK_IFELSE([AC_LANG_SOURCE([
>  #ifdef INCLUDE_LIBUTIL_H
>  #include INCLUDE_LIBUTIL_H
>  #endif
> @@ -17,7 +17,7 @@ int main(void) {
>    openpty(0,0,0,0,0);
>    login_tty(0);
>  }
> -],[
> +])],[
>                  break
>              ],[])
>              AX_SAVEVAR_RESTORE(LIBS)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 26 16:17:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYRr-0007pJ-5v; Tue, 26 Jun 2012 16:17:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjYRp-0007p5-Ed
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:17:01 +0000
Received: from [85.158.143.99:17000] by server-1.bemta-4.messagelabs.com id
	A7/BB-24392-C70E9EF4; Tue, 26 Jun 2012 16:17:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340727420!25867149!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21783 invoked from network); 26 Jun 2012 16:17:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:17:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:16:59 +0100
Message-ID: <1340727418.3832.164.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:16:58 +0100
In-Reply-To: <59762b446ab4e6d9a851.1339593049@probook.site>
References: <patchbomb.1339593047@probook.site>
	<59762b446ab4e6d9a851.1339593049@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/m4: add AC_LANG_SOURCE to fix
 autoconf warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 14:10 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339593008 -7200
> # Node ID 59762b446ab4e6d9a851a91d1457c11f6c828d49
> # Parent  0dfe08c91739527eb454d5e4957635cb8b90e1e1
> tools/m4: add AC_LANG_SOURCE to fix autoconf warnings
> 
> I see these warnings with autoconf 2.68, add AC_LANG_SOURCE as suggested
> by upstream documentation.
> 
> ...
>  # bash autogen.sh
> configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
> configure.ac:141: the top level
> configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
> configure.ac:142: the top level
> configure.ac:141: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/pthread.m4:21: AX_CHECK_PTHREAD is expanded from...
> configure.ac:141: the top level
> configure.ac:142: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> m4/ptyfuncs.m4:1: AX_CHECK_PTYFUNCS is expanded from...
> configure.ac:142: the top level
> 
> 
> Please rerun autoconf after applying this.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/pthread.m4
> --- a/tools/m4/pthread.m4
> +++ b/tools/m4/pthread.m4
> @@ -24,13 +24,13 @@ AC_DEFUN([AX_CHECK_PTHREAD],[
>          AX_PTHREAD_CV2VARS
>          AX_PTHREAD_VARS([AX_SAVEVAR_SAVE])
>          AX_PTHREAD_VARS([AX_PTHREAD_VAR_APPLY])
> -        AC_LINK_IFELSE([
> +        AC_LINK_IFELSE([AC_LANG_SOURCE([
>  #include <pthread.h>
>  int main(void) {
>    pthread_atfork(0,0,0);
>    pthread_create(0,0,0,0);
>  }
> -],[],[ax_cv_pthread_flags=failed])
> +])],[],[ax_cv_pthread_flags=failed])
>          AX_PTHREAD_VARS([AX_SAVEVAR_RESTORE])
>      ])
>      if test "x$ax_cv_pthread_flags" = xfailed; then
> diff -r 0dfe08c91739 -r 59762b446ab4 tools/m4/ptyfuncs.m4
> --- a/tools/m4/ptyfuncs.m4
> +++ b/tools/m4/ptyfuncs.m4
> @@ -9,7 +9,7 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [
>              fi
>              AX_SAVEVAR_SAVE(LIBS)
>              LIBS="$LIBS $ax_cv_ptyfuncs_libs"
> -            AC_LINK_IFELSE([
> +            AC_LINK_IFELSE([AC_LANG_SOURCE([
>  #ifdef INCLUDE_LIBUTIL_H
>  #include INCLUDE_LIBUTIL_H
>  #endif
> @@ -17,7 +17,7 @@ int main(void) {
>    openpty(0,0,0,0,0);
>    login_tty(0);
>  }
> -],[
> +])],[
>                  break
>              ],[])
>              AX_SAVEVAR_RESTORE(LIBS)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 26 16:17:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYSE-0007sg-JM; Tue, 26 Jun 2012 16:17:26 +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 1SjYSD-0007sO-3h
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:17:25 +0000
Received: from [193.109.254.147:8418] by server-3.bemta-14.messagelabs.com id
	9E/D5-08687-490E9EF4; Tue, 26 Jun 2012 16:17:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340727443!8645245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6876 invoked from network); 26 Jun 2012 16:17:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:17:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:17:23 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:17:23 +0100
Message-ID: <4FE9E091.2090001@citrix.com>
Date: Tue, 26 Jun 2012 17:17:21 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
In-Reply-To: <20452.22802.102071.107153@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
>> This patch converts libxl_device_nic_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>> we reached the desired xenbus state.
>>
>> Calls to libxl_device_nic_add have also been moved to occur after the
>> device model has been launched, so when hotplug scripts are called
>> from this functions the interfaces already exists.
>>
>> As usual, libxl_device_nic_add callers have been modified, and the
>> internal function libxl__device_disk_add has been used if the call was
>> inside an already running ao.
>
> This all looks reasonable to me.  But seeing this:
>
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index 5d34ed5..f7217aa 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -454,8 +454,8 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>>   #define libxl__device_disk_add(egc, domid, disk, aodev)                       \
>>           libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
>>
>> -#define DEFINE_DEVICES_ADD(type)                                              \
>> -    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
>> +#define DEFINE_DEVICES_ADD(type, name)                                        \
>> +    void libxl__add_##name##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
>>                                 libxl_domain_config *d_config,                  \
>>                                 libxl__ao_devices *aodevs,                      \
>>                                 libxl__devices_callback *callback)              \
>> @@ -469,12 +469,13 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>>                                                                                 \
>>           for (i = 0; i<  aodevs->size; i++) {                                  \
>>               aodevs->array[i].callback = libxl__ao_devices_callback;           \
>> -            libxl__device_##type##_add(egc, domid,&d_config->type##s[i],     \
>> +            libxl__device_##name##_add(egc, domid,&d_config->type##s[i],     \
>>                                          &aodevs->array[i]);                    \
>>           }                                                                     \
>>       }
>>
>> -DEFINE_DEVICES_ADD(disk)
>> +DEFINE_DEVICES_ADD(disk, disk)
>> +DEFINE_DEVICES_ADD(vif, nic)
>
> it seems to me that this is an anomaly which might be better fixed
> than worked around.
>
> Should we rename the functions libxl_*nic* or the structures *vif* ?
> Or should we rename both, to "net" perhaps ?

I think we should either rename the strucutres to nic also (because the 
also hold ioemu cards), or get rid of nic/vif an name everything net.

>
> In any case,
>
> 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 Jun 26 16:17:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYSE-0007sg-JM; Tue, 26 Jun 2012 16:17:26 +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 1SjYSD-0007sO-3h
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:17:25 +0000
Received: from [193.109.254.147:8418] by server-3.bemta-14.messagelabs.com id
	9E/D5-08687-490E9EF4; Tue, 26 Jun 2012 16:17:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340727443!8645245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6876 invoked from network); 26 Jun 2012 16:17:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:17:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:17:23 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:17:23 +0100
Message-ID: <4FE9E091.2090001@citrix.com>
Date: Tue, 26 Jun 2012 17:17:21 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
In-Reply-To: <20452.22802.102071.107153@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
>> This patch converts libxl_device_nic_add to an ao operation that
>> waits for device backend to reach state XenbusStateInitWait and then
>> marks the operation as completed. This is not really useful now, but
>> will be used by latter patches that will launch hotplug scripts after
>> we reached the desired xenbus state.
>>
>> Calls to libxl_device_nic_add have also been moved to occur after the
>> device model has been launched, so when hotplug scripts are called
>> from this functions the interfaces already exists.
>>
>> As usual, libxl_device_nic_add callers have been modified, and the
>> internal function libxl__device_disk_add has been used if the call was
>> inside an already running ao.
>
> This all looks reasonable to me.  But seeing this:
>
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index 5d34ed5..f7217aa 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -454,8 +454,8 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>>   #define libxl__device_disk_add(egc, domid, disk, aodev)                       \
>>           libxl__device_disk_add(egc, domid, XBT_NULL, disk, aodev)
>>
>> -#define DEFINE_DEVICES_ADD(type)                                              \
>> -    void libxl__add_##type##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
>> +#define DEFINE_DEVICES_ADD(type, name)                                        \
>> +    void libxl__add_##name##s(libxl__egc *egc, libxl__ao *ao, uint32_t domid, \
>>                                 libxl_domain_config *d_config,                  \
>>                                 libxl__ao_devices *aodevs,                      \
>>                                 libxl__devices_callback *callback)              \
>> @@ -469,12 +469,13 @@ void libxl__ao_devices_callback(libxl__egc *egc, libxl__ao_device *aodev)
>>                                                                                 \
>>           for (i = 0; i<  aodevs->size; i++) {                                  \
>>               aodevs->array[i].callback = libxl__ao_devices_callback;           \
>> -            libxl__device_##type##_add(egc, domid,&d_config->type##s[i],     \
>> +            libxl__device_##name##_add(egc, domid,&d_config->type##s[i],     \
>>                                          &aodevs->array[i]);                    \
>>           }                                                                     \
>>       }
>>
>> -DEFINE_DEVICES_ADD(disk)
>> +DEFINE_DEVICES_ADD(disk, disk)
>> +DEFINE_DEVICES_ADD(vif, nic)
>
> it seems to me that this is an anomaly which might be better fixed
> than worked around.
>
> Should we rename the functions libxl_*nic* or the structures *vif* ?
> Or should we rename both, to "net" perhaps ?

I think we should either rename the strucutres to nic also (because the 
also hold ioemu cards), or get rid of nic/vif an name everything net.

>
> In any case,
>
> 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 Jun 26 16:17:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:17: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 1SjYSK-0007tv-VY; Tue, 26 Jun 2012 16:17: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 1SjYSK-0007tZ-9i
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:17:32 +0000
Received: from [85.158.139.83:58524] by server-1.bemta-5.messagelabs.com id
	AC/BF-19721-B90E9EF4; Tue, 26 Jun 2012 16:17:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340727450!28340997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13363 invoked from network); 26 Jun 2012 16:17:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16: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.213.0;
	Tue, 26 Jun 2012 17:17:30 +0100
Message-ID: <1340727449.3832.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:17:29 +0100
In-Reply-To: <752a11d976972b3dca88.1339593050@probook.site>
References: <patchbomb.1339593047@probook.site>
	<752a11d976972b3dca88.1339593050@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill
 PACKAGE_TARNAME in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 14:10 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339593017 -7200
> # Node ID 752a11d976972b3dca886e16f7e07572cf7b3129
> # Parent  59762b446ab4e6d9a851a91d1457c11f6c828d49
> tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
> 
> Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
> preserve the currently used path, which ends with /xen, specify a value
> for PACKAGE_TARNAME. Without this change the path would end with
> /xen-hypervisor.
> 
> Also adjust mail adress to xen-devel@lists.xen.org.
> 
> Please rerun autoconf after applying this.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 59762b446ab4 -r 752a11d97697 tools/configure.ac
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -3,7 +3,7 @@
>  
>  AC_PREREQ([2.67])
>  AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
> -    [xen-devel@lists.xensource.com])
> +    [xen-devel@lists.xen.org], [xen], [http://www.xen.org/])
>  AC_CONFIG_SRCDIR([libxl/libxl.c])
>  AC_CONFIG_FILES([../config/Tools.mk])
>  AC_CONFIG_HEADERS([config.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 Tue Jun 26 16:17:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:17: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 1SjYSK-0007tv-VY; Tue, 26 Jun 2012 16:17: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 1SjYSK-0007tZ-9i
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:17:32 +0000
Received: from [85.158.139.83:58524] by server-1.bemta-5.messagelabs.com id
	AC/BF-19721-B90E9EF4; Tue, 26 Jun 2012 16:17:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340727450!28340997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13363 invoked from network); 26 Jun 2012 16:17:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16: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.213.0;
	Tue, 26 Jun 2012 17:17:30 +0100
Message-ID: <1340727449.3832.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:17:29 +0100
In-Reply-To: <752a11d976972b3dca88.1339593050@probook.site>
References: <patchbomb.1339593047@probook.site>
	<752a11d976972b3dca88.1339593050@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Roger
	Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/configure.ac: fill
 PACKAGE_TARNAME in AC_INIT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 14:10 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339593017 -7200
> # Node ID 752a11d976972b3dca886e16f7e07572cf7b3129
> # Parent  59762b446ab4e6d9a851a91d1457c11f6c828d49
> tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
> 
> Upcoming changes will move DOCDIR from Config.mk to config/Tools.mk. To
> preserve the currently used path, which ends with /xen, specify a value
> for PACKAGE_TARNAME. Without this change the path would end with
> /xen-hypervisor.
> 
> Also adjust mail adress to xen-devel@lists.xen.org.
> 
> Please rerun autoconf after applying this.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 59762b446ab4 -r 752a11d97697 tools/configure.ac
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -3,7 +3,7 @@
>  
>  AC_PREREQ([2.67])
>  AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
> -    [xen-devel@lists.xensource.com])
> +    [xen-devel@lists.xen.org], [xen], [http://www.xen.org/])
>  AC_CONFIG_SRCDIR([libxl/libxl.c])
>  AC_CONFIG_FILES([../config/Tools.mk])
>  AC_CONFIG_HEADERS([config.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 Tue Jun 26 16:20:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYVA-0008Ig-Ia; Tue, 26 Jun 2012 16:20:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjYV9-0008IT-Rf
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:20:28 +0000
Received: from [193.109.254.147:47618] by server-5.bemta-14.messagelabs.com id
	B2/A7-04343-B41E9EF4; Tue, 26 Jun 2012 16:20:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340727626!6228378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14421 invoked from network); 26 Jun 2012 16:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:19:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:19:41 +0100
Message-ID: <1340727580.3832.166.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:19:40 +0100
In-Reply-To: <20120613131352.GA1275@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
	<20120613075853.GA22553@aepfle.de>
	<1339574778.24104.122.camel@zakaz.uk.xensource.com>
	<20120613131352.GA1275@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, 2012-06-13 at 14:13 +0100, Olaf Hering wrote:
> On Wed, Jun 13, Ian Campbell wrote:
> 
> > On Wed, 2012-06-13 at 08:58 +0100, Olaf Hering wrote:
> > > On Tue, Jun 12, Ian Campbell wrote:
> > > 
> > > > On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > > > > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > > > > xl-network-configuration. Adjust to new DOCDIR location.
> > > > 
> > > > The reason for omitting the extension is that it can be .html or .txt
> > > > depending on the context which the link is given in.
> > > 
> > > How is that link ' F<xl-network-configuration>' supposed to be filled?
> > > I think F refers to a local filename.
> > 
> > F<..> just means "format as a filename i.e. italics", it doesn't turn
> > into an actual link even in html. I should have said "reference" rather
> > than "link" I think.
> 
> So how should I handle that part then? Leaving it alone for the time
> being? That would be fine with me.

Lets leave it for now.

> > > > > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > > > > +			misc/xl-disk-configuration.txt \
> > > > > +			misc/vbd-interface.txt \
> > > > > +			misc/xl-network-configuration.markdown
> > > > 
> > > > Any reason not to install the whole of $(DOC_TXT) instead of just this
> > > > subset?
> > > 
> > > Most of it looks like developer documentation to me. In the end
> > > kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
> > > installed in addition to the files above.
> > 
> > Perhaps we should be splitting the misc dir up into user and dev etc?
> 
> I think that will just cause unneeded churn. The list of user
> documentation files can be maintained in Makefile variable such as
> DOCS_TO_INSTALL.

OK.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:20:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYVA-0008Ig-Ia; Tue, 26 Jun 2012 16:20:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjYV9-0008IT-Rf
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:20:28 +0000
Received: from [193.109.254.147:47618] by server-5.bemta-14.messagelabs.com id
	B2/A7-04343-B41E9EF4; Tue, 26 Jun 2012 16:20:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340727626!6228378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14421 invoked from network); 26 Jun 2012 16:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:19:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:19:41 +0100
Message-ID: <1340727580.3832.166.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:19:40 +0100
In-Reply-To: <20120613131352.GA1275@aepfle.de>
References: <d5280420afc9c1e52d8e.1339430192@probook.site>
	<1339514061.24104.81.camel@zakaz.uk.xensource.com>
	<20120613075853.GA22553@aepfle.de>
	<1339574778.24104.122.camel@zakaz.uk.xensource.com>
	<20120613131352.GA1275@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: install documentation which is
 referenced in man 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, 2012-06-13 at 14:13 +0100, Olaf Hering wrote:
> On Wed, Jun 13, Ian Campbell wrote:
> 
> > On Wed, 2012-06-13 at 08:58 +0100, Olaf Hering wrote:
> > > On Tue, Jun 12, Ian Campbell wrote:
> > > 
> > > > On Mon, 2012-06-11 at 16:56 +0100, Olaf Hering wrote:
> > > > > xl.cfg.5 refers to non-existant files named xl-disk-configuration and
> > > > > xl-network-configuration. Adjust to new DOCDIR location.
> > > > 
> > > > The reason for omitting the extension is that it can be .html or .txt
> > > > depending on the context which the link is given in.
> > > 
> > > How is that link ' F<xl-network-configuration>' supposed to be filled?
> > > I think F refers to a local filename.
> > 
> > F<..> just means "format as a filename i.e. italics", it doesn't turn
> > into an actual link even in html. I should have said "reference" rather
> > than "link" I think.
> 
> So how should I handle that part then? Leaving it alone for the time
> being? That would be fine with me.

Lets leave it for now.

> > > > > +DOC_MAN_REFS    := misc/sedf_scheduler_mini-HOWTO.txt \
> > > > > +			misc/xl-disk-configuration.txt \
> > > > > +			misc/vbd-interface.txt \
> > > > > +			misc/xl-network-configuration.markdown
> > > > 
> > > > Any reason not to install the whole of $(DOC_TXT) instead of just this
> > > > subset?
> > > 
> > > Most of it looks like developer documentation to me. In the end
> > > kexec_and_kdump.txt, vtd.txt and perhaps the xen cmdline docu could be
> > > installed in addition to the files above.
> > 
> > Perhaps we should be splitting the misc dir up into user and dev etc?
> 
> I think that will just cause unneeded churn. The list of user
> documentation files can be maintained in Makefile variable such as
> DOCS_TO_INSTALL.

OK.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:20:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:20: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 1SjYVN-0008L2-3c; Tue, 26 Jun 2012 16:20:41 +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 1SjYVL-0008Kc-Lh
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:20:39 +0000
Received: from [85.158.143.35:26017] by server-1.bemta-4.messagelabs.com id
	E7/B0-24392-651E9EF4; Tue, 26 Jun 2012 16:20:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340727637!13943910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1300 invoked from network); 26 Jun 2012 16:20:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:20:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:20:37 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:20:37 +0100
Message-ID: <4FE9E153.1050309@citrix.com>
Date: Tue, 26 Jun 2012 17:20:35 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
In-Reply-To: <20452.22966.110320.601890@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
>> Set the default value for nic interfaces to VIF, since it used to be
>> IOEMU, even for PV guests.
>
> If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
> HVM guests getting emulated network interfaces by default ?

Yes, if you want emulated interfaces with HVM guests you should use 
'type=ioemu', that's how it has always been right?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:20:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:20: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 1SjYVN-0008L2-3c; Tue, 26 Jun 2012 16:20:41 +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 1SjYVL-0008Kc-Lh
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:20:39 +0000
Received: from [85.158.143.35:26017] by server-1.bemta-4.messagelabs.com id
	E7/B0-24392-651E9EF4; Tue, 26 Jun 2012 16:20:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340727637!13943910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1300 invoked from network); 26 Jun 2012 16:20:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:20:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13229946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:20:37 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:20:37 +0100
Message-ID: <4FE9E153.1050309@citrix.com>
Date: Tue, 26 Jun 2012 17:20:35 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
In-Reply-To: <20452.22966.110320.601890@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
>> Set the default value for nic interfaces to VIF, since it used to be
>> IOEMU, even for PV guests.
>
> If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
> HVM guests getting emulated network interfaces by default ?

Yes, if you want emulated interfaces with HVM guests you should use 
'type=ioemu', that's how it has always been right?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYZA-0000FY-SI; Tue, 26 Jun 2012 16:24: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 1SjYZ8-0000FQ-0u
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:24:35 +0000
Received: from [85.158.139.83:14367] by server-11.bemta-5.messagelabs.com id
	15/93-20400-142E9EF4; Tue, 26 Jun 2012 16:24:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340727872!25662403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29653 invoked from network); 26 Jun 2012 16:24:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:24:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:24:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:24:32 +0100
Message-ID: <1340727870.3832.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:24:30 +0100
In-Reply-To: <3a8cd926cd23170cd9d2.1339598492@probook.site>
References: <3a8cd926cd23170cd9d2.1339598492@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 15:41 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339598410 -7200
> # Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
> # Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
> tools: use --docdir option from configure

Not just tools: but also docs: since one of the effects of this patch is
that some "make *doc*" commands now require one to run ./configure
first.

Are we happy with that?

Perhaps we should defer these sorts of build system changes to 4.3 at this point.

> Use configure to set the docdir location. Up to now it was a Makefile
> variable which had to be specified with each make invocation.
> Move the DODCIR define from Config.mk to config/Tools.mk.
> Adjust some Makefiles which use DOCDIR to source also config/Tools.mk.
> 
> Special care needs to be taken with qemu-xen-traditional. Internally it
> uses the variable datadir to set the path to keymaps and ROM files. It
> also makes use of tools/Rules.mk, which in turn sources config/Tools.mk.
> This overwrites the initial value of datadir and keymaps and ROM files
> will be installed into a wrong location. Fix this by specifying datadir
> as make option.

Ewww... But necessary I suppose.

> 
> datadir itself needs to be present in config/Tools.mk.in, without it
> autoconf will print warnings and the newly added variables such as
> @docdir@ will not be expanded properly.
> 
> This patch does not move SHAREDIR and MANDIR from Config.mk to
> config/Tools.mk because qemu-xen-traditional is not prepared for that.
> It has ${prefix}/share hardcoded. This has to be addressed in a separate
> change.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 Config.mk
> --- a/Config.mk
> +++ b/Config.mk
> @@ -45,7 +45,6 @@ include $(XEN_ROOT)/config/$(XEN_OS).mk
>  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
>  
>  SHAREDIR    ?= $(PREFIX)/share
> -DOCDIR      ?= $(SHAREDIR)/doc/xen
>  MANDIR      ?= $(SHAREDIR)/man
>  BASH_COMPLETION_DIR ?= $(CONFIG_DIR)/bash_completion.d
>  
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 config/Tools.mk.in
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -1,6 +1,11 @@
>  # Prefix and install folder
>  PREFIX              := @prefix@
> +prefix              := @prefix@
>  LIBLEAFDIR_x86_64   := @LIB_PATH@
> +PACKAGE_TARNAME     := @PACKAGE_TARNAME@
> +datarootdir         := @datarootdir@
> +datadir             := @datadir@
> +DOCDIR              := @docdir@
>  
>  # A debug build of tools?
>  debug               := @debug@
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/Makefile
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -2,6 +2,7 @@
>  
>  XEN_ROOT=$(CURDIR)/..
>  include $(XEN_ROOT)/Config.mk
> +-include $(XEN_ROOT)/config/Tools.mk
>  include $(XEN_ROOT)/docs/Docs.mk
>  
>  VERSION		= xen-unstable
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/xen-api/Makefile
> --- a/docs/xen-api/Makefile
> +++ b/docs/xen-api/Makefile
> @@ -2,6 +2,7 @@
>  
>  XEN_ROOT=$(CURDIR)/../..
>  include $(XEN_ROOT)/Config.mk
> +-include $(XEN_ROOT)/config/Tools.mk
>  include $(XEN_ROOT)/docs/Docs.mk
>  
> 
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 stubdom/Makefile
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -6,6 +6,7 @@ export XEN_OS=MiniOS
>  export stubdom=y
>  export debug=y
>  include $(XEN_ROOT)/Config.mk
> +-include $(XEN_ROOT)/config/Tools.mk
>  
>  #ZLIB_URL?=http://www.zlib.net
>  ZLIB_URL=$(XEN_EXTFILES_URL)
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 tools/Makefile
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -123,7 +123,8 @@ subdir-all-qemu-xen-traditional-dir: qem
>  		$(buildmakevars2shellvars); \
>  		cd qemu-xen-traditional-dir; \
>  		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
> -		$(MAKE) all
> +		$(MAKE) all \
> +			datadir="$(SHAREDIR)/xen/qemu"
>  
>  subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
>  	set -e; \
> @@ -132,11 +133,14 @@ subdir-install-qemu-xen-traditional-dir:
>  		$(QEMU_ROOT)/xen-setup \
>  		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
>  		$(IOEMU_CONFIGURE_CROSS); \
> -		$(MAKE) install
> +		$(MAKE) install \
> +			datadir="$(SHAREDIR)/xen/qemu"
>  
>  subdir-clean-qemu-xen-traditional-dir:
>  	set -e; if test -d qemu-xen-traditional-dir/.; then \
> -		$(MAKE) -C qemu-xen-traditional-dir clean; \
> +		$(MAKE) -C qemu-xen-traditional-dir clean \
> +			datadir="$(SHAREDIR)/xen/qemu" \
> +		; \
>  	fi
>  
>  .PHONY: qemu-xen-dir-force-update
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 26 16:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYZA-0000FY-SI; Tue, 26 Jun 2012 16:24: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 1SjYZ8-0000FQ-0u
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:24:35 +0000
Received: from [85.158.139.83:14367] by server-11.bemta-5.messagelabs.com id
	15/93-20400-142E9EF4; Tue, 26 Jun 2012 16:24:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340727872!25662403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29653 invoked from network); 26 Jun 2012 16:24:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:24:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230052"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:24:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:24:32 +0100
Message-ID: <1340727870.3832.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 26 Jun 2012 17:24:30 +0100
In-Reply-To: <3a8cd926cd23170cd9d2.1339598492@probook.site>
References: <3a8cd926cd23170cd9d2.1339598492@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-13 at 15:41 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1339598410 -7200
> # Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
> # Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
> tools: use --docdir option from configure

Not just tools: but also docs: since one of the effects of this patch is
that some "make *doc*" commands now require one to run ./configure
first.

Are we happy with that?

Perhaps we should defer these sorts of build system changes to 4.3 at this point.

> Use configure to set the docdir location. Up to now it was a Makefile
> variable which had to be specified with each make invocation.
> Move the DODCIR define from Config.mk to config/Tools.mk.
> Adjust some Makefiles which use DOCDIR to source also config/Tools.mk.
> 
> Special care needs to be taken with qemu-xen-traditional. Internally it
> uses the variable datadir to set the path to keymaps and ROM files. It
> also makes use of tools/Rules.mk, which in turn sources config/Tools.mk.
> This overwrites the initial value of datadir and keymaps and ROM files
> will be installed into a wrong location. Fix this by specifying datadir
> as make option.

Ewww... But necessary I suppose.

> 
> datadir itself needs to be present in config/Tools.mk.in, without it
> autoconf will print warnings and the newly added variables such as
> @docdir@ will not be expanded properly.
> 
> This patch does not move SHAREDIR and MANDIR from Config.mk to
> config/Tools.mk because qemu-xen-traditional is not prepared for that.
> It has ${prefix}/share hardcoded. This has to be addressed in a separate
> change.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 Config.mk
> --- a/Config.mk
> +++ b/Config.mk
> @@ -45,7 +45,6 @@ include $(XEN_ROOT)/config/$(XEN_OS).mk
>  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
>  
>  SHAREDIR    ?= $(PREFIX)/share
> -DOCDIR      ?= $(SHAREDIR)/doc/xen
>  MANDIR      ?= $(SHAREDIR)/man
>  BASH_COMPLETION_DIR ?= $(CONFIG_DIR)/bash_completion.d
>  
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 config/Tools.mk.in
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -1,6 +1,11 @@
>  # Prefix and install folder
>  PREFIX              := @prefix@
> +prefix              := @prefix@
>  LIBLEAFDIR_x86_64   := @LIB_PATH@
> +PACKAGE_TARNAME     := @PACKAGE_TARNAME@
> +datarootdir         := @datarootdir@
> +datadir             := @datadir@
> +DOCDIR              := @docdir@
>  
>  # A debug build of tools?
>  debug               := @debug@
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/Makefile
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -2,6 +2,7 @@
>  
>  XEN_ROOT=$(CURDIR)/..
>  include $(XEN_ROOT)/Config.mk
> +-include $(XEN_ROOT)/config/Tools.mk
>  include $(XEN_ROOT)/docs/Docs.mk
>  
>  VERSION		= xen-unstable
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 docs/xen-api/Makefile
> --- a/docs/xen-api/Makefile
> +++ b/docs/xen-api/Makefile
> @@ -2,6 +2,7 @@
>  
>  XEN_ROOT=$(CURDIR)/../..
>  include $(XEN_ROOT)/Config.mk
> +-include $(XEN_ROOT)/config/Tools.mk
>  include $(XEN_ROOT)/docs/Docs.mk
>  
> 
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 stubdom/Makefile
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -6,6 +6,7 @@ export XEN_OS=MiniOS
>  export stubdom=y
>  export debug=y
>  include $(XEN_ROOT)/Config.mk
> +-include $(XEN_ROOT)/config/Tools.mk
>  
>  #ZLIB_URL?=http://www.zlib.net
>  ZLIB_URL=$(XEN_EXTFILES_URL)
> diff -r 9d6fb03ba8e9 -r 3a8cd926cd23 tools/Makefile
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -123,7 +123,8 @@ subdir-all-qemu-xen-traditional-dir: qem
>  		$(buildmakevars2shellvars); \
>  		cd qemu-xen-traditional-dir; \
>  		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
> -		$(MAKE) all
> +		$(MAKE) all \
> +			datadir="$(SHAREDIR)/xen/qemu"
>  
>  subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
>  	set -e; \
> @@ -132,11 +133,14 @@ subdir-install-qemu-xen-traditional-dir:
>  		$(QEMU_ROOT)/xen-setup \
>  		--extra-cflags="$(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
>  		$(IOEMU_CONFIGURE_CROSS); \
> -		$(MAKE) install
> +		$(MAKE) install \
> +			datadir="$(SHAREDIR)/xen/qemu"
>  
>  subdir-clean-qemu-xen-traditional-dir:
>  	set -e; if test -d qemu-xen-traditional-dir/.; then \
> -		$(MAKE) -C qemu-xen-traditional-dir clean; \
> +		$(MAKE) -C qemu-xen-traditional-dir clean \
> +			datadir="$(SHAREDIR)/xen/qemu" \
> +		; \
>  	fi
>  
>  .PHONY: qemu-xen-dir-force-update
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 26 16:24:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYZK-0000GT-9O; Tue, 26 Jun 2012 16:24: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 1SjYZJ-0000GE-Aa
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:24:45 +0000
Received: from [85.158.139.83:48296] by server-9.bemta-5.messagelabs.com id
	0C/94-01069-C42E9EF4; Tue, 26 Jun 2012 16:24:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340727884!29606940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30851 invoked from network); 26 Jun 2012 16:24:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	26 Jun 2012 16:24:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 17:24:43 +0100
Message-Id: <4FE9FE97020000780008C00F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 17:25:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jun Nakajima" <jun.nakajima@intel.com>,
 "Keir Fraser" <keir@xen.org>
References: <4FDB790F020000780008A406@nat28.tlf.novell.com>
	<CC012A16.43075%keir@xen.org>
In-Reply-To: <CC012A16.43075%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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.06.12 at 19:06, Keir Fraser <keir@xen.org> wrote:
> On 15/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> While pv-ops so far doesn't care to eliminate the two trap-and-
>> emulate CR0 accesses from the asm/xor.h save/restore
>> operations, the legacy x86-64 kernel uses conditional clts()/stts()
>> for this purpose. While looking into whether to extend this to the
>> newly added (in 3.5) AVX operations there I realized that this isn't
>> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
>> kernel_fpu_end() pair (as it will stts() at the end no matter what
>> the original state of CR0.TS was).
>> 
>> In order to not introduce completely new hypercalls to overcome
>> this (fpu_taskswitch isn't really extensible on its own), I'm
>> considering to add a new VM assist, altering the fpu_taskswitch
>> behavior so that it would return an indicator whether any change
>> to the virtual CR0.TS was done. That way, the kernel can
>> implement a true save/restore cycle here.
> 
> It should be possible for the guest kernel to track its CR0.TS setting
> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
> cleared on #NM.

While this works fine and is fairly non-intrusive, it's not really
buying us much: The non-SSE variants of the xor code will still
outperform the SSE one on both 32- and 64-bit x86 (and the
MMX ones on 32-bit). So I now instead wonder why linux-2.6.18's
include/asm-x86_64/mach-xen/asm/xor.h doesn't simply
forward to asm-generic/xor.h, or at least doesn't override the
template selection logic. Jun, do you recall whether this was
perhaps done without any actual measurements when the port
to x86-64 was first 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 Jun 26 16:24:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYZK-0000GT-9O; Tue, 26 Jun 2012 16:24: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 1SjYZJ-0000GE-Aa
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:24:45 +0000
Received: from [85.158.139.83:48296] by server-9.bemta-5.messagelabs.com id
	0C/94-01069-C42E9EF4; Tue, 26 Jun 2012 16:24:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340727884!29606940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NDA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30851 invoked from network); 26 Jun 2012 16:24:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	26 Jun 2012 16:24:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Jun 2012 17:24:43 +0100
Message-Id: <4FE9FE97020000780008C00F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 26 Jun 2012 17:25:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jun Nakajima" <jun.nakajima@intel.com>,
 "Keir Fraser" <keir@xen.org>
References: <4FDB790F020000780008A406@nat28.tlf.novell.com>
	<CC012A16.43075%keir@xen.org>
In-Reply-To: <CC012A16.43075%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] fpu_taskswitch adjustment 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.06.12 at 19:06, Keir Fraser <keir@xen.org> wrote:
> On 15/06/2012 17:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> While pv-ops so far doesn't care to eliminate the two trap-and-
>> emulate CR0 accesses from the asm/xor.h save/restore
>> operations, the legacy x86-64 kernel uses conditional clts()/stts()
>> for this purpose. While looking into whether to extend this to the
>> newly added (in 3.5) AVX operations there I realized that this isn't
>> fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
>> kernel_fpu_end() pair (as it will stts() at the end no matter what
>> the original state of CR0.TS was).
>> 
>> In order to not introduce completely new hypercalls to overcome
>> this (fpu_taskswitch isn't really extensible on its own), I'm
>> considering to add a new VM assist, altering the fpu_taskswitch
>> behavior so that it would return an indicator whether any change
>> to the virtual CR0.TS was done. That way, the kernel can
>> implement a true save/restore cycle here.
> 
> It should be possible for the guest kernel to track its CR0.TS setting
> shouldn't it? It gets modified only via a few paravirt hooks, and implicitly
> cleared on #NM.

While this works fine and is fairly non-intrusive, it's not really
buying us much: The non-SSE variants of the xor code will still
outperform the SSE one on both 32- and 64-bit x86 (and the
MMX ones on 32-bit). So I now instead wonder why linux-2.6.18's
include/asm-x86_64/mach-xen/asm/xor.h doesn't simply
forward to asm-generic/xor.h, or at least doesn't override the
template selection logic. Jun, do you recall whether this was
perhaps done without any actual measurements when the port
to x86-64 was first 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 Jun 26 16:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:25: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 1SjYZq-0000LQ-Of; Tue, 26 Jun 2012 16:25:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjYZp-0000Kt-9m
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:25:17 +0000
Received: from [85.158.138.51:63033] by server-4.bemta-3.messagelabs.com id
	FD/73-17105-C62E9EF4; Tue, 26 Jun 2012 16:25:16 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340727915!28533926!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5042 invoked from network); 26 Jun 2012 16:25:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 16:25:15 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79146227; Tue, 26 Jun 2012 18:25:14 +0200
Message-ID: <1340727908.9444.21.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 26 Jun 2012 18:25:08 +0200
In-Reply-To: <1340360049.26083.82.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
	<1340360049.26083.82.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4293735062636114109=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4293735062636114109==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-aw9n+rJ11gZMO2qhho7z"


--=-aw9n+rJ11gZMO2qhho7z
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-22 at 11:14 +0100, Ian Campbell wrote:
> > > > +    /* Bring the best candidate in front of the list --> candidate=
s[0] */
> > > > +    if (nr_candidates > 1)
> > > > +        libxl__sort_numa_candidates(candidates, nr_candidates, num=
a_cmpf);
> > >=20
> > > Is the start up cost of libxl__sort_numa_candidates significant enoug=
h
> > > to make that if worthwhile?
> > >=20
> > I'm not sure what you mean here, I'm afraid ... :-(
>=20
> Is the cost of sorting the 1 element list so high it is worth avoiding.
> Since the sort itself would be trivial the startup costs are what would
> dominate.
>=20
So, the answer is that I really don't know, as I'm using a library
function for doing the actual work. I really do not expect for them to
be that high, and I hence can remove the if() if you think it looks
ugly. :-)

> > > I'm not sure about this, if numa_place_domain fails for any reason wo=
uld
> > > we be not better off logging and continuing without placement? We
> > > already do that explicitly in a couple of cases.
> > >=20
> > Well, actually, if it "fails" in the sense it finds no candidates or
> > does not manage in placing the domain, it returns 0, so we do right wha=
t
> > you're suggesting. I'm sure this is stated in some comment but I guess =
I
> > can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
> > something, which I think has to be handled like this, hasn't it?
>=20
> That makes sense.
>=20
> > Perhaps I can also add some logging about "successfully failing", i.e.,
> > not getting into any error but not being able to place the domain. If
> > yes, that will happen _inside_ numa_place_domain() rather than here.
>=20
> Logging in that case seems wise in any case since it will have
> performance implications I think.
>=20
Ok, I'll log something out.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-aw9n+rJ11gZMO2qhho7z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p4mQACgkQk4XaBE3IOsQ3mQCfUw3Yp5pme8z6n5M+9bjMOuoq
iKkAoJwY2zdWF9rpYfju0l6twL0kiVPj
=0itV
-----END PGP SIGNATURE-----

--=-aw9n+rJ11gZMO2qhho7z--



--===============4293735062636114109==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4293735062636114109==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 16:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:25: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 1SjYZq-0000LQ-Of; Tue, 26 Jun 2012 16:25:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjYZp-0000Kt-9m
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:25:17 +0000
Received: from [85.158.138.51:63033] by server-4.bemta-3.messagelabs.com id
	FD/73-17105-C62E9EF4; Tue, 26 Jun 2012 16:25:16 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340727915!28533926!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5042 invoked from network); 26 Jun 2012 16:25:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-174.messagelabs.com with SMTP;
	26 Jun 2012 16:25:15 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79146227; Tue, 26 Jun 2012 18:25:14 +0200
Message-ID: <1340727908.9444.21.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 26 Jun 2012 18:25:08 +0200
In-Reply-To: <1340360049.26083.82.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
	<1340360049.26083.82.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4293735062636114109=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4293735062636114109==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-aw9n+rJ11gZMO2qhho7z"


--=-aw9n+rJ11gZMO2qhho7z
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-22 at 11:14 +0100, Ian Campbell wrote:
> > > > +    /* Bring the best candidate in front of the list --> candidate=
s[0] */
> > > > +    if (nr_candidates > 1)
> > > > +        libxl__sort_numa_candidates(candidates, nr_candidates, num=
a_cmpf);
> > >=20
> > > Is the start up cost of libxl__sort_numa_candidates significant enoug=
h
> > > to make that if worthwhile?
> > >=20
> > I'm not sure what you mean here, I'm afraid ... :-(
>=20
> Is the cost of sorting the 1 element list so high it is worth avoiding.
> Since the sort itself would be trivial the startup costs are what would
> dominate.
>=20
So, the answer is that I really don't know, as I'm using a library
function for doing the actual work. I really do not expect for them to
be that high, and I hence can remove the if() if you think it looks
ugly. :-)

> > > I'm not sure about this, if numa_place_domain fails for any reason wo=
uld
> > > we be not better off logging and continuing without placement? We
> > > already do that explicitly in a couple of cases.
> > >=20
> > Well, actually, if it "fails" in the sense it finds no candidates or
> > does not manage in placing the domain, it returns 0, so we do right wha=
t
> > you're suggesting. I'm sure this is stated in some comment but I guess =
I
> > can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
> > something, which I think has to be handled like this, hasn't it?
>=20
> That makes sense.
>=20
> > Perhaps I can also add some logging about "successfully failing", i.e.,
> > not getting into any error but not being able to place the domain. If
> > yes, that will happen _inside_ numa_place_domain() rather than here.
>=20
> Logging in that case seems wise in any case since it will have
> performance implications I think.
>=20
Ok, I'll log something out.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-aw9n+rJ11gZMO2qhho7z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p4mQACgkQk4XaBE3IOsQ3mQCfUw3Yp5pme8z6n5M+9bjMOuoq
iKkAoJwY2zdWF9rpYfju0l6twL0kiVPj
=0itV
-----END PGP SIGNATURE-----

--=-aw9n+rJ11gZMO2qhho7z--



--===============4293735062636114109==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4293735062636114109==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 16:26:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYaz-0000Vb-8e; Tue, 26 Jun 2012 16:26: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 1SjYax-0000V3-2v
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:26:27 +0000
Received: from [85.158.143.99:26544] by server-3.bemta-4.messagelabs.com id
	89/80-05808-1B2E9EF4; Tue, 26 Jun 2012 16:26:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340727984!23958715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16489 invoked from network); 26 Jun 2012 16:26:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:26:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:26:24 +0100
Message-ID: <1340727982.3832.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 26 Jun 2012 17:26:22 +0100
In-Reply-To: <1340727908.9444.21.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
	<1340360049.26083.82.camel@zakaz.uk.xensource.com>
	<1340727908.9444.21.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 17:25 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-22 at 11:14 +0100, Ian Campbell wrote:
> > > > > +    /* Bring the best candidate in front of the list --> candidates[0] */
> > > > > +    if (nr_candidates > 1)
> > > > > +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);
> > > > 
> > > > Is the start up cost of libxl__sort_numa_candidates significant enough
> > > > to make that if worthwhile?
> > > > 
> > > I'm not sure what you mean here, I'm afraid ... :-(
> > 
> > Is the cost of sorting the 1 element list so high it is worth avoiding.
> > Since the sort itself would be trivial the startup costs are what would
> > dominate.
> > 
> So, the answer is that I really don't know, as I'm using a library
> function for doing the actual work. I really do not expect for them to
> be that high, and I hence can remove the if() if you think it looks
> ugly. :-)

Not really ugly, it just seemed like an odd optimisation to make.

> 
> > > > I'm not sure about this, if numa_place_domain fails for any reason would
> > > > we be not better off logging and continuing without placement? We
> > > > already do that explicitly in a couple of cases.
> > > > 
> > > Well, actually, if it "fails" in the sense it finds no candidates or
> > > does not manage in placing the domain, it returns 0, so we do right what
> > > you're suggesting. I'm sure this is stated in some comment but I guess I
> > > can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
> > > something, which I think has to be handled like this, hasn't it?
> > 
> > That makes sense.
> > 
> > > Perhaps I can also add some logging about "successfully failing", i.e.,
> > > not getting into any error but not being able to place the domain. If
> > > yes, that will happen _inside_ numa_place_domain() rather than here.
> > 
> > Logging in that case seems wise in any case since it will have
> > performance implications I think.
> > 
> Ok, I'll log something out.
> 
> Thanks and Regards,
> Dario
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:26:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYaz-0000Vb-8e; Tue, 26 Jun 2012 16:26: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 1SjYax-0000V3-2v
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:26:27 +0000
Received: from [85.158.143.99:26544] by server-3.bemta-4.messagelabs.com id
	89/80-05808-1B2E9EF4; Tue, 26 Jun 2012 16:26:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340727984!23958715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16489 invoked from network); 26 Jun 2012 16:26:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:26:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:26:24 +0100
Message-ID: <1340727982.3832.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Tue, 26 Jun 2012 17:26:22 +0100
In-Reply-To: <1340727908.9444.21.camel@Solace>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
	<1340360049.26083.82.camel@zakaz.uk.xensource.com>
	<1340727908.9444.21.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 17:25 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-22 at 11:14 +0100, Ian Campbell wrote:
> > > > > +    /* Bring the best candidate in front of the list --> candidates[0] */
> > > > > +    if (nr_candidates > 1)
> > > > > +        libxl__sort_numa_candidates(candidates, nr_candidates, numa_cmpf);
> > > > 
> > > > Is the start up cost of libxl__sort_numa_candidates significant enough
> > > > to make that if worthwhile?
> > > > 
> > > I'm not sure what you mean here, I'm afraid ... :-(
> > 
> > Is the cost of sorting the 1 element list so high it is worth avoiding.
> > Since the sort itself would be trivial the startup costs are what would
> > dominate.
> > 
> So, the answer is that I really don't know, as I'm using a library
> function for doing the actual work. I really do not expect for them to
> be that high, and I hence can remove the if() if you think it looks
> ugly. :-)

Not really ugly, it just seemed like an odd optimisation to make.

> 
> > > > I'm not sure about this, if numa_place_domain fails for any reason would
> > > > we be not better off logging and continuing without placement? We
> > > > already do that explicitly in a couple of cases.
> > > > 
> > > Well, actually, if it "fails" in the sense it finds no candidates or
> > > does not manage in placing the domain, it returns 0, so we do right what
> > > you're suggesting. I'm sure this is stated in some comment but I guess I
> > > can repeat it here. If !rc, it means we stepped into some ERROR_FAIL or
> > > something, which I think has to be handled like this, hasn't it?
> > 
> > That makes sense.
> > 
> > > Perhaps I can also add some logging about "successfully failing", i.e.,
> > > not getting into any error but not being able to place the domain. If
> > > yes, that will happen _inside_ numa_place_domain() rather than here.
> > 
> > Logging in that case seems wise in any case since it will have
> > performance implications I think.
> > 
> Ok, I'll log something out.
> 
> Thanks and Regards,
> Dario
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:26:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYb9-0000XI-Lz; Tue, 26 Jun 2012 16:26:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjYb8-0000Wx-G7
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:26:38 +0000
Received: from [193.109.254.147:53726] by server-12.bemta-14.messagelabs.com
	id 25/C6-30461-DB2E9EF4; Tue, 26 Jun 2012 16:26:37 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340727995!8502463!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4573 invoked from network); 26 Jun 2012 16:26:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 16:26:35 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79146215; Tue, 26 Jun 2012 18:26:35 +0200
Message-ID: <1340727989.9444.22.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 26 Jun 2012 18:26:29 +0200
In-Reply-To: <1340726421.3832.160.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<6c32fcbbd4896a55b73e.1339779869@Solace>
	<1340268784.21872.15.camel@zakaz.uk.xensource.com>
	<1340726421.3832.160.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
 GCREALLOC_ARRAY 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: multipart/mixed; boundary="===============3734191839516441908=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3734191839516441908==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-vQKN5vnVZQhLV+uiEIL+"


--=-vQKN5vnVZQhLV+uiEIL+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 17:00 +0100, Ian Campbell wrote:
> On Thu, 2012-06-21 at 09:53 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > > Causing a build failure when trying to use it:
> > >=20
> > > xxx: error: expected ';' before ')' token
> > > xxx: error: expected statement before ')' token
> > >=20
> > > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >=20
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
> This bugfix was mostly independent from the rest of the series,=20
Indeed. I submitted it as a separate patch the week before, but it maybe
got lost. :-)

> so I've committed it.
Cool.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-vQKN5vnVZQhLV+uiEIL+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p4rUACgkQk4XaBE3IOsSBswCgklrDnZxD71jcArqFU3PjkOFJ
bzUAn15Lu8mWcMYsrmI1tPhJigDBPWTZ
=Do8U
-----END PGP SIGNATURE-----

--=-vQKN5vnVZQhLV+uiEIL+--



--===============3734191839516441908==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3734191839516441908==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 16:26:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYb9-0000XI-Lz; Tue, 26 Jun 2012 16:26:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjYb8-0000Wx-G7
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:26:38 +0000
Received: from [193.109.254.147:53726] by server-12.bemta-14.messagelabs.com
	id 25/C6-30461-DB2E9EF4; Tue, 26 Jun 2012 16:26:37 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340727995!8502463!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4573 invoked from network); 26 Jun 2012 16:26:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 16:26:35 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79146215; Tue, 26 Jun 2012 18:26:35 +0200
Message-ID: <1340727989.9444.22.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 26 Jun 2012 18:26:29 +0200
In-Reply-To: <1340726421.3832.160.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<6c32fcbbd4896a55b73e.1339779869@Solace>
	<1340268784.21872.15.camel@zakaz.uk.xensource.com>
	<1340726421.3832.160.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01 of 10 v2] libxl: fix a typo in the
 GCREALLOC_ARRAY 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: multipart/mixed; boundary="===============3734191839516441908=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3734191839516441908==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-vQKN5vnVZQhLV+uiEIL+"


--=-vQKN5vnVZQhLV+uiEIL+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 17:00 +0100, Ian Campbell wrote:
> On Thu, 2012-06-21 at 09:53 +0100, Ian Campbell wrote:
> > On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote:
> > > Causing a build failure when trying to use it:
> > >=20
> > > xxx: error: expected ';' before ')' token
> > > xxx: error: expected statement before ')' token
> > >=20
> > > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >=20
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
> This bugfix was mostly independent from the rest of the series,=20
Indeed. I submitted it as a separate patch the week before, but it maybe
got lost. :-)

> so I've committed it.
Cool.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-vQKN5vnVZQhLV+uiEIL+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p4rUACgkQk4XaBE3IOsSBswCgklrDnZxD71jcArqFU3PjkOFJ
bzUAn15Lu8mWcMYsrmI1tPhJigDBPWTZ
=Do8U
-----END PGP SIGNATURE-----

--=-vQKN5vnVZQhLV+uiEIL+--



--===============3734191839516441908==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3734191839516441908==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 16:29:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:29: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 1SjYdM-0000qV-Qv; Tue, 26 Jun 2012 16:28:56 +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 1SjYdL-0000q1-UN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:28:56 +0000
Received: from [193.109.254.147:16370] by server-4.bemta-14.messagelabs.com id
	92/66-02077-743E9EF4; Tue, 26 Jun 2012 16:28:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340728134!8657735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8163 invoked from network); 26 Jun 2012 16:28:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:28:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:28:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:28:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjYdK-0008TC-8E; Tue, 26 Jun 2012 16:28:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjYdK-0005bh-76;
	Tue, 26 Jun 2012 17:28:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.58182.205340.801355@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 17:28:54 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0233305f23816261bb49.1338466270@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
	IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> And make all the required infrastructure updates to enable this.

> diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
> --- a/tools/libxl/idl.txt
> +++ b/tools/libxl/idl.txt
> @@ -145,12 +145,24 @@ idl.KeyedUnion
>  
>   A subclass of idl.Aggregate which represents the C union type
>   where the currently valid member of the union can be determined based
> - upon another member in the containing type.
> + upon another member in the containing type. An idl.KeyedUnion must
> + always be a member of a containing idl.Aggregate type.
>  
> - The KeyedUnion.keyvar contains an idl.type the member of the
> + The KeyedUnion.keyvar contains an idl.Type the member of the
>   containing type which determines the valid member of the union. The
>   must be an instance of the Enumeration type.

Something seems to have been mangled here in this sentence (although
all your patch does is change the case of the name).

> +idl.Array
> +
> +  A class representing an array or similar elements. An idl.Array must
                                   ^^
of.

> +  always be an idl.Field of a containing idl.Aggregate.
> +
> +  idl.Array.elem_type contains an idl.Type which is the type of all
> +  elements of the array.

More natural in English would be, I think, "... the type of each
element of the array".

> +  idl.Array.len_var contains an idl.Field which is added to the parent
> +  idl.Aggregate and will contain the length of the array.

I think you should explicitly say that len_var MUST be a field named
"num_XXX" where the original field is named XXX, as previously stated.

In the future this will probably be enforced by the idl compiler.


Aside from that,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:29:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:29: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 1SjYdM-0000qV-Qv; Tue, 26 Jun 2012 16:28:56 +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 1SjYdL-0000q1-UN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:28:56 +0000
Received: from [193.109.254.147:16370] by server-4.bemta-14.messagelabs.com id
	92/66-02077-743E9EF4; Tue, 26 Jun 2012 16:28:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340728134!8657735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8163 invoked from network); 26 Jun 2012 16:28:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:28:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:28:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:28:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjYdK-0008TC-8E; Tue, 26 Jun 2012 16:28:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjYdK-0005bh-76;
	Tue, 26 Jun 2012 17:28:54 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.58182.205340.801355@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 17:28:54 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0233305f23816261bb49.1338466270@Solace>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
	IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> And make all the required infrastructure updates to enable this.

> diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
> --- a/tools/libxl/idl.txt
> +++ b/tools/libxl/idl.txt
> @@ -145,12 +145,24 @@ idl.KeyedUnion
>  
>   A subclass of idl.Aggregate which represents the C union type
>   where the currently valid member of the union can be determined based
> - upon another member in the containing type.
> + upon another member in the containing type. An idl.KeyedUnion must
> + always be a member of a containing idl.Aggregate type.
>  
> - The KeyedUnion.keyvar contains an idl.type the member of the
> + The KeyedUnion.keyvar contains an idl.Type the member of the
>   containing type which determines the valid member of the union. The
>   must be an instance of the Enumeration type.

Something seems to have been mangled here in this sentence (although
all your patch does is change the case of the name).

> +idl.Array
> +
> +  A class representing an array or similar elements. An idl.Array must
                                   ^^
of.

> +  always be an idl.Field of a containing idl.Aggregate.
> +
> +  idl.Array.elem_type contains an idl.Type which is the type of all
> +  elements of the array.

More natural in English would be, I think, "... the type of each
element of the array".

> +  idl.Array.len_var contains an idl.Field which is added to the parent
> +  idl.Aggregate and will contain the length of the array.

I think you should explicitly say that len_var MUST be a field named
"num_XXX" where the original field is named XXX, as previously stated.

In the future this will probably be enforced by the idl compiler.


Aside from that,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:29:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:29: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 1SjYdL-0000pu-8c; Tue, 26 Jun 2012 16:28: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 1SjYdJ-0000pg-Sj
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:28:54 +0000
Received: from [85.158.138.51:17955] by server-9.bemta-3.messagelabs.com id
	07/6E-10419-043E9EF4; Tue, 26 Jun 2012 16:28:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340728127!29609771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29925 invoked from network); 26 Jun 2012 16:28:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:28:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:28:47 +0100
Message-ID: <1340728125.3832.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Jun 2012 17:28:45 +0100
In-Reply-To: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
References: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs/xen-headers: allow headers to be
 symlinks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 13:20 +0100, Jan Beulich wrote:
> There's no apparent reason not to permit this, and since we don't
> support out-of-source-tree builds, the least overhead way of doing
> multiple, differently configured (perhaps different architecture)
> builds from a single source tree is to create symlinked build trees.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Seems reasonable and applying the patch resulted in no change in the
output on this end:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/docs/xen-headers
> +++ b/docs/xen-headers
> @@ -368,7 +368,7 @@ foreach $pass (qw(1 2)) {
>      find({ wanted => 
>                 sub {
>                     return unless m/\.h$/;
> -                   lstat $File::Find::name or die "$File::Find::name $!";
> +                   stat $File::Find::name or die "$File::Find::name $!";
>                     -f _ or die "$File::Find::name";
>                     substr($File::Find::name, 0, 1+length $basedir) 
>                         eq "$basedir/"
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:29:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:29: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 1SjYdL-0000pu-8c; Tue, 26 Jun 2012 16:28: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 1SjYdJ-0000pg-Sj
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:28:54 +0000
Received: from [85.158.138.51:17955] by server-9.bemta-3.messagelabs.com id
	07/6E-10419-043E9EF4; Tue, 26 Jun 2012 16:28:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340728127!29609771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29925 invoked from network); 26 Jun 2012 16:28:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:28:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 26 Jun 2012 17:28:47 +0100
Message-ID: <1340728125.3832.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Jun 2012 17:28:45 +0100
In-Reply-To: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
References: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs/xen-headers: allow headers to be
 symlinks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-21 at 13:20 +0100, Jan Beulich wrote:
> There's no apparent reason not to permit this, and since we don't
> support out-of-source-tree builds, the least overhead way of doing
> multiple, differently configured (perhaps different architecture)
> builds from a single source tree is to create symlinked build trees.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Seems reasonable and applying the patch resulted in no change in the
output on this end:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/docs/xen-headers
> +++ b/docs/xen-headers
> @@ -368,7 +368,7 @@ foreach $pass (qw(1 2)) {
>      find({ wanted => 
>                 sub {
>                     return unless m/\.h$/;
> -                   lstat $File::Find::name or die "$File::Find::name $!";
> +                   stat $File::Find::name or die "$File::Find::name $!";
>                     -f _ or die "$File::Find::name";
>                     substr($File::Find::name, 0, 1+length $basedir) 
>                         eq "$basedir/"
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:30:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYf2-00018s-Bs; Tue, 26 Jun 2012 16:30:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <okhalid.cern@gmail.com>) id 1SjYf1-00018V-0J
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:30:39 +0000
Received: from [85.158.143.35:36115] by server-3.bemta-4.messagelabs.com id
	3B/25-05808-EA3E9EF4; Tue, 26 Jun 2012 16:30:38 +0000
X-Env-Sender: okhalid.cern@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340728230!11093163!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12114 invoked from network); 26 Jun 2012 16:30:32 -0000
Received: from mail-gg0-f171.google.com (HELO mail-gg0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:30:32 -0000
Received: by ggmi1 with SMTP id i1so130878ggm.30
	for <multiple recipients>; Tue, 26 Jun 2012 09:30:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=tu1+d7+QldrSga9TPvsc1QH14Qm7KVjZyJDLCXFVDI0=;
	b=v8PCMAC+vVrS2167UaXGdScVya7F2t71Yrmhd/9Qk2ZbtNELOCVGEg9dG9k6kRStBp
	53ch5U3b9yCQAH4jX+ozEV57qEfpNX/eVTRmuLBVE56XL+JbHLBlvSnrAZJqQcBeI/VM
	8C8Hv3pUK1xDCYWU6sC7bA0XidnfHH8r8JrBbiwWmgrbIOROSeRi3UvK6E7vZ0gRrYxg
	fIhjYYCvsGGlimPFZbBlCm5mwVlp077HbMFk8KEsm/08W9sq93p80kAJWUr2/QdgprsQ
	EfSiOUyfkSrQHpRm6E/eRtSfsMoD7EjA9VW63NjNb7V9L7QI+yxKMWkuFtF6z5tvbjhM
	OA7g==
MIME-Version: 1.0
Received: by 10.50.94.166 with SMTP id dd6mr11665892igb.11.1340728230217; Tue,
	26 Jun 2012 09:30:30 -0700 (PDT)
Received: by 10.231.174.84 with HTTP; Tue, 26 Jun 2012 09:30:29 -0700 (PDT)
In-Reply-To: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
References: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
Date: Tue, 26 Jun 2012 17:30:29 +0100
Message-ID: <CAPM9MsSn0haiMSK1tFzC_0HSGC1M3ccDex8sy6ibw5BXwOTvKg@mail.gmail.com>
From: "Omer K." <okhalid.cern@gmail.com>
To: xen-users list <xen-users@lists.xensource.com>, 
	xen-devel list <xen-devel@lists.xensource.com>,
	xen-tools@lists.xensource.com
Cc: rolu@roce.org
Subject: Re: [Xen-devel] Unable to make xen tools from xen-unstable 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: okhalid.cern@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3630840264280575649=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3630840264280575649==
Content-Type: multipart/alternative; boundary=e89a8f235485e70a7404c3629d8b

--e89a8f235485e70a7404c3629d8b
Content-Type: text/plain; charset=UTF-8

Hi Rolu,

Thank you for forwarding me with link. I configured xen-unstable with
--enable-githttp flag and it worked.

Thanks
Omer

On Mon, Jun 25, 2012 at 6:17 PM, Omer K. <okhalid.cern@gmail.com> wrote:

> Hi,
>
> I have downloaded the latest  xen-unstable release using mercurial
> repositories. After ./configure, "make xen" successfully builds but "make
> tools" fails after building xen trace package, and fails to download
> seabios.git repository. Following is the output, and any help would be much
> appreciated. Thank you.
>
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cross-install
> -m0644 -p xentrace.8
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/share/man/man8
> make[3]: Leaving directory
> `//scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace'
> make[2]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C xcutils install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
> -d -m0755 -p
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
> -m0755 -p xc_restore xc_save readnotes lsevtchn
> /sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> make[2]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C firmware install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> GIT=git
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh
> git://xenbits.xen.org/seabios.git rel-1.6.3.2 seabios-dir
> Cloning into seabios-dir-remote.tmp...
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> make[2]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make[1]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools'
> linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://
> xenbits.xen.org/seabios.git
> Cloning into seabios...
> fatal: Unable to look up xenbits.xen.org (port 9418) (Name or service not
> known)
>
>

--e89a8f235485e70a7404c3629d8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Rolu,<br><br>Thank you for forwarding me with link. I configured xen-uns=
table with --enable-githttp flag and it worked.<br><br>Thanks<br>Omer<br><b=
r><div class=3D"gmail_quote">On Mon, Jun 25, 2012 at 6:17 PM, Omer K. <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:okhalid.cern@gmail.com" target=3D"_blank=
">okhalid.cern@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">Hi,<br><br>I have downloaded the latest=C2=
=A0 xen-unstable release using mercurial repositories. After ./configure, &=
quot;make xen&quot; successfully builds but &quot;make tools&quot; fails af=
ter building xen trace package, and fails to download seabios.git repositor=
y. Following is the output, and any help would be much appreciated. Thank y=
ou.<br>

<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cr=
oss-install -m0644 -p xentrace.8 /scratch/xen-unstable4.2/xen-unstable-4.2/=
dist/install/usr/share/man/man8<br>make[3]: Leaving directory `//scratch/xe=
n-unstable4.2/xen-unstable-4.2/tools/xentrace&#39;<br>

make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
&#39;<br>make[2]: Entering directory `/scratch/xen-unstable4.2/xen-unstable=
-4.2/tools&#39;<br>make -C xcutils install<br>make[3]: Entering directory `=
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils&#39;<br>

/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-i=
nstall -d -m0755 -p /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/=
usr/lib/xen/bin<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/=
../../tools/cross-install -m0755 -p xc_restore xc_save readnotes lsevtchn /=
sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bi=
n<br>

make[3]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
/xcutils&#39;<br>make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-u=
nstable-4.2/tools&#39;<br>make[2]: Entering directory `/scratch/xen-unstabl=
e4.2/xen-unstable-4.2/tools&#39;<br>

make -C firmware install<br>make[3]: Entering directory `/scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware&#39;<br>GIT=3Dgit /scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh git://=
<a href=3D"http://xenbits.xen.org/seabios.git" target=3D"_blank">xenbits.xe=
n.org/seabios.git</a> rel-1.6.3.2 seabios-dir<br>

Cloning into seabios-dir-remote.tmp...<br>make[3]: Leaving directory `/scra=
tch/xen-unstable4.2/xen-unstable-4.2/tools/firmware&#39;<br>make[2]: Leavin=
g directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<br>make[1=
]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<b=
r>

linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://<a h=
ref=3D"http://xenbits.xen.org/seabios.git" target=3D"_blank">xenbits.xen.or=
g/seabios.git</a><br>Cloning into seabios...<br><span style=3D"background-c=
olor:rgb(255,255,51)">fatal: Unable to look up <a href=3D"http://xenbits.xe=
n.org" target=3D"_blank">xenbits.xen.org</a> (port 9418) (Name or service n=
ot known)</span><br>

<br>
</blockquote></div><br>

--e89a8f235485e70a7404c3629d8b--


--===============3630840264280575649==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3630840264280575649==--


From xen-devel-bounces@lists.xen.org Tue Jun 26 16:30:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYf2-00018s-Bs; Tue, 26 Jun 2012 16:30:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <okhalid.cern@gmail.com>) id 1SjYf1-00018V-0J
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 16:30:39 +0000
Received: from [85.158.143.35:36115] by server-3.bemta-4.messagelabs.com id
	3B/25-05808-EA3E9EF4; Tue, 26 Jun 2012 16:30:38 +0000
X-Env-Sender: okhalid.cern@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340728230!11093163!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12114 invoked from network); 26 Jun 2012 16:30:32 -0000
Received: from mail-gg0-f171.google.com (HELO mail-gg0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:30:32 -0000
Received: by ggmi1 with SMTP id i1so130878ggm.30
	for <multiple recipients>; Tue, 26 Jun 2012 09:30:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=tu1+d7+QldrSga9TPvsc1QH14Qm7KVjZyJDLCXFVDI0=;
	b=v8PCMAC+vVrS2167UaXGdScVya7F2t71Yrmhd/9Qk2ZbtNELOCVGEg9dG9k6kRStBp
	53ch5U3b9yCQAH4jX+ozEV57qEfpNX/eVTRmuLBVE56XL+JbHLBlvSnrAZJqQcBeI/VM
	8C8Hv3pUK1xDCYWU6sC7bA0XidnfHH8r8JrBbiwWmgrbIOROSeRi3UvK6E7vZ0gRrYxg
	fIhjYYCvsGGlimPFZbBlCm5mwVlp077HbMFk8KEsm/08W9sq93p80kAJWUr2/QdgprsQ
	EfSiOUyfkSrQHpRm6E/eRtSfsMoD7EjA9VW63NjNb7V9L7QI+yxKMWkuFtF6z5tvbjhM
	OA7g==
MIME-Version: 1.0
Received: by 10.50.94.166 with SMTP id dd6mr11665892igb.11.1340728230217; Tue,
	26 Jun 2012 09:30:30 -0700 (PDT)
Received: by 10.231.174.84 with HTTP; Tue, 26 Jun 2012 09:30:29 -0700 (PDT)
In-Reply-To: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
References: <CAPM9MsTVyxm+vVNFAK1YkL4Z3SGeKcQg-Op_q22sD6B4XFOssg@mail.gmail.com>
Date: Tue, 26 Jun 2012 17:30:29 +0100
Message-ID: <CAPM9MsSn0haiMSK1tFzC_0HSGC1M3ccDex8sy6ibw5BXwOTvKg@mail.gmail.com>
From: "Omer K." <okhalid.cern@gmail.com>
To: xen-users list <xen-users@lists.xensource.com>, 
	xen-devel list <xen-devel@lists.xensource.com>,
	xen-tools@lists.xensource.com
Cc: rolu@roce.org
Subject: Re: [Xen-devel] Unable to make xen tools from xen-unstable 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: okhalid.cern@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3630840264280575649=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3630840264280575649==
Content-Type: multipart/alternative; boundary=e89a8f235485e70a7404c3629d8b

--e89a8f235485e70a7404c3629d8b
Content-Type: text/plain; charset=UTF-8

Hi Rolu,

Thank you for forwarding me with link. I configured xen-unstable with
--enable-githttp flag and it worked.

Thanks
Omer

On Mon, Jun 25, 2012 at 6:17 PM, Omer K. <okhalid.cern@gmail.com> wrote:

> Hi,
>
> I have downloaded the latest  xen-unstable release using mercurial
> repositories. After ./configure, "make xen" successfully builds but "make
> tools" fails after building xen trace package, and fails to download
> seabios.git repository. Following is the output, and any help would be much
> appreciated. Thank you.
>
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cross-install
> -m0644 -p xentrace.8
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/share/man/man8
> make[3]: Leaving directory
> `//scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace'
> make[2]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C xcutils install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
> -d -m0755 -p
> /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-install
> -m0755 -p xc_restore xc_save readnotes lsevtchn
> /sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bin
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils'
> make[2]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make[2]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make -C firmware install
> make[3]: Entering directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> GIT=git
> /scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh
> git://xenbits.xen.org/seabios.git rel-1.6.3.2 seabios-dir
> Cloning into seabios-dir-remote.tmp...
> make[3]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools/firmware'
> make[2]: Leaving directory
> `/scratch/xen-unstable4.2/xen-unstable-4.2/tools'
> make[1]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools'
> linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://
> xenbits.xen.org/seabios.git
> Cloning into seabios...
> fatal: Unable to look up xenbits.xen.org (port 9418) (Name or service not
> known)
>
>

--e89a8f235485e70a7404c3629d8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Rolu,<br><br>Thank you for forwarding me with link. I configured xen-uns=
table with --enable-githttp flag and it worked.<br><br>Thanks<br>Omer<br><b=
r><div class=3D"gmail_quote">On Mon, Jun 25, 2012 at 6:17 PM, Omer K. <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:okhalid.cern@gmail.com" target=3D"_blank=
">okhalid.cern@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">Hi,<br><br>I have downloaded the latest=C2=
=A0 xen-unstable release using mercurial repositories. After ./configure, &=
quot;make xen&quot; successfully builds but &quot;make tools&quot; fails af=
ter building xen trace package, and fails to download seabios.git repositor=
y. Following is the output, and any help would be much appreciated. Thank y=
ou.<br>

<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xentrace/../../tools/cr=
oss-install -m0644 -p xentrace.8 /scratch/xen-unstable4.2/xen-unstable-4.2/=
dist/install/usr/share/man/man8<br>make[3]: Leaving directory `//scratch/xe=
n-unstable4.2/xen-unstable-4.2/tools/xentrace&#39;<br>

make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
&#39;<br>make[2]: Entering directory `/scratch/xen-unstable4.2/xen-unstable=
-4.2/tools&#39;<br>make -C xcutils install<br>make[3]: Entering directory `=
/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils&#39;<br>

/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/../../tools/cross-i=
nstall -d -m0755 -p /scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/=
usr/lib/xen/bin<br>/scratch/xen-unstable4.2/xen-unstable-4.2/tools/xcutils/=
../../tools/cross-install -m0755 -p xc_restore xc_save readnotes lsevtchn /=
sapmnt/scratch/xen-unstable4.2/xen-unstable-4.2/dist/install/usr/lib/xen/bi=
n<br>

make[3]: Leaving directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools=
/xcutils&#39;<br>make[2]: Leaving directory `/scratch/xen-unstable4.2/xen-u=
nstable-4.2/tools&#39;<br>make[2]: Entering directory `/scratch/xen-unstabl=
e4.2/xen-unstable-4.2/tools&#39;<br>

make -C firmware install<br>make[3]: Entering directory `/scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware&#39;<br>GIT=3Dgit /scratch/xen-unsta=
ble4.2/xen-unstable-4.2/tools/firmware/../../scripts/git-checkout.sh git://=
<a href=3D"http://xenbits.xen.org/seabios.git" target=3D"_blank">xenbits.xe=
n.org/seabios.git</a> rel-1.6.3.2 seabios-dir<br>

Cloning into seabios-dir-remote.tmp...<br>make[3]: Leaving directory `/scra=
tch/xen-unstable4.2/xen-unstable-4.2/tools/firmware&#39;<br>make[2]: Leavin=
g directory `/scratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<br>make[1=
]: Leaving directory `/cratch/xen-unstable4.2/xen-unstable-4.2/tools&#39;<b=
r>

linux-8shx:/scratch/xen-unstable4.2/xen-unstable-4.2 # git clone git://<a h=
ref=3D"http://xenbits.xen.org/seabios.git" target=3D"_blank">xenbits.xen.or=
g/seabios.git</a><br>Cloning into seabios...<br><span style=3D"background-c=
olor:rgb(255,255,51)">fatal: Unable to look up <a href=3D"http://xenbits.xe=
n.org" target=3D"_blank">xenbits.xen.org</a> (port 9418) (Name or service n=
ot known)</span><br>

<br>
</blockquote></div><br>

--e89a8f235485e70a7404c3629d8b--


--===============3630840264280575649==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3630840264280575649==--


From xen-devel-bounces@lists.xen.org Tue Jun 26 16:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYfO-0001Cw-Gc; Tue, 26 Jun 2012 16:31:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjYfN-0001Cf-C3
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:31:01 +0000
Received: from [193.109.254.147:40647] by server-3.bemta-14.messagelabs.com id
	04/2F-08687-4C3E9EF4; Tue, 26 Jun 2012 16:31:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340728258!8686719!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21629 invoked from network); 26 Jun 2012 16:30:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16: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.213.0;
	Tue, 26 Jun 2012 17:30:51 +0100
Message-ID: <1340728250.3832.171.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 17:30:50 +0100
In-Reply-To: <20457.58182.205340.801355@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20457.58182.205340.801355@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 17:28 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> > And make all the required infrastructure updates to enable this.
> 
> > diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
> > --- a/tools/libxl/idl.txt
> > +++ b/tools/libxl/idl.txt
> > @@ -145,12 +145,24 @@ idl.KeyedUnion
> >  
> >   A subclass of idl.Aggregate which represents the C union type
> >   where the currently valid member of the union can be determined based
> > - upon another member in the containing type.
> > + upon another member in the containing type. An idl.KeyedUnion must
> > + always be a member of a containing idl.Aggregate type.
> >  
> > - The KeyedUnion.keyvar contains an idl.type the member of the
> > + The KeyedUnion.keyvar contains an idl.Type the member of the
> >   containing type which determines the valid member of the union. The
> >   must be an instance of the Enumeration type.
> 
> Something seems to have been mangled here in this sentence (although
> all your patch does is change the case of the name).
> 
> > +idl.Array
> > +
> > +  A class representing an array or similar elements. An idl.Array must
>                                    ^^
> of.
> 
> > +  always be an idl.Field of a containing idl.Aggregate.
> > +
> > +  idl.Array.elem_type contains an idl.Type which is the type of all
> > +  elements of the array.
> 
> More natural in English would be, I think, "... the type of each
> element of the array".
> 
> > +  idl.Array.len_var contains an idl.Field which is added to the parent
> > +  idl.Aggregate and will contain the length of the array.
> 
> I think you should explicitly say that len_var MUST be a field named
> "num_XXX" where the original field is named XXX, as previously stated.
> 
> In the future this will probably be enforced by the idl compiler.
> 
> 
> Aside from that,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

Dario, since this is my patch do you want me to address the above and
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 Jun 26 16:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYfO-0001Cw-Gc; Tue, 26 Jun 2012 16:31:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjYfN-0001Cf-C3
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:31:01 +0000
Received: from [193.109.254.147:40647] by server-3.bemta-14.messagelabs.com id
	04/2F-08687-4C3E9EF4; Tue, 26 Jun 2012 16:31:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340728258!8686719!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21629 invoked from network); 26 Jun 2012 16:30:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16: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.213.0;
	Tue, 26 Jun 2012 17:30:51 +0100
Message-ID: <1340728250.3832.171.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 17:30:50 +0100
In-Reply-To: <20457.58182.205340.801355@mariner.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20457.58182.205340.801355@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 17:28 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the IDL"):
> > And make all the required infrastructure updates to enable this.
> 
> > diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
> > --- a/tools/libxl/idl.txt
> > +++ b/tools/libxl/idl.txt
> > @@ -145,12 +145,24 @@ idl.KeyedUnion
> >  
> >   A subclass of idl.Aggregate which represents the C union type
> >   where the currently valid member of the union can be determined based
> > - upon another member in the containing type.
> > + upon another member in the containing type. An idl.KeyedUnion must
> > + always be a member of a containing idl.Aggregate type.
> >  
> > - The KeyedUnion.keyvar contains an idl.type the member of the
> > + The KeyedUnion.keyvar contains an idl.Type the member of the
> >   containing type which determines the valid member of the union. The
> >   must be an instance of the Enumeration type.
> 
> Something seems to have been mangled here in this sentence (although
> all your patch does is change the case of the name).
> 
> > +idl.Array
> > +
> > +  A class representing an array or similar elements. An idl.Array must
>                                    ^^
> of.
> 
> > +  always be an idl.Field of a containing idl.Aggregate.
> > +
> > +  idl.Array.elem_type contains an idl.Type which is the type of all
> > +  elements of the array.
> 
> More natural in English would be, I think, "... the type of each
> element of the array".
> 
> > +  idl.Array.len_var contains an idl.Field which is added to the parent
> > +  idl.Aggregate and will contain the length of the array.
> 
> I think you should explicitly say that len_var MUST be a field named
> "num_XXX" where the original field is named XXX, as previously stated.
> 
> In the future this will probably be enforced by the idl compiler.
> 
> 
> Aside from that,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

Dario, since this is my patch do you want me to address the above and
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 Jun 26 16:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYh5-0001Wi-0D; Tue, 26 Jun 2012 16:32:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SjYh3-0001WR-OK
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:32:45 +0000
Received: from [85.158.143.99:35085] by server-1.bemta-4.messagelabs.com id
	8A/AF-24392-D24E9EF4; Tue, 26 Jun 2012 16:32:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340728364!22856922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27696 invoked from network); 26 Jun 2012 16:32:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:32:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:32:44 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:32:43 +0100
Message-ID: <4FE9E429.4040105@citrix.com>
Date: Tue, 26 Jun 2012 17:32:41 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-4-git-send-email-roger.pau@citrix.com>
	<20434.6341.292944.748723@mariner.uk.xensource.com>
	<4FD72FD2.3040008@citrix.com>
In-Reply-To: <4FD72FD2.3040008@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES
 and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
> Ian Jackson wrote:
>> Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
>>> Parse those options correctly, since the "+=" operator is not valid.
>>> Also added CPPFLAGS, so headers checks don't give strange results.
>> ...
>>>    CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
>>> +CPPFLAGS="$CFLAGS"
>
> Without this I get the following (harmless but noisy) error:
>
> checking yajl/yajl_version.h usability... yes
> checking yajl/yajl_version.h presence... no
> configure: WARNING: yajl/yajl_version.h: accepted by the compiler,
> rejected by the preprocessor!
> configure: WARNING: yajl/yajl_version.h: proceeding with the compiler's
> result
>
>> Surely that can't be right.
>
>    From http://www.edwardrosten.com/code/autoconf/:
>
> "Just append stuff to CFLAGS (for the C compiler), CPPFLAGS (for the C
> preprocessor, C and C++ compilers), CXXFLAGS (for the C++ compiler) and
> LIBS (for the linker)."
>
> It seems like the preprocessor check uses CPPFLAGS instead of CFLAGS, so
> we have to set both.

Any news on this one?

Thanks, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjYh5-0001Wi-0D; Tue, 26 Jun 2012 16:32:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SjYh3-0001WR-OK
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:32:45 +0000
Received: from [85.158.143.99:35085] by server-1.bemta-4.messagelabs.com id
	8A/AF-24392-D24E9EF4; Tue, 26 Jun 2012 16:32:45 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340728364!22856922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27696 invoked from network); 26 Jun 2012 16:32:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:32:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="13230259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:32:44 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:32:43 +0100
Message-ID: <4FE9E429.4040105@citrix.com>
Date: Tue, 26 Jun 2012 17:32:41 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com>
	<1336745632-28158-4-git-send-email-roger.pau@citrix.com>
	<20434.6341.292944.748723@mariner.uk.xensource.com>
	<4FD72FD2.3040008@citrix.com>
In-Reply-To: <4FD72FD2.3040008@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES
 and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
> Ian Jackson wrote:
>> Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
>>> Parse those options correctly, since the "+=" operator is not valid.
>>> Also added CPPFLAGS, so headers checks don't give strange results.
>> ...
>>>    CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
>>> +CPPFLAGS="$CFLAGS"
>
> Without this I get the following (harmless but noisy) error:
>
> checking yajl/yajl_version.h usability... yes
> checking yajl/yajl_version.h presence... no
> configure: WARNING: yajl/yajl_version.h: accepted by the compiler,
> rejected by the preprocessor!
> configure: WARNING: yajl/yajl_version.h: proceeding with the compiler's
> result
>
>> Surely that can't be right.
>
>    From http://www.edwardrosten.com/code/autoconf/:
>
> "Just append stuff to CFLAGS (for the C compiler), CPPFLAGS (for the C
> preprocessor, C and C++ compilers), CXXFLAGS (for the C++ compiler) and
> LIBS (for the linker)."
>
> It seems like the preprocessor check uses CPPFLAGS instead of CFLAGS, so
> we have to set both.

Any news on this one?

Thanks, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:49:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYwf-0002lg-0u; Tue, 26 Jun 2012 16:48: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 1SjYwd-0002lb-8W
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:48:51 +0000
Received: from [85.158.139.83:8300] by server-7.bemta-5.messagelabs.com id
	E9/F3-28276-2F7E9EF4; Tue, 26 Jun 2012 16:48:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340729329!29622895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17986 invoked from network); 26 Jun 2012 16:48:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:48:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:48:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:48:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjYwa-000081-VN; Tue, 26 Jun 2012 16:48:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjYwa-0005fU-UW;
	Tue, 26 Jun 2012 17:48:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.59376.933498.174210@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 17:48:48 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340365656.26083.98.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
	<1340365656.26083.98.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for asynchrony"):
> 
> > @@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
> >      return ptr;
> >  }
> >
> > +static void remus_crashed_cb(libxl__egc *egc,
> > +                             libxl__domain_suspend_state *dss, int rc);
> 
> I think you were going to rename this remus_failover_cb but
> nevertheless:

Yes, that's done in my tree.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> Were you going to ping Shriram to test remus with this series applied?

That's a good idea.  I will do that on my next repost.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:49:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjYwf-0002lg-0u; Tue, 26 Jun 2012 16:48: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 1SjYwd-0002lb-8W
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:48:51 +0000
Received: from [85.158.139.83:8300] by server-7.bemta-5.messagelabs.com id
	E9/F3-28276-2F7E9EF4; Tue, 26 Jun 2012 16:48:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340729329!29622895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17986 invoked from network); 26 Jun 2012 16:48:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:48:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:48:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:48:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjYwa-000081-VN; Tue, 26 Jun 2012 16:48:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjYwa-0005fU-UW;
	Tue, 26 Jun 2012 17:48:48 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.59376.933498.174210@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 17:48:48 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340365656.26083.98.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-6-git-send-email-ian.jackson@eu.citrix.com>
	<1340365656.26083.98.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
 asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for asynchrony"):
> 
> > @@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
> >      return ptr;
> >  }
> >
> > +static void remus_crashed_cb(libxl__egc *egc,
> > +                             libxl__domain_suspend_state *dss, int rc);
> 
> I think you were going to rename this remus_failover_cb but
> nevertheless:

Yes, that's done in my tree.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> Were you going to ping Shriram to test remus with this series applied?

That's a good idea.  I will do that on my next repost.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:52:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:52: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 1SjZ07-0002uv-Lw; Tue, 26 Jun 2012 16:52: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 1SjZ05-0002um-Kz
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:52:25 +0000
Received: from [85.158.138.51:40420] by server-7.bemta-3.messagelabs.com id
	32/02-10113-8C8E9EF4; Tue, 26 Jun 2012 16:52:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340729543!29696308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11429 invoked from network); 26 Jun 2012 16:52:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:52:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:52:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:52:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZ03-00009P-ID; Tue, 26 Jun 2012 16:52:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZ03-0005hN-HH;
	Tue, 26 Jun 2012 17:52:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.59591.521215.399771@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 17:52:23 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340366346.26083.103.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
	<1340366346.26083.103.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 06/21] libxl: domain save/restore: run in a separate process"):
> > [...]
> > +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> > +    if (!pid) {
> > +        if (stream_fd <= 2) {
> > +            stream_fd = dup(stream_fd);
> > +            if (stream_fd < 0) {
> > +                LOGE(ERROR,"dup migration stream fd");
> 
> LOGE uses CTX -- is that safe after fork, and will it go anywhere
> anyway?

>From the doc comment for libxl__ev_child_fork:

 * The child should go on to exec (or exit) soon.  The child may not
 * make any further calls to libxl infrastructure, except for memory
 * allocation and logging.  If the child needs to use xenstore it
 * must open its own xs handle and use it directly, rather than via
 * the libxl event machinery.

So this is fine according to the doc comment.  And the doc comment is,
I think, justified.  The logging might go to some file where we share
the descriptor with the parent, but logs are opened with O_APPEND, so
that's fine.  Likewise if it's going to syslog, the socket will be
fine.

That general-purpose xtl loggers need to work in children isn't
explicitly documented in xentoollog.h but I think it's fine to leave
it that way.

> > +                exit(-1);
> > +            }
> > +        }
> > +        libxl_fd_set_cloexec(CTX, stream_fd, 0);
> > +        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
> > +
> > +        for (i=0; i<num_preserve_fds; i++)
> > +            if (preserve_fds[i] >= 0)
> > +                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
> 
> The doc comment says these cannot be 0,1,2. Possibly not worth enforcing
> though.

If this restriction is violated then things are going to go very badly
wrong, so an assertion is probably a good idea.  (This will kill the
migration child, not the parent.)

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:52:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:52: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 1SjZ07-0002uv-Lw; Tue, 26 Jun 2012 16:52: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 1SjZ05-0002um-Kz
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:52:25 +0000
Received: from [85.158.138.51:40420] by server-7.bemta-3.messagelabs.com id
	32/02-10113-8C8E9EF4; Tue, 26 Jun 2012 16:52:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340729543!29696308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11429 invoked from network); 26 Jun 2012 16:52:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 16:52:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 16:52:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 17:52:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZ03-00009P-ID; Tue, 26 Jun 2012 16:52:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZ03-0005hN-HH;
	Tue, 26 Jun 2012 17:52:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.59591.521215.399771@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 17:52:23 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340366346.26083.103.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1339761246-27641-7-git-send-email-ian.jackson@eu.citrix.com>
	<1340366346.26083.103.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 06/21] libxl: domain save/restore: run in a separate process"):
> > [...]
> > +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> > +    if (!pid) {
> > +        if (stream_fd <= 2) {
> > +            stream_fd = dup(stream_fd);
> > +            if (stream_fd < 0) {
> > +                LOGE(ERROR,"dup migration stream fd");
> 
> LOGE uses CTX -- is that safe after fork, and will it go anywhere
> anyway?

>From the doc comment for libxl__ev_child_fork:

 * The child should go on to exec (or exit) soon.  The child may not
 * make any further calls to libxl infrastructure, except for memory
 * allocation and logging.  If the child needs to use xenstore it
 * must open its own xs handle and use it directly, rather than via
 * the libxl event machinery.

So this is fine according to the doc comment.  And the doc comment is,
I think, justified.  The logging might go to some file where we share
the descriptor with the parent, but logs are opened with O_APPEND, so
that's fine.  Likewise if it's going to syslog, the socket will be
fine.

That general-purpose xtl loggers need to work in children isn't
explicitly documented in xentoollog.h but I think it's fine to leave
it that way.

> > +                exit(-1);
> > +            }
> > +        }
> > +        libxl_fd_set_cloexec(CTX, stream_fd, 0);
> > +        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
> > +
> > +        for (i=0; i<num_preserve_fds; i++)
> > +            if (preserve_fds[i] >= 0)
> > +                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
> 
> The doc comment says these cannot be 0,1,2. Possibly not worth enforcing
> though.

If this restriction is violated then things are going to go very badly
wrong, so an assertion is probably a good idea.  (This will kill the
migration child, not the parent.)

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:58:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:58: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 1SjZ5h-00037k-KX; Tue, 26 Jun 2012 16:58:13 +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 1SjZ5g-00037f-Fl
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:58:12 +0000
Received: from [85.158.143.35:31377] by server-2.bemta-4.messagelabs.com id
	DE/FD-17938-32AE9EF4; Tue, 26 Jun 2012 16:58:11 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340729890!13949067!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzIwOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18393 invoked from network); 26 Jun 2012 16:58:10 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jun 2012 16:58:10 -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 7128229EF;
	Tue, 26 Jun 2012 19:58:08 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 929DCEC027; Tue, 26 Jun 2012 19:58:08 +0300 (EEST)
Date: Tue, 26 Jun 2012 19:58:08 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120626165808.GC2058@reaktio.net>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE9E153.1050309@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 05:20:35PM +0100, Roger Pau Monne wrote:
> Ian Jackson wrote:
> >Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
> >>Set the default value for nic interfaces to VIF, since it used to be
> >>IOEMU, even for PV guests.
> >
> >If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
> >HVM guests getting emulated network interfaces by default ?
> 
> Yes, if you want emulated interfaces with HVM guests you should use
> 'type=ioemu', that's how it has always been right?
> 

With Xen 4.1 you don't have to use "type=ioemu". Emulated interfaces seem to work OK without "type=ioemu".
(at least with xm/xend). And if you actually do add "type=ioemu" it will break PVHVM for Linux guests..

Quote from: http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers

"NOTE! If you have "type=ioemu" specified for the "vif"-line, PVHVM drivers WILL NOT work! Don't specify "type" parameter for the vif. (with type=ioemu the pvhvm nic in the VM will have mac address full of zeroes - and thus won't work!). "


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:58:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16:58: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 1SjZ5h-00037k-KX; Tue, 26 Jun 2012 16:58:13 +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 1SjZ5g-00037f-Fl
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:58:12 +0000
Received: from [85.158.143.35:31377] by server-2.bemta-4.messagelabs.com id
	DE/FD-17938-32AE9EF4; Tue, 26 Jun 2012 16:58:11 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340729890!13949067!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzIwOTI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18393 invoked from network); 26 Jun 2012 16:58:10 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jun 2012 16:58:10 -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 7128229EF;
	Tue, 26 Jun 2012 19:58:08 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 929DCEC027; Tue, 26 Jun 2012 19:58:08 +0300 (EEST)
Date: Tue, 26 Jun 2012 19:58:08 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20120626165808.GC2058@reaktio.net>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE9E153.1050309@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 05:20:35PM +0100, Roger Pau Monne wrote:
> Ian Jackson wrote:
> >Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
> >>Set the default value for nic interfaces to VIF, since it used to be
> >>IOEMU, even for PV guests.
> >
> >If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
> >HVM guests getting emulated network interfaces by default ?
> 
> Yes, if you want emulated interfaces with HVM guests you should use
> 'type=ioemu', that's how it has always been right?
> 

With Xen 4.1 you don't have to use "type=ioemu". Emulated interfaces seem to work OK without "type=ioemu".
(at least with xm/xend). And if you actually do add "type=ioemu" it will break PVHVM for Linux guests..

Quote from: http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers

"NOTE! If you have "type=ioemu" specified for the "vif"-line, PVHVM drivers WILL NOT work! Don't specify "type" parameter for the vif. (with type=ioemu the pvhvm nic in the VM will have mac address full of zeroes - and thus won't work!). "


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 16:59:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjZ6I-00039w-1s; Tue, 26 Jun 2012 16:58:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjZ6G-00039m-UN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:58:49 +0000
Received: from [193.109.254.147:31204] by server-4.bemta-14.messagelabs.com id
	EB/38-02077-84AE9EF4; Tue, 26 Jun 2012 16:58:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340729926!8662037!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8290 invoked from network); 26 Jun 2012 16:58:47 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 16:58:47 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79146911; Tue, 26 Jun 2012 18:58:46 +0200
Message-ID: <1340729920.9444.53.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 26 Jun 2012 18:58:40 +0200
In-Reply-To: <1340728250.3832.171.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20457.58182.205340.801355@mariner.uk.xensource.com>
	<1340728250.3832.171.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8023514697065185416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8023514697065185416==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-DR+lul8xboY0C+rPU1Xl"


--=-DR+lul8xboY0C+rPU1Xl
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 17:30 +0100, Ian Campbell wrote:
> > Aside from that,
> >=20
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>=20
> Thanks.
>=20
> Dario, since this is my patch do you want me to address the above and
> resend?
>=20
As you wish. If that doesn't bother you too much, I'm fine with that.
Otherwise, I can do it when resending the whole series...

Let's say that, if I don't see the patch on the list when I come to
resend, I'll apply these changes myself, ok?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-DR+lul8xboY0C+rPU1Xl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p6kAACgkQk4XaBE3IOsRbGQCeO5exQNFy2sLKqQoD1dCZC1m2
KMoAn1O4X9O55oieWp69mRnvhHN5AnVf
=BgQA
-----END PGP SIGNATURE-----

--=-DR+lul8xboY0C+rPU1Xl--



--===============8023514697065185416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8023514697065185416==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 16:59:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 16: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 1SjZ6I-00039w-1s; Tue, 26 Jun 2012 16:58:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjZ6G-00039m-UN
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 16:58:49 +0000
Received: from [193.109.254.147:31204] by server-4.bemta-14.messagelabs.com id
	EB/38-02077-84AE9EF4; Tue, 26 Jun 2012 16:58:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340729926!8662037!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8290 invoked from network); 26 Jun 2012 16:58:47 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-27.messagelabs.com with SMTP;
	26 Jun 2012 16:58:47 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79146911; Tue, 26 Jun 2012 18:58:46 +0200
Message-ID: <1340729920.9444.53.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 26 Jun 2012 18:58:40 +0200
In-Reply-To: <1340728250.3832.171.camel@zakaz.uk.xensource.com>
References: <patchbomb.1338466265@Solace>
	<0233305f23816261bb49.1338466270@Solace>
	<20457.58182.205340.801355@mariner.uk.xensource.com>
	<1340728250.3832.171.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05 of 11] libxl: add a new Array type to the
 IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8023514697065185416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8023514697065185416==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-DR+lul8xboY0C+rPU1Xl"


--=-DR+lul8xboY0C+rPU1Xl
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 17:30 +0100, Ian Campbell wrote:
> > Aside from that,
> >=20
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>=20
> Thanks.
>=20
> Dario, since this is my patch do you want me to address the above and
> resend?
>=20
As you wish. If that doesn't bother you too much, I'm fine with that.
Otherwise, I can do it when resending the whole series...

Let's say that, if I don't see the patch on the list when I come to
resend, I'll apply these changes myself, ok?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-DR+lul8xboY0C+rPU1Xl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/p6kAACgkQk4XaBE3IOsRbGQCeO5exQNFy2sLKqQoD1dCZC1m2
KMoAn1O4X9O55oieWp69mRnvhHN5AnVf
=BgQA
-----END PGP SIGNATURE-----

--=-DR+lul8xboY0C+rPU1Xl--



--===============8023514697065185416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8023514697065185416==--



From xen-devel-bounces@lists.xen.org Tue Jun 26 17:01:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjZ8H-0003Ki-Jt; Tue, 26 Jun 2012 17:00:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SjZ8F-0003Ka-NZ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:00:51 +0000
Received: from [85.158.143.35:42208] by server-3.bemta-4.messagelabs.com id
	FA/70-05808-3CAE9EF4; Tue, 26 Jun 2012 17:00:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340730045!14158327!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30398 invoked from network); 26 Jun 2012 17:00:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:00:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:00:22 +0100
Date: Tue, 26 Jun 2012 17:59:56 +0100
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: <1340717554.3832.107.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Ren, Yongjie" <yongjie.ren@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > libxl: set stdvga=1 by default when creating a hvm guest
> > 
> > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x, Ubuntu, Fedora) support VBE 2.0 or later.
> > So, select a standard VGA card with VBE as the default emulated graphics device.
> 
> I'm not expert on the graphics side of HVM, but on the face of it
> switching the default to something more modern seems like a reasonable
> idea, although I'm not sure if we should be doing this for 4.2 at this
> point.
> 
> I've CCd Tim and Stefano for input from the HVM and QEMU sides.

I think it is a good thing.
The only thing to keep in mind is that QEMU upstream is switching to
16MB of videoram for stdvga. So at some point in the near future
upstream QEMU will stop working correctly with xen 4.2, unless we bump
the videoram to 16MB too.


> > It's also a workaround for the following bug.
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> 
> Do you understand the root cause of that bug?
> 
> It's hard to see how detaching a VF relates to the VGA emulation in use.
> Can you explain it? Are you sure you aren't just masking the real issue
> here?

Indeed. We cannot possibly accept the patch on the basis that it looks
like it is masking an unrelated pci-passthrough bug.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:01:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjZ8H-0003Ki-Jt; Tue, 26 Jun 2012 17:00:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SjZ8F-0003Ka-NZ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:00:51 +0000
Received: from [85.158.143.35:42208] by server-3.bemta-4.messagelabs.com id
	FA/70-05808-3CAE9EF4; Tue, 26 Jun 2012 17:00:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340730045!14158327!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30398 invoked from network); 26 Jun 2012 17:00:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:00:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:00:22 +0100
Date: Tue, 26 Jun 2012 17:59:56 +0100
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: <1340717554.3832.107.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Ren, Yongjie" <yongjie.ren@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > libxl: set stdvga=1 by default when creating a hvm guest
> > 
> > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x, Ubuntu, Fedora) support VBE 2.0 or later.
> > So, select a standard VGA card with VBE as the default emulated graphics device.
> 
> I'm not expert on the graphics side of HVM, but on the face of it
> switching the default to something more modern seems like a reasonable
> idea, although I'm not sure if we should be doing this for 4.2 at this
> point.
> 
> I've CCd Tim and Stefano for input from the HVM and QEMU sides.

I think it is a good thing.
The only thing to keep in mind is that QEMU upstream is switching to
16MB of videoram for stdvga. So at some point in the near future
upstream QEMU will stop working correctly with xen 4.2, unless we bump
the videoram to 16MB too.


> > It's also a workaround for the following bug.
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> 
> Do you understand the root cause of that bug?
> 
> It's hard to see how detaching a VF relates to the VGA emulation in use.
> Can you explain it? Are you sure you aren't just masking the real issue
> here?

Indeed. We cannot possibly accept the patch on the basis that it looks
like it is masking an unrelated pci-passthrough bug.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjZEI-0003e4-F2; Tue, 26 Jun 2012 17:07:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZEG-0003dz-TB
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:07:05 +0000
Received: from [193.109.254.147:52440] by server-11.bemta-14.messagelabs.com
	id 02/B6-24843-83CE9EF4; Tue, 26 Jun 2012 17:07:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340730413!6234770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1350 invoked from network); 26 Jun 2012 17:06:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:06:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:06:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:06:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZE4-0000Ii-VQ; Tue, 26 Jun 2012 17:06:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZE4-0005zu-Ua;
	Tue, 26 Jun 2012 18:06:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.60460.687876.481055@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:06:52 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340367778.26083.114.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1340367778.26083.114.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SWFuIENhbXBiZWxsIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggdjMgMDAvMThdIGxp
YnhsOiBkb21haW4gc2F2ZS9yZXN0b3JlOiBydW4gaW4gYSBzZXBhcmF0ZSBwcm9jZXNzIik6Cj4g
T24gRnJpLCAyMDEyLTA2LTE1IGF0IDEyOjUzICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiA+
IFRoaXMgaXMgdjQgb2YgbXkgc2VyaWVzIHRvIGFzeW5jaWZ5IHNhdmUvcmVzdG9yZS4gIEFsbCBj
b21tZW50cyBoYXZlCj4gPiBiZWVuIGFkZHJlc3NlZC4KPiAKPiBCdWlsZGluZyB3aXRoIHRoaXMg
SSBnZXQ6Cj4gICAgICAgICBjYzE6IHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCj4g
ICAgICAgICBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9kb21haW5fZGVzdHJveeKAmToK
PiAgICAgICAgIGxpYnhsLmM6MTIyNDogZXJyb3I6IOKAmGRtX3ByZXNlbnTigJkgbWF5IGJlIHVz
ZWQgdW5pbml0aWFsaXplZCBpbiB0aGlzIGZ1bmN0aW9uCj4gICAgICAgICAKPiBJIGV4cGVjdCBi
ZWNhdXNlIGZvciBzb21lIHJlYXNvbiBnY2MgZG9lc24ndCByZWFsaXNlIHRoYXQgdGhlIHN3aXRj
aAo+IGNvdmVycyBhbGwgcG9zc2libGUgZW51bSB2YWx1ZXMgKHNpbmNlIHRoZSBjYXNlcyBhbGwg
ZWl0aGVyIGluaXRpYWxpc2UKPiBvciBqdW1wIHRvIG91dCB3aGljaCBkb2VzIG5vdCB1c2UgZG1f
cHJlc2VudCkuCgpIb3cgYW5ub3lpbmcuCgo+IEluIG9yZGVyIHRoYXQgSSBjb3VsZCBjb250aW51
ZSB0byB0ZXN0IEkgZGlkIHRoaXM6Cj4gCj4gZGlmZiAtciBmY2ExMzMwZmEzNjcgdG9vbHMvbGli
eGwvbGlieGwuYwo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMJRnJpIEp1biAyMiAxMzoxOToy
MiAyMDEyICswMTAwCj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwlGcmkgSnVuIDIyIDEzOjIy
OjI1IDIwMTIgKzAxMDAKPiBAQCAtMTI0NCw2ICsxMjQ0LDcgQEAgaW50IGxpYnhsX2RvbWFpbl9k
ZXN0cm95KGxpYnhsX2N0eCAqY3R4LAo+ICAgICAgY2FzZSBMSUJYTF9ET01BSU5fVFlQRV9JTlZB
TElEOgo+ICAgICAgICAgIHJjID0gRVJST1JfRkFJTDsKPiAgICAgICAgICBnb3RvIG91dDsKPiAr
ICAgIGRlZmF1bHQ6IGFib3J0KCk7Cj4gICAgICB9Cj4gIAo+ICAgICAgZG9tX3BhdGggPSBsaWJ4
bF9feHNfZ2V0X2RvbXBhdGgoZ2MsIGRvbWlkKTsKPiAKPiBidXQgeW91IG1pZ2h0IGhhdmUgYSBi
ZXR0ZXIgcHJlZmVyZW5jZS4KClRoYW5rcywgSSBoYXZlIGRvbmUgdGhhdC4KCklhbi4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjZEI-0003e4-F2; Tue, 26 Jun 2012 17:07:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZEG-0003dz-TB
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:07:05 +0000
Received: from [193.109.254.147:52440] by server-11.bemta-14.messagelabs.com
	id 02/B6-24843-83CE9EF4; Tue, 26 Jun 2012 17:07:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340730413!6234770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1350 invoked from network); 26 Jun 2012 17:06:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:06:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13230824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:06:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:06:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZE4-0000Ii-VQ; Tue, 26 Jun 2012 17:06:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZE4-0005zu-Ua;
	Tue, 26 Jun 2012 18:06:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.60460.687876.481055@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:06:52 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340367778.26083.114.camel@zakaz.uk.xensource.com>
References: <1339761246-27641-1-git-send-email-ian.jackson@eu.citrix.com>
	<1340367778.26083.114.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3 00/18] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SWFuIENhbXBiZWxsIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggdjMgMDAvMThdIGxp
YnhsOiBkb21haW4gc2F2ZS9yZXN0b3JlOiBydW4gaW4gYSBzZXBhcmF0ZSBwcm9jZXNzIik6Cj4g
T24gRnJpLCAyMDEyLTA2LTE1IGF0IDEyOjUzICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiA+
IFRoaXMgaXMgdjQgb2YgbXkgc2VyaWVzIHRvIGFzeW5jaWZ5IHNhdmUvcmVzdG9yZS4gIEFsbCBj
b21tZW50cyBoYXZlCj4gPiBiZWVuIGFkZHJlc3NlZC4KPiAKPiBCdWlsZGluZyB3aXRoIHRoaXMg
SSBnZXQ6Cj4gICAgICAgICBjYzE6IHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCj4g
ICAgICAgICBsaWJ4bC5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4bF9kb21haW5fZGVzdHJveeKAmToK
PiAgICAgICAgIGxpYnhsLmM6MTIyNDogZXJyb3I6IOKAmGRtX3ByZXNlbnTigJkgbWF5IGJlIHVz
ZWQgdW5pbml0aWFsaXplZCBpbiB0aGlzIGZ1bmN0aW9uCj4gICAgICAgICAKPiBJIGV4cGVjdCBi
ZWNhdXNlIGZvciBzb21lIHJlYXNvbiBnY2MgZG9lc24ndCByZWFsaXNlIHRoYXQgdGhlIHN3aXRj
aAo+IGNvdmVycyBhbGwgcG9zc2libGUgZW51bSB2YWx1ZXMgKHNpbmNlIHRoZSBjYXNlcyBhbGwg
ZWl0aGVyIGluaXRpYWxpc2UKPiBvciBqdW1wIHRvIG91dCB3aGljaCBkb2VzIG5vdCB1c2UgZG1f
cHJlc2VudCkuCgpIb3cgYW5ub3lpbmcuCgo+IEluIG9yZGVyIHRoYXQgSSBjb3VsZCBjb250aW51
ZSB0byB0ZXN0IEkgZGlkIHRoaXM6Cj4gCj4gZGlmZiAtciBmY2ExMzMwZmEzNjcgdG9vbHMvbGli
eGwvbGlieGwuYwo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMJRnJpIEp1biAyMiAxMzoxOToy
MiAyMDEyICswMTAwCj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwlGcmkgSnVuIDIyIDEzOjIy
OjI1IDIwMTIgKzAxMDAKPiBAQCAtMTI0NCw2ICsxMjQ0LDcgQEAgaW50IGxpYnhsX2RvbWFpbl9k
ZXN0cm95KGxpYnhsX2N0eCAqY3R4LAo+ICAgICAgY2FzZSBMSUJYTF9ET01BSU5fVFlQRV9JTlZB
TElEOgo+ICAgICAgICAgIHJjID0gRVJST1JfRkFJTDsKPiAgICAgICAgICBnb3RvIG91dDsKPiAr
ICAgIGRlZmF1bHQ6IGFib3J0KCk7Cj4gICAgICB9Cj4gIAo+ICAgICAgZG9tX3BhdGggPSBsaWJ4
bF9feHNfZ2V0X2RvbXBhdGgoZ2MsIGRvbWlkKTsKPiAKPiBidXQgeW91IG1pZ2h0IGhhdmUgYSBi
ZXR0ZXIgcHJlZmVyZW5jZS4KClRoYW5rcywgSSBoYXZlIGRvbmUgdGhhdC4KCklhbi4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:19:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZQQ-0003o4-Nw; Tue, 26 Jun 2012 17:19: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 1SjZQP-0003nz-0P
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:19:37 +0000
Received: from [85.158.138.51:10596] by server-11.bemta-3.messagelabs.com id
	14/C0-02904-82FE9EF4; Tue, 26 Jun 2012 17:19:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340731175!20745647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8873 invoked from network); 26 Jun 2012 17:19:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:19:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:19:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZQL-0000Qx-PU; Tue, 26 Jun 2012 17:19:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZQL-000613-OV;
	Tue, 26 Jun 2012 18:19:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61221.744769.779520@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:19:33 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE9CF7D.3060403@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
	<4FE9CF7D.3060403@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 v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op"):
> Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH v6 06/13] libxl: convert libxl_device_disk_a
> > Is it really safe to call libxl__device_disk_add without a real
> > transaction ?  I see that the current code does it but it seems wrong
> > to me.  We end up writing all of the individual settings in the
> > backend one at a time.
> 
> Well, this is not really my code, this was part of Stefanos series about 
> local disk attach. However, I don't see how we end up writing them one 
> at a time, libxl__device_generic_add creates a transaction if none is 
> given, so all backend and frontend entries are added at the same 
> transaction. Calling libxl__device_disk_add without a transaction 
> behaves just like it did previously.

Oh, right, that's OK then.  Sorry for missing that.

> > I think this applies to all the other device types too.  So I think
> > the right answer would be to make them take a transaction parameter
> > too.  Ie, insert a patch before this one which adds a transaction
> > parameter (ignored for now and always passed 0 if you don't want to
> > actually make it work properly) to libxl__add_nic etc.  Then you don't
> > need this unpleasant macro.
> 
> Ok, I will add this patch that makes all device_*_add take a transaction 
> parameter, although it will be ignored right now.

Right.  (You could pass it through to device_generic_add if that was
easy.)

> >> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
> >> +{
> >> +    STATE_AO_GC(aodev->ao);
> >> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
> >> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> >> +    int rc = 0;
> > ...
> >> +out_fail:
> >> +    assert(rc);
> >> +    aodev->rc = rc;
> >> +    device_xsentries_remove(egc, aodev);
> >> +    return;
> >> +}
> >
> > Firstly, I'm not convinced it's really proper for
> > libxl__initiate_device_connection to call device_xsentries_remove.
> > After all device_xsentries_remove is part of the implementation of
> > libxl__initiate_device_remove.
> 
> This is part of both flows, both device connection and disconnection.

Well then it should have a proper description and a better name,
perhaps ?  As it is it looks like you're doing what amounts to "goto"
from one "function" to another - only we don't notice it like that
because it's split into multiple ao callbacks.

> > And, secondly, does device_xsentries_remove really do what you want ?
> > It has a test in it which makes it only do its work if action is
> > DISCONNECT.
> 
> Yes, that's because it's called by both flows.

If it is called in the connect flow, won't it be a no-op then ?
Perhaps I'm being excessively dense here.


> > Isn't the effect of this that if the xs transaction gets a conflict,
> > we'll rerun the hotplug scripts, etc. ?  I think I may be confused
> > here, but I don't understand how this transaction loop is supposed to
> > work and how it is supposed to relate to the interaction with other
> > domains, scripts, etc.
> 
> Yes I see your point. We should disconnect the device (execute hotplug 
> scripts) but since the xenstore entries are already gone (because the 
> transaction is not committed successfully) I don't see anyway to do it, 
> we cannot execute those scripts if the backend entries have been lost.
> 
> > Indeed it seems to me like your arrangements in libxl__device_disk_add
> > couldn't work if a non-null t was supplied.  libxl__device_disk_add
> > would do all the writes in the transaction, but not commit it, so that
> > none of them are visible to anyone, and then wait for the deivde state
> > to change, which will never happen.
> 
> I'm not so sure, is it possible to add a watch to a xenstore path that 
> is inside of a not yet committed transaction? If so this will work fine, 
> the transaction will be finished correctly, and the path will be updated 
> to the correct state (2).

AIUI you can add a watch for any path that you like - the path you ask
to watch doesn't have to exist.  But you won't (necessarily) see
events for uncommitted transactions.

> If the transaction is not committed successfully, we will get a timeout 
> from the devstate event and exit.

I think that the only way all this could work is if you firstly, in
one transaction, create enough of the backend for the hotplug scripts
to run, and then in a second transaction create the rest of the
backend plus the frontend.

> > I think this code is a symptom of a problem elsewhere.  When adding a
> > disk to a domain, it should not be necessary to explicitly ask to add
> > it to the stubdom too.  But this is not your fault, or your problem
> > right now.
> 
> So I assume we can leave this for later.

Yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:19:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZQQ-0003o4-Nw; Tue, 26 Jun 2012 17:19: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 1SjZQP-0003nz-0P
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:19:37 +0000
Received: from [85.158.138.51:10596] by server-11.bemta-3.messagelabs.com id
	14/C0-02904-82FE9EF4; Tue, 26 Jun 2012 17:19:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340731175!20745647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8873 invoked from network); 26 Jun 2012 17:19:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:19:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:19:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZQL-0000Qx-PU; Tue, 26 Jun 2012 17:19:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZQL-000613-OV;
	Tue, 26 Jun 2012 18:19:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61221.744769.779520@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:19:33 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE9CF7D.3060403@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
	<4FE9CF7D.3060403@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 v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op"):
> Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH v6 06/13] libxl: convert libxl_device_disk_a
> > Is it really safe to call libxl__device_disk_add without a real
> > transaction ?  I see that the current code does it but it seems wrong
> > to me.  We end up writing all of the individual settings in the
> > backend one at a time.
> 
> Well, this is not really my code, this was part of Stefanos series about 
> local disk attach. However, I don't see how we end up writing them one 
> at a time, libxl__device_generic_add creates a transaction if none is 
> given, so all backend and frontend entries are added at the same 
> transaction. Calling libxl__device_disk_add without a transaction 
> behaves just like it did previously.

Oh, right, that's OK then.  Sorry for missing that.

> > I think this applies to all the other device types too.  So I think
> > the right answer would be to make them take a transaction parameter
> > too.  Ie, insert a patch before this one which adds a transaction
> > parameter (ignored for now and always passed 0 if you don't want to
> > actually make it work properly) to libxl__add_nic etc.  Then you don't
> > need this unpleasant macro.
> 
> Ok, I will add this patch that makes all device_*_add take a transaction 
> parameter, although it will be ignored right now.

Right.  (You could pass it through to device_generic_add if that was
easy.)

> >> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
> >> +{
> >> +    STATE_AO_GC(aodev->ao);
> >> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
> >> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
> >> +    int rc = 0;
> > ...
> >> +out_fail:
> >> +    assert(rc);
> >> +    aodev->rc = rc;
> >> +    device_xsentries_remove(egc, aodev);
> >> +    return;
> >> +}
> >
> > Firstly, I'm not convinced it's really proper for
> > libxl__initiate_device_connection to call device_xsentries_remove.
> > After all device_xsentries_remove is part of the implementation of
> > libxl__initiate_device_remove.
> 
> This is part of both flows, both device connection and disconnection.

Well then it should have a proper description and a better name,
perhaps ?  As it is it looks like you're doing what amounts to "goto"
from one "function" to another - only we don't notice it like that
because it's split into multiple ao callbacks.

> > And, secondly, does device_xsentries_remove really do what you want ?
> > It has a test in it which makes it only do its work if action is
> > DISCONNECT.
> 
> Yes, that's because it's called by both flows.

If it is called in the connect flow, won't it be a no-op then ?
Perhaps I'm being excessively dense here.


> > Isn't the effect of this that if the xs transaction gets a conflict,
> > we'll rerun the hotplug scripts, etc. ?  I think I may be confused
> > here, but I don't understand how this transaction loop is supposed to
> > work and how it is supposed to relate to the interaction with other
> > domains, scripts, etc.
> 
> Yes I see your point. We should disconnect the device (execute hotplug 
> scripts) but since the xenstore entries are already gone (because the 
> transaction is not committed successfully) I don't see anyway to do it, 
> we cannot execute those scripts if the backend entries have been lost.
> 
> > Indeed it seems to me like your arrangements in libxl__device_disk_add
> > couldn't work if a non-null t was supplied.  libxl__device_disk_add
> > would do all the writes in the transaction, but not commit it, so that
> > none of them are visible to anyone, and then wait for the deivde state
> > to change, which will never happen.
> 
> I'm not so sure, is it possible to add a watch to a xenstore path that 
> is inside of a not yet committed transaction? If so this will work fine, 
> the transaction will be finished correctly, and the path will be updated 
> to the correct state (2).

AIUI you can add a watch for any path that you like - the path you ask
to watch doesn't have to exist.  But you won't (necessarily) see
events for uncommitted transactions.

> If the transaction is not committed successfully, we will get a timeout 
> from the devstate event and exit.

I think that the only way all this could work is if you firstly, in
one transaction, create enough of the backend for the hotplug scripts
to run, and then in a second transaction create the rest of the
backend plus the frontend.

> > I think this code is a symptom of a problem elsewhere.  When adding a
> > disk to a domain, it should not be necessary to explicitly ask to add
> > it to the stubdom too.  But this is not your fault, or your problem
> > right now.
> 
> So I assume we can leave this for later.

Yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:21: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 1SjZS5-0003sO-8D; Tue, 26 Jun 2012 17:21: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 1SjZS4-0003sI-6L
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:21:20 +0000
Received: from [193.109.254.147:37184] by server-3.bemta-14.messagelabs.com id
	EC/3B-08687-E8FE9EF4; Tue, 26 Jun 2012 17:21:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340731277!968211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20492 invoked from network); 26 Jun 2012 17:21:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:21:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:21:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZS1-0000Re-5q; Tue, 26 Jun 2012 17:21:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZS1-00061I-51;
	Tue, 26 Jun 2012 18:21:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61325.137078.150553@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:21:17 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <e764d52618f736bdc58a.1340726463@Solace>
References: <e764d52618f736bdc58a.1340726463@Solace>
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 v2] libxl: document the memory ownership of
	some 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

Dario Faggioli writes ("[PATCH v2] libxl: document the memory ownership of some functions"):
> Specifying they allocate dynamic memory that needs to be explicitly freed.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:21: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 1SjZS5-0003sO-8D; Tue, 26 Jun 2012 17:21: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 1SjZS4-0003sI-6L
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:21:20 +0000
Received: from [193.109.254.147:37184] by server-3.bemta-14.messagelabs.com id
	EC/3B-08687-E8FE9EF4; Tue, 26 Jun 2012 17:21:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340731277!968211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20492 invoked from network); 26 Jun 2012 17:21:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:21:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:21:17 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZS1-0000Re-5q; Tue, 26 Jun 2012 17:21:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZS1-00061I-51;
	Tue, 26 Jun 2012 18:21:17 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61325.137078.150553@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:21:17 +0100
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <e764d52618f736bdc58a.1340726463@Solace>
References: <e764d52618f736bdc58a.1340726463@Solace>
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 v2] libxl: document the memory ownership of
	some 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

Dario Faggioli writes ("[PATCH v2] libxl: document the memory ownership of some functions"):
> Specifying they allocate dynamic memory that needs to be explicitly freed.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZSv-0003we-MY; Tue, 26 Jun 2012 17:22: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 1SjZSu-0003wV-29
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:22:12 +0000
Received: from [85.158.139.83:23835] by server-12.bemta-5.messagelabs.com id
	2E/17-25233-3CFE9EF4; Tue, 26 Jun 2012 17:22:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340731330!28349236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15214 invoked from network); 26 Jun 2012 17:22:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:22:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:22:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:22:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZSr-0000S2-3c; Tue, 26 Jun 2012 17:22:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZSr-00061S-2w;
	Tue, 26 Jun 2012 18:22:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61377.77775.31123@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:22:09 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE9E091.2090001@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
> Ian Jackson wrote:
> > Should we rename the functions libxl_*nic* or the structures *vif* ?
> > Or should we rename both, to "net" perhaps ?
> 
> I think we should either rename the strucutres to nic also (because the 
> also hold ioemu cards), or get rid of nic/vif an name everything net.

Can you try to rename everything to `net' and see if that turns out to
be an impenetrable yak ?

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 Jun 26 17:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZSv-0003we-MY; Tue, 26 Jun 2012 17:22: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 1SjZSu-0003wV-29
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:22:12 +0000
Received: from [85.158.139.83:23835] by server-12.bemta-5.messagelabs.com id
	2E/17-25233-3CFE9EF4; Tue, 26 Jun 2012 17:22:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340731330!28349236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15214 invoked from network); 26 Jun 2012 17:22:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:22:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:22:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:22:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZSr-0000S2-3c; Tue, 26 Jun 2012 17:22:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZSr-00061S-2w;
	Tue, 26 Jun 2012 18:22:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61377.77775.31123@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:22:09 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE9E091.2090001@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
> Ian Jackson wrote:
> > Should we rename the functions libxl_*nic* or the structures *vif* ?
> > Or should we rename both, to "net" perhaps ?
> 
> I think we should either rename the strucutres to nic also (because the 
> also hold ioemu cards), or get rid of nic/vif an name everything net.

Can you try to rename everything to `net' and see if that turns out to
be an impenetrable yak ?

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 Jun 26 17:23:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZTh-00041I-48; Tue, 26 Jun 2012 17:23:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZTg-000414-9e
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:23:00 +0000
Received: from [85.158.143.99:64508] by server-3.bemta-4.messagelabs.com id
	58/52-05808-3FFE9EF4; Tue, 26 Jun 2012 17:22:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340731378!23917201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27512 invoked from network); 26 Jun 2012 17:22:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231096"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:22:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:22:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZTe-0000SI-KD; Tue, 26 Jun 2012 17:22:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZTe-00061W-JF;
	Tue, 26 Jun 2012 18:22:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61426.574018.25625@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:22:58 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE9E153.1050309@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@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 v6 10/13] libxl: set nic type to VIF 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

Roger Pau Monne writes ("Re: [PATCH v6 10/13] libxl: set nic type to VIF by default"):
> Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
> >> Set the default value for nic interfaces to VIF, since it used to be
> >> IOEMU, even for PV guests.
> >
> > If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
> > HVM guests getting emulated network interfaces by default ?
> 
> Yes, if you want emulated interfaces with HVM guests you should use 
> 'type=ioemu', that's how it has always been right?

AIUI the current code doesn't require that.  Certainly looking at your
patch it appears that the existing default is VIF_IOEMU.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:23:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZTh-00041I-48; Tue, 26 Jun 2012 17:23:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZTg-000414-9e
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:23:00 +0000
Received: from [85.158.143.99:64508] by server-3.bemta-4.messagelabs.com id
	58/52-05808-3FFE9EF4; Tue, 26 Jun 2012 17:22:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1340731378!23917201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27512 invoked from network); 26 Jun 2012 17:22:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231096"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:22:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:22:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZTe-0000SI-KD; Tue, 26 Jun 2012 17:22:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZTe-00061W-JF;
	Tue, 26 Jun 2012 18:22:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61426.574018.25625@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:22:58 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
In-Reply-To: <4FE9E153.1050309@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@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 v6 10/13] libxl: set nic type to VIF 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

Roger Pau Monne writes ("Re: [PATCH v6 10/13] libxl: set nic type to VIF by default"):
> Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
> >> Set the default value for nic interfaces to VIF, since it used to be
> >> IOEMU, even for PV guests.
> >
> > If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
> > HVM guests getting emulated network interfaces by default ?
> 
> Yes, if you want emulated interfaces with HVM guests you should use 
> 'type=ioemu', that's how it has always been right?

AIUI the current code doesn't require that.  Certainly looking at your
patch it appears that the existing default is VIF_IOEMU.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:24:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:24: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 1SjZUZ-0004AV-O7; Tue, 26 Jun 2012 17: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.Jackson@eu.citrix.com>) id 1SjZUX-0004A6-NA
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:23:53 +0000
Received: from [85.158.138.51:30819] by server-6.bemta-3.messagelabs.com id
	45/86-11602-820F9EF4; Tue, 26 Jun 2012 17:23:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340731430!29547447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26804 invoked from network); 26 Jun 2012 17:23:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231110"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:23:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:23:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZUU-0000Sr-36; Tue, 26 Jun 2012 17:23:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZUU-00061c-2B;
	Tue, 26 Jun 2012 18:23:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61478.53122.864272@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:23:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340727982.3832.169.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
	<1340360049.26083.82.camel@zakaz.uk.xensource.com>
	<1340727908.9444.21.camel@Solace>
	<1340727982.3832.169.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 08 of 10 v2] libxl: enable automatic placement of guests on NUMA nodes"):
> On Tue, 2012-06-26 at 17:25 +0100, Dario Faggioli wrote:
> > So, the answer is that I really don't know, as I'm using a library
> > function for doing the actual work. I really do not expect for them to
> > be that high, and I hence can remove the if() if you think it looks
> > ugly. :-)
> 
> Not really ugly, it just seemed like an odd optimisation to make.

Yes, please remove the if().  It makes the code more complicated and
this is not a hot path.

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 Jun 26 17:24:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:24: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 1SjZUZ-0004AV-O7; Tue, 26 Jun 2012 17: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.Jackson@eu.citrix.com>) id 1SjZUX-0004A6-NA
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:23:53 +0000
Received: from [85.158.138.51:30819] by server-6.bemta-3.messagelabs.com id
	45/86-11602-820F9EF4; Tue, 26 Jun 2012 17:23:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340731430!29547447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26804 invoked from network); 26 Jun 2012 17:23:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231110"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:23:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:23:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZUU-0000Sr-36; Tue, 26 Jun 2012 17:23:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZUU-00061c-2B;
	Tue, 26 Jun 2012 18:23:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.61478.53122.864272@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 18:23:50 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340727982.3832.169.camel@zakaz.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<1340278832.21872.112.camel@zakaz.uk.xensource.com>
	<1340296452.4856.87.camel@Solace>
	<1340360049.26083.82.camel@zakaz.uk.xensource.com>
	<1340727908.9444.21.camel@Solace>
	<1340727982.3832.169.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 08 of 10 v2] libxl: enable automatic placement of guests on NUMA nodes"):
> On Tue, 2012-06-26 at 17:25 +0100, Dario Faggioli wrote:
> > So, the answer is that I really don't know, as I'm using a library
> > function for doing the actual work. I really do not expect for them to
> > be that high, and I hence can remove the if() if you think it looks
> > ugly. :-)
> 
> Not really ugly, it just seemed like an odd optimisation to make.

Yes, please remove the if().  It makes the code more complicated and
this is not a hot path.

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 Jun 26 17:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZUu-0004EH-58; Tue, 26 Jun 2012 17:24:16 +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 1SjZUr-0004Dk-Va
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:24:14 +0000
Received: from [85.158.138.51:37899] by server-2.bemta-3.messagelabs.com id
	F6/DF-10266-C30F9EF4; Tue, 26 Jun 2012 17:24:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340731452!21491133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3123 invoked from network); 26 Jun 2012 17:24:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:24:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:24:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:24:12 +0100
Date: Tue, 26 Jun 2012 18:23:46 +0100
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: <1340720935.3832.138.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261823330.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720935.3832.138.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 2/5] xen/arm: gic and vgic 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > - the last argument of find_next_bit is the maximum number of bits, not
> > the maximum number of bytes;
> 
> I guess 8*sizeof(...) is pretty ugly too so just using the hardcoded
> numbers is acceptable in this case.

Yeah, that's what I thought.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZUu-0004EH-58; Tue, 26 Jun 2012 17:24:16 +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 1SjZUr-0004Dk-Va
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:24:14 +0000
Received: from [85.158.138.51:37899] by server-2.bemta-3.messagelabs.com id
	F6/DF-10266-C30F9EF4; Tue, 26 Jun 2012 17:24:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340731452!21491133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3123 invoked from network); 26 Jun 2012 17:24:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:24:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:24:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:24:12 +0100
Date: Tue, 26 Jun 2012 18:23:46 +0100
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: <1340720935.3832.138.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261823330.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720935.3832.138.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 2/5] xen/arm: gic and vgic 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > - the last argument of find_next_bit is the maximum number of bits, not
> > the maximum number of bytes;
> 
> I guess 8*sizeof(...) is pretty ugly too so just using the hardcoded
> numbers is acceptable in this case.

Yeah, that's what I thought.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:26:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjZWR-0004UB-LZ; Tue, 26 Jun 2012 17:25: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 1SjZWQ-0004Ts-IP
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:25:50 +0000
Received: from [85.158.143.99:16448] by server-3.bemta-4.messagelabs.com id
	1D/54-05808-D90F9EF4; Tue, 26 Jun 2012 17:25:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340731548!23992472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2921 invoked from network); 26 Jun 2012 17:25:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:25:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:25:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:25:47 +0100
Date: Tue, 26 Jun 2012 18:25:32 +0100
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: <1340718914.3832.120.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261825230.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718914.3832.120.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm/vtimer: do not let the guest
 interact with the physical 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > The guest can read the physical counter but it shouldn't be able to
> > cause interrupts of the physical timer to go to the hypervisor.
> > Trap physical timer reads/writes in vtimer.c instead.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/time.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> > index 1587fa2..d5b71d7 100644
> > --- a/xen/arch/arm/time.c
> > +++ b/xen/arch/arm/time.c
> > @@ -160,8 +160,8 @@ void __cpuinit init_timer_interrupt(void)
> >      WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
> >      WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
> >  #if USE_HYP_TIMER
> > -    /* Let the VMs read the physical counter and timer so they can tell time */
> > -    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
> > +    /* Do not the VMs program the physical timer, only read the physical counter */
> 
> "Do not *let* the VMs..." ?

right..


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17:26:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjZWR-0004UB-LZ; Tue, 26 Jun 2012 17:25: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 1SjZWQ-0004Ts-IP
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:25:50 +0000
Received: from [85.158.143.99:16448] by server-3.bemta-4.messagelabs.com id
	1D/54-05808-D90F9EF4; Tue, 26 Jun 2012 17:25:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340731548!23992472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2921 invoked from network); 26 Jun 2012 17:25:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:25:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:25:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:25:47 +0100
Date: Tue, 26 Jun 2012 18:25:32 +0100
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: <1340718914.3832.120.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261825230.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718914.3832.120.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm/vtimer: do not let the guest
 interact with the physical 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > The guest can read the physical counter but it shouldn't be able to
> > cause interrupts of the physical timer to go to the hypervisor.
> > Trap physical timer reads/writes in vtimer.c instead.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/time.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> > index 1587fa2..d5b71d7 100644
> > --- a/xen/arch/arm/time.c
> > +++ b/xen/arch/arm/time.c
> > @@ -160,8 +160,8 @@ void __cpuinit init_timer_interrupt(void)
> >      WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
> >      WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
> >  #if USE_HYP_TIMER
> > -    /* Let the VMs read the physical counter and timer so they can tell time */
> > -    WRITE_CP32(CNTHCTL_PA|CNTHCTL_TA, CNTHCTL);
> > +    /* Do not the VMs program the physical timer, only read the physical counter */
> 
> "Do not *let* the VMs..." ?

right..


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjZZq-0004lu-9q; Tue, 26 Jun 2012 17:29:22 +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 1SjZZo-0004lk-HV
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:29:20 +0000
Received: from [85.158.143.99:28549] by server-3.bemta-4.messagelabs.com id
	CC/B6-05808-F61F9EF4; Tue, 26 Jun 2012 17:29:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340731759!21542647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9621 invoked from network); 26 Jun 2012 17:29:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:29:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:29:19 +0100
Date: Tue, 26 Jun 2012 18:28:53 +0100
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: <1340719657.3832.125.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261826450.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120607124606.GT70339@ocelot.phlegethon.org>
	<1340719657.3832.125.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
 VCPUs not currently running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 26 Jun 2012, Ian Campbell wrote:
> On Thu, 2012-06-07 at 13:46 +0100, Tim Deegan wrote:
> > At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> > > +static void gic_restore_pending_irqs(struct vcpu *v)
> > > +{
> > > +    int i;
> > > +    struct pending_irq *p;
> > > +
> > > +    /* check for new pending irqs */
> > > +    if ( list_empty(&v->arch.vgic.lr_pending) )
> > > +        return;
> > > +
> > > +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> 
> Is list_for_each_entry on an empty list somehow wrong/buggy/slow?

Not at all. I'll change it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1SjZZq-0004lu-9q; Tue, 26 Jun 2012 17:29:22 +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 1SjZZo-0004lk-HV
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:29:20 +0000
Received: from [85.158.143.99:28549] by server-3.bemta-4.messagelabs.com id
	CC/B6-05808-F61F9EF4; Tue, 26 Jun 2012 17:29:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340731759!21542647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9621 invoked from network); 26 Jun 2012 17:29:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:29:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:29:19 +0100
Date: Tue, 26 Jun 2012 18:28:53 +0100
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: <1340719657.3832.125.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261826450.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120607124606.GT70339@ocelot.phlegethon.org>
	<1340719657.3832.125.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/5] xen/gic: support injecting IRQs even to
 VCPUs not currently running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 26 Jun 2012, Ian Campbell wrote:
> On Thu, 2012-06-07 at 13:46 +0100, Tim Deegan wrote:
> > At 12:22 +0100 on 06 Jun (1338985328), Stefano Stabellini wrote:
> > > +static void gic_restore_pending_irqs(struct vcpu *v)
> > > +{
> > > +    int i;
> > > +    struct pending_irq *p;
> > > +
> > > +    /* check for new pending irqs */
> > > +    if ( list_empty(&v->arch.vgic.lr_pending) )
> > > +        return;
> > > +
> > > +    list_for_each_entry ( p, &v->arch.vgic.lr_pending, lr_queue )
> 
> Is list_for_each_entry on an empty list somehow wrong/buggy/slow?

Not at all. I'll change it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:54:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZxy-00057p-Fy; Tue, 26 Jun 2012 17:54:18 +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 1SjZxx-00057k-5K
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:54:17 +0000
Received: from [193.109.254.147:56538] by server-6.bemta-14.messagelabs.com id
	9D/D3-08993-847F9EF4; Tue, 26 Jun 2012 17:54:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340733255!8668715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25886 invoked from network); 26 Jun 2012 17:54:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:54:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:54:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:54:15 +0100
Date: Tue, 26 Jun 2012 18:53:59 +0100
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: <1340719712.3832.126.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340719712.3832.126.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > Properly initialize all the pending_irqs.lr_queue like we do for
> > inflight.
> > Check whether we already have the irq in lr_queue before adding it.
> 
> Should this be a fatal error? Can a guest make this happen?

it could happen if the guest keeps enabling and disabling the irqs using
the GICD_ICENABLERn and the GICD_ISENABLERn registers.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c  |    6 ++++++
> >  xen/arch/arm/vgic.c |    6 ++++++
> >  2 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 2e41d75..998033a 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
> >      }
> >  
> >      n = irq_to_pending(v, virtual_irq);
> > +    if ( !list_empty(&n->lr_queue) )
> > +    {
> > +        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
> > +                virtual_irq);
> > +        goto out;
> > +    }
> >      list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
> >      {
> >          if ( iter->priority > priority )
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 4cdfec5..653e8e5 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
> >      d->arch.vgic.pending_irqs =
> >          xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> >      for (i=0; i<d->arch.vgic.nr_lines; i++)
> > +    {
> >          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> > +        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
> > +    }
> >      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
> >          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> >      return 0;
> > @@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
> >  
> >      memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> >      for (i = 0; i < 32; i++)
> > +    {
> >          INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> > +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
> > +    }
> >      printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
> >             &v->arch.vgic.pending_irqs[0],
> >             v->arch.vgic.pending_irqs[0].desc);
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:54:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZxy-00057p-Fy; Tue, 26 Jun 2012 17:54:18 +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 1SjZxx-00057k-5K
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:54:17 +0000
Received: from [193.109.254.147:56538] by server-6.bemta-14.messagelabs.com id
	9D/D3-08993-847F9EF4; Tue, 26 Jun 2012 17:54:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340733255!8668715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25886 invoked from network); 26 Jun 2012 17:54:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:54:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:54:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:54:15 +0100
Date: Tue, 26 Jun 2012 18:53:59 +0100
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: <1340719712.3832.126.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340719712.3832.126.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > Properly initialize all the pending_irqs.lr_queue like we do for
> > inflight.
> > Check whether we already have the irq in lr_queue before adding it.
> 
> Should this be a fatal error? Can a guest make this happen?

it could happen if the guest keeps enabling and disabling the irqs using
the GICD_ICENABLERn and the GICD_ISENABLERn registers.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c  |    6 ++++++
> >  xen/arch/arm/vgic.c |    6 ++++++
> >  2 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 2e41d75..998033a 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
> >      }
> >  
> >      n = irq_to_pending(v, virtual_irq);
> > +    if ( !list_empty(&n->lr_queue) )
> > +    {
> > +        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
> > +                virtual_irq);
> > +        goto out;
> > +    }
> >      list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
> >      {
> >          if ( iter->priority > priority )
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 4cdfec5..653e8e5 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
> >      d->arch.vgic.pending_irqs =
> >          xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> >      for (i=0; i<d->arch.vgic.nr_lines; i++)
> > +    {
> >          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> > +        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
> > +    }
> >      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
> >          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> >      return 0;
> > @@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
> >  
> >      memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> >      for (i = 0; i < 32; i++)
> > +    {
> >          INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> > +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
> > +    }
> >      printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
> >             &v->arch.vgic.pending_irqs[0],
> >             v->arch.vgic.pending_irqs[0].desc);
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzW-0005CD-B9; Tue, 26 Jun 2012 17:55:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzV-0005Br-Dw
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:53 +0000
Received: from [85.158.143.99:51327] by server-3.bemta-4.messagelabs.com id
	F4/28-05808-8A7F9EF4; Tue, 26 Jun 2012 17:55:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26135 invoked from network); 26 Jun 2012 17:55:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000je-Cn; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VA-As;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:54:59 +0100
Message-ID: <1340733318-21099-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/21] libxc: Do not segfault if (e.g.)
	switch_qemu_logdirty 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

In xc_domain_save the local variable `ob' is initialised to NULL.
There are then various startup actions.  Some of these `goto out' on
failure; for example the call to callbacks->switch_qemu_logdirty on
l.978.  However, out is used both by success and error paths.  So it
attempts (l.2043) to flush the current output buffer.  If ob has not
yet been assigned a non-NULL value, this segfaults.  So make the call
to outbuf_flush conditional on ob.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_domain_save.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index fcc7718..c359649 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -2040,7 +2040,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
     }
 
     /* Flush last write and discard cache for file. */
-    if ( outbuf_flush(xch, ob, io_fd) < 0 ) {
+    if ( ob && outbuf_flush(xch, ob, io_fd) < 0 ) {
         PERROR("Error when flushing output buffer");
         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 Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzb-0005G8-M6; Tue, 26 Jun 2012 17:55: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 1SjZzX-0005CP-5V
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:39504] by server-1.bemta-3.messagelabs.com id
	0F/80-14648-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19506 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jw-Ob; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VY-Nl;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:05 +0100
Message-ID: <1340733318-21099-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/21] libxl: provide libxl__xs_*_checked and
	libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 useful utility functions make dealing with xenstore a little
less painful.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Fixed typo `commited' in comment.

Changes in v3:
 * Fixed typo `transacton' in log messages.
---
 tools/libxl/libxl_internal.h |   38 +++++++++++++++++++++
 tools/libxl/libxl_xshelp.c   |   76 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1a7b526..b108d00 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -498,6 +498,44 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*----- "checked" xenstore access functions -----*/
+/* Each of these functions will check that it succeeded; if it
+ * fails it logs and returns ERROR_FAIL.
+ */
+
+/* On success, *result_out came from the gc.
+ * On error, *result_out is undefined.
+ * ENOENT counts as success but sets *result_out=0
+ */
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out);
+
+/* Does not include a trailing null.
+ * May usefully be combined with GCSPRINTF if the format string
+ * behaviour of libxl__xs_write is desirable. */
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string);
+
+/* ENOENT is not an error (even if the parent directories don't exist) */
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
+
+/* Transaction functions, best used together.
+ * The caller should initialise *t to 0 (XBT_NULL) before calling start.
+ * Each function leaves *t!=0 iff the transaction needs cleaning up.
+ *
+ * libxl__xs_transaction_commit returns:
+ *   <0  failure - a libxl error code
+ *   +1  commit conflict; transaction has been destroyed and caller
+ *        must go round again (call _start again and retry)
+ *    0  committed successfully
+ */
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
+
+
+
 /*
  * This is a recursive delete, from top to bottom. What this function does
  * is remove empty folders that contained the deleted entry.
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index c5b5364..993f527 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,82 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out)
+{
+    char *result = libxl__xs_read(gc, t, path);
+    if (!result) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "xenstore read failed: `%s'", path);
+            return ERROR_FAIL;
+        }
+    }
+    *result_out = result;
+    return 0;
+}
+
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string)
+{
+    size_t length = strlen(string);
+    if (!xs_write(CTX->xsh, t, path, string, length)) {
+        LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, string);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path)
+{
+    if (!xs_rm(CTX->xsh, t, path)) {
+        if (errno == ENOENT)
+            return 0;
+
+        LOGE(ERROR, "xenstore rm failed: `%s'", path);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(!*t);
+    *t = xs_transaction_start(CTX->xsh);
+    if (!*t) {
+        LOGE(ERROR, "could not create xenstore transaction");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(*t);
+
+    if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        if (errno == EAGAIN)
+            return +1;
+
+        *t = 0;
+        LOGE(ERROR, "could not commit xenstore transaction");
+        return ERROR_FAIL;
+    }
+
+    *t = 0;
+    return 0;
+}
+
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t)
+{
+    if (!*t)
+        return;
+
+    if (!xs_transaction_end(CTX->xsh, *t, 1))
+        LOGE(ERROR, "could not abort xenstore transaction");
+
+    *t = 0;
+}
+
 int libxl__xs_path_cleanup(libxl__gc *gc, xs_transaction_t t, char *user_path)
 {
     unsigned int nb = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzd-0005Hs-EC; Tue, 26 Jun 2012 17:56:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005C0-HH
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51376] by server-1.bemta-4.messagelabs.com id
	47/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26193 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000k2-To; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vk-Rt;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:08 +0100
Message-ID: <1340733318-21099-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/21] libxl: prepare for asynchronous writing
	of qemu save 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

* Combine the various calls to libxl__device_model_savefile into one
  at the start of libxl__domain_suspend, storing the result in the
  dss.  Consequently a few functions take a dss instead of some or all
  of their other arguments.

* Make libxl__domain_save_device_model's API into an asynchronous
  style which takes a callback.  The function is, however, still
  synchronous; it will be made actually async in the next patch.

* Consequently make libxl__remus_domain_checkpoint_callback into an
  asynchronous callback.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h       |   18 ++++++++++--
 tools/libxl/libxl_save_msgs_gen.pl |    2 +-
 3 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4a588fb..439b4da 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -705,11 +705,13 @@ static void switch_logdirty_done(libxl__egc *egc,
 
 /*----- callbacks, called by xc_domain_save -----*/
 
-int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                       libxl__domain_suspend_state *dss)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
-    const char *filename = libxl__device_model_savefile(gc, domid);
+    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: {
@@ -878,7 +880,7 @@ int libxl__domain_suspend_common_callback(void *user)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -993,19 +995,32 @@ static int libxl__remus_domain_resume_callback(void *data)
     return 1;
 }
 
-static int libxl__remus_domain_checkpoint_callback(void *data)
+/*----- remus asynchronous checkpoint callback -----*/
+
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc);
+
+static void libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
-    if (dss->hvm &&
-        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
-        return 0;
+    if (dss->hvm) {
+        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
+    } else {
+        remus_checkpoint_dm_saved(egc, dss, 0);
+    }
+}
 
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc)
+{
     /* TODO: Wait for disk and memory ack, release network buffer */
+    /* TODO: make this asynchronous */
     usleep(dss->interval * 1000);
-    return 1;
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
 }
 
 /*----- main code for suspending, in order of execution -----*/
@@ -1055,6 +1070,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
+    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
 
     if (r_info != NULL) {
         dss->interval = r_info->interval;
@@ -1104,7 +1120,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
 
     /* Convenience aliases */
     const libxl_domain_type type = dss->type;
-    const uint32_t domid = dss->domid;
 
     if (rc)
         goto out;
@@ -1122,11 +1137,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
     }
 
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
-        rc = libxl__domain_suspend_device_model(gc, domid);
+        rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
         
-        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
-        if (rc) goto out;
+        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
+        return;
     }
 
     rc = 0;
@@ -1135,14 +1150,22 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback)
 {
+    STATE_AO_GC(dss->ao);
     int rc, fd2 = -1, c;
     char buf[1024];
-    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
+    dss->save_dm_callback = callback;
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    const int fd = dss->fd;
+
     if (stat(filename, &st) < 0)
     {
         LOG(ERROR, "Unable to stat qemu save file\n");
@@ -1184,7 +1207,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return rc;
+
+    dss->save_dm_callback(egc, dss, rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8b582e4..e95892a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 
 _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
                                      uint32_t size, void *data);
-_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
+
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
+typedef void libxl__save_device_model_cb(libxl__egc*,
+                                         libxl__domain_suspend_state*, int rc);
 
 typedef struct libxl__logdirty_switch {
     const char *cmd;
@@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
     int hvm;
     int xcflags;
     int guest_responded;
+    const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
     libxl__logdirty_switch logdirty;
+    /* private for libxl__domain_save_device_model */
+    libxl__save_device_model_cb *save_dm_callback;
 };
 
 
@@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
+/* Each time the dm needs to be saved, we must call suspend and then save */
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                           libxl__domain_suspend_state *dss);
+_hidden void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback);
+
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+
 
 /*
  * Convenience macros.
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index a9ac808..ee126c7 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -25,7 +25,7 @@ our @msgs = (
                                                 'unsigned long', 'total'] ],
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
-    [  5, 'scxW',   "checkpoint", [] ],      
+    [  5, 'scxA',   "checkpoint", [] ],      
     [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZza-0005Ep-7E; Tue, 26 Jun 2012 17:55:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005C0-1r
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:6179] by server-1.bemta-4.messagelabs.com id
	17/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26203 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kH-7l; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005W4-5M;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:13 +0100
Message-ID: <1340733318-21099-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/21] xl: Handle return value from
	libxl_domain_suspend correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl_domain_suspend returns a libxl error code.  So it must be
wrapped with MUST and not CHK_ERRNO.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 4aea1c7..56e51aa 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2817,7 +2817,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzc-0005Gw-Fj; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CN-4O
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:65389] by server-9.bemta-5.messagelabs.com id
	90/94-01069-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12321 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jz-Qn; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vc-OL;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:06 +0100
Message-ID: <1340733318-21099-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/21] libxl: wait for qemu to acknowledge
	logdirty 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

The current migration code in libxl instructs qemu to start or stop
logdirty, but it does not wait for an acknowledgement from qemu before
continuing.  This might lead to memory corruption (!)

Fix this by waiting for qemu to acknowledge the command.

Unfortunately the necessary ao arrangements for waiting for this
command are unique because qemu has a special protocol for this
particular operation.

Also, this change means that the switch_qemu_logdirty callback
implementation in libxl can no longer synchronously produce its return
value, as it now needs to wait for xenstore.  So we tell the
marshalling code generator that it is a message which does not need a
reply.  This turns the callback function called by the marshaller into
one which returns void; the callback function arranges to later
explicitly sends the reply to the helper, when the xs watch triggers
and the appropriate value is read from xenstore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Correct the sense of the return value from switch_qemu_logdirty.
 * Fix a somewhat mendacious log message.
---
 tools/libxl/libxl_dom.c            |  177 +++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h       |   18 ++++-
 tools/libxl/libxl_save_callout.c   |    8 ++
 tools/libxl/libxl_save_msgs_gen.pl |    7 +-
 4 files changed, 194 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ba58c45..4a588fb 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -530,30 +530,181 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
 static void domain_suspend_done(libxl__egc *egc,
                         libxl__domain_suspend_state *dss, int rc);
 
-/*----- callbacks, called by xc_domain_save -----*/
+/*----- complicated callback, called by xc_domain_save -----*/
+
+/*
+ * We implement the other end of protocol for controlling qemu-dm's
+ * logdirty.  There is no documentation for this protocol, but our
+ * counterparty's implementation is in
+ * qemu-xen-traditional.git:xenstore.c in the function
+ * xenstore_process_logdirty_event
+ */
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs);
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok);
 
-int libxl__domain_suspend_common_switch_qemu_logdirty
+static void logdirty_init(libxl__logdirty_switch *lds)
+{
+    lds->cmd_path = 0;
+    libxl__ev_xswatch_init(&lds->watch);
+    libxl__ev_time_init(&lds->timeout);
+}
+
+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);
+    libxl__logdirty_switch *lds = &dss->logdirty;
     STATE_AO_GC(dss->ao);
-    char *path;
-    bool rc;
+    int rc;
+    xs_transaction_t t = 0;
+    const char *got;
 
-    path = libxl__sprintf(gc,
+    if (!lds->cmd_path) {
+        lds->cmd_path = GCSPRINTF(
                    "/local/domain/0/device-model/%u/logdirty/cmd", domid);
-    if (!path)
-        return 1;
+        lds->ret_path = GCSPRINTF(
+                   "/local/domain/0/device-model/%u/logdirty/ret", domid);
+    }
+    lds->cmd = enable ? "enable" : "disable";
 
-    if (enable)
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
-    else
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
+    rc = libxl__ev_xswatch_register(gc, &lds->watch,
+                                switch_logdirty_xswatch, lds->ret_path);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_register_rel(gc, &lds->timeout,
+                                switch_logdirty_timeout, 10*1000);
+    if (rc) goto out;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->cmd_path, &got);
+        if (rc) goto out;
+
+        if (got) {
+            const char *got_ret;
+            rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got_ret);
+            if (rc) goto out;
 
-    return rc ? 0 : 1;
+            if (strcmp(got, got_ret)) {
+                LOG(ERROR,"controlling logdirty: qemu was already sent"
+                    " command `%s' (xenstore path `%s') but result is `%s'",
+                    got, lds->cmd_path, got_ret ? got_ret : "<none>");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+            rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+            if (rc) goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_write_checked(gc, t, lds->cmd_path, lds->cmd);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t);
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+    /* OK, wait for some callback */
+    return;
+
+ out:
+    LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+    switch_logdirty_done(egc,dss,-1);
+}
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
+    STATE_AO_GC(dss->ao);
+    LOG(ERROR,"logdirty switch: wait for device model timed out");
+    switch_logdirty_done(egc,dss,-1);
 }
 
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(watch, *dss, logdirty.watch);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+    STATE_AO_GC(dss->ao);
+    const char *got;
+    xs_transaction_t t = 0;
+    int rc;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
+        if (rc) goto out;
+
+        if (!got) {
+            rc = +1;
+            goto out;
+        }
+
+        if (strcmp(got, lds->cmd)) {
+            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
+                " (xenstore paths `%s' / `%s')", lds->cmd, got,
+                lds->cmd_path, lds->ret_path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t); 
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+ out:
+    /* rc < 0: error
+     * rc == 0: ok, we are done
+     * rc == +1: need to keep waiting
+     */
+    libxl__xs_transaction_abort(gc, &t);
+
+    if (!rc) {
+        switch_logdirty_done(egc,dss,0);
+    } else if (rc < 0) {
+        LOG(ERROR,"logdirty switch: failed (rc=%d)",rc);
+        switch_logdirty_done(egc,dss,-1);
+    }
+}
+
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss,
+                                 int broke)
+{
+    STATE_AO_GC(dss->ao);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+
+    libxl__ev_xswatch_deregister(gc, &lds->watch);
+    libxl__ev_time_deregister(gc, &lds->timeout);
+
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, broke);
+}
+
+/*----- callbacks, called by xc_domain_save -----*/
+
 int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -875,6 +1026,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     libxl__srm_save_autogen_callbacks *const callbacks =
         &dss->shs.callbacks.save.a;
 
+    logdirty_init(&dss->logdirty);
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b108d00..05bed01 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1864,6 +1864,14 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
 
+typedef struct libxl__logdirty_switch {
+    const char *cmd;
+    const char *cmd_path;
+    const char *ret_path;
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+} libxl__logdirty_switch;
+
 struct libxl__domain_suspend_state {
     /* set by caller of libxl__domain_suspend */
     libxl__ao *ao;
@@ -1883,6 +1891,7 @@ struct libxl__domain_suspend_state {
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
+    libxl__logdirty_switch logdirty;
 };
 
 
@@ -2013,8 +2022,15 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
+/* Used by asynchronous callbacks: ie ones which xc regards as
+ * returning a value, but which we want to handle asynchronously.
+ * Such functions' actual callback function return void in libxl
+ * When they are ready to indicate completion, they call this. */
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value);
+
 _hidden int libxl__domain_suspend_common_callback(void *data);
-_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+_hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data);
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 19fff1b..6332beb 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -142,6 +142,14 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
 }
 
 
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value)
+{
+    shs->egc = egc;
+    libxl__srm_callout_sendreply(return_value, shs);
+    shs->egc = 0;
+}
+
 /*----- helper execution -----*/
 
 static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index c45986e..a9ac808 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -14,6 +14,7 @@ our @msgs = (
     #   x  - function pointer is in struct {save,restore}_callbacks
     #         and its null-ness needs to be passed through to the helper's xc
     #   W  - needs a return value; callback is synchronous
+    #   A  - needs a return value; callback is asynchronous
     [  1, 'sr',     "log",                   [qw(uint32_t level
                                                  uint32_t errnoval
                                                  STRING context
@@ -25,7 +26,7 @@ our @msgs = (
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
     [  5, 'scxW',   "checkpoint", [] ],      
-    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+    [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
     [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
@@ -262,7 +263,7 @@ foreach my $msginfo (@msgs) {
         $f_more_sr->("        int r;\n");
     }
 
-    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_helper = $flags =~ m/[WA]/ ? 'int' : 'void';
     my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
     my $c_decl = '(';
     my $c_callback_args = '';
@@ -351,7 +352,7 @@ END_ALWAYS
     assert(len == allocd);
     ${transmit}(buf, len, user);
 ");
-    if ($flags =~ m/W/) {
+    if ($flags =~ m/[WA]/) {
 	f_more("${encode}_$name",
                (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
     int r = ${helper}_getreply(user);
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzZ-0005EC-0H; Tue, 26 Jun 2012 17:55:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzW-0005Br-N4
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51381] by server-3.bemta-4.messagelabs.com id
	78/28-05808-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26232 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jp-Js; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VM-Hr;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:02 +0100
Message-ID: <1340733318-21099-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
	asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the internal and external APIs for domain save (suspend) to be
capable of asynchronous operation.  The implementation remains
synchronous.  The interfaces surrounding device model saving are still
synchronous.

Public API changes:

 * libxl_domain_save takes an ao_how.

 * libxl_domain_remus_start takes an ao_how.  If the
   libxl_domain_remus_info is NULL, we abort rather than returning an
   error.

 * The `suspend_callback' function passed to libxl_domain_save is
   never called by the existing implementation in libxl.  Abolish it.

 * libxl_domain_save takes its flags parameter as an argument.
   Thus libxl_domain_suspend_info is abolished.

 * XL_SUSPEND_* flags renamed to LIBXL_SAVE_*.

 * Callers in xl updated.

Internal code restructuring:

 * libxl__domain_suspend_state member types and names rationalised.

 * libxl__domain_suspend renamed from libxl__domain_suspend_common.
   (_common here actually meant "internal function").

 * libxl__domain_suspend takes a libxl__domain_suspend_state, which
   where the parameters to the operation are filled in by the caller.

 * xc_domain_save is now called via libxl__xc_domain_save which can
   itself become asynchronous.

 * Consequently, libxl__domain_suspend is split into two functions at
   the callback boundary; the second half is
   libxl__xc_domain_save_done.

 * libxl__domain_save_device_model is now called by the actual
   implementation rather than by the public wrapper.  It is already in
   its proper place in the domain save execution sequence.  So
   officially make it part of that execution sequence, renaming it to
   domain_save_device_model.

 * Effectively, rewrite the public wrapper functions
   libxl_domain_suspend and libxl_domain_remus_start.

 * Remove a needless #include <xenctrl.h>

 * libxl__domain_suspend aborts on unexpected domain types rather
   than mysteriously returning EINVAL.

 * struct save_callbacks moved from the stack to the dss.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v5:
 * Renamed remus_crashed_cb to remus_failover_cb.

Changes in v4:
 * libxl_domain_suspend now handles error from libxl__domain_type
   in the correct way.  (Hunk brought forward from domain type
   fixup patch.)
 * Comment clarifies that libxl__domain_suspend calls dss->callback
   when done.

Changes in v3:
 * Remove `hvm' and `xcflags' args to libxl__xc_domain_save.  Instead,
   just use the values from the dss.

Changes in v2:
 * Move save_callbacks too.
 * Merge with Remus changes.
 * Improvements to commit message.
 * Do not rename libxl_domain_suspend any more.
---
 tools/libxl/libxl.c              |   94 +++++++++++++++++++++---------
 tools/libxl/libxl.h              |   22 ++++----
 tools/libxl/libxl_dom.c          |  121 +++++++++++++++++++++++++++-----------
 tools/libxl/libxl_internal.h     |   45 ++++++++++++---
 tools/libxl/libxl_save_callout.c |   11 ++++
 tools/libxl/xl_cmdimpl.c         |    9 +--
 6 files changed, 214 insertions(+), 88 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..6ec7471 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
     return ptr;
 }
 
+static void remus_failover_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc);
+
 /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd)
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    libxl_domain_type type = libxl__domain_type(gc, domid);
-    int rc = 0;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_suspend_state *dss;
+    int rc;
 
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
-        goto remus_fail;
+        goto out;
     }
 
-    if (info == NULL) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "No remus_info structure supplied for domain %d", domid);
-        rc = ERROR_INVAL;
-        goto remus_fail;
-    }
+    GCNEW(dss);
+    dss->ao = ao;
+    dss->callback = remus_failover_cb;
+    dss->domid = domid;
+    dss->fd = send_fd;
+    /* TODO do something with recv_fd */
+    dss->type = type;
+    dss->live = 1;
+    dss->debug = 0;
+    dss->remus = info;
+
+    assert(info);
 
     /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
 
     /* Point of no return */
-    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
-                                      /* debug */ 0, info);
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out:
+    return AO_ABORT(rc);
+}
 
+static void remus_failover_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
     /*
      * With Remus, if we reach this point, it means either
      * backup died or some network error occurred preventing us
@@ -683,27 +702,46 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
     /* TBD: Remus cleanup - i.e. detach qdisc, release other
      * resources.
      */
- remus_fail:
-    GC_FREE;
-    return rc;
+    libxl__ao_complete(egc, ao, rc);
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                         uint32_t domid, int fd)
+static void domain_suspend_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
 {
-    GC_INIT(ctx);
+    STATE_AO_GC(dss->ao);
+    libxl__ao_complete(egc,ao,rc);
+
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    int rc;
+
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
-    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
-    int rc = 0;
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out_err;
+    }
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
-                                      /* No Remus */ NULL);
+    libxl__domain_suspend_state *dss;
+    GCNEW(dss);
 
-    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(gc, domid, fd);
-    GC_FREE;
-    return rc;
+    dss->ao = ao;
+    dss->callback = domain_suspend_cb;
+
+    dss->domid = domid;
+    dss->fd = fd;
+    dss->type = type;
+    dss->live = flags & LIBXL_SUSPEND_LIVE;
+    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out_err:
+    return AO_ABORT(rc);
 }
 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..10d7115 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
 
-typedef struct {
-#define XL_SUSPEND_DEBUG 1
-#define XL_SUSPEND_LIVE 2
-    int flags;
-    int (*suspend_callback)(void *, int);
-} libxl_domain_suspend_info;
-
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
@@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
-int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd);
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                          uint32_t domid, int fd);
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_asyncop_how *ao_how);
+#define LIBXL_SUSPEND_DEBUG 1
+#define LIBXL_SUSPEND_LIVE 2
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
  *   must support this.
  */
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
+
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how);
+
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d73b089..c44dec0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -17,13 +17,11 @@
 
 #include <glob.h>
 
-#include <xenctrl.h>
-#include <xc_dom.h>
+#include "libxl_internal.h"
 
+#include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl_internal.h"
-
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -523,11 +521,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-static int libxl__domain_suspend_common_switch_qemu_logdirty
+/*==================== Domain suspend (save) ====================*/
+
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc);
+
+/*----- callbacks, called by xc_domain_save -----*/
+
+int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
 
@@ -592,10 +597,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
@@ -716,7 +721,7 @@ static int libxl__domain_suspend_common_callback(void *data)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss->domid);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -733,11 +738,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -808,6 +813,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
     return 0;
 }
 
+/*----- remus callbacks -----*/
+
 static int libxl__remus_domain_suspend_callback(void *data)
 {
     /* TODO: Issue disk and network checkpoint reqs. */
@@ -817,7 +824,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
 static int libxl__remus_domain_resume_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
     if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
@@ -830,10 +837,11 @@ static int libxl__remus_domain_resume_callback(void *data)
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
     if (dss->hvm &&
-        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
+        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
@@ -841,17 +849,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
     return 1;
 }
 
-int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                 libxl_domain_type type,
-                                 int live, int debug,
-                                 const libxl_domain_remus_info *r_info)
+/*----- main code for suspending, in order of execution -----*/
+
+void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 {
+    STATE_AO_GC(dss->ao);
     int port;
-    struct save_callbacks callbacks[1];
-    libxl__domain_suspend_state dss[1];
     int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+    const libxl_domain_type type = dss->type;
+    const int live = dss->live;
+    const int debug = dss->debug;
+    const libxl_domain_remus_info *const r_info = dss->remus;
+    struct save_callbacks *const callbacks = &dss->callbacks;
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
@@ -870,15 +884,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->hvm = 0;
         break;
     default:
-        return ERROR_INVAL;
+        abort();
     }
 
     dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (dss->hvm) ? XCFLAGS_HVM : 0;
 
-    dss->domid = domid;
-    dss->gc = gc;
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
 
@@ -886,10 +898,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->interval = r_info->interval;
         if (r_info->compression)
             dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        dss->save_fd = fd;
     }
-    else
-        dss->save_fd = -1;
 
     dss->xce = xc_evtchn_open(NULL, 0);
     if (dss->xce == NULL)
@@ -919,10 +928,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     callbacks->toolstack_save = libxl__toolstack_save;
     callbacks->data = dss;
 
-    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
-                        dss->hvm, vm_generationid_addr);
-    if ( rc ) {
-        LOGE(ERROR, "saving domain: %s",
+    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
+    return;
+
+ out:
+    domain_suspend_done(egc, dss, rc);
+}
+
+void libxl__xc_domain_save_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss,
+                                int rc, int retval, int errnoval)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const libxl_domain_type type = dss->type;
+    const uint32_t domid = dss->domid;
+
+    if (rc)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "saving domain: %s",
                          dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
@@ -930,16 +957,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
+        goto out;
     }
 
-    if (dss->suspend_eventchn > 0)
-        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                                  dss->suspend_eventchn);
-    if (dss->xce != NULL)
-        xc_evtchn_close(dss->xce);
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, domid);
+        if (rc) goto out;
+        
+        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
+        if (rc) goto out;
+    }
+
+    rc = 0;
 
 out:
-    return rc;
+    domain_suspend_done(egc, dss, rc);
 }
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
@@ -994,6 +1026,25 @@ out:
     return rc;
 }
 
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
+
+    dss->callback(egc, dss, rc);
+}
+
+/*==================== Miscellaneous ====================*/
+
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
     char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 28478ea..7cf1b04 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
+typedef void libxl__domain_suspend_cb(libxl__egc*,
+                                      libxl__domain_suspend_state*, int rc);
+
 struct libxl__domain_suspend_state {
-    libxl__gc *gc;
+    /* set by caller of libxl__domain_suspend */
+    libxl__ao *ao;
+    libxl__domain_suspend_cb *callback;
+
+    uint32_t domid;
+    int fd;
+    libxl_domain_type type;
+    int live;
+    int debug;
+    const libxl_domain_remus_info *remus;
+    /* private */
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
-    int domid;
     int hvm;
-    unsigned int xcflags;
+    int xcflags;
     int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
     int interval; /* checkpoint interval (for Remus) */
+    struct save_callbacks callbacks;
 };
 
 
@@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
 
 /*----- Domain suspend (save) functions -----*/
 
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
+/* calls dss->callback when done */
+_hidden void libxl__domain_suspend(libxl__egc *egc,
+                                   libxl__domain_suspend_state *dss);
+
+
+/* calls libxl__xc_domain_suspend_done when done */
+_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
+                                   unsigned long vm_generationid_addr);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_save_done(libxl__egc*,
+                                        libxl__domain_suspend_state*,
+                                        int rc, int retval, int errnoval);
+
+_hidden int libxl__domain_suspend_common_callback(void *data);
+_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data);
+_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data);
+
 
 /* calls libxl__xc_domain_restore_done when done */
 _hidden void libxl__xc_domain_restore(libxl__egc *egc,
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 2f8db9f..1b481ab 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               &state->vm_generationid_addr, &dcs->callbacks);
     libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
 }
+
+void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
+                           unsigned long vm_generationid_addr)
+{
+    STATE_AO_GC(dss->ao);
+    int r;
+
+    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
+                       &dss->callbacks, dss->hvm, vm_generationid_addr);
+    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index afa0af6..4aea1c7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2817,7 +2817,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
+    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
@@ -2979,7 +2979,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     pid_t child = -1;
     int rc;
     int send_fd = -1, recv_fd = -1;
-    libxl_domain_suspend_info suspinfo;
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
@@ -3001,9 +3000,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    memset(&suspinfo, 0, sizeof(suspinfo));
-    suspinfo.flags |= XL_SUSPEND_LIVE;
-    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
+    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -6575,7 +6572,7 @@ int main_remus(int argc, char **argv)
     }
 
     /* Point of no return */
-    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
 
     /* If we are here, it means backup has failed/domain suspend failed.
      * Try to resume the domain and exit gracefully.
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzV-0005C1-VY; Tue, 26 Jun 2012 17:55:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzV-0005Bp-9y
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:53 +0000
Received: from [85.158.143.99:6132] by server-2.bemta-4.messagelabs.com id
	45/2A-17938-8A7F9EF4; Tue, 26 Jun 2012 17:55:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26107 invoked from network); 26 Jun 2012 17:55:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jd-BA; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005V0-9J;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:54:58 +0100
Message-ID: <1340733318-21099-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/21] libxc: xc_domain_restore,
	make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the one provider of this callback, in libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * No longer introduce function pointer typedefs into the libxc API.
---
 tools/libxc/xenguest.h  |    2 +-
 tools/libxl/libxl_dom.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 91d53f7..707e31c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
     /* callback to restore toolstack specific data */
-    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
             uint32_t size, void* data);
 
     /* to be provided as the last argument to each callback function */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a2e6655..6d63e0e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -469,13 +469,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = (libxl__gc *) data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
-    uint8_t *ptr = buf;
+    const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
     struct libxl__physmap_info* pi;
     char *xs_path;
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzf-0005KE-HE; Tue, 26 Jun 2012 17:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005CP-Pt
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:12328] by server-1.bemta-3.messagelabs.com id
	C0/90-14648-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19531 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000k8-1i; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vs-WF;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:10 +0100
Message-ID: <1340733318-21099-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/21] libxl: Add a gc to libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.

libxl_get_cpu_topology doesn't have one but does use NOGC.
Fix this by:
 - introducing an `out' label
 - replacing the only call to `return' with a suitable assignment
   to ret and a `goto out'.
 - adding uses of GC_INIT and GC_FREE.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6ec7471..a259d65 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3201,6 +3201,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
@@ -3213,7 +3214,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
     if (max_cpus == 0)
     {
         LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
-        return NULL;
+        ret = NULL;
+        goto out;
     }
 
     coremap = xc_hypercall_buffer_alloc
@@ -3258,6 +3260,8 @@ fail:
 
     if (ret)
         *nr = max_cpus;
+ out:
+    GC_FREE;
     return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzX-0005DQ-RX; Tue, 26 Jun 2012 17:55: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 1SjZzV-0005Br-Tp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:54 +0000
Received: from [85.158.143.99:51349] by server-3.bemta-4.messagelabs.com id
	C5/28-05808-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26160 invoked from network); 26 Jun 2012 17:55:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jc-Aa; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Uy-85;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:54:57 +0100
Message-ID: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v5 of my series to asyncify save/restore, rebased to tip and
retested.  There are minor changes to 3 patches, as discussed on-list,
marked with "*" below:

    01/21 libxc: xc_domain_restore, make toolstack_restore const-correct
    02/21 libxc: Do not segfault if (e.g.) switch_qemu_logdirty fails
    03/21 libxl: domain save: rename variables etc.
    04/21 libxl: domain restore: reshuffle, preparing for ao
  * 05/21 libxl: domain save: API changes for asynchrony
  * 06/21 libxl: domain save/restore: run in a separate process
    07/21 libxl: rename libxl_dom:save_helper to physmap_path
    08/21 libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
    09/21 libxl: wait for qemu to acknowledge logdirty command
    10/21 libxl: datacopier: provide "prefix data" facility
    11/21 libxl: prepare for asynchronous writing of qemu save file
    12/21 libxl: Make libxl__domain_save_device_model asynchronous
    13/21 libxl: Add a gc to libxl_get_cpu_topology
    14/21 libxl: Do not pass NULL as gc_opt; introduce NOGC
    15/21 libxl: Get compiler to warn about gc_opt==NULL
    16/21 xl: Handle return value from libxl_domain_suspend correctly
    17/21 libxl: do not leak dms->saved_state
    18/21 libxl: do not leak spawned middle children
    19/21 libxl: do not leak an event struct on ignored ao progress
  * 20/21 libxl: further fixups re LIBXL_DOMAIN_TYPE
  ! 21/21 libxl: DO NOT APPLY enforce prohibition on internal

All of these apart from the last have been acked and I intend to
commit those to xen-unstable.hg soon.

However, first I will invite Shriram to check that Remus is still
working.  (I can't conveniently do this with this message due to
shoddiness in git-send-email.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZza-0005Ep-7E; Tue, 26 Jun 2012 17:55:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005C0-1r
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:6179] by server-1.bemta-4.messagelabs.com id
	17/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26203 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kH-7l; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005W4-5M;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:13 +0100
Message-ID: <1340733318-21099-17-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/21] xl: Handle return value from
	libxl_domain_suspend correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl_domain_suspend returns a libxl error code.  So it must be
wrapped with MUST and not CHK_ERRNO.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/xl_cmdimpl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 4aea1c7..56e51aa 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2817,7 +2817,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzW-0005CD-B9; Tue, 26 Jun 2012 17:55:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzV-0005Br-Dw
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:53 +0000
Received: from [85.158.143.99:51327] by server-3.bemta-4.messagelabs.com id
	F4/28-05808-8A7F9EF4; Tue, 26 Jun 2012 17:55:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26135 invoked from network); 26 Jun 2012 17:55:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000je-Cn; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VA-As;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:54:59 +0100
Message-ID: <1340733318-21099-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/21] libxc: Do not segfault if (e.g.)
	switch_qemu_logdirty 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

In xc_domain_save the local variable `ob' is initialised to NULL.
There are then various startup actions.  Some of these `goto out' on
failure; for example the call to callbacks->switch_qemu_logdirty on
l.978.  However, out is used both by success and error paths.  So it
attempts (l.2043) to flush the current output buffer.  If ob has not
yet been assigned a non-NULL value, this segfaults.  So make the call
to outbuf_flush conditional on ob.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_domain_save.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index fcc7718..c359649 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -2040,7 +2040,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
     }
 
     /* Flush last write and discard cache for file. */
-    if ( outbuf_flush(xch, ob, io_fd) < 0 ) {
+    if ( ob && outbuf_flush(xch, ob, io_fd) < 0 ) {
         PERROR("Error when flushing output buffer");
         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 Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzb-0005G8-M6; Tue, 26 Jun 2012 17:55: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 1SjZzX-0005CP-5V
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:39504] by server-1.bemta-3.messagelabs.com id
	0F/80-14648-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19506 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jw-Ob; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VY-Nl;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:05 +0100
Message-ID: <1340733318-21099-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/21] libxl: provide libxl__xs_*_checked and
	libxl__xs_transaction_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 useful utility functions make dealing with xenstore a little
less painful.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Fixed typo `commited' in comment.

Changes in v3:
 * Fixed typo `transacton' in log messages.
---
 tools/libxl/libxl_internal.h |   38 +++++++++++++++++++++
 tools/libxl/libxl_xshelp.c   |   76 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1a7b526..b108d00 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -498,6 +498,44 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*----- "checked" xenstore access functions -----*/
+/* Each of these functions will check that it succeeded; if it
+ * fails it logs and returns ERROR_FAIL.
+ */
+
+/* On success, *result_out came from the gc.
+ * On error, *result_out is undefined.
+ * ENOENT counts as success but sets *result_out=0
+ */
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out);
+
+/* Does not include a trailing null.
+ * May usefully be combined with GCSPRINTF if the format string
+ * behaviour of libxl__xs_write is desirable. */
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string);
+
+/* ENOENT is not an error (even if the parent directories don't exist) */
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path);
+
+/* Transaction functions, best used together.
+ * The caller should initialise *t to 0 (XBT_NULL) before calling start.
+ * Each function leaves *t!=0 iff the transaction needs cleaning up.
+ *
+ * libxl__xs_transaction_commit returns:
+ *   <0  failure - a libxl error code
+ *   +1  commit conflict; transaction has been destroyed and caller
+ *        must go round again (call _start again and retry)
+ *    0  committed successfully
+ */
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t);
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t);
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t);
+
+
+
 /*
  * This is a recursive delete, from top to bottom. What this function does
  * is remove empty folders that contained the deleted entry.
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index c5b5364..993f527 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -135,6 +135,82 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
+int libxl__xs_read_checked(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, const char **result_out)
+{
+    char *result = libxl__xs_read(gc, t, path);
+    if (!result) {
+        if (errno != ENOENT) {
+            LOGE(ERROR, "xenstore read failed: `%s'", path);
+            return ERROR_FAIL;
+        }
+    }
+    *result_out = result;
+    return 0;
+}
+
+int libxl__xs_write_checked(libxl__gc *gc, xs_transaction_t t,
+                            const char *path, const char *string)
+{
+    size_t length = strlen(string);
+    if (!xs_write(CTX->xsh, t, path, string, length)) {
+        LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, string);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_rm_checked(libxl__gc *gc, xs_transaction_t t, const char *path)
+{
+    if (!xs_rm(CTX->xsh, t, path)) {
+        if (errno == ENOENT)
+            return 0;
+
+        LOGE(ERROR, "xenstore rm failed: `%s'", path);
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_start(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(!*t);
+    *t = xs_transaction_start(CTX->xsh);
+    if (!*t) {
+        LOGE(ERROR, "could not create xenstore transaction");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__xs_transaction_commit(libxl__gc *gc, xs_transaction_t *t)
+{
+    assert(*t);
+
+    if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        if (errno == EAGAIN)
+            return +1;
+
+        *t = 0;
+        LOGE(ERROR, "could not commit xenstore transaction");
+        return ERROR_FAIL;
+    }
+
+    *t = 0;
+    return 0;
+}
+
+void libxl__xs_transaction_abort(libxl__gc *gc, xs_transaction_t *t)
+{
+    if (!*t)
+        return;
+
+    if (!xs_transaction_end(CTX->xsh, *t, 1))
+        LOGE(ERROR, "could not abort xenstore transaction");
+
+    *t = 0;
+}
+
 int libxl__xs_path_cleanup(libxl__gc *gc, xs_transaction_t t, char *user_path)
 {
     unsigned int nb = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzd-0005Hs-EC; Tue, 26 Jun 2012 17:56:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005C0-HH
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51376] by server-1.bemta-4.messagelabs.com id
	47/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26193 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000k2-To; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vk-Rt;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:08 +0100
Message-ID: <1340733318-21099-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/21] libxl: prepare for asynchronous writing
	of qemu save 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

* Combine the various calls to libxl__device_model_savefile into one
  at the start of libxl__domain_suspend, storing the result in the
  dss.  Consequently a few functions take a dss instead of some or all
  of their other arguments.

* Make libxl__domain_save_device_model's API into an asynchronous
  style which takes a callback.  The function is, however, still
  synchronous; it will be made actually async in the next patch.

* Consequently make libxl__remus_domain_checkpoint_callback into an
  asynchronous callback.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c            |   54 ++++++++++++++++++++++++++----------
 tools/libxl/libxl_internal.h       |   18 ++++++++++--
 tools/libxl/libxl_save_msgs_gen.pl |    2 +-
 3 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4a588fb..439b4da 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -705,11 +705,13 @@ static void switch_logdirty_done(libxl__egc *egc,
 
 /*----- callbacks, called by xc_domain_save -----*/
 
-int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                       libxl__domain_suspend_state *dss)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
-    const char *filename = libxl__device_model_savefile(gc, domid);
+    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: {
@@ -878,7 +880,7 @@ int libxl__domain_suspend_common_callback(void *user)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -993,19 +995,32 @@ static int libxl__remus_domain_resume_callback(void *data)
     return 1;
 }
 
-static int libxl__remus_domain_checkpoint_callback(void *data)
+/*----- remus asynchronous checkpoint callback -----*/
+
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc);
+
+static void libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
-    if (dss->hvm &&
-        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
-        return 0;
+    if (dss->hvm) {
+        libxl__domain_save_device_model(egc, dss, remus_checkpoint_dm_saved);
+    } else {
+        remus_checkpoint_dm_saved(egc, dss, 0);
+    }
+}
 
+static void remus_checkpoint_dm_saved(libxl__egc *egc,
+                                      libxl__domain_suspend_state *dss, int rc)
+{
     /* TODO: Wait for disk and memory ack, release network buffer */
+    /* TODO: make this asynchronous */
     usleep(dss->interval * 1000);
-    return 1;
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, 1);
 }
 
 /*----- main code for suspending, in order of execution -----*/
@@ -1055,6 +1070,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
+    dss->dm_savefile = libxl__device_model_savefile(gc, domid);
 
     if (r_info != NULL) {
         dss->interval = r_info->interval;
@@ -1104,7 +1120,6 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
 
     /* Convenience aliases */
     const libxl_domain_type type = dss->type;
-    const uint32_t domid = dss->domid;
 
     if (rc)
         goto out;
@@ -1122,11 +1137,11 @@ void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
     }
 
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
-        rc = libxl__domain_suspend_device_model(gc, domid);
+        rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
         
-        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
-        if (rc) goto out;
+        libxl__domain_save_device_model(egc, dss, domain_suspend_done);
+        return;
     }
 
     rc = 0;
@@ -1135,14 +1150,22 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback)
 {
+    STATE_AO_GC(dss->ao);
     int rc, fd2 = -1, c;
     char buf[1024];
-    const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
 
+    dss->save_dm_callback = callback;
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    const int fd = dss->fd;
+
     if (stat(filename, &st) < 0)
     {
         LOG(ERROR, "Unable to stat qemu save file\n");
@@ -1184,7 +1207,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return rc;
+
+    dss->save_dm_callback(egc, dss, rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8b582e4..e95892a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -824,10 +824,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 
 _hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
                                      uint32_t size, void *data);
-_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
-_hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
+
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -1869,6 +1867,8 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
+typedef void libxl__save_device_model_cb(libxl__egc*,
+                                         libxl__domain_suspend_state*, int rc);
 
 typedef struct libxl__logdirty_switch {
     const char *cmd;
@@ -1895,9 +1895,12 @@ struct libxl__domain_suspend_state {
     int hvm;
     int xcflags;
     int guest_responded;
+    const char *dm_savefile;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
     libxl__logdirty_switch logdirty;
+    /* private for libxl__domain_save_device_model */
+    libxl__save_device_model_cb *save_dm_callback;
 };
 
 
@@ -2053,6 +2056,15 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
+/* Each time the dm needs to be saved, we must call suspend and then save */
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
+                                           libxl__domain_suspend_state *dss);
+_hidden void libxl__domain_save_device_model(libxl__egc *egc,
+                                     libxl__domain_suspend_state *dss,
+                                     libxl__save_device_model_cb *callback);
+
+_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+
 
 /*
  * Convenience macros.
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index a9ac808..ee126c7 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -25,7 +25,7 @@ our @msgs = (
                                                 'unsigned long', 'total'] ],
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
-    [  5, 'scxW',   "checkpoint", [] ],      
+    [  5, 'scxA',   "checkpoint", [] ],      
     [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzf-0005Km-TF; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CN-SU
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:56 +0000
Received: from [85.158.139.83:65421] by server-9.bemta-5.messagelabs.com id
	48/94-01069-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12348 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000k6-0d; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vo-TR;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:09 +0100
Message-ID: <1340733318-21099-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/21] libxl: Make
	libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in series v3:
 * Improve one more a debugging message.
---
 tools/libxl/libxl_dom.c      |  100 +++++++++++++++++++++++++++---------------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 439b4da..abc5932 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1150,15 +1150,17 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
 void libxl__domain_save_device_model(libxl__egc *egc,
                                      libxl__domain_suspend_state *dss,
                                      libxl__save_device_model_cb *callback)
 {
     STATE_AO_GC(dss->ao);
-    int rc, fd2 = -1, c;
-    char buf[1024];
     struct stat st;
     uint32_t qemu_state_len;
+    int rc;
 
     dss->save_dm_callback = callback;
 
@@ -1166,49 +1168,77 @@ void libxl__domain_save_device_model(libxl__egc *egc,
     const char *const filename = dss->dm_savefile;
     const int fd = dss->fd;
 
-    if (stat(filename, &st) < 0)
+    libxl__datacopier_state *dc = &dss->save_dm_datacopier;
+    memset(dc, 0, sizeof(*dc));
+    dc->readwhat = GCSPRINTF("qemu save file %s", filename);
+    dc->ao = ao;
+    dc->readfd = -1;
+    dc->writefd = fd;
+    dc->maxsz = INT_MAX;
+    dc->copywhat = GCSPRINTF("qemu save file for domain %"PRIu32, dss->domid);
+    dc->writewhat = "save/migration stream";
+    dc->callback = save_device_model_datacopier_done;
+
+    dc->readfd = open(filename, O_RDONLY);
+    if (dc->readfd < 0) {
+        LOGE(ERROR, "unable to open %s", dc->readwhat);
+        goto out;
+    }
+
+    if (fstat(dc->readfd, &st))
     {
-        LOG(ERROR, "Unable to stat qemu save file\n");
-        rc = ERROR_FAIL;
+        LOGE(ERROR, "unable to fstat %s", dc->readwhat);
+        goto out;
+    }
+
+    if (!S_ISREG(st.st_mode)) {
+        LOG(ERROR, "%s is not a plain file!", dc->readwhat);
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "%s is %d bytes", dc->readwhat, qemu_state_len);
 
-    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
-    if (rc)
-        goto out;
+    rc = libxl__datacopier_start(dc);
+    if (rc) goto out;
 
-    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
-                            "saved-state file", "saved-state length");
-    if (rc)
-        goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 QEMU_SIGNATURE, strlen(QEMU_SIGNATURE));
 
-    fd2 = open(filename, O_RDONLY);
-    if (fd2 < 0) {
-        LOGE(ERROR, "Unable to open qemu save file\n");
-        goto out;
-    }
-    while ((c = read(fd2, buf, sizeof(buf))) != 0) {
-        if (c < 0) {
-            if (errno == EINTR)
-                continue;
-            rc = errno;
-            goto out;
-        }
-        rc = libxl_write_exactly(
-            CTX, fd, buf, c, "saved-state file", "qemu state");
-        if (rc)
-            goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 &qemu_state_len, sizeof(qemu_state_len));
+    return;
+
+ out:
+    save_device_model_datacopier_done(egc, dc, -1, 0);
+}
+
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(dc, *dss, save_dm_datacopier);
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    int our_rc = 0;
+    int rc;
+
+    libxl__datacopier_kill(dc);
+
+    if (onwrite || errnoval)
+        our_rc = ERROR_FAIL;
+
+    if (dc->readfd >= 0) {
+        close(dc->readfd);
+        dc->readfd = -1;
     }
-    rc = 0;
-out:
-    if (fd2 >= 0) close(fd2);
-    unlink(filename);
 
-    dss->save_dm_callback(egc, dss, rc);
+    rc = libxl__remove_file(gc, filename);
+    if (!our_rc) our_rc = rc;
+
+    dss->save_dm_callback(egc, dss, our_rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e95892a..c9b4189 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1901,6 +1901,7 @@ struct libxl__domain_suspend_state {
     libxl__logdirty_switch logdirty;
     /* private for libxl__domain_save_device_model */
     libxl__save_device_model_cb *save_dm_callback;
+    libxl__datacopier_state save_dm_datacopier;
 };
 
 
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzc-0005Gw-Fj; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CN-4O
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:65389] by server-9.bemta-5.messagelabs.com id
	90/94-01069-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12321 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jz-Qn; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vc-OL;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:06 +0100
Message-ID: <1340733318-21099-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/21] libxl: wait for qemu to acknowledge
	logdirty 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

The current migration code in libxl instructs qemu to start or stop
logdirty, but it does not wait for an acknowledgement from qemu before
continuing.  This might lead to memory corruption (!)

Fix this by waiting for qemu to acknowledge the command.

Unfortunately the necessary ao arrangements for waiting for this
command are unique because qemu has a special protocol for this
particular operation.

Also, this change means that the switch_qemu_logdirty callback
implementation in libxl can no longer synchronously produce its return
value, as it now needs to wait for xenstore.  So we tell the
marshalling code generator that it is a message which does not need a
reply.  This turns the callback function called by the marshaller into
one which returns void; the callback function arranges to later
explicitly sends the reply to the helper, when the xs watch triggers
and the appropriate value is read from xenstore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Correct the sense of the return value from switch_qemu_logdirty.
 * Fix a somewhat mendacious log message.
---
 tools/libxl/libxl_dom.c            |  177 +++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h       |   18 ++++-
 tools/libxl/libxl_save_callout.c   |    8 ++
 tools/libxl/libxl_save_msgs_gen.pl |    7 +-
 4 files changed, 194 insertions(+), 16 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ba58c45..4a588fb 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -530,30 +530,181 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
 static void domain_suspend_done(libxl__egc *egc,
                         libxl__domain_suspend_state *dss, int rc);
 
-/*----- callbacks, called by xc_domain_save -----*/
+/*----- complicated callback, called by xc_domain_save -----*/
+
+/*
+ * We implement the other end of protocol for controlling qemu-dm's
+ * logdirty.  There is no documentation for this protocol, but our
+ * counterparty's implementation is in
+ * qemu-xen-traditional.git:xenstore.c in the function
+ * xenstore_process_logdirty_event
+ */
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs);
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss, int ok);
 
-int libxl__domain_suspend_common_switch_qemu_logdirty
+static void logdirty_init(libxl__logdirty_switch *lds)
+{
+    lds->cmd_path = 0;
+    libxl__ev_xswatch_init(&lds->watch);
+    libxl__ev_time_init(&lds->timeout);
+}
+
+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);
+    libxl__logdirty_switch *lds = &dss->logdirty;
     STATE_AO_GC(dss->ao);
-    char *path;
-    bool rc;
+    int rc;
+    xs_transaction_t t = 0;
+    const char *got;
 
-    path = libxl__sprintf(gc,
+    if (!lds->cmd_path) {
+        lds->cmd_path = GCSPRINTF(
                    "/local/domain/0/device-model/%u/logdirty/cmd", domid);
-    if (!path)
-        return 1;
+        lds->ret_path = GCSPRINTF(
+                   "/local/domain/0/device-model/%u/logdirty/ret", domid);
+    }
+    lds->cmd = enable ? "enable" : "disable";
 
-    if (enable)
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
-    else
-        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
+    rc = libxl__ev_xswatch_register(gc, &lds->watch,
+                                switch_logdirty_xswatch, lds->ret_path);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_register_rel(gc, &lds->timeout,
+                                switch_logdirty_timeout, 10*1000);
+    if (rc) goto out;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->cmd_path, &got);
+        if (rc) goto out;
+
+        if (got) {
+            const char *got_ret;
+            rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got_ret);
+            if (rc) goto out;
 
-    return rc ? 0 : 1;
+            if (strcmp(got, got_ret)) {
+                LOG(ERROR,"controlling logdirty: qemu was already sent"
+                    " command `%s' (xenstore path `%s') but result is `%s'",
+                    got, lds->cmd_path, got_ret ? got_ret : "<none>");
+                rc = ERROR_FAIL;
+                goto out;
+            }
+            rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+            if (rc) goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_write_checked(gc, t, lds->cmd_path, lds->cmd);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t);
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+    /* OK, wait for some callback */
+    return;
+
+ out:
+    LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+    switch_logdirty_done(egc,dss,-1);
+}
+
+static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                                    const struct timeval *requested_abs)
+{
+    libxl__domain_suspend_state *dss = CONTAINER_OF(ev, *dss, logdirty.timeout);
+    STATE_AO_GC(dss->ao);
+    LOG(ERROR,"logdirty switch: wait for device model timed out");
+    switch_logdirty_done(egc,dss,-1);
 }
 
+static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
+                            const char *watch_path, const char *event_path)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(watch, *dss, logdirty.watch);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+    STATE_AO_GC(dss->ao);
+    const char *got;
+    xs_transaction_t t = 0;
+    int rc;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
+        if (rc) goto out;
+
+        if (!got) {
+            rc = +1;
+            goto out;
+        }
+
+        if (strcmp(got, lds->cmd)) {
+            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
+                " (xenstore paths `%s' / `%s')", lds->cmd, got,
+                lds->cmd_path, lds->ret_path);
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
+        if (rc) goto out;
+
+        rc = libxl__xs_transaction_commit(gc, &t); 
+        if (!rc) break;
+        if (rc<0) goto out;
+    }
+
+ out:
+    /* rc < 0: error
+     * rc == 0: ok, we are done
+     * rc == +1: need to keep waiting
+     */
+    libxl__xs_transaction_abort(gc, &t);
+
+    if (!rc) {
+        switch_logdirty_done(egc,dss,0);
+    } else if (rc < 0) {
+        LOG(ERROR,"logdirty switch: failed (rc=%d)",rc);
+        switch_logdirty_done(egc,dss,-1);
+    }
+}
+
+static void switch_logdirty_done(libxl__egc *egc,
+                                 libxl__domain_suspend_state *dss,
+                                 int broke)
+{
+    STATE_AO_GC(dss->ao);
+    libxl__logdirty_switch *lds = &dss->logdirty;
+
+    libxl__ev_xswatch_deregister(gc, &lds->watch);
+    libxl__ev_time_deregister(gc, &lds->timeout);
+
+    libxl__xc_domain_saverestore_async_callback_done(egc, &dss->shs, broke);
+}
+
+/*----- callbacks, called by xc_domain_save -----*/
+
 int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -875,6 +1026,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     libxl__srm_save_autogen_callbacks *const callbacks =
         &dss->shs.callbacks.save.a;
 
+    logdirty_init(&dss->logdirty);
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b108d00..05bed01 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1864,6 +1864,14 @@ typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 typedef void libxl__domain_suspend_cb(libxl__egc*,
                                       libxl__domain_suspend_state*, int rc);
 
+typedef struct libxl__logdirty_switch {
+    const char *cmd;
+    const char *cmd_path;
+    const char *ret_path;
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+} libxl__logdirty_switch;
+
 struct libxl__domain_suspend_state {
     /* set by caller of libxl__domain_suspend */
     libxl__ao *ao;
@@ -1883,6 +1891,7 @@ struct libxl__domain_suspend_state {
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
     libxl__save_helper_state shs;
+    libxl__logdirty_switch logdirty;
 };
 
 
@@ -2013,8 +2022,15 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 _hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
+/* Used by asynchronous callbacks: ie ones which xc regards as
+ * returning a value, but which we want to handle asynchronously.
+ * Such functions' actual callback function return void in libxl
+ * When they are ready to indicate completion, they call this. */
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value);
+
 _hidden int libxl__domain_suspend_common_callback(void *data);
-_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+_hidden void libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data);
 _hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data);
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 19fff1b..6332beb 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -142,6 +142,14 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
 }
 
 
+void libxl__xc_domain_saverestore_async_callback_done(libxl__egc *egc,
+                           libxl__save_helper_state *shs, int return_value)
+{
+    shs->egc = egc;
+    libxl__srm_callout_sendreply(return_value, shs);
+    shs->egc = 0;
+}
+
 /*----- helper execution -----*/
 
 static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
index c45986e..a9ac808 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -14,6 +14,7 @@ our @msgs = (
     #   x  - function pointer is in struct {save,restore}_callbacks
     #         and its null-ness needs to be passed through to the helper's xc
     #   W  - needs a return value; callback is synchronous
+    #   A  - needs a return value; callback is asynchronous
     [  1, 'sr',     "log",                   [qw(uint32_t level
                                                  uint32_t errnoval
                                                  STRING context
@@ -25,7 +26,7 @@ our @msgs = (
     [  3, 'scxW',   "suspend", [] ],         
     [  4, 'scxW',   "postcopy", [] ],        
     [  5, 'scxW',   "checkpoint", [] ],      
-    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+    [  6, 'scxA',   "switch_qemu_logdirty",  [qw(int domid
                                               unsigned enable)] ],
     #                toolstack_save          done entirely `by hand'
     [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
@@ -262,7 +263,7 @@ foreach my $msginfo (@msgs) {
         $f_more_sr->("        int r;\n");
     }
 
-    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_helper = $flags =~ m/[WA]/ ? 'int' : 'void';
     my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
     my $c_decl = '(';
     my $c_callback_args = '';
@@ -351,7 +352,7 @@ END_ALWAYS
     assert(len == allocd);
     ${transmit}(buf, len, user);
 ");
-    if ($flags =~ m/W/) {
+    if ($flags =~ m/[WA]/) {
 	f_more("${encode}_$name",
                (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
     int r = ${helper}_getreply(user);
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZze-0005Ih-5y; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005Ca-Ct
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:2869] by server-12.bemta-5.messagelabs.com id
	BD/BD-25233-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12341 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kL-9W; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005W8-7C;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:14 +0100
Message-ID: <1340733318-21099-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/21] libxl: do not leak dms->saved_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

This was allocated using asprintf but never freed.  Use GCSPRINTF.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b95a2fe..2d21be5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -801,9 +801,8 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
         goto out;
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
+        state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
     }
 
 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 Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzf-0005Je-0C; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CW-Av
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51371] by server-1.bemta-4.messagelabs.com id
	36/E3-24392-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26179 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000js-Lq; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VQ-JR;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:03 +0100
Message-ID: <1340733318-21099-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v5:
 * assert that preserve_fds are >2.

Changes in v4:
 * Migration stream fd is handled specially by the run_helper
   function, rather than simply being a numarg.  Specifically:
     - dup it to a safe fd number if necessary.
     - clear cloexec flag fd before execing helper
 * Toolstack data fd argument to run_helper replaced with
   generic preserve_fds array, which get cloexec cleared.
 * libxl__xc_domain_save uses supplied callback function pointer,
   rather than calling libxl__toolstack_save directly;
   toolstack data save callback is only supplied to libxc if
   in-libxl caller supplied a callback.
 * libxl-save-helper is not needlessly linked against libxl.
 * Code which prepares pipes for helper clarified.
 * Deal properly with, and log properly, POLLPRI/POLLERR on
   pipe to save helper.
 * Spelling fix in perl script comment.
 * In message generator, use better names for the ends of serial
   conditional here documents.
 * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.
---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   22 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   36 ++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  368 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  281 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1147 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_save_helper.c
 create mode 100755 tools/libxl/libxl_save_msgs_gen.pl

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..ddc2624 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -169,7 +183,9 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9c3c671..7b92539 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -662,7 +662,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -702,7 +703,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -722,10 +722,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c44dec0..b52d29a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,16 +467,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -529,9 +533,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -597,9 +602,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -739,9 +745,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -810,6 +816,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -864,7 +872,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -925,8 +934,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -935,10 +943,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7cf1b04..1a7b526 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..19fff1b 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,30 @@
 
 #include "libxl_internal.h"
 
+/* stream_fd is as from the caller (eventually, the application).
+ * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
+ * The actual fd value is not included in the supplied argnums; rather
+ * it will be automatically supplied by run_helper as the 2nd argument.
+ *
+ * preserve_fds are fds that the caller is intending to pass to the
+ * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
+ * An entry may be -1 in which case it will be ignored.
+ */
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg,
+                       int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +51,344 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc, toolstack_data_fd = -1;
+    uint32_t toolstack_data_len = 0;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    if (dss->shs.callbacks.save.toolstack_save) {
+        r = dss->shs.callbacks.save.toolstack_save
+            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        dss->shs.toolstack_data_file = tmpfile();
+        if (!dss->shs.toolstack_data_file) {
+            LOGE(ERROR, "cannot create toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+        r = libxl_write_exactly(CTX, toolstack_data_fd,
+                                toolstack_data_buf, toolstack_data_len,
+                                "toolstack data tmpfile", 0);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        r = lseek(toolstack_data_fd, 0, SEEK_SET);
+        if (r) {
+            LOGE(ERROR, "rewind toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    const unsigned long argnums[] = {
+        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               &toolstack_data_fd, 1,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[4 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    const char **stream_fd_arg = arg++;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    int childfd;
+    for (childfd=0; childfd<2; childfd++) {
+        /* Setting up the pipe for the child's fd childfd */
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
+        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
+        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
+        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        if (stream_fd <= 2) {
+            stream_fd = dup(stream_fd);
+            if (stream_fd < 0) {
+                LOGE(ERROR,"dup migration stream fd");
+                exit(-1);
+            }
+        }
+        libxl_fd_set_cloexec(CTX, stream_fd, 0);
+        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
+
+        for (i=0; i<num_preserve_fds; i++)
+            if (preserve_fds[i] >= 0) {
+                assert(preserve_fds[i] > 2);
+                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
+            }
+
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & (POLLERR|POLLPRI)) {
+        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
+            shs->stdout_what, revents);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..3bdfa28
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,281 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    *buf = xmalloc(toolstack_save_len);
+    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    toolstack_save_fd = -1;
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        if (toolstack_save_fd >= 0)
+            helper_save_callbacks.toolstack_save = toolstack_save_cb;
+
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..c45986e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,397 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copious debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .=
+        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END_BOTH
+
+#include "libxl_internal.h"
+
+END_CALLOUT
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END_HELPER
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END_ALWAYS
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END_DEBUG
+    switch (mtype) {
+
+END_ALWAYS
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END_DEBUG
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END_ALWAYS
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name",
+               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
+    int r = ${helper}_getreply(user);
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END_DEBUG
+    return r;
+END_ALWAYS
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzZ-0005EO-EM; Tue, 26 Jun 2012 17:55: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 1SjZzW-0005CG-Tq
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:39478] by server-5.bemta-3.messagelabs.com id
	D3/94-01572-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19492 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000k0-SC; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vg-Pw;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:07 +0100
Message-ID: <1340733318-21099-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/21] libxl: datacopier: provide "prefix data"
	facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used to write the qemu data banner to the save/migration
stream.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Clarified and added comments explaining the `immediately'
   constraint and the lack of a reentrancy/threading hazard.
 * Fixed subject line typo.
---
 tools/libxl/libxl_aoutils.c  |   22 ++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index ee0df57..7f8d6d3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -74,6 +74,28 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
     }
 }
 
+void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
+                                  const void *data, size_t len)
+{
+    libxl__datacopier_buf *buf;
+    /*
+     * It is safe for this to be called immediately after _start, as
+     * is documented in the public comment.  _start's caller must have
+     * the ctx locked, so other threads don't get to mess with the
+     * contents, and the fd events cannot happen reentrantly.  So we
+     * are guaranteed to beat the first data from the read fd.
+     */
+
+    assert(len < dc->maxsz - dc->used);
+
+    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf->used = len;
+    memcpy(buf->buf, data, len);
+
+    dc->used += len;
+    LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+}
+
 static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
                                 int fd, short events, short revents) {
     libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 05bed01..8b582e4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1811,6 +1811,12 @@ _hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
 _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
+/* Inserts literal data into the output stream.  The data is copied.
+ * May safely be used only immediately after libxl__datacopier_start
+ * (before the ctx is unlocked).  But may be called multiple times.
+ * NB exceeding maxsz will fail an assertion! */
+_hidden void libxl__datacopier_prefixdata(libxl__egc*, libxl__datacopier_state*,
+                                          const void *data, size_t len);
 
 /*----- Save/restore helper (used by creation and suspend) -----*/
 
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzd-0005IJ-QD; Tue, 26 Jun 2012 17:56:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005CT-BW
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:65405] by server-8.bemta-5.messagelabs.com id
	0D/59-10278-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12336 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231569"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kF-5c; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005W0-3l;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:12 +0100
Message-ID: <1340733318-21099-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/21] libxl: Get compiler to warn about
	gc_opt==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

Since it used to be legal to pass gc_opt==NULL, and there are various
patches floating about and under development which do so, add a
compiler annotation which makes the build fail when that is done.

This turns a runtime crash into a build failure, and should ensure
that we don't accidentally commit a broken combination of patches.

This is something of an annoying approach because it adds a macro
invocation to the RHS of every declaration of a function taking a
gc_opt.  So it should be reverted after Xen 4.2rc1.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index aa150b5..85f4bc6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * psuedo-gc.
  */
 /* register ptr in gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
+
+#define NN1 __attribute__((nonnull(1)))
+ /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
+  * warn about this if any slip through. */
+
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
 
 /* Each of these logs errors and returns a libxl error code.
  * They do not mind if path is already removed.
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzf-0005KE-HE; Tue, 26 Jun 2012 17:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005CP-Pt
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:12328] by server-1.bemta-3.messagelabs.com id
	C0/90-14648-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19531 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000k8-1i; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vs-WF;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:10 +0100
Message-ID: <1340733318-21099-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/21] libxl: Add a gc to libxl_get_cpu_topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.

libxl_get_cpu_topology doesn't have one but does use NOGC.
Fix this by:
 - introducing an `out' label
 - replacing the only call to `return' with a suitable assignment
   to ret and a `goto out'.
 - adding uses of GC_INIT and GC_FREE.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6ec7471..a259d65 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3201,6 +3201,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
@@ -3213,7 +3214,8 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
     if (max_cpus == 0)
     {
         LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
-        return NULL;
+        ret = NULL;
+        goto out;
     }
 
     coremap = xc_hypercall_buffer_alloc
@@ -3258,6 +3260,8 @@ fail:
 
     if (ret)
         *nr = max_cpus;
+ out:
+    GC_FREE;
     return ret;
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZze-0005JB-Hx; Tue, 26 Jun 2012 17:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005CU-DZ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:39500] by server-4.bemta-3.messagelabs.com id
	B1/E8-17105-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19495 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kV-Gh; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WP-Fp;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:18 +0100
Message-ID: <1340733318-21099-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce prohibition
	on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 .gitignore                        |    1 +
 .hgignore                         |    1 +
 tools/libxl/Makefile              |   16 +++++++++++++---
 tools/libxl/check-libxl-api-rules |   15 +++++++++++++++
 tools/libxl/gentypes.py           |    1 -
 tools/libxl/libxl.h               |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h         |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h      |   14 ++++++++++----
 8 files changed, 79 insertions(+), 24 deletions(-)
 create mode 100755 tools/libxl/check-libxl-api-rules

diff --git a/.gitignore b/.gitignore
index 3451e52..22faeaa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -187,6 +187,7 @@ tools/libxl/xl
 tools/libxl/testenum
 tools/libxl/testenum.c
 tools/libxl/tmp.*
+tools/libxl/libxl.api-for-check
 tools/libaio/src/*.ol
 tools/libaio/src/*.os
 tools/misc/cpuperf/cpuperf-perfcntr
diff --git a/.hgignore b/.hgignore
index 05304ea..5756bf8 100644
--- a/.hgignore
+++ b/.hgignore
@@ -185,6 +185,7 @@
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
 ^tools/libxl/.*\.new$
+^tools/libxl/libxl\.api-for-check
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index ddc2624..1c8b62b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
@@ -74,7 +74,8 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
-	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h \
+        libxl.api-ok
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
@@ -113,6 +114,15 @@ $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 genpath-target = $(call buildmakevars2file,_paths.h.tmp)
 $(eval $(genpath-target))
 
+libxl.api-ok: check-libxl-api-rules libxl.api-for-check
+	perl $^
+
+%.api-for-check: %.h
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
+		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
+		>$@.new
+	$(call move-if-changed,$@.new,$@)
+
 _paths.h: genpath
 	sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" $@.tmp >$@.2.tmp
 	rm -f $@.tmp
@@ -200,7 +210,7 @@ install: all
 .PHONY: clean
 clean:
 	$(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS)
-	$(RM) -f _*.c *.pyc _paths.*.tmp
+	$(RM) -f _*.c *.pyc _paths.*.tmp *.api-for-check
 	$(RM) -f testidl.c.new testidl.c
 #	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
 
diff --git a/tools/libxl/check-libxl-api-rules b/tools/libxl/check-libxl-api-rules
new file mode 100755
index 0000000..e056573
--- /dev/null
+++ b/tools/libxl/check-libxl-api-rules
@@ -0,0 +1,15 @@
+#!/usr/bin/perl -w
+use strict;
+our $needed=0;
+while (<>) {
+      if (m/libxl_asyncop_how[^;]/) {
+         $needed=1;
+      }      
+      if (m/LIBXL_EXTERNAL_CALLERS_ONLY/) {
+          $needed=0;
+      }
+      next unless $needed;
+      if (m/\;/) {
+          die "$ARGV:$.:missing LIBXL_EXTERNAL_CALLERS_ONLY";
+      }
+}
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 10d7115..1a32d9e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 36c75ed..6c859bc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1538,10 +1544,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzf-0005Km-TF; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CN-SU
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:56 +0000
Received: from [85.158.139.83:65421] by server-9.bemta-5.messagelabs.com id
	48/94-01069-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12348 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000k6-0d; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vo-TR;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:09 +0100
Message-ID: <1340733318-21099-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/21] libxl: Make
	libxl__domain_save_device_model asynchronous
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in series v3:
 * Improve one more a debugging message.
---
 tools/libxl/libxl_dom.c      |  100 +++++++++++++++++++++++++++---------------
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 439b4da..abc5932 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1150,15 +1150,17 @@ out:
     domain_suspend_done(egc, dss, rc);
 }
 
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval);
+
 void libxl__domain_save_device_model(libxl__egc *egc,
                                      libxl__domain_suspend_state *dss,
                                      libxl__save_device_model_cb *callback)
 {
     STATE_AO_GC(dss->ao);
-    int rc, fd2 = -1, c;
-    char buf[1024];
     struct stat st;
     uint32_t qemu_state_len;
+    int rc;
 
     dss->save_dm_callback = callback;
 
@@ -1166,49 +1168,77 @@ void libxl__domain_save_device_model(libxl__egc *egc,
     const char *const filename = dss->dm_savefile;
     const int fd = dss->fd;
 
-    if (stat(filename, &st) < 0)
+    libxl__datacopier_state *dc = &dss->save_dm_datacopier;
+    memset(dc, 0, sizeof(*dc));
+    dc->readwhat = GCSPRINTF("qemu save file %s", filename);
+    dc->ao = ao;
+    dc->readfd = -1;
+    dc->writefd = fd;
+    dc->maxsz = INT_MAX;
+    dc->copywhat = GCSPRINTF("qemu save file for domain %"PRIu32, dss->domid);
+    dc->writewhat = "save/migration stream";
+    dc->callback = save_device_model_datacopier_done;
+
+    dc->readfd = open(filename, O_RDONLY);
+    if (dc->readfd < 0) {
+        LOGE(ERROR, "unable to open %s", dc->readwhat);
+        goto out;
+    }
+
+    if (fstat(dc->readfd, &st))
     {
-        LOG(ERROR, "Unable to stat qemu save file\n");
-        rc = ERROR_FAIL;
+        LOGE(ERROR, "unable to fstat %s", dc->readwhat);
+        goto out;
+    }
+
+    if (!S_ISREG(st.st_mode)) {
+        LOG(ERROR, "%s is not a plain file!", dc->readwhat);
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "%s is %d bytes", dc->readwhat, qemu_state_len);
 
-    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
-    if (rc)
-        goto out;
+    rc = libxl__datacopier_start(dc);
+    if (rc) goto out;
 
-    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
-                            "saved-state file", "saved-state length");
-    if (rc)
-        goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 QEMU_SIGNATURE, strlen(QEMU_SIGNATURE));
 
-    fd2 = open(filename, O_RDONLY);
-    if (fd2 < 0) {
-        LOGE(ERROR, "Unable to open qemu save file\n");
-        goto out;
-    }
-    while ((c = read(fd2, buf, sizeof(buf))) != 0) {
-        if (c < 0) {
-            if (errno == EINTR)
-                continue;
-            rc = errno;
-            goto out;
-        }
-        rc = libxl_write_exactly(
-            CTX, fd, buf, c, "saved-state file", "qemu state");
-        if (rc)
-            goto out;
+    libxl__datacopier_prefixdata(egc, dc,
+                                 &qemu_state_len, sizeof(qemu_state_len));
+    return;
+
+ out:
+    save_device_model_datacopier_done(egc, dc, -1, 0);
+}
+
+static void save_device_model_datacopier_done(libxl__egc *egc,
+     libxl__datacopier_state *dc, int onwrite, int errnoval)
+{
+    libxl__domain_suspend_state *dss =
+        CONTAINER_OF(dc, *dss, save_dm_datacopier);
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const char *const filename = dss->dm_savefile;
+    int our_rc = 0;
+    int rc;
+
+    libxl__datacopier_kill(dc);
+
+    if (onwrite || errnoval)
+        our_rc = ERROR_FAIL;
+
+    if (dc->readfd >= 0) {
+        close(dc->readfd);
+        dc->readfd = -1;
     }
-    rc = 0;
-out:
-    if (fd2 >= 0) close(fd2);
-    unlink(filename);
 
-    dss->save_dm_callback(egc, dss, rc);
+    rc = libxl__remove_file(gc, filename);
+    if (!our_rc) our_rc = rc;
+
+    dss->save_dm_callback(egc, dss, our_rc);
 }
 
 static void domain_suspend_done(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e95892a..c9b4189 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1901,6 +1901,7 @@ struct libxl__domain_suspend_state {
     libxl__logdirty_switch logdirty;
     /* private for libxl__domain_save_device_model */
     libxl__save_device_model_cb *save_dm_callback;
+    libxl__datacopier_state save_dm_datacopier;
 };
 
 
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzY-0005Dy-Jw; Tue, 26 Jun 2012 17:55:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzW-0005C0-Ap
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:54 +0000
Received: from [85.158.143.99:6158] by server-1.bemta-4.messagelabs.com id
	B4/E3-24392-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26165 invoked from network); 26 Jun 2012 17:55:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jj-GD; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VE-CV;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:00 +0100
Message-ID: <1340733318-21099-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/21] libxl: domain save: rename variables etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Preparatory work for making domain suspend asynchronous:

* Rename `struct suspendinfo' to `libxl__domain_suspend_state'
  and move it to libxl_internal.h.

* Rename variables `si' to `dss'.

* Change the stack-allocated state and callbacks from
    struct suspendinfo si;
    struct save_callbacks callbacks;
    struct restore_callbacks callbacks;
  to
    libxl__domain_suspend_state dss[1];
    struct save_callbacks callbacks[1];
    struct restore_callbacks callbacks[1];
  so that it may be referred to as a pointer variable everywhere.

* Rename the variable `flags' (in libxl__domain_suspend_state) to
  `xcflags', to help distinguish it from the other `flags' which is
  passed in from the calling application in libxl_domain_suspend_info.
  Abolish the local variable in libxl__domain_suspend_common, as it
  can use the one in the dss.

* Move the prototypes of suspend-related functions in libxl_internal.h
  to after the definition of the state struct.

* Replace several ctx variables with gc variables and
  consequently references to ctx with CTX.  Change references
  to `dss->gc' in the functional code to simply `gc'.

* Use LOG* rather than LIBXL__LOG* in a number of places.

* In libxl__domain_save_device_model use `rc' instead of `ret'.

* Introduce and use `gc' and `domid' in
  libxl__domain_suspend_common_callback.

* Wrap some long lines.

* Add an extra pair of parens for clarity in a flag test.

* Remove two pointless casts from void* to a struct*.

No functional change whatsoever.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Abolish local variables `xcflags' and `hvm' in
   libxl__domain_suspend_common; just use dss->xcflags and dss->hvm
   instead and hence do not lose some of the changes to xcflags.

Changes in v2:
 * Make callbacks into arrays (for pointerisation) too.
 * Updated to cope with new remus code.
 * Fixed typo in commit message.
---
 tools/libxl/libxl_dom.c      |  261 ++++++++++++++++++++----------------------
 tools/libxl/libxl_internal.h |   30 ++++-
 2 files changed, 151 insertions(+), 140 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6d63e0e..4202b4b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -472,7 +472,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
-    libxl__gc *gc = (libxl__gc *) data;
+    libxl__gc *gc = data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
     const uint8_t *ptr = buf;
@@ -533,7 +533,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
-    struct restore_callbacks callbacks;
+    struct restore_callbacks callbacks[1];
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -541,8 +541,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks.toolstack_restore = libxl__toolstack_restore;
-        callbacks.data = gc;
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -558,7 +558,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, &callbacks);
+                           &state->vm_generationid_addr, callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -566,33 +566,23 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-struct suspendinfo {
-    libxl__gc *gc;
-    xc_evtchn *xce; /* event channel handle */
-    int suspend_eventchn;
-    int domid;
-    int hvm;
-    unsigned int flags;
-    int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
-    int interval; /* checkpoint interval (for Remus) */
-};
-
-static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
+static int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     char *path;
     bool rc;
 
-    path = libxl__sprintf(si->gc, "/local/domain/0/device-model/%u/logdirty/cmd", domid);
+    path = libxl__sprintf(gc,
+                   "/local/domain/0/device-model/%u/logdirty/cmd", domid);
     if (!path)
         return 1;
 
     if (enable)
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "enable", strlen("enable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
     else
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "disable", strlen("disable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
 
     return rc ? 0 : 1;
 }
@@ -647,53 +637,56 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
 
 static int libxl__domain_suspend_common_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
     int watchdog;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
 
-    if (si->hvm) {
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->hvm) {
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
     }
 
-    if ((hvm_s_state == 0) && (si->suspend_eventchn >= 0)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via event channel",
-                   si->hvm ? "PVHVM" : "PV");
-        ret = xc_evtchn_notify(si->xce, si->suspend_eventchn);
+    if ((hvm_s_state == 0) && (dss->suspend_eventchn >= 0)) {
+        LOG(DEBUG, "issuing %s suspend request via event channel",
+            dss->hvm ? "PVHVM" : "PV");
+        ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_evtchn_notify failed ret=%d", ret);
+            LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
             return 0;
         }
-        ret = xc_await_suspend(ctx->xch, si->xce, si->suspend_eventchn);
+        ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_await_suspend failed ret=%d", ret);
+            LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
             return 0;
         }
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
         goto guest_suspended;
     }
 
-    if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling xc_domain_shutdown on HVM domain");
-        xc_domain_shutdown(ctx->xch, si->domid, SHUTDOWN_suspend);
+    if (dss->hvm && (!hvm_pvdrv || hvm_s_state)) {
+        LOG(DEBUG, "Calling xc_domain_shutdown on HVM domain");
+        xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
         /* The guest does not (need to) respond to this sort of request. */
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
     } else {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
-                   si->hvm ? "PVHVM" : "PV");
+        LOG(DEBUG, "issuing %s suspend request via XenBus control node",
+            dss->hvm ? "PVHVM" : "PV");
 
-        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
+        libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
+        LOG(DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
             if (!state) state = "";
 
             watchdog--;
@@ -709,17 +702,17 @@ static int libxl__domain_suspend_common_callback(void *data)
          * at the last minute.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, cancelling request");
+            LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
         retry_transaction:
-            t = xs_transaction_start(ctx->xsh);
+            t = xs_transaction_start(CTX->xsh);
 
-            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, t, domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
+                libxl__domain_pvcontrol_write(gc, t, domid, "");
 
-            if (!xs_transaction_end(ctx->xsh, t, 0))
+            if (!xs_transaction_end(CTX->xsh, t, 0))
                 if (errno == EAGAIN)
                     goto retry_transaction;
 
@@ -731,27 +724,29 @@ static int libxl__domain_suspend_common_callback(void *data)
          * case we lost the race while cancelling and should continue.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, request cancelled");
+            LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
             return 0;
         }
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest acknowledged suspend request");
-        si->guest_responded = 1;
+        LOG(DEBUG, "guest acknowledged suspend request");
+        dss->guest_responded = 1;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to suspend");
+    LOG(DEBUG, "wait for the guest to suspend");
     watchdog = 60;
     while (watchdog > 0) {
         xc_domaininfo_t info;
 
         usleep(100000);
-        ret = xc_domain_getinfolist(ctx->xch, si->domid, 1, &info);
-        if (ret == 1 && info.domain == si->domid && info.flags & XEN_DOMINF_shutdown) {
+        ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
+        if (ret == 1 && info.domain == domid &&
+            (info.flags & XEN_DOMINF_shutdown)) {
             int shutdown_reason;
 
-            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
+            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+                & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
+                LOG(DEBUG, "guest has suspended");
                 goto guest_suspended;
             }
         }
@@ -759,15 +754,14 @@ static int libxl__domain_suspend_common_callback(void *data)
         watchdog--;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
+    LOG(ERROR, "guest did not suspend");
     return 0;
 
  guest_suspended:
-    if (si->hvm) {
-        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+    if (dss->hvm) {
+        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
         if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
         }
     }
@@ -785,9 +779,8 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
-    struct suspendinfo *si = (struct suspendinfo *) data;
-    libxl__gc *gc = (libxl__gc *) si->gc;
-    libxl_ctx *ctx = gc->owner;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -816,21 +809,21 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         char *xs_path;
         phys_offset = entries[i];
         if (phys_offset == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            LOG(ERROR, "phys_offset %d is NULL", i);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
@@ -866,11 +859,11 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
 
     /* Resumes the domain and the device model */
-    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+    if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
         return 0;
 
     /* TODO: Deal with disk. Start a new network output buffer */
@@ -879,15 +872,15 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
 
     /* This would go into tailbuf. */
-    if (si->hvm &&
-        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+    if (dss->hvm &&
+        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
-    usleep(si->interval * 1000);
+    usleep(dss->interval * 1000);
     return 1;
 }
 
@@ -896,12 +889,10 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  int live, int debug,
                                  const libxl_domain_remus_info *r_info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags;
     int port;
-    struct save_callbacks callbacks;
-    struct suspendinfo si;
-    int hvm, rc = ERROR_FAIL;
+    struct save_callbacks callbacks[1];
+    libxl__domain_suspend_state dss[1];
+    int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
     switch (type) {
@@ -914,82 +905,81 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
         vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
-        hvm = 1;
+        dss->hvm = 1;
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
         vm_generationid_addr = 0;
-        hvm = 0;
+        dss->hvm = 0;
         break;
     default:
         return ERROR_INVAL;
     }
 
-    memset(&si, 0, sizeof(si));
-    flags = (live) ? XCFLAGS_LIVE : 0
+    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
-          | (hvm) ? XCFLAGS_HVM : 0;
+          | (dss->hvm) ? XCFLAGS_HVM : 0;
+
+    dss->domid = domid;
+    dss->gc = gc;
+    dss->suspend_eventchn = -1;
+    dss->guest_responded = 0;
 
     if (r_info != NULL) {
-        si.interval = r_info->interval;
+        dss->interval = r_info->interval;
         if (r_info->compression)
-            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        si.save_fd = fd;
+            dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        dss->save_fd = fd;
     }
     else
-        si.save_fd = -1;
-
-    si.domid = domid;
-    si.flags = flags;
-    si.hvm = hvm;
-    si.gc = gc;
-    si.suspend_eventchn = -1;
-    si.guest_responded = 0;
+        dss->save_fd = -1;
 
-    si.xce = xc_evtchn_open(NULL, 0);
-    if (si.xce == NULL)
+    dss->xce = xc_evtchn_open(NULL, 0);
+    if (dss->xce == NULL)
         goto out;
     else
     {
-        port = xs_suspend_evtchn_port(si.domid);
+        port = xs_suspend_evtchn_port(dss->domid);
 
         if (port >= 0) {
-            si.suspend_eventchn = xc_suspend_evtchn_init(ctx->xch, si.xce, si.domid, port);
+            dss->suspend_eventchn =
+                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
 
-            if (si.suspend_eventchn < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "Suspend event channel initialization failed");
+            if (dss->suspend_eventchn < 0)
+                LOG(WARN, "Suspend event channel initialization failed");
         }
     }
 
-    memset(&callbacks, 0, sizeof(callbacks));
+    memset(callbacks, 0, sizeof(*callbacks));
     if (r_info != NULL) {
-        callbacks.suspend = libxl__remus_domain_suspend_callback;
-        callbacks.postcopy = libxl__remus_domain_resume_callback;
-        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+        callbacks->suspend = libxl__remus_domain_suspend_callback;
+        callbacks->postcopy = libxl__remus_domain_resume_callback;
+        callbacks->checkpoint = libxl__remus_domain_checkpoint_callback;
     } else
-        callbacks.suspend = libxl__domain_suspend_common_callback;
+        callbacks->suspend = libxl__domain_suspend_common_callback;
 
-    callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks.toolstack_save = libxl__toolstack_save;
-    callbacks.data = &si;
+    callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks->toolstack_save = libxl__toolstack_save;
+    callbacks->data = dss;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-                        hvm, vm_generationid_addr);
+    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
+                        dss->hvm, vm_generationid_addr);
     if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
-                         si.guest_responded ?
+        LOGE(ERROR, "saving domain: %s",
+                         dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
-        if ( !si.guest_responded )
+        if ( !dss->guest_responded )
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
     }
 
-    if (si.suspend_eventchn > 0)
-        xc_suspend_evtchn_release(ctx->xch, si.xce, domid, si.suspend_eventchn);
-    if (si.xce != NULL)
-        xc_evtchn_close(si.xce);
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
 
 out:
     return rc;
@@ -997,8 +987,7 @@ out:
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
+    int rc, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -1006,46 +995,46 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 
     if (stat(filename, &st) < 0)
     {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        ret = ERROR_FAIL;
+        LOG(ERROR, "Unable to stat qemu save file\n");
+        rc = ERROR_FAIL;
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
                               "saved-state file", "qemu signature");
-    if (ret)
+    if (rc)
         goto out;
 
-    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (ret)
+    if (rc)
         goto out;
 
     fd2 = open(filename, O_RDONLY);
     if (fd2 < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        LOGE(ERROR, "Unable to open qemu save file\n");
         goto out;
     }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            ret = errno;
+            rc = errno;
             goto out;
         }
-        ret = libxl_write_exactly(
-            ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (ret)
+        rc = libxl_write_exactly(
+            CTX, fd, buf, c, "saved-state file", "qemu state");
+        if (rc)
             goto out;
     }
-    ret = 0;
+    rc = 0;
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return ret;
+    return rc;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..f22bf94 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -786,10 +786,6 @@ _hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                          libxl_domain_build_info *info,
                                          libxl__domain_build_state *state,
                                          int fd);
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1778,6 +1774,23 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Domain suspend (save) state structure -----*/
+
+typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
+
+struct libxl__domain_suspend_state {
+    libxl__gc *gc;
+    xc_evtchn *xce; /* event channel handle */
+    int suspend_eventchn;
+    int domid;
+    int hvm;
+    unsigned int xcflags;
+    int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
+};
+
+
 /*----- openpty -----*/
 
 /*
@@ -1888,6 +1901,15 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
 };
 
+/*----- Domain suspend (save) functions -----*/
+
+_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
+                                         libxl_domain_type type,
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
+
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZze-0005Ih-5y; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005Ca-Ct
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:2869] by server-12.bemta-5.messagelabs.com id
	BD/BD-25233-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12341 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kL-9W; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005W8-7C;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:14 +0100
Message-ID: <1340733318-21099-18-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/21] libxl: do not leak dms->saved_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

This was allocated using asprintf but never freed.  Use GCSPRINTF.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b95a2fe..2d21be5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -801,9 +801,8 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
         goto out;
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
+        state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
     }
 
 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 Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzZ-0005EC-0H; Tue, 26 Jun 2012 17:55:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzW-0005Br-N4
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51381] by server-3.bemta-4.messagelabs.com id
	78/28-05808-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26232 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jp-Js; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VM-Hr;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:02 +0100
Message-ID: <1340733318-21099-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/21] libxl: domain save: API changes for
	asynchrony
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the internal and external APIs for domain save (suspend) to be
capable of asynchronous operation.  The implementation remains
synchronous.  The interfaces surrounding device model saving are still
synchronous.

Public API changes:

 * libxl_domain_save takes an ao_how.

 * libxl_domain_remus_start takes an ao_how.  If the
   libxl_domain_remus_info is NULL, we abort rather than returning an
   error.

 * The `suspend_callback' function passed to libxl_domain_save is
   never called by the existing implementation in libxl.  Abolish it.

 * libxl_domain_save takes its flags parameter as an argument.
   Thus libxl_domain_suspend_info is abolished.

 * XL_SUSPEND_* flags renamed to LIBXL_SAVE_*.

 * Callers in xl updated.

Internal code restructuring:

 * libxl__domain_suspend_state member types and names rationalised.

 * libxl__domain_suspend renamed from libxl__domain_suspend_common.
   (_common here actually meant "internal function").

 * libxl__domain_suspend takes a libxl__domain_suspend_state, which
   where the parameters to the operation are filled in by the caller.

 * xc_domain_save is now called via libxl__xc_domain_save which can
   itself become asynchronous.

 * Consequently, libxl__domain_suspend is split into two functions at
   the callback boundary; the second half is
   libxl__xc_domain_save_done.

 * libxl__domain_save_device_model is now called by the actual
   implementation rather than by the public wrapper.  It is already in
   its proper place in the domain save execution sequence.  So
   officially make it part of that execution sequence, renaming it to
   domain_save_device_model.

 * Effectively, rewrite the public wrapper functions
   libxl_domain_suspend and libxl_domain_remus_start.

 * Remove a needless #include <xenctrl.h>

 * libxl__domain_suspend aborts on unexpected domain types rather
   than mysteriously returning EINVAL.

 * struct save_callbacks moved from the stack to the dss.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v5:
 * Renamed remus_crashed_cb to remus_failover_cb.

Changes in v4:
 * libxl_domain_suspend now handles error from libxl__domain_type
   in the correct way.  (Hunk brought forward from domain type
   fixup patch.)
 * Comment clarifies that libxl__domain_suspend calls dss->callback
   when done.

Changes in v3:
 * Remove `hvm' and `xcflags' args to libxl__xc_domain_save.  Instead,
   just use the values from the dss.

Changes in v2:
 * Move save_callbacks too.
 * Merge with Remus changes.
 * Improvements to commit message.
 * Do not rename libxl_domain_suspend any more.
---
 tools/libxl/libxl.c              |   94 +++++++++++++++++++++---------
 tools/libxl/libxl.h              |   22 ++++----
 tools/libxl/libxl_dom.c          |  121 +++++++++++++++++++++++++++-----------
 tools/libxl/libxl_internal.h     |   45 ++++++++++++---
 tools/libxl/libxl_save_callout.c |   11 ++++
 tools/libxl/xl_cmdimpl.c         |    9 +--
 6 files changed, 214 insertions(+), 88 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6215923..6ec7471 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -648,32 +648,51 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm)
     return ptr;
 }
 
+static void remus_failover_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc);
+
 /* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd)
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
-    libxl_domain_type type = libxl__domain_type(gc, domid);
-    int rc = 0;
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_suspend_state *dss;
+    int rc;
 
+    libxl_domain_type type = libxl__domain_type(gc, domid);
     if (type == LIBXL_DOMAIN_TYPE_INVALID) {
         rc = ERROR_FAIL;
-        goto remus_fail;
+        goto out;
     }
 
-    if (info == NULL) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "No remus_info structure supplied for domain %d", domid);
-        rc = ERROR_INVAL;
-        goto remus_fail;
-    }
+    GCNEW(dss);
+    dss->ao = ao;
+    dss->callback = remus_failover_cb;
+    dss->domid = domid;
+    dss->fd = send_fd;
+    /* TODO do something with recv_fd */
+    dss->type = type;
+    dss->live = 1;
+    dss->debug = 0;
+    dss->remus = info;
+
+    assert(info);
 
     /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
 
     /* Point of no return */
-    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
-                                      /* debug */ 0, info);
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out:
+    return AO_ABORT(rc);
+}
 
+static void remus_failover_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
     /*
      * With Remus, if we reach this point, it means either
      * backup died or some network error occurred preventing us
@@ -683,27 +702,46 @@ int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
     /* TBD: Remus cleanup - i.e. detach qdisc, release other
      * resources.
      */
- remus_fail:
-    GC_FREE;
-    return rc;
+    libxl__ao_complete(egc, ao, rc);
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                         uint32_t domid, int fd)
+static void domain_suspend_cb(libxl__egc *egc,
+                              libxl__domain_suspend_state *dss, int rc)
 {
-    GC_INIT(ctx);
+    STATE_AO_GC(dss->ao);
+    libxl__ao_complete(egc,ao,rc);
+
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    int rc;
+
     libxl_domain_type type = libxl__domain_type(gc, domid);
-    int live = info != NULL && info->flags & XL_SUSPEND_LIVE;
-    int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
-    int rc = 0;
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out_err;
+    }
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
-                                      /* No Remus */ NULL);
+    libxl__domain_suspend_state *dss;
+    GCNEW(dss);
 
-    if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
-        rc = libxl__domain_save_device_model(gc, domid, fd);
-    GC_FREE;
-    return rc;
+    dss->ao = ao;
+    dss->callback = domain_suspend_cb;
+
+    dss->domid = domid;
+    dss->fd = fd;
+    dss->type = type;
+    dss->live = flags & LIBXL_SUSPEND_LIVE;
+    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+
+    libxl__domain_suspend(egc, dss);
+    return AO_INPROGRESS;
+
+ out_err:
+    return AO_ABORT(rc);
 }
 
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05f0e01..10d7115 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -347,13 +347,6 @@ typedef struct libxl__ctx libxl_ctx;
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
 
-typedef struct {
-#define XL_SUSPEND_DEBUG 1
-#define XL_SUSPEND_LIVE 2
-    int flags;
-    int (*suspend_callback)(void *, int);
-} libxl_domain_suspend_info;
-
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
@@ -514,16 +507,23 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
 
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
-int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
-                             uint32_t domid, int send_fd, int recv_fd);
-int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
-                          uint32_t domid, int fd);
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_asyncop_how *ao_how);
+#define LIBXL_SUSPEND_DEBUG 1
+#define LIBXL_SUSPEND_LIVE 2
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
  *   must support this.
  */
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
+
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd,
+                             const libxl_asyncop_how *ao_how);
+
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d73b089..c44dec0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -17,13 +17,11 @@
 
 #include <glob.h>
 
-#include <xenctrl.h>
-#include <xc_dom.h>
+#include "libxl_internal.h"
 
+#include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl_internal.h"
-
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -523,11 +521,18 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-static int libxl__domain_suspend_common_switch_qemu_logdirty
+/*==================== Domain suspend (save) ====================*/
+
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc);
+
+/*----- callbacks, called by xc_domain_save -----*/
+
+int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
 
@@ -592,10 +597,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
@@ -716,7 +721,7 @@ static int libxl__domain_suspend_common_callback(void *data)
 
  guest_suspended:
     if (dss->hvm) {
-        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
+        ret = libxl__domain_suspend_device_model(gc, dss->domid);
         if (ret) {
             LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
@@ -733,11 +738,11 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -808,6 +813,8 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
     return 0;
 }
 
+/*----- remus callbacks -----*/
+
 static int libxl__remus_domain_suspend_callback(void *data)
 {
     /* TODO: Issue disk and network checkpoint reqs. */
@@ -817,7 +824,7 @@ static int libxl__remus_domain_suspend_callback(void *data)
 static int libxl__remus_domain_resume_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
-    libxl__gc *gc = dss->gc;
+    STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
     if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
@@ -830,10 +837,11 @@ static int libxl__remus_domain_resume_callback(void *data)
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
     libxl__domain_suspend_state *dss = data;
+    STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
     if (dss->hvm &&
-        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
+        libxl__domain_save_device_model(gc, dss->domid, dss->fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
@@ -841,17 +849,23 @@ static int libxl__remus_domain_checkpoint_callback(void *data)
     return 1;
 }
 
-int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                 libxl_domain_type type,
-                                 int live, int debug,
-                                 const libxl_domain_remus_info *r_info)
+/*----- main code for suspending, in order of execution -----*/
+
+void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
 {
+    STATE_AO_GC(dss->ao);
     int port;
-    struct save_callbacks callbacks[1];
-    libxl__domain_suspend_state dss[1];
     int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+    const libxl_domain_type type = dss->type;
+    const int live = dss->live;
+    const int debug = dss->debug;
+    const libxl_domain_remus_info *const r_info = dss->remus;
+    struct save_callbacks *const callbacks = &dss->callbacks;
+
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
         char *path;
@@ -870,15 +884,13 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->hvm = 0;
         break;
     default:
-        return ERROR_INVAL;
+        abort();
     }
 
     dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (dss->hvm) ? XCFLAGS_HVM : 0;
 
-    dss->domid = domid;
-    dss->gc = gc;
     dss->suspend_eventchn = -1;
     dss->guest_responded = 0;
 
@@ -886,10 +898,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         dss->interval = r_info->interval;
         if (r_info->compression)
             dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        dss->save_fd = fd;
     }
-    else
-        dss->save_fd = -1;
 
     dss->xce = xc_evtchn_open(NULL, 0);
     if (dss->xce == NULL)
@@ -919,10 +928,28 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     callbacks->toolstack_save = libxl__toolstack_save;
     callbacks->data = dss;
 
-    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
-                        dss->hvm, vm_generationid_addr);
-    if ( rc ) {
-        LOGE(ERROR, "saving domain: %s",
+    libxl__xc_domain_save(egc, dss, vm_generationid_addr);
+    return;
+
+ out:
+    domain_suspend_done(egc, dss, rc);
+}
+
+void libxl__xc_domain_save_done(libxl__egc *egc,
+                                libxl__domain_suspend_state *dss,
+                                int rc, int retval, int errnoval)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const libxl_domain_type type = dss->type;
+    const uint32_t domid = dss->domid;
+
+    if (rc)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "saving domain: %s",
                          dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
@@ -930,16 +957,21 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
+        goto out;
     }
 
-    if (dss->suspend_eventchn > 0)
-        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
-                                  dss->suspend_eventchn);
-    if (dss->xce != NULL)
-        xc_evtchn_close(dss->xce);
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, domid);
+        if (rc) goto out;
+        
+        rc = libxl__domain_save_device_model(gc, domid, dss->fd);
+        if (rc) goto out;
+    }
+
+    rc = 0;
 
 out:
-    return rc;
+    domain_suspend_done(egc, dss, rc);
 }
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
@@ -994,6 +1026,25 @@ out:
     return rc;
 }
 
+static void domain_suspend_done(libxl__egc *egc,
+                        libxl__domain_suspend_state *dss, int rc)
+{
+    STATE_AO_GC(dss->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
+
+    dss->callback(egc, dss, rc);
+}
+
+/*==================== Miscellaneous ====================*/
+
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
     char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 28478ea..7cf1b04 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1777,16 +1777,28 @@ _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
 
+typedef void libxl__domain_suspend_cb(libxl__egc*,
+                                      libxl__domain_suspend_state*, int rc);
+
 struct libxl__domain_suspend_state {
-    libxl__gc *gc;
+    /* set by caller of libxl__domain_suspend */
+    libxl__ao *ao;
+    libxl__domain_suspend_cb *callback;
+
+    uint32_t domid;
+    int fd;
+    libxl_domain_type type;
+    int live;
+    int debug;
+    const libxl_domain_remus_info *remus;
+    /* private */
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
-    int domid;
     int hvm;
-    unsigned int xcflags;
+    int xcflags;
     int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
     int interval; /* checkpoint interval (for Remus) */
+    struct save_callbacks callbacks;
 };
 
 
@@ -1903,10 +1915,27 @@ struct libxl__domain_create_state {
 
 /*----- Domain suspend (save) functions -----*/
 
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
+/* calls dss->callback when done */
+_hidden void libxl__domain_suspend(libxl__egc *egc,
+                                   libxl__domain_suspend_state *dss);
+
+
+/* calls libxl__xc_domain_suspend_done when done */
+_hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
+                                   unsigned long vm_generationid_addr);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_save_done(libxl__egc*,
+                                        libxl__domain_suspend_state*,
+                                        int rc, int retval, int errnoval);
+
+_hidden int libxl__domain_suspend_common_callback(void *data);
+_hidden int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data);
+_hidden int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data);
+
 
 /* calls libxl__xc_domain_restore_done when done */
 _hidden void libxl__xc_domain_restore(libxl__egc *egc,
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 2f8db9f..1b481ab 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -35,3 +35,14 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               &state->vm_generationid_addr, &dcs->callbacks);
     libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
 }
+
+void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
+                           unsigned long vm_generationid_addr)
+{
+    STATE_AO_GC(dss->ao);
+    int r;
+
+    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
+                       &dss->callbacks, dss->hvm, vm_generationid_addr);
+    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index afa0af6..4aea1c7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2817,7 +2817,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint,
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    CHK_ERRNO(libxl_domain_suspend(ctx, NULL, domid, fd));
+    CHK_ERRNO(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
     close(fd);
 
     if (checkpoint)
@@ -2979,7 +2979,6 @@ static void migrate_domain(const char *domain_spec, const char *rune,
     pid_t child = -1;
     int rc;
     int send_fd = -1, recv_fd = -1;
-    libxl_domain_suspend_info suspinfo;
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
@@ -3001,9 +3000,7 @@ static void migrate_domain(const char *domain_spec, const char *rune,
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    memset(&suspinfo, 0, sizeof(suspinfo));
-    suspinfo.flags |= XL_SUSPEND_LIVE;
-    rc = libxl_domain_suspend(ctx, &suspinfo, domid, send_fd);
+    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -6575,7 +6572,7 @@ int main_remus(int argc, char **argv)
     }
 
     /* Point of no return */
-    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd, 0);
 
     /* If we are here, it means backup has failed/domain suspend failed.
      * Try to resume the domain and exit gracefully.
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzZ-0005EO-EM; Tue, 26 Jun 2012 17:55: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 1SjZzW-0005CG-Tq
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:39478] by server-5.bemta-3.messagelabs.com id
	D3/94-01572-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19492 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000k0-SC; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Vg-Pw;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:07 +0100
Message-ID: <1340733318-21099-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/21] libxl: datacopier: provide "prefix data"
	facility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be used to write the qemu data banner to the save/migration
stream.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Clarified and added comments explaining the `immediately'
   constraint and the lack of a reentrancy/threading hazard.
 * Fixed subject line typo.
---
 tools/libxl/libxl_aoutils.c  |   22 ++++++++++++++++++++++
 tools/libxl/libxl_internal.h |    6 ++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index ee0df57..7f8d6d3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -74,6 +74,28 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
     }
 }
 
+void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
+                                  const void *data, size_t len)
+{
+    libxl__datacopier_buf *buf;
+    /*
+     * It is safe for this to be called immediately after _start, as
+     * is documented in the public comment.  _start's caller must have
+     * the ctx locked, so other threads don't get to mess with the
+     * contents, and the fd events cannot happen reentrantly.  So we
+     * are guaranteed to beat the first data from the read fd.
+     */
+
+    assert(len < dc->maxsz - dc->used);
+
+    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf->used = len;
+    memcpy(buf->buf, data, len);
+
+    dc->used += len;
+    LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry);
+}
+
 static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev,
                                 int fd, short events, short revents) {
     libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 05bed01..8b582e4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1811,6 +1811,12 @@ _hidden void libxl__datacopier_init(libxl__datacopier_state *dc);
 _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
+/* Inserts literal data into the output stream.  The data is copied.
+ * May safely be used only immediately after libxl__datacopier_start
+ * (before the ctx is unlocked).  But may be called multiple times.
+ * NB exceeding maxsz will fail an assertion! */
+_hidden void libxl__datacopier_prefixdata(libxl__egc*, libxl__datacopier_state*,
+                                          const void *data, size_t len);
 
 /*----- Save/restore helper (used by creation and suspend) -----*/
 
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzY-0005Dp-7u; Tue, 26 Jun 2012 17:55:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzW-0005Br-AJ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:54 +0000
Received: from [85.158.143.99:51362] by server-3.bemta-4.messagelabs.com id
	66/28-05808-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26170 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kQ-DR; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WG-BP;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:16 +0100
Message-ID: <1340733318-21099-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/21] libxl: do not leak an event struct on
	ignored ao 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 entry to libxl__ao_progress_report, the caller has allocated an
event.  If the progress report is to be ignored, we need to free it.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index eb23a93..1957505 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1602,6 +1602,7 @@ void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
     ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
+        libxl_event_free(CTX,ev);
         /* ignore */
     } else if (how->callback) {
         libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzb-0005Fk-7n; Tue, 26 Jun 2012 17:55: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 1SjZzW-0005CB-SM
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:12294] by server-8.bemta-3.messagelabs.com id
	A5/B2-06157-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19487 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jm-I6; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VI-Fy;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:01 +0100
Message-ID: <1340733318-21099-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/21] libxl: domain restore: reshuffle,
	preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to arrange that libxl, instead of calling
xc_domain_restore, calls a stub function which forks and execs a
helper program, so that restore can be asynchronous rather than
blocking the whole toolstack.

This stub function will be called libxl__xc_domain_restore.

However, its prospective call site is unsuitable for a function which
needs to make a callback, and is buried in two nested single-call-site
functions which are logically part of the domain creation procedure.

So we first abolish those single-call-site functions, integrate their
contents into domain creation in their proper temporal order, and
break out libxl__xc_domain_restore ready for its reimplementation.

No functional change - just the following reorganisation:

* Abolish libxl__domain_restore_common, as it had only one caller.
  Move its contents into (what was) domain_restore.

* There is a new stage function domcreate_rebuild_done containing what
  used to be the bulk of domcreate_bootloader_done, since
  domcreate_bootloader_done now simply starts the restore (or does the
  rebuild) and arranges to call the next stage.

* Move the contents of domain_restore into its correct place in the
  domain creation sequence.  We put it inside
  domcreate_bootloader_done, which now either calls
  libxl__xc_domain_restore which will call the new function
  domcreate_rebuild_done, or calls domcreate_rebuild_done directly.

* Various general-purpose local variables (`i' etc.) and convenience
  alias variables need to be shuffled about accordingly.

* Consequently libxl__toolstack_restore needs to gain external linkage
  as it is now in a different file to its user.

* Move the xc_domain_save callbacks struct from the stack into
  libxl__domain_create_state.

In general the moved code remains almost identical.  Two returns in
what used to be libxl__domain_restore_common have been changed to set
the return value and "goto out", and the call sites for the abolished
and new functions have been adjusted.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v2:
 * Also move the save callbacks
---
 tools/libxl/Makefile             |    1 +
 tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
 tools/libxl/libxl_dom.c          |   45 +-------
 tools/libxl/libxl_internal.h     |   19 +++-
 tools/libxl/libxl_save_callout.c |   37 ++++++
 5 files changed, 206 insertions(+), 140 deletions(-)
 create mode 100644 tools/libxl/libxl_save_callout.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e7d5cc2..1d8b80a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
+			libxl_save_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 67cd207..9c3c671 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -21,7 +21,6 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
-#include <xenguest.h>
 
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -372,89 +371,6 @@ out:
     return ret;
 }
 
-static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
-                          uint32_t domid, int fd,
-                          libxl__domain_build_state *state)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    char **vments = NULL, **localents = NULL;
-    struct timeval start_time;
-    int i, ret, esave, flags;
-
-    ret = libxl__build_pre(gc, domid, info, state);
-    if (ret)
-        goto out;
-
-    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
-    if (ret)
-        goto out;
-
-    gettimeofday(&start_time, NULL);
-
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        vments = libxl__calloc(gc, 7, sizeof(char *));
-        vments[0] = "rtc/timeoffset";
-        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
-        vments[2] = "image/ostype";
-        vments[3] = "hvm";
-        vments[4] = "start_time";
-        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        vments = libxl__calloc(gc, 11, sizeof(char *));
-        i = 0;
-        vments[i++] = "image/ostype";
-        vments[i++] = "linux";
-        vments[i++] = "image/kernel";
-        vments[i++] = (char *) state->pv_kernel.path;
-        vments[i++] = "start_time";
-        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        if (state->pv_ramdisk.path) {
-            vments[i++] = "image/ramdisk";
-            vments[i++] = (char *) state->pv_ramdisk.path;
-        }
-        if (state->pv_cmdline) {
-            vments[i++] = "image/cmdline";
-            vments[i++] = (char *) state->pv_cmdline;
-        }
-        break;
-    default:
-        ret = ERROR_INVAL;
-        goto out;
-    }
-    ret = libxl__build_post(gc, domid, info, state, vments, localents);
-    if (ret)
-        goto out;
-
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
-                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
-    }
-
-out:
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
-        libxl__file_reference_unmap(&state->pv_kernel);
-        libxl__file_reference_unmap(&state->pv_ramdisk);
-    }
-
-    esave = errno;
-
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
-    } else {
-        flags &= ~O_NONBLOCK;
-        if (fcntl(fd, F_SETFL, flags) == -1)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
-                         " back to blocking mode");
-    }
-
-    errno = esave;
-    return ret;
-}
-
 int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
@@ -635,10 +551,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
-
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -732,20 +651,20 @@ static void domcreate_console_available(libxl__egc *egc,
 
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
-                                      int ret)
+                                      int rc)
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    libxl_ctx *const ctx = CTX;
+    struct restore_callbacks *const callbacks = &dcs->callbacks;
 
-    if (ret) goto error_out;
+    if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
     /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
      * been initialised by the bootloader already.
@@ -761,12 +680,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
+    if ( restore_fd < 0 ) {
+        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    /* Restore */
+
+    rc = libxl__build_pre(gc, domid, info, state);
+    if (rc)
+        goto out;
+
+    /* read signature */
+    int hvm, pae, superpages;
+    int no_incr_generationid;
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        hvm = 1;
+        superpages = 1;
+        pae = libxl_defbool_val(info->u.hvm.pae);
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        hvm = 0;
+        superpages = 0;
+        pae = 1;
+        no_incr_generationid = 0;
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+    libxl__xc_domain_restore(egc, dcs,
+                             hvm, pae, superpages, no_incr_generationid);
+    return;
+
+ out:
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret, int retval, int errnoval)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char **vments = NULL, **localents = NULL;
+    struct timeval start_time;
+    int i, esave, flags;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    const int fd = dcs->restore_fd;
+
+    if (ret)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "restoring domain");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    gettimeofday(&start_time, NULL);
+
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        vments = libxl__calloc(gc, 7, sizeof(char *));
+        vments[0] = "rtc/timeoffset";
+        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
+        vments[2] = "image/ostype";
+        vments[3] = "hvm";
+        vments[4] = "start_time";
+        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        vments = libxl__calloc(gc, 11, sizeof(char *));
+        i = 0;
+        vments[i++] = "image/ostype";
+        vments[i++] = "linux";
+        vments[i++] = "image/kernel";
+        vments[i++] = (char *) state->pv_kernel.path;
+        vments[i++] = "start_time";
+        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        if (state->pv_ramdisk.path) {
+            vments[i++] = "image/ramdisk";
+            vments[i++] = (char *) state->pv_ramdisk.path;
+        }
+        if (state->pv_cmdline) {
+            vments[i++] = "image/cmdline";
+            vments[i++] = (char *) state->pv_cmdline;
+        }
+        break;
+    default:
+        ret = ERROR_INVAL;
+        goto out;
+    }
+    ret = libxl__build_post(gc, domid, info, state, vments, localents);
+    if (ret)
+        goto out;
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = asprintf(&state->saved_state,
+                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+        ret = (ret < 0) ? ERROR_FAIL : 0;
+    }
+
+out:
+    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+        libxl__file_reference_unmap(&state->pv_kernel);
+        libxl__file_reference_unmap(&state->pv_ramdisk);
+    }
+
+    esave = errno;
+
+    flags = fcntl(fd, F_GETFL);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        flags &= ~O_NONBLOCK;
+        if (fcntl(fd, F_SETFL, flags) == -1)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
+                         " back to blocking mode");
     }
 
+    errno = esave;
+    domcreate_rebuild_done(egc, dcs, ret);
+}
+
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret)
+{
+    STATE_AO_GC(dcs->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
         ret = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4202b4b..d73b089 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -19,7 +19,6 @@
 
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xenguest.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
@@ -469,7 +468,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = data;
@@ -524,48 +523,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                 libxl_domain_build_info *info,
-                                 libxl__domain_build_state *state,
-                                 int fd)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    /* read signature */
-    int rc;
-    int hvm, pae, superpages;
-    struct restore_callbacks callbacks[1];
-    int no_incr_generationid;
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        hvm = 1;
-        superpages = 1;
-        pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        hvm = 0;
-        superpages = 0;
-        pae = 1;
-        no_incr_generationid = 0;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-    rc = xc_domain_restore(ctx->xch, fd, domid,
-                           state->store_port, &state->store_mfn,
-                           state->store_domid, state->console_port,
-                           &state->console_mfn, state->console_domid,
-                           hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, callbacks);
-    if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 static int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f22bf94..28478ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -46,6 +46,7 @@
 
 #include <xenstore.h>
 #include <xenctrl.h>
+#include <xenguest.h>
 
 #include "xentoollog.h"
 
@@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
 
-_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                         libxl_domain_build_info *info,
-                                         libxl__domain_build_state *state,
-                                         int fd);
+_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+                                     uint32_t size, void *data);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    struct restore_callbacks callbacks;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          int live, int debug,
                                          const libxl_domain_remus_info *r_info);
 
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_restore(libxl__egc *egc,
+                                      libxl__domain_create_state *dcs,
+                                      int hvm, int pae, int superpages,
+                                      int no_incr_generationid);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                           libxl__domain_create_state *dcs,
+                                           int rc, int retval, int errnoval);
 
 
 /*
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
new file mode 100644
index 0000000..2f8db9f
--- /dev/null
+++ b/tools/libxl/libxl_save_callout.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h"
+
+#include "libxl_internal.h"
+
+void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
+                              int hvm, int pae, int superpages,
+                              int no_incr_generationid)
+{
+    STATE_AO_GC(dcs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
+                              state->store_port, &state->store_mfn,
+                              state->store_domid, state->console_port,
+                              &state->console_mfn, state->console_domid,
+                              hvm, pae, superpages, no_incr_generationid,
+                              &state->vm_generationid_addr, &dcs->callbacks);
+    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+}
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzc-0005GY-2n; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CO-7D
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:2847] by server-2.bemta-5.messagelabs.com id
	5B/94-04598-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12323 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kU-GC; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WK-DF;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:17 +0100
Message-ID: <1340733318-21099-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/21] libxl: further fixups re LIBXL_DOMAIN_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

* Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
  handling.  At every call site, replace it with an open-coded call to
  libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.

* This involves adding an `out:' to libxl_domain_unpause.

* In libxl_domain_destroy and do_pci_add, do not `default: abort();'
  if the domain type cannot be found.  Instead switch on
  LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
  handling.

* In libxl__primary_console_find, remove a spurious default clause
  from the domain type switch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v5:
 * Add `default: abort()' to libxl__domain_type switch.

Changes in v4 of series:
 * Hunk
     In libxl_domain_suspend (as reorganised) error check, check for
     LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
   merged into the earlier patch where the slightly-wrong code was
   introduced.
---
 tools/libxl/libxl.c          |   28 +++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h |    5 +++--
 tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
 3 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1a7404a..1b84398 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
         goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_resume_device_model(gc, domid);
         if (rc) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -788,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
@@ -802,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
+ out:
     GC_FREE;
     return rc;
 }
@@ -813,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
     unsigned long pvdriver = 0;
     int ret;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV)
         return 1;
 
     ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
@@ -1213,6 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        rc = ERROR_FAIL;
+        goto out;
     default:
         abort();
     }
@@ -1362,8 +1382,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
         case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-        default:
-            abort();
         }
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9df0db5..36c75ed 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
 _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
                                     libxl_domain_sched_params *scparams);
-#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
-    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
+
 typedef struct {
     uint32_t store_port;
     uint32_t store_domid;
@@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+/* returns 0 or 1, or a libxl error code */
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+
 _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
                                             xs_transaction_t t, uint32_t domid);
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..81438be 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
     if (!num_devs)
         return libxl__create_pci_backend(gc, domid, pcidev, 1);
 
-    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0)
             return ERROR_FAIL;
     }
@@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
         return ERROR_INVAL;
     num = atoi(num_devs);
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -199,7 +207,7 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
         }
         break;
     }
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        return ERROR_FAIL;
     }
 out:
     if (!libxl_is_stubdom(ctx, domid, 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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzc-0005HD-SE; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005Br-9s
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51413] by server-3.bemta-4.messagelabs.com id
	69/28-05808-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26274 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kC-42; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005Vw-1R;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:11 +0100
Message-ID: <1340733318-21099-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: [Xen-devel] [PATCH 14/21] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc (and which replaces the previous
#define NOGC NULL).

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a259d65..1a7404a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7b92539..b95a2fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -163,7 +163,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c9b4189..aa150b5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
-#define NOGC          NULL
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 67ef82c..08c7dac 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzf-0005Je-0C; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CW-Av
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51371] by server-1.bemta-4.messagelabs.com id
	36/E3-24392-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26179 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000js-Lq; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VQ-JR;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:03 +0100
Message-ID: <1340733318-21099-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/21] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v5:
 * assert that preserve_fds are >2.

Changes in v4:
 * Migration stream fd is handled specially by the run_helper
   function, rather than simply being a numarg.  Specifically:
     - dup it to a safe fd number if necessary.
     - clear cloexec flag fd before execing helper
 * Toolstack data fd argument to run_helper replaced with
   generic preserve_fds array, which get cloexec cleared.
 * libxl__xc_domain_save uses supplied callback function pointer,
   rather than calling libxl__toolstack_save directly;
   toolstack data save callback is only supplied to libxc if
   in-libxl caller supplied a callback.
 * libxl-save-helper is not needlessly linked against libxl.
 * Code which prepares pipes for helper clarified.
 * Deal properly with, and log properly, POLLPRI/POLLERR on
   pipe to save helper.
 * Spelling fix in perl script comment.
 * In message generator, use better names for the ends of serial
   conditional here documents.
 * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.
---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   22 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   36 ++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  368 ++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  281 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1147 insertions(+), 38 deletions(-)
 create mode 100644 tools/libxl/libxl_save_helper.c
 create mode 100755 tools/libxl/libxl_save_msgs_gen.pl

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..ddc2624 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -169,7 +183,9 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9c3c671..7b92539 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -662,7 +662,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -702,7 +703,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -722,10 +722,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c44dec0..b52d29a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,16 +467,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -529,9 +533,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -597,9 +602,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -739,9 +745,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -810,6 +816,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -864,7 +872,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -925,8 +934,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -935,10 +943,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7cf1b04..1a7b526 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..19fff1b 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,30 @@
 
 #include "libxl_internal.h"
 
+/* stream_fd is as from the caller (eventually, the application).
+ * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
+ * The actual fd value is not included in the supplied argnums; rather
+ * it will be automatically supplied by run_helper as the 2nd argument.
+ *
+ * preserve_fds are fds that the caller is intending to pass to the
+ * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
+ * An entry may be -1 in which case it will be ignored.
+ */
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg,
+                       int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +51,344 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc, toolstack_data_fd = -1;
+    uint32_t toolstack_data_len = 0;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    if (dss->shs.callbacks.save.toolstack_save) {
+        r = dss->shs.callbacks.save.toolstack_save
+            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        dss->shs.toolstack_data_file = tmpfile();
+        if (!dss->shs.toolstack_data_file) {
+            LOGE(ERROR, "cannot create toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+        r = libxl_write_exactly(CTX, toolstack_data_fd,
+                                toolstack_data_buf, toolstack_data_len,
+                                "toolstack data tmpfile", 0);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        r = lseek(toolstack_data_fd, 0, SEEK_SET);
+        if (r) {
+            LOGE(ERROR, "rewind toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    const unsigned long argnums[] = {
+        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               &toolstack_data_fd, 1,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[4 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    const char **stream_fd_arg = arg++;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    int childfd;
+    for (childfd=0; childfd<2; childfd++) {
+        /* Setting up the pipe for the child's fd childfd */
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
+        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
+        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
+        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        if (stream_fd <= 2) {
+            stream_fd = dup(stream_fd);
+            if (stream_fd < 0) {
+                LOGE(ERROR,"dup migration stream fd");
+                exit(-1);
+            }
+        }
+        libxl_fd_set_cloexec(CTX, stream_fd, 0);
+        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
+
+        for (i=0; i<num_preserve_fds; i++)
+            if (preserve_fds[i] >= 0) {
+                assert(preserve_fds[i] > 2);
+                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
+            }
+
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & (POLLERR|POLLPRI)) {
+        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
+            shs->stdout_what, revents);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..3bdfa28
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,281 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    *buf = xmalloc(toolstack_save_len);
+    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    toolstack_save_fd = -1;
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        if (toolstack_save_fd >= 0)
+            helper_save_callbacks.toolstack_save = toolstack_save_cb;
+
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..c45986e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,397 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copious debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .=
+        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END_BOTH
+
+#include "libxl_internal.h"
+
+END_CALLOUT
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END_HELPER
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END_ALWAYS
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END_DEBUG
+    switch (mtype) {
+
+END_ALWAYS
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END_DEBUG
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END_ALWAYS
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name",
+               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
+    int r = ${helper}_getreply(user);
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END_DEBUG
+    return r;
+END_ALWAYS
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzd-0005IJ-QD; Tue, 26 Jun 2012 17:56:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005CT-BW
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:65405] by server-8.bemta-5.messagelabs.com id
	0D/59-10278-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12336 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231569"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kF-5c; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005W0-3l;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:12 +0100
Message-ID: <1340733318-21099-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/21] libxl: Get compiler to warn about
	gc_opt==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

Since it used to be legal to pass gc_opt==NULL, and there are various
patches floating about and under development which do so, add a
compiler annotation which makes the build fail when that is done.

This turns a runtime crash into a build failure, and should ensure
that we don't accidentally commit a broken combination of patches.

This is something of an annoying approach because it adds a macro
invocation to the RHS of every declaration of a function taking a
gc_opt.  So it should be reverted after Xen 4.2rc1.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index aa150b5..85f4bc6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -453,28 +453,33 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * psuedo-gc.
  */
 /* register ptr in gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
+
+#define NN1 __attribute__((nonnull(1)))
+ /* It used to be legal to pass NULL for gc_opt.  Get the compiler to
+  * warn about this if any slip through. */
+
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */) NN1;
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes) NN1;
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size) NN1;
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size) NN1;
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3) NN1;
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c) NN1;
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n) NN1;
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s) NN1;
 
 /* Each of these logs errors and returns a libxl error code.
  * They do not mind if path is already removed.
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzY-0005Dy-Jw; Tue, 26 Jun 2012 17:55:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzW-0005C0-Ap
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:54 +0000
Received: from [85.158.143.99:6158] by server-1.bemta-4.messagelabs.com id
	B4/E3-24392-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26165 invoked from network); 26 Jun 2012 17:55:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jj-GD; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VE-CV;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:00 +0100
Message-ID: <1340733318-21099-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/21] libxl: domain save: rename variables etc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Preparatory work for making domain suspend asynchronous:

* Rename `struct suspendinfo' to `libxl__domain_suspend_state'
  and move it to libxl_internal.h.

* Rename variables `si' to `dss'.

* Change the stack-allocated state and callbacks from
    struct suspendinfo si;
    struct save_callbacks callbacks;
    struct restore_callbacks callbacks;
  to
    libxl__domain_suspend_state dss[1];
    struct save_callbacks callbacks[1];
    struct restore_callbacks callbacks[1];
  so that it may be referred to as a pointer variable everywhere.

* Rename the variable `flags' (in libxl__domain_suspend_state) to
  `xcflags', to help distinguish it from the other `flags' which is
  passed in from the calling application in libxl_domain_suspend_info.
  Abolish the local variable in libxl__domain_suspend_common, as it
  can use the one in the dss.

* Move the prototypes of suspend-related functions in libxl_internal.h
  to after the definition of the state struct.

* Replace several ctx variables with gc variables and
  consequently references to ctx with CTX.  Change references
  to `dss->gc' in the functional code to simply `gc'.

* Use LOG* rather than LIBXL__LOG* in a number of places.

* In libxl__domain_save_device_model use `rc' instead of `ret'.

* Introduce and use `gc' and `domid' in
  libxl__domain_suspend_common_callback.

* Wrap some long lines.

* Add an extra pair of parens for clarity in a flag test.

* Remove two pointless casts from void* to a struct*.

No functional change whatsoever.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * Abolish local variables `xcflags' and `hvm' in
   libxl__domain_suspend_common; just use dss->xcflags and dss->hvm
   instead and hence do not lose some of the changes to xcflags.

Changes in v2:
 * Make callbacks into arrays (for pointerisation) too.
 * Updated to cope with new remus code.
 * Fixed typo in commit message.
---
 tools/libxl/libxl_dom.c      |  261 ++++++++++++++++++++----------------------
 tools/libxl/libxl_internal.h |   30 ++++-
 2 files changed, 151 insertions(+), 140 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6d63e0e..4202b4b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -472,7 +472,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
-    libxl__gc *gc = (libxl__gc *) data;
+    libxl__gc *gc = data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
     const uint8_t *ptr = buf;
@@ -533,7 +533,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
-    struct restore_callbacks callbacks;
+    struct restore_callbacks callbacks[1];
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -541,8 +541,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks.toolstack_restore = libxl__toolstack_restore;
-        callbacks.data = gc;
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -558,7 +558,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, &callbacks);
+                           &state->vm_generationid_addr, callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -566,33 +566,23 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     return 0;
 }
 
-struct suspendinfo {
-    libxl__gc *gc;
-    xc_evtchn *xce; /* event channel handle */
-    int suspend_eventchn;
-    int domid;
-    int hvm;
-    unsigned int flags;
-    int guest_responded;
-    int save_fd; /* Migration stream fd (for Remus) */
-    int interval; /* checkpoint interval (for Remus) */
-};
-
-static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
+static int libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned int enable, void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     char *path;
     bool rc;
 
-    path = libxl__sprintf(si->gc, "/local/domain/0/device-model/%u/logdirty/cmd", domid);
+    path = libxl__sprintf(gc,
+                   "/local/domain/0/device-model/%u/logdirty/cmd", domid);
     if (!path)
         return 1;
 
     if (enable)
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "enable", strlen("enable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "enable", strlen("enable"));
     else
-        rc = xs_write(ctx->xsh, XBT_NULL, path, "disable", strlen("disable"));
+        rc = xs_write(CTX->xsh, XBT_NULL, path, "disable", strlen("disable"));
 
     return rc ? 0 : 1;
 }
@@ -647,53 +637,56 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
 
 static int libxl__domain_suspend_common_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
     char *state = "suspend";
     int watchdog;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
     xs_transaction_t t;
 
-    if (si->hvm) {
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
-        xc_get_hvm_param(ctx->xch, si->domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
+    /* Convenience aliases */
+    const uint32_t domid = dss->domid;
+
+    if (dss->hvm) {
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_CALLBACK_IRQ, &hvm_pvdrv);
+        xc_get_hvm_param(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, &hvm_s_state);
     }
 
-    if ((hvm_s_state == 0) && (si->suspend_eventchn >= 0)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via event channel",
-                   si->hvm ? "PVHVM" : "PV");
-        ret = xc_evtchn_notify(si->xce, si->suspend_eventchn);
+    if ((hvm_s_state == 0) && (dss->suspend_eventchn >= 0)) {
+        LOG(DEBUG, "issuing %s suspend request via event channel",
+            dss->hvm ? "PVHVM" : "PV");
+        ret = xc_evtchn_notify(dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_evtchn_notify failed ret=%d", ret);
+            LOG(ERROR, "xc_evtchn_notify failed ret=%d", ret);
             return 0;
         }
-        ret = xc_await_suspend(ctx->xch, si->xce, si->suspend_eventchn);
+        ret = xc_await_suspend(CTX->xch, dss->xce, dss->suspend_eventchn);
         if (ret < 0) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "xc_await_suspend failed ret=%d", ret);
+            LOG(ERROR, "xc_await_suspend failed ret=%d", ret);
             return 0;
         }
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
         goto guest_suspended;
     }
 
-    if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling xc_domain_shutdown on HVM domain");
-        xc_domain_shutdown(ctx->xch, si->domid, SHUTDOWN_suspend);
+    if (dss->hvm && (!hvm_pvdrv || hvm_s_state)) {
+        LOG(DEBUG, "Calling xc_domain_shutdown on HVM domain");
+        xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_suspend);
         /* The guest does not (need to) respond to this sort of request. */
-        si->guest_responded = 1;
+        dss->guest_responded = 1;
     } else {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "issuing %s suspend request via XenBus control node",
-                   si->hvm ? "PVHVM" : "PV");
+        LOG(DEBUG, "issuing %s suspend request via XenBus control node",
+            dss->hvm ? "PVHVM" : "PV");
 
-        libxl__domain_pvcontrol_write(si->gc, XBT_NULL, si->domid, "suspend");
+        libxl__domain_pvcontrol_write(gc, XBT_NULL, domid, "suspend");
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to acknowledge suspend request");
+        LOG(DEBUG, "wait for the guest to acknowledge suspend request");
         watchdog = 60;
         while (!strcmp(state, "suspend") && watchdog > 0) {
             usleep(100000);
 
-            state = libxl__domain_pvcontrol_read(si->gc, XBT_NULL, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, XBT_NULL, domid);
             if (!state) state = "";
 
             watchdog--;
@@ -709,17 +702,17 @@ static int libxl__domain_suspend_common_callback(void *data)
          * at the last minute.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, cancelling request");
+            LOG(ERROR, "guest didn't acknowledge suspend, cancelling request");
         retry_transaction:
-            t = xs_transaction_start(ctx->xsh);
+            t = xs_transaction_start(CTX->xsh);
 
-            state = libxl__domain_pvcontrol_read(si->gc, t, si->domid);
+            state = libxl__domain_pvcontrol_read(gc, t, domid);
             if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
-                libxl__domain_pvcontrol_write(si->gc, t, si->domid, "");
+                libxl__domain_pvcontrol_write(gc, t, domid, "");
 
-            if (!xs_transaction_end(ctx->xsh, t, 0))
+            if (!xs_transaction_end(CTX->xsh, t, 0))
                 if (errno == EAGAIN)
                     goto retry_transaction;
 
@@ -731,27 +724,29 @@ static int libxl__domain_suspend_common_callback(void *data)
          * case we lost the race while cancelling and should continue.
          */
         if (!strcmp(state, "suspend")) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest didn't acknowledge suspend, request cancelled");
+            LOG(ERROR, "guest didn't acknowledge suspend, request cancelled");
             return 0;
         }
 
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest acknowledged suspend request");
-        si->guest_responded = 1;
+        LOG(DEBUG, "guest acknowledged suspend request");
+        dss->guest_responded = 1;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "wait for the guest to suspend");
+    LOG(DEBUG, "wait for the guest to suspend");
     watchdog = 60;
     while (watchdog > 0) {
         xc_domaininfo_t info;
 
         usleep(100000);
-        ret = xc_domain_getinfolist(ctx->xch, si->domid, 1, &info);
-        if (ret == 1 && info.domain == si->domid && info.flags & XEN_DOMINF_shutdown) {
+        ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
+        if (ret == 1 && info.domain == domid &&
+            (info.flags & XEN_DOMINF_shutdown)) {
             int shutdown_reason;
 
-            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
+            shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
+                & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
+                LOG(DEBUG, "guest has suspended");
                 goto guest_suspended;
             }
         }
@@ -759,15 +754,14 @@ static int libxl__domain_suspend_common_callback(void *data)
         watchdog--;
     }
 
-    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
+    LOG(ERROR, "guest did not suspend");
     return 0;
 
  guest_suspended:
-    if (si->hvm) {
-        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+    if (dss->hvm) {
+        ret = libxl__domain_suspend_device_model(dss->gc, dss->domid);
         if (ret) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            LOG(ERROR, "libxl__domain_suspend_device_model failed ret=%d", ret);
             return 0;
         }
     }
@@ -785,9 +779,8 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         uint32_t *len, void *data)
 {
-    struct suspendinfo *si = (struct suspendinfo *) data;
-    libxl__gc *gc = (libxl__gc *) si->gc;
-    libxl_ctx *ctx = gc->owner;
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
     unsigned int num = 0;
@@ -816,21 +809,21 @@ static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         char *xs_path;
         phys_offset = entries[i];
         if (phys_offset == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "phys_offset %d is NULL", i);
+            LOG(ERROR, "phys_offset %d is NULL", i);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
         xs_path = save_helper(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s is NULL", xs_path);
+            LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
@@ -866,11 +859,11 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    struct suspendinfo *si = data;
-    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+    libxl__domain_suspend_state *dss = data;
+    libxl__gc *gc = dss->gc;
 
     /* Resumes the domain and the device model */
-    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+    if (libxl_domain_resume(CTX, dss->domid, /* Fast Suspend */1))
         return 0;
 
     /* TODO: Deal with disk. Start a new network output buffer */
@@ -879,15 +872,15 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    struct suspendinfo *si = data;
+    libxl__domain_suspend_state *dss = data;
 
     /* This would go into tailbuf. */
-    if (si->hvm &&
-        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+    if (dss->hvm &&
+        libxl__domain_save_device_model(dss->gc, dss->domid, dss->save_fd))
         return 0;
 
     /* TODO: Wait for disk and memory ack, release network buffer */
-    usleep(si->interval * 1000);
+    usleep(dss->interval * 1000);
     return 1;
 }
 
@@ -896,12 +889,10 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  int live, int debug,
                                  const libxl_domain_remus_info *r_info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int flags;
     int port;
-    struct save_callbacks callbacks;
-    struct suspendinfo si;
-    int hvm, rc = ERROR_FAIL;
+    struct save_callbacks callbacks[1];
+    libxl__domain_suspend_state dss[1];
+    int rc = ERROR_FAIL;
     unsigned long vm_generationid_addr;
 
     switch (type) {
@@ -914,82 +905,81 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
         vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
-        hvm = 1;
+        dss->hvm = 1;
         break;
     }
     case LIBXL_DOMAIN_TYPE_PV:
         vm_generationid_addr = 0;
-        hvm = 0;
+        dss->hvm = 0;
         break;
     default:
         return ERROR_INVAL;
     }
 
-    memset(&si, 0, sizeof(si));
-    flags = (live) ? XCFLAGS_LIVE : 0
+    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
-          | (hvm) ? XCFLAGS_HVM : 0;
+          | (dss->hvm) ? XCFLAGS_HVM : 0;
+
+    dss->domid = domid;
+    dss->gc = gc;
+    dss->suspend_eventchn = -1;
+    dss->guest_responded = 0;
 
     if (r_info != NULL) {
-        si.interval = r_info->interval;
+        dss->interval = r_info->interval;
         if (r_info->compression)
-            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
-        si.save_fd = fd;
+            dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        dss->save_fd = fd;
     }
     else
-        si.save_fd = -1;
-
-    si.domid = domid;
-    si.flags = flags;
-    si.hvm = hvm;
-    si.gc = gc;
-    si.suspend_eventchn = -1;
-    si.guest_responded = 0;
+        dss->save_fd = -1;
 
-    si.xce = xc_evtchn_open(NULL, 0);
-    if (si.xce == NULL)
+    dss->xce = xc_evtchn_open(NULL, 0);
+    if (dss->xce == NULL)
         goto out;
     else
     {
-        port = xs_suspend_evtchn_port(si.domid);
+        port = xs_suspend_evtchn_port(dss->domid);
 
         if (port >= 0) {
-            si.suspend_eventchn = xc_suspend_evtchn_init(ctx->xch, si.xce, si.domid, port);
+            dss->suspend_eventchn =
+                xc_suspend_evtchn_init(CTX->xch, dss->xce, dss->domid, port);
 
-            if (si.suspend_eventchn < 0)
-                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "Suspend event channel initialization failed");
+            if (dss->suspend_eventchn < 0)
+                LOG(WARN, "Suspend event channel initialization failed");
         }
     }
 
-    memset(&callbacks, 0, sizeof(callbacks));
+    memset(callbacks, 0, sizeof(*callbacks));
     if (r_info != NULL) {
-        callbacks.suspend = libxl__remus_domain_suspend_callback;
-        callbacks.postcopy = libxl__remus_domain_resume_callback;
-        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+        callbacks->suspend = libxl__remus_domain_suspend_callback;
+        callbacks->postcopy = libxl__remus_domain_resume_callback;
+        callbacks->checkpoint = libxl__remus_domain_checkpoint_callback;
     } else
-        callbacks.suspend = libxl__domain_suspend_common_callback;
+        callbacks->suspend = libxl__domain_suspend_common_callback;
 
-    callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks.toolstack_save = libxl__toolstack_save;
-    callbacks.data = &si;
+    callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks->toolstack_save = libxl__toolstack_save;
+    callbacks->data = dss;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-                        hvm, vm_generationid_addr);
+    rc = xc_domain_save(CTX->xch, fd, domid, 0, 0, dss->xcflags, callbacks,
+                        dss->hvm, vm_generationid_addr);
     if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
-                         si.guest_responded ?
+        LOGE(ERROR, "saving domain: %s",
+                         dss->guest_responded ?
                          "domain responded to suspend request" :
                          "domain did not respond to suspend request");
-        if ( !si.guest_responded )
+        if ( !dss->guest_responded )
             rc = ERROR_GUEST_TIMEDOUT;
         else
             rc = ERROR_FAIL;
     }
 
-    if (si.suspend_eventchn > 0)
-        xc_suspend_evtchn_release(ctx->xch, si.xce, domid, si.suspend_eventchn);
-    if (si.xce != NULL)
-        xc_evtchn_close(si.xce);
+    if (dss->suspend_eventchn > 0)
+        xc_suspend_evtchn_release(CTX->xch, dss->xce, domid,
+                                  dss->suspend_eventchn);
+    if (dss->xce != NULL)
+        xc_evtchn_close(dss->xce);
 
 out:
     return rc;
@@ -997,8 +987,7 @@ out:
 
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
+    int rc, fd2 = -1, c;
     char buf[1024];
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
@@ -1006,46 +995,46 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 
     if (stat(filename, &st) < 0)
     {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
-        ret = ERROR_FAIL;
+        LOG(ERROR, "Unable to stat qemu save file\n");
+        rc = ERROR_FAIL;
         goto out;
     }
 
     qemu_state_len = st.st_size;
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
+    LOG(DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
+    rc = libxl_write_exactly(CTX, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
                               "saved-state file", "qemu signature");
-    if (ret)
+    if (rc)
         goto out;
 
-    ret = libxl_write_exactly(ctx, fd, &qemu_state_len, sizeof(qemu_state_len),
+    rc = libxl_write_exactly(CTX, fd, &qemu_state_len, sizeof(qemu_state_len),
                             "saved-state file", "saved-state length");
-    if (ret)
+    if (rc)
         goto out;
 
     fd2 = open(filename, O_RDONLY);
     if (fd2 < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Unable to open qemu save file\n");
+        LOGE(ERROR, "Unable to open qemu save file\n");
         goto out;
     }
     while ((c = read(fd2, buf, sizeof(buf))) != 0) {
         if (c < 0) {
             if (errno == EINTR)
                 continue;
-            ret = errno;
+            rc = errno;
             goto out;
         }
-        ret = libxl_write_exactly(
-            ctx, fd, buf, c, "saved-state file", "qemu state");
-        if (ret)
+        rc = libxl_write_exactly(
+            CTX, fd, buf, c, "saved-state file", "qemu state");
+        if (rc)
             goto out;
     }
-    ret = 0;
+    rc = 0;
 out:
     if (fd2 >= 0) close(fd2);
     unlink(filename);
-    return ret;
+    return rc;
 }
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa4c08f..f22bf94 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -786,10 +786,6 @@ _hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                          libxl_domain_build_info *info,
                                          libxl__domain_build_state *state,
                                          int fd);
-_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
-                                         libxl_domain_type type,
-                                         int live, int debug,
-                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1778,6 +1774,23 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Domain suspend (save) state structure -----*/
+
+typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
+
+struct libxl__domain_suspend_state {
+    libxl__gc *gc;
+    xc_evtchn *xce; /* event channel handle */
+    int suspend_eventchn;
+    int domid;
+    int hvm;
+    unsigned int xcflags;
+    int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
+};
+
+
 /*----- openpty -----*/
 
 /*
@@ -1888,6 +1901,15 @@ struct libxl__domain_create_state {
          * for the non-stubdom device model. */
 };
 
+/*----- Domain suspend (save) functions -----*/
+
+_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
+                                         libxl_domain_type type,
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
+
+
+
 /*
  * Convenience macros.
  */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZze-0005JB-Hx; Tue, 26 Jun 2012 17:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzX-0005CU-DZ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:39500] by server-4.bemta-3.messagelabs.com id
	B1/E8-17105-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19495 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kV-Gh; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WP-Fp;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:18 +0100
Message-ID: <1340733318-21099-22-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 21/21] libxl: DO NOT APPLY enforce prohibition
	on internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 APPLY THIS PATCH.
It contains -Wno-error.  Without that it would break the build.

Subject [PATCH] libxl: enforce prohibitions of internal callers

libxl_internal.h says:

 * Functions using LIBXL__INIT_EGC may *not* generally be called from
 * within libxl, because libxl__egc_cleanup may call back into the
 * application. ...

and

 *                    ...  [Functions which take an ao_how] MAY NOT
 * be called from inside libxl, because they can cause reentrancy
 * callbacks.

However, this was not enforced.  Particularly the latter restriction
is easy to overlook, especially since during the transition period to
the new event system we have bent this rule a couple of times, and the
bad pattern simply involves passing 0 or NULL for the ao_how.

So use the compiler to enforce this property, as follows:

 - Mark all functions which take a libxl_asyncop_how, or which
   use EGC_INIT or LIBXL__INIT_EGC, with a new annotation
   LIBXL_EXTERNAL_CALLERS_ONLY in the public header.

 - Change the documentation comment for asynch operations and egcs to
   say that this should always be done.

 - Arrange that if libxl.h is included via libxl_internal.h,
   LIBXL_EXTERNAL_CALLERS_ONLY expands to __attribute__((warning(...))),
   which generates a message like this:
      libxl.c:1772: warning: call to 'libxl_device_disk_remove'
             declared with attribute warning:
             may not be called from within libxl
   Otherwise, the annotation expands to nothing, so external
   callers are unaffected.

 - Forbid inclusion of both libxl.h and libxl_internal.h unless
   libxl_internal.h came first, so that the above check doesn't have
   any loopholes.  Files which include libxl_internal.h should not
   include libxl.h as well.

   This is enforced explicitly using #error.  However, in practice
   with the current tree it just changes the error message when this
   mistake is made; otherwise we would carry on to immediately
   following #define which would cause the compiler to complain that
   LIBXL_EXTERNAL_CALLERS_ONLY was redefined.  Then the developer
   might be tempted to add a #ifndef which would be wrong - it would
   leave the affected translation unit unprotected by the new
   enforcement regime.  So let's be explicit.

 - Fix the one source of files which violate the above principle, the
   output from the idl compiler, by removing the redundant inclusion
   of libxl.h from the output.

In the tree I am using as a base at the time of writing, this new
restriction catches three errors: two in libxl_device_disk_remove and
one in libxl__device_disk_local_detach.  To avoid entirely breaking my
build I have also done this:

 - Temporarily change -Werror to -Wno-error in the libxl Makefile.

This patch should not be applied in this form.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 .gitignore                        |    1 +
 .hgignore                         |    1 +
 tools/libxl/Makefile              |   16 +++++++++++++---
 tools/libxl/check-libxl-api-rules |   15 +++++++++++++++
 tools/libxl/gentypes.py           |    1 -
 tools/libxl/libxl.h               |   34 +++++++++++++++++++++++++---------
 tools/libxl/libxl_event.h         |   21 ++++++++++++++-------
 tools/libxl/libxl_internal.h      |   14 ++++++++++----
 8 files changed, 79 insertions(+), 24 deletions(-)
 create mode 100755 tools/libxl/check-libxl-api-rules

diff --git a/.gitignore b/.gitignore
index 3451e52..22faeaa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -187,6 +187,7 @@ tools/libxl/xl
 tools/libxl/testenum
 tools/libxl/testenum.c
 tools/libxl/tmp.*
+tools/libxl/libxl.api-for-check
 tools/libaio/src/*.ol
 tools/libaio/src/*.os
 tools/misc/cpuperf/cpuperf-perfcntr
diff --git a/.hgignore b/.hgignore
index 05304ea..5756bf8 100644
--- a/.hgignore
+++ b/.hgignore
@@ -185,6 +185,7 @@
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
 ^tools/libxl/.*\.new$
+^tools/libxl/libxl\.api-for-check
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index ddc2624..1c8b62b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-error -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
@@ -74,7 +74,8 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
-	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h \
+        libxl.api-ok
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
@@ -113,6 +114,15 @@ $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 genpath-target = $(call buildmakevars2file,_paths.h.tmp)
 $(eval $(genpath-target))
 
+libxl.api-ok: check-libxl-api-rules libxl.api-for-check
+	perl $^
+
+%.api-for-check: %.h
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
+		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
+		>$@.new
+	$(call move-if-changed,$@.new,$@)
+
 _paths.h: genpath
 	sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" $@.tmp >$@.2.tmp
 	rm -f $@.tmp
@@ -200,7 +210,7 @@ install: all
 .PHONY: clean
 clean:
 	$(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS)
-	$(RM) -f _*.c *.pyc _paths.*.tmp
+	$(RM) -f _*.c *.pyc _paths.*.tmp *.api-for-check
 	$(RM) -f testidl.c.new testidl.c
 #	$(RM) -f $(AUTOSRCS) $(AUTOINCS)
 
diff --git a/tools/libxl/check-libxl-api-rules b/tools/libxl/check-libxl-api-rules
new file mode 100755
index 0000000..e056573
--- /dev/null
+++ b/tools/libxl/check-libxl-api-rules
@@ -0,0 +1,15 @@
+#!/usr/bin/perl -w
+use strict;
+our $needed=0;
+while (<>) {
+      if (m/libxl_asyncop_how[^;]/) {
+         $needed=1;
+      }      
+      if (m/LIBXL_EXTERNAL_CALLERS_ONLY/) {
+          $needed=0;
+      }
+      next unless $needed;
+      if (m/\;/) {
+          die "$ARGV:$.:missing LIBXL_EXTERNAL_CALLERS_ONLY";
+      }
+}
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3c561ba..6e83b21 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -341,7 +341,6 @@ if __name__ == '__main__':
 #include <stdlib.h>
 #include <string.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 #define LIBXL_DTOR_POISON 0xa5
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 10d7115..1a32d9e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -266,6 +266,13 @@
 #endif
 #endif
 
+/* 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. */
+#ifndef LIBXL_EXTERNAL_CALLERS_ONLY
+#define LIBXL_EXTERNAL_CALLERS_ONLY /* disappears for callers outside libxl */
+#endif
+
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
 #define LIBXL_MAC_FMTLEN ((2*6)+5) /* 6 hex bytes plus 5 colons */
@@ -495,11 +502,13 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             const libxl_asyncop_how *ao_how,
-                            const libxl_asyncprogress_how *aop_console_how);
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 uint32_t *domid, int restore_fd,
                                 const libxl_asyncop_how *ao_how,
-                                const libxl_asyncprogress_how *aop_console_how);
+                                const libxl_asyncprogress_how *aop_console_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
@@ -510,7 +519,8 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how);
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
@@ -522,7 +532,8 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 
 int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
                              uint32_t domid, int send_fd, int recv_fd,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
@@ -544,7 +555,8 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
 
 int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
                            const char *filename,
-                           const libxl_asyncop_how *ao_how);
+                           const libxl_asyncop_how *ao_how)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb);
 int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce);
@@ -653,7 +665,8 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
-                             const libxl_asyncop_how *ao_how);
+                             const libxl_asyncop_how *ao_how)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -671,7 +684,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -682,14 +696,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
-                            const libxl_asyncop_how *ao_how);
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 713d96d..3344bc8 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -37,7 +37,8 @@ typedef int libxl_event_predicate(const libxl_event*, void *user);
 
 int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
                       uint64_t typemask,
-                      libxl_event_predicate *predicate, void *predicate_user);
+                      libxl_event_predicate *predicate, void *predicate_user)
+                      LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Searches for an event, already-happened, which matches typemask
    * and predicate.  predicate==0 matches any event.
    * libxl_event_check returns the event, which must then later be
@@ -48,7 +49,8 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
 
 int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      uint64_t typemask,
-                     libxl_event_predicate *predicate, void *predicate_user);
+                     libxl_event_predicate *predicate, void *predicate_user)
+                     LIBXL_EXTERNAL_CALLERS_ONLY;
   /* Like libxl_event_check but blocks if no suitable events are
    * available, until some are.  Uses libxl_osevent_beforepoll/
    * _afterpoll so may be inefficient if very many domains are being
@@ -256,7 +258,8 @@ struct pollfd;
  */
 int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
                              struct pollfd *fds, int *timeout_upd,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* nfds and fds[0..nfds] must be from the most recent call to
  * _beforepoll, as modified by poll.  (It is therefore not possible
@@ -271,7 +274,8 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
  * libxl_event_check.
  */
 void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now);
+                             struct timeval now)
+                             LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 typedef struct libxl_osevent_hooks {
@@ -357,14 +361,16 @@ void libxl_osevent_register_hooks(libxl_ctx *ctx,
  */
 
 void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
-                               int fd, short events, short revents);
+                               int fd, short events, short revents)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Implicitly, on entry to this function the timeout has been
  * deregistered.  If _occurred_timeout is called, libxl will not
  * call timeout_deregister; if it wants to requeue the timeout it
  * will call timeout_register again.
  */
-void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+                                    LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*======================================================================*/
@@ -506,7 +512,8 @@ void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
  * certainly need to use the self-pipe trick (or a working pselect or
  * ppoll) to implement this.
  */
-int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status)
+                           LIBXL_EXTERNAL_CALLERS_ONLY;
 
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 36c75ed..6c859bc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -52,6 +52,12 @@
 
 #include <xen/io/xenbus.h>
 
+#ifdef LIBXL_H
+# error libxl.h should be included via libxl_internal.h, not separately
+#endif
+#define LIBXL_EXTERNAL_CALLERS_ONLY \
+    __attribute__((warning("may not be called from within libxl")))
+
 #include "libxl.h"
 #include "_paths.h"
 #include "_libxl_save_msgs_callout.h"
@@ -1538,10 +1544,10 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  *
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
- * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
- * should in any case not find it necessary to call egc-creators from
- * within libxl.
+ * application.  This should be enforced by declaring all such
+ * functions in libxl.h or libxl_event.h with
+ * LIBXL_EXTERNAL_CALLERS_ONLY.  You should in any case not find it
+ * necessary to call egc-creators from within libxl.
  *
  * The callbacks must all take place with the ctx unlocked because
  * the application is entitled to reenter libxl from them.  This
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzc-0005GY-2n; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005CO-7D
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.139.83:2847] by server-2.bemta-5.messagelabs.com id
	5B/94-04598-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340733353!29538165!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12323 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kU-GC; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WK-DF;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:17 +0100
Message-ID: <1340733318-21099-21-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/21] libxl: further fixups re LIBXL_DOMAIN_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

* Abolish the macro LIBXL__DOMAIN_IS_TYPE which had incorrect error
  handling.  At every call site, replace it with an open-coded call to
  libxl_domain_type and check against LIBXL_DOMAIN_TYPE_INVALID.

* This involves adding an `out:' to libxl_domain_unpause.

* In libxl_domain_destroy and do_pci_add, do not `default: abort();'
  if the domain type cannot be found.  Instead switch on
  LIBXL_DOMAIN_TYPE_INVALID specifically and do some actual error
  handling.

* In libxl__primary_console_find, remove a spurious default clause
  from the domain type switch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v5:
 * Add `default: abort()' to libxl__domain_type switch.

Changes in v4 of series:
 * Hunk
     In libxl_domain_suspend (as reorganised) error check, check for
     LIBXL_DOMAIN_TYPE_INVALID and remove a pointless extra log message.
   merged into the earlier patch where the slightly-wrong code was
   introduced.
---
 tools/libxl/libxl.c          |   28 +++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h |    5 +++--
 tools/libxl/libxl_pci.c      |   18 +++++++++++++-----
 3 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1a7404a..1b84398 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -390,7 +390,13 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
         goto out;
     }
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_resume_device_model(gc, domid);
         if (rc) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -788,7 +794,13 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
     char *state;
     int ret, rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (type == LIBXL_DOMAIN_TYPE_HVM) {
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
@@ -802,6 +814,7 @@ int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid)
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unpausing domain %d", domid);
         rc = ERROR_FAIL;
     }
+ out:
     GC_FREE;
     return rc;
 }
@@ -813,7 +826,11 @@ int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid)
     unsigned long pvdriver = 0;
     int ret;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV))
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV)
         return 1;
 
     ret = xc_get_hvm_param(ctx->xch, domid, HVM_PARAM_CALLBACK_IRQ, &pvdriver);
@@ -1213,6 +1230,9 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
         pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid));
         dm_present = (pid != NULL);
         break;
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        rc = ERROR_FAIL;
+        goto out;
     default:
         abort();
     }
@@ -1362,8 +1382,6 @@ static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
         case LIBXL_DOMAIN_TYPE_INVALID:
             rc = ERROR_INVAL;
             goto out;
-        default:
-            abort();
         }
     }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9df0db5..36c75ed 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -797,8 +797,7 @@ _hidden int libxl__domain_cpupool(libxl__gc *gc, uint32_t domid);
 _hidden libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__sched_set_params(libxl__gc *gc, uint32_t domid,
                                     libxl_domain_sched_params *scparams);
-#define LIBXL__DOMAIN_IS_TYPE(gc, domid, type) \
-    libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
+
 typedef struct {
     uint32_t store_port;
     uint32_t store_domid;
@@ -841,7 +840,9 @@ _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
+/* returns 0 or 1, or a libxl error code */
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
+
 _hidden char * libxl__domain_pvcontrol_read(libxl__gc *gc,
                                             xs_transaction_t t, uint32_t domid);
 _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t,
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..81438be 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -128,7 +128,11 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
     if (!num_devs)
         return libxl__create_pci_backend(gc, domid, pcidev, 1);
 
-    if (!starting && LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (!starting && domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0)
             return ERROR_FAIL;
     }
@@ -171,7 +175,11 @@ static int libxl__device_pci_remove_xenstore(libxl__gc *gc, uint32_t domid, libx
         return ERROR_INVAL;
     num = atoi(num_devs);
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    libxl_domain_type domtype = libxl__domain_type(gc, domid);
+    if (domtype == LIBXL_DOMAIN_TYPE_INVALID)
+        return ERROR_FAIL;
+
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -199,7 +207,7 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc, domid, PV)) {
+    if (domtype == LIBXL_DOMAIN_TYPE_PV) {
         if (libxl__wait_for_backend(gc, be_path, "4") < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "pci backend at %s is not ready", be_path);
             return ERROR_FAIL;
@@ -939,8 +947,8 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, i
         }
         break;
     }
-    default:
-        abort();
+    case LIBXL_DOMAIN_TYPE_INVALID:
+        return ERROR_FAIL;
     }
 out:
     if (!libxl_is_stubdom(ctx, domid, 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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzY-0005Dp-7u; Tue, 26 Jun 2012 17:55:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzW-0005Br-AJ
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:54 +0000
Received: from [85.158.143.99:51362] by server-3.bemta-4.messagelabs.com id
	66/28-05808-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26170 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kQ-DR; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WG-BP;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:16 +0100
Message-ID: <1340733318-21099-20-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/21] libxl: do not leak an event struct on
	ignored ao 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 entry to libxl__ao_progress_report, the caller has allocated an
event.  If the progress report is to be ignored, we need to free it.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_event.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index eb23a93..1957505 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1602,6 +1602,7 @@ void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao,
     ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
+        libxl_event_free(CTX,ev);
         /* ignore */
     } else if (how->callback) {
         libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop));
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzX-0005DQ-RX; Tue, 26 Jun 2012 17:55: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 1SjZzV-0005Br-Tp
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:54 +0000
Received: from [85.158.143.99:51349] by server-3.bemta-4.messagelabs.com id
	C5/28-05808-9A7F9EF4; Tue, 26 Jun 2012 17:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26160 invoked from network); 26 Jun 2012 17:55:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231555"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jc-Aa; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005Uy-85;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:54:57 +0100
Message-ID: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in a
	separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v5 of my series to asyncify save/restore, rebased to tip and
retested.  There are minor changes to 3 patches, as discussed on-list,
marked with "*" below:

    01/21 libxc: xc_domain_restore, make toolstack_restore const-correct
    02/21 libxc: Do not segfault if (e.g.) switch_qemu_logdirty fails
    03/21 libxl: domain save: rename variables etc.
    04/21 libxl: domain restore: reshuffle, preparing for ao
  * 05/21 libxl: domain save: API changes for asynchrony
  * 06/21 libxl: domain save/restore: run in a separate process
    07/21 libxl: rename libxl_dom:save_helper to physmap_path
    08/21 libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
    09/21 libxl: wait for qemu to acknowledge logdirty command
    10/21 libxl: datacopier: provide "prefix data" facility
    11/21 libxl: prepare for asynchronous writing of qemu save file
    12/21 libxl: Make libxl__domain_save_device_model asynchronous
    13/21 libxl: Add a gc to libxl_get_cpu_topology
    14/21 libxl: Do not pass NULL as gc_opt; introduce NOGC
    15/21 libxl: Get compiler to warn about gc_opt==NULL
    16/21 xl: Handle return value from libxl_domain_suspend correctly
    17/21 libxl: do not leak dms->saved_state
    18/21 libxl: do not leak spawned middle children
    19/21 libxl: do not leak an event struct on ignored ao progress
  * 20/21 libxl: further fixups re LIBXL_DOMAIN_TYPE
  ! 21/21 libxl: DO NOT APPLY enforce prohibition on internal

All of these apart from the last have been acked and I intend to
commit those to xen-unstable.hg soon.

However, first I will invite Shriram to check that Remus is still
working.  (I can't conveniently do this with this message due to
shoddiness in git-send-email.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzV-0005C1-VY; Tue, 26 Jun 2012 17:55:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzV-0005Bp-9y
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:53 +0000
Received: from [85.158.143.99:6132] by server-2.bemta-4.messagelabs.com id
	45/2A-17938-8A7F9EF4; Tue, 26 Jun 2012 17:55:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26107 invoked from network); 26 Jun 2012 17:55:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jd-BA; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005V0-9J;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:54:58 +0100
Message-ID: <1340733318-21099-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/21] libxc: xc_domain_restore,
	make toolstack_restore const-correct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Update the one provider of this callback, in libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v3:
 * No longer introduce function pointer typedefs into the libxc API.
---
 tools/libxc/xenguest.h  |    2 +-
 tools/libxl/libxl_dom.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 91d53f7..707e31c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -92,7 +92,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
     /* callback to restore toolstack specific data */
-    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+    int (*toolstack_restore)(uint32_t domid, const uint8_t *buf,
             uint32_t size, void* data);
 
     /* to be provided as the last argument to each callback function */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a2e6655..6d63e0e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -469,13 +469,13 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = (libxl__gc *) data;
     libxl_ctx *ctx = gc->owner;
     int i, ret;
-    uint8_t *ptr = buf;
+    const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
     struct libxl__physmap_info* pi;
     char *xs_path;
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzb-0005Fk-7n; Tue, 26 Jun 2012 17:55: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 1SjZzW-0005CB-SM
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.138.51:12294] by server-8.bemta-3.messagelabs.com id
	A5/B2-06157-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733352!20749293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19487 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jm-I6; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VI-Fy;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:01 +0100
Message-ID: <1340733318-21099-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/21] libxl: domain restore: reshuffle,
	preparing for ao
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We are going to arrange that libxl, instead of calling
xc_domain_restore, calls a stub function which forks and execs a
helper program, so that restore can be asynchronous rather than
blocking the whole toolstack.

This stub function will be called libxl__xc_domain_restore.

However, its prospective call site is unsuitable for a function which
needs to make a callback, and is buried in two nested single-call-site
functions which are logically part of the domain creation procedure.

So we first abolish those single-call-site functions, integrate their
contents into domain creation in their proper temporal order, and
break out libxl__xc_domain_restore ready for its reimplementation.

No functional change - just the following reorganisation:

* Abolish libxl__domain_restore_common, as it had only one caller.
  Move its contents into (what was) domain_restore.

* There is a new stage function domcreate_rebuild_done containing what
  used to be the bulk of domcreate_bootloader_done, since
  domcreate_bootloader_done now simply starts the restore (or does the
  rebuild) and arranges to call the next stage.

* Move the contents of domain_restore into its correct place in the
  domain creation sequence.  We put it inside
  domcreate_bootloader_done, which now either calls
  libxl__xc_domain_restore which will call the new function
  domcreate_rebuild_done, or calls domcreate_rebuild_done directly.

* Various general-purpose local variables (`i' etc.) and convenience
  alias variables need to be shuffled about accordingly.

* Consequently libxl__toolstack_restore needs to gain external linkage
  as it is now in a different file to its user.

* Move the xc_domain_save callbacks struct from the stack into
  libxl__domain_create_state.

In general the moved code remains almost identical.  Two returns in
what used to be libxl__domain_restore_common have been changed to set
the return value and "goto out", and the call sites for the abolished
and new functions have been adjusted.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v2:
 * Also move the save callbacks
---
 tools/libxl/Makefile             |    1 +
 tools/libxl/libxl_create.c       |  244 +++++++++++++++++++++++--------------
 tools/libxl/libxl_dom.c          |   45 +-------
 tools/libxl/libxl_internal.h     |   19 +++-
 tools/libxl/libxl_save_callout.c |   37 ++++++
 5 files changed, 206 insertions(+), 140 deletions(-)
 create mode 100644 tools/libxl/libxl_save_callout.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index e7d5cc2..1d8b80a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,6 +67,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
+			libxl_save_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 67cd207..9c3c671 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -21,7 +21,6 @@
 #include "libxl_arch.h"
 
 #include <xc_dom.h>
-#include <xenguest.h>
 
 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -372,89 +371,6 @@ out:
     return ret;
 }
 
-static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
-                          uint32_t domid, int fd,
-                          libxl__domain_build_state *state)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    char **vments = NULL, **localents = NULL;
-    struct timeval start_time;
-    int i, ret, esave, flags;
-
-    ret = libxl__build_pre(gc, domid, info, state);
-    if (ret)
-        goto out;
-
-    ret = libxl__domain_restore_common(gc, domid, info, state, fd);
-    if (ret)
-        goto out;
-
-    gettimeofday(&start_time, NULL);
-
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        vments = libxl__calloc(gc, 7, sizeof(char *));
-        vments[0] = "rtc/timeoffset";
-        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
-        vments[2] = "image/ostype";
-        vments[3] = "hvm";
-        vments[4] = "start_time";
-        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        vments = libxl__calloc(gc, 11, sizeof(char *));
-        i = 0;
-        vments[i++] = "image/ostype";
-        vments[i++] = "linux";
-        vments[i++] = "image/kernel";
-        vments[i++] = (char *) state->pv_kernel.path;
-        vments[i++] = "start_time";
-        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
-        if (state->pv_ramdisk.path) {
-            vments[i++] = "image/ramdisk";
-            vments[i++] = (char *) state->pv_ramdisk.path;
-        }
-        if (state->pv_cmdline) {
-            vments[i++] = "image/cmdline";
-            vments[i++] = (char *) state->pv_cmdline;
-        }
-        break;
-    default:
-        ret = ERROR_INVAL;
-        goto out;
-    }
-    ret = libxl__build_post(gc, domid, info, state, vments, localents);
-    if (ret)
-        goto out;
-
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&state->saved_state,
-                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
-        ret = (ret < 0) ? ERROR_FAIL : 0;
-    }
-
-out:
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
-        libxl__file_reference_unmap(&state->pv_kernel);
-        libxl__file_reference_unmap(&state->pv_ramdisk);
-    }
-
-    esave = errno;
-
-    flags = fcntl(fd, F_GETFL);
-    if (flags == -1) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
-    } else {
-        flags &= ~O_NONBLOCK;
-        if (fcntl(fd, F_SETFL, flags) == -1)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
-                         " back to blocking mode");
-    }
-
-    errno = esave;
-    return ret;
-}
-
 int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
                        uint32_t *domid)
 {
@@ -635,10 +551,13 @@ static void domcreate_bootloader_console_available(libxl__egc *egc,
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
                                       int rc);
-
 static void domcreate_console_available(libxl__egc *egc,
                                         libxl__domain_create_state *dcs);
 
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret);
+
 /* Our own function to clean up and call the user's callback.
  * The final call in the sequence. */
 static void domcreate_complete(libxl__egc *egc,
@@ -732,20 +651,20 @@ static void domcreate_console_available(libxl__egc *egc,
 
 static void domcreate_bootloader_done(libxl__egc *egc,
                                       libxl__bootloader_state *bl,
-                                      int ret)
+                                      int rc)
 {
     libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl);
     STATE_AO_GC(bl->ao);
-    int i;
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
     libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    libxl_ctx *const ctx = CTX;
+    struct restore_callbacks *const callbacks = &dcs->callbacks;
 
-    if (ret) goto error_out;
+    if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
     /* consume bootloader outputs. state->pv_{kernel,ramdisk} have
      * been initialised by the bootloader already.
@@ -761,12 +680,153 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state);
+    if ( restore_fd < 0 ) {
+        rc = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        domcreate_rebuild_done(egc, dcs, rc);
+        return;
+    }
+
+    /* Restore */
+
+    rc = libxl__build_pre(gc, domid, info, state);
+    if (rc)
+        goto out;
+
+    /* read signature */
+    int hvm, pae, superpages;
+    int no_incr_generationid;
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        hvm = 1;
+        superpages = 1;
+        pae = libxl_defbool_val(info->u.hvm.pae);
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
+        callbacks->toolstack_restore = libxl__toolstack_restore;
+        callbacks->data = gc;
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        hvm = 0;
+        superpages = 0;
+        pae = 1;
+        no_incr_generationid = 0;
+        break;
+    default:
+        rc = ERROR_INVAL;
+        goto out;
+    }
+    libxl__xc_domain_restore(egc, dcs,
+                             hvm, pae, superpages, no_incr_generationid);
+    return;
+
+ out:
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret, int retval, int errnoval)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char **vments = NULL, **localents = NULL;
+    struct timeval start_time;
+    int i, esave, flags;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    const int fd = dcs->restore_fd;
+
+    if (ret)
+        goto out;
+
+    if (retval) {
+        LOGEV(ERROR, errnoval, "restoring domain");
+        ret = ERROR_FAIL;
+        goto out;
+    }
+
+    gettimeofday(&start_time, NULL);
+
+    switch (info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        vments = libxl__calloc(gc, 7, sizeof(char *));
+        vments[0] = "rtc/timeoffset";
+        vments[1] = (info->u.hvm.timeoffset) ? info->u.hvm.timeoffset : "";
+        vments[2] = "image/ostype";
+        vments[3] = "hvm";
+        vments[4] = "start_time";
+        vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        vments = libxl__calloc(gc, 11, sizeof(char *));
+        i = 0;
+        vments[i++] = "image/ostype";
+        vments[i++] = "linux";
+        vments[i++] = "image/kernel";
+        vments[i++] = (char *) state->pv_kernel.path;
+        vments[i++] = "start_time";
+        vments[i++] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+        if (state->pv_ramdisk.path) {
+            vments[i++] = "image/ramdisk";
+            vments[i++] = (char *) state->pv_ramdisk.path;
+        }
+        if (state->pv_cmdline) {
+            vments[i++] = "image/cmdline";
+            vments[i++] = (char *) state->pv_cmdline;
+        }
+        break;
+    default:
+        ret = ERROR_INVAL;
+        goto out;
+    }
+    ret = libxl__build_post(gc, domid, info, state, vments, localents);
+    if (ret)
+        goto out;
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = asprintf(&state->saved_state,
+                       XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+        ret = (ret < 0) ? ERROR_FAIL : 0;
+    }
+
+out:
+    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+        libxl__file_reference_unmap(&state->pv_kernel);
+        libxl__file_reference_unmap(&state->pv_ramdisk);
+    }
+
+    esave = errno;
+
+    flags = fcntl(fd, F_GETFL);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get flags on restore fd");
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, domid, state);
+        flags &= ~O_NONBLOCK;
+        if (fcntl(fd, F_SETFL, flags) == -1)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to put restore fd"
+                         " back to blocking mode");
     }
 
+    errno = esave;
+    domcreate_rebuild_done(egc, dcs, ret);
+}
+
+static void domcreate_rebuild_done(libxl__egc *egc,
+                                   libxl__domain_create_state *dcs,
+                                   int ret)
+{
+    STATE_AO_GC(dcs->ao);
+    int i;
+
+    /* convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl__domain_build_state *const state = &dcs->build_state;
+    libxl_ctx *const ctx = CTX;
+
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot (re-)build domain: %d", ret);
         ret = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4202b4b..d73b089 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -19,7 +19,6 @@
 
 #include <xenctrl.h>
 #include <xc_dom.h>
-#include <xenguest.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
@@ -469,7 +468,7 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
             domid, phys_offset, node);
 }
 
-static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
         uint32_t size, void *data)
 {
     libxl__gc *gc = data;
@@ -524,48 +523,6 @@ static int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
     return 0;
 }
 
-int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                 libxl_domain_build_info *info,
-                                 libxl__domain_build_state *state,
-                                 int fd)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    /* read signature */
-    int rc;
-    int hvm, pae, superpages;
-    struct restore_callbacks callbacks[1];
-    int no_incr_generationid;
-    switch (info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        hvm = 1;
-        superpages = 1;
-        pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
-        callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        hvm = 0;
-        superpages = 0;
-        pae = 1;
-        no_incr_generationid = 0;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-    rc = xc_domain_restore(ctx->xch, fd, domid,
-                           state->store_port, &state->store_mfn,
-                           state->store_domid, state->console_port,
-                           &state->console_mfn, state->console_domid,
-                           hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, callbacks);
-    if ( rc ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 static int libxl__domain_suspend_common_switch_qemu_logdirty
                                (int domid, unsigned int enable, void *data)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f22bf94..28478ea 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -46,6 +46,7 @@
 
 #include <xenstore.h>
 #include <xenctrl.h>
+#include <xenguest.h>
 
 #include "xentoollog.h"
 
@@ -782,10 +783,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
 
-_hidden int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
-                                         libxl_domain_build_info *info,
-                                         libxl__domain_build_state *state,
-                                         int fd);
+_hidden int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
+                                     uint32_t size, void *data);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
@@ -1899,6 +1898,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
+    struct restore_callbacks callbacks;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1908,6 +1908,17 @@ _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          int live, int debug,
                                          const libxl_domain_remus_info *r_info);
 
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_restore(libxl__egc *egc,
+                                      libxl__domain_create_state *dcs,
+                                      int hvm, int pae, int superpages,
+                                      int no_incr_generationid);
+/* If rc==0 then retval is the return value from xc_domain_save
+ * and errnoval is the errno value it provided.
+ * If rc!=0, retval and errnoval are undefined. */
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
+                                           libxl__domain_create_state *dcs,
+                                           int rc, int retval, int errnoval);
 
 
 /*
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
new file mode 100644
index 0000000..2f8db9f
--- /dev/null
+++ b/tools/libxl/libxl_save_callout.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h"
+
+#include "libxl_internal.h"
+
+void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
+                              int hvm, int pae, int superpages,
+                              int no_incr_generationid)
+{
+    STATE_AO_GC(dcs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = dcs->guest_domid;
+    const int restore_fd = dcs->restore_fd;
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
+                              state->store_port, &state->store_mfn,
+                              state->store_domid, state->console_port,
+                              &state->console_mfn, state->console_domid,
+                              hvm, pae, superpages, no_incr_generationid,
+                              &state->vm_generationid_addr, &dcs->callbacks);
+    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+}
-- 
1.7.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 Jun 26 17:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzc-0005HD-SE; Tue, 26 Jun 2012 17:56: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 1SjZzX-0005Br-9s
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:55 +0000
Received: from [85.158.143.99:51413] by server-3.bemta-4.messagelabs.com id
	69/28-05808-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26274 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kC-42; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005Vw-1R;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:11 +0100
Message-ID: <1340733318-21099-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: [Xen-devel] [PATCH 14/21] libxl: Do not pass NULL as gc_opt;
	introduce NOGC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 25182:6c3345d7e9d9 the practice of passing NULL to gc-using memory
allocation functions was introduced.  However, the arrangements there
were not correct as committed, because the error handling and logging
depends on getting a ctx from the gc - so an allocation error would in
fact result in libxl dereferencing NULL.

Instead, provide a special dummy gc in the ctx, called `nogc_gc'.  It
is marked out specially by having alloc_maxsize==-1, which is
otherwise invalid.

Functions which need to actually look into the gc use the new test
function gc_is_real (whose purpose is mainly clarity of the code) to
check whether the gc is the dummy one, and do nothing if it is.  And
we provide a helper macro NOGC which uses the in-scope real gc to find
the ctx and hence the dummy gc (and which replaces the previous
#define NOGC NULL).

Change all callers which pass 0 or NULL to an allocation function to
use NOGC or &ctx->nogc_gc, as applicable in the context.

We add a comment near the definition of LIBXL_INIT_GC pointing out
that it isn't any more the only place a libxl__gc struct is
initialised, for the benefit of anyone changing the contents of gc's
in the future.

Also, actually document that libxl__ptr_add is legal with ptr==NULL,
and change a couple of calls not to check for NULL argument.

Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
 tools/libxl/libxl.c          |    3 +++
 tools/libxl/libxl_aoutils.c  |    3 ++-
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_event.c    |    5 +++--
 tools/libxl/libxl_exec.c     |    2 +-
 tools/libxl/libxl_fork.c     |    2 +-
 tools/libxl/libxl_internal.c |   11 +++++++++--
 tools/libxl/libxl_internal.h |   37 +++++++++++++++++++++++--------------
 tools/libxl/libxl_utils.c    |    6 ++----
 tools/libxl/libxl_xshelp.c   |    7 ++-----
 10 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a259d65..1a7404a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* First initialise pointers etc. (cannot fail) */
 
+    ctx->nogc_gc.alloc_maxsize = -1;
+    ctx->nogc_gc.owner = ctx;
+
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
     ctx->osevent_hooks = 0;
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 7f8d6d3..99972a2 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -77,6 +77,7 @@ static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc)
 void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
                                   const void *data, size_t len)
 {
+    EGC_GC;
     libxl__datacopier_buf *buf;
     /*
      * It is safe for this to be called immediately after _start, as
@@ -88,7 +89,7 @@ void libxl__datacopier_prefixdata(libxl__egc *egc, libxl__datacopier_state *dc,
 
     assert(len < dc->maxsz - dc->used);
 
-    buf = libxl__zalloc(0, sizeof(*buf) - sizeof(buf->buf) + len);
+    buf = libxl__zalloc(NOGC, sizeof(*buf) - sizeof(buf->buf) + len);
     buf->used = len;
     memcpy(buf->buf, data, len);
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 7b92539..b95a2fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -163,7 +163,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     }
 
     if (b_info->blkdev_start == NULL)
-        b_info->blkdev_start = libxl__strdup(0, "xvda");
+        b_info->blkdev_start = libxl__strdup(NOGC, "xvda");
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 565d2c2..eb23a93 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -772,7 +772,7 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
         if (poller->fd_rindices_allocd < maxfd) {
             assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd));
             poller->fd_rindices =
-                libxl__realloc(0, poller->fd_rindices,
+                libxl__realloc(NOGC, poller->fd_rindices,
                                maxfd * sizeof(*poller->fd_rindices));
             memset(poller->fd_rindices + poller->fd_rindices_allocd,
                    0,
@@ -1099,9 +1099,10 @@ void libxl_event_free(libxl_ctx *ctx, libxl_event *event)
 libxl_event *libxl__event_new(libxl__egc *egc,
                               libxl_event_type type, uint32_t domid)
 {
+    EGC_GC;
     libxl_event *ev;
 
-    ev = libxl__zalloc(0,sizeof(*ev));
+    ev = libxl__zalloc(NOGC,sizeof(*ev));
     ev->type = type;
     ev->domid = domid;
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 082bf44..cfa379c 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -280,7 +280,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd));
+    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
     libxl__ev_child_init(&ss->ssd->mid);
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 9ff99e0..044ddad 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -92,7 +92,7 @@ libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
     libxl__carefd *cf = 0;
 
     libxl_fd_set_cloexec(ctx, fd, 1);
-    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf = libxl__zalloc(&ctx->nogc_gc, sizeof(*cf));
     cf->fd = fd;
     LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
     return cf;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 8139520..fbff7d0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -30,11 +30,16 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
 #undef L
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
-    if (!gc)
+    if (!gc_is_real(gc))
         return;
 
     if (!ptr)
@@ -66,6 +71,8 @@ void libxl__free_all(libxl__gc *gc)
     void *ptr;
     int i;
 
+    assert(gc_is_real(gc));
+
     for (i = 0; i < gc->alloc_maxsize; i++) {
         ptr = gc->alloc_ptrs[i];
         gc->alloc_ptrs[i] = NULL;
@@ -104,7 +111,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr && gc != NULL) {
+    } else if (new_ptr != ptr && gc_is_real(gc)) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c9b4189..aa150b5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -277,10 +277,18 @@ struct libxl__poller {
     int wakeup_pipe[2]; /* 0 means no fd allocated */
 };
 
+struct libxl__gc {
+    /* mini-GC */
+    int alloc_maxsize; /* -1 means this is the dummy non-gc gc */
+    void **alloc_ptrs;
+    libxl_ctx *owner;
+};
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
+    libxl__gc nogc_gc;
 
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
@@ -356,13 +364,6 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-struct libxl__gc {
-    /* mini-GC */
-    int alloc_maxsize;
-    void **alloc_ptrs;
-    libxl_ctx *owner;
-};
-
 struct libxl__egc {
     /* For event-generating functions only.
      * The egc and its gc may be accessed only on the creating thread. */
@@ -420,6 +421,7 @@ struct libxl__ao {
         (gc).alloc_ptrs = 0;                    \
         (gc).owner = (ctx);                     \
     } while(0)
+    /* NB, also, a gc struct ctx->nogc_gc is initialised in libxl_ctx_alloc */
 
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
 {
@@ -438,13 +440,20 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
  *
- * However, where the argument is stated to be "gc_opt", NULL may be
- * passed instead, in which case no garbage collection will occur; the
- * pointer must later be freed with free().  This is for memory
- * allocations of types (b) and (c).
+ * However, where the argument is stated to be "gc_opt", &ctx->nogc_gc
+ * may be passed instead, in which case no garbage collection will
+ * occur; the pointer must later be freed with free().  (Passing NULL
+ * for gc_opt is not permitted.)  This is for memory allocations of
+ * types (b) and (c).  The convenience macro NOGC should be used where
+ * possible.
+ *
+ * NOGC (and ctx->nogc_gc) may ONLY be used with functions which
+ * explicitly declare that it's OK.  Use with nonconsenting functions
+ * may result in leaks of those functions' internal allocations on the
+ * psuedo-gc.
  */
-/* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
+/* register ptr in gc for free on exit from outermost libxl callframe. */
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be NULL */);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
@@ -2110,7 +2119,7 @@ _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 #define GC_INIT(ctx)  libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
-#define NOGC          NULL
+#define NOGC          (&CTX->nogc_gc) /* pass only to consenting functions */
 
 /* Allocation macros all of which use the gc. */
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 67ef82c..08c7dac 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -58,8 +58,7 @@ char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid)
 {
     char *s = libxl_domid_to_name(libxl__gc_owner(gc), domid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
@@ -107,8 +106,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
-    if ( s )
-        libxl__ptr_add(gc, s);
+    libxl__ptr_add(gc, s);
     return s;
 }
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 993f527..7fdf164 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -86,11 +86,8 @@ char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
     char *ptr;
 
     ptr = xs_read(ctx->xsh, t, path, NULL);
-    if (ptr != NULL) {
-        libxl__ptr_add(gc, ptr);
-        return ptr;
-    }
-    return 0;
+    libxl__ptr_add(gc, ptr);
+    return ptr;
 }
 
 char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
-- 
1.7.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 Jun 26 17:56:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzg-0005Me-NB; Tue, 26 Jun 2012 17:56:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzZ-0005CW-Fo
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:57 +0000
Received: from [85.158.143.99:51403] by server-1.bemta-4.messagelabs.com id
	38/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26272 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jv-O6; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VU-LT;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:04 +0100
Message-ID: <1340733318-21099-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/21] libxl: rename libxl_dom:save_helper to
	physmap_path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"save_helper" isn't very descriptive.  Also it is now confusing
because it reads like it might refer to the libxl-save-helper
executable which runs xc_domain_save and xc_domain_restore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b52d29a..ba58c45 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -736,7 +736,7 @@ int libxl__domain_suspend_common_callback(void *user)
     return 1;
 }
 
-static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
     return libxl__sprintf(gc,
@@ -781,21 +781,21 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        xs_path = physmap_path(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "size");
+        xs_path = physmap_path(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "name");
+        xs_path = physmap_path(gc, domid, phys_offset, "name");
         name = libxl__xs_read(gc, 0, xs_path);
         if (name == NULL)
             namelen = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzh-0005N8-3y; Tue, 26 Jun 2012 17:56:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzZ-0005C0-9S
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:57 +0000
Received: from [85.158.143.99:6186] by server-1.bemta-4.messagelabs.com id
	08/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26247 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kN-Bz; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WC-9A;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:15 +0100
Message-ID: <1340733318-21099-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/21] libxl: do not leak spawned middle children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn would, when libxl__spawn_detach was called, make
the spawn become idle immediately.  However it still has a child
process which needs to be waited for: the `detachable' spawned
child.

This is wrong because the ultimate in-libxl caller may return to the
application, with a child process still forked but not reaped libxl
contrary to the documented behaviour of libxl.

Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
which is asynchronous.  The detachable spawned children are abolished;
instead, we defer calling back to the in-libxl user until the middle
child has been reaped.

Also, remove erroneous comment suggesting that `death' callback
parameter to libxl__ev_child_fork may be NULL.  It may not, and there
are no callers which pass NULL.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Clarify semantics of sub-states of Attached.
 * Fix reference to `Failing' sub-state in comment to `Failed'.

Changes in v3 of series:
 * Now also remove erroneous comment about NULL fork death callback.
---
 tools/libxl/libxl_dm.c       |   14 ++++-
 tools/libxl/libxl_exec.c     |  130 +++++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h |   43 +++++++-------
 3 files changed, 110 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..b3de145 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -908,6 +908,8 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
 static void device_model_startup_failed(libxl__egc *egc,
                                         libxl__spawn_state *spawn);
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn);
 
 /* our "next step" function, called from those callbacks and elsewhere */
 static void device_model_spawn_outcome(libxl__egc *egc,
@@ -1015,6 +1017,7 @@ retry_transaction:
     spawn->midproc_cb = libxl__spawn_record_pid;
     spawn->confirm_cb = device_model_confirm;
     spawn->failure_cb = device_model_startup_failed;
+    spawn->detached_cb = device_model_detached;
 
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
@@ -1048,9 +1051,7 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
     if (strcmp(xsdata, "running"))
         return;
 
-    libxl__spawn_detach(gc, spawn);
-
-    device_model_spawn_outcome(egc, dmss, 0);
+    libxl__spawn_initiate_detach(gc, spawn);
 }
 
 static void device_model_startup_failed(libxl__egc *egc,
@@ -1060,6 +1061,13 @@ static void device_model_startup_failed(libxl__egc *egc,
     device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
 }
 
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, 0);
+}
+
 static void device_model_spawn_outcome(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index cfa379c..0477386 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -238,15 +238,22 @@ err:
 /*
  * Full set of possible states of a libxl__spawn_state and its _detachable:
  *
- *               ss->        ss->        ss->    | ssd->       ssd->
- *               timeout     xswatch     ssd     |  mid         ss
- *  - Undefined   undef       undef       no     |  -           -
- *  - Idle        Idle        Idle        no     |  -           -
- *  - Active      Active      Active      yes    |  Active      yes
- *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
- *  - Detached    -           -           -      |  Active      no
+ *                   detaching failed  mid     timeout      xswatch          
+ *  - Undefined         undef   undef   -        undef        undef
+ *  - Idle              any     any     Idle     Idle         Idle
+ *  - Attached OK       0       0       Active   Active       Active
+ *  - Attached Failed   0       1       Active   Idle         Idle
+ *  - Detaching         1       maybe   Active   Idle         Idle
+ *  - Partial           any     any     Idle     Active/Idle  Active/Idle
  *
- * When in state Detached, the middle process has been sent a SIGKILL.
+ * When in states Detaching or Attached Failed, the middle process has
+ * been sent a SIGKILL.
+ *
+ * The difference between Attached OK and Attached Failed is not
+ * directly visible to callers - callers see these two the same,
+ * although of course Attached OK will hopefully eventually result in
+ * a call to detached_cb, whereas Attached Failed will end up
+ * in a call to failure_cb.
  */
 
 /* Event callbacks. */
@@ -257,19 +264,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status);
 
-/* Precondition: Partial.  Results: Detached. */
+/* Precondition: Partial.  Results: Idle. */
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-/* Precondition: Partial; caller has logged failure reason.
- * Results: Caller notified of failure;
- *  after return, ss may be completely invalid as caller may reuse it */
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
+/* Precondition: Attached or Detaching; caller has logged failure reason.
+ * Results: Detaching, or Attached Failed */
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss);
 
 void libxl__spawn_init(libxl__spawn_state *ss)
 {
+    libxl__ev_child_init(&ss->mid);
     libxl__ev_time_init(&ss->timeout);
     libxl__ev_xswatch_init(&ss->xswatch);
-    ss->ssd = 0;
 }
 
 int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -280,8 +286,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
-    libxl__ev_child_init(&ss->ssd->mid);
+    ss->failed = ss->detaching = 0;
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
                                      spawn_timeout, ss->timeout_ms);
@@ -291,7 +296,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
                                     spawn_watch_event, ss->xspath);
     if (rc) goto out_err;
 
-    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    pid_t middle = libxl__ev_child_fork(gc, &ss->mid, spawn_middle_death);
     if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
 
     if (middle) {
@@ -344,54 +349,64 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
+    assert(!libxl__ev_child_inuse(&ss->mid));
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+}
+
+static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+/* Precondition: Attached or Detaching, but caller must have just set
+ * at least one of detaching or failed.
+ * Results: Detaching or Attached Failed */
+{
     int r;
 
+    assert(libxl__ev_child_inuse(&ss->mid));
     libxl__ev_time_deregister(gc, &ss->timeout);
     libxl__ev_xswatch_deregister(gc, &ss->xswatch);
 
-    libxl__spawn_state_detachable *ssd = ss->ssd;
-    if (ssd) {
-        if (libxl__ev_child_inuse(&ssd->mid)) {
-            pid_t child = ssd->mid.pid;
-            r = kill(child, SIGKILL);
-            if (r && errno != ESRCH)
-                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
-                     ss->what, (unsigned long)child);
-        }
+    pid_t child = ss->mid.pid;
+    r = kill(child, SIGKILL);
+    if (r && errno != ESRCH)
+        LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+             ss->what, (unsigned long)child);
+}
 
-        /* disconnect the ss and ssd from each other */
-        ssd->ss = 0;
-        ss->ssd = 0;
-    }
+void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    ss->detaching = 1;
+    spawn_detach(gc, ss);
 }
 
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss)
+/* Caller must have logged.  Must be last thing in calling function,
+ * as it may make the callback.  Precondition: Attached or Detaching. */
 {
     EGC_GC;
-    spawn_cleanup(gc, ss);
-    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+    ss->failed = 1;
+    spawn_detach(gc, ss);
 }
 
 static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
                           const struct timeval *requested_abs)
 {
-    /* Before event, was Active; is now Partial. */
+    /* Before event, was Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
     LOG(ERROR, "%s: startup timed out", ss->what);
-    spawn_failed(egc, ss); /* must be last */
+    spawn_fail(egc, ss); /* must be last */
 }
 
 static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
                               const char *watch_path, const char *event_path)
 {
-    /* On entry, is Active. */
+    /* On entry, is Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
     char *p = libxl__xs_read(gc, 0, ss->xspath);
     if (!p && errno != ENOENT) {
         LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
-        spawn_failed(egc, ss); /* must be last */
+        spawn_fail(egc, ss); /* must be last */
         return;
     }
     ss->confirm_cb(egc, ss, p); /* must be last */
@@ -399,20 +414,22 @@ static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
 
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status)
-    /* Before event, was Active or Detached;
-     * is now Active or Detached except that ssd->mid is Idle */
+    /* On entry, is Attached or Detaching */
 {
     EGC_GC;
-    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
-    libxl__spawn_state *ss = ssd->ss;
-
-    if (!WIFEXITED(status)) {
+    libxl__spawn_state *ss = CONTAINER_OF(childw, *ss, mid);
+
+    if ((ss->failed || ss->detaching) &&
+        ((WIFEXITED(status) && WEXITSTATUS(status)==0) ||
+         (WIFSIGNALED(status) && WTERMSIG(status)==SIGKILL))) {
+        /* as expected */
+    } else if (!WIFEXITED(status)) {
+        int loglevel = ss->detaching ? XTL_WARN : XTL_ERROR;
         const char *what =
-            GCSPRINTF("%s intermediate process (startup monitor)",
-                      ss ? ss->what : "(detached)");
-        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+            GCSPRINTF("%s intermediate process (startup monitor)", ss->what);
         libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
-    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        ss->failed = 1;
+    } else {
         if (!status)
             LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
                 " when we were waiting for it to confirm startup",
@@ -430,15 +447,22 @@ static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                 LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
                     " signal number %d", ss->what, (unsigned long)pid, sig);
         }
-        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
-        spawn_failed(egc, ss); /* must be last use of ss */
+        ss->failed = 1;
     }
-    free(ssd);
-}
 
-void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
-{
     spawn_cleanup(gc, ss);
+
+    if (ss->failed && !ss->detaching) {
+        ss->failure_cb(egc, ss); /* must be last */
+        return;
+    }
+    
+    if (ss->failed && ss->detaching)
+        LOG(WARN,"%s underlying machinery seemed to fail,"
+            " but its function seems to have been successful", ss->what);
+
+    assert(ss->detaching);
+    ss->detached_cb(egc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 85f4bc6..9df0db5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -690,8 +690,7 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
  * the libxl event machinery.
  *
  * The parent may signal the child but it must not reap it.  That will
- * be done by the event machinery.  death may be NULL in which case
- * the child is still reaped but its death is ignored.
+ * be done by the event machinery.
  *
  * It is not possible to "deregister" the child death event source.
  * It will generate exactly one event callback; until then the childw
@@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
  *
  * Higher-level double-fork and separate detach eg as for device models
  *
- * Each libxl__spawn_state is in one of the conventional states
- *    Undefined, Idle, Active
+ * Each libxl__spawn_state is in one of these states
+ *    Undefined, Idle, Attached, Detaching
  */
 
 typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
@@ -1040,15 +1039,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
  * intermediate or final child; an error message will have been
  * logged.
  *
- * confirm_cb and failure_cb will not be called reentrantly from
- * within libxl__spawn_spawn.
+ * confirm_cb, failure_cb and detached_cb will not be called
+ * reentrantly from within libxl__spawn_spawn.
  *
  * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
  *  < 0   error, *spawn is now Idle and need not be detached
- *   +1   caller is the parent, *spawn is Active and must eventually be detached
+ *   +1   caller is the parent, *spawn is Attached and must be detached
  *    0   caller is now the inner child, should probably call libxl__exec
  *
  * The spawn state must be Undefined or Idle on entry.
@@ -1056,12 +1055,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
 _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl__spawn_detach - Detaches the daemonic child.
+ * libxl__spawn_request_detach - Detaches the daemonic child.
  *
  * Works by killing the intermediate process from spawn_spawn.
  * After this function returns, failures of either child are no
  * longer reported via failure_cb.
  *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
  * If called before the inner child has been created, this may prevent
  * it from running at all.  Thus this should be called only when the
  * inner child has notified that it is ready.  Normally it will be
@@ -1069,10 +1071,10 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
  *
  * Logs errors.
  *
- * The spawn state must be Active or Idle on entry and will be Idle
+ * The spawn state must be Attached entry and will be Detaching
  * on return.
  */
-_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
+_hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
  * If successful, this should return 0.
@@ -1109,15 +1111,11 @@ typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
 typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
                                      const char *xsdata);
 
-typedef struct {
-    /* Private to the spawn implementation.
-     */
-    /* This separate struct, from malloc, allows us to "detach"
-     * the child and reap it later, when our user has gone
-     * away and freed its libxl__spawn_state */
-    struct libxl__spawn_state *ss;
-    libxl__ev_child mid;
-} libxl__spawn_state_detachable;
+/*
+ * Called when the detach (requested by libxl__spawn_initiate_detach) has
+ * completed.  On entry to the callback the spawn state is Idle.
+ */
+typedef void libxl__spawn_detached_cb(libxl__egc*, libxl__spawn_state*);
 
 struct libxl__spawn_state {
     /* must be filled in by user and remain valid */
@@ -1129,15 +1127,18 @@ struct libxl__spawn_state {
     libxl__spawn_midproc_cb *midproc_cb;
     libxl__spawn_failure_cb *failure_cb;
     libxl__spawn_confirm_cb *confirm_cb;
+    libxl__spawn_detached_cb *detached_cb;
 
     /* remaining fields are private to libxl_spawn_... */
+    int detaching; /* we are in Detaching */
+    int failed; /* might be true whenever we are not Idle */
+    libxl__ev_child mid; /* always in use whenever we are not Idle */
     libxl__ev_time timeout;
     libxl__ev_xswatch xswatch;
-    libxl__spawn_state_detachable *ssd;
 };
 
 static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
-    { return !!ss->ssd; }
+    { return libxl__ev_child_inuse(&ss->mid); }
 
 /*
  * libxl_spawner_record_pid - Record given pid in xenstore
-- 
1.7.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 Jun 26 17:56:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzg-0005Me-NB; Tue, 26 Jun 2012 17:56:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzZ-0005CW-Fo
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:57 +0000
Received: from [85.158.143.99:51403] by server-1.bemta-4.messagelabs.com id
	38/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26272 invoked from network); 26 Jun 2012 17:55:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZyz-0000jv-O6; Tue, 26 Jun 2012 17:55:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZyz-0005VU-LT;
	Tue, 26 Jun 2012 18:55:21 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Jun 2012 18:55:04 +0100
Message-ID: <1340733318-21099-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/21] libxl: rename libxl_dom:save_helper to
	physmap_path
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"save_helper" isn't very descriptive.  Also it is now confusing
because it reads like it might refer to the libxl-save-helper
executable which runs xc_domain_save and xc_domain_restore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b52d29a..ba58c45 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -736,7 +736,7 @@ int libxl__domain_suspend_common_callback(void *user)
     return 1;
 }
 
-static inline char *save_helper(libxl__gc *gc, uint32_t domid,
+static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
     return libxl__sprintf(gc,
@@ -781,21 +781,21 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "start_addr");
+        xs_path = physmap_path(gc, domid, phys_offset, "start_addr");
         start_addr = libxl__xs_read(gc, 0, xs_path);
         if (start_addr == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "size");
+        xs_path = physmap_path(gc, domid, phys_offset, "size");
         size = libxl__xs_read(gc, 0, xs_path);
         if (size == NULL) {
             LOG(ERROR, "%s is NULL", xs_path);
             return -1;
         }
 
-        xs_path = save_helper(gc, domid, phys_offset, "name");
+        xs_path = physmap_path(gc, domid, phys_offset, "name");
         name = libxl__xs_read(gc, 0, xs_path);
         if (name == NULL)
             namelen = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:56:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 17: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 1SjZzh-0005N8-3y; Tue, 26 Jun 2012 17:56:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjZzZ-0005C0-9S
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 17:55:57 +0000
Received: from [85.158.143.99:6186] by server-1.bemta-4.messagelabs.com id
	08/E3-24392-AA7F9EF4; Tue, 26 Jun 2012 17:55:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340733351!28924010!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26247 invoked from network); 26 Jun 2012 17:55:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:55:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjZz0-0000kN-Bz; Tue, 26 Jun 2012 17:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjZz0-0005WC-9A;
	Tue, 26 Jun 2012 18:55:22 +0100
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 26 Jun 2012 18:55:15 +0100
Message-ID: <1340733318-21099-19-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/21] libxl: do not leak spawned middle children
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__spawn_spawn would, when libxl__spawn_detach was called, make
the spawn become idle immediately.  However it still has a child
process which needs to be waited for: the `detachable' spawned
child.

This is wrong because the ultimate in-libxl caller may return to the
application, with a child process still forked but not reaped libxl
contrary to the documented behaviour of libxl.

Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
which is asynchronous.  The detachable spawned children are abolished;
instead, we defer calling back to the in-libxl user until the middle
child has been reaped.

Also, remove erroneous comment suggesting that `death' callback
parameter to libxl__ev_child_fork may be NULL.  It may not, and there
are no callers which pass NULL.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Changes in v4:
 * Clarify semantics of sub-states of Attached.
 * Fix reference to `Failing' sub-state in comment to `Failed'.

Changes in v3 of series:
 * Now also remove erroneous comment about NULL fork death callback.
---
 tools/libxl/libxl_dm.c       |   14 ++++-
 tools/libxl/libxl_exec.c     |  130 +++++++++++++++++++++++++-----------------
 tools/libxl/libxl_internal.h |   43 +++++++-------
 3 files changed, 110 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 340fcfa..b3de145 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -908,6 +908,8 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
                                  const char *xsdata);
 static void device_model_startup_failed(libxl__egc *egc,
                                         libxl__spawn_state *spawn);
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn);
 
 /* our "next step" function, called from those callbacks and elsewhere */
 static void device_model_spawn_outcome(libxl__egc *egc,
@@ -1015,6 +1017,7 @@ retry_transaction:
     spawn->midproc_cb = libxl__spawn_record_pid;
     spawn->confirm_cb = device_model_confirm;
     spawn->failure_cb = device_model_startup_failed;
+    spawn->detached_cb = device_model_detached;
 
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
@@ -1048,9 +1051,7 @@ static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
     if (strcmp(xsdata, "running"))
         return;
 
-    libxl__spawn_detach(gc, spawn);
-
-    device_model_spawn_outcome(egc, dmss, 0);
+    libxl__spawn_initiate_detach(gc, spawn);
 }
 
 static void device_model_startup_failed(libxl__egc *egc,
@@ -1060,6 +1061,13 @@ static void device_model_startup_failed(libxl__egc *egc,
     device_model_spawn_outcome(egc, dmss, ERROR_FAIL);
 }
 
+static void device_model_detached(libxl__egc *egc,
+                                  libxl__spawn_state *spawn)
+{
+    libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn);
+    device_model_spawn_outcome(egc, dmss, 0);
+}
+
 static void device_model_spawn_outcome(libxl__egc *egc,
                                        libxl__dm_spawn_state *dmss,
                                        int rc)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index cfa379c..0477386 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -238,15 +238,22 @@ err:
 /*
  * Full set of possible states of a libxl__spawn_state and its _detachable:
  *
- *               ss->        ss->        ss->    | ssd->       ssd->
- *               timeout     xswatch     ssd     |  mid         ss
- *  - Undefined   undef       undef       no     |  -           -
- *  - Idle        Idle        Idle        no     |  -           -
- *  - Active      Active      Active      yes    |  Active      yes
- *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if exists)
- *  - Detached    -           -           -      |  Active      no
+ *                   detaching failed  mid     timeout      xswatch          
+ *  - Undefined         undef   undef   -        undef        undef
+ *  - Idle              any     any     Idle     Idle         Idle
+ *  - Attached OK       0       0       Active   Active       Active
+ *  - Attached Failed   0       1       Active   Idle         Idle
+ *  - Detaching         1       maybe   Active   Idle         Idle
+ *  - Partial           any     any     Idle     Active/Idle  Active/Idle
  *
- * When in state Detached, the middle process has been sent a SIGKILL.
+ * When in states Detaching or Attached Failed, the middle process has
+ * been sent a SIGKILL.
+ *
+ * The difference between Attached OK and Attached Failed is not
+ * directly visible to callers - callers see these two the same,
+ * although of course Attached OK will hopefully eventually result in
+ * a call to detached_cb, whereas Attached Failed will end up
+ * in a call to failure_cb.
  */
 
 /* Event callbacks. */
@@ -257,19 +264,18 @@ static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status);
 
-/* Precondition: Partial.  Results: Detached. */
+/* Precondition: Partial.  Results: Idle. */
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
 
-/* Precondition: Partial; caller has logged failure reason.
- * Results: Caller notified of failure;
- *  after return, ss may be completely invalid as caller may reuse it */
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
+/* Precondition: Attached or Detaching; caller has logged failure reason.
+ * Results: Detaching, or Attached Failed */
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss);
 
 void libxl__spawn_init(libxl__spawn_state *ss)
 {
+    libxl__ev_child_init(&ss->mid);
     libxl__ev_time_init(&ss->timeout);
     libxl__ev_xswatch_init(&ss->xswatch);
-    ss->ssd = 0;
 }
 
 int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
@@ -280,8 +286,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
     int status, rc;
 
     libxl__spawn_init(ss);
-    ss->ssd = libxl__zalloc(NOGC, sizeof(*ss->ssd));
-    libxl__ev_child_init(&ss->ssd->mid);
+    ss->failed = ss->detaching = 0;
 
     rc = libxl__ev_time_register_rel(gc, &ss->timeout,
                                      spawn_timeout, ss->timeout_ms);
@@ -291,7 +296,7 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
                                     spawn_watch_event, ss->xspath);
     if (rc) goto out_err;
 
-    pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death);
+    pid_t middle = libxl__ev_child_fork(gc, &ss->mid, spawn_middle_death);
     if (middle ==-1) { rc = ERROR_FAIL; goto out_err; }
 
     if (middle) {
@@ -344,54 +349,64 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss)
 
 static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss)
 {
+    assert(!libxl__ev_child_inuse(&ss->mid));
+    libxl__ev_time_deregister(gc, &ss->timeout);
+    libxl__ev_xswatch_deregister(gc, &ss->xswatch);
+}
+
+static void spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
+/* Precondition: Attached or Detaching, but caller must have just set
+ * at least one of detaching or failed.
+ * Results: Detaching or Attached Failed */
+{
     int r;
 
+    assert(libxl__ev_child_inuse(&ss->mid));
     libxl__ev_time_deregister(gc, &ss->timeout);
     libxl__ev_xswatch_deregister(gc, &ss->xswatch);
 
-    libxl__spawn_state_detachable *ssd = ss->ssd;
-    if (ssd) {
-        if (libxl__ev_child_inuse(&ssd->mid)) {
-            pid_t child = ssd->mid.pid;
-            r = kill(child, SIGKILL);
-            if (r && errno != ESRCH)
-                LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
-                     ss->what, (unsigned long)child);
-        }
+    pid_t child = ss->mid.pid;
+    r = kill(child, SIGKILL);
+    if (r && errno != ESRCH)
+        LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)",
+             ss->what, (unsigned long)child);
+}
 
-        /* disconnect the ss and ssd from each other */
-        ssd->ss = 0;
-        ss->ssd = 0;
-    }
+void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state *ss)
+{
+    ss->detaching = 1;
+    spawn_detach(gc, ss);
 }
 
-static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss)
+static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss)
+/* Caller must have logged.  Must be last thing in calling function,
+ * as it may make the callback.  Precondition: Attached or Detaching. */
 {
     EGC_GC;
-    spawn_cleanup(gc, ss);
-    ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */
+    ss->failed = 1;
+    spawn_detach(gc, ss);
 }
 
 static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev,
                           const struct timeval *requested_abs)
 {
-    /* Before event, was Active; is now Partial. */
+    /* Before event, was Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout);
     LOG(ERROR, "%s: startup timed out", ss->what);
-    spawn_failed(egc, ss); /* must be last */
+    spawn_fail(egc, ss); /* must be last */
 }
 
 static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
                               const char *watch_path, const char *event_path)
 {
-    /* On entry, is Active. */
+    /* On entry, is Attached. */
     EGC_GC;
     libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch);
     char *p = libxl__xs_read(gc, 0, ss->xspath);
     if (!p && errno != ENOENT) {
         LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath);
-        spawn_failed(egc, ss); /* must be last */
+        spawn_fail(egc, ss); /* must be last */
         return;
     }
     ss->confirm_cb(egc, ss, p); /* must be last */
@@ -399,20 +414,22 @@ static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw,
 
 static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                                pid_t pid, int status)
-    /* Before event, was Active or Detached;
-     * is now Active or Detached except that ssd->mid is Idle */
+    /* On entry, is Attached or Detaching */
 {
     EGC_GC;
-    libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid);
-    libxl__spawn_state *ss = ssd->ss;
-
-    if (!WIFEXITED(status)) {
+    libxl__spawn_state *ss = CONTAINER_OF(childw, *ss, mid);
+
+    if ((ss->failed || ss->detaching) &&
+        ((WIFEXITED(status) && WEXITSTATUS(status)==0) ||
+         (WIFSIGNALED(status) && WTERMSIG(status)==SIGKILL))) {
+        /* as expected */
+    } else if (!WIFEXITED(status)) {
+        int loglevel = ss->detaching ? XTL_WARN : XTL_ERROR;
         const char *what =
-            GCSPRINTF("%s intermediate process (startup monitor)",
-                      ss ? ss->what : "(detached)");
-        int loglevel = ss ? XTL_ERROR : XTL_WARN;
+            GCSPRINTF("%s intermediate process (startup monitor)", ss->what);
         libxl_report_child_exitstatus(CTX, loglevel, what, pid, status);
-    } else if (ss) { /* otherwise it was supposed to be a daemon by now */
+        ss->failed = 1;
+    } else {
         if (!status)
             LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0,"
                 " when we were waiting for it to confirm startup",
@@ -430,15 +447,22 @@ static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
                 LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal"
                     " signal number %d", ss->what, (unsigned long)pid, sig);
         }
-        ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */
-        spawn_failed(egc, ss); /* must be last use of ss */
+        ss->failed = 1;
     }
-    free(ssd);
-}
 
-void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss)
-{
     spawn_cleanup(gc, ss);
+
+    if (ss->failed && !ss->detaching) {
+        ss->failure_cb(egc, ss); /* must be last */
+        return;
+    }
+    
+    if (ss->failed && ss->detaching)
+        LOG(WARN,"%s underlying machinery seemed to fail,"
+            " but its function seems to have been successful", ss->what);
+
+    assert(ss->detaching);
+    ss->detached_cb(egc, ss);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 85f4bc6..9df0db5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -690,8 +690,7 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
  * the libxl event machinery.
  *
  * The parent may signal the child but it must not reap it.  That will
- * be done by the event machinery.  death may be NULL in which case
- * the child is still reaped but its death is ignored.
+ * be done by the event machinery.
  *
  * It is not possible to "deregister" the child death event source.
  * It will generate exactly one event callback; until then the childw
@@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid);
  *
  * Higher-level double-fork and separate detach eg as for device models
  *
- * Each libxl__spawn_state is in one of the conventional states
- *    Undefined, Idle, Active
+ * Each libxl__spawn_state is in one of these states
+ *    Undefined, Idle, Attached, Detaching
  */
 
 typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting;
@@ -1040,15 +1039,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
  * intermediate or final child; an error message will have been
  * logged.
  *
- * confirm_cb and failure_cb will not be called reentrantly from
- * within libxl__spawn_spawn.
+ * confirm_cb, failure_cb and detached_cb will not be called
+ * reentrantly from within libxl__spawn_spawn.
  *
  * what: string describing the spawned process, used for logging
  *
  * Logs errors.  A copy of "what" is taken. 
  * Return values:
  *  < 0   error, *spawn is now Idle and need not be detached
- *   +1   caller is the parent, *spawn is Active and must eventually be detached
+ *   +1   caller is the parent, *spawn is Attached and must be detached
  *    0   caller is now the inner child, should probably call libxl__exec
  *
  * The spawn state must be Undefined or Idle on entry.
@@ -1056,12 +1055,15 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
 _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
 
 /*
- * libxl__spawn_detach - Detaches the daemonic child.
+ * libxl__spawn_request_detach - Detaches the daemonic child.
  *
  * Works by killing the intermediate process from spawn_spawn.
  * After this function returns, failures of either child are no
  * longer reported via failure_cb.
  *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
  * If called before the inner child has been created, this may prevent
  * it from running at all.  Thus this should be called only when the
  * inner child has notified that it is ready.  Normally it will be
@@ -1069,10 +1071,10 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn);
  *
  * Logs errors.
  *
- * The spawn state must be Active or Idle on entry and will be Idle
+ * The spawn state must be Attached entry and will be Detaching
  * on return.
  */
-_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*);
+_hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
 
 /*
  * If successful, this should return 0.
@@ -1109,15 +1111,11 @@ typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*);
 typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*,
                                      const char *xsdata);
 
-typedef struct {
-    /* Private to the spawn implementation.
-     */
-    /* This separate struct, from malloc, allows us to "detach"
-     * the child and reap it later, when our user has gone
-     * away and freed its libxl__spawn_state */
-    struct libxl__spawn_state *ss;
-    libxl__ev_child mid;
-} libxl__spawn_state_detachable;
+/*
+ * Called when the detach (requested by libxl__spawn_initiate_detach) has
+ * completed.  On entry to the callback the spawn state is Idle.
+ */
+typedef void libxl__spawn_detached_cb(libxl__egc*, libxl__spawn_state*);
 
 struct libxl__spawn_state {
     /* must be filled in by user and remain valid */
@@ -1129,15 +1127,18 @@ struct libxl__spawn_state {
     libxl__spawn_midproc_cb *midproc_cb;
     libxl__spawn_failure_cb *failure_cb;
     libxl__spawn_confirm_cb *confirm_cb;
+    libxl__spawn_detached_cb *detached_cb;
 
     /* remaining fields are private to libxl_spawn_... */
+    int detaching; /* we are in Detaching */
+    int failed; /* might be true whenever we are not Idle */
+    libxl__ev_child mid; /* always in use whenever we are not Idle */
     libxl__ev_time timeout;
     libxl__ev_xswatch xswatch;
-    libxl__spawn_state_detachable *ssd;
 };
 
 static inline int libxl__spawn_inuse(libxl__spawn_state *ss)
-    { return !!ss->ssd; }
+    { return libxl__ev_child_inuse(&ss->mid); }
 
 /*
  * libxl_spawner_record_pid - Record given pid in xenstore
-- 
1.7.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 Jun 26 17:59:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1Sja2S-0007ku-Uj; Tue, 26 Jun 2012 17:58:56 +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 1Sja2Q-0007ii-48
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:58:54 +0000
Received: from [85.158.138.51:28781] by server-12.bemta-3.messagelabs.com id
	0B/04-30206-D58F9EF4; Tue, 26 Jun 2012 17:58:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340733532!20505759!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4618 invoked from network); 26 Jun 2012 17:58:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:58:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:58:52 +0100
Date: Tue, 26 Jun 2012 18:58:27 +0100
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: <1340718633.3832.118.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718633.3832.118.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 5/5] xcbuild: add console and xenstore
	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, 26 Jun 2012, Ian Campbell wrote:
> Do you not have libxl and friends up and running sufficiently to use?
> This xcbuild was really just intended to tide us over until that stuff
> worked, not to be an actual thing...

xl/libxl works well enough for basic commands like "xl list", however
in order to support something like "xl create" I expect that some more
refactoring is needed as well as code motion to arch specific files.
Considering that we are in code freeze right now, I thought it wouldn't
be acceptable for 4.2, so I didn't even try.


> On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  tools/xcutils/Makefile  |    4 +-
> >  tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
> >  2 files changed, 59 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> > index 92c5a68..c88f286 100644
> > --- a/tools/xcutils/Makefile
> > +++ b/tools/xcutils/Makefile
> > @@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
> >  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> >  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
> >  CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
> > -CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> > +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
> >  
> >  .PHONY: all
> >  all: build
> > @@ -35,7 +35,7 @@ xc_save: xc_save.o
> >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> >  
> >  xcbuild: xcbuild.o
> > -	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> >  
> >  readnotes: readnotes.o
> >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> > index a70c3ca..7b5c0f8 100644
> > --- a/tools/xcutils/xcbuild.c
> > +++ b/tools/xcutils/xcbuild.c
> > @@ -1,6 +1,7 @@
> >  #include <unistd.h>
> >  #include <stdio.h>
> >  #include <stdlib.h>
> > +#include <string.h>
> >  
> >  #include <errno.h>
> >  
> > @@ -8,6 +9,7 @@
> >  //#include <xenguest.h>
> >  #include <xentoollog.h>
> >  #include <xc_dom.h>
> > +#include <xenstore.h>
> >  
> >  int main(int argc, char **argv)
> >  {
> > @@ -15,11 +17,19 @@ int main(int argc, char **argv)
> >  	xc_interface *xch;
> >  	int rv;
> >  	const char *image;
> > -	uint32_t domid;
> > +	uint32_t domid = 1;
> >  	xen_domain_handle_t handle;
> >  	int maxmem = 128; /* MB */ //atoi(argv[2]);
> >  	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
> >  	struct xc_dom_image *dom;
> > +	unsigned long console_mfn;
> > +	unsigned long console_port;
> > +	unsigned long store_mfn;
> > +	unsigned long store_port;
> > +	struct xs_handle *xs;
> > +	char *dom_path;
> > +	char path[256];
> > +	char val[256];
> >  
> >  	image = (argc < 2) ? "guest.img" : argv[1];
> >  	printf("Image: %s\n", image);
> > @@ -103,6 +113,52 @@ int main(int argc, char **argv)
> >  	if (rv) return rv;
> >  	rv = xc_dom_build_image(dom);
> >  	if (rv) return rv;
> > +
> > +	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
> > +	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > +	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
> > +
> > +	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
> > +	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > +	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
> > +	xs = xs_daemon_open();
> > +	if (xs == NULL) {
> > +		printf("Could not contact XenStore");
> > +		return errno;
> > +	}
> > +	dom_path = xs_get_domain_path(xs, domid);
> > +
> > +	snprintf(path, sizeof(path), "%s/console/port", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", console_port);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", console_mfn);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/type", dom_path);
> > +	snprintf(val, sizeof(val), "xenconsoled");
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/output", dom_path);
> > +	snprintf(val, sizeof(val), "pty");
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
> > +	snprintf(val, sizeof(val), "%d", 1048576);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/store/port", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", store_port);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", store_mfn);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +	xs_introduce_domain(xs, domid, store_mfn, store_port);
> > +
> > +	xs_daemon_close(xs);
> > +
> >  	rv = xc_dom_boot_image(dom);
> >  	if (rv) return rv;
> >  
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 17:59:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 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 1Sja2S-0007ku-Uj; Tue, 26 Jun 2012 17:58:56 +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 1Sja2Q-0007ii-48
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 17:58:54 +0000
Received: from [85.158.138.51:28781] by server-12.bemta-3.messagelabs.com id
	0B/04-30206-D58F9EF4; Tue, 26 Jun 2012 17:58:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340733532!20505759!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4618 invoked from network); 26 Jun 2012 17:58:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 17:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 17:58:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 18:58:52 +0100
Date: Tue, 26 Jun 2012 18:58:27 +0100
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: <1340718633.3832.118.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718633.3832.118.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 5/5] xcbuild: add console and xenstore
	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, 26 Jun 2012, Ian Campbell wrote:
> Do you not have libxl and friends up and running sufficiently to use?
> This xcbuild was really just intended to tide us over until that stuff
> worked, not to be an actual thing...

xl/libxl works well enough for basic commands like "xl list", however
in order to support something like "xl create" I expect that some more
refactoring is needed as well as code motion to arch specific files.
Considering that we are in code freeze right now, I thought it wouldn't
be acceptable for 4.2, so I didn't even try.


> On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  tools/xcutils/Makefile  |    4 +-
> >  tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
> >  2 files changed, 59 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> > index 92c5a68..c88f286 100644
> > --- a/tools/xcutils/Makefile
> > +++ b/tools/xcutils/Makefile
> > @@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
> >  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> >  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
> >  CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
> > -CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> > +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
> >  
> >  .PHONY: all
> >  all: build
> > @@ -35,7 +35,7 @@ xc_save: xc_save.o
> >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> >  
> >  xcbuild: xcbuild.o
> > -	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> >  
> >  readnotes: readnotes.o
> >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> > index a70c3ca..7b5c0f8 100644
> > --- a/tools/xcutils/xcbuild.c
> > +++ b/tools/xcutils/xcbuild.c
> > @@ -1,6 +1,7 @@
> >  #include <unistd.h>
> >  #include <stdio.h>
> >  #include <stdlib.h>
> > +#include <string.h>
> >  
> >  #include <errno.h>
> >  
> > @@ -8,6 +9,7 @@
> >  //#include <xenguest.h>
> >  #include <xentoollog.h>
> >  #include <xc_dom.h>
> > +#include <xenstore.h>
> >  
> >  int main(int argc, char **argv)
> >  {
> > @@ -15,11 +17,19 @@ int main(int argc, char **argv)
> >  	xc_interface *xch;
> >  	int rv;
> >  	const char *image;
> > -	uint32_t domid;
> > +	uint32_t domid = 1;
> >  	xen_domain_handle_t handle;
> >  	int maxmem = 128; /* MB */ //atoi(argv[2]);
> >  	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
> >  	struct xc_dom_image *dom;
> > +	unsigned long console_mfn;
> > +	unsigned long console_port;
> > +	unsigned long store_mfn;
> > +	unsigned long store_port;
> > +	struct xs_handle *xs;
> > +	char *dom_path;
> > +	char path[256];
> > +	char val[256];
> >  
> >  	image = (argc < 2) ? "guest.img" : argv[1];
> >  	printf("Image: %s\n", image);
> > @@ -103,6 +113,52 @@ int main(int argc, char **argv)
> >  	if (rv) return rv;
> >  	rv = xc_dom_build_image(dom);
> >  	if (rv) return rv;
> > +
> > +	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
> > +	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > +	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
> > +
> > +	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
> > +	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > +	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
> > +	xs = xs_daemon_open();
> > +	if (xs == NULL) {
> > +		printf("Could not contact XenStore");
> > +		return errno;
> > +	}
> > +	dom_path = xs_get_domain_path(xs, domid);
> > +
> > +	snprintf(path, sizeof(path), "%s/console/port", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", console_port);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", console_mfn);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/type", dom_path);
> > +	snprintf(val, sizeof(val), "xenconsoled");
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/output", dom_path);
> > +	snprintf(val, sizeof(val), "pty");
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
> > +	snprintf(val, sizeof(val), "%d", 1048576);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/store/port", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", store_port);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +
> > +	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
> > +	snprintf(val, sizeof(val), "%lu", store_mfn);
> > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > +	xs_introduce_domain(xs, domid, store_mfn, store_port);
> > +
> > +	xs_daemon_close(xs);
> > +
> >  	rv = xc_dom_boot_image(dom);
> >  	if (rv) return rv;
> >  
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 18:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18:00: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 1Sja3Y-0008Lb-Ex; Tue, 26 Jun 2012 18:00: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 1Sja3W-0008H9-Ue
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 18:00:03 +0000
Received: from [85.158.138.51:34592] by server-4.bemta-3.messagelabs.com id
	59/6C-17105-2A8F9EF4; Tue, 26 Jun 2012 18:00:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733601!20749707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4566 invoked from network); 26 Jun 2012 18:00:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 18:00:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 18:00:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 19:00:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sja3U-0000m2-Ti; Tue, 26 Jun 2012 18:00:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sja3U-0005hU-Ss;
	Tue, 26 Jun 2012 19:00:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.63648.864838.199205@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 19:00:00 +0100
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.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: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> This is v5 of my series to asyncify save/restore, rebased to tip and
> retested.  There are minor changes to 3 patches, as discussed on-list,
> marked with "*" below:
> 
>     01/21 libxc: xc_domain_restore, make toolstack_restore const-correct
>     02/21 libxc: Do not segfault if (e.g.) switch_qemu_logdirty fails
>     03/21 libxl: domain save: rename variables etc.
>     04/21 libxl: domain restore: reshuffle, preparing for ao
>   * 05/21 libxl: domain save: API changes for asynchrony
>   * 06/21 libxl: domain save/restore: run in a separate process
>     07/21 libxl: rename libxl_dom:save_helper to physmap_path
>     08/21 libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
>     09/21 libxl: wait for qemu to acknowledge logdirty command
>     10/21 libxl: datacopier: provide "prefix data" facility
>     11/21 libxl: prepare for asynchronous writing of qemu save file
>     12/21 libxl: Make libxl__domain_save_device_model asynchronous
>     13/21 libxl: Add a gc to libxl_get_cpu_topology
>     14/21 libxl: Do not pass NULL as gc_opt; introduce NOGC
>     15/21 libxl: Get compiler to warn about gc_opt==NULL
>     16/21 xl: Handle return value from libxl_domain_suspend correctly
>     17/21 libxl: do not leak dms->saved_state
>     18/21 libxl: do not leak spawned middle children
>     19/21 libxl: do not leak an event struct on ignored ao progress
>   * 20/21 libxl: further fixups re LIBXL_DOMAIN_TYPE
>   ! 21/21 libxl: DO NOT APPLY enforce prohibition on internal
> 
> All of these apart from the last have been acked and I intend to
> commit those to xen-unstable.hg soon.
> 
> However, first I will invite Shriram to check that Remus is still
> working.  (I can't conveniently do this with this message due to
> shoddiness in git-send-email.)

Shriram, would you care to take a look at this series and perhaps
retest it ?

If you would prefer a git branch to a series of patches, you can find
it here:
  http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram
NB that branch is REBASING.

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 Jun 26 18:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18:00: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 1Sja3Y-0008Lb-Ex; Tue, 26 Jun 2012 18:00: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 1Sja3W-0008H9-Ue
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 18:00:03 +0000
Received: from [85.158.138.51:34592] by server-4.bemta-3.messagelabs.com id
	59/6C-17105-2A8F9EF4; Tue, 26 Jun 2012 18:00:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340733601!20749707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4566 invoked from network); 26 Jun 2012 18:00:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 18:00:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 18:00:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 19:00:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sja3U-0000m2-Ti; Tue, 26 Jun 2012 18:00:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sja3U-0005hU-Ss;
	Tue, 26 Jun 2012 19:00:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20457.63648.864838.199205@mariner.uk.xensource.com>
Date: Tue, 26 Jun 2012 19:00:00 +0100
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.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: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> This is v5 of my series to asyncify save/restore, rebased to tip and
> retested.  There are minor changes to 3 patches, as discussed on-list,
> marked with "*" below:
> 
>     01/21 libxc: xc_domain_restore, make toolstack_restore const-correct
>     02/21 libxc: Do not segfault if (e.g.) switch_qemu_logdirty fails
>     03/21 libxl: domain save: rename variables etc.
>     04/21 libxl: domain restore: reshuffle, preparing for ao
>   * 05/21 libxl: domain save: API changes for asynchrony
>   * 06/21 libxl: domain save/restore: run in a separate process
>     07/21 libxl: rename libxl_dom:save_helper to physmap_path
>     08/21 libxl: provide libxl__xs_*_checked and libxl__xs_transaction_*
>     09/21 libxl: wait for qemu to acknowledge logdirty command
>     10/21 libxl: datacopier: provide "prefix data" facility
>     11/21 libxl: prepare for asynchronous writing of qemu save file
>     12/21 libxl: Make libxl__domain_save_device_model asynchronous
>     13/21 libxl: Add a gc to libxl_get_cpu_topology
>     14/21 libxl: Do not pass NULL as gc_opt; introduce NOGC
>     15/21 libxl: Get compiler to warn about gc_opt==NULL
>     16/21 xl: Handle return value from libxl_domain_suspend correctly
>     17/21 libxl: do not leak dms->saved_state
>     18/21 libxl: do not leak spawned middle children
>     19/21 libxl: do not leak an event struct on ignored ao progress
>   * 20/21 libxl: further fixups re LIBXL_DOMAIN_TYPE
>   ! 21/21 libxl: DO NOT APPLY enforce prohibition on internal
> 
> All of these apart from the last have been acked and I intend to
> commit those to xen-unstable.hg soon.
> 
> However, first I will invite Shriram to check that Remus is still
> working.  (I can't conveniently do this with this message due to
> shoddiness in git-send-email.)

Shriram, would you care to take a look at this series and perhaps
retest it ?

If you would prefer a git branch to a series of patches, you can find
it here:
  http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram
NB that branch is REBASING.

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 Jun 26 18:06:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18:06: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 1Sja9v-0000Wv-AZ; Tue, 26 Jun 2012 18:06:39 +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 1Sja9t-0000Wq-9n
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 18:06:37 +0000
Received: from [85.158.138.51:4895] by server-2.bemta-3.messagelabs.com id
	62/76-10266-C2AF9EF4; Tue, 26 Jun 2012 18:06:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340733995!26760097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22302 invoked from network); 26 Jun 2012 18:06:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 18:06:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 18:06:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 19:06:21 +0100
Date: Tue, 26 Jun 2012 19:05:55 +0100
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: <1340721279.3832.143.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340721279.3832.143.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 4/5] libxc/arm: allocate xenstore and
	console 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > Allocate two additional pages at the end of the guest physical memory
> > for xenstore and console.
> > Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> > values.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
> >  1 files changed, 22 insertions(+), 10 deletions(-)
> > 
> > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > index bb86139..df2eefe 100644
> > --- a/tools/libxc/xc_dom_arm.c
> > +++ b/tools/libxc/xc_dom_arm.c
> > @@ -25,6 +25,10 @@
> >  #include "xg_private.h"
> >  #include "xc_dom.h"
> >  
> > +#define NR_MAGIC_PAGES 2
> > +#define CONSOLE_PFN_OFFSET 0
> > +#define XENSTORE_PFN_OFFSET 1
> > +
> >  /* ------------------------------------------------------------------------ */
> >  /*
> >   * arm guests are hybrid and start off with paging disabled, therefore no
> > @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> >  static int alloc_magic_pages(struct xc_dom_image *dom)
> >  {
> >      DOMPRINTF_CALLED(dom->xch);
> > -    /* XXX
> > -     *   dom->p2m_guest
> > -     *   dom->start_info_pfn
> > -     *   dom->xenstore_pfn
> > -     *   dom->console_pfn
> > -     */
> >      return 0;
> >  }
> >  
> > @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> >  {
> >      int rc;
> >      xen_pfn_t pfn, allocsz, i;
> > +    xen_pfn_t store_pfn, console_pfn;
> >  
> >      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
> >              dom->total_pages, dom->rambase_pfn);
> >  
> >      dom->shadow_enabled = 1;
> >  
> > -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> > +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
> >  
> >      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
> >              dom->rambase_pfn, dom->total_pages );
> >      /* setup initial p2m */
> > -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> > +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
> >          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
> >  
> >      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> > @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> >  
> >      /* allocate guest memory */
> >      for ( i = rc = allocsz = 0;
> > -          (i < dom->total_pages) && !rc;
> > +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
> >            i += allocsz )
> >      {
> > -        allocsz = dom->total_pages - i;
> > +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
> 
> All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.
> 
> Do these pages need to be in p2m_host or would it be fine to just insert
> them into the guest p2m individually outside the main allocation logic?

I think it makes sense for them to be in p2m_host. In fact if we try to
allocate them later, wouldn't we have the problem of having to extend
the guest p2m? We might as well do it here.


> Otherwise perhaps simply int total_pages = dom->total_pages + NR... and
> use throughout?

Yes, I can do that.


> >          if ( allocsz > 1024*1024 )
> >              allocsz = 1024*1024;
> >          fprintf(stderr, "alloc %"PRI_xen_pfn" at offset %"PRI_xen_pfn" which is %"PRI_xen_pfn"\n",
> > @@ -168,6 +167,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> >      fprintf(stderr, "%s: popl'd p2m_host[%"PRI_xen_pfn"] = %"PRI_xen_pfn"\n",
> >              __func__, dom->total_pages-1, dom->p2m_host[dom->total_pages-1]);
> 
> I really need to scrub the debug printfs from my patch...
> 
> >  
> > +    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
> > +    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
> > +            console_pfn);
> > +    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
> > +            store_pfn);
> > +
> > +    fprintf(stderr, "%s: console_pfn=%"PRI_xen_pfn" xenstore_pfn=%"PRI_xen_pfn"\n",
> > +            __func__, console_pfn, store_pfn);
> 
> ... and so do you ;-)
 
OK :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 18:06:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18:06: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 1Sja9v-0000Wv-AZ; Tue, 26 Jun 2012 18:06:39 +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 1Sja9t-0000Wq-9n
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 18:06:37 +0000
Received: from [85.158.138.51:4895] by server-2.bemta-3.messagelabs.com id
	62/76-10266-C2AF9EF4; Tue, 26 Jun 2012 18:06:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340733995!26760097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22302 invoked from network); 26 Jun 2012 18:06:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 18:06:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13231716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 18:06:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 19:06:21 +0100
Date: Tue, 26 Jun 2012 19:05:55 +0100
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: <1340721279.3832.143.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340721279.3832.143.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 4/5] libxc/arm: allocate xenstore and
	console 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 Tue, 26 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > Allocate two additional pages at the end of the guest physical memory
> > for xenstore and console.
> > Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> > values.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
> >  1 files changed, 22 insertions(+), 10 deletions(-)
> > 
> > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > index bb86139..df2eefe 100644
> > --- a/tools/libxc/xc_dom_arm.c
> > +++ b/tools/libxc/xc_dom_arm.c
> > @@ -25,6 +25,10 @@
> >  #include "xg_private.h"
> >  #include "xc_dom.h"
> >  
> > +#define NR_MAGIC_PAGES 2
> > +#define CONSOLE_PFN_OFFSET 0
> > +#define XENSTORE_PFN_OFFSET 1
> > +
> >  /* ------------------------------------------------------------------------ */
> >  /*
> >   * arm guests are hybrid and start off with paging disabled, therefore no
> > @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> >  static int alloc_magic_pages(struct xc_dom_image *dom)
> >  {
> >      DOMPRINTF_CALLED(dom->xch);
> > -    /* XXX
> > -     *   dom->p2m_guest
> > -     *   dom->start_info_pfn
> > -     *   dom->xenstore_pfn
> > -     *   dom->console_pfn
> > -     */
> >      return 0;
> >  }
> >  
> > @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> >  {
> >      int rc;
> >      xen_pfn_t pfn, allocsz, i;
> > +    xen_pfn_t store_pfn, console_pfn;
> >  
> >      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
> >              dom->total_pages, dom->rambase_pfn);
> >  
> >      dom->shadow_enabled = 1;
> >  
> > -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> > +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
> >  
> >      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
> >              dom->rambase_pfn, dom->total_pages );
> >      /* setup initial p2m */
> > -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> > +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
> >          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
> >  
> >      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> > @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> >  
> >      /* allocate guest memory */
> >      for ( i = rc = allocsz = 0;
> > -          (i < dom->total_pages) && !rc;
> > +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
> >            i += allocsz )
> >      {
> > -        allocsz = dom->total_pages - i;
> > +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
> 
> All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.
> 
> Do these pages need to be in p2m_host or would it be fine to just insert
> them into the guest p2m individually outside the main allocation logic?

I think it makes sense for them to be in p2m_host. In fact if we try to
allocate them later, wouldn't we have the problem of having to extend
the guest p2m? We might as well do it here.


> Otherwise perhaps simply int total_pages = dom->total_pages + NR... and
> use throughout?

Yes, I can do that.


> >          if ( allocsz > 1024*1024 )
> >              allocsz = 1024*1024;
> >          fprintf(stderr, "alloc %"PRI_xen_pfn" at offset %"PRI_xen_pfn" which is %"PRI_xen_pfn"\n",
> > @@ -168,6 +167,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> >      fprintf(stderr, "%s: popl'd p2m_host[%"PRI_xen_pfn"] = %"PRI_xen_pfn"\n",
> >              __func__, dom->total_pages-1, dom->p2m_host[dom->total_pages-1]);
> 
> I really need to scrub the debug printfs from my patch...
> 
> >  
> > +    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
> > +    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
> > +            console_pfn);
> > +    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
> > +            store_pfn);
> > +
> > +    fprintf(stderr, "%s: console_pfn=%"PRI_xen_pfn" xenstore_pfn=%"PRI_xen_pfn"\n",
> > +            __func__, console_pfn, store_pfn);
> 
> ... and so do you ;-)
 
OK :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 18:30:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18: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 1SjaWW-0000rH-5y; Tue, 26 Jun 2012 18:30: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 1SjaWU-0000rC-T7
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 18:29:59 +0000
Received: from [85.158.143.99:14768] by server-2.bemta-4.messagelabs.com id
	B6/E1-17938-6AFF9EF4; Tue, 26 Jun 2012 18:29:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340735397!29220802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10290 invoked from network); 26 Jun 2012 18:29:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 18:29:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13232017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 18:29:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 19:29:57 +0100
Date: Tue, 26 Jun 2012 19:29:31 +0100
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: <1340720842.3832.137.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720842.3832.137.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 1/5] xen/arm: implement do_hvm_op 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

On Tue, 26 Jun 2012, Ian Campbell wrote:
> We need to device how hybrid our hybrid arm guests are going to be.

Right.


> The particular hvm params you are using here (evtchn port etc) typically
> live in start_info for a PV guest. In principal we could define a start
> info for ARM too but that leaves the question of how the guest can find
> it (which loops up back to hvm_params...).

One way would be to introduce a new XENMAPSPACE, like we have done for
XENMAPSPACE_shared_info. Then the guest would use a
XENMEM_add_to_physmap to map it.


> Looking at the other stuff in start_info, it has stuff like modules (aka
> ramdisks) and command lines which ARM guest get via the normal ARM boot
> protocol stuff (i.e. the domain builder does it) and a bunch of stuff
> which seems to only make sense for proper-PV guests.
> 
> So maybe HVM PARAM is the right answer?

Yes, that is one of the reasons why I preferred introducing hvm_op
rather than a new XENMAPSPACE: we don't need anything else from
start_info aside from the parameters already provided through
HVMOP_get_param.
On the other hand hvm_op can be useful for other things, for example one
day we might use the HVM_PARAM_IOREQ_PFN parameter.
Most importantly, from the Linux side of things, acting like a PV on HVM
kernel is a perfect fit, the changes required are down to a minimum.


> sinfo does have flags which contains stuff like SIF_INITIAL_DOMAIN.
> Might we want that?

We don't need it thanks to XENFEAT_dom0, see 
1340381685-22529-3-git-send-email-stefano.stabellini@eu.citrix.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 18:30:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18: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 1SjaWW-0000rH-5y; Tue, 26 Jun 2012 18:30: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 1SjaWU-0000rC-T7
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 18:29:59 +0000
Received: from [85.158.143.99:14768] by server-2.bemta-4.messagelabs.com id
	B6/E1-17938-6AFF9EF4; Tue, 26 Jun 2012 18:29:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340735397!29220802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI1OTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10290 invoked from network); 26 Jun 2012 18:29:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 18:29:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="13232017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 18:29:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 19:29:57 +0100
Date: Tue, 26 Jun 2012 19:29:31 +0100
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: <1340720842.3832.137.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720842.3832.137.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 1/5] xen/arm: implement do_hvm_op 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

On Tue, 26 Jun 2012, Ian Campbell wrote:
> We need to device how hybrid our hybrid arm guests are going to be.

Right.


> The particular hvm params you are using here (evtchn port etc) typically
> live in start_info for a PV guest. In principal we could define a start
> info for ARM too but that leaves the question of how the guest can find
> it (which loops up back to hvm_params...).

One way would be to introduce a new XENMAPSPACE, like we have done for
XENMAPSPACE_shared_info. Then the guest would use a
XENMEM_add_to_physmap to map it.


> Looking at the other stuff in start_info, it has stuff like modules (aka
> ramdisks) and command lines which ARM guest get via the normal ARM boot
> protocol stuff (i.e. the domain builder does it) and a bunch of stuff
> which seems to only make sense for proper-PV guests.
> 
> So maybe HVM PARAM is the right answer?

Yes, that is one of the reasons why I preferred introducing hvm_op
rather than a new XENMAPSPACE: we don't need anything else from
start_info aside from the parameters already provided through
HVMOP_get_param.
On the other hand hvm_op can be useful for other things, for example one
day we might use the HVM_PARAM_IOREQ_PFN parameter.
Most importantly, from the Linux side of things, acting like a PV on HVM
kernel is a perfect fit, the changes required are down to a minimum.


> sinfo does have flags which contains stuff like SIF_INITIAL_DOMAIN.
> Might we want that?

We don't need it thanks to XENFEAT_dom0, see 
1340381685-22529-3-git-send-email-stefano.stabellini@eu.citrix.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 18:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18: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 1SjalL-0001Bu-Me; Tue, 26 Jun 2012 18:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SjalJ-0001Bk-Hv
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 18:45:17 +0000
Received: from [85.158.138.51:57387] by server-11.bemta-3.messagelabs.com id
	32/07-02904-7330AEF4; Tue, 26 Jun 2012 18:45:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340736308!28482410!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12616 invoked from network); 26 Jun 2012 18:45:10 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jun 2012 18:45:10 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5QIj5bU027281
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 11:45:06 -0700
Received: by bkwj10 with SMTP id j10so291117bkw.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 11:45:04 -0700 (PDT)
Received: by 10.204.150.89 with SMTP id x25mr5916276bkv.24.1340736304084; Tue,
	26 Jun 2012 11:45:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Tue, 26 Jun 2012 11:44:23 -0700 (PDT)
In-Reply-To: <20457.63648.864838.199205@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 26 Jun 2012 14:44:23 -0400
Message-ID: <CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1252988008459377519=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1252988008459377519==
Content-Type: multipart/alternative; boundary=0015175cfe1824786b04c3647f20

--0015175cfe1824786b04c3647f20
Content-Type: text/plain; charset=ISO-8859-1

>
> Shriram, would you care to take a look at this series and perhaps
> retest it ?
>
>
Sure will do.


If you would prefer a git branch to a series of patches, you can find
> it here:
>
> http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
>  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram
> NB that branch is REBASING.
>
>
I am not too familiar with the git lingo.. What did you mean by "branch is
rebasing" ?
Am I supposed to do something special, apart from the normal process below:
git clone git://xen....
git checkout -b for-shriram origin/for-shriram

thanks
shriram


> Thanks,
> Ian.
>
>

--0015175cfe1824786b04c3647f20
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<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">Shriram, would yo=
u care to take a look at this series and perhaps<br>
retest it ?<br>
<br></blockquote><div><br></div><div>Sure will do.</div><div><br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
If you would prefer a git branch to a series of patches, you can find<br>
it here:<br>
 =A0<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.g=
it;a=3Dshortlog;h=3Drefs/heads/for-shriram" target=3D"_blank">http://xenbit=
s.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.git;a=3Dshortlog;h=3Drefs/hea=
ds/for-shriram</a><br>


 =A0git://<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstable.git#shr=
iram" target=3D"_blank">xenbits.xen.org/people/iwj/xen-unstable.git#shriram=
</a><br>
NB that branch is REBASING.<br>
<br></blockquote><div><br></div><div>I am not too familiar with the git lin=
go.. What did you mean by=A0&quot;branch is rebasing&quot; ?</div><div>Am I=
 supposed to do something special, apart from=A0the normal process below:=
=A0</div>

<div>git clone git://xen....</div><div>git checkout -b for-shriram origin/f=
or-shriram=A0</div><div><br></div><div>thanks</div><div>shriram</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">


Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>

--0015175cfe1824786b04c3647f20--


--===============1252988008459377519==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1252988008459377519==--


From xen-devel-bounces@lists.xen.org Tue Jun 26 18:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 18: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 1SjalL-0001Bu-Me; Tue, 26 Jun 2012 18:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SjalJ-0001Bk-Hv
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 18:45:17 +0000
Received: from [85.158.138.51:57387] by server-11.bemta-3.messagelabs.com id
	32/07-02904-7330AEF4; Tue, 26 Jun 2012 18:45:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340736308!28482410!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12616 invoked from network); 26 Jun 2012 18:45:10 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jun 2012 18:45:10 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5QIj5bU027281
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 11:45:06 -0700
Received: by bkwj10 with SMTP id j10so291117bkw.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 11:45:04 -0700 (PDT)
Received: by 10.204.150.89 with SMTP id x25mr5916276bkv.24.1340736304084; Tue,
	26 Jun 2012 11:45:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Tue, 26 Jun 2012 11:44:23 -0700 (PDT)
In-Reply-To: <20457.63648.864838.199205@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 26 Jun 2012 14:44:23 -0400
Message-ID: <CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1252988008459377519=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1252988008459377519==
Content-Type: multipart/alternative; boundary=0015175cfe1824786b04c3647f20

--0015175cfe1824786b04c3647f20
Content-Type: text/plain; charset=ISO-8859-1

>
> Shriram, would you care to take a look at this series and perhaps
> retest it ?
>
>
Sure will do.


If you would prefer a git branch to a series of patches, you can find
> it here:
>
> http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
>  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram
> NB that branch is REBASING.
>
>
I am not too familiar with the git lingo.. What did you mean by "branch is
rebasing" ?
Am I supposed to do something special, apart from the normal process below:
git clone git://xen....
git checkout -b for-shriram origin/for-shriram

thanks
shriram


> Thanks,
> Ian.
>
>

--0015175cfe1824786b04c3647f20
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<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">Shriram, would yo=
u care to take a look at this series and perhaps<br>
retest it ?<br>
<br></blockquote><div><br></div><div>Sure will do.</div><div><br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
If you would prefer a git branch to a series of patches, you can find<br>
it here:<br>
 =A0<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.g=
it;a=3Dshortlog;h=3Drefs/heads/for-shriram" target=3D"_blank">http://xenbit=
s.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.git;a=3Dshortlog;h=3Drefs/hea=
ds/for-shriram</a><br>


 =A0git://<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstable.git#shr=
iram" target=3D"_blank">xenbits.xen.org/people/iwj/xen-unstable.git#shriram=
</a><br>
NB that branch is REBASING.<br>
<br></blockquote><div><br></div><div>I am not too familiar with the git lin=
go.. What did you mean by=A0&quot;branch is rebasing&quot; ?</div><div>Am I=
 supposed to do something special, apart from=A0the normal process below:=
=A0</div>

<div>git clone git://xen....</div><div>git checkout -b for-shriram origin/f=
or-shriram=A0</div><div><br></div><div>thanks</div><div>shriram</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">


Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>

--0015175cfe1824786b04c3647f20--


--===============1252988008459377519==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1252988008459377519==--


From xen-devel-bounces@lists.xen.org Tue Jun 26 20:33:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 20:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjcQz-0002Er-Fm; Tue, 26 Jun 2012 20:32:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SjcQy-0002Em-IV
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 20:32:24 +0000
Received: from [85.158.139.83:51468] by server-7.bemta-5.messagelabs.com id
	3A/E9-28276-75C1AEF4; Tue, 26 Jun 2012 20:32:23 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340742741!26930056!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk1NTUy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4599 invoked from network); 26 Jun 2012 20:32:22 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 20:32:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340742743; x=1372278743;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=axR0Irmy4GFakXIjWr+EZ1gTBuEWxCLkwI1Rs6frL7E=;
	b=K/ZI+Xr662jKFFfrU9bxcPrCrQJbxIqnOmqEnZCGFxm1dyU/g26ludLD
	WntSZWRMU2E10sw6Ow7NUex4XA9Iqw==;
X-IronPort-AV: E=Sophos;i="4.77,480,1336348800"; d="scan'208";a="987855526"
Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2012 20:31:54 +0000
Received: from ex10-hub-9002.ant.amazon.com (ex10-hub-9002.ant.amazon.com
	[10.185.137.130])
	by smtp-in-1105.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5QKVqhH003723
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 26 Jun 2012 20:31:53 GMT
Received: from US-SEA-R8XVZTX (10.224.80.44) by ex10-hub-9002.ant.amazon.com
	(10.185.137.130) with Microsoft SMTP Server id 14.2.247.3;
	Tue, 26 Jun 2012 13:31:51 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Tue, 26 Jun 2012
	13:31:51 -0700
Date: Tue, 26 Jun 2012 13:31:51 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120626203151.GA8676@US-SEA-R8XVZTX>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
>     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
>       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822

This may be a problem with the guest, rather than a problem with Xen
or the toolstack. I tested on a domU running a 3.2.20-based Linux
kernel. The domU kernel didn't automatically enable the vCPUs after
calling "xl vcpu-set" to increase the allocation.

# xl list 2
Name                                        ID   Mem VCPUs      State Time(s)
test                                         2 15360     1     -b---- 6617.6
# xl vcpu-set 2 4
# xl list 2
Name                                        ID   Mem VCPUs      State Time(s)
test                                         2 15360     1     -b---- 6617.7

But when I hotplugged the CPUs on the domU side with

  for online in /sys/devices/system/cpu/cpu*/online; do
      echo 1 > $online
  done

Now we see:

# xl list 2
Name                                        ID   Mem VCPUs      State Time(s)
test                                         2 15360     4     -b---- 6617.8

I've added this as a comment to the bugzilla.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 20:33:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 20:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjcQz-0002Er-Fm; Tue, 26 Jun 2012 20:32:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SjcQy-0002Em-IV
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 20:32:24 +0000
Received: from [85.158.139.83:51468] by server-7.bemta-5.messagelabs.com id
	3A/E9-28276-75C1AEF4; Tue, 26 Jun 2012 20:32:23 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340742741!26930056!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk1NTUy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4599 invoked from network); 26 Jun 2012 20:32:22 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 20:32:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340742743; x=1372278743;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=axR0Irmy4GFakXIjWr+EZ1gTBuEWxCLkwI1Rs6frL7E=;
	b=K/ZI+Xr662jKFFfrU9bxcPrCrQJbxIqnOmqEnZCGFxm1dyU/g26ludLD
	WntSZWRMU2E10sw6Ow7NUex4XA9Iqw==;
X-IronPort-AV: E=Sophos;i="4.77,480,1336348800"; d="scan'208";a="987855526"
Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2012 20:31:54 +0000
Received: from ex10-hub-9002.ant.amazon.com (ex10-hub-9002.ant.amazon.com
	[10.185.137.130])
	by smtp-in-1105.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5QKVqhH003723
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 26 Jun 2012 20:31:53 GMT
Received: from US-SEA-R8XVZTX (10.224.80.44) by ex10-hub-9002.ant.amazon.com
	(10.185.137.130) with Microsoft SMTP Server id 14.2.247.3;
	Tue, 26 Jun 2012 13:31:51 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Tue, 26 Jun 2012
	13:31:51 -0700
Date: Tue, 26 Jun 2012 13:31:51 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120626203151.GA8676@US-SEA-R8XVZTX>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
>     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
>       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822

This may be a problem with the guest, rather than a problem with Xen
or the toolstack. I tested on a domU running a 3.2.20-based Linux
kernel. The domU kernel didn't automatically enable the vCPUs after
calling "xl vcpu-set" to increase the allocation.

# xl list 2
Name                                        ID   Mem VCPUs      State Time(s)
test                                         2 15360     1     -b---- 6617.6
# xl vcpu-set 2 4
# xl list 2
Name                                        ID   Mem VCPUs      State Time(s)
test                                         2 15360     1     -b---- 6617.7

But when I hotplugged the CPUs on the domU side with

  for online in /sys/devices/system/cpu/cpu*/online; do
      echo 1 > $online
  done

Now we see:

# xl list 2
Name                                        ID   Mem VCPUs      State Time(s)
test                                         2 15360     4     -b---- 6617.8

I've added this as a comment to the bugzilla.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 21:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 21:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjctc-0002fv-TW; Tue, 26 Jun 2012 21:02:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sjctc-0002fl-2J
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 21:02:00 +0000
Received: from [193.109.254.147:37743] by server-4.bemta-14.messagelabs.com id
	FE/25-02077-7432AEF4; Tue, 26 Jun 2012 21:01:59 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340744509!3523628!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4728 invoked from network); 26 Jun 2012 21:01:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 21:01:51 -0000
Received: by obbta14 with SMTP id ta14so504527obb.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 14:01:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=kT7n8DQgiccxcJx8vPYSufEpKCcWBPkjXfHHw1GmiYg=;
	b=i447j2aTxJQBo7QzTgCG2hNVl5sMM0Y8sny0MpvrihtJeNpjBzI812f32BOW6Efblo
	fNcwQeq7mBL534i8mDTMXSEpWY61lqDNmkeqGI23iWgDhDNUlZRStijMgmWKlGlQuc95
	rB76Zrpnz0fLB7UkolZcW2RztYfnkebx2LAifCnfBXK8XiL4Z/fBq2ipYHkohI+EE80L
	pc49/3in8cmUXPNJuja95Gj6zpT7CzA4mrMKIZpwkKr8yHirw1A2sZQQrRHgUm/5ZWgW
	Th+G5cWhOtHmQi5LdcXmdVGYUTGrgjO9/iDgqoDRncgl+64rrLY5JpBBbOLBQ/BE5z7r
	GcxA==
Received: by 10.182.74.68 with SMTP id r4mr5525920obv.31.1340744509194; Tue,
	26 Jun 2012 14:01:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Tue, 26 Jun 2012 14:01:27 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Tue, 26 Jun 2012 23:01:27 +0200
Message-ID: <CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQn2kgxQqaC5bWuK8PXAUHFbeJdjRogyR9kdSiKIowswCXIjvw09fLKJL4GpeM9OMF5/yEOT
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 2:59 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 26 Jun 2012, Rolu wrote:
>> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Mon, 25 Jun 2012, Jan Beulich wrote:
>> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
>> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> >> At the same time, adding logging to the guest kernel would
>> >> >> be nice, to see what value it actually writes (in a current
>> >> >> kernel this would be in __write_msi_msg()).
>> >> >>
>> >> >
>> >> > Turns out that msg->data here is also 0x4300, so it seems the guest
>> >> > kernel is producing these values. I caused it to make a stack trace
>> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
>> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
>> >> > current data field and if it isn't equal to the macro it uses
>> >> > xen_msi_compose_msg to make a new message, but that function just sets
>> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
>> >> > then gets passed to __write_msi_msg and that's that. There are no
>> >> > other writes through __write_msi_msg (except for the same thing for
>> >> > other devices).
>> >> >
>> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
>> >> > decoded as the delivery mode, so it seems the kernel is intentionally
>> >> > setting it to 3.
>> >>
>> >> So that can never have worked properly afaict. Stefano, the
>> >> code as it is currently - using literal (3 << 8) - is clearly bogus.
>> >> Your original commit at least had a comment saying that the
>> >> reserved delivery mode encoding is intentional here, but that
>> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
>> >> In any case - the cooperation with qemu apparently doesn't
>> >> work, as the reserved encoding should never make it through
>> >> to the hypervisor. Could you explain what the intention here
>> >> was?
>> >>
>> >> And regardless of anything, can the literal numbers please be
>> >> replaced by proper manifest constants - the "8" here already
>> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
>> >> proper symbolic would permit locating where this is being (or
>> >> really, as it doesn't appear to work supposed to be) consumed
>> >> in qemu, provided it uses the same definition (i.e. that one
>> >> should go into one of the public headers).
>> >
>> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
>> > because notifications are not supposed to be delivered as MSI anymore.
>> >
>> > This is what should happen:
>> >
>> > 1) Linux configures the device with a 0 vector number and the pirq number
>> > in the address field;
>> >
>> > 2) QEMU notices a vector number of 0 and reads the pirq number from the
>> > address field, passing it to xc_domain_update_msi_irq;
>> >
>> > 3) Xen assignes the given pirq to the physical MSI;
>> >
>> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>> >
>> > 5) Xen sets the pirq as "IRQ_PT";
>> >
>> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
>> > returns true so Xen calls send_guest_pirq instead.
>> >
>> >
>> > Obviously 6) is not happening. hvm_domain_use_pirq is:
>> >
>> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
>> >
>> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
>> > above).
>>
>> This appears to be true. I added logging to hvm_pci_msi_assert in
>> xen/drivers/passthrough/io.c and it indicates that
>> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
>> before an unsupported delivery mode message.
>>
>> I also log pirq->pirq but I found that most of the time I can't find
>> this value anywhere else (I'm not sure how to interpret the value,
>> though). For example, in my last try:
>>
>> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
>> 53. The vast majority are for 54.
>> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
>> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
>> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
>> but complains it's already mapped.
>> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
>> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
>> 22, 52, 48, 47. Also never 54 or 53.
>> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
>> * The qemu log mentions pirq 35, 36 and 37
>>
>> It seems pirq values don't always mean the same? Is it a coincidence
>> that 55 occurs almost everywhere, or is something going wrong with the
>> other two values (53 and 54 versus 16 and 17)?
>>
>> I have three MSI capable devices passed through to the domU, and I do
>> see groups of three distinct pirqs in the data above - just not the
>> same ones in every place I look.
>>
>> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
>> > (__startup_pirq doesn't get called), or Xen is erroring out in
>> > map_domain_emuirq_pirq.
>>
>> evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.
>>
>> map_domain_emuirq_pirq always gets past the checks in the top half
>> (i.e. up to the line /* do not store emuirq mappings for pt devices
>> */), except for one time with pirq=49,emuirq=23 where it finds they
>> are already mapped.
>> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
>> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
>> directly logged that but it's the only assignment there).
>>
>> Interestingly, I get an unsupported delivery mode error for pirq 55
>> where my logging says pirq->arch.hvm.emuirq is -1, *after*
>> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.
>
> Looking back at your QEMU logs, it seems that pt_msi_setup is not
> called (or it is not called at the right time), otherwise you should
> get:
>
> pt_msi_setup requested pirq = %d
>
> in your logs.
> Could you try disabling msitranslate? You can do that adding
>
> pci_msitranslate=0
>
> to your VM config file.

I tried that, but it didn't work.

> If that works, probably this (untested) QEMU patch could fix your problem:
>

I appreciate the help.

I applied the patch anyway just to see what would happen (had to edit
a few dev versus d variable names) but it didn't help. It also breaks
pt_msi_update, as I get in the qemu log:

pt_msi_update: Update msi with pirq 2f gvec 0 gflags 302f
pt_msi_update: Error: Binding of MSI failed.
pt_msi_update: Error: Unmapping of MSI failed.
pt_msgctrl_reg_write: Warning: Can not bind MSI for dev 80

I added some logging to pt_msi_setup (without the patch). It does get
called, and it does so rather early in the boot process, each time
right before lines as these:

pci_intx: intx=1
register_real_device: Real physical device 00:1b.0 registered successfuly!
IRQ type = MSI-INTx

At this point dev->msi->data, addr_hi and addr_lo are all 0, which
doesn't seem right. Is it being called prematurely?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 21:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 21:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjctc-0002fv-TW; Tue, 26 Jun 2012 21:02:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sjctc-0002fl-2J
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 21:02:00 +0000
Received: from [193.109.254.147:37743] by server-4.bemta-14.messagelabs.com id
	FE/25-02077-7432AEF4; Tue, 26 Jun 2012 21:01:59 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340744509!3523628!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4728 invoked from network); 26 Jun 2012 21:01:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 21:01:51 -0000
Received: by obbta14 with SMTP id ta14so504527obb.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 14:01:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=kT7n8DQgiccxcJx8vPYSufEpKCcWBPkjXfHHw1GmiYg=;
	b=i447j2aTxJQBo7QzTgCG2hNVl5sMM0Y8sny0MpvrihtJeNpjBzI812f32BOW6Efblo
	fNcwQeq7mBL534i8mDTMXSEpWY61lqDNmkeqGI23iWgDhDNUlZRStijMgmWKlGlQuc95
	rB76Zrpnz0fLB7UkolZcW2RztYfnkebx2LAifCnfBXK8XiL4Z/fBq2ipYHkohI+EE80L
	pc49/3in8cmUXPNJuja95Gj6zpT7CzA4mrMKIZpwkKr8yHirw1A2sZQQrRHgUm/5ZWgW
	Th+G5cWhOtHmQi5LdcXmdVGYUTGrgjO9/iDgqoDRncgl+64rrLY5JpBBbOLBQ/BE5z7r
	GcxA==
Received: by 10.182.74.68 with SMTP id r4mr5525920obv.31.1340744509194; Tue,
	26 Jun 2012 14:01:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Tue, 26 Jun 2012 14:01:27 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Tue, 26 Jun 2012 23:01:27 +0200
Message-ID: <CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQn2kgxQqaC5bWuK8PXAUHFbeJdjRogyR9kdSiKIowswCXIjvw09fLKJL4GpeM9OMF5/yEOT
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 2:59 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 26 Jun 2012, Rolu wrote:
>> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Mon, 25 Jun 2012, Jan Beulich wrote:
>> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
>> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> >> At the same time, adding logging to the guest kernel would
>> >> >> be nice, to see what value it actually writes (in a current
>> >> >> kernel this would be in __write_msi_msg()).
>> >> >>
>> >> >
>> >> > Turns out that msg->data here is also 0x4300, so it seems the guest
>> >> > kernel is producing these values. I caused it to make a stack trace
>> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
>> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
>> >> > current data field and if it isn't equal to the macro it uses
>> >> > xen_msi_compose_msg to make a new message, but that function just sets
>> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
>> >> > then gets passed to __write_msi_msg and that's that. There are no
>> >> > other writes through __write_msi_msg (except for the same thing for
>> >> > other devices).
>> >> >
>> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
>> >> > decoded as the delivery mode, so it seems the kernel is intentionally
>> >> > setting it to 3.
>> >>
>> >> So that can never have worked properly afaict. Stefano, the
>> >> code as it is currently - using literal (3 << 8) - is clearly bogus.
>> >> Your original commit at least had a comment saying that the
>> >> reserved delivery mode encoding is intentional here, but that
>> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
>> >> In any case - the cooperation with qemu apparently doesn't
>> >> work, as the reserved encoding should never make it through
>> >> to the hypervisor. Could you explain what the intention here
>> >> was?
>> >>
>> >> And regardless of anything, can the literal numbers please be
>> >> replaced by proper manifest constants - the "8" here already
>> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
>> >> proper symbolic would permit locating where this is being (or
>> >> really, as it doesn't appear to work supposed to be) consumed
>> >> in qemu, provided it uses the same definition (i.e. that one
>> >> should go into one of the public headers).
>> >
>> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
>> > because notifications are not supposed to be delivered as MSI anymore.
>> >
>> > This is what should happen:
>> >
>> > 1) Linux configures the device with a 0 vector number and the pirq number
>> > in the address field;
>> >
>> > 2) QEMU notices a vector number of 0 and reads the pirq number from the
>> > address field, passing it to xc_domain_update_msi_irq;
>> >
>> > 3) Xen assignes the given pirq to the physical MSI;
>> >
>> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>> >
>> > 5) Xen sets the pirq as "IRQ_PT";
>> >
>> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
>> > returns true so Xen calls send_guest_pirq instead.
>> >
>> >
>> > Obviously 6) is not happening. hvm_domain_use_pirq is:
>> >
>> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
>> >
>> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
>> > above).
>>
>> This appears to be true. I added logging to hvm_pci_msi_assert in
>> xen/drivers/passthrough/io.c and it indicates that
>> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
>> before an unsupported delivery mode message.
>>
>> I also log pirq->pirq but I found that most of the time I can't find
>> this value anywhere else (I'm not sure how to interpret the value,
>> though). For example, in my last try:
>>
>> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
>> 53. The vast majority are for 54.
>> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
>> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
>> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
>> but complains it's already mapped.
>> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
>> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
>> 22, 52, 48, 47. Also never 54 or 53.
>> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
>> * The qemu log mentions pirq 35, 36 and 37
>>
>> It seems pirq values don't always mean the same? Is it a coincidence
>> that 55 occurs almost everywhere, or is something going wrong with the
>> other two values (53 and 54 versus 16 and 17)?
>>
>> I have three MSI capable devices passed through to the domU, and I do
>> see groups of three distinct pirqs in the data above - just not the
>> same ones in every place I look.
>>
>> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
>> > (__startup_pirq doesn't get called), or Xen is erroring out in
>> > map_domain_emuirq_pirq.
>>
>> evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.
>>
>> map_domain_emuirq_pirq always gets past the checks in the top half
>> (i.e. up to the line /* do not store emuirq mappings for pt devices
>> */), except for one time with pirq=49,emuirq=23 where it finds they
>> are already mapped.
>> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
>> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
>> directly logged that but it's the only assignment there).
>>
>> Interestingly, I get an unsupported delivery mode error for pirq 55
>> where my logging says pirq->arch.hvm.emuirq is -1, *after*
>> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.
>
> Looking back at your QEMU logs, it seems that pt_msi_setup is not
> called (or it is not called at the right time), otherwise you should
> get:
>
> pt_msi_setup requested pirq = %d
>
> in your logs.
> Could you try disabling msitranslate? You can do that adding
>
> pci_msitranslate=0
>
> to your VM config file.

I tried that, but it didn't work.

> If that works, probably this (untested) QEMU patch could fix your problem:
>

I appreciate the help.

I applied the patch anyway just to see what would happen (had to edit
a few dev versus d variable names) but it didn't help. It also breaks
pt_msi_update, as I get in the qemu log:

pt_msi_update: Update msi with pirq 2f gvec 0 gflags 302f
pt_msi_update: Error: Binding of MSI failed.
pt_msi_update: Error: Unmapping of MSI failed.
pt_msgctrl_reg_write: Warning: Can not bind MSI for dev 80

I added some logging to pt_msi_setup (without the patch). It does get
called, and it does so rather early in the boot process, each time
right before lines as these:

pci_intx: intx=1
register_real_device: Real physical device 00:1b.0 registered successfuly!
IRQ type = MSI-INTx

At this point dev->msi->data, addr_hi and addr_lo are all 0, which
doesn't seem right. Is it being called prematurely?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 21:17:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 21:17: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 1Sjd89-0003G2-0K; Tue, 26 Jun 2012 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 <konrad.wilk@oracle.com>) id 1Sjd86-0003Fw-Uj
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 21:16:59 +0000
Received: from [85.158.143.99:48123] by server-1.bemta-4.messagelabs.com id
	8C/AD-24392-AC62AEF4; Tue, 26 Jun 2012 21:16:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340745416!28941643!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwOTQ4OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13017 invoked from network); 26 Jun 2012 21:16:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jun 2012 21:16:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5QLGpqe007768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Jun 2012 21:16:52 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
	q5QLGpP4017338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Jun 2012 21:16:51 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
	q5QLGoQ7013221; Tue, 26 Jun 2012 16:16:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Jun 2012 14:16:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5199540290; Tue, 26 Jun 2012 17:09:06 -0400 (EDT)
Date: Tue, 26 Jun 2012 17:09:06 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120626210906.GA14905@phenom.dumpdata.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120626203151.GA8676@US-SEA-R8XVZTX>
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>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> 
> This may be a problem with the guest, rather than a problem with Xen
> or the toolstack. I tested on a domU running a 3.2.20-based Linux
> kernel. The domU kernel didn't automatically enable the vCPUs after
> calling "xl vcpu-set" to increase the allocation.
> 
> # xl list 2
> Name                                        ID   Mem VCPUs      State Time(s)
> test                                         2 15360     1     -b---- 6617.6
> # xl vcpu-set 2 4
> # xl list 2
> Name                                        ID   Mem VCPUs      State Time(s)
> test                                         2 15360     1     -b---- 6617.7
> 
> But when I hotplugged the CPUs on the domU side with
> 
>   for online in /sys/devices/system/cpu/cpu*/online; do
>       echo 1 > $online
>   done
> 
> Now we see:
> 
> # xl list 2
> Name                                        ID   Mem VCPUs      State Time(s)
> test                                         2 15360     4     -b---- 6617.8
> 
> I've added this as a comment to the bugzilla.

That is a generic bug - its a race in the generic code where
the cpuX directory is created; then udev kicks off and tries to
echo 1 > cpuX/online (but online hasn't been created yet); the cpu-hotplug
code creates 'online' directory.

I've asked Greg KH about it, and here is his take:
https://lkml.org/lkml/2012/4/30/198

But I never got to prep a patch. If somebody gets to do it before me,
I owe them a beer!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 21:17:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 21:17: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 1Sjd89-0003G2-0K; Tue, 26 Jun 2012 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 <konrad.wilk@oracle.com>) id 1Sjd86-0003Fw-Uj
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 21:16:59 +0000
Received: from [85.158.143.99:48123] by server-1.bemta-4.messagelabs.com id
	8C/AD-24392-AC62AEF4; Tue, 26 Jun 2012 21:16:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340745416!28941643!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYwOTQ4OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13017 invoked from network); 26 Jun 2012 21:16:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jun 2012 21:16:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5QLGpqe007768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Jun 2012 21:16:52 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
	q5QLGpP4017338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Jun 2012 21:16:51 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
	q5QLGoQ7013221; Tue, 26 Jun 2012 16:16:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Jun 2012 14:16:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5199540290; Tue, 26 Jun 2012 17:09:06 -0400 (EDT)
Date: Tue, 26 Jun 2012 17:09:06 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120626210906.GA14905@phenom.dumpdata.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120626203151.GA8676@US-SEA-R8XVZTX>
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>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> 
> This may be a problem with the guest, rather than a problem with Xen
> or the toolstack. I tested on a domU running a 3.2.20-based Linux
> kernel. The domU kernel didn't automatically enable the vCPUs after
> calling "xl vcpu-set" to increase the allocation.
> 
> # xl list 2
> Name                                        ID   Mem VCPUs      State Time(s)
> test                                         2 15360     1     -b---- 6617.6
> # xl vcpu-set 2 4
> # xl list 2
> Name                                        ID   Mem VCPUs      State Time(s)
> test                                         2 15360     1     -b---- 6617.7
> 
> But when I hotplugged the CPUs on the domU side with
> 
>   for online in /sys/devices/system/cpu/cpu*/online; do
>       echo 1 > $online
>   done
> 
> Now we see:
> 
> # xl list 2
> Name                                        ID   Mem VCPUs      State Time(s)
> test                                         2 15360     4     -b---- 6617.8
> 
> I've added this as a comment to the bugzilla.

That is a generic bug - its a race in the generic code where
the cpuX directory is created; then udev kicks off and tries to
echo 1 > cpuX/online (but online hasn't been created yet); the cpu-hotplug
code creates 'online' directory.

I've asked Greg KH about it, and here is his take:
https://lkml.org/lkml/2012/4/30/198

But I never got to prep a patch. If somebody gets to do it before me,
I owe them a beer!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 22:28:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 22:28: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 1SjeEW-0004nB-Mh; Tue, 26 Jun 2012 22:27: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 1SjeEV-0004n4-Qf
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 22:27:40 +0000
Received: from [193.109.254.147:58245] by server-5.bemta-14.messagelabs.com id
	16/14-04343-B573AEF4; Tue, 26 Jun 2012 22:27:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340749658!3530283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14316 invoked from network); 26 Jun 2012 22:27:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 22:27:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,480,1336348800"; d="scan'208";a="13233927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 22:27:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 23:27:38 +0100
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 1SjeET-0002MJ-PV;
	Tue, 26 Jun 2012 22:27:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjeET-0007Yy-79;
	Tue, 26 Jun 2012 23:27:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13371-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 23:27:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13371: 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 13371 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13371/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13370

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  c6c9d20963d7
baseline version:
 xen                  e08cf97e76f0

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c6c9d20963d7
+ . 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 c6c9d20963d7
+ branch=xen-unstable
+ revision=c6c9d20963d7
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c6c9d20963d7 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 21 changesets with 41 changes to 19 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 22:28:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 22:28: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 1SjeEW-0004nB-Mh; Tue, 26 Jun 2012 22:27: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 1SjeEV-0004n4-Qf
	for xen-devel@lists.xensource.com; Tue, 26 Jun 2012 22:27:40 +0000
Received: from [193.109.254.147:58245] by server-5.bemta-14.messagelabs.com id
	16/14-04343-B573AEF4; Tue, 26 Jun 2012 22:27:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340749658!3530283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14316 invoked from network); 26 Jun 2012 22:27:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 22:27:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,480,1336348800"; d="scan'208";a="13233927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jun 2012 22:27:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 26 Jun 2012 23:27:38 +0100
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 1SjeET-0002MJ-PV;
	Tue, 26 Jun 2012 22:27:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjeET-0007Yy-79;
	Tue, 26 Jun 2012 23:27:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13371-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Jun 2012 23:27:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13371: 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 13371 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13371/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13370

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  c6c9d20963d7
baseline version:
 xen                  e08cf97e76f0

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c6c9d20963d7
+ . 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 c6c9d20963d7
+ branch=xen-unstable
+ revision=c6c9d20963d7
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c6c9d20963d7 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 21 changesets with 41 changes to 19 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 22:58:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 22: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 1SjehT-0005uv-Mg; Tue, 26 Jun 2012 22:57:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SjehS-0005uq-6O
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 22:57:34 +0000
Received: from [85.158.143.35:12113] by server-1.bemta-4.messagelabs.com id
	C3/B5-24392-D5E3AEF4; Tue, 26 Jun 2012 22:57:33 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340751449!13546908!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU4Nzky\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15092 invoked from network); 26 Jun 2012 22:57:32 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 22:57:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340751452; x=1372287452;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=37/7HMySFMfpdOR4XGsiNyjoJYzzXPendInueb8Q3U0=;
	b=mNBBUQDgZkttcJmJzhXTbGCke2H2yGQDGj1yP9aJWBJLHdsqUtiA6X5P
	5jqio04GYrgwzSqgcIJ62EVne9rzDA==;
X-IronPort-AV: E=Sophos;i="4.77,481,1336348800"; d="scan'208";a="321076408"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2012 22:57:25 +0000
Received: from ex10-hub-36002.ant.amazon.com (ex10-hub-36002.sea32.amazon.com
	[10.250.1.7])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5QMvNhk023428
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 26 Jun 2012 22:57:24 GMT
Received: from US-SEA-R8XVZTX (10.224.80.41) by ex10-hub-36002.ant.amazon.com
	(10.250.1.7) with Microsoft SMTP Server id 14.2.247.3;
	Tue, 26 Jun 2012 15:57:01 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Tue, 26 Jun 2012
	15:57:01 -0700
Date: Tue, 26 Jun 2012 15:57:00 -0700
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120626225700.GB8676@US-SEA-R8XVZTX>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
	<20120626210906.GA14905@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120626210906.GA14905@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> > >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> > >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > 
> > This may be a problem with the guest, rather than a problem with Xen
> > or the toolstack. I tested on a domU running a 3.2.20-based Linux
> > kernel. The domU kernel didn't automatically enable the vCPUs after
> > calling "xl vcpu-set" to increase the allocation.
> > [...]
> > 
> > I've added this as a comment to the bugzilla.
> 
> That is a generic bug - its a race in the generic code where
> the cpuX directory is created; then udev kicks off and tries to
> echo 1 > cpuX/online (but online hasn't been created yet); the cpu-hotplug
> code creates 'online' directory.
> 
> I've asked Greg KH about it, and here is his take:
> https://lkml.org/lkml/2012/4/30/198
> 
> But I never got to prep a patch. If somebody gets to do it before me,
> I owe them a beer!

My problem was that I didn't even have a udev rule to auto-online
hotplugged CPUs. Everything works as expected after adding the rule
suggested on the wiki: http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug

I'm thinking that the bug report is just this well hashed out
problem. For historical reference, here's the thread discussing the
behavior change in pv-ops kernels:
  http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Jun 26 22:58:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Jun 2012 22: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 1SjehT-0005uv-Mg; Tue, 26 Jun 2012 22:57:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SjehS-0005uq-6O
	for xen-devel@lists.xen.org; Tue, 26 Jun 2012 22:57:34 +0000
Received: from [85.158.143.35:12113] by server-1.bemta-4.messagelabs.com id
	C3/B5-24392-D5E3AEF4; Tue, 26 Jun 2012 22:57:33 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340751449!13546908!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDU4Nzky\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15092 invoked from network); 26 Jun 2012 22:57:32 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jun 2012 22:57:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340751452; x=1372287452;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=37/7HMySFMfpdOR4XGsiNyjoJYzzXPendInueb8Q3U0=;
	b=mNBBUQDgZkttcJmJzhXTbGCke2H2yGQDGj1yP9aJWBJLHdsqUtiA6X5P
	5jqio04GYrgwzSqgcIJ62EVne9rzDA==;
X-IronPort-AV: E=Sophos;i="4.77,481,1336348800"; d="scan'208";a="321076408"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2012 22:57:25 +0000
Received: from ex10-hub-36002.ant.amazon.com (ex10-hub-36002.sea32.amazon.com
	[10.250.1.7])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5QMvNhk023428
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 26 Jun 2012 22:57:24 GMT
Received: from US-SEA-R8XVZTX (10.224.80.41) by ex10-hub-36002.ant.amazon.com
	(10.250.1.7) with Microsoft SMTP Server id 14.2.247.3;
	Tue, 26 Jun 2012 15:57:01 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Tue, 26 Jun 2012
	15:57:01 -0700
Date: Tue, 26 Jun 2012 15:57:00 -0700
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120626225700.GB8676@US-SEA-R8XVZTX>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
	<20120626210906.GA14905@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120626210906.GA14905@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> > >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> > >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > 
> > This may be a problem with the guest, rather than a problem with Xen
> > or the toolstack. I tested on a domU running a 3.2.20-based Linux
> > kernel. The domU kernel didn't automatically enable the vCPUs after
> > calling "xl vcpu-set" to increase the allocation.
> > [...]
> > 
> > I've added this as a comment to the bugzilla.
> 
> That is a generic bug - its a race in the generic code where
> the cpuX directory is created; then udev kicks off and tries to
> echo 1 > cpuX/online (but online hasn't been created yet); the cpu-hotplug
> code creates 'online' directory.
> 
> I've asked Greg KH about it, and here is his take:
> https://lkml.org/lkml/2012/4/30/198
> 
> But I never got to prep a patch. If somebody gets to do it before me,
> I owe them a beer!

My problem was that I didn't even have a udev rule to auto-online
hotplugged CPUs. Everything works as expected after adding the rule
suggested on the wiki: http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug

I'm thinking that the bug report is just this well hashed out
problem. For historical reference, here's the thread discussing the
behavior change in pv-ops kernels:
  http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 01:17:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 01: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 1Sjgsk-0004Z9-Gf; Wed, 27 Jun 2012 01:17:22 +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 1Sjgsj-0004Z1-Eq
	for Xen-devel@lists.xensource.com; Wed, 27 Jun 2012 01:17:21 +0000
Received: from [193.109.254.147:44695] by server-9.bemta-14.messagelabs.com id
	E0/5F-07693-02F5AEF4; Wed, 27 Jun 2012 01:17:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340759838!8668487!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjA1ODIx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11585 invoked from network); 27 Jun 2012 01:17:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 01:17:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5R1HAE5002735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 01:17:11 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
	q5R1H9c9003218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 01:17:10 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
	q5R1H9iK023031; Tue, 26 Jun 2012 20:17:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Jun 2012 18:17:09 -0700
Date: Tue, 26 Jun 2012 18:17:07 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120626181707.4203d336@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: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [HYBRID]: status 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 Guys,

Just a quick status update. I refreshed my trees and then debugged as
the code had changed a lot. I'm again few weeks behind from the latest
tree on both linux and xen. After the refresh, I ran into few issues:

   - xenstored is using gnttab interface that will not work for hybrid
     For now I just disabled it.

   - libxl has changed a lot, so for now, I'm only supporting 
          disk = ['phy:/dev/loop1,xvda,w']

   - the struct pv_vcpu and hvm_vcpu are into a union now. I added a new
     type hyb_vcpu and now going thru the code changing all refs.

   - on the linux side I managed to remove all changes to non-xen files,
     this should help a alot. 

Once I finish the changes for hyb_vcpu union, I should be able to get
things working again. Then I'll refresh the linux tree, keeping xen the
same, and test it all out and submit linux patch. After that I'll
refresh xen tree and keeping same linux, test it out, and submit patch. 

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 Jun 27 01:17:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 01: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 1Sjgsk-0004Z9-Gf; Wed, 27 Jun 2012 01:17:22 +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 1Sjgsj-0004Z1-Eq
	for Xen-devel@lists.xensource.com; Wed, 27 Jun 2012 01:17:21 +0000
Received: from [193.109.254.147:44695] by server-9.bemta-14.messagelabs.com id
	E0/5F-07693-02F5AEF4; Wed, 27 Jun 2012 01:17:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340759838!8668487!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjA1ODIx\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11585 invoked from network); 27 Jun 2012 01:17:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 01:17:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5R1HAE5002735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 01:17:11 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
	q5R1H9c9003218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 01:17:10 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
	q5R1H9iK023031; Tue, 26 Jun 2012 20:17:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Jun 2012 18:17:09 -0700
Date: Tue, 26 Jun 2012 18:17:07 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120626181707.4203d336@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: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [HYBRID]: status 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 Guys,

Just a quick status update. I refreshed my trees and then debugged as
the code had changed a lot. I'm again few weeks behind from the latest
tree on both linux and xen. After the refresh, I ran into few issues:

   - xenstored is using gnttab interface that will not work for hybrid
     For now I just disabled it.

   - libxl has changed a lot, so for now, I'm only supporting 
          disk = ['phy:/dev/loop1,xvda,w']

   - the struct pv_vcpu and hvm_vcpu are into a union now. I added a new
     type hyb_vcpu and now going thru the code changing all refs.

   - on the linux side I managed to remove all changes to non-xen files,
     this should help a alot. 

Once I finish the changes for hyb_vcpu union, I should be able to get
things working again. Then I'll refresh the linux tree, keeping xen the
same, and test it all out and submit linux patch. After that I'll
refresh xen tree and keeping same linux, test it out, and submit patch. 

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 Jun 27 01:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 01:26: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 1Sjh1T-0004iL-Hj; Wed, 27 Jun 2012 01:26:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Sjh1S-0004iG-9G
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 01:26:22 +0000
Received: from [193.109.254.147:41634] by server-6.bemta-14.messagelabs.com id
	76/97-08993-D316AEF4; Wed, 27 Jun 2012 01:26:21 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340760378!8705817!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22615 invoked from network); 27 Jun 2012 01:26:19 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 01:26:19 -0000
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com
	[209.85.160.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5R1QGvk018261
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 18:26:16 -0700
Received: by pbbro12 with SMTP id ro12so908415pbb.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 18:26:15 -0700 (PDT)
Received: by 10.68.131.10 with SMTP id oi10mr56981164pbb.122.1340760375454;
	Tue, 26 Jun 2012 18:26:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.204.13 with HTTP; Tue, 26 Jun 2012 18:25:34 -0700 (PDT)
In-Reply-To: <CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 26 Jun 2012 21:25:34 -0400
Message-ID: <CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6530511774059146131=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6530511774059146131==
Content-Type: multipart/alternative; boundary=047d7b15ad07e86bf304c36a1945

--047d7b15ad07e86bf304c36a1945
Content-Type: text/plain; charset=ISO-8859-1

Ian,
 The code segfaults. Here are the system details and error traces from gdb.

My setup:

dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),
           running latest xen-4.2-unstable (built from your repo)
           tools stack also built from your repo (which I hope has all the
latest patches).

domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version)
           with suspend event channel support

As a sanity check, I tested xl remus with latest tip from xen-unstable
mercurial repo, c/s: 25496:e08cf97e76f0

Blackhole replication (to /dev/null) and localhost replication worked as
expected
and the guest recovered properly without any issues.

These are the commands, just in case you wish to try them yourself on any
guest.

 nohup xl remus -b -i 100 domU dummy >logfile 2>&1 &
 nohup xl remus -i 100 -e domU localhost >logfile 2>&1 &

With the your repo, both blackhole replication and localhost replication
segfault.
I havent tested remote replication. [I dont know if the segfault is from
your patches
or someone else's :) ]

The source domain is left in ---ss- state.
With localhost replication, the targetdomain--incoming becomes operational,
but without renaming.

Blackhole replication:
================
xl error:
----------
xc: error: Could not get domain info (3 = No such process): Internal error
libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for
domain 4154075147: No such process
 libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to
open qemu save file ?8b: No such file or directory

I also ran xl in GDB to get a stack trace and hopefully some useful debug
info.
gdb traces: http://pastebin.com/7zFwFjW4


Localhost replication: Partial success, but xl still segfaults
 dmesg shows
 [ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp
00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]

xl error:
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/487)
Loading new save file <incoming migration stream> (new xl fmt info
0x0/0x0/487)
 Savefile contains xl domain config
xc: error: Could not get domain info (3 = No such process): Internal error
libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for
domain 2491594763: No such process
libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to
open qemu save file `??: No such file or directory
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 buffering batch, finishing (0 = Success): Internal
error
migration target: Remus Failover for domain 3
libxl: error: libxl.c:313:libxl__domain_rename: domain with name "drbd-vm"
already exists.
migration target (Remus): Failed to rename domain from drbd-vm--incoming to
drbd-vm:-6

I see calls related to qemu, but I am running a PV guest!

thanks
shriram


On Tue, Jun 26, 2012 at 2:44 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> Shriram, would you care to take a look at this series and perhaps
>> retest it ?
>>
>>
> Sure will do.
>
>
> If you would prefer a git branch to a series of patches, you can find
>> it here:
>>
>> http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
>>  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram
>> NB that branch is REBASING.
>>
>>
> I am not too familiar with the git lingo.. What did you mean by "branch is
> rebasing" ?
> Am I supposed to do something special, apart from the normal process
> below:
> git clone git://xen....
> git checkout -b for-shriram origin/for-shriram
>
> thanks
> shriram
>
>
>> Thanks,
>> Ian.
>>
>>
>

--047d7b15ad07e86bf304c36a1945
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ian,<div>=A0The code segfaults. Here are the system details and error trace=
s from gdb.</div><div>=A0</div><div>My setup:</div><div><br></div><div>dom0=
 : ubuntu 64bit, 2.6.32-39 (pvops kernel),=A0</div><div>=A0 =A0 =A0 =A0 =A0=
 =A0running latest xen-4.2-unstable (built from your repo)</div>


<div>=A0 =A0 =A0 =A0 =A0 =A0tools stack also built from your repo (which I =
hope has all the latest patches).<br><br>domU: ubuntu 32bit PV, xenolinux k=
ernel (2.6.32.2 - novel suse version)=A0</div><div>=A0 =A0 =A0 =A0 =A0 =A0w=
ith suspend event channel support</div>

<div><br></div><div>As a sanity check, I tested xl remus with latest tip fr=
om xen-unstable=A0</div><div>mercurial repo, c/s: 25496:e08cf97e76f0</div><=
div><br></div><div>Blackhole replication (to /dev/null) and localhost repli=
cation worked as expected</div>

<div>and the guest recovered properly without any issues.</div><div><br></d=
iv><div>These are the commands, just in case you wish to try them yourself =
on any guest.</div><div><br></div><div>=A0nohup xl remus -b -i 100 domU dum=
my &gt;logfile 2&gt;&amp;1 &amp;</div>


<div>=A0nohup xl remus -i 100 -e domU localhost &gt;logfile 2&gt;&amp;1 &am=
p;</div><div><br></div><div>With the your repo,=A0both blackhole replicatio=
n and localhost replication segfault.=A0</div><div>I havent tested remote r=
eplication. [I dont know if the segfault is from your patches</div>

<div>or someone=A0else&#39;s :) ]</div>
<div><br></div><div>The source domain is left in ---ss- state.=A0</div><div=
>With localhost replication, the targetdomain--incoming becomes operational=
,</div><div>but without renaming.</div><div><br></div><div>Blackhole replic=
ation:</div>

<div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>xl error:=
=A0</div><div>
<div>----------</div><div>xc: error: Could not get domain info (3 =3D No su=
ch process): Internal error</div><div>libxl: error: libxl.c:388:libxl_domai=
n_resume: xc_domain_resume failed for domain <a href=3D"tel:4154075147" val=
ue=3D"+14154075147" target=3D"_blank">4154075147</a>: No such process</div>

<div>
libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to o=
pen qemu save file ?8b: No such file or directory</div></div><div><br></div=
><div>I also ran xl in GDB to get a stack trace and hopefully some useful d=
ebug info.</div>

<div><div>gdb traces:=A0<a href=3D"http://pastebin.com/7zFwFjW4" target=3D"=
_blank">http://pastebin.com/7zFwFjW4</a></div></div><div><br></div><div><br=
></div><div>Localhost replication: Partial success, but xl still segfaults<=
/div>

<div><div>=A0dmesg shows</div><div>=A0[ 1399.254849] xl[4716]: segfault at =
0 ip 00007f979483a417 sp 00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7=
f9794807000+4d000]</div></div><div><br></div><div>xl error:=A0</div><div><d=
iv>

migration target: Ready to receive domain.</div><div>Saving to migration st=
ream new xl format (info 0x0/0x0/487)</div>
<div>Loading new save file &lt;incoming migration stream&gt; (new xl fmt in=
fo 0x0/0x0/487)</div><div>=A0Savefile contains xl domain config</div><div>x=
c: error: Could not get domain info (3 =3D No such process): Internal error=
</div>


<div>libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed=
 for domain 2491594763: No such process</div><div>libxl: error: libxl_dom.c=
:1184:libxl__domain_save_device_model: unable to open qemu save file `??: N=
o such file or directory</div>


<div>xc: error: 0-length read: Internal error</div><div>xc: error: read_exa=
ct_timed failed (read rc: 0, errno: 0): Internal error</div><div>xc: error:=
 Error when reading batch size (0 =3D Success): Internal error</div><div>


xc: error: error when buffering batch, finishing (0 =3D Success): Internal =
error</div><div>migration target: Remus Failover for domain 3</div><div>lib=
xl: error: libxl.c:313:libxl__domain_rename: domain with name &quot;drbd-vm=
&quot; already exists.</div>


<div>migration target (Remus): Failed to rename domain from drbd-vm--incomi=
ng to drbd-vm:-6</div></div><div><br></div><div>I see calls related to qemu=
, but I am running a PV guest!</div><div><br></div><div>thanks</div><div>

shriram</div><div><br></div><div><br></div><div><div class=3D"gmail_quote">=
On Tue, Jun 26, 2012 at 2:44 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:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">


Shriram, would you care to take a look at this series and perhaps<br>
retest it ?<br>
<br></blockquote><div><br></div></div><div>Sure will do.</div><div><div><br=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you would prefer a git branch to a series of patches, you can find<br>
it here:<br>
 =A0<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.g=
it;a=3Dshortlog;h=3Drefs/heads/for-shriram" target=3D"_blank">http://xenbit=
s.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.git;a=3Dshortlog;h=3Drefs/hea=
ds/for-shriram</a><br>




 =A0git://<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstable.git#shr=
iram" target=3D"_blank">xenbits.xen.org/people/iwj/xen-unstable.git#shriram=
</a><br>
NB that branch is REBASING.<br>
<br></blockquote><div><br></div></div><div>I am not too familiar with the g=
it lingo.. What did you mean by=A0&quot;branch is rebasing&quot; ?</div><di=
v>Am I supposed to do something special, apart from=A0the normal process be=
low:=A0</div>



<div>git clone git://xen....</div><div>git checkout -b for-shriram origin/f=
or-shriram=A0</div><div><br></div><div>thanks</div><div>shriram</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">




Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>
</blockquote></div><br></div>

--047d7b15ad07e86bf304c36a1945--


--===============6530511774059146131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6530511774059146131==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 01:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 01:26: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 1Sjh1T-0004iL-Hj; Wed, 27 Jun 2012 01:26:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Sjh1S-0004iG-9G
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 01:26:22 +0000
Received: from [193.109.254.147:41634] by server-6.bemta-14.messagelabs.com id
	76/97-08993-D316AEF4; Wed, 27 Jun 2012 01:26:21 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340760378!8705817!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22615 invoked from network); 27 Jun 2012 01:26:19 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 01:26:19 -0000
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com
	[209.85.160.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5R1QGvk018261
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 18:26:16 -0700
Received: by pbbro12 with SMTP id ro12so908415pbb.32
	for <xen-devel@lists.xen.org>; Tue, 26 Jun 2012 18:26:15 -0700 (PDT)
Received: by 10.68.131.10 with SMTP id oi10mr56981164pbb.122.1340760375454;
	Tue, 26 Jun 2012 18:26:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.204.13 with HTTP; Tue, 26 Jun 2012 18:25:34 -0700 (PDT)
In-Reply-To: <CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 26 Jun 2012 21:25:34 -0400
Message-ID: <CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6530511774059146131=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6530511774059146131==
Content-Type: multipart/alternative; boundary=047d7b15ad07e86bf304c36a1945

--047d7b15ad07e86bf304c36a1945
Content-Type: text/plain; charset=ISO-8859-1

Ian,
 The code segfaults. Here are the system details and error traces from gdb.

My setup:

dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),
           running latest xen-4.2-unstable (built from your repo)
           tools stack also built from your repo (which I hope has all the
latest patches).

domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version)
           with suspend event channel support

As a sanity check, I tested xl remus with latest tip from xen-unstable
mercurial repo, c/s: 25496:e08cf97e76f0

Blackhole replication (to /dev/null) and localhost replication worked as
expected
and the guest recovered properly without any issues.

These are the commands, just in case you wish to try them yourself on any
guest.

 nohup xl remus -b -i 100 domU dummy >logfile 2>&1 &
 nohup xl remus -i 100 -e domU localhost >logfile 2>&1 &

With the your repo, both blackhole replication and localhost replication
segfault.
I havent tested remote replication. [I dont know if the segfault is from
your patches
or someone else's :) ]

The source domain is left in ---ss- state.
With localhost replication, the targetdomain--incoming becomes operational,
but without renaming.

Blackhole replication:
================
xl error:
----------
xc: error: Could not get domain info (3 = No such process): Internal error
libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for
domain 4154075147: No such process
 libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to
open qemu save file ?8b: No such file or directory

I also ran xl in GDB to get a stack trace and hopefully some useful debug
info.
gdb traces: http://pastebin.com/7zFwFjW4


Localhost replication: Partial success, but xl still segfaults
 dmesg shows
 [ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp
00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]

xl error:
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/487)
Loading new save file <incoming migration stream> (new xl fmt info
0x0/0x0/487)
 Savefile contains xl domain config
xc: error: Could not get domain info (3 = No such process): Internal error
libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for
domain 2491594763: No such process
libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to
open qemu save file `??: No such file or directory
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 buffering batch, finishing (0 = Success): Internal
error
migration target: Remus Failover for domain 3
libxl: error: libxl.c:313:libxl__domain_rename: domain with name "drbd-vm"
already exists.
migration target (Remus): Failed to rename domain from drbd-vm--incoming to
drbd-vm:-6

I see calls related to qemu, but I am running a PV guest!

thanks
shriram


On Tue, Jun 26, 2012 at 2:44 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> Shriram, would you care to take a look at this series and perhaps
>> retest it ?
>>
>>
> Sure will do.
>
>
> If you would prefer a git branch to a series of patches, you can find
>> it here:
>>
>> http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
>>  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram
>> NB that branch is REBASING.
>>
>>
> I am not too familiar with the git lingo.. What did you mean by "branch is
> rebasing" ?
> Am I supposed to do something special, apart from the normal process
> below:
> git clone git://xen....
> git checkout -b for-shriram origin/for-shriram
>
> thanks
> shriram
>
>
>> Thanks,
>> Ian.
>>
>>
>

--047d7b15ad07e86bf304c36a1945
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ian,<div>=A0The code segfaults. Here are the system details and error trace=
s from gdb.</div><div>=A0</div><div>My setup:</div><div><br></div><div>dom0=
 : ubuntu 64bit, 2.6.32-39 (pvops kernel),=A0</div><div>=A0 =A0 =A0 =A0 =A0=
 =A0running latest xen-4.2-unstable (built from your repo)</div>


<div>=A0 =A0 =A0 =A0 =A0 =A0tools stack also built from your repo (which I =
hope has all the latest patches).<br><br>domU: ubuntu 32bit PV, xenolinux k=
ernel (2.6.32.2 - novel suse version)=A0</div><div>=A0 =A0 =A0 =A0 =A0 =A0w=
ith suspend event channel support</div>

<div><br></div><div>As a sanity check, I tested xl remus with latest tip fr=
om xen-unstable=A0</div><div>mercurial repo, c/s: 25496:e08cf97e76f0</div><=
div><br></div><div>Blackhole replication (to /dev/null) and localhost repli=
cation worked as expected</div>

<div>and the guest recovered properly without any issues.</div><div><br></d=
iv><div>These are the commands, just in case you wish to try them yourself =
on any guest.</div><div><br></div><div>=A0nohup xl remus -b -i 100 domU dum=
my &gt;logfile 2&gt;&amp;1 &amp;</div>


<div>=A0nohup xl remus -i 100 -e domU localhost &gt;logfile 2&gt;&amp;1 &am=
p;</div><div><br></div><div>With the your repo,=A0both blackhole replicatio=
n and localhost replication segfault.=A0</div><div>I havent tested remote r=
eplication. [I dont know if the segfault is from your patches</div>

<div>or someone=A0else&#39;s :) ]</div>
<div><br></div><div>The source domain is left in ---ss- state.=A0</div><div=
>With localhost replication, the targetdomain--incoming becomes operational=
,</div><div>but without renaming.</div><div><br></div><div>Blackhole replic=
ation:</div>

<div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>xl error:=
=A0</div><div>
<div>----------</div><div>xc: error: Could not get domain info (3 =3D No su=
ch process): Internal error</div><div>libxl: error: libxl.c:388:libxl_domai=
n_resume: xc_domain_resume failed for domain <a href=3D"tel:4154075147" val=
ue=3D"+14154075147" target=3D"_blank">4154075147</a>: No such process</div>

<div>
libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to o=
pen qemu save file ?8b: No such file or directory</div></div><div><br></div=
><div>I also ran xl in GDB to get a stack trace and hopefully some useful d=
ebug info.</div>

<div><div>gdb traces:=A0<a href=3D"http://pastebin.com/7zFwFjW4" target=3D"=
_blank">http://pastebin.com/7zFwFjW4</a></div></div><div><br></div><div><br=
></div><div>Localhost replication: Partial success, but xl still segfaults<=
/div>

<div><div>=A0dmesg shows</div><div>=A0[ 1399.254849] xl[4716]: segfault at =
0 ip 00007f979483a417 sp 00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7=
f9794807000+4d000]</div></div><div><br></div><div>xl error:=A0</div><div><d=
iv>

migration target: Ready to receive domain.</div><div>Saving to migration st=
ream new xl format (info 0x0/0x0/487)</div>
<div>Loading new save file &lt;incoming migration stream&gt; (new xl fmt in=
fo 0x0/0x0/487)</div><div>=A0Savefile contains xl domain config</div><div>x=
c: error: Could not get domain info (3 =3D No such process): Internal error=
</div>


<div>libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed=
 for domain 2491594763: No such process</div><div>libxl: error: libxl_dom.c=
:1184:libxl__domain_save_device_model: unable to open qemu save file `??: N=
o such file or directory</div>


<div>xc: error: 0-length read: Internal error</div><div>xc: error: read_exa=
ct_timed failed (read rc: 0, errno: 0): Internal error</div><div>xc: error:=
 Error when reading batch size (0 =3D Success): Internal error</div><div>


xc: error: error when buffering batch, finishing (0 =3D Success): Internal =
error</div><div>migration target: Remus Failover for domain 3</div><div>lib=
xl: error: libxl.c:313:libxl__domain_rename: domain with name &quot;drbd-vm=
&quot; already exists.</div>


<div>migration target (Remus): Failed to rename domain from drbd-vm--incomi=
ng to drbd-vm:-6</div></div><div><br></div><div>I see calls related to qemu=
, but I am running a PV guest!</div><div><br></div><div>thanks</div><div>

shriram</div><div><br></div><div><br></div><div><div class=3D"gmail_quote">=
On Tue, Jun 26, 2012 at 2:44 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:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">


Shriram, would you care to take a look at this series and perhaps<br>
retest it ?<br>
<br></blockquote><div><br></div></div><div>Sure will do.</div><div><div><br=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you would prefer a git branch to a series of patches, you can find<br>
it here:<br>
 =A0<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.g=
it;a=3Dshortlog;h=3Drefs/heads/for-shriram" target=3D"_blank">http://xenbit=
s.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.git;a=3Dshortlog;h=3Drefs/hea=
ds/for-shriram</a><br>




 =A0git://<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstable.git#shr=
iram" target=3D"_blank">xenbits.xen.org/people/iwj/xen-unstable.git#shriram=
</a><br>
NB that branch is REBASING.<br>
<br></blockquote><div><br></div></div><div>I am not too familiar with the g=
it lingo.. What did you mean by=A0&quot;branch is rebasing&quot; ?</div><di=
v>Am I supposed to do something special, apart from=A0the normal process be=
low:=A0</div>



<div>git clone git://xen....</div><div>git checkout -b for-shriram origin/f=
or-shriram=A0</div><div><br></div><div>thanks</div><div>shriram</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">




Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>
</blockquote></div><br></div>

--047d7b15ad07e86bf304c36a1945--


--===============6530511774059146131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6530511774059146131==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 01:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 01:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjhKR-00052A-6Z; Wed, 27 Jun 2012 01:45:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SjhKQ-000521-6G
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 01:45:58 +0000
Received: from [85.158.143.35:24691] by server-1.bemta-4.messagelabs.com id
	89/D3-24392-5D56AEF4; Wed, 27 Jun 2012 01:45:57 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340761554!11141785!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU2NDMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12735 invoked from network); 27 Jun 2012 01:45:55 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 01:45:55 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 26 Jun 2012 18:45:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="116365330"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Jun 2012 18:45:52 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 26 Jun 2012 18:45:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Wed, 27 Jun 2012 09:45:50 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
	guest
Thread-Index: Ac1TYUb9qkj/ISJ7SGCLemLA1RFKQgAW/s4iABGm4ZA=
Date: Wed, 27 Jun 2012 01:45:49 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.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: "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] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, June 27, 2012 1:00 AM
> To: Ian Campbell
> Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> Stefano Stabellini
> Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> guest
> 
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > libxl: set stdvga=1 by default when creating a hvm guest
> > >
> > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> Ubuntu, Fedora) support VBE 2.0 or later.
> > > So, select a standard VGA card with VBE as the default emulated
> graphics device.
> >
> > I'm not expert on the graphics side of HVM, but on the face of it
> > switching the default to something more modern seems like a
> reasonable
> > idea, although I'm not sure if we should be doing this for 4.2 at this
> > point.
> >
> > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> 
> I think it is a good thing.
> The only thing to keep in mind is that QEMU upstream is switching to
> 16MB of videoram for stdvga. So at some point in the near future
> upstream QEMU will stop working correctly with xen 4.2, unless we bump
> the videoram to 16MB too.
> 
Yes, we should pay attention to this when using upstream QEMU.

> 
> > > It's also a workaround for the following bug.
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> >
> > Do you understand the root cause of that bug?
> >
I don't understand the root cause.

> > It's hard to see how detaching a VF relates to the VGA emulation in use.
> > Can you explain it? Are you sure you aren't just masking the real issue
> > here?
> 
It's strange that detaching a VF may break the graphics display.
As it only happens when 'stdvga=0', it might not be a normal usage.

> Indeed. We cannot possibly accept the patch on the basis that it looks
> like it is masking an unrelated pci-passthrough bug.
>
I don't want to mask that bug, either. :-)
The following sentence is quoted from xl.cfg man page.
"If your guest supports VBE 2.0 or later (e.g. Windows XP onwards) 
then you should enable this (stdvga option)."
If we set 'stdvga=1', we will not meet the bug (#1812).
I assume many Xen users (including me) are not very familiar with 'stdvga' and 
will leave it as default (it's 0 before my patch). 
If then, users may meet something *strange* like bug #1812.
I don't think it's friendly to end users, so I set the default value of 'stdvga' to '1'.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 01:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 01:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjhKR-00052A-6Z; Wed, 27 Jun 2012 01:45:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SjhKQ-000521-6G
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 01:45:58 +0000
Received: from [85.158.143.35:24691] by server-1.bemta-4.messagelabs.com id
	89/D3-24392-5D56AEF4; Wed, 27 Jun 2012 01:45:57 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340761554!11141785!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU2NDMy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12735 invoked from network); 27 Jun 2012 01:45:55 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 01:45:55 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 26 Jun 2012 18:45:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="116365330"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Jun 2012 18:45:52 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 26 Jun 2012 18:45:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Wed, 27 Jun 2012 09:45:50 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
	guest
Thread-Index: Ac1TYUb9qkj/ISJ7SGCLemLA1RFKQgAW/s4iABGm4ZA=
Date: Wed, 27 Jun 2012 01:45:49 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.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: "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] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, June 27, 2012 1:00 AM
> To: Ian Campbell
> Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> Stefano Stabellini
> Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> guest
> 
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > libxl: set stdvga=1 by default when creating a hvm guest
> > >
> > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> Ubuntu, Fedora) support VBE 2.0 or later.
> > > So, select a standard VGA card with VBE as the default emulated
> graphics device.
> >
> > I'm not expert on the graphics side of HVM, but on the face of it
> > switching the default to something more modern seems like a
> reasonable
> > idea, although I'm not sure if we should be doing this for 4.2 at this
> > point.
> >
> > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> 
> I think it is a good thing.
> The only thing to keep in mind is that QEMU upstream is switching to
> 16MB of videoram for stdvga. So at some point in the near future
> upstream QEMU will stop working correctly with xen 4.2, unless we bump
> the videoram to 16MB too.
> 
Yes, we should pay attention to this when using upstream QEMU.

> 
> > > It's also a workaround for the following bug.
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> >
> > Do you understand the root cause of that bug?
> >
I don't understand the root cause.

> > It's hard to see how detaching a VF relates to the VGA emulation in use.
> > Can you explain it? Are you sure you aren't just masking the real issue
> > here?
> 
It's strange that detaching a VF may break the graphics display.
As it only happens when 'stdvga=0', it might not be a normal usage.

> Indeed. We cannot possibly accept the patch on the basis that it looks
> like it is masking an unrelated pci-passthrough bug.
>
I don't want to mask that bug, either. :-)
The following sentence is quoted from xl.cfg man page.
"If your guest supports VBE 2.0 or later (e.g. Windows XP onwards) 
then you should enable this (stdvga option)."
If we set 'stdvga=1', we will not meet the bug (#1812).
I assume many Xen users (including me) are not very familiar with 'stdvga' and 
will leave it as default (it's 0 before my patch). 
If then, users may meet something *strange* like bug #1812.
I don't think it's friendly to end users, so I set the default value of 'stdvga' to '1'.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 02:11:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 02:11: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 1SjhiJ-0005kt-CB; Wed, 27 Jun 2012 02:10:39 +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 1SjhiH-0005ko-U7
	for Xen-devel@lists.xensource.com; Wed, 27 Jun 2012 02:10:38 +0000
Received: from [85.158.143.99:51859] by server-1.bemta-4.messagelabs.com id
	56/EC-24392-D9B6AEF4; Wed, 27 Jun 2012 02:10:37 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340763035!22903683!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMDc2Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11936 invoked from network); 27 Jun 2012 02:10:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 02:10:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5R2ASr7011107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 02:10:29 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
	q5R2ARPb018497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 02:10:27 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
	q5R2AQuf001406; Tue, 26 Jun 2012 21:10:26 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Jun 2012 19:10:26 -0700
Date: Tue, 26 Jun 2012 19:10:24 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120626191024.24d64006@mantra.us.oracle.com>
In-Reply-To: <20120626181707.4203d336@mantra.us.oracle.com>
References: <20120626181707.4203d336@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: status 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, 26 Jun 2012 18:17:07 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> Hi Guys,
> 
> Just a quick status update. I refreshed my trees and then debugged as
> the code had changed a lot. I'm again few weeks behind from the latest
> tree on both linux and xen. After the refresh, I ran into few issues:
> 
>    - xenstored is using gnttab interface that will not work for hybrid
>      For now I just disabled it.
> 
>    - libxl has changed a lot, so for now, I'm only supporting 
>           disk = ['phy:/dev/loop1,xvda,w']
> 
>    - the struct pv_vcpu and hvm_vcpu are into a union now. I added a
> new type hyb_vcpu and now going thru the code changing all refs.
 
Never mind on this. Adding a new type to union is creating a lot
of changes to vmx files, altho it would have been nice to keep a clean 
hyb_vcpu struct. I guess, I'll add a few hyb fields to hvm_vcpu and that
would keep code change to minimum.

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 Jun 27 02:11:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 02:11: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 1SjhiJ-0005kt-CB; Wed, 27 Jun 2012 02:10:39 +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 1SjhiH-0005ko-U7
	for Xen-devel@lists.xensource.com; Wed, 27 Jun 2012 02:10:38 +0000
Received: from [85.158.143.99:51859] by server-1.bemta-4.messagelabs.com id
	56/EC-24392-D9B6AEF4; Wed, 27 Jun 2012 02:10:37 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340763035!22903683!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMDc2Nw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11936 invoked from network); 27 Jun 2012 02:10:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 02:10:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5R2ASr7011107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 02:10:29 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
	q5R2ARPb018497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 02:10:27 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
	q5R2AQuf001406; Tue, 26 Jun 2012 21:10:26 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Jun 2012 19:10:26 -0700
Date: Tue, 26 Jun 2012 19:10:24 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120626191024.24d64006@mantra.us.oracle.com>
In-Reply-To: <20120626181707.4203d336@mantra.us.oracle.com>
References: <20120626181707.4203d336@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: status 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, 26 Jun 2012 18:17:07 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> Hi Guys,
> 
> Just a quick status update. I refreshed my trees and then debugged as
> the code had changed a lot. I'm again few weeks behind from the latest
> tree on both linux and xen. After the refresh, I ran into few issues:
> 
>    - xenstored is using gnttab interface that will not work for hybrid
>      For now I just disabled it.
> 
>    - libxl has changed a lot, so for now, I'm only supporting 
>           disk = ['phy:/dev/loop1,xvda,w']
> 
>    - the struct pv_vcpu and hvm_vcpu are into a union now. I added a
> new type hyb_vcpu and now going thru the code changing all refs.
 
Never mind on this. Adding a new type to union is creating a lot
of changes to vmx files, altho it would have been nice to keep a clean 
hyb_vcpu struct. I guess, I'll add a few hyb fields to hvm_vcpu and that
would keep code change to minimum.

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 Jun 27 03:52:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 03:52: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 1SjjIY-0006To-SI; Wed, 27 Jun 2012 03:52:10 +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 1SjjIW-0006Tj-FJ
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 03:52:09 +0000
Received: from [85.158.139.83:59293] by server-11.bemta-5.messagelabs.com id
	51/9C-20400-7638AEF4; Wed, 27 Jun 2012 03:52:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340769121!28988428!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMzAwMzg0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14830 invoked from network); 27 Jun 2012 03:52:02 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 03:52:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Jun 2012 20:52:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="pdf'?scan'208";a="116396146"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Jun 2012 20:51:59 -0700
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; Tue, 26 Jun 2012 20:51:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Wed, 27 Jun 2012 11:51:54 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>, "Auld, Will"
	<will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: Ac1UGDBj1l9vq4iTRyWE8p2SJy8j9w==
Date: Wed, 27 Jun 2012 03:51:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233525D395@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_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

This is updated xen vMCE design foils, according to comments from community=
 recently.

This foils focus on vMCE part of Xen MCA, so as Keir said, it's some dense.
Later Will will present a document to elaborate more, including Intel MCA a=
nd surrounding features and Xen implementation.

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_
Content-Type: application/pdf; name="xen vMCE design (v0 2).pdf"
Content-Description: xen vMCE design (v0 2).pdf
Content-Disposition: attachment; filename="xen vMCE design (v0 2).pdf";
	size=256622; creation-date="Wed, 27 Jun 2012 03:21:05 GMT";
	modification-date="Wed, 27 Jun 2012 03:18:50 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDc4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDE0L0tpZHNbIDMgMCBSIDE0
IDAgUiA0MSAwIFIgNTQgMCBSIDU2IDAgUiA1OCAwIFIgNjAgMCBSIDYyIDAgUiA2NSAwIFIgNjcg
MCBSIDY5IDAgUiA3MSAwIFIgNzMgMCBSIDc1IDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv
SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRz
IDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9U
YWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA2NDA+Pg0Kc3RyZWFtDQp4nKWU32/aMBDH3yPlf7hHpyqOzz9jCVVdoauK
WqnbkLqp2gNqKU0FQStj0/77nU0oBAJ72EOc5GLf9/s5nwP5HXS7+W3vug/i7Awu+j34kSYCBBdC
oJTCgZMCjBbwNk6T+xOo6DMXCjXNUc7SaI2Ht8n7KiEsCt1Y9nySJp/SBC5vewBbkrgn2bJ4penQ
c2eApoFR60cuDS2Ax1ma5Nez0WRsoD+HNiW5UerUQgK9qzkLhdiiacRaUnuO0oBCXlDEx0VbsvaQ
rNqXNQb9cVntiGtFasBGYR1ItxXdIUW9r2gLbVeKUmtsKy4K9V5cERGt8MGEi+ob2eKQrMlvRtUE
2OuoM7jLag8XQ1r3EaHgtKXDZ9KJEkgiiheK4tpJGM5CR1lfAPVQfvWFajJZrENXafLAZNbRTIQB
wxBfc5vT3TCXfYfhIE0uhy2u7JaRd21juJRb2g8MjuVwh8jWCbVDTsek4MqsE+KxhEVrDrsqyCbH
UVO+UWEJSu6WWKLhgj4o6mFf17j91O6HP8eqfx1XkGn267Z3Cf3xopxkilVbphr+PflvqP0DAMUO
Adn1xQ4C9aA3gB65UnXSmzIzbHmaWUrfQcMG9FqSy2pBD3PaJ4pq1n0tKwou5mGccBqmdJVZR7Hl
+fqp+klZxlMeuulxHnppdnYAz5AT3TRynA5b6GwDDh39xOhmNdemzjmI1hSjfjslECnYt2X1sqH6
EwGqF5pGQf5ajiLfeRkQCEezccCYhmmc8jyGOJF5NqO3g3D0OzW66eQ4nWzpYCld5FGOG1dn+bCc
0q48RRZk9zRGvGl9Ubhg3d+74eB8tAwb9vSfZJo2jM5Tw9Me2V+R5XLyDQplbmRzdHJlYW0NCmVu
ZG9iag0KNSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTAyNC9I
ZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIv
RENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4NzExPj4NCnN0cmVhbQ0K/9j/4AAQ
SkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDxD/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPx
D/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi
688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/z
M9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/n
z0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/
EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+
Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH
1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+
fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0
f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+
pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQ
fW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4X
H4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAX
R/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/
9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPq
lD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDh
cfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/
Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+e
l/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+
qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoPAopD0oA27uLR7BoYZbK6mkaGORnF
wFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2FzeJNJDC7QwKHmkVciNc4yfasopct2
/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCxqVL3RtPH+j6edQmH/La8Yqn4Iv8A
U1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx10y7H/b0P/iaVU0e8bZG1xYyn7rTM
JIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIsNX0O41bTbQ2F3aKr3diG3IY26SJ3
A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVpXjfaNC0+4c5ljZ7fd3KjBX8skVm1
vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOldZa6BoekwR3XiXUt0joHTT7I75CD
yNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibUlDiw+zRn+O5YJx9OtW2+IR02MweG
tGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS9dX/AF8zRKjHdt+mh1y/DCG2XOqe
J9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR7Gq96j+5Fe2pLamvvZ6UvgLwjdfL
aeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2OqX2mTCSxvZ7Zwesbkfp0NS6VZfDP7
0Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6qF0bxVDDLFN8guCo2k9t47fUVheP/
AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2lJ3XXujiKKKK6jlCiiigAooooAKKK
KACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW1v4PFXlxlLextBHaqrFcKHxk4PzE
9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrSXmi6kpJe3G8hCclHXqCDXHPom7bW
+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq5f6bp2ta/aRX1pERY6LHdM7SMBNx
gK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X3MliLM30r2a7ICkGSFIxtJxyPrWb
oVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjADBUtzg1z+jW8nh/wVq2qX4MTanCLW
zhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOfevPb7ULvUZEa7uZJzEgjj3HhUHAA
HYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfWjJ/yLVt/19Sf+gis6u2PU459Aooo
qiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmmc4VcdF+p9KrWFlPqWoW9lbLumnkE
aD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+RrTppxc5bL8xNMt/Bj+BZJb2WAa75
UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBYEE4OaX4X6bplx4Qu7q8sLe5aOdzu
kiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw9/wk+urppuTb7o2fzAu7p2xXp/h7
WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+RHC7RgnJClQcfhVSxbcZRs4ySuTHC
pSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/EfVNMvL6Xw/DpedYmeJVuti9yMDPWr
t1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VOcrSSivw8jxgEEcV6tp3h/SJPhFJq
b6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L95WA4z71c0r/AJIdL/16Sf8AoRrO
tiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1r1bQpT4q+Ec8F388sUMkW48klBlT
/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb30IwcnKUr7W1PER0FLSDpzS16BwBR
RRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SXUaMPlHUEg0aTqGr6HIX03WLW3z95
Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMxs64DV4k8fNXhyppHuQwEHafM02e/
J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/mWNeBx2F1LaG6SB2gEgj3gcFiM4Hv
iq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/Ddiqn2Fs/8fWn/wDgdF/8VXleKOK2
WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1JrKqn4Z/5ExP+v5//AEAVcr1cLUdS
kpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E9mtz4zEzjP2aBpF+p4/qa5nxFcvd
+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3RpNG8XXqMuIrhzPC3YqxyfyOa5Iu2
Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+gCvO9J8ZajpWg3miqkc1ncoy7X4M
ZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZXOiGJpqUG+isaHwk/wCR3P8A17Sf
zFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOPT6VLf+K9QvPFP/CQRBLW8BUqI+VG
Bjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2aywMZih2Y6deldv431y80SO2ubfQY
9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOehqfQvinrOj2SWk8MV9FGNqNISrgdh
kdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8JrbWE4aHzdxUAsMZxj9a0tJIPwOlw
c4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXifV7XR7nQLVftFtdgoIdhZlJ6lcVX1
WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU+i8fjT/id4xh1ORdD02QPaQNmeRf
uu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVfa1XtsjGVeMaXs6a33YUUUV1nIFFF
FABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVrxappEkVvc3t/ZvrDQmOO5WFmRfkA
VpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8AhBPEf/Pin/gRH/8AFV8xUhLnenU+
npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4BfccehqG21TwubWF74W0l/5ZkkkEBwJIid
ijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8VWfJLsXzx7o3n1vQ7bRP3E8Mt8sD
i3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gDKflAwWyepqr/AMIJ4i/58U/8CY//
AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6AKuUabpd3o/heK1vkWOdrt3CCRWO
3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBNZ3c1hewXdu22aBw
6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3Y3EkE6dHQ4/A+ormxGH9raUXaS2Z
0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOUmikiYdVkUqf1r0/RfjHNEqxa1Yeb
jgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09KkL+aOj6vh6mtOdvJngG4eoo3D1FfQ
4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoYJrhtsMMkh9EQt/Kt3T/AviXUyPJ0
qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWVnd3TdiwEY/Wl9bxE/gp/f/SD6rQh
8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0pzI34nk/QV5fqvxY8QXytHZrBYRn
vGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo/wAKN33Yy4YPczOpyrOzA+xNR0UV
6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJgelGB6UtFACYHpRgelLRQAmAKWii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6ClooAKKKKACiiigAooooAKKKKACi
iigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1
YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDcy
OT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
cwBjAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8Aq2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/o
KVz1fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir
9lHz+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRu
AiKST+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf
+b/4qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v
/wCTGnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD
0SZdhP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1x
NpV633IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTN
ZSn70kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2
ELj/ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP
3QW4A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHL
fxE9OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvb
ue4cnJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+
ZcqddtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy
/P8AQ4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQ
HFzaTAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6T
SatcqMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8
ia77wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaar
eW6/dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0
NjE1ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvB
Py/I5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+Rrp
tW8eDWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr
/o/COQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1
haNbyWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuP
Dlr43k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8A
ErQb6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzC
ZG05llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5
PqeufWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4
HtvCVlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/I
x6Z/19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3
h8KMJ/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVn
TScWn3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2Y
Pn8Ov6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7W
hW1qqz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41W
OPl0a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j
/px+taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+
EYVvNVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVy
x/M1FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxIN
d/5GHUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzu
H0rnv+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O
/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9
/wCH/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/
9A/xF/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvM
aKPrlf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNe
Q1r+FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0k
PhR87P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54
c8I+GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+w
zXovhXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNh
bacTMzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeG
rLWhZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dv
rGCaWOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u
5ma9R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+
Ho8adbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1Zt
LXRblr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rm
nR6Xdardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/
AK/4P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0X
Xv8AkYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm
7+HOhC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy9
52/lSRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRn
g05Z5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7e
lKZ5TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHp
mmxSyQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5
HHRP+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19
S/8AoZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f
/wDf9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmf
ib/oO3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//
AH/aiij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCE
z8Tf9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDIwMC9IZWlnaHQgOTgvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNTQ5ND4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBASwBLAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
YgDIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8A4yiiivrT5IKKKKBhRRRQAUUmaWgAooooAKKKKACijNFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRWt4a/5GC1/4H/6AaP+El1f/n7/APIaf4Vw1MRX9u6NGCdkm25NbuS6Rl/KdlOhR9iqtWbV
21pFPZJ9ZLuZNXLDSrvUi/2aPcE+8ScCrX/CS6v/AM/f/kNP8Ks2niy/gLfaNtwCOMgJj8hWGJq5
mqTdGnDm/wATf4OMfzRtQp5e6iVWpLl/wpf+3S/Iw5YngleKRSrodrKexrovDcVrZ6JrXiG5tYrt
7BYo7eCYbo2kkbAZh3A64NYF3cveXUlxJjfI2TjoK6Pw3C2reFPEmh2w3X8whubeLPMojbLKB3OO
cV11XP2Cc9Hpe34nNSUPbNQ1Wtv0LOgau/jWa70bVrKy82S2kltLmC3WJ4pEG4DKgZU4OQaz7fwi
xsbG4vNb0mye+iWW3inlYMynoThcDmrvgzTr3Q72713VLOezsrG0m3PcRmPe7KVVFyOWJNQ+J9G1
LVNL8I/YtPurkHSIk3RRMy7sngkDA6j865udwqcsHZHTyKdPmmrsq2/g/U31K/s7trexXT8G7uLm
TbHGD93nvkdMdaLjwleLLp/2O6s7+2v5/s8NzbyZQSf3WyAVPfp0rutYkiurXxFpsemprN3ZrZef
ZrK4LbUwxBQhm2nqBWJod1fw3Gh2K+E20bTZdZhl8x2lO6XBHHmEnoD09KSxdRq/9bfeN4Smnb+t
/uMk+CJpHuLaz1rSbzULdWaSzhmYudvULlQCR6fWs/wiumz+K9Nj1Up9heXEm84UnB2g+27FbHgx
f+L1hu/2y8/9AlrjtLsLnVJktLSB57hwSkaDJOAScD6Amt4TnJShJ9N/W5hOEIuMorr+VjqfEGve
IbC4utK1jRtMhV1ZI0+woAqkEBomGOnY5PQVXs/CU0mnWt5farpmmLdjNsl5MVaQdA2ADhfc1t+G
4dbubC+0XxJZXJ0OC1kl868hZTZsq5Uo7DI5GNv9M1n+LtJ1DXf+Ee1DTLK4vLSXSoIUe3jZwjrk
MhwOCDWMajg+RWXmbSpqa53d+Rn3HhXUbO31qW68uJtJMPnITkuJWwpUjgjvUWn+HrvU9LjvreSL
El9HYpGxIJkfoemMc13esxyX+meKdFtAbjUrfTNMjkhi+di0blpMY64BFZvhmxvbDwvpa3lpcWzP
4ns2UTRshYcDIz1HWmsXPkb63X5ITwkOdLpZ/mY7+CZzff2ba6tpt3qYkMclrBIxMeM7ixKgALjm
ql14aMbwxWGr6Zqc8sywCC0mJfefQEDK+44rZ0IBvip4otgwWe7OoQQZOMyMzYGe3Q1neCtKvtE8
Y6VeapYXNpbpdeU0s8LIodlIAyRjrTVepq29lf1E6FPRJdbeg6fwVcILiK21XS7y/tkLzWUE5Mqh
fvYyAGI7gGuYDBhxXeWj6joniea4sPh4yX1u8n7/AM24ZMEEFssxQggnnpzXn8AITmtsNVnNvm/r
7jHEUoQS5SWiiius5QooooAKKKKANbw1/wAjBa/8D/8AQDWTWt4a/wCRgtf+B/8AoBrJrhp/79U/
wQ/Oodk/9zp/4p/lAKdHFJNII4o3kc9FRck/gKbWjoWu3PhvV4tTtYYpZYlYBJM7TkEdj712TbUW
0tTlgk5JPYr/ANnX3/Plc/8Aflv8Ka1hqEJE6W11E0fzCQRspX3zjivavhz471Lxjd6jFfWdtbi2
RGQw7vm3E9ck+lcXrfxb12e71XRk0uyMZkmtFYBy5GSmevWvPWLqym4OH4noPCU4xU1P8DhL2/1T
U0Vb/Ury7RfuiedpAPpkmtrWPFd5NY6NZ6RqGoWiWlglvcJHM0au4Jzwp5GD3rUsfhZ4pubNZnt4
ICy5Ec0uH/IA4P1rm9V0e+0K+NnqVq1vOBuAYghh6gjgitkqFRpRa0MG69NNyT1KFu1zaXAube5m
huASfNjkKvk+45q7DJrusapb+XeaheagpzAfOd5AQM5U5yMYzx6V0GjfDvxFrdkl5Bbxw28g3Rvc
Ps3j1AwTj3xWr4U8Oap4Z+J+iW+pwqhmE7RsjhlcCJ89Pw60VKlFKXK02kx06dZtcyaTZxE0WqaN
qrGZruz1FDuLlmSUFhyc9eQTz71UiDwkNG7I6nKspwQfY16r4z8AeIfEPje9v7OGFbNkjVJJZQu4
hADgDJ6+orgvEHhzVPDN0kGpwCPzBmORW3I4HXB/p1p0K9Oolqr9ia9GpTb3t3M+71PWNQgFvear
fXEA6RzXDuo/AnFNs73U9NieKw1K8tY3++kE7IG+oB5rsbb4WeKbhAz20FvntLOM/wDjuazNf8Ea
74bt/tN9bK1tkKZoX3qpPr3H4imp4dvlTQOGIS5mmc3bvdWdz9qtrqeC5Bz5sUhV/fkc1NPf6rdz
xz3WqXs0sTh45JLhmZGHQgk8EetaeheGdW8STOmmWpkWP/WSMwVE+pPf2rU1j4deI9Fs3u5raOeC
MbpGt5NxQepHBx9KcnQUuVtXJiq7jzJOxgW+jaxqME+qQWt5crG7PNdKGbDj5mJb15yT71Xu7/U9
SRUvtRvLpE+6s87OF+mTxXq3w7fPwp8RsD0kucf9+Erzfwz4b1fxLuTTbUyCPHmSMwVE+pPf261l
CrCU5KaSUeprOlNQi43bkVJNU1ia1FpLq19JagY8l7hymP8Adziq6rtGK6zWPh14j0Wze7mto54I
xudreTcUHqRwcfSsHStLvtbvUs9OtnuJ2Gdq9h6k9APc10U50uVyg1YwqRq3UZp3KdFdyfhN4oEe
8LZk/wBwT8/yx+tUrL4c+Ib2/u7Ex20FzaqjOksw5V87WBXII+U0vrNH+ZB9Wrfys5OinvDJHdPb
Mh85JDGyd9wOMfnW54k8H6n4Vht5dRe2xcMVjWKQsTgZPYeo/OtHUgmk3uQqc2m0tjAoooqyDW8N
f8jBa/8AA/8A0A1k1reGv+Rgtf8Agf8A6Aaya4af+/VP8EPzqHZP/c6f+Kf5QCiiiu44z1D4KD/i
Y6z/ANcov5tWH4GtIbv4wXQlUMIru5lUEfxBmx+ROfwrc+Cp/wCJlrP/AFyi/m1choWvReG/ibda
lcAm2F9cRzEDJCMzDI+nB/CvJqJutVS7foetTaVGm33/AFPQ/F3h74h6t4me60fWI7PTotot4o7p
o84AyXUDDEnPXPGKl+I+mte+H/DcmprH9vF9bwTtH93MgxIAfTIH5VR8SfDkeMdXfxBoXiJBBdhS
6BiybgoGVKnuAMj1zXE+KfC8fgibTZ/7dXUtQS5ErW4OPL2YIJG4nr3IFctJXceV6ryOmq7KV1o/
M6r40a1qdje6TpmnXk1nbtE0j/Z3MZY5AAOOwx096534e6jqmo/EXQRqN/cXfkCcRmeQuVBifIye
e1d54l8OWHxPstO1fRtUijlhQqQw3fK2DtYA5VgQfzrB0XwxD4T+KHh20GqR3lxKs7Sqi7fKxE2M
jJPOfbpWtKVL2Di/iszKrGr7ZSXw3RjfFPXNci8e3Vla6ve29rDHEY4oZ2RQSgJOARk5J5roviRL
JefCDQL+5bzLpvs0jSHqWaE7j+Jrkvilz8SNR/65Q/8AosV1XxBOfgj4fxz8tn/6JNHKowpSW4KT
lOpFlr423+oWVpoq2F9c2olklEnkTMm/AXGcHml8FXd3rHwg16PVbiS7MIuIkeZizbRErDk8nBJx
+HpUHxyIMGg45/eTfySnfDw4+E/iT/fuf/RCVmor6spdbmjk/rLj0sLDqE/hn4Cw3+lt5V3OinzR
1DSSYLfUDgfQVT+DviLWr/Wr3TNT1C4vYGtTOpuZDIyMGVcAnJwQ/T2qXwVd6X41+Gv/AAh95dpa
38K7EB+8wDbkdRxuxwCB+ma1fDnhnT/hjBea1rerQtI0RiQKu35cgkKCcsxIHA9KHycs1P4m9AXN
zQcPhS1HeHLWKx8H+PLSAbYYdQvkjUfwr5K4H4Cs63vp/C/wDgvdKbyruZFPmjqGkkwW+oHA+gqX
wRqLat8O/GepSLsa7vL2fb/dDQqQPw6VU8FXel+Nfhr/AMIfeXaWt/CuxAfvMA25HUcbscAgfpmo
s9XLurl3WnL2diL4O+I9a1DWr3TNTv7i9ga1M6m5kMjIwZVwCecEP09q2/Atnb6LJ41uraJc2t7L
HEpHREBYL9Pm/Sk8OeGdP+GMF5rWt6tCztEYk2jb8uQSFBOWYkDgelYPw18X2V5q3iGz1aRLZdYu
HuId7BRl8hkz64K4+hq6lpOTpfDoRTvFRVX4tTl/BGva9qHjzSpbzWL6UT3I8xGuG2sDnjbnGPbp
XpVxq50/47xWjviG+0xYeem8FmU/+Okf8CrO8PfCa+0PxNaX41K2ls7abzEG1g7L2BHQH8a574pX
smm/FOy1CHPmW0EEq4OMlXY4qpKnVqKNPsTF1KdNyqdyxc+Hifjr9i2ZhluVvvYrje2f+BAiqnxh
1U33jaHTkbMen24DD0d/mP8A47sr12HT9Ovddt/F0M8bp/Z5gVxyChYPuz7fMPxr5wv9RbWtf1DV
X/5erh5FHopPA/AYH4VphW6tWN/sozxSVKnK32mMooor2TxzW8Nf8jBa/wDA/wD0A1k1reGv+Rgt
f+B/+gGj/hGtX/59P/Iif415UsVQoY6ftpqN4QtdpdZ9z0o4atWwcPZQcrSlsm+kOxk0Vrf8I1q/
/Pp/5ET/ABo/4RrV/wDn0/8AIif41v8A2pgf+f0P/Al/mY/2djP+fUv/AAF/5GJNCso5ojhVE29q
2/8AhGtX/wCfT/yIn+NH/CNav/z6f+RE/wAaX9pYC9/bQ/8AAl/mP6hjbW9lL/wF/wCRg/ZijExS
PHnrtYjNJFaJF0rf/wCEa1f/AJ9P/Iif40f8I1q//Pp/5ET/ABqf7Qy+9/bQ/wDAl/mV9Sx1reyl
/wCAv/IwjbkOXjdkYjGVODTFs1AOeSeuTXRR+GNVeRVa3CKTgsZFIHvwabrGhS6SsbmUSxvxkDGD
9KUcwwE6ypQqRcpbWd/xWgSwWNhSdScGorurfnqYcVuI+FHJ7VqzeCtdS1N7Jo16INu4sYTwPUjr
itf4fQxTeNbIyoHWFZJwrDgsqEr+RwfwrnDrGr3d5LeyajdefKSXcTMCc9RwenPSumbfPyRWxjBL
k55PcqR2yK+4UslushBNdRY6Zo2neGodb11ryVbmZoba2tSqltv3mZmB47YFM1fRbKFtFvNNnnbT
NXz5PngeZGyuEdTjg4JHNCq078gnSqW5jmmtUZcelMa03uHldnYDALNk16E2jeEF8WN4WJ1lbsy+
Qt2ZIynmHp8uPu5/Gk+H6abb+Lp9PvrWWW+h89FkVx5YCqQQVI68HBzWcq1NxcuXY0jRqKSjfc4B
7VGxxStaoygeneum0bTtH1/V7uWA3djo1laNdXBkZZJdq9QpAAySeKkksdB1jRNRv9BN/bz6cFkm
gu2VhJGTjcpUDBHcGr9tTvZoj2VS10zkmtN8geV2dgMAsc8V0PhpPC/2meHxOJ1tnQCKWHd8jZ77
eensa0EsfDul+FtH1bVY9SuZtTM+2O2lREQRvt5yCSTkfrXLv5cruUVhGWO0NyQO1CUKkXGGnmDc
6bUp6+R6Zpdt8L/DuowavD4ku7h7U+ZDBJIXVTjjCqgOfqayjq3hLxz4t1bUPEF9c6bbhIotPwdp
ZBu3FjtYA5wce/euD+yx5zinGFCMY4rGOCafNzO5vLGprl5dD0nVPEvhPwn4Kv8AQvCl7Je3eobg
8p5KhgFLM2APu8ADvXmlvH5cQFKtvGhyBUtb4fD+yu27tnPXxHtbJKyQUUUV0nOFFFFAgooooGFF
FFABRRRQA+KV4JVliYq6HKkdjVm+1S71EobmXcEHygDA/SqdFZyoUpVFVlFOS2dtUaRrVIwdNSfK
910Zr+FtYh0HxNZ6hcqzWylo5gvXYylSfwzn8KsTeFbG3WaeHxToslkAWiPnnzmHYGMDIb9K58jI
qPyFzmonSlz88XYqFSPJySVzutD1y5ufBttpel+I7fRdRs7iRmFzL5STxtzneQRkHtWRrVzevrGk
rqXia31h4ZQxaFy8cALLn5yADnHb0rnWiVhyKFhVRWawtpuRq8TeKiddNe2Z+Mn9oC6gNp/aSv8A
aBIDHtyOd2cY96b4Z1KxtfibdXdxdRRWss10qzs3yDeHCkn0ORz71ygjUCjy1xij6srWv0sL6y73
t1udX4SuY/Cut39jcatawNe2LQx39rKJo4JDgqxK8Y459Min6zc66mjXKaj46sL6ORdq2lrcmczc
jg4XCjvz6VyAhUDGKQQKDkCk8LeXM2NYm0eVHQa3dW0/gbwhax3EUk9v9s86JXBaPdKCu4dRkcjN
YYGBTRGM5p9dFKnyKxhVqc7uFFFFaGYUUUUAFFFFABRRRQIKKKKBhRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2Jq
DQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FCQ0RFRStW
ZXJkYW5hLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDEwIDAg
Ui9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1dpZHRocyA5MzQgMCBSPj4NCmVuZG9iag0KMTAg
MCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK1ZlcmRhbmEsQm9s
ZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWln
aHQgNzY1L0F2Z1dpZHRoIDU2OC9NYXhXaWR0aCAyMjU3L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQg
MjUwL1N0ZW1WIDU2L0ZvbnRCQm94WyAtNTUwIC0yMDcgMTcwNyA3NjVdIC9Gb250RmlsZTIgOTM1
IDAgUj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvQ0Eg
MT4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1l
L0YyL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250
RGVzY3JpcHRvciAxMyAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgOTM5IDAg
Uj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FC
Q0RFRStWZXJkYW5hL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDEwMDUvRGVzY2VudCAt
MjA3L0NhcEhlaWdodCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDIwMDYvRm9udFdlaWdodCA0
MDAvWEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC01NjAgLTIwNyAxNDQ3IDc2NV0gL0Zv
bnRGaWxlMiA5MzcgMCBSPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTE2IDE2IDAgUi9J
bWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSL0ltYWdlMTcgMTcgMCBSL0ltYWdlMjggMjggMCBSPj4v
Rm9udDw8L0YyIDEyIDAgUi9GMSA5IDAgUi9GMyAzOSAwIFI+Pi9QYXR0ZXJuPDwvUDIwIDIwIDAg
Ui9QMzEgMzEgMCBSPj4vRXh0R1N0YXRlPDwvR1MyNyAyNyAwIFIvR1MzOCAzOCAwIFI+Pi9Qcm9j
U2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAg
NTQwXSAvQ29udGVudHMgMTUgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9D
Uy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4NCmVuZG9iag0KMTUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjY2NT4+DQpzdHJlYW0NCnicpVrbTxw3F39H
4n+w1JfZSgy+X6SqUksoTfUh0YQmldI+oO1yiRZIgfC1/31/x56Zndm1PTR9YMFnfa4+Vxt2eMa+
+ebw9Oj1K8a//ZZ9/+qI/bm/xxlvOedCSu6Yk5wZzdnDan/v/dfsDl+3XAmNPcpZfFoT2MPVgMW5
FVxP0C6/3t/7eX+PHZ8eMTZiKXZYZpATTydC6wzDNmZU/2crDRDY8nZ/7/D17cXVyrBX9yzHSW44
HXSMuAiu09MrITI8De9Z6tAKaZgSrQckRKQRW2FLfNUuX2NEqPPVDoolVQ2zkbMmVccsXYmj3uVo
vbaJo9Ra5KwruBqsy6OOlgcSwkXuG7a+xNZkDCytrjuSxaFqHdkKxVtjmTat10xYoPmxgYvq2o6v
IPn/H31TO0FeqRU+hRXszcn+3p4UnvQRTrVWMSV96z1xU0Ajgd5maLuO9vfnkOMHyYRk55cwVhKY
KS+JqRSqhXznt+XA2AWTTB8atvidnf+0v3d8nuHuR9y3WIrgW5dYzhAJFSJeQ6CXEBG8QsWGNryM
ipiYUzChcVZTi2rZSsskhy/IjuaP948L2zwtVMNOjxYHsjkeMRkLpIVtpZgi1wWSW+crXRvsRCC4
bSsD095u7P3r6g6SHLPFgW2+e1joZnmNj5un1fLp88OqIJwRcFA/JVQXbpQ5Ds8unp5WD3ds+Ygt
iKLHJYLn8OStdOzqEfnCM9C2cE+jx/lWksfHmLCGQsIFiU/vZQqJHbRcDAi9HQQ7p2bgjQFBi2+k
LsUBcaRkgFR5vsSpvi8YykrVajMmBjBh1K2VSz9czaQfLSTlnMgYqQDW0ZbykZIaaW+UfmQx7Qm7
bR6z7UPGtCCsBXl2Ovg/7smPb+HSvGAFQU7sp1h1A7iSuygxuIvyyV0cqhnlQJvSgKA0IIiVGXtP
yWtmsLNO5DNW8ltehNgXUFmZ1tScKJlPRfP9Uoo2jxItRrTmrNenyUICl4rqLzJ9YLfDSilPFlgT
wGYBtB+rawLItMPRjkjDRIBWA4of7UhYl7lGZtymbWpeNtwE+8jYB8Ui799hGfYH27MmtTJBd6Jo
tFPwjA6wjieYbaHEYKRtxyAboW2LJVXESqxgI2LS2pFT8ZkaPUMi51lSZoqKnXqWQD/l0VrAtFp+
UZ3+hUrQ6oEtBG8ekew/XSxXbCGpLOnmvvtZPy5Mw35rfjj97vB2SRG+WrhmfQ/o1cI3vy0KzqqC
bdHnjcSb8Vap6t6qA7o2aqKit9KKGh8pqPFZE8AMANkDuv3J73RQCYB62NGgLhRJRqf9IX3tKcgq
rtqXDjpqZelTouBEEQVV2+R++HMTBlrwrZUcwkGjJZTQNCKhNjue9ugIrcjRFweD/p0YpzDuVpuo
NTJkAZswNkqlHX0YG3StE/mNdKMdFZnsTMYxjik3ZAusNLd9qsCe6arb2eUaciZuBtQhoGgzTqH7
riKbqwa6BGtEaadziEGt9CjICw14GS0b2H62W5RoFSCTsqAYviiuKUxVs1rfX7FCcEqB84ScliIh
xebN3VPMBpcXqEDLUsMnvaM+ZoJZj+rw0klGxvFXuDigCR73y9iMl4ypcg08lSAUcuFNNGyt4naN
N0Mae0up7hKaU0d+8/BnKamhPVAT4jPqq011yautTfQfUhsNRzd6yWpxUDKjtkYB5CZJVvSaHbVf
v31T6jWQRowa05vTdCZ9KzQPSMwiCDoeSnbQnHqsBFiPALwDDCg94JpgLsLghzaSUUr0m2yHlXYE
1QEK+UDpaj7AUceoJlIYhamV0LHFeGnZrxLInqvJzaOo8hgu/kM2OHvHTj7Dq1ePVNZR7F1TSgvK
2pT3R9Fdn04VimbU86X5QNli9VTek5UkNMYvujmBN4xigYzeZ5EpdrL3DHrW5C4XSuhqcZQS7shV
Z/IQeQUuR/LuQpPBnzFGl4Z5p1vrxqTnzOXrUWV0LMzCx/7BONuv1qNVbG+Gnbqv+s4kgI+oXqRV
qvf9d7IWQGEmtxmfhikXg8DExUzjq/l2fZRbQ3lMwBLlARPgl4TDmxXK3CPFA6LhiQplKRoMZSZH
1mx979uE+Pdjj0kkbksTPzSVYYpdPWottqbJsDNyo7FQgm8i7XpxYJrnW7q3gVJFPZBGUa0k3WcM
1X5xIHRzR/gfFwe6IaMsnwhqGmrt70q0UKfg7hNada1yxUqh4SRdOFT0HZVPZNBnBouSNrqcoxDY
2kICt8H9Um0UPFPLKa26NirXcXAUHCgTm+hE5Pn1QqjmDan0c6mTQpZRcopW593Xq839Vz7sXLrq
7u6EBY6LfooRZ7YatD2kjaEPSw2t9NULZW1nm1qPQDRDUa62J8voCZ9RqAQOT8WujH7WN3elrlTY
eI4j6nO2dDOpK9qArsBfbIOdxn6auJBeAw1d6HKtrxvg0wVV3CuM4uS9+PPykubwG3xULIDj02Py
cxbIXaE7qpagQu8UfXTHfLm8p7B6pnz3wKJ4yyeKtpv7UmgJoiWmpKoCGV5uDNIc2A243Wozz+JY
soDNgKtcSDv6yRMmT4OaGlDUaEe55pk+SRueWvVuYE6r0cDMeRYwGvuDT4BUubt5Jw3/huv+u4oo
cmbWTtW3v93rVtRSx65YepMHbG73fEwBNFClVptoEECLAUWNdlREVXOlTdPFOCVRQ81bpa5/aL46
OSt1V9BFjGnMuZzODlLQCUTsJi2/O00tsGn+oppCQ2JBgBAvuybIdQnMTB6SOh5PZ3Kair2r3S+Y
+VQsfSqgyBh25kr69O2bWoMkTaASJrVufX8hTfPzar2idHG7ImQCPPxdLOamDVMCdXu5GZ+nHOh5
769Yja6ind1adTs7b0eykV4MqDFWez93sv+u4uS+mMC0kXRuXSj2K91fX2nDqUHeBQyhqE3sx6Xu
VdMm5Ys07BCK9nHe0XxGyrk3ge5BOd2mgpNAuqULigRYjwCuAwwoPeCaNvm0SQ1kZALYgUy3I2yw
cgJbPpc7YGWEDaJOUgms5A5Gb2g6PdQdlXwaEvMJsZc81Nn6I4JGC6H85DbAVa4TcsE4SyOXDWzu
GWHrfQqlBm72H+4Xfnx3Gnu1k890w2AqY0h06n9xuWBIKP0vLhes2upli8ZUcYdPtwPx7o1ul8uG
zFYKBKXBfMg96TXzQKxM9KKjs9LjnvauNWJM7UWOZ7aiY/eh1lIXi3RvWt0b8deFEs2q1LqhBG0j
1GXoa87o7W73fib/bKdMTCZgFtuyboVUy+kxQNBrsQzx2Tpau18sqUcKaXaLAGMU3RF2mP0KVGln
t0KGDOTwCQ+VB0m4o5oWS3qMSTwToJcnYY5kXcZ0VXhRtLlLJeoQDV1LWSLce//xVyXXRwVAmZ9s
rx/CdP5QmVDXcAT4q0T+Tg62W6h2j+1D836VegDBm4uHVfx9vSr+Rwi9oiFYN0zm5A6H/7u4u2LN
x4uDn84WW/nK76Yr1XoFuHZ9yFmM7lf9H1FiSd0Hpw9BH3F5aA8lTSyuJozLPSgY+k8HOWI5o5ET
JY02t4DwUgeKaviPHlmlmL3wxwgTLaHK/xb0D2jXEfsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNiAw
IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0Nv
bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0lu
dGVycG9sYXRlIHRydWUvTGVuZ3RoIDcyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA
/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0
NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEB
AAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci
cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpj
ZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI
ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgME
BQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkj
M1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ
2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooA//2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjE3IDAgb2JqDQo8
PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNzIxL0hlaWdodCAzNjMvQ29sb3JT
cGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJw
b2xhdGUgdHJ1ZS9TTWFzayAxOCAwIFIvTGVuZ3RoIDI5NDEyPj4NCnN0cmVhbQ0K/9j/4AAQSkZJ
RgABAQEAeAB4AAD/4QBaRXhpZgAATU0AKgAAAAgABQMBAAUAAAABAAAASgMDAAEAAAABAAAAAFEQ
AAEAAAABAQAAAFERAAQAAAABAAASdFESAAQAAAABAAASdAAAAAAAAYagAACxj//bAEMACAYGBwYF
CAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0
Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMv/AABEIAWsGuQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID
BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB
FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna
4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1
EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0
4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI
iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery
8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+ur+H2gWXiPxFJZ36sYFt2kwrEHO5R2/3q5Su/wDhB/yN
8/8A15t/6MjqoK8kTN2iz0EfB/wyRkLPj/ro3+NL/wAKe8M/3Z/+/jf411N1dzwShY32rtzjANQf
2jdf89f/AB0f4V1csexyc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+F
H9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR
/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf
2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9
o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/a
N1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2j
df8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3
X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1
/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf
89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/
AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z
1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8A
PX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX
/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9
f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/
AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/
8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8A
HR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x
0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAd
H+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR
/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f
4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+
FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/h
Ryx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4U
csewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FH
LHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRy
x7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucs
ewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLH
sHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7
BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsew
c0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsH
NPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7Bz
T7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0
+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNP
uc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7
nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5
zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc
7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO
/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv
/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/
AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8
Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8A
wp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp
7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDC
nvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/Cnv
DP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe
8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M
/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7w
z/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/
AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP
92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8A
dn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3
Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2
f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn
/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/
+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/
AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7
+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8A
v43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v4
3+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/
jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf
40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N
/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/j
R/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+
NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH
/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40
f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8
Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/
wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp
7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/C
nvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/Cnv
DP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke
8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M
/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7w
z/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/
AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP
92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8A
dn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3
Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2
f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn
/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/
+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/
AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7
+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8A
v43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v4
3+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/
jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf
410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N
/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/j
XRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+
NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+Nd
F/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf41
0X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X
9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXR
f2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2
jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/
aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN
1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o
3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X
/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jd
f89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf8
9f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/
z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1
/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jQPg94Zzytxj/rqf8a6L+0br/nr
/wCOj/CnJqF0zqvm9Tj7o/wo5Y9g5p9zxz4i/D+Hw2qahpXnPY5CTI/zGJj0bP8AdPTnocc8gDz2
vqu9jjuBNFOivFIpV1cZDKRggj0xXypWFWKT0OilNyVmFd/8IP8Akb5/+vNv/RkdcBXofweiLeKb
qXHC2pU/i6n+lTD4kVU+FnsOof69f93+pqpVi/Obgeyiqua6jjHUU3NGaQx1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1SQf6+P8A3h/Ooc1JAf8ASIv98fzp
gS65P9n0jUZ+R5dvI/HspNfL9fS3ir/kVtb/AOvKf/0Bq+aawrbo3obMK9S+C8YN9qsvdViUfjvP
9K8tr1X4Lf6/V/8Atj/KSop/Ei6vwM9KvTm6f2x/Kq9TXn/H2/4fyqCuo5RaKSikAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
SQf8fEX++P51FU1qM3UY980wIfFX/Ira3/15T/8AoDV8019K+LGC+FdaJOB9inH5oa+aqwrbo3ob
MK9U+C/+v1f/ALY/ykryuvWfgvFhNWm7M0S/kG/+KqKfxIur8DPRLz/j7f8AD+VQVJdnN1Ifeoa6
TlHUU2igY6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOqxZf8AH3H+P8qq1Ysv+PuP
8f5GgRl+PpzB4I1aQHGYgn/fTBf618717/8AEn/kQNT/AO2X/o1K8ArCt8R0UPhCvZ/g2gGgXsnd
rpl/JU/xrxivafg7/wAi3df9fb/+gR0qXxDrfCddcHNxJ/vGo806f/j4k/3j/OmV0HMLmjNJRQMX
NGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB
c0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKA
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzR
mkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXN
GaSigBc0ZpKKAFzRmkooAXNGaSigBc1Ysv8Aj7T8f5VWq1p4zdA+gNAmYXxJ/wCRA1P/ALZf+jUr
wCvfviUwHgHUgTyxiA9/3q14DWFb4joofCFe0fB7/kW7r/r7f/0COvF69u+EcPl+FJXx/rLl2/RR
/wCy0qXxDrfCdNOf9Ik/3z/Oo80srbpnPqxpma6DnHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc
0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM0
3NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmj
NNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZ
ozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
B2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2at6ef37f7h/mKpZq
5px/fv8A7h/mKEJnLfFibyvBoT/nrdRp+jN/SvDq9q+L/wDyKdr/ANfyf+i5K8Vrnq/EdNH4Qr3r
4YqF8EWZHVjIT/38cf0rwWve/hmf+KHsf+2n/o16dH4hVvhNItmjNNzRmtjAdmjNNzRmgB2aM03N
GaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZq3px/ft/uH+Yqlmr2mj55D7AU0D2OQ+L/APyKdr/1/J/6LkrxWvafjA4HhazTub1SPwR/8a8W
rnq/EdFH4Qr3r4af8iPY/wDbT/0Y9eC1794Bj+z+B7Af9M2f82Lf1p0fiFW+EtUU3NGa2MR1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1aGl9Zfw/
rWbmtHSj80n4f1poT2OD+MsxWz0iHPDySvj6BR/7NXkleq/Gf/mCf9t//adeVVzVPiZ00vgQV9De
GQE8F6eB/wA+UZ/8hg18819C+HD/AMUZYf8AXlH/AOixVUd2TW2QmaM0zNGa2MR+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmtHST80n4f1rLzWrpP3WPq39KEJ7Hn3xn/5gn/bf/2nXlVep/GZ1Mmix5+ZRMxHsdn+Bryy
uep8TOml8CCvoPw4ceDbD/ryj/8ARYr58r6H02P7L4YtYsY2WyJj6KBVUt2TW2RWzRmmZozWpiPz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD81saOcxt/vH+QrEzW1opzG/1P9KaE9jy/wCMMpbxFYw9ktN35uw/9lrzqvQP
i/8A8jZa/wDXin/oySvP655/Ezqp/Cgr6NmwulELwAAAPxr5yr6LuD/xLG/D/wBCq6XUit0MzNGa
ZmjNaGQ/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD8
0ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA
/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0
APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmj
NAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZ
ozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zp
maM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NG
aZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzW3of3H+p/pWDmt7RP9X9Qf501uKWx5Z8X/APkbLX/rxT/0ZJXn
9d78XJA/i+BR1SzRT/305/rXBVzT+JnTT+FBX0TcnGmN+H86+fbKLz7+2i/vyqv5kCvfr1tungeu
K0pdSKvQzM0ZqPNGasyJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM10W
h82+fQf1Nczmum0A5tG/z3NVHcUtjxn4mymTx3fKc/u0iUf98Kf61yNdV8Sf+R/1P/tl/wCikrla
5pfEzqh8KL+hc+INNz0+1Rf+hivcdRP+gx/7w/ka8O0L/kYNN/6+ov8A0MV7dqJ/0GP/AHh/I1pT
2ZnV3RnZozUeaM1ZmSZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZrpvD/
APx6t+H8zXK5rq9AGLZvov8AWnHcmWx4t8Sf+R/1P/tl/wCikrla6f4hyrN481Rl6BkX8RGoP8q5
iueXxM6ofCi/of8AyMGm/wDX1F/6EK9r1I4sox/tD+RrxvwxH5viXT1xnEob8uf6V7BqzYiiX3Na
U9mZ1N0Z2aM1Huo3VRBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJ
mjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma
M1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZrsNBH+gbvX
A/QVxe6u18PnOmD/AHv/AGUVUdyZ7HgXi2UzeMNYY9ReSr+TEf0rGrV8T/8AI2az/wBf0/8A6Mas
quZ7nVHZG74N/wCRrsc+r/8AoDV6pq5/1P8AwL+leVeDv+Rqsv8Agf8A6A1epawf9T/wL+la0/hM
qnxGfmjNR7qN1USSZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozU
e6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7
qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma7fw9/yDP+Bf8A
sorhN1d5oAI09v8ArocfkKqO5E9j5+8T/wDI2az/ANf0/wD6MasqtHxBKJ/EmqSjGJLyVhj3cms6
uZ7nUtjc8HDPiqy+r/8AoDV6frDf6n/gX9K848DR7/Esbf3I2b+Q/rXoOrt++jX0XP61rD4TKfxF
HNGaZmjNMkfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0
zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5r0PRFxpcZ/vFj+uK85zXo+i86TB/wAC/wDQjVw3InsfM8sh
lleQ9XYsfxplFFcp1nVeAP8AkYZP+vc/+hLXb6uf9LT/AHB/M1w/gH/kYJP+uB/9CWu11Y/6Uv8A
uD+ZraHwmM/iKWaM03NGaYh2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAeOSBXpGh/wDIHg/4F/6Ea82j5lQerCvRdMk+
zeHklPOyN3/UmqgZ1Nj5pooormOs6nwED/b8h7eQf/QlrstWP+lr/uD+Zrlfh9HnULqTH3UUfnn/
AArpdUbN8w9AB+lax+Exl8RVzRmm5ozTEOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA
7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0
AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmj
NADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5
ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zp
uaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAEsR/fJ/vCu91BjB4DvHXqunSOM
evlk15/Ef3yf7wr0DVv+Sf33/YLk/wDRRq47Mie6PnOiiiuY6jtfh7/r776J/wCzVu6kf9Pl/D+Q
rB+H3+vvvon/ALNW5qR/0+X8P5CtY/CYy+Ir5ozTM0ZpgPzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAE0PMyf7wr0DVv+
Sf33/YKk/wDRRrz625nSu98QyfZfh7fZOMaeY/zTb/WrjszOe6PniiiiuY6jtPh+D5t8e2E/9mra
1Fs38uPb+QrM8Api0upPWTb+QH+NXrxt15Mf9sitV8Ji/iZFmjNJRQAuaM0lFAC5ozSUUALmjNJR
QAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0l
FAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozS
UUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjN
JRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM
0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5o
zSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALm
jNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAu
aM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC
5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUA
LmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQ
AuaM0lFAC5ozSUUATWx/fr+P8q7b4h5h+H2oheyxL+HmIK4i2P79fx/lXb/En/kQNT/7Zf8Ao1Kt
fCyJfEjwCiiiuc6Tv/Af/ILuP+ux/wDQVqe6/wCPub/ro386r+A/+QXcf9dj/wCgrU90f9Lm/wCu
jfzrVfCjF/EyOikzRmgYtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0U
maM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALR
SZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAt
FJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC
0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0A
LRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQ
AtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjN
AC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM
0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZo
zQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJm
jNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0AT23+vX2zXcfEn/kQNT/
AO2X/o1K4mwTzLpU9eP1rsPifN5XgW7Tj97JGn/j4b/2WrXwszl8SPBqKKK5zpO/8CqRpU5PeYkf
kKkuTm6lPq5/nUngxAmgo399mP6kf0quzbmJ9TmtuiMftMKKSikMWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA0dDUPrNq
p6NKg/8AHhW58XmK+EbYDo16gP8A3w5/pWJoB/4nln/12T/0IVtfF/8A5FO1/wCv5P8A0XJVfYZm
/jR4rRRRWB0nc+CdWt5I10m4jCyjc0LgnDjqQffqfp9Oex+wW3/PL/x4/wCNeLo7xSLJGzI6kMrK
cEEdCDWr/wAJTrf/AEEZfyH+FaRnZamcoNu6PU/sFt/zy/8AHj/jR9gtv+eX/jx/xryz/hKdb/6C
Mv5D/Cj/AISnW/8AoIy/kP8ACnzon2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTr
f/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfy
H+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoP
Zy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9
gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/
48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7
Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/
AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jX
ln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt
/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nq8FrBb3EcyRDfG4dck9Qc+tVfircpd+C7OVDwb5MjPQ+XJxXmX/C
U63/ANBGX8h/hVe91vUtRtxBd3kksQYPsOMbgCAf1P50OorWBU3dMoUUUVkbH//ZDQplbmRzdHJl
YW0NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRo
IDE3MjEvSGVpZ2h0IDM2My9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0
c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMjgyMT4+DQpzdHJlYW0NCnic7d1LcpvHGYZRLQVLwU7IbCRkFpKQWUPudmz4LsuWI9mObEuy
Atm6BAAJQgB/8CaqFFcTnDTb/zDdX9U5w2/0zp4CCtW4dQsAAID/g9/+HgAaVQrX6C0AtKoQrnHt
TQDw626Gq/YiAOjxB+ECIBThAiAW4QIgFuECIJRxKVx3AaAxj9frq0gJFwARCBcAoTwVLgAieSFc
AEQyEy4AIrkOl18VAhDCYn2aGjUSLgAiWK/PUqP2hAuACNbr89SoHeECIALhAiCU9foiNWpLuACI
YL1+nRo1FC4AIlivL1OjBsIFQATCBUAo6/WbwsMZm3B9CQBtuVt+8Um4AGhU15XCNUi389rjACDX
F65V7XEAkCuHa5huB7XHAUCuHK5t4QKgTeVw7abbi9rjACDXF65x7XEAkCuHaz/dfqg9DgBy5XCN
hAuANpXDNU63r2uPA4BcX7hqbwOAG8rh8uITAI0SLgBCES4AIrkvXABEIlwAhPJAuACI5JFwARDJ
WLgAiOS5cAEQiXABEMp0E66xcAEQwdEmXCPhAiCCo+5EuACIo+tOU6P2hAuACLruLDVqR7gAiKDr
zlOjtoQLgAiuwzUULgAi6LrXvx6uLwCgLb+E6zI1aiBcAETQdW8KD2cIFwCNEi4AQik/VXgVrvPa
4wAgVw7XQLgAaFM5XMN0W9UeBwC5cri20+2g9jgAyPWF60XtcQCQK4drN93+U3scAOTK4doXLgDa
VA7XKN2+rz0OAHJ94fq69jgAyJXDNRYuANpUDpcXnwBolHABEIpwARCKcAEQyT3hAiCSB33hugMA
bfnikXABEMlD4QIgkrFwARDJc+ECIJKpcAEQyXW4xsIFQARH3Ulq1Ei4AIig605To/aEC4AIuu4s
NWpHuACIQLgACKXrzlOjtoQLgAi67nVq1FC4AIig6y5TowbCBUAEwgVAKF33pvBwhnAB0Kjyi0+b
cH0OAI05LoZrkG5ntccBQO74uBSuYbqtao8DgFxfuA5qjwOAXDlc28IFQJvK4dpNt2e1xwFArhyu
/XT7sfY4AMiVwzVKtwe1xwFAri9c92qPA4BcOVxj4QKgTeVweTgDgEYJFwCh9IXrNgC0RrgAiOQr
4QIgEuECIJRvhAuASH4QLgAieSJcAETys3ABEIlwARDKZBOusXABEMF8E66RcAEQwfx4LVwAxHF8
fJIatVcK12cA0JZfwnWaGrUjXABEsFqdp0ZtCRcAEaxWZ6lRQ+ECIILV6kK4AIhjtXqdGjUQLgAi
WK3eFB7OEC4AGiVcAISyWpWeKhyk21ntcQCQ6wvXqvY4AMiVwzVMt9mnANCYcri2hQuANpXDtZtu
P9ceBwC5vnA9qj0OAHLlcO2n27e1xwFArhyukXAB0KZyuMbpdrf2OADI9YWr9jYAuKEcrrfCBUCb
hAuAUIQLgFD6wvUJADTmC+ECIJJ7y6VwARDHA+ECIBLhAiCUx8IFQCRPhQuASF4KFwCRXIdrXArX
xwDQmMPlcWrUSLgAiGC57FKj9oQLgAiWy5PUqB3hAiAC4QIglOXyLDVqS7gAiGC5vEiNGgoXABEs
l69TowbCBUAEwgVAKMvlm8LDGcIFQKPKLz5dhev0IwBozKtiuAbCBUCbXr0qhWuYbq9qjwOAXDlc
2+k2qT0OAHJ94fqp9jgAyJXDtZtuD2uPA4BcOVz7wgVAm8rhGqXbN7XHAUCuL1x3PgSAxpTDNRYu
ANpUDtfVrfY2ALhBuAAIRbgACEW4AIjktnABEIlwARDK3b5wfQAAbfnwW+ECIJLvFwvhAiCOJ8IF
QCTCBUAozzbhGgsXABFMN+EaCRcAEUwXS+ECII7FYpUatSdcAESwWKxTo3ZK4RoBQGMWi9PUqC3h
AiCC63ANhQuACBaLC+ECII7F4nVq1EC4AIhgsXhTeDhDuABolHABEEr5qcJBup3WHgcAuXK4hul2
VHscAOT6wvXyfQBoy6+Ea1u4AGjT0VEpXLtXf3VSexwA5Mrh2k+372uPA4BcOVyjdLtfexwA5PrC
dbv2OADIlcM1Fi4A2lQO19Wt9jYAuKEvXO8BQFuEC4BghAuAUIQLgEg+Fi4AIrkjXABEck+4AIhE
uAAI5TvhAiCSx33h+icANOapcAEQydP5PDVqLFwARPDf+SI1aiRcAEQwny9To/aEC4AI5vMuNWpH
uACIQLgACGU+X6dGbQkXABHM52epUUPhAiCC+fwiNWpQCte7ANAW4QIglvn8svBwhnAB0KjNwxlZ
uAbpdlJ7HADk+sI1rz0OAHLlcA3T7WXtcQCQK4drW7gAaFM5XLvp9qT2OADI9YXr37XHAUCuHK79
dLv7DgA05rAYrpFwAdCmw8NSuMbp9nHtcQCQ6wtX7W0AcEM5XG+FC4A2CRcAoQgXAKEIFwCRfCBc
AEQiXACEclu4AIjkq75w/QMAGvONcAEQyUPhAiAS4QIglPEmXGPhAiCCl5twjYQLgAheHi6EC4A4
Dg9fpUbtCRcAERweHqdG7QgXABEcHq5To7ZK4fo7ADTmOlxD4QIggoODU+ECII6Dg4vUqIFwARDB
wcFl4eEM4QKgUX3hOqk9DgByBwelpwoHwgVAm8rhGqbbvPY4AMiVw7Wdbi9qjwOAXF+4fqw9DgBy
5XDtptu3tccBQK4crn3hAqBN5XCN0u1O7XEAkCuHa5xuH/wNABojXACEUg7X1a32NgC4QbgACEW4
AAhFuAAIRbgAiOQ94QIgkk+EC4BIvhQuACIRLgBC+Vq4AIjkh75w/RUAGvNEuACI5Mlslho1Fi4A
Ing+m6dGjYQLgAhms0Vq1J5wARDBbLYSLgDiuA7XjnABEMFstk6N2hIuACKYzU5To4bCBUAEs9lF
atRAuACIQLgACGU2uyw8nCFcADRq83BGFq5Bup3UHgcAuXK4huk2rz0OAHJ94XpeexwA5Mrh2k63
Z38BgMaUw7Wbbo9qjwOAXDlc++l2v/Y4AMiVwzVKt9u1xwFAri9co9rjACBXDtdYuABoUzlcV7fa
2wDgBuECIBThAiAU4QIgFOECIJJ3hQuASIQLgFA+Ei4AIrkjXABEck+4AIjkO+ECIBLhAiCUJ5tw
jYULgAiezeZXD8GXwvVnAGiLcAEQy3S6SI3aEy4AIphOV6lRO8IFQATTaZcatSVcAERwHa6hcAEQ
wXR6KlwAxDGdXqRGDYQLgAim08vCwxnCBUCjyuEapNu69jgAyE2npacKr8I1rz0OAHLlcA3T7Vnt
cQCQK4drW7gAaFM5XLvp9rD2OADI9YXrfu1xAJArh2s/3T6rPQ4AcuVwjYQLgDaVwzVOt/drjwOA
XF+4am8DgBvK4fLiEwCNEi4AQhEuAEIRLgBCES4AInlHuACI5EPhAiCSz4ULgEiEC4BQ/iVcAETy
oC9cfwKAxvwoXABE8ngySY0aCxcAEfw0OUiNGgkXABFMJkepUXvCBUAEk8lSuACI4zpcO8IFQAST
SZcatSVcAEQwmZykRg2FC4AIJpPz1KiBcAEQgXABEMpkcll4OOMqXOva4wAgt3k4IwvXQLgAaFM5
XMN0m9ceBwC5cri20+1Z7XEAkOsL18Pa4wAgVw7Xbrrdqz0OAHLlcO0LFwBtKodrlG6f1h4HALly
uMbp9l7tcQCQEy4AQimHy4tPADRKuAAIpS9cEwBoj3ABEEopXE/fAkDTbpU+cgFAq24pFwCR5OFS
LgCadiNcv6m9CAB63AiXH2gA0LKb4fJlIQANK4Tr1h8BoFG/K4ULAEL4H94CKEINCmVuZHN0cmVh
bQ0KZW5kb2JqDQoxOSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2Rl
WyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21h
aW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggNDgyPj4NCnN0cmVhbQ0KeJyNwmVXWgEYAOBfuFI23Ryl5KUuXLq7u7tBBRsFAxDFANe6bv/J
3nsuR4/7sLPnPPWL6/q/j69r49//8dfk6M7q7Z/48zsr+B/4s79+L8PTm9+IpRPi18khvjj8cvv4
c+Hm0SeYx3/MDyZzgw+5Q+L7bJ94le3hM73LTBef7r5LHxDfpvbhG5jce01M7L7Cd17GYfsFjLUv
YjtwHN2Go2hrFGmdw/DWWXgTnobgxkkQrg+Da8cBuHrkhysDH2weept9b6PvafQ8y133EjxwL+67
YH3PWdt11jqOasdebdsrO7Yy3LaWWtZiy1LcshQ2zfkNaMqtG7NrxsyqAaZX9KmmLtXQJZe1iSWo
iS9qYnV1tKaCkaoyXFGGyopQSR4sygNFmb8g8+elvhzmzWKejAS602JXCnUmUWdC5IgL7TGhLSaw
RQXWCN8S5ptDPHMIMQURY4Br8HMMPo7ex9Z52VoPS+tmaVxMtYuhdjJUjgWlfV5hg3S5lS6z0GRm
mtRMxUxUzEiRGChiA1msJ6O656h2TqSdE2rgM4H6KV+F5ylneYpZRDGDyGe4MviEI4WP2RgksSQk
lpjEFE8z0WkGOsUQTS1A4aN5KMDT+Q8hDfIeQCpE7lMgF96DZA78A4Rh2QoNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoyMCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9E
ZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0
cnVlIHRydWVdIC9GdW5jdGlvbiAxOSAwIFI+Pj4+DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9UeXBl
L01hc2svUy9MdW1pbm9zaXR5L0cgMjIgMCBSL0JDIDIzIDAgUj4+DQplbmRvYmoNCjIyIDAgb2Jq
DQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0JCb3hbIDQ4IDc4IDY2MCAxMzJdIC9Hcm91
cCAyNCAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AyNiAyNiAwIFI+Pj4+L0xlbmd0aCA0Mz4+
DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMjYgc2NuDQo0OCA3OCA2MTIgNTQgcmUNCmYqDQoNCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9iag0KWyAwIDAgMF0gDQplbmRvYmoNCjI0IDAgb2JqDQo8
PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2JqDQoyNSAwIG9iag0KPDwvRnVu
Y3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2RlWyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEg
MCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9P
cmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTU4Pj4NCnN0cmVhbQ0KeJx9wYVOgmEA
htG7pUukRErpkhBQCYtUlLxBtmd7t+8fP5xzPNo4XLW/YGdne2Zj9W/4s1obfuXHsJKlLGQuM5ni
W77wKR94lwnGGGEob3jFCwboo4dndNFBGy08oYkG6qihigrKKKGIAvJ4xANyyEoGaaRwL0ncSQJx
iSEqEbmVsNxIyBCUgMFv5TN4rTxn3HZcFzivctg5AUDupZANCmVuZHN0cmVhbQ0KZW5kb2JqDQoy
NiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv
U2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0cnVlIHRydWVd
IC9GdW5jdGlvbiAyNSAwIFI+Pj4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0
ZS9CTS9Ob3JtYWwvY2EgMS9TTWFzayAyMSAwIFI+Pg0KZW5kb2JqDQoyOCAwIG9iag0KPDwvVHlw
ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTE0Ni9IZWlnaHQgNDA2L0NvbG9yU3BhY2Uv
RGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRl
IHRydWUvU01hc2sgMjkgMCBSL0xlbmd0aCAyMDIyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEB
AHgAeAAA/+EAWkV4aWYAAE1NACoAAAAIAAUDAQAFAAAAAQAAAEoDAwABAAAAAQAAAABREAABAAAA
AQEAAABREQAEAAAAAQAAEnRREgAEAAAAAQAAEnQAAAAAAAGGoAAAsY//2wBDAAgGBgcGBQgHBwcJ
CQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBD
AQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjL/wAARCAGWBHoDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI
CQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAk
M2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgEC
BAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcY
GRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOU
lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3
+Pn6/9oADAMBAAIRAxEAPwDwO3gkurmK3hUNLK4RASBkk4HJ4H410f8AwrzxSf8AmGD/AMCYv/iq
xdH/AOQ3Yf8AXzH/AOhCvqEEjpWlOCluZVKjjsfPH/CvPFP/AECx/wCBMX/xVH/CvPFP/QLH/gTF
/wDFV9AS3kkchUBSB6imfb5f7qfka09lEz9tI8C/4V54p/6BY/8AAmL/AOKo/wCFeeKf+gWP/AmL
/wCKr337fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfin/oFj/wIi/8AiqP+Fd+Kv+gWP/AiL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AiL/4qj/hXfir/AKBY/wDAiL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwIi/+Ko/4V34q/6BY/8AAiL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXfir/oFj/wACYv8A4qj/AIV34q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFd+Kv+gWP/AmL/wCKo/4V34q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V34q/6BY/8CYv/iqP+Fd+Kv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXfir/
AKBY/wDAmL/4qj/hXfir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFd+Kv+gWP/
AAJi/wDiqP8AhXfir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV34q/6BY/8CYv/
AIqj/hXfir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXfir/oFj/wJi/+Ko/4V34q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv8AoFj/AMCYv/iqP+Fd+Kv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V34q/6BY/8AAmL/AOKo/wCFd+Kv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfir/oFj/wJi/8AiqP+Fd+Kv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AmL/4qj/hXfir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXXir/oFj/wACYv8A4qj/AIV14q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFdeKv+gWP/AmL/wCKo/4V14q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V14q/6BY/8CYv/iqP+FdeKv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXXir/
AKBY/wDAmL/4qj/hXXir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFdeKv+gWP/
AAJi/wDiqP8AhXXir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV14q/6BY/8CYv/
AIqj/hXXir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXXir/oFj/wJi/+Ko/4V14q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+FdeKv8AoFj/AMCYv/iqP+FdeKv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V14q/6BY/8AAmL/AOKo/wCFdeKv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXXir/oFj/wJi/8AiqP+FdeKv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+FdeKv+gWP/AmL/4qj/hXXir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V14q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPBP+FdeKv+gWP/AAJi/wDiqP8AhXXiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZ
RD20jwT/AIV14r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r
/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/
AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/
AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hX
Piv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6B
Y/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJ
i/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq9
7+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v9
1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9
vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qf
kaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ
9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4
Vz4r/wCgWP8AwJi/+Ko/4Vx4r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+
gUP/AAJi/wDiqP8AhXHiv/oFD/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8
CYv/AIqj/hXHiv8A6BQ/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4q
j/hXHiv/AKBQ/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/wCgUP8AwJi/+Ko/4Vx4
r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+gUP/AAJi/wDiqP8AhXHiv/oF
D/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8CYv/AIqj/hXHiv8A6BQ/8CYv
/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4qj/hXHiv/AKBQ/wDAmL/4qve/
t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4s/wCgUP8AwJi/+Ko/4Vx4s/6BQ/8AAmL/AOKr3v7fL/dT
8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AAJi/wDiqP8AhXHiz/oFD/wJi/8Aiq96+3y/3U/I0fb5
f7qfkaPZRD20jwX/AIVx4s/6BQ/8CYv/AIqj/hXHiz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaP
ZRD20jwX/hXHiz/oFD/wJi/+Ko/4Vx4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf
+FceLP8AoFD/AMCYv/iqP+FceLP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz
/oFD/wACYv8A4qj/AIVx4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/wCFceLP+gUP
/AmL/wCKo/4Vx4s/6BQ/8CYv/iq96+3y/wB1PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8CYv/iqP
+FceLP8AoFD/AMCYv/iq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz/AKBQ/wDAmL/4qj/hXHiz
/oFD/wACYv8A4qvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8AAmL/AOKo/wCFceLP+gUP
/AmL/wCKr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf8AhXHiz/oFD/wJi/8AiqP+FceLP+gUP/AmL/4q
vevt8v8AdT8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AmL/4qj/hXHiz/AKBQ/wDAmL/4qvevt8v9
1PyNH2+X+6n5Gj2UQ9tI8F/4Vv4s/wCgUP8AwJi/+Ko/4Vv4s/6BQ/8AAmL/AOLr3r7fL/dT8jR9
vl/up+Ro9lEPbSPBf+Fb+LP+gUP/AAJi/wDi6P8AhW/iz/oFD/wJi/8Ai696+3y/3U/I0fb5f7qf
kaPZRD20jwX/AIVv4s/6BQ/8CYv/AIqj/hW/iz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaPZRD2
0jwX/hW/iz/oFD/wJi/+Ko/4Vv4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf+Fb+
LP8AoFD/AMCYv/iqP+Fb+LP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hW/iz/oFD
/wACYv8A4qj/AIVv4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI+ctb8L6z4dW3bVbP7O
txu8o+Yj7tuM/dJx1HWsivb/AIrKt34RhllUbonLpjjB3Kv8mNeIVlOPK7I2pycldl3R/wDkN2H/
AF8x/wDoQr6fr5g0f/kN2H/XzH/6EK+n60o7Myr7oo3H+vb8P5VFUtx/r2/D+VRVqYhRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/E3/AJEv8f8A2oleIV7f
8Tf+RL/H/wBqJXiFYVfiOmj8Jd0f/kN2H/XzH/6EK+nc18xaP/yG7D/r5j/9CFfTtXR2ZFfdFG4/
17fh/KoqluP9e34fyqKtTEKKKKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAct8TP+RL/H/wBqJXiNe3fEz/kS/wAf/aiV4jWFX4jpo/CXdH/5Ddh/18x/+hCvpyvm
PR/+Q3Yf9fMf/oQr6cqqOzIr7oo3H+vb8P5VFUtx/r2/D+VRVsYhRRRSGFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBy/xL/wCRL/H/ANqJXiNe3fEv/kS/x/8AaiV4
jXPV+I6KPwl3R/8AkN2H/XzH/wChCvpuvmTR/wDkN2H/AF8x/wDoQr6bzV0dmRX3RQuf9e34fyqK
pbk/v2/D+VRZrUxCijNGaBhRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmj
NABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRm
jNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRR
mjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABR
RmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAB
RRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNA
BRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAHMfEr/AJEv8f8A2oleJV7b8Sv+RL/H/wBq
JXiVc9X4joo/CXdH/wCQ3Yf9fMf/AKEK+mc18zaP/wAhuw/6+Y//AEIV9MVdHZkV90Ubk/v2/D+V
RZqS5/17fh/Koq1MRc0ZpKKBi5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSU
UALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJ
RQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0
lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5oz
SUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmj
NJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAua
M0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5
ozSUUALmjNJRQBzXxJ/5Ev8AH/2oleJ17Z8SD/xRZ+v/ALUSvE656vxHRR+Eu6P/AMhqw/6+I/8A
0IV9L180aR/yGrD/AK+I/wD0IV9LVdHZkV90Ubk/6Q34fyqLNSXP/Hw34fyqGtTIdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooA5z4j/wDIln6/+1ErxSvaviP/AMiWfr/7USvFa56vxHRR+EuaR/yGrD/r4j/9CFfSua+a
tI/5DVh/18R/+hCvpSro7Mivuijcn/SG/D+VQ5qS5/4+G/D+VRVqZC5ozSUUgFzRmkooAXNGaSig
Bc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKK
AFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmko
oAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaS
igBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Zp
KKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRm
kooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNG
aSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigDnfiKf+KLP1/8AaiV4tXtHxE/5
Etvr/wC1ErxesKvxHRR+EuaR/wAhqx/6+I//AEIV9JZr5t0j/kNWP/XxH/6EK+kM1dHZkVt0Ubk/
6Q34fyqHNSXJ/wBIb8P5VFmtDIXNGaTNGaBi5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozS
ZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJm
jNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM
0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQ
AuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC
5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALm
jNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0Ac/8Q/+RLb6/wDt
RK8Yr2b4hHPgtvr/AO1ErxmsKvxG9L4S5pP/ACGbH/r4j/8AQhX0dmvnHSf+QzY/9fEf/oQr6MzV
0tmRW3RRuT/pD/h/Koc1Jcn/AEh/w/lUOa0Mh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQBhfEH/kS3+v8A7USvGq9k8fn/AIot/qP/AEYleN1hV+I3pfCXNJ/5DNj/
ANfEf/oQr6KzXzrpP/IYsf8Ar4j/APQhX0RmqpdSa26KN0f9If8AD+VQ5p90f9If8P5VDmtTIfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB
+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Zo
AfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNG
aAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMz
RmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozT
M0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM
0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfm
jNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAxfHx/wCKLf6j/wBGJXjl
ew+PDnwXJ9R/6MSvHqwq/Eb0vhLelf8AIYsf+viP/wBCFfQ+a+eNK/5DFl/18R/+hCvoTNVS2ZNb
dFG6P+kP+H8qhzT7o/6Q/wCH8qhzWhmPzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0AY/js/8UXJ9R/6MSvH69f8AHJz4Ll+o/wDRiV5BWNTc3pfCW9K/5C9l/wBfEf8A
6EK+gs18+6V/yF7L/rvH/wChCvf81VLqRW3RQuj/AKS/4fyqHNPuj/pL/h/Koc1oZj80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAGV43OfBcv1H/AKMWvIq9c8anPgub
6j/0YteR1jU3N6Wxb0v/AJC9l/13T/0IV77n3rwLS/8AkLWX/XdP/QhXvWaql1IrdDPuj/pL/h/K
oc1JdH/SX/D+VQ5qyB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
DM8ZnPguf6j/ANGLXktes+MjnwZP9V/9GLXk1ZVNzalsWtL/AOQtZ/8AXdP/AEIV7xmvB9M/5C1n
/wBd0/8AQhXu2aql1Jq9DPuz/pL/AIfyqHNPuz/pL/h/Koc1ZmPzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjN
AD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZo
zQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpm
aM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AZ/jA58GXH1X/wBGLXlFereLjnwZcfVf/Ri15TWVTc2p
7FrTP+QrZ/8AXdP/AEIV7nmvDNM/5Ctn/wBd0/8AQhXuGadMmr0M+7P+kv8Ah/Koc0+7P+lP+H8q
gzVkEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1H
mjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAFPxYf+KMufqv8A6MWvK69S8VHPgy5+q/8Aoxa8trKpua09i1pv/IVs/wDrun/oQr27
NeI6b/yFLT/rsn/oQr2vNVTJq9DOuz/pT/h/Koc0+7P+lP8Ah/Koc1ZA/NGaZmjNAx+aM0zNGaAH
5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmg
B+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Z
oAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zN
GaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNM
zRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAq+KDnwZdfVf8A0YteXV6f4mOfBt39U/8ARi15
hWVTc0p7FnTf+Qpaf9dk/wDQhXtOa8W07/kKWn/XZP8A0IV7Pmqpk1ehm3h/0p/w/lUGalvD/pT/
AIfyqDNUSOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AV/Epz4Nu
/qn/AKMWvMq9M8RnPg28+qf+jFrzOs57mlPYs6d/yE7T/rsn/oQr2TNeN6d/yE7T/rsn/oQr2LNV
TFU3Rm3h/wBKf8P5VBmpbw/6U/4fyqDNUQh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0
ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7
NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0A
OzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjN
ADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5o
zQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zpu
aM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQBF4hP8AxRt59U/9GLXmlek+IDnwbe/VP/Rgrzas57mlPYs6d/yE7T/rsn/o
Qr2HNePaf/yErX/rsn8xXr2aqmTUM28P+lP+H8qgzUl4f9Kf8P5VBmmSPzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AM1858G3v1T/0YK83r0fXT/wAUdffVP/Rgrzio
nuaQ2LGn/wDIStf+uyfzFeu5ryLT/wDkJWv/AF2T+Yr1vNOmTUMy8P8ApT/h/KoM1LeH/Sn/AA/l
UGaokdmjNNzRmgY7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AJrZ/4o6++sf/
AKMFec16LrX/ACJ19/2z/wDRgrzqonuXDYsaf/yErX/rsn8xXrVeS2H/ACEbX/rsn8xXrOadMmoZ
d4f9Kf8AD+VV81NeH/S3/D+VQZqhC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAua
M0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5oz
SZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJ
mjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0ma
M0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZoz
QAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNA
C5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNABrP/ACJ1/wD9
s/8A0YK87r0PWDnwdf8A/bP/ANGCvPKie5cNixYf8hG1/wCuyfzFer15RYf8hG1/66p/MV6tmnTJ
qGXef8fT/h/KoKmvD/pT/h/KoM1QkLRSZozSAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAF
opM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoA
WikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmg
BaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGa
AFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0Z
oAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzR
mgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTN
GaAFopM0ZoAWikzRmgBaKTNGaADV/wDkTtQ/7Z/+jBXnteg6v/yJ+of9s/8A0YK8+qZ7lw2LFh/y
EbX/AK6p/MV6pmvK7D/kI2v/AF1T+Yr1PNOAqhl3h/0p/wAP5VBmprz/AI+n/D+VQVRKFzRmkopD
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB2rf8ifqH/b
P/0YK8+r0DVf+RP1D/tn/wCjBXn9TPcqGzLFh/yEbb/rqn8xXqWa8u05S2p2ijqZkH/jwr1DNOAp
mXeH/Sn/AA/lUGatXUUj3Lsq5Bx39qh8iX+7+oqiSPNGak8iX+7+oo8iX+7+opAR5ozUnkS/3f1F
HkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/
UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmj
NSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev9
39RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/
AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEea
M1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/
3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeR
L/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQ
BHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J
5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UU
eRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1F
AEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozU
nkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/
UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev9
39RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEe
aM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8A
d/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/
3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR
5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeR
L/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR
5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAN1X/kT9R/7Z/+jBXn9egaspXwjqIYYP7v/wBGCvP6me5c
NgqaG6uLdSsM8sYJyQjkZ/KiioLLo8QaoAB9q6f7C/4Uf8JDqn/P1/5DX/Ciindisg/4SHVP+fr/
AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU
/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4
SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsL
IP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wo
oouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kN
f8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1
/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p
/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf
8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4
Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/
8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n
6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+
Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLI
P+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAK
KKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf
8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9
f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOq
f8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH
/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr
/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCf
r/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP
+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8A
hIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouw
sg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KK
KLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ
1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/
X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDq
n/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8A
CQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/
AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8A
Ia/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T
/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh
1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLs
LIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKK
LsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1
/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X
/kNf8KKKLsLIjn1rUbm3e3muC0UmNy7FGcHI6D1AqhRRSGf/2Q0KZW5kc3RyZWFtDQplbmRvYmoN
CjI5IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxMTQ2L0hlaWdo
dCA0MDYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25l
bnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0MTg+Pg0K
c3RyZWFtDQp4nO3Wx00dUBQAUTpzra7BOAeccwc4xw84hzWWl0i85Z0vpHOKGM3ODgAAAAAAAJwp
xwAF5QF655QH6CkP0FMeoLd3enmeAww5/HtiepQHCCgP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAb12eZwBDDpQHyB38UR6gpjxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbleQowRHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95
gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAforcvzBGCI8gA95QF6ygP0lAfo
KQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PI8Bhmx+Kw9QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAL11eR4BDFEeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gC9dXkeAsxQHmALPv9SHqCmPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7P
A4AhygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoLcuz32AIZ9+Kg9QUx6gpzxA
T3mAnvIAPeUBesoD9JQH6K3Lcw9giPIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8twF
GPLxh/IANeUBesoD9JQH6CkP0FMeoKc8QE95gN66PHcAhnxQHiCnPEBPeYCe8gA95QF6ygP0lAfo
KQ/QW5fnNsAQ5QF6778rD1BTHqCnPEBPeYCe8gA95QF6ygP01uXZA5ihPMAWKA/QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FuX5xbAEOUBeu++KQ9QUx6gpzxAT3mAnvIAPeUBesoD9NbluQkwQ3mA
LXirPEBOeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7PDYAhb74qD1BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QW5fnOsAM5QG2QHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QG9dnmsAQ15/UR6gpjxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PFcBhigP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqC3Ls8VgCGvjpQHqCkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYDeujyX
AYYoD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mA3ro8lwBGKA+wDS8PlQeoKQ/Q
Ux6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8lwEmKE8wBYoD9BTHqCn
PEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66
PLsAQ14cKA9QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbluQAwY3dfeYDc
/kZ5gJryAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QG9dng3AmFV5jgDGnCjPf+ePAcbtnEJ+gFmnlQcAAACAs+kfpG8Q
rA0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMC9TaXplWyA1
MTJdIC9EZWNvZGVbIDAgMSAwIDEgMCAxXSAvUmFuZ2VbIDAgMSAwIDEgMCAxXSAvQml0c1BlclNh
bXBsZSA4L0RvbWFpblsgMCAxXSAvRW5jb2RlWyAwIDUxMV0gL09yZGVyIDEvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA4NTA+Pg0Kc3RyZWFtDQp4nJWU5zubYRhH/0KrulvEliAiNkmERKwIIgRB
xGoRe+89W1106/pPeu48b40PPvS6zmfyPvfvnKiErChBH5Woj77GEJ1kiBGyY3RCrJATmyzECblx
KWCEe6mQJ6SZ4iEd8u9DhlnILHgQ4WFWITzSFwmGYnicXQJPckojlD3NhfJnxgp4nmd5brIkmKwJ
JltCvi3RXJloticVQJWusEpXVJ1c5EgudqQUO1NKalJLXZBWVptWXpcOFfUZlgbItDZmWd1ZtiZ9
pUdv9xjszYaqluxqaM1xeHOcbblOn7HGZ3S157k68mr9pjq/qb4zv77L3NBtbgwUgLunsKm30NNX
BM3B4pb+kpZQSetAqXegzDtY1jZU7huGivaRio4XFv9Li3/U2jlq7RqzdY1XdocrA2F7YMLeM1nV
OwXVfdOO4IwjOOvsn3WG5mpC8zUD867BBdfgYu3QUu3wUt3wct3ISj28WG14uQaNo+uNoxvusQ33
+GbT+FZTeMsT3vZMwE7z5C60TO1B6/R+6/SBdwYOvbOHbXNH4Js79s3DSfsCnLYvnnYsvupYeu1X
LJ91wsobYfVtl/Cuew3eC+vvA+sfAhtw3gObcAG9W/BR2P7Yt/1JY+dzUONLcFfoh72vV4T2voX2
r/gOAweKS43Dy0HhxzVHwtDRz1scK37B8E1OFL/vYgRO//wfd/+1CJH/eOM3DGlEfuHtn62+5dbX
HconX39+5DXUy1w/1N63m2/Yv6u9rTxy5LV59qsTcA7tLlsX6lJyso3zgPCBU3JQ7bJr7zg05+bo
2vWXzxiDWgXzYCRMRQazcMJ4ZEJzx2pRTEsGNnPA2Jic2p7aIYOUWYa3mShDZa6MlukyYLVkJs2w
mTcjZ+oMntkzfhRABHRACtRAEDRRviAO+iARKiEUWiEXiiEauiGdsg8NkRElERM9kRRVERZtkReF
ERmdkRq1ERzNkR3lER/9iQApIAhkgTiQCEJBLogG6SAgZET1hLCQFyJDalRziA8JIkTkiCiRJgJF
pogVySJcki+TlZQRNFU2EkfoyJ3qnmqg6qFqo+qkaibx1Cqanh8vSGDJrNbbVKMqsKSYICdrfZZQ
67RuS8CTJOaS9H95J/US/Ej5/wKcWpEGDQplbmRzdHJlYW0NCmVuZG9iag0KMzEgMCBvYmoNCjw8
L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBl
IDIvQ29vcmRzWyA1NjkuODEgNjA5LjI1IDU2OS44MSAzMjYuNzVdIC9FeHRlbmRbIHRydWUgdHJ1
ZV0gL0Z1bmN0aW9uIDMwIDAgUj4+Pj4NCmVuZG9iag0KMzIgMCBvYmoNCjw8L1R5cGUvTWFzay9T
L0x1bWlub3NpdHkvRyAzMyAwIFIvQkMgMzQgMCBSPj4NCmVuZG9iag0KMzMgMCBvYmoNCjw8L1R5
cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vQkJveFsgNDc5LjEzIDMyNi43NSA2NjAuNSA0NjhdIC9H
cm91cCAzNSAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AzNyAzNyAwIFI+Pj4+L0xlbmd0aCA1
OD4+DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMzcgc2NuDQo0NzkuMTMgMzI2Ljc1IDE4MS4zNyAx
NDEuMjUgcmUNCmYqDQoNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNCAwIG9iag0KWyAwIDAgMF0gDQpl
bmRvYmoNCjM1IDAgb2JqDQo8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2Jq
DQozNiAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgNTEyXSAvRGVjb2RlWyAwIDEgMCAx
IDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0g
L0VuY29kZVsgMCA1MTFdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTI4Pj4N
CnN0cmVhbQ0KeJy91IcNwCAQA8D95yG99z5UBrAd9CDlJkC8bedCJBFSi8wn1wqhFCqmZhrQMh3o
wQBGMDEzWJiV2YRdOLTT57K4Izw/inmn6UO83/txGnVNdX0aFRoqzB6NKCYZ046NwNbQcmEHaVVp
qdUCqMX4GBnvQJnmLmZXg4bcvQ6mfT0NCmVuZHN0cmVhbQ0KZW5kb2JqDQozNyAwIG9iag0KPDwv
UGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUg
Mi9Db29yZHNbIDU2OS44MSA2MDkuMjUgNTY5LjgxIDMyNi43NV0gL0V4dGVuZFsgdHJ1ZSB0cnVl
XSAvRnVuY3Rpb24gMzYgMCBSPj4+Pg0KZW5kb2JqDQozOCAwIG9iag0KPDwvVHlwZS9FeHRHU3Rh
dGUvQk0vTm9ybWFsL2NhIDEvU01hc2sgMzIgMCBSPj4NCmVuZG9iag0KMzkgMCBvYmoNCjw8L1R5
cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvQUJDREVFK1ZlcmRhbmEs
SXRhbGljL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA0MCAwIFIvRmly
c3RDaGFyIDMyL0xhc3RDaGFyIDExNC9XaWR0aHMgOTQwIDAgUj4+DQplbmRvYmoNCjQwIDAgb2Jq
DQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStWZXJkYW5hLEl0YWxpYy9G
bGFncyAzMi9JdGFsaWNBbmdsZSAtMTMvQXNjZW50IDEwMDUvRGVzY2VudCAtMjA3L0NhcEhlaWdo
dCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDE5MTQvRm9udFdlaWdodCA0MDAvWEhlaWdodCAy
NTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NTMgLTIwNyAxNDYxIDc2NV0gL0ZvbnRGaWxlMiA5NDEg
MCBSPj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNDMgNDMgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNDIgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyAyPj4NCmVuZG9iag0KNDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTI5MT4+DQpzdHJlYW0NCnicnVdLb+M2EL4b8H/gkVrUNN+kgCCHPLrdRV1skxRb
IOhBdRTH2UjKynL69ztD24lkS4rig2mb0jy+mfmGQzL9Rk5OprPzLxeEn56Ss4tz8nM84oQzzrmQ
kjviJCdGc1Km49H3TySHx4wroeEd5Sys1sSkXLxKcW4F1w2x+0/j0Z/jEbmcnRNSMykOTLYIb2w6
ETNnCLxGjNr9ZNKAAJln49H0S5YsUq3IRUHaTMk3U5OtJS5itwXqlRAtRg3f2dQxE9IQJZiHnTgI
1ezaLrPq0KwxIu43qx0A20A1xAbDGqHWLboui/rQovXabixKrUVbdAVXr9HlAaLlMTrhgvU3s77L
rJn+nuQLQh+Tyddv0daHsxuQ+1UQzyCnN/dgJ5gQYEQxr2BfO0luMiwpG3sCRTT9fA0xWax2W5/H
o1sqo4mmHBeBS/g7tVP4NtRF/5Cbr+PR5U2LV7bmyKttY5iUNdu3lPTpcF3Idgq1Ewx44pkyO4Wq
T6Fv1WE3AXnT0etU3IiwJNKx2DZCLEEj0EF7y5zbxridtofbVyHqZ8n8x6KMNC3WGPD8ruZQw3ct
mfN1S+84L3jDe02k2PdeIN9AJ1CBb3WecO7dadOFAJ3vV5eCWPqmMP07jSzNSQbrPI0UOGjovMhg
fS7yFEDm1aoDnzSKiT11/fhEA58hwjO/RwCzwSc1i+NXfGeXLfjAdF3SOWZ9UxLA5SSaWDoDYOeX
0URS8uUav646IInYMiOaSvohycGQgNrqOEg1yTZIq+K+WuJe+bMrU1BITjQV9cNSQ2EpD6o3OgVy
xeIqoeyRQs2dwJ6PQa9pv6UvMwDckTfgOeSt8Xo/QD0YoOVMxMc0ig9CfbNzSy+KjJNsnj5FE0WL
ReDlxNElNva8SkvYuE+Arx3p9p6JpkIStfnB4OBr9UV5ZoZR2gxtWYo75s2RLasuTBXJEuhPjwUs
JXkuIBjLCOOyIpGnxT2BXga1gr35Enee4GGxWEaOzjsCpqRhMC81rPTDtkPLR3rz2v0/VhB1Sfpb
8R+WAnbnqiCbOnhM51W9F3QUA5xC8Z62fmxuMDarmTgOW01yD1uarUPVJxWePqHsEd/1VecxBAe6
2VPZD9APBgixM8cBrEnuAXzC5IUMvqQkCz+Q4CUC7jpoDVO6qfOQ0KKH0HBhYbEeFJx4KKFFzHFe
PI7QdWE6Sx5xmipDvnH8yFdVmdRpLfmW1/N1WaZhN2zuaN7Fa+eZbdrqBS/50MoQFlqsPqYy6pL0
rFjndwSK4qFYVV3Z5xoH1oZcPwqxl0Jh9lMYCyZgoBbaI3V6U3goLOAKJExDGEp8telFDzhEVvBJ
y2KR5mmxXm1orDj9t0yTH2FkiSaeZiHBii4g1bBXbf8W+S/wWHo6T3L4mxeoVyisigobfoFUetqc
iFLRl2VC5s9rrJSuOdxycFQ3/e0PoBwcQBkzdXQAa8L0D2RA3jXeaI63oIbApPNd6AJ77ybl/AHD
FYcIrzAja8zTCjcFUCskZYY91mBchaEpXgHWeHQmMFzabt9UrJBjdXP9wW0bLW07ySBxQr5Hsq6e
V5em3wFyGioM2m15t4Hp6PN2u+wKprUhmHVVnYF3Guetxrt3mFWYVvR2dCMz+NlzlMH1w+mmiv5g
Dh5j4RJq3g1lWxhrgvSvPE+qdZk8YdMlkZD1a0i4goShZImPi5ys0gy7eF4F8PMu1CqWrOnhIej/
AQcEAa0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5
cGUvSW1hZ2UvV2lkdGggMTAyNC9IZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4
NzExPj4NCnN0cmVhbQ0K/9j/4AAQSkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sA
QwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8n
OT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAA
AAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQy
gZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm
Z2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS
09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYH
CAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1Lw
FWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5
eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj
5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigDxD/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/
AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1u
v/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+I
f+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8
Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fq
T/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/
lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4
h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/
8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/
AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD
+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P
/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/
ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z5
6X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688o
o+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/
AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8A
z56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzy
ij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/
ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoP
AopD0oA27uLR7BoYZbK6mkaGORnFwFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2Fz
eJNJDC7QwKHmkVciNc4yfasopct2/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCx
qVL3RtPH+j6edQmH/La8Yqn4Iv8AU1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx1
0y7H/b0P/iaVU0e8bZG1xYyn7rTMJIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIs
NX0O41bTbQ2F3aKr3diG3IY26SJ3A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVp
XjfaNC0+4c5ljZ7fd3KjBX8skVm1vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOl
dZa6BoekwR3XiXUt0joHTT7I75CDyNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibU
lDiw+zRn+O5YJx9OtW2+IR02MweGtGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS
9dX/AF8zRKjHdt+mh1y/DCG2XOqeJ9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR
7Gq96j+5Fe2pLamvvZ6UvgLwjdfLaeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2Oq
X2mTCSxvZ7Zwesbkfp0NS6VZfDP70Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6q
F0bxVDDLFN8guCo2k9t47fUVheP/AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2l
J3XXujiKKKK6jlCiiigAooooAKKKKACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW
1v4PFXlxlLextBHaqrFcKHxk4PzE9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrS
Xmi6kpJe3G8hCclHXqCDXHPom7bW+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq
5f6bp2ta/aRX1pERY6LHdM7SMBNxgK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X
3MliLM30r2a7ICkGSFIxtJxyPrWboVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjAD
BUtzg1z+jW8nh/wVq2qX4MTanCLWzhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOf
evPb7ULvUZEa7uZJzEgjj3HhUHAAHYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfW
jJ/yLVt/19Sf+gis6u2PU459AoooqiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmm
c4VcdF+p9KrWFlPqWoW9lbLumnkEaD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+R
rTppxc5bL8xNMt/Bj+BZJb2WAa75UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBY
EE4OaX4X6bplx4Qu7q8sLe5aOdzukiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw
9/wk+urppuTb7o2fzAu7p2xXp/h7WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+R
HC7RgnJClQcfhVSxbcZRs4ySuTHCpSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/Ef
VNMvL6Xw/DpedYmeJVuti9yMDPWrt1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VO
crSSivw8jxgEEcV6tp3h/SJPhFJqb6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L
95WA4z71c0r/AJIdL/16Sf8AoRrOtiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1
r1bQpT4q+Ec8F388sUMkW48klBlT/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb3
0IwcnKUr7W1PER0FLSDpzS16BwBRRRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SX
UaMPlHUEg0aTqGr6HIX03WLW3z95Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMx
s64DV4k8fNXhyppHuQwEHafM02e/J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/m
WNeBx2F1LaG6SB2gEgj3gcFiM4Hviq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/D
diqn2Fs/8fWn/wDgdF/8VXleKOK2WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1J
rKqn4Z/5ExP+v5//AEAVcr1cLUdSkpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E
9mtz4zEzjP2aBpF+p4/qa5nxFcvd+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3R
pNG8XXqMuIrhzPC3YqxyfyOa5Iu2Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+
gCvO9J8ZajpWg3miqkc1ncoy7X4MZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZ
XOiGJpqUG+isaHwk/wCR3P8A17SfzFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOP
T6VLf+K9QvPFP/CQRBLW8BUqI+VGBjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2a
ywMZih2Y6deldv431y80SO2ubfQY9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOeh
qfQvinrOj2SWk8MV9FGNqNISrgdhkdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8J
rbWE4aHzdxUAsMZxj9a0tJIPwOlwc4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXif
V7XR7nQLVftFtdgoIdhZlJ6lcVX1WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU
+i8fjT/id4xh1ORdD02QPaQNmeRfuu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVf
a1XtsjGVeMaXs6a33YUUUV1nIFFFFABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVr
xappEkVvc3t/ZvrDQmOO5WFmRfkAVpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8A
hBPEf/Pin/gRH/8AFV8xUhLnenU+npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4Bfcceh
qG21TwubWF74W0l/5ZkkkEBwJIidijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8
VWfJLsXzx7o3n1vQ7bRP3E8Mt8sDi3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gD
KflAwWyepqr/AMIJ4i/58U/8CY//AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6
AKuUabpd3o/heK1vkWOdrt3CCRWO3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQBNZ3c1hewXdu22aBw6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3
Y3EkE6dHQ4/A+ormxGH9raUXaS2Z0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOU
mikiYdVkUqf1r0/RfjHNEqxa1Yebjgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09Kk
L+aOj6vh6mtOdvJngG4eoo3D1FfQ4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoY
JrhtsMMkh9EQt/Kt3T/AviXUyPJ0qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWV
nd3TdiwEY/Wl9bxE/gp/f/SD6rQh8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0
pzI34nk/QV5fqvxY8QXytHZrBYRnvGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo
/wAKN33Yy4YPczOpyrOzA+xNR0UV6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJ
gelGB6UtFACYHpRgelLRQAmAKWiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6
ClooAKKKKACiiigAooooAKKKKACiiigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNDQgMCBv
YmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0Vu
Y29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDQ1IDAgUi9Ub1VuaWNvZGUgOTM2IDAg
Uj4+DQplbmRvYmoNCjQ1IDAgb2JqDQpbIDQ2IDAgUl0gDQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9C
YXNlRm9udC9BQkNERUUrVmVyZGFuYS9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lE
VG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDQ3IDAgUi9Gb250RGVzY3Jp
cHRvciA0OCAwIFIvVyA5MzggMCBSPj4NCmVuZG9iag0KNDcgMCBvYmoNCjw8L09yZGVyaW5nKElk
ZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQo0OCAwIG9i
ag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrVmVyZGFuYS9GbGFncyAz
Mi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWlnaHQgNzY1L0F2
Z1dpZHRoIDUwOC9NYXhXaWR0aCAyMDA2L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1W
IDUwL0ZvbnRCQm94WyAtNTYwIC0yMDcgMTQ0NyA3NjVdIC9Gb250RmlsZTIgOTM3IDAgUj4+DQpl
bmRvYmoNCjQ5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNE
RUUrV2luZ2RpbmdzL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDUwIDAgUi9U
b1VuaWNvZGUgOTQyIDAgUj4+DQplbmRvYmoNCjUwIDAgb2JqDQpbIDUxIDAgUl0gDQplbmRvYmoN
CjUxIDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrV2luZ2RpbmdzL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
NTIgMCBSL0ZvbnREZXNjcmlwdG9yIDUzIDAgUi9XIDk0NCAwIFI+Pg0KZW5kb2JqDQo1MiAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjUzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStXaW5nZGluZ3MvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODk5L0Rlc2NlbnQgMjA1
L0NhcEhlaWdodCA3NzEvQXZnV2lkdGggODkwL01heFdpZHRoIDEzNTkvRm9udFdlaWdodCA0MDAv
WEhlaWdodCAyNTAvU3RlbVYgODkvRm9udEJCb3hbIDAgMjA1IDEzNTkgNzcxXSAvRm9udEZpbGUy
IDk0MyAwIFI+Pg0KZW5kb2JqDQo1NCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9S
ZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAw
IFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUg
NDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn
ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNTUg
MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz
L1MvU3RydWN0UGFyZW50cyAzPj4NCmVuZG9iag0KNTUgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggNTAxMT4+DQpzdHJlYW0NCnicnVtZbxtJkn434P9QwAKD4mBVyvsAGgJst93b
g/aO1/bsLtAzD7RM2eqWRC0p293/fuOLyCxWUayirAdJrGBFxpFxZ6o5fdP88MPp6xc//9ios7Pm
+Y8vmv97+kQ1qlNKaWNUbKJRjXeq2ayePvmfvzY39HWnrHb0jo2Bfgefm82nHkupoJUboV389emT
/3r6pHn5+kXTDEjqeyQPIAvNqHMXfUOvNd7Wj53xhNCcXz99cvrz9fLTyjc/rptDlMyO0kkhpHSO
Rc5ktT5A06tK0uVOG99Y3SWCZEYakA1TZO19st7rPE/WRZJLJPVNYMIOkg4pximK7j7FkFwQisY5
fUi5WtleuYpFDCqDicjUd2TTFFl/+svy5lPT/rY8+dubReHh+XvCe6Wb1NGWvr8gOkxCExHbJUtw
F03z/hoWFXJqyIZOf3pHOvm0raCfnj75tTWLE9cq/NL4xY+n4ZT++jYu/tW8/9vTJy/fH+AqDBjp
aXvfGTOg/WvbzK0RpySrC7qoO3KT1FlfF3RzC6aDawRRyG6NWabySMOmMbHLYaRinU3nbeNS6GIs
Oj7stffBb1nr/7u6ab6+fvGyWZzEdnl7u1m4dr08h/I/E0yn9p+t/udiwOZIzSZ03g3pHxFJq5FM
jiTo0lgk3QUdGudsZ2XFH5RK8WzMANShx4gmd26I1r5bnNh2dbuw7XKzvFs1n76stneQybQkML5s
vrGRNZ/XixPT0peAH5bUWtNZO1p/XlA9EtQ3mvbejB2EQkAglo3vQuhFff7ykKi+y2mMHCkujnDb
f9yQqFe0f5f08/sKkob2/PbL5SK0HyfE0oHcdm+debnM/ga6fb9PlsXSir+Y3cF7uFrpfeSWzHNx
EloyUePb8+VNs9C6vVgWIbUi2C2ePlwuThIpgAz5Er/uFlk+rLakAcIm0JqRyRKw/bAGXd65oI+m
vVnBEFZT2nLKdCmPuZvXln2gtmx2XTaP1NYQ+bC2riHWcvv7wrcs8pTGLklVUVQ10MqXmxt2pfMV
3GW7XW7+nFQQMZTHDM0ryB1wkwNOYmOiJHXcScJ9Hxmiti+vv8BDEA5IJbpd4k/7jXcdX1xN+Umi
2Dtmoz2Zejf7Tu+9+3F1ARqX5KE3q48g6ltslMFGnWT54m5Fvzdk2aTlc/ZfS0Zs2zXHqglqImMw
Xaz+y3GO0P59AawTY9vz9c0WQYHAvt0ClmTRi4lFDVk45eXRsvP76B9q6LSfOjzW0AfI7c83lzD0
u7/cbtYf2DJ3dkuq3CzJXCeks5GlG642L13Yl053ewxSHgODlkqeY0HPjDFt3Mdsn2NvllsE7vPl
Ff2Gaf4Jg/DtxXrD5vCJtvIL7XCJZOzZ7MeuRR7A37sFdHKiY/sXWFpzSy9t1qinPjDiRKYztlN5
zNC8duJDtWOo7EyP0s4Ak3KZiLddfiCBoJqVOAiJ/48Xb6c2nWpdv7fSlAcbssC89y50DcVuVrA6
CSJEnkl/FE8jRVNgJSAxJlm4ZuO78lc2a0rxVFug/RhSnVd82lN8vlclaKqDoT8Iv9P8c31A8weQ
o0VVMERu36wXCT6moQ0S5u6Ky4wVpY0t9kRMzihKtSX8qOHrv8FP8fI5tAKd0ZufodE1mfl2IV8S
3Br+tCEoftblL33jXL92olgHc67U76Y0G2Ln8liQec3mB5q0yRRDHmPRA0SxCtgW283DDTp2No0W
mrZniuPjVyfN+Bx83AL+OCOmSjLaEalZTZv9hiDf63HEhE3yVEAfNeFwyIKHuO1/rsWOyDCvYY0k
/wmEQ4XDVubLt59hWmtkTBiqJZm/3AJ0i1cBx6t3ZafsDsSGeVORJ22yKGrI2rym9ENtkoS2s0nI
TRnlGNPFM4s/L84c/fGBPjr68Wce0FcMdensBC8pe3YS6a/FAILeNM/k2Rn5HjAbz06Aal6dnRjg
yBKEqk0h4KMsLiQdSL48G67PHLwaclC/oVKSKT0PshRYcVlYN0LQewFXJt0LMIjPggoGrTB41I9R
41JMGarsyP7td06Tlk5VlwqPtPQBbvsTO2sQW6y2vZSAjd9SU1CVv+ZIO7L7U9j1Nyr/ERaKa3zA
Bw64n4rV09u3PRAr9L6xnSwvbMbIYsTovN72e6hJvXndmcfqbYDbPvu65hIDGmLhm+v1xxVHQoBE
7u3tisQ8x1vUjV7yWOG8QVAVxC2azpKdJjShPEYKI9LzmnAPLLKNDShwH1dkD5Hbl5sN1ZsTfQ4F
DbX3/mRPRLXN3qtSqF+sdz04qvaLubI9dDqNF5nX172mZCpiGjscwXxPGh9gtn9HIqlDmFKuX6+W
1Kd4Bn+in4svpWaVevEbzOtzLeNv+jpS0jP5KjnlaoN1pXDfsLY+DRH4AwZcU1MLm3Pn9JjVeb09
tN1BmxgfpbYdYvuKZKxlxl0tLzZSGkrf8rEWKLUS+Soqae64MsQrB7sh0iN/y2rtF7le3tDHSWWR
Nzo9YnBeV/Ghcz5NCcM8cs43xG1/WS2/rrjI+LzeNX4XV4hQf1x+uBxMAaHPqVmNsa5LYbz0vKhp
bx59f+BSJI3kof5BS96rsyfGwZq2xebvnwcP8TiYwR42PNW6hD/d/CaTLVR4HuNBGZ5MldEahwqj
NWfFs+ph0y1t+WTmMdOtIWr7rDRUaFOXHB+2F6tNI0M+Kuv/5O5rMp5nj4ZitOK8ePcq0ol8pHXq
tH9kPhoit69413hieQfJDG3h+mZmuA2BhgtMJqjourhH7N3bZ38/fQeLefvsLRvIh+XN75OdjwqI
HKMV5tX30FE6Du7UscOQSfUNkNv3m+XN9opTC4daViCiCM/Rlx8/blbbLX0Ohyblur4wpQDiNtsx
wXkFPHQ6juGrfux0fIjc/ri6knErGdDXaU9AEtjDnJfkXmVGC5iDOZPszIejQ7BO7WNL4hxity/J
p7/Cr6+ofv8irXxsebKdW8pyOPaRQkM+ra4wUQRGnz8jFR+wg+v1doFhMyeTQNU7KafMVHV9fcMj
4ymdWer4bRwzOK+zWp1NHFm66DttG2c4HOnEx/RWdb6/bOCab5Mnm0fQ3x1iKBzNb94YnAI7Sp1R
hNSgHPDbEAR8jyFyyvrTl1Udv3M0nj5nDCohdw4oHFNjPKJGCoLGN1nxIT9i/J4WJxU4h3hQf4fO
vL2JqDrhiyp/h8b+g4MSmeKcqhwsbrD0MVXlI6oyrgsUwJLhdSUPagKSHR3V1hHcQwpzg8s4mhT7
DbLRYiTbb03za2jIl5p/kazNx4YIGCxpjG5IUh8UVsbTFS9+8JZIzc/3Ve6p7SV8bahSy7wgVRPk
LRRFg8GSPmoqVfjZyrPIR9upmOZnMJHQwztNQVrWoIIGUc5UjPqtLxgXh7g0+243bhmclFsm0W77
7/E5xKy9nuA1/XpHnviWDzInLzXYzushwSN25ewBw3fe4vhP59A3ErBptCIP40JH5KAh/jwT7hAT
DimMSv20G1K9X2RMgqg5ohRB9C/6HlKqR54JI9v/iSp5NRfzPcUD2uzR8vNM+kmLdAn+YnF8fI0n
J/ZJYTDDeFziwxEKRTBYBhjU92SPlCn5mVyIPM8kjJcYoHB4qakPSIkBEUcc5JtUxfcA1POWPMsI
gJG1ZeJlUX7Ddy5UQMryhq5sBFnCVT6tYyJO1iRJFDAUDhsLgBgCo7kQ8V2ILEosbwSMFuGc4jmO
KhEbWHhfXYnzG8oeA2SoDB6aeNKSZRmMtkgasgFZJRp+gfxJF/k1K8S7yistkWWepgoKUcyMUnil
1o52wSXww8+0OLhw/Qt8SQlcBNezirShg+2cF05JF/QcKqMh804Rf8pWTgvA2CqKIk4D6aE+u8RL
xlSp0HoJhbzqXFEInnIJYBClfC0WNRWOahXgSS5HxbyXgOvZSCxFM4l/3rNpWKrVxCC9h5TAcHV9
T5olES1qU1NWoRzKHHvSIX9nsQcz/NT87igTGwTYAEdgH2FSjsoUU+yGtwUA2mA84VIhPZH94Ul7
DujE7rnYlNMMMKZaHV+9YQMudpmQA+Bo5VnjBV2fXSdXdWxv+uS9DpcKXfUNks0pThMFYAAIOFou
7kQMK49zueKzmdSucBWyAkyQizeh+myQiybOVZ/NkYdc2VcAxW2bU2/VESctliJp8hWgAfCd5E+2
atyjsfhTjAWbkzVspgDwguot1GExCx33AFqSdGh75yPGLUnsTbVpkh23Qnx1PotbIoRXXmDDtSEX
g4Bb4Pg1+IJB6TbTI+5u1meDiVWosYjcg/SIEZbpAcSvdWQy8ixyOt2pVAEaM3lfN4SIkedZLvTK
M05OKfKoWAGGAJTmfagAHcWOexRol3bd9HxWQOgBYvop95IkXrRsakhClu8RFQDqd+LL6qqcwnkf
Q+Bcrro31KlwqO6ruhCFiCruvtq6Axrq4vBbACmyhm3uIyaOj90gpDrDe+TqrpOQFpE2VjvRxDhM
LlfTgqxk6CVBwPiIKjmT35knuucIsy0GzKaTaxYiQGLj2/mAhcmb3lwz31fIrkZ2chsvFh59dTQ2
+YjdKwB2ioSbm8U3yR6dUhCgem9kT/Ox+rfP9RJcCQDGsbdq36e2zP5cvABSOnZ4r2uQgX/Hrs90
SSJEcDXTMQJ7eYlpxnCUKepK8AIEoUqCD/URpQoTpCdrGFBsJ7FHAVDSKbk1l6rDHEUwr5kOOTSi
K6kqSjyvtUDk8KZ5qDQTsPfHpPfOnHzkxO5UvUt6vxr6VU7Svp5+5knF9dTtL5/E+4j7OnJBw+Qm
r4uhKodnofSpdaUcWPEpYbmfEdrzu0s+v1jz2cVEA4YSNY7Xmi//8qEOUXOhPLoz+N+v+Woc0f7j
slyDO3AF7vCtFa85/yDy1q7wJxLozb9NaUSi4fD9WSG8mu8iPYVBQzGQCmOtnJj30fZxEulQ3+j1
fMcUNEc0g2yV661wVENE0NkGhaiut8L3wdI7vXj2pp4ryBEMPr14Dwv5RZ4nLILKXko4hqJgqMp8
Tf3F0W4nUCWHRmWIOL8L465R8+X4PUsIVLNRaMDspx5w/DFFH9l49OY8dbu/A/emj47SCpW71vHE
6KFtK/8HR8D/LJzPH74iyiF+75YnMJCmBtyIZ7jWt0MYHsFO4PjEMlD2N2Oc+ZNabxSnxSHevD4P
Na9BBupI6dk9yoz5iqjbXRGdMVzNSQ0Fh3bfIWnAsYEe481L6nczH4Mil0eYmY0gU5MwMAWZAuUm
IA/1YyCFoZChvEW0ouIcZSSLTUyBfNjFq0PaC5YbEW1MaXWC4xwIQOA8D4CVNwgfT9yd8jwKT7QQ
nhLaikDRFKeK1MlbK8halreoWQLMTxp9YgJP2slTFmx+C22/jYJteQpCAAfStpOpmovyEPiJKgNG
dqhltFysYuTArTeFBlcAkZtzk0uBF9DIWhkJBAF47pGpnw8FQNGYu/ecK0PoK00uHQpkwICTiKRQ
BWaWa/cOQJBZmzQTrEEZZdj6HKTfV0LEZnDM/X6oADSv8m8aV7JpXtZwtRgJVPdHTBpwhnotz+jm
aXXNBoJ4mD335lKNBW+lWY/9G3zxFf2+MgLgUQAA3tQ1MJjBn1wByvIbUmqCLEUYLJrLooqbd+ek
aA4uywu6UnVJ+Bq05oG6GnCCWrxIE1mLVIsX3hNmMjjjy6YCqF7loUFhJKADACDqKgzmELk0hpAW
eqcly05BH5mJys6AkSDekLipuhYANpxqXdmKwKlDuvPyDI+gZlIGPmAMeZ0ALlaANYziC93IVkdL
5lgBmHZhptVvbzAIxkZxoXstAGLToL1OQtnCT3F7WUpWsEp+BIAthLhRAIo1FUBaxKKup2NRf+C6
SKUDlRsTS5+PZ6xqXTWS4PhyD5eiRQPyXDYCGhKEsuEEkBVlVAI+KfqC5E7tvCmGjEbHygVinYvV
uwlAPmFoE22/ERWQKqCgpN3WyKLG94S4VTNkxskKIY5BJujSOGK7yhu5jr4PFf6+TmrYfWVSo0ON
qLQWRjG2Dwn4tyvNCRJPWiY1Wp6MTHGopCghFY2Ydn2QMrV/KZI7bkt5UmNq1Kqjmh6QhsMaBDr8
5yCGNX2wNDKr8fUZPKtd1OJRHw9rbHVb/Keeql0nALE0iLp6OviiFrLaHw9QMKwpwdLzBBltqNU1
emCogbF3D4iJW1kVa8Dh+Y6tOQIbwy2QTPrgxc5x/5x2bh15WKN6x0cTRN1njXscR9EDFBV7qT3Q
ileHtNzn594m8D8+mDrkPvoYHtZUNuV/HvphAgeSzOMGnwZWj4FE6P0E0wXn66KBp82ogFwxYAM2
rO8d3EBoS9ko9oBSxxhXY4LCeCaVCQUAmFBgkGkqAINMVUcDzGgBxApgFFPGIACgZcJ0tBe2lk9D
4Ykv3wcei3ENRbheXSxY3YDEe+Z8pen55ALKKVxhBwyrr1gbbRGJZCWklU3E0C64mjW9DGNok1Sf
3qyMa4rjeCvdcBykNx95XON78/OZxzXFcTwfN2JcU/lQgpLK3I6NXIaF0VQ38Dyucb3jZM8dr+od
x2a28ZCqryUj45q+cjEy1NzVNiHIuCb2xU4Z1/jq4c4PxjUcA7z4a6wAY2Vc0xc3QaY1faDhEVDs
SxnDsxWKEsU7na4z38q5hvAINKHWNjZJJOpLmeg4VpXsQABlOZrJbJXDp0Szoj/LZwp4w/f5Qf6H
C3RKlrIyrt9VZXz4mIqsg5j9/1aP5s4NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NiAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0Pj4NCmVuZG9iag0KNTcg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTg3Mj4+DQpzdHJlYW0NCnicnVht
b9s2EP4eIP+BnwZ6qGW+kxoCA42bFC2aIWsDbEA7DKoru+5iy5PsdP33uyPlWLQt2TOQWLLM5+6e
493xTmRwT66uBnejN68IGw7J9asR+efyghGWMMa4EMwSKxjRipEyv7z4/WeygJ8TJrmCNdIa+DQ6
JeX0GcWY4UxFsMnPlxe/XV6Qm7sRIQ2VfE/lAXDQaXmaWE1gGdFyc5sIDQAynl9eDN7Ms2muyauC
HNIktpr6tSLGU1vzdJLzAzo126hUacKFJpInDp6kHtRQa9rUyn21WvO0W62ywCsw1cR4xQqZNjXa
No1qX6NxygSNQil+yLmcyWfnMk/RsBSNsF77Vq1rU6sH77LFlNBvWf/tfa+24foBcLecuAS29GEC
erwKDkpk4iQ8V1aQhzlGlEkdgRgavP4APplWm0evLy8+UtHrK8rwg+OH/zowA7hqant/koe3lxc3
DwesMg1DnnVrnQjR0P2Rki4Zto3ZRqCyPIE0cYnUG4G6S6A7KMMEh2xldBqVRh4WRNgkNZGLeSoS
LYlyJrG29vHhrN1//N57/Y98QZ7uRjek17c0Wy7LnqJFNkbnf4Vn3NFPVHzqNcyM3CxMolVT/xFK
nEWcFDBIXEQJsk+mgigI0ZQHkVeMOTuMLUB/8BiJ6atjJL3rSfrhfUXy+foROWWrWa8vabFoIcRT
lVgVy+gmxCNCmnCzQ8jYQEjKRNhnQtc3hwjp3Q12aZLqGEzv12UOtGB3HK0GPU2/w21K8zncAkvt
SZp2jkLpRLpYZjdHcSpHJJCey7EBpr9iGGL8Mbpo3yyooVBmI2C/ba1WYGK8NivHGOOC0xn4s6pA
5xo9W4WH2TSbtfowlYmOpXW7UO7Gvdotl1ie0ULG8NId+PtgwXfB9LYoSY8LOsmA2HyG4fKIWf6j
NfZ5AsU4ktHqzhSqmIrXzosvOSbXI+kJBy4FVVW1zuGbpmVRrMAYTidlMYcbFkzJp+Bpmo1/QNTC
OkuXZTH2QqqqKFt0K6sTG6vu9r3a9T1PdrwHvQbIks5ije9wPWBFjNT2AFJY6AAE/HNIAgNXO1Tw
mMlh38JVwSOlsEmAqzu0v7ESAUVSu0jJEcb6VMZWJfxYlT3MuIGkr7G0riFzwtatcDeXPdx1PLw/
b34gWKHGORlnS4jI7DN8zOD/sb6u6msQgslv6BNWsizcYy0fgSpD/8IVo5f3IO4FAMgCbgqMJBTh
T7IxakCLUOCXtkByHIM4otLtV3NqFksN/tVnZnET/JzFz9nVmpEi4TG0K3mhWYzWVksvfTybzMak
Jxv521oBGVTASEa37+ypMakMNCtnZWGMFOlQX2EiDvviKmQbk/6PCczAkU9KBT/Lq/BI2mEfIeI2
QNjtJm+5lxBSGVdswCjnZijr5OaY3XWyb9SiPqX8EhXEqduoGkB58gb4QmEigOYBZw9rCOWjb67q
chJMe64yL4MMF2S4oKXBYSvvJQob9tWWWK1ig/I26SbzRknzMrwBJjzAZdc6lD9fBrf224YEHJPk
0DQcs7GR4X2Nt37FtTlemTRkAKZzIwqOhKQ7NSShVWKd2dwakjGyIySl8UR9GIqwF3iMoNNMA6LS
rY8lG24iV40wklEKRjHOgOEqnZesomAOu7Bx9rXfhsgsE/wfIrE1bmUzbo9vDwyliXKRR6Ltibu1
4D0Bc8tpZ3x64lwhUmh+O8/4trmiiaT1yCSwjdFYKzV9gk7H+j5L0ymcPOWxWUOINDEmlttJUrAT
+3BhbWLlmX14E0xvSjzDFW3rxbhkOEREmNZjR1oYx+O12HgvJtjpQ5N49+E9nNbVL63+gnNaxfhu
f/FTj2th4PDsPHM6jusmmC4L32gvVo/YqOQwVECQwIFq6KognyFE0roVn0J85G2diYBStiO4m+mp
E5qf/c6OjAaYvlnMoOtawf79tESOGCeSIsM+V0e3ErLRxvK6+Z08PmFS2bN3sgGmVfYEBPNBWTe1
RRlGmTtki32ohj5U+Ta0j30oNrg4wkzqhm311e92lf2NYuARjOSTMJCtV9ialr5gQDPsH+b/rvJF
5UOjtWJoONowA5pmdvttb/Rp9Rv8AjPGmX5rgI/4beZneu+4h3c9R0VbhDgQGQtuPSyCETxNsas9
xSt741HLYcFhMpDHnHLwsGgiw+By4wvBDKvC4ls+xrNBdbyHspAgaSymm5M5sQJwbfAN13kVoAmm
12WRfUFW46zy45t/JyWkv6tf3mSPjzDA+VdVT+PlumrbbTBO7IjvpmtPpSu3UfH/6TbAdOQnzHKR
l55OIN02HXGnIXwjfDefvVa0LVG5kIkzZyZqExw2BFKT0SFZjn0RX1cvwnkFdcwPgJtQxdeJUKZS
WozHa6xvjmZ+2M78xL15n1Mspv5LgMzD1I+w7yHvF1+K723DeGqTHQO7PbbX8UHzLg6275zDqCqO
veVI2C46NKFNNH3w3RC+ZM3L8D4ZSnjuOYfjsCW+uUNakag9dv8BXj+mtg0KZW5kc3RyZWFtDQpl
bmRvYmoNCjU4IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hP
YmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAw
IFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9iag0KNTkg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDIxPj4NCnN0cmVhbQ0KeJx9k09P
8zAMxu+V+h187JCW2knsJBLiwAYIBBIvVOKAOExoTCAG4s/3F263bt27dhe3dWP/Hj9JoLyF4+Py
ZnI5BTw5gdPpBL7yDAENIpK1GCBYBPYI3/M8eziCD/1t0JHXNS6IRuEE34tNFaIQ+p2yl6M8+5dn
cHYzAeggaQ/ZU7xiBkomMOgyYNe+GstaAM/LPCsvl7PFnGH6CX0kuyWN1yCkFNZzRkfUw2RskT4Z
sgyOTNRMaoo6WBnCun0sM6XDWB90rtWkDNKAfT1plxiGiH6fKNHLimi9pz5zCd3GXGxGFEy1iNDQ
t9g4hOXyevaxgOJtNr66Ha01nFZad04QjW5p9aKcBkEKcSY6zftgoVrWJ0pSBD1D5cW9erL4aVMX
efZY2NHYF1gHqkPzWUqpTy7C6Amqqzw7q3pUSUfIhs1srO2wHws41CMMTdY29IGMXpNoHLcN5VDD
2NtDVoZsexwUlXYctuBkx1+bdPeiZtVmvza4/8rup+8ay6fz39nr+8gVPx0Z7X7+R/PWGpEubVf9
gMjIJiYtIzFuaOY/qW/tbg0KZW5kc3RyZWFtDQplbmRvYmoNCjYwIDAgb2JqDQo8PC9UeXBlL1Bh
Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2
IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIg
MCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NT
ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1
NDBdIC9Db250ZW50cyA2MSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NT
L0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDY+Pg0KZW5kb2JqDQo2MSAwIG9iag0K
PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MTEwPj4NCnN0cmVhbQ0KeJytG2tv20byuwH/
BwIFDlQR0fveZa5nIFactEVS+GIXVyA9GLIiO25tySfZTXO//mb2Qe5SXEry9UNkajWvnZ33MsXR
WfHdd0fvJz+8LsjxcXHyelL85/CAFKQihFDGiC40I4UUpFjNDw/+9W2xgJ8rwqkAGK4VfCpZF6ub
BosQRYlI0K6/PTz45+FBcfp+UhQRS7rBsgfZ8dS0rrQsAKyQPDxWTAJCMbs/PDj64X56M5fF62XR
x4m1nMaeEaG19vs0nNIenpIElqKuKJMFp5WBldoiRWxVji3fZCslrYfZCg37cjuVhbKMBe405qhz
HMUmR2WEchyZELRPuZTwRrnEblGRGoXQlnvL1uTYyqN308VNUf42Hf94NvIynFwA3htamAqO9OIa
+FgWFJjwynBYF5oVF/doUao2BdjQ0dtz0MnNOiy9PTz4WLLRWJQEPyh+2K9H6gj+ylKP/l1c/Hh4
cHrRI5WKBGl4S1kxFvH+WBZDNHRuZ4Gg0LQCNzEVl4HgoFCml4ZyCmlpDApVJxpmBdNVbVIdU6Uq
MHBUNQlK7nfbzeUPVu1ny9vFY0FfFu/PR6L8UIzGupzfP91NH2+XsLAoUP+/lvTXUSRqqmpWMRGL
sGVbNMQgUklj7YFr0IkpwGwrI+F3g3YKNiqauCIMGClvIDhHu00gFCMRDSM2SOCmQeZK1ww+jWFW
L541VzXai2ctZKWAfod5gHHMOzCevYdx7DsggRXjYJURK73JyYM0nPQmIwfSMNIbfJjWlWaDfALI
AB8PMsQH4mU9vJ8AMsTHgQzwoYZWUg9ZR4DIW4eH6LGOwITLygwrLYAMbMaDDGymBn/UcpBPABng
40H6+NDiS9bpwWl/KxqXggjCdXHf8DWmqmVxd3hwfnjQeFUD5BcSIK5tLvOuB0CaqGghhfIe0kL5
hQ6UM+8Iyi2kUN44Wyi/0IFyphVBuYUUyptGC+UXOlDuZCMot+CgGK58sdAmVZtfSNSmiUwPwC/0
6lZJ/BPp1i2kUN4eWii/4KA2AzHtJBjKkuQiIKTDJ5RFYD4Y2DF8giHZwBmeXRZ5P+Ll5O1orMrL
0RgeX52NZJIF4ozB67qCHYDmuPIJYzZ9AITpFWScW/h35/8++r9zJLrOkEMF0pTccP5hfQUDQ2eJ
N/uxfD1fz1bIGUV4gB0GcZajMSsXuXwIbgSOllAalof3yKOw/BVdea5vQYoF/LMK+QQPOR0rrro6
RskXfhcWf3U9nc1xK3kiEFPAjEE3tfBUrpdWJcUNnNdTkGT9mKNg6g0Kw8oQPcrgBjIpt3bDha9y
mMQCWwBxCEiE+SKnu+qsc7LEYvLJ6w73b8sc0KZy8qO9fcqZFxbLLGa+bQuyr/ZD9DqlMjn72Z4g
iHIFD9MFSPE7fKXSyony3l8FEVc5DROsJ/cRr69eVqyuOtIR5Nr5eDES0TfqnjJy1XBmah+59MDJ
S2hdqD/5WmHsqQmWcQxO2p18d7U/Ll1gNfsObd5+PxsUqLeGlwaKuligbduq+6INoZXSKRX0ZnTR
NURBaS3Snrs1j/w2cq4rGa2gx+IQRnjg8OXz3AUuT3V2B4wsk2nOuqRRVv8xmcHtMtJnXaA0cP9o
u9ipClNczMDOstFHO8eLsSzGsAB0wIyIbsNQR6env1w0z4NmwfrSh5DWzBMGw2L2BX1JsT1Jqdjz
+fMxhAE8vE9pAoCTXM1R9ptRPknKWmFVsYeAfYE4HGRMJRsAIC2jp+zOsS9u+pNjCmqrZ0T+ruMA
ox1OuC9CCoXddyTItt30hTPJgQhNiKBIuTODytjwPVj2BSx/ZDEROnxiu/PrC23hwKiqBO93tQvr
b+ejXbyN98UT9DZoGRIeg5LyvqCAJZ/RPZLeXkI9A0Hx0Zc462yQJXYoxAjD2tFRuPJhHKsMidtT
+PEyfONNTJ+i02KRTBk8zz7nIzlUchSykUa99kfy9TxXgElj80CCPayqvvAWjChW1TYr2v1w+EYb
UhGWzrm8VeG4izyvDpDWAnl5efoLqu7iEkvCyU8Xg5L1xUCc4kEgiETZtr++uCadzSRU7jEd2yrw
doQloICILsrrp5Eu72w7NWYKjh4rg0XXWnraNwntJNg3lVBr0F2SHnfGmBrT5nZ660fwBBxWxLyG
laK3H7orShMVETsgdp8vQCfN98EidI+zMsMtcbBDCB1M/f/5CEeupx8u8ftwFOyLtEKRippYli2b
E32xVBKCSSahsn7yDS/+s83u6hH7ElWuj0DpX+C59l3JCmOYA8kHMI0FHEVzDBxcwTJbjkz5B9qc
I/Y1R0HXmDYTCsM77Yv3PoglO90SxPbQLUsMB9hAwO3M6gnEcQbHxkNBtOes/jtCjD7u8XsJUS9h
xQzEvoTVx/KHBUYVTGx/e7DntUSdX83xYDHiQG1pJwN2KvAyoxcKZSRP6Q6rJY3tEt08FVUopxVh
Ku0owjZPTvu2mboiFEdEJ4h9U6jMNphtmmPc4W2I7jbgLNN9GOb2wRWWJoMbqbvHRQmaRoJbfsAd
zKFGmuYGE5RJO2iKscYbaUH0sOMQOGRXVMmOJf6hx2P8K94cg13gwoQQ8uYYHwk/Hhv8zRwr/AUv
Os3xWMfgQsCiPh6LFk7AV+7RGQkwyi0g8om05OUrvDi1j2ISuHtcTypIEKQMQkccrIBAXJwgI7fe
bOpVQg1lOFHH2mNy7tcsdxrjKYtTO8DeE+1ezPkjhTMKjvJlBYn8FryNl49zN4MycMK6vAazvbY9
HfTkWDrCL1x40LWFxGmQ7f6w65uDH1/bMhMBFs5QdHaAxRirUkmGbV3ubOuUB5J7m3qLWr6+tRFo
Pb26szkGjb74efIhZ/aKYv0VU+hafXw7KkUC+oT5aoEfKzv8UOWd5Q7F/ljY7598hc45TqUxOpKy
+LXMKVdoTMIti/3q0lzhwiRPJd/3Wjd7XcsgC6b6H7YGtdUaKDX2SKEE3NsauOqglu8nby8nF+/A
6i/P/oF5imDdi1PbMdYirgwm7pT6DAfwAehyYov8d7kbCEiZKmE7rAS9qxK4qZ+rhAjVKuEUdvPL
RVDCC2eRC1duyRA8VPnnozPRYM43dh7/woFwbtetsu7X+HiEjxCJhP/ugK6XED9WA1c2QUZtKtUM
8BhYKM7jqCHfZz2QV0QleBYl77HaDo0aeKSOnim/P7KvhRj7LceOMfvaR4ye48SYvZlIONVIW3+P
Cq3B+W3IXc9HtdfSW9Da2TdZkxIVS+kN25TZNcxyrEWfF2Yj1PJ05APf9Aq36cKedRk0pZ8nuNls
zMXS2STk8idoI1cMulekLdAKC6zhhoIuVD4RCxwma3shKTh8QoYIwbG77IJjrupn0L5Cg5EQ/qui
rqpEcpRbrKPutBObJ+wDjhSRcfS2B9mA06JuMQ4MRxenECLO7dTkDM+MdSPy9A98diHZnez9cuQf
29O39NYPWMLMEJbiLdwYOsBZzq8gExqTCDuoOUl21Zxgz9Zci7qD5s5th88yals/PSD2Q1hd2Sat
cYz10ZdiNXK5zbXLcx+qc80yl3UlWSLjsMLorgrj5NkKa1F3UJgdiUMsuLQak3F2shqb/j7iAQO+
o9aubcR4CLaGwA3W/dSXzmByLmtmFIfvEbBE1mHFdVv+rOKoebbiWlSruPsnHPd2A6nTAyuu0Mym
C1TF7+tQJHTszdYHtgpGzOzFPVPu+pbumM4k31RGtyUCF8bMQGBnJq+OBlyzHnB8F9i2j9CZMezM
To+xa4OWFjoz1wi6zo2FfpH7zhKxbJfKWzT/syUoXUvIfGNp2s7RgmjXI1LSEm+pacf9xNEQkYyy
R0bRkredpuXjUR0oNKWICG03H2g5Oxbj9MVq+85GuCdAW3AxOXY0Kssre+/rbIUWj0tMv8YDobXc
tCF8/ehjEZZCTfzxhidk43H4z4WwXGQCYzKphMNGJbZ6mLMpZnhDcncX8wqLcMv3t/b1ixv3xoX0
PnbbaMVGkeLLEnZsfeguSneLpS/Fr9wrJQFn9rvXVq5B96VjIsiwXuSuetH0+XqJcEuIx9QGWbCR
cPhT13W5jX4Fo1IQguxo8TOq5uu6KQdmFhRUNB+ZjqVIb0NWUbOg1rYzcQcAUuXKTS+sIlighu7p
FKz2mxf2aszJ8oADF6T6h5+qLL0kjgscKN880Jm36+n6M37/e+74bMJIJBg+vY2WOjMTxdkC2VL5
9w9FY8yBl0de2tkSY7l3T/z7BVSj2uDA3R3A1ndqePmP3FyDE4bVXCLfsLI2Wu+csjjDhPUcZUWY
4QJ40txT50YIlFG8wEuQh3eyc8PHmL3YGdhKn8e7jq+Dy5XLiTKeqdpp5qnLMLybGMMcF5IOw8Eo
FZiOcC7qRsBvfB40IW/WzRS2ZdCMY/2QmB3Hy2EsHLFyQ11kw+3vzdA1TGJF7b8w/0srRDMqdlIq
n71lPOfdJe5xQqtU+VsOtN51KsSIecaBugqwg8tpO2Lnye5ru91kFm9H99zN1u0xWFV0B+Z2JI+1
CQsKt6pjuOCKLA71DetcAcguf0/Rz/VVW1ZFNwENuzDxz47xB8dQtNb4NnXQSSsDbpJ37i+iywph
kGXrESfOpil1kiEY53Ep2Jn9ewtLRJbej2BVRzYekNuLBgQRbPvdxR63IHtcc+xYQ3r9GvgjvQ90
+oerdvBqf1kXkBnsk820Pl9j4zFdjaLGrplchuYWaDky9w9t4kXw+/niEVdyr7KxWuB/OEqEHHRU
RXZ1VKpFQ3Pf+W2MCyWIKySbObTXSa/2UkXZMmT9NG2LyLjC6vTCVuduplt8mkPuumraO1fA73Yf
6Dag7P8PbO4DuTcqH0u9pTfL3nqjm7E3sZG3PzeRumv4niBpDbh12r4QFjliN3w1DnKSBn7iYUKX
Z+l2k09fnqN0p5TBdKUSxW2xRLqzJUoaH8Z+lhjhJpV7t/dHG6LlbAW18PS/WNB9De8F42BuHkzT
efOiBehaMVTaUCP+5l6yR+v1lB9DG2VJhcgAZtvGi3Z80SW6l+kKgm+3Ngkhc7+85dL4L0oj1tbZ
K8eyW4ggVnzb/MqKE/tZyzGuoqhP38kYAqmhLNLVTRtZo3WYHc0Z/zepSrS5xZ7ZjtU5BUcJr0jm
zLm/Oo8x+6pzCK9s4C0PfPEopjC8nY23VXIlOqXPSRSuRI9xy/O59xU79KzLy9OfnMdBT+xczvWi
mc4Zr06wlW2vtaPZcetlwQfXn5d3dtqeHUWAiMKkIg6rbOc3Yyi0fsMqy3c1HVxbBLtaNyp7o1KM
p6VpKItep6+lRM6IPoLlbyiD2SS87OH9NC3rmpDxKs2RXTf3GZHTiHuTTzvse1i0L8tsabLEq6wM
EJyisnx3K60xh4TXipLBejsNiy7hZ+0AfjmSSeHiABauJslNcXTVYTlsdTu/o6Lrlua+jhrjlue2
ILPTz6M4ra0fl3a0NFYhl0nt56743Q0MMYHe39pJSme0mLuMYNzghWEiwoZK/geeLqEoDQplbmRz
dHJlYW0NCmVuZG9iag0KNjIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1hZ2U2NCA2NCAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNjMgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyA3Pj4NCmVuZG9iag0KNjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTQ1ND4+DQpzdHJlYW0NCnicxVhbT+NGFH5Hyn8YqS/jFZnMfcar7UoQWMSqqJSk
24fdqjLEsGmTeGsnIP59z7ET8DixifLSBxx7fC5zvvnOxZDBNfnwYXA1vDwj/ONHcno2JP/2jjjh
jHMupOSOOMmJ0Zzkae/oj3dkAa8ZV0KDjHIWrtbEJH940eLcCq4Dtft3vaPfekfk/GpISM2l2HK5
Q7ny6UTMnCEgRoza3DJpQIHczXtHg8t58pAacpaRXZ7kq6f+2hEXsVvH6ZUQO3wavnGpYyakIUow
DytxqVRza9vcqm23xoi42612EFcVqSG2dKwx0sCjbnOpt11ar23lUmotdqEruHpBl5cxWh7jLlzp
/tWvb3NrBr8kiwdC/076n6+j9R5Ox6D3SRDP4EzH9+CndCHAiWJewbp2koznSCkbewIkGlyMAJSH
YrN00Tv6SmXU15TjReClfBzYAfwa6qI/yfhz7+h8vGNXtraRF9/GMClrvr9S0mXDtUW2MaidYJAn
nimzMei7DPqdNmwFyKuNzk3FAcKSSMdiG0AsrGVAcO0tc26N8e603V6+KVG/zqaLJYn6ior35GoU
KXoDT56m89UsWU6zBUH8v1H5LaptNYRaMqnre3gjLMGDuDSRgsU+5E7MLNrUihld2fzAuXcfwy2U
oEBoNlQGnJQPtel5nmeRpXlLEM4xz32o0m+RhUBj2ZCdRoYu7jMSCVndL9Mcfu6Tu7TFihSexSa0
0g2bCGAzBAw0UNOmgg3KqHpB7fR8B2rCB4rWM4nhvyrSE7IEMuTJorhP8YbMor6lyXPaBqGEYgJZ
XbfRHY9s0ECYJr29YFZ7omI4HdlNg23lON5Spp8iDcej6Az+MLw0B3oLOK5s0RKVcIY5FVppI4bw
ksUN2dENuDn5dTCK+o7eYJ6d4ApmnKe3yeKfosWYUorphrFuPNXeeEIdcofC+apLx8iOGUCaLFMg
O8QkFf2eFcvqwdNkMskx5LQAoQLfixL2DG/pwwrWTblQnUIo3oKLlhKyO9hHNyx6b1igZxh/KC41
ZXoG+09nEBty7THN37cRxioGHT/Q7Q7GNINRTMmwJQgH5R3oY6EWvBGMbrZsoUxTmZ4/JhDODPm7
SjBvUqhyjiYLuJ+QKKaTFE+zFJji5RGzSni6/J7i6zkQonwuUniDomjAQu7lWfkIT5wuM/IIgN39
WPG2PgN7DTZG2lBdBwH1UeyXOXbfyipjGCsOqaw1RXoFwA0v/hqNT8a/j9piiBWzIlDrDsHty3Lp
YAo8tJjWlenpdJ29Fk9R4eW9ItUJYwan+WM6OcZU5/SpXJ6DcIElV0pafAeRbDWbYO5regukAO4U
yRyM4r1QNMGSAT17Mi+VQCoDToFa/oTWMLkKfKwKz8X1Ty1gWsWZCffexp1NnDDT2L1w93tTR8YH
UudVsaJOmWRv0Mdr7Fp11e4w4h30acSx4Q93+zSP5jwXN5XpEDtHmpSzBTaL22dSsWQK68uyUWsK
M3lJBV4cVwftgErTJUxyL2+BXaIgd2hohf0EuGdpxbGLaxBqY4XWcMY22FKTFZ25IGAO3K9qS74v
SbAhCH8IS+qadZqcnJ3hh9TN4AqgWa9dAUCXo2HbHGcNfCyEBrvDE/vWHqHFwYNHTZeeYyFZYYOt
Jg+sIVJv6kUye0qei6pgYI1A4R8zLBR4ly42sx9qKQffNgusRCjPq1ozgOdNweqvKxYIQoEhVZOD
NSxwKxyMv0XHJd8664mAocVsBmucDvAP58AvcC6aXqLZ0fALpsHP5ScweuTVfmHGehmuFhlJJrin
ST4oE+A+a2M3hwqgA8fdh7j3NC64wAHswFOsKUMFwENJ8gr62+dyGEDgq3PDQ8LfqgYY/N8AtI3j
zXC5KRYNQUBJlILkDpYSKAnrgfKtLrGuB8EOuyHbe+D2nEl1aM+tK/+vI3ewkS1k/gMc9TgFDQpl
bmRzdHJlYW0NCmVuZG9iag0KNjQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl
L1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVu
dCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpzdHJl
YW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a
Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAcwBj
AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF
BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq
NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E
AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR
BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG
R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz
tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A
q2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/oKVz1
fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir9lHz
+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRuAiKS
T+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf+b/4
qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v/wCT
GnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD0SZd
hP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1xNpV6
33IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTNZSn7
0kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2ELj/
ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP3QW4
A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHLfxE9
OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvbue4c
nJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+Zcqd
dtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy/P8A
Q4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQHFza
TAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6TSatc
qMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8ia77
wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaareW6/
dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0NjE1
ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvBPy/I
5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+RrptW8e
DWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr/o/C
OQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1haNb
yWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuPDlr4
3k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8AErQb
6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzCZG05
llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5Pqeu
fWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4HtvC
VlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/Ix6Z/
19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3h8KM
J/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVnTScW
n3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2YPn8O
v6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7WhW1q
qz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41WOPl0
a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j/px+
taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+EYVv
NVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVyx/M1
FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxINd/5G
HUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzuH0rn
v+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O/wCE
v8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9/wCH
/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/9A/x
F/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKPr
lf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNeQ1r+
FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0kPhR8
7P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54c8I+
GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+wzXov
hXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNhbacT
MzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeGrLWh
ZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dvrGCa
WOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u5ma9
R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+Ho8a
dbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1ZtLXRb
lr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rmnR6X
dardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/AK/4
P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0XXv8A
kYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm7+HO
hC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy952/l
SRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRng05Z
5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7elKZ5
TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHpmmxS
yQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5HHRP
+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19S/8A
oZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f/wDf
9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmfib/o
O3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//AH/a
iij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCEz8Tf
9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/2Q0K
ZW5kc3RyZWFtDQplbmRvYmoNCjY1IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jl
c291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAg
Ui9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0
OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdl
Qi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2NiAw
IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv
Uy9TdHJ1Y3RQYXJlbnRzIDg+Pg0KZW5kb2JqDQo2NiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj
b2RlL0xlbmd0aCAxNzg5Pj4NCnN0cmVhbQ0KeJydWNtu4zYQfQ/gf+CjXNQ0h3cVqYHEuWAXmzbd
uOjDbrHwOk7qIo5TO1tg/74zpGSJtiS7ebBkUXPhHB4OZ8SGt+z0dHgzfnfBxGjEzi/G7J/eiWCC
CyFASuGYk4IZLdh63jv54wf2jK+5UKBRRjmLV2tytn7caglhQehE7eGH3slvvRN2eTNmrOYS9lw2
KEefDnLuDEMxZlT5l0uDCmy27J0M3y2nj3PDLlasyZOsPA0KRwJyV8TpFUCDTyNKlzrnIA1TwD2O
5EGp5ta2uVX7bo2BvNutdhhXjNQwGxxrirTu0bV51Pserdc2epRaQxO4INQWXBFCtCKnSbjgvXLr
29ya4Yfp8yPL/p4O3t/2izmcT1DvCpjnuKSTB/QTXAA6UdwrHNdOssmSGGVzz5BDw+s7xORxUw5d
904+ZbI/0JmgC9AlPA7tEO8mc/0/2eR97+Ry0jArW5vI1rcxXMqa708Z67Lh2iIrDWoHHLeJ58qU
BvMug77Rho2AVDY6J5UnCEsmHc9tAjFYy5Hf2lvuXIFx867dH/4YUL9dLZ5fWX+gMviJ3dz1VfYR
n3w2X357mr4uVs+M8P+cqc/92lRTqCWXuj6HA2GBSOLSTALPfcqdnFuyqRU3Oto8FcK7UTqFAAqG
ZlNlxEn5VDv7ZYWhsb7JnlfPLYHkuOO1T9UGLbIgPAeXyk7XaH72F+uDyxb4d7P5Nu/rbIMDPps+
4t/pou+zNvfSA5cqNdmNIyQ4Ggae78CoTcQR06rawnh+2QAj+ETRei6FrytmV6s1e5guF8SHJ7p8
b8PGeJ6rRLcVRuu4yBPR5eoeV2qOHiSGDzILDissBzZbr1ZIWZc9rFdLhoIumz/2bTadfWcva1rn
WZDdrNabNs5qyXEP1v12Qy13KAtmdyvi6llkj8od97KdsjWyNYhLN9J4MxJ/gCtl8e4wpavRwOG4
xmet6XTBu8fxq5E5ja+B/ugzfOfjO2PDO+NGqi5iSESOBjQYRKMJXXgBexpdhymEwWCqFCfPRhUz
GNMr8tbEpz2AVC6RjEnEB0BXR4OOidV1p4l93XIFKt3sOpLsFTdvSILEJjyFvs7xCXS2LKlFj7jV
py/Tr4snZN4CX7zij+7zTRRQIvt3MWXEzpvx9Zcxpdiz2x/jS8wCRGEk9uzl2wIt3LcRFYsRm8yx
GzLdcOyUIOGRaPxRVsyxiUUpycG/JbPUNUNqoX2vad+3JxUPqVp7VgmnYiK7eSHrM7yEfPKwoEQy
C+kkSTBtyTk3eIKmJrsxtEeTF/A89m9lb02ZSibKmTYQFeHEp3Y8reZKpfqteGLtY3ZkNy9z2g20
PYj1DwFEwlNZfCAon3D4vhVP5znWIInJbjzdLp6KK5kWQ+CwsMGlAu46MnDAU+8Wq6DMrnJ2QwiO
rymyLxjQePIBj+/hDQI8XuCGdhkOtIUnODYAibXu8PzR4TlF5dYbw6spF+HhwoEI8d1Nzia/37H+
rj3dYE9iXqIA08mcw1GTkVpQLZ1MZtdtJauxVWmY+N3414tQWWHimFNyDYUAjuSBmzgwW9DIwwJZ
qbBEWK9X67BBZqTQ7E27nHvbPrP9ddut0WFn0YwKuBsXQDhsUO4Wx615Qyo8FOwb80ZdObvCxSds
VDyatsfV5AOSXQeytzPdYx4xqb3uAOFopuPtUF5sJXqlG04XKiT3t3M8jaXL7hcU+Gb69YkOBDzu
pckCe/CQBsCDnJTwMJfQYOXLbd9FMz8z0UYs+ragk2l1o7RXcLahBHm9tv9/KNV0d1CqskLH0svw
PaFupDumvXquca+AVxzaU0r9UNqTVjbWz7GM1uN4oxr1siqDQyWtq9L3KkiVNTaWUKE4DrW3bUJT
7iUz6+rzOICCPg4F7IykPR6GVFxiaa7zImTqC2Iv4MMI1uux/A/dRdVBlB1GqO2py7gYDYLaOAjo
snswo0EN3RLrwui2VTHRVyJUvjRlmzMayDr0qrBRrkiQDB2JiR5ssXS1abtWL0HQxmeSPjf11mak
GgzQlzsVPBas2GIliq4KtnM6L0z7Q9GGeUA051IahvZpHBdnz3eBe9HaFVw+i60YxFsBYB2egNpZ
rUOLUDU3aSn1rM2JRHUuHeCyaWg3SgIb4Pqo2kceXSoDVR0dtc/OIbcjLvOquTYVW2n9FH02tREw
LSmP4M/Rp9R4Vz6OkbwSBZdIiQZJUcm4KYoGvuQGiLCyxWKF9Q8LpqvOu+rMbWytdbFLIzUCH/Ji
ZnbLqzAJXTbkJqUCCeTlZpaxuT+ySTd0qKTIHVi8o+tygKRXbDipmgrN8qRKlVXxYQQBijkhpPgQ
uYQqvcc8dRW3Ib6DPGaZuESRDXGl4kK5iFdMmfVPKWEbHVXaxr6mPt19/P4D8pwsBQ0KZW5kc3Ry
ZWFtDQplbmRvYmoNCjY3IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNl
czw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFn
ZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+
Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn
ZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2OCAwIFIvR3Jv
dXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1
Y3RQYXJlbnRzIDk+Pg0KZW5kb2JqDQo2OCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl
bmd0aCAyMTczPj4NCnN0cmVhbQ0KeJydWVtv28YSfjfg/7BAgWJVVNTelwwCAbFiGy1iwKcx0Ie0
CGiZknUiiT6iHDf//szMkjIpkbSqB9Hk7s7t29mZ2TEb3bL370c3k98+MjEes4uPE/a/8zPBRCSE
kEoJz7wSzBrBNtn52Z+/sDVMR0JLA2u0d/B0NmGb+Y5KCCeFaZDNfjk/+8/5Gbu8mTBWEykPRLYQ
B5leJpG3DJYxq6vXSFkgYNPV+dnot1U6zyz7mLM2SepV0rAUJGTiSztjLWWLTCsqkSaJpLJMyyiG
kYSIamJdl1h9KNZamfSLNR7sCpZa5kiwQUvrEn2XRHMo0cXGBYnKGNkGrhR6B64gE51IUAlP0l/F
xl1i7ehTup4z/t90+PvtoNTh4g7oriSLI9jSuxnIIREShOgo1jBuvGJ3K/Qol8QMfGh0/RkwmRfV
0PX52ReuBkPDBT4kPuhz5Ebw13I/+Jvd/X5+dnnXopWrKbKTbW2kVE32F876ePguyyqGxssIjkkc
aRsYItZGO3Y3/cKl6OMdt7GLVQQHqs6OOPUqmTQQV0z5KHENyGWSRDH4sYoSWULefogPh/+gTbjN
F+stGww1V+/YcvE9Y6vBUPHFfJNuF/m6pl0DbakjYety37BEioYpBhQHvZuWgFOCKVZHzgeW74WI
/bipAcIgm5TaRXHcpORLdKIFPtAiepkPNEej0NZ8zQblfFE8ZwPD33VYqpTEfWsw77dUNiy1TLo9
S8FTyVLQW+idpReXbZba/Q33PnJxkxjs0HyGVhoO24bbt4WRDHZVST7b5HiwVjACAzH/QM+/ACHH
080cV+NKqfl9uv721wDePdHnSM8v4OlgeQF4IY90iYQ4VRF0AGeci6xrKtoPnNp3EbMfYBIZSTg+
RonI6Dd85IBYQuyTtkHMX8AFpEBv8eHBBsrz61u0+Sc2iHm6BVDZANYAEIa/PGboPmuWAhzTaYYI
FQUbaMtv8H0S+H2FpZO7Tx3IaCci2dSjHxh9NDDCRlp2A7MPRXO5+iiEMWMLr1aCQ7rw6iDD6LEU
+K5xBfz18BfGzUWY0/U5W85fjYdEP6E1Spa8rApzHr8TeI8Dj6TkQfS4xoZ1OI5rrBgPUU61FudL
3rLiTfITUhtJpArsTBxISbwP7MN4UA3Xa2CvEARYoz4E1Y0am2oIOGsdhsXVThPt3jekkuKTYJzx
tAR1VR8CNa4W7ihvxUwNibK+RW94iWnxEtfqJjoBB3wrxh5Sl15Tp+YXEBKeMVqwCwoLUvJpCt4P
8VUqCLNLjD0/KPbA1Gb0QuNFvspo4GZCyQZP3lc4UZOB53Bs8MRpiE7wMsPzl23oBGIYdxThDN9m
XWHHWAiQTSXZ4F/EB+0tprZjELdH5jQNdWZyUk6rU/L0CQx/wiyWp9PH/YSFFdkeE5AN5UaTSb9F
7sjcpbWK9Km5q07Mr8CmfINBlfJStsF0pfimY3uliaGQbbIYdq21Diu4xlpMlesZpTYI2Z//AOlF
V+bXNrKmSd6Pnj82TmvA1Z+awOrE/ClfIGzr7RLPRlYUCB6dnm3O7uGQJXRsYjw22+yhy9QYSkLX
5Lx/aPa1EDJyxwWm+EinUrGJYnmiU9WJ952KNn0B8QUD1c9P5F85zt5TjaTecgQjI6OaEvotTo4O
xcoBmvGpobhODUZDzbah+BrC6vVXGJl8uO0yC1JLkjR59JqlDmp4wGUv4HhSCzY0dm8YpZqUELb3
KPFCCBt4D/uWrmF7vhVgzq+UHIZQpK3RXPL2a3zewudPLERHLOvv4W2JuQOZrLDan6bP8CyyB6x2
PS34waqlQQLOWOL8DL/VPaQ0ou+KRlCDRMo0te6HUB4LoYGb1UkIvhLyz5go4YcXg2X5C8YX6fcK
mxG8bDKMHsUW8AnRl77ZyyNeI6jgDbcHj8HEVzep7FeCb5qviwUg9VAt3iwQzHkgAWGzZzp6hkAt
WSMvdE1briHCf7YV4CivWFTqdN5CjcE7f93kfvQPbhhd6CvImOYk+GuUgMxqBWaTbz1UCC7LDVlX
cNEo2YneW+1XaXg5va1G4OKhd3tJI1BRDROePsA3bc56h/srEYJuwv5uFtPtwL1yfWyoUWpcEw7R
pL5PRbZleFwaq+Y778DSbPrYauFTdV7psezYUhf7KE6aMPbv6dGXIwW545hQ2x5pa8T8qgqzLVe+
GMJWV7x1kZRNTv2mHVT0Xe4KufjEeFujpHABcUH/+7ggWwND6StVoJWhBfNc0RJbco0iZ9+yDEnQ
SVhROVhwHnTX4Ma4toPFfTU0C3l/Z0I6Kw9VCE2MNquu7KJi3xVlnNfYM21A1b9vB/eCLpeU4O09
1/Vej6zR7jnkNSJZ+uPoBsybwG9BA/By9wl2R0MwXtN1akZNMKgMCWCZ1DoeKV3eyrYIzDwtsZii
eUB51ZUToV52De36wXJHOrmEbfBvHd9WJ69TAkSaEHKAEDjE5A7N/xSsh0oQwzTGriLFumNXQHQW
znDFgMK5IaHf3IM7Qpe5TkSx6jPXdJnbpNRirMsmhplgTwPfQwND+/BXXYXeB7ZS1K5PEtooE2qB
ULPnclx2PULvxtOMVTva0PUw1LYh2itaUc1IE6RdIPfWJkjTHKy3m9Z030lKyw0kj+OyxrF3Eqlp
f066ktRo+STEzzW2MuAQTdMCXetdmVfR0zRdU75nNL8qP2vtXPzEtvVQS/7yuKAyQFet2+83k0tq
1+bT6TMG7s7uiMKmbF2zfpzabjLtoQxgODW51mh5ep9vIG2ATa/3VgpRnf+LUDLG/zrVmfTapA+u
MZ02CYG9pBONqhHzdb4N0fZHCK4JXM9zurIX8BVjBsSIu32k3ha1xqgpBq9K8Hm+ZThRQiMg72EZ
uH0uaPrn0FvL0qITIziVEXpzXacDkP4PSmk7Wg0KZW5kc3RyZWFtDQplbmRvYmoNCjY5IDAgb2Jq
DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUg
NSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEg
OSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDEx
IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJv
eFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJh
bnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDEwPj4NCmVuZG9i
ag0KNzAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTE0NT4+DQpzdHJlYW0N
CnicnVbfT9tIEH6PlP9hHtdVs9nfu64QJwi0oioSd43UB3oPvmCSlGDn4gTKf3+zawfsJDYcL2t7
vTPffJ9nxgPDKzg6Gl6OLs6AHR/D6dkI/u33GDDKGONCMAtWMNCKwSrt9358gAxfUya5wjPSGlyN
jmE1fbZizHCmGma3H/q9P/s9OL8cAdQg+R7kAeMS0/KYWg14DLTc3lKh0QAm9/3e8OI+maYaznI4
hCRekAYVEOOxrXg6yfkBTM22kCqmXGiQnDrciYNRDda0wcp9WK153A2rLPIqmWowAVh5pnVE24ao
9hGNU6ZEFErxQ+JyJp/FZYGiYbEPwgb0F1jXBquH35JsCuRXMvh6FVUxnI7R7jMHR/GTjm8RJ0Bw
BJHUSdxXVsD43meUiR1gDg2/fEdNpsV260u/d01ENFCE+YX7JTwOzRCvmtjobxh/7ffOxweiMrVA
nrG1pkLUsK8JdPmwbcy2DpXlFMvEUalLh15rJQ2MJ9eE8y7f7pA7JygWVN1d8NQZZNxQXICwNDYN
yQVTlFv0bqi1leaHq3h/+6/wFa7yebaGaCCJ/ASXo3O8NWSe/UonkSTreZ7VAmwIzhWN68CvcOGs
QUaB4LtklKBcKVDYCIwrfR4x5uxxM4KgBNtLvpjGrGlMLpBGZMgE+XFGHi5HPsWQIVdknQO+SRaR
JYtIk8D6YbLcFC10JRNU8Kb7br68wVcDd9Q1Q7au5Ms1xcuW7+n5Ab7cNSw5wx7WMCQn2ZP/iIBk
VnNfQsWdv3+cpRkEYnAMy8kyUmRTfES6MUmyG3yCuafuv/d67uXJswLyyWSzgmQNCQR90FueTSPZ
YFxXp4xHxjJQDPGU3u5T8NaP+GBJdpOjj8c/WpwIgXR400u3xGInpVCPeEdjjmmKeS+toFJ159Qh
ayl2rclnFC1fBQWRliSZ++hljAZckzXepQUm1rrcsmSON9nN3Gdh4gvKH/BnY5LftaWaNFTJJmi3
DvKADuagDJr7LvmqDOagCjXjSoUy4wYOc0SSIMbmd6WGKDfWUXVikmTbW7+XL1JcV8m6TBC/NZtj
vhZeHImni61Skvwk4zx7CqbfNhPcv/sZtXUl/8vbCbVbO/Vm7SSj/L3SvdjuKvc9XySreYHUP5b6
SPZ24bhoKmd2hTvxjmd5u2C+geMcUQ+wWy/9Zr2Yw3p6r2A1YzLKMZ1I5r98uso+le0aq232tExX
D/6dF6wIRSkUKWZe4c3ixj9y8k8K003qVakkRctkmuXFusrZSWsucV+AjVC6tTFvbfnCaardO1p+
3ZCcLJc+FfJkMoPIkVsUIKhRdXls+D7L/Jlqp63h4OzEZN0394OC8auwLswPzZ1ydOgWw765OQuj
/Kj1junl/7fyGtY1thXft1IsJuzPVT3NQ6K0/KF8vLLpo1sEtyuCpFI048LR3MelNOWvtRe1O/Rw
43aNyY98VfgswKFHMN8PkBh3JPyBizAIhXJ4PnEXpoWFfx0WPBKXp9dFuvC/udu2vEF0nPcb6Hty
/AePjAe7DQplbmRzdHJlYW0NCmVuZG9iag0KNzEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1h
Z2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMSA5IDAgUi9GMiAxMiAwIFI+Pi9FeHRH
U3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1h
Z2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MiAwIFIvR3JvdXA8PC9U
eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl
bnRzIDExPj4NCmVuZG9iag0KNzIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
NDI4Pj4NCnN0cmVhbQ0KeJx9k01PwzAMhu+V+h987JCW2kmcDwlx2AYIBBIflThMHKZpmwQan+L/
43bryFi7S9q6sZ/XrxMo7+D0tLwdX00Az85gNBnDZ54hoEJE0ho9eI3AFuFrkWdPJ/AmvxUasrLH
eCer4whfq10WoiO0e2nLkzy7zzM4vx0DJEg6QHYkb5ieovIMsg3YtK9KsyTAfJ1n5dV6tlowTN6h
i6T/SMMtCCn6bZ/BEHUwGVukjYo0gyEVJBKbpATr+rDmEMtM8TjWeulr0ymDa8C27jQl+j6iPSS6
YN2GqK2lLnMJzc5cbFp0GGsRvqH/YUMflsub2dsKipfZ8PpusNUwqiTvgiAoGWm1FE6DIIEYFYzE
rddQresT5WIAOUPl5aN4svpuQ5d5Ni30YGgLrBeql+azdKU8ufCDZ6iu8+y86lDlEiE7NrPSOmFP
CzhWw/d11ha0npRck6AMbwrWXlvjoJpPC9LHaoeuckEruVBpuabSUZFxz3ENNT3xW0fpWYLiut36
3X2DD8MPzQRGs/nrz0eioB3tP5DVTgWXkvaF9+gLrEKUNHLK9M3kFyfA77oNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo3MyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Y
T2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDgg
MCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBS
Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAw
IDAgNzIwIDU0MF0gL0NvbnRlbnRzIDc0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3Bh
cmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTI+Pg0KZW5kb2JqDQo3
NCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjA5Pj4NCnN0cmVhbQ0KeJyt
V9tuIzcMfTfgf+BTMRPAsiTqCiwWyNppkMUaSGMXfQgWCydNjGxzq9Oiv19yfNkZW5qpnT54PHFE
HfKQOqRgeAkfPgwno4sxyI8f4dN4BH/2exKkkFIqraUHryVYI2F51+/9dgLP9G8hURlag97R09kI
y8XWSkqnpGmY3Z/0e7/0e3A2GQHUINUeZMJ4helVFN4CLQOLm1ehLRnA7VO/N7x4mi/uLIxfIIWk
fyAN1kBSRb+OM6BSCUwrN5AmCqUtoBKBfomVUQ3W5WBxH9ZaFdthjae4VpFacBWw4UjriD6HaPYR
XTBuhaiNUSlylcQtubIK0cnITvgK/QdsyMHa4Zf58wKK7/PB58ty7cOnGdn9rCAISunsnnAqCAVo
gqDYgjBew+yJK8rFAFRDw/MpcbJ42/x03u9dF7ocmELyQ/Gj+nPohvRtC19+hdnnfu9slvDK1RzZ
YscooqlhXxfQtofPRbbdUFkRNG2IdrUhc23Qwez2ulDYtndIbae9QNPYrtqp1cnYYFwD7RFdg3Id
rIgKTHDC+zXn6VO8//NVlYXJ6AzKgSsm0xKLq7eaO3X3DaLAOkyH52ojO0yaV4xokJ7KqcodRaUS
AmgbQNHBcJoIqip0oysG/qmc3jVmp9utpyl31A6TiopXN6tX+cAZ0i4KxDWV0TF6lJpFyYc1k7u/
roksTTE6/1baYnR6maFROzp6vo7RxaPu4pEkDEFLIxxmqMyz2G6bJBL3iNwhMQrnQNPhifYoEpFJ
HM3o+0uWRMfs1TC6SNyoJyNihbvxgzng4K3MkNc02fKWtUmSZhOCQGkQYfV1ZLlVTE1npdPFaWl9
Mft1mmOMVIJafg2rizHXXnZI58dz41QcfsUC/tey67JNMuhTkmoC2WkR/bH0PZQDX2yKjTtQTvzo
1DawuugL2YLj6LFN+BIF12qTpGu3cSTkDtFy/36f3D1w5/hGb9syDAWzma1EQ2fH6AMEUMtWKl2H
9mXYbDNLEar3+8fO5GMqMt8le6tqPB2PeRC6yhJI1gdon9Yt/FX6f5D2tdokmcPkyfWCBvz3ad+K
rknpiovpKHtyaVCIBwifrg3amZGJtv0OcK3Ifw1fCQZ+hx7KCIY+hMCvCnm0h8eKk+TFxe6OdjvD
SCRYDdHRQK2PmusWjy835UAX88dsG9WCbhA1iC5u3J7PSVUJVB+SkrbZ9PVumXEB/aov1VcPcmt5
0o3NtTfz5z+y58Tw+N5Y3h5dqsVoa3ngNZoPQmc4OlI4qrk6G46kcLC59vb179xqGnjdjh/t0YT2
Bm69FJYSqOkmSNMx8qGu3epzvbvFLHn49/qQblSLJcLomPBAR3V7uA5cPFPreaDPX/T5iav9lZRh
+cI3yBt6uysH2OCpzqmjBuCpD1gKJq45ZWGZlqy+JMFv1b3oJGfOU6BqmremBPOdzBLXiu5WrKx7
uUiocHZ9KgmoEoVtg+RS1YryGY5g/my5ZG5fmPPccXCKLeoY+ePgqKG5nbWc2GdKyP0LJSLs5Saz
kcZKgEjW1GajbApRCauaa9tT2HEb49GCkoHO8oR72G2syzaZ2o7bGFoqDkMyS/Or+l+G5FybrVS2
hpMg8l+7eAi/DQplbmRzdHJlYW0NCmVuZG9iag0KNzUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJl
bnQgMiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIv
SW1hZ2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMiAxMiAwIFIvRjEgOSAwIFI+Pi9F
eHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMv
SW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3NiAwIFIvR3JvdXA8
PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQ
YXJlbnRzIDEzPj4NCmVuZG9iag0KNzYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMTg5NT4+DQpzdHJlYW0NCnicrVlNb9s4EL0b8H/gUS4aWfyUhC0KpEm266Ipso2LFgj24NqK
m21sZ2Wn3f77nSEpm5RFJgL2UMUSR+89zgw5Q5WMr8irV+PLs8k5yV6/Jm/Oz8g/w0FGsjTLMspY
lpOcZUSKjNTVcPD5BVnDcJpxKsCG5wquSpakXu7fyjJFM+G9dvtiOPhzOCAXl2eEOJT0iLLjZcOZ
0zLNJQEzInnzM2USXiDz1XAwnqxmy0qS8w3pYmIHphNLlNEyt/MsOKUdnDJrKEWZUiYJp2kBT0r9
kkOrQrT8mFZKWsZpRQ7zMjOVRGligTN1GfMQozhmVIVQhpEJQbucSzO+d26mp6iyEkXkmv1AW4Ro
paV9MwXT3xlheVoqMr0FbA1LCQMf5gw8WUDCkOkqmEbjt9fgluW20+Dj2+HgJvlSrcnH02syOpHJ
djfbPW5Hf5Hpu+HgYtqhTTnaGjVCKUB11dwkJAaSWxCQUaAYqSWVimrNTKG3hAQ0mLtJVVZqTzb5
zyAI1oCCk4/GeanSPQTPuiDQBTCBNC8ZXIuCudyU4h/LDSnE29zGwHC3xi23sbDcbQjNwpV0WZTH
YActg2qh29EGXbWRaRlBNoMhZDMaQma51L60yDz1/WKHLbY7atDteIPuGsD+k2M8bFCUEw7GhTsd
2iY1w5aUHpOa8YbUe13j06JMD/AibQXbDFt4b9Tgm/EG3n/d4MPDQyrDTTuVrcGe4jiVrcWBpDhi
KU1+B6dhx8PzsAadE4F3ioLsIyKl3suCXHY8zGUNOrko+YkX2Jxgb/mbmAVXlGRlsdETktwPB9fD
QbPazLDFdg04gg2YTju7H4BhninngbGkrqVZvY6leWBJjZFdhAcj+8A3MuvJMTIPPCO7LA5G9oFv
ZNLYMTIPPCOTiwcbc++bmFRybMwDz8jmwsHIPmiMzDZpg2JSwgsLvnWwsHe+ifV0UXiCzb1nYnPl
YGMfGKOj4lK0qictvNLJeSokJJTK04zpYkUxr3W+3SSTXTUSySpWvMqOCpjD/EoP9IkKSLMOFCa5
dpqLcv1kRaa0AwqaoZTzPoJYV2HHVqbwUc42q1W13sUl8Q4w6C7TopePhBdJCg9SaGe7ggmbOo21
QcHm5/JsdMKSUzKiMrlb345UUs+2cN2NeFI/QirMd3itK0eoOyla0BQaiIOAp+YkI3F3QLbA//jw
sKnhL2qpFgEBHFzAyh4COhs4G2cH5HLzowKv5MktemIzksmKLEYnPNnA/Sojuw14iXz7Bc55qEYn
4KIfd1uwwuE6oFUJqbvWZ2vNuzLbhJyXILlJyQsMIhmVyWwNehZklCefzj6chmLGYbV6AHEVRThk
LkjfkD1fQNeOY0PmgnxCBVW9fZjNK+MQLrSSjf13jwbkHn8ulxjLu/WSjFjuuE3/mt3/wjVwtw3F
EUhVDw+yrs2uiSO0xqpsZrCeb/RqQylVXetkgr5gDslY/wqogWM1lAMfKC6na8NsAuqi9I7o8yVE
dlsP5VJHcrWpcaFhhqOmef349auJndy7KSBNYpBUH2lde3cjjcMW3qC8xwzisEdkSfXvw/3dXGcU
+gl0qeQn3tZwL5LQ5ikBDrW5qCdB2zwVLQVfZ/PvwFU85QNFoc3zX427QETyNaNwaN3XQkzVA792
BqQrxgwfRLKWFnnahouLilQOD6V31j5fQqR2eCjnsx2UghluNfBn4booFF4G7hV9tHTVBquFFXA+
alAmayxLTj2/Q1FrgrW+2s2/mQR+Qh1Ueap83Li6rpphM4jBoYPmTbfCuMTPSVxy/CPFvl85HjAd
y+kVLqyLiW5Z3lx8xLtpKMmoXjQO41O6u0qNTTIP5fPpJETKyhzT6vmkvKs8NKF0Uc6xOEDvgaHS
28v6JYQSd0V9N9ObDd5+x02nXlf34CTo6KrZIrQMFZe4BfUQ29lt28hSlaoGxYsThkkk1+E4Ka3C
fT+uoqt+NHFyUfpuBj0kROqEh9JE7dBkBLpGvRKhAQgVMplmLehQsVCwjbRMfza9a/092J3SVLI+
HoiUCZrDuYB2psLkw7tgGnBU4L0bVxCpCR5K3zToISFSEzyU48UbkIBfALJeXogcEyiD0ybvisMf
F9fTMX7zfgu/QgFRJZ7uPJC4lMhZwUP5MA6dTlgBO1LehzNyPPBQ/t+F6EHHF6Jn+uyF+HwPiMj5
omApy1nLA19wCayJrp34Px85nIR22A/UtzPsr0MNK2MKp+5hxpVFjhoeyufJVTAfwA1lH87I2cJD
WemOvbrfLF/qU+D8Ae8fIfpUB2h9f7eGlKj0KsEHt/YfPK90j7/YYCpVv+kFRbDyNpfA0jYqlIRe
r+mjXNZvG/vpZbZYvNRfH1YVjjbnH3ecwE+tcolBhdNQ5LBatjjj/uPj9zM4XCV/z07eXY1a36CK
o09QokglRDMV1rEZHLT0p3LzQzdtDJdYhheKF307VmOGns2jYjprTAnbknAon5qRDM3o8LlQpgUD
RC4NIvacgisynd8kVETBuwoAh7XLhYenoY5k/gdpUVQoDQplbmRzdHJlYW0NCmVuZG9iag0KNzcg
MCBvYmoNCjw8L1RpdGxlKFZlcmRhbmEgQm9sZCAzMCkgL0F1dGhvcihJbnRlbCBDb3Jwb3JhdGlv
bikgL0NyZWF0aW9uRGF0ZShEOjIwMTIwNjI3MTExODQ5KzA4JzAwJykgL01vZERhdGUoRDoyMDEy
MDYyNzExMTg0OSswOCcwMCcpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAUABv
AHcAZQByAFAAbwBpAG4AdACuACAAMgAwADEAMCkgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBm
AHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApID4+DQplbmRvYmoNCjg0IDAg
b2JqDQo8PC9UeXBlL09ialN0bS9OIDUwMC9GaXJzdCA0ODA4L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggNjA1MT4+DQpzdHJlYW0NCnicrV1djyy5bX0PkP9Qj87TLYmkPgDDQIIkSGA/LLz7ZgSL
Xe+FbWDjXWx2Yfvfh0dN9fT0lMia7nmYW7o9JZISeQ4pqaqn5W3fmmyStla2lGRrdUu1b61tmWnr
+0ZZ/9c3annreWPmraeNe906byJ967SVlLZetlK1Q91qlq23rVa9ReWhu/56ly3tu/7khH/0R+9O
u/4katrgLWX8D/flgk/UHhL0Uos4dW3oD1ftnlSOZO2hepOonpRUYCGI156l4Vf6U2uG+C21jMHp
T9MBYZSps/6T6pZ3SFXpea/opcNOucEWbeh4U85bzqIq1O5MUJhJGxVmis4Rq0A1JXPHCMqWRdBd
JRe9EbJ0NPqJGpcro7vqqjoxiVRg0wlMpCo6hkMquTd8whvtgk9kI1iXqGoDw6GiHsFwdNbUNapd
LSBSXyVSL1Efs7URF9Wln5JgJjhrA7Oq7qOiCpOOn8q4WSVXgRyV3OAHVskNN+un1OEvVskdQ9Y4
4V316PRvPJymVnLC/AhtnIdDijbGzbIxoifpjDBpnOA+DSC9uewby7i5a6PozWouF9xcVHLBZBaV
XMfNKrnterPex23crHJ6gqsLQhHO75vsOjfqfG1gWuquUY051IiRjDnU+yQjNtTTQoxPaBNG1NWi
jYLQVywIhqxRpZ6UAQYpCNGqkgtCoqnkKogmldxws2JDGgCk0qULPlFU7IhlFVF2tS4psAqiKel9
BQqThkXJiB81V4eOOO1bIQxZ1RTG/CjWCmPIgJlgfjR0imB+9KcU9VVSL5YKBAwM6pSkrnIa4KA4
1OhDmKscGKbxvtVdUaK31F1nBKCrRScrq7UKGA1BRV6tbUBiq029mPX+ikDIirwGxGT9abt6SNGi
8EZMq7UN488ab03hoA3a1AgVqJ5qVACtujUGSFRWU1dqA/SjQZlVcSs7GiqwlIE6JaMBPxVYddKz
oqo1RqNoo0MguEnDK6sFfde4zwq4vuvgsgZ5R3gpaJW4AHVFVc8VDeUpUmhlDZhOHQ2lLBYAe1fS
SmioHAELKvK6ukARrnLqjobeUzF2cGEb4FeBTYMg6329MxqD7nSyM4Pr9oIWWG1QA1y8IzSyDEpk
MAkYbkwXjVbBxBUwI5SDs5QR4AvIK+qILBcWBecwWnDZIMzhMwToPpwGdO4dUQC20Rvx2wb2BCmB
JxKiKhdwIyzKZdBywmeDQTV+M9ChhKKjRYQpJego62BTtSMjwtOwCrSeRkAN9q1gwDrIFrN5IVmM
aBB5x3wOAu/aLwMVGpAgRtDqrtGvXAnuRTw18CkiL7dBzGpRBkLV1WiBfwlzCrpV36AF3hbMKcCp
UwKCheSCuALTKjmrpcCemoYWJFeEVgdXN8QWyFr/qzoGx4MIlaZB6YghcCjtKoGQ3gg8mPtgdUVE
7mBqjDUrWSjBg7XhQYJ9BFIj2EegCoJ9BFKlon4jJD6FDVqQUsHvICuqiO8KCxQp+hm0dXA0sh/v
O5LPaGGGQB4MCiakTQasCDmRMbME2mAa2aWg1dFCDxbch4yrLKotyBP1EY18UAitkTR0ngiZjqug
BXlNLSLkKIU4WpCnyNMWsgsiUXMZ0gtSDtKTgEFGchWQWC74DFEIz+qMImuNREIdWQ+piTXqCBQn
orIIKU1E55lopCCMkpBxSh/pEblHEQHU61xk9IXkprFCSBsC1BKQVzB/8JO2ChIpEg8yO4GqC9if
gOkC1I68W2A5bNSWxrKmXiQv5F6wQEGtRMB+UbO2Qe+lJMiDtuFfZAytnlQe+KAAySSQrNyorZHf
1LejHCpACo3EtmNOge6qQEeCR7LDnALdFfFHMvIerAK6K+zN0KbBrjqA7loTWqNcUsQS4qU2xClw
XpVVtTWKQsU0jUy2I5oQYQ3VFQHJDemRwAcN9Ep1VF3wFligYQyYG4U+vDWynwYMCg6kSIwcONdy
iEalqUlS0ILkinEA563Cv8B5Q1VJwLk6EC1I7qhk+kin8CDQrfQCHciIqNYI6O5IrgR09zwKnJFc
E1pIqhjXKKI0INBCX2SqUb90GUUSWmWMHNm3dPwW2oZ9YIYO+xg477CPgfMO+3gHg8M+Rq7bYR8K
EM3PGa2RqXWEDF7ckTsYnLqDM3jkXfiRE/I2Z7SQ0lntYI0PTeGEFnoU1cQJOlB+MlKaVrhaLo2i
V3O3tqCjocwa9S9KUEYBrLlCtYEhNfmghcSP4p1R8aZRvOWR+vVuRsWQwEY8ambgipE5EkaIOllb
YJqKHoIoKZBXGPViRU2gMcWjggAuGTkJbtUW7usoMFEh63SoXuSfjCqfUSznURsiA2YkfgYfZ+QJ
JtQEQB2rPVpBqAcuhQejZBw1hGCekauVaFCXQl5VX/AoR4ZVyCEqTmeSIaVn/BZSOsaLnKR0jc9Q
J+i0oahFwQGrkEcJdcelrkDO0koXxYfaC3bVVkcZjL64W+kVhYjOGqNaUDhraxQwBfOs86At6C2X
BQjuyyhUMBsF8lC0MwoTDXRU0ZA3fFlG1QK9mHsNJG0hQzNqYkZ2Z1RQjHqQkRexzNKqBmOro9DB
vCBDM6xk1HIM3mWUUwzUcoWOgnFUyKsJLdyHUokb5KFW4jYqIYyjjqoHEYuyUfaE34KfdtU+qkPB
IolHnYRqiVFBCHiXRzWDPMsouwQ8x6gWBDHAHdURKhQVj5oIqxXUK1IQ931UR2PpAL0VcTVqJxSZ
jNyvhf9YWKBiUuQIECXgXUbmLQpH/QxVD1YaajiqKI0aHrlL8aifjdoJKwXgvAAVMvIyuEX2keM0
VgSYLlgJCfBbsBQa9UpBBuNRWVWVP0rS0jTGBdgvWGwI8KsrJbQEtRj0AskVhbkAyRULDixntIU1
Sh5VmUY/Vs9aqe1ooe5CxhDgo4IBBDiv8KiABaoQWpCnQ9dWRUsjSYBQTRpoQXLFWgm41PyBFvo2
jBe41DUvWozaTu0V4LKhFoV0rY5orMXQUp9pokeVhxkCQhsyrKC8b8hAY8HQwBkC1DZEA5hPyzXF
KVZJWu9h5OA6zR+QDB1Y3Y4aWqdPfwvUNiAFvbQFbwG/mvLQQjUITAuQ11FByajtUJULkNxRrwqQ
3FFhyKgVaWyLjFpRvTdq4w6fCdhCVxRqH9Ddi1y2T5RK8NtRmSL/okbQvIkIK6PORIQB05o/sACt
qDN3tFD57fqvoErZUaFgqa+ZYsQLPkM9KMhsO3iYR/0I7hNUZbtgGVxHdakeFeR+XajqXKG+UMfo
7FbIUzdoa9SZmElkbSUQlVxHTQm/ob5QUtbPUB0l1MByqS415sGz2sLYFN1ae2JsowYE/0kbNSDG
hkotAQeCnJ4wQkGu1lILrYTWWGBDXmW0IK8pEn/9609fYJtp337/6ctPX/74zV8/ffWPHz9/+vLn
n37548//8f3n//30xZ82Gr//7bb/5jf//E+vu/znX/70y0+fP/3r9z//Kv/L9qbzb/+wpf/ZrjLc
/nzcPz/Zn872/+HnP379189/+/rb73/5/PV3P/3w4//9+ZvvfvjbsVQ+lNpN6hdHXWQrrilfff77
z9/+8Pejruphveeod0+eSl33P6wyL1WS9f6vdNjxYY281CjeINP+QJ/DqAz6+JHojazgHuzxjktb
jbO2CcTv//Ld5yNJbXgFO8/jcpHbLnJbu1z6RUu6XOhykeXczphdgT/xG/Rf+5xG/0WIK8CH/+MC
6LSARwjghNjj/uL3D71Rrn1Q1XsccKgo6NQe6dQf6TTRu5oIB1Y42EBw41zjck12veGue2sSudYE
8epZk9jROpnlmDNTEOWu2rJUez4a0zFKcK7jzVYAAtfs/hFmH6MIZ06e2eVxs/M6tN5h9gKTmV2z
j0F5zmz5CLOPAX5eQA6wHpJeTjeT5RZb+QlE0f4Bk5XP552FgGczTA5STCwgwEnsrvriLiquu56I
baqxu2JT+42pbmTREwmLT0RWaCrdgICza+oTIGD6ABBQAIJ4rHwzVjeCKIh2d6wfEUF0U5GxH0HH
9H/KVPkIbqIAbfFYb9AibkHFT6BFnIJK3KUaP1HGybqewnMYntYn4CbN0epGEwcY87SWj4gmDhJV
GE0sL2MtfjQ9UbmVdTS9w9SbjFZcPuInMlpZ8xGe0/G0BiWaq/UjKnIJ8B4LOL9jsBBwjEI8s+RM
nDyBourwVHV5Sp5YQNUT674wnuUGetWNLHkCevVDIivImrGAAJGxgMUGR3MjqzyRAdtHcFa5qReb
y1nliQTWPqKGKnRjqpv1yhPI6eusl/z99PJEkdk/YuegHKMwdXfnoDxRcPb1zkHqfjQ9kQG7kwG7
y1MFz2c+oXhNVXgE1FFc01Yfxw8OH1eK42OBtNsO6J7tSnZlu4pdi12rXS9nBrYrOvcpxxPel6v9
Ppv8bDus2e7PJj+b3Gz98uxnO7Rk/cjsI+tP1p9ML5kcsv5k/dn6s/Vn68fWj60fWz+2fmL9xPqJ
6RXrJ2av2P3F7i92f7H7i91fTE8xPdXmpVq/av2q9avWr5qeav2a9WvWz851LJWMp58vV9PXZj+z
0053kh3vGP4nIidGZsguwnnuHaxo+TLpr05+XjqdPvq5SPEl+Gc/T0ig8xIeOf15I/fcAfDSHI8g
0o0r7wWkc6fAj+nNjt5TR8GPqWVH7VyG/+7ffvjuH96p0pueM2P97r+Ptba11ryHWhchn7qvNSdH
aw61LmASaiVHK4daF9AKtYqjtYRaF8ALtVYnmq5aj7teqNocMadmGrsYSAsHIo8FaO5rrZRCrQsC
ot3XSg4HEIVa64NaHQogCbUuSC/U6vg1CBWrcmxKppELM2IOW9BnFCLkcBiHHJYXzEkBwtjhMA5D
JC+Y83q+sdLqhAiHIZIXzBlqdULkZZ6Ou1posBMaHIZGXpBv6CQvNHqodUG+kVbxKhcfUWzka3W/
Tc00diFSXJG2tLGUMbl68sIE5hzVMxXMOkriFV22FVy2lVu2lVu2lVveZ4Vvw7BnX6wkm7NwbL5E
D3zK22e+XjqdrvyFF2pPV/5PSKDzEh6p/N/I9TdPZ+W/NMcLJLmJxHsBxd+TmJX/Q3pLcvROBLiV
/2NqyVEbV4j7oueVFY5J6vbM5U3fkBrTIuSvpzULrXVfa62nK/83PVOg1Znherryf7dWcWb4Ok/H
XY3+b09a3qg/vXh4t5Oc0KhxaMiiZ6C1OaHR4tBYEE4LnNSc0GhxaNQHtTqh0eJCeUFyLSiUW3O0
JjcgmxMSLQ6JBT1G09SdkOhhSOQFM/ZIqxcS/jTdnnm8URtGU16QajhNTjT1uLZekGoPoqk70dTj
2npBqoFWvIn2sHOskuxOeVF9XrZta2OGibgJgRla09dzNIeqaA93L/KCvwMmpX0dhbTHUXjM37RT
oHUdhbSHuSof83es1ctVrjNtKqZxj+Vp87sda5hPp9WLEYV7ZXmRVYK8TbtXN/uLxGIDsXMdKy7m
FE6jF6LZF22iyhkR7sOy9zOZ4hRwnHgo+YxKyfFfCrdZ6DjxUOJAq8MWKYwaOs4e9HJ4sNC6jhqK
jwDoOHuEWvN6rUXxEQAdZ49Yq+PXHPv1mI8pB37Nnl+vFh93dUg1ubiziJk+nLM6rY1wcSzysjdj
Rj/CBobZafwzq+Zpiw0vOYv38/s/JDdudbc46IkdDsoOU7/D2JeHM+l6FnJs7BPbIkROUXu0vbTY
n4q2SOLnbhf1/DskLCjSf1eDFwXyuclbQ4XIf7Q12tFz1Tqkzu4WGq82/M6o5TMgjN202EF4h4QI
nLGE4xqM2H8O/xmcsZMm2H8Q/4ntR2KnLjvPRfKyc07iBphEu+WeseKUDeK+GyTPoFicukHc2lWe
QbE42V9czpJnUCxOej+PIHkaxfI0iuUYxSeOo+wBuiy2krcH6LLYasYepLNzkHkuMc8JZhk0vpfu
crVqzE7dLF+P7567XO1+ezDQUtLMEZO0xzfKXa7Wzx4MNF6aRDG+M25cxfrZeCxaZ/iMb4C7XO3+
st5foRKyQTE22A86nT9GKwu154/RHpdA5yU8dIx2L/fkMdrKHA/Gt++33AuoJ4/RHtFbk6P33DHa
Q2rJUXv+GO2+p3+MRq/OSu77nj9Gu+8Z7PS8Oiu56/uyCxoeo71Xa3a0nj9Gu+8Z7PC9Oiu57xuf
lSyAF5yV0Kuzkvu+58/A3qm1e369ztOxwUb8zUF9j0NjQTiRk7oTGvHBx/UY7b5npNUJjR5DfkFy
oVYH8oGT7FyAXp0LLFF47GcTYUcP5tNpdURixxxmuX/uYjdHVA/3IdOCxCMm7evA5RNnJcf8je84
9bTyvg5cPnFWcszfHJxa8L4O3BuLj7uy0zU+Zjmm/nia1jHP+/nDvvuefsLhtKZDTnFIHFN/rNUL
icA5FyRx8kogF4wW6jOEpk+n1Yu5iJ83XSSkAJScnGhLcbQdZxNOkVYn2uKDkHycTWKtDgHlONqO
swnnAFnZibb4rYR8TLacAwLKDgFlP8azFxJ+bNvbdJwfzlUWdDMMprELUf5RhJ1x0jzjtHfIDOMT
VXNQz6xM1gLinQiyHQWaOwrz4MPOValY4Wev6NnSbi615iwsXD0hvFzRX+y7XdG/dDq/om8LtedX
9I9LoPMSHlrR38m9vh4SrOhX5jiBxLcviLzR625Mv6zoH9JbHL3uznR/Rmtbao1hw7bxxvZGLtvG
G9vGG19Otaa/5vzN8SzGGr3Yb08nv4LLtdNpuFyk+BJ8uDwhgc5LeAQu93L9L7m6wmVpjhdAt19z
9Uav/x2iEy6P6e1rvdezEXcD7CG1t2cjb9RG7z5fIzfdhK7/pVNpEa7XA5Gv/v3YzuLY6bJJWoR3
qLE5Gt1XmNMCDpHG2230pS+++v2xtcZEdsTA4oRTcc+80gJ0L1XLwnpyNLrHXXPj690axdHoUkRa
MESo0SGHyENWktlcTAsXdvjxVa/bUG86Nn8A1Qmx66sJx0oXLBNqzI5Gt+yZuzPv1shPOMkSvz3S
yNUJ6uqGGP4uxoJ5rquV1QCcKPO/fyovmCfU6LBFc0998oItIo3tTN5ZOMnWYDYX08KF9X6IyXW7
4U3HHAzAibLmpsC51fBujQ5hNDcF5gVbhBq9FBg4yb6kxeZiWngsq/sh1q8Px74ZQPcH0J0o624W
pEWdEmp0CMP//ilasEWo0cmCkZO6rW+65abuBHV3Qwx/lm1BBddDldUAnCjrbiLEX3ZbwDdQij+6
tFIqu5sIaQHfUKOTCEM/WVV3mY5p4cJ6P8ra9aHKNx0pGMA60GR3cyEfwzfWuOYM8f9gAh/DN9bo
rcJ8J9nEz7mYFkZrs2++/f54L8K+hctWDbM2neXPzLCTxCdPzDicQz2ehvglCD5mIwlegpDkaQ0f
lufj+kWClyAkrVOjxHv/fExcErwYIGkdLBK/BMHHq55Qa3awn8MzHT7mS3l5fWKhdZ0ZJH4Jgo85
M9bq+dV9CcKmYhq3UB8+CcLHlVPspDX2heLQWDD09a85LLSSExoUQl4WLB1qdSBP4WGULJg61Or4
9fpo/lrrgt5CrU5GovBIWxb0dn2mf6H19i8i3Pfl8JBRFvQWal0XLBJ/WZEs6C3U6hGN+7VB5oA5
JdPIh9jDNv4NNTOOZ2TNUUTJ6jjemxGTqbBXrIyM5iAX0x4yrSz4Pcqg7DBt/FVLsuD3UKszjRLS
pCzImQMQO3veInFgL8hZglwmTmBL6NeyIOdQq+NXCf1aFuQcanX8yj6Irey1KZlGPoQ0e4zdrF2M
JCTtsqqEg9h2dvOlhMm4LFJFCepvZxdeSpiMyyJVhFqdZBx/G1FZpIpQ6+OhYZvxNiXTyGjJc8zn
Fqj2lWnG0ZM1Z7zPSJujWqjafVVmdXK2ac6c+kla23DilNxeK2F7rYTttRK210rYZsCOaeex6TzG
nAvpOdqF769mrM4eLxC6PTV/6XT+1Dwv1J4/NX9cAp2X8NCp+Z3c4K9sXE/NV+Z4AXX7dzbe6HU3
Dl9OzR/S2xy9Ewn+qfkjal+dONwJaGEFMV8bedMzyKqvjhzu+8ZPri9CvvlPOMqrjfv7vvFLDQuY
tGAZ0J0ZPvFGwgJaodbsaI39ugBeqPXQr/8Pgj3xPA0KZW5kc3RyZWFtDQplbmRvYmoNCjU5OCAw
IG9iag0KPDwvVHlwZS9PYmpTdG0vTiAzNTQvRmlyc3QgMzM1OC9GaWx0ZXIvRmxhdGVEZWNvZGUv
TGVuZ3RoIDU2MDE+Pg0Kc3RyZWFtDQp4nK1c244kt5F9X2D/IR93nzp5JwHDgHdlw4bWgjAS4Adj
IbQ0vdLAo2lh1IKtv99zsg6rqmuSwepqvTSjs5IRwbgcXpOplWVdUstLqijS4hzKWhdXypLXdfGZ
P7cl4HlewxIKS7/EkFG6JTaWaUkpoYxLdgEl3iksy1KCQ5mX0lC6dalpxf9taXwH77bM0i9u9WDk
oMBaSURoEsmuLM5vfDOI7EG4xQXvoSVeDtA/VVRPjk/wUyptSWDq8la9sSUQ6fFT9dAJNV2tDURY
XKPWPi5+xe8ZGni38qcEIqO6r4v3nk8KiIonASYJkU/a4iMMkgOqR7YihMUntiLg5cRWwEZ+UyOi
VmErAmoVtiL6xVdPwoGo0DBAVosk0hJWmC4HD6KwOuzu8GKOBQS8lGNegk+QDnOGQJtDpxAK3sHT
EGn1hOqRLUUjQ6LOKS6BTsnJgcggYoVHA0XgnbpSBN6pbE6CiIZ254yXG0ybEQpoMfjANHFtJMIS
YXEQeYnekUggCjTMDTESSFQQDRpCuRipM/wRkyPDAoI6wyKRBsgJtQqbg3CMhWYB91gptOCd2hhZ
eNLQuFwQtStiKuO9tNLL9L3zfAdRDDeDQGh6mC3DjglG3AIzBUYnbJRiYETh5QQDZARSopoZnk4F
cZERYwgoimCGwCS5IuAaHUfLHqQzI9DuvIU4AiSzgqt8woBjxDfP0AHDRr/CNpl5A0stBUkGN+Bx
2zyU8CTQ1iQ8LRtAJLafBBsAXxR6sUYS1AlVC53XEjlXsoj4g6du5Tt44hL/80vxjgSeehgSj5Gi
gQQqBIQWrV9iIoGniY+RegXmQI11KYzKQhZs5aZTSSTwtFIOcqcwfmi+0pAOhY1slURe6or4ggpL
dSuJBgJOK/AZspNw4UG0A27UQDVgUDSURARRqGYAjFANVKhwBghwZiqgBUtFm0GAYaEaCMFaPQ2A
J5UNhNVgMPBBsrUVgVSgU3O0DRKtOQRSQX41H0gkEPBwQcI2pBMtujTqA2MvjfbJ4AXD0yEOeJbJ
py6tsBZ0apubkHGtEQ8hrzWEX0EmuJXpVBJRz9FMSFBQCEPYm5AY+QzAt4aVzxqpzGfAtxUJR3eQ
onUzQTTRvJk1CMYlk/OmUWbdzUvExpWpVRDpQNtIaiXFwCnk1xIp8IMymQ4mVUgRlh1jC1qAohUL
qS2W8AZ+DAyAlRSNDecCyNHWUsEZME2KnJn3jGTnmIgFCQuKIZUpg+0vmb9u+mXy28wXKa0xGAn/
fqXOlX0EWC80ufPEoYLsBAWZzF63QTaiEVRklCFTQTFy0ALnE6UhV9HBMAra1tWwRewQPSOwVL7H
/xHKoBraUVdyhsMXAicSn7ELP4HCOxVZ7AJ7kbqyo0LXwOgHBUwHVUgVPoO0QCSoyFdQjc8gA5Cd
mSag2OdVdpKB+Fq3HpA5WB1lULfKnjNURj27zlDJhV0mnADOiH0X141LIbVxgbRIuKrsG6MjFyS4
i55c2E1GNAlUJEUu7DFjJBckOSj4u3rySxuXTGrjQmnskGogv7JxoTR6tQZKI/8ayK/CZzVQWot8
Bs6JvV9FlIHKhIGy9e+QhjwHhehiSx2AHe1AfIBqlAYZKSDWmHEuRWY8MhoU7Rw5SmD/XCM5J8RA
jeSXNy6USwgujdIYhTVyFMEOmIMWl5mhFVEGqhGBwA/g3ohFoOBgUInjDsYGMxm9NH8FP3TK4MIo
Rse2gRYojgEqszYT6CujPTPHKzMg0z+V2Y0eBzoz49GdEOfAD2DPGpkU44/ZXTYLMbvLZiFmN0CY
1EqqUQPoB0QExUwG3PHXQIp+Y/4WIkhlxkMVYij5sTeuzPPCHqQSGQrxoTJ/C+3EEQyAnO1gniOF
SHGoRQSpzNVKBKlAKle3qGNG1S3qiBF1yw9mLYKB/CopcKjMVbiM1EoK2VmZqzA2KXLZBpbM7sqh
SSUe1K0noS8rs6kypyutzb7SVfbgxDtQ0KoxfxugFdRKqpEfdG6OAM6sRQX+yjGjr3wGfugPth6E
FPsAZm2LiVTh2BL/0yKg4JXGrG1562oog900UQRglkjxPeZ4YyY32rgxk1vb5DZSsF1DTPt1zfwV
o0ykNDuqlRTbgZjBUBbWZftANVIYYGI4QLkYjq4RrWkc4KLX4K8c/DI6OdQDxXZwHLxyaNg4yF05
fGgcCa/sY9AtgtryN/E9WrEhpzFyRtY1jo/duj3DewR3UNAFYMx+vJCq7CFAEErgewy1V2IoiLpB
AIhGL8ErqNU2XUFxVMYxL2AdcRLA2aOzwTiRugVOTiIH04EDsoSY99Fvo3pSxIJMzpFj6BI5eKev
MVQBz3XDfzxDd06kIBVhy9/97u7LbXK0Lm/uvrr7n/96fPvr3de//vRw99XTx1++e/rj+4cf7z7/
O/Dif5e7L7+HLL75+9//+7+pZuo1/7JXLW2Trzf7ddEI1d2vmo2qyawK4+HnhQB4KIPKNGbZ2tQG
eabMrg04xxxJ5TxzJrUMarqJ1HCr+aTUQGycKlxvNNPYOZzRzaS2Qc08kVpvN9M4tjn/nyjs19vM
5IxoctNo8m5QcxJNbhxNXMmYSfU3SjVCwk0xy4cbpVqYZYfEwQHdJF3JAStvseLqyoZZB5Ts+NTz
vidiD/Aecb11A5HOFimYrAZM5g7aXz/86+nbx3/tMxoDSOn1v3r/7u3Dbu0s9C5C7+JVSr0SVSaV
RaXq1bEFuBAi8T/df/hEOiscHPz5su5U+tO773/5+HD3h/dP/+H/c9mFIYlNA7FnHOI+B/9qDuF6
Do9P333z4eGf33z7/peHb95+fPzp5x/u3z7+c59v3Ofre0p8uevNJU/UMQKJ65UnV17KLZZcTEFe
I7cacju0/9nt1W2vEBvWsdgQpl3gOqh5BJp9vAvRkDofGQ5CPkz6sVAMqfOx2CBNQrWlRsPC0U2l
DlJrKtUbbbV7lCBYj85gYfYk8mHXcsDC7BkUfF3ZCYvdfHQD9IjXTz0ua04CLBoBFq8f7F/WnLg6
GQGWrh/sX9acDFlSMKReP2J/qVQjGqI5uZMpunIzB+/7V5mRjMyI0WahzIi3Z0a8PSMGPUVeZ/7y
A6BPzfZXNiyVp92LHwB9nnQv2XBxTlOpA6CfSjVGDscx7HzqcFmzTKS2sdQy9+sAI2dSi+VXu284
mKIrNwurfRbqGw7VurYDVjYqHEK/Kz1gUUwWyfDAJJXTNSiwm8p+0EWV+Rx10M2USedWDCOX+drD
oJspk86tGlFSbLQuVmbYKF2E0sXwTwk2i2tQelDVgK/rBvXq6qLyJGrintSsQ0Bvu/+HctyXzyfP
PA6ycfFaJvDi6iXdS7pXtnpJ96oXDCw5Lh8MJ8+H3Hw2eT5Wun7yXAZir588384hXM/hpsnzJd/u
0cnkeaSOFXj1POUuGLTVknuaPN8itzlDbu+O7MnzTWKDIXY+y1gHNSdA/GyD47LufJYxCPlmAzFP
1Iykliu2FPbTpEy2FMo6tnC5Yl9gP7XmUpMhde7X/cSbS7X8ao5i5IBukq7kLLz2o6uJxTilyjod
zR5n0C+L7bKOAaS4+WLJPnYVt9pSnTekzqOsDGqGiVQjyk4a71eNRtV5gO5D7dxM4wAtbg48+0hb
3AR4vAE8fr77tA+yxU+S0RvA4+e7T/sgO5dqhISfj+wHIDuVavnVBh6N9WSSruRAjevnwC8NEQM1
whQ1/ACvwyQdgoUattmCAa7zVXe/D65TMwUDNear7n4ArpNV9xKM6ArzkBiA61Sq1ZFMnHOYJZVn
i9cvxGd1opoSKfR7SHUf91bsi4jzxZsbcTwa0Rfn0TfA8Wgvj5VoRN9p3XUkNQxwfCrVAKSJEzV7
LnHspMlgSkOWPhTofXOPwO7j3oqBCHupomlO38RyVenG3eaVkxsjNueLAlWLAFWT/6rJv84Y8MT/
odRqYNM6XFO9ZkVLX48bLgocBiPniwKnStcvCrSB2OsXBW7nEK7ncNOiwAXf447NZFFgpI4RSOXZ
ns2l3GzJPS0K3CS3GHJ7BNuLAjeJbWOxeT5RXgc1J2O4HAypU3R1g5DPcSI1G1Lnk8RBmkw2H0o2
LDzf8nCD1JpJfbblcSl17tdB4k2lGn4t86lpulGqkbLZ7I/k9u6Ibpqu7KAh8ynrAIBmAVoMDJhv
Whxn9pc1JwPtZ5sWF3XrPFQGoFcnEFCtULGHvM9Oz73M3zoCV6qRHtnc7xA+9ajs4dCVHrC0x25Z
UZeNqLsKzbPRrOkoqEQlQ1IyJI0HdRahJI0Lk6bP2qBR99RbOZDe/TIaBR0A6/ko6Fjp6lHQgYvN
wR4FvYJDuJ7DLaOgS77N3HI9joKG6liB1M5S7BO5wZJ7HAXdJjcacs1zlO01UvNY6jxtNFkomiQU
TRKKPrIomizIX91+vT2Dts4mDdrPfZYu7cWThgMXm8MkXW7nEK7ncFO6POdb1+smDUN1jACq51sw
n8i9btJwm9xiyL1q0nCb2DYU+4LIdafQrc7EMjcLV0vZ8+2SVyjrz5Q1I8nN4tpUdhxIL1E2nilr
ngLvQ+7blK2/ibL5pKw3d937APcmZb37TZStZ8qa/aB7TYL5+Fso688SzJso5F+TYH4MQi9R9izB
jl8Q7Cv7mgQ7/4Lgmp5n0PkN+pjjQXPzFNxtioeh4jWYgORf07MFo2cLdky9JlvDbxNTZ9ka7Jh6
TbbGa2Jqqmw4y9ZoxlF4TbbGcRy9RNmzbI3muDy8JlvP90MuGcwH5tpk4CUdh9Kp9CqDyqgyq1Q9
p3raF6naF1H/v12ucSiLysOAX73YdoHGoVQ9HSkUFm+XZBxK1QuSowORSuueZ9uFF4dS70e9H/W+
Dk7WaOTsdDeifPp9X335bkRJA7HXTyxu5xCu53DTxOKC73E3Yn+gfZpZjPSxMuB8O+ITwflaX5az
SiYO1uO84FLW8STvZ7v1ztd+Lutme3C/nsb3LxXqDaH26MyfxukvFRqv8MjXb/a9qczNytzzfZBP
GmD2rm4QjMfdk5H2xZBonrU9ThVeKrGNJRZ7vD9InJnE872Pl3ooC2u1MVCLEdfFDrEyqOUn2hvx
Vcyuti/Fv1hiNiTa08cBWkwl1ts9pK/cZYuu4T6vasZXP233ifbN1r4a8VXtGcAA6KYSDZyo9uB/
0J1Oag2wcaqnfFKNiJr5t2r0pDMZ0nTQChOx/AAja5m0wkAs+7sAP8DImcRmRFSzI2qAkZNaA2ya
6qnca6/oA7U8Lkt2TQetsGeYA7xrk/6hGYjR7Iga4N1U4jiieAWVITEMMGoisa2v6AN1SEu26BoO
tDf7wLCPd221+4e2juOrrfZ0cx/v5hLHiNVWsw8M+1g5l3h7Hyird1t0Dff1cHZ87WNkW22kb24c
X83Zqxf7GDmXOO4Dm70iH/Yxci7xmrnXwENaO5AtuoYD7e342sfqdvxyYqT9OL6aMyeBYR9XpxK9
gRPenAOGfVydSzT6jqmHijxzmJM1b0S0N+Mr7mN0O24QjLQfx1ez1+vjAFenEg2c8GbPFwe4OpVo
jKVmHtJnGrJF13C2mHL/7fvd5cCq74g1we/TyD5Z6YPbPgjqXWwH8g4XPSh70/fNEkzQjbyn8vZF
oRaMULW3IGJa4iuWo1oYt3m+IFt1wKjqgFHVAaOqA0ZVB4y0otYDpFuzt21H+pmwrz8+PLx5fHy6
e/P4/uGv9z8tmrN8ef/x4cP266JZ4baFeWB88KyXp730ClqmiQrAqIXX1C+F0MF4nVDvZ7T6oZO+
xt1NS72PSnwBI3/+8Otpq/ZP0PnD49PD3Rf888cPb0//dId89fDd092fH+7fPnw80KzT6b98eP/u
w8NXP9zTEnzwhw/gcP/07vGD/v/49O7/7kFs//3t8eM/vn18/MfdZ4/f/fIjlNqe/PzDw8MTtXy6
++v9dx8fz/7/7x/w9+z/z97dv3/8/uzBwe2ndw9y8Nr3H+9/1Jqr2vrFLz/+/PeFVzhv9nHbPa+b
5bd7Xjfbb/e8blbf7nnd7L7d87pZfLvndbPxds/rZuXtntfNnds9rxvndbvodSPddtPrRvrtqteN
DNtdr5t3qBy3MxV7Aglhg6BBSPCs8M8KYZYiV32MgIv83bpKNa+yqxpVJpVS9jC245Xsaofqa1fC
aYThtCvhBE9O/ZtT/+ZkHKddCaddCaddCee7cVRPpnZKPqfdCafdCaevgpx2KVwQn6D62q1w+mrE
yWFOH6o47Va4qHpKHieQcAIJp2R0AgkncHACByc4d7obxSlpnQ5Vuqz3BfdO5zadblF0Ch+n2xSd
ugOnWxSdznc63aLo1E04rVM4Jb9T4Dglv1MEOcWOU/A4hY1TwDjNqZ26G6eYcT1Cj+DkzstDMHkF
j1fQeAWNV9B4bWV5Bc2p9BdlVKn39SmYV5B4BYlXcHhtWXkFg1cQeG1VeTnfy+lezva6UMrLyb7f
BrY1JnX41ctJQuVprw7caxX9WMrjp1JKy9NeHvZaOfRaOfTyqJcnvUDDy3NeHvPymJenvDzlNT8O
yuigjA5yRpATgjI3yPhB+4hBmRqUoUFGDzJ6UEYGGT3I6EEZGWT8oEwMckJQJgZlYlC3FeSMoP3C
oEwMck6Qc4KcE4ScoXeHAuQgvwT5IygDg/wR8plTg9IwKA2D0jBooT3ISSG356XS8VRKuJwW5LSg
tAtyWpDTgpwWlGZBTgtKr6C0inJalNOinBblrKgMicqQ6Prvqi84jX0wz0ZHeSzKY1Eei8LQKM9F
eexU5ovyrOOIAtIo90W5L8p9UUAaBaSnsj0v5c7Y+1elV5Qbo4A0Ko2iPBblqah0OpXSR4AZS7ko
JVdAGQWQp1Ly5bmoc7KnUnrIg7HVZ2VS+p1KXYcrj57KolKjOKVhUhomeTQpDZOmH0lpmNQhJjkx
Ke2S0i0p3ZL8lOSnJP8kpVdSeiX5IQnukvyQ5IckP6Q++pEfUt/CY1Bcfxdwvijr81LplOSUpF4r
KY2S0ihpfKN76/vd7f029X5Jeb82vN/G3e/H7jdWn+6QZiOuv5MpX5T1eak004Wt/QrVfqlpv2b0
7KYp/a6hhm6J7Pc2nm6gUseim/r63Xn9Nrt+v9zZDVX9c9EzILz+G9P2vFQanEopKQ/oqpt++Uy/
DqZf0NIvKenXhvSLPPr9GP3Gin6HRL/Vod+z0K8r6BcI9O/y+5fy/dv1/p12/3L69C0zG3/9pyXp
oiwXpYQpJ/RJX//Irn/21j9E65+G9S+r+rdOp6+PNuWuPsDvL8p4UZ63+OrDR+miLBelViWOh5FU
/3gYSfWOh5H64aV+GElyj4eRNLc+HkaSnH4YSTl0OowkOUI5ncw7HUZSbp0OI+n942GkM6NcvwCQ
LkoJFSSeSn9Rxouy15MxFB7aY+87330/uu/s9v3Wy/3MvjPY9+su98P6zlLf7+m7MH0/o+8y9LX/
vore17b7inNfu+0rqn2ds68Y9nW8vrrWF4TOynBe0vj/D0bVnZoNCmVuZHN0cmVhbQ0KZW5kb2Jq
DQo5MzQgMCBvYmoNClsgMzQyIDAgMCAwIDAgMCAwIDAgNTQzIDU0MyAwIDAgMzYxIDQ4MCAwIDY4
OSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgMCA0MDIgMCAwIDAgMCAw
IDc3NiA3NjIgNzI0IDgzMCA2ODMgNjUwIDgxMSA4MzcgNTQ2IDU1NSAwIDYzNyA5NDggODQ3IDAg
NzMzIDAgNzgyIDcxMCA2ODIgODEyIDc2NCAxMTI4IDc2NCAwIDAgMCAwIDAgMCAwIDAgNjY4IDY5
OSA1ODggNjk5IDY2NCA0MjIgNjk5IDcxMiAzNDIgMCA2NzEgMzQyIDEwNTggNzEyIDY4NyA2OTkg
Njk5IDQ5NyA1OTMgNDU2IDcxMiA2NTAgOTc5IDY2OSA2NTFdIA0KZW5kb2JqDQo5MzUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjA0NzUvTGVuZ3RoMSA1NTQ5Mj4+DQpzdHJl
YW0NCnic7H0JeFTV3ff/3Dt3mf3OPpPJzJ3JTBKSSZjsO2RICBACEkiABAhJSJBFkCgosgYVRQLW
AmpRaKt9XbHVibgEixi7aKu1itZ9qftWUOveQma+/7mTBK18X5+vvj6+j+/8kvO755x7lnuW3/n/
78CTAQIANiQVNE5sqp8srF3YDHD/NAD3BZMn1k2CDPbXAIc7sJR3cuOMJqHUUIXpLZgum9w0u+bN
4LsZmB7A9JXTmpumdL2d9RSABsuz981oChesfunCFgDyHN7vmDNxesuav29cCWBIBeBe7VrZ2fP6
fb3nA6yciGV+0XX+Gt8c/5m5AGvvwvTHZ/YsWbm+7oMgwNnvYvkHlnSu7gEHqLG/RmxPWrJi3Zlv
VjdvBlh3C8DYFUu7V14Q3PXnCQCWkwCtU5Yu7ux+UXrvZ9jWAixfshQzTI2aeZi+EtPBpSvXXLDo
GfkgAFMGII5Zsaqr8271gR6AW6wAwtkrOy/o4YN8DZan4/Od3bly8bQPznkd4I6tALpf9qxavSZ+
AeB4D+fR+z3nLu55ZcPLRwHW4POwaqBzy3Hyxj0/ym43Vn0GbhEofrWi6Ut6/f3Yuq4T1w7t0d8i
7sGyamAgAawnamOzcJ7K8P45+luUlr6KhTSHvQcmAKukGZAgArMxwnEPJHJUO5jDwIHIXcsVYpPp
iSt7HTzFciIwWlHFcioVo7oe+HgEfPPpjNKK05t8PsAfdjPvjbXCI6KW3O4D8nN6T9XFHaUjBSIO
PxL2oQS2DB5VHYSb4TRQtcKDGG4aSTNvQoB9Fs6mcW4rbOCi0MNFiQavhzDsxNCM4QYMl2LYj6EL
w1JaHvuZfro++BJw8k44wj0CS/gb8LoWQxEc4Tdh+iAcUS2EDapzIFvp0wVHhKvw3kNwREm/nLji
Sh/h7oCV3BrI4nvhVj4VnGoBauj1dH1+FVwLzOH2wgHV3dCC13lcI7SwnRBS4gfhAM7RdUq5hUr8
gLgWDtB8brNS/gAtx/4T6z8A7eyNWO8gXI/r5RWegVxuHqRwxeD9d8+QRBJJJJFEEv9zwN5DiNWa
naUknGhIiQHIKSRMMmhJplE2jM0yESD5JjCAwZpmSA+mj7Si4yVep+WzrJBpzclS87yOaLJkSWf4
fgaVRBL/G0ASUgUdfCnGQQQxHsP3FA2yRmEtaJF1oEPWgz4+RJWLbAQjsqSwCUzIZjDHT4IFLMhW
sCHbFLaDHdkBjvgJ9LKdyC5IQU4BN7Jb4VRIjf8TPOBB9oIXWQYfsk9hP/jj/4A0SEMOQAA5COnI
6ZCBnIH8JWRCJvIYGIOcBVnI2RBCDiF/ATmQg5wLuchjYSxyGPKQ8yA//jnkK1wABciFUIhcBEXI
xVAS/wxKFC6FUuQyKEMuh3LkCqiMfwqVUIVcBeOQxyk8HsYjV0N1/BN8Y5uAPEHhGqhBroVa5Ikw
Mf4x1MEk5EkwGXmywlNgCnI91Mf/DlNhKnIDTEOeBtORpyt8BpwR/whmwAzkRpiJPBNmIc9C/hCa
oAm5GZqRZ8Ns5DkwF3kutMQ/gBaFW6EVeR7MQ54PC5AXQFv8GLQpvBAWIrdDO3IHdCB3wqL432CR
wl3QhdwN3ciLYTHymbAk/j4sgaXISxVeBsuQl8Ny5LPgrPh7sAJWIq9U+Gw4G3kVrELugZ74u3AO
nIt8rsKrYTXyGliDfB6cF38HzofzkdfCBcgXKLwO1iGvh/Xxt2EDbEDeCJuQNym8GTYj90Jv/C3Y
AluQL4SLkC+Ci5EvVngrbI2/CZfAJciXwqXI2+Ay5MsU3g7b429AH/Qh74AdyDvhcuTL4UfIP0J+
Ha6AK5B/DD9G3gW7kHfDHuQ9yK/BlXAl8lVwFfLVcDXyT2Av8l64Jv4qXKPwtbAPeZ/C+2E/8k/h
Z/G/ws8U/jlch3ydwtfD9ci/gP+KvwL/BTcg36DwjXAT8k0K3ww3x1+GW+BW5FsVPgC3Id+m8C/h
l/GX4FdwO/LtcAfyHRBFjircD/3xF+FOuBP5INyFfBfcjXw33IN8D/ILcC/cizwAh5APwX3I98Gv
kX+N/DwchsPI98P9yEfgAeQHYBB5EB6MPwcPKvwb+A3yb+F3yL+D3yP/HvlZeAgeQn4YHkb+A/wB
+Y/wCPIj8Gj8GXgU/oT8J4Ufg8eQ/wyPIz8OT8SfhicUPgpHkZ+EJ5GfgqeQ/wJPxzEo/Aw8i/ys
ws/Bc8jPwwvxp+AFeBH5RXgJ+SWFX4aXkV+BV+JPwl/hVeRXFX4NXkd+XeE34I34UXgT3kJ+C95G
fhveQX5H4Xfh3fgT8B68h/w+/A35bwofg2PIx+F4/HH4AD5A/hA+Qv4I/o78d/gY+WPkP8Mn8Any
p/Ap8mfwOfLn8AXyF8iPwZfwJfI/4B/I/4QTyCfgZPxPcBKGkIcghhxTOA5xZKCfa7ADaq0aWFbF
KSc+hxdWBfwpgEq5IQq8wPOCgAV4UQD8oSmtMGIqeJ5TflngWTWtp+IwhbHvxXAlkcQPHRqdhuo2
ITCqW5SwcArDulWLgloQRBGFyKtF6sMJvCjqxJFWBIGKWhBYEFgtrcfxmMIq38+gkkjiBw6tTgsq
lSohMGofUcLiKYzqVqS/1IAKGjXVLc04pVtRRFFzoqgCUaWj9XgBUxpRPH2nSSSRxLeCzqBD3XIJ
3VL7SHWrHgUkHGiMoQg1Gl4AUasBNWaIGrVBPdLK6XWrS+o2iSS+E+gNetQtf0q3KGH1N3SrQaB0
tVS3uhHdagyakVYwqVZzajXVrYHW40Verdap1afvNIkkkvhWMEgGfK3lE4aR2kfUreYUIPHiq0Vo
1FotFlDrtaABrUaj1UrakVbQGmvUvEajArXKQOsJIk/tcVK3SSTxXcAoGaluEwIb0a12FMO61Wm1
Oo1GRx1fDTrWWszQ6L6iW42GOtFUtxqVpOhWLVB7rDl9p0kkkcS3gmSWTumW2kc0vdpv6lan02s1
er2oBo1RDzrQa3V6nVk30opWi8ZY0GoV3dJ6olrQaiRtUrdJJPFdwGQxAc8LCYEN61Z3CpB48dXr
dQad1kAdXy061qhbnc6gt+hHWkFrrNMKOh0PWt5M64kaUac1abWn7zSJJJL4VjBbzVS3CYFRv1ZQ
g04/imHdGgx6o05nNGIBrckIejDodUaDdfQ/vqI11utEvZ4HHW/RY321VqT2WHf6TpNIIolvBYvN
AoIgfk23esMoIPGBldFgkFCpkgbfbNGxNmCG3mi0GUda0aNu9aLeIIBesBr0VLdqgw4V/P0MKokk
fuCwOqxUtwmBUb8WXWbDN3QrGQ0mg16ijq8eHWsjSChko+OUbg3oNosGRbc2Wk+jUxv0Vr3+9J0m
kUQS3wo2p+3ruhVRt8ZRjOhWMpoMBpNZi2+26FgbFSFLTmmkFYMR3Wa10SiAQbAbsb5GpzEaUMHf
y5iSSOKHDrvLDqKoThhG+j6KLrNRGgUkPmg2mSSz0WCmL6wGdKwlMElGs8llGmnFaES3WW2URDCK
Dgn1rtVrJAMq+PsZVBJJ/MDhSHFQ3SYERv1a1K30Dd2azSaLZLRYsIDRbgETmCXJYk4xj7RilNBt
1kiKbp20ntagoX608fSdJpFEEt8KTrcTdas5pVu1Dq3rKCDxD0QWs8mKSqUvrEZ8ITaDxYS6dY/q
VjKh26wxmUSQRJdJMpl0Bi31o6XvZUxJJPFDh9vrBrVaKykJah81erCcAiQ+aLbZrHaz2U4NqAkN
tBVsFrPd5rWNtGK2oIy1FosazGoPraeXdNQem0/bZxJJJPHt4PF7QKPRJd5UqX1E02u1jQISH1g5
7Dan1eKkBtTsdoENHDar0+63j7RisZqsFp3VpgGLRrZZrVaDSW+zpKLuk0giif9++II+0Gr1CYGh
Xww6I9gdo4DEB1Yup8Ntt6W4TWawooF2gMthT3EGR/8SqM1usdsMdocWbNo0h91ulyxGh0222U7f
aRJJJPGt4E/3n9It9Wt1Eji+odsUl9PtsLlTsYBNpn+5N8XhcLvSXSOt2B0Wh93gcGrBrg04sZ5k
NTptPntSt0kk8V0gPTsd9HpjwuO1WgH0Zkg5BUh8IuxJdcsup1e22sAZkMENnhSXNzU7daQVV4o9
xSWlpOjBpc9McaWkmO0mtMeuf/unuZNIIon/ANnhbDAYTAnLifYVjFbweEcBiRdfv88b8LjTAljA
PSYIMvi9njRf2DfSSqrH5Uk1e7wGSDXkeD0ej81l8bqzUt3fy5iSSOKHjrFFY0GSLAmBuVC+Jjv4
/KOAhAMdDPgzZG96pisFPDmZkAZBv5weKAqMtCL73D7Z4vNLIEv5fp/P53Db/N5cOfk1FEkk8V2g
oKwATCarR0m4Ub5mJ6QFRwFW5UZmRjA7zZ+V7U4FHxrodMgMpmVllGWMtOIPeAJ+WyBogjRTcTAt
EHB5HUF/Puo+iSSS+E7ADH8dlhVYGiMpGHgY/douwjAw+u1eI6Df4DX8R5e1Ovr/pcBssdrsDqcr
BbWdMLPB9IzMMVnZoZxcCOflQyEUl5SWlVdUjrQxsW7S5Cn1UxumwRkzGmfOamqePWduS+u8+Qv+
uwfI/mfVVHAZshckbMCAPkYW5EI5VMJUOAMaoQWWwTq4Dn7Fbo7HgX6v2BjIgTDenwDT8P4s6ISz
Ru7H3zjtT1e86+R13/h+tG8gUtFcVlpSXFRYkJ8XHpubE8rOGpOZkR4MpPl9steT6k5xOR12m9Vi
NklGg16n1ahFgedULEMgh0SdtS39LiHkRvepNXc4nfL1dJRNlz72R8H8tULuf6mU+i9pz7+kvaPp
M6JgjU4K1E6kDffDpLejYIkSaxRoL8QyHXsarlTXvTxQtyzqqu3u6MAaEwOSLzrpo/Dwoyht92s1
tYHaxZrcHOjXaDGqxRiW7eknk8YTJcJMqqvoZ0DU5+ZEzaEok15Hw/JoZEcHRgITsSW8Yzl1ZyA+
uPOrtwCrjcQsiRiJ8rVRQenXtywa6YzCDl9/zmDfzgEJFnWEdN2B7s4FOHOd+Iz9wKbXLW2m81hH
Q8dSX1SFjSvkxhxf3VJfX4BOR93SDuTARKx12nzMVte2bPMPuqNmvNZFTaHoZCwxef2bbravzrnM
R5N9fdt80etmtnz1rp9ya2urEx+4ry6ADWJjdctrcCjOcG5OYkzDE9DdsZz2ubyTPmfdcl/fjsXK
s+5UnkEpWrcUF6bz35Xq66vrDtR1d3bXJFqvjUaalQs0z2tRBohTN7F1OGu4AN5RKXc6Jrb6E5Pd
MKullj5YoHOiO7HsozkdwzmYUTdy00efoB4biPq6fFGY1RLAomWUFpdBX1eZsnn8rQRrNZ6qFeXS
pYCv7zOIko7A8WNfz+kczuHTpc+ARicFJnX09U0K+Cb1dfR1DsS3LAr4pEBff0NDX09dB/ba2IK1
BuL37XBHJ+1sjUodS0kFzj3dAZNmtVS7/abWkWTjSBJwS+HG0irDwVnA3/rhC84yNLf4fThRs1ta
3ThPLTTejPHElW4k3LhluMbD00bnaHHZ6PTUDkf9fro7dwxEYBEmoltmtiTSPljkvhMi4RCuRwe9
Mzhyxzab3tkycme0ekcAe7lLOaJsUTFj9Nco2S11SyuixP7/uL04cT9qqW1h3UxrIsa4WRrThFDp
VVFHCONjQn24CE8EolIoyrUMuqtafZIJTwC6ek2BhpnzWnx1faO7IJEzPFK6D3CrBzqX9g1LiW56
PApq+gPkspn9EXJZ07yWQxKez5c1t9zJEKa2o6a1P4j3Wg758GhVcpnRXJry0RQ00A14JyMqt9yH
IgBblLsqJUNJdw0QUPLEkTwCXQNMIk9S8hC5EFE3v/tOUH7nbZOMyxfpfkYnlUSeJ8/uNsmPYfgT
hkcxPILhjxgexHDrvqC8H8O1+3zyNfvGyPt2u+W/77XJN+91yT/Zmy1fvTddvgrjkb1kLxY3fkyu
3O2S9+wOybt2+2XYTWhHC3ZrpRLjYflw+DAb/jWBQ9IhxojPfDfxfdn7JSN94fsi8gXb+xmRPvV9
yvg+aPyACR+rPjbjGJv3dM/TzME7x8h3HjTJ4YPVBzuiPdGev3BvvRmU38AQfpN2cPA3OBDaUfwu
jDzZO1Y+iuGJXp/8eK9JHsTwAIYrjsSPMMb7Sfx+0n+HSe65g0i3+G5hdmzPk/u2h+XtvYXyZVud
8jYMl26tly/ZapIv3lohb8VmVh247kD0wEcHVJHribTAtyCygP0EW7yo1ylf2DtV3oLXzdjjJgyN
vR29Pb2sZPTLdlu2LPB+2eXMllWsX7aYs+WcXGN2yDAmy5iRaQimG9MCBp/f6JUN7lSPHn0WPbou
evRg9EbJpNPpDTq1RqvjBVGHTo4OPSCdZNxiZCL8Fp6JsFtYxgjVMAN6QWVEi18NEc8qTDwAj0Mc
RHelKBsrRJktF2UoE+XGQhI1N0BDc03UQvDaVBMtDDUMiDArWhBqiKob57f0E/KjVsyNMpfh8jRH
VZfhLmrG83/e/JYB4qK3L1HMAcYGyJZLLr/cPRprbQ15ot0NTS3RHk9rtIBGfuxphRBi9ZrVq1eH
/i/oV9Peu2fV9L+nosaiM/peYGL/++8phiP6fmAiGa761TYwio2OphK/XwGEzlPy13yjO6USHhO8
lf5XXu4oyCP8NZerC5TPcOKvKfzySDzWHf/sP3PivglxOPz/gBxlsr5tv+QKcinZQprJWrKSnEeW
kQjpIq3IF2NqFdyuFLoR3iM+4iIGQkiAmIgAJ0g68RALUYEG08ewzKdKyZ8q/CmpgE8YZbZgB4YH
4C/wJhyHGDHAEfxZgj8H4Hr67UjESzJJOZkCH2Dr9F+mroV+OIRl/oB1XoS34SMiknnkfNJHrmT0
zGRmHpZzklqynZnOnFAFQSBrGTNZwt5HPiU8sZEg3Ad/ghfYaPxdch28yuYyB+EC9H2fIkUkwt7I
ZrMyc5S5EXtiqIEQ6N/gYvFivZdnVEBD+LGXH1MoP89v8pvSkQiW+ucWDk7QK2yhrxgMPIq0EncL
rZ0RsbMswwh/5uBl1ZPsyzO4do7hZqhJW7jtzaE3ITxUEK7OzyOsnyXYHrNybOy+sWRfbAW5kjt6
4iVV8J9hImKbN7MPq3S8VWmzJBLgBWyUJfC4ke1ge1iE6nEQJGGV0CuohLA6omawg+OFGKC6MGwu
L6d9BJQfla7q9ap+DLx16CAznQb6hvRgrJs9iD3YoCqSM4M0MA38DKGdtAuryCpmFY8tk16ml+8V
DAIQt2ikZtQ4qLrbLn1K+ymEajqONuLPYEySudRvMxCBZ2xWs8NLHOzB2LbBQ4cGybqZe6qrGurH
V/2kMdb9GnmJuPHnpdc89Yc2ro29csNtsfc3nv/gZPo8N+Hz7B15nol4kEUsE62NbKOlg+lgOywd
1h6mh+2x9FgNZlC5MRCVSjsI9zikz7/2PBIj+IvHk9ISc3ERkzmWZBb77WZ276HB2LbGvZXj6xuq
qvfMJOsGDzFVsbdiwdc8kwfXbiT2224gaWs3Hqr3vBYL4tMEYj9ilpPtOP/5kaCRGBknyERGmYVJ
mCmHalLNaJkX2edVuDuZXjTRdOZxZugjqEnAwiyP7f3r78n2IY45QUd3NsOzy9gMbC81IpFnGQk6
6FsrE+ZmcLh0OAAI08q4J9hltBLDEx/W2xA7rHpY2QclESO+AJPfMqwVtwKtOxB/N2JQS6XgpET3
MT5FYRgPsupwft42bmxo26bfqYmfqB4++U7sMdbOW7+8RWjBfnvir3ER7kNw4HlWF8mvY+o0Uw1T
7WuYNZoNhg120b2vwjzVzJgF/75ivo5neJdzu/JWne7dDjqiw8GaEnut7Tj+5ue1ESsjGEggLSMz
gykuMpeOJ4UFdofdzEkZgTTeJNkLC0q4yMQpU989cPOx+qk1E6dOPXbDbe9Ora+JbVq+YcPyFevW
rWDeOxx7tr2zq3vRIhI4/Bvi7Vq0aHH3othrh4nhrbdiH8W+eP99fAqCJ7TqGPc0GKE4InO39vKE
53W8gd1PjLcYdIY+lmNuAbaaXYUyCbd9WiAdL5cU5VXTZ87PyyKoZn9xQQk+ZSnGVMdOeklF7KEp
W3OKilSkgRQSFWv5xGRzNVadCNNxH0JrMJX7ADywI5Jn2KiXShmT1eTXp5uK9EWmyaY5pkW2NTYN
MEaj9hqLwKReSzqgI7UHelJVqdQFsSsrlMqI27fYid2+U5akkeWSPseHMpfjurUpz4ibuba5JeI2
MlqnzLidYSbkrHROdc7n5jvP4s5y9jr0ba10xkNZpLgkiGMoLqJzLARMJcFCn8pm5XElBD839cSq
S4l+5rozL96w4NG5vsnEtgMPzIzLd80fyGR++nnnCzPOu332maumVZIGefzfnr08tq358lQ62p24
OwLcRxCBqyM9ymjDlLRatsCtNReEtGOltLGBggpthbFobFFB0bh67aSCunEzSat2pmtWVTdZru12
dZadT9Zr15S5x4/z7u9A7eTl5Vwjq4sEvd50jdqV0VcxQ26XGTnfsT1frhin0rFsTWJr4c4yO8qP
h8NtYdxgOB3V5nJknCV6quG4Q2grEqMMpAUzTYVe3GsliXlAvYeI6avJ0ZnB7ZioZvMS1UB+RdOc
5jd+cSj2RVPmnA+7Ki4Lp+dU5ef3Vc6afcYF2Tk5YwOZyzMWvrQkfRZJ2XX5X+pmNV67ufBc5r7s
nrZl90yorq0IkslF0yw+1+TaCZONEks0GrOlelxuqWTWTRhHav3j8rPydy7c+Fu3QchGxTXHT6Il
OIrehR7OjUzPEgivt+vDwlRhkr5VaNavEM7UrxfO02t1jfoOfY+e1fO8wKuJfh+1IL0cy3GswLMz
NO0aRiOodaodGkKMMh9GcSpTVoizU0BPEZwtZaoK8DTZJr3cphokbW0kQLe8CY+XQmSu/dHYrqEw
c4hse3ToodgMMjd2I5lPUtiOk1czKUNv4x64AfdANj5vCHoiZ2iV5RfdYq6Yqy9kK8VKXaFpAlsv
TjBNdbSITdnLxHWi5PWm7MtIuzaDl3mNxnAN7/Kl7ZAjWlOpbN3ukzVWPEFy0UvQKI+LOx6XOHQ8
PLrC1DIqy0sSS4sn978ubWItcSC2xPHiJVz23KYFH15z8Iszsuc/ubR6TygtEE4v2Tt+3o3jc1SB
oUlye3DDg5Pmn0m+XPPw5Gn1pDSN1JdM8WTIkdqiBoffJhvZKbE3PmHYcHbp3dSWX4rjnsIdh3QY
B8sjDXnqQk1eWURdq5lQ1pja7G0MzA52exflr9asMayRVrvPTV1davbw4f0+uz1ln483C5X7eZen
2G7XZeF4JXrGVxd/7czE5TGjATmOY8YR04lQjk/+a8dnYr+aAokxj4yWfHUirLzNSjPpwTqledrM
p6+49OUZ8zvmnbmIlD9Xf3tKhvvCWYPP2Kff1jX3qkhTd6xcTs9ODy4qyukYw+RnpU7L8TeSE6sf
qZt6Rn3DHCLd/zuSd17PRisXe1HvP3zL2PIxORW/i+1Ma2usb0tNtVmNmrGBDT/Plj1e3B378TwM
4e7gYXokD90SsgNNEn2/ZK/leIaw0MDMZ5hsppqZwbQzq5gNDM+gQ4WOLVrthMJxk7bhHsD9OlTQ
pmzV49sGCRorXF4uNLQw1swcHmJVV6huPTFXdRfxoAXsir/CTec+gVQYi2fTYGQ2m2XNKnSOy5/g
nJ7fTNo1raZ2d2vOwvzm8ubq5UKXdrFpsa3LfVbBRsMa2xrX+gInz4SL83IiOU057cWLcs7N6S0W
i3UpOSrWt9+CK8e6PH12elzLLnep3Q7Feim83ZUzvI41GdslqaxPVhO14mopy4m72FRejrEQPauq
j+PJ1UaPb7u7oLKgoYAtqCxW4VNW5mzNUmXl+Ezm8jYalAPcqvKn0dUsLiopLaaXoD9xfOMJRRJn
uoEkFtkxnliUlc9UchKi4KbH7oi9cOOx6dPqL77+ovVkChGIlZRvvWz/1bGu8zqDDbIno3Zaamfd
2DHylB7/5lCo7qoLfHPkYA657qGTE6sqfza/51cT+Kp7Luh//bHblt9UwVf+gRkzbZ7ZZCoNVNb4
dQF7yZyhzVOm5hlzpMxVdUs3WKyO8VQlS+Nv4OnwoaKSjkhteVpVsCpralp9sD5rnjTP3G5rT5nn
XlhxVsUaZh23ybh+zMYKs9VXtt+Rs9/B++jfmt7Hu6wZarUnA1VSXbDdo8zmiDaoj0xPhBFtMAKv
oto4dR6UJsRCJw38CUdjVBgjc0ZLFpVw2R2LlsceOjr1l+4x3lUdZ1xdUjlNP/eqVc3XVDd1kenE
sOPZM+YviF0YzvJMy86c7Jczs9MD7WW5yz0sW/Xr2JGz1641CyTd4MvMzt3WXlCcFap8cM+HJBdF
E/t82/qfhnypbr9v6ZRJ7aluu0OnzaLzMx29xyvxbZF675MihUbOyDtVMifzY1RhLsyXqaq5al5L
nmc4/kXheZH/ywxVu2qVqleFgCdm4NtVuA0nIeFSVh9P+Nkmv4U6lnNjfeT8cdS7ZF5A/zIj4WEy
9PsmeS9qUkAbc3tkFs/QL8thyIWYodawqos4ji/ly4QGfqIwn28WVvKLhM38OQI6LSLD7unBgxk0
aqISeG49OlQsRxhWxQuiWqPmNMBxDAzE/xoxa6RSzo8ERh0BnawjHJVzGzqdbbj1Uc30otgfqgL1
dJjObYJNnKqtlbRtk4YGBwcVFgfx9l3V6ulqBtpa/X58HULlaxneG1u9ZOi5JbFNTAa5L3TvvSQ3
9hR39ORKxj70Pn0/O4InzwCO0gZBKIR5kcoGawvTbFvGdNt6dD36cwOixZxzJXglL9PhvcPLeL2C
Z4/I5u4R7JvNOUajkL4JBoq9Ob3C3UXS50MFOL/KpjuO7nc1jbadM+xmJE5knPWvOg7k6y6G5etJ
bmDutJanfjF0PlNz182zZjedu3T3bTFrejh70znBqvlb0ot8C0trcn82pzn1Fzsrq3LJH1YcKKsp
4446s0K72lbcOFb03EMeT59qltjY73mTo37oycnTLXomdjnjcjVRz2wJ6u5s9EML4dJDEIpvPYh2
2TaQuJoG4r+JzFbrSsPjkUSP0xNgM1RZYlgd9gQCrUyraq6mNXVO8Dx2vdoYtlRbVll6LSqLJWWX
TuXLzcvtyO3JVeXmZuwCiyV3oBiKZxS3F7O+Tfy9RThJbdLnBYqpblMIJwjdsFCIQwfsqxbLTo1W
Blox5fTiFRNlV46rkpLSQhP1aXi2/abYO4sXr1q+uJPIBxb+JFK7MisndXZJ6Zb6mbvHV9bPqBp3
df2k7RX5ze4xZWeW1W/xLOrsJGlH+olvSdcKm8kStsZ+4qzx+XIKK8sPX7rzcElpODvoqXHG9rty
JJsdtYC7hB+Hu8SAHntVJLvVPNu9mFmuP59Zp+ftu0XWsVswbtLAeiw6IMtyRG6UWQduCS++S7ZJ
n7YldsOps4fuAtXoITO63vy4I7tWxk7eOfQJk3oPEedd2x9bfdaayg0bOzu3bxm3bBHzzhOxe1tq
irij48oWxh58es/RSo/t5AKXv+qPdDXxKVWf4FNqYXIkRb0rj4/wHXwPv4WP0u94JdwuhtXsIiI1
SEbJViqqRAA9r+4ld+vo1qVOH9qd0Y2Lz+v3m0Z/VJ+ceFRVPFTPXDK0gbmXOxp7NRbH8OORnt/D
ntVQE7Fyu/KYCNPB0I8tyC6RFVgWaJ8mtR7fWbRh7Qwtw3A4OxraKzXeocIwKn2kU3Kqy/eGmpgN
Q5fELlKFVP2xv8VeHdqKvdB9+xr3Bu7bIFx9CIyJ/aodiL8aCeJWDXAhIeQIuFvszalncv+HvS+B
iuLYGq7qZaZ7hlkZ9mVm2AQHmQFEQBQGBRUBFxB3IruMIowwiBgVRKImRk1ciVnckhg1RmMSjVGj
ZnvGaKJZ1KcvMYnZE41RY/IiNN+tngaJ+r73/f85///Od05sqbm1dNW9t27drZvBIZ/JzpPP0c8M
8AhZaQ2tCaVCCTLJEECFhvK0VZWmqlE1qRiVyrCSZ4JW0Z7W0JEwKBTJVCrzfIQi7BHYfx4r85KF
y2jZvnDtzcLLoscZb9URjEUzDSJMKhYxdgVBDodNNiGdFpF9vkOCoa1fIiGPvVQm7H1aaBXy8B7c
ugortlgCq+L6Pz6u4tlBaVlYhpF3grdwltpV0CsXP4mrwKXeljBS2OKVG2CKGZA6YH/jb8IfFIXD
sJ97D9hfxd0fZLfQj9o4O1fEOblmbjcn4zhWIacxq+epJrRXhVQkKKA5uol1b30hKVBafFr8PTae
/VVo7nhXaMbNVCL8PNLhZE93XKTMJJsAKvSSuGayPYRnVsloBb0Kc8pNiiYImjchGtO0ysOosqns
EIMwIo9IAN1xI06MTTvixOg5Xke88FBdPH2pve3GDbryxg3M0UcxJ/zenkbkq3fn9/Q7sI4virMH
TqCw1yofGoz+Spmnj4/Cq6mZpBL8m7piAdEndlv9y3/yhXv4/4Qw+p0hmVnvt03dmxlmqxztmOnr
IxN2UJ/gV0p2pKRlatQ4Rm9Mioutn0SNxnpJyq8CFiwKtRvAmj0KqxYhJ3ngLmfgFMngtOvcmZe0
rqwAc/XW+8C0PezpWyOlkyI7C3N4oFf2IxoEcRCILmMXw+EApUVJI95DoVFq+UCFURlBRzNWhVWZ
okhRjuSzFHOUrfxDytX8OsXjSkM/xQRFE9XEMgoiz4FqfSLb7KFNpEjBUgqatzJpTBHjBBeADPCF
ZkaJGFrO03IlzxJBUCM12JjOI/vgMLAt8ldUQIClkFAhOtLE8opmONZmAXsMYZ/FAlSBT00o47FZ
dlZoEX4SfoOftfh1PBKPwK/TX3c0UovbA0BGvKgfJYo5UTcctGeNpOxyagXVLAcH3puikEwrM8mG
4izZbLkMUX0wllFyDlMMLaPpUJkN23E+LsJO3ABHB1NyOyAqb0Z7lXDYj+wFpiElpiQCqGaGaBQg
wALSbAESCt00EMfBz0KFyVOovvJsCtwVCtwVqkTeRDnlHqLrDEN267LzxtuVckxRLSQYkskXi/mu
CeBooMKZtVFYpBoKGScs71gibMTvUUZcRAvtFDgUO+gCt51glwKtWmQEHeyXr63Q1DO030q5nPdd
CVuim9cfDSdGQlSHHqAOzUaz3Uz5yZv4V0zaG5I6JPZCVIe3xdciru6OUe9wEpYOSZ9wYcvPQjM1
e/mb2ROnCHUZfQbUThlUXdJkCTfTt8oOp4+fKMCGxMamvPpQ2iS9LysM8g0zTUCSZRsvWjYjarTn
eWj9tdHagdpc7WRtgd8o/ypthX+TVqnTLtAYNfHGwcY6I2304lal6UbqmnS0TmeQr/KiNQanETs1
GM0LNAYaNBqziRDF6ZsMQJSk4yE2s14uhC2JlxQ9RC1imNZxBJzRP5MEEhaq6+kpMTgmqVdl5tJZ
k+f2jgwHl9UiTHtRaKFaW1/PH1P62HKGTxrlo5ULNXqTMbu9HxXS8Rl7OjgubsPsZ05lggzO6Pya
rWB/Aj/n4H4U0tlsV4PscM1QsMG8OtH4aueX9iEAKH0DfPvh/gGZeHjA6PhyfhZf7znbpyHWQ0YB
r3T+FiaITgPH0hy+KogxyW1yp5yWy5VgNEyWef66eSZ/cWt5mAqhBOLpfEP2k6QmpMxEoWQrJLFk
LAZLf12CZbgu0zJRV2CZriu33K9zWUAsiUMLdsxCiRIqekcYbIeYofJmeqYxusIW0dKE/SnMA2mp
EJYKR/YLl2f3bsC9loTWhkUn548acyDv4DO4HoevwkZH1ETh1hLblOheSRPn5a0bt2ML/vgfwuX0
OFw+pcJDre+XEDvU0xAaMPD046ewPNkibBtWrNJrBvZKSfPXmQKTjhK9BmEKmy1GC9F2f8w8CucX
TcJN7KQmklfnOS1v55t42m0BxAcXovLvsvVstmAVmgUrG8K8eGsk86KYq94GVv4MzKlDSfZwnZz2
WJlAZ9L1NE17apuadY/oKJ3O0+6JuSYkXyHfAFthdZtmKZEcD/ODBTYhP1hGDHJB7bNnhN3Cfrhe
xC0tKx95ALdQAaC/zuMI7Enva5/yeNvKTfQmWJ3EP4yYk1hoVyLQV4ilaNodtmggYqHFsIVYHo62
kkUtFjFZJm6sMo4dxOaxRayTZcn+kbY+cma8jGIZVtYCd7HMApqie+FIajDOoWrxPEoWgkLoQWgQ
XYfqaFmhO76BHw4OyASSdgeVK2M6vhDyOr7Aq3AlrmRP/2EFw/ID4w0TDgJE3iaWBY+3BxF8aZbj
lSC5MpriNOo5qB7cF7NCkyhSoCYAUhvVdnWRmnan/EDHozRJY+5Hys7PXwK1Cu7i50S90iYowAxI
xExzcS4lRdt9ghLpMWpt4ggqncnicvlBiiHKKdQoZjw3mR+jqKGKGQc3jS9XVCgbuSbeqZilXEq1
Mkv5VsUS5eMQ0z7Or1bcwLdYk4qiGCOlZayUiUmlYplkbiAfp+in9GCIX8cHxyVSJigUXTWe1ETL
xgMOFEEE+s7YB3oFJfK9oWiiMKX0WACccYIIcvImGQtOMM/qcRAbgvuw8XgAC6xnx+IJbAmewcIW
sFopqJRK3PU4F/QWFGQTxH3whMKTe1uoEcYJvwrtUNbgR7/GetyE2atkU+jj7f1gYzoZTH5QD2lS
oo/tTiXFcAGUgWM0FOKAaC5RkUMN5iZT+VwFB1aJ82jE9XQ92yCfw89Rwv4BJUipYGUsJ+cYXs+H
8FQU35+n+GYFrcAQ9Ss5OQJvO0qeLJ8tvyZn5C1AKwexOCOjiYNwEXSSNlFmJo8NSM0HAIbUFMAV
hZJhIBK4nUsDu28VH2Bb04jxJ0q6cObiI0e07nAbYA4ibi0p2CPEPBaazURpu//LGCFDOAwnbDyl
7biFD+B+OA1v6/gd/yB4U1eoS4INn+qIBn06tvNLZh+zEGmQDVXYh2p82Wg/3yw2K3ACOyFwOuvQ
TA+cFV4b5eyjwr8YjRbvXnaVJrFXr9CtFq1qq7e3zYhtrdbX4qxxWBNpjKQiI+Wtfgdi3Y/vRI82
jphR4gdadF3GNEGNeyZ0fMQq+IYkZ9YvLPGORx/gI+ZlbY/ul+zh62PP6FfTO2hsREJtxsZz1eVl
OHJD2+oJx6PNyRgvwPFYJzyOw3+Qeal16Qmh0QaDZ/RD3ql6X5931t//BITBvKxwaJoOazRRh453
MED99s4f2FSZAXyFINBvYZk4M2icpkLTxDb5yQxr1VoeBbTR3pxuITpolPkoW7n9wSJNEDyLZLl9
Wy0ijq2cKFGS1dVLeT6dO4+bKly4cN9yu0bYiivzd8785BthWcXC+KrYXkNiVzxMpYPnticyIklm
6Dg/KE84Kfy4drMxqOOEWvEcSOx42J2ZTAvqhZbYQ210Gp/iFxtgpzOZHC6Hz/HLCMg2TjJON841
qSNM4Fsa4PCRMExNDqgXNGiJs2bTYq3WZ52HNi0Mh4mZUGgMCwtah7y1KEwb1hRGh1mjcFhUURT2
Xyg7EElSAyT/Q56/XiaukGgvLW4PlO1Ob7oz2CSf7U7SdecwE+N1akxdX3V94oQSx32TrjTXvTEm
3ivFElWS/sjjG1ZmzAgL6esdX7A/eEhW1mdrnvwqe+iguEjhpN7m4x2078nNzxm9DNFewslIK+zQ
xM4vmCuwQ57IhFLtkcMVw/1namlTbxXRhiCKeuS7Tq3FwWtZb52BakWvhQQs5A6YgQS38KVdJvtE
UC+MIoIXGkLpbuMOrmQP1JkrQlvh5mknb+YPy3ijuHxBBq4U2iLGhC5fXjs/tro+ZxgegD1WfDoy
O99ixp/dCqF6adUvPvnMmnDAk+xUO7MIeaFAVG3PD6MsinhqgGIwlcvmKgarc7QT2UmKggCHbDpf
ZCjycVGNvEvtMhjwL4GBHn5b9VrEabl8rpSrE//YdZuHN897t6KDwdZgHIhbNQeC3DEieU7f5cR0
nSezO6IiXJcCXijD3YlTpr39GLf/5dozqZFzzi0UXhDacAGOAjVpENbT05yVizj8c+vDeVbhYmw0
tmE/7I0zIchvL5hZW9UAEmiB6LJFFgy6024Pg9irzQsrOfVWnUZF/pKDv8bf6A+WjdN5tGqmQBBP
qUBqLoObKSqxZDGlkJycJj4Gwu4nH0HY7EWOSmhCPEgR2Qa6JcA3N3paNvYWbgpt69df+GxUSxzr
IdfnzOBvtD9K19wwvv++kifSIExgrsB5iAAvssCeNMJ7RJ8R8YXehfEO72nx87g5HvWhc+KVXmG+
lnVmbYQmdq0vRKjrZIE8HxDWywukIyFmYcCBvqCeiJ8f1xWiWslJFt+vKAy/R6A6EJMWdFtuEu+U
m4mjR3/9SP2l/OhBr2eXzTMbA9OfKv6pE40YOuho+aQ1A1W4UGgzTgxbvryxoV/lgqfODUxNDDRg
P39LeIipbIhXQirsccjS49lDRlgi4to7cYdKs2Xl5uYQYrW2g1enhxPgDRoqFHt5eg3QOb0YrFVx
azy1aqTCQJavzbfIl9IqW1X7faRcAlFQXUSZzbq+XdkP0dfrR/juxeqFtWqdITcztjwF5KKy6MWq
vSepPhmLTYBWaPtXoJM+yh718UckRtkIRaD07kqs3cw+5Q4baYgYNZh5ErWyTyKsxRQexRfxTnAy
uzzMtK6n8+SpPKUn6yiEVjyXKd2IdV305cHMSnTMPgYEiFcrjdjI98FWPg0nUWn8CJzNF+IpfDWe
wTfhefwi5TZqk/IwtUd5nPpV6UfeoVkMd2s4I0dxw3nM23Q+ifwSyqaEgBRT9Kud5+wBANMKpUKO
OAROmULDxisHK/OVdUp36B4MylJBKRW0+7mQVYWRmC6hOLqV3e8hBVBAlBiOu2Na0CposfaIhTti
YTssMxnwVSRPEeJUufRsFrN5QqHwdgmhG7fiDUIV/r5BWC4ztE/BV4VAN/2UXuRskF1PfjGiVWKk
6LkSRpKtdPPQzT8Y7L5PfgbOQiS6z57OeNOBXoGRvlu9nw3Y5703gItY46/V+RgpRs2vMWg1GnVw
q3G7D26ldKpW9XZEaSn41zsK9bb1HtXb2bsrLdRBXqy4IckOkCjqF50oPm590uNJrVh69ehkbghr
Ob0+a1BCWSTBs3D71JrttqoTJXsPCWvlet3wwX3G0oHtX1GxeXVhYWaLb/tXTOncrLzSokmV5092
hFOx+bXQbuyWeqDu3lKv+b+Req//mdQDSqLQE53+KRsBOl2JQpHZrvdq47VmcAc04A2EB4ChDBP1
iPsZYVeY49a+uF+/hL73yJizEcIh4R9wHcKZOATCnXQhMzQ0zGSa2Lfv6HBzrxCzaUJy7AQqFlTw
UfDYvLAPThWOdJy3NE4vXRQZFRLYu9eSqZMXR/UKM5NTuV0oY1OBS8Q6ptktGVSGJsOUp8nzLNeU
eYKzH8j7rNVpPTTB62TeygADIB6iDuBbPfab3W4M8Cut240xEFRFzdfFrG5Pxo18akHmsL2VRYuG
ELaBK/Ph98IyZyO4MmF5kcSVWfrV8BGjosKFaLazHnyZE8JPT68GX+Y9NbdV1N1lou4muKbYexFL
nmuaZJpucmrnmOTEius1xIzjgD8ZcklV98DTrLvDjN+ljoW28c853v9VNONTFgwT1W+3HRfKKMXQ
IbdNOSjcj25bclHy6HPMVKRHSfuwh9ODAqtHVIQPhJrMGo1GqeE5hAxWA/aQt/L7PbuSK4BhWofF
/b5D6F2HhT5n8qkIyZ2VQXjXsHu4p01Pe3CcwbdDy5Q+UzGY/MYTRlPA25kDPLKhFrs2zprlO9Ra
jxuVjQH1oXIjcerMEOaxJihSdKA9/SOZIHoUBEPEzTObw7cGaeUEVU+SopOrt9Le5siF/rqFZn+5
mBNRiDmROGcclruDTX2PrIjF7euRtEih6C9Jz7J18d6S9LpFGv6Tp9px7qdCbq77iEOYOcIx4Ze1
N4abA4amJy0fPa1iwJjIB5MeWw2euWL+t+nGUScd4xr6lSU22ZcvwWUvfJIUgiM9+/j7mK0xUeE6
3ksTuW3+5rPxQcJXiZm26MjeXkovbfgG4oV0/kDPZp9GAWi4PVrBBrCURgkRnFKrkm9VKjQBAT5A
q5q8rICCNEGYU2lbFVyNnJAZH08euurcbxOSdLTonpCHXeHuoIM4IuJGkfyE9Ig5np7dv+W+D0+u
Xg1ae7Swi9Koh2YETtIHKzS67e9TqhtwcA/fEGpTxoeGRvkqYN1NnV+wPFMK+irVHqWQ+ctyPCd5
Vnk2yed4yikvltfo1oBoi4LtVlskmPARH02RtL9VfHeEaC3JS40g2fFufHRmlhfayp6te+1dPE1p
8MzNjHH2xZVzc0aeOU1d6PioYGZ4eEiImSb2JBg0pxdgIkNV9rDdLDh0ftRQdjzLkKzHYjHrsYim
6DI8nXLh+ylGjEXNvCaRJgVJsGioOaievI3IWbmRHIVoLYyHcM6dV3fjCWF5z9wIKpSSI6yXMFKo
FPLwPMxgzJTeepIpbW+nGSLdfcBibQPMPNAe+0yekjF+lDcTRUUwyTiNsjEpfLwiC4+k7Ew2P1gx
iSpgJvP5iiqqjKniixXzKCczj69VBFLKRR7YgxDCcIzcIKduwD4vghB6NL6PLcfT2Jm4iZXVc3XK
29kXDcWJZPp1B+BITRwYrdokJl9kXckXd+6FJEULxSBbjLWhJC+AmpWExADyX75NeFpo+foLYR5E
dXOOXMVpXx0itFK/diiB3j9oGfkhNPvDbtiBZiW6bNdYKRM3lprAMdRwd1Znrz0CgEDWU9mfTVCO
wIPpwfIR/AQ8lh7PjpVP4Mcp1UqS82HJ2Y8mGaA70hDZ3e5OjyRENjDk1c5Tdh10yJd0JyE04laT
fJLCveUSL+7MQRDnh9EyFOPe8ntlIiw9MhGWP2ciSAJLDLaUYqImgLhAdmHy1ZtCGT4g5OCnf7qM
nxSy8ShhNxVLxQl78fCOs4RTwWDLfIBTcrTMnsaxw9nx9AS2gmahAahlduD94BQtJm/JPi3fK6fE
LVfSctaXDqctbBI9jb2fqqfnsC6ZkiL0hYI0y4hIU4h1v/CqYZkAiuKt/EhefOpB3rJza27yikMP
qS4UMyxHCEW4sCvbRD2DEa7teESYswfQn4OXUWf+wPhpZhJCyChdWWhOj+sNzItXLM6FazZ5Q5ha
TMfSD8JRbGM+YttkkXCV9Lg+kY+Rf8elcLO53Xx/3sU/x//I/6hQKRYp2hXtygK4jnk0emzx+FLV
X82rV915afSaEs0lCPu3aH/Qlem26j7Wfawfo3fqL3qaPWs9jxkCDRMN33gles31etd7sPc5n35/
XX9df11/XX9df13/Oy7x986G0CO6v8MgDnV9cQQGVyFOginEoKMSTCMr2iXBDHif+yWYBfgdCZYB
/JkEy9G87nl4cBR/kGAVzkG/S7Aa9aYyyLdXMDSspQa/3g0zKIyqFmEW2hXUZglmkD+1UoRl0C6j
Dkowg7yp50VYDu0c9aEEM8iXekOEyW+OeVBXJZhBIdR5ESZ/VqiMapdgjNR0kQTDPMx8CabRfcxE
CYY5mWoJZgFeIsEygF+VYDn6o3seHgUypyRYRbUxP0mwGo2Ru+lVENrl30kwg4Ll50RYCe16TibB
gLP8pgh7ENy4SAkGfDhfEVZDu5YbLsEMMnH9RVgrzhMpwTCPNN6T8JCbJsHAQ85No4HgwzVLMODD
OUXYC9oN3FMSDHvELRdhb3H8GxJMxu8RYT9x/OcSTMa7+RBA9pRnJBj2lLshwkHinn4owWRP3XMa
xfHBEgzjebUIh5E95ZMkmEGBvJvGPuL4MRJMxosyxvXgM9eDz1wP/Lke+Hv0GO/RY7xHD/57SPzf
Zoqz2ZJMuY7S2pq6mgqXaXBNrbOmttjlqKmOMaVXVZnyHFMrXXWmvPK68tpZ5WUxY8try4qri02O
OlO5w1VZXmsqNtWWT3XUucpry8tMrtrisvIZxbXTTTWkp0e14t6rmBzVJpjGVFDtcMH9+a5iV3md
qbi6zAoT1IgLlNbUV7tqHeV1Md0z9O9CY1BNVRmp1JGpEmJscabI7kFR0qA+ZFBusQsmazANLq4F
TCfU1JtmFDea6uvKYXWgpaKm2mUqrjM5y2tnOFwEk5JGEa/Mgpx06K0VK87amrL6UhfBuaHSUVrZ
4174dFSXVtWXESbUmMocdc4qWAAIgbscMKAURpVXu2JMXWvXVFc1miIdUabyGSXkpttTVXcNvidG
4vAyR/VU4Hsd8KWUsLHH6iJDpblSRAQiHbCKq3wG4XmtA1Ytq2morqop7rko4FzsxhQ43s36mnqX
s95lKiuf5SgtJ2Mqy6ucdxBU6XI5+1utDQ0NMTO6WB9TWjPD6mp01kytLXZWNlrJEnVWNBaVo1pU
hopRNfzEIhvqh0xoBLROhfZy5ILWP48xQVs9VgH8/V09FVAvu6t1iDiP695r0UvoQ/Rb9GEoX0Tb
YHQctNtQEkC5yIFK4Y4aVAc/FTCDCQ0GqBY5xbIYWhwAVaMY6ElHVXCZUB60TUWV0Fcn1srhk6w7
S8Qt5i7sHOK4cvh0wV2kzyS214o8IL0usZXcTWgn65ZBbQZ81qLp0FbTfc+9eyv+j2ghGFWLcxFs
TKgAag4RB7J+vrgjLpEqk0hDGVhTNwY1PSgohVo99BKMHOLomHvg0P8ubgyCniqod/XUdWOVADPY
YHfItxzdPVPUHTP16Z4pV8TXjVmDSDXhjJunE0QsTSK3GuGzXtwrN+3ufakQV3eJtJK6U7xvhsiR
Lp6UiPd28SsTOJYD0uC+t7ZHj1PEuAxWKRVndPO5QVyrFMp7r+uuk7GlQE+9uLtuSaiBskzsd0KP
mwL3jrjXckgzlEpzlYslkdU76Sb9VSIUCXdFifI4A+jqWuleWFXfNfP/nEe3Zy8TZ5oqyXudJC+l
3dJ4b9pvS+if8UrpwQFCiZsWl7hel5yT+d20lkFLg0h5jXhq7k2pm8/Ff+JpuSTvd0o94aoLxtWL
dxJsZ4nUlHfPQ0ZWwYj/focqRc454RRY4WoQrxiRo3+W+hjxzhkwxgUUEQqnijQ6YYZGaO2iog7d
qWlv61jHPXVsDrRXAjQLZiAj6u8aMVRcqU48MS6Rurv17vdA63R0E2b5Hnru7B8r3nln6zAoq+CO
inv2jpJorAf5cUtI439L2V1YMUYmlUlhBjP9mCTGzgxkspnku2YY8y8tTDbBDsdC7e4eIsFOoPdu
TuSI594BsPRFcJ316KN/8SUdNHkkjbQId3a6vw1P/ENI3kj6ljz6FZLp7hHjIKRAfcGS4apiVzXc
Cz5yzphhJuSdNzLXhAJhrU5xxR5l931JYJ/ufV9wjztw9ydGVFVNaRVSi6VBnAdLs4HHC5GAu6aV
PiOI34kY+kH6IXop/TAib+z+E/0BXUZsEmscwvQycRaXNJs0X0ApQtJXdqKASbaWgHEyvveiYYt+
U2E5tbElYBg0ZVAYxyptvIy1qGnKn0W2YpnCIsMMbkmkMLMx3zbaFt2jJXBzcHMgGiBeI0GA6kQT
US4evFRy2cw9JmMMHR9cb571yDfhfWK/y3hhZ1712l8yXt3Y4t3b1sLobS3UHxtJ+p3SQGC5dMCA
JbrTqTdLf7pot6m6MSWRns0Za7FFyegCRukZMrjG2VhL/GdTZGmUKTY5OfEOHzgmNtgW6B7sdU/v
ONZsM5J+2tP3dn9eTY3LlF7vqqypdbgabcE+quREW2yszZZog38TfVRxtti4+Fip+h/AqAWH9GQL
ZhHdgjUI2hVUC8ZoG3XoqPOblGsjAiI3rJt9n+2HzduWhU/5XViTs2Wf8ORmU+rc0Zsf37yiKG76
6UFljVeen/XumPPXfnxiUeCKDa0VL709fU5J6JmgAZ9p8Mrv1r51uE/F+vWVEY+d6h992OOV8RFH
h3yrSE1aG70tMvm5n7IWDrrUqjmwvqqg+PmWuZuK+jTkfP/Yy2Up60cFxnJhhg3bvn3U4vvNwLZS
Q9F4tnxDUGLe4t+2/ryaeifgo8MFmS892Hy4/09jVo94oWPrnBmuEbt8T6zlI81o3CNFjsQD2Xr5
gLGdk249XaHgnv1wwdhxP+9Nuc97QQNz/ubrLzSvEXafbDqz1b928oDjB69yW0JsL8keePclU4Pn
AxfJ977gLQuesy14xrZgM3AzCDML1tsWrGvWTjrl/NlR+1To6PmGPbnLO9/bVPv/f/9a/o2M02QP
13ynPLLs+jrfhMuv4rBzDbrrk4viNjylfC+VfXTJinf7f2O+dnXcquhXNg49VvJz+9kTKSkTt/Ub
4xDCZqS9e2L7Z+zcT2OXDdygdU47IOhH+jqOtJ8afEk30TTyh5L7d233O2ZJDO/zevkm/UPhmtIt
v40J/Kf53TNe1/Oerx4cJ+9o8fn966lVqtE3D/2S97dD375lazfF8kuC1kT5534SRD3zS/Pn9MuT
brz46bFxV8qz/pY3Zu/LdKS+85EzV7kV819d9/aOxOiv5nz1XMOlWRvRqWlpRz/s99Dn6frnEqYF
TLuQ8MXHgcxXz2UyxybGJ1XnBqpK9ik2P/zRJ2PShpwMLHjWeUHff/Gq+g1bP9wIWqHI1kLnuLWC
ImaH7h+jOic/+d6RLp0S9J9SBnDuk+LgH2iAOFAGsXFQTehSBo2iBoVJZJ5UQX6sp01HKpynYlxx
XSXElC5YRmtTk0a5pzyvvGxGTXVZF2KKf4VYqM3sRsy/Z39ZuSnfMbWaRKqjBqf/W62wr3HemcKX
MpOf6/t87Pl/hidkNRy5ZXzqb5kzfz495LuPH35zek5eyY3HqDdzz2VVWcNSyw+/H7pPOWxfU/2n
mYe2r1CPejvccm3jt6pQ4+n0sD9KHvvAL/OZVcONj518yRry5vA+c2v+7hWc8nCyNvnTQ1E3KlL6
4LhOodewZ1+pwoufuPXantKmln9O3rig9YHlu6+9unrLB0nPjnrAp9fiEZ/abqKBN97558AFry+6
XJW8NabvzZdjdinmlTw6u+KJtjrVol3X3rpu2j9Sv6z0vei/x2X6XTkwfG3KqHzf9ytGN27fufjY
2NQNLaOWVLMvJhy9P+xQXsXAx0acsMyPr24dKjv91Knhi6jqRejpI4sv5kta4Q/bgt9snkQphDMe
NoWMA4PGsnKa/t+hKjQER0+MOxnWRsOHLYg0qBlvxnAi6P1ZyDlp1y/n3xqxfnRGzJaM0qs2JenW
MOS7Yxf1ODqijrl/xwvzh0dce//gCNfm8b1cvetfWtSxI2f1bJT7/fEfff/heFu9ee51avA7xxef
+D3/xBsbDo2tuVqasS0DXVl7bP0nga8qN/ipVp89H7wzat7Pl5+te37FZ8nLB7ZNO5g048Mlu0I7
Ln5/xsE/uuSQ8AU60Pf6b3P/qdXHsD9GrV01aHrkzH1JKz6Xq94trDx5qDl9esVzB/YdWN73+DVa
O3fOrx9+Puji/cIXXzwv3Lz4ieol55mVl0buTdo8t8/HAy/0VZYkUhsWTAt98Obk0hW7Jx5IPlv0
cEGrf/yvKW0bWzw2T1n6UvS+Tc+8t+O8ae9hm98DJoOq98G8G+mf32e7tDLSsfio88vrW3e83zyo
dpYadMw00DF5ko4p1szOdTuNPc8RC3rmP3iquxROvM0GGiceFI4t2RZHqvGkanP9P0FN6qf/Rf+/
1TWbLyiWffDG0azHT27v33dn6ITpF6peN4fsW33shxcOv/NJxBtxuqUHzxdG3+o3NtjL8sIK1aeG
LdWROU3eaenPL7O/OGSJ6u8LVu9cJzs1LmPW5B9+aVd/2eTaEv+e6+ufLxVvmk/vy+z8JFX/ye7j
96lO3X9tn6eqvWha5AP1D+/befCB73xefuT1X733lhRe1l3sf8U8aemu5ro3My+tebCh6PFvdzYc
TVwWb7B6Xih59wX/bSPbpu782JRsm/n5sqlDvnwn8IZqlCvd+h0bNs08PWv3yrf2JP9t0DMzJvsO
37Hi7PKFqbMVQ889vac19M0vr91f8eJw16GI9Ownig1FI2zHWq6fUjrnXinIbfiQK5i1QNI1v9sW
/CryPkhDTiwcQtmRHgf2utm+fO7o38dkt33tc3bawr5sTMR391ZNRE8EhTK+Nu/mex/zDDLAyAy0
pdiSNyZuTFgUL6UNS2ur7kgbOqc7SKtVSrbWWQfng6DFQJNtWNeS4IcMsPW3JXXVbdSi6H+ZhxQn
LK/tMZPrjgMkahv7uJr8qU+ZFvbF6m98sgfs/PHcgqYrqkZXw8h1Q32vIy/H/Aslj2zumLrpia8i
o/4oOPuYMOrwffxL+5+93HK9Lbhmwh+//vKFx0dLuVRvH9PpI69kDuUiisbx2auvcidey62++uUw
fWTCUnPtxSl7dzn0YauvfN+XvzC/umalIu9475ys7XHRi77bdKIw4uDBAZ9P2rNQ+VpC4MjWzKGd
B1ZvmiDftvbT2YfGNT2zdcSJazufWJ/+5XuTw1L/0dR36IibHxy7/8kf9777RKkhf9fO9T+fPfzB
xk071hyfY1kc/V87cPzmnxzmW/st1n68GCMpzn/g+6mGZQIcUncnKD/fsNDH7tUGQbUKvoM6O5dk
H++3AZY2c4GlTSustPGseQuZKBu40iYkMze1uCQxtwC5tDEzsDQ0MzA0NTUCN28MwVwjAxDXoHEZ
TdymbqAKqSjl8pwzC0AD4y7BrgquwX5WhgYuFrqmFibmus5ObhYwhczCcjg8EZxaBBpKJ1hAvdrF
mnziZuW6Fhe7pZuPvPWZp3LfskyO85qRV0TFJe2bS9knvH9u+3uvWs3i309r64zO37TttjT/9OOG
tYnYlUlNv03eZLQWSfU/2OHzYEfrZ2MupoOLyopNfWI/bn/oVSu7Y0rF7f9yraJOboXn6tXDhS42
+1uf/3XvW/dbe4bHV+8l/hTv9V7SaPM10+HVw8797P67Sqpf8jx1f7U65+PV9EaOH2KnaoV3Fz/i
9PmV9PvtAstZVv9eC55IlEuKuMEV0nzV2tv7Uehe/QSpvkmszrdiXzdxKU/nXMBqmNo92U/OUXHR
pAl/XV1c8003upqvzVyZ+tPEeaP4IWvLhwI9n6TaH4cEyFvPNVyLXEAhCqS6og969mGaD1S/Z+xg
/OP9sO78YzuUsif/hZ/99J0mq73b+vfMebXG2tH52AWKyp6S4oLkRKqUPTCTSrCVoBwYpTCWAiqz
qomTR+zivfNunXr7L5pUNdarazhqfb6sOIlv+tr44DjNn28PhnitqP0ufIFb5KfvpzZRhrzHzbIa
rst1LI3u5s8yj3qnHNQfwtxrv3xOisU3sxMiztus7Gac5D1c2KjxOW254aOY2P6fQUEPY15PnjA3
k9On8+LFMh8T3qyHNS7LtaObQ+pdVSRVj3S5HVV9LNmQqSnyTfzYByWdRrc47S8/lx0rt1PO/7ks
pbVvURLvSl25FU8n2NX/39D3Z/qbj39Z1p/1PBdVsubXZ2F5actzi7dc2/Nly7sTaz+Fyf22+Xji
mpbLnv1z7GvTJM5uUkjmOuVgm2okWbNph+1BNQ8/JcmZeT0GBz9ORC2gBLK4Z/ofYFBdLXjbVT6i
Kn0RejE1MJ0vaOlkYGJiDiqdLIHcAeh8YRSchMqbO+Z5v9efcPIqlDhxzsMu+MCv1SK7dIx2C/kH
nWh+a2d809Nwksa2iSkP5ANadh3yvljP+uN96b7u4yuursssSKtQT3uxbfv71p1n3636K7SEO1JJ
U/+8w80wFumyrbkpuV4ht+9+vLd/fvPxhvv1PkzmU74emMcRJpfhfvbmgbIY/dptqixbwqKzZJL/
N9TYvLvKouprWV7CHnso5kabuU7pSb5XcpacNWX/5ubkVT14Y9c/fV4hX7yWv0RSgtG8S81+2kox
Ga7d9/RbBAI2/dwq1ZvzTnW28I/TAtdb+b40lRWbHZtatehMAtsb1g1txtt/TIlucWyJaJ2St0Fe
x+NM/hznB1kv6tX6siHlTROjBjBEVLDn0CHR/RJg44QOgIoygu/jQCo9sRaOknANIkwsPHJcDMHg
0XZnBkfUrhlGvw5LATXFV9DwUE3AbsG+hYnsjHw9Ba6974tD9tpzsur+3xEY3Crz1nLi9sVh3Pd6
tllLX/y9ZvnJ7RsDFaXzOTLrspkXKbm9zdmSW6O0w+1yy+de/n3sXWYHX9e9LIh1nT/p0plzd/sO
PNyvdbbmzcl1Rlfbd55OPmJ2UUJxf9k961mbpYvnKXbc2LJFKKTny5xDqV6zNNTmJHTxWx8XTq3w
2H1+bbOV/4akiHsGL19ayj7u/HTLsvGnsGJPSkMyG8u0T7OYnPWr3Tp2/We6mfrT694t5pLJm1nz
eM7MvaORWOPxUXyOoKIFk0z7Graj04x2PHU4Fmy7d2XnvRdp5r1flKbNObOhPCTQ6lqRyyblb4ZN
LPOBhdRsJkZGg8b2AeyVofQVEWPcCxpPGYjA41uD0ZCdmRU8RwFKBdDI5GQ25EEeVge6BsHjNuQz
QJYVNVBGaGQxBKaxX1++i0rZvClsN4/J0L04S6MpbvcMgxAkLTyGbgYuC6QaJHBNBi9Ua1AhYkmB
AlpxxtLEyNApdtvqRZdJ+ramx7rBXGsPH2GY0+dy/dKvV3zrl95rm7w30crKbE3FxELBszb8Pzwd
w27cKlspYh3nGGb36/qc01ztfEt3anr+/LLxZX5zQ9glpkOCrIFFb0qkQ3rlBRfzBmw5oda1himz
wLA95t9sXeE+TZNQ20plGZ4l86zfHeBg+2FYHjFf68BCrX9X/ppI+fuppHNMCSm+LWx+47vNaXHV
fzsultqnnyq/qn/Ydaba9M1feo488Mxl3WbO9OiUeszKHq8Or4DlSg1aW/tbimY5Rt1dn+maJTKB
K3Xek6cSznvyeVyWBsls1cqcKsz4VdoiO9b7YZN0DpPFsaJN/bJHOFwVX7EdZNuwsIlJ3qCJSRoR
J2yGTUw8QCEOuidJ9BoIpUPBDk2SC2INJJBTHjdi1ocRaCdchtWQH1i1WhgaGIMqUktQSx894dnO
XMiyfNXfo4v+q+V+TK4rz/TLtUAro0BJJNtG5vTB8unfHp3iT/G48lO4+4vDwgq/+0LiWyOyhLPc
+oRfekS3Tdf5/GRO+qzTIYbvFT6KNs15w8vgEa1eljLBdeW0ysM1daY9S+KFUnbP3l4iLbv/MFv7
7sV3U0VNhSwmVL+p89uuIzT9k3Vlnvnb7HNeiyJ15+kYpLf2qG158SBUSPn6dLOziSyFF62qU65M
O3Zn5blNr+9tOfpy7TyRsLlNZyXXzj51rGKO+uunnZaK6TEH//RbGtnJ7l0z9axthLtBpt+87qUb
zbamJtU2eNsd3z5v8Tx52U/NZhF9T1ef1P632Z+7c4vETb9X/wr/BdeLShy/KiV3Q5u7KnD764YW
A7nKk5s2Sx36xAAARFDsww0KZW5kc3RyZWFtDQplbmRvYmoNCjkzNiAwIG9iag0KPDwvRmlsdGVy
L0ZsYXRlRGVjb2RlL0xlbmd0aCAzNDM+Pg0Kc3RyZWFtDQp4nH1STW+DMAy98yty7A4VJAHWSgip
pavEYR9atx9AE9MhjRAFeuDfL9isWztpkSB6z8/2i+ywKHelaQYWvrhOHWBgdWO0g747OwXsCKfG
BDxhulHDjPCv2soGoU8+jP0AbWnqLsgyFr76YD+4kS02ujvCXRA+Ow2uMSe2eC8OHh/O1n5CC2Zg
UZDnTEPtCz1W9qlqgYWYtiy1jzfDuPQ5P4q30QITiDmZUZ2G3lYKXGVOEGSRPznL9v7kARh9E5eU
dazVR+VQLb06ikSUI0oJSUJ7QgVWmnPS7wqXhpyjjMekfsBcMaN7vGJO5JrIDZEpkQWROyLXRFJr
Se7iAklJ7uQKr0TOtsgIv31ZLEi2/+2e/3Efk9GE2qf8qqi4Lbqa3iMiIdDQliPi8v8W2wRrb1NS
r65aTDOaVumyAOrsnJ897hsOfRp3Y+CykrazU9b0fQFbEcp/DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI2OTI2L0xlbmd0aDEgNzE5
MjA+Pg0Kc3RyZWFtDQp4nOydeXgb1dX/z6ya0cxotIx2SxpJlmxLtuVNduw4lhLbSRwnOIuTOouJ
Eww4gSQOSdOQ0CYUQkKgIUBL2UqBUmihBWchJCwl7JQ9UGgp0DdQoPCWAG0ppUCk99xxwtIf7/Mq
f/Tp7wk69nxm5s6dq3uv7veecyVbAgoAXAgWBjpmdU2a7to2BHB4GMC/cVJH50SIM3cBfHou5gpO
mt4zy9RkacXzG/B8zKRZsye8XvpWHM9fxvPvT+2dNfnKic0/A5BKAZg7e2al6s6YedV4AOotvD4w
p2Na3+q/nLUMwHIQgDt40rJFw5+eO3QvwBYr5rn+pDWr9anXj6cBLjodzy8/ZfjUZTc8tWwGwPm7
Aeg7T120ahjcIOLjrcbyrKeefuYpf77wDy8BXMwCzNw6NLhs7bJewQOg7QdYNX3o5EWDz3/01CIs
C8uDxiFMUMsErB9F6l86tGz12isfqr4Vy54MILx82slnLK8/t7IH4M942dR2+oqTFlW/6TsH4I/b
8Xz5skVrh/kE8228/1HMoC9ftOzkd17MLgT4axbA7BhesWp1vgfWYv16yfXhM04eFobfw2sXYn/S
nwLpa44Ljbz64vyFauvfwS8AsZu/01FB9g9Vt+ifnHf4UulSAZ8DbCcNo4b3CVJuJoBciddXSpca
JX3R9pIUZg9MB8Y4p8EKKZiDB2Z8XCOFtVHbgQOBu5KrxyJjo3vmWlhL3yQALfEsw7EszV4HfD4L
+nzSw+TGabN0HTBBj/DB3Fx4TJCoW3Wgfkyusf3cAdJSoIQjVaKfGd2YOBVlfgE/4y+EB45WknsG
VpE9cz3cjtulnAtuMu55Gy7F8ytwf5i5Pv8app/PuSgX7q87mgf3d42mw5W4rcNtJXM9NQ/vexMf
I4fb3/kLKZnth2uxV0e4teDjzoJHuctgFZ/AvQqPslfAo3wDnjPwKHMinM/8BCqNVqzG9F9hnk9x
PxVWsc+N7rntmLYWzmPfxcd/CXaSMk1vwwJuPXSw7wAPX2GcK2/0N/sUDLGfwj42CUtwfzr7ICzF
fukgx5wV9tF1cBt9X/5+9m64D4/vMj0K+0g6+xIsNe7DfMxS4/7lTBm04bUdmHcctnMO7lvJMdsA
/V9Vh//fDJ+Tff/pOhRiOKau+OI5Hc8fouNw7X+oOkUrWtGKVrT/uDF7KKqkpMZiIbEYRVmAUilK
QgMCCVMsFkmus1i9UadFXW2GqlKLoiiWuspAXXWJzSiDAkxQlBJF2k1Zdtskq6IkbDbJbFXNtoIr
8q9x3/9uEsldePaiFe04NaJYNJDhIyEPAgj5HK6tzEizQRQxUgYZqYCSPwwWsCBVUJFWgzawIe1g
x+jeAQ6kBk6k06ALSNTvBnf+E/CAB+kFH9IHfqTfYAmU5D+GAASQQQgiQ6AjdYNhCOf/CRGIIKMQ
RZZCDBmDODKO/AjKoAxZDuXICqhAJiCJTCL/gSuZSmQVVCGroRqZghpkDdTmP4Rag3VQh6yHemQD
NCDT0Jj/OzQabIIm5BgYg2yGZmQLjM1/AGOhFdkK45DjDLZBGzIDmfzfcGU4Hjne4ASYgGyHdmQH
dOT/Cp0wETkRJiEnGZwMk5Fd0JX/C0yBKchumIqcCtOQ0wyeACfk34ce6EFOhxnIGTATORP5HsyC
Wche6EXOhtnIOfAN5DegL/8u9BmcC3OR82Aecj4sQC6A/vw7uF4iPBFORC6EhcgBGEAugsX5P8Ni
gyfBSchBGESeDCcjT4FT8/8Np8IQcsjgEliCXApLkafBafm34XRYhlxmcDksR66AFchhGM6/BSvh
DOQZBlfBKuRqWI38Jnwz/ydYA2uQ34K1yLUGz4QzketgXf5NWA/rkWfBt5HfNvgd+A5yA2zIvwEb
YSPybPgu8rtwDvIcg+fCufnXYRNsQp4H5yE3wxbkFoPnw/n5P8JW2Iq8AC5AXgjfQ34PtiG3IV+D
i+Ai5HbYjrwYLkZeApciL0W+Ct+H7yN/AD9AXgaXIX8IlyMvhyvyB3EdRXglXIW8yuDVcDXyR3BN
/r/gGoM/hmuR1xq8Dq5DXg8/yf8BfgI3IG8w+FO4EXmjwZvgpvwr8DP4OfLnBm+GW5C3GPwF/CL/
MvwSbkXeCrchb4MR5IjBHbAjjyt42IncBbuRu+F25O2wB7kH+Xu4A+5A7oV9yH1wJ/JOuAt5F/JF
uBvuRt4D9yB/Bfci74X9yP1wX/53cJ/B++F+5APwIPJBeAj5EPK38DA8jHwEHkE+Co8ifw2PIR+D
x/MvwOPwBPIJg0/Ck8in4Gnk0/BM/nl4xuABOIB8Fp5FPgfPIX8Dz+dxM/gC/Bb5W4O/g98hX4Tf
55+D38NLyJfgZeTLBl+BV5B/gD/kn4X/goPIgwZfhdeQrxn8I/wxfwBehzeQb8CbyDfhT8g/GXwL
3so/A2/D28j/hj8j/2zwHXgHeQgO5Z+Gd+Fd5HvwPvJ9+AvyL/BX5F+RT8Hf4G/ID+AD5N/hQ+SH
8A/kP5BPwkfwEfKf8E/kx/AJ8hP4NP8EfAqHkYchh8wZzEMeCTiPArNXNIvAMBxnAjABy5qA4RjW
hAYEJpYc82bBJAgmXhA4DnhREE0ipgq4NxmOggeeGIO/DM+I5JjFH97E81zB3qbwnORBafr/zFa0
oh2/ZpbMKFeWE4geiHxZjuU+1y3HCYLAm4lK+aO6RdWKAqaYpM90ixlR4yYTw5gYydA7z5p4VPxX
vkb7lXZsumWYY21o0Yp2HBl57YPoVgRcUX2VbkVRRH8riKIJPe1n/lYgHlgSRnVL8vKjumWP6JZD
3RKvXLhuC89Z1G3RvvYmKzLqluPN5P1l9K6GbtHHCkAgGLo1yUS3gkkUUbcms2gWUMioXeWIbkle
dMasIBi6Ne4zcYY/NhVckcJzkjfJi7ot2tfaFEVBuXKcoVueR+2ir/xct5iCulVEolvcOAyJJUO3
mCwqomiUcVTjX9ItFiKZhKJui1a0f4NZVAvqluclXOp+plsiSiAQ8YIkCRaz2SyJgmRG3SIl3NDr
mlXzqG5FMEJndM0MJzCKcZ+A8TTeIhRckcJzkgdl2WNtaNGKdhyZqqpEtyaZvJNuMpmJbk0oUzMQ
mE0mWZYFFWUriaIs4fpXUCRZlFG30me6NaPGiTMmuhUZVTSP6pb4Y7HgihSuWwwNirot2tfbrDYr
eRfHpOBS19Atb+K/pFsMpEUrOl3ZLMoyrldFRVbMCjpcWbJJklEGySuYzbwZ/bHIqeQ+XsR18DHp
tvCcRd0W7WtvNpsNdWsSLES3uCQF9JTC539hJwgWi0W0odNFqSoKxr2iRUHdyrJZlm2y2ShDAoyi
JTOG1Bxv5mwYSEsm0SSZMbz+d+iWTBZc4W8bFa1ox5/Z7XZDtyqAYujWJJi+pFsMpM12lK0FdWhB
3ZpVPLQosqTIdnnU35K8oiQZupU4u3Ef6lZSMbngipgLzlnUbdG+9uZwOMg7taIVwILLVIyVRRMG
xLIMBLIoWq1WswODZVWWVIsggmS1qJKqKLJFcSiyUYYMGEXLEi6FeZPE28l9gtkkSxheF67GwnOS
By3qtmhfa9M0DXUrEN2qqFvF0K1C3h0iUAzdShoGy6oiW1WiW5tqla0Wi6xaNMuobhUwwmaTrPAm
mUc1o97NAuaXjzjkQqzwnLgUL+q2aF9vczqdRLfkX71UMJsxVjYL5s91azbjAlhyomytqEOrYAbZ
brUpNtWiqBanRTHKIHklRTEphm41Q+8S6tb279PtMfwBZdGKdvyZy+XCZa1otpNPwzCbLYZu0b1a
gMBiNuMCWHbhItdmUWw2M+rWYehWtVhVl2oxyrCAseQVLBZeUHhUs8UiSqJFsStHAulCrPCc5EGL
ui3a19rcbjfRreQAsKFuVUO3KnlXl0A1m3EBrLgxWLarip3oVnHY7Ba71WqxWd3WUd2qqHHZYhEs
Ki9YeFQz6l0WVYvDYilcjUrBOVUo6rZoX3PzeDyGbjWiW0nCNa4kSp/rVpJwAax4rFabA3VoN0ug
aHaHxWGzqnarx6oaZaBuVQybBdXQrdvQuyKS9a+lcDUWdVu0ohVsfr8f3awkuwA0kGX0ubJZtpF3
dQlwhYqBtOq3OxxOm9WpSTKobs1pdTrsNs3ud4x+AIoNrDZ0v7gUNolWk89mxfssks3qsh5xyIWY
WnBO8qDH8A8LRSva8WeBQIDoVvEAOEFR7CApkmIn7+oS4AoVHbI1gE7XZbe5XIoCVo/LbXNrmt2p
BTS7UYYdbHYVg2i7XTTbxBJyn6xKdpvHZitcjdaCc5IHPYY/fC5a0Y4/03Udw2NF9eFSF0Nj9Lmq
rGrk3SECTVV9Pp9NR6fr1exej6KC3e/xOrwul+Z26S7NKEMDh2bTHBhS4zpZDGkOTbPYFM3hczgK
/0SywnOSBz2GP6AsWtGOPwuHwxgeK6ofl7qoW6ehWyd5d4jAqaoYSNvDbrfb63T4vES3JV6f5nO7
NY877B7VrRM0p82pyU4nrpNF3ak5nahbp+bXtMLVaC84pxOKui3a19xisRiGx6otiEtdXNJ6QLEp
Ng95tYoAI91gMKjFvF5fwO0MlFht4AyVBFwBn9ft98a8bqMMD7jcDrdLcbvNistc6na53VaH6nYF
XS5HwRXRCs6JIT2G9sfa0KIV7TiyRCKBbtbmiJDPiXM4/KA6VIefvFpF4Hc4IpGIO4GrYN3vCet2
B7ijobA3HAj4QoFEwGeU4Qevz+Xzqj6/bPHKFX6vz2d32fzeiNfrKrgi7oJzYmgAUuF/plG0oh1/
Vl1dDVar3RnHkBlD4wDYMOQNkFerCAJOZzwe91aHdD0a8JVG7U7wlUVKS0r1UEkkVKWXGGUEoCTg
CfitgYBs9ctVgZJAQPPYA/643+8puCLegnMGcJMLf2O4aEU7/qyurg7sds1dAVAKbrcOdrfdrZNX
qwh0t7uiosJfF4lEy/RAWdzphpJErCxYFo2EYpHaSMgoQ4dgyBcK2kM6xttqrR4MhZw+TQ9WBIO+
giviLzinDuTjdY6xnUUr2vFkjY2NGB47vZUAZeD1RkDzal6MjSNAgJFuZWVloDEWiycioUSF2wvB
6vJkOBmPhctj6VjYKCMCeqQkomNIrTp0NR0JY2hd4ozolfoRh1yIBQrOiSE9hvbH2tCiFe04spaW
FtA0tz+FS13w+WLg9Dl9MfJqFUHM50ulUnpLeXlFVSxcVenxgV6brI5Wl5eXJsqby0uNMmIQLQ2W
RrXSmKpF1DGxaGmpN+iORVKRSLDgiugF54zhZrUeWzOLVrTjytrb28Hj8YWaAGohGEyCJ+gJJtGA
IBkMNjU1xdqrq1MNibKGukAQYmPq0uXpVHVFbfWEauPrQiEJ5YlootyTSNjd5fbxiYpEIhD1Jcqb
ysujBVckVnDOJJB/9z/WhhataMeRdXd3o5sNRsYBNGFoXAP+iD9SgwYENZHIuHHjKrrr6xtaUsmW
MaEIJDJjxlaNbaivbqqfUl9tlFEDVamyVBW6Zqev0tmVqkYXXRZMVY6rrCwruCIVBeesAfJvw8fY
zqIV7XiyWbNmQSAQjncAtEI8noZgPBhPowFBOh7v6OiomtXc3JJtqMm2ReJQPbFtfN34lub6cc0z
m+uNMtJQ15BsqA00pD2BWs+MdF1DQzQZTtd21NZWFlyRqoJzpoH8++GxNrRoRTuObMGCBaDrpYlu
DJkhkWiBcCKcaCGrXoKWRAIdct2CTCY7qSU9qbMsAfUndE5umpzNNLdn5meajTJaoKm5prlJb27x
6I2euS1jmpvLakpbGrsbG2sKrkhdwTlbcPMW/rZR0Yp2/Nng4CBEo2XVMwG6oKoqC6VVpVVZNCDI
VlXNnDmzabCjc+K0TPMJ3YkqGNPb3dPaM7GjravjpM42o4wstLY1tLVG2zL+yFj/osy4trZkQ1lm
7MyxY9MFV6Sp4JxZIP/GdIztLFrRjjOjj3zLuAYMOaJ8uPGff/U4Rb6z8l+/thIvMizHk49PlWQF
VKvN7tCcLvB4ff6SQDCkhyPR0li8rLwikaysglRNbV19Q7qxaUxzy9hWo4QJgJPBpMldU7qnTjuh
Z/qMmbN6Z8/5Rt/cefMX9Bde982FZBr9TpIduN2+p/CigYUtyCBYsQALRCEOGG3AFJgLC2EdXAu/
ZL6jO3SvHsnngbweHodyqMQofipeX/TZdQ+5nv/jv/yclD/p02sPXnPwRwdP/r+/4z3rnN3b1FiX
qq6qjMdCmsNuU2SOpSv1ESbWGe2MLhraqncO6VujHQMdVZXdM/s6O/zh8NyqSh2TO/QRakDvHJm4
ZsiztZNkGLEnR+hYJ9mWjmQvGMCDaEc4HMYrjs+v7M3vv/ALl/QlI9lFI3CBvqNy/9YL91ph8UBS
HowOLlrQN8IswsfaAViZod4+UieyDQzpIyzebcCPKUeqSK4NDSCjHXjXV6Zjstjetzm83z9ix33n
iC05MglzTFr3up/Z2ulZopPTrVs36yPXzuj74tUw4dy5cz1f6oaJ0YkDW7dOjOoTtw5sXbQ3v3Fx
VLdGt+7o7t463Dmgj8D0vhEK0++8wD8y8cK5I9aBIaoFm0zaMXFmX8YftmEp4TBp7wV7s7AYT0Y2
zugbPddhsX8nZFPJuSP0ALmy/+gV52xyZePRK5/dPhA1+rq9j/HTWHD3rGj3jHl9eufWgSMVPpIy
ZvRsBw0TdkSpLTN2ZKkts+b17bPiaNvS27eTpuj2gQlzd5Titb59Og4UI5UmqSSRnOjkBLop7I6d
tGDk9+/LAmw0rrJGgnF+0l4KjDThaBoFJ+2lR9OsR9NoTGNH07JGGjFsDN3e2/fFWuNG6g6wD3rz
+7PBnRV1jdad+s7szuk7h3du3HntzpGdz+w8uNO8f+f7O2kca9nh292exlAHpc4JzaF7Zi+cTa/o
pX7ce1svPWOWm505y8XOmulkp3TNZCd2NbGTuurYybh1pZvZ1kwdOy4zjm3LhNn2TICdkJnJjsct
i1smXcfW1Q+y9ekGNt3Qyzakg+wzDQcb3m9g9ubf3bU7Nrlxb/7grt3WKO7fzSq7RbVxt28yu2bX
ebuwWu/v2mXk+Dib3yWWNu7SJrPnb3Gww6cPr6XVq//rGjr7I5e3MXu1y9+Y/aEbjy5z+xvP2+QI
qeeqm9Rt6kXq9tC5oW2hi1LbNm7auOWii7dv2r55+xY1+13R2qieETqDzq4U5UZ1GaU/SumPUJmH
33uY1h/KPkTDYgoWWxfT2UXXLqLV+VSVZmMrtRib1JrZhOZgKzQnG9KCbFhvZ3Wtlf21r5P1+Sex
fl8r69PqWCfmc2B17ZqPteE2rFFZbXx7o2pJhICnlAe6Q/L93SHz/u6QiBt3d3eIvac7xOzrDtF3
doeoPd0huKM79MD9idD+exOhe7Jz7g6H7twXDt2xJxy6/4EHlXv336fcfc+v5H133iXvuWOvbL17
4910dt/GfbS6J7OnZ8+GPay6J4WHK/Dw3j1P78nvEcxiEysrNM5dDE1TQE/nqL1Unhqxd0N374QR
B4X7WRN2iHXJ7pHBmRM2fe97gZHLcOSObAzM3StgHtTpCLVt7ojQPevI4ejbJ6tWr1qV/AobYTpH
+M6hRSN8tGMVObGQEwvOFpbOEZUcq9GOJDWidQ6NaHj0/xSy6qglVx25OPpABuCbX/WYpC6rkckk
H+Q17n3uAHsW28+8Qv7jNf+n/Ku5tbnB3Fzm++R7rOEyuBkl8jA89dlkfzfcb+zXwE7YD49/yRGc
Dd+HG+EJ+D2891na5XAN3AIjX8q33Ui9AX4Ot8IuuBMewLQtcDGm/hR+8YV8K9B/XgRXoa96jjr6
dxgP0Bo1WoO3QaYPUKuobeBDv9YBC2AVfAfOw3o9Sk3FtHGYNh1Tz4C1cAmm7oNHv8J5jYM50A9L
YTk64H1wn5GWwNReGMRUkjZqK9Gnng/XwU1wF9ZrHdbsYrjyK8o7mw7TYVgNb+Cdj1E/oB/GFt0E
m3iNfLIsd4D0Kttv9C3kXwXIDeb/jhHAYvoD+nr6YriNXor+mSYu10S+SpTBnXYHT7NAttSTrzxp
oLYmbAvbYggKc328kYNPyB42ko+1pKkogsHHIncvynoYHM2m2ZygihT0s7Is07PZJNPP7c2/sttq
pWfjwTu7VdU4+Hi3ohgHv9stSaOXsmZRpGerXIijuVS/MYZeP5x8vR8yh+pTmdoaiokyjmi6nmZ8
N5e88MQT3IFPfs02fZx6DmfjnzEHGJbXjJrEs06a5xkTpYpZkWYqgUzhbKUpdai+P3UIi2utT7WO
Fkd+GDZ5bvJnuPHa4XvodrKROA/HCvdrbJsf+3BHdmU2PEdczQ2L6x3rXevd632o4WDApTqpU52U
MyirVocmaSYhVOIGDzXkoTxBjqZ8vJdf7NUWD0uUxNgkm5dhFfBTfr/i9lEB1nq7I0hzIivfrppU
h4eVQKM0RpV6JFoSINOf6be7m1OHRjcqVZ8yzlOp/tdTr9fWbN6Pdrh/Jdnt32z94hnVT4WZsDPM
RB3Glg4bWz1jbBxe436d27WAasj9fOjsodxfCV6gpi3IPUF9Y8nZSygLQSKXzr17ImVnbsht2Zyb
T/2UbJuptZupG3PzyLYpdy7296r8q7yDex8k8EAnvJpdIapetVWucdYE0lVt43p8kwI9HWeWSEtj
A5n13BphvbomsC423DacETmBT/BNmuAKaAmtyZmpkBOBeFONUGPOCllzlzxe6ylpD0zUp4bHV41v
nSHMVebHlnCnCKepA4FgRnYF9KiXIT5zrN3dxNzsVSrFNi6apl2ZqDkoVCptTAq0MbyWysidDj2Q
GsP64hCkgsFOTfFRPp/DGV810fohjq5+stmwd232Zuzt1CE8hEzmUAb3h5IpTMTf2pr+fuzZhng0
wjs1l7ux0UHxvIknJ/V1jZRT401UtIzno5HSdENjU2NjUzw+elBf5yJXMTeFqY3xNONZ2bdgdc85
i0++PxcJtYVKSm/5Uf8d1Gl1rdS6D99Y9f6GZ3KHGqLRofTyRel03XWLfvmCJ6CvOZFaZbFQNMXe
tHDZ+rndq3uimw8D9axamyhb3nnJrvn0rQMD7y/LbT+4beXfHlpwXm1qVmjyJSvaz6yrab3tvMoV
lbXz9Nxl5QMNY7bWoCRuzw0yKmrGCXOy7SIlmryU11TOlHM91GRmMtdjWkgtNK2gVpg2UGvptfwG
k91EUfI6lhLI3aDK6MJmq7Ih2hC7xWX94FAyif3YihIjcu2nonHaZrU31TtJN9FOze52udyM+saO
Bx/c8caMSzOt3V1trVdOyw0+Th2kqvDn4OPmrns3rM/97oZbcq9vXP9IJ1lhXZobpA8Z9VyabeYZ
3uFknI44FWfijrhzEpVlso5JzunMdMcAM+A4E9bQw8ywY43mtFOs/E2g7BmWYllpb/6D3aTC5CCr
kkpLIZDJbASXuK0fJv+17lbaFE2TJ8uebqDL4vGydL3LTh/Cik+7amxb15RxmUtnYEPo1txzOf1x
c+cj6zdSJbfcQJWv33Bvl/nxnI41v4lew67Emttge1bscVC2rGhtEsiI7cOD+fR8rlfqtZxGn8YN
SoOW9fR6bpW0yiJTvGqWLIKNo3mZ72GnszRrVmVsDaU6Qg4abErWSlkFk9yDz5rVQuMKVOKVcnFY
puRUfz1OFnU4VeBAJsAG1fdjy+rJ3FGfqsdRTCWT/ZQp5og6uLIqqolj6pmYm2NXZnOX8WdzuR+O
p76dO2c8tZQ/20Sdls2dy3xr+fO5y6mhF5Y//fTy56lTc1f8ZvmTo8/MNjqDHpOBdDbuoxJUkk5D
M90Jk7FX59KD6J4eYmSaZuaw6I1oH4bkWJEUWD+oS5FOFqmog87k3rzkVipweCV9ESnzCrqWEek3
sUw9q1ETVAzuVa4HeriFsJB8mjJN5kFAxWIBOKkx4uHt9DBdezu59zDiHaM++h56DiVAFbU3/1bW
TJ7lFJVB5aBfOYT+BP1a1FZPvfPee5ibyr+We4ZZYHiPxmyMoYCjXFSMGgNd0EHNoU6lvkWdR5kp
O82ksDZk7JNKQCbVj3XYfKh/835sCMUsOFz/S/oxXvvoblMH8SDn519lL+Lew5kxCpuzkUaqWWqQ
x9rHehqCnVSX1CF327s9HUHZ2SXS4S7GrOLI3EOcphoGDLkNTwlktPqJhwQPuQTXxNRYKEb7De/q
D/OYMesgOXkrGdO8TPLyl5fiiE7imO4/ssc2k1aTYR3WiSjDuh2nonRDHIc2zmejsxjKEycy9qJP
ch/lPvjHx5RIyf/I/TPq9ZZGz1x44vrSiNdVGj5z8MSz6LdzK3LnU2dRW6nvUetzGz69fcZLV15+
8IRpJ5zQM+XdbVc/O+uEmSfgk0G58Hlv5V4AFbZk09xEnpcZCzOZElRbyEZzdEilVFW2GI2xKLLM
z7bodIZZwQwzDCOTmAHn94NZiTSQcZEGMqRDAqSRTJDcxfAkjmCsisIjSQlM6mgEilJIJokWUvWo
gsN1mfoUeeZx1NjC6Tpjgq63hdnWT39PNeYey2yPVafZq6iay5k3tzg177TxH9+Pz/V12IKL0b/p
6NtmTA8NhGiO4W0uxmkrtY3lxihpSyaQCTaHurnJSqelJ9AT7AotZPrZfm6+OMe20Huiv79kYWBh
cCkzyJ9sW+xcERymV9s2+DaUbAjGsDVv7SaVpsk4zZAjUK1qlZAqqVGzKq9mjfGQlbF1qipNcdB0
aAolhGgh7DLmLpcx/bpY0iEu0jVecoPLRUpyufRrImokFKGxI68IWz/EniAw+uaQvdnoEnR82FG1
NWRK6MeuITMeGRZkTJD5r54soQzPhb9h9uJPrUuem79/2xXnz//NyeZJh1a8QbHJRNmS7tNeP4kJ
H5i3e+6dL21YfU52wrPRllfumX3phLa1XUse6iVzIarhLOzHcbA3u02SuJRPcqYqpHiqorVVSmu1
kYbUFKlTa4+0p+ZQc7m50uzUUumU1NLWtdKa1Or0+lZfQ0tHCz22BfuXqrJV0VVVFVNCYi2tKiGF
VhTbFNEcDTcZQ6mJJYOiiSe90BSsdoWZ6mALLrkYnzFkZGOYXJtRM6EMLV/ZZn2z3/pmMmlzN1sP
YXhFeseIOfsz9maySx3GaZSIx3XEi0cjhjsgYmn6TEQYmdZ9QVCjnUckRe5xulyspaZtSnv342ee
9f40dfabp2W2VVZX1VdVbZwyb+Llt1dXJBe3LXxhIenTZTe2T55y27dqzqKfTH731FNuzkxsHxs9
MGZKoqJy6YzpS4Ih940b1jXO8Pm0jrYD0bHllTVb5p+1z2MR6rGf78J+3oRxawJ+mB1nFnxCUhgn
pG3jXN1Ch22e0FuxVFgnyIGAr4tMJDjdxcJTYnyQVs0hM202W6bwZj2i9wSoAAnJq8nACrhItwUs
pFMDhsYCWhj0gAjGBfhxpVoZqqTFq5KjPWlrJh1pKPBQ6vOeTPUfJtN+P/W/9yH2mw3jVtvRrmM3
TZ0w+ZFz1r12gmXmy0snbWqorEqnGn6woO8nY5mNh8cn54XP3DN1eh/14tCvxk/sri99rqGrvC65
tmfaUj0e8sh0/rbcapataGi69ch8fBN3CCLQBD/IjuEVl9Icq6+tb+qKTahtb1pIzVGm69PDJ4e/
WWvxMRVdAYfDPSXAqHQaJ2dfZcoeDYNdxBn53c+nZsmYmo1BB6S/VNJHcHWz2hxqplNhkUzpJLN4
+RgSYxjjDEca6R/0zWRWtjdjr2DA2Wz0DJBuidPpBntTYynpA2eUdAuYjvaI6Stn7Jtyz7+4fHfn
nP7Z/X2Ua9/Y6RXmkpVjf5sHZ+9PTlt48dS+uY83/Q/r3gIfRXX2PefMffa+2fsm2Ww2982yIdkl
BBJ2CIEkBEy4BBJgSQIJlwASINx5jVYFvFtsxUu9a6v2eytFVND8qhVL0dZW661qixWRKgpatZRC
dvKdc2ZmCWBbv/f9MLueTWZn5jzn/zzP//k/ZxKj+mpad02HcGLVqBWJ7/8YfPSR8mHdpFnA/stD
oHzjmgHJ9LzFr3z9cUU8FK959qbklkiOo6jEVRy495l4afHPEbZQHcr8EGGLo5rlchFIMA80gCbY
BjfTPEqbIAelelwSTmVpKFiEgLAV0jQFIWPBSZMhFUwVmjgmWSlbFeYAO6wnd+B6BSVQFJeZH6YW
vg1fHdpDn2O+Omdmc59AOXnL8BHmR+zXlJcqoiqBcIAqQFTOhIyav18b5OmDkD7IxYuzAY8i4Ziz
IjdWGKuoc07MrSucXNHinO+d558XmJ3bEW4v7Rg9u2J2ZaewyLzIvsjbGeos3GDeYN9aut2excHH
Cn4chQUuKcrQWfVWGG9AQMihMkBGBhWVTMVBylWQoznBPeqa5wRNBBd40U2m8iC3eyypMPDaH1M9
A73ZKqJrTpKcjFhZctLsNjm7vfS6UlhcWk7Ho8XRMaHJoTmh7tCdBZwvJ0QXZOHahBQoyXaEExLB
CVhIoRHHZUaeFqlRpKHTJYqLVCkEMoV6ncL8SHnj2FfKh7devWkdcLz1AZCu2HLjD04+cuUVD8yY
mX9D7eJpgRkbon3JeauevWXXE+C+Xw5TZw9ue3k8J9+x9tG/vP1Iz8FKrnoPbF4xsGlJw/Ji+7iM
2ptT6xasHusqyB39aO+OPbcjX1sz/BHhPtjXrpGrBMbLFDPV+dXh+Khp+dPCk0a1MR3upGemvw9s
zbfYssobHcWNDi5Li0Bxm4icTfQRHwsRb7Oq9Ee1cmnQR+iOj8G/9d2OnUvzLuJbVSS5RUnU0V0L
8hxzPujYK9UQhE1HEdeyp10r7VcoMDG3tM+br5w6EFuQJ2X1TvzzOUfy4a4FP2xqawelf1y5f3Lr
glfksdGViVt/MkaOrKy97P4pgKZrDyov9q3dZjAihwLip2PL8mI1g1cfA9mTJs1Szj1892AsUrjv
oY5NkYCzpMhZTEEwD7lNI5Mk+kW+7AJzIMvNYQWeinCAwjNFXAqT1+pUtUblACKwNvSCjV+gf7QM
ss49hMUrSB1HrHyXdq5pcqXESpyP9XElbJiLM1XcZKaBa2XauW6mn/kVbyGX4vg5AsclmGZUajBU
RL0YMqBO1skFk/iSGZiyo0s2YtaOrzr0gs7cFWo6eyXzGxQdOvatY0EpWryjcoHkqaSz8VuAiqLQ
gCOBLIAyQRYgw6KoIIMWwssrcEBMYmZfkUS5Y3RZ06w22cAys2lIc5hA7LCm0A/7QjtI5oM4cALA
XnnuCuZ7Q2vpm6dDsA2Cfcp6ZT22wN9BL7ub/hmxQFzOYWdzYDaHKwlZBGVYFEJXjlJYxUeXB+Ti
yfTVT0a10gKRxCC7+9xC5kH8os33pwbvx5zWiOZ5M5ln175tNCgFeJ5FaIosnicbAFEAWQs6rz5P
Gs8zCsqADOh/OVOamc2yHJwNLpgpQDNFP+zN566gbx5ay3wPXpYa3gduADfsSw2j+0c3RJ9EfpaJ
+OlyuR6zvTwHHfc0w2a6ma3zLGBne5Yzy63dnn5Pf6ZR6EMVI+fLdrnsMR8UAq3ZQk44EOACA+j3
FqfoxlUr5VYD9UkiixAqhJ0JSyNJkr+1DM47Q7ZL6aILICJEn5xSNXbXzCcn7i4bJ9+5eeUvx0pT
3ul855/K+t/+llm36M7xVd3RD8Ho/LZIbPWcNavrQr/1h18/exQreXuGs/nL0IxqqWbqbflBDloY
AyuJFr8505KwyC4YYDLZgD+Q6ch1FAYSgYn5sJQpZaP+aGZebk5hNBGdWC/XNcxpyJJYtrC98XKx
x7TctyzYU7gksWRiv2urv6+wv6p/vMXO2gR7/UyzQ3b6Kx0MM32WEImUzDALNaOzZ4yugZYIiLC2
SfaIY6o9YQAGy4ycGdBT7DBUWpCxB3A3Na+4ckWLKiAh45xMIoNFK1LlyG9Q0U0yPPpTFL1eDaN3
XJFr5oN8kOhEKPjYcfCJV9gqsB1hYUFeKJfRxRIGxyAnEZRGkAIGxSpg0yMVOoS/bEaT0uCfurPt
0ZdP/7Sxb+J9X5eE57e1KUOP3K/8o6Nz1bKOxUC6Z84zs7sebX9WeXHtuiu39/eDCU+9BGK9vWtS
tyS6q67a1b910na4+wZlaEV/tawc+wiYg8GyoaebPmx/GBg7O5f2L1qkfHHXI8oXXT1LXZ6bnZaB
tetA7cEDILF+/fZtfX3KrxQZclnefT9+6CcTsBf6KIpdiNgCT0nUS08i12P3D58h1Q6nD3iSpvFo
KjeZh6IoCXAH8hwH+pIo0TsYwDiQV2zj1vGQjkkyrgglGXOsMkmW+iRaEiWOBltYwAoWI+B4kWaN
VB5VheAzj+ql+tF5qMuN6E8SG2bHsNPZVraH3crybLcBcVVUDhFNFS1XsjqBBROURXCkQ+6XJKoq
/p+A+AnuciSDITpII56SgULPwjd2pbbtehlmA2Gbck45C+5TutjXhzbB91P5CBqH0dzDaO5OdDMV
wCTbWaPTWGhshXOcA17ObiuNZWMZyIFTW3Y2nxUT6EiMF1xOe6klzSstOaT62z/8lZyJ52wpwFUu
/i2uBvl8J0VKZBRnj+uMFFeTZPAV0dfR4Ng+/CX8J5lUhdSauCUux2F2qYM346+jNRgiGjwavKcS
F17AKYfHTBefDg1OkNOhwd/I6fDgabKAK2NEYSD/UuVJ/QNKumqdicKIynPQ55NYQ9WjRwjF15Hl
EdCqKPRbHFNU0kIOwh/Z8Oz62S/fnfoSHHjowakzp66ct/tnypN5RdHtiz8HVPLyaLRwYEx92XWL
lJcB970fx8fGwCurH6+sHcu+7ikI71jY+8OIEPgNZMZMdftNysyM7OyO1F3zevO9ltTb/rzCbpy/
1g1/zE5hP0eV02p5DgtMIudwAb/ocOY7xzgnOeYLbVKbeb51flEn3eXogxssfY4Ml8sXs8OSkoIY
J7moNagQArgWipYmSleXsjlOowNb1piJ7WlcFlZpCrJStdrUQC9skXxOrYjyvoX6X0D0KyvYKZXt
DTW3zHlQ+ceizpXLFnUA08Obvthl2frV9Wueqp88vXXSlOeW3XJ2lXmlp8Sd4Z/f1QHyX9wPcru7
loxr/GzpwsbpTR/ffs/R+qn1ixYhH8U43YtwaqayqEE5VGVvtC+Hy0yMCwHSjQC5gQIWJyURmHGk
1kHJLl3+7CPMBKNDQ903spegrT9gCUQDcqAzwLj//8As+zzMTp5HWVInQyq/U0HFnOdyiLCo8Nn7
89uWnHtV2Qn63wOg/Y7Hf79lc9uh65999pa32levhn/9jfL0/ATCSqKyQ3np7Se+nFxeeO7qkqr6
TzAukI2Ye5CNDNStz4hxirNykMPOm0dkNw6wcUhLcSAwlAAEap3JYgKc6ABk1kCfNUjPGpBZA33W
QJ81GnxKZo0HZNZgpfEi56pOVqe9aQ3Rski5TF7MPUNh+q2hv9EW/GJf36Ms25N6R7v/AXT/InX3
XnSv+Nad+EYg5EFcoHmBopsNuFDbP/ym7CPr122wGBCJAfgu2P/RAv5FX8DPtQWURkwljObyTZik
SS0yYMZFpoH8nxlIWeCO1OZD9DNsUFmwJ1WBbp7450fsg8g/86hX5PE84jGcOYvLMAfNcXMjmGie
Ye7hegyLzf3m/kxLblwOgVDISFut7pgRZsVoaYMIcq25ojW4f1iRM/CNB1dSDEG2VUP2aR3Zxy5B
9lk9jJ6TQySMri+wFMgF0OcU7fjbInFx0YiPEpflq7JrGqjhk2GU/qNRFa8VmEupCjZyfUbzeyuF
oYudnlQhlA3/YkwlYaEPblE+2PEz5ciSpX3gAbByAIh32gMbqiY/sfqs8mdELLnO5xuUNXDW5WNn
dXZ2gdBB0APuqWn8zHOZL1CsPK+cUj5Qni/IBqt+puKBHU/wfHQvHSftCBeZt2AVoCCwEqrlWUGE
DlTJvqCnkbP7tFTzzT7NWMdVDFCCbio5jxxrJxazEHNlEFNtQi4hm1pMtEA7EAf4g94MHtJbvxqc
WHIqVkcRq+OKDPD58IDAib3EM8LnP1GJ6kQ1MvCasKrzY1BVoPcKdvyhlPfQIfjXQ/DdVCH7emo/
bED2uA6RlbeIPXrkkMiUc7RElwPBtEoSDPMkB83CeZoWTcR1ev/wEYITWscJGijkRvFemqeJHr0q
fX/flFtT6HWcqK2pcgz0IKJ7oXjQiau3t1L7Dh6E0w4evIN54I47znWg+ykd/gyeINxhjezoBdsA
tFc4aZ43xGgxI8PuICFYW42zOmJP6Yg9pSP2PRyL8XqQlYBkJTa6LW7A9biwTpeGJm5lpNQaD+fm
i4Q5jD944ouXy+4fYyjelFiwyue3KL+CAFz90ps24wFzdklhUf80uudeLdJsQHfOUuufhjSDYiLh
HSoKKN7CIzr3v4qLJ7S4yI3MBraKKOlvkHCIBf0NQzMPwU/Y189+oKH9NLonI2iU58+RwFg4lh0j
rYad9Gq2UxqAffQA2ycZWsU50jwD3U330+sRiZQgLXKQggyhnIyMb40hxBOFDKaOmc2gf7xBpAGK
gZIBYQRvjjKRsOqgsnVfkaer+qCqYJAVksjy+MipPGRpjKqTmC3mgLnFjAgs8QKiKbIMQXsGb/1/
j8An9Ah8SovAphFGw9rsyI823O9W3QZz3Umz2/bFmF4GJtvRcG83A5LtiCfjgLWWSq5FTgVCAMdq
AILs6UPKog1KzwFgBjeBK0EGSw/tppefTSE6fJCu0TIoOxZnIBCWZSMf4GP8ZH4G38Wv4fkNHLAA
yAWAk4txddwsbgXo5AZAH2cwAoaD80ArhxOVgGg+I3AA8rh20Cb9jT7ps+oUM0h8ujhQHZUnjwhU
angqIPYn0RqvCLY/SnmyAUJyFCTWh6SBADMYYn1Gtz6Ttj5DDmZ06zO69RmVf3PkT+TWmJH57yLr
p4girNsfG3ntmmQSlxuqiVHgGvv31IQDoAJec4CNncUbX2TmBcTe1g1/yL7Hfkm5qRD1CzmXoRhk
NYPdTbk5r9FrnwvmsrP4DkObqc3WkTHLbXXibqEHT0YkU9ogbnZCf8wJgzFR8qD5kXv1OGl9qjQu
LbQQd1QPcV/KMRLj1uVb8gFuIiTy6WwC1GynhSRDC2nVWThSvpC/WJapHUnckkzqI5IMk1gBQfzN
ZXeqFO5CFpxhpdRcWFFOsdnzuxa3Lzj3wD3K8Lx5XZ0L2gB71/3D9crQhx8pKSAcOQJ4tqBbObJ/
v/Lnrp4lyxYvBjkHngbBpYuWLU91gVwwHhWpR5T3UZFQSansl7kd4dJKBag/yWXjHDVZTY6mrBbz
bEuPhffGKN7KQ54XPTGJFgVLMBCENmcOVUbJVB/FjMTYGdlA0KV3Ar7U8+YnOm84oZVfq4OWYCII
vbxDJJFQ1G0tpmElEliJOqxEHVaifjo0+Jgslbgy58I8+I3W+TypU6vkyRElVwjjaWQbQefHzO2T
J0z/w/2HDoEfbH+2oTX5uzGVZVsXvvSTTbejwoqxLH5swvTpKZQjI2VVj++YvjYv4E/9dzha1osx
qGxkzyAM5lOjqV/J9Rh/jIfJwvhzelxZCwztpnbbAoS+ud65Wf051tZAT2B9Vn+Eyc8PxmlDcSyb
EwkOnTCKUJidwVEV6wqQUWQznmGB00+JXBZt8etQ9OtQ9GMoFmHD+NdVWCqApSJQkaigSy8EoQa/
co2RqR0YFO7KrSfDx6NE3koQ9SahdaeSQFWGLy3IEEStkNcKMXokMM9Ur6/52RuiJ+K8EJrt87s+
GGS6ryle4/F/PhKmym0W0/N7GfoCiHZh6CpfKNc3rb3CK9H3XQRYtVq7Q8PrOXmWALJABIwDVVmT
LQ2Ohqx5YI6l3bEaLIedUo/hCrDeYIPgSXS0lffFIMle+J1rlSGAkPXECNHDsJaDtM2J6hYTRnIW
tpspE5vYRCKkyYNtaDJZsTpIkEww7aVF0kh1UKz5PzG6NJFLU7u/aUTuPIDLUV0QDSerqqJpCFer
GCZ6AmkWbUl5XsB9ahBMQxnrBxkXlXt3KMOKWfn0EHhgx76GGfMfvLkrEgtvaPn08MIbR0fCsCW1
h309FKm4e+MD71aCh+TFuVnu1O+CkZJVOFttH/6YhajOKEMrQ0W1hBLRM8sonNZ34ZGHzNpN3l3k
3UloooOUy4gbBKiQX3AEioUiT14gL1oljLGOzYgHxpRMFSZbGzMmB6YW1pW0Ifi2BlojK7xL/D2B
JeHO6FZXX6Avp7+kP7LdHhJls7VSwG+Ijth8RUwWFwzmx0ijJMZJwSKnj+Dch53BiG3rszmpoE+k
dH/B0Ui2kLjUX24p7yuHYu9oveWtdWq1Nq1amrircEPK2WabW7TMtrRos21D0XW27UW7bXcWSbj9
hNZGDzl6KzcPM0Ym3f8u1BtSuJzJO9+LcrlYOKOx5a3bH1CGrzWvAUXf2/9q1+KmJxYdeh5Uf30P
YqbmVuWz79/3y87N8uczf/woeGzu4+PlhurxZxYuuX7d4oU+h89R8puHnvuiuvREQ8c1y5K9meYi
Z+le7SEd5hRRG9fJXsDEOZoWLGJAbBZpaj6AhFs6UD4+LUskRc9vZrEgeUI2EOwKGnBP7NMQ+9Ul
iB0mkiWrbS9JfhNWN6dqpB7jMR5kTqU+P5T6HN1J8OwHbHAPvrO9KEsXozvLon4r+0P2kKeGrhGn
0dPEjRkb3UKmiXaihfQ7AiOqrTN6Xjkh2wh3IZxQ6zRiPTCLHCiN4C8bApZAICAHaIvDuH/4T+q0
jGRjiDFdrBnJeYy40sWnMuqJykj6puhkRnUPEhqs+FbFRd0akai+oI2PVhvx7hFNM/SRLa6fMf13
1934Wv2M+kPBwtLdvStujxQGD8E5D/6tZdqUqQ0zP3mM3jq0dfONVRNrJ9ZW3baKvh7ZSteMOepG
eUk9aEBhimF5bi63naM5B7ImyzNzme0MzThoSAugjrSf14FtkKNYuJ4GNA2FydRUvK+eZqg8apym
A3PU5YJFAOjHQIfpON1K99BbaY7u5rEOjOaXtJG9ciQXpCVg/CaQ9nQQVGDVN3VUOZM6+iZ4A7yB
6osoeh1ls9F9L0DlzU24yqBelh+vp5fSm2naBAyQYSDLCkaDG3hpD+sVvIZiulgoNoyHVXQ5ExOq
xQppnKEJ1jF1wjRxktRkaAXzEDrnsXP5drFV6gG9sIfpZXvFHlyrMOuEbeJaaZthlNGBrso7OBbh
HNCkPhHJO0VTIkRwRsGZgxyyxngqxjVRddwWaj3HUWtRkZEwd5gHzAy31GQ9hcIAnjUWwck+IKA2
nwDin7gnj37QvNEPf5PyXx8ov1Z+956y4TegCsRQRgKV2AbMm+dKESMtYd4+l80cRXdVp7F9A/Wi
vHs92MJDiWElH+OUSpmQVClOZ2qlNrqDaWPnii3SXMMyehWzjF0qdkpLDVuZdZLbgOcmOgReoB0o
U7EOjuNZhgeSgYMC3llgAhx0wQI4BtZDVhS8QrFQJTQILBR4icFVg4lyUQXUGKqeakErv8QkiJyX
K+aquAaug+O4Jag6T5bjlw1vqEbrr5pA24+g/yATJEVIjEBWf2xKgeBjpVfp/CPkFfYY+D64i309
lZOywJ7U3fAT+GnqIZik8FZ5ijmOLCBQb8oLSkEpU8THeRnIjMy38MuYPl5ycV6hkCsS5nDtQg/X
KwgCnjPnQGiHlInFmwwZiqcZVF4iBOE5SwGpWRqQGBTMUBmdDmeqEjCyBFGIJMBgrqhVJ1/qRclZ
vSg5K5OiEwfBAZTr0kEuisOaXqRUWY/p0FAdAttEBQYKdtgizPHUN4dSX70PdoO7UbU3mFoHN9Ht
qSXwLuSpw0PKm6xveBoCpO1p0AIRKmAU1eqU3l9lfdh5lDc3IWazbPhDJovZhBatAiyX240SE/JK
zhATtuP7LCXvEfLebp6RvaB0ubkza3Vkq7TF0Ze1tVSCQlFNmU22QZstR2jOBJmZnkQOM3qiIAHB
kgWybIVx4hxQF62hXjzigcrMoY/KMlAcqR7taY1LDb8e4lk+LToP6RIL2ZnIkZqSU+t9pyhyuvj1
/bglHogn4vQoHNDxdwl3MOGvjBLwV0b5DXgtKglfIOKSQcDHGYiYaCDp3ECqKIMLn9hAClIDCfuG
a0d0XrSS8nj6M94GkSKkSlNZE+oOd1wQkP0QOHmjCjOudR7Ufep5ld+6f422jdjmzmQ9520tim6Z
ufsPq3qWgOyHIyVFfTVTn+6SKl/r2fCEnKh9bs6ndTO6+zcufnijrcbuDhy+e+CeSCRHyJJne9zW
wvznLXmF0VG7VipZKIA4MtxdrZ1d0xEGDiAM3IqCfAaVA+xycQzGLeOdZTl1cLKlySnnzLUvtQ8I
WzONZpFz19oYI8iWOckgONSl5Fod+v5Zh3/k/tkv9Vz6jWwgC2jWd2vtI4ulfx0NvpaLycrdmhvI
TeRCs180qqouKcMEfLhIHEf0GbEKSFIsFhguTK6n9Jx6WjaQNMvhb5JkS1Lr/uEvnibJdmfwQhUA
rVa6hMNLShYOU+CqC/Itj/VMvDp2dacPb1N3gd3aPKn+8SUdN0827hls3rv60McvXnPbzEcbWtY1
/ujnsPLGv0xrbo4UxDhH6s2Js5TXlOOHf18/NnVlXibZy718+K/018xGKkg9JU+zhJpDMAxyzSWu
PM84EDePc8U9jaBZqjM3uyZ62kGreTnoMW8B68wZVqsjYWSCQV+CFi0hopeFyLbVdDF8RDf0EXkU
se9NITdBtdsvEryLAjEw8QCR0FmRmAzVuWeIpcRrc9M9n7A2GtlCS5IemsZFrNSI7pkKWrLVl/56
4WMdm19paGwBkX90HpguzXlm7v0Hnnq4akO0uMEpTYmU1zc0/Ok2YAdjxxS+PqnhnddeeTfb44za
EDZXImxO0rAJ5fxqX1nm2JxmX21mQ04bt4zrs4p2AG2sZ6KZAUJ2LSvZHP8i1pjUWJMra/A8LYdI
yCEElLKOYHslxHySFnROyRESayzqJmFix10qTrXN4GRnpt8vePCZBNzlCOOzCeRsAlEfBXKkQLbH
CgTJgoDPJFwbvECeGimoE2SWl1M6FBPI3CRwhHKhTX+6xW2roEduSWAmDc7Ys/TwZzMm1z3V1baz
aXBw2qb6e/fsvL3l4fVTLgMxYLv5yGXTWvILwbGzw/CqXN+fXvn17+uxJtM7fJzpZLZRHlTjHpYL
C5iwqYwZb6rOnsQ0mZqy55laXL2mTvcm05ZsM6gOBCyZNU78dMcneOszCosGPmFBThok8T5IgOjF
VjaRkY/KSbcq64gNbwniAjgRpAOAGAcQOg38dmJGOzGbneDTTsxmJ3+3Q/xl+7Xp6hUZSfVdHIkr
1HIqTKpXIqsHz3dw8X6OHFU4sDu1YMt0Dr08YUzsljlr/zpa6ji0SjmhHAbhb47+/Rlw2+27nzRC
/9I7R5eVzS99tWgMKvmdCKO1ypmvS37w4N5rVMZF27lsZLNfy0t9BFk+Uu4LjirHepZGdCThpAzm
CYKNNQkU3gElWkQzwpxRTTQkxRCXMxBUGABJMT6LjTLLJmul2YUxas7BZzaT75jT0c08Cl/JjBFK
sqHZjs9jxp0ybUc/Ppf5Ou9ITJWXl6fUQVTriyUqSH+E9MNRbtK816n2BEPxCpSgMM5ouxToLti8
CsxSnhwcGDj0XKKnhF0oZqy4seDeoYn08/fm//oto4A9VmlnJiEchVAdH5UjNRkTSspLx5XViU0Z
00pqS5vK5oMkO8/VC1ayva5tbF+OLZe1B51FcjbD65UYHsh+PCmeN8i0adREJ2/hABfMKydGtusu
btddHA9kFSE+ivMQ/57xHfzbd6lvlwfKE+UwTKAXJqsS9ntIp9KDfTsfn8lDgqWHrJ+HPAnhIUfi
MXq/dvTIbII3oH47PTipPgaQdu98KxW8sAt0sbtXXuzuiqJ80/7YTGnU4e7OK0Kh7Na7NyHvnzLx
2QVdVzeifNR0lXz33mvunPnIgHJMOe11v2CPjyouvLxuSd0kVFvxt74+rb65sKhs6G3YlZv12qHB
FxMI1wcQcDtQ1HWBCjmDdrqc65201STUZjBmAEzCt0bYMyTZQL2OhT7SxdV6AkOyjSwDM2IZMJ/T
BorGEHJ1frePLAvmaDGSwgigtbL7+56Ap9MDrRf4kDDCh3wmnSOY0g+xmMjBJp0jmPRK3ESUCHw1
EzmFCW+BIKobVsqICLfTPbLLSRbvgjBNIk8Ya2YJleIFQ7bzu+p1yuByMh2Ddo93YdP0R6cPDrYN
Ln7qF3Db9B0FJcXTxg/9ApGDVxtnvvcqjsRPIFpwNfs+2UX5kJwB6iAyTyWkOVTR4v2Cu4hBS4mt
OhkyMe2hXxJJGLXE8AFIunudA0RvOaI3fzWDaN0u3SCsbhBWXRbS8x1WpcKdQnq6yWOqBY6FSfWa
IBsIyMZD/FjX1W++aRwcZD0Hz+YzSTST4ReVdugkM/FSr8shic1kYXo6rgle1mCwyLyp2Q3cAxKQ
QKdLR5ZLF4Jc+v24dGS5fGT+6mNZnZK7zwu8RAX0Eh7jxXSHTNFLRFD0+ZjaJPBCLSmpe7S8+LmB
DHxqL4/P62Xxcnt3+UcubrK8XJ9yNBlNag1bMu8kmfelfdtQPAidyBKHHy26ulTK7Ig0tLlcpk/B
I9gw0kuHrcYnDZlFRUVrZtDX3IsZ4C+Rtz2BvM1AnZXriuAfwfsiLQKLKQCyYMAUAVFTmUE2zDYs
h1sAfqgP+NChgrgPGiRaEiArsTwqkgUD7JT68KMkJMkWEQ+iTDkm2YSKd7LaNEEJzeA5aw/j+EZC
4+hF0EgjIo2R46qvsIyGkH+o0hwaEF9hrzNe6iu4TYxqILXRllBVHvzY9Ja/e5gXsOyBhZ41wRBQ
nQXVt8wTZxR5y+AgDJxM/RN82q/cwDmGfDCaGsLP2SCTbSTPDP6XXAgBEDC+d2kxRWW+xJO19q5v
AACgzxGk4Q+M6aa31uvWsiogUwOYAJPBTuY8+MmEjmtPqpIHGTcODhJ1DEdM3o2yXhgclpvoPLo4
Iy+juC6nruCZEv7pfJAfyMoU3LVFuUwWC6yZghwBgUhZRI60RPoi7L+++QhOhG58wxHCqABpIgJB
6+CfILUWwOttI/MpIwdlalP6ioRRgHXoMJkMIU+gy5pvyNSeHybXtJBrWsg1LT4rsQW+jpVcB33+
g1qOWwvw0VaSOa044uPTW/XQjwbnCBzQYFgO4ktZAz5yGR+5jI9cxkcu4/Nl6ouSmVZJM8nBmTrw
MvXVyUxznEwJnyJTlQLUgWzGV8rsClhl65VW2hpNKyk6Aq0Xfsba+/lDtPCNlahqBM/qVDnZb31R
GEfFuO2iqO5UE7Ia23n3oMnpnjOj+d5mmlGH0+/GYf6JxWvvK1w7uGL/E3Bbw/aicGlzjbsmOxWH
26ZeWxQO49DPJLc1zuxs7Wz94DCl516EJBcovjj3sv/D3OsekXvVZryeaBVd+P4LXuGLEi3uSRUR
NJ5PuSTZqon3X6dcgsoLcq3qW+kk/L9Nuf8p4zq/Q8YlZkcJF1c+HzJrkMUNlBtFYN94c8wac4x3
NZnrrHWOJpdgSYiMM0FLRn0HhFE3vRG3BIjJjH6vrNl0SNc9/qJ6kfYA8f7h93RWc0qvy0/rAshZ
uUYVQLwWb8Cb8K72MnaiNdqJxe3EynY/5yJPGRNVjCMElSO1EYcplBefHT+NjN5J8xX/Db1f6/k3
+0/C4fM7OUc0VtNPMmGOuUb55LOTyqfAffIz4Hnx8d13Pvb4Hbf/FI5SvlBeAtXAhv6rUQ4qX7z7
xhvv/uHdd7CipHQztyKL4qo9V84vh1XO8pxJsNFZmzPHvtR+hbAtU9LVJDZb5kSD0aHbFA1OExRr
apJmzNd0OH+pbX+zX7zh+lKrnv63spLxu8pK6Z5NWl/SotF30pcuFZj+jcKUBu/FCtNl9bVPds+9
qXFwsOm53lc+fPH6W2Y83NSyrvGePbB654eXTZ1RUKSUsv9cn2hVfq98/srhKVWpHXm+N0k91k3q
MbwWvBweT9f4yjLH5Uyjm3xTMqfmYAWFhTbGI5sZYMyuZUWbQ9VIvnOk+a5Kylm5XVVp/6OSQjZv
CxxRTuyX6CdmfBZB+HcqykUp4GIZBYRs/6muGpz7f7p/fXJWXe3exfNuaECF1GWbpjz0+HW3zXxY
6Ya+pkZEU8y3/rmpsaWosGzoebgplPnnF196o16L4PRaRIDt1KDsoExWxMEQ/7KguD5JsrCiMPK5
AW0jBUU5ZEefAxp5YjieTJcn8OIJQnmfqCNUTJMYDc46QvHGFdlGdL08DE9R0rU8Ak80+Kcq6u3M
+HaWhlFZrT5xRIx0SbKj10olzWPmPtg0ONj30/bRpaX0rZI4vWbor0zykXlNLI9nf/nwx/Q7zCaq
AsyS53JQ9Duh118gluSVi9V5teK0vIVs0jUrOCc6u3w1u9LVmdMd7Sl3bGEHbP05m4v6w9eDnaZr
fTuKfgDu8hsos6eYyaavzEVhBGMiN7dggqoTyITs87xhAi0GzRhcYWyMYmK5YmKzYn+cxGQP0ZI8
ZAOgh6QcVMifforU62Yd22aiUxPdxE8FPTzJoHozOL21Tdtt5NBiTzrknNFDzhm5kOD6Zq0H0REf
iLM8Cds8aSXwPrKc22OkaXC+dUB2BITD0XRcTktZ6I08gao/ATai3ojHCtNtfx3Jaf3Vrbb+3S76
ndT7234/RWp/r3vbjQUFK4uuit+2tWrc2P9e0f1qndTwu8VLbw6XLIxdFb66vh7U3vnS+NAbk5pb
5tTm5npEj7lw9+WTt5RFK0eHXo43Nl82ORRyGT1SduNUtNYThk/AFHsv5af2yrVG1seGWdpg5SeY
DBLr97sTtNicNZAFzdSNWYLJStBqJQtkJSzbSpbJ6pMEHotdPK7cbGTDJRG8NF/Q4c2n4c1nEmmI
nAM/qqCmYN5N9l3uzLxQ71LxHbWeLteqt4oKdcORKlzjeq0C7151Bs930itg6v+29x1gUSXN2idN
IicViYMEQRCGzJAECUpQkKgIK2nAQWAQBhBFSYq6iDktZswBFQNm0TVhFnfNWddddY2orJG51c2A
o8vevf/z3+/uc5/7eeSd6u7qquo63dV9zukz4zzefuO2kpL95MS2Yq5u90FhtqndlZTUtHafpiKW
kr5tjUvb6KEp1pbm+jzU6+thDRELY747qe+jo8zuyRnLoSlWNx5Lsz9LieR2fVO6tYtg+tzHsD2Y
/mm1RsnD6JOOZUSrj6PCzRG19njavlL763sj3I5Hl9zOZbf8RnWHn7kdcyoXuRZPdFwsgtuxUAPi
LY4k3Mk9vnkW9tUd7HbX46nOU75Oc5Y7XWHbgqYjE7t/xGbx1qP7NfT0YyKC6kL2F4eEX7lAXfo8
MbrI2sYy1IPuDz72Qu9TgI/ZRLWPrwVjxXZhhOxAJojNtmIJWT6sIaxEFouthx7h6tEUbUn0pt0I
VzqYGEDnk2MprnyjAoviUiR66eKQjxlPw1WFMCAyiLEEQ1SjjQo0rU2L6HyaoQ3wRsxyDgzRBJhR
Etr3iiruU4D/6FG1/GE9U9LmeaCt3xkyjoSe8HElk/BpMl0E1sQQBJiaQKgQLXsILjhXvrGz5cve
Rfxq3hufyXgZTBvSNmQfyoo2ZyxYZlxrZSfSg+VPhrBiyaHMMFaschaVzKRyM3ipSqOUi8jxVC4j
5Y7j5SmNVTZSQc3n6LFZbIKnwaN4HRsUlNjRnXsTwAHqbGO2HZsm9HCEs8AdaLqahlo/NYkaTbDR
Gh6vNDv2MrHxLmu8tMR70tgV8k3NDjiCyR9Xf72RAf20FGndsZlBG1ykzXZpu7W57V7bg7q260fP
kj0WkUY/IlfRCZ+Qu5bRSegPjSdPONel4DNl4p7PNJ6yPqlD63D0eb3p3hxPwoN0op0YJ7YTx4Pn
pRRKhJD+tD/jz/bnhPAGKcWR0XQcK5oTx4tWlpCJtJiVyJHw0pRN1SmC248ScMMoH+54Kgc6tZ6S
shJ2Fr6lQusxLIakWDBg2MxYJh+5igGaZFOqJDhNmWGUcLfpBd2GDUZWo1eO0Neg+KiOUGXYFEMy
ONIz5eg2SIID3t5ijfY64FtH+GvlutjqYNK508GRZEqfwVL68A1yR1v4M9KD9LzZFkTWtUVSfSkB
+va3z9eRd7xgTYdGAoeY5uPL4P3b4exEdg6bzaM5rJ50D1YgGUQPJWLJIppHcVCfYOkxNBNEBDIU
QVMMi1KhRpIkSdE009kkNBKC8VhgEdU8dR5JM9pMACNi8sEv5VyNX9rbg5tDdNzJkY+DQ/KNK9rt
I+Gz9OSFNr8zZCwZxyR84JAXmd6fjtKeyPYEWB09ANt5RIyPezeuO+3MDaYDuPF0FDeRW0LncJU4
HNobOinF9Sa5DJemOByG4k1XNlbupzxCWaJcosyiJiqhjXS/wIhEL/vK36OQP8QwMXFGuxy6kSb0
g09jqarPFXT651xqWRXtvKTyU/s1NpStYpThnGvvomkI4OwpKugbegg7/F6gjvzBPEyn9KqbNTU3
btTU3KTm488bN/B3ZXky46mbBE3o+qiQUWiLBf76RMouQXGjBTP+kwH9C+WJ3l6XPaMfkpX4vpXt
TkoXpjv0FVnbeSqu+FUNVfA/iV7/p2AuodDuWEf0zjdpjR7JgE8rv2979YZ+SNmB9uXwKcSS7GCp
CZX1kDRdEEXpdoihQQxBkWCQoij8vV/Ctlffr2brfG4GYfifsfxIJapJE3y0kW1UBLWFNoYjiE6n
K+jNjICZxXJmPWY9ZhdwenAiuDbco9wnPAveKF4N765SkLKt8iaVSlVCdbZqi1qM2gf1cvVTGr3h
GA2x/o5WibaJ9hWd77uJum3rPrD7qh59emzUtVU4/HX9ewbqsfTm6gfpPzDIMgwzUjPKM2YbLzF+
ZKJqcryXxNTZ9LlZlnmK+SOLGovW3jMtjS3HWzb+C447/4LjffthZWQV8O/j38e/j38f/z7+Lx54
viUJguMOk7QDmyC4pA1ceTTIFhPqgLaEBmEmOwdoI7sP2BfyNQgX2VNAV1kGoBCXumP0kG0F9JRJ
Af0xzzDZVcA4TA/HPPE4JwFQk1CXTQDUkCUC1sumACKNZpBzDtBF1groCvlmhBumhbKjaCM3LvUE
XWZErAy9BT4Ulw7D+XFgpxloQXQ9xp0YG0COOWh8CqhBKAFqYtoVZJrD0kSJsMB6LXCt3sCJUBOj
K0Z34O8NbWwF9ATailBv+xlQE6MhyLEijDD2gqsFK/DbYkBXwgjQH9MDQY4VEQFoA7ruA9YD9sVW
9cX29IVarYQd9okdYQE5dkQfjH1hNWRHOGDaVRYDKJTNBnQHyXZgD+IfhnPiMdbjnAZAB5B/H1AT
I2qLA26FA26FI26FI26FIz7XjmC9DqA/pgdiRDY7YTlOWI4zWLgYEHnPGctxBv6rgIjfGfM7w3lB
+fGyk4D1mL9Btpdwwe11we11AY0IXWRPAIeBZBfcW1yg1n3wnXrbbUAN6GmuYCGiDWVuyKcYkZ9d
QcIUQAvQ7gq+QugA2l1B5htAV9DoCrZBfyUCZdCfwEKEwdDTXMFOREdjaTGyUMChmB6GMQ5jPMYE
8LkrtCKDcMP2u2H73fD5EmI7hbj/CLGdQrBzK6ARRjPwkhD3ASFoRxiBcSjOj5c1AqJe547luGM5
7iAfvbSA5LhjOe747LhjOe5YjjuW4w72HwUcihFJc8fSPEDOVkALsNADPIPQAaM/Lh0I/B4gAeFQ
8LYH1EX89YCe2BJPkCAF1MQ08rwn9rwnWIJ4UG/0BGmIZwCcBU+QOQEwGGM42OZJDMEYgXMiMR2F
6WhMx0Bf9QTtCIfhnHqQ5g/0S8A4sNYfrHpJBOC+F4B9HgA5H4lAsO0pIOqBgVDrKTEQaCkRBNeK
noAqMF6CCFXo5UE4zgRhrwaBhCmAvYhswHiQH4R9FUQ0AGcI6H0KiPSGQOlTYjDu54OhXYiOwIh6
cjjmDMec4ZhzCM4ZgnOG4JwIbHMEtjkCSl8BDsd0PNCRuDQSl0biFkVjn0fjdkVjn0eDb28C1uOc
BogksVB6FRBZHgv5iG6A0ToMpIUCotJhIBPR/pgeKHsOGIER8ccB515ApCUOOBHtj2mkZTj20nAY
KYgeAFqGg4RHgMGYjsA08lg8yOkPiDTGgxxE+2M6EHTF47rxWHs8rhuPbYiHs49oZEkCtiEB+FsB
B2AcCGM2AfMnAD+iozCNbKvH/b8ez0T1eCaqxzNRPZ6J6vFMVI9nh3o8E9Xjmaget64ez0T1OLbU
45moHs9E9Xgm2oljdQO0yBZQE2N7jiv0kwYYnamA7tCvGuAP5cSA3xrA95Z4/rSlbDt/s8iB6Pih
KJLgQKqdpoA+LKdpyN0ipxkFHhZ6Z0hOsxXyOcT4TppHqBH35LQqGUq8kNNqRB/KA/1aFUODLhVK
hGkW0BpUPqbZOH8Spjk4fxamuZhegWkeSEql6uU0SajR3eQ0RagxjnKaJlIZdTnNKPCwCF3GT06z
FfI5xIdOmkcYMHlyWpVayMyQ02pEFKc3ppUU7FdGtnHGYVpFIV8N0ZwqTGsg2ziLMK0NtBZnPaZ1
FPi74Ta2090V8nviuvswrY91tcs0VOAxVqDNMP9JTPfF9BVEcxVs5irIV1HIV5Hbv57vIBC48QeJ
U3IleZI0Kd9PkpsjyU2SiiXZtnzfzEx+hDh9pDSPHyHKE+UWiFJtY0S5qUnZSXxxHl8klo4U5fKT
+LmidHGeVJQrSuVLc5NSRVlJuaP4ElSikEzrWgtfnM0HMfzobLEU6kdKk6SiPH5SdqodCJBgBSmS
/GxprliUZ9spwb3DjAhRen5mUi5K5yFpzrYCB75lJ5/VoCQpyCjk+yXlgoHDJPn8rKQifn6eCJRC
E9Ik2VJ+Uh4/R5SbJZYiA5KLsDkB0aG+UJqLEzm5ktT8FCkytXCkOGWkQl34FGenZOanorZL+Kni
vJxMUAD2Qy0xMKQAlyhbasvv0C3JziziW4qt+KKsZFTpi6jsDuYuLcLsqeLsdHB3HrgjBXlPQTv2
o1yWBzbAUgxapKIs5OpcMWhNlRRmZ0qSFJWCzUntloKjOz0uyZfm5Ev5qaICcYoI8YwUZeZ806CR
UmmOu51dYWGhbVaHu21TJFl20qIcSXpuUs7IIjukIs8OJikJkUtkEUlEJoSrIkglE0WkKiHCPzvz
GP6+lEcSUvjMhhCXBHmpdA1dTx+gG+FvD72X3kSsJ/gQfgRwuAE1iBATKcAnIfLgLw3q8gk/LC0H
YxLkiIHKJmyhxBfkZ8JnBOSlEyOhLA+nRPApAu4CwFTgjMGpVGxHEvoCS8wngk8p1EJlfJyfC3Q6
LpXiXFSbDzTSmwqpLNyGUZAn6azTdWna/1NbkEXZWBayhg+TcTa2rV1/uweluFV8uS/t5BZIFFqQ
Aql8KEUWiTG3bRc2uP/JGxG41fngSWR/R3lep23OIEcA54gP09Gf5VlBHrKu3Y5C3EYkp92Dw7BN
fOybIvjMx2emvaXtZyENa5HilqF0Dq6Xhdvf4YFkXLfDOwHgn1A49+11cxVKcrBlqaAlBUts92oh
1pUC2LXe9jTiTQEf5ONz2X7eJYCpuDwHe6eo0//tusRyCSlyWSKMqGd+225UnokpS6hlhXtfFrSr
Q1NXVmX/SfJ/3UdfpKdiSeny3p0n7x0pnX2v67Z/6Y9f2+Wh4AHUkva2SLG+jl6N5Le3NRVyCnHL
JXiMdN3Sdj8nfeVTkbx3f9vHkVelwJePayJrC3BrRJ1yEGcmcPznZ2gk9lwO9HY7OArxYYs9+nXv
tsU1s4BHCi1CLUzHbcwBCUWQ29GKPEIxKqK4J+5M38NRUvRV1BR9FRdxZGSMGHsmhBnAeAEKgTsJ
2oa8hqKpL3Dkykd3UscPbBKwDh/TxS92ta8C8cqLIGWy9l8ZhdUfQXQn5L8+Su/EL/5+WUsShBJc
e7sQZGaSNBvqwronNGogn+geETaITxiALhnWqICd9dwghHRdz0ihBtn5SRJUpiQlk1DDqIPlkHJp
FFrbyVMa8k8LtBYiGHoq/T1dRU+DFEW8Jz5AkTHJxykuQdLVWIpULk0uT19MEFgD/NNPEpTrJ7B5
fSoHVv6hSnKo5eX6gyErmCJJe2UBj82yVqMpPRYhSGIrWbNJhix3pUhmeaRgiMBGIceg1qjUABbq
6AiDUYb6CjqjqHd5o0NgoiCM0Xkr1DkRuH7OjrQny0I9prrXe8x0m7W8vHsfQTmjJSinPiyn0bek
qMMCvsrTc4pms3drytM7PgLVTkvRSluQY28tsGLT0Yyydi8/SU5RLlrH8S1TrPj2QqHrN2sxW3sj
gUE7c7cuV2n2JgJjVE5r634pj5BIpHzffOlISa5YWiQw6qEqdBXY2wsErgL4F9dD1QH9qqy9PPkP
WFRO9lJ0C8ki6HJSnYB8JaqcJIn11IHDOb96tAzWt1y2YMx3gie166vNR7xrmxe6clfbklq+d/GQ
2kW1MxIdRjX3Ty16vqngZNT1lt8XVxrMWDYxbfuxUWOTTS8bet5WJ2c/mn+0sW9aTc1Iix8uuNs0
quwcanE48Dclb7f5NustheueBlX0fzBRfV9NZnTSpvLiFYl9C0Mf/7Aj1aMm3MCea6azbP1vs6x1
f/VamKKTOJQlWmboGjH5j7Uv5lLH9X9qjA7YPrW00f1p1NzBmz+vHZslHbxF98x8nqUJETszUey6
L0SL4xkjG/5xVZoSd83FspjYFw0e33UvK2Sutx7cXDqvbevZkstr9XLjPU/tf8ld2UuwnT3p5HZ+
ofakOxT6bYSVZesEZasFZbXgTUOSKasRlC0o1Rh+IeeFOHep6ZAJOtsGTZedXpH7P3/+yv+mj9Po
HM57pHyo+vUCXednu0mzq4War+MTHZYtVT7tzZo1ZcZJ919NWl7GzrHZuXxAU/KLT1fOeHjErXeJ
EreZZfU7eWbDbVbxLftqr2UaORn72rTCdMWHPl3we6AZxw97kjxuy4aeTdau5n0PilZofW+unrLy
jyiD9yYnL3d7HbEp28+B87m8x7uH6ZmqQ1oPvIo4ceC3o4JPfHveFMN5VnqDLhlSq1+V3qV3DH9T
f6sp9rko6EREVMMO2lJLNvPyS+6MCbsXHNvoavPL2F/WFT4oWE5cyOh3+KLL93d9tdY5Z+hn3HC+
97MB88u6AKYpztEte5CBavIupdppP12K6hd41iB6Tc4NLffJc/KXrb24HKJCoqCcDm2PCkq2GzVv
hsvil5w+1BFTDP+pYADj3s0B/kEEcIBgYO8ASeeOYFCEIygIYWtT0ZH22gJNlOBqK8Um5Y2Eixwp
qNEQqKFMjjYnQpSaJclO7TBM6a8MMxWYtBump1ieKuJHitOz0aVTuJ/v30aFXUXjLydsDxCuc9pk
f/29uXNQ4aGPxktPBIx+0Rz46OdpR0aFRiS/+YE6MuhqUKadmbeo8ZzpLuWBu0rybwUc2DBDLfyY
uXXL8t9UTY2bfc0+JP9wvmfA6jnBxj+c3W7X60hw32LJtW5GHtOEGsJbB6zepHn0JR1kbb0HrtmZ
SU5e/HHvtpSS8vfxy8smTpq+tWX33JXn3daET+rRe/LgW4JWwuvN8fdeZQcrn2UK19o6te6w3aI0
PnnWmLTFC/NUK7e0HH3N3xOmVZ1y2uaaQ0DP5/uC53uER+qeSxtStKFuclOM97Ly8CnZrHrnw+PM
DkSkef0w+Iz1BMfsiQPYzUsvBFdS2ZXEqkOT70TKo8IHQdkfAm0UFMwZFYESmwsTGovFoen/HaFC
HdmoTZIyhiWg4UNgiDLUmO6MzhnDcwVEzvAtr64fHVwzxN92pX/KS4EyKlZnGBhGlQpDB8eYcRs3
Twi2aDm3f7C0dmhvaZ/87ZWfN4bOHUMMenzqd92b4mNqtcWvKb/jpyafeRd55sdlB2IkL1P81/sT
z+c31Vwy2K28rKfq3CvXjeqsxr94tiZv04zbwuleCzP2u2VdnLLF9POdx5fFvFlTDrTdI/Y5vf6j
+L2Gli3rd6v5c/qPshy9y23GXY7qyYSRZw+U+o5KW7dv177pTqdaaI3isW8v3u1/Z1zbvXub2lrv
XFLdnnN59oOwBrfa4r4/e91wUk52pZaVZZhObY1PmbE1bp/wSuK06Il6jm89Fi4vV6kdUbXdZteK
1ac3Xuc3NAp6TuLrqPbZH/HG9+53ggezLcWTD+fcf71247nS/rkFahBjMiDGRMhjTJL6mEHti0bF
ccSCOPMPjuqOgOMoEEDEcYSAIxAKHFDSESUF0n+JafJy+i/K/zbW1N5Qqj7/4+GgRWc3uDvVmQ4b
dSPzoEmvXXObnmxuPH7J4kcHzar91xNsPrrEGHWz3jxD9ZbOymzL0JLu/Xw3VfvUB05RvVY2t24B
+0Ksf0H8k1ef1O6XSFc6npY+fPEgacUEeleA7JK31qWtp75TvTCuZZe26qfEDMtJ+dN21e2f9KjH
jpkH33ZvSE54pnnH/bnJ8KotpXlHAh7Mm1qYuOi3usLDrtWOOnbaN5JPbtZbH7Ywve5nvlAw+m51
euD94wZvVMOlvnaPWGYZJqOCts4+uk14ov/qrHjd4I0zrkyv8B6jNODqqm0TTY/cbxmXVh8sPWDh
G7I4SSdxsKCp/PUF5Zzi59GDCi9yowvK5LHmnaDsLfa9oToasTAI2YcUBuxrE5/pxUPeRYUsfNjj
SkaFE8vW4lHXoQnFCUNTRlfQvbTrYe6PGIwZL4GHQLjcdblzpaP8PlZKbuY397FyRolRrp387l+e
nV8kdDRbyBIM7FAJ6xBPgbvArSMtoCpt/vLGGBYoylWQJP1mAOFo4xMriUxfyq9wItV+7RHiWff7
1bKS56pF0sKwBQN0XxPdxBNuJM+s/Zy+YvEvllYfoq/80Bbe+B1v+541z8pfLzSSDPvw9tU9lZ+q
uN7de/CbD+0MGMC1SIzlhcx9yT2zd1D2y/sDtSydq0xy74xo2CLWMpv7/LET78aEbMlspYhTfUKD
NjjYVD5acSbBYv9+z7vDt1Uo73U2CJsYMEC2b+6KYZz182+NORBbsnrt4DMtdYtrfO+fjjfzvlni
NGBw6/mmcUt+bzi5OEUncktdzYsrjeeXr9g479RY68k2h05c+5RJX290q3vVHN+zh/qhP06VrtHg
6t2aafrb1hWh3k+2alqMUTtss2fVqBMzPCHaLIFoM6kj2gQVP2t/IPHPRZsocZYoT5qUlaMYbVwE
QnsXgb2zswNe3tjjpIMAJQVla/4ltvUWmLdPlEbZfuIcdKfWPzKAHxA52N1e4O/W19nNybWvX/9A
tw5GWtvoLxoRKcpF93b/NkA92ctKabpWtHmiv/fq7UefhS41uyMsMOJddggeOuai9bXVnJkvfvP6
eMCieOXHh+MnOJy/5lUldG15d9XDqfvPs8s/Oj0dOSlXb8bd3aF3d0967ahEHa4tyHMOTXi1617w
eMPdc8fckBlN6tY/cPS5kt6xWs0VYR7nP9xurXrWj3hw6XbS+x7VIavKPN+KfZ7cm9rICdsrHfdY
5eGAJxszX11KL+O+635qvPa+vPu80A/JH58tF9a4t/2u2ZRklDz0qlJUxSWPkJD70QfsEvWmz2b5
XU/4vVzJdAFvOcteVDVnsJGvSe3smZ8D/AMkzvUBrnXi9aL3Tn71PX70EN7TmNaiN/lBVLixxxL7
OsUA9SUgTch9adsvxuqu+R8jd5OfQu5NOP/A+6vYI3k0uN+CPU4bQypn7F/8ZJOHr9/xC/9fsUea
l5OS9N8SezokSbuKoNw/ReEuApR4bDlPpXvz7fOBU20bm53GlpX0tvTt8/onk9lqC+pGRH5n9f7Z
4ajgdeP/0L6grPN+UEtlNyL7QYWhZcBaG6HDLUmNa9xz04gZUXR1v7WLU91aXZp0/BrcvReeVD0y
uszyddpa+/vxCTPeR0Tci/99zswlYl7o1ObmglAn1Yx7xf5rrYdXRJUEmPU0P/p94DHzBz1LxVY6
rT2Ov+xlUxb4nfWb92uOF3qbSt6vSZ00vTZZdX1fo3UPZ3qXyLZO/7Tg6avPzJazQefipJs+vNY2
1heeW7nj8v43O5431bXEGH30fNV0uY///sbF/can6Z7dxk9ROuXjJXLoWbxtt9dhi4GDe/X8IXua
4PCrWV8HKI0M5R/CDhHmGzVvBBgPHZte+22Y+mcuvuTRSeDk5IqikxCS/8DF158C59/Fm5uu2R+3
NPUPHq3bdG6gd+ShDxt19to47NMKi2iqeObteC3IfrZlw6zUu8bhE/f+GNJcwnr3Iv9g1Yl1lzaL
c9LG9E571LDrxaQ9Z59v+Ky1SnlYLyu78z7XYhj9gp1ZqVnBUTduvbrduKziROmdklDKde7bQ0u5
MUYjB5y9dqgg3m58gzmzI2Z4hkGKrLTY8/klxnyQsFDKSfgx/mqlq03+SbUnRkJecUHbkszssXef
es9YsHS02og+YbrJiQ5LL1YMtu4VPzKg6rbdRI3wbe936lVnPjdfpP3utMaVSWpvygvyXI7PG1t7
JpH9lLW10nHXu7nDJ/pOHDppbvZWY5uBZySL/e5mPCqxmD6qPd6Uk5bgEbOuR+j/issvDTZPfgO0
G4muqQiF6NllcOzZWUGHYlSMlIhIIp9IJvwI368vzf50XddFgJo7SNP+x+LwfZrTVyRxSLVpOQHV
L/KiDvTjsfrKdg+JnGTwTDhr18oY5dvTGjz0mz9uWntyV/0QE30JVzxhFF3bK/BZ5o6s4l67A3+a
+Lpa/SDne5fDv094nJMQsGz2xTPnbk0/dK+xz9nipyc3O1yavOd0ylGXZl2TxoLbHjXb9fOWmky5
umOHVtS0N4t/FAXXWFosTvxe3eOEtmjMwH3n6yrcw7YmD70tePxYaPhgast1Ydl7bZNpqaUpbGZ+
Sw3lZzcucMpeGXVN9D749nVaOmc7K1vlzJKblknFA1/1WKxp4kYZTN7EPjbfYfdDn+ORXgfWT739
KM21+k2v+YvPbC2MGuJ+Odd/m2mrfTmzGoLUCookBWWT/8Grsq+uFb/c415edkGg03m+LUl7Ds3C
zyhQL5CfTB5tr6J4Wx2s+ZJStlcTKJZ2E5h+qcjYQx8rXdRUzu+de/DXA0WFd6Ke6WfnlXkI4hSq
qNiHCoKX80uN/vPnmyssSs3+C0+6+d8ENaacJHTzdM4V2XifOWEuHS3YWVXVbN2/rXufC5XeOx7Y
RrqteTv+lhvdf8SIBEt9/Vm93pYnL2lzqNhurb+s9khCwxbfg88+fZjHuNyKcalYp3a5u8flDN0U
6eTXGXveOHv1beMISkoWu3t9iP/5qX+i/6n40Pr0GbNWrF/es2lqqFbvj2Z9romLCh9PXzXssu5j
swU+Cyf0M8saLya8Qs9XLRrab9Tv22InaYzKe5DbsnBhIRUeT+3WsW0mHxYt1mH78LYzNk41u+M+
WExccK1tJ/FpLGu9SHdP6QSrXe5Ro+cbOac9jbmsP7e5cuW8D2HVqd4WWcETikz6V6WEFKQePhVx
/Y3+9ojRg94eWLSinDIWlFP6X84M276cUoEs7v94x/x2HvrqsoIj75jLEwS6iv1P+cuzHxJ0dpaw
7NVhgnWzFzii6VTo4Bz3p+63WisiX/zTuH5LaobfWa+daei4enTeN5EKdZEx1jNPM2YuA1ZEbV9b
8avB+5TmI7onPU0P2/D/uDLdZOmWCR/Ol1snzMm/pFxTHdc615D+fOO3yS5Kk/oVON6qWHQ/1ngt
19rHdCLn12Mtg+Zt2U2VW+atTZg7r3/l2hJLzXHNsqLSvhcZ6pcR5j/l+akEJ1hYutqPvHXl5jGZ
V/RSzyc2OoY/+/bdseH55iPmhybvSI6r1tzhUxU+QOfo61vWL5TDDj6Pmaed+VNPFZfj/DQR++1C
U8PG4UeaNlwwPpFu/u7nY8uIQzvm3xfKni/ZlNH7Ji+2xLLbs9bj8RuEi7qFzQxrZKbeVOcsOGpp
crublsqNmNWzfp06556yxbFe9IvyotkZdb10gsH9/wFpnva+DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM4IDAgb2JqDQpbIDBbIDEwMDBdICAzWyAzNTJdICA2WyA4MThdICA5WyA3MjddICAxMVsgNDU0
IDQ1NCA2MzZdICAxNVsgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNl0gIDI0WyA2MzYg
NjM2IDYzNiA2MzYgNjM2IDQ1NCA0NTQgODE4IDgxOCA4MTggNTQ1IDEwMDAgNjg0IDY4NiA2OTgg
NzcxIDYzMiA1NzUgNzc1IDc1MSA0MjEgNDU1XSAgNDdbIDU1NyA4NDMgNzQ4IDc4NyA2MDMgNzg3
IDY5NSA2ODQgNjE2IDczMiA2ODQgOTg5IDY4NSA2MTVdICA2NlsgNjM2XSAgNjhbIDYwMSA2MjMg
NTIxIDYyMyA1OTYgMzUyIDYyMyA2MzMgMjc0IDM0NCA1OTIgMjc0IDk3MyA2MzMgNjA3IDYyMyA2
MjMgNDI3IDUyMSAzOTQgNjMzIDU5MiA4MTggNTkyIDU5MiA1MjVdICAxMzVbIDU0NV0gIDE3N1sg
NjM2XSAgMTgxWyAyNjkgMjY5XSBdIA0KZW5kb2JqDQo5MzkgMCBvYmoNClsgMzUyIDAgMCA4MTgg
MCAwIDcyNyAwIDQ1NCA0NTQgNjM2IDAgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNiAw
IDYzNiA2MzYgNjM2IDYzNiA2MzYgNDU0IDQ1NCA4MTggODE4IDgxOCA1NDUgMTAwMCA2ODQgNjg2
IDY5OCA3NzEgNjMyIDU3NSA3NzUgNzUxIDQyMSA0NTUgMCA1NTcgODQzIDc0OCA3ODcgNjAzIDc4
NyA2OTUgNjg0IDYxNiA3MzIgNjg0IDk4OSA2ODUgNjE1IDAgMCAwIDAgMCA2MzYgMCA2MDEgNjIz
IDUyMSA2MjMgNTk2IDM1MiA2MjMgNjMzIDI3NCAzNDQgNTkyIDI3NCA5NzMgNjMzIDYwNyA2MjMg
NjIzIDQyNyA1MjEgMzk0IDYzMyA1OTIgODE4IDU5MiA1OTIgNTI1XSANCmVuZG9iag0KOTQwIDAg
b2JqDQpbIDM1MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCA5OTAgMCAwIDAgMCAwIDAgMCAwIDAgNjAxIDAgMCAwIDU5NiAwIDAgNjMzIDAgMCAwIDAg
MCAwIDAgMCAwIDQyN10gDQplbmRvYmoNCjk0MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAxMTk5OS9MZW5ndGgxIDUyMTcyPj4NCnN0cmVhbQ0KeJzsfQl8E9X2/5mZ7GnSNEnX
tM2EtKWlpUlb6EaB0g2wLKULtECloQm00CW2KYuylAoUyyaLgLhQ4amoKEFQQLbiCogKuD1REJ6I
oFYRFZUtvzOTNA2ID/r+j/f+7/OZ73S+c+65955777nLzE3SBAgA8EXiQV5WweCBZ64tOQ1gzwPQ
zBiYlZ0DEdQugM1mTBU6MG94gTBJnobhuRhOHlhQlHEm7FwEhndjeOWQwoJBo2KMfweQFAJQrw0v
MMTX5T/gACBQB2Ujs4YW236aUQ0gVwDwT5VXm6ymkU9IAZrTMU1d+RQb3TdniApgGaYnzk6wTqxe
++rI+QALtmH67yaa6q3gD2IsD+2DYmLV9AlprR8cBVjRBiBsrDBXT6PCNzwOoLoAUJ9XYTGZjxtH
nEdbYzF9YgUqFDrRmxheieGwimrbtNQwfgsAmQwgCqqqLTc1p8/bA/AY1kdYU22aZhX0F2DbiR2Y
nq4xVVuEsn5PAqy3A3g1WWvrbY4MmIb16cXEW+ss1qCfHqoEWNKK7U8Exrd8vrb7mfLqcd5pv4JG
BAxe3L27hrm+FZtdfrXs2gqpXVQBJLaLBCcwn0h6PR/LiMD4c1I7yIACT4xi0lCvQqIrDwkKGABF
KOj43zk1PB/iYeCDiL+WnwAxRDh7HUK1wjTyWRGQUgGP4vOkJO8pEDjSgR7DeJTJOLSAptE6Da2C
0OslcEgkJV5CxTomjlfKP8q0FAgR2zgs5ojzpCJgE7WJiIP/EQj2Qs6dpBN+T+jvJB3vfejulq9C
Ee9NKO4I8xWQfCc2qEl3lo4DBw4cOHD4/xPUqwQRHGwk7jxHmFvycUuYnU8AdFrp8W+pHAcOHP4a
BBAMwAt+FzlABCLHddybSJAlLEtBiuwFXsgykDmugRzkyN7gjaxg2Qd8kJWgdFwFFaiQ1eCL7Muy
H/gh+4O/4woEQAByIAQhB4EGWcNyMAQ7LkMIhCCHQiiyFmhkmmUd6Bx/QDfohqwHPXIYhCOHQwRy
BPLv+DzeHTkSIpGjIAq5B0QjRyP/BjEQg9wTeiLHQiyyAYzIRohzXII4luMhHjkBEpB7QS/k3pDo
+BV3XQwnQRJyMiQjp0AKcir0cfwCfSANOQ36IvdluR/0Q+4P/R0/QzoMQB7AcgZkIGdCJnIWZDku
QjbkIOfAQOSBLA+CQciDYbDjJ7gH7kHOhSHIQ2Ao8lCWh8EwxwUYDsOR82AE8gjIR85H/hEKoAC5
EAqRi6AIeSSMQh4FxY4fcJfCcAmUII+G0chjYCzyWCh1fA+lLN8L9yKPg3HIZVCGbILxju9gPMvl
UI5sBjOyBSzIE2Ci41uYCBXIFSxXQiXyJJiEPBkmO85DFVQjV7NcAzXItVCLbAWr4xzcB3XIdSzX
Qz2yDWzIDdDg+AamwBTkqTANeRrL02E68v1wv+MsPAAPIM+AmcgzWZ4Fs5Bnw2zH19AIjchzoAm5
CR5EfpDluTDXcQbmwTzk+TAfuRkWIC9g+SF4yPEVtEAL8kJYiLwIFiMvhiXIS5D/AUthKfLD8DDy
MliGvBxWIK9APg0rYSXyI/AI8ipYhbwa1iCvgUcdp+BRltfCY8iPsfw4PI78BDzp+BKeZHkdtCK3
svwUPIW8HjY4TsIG+Bvy31h+Gp5BfoblZ+FZxwnYCM8hP8fy8/AC8gssb4JNji/gRXgJ+SXYjLwZ
7Mh2lrfAFsfn8DK8jLwVtiFvg1eQX4FXkV9FPg7bYTvyDtiJvBNeQ34NdiHvQv4MdsNu5D2wB3kv
7EPeB23IbbDf8XfYz/Lr8DryG/Am8pvwFvJbyJ/C2/A28jvwDvIBOIB8EA4hH4J3HZ/Au3AY+TDL
78F7yO/DB8gfwBHHx3CE5aNwFPkYHEP+ED5E/gg+duDJ8ifwKfKnLP8d/o78GRx3fAjH4XPkz+EL
5C9YPgEnkE/CSccx+BJOIZ9i+TT8A/kfLH8FXzmOwhn4GvlrOIt8Fr5B/oblc3DOcQTOw3nkb+E7
5O9Y/h6+R26HdscH8AP8gPwjXEC+AD8h/wQXkS8ivw8/w8/Iv8AvyL/CJeRL8Bvyb8jvwe/wO/If
8AfyZbiCfAWuOg7DVbiGfA2uI19n2QEOZMB1FKgdYrEYKIrHu/Pbgsgtid0SH0DAnG5FF+xx4MCh
q5BIJMDj8fh3nqNz3krcEk5YgYCbtxw4/IcglUpx3vK7MG8777JStyTEPyF7caEL9jhw4NBVeHl5
MfNWcPuUHei8y3q5Jde87bwVc/OWA4e7CJlMBnx+V+Zt5122c97ihBWJPOdtF+xx4MChq5DL5Thv
BV2YZ52zVe6WcMKKRZ6P0Ny85cDhLsLb25uZt8Lbp+yArDOvW8IJKxZz85YDh/8QFAoFCATC/8d5
K2FemL7pBWYOHDjcLfj4+DDzVnT7lB3ofDru/IQdTlip5KYXmDlw4HC3oFQquzhvO++ySrckZd5Q
8py3XbDHgQOHrkKlUoFQKBTfPmUHFJ153RJOWC/pTS8wc+DA4W5BrVbjvBV1Yd52Ph2r3ZIX80aw
59a3C/Y4cODQVfj6+jLzVnL7lB3ofDr2dUsy5o1gbt5y4PAfgp+fH4hE4i7M286nYz+3hBNWLvN8
yYqbtxw43EX4+/sz81Z6+5Qd6Jy3/m5JznyA46Y3hjhw4HC3EBAQ0MV527mrDXBLzJzl5i0HDv8p
aDQakEikXrdP2YHOu6zGLSkAfBSeL1l1wR4HDhy6ipCQEGbeym6fsgOdd9kQt4QTVunj+ZIVN285
cLiLoGkapFKZ9+1TdqDzLku7JdzzqlWej9By4MCBw12DTqcDL6+uzNvgzrxuCSesr9rzjSFu3nLg
cBcRHh4OMpm3z+1TdkDbmdct+eG2189z66v4d9SNAwcOt0aPHj3A29tHdfuUHej8evzOr+cNBAgK
9HyEVgIHDhzuGmJjY0GhUPrePmUH3D9XAbFuCZ+dQzSeL1SpgQMHDncN8fHxoFSq/W+fsgOdd9l4
txSKj8+hni9UdWEd4MCBQ1eRmJgIKpVv4J3n6LzL9nZLNEA35nQrurAOcODAoatITU0Ftdpfc/uU
Hej8SbsUt4R73jC95wtVXVgHOHDg0FVkZmZCQECQ9vYpO9D5U4oZbikSH58jPR+hQ4ADBw53Dbm5
uRAUFNrt9ik70N8t3eOWegIYmNOtoP8ddePAgcOtUVBQACEhuog7z9H5c8r5bikeoFec54b3jn5L
mQMHDv8axo4dCzQd1oVfSh3mlsa4pSTc7OKZ6lZ0Bw4cONw1mM1m0Ou7x94+ZQcK3VK5W0oD6Jfm
+Qgd/W+pHAcOHP4KpOsXytVAMRIRhKeg82fLCZJk0twIjKS68iN+RrfUeU/OAhg4CHfYbkVRFyt+
p6D+tWw8KAbmk18KNEBCNxgKo8AEFqiAOmh1OIDZxTt15g6d46sbjnK45S/Ip6cVpqYkJyX27pUQ
H2c0xPaMie4RFdk9IjxM301Ha0NDgjVBgQH+fr5qldJH4S2XeUklYpFQwOdRJAExhD0gs3hLoDBa
o9PpSnq6wkE3hu1UuOKizg7KGxJpbsoUfFM45KZwqDs8zA5qe44+M4sxvAVyztpBZSfUdmBKIVRD
sSRXpmzzJH12pT0w01xWhjmy9ArannPB4KoKa3uLVJKpz7RIesbAFokURSlKmNa6hcjpR7ACmZOd
uoUEkaxnjF0ZbSfDs5lzkj19YRkK+iy0hDGqzpgdjrZFnlGA2ToklVMi7IJMu5Atl660p5vssJDe
EtPWsmiHAsaXRXuZ9WbTWPScCeu4Bajw7IpCxo/ZzFlWQdt5aJwlDWro7Aq6Rc+4I7uiDFmfhblu
qUe1OLO4WdemsSvxmm33ibYPxBQD7z+joVqyAyppJtjS0kzbW0cUe8bqGC4pKQnACrdk69EgGsue
lIFNCTD0jHG2yeUAc9kkpsxJJqae2ZPoloUWtq6L2DqwSbMrsGNMt0vV0pJt1mebTeYMp/VMe3oh
e4HC0cVsA9F1WSUulSsBxvDYmLKsEp3T2bn5xZlMxfSmLI2z292aMpcGFdkdkTRTg8FowE6X03bI
L9Zj0mSGLMnQUp7MDh5dCYG58jpz2fnhCj3d8ivYiTJ9+/c3akwujSBc8SswYo4+p6ylJUdP57SU
tZh2OBrH62mFvmVLbm6LNbsMS80rxlw7HK8t1NhzFpXYFWUVRCr6nhkBOfnF/TU6n5KOYF5HEHBI
4cCSss1BL+DfYNcFvQyFxToaHVVUXKJBPxUzciHKziszkHDgJmMfu9zG+MiS7HZPpkvU6ZjRuXBH
OozHgL1xRLEzTMN4zcuQbojG/ihjYto6YnyLmJjGjhh39jI9lrKNXZh87aII95+3wk+VXZFqJ/z+
SbTFGW9XZRZTGrLEKZEaipEk0TjT0+z+0ShHRrdgJxzR2xXRdn5xmyathFb44ArA9F6BPnfE6GI6
u8U9CpwaV0uZcYBDXW+qaHFNJWbQ4/AgsIPSMwfpDZCGZmhGkWNP12cY2BjzKbBTpzACF42MLXpi
wYgt6cSCgtHFOxW4Ti8oLH6ZJMjMsoySLWEYV7yTxmWY1ZJuLROimRDkMkP1ZVLERml2pgM0srE8
VsGGy3cQwOpEHToCyneQTp2C1SF6Qrq48Nw3gdqz3wRpsaPTH3zHPzDxH99FaL//LkZLf5b+GTn8
8LjD5LuHlNraQ8S6Q5sPkQeXi7T7t4VpH1+bpH1sbbz2UTzXLovXrlll1K5eNUj7CJ6rlvfUrkTd
imWx2mXLc7Ta5Ybl5PJltHb4snHLyHXLiPRTp06RipP0SRJOKk4aT6afzDtpPSlI3y2WJjL1yNvl
pUhUvEak7xArEmG7Yju9nSp7xfoK+dXXeu2Zr2kttBvby9qpvI+J9I/yPrJ+RF2c46u9sC1e+yOe
67YRnx+P0R7/XKf94kSs9sReJdO4rR/KFaxxx4cSReKxvSLtUYzwPqI9YjhCfbA3UNuG576Zudo9
e7XavbNTtEsW5WoXL8zVLloYqW1ZmKl9CM+Fswdqn5gXpF0wL1bbPK+Hdv48s3buvDztg3imz0vr
mzgPM7Y2KbVNjbnaObNztemNA7ISG2dHamdiYPasbK11FpE+a0BmYpS5jznXXGIuM9vMAoW3Tuvn
20MrFOi0gQE9tDxKp1Upe2hjenr3iJZHRnlHdJeHhXt308tpnXeoVq4JDpEFBAbJfP38ZUqVWuat
8PHyksm9xBKpl0Ao8sKHHy98MvJSeDd6k+mCRgGZTjVSpDduXYZDesRs4HmDAQO1MBv2wQfgAJGm
j0jrnSrSUikiLSSLtHkJhF2ZC7mFGXYVgdeCDHtCdO4OEeTb46Nz7eK8McVbCGJJCWrt5AIcboV2
3gIcYYV4Fxk9pngHEchEz2NvKijtIBrnLV6scUslJdEhdnNuQbHdGlJij2eEh0NKIBpRb6uvr4/+
C2wRM6Wb8zO2nOcxtxyT/bw+a8u359nbj/1bfRZhN+PEzKq3z8qusM/SZ0X/panozihGYAvF08bW
AOpt0Q03JrZFd1QLQKBmvsOFf5T5txon3/BoVurUOE7fyNfNjl//tYe9P0MEXf96Y+IoGXWTZmKX
Cz4Kb8N+2Maeb8Bu2I7HS/Ak6t+BPahjTiscgI2wAbXLYBOshydgFTzDhuYSJOYC2AwP32D1IXyI
Pw31KI2EarDBHFgEK2Ad5hqIuvkQB8kwHUrweB52YFmXoBUehwUwDcdwIzTDEngUNa/Ah3CeUME1
QkkkEGlkMJlFriNCSAO5lKrH+ryMNdlMjiN1xHriGuZaiXXbBlPQwiLKDt2xTo+RdtKB9XwMhmAs
Voq51QiZH1yh8KLeLiB5wJyG9068x1KcUeej8wlHIjDV5UY+XGGu0MhsP0hsPZDHcYQwufumR5LU
PiCiiT7EUGIcUUvMJgRoX/iBQTybP1u8lM/jUxRJCg/zwXAt3tDfSBhK8ZpQ2nytLU5M6FWUPimB
PH69/fkTTYfjDvOPXjnIS7ps+BBrGUcdpdoFarYcQ7qGomWKJCFDAiFaxC3GMZLkHaMFhMBQ2p5g
aIf+CQZlSkqckYiOJii9So8n1f7q3LKNeArU1/aQmcyJt40cHO3vYwu8YHP6XDGJGyuxXBpEKii1
WCulKT0vShonTpFmUenigZJ7pON446RVvEpJrXQqzOZNFUyXzJZqxkumkzN5lBfMkZJCERCJRA5x
L7Z/JrafkIv5gkahSChLEWVECBOFOcJRwilCvlAml6UKX5HxSQklns0jeFLgUUIxhe3rr/RPMZQi
GQnF2WihovRMtAJd1Eb4JBhKm9va0FtQSpTq9OgzitATOhWh4085QERc2zDl2PVju4hiQnGQzCJU
vJ+uPkfNunyOf/TqG1RfnA6EHmfVaLa169JHdCcMVKw4EZKIVFwWc4jB1DDxKGqU2EJUiWeQ06kH
xD5SXHFb0UuEVNIkpkiKJxLOEvAFo/kz+CTFF4lxPSYFFN6GSYoSwA7Hl+nBEkWSBHdtNLPxk6fL
rXKSz6cFRkG6gMLOwRYwrYhWphgScIlmmoqdVNqswPYpmrFpbSiK2ohSZ9uoBBWBf6LR13p/HXNt
7xd9D0aSA/HM5R+9bOAdvWLAQRLD++gKzTuFo7G74zRvNG8atq43LEovAYPKEOMbbkhV9zIM9s0y
FPaY0GNKD2kweMl6h/YODZ0f10sdF9crMaVXRlxiUmJqVJRf3GtJggf90pWBSX6wpkdwQnBmMBUc
3FM1PIqIigpf3VPRS/yIyg/6txv6tzNNwWaUtuM4jm5XnPVJMWBnnYlulsdG82cq3myWp6Xx33wz
zoidJSeEcsJX7ZcQn5gkZAP6bhG9e2GpYUn9iN69IrrHokYg1GMoIR73njiu9dSktT8OG1E4fuKY
PflhmlJjwqz8ec801N9H9D8sEEXo9aXJRcezJOEpX1iOHBELNu8ihwr0Ot19hYOGjEh5XNHH11/7
2Mx521NTEgTBUX7GNKVSlqTZ7R3RtFjTV3NNgv4qcpzm98BZpQI9zEsfPThocLdJvNkiq88MjUCp
1ut1FIljZj6pUpOkKixFlRFB9iazyZFkA8knw8LDUhW4fuDzVi05m2wkHyYFJBkuEQeJyZAHxbvC
VOC/yltB0o8IXA7DCa+41M72/33OYd0cG42OkivSRGnoLBzV2OtJLt8ona7wV1FO17j9x+9xfc1u
zezHxjy50zyy6FxTyaoB1pWZcwZXbEjtnVI5pXDzPQL1H983jOp7YN9ThLZq8syICOLMtUa9zjxq
+MmK++cUxjMrV7HjLK+JNwPEuC6Wp8fzlAq5WlmgKdPM9rIqheI16f6Ev79EsEah0OlCVkv8csSF
YpuY0ulUMrF/EDVPxTxrScXeSSpVVNCDsl2Ril/asWXR7T4pKeywAGaE9G9H8b72OGMpwXYz0xCi
W1hvBeicvaxzNyvBOS6oNj6vYc6SL7oTgnPXfyfmEqF7D/morh4U8Dc9WXN+uDQqPq9fvzJyY0hk
wORp9oev9Tt+DO8F2/e8ENo0MiQ5YPFTIxPfVYZ6eytw1ibjvXo19m8grN6epMpRjVRRATscx9NH
i2VJgb5R6ijfSnmF7/3yab7WAGugmC8SzSd4aoLgeXvL1Go/lUKlUMz3Uap9fJQ8HyXxGnqHCEpR
ZkT49PbJ9hnp0+DD9wnSBKX67AzyesRfoQS+DxgS+vdv71y4ShWXmtuc3SwUYTfj5AhgZwd2djRR
SrADXeX2DaUnEii233mrxaKNu1d4yQqqhmwftX83MXF30+Rd5cs3UPcG5GuvRZMzeg/vXlhUmHp1
L67n7+XmrQBni6nz+HyihJr0oEBZojRHWiTleQmFfJFUis0TS9RisUTJ9F2UWJGkVKqtakKVIsmI
EPcWZ4tHihvEfLFKrUoV71Sh8x7x9pZ6i3FF7o/3KY9GMR3tbpQ8LQ4boneOUmxMgtA5cKm9ksjs
uHt3Fm3b69gbMW9nUVxMD2q1RFyUdvUbXunTpYP4zO8laV1HAd6l78bx258PYsItjuvMQc4gf2AO
auItjjbu4A7u4A7u4I7/xYPdiedQw9zvCzH/AumUCdxXxrtkEje4+10yhTvzzS6ZB3LY6ZL5uMc4
4JIFqD/lkoUw021HjPofXLKMGAJXXbIcepCDmHf7eMw7W3KyySXzIJSsY2U+q291yYz+YVYWoN6L
3OuSeRBMvsTKQlZ/3CUz+kOsLGL0FM8l86Ab+QMrM9+Hb6YULpkAOWVzyZiet9wlUzCeV+OS0Sav
ySXzIYDX6pIFqD/ikoVw2W1HjPrvXbKMXMMXuWQ5FAqdeSUebZd4tF2KerWrLbglhjBXW7xQrxDx
XDIPaOEvrCxHvUgU5pJ5ECBi30nlKRj7ojSXjPZFMaysYvWjXTKjv4eV1R4+VHv40JdNP80lM+kr
WNmP1a9yyYx+PisHMnZE21wy2hH9jZU1bPojLplJ38bKIR7lhniUq2Xt/OCSGTsnWTmMsSOWuGTG
zmVW7smkF0e6ZEwvDmBkkYefRR5+FnnUX+RRfy+P9F4e6b08/O/l8v9zdLzRmEwPrSyvq62vnWCj
M2vrrLV1JltlbU0sPaCqis6vnFhhq6fzLfWWuikWc+xIS53ZVGOiK+tpS6WtwlJHm+g6y8TKepul
zmKmbXUms6XaVDeZrmViPIITbl0KXVlDoxm6qKbShvkLbCabpZ421ZgNaKCWLaC8tqHGVldpqY91
W0jtqMZgm6mqspwJ1jPGesca4+lId7IoV7KezmRDTTY0OJXONNVhbUtqG+hq03S6od6CNcD2TKit
sdGmetpqqauutDG1GT+drVt20ZABGFvHBqx1teaGchtT76kVleUVHnnxWllTXtVgZhxRS5sr661V
WAA2BnNVYoJyTGWpscXSHWXX1lRNpyMro2hL9XgmU6epmo7Et6wRm9xcWTMRfV+PvilnXOlROutU
l60+bAUiK7EUm6Wa8XtdJZZqrp1aU1Vr8iwU62xy1hS97nZ/bYPN2mCjzZYpleUWJk2Fpcp6U4Mq
bDZrqsEwderU2OoO58eW11YbbNOttRPrTNaK6QamiHoDjAQL1IEZTFCDJw2Z0IDheqiEKRi+OXYy
G3s/tP+TWGfem+NyPeJqkW0YvjFNHBghEWiqldpFbaK2UjupLfAc5oxHvRH3ocynEyqhHHPUop1a
mIA2mPrWosbKsgk1lSjVQCzGDIAqPGjIR91EqMC4ejZkwStT7hRkM6a8uaaVbDoLW8cKNo5m9XUo
T2RjbayWyU2jXMd+YsIC1XitQx/QbF2ceW4dO6FLbWFqVMPaYmpDQxGGKtk6MOUXoGRiQ/VsmTWo
NbhqUOvRgnIMNWAsU6NKNnXsLeqQ+idvDGbtV7EpO2Lr3TXrjVaM2EM0RN7CWtRN1nreYG0oW29n
DaeyrWc85PRtCVtbmvXadLw2sH3m9IGzfyawNbCxbWbCVjZfNeuZDt+MZ/N2+C0bPTcER4Uzb51H
jJWttRlLKWctOv09lS2rHPnW5TrDTNpybFED28vOEVGLbGbjrRjjbIGzZ5xlVboslLtsWVhmxuzN
7Wbiq1gpEnNFseOyGtvVUdKtalXzJ8t37qNO62bW0kTXuK93jZty96i8dds7R+qN9erj4QGmJc62
2NjyOsY7Y9/ZVjNqprItr2Vnz61b6vSz6QafWlzj/ubRz3jVhuka2JxMbaewrbG47TApqzDFP++h
CtZzVpwJBjymskcs69EbR34sm7Ma09iwRUwLJ7JttKKF6ajtaEU9/HkF7pwj92F9LX+KzyJGYKzt
Fit3rccK+9frugVL/6vVeTq258/rOlOj065Z+yfLvCBeJi+dN4CXzIv/C7t/cb8gjO6WTv5Tzjyo
JUxsP9XcojXZmPN+V4j9QJzjZzyHwLS/eA+SAubJXQGEw+H8VCD7Dd9+4Pq0IPUKMs9j78L84kYv
vBsRVSZbDebFZ98hhYNo8MsfPpRmvpaJ/bzcDezOl4z3mFvnC/XIQbivBJBVteVVIGdZzdohXNZI
di/kDClc1wjmeRJ41ENUC7WQWoQhEv6AyxilJWg2JAKCWsxasbmsuexpmHdvXd8hpRlnbNKMEYh7
zB80/zcZISRbmzRDUDWIJIg4qVEs4EfLKTKID0aTQBItIHhEUxJJ8FoLjCOMMR6a4PWhjcGQxh7D
cfFgpkAVdhczafoxh1HnYYyn3ifRnnl9xm/J3sceDbpwJcEuMYV819rk18PYxFMam8jLrRRJkKQ3
bhgXpqUt8Dna71L591+mG2XumjI7OKM1LtoYJaCKeFJVt8xa6/Q65rmYjiyPouNSUpJueraNjQs1
BjsT+97yqTdOZ9Qy8ZQqoDM+v7bWRg9osFXU1lXaphtD/WUpSca4OKMxyYgY7S+LN8bFJ8S5gv+F
GjUR3TzdQvCBaiK8AfUSsokg4Dlyz37r2T4Xh2ki162edq/x2/XPLQ4f9/v1R4Zs2H79ifV0vxkj
1j+2fmlZ/OSjGebpP2yacrDw+MXvHp8fvHTd3Alb35p8/3j9JyFpJ72J5edWvbmv54S1aysiHj2S
GrPP65XiiP0530j6Ja+KeS4yZeP3gx/M+Gqu9661VUWmTU0znirrOXXI+Ue3mfuszQuOE4Wp1z33
zbLogLN915Sry4r5lnUhSfnNvz3740rybc2H+4qytz7UuC/1+8KVw1669uz91bZhmwMOrxJH6mDU
w2WVSbtylcK0kY4xV/42QSJ65tickaN+fLXPvX5zpvKOX9r7UuMj1+3vzf7k2aC6sWmHdl8Qbehm
3CqYd3ArPVU170uSwoG/Yc5G45ynjXPWozdDCN6ctcY5qxsVY45Yf6yse1I/Ypb65aFLHO8+Vfef
77+m24xxiunDR85J2xb/vDqgd/sOIuzvU31+HlsWv+5J6bv9+MsWLD2YelZ38cKoFTGvtA48MP7H
q58e7tNn9HOJhZXXw6r7Hzz8/En+jBNxi/uuU1gn7bquHB5Q2Xb1SOZXPqPp4d+Of2Dz84EHopPC
e+61PKVsCfcu3/BbYfAfuoOf+P6cv6kmM154rcn/968nVslGXNrzU/47e75503iVjhMvCHkkKmjo
xyHk0z81nqK2jflly4kDo36wDH4nv/DVbVSk0vHwJxdES2ftWP3WC0kxZ+4/s3HqV1Na4cik/vuP
JbacGqDc2HuSZtLnvU9/FMw7szGbd2B0QnLN0GDZ+O2S9Ys+/Liwf857wUXPWD9XpjavaFj37LFW
XBXKjE3UEOeqIIl9weeLPMfYJ95t61hTQv5biwHO++R4BK4A8bgYxMVjsHfHYjCdXUHRiEBFFhXE
qYw+TECkkowy1VfgPtGGxSiMckYpVAnzLebq2hpzR8Ukf1UxvVHnrFiQZ7zZQhdUTqxhdp95mQNu
uypsnz7zk9Kt2Skbe22KO/5HeO/BU9uuaJ98J/u+H4/mnPto0RuTh+SP/+VR8o2hfx9cZQjrZ9n3
vn67dND22Q0nsvc8v1Se91Z49MXWb2R67dEBYZfHP/pBYPbTK+7RPvreVkO3N+7pOaP2M9/QPotS
FCkn9kT9MqFPTyLecb37oGdeqSKaH7/y2svls5v+GNs6Z+68JfaLO1Zu+CD5mbx5/t2bh50wXoK+
v7z9R985e+e3V6U8G9vr0rbYzZKZ45dNm/D4mnrZ/M0X3/yZ3jlcubj83ZjP4rMDf9h1z6o+eQUB
708YMf35F5sPjOy3rilvQQ1/S+/9D4TtyZ/Q99Fhh6NnJdTMHSg4+uSRe+aTNfPhb23NXxa4VoXL
xjm/GVXMohDO8zJKBCK8ofH5Qor631gqvJk6qgjCweMbKbwYQxiFnOfHUx8OeX8KWMds/un4m8PW
jsiK3ZBVfsEoZaK9ecwn7ud7TB12jXnghZdm3RNx8f3dw2zri7vbejRsnX/thSErp8HQ84e+C/ii
8i35+hk/k5lvH2o+/HvB4dfX7RlZe6E867ks+GHVgbUfB++QrguUrfz0eOiLUTN/bH+mftPSkylL
+q6ZtDu5+tiCzfprX57/pFK8bMGe66dhV6+ff5vxh0IZy/8uatWKjMmR921PXnpKKDtYWvHensYB
kyds3LV915Jehy5Sihn3/3rsVMaXD1w/fXrT9Utffizbav1k+VfDX01eP6PnR30/7yUdn0SumzNJ
/9ClseVL7aN3pXxatqhoblDCr33WtDZ5rR+3cGvM9qeefveF4/Sr+4yB82i1rMfu/F8GnLrX+NXy
yMrm/dZ//PzsC+83ZtRNkeMaMwnXmHzXGmPynjbU+dDoOY/4uM78F2d1x4KTYDTiipOAC44xxRjP
BBOYoNF2V6rmiqf+Iv62a836zyWLP3h9/+DH3ns+tdeL+pLJn1ft1XXbvvLAty/te/vjiNfjfRbu
Pl4acyVxZKhv9EtLZSfUG2oih8z26z9g0+L0LTkLZJ/NWfniasGRUVlTxn7701X5/1Vv5vFQbn8c
N4xlbNmyG8aWasoMI8YyiLFnMJKK7IrsJmSfGaNkTZI0hBZ1M5Fki2u9tixNN9lKlutmCVmSpfgN
VzeV+7u/1+u39Pr9+T3Pc87zPOd8v+9zvp/znKEI3A3FJ7iR6WGH7HCGEvRaJ4qns6DlBMfTkNkS
Xo6P9u5ypDNxJZQK0qhAUdLP7/mLHW0nuV+rTkGOx+ZH+tehhy/HBNpfe0MJrFGOV+ST5+1zbL4v
fBeTdpLyXAIJ8x2IP6k31CA6z2GG05YfZZR2h5w2LEiuL0Q2HrzlaSNodC+xK4GICmLV775ZGCVV
NzQb4vrACFcpq21MduCzN4U1EeaesvmETh0+FPiM5XAAfpM1izD8+42+F9uxHrG0IGSq3hKwcxCt
hFDzRUvjtBGBLncignG/7Oj2aFrnhJgUUBDGH7l9mOuu3yAO1ICpwZBZyllK0YqbUqCTn8c3UqDP
abf1UvlNAdVfXgdLc7T9tCKYwedH0tYh6jBVmMpnG0YfDf1LbXGjQRe/LS3hvgmgDdpoHfHGnsyU
ICIAnL8LGKtTJrrxEVMcZ3GBmCv6gnN0O93C+xyTcj6dzCb/Jrd7+XDX1VWzqhOgh2W3JwlzaWDv
o8vvZwbZf41lQfELSFCrH6H1WWTtj4CMU96xtJYf8no3ZMAjpxQL8XttV5zvxiOdMjWGAPWFe3kn
s1q07DEx/EkBGj2a3WorW1GhPnC8kMhWriSKiULrrz1OyT7KfDf1VVDlkYhbuaatsxRyuvbQExtp
1MsIhL7pQkdTSMZEcTPZiQ+bT0mf7qrqyMq+d7kleO85aHVjz0cPht4qFcoM1UZIYEf1h5bI21ws
wq+SpN4UZJugxgu4ZYM4a6BlN083JqrTaJNBow3pM20MQyf/2AD7cbSxdPN08cc5ePpspc0BGBJ+
AAZXUlLYWN7AN0wF2LoJw9/+r7zbLpjMHxMl2EvHzWdd7NbFoiXQWFNVOExXZZ+SCkJ5n85BPZXP
NzLwgv/iI7Aufuvy+N8Caryc0amp5+z9KF3UrYf1kyaZ0q+RAWDQCwUj66Bne3tuMSdNv9FYqZQN
vbEyEhau0NGjEYtUnl3sVkPwP08mrCDeniL5CScOlJoMlJLmFFnpa3IC/JVMbGdKBo3CxEpTgvrW
wKSdB/V82yN2HeGhEjFqHcv9C7GTmnTDnf0OSwLxxjfx6u/dtMYHY6qYMeW4kDH2Ef3xex4znSfx
LIv8LWG8j/2HQCbLjiuTWch01dUJ7iYHsKN1N6slsVPN2HjocKW8vXBCMqNOr+0EgVXqCiiLEe4S
e8kUrA3JSU76hNZFeys9QCtT3O66LCF0HgjUqiEHueJmhc8NW5qJq2XAKVsB9QVI4X7v9mta7R6Q
+XCqFPDReDC8Yxj1FXu8R001r5Qh7hlHJ1aQx/PUtHUanv5b7MH5+zg5/EfY87kl3HYEZfmOwtsA
yi2YAGLnp/Z36MXsr6IigvERu+S098z9CknmvEKxw57YvTRZY2l0J+wD71M2vqVDs9E76byGiWJy
6FwoUuGVd7rysSkpi0RLhnjNXLKzysKBJj6dYlVUWjNHnS9ebs41Fz5kY5u4ZGExaDNxKSnDDWQS
Q6UGmCA43AdDdXP3HidaRqClhWTqL+j9IjMsFOm2m29BoOGdJBSvd2Lv/NLthkCUlPfSbWdSQo4j
x9194DsjSaiItYKEj1feznwC5rcZth/D5S3P8YqLINtvFL2omC+aaqLMWoFX1GeaXuzRragia4a5
CrYVSjixtmhpuCgIhRaWatTIGphKCl31ioPVzFz8GlBc7mxXMdV0Mve4+9Di1sEnc77F1I9Jvjbp
BEMglNfphKSZPyD5+g6cf8ebl8peK/lNB418BZvaDVDY6uV7fOVQhcc8GIsm4iRKsccQnixXfNF5
QNwsqrzWmBrBuDh95ufYxjud9918XIN2uY4Wl0yTytqmfvrEc5PtqORu+Q6tHiugSMAjT2dPI8u+
VzP9VdeJjZGvI0zolVPeV2eyWIFP6bf1VAfYyIcVywCLrI67izqtRYaqT3UCZQ4hA3HMtrU23dHK
0DPNnONgJCg0YDXDwyt44C0q8UqmL6fdHoygo71C5jOi6V5Jm1Po2H75KC6zwqVHwvEeUzLXeBef
cHWROOcJAf4HGi4H57TaM71lLIhWLFlMOR6lHWVNSvEqEIcatHqTdQbcRyNkE07/wRsCQI7WI9Lb
R+j/RfrFxQTaFEB3AjZOMW+h57ZwFPqzAh89kB3MSoelO0PnSKdDp/11avZdXrcNoFIOccNrQ80e
cydkOzADOON80PHT/paVmiDGfWul5liS6CTyYskNK7b+uGI1EepKXm5zyQNziIg3i1v4aYYcSb1J
jyLPUMlSvV+j5uJ3/Mx84UDNRPiYjy36evKz1vZXCdWDVXvaQt8231foPFf2xKn+AFUQUhXQr5b+
UMQ/E3K+u6iIxzJunlzrYpQuJ0u2v7BDrZHXJcjgcQeFqIopcLTuh42NIcWGY2Z7kfglXkicc6QT
EzB1Np1eRz5E73z5Gn2Py5JRfy8D7tJDRi/21oyXcg6hBjMCZG6ICr3ouTymX1IVSke0GrAalXdj
+kddlePnJVPJrQWBluaqL/x0C6UW4ATgDRqkrtMDADD8uR+YlX2VK37RuLPw7TC+P8dbDgBnZmDc
OLS/7gWbgwligLNvldVpb/PFYoNzwrZe3QmT+lIRCKf52EIJZmcpcHmafOP34CCimVQHzjwSZr2l
CjvcCGaQta7M/5MN3WzZSOl/4VcBiW+QBiQA6DLLlvtkyPpzcfWefg/q0YdrjzWIQM1V6Z5XB3S1
WRmSZJRPHz1jyLsU5aHhdov1vGLyKYPphXymzv2aMmNKZ2u5OisB/uHVT4VaJkpq+BymTOmPcVwY
m9cST8u/XpdRVFXFFQbPaqlP521n840Nql090sXKihWQpnpYTRkkHkGp72o00sBin0Mj1IINMbud
cyQCh6+N6EOApPiusFfSa5msbakHVXxn7C/Ig5o+WYtj0dhOltWQ5TVB7VF8yOXZshVuzuTGTEZb
AIVgP+LiIgZNIZsnVpiCLISlLg5LZ7pMp/kS3X4zmSpsNLd8s5SxavdsjR1Qh39LhdjBh/h4DYqy
CfTiMAK9yJdxYYIT6NlpRSz/c7f8dhb6Kqlg3nTLLFuY4FbvY/uy8wOgPfPPK4zwHbTpVQUOU1yf
TJEKSse+c76AEz15ZxmDKsCr1uBLTqZ5omT5gm84te4iTDJ93lqKGIIUSkLx2nC63lUGDP7J2tlb
551z26hsupdEX6ri69QCS7NuZqQVNDMM/Q5ywAzXtZY6mIsJ3IU+11K5ELqPvIKAHk9IeU3U7XrC
bwwMHjBSss4sVbofO2b3iVoblxSclhj/wgNNcphAcz/q7pXINrTb507p5YMzkWtYHzSkNonrOEBZ
vahNhxYspCILmsGPTzWnoNbC+3MLGSUd++8n9Nq+Cb1KJxKDA5j47IjBDULwAaZrkYiqYzx5SukH
PT4w77UhVEbHj6cBW+sVu/q9HlKFS8h3TEYmAKzh4b6HuUeUplILnkqZlmSSOrJnOLRue96cxr9/
3elqJ0L3Dw8XazsNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5NDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0
ZURlY29kZS9MZW5ndGggMjI1Pj4NCnN0cmVhbQ0KeJxdkMFqwzAMhu9+Ch27Q3G6Uw8hsLUb5LB1
NNsDOLaSGRbZKM4hbz/ZDR1MYIP8/5/4LX1qzy35BPqDg+0wweDJMc5hYYvQ4+hJHSpw3qatK7ed
TFRa4G6dE04tDUHVNeiriHPiFXZPLvT4oPSFHbKnEXZfp076bonxByekBJVqGnA4yKA3E9/NhKAL
tm+d6D6te2H+HJ9rRHgs/eEWxgaHczQW2dCIqq6kGqhfpRqF5P7pG9UP9ttwdj+/ZHd1Phb39p65
/L17KLswS56ygxIkR/CE9zXFEDOVzy8cpG9rDQplbmRzdHJlYW0NCmVuZG9iag0KOTQzIDAgb2Jq
DQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzMTUzL0xlbmd0aDEgMjgyODg+Pg0Kc3Ry
ZWFtDQp4nNx8CXyTRfr/M++bq/d9QDjeNLQUeiRt6QUFCj04yl2OFlGaJm+b2DSJSdpSDxYQAQuu
7Iq6sKvgjSgawAPwRlHU9Vp1F0TFA491xcVdkfWg+T0z75s2pRQDH3/7/33+8zLfmXfmmWeea+ad
N00AAgDxCAoQKmunTZn4zl/iAWozAbR1M+bXTlXw3KcAykqk+nx2rSE/7/XjZgCyHe8XLqycWdf6
attCAFU20nxkbjW5GrL+WQ2g8yLNYnO7V3jIcP/9AKNXY//YJldz6wvfjfMBpL2JEy5tNnlcGj2E
43yJyC+x2d7Z9OqMK+IADM8izxesltZlj3ZfvRggMhIgyWoVTZYj5KUvkTfOB0W0IT4h3I73Frwf
YW31Lpu4S/EMAIe3fKXdaTYZp+Q+j6Q4P3mx1bTMxesVp7C+DgkEh6lVXFC/9HWAkhkAg+9zOT1e
/zhAXvO+o/0ut+ia/dLIpQAjjchvPlBbKVG68I9sS2PKTmm0GqDpnp03ddPyucl/twJ0zwk/ps7D
20hGTxOW6rzuOQARGwD8b4Qf6+kJpGdZyydwKWhAjeJzEAsGKMWhXyuWYh9e6mFkI86uUbyuQIn5
5EAJFl6IpGINkGbWCgKUnxROHlZlkbshT51HfCt6ehUA7EYl32smwPSwTNg0ILv/Y0nzKez8b82l
/t1/b67/K0mt+/9PZ9UlsJPmX5HlJ4TgEj17VZ8nnYf0Arj8SoNDF5wqSVWNhP9o/HSv8ndDGGgQ
wyHMfwYiIBzrkRCB9SiIRIxmGANRiLEQjRgHMf6fIR5iERMgDjER4hGTIAExGRL9P0EKJCGmMhwE
yYiDIQVRC6n+H2EIDEIcCoMRh4EWcTgM8f8AAgxF1DFMg2GIehiOOAIE/38gHXSIGZCGOBL0iJkw
AnEUpPtPw2iGWZCBmA0jEXMgEzEXRvm/x714NKIRshDzIBsxH3L8p6CA4RjIRSwEA2IRGBGLIc//
HZRAPmIpFCCOhTGI46AQsQyK/P+G8QwnQDHiRChBLIdS/79gEoxFnAzjECugDLESxiNWwQT/t1DN
cApMRJwK5YjTYBLidJjsPwk1UIE4AyoRZ0I14iyGsxH/CXNgCuJcmIo4D6Yh1sJ0/zcwH2oQF8AM
xIUwE3ERzEKsQzwB9TAbcTHMQbwE5iIugXmIl0Kt/2u4DOYjLoUFiA2wENHEsBEW+f8BZqhDtEA9
ogiLEZvgEv9X0AxLEK1wKaINLkO8HJYitiD+HezQgNgKJkQHNCI6wYzoAov/S7gCREQ3NCF6oBnR
y7ANrP4voB1siB1wOeIyaEHsBLv/c7gSWhGvAgfi1eBEvIbhcnD5P4PfwBWIK8CNuBI8iKvAi3gt
tPmPw2poR7wOOhDXMFwLyxDXQaf/U7gerkTsgqsQ18PViBvgGv8ncAMsR/wt/AbxRliBuJHh72Cl
/2P4PaxCvAmuRdwE1yHezPAWWOP/CG6FtYh/gHWImxlugesR/whd/mPwJ1iPeBtsQLwdbkDcCr/1
fwjb4EbEO2Aj4p0M74LfId4Nv/d/APfATYj3wibE++BmxO1wC+L9cKv/fdgBf0B8gOGDsBlxJ/wJ
8SHEo/Aw3Ibog9sRd8FWxN2wzf8e7IE7EB+BOxEfhbsQH4O7ER+He/xHYC/DfXAv4n64D/EJ2I74
JNzvPwxPwQ7Ep+EBxGfgQcRnYaf/b/AcPIR4gOHz8DDiC+BDPAi7/H+FF2E34kuwB/EQPIL4MjyK
+Ao85n8XXmX4Z3gc8TXYi/g67EN8A/b734E34QnEt+BJxL/AU4hvw9P+t+EdeAbxXYZ/hWcRUQrE
w3DA/xc4As8jvgcvIB6FFxHfZ/gBvOR/Cz6EQ4jHGH4ELyN+DK8gfgKv+t+ET+HPiMfhNcTP4HXE
z+EN/xvwBbyJ+CW8hfh3hl/BXxD/AW/7X4ev4R3EE/Au4jfwV8R/wt8QT8Jh/2vwLRxB/Be8h/hv
ht/BUcRT8L7/z/A9fIB4Gj5E/A8cQ/wBPvK/Cj/Cx4g/wSeIP8OniGcYdsNx/yvgh88QAXdcgOMR
USrc2iOiQn+ARA7cFR46l19pcFhYCESR0Sp8cEVGh872POaICJ3LrzQ4PBTLRMWo0YJRMaGzPY85
zuPiX04XNTgkHWPiMFIRQ2d7HtILiIb+6QKWS2+KDMUysfEatGBsfOhsz0N6AdHQP12UgaJCsUxc
QhhaMD4hdLbnIY0NnUv/dFEGig7FMgnJ4WjBxOTQ2SYN3HUB0dA/XcBy6U0xoVgmKTUCzZ+cGjrb
lIG7EkPn0j9dQCj1prhQLJOqjUTzD9KGzvY8pOdR/5fTeeJj4JQQimW0wzFSYcjw0NkOG7hrcOhc
+qcLCKXelBSKZYbqYvB1c5gudLbCwF0XEA3900UZKCWU0BHSY9GCuvTQ2Y4YuOs8Lv7lNPRiBg0a
FAKRLiMOBkFaRuhsz2OOC4j4/umidBwcivfTRyfAEMgYHTrbUQN36UPn0j9dwHLpTUNDscxoYxKu
sCxj6GwNA3dlhs6lf7qA5dKbdKFYJrcwBc1vKAydbcHAXdmhc+mfzhMfA6f0UCyTXzoIMmBMaehs
SwbuOo+LfznlXMygzFBCp2iCFi1YMiF0tmUDd53Hxb+cjBczKCsrBKKxk4diiJVNDp1t+cBdxaFz
6Z/GXMyg3NwQiCpmpkE+VM0Mne30gbsmhs6lfzpPfAycCkPZSGoWZuAKm7kwdLa1A3dNCZ1L/1Rx
MYPKQrFM7dLRMAEWLg2d7ZKBu2aHzqV/Ok98DJwmh7LIlthyoQqW2kJn2zRw16LQufRP8y5m0LRp
IRBZ3PlQA83u0Nk6B+66gGjon+ovZtDsEEOHk/9Qlwg8LQgeAYkKgr8w0P9PefReMfDf+fsl47mb
a/rcrQud38Wnp54OlVLBHiGRoEELKU6mnZx50nLSffKw3w9wUiff/c3vj/kUry9ik2M+P9tK5cUl
xWMK8vOMhtyc7KzRozJHZqSP0KfphOHDhg7RDh6UmpKclJgQHxcbEx0VGREeplGrlAqeI5Bdpa9u
EHwZDT5Fhn7q1Bx6rzdhgymoocEnYFN1Xxqf0MDIhL6U5UjZdBZluURZ3kNJYoUyKMvJFqr0gu+1
Sr2wlyyeW4f1Gyr19YLvBKvPZHVFBruJwhudDkcIVanWSsFHGoQqX3W7tauqoRL57YoIr9BXiOE5
2bArPAKrEVjzVetdu0j1BMIqXHXV2F0caKJQKt90fWWVb5q+korg49OrTBbfnLl1VZVana4+J9tH
Ksz6Rh/oJ/tishgJVLBpfKoKn5pNI9ioOrBe2JX9bNeGvbHQ2JAVadFbTEvqfLypns4Rl+Wboq/0
TbnyeGpO9l5y7/w6X1jFXgLz6/bBdP+KXdNWVFbW09niK+rWMvIUJE+58riW76pKtQn0tqtrreDb
NrcuuFdHsb4emeZk18yr06HU+qoNAlVjXh3TAJmSVAMKSduompLCor6KtjRcLvjC9JP11q7LG9BZ
g7t8MK9Tt3vw9PJ9/o9gepXQNb9Or/NN1OrrTZVDdiVC17zOPdPKhWl9e3Kyd8XGSZbeFR0jVyKj
gitiTx+rMXJaQ6kDpiZUIv00DBGfYBZQkjq9j0svoSCWQJe5BMkw1RO0qA3t19AVO5Y6Qpkeqxe6
TgEGgv7E131bTHKLKj32FNAqDZeekMP+QN2XleUbPZpGiroCXYuSTWD3hTnZ7b4avStW8NWgyWBO
HQ6qH2tAk+t01Mvr95ZDI974Vsytk+4FaNTuhnJDVr2Pa6A9zwZ6khbQnhWBnp7hDXoM50fYQk7y
aTJ6/sXEJidUWcf6SPJ5ukWpH5dPlbBLoUzvmlOXYepar81o6NpQj66pxqXY1VWtF6q7GrpMe/0r
GvVCrL5rV01Nl6uqIaDSXv+z67W+8g31VoJG9RVI1vAlVNTxWq5eqnFavj4HyiOhuhpFiY/TlE8V
9nJFu6fmY3EtK8iDUvGAVNwvFdul4j6puEsq7pCKrVIxTSqmSsUUqZgsFeVSMUEqyqSiVCpUUqGQ
Cl4qSPlsLN/HfBTze5j/ivl5zI9hfhTzw5h3Yn4Q83bM92Heivl2zLdh3oD5WsxmzEsZz4cl1jul
YodU3CsV90jF3VJxu1RUSsUkqRgvFSVSoZYKpVRwUgHl5Vgewfwu5kOYX8L8IuaDmB/H/AjmPZgf
wrwN8+8xd2K2TM1PDEsMK964l7SXT1NvvEO98Sb1xhvUG53qjXb1xib1RlG9cYl642L1xnr1xjr1
CE2aRtAM0wzRDNakapI1iZp4TawmWhOpCddoNCqNQsNp8AHkS+BruJrayaTG96wZahoF3/e1+r0k
fO5in1I/mfjia6Bm/uRUX0mWj1vHdrO9xL+LkN9ep6Ub2T4gxH/dDVq5rK+H5Kz+KbXPXc2czidh
OCkGNWLBHvXwF9S0tRZbN7LWjbR1I2tNJbvnQH6NaX3DUDgH495Eztvbh7LKRtWdU7dLA5PrK5ZI
5R4uIhz1adDq6icnx7omMOXG6VKXa/cr6BdBI3A9R+IDIgoz7cqZlDOJdimAdUXTZ4fclbp8nE67
n2yXu2KxOQ5N+esdNH6l9NaAPXl4mUkdt5JbjLU/QiPiFswWzJthE2zi9kg0+E5vBh/WpsMXykP4
iulm7QVwNWIl/AcNt4a1lEEj9jci9UEsJ2CfGUvCeGwiG1h5DaxG3t9ye7gD3AHWOxH5TqcU0sXt
UR7CdsrvWngIPiT0+6RXwU3Ytw/eoqOQ8ybYCadJJl7ryWfkBDcHWwmdH/m0IPUmlPdpOAL/Jolk
AukiTyJNPLeSySLNtgJpDuL1FuNCr5nETpzETa5Hnsc5nitErk5uHbeN83EH+HrFBOUhVbyqWG1n
32Hl8LQbhxpSbrPwJbMRryt6uErXm4Qjc8l8YiW3kG0ow0FyAq/vuBxuIlqdXjfzDYpIxZfKFuWd
eB1SLVDfplEhbyWoYDAIkA5jUKsqnGMuymyBy+FKdl2F19Voy1WwFbbBHXA/7IL98BydE47Ch3Aa
rRODF9WrmJSSRXjV4+Umy8lqtMf6oOsG8ieyh+xH+V4l73LDUWvpsqP2kpTXclu4R7hXuT9zx7jj
3FfctzzwYfxSvpH38PfwO/g3+DcUUxXbFHco3le8ryRKH7NUvCpRdalqPV4b1GHqFvVq9e/Ut6kf
C8+FFNQrG/Wajm9uZuhETa7Gw3sX89ouvB6BR/E6BF9RPfDyy5rQq5RUkmqyAK96shhPAK3EQ5b1
aHQ3uZdsJ4+gLu/idZgcJR+Tf5Bv2HWaU3HJXFaPfnO4Wm4R18Ldwm3m/sQ9gBG5h3uSO8x9iDoe
506hjhF8PJ/ED+Or+Gq85vOX8Mv4a/md/AH+KH8C/RapGK+YoFiguBR1f1FxXPElepJT8sp0ZaFy
LF5WpUO5XLleeTtG9AnlCVUks0q8KkE1TrVWtVW1R3VEdUadpE5Wp+GVq85T16rt6nb1DvVx9Rea
B8MmhdnC3OHZsAPffx4/a/U+Sr/Lw12qMsBgchSj4Qo+BqkEuva4SLU9zMbtodKpa0kmeuoDOM2H
QY3iRVjEXwJ2ZSMfof4athOPYiV5gK+GB+EedTt5km/gT/D3KNNV4yR7clv4HepOdYP6C5T0O/4m
pVWdSyYp15Pt3ERc0W4yF74np+AynNnLjYYX4XpYR9rxgbNJ8yCJwrV2kBtO1ivv5HcrtvFVyuVk
FHpQqzzEXweFkITvRpmQhrGuxHdH+jLI0e9v8ytw9fP4gNCXx6jfIYp3yF34LuUHpZ/fRz4DMHSf
iD0BE79BzDMWxOni0nVxuhU8nFnBQTcoD/1YskJxiH4JfLr/qPo75QnkHIH8B4MexsHd5ZkKlSYs
Ij4xdbBOH8FFxyWN40tTtGP4fKUwIj0jR5UF+asiSak1ei9XuDsri9tLrivPBi5okGJYRpIhlkSO
SB8zTlUEgjbTOywnLtZbpEzxGm4ctpcbs7uoSLGPCCjriVLDmTMnSmNPlLIcF5+CWSqlTmw8wVpT
SllfSmmeMYWQ5ATMKekZI0lRQX6SmmAlOYkhvvKx25T0osIxGfo0dd9iOpmuXPp10o+38a23phOi
/+NPcXERmYQfrxPO6HL5STHaM6qE+Ci+LDL6p5hSUlwZFT10SllScsqUiZFROQXp5CdFypTuH3/6
u6JlzkPP7634ebIiI5y7alD0mZIII7dcN/iMQOJio7VcZ5bw8ydTl5QNjYzQl2YkJKQVjYqIGEnt
vglAswl9mIJPiLEwBebDErizPLpkQiGpX1BUMpafNSZ1AVr38VrgBg2doKzfyxXv0RrWTMMTaLkw
a83oijXh2trwFaNh0aChYwrHLkIjXzKSjMhP5eZGX4JnyfLE/IRl0cvKRywbeePcanXNsvK5+XzR
PqKDHMOJlFI0qeHECfZPsjX7l1JqgInMDbFnvj9B6dD+pbI/DIY8I1GPzBg5MqNwDFqcvlir1aqk
xJTkFJ66IIWo6H1SSkqyWqVPQ6pian9lMcE7dEZyQT6zPw4hdBzeY7c+LT2fYlIi77uhJrHtzX90
Lrzq0iUKwrkTE6YoLh86uGvtT7NLkpIXcrx6y5YdCx0PkPFWUrGFf/sqV86YH7V5k0fN2VRfOJPM
+sxWXr66e2IGEfPyjHzzwpyygkua/zDXVVvr0BhSkiOmjgmP6D7NPacoPjNFp9EItWGD8tatWLmo
YlHLi5PGqPKWnHk9X6OA1OGueV3TCxb8/PWNk/MyM19vmfoPAyZcsTv9RzWbcbVkQhbk4sodA8Xo
vfFwW3mOdtTobKPCEA+R0dqRWbl5+QVjItJTCotKSseVqVQkonjseKWwKiV9VXx8ioGul2GqiKEG
I6UrKi4pHRtRmDNqdNa4svGqbD4iOozfT2bjQTK/PGLkjdG5Q7O9OTnRhfu4BRBmYK7DfOa748xt
0opA+aQe6rW4lN52dFqSIi4R9GlQGJteWFQsOY96o5ium0TqnJHolqRkUpyQUMCTFKJMURJ1eoKa
50cm8HbS1P3y+0e7XyZN+dPXmK7dV/hs56jxYTG5rdU3f1B6Z92qSVxC5vdlBalk6qjuL0mNpvs9
Upfa/XCBcfphw30K67rfd299v/sVUoTNt60bHJnUfMPW3HsEZfrIsv3GdfdGkxm67idJZfdRkj68
+z2VQdv9zaiPu/fHkSHd18QRL93xdsIm1XG24w2Hyx9VxCclK9STwsntuJC0iFFoKVqP4pTlYZDI
x6pwdYXvJ6UwjIzbrYyPnRSB9VQyDpKIiEyUFDkz3Xow0L/DrQeztASoEXHTpEbMMxYX6pJIkq5Q
h6EMBfmA8a7D26JAFO9UFf884cx6sm8ZGXTgABm0jOw9s/6OA9eteW7Tpk1cddemqzY/TeK7v3l6
81WbuqwPr37mmdUPM21A1ca0CYNx5eEaPCWtglUKJW6j08ujVCsUqAp/I3ejIgzoK6LmToWBbY9n
4kphIqvRNZtnTI/TJajjinVxauXMnw4Q80Elf9CsGP/TgUas/HjmoGQ5UD7M5lLBwt1KlWovt6Y8
iuMTOZWC41UKlVJBW1IJl0gIpyC8Atvps+RGjleqFLCP4HnQ8DluGDDxcxZNa5W5WZprYl9Yq8lN
zVJiRRfG6XRE+fCP3Uque/6ZSO4Jchk9HZwZwl3m9/dIMAWeUi2hP3wqp0/mDPn6hDz1v3FxnRd1
ffT/6uKT/2vXIjyR/ioXO2GlkwM9n8jmQ+AzbIKRXSTXOVArv5TrPGiVH8p1RRCNEiKVP8h1FcSp
lHJdDStUyXJdA4mqW+R6uPJBnE2qR0C+aodcjyIzVe/TT9gV9P0gUjOK1env62I1haxOvyps0VTJ
dQLxml1ynYPoxCS5zkNRIpHriiAaJaQmFst1FaQlzpbragKJV8h1DWQmBerhEXWa++V6BFiSNsv1
KG5L0hlWD6dypt7K6hFUztR7WD0yqD2WyibXE7Aen/ooqycG0WjZ2JdYfWhQ+wg29m+0rknubY+U
571fyDcai4SZNrPb6XE2eYUKp9vldJu8NqcjV5hktwvzbM1Wr0eYJ3pEd7toyZ1vFYVFNkezBbNH
aHI6sLNDdIuCRfTYmh2iRWjsFGrcNo8w1WlvFT2CyWERKqwmtx3rk23Not3ZIdgcQl5pqZH1YSUv
V4gKjwqnrIMYOt22ZpvDZLd3sh9uWoQZbWabxSRMMzsdnmxhktvt7MCS8qj1mtwewesUzM5Wl11s
FR1ewYvc5BFecZmXcRaaTK025Ici0m4Psg3I7fbkopJsomzBLTrdzSaH7Up6Qydwi3bR5EEZJMnz
BZMnyGg99shmbL1WtxjQxOV2ttssomAS0AStTofN2eZBAXqM5RG9grNJsFGdcBaXG+3s8CIvxgnV
wTFMK6dDpPyQ1oWyOtEurLnNK7oFT6fHK7ZKpqbDRMkEjLrZbXJZbWYkb0MPovw4oMlkFj09NkdT
mzBLIjQ53cKcimyBiup1urOFFrGz0WlyW2gTckAN3SZzSyO6JZuqZBEsbls7NltsnhbR66UEJhdK
bvJ4pFuXm82ZjbZfli2IXnNuNrVeh4jBhWXvtE02O7Wa3YL6IT+nuY0pgRObbHYJG53LRGzosDks
zPdmu80lS0d17zChHRpNVJBcYZpDMFksNhrJ2UERa3OY7W1ofnniDpvXKjQ6EVAviRpNRZn1Whc9
ZWtCEzrMqI6nzWxl8rttkpucTrtkeSuCh8aOic4kNNupCWQhXbTFY7Z5PE6qXKNIzdfobG3Ebqto
bhFkzYIM0+pEpwQLZWs1NaPcPQKIJvS1JB6b1o7LBV2E0dDaiDJRZl630+5sZt6XyUSH2eY22zHy
HGhet4nRYRTaRTOdhkaMqZVGGFWGqcW853Y2mlh8u+w4A1Lj6sDVhGsZSRkZ1ttw1VsDgTXHaZPi
WOJhQSGkW9SqyS1e0UbXaFObg01L3RIUqb1BivZ20r6AJ+kaN6HTcEX1kdkVmE12gvccuxTq6kTa
JrSZie0dlLEZ5Wlqs9PJLSZJFGTXIdJdj4lusdERVFiLzS3K0tIOj7fTTpWtxtBtN7ltordT0rXV
ZTJ7qYca2+x20Ss5QkTbtMi7ldNNtxkW2ouoZaiIvcJhXeLXszk0i85W0eu2mQXJd9QqV7Sh4NQf
TntnM9sPcQtslmZjwuGGmNtrgXlic5vd5B4rzKwdy7b8hTgRtV1hrtHYQ5YjkwWtFnS2jYWZCSOs
2UYVQcFoWIqtJncL6oI9QbdN536WUFNTnyzAXUVk+7VXejQYkIGTTWB2tjlQSWrSXhbzO11OFhed
Vq/XNdZg6OjoyG0NdOfiGjV43W1oepdoYF42dARkN9Q723DT6KT7Hs5tk8KA+gXDu9Xm9UqPKipV
1YIZk9gWRG9wx7a0oQNR4g4MR2vQWFvP9mGhgYhbnstukrzOdjnUASPXgZuPEJjc6cDdPtM2ShBb
G+moXl6OAPU5RWLkbB9BN1PfB5aJPD2zp8xrHJMg04az4GOAmtxNH3K4RTrsTlPwpGz1yBuy0GN5
Z5sXdzp8JrXbzCKlsYp211kagQOc4KY/0QQ71IIXSwdYEN2I94OAxzEjXkVYmwk2MGO7EzyYm5BW
gAo22sXQhC02rDnwFVqAScjPjuU8bGsGK/Z52J2IpYjU7YgWpJyPfSL2LEI6B1Ja5JJSNzFu0sgO
NopSWhgPytXBeAjQCJ2INdhvY7RTcZwddRLZnaQRldXK9LLL7ZMZDxHvnchdYPMK+PJfipcxaJzU
kse0iqK/w8IckPrcEjqZJM2Mo4nZgcpH662yxDOgDW1pY5YWYBrWKR8PZDPLuZmVO+T7gBySd9xs
Li/2C2xUK1qfakQ5O5hPvLJsfefwYtsy1h+QmdaoRDZZPsmKgdEeWdqz7U3nz5U92asRlZPqTjVv
ZhLb4MqenoAGbmZtEe89sh2CbZ7PKD0DRFr/+MgOkpaWlPvZPnExLu3MCiLjL8hR0MqoaLy2IaVk
gf6RReX0Mo82MWkDfpJ0cTH0yJaX5OqVSfKONE+vr5yMd0A+ia9LtqtTjpde6jbmNzeTpBOzl3k6
OKoDs4l9oqCXdzNbmS6kotJL3NvkNSjZX5qBxoKZadM/zt2y7aQy2ApNzOMCzMHVRf0RsKqXtdOW
FhzTibHllPeUAJUkg+RDN5u7Bamk1ZLd4yUL8wpdTe0ytYWt8RbmF28PBxOzocA09MheC/S62PiA
ntly3C9jNUpnRo2ze2Kvg1nS3nN/Lm2b2JoJxJqdxY1bjkgL/Yk7atfrCUljExsTXKc2WcYsns3m
tTGP9q57M9LYUPq+tgv4vYPJR3VqZDXJIrlsN3EwOguzVWBPzh5gj6U1OlObHP19Ne5gHKxsd3DK
NclfwbxNsr0kyc4Vu9KasjHLmRmlWfaOh+1S1iD7u2XOgdXkZDYOjnmrXPP07DumHp1oxNt7oqCv
JV09NB62M3rYmgt4rlH2fLasbSuiNJquARqfwlk+O3fEtDKe4nksZWMx0Czbu78FRPYstZ5lvV5t
7fLTRVpF0t7QymSzB0nmZXsffbo1B639vtxE5gkbUppZRFvYc0qKXjcbEeAn7YV2ZomANoE9xsT8
La2BgGd6vdW79qg8jaw9sH+7WOR5evYv6dkhPZuk57IoP/EC3KT2NvlZb+23Y83BXluf/ThYDots
ieBet7ySaXkFchZ7JGhj1gloG1gt595Tz7WTSvHt7Bl39poMPMdN8kqzyE/egezs6qdb35XgDfEs
JfnVKfNtkuPMFHTuCEhslu1DbWHv0dwSdNbrfdJQXwXOer1Wt7BV3yQ/RSTLWljEiWfZNjCCRm6n
fEqjnq2Wd912JouN7XOdffxKo8/EuAXWUCOT185og1eEKMdNy1lnKzpD4DTTu2sv6omZgBXPZTmP
7MFe+fqfHJrZ2aiVtblZ1Ah91l0gVmj8meRTRbbscXo2aQ46H0qnwOY+uvVaziSf0M4VA/PYCmtj
+6MbxgI9adWyMnDKXyhrFIi7QuREe/pzyzmL27mfLdLKtgXtZiZ5D2tmvV45LixBu6XIdkc322+d
PWPO3dsEF/JeEojqwDpZIJ9VxKDztReC3xoMsgTOIA3MbP9xyJ4MROm5pJiPnnOx/TewX3Sy1eHF
+ljkbcA1Q69cdgrvOzpXfo4a2DxtctTTXdYQtJYN8rkh2O4GqGcSSicNulKks5akt63PbhBYL9Lu
3cqsEbBH3/eBKvrfCuG7Se8pKNAjnbEt7Cnm7bFxh7w7WgeY13aO04elZ0eUTnkuFlvBa733LCfI
pxSvvGKpD4R+mlMK6WyfieNGsWhsZU96y4ByOfrxDt1Kvdx7zyPSag6s+7OfJn21743PvnKNC7IB
1UTSRXobCES5u+dNTjpFOtiT0jSgpr3Pnr4nZOEcMe9kpznpTCe9J7UzbcQePlb21HL9go9mQe+n
DWLQnYmdaYI/f5BOvAGKj7HfwUaY2D5rAfq5hfSbCwB/Cf2/Hs+ZFOwXCEOAaJCa/vqA/RWLsL8r
YdbS/w9T/t8JtGXGVdoSVdjoNVPXnI4iam7bKu0obErnCMmLMIaplFnRPDdYCUaTKjxLRRRkVTFH
FNtqjXON2UEtQ+4ctmIIlLFrNkaDh+3hIrPCBHoZdUHMFIkLdnQ+/tmtm8kDmY8bdzT98fq0q45o
tq1KOmZcxb+AOWcbzxGOi53yzKCbj90wr7ri9NHWqVF5dxujekQlShRq5XomJL9AoUrgFk/KSzIm
0BtNQuQikX685xAqTC4xL9EYT5vVCRGVbe5Gk6PdZreLeTHIDVvDE1TzraYOr5g31KilDREJiVKD
UCG6vezTcvqBVd5w41DazScky93zba04i6mVfSBeMck4LCXKWJCXbxxjZGlxSlQevS3ILygsLSxd
bKwNEnZBbV6KMUmaP3qh6LbV2pod2cI0hzk3L8s4SpooLdDBpqKfNEpz1Ypu+vGWh066iqQFW4Uo
gV9FYgDbw7lVhMD9r+y++8+vCQ+HX3P9g2vbTj4y69tjz8U802x66i7LkPee+OGVggdWG6+vW77h
aMsHRbfHPPPW18v+1XHvcmfZMzc9HLXf+p190ytPzct5YOr4U4+9e+lSLbf1R0PLsLtP37Xl3sGH
uI9/M2Pep9ENX5cPWb4v6sOJLz1ybO1TS6+8PC+X37wyYfsU4fU8T9SinNeWjSm4OX5z/L4PrYYd
n396oGvD6OfX69Y2PXVt3SJn2zNlOzLWXvpKbFLZ1tVfzX8u3PFC98HpH+xTx92advXRCSPfGrbs
6615L3/7edqgoy/smVKxZfDSbcM2Hr/s1DdXf3vNA43kxlMzIz58M23h9ptfe2hd+0Pf7I/69/GZ
R7b9ZN32UOK4PWufe4LjMfDvWnnUuPKwcYxKgxGrVKoJUWQaM4wjAvdGsiZV/lDWafa4ctvpR9xo
d/qhLIudoQmE+BUaowoLjoBxEm0brhhrLDEWbRuzLX+NUR5udtv7jDZIsRIcKhWTcpGKRerQdEWk
MTwgBa8xRtPGGDoX/V2PCiXE+zgFRubdg4wpgfjmEyLn107CQCvJycspLDhrVfArV8L0lh++qjtQ
OSTv+s7NWbc8s+pB8tchM17zddU5jmlG3XXZoVduSvhCMS/qn1NGGqDEd/zlm2ZteSetMen0xGLd
bFfeim/Xl6zd8+WXt0L3GwtumTXiL/ePnHXlQ4+bJv179OtfvHzksg+eyLpuwqO3PXrk40X+px85
uPzUG5G3n7y1O+vtcfO02pKRpydOxzXsN67ivpDXcdTfs06+c3jUutR8ZdhlW9rXnb2O/1dWRv/l
aCwJXo6LQpzUYMyRJs34pUlr2R9ff3FJ7p6TOfWDt61Xrk6tbGq7dPkLe7eaM/zjK/50dVxJbPoC
z5G2kbYzs/YJS94O/2GbdvSJBQt1psPDjh5/sqDlpX9+cFex+FvtTZGP1Q5bcnVT4VJlV1V3+6xj
tSvuXCnc9tC6JXdqTn9m/OGbtOIZk/+nevOOairZ43iA0GGRDlKkRqToDcWg0psiIr0j0oIUpXcU
SVSaCAKGqpAEA4QqIkUpEgUEDIqCKMiCLjVIkaqIwkuAVXbVt++8c97bs3/lzJ3cm5k7v99nvt+Z
CdOTodZdzb0WJIR6lWmebBFV+Dy26IrSWu7YCU/aXFWv4ftpTWtExxWNcXq0zjuEiTdOer46fofU
dNIAHTraOCviKAMrINSxI8frA8m6DIzXyLwtNZHEU6IybOZj0K10o8rHVagyTbZOdTzs3ZnwFZ4x
SGn5bKZZjYYsqjasaK3HtHhPYKTW1AFhrCfPmE2dhPsrUJT2jpgor62U7AAQj/7LlGT5mpLUZKWu
sJmMsoA0IIWGoCWixX6WjIEBAXIuThvpx7ORfpRH/JsMpGv6jzJQ8c8ZSBnlmFDf/uOmVCJ2b8La
kUDzl7v8aQ3JoIcNnZ2ti7+8Wl8xbFJwBthblgIFelIGT14X4aw4q9to3HlhPIr3QsHu1FOceqsd
tRmaNMRsEzvay+cLfRYEjAUk9s57XDkt9qGugwc1zRLY5B7S9y7TOYYQcPVjXGC4eHFeRkR6xYek
PX6Ge4MEjmj2v69iFTHvDUGnI108vjA+jX8fVMeY3bfCbgHJcpJvDKe+FRHdiH14WUw29JlScH1K
gP3K3bFj3EzixJHnPYp79TW4VdgcwyVacW6zaU9936mNL7JGDjw7mxfs50G4bnQYUBKtwJbvdFaR
6UsskqaPeMVXaR/x2w2cz5pKXCmABHOQEfBpEwFsIALosopKLPsztWWXqSGN7W8MTCaA7++5zcwp
pu3jG+a/sWkp5bKHckQB9qeNuL1QYUBw88vcP9yig4oCuzaHie9bvamPT6CIZlCgu4+/R2AYBQ8H
YAAUCgCwLTzIU04wQreKf0OL/nIqp24g+I4dmj8uIJWbHuoATGLxVyRPflxDHcurWbuBFVE7a4LN
xiY5yns903INmykJbjfvn393PVowKfeiW2WLV7izeK+QyiAbVcpEWvN9ObesLHdIZtdB2fssVdYQ
gt44k5pymixe6kDhlP4FreGLbHVZpy2cSpBnMY5yIcdImXdcD2UZC0IZJLhy8ePJMnxjqhkuXI7W
tPBcIZhpzIeC2WvUrQLd9y10K+Oi7h+cMr92vOxLQfiZwOPlfMQ0RilRkNVVRw9YnQEHvYrlut3q
TTcmhvznCEur2epDDjyIEHD/cmNZFGrtVuf53oKd/vYqHfXvGfLEgEq6S+2VIiGcl4a2uFEIIHAA
AkvJSyowIgtApEftsOvynfXwzxE3ieS6bZi4/hjj//8fP+RfxPgGFVATzE1XFtL5lKZrqSRehbAv
2DvK5+YwP1ajTY5Naj84Jjr/3ipVtgp9uM159vNL4qFDtvj95h5rEmfU24lFg7Rnf4VeUc3d4etZ
t8ZhxOfR9LlLe5jdVsRo0jmivIi/TQYmKdcIx3DES7K55H0wF1wRbe/lXjAt8daWp/+C5P04euo0
q8lyw5zpo4bxZuCzCJQxVgi1Z6fhCyFq3FzUG5o7dosVv7ZZzcD1H5maV9+hkeJYv9r7niEpsja9
pRgmOxI+UhgyHIwGdXmqE57vj3+jyVGo5Cng+VrpbY8geKRQF9xmq6DsbSjI6lzDhE3ofmGurtcp
aJHv+5rjYExqUG7BczSZCg/J4qB8Sxh4MmcaNYGEitn7m6kxbrvv/W4ShP4uJAD7yXpBEQpTVIQq
UgQ8GfHy+39HAiL/j5KBE2DftBtMVk4B7mQpEEj+nR0bUwjZbNCbwl3P+Hi7/t4ypp+17GfdlCf/
6HfdFAdEN7uxc3uNK3xDfFDUiPGGKRD5niSsFJIwbJDkIVHkSv3QuprxTPiDHgnJ5eAnouud0pbH
O67XIG8rhcmBmgsZXri01+CWSQRCb0VCGpb+E1s10jTrHbK1YUdLYdOM18VEM4E640+uVHEEnh6k
O0gjVGeJQ/n4qovJm0+qd0dhFUMu9OKH/DQUDy96lekt7Q4QFnusxS9sUm2a1Z3XxdnKr+5Hd2Ye
JapzUmu6qT3TVaSWoPgZqzMWcVtoX23+4CJmKFuUbc0aqmmhHFluPT4yZRMmWfxBeh+7unKomtb5
AveRSDF33rGjKc2hOqaHMUYX41Kzm05FTDKuRtOcW870U5EpcMsgDsn9JkO9k03xCHxJhaN8LkZQ
CGLqQyTHHk0ekkqa/D4gP9LhNP8MvHDQMW4ZcG4yX6hpaEDgDYsq9AuYB8wl+VHG4ESbv3np6DJa
mpdnlbBihgD4v97CRQ1mEWYCmYGCyHZdG6QJMG8Inw3foQewfRVYtAAN+WNbXm5gzGX4zQJt7a1J
ZmbFZ0ioWpyz7guGghUneNtemk/KRzSfVs3vvtA93GJpVljF/4Q4Nodesaw+cu2wxCh+10B4zzJP
OMfrhasCUwwnKi9dvZtgXSdIRHWjriksJg+ux2Y7GOgbH4AcFBEwh30+Z8+d+nBAMPG9k6nKKP20
22zYVNITKxc4ik8fHT4ErxmClK21cVS3YomtJy/7LnS8LkZ60w/A+e8WLkc/YNTKmIOUeIRXEGQK
brntwpXHMHilc9be2p8pTJvHqZzXVAKo3RN9CeR3OHMIlltdGZ0LZ7/noMICm0slpMQeB9vS2j96
2ovve3suOXT36h1vXBKdgnWFgzQ7G4CkVSCjTGATY0xOejmPKf8ZBcG/W6H4pyDjG/sOKCoo7qe4
JRhZG5GLSpQiEPg/6cdWPc1P6v9SEnUi0pTL7LHzhKHBrmLUlV6VG7suPzwRvffE+wr/peKSWM+q
/gqxCOa2NpxBsoMYJ2llSfxG1aJ3cNnszE2VR81NNvbqxZUBCpB8Z4RTGMZ50TsW1eX966Pc5zdN
2IOd7vnGwzFpPHEFJxBdOm6jry1zNDo+DwRL7NUBQKO95yJQ7C+shfImjJjbYwewvWaZpztcOjI9
s1IcjhmyT+zrtrNzOGmaFyCHq7uoy5rAzx38mKE/K9+Xe8JwyuPLidteSdN7TGDKl1v19LmvGWfc
WnS/+XKQ0e9UYE5IgtAlr/TJ8ZO6xDdjfqzPXECpEdCMROY7nA2VXTNzQ6IzeEenGZi26sNNSYSk
SiG/kcTvvMs3GMz0eeGDzDqNZgSO89MJ510vfnrty0/Ih6dcFQcjMAAiJ+qHFMEE3vw7+Pe9WDDY
NH46gBaggVZDq0Qf3Gb8/niyztfLg3J139aJuIB9lASgxD859uU3DKHRNieqDWgC6l+dKHW0wk9P
7G08F+7//QMDf+QJlftmUcrZ9hlcJ8y9PYao28YrV7sfGJbuKz5vztovX/3Rc4x1VXRniBrOPfwO
KjLefl67+UI2/FyssclZJNfShYCX2Eb7DmrfJ5DTvPWmXLi4ppoRDBETdCPZT1WgyRJkWfXxIqTf
QWG1VzLcIas/f3VxXnNniYVe6ZGBZGVOa0b9uQVozK56cKIdB5yGxGzShWGJz2zoIxR2MXBLilZV
W8UJPrOLVsJ1fCmKmcLD1Gu0vYZF5nTrI8tIcxa3MUfq4Y1min3tE3QuYLpQb+P1I3XZk9q2Ma9L
maKWbFpkR0bP2x0dlQ+bEbuUwiJXaWzX+kDD2rr4eefwPkLn1JlcWBgUCX5MxuYjaioqAFH1j4Hj
HwD/bRkbjZgAuL5OqFJUUHoa2o3leco0uzX0jDRQlu0r5+SmfysxQ38BttdyA+LfbgRDyXmriLrt
EXV+wQiT8bRdQwahWV+d3wT4b7uFBeoKOKOVo/b/cDNO7+vGx082OTGQKImfn0b9emD1z2oSjKQC
AcoHn7+2uapq7BGfbCVS7tTXSwJ1O3HdECd0algOOoQ6mz94pk0KtCpgWvvlPsnm1HW2mMaPftav
Wm8KFw6IOV0QeZRYgWe/uOuI7fIFosHNalmIbVayhGydz6eWXzHoIhquPD/2JT0R4i7NUWec3oup
dcbQ57wxZ1vmJ6ZjVyNb3Cp0lnOOyWbkxWeQhvlCPtytm87MqiyfNCwSNPIuF1G/9dIkie2+JJ9c
qU/9RGyRccp4ScIs8h7fyTBSevQdaFNktS58RasJT8dgV6Jnsc/bfJB/NLL8RQ6srQzAO6Zm+H0h
JazBqbAJT6wk1ns8R6JrZM492W9S7dn+sp/v7cOWZAySLIuQVKvfRowOiqSaIl+aoIT3qf/JouYP
llJZ6Bg2G0BNpgzaBuDbHnvM37Z2qMih97WGFspGme/JE7y8vII8VP6ALZm/20KPA7xjtBSHPsrJ
cND1Zmi1ve9bxR+EgJ/rJx7eTwujozSc5WrzOk9D5YYbcaK2k7+tTpjoKuC8qs8+GMi4eOejFLc+
fpokb7xYq5Gjb4CM4siruNyNM2A5lZBE4nNWH0EtjDRYTb5E8SphDjSswIQx/RPzJ23QryYJOdc5
WF0VgypCEmUr+5N6Fj3jJuATs3ifElsca6o75EX+cEXxOnJIVaiFaNQwIJogEAwx5b1ry8miZZMi
WRu0tnO5xIoteNWRlPyu/Ty7Az+2lbcv/r3KW5y+bsAINf6xnHtxub4oi0v107bEzkvXM6WnqHSc
j2b0BN3+rUc5MTHLAjLVyk9j/6q97SrdeVLVYn1Xc/rl0lVJTnxilnr2vwDOyM6hDQplbmRzdHJl
YW0NCmVuZG9iag0KOTQ0IDAgb2JqDQpbIDBbIDUwMF0gIDE5MFsgNzk0XSBdIA0KZW5kb2JqDQo5
NDUgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXplIDk0NS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5m
byA3NyAwIFIvSURbPDhDMTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5
RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5MTc+
Pg0Kc3RyZWFtDQp4nDXZBZgV5QLH4f0v2AWKXkzAQkQFBEWxECwMjIuJXhUxMBDEJMQEExHzYmOL
jYEoNohid6MgKoLdAXj43mGfffZ95uyc2T1nZr7ffHPq6mpf8+en9rNxXd0ChhRiqb5nYZF1Ct1/
KOx1aqH3hMLAzwuDRhYGD8fEwpCjCqcfUBg6r3DBuMKILReQTC8sc2+h0b6YVWjcGt8Xll8anQsr
3Fpo0hEDC723LRw9qtB3bOH4nXFRoV8fDEN5DTkhuBEzCgOuKJxYXlhO+qkwqFth0ooYjfGFyfvj
5sILnj5lNXTCJ4UXWxZespWpJxWm9Sh89lDh6z0Ks64tzPbPz5lTmLtDYd4dC6hvOKaw0sxC0+0L
zUYUmn9XaPVooXXTQpvyT9S3W7/QvkWhQ9/C5gMKnZ4udKkt1de+98me2Av/rVHXo245VKv0qD2h
64iyVHswqEcDNMSiWASLYzEsiSWwLJbC0lgGJ6GRv763pcZYHiugCVbESlgV/0FTrIxVsDpWQzOs
geZYEy2wFtbB2lgX66ElWmF9tMaG2AAboQ3aoh02Rge0xyboiE2xGTphc2yBLbE1tsI22Bad0QVd
sT22w47YAd2wE3bBztgVu2F3dMce2At7ogeqw63axftgX+yP/dATB+BA/A8H4WAcgkNxGHqhN47A
4TgSfXAUjsHROBZ9cRz64XicgP44EQNwK052QFcv8xScitMwEIMxCKdjCM7AUNyCm3EWzsSFOAdn
YxjOxXkYjgtwPi7GRbgcl2AELsVIXIZRuBJXYAyuxlW4DqPxf1yLa3ADrsdNuLGQaiy4zdtaHTa3
4w7cibtwN8biXtyD+3EfvscneBAP4GM8hHF4DI/gYYzHo3gcE/ABJuIJvIGn8CSewdN4Hs/hWUzG
JLyIKXgBU/ESXscreBmv4VW8hTfxPt7B23gP7+IjfIhP8R0+wzR8i+n4HHPwBWbgS8zE1/gKs/EN
ZuEH/IQf8TN+xS/4Db/jD/yFP/EP/sY8zMV8x6AoRhSjhtHGyGC0MdoYUYwoRhQjipHBiGIkMqIY
SU4jqGEMqlnBGWCojChGFCOKUcPIYEQxShlRjChGFGOgjtE7EhmJjCxFGyOYkcjoZnQsghnBjChG
KSOfEcyoaCQyuhlRjGBGRSOYkc9oYwQzchaljFJGIiOR0c1IZAQzohjBjGBGIqObEcUoZTQu2hjd
jDZGN6N/kcjIZyQyghkVjY6Vi6/abhS+SGR1+VNFoxrkFq5S7XBtjDZGDSORcRrmYJuuVpHISGS0
MUoZUYxSRhsjmJHISGQ0JxIZ4YtSRj4jmBHMCGYEM8IXiYx8xqVf5DMSmZOheJHICGaUMkoZpYxS
RuqihtHNyGCUMjIYiYziRRQjihHFiGLUMNIaUYwoRhQjihHFiGJEMaoWbYw2RhQjilHDqGF0M0oZ
bYwoRhQjiqmiKFkRqbjyiKuEGKEjkbkNShKljG5GIqOb0cYoZVQ0ShkVjURGIiNLkchIZLQx2hht
jDZGFKOiUbyIYnQzahjBjBpGKSN80cYoXkQxmhpRjChG/yKKEcWoYdQwahg1jBpGDaNxUcOoYdQw
ahh9z/vlxKvmHZlWlhaesKIY/YsaRviieFHDKF7UMFKXr216ZVRDuijmGw9Wo77eZo4Hq0i5xIlA
RykjnxHM/OQJ9QgWTB97jq7mhmWqV6MhFsdiWBRLYgksg6WxFJbDslgJjWEaWKdxZf5XY0U0wX5Y
1bt7oKXVsDrWQDO0QHOshTWxDtbGvmiLllgXbdAK62EjtMb62BAboB22wpZoj42xBTZBB3RCR2yK
zbEZtsZu2BW7oDO2wc7ogm2xHbqiG3bA9tgJO6I79sHe6IE9sDvErc59hjp3Hcolf4397biDLB2A
nqj2ZvU7HSsTvxqH4hAchl64GlfhcPTG8TgSR6Av+uAoHIOjcRyORX/0w5UYgBNgxlduaNQ4Eafi
FIzAQJyGMzEYg3A6huAMDMXZOAvDcC7OwXkYjotxAc7HRbgQI3EJrsAoXIrLcRkmYrS9We2ja3At
rsP1uBE3YAxuwi24GU/gcZjxlWl1jQm4A7fjAdyFO3E3xuJe3IP7cR/G4UE8hofxEMbjUTyCF/Gk
t6A6Wp/C03gGz+J5PIfJmIQpeAF/4SWbro75qXgZr+BVvI7X8CbewNt4C+/gPbyLqlwf4gN8hE/w
MT7FZ9C4MqurMQPT8QW+xEx8hVmoqlYFrErWbHyHb/EDvseP+BlVuX7Bb/gVv+NP/OH9rAarvy1V
A8s/mIt5mG8VNUx1i9QQG6WM1EUUy6SwhhpGMKOUUcpUtzrVMIIZpYxSRiIjkWU6V0MNo5RRw4Wz
QRWNUkb44mKhzP9qVMFcBRIZ3YxuRvEimBHMCGYEM2oYwYx8RgajjdHGiGJEMaIYUYzURWgjrVHD
CGZkMEoZ3YwaRg2jhlHDqGh0M6oWiYz6RhQjilHDqGEkMsIXbYzwRRQjkRHFyG5kN8KX7rVjpL9b
+APaFJ4rH1HUT2q1gAYblU9NGrTtVWg3tbBx+YyhwaGvF3rNLVw5oa7uX/K2AYQNCmVuZHN0cmVh
bQ0KZW5kb2JqDQp4cmVmDQowIDk0Ng0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDE3IDAw
MDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDI3MyAwMDAwMCBuDQowMDAwMDAwNjAz
IDAwMDAwIG4NCjAwMDAwMDEzMTcgMDAwMDAgbg0KMDAwMDAyMDIwOCAwMDAwMCBuDQowMDAwMDIx
MTEyIDAwMDAwIG4NCjAwMDAwMjU3ODYgMDAwMDAgbg0KMDAwMDAzMTQ1NyAwMDAwMCBuDQowMDAw
MDMxNjMyIDAwMDAwIG4NCjAwMDAwMzE4NzkgMDAwMDAgbg0KMDAwMDAzMTkzMyAwMDAwMCBuDQow
MDAwMDMyMTA0IDAwMDAwIG4NCjAwMDAwMzIzNDYgMDAwMDAgbg0KMDAwMDAzMjc2NiAwMDAwMCBu
DQowMDAwMDM1NTA3IDAwMDAwIG4NCjAwMDAwMzY0MTIgMDAwMDAgbg0KMDAwMDA2NjAxOCAwMDAw
MCBuDQowMDAwMDY5MDM4IDAwMDAwIG4NCjAwMDAwNjk3MTkgMDAwMDAgbg0KMDAwMDA2OTg2NSAw
MDAwMCBuDQowMDAwMDY5OTMxIDAwMDAwIG4NCjAwMDAwNzAxMjcgMDAwMDAgbg0KMDAwMDA3MDE1
NiAwMDAwMCBuDQowMDAwMDcwMjA4IDAwMDAwIG4NCjAwMDAwNzA1NjUgMDAwMDAgbg0KMDAwMDA3
MDcxMSAwMDAwMCBuDQowMDAwMDcwNzc4IDAwMDAwIG4NCjAwMDAwOTEyMDEgMDAwMDAgbg0KMDAw
MDA5MjgxOCAwMDAwMCBuDQowMDAwMDkzODY3IDAwMDAwIG4NCjAwMDAwOTQwMjYgMDAwMDAgbg0K
MDAwMDA5NDA5MiAwMDAwMCBuDQowMDAwMDk0MzEzIDAwMDAwIG4NCjAwMDAwOTQzNDIgMDAwMDAg
bg0KMDAwMDA5NDM5NCAwMDAwMCBuDQowMDAwMDk0NzIxIDAwMDAwIG4NCjAwMDAwOTQ4ODAgMDAw
MDAgbg0KMDAwMDA5NDk0NyAwMDAwMCBuDQowMDAwMDk1MTI1IDAwMDAwIG4NCjAwMDAwOTUzNzYg
MDAwMDAgbg0KMDAwMDA5NTczMCAwMDAwMCBuDQowMDAwMDk3MDk3IDAwMDAwIG4NCjAwMDAxMTU5
ODkgMDAwMDAgbg0KMDAwMDExNjEyMiAwMDAwMCBuDQowMDAwMTE2MTUyIDAwMDAwIG4NCjAwMDAx
MTYzMTMgMDAwMDAgbg0KMDAwMDExNjM4NyAwMDAwMCBuDQowMDAwMTE2NjI5IDAwMDAwIG4NCjAw
MDAxMTY3NjQgMDAwMDAgbg0KMDAwMDExNjc5NCAwMDAwMCBuDQowMDAwMTE2OTU3IDAwMDAwIG4N
CjAwMDAxMTcwMzEgMDAwMDAgbg0KMDAwMDExNzI2OSAwMDAwMCBuDQowMDAwMTE3NjIxIDAwMDAw
IG4NCjAwMDAxMjI3MDggMDAwMDAgbg0KMDAwMDEyMzA2MCAwMDAwMCBuDQowMDAwMTI1MDA4IDAw
MDAwIG4NCjAwMDAxMjUzNDAgMDAwMDAgbg0KMDAwMDEyNTgzNiAwMDAwMCBuDQowMDAwMTI2MTg4
IDAwMDAwIG4NCjAwMDAxMzAzNzQgMDAwMDAgbg0KMDAwMDEzMDcyOCAwMDAwMCBuDQowMDAwMTMy
MjU4IDAwMDAwIG4NCjAwMDAxMzY5MzMgMDAwMDAgbg0KMDAwMDEzNzI4NSAwMDAwMCBuDQowMDAw
MTM5MTUwIDAwMDAwIG4NCjAwMDAxMzk1MDIgMDAwMDAgbg0KMDAwMDE0MTc1MSAwMDAwMCBuDQow
MDAwMTQyMTA0IDAwMDAwIG4NCjAwMDAxNDMzMjUgMDAwMDAgbg0KMDAwMDE0MzY1OCAwMDAwMCBu
DQowMDAwMTQ0MTYxIDAwMDAwIG4NCjAwMDAxNDQ0OTQgMDAwMDAgbg0KMDAwMDE0NTc3OSAwMDAw
MCBuDQowMDAwMTQ2MTEyIDAwMDAwIG4NCjAwMDAxNDgwODMgMDAwMDAgbg0KMDAwMDAwMDA3OSA2
NTUzNSBmDQowMDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4
MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAw
MDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAw
MDAwMDA4OCA2NTUzNSBmDQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0K
MDAwMDAwMDA5MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUg
Zg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1
MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkg
NjU1MzUgZg0KMDAwMDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAx
MDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAw
MDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAw
MDAwMDAxMDggNjU1MzUgZg0KMDAwMDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYN
CjAwMDAwMDAxMTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1
IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1
NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5
IDY1NTM1IGYNCjAwMDAwMDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAw
MTIyIDY1NTM1IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAw
MDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQow
MDAwMDAwMTI4IDY1NTM1IGYNCjAwMDAwMDAxMjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBm
DQowMDAwMDAwMTMxIDY1NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUz
NSBmDQowMDAwMDAwMTM0IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDEzNiA2
NTUzNSBmDQowMDAwMDAwMTM3IDY1NTM1IGYNCjAwMDAwMDAxMzggNjU1MzUgZg0KMDAwMDAwMDEz
OSA2NTUzNSBmDQowMDAwMDAwMTQwIDY1NTM1IGYNCjAwMDAwMDAxNDEgNjU1MzUgZg0KMDAwMDAw
MDE0MiA2NTUzNSBmDQowMDAwMDAwMTQzIDY1NTM1IGYNCjAwMDAwMDAxNDQgNjU1MzUgZg0KMDAw
MDAwMDE0NSA2NTUzNSBmDQowMDAwMDAwMTQ2IDY1NTM1IGYNCjAwMDAwMDAxNDcgNjU1MzUgZg0K
MDAwMDAwMDE0OCA2NTUzNSBmDQowMDAwMDAwMTQ5IDY1NTM1IGYNCjAwMDAwMDAxNTAgNjU1MzUg
Zg0KMDAwMDAwMDE1MSA2NTUzNSBmDQowMDAwMDAwMTUyIDY1NTM1IGYNCjAwMDAwMDAxNTMgNjU1
MzUgZg0KMDAwMDAwMDE1NCA2NTUzNSBmDQowMDAwMDAwMTU1IDY1NTM1IGYNCjAwMDAwMDAxNTYg
NjU1MzUgZg0KMDAwMDAwMDE1NyA2NTUzNSBmDQowMDAwMDAwMTU4IDY1NTM1IGYNCjAwMDAwMDAx
NTkgNjU1MzUgZg0KMDAwMDAwMDE2MCA2NTUzNSBmDQowMDAwMDAwMTYxIDY1NTM1IGYNCjAwMDAw
MDAxNjIgNjU1MzUgZg0KMDAwMDAwMDE2MyA2NTUzNSBmDQowMDAwMDAwMTY0IDY1NTM1IGYNCjAw
MDAwMDAxNjUgNjU1MzUgZg0KMDAwMDAwMDE2NiA2NTUzNSBmDQowMDAwMDAwMTY3IDY1NTM1IGYN
CjAwMDAwMDAxNjggNjU1MzUgZg0KMDAwMDAwMDE2OSA2NTUzNSBmDQowMDAwMDAwMTcwIDY1NTM1
IGYNCjAwMDAwMDAxNzEgNjU1MzUgZg0KMDAwMDAwMDE3MiA2NTUzNSBmDQowMDAwMDAwMTczIDY1
NTM1IGYNCjAwMDAwMDAxNzQgNjU1MzUgZg0KMDAwMDAwMDE3NSA2NTUzNSBmDQowMDAwMDAwMTc2
IDY1NTM1IGYNCjAwMDAwMDAxNzcgNjU1MzUgZg0KMDAwMDAwMDE3OCA2NTUzNSBmDQowMDAwMDAw
MTc5IDY1NTM1IGYNCjAwMDAwMDAxODAgNjU1MzUgZg0KMDAwMDAwMDE4MSA2NTUzNSBmDQowMDAw
MDAwMTgyIDY1NTM1IGYNCjAwMDAwMDAxODMgNjU1MzUgZg0KMDAwMDAwMDE4NCA2NTUzNSBmDQow
MDAwMDAwMTg1IDY1NTM1IGYNCjAwMDAwMDAxODYgNjU1MzUgZg0KMDAwMDAwMDE4NyA2NTUzNSBm
DQowMDAwMDAwMTg4IDY1NTM1IGYNCjAwMDAwMDAxODkgNjU1MzUgZg0KMDAwMDAwMDE5MCA2NTUz
NSBmDQowMDAwMDAwMTkxIDY1NTM1IGYNCjAwMDAwMDAxOTIgNjU1MzUgZg0KMDAwMDAwMDE5MyA2
NTUzNSBmDQowMDAwMDAwMTk0IDY1NTM1IGYNCjAwMDAwMDAxOTUgNjU1MzUgZg0KMDAwMDAwMDE5
NiA2NTUzNSBmDQowMDAwMDAwMTk3IDY1NTM1IGYNCjAwMDAwMDAxOTggNjU1MzUgZg0KMDAwMDAw
MDE5OSA2NTUzNSBmDQowMDAwMDAwMjAwIDY1NTM1IGYNCjAwMDAwMDAyMDEgNjU1MzUgZg0KMDAw
MDAwMDIwMiA2NTUzNSBmDQowMDAwMDAwMjAzIDY1NTM1IGYNCjAwMDAwMDAyMDQgNjU1MzUgZg0K
MDAwMDAwMDIwNSA2NTUzNSBmDQowMDAwMDAwMjA2IDY1NTM1IGYNCjAwMDAwMDAyMDcgNjU1MzUg
Zg0KMDAwMDAwMDIwOCA2NTUzNSBmDQowMDAwMDAwMjA5IDY1NTM1IGYNCjAwMDAwMDAyMTAgNjU1
MzUgZg0KMDAwMDAwMDIxMSA2NTUzNSBmDQowMDAwMDAwMjEyIDY1NTM1IGYNCjAwMDAwMDAyMTMg
NjU1MzUgZg0KMDAwMDAwMDIxNCA2NTUzNSBmDQowMDAwMDAwMjE1IDY1NTM1IGYNCjAwMDAwMDAy
MTYgNjU1MzUgZg0KMDAwMDAwMDIxNyA2NTUzNSBmDQowMDAwMDAwMjE4IDY1NTM1IGYNCjAwMDAw
MDAyMTkgNjU1MzUgZg0KMDAwMDAwMDIyMCA2NTUzNSBmDQowMDAwMDAwMjIxIDY1NTM1IGYNCjAw
MDAwMDAyMjIgNjU1MzUgZg0KMDAwMDAwMDIyMyA2NTUzNSBmDQowMDAwMDAwMjI0IDY1NTM1IGYN
CjAwMDAwMDAyMjUgNjU1MzUgZg0KMDAwMDAwMDIyNiA2NTUzNSBmDQowMDAwMDAwMjI3IDY1NTM1
IGYNCjAwMDAwMDAyMjggNjU1MzUgZg0KMDAwMDAwMDIyOSA2NTUzNSBmDQowMDAwMDAwMjMwIDY1
NTM1IGYNCjAwMDAwMDAyMzEgNjU1MzUgZg0KMDAwMDAwMDIzMiA2NTUzNSBmDQowMDAwMDAwMjMz
IDY1NTM1IGYNCjAwMDAwMDAyMzQgNjU1MzUgZg0KMDAwMDAwMDIzNSA2NTUzNSBmDQowMDAwMDAw
MjM2IDY1NTM1IGYNCjAwMDAwMDAyMzcgNjU1MzUgZg0KMDAwMDAwMDIzOCA2NTUzNSBmDQowMDAw
MDAwMjM5IDY1NTM1IGYNCjAwMDAwMDAyNDAgNjU1MzUgZg0KMDAwMDAwMDI0MSA2NTUzNSBmDQow
MDAwMDAwMjQyIDY1NTM1IGYNCjAwMDAwMDAyNDMgNjU1MzUgZg0KMDAwMDAwMDI0NCA2NTUzNSBm
DQowMDAwMDAwMjQ1IDY1NTM1IGYNCjAwMDAwMDAyNDYgNjU1MzUgZg0KMDAwMDAwMDI0NyA2NTUz
NSBmDQowMDAwMDAwMjQ4IDY1NTM1IGYNCjAwMDAwMDAyNDkgNjU1MzUgZg0KMDAwMDAwMDI1MCA2
NTUzNSBmDQowMDAwMDAwMjUxIDY1NTM1IGYNCjAwMDAwMDAyNTIgNjU1MzUgZg0KMDAwMDAwMDI1
MyA2NTUzNSBmDQowMDAwMDAwMjU0IDY1NTM1IGYNCjAwMDAwMDAyNTUgNjU1MzUgZg0KMDAwMDAw
MDI1NiA2NTUzNSBmDQowMDAwMDAwMjU3IDY1NTM1IGYNCjAwMDAwMDAyNTggNjU1MzUgZg0KMDAw
MDAwMDI1OSA2NTUzNSBmDQowMDAwMDAwMjYwIDY1NTM1IGYNCjAwMDAwMDAyNjEgNjU1MzUgZg0K
MDAwMDAwMDI2MiA2NTUzNSBmDQowMDAwMDAwMjYzIDY1NTM1IGYNCjAwMDAwMDAyNjQgNjU1MzUg
Zg0KMDAwMDAwMDI2NSA2NTUzNSBmDQowMDAwMDAwMjY2IDY1NTM1IGYNCjAwMDAwMDAyNjcgNjU1
MzUgZg0KMDAwMDAwMDI2OCA2NTUzNSBmDQowMDAwMDAwMjY5IDY1NTM1IGYNCjAwMDAwMDAyNzAg
NjU1MzUgZg0KMDAwMDAwMDI3MSA2NTUzNSBmDQowMDAwMDAwMjcyIDY1NTM1IGYNCjAwMDAwMDAy
NzMgNjU1MzUgZg0KMDAwMDAwMDI3NCA2NTUzNSBmDQowMDAwMDAwMjc1IDY1NTM1IGYNCjAwMDAw
MDAyNzYgNjU1MzUgZg0KMDAwMDAwMDI3NyA2NTUzNSBmDQowMDAwMDAwMjc4IDY1NTM1IGYNCjAw
MDAwMDAyNzkgNjU1MzUgZg0KMDAwMDAwMDI4MCA2NTUzNSBmDQowMDAwMDAwMjgxIDY1NTM1IGYN
CjAwMDAwMDAyODIgNjU1MzUgZg0KMDAwMDAwMDI4MyA2NTUzNSBmDQowMDAwMDAwMjg0IDY1NTM1
IGYNCjAwMDAwMDAyODUgNjU1MzUgZg0KMDAwMDAwMDI4NiA2NTUzNSBmDQowMDAwMDAwMjg3IDY1
NTM1IGYNCjAwMDAwMDAyODggNjU1MzUgZg0KMDAwMDAwMDI4OSA2NTUzNSBmDQowMDAwMDAwMjkw
IDY1NTM1IGYNCjAwMDAwMDAyOTEgNjU1MzUgZg0KMDAwMDAwMDI5MiA2NTUzNSBmDQowMDAwMDAw
MjkzIDY1NTM1IGYNCjAwMDAwMDAyOTQgNjU1MzUgZg0KMDAwMDAwMDI5NSA2NTUzNSBmDQowMDAw
MDAwMjk2IDY1NTM1IGYNCjAwMDAwMDAyOTcgNjU1MzUgZg0KMDAwMDAwMDI5OCA2NTUzNSBmDQow
MDAwMDAwMjk5IDY1NTM1IGYNCjAwMDAwMDAzMDAgNjU1MzUgZg0KMDAwMDAwMDMwMSA2NTUzNSBm
DQowMDAwMDAwMzAyIDY1NTM1IGYNCjAwMDAwMDAzMDMgNjU1MzUgZg0KMDAwMDAwMDMwNCA2NTUz
NSBmDQowMDAwMDAwMzA1IDY1NTM1IGYNCjAwMDAwMDAzMDYgNjU1MzUgZg0KMDAwMDAwMDMwNyA2
NTUzNSBmDQowMDAwMDAwMzA4IDY1NTM1IGYNCjAwMDAwMDAzMDkgNjU1MzUgZg0KMDAwMDAwMDMx
MCA2NTUzNSBmDQowMDAwMDAwMzExIDY1NTM1IGYNCjAwMDAwMDAzMTIgNjU1MzUgZg0KMDAwMDAw
MDMxMyA2NTUzNSBmDQowMDAwMDAwMzE0IDY1NTM1IGYNCjAwMDAwMDAzMTUgNjU1MzUgZg0KMDAw
MDAwMDMxNiA2NTUzNSBmDQowMDAwMDAwMzE3IDY1NTM1IGYNCjAwMDAwMDAzMTggNjU1MzUgZg0K
MDAwMDAwMDMxOSA2NTUzNSBmDQowMDAwMDAwMzIwIDY1NTM1IGYNCjAwMDAwMDAzMjEgNjU1MzUg
Zg0KMDAwMDAwMDMyMiA2NTUzNSBmDQowMDAwMDAwMzIzIDY1NTM1IGYNCjAwMDAwMDAzMjQgNjU1
MzUgZg0KMDAwMDAwMDMyNSA2NTUzNSBmDQowMDAwMDAwMzI2IDY1NTM1IGYNCjAwMDAwMDAzMjcg
NjU1MzUgZg0KMDAwMDAwMDMyOCA2NTUzNSBmDQowMDAwMDAwMzI5IDY1NTM1IGYNCjAwMDAwMDAz
MzAgNjU1MzUgZg0KMDAwMDAwMDMzMSA2NTUzNSBmDQowMDAwMDAwMzMyIDY1NTM1IGYNCjAwMDAw
MDAzMzMgNjU1MzUgZg0KMDAwMDAwMDMzNCA2NTUzNSBmDQowMDAwMDAwMzM1IDY1NTM1IGYNCjAw
MDAwMDAzMzYgNjU1MzUgZg0KMDAwMDAwMDMzNyA2NTUzNSBmDQowMDAwMDAwMzM4IDY1NTM1IGYN
CjAwMDAwMDAzMzkgNjU1MzUgZg0KMDAwMDAwMDM0MCA2NTUzNSBmDQowMDAwMDAwMzQxIDY1NTM1
IGYNCjAwMDAwMDAzNDIgNjU1MzUgZg0KMDAwMDAwMDM0MyA2NTUzNSBmDQowMDAwMDAwMzQ0IDY1
NTM1IGYNCjAwMDAwMDAzNDUgNjU1MzUgZg0KMDAwMDAwMDM0NiA2NTUzNSBmDQowMDAwMDAwMzQ3
IDY1NTM1IGYNCjAwMDAwMDAzNDggNjU1MzUgZg0KMDAwMDAwMDM0OSA2NTUzNSBmDQowMDAwMDAw
MzUwIDY1NTM1IGYNCjAwMDAwMDAzNTEgNjU1MzUgZg0KMDAwMDAwMDM1MiA2NTUzNSBmDQowMDAw
MDAwMzUzIDY1NTM1IGYNCjAwMDAwMDAzNTQgNjU1MzUgZg0KMDAwMDAwMDM1NSA2NTUzNSBmDQow
MDAwMDAwMzU2IDY1NTM1IGYNCjAwMDAwMDAzNTcgNjU1MzUgZg0KMDAwMDAwMDM1OCA2NTUzNSBm
DQowMDAwMDAwMzU5IDY1NTM1IGYNCjAwMDAwMDAzNjAgNjU1MzUgZg0KMDAwMDAwMDM2MSA2NTUz
NSBmDQowMDAwMDAwMzYyIDY1NTM1IGYNCjAwMDAwMDAzNjMgNjU1MzUgZg0KMDAwMDAwMDM2NCA2
NTUzNSBmDQowMDAwMDAwMzY1IDY1NTM1IGYNCjAwMDAwMDAzNjYgNjU1MzUgZg0KMDAwMDAwMDM2
NyA2NTUzNSBmDQowMDAwMDAwMzY4IDY1NTM1IGYNCjAwMDAwMDAzNjkgNjU1MzUgZg0KMDAwMDAw
MDM3MCA2NTUzNSBmDQowMDAwMDAwMzcxIDY1NTM1IGYNCjAwMDAwMDAzNzIgNjU1MzUgZg0KMDAw
MDAwMDM3MyA2NTUzNSBmDQowMDAwMDAwMzc0IDY1NTM1IGYNCjAwMDAwMDAzNzUgNjU1MzUgZg0K
MDAwMDAwMDM3NiA2NTUzNSBmDQowMDAwMDAwMzc3IDY1NTM1IGYNCjAwMDAwMDAzNzggNjU1MzUg
Zg0KMDAwMDAwMDM3OSA2NTUzNSBmDQowMDAwMDAwMzgwIDY1NTM1IGYNCjAwMDAwMDAzODEgNjU1
MzUgZg0KMDAwMDAwMDM4MiA2NTUzNSBmDQowMDAwMDAwMzgzIDY1NTM1IGYNCjAwMDAwMDAzODQg
NjU1MzUgZg0KMDAwMDAwMDM4NSA2NTUzNSBmDQowMDAwMDAwMzg2IDY1NTM1IGYNCjAwMDAwMDAz
ODcgNjU1MzUgZg0KMDAwMDAwMDM4OCA2NTUzNSBmDQowMDAwMDAwMzg5IDY1NTM1IGYNCjAwMDAw
MDAzOTAgNjU1MzUgZg0KMDAwMDAwMDM5MSA2NTUzNSBmDQowMDAwMDAwMzkyIDY1NTM1IGYNCjAw
MDAwMDAzOTMgNjU1MzUgZg0KMDAwMDAwMDM5NCA2NTUzNSBmDQowMDAwMDAwMzk1IDY1NTM1IGYN
CjAwMDAwMDAzOTYgNjU1MzUgZg0KMDAwMDAwMDM5NyA2NTUzNSBmDQowMDAwMDAwMzk4IDY1NTM1
IGYNCjAwMDAwMDAzOTkgNjU1MzUgZg0KMDAwMDAwMDQwMCA2NTUzNSBmDQowMDAwMDAwNDAxIDY1
NTM1IGYNCjAwMDAwMDA0MDIgNjU1MzUgZg0KMDAwMDAwMDQwMyA2NTUzNSBmDQowMDAwMDAwNDA0
IDY1NTM1IGYNCjAwMDAwMDA0MDUgNjU1MzUgZg0KMDAwMDAwMDQwNiA2NTUzNSBmDQowMDAwMDAw
NDA3IDY1NTM1IGYNCjAwMDAwMDA0MDggNjU1MzUgZg0KMDAwMDAwMDQwOSA2NTUzNSBmDQowMDAw
MDAwNDEwIDY1NTM1IGYNCjAwMDAwMDA0MTEgNjU1MzUgZg0KMDAwMDAwMDQxMiA2NTUzNSBmDQow
MDAwMDAwNDEzIDY1NTM1IGYNCjAwMDAwMDA0MTQgNjU1MzUgZg0KMDAwMDAwMDQxNSA2NTUzNSBm
DQowMDAwMDAwNDE2IDY1NTM1IGYNCjAwMDAwMDA0MTcgNjU1MzUgZg0KMDAwMDAwMDQxOCA2NTUz
NSBmDQowMDAwMDAwNDE5IDY1NTM1IGYNCjAwMDAwMDA0MjAgNjU1MzUgZg0KMDAwMDAwMDQyMSA2
NTUzNSBmDQowMDAwMDAwNDIyIDY1NTM1IGYNCjAwMDAwMDA0MjMgNjU1MzUgZg0KMDAwMDAwMDQy
NCA2NTUzNSBmDQowMDAwMDAwNDI1IDY1NTM1IGYNCjAwMDAwMDA0MjYgNjU1MzUgZg0KMDAwMDAw
MDQyNyA2NTUzNSBmDQowMDAwMDAwNDI4IDY1NTM1IGYNCjAwMDAwMDA0MjkgNjU1MzUgZg0KMDAw
MDAwMDQzMCA2NTUzNSBmDQowMDAwMDAwNDMxIDY1NTM1IGYNCjAwMDAwMDA0MzIgNjU1MzUgZg0K
MDAwMDAwMDQzMyA2NTUzNSBmDQowMDAwMDAwNDM0IDY1NTM1IGYNCjAwMDAwMDA0MzUgNjU1MzUg
Zg0KMDAwMDAwMDQzNiA2NTUzNSBmDQowMDAwMDAwNDM3IDY1NTM1IGYNCjAwMDAwMDA0MzggNjU1
MzUgZg0KMDAwMDAwMDQzOSA2NTUzNSBmDQowMDAwMDAwNDQwIDY1NTM1IGYNCjAwMDAwMDA0NDEg
NjU1MzUgZg0KMDAwMDAwMDQ0MiA2NTUzNSBmDQowMDAwMDAwNDQzIDY1NTM1IGYNCjAwMDAwMDA0
NDQgNjU1MzUgZg0KMDAwMDAwMDQ0NSA2NTUzNSBmDQowMDAwMDAwNDQ2IDY1NTM1IGYNCjAwMDAw
MDA0NDcgNjU1MzUgZg0KMDAwMDAwMDQ0OCA2NTUzNSBmDQowMDAwMDAwNDQ5IDY1NTM1IGYNCjAw
MDAwMDA0NTAgNjU1MzUgZg0KMDAwMDAwMDQ1MSA2NTUzNSBmDQowMDAwMDAwNDUyIDY1NTM1IGYN
CjAwMDAwMDA0NTMgNjU1MzUgZg0KMDAwMDAwMDQ1NCA2NTUzNSBmDQowMDAwMDAwNDU1IDY1NTM1
IGYNCjAwMDAwMDA0NTYgNjU1MzUgZg0KMDAwMDAwMDQ1NyA2NTUzNSBmDQowMDAwMDAwNDU4IDY1
NTM1IGYNCjAwMDAwMDA0NTkgNjU1MzUgZg0KMDAwMDAwMDQ2MCA2NTUzNSBmDQowMDAwMDAwNDYx
IDY1NTM1IGYNCjAwMDAwMDA0NjIgNjU1MzUgZg0KMDAwMDAwMDQ2MyA2NTUzNSBmDQowMDAwMDAw
NDY0IDY1NTM1IGYNCjAwMDAwMDA0NjUgNjU1MzUgZg0KMDAwMDAwMDQ2NiA2NTUzNSBmDQowMDAw
MDAwNDY3IDY1NTM1IGYNCjAwMDAwMDA0NjggNjU1MzUgZg0KMDAwMDAwMDQ2OSA2NTUzNSBmDQow
MDAwMDAwNDcwIDY1NTM1IGYNCjAwMDAwMDA0NzEgNjU1MzUgZg0KMDAwMDAwMDQ3MiA2NTUzNSBm
DQowMDAwMDAwNDczIDY1NTM1IGYNCjAwMDAwMDA0NzQgNjU1MzUgZg0KMDAwMDAwMDQ3NSA2NTUz
NSBmDQowMDAwMDAwNDc2IDY1NTM1IGYNCjAwMDAwMDA0NzcgNjU1MzUgZg0KMDAwMDAwMDQ3OCA2
NTUzNSBmDQowMDAwMDAwNDc5IDY1NTM1IGYNCjAwMDAwMDA0ODAgNjU1MzUgZg0KMDAwMDAwMDQ4
MSA2NTUzNSBmDQowMDAwMDAwNDgyIDY1NTM1IGYNCjAwMDAwMDA0ODMgNjU1MzUgZg0KMDAwMDAw
MDQ4NCA2NTUzNSBmDQowMDAwMDAwNDg1IDY1NTM1IGYNCjAwMDAwMDA0ODYgNjU1MzUgZg0KMDAw
MDAwMDQ4NyA2NTUzNSBmDQowMDAwMDAwNDg4IDY1NTM1IGYNCjAwMDAwMDA0ODkgNjU1MzUgZg0K
MDAwMDAwMDQ5MCA2NTUzNSBmDQowMDAwMDAwNDkxIDY1NTM1IGYNCjAwMDAwMDA0OTIgNjU1MzUg
Zg0KMDAwMDAwMDQ5MyA2NTUzNSBmDQowMDAwMDAwNDk0IDY1NTM1IGYNCjAwMDAwMDA0OTUgNjU1
MzUgZg0KMDAwMDAwMDQ5NiA2NTUzNSBmDQowMDAwMDAwNDk3IDY1NTM1IGYNCjAwMDAwMDA0OTgg
NjU1MzUgZg0KMDAwMDAwMDQ5OSA2NTUzNSBmDQowMDAwMDAwNTAwIDY1NTM1IGYNCjAwMDAwMDA1
MDEgNjU1MzUgZg0KMDAwMDAwMDUwMiA2NTUzNSBmDQowMDAwMDAwNTAzIDY1NTM1IGYNCjAwMDAw
MDA1MDQgNjU1MzUgZg0KMDAwMDAwMDUwNSA2NTUzNSBmDQowMDAwMDAwNTA2IDY1NTM1IGYNCjAw
MDAwMDA1MDcgNjU1MzUgZg0KMDAwMDAwMDUwOCA2NTUzNSBmDQowMDAwMDAwNTA5IDY1NTM1IGYN
CjAwMDAwMDA1MTAgNjU1MzUgZg0KMDAwMDAwMDUxMSA2NTUzNSBmDQowMDAwMDAwNTEyIDY1NTM1
IGYNCjAwMDAwMDA1MTMgNjU1MzUgZg0KMDAwMDAwMDUxNCA2NTUzNSBmDQowMDAwMDAwNTE1IDY1
NTM1IGYNCjAwMDAwMDA1MTYgNjU1MzUgZg0KMDAwMDAwMDUxNyA2NTUzNSBmDQowMDAwMDAwNTE4
IDY1NTM1IGYNCjAwMDAwMDA1MTkgNjU1MzUgZg0KMDAwMDAwMDUyMCA2NTUzNSBmDQowMDAwMDAw
NTIxIDY1NTM1IGYNCjAwMDAwMDA1MjIgNjU1MzUgZg0KMDAwMDAwMDUyMyA2NTUzNSBmDQowMDAw
MDAwNTI0IDY1NTM1IGYNCjAwMDAwMDA1MjUgNjU1MzUgZg0KMDAwMDAwMDUyNiA2NTUzNSBmDQow
MDAwMDAwNTI3IDY1NTM1IGYNCjAwMDAwMDA1MjggNjU1MzUgZg0KMDAwMDAwMDUyOSA2NTUzNSBm
DQowMDAwMDAwNTMwIDY1NTM1IGYNCjAwMDAwMDA1MzEgNjU1MzUgZg0KMDAwMDAwMDUzMiA2NTUz
NSBmDQowMDAwMDAwNTMzIDY1NTM1IGYNCjAwMDAwMDA1MzQgNjU1MzUgZg0KMDAwMDAwMDUzNSA2
NTUzNSBmDQowMDAwMDAwNTM2IDY1NTM1IGYNCjAwMDAwMDA1MzcgNjU1MzUgZg0KMDAwMDAwMDUz
OCA2NTUzNSBmDQowMDAwMDAwNTM5IDY1NTM1IGYNCjAwMDAwMDA1NDAgNjU1MzUgZg0KMDAwMDAw
MDU0MSA2NTUzNSBmDQowMDAwMDAwNTQyIDY1NTM1IGYNCjAwMDAwMDA1NDMgNjU1MzUgZg0KMDAw
MDAwMDU0NCA2NTUzNSBmDQowMDAwMDAwNTQ1IDY1NTM1IGYNCjAwMDAwMDA1NDYgNjU1MzUgZg0K
MDAwMDAwMDU0NyA2NTUzNSBmDQowMDAwMDAwNTQ4IDY1NTM1IGYNCjAwMDAwMDA1NDkgNjU1MzUg
Zg0KMDAwMDAwMDU1MCA2NTUzNSBmDQowMDAwMDAwNTUxIDY1NTM1IGYNCjAwMDAwMDA1NTIgNjU1
MzUgZg0KMDAwMDAwMDU1MyA2NTUzNSBmDQowMDAwMDAwNTU0IDY1NTM1IGYNCjAwMDAwMDA1NTUg
NjU1MzUgZg0KMDAwMDAwMDU1NiA2NTUzNSBmDQowMDAwMDAwNTU3IDY1NTM1IGYNCjAwMDAwMDA1
NTggNjU1MzUgZg0KMDAwMDAwMDU1OSA2NTUzNSBmDQowMDAwMDAwNTYwIDY1NTM1IGYNCjAwMDAw
MDA1NjEgNjU1MzUgZg0KMDAwMDAwMDU2MiA2NTUzNSBmDQowMDAwMDAwNTYzIDY1NTM1IGYNCjAw
MDAwMDA1NjQgNjU1MzUgZg0KMDAwMDAwMDU2NSA2NTUzNSBmDQowMDAwMDAwNTY2IDY1NTM1IGYN
CjAwMDAwMDA1NjcgNjU1MzUgZg0KMDAwMDAwMDU2OCA2NTUzNSBmDQowMDAwMDAwNTY5IDY1NTM1
IGYNCjAwMDAwMDA1NzAgNjU1MzUgZg0KMDAwMDAwMDU3MSA2NTUzNSBmDQowMDAwMDAwNTcyIDY1
NTM1IGYNCjAwMDAwMDA1NzMgNjU1MzUgZg0KMDAwMDAwMDU3NCA2NTUzNSBmDQowMDAwMDAwNTc1
IDY1NTM1IGYNCjAwMDAwMDA1NzYgNjU1MzUgZg0KMDAwMDAwMDU3NyA2NTUzNSBmDQowMDAwMDAw
NTc4IDY1NTM1IGYNCjAwMDAwMDA1NzkgNjU1MzUgZg0KMDAwMDAwMDU4MCA2NTUzNSBmDQowMDAw
MDAwNTgxIDY1NTM1IGYNCjAwMDAwMDA1ODIgNjU1MzUgZg0KMDAwMDAwMDU4MyA2NTUzNSBmDQow
MDAwMDAwNTg0IDY1NTM1IGYNCjAwMDAwMDA1ODUgNjU1MzUgZg0KMDAwMDAwMDU4NiA2NTUzNSBm
DQowMDAwMDAwNTg3IDY1NTM1IGYNCjAwMDAwMDA1ODggNjU1MzUgZg0KMDAwMDAwMDU4OSA2NTUz
NSBmDQowMDAwMDAwNTkwIDY1NTM1IGYNCjAwMDAwMDA1OTEgNjU1MzUgZg0KMDAwMDAwMDU5MiA2
NTUzNSBmDQowMDAwMDAwNTkzIDY1NTM1IGYNCjAwMDAwMDA1OTQgNjU1MzUgZg0KMDAwMDAwMDU5
NSA2NTUzNSBmDQowMDAwMDAwNTk2IDY1NTM1IGYNCjAwMDAwMDA1OTcgNjU1MzUgZg0KMDAwMDAw
MDU5OCA2NTUzNSBmDQowMDAwMDAwNTk5IDY1NTM1IGYNCjAwMDAwMDA2MDAgNjU1MzUgZg0KMDAw
MDAwMDYwMSA2NTUzNSBmDQowMDAwMDAwNjAyIDY1NTM1IGYNCjAwMDAwMDA2MDMgNjU1MzUgZg0K
MDAwMDAwMDYwNCA2NTUzNSBmDQowMDAwMDAwNjA1IDY1NTM1IGYNCjAwMDAwMDA2MDYgNjU1MzUg
Zg0KMDAwMDAwMDYwNyA2NTUzNSBmDQowMDAwMDAwNjA4IDY1NTM1IGYNCjAwMDAwMDA2MDkgNjU1
MzUgZg0KMDAwMDAwMDYxMCA2NTUzNSBmDQowMDAwMDAwNjExIDY1NTM1IGYNCjAwMDAwMDA2MTIg
NjU1MzUgZg0KMDAwMDAwMDYxMyA2NTUzNSBmDQowMDAwMDAwNjE0IDY1NTM1IGYNCjAwMDAwMDA2
MTUgNjU1MzUgZg0KMDAwMDAwMDYxNiA2NTUzNSBmDQowMDAwMDAwNjE3IDY1NTM1IGYNCjAwMDAw
MDA2MTggNjU1MzUgZg0KMDAwMDAwMDYxOSA2NTUzNSBmDQowMDAwMDAwNjIwIDY1NTM1IGYNCjAw
MDAwMDA2MjEgNjU1MzUgZg0KMDAwMDAwMDYyMiA2NTUzNSBmDQowMDAwMDAwNjIzIDY1NTM1IGYN
CjAwMDAwMDA2MjQgNjU1MzUgZg0KMDAwMDAwMDYyNSA2NTUzNSBmDQowMDAwMDAwNjI2IDY1NTM1
IGYNCjAwMDAwMDA2MjcgNjU1MzUgZg0KMDAwMDAwMDYyOCA2NTUzNSBmDQowMDAwMDAwNjI5IDY1
NTM1IGYNCjAwMDAwMDA2MzAgNjU1MzUgZg0KMDAwMDAwMDYzMSA2NTUzNSBmDQowMDAwMDAwNjMy
IDY1NTM1IGYNCjAwMDAwMDA2MzMgNjU1MzUgZg0KMDAwMDAwMDYzNCA2NTUzNSBmDQowMDAwMDAw
NjM1IDY1NTM1IGYNCjAwMDAwMDA2MzYgNjU1MzUgZg0KMDAwMDAwMDYzNyA2NTUzNSBmDQowMDAw
MDAwNjM4IDY1NTM1IGYNCjAwMDAwMDA2MzkgNjU1MzUgZg0KMDAwMDAwMDY0MCA2NTUzNSBmDQow
MDAwMDAwNjQxIDY1NTM1IGYNCjAwMDAwMDA2NDIgNjU1MzUgZg0KMDAwMDAwMDY0MyA2NTUzNSBm
DQowMDAwMDAwNjQ0IDY1NTM1IGYNCjAwMDAwMDA2NDUgNjU1MzUgZg0KMDAwMDAwMDY0NiA2NTUz
NSBmDQowMDAwMDAwNjQ3IDY1NTM1IGYNCjAwMDAwMDA2NDggNjU1MzUgZg0KMDAwMDAwMDY0OSA2
NTUzNSBmDQowMDAwMDAwNjUwIDY1NTM1IGYNCjAwMDAwMDA2NTEgNjU1MzUgZg0KMDAwMDAwMDY1
MiA2NTUzNSBmDQowMDAwMDAwNjUzIDY1NTM1IGYNCjAwMDAwMDA2NTQgNjU1MzUgZg0KMDAwMDAw
MDY1NSA2NTUzNSBmDQowMDAwMDAwNjU2IDY1NTM1IGYNCjAwMDAwMDA2NTcgNjU1MzUgZg0KMDAw
MDAwMDY1OCA2NTUzNSBmDQowMDAwMDAwNjU5IDY1NTM1IGYNCjAwMDAwMDA2NjAgNjU1MzUgZg0K
MDAwMDAwMDY2MSA2NTUzNSBmDQowMDAwMDAwNjYyIDY1NTM1IGYNCjAwMDAwMDA2NjMgNjU1MzUg
Zg0KMDAwMDAwMDY2NCA2NTUzNSBmDQowMDAwMDAwNjY1IDY1NTM1IGYNCjAwMDAwMDA2NjYgNjU1
MzUgZg0KMDAwMDAwMDY2NyA2NTUzNSBmDQowMDAwMDAwNjY4IDY1NTM1IGYNCjAwMDAwMDA2Njkg
NjU1MzUgZg0KMDAwMDAwMDY3MCA2NTUzNSBmDQowMDAwMDAwNjcxIDY1NTM1IGYNCjAwMDAwMDA2
NzIgNjU1MzUgZg0KMDAwMDAwMDY3MyA2NTUzNSBmDQowMDAwMDAwNjc0IDY1NTM1IGYNCjAwMDAw
MDA2NzUgNjU1MzUgZg0KMDAwMDAwMDY3NiA2NTUzNSBmDQowMDAwMDAwNjc3IDY1NTM1IGYNCjAw
MDAwMDA2NzggNjU1MzUgZg0KMDAwMDAwMDY3OSA2NTUzNSBmDQowMDAwMDAwNjgwIDY1NTM1IGYN
CjAwMDAwMDA2ODEgNjU1MzUgZg0KMDAwMDAwMDY4MiA2NTUzNSBmDQowMDAwMDAwNjgzIDY1NTM1
IGYNCjAwMDAwMDA2ODQgNjU1MzUgZg0KMDAwMDAwMDY4NSA2NTUzNSBmDQowMDAwMDAwNjg2IDY1
NTM1IGYNCjAwMDAwMDA2ODcgNjU1MzUgZg0KMDAwMDAwMDY4OCA2NTUzNSBmDQowMDAwMDAwNjg5
IDY1NTM1IGYNCjAwMDAwMDA2OTAgNjU1MzUgZg0KMDAwMDAwMDY5MSA2NTUzNSBmDQowMDAwMDAw
NjkyIDY1NTM1IGYNCjAwMDAwMDA2OTMgNjU1MzUgZg0KMDAwMDAwMDY5NCA2NTUzNSBmDQowMDAw
MDAwNjk1IDY1NTM1IGYNCjAwMDAwMDA2OTYgNjU1MzUgZg0KMDAwMDAwMDY5NyA2NTUzNSBmDQow
MDAwMDAwNjk4IDY1NTM1IGYNCjAwMDAwMDA2OTkgNjU1MzUgZg0KMDAwMDAwMDcwMCA2NTUzNSBm
DQowMDAwMDAwNzAxIDY1NTM1IGYNCjAwMDAwMDA3MDIgNjU1MzUgZg0KMDAwMDAwMDcwMyA2NTUz
NSBmDQowMDAwMDAwNzA0IDY1NTM1IGYNCjAwMDAwMDA3MDUgNjU1MzUgZg0KMDAwMDAwMDcwNiA2
NTUzNSBmDQowMDAwMDAwNzA3IDY1NTM1IGYNCjAwMDAwMDA3MDggNjU1MzUgZg0KMDAwMDAwMDcw
OSA2NTUzNSBmDQowMDAwMDAwNzEwIDY1NTM1IGYNCjAwMDAwMDA3MTEgNjU1MzUgZg0KMDAwMDAw
MDcxMiA2NTUzNSBmDQowMDAwMDAwNzEzIDY1NTM1IGYNCjAwMDAwMDA3MTQgNjU1MzUgZg0KMDAw
MDAwMDcxNSA2NTUzNSBmDQowMDAwMDAwNzE2IDY1NTM1IGYNCjAwMDAwMDA3MTcgNjU1MzUgZg0K
MDAwMDAwMDcxOCA2NTUzNSBmDQowMDAwMDAwNzE5IDY1NTM1IGYNCjAwMDAwMDA3MjAgNjU1MzUg
Zg0KMDAwMDAwMDcyMSA2NTUzNSBmDQowMDAwMDAwNzIyIDY1NTM1IGYNCjAwMDAwMDA3MjMgNjU1
MzUgZg0KMDAwMDAwMDcyNCA2NTUzNSBmDQowMDAwMDAwNzI1IDY1NTM1IGYNCjAwMDAwMDA3MjYg
NjU1MzUgZg0KMDAwMDAwMDcyNyA2NTUzNSBmDQowMDAwMDAwNzI4IDY1NTM1IGYNCjAwMDAwMDA3
MjkgNjU1MzUgZg0KMDAwMDAwMDczMCA2NTUzNSBmDQowMDAwMDAwNzMxIDY1NTM1IGYNCjAwMDAw
MDA3MzIgNjU1MzUgZg0KMDAwMDAwMDczMyA2NTUzNSBmDQowMDAwMDAwNzM0IDY1NTM1IGYNCjAw
MDAwMDA3MzUgNjU1MzUgZg0KMDAwMDAwMDczNiA2NTUzNSBmDQowMDAwMDAwNzM3IDY1NTM1IGYN
CjAwMDAwMDA3MzggNjU1MzUgZg0KMDAwMDAwMDczOSA2NTUzNSBmDQowMDAwMDAwNzQwIDY1NTM1
IGYNCjAwMDAwMDA3NDEgNjU1MzUgZg0KMDAwMDAwMDc0MiA2NTUzNSBmDQowMDAwMDAwNzQzIDY1
NTM1IGYNCjAwMDAwMDA3NDQgNjU1MzUgZg0KMDAwMDAwMDc0NSA2NTUzNSBmDQowMDAwMDAwNzQ2
IDY1NTM1IGYNCjAwMDAwMDA3NDcgNjU1MzUgZg0KMDAwMDAwMDc0OCA2NTUzNSBmDQowMDAwMDAw
NzQ5IDY1NTM1IGYNCjAwMDAwMDA3NTAgNjU1MzUgZg0KMDAwMDAwMDc1MSA2NTUzNSBmDQowMDAw
MDAwNzUyIDY1NTM1IGYNCjAwMDAwMDA3NTMgNjU1MzUgZg0KMDAwMDAwMDc1NCA2NTUzNSBmDQow
MDAwMDAwNzU1IDY1NTM1IGYNCjAwMDAwMDA3NTYgNjU1MzUgZg0KMDAwMDAwMDc1NyA2NTUzNSBm
DQowMDAwMDAwNzU4IDY1NTM1IGYNCjAwMDAwMDA3NTkgNjU1MzUgZg0KMDAwMDAwMDc2MCA2NTUz
NSBmDQowMDAwMDAwNzYxIDY1NTM1IGYNCjAwMDAwMDA3NjIgNjU1MzUgZg0KMDAwMDAwMDc2MyA2
NTUzNSBmDQowMDAwMDAwNzY0IDY1NTM1IGYNCjAwMDAwMDA3NjUgNjU1MzUgZg0KMDAwMDAwMDc2
NiA2NTUzNSBmDQowMDAwMDAwNzY3IDY1NTM1IGYNCjAwMDAwMDA3NjggNjU1MzUgZg0KMDAwMDAw
MDc2OSA2NTUzNSBmDQowMDAwMDAwNzcwIDY1NTM1IGYNCjAwMDAwMDA3NzEgNjU1MzUgZg0KMDAw
MDAwMDc3MiA2NTUzNSBmDQowMDAwMDAwNzczIDY1NTM1IGYNCjAwMDAwMDA3NzQgNjU1MzUgZg0K
MDAwMDAwMDc3NSA2NTUzNSBmDQowMDAwMDAwNzc2IDY1NTM1IGYNCjAwMDAwMDA3NzcgNjU1MzUg
Zg0KMDAwMDAwMDc3OCA2NTUzNSBmDQowMDAwMDAwNzc5IDY1NTM1IGYNCjAwMDAwMDA3ODAgNjU1
MzUgZg0KMDAwMDAwMDc4MSA2NTUzNSBmDQowMDAwMDAwNzgyIDY1NTM1IGYNCjAwMDAwMDA3ODMg
NjU1MzUgZg0KMDAwMDAwMDc4NCA2NTUzNSBmDQowMDAwMDAwNzg1IDY1NTM1IGYNCjAwMDAwMDA3
ODYgNjU1MzUgZg0KMDAwMDAwMDc4NyA2NTUzNSBmDQowMDAwMDAwNzg4IDY1NTM1IGYNCjAwMDAw
MDA3ODkgNjU1MzUgZg0KMDAwMDAwMDc5MCA2NTUzNSBmDQowMDAwMDAwNzkxIDY1NTM1IGYNCjAw
MDAwMDA3OTIgNjU1MzUgZg0KMDAwMDAwMDc5MyA2NTUzNSBmDQowMDAwMDAwNzk0IDY1NTM1IGYN
CjAwMDAwMDA3OTUgNjU1MzUgZg0KMDAwMDAwMDc5NiA2NTUzNSBmDQowMDAwMDAwNzk3IDY1NTM1
IGYNCjAwMDAwMDA3OTggNjU1MzUgZg0KMDAwMDAwMDc5OSA2NTUzNSBmDQowMDAwMDAwODAwIDY1
NTM1IGYNCjAwMDAwMDA4MDEgNjU1MzUgZg0KMDAwMDAwMDgwMiA2NTUzNSBmDQowMDAwMDAwODAz
IDY1NTM1IGYNCjAwMDAwMDA4MDQgNjU1MzUgZg0KMDAwMDAwMDgwNSA2NTUzNSBmDQowMDAwMDAw
ODA2IDY1NTM1IGYNCjAwMDAwMDA4MDcgNjU1MzUgZg0KMDAwMDAwMDgwOCA2NTUzNSBmDQowMDAw
MDAwODA5IDY1NTM1IGYNCjAwMDAwMDA4MTAgNjU1MzUgZg0KMDAwMDAwMDgxMSA2NTUzNSBmDQow
MDAwMDAwODEyIDY1NTM1IGYNCjAwMDAwMDA4MTMgNjU1MzUgZg0KMDAwMDAwMDgxNCA2NTUzNSBm
DQowMDAwMDAwODE1IDY1NTM1IGYNCjAwMDAwMDA4MTYgNjU1MzUgZg0KMDAwMDAwMDgxNyA2NTUz
NSBmDQowMDAwMDAwODE4IDY1NTM1IGYNCjAwMDAwMDA4MTkgNjU1MzUgZg0KMDAwMDAwMDgyMCA2
NTUzNSBmDQowMDAwMDAwODIxIDY1NTM1IGYNCjAwMDAwMDA4MjIgNjU1MzUgZg0KMDAwMDAwMDgy
MyA2NTUzNSBmDQowMDAwMDAwODI0IDY1NTM1IGYNCjAwMDAwMDA4MjUgNjU1MzUgZg0KMDAwMDAw
MDgyNiA2NTUzNSBmDQowMDAwMDAwODI3IDY1NTM1IGYNCjAwMDAwMDA4MjggNjU1MzUgZg0KMDAw
MDAwMDgyOSA2NTUzNSBmDQowMDAwMDAwODMwIDY1NTM1IGYNCjAwMDAwMDA4MzEgNjU1MzUgZg0K
MDAwMDAwMDgzMiA2NTUzNSBmDQowMDAwMDAwODMzIDY1NTM1IGYNCjAwMDAwMDA4MzQgNjU1MzUg
Zg0KMDAwMDAwMDgzNSA2NTUzNSBmDQowMDAwMDAwODM2IDY1NTM1IGYNCjAwMDAwMDA4MzcgNjU1
MzUgZg0KMDAwMDAwMDgzOCA2NTUzNSBmDQowMDAwMDAwODM5IDY1NTM1IGYNCjAwMDAwMDA4NDAg
NjU1MzUgZg0KMDAwMDAwMDg0MSA2NTUzNSBmDQowMDAwMDAwODQyIDY1NTM1IGYNCjAwMDAwMDA4
NDMgNjU1MzUgZg0KMDAwMDAwMDg0NCA2NTUzNSBmDQowMDAwMDAwODQ1IDY1NTM1IGYNCjAwMDAw
MDA4NDYgNjU1MzUgZg0KMDAwMDAwMDg0NyA2NTUzNSBmDQowMDAwMDAwODQ4IDY1NTM1IGYNCjAw
MDAwMDA4NDkgNjU1MzUgZg0KMDAwMDAwMDg1MCA2NTUzNSBmDQowMDAwMDAwODUxIDY1NTM1IGYN
CjAwMDAwMDA4NTIgNjU1MzUgZg0KMDAwMDAwMDg1MyA2NTUzNSBmDQowMDAwMDAwODU0IDY1NTM1
IGYNCjAwMDAwMDA4NTUgNjU1MzUgZg0KMDAwMDAwMDg1NiA2NTUzNSBmDQowMDAwMDAwODU3IDY1
NTM1IGYNCjAwMDAwMDA4NTggNjU1MzUgZg0KMDAwMDAwMDg1OSA2NTUzNSBmDQowMDAwMDAwODYw
IDY1NTM1IGYNCjAwMDAwMDA4NjEgNjU1MzUgZg0KMDAwMDAwMDg2MiA2NTUzNSBmDQowMDAwMDAw
ODYzIDY1NTM1IGYNCjAwMDAwMDA4NjQgNjU1MzUgZg0KMDAwMDAwMDg2NSA2NTUzNSBmDQowMDAw
MDAwODY2IDY1NTM1IGYNCjAwMDAwMDA4NjcgNjU1MzUgZg0KMDAwMDAwMDg2OCA2NTUzNSBmDQow
MDAwMDAwODY5IDY1NTM1IGYNCjAwMDAwMDA4NzAgNjU1MzUgZg0KMDAwMDAwMDg3MSA2NTUzNSBm
DQowMDAwMDAwODcyIDY1NTM1IGYNCjAwMDAwMDA4NzMgNjU1MzUgZg0KMDAwMDAwMDg3NCA2NTUz
NSBmDQowMDAwMDAwODc1IDY1NTM1IGYNCjAwMDAwMDA4NzYgNjU1MzUgZg0KMDAwMDAwMDg3NyA2
NTUzNSBmDQowMDAwMDAwODc4IDY1NTM1IGYNCjAwMDAwMDA4NzkgNjU1MzUgZg0KMDAwMDAwMDg4
MCA2NTUzNSBmDQowMDAwMDAwODgxIDY1NTM1IGYNCjAwMDAwMDA4ODIgNjU1MzUgZg0KMDAwMDAw
MDg4MyA2NTUzNSBmDQowMDAwMDAwODg0IDY1NTM1IGYNCjAwMDAwMDA4ODUgNjU1MzUgZg0KMDAw
MDAwMDg4NiA2NTUzNSBmDQowMDAwMDAwODg3IDY1NTM1IGYNCjAwMDAwMDA4ODggNjU1MzUgZg0K
MDAwMDAwMDg4OSA2NTUzNSBmDQowMDAwMDAwODkwIDY1NTM1IGYNCjAwMDAwMDA4OTEgNjU1MzUg
Zg0KMDAwMDAwMDg5MiA2NTUzNSBmDQowMDAwMDAwODkzIDY1NTM1IGYNCjAwMDAwMDA4OTQgNjU1
MzUgZg0KMDAwMDAwMDg5NSA2NTUzNSBmDQowMDAwMDAwODk2IDY1NTM1IGYNCjAwMDAwMDA4OTcg
NjU1MzUgZg0KMDAwMDAwMDg5OCA2NTUzNSBmDQowMDAwMDAwODk5IDY1NTM1IGYNCjAwMDAwMDA5
MDAgNjU1MzUgZg0KMDAwMDAwMDkwMSA2NTUzNSBmDQowMDAwMDAwOTAyIDY1NTM1IGYNCjAwMDAw
MDA5MDMgNjU1MzUgZg0KMDAwMDAwMDkwNCA2NTUzNSBmDQowMDAwMDAwOTA1IDY1NTM1IGYNCjAw
MDAwMDA5MDYgNjU1MzUgZg0KMDAwMDAwMDkwNyA2NTUzNSBmDQowMDAwMDAwOTA4IDY1NTM1IGYN
CjAwMDAwMDA5MDkgNjU1MzUgZg0KMDAwMDAwMDkxMCA2NTUzNSBmDQowMDAwMDAwOTExIDY1NTM1
IGYNCjAwMDAwMDA5MTIgNjU1MzUgZg0KMDAwMDAwMDkxMyA2NTUzNSBmDQowMDAwMDAwOTE0IDY1
NTM1IGYNCjAwMDAwMDA5MTUgNjU1MzUgZg0KMDAwMDAwMDkxNiA2NTUzNSBmDQowMDAwMDAwOTE3
IDY1NTM1IGYNCjAwMDAwMDA5MTggNjU1MzUgZg0KMDAwMDAwMDkxOSA2NTUzNSBmDQowMDAwMDAw
OTIwIDY1NTM1IGYNCjAwMDAwMDA5MjEgNjU1MzUgZg0KMDAwMDAwMDkyMiA2NTUzNSBmDQowMDAw
MDAwOTIzIDY1NTM1IGYNCjAwMDAwMDA5MjQgNjU1MzUgZg0KMDAwMDAwMDkyNSA2NTUzNSBmDQow
MDAwMDAwOTI2IDY1NTM1IGYNCjAwMDAwMDA5MjcgNjU1MzUgZg0KMDAwMDAwMDkyOCA2NTUzNSBm
DQowMDAwMDAwOTI5IDY1NTM1IGYNCjAwMDAwMDA5MzAgNjU1MzUgZg0KMDAwMDAwMDkzMSA2NTUz
NSBmDQowMDAwMDAwOTMyIDY1NTM1IGYNCjAwMDAwMDA5MzMgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMTYwMjI5IDAwMDAwIG4NCjAwMDAxNjA1NTkgMDAwMDAgbg0KMDAwMDE4MTEy
NiAwMDAwMCBuDQowMDAwMTgxNTQ1IDAwMDAwIG4NCjAwMDAyMDg1NjMgMDAwMDAgbg0KMDAwMDIw
ODk5NCAwMDAwMCBuDQowMDAwMjA5MzU1IDAwMDAwIG4NCjAwMDAyMDk1NTcgMDAwMDAgbg0KMDAw
MDIyMTY0OCAwMDAwMCBuDQowMDAwMjIxOTQ5IDAwMDAwIG4NCjAwMDAyMzUxOTQgMDAwMDAgbg0K
MDAwMDIzNTIzOCAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDk0Ni9Sb290IDEgMCBSL0luZm8g
NzcgMCBSL0lEWzw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz48OEMxMjM5OUY3OUZC
RUI0NkI3NTg1QURGM0Q5NDU2NTM+XSA+Pg0Kc3RhcnR4cmVmDQoyMzczNTkNCiUlRU9GDQp4cmVm
DQowIDANCnRyYWlsZXINCjw8L1NpemUgOTQ2L1Jvb3QgMSAwIFIvSW5mbyA3NyAwIFIvSURbPDhD
MTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYz
RDk0NTY1Mz5dIC9QcmV2IDIzNzM1OS9YUmVmU3RtIDIzNTIzOD4+DQpzdGFydHhyZWYNCjI1NjQz
OQ0KJSVFT0Y=

--_002_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Jun 27 03:52:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 03:52: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 1SjjIY-0006To-SI; Wed, 27 Jun 2012 03:52:10 +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 1SjjIW-0006Tj-FJ
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 03:52:09 +0000
Received: from [85.158.139.83:59293] by server-11.bemta-5.messagelabs.com id
	51/9C-20400-7638AEF4; Wed, 27 Jun 2012 03:52:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340769121!28988428!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMzAwMzg0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14830 invoked from network); 27 Jun 2012 03:52:02 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 03:52:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Jun 2012 20:52:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="pdf'?scan'208";a="116396146"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Jun 2012 20:51:59 -0700
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; Tue, 26 Jun 2012 20:51:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Wed, 27 Jun 2012 11:51:54 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>, "Auld, Will"
	<will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: Ac1UGDBj1l9vq4iTRyWE8p2SJy8j9w==
Date: Wed, 27 Jun 2012 03:51:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233525D395@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_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>,
	"Jiang, Yunhong" <yunhong.jiang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

This is updated xen vMCE design foils, according to comments from community=
 recently.

This foils focus on vMCE part of Xen MCA, so as Keir said, it's some dense.
Later Will will present a document to elaborate more, including Intel MCA a=
nd surrounding features and Xen implementation.

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_
Content-Type: application/pdf; name="xen vMCE design (v0 2).pdf"
Content-Description: xen vMCE design (v0 2).pdf
Content-Disposition: attachment; filename="xen vMCE design (v0 2).pdf";
	size=256622; creation-date="Wed, 27 Jun 2012 03:21:05 GMT";
	modification-date="Wed, 27 Jun 2012 03:18:50 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDc4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDE0L0tpZHNbIDMgMCBSIDE0
IDAgUiA0MSAwIFIgNTQgMCBSIDU2IDAgUiA1OCAwIFIgNjAgMCBSIDYyIDAgUiA2NSAwIFIgNjcg
MCBSIDY5IDAgUiA3MSAwIFIgNzMgMCBSIDc1IDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv
SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRz
IDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9U
YWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA2NDA+Pg0Kc3RyZWFtDQp4nKWU32/aMBDH3yPlf7hHpyqOzz9jCVVdoauK
WqnbkLqp2gNqKU0FQStj0/77nU0oBAJ72EOc5GLf9/s5nwP5HXS7+W3vug/i7Awu+j34kSYCBBdC
oJTCgZMCjBbwNk6T+xOo6DMXCjXNUc7SaI2Ht8n7KiEsCt1Y9nySJp/SBC5vewBbkrgn2bJ4penQ
c2eApoFR60cuDS2Ax1ma5Nez0WRsoD+HNiW5UerUQgK9qzkLhdiiacRaUnuO0oBCXlDEx0VbsvaQ
rNqXNQb9cVntiGtFasBGYR1ItxXdIUW9r2gLbVeKUmtsKy4K9V5cERGt8MGEi+ob2eKQrMlvRtUE
2OuoM7jLag8XQ1r3EaHgtKXDZ9KJEkgiiheK4tpJGM5CR1lfAPVQfvWFajJZrENXafLAZNbRTIQB
wxBfc5vT3TCXfYfhIE0uhy2u7JaRd21juJRb2g8MjuVwh8jWCbVDTsek4MqsE+KxhEVrDrsqyCbH
UVO+UWEJSu6WWKLhgj4o6mFf17j91O6HP8eqfx1XkGn267Z3Cf3xopxkilVbphr+PflvqP0DAMUO
Adn1xQ4C9aA3gB65UnXSmzIzbHmaWUrfQcMG9FqSy2pBD3PaJ4pq1n0tKwou5mGccBqmdJVZR7Hl
+fqp+klZxlMeuulxHnppdnYAz5AT3TRynA5b6GwDDh39xOhmNdemzjmI1hSjfjslECnYt2X1sqH6
EwGqF5pGQf5ajiLfeRkQCEezccCYhmmc8jyGOJF5NqO3g3D0OzW66eQ4nWzpYCld5FGOG1dn+bCc
0q48RRZk9zRGvGl9Ubhg3d+74eB8tAwb9vSfZJo2jM5Tw9Me2V+R5XLyDQplbmRzdHJlYW0NCmVu
ZG9iag0KNSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTAyNC9I
ZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIv
RENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4NzExPj4NCnN0cmVhbQ0K/9j/4AAQ
SkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDxD/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPx
D/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi
688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/z
M9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/n
z0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/
EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+
Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH
1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+
fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0
f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+
pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQ
fW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4X
H4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAX
R/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/
9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPq
lD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDh
cfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/
Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+e
l/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+
qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoPAopD0oA27uLR7BoYZbK6mkaGORnF
wFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2FzeJNJDC7QwKHmkVciNc4yfasopct2
/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCxqVL3RtPH+j6edQmH/La8Yqn4Iv8A
U1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx10y7H/b0P/iaVU0e8bZG1xYyn7rTM
JIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIsNX0O41bTbQ2F3aKr3diG3IY26SJ3
A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVpXjfaNC0+4c5ljZ7fd3KjBX8skVm1
vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOldZa6BoekwR3XiXUt0joHTT7I75CD
yNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibUlDiw+zRn+O5YJx9OtW2+IR02MweG
tGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS9dX/AF8zRKjHdt+mh1y/DCG2XOqe
J9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR7Gq96j+5Fe2pLamvvZ6UvgLwjdfL
aeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2OqX2mTCSxvZ7Zwesbkfp0NS6VZfDP7
0Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6qF0bxVDDLFN8guCo2k9t47fUVheP/
AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2lJ3XXujiKKKK6jlCiiigAooooAKKK
KACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW1v4PFXlxlLextBHaqrFcKHxk4PzE
9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrSXmi6kpJe3G8hCclHXqCDXHPom7bW
+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq5f6bp2ta/aRX1pERY6LHdM7SMBNx
gK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X3MliLM30r2a7ICkGSFIxtJxyPrWb
oVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjADBUtzg1z+jW8nh/wVq2qX4MTanCLW
zhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOfevPb7ULvUZEa7uZJzEgjj3HhUHAA
HYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfWjJ/yLVt/19Sf+gis6u2PU459Aooo
qiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmmc4VcdF+p9KrWFlPqWoW9lbLumnkE
aD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+RrTppxc5bL8xNMt/Bj+BZJb2WAa75
UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBYEE4OaX4X6bplx4Qu7q8sLe5aOdzu
kiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw9/wk+urppuTb7o2fzAu7p2xXp/h7
WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+RHC7RgnJClQcfhVSxbcZRs4ySuTHC
pSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/EfVNMvL6Xw/DpedYmeJVuti9yMDPWr
t1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VOcrSSivw8jxgEEcV6tp3h/SJPhFJq
b6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L95WA4z71c0r/AJIdL/16Sf8AoRrO
tiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1r1bQpT4q+Ec8F388sUMkW48klBlT
/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb30IwcnKUr7W1PER0FLSDpzS16BwBR
RRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SXUaMPlHUEg0aTqGr6HIX03WLW3z95
Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMxs64DV4k8fNXhyppHuQwEHafM02e/
J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/mWNeBx2F1LaG6SB2gEgj3gcFiM4Hv
iq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/Ddiqn2Fs/8fWn/wDgdF/8VXleKOK2
WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1JrKqn4Z/5ExP+v5//AEAVcr1cLUdS
kpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E9mtz4zEzjP2aBpF+p4/qa5nxFcvd
+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3RpNG8XXqMuIrhzPC3YqxyfyOa5Iu2
Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+gCvO9J8ZajpWg3miqkc1ncoy7X4M
ZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZXOiGJpqUG+isaHwk/wCR3P8A17Sf
zFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOPT6VLf+K9QvPFP/CQRBLW8BUqI+VG
Bjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2aywMZih2Y6deldv431y80SO2ubfQY
9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOehqfQvinrOj2SWk8MV9FGNqNISrgdh
kdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8JrbWE4aHzdxUAsMZxj9a0tJIPwOlw
c4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXifV7XR7nQLVftFtdgoIdhZlJ6lcVX1
WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU+i8fjT/id4xh1ORdD02QPaQNmeRf
uu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVfa1XtsjGVeMaXs6a33YUUUV1nIFFF
FABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVrxappEkVvc3t/ZvrDQmOO5WFmRfkA
VpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8AhBPEf/Pin/gRH/8AFV8xUhLnenU+
npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4BfccehqG21TwubWF74W0l/5ZkkkEBwJIid
ijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8VWfJLsXzx7o3n1vQ7bRP3E8Mt8sD
i3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gDKflAwWyepqr/AMIJ4i/58U/8CY//
AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6AKuUabpd3o/heK1vkWOdrt3CCRWO
3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBNZ3c1hewXdu22aBw
6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3Y3EkE6dHQ4/A+ormxGH9raUXaS2Z
0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOUmikiYdVkUqf1r0/RfjHNEqxa1Yeb
jgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09KkL+aOj6vh6mtOdvJngG4eoo3D1FfQ
4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoYJrhtsMMkh9EQt/Kt3T/AviXUyPJ0
qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWVnd3TdiwEY/Wl9bxE/gp/f/SD6rQh
8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0pzI34nk/QV5fqvxY8QXytHZrBYRn
vGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo/wAKN33Yy4YPczOpyrOzA+xNR0UV
6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJgelGB6UtFACYHpRgelLRQAmAKWii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6ClooAKKKKACiiigAooooAKKKKACi
iigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1
YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDcy
OT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
cwBjAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8Aq2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/o
KVz1fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir
9lHz+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRu
AiKST+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf
+b/4qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v
/wCTGnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD
0SZdhP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1x
NpV633IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTN
ZSn70kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2
ELj/ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP
3QW4A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHL
fxE9OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvb
ue4cnJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+
ZcqddtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy
/P8AQ4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQ
HFzaTAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6T
SatcqMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8
ia77wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaar
eW6/dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0
NjE1ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvB
Py/I5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+Rrp
tW8eDWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr
/o/COQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1
haNbyWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuP
Dlr43k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8A
ErQb6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzC
ZG05llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5
PqeufWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4
HtvCVlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/I
x6Z/19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3
h8KMJ/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVn
TScWn3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2Y
Pn8Ov6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7W
hW1qqz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41W
OPl0a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j
/px+taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+
EYVvNVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVy
x/M1FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxIN
d/5GHUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzu
H0rnv+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O
/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9
/wCH/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/
9A/xF/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvM
aKPrlf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNe
Q1r+FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0k
PhR87P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54
c8I+GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+w
zXovhXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNh
bacTMzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeG
rLWhZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dv
rGCaWOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u
5ma9R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+
Ho8adbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1Zt
LXRblr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rm
nR6Xdardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/
AK/4P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0X
Xv8AkYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm
7+HOhC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy9
52/lSRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRn
g05Z5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7e
lKZ5TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHp
mmxSyQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5
HHRP+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19
S/8AoZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f
/wDf9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmf
ib/oO3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//
AH/aiij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCE
z8Tf9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDIwMC9IZWlnaHQgOTgvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNTQ5ND4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBASwBLAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
YgDIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8A4yiiivrT5IKKKKBhRRRQAUUmaWgAooooAKKKKACijNFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRWt4a/5GC1/4H/6AaP+El1f/n7/APIaf4Vw1MRX9u6NGCdkm25NbuS6Rl/KdlOhR9iqtWbV
21pFPZJ9ZLuZNXLDSrvUi/2aPcE+8ScCrX/CS6v/AM/f/kNP8Ks2niy/gLfaNtwCOMgJj8hWGJq5
mqTdGnDm/wATf4OMfzRtQp5e6iVWpLl/wpf+3S/Iw5YngleKRSrodrKexrovDcVrZ6JrXiG5tYrt
7BYo7eCYbo2kkbAZh3A64NYF3cveXUlxJjfI2TjoK6Pw3C2reFPEmh2w3X8whubeLPMojbLKB3OO
cV11XP2Cc9Hpe34nNSUPbNQ1Wtv0LOgau/jWa70bVrKy82S2kltLmC3WJ4pEG4DKgZU4OQaz7fwi
xsbG4vNb0mye+iWW3inlYMynoThcDmrvgzTr3Q72713VLOezsrG0m3PcRmPe7KVVFyOWJNQ+J9G1
LVNL8I/YtPurkHSIk3RRMy7sngkDA6j865udwqcsHZHTyKdPmmrsq2/g/U31K/s7trexXT8G7uLm
TbHGD93nvkdMdaLjwleLLp/2O6s7+2v5/s8NzbyZQSf3WyAVPfp0rutYkiurXxFpsemprN3ZrZef
ZrK4LbUwxBQhm2nqBWJod1fw3Gh2K+E20bTZdZhl8x2lO6XBHHmEnoD09KSxdRq/9bfeN4Smnb+t
/uMk+CJpHuLaz1rSbzULdWaSzhmYudvULlQCR6fWs/wiumz+K9Nj1Up9heXEm84UnB2g+27FbHgx
f+L1hu/2y8/9AlrjtLsLnVJktLSB57hwSkaDJOAScD6Amt4TnJShJ9N/W5hOEIuMorr+VjqfEGve
IbC4utK1jRtMhV1ZI0+woAqkEBomGOnY5PQVXs/CU0mnWt5farpmmLdjNsl5MVaQdA2ADhfc1t+G
4dbubC+0XxJZXJ0OC1kl868hZTZsq5Uo7DI5GNv9M1n+LtJ1DXf+Ee1DTLK4vLSXSoIUe3jZwjrk
MhwOCDWMajg+RWXmbSpqa53d+Rn3HhXUbO31qW68uJtJMPnITkuJWwpUjgjvUWn+HrvU9LjvreSL
El9HYpGxIJkfoemMc13esxyX+meKdFtAbjUrfTNMjkhi+di0blpMY64BFZvhmxvbDwvpa3lpcWzP
4ns2UTRshYcDIz1HWmsXPkb63X5ITwkOdLpZ/mY7+CZzff2ba6tpt3qYkMclrBIxMeM7ixKgALjm
ql14aMbwxWGr6Zqc8sywCC0mJfefQEDK+44rZ0IBvip4otgwWe7OoQQZOMyMzYGe3Q1neCtKvtE8
Y6VeapYXNpbpdeU0s8LIodlIAyRjrTVepq29lf1E6FPRJdbeg6fwVcILiK21XS7y/tkLzWUE5Mqh
fvYyAGI7gGuYDBhxXeWj6joniea4sPh4yX1u8n7/AM24ZMEEFssxQggnnpzXn8AITmtsNVnNvm/r
7jHEUoQS5SWiiius5QooooAKKKKANbw1/wAjBa/8D/8AQDWTWt4a/wCRgtf+B/8AoBrJrhp/79U/
wQ/Oodk/9zp/4p/lAKdHFJNII4o3kc9FRck/gKbWjoWu3PhvV4tTtYYpZYlYBJM7TkEdj712TbUW
0tTlgk5JPYr/ANnX3/Plc/8Aflv8Ka1hqEJE6W11E0fzCQRspX3zjivavhz471Lxjd6jFfWdtbi2
RGQw7vm3E9ck+lcXrfxb12e71XRk0uyMZkmtFYBy5GSmevWvPWLqym4OH4noPCU4xU1P8DhL2/1T
U0Vb/Ury7RfuiedpAPpkmtrWPFd5NY6NZ6RqGoWiWlglvcJHM0au4Jzwp5GD3rUsfhZ4pubNZnt4
ICy5Ec0uH/IA4P1rm9V0e+0K+NnqVq1vOBuAYghh6gjgitkqFRpRa0MG69NNyT1KFu1zaXAube5m
huASfNjkKvk+45q7DJrusapb+XeaheagpzAfOd5AQM5U5yMYzx6V0GjfDvxFrdkl5Bbxw28g3Rvc
Ps3j1AwTj3xWr4U8Oap4Z+J+iW+pwqhmE7RsjhlcCJ89Pw60VKlFKXK02kx06dZtcyaTZxE0WqaN
qrGZruz1FDuLlmSUFhyc9eQTz71UiDwkNG7I6nKspwQfY16r4z8AeIfEPje9v7OGFbNkjVJJZQu4
hADgDJ6+orgvEHhzVPDN0kGpwCPzBmORW3I4HXB/p1p0K9Oolqr9ia9GpTb3t3M+71PWNQgFvear
fXEA6RzXDuo/AnFNs73U9NieKw1K8tY3++kE7IG+oB5rsbb4WeKbhAz20FvntLOM/wDjuazNf8Ea
74bt/tN9bK1tkKZoX3qpPr3H4imp4dvlTQOGIS5mmc3bvdWdz9qtrqeC5Bz5sUhV/fkc1NPf6rdz
xz3WqXs0sTh45JLhmZGHQgk8EetaeheGdW8STOmmWpkWP/WSMwVE+pPf2rU1j4deI9Fs3u5raOeC
MbpGt5NxQepHBx9KcnQUuVtXJiq7jzJOxgW+jaxqME+qQWt5crG7PNdKGbDj5mJb15yT71Xu7/U9
SRUvtRvLpE+6s87OF+mTxXq3w7fPwp8RsD0kucf9+Erzfwz4b1fxLuTTbUyCPHmSMwVE+pPf261l
CrCU5KaSUeprOlNQi43bkVJNU1ia1FpLq19JagY8l7hymP8Adziq6rtGK6zWPh14j0Wze7mto54I
xudreTcUHqRwcfSsHStLvtbvUs9OtnuJ2Gdq9h6k9APc10U50uVyg1YwqRq3UZp3KdFdyfhN4oEe
8LZk/wBwT8/yx+tUrL4c+Ib2/u7Ex20FzaqjOksw5V87WBXII+U0vrNH+ZB9Wrfys5OinvDJHdPb
Mh85JDGyd9wOMfnW54k8H6n4Vht5dRe2xcMVjWKQsTgZPYeo/OtHUgmk3uQqc2m0tjAoooqyDW8N
f8jBa/8AA/8A0A1k1reGv+Rgtf8Agf8A6Aaya4af+/VP8EPzqHZP/c6f+Kf5QCiiiu44z1D4KD/i
Y6z/ANcov5tWH4GtIbv4wXQlUMIru5lUEfxBmx+ROfwrc+Cp/wCJlrP/AFyi/m1choWvReG/ibda
lcAm2F9cRzEDJCMzDI+nB/CvJqJutVS7foetTaVGm33/AFPQ/F3h74h6t4me60fWI7PTotot4o7p
o84AyXUDDEnPXPGKl+I+mte+H/DcmprH9vF9bwTtH93MgxIAfTIH5VR8SfDkeMdXfxBoXiJBBdhS
6BiybgoGVKnuAMj1zXE+KfC8fgibTZ/7dXUtQS5ErW4OPL2YIJG4nr3IFctJXceV6ryOmq7KV1o/
M6r40a1qdje6TpmnXk1nbtE0j/Z3MZY5AAOOwx096534e6jqmo/EXQRqN/cXfkCcRmeQuVBifIye
e1d54l8OWHxPstO1fRtUijlhQqQw3fK2DtYA5VgQfzrB0XwxD4T+KHh20GqR3lxKs7Sqi7fKxE2M
jJPOfbpWtKVL2Di/iszKrGr7ZSXw3RjfFPXNci8e3Vla6ve29rDHEY4oZ2RQSgJOARk5J5roviRL
JefCDQL+5bzLpvs0jSHqWaE7j+Jrkvilz8SNR/65Q/8AosV1XxBOfgj4fxz8tn/6JNHKowpSW4KT
lOpFlr423+oWVpoq2F9c2olklEnkTMm/AXGcHml8FXd3rHwg16PVbiS7MIuIkeZizbRErDk8nBJx
+HpUHxyIMGg45/eTfySnfDw4+E/iT/fuf/RCVmor6spdbmjk/rLj0sLDqE/hn4Cw3+lt5V3OinzR
1DSSYLfUDgfQVT+DviLWr/Wr3TNT1C4vYGtTOpuZDIyMGVcAnJwQ/T2qXwVd6X41+Gv/AAh95dpa
38K7EB+8wDbkdRxuxwCB+ma1fDnhnT/hjBea1rerQtI0RiQKu35cgkKCcsxIHA9KHycs1P4m9AXN
zQcPhS1HeHLWKx8H+PLSAbYYdQvkjUfwr5K4H4Cs63vp/C/wDgvdKbyruZFPmjqGkkwW+oHA+gqX
wRqLat8O/GepSLsa7vL2fb/dDQqQPw6VU8FXel+Nfhr/AMIfeXaWt/CuxAfvMA25HUcbscAgfpmo
s9XLurl3WnL2diL4O+I9a1DWr3TNTv7i9ga1M6m5kMjIwZVwCecEP09q2/Atnb6LJ41uraJc2t7L
HEpHREBYL9Pm/Sk8OeGdP+GMF5rWt6tCztEYk2jb8uQSFBOWYkDgelYPw18X2V5q3iGz1aRLZdYu
HuId7BRl8hkz64K4+hq6lpOTpfDoRTvFRVX4tTl/BGva9qHjzSpbzWL6UT3I8xGuG2sDnjbnGPbp
XpVxq50/47xWjviG+0xYeem8FmU/+Okf8CrO8PfCa+0PxNaX41K2ls7abzEG1g7L2BHQH8a574pX
smm/FOy1CHPmW0EEq4OMlXY4qpKnVqKNPsTF1KdNyqdyxc+Hifjr9i2ZhluVvvYrje2f+BAiqnxh
1U33jaHTkbMen24DD0d/mP8A47sr12HT9Ovddt/F0M8bp/Z5gVxyChYPuz7fMPxr5wv9RbWtf1DV
X/5erh5FHopPA/AYH4VphW6tWN/sozxSVKnK32mMooor2TxzW8Nf8jBa/wDA/wD0A1k1reGv+Rgt
f+B/+gGj/hGtX/59P/Iif415UsVQoY6ftpqN4QtdpdZ9z0o4atWwcPZQcrSlsm+kOxk0Vrf8I1q/
/Pp/5ET/ABo/4RrV/wDn0/8AIif41v8A2pgf+f0P/Al/mY/2djP+fUv/AAF/5GJNCso5ojhVE29q
2/8AhGtX/wCfT/yIn+NH/CNav/z6f+RE/wAaX9pYC9/bQ/8AAl/mP6hjbW9lL/wF/wCRg/ZijExS
PHnrtYjNJFaJF0rf/wCEa1f/AJ9P/Iif40f8I1q//Pp/5ET/ABqf7Qy+9/bQ/wDAl/mV9Sx1reyl
/wCAv/IwjbkOXjdkYjGVODTFs1AOeSeuTXRR+GNVeRVa3CKTgsZFIHvwabrGhS6SsbmUSxvxkDGD
9KUcwwE6ypQqRcpbWd/xWgSwWNhSdScGorurfnqYcVuI+FHJ7VqzeCtdS1N7Jo16INu4sYTwPUjr
itf4fQxTeNbIyoHWFZJwrDgsqEr+RwfwrnDrGr3d5LeyajdefKSXcTMCc9RwenPSumbfPyRWxjBL
k55PcqR2yK+4UslushBNdRY6Zo2neGodb11ryVbmZoba2tSqltv3mZmB47YFM1fRbKFtFvNNnnbT
NXz5PngeZGyuEdTjg4JHNCq078gnSqW5jmmtUZcelMa03uHldnYDALNk16E2jeEF8WN4WJ1lbsy+
Qt2ZIynmHp8uPu5/Gk+H6abb+Lp9PvrWWW+h89FkVx5YCqQQVI68HBzWcq1NxcuXY0jRqKSjfc4B
7VGxxStaoygeneum0bTtH1/V7uWA3djo1laNdXBkZZJdq9QpAAySeKkksdB1jRNRv9BN/bz6cFkm
gu2VhJGTjcpUDBHcGr9tTvZoj2VS10zkmtN8geV2dgMAsc8V0PhpPC/2meHxOJ1tnQCKWHd8jZ77
eensa0EsfDul+FtH1bVY9SuZtTM+2O2lREQRvt5yCSTkfrXLv5cruUVhGWO0NyQO1CUKkXGGnmDc
6bUp6+R6Zpdt8L/DuowavD4ku7h7U+ZDBJIXVTjjCqgOfqayjq3hLxz4t1bUPEF9c6bbhIotPwdp
ZBu3FjtYA5wce/euD+yx5zinGFCMY4rGOCafNzO5vLGprl5dD0nVPEvhPwn4Kv8AQvCl7Je3eobg
8p5KhgFLM2APu8ADvXmlvH5cQFKtvGhyBUtb4fD+yu27tnPXxHtbJKyQUUUV0nOFFFFAgooooGFF
FFABRRRQA+KV4JVliYq6HKkdjVm+1S71EobmXcEHygDA/SqdFZyoUpVFVlFOS2dtUaRrVIwdNSfK
910Zr+FtYh0HxNZ6hcqzWylo5gvXYylSfwzn8KsTeFbG3WaeHxToslkAWiPnnzmHYGMDIb9K58jI
qPyFzmonSlz88XYqFSPJySVzutD1y5ufBttpel+I7fRdRs7iRmFzL5STxtzneQRkHtWRrVzevrGk
rqXia31h4ZQxaFy8cALLn5yADnHb0rnWiVhyKFhVRWawtpuRq8TeKiddNe2Z+Mn9oC6gNp/aSv8A
aBIDHtyOd2cY96b4Z1KxtfibdXdxdRRWss10qzs3yDeHCkn0ORz71ygjUCjy1xij6srWv0sL6y73
t1udX4SuY/Cut39jcatawNe2LQx39rKJo4JDgqxK8Y459Min6zc66mjXKaj46sL6ORdq2lrcmczc
jg4XCjvz6VyAhUDGKQQKDkCk8LeXM2NYm0eVHQa3dW0/gbwhax3EUk9v9s86JXBaPdKCu4dRkcjN
YYGBTRGM5p9dFKnyKxhVqc7uFFFFaGYUUUUAFFFFABRRRQIKKKKBhRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2Jq
DQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FCQ0RFRStW
ZXJkYW5hLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDEwIDAg
Ui9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1dpZHRocyA5MzQgMCBSPj4NCmVuZG9iag0KMTAg
MCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK1ZlcmRhbmEsQm9s
ZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWln
aHQgNzY1L0F2Z1dpZHRoIDU2OC9NYXhXaWR0aCAyMjU3L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQg
MjUwL1N0ZW1WIDU2L0ZvbnRCQm94WyAtNTUwIC0yMDcgMTcwNyA3NjVdIC9Gb250RmlsZTIgOTM1
IDAgUj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvQ0Eg
MT4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1l
L0YyL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250
RGVzY3JpcHRvciAxMyAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgOTM5IDAg
Uj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FC
Q0RFRStWZXJkYW5hL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDEwMDUvRGVzY2VudCAt
MjA3L0NhcEhlaWdodCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDIwMDYvRm9udFdlaWdodCA0
MDAvWEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC01NjAgLTIwNyAxNDQ3IDc2NV0gL0Zv
bnRGaWxlMiA5MzcgMCBSPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTE2IDE2IDAgUi9J
bWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSL0ltYWdlMTcgMTcgMCBSL0ltYWdlMjggMjggMCBSPj4v
Rm9udDw8L0YyIDEyIDAgUi9GMSA5IDAgUi9GMyAzOSAwIFI+Pi9QYXR0ZXJuPDwvUDIwIDIwIDAg
Ui9QMzEgMzEgMCBSPj4vRXh0R1N0YXRlPDwvR1MyNyAyNyAwIFIvR1MzOCAzOCAwIFI+Pi9Qcm9j
U2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAg
NTQwXSAvQ29udGVudHMgMTUgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9D
Uy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4NCmVuZG9iag0KMTUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjY2NT4+DQpzdHJlYW0NCnicpVrbTxw3F39H
4n+w1JfZSgy+X6SqUksoTfUh0YQmldI+oO1yiRZIgfC1/31/x56Zndm1PTR9YMFnfa4+Vxt2eMa+
+ebw9Oj1K8a//ZZ9/+qI/bm/xxlvOedCSu6Yk5wZzdnDan/v/dfsDl+3XAmNPcpZfFoT2MPVgMW5
FVxP0C6/3t/7eX+PHZ8eMTZiKXZYZpATTydC6wzDNmZU/2crDRDY8nZ/7/D17cXVyrBX9yzHSW44
HXSMuAiu09MrITI8De9Z6tAKaZgSrQckRKQRW2FLfNUuX2NEqPPVDoolVQ2zkbMmVccsXYmj3uVo
vbaJo9Ra5KwruBqsy6OOlgcSwkXuG7a+xNZkDCytrjuSxaFqHdkKxVtjmTat10xYoPmxgYvq2o6v
IPn/H31TO0FeqRU+hRXszcn+3p4UnvQRTrVWMSV96z1xU0Ajgd5maLuO9vfnkOMHyYRk55cwVhKY
KS+JqRSqhXznt+XA2AWTTB8atvidnf+0v3d8nuHuR9y3WIrgW5dYzhAJFSJeQ6CXEBG8QsWGNryM
ipiYUzChcVZTi2rZSsskhy/IjuaP948L2zwtVMNOjxYHsjkeMRkLpIVtpZgi1wWSW+crXRvsRCC4
bSsD095u7P3r6g6SHLPFgW2+e1joZnmNj5un1fLp88OqIJwRcFA/JVQXbpQ5Ds8unp5WD3ds+Ygt
iKLHJYLn8OStdOzqEfnCM9C2cE+jx/lWksfHmLCGQsIFiU/vZQqJHbRcDAi9HQQ7p2bgjQFBi2+k
LsUBcaRkgFR5vsSpvi8YykrVajMmBjBh1K2VSz9czaQfLSTlnMgYqQDW0ZbykZIaaW+UfmQx7Qm7
bR6z7UPGtCCsBXl2Ovg/7smPb+HSvGAFQU7sp1h1A7iSuygxuIvyyV0cqhnlQJvSgKA0IIiVGXtP
yWtmsLNO5DNW8ltehNgXUFmZ1tScKJlPRfP9Uoo2jxItRrTmrNenyUICl4rqLzJ9YLfDSilPFlgT
wGYBtB+rawLItMPRjkjDRIBWA4of7UhYl7lGZtymbWpeNtwE+8jYB8Ui799hGfYH27MmtTJBd6Jo
tFPwjA6wjieYbaHEYKRtxyAboW2LJVXESqxgI2LS2pFT8ZkaPUMi51lSZoqKnXqWQD/l0VrAtFp+
UZ3+hUrQ6oEtBG8ekew/XSxXbCGpLOnmvvtZPy5Mw35rfjj97vB2SRG+WrhmfQ/o1cI3vy0KzqqC
bdHnjcSb8Vap6t6qA7o2aqKit9KKGh8pqPFZE8AMANkDuv3J73RQCYB62NGgLhRJRqf9IX3tKcgq
rtqXDjpqZelTouBEEQVV2+R++HMTBlrwrZUcwkGjJZTQNCKhNjue9ugIrcjRFweD/p0YpzDuVpuo
NTJkAZswNkqlHX0YG3StE/mNdKMdFZnsTMYxjik3ZAusNLd9qsCe6arb2eUaciZuBtQhoGgzTqH7
riKbqwa6BGtEaadziEGt9CjICw14GS0b2H62W5RoFSCTsqAYviiuKUxVs1rfX7FCcEqB84ScliIh
xebN3VPMBpcXqEDLUsMnvaM+ZoJZj+rw0klGxvFXuDigCR73y9iMl4ypcg08lSAUcuFNNGyt4naN
N0Mae0up7hKaU0d+8/BnKamhPVAT4jPqq011yautTfQfUhsNRzd6yWpxUDKjtkYB5CZJVvSaHbVf
v31T6jWQRowa05vTdCZ9KzQPSMwiCDoeSnbQnHqsBFiPALwDDCg94JpgLsLghzaSUUr0m2yHlXYE
1QEK+UDpaj7AUceoJlIYhamV0LHFeGnZrxLInqvJzaOo8hgu/kM2OHvHTj7Dq1ePVNZR7F1TSgvK
2pT3R9Fdn04VimbU86X5QNli9VTek5UkNMYvujmBN4xigYzeZ5EpdrL3DHrW5C4XSuhqcZQS7shV
Z/IQeQUuR/LuQpPBnzFGl4Z5p1vrxqTnzOXrUWV0LMzCx/7BONuv1qNVbG+Gnbqv+s4kgI+oXqRV
qvf9d7IWQGEmtxmfhikXg8DExUzjq/l2fZRbQ3lMwBLlARPgl4TDmxXK3CPFA6LhiQplKRoMZSZH
1mx979uE+Pdjj0kkbksTPzSVYYpdPWottqbJsDNyo7FQgm8i7XpxYJrnW7q3gVJFPZBGUa0k3WcM
1X5xIHRzR/gfFwe6IaMsnwhqGmrt70q0UKfg7hNada1yxUqh4SRdOFT0HZVPZNBnBouSNrqcoxDY
2kICt8H9Um0UPFPLKa26NirXcXAUHCgTm+hE5Pn1QqjmDan0c6mTQpZRcopW593Xq839Vz7sXLrq
7u6EBY6LfooRZ7YatD2kjaEPSw2t9NULZW1nm1qPQDRDUa62J8voCZ9RqAQOT8WujH7WN3elrlTY
eI4j6nO2dDOpK9qArsBfbIOdxn6auJBeAw1d6HKtrxvg0wVV3CuM4uS9+PPykubwG3xULIDj02Py
cxbIXaE7qpagQu8UfXTHfLm8p7B6pnz3wKJ4yyeKtpv7UmgJoiWmpKoCGV5uDNIc2A243Wozz+JY
soDNgKtcSDv6yRMmT4OaGlDUaEe55pk+SRueWvVuYE6r0cDMeRYwGvuDT4BUubt5Jw3/huv+u4oo
cmbWTtW3v93rVtRSx65YepMHbG73fEwBNFClVptoEECLAUWNdlREVXOlTdPFOCVRQ81bpa5/aL46
OSt1V9BFjGnMuZzODlLQCUTsJi2/O00tsGn+oppCQ2JBgBAvuybIdQnMTB6SOh5PZ3Kair2r3S+Y
+VQsfSqgyBh25kr69O2bWoMkTaASJrVufX8hTfPzar2idHG7ImQCPPxdLOamDVMCdXu5GZ+nHOh5
769Yja6ind1adTs7b0eykV4MqDFWez93sv+u4uS+mMC0kXRuXSj2K91fX2nDqUHeBQyhqE3sx6Xu
VdMm5Ys07BCK9nHe0XxGyrk3ge5BOd2mgpNAuqULigRYjwCuAwwoPeCaNvm0SQ1kZALYgUy3I2yw
cgJbPpc7YGWEDaJOUgms5A5Gb2g6PdQdlXwaEvMJsZc81Nn6I4JGC6H85DbAVa4TcsE4SyOXDWzu
GWHrfQqlBm72H+4Xfnx3Gnu1k890w2AqY0h06n9xuWBIKP0vLhes2upli8ZUcYdPtwPx7o1ul8uG
zFYKBKXBfMg96TXzQKxM9KKjs9LjnvauNWJM7UWOZ7aiY/eh1lIXi3RvWt0b8deFEs2q1LqhBG0j
1GXoa87o7W73fib/bKdMTCZgFtuyboVUy+kxQNBrsQzx2Tpau18sqUcKaXaLAGMU3RF2mP0KVGln
t0KGDOTwCQ+VB0m4o5oWS3qMSTwToJcnYY5kXcZ0VXhRtLlLJeoQDV1LWSLce//xVyXXRwVAmZ9s
rx/CdP5QmVDXcAT4q0T+Tg62W6h2j+1D836VegDBm4uHVfx9vSr+Rwi9oiFYN0zm5A6H/7u4u2LN
x4uDn84WW/nK76Yr1XoFuHZ9yFmM7lf9H1FiSd0Hpw9BH3F5aA8lTSyuJozLPSgY+k8HOWI5o5ET
JY02t4DwUgeKaviPHlmlmL3wxwgTLaHK/xb0D2jXEfsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNiAw
IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0Nv
bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0lu
dGVycG9sYXRlIHRydWUvTGVuZ3RoIDcyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA
/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0
NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEB
AAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci
cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpj
ZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI
ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgME
BQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkj
M1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ
2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooA//2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjE3IDAgb2JqDQo8
PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNzIxL0hlaWdodCAzNjMvQ29sb3JT
cGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJw
b2xhdGUgdHJ1ZS9TTWFzayAxOCAwIFIvTGVuZ3RoIDI5NDEyPj4NCnN0cmVhbQ0K/9j/4AAQSkZJ
RgABAQEAeAB4AAD/4QBaRXhpZgAATU0AKgAAAAgABQMBAAUAAAABAAAASgMDAAEAAAABAAAAAFEQ
AAEAAAABAQAAAFERAAQAAAABAAASdFESAAQAAAABAAASdAAAAAAAAYagAACxj//bAEMACAYGBwYF
CAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0
Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMv/AABEIAWsGuQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID
BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB
FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna
4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1
EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0
4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI
iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery
8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+ur+H2gWXiPxFJZ36sYFt2kwrEHO5R2/3q5Su/wDhB/yN
8/8A15t/6MjqoK8kTN2iz0EfB/wyRkLPj/ro3+NL/wAKe8M/3Z/+/jf411N1dzwShY32rtzjANQf
2jdf89f/AB0f4V1csexyc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+F
H9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR
/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf
2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9
o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/a
N1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2j
df8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3
X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1
/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf
89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/
AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z
1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8A
PX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX
/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9
f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/
AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/
8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8A
HR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x
0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAd
H+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR
/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f
4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+
FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/h
Ryx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4U
csewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FH
LHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRy
x7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucs
ewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLH
sHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7
BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsew
c0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsH
NPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7Bz
T7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0
+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNP
uc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7
nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5
zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc
7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO
/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv
/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/
AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8
Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8A
wp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp
7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDC
nvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/Cnv
DP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe
8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M
/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7w
z/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/
AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP
92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8A
dn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3
Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2
f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn
/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/
+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/
AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7
+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8A
v43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v4
3+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/
jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf
40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N
/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/j
R/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+
NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH
/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40
f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8
Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/
wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp
7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/C
nvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/Cnv
DP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke
8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M
/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7w
z/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/
AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP
92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8A
dn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3
Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2
f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn
/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/
+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/
AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7
+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8A
v43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v4
3+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/
jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf
410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N
/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/j
XRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+
NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+Nd
F/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf41
0X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X
9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXR
f2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2
jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/
aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN
1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o
3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X
/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jd
f89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf8
9f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/
z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1
/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jQPg94Zzytxj/rqf8a6L+0br/nr
/wCOj/CnJqF0zqvm9Tj7o/wo5Y9g5p9zxz4i/D+Hw2qahpXnPY5CTI/zGJj0bP8AdPTnocc8gDz2
vqu9jjuBNFOivFIpV1cZDKRggj0xXypWFWKT0OilNyVmFd/8IP8Akb5/+vNv/RkdcBXofweiLeKb
qXHC2pU/i6n+lTD4kVU+FnsOof69f93+pqpVi/Obgeyiqua6jjHUU3NGaQx1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1SQf6+P8A3h/Ooc1JAf8ASIv98fzp
gS65P9n0jUZ+R5dvI/HspNfL9fS3ir/kVtb/AOvKf/0Bq+aawrbo3obMK9S+C8YN9qsvdViUfjvP
9K8tr1X4Lf6/V/8Atj/KSop/Ei6vwM9KvTm6f2x/Kq9TXn/H2/4fyqCuo5RaKSikAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
SQf8fEX++P51FU1qM3UY980wIfFX/Ira3/15T/8AoDV8019K+LGC+FdaJOB9inH5oa+aqwrbo3ob
MK9U+C/+v1f/ALY/ykryuvWfgvFhNWm7M0S/kG/+KqKfxIur8DPRLz/j7f8AD+VQVJdnN1Ifeoa6
TlHUU2igY6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOqxZf8AH3H+P8qq1Ysv+PuP
8f5GgRl+PpzB4I1aQHGYgn/fTBf618717/8AEn/kQNT/AO2X/o1K8ArCt8R0UPhCvZ/g2gGgXsnd
rpl/JU/xrxivafg7/wAi3df9fb/+gR0qXxDrfCddcHNxJ/vGo806f/j4k/3j/OmV0HMLmjNJRQMX
NGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB
c0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKA
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzR
mkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXN
GaSigBc0ZpKKAFzRmkooAXNGaSigBc1Ysv8Aj7T8f5VWq1p4zdA+gNAmYXxJ/wCRA1P/ALZf+jUr
wCvfviUwHgHUgTyxiA9/3q14DWFb4joofCFe0fB7/kW7r/r7f/0COvF69u+EcPl+FJXx/rLl2/RR
/wCy0qXxDrfCdNOf9Ik/3z/Oo80srbpnPqxpma6DnHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc
0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM0
3NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmj
NNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZ
ozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
B2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2at6ef37f7h/mKpZq
5px/fv8A7h/mKEJnLfFibyvBoT/nrdRp+jN/SvDq9q+L/wDyKdr/ANfyf+i5K8Vrnq/EdNH4Qr3r
4YqF8EWZHVjIT/38cf0rwWve/hmf+KHsf+2n/o16dH4hVvhNItmjNNzRmtjAdmjNNzRmgB2aM03N
GaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZq3px/ft/uH+Yqlmr2mj55D7AU0D2OQ+L/APyKdr/1/J/6LkrxWvafjA4HhazTub1SPwR/8a8W
rnq/EdFH4Qr3r4af8iPY/wDbT/0Y9eC1794Bj+z+B7Af9M2f82Lf1p0fiFW+EtUU3NGa2MR1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1aGl9Zfw/
rWbmtHSj80n4f1poT2OD+MsxWz0iHPDySvj6BR/7NXkleq/Gf/mCf9t//adeVVzVPiZ00vgQV9De
GQE8F6eB/wA+UZ/8hg18819C+HD/AMUZYf8AXlH/AOixVUd2TW2QmaM0zNGa2MR+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmtHST80n4f1rLzWrpP3WPq39KEJ7Hn3xn/5gn/bf/2nXlVep/GZ1Mmix5+ZRMxHsdn+Bryy
uep8TOml8CCvoPw4ceDbD/ryj/8ARYr58r6H02P7L4YtYsY2WyJj6KBVUt2TW2RWzRmmZozWpiPz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD81saOcxt/vH+QrEzW1opzG/1P9KaE9jy/wCMMpbxFYw9ktN35uw/9lrzqvQP
i/8A8jZa/wDXin/oySvP655/Ezqp/Cgr6NmwulELwAAAPxr5yr6LuD/xLG/D/wBCq6XUit0MzNGa
ZmjNaGQ/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD8
0ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA
/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0
APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmj
NAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZ
ozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zp
maM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NG
aZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzW3of3H+p/pWDmt7RP9X9Qf501uKWx5Z8X/APkbLX/rxT/0ZJXn
9d78XJA/i+BR1SzRT/305/rXBVzT+JnTT+FBX0TcnGmN+H86+fbKLz7+2i/vyqv5kCvfr1tungeu
K0pdSKvQzM0ZqPNGasyJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM10W
h82+fQf1Nczmum0A5tG/z3NVHcUtjxn4mymTx3fKc/u0iUf98Kf61yNdV8Sf+R/1P/tl/wCikrla
5pfEzqh8KL+hc+INNz0+1Rf+hivcdRP+gx/7w/ka8O0L/kYNN/6+ov8A0MV7dqJ/0GP/AHh/I1pT
2ZnV3RnZozUeaM1ZmSZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZrpvD/
APx6t+H8zXK5rq9AGLZvov8AWnHcmWx4t8Sf+R/1P/tl/wCikrla6f4hyrN481Rl6BkX8RGoP8q5
iueXxM6ofCi/of8AyMGm/wDX1F/6EK9r1I4sox/tD+RrxvwxH5viXT1xnEob8uf6V7BqzYiiX3Na
U9mZ1N0Z2aM1Huo3VRBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJ
mjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma
M1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZrsNBH+gbvX
A/QVxe6u18PnOmD/AHv/AGUVUdyZ7HgXi2UzeMNYY9ReSr+TEf0rGrV8T/8AI2az/wBf0/8A6Mas
quZ7nVHZG74N/wCRrsc+r/8AoDV6pq5/1P8AwL+leVeDv+Rqsv8Agf8A6A1epawf9T/wL+la0/hM
qnxGfmjNR7qN1USSZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozU
e6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7
qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma7fw9/yDP+Bf8A
sorhN1d5oAI09v8ArocfkKqO5E9j5+8T/wDI2az/ANf0/wD6MasqtHxBKJ/EmqSjGJLyVhj3cms6
uZ7nUtjc8HDPiqy+r/8AoDV6frDf6n/gX9K848DR7/Esbf3I2b+Q/rXoOrt++jX0XP61rD4TKfxF
HNGaZmjNMkfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0
zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5r0PRFxpcZ/vFj+uK85zXo+i86TB/wAC/wDQjVw3InsfM8sh
lleQ9XYsfxplFFcp1nVeAP8AkYZP+vc/+hLXb6uf9LT/AHB/M1w/gH/kYJP+uB/9CWu11Y/6Uv8A
uD+ZraHwmM/iKWaM03NGaYh2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAeOSBXpGh/wDIHg/4F/6Ea82j5lQerCvRdMk+
zeHklPOyN3/UmqgZ1Nj5pooormOs6nwED/b8h7eQf/QlrstWP+lr/uD+Zrlfh9HnULqTH3UUfnn/
AArpdUbN8w9AB+lax+Exl8RVzRmm5ozTEOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA
7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0
AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmj
NADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5
ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zp
uaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAEsR/fJ/vCu91BjB4DvHXqunSOM
evlk15/Ef3yf7wr0DVv+Sf33/YLk/wDRRq47Mie6PnOiiiuY6jtfh7/r776J/wCzVu6kf9Pl/D+Q
rB+H3+vvvon/ALNW5qR/0+X8P5CtY/CYy+Ir5ozTM0ZpgPzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAE0PMyf7wr0DVv+
Sf33/YKk/wDRRrz625nSu98QyfZfh7fZOMaeY/zTb/WrjszOe6PniiiiuY6jtPh+D5t8e2E/9mra
1Fs38uPb+QrM8Api0upPWTb+QH+NXrxt15Mf9sitV8Ji/iZFmjNJRQAuaM0lFAC5ozSUUALmjNJR
QAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0l
FAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozS
UUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjN
JRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM
0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5o
zSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALm
jNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAu
aM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC
5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUA
LmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQ
AuaM0lFAC5ozSUUATWx/fr+P8q7b4h5h+H2oheyxL+HmIK4i2P79fx/lXb/En/kQNT/7Zf8Ao1Kt
fCyJfEjwCiiiuc6Tv/Af/ILuP+ux/wDQVqe6/wCPub/ro386r+A/+QXcf9dj/wCgrU90f9Lm/wCu
jfzrVfCjF/EyOikzRmgYtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0U
maM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALR
SZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAt
FJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC
0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0A
LRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQ
AtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjN
AC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM
0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZo
zQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJm
jNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0AT23+vX2zXcfEn/kQNT/
AO2X/o1K4mwTzLpU9eP1rsPifN5XgW7Tj97JGn/j4b/2WrXwszl8SPBqKKK5zpO/8CqRpU5PeYkf
kKkuTm6lPq5/nUngxAmgo399mP6kf0quzbmJ9TmtuiMftMKKSikMWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA0dDUPrNq
p6NKg/8AHhW58XmK+EbYDo16gP8A3w5/pWJoB/4nln/12T/0IVtfF/8A5FO1/wCv5P8A0XJVfYZm
/jR4rRRRWB0nc+CdWt5I10m4jCyjc0LgnDjqQffqfp9Oex+wW3/PL/x4/wCNeLo7xSLJGzI6kMrK
cEEdCDWr/wAJTrf/AEEZfyH+FaRnZamcoNu6PU/sFt/zy/8AHj/jR9gtv+eX/jx/xryz/hKdb/6C
Mv5D/Cj/AISnW/8AoIy/kP8ACnzon2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTr
f/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfy
H+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoP
Zy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9
gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/
48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7
Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/
AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jX
ln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt
/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nq8FrBb3EcyRDfG4dck9Qc+tVfircpd+C7OVDwb5MjPQ+XJxXmX/C
U63/ANBGX8h/hVe91vUtRtxBd3kksQYPsOMbgCAf1P50OorWBU3dMoUUUVkbH//ZDQplbmRzdHJl
YW0NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRo
IDE3MjEvSGVpZ2h0IDM2My9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0
c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMjgyMT4+DQpzdHJlYW0NCnic7d1LcpvHGYZRLQVLwU7IbCRkFpKQWUPudmz4LsuWI9mObEuy
Atm6BAAJQgB/8CaqFFcTnDTb/zDdX9U5w2/0zp4CCtW4dQsAAID/g9/+HgAaVQrX6C0AtKoQrnHt
TQDw626Gq/YiAOjxB+ECIBThAiAW4QIgFuECIJRxKVx3AaAxj9frq0gJFwARCBcAoTwVLgAieSFc
AEQyEy4AIrkOl18VAhDCYn2aGjUSLgAiWK/PUqP2hAuACNbr89SoHeECIALhAiCU9foiNWpLuACI
YL1+nRo1FC4AIlivL1OjBsIFQATCBUAo6/WbwsMZm3B9CQBtuVt+8Um4AGhU15XCNUi389rjACDX
F65V7XEAkCuHa5huB7XHAUCuHK5t4QKgTeVw7abbi9rjACDXF65x7XEAkCuHaz/dfqg9DgBy5XCN
hAuANpXDNU63r2uPA4BcX7hqbwOAG8rh8uITAI0SLgBCES4AIrkvXABEIlwAhPJAuACI5JFwARDJ
WLgAiOS5cAEQiXABEMp0E66xcAEQwdEmXCPhAiCCo+5EuACIo+tOU6P2hAuACLruLDVqR7gAiKDr
zlOjtoQLgAiuwzUULgAi6LrXvx6uLwCgLb+E6zI1aiBcAETQdW8KD2cIFwCNEi4AQik/VXgVrvPa
4wAgVw7XQLgAaFM5XMN0W9UeBwC5cri20+2g9jgAyPWF60XtcQCQK4drN93+U3scAOTK4doXLgDa
VA7XKN2+rz0OAHJ94fq69jgAyJXDNRYuANpUDpcXnwBolHABEIpwARCKcAEQyT3hAiCSB33hugMA
bfnikXABEMlD4QIgkrFwARDJc+ECIJKpcAEQyXW4xsIFQARH3Ulq1Ei4AIig605To/aEC4AIuu4s
NWpHuACIQLgACKXrzlOjtoQLgAi67nVq1FC4AIig6y5TowbCBUAEwgVAKF33pvBwhnAB0Kjyi0+b
cH0OAI05LoZrkG5ntccBQO74uBSuYbqtao8DgFxfuA5qjwOAXDlc28IFQJvK4dpNt2e1xwFArhyu
/XT7sfY4AMiVwzVKtwe1xwFAri9c92qPA4BcOVxj4QKgTeVweTgDgEYJFwCh9IXrNgC0RrgAiOQr
4QIgEuECIJRvhAuASH4QLgAieSJcAETys3ABEIlwARDKZBOusXABEMF8E66RcAEQwfx4LVwAxHF8
fJIatVcK12cA0JZfwnWaGrUjXABEsFqdp0ZtCRcAEaxWZ6lRQ+ECIILV6kK4AIhjtXqdGjUQLgAi
WK3eFB7OEC4AGiVcAISyWpWeKhyk21ntcQCQ6wvXqvY4AMiVwzVMt9mnANCYcri2hQuANpXDtZtu
P9ceBwC5vnA9qj0OAHLlcO2n27e1xwFArhyukXAB0KZyuMbpdrf2OADI9YWr9jYAuKEcrrfCBUCb
hAuAUIQLgFD6wvUJADTmC+ECIJJ7y6VwARDHA+ECIBLhAiCUx8IFQCRPhQuASF4KFwCRXIdrXArX
xwDQmMPlcWrUSLgAiGC57FKj9oQLgAiWy5PUqB3hAiAC4QIglOXyLDVqS7gAiGC5vEiNGgoXABEs
l69TowbCBUAEwgVAKMvlm8LDGcIFQKPKLz5dhev0IwBozKtiuAbCBUCbXr0qhWuYbq9qjwOAXDlc
2+k2qT0OAHJ94fqp9jgAyJXDtZtuD2uPA4BcOVz7wgVAm8rhGqXbN7XHAUCuL1x3PgSAxpTDNRYu
ANpUDtfVrfY2ALhBuAAIRbgACEW4AIjktnABEIlwARDK3b5wfQAAbfnwW+ECIJLvFwvhAiCOJ8IF
QCTCBUAozzbhGgsXABFMN+EaCRcAEUwXS+ECII7FYpUatSdcAESwWKxTo3ZK4RoBQGMWi9PUqC3h
AiCC63ANhQuACBaLC+ECII7F4nVq1EC4AIhgsXhTeDhDuABolHABEEr5qcJBup3WHgcAuXK4hul2
VHscAOT6wvXyfQBoy6+Ea1u4AGjT0VEpXLtXf3VSexwA5Mrh2k+372uPA4BcOVyjdLtfexwA5PrC
dbv2OADIlcM1Fi4A2lQO19Wt9jYAuKEvXO8BQFuEC4BghAuAUIQLgEg+Fi4AIrkjXABEck+4AIhE
uAAI5TvhAiCSx33h+icANOapcAEQydP5PDVqLFwARPDf+SI1aiRcAEQwny9To/aEC4AI5vMuNWpH
uACIQLgACGU+X6dGbQkXABHM52epUUPhAiCC+fwiNWpQCte7ANAW4QIglvn8svBwhnAB0KjNwxlZ
uAbpdlJ7HADk+sI1rz0OAHLlcA3T7WXtcQCQK4drW7gAaFM5XLvp9qT2OADI9YXr37XHAUCuHK79
dLv7DgA05rAYrpFwAdCmw8NSuMbp9nHtcQCQ6wtX7W0AcEM5XG+FC4A2CRcAoQgXAKEIFwCRfCBc
AEQiXACEclu4AIjkq75w/QMAGvONcAEQyUPhAiAS4QIglPEmXGPhAiCCl5twjYQLgAheHi6EC4A4
Dg9fpUbtCRcAERweHqdG7QgXABEcHq5To7ZK4fo7ADTmOlxD4QIggoODU+ECII6Dg4vUqIFwARDB
wcFl4eEM4QKgUX3hOqk9DgByBwelpwoHwgVAm8rhGqbbvPY4AMiVw7Wdbi9qjwOAXF+4fqw9DgBy
5XDtptu3tccBQK4crn3hAqBN5XCN0u1O7XEAkCuHa5xuH/wNABojXACEUg7X1a32NgC4QbgACEW4
AAhFuAAIRbgAiOQ94QIgkk+EC4BIvhQuACIRLgBC+Vq4AIjkh75w/RUAGvNEuACI5Mlslho1Fi4A
Ing+m6dGjYQLgAhms0Vq1J5wARDBbLYSLgDiuA7XjnABEMFstk6N2hIuACKYzU5To4bCBUAEs9lF
atRAuACIQLgACGU2uyw8nCFcADRq83BGFq5Bup3UHgcAuXK4huk2rz0OAHJ94XpeexwA5Mrh2k63
Z38BgMaUw7Wbbo9qjwOAXDlc++l2v/Y4AMiVwzVKt9u1xwFAri9co9rjACBXDtdYuABoUzlcV7fa
2wDgBuECIBThAiAU4QIgFOECIJJ3hQuASIQLgFA+Ei4AIrkjXABEck+4AIjkO+ECIBLhAiCUJ5tw
jYULgAiezeZXD8GXwvVnAGiLcAEQy3S6SI3aEy4AIphOV6lRO8IFQATTaZcatSVcAERwHa6hcAEQ
wXR6KlwAxDGdXqRGDYQLgAim08vCwxnCBUCjyuEapNu69jgAyE2npacKr8I1rz0OAHLlcA3T7Vnt
cQCQK4drW7gAaFM5XLvp9rD2OADI9YXrfu1xAJArh2s/3T6rPQ4AcuVwjYQLgDaVwzVOt/drjwOA
XF+4am8DgBvK4fLiEwCNEi4AQhEuAEIRLgBCES4AInlHuACI5EPhAiCSz4ULgEiEC4BQ/iVcAETy
oC9cfwKAxvwoXABE8ngySY0aCxcAEfw0OUiNGgkXABFMJkepUXvCBUAEk8lSuACI4zpcO8IFQAST
SZcatSVcAEQwmZykRg2FC4AIJpPz1KiBcAEQgXABEMpkcll4OOMqXOva4wAgt3k4IwvXQLgAaFM5
XMN0m9ceBwC5cri20+1Z7XEAkOsL18Pa4wAgVw7Xbrrdqz0OAHLlcO0LFwBtKodrlG6f1h4HALly
uMbp9l7tcQCQEy4AQimHy4tPADRKuAAIpS9cEwBoj3ABEEopXE/fAkDTbpU+cgFAq24pFwCR5OFS
LgCadiNcv6m9CAB63AiXH2gA0LKb4fJlIQANK4Tr1h8BoFG/K4ULAEL4H94CKEINCmVuZHN0cmVh
bQ0KZW5kb2JqDQoxOSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2Rl
WyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21h
aW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggNDgyPj4NCnN0cmVhbQ0KeJyNwmVXWgEYAOBfuFI23Ryl5KUuXLq7u7tBBRsFAxDFANe6bv/J
3nsuR4/7sLPnPPWL6/q/j69r49//8dfk6M7q7Z/48zsr+B/4s79+L8PTm9+IpRPi18khvjj8cvv4
c+Hm0SeYx3/MDyZzgw+5Q+L7bJ94le3hM73LTBef7r5LHxDfpvbhG5jce01M7L7Cd17GYfsFjLUv
YjtwHN2Go2hrFGmdw/DWWXgTnobgxkkQrg+Da8cBuHrkhysDH2weept9b6PvafQ8y133EjxwL+67
YH3PWdt11jqOasdebdsrO7Yy3LaWWtZiy1LcshQ2zfkNaMqtG7NrxsyqAaZX9KmmLtXQJZe1iSWo
iS9qYnV1tKaCkaoyXFGGyopQSR4sygNFmb8g8+elvhzmzWKejAS602JXCnUmUWdC5IgL7TGhLSaw
RQXWCN8S5ptDPHMIMQURY4Br8HMMPo7ex9Z52VoPS+tmaVxMtYuhdjJUjgWlfV5hg3S5lS6z0GRm
mtRMxUxUzEiRGChiA1msJ6O656h2TqSdE2rgM4H6KV+F5ylneYpZRDGDyGe4MviEI4WP2RgksSQk
lpjEFE8z0WkGOsUQTS1A4aN5KMDT+Q8hDfIeQCpE7lMgF96DZA78A4Rh2QoNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoyMCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9E
ZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0
cnVlIHRydWVdIC9GdW5jdGlvbiAxOSAwIFI+Pj4+DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9UeXBl
L01hc2svUy9MdW1pbm9zaXR5L0cgMjIgMCBSL0JDIDIzIDAgUj4+DQplbmRvYmoNCjIyIDAgb2Jq
DQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0JCb3hbIDQ4IDc4IDY2MCAxMzJdIC9Hcm91
cCAyNCAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AyNiAyNiAwIFI+Pj4+L0xlbmd0aCA0Mz4+
DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMjYgc2NuDQo0OCA3OCA2MTIgNTQgcmUNCmYqDQoNCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9iag0KWyAwIDAgMF0gDQplbmRvYmoNCjI0IDAgb2JqDQo8
PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2JqDQoyNSAwIG9iag0KPDwvRnVu
Y3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2RlWyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEg
MCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9P
cmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTU4Pj4NCnN0cmVhbQ0KeJx9wYVOgmEA
htG7pUukRErpkhBQCYtUlLxBtmd7t+8fP5xzPNo4XLW/YGdne2Zj9W/4s1obfuXHsJKlLGQuM5ni
W77wKR94lwnGGGEob3jFCwboo4dndNFBGy08oYkG6qihigrKKKGIAvJ4xANyyEoGaaRwL0ncSQJx
iSEqEbmVsNxIyBCUgMFv5TN4rTxn3HZcFzivctg5AUDupZANCmVuZHN0cmVhbQ0KZW5kb2JqDQoy
NiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv
U2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0cnVlIHRydWVd
IC9GdW5jdGlvbiAyNSAwIFI+Pj4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0
ZS9CTS9Ob3JtYWwvY2EgMS9TTWFzayAyMSAwIFI+Pg0KZW5kb2JqDQoyOCAwIG9iag0KPDwvVHlw
ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTE0Ni9IZWlnaHQgNDA2L0NvbG9yU3BhY2Uv
RGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRl
IHRydWUvU01hc2sgMjkgMCBSL0xlbmd0aCAyMDIyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEB
AHgAeAAA/+EAWkV4aWYAAE1NACoAAAAIAAUDAQAFAAAAAQAAAEoDAwABAAAAAQAAAABREAABAAAA
AQEAAABREQAEAAAAAQAAEnRREgAEAAAAAQAAEnQAAAAAAAGGoAAAsY//2wBDAAgGBgcGBQgHBwcJ
CQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBD
AQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjL/wAARCAGWBHoDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI
CQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAk
M2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgEC
BAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcY
GRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOU
lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3
+Pn6/9oADAMBAAIRAxEAPwDwO3gkurmK3hUNLK4RASBkk4HJ4H410f8AwrzxSf8AmGD/AMCYv/iq
xdH/AOQ3Yf8AXzH/AOhCvqEEjpWlOCluZVKjjsfPH/CvPFP/AECx/wCBMX/xVH/CvPFP/QLH/gTF
/wDFV9AS3kkchUBSB6imfb5f7qfka09lEz9tI8C/4V54p/6BY/8AAmL/AOKo/wCFeeKf+gWP/AmL
/wCKr337fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfin/oFj/wIi/8AiqP+Fd+Kv+gWP/AiL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AiL/4qj/hXfir/AKBY/wDAiL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwIi/+Ko/4V34q/6BY/8AAiL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXfir/oFj/wACYv8A4qj/AIV34q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFd+Kv+gWP/AmL/wCKo/4V34q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V34q/6BY/8CYv/iqP+Fd+Kv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXfir/
AKBY/wDAmL/4qj/hXfir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFd+Kv+gWP/
AAJi/wDiqP8AhXfir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV34q/6BY/8CYv/
AIqj/hXfir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXfir/oFj/wJi/+Ko/4V34q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv8AoFj/AMCYv/iqP+Fd+Kv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V34q/6BY/8AAmL/AOKo/wCFd+Kv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfir/oFj/wJi/8AiqP+Fd+Kv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AmL/4qj/hXfir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXXir/oFj/wACYv8A4qj/AIV14q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFdeKv+gWP/AmL/wCKo/4V14q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V14q/6BY/8CYv/iqP+FdeKv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXXir/
AKBY/wDAmL/4qj/hXXir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFdeKv+gWP/
AAJi/wDiqP8AhXXir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV14q/6BY/8CYv/
AIqj/hXXir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXXir/oFj/wJi/+Ko/4V14q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+FdeKv8AoFj/AMCYv/iqP+FdeKv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V14q/6BY/8AAmL/AOKo/wCFdeKv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXXir/oFj/wJi/8AiqP+FdeKv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+FdeKv+gWP/AmL/4qj/hXXir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V14q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPBP+FdeKv+gWP/AAJi/wDiqP8AhXXiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZ
RD20jwT/AIV14r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r
/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/
AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/
AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hX
Piv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6B
Y/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJ
i/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq9
7+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v9
1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9
vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qf
kaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ
9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4
Vz4r/wCgWP8AwJi/+Ko/4Vx4r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+
gUP/AAJi/wDiqP8AhXHiv/oFD/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8
CYv/AIqj/hXHiv8A6BQ/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4q
j/hXHiv/AKBQ/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/wCgUP8AwJi/+Ko/4Vx4
r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+gUP/AAJi/wDiqP8AhXHiv/oF
D/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8CYv/AIqj/hXHiv8A6BQ/8CYv
/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4qj/hXHiv/AKBQ/wDAmL/4qve/
t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4s/wCgUP8AwJi/+Ko/4Vx4s/6BQ/8AAmL/AOKr3v7fL/dT
8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AAJi/wDiqP8AhXHiz/oFD/wJi/8Aiq96+3y/3U/I0fb5
f7qfkaPZRD20jwX/AIVx4s/6BQ/8CYv/AIqj/hXHiz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaP
ZRD20jwX/hXHiz/oFD/wJi/+Ko/4Vx4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf
+FceLP8AoFD/AMCYv/iqP+FceLP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz
/oFD/wACYv8A4qj/AIVx4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/wCFceLP+gUP
/AmL/wCKo/4Vx4s/6BQ/8CYv/iq96+3y/wB1PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8CYv/iqP
+FceLP8AoFD/AMCYv/iq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz/AKBQ/wDAmL/4qj/hXHiz
/oFD/wACYv8A4qvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8AAmL/AOKo/wCFceLP+gUP
/AmL/wCKr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf8AhXHiz/oFD/wJi/8AiqP+FceLP+gUP/AmL/4q
vevt8v8AdT8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AmL/4qj/hXHiz/AKBQ/wDAmL/4qvevt8v9
1PyNH2+X+6n5Gj2UQ9tI8F/4Vv4s/wCgUP8AwJi/+Ko/4Vv4s/6BQ/8AAmL/AOLr3r7fL/dT8jR9
vl/up+Ro9lEPbSPBf+Fb+LP+gUP/AAJi/wDi6P8AhW/iz/oFD/wJi/8Ai696+3y/3U/I0fb5f7qf
kaPZRD20jwX/AIVv4s/6BQ/8CYv/AIqj/hW/iz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaPZRD2
0jwX/hW/iz/oFD/wJi/+Ko/4Vv4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf+Fb+
LP8AoFD/AMCYv/iqP+Fb+LP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hW/iz/oFD
/wACYv8A4qj/AIVv4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI+ctb8L6z4dW3bVbP7O
txu8o+Yj7tuM/dJx1HWsivb/AIrKt34RhllUbonLpjjB3Kv8mNeIVlOPK7I2pycldl3R/wDkN2H/
AF8x/wDoQr6fr5g0f/kN2H/XzH/6EK+n60o7Myr7oo3H+vb8P5VFUtx/r2/D+VRVqYhRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/E3/AJEv8f8A2oleIV7f
8Tf+RL/H/wBqJXiFYVfiOmj8Jd0f/kN2H/XzH/6EK+nc18xaP/yG7D/r5j/9CFfTtXR2ZFfdFG4/
17fh/KoqluP9e34fyqKtTEKKKKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAct8TP+RL/H/wBqJXiNe3fEz/kS/wAf/aiV4jWFX4jpo/CXdH/5Ddh/18x/+hCvpyvm
PR/+Q3Yf9fMf/oQr6cqqOzIr7oo3H+vb8P5VFUtx/r2/D+VRVsYhRRRSGFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBy/xL/wCRL/H/ANqJXiNe3fEv/kS/x/8AaiV4
jXPV+I6KPwl3R/8AkN2H/XzH/wChCvpuvmTR/wDkN2H/AF8x/wDoQr6bzV0dmRX3RQuf9e34fyqK
pbk/v2/D+VRZrUxCijNGaBhRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmj
NABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRm
jNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRR
mjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABR
RmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAB
RRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNA
BRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAHMfEr/AJEv8f8A2oleJV7b8Sv+RL/H/wBq
JXiVc9X4joo/CXdH/wCQ3Yf9fMf/AKEK+mc18zaP/wAhuw/6+Y//AEIV9MVdHZkV90Ubk/v2/D+V
RZqS5/17fh/Koq1MRc0ZpKKBi5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSU
UALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJ
RQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0
lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5oz
SUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmj
NJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAua
M0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5
ozSUUALmjNJRQBzXxJ/5Ev8AH/2oleJ17Z8SD/xRZ+v/ALUSvE656vxHRR+Eu6P/AMhqw/6+I/8A
0IV9L180aR/yGrD/AK+I/wD0IV9LVdHZkV90Ubk/6Q34fyqLNSXP/Hw34fyqGtTIdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooA5z4j/wDIln6/+1ErxSvaviP/AMiWfr/7USvFa56vxHRR+EuaR/yGrD/r4j/9CFfSua+a
tI/5DVh/18R/+hCvpSro7Mivuijcn/SG/D+VQ5qS5/4+G/D+VRVqZC5ozSUUgFzRmkooAXNGaSig
Bc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKK
AFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmko
oAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaS
igBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Zp
KKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRm
kooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNG
aSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigDnfiKf+KLP1/8AaiV4tXtHxE/5
Etvr/wC1ErxesKvxHRR+EuaR/wAhqx/6+I//AEIV9JZr5t0j/kNWP/XxH/6EK+kM1dHZkVt0Ubk/
6Q34fyqHNSXJ/wBIb8P5VFmtDIXNGaTNGaBi5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozS
ZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJm
jNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM
0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQ
AuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC
5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALm
jNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0Ac/8Q/+RLb6/wDt
RK8Yr2b4hHPgtvr/AO1ErxmsKvxG9L4S5pP/ACGbH/r4j/8AQhX0dmvnHSf+QzY/9fEf/oQr6MzV
0tmRW3RRuT/pD/h/Koc1Jcn/AEh/w/lUOa0Mh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQBhfEH/kS3+v8A7USvGq9k8fn/AIot/qP/AEYleN1hV+I3pfCXNJ/5DNj/
ANfEf/oQr6KzXzrpP/IYsf8Ar4j/APQhX0RmqpdSa26KN0f9If8AD+VQ5p90f9If8P5VDmtTIfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB
+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Zo
AfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNG
aAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMz
RmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozT
M0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM
0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfm
jNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAxfHx/wCKLf6j/wBGJXjl
ew+PDnwXJ9R/6MSvHqwq/Eb0vhLelf8AIYsf+viP/wBCFfQ+a+eNK/5DFl/18R/+hCvoTNVS2ZNb
dFG6P+kP+H8qhzT7o/6Q/wCH8qhzWhmPzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0AY/js/8UXJ9R/6MSvH69f8AHJz4Ll+o/wDRiV5BWNTc3pfCW9K/5C9l/wBfEf8A
6EK+gs18+6V/yF7L/rvH/wChCvf81VLqRW3RQuj/AKS/4fyqHNPuj/pL/h/Koc1oZj80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAGV43OfBcv1H/AKMWvIq9c8anPgub
6j/0YteR1jU3N6Wxb0v/AJC9l/13T/0IV77n3rwLS/8AkLWX/XdP/QhXvWaql1IrdDPuj/pL/h/K
oc1JdH/SX/D+VQ5qyB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
DM8ZnPguf6j/ANGLXktes+MjnwZP9V/9GLXk1ZVNzalsWtL/AOQtZ/8AXdP/AEIV7xmvB9M/5C1n
/wBd0/8AQhXu2aql1Jq9DPuz/pL/AIfyqHNPuz/pL/h/Koc1ZmPzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjN
AD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZo
zQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpm
aM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AZ/jA58GXH1X/wBGLXlFereLjnwZcfVf/Ri15TWVTc2p
7FrTP+QrZ/8AXdP/AEIV7nmvDNM/5Ctn/wBd0/8AQhXuGadMmr0M+7P+kv8Ah/Koc0+7P+lP+H8q
gzVkEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1H
mjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAFPxYf+KMufqv8A6MWvK69S8VHPgy5+q/8Aoxa8trKpua09i1pv/IVs/wDrun/oQr27
NeI6b/yFLT/rsn/oQr2vNVTJq9DOuz/pT/h/Koc0+7P+lP8Ah/Koc1ZA/NGaZmjNAx+aM0zNGaAH
5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmg
B+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Z
oAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zN
GaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNM
zRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAq+KDnwZdfVf8A0YteXV6f4mOfBt39U/8ARi15
hWVTc0p7FnTf+Qpaf9dk/wDQhXtOa8W07/kKWn/XZP8A0IV7Pmqpk1ehm3h/0p/w/lUGalvD/pT/
AIfyqDNUSOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AV/Epz4Nu
/qn/AKMWvMq9M8RnPg28+qf+jFrzOs57mlPYs6d/yE7T/rsn/oQr2TNeN6d/yE7T/rsn/oQr2LNV
TFU3Rm3h/wBKf8P5VBmpbw/6U/4fyqDNUQh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0
ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7
NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0A
OzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjN
ADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5o
zQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zpu
aM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQBF4hP8AxRt59U/9GLXmlek+IDnwbe/VP/Rgrzas57mlPYs6d/yE7T/rsn/o
Qr2HNePaf/yErX/rsn8xXr2aqmTUM28P+lP+H8qgzUl4f9Kf8P5VBmmSPzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AM1858G3v1T/0YK83r0fXT/wAUdffVP/Rgrzio
nuaQ2LGn/wDIStf+uyfzFeu5ryLT/wDkJWv/AF2T+Yr1vNOmTUMy8P8ApT/h/KoM1LeH/Sn/AA/l
UGaokdmjNNzRmgY7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AJrZ/4o6++sf/
AKMFec16LrX/ACJ19/2z/wDRgrzqonuXDYsaf/yErX/rsn8xXrVeS2H/ACEbX/rsn8xXrOadMmoZ
d4f9Kf8AD+VV81NeH/S3/D+VQZqhC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAua
M0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5oz
SZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJ
mjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0ma
M0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZoz
QAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNA
C5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNABrP/ACJ1/wD9
s/8A0YK87r0PWDnwdf8A/bP/ANGCvPKie5cNixYf8hG1/wCuyfzFer15RYf8hG1/66p/MV6tmnTJ
qGXef8fT/h/KoKmvD/pT/h/KoM1QkLRSZozSAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAF
opM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoA
WikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmg
BaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGa
AFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0Z
oAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzR
mgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTN
GaAFopM0ZoAWikzRmgBaKTNGaADV/wDkTtQ/7Z/+jBXnteg6v/yJ+of9s/8A0YK8+qZ7lw2LFh/y
EbX/AK6p/MV6pmvK7D/kI2v/AF1T+Yr1PNOAqhl3h/0p/wAP5VBmprz/AI+n/D+VQVRKFzRmkopD
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB2rf8ifqH/b
P/0YK8+r0DVf+RP1D/tn/wCjBXn9TPcqGzLFh/yEbb/rqn8xXqWa8u05S2p2ijqZkH/jwr1DNOAp
mXeH/Sn/AA/lUGatXUUj3Lsq5Bx39qh8iX+7+oqiSPNGak8iX+7+oo8iX+7+opAR5ozUnkS/3f1F
HkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/
UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmj
NSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev9
39RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/
AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEea
M1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/
3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeR
L/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQ
BHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J
5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UU
eRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1F
AEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozU
nkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/
UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev9
39RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEe
aM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8A
d/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/
3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR
5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeR
L/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR
5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAN1X/kT9R/7Z/+jBXn9egaspXwjqIYYP7v/wBGCvP6me5c
NgqaG6uLdSsM8sYJyQjkZ/KiioLLo8QaoAB9q6f7C/4Uf8JDqn/P1/5DX/Ciindisg/4SHVP+fr/
AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU
/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4
SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsL
IP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wo
oouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kN
f8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1
/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p
/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf
8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4
Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/
8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n
6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+
Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLI
P+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAK
KKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf
8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9
f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOq
f8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH
/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr
/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCf
r/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP
+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8A
hIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouw
sg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KK
KLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ
1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/
X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDq
n/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8A
CQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/
AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8A
Ia/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T
/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh
1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLs
LIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKK
LsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1
/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X
/kNf8KKKLsLIjn1rUbm3e3muC0UmNy7FGcHI6D1AqhRRSGf/2Q0KZW5kc3RyZWFtDQplbmRvYmoN
CjI5IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxMTQ2L0hlaWdo
dCA0MDYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25l
bnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0MTg+Pg0K
c3RyZWFtDQp4nO3Wx00dUBQAUTpzra7BOAeccwc4xw84hzWWl0i85Z0vpHOKGM3ODgAAAAAAAJwp
xwAF5QF655QH6CkP0FMeoLd3enmeAww5/HtiepQHCCgP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAb12eZwBDDpQHyB38UR6gpjxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbleQowRHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95
gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAforcvzBGCI8gA95QF6ygP0lAfo
KQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PI8Bhmx+Kw9QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAL11eR4BDFEeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gC9dXkeAsxQHmALPv9SHqCmPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7P
A4AhygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoLcuz32AIZ9+Kg9QUx6gpzxA
T3mAnvIAPeUBesoD9JQH6K3Lcw9giPIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8twF
GPLxh/IANeUBesoD9JQH6CkP0FMeoKc8QE95gN66PHcAhnxQHiCnPEBPeYCe8gA95QF6ygP0lAfo
KQ/QW5fnNsAQ5QF6778rD1BTHqCnPEBPeYCe8gA95QF6ygP01uXZA5ihPMAWKA/QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FuX5xbAEOUBeu++KQ9QUx6gpzxAT3mAnvIAPeUBesoD9NbluQkwQ3mA
LXirPEBOeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7PDYAhb74qD1BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QW5fnOsAM5QG2QHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QG9dnmsAQ15/UR6gpjxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PFcBhigP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqC3Ls8VgCGvjpQHqCkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYDeujyX
AYYoD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mA3ro8lwBGKA+wDS8PlQeoKQ/Q
Ux6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8lwEmKE8wBYoD9BTHqCn
PEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66
PLsAQ14cKA9QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbluQAwY3dfeYDc
/kZ5gJryAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QG9dng3AmFV5jgDGnCjPf+ePAcbtnEJ+gFmnlQcAAACAs+kfpG8Q
rA0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMC9TaXplWyA1
MTJdIC9EZWNvZGVbIDAgMSAwIDEgMCAxXSAvUmFuZ2VbIDAgMSAwIDEgMCAxXSAvQml0c1BlclNh
bXBsZSA4L0RvbWFpblsgMCAxXSAvRW5jb2RlWyAwIDUxMV0gL09yZGVyIDEvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA4NTA+Pg0Kc3RyZWFtDQp4nJWU5zubYRhH/0KrulvEliAiNkmERKwIIgRB
xGoRe+89W1106/pPeu48b40PPvS6zmfyPvfvnKiErChBH5Woj77GEJ1kiBGyY3RCrJATmyzECblx
KWCEe6mQJ6SZ4iEd8u9DhlnILHgQ4WFWITzSFwmGYnicXQJPckojlD3NhfJnxgp4nmd5brIkmKwJ
JltCvi3RXJloticVQJWusEpXVJ1c5EgudqQUO1NKalJLXZBWVptWXpcOFfUZlgbItDZmWd1ZtiZ9
pUdv9xjszYaqluxqaM1xeHOcbblOn7HGZ3S157k68mr9pjq/qb4zv77L3NBtbgwUgLunsKm30NNX
BM3B4pb+kpZQSetAqXegzDtY1jZU7huGivaRio4XFv9Li3/U2jlq7RqzdY1XdocrA2F7YMLeM1nV
OwXVfdOO4IwjOOvsn3WG5mpC8zUD867BBdfgYu3QUu3wUt3wct3ISj28WG14uQaNo+uNoxvusQ33
+GbT+FZTeMsT3vZMwE7z5C60TO1B6/R+6/SBdwYOvbOHbXNH4Js79s3DSfsCnLYvnnYsvupYeu1X
LJ91wsobYfVtl/Cuew3eC+vvA+sfAhtw3gObcAG9W/BR2P7Yt/1JY+dzUONLcFfoh72vV4T2voX2
r/gOAweKS43Dy0HhxzVHwtDRz1scK37B8E1OFL/vYgRO//wfd/+1CJH/eOM3DGlEfuHtn62+5dbX
HconX39+5DXUy1w/1N63m2/Yv6u9rTxy5LV59qsTcA7tLlsX6lJyso3zgPCBU3JQ7bJr7zg05+bo
2vWXzxiDWgXzYCRMRQazcMJ4ZEJzx2pRTEsGNnPA2Jic2p7aIYOUWYa3mShDZa6MlukyYLVkJs2w
mTcjZ+oMntkzfhRABHRACtRAEDRRviAO+iARKiEUWiEXiiEauiGdsg8NkRElERM9kRRVERZtkReF
ERmdkRq1ERzNkR3lER/9iQApIAhkgTiQCEJBLogG6SAgZET1hLCQFyJDalRziA8JIkTkiCiRJgJF
pogVySJcki+TlZQRNFU2EkfoyJ3qnmqg6qFqo+qkaibx1Cqanh8vSGDJrNbbVKMqsKSYICdrfZZQ
67RuS8CTJOaS9H95J/US/Ej5/wKcWpEGDQplbmRzdHJlYW0NCmVuZG9iag0KMzEgMCBvYmoNCjw8
L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBl
IDIvQ29vcmRzWyA1NjkuODEgNjA5LjI1IDU2OS44MSAzMjYuNzVdIC9FeHRlbmRbIHRydWUgdHJ1
ZV0gL0Z1bmN0aW9uIDMwIDAgUj4+Pj4NCmVuZG9iag0KMzIgMCBvYmoNCjw8L1R5cGUvTWFzay9T
L0x1bWlub3NpdHkvRyAzMyAwIFIvQkMgMzQgMCBSPj4NCmVuZG9iag0KMzMgMCBvYmoNCjw8L1R5
cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vQkJveFsgNDc5LjEzIDMyNi43NSA2NjAuNSA0NjhdIC9H
cm91cCAzNSAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AzNyAzNyAwIFI+Pj4+L0xlbmd0aCA1
OD4+DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMzcgc2NuDQo0NzkuMTMgMzI2Ljc1IDE4MS4zNyAx
NDEuMjUgcmUNCmYqDQoNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNCAwIG9iag0KWyAwIDAgMF0gDQpl
bmRvYmoNCjM1IDAgb2JqDQo8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2Jq
DQozNiAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgNTEyXSAvRGVjb2RlWyAwIDEgMCAx
IDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0g
L0VuY29kZVsgMCA1MTFdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTI4Pj4N
CnN0cmVhbQ0KeJy91IcNwCAQA8D95yG99z5UBrAd9CDlJkC8bedCJBFSi8wn1wqhFCqmZhrQMh3o
wQBGMDEzWJiV2YRdOLTT57K4Izw/inmn6UO83/txGnVNdX0aFRoqzB6NKCYZ046NwNbQcmEHaVVp
qdUCqMX4GBnvQJnmLmZXg4bcvQ6mfT0NCmVuZHN0cmVhbQ0KZW5kb2JqDQozNyAwIG9iag0KPDwv
UGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUg
Mi9Db29yZHNbIDU2OS44MSA2MDkuMjUgNTY5LjgxIDMyNi43NV0gL0V4dGVuZFsgdHJ1ZSB0cnVl
XSAvRnVuY3Rpb24gMzYgMCBSPj4+Pg0KZW5kb2JqDQozOCAwIG9iag0KPDwvVHlwZS9FeHRHU3Rh
dGUvQk0vTm9ybWFsL2NhIDEvU01hc2sgMzIgMCBSPj4NCmVuZG9iag0KMzkgMCBvYmoNCjw8L1R5
cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvQUJDREVFK1ZlcmRhbmEs
SXRhbGljL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA0MCAwIFIvRmly
c3RDaGFyIDMyL0xhc3RDaGFyIDExNC9XaWR0aHMgOTQwIDAgUj4+DQplbmRvYmoNCjQwIDAgb2Jq
DQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStWZXJkYW5hLEl0YWxpYy9G
bGFncyAzMi9JdGFsaWNBbmdsZSAtMTMvQXNjZW50IDEwMDUvRGVzY2VudCAtMjA3L0NhcEhlaWdo
dCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDE5MTQvRm9udFdlaWdodCA0MDAvWEhlaWdodCAy
NTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NTMgLTIwNyAxNDYxIDc2NV0gL0ZvbnRGaWxlMiA5NDEg
MCBSPj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNDMgNDMgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNDIgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyAyPj4NCmVuZG9iag0KNDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTI5MT4+DQpzdHJlYW0NCnicnVdLb+M2EL4b8H/gkVrUNN+kgCCHPLrdRV1skxRb
IOhBdRTH2UjKynL69ztD24lkS4rig2mb0jy+mfmGQzL9Rk5OprPzLxeEn56Ss4tz8nM84oQzzrmQ
kjviJCdGc1Km49H3TySHx4wroeEd5Sys1sSkXLxKcW4F1w2x+0/j0Z/jEbmcnRNSMykOTLYIb2w6
ETNnCLxGjNr9ZNKAAJln49H0S5YsUq3IRUHaTMk3U5OtJS5itwXqlRAtRg3f2dQxE9IQJZiHnTgI
1ezaLrPq0KwxIu43qx0A20A1xAbDGqHWLboui/rQovXabixKrUVbdAVXr9HlAaLlMTrhgvU3s77L
rJn+nuQLQh+Tyddv0daHsxuQ+1UQzyCnN/dgJ5gQYEQxr2BfO0luMiwpG3sCRTT9fA0xWax2W5/H
o1sqo4mmHBeBS/g7tVP4NtRF/5Cbr+PR5U2LV7bmyKttY5iUNdu3lPTpcF3Idgq1Ewx44pkyO4Wq
T6Fv1WE3AXnT0etU3IiwJNKx2DZCLEEj0EF7y5zbxridtofbVyHqZ8n8x6KMNC3WGPD8ruZQw3ct
mfN1S+84L3jDe02k2PdeIN9AJ1CBb3WecO7dadOFAJ3vV5eCWPqmMP07jSzNSQbrPI0UOGjovMhg
fS7yFEDm1aoDnzSKiT11/fhEA58hwjO/RwCzwSc1i+NXfGeXLfjAdF3SOWZ9UxLA5SSaWDoDYOeX
0URS8uUav646IInYMiOaSvohycGQgNrqOEg1yTZIq+K+WuJe+bMrU1BITjQV9cNSQ2EpD6o3OgVy
xeIqoeyRQs2dwJ6PQa9pv6UvMwDckTfgOeSt8Xo/QD0YoOVMxMc0ig9CfbNzSy+KjJNsnj5FE0WL
ReDlxNElNva8SkvYuE+Arx3p9p6JpkIStfnB4OBr9UV5ZoZR2gxtWYo75s2RLasuTBXJEuhPjwUs
JXkuIBjLCOOyIpGnxT2BXga1gr35Enee4GGxWEaOzjsCpqRhMC81rPTDtkPLR3rz2v0/VhB1Sfpb
8R+WAnbnqiCbOnhM51W9F3QUA5xC8Z62fmxuMDarmTgOW01yD1uarUPVJxWePqHsEd/1VecxBAe6
2VPZD9APBgixM8cBrEnuAXzC5IUMvqQkCz+Q4CUC7jpoDVO6qfOQ0KKH0HBhYbEeFJx4KKFFzHFe
PI7QdWE6Sx5xmipDvnH8yFdVmdRpLfmW1/N1WaZhN2zuaN7Fa+eZbdrqBS/50MoQFlqsPqYy6pL0
rFjndwSK4qFYVV3Z5xoH1oZcPwqxl0Jh9lMYCyZgoBbaI3V6U3goLOAKJExDGEp8telFDzhEVvBJ
y2KR5mmxXm1orDj9t0yTH2FkiSaeZiHBii4g1bBXbf8W+S/wWHo6T3L4mxeoVyisigobfoFUetqc
iFLRl2VC5s9rrJSuOdxycFQ3/e0PoBwcQBkzdXQAa8L0D2RA3jXeaI63oIbApPNd6AJ77ybl/AHD
FYcIrzAja8zTCjcFUCskZYY91mBchaEpXgHWeHQmMFzabt9UrJBjdXP9wW0bLW07ySBxQr5Hsq6e
V5em3wFyGioM2m15t4Hp6PN2u+wKprUhmHVVnYF3Guetxrt3mFWYVvR2dCMz+NlzlMH1w+mmiv5g
Dh5j4RJq3g1lWxhrgvSvPE+qdZk8YdMlkZD1a0i4goShZImPi5ys0gy7eF4F8PMu1CqWrOnhIej/
AQcEAa0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5
cGUvSW1hZ2UvV2lkdGggMTAyNC9IZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4
NzExPj4NCnN0cmVhbQ0K/9j/4AAQSkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sA
QwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8n
OT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAA
AAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQy
gZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm
Z2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS
09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYH
CAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1Lw
FWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5
eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj
5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigDxD/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/
AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1u
v/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+I
f+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8
Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fq
T/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/
lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4
h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/
8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/
AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD
+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P
/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/
ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z5
6X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688o
o+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/
AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8A
z56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzy
ij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/
ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoP
AopD0oA27uLR7BoYZbK6mkaGORnFwFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2Fz
eJNJDC7QwKHmkVciNc4yfasopct2/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCx
qVL3RtPH+j6edQmH/La8Yqn4Iv8AU1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx1
0y7H/b0P/iaVU0e8bZG1xYyn7rTMJIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIs
NX0O41bTbQ2F3aKr3diG3IY26SJ3A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVp
XjfaNC0+4c5ljZ7fd3KjBX8skVm1vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOl
dZa6BoekwR3XiXUt0joHTT7I75CDyNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibU
lDiw+zRn+O5YJx9OtW2+IR02MweGtGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS
9dX/AF8zRKjHdt+mh1y/DCG2XOqeJ9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR
7Gq96j+5Fe2pLamvvZ6UvgLwjdfLaeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2Oq
X2mTCSxvZ7Zwesbkfp0NS6VZfDP70Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6q
F0bxVDDLFN8guCo2k9t47fUVheP/AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2l
J3XXujiKKKK6jlCiiigAooooAKKKKACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW
1v4PFXlxlLextBHaqrFcKHxk4PzE9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrS
Xmi6kpJe3G8hCclHXqCDXHPom7bW+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq
5f6bp2ta/aRX1pERY6LHdM7SMBNxgK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X
3MliLM30r2a7ICkGSFIxtJxyPrWboVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjAD
BUtzg1z+jW8nh/wVq2qX4MTanCLWzhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOf
evPb7ULvUZEa7uZJzEgjj3HhUHAAHYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfW
jJ/yLVt/19Sf+gis6u2PU459AoooqiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmm
c4VcdF+p9KrWFlPqWoW9lbLumnkEaD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+R
rTppxc5bL8xNMt/Bj+BZJb2WAa75UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBY
EE4OaX4X6bplx4Qu7q8sLe5aOdzukiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw
9/wk+urppuTb7o2fzAu7p2xXp/h7WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+R
HC7RgnJClQcfhVSxbcZRs4ySuTHCpSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/Ef
VNMvL6Xw/DpedYmeJVuti9yMDPWrt1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VO
crSSivw8jxgEEcV6tp3h/SJPhFJqb6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L
95WA4z71c0r/AJIdL/16Sf8AoRrOtiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1
r1bQpT4q+Ec8F388sUMkW48klBlT/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb3
0IwcnKUr7W1PER0FLSDpzS16BwBRRRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SX
UaMPlHUEg0aTqGr6HIX03WLW3z95Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMx
s64DV4k8fNXhyppHuQwEHafM02e/J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/m
WNeBx2F1LaG6SB2gEgj3gcFiM4Hviq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/D
diqn2Fs/8fWn/wDgdF/8VXleKOK2WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1J
rKqn4Z/5ExP+v5//AEAVcr1cLUdSkpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E
9mtz4zEzjP2aBpF+p4/qa5nxFcvd+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3R
pNG8XXqMuIrhzPC3YqxyfyOa5Iu2Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+
gCvO9J8ZajpWg3miqkc1ncoy7X4MZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZ
XOiGJpqUG+isaHwk/wCR3P8A17SfzFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOP
T6VLf+K9QvPFP/CQRBLW8BUqI+VGBjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2a
ywMZih2Y6deldv431y80SO2ubfQY9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOeh
qfQvinrOj2SWk8MV9FGNqNISrgdhkdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8J
rbWE4aHzdxUAsMZxj9a0tJIPwOlwc4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXif
V7XR7nQLVftFtdgoIdhZlJ6lcVX1WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU
+i8fjT/id4xh1ORdD02QPaQNmeRfuu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVf
a1XtsjGVeMaXs6a33YUUUV1nIFFFFABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVr
xappEkVvc3t/ZvrDQmOO5WFmRfkAVpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8A
hBPEf/Pin/gRH/8AFV8xUhLnenU+npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4Bfcceh
qG21TwubWF74W0l/5ZkkkEBwJIidijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8
VWfJLsXzx7o3n1vQ7bRP3E8Mt8sDi3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gD
KflAwWyepqr/AMIJ4i/58U/8CY//AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6
AKuUabpd3o/heK1vkWOdrt3CCRWO3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQBNZ3c1hewXdu22aBw6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3
Y3EkE6dHQ4/A+ormxGH9raUXaS2Z0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOU
mikiYdVkUqf1r0/RfjHNEqxa1Yebjgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09Kk
L+aOj6vh6mtOdvJngG4eoo3D1FfQ4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoY
JrhtsMMkh9EQt/Kt3T/AviXUyPJ0qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWV
nd3TdiwEY/Wl9bxE/gp/f/SD6rQh8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0
pzI34nk/QV5fqvxY8QXytHZrBYRnvGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo
/wAKN33Yy4YPczOpyrOzA+xNR0UV6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJ
gelGB6UtFACYHpRgelLRQAmAKWiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6
ClooAKKKKACiiigAooooAKKKKACiiigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNDQgMCBv
YmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0Vu
Y29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDQ1IDAgUi9Ub1VuaWNvZGUgOTM2IDAg
Uj4+DQplbmRvYmoNCjQ1IDAgb2JqDQpbIDQ2IDAgUl0gDQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9C
YXNlRm9udC9BQkNERUUrVmVyZGFuYS9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lE
VG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDQ3IDAgUi9Gb250RGVzY3Jp
cHRvciA0OCAwIFIvVyA5MzggMCBSPj4NCmVuZG9iag0KNDcgMCBvYmoNCjw8L09yZGVyaW5nKElk
ZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQo0OCAwIG9i
ag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrVmVyZGFuYS9GbGFncyAz
Mi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWlnaHQgNzY1L0F2
Z1dpZHRoIDUwOC9NYXhXaWR0aCAyMDA2L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1W
IDUwL0ZvbnRCQm94WyAtNTYwIC0yMDcgMTQ0NyA3NjVdIC9Gb250RmlsZTIgOTM3IDAgUj4+DQpl
bmRvYmoNCjQ5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNE
RUUrV2luZ2RpbmdzL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDUwIDAgUi9U
b1VuaWNvZGUgOTQyIDAgUj4+DQplbmRvYmoNCjUwIDAgb2JqDQpbIDUxIDAgUl0gDQplbmRvYmoN
CjUxIDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrV2luZ2RpbmdzL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
NTIgMCBSL0ZvbnREZXNjcmlwdG9yIDUzIDAgUi9XIDk0NCAwIFI+Pg0KZW5kb2JqDQo1MiAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjUzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStXaW5nZGluZ3MvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODk5L0Rlc2NlbnQgMjA1
L0NhcEhlaWdodCA3NzEvQXZnV2lkdGggODkwL01heFdpZHRoIDEzNTkvRm9udFdlaWdodCA0MDAv
WEhlaWdodCAyNTAvU3RlbVYgODkvRm9udEJCb3hbIDAgMjA1IDEzNTkgNzcxXSAvRm9udEZpbGUy
IDk0MyAwIFI+Pg0KZW5kb2JqDQo1NCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9S
ZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAw
IFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUg
NDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn
ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNTUg
MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz
L1MvU3RydWN0UGFyZW50cyAzPj4NCmVuZG9iag0KNTUgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggNTAxMT4+DQpzdHJlYW0NCnicnVtZbxtJkn434P9QwAKD4mBVyvsAGgJst93b
g/aO1/bsLtAzD7RM2eqWRC0p293/fuOLyCxWUayirAdJrGBFxpFxZ6o5fdP88MPp6xc//9ios7Pm
+Y8vmv97+kQ1qlNKaWNUbKJRjXeq2ayePvmfvzY39HWnrHb0jo2Bfgefm82nHkupoJUboV389emT
/3r6pHn5+kXTDEjqeyQPIAvNqHMXfUOvNd7Wj53xhNCcXz99cvrz9fLTyjc/rptDlMyO0kkhpHSO
Rc5ktT5A06tK0uVOG99Y3SWCZEYakA1TZO19st7rPE/WRZJLJPVNYMIOkg4pximK7j7FkFwQisY5
fUi5WtleuYpFDCqDicjUd2TTFFl/+svy5lPT/rY8+dubReHh+XvCe6Wb1NGWvr8gOkxCExHbJUtw
F03z/hoWFXJqyIZOf3pHOvm0raCfnj75tTWLE9cq/NL4xY+n4ZT++jYu/tW8/9vTJy/fH+AqDBjp
aXvfGTOg/WvbzK0RpySrC7qoO3KT1FlfF3RzC6aDawRRyG6NWabySMOmMbHLYaRinU3nbeNS6GIs
Oj7stffBb1nr/7u6ab6+fvGyWZzEdnl7u1m4dr08h/I/E0yn9p+t/udiwOZIzSZ03g3pHxFJq5FM
jiTo0lgk3QUdGudsZ2XFH5RK8WzMANShx4gmd26I1r5bnNh2dbuw7XKzvFs1n76stneQybQkML5s
vrGRNZ/XixPT0peAH5bUWtNZO1p/XlA9EtQ3mvbejB2EQkAglo3vQuhFff7ykKi+y2mMHCkujnDb
f9yQqFe0f5f08/sKkob2/PbL5SK0HyfE0oHcdm+debnM/ga6fb9PlsXSir+Y3cF7uFrpfeSWzHNx
EloyUePb8+VNs9C6vVgWIbUi2C2ePlwuThIpgAz5Er/uFlk+rLakAcIm0JqRyRKw/bAGXd65oI+m
vVnBEFZT2nLKdCmPuZvXln2gtmx2XTaP1NYQ+bC2riHWcvv7wrcs8pTGLklVUVQ10MqXmxt2pfMV
3GW7XW7+nFQQMZTHDM0ryB1wkwNOYmOiJHXcScJ9Hxmiti+vv8BDEA5IJbpd4k/7jXcdX1xN+Umi
2Dtmoz2Zejf7Tu+9+3F1ARqX5KE3q48g6ltslMFGnWT54m5Fvzdk2aTlc/ZfS0Zs2zXHqglqImMw
Xaz+y3GO0P59AawTY9vz9c0WQYHAvt0ClmTRi4lFDVk45eXRsvP76B9q6LSfOjzW0AfI7c83lzD0
u7/cbtYf2DJ3dkuq3CzJXCeks5GlG642L13Yl053ewxSHgODlkqeY0HPjDFt3Mdsn2NvllsE7vPl
Ff2Gaf4Jg/DtxXrD5vCJtvIL7XCJZOzZ7MeuRR7A37sFdHKiY/sXWFpzSy9t1qinPjDiRKYztlN5
zNC8duJDtWOo7EyP0s4Ak3KZiLddfiCBoJqVOAiJ/48Xb6c2nWpdv7fSlAcbssC89y50DcVuVrA6
CSJEnkl/FE8jRVNgJSAxJlm4ZuO78lc2a0rxVFug/RhSnVd82lN8vlclaKqDoT8Iv9P8c31A8weQ
o0VVMERu36wXCT6moQ0S5u6Ky4wVpY0t9kRMzihKtSX8qOHrv8FP8fI5tAKd0ZufodE1mfl2IV8S
3Br+tCEoftblL33jXL92olgHc67U76Y0G2Ln8liQec3mB5q0yRRDHmPRA0SxCtgW283DDTp2No0W
mrZniuPjVyfN+Bx83AL+OCOmSjLaEalZTZv9hiDf63HEhE3yVEAfNeFwyIKHuO1/rsWOyDCvYY0k
/wmEQ4XDVubLt59hWmtkTBiqJZm/3AJ0i1cBx6t3ZafsDsSGeVORJ22yKGrI2rym9ENtkoS2s0nI
TRnlGNPFM4s/L84c/fGBPjr68Wce0FcMdensBC8pe3YS6a/FAILeNM/k2Rn5HjAbz06Aal6dnRjg
yBKEqk0h4KMsLiQdSL48G67PHLwaclC/oVKSKT0PshRYcVlYN0LQewFXJt0LMIjPggoGrTB41I9R
41JMGarsyP7td06Tlk5VlwqPtPQBbvsTO2sQW6y2vZSAjd9SU1CVv+ZIO7L7U9j1Nyr/ERaKa3zA
Bw64n4rV09u3PRAr9L6xnSwvbMbIYsTovN72e6hJvXndmcfqbYDbPvu65hIDGmLhm+v1xxVHQoBE
7u3tisQ8x1vUjV7yWOG8QVAVxC2azpKdJjShPEYKI9LzmnAPLLKNDShwH1dkD5Hbl5sN1ZsTfQ4F
DbX3/mRPRLXN3qtSqF+sdz04qvaLubI9dDqNF5nX172mZCpiGjscwXxPGh9gtn9HIqlDmFKuX6+W
1Kd4Bn+in4svpWaVevEbzOtzLeNv+jpS0jP5KjnlaoN1pXDfsLY+DRH4AwZcU1MLm3Pn9JjVeb09
tN1BmxgfpbYdYvuKZKxlxl0tLzZSGkrf8rEWKLUS+Soqae64MsQrB7sh0iN/y2rtF7le3tDHSWWR
Nzo9YnBeV/Ghcz5NCcM8cs43xG1/WS2/rrjI+LzeNX4XV4hQf1x+uBxMAaHPqVmNsa5LYbz0vKhp
bx59f+BSJI3kof5BS96rsyfGwZq2xebvnwcP8TiYwR42PNW6hD/d/CaTLVR4HuNBGZ5MldEahwqj
NWfFs+ph0y1t+WTmMdOtIWr7rDRUaFOXHB+2F6tNI0M+Kuv/5O5rMp5nj4ZitOK8ePcq0ol8pHXq
tH9kPhoit69413hieQfJDG3h+mZmuA2BhgtMJqjourhH7N3bZ38/fQeLefvsLRvIh+XN75OdjwqI
HKMV5tX30FE6Du7UscOQSfUNkNv3m+XN9opTC4daViCiCM/Rlx8/blbbLX0Ohyblur4wpQDiNtsx
wXkFPHQ6juGrfux0fIjc/ri6knErGdDXaU9AEtjDnJfkXmVGC5iDOZPszIejQ7BO7WNL4hxity/J
p7/Cr6+ofv8irXxsebKdW8pyOPaRQkM+ra4wUQRGnz8jFR+wg+v1doFhMyeTQNU7KafMVHV9fcMj
4ymdWer4bRwzOK+zWp1NHFm66DttG2c4HOnEx/RWdb6/bOCab5Mnm0fQ3x1iKBzNb94YnAI7Sp1R
hNSgHPDbEAR8jyFyyvrTl1Udv3M0nj5nDCohdw4oHFNjPKJGCoLGN1nxIT9i/J4WJxU4h3hQf4fO
vL2JqDrhiyp/h8b+g4MSmeKcqhwsbrD0MVXlI6oyrgsUwJLhdSUPagKSHR3V1hHcQwpzg8s4mhT7
DbLRYiTbb03za2jIl5p/kazNx4YIGCxpjG5IUh8UVsbTFS9+8JZIzc/3Ve6p7SV8bahSy7wgVRPk
LRRFg8GSPmoqVfjZyrPIR9upmOZnMJHQwztNQVrWoIIGUc5UjPqtLxgXh7g0+243bhmclFsm0W77
7/E5xKy9nuA1/XpHnviWDzInLzXYzushwSN25ewBw3fe4vhP59A3ErBptCIP40JH5KAh/jwT7hAT
DimMSv20G1K9X2RMgqg5ohRB9C/6HlKqR54JI9v/iSp5NRfzPcUD2uzR8vNM+kmLdAn+YnF8fI0n
J/ZJYTDDeFziwxEKRTBYBhjU92SPlCn5mVyIPM8kjJcYoHB4qakPSIkBEUcc5JtUxfcA1POWPMsI
gJG1ZeJlUX7Ddy5UQMryhq5sBFnCVT6tYyJO1iRJFDAUDhsLgBgCo7kQ8V2ILEosbwSMFuGc4jmO
KhEbWHhfXYnzG8oeA2SoDB6aeNKSZRmMtkgasgFZJRp+gfxJF/k1K8S7yistkWWepgoKUcyMUnil
1o52wSXww8+0OLhw/Qt8SQlcBNezirShg+2cF05JF/QcKqMh804Rf8pWTgvA2CqKIk4D6aE+u8RL
xlSp0HoJhbzqXFEInnIJYBClfC0WNRWOahXgSS5HxbyXgOvZSCxFM4l/3rNpWKrVxCC9h5TAcHV9
T5olES1qU1NWoRzKHHvSIX9nsQcz/NT87igTGwTYAEdgH2FSjsoUU+yGtwUA2mA84VIhPZH94Ul7
DujE7rnYlNMMMKZaHV+9YQMudpmQA+Bo5VnjBV2fXSdXdWxv+uS9DpcKXfUNks0pThMFYAAIOFou
7kQMK49zueKzmdSucBWyAkyQizeh+myQiybOVZ/NkYdc2VcAxW2bU2/VESctliJp8hWgAfCd5E+2
atyjsfhTjAWbkzVspgDwguot1GExCx33AFqSdGh75yPGLUnsTbVpkh23Qnx1PotbIoRXXmDDtSEX
g4Bb4Pg1+IJB6TbTI+5u1meDiVWosYjcg/SIEZbpAcSvdWQy8ixyOt2pVAEaM3lfN4SIkedZLvTK
M05OKfKoWAGGAJTmfagAHcWOexRol3bd9HxWQOgBYvop95IkXrRsakhClu8RFQDqd+LL6qqcwnkf
Q+Bcrro31KlwqO6ruhCFiCruvtq6Axrq4vBbACmyhm3uIyaOj90gpDrDe+TqrpOQFpE2VjvRxDhM
LlfTgqxk6CVBwPiIKjmT35knuucIsy0GzKaTaxYiQGLj2/mAhcmb3lwz31fIrkZ2chsvFh59dTQ2
+YjdKwB2ioSbm8U3yR6dUhCgem9kT/Ox+rfP9RJcCQDGsbdq36e2zP5cvABSOnZ4r2uQgX/Hrs90
SSJEcDXTMQJ7eYlpxnCUKepK8AIEoUqCD/URpQoTpCdrGFBsJ7FHAVDSKbk1l6rDHEUwr5kOOTSi
K6kqSjyvtUDk8KZ5qDQTsPfHpPfOnHzkxO5UvUt6vxr6VU7Svp5+5knF9dTtL5/E+4j7OnJBw+Qm
r4uhKodnofSpdaUcWPEpYbmfEdrzu0s+v1jz2cVEA4YSNY7Xmi//8qEOUXOhPLoz+N+v+Woc0f7j
slyDO3AF7vCtFa85/yDy1q7wJxLozb9NaUSi4fD9WSG8mu8iPYVBQzGQCmOtnJj30fZxEulQ3+j1
fMcUNEc0g2yV661wVENE0NkGhaiut8L3wdI7vXj2pp4ryBEMPr14Dwv5RZ4nLILKXko4hqJgqMp8
Tf3F0W4nUCWHRmWIOL8L465R8+X4PUsIVLNRaMDspx5w/DFFH9l49OY8dbu/A/emj47SCpW71vHE
6KFtK/8HR8D/LJzPH74iyiF+75YnMJCmBtyIZ7jWt0MYHsFO4PjEMlD2N2Oc+ZNabxSnxSHevD4P
Na9BBupI6dk9yoz5iqjbXRGdMVzNSQ0Fh3bfIWnAsYEe481L6nczH4Mil0eYmY0gU5MwMAWZAuUm
IA/1YyCFoZChvEW0ouIcZSSLTUyBfNjFq0PaC5YbEW1MaXWC4xwIQOA8D4CVNwgfT9yd8jwKT7QQ
nhLaikDRFKeK1MlbK8halreoWQLMTxp9YgJP2slTFmx+C22/jYJteQpCAAfStpOpmovyEPiJKgNG
dqhltFysYuTArTeFBlcAkZtzk0uBF9DIWhkJBAF47pGpnw8FQNGYu/ecK0PoK00uHQpkwICTiKRQ
BWaWa/cOQJBZmzQTrEEZZdj6HKTfV0LEZnDM/X6oADSv8m8aV7JpXtZwtRgJVPdHTBpwhnotz+jm
aXXNBoJ4mD335lKNBW+lWY/9G3zxFf2+MgLgUQAA3tQ1MJjBn1wByvIbUmqCLEUYLJrLooqbd+ek
aA4uywu6UnVJ+Bq05oG6GnCCWrxIE1mLVIsX3hNmMjjjy6YCqF7loUFhJKADACDqKgzmELk0hpAW
eqcly05BH5mJys6AkSDekLipuhYANpxqXdmKwKlDuvPyDI+gZlIGPmAMeZ0ALlaANYziC93IVkdL
5lgBmHZhptVvbzAIxkZxoXstAGLToL1OQtnCT3F7WUpWsEp+BIAthLhRAIo1FUBaxKKup2NRf+C6
SKUDlRsTS5+PZ6xqXTWS4PhyD5eiRQPyXDYCGhKEsuEEkBVlVAI+KfqC5E7tvCmGjEbHygVinYvV
uwlAPmFoE22/ERWQKqCgpN3WyKLG94S4VTNkxskKIY5BJujSOGK7yhu5jr4PFf6+TmrYfWVSo0ON
qLQWRjG2Dwn4tyvNCRJPWiY1Wp6MTHGopCghFY2Ydn2QMrV/KZI7bkt5UmNq1Kqjmh6QhsMaBDr8
5yCGNX2wNDKr8fUZPKtd1OJRHw9rbHVb/Keeql0nALE0iLp6OviiFrLaHw9QMKwpwdLzBBltqNU1
emCogbF3D4iJW1kVa8Dh+Y6tOQIbwy2QTPrgxc5x/5x2bh15WKN6x0cTRN1njXscR9EDFBV7qT3Q
ileHtNzn594m8D8+mDrkPvoYHtZUNuV/HvphAgeSzOMGnwZWj4FE6P0E0wXn66KBp82ogFwxYAM2
rO8d3EBoS9ko9oBSxxhXY4LCeCaVCQUAmFBgkGkqAINMVUcDzGgBxApgFFPGIACgZcJ0tBe2lk9D
4Ykv3wcei3ENRbheXSxY3YDEe+Z8pen55ALKKVxhBwyrr1gbbRGJZCWklU3E0C64mjW9DGNok1Sf
3qyMa4rjeCvdcBykNx95XON78/OZxzXFcTwfN2JcU/lQgpLK3I6NXIaF0VQ38Dyucb3jZM8dr+od
x2a28ZCqryUj45q+cjEy1NzVNiHIuCb2xU4Z1/jq4c4PxjUcA7z4a6wAY2Vc0xc3QaY1faDhEVDs
SxnDsxWKEsU7na4z38q5hvAINKHWNjZJJOpLmeg4VpXsQABlOZrJbJXDp0Szoj/LZwp4w/f5Qf6H
C3RKlrIyrt9VZXz4mIqsg5j9/1aP5s4NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NiAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0Pj4NCmVuZG9iag0KNTcg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTg3Mj4+DQpzdHJlYW0NCnicnVht
b9s2EP4eIP+BnwZ6qGW+kxoCA42bFC2aIWsDbEA7DKoru+5iy5PsdP33uyPlWLQt2TOQWLLM5+6e
493xTmRwT66uBnejN68IGw7J9asR+efyghGWMMa4EMwSKxjRipEyv7z4/WeygJ8TJrmCNdIa+DQ6
JeX0GcWY4UxFsMnPlxe/XV6Qm7sRIQ2VfE/lAXDQaXmaWE1gGdFyc5sIDQAynl9eDN7Ms2muyauC
HNIktpr6tSLGU1vzdJLzAzo126hUacKFJpInDp6kHtRQa9rUyn21WvO0W62ywCsw1cR4xQqZNjXa
No1qX6NxygSNQil+yLmcyWfnMk/RsBSNsF77Vq1rU6sH77LFlNBvWf/tfa+24foBcLecuAS29GEC
erwKDkpk4iQ8V1aQhzlGlEkdgRgavP4APplWm0evLy8+UtHrK8rwg+OH/zowA7hqant/koe3lxc3
DwesMg1DnnVrnQjR0P2Rki4Zto3ZRqCyPIE0cYnUG4G6S6A7KMMEh2xldBqVRh4WRNgkNZGLeSoS
LYlyJrG29vHhrN1//N57/Y98QZ7uRjek17c0Wy7LnqJFNkbnf4Vn3NFPVHzqNcyM3CxMolVT/xFK
nEWcFDBIXEQJsk+mgigI0ZQHkVeMOTuMLUB/8BiJ6atjJL3rSfrhfUXy+foROWWrWa8vabFoIcRT
lVgVy+gmxCNCmnCzQ8jYQEjKRNhnQtc3hwjp3Q12aZLqGEzv12UOtGB3HK0GPU2/w21K8zncAkvt
SZp2jkLpRLpYZjdHcSpHJJCey7EBpr9iGGL8Mbpo3yyooVBmI2C/ba1WYGK8NivHGOOC0xn4s6pA
5xo9W4WH2TSbtfowlYmOpXW7UO7Gvdotl1ie0ULG8NId+PtgwXfB9LYoSY8LOsmA2HyG4fKIWf6j
NfZ5AsU4ktHqzhSqmIrXzosvOSbXI+kJBy4FVVW1zuGbpmVRrMAYTidlMYcbFkzJp+Bpmo1/QNTC
OkuXZTH2QqqqKFt0K6sTG6vu9r3a9T1PdrwHvQbIks5ije9wPWBFjNT2AFJY6AAE/HNIAgNXO1Tw
mMlh38JVwSOlsEmAqzu0v7ESAUVSu0jJEcb6VMZWJfxYlT3MuIGkr7G0riFzwtatcDeXPdx1PLw/
b34gWKHGORlnS4jI7DN8zOD/sb6u6msQgslv6BNWsizcYy0fgSpD/8IVo5f3IO4FAMgCbgqMJBTh
T7IxakCLUOCXtkByHIM4otLtV3NqFksN/tVnZnET/JzFz9nVmpEi4TG0K3mhWYzWVksvfTybzMak
Jxv521oBGVTASEa37+ypMakMNCtnZWGMFOlQX2EiDvviKmQbk/6PCczAkU9KBT/Lq/BI2mEfIeI2
QNjtJm+5lxBSGVdswCjnZijr5OaY3XWyb9SiPqX8EhXEqduoGkB58gb4QmEigOYBZw9rCOWjb67q
chJMe64yL4MMF2S4oKXBYSvvJQob9tWWWK1ig/I26SbzRknzMrwBJjzAZdc6lD9fBrf224YEHJPk
0DQcs7GR4X2Nt37FtTlemTRkAKZzIwqOhKQ7NSShVWKd2dwakjGyIySl8UR9GIqwF3iMoNNMA6LS
rY8lG24iV40wklEKRjHOgOEqnZesomAOu7Bx9rXfhsgsE/wfIrE1bmUzbo9vDwyliXKRR6Ltibu1
4D0Bc8tpZ3x64lwhUmh+O8/4trmiiaT1yCSwjdFYKzV9gk7H+j5L0ymcPOWxWUOINDEmlttJUrAT
+3BhbWLlmX14E0xvSjzDFW3rxbhkOEREmNZjR1oYx+O12HgvJtjpQ5N49+E9nNbVL63+gnNaxfhu
f/FTj2th4PDsPHM6jusmmC4L32gvVo/YqOQwVECQwIFq6KognyFE0roVn0J85G2diYBStiO4m+mp
E5qf/c6OjAaYvlnMoOtawf79tESOGCeSIsM+V0e3ErLRxvK6+Z08PmFS2bN3sgGmVfYEBPNBWTe1
RRlGmTtki32ohj5U+Ta0j30oNrg4wkzqhm311e92lf2NYuARjOSTMJCtV9ialr5gQDPsH+b/rvJF
5UOjtWJoONowA5pmdvttb/Rp9Rv8AjPGmX5rgI/4beZneu+4h3c9R0VbhDgQGQtuPSyCETxNsas9
xSt741HLYcFhMpDHnHLwsGgiw+By4wvBDKvC4ls+xrNBdbyHspAgaSymm5M5sQJwbfAN13kVoAmm
12WRfUFW46zy45t/JyWkv6tf3mSPjzDA+VdVT+PlumrbbTBO7IjvpmtPpSu3UfH/6TbAdOQnzHKR
l55OIN02HXGnIXwjfDefvVa0LVG5kIkzZyZqExw2BFKT0SFZjn0RX1cvwnkFdcwPgJtQxdeJUKZS
WozHa6xvjmZ+2M78xL15n1Mspv5LgMzD1I+w7yHvF1+K723DeGqTHQO7PbbX8UHzLg6275zDqCqO
veVI2C46NKFNNH3w3RC+ZM3L8D4ZSnjuOYfjsCW+uUNakag9dv8BXj+mtg0KZW5kc3RyZWFtDQpl
bmRvYmoNCjU4IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hP
YmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAw
IFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9iag0KNTkg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDIxPj4NCnN0cmVhbQ0KeJx9k09P
8zAMxu+V+h187JCW2knsJBLiwAYIBBIvVOKAOExoTCAG4s/3F263bt27dhe3dWP/Hj9JoLyF4+Py
ZnI5BTw5gdPpBL7yDAENIpK1GCBYBPYI3/M8eziCD/1t0JHXNS6IRuEE34tNFaIQ+p2yl6M8+5dn
cHYzAeggaQ/ZU7xiBkomMOgyYNe+GstaAM/LPCsvl7PFnGH6CX0kuyWN1yCkFNZzRkfUw2RskT4Z
sgyOTNRMaoo6WBnCun0sM6XDWB90rtWkDNKAfT1plxiGiH6fKNHLimi9pz5zCd3GXGxGFEy1iNDQ
t9g4hOXyevaxgOJtNr66Ha01nFZad04QjW5p9aKcBkEKcSY6zftgoVrWJ0pSBD1D5cW9erL4aVMX
efZY2NHYF1gHqkPzWUqpTy7C6Amqqzw7q3pUSUfIhs1srO2wHws41CMMTdY29IGMXpNoHLcN5VDD
2NtDVoZsexwUlXYctuBkx1+bdPeiZtVmvza4/8rup+8ay6fz39nr+8gVPx0Z7X7+R/PWGpEubVf9
gMjIJiYtIzFuaOY/qW/tbg0KZW5kc3RyZWFtDQplbmRvYmoNCjYwIDAgb2JqDQo8PC9UeXBlL1Bh
Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2
IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIg
MCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NT
ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1
NDBdIC9Db250ZW50cyA2MSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NT
L0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDY+Pg0KZW5kb2JqDQo2MSAwIG9iag0K
PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MTEwPj4NCnN0cmVhbQ0KeJytG2tv20byuwH/
BwIFDlQR0fveZa5nIFactEVS+GIXVyA9GLIiO25tySfZTXO//mb2Qe5SXEry9UNkajWvnZ33MsXR
WfHdd0fvJz+8LsjxcXHyelL85/CAFKQihFDGiC40I4UUpFjNDw/+9W2xgJ8rwqkAGK4VfCpZF6ub
BosQRYlI0K6/PTz45+FBcfp+UhQRS7rBsgfZ8dS0rrQsAKyQPDxWTAJCMbs/PDj64X56M5fF62XR
x4m1nMaeEaG19vs0nNIenpIElqKuKJMFp5WBldoiRWxVji3fZCslrYfZCg37cjuVhbKMBe405qhz
HMUmR2WEchyZELRPuZTwRrnEblGRGoXQlnvL1uTYyqN308VNUf42Hf94NvIynFwA3htamAqO9OIa
+FgWFJjwynBYF5oVF/doUao2BdjQ0dtz0MnNOiy9PTz4WLLRWJQEPyh+2K9H6gj+ylKP/l1c/Hh4
cHrRI5WKBGl4S1kxFvH+WBZDNHRuZ4Gg0LQCNzEVl4HgoFCml4ZyCmlpDApVJxpmBdNVbVIdU6Uq
MHBUNQlK7nfbzeUPVu1ny9vFY0FfFu/PR6L8UIzGupzfP91NH2+XsLAoUP+/lvTXUSRqqmpWMRGL
sGVbNMQgUklj7YFr0IkpwGwrI+F3g3YKNiqauCIMGClvIDhHu00gFCMRDSM2SOCmQeZK1ww+jWFW
L541VzXai2ctZKWAfod5gHHMOzCevYdx7DsggRXjYJURK73JyYM0nPQmIwfSMNIbfJjWlWaDfALI
AB8PMsQH4mU9vJ8AMsTHgQzwoYZWUg9ZR4DIW4eH6LGOwITLygwrLYAMbMaDDGymBn/UcpBPABng
40H6+NDiS9bpwWl/KxqXggjCdXHf8DWmqmVxd3hwfnjQeFUD5BcSIK5tLvOuB0CaqGghhfIe0kL5
hQ6UM+8Iyi2kUN44Wyi/0IFyphVBuYUUyptGC+UXOlDuZCMot+CgGK58sdAmVZtfSNSmiUwPwC/0
6lZJ/BPp1i2kUN4eWii/4KA2AzHtJBjKkuQiIKTDJ5RFYD4Y2DF8giHZwBmeXRZ5P+Ll5O1orMrL
0RgeX52NZJIF4ozB67qCHYDmuPIJYzZ9AITpFWScW/h35/8++r9zJLrOkEMF0pTccP5hfQUDQ2eJ
N/uxfD1fz1bIGUV4gB0GcZajMSsXuXwIbgSOllAalof3yKOw/BVdea5vQYoF/LMK+QQPOR0rrro6
RskXfhcWf3U9nc1xK3kiEFPAjEE3tfBUrpdWJcUNnNdTkGT9mKNg6g0Kw8oQPcrgBjIpt3bDha9y
mMQCWwBxCEiE+SKnu+qsc7LEYvLJ6w73b8sc0KZy8qO9fcqZFxbLLGa+bQuyr/ZD9DqlMjn72Z4g
iHIFD9MFSPE7fKXSyony3l8FEVc5DROsJ/cRr69eVqyuOtIR5Nr5eDES0TfqnjJy1XBmah+59MDJ
S2hdqD/5WmHsqQmWcQxO2p18d7U/Ll1gNfsObd5+PxsUqLeGlwaKuligbduq+6INoZXSKRX0ZnTR
NURBaS3Snrs1j/w2cq4rGa2gx+IQRnjg8OXz3AUuT3V2B4wsk2nOuqRRVv8xmcHtMtJnXaA0cP9o
u9ipClNczMDOstFHO8eLsSzGsAB0wIyIbsNQR6env1w0z4NmwfrSh5DWzBMGw2L2BX1JsT1Jqdjz
+fMxhAE8vE9pAoCTXM1R9ptRPknKWmFVsYeAfYE4HGRMJRsAIC2jp+zOsS9u+pNjCmqrZ0T+ruMA
ox1OuC9CCoXddyTItt30hTPJgQhNiKBIuTODytjwPVj2BSx/ZDEROnxiu/PrC23hwKiqBO93tQvr
b+ejXbyN98UT9DZoGRIeg5LyvqCAJZ/RPZLeXkI9A0Hx0Zc462yQJXYoxAjD2tFRuPJhHKsMidtT
+PEyfONNTJ+i02KRTBk8zz7nIzlUchSykUa99kfy9TxXgElj80CCPayqvvAWjChW1TYr2v1w+EYb
UhGWzrm8VeG4izyvDpDWAnl5efoLqu7iEkvCyU8Xg5L1xUCc4kEgiETZtr++uCadzSRU7jEd2yrw
doQloICILsrrp5Eu72w7NWYKjh4rg0XXWnraNwntJNg3lVBr0F2SHnfGmBrT5nZ660fwBBxWxLyG
laK3H7orShMVETsgdp8vQCfN98EidI+zMsMtcbBDCB1M/f/5CEeupx8u8ftwFOyLtEKRippYli2b
E32xVBKCSSahsn7yDS/+s83u6hH7ElWuj0DpX+C59l3JCmOYA8kHMI0FHEVzDBxcwTJbjkz5B9qc
I/Y1R0HXmDYTCsM77Yv3PoglO90SxPbQLUsMB9hAwO3M6gnEcQbHxkNBtOes/jtCjD7u8XsJUS9h
xQzEvoTVx/KHBUYVTGx/e7DntUSdX83xYDHiQG1pJwN2KvAyoxcKZSRP6Q6rJY3tEt08FVUopxVh
Ku0owjZPTvu2mboiFEdEJ4h9U6jMNphtmmPc4W2I7jbgLNN9GOb2wRWWJoMbqbvHRQmaRoJbfsAd
zKFGmuYGE5RJO2iKscYbaUH0sOMQOGRXVMmOJf6hx2P8K94cg13gwoQQ8uYYHwk/Hhv8zRwr/AUv
Os3xWMfgQsCiPh6LFk7AV+7RGQkwyi0g8om05OUrvDi1j2ISuHtcTypIEKQMQkccrIBAXJwgI7fe
bOpVQg1lOFHH2mNy7tcsdxrjKYtTO8DeE+1ezPkjhTMKjvJlBYn8FryNl49zN4MycMK6vAazvbY9
HfTkWDrCL1x40LWFxGmQ7f6w65uDH1/bMhMBFs5QdHaAxRirUkmGbV3ubOuUB5J7m3qLWr6+tRFo
Pb26szkGjb74efIhZ/aKYv0VU+hafXw7KkUC+oT5aoEfKzv8UOWd5Q7F/ljY7598hc45TqUxOpKy
+LXMKVdoTMIti/3q0lzhwiRPJd/3Wjd7XcsgC6b6H7YGtdUaKDX2SKEE3NsauOqglu8nby8nF+/A
6i/P/oF5imDdi1PbMdYirgwm7pT6DAfwAehyYov8d7kbCEiZKmE7rAS9qxK4qZ+rhAjVKuEUdvPL
RVDCC2eRC1duyRA8VPnnozPRYM43dh7/woFwbtetsu7X+HiEjxCJhP/ugK6XED9WA1c2QUZtKtUM
8BhYKM7jqCHfZz2QV0QleBYl77HaDo0aeKSOnim/P7KvhRj7LceOMfvaR4ye48SYvZlIONVIW3+P
Cq3B+W3IXc9HtdfSW9Da2TdZkxIVS+kN25TZNcxyrEWfF2Yj1PJ05APf9Aq36cKedRk0pZ8nuNls
zMXS2STk8idoI1cMulekLdAKC6zhhoIuVD4RCxwma3shKTh8QoYIwbG77IJjrupn0L5Cg5EQ/qui
rqpEcpRbrKPutBObJ+wDjhSRcfS2B9mA06JuMQ4MRxenECLO7dTkDM+MdSPy9A98diHZnez9cuQf
29O39NYPWMLMEJbiLdwYOsBZzq8gExqTCDuoOUl21Zxgz9Zci7qD5s5th88yals/PSD2Q1hd2Sat
cYz10ZdiNXK5zbXLcx+qc80yl3UlWSLjsMLorgrj5NkKa1F3UJgdiUMsuLQak3F2shqb/j7iAQO+
o9aubcR4CLaGwA3W/dSXzmByLmtmFIfvEbBE1mHFdVv+rOKoebbiWlSruPsnHPd2A6nTAyuu0Mym
C1TF7+tQJHTszdYHtgpGzOzFPVPu+pbumM4k31RGtyUCF8bMQGBnJq+OBlyzHnB8F9i2j9CZMezM
To+xa4OWFjoz1wi6zo2FfpH7zhKxbJfKWzT/syUoXUvIfGNp2s7RgmjXI1LSEm+pacf9xNEQkYyy
R0bRkredpuXjUR0oNKWICG03H2g5Oxbj9MVq+85GuCdAW3AxOXY0Kssre+/rbIUWj0tMv8YDobXc
tCF8/ehjEZZCTfzxhidk43H4z4WwXGQCYzKphMNGJbZ6mLMpZnhDcncX8wqLcMv3t/b1ixv3xoX0
PnbbaMVGkeLLEnZsfeguSneLpS/Fr9wrJQFn9rvXVq5B96VjIsiwXuSuetH0+XqJcEuIx9QGWbCR
cPhT13W5jX4Fo1IQguxo8TOq5uu6KQdmFhRUNB+ZjqVIb0NWUbOg1rYzcQcAUuXKTS+sIlighu7p
FKz2mxf2aszJ8oADF6T6h5+qLL0kjgscKN880Jm36+n6M37/e+74bMJIJBg+vY2WOjMTxdkC2VL5
9w9FY8yBl0de2tkSY7l3T/z7BVSj2uDA3R3A1ndqePmP3FyDE4bVXCLfsLI2Wu+csjjDhPUcZUWY
4QJ40txT50YIlFG8wEuQh3eyc8PHmL3YGdhKn8e7jq+Dy5XLiTKeqdpp5qnLMLybGMMcF5IOw8Eo
FZiOcC7qRsBvfB40IW/WzRS2ZdCMY/2QmB3Hy2EsHLFyQ11kw+3vzdA1TGJF7b8w/0srRDMqdlIq
n71lPOfdJe5xQqtU+VsOtN51KsSIecaBugqwg8tpO2Lnye5ru91kFm9H99zN1u0xWFV0B+Z2JI+1
CQsKt6pjuOCKLA71DetcAcguf0/Rz/VVW1ZFNwENuzDxz47xB8dQtNb4NnXQSSsDbpJ37i+iywph
kGXrESfOpil1kiEY53Ep2Jn9ewtLRJbej2BVRzYekNuLBgQRbPvdxR63IHtcc+xYQ3r9GvgjvQ90
+oerdvBqf1kXkBnsk820Pl9j4zFdjaLGrplchuYWaDky9w9t4kXw+/niEVdyr7KxWuB/OEqEHHRU
RXZ1VKpFQ3Pf+W2MCyWIKySbObTXSa/2UkXZMmT9NG2LyLjC6vTCVuduplt8mkPuumraO1fA73Yf
6Dag7P8PbO4DuTcqH0u9pTfL3nqjm7E3sZG3PzeRumv4niBpDbh12r4QFjliN3w1DnKSBn7iYUKX
Z+l2k09fnqN0p5TBdKUSxW2xRLqzJUoaH8Z+lhjhJpV7t/dHG6LlbAW18PS/WNB9De8F42BuHkzT
efOiBehaMVTaUCP+5l6yR+v1lB9DG2VJhcgAZtvGi3Z80SW6l+kKgm+3Ngkhc7+85dL4L0oj1tbZ
K8eyW4ggVnzb/MqKE/tZyzGuoqhP38kYAqmhLNLVTRtZo3WYHc0Z/zepSrS5xZ7ZjtU5BUcJr0jm
zLm/Oo8x+6pzCK9s4C0PfPEopjC8nY23VXIlOqXPSRSuRI9xy/O59xU79KzLy9OfnMdBT+xczvWi
mc4Zr06wlW2vtaPZcetlwQfXn5d3dtqeHUWAiMKkIg6rbOc3Yyi0fsMqy3c1HVxbBLtaNyp7o1KM
p6VpKItep6+lRM6IPoLlbyiD2SS87OH9NC3rmpDxKs2RXTf3GZHTiHuTTzvse1i0L8tsabLEq6wM
EJyisnx3K60xh4TXipLBejsNiy7hZ+0AfjmSSeHiABauJslNcXTVYTlsdTu/o6Lrlua+jhrjlue2
ILPTz6M4ra0fl3a0NFYhl0nt56743Q0MMYHe39pJSme0mLuMYNzghWEiwoZK/geeLqEoDQplbmRz
dHJlYW0NCmVuZG9iag0KNjIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1hZ2U2NCA2NCAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNjMgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyA3Pj4NCmVuZG9iag0KNjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTQ1ND4+DQpzdHJlYW0NCnicxVhbT+NGFH5Hyn8YqS/jFZnMfcar7UoQWMSqqJSk
24fdqjLEsGmTeGsnIP59z7ET8DixifLSBxx7fC5zvvnOxZDBNfnwYXA1vDwj/ONHcno2JP/2jjjh
jHMupOSOOMmJ0Zzkae/oj3dkAa8ZV0KDjHIWrtbEJH940eLcCq4Dtft3vaPfekfk/GpISM2l2HK5
Q7ny6UTMnCEgRoza3DJpQIHczXtHg8t58pAacpaRXZ7kq6f+2hEXsVvH6ZUQO3wavnGpYyakIUow
DytxqVRza9vcqm23xoi42612EFcVqSG2dKwx0sCjbnOpt11ar23lUmotdqEruHpBl5cxWh7jLlzp
/tWvb3NrBr8kiwdC/076n6+j9R5Ox6D3SRDP4EzH9+CndCHAiWJewbp2koznSCkbewIkGlyMAJSH
YrN00Tv6SmXU15TjReClfBzYAfwa6qI/yfhz7+h8vGNXtraRF9/GMClrvr9S0mXDtUW2MaidYJAn
nimzMei7DPqdNmwFyKuNzk3FAcKSSMdiG0AsrGVAcO0tc26N8e603V6+KVG/zqaLJYn6ior35GoU
KXoDT56m89UsWU6zBUH8v1H5LaptNYRaMqnre3gjLMGDuDSRgsU+5E7MLNrUihld2fzAuXcfwy2U
oEBoNlQGnJQPtel5nmeRpXlLEM4xz32o0m+RhUBj2ZCdRoYu7jMSCVndL9Mcfu6Tu7TFihSexSa0
0g2bCGAzBAw0UNOmgg3KqHpB7fR8B2rCB4rWM4nhvyrSE7IEMuTJorhP8YbMor6lyXPaBqGEYgJZ
XbfRHY9s0ECYJr29YFZ7omI4HdlNg23lON5Spp8iDcej6Az+MLw0B3oLOK5s0RKVcIY5FVppI4bw
ksUN2dENuDn5dTCK+o7eYJ6d4ApmnKe3yeKfosWYUorphrFuPNXeeEIdcofC+apLx8iOGUCaLFMg
O8QkFf2eFcvqwdNkMskx5LQAoQLfixL2DG/pwwrWTblQnUIo3oKLlhKyO9hHNyx6b1igZxh/KC41
ZXoG+09nEBty7THN37cRxioGHT/Q7Q7GNINRTMmwJQgH5R3oY6EWvBGMbrZsoUxTmZ4/JhDODPm7
SjBvUqhyjiYLuJ+QKKaTFE+zFJji5RGzSni6/J7i6zkQonwuUniDomjAQu7lWfkIT5wuM/IIgN39
WPG2PgN7DTZG2lBdBwH1UeyXOXbfyipjGCsOqaw1RXoFwA0v/hqNT8a/j9piiBWzIlDrDsHty3Lp
YAo8tJjWlenpdJ29Fk9R4eW9ItUJYwan+WM6OcZU5/SpXJ6DcIElV0pafAeRbDWbYO5regukAO4U
yRyM4r1QNMGSAT17Mi+VQCoDToFa/oTWMLkKfKwKz8X1Ty1gWsWZCffexp1NnDDT2L1w93tTR8YH
UudVsaJOmWRv0Mdr7Fp11e4w4h30acSx4Q93+zSP5jwXN5XpEDtHmpSzBTaL22dSsWQK68uyUWsK
M3lJBV4cVwftgErTJUxyL2+BXaIgd2hohf0EuGdpxbGLaxBqY4XWcMY22FKTFZ25IGAO3K9qS74v
SbAhCH8IS+qadZqcnJ3hh9TN4AqgWa9dAUCXo2HbHGcNfCyEBrvDE/vWHqHFwYNHTZeeYyFZYYOt
Jg+sIVJv6kUye0qei6pgYI1A4R8zLBR4ly42sx9qKQffNgusRCjPq1ozgOdNweqvKxYIQoEhVZOD
NSxwKxyMv0XHJd8664mAocVsBmucDvAP58AvcC6aXqLZ0fALpsHP5ScweuTVfmHGehmuFhlJJrin
ST4oE+A+a2M3hwqgA8fdh7j3NC64wAHswFOsKUMFwENJ8gr62+dyGEDgq3PDQ8LfqgYY/N8AtI3j
zXC5KRYNQUBJlILkDpYSKAnrgfKtLrGuB8EOuyHbe+D2nEl1aM+tK/+vI3ewkS1k/gMc9TgFDQpl
bmRzdHJlYW0NCmVuZG9iag0KNjQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl
L1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVu
dCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpzdHJl
YW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a
Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAcwBj
AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF
BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq
NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E
AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR
BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG
R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz
tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A
q2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/oKVz1
fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir9lHz
+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRuAiKS
T+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf+b/4
qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v/wCT
GnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD0SZd
hP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1xNpV6
33IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTNZSn7
0kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2ELj/
ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP3QW4
A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHLfxE9
OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvbue4c
nJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+Zcqd
dtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy/P8A
Q4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQHFza
TAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6TSatc
qMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8ia77
wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaareW6/
dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0NjE1
ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvBPy/I
5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+RrptW8e
DWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr/o/C
OQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1haNb
yWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuPDlr4
3k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8AErQb
6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzCZG05
llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5Pqeu
fWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4HtvC
VlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/Ix6Z/
19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3h8KM
J/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVnTScW
n3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2YPn8O
v6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7WhW1q
qz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41WOPl0
a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j/px+
taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+EYVv
NVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVyx/M1
FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxINd/5G
HUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzuH0rn
v+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O/wCE
v8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9/wCH
/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/9A/x
F/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKPr
lf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNeQ1r+
FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0kPhR8
7P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54c8I+
GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+wzXov
hXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNhbacT
MzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeGrLWh
ZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dvrGCa
WOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u5ma9
R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+Ho8a
dbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1ZtLXRb
lr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rmnR6X
dardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/AK/4
P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0XXv8A
kYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm7+HO
hC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy952/l
SRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRng05Z
5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7elKZ5
TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHpmmxS
yQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5HHRP
+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19S/8A
oZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f/wDf
9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmfib/o
O3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//AH/a
iij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCEz8Tf
9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/2Q0K
ZW5kc3RyZWFtDQplbmRvYmoNCjY1IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jl
c291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAg
Ui9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0
OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdl
Qi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2NiAw
IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv
Uy9TdHJ1Y3RQYXJlbnRzIDg+Pg0KZW5kb2JqDQo2NiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj
b2RlL0xlbmd0aCAxNzg5Pj4NCnN0cmVhbQ0KeJydWNtu4zYQfQ/gf+CjXNQ0h3cVqYHEuWAXmzbd
uOjDbrHwOk7qIo5TO1tg/74zpGSJtiS7ebBkUXPhHB4OZ8SGt+z0dHgzfnfBxGjEzi/G7J/eiWCC
CyFASuGYk4IZLdh63jv54wf2jK+5UKBRRjmLV2tytn7caglhQehE7eGH3slvvRN2eTNmrOYS9lw2
KEefDnLuDEMxZlT5l0uDCmy27J0M3y2nj3PDLlasyZOsPA0KRwJyV8TpFUCDTyNKlzrnIA1TwD2O
5EGp5ta2uVX7bo2BvNutdhhXjNQwGxxrirTu0bV51Pserdc2epRaQxO4INQWXBFCtCKnSbjgvXLr
29ya4Yfp8yPL/p4O3t/2izmcT1DvCpjnuKSTB/QTXAA6UdwrHNdOssmSGGVzz5BDw+s7xORxUw5d
904+ZbI/0JmgC9AlPA7tEO8mc/0/2eR97+Ry0jArW5vI1rcxXMqa708Z67Lh2iIrDWoHHLeJ58qU
BvMug77Rho2AVDY6J5UnCEsmHc9tAjFYy5Hf2lvuXIFx867dH/4YUL9dLZ5fWX+gMviJ3dz1VfYR
n3w2X357mr4uVs+M8P+cqc/92lRTqCWXuj6HA2GBSOLSTALPfcqdnFuyqRU3Oto8FcK7UTqFAAqG
ZlNlxEn5VDv7ZYWhsb7JnlfPLYHkuOO1T9UGLbIgPAeXyk7XaH72F+uDyxb4d7P5Nu/rbIMDPps+
4t/pou+zNvfSA5cqNdmNIyQ4Ggae78CoTcQR06rawnh+2QAj+ETRei6FrytmV6s1e5guF8SHJ7p8
b8PGeJ6rRLcVRuu4yBPR5eoeV2qOHiSGDzILDissBzZbr1ZIWZc9rFdLhoIumz/2bTadfWcva1rn
WZDdrNabNs5qyXEP1v12Qy13KAtmdyvi6llkj8od97KdsjWyNYhLN9J4MxJ/gCtl8e4wpavRwOG4
xmet6XTBu8fxq5E5ja+B/ugzfOfjO2PDO+NGqi5iSESOBjQYRKMJXXgBexpdhymEwWCqFCfPRhUz
GNMr8tbEpz2AVC6RjEnEB0BXR4OOidV1p4l93XIFKt3sOpLsFTdvSILEJjyFvs7xCXS2LKlFj7jV
py/Tr4snZN4CX7zij+7zTRRQIvt3MWXEzpvx9Zcxpdiz2x/jS8wCRGEk9uzl2wIt3LcRFYsRm8yx
GzLdcOyUIOGRaPxRVsyxiUUpycG/JbPUNUNqoX2vad+3JxUPqVp7VgmnYiK7eSHrM7yEfPKwoEQy
C+kkSTBtyTk3eIKmJrsxtEeTF/A89m9lb02ZSibKmTYQFeHEp3Y8reZKpfqteGLtY3ZkNy9z2g20
PYj1DwFEwlNZfCAon3D4vhVP5znWIInJbjzdLp6KK5kWQ+CwsMGlAu46MnDAU+8Wq6DMrnJ2QwiO
rymyLxjQePIBj+/hDQI8XuCGdhkOtIUnODYAibXu8PzR4TlF5dYbw6spF+HhwoEI8d1Nzia/37H+
rj3dYE9iXqIA08mcw1GTkVpQLZ1MZtdtJauxVWmY+N3414tQWWHimFNyDYUAjuSBmzgwW9DIwwJZ
qbBEWK9X67BBZqTQ7E27nHvbPrP9ddut0WFn0YwKuBsXQDhsUO4Wx615Qyo8FOwb80ZdObvCxSds
VDyatsfV5AOSXQeytzPdYx4xqb3uAOFopuPtUF5sJXqlG04XKiT3t3M8jaXL7hcU+Gb69YkOBDzu
pckCe/CQBsCDnJTwMJfQYOXLbd9FMz8z0UYs+ragk2l1o7RXcLahBHm9tv9/KNV0d1CqskLH0svw
PaFupDumvXquca+AVxzaU0r9UNqTVjbWz7GM1uN4oxr1siqDQyWtq9L3KkiVNTaWUKE4DrW3bUJT
7iUz6+rzOICCPg4F7IykPR6GVFxiaa7zImTqC2Iv4MMI1uux/A/dRdVBlB1GqO2py7gYDYLaOAjo
snswo0EN3RLrwui2VTHRVyJUvjRlmzMayDr0qrBRrkiQDB2JiR5ssXS1abtWL0HQxmeSPjf11mak
GgzQlzsVPBas2GIliq4KtnM6L0z7Q9GGeUA051IahvZpHBdnz3eBe9HaFVw+i60YxFsBYB2egNpZ
rUOLUDU3aSn1rM2JRHUuHeCyaWg3SgIb4Pqo2kceXSoDVR0dtc/OIbcjLvOquTYVW2n9FH02tREw
LSmP4M/Rp9R4Vz6OkbwSBZdIiQZJUcm4KYoGvuQGiLCyxWKF9Q8LpqvOu+rMbWytdbFLIzUCH/Ji
ZnbLqzAJXTbkJqUCCeTlZpaxuT+ySTd0qKTIHVi8o+tygKRXbDipmgrN8qRKlVXxYQQBijkhpPgQ
uYQqvcc8dRW3Ib6DPGaZuESRDXGl4kK5iFdMmfVPKWEbHVXaxr6mPt19/P4D8pwsBQ0KZW5kc3Ry
ZWFtDQplbmRvYmoNCjY3IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNl
czw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFn
ZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+
Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn
ZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2OCAwIFIvR3Jv
dXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1
Y3RQYXJlbnRzIDk+Pg0KZW5kb2JqDQo2OCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl
bmd0aCAyMTczPj4NCnN0cmVhbQ0KeJydWVtv28YSfjfg/7BAgWJVVNTelwwCAbFiGy1iwKcx0Ie0
CGiZknUiiT6iHDf//szMkjIpkbSqB9Hk7s7t29mZ2TEb3bL370c3k98+MjEes4uPE/a/8zPBRCSE
kEoJz7wSzBrBNtn52Z+/sDVMR0JLA2u0d/B0NmGb+Y5KCCeFaZDNfjk/+8/5Gbu8mTBWEykPRLYQ
B5leJpG3DJYxq6vXSFkgYNPV+dnot1U6zyz7mLM2SepV0rAUJGTiSztjLWWLTCsqkSaJpLJMyyiG
kYSIamJdl1h9KNZamfSLNR7sCpZa5kiwQUvrEn2XRHMo0cXGBYnKGNkGrhR6B64gE51IUAlP0l/F
xl1i7ehTup4z/t90+PvtoNTh4g7oriSLI9jSuxnIIREShOgo1jBuvGJ3K/Qol8QMfGh0/RkwmRfV
0PX52ReuBkPDBT4kPuhz5Ebw13I/+Jvd/X5+dnnXopWrKbKTbW2kVE32F876ePguyyqGxssIjkkc
aRsYItZGO3Y3/cKl6OMdt7GLVQQHqs6OOPUqmTQQV0z5KHENyGWSRDH4sYoSWULefogPh/+gTbjN
F+stGww1V+/YcvE9Y6vBUPHFfJNuF/m6pl0DbakjYety37BEioYpBhQHvZuWgFOCKVZHzgeW74WI
/bipAcIgm5TaRXHcpORLdKIFPtAiepkPNEej0NZ8zQblfFE8ZwPD33VYqpTEfWsw77dUNiy1TLo9
S8FTyVLQW+idpReXbZba/Q33PnJxkxjs0HyGVhoO24bbt4WRDHZVST7b5HiwVjACAzH/QM+/ACHH
080cV+NKqfl9uv721wDePdHnSM8v4OlgeQF4IY90iYQ4VRF0AGeci6xrKtoPnNp3EbMfYBIZSTg+
RonI6Dd85IBYQuyTtkHMX8AFpEBv8eHBBsrz61u0+Sc2iHm6BVDZANYAEIa/PGboPmuWAhzTaYYI
FQUbaMtv8H0S+H2FpZO7Tx3IaCci2dSjHxh9NDDCRlp2A7MPRXO5+iiEMWMLr1aCQ7rw6iDD6LEU
+K5xBfz18BfGzUWY0/U5W85fjYdEP6E1Spa8rApzHr8TeI8Dj6TkQfS4xoZ1OI5rrBgPUU61FudL
3rLiTfITUhtJpArsTBxISbwP7MN4UA3Xa2CvEARYoz4E1Y0am2oIOGsdhsXVThPt3jekkuKTYJzx
tAR1VR8CNa4W7ihvxUwNibK+RW94iWnxEtfqJjoBB3wrxh5Sl15Tp+YXEBKeMVqwCwoLUvJpCt4P
8VUqCLNLjD0/KPbA1Gb0QuNFvspo4GZCyQZP3lc4UZOB53Bs8MRpiE7wMsPzl23oBGIYdxThDN9m
XWHHWAiQTSXZ4F/EB+0tprZjELdH5jQNdWZyUk6rU/L0CQx/wiyWp9PH/YSFFdkeE5AN5UaTSb9F
7sjcpbWK9Km5q07Mr8CmfINBlfJStsF0pfimY3uliaGQbbIYdq21Diu4xlpMlesZpTYI2Z//AOlF
V+bXNrKmSd6Pnj82TmvA1Z+awOrE/ClfIGzr7RLPRlYUCB6dnm3O7uGQJXRsYjw22+yhy9QYSkLX
5Lx/aPa1EDJyxwWm+EinUrGJYnmiU9WJ952KNn0B8QUD1c9P5F85zt5TjaTecgQjI6OaEvotTo4O
xcoBmvGpobhODUZDzbah+BrC6vVXGJl8uO0yC1JLkjR59JqlDmp4wGUv4HhSCzY0dm8YpZqUELb3
KPFCCBt4D/uWrmF7vhVgzq+UHIZQpK3RXPL2a3zewudPLERHLOvv4W2JuQOZrLDan6bP8CyyB6x2
PS34waqlQQLOWOL8DL/VPaQ0ou+KRlCDRMo0te6HUB4LoYGb1UkIvhLyz5go4YcXg2X5C8YX6fcK
mxG8bDKMHsUW8AnRl77ZyyNeI6jgDbcHj8HEVzep7FeCb5qviwUg9VAt3iwQzHkgAWGzZzp6hkAt
WSMvdE1briHCf7YV4CivWFTqdN5CjcE7f93kfvQPbhhd6CvImOYk+GuUgMxqBWaTbz1UCC7LDVlX
cNEo2YneW+1XaXg5va1G4OKhd3tJI1BRDROePsA3bc56h/srEYJuwv5uFtPtwL1yfWyoUWpcEw7R
pL5PRbZleFwaq+Y778DSbPrYauFTdV7psezYUhf7KE6aMPbv6dGXIwW545hQ2x5pa8T8qgqzLVe+
GMJWV7x1kZRNTv2mHVT0Xe4KufjEeFujpHABcUH/+7ggWwND6StVoJWhBfNc0RJbco0iZ9+yDEnQ
SVhROVhwHnTX4Ma4toPFfTU0C3l/Z0I6Kw9VCE2MNquu7KJi3xVlnNfYM21A1b9vB/eCLpeU4O09
1/Vej6zR7jnkNSJZ+uPoBsybwG9BA/By9wl2R0MwXtN1akZNMKgMCWCZ1DoeKV3eyrYIzDwtsZii
eUB51ZUToV52De36wXJHOrmEbfBvHd9WJ69TAkSaEHKAEDjE5A7N/xSsh0oQwzTGriLFumNXQHQW
znDFgMK5IaHf3IM7Qpe5TkSx6jPXdJnbpNRirMsmhplgTwPfQwND+/BXXYXeB7ZS1K5PEtooE2qB
ULPnclx2PULvxtOMVTva0PUw1LYh2itaUc1IE6RdIPfWJkjTHKy3m9Z030lKyw0kj+OyxrF3Eqlp
f066ktRo+STEzzW2MuAQTdMCXetdmVfR0zRdU75nNL8qP2vtXPzEtvVQS/7yuKAyQFet2+83k0tq
1+bT6TMG7s7uiMKmbF2zfpzabjLtoQxgODW51mh5ep9vIG2ATa/3VgpRnf+LUDLG/zrVmfTapA+u
MZ02CYG9pBONqhHzdb4N0fZHCK4JXM9zurIX8BVjBsSIu32k3ha1xqgpBq9K8Hm+ZThRQiMg72EZ
uH0uaPrn0FvL0qITIziVEXpzXacDkP4PSmk7Wg0KZW5kc3RyZWFtDQplbmRvYmoNCjY5IDAgb2Jq
DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUg
NSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEg
OSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDEx
IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJv
eFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJh
bnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDEwPj4NCmVuZG9i
ag0KNzAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTE0NT4+DQpzdHJlYW0N
CnicnVbfT9tIEH6PlP9hHtdVs9nfu64QJwi0oioSd43UB3oPvmCSlGDn4gTKf3+zawfsJDYcL2t7
vTPffJ9nxgPDKzg6Gl6OLs6AHR/D6dkI/u33GDDKGONCMAtWMNCKwSrt9358gAxfUya5wjPSGlyN
jmE1fbZizHCmGma3H/q9P/s9OL8cAdQg+R7kAeMS0/KYWg14DLTc3lKh0QAm9/3e8OI+maYaznI4
hCRekAYVEOOxrXg6yfkBTM22kCqmXGiQnDrciYNRDda0wcp9WK153A2rLPIqmWowAVh5pnVE24ao
9hGNU6ZEFErxQ+JyJp/FZYGiYbEPwgb0F1jXBquH35JsCuRXMvh6FVUxnI7R7jMHR/GTjm8RJ0Bw
BJHUSdxXVsD43meUiR1gDg2/fEdNpsV260u/d01ENFCE+YX7JTwOzRCvmtjobxh/7ffOxweiMrVA
nrG1pkLUsK8JdPmwbcy2DpXlFMvEUalLh15rJQ2MJ9eE8y7f7pA7JygWVN1d8NQZZNxQXICwNDYN
yQVTlFv0bqi1leaHq3h/+6/wFa7yebaGaCCJ/ASXo3O8NWSe/UonkSTreZ7VAmwIzhWN68CvcOGs
QUaB4LtklKBcKVDYCIwrfR4x5uxxM4KgBNtLvpjGrGlMLpBGZMgE+XFGHi5HPsWQIVdknQO+SRaR
JYtIk8D6YbLcFC10JRNU8Kb7br68wVcDd9Q1Q7au5Ms1xcuW7+n5Ab7cNSw5wx7WMCQn2ZP/iIBk
VnNfQsWdv3+cpRkEYnAMy8kyUmRTfES6MUmyG3yCuafuv/d67uXJswLyyWSzgmQNCQR90FueTSPZ
YFxXp4xHxjJQDPGU3u5T8NaP+GBJdpOjj8c/WpwIgXR400u3xGInpVCPeEdjjmmKeS+toFJ159Qh
ayl2rclnFC1fBQWRliSZ++hljAZckzXepQUm1rrcsmSON9nN3Gdh4gvKH/BnY5LftaWaNFTJJmi3
DvKADuagDJr7LvmqDOagCjXjSoUy4wYOc0SSIMbmd6WGKDfWUXVikmTbW7+XL1JcV8m6TBC/NZtj
vhZeHImni61Skvwk4zx7CqbfNhPcv/sZtXUl/8vbCbVbO/Vm7SSj/L3SvdjuKvc9XySreYHUP5b6
SPZ24bhoKmd2hTvxjmd5u2C+geMcUQ+wWy/9Zr2Yw3p6r2A1YzLKMZ1I5r98uso+le0aq232tExX
D/6dF6wIRSkUKWZe4c3ixj9y8k8K003qVakkRctkmuXFusrZSWsucV+AjVC6tTFvbfnCaardO1p+
3ZCcLJc+FfJkMoPIkVsUIKhRdXls+D7L/Jlqp63h4OzEZN0394OC8auwLswPzZ1ydOgWw765OQuj
/Kj1junl/7fyGtY1thXft1IsJuzPVT3NQ6K0/KF8vLLpo1sEtyuCpFI048LR3MelNOWvtRe1O/Rw
43aNyY98VfgswKFHMN8PkBh3JPyBizAIhXJ4PnEXpoWFfx0WPBKXp9dFuvC/udu2vEF0nPcb6Hty
/AePjAe7DQplbmRzdHJlYW0NCmVuZG9iag0KNzEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1h
Z2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMSA5IDAgUi9GMiAxMiAwIFI+Pi9FeHRH
U3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1h
Z2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MiAwIFIvR3JvdXA8PC9U
eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl
bnRzIDExPj4NCmVuZG9iag0KNzIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
NDI4Pj4NCnN0cmVhbQ0KeJx9k01PwzAMhu+V+h987JCW2kmcDwlx2AYIBBIflThMHKZpmwQan+L/
43bryFi7S9q6sZ/XrxMo7+D0tLwdX00Az85gNBnDZ54hoEJE0ho9eI3AFuFrkWdPJ/AmvxUasrLH
eCer4whfq10WoiO0e2nLkzy7zzM4vx0DJEg6QHYkb5ieovIMsg3YtK9KsyTAfJ1n5dV6tlowTN6h
i6T/SMMtCCn6bZ/BEHUwGVukjYo0gyEVJBKbpATr+rDmEMtM8TjWeulr0ymDa8C27jQl+j6iPSS6
YN2GqK2lLnMJzc5cbFp0GGsRvqH/YUMflsub2dsKipfZ8PpusNUwqiTvgiAoGWm1FE6DIIEYFYzE
rddQresT5WIAOUPl5aN4svpuQ5d5Ni30YGgLrBeql+azdKU8ufCDZ6iu8+y86lDlEiE7NrPSOmFP
CzhWw/d11ha0npRck6AMbwrWXlvjoJpPC9LHaoeuckEruVBpuabSUZFxz3ENNT3xW0fpWYLiut36
3X2DD8MPzQRGs/nrz0eioB3tP5DVTgWXkvaF9+gLrEKUNHLK9M3kFyfA77oNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo3MyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Y
T2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDgg
MCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBS
Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAw
IDAgNzIwIDU0MF0gL0NvbnRlbnRzIDc0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3Bh
cmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTI+Pg0KZW5kb2JqDQo3
NCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjA5Pj4NCnN0cmVhbQ0KeJyt
V9tuIzcMfTfgf+BTMRPAsiTqCiwWyNppkMUaSGMXfQgWCydNjGxzq9Oiv19yfNkZW5qpnT54PHFE
HfKQOqRgeAkfPgwno4sxyI8f4dN4BH/2exKkkFIqraUHryVYI2F51+/9dgLP9G8hURlag97R09kI
y8XWSkqnpGmY3Z/0e7/0e3A2GQHUINUeZMJ4helVFN4CLQOLm1ehLRnA7VO/N7x4mi/uLIxfIIWk
fyAN1kBSRb+OM6BSCUwrN5AmCqUtoBKBfomVUQ3W5WBxH9ZaFdthjae4VpFacBWw4UjriD6HaPYR
XTBuhaiNUSlylcQtubIK0cnITvgK/QdsyMHa4Zf58wKK7/PB58ty7cOnGdn9rCAISunsnnAqCAVo
gqDYgjBew+yJK8rFAFRDw/MpcbJ42/x03u9dF7ocmELyQ/Gj+nPohvRtC19+hdnnfu9slvDK1RzZ
YscooqlhXxfQtofPRbbdUFkRNG2IdrUhc23Qwez2ulDYtndIbae9QNPYrtqp1cnYYFwD7RFdg3Id
rIgKTHDC+zXn6VO8//NVlYXJ6AzKgSsm0xKLq7eaO3X3DaLAOkyH52ojO0yaV4xokJ7KqcodRaUS
AmgbQNHBcJoIqip0oysG/qmc3jVmp9utpyl31A6TiopXN6tX+cAZ0i4KxDWV0TF6lJpFyYc1k7u/
roksTTE6/1baYnR6maFROzp6vo7RxaPu4pEkDEFLIxxmqMyz2G6bJBL3iNwhMQrnQNPhifYoEpFJ
HM3o+0uWRMfs1TC6SNyoJyNihbvxgzng4K3MkNc02fKWtUmSZhOCQGkQYfV1ZLlVTE1npdPFaWl9
Mft1mmOMVIJafg2rizHXXnZI58dz41QcfsUC/tey67JNMuhTkmoC2WkR/bH0PZQDX2yKjTtQTvzo
1DawuugL2YLj6LFN+BIF12qTpGu3cSTkDtFy/36f3D1w5/hGb9syDAWzma1EQ2fH6AMEUMtWKl2H
9mXYbDNLEar3+8fO5GMqMt8le6tqPB2PeRC6yhJI1gdon9Yt/FX6f5D2tdokmcPkyfWCBvz3ad+K
rknpiovpKHtyaVCIBwifrg3amZGJtv0OcK3Ifw1fCQZ+hx7KCIY+hMCvCnm0h8eKk+TFxe6OdjvD
SCRYDdHRQK2PmusWjy835UAX88dsG9WCbhA1iC5u3J7PSVUJVB+SkrbZ9PVumXEB/aov1VcPcmt5
0o3NtTfz5z+y58Tw+N5Y3h5dqsVoa3ngNZoPQmc4OlI4qrk6G46kcLC59vb179xqGnjdjh/t0YT2
Bm69FJYSqOkmSNMx8qGu3epzvbvFLHn49/qQblSLJcLomPBAR3V7uA5cPFPreaDPX/T5iav9lZRh
+cI3yBt6uysH2OCpzqmjBuCpD1gKJq45ZWGZlqy+JMFv1b3oJGfOU6BqmremBPOdzBLXiu5WrKx7
uUiocHZ9KgmoEoVtg+RS1YryGY5g/my5ZG5fmPPccXCKLeoY+ePgqKG5nbWc2GdKyP0LJSLs5Saz
kcZKgEjW1GajbApRCauaa9tT2HEb49GCkoHO8oR72G2syzaZ2o7bGFoqDkMyS/Or+l+G5FybrVS2
hpMg8l+7eAi/DQplbmRzdHJlYW0NCmVuZG9iag0KNzUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJl
bnQgMiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIv
SW1hZ2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMiAxMiAwIFIvRjEgOSAwIFI+Pi9F
eHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMv
SW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3NiAwIFIvR3JvdXA8
PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQ
YXJlbnRzIDEzPj4NCmVuZG9iag0KNzYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMTg5NT4+DQpzdHJlYW0NCnicrVlNb9s4EL0b8H/gUS4aWfyUhC0KpEm266Ipso2LFgj24NqK
m21sZ2Wn3f77nSEpm5RFJgL2UMUSR+89zgw5Q5WMr8irV+PLs8k5yV6/Jm/Oz8g/w0FGsjTLMspY
lpOcZUSKjNTVcPD5BVnDcJpxKsCG5wquSpakXu7fyjJFM+G9dvtiOPhzOCAXl2eEOJT0iLLjZcOZ
0zLNJQEzInnzM2USXiDz1XAwnqxmy0qS8w3pYmIHphNLlNEyt/MsOKUdnDJrKEWZUiYJp2kBT0r9
kkOrQrT8mFZKWsZpRQ7zMjOVRGligTN1GfMQozhmVIVQhpEJQbucSzO+d26mp6iyEkXkmv1AW4Ro
paV9MwXT3xlheVoqMr0FbA1LCQMf5gw8WUDCkOkqmEbjt9fgluW20+Dj2+HgJvlSrcnH02syOpHJ
djfbPW5Hf5Hpu+HgYtqhTTnaGjVCKUB11dwkJAaSWxCQUaAYqSWVimrNTKG3hAQ0mLtJVVZqTzb5
zyAI1oCCk4/GeanSPQTPuiDQBTCBNC8ZXIuCudyU4h/LDSnE29zGwHC3xi23sbDcbQjNwpV0WZTH
YActg2qh29EGXbWRaRlBNoMhZDMaQma51L60yDz1/WKHLbY7atDteIPuGsD+k2M8bFCUEw7GhTsd
2iY1w5aUHpOa8YbUe13j06JMD/AibQXbDFt4b9Tgm/EG3n/d4MPDQyrDTTuVrcGe4jiVrcWBpDhi
KU1+B6dhx8PzsAadE4F3ioLsIyKl3suCXHY8zGUNOrko+YkX2Jxgb/mbmAVXlGRlsdETktwPB9fD
QbPazLDFdg04gg2YTju7H4BhninngbGkrqVZvY6leWBJjZFdhAcj+8A3MuvJMTIPPCO7LA5G9oFv
ZNLYMTIPPCOTiwcbc++bmFRybMwDz8jmwsHIPmiMzDZpg2JSwgsLvnWwsHe+ifV0UXiCzb1nYnPl
YGMfGKOj4lK0qictvNLJeSokJJTK04zpYkUxr3W+3SSTXTUSySpWvMqOCpjD/EoP9IkKSLMOFCa5
dpqLcv1kRaa0AwqaoZTzPoJYV2HHVqbwUc42q1W13sUl8Q4w6C7TopePhBdJCg9SaGe7ggmbOo21
QcHm5/JsdMKSUzKiMrlb345UUs+2cN2NeFI/QirMd3itK0eoOyla0BQaiIOAp+YkI3F3QLbA//jw
sKnhL2qpFgEBHFzAyh4COhs4G2cH5HLzowKv5MktemIzksmKLEYnPNnA/Sojuw14iXz7Bc55qEYn
4KIfd1uwwuE6oFUJqbvWZ2vNuzLbhJyXILlJyQsMIhmVyWwNehZklCefzj6chmLGYbV6AHEVRThk
LkjfkD1fQNeOY0PmgnxCBVW9fZjNK+MQLrSSjf13jwbkHn8ulxjLu/WSjFjuuE3/mt3/wjVwtw3F
EUhVDw+yrs2uiSO0xqpsZrCeb/RqQylVXetkgr5gDslY/wqogWM1lAMfKC6na8NsAuqi9I7o8yVE
dlsP5VJHcrWpcaFhhqOmef349auJndy7KSBNYpBUH2lde3cjjcMW3qC8xwzisEdkSfXvw/3dXGcU
+gl0qeQn3tZwL5LQ5ikBDrW5qCdB2zwVLQVfZ/PvwFU85QNFoc3zX427QETyNaNwaN3XQkzVA792
BqQrxgwfRLKWFnnahouLilQOD6V31j5fQqR2eCjnsx2UghluNfBn4booFF4G7hV9tHTVBquFFXA+
alAmayxLTj2/Q1FrgrW+2s2/mQR+Qh1Ueap83Li6rpphM4jBoYPmTbfCuMTPSVxy/CPFvl85HjAd
y+kVLqyLiW5Z3lx8xLtpKMmoXjQO41O6u0qNTTIP5fPpJETKyhzT6vmkvKs8NKF0Uc6xOEDvgaHS
28v6JYQSd0V9N9ObDd5+x02nXlf34CTo6KrZIrQMFZe4BfUQ29lt28hSlaoGxYsThkkk1+E4Ka3C
fT+uoqt+NHFyUfpuBj0kROqEh9JE7dBkBLpGvRKhAQgVMplmLehQsVCwjbRMfza9a/092J3SVLI+
HoiUCZrDuYB2psLkw7tgGnBU4L0bVxCpCR5K3zToISFSEzyU48UbkIBfALJeXogcEyiD0ybvisMf
F9fTMX7zfgu/QgFRJZ7uPJC4lMhZwUP5MA6dTlgBO1LehzNyPPBQ/t+F6EHHF6Jn+uyF+HwPiMj5
omApy1nLA19wCayJrp34Px85nIR22A/UtzPsr0MNK2MKp+5hxpVFjhoeyufJVTAfwA1lH87I2cJD
WemOvbrfLF/qU+D8Ae8fIfpUB2h9f7eGlKj0KsEHt/YfPK90j7/YYCpVv+kFRbDyNpfA0jYqlIRe
r+mjXNZvG/vpZbZYvNRfH1YVjjbnH3ecwE+tcolBhdNQ5LBatjjj/uPj9zM4XCV/z07eXY1a36CK
o09QokglRDMV1rEZHLT0p3LzQzdtDJdYhheKF307VmOGns2jYjprTAnbknAon5qRDM3o8LlQpgUD
RC4NIvacgisynd8kVETBuwoAh7XLhYenoY5k/gdpUVQoDQplbmRzdHJlYW0NCmVuZG9iag0KNzcg
MCBvYmoNCjw8L1RpdGxlKFZlcmRhbmEgQm9sZCAzMCkgL0F1dGhvcihJbnRlbCBDb3Jwb3JhdGlv
bikgL0NyZWF0aW9uRGF0ZShEOjIwMTIwNjI3MTExODQ5KzA4JzAwJykgL01vZERhdGUoRDoyMDEy
MDYyNzExMTg0OSswOCcwMCcpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAUABv
AHcAZQByAFAAbwBpAG4AdACuACAAMgAwADEAMCkgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBm
AHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApID4+DQplbmRvYmoNCjg0IDAg
b2JqDQo8PC9UeXBlL09ialN0bS9OIDUwMC9GaXJzdCA0ODA4L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggNjA1MT4+DQpzdHJlYW0NCnicrV1djyy5bX0PkP9Qj87TLYmkPgDDQIIkSGA/LLz7ZgSL
Xe+FbWDjXWx2Yfvfh0dN9fT0lMia7nmYW7o9JZISeQ4pqaqn5W3fmmyStla2lGRrdUu1b61tmWnr
+0ZZ/9c3annreWPmraeNe906byJ967SVlLZetlK1Q91qlq23rVa9ReWhu/56ly3tu/7khH/0R+9O
u/4katrgLWX8D/flgk/UHhL0Uos4dW3oD1ftnlSOZO2hepOonpRUYCGI156l4Vf6U2uG+C21jMHp
T9MBYZSps/6T6pZ3SFXpea/opcNOucEWbeh4U85bzqIq1O5MUJhJGxVmis4Rq0A1JXPHCMqWRdBd
JRe9EbJ0NPqJGpcro7vqqjoxiVRg0wlMpCo6hkMquTd8whvtgk9kI1iXqGoDw6GiHsFwdNbUNapd
LSBSXyVSL1Efs7URF9Wln5JgJjhrA7Oq7qOiCpOOn8q4WSVXgRyV3OAHVskNN+un1OEvVskdQ9Y4
4V316PRvPJymVnLC/AhtnIdDijbGzbIxoifpjDBpnOA+DSC9uewby7i5a6PozWouF9xcVHLBZBaV
XMfNKrnterPex23crHJ6gqsLQhHO75vsOjfqfG1gWuquUY051IiRjDnU+yQjNtTTQoxPaBNG1NWi
jYLQVywIhqxRpZ6UAQYpCNGqkgtCoqnkKogmldxws2JDGgCk0qULPlFU7IhlFVF2tS4psAqiKel9
BQqThkXJiB81V4eOOO1bIQxZ1RTG/CjWCmPIgJlgfjR0imB+9KcU9VVSL5YKBAwM6pSkrnIa4KA4
1OhDmKscGKbxvtVdUaK31F1nBKCrRScrq7UKGA1BRV6tbUBiq029mPX+ikDIirwGxGT9abt6SNGi
8EZMq7UN488ab03hoA3a1AgVqJ5qVACtujUGSFRWU1dqA/SjQZlVcSs7GiqwlIE6JaMBPxVYddKz
oqo1RqNoo0MguEnDK6sFfde4zwq4vuvgsgZ5R3gpaJW4AHVFVc8VDeUpUmhlDZhOHQ2lLBYAe1fS
SmioHAELKvK6ukARrnLqjobeUzF2cGEb4FeBTYMg6329MxqD7nSyM4Pr9oIWWG1QA1y8IzSyDEpk
MAkYbkwXjVbBxBUwI5SDs5QR4AvIK+qILBcWBecwWnDZIMzhMwToPpwGdO4dUQC20Rvx2wb2BCmB
JxKiKhdwIyzKZdBywmeDQTV+M9ChhKKjRYQpJego62BTtSMjwtOwCrSeRkAN9q1gwDrIFrN5IVmM
aBB5x3wOAu/aLwMVGpAgRtDqrtGvXAnuRTw18CkiL7dBzGpRBkLV1WiBfwlzCrpV36AF3hbMKcCp
UwKCheSCuALTKjmrpcCemoYWJFeEVgdXN8QWyFr/qzoGx4MIlaZB6YghcCjtKoGQ3gg8mPtgdUVE
7mBqjDUrWSjBg7XhQYJ9BFIj2EegCoJ9BFKlon4jJD6FDVqQUsHvICuqiO8KCxQp+hm0dXA0sh/v
O5LPaGGGQB4MCiakTQasCDmRMbME2mAa2aWg1dFCDxbch4yrLKotyBP1EY18UAitkTR0ngiZjqug
BXlNLSLkKIU4WpCnyNMWsgsiUXMZ0gtSDtKTgEFGchWQWC74DFEIz+qMImuNREIdWQ+piTXqCBQn
orIIKU1E55lopCCMkpBxSh/pEblHEQHU61xk9IXkprFCSBsC1BKQVzB/8JO2ChIpEg8yO4GqC9if
gOkC1I68W2A5bNSWxrKmXiQv5F6wQEGtRMB+UbO2Qe+lJMiDtuFfZAytnlQe+KAAySSQrNyorZHf
1LejHCpACo3EtmNOge6qQEeCR7LDnALdFfFHMvIerAK6K+zN0KbBrjqA7loTWqNcUsQS4qU2xClw
XpVVtTWKQsU0jUy2I5oQYQ3VFQHJDemRwAcN9Ep1VF3wFligYQyYG4U+vDWynwYMCg6kSIwcONdy
iEalqUlS0ILkinEA563Cv8B5Q1VJwLk6EC1I7qhk+kin8CDQrfQCHciIqNYI6O5IrgR09zwKnJFc
E1pIqhjXKKI0INBCX2SqUb90GUUSWmWMHNm3dPwW2oZ9YIYO+xg477CPgfMO+3gHg8M+Rq7bYR8K
EM3PGa2RqXWEDF7ckTsYnLqDM3jkXfiRE/I2Z7SQ0lntYI0PTeGEFnoU1cQJOlB+MlKaVrhaLo2i
V3O3tqCjocwa9S9KUEYBrLlCtYEhNfmghcSP4p1R8aZRvOWR+vVuRsWQwEY8ambgipE5EkaIOllb
YJqKHoIoKZBXGPViRU2gMcWjggAuGTkJbtUW7usoMFEh63SoXuSfjCqfUSznURsiA2YkfgYfZ+QJ
JtQEQB2rPVpBqAcuhQejZBw1hGCekauVaFCXQl5VX/AoR4ZVyCEqTmeSIaVn/BZSOsaLnKR0jc9Q
J+i0oahFwQGrkEcJdcelrkDO0koXxYfaC3bVVkcZjL64W+kVhYjOGqNaUDhraxQwBfOs86At6C2X
BQjuyyhUMBsF8lC0MwoTDXRU0ZA3fFlG1QK9mHsNJG0hQzNqYkZ2Z1RQjHqQkRexzNKqBmOro9DB
vCBDM6xk1HIM3mWUUwzUcoWOgnFUyKsJLdyHUokb5KFW4jYqIYyjjqoHEYuyUfaE34KfdtU+qkPB
IolHnYRqiVFBCHiXRzWDPMsouwQ8x6gWBDHAHdURKhQVj5oIqxXUK1IQ931UR2PpAL0VcTVqJxSZ
jNyvhf9YWKBiUuQIECXgXUbmLQpH/QxVD1YaajiqKI0aHrlL8aifjdoJKwXgvAAVMvIyuEX2keM0
VgSYLlgJCfBbsBQa9UpBBuNRWVWVP0rS0jTGBdgvWGwI8KsrJbQEtRj0AskVhbkAyRULDixntIU1
Sh5VmUY/Vs9aqe1ooe5CxhDgo4IBBDiv8KiABaoQWpCnQ9dWRUsjSYBQTRpoQXLFWgm41PyBFvo2
jBe41DUvWozaTu0V4LKhFoV0rY5orMXQUp9pokeVhxkCQhsyrKC8b8hAY8HQwBkC1DZEA5hPyzXF
KVZJWu9h5OA6zR+QDB1Y3Y4aWqdPfwvUNiAFvbQFbwG/mvLQQjUITAuQ11FByajtUJULkNxRrwqQ
3FFhyKgVaWyLjFpRvTdq4w6fCdhCVxRqH9Ddi1y2T5RK8NtRmSL/okbQvIkIK6PORIQB05o/sACt
qDN3tFD57fqvoErZUaFgqa+ZYsQLPkM9KMhsO3iYR/0I7hNUZbtgGVxHdakeFeR+XajqXKG+UMfo
7FbIUzdoa9SZmElkbSUQlVxHTQm/ob5QUtbPUB0l1MByqS415sGz2sLYFN1ae2JsowYE/0kbNSDG
hkotAQeCnJ4wQkGu1lILrYTWWGBDXmW0IK8pEn/9609fYJtp337/6ctPX/74zV8/ffWPHz9/+vLn
n37548//8f3n//30xZ82Gr//7bb/5jf//E+vu/znX/70y0+fP/3r9z//Kv/L9qbzb/+wpf/ZrjLc
/nzcPz/Zn872/+HnP379189/+/rb73/5/PV3P/3w4//9+ZvvfvjbsVQ+lNpN6hdHXWQrrilfff77
z9/+8Pejruphveeod0+eSl33P6wyL1WS9f6vdNjxYY281CjeINP+QJ/DqAz6+JHojazgHuzxjktb
jbO2CcTv//Ld5yNJbXgFO8/jcpHbLnJbu1z6RUu6XOhykeXczphdgT/xG/Rf+5xG/0WIK8CH/+MC
6LSARwjghNjj/uL3D71Rrn1Q1XsccKgo6NQe6dQf6TTRu5oIB1Y42EBw41zjck12veGue2sSudYE
8epZk9jROpnlmDNTEOWu2rJUez4a0zFKcK7jzVYAAtfs/hFmH6MIZ06e2eVxs/M6tN5h9gKTmV2z
j0F5zmz5CLOPAX5eQA6wHpJeTjeT5RZb+QlE0f4Bk5XP552FgGczTA5STCwgwEnsrvriLiquu56I
baqxu2JT+42pbmTREwmLT0RWaCrdgICza+oTIGD6ABBQAIJ4rHwzVjeCKIh2d6wfEUF0U5GxH0HH
9H/KVPkIbqIAbfFYb9AibkHFT6BFnIJK3KUaP1HGybqewnMYntYn4CbN0epGEwcY87SWj4gmDhJV
GE0sL2MtfjQ9UbmVdTS9w9SbjFZcPuInMlpZ8xGe0/G0BiWaq/UjKnIJ8B4LOL9jsBBwjEI8s+RM
nDyBourwVHV5Sp5YQNUT674wnuUGetWNLHkCevVDIivImrGAAJGxgMUGR3MjqzyRAdtHcFa5qReb
y1nliQTWPqKGKnRjqpv1yhPI6eusl/z99PJEkdk/YuegHKMwdXfnoDxRcPb1zkHqfjQ9kQG7kwG7
y1MFz2c+oXhNVXgE1FFc01Yfxw8OH1eK42OBtNsO6J7tSnZlu4pdi12rXS9nBrYrOvcpxxPel6v9
Ppv8bDus2e7PJj+b3Gz98uxnO7Rk/cjsI+tP1p9ML5kcsv5k/dn6s/Vn68fWj60fWz+2fmL9xPqJ
6RXrJ2av2P3F7i92f7H7i91fTE8xPdXmpVq/av2q9avWr5qeav2a9WvWz851LJWMp58vV9PXZj+z
0053kh3vGP4nIidGZsguwnnuHaxo+TLpr05+XjqdPvq5SPEl+Gc/T0ig8xIeOf15I/fcAfDSHI8g
0o0r7wWkc6fAj+nNjt5TR8GPqWVH7VyG/+7ffvjuH96p0pueM2P97r+Ptba11ryHWhchn7qvNSdH
aw61LmASaiVHK4daF9AKtYqjtYRaF8ALtVYnmq5aj7teqNocMadmGrsYSAsHIo8FaO5rrZRCrQsC
ot3XSg4HEIVa64NaHQogCbUuSC/U6vg1CBWrcmxKppELM2IOW9BnFCLkcBiHHJYXzEkBwtjhMA5D
JC+Y83q+sdLqhAiHIZIXzBlqdULkZZ6Ou1posBMaHIZGXpBv6CQvNHqodUG+kVbxKhcfUWzka3W/
Tc00diFSXJG2tLGUMbl68sIE5hzVMxXMOkriFV22FVy2lVu2lVu2lVveZ4Vvw7BnX6wkm7NwbL5E
D3zK22e+XjqdrvyFF2pPV/5PSKDzEh6p/N/I9TdPZ+W/NMcLJLmJxHsBxd+TmJX/Q3pLcvROBLiV
/2NqyVEbV4j7oueVFY5J6vbM5U3fkBrTIuSvpzULrXVfa62nK/83PVOg1Znherryf7dWcWb4Ok/H
XY3+b09a3qg/vXh4t5Oc0KhxaMiiZ6C1OaHR4tBYEE4LnNSc0GhxaNQHtTqh0eJCeUFyLSiUW3O0
JjcgmxMSLQ6JBT1G09SdkOhhSOQFM/ZIqxcS/jTdnnm8URtGU16QajhNTjT1uLZekGoPoqk70dTj
2npBqoFWvIn2sHOskuxOeVF9XrZta2OGibgJgRla09dzNIeqaA93L/KCvwMmpX0dhbTHUXjM37RT
oHUdhbSHuSof83es1ctVrjNtKqZxj+Vp87sda5hPp9WLEYV7ZXmRVYK8TbtXN/uLxGIDsXMdKy7m
FE6jF6LZF22iyhkR7sOy9zOZ4hRwnHgo+YxKyfFfCrdZ6DjxUOJAq8MWKYwaOs4e9HJ4sNC6jhqK
jwDoOHuEWvN6rUXxEQAdZ49Yq+PXHPv1mI8pB37Nnl+vFh93dUg1ubiziJk+nLM6rY1wcSzysjdj
Rj/CBobZafwzq+Zpiw0vOYv38/s/JDdudbc46IkdDsoOU7/D2JeHM+l6FnJs7BPbIkROUXu0vbTY
n4q2SOLnbhf1/DskLCjSf1eDFwXyuclbQ4XIf7Q12tFz1Tqkzu4WGq82/M6o5TMgjN202EF4h4QI
nLGE4xqM2H8O/xmcsZMm2H8Q/4ntR2KnLjvPRfKyc07iBphEu+WeseKUDeK+GyTPoFicukHc2lWe
QbE42V9czpJnUCxOej+PIHkaxfI0iuUYxSeOo+wBuiy2krcH6LLYasYepLNzkHkuMc8JZhk0vpfu
crVqzE7dLF+P7567XO1+ezDQUtLMEZO0xzfKXa7Wzx4MNF6aRDG+M25cxfrZeCxaZ/iMb4C7XO3+
st5foRKyQTE22A86nT9GKwu154/RHpdA5yU8dIx2L/fkMdrKHA/Gt++33AuoJ4/RHtFbk6P33DHa
Q2rJUXv+GO2+p3+MRq/OSu77nj9Gu+8Z7PS8Oiu56/uyCxoeo71Xa3a0nj9Gu+8Z7PC9Oiu57xuf
lSyAF5yV0Kuzkvu+58/A3qm1e369ztOxwUb8zUF9j0NjQTiRk7oTGvHBx/UY7b5npNUJjR5DfkFy
oVYH8oGT7FyAXp0LLFF47GcTYUcP5tNpdURixxxmuX/uYjdHVA/3IdOCxCMm7evA5RNnJcf8je84
9bTyvg5cPnFWcszfHJxa8L4O3BuLj7uy0zU+Zjmm/nia1jHP+/nDvvuefsLhtKZDTnFIHFN/rNUL
icA5FyRx8kogF4wW6jOEpk+n1Yu5iJ83XSSkAJScnGhLcbQdZxNOkVYn2uKDkHycTWKtDgHlONqO
swnnAFnZibb4rYR8TLacAwLKDgFlP8azFxJ+bNvbdJwfzlUWdDMMprELUf5RhJ1x0jzjtHfIDOMT
VXNQz6xM1gLinQiyHQWaOwrz4MPOValY4Wev6NnSbi615iwsXD0hvFzRX+y7XdG/dDq/om8LtedX
9I9LoPMSHlrR38m9vh4SrOhX5jiBxLcviLzR625Mv6zoH9JbHL3uznR/Rmtbao1hw7bxxvZGLtvG
G9vGG19Otaa/5vzN8SzGGr3Yb08nv4LLtdNpuFyk+BJ8uDwhgc5LeAQu93L9L7m6wmVpjhdAt19z
9Uav/x2iEy6P6e1rvdezEXcD7CG1t2cjb9RG7z5fIzfdhK7/pVNpEa7XA5Gv/v3YzuLY6bJJWoR3
qLE5Gt1XmNMCDpHG2230pS+++v2xtcZEdsTA4oRTcc+80gJ0L1XLwnpyNLrHXXPj690axdHoUkRa
MESo0SGHyENWktlcTAsXdvjxVa/bUG86Nn8A1Qmx66sJx0oXLBNqzI5Gt+yZuzPv1shPOMkSvz3S
yNUJ6uqGGP4uxoJ5rquV1QCcKPO/fyovmCfU6LBFc0998oItIo3tTN5ZOMnWYDYX08KF9X6IyXW7
4U3HHAzAibLmpsC51fBujQ5hNDcF5gVbhBq9FBg4yb6kxeZiWngsq/sh1q8Px74ZQPcH0J0o624W
pEWdEmp0CMP//ilasEWo0cmCkZO6rW+65abuBHV3Qwx/lm1BBddDldUAnCjrbiLEX3ZbwDdQij+6
tFIqu5sIaQHfUKOTCEM/WVV3mY5p4cJ6P8ra9aHKNx0pGMA60GR3cyEfwzfWuOYM8f9gAh/DN9bo
rcJ8J9nEz7mYFkZrs2++/f54L8K+hctWDbM2neXPzLCTxCdPzDicQz2ehvglCD5mIwlegpDkaQ0f
lufj+kWClyAkrVOjxHv/fExcErwYIGkdLBK/BMHHq55Qa3awn8MzHT7mS3l5fWKhdZ0ZJH4Jgo85
M9bq+dV9CcKmYhq3UB8+CcLHlVPspDX2heLQWDD09a85LLSSExoUQl4WLB1qdSBP4WGULJg61Or4
9fpo/lrrgt5CrU5GovBIWxb0dn2mf6H19i8i3Pfl8JBRFvQWal0XLBJ/WZEs6C3U6hGN+7VB5oA5
JdPIh9jDNv4NNTOOZ2TNUUTJ6jjemxGTqbBXrIyM5iAX0x4yrSz4Pcqg7DBt/FVLsuD3UKszjRLS
pCzImQMQO3veInFgL8hZglwmTmBL6NeyIOdQq+NXCf1aFuQcanX8yj6Irey1KZlGPoQ0e4zdrF2M
JCTtsqqEg9h2dvOlhMm4LFJFCepvZxdeSpiMyyJVhFqdZBx/G1FZpIpQ6+OhYZvxNiXTyGjJc8zn
Fqj2lWnG0ZM1Z7zPSJujWqjafVVmdXK2ac6c+kla23DilNxeK2F7rYTttRK210rYZsCOaeex6TzG
nAvpOdqF769mrM4eLxC6PTV/6XT+1Dwv1J4/NX9cAp2X8NCp+Z3c4K9sXE/NV+Z4AXX7dzbe6HU3
Dl9OzR/S2xy9Ewn+qfkjal+dONwJaGEFMV8bedMzyKqvjhzu+8ZPri9CvvlPOMqrjfv7vvFLDQuY
tGAZ0J0ZPvFGwgJaodbsaI39ugBeqPXQr/8Pgj3xPA0KZW5kc3RyZWFtDQplbmRvYmoNCjU5OCAw
IG9iag0KPDwvVHlwZS9PYmpTdG0vTiAzNTQvRmlyc3QgMzM1OC9GaWx0ZXIvRmxhdGVEZWNvZGUv
TGVuZ3RoIDU2MDE+Pg0Kc3RyZWFtDQp4nK1c244kt5F9X2D/IR93nzp5JwHDgHdlw4bWgjAS4Adj
IbQ0vdLAo2lh1IKtv99zsg6rqmuSwepqvTSjs5IRwbgcXpOplWVdUstLqijS4hzKWhdXypLXdfGZ
P7cl4HlewxIKS7/EkFG6JTaWaUkpoYxLdgEl3iksy1KCQ5mX0lC6dalpxf9taXwH77bM0i9u9WDk
oMBaSURoEsmuLM5vfDOI7EG4xQXvoSVeDtA/VVRPjk/wUyptSWDq8la9sSUQ6fFT9dAJNV2tDURY
XKPWPi5+xe8ZGni38qcEIqO6r4v3nk8KiIonASYJkU/a4iMMkgOqR7YihMUntiLg5cRWwEZ+UyOi
VmErAmoVtiL6xVdPwoGo0DBAVosk0hJWmC4HD6KwOuzu8GKOBQS8lGNegk+QDnOGQJtDpxAK3sHT
EGn1hOqRLUUjQ6LOKS6BTsnJgcggYoVHA0XgnbpSBN6pbE6CiIZ254yXG0ybEQpoMfjANHFtJMIS
YXEQeYnekUggCjTMDTESSFQQDRpCuRipM/wRkyPDAoI6wyKRBsgJtQqbg3CMhWYB91gptOCd2hhZ
eNLQuFwQtStiKuO9tNLL9L3zfAdRDDeDQGh6mC3DjglG3AIzBUYnbJRiYETh5QQDZARSopoZnk4F
cZERYwgoimCGwCS5IuAaHUfLHqQzI9DuvIU4AiSzgqt8woBjxDfP0AHDRr/CNpl5A0stBUkGN+Bx
2zyU8CTQ1iQ8LRtAJLafBBsAXxR6sUYS1AlVC53XEjlXsoj4g6du5Tt44hL/80vxjgSeehgSj5Gi
gQQqBIQWrV9iIoGniY+RegXmQI11KYzKQhZs5aZTSSTwtFIOcqcwfmi+0pAOhY1slURe6or4ggpL
dSuJBgJOK/AZspNw4UG0A27UQDVgUDSURARRqGYAjFANVKhwBghwZiqgBUtFm0GAYaEaCMFaPQ2A
J5UNhNVgMPBBsrUVgVSgU3O0DRKtOQRSQX41H0gkEPBwQcI2pBMtujTqA2MvjfbJ4AXD0yEOeJbJ
py6tsBZ0apubkHGtEQ8hrzWEX0EmuJXpVBJRz9FMSFBQCEPYm5AY+QzAt4aVzxqpzGfAtxUJR3eQ
onUzQTTRvJk1CMYlk/OmUWbdzUvExpWpVRDpQNtIaiXFwCnk1xIp8IMymQ4mVUgRlh1jC1qAohUL
qS2W8AZ+DAyAlRSNDecCyNHWUsEZME2KnJn3jGTnmIgFCQuKIZUpg+0vmb9u+mXy28wXKa0xGAn/
fqXOlX0EWC80ufPEoYLsBAWZzF63QTaiEVRklCFTQTFy0ALnE6UhV9HBMAra1tWwRewQPSOwVL7H
/xHKoBraUVdyhsMXAicSn7ELP4HCOxVZ7AJ7kbqyo0LXwOgHBUwHVUgVPoO0QCSoyFdQjc8gA5Cd
mSag2OdVdpKB+Fq3HpA5WB1lULfKnjNURj27zlDJhV0mnADOiH0X141LIbVxgbRIuKrsG6MjFyS4
i55c2E1GNAlUJEUu7DFjJBckOSj4u3rySxuXTGrjQmnskGogv7JxoTR6tQZKI/8ayK/CZzVQWot8
Bs6JvV9FlIHKhIGy9e+QhjwHhehiSx2AHe1AfIBqlAYZKSDWmHEuRWY8MhoU7Rw5SmD/XCM5J8RA
jeSXNy6USwgujdIYhTVyFMEOmIMWl5mhFVEGqhGBwA/g3ohFoOBgUInjDsYGMxm9NH8FP3TK4MIo
Rse2gRYojgEqszYT6CujPTPHKzMg0z+V2Y0eBzoz49GdEOfAD2DPGpkU44/ZXTYLMbvLZiFmN0CY
1EqqUQPoB0QExUwG3PHXQIp+Y/4WIkhlxkMVYij5sTeuzPPCHqQSGQrxoTJ/C+3EEQyAnO1gniOF
SHGoRQSpzNVKBKlAKle3qGNG1S3qiBF1yw9mLYKB/CopcKjMVbiM1EoK2VmZqzA2KXLZBpbM7sqh
SSUe1K0noS8rs6kypyutzb7SVfbgxDtQ0KoxfxugFdRKqpEfdG6OAM6sRQX+yjGjr3wGfugPth6E
FPsAZm2LiVTh2BL/0yKg4JXGrG1562oog900UQRglkjxPeZ4YyY32rgxk1vb5DZSsF1DTPt1zfwV
o0ykNDuqlRTbgZjBUBbWZftANVIYYGI4QLkYjq4RrWkc4KLX4K8c/DI6OdQDxXZwHLxyaNg4yF05
fGgcCa/sY9AtgtryN/E9WrEhpzFyRtY1jo/duj3DewR3UNAFYMx+vJCq7CFAEErgewy1V2IoiLpB
AIhGL8ErqNU2XUFxVMYxL2AdcRLA2aOzwTiRugVOTiIH04EDsoSY99Fvo3pSxIJMzpFj6BI5eKev
MVQBz3XDfzxDd06kIBVhy9/97u7LbXK0Lm/uvrr7n/96fPvr3de//vRw99XTx1++e/rj+4cf7z7/
O/Dif5e7L7+HLL75+9//+7+pZuo1/7JXLW2Trzf7ddEI1d2vmo2qyawK4+HnhQB4KIPKNGbZ2tQG
eabMrg04xxxJ5TxzJrUMarqJ1HCr+aTUQGycKlxvNNPYOZzRzaS2Qc08kVpvN9M4tjn/nyjs19vM
5IxoctNo8m5QcxJNbhxNXMmYSfU3SjVCwk0xy4cbpVqYZYfEwQHdJF3JAStvseLqyoZZB5Ts+NTz
vidiD/Aecb11A5HOFimYrAZM5g7aXz/86+nbx3/tMxoDSOn1v3r/7u3Dbu0s9C5C7+JVSr0SVSaV
RaXq1bEFuBAi8T/df/hEOiscHPz5su5U+tO773/5+HD3h/dP/+H/c9mFIYlNA7FnHOI+B/9qDuF6
Do9P333z4eGf33z7/peHb95+fPzp5x/u3z7+c59v3Ofre0p8uevNJU/UMQKJ65UnV17KLZZcTEFe
I7cacju0/9nt1W2vEBvWsdgQpl3gOqh5BJp9vAvRkDofGQ5CPkz6sVAMqfOx2CBNQrWlRsPC0U2l
DlJrKtUbbbV7lCBYj85gYfYk8mHXcsDC7BkUfF3ZCYvdfHQD9IjXTz0ua04CLBoBFq8f7F/WnLg6
GQGWrh/sX9acDFlSMKReP2J/qVQjGqI5uZMpunIzB+/7V5mRjMyI0WahzIi3Z0a8PSMGPUVeZ/7y
A6BPzfZXNiyVp92LHwB9nnQv2XBxTlOpA6CfSjVGDscx7HzqcFmzTKS2sdQy9+sAI2dSi+VXu284
mKIrNwurfRbqGw7VurYDVjYqHEK/Kz1gUUwWyfDAJJXTNSiwm8p+0EWV+Rx10M2USedWDCOX+drD
oJspk86tGlFSbLQuVmbYKF2E0sXwTwk2i2tQelDVgK/rBvXq6qLyJGrintSsQ0Bvu/+HctyXzyfP
PA6ycfFaJvDi6iXdS7pXtnpJ96oXDCw5Lh8MJ8+H3Hw2eT5Wun7yXAZir588384hXM/hpsnzJd/u
0cnkeaSOFXj1POUuGLTVknuaPN8itzlDbu+O7MnzTWKDIXY+y1gHNSdA/GyD47LufJYxCPlmAzFP
1Iykliu2FPbTpEy2FMo6tnC5Yl9gP7XmUpMhde7X/cSbS7X8ao5i5IBukq7kLLz2o6uJxTilyjod
zR5n0C+L7bKOAaS4+WLJPnYVt9pSnTekzqOsDGqGiVQjyk4a71eNRtV5gO5D7dxM4wAtbg48+0hb
3AR4vAE8fr77tA+yxU+S0RvA4+e7T/sgO5dqhISfj+wHIDuVavnVBh6N9WSSruRAjevnwC8NEQM1
whQ1/ACvwyQdgoUattmCAa7zVXe/D65TMwUDNear7n4ArpNV9xKM6ArzkBiA61Sq1ZFMnHOYJZVn
i9cvxGd1opoSKfR7SHUf91bsi4jzxZsbcTwa0Rfn0TfA8Wgvj5VoRN9p3XUkNQxwfCrVAKSJEzV7
LnHspMlgSkOWPhTofXOPwO7j3oqBCHupomlO38RyVenG3eaVkxsjNueLAlWLAFWT/6rJv84Y8MT/
odRqYNM6XFO9ZkVLX48bLgocBiPniwKnStcvCrSB2OsXBW7nEK7ncNOiwAXf447NZFFgpI4RSOXZ
ns2l3GzJPS0K3CS3GHJ7BNuLAjeJbWOxeT5RXgc1J2O4HAypU3R1g5DPcSI1G1Lnk8RBmkw2H0o2
LDzf8nCD1JpJfbblcSl17tdB4k2lGn4t86lpulGqkbLZ7I/k9u6Ibpqu7KAh8ynrAIBmAVoMDJhv
Whxn9pc1JwPtZ5sWF3XrPFQGoFcnEFCtULGHvM9Oz73M3zoCV6qRHtnc7xA+9ajs4dCVHrC0x25Z
UZeNqLsKzbPRrOkoqEQlQ1IyJI0HdRahJI0Lk6bP2qBR99RbOZDe/TIaBR0A6/ko6Fjp6lHQgYvN
wR4FvYJDuJ7DLaOgS77N3HI9joKG6liB1M5S7BO5wZJ7HAXdJjcacs1zlO01UvNY6jxtNFkomiQU
TRKKPrIomizIX91+vT2Dts4mDdrPfZYu7cWThgMXm8MkXW7nEK7ncFO6POdb1+smDUN1jACq51sw
n8i9btJwm9xiyL1q0nCb2DYU+4LIdafQrc7EMjcLV0vZ8+2SVyjrz5Q1I8nN4tpUdhxIL1E2nilr
ngLvQ+7blK2/ibL5pKw3d937APcmZb37TZStZ8qa/aB7TYL5+Fso688SzJso5F+TYH4MQi9R9izB
jl8Q7Cv7mgQ7/4Lgmp5n0PkN+pjjQXPzFNxtioeh4jWYgORf07MFo2cLdky9JlvDbxNTZ9ka7Jh6
TbbGa2Jqqmw4y9ZoxlF4TbbGcRy9RNmzbI3muDy8JlvP90MuGcwH5tpk4CUdh9Kp9CqDyqgyq1Q9
p3raF6naF1H/v12ucSiLysOAX73YdoHGoVQ9HSkUFm+XZBxK1QuSowORSuueZ9uFF4dS70e9H/W+
Dk7WaOTsdDeifPp9X335bkRJA7HXTyxu5xCu53DTxOKC73E3Yn+gfZpZjPSxMuB8O+ITwflaX5az
SiYO1uO84FLW8STvZ7v1ztd+Lutme3C/nsb3LxXqDaH26MyfxukvFRqv8MjXb/a9qczNytzzfZBP
GmD2rm4QjMfdk5H2xZBonrU9ThVeKrGNJRZ7vD9InJnE872Pl3ooC2u1MVCLEdfFDrEyqOUn2hvx
Vcyuti/Fv1hiNiTa08cBWkwl1ts9pK/cZYuu4T6vasZXP233ifbN1r4a8VXtGcAA6KYSDZyo9uB/
0J1Oag2wcaqnfFKNiJr5t2r0pDMZ0nTQChOx/AAja5m0wkAs+7sAP8DImcRmRFSzI2qAkZNaA2ya
6qnca6/oA7U8Lkt2TQetsGeYA7xrk/6hGYjR7Iga4N1U4jiieAWVITEMMGoisa2v6AN1SEu26BoO
tDf7wLCPd221+4e2juOrrfZ0cx/v5hLHiNVWsw8M+1g5l3h7Hyird1t0Dff1cHZ87WNkW22kb24c
X83Zqxf7GDmXOO4Dm70iH/Yxci7xmrnXwENaO5AtuoYD7e342sfqdvxyYqT9OL6aMyeBYR9XpxK9
gRPenAOGfVydSzT6jqmHijxzmJM1b0S0N+Mr7mN0O24QjLQfx1ez1+vjAFenEg2c8GbPFwe4OpVo
jKVmHtJnGrJF13C2mHL/7fvd5cCq74g1we/TyD5Z6YPbPgjqXWwH8g4XPSh70/fNEkzQjbyn8vZF
oRaMULW3IGJa4iuWo1oYt3m+IFt1wKjqgFHVAaOqA0ZVB4y0otYDpFuzt21H+pmwrz8+PLx5fHy6
e/P4/uGv9z8tmrN8ef/x4cP266JZ4baFeWB88KyXp730ClqmiQrAqIXX1C+F0MF4nVDvZ7T6oZO+
xt1NS72PSnwBI3/+8Otpq/ZP0PnD49PD3Rf888cPb0//dId89fDd092fH+7fPnw80KzT6b98eP/u
w8NXP9zTEnzwhw/gcP/07vGD/v/49O7/7kFs//3t8eM/vn18/MfdZ4/f/fIjlNqe/PzDw8MTtXy6
++v9dx8fz/7/7x/w9+z/z97dv3/8/uzBwe2ndw9y8Nr3H+9/1Jqr2vrFLz/+/PeFVzhv9nHbPa+b
5bd7Xjfbb/e8blbf7nnd7L7d87pZfLvndbPxds/rZuXtntfNnds9rxvndbvodSPddtPrRvrtqteN
DNtdr5t3qBy3MxV7Aglhg6BBSPCs8M8KYZYiV32MgIv83bpKNa+yqxpVJpVS9jC245Xsaofqa1fC
aYThtCvhBE9O/ZtT/+ZkHKddCaddCaddCee7cVRPpnZKPqfdCafdCaevgpx2KVwQn6D62q1w+mrE
yWFOH6o47Va4qHpKHieQcAIJp2R0AgkncHACByc4d7obxSlpnQ5Vuqz3BfdO5zadblF0Ch+n2xSd
ugOnWxSdznc63aLo1E04rVM4Jb9T4Dglv1MEOcWOU/A4hY1TwDjNqZ26G6eYcT1Cj+DkzstDMHkF
j1fQeAWNV9B4bWV5Bc2p9BdlVKn39SmYV5B4BYlXcHhtWXkFg1cQeG1VeTnfy+lezva6UMrLyb7f
BrY1JnX41ctJQuVprw7caxX9WMrjp1JKy9NeHvZaOfRaOfTyqJcnvUDDy3NeHvPymJenvDzlNT8O
yuigjA5yRpATgjI3yPhB+4hBmRqUoUFGDzJ6UEYGGT3I6EEZGWT8oEwMckJQJgZlYlC3FeSMoP3C
oEwMck6Qc4KcE4ScoXeHAuQgvwT5IygDg/wR8plTg9IwKA2D0jBooT3ISSG356XS8VRKuJwW5LSg
tAtyWpDTgpwWlGZBTgtKr6C0inJalNOinBblrKgMicqQ6Prvqi84jX0wz0ZHeSzKY1Eei8LQKM9F
eexU5ovyrOOIAtIo90W5L8p9UUAaBaSnsj0v5c7Y+1elV5Qbo4A0Ko2iPBblqah0OpXSR4AZS7ko
JVdAGQWQp1Ly5bmoc7KnUnrIg7HVZ2VS+p1KXYcrj57KolKjOKVhUhomeTQpDZOmH0lpmNQhJjkx
Ke2S0i0p3ZL8lOSnJP8kpVdSeiX5IQnukvyQ5IckP6Q++pEfUt/CY1Bcfxdwvijr81LplOSUpF4r
KY2S0ihpfKN76/vd7f029X5Jeb82vN/G3e/H7jdWn+6QZiOuv5MpX5T1eak004Wt/QrVfqlpv2b0
7KYp/a6hhm6J7Pc2nm6gUseim/r63Xn9Nrt+v9zZDVX9c9EzILz+G9P2vFQanEopKQ/oqpt++Uy/
DqZf0NIvKenXhvSLPPr9GP3Gin6HRL/Vod+z0K8r6BcI9O/y+5fy/dv1/p12/3L69C0zG3/9pyXp
oiwXpYQpJ/RJX//Irn/21j9E65+G9S+r+rdOp6+PNuWuPsDvL8p4UZ63+OrDR+miLBelViWOh5FU
/3gYSfWOh5H64aV+GElyj4eRNLc+HkaSnH4YSTl0OowkOUI5ncw7HUZSbp0OI+n942GkM6NcvwCQ
LkoJFSSeSn9Rxouy15MxFB7aY+87330/uu/s9v3Wy/3MvjPY9+su98P6zlLf7+m7MH0/o+8y9LX/
vore17b7inNfu+0rqn2ds68Y9nW8vrrWF4TOynBe0vj/D0bVnZoNCmVuZHN0cmVhbQ0KZW5kb2Jq
DQo5MzQgMCBvYmoNClsgMzQyIDAgMCAwIDAgMCAwIDAgNTQzIDU0MyAwIDAgMzYxIDQ4MCAwIDY4
OSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgMCA0MDIgMCAwIDAgMCAw
IDc3NiA3NjIgNzI0IDgzMCA2ODMgNjUwIDgxMSA4MzcgNTQ2IDU1NSAwIDYzNyA5NDggODQ3IDAg
NzMzIDAgNzgyIDcxMCA2ODIgODEyIDc2NCAxMTI4IDc2NCAwIDAgMCAwIDAgMCAwIDAgNjY4IDY5
OSA1ODggNjk5IDY2NCA0MjIgNjk5IDcxMiAzNDIgMCA2NzEgMzQyIDEwNTggNzEyIDY4NyA2OTkg
Njk5IDQ5NyA1OTMgNDU2IDcxMiA2NTAgOTc5IDY2OSA2NTFdIA0KZW5kb2JqDQo5MzUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjA0NzUvTGVuZ3RoMSA1NTQ5Mj4+DQpzdHJl
YW0NCnic7H0JeFTV3ff/3Dt3mf3OPpPJzJ3JTBKSSZjsO2RICBACEkiABAhJSJBFkCgosgYVRQLW
AmpRaKt9XbHVibgEixi7aKu1itZ9qftWUOveQma+/7mTBK18X5+vvj6+j+/8kvO755x7lnuW3/n/
78CTAQIANiQVNE5sqp8srF3YDHD/NAD3BZMn1k2CDPbXAIc7sJR3cuOMJqHUUIXpLZgum9w0u+bN
4LsZmB7A9JXTmpumdL2d9RSABsuz981oChesfunCFgDyHN7vmDNxesuav29cCWBIBeBe7VrZ2fP6
fb3nA6yciGV+0XX+Gt8c/5m5AGvvwvTHZ/YsWbm+7oMgwNnvYvkHlnSu7gEHqLG/RmxPWrJi3Zlv
VjdvBlh3C8DYFUu7V14Q3PXnCQCWkwCtU5Yu7ux+UXrvZ9jWAixfshQzTI2aeZi+EtPBpSvXXLDo
GfkgAFMGII5Zsaqr8271gR6AW6wAwtkrOy/o4YN8DZan4/Od3bly8bQPznkd4I6tALpf9qxavSZ+
AeB4D+fR+z3nLu55ZcPLRwHW4POwaqBzy3Hyxj0/ym43Vn0GbhEofrWi6Ut6/f3Yuq4T1w7t0d8i
7sGyamAgAawnamOzcJ7K8P45+luUlr6KhTSHvQcmAKukGZAgArMxwnEPJHJUO5jDwIHIXcsVYpPp
iSt7HTzFciIwWlHFcioVo7oe+HgEfPPpjNKK05t8PsAfdjPvjbXCI6KW3O4D8nN6T9XFHaUjBSIO
PxL2oQS2DB5VHYSb4TRQtcKDGG4aSTNvQoB9Fs6mcW4rbOCi0MNFiQavhzDsxNCM4QYMl2LYj6EL
w1JaHvuZfro++BJw8k44wj0CS/gb8LoWQxEc4Tdh+iAcUS2EDapzIFvp0wVHhKvw3kNwREm/nLji
Sh/h7oCV3BrI4nvhVj4VnGoBauj1dH1+FVwLzOH2wgHV3dCC13lcI7SwnRBS4gfhAM7RdUq5hUr8
gLgWDtB8brNS/gAtx/4T6z8A7eyNWO8gXI/r5RWegVxuHqRwxeD9d8+QRBJJJJFEEv9zwN5DiNWa
naUknGhIiQHIKSRMMmhJplE2jM0yESD5JjCAwZpmSA+mj7Si4yVep+WzrJBpzclS87yOaLJkSWf4
fgaVRBL/G0ASUgUdfCnGQQQxHsP3FA2yRmEtaJF1oEPWgz4+RJWLbAQjsqSwCUzIZjDHT4IFLMhW
sCHbFLaDHdkBjvgJ9LKdyC5IQU4BN7Jb4VRIjf8TPOBB9oIXWQYfsk9hP/jj/4A0SEMOQAA5COnI
6ZCBnIH8JWRCJvIYGIOcBVnI2RBCDiF/ATmQg5wLuchjYSxyGPKQ8yA//jnkK1wABciFUIhcBEXI
xVAS/wxKFC6FUuQyKEMuh3LkCqiMfwqVUIVcBeOQxyk8HsYjV0N1/BN8Y5uAPEHhGqhBroVa5Ikw
Mf4x1MEk5EkwGXmywlNgCnI91Mf/DlNhKnIDTEOeBtORpyt8BpwR/whmwAzkRpiJPBNmIc9C/hCa
oAm5GZqRZ8Ns5DkwF3kutMQ/gBaFW6EVeR7MQ54PC5AXQFv8GLQpvBAWIrdDO3IHdCB3wqL432CR
wl3QhdwN3ciLYTHymbAk/j4sgaXISxVeBsuQl8Ny5LPgrPh7sAJWIq9U+Gw4G3kVrELugZ74u3AO
nIt8rsKrYTXyGliDfB6cF38HzofzkdfCBcgXKLwO1iGvh/Xxt2EDbEDeCJuQNym8GTYj90Jv/C3Y
AluQL4SLkC+Ci5EvVngrbI2/CZfAJciXwqXI2+Ay5MsU3g7b429AH/Qh74AdyDvhcuTL4UfIP0J+
Ha6AK5B/DD9G3gW7kHfDHuQ9yK/BlXAl8lVwFfLVcDXyT2Av8l64Jv4qXKPwtbAPeZ/C+2E/8k/h
Z/G/ws8U/jlch3ydwtfD9ci/gP+KvwL/BTcg36DwjXAT8k0K3ww3x1+GW+BW5FsVPgC3Id+m8C/h
l/GX4FdwO/LtcAfyHRBFjircD/3xF+FOuBP5INyFfBfcjXw33IN8D/ILcC/cizwAh5APwX3I98Gv
kX+N/DwchsPI98P9yEfgAeQHYBB5EB6MPwcPKvwb+A3yb+F3yL+D3yP/HvlZeAgeQn4YHkb+A/wB
+Y/wCPIj8Gj8GXgU/oT8J4Ufg8eQ/wyPIz8OT8SfhicUPgpHkZ+EJ5GfgqeQ/wJPxzEo/Aw8i/ys
ws/Bc8jPwwvxp+AFeBH5RXgJ+SWFX4aXkV+BV+JPwl/hVeRXFX4NXkd+XeE34I34UXgT3kJ+C95G
fhveQX5H4Xfh3fgT8B68h/w+/A35bwofg2PIx+F4/HH4AD5A/hA+Qv4I/o78d/gY+WPkP8Mn8Any
p/Ap8mfwOfLn8AXyF8iPwZfwJfI/4B/I/4QTyCfgZPxPcBKGkIcghhxTOA5xZKCfa7ADaq0aWFbF
KSc+hxdWBfwpgEq5IQq8wPOCgAV4UQD8oSmtMGIqeJ5TflngWTWtp+IwhbHvxXAlkcQPHRqdhuo2
ITCqW5SwcArDulWLgloQRBGFyKtF6sMJvCjqxJFWBIGKWhBYEFgtrcfxmMIq38+gkkjiBw6tTgsq
lSohMGofUcLiKYzqVqS/1IAKGjXVLc04pVtRRFFzoqgCUaWj9XgBUxpRPH2nSSSRxLeCzqBD3XIJ
3VL7SHWrHgUkHGiMoQg1Gl4AUasBNWaIGrVBPdLK6XWrS+o2iSS+E+gNetQtf0q3KGH1N3SrQaB0
tVS3uhHdagyakVYwqVZzajXVrYHW40Verdap1afvNIkkkvhWMEgGfK3lE4aR2kfUreYUIPHiq0Vo
1FotFlDrtaABrUaj1UrakVbQGmvUvEajArXKQOsJIk/tcVK3SSTxXcAoGaluEwIb0a12FMO61Wm1
Oo1GRx1fDTrWWszQ6L6iW42GOtFUtxqVpOhWLVB7rDl9p0kkkcS3gmSWTumW2kc0vdpv6lan02s1
er2oBo1RDzrQa3V6nVk30opWi8ZY0GoV3dJ6olrQaiRtUrdJJPFdwGQxAc8LCYEN61Z3CpB48dXr
dQad1kAdXy061qhbnc6gt+hHWkFrrNMKOh0PWt5M64kaUac1abWn7zSJJJL4VjBbzVS3CYFRv1ZQ
g04/imHdGgx6o05nNGIBrckIejDodUaDdfQ/vqI11utEvZ4HHW/RY321VqT2WHf6TpNIIolvBYvN
AoIgfk23esMoIPGBldFgkFCpkgbfbNGxNmCG3mi0GUda0aNu9aLeIIBesBr0VLdqgw4V/P0MKokk
fuCwOqxUtwmBUb8WXWbDN3QrGQ0mg16ijq8eHWsjSChko+OUbg3oNosGRbc2Wk+jUxv0Vr3+9J0m
kUQS3wo2p+3ruhVRt8ZRjOhWMpoMBpNZi2+26FgbFSFLTmmkFYMR3Wa10SiAQbAbsb5GpzEaUMHf
y5iSSOKHDrvLDqKoThhG+j6KLrNRGgUkPmg2mSSz0WCmL6wGdKwlMElGs8llGmnFaES3WW2URDCK
Dgn1rtVrJAMq+PsZVBJJ/MDhSHFQ3SYERv1a1K30Dd2azSaLZLRYsIDRbgETmCXJYk4xj7RilNBt
1kiKbp20ntagoX608fSdJpFEEt8KTrcTdas5pVu1Dq3rKCDxD0QWs8mKSqUvrEZ8ITaDxYS6dY/q
VjKh26wxmUSQRJdJMpl0Bi31o6XvZUxJJPFDh9vrBrVaKykJah81erCcAiQ+aLbZrHaz2U4NqAkN
tBVsFrPd5rWNtGK2oIy1FosazGoPraeXdNQem0/bZxJJJPHt4PF7QKPRJd5UqX1E02u1jQISH1g5
7Dan1eKkBtTsdoENHDar0+63j7RisZqsFp3VpgGLRrZZrVaDSW+zpKLuk0giif9++II+0Gr1CYGh
Xww6I9gdo4DEB1Yup8Ntt6W4TWawooF2gMthT3EGR/8SqM1usdsMdocWbNo0h91ulyxGh0222U7f
aRJJJPGt4E/3n9It9Wt1Eji+odsUl9PtsLlTsYBNpn+5N8XhcLvSXSOt2B0Wh93gcGrBrg04sZ5k
NTptPntSt0kk8V0gPTsd9HpjwuO1WgH0Zkg5BUh8IuxJdcsup1e22sAZkMENnhSXNzU7daQVV4o9
xSWlpOjBpc9McaWkmO0mtMeuf/unuZNIIon/ANnhbDAYTAnLifYVjFbweEcBiRdfv88b8LjTAljA
PSYIMvi9njRf2DfSSqrH5Uk1e7wGSDXkeD0ej81l8bqzUt3fy5iSSOKHjrFFY0GSLAmBuVC+Jjv4
/KOAhAMdDPgzZG96pisFPDmZkAZBv5weKAqMtCL73D7Z4vNLIEv5fp/P53Db/N5cOfk1FEkk8V2g
oKwATCarR0m4Ub5mJ6QFRwFW5UZmRjA7zZ+V7U4FHxrodMgMpmVllGWMtOIPeAJ+WyBogjRTcTAt
EHB5HUF/Puo+iSSS+E7ADH8dlhVYGiMpGHgY/douwjAw+u1eI6Df4DX8R5e1Ovr/pcBssdrsDqcr
BbWdMLPB9IzMMVnZoZxcCOflQyEUl5SWlVdUjrQxsW7S5Cn1UxumwRkzGmfOamqePWduS+u8+Qv+
uwfI/mfVVHAZshckbMCAPkYW5EI5VMJUOAMaoQWWwTq4Dn7Fbo7HgX6v2BjIgTDenwDT8P4s6ISz
Ru7H3zjtT1e86+R13/h+tG8gUtFcVlpSXFRYkJ8XHpubE8rOGpOZkR4MpPl9steT6k5xOR12m9Vi
NklGg16n1ahFgedULEMgh0SdtS39LiHkRvepNXc4nfL1dJRNlz72R8H8tULuf6mU+i9pz7+kvaPp
M6JgjU4K1E6kDffDpLejYIkSaxRoL8QyHXsarlTXvTxQtyzqqu3u6MAaEwOSLzrpo/Dwoyht92s1
tYHaxZrcHOjXaDGqxRiW7eknk8YTJcJMqqvoZ0DU5+ZEzaEok15Hw/JoZEcHRgITsSW8Yzl1ZyA+
uPOrtwCrjcQsiRiJ8rVRQenXtywa6YzCDl9/zmDfzgEJFnWEdN2B7s4FOHOd+Iz9wKbXLW2m81hH
Q8dSX1SFjSvkxhxf3VJfX4BOR93SDuTARKx12nzMVte2bPMPuqNmvNZFTaHoZCwxef2bbravzrnM
R5N9fdt80etmtnz1rp9ya2urEx+4ry6ADWJjdctrcCjOcG5OYkzDE9DdsZz2ubyTPmfdcl/fjsXK
s+5UnkEpWrcUF6bz35Xq66vrDtR1d3bXJFqvjUaalQs0z2tRBohTN7F1OGu4AN5RKXc6Jrb6E5Pd
MKullj5YoHOiO7HsozkdwzmYUTdy00efoB4biPq6fFGY1RLAomWUFpdBX1eZsnn8rQRrNZ6qFeXS
pYCv7zOIko7A8WNfz+kczuHTpc+ARicFJnX09U0K+Cb1dfR1DsS3LAr4pEBff0NDX09dB/ba2IK1
BuL37XBHJ+1sjUodS0kFzj3dAZNmtVS7/abWkWTjSBJwS+HG0irDwVnA3/rhC84yNLf4fThRs1ta
3ThPLTTejPHElW4k3LhluMbD00bnaHHZ6PTUDkf9fro7dwxEYBEmoltmtiTSPljkvhMi4RCuRwe9
Mzhyxzab3tkycme0ekcAe7lLOaJsUTFj9Nco2S11SyuixP7/uL04cT9qqW1h3UxrIsa4WRrThFDp
VVFHCONjQn24CE8EolIoyrUMuqtafZIJTwC6ek2BhpnzWnx1faO7IJEzPFK6D3CrBzqX9g1LiW56
PApq+gPkspn9EXJZ07yWQxKez5c1t9zJEKa2o6a1P4j3Wg758GhVcpnRXJry0RQ00A14JyMqt9yH
IgBblLsqJUNJdw0QUPLEkTwCXQNMIk9S8hC5EFE3v/tOUH7nbZOMyxfpfkYnlUSeJ8/uNsmPYfgT
hkcxPILhjxgexHDrvqC8H8O1+3zyNfvGyPt2u+W/77XJN+91yT/Zmy1fvTddvgrjkb1kLxY3fkyu
3O2S9+wOybt2+2XYTWhHC3ZrpRLjYflw+DAb/jWBQ9IhxojPfDfxfdn7JSN94fsi8gXb+xmRPvV9
yvg+aPyACR+rPjbjGJv3dM/TzME7x8h3HjTJ4YPVBzuiPdGev3BvvRmU38AQfpN2cPA3OBDaUfwu
jDzZO1Y+iuGJXp/8eK9JHsTwAIYrjsSPMMb7Sfx+0n+HSe65g0i3+G5hdmzPk/u2h+XtvYXyZVud
8jYMl26tly/ZapIv3lohb8VmVh247kD0wEcHVJHribTAtyCygP0EW7yo1ylf2DtV3oLXzdjjJgyN
vR29Pb2sZPTLdlu2LPB+2eXMllWsX7aYs+WcXGN2yDAmy5iRaQimG9MCBp/f6JUN7lSPHn0WPbou
evRg9EbJpNPpDTq1RqvjBVGHTo4OPSCdZNxiZCL8Fp6JsFtYxgjVMAN6QWVEi18NEc8qTDwAj0Mc
RHelKBsrRJktF2UoE+XGQhI1N0BDc03UQvDaVBMtDDUMiDArWhBqiKob57f0E/KjVsyNMpfh8jRH
VZfhLmrG83/e/JYB4qK3L1HMAcYGyJZLLr/cPRprbQ15ot0NTS3RHk9rtIBGfuxphRBi9ZrVq1eH
/i/oV9Peu2fV9L+nosaiM/peYGL/++8phiP6fmAiGa761TYwio2OphK/XwGEzlPy13yjO6USHhO8
lf5XXu4oyCP8NZerC5TPcOKvKfzySDzWHf/sP3PivglxOPz/gBxlsr5tv+QKcinZQprJWrKSnEeW
kQjpIq3IF2NqFdyuFLoR3iM+4iIGQkiAmIgAJ0g68RALUYEG08ewzKdKyZ8q/CmpgE8YZbZgB4YH
4C/wJhyHGDHAEfxZgj8H4Hr67UjESzJJOZkCH2Dr9F+mroV+OIRl/oB1XoS34SMiknnkfNJHrmT0
zGRmHpZzklqynZnOnFAFQSBrGTNZwt5HPiU8sZEg3Ad/ghfYaPxdch28yuYyB+EC9H2fIkUkwt7I
ZrMyc5S5EXtiqIEQ6N/gYvFivZdnVEBD+LGXH1MoP89v8pvSkQiW+ucWDk7QK2yhrxgMPIq0EncL
rZ0RsbMswwh/5uBl1ZPsyzO4do7hZqhJW7jtzaE3ITxUEK7OzyOsnyXYHrNybOy+sWRfbAW5kjt6
4iVV8J9hImKbN7MPq3S8VWmzJBLgBWyUJfC4ke1ge1iE6nEQJGGV0CuohLA6omawg+OFGKC6MGwu
L6d9BJQfla7q9ap+DLx16CAznQb6hvRgrJs9iD3YoCqSM4M0MA38DKGdtAuryCpmFY8tk16ml+8V
DAIQt2ikZtQ4qLrbLn1K+ymEajqONuLPYEySudRvMxCBZ2xWs8NLHOzB2LbBQ4cGybqZe6qrGurH
V/2kMdb9GnmJuPHnpdc89Yc2ro29csNtsfc3nv/gZPo8N+Hz7B15nol4kEUsE62NbKOlg+lgOywd
1h6mh+2x9FgNZlC5MRCVSjsI9zikz7/2PBIj+IvHk9ISc3ERkzmWZBb77WZ276HB2LbGvZXj6xuq
qvfMJOsGDzFVsbdiwdc8kwfXbiT2224gaWs3Hqr3vBYL4tMEYj9ilpPtOP/5kaCRGBknyERGmYVJ
mCmHalLNaJkX2edVuDuZXjTRdOZxZugjqEnAwiyP7f3r78n2IY45QUd3NsOzy9gMbC81IpFnGQk6
6FsrE+ZmcLh0OAAI08q4J9hltBLDEx/W2xA7rHpY2QclESO+AJPfMqwVtwKtOxB/N2JQS6XgpET3
MT5FYRgPsupwft42bmxo26bfqYmfqB4++U7sMdbOW7+8RWjBfnvir3ER7kNw4HlWF8mvY+o0Uw1T
7WuYNZoNhg120b2vwjzVzJgF/75ivo5neJdzu/JWne7dDjqiw8GaEnut7Tj+5ue1ESsjGEggLSMz
gykuMpeOJ4UFdofdzEkZgTTeJNkLC0q4yMQpU989cPOx+qk1E6dOPXbDbe9Ora+JbVq+YcPyFevW
rWDeOxx7tr2zq3vRIhI4/Bvi7Vq0aHH3othrh4nhrbdiH8W+eP99fAqCJ7TqGPc0GKE4InO39vKE
53W8gd1PjLcYdIY+lmNuAbaaXYUyCbd9WiAdL5cU5VXTZ87PyyKoZn9xQQk+ZSnGVMdOeklF7KEp
W3OKilSkgRQSFWv5xGRzNVadCNNxH0JrMJX7ADywI5Jn2KiXShmT1eTXp5uK9EWmyaY5pkW2NTYN
MEaj9hqLwKReSzqgI7UHelJVqdQFsSsrlMqI27fYid2+U5akkeWSPseHMpfjurUpz4ibuba5JeI2
MlqnzLidYSbkrHROdc7n5jvP4s5y9jr0ba10xkNZpLgkiGMoLqJzLARMJcFCn8pm5XElBD839cSq
S4l+5rozL96w4NG5vsnEtgMPzIzLd80fyGR++nnnCzPOu332maumVZIGefzfnr08tq358lQ62p24
OwLcRxCBqyM9ymjDlLRatsCtNReEtGOltLGBggpthbFobFFB0bh67aSCunEzSat2pmtWVTdZru12
dZadT9Zr15S5x4/z7u9A7eTl5Vwjq4sEvd50jdqV0VcxQ26XGTnfsT1frhin0rFsTWJr4c4yO8qP
h8NtYdxgOB3V5nJknCV6quG4Q2grEqMMpAUzTYVe3GsliXlAvYeI6avJ0ZnB7ZioZvMS1UB+RdOc
5jd+cSj2RVPmnA+7Ki4Lp+dU5ef3Vc6afcYF2Tk5YwOZyzMWvrQkfRZJ2XX5X+pmNV67ufBc5r7s
nrZl90yorq0IkslF0yw+1+TaCZONEks0GrOlelxuqWTWTRhHav3j8rPydy7c+Fu3QchGxTXHT6Il
OIrehR7OjUzPEgivt+vDwlRhkr5VaNavEM7UrxfO02t1jfoOfY+e1fO8wKuJfh+1IL0cy3GswLMz
NO0aRiOodaodGkKMMh9GcSpTVoizU0BPEZwtZaoK8DTZJr3cphokbW0kQLe8CY+XQmSu/dHYrqEw
c4hse3ToodgMMjd2I5lPUtiOk1czKUNv4x64AfdANj5vCHoiZ2iV5RfdYq6Yqy9kK8VKXaFpAlsv
TjBNdbSITdnLxHWi5PWm7MtIuzaDl3mNxnAN7/Kl7ZAjWlOpbN3ukzVWPEFy0UvQKI+LOx6XOHQ8
PLrC1DIqy0sSS4sn978ubWItcSC2xPHiJVz23KYFH15z8Iszsuc/ubR6TygtEE4v2Tt+3o3jc1SB
oUlye3DDg5Pmn0m+XPPw5Gn1pDSN1JdM8WTIkdqiBoffJhvZKbE3PmHYcHbp3dSWX4rjnsIdh3QY
B8sjDXnqQk1eWURdq5lQ1pja7G0MzA52exflr9asMayRVrvPTV1davbw4f0+uz1ln483C5X7eZen
2G7XZeF4JXrGVxd/7czE5TGjATmOY8YR04lQjk/+a8dnYr+aAokxj4yWfHUirLzNSjPpwTqledrM
p6+49OUZ8zvmnbmIlD9Xf3tKhvvCWYPP2Kff1jX3qkhTd6xcTs9ODy4qyukYw+RnpU7L8TeSE6sf
qZt6Rn3DHCLd/zuSd17PRisXe1HvP3zL2PIxORW/i+1Ma2usb0tNtVmNmrGBDT/Plj1e3B378TwM
4e7gYXokD90SsgNNEn2/ZK/leIaw0MDMZ5hsppqZwbQzq5gNDM+gQ4WOLVrthMJxk7bhHsD9OlTQ
pmzV49sGCRorXF4uNLQw1swcHmJVV6huPTFXdRfxoAXsir/CTec+gVQYi2fTYGQ2m2XNKnSOy5/g
nJ7fTNo1raZ2d2vOwvzm8ubq5UKXdrFpsa3LfVbBRsMa2xrX+gInz4SL83IiOU057cWLcs7N6S0W
i3UpOSrWt9+CK8e6PH12elzLLnep3Q7Feim83ZUzvI41GdslqaxPVhO14mopy4m72FRejrEQPauq
j+PJ1UaPb7u7oLKgoYAtqCxW4VNW5mzNUmXl+Ezm8jYalAPcqvKn0dUsLiopLaaXoD9xfOMJRRJn
uoEkFtkxnliUlc9UchKi4KbH7oi9cOOx6dPqL77+ovVkChGIlZRvvWz/1bGu8zqDDbIno3Zaamfd
2DHylB7/5lCo7qoLfHPkYA657qGTE6sqfza/51cT+Kp7Luh//bHblt9UwVf+gRkzbZ7ZZCoNVNb4
dQF7yZyhzVOm5hlzpMxVdUs3WKyO8VQlS+Nv4OnwoaKSjkhteVpVsCpralp9sD5rnjTP3G5rT5nn
XlhxVsUaZh23ybh+zMYKs9VXtt+Rs9/B++jfmt7Hu6wZarUnA1VSXbDdo8zmiDaoj0xPhBFtMAKv
oto4dR6UJsRCJw38CUdjVBgjc0ZLFpVw2R2LlsceOjr1l+4x3lUdZ1xdUjlNP/eqVc3XVDd1kenE
sOPZM+YviF0YzvJMy86c7Jczs9MD7WW5yz0sW/Xr2JGz1641CyTd4MvMzt3WXlCcFap8cM+HJBdF
E/t82/qfhnypbr9v6ZRJ7aluu0OnzaLzMx29xyvxbZF675MihUbOyDtVMifzY1RhLsyXqaq5al5L
nmc4/kXheZH/ywxVu2qVqleFgCdm4NtVuA0nIeFSVh9P+Nkmv4U6lnNjfeT8cdS7ZF5A/zIj4WEy
9PsmeS9qUkAbc3tkFs/QL8thyIWYodawqos4ji/ly4QGfqIwn28WVvKLhM38OQI6LSLD7unBgxk0
aqISeG49OlQsRxhWxQuiWqPmNMBxDAzE/xoxa6RSzo8ERh0BnawjHJVzGzqdbbj1Uc30otgfqgL1
dJjObYJNnKqtlbRtk4YGBwcVFgfx9l3V6ulqBtpa/X58HULlaxneG1u9ZOi5JbFNTAa5L3TvvSQ3
9hR39ORKxj70Pn0/O4InzwCO0gZBKIR5kcoGawvTbFvGdNt6dD36cwOixZxzJXglL9PhvcPLeL2C
Z4/I5u4R7JvNOUajkL4JBoq9Ob3C3UXS50MFOL/KpjuO7nc1jbadM+xmJE5knPWvOg7k6y6G5etJ
bmDutJanfjF0PlNz182zZjedu3T3bTFrejh70znBqvlb0ot8C0trcn82pzn1Fzsrq3LJH1YcKKsp
4446s0K72lbcOFb03EMeT59qltjY73mTo37oycnTLXomdjnjcjVRz2wJ6u5s9EML4dJDEIpvPYh2
2TaQuJoG4r+JzFbrSsPjkUSP0xNgM1RZYlgd9gQCrUyraq6mNXVO8Dx2vdoYtlRbVll6LSqLJWWX
TuXLzcvtyO3JVeXmZuwCiyV3oBiKZxS3F7O+Tfy9RThJbdLnBYqpblMIJwjdsFCIQwfsqxbLTo1W
Blox5fTiFRNlV46rkpLSQhP1aXi2/abYO4sXr1q+uJPIBxb+JFK7MisndXZJ6Zb6mbvHV9bPqBp3
df2k7RX5ze4xZWeW1W/xLOrsJGlH+olvSdcKm8kStsZ+4qzx+XIKK8sPX7rzcElpODvoqXHG9rty
JJsdtYC7hB+Hu8SAHntVJLvVPNu9mFmuP59Zp+ftu0XWsVswbtLAeiw6IMtyRG6UWQduCS++S7ZJ
n7YldsOps4fuAtXoITO63vy4I7tWxk7eOfQJk3oPEedd2x9bfdaayg0bOzu3bxm3bBHzzhOxe1tq
irij48oWxh58es/RSo/t5AKXv+qPdDXxKVWf4FNqYXIkRb0rj4/wHXwPv4WP0u94JdwuhtXsIiI1
SEbJViqqRAA9r+4ld+vo1qVOH9qd0Y2Lz+v3m0Z/VJ+ceFRVPFTPXDK0gbmXOxp7NRbH8OORnt/D
ntVQE7Fyu/KYCNPB0I8tyC6RFVgWaJ8mtR7fWbRh7Qwtw3A4OxraKzXeocIwKn2kU3Kqy/eGmpgN
Q5fELlKFVP2xv8VeHdqKvdB9+xr3Bu7bIFx9CIyJ/aodiL8aCeJWDXAhIeQIuFvszalncv+HvS+B
iuLYGq7qZaZ7hlkZ9mVm2AQHmQFEQBQGBRUBFxB3IruMIowwiBgVRKImRk1ciVnckhg1RmMSjVGj
ZnvGaKJZ1KcvMYnZE41RY/IiNN+tngaJ+r73/f85///Od05sqbm1dNW9t27drZvBIZ/JzpPP0c8M
8AhZaQ2tCaVCCTLJEECFhvK0VZWmqlE1qRiVyrCSZ4JW0Z7W0JEwKBTJVCrzfIQi7BHYfx4r85KF
y2jZvnDtzcLLoscZb9URjEUzDSJMKhYxdgVBDodNNiGdFpF9vkOCoa1fIiGPvVQm7H1aaBXy8B7c
ugortlgCq+L6Pz6u4tlBaVlYhpF3grdwltpV0CsXP4mrwKXeljBS2OKVG2CKGZA6YH/jb8IfFIXD
sJ97D9hfxd0fZLfQj9o4O1fEOblmbjcn4zhWIacxq+epJrRXhVQkKKA5uol1b30hKVBafFr8PTae
/VVo7nhXaMbNVCL8PNLhZE93XKTMJJsAKvSSuGayPYRnVsloBb0Kc8pNiiYImjchGtO0ysOosqns
EIMwIo9IAN1xI06MTTvixOg5Xke88FBdPH2pve3GDbryxg3M0UcxJ/zenkbkq3fn9/Q7sI4virMH
TqCw1yofGoz+Spmnj4/Cq6mZpBL8m7piAdEndlv9y3/yhXv4/4Qw+p0hmVnvt03dmxlmqxztmOnr
IxN2UJ/gV0p2pKRlatQ4Rm9Mioutn0SNxnpJyq8CFiwKtRvAmj0KqxYhJ3ngLmfgFMngtOvcmZe0
rqwAc/XW+8C0PezpWyOlkyI7C3N4oFf2IxoEcRCILmMXw+EApUVJI95DoVFq+UCFURlBRzNWhVWZ
okhRjuSzFHOUrfxDytX8OsXjSkM/xQRFE9XEMgoiz4FqfSLb7KFNpEjBUgqatzJpTBHjBBeADPCF
ZkaJGFrO03IlzxJBUCM12JjOI/vgMLAt8ldUQIClkFAhOtLE8opmONZmAXsMYZ/FAlSBT00o47FZ
dlZoEX4SfoOftfh1PBKPwK/TX3c0UovbA0BGvKgfJYo5UTcctGeNpOxyagXVLAcH3puikEwrM8mG
4izZbLkMUX0wllFyDlMMLaPpUJkN23E+LsJO3ABHB1NyOyAqb0Z7lXDYj+wFpiElpiQCqGaGaBQg
wALSbAESCt00EMfBz0KFyVOovvJsCtwVCtwVqkTeRDnlHqLrDEN267LzxtuVckxRLSQYkskXi/mu
CeBooMKZtVFYpBoKGScs71gibMTvUUZcRAvtFDgUO+gCt51glwKtWmQEHeyXr63Q1DO030q5nPdd
CVuim9cfDSdGQlSHHqAOzUaz3Uz5yZv4V0zaG5I6JPZCVIe3xdciru6OUe9wEpYOSZ9wYcvPQjM1
e/mb2ROnCHUZfQbUThlUXdJkCTfTt8oOp4+fKMCGxMamvPpQ2iS9LysM8g0zTUCSZRsvWjYjarTn
eWj9tdHagdpc7WRtgd8o/ypthX+TVqnTLtAYNfHGwcY6I2304lal6UbqmnS0TmeQr/KiNQanETs1
GM0LNAYaNBqziRDF6ZsMQJSk4yE2s14uhC2JlxQ9RC1imNZxBJzRP5MEEhaq6+kpMTgmqVdl5tJZ
k+f2jgwHl9UiTHtRaKFaW1/PH1P62HKGTxrlo5ULNXqTMbu9HxXS8Rl7OjgubsPsZ05lggzO6Pya
rWB/Aj/n4H4U0tlsV4PscM1QsMG8OtH4aueX9iEAKH0DfPvh/gGZeHjA6PhyfhZf7znbpyHWQ0YB
r3T+FiaITgPH0hy+KogxyW1yp5yWy5VgNEyWef66eSZ/cWt5mAqhBOLpfEP2k6QmpMxEoWQrJLFk
LAZLf12CZbgu0zJRV2CZriu33K9zWUAsiUMLdsxCiRIqekcYbIeYofJmeqYxusIW0dKE/SnMA2mp
EJYKR/YLl2f3bsC9loTWhkUn548acyDv4DO4HoevwkZH1ETh1hLblOheSRPn5a0bt2ML/vgfwuX0
OFw+pcJDre+XEDvU0xAaMPD046ewPNkibBtWrNJrBvZKSfPXmQKTjhK9BmEKmy1GC9F2f8w8CucX
TcJN7KQmklfnOS1v55t42m0BxAcXovLvsvVstmAVmgUrG8K8eGsk86KYq94GVv4MzKlDSfZwnZz2
WJlAZ9L1NE17apuadY/oKJ3O0+6JuSYkXyHfAFthdZtmKZEcD/ODBTYhP1hGDHJB7bNnhN3Cfrhe
xC0tKx95ALdQAaC/zuMI7Enva5/yeNvKTfQmWJ3EP4yYk1hoVyLQV4ilaNodtmggYqHFsIVYHo62
kkUtFjFZJm6sMo4dxOaxRayTZcn+kbY+cma8jGIZVtYCd7HMApqie+FIajDOoWrxPEoWgkLoQWgQ
XYfqaFmhO76BHw4OyASSdgeVK2M6vhDyOr7Aq3AlrmRP/2EFw/ID4w0TDgJE3iaWBY+3BxF8aZbj
lSC5MpriNOo5qB7cF7NCkyhSoCYAUhvVdnWRmnan/EDHozRJY+5Hys7PXwK1Cu7i50S90iYowAxI
xExzcS4lRdt9ghLpMWpt4ggqncnicvlBiiHKKdQoZjw3mR+jqKGKGQc3jS9XVCgbuSbeqZilXEq1
Mkv5VsUS5eMQ0z7Or1bcwLdYk4qiGCOlZayUiUmlYplkbiAfp+in9GCIX8cHxyVSJigUXTWe1ETL
xgMOFEEE+s7YB3oFJfK9oWiiMKX0WACccYIIcvImGQtOMM/qcRAbgvuw8XgAC6xnx+IJbAmewcIW
sFopqJRK3PU4F/QWFGQTxH3whMKTe1uoEcYJvwrtUNbgR7/GetyE2atkU+jj7f1gYzoZTH5QD2lS
oo/tTiXFcAGUgWM0FOKAaC5RkUMN5iZT+VwFB1aJ82jE9XQ92yCfw89Rwv4BJUipYGUsJ+cYXs+H
8FQU35+n+GYFrcAQ9Ss5OQJvO0qeLJ8tvyZn5C1AKwexOCOjiYNwEXSSNlFmJo8NSM0HAIbUFMAV
hZJhIBK4nUsDu28VH2Bb04jxJ0q6cObiI0e07nAbYA4ibi0p2CPEPBaazURpu//LGCFDOAwnbDyl
7biFD+B+OA1v6/gd/yB4U1eoS4INn+qIBn06tvNLZh+zEGmQDVXYh2p82Wg/3yw2K3ACOyFwOuvQ
TA+cFV4b5eyjwr8YjRbvXnaVJrFXr9CtFq1qq7e3zYhtrdbX4qxxWBNpjKQiI+Wtfgdi3Y/vRI82
jphR4gdadF3GNEGNeyZ0fMQq+IYkZ9YvLPGORx/gI+ZlbY/ul+zh62PP6FfTO2hsREJtxsZz1eVl
OHJD2+oJx6PNyRgvwPFYJzyOw3+Qeal16Qmh0QaDZ/RD3ql6X5931t//BITBvKxwaJoOazRRh453
MED99s4f2FSZAXyFINBvYZk4M2icpkLTxDb5yQxr1VoeBbTR3pxuITpolPkoW7n9wSJNEDyLZLl9
Wy0ijq2cKFGS1dVLeT6dO4+bKly4cN9yu0bYiivzd8785BthWcXC+KrYXkNiVzxMpYPnticyIklm
6Dg/KE84Kfy4drMxqOOEWvEcSOx42J2ZTAvqhZbYQ210Gp/iFxtgpzOZHC6Hz/HLCMg2TjJON841
qSNM4Fsa4PCRMExNDqgXNGiJs2bTYq3WZ52HNi0Mh4mZUGgMCwtah7y1KEwb1hRGh1mjcFhUURT2
Xyg7EElSAyT/Q56/XiaukGgvLW4PlO1Ob7oz2CSf7U7SdecwE+N1akxdX3V94oQSx32TrjTXvTEm
3ivFElWS/sjjG1ZmzAgL6esdX7A/eEhW1mdrnvwqe+iguEjhpN7m4x2078nNzxm9DNFewslIK+zQ
xM4vmCuwQ57IhFLtkcMVw/1namlTbxXRhiCKeuS7Tq3FwWtZb52BakWvhQQs5A6YgQS38KVdJvtE
UC+MIoIXGkLpbuMOrmQP1JkrQlvh5mknb+YPy3ijuHxBBq4U2iLGhC5fXjs/tro+ZxgegD1WfDoy
O99ixp/dCqF6adUvPvnMmnDAk+xUO7MIeaFAVG3PD6MsinhqgGIwlcvmKgarc7QT2UmKggCHbDpf
ZCjycVGNvEvtMhjwL4GBHn5b9VrEabl8rpSrE//YdZuHN897t6KDwdZgHIhbNQeC3DEieU7f5cR0
nSezO6IiXJcCXijD3YlTpr39GLf/5dozqZFzzi0UXhDacAGOAjVpENbT05yVizj8c+vDeVbhYmw0
tmE/7I0zIchvL5hZW9UAEmiB6LJFFgy6024Pg9irzQsrOfVWnUZF/pKDv8bf6A+WjdN5tGqmQBBP
qUBqLoObKSqxZDGlkJycJj4Gwu4nH0HY7EWOSmhCPEgR2Qa6JcA3N3paNvYWbgpt69df+GxUSxzr
IdfnzOBvtD9K19wwvv++kifSIExgrsB5iAAvssCeNMJ7RJ8R8YXehfEO72nx87g5HvWhc+KVXmG+
lnVmbYQmdq0vRKjrZIE8HxDWywukIyFmYcCBvqCeiJ8f1xWiWslJFt+vKAy/R6A6EJMWdFtuEu+U
m4mjR3/9SP2l/OhBr2eXzTMbA9OfKv6pE40YOuho+aQ1A1W4UGgzTgxbvryxoV/lgqfODUxNDDRg
P39LeIipbIhXQirsccjS49lDRlgi4to7cYdKs2Xl5uYQYrW2g1enhxPgDRoqFHt5eg3QOb0YrFVx
azy1aqTCQJavzbfIl9IqW1X7faRcAlFQXUSZzbq+XdkP0dfrR/juxeqFtWqdITcztjwF5KKy6MWq
vSepPhmLTYBWaPtXoJM+yh718UckRtkIRaD07kqs3cw+5Q4baYgYNZh5ErWyTyKsxRQexRfxTnAy
uzzMtK6n8+SpPKUn6yiEVjyXKd2IdV305cHMSnTMPgYEiFcrjdjI98FWPg0nUWn8CJzNF+IpfDWe
wTfhefwi5TZqk/IwtUd5nPpV6UfeoVkMd2s4I0dxw3nM23Q+ifwSyqaEgBRT9Kud5+wBANMKpUKO
OAROmULDxisHK/OVdUp36B4MylJBKRW0+7mQVYWRmC6hOLqV3e8hBVBAlBiOu2Na0CposfaIhTti
YTssMxnwVSRPEeJUufRsFrN5QqHwdgmhG7fiDUIV/r5BWC4ztE/BV4VAN/2UXuRskF1PfjGiVWKk
6LkSRpKtdPPQzT8Y7L5PfgbOQiS6z57OeNOBXoGRvlu9nw3Y5703gItY46/V+RgpRs2vMWg1GnVw
q3G7D26ldKpW9XZEaSn41zsK9bb1HtXb2bsrLdRBXqy4IckOkCjqF50oPm590uNJrVh69ehkbghr
Ob0+a1BCWSTBs3D71JrttqoTJXsPCWvlet3wwX3G0oHtX1GxeXVhYWaLb/tXTOncrLzSokmV5092
hFOx+bXQbuyWeqDu3lKv+b+Req//mdQDSqLQE53+KRsBOl2JQpHZrvdq47VmcAc04A2EB4ChDBP1
iPsZYVeY49a+uF+/hL73yJizEcIh4R9wHcKZOATCnXQhMzQ0zGSa2Lfv6HBzrxCzaUJy7AQqFlTw
UfDYvLAPThWOdJy3NE4vXRQZFRLYu9eSqZMXR/UKM5NTuV0oY1OBS8Q6ptktGVSGJsOUp8nzLNeU
eYKzH8j7rNVpPTTB62TeygADIB6iDuBbPfab3W4M8Cut240xEFRFzdfFrG5Pxo18akHmsL2VRYuG
ELaBK/Ph98IyZyO4MmF5kcSVWfrV8BGjosKFaLazHnyZE8JPT68GX+Y9NbdV1N1lou4muKbYexFL
nmuaZJpucmrnmOTEius1xIzjgD8ZcklV98DTrLvDjN+ljoW28c853v9VNONTFgwT1W+3HRfKKMXQ
IbdNOSjcj25bclHy6HPMVKRHSfuwh9ODAqtHVIQPhJrMGo1GqeE5hAxWA/aQt/L7PbuSK4BhWofF
/b5D6F2HhT5n8qkIyZ2VQXjXsHu4p01Pe3CcwbdDy5Q+UzGY/MYTRlPA25kDPLKhFrs2zprlO9Ra
jxuVjQH1oXIjcerMEOaxJihSdKA9/SOZIHoUBEPEzTObw7cGaeUEVU+SopOrt9Le5siF/rqFZn+5
mBNRiDmROGcclruDTX2PrIjF7euRtEih6C9Jz7J18d6S9LpFGv6Tp9px7qdCbq77iEOYOcIx4Ze1
N4abA4amJy0fPa1iwJjIB5MeWw2euWL+t+nGUScd4xr6lSU22ZcvwWUvfJIUgiM9+/j7mK0xUeE6
3ksTuW3+5rPxQcJXiZm26MjeXkovbfgG4oV0/kDPZp9GAWi4PVrBBrCURgkRnFKrkm9VKjQBAT5A
q5q8rICCNEGYU2lbFVyNnJAZH08euurcbxOSdLTonpCHXeHuoIM4IuJGkfyE9Ig5np7dv+W+D0+u
Xg1ae7Swi9Koh2YETtIHKzS67e9TqhtwcA/fEGpTxoeGRvkqYN1NnV+wPFMK+irVHqWQ+ctyPCd5
Vnk2yed4yikvltfo1oBoi4LtVlskmPARH02RtL9VfHeEaC3JS40g2fFufHRmlhfayp6te+1dPE1p
8MzNjHH2xZVzc0aeOU1d6PioYGZ4eEiImSb2JBg0pxdgIkNV9rDdLDh0ftRQdjzLkKzHYjHrsYim
6DI8nXLh+ylGjEXNvCaRJgVJsGioOaievI3IWbmRHIVoLYyHcM6dV3fjCWF5z9wIKpSSI6yXMFKo
FPLwPMxgzJTeepIpbW+nGSLdfcBibQPMPNAe+0yekjF+lDcTRUUwyTiNsjEpfLwiC4+k7Ew2P1gx
iSpgJvP5iiqqjKniixXzKCczj69VBFLKRR7YgxDCcIzcIKduwD4vghB6NL6PLcfT2Jm4iZXVc3XK
29kXDcWJZPp1B+BITRwYrdokJl9kXckXd+6FJEULxSBbjLWhJC+AmpWExADyX75NeFpo+foLYR5E
dXOOXMVpXx0itFK/diiB3j9oGfkhNPvDbtiBZiW6bNdYKRM3lprAMdRwd1Znrz0CgEDWU9mfTVCO
wIPpwfIR/AQ8lh7PjpVP4Mcp1UqS82HJ2Y8mGaA70hDZ3e5OjyRENjDk1c5Tdh10yJd0JyE04laT
fJLCveUSL+7MQRDnh9EyFOPe8ntlIiw9MhGWP2ciSAJLDLaUYqImgLhAdmHy1ZtCGT4g5OCnf7qM
nxSy8ShhNxVLxQl78fCOs4RTwWDLfIBTcrTMnsaxw9nx9AS2gmahAahlduD94BQtJm/JPi3fK6fE
LVfSctaXDqctbBI9jb2fqqfnsC6ZkiL0hYI0y4hIU4h1v/CqYZkAiuKt/EhefOpB3rJza27yikMP
qS4UMyxHCEW4sCvbRD2DEa7teESYswfQn4OXUWf+wPhpZhJCyChdWWhOj+sNzItXLM6FazZ5Q5ha
TMfSD8JRbGM+YttkkXCV9Lg+kY+Rf8elcLO53Xx/3sU/x//I/6hQKRYp2hXtygK4jnk0emzx+FLV
X82rV915afSaEs0lCPu3aH/Qlem26j7Wfawfo3fqL3qaPWs9jxkCDRMN33gles31etd7sPc5n35/
XX9df11/XX9df13/Oy7x986G0CO6v8MgDnV9cQQGVyFOginEoKMSTCMr2iXBDHif+yWYBfgdCZYB
/JkEy9G87nl4cBR/kGAVzkG/S7Aa9aYyyLdXMDSspQa/3g0zKIyqFmEW2hXUZglmkD+1UoRl0C6j
Dkowg7yp50VYDu0c9aEEM8iXekOEyW+OeVBXJZhBIdR5ESZ/VqiMapdgjNR0kQTDPMx8CabRfcxE
CYY5mWoJZgFeIsEygF+VYDn6o3seHgUypyRYRbUxP0mwGo2Ru+lVENrl30kwg4Ll50RYCe16TibB
gLP8pgh7ENy4SAkGfDhfEVZDu5YbLsEMMnH9RVgrzhMpwTCPNN6T8JCbJsHAQ85No4HgwzVLMODD
OUXYC9oN3FMSDHvELRdhb3H8GxJMxu8RYT9x/OcSTMa7+RBA9pRnJBj2lLshwkHinn4owWRP3XMa
xfHBEgzjebUIh5E95ZMkmEGBvJvGPuL4MRJMxosyxvXgM9eDz1wP/Lke+Hv0GO/RY7xHD/57SPzf
Zoqz2ZJMuY7S2pq6mgqXaXBNrbOmttjlqKmOMaVXVZnyHFMrXXWmvPK68tpZ5WUxY8try4qri02O
OlO5w1VZXmsqNtWWT3XUucpry8tMrtrisvIZxbXTTTWkp0e14t6rmBzVJpjGVFDtcMH9+a5iV3md
qbi6zAoT1IgLlNbUV7tqHeV1Md0z9O9CY1BNVRmp1JGpEmJscabI7kFR0qA+ZFBusQsmazANLq4F
TCfU1JtmFDea6uvKYXWgpaKm2mUqrjM5y2tnOFwEk5JGEa/Mgpx06K0VK87amrL6UhfBuaHSUVrZ
4174dFSXVtWXESbUmMocdc4qWAAIgbscMKAURpVXu2JMXWvXVFc1miIdUabyGSXkpttTVXcNvidG
4vAyR/VU4Hsd8KWUsLHH6iJDpblSRAQiHbCKq3wG4XmtA1Ytq2morqop7rko4FzsxhQ43s36mnqX
s95lKiuf5SgtJ2Mqy6ucdxBU6XI5+1utDQ0NMTO6WB9TWjPD6mp01kytLXZWNlrJEnVWNBaVo1pU
hopRNfzEIhvqh0xoBLROhfZy5ILWP48xQVs9VgH8/V09FVAvu6t1iDiP695r0UvoQ/Rb9GEoX0Tb
YHQctNtQEkC5yIFK4Y4aVAc/FTCDCQ0GqBY5xbIYWhwAVaMY6ElHVXCZUB60TUWV0Fcn1srhk6w7
S8Qt5i7sHOK4cvh0wV2kzyS214o8IL0usZXcTWgn65ZBbQZ81qLp0FbTfc+9eyv+j2ghGFWLcxFs
TKgAag4RB7J+vrgjLpEqk0hDGVhTNwY1PSgohVo99BKMHOLomHvg0P8ubgyCniqod/XUdWOVADPY
YHfItxzdPVPUHTP16Z4pV8TXjVmDSDXhjJunE0QsTSK3GuGzXtwrN+3ufakQV3eJtJK6U7xvhsiR
Lp6UiPd28SsTOJYD0uC+t7ZHj1PEuAxWKRVndPO5QVyrFMp7r+uuk7GlQE+9uLtuSaiBskzsd0KP
mwL3jrjXckgzlEpzlYslkdU76Sb9VSIUCXdFifI4A+jqWuleWFXfNfP/nEe3Zy8TZ5oqyXudJC+l
3dJ4b9pvS+if8UrpwQFCiZsWl7hel5yT+d20lkFLg0h5jXhq7k2pm8/Ff+JpuSTvd0o94aoLxtWL
dxJsZ4nUlHfPQ0ZWwYj/focqRc454RRY4WoQrxiRo3+W+hjxzhkwxgUUEQqnijQ6YYZGaO2iog7d
qWlv61jHPXVsDrRXAjQLZiAj6u8aMVRcqU48MS6Rurv17vdA63R0E2b5Hnru7B8r3nln6zAoq+CO
inv2jpJorAf5cUtI439L2V1YMUYmlUlhBjP9mCTGzgxkspnku2YY8y8tTDbBDsdC7e4eIsFOoPdu
TuSI594BsPRFcJ316KN/8SUdNHkkjbQId3a6vw1P/ENI3kj6ljz6FZLp7hHjIKRAfcGS4apiVzXc
Cz5yzphhJuSdNzLXhAJhrU5xxR5l931JYJ/ufV9wjztw9ydGVFVNaRVSi6VBnAdLs4HHC5GAu6aV
PiOI34kY+kH6IXop/TAib+z+E/0BXUZsEmscwvQycRaXNJs0X0ApQtJXdqKASbaWgHEyvveiYYt+
U2E5tbElYBg0ZVAYxyptvIy1qGnKn0W2YpnCIsMMbkmkMLMx3zbaFt2jJXBzcHMgGiBeI0GA6kQT
US4evFRy2cw9JmMMHR9cb571yDfhfWK/y3hhZ1712l8yXt3Y4t3b1sLobS3UHxtJ+p3SQGC5dMCA
JbrTqTdLf7pot6m6MSWRns0Za7FFyegCRukZMrjG2VhL/GdTZGmUKTY5OfEOHzgmNtgW6B7sdU/v
ONZsM5J+2tP3dn9eTY3LlF7vqqypdbgabcE+quREW2yszZZog38TfVRxtti4+Fip+h/AqAWH9GQL
ZhHdgjUI2hVUC8ZoG3XoqPOblGsjAiI3rJt9n+2HzduWhU/5XViTs2Wf8ORmU+rc0Zsf37yiKG76
6UFljVeen/XumPPXfnxiUeCKDa0VL709fU5J6JmgAZ9p8Mrv1r51uE/F+vWVEY+d6h992OOV8RFH
h3yrSE1aG70tMvm5n7IWDrrUqjmwvqqg+PmWuZuK+jTkfP/Yy2Up60cFxnJhhg3bvn3U4vvNwLZS
Q9F4tnxDUGLe4t+2/ryaeifgo8MFmS892Hy4/09jVo94oWPrnBmuEbt8T6zlI81o3CNFjsQD2Xr5
gLGdk249XaHgnv1wwdhxP+9Nuc97QQNz/ubrLzSvEXafbDqz1b928oDjB69yW0JsL8keePclU4Pn
AxfJ977gLQuesy14xrZgM3AzCDML1tsWrGvWTjrl/NlR+1To6PmGPbnLO9/bVPv/f/9a/o2M02QP
13ynPLLs+jrfhMuv4rBzDbrrk4viNjylfC+VfXTJinf7f2O+dnXcquhXNg49VvJz+9kTKSkTt/Ub
4xDCZqS9e2L7Z+zcT2OXDdygdU47IOhH+jqOtJ8afEk30TTyh5L7d233O2ZJDO/zevkm/UPhmtIt
v40J/Kf53TNe1/Oerx4cJ+9o8fn966lVqtE3D/2S97dD375lazfF8kuC1kT5534SRD3zS/Pn9MuT
brz46bFxV8qz/pY3Zu/LdKS+85EzV7kV819d9/aOxOiv5nz1XMOlWRvRqWlpRz/s99Dn6frnEqYF
TLuQ8MXHgcxXz2UyxybGJ1XnBqpK9ik2P/zRJ2PShpwMLHjWeUHff/Gq+g1bP9wIWqHI1kLnuLWC
ImaH7h+jOic/+d6RLp0S9J9SBnDuk+LgH2iAOFAGsXFQTehSBo2iBoVJZJ5UQX6sp01HKpynYlxx
XSXElC5YRmtTk0a5pzyvvGxGTXVZF2KKf4VYqM3sRsy/Z39ZuSnfMbWaRKqjBqf/W62wr3HemcKX
MpOf6/t87Pl/hidkNRy5ZXzqb5kzfz495LuPH35zek5eyY3HqDdzz2VVWcNSyw+/H7pPOWxfU/2n
mYe2r1CPejvccm3jt6pQ4+n0sD9KHvvAL/OZVcONj518yRry5vA+c2v+7hWc8nCyNvnTQ1E3KlL6
4LhOodewZ1+pwoufuPXantKmln9O3rig9YHlu6+9unrLB0nPjnrAp9fiEZ/abqKBN97558AFry+6
XJW8NabvzZdjdinmlTw6u+KJtjrVol3X3rpu2j9Sv6z0vei/x2X6XTkwfG3KqHzf9ytGN27fufjY
2NQNLaOWVLMvJhy9P+xQXsXAx0acsMyPr24dKjv91Knhi6jqRejpI4sv5kta4Q/bgt9snkQphDMe
NoWMA4PGsnKa/t+hKjQER0+MOxnWRsOHLYg0qBlvxnAi6P1ZyDlp1y/n3xqxfnRGzJaM0qs2JenW
MOS7Yxf1ODqijrl/xwvzh0dce//gCNfm8b1cvetfWtSxI2f1bJT7/fEfff/heFu9ee51avA7xxef
+D3/xBsbDo2tuVqasS0DXVl7bP0nga8qN/ipVp89H7wzat7Pl5+te37FZ8nLB7ZNO5g048Mlu0I7
Ln5/xsE/uuSQ8AU60Pf6b3P/qdXHsD9GrV01aHrkzH1JKz6Xq94trDx5qDl9esVzB/YdWN73+DVa
O3fOrx9+Puji/cIXXzwv3Lz4ieol55mVl0buTdo8t8/HAy/0VZYkUhsWTAt98Obk0hW7Jx5IPlv0
cEGrf/yvKW0bWzw2T1n6UvS+Tc+8t+O8ae9hm98DJoOq98G8G+mf32e7tDLSsfio88vrW3e83zyo
dpYadMw00DF5ko4p1szOdTuNPc8RC3rmP3iquxROvM0GGiceFI4t2RZHqvGkanP9P0FN6qf/Rf+/
1TWbLyiWffDG0azHT27v33dn6ITpF6peN4fsW33shxcOv/NJxBtxuqUHzxdG3+o3NtjL8sIK1aeG
LdWROU3eaenPL7O/OGSJ6u8LVu9cJzs1LmPW5B9+aVd/2eTaEv+e6+ufLxVvmk/vy+z8JFX/ye7j
96lO3X9tn6eqvWha5AP1D+/befCB73xefuT1X733lhRe1l3sf8U8aemu5ro3My+tebCh6PFvdzYc
TVwWb7B6Xih59wX/bSPbpu782JRsm/n5sqlDvnwn8IZqlCvd+h0bNs08PWv3yrf2JP9t0DMzJvsO
37Hi7PKFqbMVQ889vac19M0vr91f8eJw16GI9Ownig1FI2zHWq6fUjrnXinIbfiQK5i1QNI1v9sW
/CryPkhDTiwcQtmRHgf2utm+fO7o38dkt33tc3bawr5sTMR391ZNRE8EhTK+Nu/mex/zDDLAyAy0
pdiSNyZuTFgUL6UNS2ur7kgbOqc7SKtVSrbWWQfng6DFQJNtWNeS4IcMsPW3JXXVbdSi6H+ZhxQn
LK/tMZPrjgMkahv7uJr8qU+ZFvbF6m98sgfs/PHcgqYrqkZXw8h1Q32vIy/H/Aslj2zumLrpia8i
o/4oOPuYMOrwffxL+5+93HK9Lbhmwh+//vKFx0dLuVRvH9PpI69kDuUiisbx2auvcidey62++uUw
fWTCUnPtxSl7dzn0YauvfN+XvzC/umalIu9475ys7XHRi77bdKIw4uDBAZ9P2rNQ+VpC4MjWzKGd
B1ZvmiDftvbT2YfGNT2zdcSJazufWJ/+5XuTw1L/0dR36IibHxy7/8kf9777RKkhf9fO9T+fPfzB
xk071hyfY1kc/V87cPzmnxzmW/st1n68GCMpzn/g+6mGZQIcUncnKD/fsNDH7tUGQbUKvoM6O5dk
H++3AZY2c4GlTSustPGseQuZKBu40iYkMze1uCQxtwC5tDEzsDQ0MzA0NTUCN28MwVwjAxDXoHEZ
TdymbqAKqSjl8pwzC0AD4y7BrgquwX5WhgYuFrqmFibmus5ObhYwhczCcjg8EZxaBBpKJ1hAvdrF
mnziZuW6Fhe7pZuPvPWZp3LfskyO85qRV0TFJe2bS9knvH9u+3uvWs3i309r64zO37TttjT/9OOG
tYnYlUlNv03eZLQWSfU/2OHzYEfrZ2MupoOLyopNfWI/bn/oVSu7Y0rF7f9yraJOboXn6tXDhS42
+1uf/3XvW/dbe4bHV+8l/hTv9V7SaPM10+HVw8797P67Sqpf8jx1f7U65+PV9EaOH2KnaoV3Fz/i
9PmV9PvtAstZVv9eC55IlEuKuMEV0nzV2tv7Uehe/QSpvkmszrdiXzdxKU/nXMBqmNo92U/OUXHR
pAl/XV1c8003upqvzVyZ+tPEeaP4IWvLhwI9n6TaH4cEyFvPNVyLXEAhCqS6og969mGaD1S/Z+xg
/OP9sO78YzuUsif/hZ/99J0mq73b+vfMebXG2tH52AWKyp6S4oLkRKqUPTCTSrCVoBwYpTCWAiqz
qomTR+zivfNunXr7L5pUNdarazhqfb6sOIlv+tr44DjNn28PhnitqP0ufIFb5KfvpzZRhrzHzbIa
rst1LI3u5s8yj3qnHNQfwtxrv3xOisU3sxMiztus7Gac5D1c2KjxOW254aOY2P6fQUEPY15PnjA3
k9On8+LFMh8T3qyHNS7LtaObQ+pdVSRVj3S5HVV9LNmQqSnyTfzYByWdRrc47S8/lx0rt1PO/7ks
pbVvURLvSl25FU8n2NX/39D3Z/qbj39Z1p/1PBdVsubXZ2F5actzi7dc2/Nly7sTaz+Fyf22+Xji
mpbLnv1z7GvTJM5uUkjmOuVgm2okWbNph+1BNQ8/JcmZeT0GBz9ORC2gBLK4Z/ofYFBdLXjbVT6i
Kn0RejE1MJ0vaOlkYGJiDiqdLIHcAeh8YRSchMqbO+Z5v9efcPIqlDhxzsMu+MCv1SK7dIx2C/kH
nWh+a2d809Nwksa2iSkP5ANadh3yvljP+uN96b7u4yuursssSKtQT3uxbfv71p1n3636K7SEO1JJ
U/+8w80wFumyrbkpuV4ht+9+vLd/fvPxhvv1PkzmU74emMcRJpfhfvbmgbIY/dptqixbwqKzZJL/
N9TYvLvKouprWV7CHnso5kabuU7pSb5XcpacNWX/5ubkVT14Y9c/fV4hX7yWv0RSgtG8S81+2kox
Ga7d9/RbBAI2/dwq1ZvzTnW28I/TAtdb+b40lRWbHZtatehMAtsb1g1txtt/TIlucWyJaJ2St0Fe
x+NM/hznB1kv6tX6siHlTROjBjBEVLDn0CHR/RJg44QOgIoygu/jQCo9sRaOknANIkwsPHJcDMHg
0XZnBkfUrhlGvw5LATXFV9DwUE3AbsG+hYnsjHw9Ba6974tD9tpzsur+3xEY3Crz1nLi9sVh3Pd6
tllLX/y9ZvnJ7RsDFaXzOTLrspkXKbm9zdmSW6O0w+1yy+de/n3sXWYHX9e9LIh1nT/p0plzd/sO
PNyvdbbmzcl1Rlfbd55OPmJ2UUJxf9k961mbpYvnKXbc2LJFKKTny5xDqV6zNNTmJHTxWx8XTq3w
2H1+bbOV/4akiHsGL19ayj7u/HTLsvGnsGJPSkMyG8u0T7OYnPWr3Tp2/We6mfrT694t5pLJm1nz
eM7MvaORWOPxUXyOoKIFk0z7Graj04x2PHU4Fmy7d2XnvRdp5r1flKbNObOhPCTQ6lqRyyblb4ZN
LPOBhdRsJkZGg8b2AeyVofQVEWPcCxpPGYjA41uD0ZCdmRU8RwFKBdDI5GQ25EEeVge6BsHjNuQz
QJYVNVBGaGQxBKaxX1++i0rZvClsN4/J0L04S6MpbvcMgxAkLTyGbgYuC6QaJHBNBi9Ua1AhYkmB
AlpxxtLEyNApdtvqRZdJ+ramx7rBXGsPH2GY0+dy/dKvV3zrl95rm7w30crKbE3FxELBszb8Pzwd
w27cKlspYh3nGGb36/qc01ztfEt3anr+/LLxZX5zQ9glpkOCrIFFb0qkQ3rlBRfzBmw5oda1himz
wLA95t9sXeE+TZNQ20plGZ4l86zfHeBg+2FYHjFf68BCrX9X/ppI+fuppHNMCSm+LWx+47vNaXHV
fzsultqnnyq/qn/Ydaba9M1feo488Mxl3WbO9OiUeszKHq8Or4DlSg1aW/tbimY5Rt1dn+maJTKB
K3Xek6cSznvyeVyWBsls1cqcKsz4VdoiO9b7YZN0DpPFsaJN/bJHOFwVX7EdZNuwsIlJ3qCJSRoR
J2yGTUw8QCEOuidJ9BoIpUPBDk2SC2INJJBTHjdi1ocRaCdchtWQH1i1WhgaGIMqUktQSx894dnO
XMiyfNXfo4v+q+V+TK4rz/TLtUAro0BJJNtG5vTB8unfHp3iT/G48lO4+4vDwgq/+0LiWyOyhLPc
+oRfekS3Tdf5/GRO+qzTIYbvFT6KNs15w8vgEa1eljLBdeW0ysM1daY9S+KFUnbP3l4iLbv/MFv7
7sV3U0VNhSwmVL+p89uuIzT9k3Vlnvnb7HNeiyJ15+kYpLf2qG158SBUSPn6dLOziSyFF62qU65M
O3Zn5blNr+9tOfpy7TyRsLlNZyXXzj51rGKO+uunnZaK6TEH//RbGtnJ7l0z9axthLtBpt+87qUb
zbamJtU2eNsd3z5v8Tx52U/NZhF9T1ef1P632Z+7c4vETb9X/wr/BdeLShy/KiV3Q5u7KnD764YW
A7nKk5s2Sx36xAAARFDsww0KZW5kc3RyZWFtDQplbmRvYmoNCjkzNiAwIG9iag0KPDwvRmlsdGVy
L0ZsYXRlRGVjb2RlL0xlbmd0aCAzNDM+Pg0Kc3RyZWFtDQp4nH1STW+DMAy98yty7A4VJAHWSgip
pavEYR9atx9AE9MhjRAFeuDfL9isWztpkSB6z8/2i+ywKHelaQYWvrhOHWBgdWO0g747OwXsCKfG
BDxhulHDjPCv2soGoU8+jP0AbWnqLsgyFr76YD+4kS02ujvCXRA+Ow2uMSe2eC8OHh/O1n5CC2Zg
UZDnTEPtCz1W9qlqgYWYtiy1jzfDuPQ5P4q30QITiDmZUZ2G3lYKXGVOEGSRPznL9v7kARh9E5eU
dazVR+VQLb06ikSUI0oJSUJ7QgVWmnPS7wqXhpyjjMekfsBcMaN7vGJO5JrIDZEpkQWROyLXRFJr
Se7iAklJ7uQKr0TOtsgIv31ZLEi2/+2e/3Efk9GE2qf8qqi4Lbqa3iMiIdDQliPi8v8W2wRrb1NS
r65aTDOaVumyAOrsnJ897hsOfRp3Y+CykrazU9b0fQFbEcp/DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI2OTI2L0xlbmd0aDEgNzE5
MjA+Pg0Kc3RyZWFtDQp4nOydeXgb1dX/z6ya0cxotIx2SxpJlmxLtuVNduw4lhLbSRwnOIuTOouJ
Eww4gSQOSdOQ0CYUQkKgIUBL2UqBUmihBWchJCwl7JQ9UGgp0DdQoPCWAG0ppUCk99xxwtIf7/Mq
f/Tp7wk69nxm5s6dq3uv7veecyVbAgoAXAgWBjpmdU2a7to2BHB4GMC/cVJH50SIM3cBfHou5gpO
mt4zy9RkacXzG/B8zKRZsye8XvpWHM9fxvPvT+2dNfnKic0/A5BKAZg7e2al6s6YedV4AOotvD4w
p2Na3+q/nLUMwHIQgDt40rJFw5+eO3QvwBYr5rn+pDWr9anXj6cBLjodzy8/ZfjUZTc8tWwGwPm7
Aeg7T120ahjcIOLjrcbyrKeefuYpf77wDy8BXMwCzNw6NLhs7bJewQOg7QdYNX3o5EWDz3/01CIs
C8uDxiFMUMsErB9F6l86tGz12isfqr4Vy54MILx82slnLK8/t7IH4M942dR2+oqTFlW/6TsH4I/b
8Xz5skVrh/kE8228/1HMoC9ftOzkd17MLgT4axbA7BhesWp1vgfWYv16yfXhM04eFobfw2sXYn/S
nwLpa44Ljbz64vyFauvfwS8AsZu/01FB9g9Vt+ifnHf4UulSAZ8DbCcNo4b3CVJuJoBciddXSpca
JX3R9pIUZg9MB8Y4p8EKKZiDB2Z8XCOFtVHbgQOBu5KrxyJjo3vmWlhL3yQALfEsw7EszV4HfD4L
+nzSw+TGabN0HTBBj/DB3Fx4TJCoW3Wgfkyusf3cAdJSoIQjVaKfGd2YOBVlfgE/4y+EB45WknsG
VpE9cz3cjtulnAtuMu55Gy7F8ytwf5i5Pv8app/PuSgX7q87mgf3d42mw5W4rcNtJXM9NQ/vexMf
I4fb3/kLKZnth2uxV0e4teDjzoJHuctgFZ/AvQqPslfAo3wDnjPwKHMinM/8BCqNVqzG9F9hnk9x
PxVWsc+N7rntmLYWzmPfxcd/CXaSMk1vwwJuPXSw7wAPX2GcK2/0N/sUDLGfwj42CUtwfzr7ICzF
fukgx5wV9tF1cBt9X/5+9m64D4/vMj0K+0g6+xIsNe7DfMxS4/7lTBm04bUdmHcctnMO7lvJMdsA
/V9Vh//fDJ+Tff/pOhRiOKau+OI5Hc8fouNw7X+oOkUrWtGKVrT/uDF7KKqkpMZiIbEYRVmAUilK
QgMCCVMsFkmus1i9UadFXW2GqlKLoiiWuspAXXWJzSiDAkxQlBJF2k1Zdtskq6IkbDbJbFXNtoIr
8q9x3/9uEsldePaiFe04NaJYNJDhIyEPAgj5HK6tzEizQRQxUgYZqYCSPwwWsCBVUJFWgzawIe1g
x+jeAQ6kBk6k06ALSNTvBnf+E/CAB+kFH9IHfqTfYAmU5D+GAASQQQgiQ6AjdYNhCOf/CRGIIKMQ
RZZCDBmDODKO/AjKoAxZDuXICqhAJiCJTCL/gSuZSmQVVCGroRqZghpkDdTmP4Rag3VQh6yHemQD
NCDT0Jj/OzQabIIm5BgYg2yGZmQLjM1/AGOhFdkK45DjDLZBGzIDmfzfcGU4Hjne4ASYgGyHdmQH
dOT/Cp0wETkRJiEnGZwMk5Fd0JX/C0yBKchumIqcCtOQ0wyeACfk34ce6EFOhxnIGTATORP5HsyC
Wche6EXOhtnIOfAN5DegL/8u9BmcC3OR82Aecj4sQC6A/vw7uF4iPBFORC6EhcgBGEAugsX5P8Ni
gyfBSchBGESeDCcjT4FT8/8Np8IQcsjgEliCXApLkafBafm34XRYhlxmcDksR66AFchhGM6/BSvh
DOQZBlfBKuRqWI38Jnwz/ydYA2uQ34K1yLUGz4QzketgXf5NWA/rkWfBt5HfNvgd+A5yA2zIvwEb
YSPybPgu8rtwDvIcg+fCufnXYRNsQp4H5yE3wxbkFoPnw/n5P8JW2Iq8AC5AXgjfQ34PtiG3IV+D
i+Ai5HbYjrwYLkZeApciL0W+Ct+H7yN/AD9AXgaXIX8IlyMvhyvyB3EdRXglXIW8yuDVcDXyR3BN
/r/gGoM/hmuR1xq8Dq5DXg8/yf8BfgI3IG8w+FO4EXmjwZvgpvwr8DP4OfLnBm+GW5C3GPwF/CL/
MvwSbkXeCrchb4MR5IjBHbAjjyt42IncBbuRu+F25O2wB7kH+Xu4A+5A7oV9yH1wJ/JOuAt5F/JF
uBvuRt4D9yB/Bfci74X9yP1wX/53cJ/B++F+5APwIPJBeAj5EPK38DA8jHwEHkE+Co8ifw2PIR+D
x/MvwOPwBPIJg0/Ck8in4Gnk0/BM/nl4xuABOIB8Fp5FPgfPIX8Dz+dxM/gC/Bb5W4O/g98hX4Tf
55+D38NLyJfgZeTLBl+BV5B/gD/kn4X/goPIgwZfhdeQrxn8I/wxfwBehzeQb8CbyDfhT8g/GXwL
3so/A2/D28j/hj8j/2zwHXgHeQgO5Z+Gd+Fd5HvwPvJ9+AvyL/BX5F+RT8Hf4G/ID+AD5N/hQ+SH
8A/kP5BPwkfwEfKf8E/kx/AJ8hP4NP8EfAqHkYchh8wZzEMeCTiPArNXNIvAMBxnAjABy5qA4RjW
hAYEJpYc82bBJAgmXhA4DnhREE0ipgq4NxmOggeeGIO/DM+I5JjFH97E81zB3qbwnORBafr/zFa0
oh2/ZpbMKFeWE4geiHxZjuU+1y3HCYLAm4lK+aO6RdWKAqaYpM90ixlR4yYTw5gYydA7z5p4VPxX
vkb7lXZsumWYY21o0Yp2HBl57YPoVgRcUX2VbkVRRH8riKIJPe1n/lYgHlgSRnVL8vKjumWP6JZD
3RKvXLhuC89Z1G3RvvYmKzLqluPN5P1l9K6GbtHHCkAgGLo1yUS3gkkUUbcms2gWUMioXeWIbkle
dMasIBi6Ne4zcYY/NhVckcJzkjfJi7ot2tfaFEVBuXKcoVueR+2ir/xct5iCulVEolvcOAyJJUO3
mCwqomiUcVTjX9ItFiKZhKJui1a0f4NZVAvqluclXOp+plsiSiAQ8YIkCRaz2SyJgmRG3SIl3NDr
mlXzqG5FMEJndM0MJzCKcZ+A8TTeIhRckcJzkgdl2WNtaNGKdhyZqqpEtyaZvJNuMpmJbk0oUzMQ
mE0mWZYFFWUriaIs4fpXUCRZlFG30me6NaPGiTMmuhUZVTSP6pb4Y7HgihSuWwwNirot2tfbrDYr
eRfHpOBS19Atb+K/pFsMpEUrOl3ZLMoyrldFRVbMCjpcWbJJklEGySuYzbwZ/bHIqeQ+XsR18DHp
tvCcRd0W7WtvNpsNdWsSLES3uCQF9JTC539hJwgWi0W0odNFqSoKxr2iRUHdyrJZlm2y2ShDAoyi
JTOG1Bxv5mwYSEsm0SSZMbz+d+iWTBZc4W8bFa1ox5/Z7XZDtyqAYujWJJi+pFsMpM12lK0FdWhB
3ZpVPLQosqTIdnnU35K8oiQZupU4u3Ef6lZSMbngipgLzlnUbdG+9uZwOMg7taIVwILLVIyVRRMG
xLIMBLIoWq1WswODZVWWVIsggmS1qJKqKLJFcSiyUYYMGEXLEi6FeZPE28l9gtkkSxheF67GwnOS
By3qtmhfa9M0DXUrEN2qqFvF0K1C3h0iUAzdShoGy6oiW1WiW5tqla0Wi6xaNMuobhUwwmaTrPAm
mUc1o97NAuaXjzjkQqzwnLgUL+q2aF9vczqdRLfkX71UMJsxVjYL5s91azbjAlhyomytqEOrYAbZ
brUpNtWiqBanRTHKIHklRTEphm41Q+8S6tb279PtMfwBZdGKdvyZy+XCZa1otpNPwzCbLYZu0b1a
gMBiNuMCWHbhItdmUWw2M+rWYehWtVhVl2oxyrCAseQVLBZeUHhUs8UiSqJFsStHAulCrPCc5EGL
ui3a19rcbjfRreQAsKFuVUO3KnlXl0A1m3EBrLgxWLarip3oVnHY7Ba71WqxWd3WUd2qqHHZYhEs
Ki9YeFQz6l0WVYvDYilcjUrBOVUo6rZoX3PzeDyGbjWiW0nCNa4kSp/rVpJwAax4rFabA3VoN0ug
aHaHxWGzqnarx6oaZaBuVQybBdXQrdvQuyKS9a+lcDUWdVu0ohVsfr8f3awkuwA0kGX0ubJZtpF3
dQlwhYqBtOq3OxxOm9WpSTKobs1pdTrsNs3ud4x+AIoNrDZ0v7gUNolWk89mxfssks3qsh5xyIWY
WnBO8qDH8A8LRSva8WeBQIDoVvEAOEFR7CApkmIn7+oS4AoVHbI1gE7XZbe5XIoCVo/LbXNrmt2p
BTS7UYYdbHYVg2i7XTTbxBJyn6xKdpvHZitcjdaCc5IHPYY/fC5a0Y4/03Udw2NF9eFSF0Nj9Lmq
rGrk3SECTVV9Pp9NR6fr1exej6KC3e/xOrwul+Z26S7NKEMDh2bTHBhS4zpZDGkOTbPYFM3hczgK
/0SywnOSBz2GP6AsWtGOPwuHwxgeK6ofl7qoW6ehWyd5d4jAqaoYSNvDbrfb63T4vES3JV6f5nO7
NY877B7VrRM0p82pyU4nrpNF3ak5nahbp+bXtMLVaC84pxOKui3a19xisRiGx6otiEtdXNJ6QLEp
Ng95tYoAI91gMKjFvF5fwO0MlFht4AyVBFwBn9ft98a8bqMMD7jcDrdLcbvNistc6na53VaH6nYF
XS5HwRXRCs6JIT2G9sfa0KIV7TiyRCKBbtbmiJDPiXM4/KA6VIefvFpF4Hc4IpGIO4GrYN3vCet2
B7ijobA3HAj4QoFEwGeU4Qevz+Xzqj6/bPHKFX6vz2d32fzeiNfrKrgi7oJzYmgAUuF/plG0oh1/
Vl1dDVar3RnHkBlD4wDYMOQNkFerCAJOZzwe91aHdD0a8JVG7U7wlUVKS0r1UEkkVKWXGGUEoCTg
CfitgYBs9ctVgZJAQPPYA/643+8puCLegnMGcJMLf2O4aEU7/qyurg7sds1dAVAKbrcOdrfdrZNX
qwh0t7uiosJfF4lEy/RAWdzphpJErCxYFo2EYpHaSMgoQ4dgyBcK2kM6xttqrR4MhZw+TQ9WBIO+
giviLzinDuTjdY6xnUUr2vFkjY2NGB47vZUAZeD1RkDzal6MjSNAgJFuZWVloDEWiycioUSF2wvB
6vJkOBmPhctj6VjYKCMCeqQkomNIrTp0NR0JY2hd4ozolfoRh1yIBQrOiSE9hvbH2tCiFe04spaW
FtA0tz+FS13w+WLg9Dl9MfJqFUHM50ulUnpLeXlFVSxcVenxgV6brI5Wl5eXJsqby0uNMmIQLQ2W
RrXSmKpF1DGxaGmpN+iORVKRSLDgiugF54zhZrUeWzOLVrTjytrb28Hj8YWaAGohGEyCJ+gJJtGA
IBkMNjU1xdqrq1MNibKGukAQYmPq0uXpVHVFbfWEauPrQiEJ5YlootyTSNjd5fbxiYpEIhD1Jcqb
ysujBVckVnDOJJB/9z/WhhataMeRdXd3o5sNRsYBNGFoXAP+iD9SgwYENZHIuHHjKrrr6xtaUsmW
MaEIJDJjxlaNbaivbqqfUl9tlFEDVamyVBW6Zqev0tmVqkYXXRZMVY6rrCwruCIVBeesAfJvw8fY
zqIV7XiyWbNmQSAQjncAtEI8noZgPBhPowFBOh7v6OiomtXc3JJtqMm2ReJQPbFtfN34lub6cc0z
m+uNMtJQ15BsqA00pD2BWs+MdF1DQzQZTtd21NZWFlyRqoJzpoH8++GxNrRoRTuObMGCBaDrpYlu
DJkhkWiBcCKcaCGrXoKWRAIdct2CTCY7qSU9qbMsAfUndE5umpzNNLdn5meajTJaoKm5prlJb27x
6I2euS1jmpvLakpbGrsbG2sKrkhdwTlbcPMW/rZR0Yp2/Nng4CBEo2XVMwG6oKoqC6VVpVVZNCDI
VlXNnDmzabCjc+K0TPMJ3YkqGNPb3dPaM7GjravjpM42o4wstLY1tLVG2zL+yFj/osy4trZkQ1lm
7MyxY9MFV6Sp4JxZIP/GdIztLFrRjjOjj3zLuAYMOaJ8uPGff/U4Rb6z8l+/thIvMizHk49PlWQF
VKvN7tCcLvB4ff6SQDCkhyPR0li8rLwikaysglRNbV19Q7qxaUxzy9hWo4QJgJPBpMldU7qnTjuh
Z/qMmbN6Z8/5Rt/cefMX9Bde982FZBr9TpIduN2+p/CigYUtyCBYsQALRCEOGG3AFJgLC2EdXAu/
ZL6jO3SvHsnngbweHodyqMQofipeX/TZdQ+5nv/jv/yclD/p02sPXnPwRwdP/r+/4z3rnN3b1FiX
qq6qjMdCmsNuU2SOpSv1ESbWGe2MLhraqncO6VujHQMdVZXdM/s6O/zh8NyqSh2TO/QRakDvHJm4
ZsiztZNkGLEnR+hYJ9mWjmQvGMCDaEc4HMYrjs+v7M3vv/ALl/QlI9lFI3CBvqNy/9YL91ph8UBS
HowOLlrQN8IswsfaAViZod4+UieyDQzpIyzebcCPKUeqSK4NDSCjHXjXV6Zjstjetzm83z9ix33n
iC05MglzTFr3up/Z2ulZopPTrVs36yPXzuj74tUw4dy5cz1f6oaJ0YkDW7dOjOoTtw5sXbQ3v3Fx
VLdGt+7o7t463Dmgj8D0vhEK0++8wD8y8cK5I9aBIaoFm0zaMXFmX8YftmEp4TBp7wV7s7AYT0Y2
zugbPddhsX8nZFPJuSP0ALmy/+gV52xyZePRK5/dPhA1+rq9j/HTWHD3rGj3jHl9eufWgSMVPpIy
ZvRsBw0TdkSpLTN2ZKkts+b17bPiaNvS27eTpuj2gQlzd5Titb59Og4UI5UmqSSRnOjkBLop7I6d
tGDk9+/LAmw0rrJGgnF+0l4KjDThaBoFJ+2lR9OsR9NoTGNH07JGGjFsDN3e2/fFWuNG6g6wD3rz
+7PBnRV1jdad+s7szuk7h3du3HntzpGdz+w8uNO8f+f7O2kca9nh292exlAHpc4JzaF7Zi+cTa/o
pX7ce1svPWOWm505y8XOmulkp3TNZCd2NbGTuurYybh1pZvZ1kwdOy4zjm3LhNn2TICdkJnJjsct
i1smXcfW1Q+y9ekGNt3Qyzakg+wzDQcb3m9g9ubf3bU7Nrlxb/7grt3WKO7fzSq7RbVxt28yu2bX
ebuwWu/v2mXk+Dib3yWWNu7SJrPnb3Gww6cPr6XVq//rGjr7I5e3MXu1y9+Y/aEbjy5z+xvP2+QI
qeeqm9Rt6kXq9tC5oW2hi1LbNm7auOWii7dv2r55+xY1+13R2qieETqDzq4U5UZ1GaU/SumPUJmH
33uY1h/KPkTDYgoWWxfT2UXXLqLV+VSVZmMrtRib1JrZhOZgKzQnG9KCbFhvZ3Wtlf21r5P1+Sex
fl8r69PqWCfmc2B17ZqPteE2rFFZbXx7o2pJhICnlAe6Q/L93SHz/u6QiBt3d3eIvac7xOzrDtF3
doeoPd0huKM79MD9idD+exOhe7Jz7g6H7twXDt2xJxy6/4EHlXv336fcfc+v5H133iXvuWOvbL17
4910dt/GfbS6J7OnZ8+GPay6J4WHK/Dw3j1P78nvEcxiEysrNM5dDE1TQE/nqL1Unhqxd0N374QR
B4X7WRN2iHXJ7pHBmRM2fe97gZHLcOSObAzM3StgHtTpCLVt7ojQPevI4ejbJ6tWr1qV/AobYTpH
+M6hRSN8tGMVObGQEwvOFpbOEZUcq9GOJDWidQ6NaHj0/xSy6qglVx25OPpABuCbX/WYpC6rkckk
H+Q17n3uAHsW28+8Qv7jNf+n/Ku5tbnB3Fzm++R7rOEyuBkl8jA89dlkfzfcb+zXwE7YD49/yRGc
Dd+HG+EJ+D2891na5XAN3AIjX8q33Ui9AX4Ot8IuuBMewLQtcDGm/hR+8YV8K9B/XgRXoa96jjr6
dxgP0Bo1WoO3QaYPUKuobeBDv9YBC2AVfAfOw3o9Sk3FtHGYNh1Tz4C1cAmm7oNHv8J5jYM50A9L
YTk64H1wn5GWwNReGMRUkjZqK9Gnng/XwU1wF9ZrHdbsYrjyK8o7mw7TYVgNb+Cdj1E/oB/GFt0E
m3iNfLIsd4D0Kttv9C3kXwXIDeb/jhHAYvoD+nr6YriNXor+mSYu10S+SpTBnXYHT7NAttSTrzxp
oLYmbAvbYggKc328kYNPyB42ko+1pKkogsHHIncvynoYHM2m2ZygihT0s7Is07PZJNPP7c2/sttq
pWfjwTu7VdU4+Hi3ohgHv9stSaOXsmZRpGerXIijuVS/MYZeP5x8vR8yh+pTmdoaiokyjmi6nmZ8
N5e88MQT3IFPfs02fZx6DmfjnzEHGJbXjJrEs06a5xkTpYpZkWYqgUzhbKUpdai+P3UIi2utT7WO
Fkd+GDZ5bvJnuPHa4XvodrKROA/HCvdrbJsf+3BHdmU2PEdczQ2L6x3rXevd632o4WDApTqpU52U
MyirVocmaSYhVOIGDzXkoTxBjqZ8vJdf7NUWD0uUxNgkm5dhFfBTfr/i9lEB1nq7I0hzIivfrppU
h4eVQKM0RpV6JFoSINOf6be7m1OHRjcqVZ8yzlOp/tdTr9fWbN6Pdrh/Jdnt32z94hnVT4WZsDPM
RB3Glg4bWz1jbBxe436d27WAasj9fOjsodxfCV6gpi3IPUF9Y8nZSygLQSKXzr17ImVnbsht2Zyb
T/2UbJuptZupG3PzyLYpdy7296r8q7yDex8k8EAnvJpdIapetVWucdYE0lVt43p8kwI9HWeWSEtj
A5n13BphvbomsC423DacETmBT/BNmuAKaAmtyZmpkBOBeFONUGPOCllzlzxe6ylpD0zUp4bHV41v
nSHMVebHlnCnCKepA4FgRnYF9KiXIT5zrN3dxNzsVSrFNi6apl2ZqDkoVCptTAq0MbyWysidDj2Q
GsP64hCkgsFOTfFRPp/DGV810fohjq5+stmwd232Zuzt1CE8hEzmUAb3h5IpTMTf2pr+fuzZhng0
wjs1l7ux0UHxvIknJ/V1jZRT401UtIzno5HSdENjU2NjUzw+elBf5yJXMTeFqY3xNONZ2bdgdc85
i0++PxcJtYVKSm/5Uf8d1Gl1rdS6D99Y9f6GZ3KHGqLRofTyRel03XWLfvmCJ6CvOZFaZbFQNMXe
tHDZ+rndq3uimw8D9axamyhb3nnJrvn0rQMD7y/LbT+4beXfHlpwXm1qVmjyJSvaz6yrab3tvMoV
lbXz9Nxl5QMNY7bWoCRuzw0yKmrGCXOy7SIlmryU11TOlHM91GRmMtdjWkgtNK2gVpg2UGvptfwG
k91EUfI6lhLI3aDK6MJmq7Ih2hC7xWX94FAyif3YihIjcu2nonHaZrU31TtJN9FOze52udyM+saO
Bx/c8caMSzOt3V1trVdOyw0+Th2kqvDn4OPmrns3rM/97oZbcq9vXP9IJ1lhXZobpA8Z9VyabeYZ
3uFknI44FWfijrhzEpVlso5JzunMdMcAM+A4E9bQw8ywY43mtFOs/E2g7BmWYllpb/6D3aTC5CCr
kkpLIZDJbASXuK0fJv+17lbaFE2TJ8uebqDL4vGydL3LTh/Cik+7amxb15RxmUtnYEPo1txzOf1x
c+cj6zdSJbfcQJWv33Bvl/nxnI41v4lew67Emttge1bscVC2rGhtEsiI7cOD+fR8rlfqtZxGn8YN
SoOW9fR6bpW0yiJTvGqWLIKNo3mZ72GnszRrVmVsDaU6Qg4abErWSlkFk9yDz5rVQuMKVOKVcnFY
puRUfz1OFnU4VeBAJsAG1fdjy+rJ3FGfqsdRTCWT/ZQp5og6uLIqqolj6pmYm2NXZnOX8WdzuR+O
p76dO2c8tZQ/20Sdls2dy3xr+fO5y6mhF5Y//fTy56lTc1f8ZvmTo8/MNjqDHpOBdDbuoxJUkk5D
M90Jk7FX59KD6J4eYmSaZuaw6I1oH4bkWJEUWD+oS5FOFqmog87k3rzkVipweCV9ESnzCrqWEek3
sUw9q1ETVAzuVa4HeriFsJB8mjJN5kFAxWIBOKkx4uHt9DBdezu59zDiHaM++h56DiVAFbU3/1bW
TJ7lFJVB5aBfOYT+BP1a1FZPvfPee5ibyr+We4ZZYHiPxmyMoYCjXFSMGgNd0EHNoU6lvkWdR5kp
O82ksDZk7JNKQCbVj3XYfKh/835sCMUsOFz/S/oxXvvoblMH8SDn519lL+Lew5kxCpuzkUaqWWqQ
x9rHehqCnVSX1CF327s9HUHZ2SXS4S7GrOLI3EOcphoGDLkNTwlktPqJhwQPuQTXxNRYKEb7De/q
D/OYMesgOXkrGdO8TPLyl5fiiE7imO4/ssc2k1aTYR3WiSjDuh2nonRDHIc2zmejsxjKEycy9qJP
ch/lPvjHx5RIyf/I/TPq9ZZGz1x44vrSiNdVGj5z8MSz6LdzK3LnU2dRW6nvUetzGz69fcZLV15+
8IRpJ5zQM+XdbVc/O+uEmSfgk0G58Hlv5V4AFbZk09xEnpcZCzOZElRbyEZzdEilVFW2GI2xKLLM
z7bodIZZwQwzDCOTmAHn94NZiTSQcZEGMqRDAqSRTJDcxfAkjmCsisIjSQlM6mgEilJIJokWUvWo
gsN1mfoUeeZx1NjC6Tpjgq63hdnWT39PNeYey2yPVafZq6iay5k3tzg177TxH9+Pz/V12IKL0b/p
6NtmTA8NhGiO4W0uxmkrtY3lxihpSyaQCTaHurnJSqelJ9AT7AotZPrZfm6+OMe20Huiv79kYWBh
cCkzyJ9sW+xcERymV9s2+DaUbAjGsDVv7SaVpsk4zZAjUK1qlZAqqVGzKq9mjfGQlbF1qipNcdB0
aAolhGgh7DLmLpcx/bpY0iEu0jVecoPLRUpyufRrImokFKGxI68IWz/EniAw+uaQvdnoEnR82FG1
NWRK6MeuITMeGRZkTJD5r54soQzPhb9h9uJPrUuem79/2xXnz//NyeZJh1a8QbHJRNmS7tNeP4kJ
H5i3e+6dL21YfU52wrPRllfumX3phLa1XUse6iVzIarhLOzHcbA3u02SuJRPcqYqpHiqorVVSmu1
kYbUFKlTa4+0p+ZQc7m50uzUUumU1NLWtdKa1Or0+lZfQ0tHCz22BfuXqrJV0VVVFVNCYi2tKiGF
VhTbFNEcDTcZQ6mJJYOiiSe90BSsdoWZ6mALLrkYnzFkZGOYXJtRM6EMLV/ZZn2z3/pmMmlzN1sP
YXhFeseIOfsz9maySx3GaZSIx3XEi0cjhjsgYmn6TEQYmdZ9QVCjnUckRe5xulyspaZtSnv342ee
9f40dfabp2W2VVZX1VdVbZwyb+Llt1dXJBe3LXxhIenTZTe2T55y27dqzqKfTH731FNuzkxsHxs9
MGZKoqJy6YzpS4Ih940b1jXO8Pm0jrYD0bHllTVb5p+1z2MR6rGf78J+3oRxawJ+mB1nFnxCUhgn
pG3jXN1Ch22e0FuxVFgnyIGAr4tMJDjdxcJTYnyQVs0hM202W6bwZj2i9wSoAAnJq8nACrhItwUs
pFMDhsYCWhj0gAjGBfhxpVoZqqTFq5KjPWlrJh1pKPBQ6vOeTPUfJtN+P/W/9yH2mw3jVtvRrmM3
TZ0w+ZFz1r12gmXmy0snbWqorEqnGn6woO8nY5mNh8cn54XP3DN1eh/14tCvxk/sri99rqGrvC65
tmfaUj0e8sh0/rbcapataGi69ch8fBN3CCLQBD/IjuEVl9Icq6+tb+qKTahtb1pIzVGm69PDJ4e/
WWvxMRVdAYfDPSXAqHQaJ2dfZcoeDYNdxBn53c+nZsmYmo1BB6S/VNJHcHWz2hxqplNhkUzpJLN4
+RgSYxjjDEca6R/0zWRWtjdjr2DA2Wz0DJBuidPpBntTYynpA2eUdAuYjvaI6Stn7Jtyz7+4fHfn
nP7Z/X2Ua9/Y6RXmkpVjf5sHZ+9PTlt48dS+uY83/Q/r3gIfRXX2PefMffa+2fsm2Ww2982yIdkl
BBJ2CIEkBEy4BBJgSQIJlwASINx5jVYFvFtsxUu9a6v2eytFVND8qhVL0dZW661qixWRKgpatZRC
dvKdc2ZmCWBbv/f9MLueTWZn5jzn/zzP//k/ZxKj+mpad02HcGLVqBWJ7/8YfPSR8mHdpFnA/stD
oHzjmgHJ9LzFr3z9cUU8FK959qbklkiOo6jEVRy495l4afHPEbZQHcr8EGGLo5rlchFIMA80gCbY
BjfTPEqbIAelelwSTmVpKFiEgLAV0jQFIWPBSZMhFUwVmjgmWSlbFeYAO6wnd+B6BSVQFJeZH6YW
vg1fHdpDn2O+Omdmc59AOXnL8BHmR+zXlJcqoiqBcIAqQFTOhIyav18b5OmDkD7IxYuzAY8i4Ziz
IjdWGKuoc07MrSucXNHinO+d558XmJ3bEW4v7Rg9u2J2ZaewyLzIvsjbGeos3GDeYN9aut2excHH
Cn4chQUuKcrQWfVWGG9AQMihMkBGBhWVTMVBylWQoznBPeqa5wRNBBd40U2m8iC3eyypMPDaH1M9
A73ZKqJrTpKcjFhZctLsNjm7vfS6UlhcWk7Ho8XRMaHJoTmh7tCdBZwvJ0QXZOHahBQoyXaEExLB
CVhIoRHHZUaeFqlRpKHTJYqLVCkEMoV6ncL8SHnj2FfKh7devWkdcLz1AZCu2HLjD04+cuUVD8yY
mX9D7eJpgRkbon3JeauevWXXE+C+Xw5TZw9ue3k8J9+x9tG/vP1Iz8FKrnoPbF4xsGlJw/Ji+7iM
2ptT6xasHusqyB39aO+OPbcjX1sz/BHhPtjXrpGrBMbLFDPV+dXh+Khp+dPCk0a1MR3upGemvw9s
zbfYssobHcWNDi5Li0Bxm4icTfQRHwsRb7Oq9Ee1cmnQR+iOj8G/9d2OnUvzLuJbVSS5RUnU0V0L
8hxzPujYK9UQhE1HEdeyp10r7VcoMDG3tM+br5w6EFuQJ2X1TvzzOUfy4a4FP2xqawelf1y5f3Lr
glfksdGViVt/MkaOrKy97P4pgKZrDyov9q3dZjAihwLip2PL8mI1g1cfA9mTJs1Szj1892AsUrjv
oY5NkYCzpMhZTEEwD7lNI5Mk+kW+7AJzIMvNYQWeinCAwjNFXAqT1+pUtUblACKwNvSCjV+gf7QM
ss49hMUrSB1HrHyXdq5pcqXESpyP9XElbJiLM1XcZKaBa2XauW6mn/kVbyGX4vg5AsclmGZUajBU
RL0YMqBO1skFk/iSGZiyo0s2YtaOrzr0gs7cFWo6eyXzGxQdOvatY0EpWryjcoHkqaSz8VuAiqLQ
gCOBLIAyQRYgw6KoIIMWwssrcEBMYmZfkUS5Y3RZ06w22cAys2lIc5hA7LCm0A/7QjtI5oM4cALA
XnnuCuZ7Q2vpm6dDsA2Cfcp6ZT22wN9BL7ub/hmxQFzOYWdzYDaHKwlZBGVYFEJXjlJYxUeXB+Ti
yfTVT0a10gKRxCC7+9xC5kH8os33pwbvx5zWiOZ5M5ln175tNCgFeJ5FaIosnicbAFEAWQs6rz5P
Gs8zCsqADOh/OVOamc2yHJwNLpgpQDNFP+zN566gbx5ay3wPXpYa3gduADfsSw2j+0c3RJ9EfpaJ
+OlyuR6zvTwHHfc0w2a6ma3zLGBne5Yzy63dnn5Pf6ZR6EMVI+fLdrnsMR8UAq3ZQk44EOACA+j3
FqfoxlUr5VYD9UkiixAqhJ0JSyNJkr+1DM47Q7ZL6aILICJEn5xSNXbXzCcn7i4bJ9+5eeUvx0pT
3ul855/K+t/+llm36M7xVd3RD8Ho/LZIbPWcNavrQr/1h18/exQreXuGs/nL0IxqqWbqbflBDloY
AyuJFr8505KwyC4YYDLZgD+Q6ch1FAYSgYn5sJQpZaP+aGZebk5hNBGdWC/XNcxpyJJYtrC98XKx
x7TctyzYU7gksWRiv2urv6+wv6p/vMXO2gR7/UyzQ3b6Kx0MM32WEImUzDALNaOzZ4yugZYIiLC2
SfaIY6o9YQAGy4ycGdBT7DBUWpCxB3A3Na+4ckWLKiAh45xMIoNFK1LlyG9Q0U0yPPpTFL1eDaN3
XJFr5oN8kOhEKPjYcfCJV9gqsB1hYUFeKJfRxRIGxyAnEZRGkAIGxSpg0yMVOoS/bEaT0uCfurPt
0ZdP/7Sxb+J9X5eE57e1KUOP3K/8o6Nz1bKOxUC6Z84zs7sebX9WeXHtuiu39/eDCU+9BGK9vWtS
tyS6q67a1b910na4+wZlaEV/tawc+wiYg8GyoaebPmx/GBg7O5f2L1qkfHHXI8oXXT1LXZ6bnZaB
tetA7cEDILF+/fZtfX3KrxQZclnefT9+6CcTsBf6KIpdiNgCT0nUS08i12P3D58h1Q6nD3iSpvFo
KjeZh6IoCXAH8hwH+pIo0TsYwDiQV2zj1vGQjkkyrgglGXOsMkmW+iRaEiWOBltYwAoWI+B4kWaN
VB5VheAzj+ql+tF5qMuN6E8SG2bHsNPZVraH3crybLcBcVVUDhFNFS1XsjqBBROURXCkQ+6XJKoq
/p+A+AnuciSDITpII56SgULPwjd2pbbtehlmA2Gbck45C+5TutjXhzbB91P5CBqH0dzDaO5OdDMV
wCTbWaPTWGhshXOcA17ObiuNZWMZyIFTW3Y2nxUT6EiMF1xOe6klzSstOaT62z/8lZyJ52wpwFUu
/i2uBvl8J0VKZBRnj+uMFFeTZPAV0dfR4Ng+/CX8J5lUhdSauCUux2F2qYM346+jNRgiGjwavKcS
F17AKYfHTBefDg1OkNOhwd/I6fDgabKAK2NEYSD/UuVJ/QNKumqdicKIynPQ55NYQ9WjRwjF15Hl
EdCqKPRbHFNU0kIOwh/Z8Oz62S/fnfoSHHjowakzp66ct/tnypN5RdHtiz8HVPLyaLRwYEx92XWL
lJcB970fx8fGwCurH6+sHcu+7ikI71jY+8OIEPgNZMZMdftNysyM7OyO1F3zevO9ltTb/rzCbpy/
1g1/zE5hP0eV02p5DgtMIudwAb/ocOY7xzgnOeYLbVKbeb51flEn3eXogxssfY4Ml8sXs8OSkoIY
J7moNagQArgWipYmSleXsjlOowNb1piJ7WlcFlZpCrJStdrUQC9skXxOrYjyvoX6X0D0KyvYKZXt
DTW3zHlQ+ceizpXLFnUA08Obvthl2frV9Wueqp88vXXSlOeW3XJ2lXmlp8Sd4Z/f1QHyX9wPcru7
loxr/GzpwsbpTR/ffs/R+qn1ixYhH8U43YtwaqayqEE5VGVvtC+Hy0yMCwHSjQC5gQIWJyURmHGk
1kHJLl3+7CPMBKNDQ903spegrT9gCUQDcqAzwLj//8As+zzMTp5HWVInQyq/U0HFnOdyiLCo8Nn7
89uWnHtV2Qn63wOg/Y7Hf79lc9uh65999pa32levhn/9jfL0/ATCSqKyQ3np7Se+nFxeeO7qkqr6
TzAukI2Ye5CNDNStz4hxirNykMPOm0dkNw6wcUhLcSAwlAAEap3JYgKc6ABk1kCfNUjPGpBZA33W
QJ81GnxKZo0HZNZgpfEi56pOVqe9aQ3Rski5TF7MPUNh+q2hv9EW/GJf36Ms25N6R7v/AXT/InX3
XnSv+Nad+EYg5EFcoHmBopsNuFDbP/ym7CPr122wGBCJAfgu2P/RAv5FX8DPtQWURkwljObyTZik
SS0yYMZFpoH8nxlIWeCO1OZD9DNsUFmwJ1WBbp7450fsg8g/86hX5PE84jGcOYvLMAfNcXMjmGie
Ye7hegyLzf3m/kxLblwOgVDISFut7pgRZsVoaYMIcq25ojW4f1iRM/CNB1dSDEG2VUP2aR3Zxy5B
9lk9jJ6TQySMri+wFMgF0OcU7fjbInFx0YiPEpflq7JrGqjhk2GU/qNRFa8VmEupCjZyfUbzeyuF
oYudnlQhlA3/YkwlYaEPblE+2PEz5ciSpX3gAbByAIh32gMbqiY/sfqs8mdELLnO5xuUNXDW5WNn
dXZ2gdBB0APuqWn8zHOZL1CsPK+cUj5Qni/IBqt+puKBHU/wfHQvHSftCBeZt2AVoCCwEqrlWUGE
DlTJvqCnkbP7tFTzzT7NWMdVDFCCbio5jxxrJxazEHNlEFNtQi4hm1pMtEA7EAf4g94MHtJbvxqc
WHIqVkcRq+OKDPD58IDAib3EM8LnP1GJ6kQ1MvCasKrzY1BVoPcKdvyhlPfQIfjXQ/DdVCH7emo/
bED2uA6RlbeIPXrkkMiUc7RElwPBtEoSDPMkB83CeZoWTcR1ev/wEYITWscJGijkRvFemqeJHr0q
fX/flFtT6HWcqK2pcgz0IKJ7oXjQiau3t1L7Dh6E0w4evIN54I47znWg+ykd/gyeINxhjezoBdsA
tFc4aZ43xGgxI8PuICFYW42zOmJP6Yg9pSP2PRyL8XqQlYBkJTa6LW7A9biwTpeGJm5lpNQaD+fm
i4Q5jD944ouXy+4fYyjelFiwyue3KL+CAFz90ps24wFzdklhUf80uudeLdJsQHfOUuufhjSDYiLh
HSoKKN7CIzr3v4qLJ7S4yI3MBraKKOlvkHCIBf0NQzMPwU/Y189+oKH9NLonI2iU58+RwFg4lh0j
rYad9Gq2UxqAffQA2ycZWsU50jwD3U330+sRiZQgLXKQggyhnIyMb40hxBOFDKaOmc2gf7xBpAGK
gZIBYQRvjjKRsOqgsnVfkaer+qCqYJAVksjy+MipPGRpjKqTmC3mgLnFjAgs8QKiKbIMQXsGb/1/
j8An9Ah8SovAphFGw9rsyI823O9W3QZz3Umz2/bFmF4GJtvRcG83A5LtiCfjgLWWSq5FTgVCAMdq
AILs6UPKog1KzwFgBjeBK0EGSw/tppefTSE6fJCu0TIoOxZnIBCWZSMf4GP8ZH4G38Wv4fkNHLAA
yAWAk4txddwsbgXo5AZAH2cwAoaD80ArhxOVgGg+I3AA8rh20Cb9jT7ps+oUM0h8ujhQHZUnjwhU
angqIPYn0RqvCLY/SnmyAUJyFCTWh6SBADMYYn1Gtz6Ttj5DDmZ06zO69RmVf3PkT+TWmJH57yLr
p4girNsfG3ntmmQSlxuqiVHgGvv31IQDoAJec4CNncUbX2TmBcTe1g1/yL7Hfkm5qRD1CzmXoRhk
NYPdTbk5r9FrnwvmsrP4DkObqc3WkTHLbXXibqEHT0YkU9ogbnZCf8wJgzFR8qD5kXv1OGl9qjQu
LbQQd1QPcV/KMRLj1uVb8gFuIiTy6WwC1GynhSRDC2nVWThSvpC/WJapHUnckkzqI5IMk1gBQfzN
ZXeqFO5CFpxhpdRcWFFOsdnzuxa3Lzj3wD3K8Lx5XZ0L2gB71/3D9crQhx8pKSAcOQJ4tqBbObJ/
v/Lnrp4lyxYvBjkHngbBpYuWLU91gVwwHhWpR5T3UZFQSansl7kd4dJKBag/yWXjHDVZTY6mrBbz
bEuPhffGKN7KQ54XPTGJFgVLMBCENmcOVUbJVB/FjMTYGdlA0KV3Ar7U8+YnOm84oZVfq4OWYCII
vbxDJJFQ1G0tpmElEliJOqxEHVaifjo0+Jgslbgy58I8+I3W+TypU6vkyRElVwjjaWQbQefHzO2T
J0z/w/2HDoEfbH+2oTX5uzGVZVsXvvSTTbejwoqxLH5swvTpKZQjI2VVj++YvjYv4E/9dzha1osx
qGxkzyAM5lOjqV/J9Rh/jIfJwvhzelxZCwztpnbbAoS+ud65Wf051tZAT2B9Vn+Eyc8PxmlDcSyb
EwkOnTCKUJidwVEV6wqQUWQznmGB00+JXBZt8etQ9OtQ9GMoFmHD+NdVWCqApSJQkaigSy8EoQa/
co2RqR0YFO7KrSfDx6NE3koQ9SahdaeSQFWGLy3IEEStkNcKMXokMM9Ur6/52RuiJ+K8EJrt87s+
GGS6ryle4/F/PhKmym0W0/N7GfoCiHZh6CpfKNc3rb3CK9H3XQRYtVq7Q8PrOXmWALJABIwDVVmT
LQ2Ohqx5YI6l3bEaLIedUo/hCrDeYIPgSXS0lffFIMle+J1rlSGAkPXECNHDsJaDtM2J6hYTRnIW
tpspE5vYRCKkyYNtaDJZsTpIkEww7aVF0kh1UKz5PzG6NJFLU7u/aUTuPIDLUV0QDSerqqJpCFer
GCZ6AmkWbUl5XsB9ahBMQxnrBxkXlXt3KMOKWfn0EHhgx76GGfMfvLkrEgtvaPn08MIbR0fCsCW1
h309FKm4e+MD71aCh+TFuVnu1O+CkZJVOFttH/6YhajOKEMrQ0W1hBLRM8sonNZ34ZGHzNpN3l3k
3UloooOUy4gbBKiQX3AEioUiT14gL1oljLGOzYgHxpRMFSZbGzMmB6YW1pW0Ifi2BlojK7xL/D2B
JeHO6FZXX6Avp7+kP7LdHhJls7VSwG+Ijth8RUwWFwzmx0ijJMZJwSKnj+Dch53BiG3rszmpoE+k
dH/B0Ui2kLjUX24p7yuHYu9oveWtdWq1Nq1amrircEPK2WabW7TMtrRos21D0XW27UW7bXcWSbj9
hNZGDzl6KzcPM0Ym3f8u1BtSuJzJO9+LcrlYOKOx5a3bH1CGrzWvAUXf2/9q1+KmJxYdeh5Uf30P
YqbmVuWz79/3y87N8uczf/woeGzu4+PlhurxZxYuuX7d4oU+h89R8puHnvuiuvREQ8c1y5K9meYi
Z+le7SEd5hRRG9fJXsDEOZoWLGJAbBZpaj6AhFs6UD4+LUskRc9vZrEgeUI2EOwKGnBP7NMQ+9Ul
iB0mkiWrbS9JfhNWN6dqpB7jMR5kTqU+P5T6HN1J8OwHbHAPvrO9KEsXozvLon4r+0P2kKeGrhGn
0dPEjRkb3UKmiXaihfQ7AiOqrTN6Xjkh2wh3IZxQ6zRiPTCLHCiN4C8bApZAICAHaIvDuH/4T+q0
jGRjiDFdrBnJeYy40sWnMuqJykj6puhkRnUPEhqs+FbFRd0akai+oI2PVhvx7hFNM/SRLa6fMf13
1934Wv2M+kPBwtLdvStujxQGD8E5D/6tZdqUqQ0zP3mM3jq0dfONVRNrJ9ZW3baKvh7ZSteMOepG
eUk9aEBhimF5bi63naM5B7ImyzNzme0MzThoSAugjrSf14FtkKNYuJ4GNA2FydRUvK+eZqg8apym
A3PU5YJFAOjHQIfpON1K99BbaY7u5rEOjOaXtJG9ciQXpCVg/CaQ9nQQVGDVN3VUOZM6+iZ4A7yB
6osoeh1ls9F9L0DlzU24yqBelh+vp5fSm2naBAyQYSDLCkaDG3hpD+sVvIZiulgoNoyHVXQ5ExOq
xQppnKEJ1jF1wjRxktRkaAXzEDrnsXP5drFV6gG9sIfpZXvFHlyrMOuEbeJaaZthlNGBrso7OBbh
HNCkPhHJO0VTIkRwRsGZgxyyxngqxjVRddwWaj3HUWtRkZEwd5gHzAy31GQ9hcIAnjUWwck+IKA2
nwDin7gnj37QvNEPf5PyXx8ov1Z+956y4TegCsRQRgKV2AbMm+dKESMtYd4+l80cRXdVp7F9A/Wi
vHs92MJDiWElH+OUSpmQVClOZ2qlNrqDaWPnii3SXMMyehWzjF0qdkpLDVuZdZLbgOcmOgReoB0o
U7EOjuNZhgeSgYMC3llgAhx0wQI4BtZDVhS8QrFQJTQILBR4icFVg4lyUQXUGKqeakErv8QkiJyX
K+aquAaug+O4Jag6T5bjlw1vqEbrr5pA24+g/yATJEVIjEBWf2xKgeBjpVfp/CPkFfYY+D64i309
lZOywJ7U3fAT+GnqIZik8FZ5ijmOLCBQb8oLSkEpU8THeRnIjMy38MuYPl5ycV6hkCsS5nDtQg/X
KwgCnjPnQGiHlInFmwwZiqcZVF4iBOE5SwGpWRqQGBTMUBmdDmeqEjCyBFGIJMBgrqhVJ1/qRclZ
vSg5K5OiEwfBAZTr0kEuisOaXqRUWY/p0FAdAttEBQYKdtgizPHUN4dSX70PdoO7UbU3mFoHN9Ht
qSXwLuSpw0PKm6xveBoCpO1p0AIRKmAU1eqU3l9lfdh5lDc3IWazbPhDJovZhBatAiyX240SE/JK
zhATtuP7LCXvEfLebp6RvaB0ubkza3Vkq7TF0Ze1tVSCQlFNmU22QZstR2jOBJmZnkQOM3qiIAHB
kgWybIVx4hxQF62hXjzigcrMoY/KMlAcqR7taY1LDb8e4lk+LToP6RIL2ZnIkZqSU+t9pyhyuvj1
/bglHogn4vQoHNDxdwl3MOGvjBLwV0b5DXgtKglfIOKSQcDHGYiYaCDp3ECqKIMLn9hAClIDCfuG
a0d0XrSS8nj6M94GkSKkSlNZE+oOd1wQkP0QOHmjCjOudR7Ufep5ld+6f422jdjmzmQ9520tim6Z
ufsPq3qWgOyHIyVFfTVTn+6SKl/r2fCEnKh9bs6ndTO6+zcufnijrcbuDhy+e+CeSCRHyJJne9zW
wvznLXmF0VG7VipZKIA4MtxdrZ1d0xEGDiAM3IqCfAaVA+xycQzGLeOdZTl1cLKlySnnzLUvtQ8I
WzONZpFz19oYI8iWOckgONSl5Fod+v5Zh3/k/tkv9Vz6jWwgC2jWd2vtI4ulfx0NvpaLycrdmhvI
TeRCs180qqouKcMEfLhIHEf0GbEKSFIsFhguTK6n9Jx6WjaQNMvhb5JkS1Lr/uEvnibJdmfwQhUA
rVa6hMNLShYOU+CqC/Itj/VMvDp2dacPb1N3gd3aPKn+8SUdN0827hls3rv60McvXnPbzEcbWtY1
/ujnsPLGv0xrbo4UxDhH6s2Js5TXlOOHf18/NnVlXibZy718+K/018xGKkg9JU+zhJpDMAxyzSWu
PM84EDePc8U9jaBZqjM3uyZ62kGreTnoMW8B68wZVqsjYWSCQV+CFi0hopeFyLbVdDF8RDf0EXkU
se9NITdBtdsvEryLAjEw8QCR0FmRmAzVuWeIpcRrc9M9n7A2GtlCS5IemsZFrNSI7pkKWrLVl/56
4WMdm19paGwBkX90HpguzXlm7v0Hnnq4akO0uMEpTYmU1zc0/Ok2YAdjxxS+PqnhnddeeTfb44za
EDZXImxO0rAJ5fxqX1nm2JxmX21mQ04bt4zrs4p2AG2sZ6KZAUJ2LSvZHP8i1pjUWJMra/A8LYdI
yCEElLKOYHslxHySFnROyRESayzqJmFix10qTrXN4GRnpt8vePCZBNzlCOOzCeRsAlEfBXKkQLbH
CgTJgoDPJFwbvECeGimoE2SWl1M6FBPI3CRwhHKhTX+6xW2roEduSWAmDc7Ys/TwZzMm1z3V1baz
aXBw2qb6e/fsvL3l4fVTLgMxYLv5yGXTWvILwbGzw/CqXN+fXvn17+uxJtM7fJzpZLZRHlTjHpYL
C5iwqYwZb6rOnsQ0mZqy55laXL2mTvcm05ZsM6gOBCyZNU78dMcneOszCosGPmFBThok8T5IgOjF
VjaRkY/KSbcq64gNbwniAjgRpAOAGAcQOg38dmJGOzGbneDTTsxmJ3+3Q/xl+7Xp6hUZSfVdHIkr
1HIqTKpXIqsHz3dw8X6OHFU4sDu1YMt0Dr08YUzsljlr/zpa6ji0SjmhHAbhb47+/Rlw2+27nzRC
/9I7R5eVzS99tWgMKvmdCKO1ypmvS37w4N5rVMZF27lsZLNfy0t9BFk+Uu4LjirHepZGdCThpAzm
CYKNNQkU3gElWkQzwpxRTTQkxRCXMxBUGABJMT6LjTLLJmul2YUxas7BZzaT75jT0c08Cl/JjBFK
sqHZjs9jxp0ybUc/Ppf5Ou9ITJWXl6fUQVTriyUqSH+E9MNRbtK816n2BEPxCpSgMM5ouxToLti8
CsxSnhwcGDj0XKKnhF0oZqy4seDeoYn08/fm//oto4A9VmlnJiEchVAdH5UjNRkTSspLx5XViU0Z
00pqS5vK5oMkO8/VC1ayva5tbF+OLZe1B51FcjbD65UYHsh+PCmeN8i0adREJ2/hABfMKydGtusu
btddHA9kFSE+ivMQ/57xHfzbd6lvlwfKE+UwTKAXJqsS9ntIp9KDfTsfn8lDgqWHrJ+HPAnhIUfi
MXq/dvTIbII3oH47PTipPgaQdu98KxW8sAt0sbtXXuzuiqJ80/7YTGnU4e7OK0Kh7Na7NyHvnzLx
2QVdVzeifNR0lXz33mvunPnIgHJMOe11v2CPjyouvLxuSd0kVFvxt74+rb65sKhs6G3YlZv12qHB
FxMI1wcQcDtQ1HWBCjmDdrqc65201STUZjBmAEzCt0bYMyTZQL2OhT7SxdV6AkOyjSwDM2IZMJ/T
BorGEHJ1frePLAvmaDGSwgigtbL7+56Ap9MDrRf4kDDCh3wmnSOY0g+xmMjBJp0jmPRK3ESUCHw1
EzmFCW+BIKobVsqICLfTPbLLSRbvgjBNIk8Ya2YJleIFQ7bzu+p1yuByMh2Ddo93YdP0R6cPDrYN
Ln7qF3Db9B0FJcXTxg/9ApGDVxtnvvcqjsRPIFpwNfs+2UX5kJwB6iAyTyWkOVTR4v2Cu4hBS4mt
OhkyMe2hXxJJGLXE8AFIunudA0RvOaI3fzWDaN0u3SCsbhBWXRbS8x1WpcKdQnq6yWOqBY6FSfWa
IBsIyMZD/FjX1W++aRwcZD0Hz+YzSTST4ReVdugkM/FSr8shic1kYXo6rgle1mCwyLyp2Q3cAxKQ
QKdLR5ZLF4Jc+v24dGS5fGT+6mNZnZK7zwu8RAX0Eh7jxXSHTNFLRFD0+ZjaJPBCLSmpe7S8+LmB
DHxqL4/P62Xxcnt3+UcubrK8XJ9yNBlNag1bMu8kmfelfdtQPAidyBKHHy26ulTK7Ig0tLlcpk/B
I9gw0kuHrcYnDZlFRUVrZtDX3IsZ4C+Rtz2BvM1AnZXriuAfwfsiLQKLKQCyYMAUAVFTmUE2zDYs
h1sAfqgP+NChgrgPGiRaEiArsTwqkgUD7JT68KMkJMkWEQ+iTDkm2YSKd7LaNEEJzeA5aw/j+EZC
4+hF0EgjIo2R46qvsIyGkH+o0hwaEF9hrzNe6iu4TYxqILXRllBVHvzY9Ja/e5gXsOyBhZ41wRBQ
nQXVt8wTZxR5y+AgDJxM/RN82q/cwDmGfDCaGsLP2SCTbSTPDP6XXAgBEDC+d2kxRWW+xJO19q5v
AACgzxGk4Q+M6aa31uvWsiogUwOYAJPBTuY8+MmEjmtPqpIHGTcODhJ1DEdM3o2yXhgclpvoPLo4
Iy+juC6nruCZEv7pfJAfyMoU3LVFuUwWC6yZghwBgUhZRI60RPoi7L+++QhOhG58wxHCqABpIgJB
6+CfILUWwOttI/MpIwdlalP6ioRRgHXoMJkMIU+gy5pvyNSeHybXtJBrWsg1LT4rsQW+jpVcB33+
g1qOWwvw0VaSOa044uPTW/XQjwbnCBzQYFgO4ktZAz5yGR+5jI9cxkcu4/Nl6ouSmVZJM8nBmTrw
MvXVyUxznEwJnyJTlQLUgWzGV8rsClhl65VW2hpNKyk6Aq0Xfsba+/lDtPCNlahqBM/qVDnZb31R
GEfFuO2iqO5UE7Ia23n3oMnpnjOj+d5mmlGH0+/GYf6JxWvvK1w7uGL/E3Bbw/aicGlzjbsmOxWH
26ZeWxQO49DPJLc1zuxs7Wz94DCl516EJBcovjj3sv/D3OsekXvVZryeaBVd+P4LXuGLEi3uSRUR
NJ5PuSTZqon3X6dcgsoLcq3qW+kk/L9Nuf8p4zq/Q8YlZkcJF1c+HzJrkMUNlBtFYN94c8wac4x3
NZnrrHWOJpdgSYiMM0FLRn0HhFE3vRG3BIjJjH6vrNl0SNc9/qJ6kfYA8f7h93RWc0qvy0/rAshZ
uUYVQLwWb8Cb8K72MnaiNdqJxe3EynY/5yJPGRNVjCMElSO1EYcplBefHT+NjN5J8xX/Db1f6/k3
+0/C4fM7OUc0VtNPMmGOuUb55LOTyqfAffIz4Hnx8d13Pvb4Hbf/FI5SvlBeAtXAhv6rUQ4qX7z7
xhvv/uHdd7CipHQztyKL4qo9V84vh1XO8pxJsNFZmzPHvtR+hbAtU9LVJDZb5kSD0aHbFA1OExRr
apJmzNd0OH+pbX+zX7zh+lKrnv63spLxu8pK6Z5NWl/SotF30pcuFZj+jcKUBu/FCtNl9bVPds+9
qXFwsOm53lc+fPH6W2Y83NSyrvGePbB654eXTZ1RUKSUsv9cn2hVfq98/srhKVWpHXm+N0k91k3q
MbwWvBweT9f4yjLH5Uyjm3xTMqfmYAWFhTbGI5sZYMyuZUWbQ9VIvnOk+a5Kylm5XVVp/6OSQjZv
CxxRTuyX6CdmfBZB+HcqykUp4GIZBYRs/6muGpz7f7p/fXJWXe3exfNuaECF1GWbpjz0+HW3zXxY
6Ya+pkZEU8y3/rmpsaWosGzoebgplPnnF196o16L4PRaRIDt1KDsoExWxMEQ/7KguD5JsrCiMPK5
AW0jBUU5ZEefAxp5YjieTJcn8OIJQnmfqCNUTJMYDc46QvHGFdlGdL08DE9R0rU8Ak80+Kcq6u3M
+HaWhlFZrT5xRIx0SbKj10olzWPmPtg0ONj30/bRpaX0rZI4vWbor0zykXlNLI9nf/nwx/Q7zCaq
AsyS53JQ9Duh118gluSVi9V5teK0vIVs0jUrOCc6u3w1u9LVmdMd7Sl3bGEHbP05m4v6w9eDnaZr
fTuKfgDu8hsos6eYyaavzEVhBGMiN7dggqoTyITs87xhAi0GzRhcYWyMYmK5YmKzYn+cxGQP0ZI8
ZAOgh6QcVMifforU62Yd22aiUxPdxE8FPTzJoHozOL21Tdtt5NBiTzrknNFDzhm5kOD6Zq0H0REf
iLM8Cds8aSXwPrKc22OkaXC+dUB2BITD0XRcTktZ6I08gao/ATai3ojHCtNtfx3Jaf3Vrbb+3S76
ndT7234/RWp/r3vbjQUFK4uuit+2tWrc2P9e0f1qndTwu8VLbw6XLIxdFb66vh7U3vnS+NAbk5pb
5tTm5npEj7lw9+WTt5RFK0eHXo43Nl82ORRyGT1SduNUtNYThk/AFHsv5af2yrVG1seGWdpg5SeY
DBLr97sTtNicNZAFzdSNWYLJStBqJQtkJSzbSpbJ6pMEHotdPK7cbGTDJRG8NF/Q4c2n4c1nEmmI
nAM/qqCmYN5N9l3uzLxQ71LxHbWeLteqt4oKdcORKlzjeq0C7151Bs930itg6v+29x1gUSXN2idN
IicViYMEQRCGzJAECUpQkKgIK2nAQWAQBhBFSYq6iDktZswBFQNm0TVhFnfNWddddY2orJG51c2A
o8vevf/z3+/uc5/7eeSd6u7qquo63dV9zukz4zzefuO2kpL95MS2Yq5u90FhtqndlZTUtHafpiKW
kr5tjUvb6KEp1pbm+jzU6+thDRELY747qe+jo8zuyRnLoSlWNx5Lsz9LieR2fVO6tYtg+tzHsD2Y
/mm1RsnD6JOOZUSrj6PCzRG19njavlL763sj3I5Hl9zOZbf8RnWHn7kdcyoXuRZPdFwsgtuxUAPi
LY4k3Mk9vnkW9tUd7HbX46nOU75Oc5Y7XWHbgqYjE7t/xGbx1qP7NfT0YyKC6kL2F4eEX7lAXfo8
MbrI2sYy1IPuDz72Qu9TgI/ZRLWPrwVjxXZhhOxAJojNtmIJWT6sIaxEFouthx7h6tEUbUn0pt0I
VzqYGEDnk2MprnyjAoviUiR66eKQjxlPw1WFMCAyiLEEQ1SjjQo0rU2L6HyaoQ3wRsxyDgzRBJhR
Etr3iiruU4D/6FG1/GE9U9LmeaCt3xkyjoSe8HElk/BpMl0E1sQQBJiaQKgQLXsILjhXvrGz5cve
Rfxq3hufyXgZTBvSNmQfyoo2ZyxYZlxrZSfSg+VPhrBiyaHMMFaschaVzKRyM3ipSqOUi8jxVC4j
5Y7j5SmNVTZSQc3n6LFZbIKnwaN4HRsUlNjRnXsTwAHqbGO2HZsm9HCEs8AdaLqahlo/NYkaTbDR
Gh6vNDv2MrHxLmu8tMR70tgV8k3NDjiCyR9Xf72RAf20FGndsZlBG1ykzXZpu7W57V7bg7q260fP
kj0WkUY/IlfRCZ+Qu5bRSegPjSdPONel4DNl4p7PNJ6yPqlD63D0eb3p3hxPwoN0op0YJ7YTx4Pn
pRRKhJD+tD/jz/bnhPAGKcWR0XQcK5oTx4tWlpCJtJiVyJHw0pRN1SmC248ScMMoH+54Kgc6tZ6S
shJ2Fr6lQusxLIakWDBg2MxYJh+5igGaZFOqJDhNmWGUcLfpBd2GDUZWo1eO0Neg+KiOUGXYFEMy
ONIz5eg2SIID3t5ijfY64FtH+GvlutjqYNK508GRZEqfwVL68A1yR1v4M9KD9LzZFkTWtUVSfSkB
+va3z9eRd7xgTYdGAoeY5uPL4P3b4exEdg6bzaM5rJ50D1YgGUQPJWLJIppHcVCfYOkxNBNEBDIU
QVMMi1KhRpIkSdE009kkNBKC8VhgEdU8dR5JM9pMACNi8sEv5VyNX9rbg5tDdNzJkY+DQ/KNK9rt
I+Gz9OSFNr8zZCwZxyR84JAXmd6fjtKeyPYEWB09ANt5RIyPezeuO+3MDaYDuPF0FDeRW0LncJU4
HNobOinF9Sa5DJemOByG4k1XNlbupzxCWaJcosyiJiqhjXS/wIhEL/vK36OQP8QwMXFGuxy6kSb0
g09jqarPFXT651xqWRXtvKTyU/s1NpStYpThnGvvomkI4OwpKugbegg7/F6gjvzBPEyn9KqbNTU3
btTU3KTm488bN/B3ZXky46mbBE3o+qiQUWiLBf76RMouQXGjBTP+kwH9C+WJ3l6XPaMfkpX4vpXt
TkoXpjv0FVnbeSqu+FUNVfA/iV7/p2AuodDuWEf0zjdpjR7JgE8rv2979YZ+SNmB9uXwKcSS7GCp
CZX1kDRdEEXpdoihQQxBkWCQoij8vV/Ctlffr2brfG4GYfifsfxIJapJE3y0kW1UBLWFNoYjiE6n
K+jNjICZxXJmPWY9ZhdwenAiuDbco9wnPAveKF4N765SkLKt8iaVSlVCdbZqi1qM2gf1cvVTGr3h
GA2x/o5WibaJ9hWd77uJum3rPrD7qh59emzUtVU4/HX9ewbqsfTm6gfpPzDIMgwzUjPKM2YbLzF+
ZKJqcryXxNTZ9LlZlnmK+SOLGovW3jMtjS3HWzb+C447/4LjffthZWQV8O/j38e/j38f/z7+Lx54
viUJguMOk7QDmyC4pA1ceTTIFhPqgLaEBmEmOwdoI7sP2BfyNQgX2VNAV1kGoBCXumP0kG0F9JRJ
Af0xzzDZVcA4TA/HPPE4JwFQk1CXTQDUkCUC1sumACKNZpBzDtBF1groCvlmhBumhbKjaCM3LvUE
XWZErAy9BT4Ulw7D+XFgpxloQXQ9xp0YG0COOWh8CqhBKAFqYtoVZJrD0kSJsMB6LXCt3sCJUBOj
K0Z34O8NbWwF9ATailBv+xlQE6MhyLEijDD2gqsFK/DbYkBXwgjQH9MDQY4VEQFoA7ruA9YD9sVW
9cX29IVarYQd9okdYQE5dkQfjH1hNWRHOGDaVRYDKJTNBnQHyXZgD+IfhnPiMdbjnAZAB5B/H1AT
I2qLA26FA26FI26FI26FIz7XjmC9DqA/pgdiRDY7YTlOWI4zWLgYEHnPGctxBv6rgIjfGfM7w3lB
+fGyk4D1mL9Btpdwwe11we11AY0IXWRPAIeBZBfcW1yg1n3wnXrbbUAN6GmuYCGiDWVuyKcYkZ9d
QcIUQAvQ7gq+QugA2l1B5htAV9DoCrZBfyUCZdCfwEKEwdDTXMFOREdjaTGyUMChmB6GMQ5jPMYE
8LkrtCKDcMP2u2H73fD5EmI7hbj/CLGdQrBzK6ARRjPwkhD3ASFoRxiBcSjOj5c1AqJe547luGM5
7iAfvbSA5LhjOe747LhjOe5YjjuW4w72HwUcihFJc8fSPEDOVkALsNADPIPQAaM/Lh0I/B4gAeFQ
8LYH1EX89YCe2BJPkCAF1MQ08rwn9rwnWIJ4UG/0BGmIZwCcBU+QOQEwGGM42OZJDMEYgXMiMR2F
6WhMx0Bf9QTtCIfhnHqQ5g/0S8A4sNYfrHpJBOC+F4B9HgA5H4lAsO0pIOqBgVDrKTEQaCkRBNeK
noAqMF6CCFXo5UE4zgRhrwaBhCmAvYhswHiQH4R9FUQ0AGcI6H0KiPSGQOlTYjDu54OhXYiOwIh6
cjjmDMec4ZhzCM4ZgnOG4JwIbHMEtjkCSl8BDsd0PNCRuDQSl0biFkVjn0fjdkVjn0eDb28C1uOc
BogksVB6FRBZHgv5iG6A0ToMpIUCotJhIBPR/pgeKHsOGIER8ccB515ApCUOOBHtj2mkZTj20nAY
KYgeAFqGg4RHgMGYjsA08lg8yOkPiDTGgxxE+2M6EHTF47rxWHs8rhuPbYiHs49oZEkCtiEB+FsB
B2AcCGM2AfMnAD+iozCNbKvH/b8ez0T1eCaqxzNRPZ6J6vFMVI9nh3o8E9Xjmaget64ez0T1OLbU
45moHs9E9Xgm2oljdQO0yBZQE2N7jiv0kwYYnamA7tCvGuAP5cSA3xrA95Z4/rSlbDt/s8iB6Pih
KJLgQKqdpoA+LKdpyN0ipxkFHhZ6Z0hOsxXyOcT4TppHqBH35LQqGUq8kNNqRB/KA/1aFUODLhVK
hGkW0BpUPqbZOH8Spjk4fxamuZhegWkeSEql6uU0SajR3eQ0RagxjnKaJlIZdTnNKPCwCF3GT06z
FfI5xIdOmkcYMHlyWpVayMyQ02pEFKc3ppUU7FdGtnHGYVpFIV8N0ZwqTGsg2ziLMK0NtBZnPaZ1
FPi74Ta2090V8nviuvswrY91tcs0VOAxVqDNMP9JTPfF9BVEcxVs5irIV1HIV5Hbv57vIBC48QeJ
U3IleZI0Kd9PkpsjyU2SiiXZtnzfzEx+hDh9pDSPHyHKE+UWiFJtY0S5qUnZSXxxHl8klo4U5fKT
+LmidHGeVJQrSuVLc5NSRVlJuaP4ElSikEzrWgtfnM0HMfzobLEU6kdKk6SiPH5SdqodCJBgBSmS
/GxprliUZ9spwb3DjAhRen5mUi5K5yFpzrYCB75lJ5/VoCQpyCjk+yXlgoHDJPn8rKQifn6eCJRC
E9Ik2VJ+Uh4/R5SbJZYiA5KLsDkB0aG+UJqLEzm5ktT8FCkytXCkOGWkQl34FGenZOanorZL+Kni
vJxMUAD2Qy0xMKQAlyhbasvv0C3JziziW4qt+KKsZFTpi6jsDuYuLcLsqeLsdHB3HrgjBXlPQTv2
o1yWBzbAUgxapKIs5OpcMWhNlRRmZ0qSFJWCzUntloKjOz0uyZfm5Ev5qaICcYoI8YwUZeZ806CR
UmmOu51dYWGhbVaHu21TJFl20qIcSXpuUs7IIjukIs8OJikJkUtkEUlEJoSrIkglE0WkKiHCPzvz
GP6+lEcSUvjMhhCXBHmpdA1dTx+gG+FvD72X3kSsJ/gQfgRwuAE1iBATKcAnIfLgLw3q8gk/LC0H
YxLkiIHKJmyhxBfkZ8JnBOSlEyOhLA+nRPApAu4CwFTgjMGpVGxHEvoCS8wngk8p1EJlfJyfC3Q6
LpXiXFSbDzTSmwqpLNyGUZAn6azTdWna/1NbkEXZWBayhg+TcTa2rV1/uweluFV8uS/t5BZIFFqQ
Aql8KEUWiTG3bRc2uP/JGxG41fngSWR/R3lep23OIEcA54gP09Gf5VlBHrKu3Y5C3EYkp92Dw7BN
fOybIvjMx2emvaXtZyENa5HilqF0Dq6Xhdvf4YFkXLfDOwHgn1A49+11cxVKcrBlqaAlBUts92oh
1pUC2LXe9jTiTQEf5ONz2X7eJYCpuDwHe6eo0//tusRyCSlyWSKMqGd+225UnokpS6hlhXtfFrSr
Q1NXVmX/SfJ/3UdfpKdiSeny3p0n7x0pnX2v67Z/6Y9f2+Wh4AHUkva2SLG+jl6N5Le3NRVyCnHL
JXiMdN3Sdj8nfeVTkbx3f9vHkVelwJePayJrC3BrRJ1yEGcmcPznZ2gk9lwO9HY7OArxYYs9+nXv
tsU1s4BHCi1CLUzHbcwBCUWQ29GKPEIxKqK4J+5M38NRUvRV1BR9FRdxZGSMGHsmhBnAeAEKgTsJ
2oa8hqKpL3Dkykd3UscPbBKwDh/TxS92ta8C8cqLIGWy9l8ZhdUfQXQn5L8+Su/EL/5+WUsShBJc
e7sQZGaSNBvqwronNGogn+geETaITxiALhnWqICd9dwghHRdz0ihBtn5SRJUpiQlk1DDqIPlkHJp
FFrbyVMa8k8LtBYiGHoq/T1dRU+DFEW8Jz5AkTHJxykuQdLVWIpULk0uT19MEFgD/NNPEpTrJ7B5
fSoHVv6hSnKo5eX6gyErmCJJe2UBj82yVqMpPRYhSGIrWbNJhix3pUhmeaRgiMBGIceg1qjUABbq
6AiDUYb6CjqjqHd5o0NgoiCM0Xkr1DkRuH7OjrQny0I9prrXe8x0m7W8vHsfQTmjJSinPiyn0bek
qMMCvsrTc4pms3drytM7PgLVTkvRSluQY28tsGLT0Yyydi8/SU5RLlrH8S1TrPj2QqHrN2sxW3sj
gUE7c7cuV2n2JgJjVE5r634pj5BIpHzffOlISa5YWiQw6qEqdBXY2wsErgL4F9dD1QH9qqy9PPkP
WFRO9lJ0C8ki6HJSnYB8JaqcJIn11IHDOb96tAzWt1y2YMx3gie166vNR7xrmxe6clfbklq+d/GQ
2kW1MxIdRjX3Ty16vqngZNT1lt8XVxrMWDYxbfuxUWOTTS8bet5WJ2c/mn+0sW9aTc1Iix8uuNs0
quwcanE48Dclb7f5NustheueBlX0fzBRfV9NZnTSpvLiFYl9C0Mf/7Aj1aMm3MCea6azbP1vs6x1
f/VamKKTOJQlWmboGjH5j7Uv5lLH9X9qjA7YPrW00f1p1NzBmz+vHZslHbxF98x8nqUJETszUey6
L0SL4xkjG/5xVZoSd83FspjYFw0e33UvK2Sutx7cXDqvbevZkstr9XLjPU/tf8ld2UuwnT3p5HZ+
ofakOxT6bYSVZesEZasFZbXgTUOSKasRlC0o1Rh+IeeFOHep6ZAJOtsGTZedXpH7P3/+yv+mj9Po
HM57pHyo+vUCXednu0mzq4War+MTHZYtVT7tzZo1ZcZJ919NWl7GzrHZuXxAU/KLT1fOeHjErXeJ
EreZZfU7eWbDbVbxLftqr2UaORn72rTCdMWHPl3we6AZxw97kjxuy4aeTdau5n0PilZofW+unrLy
jyiD9yYnL3d7HbEp28+B87m8x7uH6ZmqQ1oPvIo4ceC3o4JPfHveFMN5VnqDLhlSq1+V3qV3DH9T
f6sp9rko6EREVMMO2lJLNvPyS+6MCbsXHNvoavPL2F/WFT4oWE5cyOh3+KLL93d9tdY5Z+hn3HC+
97MB88u6AKYpztEte5CBavIupdppP12K6hd41iB6Tc4NLffJc/KXrb24HKJCoqCcDm2PCkq2GzVv
hsvil5w+1BFTDP+pYADj3s0B/kEEcIBgYO8ASeeOYFCEIygIYWtT0ZH22gJNlOBqK8Um5Y2Eixwp
qNEQqKFMjjYnQpSaJclO7TBM6a8MMxWYtBump1ieKuJHitOz0aVTuJ/v30aFXUXjLydsDxCuc9pk
f/29uXNQ4aGPxktPBIx+0Rz46OdpR0aFRiS/+YE6MuhqUKadmbeo8ZzpLuWBu0rybwUc2DBDLfyY
uXXL8t9UTY2bfc0+JP9wvmfA6jnBxj+c3W7X60hw32LJtW5GHtOEGsJbB6zepHn0JR1kbb0HrtmZ
SU5e/HHvtpSS8vfxy8smTpq+tWX33JXn3daET+rRe/LgW4JWwuvN8fdeZQcrn2UK19o6te6w3aI0
PnnWmLTFC/NUK7e0HH3N3xOmVZ1y2uaaQ0DP5/uC53uER+qeSxtStKFuclOM97Ly8CnZrHrnw+PM
DkSkef0w+Iz1BMfsiQPYzUsvBFdS2ZXEqkOT70TKo8IHQdkfAm0UFMwZFYESmwsTGovFoen/HaFC
HdmoTZIyhiWg4UNgiDLUmO6MzhnDcwVEzvAtr64fHVwzxN92pX/KS4EyKlZnGBhGlQpDB8eYcRs3
Twi2aDm3f7C0dmhvaZ/87ZWfN4bOHUMMenzqd92b4mNqtcWvKb/jpyafeRd55sdlB2IkL1P81/sT
z+c31Vwy2K28rKfq3CvXjeqsxr94tiZv04zbwuleCzP2u2VdnLLF9POdx5fFvFlTDrTdI/Y5vf6j
+L2Gli3rd6v5c/qPshy9y23GXY7qyYSRZw+U+o5KW7dv177pTqdaaI3isW8v3u1/Z1zbvXub2lrv
XFLdnnN59oOwBrfa4r4/e91wUk52pZaVZZhObY1PmbE1bp/wSuK06Il6jm89Fi4vV6kdUbXdZteK
1ac3Xuc3NAp6TuLrqPbZH/HG9+53ggezLcWTD+fcf71247nS/rkFahBjMiDGRMhjTJL6mEHti0bF
ccSCOPMPjuqOgOMoEEDEcYSAIxAKHFDSESUF0n+JafJy+i/K/zbW1N5Qqj7/4+GgRWc3uDvVmQ4b
dSPzoEmvXXObnmxuPH7J4kcHzar91xNsPrrEGHWz3jxD9ZbOymzL0JLu/Xw3VfvUB05RvVY2t24B
+0Ksf0H8k1ef1O6XSFc6npY+fPEgacUEeleA7JK31qWtp75TvTCuZZe26qfEDMtJ+dN21e2f9KjH
jpkH33ZvSE54pnnH/bnJ8KotpXlHAh7Mm1qYuOi3usLDrtWOOnbaN5JPbtZbH7Ywve5nvlAw+m51
euD94wZvVMOlvnaPWGYZJqOCts4+uk14ov/qrHjd4I0zrkyv8B6jNODqqm0TTY/cbxmXVh8sPWDh
G7I4SSdxsKCp/PUF5Zzi59GDCi9yowvK5LHmnaDsLfa9oToasTAI2YcUBuxrE5/pxUPeRYUsfNjj
SkaFE8vW4lHXoQnFCUNTRlfQvbTrYe6PGIwZL4GHQLjcdblzpaP8PlZKbuY397FyRolRrp387l+e
nV8kdDRbyBIM7FAJ6xBPgbvArSMtoCpt/vLGGBYoylWQJP1mAOFo4xMriUxfyq9wItV+7RHiWff7
1bKS56pF0sKwBQN0XxPdxBNuJM+s/Zy+YvEvllYfoq/80Bbe+B1v+541z8pfLzSSDPvw9tU9lZ+q
uN7de/CbD+0MGMC1SIzlhcx9yT2zd1D2y/sDtSydq0xy74xo2CLWMpv7/LET78aEbMlspYhTfUKD
NjjYVD5acSbBYv9+z7vDt1Uo73U2CJsYMEC2b+6KYZz182+NORBbsnrt4DMtdYtrfO+fjjfzvlni
NGBw6/mmcUt+bzi5OEUncktdzYsrjeeXr9g479RY68k2h05c+5RJX290q3vVHN+zh/qhP06VrtHg
6t2aafrb1hWh3k+2alqMUTtss2fVqBMzPCHaLIFoM6kj2gQVP2t/IPHPRZsocZYoT5qUlaMYbVwE
QnsXgb2zswNe3tjjpIMAJQVla/4ltvUWmLdPlEbZfuIcdKfWPzKAHxA52N1e4O/W19nNybWvX/9A
tw5GWtvoLxoRKcpF93b/NkA92ctKabpWtHmiv/fq7UefhS41uyMsMOJddggeOuai9bXVnJkvfvP6
eMCieOXHh+MnOJy/5lUldG15d9XDqfvPs8s/Oj0dOSlXb8bd3aF3d0967ahEHa4tyHMOTXi1617w
eMPdc8fckBlN6tY/cPS5kt6xWs0VYR7nP9xurXrWj3hw6XbS+x7VIavKPN+KfZ7cm9rICdsrHfdY
5eGAJxszX11KL+O+635qvPa+vPu80A/JH58tF9a4t/2u2ZRklDz0qlJUxSWPkJD70QfsEvWmz2b5
XU/4vVzJdAFvOcteVDVnsJGvSe3smZ8D/AMkzvUBrnXi9aL3Tn71PX70EN7TmNaiN/lBVLixxxL7
OsUA9SUgTch9adsvxuqu+R8jd5OfQu5NOP/A+6vYI3k0uN+CPU4bQypn7F/8ZJOHr9/xC/9fsUea
l5OS9N8SezokSbuKoNw/ReEuApR4bDlPpXvz7fOBU20bm53GlpX0tvTt8/onk9lqC+pGRH5n9f7Z
4ajgdeP/0L6grPN+UEtlNyL7QYWhZcBaG6HDLUmNa9xz04gZUXR1v7WLU91aXZp0/BrcvReeVD0y
uszyddpa+/vxCTPeR0Tci/99zswlYl7o1ObmglAn1Yx7xf5rrYdXRJUEmPU0P/p94DHzBz1LxVY6
rT2Ov+xlUxb4nfWb92uOF3qbSt6vSZ00vTZZdX1fo3UPZ3qXyLZO/7Tg6avPzJazQefipJs+vNY2
1heeW7nj8v43O5431bXEGH30fNV0uY///sbF/can6Z7dxk9ROuXjJXLoWbxtt9dhi4GDe/X8IXua
4PCrWV8HKI0M5R/CDhHmGzVvBBgPHZte+22Y+mcuvuTRSeDk5IqikxCS/8DF158C59/Fm5uu2R+3
NPUPHq3bdG6gd+ShDxt19to47NMKi2iqeObteC3IfrZlw6zUu8bhE/f+GNJcwnr3Iv9g1Yl1lzaL
c9LG9E571LDrxaQ9Z59v+Ky1SnlYLyu78z7XYhj9gp1ZqVnBUTduvbrduKziROmdklDKde7bQ0u5
MUYjB5y9dqgg3m58gzmzI2Z4hkGKrLTY8/klxnyQsFDKSfgx/mqlq03+SbUnRkJecUHbkszssXef
es9YsHS02og+YbrJiQ5LL1YMtu4VPzKg6rbdRI3wbe936lVnPjdfpP3utMaVSWpvygvyXI7PG1t7
JpH9lLW10nHXu7nDJ/pOHDppbvZWY5uBZySL/e5mPCqxmD6qPd6Uk5bgEbOuR+j/issvDTZPfgO0
G4muqQiF6NllcOzZWUGHYlSMlIhIIp9IJvwI368vzf50XddFgJo7SNP+x+LwfZrTVyRxSLVpOQHV
L/KiDvTjsfrKdg+JnGTwTDhr18oY5dvTGjz0mz9uWntyV/0QE30JVzxhFF3bK/BZ5o6s4l67A3+a
+Lpa/SDne5fDv094nJMQsGz2xTPnbk0/dK+xz9nipyc3O1yavOd0ylGXZl2TxoLbHjXb9fOWmky5
umOHVtS0N4t/FAXXWFosTvxe3eOEtmjMwH3n6yrcw7YmD70tePxYaPhgast1Ydl7bZNpqaUpbGZ+
Sw3lZzcucMpeGXVN9D749nVaOmc7K1vlzJKblknFA1/1WKxp4kYZTN7EPjbfYfdDn+ORXgfWT739
KM21+k2v+YvPbC2MGuJ+Odd/m2mrfTmzGoLUCookBWWT/8Grsq+uFb/c415edkGg03m+LUl7Ds3C
zyhQL5CfTB5tr6J4Wx2s+ZJStlcTKJZ2E5h+qcjYQx8rXdRUzu+de/DXA0WFd6Ke6WfnlXkI4hSq
qNiHCoKX80uN/vPnmyssSs3+C0+6+d8ENaacJHTzdM4V2XifOWEuHS3YWVXVbN2/rXufC5XeOx7Y
RrqteTv+lhvdf8SIBEt9/Vm93pYnL2lzqNhurb+s9khCwxbfg88+fZjHuNyKcalYp3a5u8flDN0U
6eTXGXveOHv1beMISkoWu3t9iP/5qX+i/6n40Pr0GbNWrF/es2lqqFbvj2Z9romLCh9PXzXssu5j
swU+Cyf0M8saLya8Qs9XLRrab9Tv22InaYzKe5DbsnBhIRUeT+3WsW0mHxYt1mH78LYzNk41u+M+
WExccK1tJ/FpLGu9SHdP6QSrXe5Ro+cbOac9jbmsP7e5cuW8D2HVqd4WWcETikz6V6WEFKQePhVx
/Y3+9ojRg94eWLSinDIWlFP6X84M276cUoEs7v94x/x2HvrqsoIj75jLEwS6iv1P+cuzHxJ0dpaw
7NVhgnWzFzii6VTo4Bz3p+63WisiX/zTuH5LaobfWa+daei4enTeN5EKdZEx1jNPM2YuA1ZEbV9b
8avB+5TmI7onPU0P2/D/uDLdZOmWCR/Ol1snzMm/pFxTHdc615D+fOO3yS5Kk/oVON6qWHQ/1ngt
19rHdCLn12Mtg+Zt2U2VW+atTZg7r3/l2hJLzXHNsqLSvhcZ6pcR5j/l+akEJ1hYutqPvHXl5jGZ
V/RSzyc2OoY/+/bdseH55iPmhybvSI6r1tzhUxU+QOfo61vWL5TDDj6Pmaed+VNPFZfj/DQR++1C
U8PG4UeaNlwwPpFu/u7nY8uIQzvm3xfKni/ZlNH7Ji+2xLLbs9bj8RuEi7qFzQxrZKbeVOcsOGpp
crublsqNmNWzfp06556yxbFe9IvyotkZdb10gsH9/wFpnva+DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM4IDAgb2JqDQpbIDBbIDEwMDBdICAzWyAzNTJdICA2WyA4MThdICA5WyA3MjddICAxMVsgNDU0
IDQ1NCA2MzZdICAxNVsgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNl0gIDI0WyA2MzYg
NjM2IDYzNiA2MzYgNjM2IDQ1NCA0NTQgODE4IDgxOCA4MTggNTQ1IDEwMDAgNjg0IDY4NiA2OTgg
NzcxIDYzMiA1NzUgNzc1IDc1MSA0MjEgNDU1XSAgNDdbIDU1NyA4NDMgNzQ4IDc4NyA2MDMgNzg3
IDY5NSA2ODQgNjE2IDczMiA2ODQgOTg5IDY4NSA2MTVdICA2NlsgNjM2XSAgNjhbIDYwMSA2MjMg
NTIxIDYyMyA1OTYgMzUyIDYyMyA2MzMgMjc0IDM0NCA1OTIgMjc0IDk3MyA2MzMgNjA3IDYyMyA2
MjMgNDI3IDUyMSAzOTQgNjMzIDU5MiA4MTggNTkyIDU5MiA1MjVdICAxMzVbIDU0NV0gIDE3N1sg
NjM2XSAgMTgxWyAyNjkgMjY5XSBdIA0KZW5kb2JqDQo5MzkgMCBvYmoNClsgMzUyIDAgMCA4MTgg
MCAwIDcyNyAwIDQ1NCA0NTQgNjM2IDAgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNiAw
IDYzNiA2MzYgNjM2IDYzNiA2MzYgNDU0IDQ1NCA4MTggODE4IDgxOCA1NDUgMTAwMCA2ODQgNjg2
IDY5OCA3NzEgNjMyIDU3NSA3NzUgNzUxIDQyMSA0NTUgMCA1NTcgODQzIDc0OCA3ODcgNjAzIDc4
NyA2OTUgNjg0IDYxNiA3MzIgNjg0IDk4OSA2ODUgNjE1IDAgMCAwIDAgMCA2MzYgMCA2MDEgNjIz
IDUyMSA2MjMgNTk2IDM1MiA2MjMgNjMzIDI3NCAzNDQgNTkyIDI3NCA5NzMgNjMzIDYwNyA2MjMg
NjIzIDQyNyA1MjEgMzk0IDYzMyA1OTIgODE4IDU5MiA1OTIgNTI1XSANCmVuZG9iag0KOTQwIDAg
b2JqDQpbIDM1MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCA5OTAgMCAwIDAgMCAwIDAgMCAwIDAgNjAxIDAgMCAwIDU5NiAwIDAgNjMzIDAgMCAwIDAg
MCAwIDAgMCAwIDQyN10gDQplbmRvYmoNCjk0MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAxMTk5OS9MZW5ndGgxIDUyMTcyPj4NCnN0cmVhbQ0KeJzsfQl8E9X2/5mZ7GnSNEnX
tM2EtKWlpUlb6EaB0g2wLKULtECloQm00CW2KYuylAoUyyaLgLhQ4amoKEFQQLbiCogKuD1REJ6I
oFYRFZUtvzOTNA2ID/r+j/f+7/OZ73S+c+65955777nLzE3SBAgA8EXiQV5WweCBZ64tOQ1gzwPQ
zBiYlZ0DEdQugM1mTBU6MG94gTBJnobhuRhOHlhQlHEm7FwEhndjeOWQwoJBo2KMfweQFAJQrw0v
MMTX5T/gACBQB2Ujs4YW236aUQ0gVwDwT5VXm6ymkU9IAZrTMU1d+RQb3TdniApgGaYnzk6wTqxe
++rI+QALtmH67yaa6q3gD2IsD+2DYmLV9AlprR8cBVjRBiBsrDBXT6PCNzwOoLoAUJ9XYTGZjxtH
nEdbYzF9YgUqFDrRmxheieGwimrbtNQwfgsAmQwgCqqqLTc1p8/bA/AY1kdYU22aZhX0F2DbiR2Y
nq4xVVuEsn5PAqy3A3g1WWvrbY4MmIb16cXEW+ss1qCfHqoEWNKK7U8Exrd8vrb7mfLqcd5pv4JG
BAxe3L27hrm+FZtdfrXs2gqpXVQBJLaLBCcwn0h6PR/LiMD4c1I7yIACT4xi0lCvQqIrDwkKGABF
KOj43zk1PB/iYeCDiL+WnwAxRDh7HUK1wjTyWRGQUgGP4vOkJO8pEDjSgR7DeJTJOLSAptE6Da2C
0OslcEgkJV5CxTomjlfKP8q0FAgR2zgs5ojzpCJgE7WJiIP/EQj2Qs6dpBN+T+jvJB3vfejulq9C
Ee9NKO4I8xWQfCc2qEl3lo4DBw4cOHD4/xPUqwQRHGwk7jxHmFvycUuYnU8AdFrp8W+pHAcOHP4a
BBAMwAt+FzlABCLHddybSJAlLEtBiuwFXsgykDmugRzkyN7gjaxg2Qd8kJWgdFwFFaiQ1eCL7Muy
H/gh+4O/4woEQAByIAQhB4EGWcNyMAQ7LkMIhCCHQiiyFmhkmmUd6Bx/QDfohqwHPXIYhCOHQwRy
BPLv+DzeHTkSIpGjIAq5B0QjRyP/BjEQg9wTeiLHQiyyAYzIRohzXII4luMhHjkBEpB7QS/k3pDo
+BV3XQwnQRJyMiQjp0AKcir0cfwCfSANOQ36IvdluR/0Q+4P/R0/QzoMQB7AcgZkIGdCJnIWZDku
QjbkIOfAQOSBLA+CQciDYbDjJ7gH7kHOhSHIQ2Ao8lCWh8EwxwUYDsOR82AE8gjIR85H/hEKoAC5
EAqRi6AIeSSMQh4FxY4fcJfCcAmUII+G0chjYCzyWCh1fA+lLN8L9yKPg3HIZVCGbILxju9gPMvl
UI5sBjOyBSzIE2Ci41uYCBXIFSxXQiXyJJiEPBkmO85DFVQjV7NcAzXItVCLbAWr4xzcB3XIdSzX
Qz2yDWzIDdDg+AamwBTkqTANeRrL02E68v1wv+MsPAAPIM+AmcgzWZ4Fs5Bnw2zH19AIjchzoAm5
CR5EfpDluTDXcQbmwTzk+TAfuRkWIC9g+SF4yPEVtEAL8kJYiLwIFiMvhiXIS5D/AUthKfLD8DDy
MliGvBxWIK9APg0rYSXyI/AI8ipYhbwa1iCvgUcdp+BRltfCY8iPsfw4PI78BDzp+BKeZHkdtCK3
svwUPIW8HjY4TsIG+Bvy31h+Gp5BfoblZ+FZxwnYCM8hP8fy8/AC8gssb4JNji/gRXgJ+SXYjLwZ
7Mh2lrfAFsfn8DK8jLwVtiFvg1eQX4FXkV9FPg7bYTvyDtiJvBNeQ34NdiHvQv4MdsNu5D2wB3kv
7EPeB23IbbDf8XfYz/Lr8DryG/Am8pvwFvJbyJ/C2/A28jvwDvIBOIB8EA4hH4J3HZ/Au3AY+TDL
78F7yO/DB8gfwBHHx3CE5aNwFPkYHEP+ED5E/gg+duDJ8ifwKfKnLP8d/o78GRx3fAjH4XPkz+EL
5C9YPgEnkE/CSccx+BJOIZ9i+TT8A/kfLH8FXzmOwhn4GvlrOIt8Fr5B/oblc3DOcQTOw3nkb+E7
5O9Y/h6+R26HdscH8AP8gPwjXEC+AD8h/wQXkS8ivw8/w8/Iv8AvyL/CJeRL8Bvyb8jvwe/wO/If
8AfyZbiCfAWuOg7DVbiGfA2uI19n2QEOZMB1FKgdYrEYKIrHu/Pbgsgtid0SH0DAnG5FF+xx4MCh
q5BIJMDj8fh3nqNz3krcEk5YgYCbtxw4/IcglUpx3vK7MG8777JStyTEPyF7caEL9jhw4NBVeHl5
MfNWcPuUHei8y3q5Jde87bwVc/OWA4e7CJlMBnx+V+Zt5122c97ihBWJPOdtF+xx4MChq5DL5Thv
BV2YZ52zVe6WcMKKRZ6P0Ny85cDhLsLb25uZt8Lbp+yArDOvW8IJKxZz85YDh/8QFAoFCATC/8d5
K2FemL7pBWYOHDjcLfj4+DDzVnT7lB3ofDru/IQdTlip5KYXmDlw4HC3oFQquzhvO++ySrckZd5Q
8py3XbDHgQOHrkKlUoFQKBTfPmUHFJ153RJOWC/pTS8wc+DA4W5BrVbjvBV1Yd52Ph2r3ZIX80aw
59a3C/Y4cODQVfj6+jLzVnL7lB3ofDr2dUsy5o1gbt5y4PAfgp+fH4hE4i7M286nYz+3hBNWLvN8
yYqbtxw43EX4+/sz81Z6+5Qd6Jy3/m5JznyA46Y3hjhw4HC3EBAQ0MV527mrDXBLzJzl5i0HDv8p
aDQakEikXrdP2YHOu6zGLSkAfBSeL1l1wR4HDhy6ipCQEGbeym6fsgOdd9kQt4QTVunj+ZIVN285
cLiLoGkapFKZ9+1TdqDzLku7JdzzqlWej9By4MCBw12DTqcDL6+uzNvgzrxuCSesr9rzjSFu3nLg
cBcRHh4OMpm3z+1TdkDbmdct+eG2189z66v4d9SNAwcOt0aPHj3A29tHdfuUHej8evzOr+cNBAgK
9HyEVgIHDhzuGmJjY0GhUPrePmUH3D9XAbFuCZ+dQzSeL1SpgQMHDncN8fHxoFSq/W+fsgOdd9l4
txSKj8+hni9UdWEd4MCBQ1eRmJgIKpVv4J3n6LzL9nZLNEA35nQrurAOcODAoatITU0Ftdpfc/uU
Hej8SbsUt4R73jC95wtVXVgHOHDg0FVkZmZCQECQ9vYpO9D5U4oZbikSH58jPR+hQ4ADBw53Dbm5
uRAUFNrt9ik70N8t3eOWegIYmNOtoP8ddePAgcOtUVBQACEhuog7z9H5c8r5bikeoFec54b3jn5L
mQMHDv8axo4dCzQd1oVfSh3mlsa4pSTc7OKZ6lZ0Bw4cONw1mM1m0Ou7x94+ZQcK3VK5W0oD6Jfm
+Qgd/W+pHAcOHP4KpOsXytVAMRIRhKeg82fLCZJk0twIjKS68iN+RrfUeU/OAhg4CHfYbkVRFyt+
p6D+tWw8KAbmk18KNEBCNxgKo8AEFqiAOmh1OIDZxTt15g6d46sbjnK45S/Ip6cVpqYkJyX27pUQ
H2c0xPaMie4RFdk9IjxM301Ha0NDgjVBgQH+fr5qldJH4S2XeUklYpFQwOdRJAExhD0gs3hLoDBa
o9PpSnq6wkE3hu1UuOKizg7KGxJpbsoUfFM45KZwqDs8zA5qe44+M4sxvAVyztpBZSfUdmBKIVRD
sSRXpmzzJH12pT0w01xWhjmy9ArannPB4KoKa3uLVJKpz7RIesbAFokURSlKmNa6hcjpR7ACmZOd
uoUEkaxnjF0ZbSfDs5lzkj19YRkK+iy0hDGqzpgdjrZFnlGA2ToklVMi7IJMu5Atl660p5vssJDe
EtPWsmiHAsaXRXuZ9WbTWPScCeu4Bajw7IpCxo/ZzFlWQdt5aJwlDWro7Aq6Rc+4I7uiDFmfhblu
qUe1OLO4WdemsSvxmm33ibYPxBQD7z+joVqyAyppJtjS0kzbW0cUe8bqGC4pKQnACrdk69EgGsue
lIFNCTD0jHG2yeUAc9kkpsxJJqae2ZPoloUWtq6L2DqwSbMrsGNMt0vV0pJt1mebTeYMp/VMe3oh
e4HC0cVsA9F1WSUulSsBxvDYmLKsEp3T2bn5xZlMxfSmLI2z292aMpcGFdkdkTRTg8FowE6X03bI
L9Zj0mSGLMnQUp7MDh5dCYG58jpz2fnhCj3d8ivYiTJ9+/c3akwujSBc8SswYo4+p6ylJUdP57SU
tZh2OBrH62mFvmVLbm6LNbsMS80rxlw7HK8t1NhzFpXYFWUVRCr6nhkBOfnF/TU6n5KOYF5HEHBI
4cCSss1BL+DfYNcFvQyFxToaHVVUXKJBPxUzciHKziszkHDgJmMfu9zG+MiS7HZPpkvU6ZjRuXBH
OozHgL1xRLEzTMN4zcuQbojG/ihjYto6YnyLmJjGjhh39jI9lrKNXZh87aII95+3wk+VXZFqJ/z+
SbTFGW9XZRZTGrLEKZEaipEk0TjT0+z+0ShHRrdgJxzR2xXRdn5xmyathFb44ArA9F6BPnfE6GI6
u8U9CpwaV0uZcYBDXW+qaHFNJWbQ4/AgsIPSMwfpDZCGZmhGkWNP12cY2BjzKbBTpzACF42MLXpi
wYgt6cSCgtHFOxW4Ti8oLH6ZJMjMsoySLWEYV7yTxmWY1ZJuLROimRDkMkP1ZVLERml2pgM0srE8
VsGGy3cQwOpEHToCyneQTp2C1SF6Qrq48Nw3gdqz3wRpsaPTH3zHPzDxH99FaL//LkZLf5b+GTn8
8LjD5LuHlNraQ8S6Q5sPkQeXi7T7t4VpH1+bpH1sbbz2UTzXLovXrlll1K5eNUj7CJ6rlvfUrkTd
imWx2mXLc7Ta5Ybl5PJltHb4snHLyHXLiPRTp06RipP0SRJOKk4aT6afzDtpPSlI3y2WJjL1yNvl
pUhUvEak7xArEmG7Yju9nSp7xfoK+dXXeu2Zr2kttBvby9qpvI+J9I/yPrJ+RF2c46u9sC1e+yOe
67YRnx+P0R7/XKf94kSs9sReJdO4rR/KFaxxx4cSReKxvSLtUYzwPqI9YjhCfbA3UNuG576Zudo9
e7XavbNTtEsW5WoXL8zVLloYqW1ZmKl9CM+Fswdqn5gXpF0wL1bbPK+Hdv48s3buvDztg3imz0vr
mzgPM7Y2KbVNjbnaObNztemNA7ISG2dHamdiYPasbK11FpE+a0BmYpS5jznXXGIuM9vMAoW3Tuvn
20MrFOi0gQE9tDxKp1Upe2hjenr3iJZHRnlHdJeHhXt308tpnXeoVq4JDpEFBAbJfP38ZUqVWuat
8PHyksm9xBKpl0Ao8sKHHy98MvJSeDd6k+mCRgGZTjVSpDduXYZDesRs4HmDAQO1MBv2wQfgAJGm
j0jrnSrSUikiLSSLtHkJhF2ZC7mFGXYVgdeCDHtCdO4OEeTb46Nz7eK8McVbCGJJCWrt5AIcboV2
3gIcYYV4Fxk9pngHEchEz2NvKijtIBrnLV6scUslJdEhdnNuQbHdGlJij2eEh0NKIBpRb6uvr4/+
C2wRM6Wb8zO2nOcxtxyT/bw+a8u359nbj/1bfRZhN+PEzKq3z8qusM/SZ0X/panozihGYAvF08bW
AOpt0Q03JrZFd1QLQKBmvsOFf5T5txon3/BoVurUOE7fyNfNjl//tYe9P0MEXf96Y+IoGXWTZmKX
Cz4Kb8N+2Maeb8Bu2I7HS/Ak6t+BPahjTiscgI2wAbXLYBOshydgFTzDhuYSJOYC2AwP32D1IXyI
Pw31KI2EarDBHFgEK2Ad5hqIuvkQB8kwHUrweB52YFmXoBUehwUwDcdwIzTDEngUNa/Ah3CeUME1
QkkkEGlkMJlFriNCSAO5lKrH+ryMNdlMjiN1xHriGuZaiXXbBlPQwiLKDt2xTo+RdtKB9XwMhmAs
Voq51QiZH1yh8KLeLiB5wJyG9068x1KcUeej8wlHIjDV5UY+XGGu0MhsP0hsPZDHcYQwufumR5LU
PiCiiT7EUGIcUUvMJgRoX/iBQTybP1u8lM/jUxRJCg/zwXAt3tDfSBhK8ZpQ2nytLU5M6FWUPimB
PH69/fkTTYfjDvOPXjnIS7ps+BBrGUcdpdoFarYcQ7qGomWKJCFDAiFaxC3GMZLkHaMFhMBQ2p5g
aIf+CQZlSkqckYiOJii9So8n1f7q3LKNeArU1/aQmcyJt40cHO3vYwu8YHP6XDGJGyuxXBpEKii1
WCulKT0vShonTpFmUenigZJ7pON446RVvEpJrXQqzOZNFUyXzJZqxkumkzN5lBfMkZJCERCJRA5x
L7Z/JrafkIv5gkahSChLEWVECBOFOcJRwilCvlAml6UKX5HxSQklns0jeFLgUUIxhe3rr/RPMZQi
GQnF2WihovRMtAJd1Eb4JBhKm9va0FtQSpTq9OgzitATOhWh4085QERc2zDl2PVju4hiQnGQzCJU
vJ+uPkfNunyOf/TqG1RfnA6EHmfVaLa169JHdCcMVKw4EZKIVFwWc4jB1DDxKGqU2EJUiWeQ06kH
xD5SXHFb0UuEVNIkpkiKJxLOEvAFo/kz+CTFF4lxPSYFFN6GSYoSwA7Hl+nBEkWSBHdtNLPxk6fL
rXKSz6cFRkG6gMLOwRYwrYhWphgScIlmmoqdVNqswPYpmrFpbSiK2ohSZ9uoBBWBf6LR13p/HXNt
7xd9D0aSA/HM5R+9bOAdvWLAQRLD++gKzTuFo7G74zRvNG8atq43LEovAYPKEOMbbkhV9zIM9s0y
FPaY0GNKD2kweMl6h/YODZ0f10sdF9crMaVXRlxiUmJqVJRf3GtJggf90pWBSX6wpkdwQnBmMBUc
3FM1PIqIigpf3VPRS/yIyg/6txv6tzNNwWaUtuM4jm5XnPVJMWBnnYlulsdG82cq3myWp6Xx33wz
zoidJSeEcsJX7ZcQn5gkZAP6bhG9e2GpYUn9iN69IrrHokYg1GMoIR73njiu9dSktT8OG1E4fuKY
PflhmlJjwqz8ec801N9H9D8sEEXo9aXJRcezJOEpX1iOHBELNu8ihwr0Ot19hYOGjEh5XNHH11/7
2Mx521NTEgTBUX7GNKVSlqTZ7R3RtFjTV3NNgv4qcpzm98BZpQI9zEsfPThocLdJvNkiq88MjUCp
1ut1FIljZj6pUpOkKixFlRFB9iazyZFkA8knw8LDUhW4fuDzVi05m2wkHyYFJBkuEQeJyZAHxbvC
VOC/yltB0o8IXA7DCa+41M72/33OYd0cG42OkivSRGnoLBzV2OtJLt8ona7wV1FO17j9x+9xfc1u
zezHxjy50zyy6FxTyaoB1pWZcwZXbEjtnVI5pXDzPQL1H983jOp7YN9ThLZq8syICOLMtUa9zjxq
+MmK++cUxjMrV7HjLK+JNwPEuC6Wp8fzlAq5WlmgKdPM9rIqheI16f6Ev79EsEah0OlCVkv8csSF
YpuY0ulUMrF/EDVPxTxrScXeSSpVVNCDsl2Ril/asWXR7T4pKeywAGaE9G9H8b72OGMpwXYz0xCi
W1hvBeicvaxzNyvBOS6oNj6vYc6SL7oTgnPXfyfmEqF7D/morh4U8Dc9WXN+uDQqPq9fvzJyY0hk
wORp9oev9Tt+DO8F2/e8ENo0MiQ5YPFTIxPfVYZ6eytw1ibjvXo19m8grN6epMpRjVRRATscx9NH
i2VJgb5R6ijfSnmF7/3yab7WAGugmC8SzSd4aoLgeXvL1Go/lUKlUMz3Uap9fJQ8HyXxGnqHCEpR
ZkT49PbJ9hnp0+DD9wnSBKX67AzyesRfoQS+DxgS+vdv71y4ShWXmtuc3SwUYTfj5AhgZwd2djRR
SrADXeX2DaUnEii233mrxaKNu1d4yQqqhmwftX83MXF30+Rd5cs3UPcG5GuvRZMzeg/vXlhUmHp1
L67n7+XmrQBni6nz+HyihJr0oEBZojRHWiTleQmFfJFUis0TS9RisUTJ9F2UWJGkVKqtakKVIsmI
EPcWZ4tHihvEfLFKrUoV71Sh8x7x9pZ6i3FF7o/3KY9GMR3tbpQ8LQ4boneOUmxMgtA5cKm9ksjs
uHt3Fm3b69gbMW9nUVxMD2q1RFyUdvUbXunTpYP4zO8laV1HAd6l78bx258PYsItjuvMQc4gf2AO
auItjjbu4A7u4A7u4I7/xYPdiedQw9zvCzH/AumUCdxXxrtkEje4+10yhTvzzS6ZB3LY6ZL5uMc4
4JIFqD/lkoUw021HjPofXLKMGAJXXbIcepCDmHf7eMw7W3KyySXzIJSsY2U+q291yYz+YVYWoN6L
3OuSeRBMvsTKQlZ/3CUz+kOsLGL0FM8l86Ab+QMrM9+Hb6YULpkAOWVzyZiet9wlUzCeV+OS0Sav
ySXzIYDX6pIFqD/ikoVw2W1HjPrvXbKMXMMXuWQ5FAqdeSUebZd4tF2KerWrLbglhjBXW7xQrxDx
XDIPaOEvrCxHvUgU5pJ5ECBi30nlKRj7ojSXjPZFMaysYvWjXTKjv4eV1R4+VHv40JdNP80lM+kr
WNmP1a9yyYx+PisHMnZE21wy2hH9jZU1bPojLplJ38bKIR7lhniUq2Xt/OCSGTsnWTmMsSOWuGTG
zmVW7smkF0e6ZEwvDmBkkYefRR5+FnnUX+RRfy+P9F4e6b08/O/l8v9zdLzRmEwPrSyvq62vnWCj
M2vrrLV1JltlbU0sPaCqis6vnFhhq6fzLfWWuikWc+xIS53ZVGOiK+tpS6WtwlJHm+g6y8TKepul
zmKmbXUms6XaVDeZrmViPIITbl0KXVlDoxm6qKbShvkLbCabpZ421ZgNaKCWLaC8tqHGVldpqY91
W0jtqMZgm6mqspwJ1jPGesca4+lId7IoV7KezmRDTTY0OJXONNVhbUtqG+hq03S6od6CNcD2TKit
sdGmetpqqauutDG1GT+drVt20ZABGFvHBqx1teaGchtT76kVleUVHnnxWllTXtVgZhxRS5sr661V
WAA2BnNVYoJyTGWpscXSHWXX1lRNpyMro2hL9XgmU6epmo7Et6wRm9xcWTMRfV+PvilnXOlROutU
l60+bAUiK7EUm6Wa8XtdJZZqrp1aU1Vr8iwU62xy1hS97nZ/bYPN2mCjzZYpleUWJk2Fpcp6U4Mq
bDZrqsEwderU2OoO58eW11YbbNOttRPrTNaK6QamiHoDjAQL1IEZTFCDJw2Z0IDheqiEKRi+OXYy
G3s/tP+TWGfem+NyPeJqkW0YvjFNHBghEWiqldpFbaK2UjupLfAc5oxHvRH3ocynEyqhHHPUop1a
mIA2mPrWosbKsgk1lSjVQCzGDIAqPGjIR91EqMC4ejZkwStT7hRkM6a8uaaVbDoLW8cKNo5m9XUo
T2RjbayWyU2jXMd+YsIC1XitQx/QbF2ceW4dO6FLbWFqVMPaYmpDQxGGKtk6MOUXoGRiQ/VsmTWo
NbhqUOvRgnIMNWAsU6NKNnXsLeqQ+idvDGbtV7EpO2Lr3TXrjVaM2EM0RN7CWtRN1nreYG0oW29n
DaeyrWc85PRtCVtbmvXadLw2sH3m9IGzfyawNbCxbWbCVjZfNeuZDt+MZ/N2+C0bPTcER4Uzb51H
jJWttRlLKWctOv09lS2rHPnW5TrDTNpybFED28vOEVGLbGbjrRjjbIGzZ5xlVboslLtsWVhmxuzN
7Wbiq1gpEnNFseOyGtvVUdKtalXzJ8t37qNO62bW0kTXuK93jZty96i8dds7R+qN9erj4QGmJc62
2NjyOsY7Y9/ZVjNqprItr2Vnz61b6vSz6QafWlzj/ubRz3jVhuka2JxMbaewrbG47TApqzDFP++h
CtZzVpwJBjymskcs69EbR34sm7Ma09iwRUwLJ7JttKKF6ajtaEU9/HkF7pwj92F9LX+KzyJGYKzt
Fit3rccK+9frugVL/6vVeTq258/rOlOj065Z+yfLvCBeJi+dN4CXzIv/C7t/cb8gjO6WTv5Tzjyo
JUxsP9XcojXZmPN+V4j9QJzjZzyHwLS/eA+SAubJXQGEw+H8VCD7Dd9+4Pq0IPUKMs9j78L84kYv
vBsRVSZbDebFZ98hhYNo8MsfPpRmvpaJ/bzcDezOl4z3mFvnC/XIQbivBJBVteVVIGdZzdohXNZI
di/kDClc1wjmeRJ41ENUC7WQWoQhEv6AyxilJWg2JAKCWsxasbmsuexpmHdvXd8hpRlnbNKMEYh7
zB80/zcZISRbmzRDUDWIJIg4qVEs4EfLKTKID0aTQBItIHhEUxJJ8FoLjCOMMR6a4PWhjcGQxh7D
cfFgpkAVdhczafoxh1HnYYyn3ifRnnl9xm/J3sceDbpwJcEuMYV819rk18PYxFMam8jLrRRJkKQ3
bhgXpqUt8Dna71L591+mG2XumjI7OKM1LtoYJaCKeFJVt8xa6/Q65rmYjiyPouNSUpJueraNjQs1
BjsT+97yqTdOZ9Qy8ZQqoDM+v7bWRg9osFXU1lXaphtD/WUpSca4OKMxyYgY7S+LN8bFJ8S5gv+F
GjUR3TzdQvCBaiK8AfUSsokg4Dlyz37r2T4Xh2ki162edq/x2/XPLQ4f9/v1R4Zs2H79ifV0vxkj
1j+2fmlZ/OSjGebpP2yacrDw+MXvHp8fvHTd3Alb35p8/3j9JyFpJ72J5edWvbmv54S1aysiHj2S
GrPP65XiiP0530j6Ja+KeS4yZeP3gx/M+Gqu9661VUWmTU0znirrOXXI+Ue3mfuszQuOE4Wp1z33
zbLogLN915Sry4r5lnUhSfnNvz3740rybc2H+4qytz7UuC/1+8KVw1669uz91bZhmwMOrxJH6mDU
w2WVSbtylcK0kY4xV/42QSJ65tickaN+fLXPvX5zpvKOX9r7UuMj1+3vzf7k2aC6sWmHdl8Qbehm
3CqYd3ArPVU170uSwoG/Yc5G45ynjXPWozdDCN6ctcY5qxsVY45Yf6yse1I/Ypb65aFLHO8+Vfef
77+m24xxiunDR85J2xb/vDqgd/sOIuzvU31+HlsWv+5J6bv9+MsWLD2YelZ38cKoFTGvtA48MP7H
q58e7tNn9HOJhZXXw6r7Hzz8/En+jBNxi/uuU1gn7bquHB5Q2Xb1SOZXPqPp4d+Of2Dz84EHopPC
e+61PKVsCfcu3/BbYfAfuoOf+P6cv6kmM154rcn/968nVslGXNrzU/47e75503iVjhMvCHkkKmjo
xyHk0z81nqK2jflly4kDo36wDH4nv/DVbVSk0vHwJxdES2ftWP3WC0kxZ+4/s3HqV1Na4cik/vuP
JbacGqDc2HuSZtLnvU9/FMw7szGbd2B0QnLN0GDZ+O2S9Ys+/Liwf857wUXPWD9XpjavaFj37LFW
XBXKjE3UEOeqIIl9weeLPMfYJ95t61hTQv5biwHO++R4BK4A8bgYxMVjsHfHYjCdXUHRiEBFFhXE
qYw+TECkkowy1VfgPtGGxSiMckYpVAnzLebq2hpzR8Ukf1UxvVHnrFiQZ7zZQhdUTqxhdp95mQNu
uypsnz7zk9Kt2Skbe22KO/5HeO/BU9uuaJ98J/u+H4/mnPto0RuTh+SP/+VR8o2hfx9cZQjrZ9n3
vn67dND22Q0nsvc8v1Se91Z49MXWb2R67dEBYZfHP/pBYPbTK+7RPvreVkO3N+7pOaP2M9/QPotS
FCkn9kT9MqFPTyLecb37oGdeqSKaH7/y2svls5v+GNs6Z+68JfaLO1Zu+CD5mbx5/t2bh50wXoK+
v7z9R985e+e3V6U8G9vr0rbYzZKZ45dNm/D4mnrZ/M0X3/yZ3jlcubj83ZjP4rMDf9h1z6o+eQUB
708YMf35F5sPjOy3rilvQQ1/S+/9D4TtyZ/Q99Fhh6NnJdTMHSg4+uSRe+aTNfPhb23NXxa4VoXL
xjm/GVXMohDO8zJKBCK8ofH5Qor631gqvJk6qgjCweMbKbwYQxiFnOfHUx8OeX8KWMds/un4m8PW
jsiK3ZBVfsEoZaK9ecwn7ud7TB12jXnghZdm3RNx8f3dw2zri7vbejRsnX/thSErp8HQ84e+C/ii
8i35+hk/k5lvH2o+/HvB4dfX7RlZe6E867ks+GHVgbUfB++QrguUrfz0eOiLUTN/bH+mftPSkylL
+q6ZtDu5+tiCzfprX57/pFK8bMGe66dhV6+ff5vxh0IZy/8uatWKjMmR921PXnpKKDtYWvHensYB
kyds3LV915Jehy5Sihn3/3rsVMaXD1w/fXrT9Utffizbav1k+VfDX01eP6PnR30/7yUdn0SumzNJ
/9ClseVL7aN3pXxatqhoblDCr33WtDZ5rR+3cGvM9qeefveF4/Sr+4yB82i1rMfu/F8GnLrX+NXy
yMrm/dZ//PzsC+83ZtRNkeMaMwnXmHzXGmPynjbU+dDoOY/4uM78F2d1x4KTYDTiipOAC44xxRjP
BBOYoNF2V6rmiqf+Iv62a836zyWLP3h9/+DH3ns+tdeL+pLJn1ft1XXbvvLAty/te/vjiNfjfRbu
Pl4acyVxZKhv9EtLZSfUG2oih8z26z9g0+L0LTkLZJ/NWfniasGRUVlTxn7701X5/1Vv5vFQbn8c
N4xlbNmyG8aWasoMI8YyiLFnMJKK7IrsJmSfGaNkTZI0hBZ1M5Fki2u9tixNN9lKlutmCVmSpfgN
VzeV+7u/1+u39Pr9+T3Pc87zPOd8v+9zvp/znKEI3A3FJ7iR6WGH7HCGEvRaJ4qns6DlBMfTkNkS
Xo6P9u5ypDNxJZQK0qhAUdLP7/mLHW0nuV+rTkGOx+ZH+tehhy/HBNpfe0MJrFGOV+ST5+1zbL4v
fBeTdpLyXAIJ8x2IP6k31CA6z2GG05YfZZR2h5w2LEiuL0Q2HrzlaSNodC+xK4GICmLV775ZGCVV
NzQb4vrACFcpq21MduCzN4U1EeaesvmETh0+FPiM5XAAfpM1izD8+42+F9uxHrG0IGSq3hKwcxCt
hFDzRUvjtBGBLncignG/7Oj2aFrnhJgUUBDGH7l9mOuu3yAO1ICpwZBZyllK0YqbUqCTn8c3UqDP
abf1UvlNAdVfXgdLc7T9tCKYwedH0tYh6jBVmMpnG0YfDf1LbXGjQRe/LS3hvgmgDdpoHfHGnsyU
ICIAnL8LGKtTJrrxEVMcZ3GBmCv6gnN0O93C+xyTcj6dzCb/Jrd7+XDX1VWzqhOgh2W3JwlzaWDv
o8vvZwbZf41lQfELSFCrH6H1WWTtj4CMU96xtJYf8no3ZMAjpxQL8XttV5zvxiOdMjWGAPWFe3kn
s1q07DEx/EkBGj2a3WorW1GhPnC8kMhWriSKiULrrz1OyT7KfDf1VVDlkYhbuaatsxRyuvbQExtp
1MsIhL7pQkdTSMZEcTPZiQ+bT0mf7qrqyMq+d7kleO85aHVjz0cPht4qFcoM1UZIYEf1h5bI21ws
wq+SpN4UZJugxgu4ZYM4a6BlN083JqrTaJNBow3pM20MQyf/2AD7cbSxdPN08cc5ePpspc0BGBJ+
AAZXUlLYWN7AN0wF2LoJw9/+r7zbLpjMHxMl2EvHzWdd7NbFoiXQWFNVOExXZZ+SCkJ5n85BPZXP
NzLwgv/iI7Aufuvy+N8Caryc0amp5+z9KF3UrYf1kyaZ0q+RAWDQCwUj66Bne3tuMSdNv9FYqZQN
vbEyEhau0NGjEYtUnl3sVkPwP08mrCDeniL5CScOlJoMlJLmFFnpa3IC/JVMbGdKBo3CxEpTgvrW
wKSdB/V82yN2HeGhEjFqHcv9C7GTmnTDnf0OSwLxxjfx6u/dtMYHY6qYMeW4kDH2Ef3xex4znSfx
LIv8LWG8j/2HQCbLjiuTWch01dUJ7iYHsKN1N6slsVPN2HjocKW8vXBCMqNOr+0EgVXqCiiLEe4S
e8kUrA3JSU76hNZFeys9QCtT3O66LCF0HgjUqiEHueJmhc8NW5qJq2XAKVsB9QVI4X7v9mta7R6Q
+XCqFPDReDC8Yxj1FXu8R001r5Qh7hlHJ1aQx/PUtHUanv5b7MH5+zg5/EfY87kl3HYEZfmOwtsA
yi2YAGLnp/Z36MXsr6IigvERu+S098z9CknmvEKxw57YvTRZY2l0J+wD71M2vqVDs9E76byGiWJy
6FwoUuGVd7rysSkpi0RLhnjNXLKzysKBJj6dYlVUWjNHnS9ebs41Fz5kY5u4ZGExaDNxKSnDDWQS
Q6UGmCA43AdDdXP3HidaRqClhWTqL+j9IjMsFOm2m29BoOGdJBSvd2Lv/NLthkCUlPfSbWdSQo4j
x9194DsjSaiItYKEj1feznwC5rcZth/D5S3P8YqLINtvFL2omC+aaqLMWoFX1GeaXuzRragia4a5
CrYVSjixtmhpuCgIhRaWatTIGphKCl31ioPVzFz8GlBc7mxXMdV0Mve4+9Di1sEnc77F1I9Jvjbp
BEMglNfphKSZPyD5+g6cf8ebl8peK/lNB418BZvaDVDY6uV7fOVQhcc8GIsm4iRKsccQnixXfNF5
QNwsqrzWmBrBuDh95ufYxjud9918XIN2uY4Wl0yTytqmfvrEc5PtqORu+Q6tHiugSMAjT2dPI8u+
VzP9VdeJjZGvI0zolVPeV2eyWIFP6bf1VAfYyIcVywCLrI67izqtRYaqT3UCZQ4hA3HMtrU23dHK
0DPNnONgJCg0YDXDwyt44C0q8UqmL6fdHoygo71C5jOi6V5Jm1Po2H75KC6zwqVHwvEeUzLXeBef
cHWROOcJAf4HGi4H57TaM71lLIhWLFlMOR6lHWVNSvEqEIcatHqTdQbcRyNkE07/wRsCQI7WI9Lb
R+j/RfrFxQTaFEB3AjZOMW+h57ZwFPqzAh89kB3MSoelO0PnSKdDp/11avZdXrcNoFIOccNrQ80e
cydkOzADOON80PHT/paVmiDGfWul5liS6CTyYskNK7b+uGI1EepKXm5zyQNziIg3i1v4aYYcSb1J
jyLPUMlSvV+j5uJ3/Mx84UDNRPiYjy36evKz1vZXCdWDVXvaQt8231foPFf2xKn+AFUQUhXQr5b+
UMQ/E3K+u6iIxzJunlzrYpQuJ0u2v7BDrZHXJcjgcQeFqIopcLTuh42NIcWGY2Z7kfglXkicc6QT
EzB1Np1eRz5E73z5Gn2Py5JRfy8D7tJDRi/21oyXcg6hBjMCZG6ICr3ouTymX1IVSke0GrAalXdj
+kddlePnJVPJrQWBluaqL/x0C6UW4ATgDRqkrtMDADD8uR+YlX2VK37RuLPw7TC+P8dbDgBnZmDc
OLS/7gWbgwligLNvldVpb/PFYoNzwrZe3QmT+lIRCKf52EIJZmcpcHmafOP34CCimVQHzjwSZr2l
CjvcCGaQta7M/5MN3WzZSOl/4VcBiW+QBiQA6DLLlvtkyPpzcfWefg/q0YdrjzWIQM1V6Z5XB3S1
WRmSZJRPHz1jyLsU5aHhdov1vGLyKYPphXymzv2aMmNKZ2u5OisB/uHVT4VaJkpq+BymTOmPcVwY
m9cST8u/XpdRVFXFFQbPaqlP521n840Nql090sXKihWQpnpYTRkkHkGp72o00sBin0Mj1IINMbud
cyQCh6+N6EOApPiusFfSa5msbakHVXxn7C/Ig5o+WYtj0dhOltWQ5TVB7VF8yOXZshVuzuTGTEZb
AIVgP+LiIgZNIZsnVpiCLISlLg5LZ7pMp/kS3X4zmSpsNLd8s5SxavdsjR1Qh39LhdjBh/h4DYqy
CfTiMAK9yJdxYYIT6NlpRSz/c7f8dhb6Kqlg3nTLLFuY4FbvY/uy8wOgPfPPK4zwHbTpVQUOU1yf
TJEKSse+c76AEz15ZxmDKsCr1uBLTqZ5omT5gm84te4iTDJ93lqKGIIUSkLx2nC63lUGDP7J2tlb
551z26hsupdEX6ri69QCS7NuZqQVNDMM/Q5ywAzXtZY6mIsJ3IU+11K5ELqPvIKAHk9IeU3U7XrC
bwwMHjBSss4sVbofO2b3iVoblxSclhj/wgNNcphAcz/q7pXINrTb507p5YMzkWtYHzSkNonrOEBZ
vahNhxYspCILmsGPTzWnoNbC+3MLGSUd++8n9Nq+Cb1KJxKDA5j47IjBDULwAaZrkYiqYzx5SukH
PT4w77UhVEbHj6cBW+sVu/q9HlKFS8h3TEYmAKzh4b6HuUeUplILnkqZlmSSOrJnOLRue96cxr9/
3elqJ0L3Dw8XazsNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5NDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0
ZURlY29kZS9MZW5ndGggMjI1Pj4NCnN0cmVhbQ0KeJxdkMFqwzAMhu9+Ch27Q3G6Uw8hsLUb5LB1
NNsDOLaSGRbZKM4hbz/ZDR1MYIP8/5/4LX1qzy35BPqDg+0wweDJMc5hYYvQ4+hJHSpw3qatK7ed
TFRa4G6dE04tDUHVNeiriHPiFXZPLvT4oPSFHbKnEXZfp076bonxByekBJVqGnA4yKA3E9/NhKAL
tm+d6D6te2H+HJ9rRHgs/eEWxgaHczQW2dCIqq6kGqhfpRqF5P7pG9UP9ttwdj+/ZHd1Phb39p65
/L17KLswS56ygxIkR/CE9zXFEDOVzy8cpG9rDQplbmRzdHJlYW0NCmVuZG9iag0KOTQzIDAgb2Jq
DQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzMTUzL0xlbmd0aDEgMjgyODg+Pg0Kc3Ry
ZWFtDQp4nNx8CXyTRfr/M++bq/d9QDjeNLQUeiRt6QUFCj04yl2OFlGaJm+b2DSJSdpSDxYQAQuu
7Iq6sKvgjSgawAPwRlHU9Vp1F0TFA491xcVdkfWg+T0z75s2pRQDH3/7/33+8zLfmXfmmWeea+ad
N00AAgDxCAoQKmunTZn4zl/iAWozAbR1M+bXTlXw3KcAykqk+nx2rSE/7/XjZgCyHe8XLqycWdf6
attCAFU20nxkbjW5GrL+WQ2g8yLNYnO7V3jIcP/9AKNXY//YJldz6wvfjfMBpL2JEy5tNnlcGj2E
43yJyC+x2d7Z9OqMK+IADM8izxesltZlj3ZfvRggMhIgyWoVTZYj5KUvkTfOB0W0IT4h3I73Frwf
YW31Lpu4S/EMAIe3fKXdaTYZp+Q+j6Q4P3mx1bTMxesVp7C+DgkEh6lVXFC/9HWAkhkAg+9zOT1e
/zhAXvO+o/0ut+ia/dLIpQAjjchvPlBbKVG68I9sS2PKTmm0GqDpnp03ddPyucl/twJ0zwk/ps7D
20hGTxOW6rzuOQARGwD8b4Qf6+kJpGdZyydwKWhAjeJzEAsGKMWhXyuWYh9e6mFkI86uUbyuQIn5
5EAJFl6IpGINkGbWCgKUnxROHlZlkbshT51HfCt6ehUA7EYl32smwPSwTNg0ILv/Y0nzKez8b82l
/t1/b67/K0mt+/9PZ9UlsJPmX5HlJ4TgEj17VZ8nnYf0Arj8SoNDF5wqSVWNhP9o/HSv8ndDGGgQ
wyHMfwYiIBzrkRCB9SiIRIxmGANRiLEQjRgHMf6fIR5iERMgDjER4hGTIAExGRL9P0EKJCGmMhwE
yYiDIQVRC6n+H2EIDEIcCoMRh4EWcTgM8f8AAgxF1DFMg2GIehiOOAIE/38gHXSIGZCGOBL0iJkw
AnEUpPtPw2iGWZCBmA0jEXMgEzEXRvm/x714NKIRshDzIBsxH3L8p6CA4RjIRSwEA2IRGBGLIc//
HZRAPmIpFCCOhTGI46AQsQyK/P+G8QwnQDHiRChBLIdS/79gEoxFnAzjECugDLESxiNWwQT/t1DN
cApMRJwK5YjTYBLidJjsPwk1UIE4AyoRZ0I14iyGsxH/CXNgCuJcmIo4D6Yh1sJ0/zcwH2oQF8AM
xIUwE3ERzEKsQzwB9TAbcTHMQbwE5iIugXmIl0Kt/2u4DOYjLoUFiA2wENHEsBEW+f8BZqhDtEA9
ogiLEZvgEv9X0AxLEK1wKaINLkO8HJYitiD+HezQgNgKJkQHNCI6wYzoAov/S7gCREQ3NCF6oBnR
y7ANrP4voB1siB1wOeIyaEHsBLv/c7gSWhGvAgfi1eBEvIbhcnD5P4PfwBWIK8CNuBI8iKvAi3gt
tPmPw2poR7wOOhDXMFwLyxDXQaf/U7gerkTsgqsQ18PViBvgGv8ncAMsR/wt/AbxRliBuJHh72Cl
/2P4PaxCvAmuRdwE1yHezPAWWOP/CG6FtYh/gHWImxlugesR/whd/mPwJ1iPeBtsQLwdbkDcCr/1
fwjb4EbEO2Aj4p0M74LfId4Nv/d/APfATYj3wibE++BmxO1wC+L9cKv/fdgBf0B8gOGDsBlxJ/wJ
8SHEo/Aw3Ibog9sRd8FWxN2wzf8e7IE7EB+BOxEfhbsQH4O7ER+He/xHYC/DfXAv4n64D/EJ2I74
JNzvPwxPwQ7Ep+EBxGfgQcRnYaf/b/AcPIR4gOHz8DDiC+BDPAi7/H+FF2E34kuwB/EQPIL4MjyK
+Ao85n8XXmX4Z3gc8TXYi/g67EN8A/b734E34QnEt+BJxL/AU4hvw9P+t+EdeAbxXYZ/hWcRUQrE
w3DA/xc4As8jvgcvIB6FFxHfZ/gBvOR/Cz6EQ4jHGH4ELyN+DK8gfgKv+t+ET+HPiMfhNcTP4HXE
z+EN/xvwBbyJ+CW8hfh3hl/BXxD/AW/7X4ev4R3EE/Au4jfwV8R/wt8QT8Jh/2vwLRxB/Be8h/hv
ht/BUcRT8L7/z/A9fIB4Gj5E/A8cQ/wBPvK/Cj/Cx4g/wSeIP8OniGcYdsNx/yvgh88QAXdcgOMR
USrc2iOiQn+ARA7cFR46l19pcFhYCESR0Sp8cEVGh872POaICJ3LrzQ4PBTLRMWo0YJRMaGzPY85
zuPiX04XNTgkHWPiMFIRQ2d7HtILiIb+6QKWS2+KDMUysfEatGBsfOhsz0N6AdHQP12UgaJCsUxc
QhhaMD4hdLbnIY0NnUv/dFEGig7FMgnJ4WjBxOTQ2SYN3HUB0dA/XcBy6U0xoVgmKTUCzZ+cGjrb
lIG7EkPn0j9dQCj1prhQLJOqjUTzD9KGzvY8pOdR/5fTeeJj4JQQimW0wzFSYcjw0NkOG7hrcOhc
+qcLCKXelBSKZYbqYvB1c5gudLbCwF0XEA3900UZKCWU0BHSY9GCuvTQ2Y4YuOs8Lv7lNPRiBg0a
FAKRLiMOBkFaRuhsz2OOC4j4/umidBwcivfTRyfAEMgYHTrbUQN36UPn0j9dwHLpTUNDscxoYxKu
sCxj6GwNA3dlhs6lf7qA5dKbdKFYJrcwBc1vKAydbcHAXdmhc+mfzhMfA6f0UCyTXzoIMmBMaehs
SwbuOo+LfznlXMygzFBCp2iCFi1YMiF0tmUDd53Hxb+cjBczKCsrBKKxk4diiJVNDp1t+cBdxaFz
6Z/GXMyg3NwQiCpmpkE+VM0Mne30gbsmhs6lfzpPfAycCkPZSGoWZuAKm7kwdLa1A3dNCZ1L/1Rx
MYPKQrFM7dLRMAEWLg2d7ZKBu2aHzqV/Ok98DJwmh7LIlthyoQqW2kJn2zRw16LQufRP8y5m0LRp
IRBZ3PlQA83u0Nk6B+66gGjon+ovZtDsEEOHk/9Qlwg8LQgeAYkKgr8w0P9PefReMfDf+fsl47mb
a/rcrQud38Wnp54OlVLBHiGRoEELKU6mnZx50nLSffKw3w9wUiff/c3vj/kUry9ik2M+P9tK5cUl
xWMK8vOMhtyc7KzRozJHZqSP0KfphOHDhg7RDh6UmpKclJgQHxcbEx0VGREeplGrlAqeI5Bdpa9u
EHwZDT5Fhn7q1Bx6rzdhgymoocEnYFN1Xxqf0MDIhL6U5UjZdBZluURZ3kNJYoUyKMvJFqr0gu+1
Sr2wlyyeW4f1Gyr19YLvBKvPZHVFBruJwhudDkcIVanWSsFHGoQqX3W7tauqoRL57YoIr9BXiOE5
2bArPAKrEVjzVetdu0j1BMIqXHXV2F0caKJQKt90fWWVb5q+korg49OrTBbfnLl1VZVana4+J9tH
Ksz6Rh/oJ/tishgJVLBpfKoKn5pNI9ioOrBe2JX9bNeGvbHQ2JAVadFbTEvqfLypns4Rl+Wboq/0
TbnyeGpO9l5y7/w6X1jFXgLz6/bBdP+KXdNWVFbW09niK+rWMvIUJE+58riW76pKtQn0tqtrreDb
NrcuuFdHsb4emeZk18yr06HU+qoNAlVjXh3TAJmSVAMKSduompLCor6KtjRcLvjC9JP11q7LG9BZ
g7t8MK9Tt3vw9PJ9/o9gepXQNb9Or/NN1OrrTZVDdiVC17zOPdPKhWl9e3Kyd8XGSZbeFR0jVyKj
gitiTx+rMXJaQ6kDpiZUIv00DBGfYBZQkjq9j0svoSCWQJe5BMkw1RO0qA3t19AVO5Y6Qpkeqxe6
TgEGgv7E131bTHKLKj32FNAqDZeekMP+QN2XleUbPZpGiroCXYuSTWD3hTnZ7b4avStW8NWgyWBO
HQ6qH2tAk+t01Mvr95ZDI974Vsytk+4FaNTuhnJDVr2Pa6A9zwZ6khbQnhWBnp7hDXoM50fYQk7y
aTJ6/sXEJidUWcf6SPJ5ukWpH5dPlbBLoUzvmlOXYepar81o6NpQj66pxqXY1VWtF6q7GrpMe/0r
GvVCrL5rV01Nl6uqIaDSXv+z67W+8g31VoJG9RVI1vAlVNTxWq5eqnFavj4HyiOhuhpFiY/TlE8V
9nJFu6fmY3EtK8iDUvGAVNwvFdul4j6puEsq7pCKrVIxTSqmSsUUqZgsFeVSMUEqyqSiVCpUUqGQ
Cl4qSPlsLN/HfBTze5j/ivl5zI9hfhTzw5h3Yn4Q83bM92Heivl2zLdh3oD5WsxmzEsZz4cl1jul
YodU3CsV90jF3VJxu1RUSsUkqRgvFSVSoZYKpVRwUgHl5Vgewfwu5kOYX8L8IuaDmB/H/AjmPZgf
wrwN8+8xd2K2TM1PDEsMK964l7SXT1NvvEO98Sb1xhvUG53qjXb1xib1RlG9cYl642L1xnr1xjr1
CE2aRtAM0wzRDNakapI1iZp4TawmWhOpCddoNCqNQsNp8AHkS+BruJrayaTG96wZahoF3/e1+r0k
fO5in1I/mfjia6Bm/uRUX0mWj1vHdrO9xL+LkN9ep6Ub2T4gxH/dDVq5rK+H5Kz+KbXPXc2czidh
OCkGNWLBHvXwF9S0tRZbN7LWjbR1I2tNJbvnQH6NaX3DUDgH495Eztvbh7LKRtWdU7dLA5PrK5ZI
5R4uIhz1adDq6icnx7omMOXG6VKXa/cr6BdBI3A9R+IDIgoz7cqZlDOJdimAdUXTZ4fclbp8nE67
n2yXu2KxOQ5N+esdNH6l9NaAPXl4mUkdt5JbjLU/QiPiFswWzJthE2zi9kg0+E5vBh/WpsMXykP4
iulm7QVwNWIl/AcNt4a1lEEj9jci9UEsJ2CfGUvCeGwiG1h5DaxG3t9ye7gD3AHWOxH5TqcU0sXt
UR7CdsrvWngIPiT0+6RXwU3Ytw/eoqOQ8ybYCadJJl7ryWfkBDcHWwmdH/m0IPUmlPdpOAL/Jolk
AukiTyJNPLeSySLNtgJpDuL1FuNCr5nETpzETa5Hnsc5nitErk5uHbeN83EH+HrFBOUhVbyqWG1n
32Hl8LQbhxpSbrPwJbMRryt6uErXm4Qjc8l8YiW3kG0ow0FyAq/vuBxuIlqdXjfzDYpIxZfKFuWd
eB1SLVDfplEhbyWoYDAIkA5jUKsqnGMuymyBy+FKdl2F19Voy1WwFbbBHXA/7IL98BydE47Ch3Aa
rRODF9WrmJSSRXjV4+Umy8lqtMf6oOsG8ieyh+xH+V4l73LDUWvpsqP2kpTXclu4R7hXuT9zx7jj
3FfctzzwYfxSvpH38PfwO/g3+DcUUxXbFHco3le8ryRKH7NUvCpRdalqPV4b1GHqFvVq9e/Ut6kf
C8+FFNQrG/Wajm9uZuhETa7Gw3sX89ouvB6BR/E6BF9RPfDyy5rQq5RUkmqyAK96shhPAK3EQ5b1
aHQ3uZdsJ4+gLu/idZgcJR+Tf5Bv2HWaU3HJXFaPfnO4Wm4R18Ldwm3m/sQ9gBG5h3uSO8x9iDoe
506hjhF8PJ/ED+Or+Gq85vOX8Mv4a/md/AH+KH8C/RapGK+YoFiguBR1f1FxXPElepJT8sp0ZaFy
LF5WpUO5XLleeTtG9AnlCVUks0q8KkE1TrVWtVW1R3VEdUadpE5Wp+GVq85T16rt6nb1DvVx9Rea
B8MmhdnC3OHZsAPffx4/a/U+Sr/Lw12qMsBgchSj4Qo+BqkEuva4SLU9zMbtodKpa0kmeuoDOM2H
QY3iRVjEXwJ2ZSMfof4athOPYiV5gK+GB+EedTt5km/gT/D3KNNV4yR7clv4HepOdYP6C5T0O/4m
pVWdSyYp15Pt3ERc0W4yF74np+AynNnLjYYX4XpYR9rxgbNJ8yCJwrV2kBtO1ivv5HcrtvFVyuVk
FHpQqzzEXweFkITvRpmQhrGuxHdH+jLI0e9v8ytw9fP4gNCXx6jfIYp3yF34LuUHpZ/fRz4DMHSf
iD0BE79BzDMWxOni0nVxuhU8nFnBQTcoD/1YskJxiH4JfLr/qPo75QnkHIH8B4MexsHd5ZkKlSYs
Ij4xdbBOH8FFxyWN40tTtGP4fKUwIj0jR5UF+asiSak1ei9XuDsri9tLrivPBi5okGJYRpIhlkSO
SB8zTlUEgjbTOywnLtZbpEzxGm4ctpcbs7uoSLGPCCjriVLDmTMnSmNPlLIcF5+CWSqlTmw8wVpT
SllfSmmeMYWQ5ATMKekZI0lRQX6SmmAlOYkhvvKx25T0osIxGfo0dd9iOpmuXPp10o+38a23phOi
/+NPcXERmYQfrxPO6HL5STHaM6qE+Ci+LDL6p5hSUlwZFT10SllScsqUiZFROQXp5CdFypTuH3/6
u6JlzkPP7634ebIiI5y7alD0mZIII7dcN/iMQOJio7VcZ5bw8ydTl5QNjYzQl2YkJKQVjYqIGEnt
vglAswl9mIJPiLEwBebDErizPLpkQiGpX1BUMpafNSZ1AVr38VrgBg2doKzfyxXv0RrWTMMTaLkw
a83oijXh2trwFaNh0aChYwrHLkIjXzKSjMhP5eZGX4JnyfLE/IRl0cvKRywbeePcanXNsvK5+XzR
PqKDHMOJlFI0qeHECfZPsjX7l1JqgInMDbFnvj9B6dD+pbI/DIY8I1GPzBg5MqNwDFqcvlir1aqk
xJTkFJ66IIWo6H1SSkqyWqVPQ6pian9lMcE7dEZyQT6zPw4hdBzeY7c+LT2fYlIi77uhJrHtzX90
Lrzq0iUKwrkTE6YoLh86uGvtT7NLkpIXcrx6y5YdCx0PkPFWUrGFf/sqV86YH7V5k0fN2VRfOJPM
+sxWXr66e2IGEfPyjHzzwpyygkua/zDXVVvr0BhSkiOmjgmP6D7NPacoPjNFp9EItWGD8tatWLmo
YlHLi5PGqPKWnHk9X6OA1OGueV3TCxb8/PWNk/MyM19vmfoPAyZcsTv9RzWbcbVkQhbk4sodA8Xo
vfFwW3mOdtTobKPCEA+R0dqRWbl5+QVjItJTCotKSseVqVQkonjseKWwKiV9VXx8ioGul2GqiKEG
I6UrKi4pHRtRmDNqdNa4svGqbD4iOozfT2bjQTK/PGLkjdG5Q7O9OTnRhfu4BRBmYK7DfOa748xt
0opA+aQe6rW4lN52dFqSIi4R9GlQGJteWFQsOY96o5ium0TqnJHolqRkUpyQUMCTFKJMURJ1eoKa
50cm8HbS1P3y+0e7XyZN+dPXmK7dV/hs56jxYTG5rdU3f1B6Z92qSVxC5vdlBalk6qjuL0mNpvs9
Upfa/XCBcfphw30K67rfd299v/sVUoTNt60bHJnUfMPW3HsEZfrIsv3GdfdGkxm67idJZfdRkj68
+z2VQdv9zaiPu/fHkSHd18QRL93xdsIm1XG24w2Hyx9VxCclK9STwsntuJC0iFFoKVqP4pTlYZDI
x6pwdYXvJ6UwjIzbrYyPnRSB9VQyDpKIiEyUFDkz3Xow0L/DrQeztASoEXHTpEbMMxYX6pJIkq5Q
h6EMBfmA8a7D26JAFO9UFf884cx6sm8ZGXTgABm0jOw9s/6OA9eteW7Tpk1cddemqzY/TeK7v3l6
81WbuqwPr37mmdUPM21A1ca0CYNx5eEaPCWtglUKJW6j08ujVCsUqAp/I3ejIgzoK6LmToWBbY9n
4kphIqvRNZtnTI/TJajjinVxauXMnw4Q80Elf9CsGP/TgUas/HjmoGQ5UD7M5lLBwt1KlWovt6Y8
iuMTOZWC41UKlVJBW1IJl0gIpyC8Atvps+RGjleqFLCP4HnQ8DluGDDxcxZNa5W5WZprYl9Yq8lN
zVJiRRfG6XRE+fCP3Uque/6ZSO4Jchk9HZwZwl3m9/dIMAWeUi2hP3wqp0/mDPn6hDz1v3FxnRd1
ffT/6uKT/2vXIjyR/ioXO2GlkwM9n8jmQ+AzbIKRXSTXOVArv5TrPGiVH8p1RRCNEiKVP8h1FcSp
lHJdDStUyXJdA4mqW+R6uPJBnE2qR0C+aodcjyIzVe/TT9gV9P0gUjOK1env62I1haxOvyps0VTJ
dQLxml1ynYPoxCS5zkNRIpHriiAaJaQmFst1FaQlzpbragKJV8h1DWQmBerhEXWa++V6BFiSNsv1
KG5L0hlWD6dypt7K6hFUztR7WD0yqD2WyibXE7Aen/ooqycG0WjZ2JdYfWhQ+wg29m+0rknubY+U
571fyDcai4SZNrPb6XE2eYUKp9vldJu8NqcjV5hktwvzbM1Wr0eYJ3pEd7toyZ1vFYVFNkezBbNH
aHI6sLNDdIuCRfTYmh2iRWjsFGrcNo8w1WlvFT2CyWERKqwmtx3rk23Not3ZIdgcQl5pqZH1YSUv
V4gKjwqnrIMYOt22ZpvDZLd3sh9uWoQZbWabxSRMMzsdnmxhktvt7MCS8qj1mtwewesUzM5Wl11s
FR1ewYvc5BFecZmXcRaaTK025Ici0m4Psg3I7fbkopJsomzBLTrdzSaH7Up6Qydwi3bR5EEZJMnz
BZMnyGg99shmbL1WtxjQxOV2ttssomAS0AStTofN2eZBAXqM5RG9grNJsFGdcBaXG+3s8CIvxgnV
wTFMK6dDpPyQ1oWyOtEurLnNK7oFT6fHK7ZKpqbDRMkEjLrZbXJZbWYkb0MPovw4oMlkFj09NkdT
mzBLIjQ53cKcimyBiup1urOFFrGz0WlyW2gTckAN3SZzSyO6JZuqZBEsbls7NltsnhbR66UEJhdK
bvJ4pFuXm82ZjbZfli2IXnNuNrVeh4jBhWXvtE02O7Wa3YL6IT+nuY0pgRObbHYJG53LRGzosDks
zPdmu80lS0d17zChHRpNVJBcYZpDMFksNhrJ2UERa3OY7W1ofnniDpvXKjQ6EVAviRpNRZn1Whc9
ZWtCEzrMqI6nzWxl8rttkpucTrtkeSuCh8aOic4kNNupCWQhXbTFY7Z5PE6qXKNIzdfobG3Ebqto
bhFkzYIM0+pEpwQLZWs1NaPcPQKIJvS1JB6b1o7LBV2E0dDaiDJRZl630+5sZt6XyUSH2eY22zHy
HGhet4nRYRTaRTOdhkaMqZVGGFWGqcW853Y2mlh8u+w4A1Lj6sDVhGsZSRkZ1ttw1VsDgTXHaZPi
WOJhQSGkW9SqyS1e0UbXaFObg01L3RIUqb1BivZ20r6AJ+kaN6HTcEX1kdkVmE12gvccuxTq6kTa
JrSZie0dlLEZ5Wlqs9PJLSZJFGTXIdJdj4lusdERVFiLzS3K0tIOj7fTTpWtxtBtN7ltordT0rXV
ZTJ7qYca2+x20Ss5QkTbtMi7ldNNtxkW2ouoZaiIvcJhXeLXszk0i85W0eu2mQXJd9QqV7Sh4NQf
TntnM9sPcQtslmZjwuGGmNtrgXlic5vd5B4rzKwdy7b8hTgRtV1hrtHYQ5YjkwWtFnS2jYWZCSOs
2UYVQcFoWIqtJncL6oI9QbdN536WUFNTnyzAXUVk+7VXejQYkIGTTWB2tjlQSWrSXhbzO11OFhed
Vq/XNdZg6OjoyG0NdOfiGjV43W1oepdoYF42dARkN9Q723DT6KT7Hs5tk8KA+gXDu9Xm9UqPKipV
1YIZk9gWRG9wx7a0oQNR4g4MR2vQWFvP9mGhgYhbnstukrzOdjnUASPXgZuPEJjc6cDdPtM2ShBb
G+moXl6OAPU5RWLkbB9BN1PfB5aJPD2zp8xrHJMg04az4GOAmtxNH3K4RTrsTlPwpGz1yBuy0GN5
Z5sXdzp8JrXbzCKlsYp211kagQOc4KY/0QQ71IIXSwdYEN2I94OAxzEjXkVYmwk2MGO7EzyYm5BW
gAo22sXQhC02rDnwFVqAScjPjuU8bGsGK/Z52J2IpYjU7YgWpJyPfSL2LEI6B1Ja5JJSNzFu0sgO
NopSWhgPytXBeAjQCJ2INdhvY7RTcZwddRLZnaQRldXK9LLL7ZMZDxHvnchdYPMK+PJfipcxaJzU
kse0iqK/w8IckPrcEjqZJM2Mo4nZgcpH662yxDOgDW1pY5YWYBrWKR8PZDPLuZmVO+T7gBySd9xs
Li/2C2xUK1qfakQ5O5hPvLJsfefwYtsy1h+QmdaoRDZZPsmKgdEeWdqz7U3nz5U92asRlZPqTjVv
ZhLb4MqenoAGbmZtEe89sh2CbZ7PKD0DRFr/+MgOkpaWlPvZPnExLu3MCiLjL8hR0MqoaLy2IaVk
gf6RReX0Mo82MWkDfpJ0cTH0yJaX5OqVSfKONE+vr5yMd0A+ia9LtqtTjpde6jbmNzeTpBOzl3k6
OKoDs4l9oqCXdzNbmS6kotJL3NvkNSjZX5qBxoKZadM/zt2y7aQy2ApNzOMCzMHVRf0RsKqXtdOW
FhzTibHllPeUAJUkg+RDN5u7Bamk1ZLd4yUL8wpdTe0ytYWt8RbmF28PBxOzocA09MheC/S62PiA
ntly3C9jNUpnRo2ze2Kvg1nS3nN/Lm2b2JoJxJqdxY1bjkgL/Yk7atfrCUljExsTXKc2WcYsns3m
tTGP9q57M9LYUPq+tgv4vYPJR3VqZDXJIrlsN3EwOguzVWBPzh5gj6U1OlObHP19Ne5gHKxsd3DK
NclfwbxNsr0kyc4Vu9KasjHLmRmlWfaOh+1S1iD7u2XOgdXkZDYOjnmrXPP07DumHp1oxNt7oqCv
JV09NB62M3rYmgt4rlH2fLasbSuiNJquARqfwlk+O3fEtDKe4nksZWMx0Czbu78FRPYstZ5lvV5t
7fLTRVpF0t7QymSzB0nmZXsffbo1B639vtxE5gkbUppZRFvYc0qKXjcbEeAn7YV2ZomANoE9xsT8
La2BgGd6vdW79qg8jaw9sH+7WOR5evYv6dkhPZuk57IoP/EC3KT2NvlZb+23Y83BXluf/ThYDots
ieBet7ySaXkFchZ7JGhj1gloG1gt595Tz7WTSvHt7Bl39poMPMdN8kqzyE/egezs6qdb35XgDfEs
JfnVKfNtkuPMFHTuCEhslu1DbWHv0dwSdNbrfdJQXwXOer1Wt7BV3yQ/RSTLWljEiWfZNjCCRm6n
fEqjnq2Wd912JouN7XOdffxKo8/EuAXWUCOT185og1eEKMdNy1lnKzpD4DTTu2sv6omZgBXPZTmP
7MFe+fqfHJrZ2aiVtblZ1Ah91l0gVmj8meRTRbbscXo2aQ46H0qnwOY+uvVaziSf0M4VA/PYCmtj
+6MbxgI9adWyMnDKXyhrFIi7QuREe/pzyzmL27mfLdLKtgXtZiZ5D2tmvV45LixBu6XIdkc322+d
PWPO3dsEF/JeEojqwDpZIJ9VxKDztReC3xoMsgTOIA3MbP9xyJ4MROm5pJiPnnOx/TewX3Sy1eHF
+ljkbcA1Q69cdgrvOzpXfo4a2DxtctTTXdYQtJYN8rkh2O4GqGcSSicNulKks5akt63PbhBYL9Lu
3cqsEbBH3/eBKvrfCuG7Se8pKNAjnbEt7Cnm7bFxh7w7WgeY13aO04elZ0eUTnkuFlvBa733LCfI
pxSvvGKpD4R+mlMK6WyfieNGsWhsZU96y4ByOfrxDt1Kvdx7zyPSag6s+7OfJn21743PvnKNC7IB
1UTSRXobCES5u+dNTjpFOtiT0jSgpr3Pnr4nZOEcMe9kpznpTCe9J7UzbcQePlb21HL9go9mQe+n
DWLQnYmdaYI/f5BOvAGKj7HfwUaY2D5rAfq5hfSbCwB/Cf2/Hs+ZFOwXCEOAaJCa/vqA/RWLsL8r
YdbS/w9T/t8JtGXGVdoSVdjoNVPXnI4iam7bKu0obErnCMmLMIaplFnRPDdYCUaTKjxLRRRkVTFH
FNtqjXON2UEtQ+4ctmIIlLFrNkaDh+3hIrPCBHoZdUHMFIkLdnQ+/tmtm8kDmY8bdzT98fq0q45o
tq1KOmZcxb+AOWcbzxGOi53yzKCbj90wr7ri9NHWqVF5dxujekQlShRq5XomJL9AoUrgFk/KSzIm
0BtNQuQikX685xAqTC4xL9EYT5vVCRGVbe5Gk6PdZreLeTHIDVvDE1TzraYOr5g31KilDREJiVKD
UCG6vezTcvqBVd5w41DazScky93zba04i6mVfSBeMck4LCXKWJCXbxxjZGlxSlQevS3ILygsLSxd
bKwNEnZBbV6KMUmaP3qh6LbV2pod2cI0hzk3L8s4SpooLdDBpqKfNEpz1Ypu+vGWh066iqQFW4Uo
gV9FYgDbw7lVhMD9r+y++8+vCQ+HX3P9g2vbTj4y69tjz8U802x66i7LkPee+OGVggdWG6+vW77h
aMsHRbfHPPPW18v+1XHvcmfZMzc9HLXf+p190ytPzct5YOr4U4+9e+lSLbf1R0PLsLtP37Xl3sGH
uI9/M2Pep9ENX5cPWb4v6sOJLz1ybO1TS6+8PC+X37wyYfsU4fU8T9SinNeWjSm4OX5z/L4PrYYd
n396oGvD6OfX69Y2PXVt3SJn2zNlOzLWXvpKbFLZ1tVfzX8u3PFC98HpH+xTx92advXRCSPfGrbs
6615L3/7edqgoy/smVKxZfDSbcM2Hr/s1DdXf3vNA43kxlMzIz58M23h9ptfe2hd+0Pf7I/69/GZ
R7b9ZN32UOK4PWufe4LjMfDvWnnUuPKwcYxKgxGrVKoJUWQaM4wjAvdGsiZV/lDWafa4ctvpR9xo
d/qhLIudoQmE+BUaowoLjoBxEm0brhhrLDEWbRuzLX+NUR5udtv7jDZIsRIcKhWTcpGKRerQdEWk
MTwgBa8xRtPGGDoX/V2PCiXE+zgFRubdg4wpgfjmEyLn107CQCvJycspLDhrVfArV8L0lh++qjtQ
OSTv+s7NWbc8s+pB8tchM17zddU5jmlG3XXZoVduSvhCMS/qn1NGGqDEd/zlm2ZteSetMen0xGLd
bFfeim/Xl6zd8+WXt0L3GwtumTXiL/ePnHXlQ4+bJv179OtfvHzksg+eyLpuwqO3PXrk40X+px85
uPzUG5G3n7y1O+vtcfO02pKRpydOxzXsN67ivpDXcdTfs06+c3jUutR8ZdhlW9rXnb2O/1dWRv/l
aCwJXo6LQpzUYMyRJs34pUlr2R9ff3FJ7p6TOfWDt61Xrk6tbGq7dPkLe7eaM/zjK/50dVxJbPoC
z5G2kbYzs/YJS94O/2GbdvSJBQt1psPDjh5/sqDlpX9+cFex+FvtTZGP1Q5bcnVT4VJlV1V3+6xj
tSvuXCnc9tC6JXdqTn9m/OGbtOIZk/+nevOOairZ43iA0GGRDlKkRqToDcWg0psiIr0j0oIUpXcU
SVSaCAKGqpAEA4QqIkUpEgUEDIqCKMiCLjVIkaqIwkuAVXbVt++8c97bs3/lzJ3cm5k7v99nvt+Z
CdOTodZdzb0WJIR6lWmebBFV+Dy26IrSWu7YCU/aXFWv4ftpTWtExxWNcXq0zjuEiTdOer46fofU
dNIAHTraOCviKAMrINSxI8frA8m6DIzXyLwtNZHEU6IybOZj0K10o8rHVagyTbZOdTzs3ZnwFZ4x
SGn5bKZZjYYsqjasaK3HtHhPYKTW1AFhrCfPmE2dhPsrUJT2jpgor62U7AAQj/7LlGT5mpLUZKWu
sJmMsoA0IIWGoCWixX6WjIEBAXIuThvpx7ORfpRH/JsMpGv6jzJQ8c8ZSBnlmFDf/uOmVCJ2b8La
kUDzl7v8aQ3JoIcNnZ2ti7+8Wl8xbFJwBthblgIFelIGT14X4aw4q9to3HlhPIr3QsHu1FOceqsd
tRmaNMRsEzvay+cLfRYEjAUk9s57XDkt9qGugwc1zRLY5B7S9y7TOYYQcPVjXGC4eHFeRkR6xYek
PX6Ge4MEjmj2v69iFTHvDUGnI108vjA+jX8fVMeY3bfCbgHJcpJvDKe+FRHdiH14WUw29JlScH1K
gP3K3bFj3EzixJHnPYp79TW4VdgcwyVacW6zaU9936mNL7JGDjw7mxfs50G4bnQYUBKtwJbvdFaR
6UsskqaPeMVXaR/x2w2cz5pKXCmABHOQEfBpEwFsIALosopKLPsztWWXqSGN7W8MTCaA7++5zcwp
pu3jG+a/sWkp5bKHckQB9qeNuL1QYUBw88vcP9yig4oCuzaHie9bvamPT6CIZlCgu4+/R2AYBQ8H
YAAUCgCwLTzIU04wQreKf0OL/nIqp24g+I4dmj8uIJWbHuoATGLxVyRPflxDHcurWbuBFVE7a4LN
xiY5yns903INmykJbjfvn393PVowKfeiW2WLV7izeK+QyiAbVcpEWvN9ObesLHdIZtdB2fssVdYQ
gt44k5pymixe6kDhlP4FreGLbHVZpy2cSpBnMY5yIcdImXdcD2UZC0IZJLhy8ePJMnxjqhkuXI7W
tPBcIZhpzIeC2WvUrQLd9y10K+Oi7h+cMr92vOxLQfiZwOPlfMQ0RilRkNVVRw9YnQEHvYrlut3q
TTcmhvznCEur2epDDjyIEHD/cmNZFGrtVuf53oKd/vYqHfXvGfLEgEq6S+2VIiGcl4a2uFEIIHAA
AkvJSyowIgtApEftsOvynfXwzxE3ieS6bZi4/hjj//8fP+RfxPgGFVATzE1XFtL5lKZrqSRehbAv
2DvK5+YwP1ajTY5Naj84Jjr/3ipVtgp9uM159vNL4qFDtvj95h5rEmfU24lFg7Rnf4VeUc3d4etZ
t8ZhxOfR9LlLe5jdVsRo0jmivIi/TQYmKdcIx3DES7K55H0wF1wRbe/lXjAt8daWp/+C5P04euo0
q8lyw5zpo4bxZuCzCJQxVgi1Z6fhCyFq3FzUG5o7dosVv7ZZzcD1H5maV9+hkeJYv9r7niEpsja9
pRgmOxI+UhgyHIwGdXmqE57vj3+jyVGo5Cng+VrpbY8geKRQF9xmq6DsbSjI6lzDhE3ofmGurtcp
aJHv+5rjYExqUG7BczSZCg/J4qB8Sxh4MmcaNYGEitn7m6kxbrvv/W4ShP4uJAD7yXpBEQpTVIQq
UgQ8GfHy+39HAiL/j5KBE2DftBtMVk4B7mQpEEj+nR0bUwjZbNCbwl3P+Hi7/t4ypp+17GfdlCf/
6HfdFAdEN7uxc3uNK3xDfFDUiPGGKRD5niSsFJIwbJDkIVHkSv3QuprxTPiDHgnJ5eAnouud0pbH
O67XIG8rhcmBmgsZXri01+CWSQRCb0VCGpb+E1s10jTrHbK1YUdLYdOM18VEM4E640+uVHEEnh6k
O0gjVGeJQ/n4qovJm0+qd0dhFUMu9OKH/DQUDy96lekt7Q4QFnusxS9sUm2a1Z3XxdnKr+5Hd2Ye
JapzUmu6qT3TVaSWoPgZqzMWcVtoX23+4CJmKFuUbc0aqmmhHFluPT4yZRMmWfxBeh+7unKomtb5
AveRSDF33rGjKc2hOqaHMUYX41Kzm05FTDKuRtOcW870U5EpcMsgDsn9JkO9k03xCHxJhaN8LkZQ
CGLqQyTHHk0ekkqa/D4gP9LhNP8MvHDQMW4ZcG4yX6hpaEDgDYsq9AuYB8wl+VHG4ESbv3np6DJa
mpdnlbBihgD4v97CRQ1mEWYCmYGCyHZdG6QJMG8Inw3foQewfRVYtAAN+WNbXm5gzGX4zQJt7a1J
ZmbFZ0ioWpyz7guGghUneNtemk/KRzSfVs3vvtA93GJpVljF/4Q4Nodesaw+cu2wxCh+10B4zzJP
OMfrhasCUwwnKi9dvZtgXSdIRHWjriksJg+ux2Y7GOgbH4AcFBEwh30+Z8+d+nBAMPG9k6nKKP20
22zYVNITKxc4ik8fHT4ErxmClK21cVS3YomtJy/7LnS8LkZ60w/A+e8WLkc/YNTKmIOUeIRXEGQK
brntwpXHMHilc9be2p8pTJvHqZzXVAKo3RN9CeR3OHMIlltdGZ0LZ7/noMICm0slpMQeB9vS2j96
2ovve3suOXT36h1vXBKdgnWFgzQ7G4CkVSCjTGATY0xOejmPKf8ZBcG/W6H4pyDjG/sOKCoo7qe4
JRhZG5GLSpQiEPg/6cdWPc1P6v9SEnUi0pTL7LHzhKHBrmLUlV6VG7suPzwRvffE+wr/peKSWM+q
/gqxCOa2NpxBsoMYJ2llSfxG1aJ3cNnszE2VR81NNvbqxZUBCpB8Z4RTGMZ50TsW1eX966Pc5zdN
2IOd7vnGwzFpPHEFJxBdOm6jry1zNDo+DwRL7NUBQKO95yJQ7C+shfImjJjbYwewvWaZpztcOjI9
s1IcjhmyT+zrtrNzOGmaFyCHq7uoy5rAzx38mKE/K9+Xe8JwyuPLidteSdN7TGDKl1v19LmvGWfc
WnS/+XKQ0e9UYE5IgtAlr/TJ8ZO6xDdjfqzPXECpEdCMROY7nA2VXTNzQ6IzeEenGZi26sNNSYSk
SiG/kcTvvMs3GMz0eeGDzDqNZgSO89MJ510vfnrty0/Ih6dcFQcjMAAiJ+qHFMEE3vw7+Pe9WDDY
NH46gBaggVZDq0Qf3Gb8/niyztfLg3J139aJuIB9lASgxD859uU3DKHRNieqDWgC6l+dKHW0wk9P
7G08F+7//QMDf+QJlftmUcrZ9hlcJ8y9PYao28YrV7sfGJbuKz5vztovX/3Rc4x1VXRniBrOPfwO
KjLefl67+UI2/FyssclZJNfShYCX2Eb7DmrfJ5DTvPWmXLi4ppoRDBETdCPZT1WgyRJkWfXxIqTf
QWG1VzLcIas/f3VxXnNniYVe6ZGBZGVOa0b9uQVozK56cKIdB5yGxGzShWGJz2zoIxR2MXBLilZV
W8UJPrOLVsJ1fCmKmcLD1Gu0vYZF5nTrI8tIcxa3MUfq4Y1min3tE3QuYLpQb+P1I3XZk9q2Ma9L
maKWbFpkR0bP2x0dlQ+bEbuUwiJXaWzX+kDD2rr4eefwPkLn1JlcWBgUCX5MxuYjaioqAFH1j4Hj
HwD/bRkbjZgAuL5OqFJUUHoa2o3leco0uzX0jDRQlu0r5+SmfysxQ38BttdyA+LfbgRDyXmriLrt
EXV+wQiT8bRdQwahWV+d3wT4b7uFBeoKOKOVo/b/cDNO7+vGx082OTGQKImfn0b9emD1z2oSjKQC
AcoHn7+2uapq7BGfbCVS7tTXSwJ1O3HdECd0algOOoQ6mz94pk0KtCpgWvvlPsnm1HW2mMaPftav
Wm8KFw6IOV0QeZRYgWe/uOuI7fIFosHNalmIbVayhGydz6eWXzHoIhquPD/2JT0R4i7NUWec3oup
dcbQ57wxZ1vmJ6ZjVyNb3Cp0lnOOyWbkxWeQhvlCPtytm87MqiyfNCwSNPIuF1G/9dIkie2+JJ9c
qU/9RGyRccp4ScIs8h7fyTBSevQdaFNktS58RasJT8dgV6Jnsc/bfJB/NLL8RQ6srQzAO6Zm+H0h
JazBqbAJT6wk1ns8R6JrZM492W9S7dn+sp/v7cOWZAySLIuQVKvfRowOiqSaIl+aoIT3qf/JouYP
llJZ6Bg2G0BNpgzaBuDbHnvM37Z2qMih97WGFspGme/JE7y8vII8VP6ALZm/20KPA7xjtBSHPsrJ
cND1Zmi1ve9bxR+EgJ/rJx7eTwujozSc5WrzOk9D5YYbcaK2k7+tTpjoKuC8qs8+GMi4eOejFLc+
fpokb7xYq5Gjb4CM4siruNyNM2A5lZBE4nNWH0EtjDRYTb5E8SphDjSswIQx/RPzJ23QryYJOdc5
WF0VgypCEmUr+5N6Fj3jJuATs3ifElsca6o75EX+cEXxOnJIVaiFaNQwIJogEAwx5b1ry8miZZMi
WRu0tnO5xIoteNWRlPyu/Ty7Az+2lbcv/r3KW5y+bsAINf6xnHtxub4oi0v107bEzkvXM6WnqHSc
j2b0BN3+rUc5MTHLAjLVyk9j/6q97SrdeVLVYn1Xc/rl0lVJTnxilnr2vwDOyM6hDQplbmRzdHJl
YW0NCmVuZG9iag0KOTQ0IDAgb2JqDQpbIDBbIDUwMF0gIDE5MFsgNzk0XSBdIA0KZW5kb2JqDQo5
NDUgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXplIDk0NS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5m
byA3NyAwIFIvSURbPDhDMTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5
RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5MTc+
Pg0Kc3RyZWFtDQp4nDXZBZgV5QLH4f0v2AWKXkzAQkQFBEWxECwMjIuJXhUxMBDEJMQEExHzYmOL
jYEoNohid6MgKoLdAXj43mGfffZ95uyc2T1nZr7ffHPq6mpf8+en9rNxXd0ChhRiqb5nYZF1Ct1/
KOx1aqH3hMLAzwuDRhYGD8fEwpCjCqcfUBg6r3DBuMKILReQTC8sc2+h0b6YVWjcGt8Xll8anQsr
3Fpo0hEDC723LRw9qtB3bOH4nXFRoV8fDEN5DTkhuBEzCgOuKJxYXlhO+qkwqFth0ooYjfGFyfvj
5sILnj5lNXTCJ4UXWxZespWpJxWm9Sh89lDh6z0Ks64tzPbPz5lTmLtDYd4dC6hvOKaw0sxC0+0L
zUYUmn9XaPVooXXTQpvyT9S3W7/QvkWhQ9/C5gMKnZ4udKkt1de+98me2Av/rVHXo245VKv0qD2h
64iyVHswqEcDNMSiWASLYzEsiSWwLJbC0lgGJ6GRv763pcZYHiugCVbESlgV/0FTrIxVsDpWQzOs
geZYEy2wFtbB2lgX66ElWmF9tMaG2AAboQ3aoh02Rge0xyboiE2xGTphc2yBLbE1tsI22Bad0QVd
sT22w47YAd2wE3bBztgVu2F3dMce2At7ogeqw63axftgX+yP/dATB+BA/A8H4WAcgkNxGHqhN47A
4TgSfXAUjsHROBZ9cRz64XicgP44EQNwK052QFcv8xScitMwEIMxCKdjCM7AUNyCm3EWzsSFOAdn
YxjOxXkYjgtwPi7GRbgcl2AELsVIXIZRuBJXYAyuxlW4DqPxf1yLa3ADrsdNuLGQaiy4zdtaHTa3
4w7cibtwN8biXtyD+3EfvscneBAP4GM8hHF4DI/gYYzHo3gcE/ABJuIJvIGn8CSewdN4Hs/hWUzG
JLyIKXgBU/ESXscreBmv4VW8hTfxPt7B23gP7+IjfIhP8R0+wzR8i+n4HHPwBWbgS8zE1/gKs/EN
ZuEH/IQf8TN+xS/4Db/jD/yFP/EP/sY8zMV8x6AoRhSjhtHGyGC0MdoYUYwoRhQjipHBiGIkMqIY
SU4jqGEMqlnBGWCojChGFCOKUcPIYEQxShlRjChGFGOgjtE7EhmJjCxFGyOYkcjoZnQsghnBjChG
KSOfEcyoaCQyuhlRjGBGRSOYkc9oYwQzchaljFJGIiOR0c1IZAQzohjBjGBGIqObEcUoZTQu2hjd
jDZGN6N/kcjIZyQyghkVjY6Vi6/abhS+SGR1+VNFoxrkFq5S7XBtjDZGDSORcRrmYJuuVpHISGS0
MUoZUYxSRhsjmJHISGQ0JxIZ4YtSRj4jmBHMCGYEM8IXiYx8xqVf5DMSmZOheJHICGaUMkoZpYxS
RuqihtHNyGCUMjIYiYziRRQjihHFiGLUMNIaUYwoRhQjihHFiGJEMaoWbYw2RhQjilHDqGF0M0oZ
bYwoRhQjiqmiKFkRqbjyiKuEGKEjkbkNShKljG5GIqOb0cYoZVQ0ShkVjURGIiNLkchIZLQx2hht
jDZGFKOiUbyIYnQzahjBjBpGKSN80cYoXkQxmhpRjChG/yKKEcWoYdQwahg1jBpGDaNxUcOoYdQw
ahh9z/vlxKvmHZlWlhaesKIY/YsaRviieFHDKF7UMFKXr216ZVRDuijmGw9Wo77eZo4Hq0i5xIlA
RykjnxHM/OQJ9QgWTB97jq7mhmWqV6MhFsdiWBRLYgksg6WxFJbDslgJjWEaWKdxZf5XY0U0wX5Y
1bt7oKXVsDrWQDO0QHOshTWxDtbGvmiLllgXbdAK62EjtMb62BAboB22wpZoj42xBTZBB3RCR2yK
zbEZtsZu2BW7oDO2wc7ogm2xHbqiG3bA9tgJO6I79sHe6IE9sDvErc59hjp3Hcolf4397biDLB2A
nqj2ZvU7HSsTvxqH4hAchl64GlfhcPTG8TgSR6Av+uAoHIOjcRyORX/0w5UYgBNgxlduaNQ4Eafi
FIzAQJyGMzEYg3A6huAMDMXZOAvDcC7OwXkYjotxAc7HRbgQI3EJrsAoXIrLcRkmYrS9We2ja3At
rsP1uBE3YAxuwi24GU/gcZjxlWl1jQm4A7fjAdyFO3E3xuJe3IP7cR/G4UE8hofxEMbjUTyCF/Gk
t6A6Wp/C03gGz+J5PIfJmIQpeAF/4SWbro75qXgZr+BVvI7X8CbewNt4C+/gPbyLqlwf4gN8hE/w
MT7FZ9C4MqurMQPT8QW+xEx8hVmoqlYFrErWbHyHb/EDvseP+BlVuX7Bb/gVv+NP/OH9rAarvy1V
A8s/mIt5mG8VNUx1i9QQG6WM1EUUy6SwhhpGMKOUUcpUtzrVMIIZpYxSRiIjkWU6V0MNo5RRw4Wz
QRWNUkb44mKhzP9qVMFcBRIZ3YxuRvEimBHMCGYEM2oYwYx8RgajjdHGiGJEMaIYUYzURWgjrVHD
CGZkMEoZ3YwaRg2jhlHDqGh0M6oWiYz6RhQjilHDqGEkMsIXbYzwRRQjkRHFyG5kN8KX7rVjpL9b
+APaFJ4rH1HUT2q1gAYblU9NGrTtVWg3tbBx+YyhwaGvF3rNLVw5oa7uX/K2AYQNCmVuZHN0cmVh
bQ0KZW5kb2JqDQp4cmVmDQowIDk0Ng0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDE3IDAw
MDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDI3MyAwMDAwMCBuDQowMDAwMDAwNjAz
IDAwMDAwIG4NCjAwMDAwMDEzMTcgMDAwMDAgbg0KMDAwMDAyMDIwOCAwMDAwMCBuDQowMDAwMDIx
MTEyIDAwMDAwIG4NCjAwMDAwMjU3ODYgMDAwMDAgbg0KMDAwMDAzMTQ1NyAwMDAwMCBuDQowMDAw
MDMxNjMyIDAwMDAwIG4NCjAwMDAwMzE4NzkgMDAwMDAgbg0KMDAwMDAzMTkzMyAwMDAwMCBuDQow
MDAwMDMyMTA0IDAwMDAwIG4NCjAwMDAwMzIzNDYgMDAwMDAgbg0KMDAwMDAzMjc2NiAwMDAwMCBu
DQowMDAwMDM1NTA3IDAwMDAwIG4NCjAwMDAwMzY0MTIgMDAwMDAgbg0KMDAwMDA2NjAxOCAwMDAw
MCBuDQowMDAwMDY5MDM4IDAwMDAwIG4NCjAwMDAwNjk3MTkgMDAwMDAgbg0KMDAwMDA2OTg2NSAw
MDAwMCBuDQowMDAwMDY5OTMxIDAwMDAwIG4NCjAwMDAwNzAxMjcgMDAwMDAgbg0KMDAwMDA3MDE1
NiAwMDAwMCBuDQowMDAwMDcwMjA4IDAwMDAwIG4NCjAwMDAwNzA1NjUgMDAwMDAgbg0KMDAwMDA3
MDcxMSAwMDAwMCBuDQowMDAwMDcwNzc4IDAwMDAwIG4NCjAwMDAwOTEyMDEgMDAwMDAgbg0KMDAw
MDA5MjgxOCAwMDAwMCBuDQowMDAwMDkzODY3IDAwMDAwIG4NCjAwMDAwOTQwMjYgMDAwMDAgbg0K
MDAwMDA5NDA5MiAwMDAwMCBuDQowMDAwMDk0MzEzIDAwMDAwIG4NCjAwMDAwOTQzNDIgMDAwMDAg
bg0KMDAwMDA5NDM5NCAwMDAwMCBuDQowMDAwMDk0NzIxIDAwMDAwIG4NCjAwMDAwOTQ4ODAgMDAw
MDAgbg0KMDAwMDA5NDk0NyAwMDAwMCBuDQowMDAwMDk1MTI1IDAwMDAwIG4NCjAwMDAwOTUzNzYg
MDAwMDAgbg0KMDAwMDA5NTczMCAwMDAwMCBuDQowMDAwMDk3MDk3IDAwMDAwIG4NCjAwMDAxMTU5
ODkgMDAwMDAgbg0KMDAwMDExNjEyMiAwMDAwMCBuDQowMDAwMTE2MTUyIDAwMDAwIG4NCjAwMDAx
MTYzMTMgMDAwMDAgbg0KMDAwMDExNjM4NyAwMDAwMCBuDQowMDAwMTE2NjI5IDAwMDAwIG4NCjAw
MDAxMTY3NjQgMDAwMDAgbg0KMDAwMDExNjc5NCAwMDAwMCBuDQowMDAwMTE2OTU3IDAwMDAwIG4N
CjAwMDAxMTcwMzEgMDAwMDAgbg0KMDAwMDExNzI2OSAwMDAwMCBuDQowMDAwMTE3NjIxIDAwMDAw
IG4NCjAwMDAxMjI3MDggMDAwMDAgbg0KMDAwMDEyMzA2MCAwMDAwMCBuDQowMDAwMTI1MDA4IDAw
MDAwIG4NCjAwMDAxMjUzNDAgMDAwMDAgbg0KMDAwMDEyNTgzNiAwMDAwMCBuDQowMDAwMTI2MTg4
IDAwMDAwIG4NCjAwMDAxMzAzNzQgMDAwMDAgbg0KMDAwMDEzMDcyOCAwMDAwMCBuDQowMDAwMTMy
MjU4IDAwMDAwIG4NCjAwMDAxMzY5MzMgMDAwMDAgbg0KMDAwMDEzNzI4NSAwMDAwMCBuDQowMDAw
MTM5MTUwIDAwMDAwIG4NCjAwMDAxMzk1MDIgMDAwMDAgbg0KMDAwMDE0MTc1MSAwMDAwMCBuDQow
MDAwMTQyMTA0IDAwMDAwIG4NCjAwMDAxNDMzMjUgMDAwMDAgbg0KMDAwMDE0MzY1OCAwMDAwMCBu
DQowMDAwMTQ0MTYxIDAwMDAwIG4NCjAwMDAxNDQ0OTQgMDAwMDAgbg0KMDAwMDE0NTc3OSAwMDAw
MCBuDQowMDAwMTQ2MTEyIDAwMDAwIG4NCjAwMDAxNDgwODMgMDAwMDAgbg0KMDAwMDAwMDA3OSA2
NTUzNSBmDQowMDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4
MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAw
MDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAw
MDAwMDA4OCA2NTUzNSBmDQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0K
MDAwMDAwMDA5MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUg
Zg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1
MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkg
NjU1MzUgZg0KMDAwMDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAx
MDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAw
MDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAw
MDAwMDAxMDggNjU1MzUgZg0KMDAwMDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYN
CjAwMDAwMDAxMTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1
IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1
NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5
IDY1NTM1IGYNCjAwMDAwMDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAw
MTIyIDY1NTM1IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAw
MDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQow
MDAwMDAwMTI4IDY1NTM1IGYNCjAwMDAwMDAxMjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBm
DQowMDAwMDAwMTMxIDY1NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUz
NSBmDQowMDAwMDAwMTM0IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDEzNiA2
NTUzNSBmDQowMDAwMDAwMTM3IDY1NTM1IGYNCjAwMDAwMDAxMzggNjU1MzUgZg0KMDAwMDAwMDEz
OSA2NTUzNSBmDQowMDAwMDAwMTQwIDY1NTM1IGYNCjAwMDAwMDAxNDEgNjU1MzUgZg0KMDAwMDAw
MDE0MiA2NTUzNSBmDQowMDAwMDAwMTQzIDY1NTM1IGYNCjAwMDAwMDAxNDQgNjU1MzUgZg0KMDAw
MDAwMDE0NSA2NTUzNSBmDQowMDAwMDAwMTQ2IDY1NTM1IGYNCjAwMDAwMDAxNDcgNjU1MzUgZg0K
MDAwMDAwMDE0OCA2NTUzNSBmDQowMDAwMDAwMTQ5IDY1NTM1IGYNCjAwMDAwMDAxNTAgNjU1MzUg
Zg0KMDAwMDAwMDE1MSA2NTUzNSBmDQowMDAwMDAwMTUyIDY1NTM1IGYNCjAwMDAwMDAxNTMgNjU1
MzUgZg0KMDAwMDAwMDE1NCA2NTUzNSBmDQowMDAwMDAwMTU1IDY1NTM1IGYNCjAwMDAwMDAxNTYg
NjU1MzUgZg0KMDAwMDAwMDE1NyA2NTUzNSBmDQowMDAwMDAwMTU4IDY1NTM1IGYNCjAwMDAwMDAx
NTkgNjU1MzUgZg0KMDAwMDAwMDE2MCA2NTUzNSBmDQowMDAwMDAwMTYxIDY1NTM1IGYNCjAwMDAw
MDAxNjIgNjU1MzUgZg0KMDAwMDAwMDE2MyA2NTUzNSBmDQowMDAwMDAwMTY0IDY1NTM1IGYNCjAw
MDAwMDAxNjUgNjU1MzUgZg0KMDAwMDAwMDE2NiA2NTUzNSBmDQowMDAwMDAwMTY3IDY1NTM1IGYN
CjAwMDAwMDAxNjggNjU1MzUgZg0KMDAwMDAwMDE2OSA2NTUzNSBmDQowMDAwMDAwMTcwIDY1NTM1
IGYNCjAwMDAwMDAxNzEgNjU1MzUgZg0KMDAwMDAwMDE3MiA2NTUzNSBmDQowMDAwMDAwMTczIDY1
NTM1IGYNCjAwMDAwMDAxNzQgNjU1MzUgZg0KMDAwMDAwMDE3NSA2NTUzNSBmDQowMDAwMDAwMTc2
IDY1NTM1IGYNCjAwMDAwMDAxNzcgNjU1MzUgZg0KMDAwMDAwMDE3OCA2NTUzNSBmDQowMDAwMDAw
MTc5IDY1NTM1IGYNCjAwMDAwMDAxODAgNjU1MzUgZg0KMDAwMDAwMDE4MSA2NTUzNSBmDQowMDAw
MDAwMTgyIDY1NTM1IGYNCjAwMDAwMDAxODMgNjU1MzUgZg0KMDAwMDAwMDE4NCA2NTUzNSBmDQow
MDAwMDAwMTg1IDY1NTM1IGYNCjAwMDAwMDAxODYgNjU1MzUgZg0KMDAwMDAwMDE4NyA2NTUzNSBm
DQowMDAwMDAwMTg4IDY1NTM1IGYNCjAwMDAwMDAxODkgNjU1MzUgZg0KMDAwMDAwMDE5MCA2NTUz
NSBmDQowMDAwMDAwMTkxIDY1NTM1IGYNCjAwMDAwMDAxOTIgNjU1MzUgZg0KMDAwMDAwMDE5MyA2
NTUzNSBmDQowMDAwMDAwMTk0IDY1NTM1IGYNCjAwMDAwMDAxOTUgNjU1MzUgZg0KMDAwMDAwMDE5
NiA2NTUzNSBmDQowMDAwMDAwMTk3IDY1NTM1IGYNCjAwMDAwMDAxOTggNjU1MzUgZg0KMDAwMDAw
MDE5OSA2NTUzNSBmDQowMDAwMDAwMjAwIDY1NTM1IGYNCjAwMDAwMDAyMDEgNjU1MzUgZg0KMDAw
MDAwMDIwMiA2NTUzNSBmDQowMDAwMDAwMjAzIDY1NTM1IGYNCjAwMDAwMDAyMDQgNjU1MzUgZg0K
MDAwMDAwMDIwNSA2NTUzNSBmDQowMDAwMDAwMjA2IDY1NTM1IGYNCjAwMDAwMDAyMDcgNjU1MzUg
Zg0KMDAwMDAwMDIwOCA2NTUzNSBmDQowMDAwMDAwMjA5IDY1NTM1IGYNCjAwMDAwMDAyMTAgNjU1
MzUgZg0KMDAwMDAwMDIxMSA2NTUzNSBmDQowMDAwMDAwMjEyIDY1NTM1IGYNCjAwMDAwMDAyMTMg
NjU1MzUgZg0KMDAwMDAwMDIxNCA2NTUzNSBmDQowMDAwMDAwMjE1IDY1NTM1IGYNCjAwMDAwMDAy
MTYgNjU1MzUgZg0KMDAwMDAwMDIxNyA2NTUzNSBmDQowMDAwMDAwMjE4IDY1NTM1IGYNCjAwMDAw
MDAyMTkgNjU1MzUgZg0KMDAwMDAwMDIyMCA2NTUzNSBmDQowMDAwMDAwMjIxIDY1NTM1IGYNCjAw
MDAwMDAyMjIgNjU1MzUgZg0KMDAwMDAwMDIyMyA2NTUzNSBmDQowMDAwMDAwMjI0IDY1NTM1IGYN
CjAwMDAwMDAyMjUgNjU1MzUgZg0KMDAwMDAwMDIyNiA2NTUzNSBmDQowMDAwMDAwMjI3IDY1NTM1
IGYNCjAwMDAwMDAyMjggNjU1MzUgZg0KMDAwMDAwMDIyOSA2NTUzNSBmDQowMDAwMDAwMjMwIDY1
NTM1IGYNCjAwMDAwMDAyMzEgNjU1MzUgZg0KMDAwMDAwMDIzMiA2NTUzNSBmDQowMDAwMDAwMjMz
IDY1NTM1IGYNCjAwMDAwMDAyMzQgNjU1MzUgZg0KMDAwMDAwMDIzNSA2NTUzNSBmDQowMDAwMDAw
MjM2IDY1NTM1IGYNCjAwMDAwMDAyMzcgNjU1MzUgZg0KMDAwMDAwMDIzOCA2NTUzNSBmDQowMDAw
MDAwMjM5IDY1NTM1IGYNCjAwMDAwMDAyNDAgNjU1MzUgZg0KMDAwMDAwMDI0MSA2NTUzNSBmDQow
MDAwMDAwMjQyIDY1NTM1IGYNCjAwMDAwMDAyNDMgNjU1MzUgZg0KMDAwMDAwMDI0NCA2NTUzNSBm
DQowMDAwMDAwMjQ1IDY1NTM1IGYNCjAwMDAwMDAyNDYgNjU1MzUgZg0KMDAwMDAwMDI0NyA2NTUz
NSBmDQowMDAwMDAwMjQ4IDY1NTM1IGYNCjAwMDAwMDAyNDkgNjU1MzUgZg0KMDAwMDAwMDI1MCA2
NTUzNSBmDQowMDAwMDAwMjUxIDY1NTM1IGYNCjAwMDAwMDAyNTIgNjU1MzUgZg0KMDAwMDAwMDI1
MyA2NTUzNSBmDQowMDAwMDAwMjU0IDY1NTM1IGYNCjAwMDAwMDAyNTUgNjU1MzUgZg0KMDAwMDAw
MDI1NiA2NTUzNSBmDQowMDAwMDAwMjU3IDY1NTM1IGYNCjAwMDAwMDAyNTggNjU1MzUgZg0KMDAw
MDAwMDI1OSA2NTUzNSBmDQowMDAwMDAwMjYwIDY1NTM1IGYNCjAwMDAwMDAyNjEgNjU1MzUgZg0K
MDAwMDAwMDI2MiA2NTUzNSBmDQowMDAwMDAwMjYzIDY1NTM1IGYNCjAwMDAwMDAyNjQgNjU1MzUg
Zg0KMDAwMDAwMDI2NSA2NTUzNSBmDQowMDAwMDAwMjY2IDY1NTM1IGYNCjAwMDAwMDAyNjcgNjU1
MzUgZg0KMDAwMDAwMDI2OCA2NTUzNSBmDQowMDAwMDAwMjY5IDY1NTM1IGYNCjAwMDAwMDAyNzAg
NjU1MzUgZg0KMDAwMDAwMDI3MSA2NTUzNSBmDQowMDAwMDAwMjcyIDY1NTM1IGYNCjAwMDAwMDAy
NzMgNjU1MzUgZg0KMDAwMDAwMDI3NCA2NTUzNSBmDQowMDAwMDAwMjc1IDY1NTM1IGYNCjAwMDAw
MDAyNzYgNjU1MzUgZg0KMDAwMDAwMDI3NyA2NTUzNSBmDQowMDAwMDAwMjc4IDY1NTM1IGYNCjAw
MDAwMDAyNzkgNjU1MzUgZg0KMDAwMDAwMDI4MCA2NTUzNSBmDQowMDAwMDAwMjgxIDY1NTM1IGYN
CjAwMDAwMDAyODIgNjU1MzUgZg0KMDAwMDAwMDI4MyA2NTUzNSBmDQowMDAwMDAwMjg0IDY1NTM1
IGYNCjAwMDAwMDAyODUgNjU1MzUgZg0KMDAwMDAwMDI4NiA2NTUzNSBmDQowMDAwMDAwMjg3IDY1
NTM1IGYNCjAwMDAwMDAyODggNjU1MzUgZg0KMDAwMDAwMDI4OSA2NTUzNSBmDQowMDAwMDAwMjkw
IDY1NTM1IGYNCjAwMDAwMDAyOTEgNjU1MzUgZg0KMDAwMDAwMDI5MiA2NTUzNSBmDQowMDAwMDAw
MjkzIDY1NTM1IGYNCjAwMDAwMDAyOTQgNjU1MzUgZg0KMDAwMDAwMDI5NSA2NTUzNSBmDQowMDAw
MDAwMjk2IDY1NTM1IGYNCjAwMDAwMDAyOTcgNjU1MzUgZg0KMDAwMDAwMDI5OCA2NTUzNSBmDQow
MDAwMDAwMjk5IDY1NTM1IGYNCjAwMDAwMDAzMDAgNjU1MzUgZg0KMDAwMDAwMDMwMSA2NTUzNSBm
DQowMDAwMDAwMzAyIDY1NTM1IGYNCjAwMDAwMDAzMDMgNjU1MzUgZg0KMDAwMDAwMDMwNCA2NTUz
NSBmDQowMDAwMDAwMzA1IDY1NTM1IGYNCjAwMDAwMDAzMDYgNjU1MzUgZg0KMDAwMDAwMDMwNyA2
NTUzNSBmDQowMDAwMDAwMzA4IDY1NTM1IGYNCjAwMDAwMDAzMDkgNjU1MzUgZg0KMDAwMDAwMDMx
MCA2NTUzNSBmDQowMDAwMDAwMzExIDY1NTM1IGYNCjAwMDAwMDAzMTIgNjU1MzUgZg0KMDAwMDAw
MDMxMyA2NTUzNSBmDQowMDAwMDAwMzE0IDY1NTM1IGYNCjAwMDAwMDAzMTUgNjU1MzUgZg0KMDAw
MDAwMDMxNiA2NTUzNSBmDQowMDAwMDAwMzE3IDY1NTM1IGYNCjAwMDAwMDAzMTggNjU1MzUgZg0K
MDAwMDAwMDMxOSA2NTUzNSBmDQowMDAwMDAwMzIwIDY1NTM1IGYNCjAwMDAwMDAzMjEgNjU1MzUg
Zg0KMDAwMDAwMDMyMiA2NTUzNSBmDQowMDAwMDAwMzIzIDY1NTM1IGYNCjAwMDAwMDAzMjQgNjU1
MzUgZg0KMDAwMDAwMDMyNSA2NTUzNSBmDQowMDAwMDAwMzI2IDY1NTM1IGYNCjAwMDAwMDAzMjcg
NjU1MzUgZg0KMDAwMDAwMDMyOCA2NTUzNSBmDQowMDAwMDAwMzI5IDY1NTM1IGYNCjAwMDAwMDAz
MzAgNjU1MzUgZg0KMDAwMDAwMDMzMSA2NTUzNSBmDQowMDAwMDAwMzMyIDY1NTM1IGYNCjAwMDAw
MDAzMzMgNjU1MzUgZg0KMDAwMDAwMDMzNCA2NTUzNSBmDQowMDAwMDAwMzM1IDY1NTM1IGYNCjAw
MDAwMDAzMzYgNjU1MzUgZg0KMDAwMDAwMDMzNyA2NTUzNSBmDQowMDAwMDAwMzM4IDY1NTM1IGYN
CjAwMDAwMDAzMzkgNjU1MzUgZg0KMDAwMDAwMDM0MCA2NTUzNSBmDQowMDAwMDAwMzQxIDY1NTM1
IGYNCjAwMDAwMDAzNDIgNjU1MzUgZg0KMDAwMDAwMDM0MyA2NTUzNSBmDQowMDAwMDAwMzQ0IDY1
NTM1IGYNCjAwMDAwMDAzNDUgNjU1MzUgZg0KMDAwMDAwMDM0NiA2NTUzNSBmDQowMDAwMDAwMzQ3
IDY1NTM1IGYNCjAwMDAwMDAzNDggNjU1MzUgZg0KMDAwMDAwMDM0OSA2NTUzNSBmDQowMDAwMDAw
MzUwIDY1NTM1IGYNCjAwMDAwMDAzNTEgNjU1MzUgZg0KMDAwMDAwMDM1MiA2NTUzNSBmDQowMDAw
MDAwMzUzIDY1NTM1IGYNCjAwMDAwMDAzNTQgNjU1MzUgZg0KMDAwMDAwMDM1NSA2NTUzNSBmDQow
MDAwMDAwMzU2IDY1NTM1IGYNCjAwMDAwMDAzNTcgNjU1MzUgZg0KMDAwMDAwMDM1OCA2NTUzNSBm
DQowMDAwMDAwMzU5IDY1NTM1IGYNCjAwMDAwMDAzNjAgNjU1MzUgZg0KMDAwMDAwMDM2MSA2NTUz
NSBmDQowMDAwMDAwMzYyIDY1NTM1IGYNCjAwMDAwMDAzNjMgNjU1MzUgZg0KMDAwMDAwMDM2NCA2
NTUzNSBmDQowMDAwMDAwMzY1IDY1NTM1IGYNCjAwMDAwMDAzNjYgNjU1MzUgZg0KMDAwMDAwMDM2
NyA2NTUzNSBmDQowMDAwMDAwMzY4IDY1NTM1IGYNCjAwMDAwMDAzNjkgNjU1MzUgZg0KMDAwMDAw
MDM3MCA2NTUzNSBmDQowMDAwMDAwMzcxIDY1NTM1IGYNCjAwMDAwMDAzNzIgNjU1MzUgZg0KMDAw
MDAwMDM3MyA2NTUzNSBmDQowMDAwMDAwMzc0IDY1NTM1IGYNCjAwMDAwMDAzNzUgNjU1MzUgZg0K
MDAwMDAwMDM3NiA2NTUzNSBmDQowMDAwMDAwMzc3IDY1NTM1IGYNCjAwMDAwMDAzNzggNjU1MzUg
Zg0KMDAwMDAwMDM3OSA2NTUzNSBmDQowMDAwMDAwMzgwIDY1NTM1IGYNCjAwMDAwMDAzODEgNjU1
MzUgZg0KMDAwMDAwMDM4MiA2NTUzNSBmDQowMDAwMDAwMzgzIDY1NTM1IGYNCjAwMDAwMDAzODQg
NjU1MzUgZg0KMDAwMDAwMDM4NSA2NTUzNSBmDQowMDAwMDAwMzg2IDY1NTM1IGYNCjAwMDAwMDAz
ODcgNjU1MzUgZg0KMDAwMDAwMDM4OCA2NTUzNSBmDQowMDAwMDAwMzg5IDY1NTM1IGYNCjAwMDAw
MDAzOTAgNjU1MzUgZg0KMDAwMDAwMDM5MSA2NTUzNSBmDQowMDAwMDAwMzkyIDY1NTM1IGYNCjAw
MDAwMDAzOTMgNjU1MzUgZg0KMDAwMDAwMDM5NCA2NTUzNSBmDQowMDAwMDAwMzk1IDY1NTM1IGYN
CjAwMDAwMDAzOTYgNjU1MzUgZg0KMDAwMDAwMDM5NyA2NTUzNSBmDQowMDAwMDAwMzk4IDY1NTM1
IGYNCjAwMDAwMDAzOTkgNjU1MzUgZg0KMDAwMDAwMDQwMCA2NTUzNSBmDQowMDAwMDAwNDAxIDY1
NTM1IGYNCjAwMDAwMDA0MDIgNjU1MzUgZg0KMDAwMDAwMDQwMyA2NTUzNSBmDQowMDAwMDAwNDA0
IDY1NTM1IGYNCjAwMDAwMDA0MDUgNjU1MzUgZg0KMDAwMDAwMDQwNiA2NTUzNSBmDQowMDAwMDAw
NDA3IDY1NTM1IGYNCjAwMDAwMDA0MDggNjU1MzUgZg0KMDAwMDAwMDQwOSA2NTUzNSBmDQowMDAw
MDAwNDEwIDY1NTM1IGYNCjAwMDAwMDA0MTEgNjU1MzUgZg0KMDAwMDAwMDQxMiA2NTUzNSBmDQow
MDAwMDAwNDEzIDY1NTM1IGYNCjAwMDAwMDA0MTQgNjU1MzUgZg0KMDAwMDAwMDQxNSA2NTUzNSBm
DQowMDAwMDAwNDE2IDY1NTM1IGYNCjAwMDAwMDA0MTcgNjU1MzUgZg0KMDAwMDAwMDQxOCA2NTUz
NSBmDQowMDAwMDAwNDE5IDY1NTM1IGYNCjAwMDAwMDA0MjAgNjU1MzUgZg0KMDAwMDAwMDQyMSA2
NTUzNSBmDQowMDAwMDAwNDIyIDY1NTM1IGYNCjAwMDAwMDA0MjMgNjU1MzUgZg0KMDAwMDAwMDQy
NCA2NTUzNSBmDQowMDAwMDAwNDI1IDY1NTM1IGYNCjAwMDAwMDA0MjYgNjU1MzUgZg0KMDAwMDAw
MDQyNyA2NTUzNSBmDQowMDAwMDAwNDI4IDY1NTM1IGYNCjAwMDAwMDA0MjkgNjU1MzUgZg0KMDAw
MDAwMDQzMCA2NTUzNSBmDQowMDAwMDAwNDMxIDY1NTM1IGYNCjAwMDAwMDA0MzIgNjU1MzUgZg0K
MDAwMDAwMDQzMyA2NTUzNSBmDQowMDAwMDAwNDM0IDY1NTM1IGYNCjAwMDAwMDA0MzUgNjU1MzUg
Zg0KMDAwMDAwMDQzNiA2NTUzNSBmDQowMDAwMDAwNDM3IDY1NTM1IGYNCjAwMDAwMDA0MzggNjU1
MzUgZg0KMDAwMDAwMDQzOSA2NTUzNSBmDQowMDAwMDAwNDQwIDY1NTM1IGYNCjAwMDAwMDA0NDEg
NjU1MzUgZg0KMDAwMDAwMDQ0MiA2NTUzNSBmDQowMDAwMDAwNDQzIDY1NTM1IGYNCjAwMDAwMDA0
NDQgNjU1MzUgZg0KMDAwMDAwMDQ0NSA2NTUzNSBmDQowMDAwMDAwNDQ2IDY1NTM1IGYNCjAwMDAw
MDA0NDcgNjU1MzUgZg0KMDAwMDAwMDQ0OCA2NTUzNSBmDQowMDAwMDAwNDQ5IDY1NTM1IGYNCjAw
MDAwMDA0NTAgNjU1MzUgZg0KMDAwMDAwMDQ1MSA2NTUzNSBmDQowMDAwMDAwNDUyIDY1NTM1IGYN
CjAwMDAwMDA0NTMgNjU1MzUgZg0KMDAwMDAwMDQ1NCA2NTUzNSBmDQowMDAwMDAwNDU1IDY1NTM1
IGYNCjAwMDAwMDA0NTYgNjU1MzUgZg0KMDAwMDAwMDQ1NyA2NTUzNSBmDQowMDAwMDAwNDU4IDY1
NTM1IGYNCjAwMDAwMDA0NTkgNjU1MzUgZg0KMDAwMDAwMDQ2MCA2NTUzNSBmDQowMDAwMDAwNDYx
IDY1NTM1IGYNCjAwMDAwMDA0NjIgNjU1MzUgZg0KMDAwMDAwMDQ2MyA2NTUzNSBmDQowMDAwMDAw
NDY0IDY1NTM1IGYNCjAwMDAwMDA0NjUgNjU1MzUgZg0KMDAwMDAwMDQ2NiA2NTUzNSBmDQowMDAw
MDAwNDY3IDY1NTM1IGYNCjAwMDAwMDA0NjggNjU1MzUgZg0KMDAwMDAwMDQ2OSA2NTUzNSBmDQow
MDAwMDAwNDcwIDY1NTM1IGYNCjAwMDAwMDA0NzEgNjU1MzUgZg0KMDAwMDAwMDQ3MiA2NTUzNSBm
DQowMDAwMDAwNDczIDY1NTM1IGYNCjAwMDAwMDA0NzQgNjU1MzUgZg0KMDAwMDAwMDQ3NSA2NTUz
NSBmDQowMDAwMDAwNDc2IDY1NTM1IGYNCjAwMDAwMDA0NzcgNjU1MzUgZg0KMDAwMDAwMDQ3OCA2
NTUzNSBmDQowMDAwMDAwNDc5IDY1NTM1IGYNCjAwMDAwMDA0ODAgNjU1MzUgZg0KMDAwMDAwMDQ4
MSA2NTUzNSBmDQowMDAwMDAwNDgyIDY1NTM1IGYNCjAwMDAwMDA0ODMgNjU1MzUgZg0KMDAwMDAw
MDQ4NCA2NTUzNSBmDQowMDAwMDAwNDg1IDY1NTM1IGYNCjAwMDAwMDA0ODYgNjU1MzUgZg0KMDAw
MDAwMDQ4NyA2NTUzNSBmDQowMDAwMDAwNDg4IDY1NTM1IGYNCjAwMDAwMDA0ODkgNjU1MzUgZg0K
MDAwMDAwMDQ5MCA2NTUzNSBmDQowMDAwMDAwNDkxIDY1NTM1IGYNCjAwMDAwMDA0OTIgNjU1MzUg
Zg0KMDAwMDAwMDQ5MyA2NTUzNSBmDQowMDAwMDAwNDk0IDY1NTM1IGYNCjAwMDAwMDA0OTUgNjU1
MzUgZg0KMDAwMDAwMDQ5NiA2NTUzNSBmDQowMDAwMDAwNDk3IDY1NTM1IGYNCjAwMDAwMDA0OTgg
NjU1MzUgZg0KMDAwMDAwMDQ5OSA2NTUzNSBmDQowMDAwMDAwNTAwIDY1NTM1IGYNCjAwMDAwMDA1
MDEgNjU1MzUgZg0KMDAwMDAwMDUwMiA2NTUzNSBmDQowMDAwMDAwNTAzIDY1NTM1IGYNCjAwMDAw
MDA1MDQgNjU1MzUgZg0KMDAwMDAwMDUwNSA2NTUzNSBmDQowMDAwMDAwNTA2IDY1NTM1IGYNCjAw
MDAwMDA1MDcgNjU1MzUgZg0KMDAwMDAwMDUwOCA2NTUzNSBmDQowMDAwMDAwNTA5IDY1NTM1IGYN
CjAwMDAwMDA1MTAgNjU1MzUgZg0KMDAwMDAwMDUxMSA2NTUzNSBmDQowMDAwMDAwNTEyIDY1NTM1
IGYNCjAwMDAwMDA1MTMgNjU1MzUgZg0KMDAwMDAwMDUxNCA2NTUzNSBmDQowMDAwMDAwNTE1IDY1
NTM1IGYNCjAwMDAwMDA1MTYgNjU1MzUgZg0KMDAwMDAwMDUxNyA2NTUzNSBmDQowMDAwMDAwNTE4
IDY1NTM1IGYNCjAwMDAwMDA1MTkgNjU1MzUgZg0KMDAwMDAwMDUyMCA2NTUzNSBmDQowMDAwMDAw
NTIxIDY1NTM1IGYNCjAwMDAwMDA1MjIgNjU1MzUgZg0KMDAwMDAwMDUyMyA2NTUzNSBmDQowMDAw
MDAwNTI0IDY1NTM1IGYNCjAwMDAwMDA1MjUgNjU1MzUgZg0KMDAwMDAwMDUyNiA2NTUzNSBmDQow
MDAwMDAwNTI3IDY1NTM1IGYNCjAwMDAwMDA1MjggNjU1MzUgZg0KMDAwMDAwMDUyOSA2NTUzNSBm
DQowMDAwMDAwNTMwIDY1NTM1IGYNCjAwMDAwMDA1MzEgNjU1MzUgZg0KMDAwMDAwMDUzMiA2NTUz
NSBmDQowMDAwMDAwNTMzIDY1NTM1IGYNCjAwMDAwMDA1MzQgNjU1MzUgZg0KMDAwMDAwMDUzNSA2
NTUzNSBmDQowMDAwMDAwNTM2IDY1NTM1IGYNCjAwMDAwMDA1MzcgNjU1MzUgZg0KMDAwMDAwMDUz
OCA2NTUzNSBmDQowMDAwMDAwNTM5IDY1NTM1IGYNCjAwMDAwMDA1NDAgNjU1MzUgZg0KMDAwMDAw
MDU0MSA2NTUzNSBmDQowMDAwMDAwNTQyIDY1NTM1IGYNCjAwMDAwMDA1NDMgNjU1MzUgZg0KMDAw
MDAwMDU0NCA2NTUzNSBmDQowMDAwMDAwNTQ1IDY1NTM1IGYNCjAwMDAwMDA1NDYgNjU1MzUgZg0K
MDAwMDAwMDU0NyA2NTUzNSBmDQowMDAwMDAwNTQ4IDY1NTM1IGYNCjAwMDAwMDA1NDkgNjU1MzUg
Zg0KMDAwMDAwMDU1MCA2NTUzNSBmDQowMDAwMDAwNTUxIDY1NTM1IGYNCjAwMDAwMDA1NTIgNjU1
MzUgZg0KMDAwMDAwMDU1MyA2NTUzNSBmDQowMDAwMDAwNTU0IDY1NTM1IGYNCjAwMDAwMDA1NTUg
NjU1MzUgZg0KMDAwMDAwMDU1NiA2NTUzNSBmDQowMDAwMDAwNTU3IDY1NTM1IGYNCjAwMDAwMDA1
NTggNjU1MzUgZg0KMDAwMDAwMDU1OSA2NTUzNSBmDQowMDAwMDAwNTYwIDY1NTM1IGYNCjAwMDAw
MDA1NjEgNjU1MzUgZg0KMDAwMDAwMDU2MiA2NTUzNSBmDQowMDAwMDAwNTYzIDY1NTM1IGYNCjAw
MDAwMDA1NjQgNjU1MzUgZg0KMDAwMDAwMDU2NSA2NTUzNSBmDQowMDAwMDAwNTY2IDY1NTM1IGYN
CjAwMDAwMDA1NjcgNjU1MzUgZg0KMDAwMDAwMDU2OCA2NTUzNSBmDQowMDAwMDAwNTY5IDY1NTM1
IGYNCjAwMDAwMDA1NzAgNjU1MzUgZg0KMDAwMDAwMDU3MSA2NTUzNSBmDQowMDAwMDAwNTcyIDY1
NTM1IGYNCjAwMDAwMDA1NzMgNjU1MzUgZg0KMDAwMDAwMDU3NCA2NTUzNSBmDQowMDAwMDAwNTc1
IDY1NTM1IGYNCjAwMDAwMDA1NzYgNjU1MzUgZg0KMDAwMDAwMDU3NyA2NTUzNSBmDQowMDAwMDAw
NTc4IDY1NTM1IGYNCjAwMDAwMDA1NzkgNjU1MzUgZg0KMDAwMDAwMDU4MCA2NTUzNSBmDQowMDAw
MDAwNTgxIDY1NTM1IGYNCjAwMDAwMDA1ODIgNjU1MzUgZg0KMDAwMDAwMDU4MyA2NTUzNSBmDQow
MDAwMDAwNTg0IDY1NTM1IGYNCjAwMDAwMDA1ODUgNjU1MzUgZg0KMDAwMDAwMDU4NiA2NTUzNSBm
DQowMDAwMDAwNTg3IDY1NTM1IGYNCjAwMDAwMDA1ODggNjU1MzUgZg0KMDAwMDAwMDU4OSA2NTUz
NSBmDQowMDAwMDAwNTkwIDY1NTM1IGYNCjAwMDAwMDA1OTEgNjU1MzUgZg0KMDAwMDAwMDU5MiA2
NTUzNSBmDQowMDAwMDAwNTkzIDY1NTM1IGYNCjAwMDAwMDA1OTQgNjU1MzUgZg0KMDAwMDAwMDU5
NSA2NTUzNSBmDQowMDAwMDAwNTk2IDY1NTM1IGYNCjAwMDAwMDA1OTcgNjU1MzUgZg0KMDAwMDAw
MDU5OCA2NTUzNSBmDQowMDAwMDAwNTk5IDY1NTM1IGYNCjAwMDAwMDA2MDAgNjU1MzUgZg0KMDAw
MDAwMDYwMSA2NTUzNSBmDQowMDAwMDAwNjAyIDY1NTM1IGYNCjAwMDAwMDA2MDMgNjU1MzUgZg0K
MDAwMDAwMDYwNCA2NTUzNSBmDQowMDAwMDAwNjA1IDY1NTM1IGYNCjAwMDAwMDA2MDYgNjU1MzUg
Zg0KMDAwMDAwMDYwNyA2NTUzNSBmDQowMDAwMDAwNjA4IDY1NTM1IGYNCjAwMDAwMDA2MDkgNjU1
MzUgZg0KMDAwMDAwMDYxMCA2NTUzNSBmDQowMDAwMDAwNjExIDY1NTM1IGYNCjAwMDAwMDA2MTIg
NjU1MzUgZg0KMDAwMDAwMDYxMyA2NTUzNSBmDQowMDAwMDAwNjE0IDY1NTM1IGYNCjAwMDAwMDA2
MTUgNjU1MzUgZg0KMDAwMDAwMDYxNiA2NTUzNSBmDQowMDAwMDAwNjE3IDY1NTM1IGYNCjAwMDAw
MDA2MTggNjU1MzUgZg0KMDAwMDAwMDYxOSA2NTUzNSBmDQowMDAwMDAwNjIwIDY1NTM1IGYNCjAw
MDAwMDA2MjEgNjU1MzUgZg0KMDAwMDAwMDYyMiA2NTUzNSBmDQowMDAwMDAwNjIzIDY1NTM1IGYN
CjAwMDAwMDA2MjQgNjU1MzUgZg0KMDAwMDAwMDYyNSA2NTUzNSBmDQowMDAwMDAwNjI2IDY1NTM1
IGYNCjAwMDAwMDA2MjcgNjU1MzUgZg0KMDAwMDAwMDYyOCA2NTUzNSBmDQowMDAwMDAwNjI5IDY1
NTM1IGYNCjAwMDAwMDA2MzAgNjU1MzUgZg0KMDAwMDAwMDYzMSA2NTUzNSBmDQowMDAwMDAwNjMy
IDY1NTM1IGYNCjAwMDAwMDA2MzMgNjU1MzUgZg0KMDAwMDAwMDYzNCA2NTUzNSBmDQowMDAwMDAw
NjM1IDY1NTM1IGYNCjAwMDAwMDA2MzYgNjU1MzUgZg0KMDAwMDAwMDYzNyA2NTUzNSBmDQowMDAw
MDAwNjM4IDY1NTM1IGYNCjAwMDAwMDA2MzkgNjU1MzUgZg0KMDAwMDAwMDY0MCA2NTUzNSBmDQow
MDAwMDAwNjQxIDY1NTM1IGYNCjAwMDAwMDA2NDIgNjU1MzUgZg0KMDAwMDAwMDY0MyA2NTUzNSBm
DQowMDAwMDAwNjQ0IDY1NTM1IGYNCjAwMDAwMDA2NDUgNjU1MzUgZg0KMDAwMDAwMDY0NiA2NTUz
NSBmDQowMDAwMDAwNjQ3IDY1NTM1IGYNCjAwMDAwMDA2NDggNjU1MzUgZg0KMDAwMDAwMDY0OSA2
NTUzNSBmDQowMDAwMDAwNjUwIDY1NTM1IGYNCjAwMDAwMDA2NTEgNjU1MzUgZg0KMDAwMDAwMDY1
MiA2NTUzNSBmDQowMDAwMDAwNjUzIDY1NTM1IGYNCjAwMDAwMDA2NTQgNjU1MzUgZg0KMDAwMDAw
MDY1NSA2NTUzNSBmDQowMDAwMDAwNjU2IDY1NTM1IGYNCjAwMDAwMDA2NTcgNjU1MzUgZg0KMDAw
MDAwMDY1OCA2NTUzNSBmDQowMDAwMDAwNjU5IDY1NTM1IGYNCjAwMDAwMDA2NjAgNjU1MzUgZg0K
MDAwMDAwMDY2MSA2NTUzNSBmDQowMDAwMDAwNjYyIDY1NTM1IGYNCjAwMDAwMDA2NjMgNjU1MzUg
Zg0KMDAwMDAwMDY2NCA2NTUzNSBmDQowMDAwMDAwNjY1IDY1NTM1IGYNCjAwMDAwMDA2NjYgNjU1
MzUgZg0KMDAwMDAwMDY2NyA2NTUzNSBmDQowMDAwMDAwNjY4IDY1NTM1IGYNCjAwMDAwMDA2Njkg
NjU1MzUgZg0KMDAwMDAwMDY3MCA2NTUzNSBmDQowMDAwMDAwNjcxIDY1NTM1IGYNCjAwMDAwMDA2
NzIgNjU1MzUgZg0KMDAwMDAwMDY3MyA2NTUzNSBmDQowMDAwMDAwNjc0IDY1NTM1IGYNCjAwMDAw
MDA2NzUgNjU1MzUgZg0KMDAwMDAwMDY3NiA2NTUzNSBmDQowMDAwMDAwNjc3IDY1NTM1IGYNCjAw
MDAwMDA2NzggNjU1MzUgZg0KMDAwMDAwMDY3OSA2NTUzNSBmDQowMDAwMDAwNjgwIDY1NTM1IGYN
CjAwMDAwMDA2ODEgNjU1MzUgZg0KMDAwMDAwMDY4MiA2NTUzNSBmDQowMDAwMDAwNjgzIDY1NTM1
IGYNCjAwMDAwMDA2ODQgNjU1MzUgZg0KMDAwMDAwMDY4NSA2NTUzNSBmDQowMDAwMDAwNjg2IDY1
NTM1IGYNCjAwMDAwMDA2ODcgNjU1MzUgZg0KMDAwMDAwMDY4OCA2NTUzNSBmDQowMDAwMDAwNjg5
IDY1NTM1IGYNCjAwMDAwMDA2OTAgNjU1MzUgZg0KMDAwMDAwMDY5MSA2NTUzNSBmDQowMDAwMDAw
NjkyIDY1NTM1IGYNCjAwMDAwMDA2OTMgNjU1MzUgZg0KMDAwMDAwMDY5NCA2NTUzNSBmDQowMDAw
MDAwNjk1IDY1NTM1IGYNCjAwMDAwMDA2OTYgNjU1MzUgZg0KMDAwMDAwMDY5NyA2NTUzNSBmDQow
MDAwMDAwNjk4IDY1NTM1IGYNCjAwMDAwMDA2OTkgNjU1MzUgZg0KMDAwMDAwMDcwMCA2NTUzNSBm
DQowMDAwMDAwNzAxIDY1NTM1IGYNCjAwMDAwMDA3MDIgNjU1MzUgZg0KMDAwMDAwMDcwMyA2NTUz
NSBmDQowMDAwMDAwNzA0IDY1NTM1IGYNCjAwMDAwMDA3MDUgNjU1MzUgZg0KMDAwMDAwMDcwNiA2
NTUzNSBmDQowMDAwMDAwNzA3IDY1NTM1IGYNCjAwMDAwMDA3MDggNjU1MzUgZg0KMDAwMDAwMDcw
OSA2NTUzNSBmDQowMDAwMDAwNzEwIDY1NTM1IGYNCjAwMDAwMDA3MTEgNjU1MzUgZg0KMDAwMDAw
MDcxMiA2NTUzNSBmDQowMDAwMDAwNzEzIDY1NTM1IGYNCjAwMDAwMDA3MTQgNjU1MzUgZg0KMDAw
MDAwMDcxNSA2NTUzNSBmDQowMDAwMDAwNzE2IDY1NTM1IGYNCjAwMDAwMDA3MTcgNjU1MzUgZg0K
MDAwMDAwMDcxOCA2NTUzNSBmDQowMDAwMDAwNzE5IDY1NTM1IGYNCjAwMDAwMDA3MjAgNjU1MzUg
Zg0KMDAwMDAwMDcyMSA2NTUzNSBmDQowMDAwMDAwNzIyIDY1NTM1IGYNCjAwMDAwMDA3MjMgNjU1
MzUgZg0KMDAwMDAwMDcyNCA2NTUzNSBmDQowMDAwMDAwNzI1IDY1NTM1IGYNCjAwMDAwMDA3MjYg
NjU1MzUgZg0KMDAwMDAwMDcyNyA2NTUzNSBmDQowMDAwMDAwNzI4IDY1NTM1IGYNCjAwMDAwMDA3
MjkgNjU1MzUgZg0KMDAwMDAwMDczMCA2NTUzNSBmDQowMDAwMDAwNzMxIDY1NTM1IGYNCjAwMDAw
MDA3MzIgNjU1MzUgZg0KMDAwMDAwMDczMyA2NTUzNSBmDQowMDAwMDAwNzM0IDY1NTM1IGYNCjAw
MDAwMDA3MzUgNjU1MzUgZg0KMDAwMDAwMDczNiA2NTUzNSBmDQowMDAwMDAwNzM3IDY1NTM1IGYN
CjAwMDAwMDA3MzggNjU1MzUgZg0KMDAwMDAwMDczOSA2NTUzNSBmDQowMDAwMDAwNzQwIDY1NTM1
IGYNCjAwMDAwMDA3NDEgNjU1MzUgZg0KMDAwMDAwMDc0MiA2NTUzNSBmDQowMDAwMDAwNzQzIDY1
NTM1IGYNCjAwMDAwMDA3NDQgNjU1MzUgZg0KMDAwMDAwMDc0NSA2NTUzNSBmDQowMDAwMDAwNzQ2
IDY1NTM1IGYNCjAwMDAwMDA3NDcgNjU1MzUgZg0KMDAwMDAwMDc0OCA2NTUzNSBmDQowMDAwMDAw
NzQ5IDY1NTM1IGYNCjAwMDAwMDA3NTAgNjU1MzUgZg0KMDAwMDAwMDc1MSA2NTUzNSBmDQowMDAw
MDAwNzUyIDY1NTM1IGYNCjAwMDAwMDA3NTMgNjU1MzUgZg0KMDAwMDAwMDc1NCA2NTUzNSBmDQow
MDAwMDAwNzU1IDY1NTM1IGYNCjAwMDAwMDA3NTYgNjU1MzUgZg0KMDAwMDAwMDc1NyA2NTUzNSBm
DQowMDAwMDAwNzU4IDY1NTM1IGYNCjAwMDAwMDA3NTkgNjU1MzUgZg0KMDAwMDAwMDc2MCA2NTUz
NSBmDQowMDAwMDAwNzYxIDY1NTM1IGYNCjAwMDAwMDA3NjIgNjU1MzUgZg0KMDAwMDAwMDc2MyA2
NTUzNSBmDQowMDAwMDAwNzY0IDY1NTM1IGYNCjAwMDAwMDA3NjUgNjU1MzUgZg0KMDAwMDAwMDc2
NiA2NTUzNSBmDQowMDAwMDAwNzY3IDY1NTM1IGYNCjAwMDAwMDA3NjggNjU1MzUgZg0KMDAwMDAw
MDc2OSA2NTUzNSBmDQowMDAwMDAwNzcwIDY1NTM1IGYNCjAwMDAwMDA3NzEgNjU1MzUgZg0KMDAw
MDAwMDc3MiA2NTUzNSBmDQowMDAwMDAwNzczIDY1NTM1IGYNCjAwMDAwMDA3NzQgNjU1MzUgZg0K
MDAwMDAwMDc3NSA2NTUzNSBmDQowMDAwMDAwNzc2IDY1NTM1IGYNCjAwMDAwMDA3NzcgNjU1MzUg
Zg0KMDAwMDAwMDc3OCA2NTUzNSBmDQowMDAwMDAwNzc5IDY1NTM1IGYNCjAwMDAwMDA3ODAgNjU1
MzUgZg0KMDAwMDAwMDc4MSA2NTUzNSBmDQowMDAwMDAwNzgyIDY1NTM1IGYNCjAwMDAwMDA3ODMg
NjU1MzUgZg0KMDAwMDAwMDc4NCA2NTUzNSBmDQowMDAwMDAwNzg1IDY1NTM1IGYNCjAwMDAwMDA3
ODYgNjU1MzUgZg0KMDAwMDAwMDc4NyA2NTUzNSBmDQowMDAwMDAwNzg4IDY1NTM1IGYNCjAwMDAw
MDA3ODkgNjU1MzUgZg0KMDAwMDAwMDc5MCA2NTUzNSBmDQowMDAwMDAwNzkxIDY1NTM1IGYNCjAw
MDAwMDA3OTIgNjU1MzUgZg0KMDAwMDAwMDc5MyA2NTUzNSBmDQowMDAwMDAwNzk0IDY1NTM1IGYN
CjAwMDAwMDA3OTUgNjU1MzUgZg0KMDAwMDAwMDc5NiA2NTUzNSBmDQowMDAwMDAwNzk3IDY1NTM1
IGYNCjAwMDAwMDA3OTggNjU1MzUgZg0KMDAwMDAwMDc5OSA2NTUzNSBmDQowMDAwMDAwODAwIDY1
NTM1IGYNCjAwMDAwMDA4MDEgNjU1MzUgZg0KMDAwMDAwMDgwMiA2NTUzNSBmDQowMDAwMDAwODAz
IDY1NTM1IGYNCjAwMDAwMDA4MDQgNjU1MzUgZg0KMDAwMDAwMDgwNSA2NTUzNSBmDQowMDAwMDAw
ODA2IDY1NTM1IGYNCjAwMDAwMDA4MDcgNjU1MzUgZg0KMDAwMDAwMDgwOCA2NTUzNSBmDQowMDAw
MDAwODA5IDY1NTM1IGYNCjAwMDAwMDA4MTAgNjU1MzUgZg0KMDAwMDAwMDgxMSA2NTUzNSBmDQow
MDAwMDAwODEyIDY1NTM1IGYNCjAwMDAwMDA4MTMgNjU1MzUgZg0KMDAwMDAwMDgxNCA2NTUzNSBm
DQowMDAwMDAwODE1IDY1NTM1IGYNCjAwMDAwMDA4MTYgNjU1MzUgZg0KMDAwMDAwMDgxNyA2NTUz
NSBmDQowMDAwMDAwODE4IDY1NTM1IGYNCjAwMDAwMDA4MTkgNjU1MzUgZg0KMDAwMDAwMDgyMCA2
NTUzNSBmDQowMDAwMDAwODIxIDY1NTM1IGYNCjAwMDAwMDA4MjIgNjU1MzUgZg0KMDAwMDAwMDgy
MyA2NTUzNSBmDQowMDAwMDAwODI0IDY1NTM1IGYNCjAwMDAwMDA4MjUgNjU1MzUgZg0KMDAwMDAw
MDgyNiA2NTUzNSBmDQowMDAwMDAwODI3IDY1NTM1IGYNCjAwMDAwMDA4MjggNjU1MzUgZg0KMDAw
MDAwMDgyOSA2NTUzNSBmDQowMDAwMDAwODMwIDY1NTM1IGYNCjAwMDAwMDA4MzEgNjU1MzUgZg0K
MDAwMDAwMDgzMiA2NTUzNSBmDQowMDAwMDAwODMzIDY1NTM1IGYNCjAwMDAwMDA4MzQgNjU1MzUg
Zg0KMDAwMDAwMDgzNSA2NTUzNSBmDQowMDAwMDAwODM2IDY1NTM1IGYNCjAwMDAwMDA4MzcgNjU1
MzUgZg0KMDAwMDAwMDgzOCA2NTUzNSBmDQowMDAwMDAwODM5IDY1NTM1IGYNCjAwMDAwMDA4NDAg
NjU1MzUgZg0KMDAwMDAwMDg0MSA2NTUzNSBmDQowMDAwMDAwODQyIDY1NTM1IGYNCjAwMDAwMDA4
NDMgNjU1MzUgZg0KMDAwMDAwMDg0NCA2NTUzNSBmDQowMDAwMDAwODQ1IDY1NTM1IGYNCjAwMDAw
MDA4NDYgNjU1MzUgZg0KMDAwMDAwMDg0NyA2NTUzNSBmDQowMDAwMDAwODQ4IDY1NTM1IGYNCjAw
MDAwMDA4NDkgNjU1MzUgZg0KMDAwMDAwMDg1MCA2NTUzNSBmDQowMDAwMDAwODUxIDY1NTM1IGYN
CjAwMDAwMDA4NTIgNjU1MzUgZg0KMDAwMDAwMDg1MyA2NTUzNSBmDQowMDAwMDAwODU0IDY1NTM1
IGYNCjAwMDAwMDA4NTUgNjU1MzUgZg0KMDAwMDAwMDg1NiA2NTUzNSBmDQowMDAwMDAwODU3IDY1
NTM1IGYNCjAwMDAwMDA4NTggNjU1MzUgZg0KMDAwMDAwMDg1OSA2NTUzNSBmDQowMDAwMDAwODYw
IDY1NTM1IGYNCjAwMDAwMDA4NjEgNjU1MzUgZg0KMDAwMDAwMDg2MiA2NTUzNSBmDQowMDAwMDAw
ODYzIDY1NTM1IGYNCjAwMDAwMDA4NjQgNjU1MzUgZg0KMDAwMDAwMDg2NSA2NTUzNSBmDQowMDAw
MDAwODY2IDY1NTM1IGYNCjAwMDAwMDA4NjcgNjU1MzUgZg0KMDAwMDAwMDg2OCA2NTUzNSBmDQow
MDAwMDAwODY5IDY1NTM1IGYNCjAwMDAwMDA4NzAgNjU1MzUgZg0KMDAwMDAwMDg3MSA2NTUzNSBm
DQowMDAwMDAwODcyIDY1NTM1IGYNCjAwMDAwMDA4NzMgNjU1MzUgZg0KMDAwMDAwMDg3NCA2NTUz
NSBmDQowMDAwMDAwODc1IDY1NTM1IGYNCjAwMDAwMDA4NzYgNjU1MzUgZg0KMDAwMDAwMDg3NyA2
NTUzNSBmDQowMDAwMDAwODc4IDY1NTM1IGYNCjAwMDAwMDA4NzkgNjU1MzUgZg0KMDAwMDAwMDg4
MCA2NTUzNSBmDQowMDAwMDAwODgxIDY1NTM1IGYNCjAwMDAwMDA4ODIgNjU1MzUgZg0KMDAwMDAw
MDg4MyA2NTUzNSBmDQowMDAwMDAwODg0IDY1NTM1IGYNCjAwMDAwMDA4ODUgNjU1MzUgZg0KMDAw
MDAwMDg4NiA2NTUzNSBmDQowMDAwMDAwODg3IDY1NTM1IGYNCjAwMDAwMDA4ODggNjU1MzUgZg0K
MDAwMDAwMDg4OSA2NTUzNSBmDQowMDAwMDAwODkwIDY1NTM1IGYNCjAwMDAwMDA4OTEgNjU1MzUg
Zg0KMDAwMDAwMDg5MiA2NTUzNSBmDQowMDAwMDAwODkzIDY1NTM1IGYNCjAwMDAwMDA4OTQgNjU1
MzUgZg0KMDAwMDAwMDg5NSA2NTUzNSBmDQowMDAwMDAwODk2IDY1NTM1IGYNCjAwMDAwMDA4OTcg
NjU1MzUgZg0KMDAwMDAwMDg5OCA2NTUzNSBmDQowMDAwMDAwODk5IDY1NTM1IGYNCjAwMDAwMDA5
MDAgNjU1MzUgZg0KMDAwMDAwMDkwMSA2NTUzNSBmDQowMDAwMDAwOTAyIDY1NTM1IGYNCjAwMDAw
MDA5MDMgNjU1MzUgZg0KMDAwMDAwMDkwNCA2NTUzNSBmDQowMDAwMDAwOTA1IDY1NTM1IGYNCjAw
MDAwMDA5MDYgNjU1MzUgZg0KMDAwMDAwMDkwNyA2NTUzNSBmDQowMDAwMDAwOTA4IDY1NTM1IGYN
CjAwMDAwMDA5MDkgNjU1MzUgZg0KMDAwMDAwMDkxMCA2NTUzNSBmDQowMDAwMDAwOTExIDY1NTM1
IGYNCjAwMDAwMDA5MTIgNjU1MzUgZg0KMDAwMDAwMDkxMyA2NTUzNSBmDQowMDAwMDAwOTE0IDY1
NTM1IGYNCjAwMDAwMDA5MTUgNjU1MzUgZg0KMDAwMDAwMDkxNiA2NTUzNSBmDQowMDAwMDAwOTE3
IDY1NTM1IGYNCjAwMDAwMDA5MTggNjU1MzUgZg0KMDAwMDAwMDkxOSA2NTUzNSBmDQowMDAwMDAw
OTIwIDY1NTM1IGYNCjAwMDAwMDA5MjEgNjU1MzUgZg0KMDAwMDAwMDkyMiA2NTUzNSBmDQowMDAw
MDAwOTIzIDY1NTM1IGYNCjAwMDAwMDA5MjQgNjU1MzUgZg0KMDAwMDAwMDkyNSA2NTUzNSBmDQow
MDAwMDAwOTI2IDY1NTM1IGYNCjAwMDAwMDA5MjcgNjU1MzUgZg0KMDAwMDAwMDkyOCA2NTUzNSBm
DQowMDAwMDAwOTI5IDY1NTM1IGYNCjAwMDAwMDA5MzAgNjU1MzUgZg0KMDAwMDAwMDkzMSA2NTUz
NSBmDQowMDAwMDAwOTMyIDY1NTM1IGYNCjAwMDAwMDA5MzMgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMTYwMjI5IDAwMDAwIG4NCjAwMDAxNjA1NTkgMDAwMDAgbg0KMDAwMDE4MTEy
NiAwMDAwMCBuDQowMDAwMTgxNTQ1IDAwMDAwIG4NCjAwMDAyMDg1NjMgMDAwMDAgbg0KMDAwMDIw
ODk5NCAwMDAwMCBuDQowMDAwMjA5MzU1IDAwMDAwIG4NCjAwMDAyMDk1NTcgMDAwMDAgbg0KMDAw
MDIyMTY0OCAwMDAwMCBuDQowMDAwMjIxOTQ5IDAwMDAwIG4NCjAwMDAyMzUxOTQgMDAwMDAgbg0K
MDAwMDIzNTIzOCAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDk0Ni9Sb290IDEgMCBSL0luZm8g
NzcgMCBSL0lEWzw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz48OEMxMjM5OUY3OUZC
RUI0NkI3NTg1QURGM0Q5NDU2NTM+XSA+Pg0Kc3RhcnR4cmVmDQoyMzczNTkNCiUlRU9GDQp4cmVm
DQowIDANCnRyYWlsZXINCjw8L1NpemUgOTQ2L1Jvb3QgMSAwIFIvSW5mbyA3NyAwIFIvSURbPDhD
MTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYz
RDk0NTY1Mz5dIC9QcmV2IDIzNzM1OS9YUmVmU3RtIDIzNTIzOD4+DQpzdGFydHhyZWYNCjI1NjQz
OQ0KJSVFT0Y=

--_002_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233525D395SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Jun 27 06:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 06: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 1SjlXJ-0007IK-Br; Wed, 27 Jun 2012 06:15: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 1SjlXI-0007IF-06
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 06:15:32 +0000
Received: from [85.158.138.51:24207] by server-8.bemta-3.messagelabs.com id
	98/3F-06157-205AAEF4; Wed, 27 Jun 2012 06:15:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340777729!29714803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2998 invoked from network); 27 Jun 2012 06:15:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 06:15:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,481,1336348800"; d="scan'208";a="13236686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 06:15:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 07:15:28 +0100
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 1SjlXE-0004sl-Jd;
	Wed, 27 Jun 2012 06:15:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjlXE-0007Z4-5L;
	Wed, 27 Jun 2012 07:15:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13372-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 07:15:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13372: 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 13372 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13372/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  c6c9d20963d7
baseline version:
 xen                  c6c9d20963d7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 06:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 06: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 1SjlXJ-0007IK-Br; Wed, 27 Jun 2012 06:15: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 1SjlXI-0007IF-06
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 06:15:32 +0000
Received: from [85.158.138.51:24207] by server-8.bemta-3.messagelabs.com id
	98/3F-06157-205AAEF4; Wed, 27 Jun 2012 06:15:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340777729!29714803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2998 invoked from network); 27 Jun 2012 06:15:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 06:15:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,481,1336348800"; d="scan'208";a="13236686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 06:15:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 07:15:28 +0100
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 1SjlXE-0004sl-Jd;
	Wed, 27 Jun 2012 06:15:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjlXE-0007Z4-5L;
	Wed, 27 Jun 2012 07:15:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13372-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 07:15:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13372: 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 13372 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13372/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  c6c9d20963d7
baseline version:
 xen                  c6c9d20963d7

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 07:29:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 07: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 1SjmgU-0007mO-Ip; Wed, 27 Jun 2012 07:29: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 1SjmgT-0007mJ-6z
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 07:29:05 +0000
Received: from [85.158.143.35:24563] by server-3.bemta-4.messagelabs.com id
	74/9F-05808-046BAEF4; Wed, 27 Jun 2012 07:29:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340782143!14028204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16852 invoked from network); 27 Jun 2012 07:29:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 07:29:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13237781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 07:29:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 08:29:00 +0100
Message-ID: <1340782140.14761.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Wed, 27 Jun 2012 08:29:00 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Tim	\(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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, 2012-06-27 at 02:45 +0100, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, June 27, 2012 1:00 AM
> > To: Ian Campbell
> > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > Stefano Stabellini
> > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > guest
> > 
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > >
> > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > So, select a standard VGA card with VBE as the default emulated
> > graphics device.
> > >
> > > I'm not expert on the graphics side of HVM, but on the face of it
> > > switching the default to something more modern seems like a
> > reasonable
> > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > point.
> > >
> > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > 
> > I think it is a good thing.
> > The only thing to keep in mind is that QEMU upstream is switching to
> > 16MB of videoram for stdvga. So at some point in the near future
> > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > the videoram to 16MB too.
> > 
> Yes, we should pay attention to this when using upstream QEMU.
> 
> > 
> > > > It's also a workaround for the following bug.
> > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > >
> > > Do you understand the root cause of that bug?
> > >
> I don't understand the root cause.
> 
> > > It's hard to see how detaching a VF relates to the VGA emulation in use.
> > > Can you explain it? Are you sure you aren't just masking the real issue
> > > here?
> > 
> It's strange that detaching a VF may break the graphics display.
> As it only happens when 'stdvga=0', it might not be a normal usage.
> 
> > Indeed. We cannot possibly accept the patch on the basis that it looks
> > like it is masking an unrelated pci-passthrough bug.
> >
> I don't want to mask that bug, either. :-)
> The following sentence is quoted from xl.cfg man page.
> "If your guest supports VBE 2.0 or later (e.g. Windows XP onwards) 
> then you should enable this (stdvga option)."
> If we set 'stdvga=1', we will not meet the bug (#1812).
> I assume many Xen users (including me) are not very familiar with 'stdvga' and 
> will leave it as default (it's 0 before my patch). 
> If then, users may meet something *strange* like bug #1812.
> I don't think it's friendly to end users, so I set the default value
> of 'stdvga' to '1'.

There are good reasons which justify setting stdvga=1 by default. But
anything to do with #1812 is not one of them. It is obviously wrong to
justify making an unrelated configuration change on the basis that it
hides a bug by default without first understanding the reasons for the
bug.

I certainly hope you are not planning to close #1812 and stop
investigating it if we change the stdvga default.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 07:29:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 07: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 1SjmgU-0007mO-Ip; Wed, 27 Jun 2012 07:29: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 1SjmgT-0007mJ-6z
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 07:29:05 +0000
Received: from [85.158.143.35:24563] by server-3.bemta-4.messagelabs.com id
	74/9F-05808-046BAEF4; Wed, 27 Jun 2012 07:29:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1340782143!14028204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16852 invoked from network); 27 Jun 2012 07:29:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 07:29:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13237781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 07:29:00 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 08:29:00 +0100
Message-ID: <1340782140.14761.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Wed, 27 Jun 2012 08:29:00 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Tim	\(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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, 2012-06-27 at 02:45 +0100, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, June 27, 2012 1:00 AM
> > To: Ian Campbell
> > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > Stefano Stabellini
> > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > guest
> > 
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > >
> > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > So, select a standard VGA card with VBE as the default emulated
> > graphics device.
> > >
> > > I'm not expert on the graphics side of HVM, but on the face of it
> > > switching the default to something more modern seems like a
> > reasonable
> > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > point.
> > >
> > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > 
> > I think it is a good thing.
> > The only thing to keep in mind is that QEMU upstream is switching to
> > 16MB of videoram for stdvga. So at some point in the near future
> > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > the videoram to 16MB too.
> > 
> Yes, we should pay attention to this when using upstream QEMU.
> 
> > 
> > > > It's also a workaround for the following bug.
> > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > >
> > > Do you understand the root cause of that bug?
> > >
> I don't understand the root cause.
> 
> > > It's hard to see how detaching a VF relates to the VGA emulation in use.
> > > Can you explain it? Are you sure you aren't just masking the real issue
> > > here?
> > 
> It's strange that detaching a VF may break the graphics display.
> As it only happens when 'stdvga=0', it might not be a normal usage.
> 
> > Indeed. We cannot possibly accept the patch on the basis that it looks
> > like it is masking an unrelated pci-passthrough bug.
> >
> I don't want to mask that bug, either. :-)
> The following sentence is quoted from xl.cfg man page.
> "If your guest supports VBE 2.0 or later (e.g. Windows XP onwards) 
> then you should enable this (stdvga option)."
> If we set 'stdvga=1', we will not meet the bug (#1812).
> I assume many Xen users (including me) are not very familiar with 'stdvga' and 
> will leave it as default (it's 0 before my patch). 
> If then, users may meet something *strange* like bug #1812.
> I don't think it's friendly to end users, so I set the default value
> of 'stdvga' to '1'.

There are good reasons which justify setting stdvga=1 by default. But
anything to do with #1812 is not one of them. It is obviously wrong to
justify making an unrelated configuration change on the basis that it
hides a bug by default without first understanding the reasons for the
bug.

I certainly hope you are not planning to close #1812 and stop
investigating it if we change the stdvga default.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:15:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08: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 1SjnP9-0000fz-RR; Wed, 27 Jun 2012 08:15:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjnP8-0000fu-Ua
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 08:15:15 +0000
Received: from [85.158.143.35:51767] by server-3.bemta-4.messagelabs.com id
	6D/56-05808-211CAEF4; Wed, 27 Jun 2012 08:15:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340784910!7297271!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15221 invoked from network); 27 Jun 2012 08:15:11 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 08:15:11 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79157977; Wed, 27 Jun 2012 10:15:10 +0200
Message-ID: <1340784903.9444.66.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 10:15:03 +0200
In-Reply-To: <20457.38656.696529.142496@mariner.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
	<CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
	<20457.38656.696529.142496@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5528006897113593129=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5528006897113593129==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-36LPAQ6TjL9c+qaN1ZD7"


--=-36LPAQ6TjL9c+qaN1ZD7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 12:03 +0100, Ian Jackson wrote:
> The conventional approach to this kind of thing is to invent a score
> for sorting etc.  Something like
>     score =3D tuning_parameter * log(freemem) - number_of_domains
> which does sort of roughly the same as your 10% rule if you squint.
>
However, if I go for this approach, I think I should stick to floating
point arith, as I'm not sure I can properly to things like normalization
and take log()-s with integers... :-/

Would that be fine?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-36LPAQ6TjL9c+qaN1ZD7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/qwQcACgkQk4XaBE3IOsSmSACgon+zvf3N0tOyi6QK6kk9kQkG
7NIAoICW+K4/9BA64Xs38arOthce+PKK
=wrjf
-----END PGP SIGNATURE-----

--=-36LPAQ6TjL9c+qaN1ZD7--



--===============5528006897113593129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5528006897113593129==--



From xen-devel-bounces@lists.xen.org Wed Jun 27 08:15:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08: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 1SjnP9-0000fz-RR; Wed, 27 Jun 2012 08:15:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SjnP8-0000fu-Ua
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 08:15:15 +0000
Received: from [85.158.143.35:51767] by server-3.bemta-4.messagelabs.com id
	6D/56-05808-211CAEF4; Wed, 27 Jun 2012 08:15:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340784910!7297271!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15221 invoked from network); 27 Jun 2012 08:15:11 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 08:15:11 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79157977; Wed, 27 Jun 2012 10:15:10 +0200
Message-ID: <1340784903.9444.66.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 10:15:03 +0200
In-Reply-To: <20457.38656.696529.142496@mariner.uk.xensource.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<4FE348C1.5030407@eu.citrix.com> <1340297032.4856.93.camel@Solace>
	<CAFLBxZahf+U1AkXC4fB_By6QxUBbxBMcgDt5XjsRs0DwOKVtgQ@mail.gmail.com>
	<20457.38656.696529.142496@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5528006897113593129=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5528006897113593129==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-36LPAQ6TjL9c+qaN1ZD7"


--=-36LPAQ6TjL9c+qaN1ZD7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-06-26 at 12:03 +0100, Ian Jackson wrote:
> The conventional approach to this kind of thing is to invent a score
> for sorting etc.  Something like
>     score =3D tuning_parameter * log(freemem) - number_of_domains
> which does sort of roughly the same as your 10% rule if you squint.
>
However, if I go for this approach, I think I should stick to floating
point arith, as I'm not sure I can properly to things like normalization
and take log()-s with integers... :-/

Would that be fine?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-36LPAQ6TjL9c+qaN1ZD7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/qwQcACgkQk4XaBE3IOsSmSACgon+zvf3N0tOyi6QK6kk9kQkG
7NIAoICW+K4/9BA64Xs38arOthce+PKK
=wrjf
-----END PGP SIGNATURE-----

--=-36LPAQ6TjL9c+qaN1ZD7--



--===============5528006897113593129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5528006897113593129==--



From xen-devel-bounces@lists.xen.org Wed Jun 27 08:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08:42:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjnp0-0000sA-64; Wed, 27 Jun 2012 08:41:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjnoy-0000s5-JO
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 08:41:56 +0000
Received: from [193.109.254.147:38478] by server-7.bemta-14.messagelabs.com id
	26/ED-29827-357CAEF4; Wed, 27 Jun 2012 08:41:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340786514!6327773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32317 invoked from network); 27 Jun 2012 08:41:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13239652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:41:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:41:54 +0100
Message-ID: <1340786512.29172.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 27 Jun 2012 09:41:52 +0100
In-Reply-To: <20120626225700.GB8676@US-SEA-R8XVZTX>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
	<20120626210906.GA14905@phenom.dumpdata.com>
	<20120626225700.GB8676@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 23:57 +0100, Matt Wilson wrote:
> On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> > > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> > > >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> > > >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > > 
> > > This may be a problem with the guest, rather than a problem with Xen
> > > or the toolstack. I tested on a domU running a 3.2.20-based Linux
> > > kernel. The domU kernel didn't automatically enable the vCPUs after
> > > calling "xl vcpu-set" to increase the allocation.
> > > [...]
> > > 
> > > I've added this as a comment to the bugzilla.
> > 
> > That is a generic bug - its a race in the generic code where
> > the cpuX directory is created; then udev kicks off and tries to
> > echo 1 > cpuX/online (but online hasn't been created yet); the cpu-hotplug
> > code creates 'online' directory.
> > 
> > I've asked Greg KH about it, and here is his take:
> > https://lkml.org/lkml/2012/4/30/198
> > 
> > But I never got to prep a patch. If somebody gets to do it before me,
> > I owe them a beer!
> 
> My problem was that I didn't even have a udev rule to auto-online
> hotplugged CPUs. Everything works as expected after adding the rule
> suggested on the wiki: http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug
> 
> I'm thinking that the bug report is just this well hashed out
> problem. For historical reference, here's the thread discussing the
> behavior change in pv-ops kernels:
>   http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html

I've added a link to that thread to the wiki page.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08:42:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjnp0-0000sA-64; Wed, 27 Jun 2012 08:41:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjnoy-0000s5-JO
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 08:41:56 +0000
Received: from [193.109.254.147:38478] by server-7.bemta-14.messagelabs.com id
	26/ED-29827-357CAEF4; Wed, 27 Jun 2012 08:41:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340786514!6327773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32317 invoked from network); 27 Jun 2012 08:41:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13239652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:41:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:41:54 +0100
Message-ID: <1340786512.29172.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 27 Jun 2012 09:41:52 +0100
In-Reply-To: <20120626225700.GB8676@US-SEA-R8XVZTX>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
	<20120626210906.GA14905@phenom.dumpdata.com>
	<20120626225700.GB8676@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 23:57 +0100, Matt Wilson wrote:
> On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> > > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> > > >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> > > >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > > 
> > > This may be a problem with the guest, rather than a problem with Xen
> > > or the toolstack. I tested on a domU running a 3.2.20-based Linux
> > > kernel. The domU kernel didn't automatically enable the vCPUs after
> > > calling "xl vcpu-set" to increase the allocation.
> > > [...]
> > > 
> > > I've added this as a comment to the bugzilla.
> > 
> > That is a generic bug - its a race in the generic code where
> > the cpuX directory is created; then udev kicks off and tries to
> > echo 1 > cpuX/online (but online hasn't been created yet); the cpu-hotplug
> > code creates 'online' directory.
> > 
> > I've asked Greg KH about it, and here is his take:
> > https://lkml.org/lkml/2012/4/30/198
> > 
> > But I never got to prep a patch. If somebody gets to do it before me,
> > I owe them a beer!
> 
> My problem was that I didn't even have a udev rule to auto-online
> hotplugged CPUs. Everything works as expected after adding the rule
> suggested on the wiki: http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug
> 
> I'm thinking that the bug report is just this well hashed out
> problem. For historical reference, here's the thread discussing the
> behavior change in pv-ops kernels:
>   http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html

I've added a link to that thread to the wiki page.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:51:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjnxe-00011M-6M; Wed, 27 Jun 2012 08:50:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjnxc-00011H-3N
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 08:50:52 +0000
Received: from [193.109.254.147:8138] by server-12.bemta-14.messagelabs.com id
	0C/2E-30461-B69CAEF4; Wed, 27 Jun 2012 08:50:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340787045!3589768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21100 invoked from network); 27 Jun 2012 08:50:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13239916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:50:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:50:45 +0100
Message-ID: <1340787043.29172.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 27 Jun 2012 09:50:43 +0100
In-Reply-To: <20120626165808.GC2058@reaktio.net>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

T24gVHVlLCAyMDEyLTA2LTI2IGF0IDE3OjU4ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUdWUsIEp1biAyNiwgMjAxMiBhdCAwNToyMDozNVBNICswMTAwLCBSb2dlciBQYXUg
TW9ubmUgd3JvdGU6Cj4gPiBJYW4gSmFja3NvbiB3cm90ZToKPiA+ID5Sb2dlciBQYXUgTW9ubmUg
d3JpdGVzICgiW1BBVENIIHY2IDEwLzEzXSBsaWJ4bDogc2V0IG5pYyB0eXBlIHRvIFZJRiBieSBk
ZWZhdWx0Iik6Cj4gPiA+PlNldCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgbmljIGludGVyZmFjZXMg
dG8gVklGLCBzaW5jZSBpdCB1c2VkIHRvIGJlCj4gPiA+PklPRU1VLCBldmVuIGZvciBQViBndWVz
dHMuCj4gPiA+Cj4gPiA+SWYgeW91ciByZW5hbWluZyBvZiBJT0VNVSB0byBWSUZfSU9FTVUgaXMg
Y29ycmVjdCwgZG9lcyB0aGlzIG5vdCBzdG9wCj4gPiA+SFZNIGd1ZXN0cyBnZXR0aW5nIGVtdWxh
dGVkIG5ldHdvcmsgaW50ZXJmYWNlcyBieSBkZWZhdWx0ID8KPiA+IAo+ID4gWWVzLCBpZiB5b3Ug
d2FudCBlbXVsYXRlZCBpbnRlcmZhY2VzIHdpdGggSFZNIGd1ZXN0cyB5b3Ugc2hvdWxkIHVzZQo+
ID4gJ3R5cGU9aW9lbXUnLCB0aGF0J3MgaG93IGl0IGhhcyBhbHdheXMgYmVlbiByaWdodD8KPiA+
IAo+IAo+IFdpdGggWGVuIDQuMSB5b3UgZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9aW9lbXUiLiBF
bXVsYXRlZCBpbnRlcmZhY2VzIHNlZW0gdG8gd29yayBPSyB3aXRob3V0ICJ0eXBlPWlvZW11Ii4K
PiAoYXQgbGVhc3Qgd2l0aCB4bS94ZW5kKS4gQW5kIGlmIHlvdSBhY3R1YWxseSBkbyBhZGQgInR5
cGU9aW9lbXUiIGl0IHdpbGwgYnJlYWsgUFZIVk0gZm9yIExpbnV4IGd1ZXN0cy4uCj4gCj4gUXVv
dGUgZnJvbTogaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1hlbkxpbnV4UFZvbkhWTWRyaXZlcnMK
PiAKPiAiTk9URSEgSWYgeW91IGhhdmUgInR5cGU9aW9lbXUiIHNwZWNpZmllZCBmb3IgdGhlICJ2
aWYiLWxpbmUsIFBWSFZNCj4gZHJpdmVycyBXSUxMIE5PVCB3b3JrISBEb24ndCBzcGVjaWZ5ICJ0
eXBlIiBwYXJhbWV0ZXIgZm9yIHRoZSB2aWYuCj4gKHdpdGggdHlwZT1pb2VtdSB0aGUgcHZodm0g
bmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3MgZnVsbCBvZgo+IHplcm9lcyAtIGFu
ZCB0aHVzIHdvbid0IHdvcmshKS4gIgoKbWFjPTAwOjAwOjAwOjAwOjAwIGlzIGNlcnRhaW5seSBh
IGJ1ZywgaWYgKGxpYil4bCBiZWhhdmVzIHRoaXMgd2F5IHRvbwp0aGVuIHdlIHNob3VsZCBmaXgg
aXQuCgpCdXQgc3VyZWx5IHR5cGU9aW9lbXUgaXMgc3VwcG9zZWQgdG8gbWVhbiAib25seSBlbXVs
YXRlZCI/IEluIHdoaWNoIGNhc2UKdGhlIGFjdHVhbCB4ZW5kIGJ1ZyBpcyB0aGF0IGl0IGNyZWF0
ZWQgYSBQViBWSUYgYXQgYWxsLgoKV2hhdCBhcmUgdGhlIG9wdGlvbnMgaGVyZT8gSSB0aGluayB0
aGV5IGFyZSwgd2l0aCB0aGVpciAobGliKXhsCmJlaGF2aW91cjoKCgkJUFYJCQkJSFZNCnR5cGU9
aW9lbXUJbWVhbmluZ2xlc3MgLyBhbiBlcnJvcgkJZW11bGF0ZWQgZGV2aWNlICsgcGFyYXZpcnQg
VklGKgp0eXBlPXZpZglwYXJhdmlydCBWSUYgZGV2aWNlKiYJCXBhcmF2aXJ0IFZJRiBkZXZpY2Ug
b25seSYKCldoZXJlICogPT0gY3VycmVudCBsaWIoeGwpIGRlZmF1bHQgYW5kICYgPT0gcHJvcG9z
ZWQgZGVmYXVsdCBhZnRlciB0aGlzIGNoYW5nZS4KYW5kOgogICAgICAgIHR5cGU9aW9lbXUgPT4J
TElCWExfTklDX1RZUEVfSU9FTVUgdG8gYmUgcmVuYW1lZCBMSUJYTF9OSUNfVFlQRV9WSUZfSU9F
TVUuCiAgICAgICAgdHlwZT12aWYgPT4JTElCWExfTklWX1RZUEVfVklGLCBubyByZW5hbWluZyBw
cm9wb3NlZC4KICAgICAgICAKQnV0IGlmIG15IHRhYmxlIGlzIGNvcnJlY3QgdGhlbiBMSUJYTF9O
SUNfVFlQRV9WSUZfSU9FTVUgaXMgdGhlIHJpZ2h0CmRlZmF1bHQgYW5kIHNob3VsZG4ndCBiZSBj
aGFuZ2VkLiBSb2dlciBjYW4geW91IGVpdGhlciBjb25maXJtIG9yCmNvcnJlY3QgbXkgdGFibGUu
CgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:51:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjnxe-00011M-6M; Wed, 27 Jun 2012 08:50:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjnxc-00011H-3N
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 08:50:52 +0000
Received: from [193.109.254.147:8138] by server-12.bemta-14.messagelabs.com id
	0C/2E-30461-B69CAEF4; Wed, 27 Jun 2012 08:50:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340787045!3589768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21100 invoked from network); 27 Jun 2012 08:50:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13239916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:50:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:50:45 +0100
Message-ID: <1340787043.29172.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 27 Jun 2012 09:50:43 +0100
In-Reply-To: <20120626165808.GC2058@reaktio.net>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

T24gVHVlLCAyMDEyLTA2LTI2IGF0IDE3OjU4ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUdWUsIEp1biAyNiwgMjAxMiBhdCAwNToyMDozNVBNICswMTAwLCBSb2dlciBQYXUg
TW9ubmUgd3JvdGU6Cj4gPiBJYW4gSmFja3NvbiB3cm90ZToKPiA+ID5Sb2dlciBQYXUgTW9ubmUg
d3JpdGVzICgiW1BBVENIIHY2IDEwLzEzXSBsaWJ4bDogc2V0IG5pYyB0eXBlIHRvIFZJRiBieSBk
ZWZhdWx0Iik6Cj4gPiA+PlNldCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgbmljIGludGVyZmFjZXMg
dG8gVklGLCBzaW5jZSBpdCB1c2VkIHRvIGJlCj4gPiA+PklPRU1VLCBldmVuIGZvciBQViBndWVz
dHMuCj4gPiA+Cj4gPiA+SWYgeW91ciByZW5hbWluZyBvZiBJT0VNVSB0byBWSUZfSU9FTVUgaXMg
Y29ycmVjdCwgZG9lcyB0aGlzIG5vdCBzdG9wCj4gPiA+SFZNIGd1ZXN0cyBnZXR0aW5nIGVtdWxh
dGVkIG5ldHdvcmsgaW50ZXJmYWNlcyBieSBkZWZhdWx0ID8KPiA+IAo+ID4gWWVzLCBpZiB5b3Ug
d2FudCBlbXVsYXRlZCBpbnRlcmZhY2VzIHdpdGggSFZNIGd1ZXN0cyB5b3Ugc2hvdWxkIHVzZQo+
ID4gJ3R5cGU9aW9lbXUnLCB0aGF0J3MgaG93IGl0IGhhcyBhbHdheXMgYmVlbiByaWdodD8KPiA+
IAo+IAo+IFdpdGggWGVuIDQuMSB5b3UgZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9aW9lbXUiLiBF
bXVsYXRlZCBpbnRlcmZhY2VzIHNlZW0gdG8gd29yayBPSyB3aXRob3V0ICJ0eXBlPWlvZW11Ii4K
PiAoYXQgbGVhc3Qgd2l0aCB4bS94ZW5kKS4gQW5kIGlmIHlvdSBhY3R1YWxseSBkbyBhZGQgInR5
cGU9aW9lbXUiIGl0IHdpbGwgYnJlYWsgUFZIVk0gZm9yIExpbnV4IGd1ZXN0cy4uCj4gCj4gUXVv
dGUgZnJvbTogaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1hlbkxpbnV4UFZvbkhWTWRyaXZlcnMK
PiAKPiAiTk9URSEgSWYgeW91IGhhdmUgInR5cGU9aW9lbXUiIHNwZWNpZmllZCBmb3IgdGhlICJ2
aWYiLWxpbmUsIFBWSFZNCj4gZHJpdmVycyBXSUxMIE5PVCB3b3JrISBEb24ndCBzcGVjaWZ5ICJ0
eXBlIiBwYXJhbWV0ZXIgZm9yIHRoZSB2aWYuCj4gKHdpdGggdHlwZT1pb2VtdSB0aGUgcHZodm0g
bmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3MgZnVsbCBvZgo+IHplcm9lcyAtIGFu
ZCB0aHVzIHdvbid0IHdvcmshKS4gIgoKbWFjPTAwOjAwOjAwOjAwOjAwIGlzIGNlcnRhaW5seSBh
IGJ1ZywgaWYgKGxpYil4bCBiZWhhdmVzIHRoaXMgd2F5IHRvbwp0aGVuIHdlIHNob3VsZCBmaXgg
aXQuCgpCdXQgc3VyZWx5IHR5cGU9aW9lbXUgaXMgc3VwcG9zZWQgdG8gbWVhbiAib25seSBlbXVs
YXRlZCI/IEluIHdoaWNoIGNhc2UKdGhlIGFjdHVhbCB4ZW5kIGJ1ZyBpcyB0aGF0IGl0IGNyZWF0
ZWQgYSBQViBWSUYgYXQgYWxsLgoKV2hhdCBhcmUgdGhlIG9wdGlvbnMgaGVyZT8gSSB0aGluayB0
aGV5IGFyZSwgd2l0aCB0aGVpciAobGliKXhsCmJlaGF2aW91cjoKCgkJUFYJCQkJSFZNCnR5cGU9
aW9lbXUJbWVhbmluZ2xlc3MgLyBhbiBlcnJvcgkJZW11bGF0ZWQgZGV2aWNlICsgcGFyYXZpcnQg
VklGKgp0eXBlPXZpZglwYXJhdmlydCBWSUYgZGV2aWNlKiYJCXBhcmF2aXJ0IFZJRiBkZXZpY2Ug
b25seSYKCldoZXJlICogPT0gY3VycmVudCBsaWIoeGwpIGRlZmF1bHQgYW5kICYgPT0gcHJvcG9z
ZWQgZGVmYXVsdCBhZnRlciB0aGlzIGNoYW5nZS4KYW5kOgogICAgICAgIHR5cGU9aW9lbXUgPT4J
TElCWExfTklDX1RZUEVfSU9FTVUgdG8gYmUgcmVuYW1lZCBMSUJYTF9OSUNfVFlQRV9WSUZfSU9F
TVUuCiAgICAgICAgdHlwZT12aWYgPT4JTElCWExfTklWX1RZUEVfVklGLCBubyByZW5hbWluZyBw
cm9wb3NlZC4KICAgICAgICAKQnV0IGlmIG15IHRhYmxlIGlzIGNvcnJlY3QgdGhlbiBMSUJYTF9O
SUNfVFlQRV9WSUZfSU9FTVUgaXMgdGhlIHJpZ2h0CmRlZmF1bHQgYW5kIHNob3VsZG4ndCBiZSBj
aGFuZ2VkLiBSb2dlciBjYW4geW91IGVpdGhlciBjb25maXJtIG9yCmNvcnJlY3QgbXkgdGFibGUu
CgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08: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 1Sjnza-00015c-MO; Wed, 27 Jun 2012 08:52: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 1SjnzZ-00015U-4H
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:52:53 +0000
Received: from [85.158.139.83:28997] by server-10.bemta-5.messagelabs.com id
	6E/86-02190-4E9CAEF4; Wed, 27 Jun 2012 08:52:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340787171!24569502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19705 invoked from network); 27 Jun 2012 08:52:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:52:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13239973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:52:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:52:51 +0100
Message-ID: <1340787170.29172.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 09:52:50 +0100
In-Reply-To: <alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340719712.3832.126.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 18:53 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > > Properly initialize all the pending_irqs.lr_queue like we do for
> > > inflight.
> > > Check whether we already have the irq in lr_queue before adding it.
> > 
> > Should this be a fatal error? Can a guest make this happen?
> 
> it could happen if the guest keeps enabling and disabling the irqs using
> the GICD_ICENABLERn and the GICD_ISENABLERn registers.

Then the printk is probably wrong. At the least it should be a gdprintk
but really I think it is unnecessary.

> 
> 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  xen/arch/arm/gic.c  |    6 ++++++
> > >  xen/arch/arm/vgic.c |    6 ++++++
> > >  2 files changed, 12 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > index 2e41d75..998033a 100644
> > > --- a/xen/arch/arm/gic.c
> > > +++ b/xen/arch/arm/gic.c
> > > @@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
> > >      }
> > >  
> > >      n = irq_to_pending(v, virtual_irq);
> > > +    if ( !list_empty(&n->lr_queue) )
> > > +    {
> > > +        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
> > > +                virtual_irq);
> > > +        goto out;
> > > +    }
> > >      list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
> > >      {
> > >          if ( iter->priority > priority )
> > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > > index 4cdfec5..653e8e5 100644
> > > --- a/xen/arch/arm/vgic.c
> > > +++ b/xen/arch/arm/vgic.c
> > > @@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
> > >      d->arch.vgic.pending_irqs =
> > >          xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> > >      for (i=0; i<d->arch.vgic.nr_lines; i++)
> > > +    {
> > >          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> > > +        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
> > > +    }
> > >      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
> > >          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> > >      return 0;
> > > @@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
> > >  
> > >      memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> > >      for (i = 0; i < 32; i++)
> > > +    {
> > >          INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> > > +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
> > > +    }
> > >      printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
> > >             &v->arch.vgic.pending_irqs[0],
> > >             v->arch.vgic.pending_irqs[0].desc);
> > 
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08: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 1Sjnza-00015c-MO; Wed, 27 Jun 2012 08:52: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 1SjnzZ-00015U-4H
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:52:53 +0000
Received: from [85.158.139.83:28997] by server-10.bemta-5.messagelabs.com id
	6E/86-02190-4E9CAEF4; Wed, 27 Jun 2012 08:52:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340787171!24569502!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDI5OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19705 invoked from network); 27 Jun 2012 08:52:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:52:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13239973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:52:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:52:51 +0100
Message-ID: <1340787170.29172.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 09:52:50 +0100
In-Reply-To: <alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340719712.3832.126.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 18:53 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > > Properly initialize all the pending_irqs.lr_queue like we do for
> > > inflight.
> > > Check whether we already have the irq in lr_queue before adding it.
> > 
> > Should this be a fatal error? Can a guest make this happen?
> 
> it could happen if the guest keeps enabling and disabling the irqs using
> the GICD_ICENABLERn and the GICD_ISENABLERn registers.

Then the printk is probably wrong. At the least it should be a gdprintk
but really I think it is unnecessary.

> 
> 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  xen/arch/arm/gic.c  |    6 ++++++
> > >  xen/arch/arm/vgic.c |    6 ++++++
> > >  2 files changed, 12 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > > index 2e41d75..998033a 100644
> > > --- a/xen/arch/arm/gic.c
> > > +++ b/xen/arch/arm/gic.c
> > > @@ -456,6 +456,12 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
> > >      }
> > >  
> > >      n = irq_to_pending(v, virtual_irq);
> > > +    if ( !list_empty(&n->lr_queue) )
> > > +    {
> > > +        printk(KERN_WARNING "%s: irq %d already in lr_queue\n", __func__,
> > > +                virtual_irq);
> > > +        goto out;
> > > +    }
> > >      list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
> > >      {
> > >          if ( iter->priority > priority )
> > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > > index 4cdfec5..653e8e5 100644
> > > --- a/xen/arch/arm/vgic.c
> > > +++ b/xen/arch/arm/vgic.c
> > > @@ -84,7 +84,10 @@ int domain_vgic_init(struct domain *d)
> > >      d->arch.vgic.pending_irqs =
> > >          xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> > >      for (i=0; i<d->arch.vgic.nr_lines; i++)
> > > +    {
> > >          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
> > > +        INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
> > > +    }
> > >      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
> > >          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> > >      return 0;
> > > @@ -99,7 +102,10 @@ int vcpu_vgic_init(struct vcpu *v)
> > >  
> > >      memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> > >      for (i = 0; i < 32; i++)
> > > +    {
> > >          INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> > > +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].lr_queue);
> > > +    }
> > >      printk("vcpu_vgic_init irq[0] at %p desc is %p\n",
> > >             &v->arch.vgic.pending_irqs[0],
> > >             v->arch.vgic.pending_irqs[0].desc);
> > 
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:56:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08: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 1Sjo2K-0001Fy-UM; Wed, 27 Jun 2012 08:55:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjo2J-0001Fq-BE
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:55:43 +0000
Received: from [85.158.143.35:11741] by server-2.bemta-4.messagelabs.com id
	78/3F-17938-E8ACAEF4; Wed, 27 Jun 2012 08:55:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340787340!15840075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26967 invoked from network); 27 Jun 2012 08:55:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:55:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13240066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:55:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:55:40 +0100
Message-ID: <1340787339.29172.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 09:55:39 +0100
In-Reply-To: <alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718633.3832.118.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] xcbuild: add console and xenstore
	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, 2012-06-26 at 18:58 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > Do you not have libxl and friends up and running sufficiently to use?
> > This xcbuild was really just intended to tide us over until that stuff
> > worked, not to be an actual thing...
> 
> xl/libxl works well enough for basic commands like "xl list", however
> in order to support something like "xl create" I expect that some more
> refactoring is needed as well as code motion to arch specific files.
> Considering that we are in code freeze right now, I thought it wouldn't
> be acceptable for 4.2, so I didn't even try.

Sounds reasonable.

It might still be interesting to run xl create and see what actually
breaks...

I don't plan to commit xcbuild, but I could maintain a dev branch
somewhere with such code in it for people to pull in to their local
tree, if that sounds useful?

> > On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  tools/xcutils/Makefile  |    4 +-
> > >  tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
> > >  2 files changed, 59 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> > > index 92c5a68..c88f286 100644
> > > --- a/tools/xcutils/Makefile
> > > +++ b/tools/xcutils/Makefile
> > > @@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
> > >  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> > >  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
> > >  CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
> > > -CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> > > +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
> > >  
> > >  .PHONY: all
> > >  all: build
> > > @@ -35,7 +35,7 @@ xc_save: xc_save.o
> > >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> > >  
> > >  xcbuild: xcbuild.o
> > > -	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > > +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> > >  
> > >  readnotes: readnotes.o
> > >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > > diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> > > index a70c3ca..7b5c0f8 100644
> > > --- a/tools/xcutils/xcbuild.c
> > > +++ b/tools/xcutils/xcbuild.c
> > > @@ -1,6 +1,7 @@
> > >  #include <unistd.h>
> > >  #include <stdio.h>
> > >  #include <stdlib.h>
> > > +#include <string.h>
> > >  
> > >  #include <errno.h>
> > >  
> > > @@ -8,6 +9,7 @@
> > >  //#include <xenguest.h>
> > >  #include <xentoollog.h>
> > >  #include <xc_dom.h>
> > > +#include <xenstore.h>
> > >  
> > >  int main(int argc, char **argv)
> > >  {
> > > @@ -15,11 +17,19 @@ int main(int argc, char **argv)
> > >  	xc_interface *xch;
> > >  	int rv;
> > >  	const char *image;
> > > -	uint32_t domid;
> > > +	uint32_t domid = 1;
> > >  	xen_domain_handle_t handle;
> > >  	int maxmem = 128; /* MB */ //atoi(argv[2]);
> > >  	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
> > >  	struct xc_dom_image *dom;
> > > +	unsigned long console_mfn;
> > > +	unsigned long console_port;
> > > +	unsigned long store_mfn;
> > > +	unsigned long store_port;
> > > +	struct xs_handle *xs;
> > > +	char *dom_path;
> > > +	char path[256];
> > > +	char val[256];
> > >  
> > >  	image = (argc < 2) ? "guest.img" : argv[1];
> > >  	printf("Image: %s\n", image);
> > > @@ -103,6 +113,52 @@ int main(int argc, char **argv)
> > >  	if (rv) return rv;
> > >  	rv = xc_dom_build_image(dom);
> > >  	if (rv) return rv;
> > > +
> > > +	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
> > > +	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > > +	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
> > > +
> > > +	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
> > > +	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > > +	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
> > > +	xs = xs_daemon_open();
> > > +	if (xs == NULL) {
> > > +		printf("Could not contact XenStore");
> > > +		return errno;
> > > +	}
> > > +	dom_path = xs_get_domain_path(xs, domid);
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/port", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", console_port);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", console_mfn);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/type", dom_path);
> > > +	snprintf(val, sizeof(val), "xenconsoled");
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/output", dom_path);
> > > +	snprintf(val, sizeof(val), "pty");
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
> > > +	snprintf(val, sizeof(val), "%d", 1048576);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/store/port", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", store_port);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", store_mfn);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +	xs_introduce_domain(xs, domid, store_mfn, store_port);
> > > +
> > > +	xs_daemon_close(xs);
> > > +
> > >  	rv = xc_dom_boot_image(dom);
> > >  	if (rv) return rv;
> > >  
> > 
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 08:56:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 08: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 1Sjo2K-0001Fy-UM; Wed, 27 Jun 2012 08:55:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjo2J-0001Fq-BE
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:55:43 +0000
Received: from [85.158.143.35:11741] by server-2.bemta-4.messagelabs.com id
	78/3F-17938-E8ACAEF4; Wed, 27 Jun 2012 08:55:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340787340!15840075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26967 invoked from network); 27 Jun 2012 08:55:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:55:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13240066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:55:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:55:40 +0100
Message-ID: <1340787339.29172.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 09:55:39 +0100
In-Reply-To: <alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718633.3832.118.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 5/5] xcbuild: add console and xenstore
	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, 2012-06-26 at 18:58 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > Do you not have libxl and friends up and running sufficiently to use?
> > This xcbuild was really just intended to tide us over until that stuff
> > worked, not to be an actual thing...
> 
> xl/libxl works well enough for basic commands like "xl list", however
> in order to support something like "xl create" I expect that some more
> refactoring is needed as well as code motion to arch specific files.
> Considering that we are in code freeze right now, I thought it wouldn't
> be acceptable for 4.2, so I didn't even try.

Sounds reasonable.

It might still be interesting to run xl create and see what actually
breaks...

I don't plan to commit xcbuild, but I could maintain a dev branch
somewhere with such code in it for people to pull in to their local
tree, if that sounds useful?

> > On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  tools/xcutils/Makefile  |    4 +-
> > >  tools/xcutils/xcbuild.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++-
> > >  2 files changed, 59 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
> > > index 92c5a68..c88f286 100644
> > > --- a/tools/xcutils/Makefile
> > > +++ b/tools/xcutils/Makefile
> > > @@ -20,7 +20,7 @@ CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxe
> > >  CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> > >  CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
> > >  CFLAGS_xcversion.o  := $(CFLAGS_libxenctrl)
> > > -CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
> > > +CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
> > >  
> > >  .PHONY: all
> > >  all: build
> > > @@ -35,7 +35,7 @@ xc_save: xc_save.o
> > >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> > >  
> > >  xcbuild: xcbuild.o
> > > -	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > > +	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
> > >  
> > >  readnotes: readnotes.o
> > >  	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> > > diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
> > > index a70c3ca..7b5c0f8 100644
> > > --- a/tools/xcutils/xcbuild.c
> > > +++ b/tools/xcutils/xcbuild.c
> > > @@ -1,6 +1,7 @@
> > >  #include <unistd.h>
> > >  #include <stdio.h>
> > >  #include <stdlib.h>
> > > +#include <string.h>
> > >  
> > >  #include <errno.h>
> > >  
> > > @@ -8,6 +9,7 @@
> > >  //#include <xenguest.h>
> > >  #include <xentoollog.h>
> > >  #include <xc_dom.h>
> > > +#include <xenstore.h>
> > >  
> > >  int main(int argc, char **argv)
> > >  {
> > > @@ -15,11 +17,19 @@ int main(int argc, char **argv)
> > >  	xc_interface *xch;
> > >  	int rv;
> > >  	const char *image;
> > > -	uint32_t domid;
> > > +	uint32_t domid = 1;
> > >  	xen_domain_handle_t handle;
> > >  	int maxmem = 128; /* MB */ //atoi(argv[2]);
> > >  	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
> > >  	struct xc_dom_image *dom;
> > > +	unsigned long console_mfn;
> > > +	unsigned long console_port;
> > > +	unsigned long store_mfn;
> > > +	unsigned long store_port;
> > > +	struct xs_handle *xs;
> > > +	char *dom_path;
> > > +	char path[256];
> > > +	char val[256];
> > >  
> > >  	image = (argc < 2) ? "guest.img" : argv[1];
> > >  	printf("Image: %s\n", image);
> > > @@ -103,6 +113,52 @@ int main(int argc, char **argv)
> > >  	if (rv) return rv;
> > >  	rv = xc_dom_build_image(dom);
> > >  	if (rv) return rv;
> > > +
> > > +	xc_get_hvm_param(xch, domid, HVM_PARAM_CONSOLE_PFN, &console_mfn);
> > > +	console_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > > +	xc_set_hvm_param(xch, domid, HVM_PARAM_CONSOLE_EVTCHN, console_port);
> > > +
> > > +	xc_get_hvm_param(xch, domid, HVM_PARAM_STORE_PFN, &store_mfn);
> > > +	store_port = xc_evtchn_alloc_unbound(xch, domid, 0);
> > > +	xc_set_hvm_param(xch, domid, HVM_PARAM_STORE_EVTCHN, store_port);
> > > +	xs = xs_daemon_open();
> > > +	if (xs == NULL) {
> > > +		printf("Could not contact XenStore");
> > > +		return errno;
> > > +	}
> > > +	dom_path = xs_get_domain_path(xs, domid);
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/port", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", console_port);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/ring-ref", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", console_mfn);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/type", dom_path);
> > > +	snprintf(val, sizeof(val), "xenconsoled");
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/output", dom_path);
> > > +	snprintf(val, sizeof(val), "pty");
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/console/limit", dom_path);
> > > +	snprintf(val, sizeof(val), "%d", 1048576);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/store/port", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", store_port);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +
> > > +	snprintf(path, sizeof(path), "%s/store/ring-ref", dom_path);
> > > +	snprintf(val, sizeof(val), "%lu", store_mfn);
> > > +	xs_write(xs, XBT_NULL, path, val, strlen(val));
> > > +	xs_introduce_domain(xs, domid, store_mfn, store_port);
> > > +
> > > +	xs_daemon_close(xs);
> > > +
> > >  	rv = xc_dom_boot_image(dom);
> > >  	if (rv) return rv;
> > >  
> > 
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 09:00:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 09:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjo6S-0001Rc-Jl; Wed, 27 Jun 2012 09:00:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjo6Q-0001RS-ON
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:59:58 +0000
Received: from [85.158.143.35:43419] by server-2.bemta-4.messagelabs.com id
	4B/88-17938-E8BCAEF4; Wed, 27 Jun 2012 08:59:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340787597!14254693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29073 invoked from network); 27 Jun 2012 08:59:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13240199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:59:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:59:57 +0100
Message-ID: <1340787595.29172.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 09:59:55 +0100
In-Reply-To: <alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340721279.3832.143.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] libxc/arm: allocate xenstore and
	console 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 Tue, 2012-06-26 at 19:05 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > > Allocate two additional pages at the end of the guest physical memory
> > > for xenstore and console.
> > > Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> > > values.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
> > >  1 files changed, 22 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > index bb86139..df2eefe 100644
> > > --- a/tools/libxc/xc_dom_arm.c
> > > +++ b/tools/libxc/xc_dom_arm.c
> > > @@ -25,6 +25,10 @@
> > >  #include "xg_private.h"
> > >  #include "xc_dom.h"
> > >  
> > > +#define NR_MAGIC_PAGES 2
> > > +#define CONSOLE_PFN_OFFSET 0
> > > +#define XENSTORE_PFN_OFFSET 1
> > > +
> > >  /* ------------------------------------------------------------------------ */
> > >  /*
> > >   * arm guests are hybrid and start off with paging disabled, therefore no
> > > @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> > >  static int alloc_magic_pages(struct xc_dom_image *dom)
> > >  {
> > >      DOMPRINTF_CALLED(dom->xch);
> > > -    /* XXX
> > > -     *   dom->p2m_guest
> > > -     *   dom->start_info_pfn
> > > -     *   dom->xenstore_pfn
> > > -     *   dom->console_pfn
> > > -     */
> > >      return 0;
> > >  }
> > >  
> > > @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > >  {
> > >      int rc;
> > >      xen_pfn_t pfn, allocsz, i;
> > > +    xen_pfn_t store_pfn, console_pfn;
> > >  
> > >      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
> > >              dom->total_pages, dom->rambase_pfn);
> > >  
> > >      dom->shadow_enabled = 1;
> > >  
> > > -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> > > +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
> > >  
> > >      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
> > >              dom->rambase_pfn, dom->total_pages );
> > >      /* setup initial p2m */
> > > -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> > > +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
> > >          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
> > >  
> > >      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> > > @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > >  
> > >      /* allocate guest memory */
> > >      for ( i = rc = allocsz = 0;
> > > -          (i < dom->total_pages) && !rc;
> > > +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
> > >            i += allocsz )
> > >      {
> > > -        allocsz = dom->total_pages - i;
> > > +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
> > 
> > All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.
> > 
> > Do these pages need to be in p2m_host or would it be fine to just insert
> > them into the guest p2m individually outside the main allocation logic?
> 
> I think it makes sense for them to be in p2m_host. In fact if we try to
> allocate them later, wouldn't we have the problem of having to extend
> the guest p2m? We might as well do it here.

The actual guest p2m is internal to the hypervisor so we never see it at
the tools layer.

I'm unsure if we need these magic pages in p2m_host. If we remember the
gfn of the magic pages that's just as useful as remembering the offset
in p2m_host and using p2m_host[offset]?


Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 09:00:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 09:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjo6S-0001Rc-Jl; Wed, 27 Jun 2012 09:00:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjo6Q-0001RS-ON
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:59:58 +0000
Received: from [85.158.143.35:43419] by server-2.bemta-4.messagelabs.com id
	4B/88-17938-E8BCAEF4; Wed, 27 Jun 2012 08:59:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340787597!14254693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29073 invoked from network); 27 Jun 2012 08:59:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 08:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13240199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 08:59:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:59:57 +0100
Message-ID: <1340787595.29172.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 09:59:55 +0100
In-Reply-To: <alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340721279.3832.143.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] libxc/arm: allocate xenstore and
	console 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 Tue, 2012-06-26 at 19:05 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > > Allocate two additional pages at the end of the guest physical memory
> > > for xenstore and console.
> > > Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> > > values.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
> > >  1 files changed, 22 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > index bb86139..df2eefe 100644
> > > --- a/tools/libxc/xc_dom_arm.c
> > > +++ b/tools/libxc/xc_dom_arm.c
> > > @@ -25,6 +25,10 @@
> > >  #include "xg_private.h"
> > >  #include "xc_dom.h"
> > >  
> > > +#define NR_MAGIC_PAGES 2
> > > +#define CONSOLE_PFN_OFFSET 0
> > > +#define XENSTORE_PFN_OFFSET 1
> > > +
> > >  /* ------------------------------------------------------------------------ */
> > >  /*
> > >   * arm guests are hybrid and start off with paging disabled, therefore no
> > > @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> > >  static int alloc_magic_pages(struct xc_dom_image *dom)
> > >  {
> > >      DOMPRINTF_CALLED(dom->xch);
> > > -    /* XXX
> > > -     *   dom->p2m_guest
> > > -     *   dom->start_info_pfn
> > > -     *   dom->xenstore_pfn
> > > -     *   dom->console_pfn
> > > -     */
> > >      return 0;
> > >  }
> > >  
> > > @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > >  {
> > >      int rc;
> > >      xen_pfn_t pfn, allocsz, i;
> > > +    xen_pfn_t store_pfn, console_pfn;
> > >  
> > >      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
> > >              dom->total_pages, dom->rambase_pfn);
> > >  
> > >      dom->shadow_enabled = 1;
> > >  
> > > -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> > > +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
> > >  
> > >      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
> > >              dom->rambase_pfn, dom->total_pages );
> > >      /* setup initial p2m */
> > > -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> > > +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
> > >          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
> > >  
> > >      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> > > @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > >  
> > >      /* allocate guest memory */
> > >      for ( i = rc = allocsz = 0;
> > > -          (i < dom->total_pages) && !rc;
> > > +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
> > >            i += allocsz )
> > >      {
> > > -        allocsz = dom->total_pages - i;
> > > +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
> > 
> > All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.
> > 
> > Do these pages need to be in p2m_host or would it be fine to just insert
> > them into the guest p2m individually outside the main allocation logic?
> 
> I think it makes sense for them to be in p2m_host. In fact if we try to
> allocate them later, wouldn't we have the problem of having to extend
> the guest p2m? We might as well do it here.

The actual guest p2m is internal to the hypervisor so we never see it at
the tools layer.

I'm unsure if we need these magic pages in p2m_host. If we remember the
gfn of the magic pages that's just as useful as remembering the offset
in p2m_host and using p2m_host[offset]?


Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 09:03:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 09: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 1Sjo9G-0001bL-AE; Wed, 27 Jun 2012 09:02: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 1Sjo9F-0001bF-AP
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 09:02:53 +0000
Received: from [85.158.139.83:19025] by server-10.bemta-5.messagelabs.com id
	74/90-02190-C3CCAEF4; Wed, 27 Jun 2012 09:02:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340787771!29746150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 27 Jun 2012 09:02:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 09:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13240294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 09:02:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 10:02:51 +0100
Message-ID: <1340787770.29172.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 10:02:50 +0100
In-Reply-To: <alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720842.3832.137.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen/arm: implement do_hvm_op 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

On Tue, 2012-06-26 at 19:29 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > We need to device how hybrid our hybrid arm guests are going to be.
> 
> Right.
> 
> 
> > The particular hvm params you are using here (evtchn port etc) typically
> > live in start_info for a PV guest. In principal we could define a start
> > info for ARM too but that leaves the question of how the guest can find
> > it (which loops up back to hvm_params...).
> 
> One way would be to introduce a new XENMAPSPACE, like we have done for
> XENMAPSPACE_shared_info. Then the guest would use a
> XENMEM_add_to_physmap to map it.
> 
> 
> > Looking at the other stuff in start_info, it has stuff like modules (aka
> > ramdisks) and command lines which ARM guest get via the normal ARM boot
> > protocol stuff (i.e. the domain builder does it) and a bunch of stuff
> > which seems to only make sense for proper-PV guests.
> > 
> > So maybe HVM PARAM is the right answer?
> 
> Yes, that is one of the reasons why I preferred introducing hvm_op
> rather than a new XENMAPSPACE: we don't need anything else from
> start_info aside from the parameters already provided through
> HVMOP_get_param.
> On the other hand hvm_op can be useful for other things, for example one
> day we might use the HVM_PARAM_IOREQ_PFN parameter.

That would be in future if/when we support proper "HVM" (or "PVHVM") ARM
guests i.e. ones which appear to the guest like a particular physical
platform, rather than our virtual hybrid platform, and therefore have a
QEMU providing a DM for that hardware?

> Most importantly, from the Linux side of things, acting like a PV on HVM
> kernel is a perfect fit, the changes required are down to a minimum.

OK.

> > sinfo does have flags which contains stuff like SIF_INITIAL_DOMAIN.
> > Might we want that?
> 
> We don't need it thanks to XENFEAT_dom0, see 
> 1340381685-22529-3-git-send-email-stefano.stabellini@eu.citrix.com

Great.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 09:03:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 09: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 1Sjo9G-0001bL-AE; Wed, 27 Jun 2012 09:02: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 1Sjo9F-0001bF-AP
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 09:02:53 +0000
Received: from [85.158.139.83:19025] by server-10.bemta-5.messagelabs.com id
	74/90-02190-C3CCAEF4; Wed, 27 Jun 2012 09:02:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340787771!29746150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 27 Jun 2012 09:02:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 09:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13240294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 09:02:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 10:02:51 +0100
Message-ID: <1340787770.29172.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 10:02:50 +0100
In-Reply-To: <alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720842.3832.137.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen/arm: implement do_hvm_op 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

On Tue, 2012-06-26 at 19:29 +0100, Stefano Stabellini wrote:
> On Tue, 26 Jun 2012, Ian Campbell wrote:
> > We need to device how hybrid our hybrid arm guests are going to be.
> 
> Right.
> 
> 
> > The particular hvm params you are using here (evtchn port etc) typically
> > live in start_info for a PV guest. In principal we could define a start
> > info for ARM too but that leaves the question of how the guest can find
> > it (which loops up back to hvm_params...).
> 
> One way would be to introduce a new XENMAPSPACE, like we have done for
> XENMAPSPACE_shared_info. Then the guest would use a
> XENMEM_add_to_physmap to map it.
> 
> 
> > Looking at the other stuff in start_info, it has stuff like modules (aka
> > ramdisks) and command lines which ARM guest get via the normal ARM boot
> > protocol stuff (i.e. the domain builder does it) and a bunch of stuff
> > which seems to only make sense for proper-PV guests.
> > 
> > So maybe HVM PARAM is the right answer?
> 
> Yes, that is one of the reasons why I preferred introducing hvm_op
> rather than a new XENMAPSPACE: we don't need anything else from
> start_info aside from the parameters already provided through
> HVMOP_get_param.
> On the other hand hvm_op can be useful for other things, for example one
> day we might use the HVM_PARAM_IOREQ_PFN parameter.

That would be in future if/when we support proper "HVM" (or "PVHVM") ARM
guests i.e. ones which appear to the guest like a particular physical
platform, rather than our virtual hybrid platform, and therefore have a
QEMU providing a DM for that hardware?

> Most importantly, from the Linux side of things, acting like a PV on HVM
> kernel is a perfect fit, the changes required are down to a minimum.

OK.

> > sinfo does have flags which contains stuff like SIF_INITIAL_DOMAIN.
> > Might we want that?
> 
> We don't need it thanks to XENFEAT_dom0, see 
> 1340381685-22529-3-git-send-email-stefano.stabellini@eu.citrix.com

Great.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 09:48:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 09:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjoqv-0001sf-Vr; Wed, 27 Jun 2012 09:48:01 +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 1Sjoqu-0001sa-Qv
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 09:48:01 +0000
Received: from [85.158.143.35:11090] by server-2.bemta-4.messagelabs.com id
	E4/39-17938-0D6DAEF4; Wed, 27 Jun 2012 09:48:00 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340790448!15843725!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMjE3OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26435 invoked from network); 27 Jun 2012 09:47:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 09:47:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5R9lOOf016122
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 09:47:25 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
	q5R9lOeo018191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 09:47:24 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
	q5R9lNp8018518; Wed, 27 Jun 2012 04:47:23 -0500
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Jun 2012 02:47:23 -0700
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	davem@davemloft.net, Ian.Campbell@citrix.com, konrad.wilk@oracle.com
Date: Wed, 27 Jun 2012 17:45:55 +0800
Message-Id: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kurt.hackel@oracle.com, Annie Li <Annie.li@oracle.com>
Subject: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is queued
	into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Annie Li <Annie.li@oracle.com>

After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
However, no dequeue action is called in this situation, it is likely that
tx_queue constains freed SKB. This patch should fix this issue, and it is
based on 3.5.0-rc4+.

This issue is found through code inspection, no bug is seen with it currently.
I run netperf test for several hours, and no network regression was found.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/net/xen-netback/netback.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f4a6fca..682633b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1363,8 +1363,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
-
 		netbk->pending_cons++;
 
 		request_gop = xen_netbk_get_requests(netbk, vif,
@@ -1376,6 +1374,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		}
 		gop = request_gop;
 
+		__skb_queue_tail(&netbk->tx_queue, skb);
+
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-- 
1.7.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 09:48:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 09:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjoqv-0001sf-Vr; Wed, 27 Jun 2012 09:48:01 +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 1Sjoqu-0001sa-Qv
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 09:48:01 +0000
Received: from [85.158.143.35:11090] by server-2.bemta-4.messagelabs.com id
	E4/39-17938-0D6DAEF4; Wed, 27 Jun 2012 09:48:00 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340790448!15843725!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMjE3OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26435 invoked from network); 27 Jun 2012 09:47:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 09:47:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5R9lOOf016122
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 09:47:25 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
	q5R9lOeo018191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 09:47:24 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
	q5R9lNp8018518; Wed, 27 Jun 2012 04:47:23 -0500
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Jun 2012 02:47:23 -0700
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	davem@davemloft.net, Ian.Campbell@citrix.com, konrad.wilk@oracle.com
Date: Wed, 27 Jun 2012 17:45:55 +0800
Message-Id: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kurt.hackel@oracle.com, Annie Li <Annie.li@oracle.com>
Subject: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is queued
	into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Annie Li <Annie.li@oracle.com>

After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
However, no dequeue action is called in this situation, it is likely that
tx_queue constains freed SKB. This patch should fix this issue, and it is
based on 3.5.0-rc4+.

This issue is found through code inspection, no bug is seen with it currently.
I run netperf test for several hours, and no network regression was found.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/net/xen-netback/netback.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f4a6fca..682633b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1363,8 +1363,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
-
 		netbk->pending_cons++;
 
 		request_gop = xen_netbk_get_requests(netbk, vif,
@@ -1376,6 +1374,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		}
 		gop = request_gop;
 
+		__skb_queue_tail(&netbk->tx_queue, skb);
+
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-- 
1.7.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:06:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1Sjp8K-00027T-Iy; Wed, 27 Jun 2012 10:06:00 +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 1Sjp8I-00027O-Ta
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 10:05:59 +0000
Received: from [85.158.139.83:20080] by server-4.bemta-5.messagelabs.com id
	80/F1-27831-50BDAEF4; Wed, 27 Jun 2012 10:05:57 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340791556!29733335!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21309 invoked from network); 27 Jun 2012 10:05:57 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-3.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 10:05:57 -0000
Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net
	[74.93.104.98])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 2E12F5842CB;
	Wed, 27 Jun 2012 03:05:56 -0700 (PDT)
Date: Wed, 27 Jun 2012 03:05:53 -0700 (PDT)
Message-Id: <20120627.030553.595987698091598621.davem@davemloft.net>
To: annie.li@oracle.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
References: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
X-Mailer: Mew version 6.5 on Emacs 24.0.97 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Networking patches need to be sent to netdev@vger.kernel.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:06:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1Sjp8K-00027T-Iy; Wed, 27 Jun 2012 10:06:00 +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 1Sjp8I-00027O-Ta
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 10:05:59 +0000
Received: from [85.158.139.83:20080] by server-4.bemta-5.messagelabs.com id
	80/F1-27831-50BDAEF4; Wed, 27 Jun 2012 10:05:57 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340791556!29733335!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21309 invoked from network); 27 Jun 2012 10:05:57 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-3.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 10:05:57 -0000
Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net
	[74.93.104.98])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 2E12F5842CB;
	Wed, 27 Jun 2012 03:05:56 -0700 (PDT)
Date: Wed, 27 Jun 2012 03:05:53 -0700 (PDT)
Message-Id: <20120627.030553.595987698091598621.davem@davemloft.net>
To: annie.li@oracle.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
References: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
X-Mailer: Mew version 6.5 on Emacs 24.0.97 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Networking patches need to be sent to netdev@vger.kernel.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:11:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjpD0-0002FK-9V; Wed, 27 Jun 2012 10:10: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 1SjpCz-0002FF-Ht
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:10:49 +0000
Received: from [85.158.143.99:22659] by server-2.bemta-4.messagelabs.com id
	7E/4B-17938-82CDAEF4; Wed, 27 Jun 2012 10:10:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340791845!24069646!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15458 invoked from network); 27 Jun 2012 10:10:47 -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;
	27 Jun 2012 10:10:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200199239"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 06:10:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 06:10:44 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SjpCu-000226-Jx;
	Wed, 27 Jun 2012 11:10:44 +0100
MIME-Version: 1.0
X-Mercurial-Node: 03b641aa89f979a1670b9fe2a0827687a17d5459
Message-ID: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 27 Jun 2012 11:10:44 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340791557 -3600
# Node ID 03b641aa89f979a1670b9fe2a0827687a17d5459
# Parent  91b2e1c01cc28427bf2b30fee5040f412dee9257
libxl: add a new Array type to the IDL

And make all the required infrastructure updates to enable this.

Since there are currently no uses of this type there is no change to
the generated code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---

Dario extracted this from my "RFC: libxl: move definition of
libxl_domain_config into the IDL" patch for use in his "Automatically
place guest on host's NUMA nodes with xl" series. I have addressed Ian
Jackson's review comments and am reposting as a separate patch.

Changes made to the idl.txt comments, in particular mention the
requirement to name the fields num_FOO.

Added support for converting C arrays into ocaml arrays (not lists as
previous patches).

diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/gentest.py	Wed Jun 27 11:05:57 2012 +0100
@@ -27,6 +27,18 @@ def gen_rand_init(ty, v, indent = "    "
     s = ""
     if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "%s = rand()%%8;\n" % (parent + ty.lenvar.name)
+        s += "%s = calloc(%s, sizeof(*%s));\n" % \
+            (v, parent + ty.lenvar.name, v)
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += gen_rand_init(ty.elem_type, v+"[i]",
+                           indent + "        ", parent)
+        s += "}\n"
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/gentypes.py	Wed Jun 27 11:05:57 2012 +0100
@@ -11,8 +11,12 @@ def libxl_C_instance_of(ty, instancename
             return libxl_C_type_define(ty)
         else:
             return libxl_C_type_define(ty) + " " + instancename
-    else:
-        return ty.typename + " " + instancename
+
+    s = ""
+    if isinstance(ty, idl.Array):
+        s += libxl_C_instance_of(ty.lenvar.type, ty.lenvar.name) + ";\n"
+
+    return s + ty.typename + " " + instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
@@ -66,6 +70,21 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        if ty.elem_type.dispose_fn is not None:
+            s += "{\n"
+            s += "    int i;\n"
+            s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+            s += libxl_C_type_dispose(ty.elem_type, v+"[i]",
+                                      indent + "        ", parent)
+        if ty.dispose_fn is not None:
+            if ty.elem_type.dispose_fn is not None:
+                s += "    "
+            s += "%s(%s);\n" % (ty.dispose_fn, ty.pass_arg(v, parent is None))
+        if ty.elem_type.dispose_fn is not None:
+            s += "}\n"
     elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -164,7 +183,24 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, idl.Enumeration):
+
+    if isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    s = yajl_gen_array_open(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "    for (i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_gen_json(ty.elem_type, v+"[i]",
+                                   indent + "        ", parent)
+        s += "    }\n"
+        s += "    s = yajl_gen_array_close(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/idl.py	Wed Jun 27 11:05:57 2012 +0100
@@ -266,6 +266,17 @@ string = Builtin("char *", namespace = N
                  json_fn = "libxl__string_gen_json",
                  autogenerate_json = False)
 
+class Array(Type):
+    """An array of the same type"""
+    def __init__(self, elem_type, lenvar_name, **kwargs):
+        kwargs.setdefault('dispose_fn', 'free')
+        Type.__init__(self, namespace=elem_type.namespace, typename=elem_type.rawname + " *", **kwargs)
+
+        lv_kwargs = dict([(x.lstrip('lenvar_'),y) for (x,y) in kwargs.items() if x.startswith('lenvar_')])
+
+        self.lenvar = Field(integer, lenvar_name, **lv_kwargs)
+        self.elem_type = elem_type
+
 class OrderedDict(dict):
     """A dictionary which remembers insertion order.
 
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/idl.txt	Wed Jun 27 11:05:57 2012 +0100
@@ -145,11 +145,24 @@ idl.KeyedUnion
 
  A subclass of idl.Aggregate which represents the C union type
  where the currently valid member of the union can be determined based
- upon another member in the containing type.
+ upon another member in the containing type. An idl.KeyedUnion must
+ always be a member of a containing idl.Aggregate type.
 
- The KeyedUnion.keyvar contains an idl.type the member of the
- containing type which determines the valid member of the union. The
- must be an instance of the Enumeration type.
+ The KeyedUnion.keyvar contains an idl.Field, this is the member of
+ the containing type which determines the valid member of the
+ union. The idl.Field.type of the keyvar must be an Enumeration type.
+
+idl.Array
+
+  A class representing an array of similar elements. An idl.Array must
+  always be an idl.Field of a containing idl.Aggregate.
+
+  idl.Array.elem_type contains an idl.Type which is the type of each
+  element of the array.
+
+  idl.Array.len_var contains an idl.Field which is added to the parent
+  idl.Aggregate and will contain the length of the array. The field
+  MUST be named num_ARRAYNAME.
 
 Standard Types
 --------------
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/ocaml/libs/xl/genwrap.py	Wed Jun 27 11:05:57 2012 +0100
@@ -55,7 +55,8 @@ def ocaml_type_of(ty):
             return "int%d" % ty.width
         else:
             return "int"
-
+    elif isinstance(ty,idl.Array):
+        return "%s array" % ocaml_type_of(ty.elem_type)
     elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
@@ -138,6 +139,8 @@ def c_val(ty, c, o, indent="", parent = 
         if not fn:
             raise NotImplementedError("No c_val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s;" % (fn % { "o": o, "c": c })
+    elif isinstance (ty,idl.Array):
+        raise("Cannot handle Array type\n")
     elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(Int_val(%s)) {\n" % o
@@ -195,6 +198,16 @@ def ocaml_Val(ty, o, c, indent="", paren
         if not fn:
             raise NotImplementedError("No ocaml Val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s = %s;" % (o, fn % { "c": c })
+    elif isinstance(ty, idl.Array):
+        s += "{\n"
+        s += "\t    int i;\n"
+        s += "\t    value array_elem;\n"
+        s += "\t    %s = caml_alloc(%s,0);\n" % (o, parent + ty.lenvar.name)
+        s += "\t    for(i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += "\t        %s\n" % ocaml_Val(ty.elem_type, "array_elem", c + "[i]", "")
+        s += "\t        Store_field(%s, i, array_elem);\n" % o
+        s += "\t    }\n"
+        s += "\t}"
     elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(%s) {\n" % c
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/python/genwrap.py	Wed Jun 27 11:05:57 2012 +0100
@@ -4,7 +4,7 @@ import sys,os
 
 import idl
 
-(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_ARRAY, TYPE_AGGREGATE) = range(7)
 
 def py_type(ty):
     if ty == idl.bool:
@@ -18,6 +18,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, idl.Array):
+        return TYPE_ARRAY
     if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
     if ty == idl.string:
@@ -74,7 +76,7 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
         l.append('    return NULL;')
     else:
@@ -105,7 +107,7 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
         l.append('    return -1;')
     else:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:11:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjpD0-0002FK-9V; Wed, 27 Jun 2012 10:10: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 1SjpCz-0002FF-Ht
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:10:49 +0000
Received: from [85.158.143.99:22659] by server-2.bemta-4.messagelabs.com id
	7E/4B-17938-82CDAEF4; Wed, 27 Jun 2012 10:10:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340791845!24069646!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15458 invoked from network); 27 Jun 2012 10:10:47 -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;
	27 Jun 2012 10:10:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200199239"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 06:10:45 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 06:10:44 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SjpCu-000226-Jx;
	Wed, 27 Jun 2012 11:10:44 +0100
MIME-Version: 1.0
X-Mercurial-Node: 03b641aa89f979a1670b9fe2a0827687a17d5459
Message-ID: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 27 Jun 2012 11:10:44 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340791557 -3600
# Node ID 03b641aa89f979a1670b9fe2a0827687a17d5459
# Parent  91b2e1c01cc28427bf2b30fee5040f412dee9257
libxl: add a new Array type to the IDL

And make all the required infrastructure updates to enable this.

Since there are currently no uses of this type there is no change to
the generated code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---

Dario extracted this from my "RFC: libxl: move definition of
libxl_domain_config into the IDL" patch for use in his "Automatically
place guest on host's NUMA nodes with xl" series. I have addressed Ian
Jackson's review comments and am reposting as a separate patch.

Changes made to the idl.txt comments, in particular mention the
requirement to name the fields num_FOO.

Added support for converting C arrays into ocaml arrays (not lists as
previous patches).

diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/gentest.py	Wed Jun 27 11:05:57 2012 +0100
@@ -27,6 +27,18 @@ def gen_rand_init(ty, v, indent = "    "
     s = ""
     if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "%s = rand()%%8;\n" % (parent + ty.lenvar.name)
+        s += "%s = calloc(%s, sizeof(*%s));\n" % \
+            (v, parent + ty.lenvar.name, v)
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+        s += gen_rand_init(ty.elem_type, v+"[i]",
+                           indent + "        ", parent)
+        s += "}\n"
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/gentypes.py	Wed Jun 27 11:05:57 2012 +0100
@@ -11,8 +11,12 @@ def libxl_C_instance_of(ty, instancename
             return libxl_C_type_define(ty)
         else:
             return libxl_C_type_define(ty) + " " + instancename
-    else:
-        return ty.typename + " " + instancename
+
+    s = ""
+    if isinstance(ty, idl.Array):
+        s += libxl_C_instance_of(ty.lenvar.type, ty.lenvar.name) + ";\n"
+
+    return s + ty.typename + " " + instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
@@ -66,6 +70,21 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
+    elif isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        if ty.elem_type.dispose_fn is not None:
+            s += "{\n"
+            s += "    int i;\n"
+            s += "    for (i=0; i<%s; i++)\n" % (parent + ty.lenvar.name)
+            s += libxl_C_type_dispose(ty.elem_type, v+"[i]",
+                                      indent + "        ", parent)
+        if ty.dispose_fn is not None:
+            if ty.elem_type.dispose_fn is not None:
+                s += "    "
+            s += "%s(%s);\n" % (ty.dispose_fn, ty.pass_arg(v, parent is None))
+        if ty.elem_type.dispose_fn is not None:
+            s += "}\n"
     elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -164,7 +183,24 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, idl.Enumeration):
+
+    if isinstance(ty, idl.Array):
+        if parent is None:
+            raise Exception("Array type must have a parent")
+        s += "{\n"
+        s += "    int i;\n"
+        s += "    s = yajl_gen_array_open(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "    for (i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += libxl_C_type_gen_json(ty.elem_type, v+"[i]",
+                                   indent + "        ", parent)
+        s += "    }\n"
+        s += "    s = yajl_gen_array_close(hand);\n"
+        s += "    if (s != yajl_gen_status_ok)\n"
+        s += "        goto out;\n"
+        s += "}\n"
+    elif isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/idl.py	Wed Jun 27 11:05:57 2012 +0100
@@ -266,6 +266,17 @@ string = Builtin("char *", namespace = N
                  json_fn = "libxl__string_gen_json",
                  autogenerate_json = False)
 
+class Array(Type):
+    """An array of the same type"""
+    def __init__(self, elem_type, lenvar_name, **kwargs):
+        kwargs.setdefault('dispose_fn', 'free')
+        Type.__init__(self, namespace=elem_type.namespace, typename=elem_type.rawname + " *", **kwargs)
+
+        lv_kwargs = dict([(x.lstrip('lenvar_'),y) for (x,y) in kwargs.items() if x.startswith('lenvar_')])
+
+        self.lenvar = Field(integer, lenvar_name, **lv_kwargs)
+        self.elem_type = elem_type
+
 class OrderedDict(dict):
     """A dictionary which remembers insertion order.
 
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/libxl/idl.txt	Wed Jun 27 11:05:57 2012 +0100
@@ -145,11 +145,24 @@ idl.KeyedUnion
 
  A subclass of idl.Aggregate which represents the C union type
  where the currently valid member of the union can be determined based
- upon another member in the containing type.
+ upon another member in the containing type. An idl.KeyedUnion must
+ always be a member of a containing idl.Aggregate type.
 
- The KeyedUnion.keyvar contains an idl.type the member of the
- containing type which determines the valid member of the union. The
- must be an instance of the Enumeration type.
+ The KeyedUnion.keyvar contains an idl.Field, this is the member of
+ the containing type which determines the valid member of the
+ union. The idl.Field.type of the keyvar must be an Enumeration type.
+
+idl.Array
+
+  A class representing an array of similar elements. An idl.Array must
+  always be an idl.Field of a containing idl.Aggregate.
+
+  idl.Array.elem_type contains an idl.Type which is the type of each
+  element of the array.
+
+  idl.Array.len_var contains an idl.Field which is added to the parent
+  idl.Aggregate and will contain the length of the array. The field
+  MUST be named num_ARRAYNAME.
 
 Standard Types
 --------------
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/ocaml/libs/xl/genwrap.py	Wed Jun 27 11:05:57 2012 +0100
@@ -55,7 +55,8 @@ def ocaml_type_of(ty):
             return "int%d" % ty.width
         else:
             return "int"
-
+    elif isinstance(ty,idl.Array):
+        return "%s array" % ocaml_type_of(ty.elem_type)
     elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
@@ -138,6 +139,8 @@ def c_val(ty, c, o, indent="", parent = 
         if not fn:
             raise NotImplementedError("No c_val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s;" % (fn % { "o": o, "c": c })
+    elif isinstance (ty,idl.Array):
+        raise("Cannot handle Array type\n")
     elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(Int_val(%s)) {\n" % o
@@ -195,6 +198,16 @@ def ocaml_Val(ty, o, c, indent="", paren
         if not fn:
             raise NotImplementedError("No ocaml Val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s = %s;" % (o, fn % { "c": c })
+    elif isinstance(ty, idl.Array):
+        s += "{\n"
+        s += "\t    int i;\n"
+        s += "\t    value array_elem;\n"
+        s += "\t    %s = caml_alloc(%s,0);\n" % (o, parent + ty.lenvar.name)
+        s += "\t    for(i=0; i<%s; i++) {\n" % (parent + ty.lenvar.name)
+        s += "\t        %s\n" % ocaml_Val(ty.elem_type, "array_elem", c + "[i]", "")
+        s += "\t        Store_field(%s, i, array_elem);\n" % o
+        s += "\t    }\n"
+        s += "\t}"
     elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(%s) {\n" % c
diff -r 91b2e1c01cc2 -r 03b641aa89f9 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Wed Jun 27 10:04:50 2012 +0100
+++ b/tools/python/genwrap.py	Wed Jun 27 11:05:57 2012 +0100
@@ -4,7 +4,7 @@ import sys,os
 
 import idl
 
-(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_ARRAY, TYPE_AGGREGATE) = range(7)
 
 def py_type(ty):
     if ty == idl.bool:
@@ -18,6 +18,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, idl.Array):
+        return TYPE_ARRAY
     if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
     if ty == idl.string:
@@ -74,7 +76,7 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
         l.append('    return NULL;')
     else:
@@ -105,7 +107,7 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
-    elif t == TYPE_AGGREGATE:
+    elif t == TYPE_AGGREGATE or t == TYPE_ARRAY:
         l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
         l.append('    return -1;')
     else:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:15:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjpHG-0002Py-6e; Wed, 27 Jun 2012 10:15: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 1SjpHD-0002Pt-Ut
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:15:12 +0000
Received: from [85.158.138.51:57664] by server-7.bemta-3.messagelabs.com id
	B2/DD-10113-F2DDAEF4; Wed, 27 Jun 2012 10:15:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340792109!20611513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21834 invoked from network); 27 Jun 2012 10:15:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 10:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13242431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 10:15:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 11:15:07 +0100
Message-ID: <1340792106.29172.22.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 Jun 2012 11:15:06 +0100
In-Reply-To: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> Since there are currently no uses of this type there is no change to
> the generated code.

But for reference if I add Dario's numa info type:

diff -r 03b641aa89f9 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jun 27 11:05:57 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Jun 27 11:13:44 2012 +0100
@@ -423,6 +423,12 @@ libxl_physinfo = Struct("physinfo", [
     ("cap_hvm_directio", bool),
     ], dir=DIR_OUT)
 
+libxl_numainfo = Struct("numainfo", [
+    ("size", uint64),
+    ("free", uint64),
+    ("dists", Array(uint32, "num_dists")),
+    ], dir=DIR_OUT)
+
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
     ("socket", uint32),

then I get the following diff to the generated files:

--- tools/libxl/_libxl_types.c.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/_libxl_types.c	2012-06-27 11:12:06.000000000 +0100
@@ -176,6 +176,12 @@ void libxl_physinfo_dispose(libxl_physin
     memset(p, LIBXL_DTOR_POISON, sizeof(*p));
 }
 
+void libxl_numainfo_dispose(libxl_numainfo *p)
+{
+    free(p->dists);
+    memset(p, LIBXL_DTOR_POISON, sizeof(*p));
+}
+
 void libxl_cputopology_dispose(libxl_cputopology *p)
 {
     memset(p, LIBXL_DTOR_POISON, sizeof(*p));
@@ -337,6 +343,11 @@ void libxl_physinfo_init(libxl_physinfo
     memset(p, '\0', sizeof(*p));
 }
 
+void libxl_numainfo_init(libxl_numainfo *p)
+{
+    memset(p, '\0', sizeof(*p));
+}
+
 void libxl_cputopology_init(libxl_cputopology *p)
 {
     memset(p, '\0', sizeof(*p));
@@ -2554,6 +2565,53 @@ char *libxl_physinfo_to_json(libxl_ctx *
     return libxl__object_to_json(ctx, "libxl_physinfo", (libxl__gen_json_callback)&libxl_physinfo_gen_json, (void *)p);
 }
 
+yajl_gen_status libxl_numainfo_gen_json(yajl_gen hand, libxl_numainfo *p)
+{
+    yajl_gen_status s;
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_string(hand, (const unsigned char *)"size", sizeof("size")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_integer(hand, p->size);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_string(hand, (const unsigned char *)"free", sizeof("free")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_integer(hand, p->free);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_string(hand, (const unsigned char *)"dists", sizeof("dists")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    {
+        int i;
+        s = yajl_gen_array_open(hand);
+        if (s != yajl_gen_status_ok)
+            goto out;
+        for (i=0; i<p->num_dists; i++) {
+            s = yajl_gen_integer(hand, p->dists[i]);
+            if (s != yajl_gen_status_ok)
+                goto out;
+        }
+        s = yajl_gen_array_close(hand);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    out:
+    return s;
+}
+
+char *libxl_numainfo_to_json(libxl_ctx *ctx, libxl_numainfo *p)
+{
+    return libxl__object_to_json(ctx, "libxl_numainfo", (libxl__gen_json_callback)&libxl_numainfo_gen_json, (void *)p);
+}
+
 yajl_gen_status libxl_cputopology_gen_json(yajl_gen hand, libxl_cputopology *p)
 {
     yajl_gen_status s;
--- tools/libxl/_libxl_types.h.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/_libxl_types.h	2012-06-27 11:12:06.000000000 +0100
@@ -475,6 +475,16 @@ void libxl_physinfo_dispose(libxl_physin
 void libxl_physinfo_init(libxl_physinfo *p);
 char *libxl_physinfo_to_json(libxl_ctx *ctx, libxl_physinfo *p);
 
+typedef struct libxl_numainfo {
+    uint64_t size;
+    uint64_t free;
+    int num_dists;
+    uint32_t * dists;
+} libxl_numainfo;
+void libxl_numainfo_dispose(libxl_numainfo *p);
+void libxl_numainfo_init(libxl_numainfo *p);
+char *libxl_numainfo_to_json(libxl_ctx *ctx, libxl_numainfo *p);
+
 typedef struct libxl_cputopology {
     uint32_t core;
     uint32_t socket;
--- tools/libxl/_libxl_types_json.h.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/_libxl_types_json.h	2012-06-27 11:12:06.000000000 +0100
@@ -40,6 +40,7 @@ yajl_gen_status libxl_diskinfo_gen_json(
 yajl_gen_status libxl_nicinfo_gen_json(yajl_gen hand, libxl_nicinfo *p);
 yajl_gen_status libxl_vcpuinfo_gen_json(yajl_gen hand, libxl_vcpuinfo *p);
 yajl_gen_status libxl_physinfo_gen_json(yajl_gen hand, libxl_physinfo *p);
+yajl_gen_status libxl_numainfo_gen_json(yajl_gen hand, libxl_numainfo *p);
 yajl_gen_status libxl_cputopology_gen_json(yajl_gen hand, libxl_cputopology *p);
 yajl_gen_status libxl_sched_credit_params_gen_json(yajl_gen hand, libxl_sched_credit_params *p);
 yajl_gen_status libxl_domain_remus_info_gen_json(yajl_gen hand, libxl_domain_remus_info *p);
--- tools/python/xen/lowlevel/xl/_pyxl_types.h.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/python/xen/lowlevel/xl/_pyxl_types.h	2012-06-27 11:12:09.000000000 +0100
@@ -268,6 +268,17 @@ _hidden int Pyphysinfo_Check(PyObject *s
 
 _hidden PyObject *attrib__libxl_hwcap_get(libxl_hwcap *hw_cap);
 
+/* Internal API for libxl_numainfo wrapper */
+typedef struct {
+    PyObject_HEAD;
+    libxl_numainfo obj;
+}Py_numainfo;
+
+_hidden Py_numainfo *Pynumainfo_New(void);
+
+_hidden int Pynumainfo_Check(PyObject *self);
+
+
 /* Internal API for libxl_cputopology wrapper */
 typedef struct {
     PyObject_HEAD;
--- tools/python/xen/lowlevel/xl/_pyxl_types.c.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/python/xen/lowlevel/xl/_pyxl_types.c	2012-06-27 11:12:09.000000000 +0100
@@ -3495,6 +3495,111 @@ int Pyphysinfo_Check(PyObject *self)
 {
     return (self->ob_type == &Pyphysinfo_Type);
 }
+/* Attribute get/set functions for libxl_numainfo */
+static PyObject *py_numainfo_size_get(Py_numainfo *self, void *priv)
+{
+    return genwrap__ull_get(self->obj.size);
+}
+
+static PyObject *py_numainfo_free_get(Py_numainfo *self, void *priv)
+{
+    return genwrap__ull_get(self->obj.free);
+}
+
+static PyObject *py_numainfo_dists_get(Py_numainfo *self, void *priv)
+{
+    PyErr_SetString(PyExc_NotImplementedError, "Getting libxl_numainfo");
+    return NULL;
+}
+
+static void Pynumainfo_dealloc(Py_numainfo *self)
+{
+    libxl_numainfo_dispose(&self->obj);
+    self->ob_type->tp_free((PyObject *)self);
+}
+
+static int Pynumainfo_init(Py_numainfo *self, PyObject *args, PyObject *kwds)
+{
+    memset(&self->obj, 0, sizeof(self->obj));
+    return genwrap__obj_init((PyObject *)self, args, kwds);
+}
+
+static PyObject *Pynumainfo_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
+{
+    Py_numainfo *self = (Py_numainfo *)type->tp_alloc(type, 0);
+    if (self == NULL)
+        return NULL;
+    memset(&self->obj, 0, sizeof(self->obj));
+    return (PyObject *)self;
+}
+
+static PyGetSetDef Pynumainfo_getset[] = {
+    { .name = "size", 
+      .get = (getter)py_numainfo_size_get, 
+      .set = (setter)NULL,
+    },
+    { .name = "free", 
+      .get = (getter)py_numainfo_free_get, 
+      .set = (setter)NULL,
+    },
+    { .name = "dists", 
+      .get = (getter)py_numainfo_dists_get, 
+      .set = (setter)NULL,
+    },
+    { .name = NULL }
+};
+
+static PyTypeObject Pynumainfo_Type= {
+    PyObject_HEAD_INIT(NULL)
+    0,
+    PKG ".numainfo",
+    sizeof(Py_numainfo),
+    0,
+    (destructor)Pynumainfo_dealloc,     /* tp_dealloc        */
+    NULL,                         /* tp_print          */
+    NULL,                         /* tp_getattr        */
+    NULL,                         /* tp_setattr        */
+    NULL,                         /* tp_compare        */
+    NULL,                         /* tp_repr           */
+    NULL,                         /* tp_as_number      */
+    NULL,                         /* tp_as_sequence    */
+    NULL,                         /* tp_as_mapping     */
+    NULL,                         /* tp_hash           */
+    NULL,                         /* tp_call           */
+    NULL,                         /* tp_str            */
+    NULL,                         /* tp_getattro       */
+    NULL,                         /* tp_setattro       */
+    NULL,                         /* tp_as_buffer      */
+    Py_TPFLAGS_DEFAULT|Py_TPFLAGS_BASETYPE, /* tp_flags          */
+    "numainfo",                         /* tp_doc            */
+    NULL,                         /* tp_traverse       */
+    NULL,                         /* tp_clear          */
+    NULL,                         /* tp_richcompare    */
+    0,                            /* tp_weaklistoffset */
+    NULL,                         /* tp_iter           */
+    NULL,                         /* tp_iternext       */
+    NULL,                         /* tp_methods        */
+    NULL,                         /* tp_members        */
+    Pynumainfo_getset,                  /* tp_getset         */
+    NULL,                         /* tp_base           */
+    NULL,                         /* tp_dict           */
+    NULL,                         /* tp_descr_get      */
+    NULL,                         /* tp_descr_set      */
+    0,                            /* tp_dictoffset     */
+    (initproc)Pynumainfo_init,          /* tp_init           */
+    NULL,                         /* tp_alloc          */
+    Pynumainfo_new,                     /* tp_new            */
+};
+
+Py_numainfo *Pynumainfo_New(void)
+{
+    return (Py_numainfo *)Pynumainfo_new(&Pynumainfo_Type, NULL, NULL);
+}
+
+int Pynumainfo_Check(PyObject *self)
+{
+    return (self->ob_type == &Pynumainfo_Type);
+}
 /* Attribute get/set functions for libxl_cputopology */
 static PyObject *py_cputopology_core_get(Py_cputopology *self, void *priv)
 {
@@ -4100,6 +4205,10 @@ void genwrap__init(PyObject *m)
         Py_INCREF(&Pyphysinfo_Type);
         PyModule_AddObject(m, "physinfo", (PyObject *)&Pyphysinfo_Type);
     }
+    if (PyType_Ready(&Pynumainfo_Type) >= 0) {
+        Py_INCREF(&Pynumainfo_Type);
+        PyModule_AddObject(m, "numainfo", (PyObject *)&Pynumainfo_Type);
+    }
     if (PyType_Ready(&Pycputopology_Type) >= 0) {
         Py_INCREF(&Pycputopology_Type);
         PyModule_AddObject(m, "cputopology", (PyObject *)&Pycputopology_Type);
--- tools/ocaml/libs/xl/_libxl_types.inc.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/ocaml/libs/xl/_libxl_types.inc	2012-06-27 11:12:11.000000000 +0100
@@ -1129,6 +1129,36 @@ static value Val_physinfo (caml_gc *gc,
 /* Stubs for physinfo */
 value stub_xl_physinfo_get(value v1);
 
+/* Convert numainfo to a caml value */
+static value Val_numainfo (caml_gc *gc, struct caml_logger *lg, libxl_numainfo *numainfo_c)
+{
+	CAMLparam0();
+	CAMLlocal1(numainfo_ocaml);
+	{
+		value numainfo_field;
+	
+		numainfo_ocaml = caml_alloc_tuple(3);
+	
+		numainfo_field = caml_copy_int64(numainfo_c->size);
+		Store_field(numainfo_ocaml, 0, numainfo_field);
+	
+		numainfo_field = caml_copy_int64(numainfo_c->free);
+		Store_field(numainfo_ocaml, 1, numainfo_field);
+	
+		{
+		    int i;
+		    value array_elem;
+		    numainfo_field = caml_alloc(numainfo_c->num_dists,0);
+		    for(i=0; i<numainfo_c->num_dists; i++) {
+		        array_elem = caml_copy_int32(numainfo_c->dists[i]);
+		        Store_field(numainfo_field, i, array_elem);
+		    }
+		}
+		Store_field(numainfo_ocaml, 2, numainfo_field);
+	}
+	CAMLreturn(numainfo_ocaml);
+}
+
 /* Convert cputopology to a caml value */
 static value Val_cputopology (caml_gc *gc, struct caml_logger *lg, libxl_cputopology *cputopology_c)
 {
--- tools/ocaml/libs/xl/_libxl_types.mli.in.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/ocaml/libs/xl/_libxl_types.mli.in	2012-06-27 11:12:11.000000000 +0100
@@ -312,6 +312,15 @@ module Physinfo : sig
 	external get : unit -> t = "stub_xl_physinfo_get"
 end
 
+module Numainfo : sig
+	type t =
+	{
+		size : int64;
+		free : int64;
+		dists : int32 array;
+	}
+end
+
 module Cputopology : sig
 	type t =
 	{
--- tools/ocaml/libs/xl/_libxl_types.ml.in.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/ocaml/libs/xl/_libxl_types.ml.in	2012-06-27 11:12:11.000000000 +0100
@@ -312,6 +312,15 @@ module Physinfo = struct
 	external get : unit -> t = "stub_xl_physinfo_get"
 end
 
+module Numainfo = struct
+	type t =
+	{
+		size : int64;
+		free : int64;
+		dists : int32 array;
+	}
+end
+
 module Cputopology = struct
 	type t =
 	{
--- tools/libxl/testidl.c.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/testidl.c	2012-06-27 11:12:06.000000000 +0100
@@ -521,6 +521,20 @@ static void libxl_physinfo_rand_init(lib
     p->cap_hvm_directio = rand() % 2;
 }
 
+static void libxl_numainfo_rand_init(libxl_numainfo *p);
+static void libxl_numainfo_rand_init(libxl_numainfo *p)
+{
+    p->size = rand() % (sizeof(p->size)*8);
+    p->free = rand() % (sizeof(p->free)*8);
+    p->num_dists = rand()%8;
+    p->dists = calloc(p->num_dists, sizeof(*p->dists));
+    {
+        int i;
+        for (i=0; i<p->num_dists; i++)
+            p->dists[i] = rand() % (sizeof(p->dists[i])*8);
+    }
+}
+
 static void libxl_cputopology_rand_init(libxl_cputopology *p);
 static void libxl_cputopology_rand_init(libxl_cputopology *p)
 {
@@ -610,6 +624,7 @@ int main(int argc, char **argv)
     libxl_nicinfo libxl_nicinfo_val;
     libxl_vcpuinfo libxl_vcpuinfo_val;
     libxl_physinfo libxl_physinfo_val;
+    libxl_numainfo libxl_numainfo_val;
     libxl_cputopology libxl_cputopology_val;
     libxl_sched_credit_params libxl_sched_credit_params_val;
     libxl_domain_remus_info libxl_domain_remus_info_val;
@@ -842,6 +857,13 @@ int main(int argc, char **argv)
     free(s);
     libxl_physinfo_dispose(&libxl_physinfo_val);
 
+    libxl_numainfo_rand_init(&libxl_numainfo_val);
+    s = libxl_numainfo_to_json(ctx, &libxl_numainfo_val);
+    printf("%s: %s\n", "libxl_numainfo", s);
+    if (s == NULL) abort();
+    free(s);
+    libxl_numainfo_dispose(&libxl_numainfo_val);
+
     libxl_cputopology_rand_init(&libxl_cputopology_val);
     s = libxl_cputopology_to_json(ctx, &libxl_cputopology_val);
     printf("%s: %s\n", "libxl_cputopology", s);





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:15:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjpHG-0002Py-6e; Wed, 27 Jun 2012 10:15: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 1SjpHD-0002Pt-Ut
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:15:12 +0000
Received: from [85.158.138.51:57664] by server-7.bemta-3.messagelabs.com id
	B2/DD-10113-F2DDAEF4; Wed, 27 Jun 2012 10:15:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340792109!20611513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21834 invoked from network); 27 Jun 2012 10:15:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 10:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13242431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 10:15:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 11:15:07 +0100
Message-ID: <1340792106.29172.22.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 Jun 2012 11:15:06 +0100
In-Reply-To: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> Since there are currently no uses of this type there is no change to
> the generated code.

But for reference if I add Dario's numa info type:

diff -r 03b641aa89f9 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jun 27 11:05:57 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Jun 27 11:13:44 2012 +0100
@@ -423,6 +423,12 @@ libxl_physinfo = Struct("physinfo", [
     ("cap_hvm_directio", bool),
     ], dir=DIR_OUT)
 
+libxl_numainfo = Struct("numainfo", [
+    ("size", uint64),
+    ("free", uint64),
+    ("dists", Array(uint32, "num_dists")),
+    ], dir=DIR_OUT)
+
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
     ("socket", uint32),

then I get the following diff to the generated files:

--- tools/libxl/_libxl_types.c.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/_libxl_types.c	2012-06-27 11:12:06.000000000 +0100
@@ -176,6 +176,12 @@ void libxl_physinfo_dispose(libxl_physin
     memset(p, LIBXL_DTOR_POISON, sizeof(*p));
 }
 
+void libxl_numainfo_dispose(libxl_numainfo *p)
+{
+    free(p->dists);
+    memset(p, LIBXL_DTOR_POISON, sizeof(*p));
+}
+
 void libxl_cputopology_dispose(libxl_cputopology *p)
 {
     memset(p, LIBXL_DTOR_POISON, sizeof(*p));
@@ -337,6 +343,11 @@ void libxl_physinfo_init(libxl_physinfo
     memset(p, '\0', sizeof(*p));
 }
 
+void libxl_numainfo_init(libxl_numainfo *p)
+{
+    memset(p, '\0', sizeof(*p));
+}
+
 void libxl_cputopology_init(libxl_cputopology *p)
 {
     memset(p, '\0', sizeof(*p));
@@ -2554,6 +2565,53 @@ char *libxl_physinfo_to_json(libxl_ctx *
     return libxl__object_to_json(ctx, "libxl_physinfo", (libxl__gen_json_callback)&libxl_physinfo_gen_json, (void *)p);
 }
 
+yajl_gen_status libxl_numainfo_gen_json(yajl_gen hand, libxl_numainfo *p)
+{
+    yajl_gen_status s;
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_string(hand, (const unsigned char *)"size", sizeof("size")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_integer(hand, p->size);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_string(hand, (const unsigned char *)"free", sizeof("free")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_integer(hand, p->free);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_string(hand, (const unsigned char *)"dists", sizeof("dists")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    {
+        int i;
+        s = yajl_gen_array_open(hand);
+        if (s != yajl_gen_status_ok)
+            goto out;
+        for (i=0; i<p->num_dists; i++) {
+            s = yajl_gen_integer(hand, p->dists[i]);
+            if (s != yajl_gen_status_ok)
+                goto out;
+        }
+        s = yajl_gen_array_close(hand);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    out:
+    return s;
+}
+
+char *libxl_numainfo_to_json(libxl_ctx *ctx, libxl_numainfo *p)
+{
+    return libxl__object_to_json(ctx, "libxl_numainfo", (libxl__gen_json_callback)&libxl_numainfo_gen_json, (void *)p);
+}
+
 yajl_gen_status libxl_cputopology_gen_json(yajl_gen hand, libxl_cputopology *p)
 {
     yajl_gen_status s;
--- tools/libxl/_libxl_types.h.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/_libxl_types.h	2012-06-27 11:12:06.000000000 +0100
@@ -475,6 +475,16 @@ void libxl_physinfo_dispose(libxl_physin
 void libxl_physinfo_init(libxl_physinfo *p);
 char *libxl_physinfo_to_json(libxl_ctx *ctx, libxl_physinfo *p);
 
+typedef struct libxl_numainfo {
+    uint64_t size;
+    uint64_t free;
+    int num_dists;
+    uint32_t * dists;
+} libxl_numainfo;
+void libxl_numainfo_dispose(libxl_numainfo *p);
+void libxl_numainfo_init(libxl_numainfo *p);
+char *libxl_numainfo_to_json(libxl_ctx *ctx, libxl_numainfo *p);
+
 typedef struct libxl_cputopology {
     uint32_t core;
     uint32_t socket;
--- tools/libxl/_libxl_types_json.h.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/_libxl_types_json.h	2012-06-27 11:12:06.000000000 +0100
@@ -40,6 +40,7 @@ yajl_gen_status libxl_diskinfo_gen_json(
 yajl_gen_status libxl_nicinfo_gen_json(yajl_gen hand, libxl_nicinfo *p);
 yajl_gen_status libxl_vcpuinfo_gen_json(yajl_gen hand, libxl_vcpuinfo *p);
 yajl_gen_status libxl_physinfo_gen_json(yajl_gen hand, libxl_physinfo *p);
+yajl_gen_status libxl_numainfo_gen_json(yajl_gen hand, libxl_numainfo *p);
 yajl_gen_status libxl_cputopology_gen_json(yajl_gen hand, libxl_cputopology *p);
 yajl_gen_status libxl_sched_credit_params_gen_json(yajl_gen hand, libxl_sched_credit_params *p);
 yajl_gen_status libxl_domain_remus_info_gen_json(yajl_gen hand, libxl_domain_remus_info *p);
--- tools/python/xen/lowlevel/xl/_pyxl_types.h.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/python/xen/lowlevel/xl/_pyxl_types.h	2012-06-27 11:12:09.000000000 +0100
@@ -268,6 +268,17 @@ _hidden int Pyphysinfo_Check(PyObject *s
 
 _hidden PyObject *attrib__libxl_hwcap_get(libxl_hwcap *hw_cap);
 
+/* Internal API for libxl_numainfo wrapper */
+typedef struct {
+    PyObject_HEAD;
+    libxl_numainfo obj;
+}Py_numainfo;
+
+_hidden Py_numainfo *Pynumainfo_New(void);
+
+_hidden int Pynumainfo_Check(PyObject *self);
+
+
 /* Internal API for libxl_cputopology wrapper */
 typedef struct {
     PyObject_HEAD;
--- tools/python/xen/lowlevel/xl/_pyxl_types.c.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/python/xen/lowlevel/xl/_pyxl_types.c	2012-06-27 11:12:09.000000000 +0100
@@ -3495,6 +3495,111 @@ int Pyphysinfo_Check(PyObject *self)
 {
     return (self->ob_type == &Pyphysinfo_Type);
 }
+/* Attribute get/set functions for libxl_numainfo */
+static PyObject *py_numainfo_size_get(Py_numainfo *self, void *priv)
+{
+    return genwrap__ull_get(self->obj.size);
+}
+
+static PyObject *py_numainfo_free_get(Py_numainfo *self, void *priv)
+{
+    return genwrap__ull_get(self->obj.free);
+}
+
+static PyObject *py_numainfo_dists_get(Py_numainfo *self, void *priv)
+{
+    PyErr_SetString(PyExc_NotImplementedError, "Getting libxl_numainfo");
+    return NULL;
+}
+
+static void Pynumainfo_dealloc(Py_numainfo *self)
+{
+    libxl_numainfo_dispose(&self->obj);
+    self->ob_type->tp_free((PyObject *)self);
+}
+
+static int Pynumainfo_init(Py_numainfo *self, PyObject *args, PyObject *kwds)
+{
+    memset(&self->obj, 0, sizeof(self->obj));
+    return genwrap__obj_init((PyObject *)self, args, kwds);
+}
+
+static PyObject *Pynumainfo_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
+{
+    Py_numainfo *self = (Py_numainfo *)type->tp_alloc(type, 0);
+    if (self == NULL)
+        return NULL;
+    memset(&self->obj, 0, sizeof(self->obj));
+    return (PyObject *)self;
+}
+
+static PyGetSetDef Pynumainfo_getset[] = {
+    { .name = "size", 
+      .get = (getter)py_numainfo_size_get, 
+      .set = (setter)NULL,
+    },
+    { .name = "free", 
+      .get = (getter)py_numainfo_free_get, 
+      .set = (setter)NULL,
+    },
+    { .name = "dists", 
+      .get = (getter)py_numainfo_dists_get, 
+      .set = (setter)NULL,
+    },
+    { .name = NULL }
+};
+
+static PyTypeObject Pynumainfo_Type= {
+    PyObject_HEAD_INIT(NULL)
+    0,
+    PKG ".numainfo",
+    sizeof(Py_numainfo),
+    0,
+    (destructor)Pynumainfo_dealloc,     /* tp_dealloc        */
+    NULL,                         /* tp_print          */
+    NULL,                         /* tp_getattr        */
+    NULL,                         /* tp_setattr        */
+    NULL,                         /* tp_compare        */
+    NULL,                         /* tp_repr           */
+    NULL,                         /* tp_as_number      */
+    NULL,                         /* tp_as_sequence    */
+    NULL,                         /* tp_as_mapping     */
+    NULL,                         /* tp_hash           */
+    NULL,                         /* tp_call           */
+    NULL,                         /* tp_str            */
+    NULL,                         /* tp_getattro       */
+    NULL,                         /* tp_setattro       */
+    NULL,                         /* tp_as_buffer      */
+    Py_TPFLAGS_DEFAULT|Py_TPFLAGS_BASETYPE, /* tp_flags          */
+    "numainfo",                         /* tp_doc            */
+    NULL,                         /* tp_traverse       */
+    NULL,                         /* tp_clear          */
+    NULL,                         /* tp_richcompare    */
+    0,                            /* tp_weaklistoffset */
+    NULL,                         /* tp_iter           */
+    NULL,                         /* tp_iternext       */
+    NULL,                         /* tp_methods        */
+    NULL,                         /* tp_members        */
+    Pynumainfo_getset,                  /* tp_getset         */
+    NULL,                         /* tp_base           */
+    NULL,                         /* tp_dict           */
+    NULL,                         /* tp_descr_get      */
+    NULL,                         /* tp_descr_set      */
+    0,                            /* tp_dictoffset     */
+    (initproc)Pynumainfo_init,          /* tp_init           */
+    NULL,                         /* tp_alloc          */
+    Pynumainfo_new,                     /* tp_new            */
+};
+
+Py_numainfo *Pynumainfo_New(void)
+{
+    return (Py_numainfo *)Pynumainfo_new(&Pynumainfo_Type, NULL, NULL);
+}
+
+int Pynumainfo_Check(PyObject *self)
+{
+    return (self->ob_type == &Pynumainfo_Type);
+}
 /* Attribute get/set functions for libxl_cputopology */
 static PyObject *py_cputopology_core_get(Py_cputopology *self, void *priv)
 {
@@ -4100,6 +4205,10 @@ void genwrap__init(PyObject *m)
         Py_INCREF(&Pyphysinfo_Type);
         PyModule_AddObject(m, "physinfo", (PyObject *)&Pyphysinfo_Type);
     }
+    if (PyType_Ready(&Pynumainfo_Type) >= 0) {
+        Py_INCREF(&Pynumainfo_Type);
+        PyModule_AddObject(m, "numainfo", (PyObject *)&Pynumainfo_Type);
+    }
     if (PyType_Ready(&Pycputopology_Type) >= 0) {
         Py_INCREF(&Pycputopology_Type);
         PyModule_AddObject(m, "cputopology", (PyObject *)&Pycputopology_Type);
--- tools/ocaml/libs/xl/_libxl_types.inc.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/ocaml/libs/xl/_libxl_types.inc	2012-06-27 11:12:11.000000000 +0100
@@ -1129,6 +1129,36 @@ static value Val_physinfo (caml_gc *gc,
 /* Stubs for physinfo */
 value stub_xl_physinfo_get(value v1);
 
+/* Convert numainfo to a caml value */
+static value Val_numainfo (caml_gc *gc, struct caml_logger *lg, libxl_numainfo *numainfo_c)
+{
+	CAMLparam0();
+	CAMLlocal1(numainfo_ocaml);
+	{
+		value numainfo_field;
+	
+		numainfo_ocaml = caml_alloc_tuple(3);
+	
+		numainfo_field = caml_copy_int64(numainfo_c->size);
+		Store_field(numainfo_ocaml, 0, numainfo_field);
+	
+		numainfo_field = caml_copy_int64(numainfo_c->free);
+		Store_field(numainfo_ocaml, 1, numainfo_field);
+	
+		{
+		    int i;
+		    value array_elem;
+		    numainfo_field = caml_alloc(numainfo_c->num_dists,0);
+		    for(i=0; i<numainfo_c->num_dists; i++) {
+		        array_elem = caml_copy_int32(numainfo_c->dists[i]);
+		        Store_field(numainfo_field, i, array_elem);
+		    }
+		}
+		Store_field(numainfo_ocaml, 2, numainfo_field);
+	}
+	CAMLreturn(numainfo_ocaml);
+}
+
 /* Convert cputopology to a caml value */
 static value Val_cputopology (caml_gc *gc, struct caml_logger *lg, libxl_cputopology *cputopology_c)
 {
--- tools/ocaml/libs/xl/_libxl_types.mli.in.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/ocaml/libs/xl/_libxl_types.mli.in	2012-06-27 11:12:11.000000000 +0100
@@ -312,6 +312,15 @@ module Physinfo : sig
 	external get : unit -> t = "stub_xl_physinfo_get"
 end
 
+module Numainfo : sig
+	type t =
+	{
+		size : int64;
+		free : int64;
+		dists : int32 array;
+	}
+end
+
 module Cputopology : sig
 	type t =
 	{
--- tools/ocaml/libs/xl/_libxl_types.ml.in.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/ocaml/libs/xl/_libxl_types.ml.in	2012-06-27 11:12:11.000000000 +0100
@@ -312,6 +312,15 @@ module Physinfo = struct
 	external get : unit -> t = "stub_xl_physinfo_get"
 end
 
+module Numainfo = struct
+	type t =
+	{
+		size : int64;
+		free : int64;
+		dists : int32 array;
+	}
+end
+
 module Cputopology = struct
 	type t =
 	{
--- tools/libxl/testidl.c.baseline	2012-06-27 10:08:58.000000000 +0100
+++ tools/libxl/testidl.c	2012-06-27 11:12:06.000000000 +0100
@@ -521,6 +521,20 @@ static void libxl_physinfo_rand_init(lib
     p->cap_hvm_directio = rand() % 2;
 }
 
+static void libxl_numainfo_rand_init(libxl_numainfo *p);
+static void libxl_numainfo_rand_init(libxl_numainfo *p)
+{
+    p->size = rand() % (sizeof(p->size)*8);
+    p->free = rand() % (sizeof(p->free)*8);
+    p->num_dists = rand()%8;
+    p->dists = calloc(p->num_dists, sizeof(*p->dists));
+    {
+        int i;
+        for (i=0; i<p->num_dists; i++)
+            p->dists[i] = rand() % (sizeof(p->dists[i])*8);
+    }
+}
+
 static void libxl_cputopology_rand_init(libxl_cputopology *p);
 static void libxl_cputopology_rand_init(libxl_cputopology *p)
 {
@@ -610,6 +624,7 @@ int main(int argc, char **argv)
     libxl_nicinfo libxl_nicinfo_val;
     libxl_vcpuinfo libxl_vcpuinfo_val;
     libxl_physinfo libxl_physinfo_val;
+    libxl_numainfo libxl_numainfo_val;
     libxl_cputopology libxl_cputopology_val;
     libxl_sched_credit_params libxl_sched_credit_params_val;
     libxl_domain_remus_info libxl_domain_remus_info_val;
@@ -842,6 +857,13 @@ int main(int argc, char **argv)
     free(s);
     libxl_physinfo_dispose(&libxl_physinfo_val);
 
+    libxl_numainfo_rand_init(&libxl_numainfo_val);
+    s = libxl_numainfo_to_json(ctx, &libxl_numainfo_val);
+    printf("%s: %s\n", "libxl_numainfo", s);
+    if (s == NULL) abort();
+    free(s);
+    libxl_numainfo_dispose(&libxl_numainfo_val);
+
     libxl_cputopology_rand_init(&libxl_cputopology_val);
     s = libxl_cputopology_to_json(ctx, &libxl_cputopology_val);
     printf("%s: %s\n", "libxl_cputopology", s);





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:46: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 1SjplQ-0002qK-F3; Wed, 27 Jun 2012 10:46: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 1SjplO-0002qE-Ty
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:46:23 +0000
Received: from [85.158.143.35:38540] by server-1.bemta-4.messagelabs.com id
	31/3F-24392-E74EAEF4; Wed, 27 Jun 2012 10:46:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340793976!6469572!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzM1MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20896 invoked from network); 27 Jun 2012 10:46:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 10:46: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 BD252111D;
	Wed, 27 Jun 2012 13:45:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5CA9BEC027; Wed, 27 Jun 2012 13:45:55 +0300 (EEST)
Date: Wed, 27 Jun 2012 13:45:55 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120627104555.GF2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, June 27, 2012 1:00 AM
> > To: Ian Campbell
> > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > Stefano Stabellini
> > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > guest
> > 
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > >
> > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > So, select a standard VGA card with VBE as the default emulated
> > graphics device.
> > >
> > > I'm not expert on the graphics side of HVM, but on the face of it
> > > switching the default to something more modern seems like a
> > reasonable
> > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > point.
> > >
> > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > 
> > I think it is a good thing.
> > The only thing to keep in mind is that QEMU upstream is switching to
> > 16MB of videoram for stdvga. So at some point in the near future
> > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > the videoram to 16MB too.
> > 
> Yes, we should pay attention to this when using upstream QEMU.
> 

Earlier there was a discussion about upstream QEMU lacking support
for being able to specify/configure the amount of videomem.

You can do that with the current qemu-xen-traditional. 
Should those patches be upstreamed? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:46: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 1SjplQ-0002qK-F3; Wed, 27 Jun 2012 10:46: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 1SjplO-0002qE-Ty
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:46:23 +0000
Received: from [85.158.143.35:38540] by server-1.bemta-4.messagelabs.com id
	31/3F-24392-E74EAEF4; Wed, 27 Jun 2012 10:46:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340793976!6469572!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzM1MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20896 invoked from network); 27 Jun 2012 10:46:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 10:46: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 BD252111D;
	Wed, 27 Jun 2012 13:45:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5CA9BEC027; Wed, 27 Jun 2012 13:45:55 +0300 (EEST)
Date: Wed, 27 Jun 2012 13:45:55 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120627104555.GF2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Wednesday, June 27, 2012 1:00 AM
> > To: Ian Campbell
> > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > Stefano Stabellini
> > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > guest
> > 
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > >
> > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > So, select a standard VGA card with VBE as the default emulated
> > graphics device.
> > >
> > > I'm not expert on the graphics side of HVM, but on the face of it
> > > switching the default to something more modern seems like a
> > reasonable
> > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > point.
> > >
> > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > 
> > I think it is a good thing.
> > The only thing to keep in mind is that QEMU upstream is switching to
> > 16MB of videoram for stdvga. So at some point in the near future
> > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > the videoram to 16MB too.
> > 
> Yes, we should pay attention to this when using upstream QEMU.
> 

Earlier there was a discussion about upstream QEMU lacking support
for being able to specify/configure the amount of videomem.

You can do that with the current qemu-xen-traditional. 
Should those patches be upstreamed? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:48:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1SjpnZ-0002xK-0C; Wed, 27 Jun 2012 10:48:37 +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 1SjpnX-0002xC-Va
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 10:48:36 +0000
Received: from [85.158.139.83:17047] by server-11.bemta-5.messagelabs.com id
	AA/B7-20400-305EAEF4; Wed, 27 Jun 2012 10:48:35 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340794110!28465045!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjA3MjQ4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27037 invoked from network); 27 Jun 2012 10:48:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 10:48:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5RAmQGt032481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 10:48: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
	q5RAmPgc021335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 10:48:25 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
	q5RAmOkn017814; Wed, 27 Jun 2012 05:48:24 -0500
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Jun 2012 03:48:24 -0700
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org, davem@davemloft.net,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com
Date: Wed, 27 Jun 2012 18:46:58 +0800
Message-Id: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kurt.hackel@oracle.com, Annie Li <Annie.li@oracle.com>
Subject: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is queued
	into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Annie Li <Annie.li@oracle.com>

After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
However, no dequeue action is called in this situation, it is likely that
tx_queue constains freed SKB. This patch should fix this issue, and it is
based on 3.5.0-rc4+.

This issue is found through code inspection, no bug is seen with it currently.
I run netperf test for several hours, and no network regression was found.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/net/xen-netback/netback.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f4a6fca..682633b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1363,8 +1363,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
-
 		netbk->pending_cons++;
 
 		request_gop = xen_netbk_get_requests(netbk, vif,
@@ -1376,6 +1374,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		}
 		gop = request_gop;
 
+		__skb_queue_tail(&netbk->tx_queue, skb);
+
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-- 
1.7.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:48:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1SjpnZ-0002xK-0C; Wed, 27 Jun 2012 10:48:37 +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 1SjpnX-0002xC-Va
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 10:48:36 +0000
Received: from [85.158.139.83:17047] by server-11.bemta-5.messagelabs.com id
	AA/B7-20400-305EAEF4; Wed, 27 Jun 2012 10:48:35 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340794110!28465045!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjA3MjQ4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27037 invoked from network); 27 Jun 2012 10:48:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 10:48:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5RAmQGt032481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 10:48: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
	q5RAmPgc021335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 10:48:25 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
	q5RAmOkn017814; Wed, 27 Jun 2012 05:48:24 -0500
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Jun 2012 03:48:24 -0700
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, netdev@vger.kernel.org, davem@davemloft.net,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com
Date: Wed, 27 Jun 2012 18:46:58 +0800
Message-Id: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kurt.hackel@oracle.com, Annie Li <Annie.li@oracle.com>
Subject: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is queued
	into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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: Annie Li <Annie.li@oracle.com>

After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
However, no dequeue action is called in this situation, it is likely that
tx_queue constains freed SKB. This patch should fix this issue, and it is
based on 3.5.0-rc4+.

This issue is found through code inspection, no bug is seen with it currently.
I run netperf test for several hours, and no network regression was found.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/net/xen-netback/netback.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f4a6fca..682633b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1363,8 +1363,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
-
 		netbk->pending_cons++;
 
 		request_gop = xen_netbk_get_requests(netbk, vif,
@@ -1376,6 +1374,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		}
 		gop = request_gop;
 
+		__skb_queue_tail(&netbk->tx_queue, skb);
+
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-- 
1.7.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1SjppE-000342-FQ; Wed, 27 Jun 2012 10:50:20 +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 1SjppE-00033v-2C
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 10:50:20 +0000
Received: from [85.158.139.83:9237] by server-11.bemta-5.messagelabs.com id
	76/6D-20400-B65EAEF4; Wed, 27 Jun 2012 10:50:19 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340794217!18486733!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMjE3OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9734 invoked from network); 27 Jun 2012 10:50:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 10:50:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5RAoCiw009539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 10:50:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5RAoBdc024001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 10:50:11 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
	q5RAoBET000913; Wed, 27 Jun 2012 05:50:11 -0500
Received: from [10.182.36.219] (/10.182.36.219)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Jun 2012 03:50:11 -0700
Message-ID: <4FEAE5A5.8070209@oracle.com>
Date: Wed, 27 Jun 2012 18:51:17 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: David Miller <davem@davemloft.net>
References: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
	<20120627.030553.595987698091598621.davem@davemloft.net>
In-Reply-To: <20120627.030553.595987698091598621.davem@davemloft.net>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kurt.hackel@oracle.com, Ian.Campbell@citrix.com,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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, sent to netdev@vger.kernel.org just now.

Thanks
Annie
On 2012-6-27 18:05, David Miller wrote:
> Networking patches need to be sent to netdev@vger.kernel.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 Wed Jun 27 10:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1SjppE-000342-FQ; Wed, 27 Jun 2012 10:50:20 +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 1SjppE-00033v-2C
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 10:50:20 +0000
Received: from [85.158.139.83:9237] by server-11.bemta-5.messagelabs.com id
	76/6D-20400-B65EAEF4; Wed, 27 Jun 2012 10:50:19 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340794217!18486733!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMjE3OA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9734 invoked from network); 27 Jun 2012 10:50:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 10:50:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5RAoCiw009539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Jun 2012 10:50:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5RAoBdc024001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2012 10:50:11 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
	q5RAoBET000913; Wed, 27 Jun 2012 05:50:11 -0500
Received: from [10.182.36.219] (/10.182.36.219)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Jun 2012 03:50:11 -0700
Message-ID: <4FEAE5A5.8070209@oracle.com>
Date: Wed, 27 Jun 2012 18:51:17 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: David Miller <davem@davemloft.net>
References: <1340790355-16838-1-git-send-email-annie.li@oracle.com>
	<20120627.030553.595987698091598621.davem@davemloft.net>
In-Reply-To: <20120627.030553.595987698091598621.davem@davemloft.net>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kurt.hackel@oracle.com, Ian.Campbell@citrix.com,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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, sent to netdev@vger.kernel.org just now.

Thanks
Annie
On 2012-6-27 18:05, David Miller wrote:
> Networking patches need to be sent to netdev@vger.kernel.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 Wed Jun 27 10:51:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjpqQ-0003Az-Vc; Wed, 27 Jun 2012 10:51:34 +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 1SjpqQ-0003Aj-4k
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:51:34 +0000
Received: from [193.109.254.147:7379] by server-1.bemta-14.messagelabs.com id
	D1/E5-24612-5B5EAEF4; Wed, 27 Jun 2012 10:51:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340794291!1916497!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22654 invoked from network); 27 Jun 2012 10:51:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 10:51:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243321"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 10:51:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 11:51:31 +0100
Date: Wed, 27 Jun 2012 11:51:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
In-Reply-To: <20120627104555.GF2058@reaktio.net>
Message-ID: <alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1408651658-1340794280=:27860"
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"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] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1408651658-1340794280=:27860
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 27 Jun 2012, Pasi Kärkkäinen wrote:
> On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > To: Ian Campbell
> > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > > Stefano Stabellini
> > > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > > guest
> > > 
> > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > > >
> > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > So, select a standard VGA card with VBE as the default emulated
> > > graphics device.
> > > >
> > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > switching the default to something more modern seems like a
> > > reasonable
> > > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > > point.
> > > >
> > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > 
> > > I think it is a good thing.
> > > The only thing to keep in mind is that QEMU upstream is switching to
> > > 16MB of videoram for stdvga. So at some point in the near future
> > > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > > the videoram to 16MB too.
> > > 
> > Yes, we should pay attention to this when using upstream QEMU.
> > 
> 
> Earlier there was a discussion about upstream QEMU lacking support
> for being able to specify/configure the amount of videomem.
> 
> You can do that with the current qemu-xen-traditional. 
> Should those patches be upstreamed? 

QEMU is getting a configurable videoram in the same patch series it is
getting 16MB by default for stdvga.
--1342847746-1408651658-1340794280=:27860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1408651658-1340794280=:27860--


From xen-devel-bounces@lists.xen.org Wed Jun 27 10:51:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjpqQ-0003Az-Vc; Wed, 27 Jun 2012 10:51:34 +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 1SjpqQ-0003Aj-4k
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:51:34 +0000
Received: from [193.109.254.147:7379] by server-1.bemta-14.messagelabs.com id
	D1/E5-24612-5B5EAEF4; Wed, 27 Jun 2012 10:51:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340794291!1916497!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22654 invoked from network); 27 Jun 2012 10:51:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 10:51:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243321"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 10:51:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 11:51:31 +0100
Date: Wed, 27 Jun 2012 11:51:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
In-Reply-To: <20120627104555.GF2058@reaktio.net>
Message-ID: <alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1408651658-1340794280=:27860"
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"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] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1408651658-1340794280=:27860
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 27 Jun 2012, Pasi Kärkkäinen wrote:
> On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > To: Ian Campbell
> > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > > Stefano Stabellini
> > > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > > guest
> > > 
> > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > > >
> > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > So, select a standard VGA card with VBE as the default emulated
> > > graphics device.
> > > >
> > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > switching the default to something more modern seems like a
> > > reasonable
> > > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > > point.
> > > >
> > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > 
> > > I think it is a good thing.
> > > The only thing to keep in mind is that QEMU upstream is switching to
> > > 16MB of videoram for stdvga. So at some point in the near future
> > > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > > the videoram to 16MB too.
> > > 
> > Yes, we should pay attention to this when using upstream QEMU.
> > 
> 
> Earlier there was a discussion about upstream QEMU lacking support
> for being able to specify/configure the amount of videomem.
> 
> You can do that with the current qemu-xen-traditional. 
> Should those patches be upstreamed? 

QEMU is getting a configurable videoram in the same patch series it is
getting 16MB by default for stdvga.
--1342847746-1408651658-1340794280=:27860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1408651658-1340794280=:27860--


From xen-devel-bounces@lists.xen.org Wed Jun 27 10:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1Sjpt5-0003RZ-O9; Wed, 27 Jun 2012 10:54:19 +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 1Sjpt4-0003RP-6U
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:54:18 +0000
Received: from [85.158.143.99:33997] by server-1.bemta-4.messagelabs.com id
	A5/8E-24392-956EAEF4; Wed, 27 Jun 2012 10:54:17 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340794456!25989808!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzM1MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32507 invoked from network); 27 Jun 2012 10:54:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 10:54:16 -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 BF1031682;
	Wed, 27 Jun 2012 13:53:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 80D2AEC027; Wed, 27 Jun 2012 13:53:55 +0300 (EEST)
Date: Wed, 27 Jun 2012 13:53:55 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120627105355.GG2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
	<alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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="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, Jun 27, 2012 at 11:51:05AM +0100, Stefano Stabellini wrote:
> On Wed, 27 Jun 2012, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > > To: Ian Campbell
> > > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.or=
g);
> > > > Stefano Stabellini
> > > > Subject: Re: [PATCH 1/2] libxl: set stdvga=3D1 by default when crea=
ting a hvm
> > > > guest
> > > > =

> > > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > > libxl: set stdvga=3D1 by default when creating a hvm guest
> > > > > >
> > > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > > So, select a standard VGA card with VBE as the default emulated
> > > > graphics device.
> > > > >
> > > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > > switching the default to something more modern seems like a
> > > > reasonable
> > > > > idea, although I'm not sure if we should be doing this for 4.2 at=
 this
> > > > > point.
> > > > >
> > > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > > =

> > > > I think it is a good thing.
> > > > The only thing to keep in mind is that QEMU upstream is switching to
> > > > 16MB of videoram for stdvga. So at some point in the near future
> > > > upstream QEMU will stop working correctly with xen 4.2, unless we b=
ump
> > > > the videoram to 16MB too.
> > > > =

> > > Yes, we should pay attention to this when using upstream QEMU.
> > > =

> > =

> > Earlier there was a discussion about upstream QEMU lacking support
> > for being able to specify/configure the amount of videomem.
> > =

> > You can do that with the current qemu-xen-traditional. =

> > Should those patches be upstreamed? =

> =

> QEMU is getting a configurable videoram in the same patch series it is
> getting 16MB by default for stdvga.
>

Oh, nice. That should help then?

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 10:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 10: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 1Sjpt5-0003RZ-O9; Wed, 27 Jun 2012 10:54:19 +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 1Sjpt4-0003RP-6U
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:54:18 +0000
Received: from [85.158.143.99:33997] by server-1.bemta-4.messagelabs.com id
	A5/8E-24392-956EAEF4; Wed, 27 Jun 2012 10:54:17 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340794456!25989808!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzM1MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32507 invoked from network); 27 Jun 2012 10:54:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 10:54:16 -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 BF1031682;
	Wed, 27 Jun 2012 13:53:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 80D2AEC027; Wed, 27 Jun 2012 13:53:55 +0300 (EEST)
Date: Wed, 27 Jun 2012 13:53:55 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120627105355.GG2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
	<alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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="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, Jun 27, 2012 at 11:51:05AM +0100, Stefano Stabellini wrote:
> On Wed, 27 Jun 2012, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > > To: Ian Campbell
> > > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.or=
g);
> > > > Stefano Stabellini
> > > > Subject: Re: [PATCH 1/2] libxl: set stdvga=3D1 by default when crea=
ting a hvm
> > > > guest
> > > > =

> > > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > > libxl: set stdvga=3D1 by default when creating a hvm guest
> > > > > >
> > > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > > So, select a standard VGA card with VBE as the default emulated
> > > > graphics device.
> > > > >
> > > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > > switching the default to something more modern seems like a
> > > > reasonable
> > > > > idea, although I'm not sure if we should be doing this for 4.2 at=
 this
> > > > > point.
> > > > >
> > > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > > =

> > > > I think it is a good thing.
> > > > The only thing to keep in mind is that QEMU upstream is switching to
> > > > 16MB of videoram for stdvga. So at some point in the near future
> > > > upstream QEMU will stop working correctly with xen 4.2, unless we b=
ump
> > > > the videoram to 16MB too.
> > > > =

> > > Yes, we should pay attention to this when using upstream QEMU.
> > > =

> > =

> > Earlier there was a discussion about upstream QEMU lacking support
> > for being able to specify/configure the amount of videomem.
> > =

> > You can do that with the current qemu-xen-traditional. =

> > Should those patches be upstreamed? =

> =

> QEMU is getting a configurable videoram in the same patch series it is
> getting 16MB by default for stdvga.
>

Oh, nice. That should help then?

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:00:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1Sjpya-0003iz-Q4; Wed, 27 Jun 2012 11:00: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 1SjpyZ-0003ir-Md
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:59:59 +0000
Received: from [85.158.138.51:29875] by server-7.bemta-3.messagelabs.com id
	1D/60-10113-EA7EAEF4; Wed, 27 Jun 2012 10:59:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340794798!25723794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27468 invoked from network); 27 Jun 2012 10:59:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 10:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 10:59:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 11:59:48 +0100
Date: Wed, 27 Jun 2012 11:59:22 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
In-Reply-To: <20120627105355.GG2058@reaktio.net>
Message-ID: <alpine.DEB.2.02.1206271157430.27860@kaball.uk.xensource.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
	<alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
	<20120627105355.GG2058@reaktio.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1782116553-1340794777=:27860"
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "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] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1782116553-1340794777=:27860
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 27 Jun 2012, Pasi Kärkkäinen wrote:
> On Wed, Jun 27, 2012 at 11:51:05AM +0100, Stefano Stabellini wrote:
> > On Wed, 27 Jun 2012, Pasi Kärkkäinen wrote:
> > > On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > > > -----Original Message-----
> > > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > > > To: Ian Campbell
> > > > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > > > > Stefano Stabellini
> > > > > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > > > > guest
> > > > > 
> > > > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > > > > >
> > > > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > > > So, select a standard VGA card with VBE as the default emulated
> > > > > graphics device.
> > > > > >
> > > > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > > > switching the default to something more modern seems like a
> > > > > reasonable
> > > > > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > > > > point.
> > > > > >
> > > > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > > > 
> > > > > I think it is a good thing.
> > > > > The only thing to keep in mind is that QEMU upstream is switching to
> > > > > 16MB of videoram for stdvga. So at some point in the near future
> > > > > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > > > > the videoram to 16MB too.
> > > > > 
> > > > Yes, we should pay attention to this when using upstream QEMU.
> > > > 
> > > 
> > > Earlier there was a discussion about upstream QEMU lacking support
> > > for being able to specify/configure the amount of videomem.
> > > 
> > > You can do that with the current qemu-xen-traditional. 
> > > Should those patches be upstreamed? 
> > 
> > QEMU is getting a configurable videoram in the same patch series it is
> > getting 16MB by default for stdvga.
> >
> 
> Oh, nice. That should help then?

Yes, but problem of the default value still exists.
Nowadays distros expect to be able to take upstream QEMU and use it with
Xen, but if we are not careful it might break when the next QEMU release
is out (1.2.0).
--1342847746-1782116553-1340794777=:27860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1782116553-1340794777=:27860--


From xen-devel-bounces@lists.xen.org Wed Jun 27 11:00:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1Sjpya-0003iz-Q4; Wed, 27 Jun 2012 11:00: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 1SjpyZ-0003ir-Md
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 10:59:59 +0000
Received: from [85.158.138.51:29875] by server-7.bemta-3.messagelabs.com id
	1D/60-10113-EA7EAEF4; Wed, 27 Jun 2012 10:59:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340794798!25723794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27468 invoked from network); 27 Jun 2012 10:59:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 10:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 10:59:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 11:59:48 +0100
Date: Wed, 27 Jun 2012 11:59:22 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
In-Reply-To: <20120627105355.GG2058@reaktio.net>
Message-ID: <alpine.DEB.2.02.1206271157430.27860@kaball.uk.xensource.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
	<alpine.DEB.2.02.1206271150050.27860@kaball.uk.xensource.com>
	<20120627105355.GG2058@reaktio.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1782116553-1340794777=:27860"
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "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] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1782116553-1340794777=:27860
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 27 Jun 2012, Pasi Kärkkäinen wrote:
> On Wed, Jun 27, 2012 at 11:51:05AM +0100, Stefano Stabellini wrote:
> > On Wed, 27 Jun 2012, Pasi Kärkkäinen wrote:
> > > On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > > > -----Original Message-----
> > > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > > > To: Ian Campbell
> > > > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > > > > Stefano Stabellini
> > > > > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> > > > > guest
> > > > > 
> > > > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > > > > >
> > > > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > > > So, select a standard VGA card with VBE as the default emulated
> > > > > graphics device.
> > > > > >
> > > > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > > > switching the default to something more modern seems like a
> > > > > reasonable
> > > > > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > > > > point.
> > > > > >
> > > > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > > > 
> > > > > I think it is a good thing.
> > > > > The only thing to keep in mind is that QEMU upstream is switching to
> > > > > 16MB of videoram for stdvga. So at some point in the near future
> > > > > upstream QEMU will stop working correctly with xen 4.2, unless we bump
> > > > > the videoram to 16MB too.
> > > > > 
> > > > Yes, we should pay attention to this when using upstream QEMU.
> > > > 
> > > 
> > > Earlier there was a discussion about upstream QEMU lacking support
> > > for being able to specify/configure the amount of videomem.
> > > 
> > > You can do that with the current qemu-xen-traditional. 
> > > Should those patches be upstreamed? 
> > 
> > QEMU is getting a configurable videoram in the same patch series it is
> > getting 16MB by default for stdvga.
> >
> 
> Oh, nice. That should help then?

Yes, but problem of the default value still exists.
Nowadays distros expect to be able to take upstream QEMU and use it with
Xen, but if we are not careful it might break when the next QEMU release
is out (1.2.0).
--1342847746-1782116553-1340794777=:27860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1782116553-1340794777=:27860--


From xen-devel-bounces@lists.xen.org Wed Jun 27 11:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1Sjq12-0003t2-CL; Wed, 27 Jun 2012 11:02:32 +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 1Sjq11-0003st-7u
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 11:02:31 +0000
Received: from [85.158.138.51:61125] by server-3.bemta-3.messagelabs.com id
	96/4D-26490-648EAEF4; Wed, 27 Jun 2012 11:02:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340794949!23416819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21602 invoked from network); 27 Jun 2012 11:02:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:02:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 12:02:29 +0100
Date: Wed, 27 Jun 2012 12:02:03 +0100
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: <1340787339.29172.14.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271201490.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718633.3832.118.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
	<1340787339.29172.14.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 5/5] xcbuild: add console and xenstore
	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, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 18:58 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > Do you not have libxl and friends up and running sufficiently to use?
> > > This xcbuild was really just intended to tide us over until that stuff
> > > worked, not to be an actual thing...
> > 
> > xl/libxl works well enough for basic commands like "xl list", however
> > in order to support something like "xl create" I expect that some more
> > refactoring is needed as well as code motion to arch specific files.
> > Considering that we are in code freeze right now, I thought it wouldn't
> > be acceptable for 4.2, so I didn't even try.
> 
> Sounds reasonable.
> 
> It might still be interesting to run xl create and see what actually
> breaks...
> 
> I don't plan to commit xcbuild, but I could maintain a dev branch
> somewhere with such code in it for people to pull in to their local
> tree, if that sounds useful?

Yep.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1Sjq12-0003t2-CL; Wed, 27 Jun 2012 11:02:32 +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 1Sjq11-0003st-7u
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 11:02:31 +0000
Received: from [85.158.138.51:61125] by server-3.bemta-3.messagelabs.com id
	96/4D-26490-648EAEF4; Wed, 27 Jun 2012 11:02:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340794949!23416819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21602 invoked from network); 27 Jun 2012 11:02:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:02:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 12:02:29 +0100
Date: Wed, 27 Jun 2012 12:02:03 +0100
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: <1340787339.29172.14.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271201490.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340718633.3832.118.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261856070.27860@kaball.uk.xensource.com>
	<1340787339.29172.14.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 5/5] xcbuild: add console and xenstore
	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, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 18:58 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > Do you not have libxl and friends up and running sufficiently to use?
> > > This xcbuild was really just intended to tide us over until that stuff
> > > worked, not to be an actual thing...
> > 
> > xl/libxl works well enough for basic commands like "xl list", however
> > in order to support something like "xl create" I expect that some more
> > refactoring is needed as well as code motion to arch specific files.
> > Considering that we are in code freeze right now, I thought it wouldn't
> > be acceptable for 4.2, so I didn't even try.
> 
> Sounds reasonable.
> 
> It might still be interesting to run xl create and see what actually
> breaks...
> 
> I don't plan to commit xcbuild, but I could maintain a dev branch
> somewhere with such code in it for people to pull in to their local
> tree, if that sounds useful?

Yep.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjq3l-00043Q-Uu; Wed, 27 Jun 2012 11:05:21 +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 1Sjq3k-00043J-EV
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 11:05:20 +0000
Received: from [85.158.143.35:21163] by server-2.bemta-4.messagelabs.com id
	1F/C8-17938-FE8EAEF4; Wed, 27 Jun 2012 11:05:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340795112!11222547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24131 invoked from network); 27 Jun 2012 11:05:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:05:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:04:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 12:04:27 +0100
Date: Wed, 27 Jun 2012 12:04:00 +0100
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: <1340787770.29172.19.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271203170.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720842.3832.137.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
	<1340787770.29172.19.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 1/5] xen/arm: implement do_hvm_op 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

On Wed, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 19:29 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > We need to device how hybrid our hybrid arm guests are going to be.
> > 
> > Right.
> > 
> > 
> > > The particular hvm params you are using here (evtchn port etc) typically
> > > live in start_info for a PV guest. In principal we could define a start
> > > info for ARM too but that leaves the question of how the guest can find
> > > it (which loops up back to hvm_params...).
> > 
> > One way would be to introduce a new XENMAPSPACE, like we have done for
> > XENMAPSPACE_shared_info. Then the guest would use a
> > XENMEM_add_to_physmap to map it.
> > 
> > 
> > > Looking at the other stuff in start_info, it has stuff like modules (aka
> > > ramdisks) and command lines which ARM guest get via the normal ARM boot
> > > protocol stuff (i.e. the domain builder does it) and a bunch of stuff
> > > which seems to only make sense for proper-PV guests.
> > > 
> > > So maybe HVM PARAM is the right answer?
> > 
> > Yes, that is one of the reasons why I preferred introducing hvm_op
> > rather than a new XENMAPSPACE: we don't need anything else from
> > start_info aside from the parameters already provided through
> > HVMOP_get_param.
> > On the other hand hvm_op can be useful for other things, for example one
> > day we might use the HVM_PARAM_IOREQ_PFN parameter.
> 
> That would be in future if/when we support proper "HVM" (or "PVHVM") ARM
> guests i.e. ones which appear to the guest like a particular physical
> platform, rather than our virtual hybrid platform, and therefore have a
> QEMU providing a DM for that hardware?

Yes, that is what HVM_PARAM_IOREQ_PFN would be for.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjq3l-00043Q-Uu; Wed, 27 Jun 2012 11:05:21 +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 1Sjq3k-00043J-EV
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 11:05:20 +0000
Received: from [85.158.143.35:21163] by server-2.bemta-4.messagelabs.com id
	1F/C8-17938-FE8EAEF4; Wed, 27 Jun 2012 11:05:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340795112!11222547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24131 invoked from network); 27 Jun 2012 11:05:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:05:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:04:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 12:04:27 +0100
Date: Wed, 27 Jun 2012 12:04:00 +0100
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: <1340787770.29172.19.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271203170.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340720842.3832.137.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261910240.27860@kaball.uk.xensource.com>
	<1340787770.29172.19.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 1/5] xen/arm: implement do_hvm_op 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

On Wed, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 19:29 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > We need to device how hybrid our hybrid arm guests are going to be.
> > 
> > Right.
> > 
> > 
> > > The particular hvm params you are using here (evtchn port etc) typically
> > > live in start_info for a PV guest. In principal we could define a start
> > > info for ARM too but that leaves the question of how the guest can find
> > > it (which loops up back to hvm_params...).
> > 
> > One way would be to introduce a new XENMAPSPACE, like we have done for
> > XENMAPSPACE_shared_info. Then the guest would use a
> > XENMEM_add_to_physmap to map it.
> > 
> > 
> > > Looking at the other stuff in start_info, it has stuff like modules (aka
> > > ramdisks) and command lines which ARM guest get via the normal ARM boot
> > > protocol stuff (i.e. the domain builder does it) and a bunch of stuff
> > > which seems to only make sense for proper-PV guests.
> > > 
> > > So maybe HVM PARAM is the right answer?
> > 
> > Yes, that is one of the reasons why I preferred introducing hvm_op
> > rather than a new XENMAPSPACE: we don't need anything else from
> > start_info aside from the parameters already provided through
> > HVMOP_get_param.
> > On the other hand hvm_op can be useful for other things, for example one
> > day we might use the HVM_PARAM_IOREQ_PFN parameter.
> 
> That would be in future if/when we support proper "HVM" (or "PVHVM") ARM
> guests i.e. ones which appear to the guest like a particular physical
> platform, rather than our virtual hybrid platform, and therefore have a
> QEMU providing a DM for that hardware?

Yes, that is what HVM_PARAM_IOREQ_PFN would be for.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:07:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1Sjq5Z-0004Bb-Em; Wed, 27 Jun 2012 11:07:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Sjq5Y-0004BR-Ph
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 11:07:13 +0000
Received: from [85.158.138.51:54118] by server-11.bemta-3.messagelabs.com id
	EC/AA-02904-069EAEF4; Wed, 27 Jun 2012 11:07:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340795228!23417993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16584 invoked from network); 27 Jun 2012 11:07:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:07:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:07:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 12:07:08 +0100
Date: Wed, 27 Jun 2012 12:06:52 +0100
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: <1340787170.29172.11.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271206400.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340719712.3832.126.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
	<1340787170.29172.11.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 18:53 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > > > Properly initialize all the pending_irqs.lr_queue like we do for
> > > > inflight.
> > > > Check whether we already have the irq in lr_queue before adding it.
> > > 
> > > Should this be a fatal error? Can a guest make this happen?
> > 
> > it could happen if the guest keeps enabling and disabling the irqs using
> > the GICD_ICENABLERn and the GICD_ISENABLERn registers.
> 
> Then the printk is probably wrong. At the least it should be a gdprintk
> but really I think it is unnecessary.

OK, I'll remove it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:07:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1Sjq5Z-0004Bb-Em; Wed, 27 Jun 2012 11:07:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Sjq5Y-0004BR-Ph
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 11:07:13 +0000
Received: from [85.158.138.51:54118] by server-11.bemta-3.messagelabs.com id
	EC/AA-02904-069EAEF4; Wed, 27 Jun 2012 11:07:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340795228!23417993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16584 invoked from network); 27 Jun 2012 11:07:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:07:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:07:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 12:07:08 +0100
Date: Wed, 27 Jun 2012 12:06:52 +0100
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: <1340787170.29172.11.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271206400.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206051814030.6030@kaball.uk.xensource.com>
	<1338981730-14816-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1338981730-14816-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340719712.3832.126.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261829300.27860@kaball.uk.xensource.com>
	<1340787170.29172.11.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] xen/vgic: initialize
	pending_irqs.lr_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 18:53 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Wed, 2012-06-06 at 12:22 +0100, Stefano Stabellini wrote:
> > > > Properly initialize all the pending_irqs.lr_queue like we do for
> > > > inflight.
> > > > Check whether we already have the irq in lr_queue before adding it.
> > > 
> > > Should this be a fatal error? Can a guest make this happen?
> > 
> > it could happen if the guest keeps enabling and disabling the irqs using
> > the GICD_ICENABLERn and the GICD_ISENABLERn registers.
> 
> Then the printk is probably wrong. At the least it should be a gdprintk
> but really I think it is unnecessary.

OK, I'll remove it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjqAK-0004Pl-UY; Wed, 27 Jun 2012 11:12:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjqAJ-0004PV-Sw
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 11:12:08 +0000
Received: from [85.158.139.83:16467] by server-12.bemta-5.messagelabs.com id
	A4/B3-25233-78AEAEF4; Wed, 27 Jun 2012 11:12:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340795525!22395613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3265 invoked from network); 27 Jun 2012 11:12:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:12:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:12:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 12:12:05 +0100
Message-ID: <1340795523.29172.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 27 Jun 2012 12:12:03 +0100
In-Reply-To: <20120627104555.GF2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Ren,
	Yongjie" <yongjie.ren@intel.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/2] libxl: set stdvga=1 by default when
 creating a hvm 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA2LTI3IGF0IDExOjQ1ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBXZWQsIEp1biAyNywgMjAxMiBhdCAwMTo0NTo0OUFNICswMDAwLCBSZW4sIFlvbmdq
aWUgd3JvdGU6Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiA+IEZyb206IFN0
ZWZhbm8gU3RhYmVsbGluaSBbbWFpbHRvOnN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29t
XQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjcsIDIwMTIgMTowMCBBTQo+ID4gPiBUbzog
SWFuIENhbXBiZWxsCj4gPiA+IENjOiBSZW4sIFlvbmdqaWU7IHhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnOyBJYW4gSmFja3NvbjsgVGltIChYZW4ub3JnKTsKPiA+ID4gU3RlZmFubyBTdGFiZWxsaW5p
Cj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8yXSBsaWJ4bDogc2V0IHN0ZHZnYT0xIGJ5IGRl
ZmF1bHQgd2hlbiBjcmVhdGluZyBhIGh2bQo+ID4gPiBndWVzdAo+ID4gPiAKPiA+ID4gT24gVHVl
LCAyNiBKdW4gMjAxMiwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gPiA+IE9uIFR1ZSwgMjAxMi0w
Ni0yNiBhdCAwNzowMiArMDEwMCwgUmVuLCBZb25namllIHdyb3RlOgo+ID4gPiA+ID4gbGlieGw6
IHNldCBzdGR2Z2E9MSBieSBkZWZhdWx0IHdoZW4gY3JlYXRpbmcgYSBodm0gZ3Vlc3QKPiA+ID4g
PiA+Cj4gPiA+ID4gPiBNb3N0IG9mIHRoZSBtb2Rlcm4gT1NlcyAoZS5nLiBXaW5kb3dzIFhQLCBX
aW5kb3dzIDcsIFJIRUw2LngsCj4gPiA+IFVidW50dSwgRmVkb3JhKSBzdXBwb3J0IFZCRSAyLjAg
b3IgbGF0ZXIuCj4gPiA+ID4gPiBTbywgc2VsZWN0IGEgc3RhbmRhcmQgVkdBIGNhcmQgd2l0aCBW
QkUgYXMgdGhlIGRlZmF1bHQgZW11bGF0ZWQKPiA+ID4gZ3JhcGhpY3MgZGV2aWNlLgo+ID4gPiA+
Cj4gPiA+ID4gSSdtIG5vdCBleHBlcnQgb24gdGhlIGdyYXBoaWNzIHNpZGUgb2YgSFZNLCBidXQg
b24gdGhlIGZhY2Ugb2YgaXQKPiA+ID4gPiBzd2l0Y2hpbmcgdGhlIGRlZmF1bHQgdG8gc29tZXRo
aW5nIG1vcmUgbW9kZXJuIHNlZW1zIGxpa2UgYQo+ID4gPiByZWFzb25hYmxlCj4gPiA+ID4gaWRl
YSwgYWx0aG91Z2ggSSdtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBiZSBkb2luZyB0aGlzIGZvciA0
LjIgYXQgdGhpcwo+ID4gPiA+IHBvaW50Lgo+ID4gPiA+Cj4gPiA+ID4gSSd2ZSBDQ2QgVGltIGFu
ZCBTdGVmYW5vIGZvciBpbnB1dCBmcm9tIHRoZSBIVk0gYW5kIFFFTVUgc2lkZXMuCj4gPiA+IAo+
ID4gPiBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aGluZy4KPiA+ID4gVGhlIG9ubHkgdGhpbmcgdG8g
a2VlcCBpbiBtaW5kIGlzIHRoYXQgUUVNVSB1cHN0cmVhbSBpcyBzd2l0Y2hpbmcgdG8KPiA+ID4g
MTZNQiBvZiB2aWRlb3JhbSBmb3Igc3RkdmdhLiBTbyBhdCBzb21lIHBvaW50IGluIHRoZSBuZWFy
IGZ1dHVyZQo+ID4gPiB1cHN0cmVhbSBRRU1VIHdpbGwgc3RvcCB3b3JraW5nIGNvcnJlY3RseSB3
aXRoIHhlbiA0LjIsIHVubGVzcyB3ZSBidW1wCj4gPiA+IHRoZSB2aWRlb3JhbSB0byAxNk1CIHRv
by4KPiA+ID4gCj4gPiBZZXMsIHdlIHNob3VsZCBwYXkgYXR0ZW50aW9uIHRvIHRoaXMgd2hlbiB1
c2luZyB1cHN0cmVhbSBRRU1VLgo+ID4gCj4gCj4gRWFybGllciB0aGVyZSB3YXMgYSBkaXNjdXNz
aW9uIGFib3V0IHVwc3RyZWFtIFFFTVUgbGFja2luZyBzdXBwb3J0Cj4gZm9yIGJlaW5nIGFibGUg
dG8gc3BlY2lmeS9jb25maWd1cmUgdGhlIGFtb3VudCBvZiB2aWRlb21lbS4KCkkgYmVsaWV2ZSB5
b3Ugd2VyZSBnb2luZyB0byBzZW5kIGEgcGF0Y2ggZG9jdW1lbnRpbmcgdGhpcz8gCgo+IAo+IFlv
dSBjYW4gZG8gdGhhdCB3aXRoIHRoZSBjdXJyZW50IHFlbXUteGVuLXRyYWRpdGlvbmFsLiAKPiBT
aG91bGQgdGhvc2UgcGF0Y2hlcyBiZSB1cHN0cmVhbWVkPyAKPiAKPiAtLSBQYXNpCj4gCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjqAK-0004Pl-UY; Wed, 27 Jun 2012 11:12:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SjqAJ-0004PV-Sw
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 11:12:08 +0000
Received: from [85.158.139.83:16467] by server-12.bemta-5.messagelabs.com id
	A4/B3-25233-78AEAEF4; Wed, 27 Jun 2012 11:12:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340795525!22395613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3265 invoked from network); 27 Jun 2012 11:12:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 11:12:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13243844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 11:12:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 12:12:05 +0100
Message-ID: <1340795523.29172.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 27 Jun 2012 12:12:03 +0100
In-Reply-To: <20120627104555.GF2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Ren,
	Yongjie" <yongjie.ren@intel.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/2] libxl: set stdvga=1 by default when
 creating a hvm 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA2LTI3IGF0IDExOjQ1ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBXZWQsIEp1biAyNywgMjAxMiBhdCAwMTo0NTo0OUFNICswMDAwLCBSZW4sIFlvbmdq
aWUgd3JvdGU6Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiA+IEZyb206IFN0
ZWZhbm8gU3RhYmVsbGluaSBbbWFpbHRvOnN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29t
XQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjcsIDIwMTIgMTowMCBBTQo+ID4gPiBUbzog
SWFuIENhbXBiZWxsCj4gPiA+IENjOiBSZW4sIFlvbmdqaWU7IHhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnOyBJYW4gSmFja3NvbjsgVGltIChYZW4ub3JnKTsKPiA+ID4gU3RlZmFubyBTdGFiZWxsaW5p
Cj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8yXSBsaWJ4bDogc2V0IHN0ZHZnYT0xIGJ5IGRl
ZmF1bHQgd2hlbiBjcmVhdGluZyBhIGh2bQo+ID4gPiBndWVzdAo+ID4gPiAKPiA+ID4gT24gVHVl
LCAyNiBKdW4gMjAxMiwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gPiA+IE9uIFR1ZSwgMjAxMi0w
Ni0yNiBhdCAwNzowMiArMDEwMCwgUmVuLCBZb25namllIHdyb3RlOgo+ID4gPiA+ID4gbGlieGw6
IHNldCBzdGR2Z2E9MSBieSBkZWZhdWx0IHdoZW4gY3JlYXRpbmcgYSBodm0gZ3Vlc3QKPiA+ID4g
PiA+Cj4gPiA+ID4gPiBNb3N0IG9mIHRoZSBtb2Rlcm4gT1NlcyAoZS5nLiBXaW5kb3dzIFhQLCBX
aW5kb3dzIDcsIFJIRUw2LngsCj4gPiA+IFVidW50dSwgRmVkb3JhKSBzdXBwb3J0IFZCRSAyLjAg
b3IgbGF0ZXIuCj4gPiA+ID4gPiBTbywgc2VsZWN0IGEgc3RhbmRhcmQgVkdBIGNhcmQgd2l0aCBW
QkUgYXMgdGhlIGRlZmF1bHQgZW11bGF0ZWQKPiA+ID4gZ3JhcGhpY3MgZGV2aWNlLgo+ID4gPiA+
Cj4gPiA+ID4gSSdtIG5vdCBleHBlcnQgb24gdGhlIGdyYXBoaWNzIHNpZGUgb2YgSFZNLCBidXQg
b24gdGhlIGZhY2Ugb2YgaXQKPiA+ID4gPiBzd2l0Y2hpbmcgdGhlIGRlZmF1bHQgdG8gc29tZXRo
aW5nIG1vcmUgbW9kZXJuIHNlZW1zIGxpa2UgYQo+ID4gPiByZWFzb25hYmxlCj4gPiA+ID4gaWRl
YSwgYWx0aG91Z2ggSSdtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBiZSBkb2luZyB0aGlzIGZvciA0
LjIgYXQgdGhpcwo+ID4gPiA+IHBvaW50Lgo+ID4gPiA+Cj4gPiA+ID4gSSd2ZSBDQ2QgVGltIGFu
ZCBTdGVmYW5vIGZvciBpbnB1dCBmcm9tIHRoZSBIVk0gYW5kIFFFTVUgc2lkZXMuCj4gPiA+IAo+
ID4gPiBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aGluZy4KPiA+ID4gVGhlIG9ubHkgdGhpbmcgdG8g
a2VlcCBpbiBtaW5kIGlzIHRoYXQgUUVNVSB1cHN0cmVhbSBpcyBzd2l0Y2hpbmcgdG8KPiA+ID4g
MTZNQiBvZiB2aWRlb3JhbSBmb3Igc3RkdmdhLiBTbyBhdCBzb21lIHBvaW50IGluIHRoZSBuZWFy
IGZ1dHVyZQo+ID4gPiB1cHN0cmVhbSBRRU1VIHdpbGwgc3RvcCB3b3JraW5nIGNvcnJlY3RseSB3
aXRoIHhlbiA0LjIsIHVubGVzcyB3ZSBidW1wCj4gPiA+IHRoZSB2aWRlb3JhbSB0byAxNk1CIHRv
by4KPiA+ID4gCj4gPiBZZXMsIHdlIHNob3VsZCBwYXkgYXR0ZW50aW9uIHRvIHRoaXMgd2hlbiB1
c2luZyB1cHN0cmVhbSBRRU1VLgo+ID4gCj4gCj4gRWFybGllciB0aGVyZSB3YXMgYSBkaXNjdXNz
aW9uIGFib3V0IHVwc3RyZWFtIFFFTVUgbGFja2luZyBzdXBwb3J0Cj4gZm9yIGJlaW5nIGFibGUg
dG8gc3BlY2lmeS9jb25maWd1cmUgdGhlIGFtb3VudCBvZiB2aWRlb21lbS4KCkkgYmVsaWV2ZSB5
b3Ugd2VyZSBnb2luZyB0byBzZW5kIGEgcGF0Y2ggZG9jdW1lbnRpbmcgdGhpcz8gCgo+IAo+IFlv
dSBjYW4gZG8gdGhhdCB3aXRoIHRoZSBjdXJyZW50IHFlbXUteGVuLXRyYWRpdGlvbmFsLiAKPiBT
aG91bGQgdGhvc2UgcGF0Y2hlcyBiZSB1cHN0cmVhbWVkPyAKPiAKPiAtLSBQYXNpCj4gCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1SjqBi-0004ib-KF; Wed, 27 Jun 2012 11:13:34 +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 1Sjo1X-0001E3-ND
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:55:00 +0000
Received: from [85.158.138.51:15062] by server-8.bemta-3.messagelabs.com id
	C3/12-06157-E5ACAEF4; Wed, 27 Jun 2012 08:54:54 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340787276!20836528!1
X-Originating-IP: [82.57.200.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16236 invoked from network); 27 Jun 2012 08:54:36 -0000
Received: from smtp205.alice.it (HELO smtp205.alice.it) (82.57.200.101)
	by server-7.tower-174.messagelabs.com with SMTP;
	27 Jun 2012 08:54:36 -0000
Received: from [192.168.178.50] (82.50.150.238) by smtp205.alice.it
	(8.6.023.02) id 4F421F7B0F1B7C20 for xen-devel@lists.xensource.com;
	Wed, 27 Jun 2012 10:54:33 +0200
Message-ID: <4FEACA2B.4040400@tiscali.it>
Date: Wed, 27 Jun 2012 10:54:03 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Mailman-Approved-At: Wed, 27 Jun 2012 11:13:32 +0000
Subject: [Xen-devel] Build error with xen-unstable changeset
	25517:c6c9d20963d7
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="===============7158966147011069039=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7158966147011069039==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060008070700000805000102"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060008070700000805000102
Content-Type: multipart/mixed;
 boundary="------------030803080800070300000702"

This is a multi-part message in MIME format.
--------------030803080800070300000702
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I had built on Wheezy updated xen-unstable changeset 25517:c6c9d20963d7=20
and I had this build error:
drivers/bus/isa.c: In function =E2isabus_probe=E2:
drivers/bus/isa.c:112:18: error: array subscript is above array bounds=20
[-Werror=3Darray-bounds]
cc1: all warnings being treated as errors
make[7]: *** [bin/isa.o] Error 1
make[7]: Leaving directory=20
`/mnt/vm/xen/xen-unstable.hg/tools/firmware/etherboot/ipxe/src'
make[6]: *** [ipxe/src/bin/rtl8139.rom] Error 2
make[6]: Leaving directory=20
`/mnt/vm/xen/xen-unstable.hg/tools/firmware/etherboot'
make[5]: *** [subdir-all-etherboot] Error 2
make[5]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools'
make: *** [install-tools] Error 2

In attachment full log file.
If you need some additional info please notify me, thanks for any reply.

--------------030803080800070300000702
Content-Type: text/plain; charset=windows-1252;
 name="xenbuild.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xenbuild.log"

cm9vdEB2ZmFybTovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcjIG1ha2UgZGViDQptYWtl
IC1DIHhlbiBpbnN0YWxsDQptYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4nDQptYWtlIC1mIFJ1bGVzLm1rIF9pbnN0YWxsDQpt
YWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4nDQptYWtlIC1DIHRvb2xzDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQpbIC1kIGZpZ2xldCBdICYm
IG1ha2UgLUMgZmlnbGV0DQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvZmlnbGV0Jw0KZ2NjIC1vIGZpZ2xldCBm
aWdsZXQuYw0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vdG9vbHMvZmlnbGV0Jw0KbWFrZSBzeW1ib2xzDQptYWtlWzRdOiBF
bnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMnDQpnY2MgLVdhbGwgLVdlcnJvciAtV3N0cmljdC1wcm90b3R5cGVzIC1PMiAtZm9taXQt
ZnJhbWUtcG9pbnRlciAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtbyBzeW1ib2xzIHN5bWJvbHMuYw0KbWFrZVs0XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQptYWtlWzNd
OiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90
b29scycNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5t
ayBpbmNsdWRlL3hlbi9jb21waWxlLmgNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbicNCm1ha2UgLUMgdG9vbHMNCm1ha2Vb
NF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi90b29scycNClsgLWQgZmlnbGV0IF0gJiYgbWFrZSAtQyBmaWdsZXQNCm1ha2VbNV06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29s
cy9maWdsZXQnDQptYWtlWzVdOiBgZmlnbGV0JyBpcyB1cCB0byBkYXRlLg0KbWFrZVs1XTog
TGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMvZmlnbGV0Jw0KbWFrZSBzeW1ib2xzDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQptYWtlWzVdOiBgc3lt
Ym9scycgaXMgdXAgdG8gZGF0ZS4NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzJw0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQogX18g
IF9fICAgICAgICAgICAgXyAgXyAgICBfX19fICAgICAgICAgICAgICAgICAgICAgXyAgICAg
ICAgXyAgICAgXyAgICAgIA0KIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAg
XyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyANCiAgXCAgLy8gXyBcICdf
IFwgIHwgfHwgfF8gICBfXykgfF9ffCB8IHwgfCAnXyBcLyBfX3wgX18vIF9gIHwgJ18gXHwg
fC8gXyBcDQogIC8gIFwgIF9fLyB8IHwgfCB8X18gICBffCAvIF9fL3xfX3wgfF98IHwgfCB8
IFxfXyBcIHx8IChffCB8IHxfKSB8IHwgIF9fLw0KIC9fL1xfXF9fX3xffCB8X3wgICAgfF98
KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbicNClsgLWUgaW5jbHVkZS9hc20gXSB8fCBsbiAt
c2YgYXNtLXg4NiBpbmNsdWRlL2FzbQ0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL1J1bGVzLm1rIC1DIGluY2x1ZGUNCm1ha2VbM106IEVudGVyaW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlJw0KbWtkaXIg
LXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShsb25nKScgcHVi
bGljL2NhbGxiYWNrLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L2NhbGxiYWNrLmMu
bmV3DQptdiAtZiBjb21wYXQvY2FsbGJhY2suYy5uZXcgY29tcGF0L2NhbGxiYWNrLmMNCmdj
YyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5v
LWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQt
ZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NF
IC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRl
IHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvY2FsbGJhY2suaSBjb21wYXQv
Y2FsbGJhY2suYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC9jYWxsYmFjay5oIHwgdHIg
J1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQi
ID5jb21wYXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21w
YXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIg
Pj5jb21wYXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL2Nh
bGxiYWNrLmg+IiA+PmNvbXBhdC9jYWxsYmFjay5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEg
cGFjayg0KSIgPj5jb21wYXQvY2FsbGJhY2suaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05
XScgY29tcGF0L2NhbGxiYWNrLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21w
YXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQv
Y2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9j
YWxsYmFjay5oLm5ldw0KbXYgLWYgY29tcGF0L2NhbGxiYWNrLmgubmV3IGNvbXBhdC9jYWxs
YmFjay5oDQpta2RpciAtcCBjb21wYXQNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFO
RExFKGxvbmcpJyBwdWJsaWMvZWxmbm90ZS5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBh
dC9lbGZub3RlLmMubmV3DQptdiAtZiBjb21wYXQvZWxmbm90ZS5jLm5ldyBjb21wYXQvZWxm
bm90ZS5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJs
ZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L2VsZm5vdGUu
aSBjb21wYXQvZWxmbm90ZS5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0L2VsZm5vdGUu
aCB8IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5k
ZWYgJGlkIiA+Y29tcGF0L2VsZm5vdGUuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIg
Pj5jb21wYXQvZWxmbm90ZS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0
Lmg+IiA+PmNvbXBhdC9lbGZub3RlLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHB1Ymxp
Yy9lbGZub3RlLmg+IiA+PmNvbXBhdC9lbGZub3RlLmgubmV3OyBcDQogZWNobyAiI3ByYWdt
YSBwYWNrKDQpIiA+PmNvbXBhdC9lbGZub3RlLmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAt
OV0nIGNvbXBhdC9lbGZub3RlLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21w
YXQvZWxmbm90ZS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9l
bGZub3RlLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIgPj5jb21wYXQvZWxm
bm90ZS5oLm5ldw0KbXYgLWYgY29tcGF0L2VsZm5vdGUuaC5uZXcgY29tcGF0L2VsZm5vdGUu
aA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShs
b25nKScgcHVibGljL2V2ZW50X2NoYW5uZWwuaCB8IFwNCiBweXRob24gL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5jb21w
YXQvZXZlbnRfY2hhbm5lbC5jLm5ldw0KbXYgLWYgY29tcGF0L2V2ZW50X2NoYW5uZWwuYy5u
ZXcgY29tcGF0L2V2ZW50X2NoYW5uZWwuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMy
IC1vIGNvbXBhdC9ldmVudF9jaGFubmVsLmkgY29tcGF0L2V2ZW50X2NoYW5uZWwuYw0Kc2V0
IC1lOyBpZD1fJChlY2hvIGNvbXBhdC9ldmVudF9jaGFubmVsLmggfCB0ciAnWzpsb3dlcjpd
LS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBhdC9l
dmVudF9jaGFubmVsLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L2V2
ZW50X2NoYW5uZWwuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIg
Pj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJs
aWMvZXZlbnRfY2hhbm5lbC5oPiIgPj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsgXA0K
IGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsg
XA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvZXZlbnRfY2hhbm5lbC5pIHwgXA0KIHB5
dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWls
ZC1oZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L2V2ZW50X2NoYW5uZWwuaC5uZXc7IFwNCiBl
Y2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsgXA0K
IGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0L2V2ZW50X2NoYW5uZWwuaC5uZXcN
Cm12IC1mIGNvbXBhdC9ldmVudF9jaGFubmVsLmgubmV3IGNvbXBhdC9ldmVudF9jaGFubmVs
LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
bG9uZyknIHB1YmxpYy9mZWF0dXJlcy5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC9m
ZWF0dXJlcy5jLm5ldw0KbXYgLWYgY29tcGF0L2ZlYXR1cmVzLmMubmV3IGNvbXBhdC9mZWF0
dXJlcy5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJs
ZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L2ZlYXR1cmVz
LmkgY29tcGF0L2ZlYXR1cmVzLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvZmVhdHVy
ZXMuaCB8IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNp
Zm5kZWYgJGlkIiA+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAk
aWQiID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9j
b21wYXQuaD4iID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUg
PHB1YmxpYy9mZWF0dXJlcy5oPiIgPj5jb21wYXQvZmVhdHVyZXMuaC5uZXc7IFwNCiBlY2hv
ICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZ3JlcCAt
diAnXiMgWzAtOV0nIGNvbXBhdC9mZWF0dXJlcy5pIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1oZWFkZXIucHkgfCB1
bmlxID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCki
ID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIg
Pj5jb21wYXQvZmVhdHVyZXMuaC5uZXcNCm12IC1mIGNvbXBhdC9mZWF0dXJlcy5oLm5ldyBj
b21wYXQvZmVhdHVyZXMuaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL2dyYW50X3RhYmxlLmggfCBcDQogcHl0aG9u
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNv
dXJjZS5weSA+Y29tcGF0L2dyYW50X3RhYmxlLmMubmV3DQptdiAtZiBjb21wYXQvZ3JhbnRf
dGFibGUuYy5uZXcgY29tcGF0L2dyYW50X3RhYmxlLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9Q
T0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0
LmggLW0zMiAtbyBjb21wYXQvZ3JhbnRfdGFibGUuaSBjb21wYXQvZ3JhbnRfdGFibGUuYw0K
c2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC9ncmFudF90YWJsZS5oIHwgdHIgJ1s6bG93ZXI6
XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQv
Z3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvZ3Jh
bnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5j
b21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL2dy
YW50X3RhYmxlLmg+IiA+PmNvbXBhdC9ncmFudF90YWJsZS5oLm5ldzsgXA0KIGVjaG8gIiNw
cmFnbWEgcGFjayg0KSIgPj5jb21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBncmVwIC12
ICdeIyBbMC05XScgY29tcGF0L2dyYW50X3RhYmxlLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8
IHVuaXEgPj5jb21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBh
Y2soKSIgPj5jb21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyog
JGlkICovIiA+PmNvbXBhdC9ncmFudF90YWJsZS5oLm5ldw0KbXYgLWYgY29tcGF0L2dyYW50
X3RhYmxlLmgubmV3IGNvbXBhdC9ncmFudF90YWJsZS5oDQpta2RpciAtcCBjb21wYXQNCmdy
ZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMva2V4ZWMuaCB8
IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21w
YXQtYnVpbGQtc291cmNlLnB5ID5jb21wYXQva2V4ZWMuYy5uZXcNCm12IC1mIGNvbXBhdC9r
ZXhlYy5jLm5ldyBjb21wYXQva2V4ZWMuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMy
IC1vIGNvbXBhdC9rZXhlYy5pIGNvbXBhdC9rZXhlYy5jDQpzZXQgLWU7IGlkPV8kKGVjaG8g
Y29tcGF0L2tleGVjLmggfCB0ciAnWzpsb3dlcjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwN
CiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNk
ZWZpbmUgJGlkIiA+PmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDx4
ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRl
IDxwdWJsaWMva2V4ZWMuaD4iID4+Y29tcGF0L2tleGVjLmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKDQpIiA+PmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGdyZXAgLXYgJ14jIFsw
LTldJyBjb21wYXQva2V4ZWMuaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBh
dC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9rZXhl
Yy5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0L2tleGVjLmgu
bmV3DQptdiAtZiBjb21wYXQva2V4ZWMuaC5uZXcgY29tcGF0L2tleGVjLmgNCm1rZGlyIC1w
IGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobG9uZyknIHB1Ymxp
Yy9tZW1vcnkuaCB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5jb21wYXQvbWVtb3J5LmMubmV3DQpt
diAtZiBjb21wYXQvbWVtb3J5LmMubmV3IGNvbXBhdC9tZW1vcnkuYw0KZ2NjIC1FIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAt
Zm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVibGljL3hl
bi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9tZW1vcnkuaSBjb21wYXQvbWVtb3J5LmMNCnNl
dCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvbWVtb3J5LmggfCB0ciAnWzpsb3dlcjpdLS8uJyAn
Wzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBhdC9tZW1vcnku
aC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvbWVtb3J5LmgubmV3OyBc
DQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L21lbW9yeS5oLm5l
dzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvbWVtb3J5Lmg+IiA+PmNvbXBhdC9tZW1v
cnkuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L21lbW9yeS5o
Lm5ldzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvbWVtb3J5LmkgfCBcDQogcHl0
aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxk
LWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQvbWVtb3J5LmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKCkiID4+Y29tcGF0L21lbW9yeS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAv
KiAkaWQgKi8iID4+Y29tcGF0L21lbW9yeS5oLm5ldw0KbXYgLWYgY29tcGF0L21lbW9yeS5o
Lm5ldyBjb21wYXQvbWVtb3J5LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUobG9uZyknIHB1YmxpYy9ubWkuaCB8IFwNCiBweXRob24gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNl
LnB5ID5jb21wYXQvbm1pLmMubmV3DQptdiAtZiBjb21wYXQvbm1pLmMubmV3IGNvbXBhdC9u
bWkuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
RFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUg
LWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9ubWkuaSBjb21w
YXQvbm1pLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvbm1pLmggfCB0ciAnWzpsb3dl
cjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBh
dC9ubWkuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvbm1pLmgubmV3
OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L25taS5oLm5l
dzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvbm1pLmg+IiA+PmNvbXBhdC9ubWkuaC5u
ZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L25taS5oLm5ldzsgXA0K
IGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvbm1pLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8
IHVuaXEgPj5jb21wYXQvbm1pLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+
Y29tcGF0L25taS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0
L25taS5oLm5ldw0KbXYgLWYgY29tcGF0L25taS5oLm5ldyBjb21wYXQvbm1pLmgNCm1rZGly
IC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobG9uZyknIHB1
YmxpYy9waHlzZGV2LmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L3BoeXNkZXYuYy5u
ZXcNCm12IC1mIGNvbXBhdC9waHlzZGV2LmMubmV3IGNvbXBhdC9waHlzZGV2LmMNCmdjYyAt
RSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlh
c2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlv
bi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1
aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1E
SEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1
YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvcGh5c2Rldi5pIGNvbXBhdC9waHlz
ZGV2LmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvcGh5c2Rldi5oIHwgdHIgJ1s6bG93
ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21w
YXQvcGh5c2Rldi5oLm5ldzsgXA0KIGVjaG8gIiNkZWZpbmUgJGlkIiA+PmNvbXBhdC9waHlz
ZGV2LmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0
L3BoeXNkZXYuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL3BoeXNkZXYuaD4i
ID4+Y29tcGF0L3BoeXNkZXYuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+
Y29tcGF0L3BoeXNkZXYuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L3Bo
eXNkZXYuaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90
b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9waHlzZGV2Lmgu
bmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+Y29tcGF0L3BoeXNkZXYuaC5uZXc7
IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9waHlzZGV2LmgubmV3DQpt
diAtZiBjb21wYXQvcGh5c2Rldi5oLm5ldyBjb21wYXQvcGh5c2Rldi5oDQpta2RpciAtcCBj
b21wYXQNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMv
cGxhdGZvcm0uaCB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5jb21wYXQvcGxhdGZvcm0uYy5uZXcN
Cm12IC1mIGNvbXBhdC9wbGF0Zm9ybS5jLm5ldyBjb21wYXQvcGxhdGZvcm0uYw0KZ2NjIC1F
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVp
bHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZs
b2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRl
cm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11
bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURI
QVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVi
bGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9wbGF0Zm9ybS5pIGNvbXBhdC9wbGF0
Zm9ybS5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0L3BsYXRmb3JtLmggfCB0ciAnWzps
b3dlcjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNv
bXBhdC9wbGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNkZWZpbmUgJGlkIiA+PmNvbXBhdC9w
bGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNv
bXBhdC9wbGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvcGxhdGZv
cm0uaD4iID4+Y29tcGF0L3BsYXRmb3JtLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNr
KDQpIiA+PmNvbXBhdC9wbGF0Zm9ybS5oLm5ldzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBj
b21wYXQvcGxhdGZvcm0uaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9w
bGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9wbGF0
Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0L3BsYXRm
b3JtLmgubmV3DQptdiAtZiBjb21wYXQvcGxhdGZvcm0uaC5uZXcgY29tcGF0L3BsYXRmb3Jt
LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
bG9uZyknIHB1YmxpYy9zY2hlZC5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC9zY2hl
ZC5jLm5ldw0KbXYgLWYgY29tcGF0L3NjaGVkLmMubmV3IGNvbXBhdC9zY2hlZC5jDQpnY2Mg
LUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1i
dWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGlu
Y2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9TRSAt
REhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVkZSBw
dWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L3NjaGVkLmkgY29tcGF0L3NjaGVk
LmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvc2NoZWQuaCB8IHRyICdbOmxvd2VyOl0t
Ly4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYgJGlkIiA+Y29tcGF0L3Nj
aGVkLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3NjaGVkLmgubmV3
OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L3NjaGVkLmgu
bmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHB1YmxpYy9zY2hlZC5oPiIgPj5jb21wYXQvc2No
ZWQuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L3NjaGVkLmgu
bmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC9zY2hlZC5pIHwgXA0KIHB5dGhv
biAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1o
ZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3NjaGVkLmgubmV3OyBcDQogZWNobyAiI3ByYWdt
YSBwYWNrKCkiID4+Y29tcGF0L3NjaGVkLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRp
ZCAqLyIgPj5jb21wYXQvc2NoZWQuaC5uZXcNCm12IC1mIGNvbXBhdC9zY2hlZC5oLm5ldyBj
b21wYXQvc2NoZWQuaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dV
RVNUX0hBTkRMRShsb25nKScgcHVibGljL3RtZW0uaCB8IFwNCiBweXRob24gL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5j
b21wYXQvdG1lbS5jLm5ldw0KbXYgLWYgY29tcGF0L3RtZW0uYy5uZXcgY29tcGF0L3RtZW0u
Yw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
IC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQg
LW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25l
c3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hy
bw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtRFZF
UkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUgLWlu
Y2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC90bWVtLmkgY29tcGF0
L3RtZW0uYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC90bWVtLmggfCB0ciAnWzpsb3dl
cjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBh
dC90bWVtLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3RtZW0uaC5u
ZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvdG1lbS5o
Lm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvdG1lbS5oPiIgPj5jb21wYXQvdG1l
bS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvdG1lbS5oLm5l
dzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvdG1lbS5pIHwgXA0KIHB5dGhvbiAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1oZWFk
ZXIucHkgfCB1bmlxID4+Y29tcGF0L3RtZW0uaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBh
Y2soKSIgPj5jb21wYXQvdG1lbS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8i
ID4+Y29tcGF0L3RtZW0uaC5uZXcNCm12IC1mIGNvbXBhdC90bWVtLmgubmV3IGNvbXBhdC90
bWVtLmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5E
TEUobG9uZyknIHB1YmxpYy90cmFjZS5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC90
cmFjZS5jLm5ldw0KbXYgLWYgY29tcGF0L3RyYWNlLmMubmV3IGNvbXBhdC90cmFjZS5jDQpn
Y2MgLUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZu
by1idWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9T
RSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVk
ZSBwdWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L3RyYWNlLmkgY29tcGF0L3Ry
YWNlLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvdHJhY2UuaCB8IHRyICdbOmxvd2Vy
Ol0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYgJGlkIiA+Y29tcGF0
L3RyYWNlLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3RyYWNlLmgu
bmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L3RyYWNl
LmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHB1YmxpYy90cmFjZS5oPiIgPj5jb21wYXQv
dHJhY2UuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L3RyYWNl
LmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC90cmFjZS5pIHwgXA0KIHB5
dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWls
ZC1oZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3RyYWNlLmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKCkiID4+Y29tcGF0L3RyYWNlLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8q
ICRpZCAqLyIgPj5jb21wYXQvdHJhY2UuaC5uZXcNCm12IC1mIGNvbXBhdC90cmFjZS5oLm5l
dyBjb21wYXQvdHJhY2UuaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL3ZjcHUuaCB8IFwNCiBweXRob24gL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5
ID5jb21wYXQvdmNwdS5jLm5ldw0KbXYgLWYgY29tcGF0L3ZjcHUuYy5uZXcgY29tcGF0L3Zj
cHUuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
RFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUg
LWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC92Y3B1LmkgY29t
cGF0L3ZjcHUuYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC92Y3B1LmggfCB0ciAnWzps
b3dlcjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNv
bXBhdC92Y3B1LmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3ZjcHUu
aC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvdmNw
dS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvdmNwdS5oPiIgPj5jb21wYXQv
dmNwdS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvdmNwdS5o
Lm5ldzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvdmNwdS5pIHwgXA0KIHB5dGhv
biAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1o
ZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3ZjcHUuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21h
IHBhY2soKSIgPj5jb21wYXQvdmNwdS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQg
Ki8iID4+Y29tcGF0L3ZjcHUuaC5uZXcNCm12IC1mIGNvbXBhdC92Y3B1LmgubmV3IGNvbXBh
dC92Y3B1LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9I
QU5ETEUobG9uZyknIHB1YmxpYy92ZXJzaW9uLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29t
cGF0L3ZlcnNpb24uYy5uZXcNCm12IC1mIGNvbXBhdC92ZXJzaW9uLmMubmV3IGNvbXBhdC92
ZXJzaW9uLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlh
YmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvdmVyc2lv
bi5pIGNvbXBhdC92ZXJzaW9uLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvdmVyc2lv
bi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lm
bmRlZiAkaWQiID5jb21wYXQvdmVyc2lvbi5oLm5ldzsgXA0KIGVjaG8gIiNkZWZpbmUgJGlk
IiA+PmNvbXBhdC92ZXJzaW9uLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21w
YXQuaD4iID4+Y29tcGF0L3ZlcnNpb24uaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVi
bGljL3ZlcnNpb24uaD4iID4+Y29tcGF0L3ZlcnNpb24uaC5uZXc7IFwNCiBlY2hvICIjcHJh
Z21hIHBhY2soNCkiID4+Y29tcGF0L3ZlcnNpb24uaC5uZXc7IFwNCiBncmVwIC12ICdeIyBb
MC05XScgY29tcGF0L3ZlcnNpb24uaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNv
bXBhdC92ZXJzaW9uLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+Y29tcGF0
L3ZlcnNpb24uaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC92
ZXJzaW9uLmgubmV3DQptdiAtZiBjb21wYXQvdmVyc2lvbi5oLm5ldyBjb21wYXQvdmVyc2lv
bi5oDQpta2RpciAtcCBjb21wYXQNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExF
KGxvbmcpJyBwdWJsaWMveGVuLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L3hlbi5j
Lm5ldw0KbXYgLWYgY29tcGF0L3hlbi5jLm5ldyBjb21wYXQveGVuLmMNCmdjYyAtRSAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4g
LWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1ESEFTX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94
ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQveGVuLmkgY29tcGF0L3hlbi5jDQpzZXQgLWU7
IGlkPV8kKGVjaG8gY29tcGF0L3hlbi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6
XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQveGVuLmgubmV3OyBcDQog
ZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3hlbi5oLm5ldzsgXA0KIGVjaG8gIiNpbmNs
dWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC94ZW4uaC5uZXc7IFwNCiBlY2hvICIjaW5j
bHVkZSA8cHVibGljL3hlbi5oPiIgPj5jb21wYXQveGVuLmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKDQpIiA+PmNvbXBhdC94ZW4uaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05
XScgY29tcGF0L3hlbi5pIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1oZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3hl
bi5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC94ZW4uaC5uZXc7
IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC94ZW4uaC5uZXcNCm12IC1m
IGNvbXBhdC94ZW4uaC5uZXcgY29tcGF0L3hlbi5oDQpta2RpciAtcCBjb21wYXQNCmdyZXAg
LXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMveGVuY29tbS5oIHwg
XA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBh
dC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC94ZW5jb21tLmMubmV3DQptdiAtZiBjb21wYXQv
eGVuY29tbS5jLm5ldyBjb21wYXQveGVuY29tbS5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9J
TlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5o
IC1tMzIgLW8gY29tcGF0L3hlbmNvbW0uaSBjb21wYXQveGVuY29tbS5jDQpzZXQgLWU7IGlk
PV8kKGVjaG8gY29tcGF0L3hlbmNvbW0uaCB8IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVy
Ol1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYgJGlkIiA+Y29tcGF0L3hlbmNvbW0uaC5uZXc7
IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQveGVuY29tbS5oLm5ldzsgXA0KIGVj
aG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC94ZW5jb21tLmgubmV3OyBc
DQogZWNobyAiI2luY2x1ZGUgPHB1YmxpYy94ZW5jb21tLmg+IiA+PmNvbXBhdC94ZW5jb21t
LmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKDQpIiA+PmNvbXBhdC94ZW5jb21tLmgu
bmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC94ZW5jb21tLmkgfCBcDQogcHl0
aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxk
LWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQveGVuY29tbS5oLm5ldzsgXA0KIGVjaG8gIiNw
cmFnbWEgcGFjaygpIiA+PmNvbXBhdC94ZW5jb21tLmgubmV3OyBcDQogZWNobyAiI2VuZGlm
IC8qICRpZCAqLyIgPj5jb21wYXQveGVuY29tbS5oLm5ldw0KbXYgLWYgY29tcGF0L3hlbmNv
bW0uaC5uZXcgY29tcGF0L3hlbmNvbW0uaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL3hlbm9wcm9mLmggfCBcDQog
cHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1
aWxkLXNvdXJjZS5weSA+Y29tcGF0L3hlbm9wcm9mLmMubmV3DQptdiAtZiBjb21wYXQveGVu
b3Byb2YuYy5uZXcgY29tcGF0L3hlbm9wcm9mLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lO
VEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0Lmgg
LW0zMiAtbyBjb21wYXQveGVub3Byb2YuaSBjb21wYXQveGVub3Byb2YuYw0Kc2V0IC1lOyBp
ZD1fJChlY2hvIGNvbXBhdC94ZW5vcHJvZi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBw
ZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQveGVub3Byb2YuaC5u
ZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQveGVub3Byb2YuaC5uZXc7IFwN
CiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQveGVub3Byb2YuaC5u
ZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL3hlbm9wcm9mLmg+IiA+PmNvbXBhdC94
ZW5vcHJvZi5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQveGVu
b3Byb2YuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L3hlbm9wcm9mLmkg
fCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29t
cGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQveGVub3Byb2YuaC5uZXc7IFwN
CiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQveGVub3Byb2YuaC5uZXc7IFwNCiBl
Y2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC94ZW5vcHJvZi5oLm5ldw0KbXYgLWYg
Y29tcGF0L3hlbm9wcm9mLmgubmV3IGNvbXBhdC94ZW5vcHJvZi5oDQpta2RpciAtcCBjb21w
YXQvYXJjaC14ODYNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBw
dWJsaWMvYXJjaC14ODYveGVuLW1jYS5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC9h
cmNoLXg4Ni94ZW4tbWNhLmMubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5j
Lm5ldyBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9J
TlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5o
IC1tMzIgLW8gY29tcGF0L2FyY2gteDg2L3hlbi1tY2EuaSBjb21wYXQvYXJjaC14ODYveGVu
LW1jYS5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0L2FyY2gteDg2L3hlbi1tY2EuaCB8
IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYg
JGlkIiA+Y29tcGF0L2FyY2gteDg2L3hlbi1tY2EuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5l
ICRpZCIgPj5jb21wYXQvYXJjaC14ODYveGVuLW1jYS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNs
dWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4tbWNhLmgubmV3OyBc
DQogIFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L2FyY2gteDg2L3hlbi1t
Y2EuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L2FyY2gteDg2L3hlbi1t
Y2EuaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29s
cy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4t
bWNhLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+Y29tcGF0L2FyY2gteDg2
L3hlbi1tY2EuaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9h
cmNoLXg4Ni94ZW4tbWNhLmgubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5o
Lm5ldyBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5oDQpta2RpciAtcCBjb21wYXQvYXJjaC14
ODYNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMvYXJj
aC14ODYveGVuLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L2FyY2gteDg2L3hlbi5j
Lm5ldw0KbXYgLWYgY29tcGF0L2FyY2gteDg2L3hlbi5jLm5ldyBjb21wYXQvYXJjaC14ODYv
eGVuLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxl
IC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvYXJjaC14ODYv
eGVuLmkgY29tcGF0L2FyY2gteDg2L3hlbi5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0
L2FyY2gteDg2L3hlbi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBc
DQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQvYXJjaC14ODYveGVuLmgubmV3OyBcDQog
ZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L2FyY2gteDg2L3hlbi5oLm5ldzsgXA0KIGVj
aG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4uaC5u
ZXc7IFwNCiAgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvYXJjaC14ODYv
eGVuLmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC9hcmNoLXg4Ni94ZW4u
aSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9j
b21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4uaC5u
ZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQvYXJjaC14ODYveGVuLmgu
bmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIgPj5jb21wYXQvYXJjaC14ODYveGVu
LmgubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODYveGVuLmgubmV3IGNvbXBhdC9hcmNoLXg4
Ni94ZW4uaA0KbWtkaXIgLXAgY29tcGF0L2FyY2gteDg2DQpncmVwIC12ICdERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL2FyY2gteDg2L3hlbi14ODZfMzIuaCB8IFwN
CiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQt
YnVpbGQtc291cmNlLnB5ID5jb21wYXQvYXJjaC14ODYveGVuLXg4Nl8zMi5jLm5ldw0KbXYg
LWYgY29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuYy5uZXcgY29tcGF0L2FyY2gteDg2L3hl
bi14ODZfMzIuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0
aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZu
by1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FU
VFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19Y
RU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFy
aWFibGUgLWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9hcmNo
LXg4Ni94ZW4teDg2XzMyLmkgY29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuYw0Kc2V0IC1l
OyBpZD1fJChlY2hvIGNvbXBhdC9hcmNoLXg4Ni94ZW4teDg2XzMyLmggfCB0ciAnWzpsb3dl
cjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBh
dC9hcmNoLXg4Ni94ZW4teDg2XzMyLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+
Y29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8
eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvYXJjaC14ODYveGVuLXg4Nl8zMi5oLm5ldzsgXA0K
ICBcDQogZWNobyAiI3ByYWdtYSBwYWNrKDQpIiA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4teDg2
XzMyLmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC9hcmNoLXg4Ni94ZW4t
eDg2XzMyLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
dG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQvYXJjaC14ODYv
eGVuLXg4Nl8zMi5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9h
cmNoLXg4Ni94ZW4teDg2XzMyLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIg
Pj5jb21wYXQvYXJjaC14ODYveGVuLXg4Nl8zMi5oLm5ldw0KbXYgLWYgY29tcGF0L2FyY2gt
eDg2L3hlbi14ODZfMzIuaC5uZXcgY29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuaA0KbWtk
aXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShsb25nKScg
cHVibGljL2FyY2gteDg2XzMyLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L2FyY2gt
eDg2XzMyLmMubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODZfMzIuYy5uZXcgY29tcGF0L2Fy
Y2gteDg2XzMyLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZh
cmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvYXJj
aC14ODZfMzIuaSBjb21wYXQvYXJjaC14ODZfMzIuYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNv
bXBhdC9hcmNoLXg4Nl8zMi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycp
OyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7IFwN
CiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7IFwNCiBl
Y2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5u
ZXc7IFwNCiAgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvYXJjaC14ODZf
MzIuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L2FyY2gteDg2XzMyLmkg
fCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29t
cGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7
IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7
IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9hcmNoLXg4Nl8zMi5oLm5l
dw0KbXYgLWYgY29tcGF0L2FyY2gteDg2XzMyLmgubmV3IGNvbXBhdC9hcmNoLXg4Nl8zMi5o
DQpleHBvcnQgUFlUSE9OPXB5dGhvbjsgXA0KIGdyZXAgLXYgJ15bICAgICBdKiMnIHhsYXQu
bHN0IHwgXA0KIHdoaWxlIHJlYWQgd2hhdCBuYW1lIGhkcjsgZG8gXA0KICAgICAgICAvYmlu
L3NoIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvZ2V0LWZpZWxkcy5z
aCAiJHdoYXQiIGNvbXBhdF8kbmFtZSAkKGVjaG8gY29tcGF0LyRoZHIgfCBzZWQgJ3MsQGFy
Y2hALHg4Nl8zMixnJykgfHwgZXhpdCAkPzsgXA0KIGRvbmUgPmNvbXBhdC94bGF0LmgubmV3
DQptdiAtZiBjb21wYXQveGxhdC5oLm5ldyBjb21wYXQveGxhdC5oDQpmb3IgaSBpbiBwdWJs
aWMvY2FsbGJhY2suaCBwdWJsaWMvZG9tMF9vcHMuaCBwdWJsaWMvZWxmbm90ZS5oIHB1Ymxp
Yy9ldmVudF9jaGFubmVsLmggcHVibGljL2ZlYXR1cmVzLmggcHVibGljL2dyYW50X3RhYmxl
LmggcHVibGljL2tleGVjLmggcHVibGljL21lbV9ldmVudC5oIHB1YmxpYy9tZW1vcnkuaCBw
dWJsDQppYy9ubWkuaCBwdWJsaWMvcGh5c2Rldi5oIHB1YmxpYy9wbGF0Zm9ybS5oIHB1Ymxp
Yy9zY2hlZC5oIHB1YmxpYy90bWVtLmggcHVibGljL3RyYWNlLmggcHVibGljL3ZjcHUuaCBw
dWJsaWMvdmVyc2lvbi5oIHB1YmxpYy94ZW5jb21tLmggcHVibGljL3hlbi1jb21wYXQuaCBw
dWJsaWMveGVuLmggcHVibGljL3hlDQpub3Byb2YuaCBwdWJsaWMvaHZtL2U4MjAuaCBwdWJs
aWMvaHZtL2h2bV9pbmZvX3RhYmxlLmggcHVibGljL2h2bS9odm1fb3AuaCBwdWJsaWMvaHZt
L2lvcmVxLmggcHVibGljL2h2bS9wYXJhbXMuaCBwdWJsaWMvaW8vYmxraWYuaCBwdWJsaWMv
aW8vY29uc29sZS5oIHB1YmxpYy9pby9mYmlmLmggcHVibGljL2lvDQovZnNpZi5oIHB1Ymxp
Yy9pby9rYmRpZi5oIHB1YmxpYy9pby9saWJ4ZW52Y2hhbi5oIHB1YmxpYy9pby9uZXRpZi5o
IHB1YmxpYy9pby9wY2lpZi5oIHB1YmxpYy9pby9wcm90b2NvbHMuaCBwdWJsaWMvaW8vcmlu
Zy5oIHB1YmxpYy9pby90cG1pZi5oIHB1YmxpYy9pby91c2JpZi5oIHB1YmxpYy9pby92c2Nz
aWlmDQouaCBwdWJsaWMvaW8veGVuYnVzLmggcHVibGljL2lvL3hzX3dpcmUuaDsgZG8gZ2Nj
IC1hbnNpIC1pbmNsdWRlIHN0ZGludC5oIC1XYWxsIC1XIC1XZXJyb3IgLVMgLW8gL2Rldi9u
dWxsIC14YyAkaSB8fCBleGl0IDE7IGVjaG8gJGk7IGRvbmUgPmhlYWRlcnMuY2hrLm5ldw0K
bXYgaGVhZGVycy5jaGsubmV3IGhlYWRlcnMuY2hrDQpybSBjb21wYXQveGVuLmMgY29tcGF0
L2tleGVjLmkgY29tcGF0L3RtZW0uaSBjb21wYXQvYXJjaC14ODZfMzIuYyBjb21wYXQvYXJj
aC14ODYveGVuLXg4Nl8zMi5jIGNvbXBhdC9tZW1vcnkuYyBjb21wYXQvc2NoZWQuYyBjb21w
YXQvdmNwdS5jIGNvbXBhdC94ZW4uaSBjb21wYXQvcGh5c2Rldi5pIGNvbXBhdC90DQpyYWNl
LmkgY29tcGF0L2ZlYXR1cmVzLmkgY29tcGF0L2NhbGxiYWNrLmMgY29tcGF0L2V2ZW50X2No
YW5uZWwuaSBjb21wYXQveGVuY29tbS5pIGNvbXBhdC9hcmNoLXg4Ni94ZW4uaSBjb21wYXQv
ZWxmbm90ZS5jIGNvbXBhdC9hcmNoLXg4Ni94ZW4tbWNhLmkgY29tcGF0L3ZlcnNpb24uaSBj
b21wYXQvcGxhdGZvDQpybS5pIGNvbXBhdC9rZXhlYy5jIGNvbXBhdC90bWVtLmMgY29tcGF0
L25taS5pIGNvbXBhdC9lbGZub3RlLmkgY29tcGF0L3BoeXNkZXYuYyBjb21wYXQvdmNwdS5p
IGNvbXBhdC90cmFjZS5jIGNvbXBhdC9mZWF0dXJlcy5jIGNvbXBhdC9ldmVudF9jaGFubmVs
LmMgY29tcGF0L2dyYW50X3RhYmxlLmkgY29tcGF0DQoveGVuY29tbS5jIGNvbXBhdC9hcmNo
LXg4Ni94ZW4uYyBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5jIGNvbXBhdC92ZXJzaW9uLmMg
Y29tcGF0L2FyY2gteDg2XzMyLmkgY29tcGF0L3BsYXRmb3JtLmMgY29tcGF0L21lbW9yeS5p
IGNvbXBhdC9zY2hlZC5pIGNvbXBhdC9ubWkuYyBjb21wYXQvY2FsbGJhY2suaSBjDQpvbXBh
dC94ZW5vcHJvZi5jIGNvbXBhdC94ZW5vcHJvZi5pIGNvbXBhdC9ncmFudF90YWJsZS5jIGNv
bXBhdC9hcmNoLXg4Ni94ZW4teDg2XzMyLmkNCm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUnDQptYWtlIC1mIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgYXJjaC94ODYgYXNt
LW9mZnNldHMucw0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2Jw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbQ0KbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZW5lcg0KaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25vdQ0Kcy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQw0KUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAuYXNtLW9mZnNldHMucy5kIC1TIC1vIGFzbS1vZmZzZXRzLnMg
eDg2XzY0L2FzbS1vZmZzZXRzLmMNCm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2Jw0KbWFrZSAtZiAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIGluY2x1ZGUvYXNtLXg4Ni9hc20t
b2Zmc2V0cy5oDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4nDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbicNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyBhcmNoL3g4NiAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL3hlbg0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2Jw0KbWFrZSAtZiAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vYXJjaC94ODYvYm9vdCBidWlsdF9pbi5vDQptYWtlWzRdOiBFbnRlcmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYv
Ym9vdCcNCm1ha2UgLWYgYnVpbGQzMi5tayByZWxvYy5TDQptYWtlWzVdOiBFbnRlcmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvYm9v
dCcNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW0zMiAtbWFyY2g9aTY4NiAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAtZm5vLXN0YWMNCmstcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV2Vy
cm9yIC1mbm8tYnVpbHRpbiAtbXNvZnQtZmxvYXQgIC1jIC1mcGljIHJlbG9jLmMgLW8gcmVs
b2Mubw0KbGQgLW1lbGZfaTM4NiAtTiAtVHRleHQgMCAtbyByZWxvYy5sbmsgcmVsb2Mubw0K
b2JqY29weSAtTyBiaW5hcnkgcmVsb2MubG5rIHJlbG9jLmJpbg0KKG9kIC12IC10IHggcmVs
b2MuYmluIHwgdHIgLXMgJyAnIHwgYXdrICdOUiA+IDEge3ByaW50IHN9IHtzPSQwfScgfCBc
DQogc2VkICdzLyAvLDB4L2cnIHwgc2VkICdzLywweCQvLycgfCBzZWQgJ3MvXlswLTldKiwv
IC5sb25nIC8nKSA+cmVsb2MuUw0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvYm9vdCcNCmdjYyAtRF9fQVNT
RU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1m
bm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmhlYWQuby5kIC1j
IGhlYWQuUyAtbyBoZWFkLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4u
byBoZWFkLm8NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2Jvb3QnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9hcmNoL3g4Ni9lZmkgYnVpbHRfaW4ubw0KbWFrZVs0XTogRW50ZXJpbmcgZGly
ZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2VmaScN
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnN0dWIuby5k
IC1mc2hvcnQtd2NoYXIgLWMgc3R1Yi5jIC1vIHN0dWIubw0KbGQgICAgLW1lbGZfeDg2XzY0
ICAtciAtbyBidWlsdF9pbi5vIHN0dWIubw0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvZWZpJw0KbWFrZSAt
ZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vY29tbW9uIGJ1aWx0X2luLm8NCm1ha2VbNF06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jb21t
b24nDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5iaXRt
YXAuby5kIC1jIGJpdG1hcC5jIC1vIGJpdG1hcC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jb3JlX3Bhcmtpbmcuby5kIC1jIGNvcmVfcGFya2lu
Zy5jIC1vIGNvcmVfcGFya2luZy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5jcHUuby5kIC1jIGNwdS5jIC1vIGNwdS5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVwb29sLm8uZCAtYyBjcHVwb29s
LmMgLW8gY3B1cG9vbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5kb21jdGwuby5kIC1jIGRvbWN0bC5jIC1vIGRvbWN0bC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kb21haW4uby5kIC1jIGRvbWFp
bi5jIC1vIGRvbWFpbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5ldmVudF9jaGFubmVsLm8uZCAtYyBldmVudF9jaGFubmVsLmMgLW8gZXZlbnRf
Y2hhbm5lbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5ncmFudF90YWJsZS5vLmQgLWMgZ3JhbnRfdGFibGUuYyAtbyBncmFudF90YWJsZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pcnEuby5kIC1j
IGlycS5jIC1vIGlycS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5rZXJuZWwuby5kIC1jIGtlcm5lbC5jIC1vIGtlcm5lbC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5rZXloYW5kbGVyLm8uZCAtYyBr
ZXloYW5kbGVyLmMgLW8ga2V5aGFuZGxlci5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5rZXhlYy5vLmQgLWMga2V4ZWMuYyAtbyBrZXhlYy5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5saWIuby5kIC1j
IGxpYi5jIC1vIGxpYi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5tZW1vcnkuby5kIC1jIG1lbW9yeS5jIC1vIG1lbW9yeS5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tdWx0aWNhbGwuby5kIC1jIG11
bHRpY2FsbC5jIC1vIG11bHRpY2FsbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC5ub3RpZmllci5vLmQgLWMgbm90aWZpZXIuYyAtbyBub3RpZmll
ci5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wYWdl
X2FsbG9jLm8uZCAtYyBwYWdlX2FsbG9jLmMgLW8gcGFnZV9hbGxvYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wcmVlbXB0Lm8uZCAtYyBwcmVl
bXB0LmMgLW8gcHJlZW1wdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5yYW5nZXNldC5vLmQgLWMgcmFuZ2VzZXQuYyAtbyByYW5nZXNldC5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zY2hlZF9jcmVk
aXQuby5kIC1jIHNjaGVkX2NyZWRpdC5jIC1vIHNjaGVkX2NyZWRpdC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zY2hlZF9jcmVkaXQyLm8uZCAt
YyBzY2hlZF9jcmVkaXQyLmMgLW8gc2NoZWRfY3JlZGl0Mi5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zY2hlZF9zZWRmLm8uZCAtYyBzY2hlZF9z
ZWRmLmMgLW8gc2NoZWRfc2VkZi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5zY2hlZF9hcmluYzY1My5vLmQgLWMgc2NoZWRfYXJpbmM2NTMuYyAt
byBzY2hlZF9hcmluYzY1My5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5zY2hlZHVsZS5vLmQgLWMgc2NoZWR1bGUuYyAtbyBzY2hlZHVsZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zaHV0ZG93bi5v
LmQgLWMgc2h1dGRvd24uYyAtbyBzaHV0ZG93bi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zb2Z0aXJxLm8uZCAtYyBzb2Z0aXJxLmMgLW8gc29m
dGlycS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5z
b3J0Lm8uZCAtYyBzb3J0LmMgLW8gc29ydC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5zcGlubG9jay5vLmQgLWMgc3BpbmxvY2suYyAtbyBzcGlu
bG9jay5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5z
dG9wX21hY2hpbmUuby5kIC1jIHN0b3BfbWFjaGluZS5jIC1vIHN0b3BfbWFjaGluZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zdHJpbmcuby5k
IC1jIHN0cmluZy5jIC1vIHN0cmluZy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC5zeW1ib2xzLm8uZCAtYyBzeW1ib2xzLmMgLW8gc3ltYm9scy5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zeXNjdGwu
by5kIC1jIHN5c2N0bC5jIC1vIHN5c2N0bC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC50YXNrbGV0Lm8uZCAtYyB0YXNrbGV0LmMgLW8gdGFza2xl
dC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50aW1l
Lm8uZCAtYyB0aW1lLmMgLW8gdGltZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC50aW1lci5vLmQgLWMgdGltZXIuYyAtbyB0aW1lci5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50cmFjZS5vLmQgLWMg
dHJhY2UuYyAtbyB0cmFjZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC52ZXJzaW9uLm8uZCAtYyB2ZXJzaW9uLmMgLW8gdmVyc2lvbi5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC52c3ByaW50Zi5vLmQg
LWMgdnNwcmludGYuYyAtbyB2c3ByaW50Zi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC53YWl0Lm8uZCAtYyB3YWl0LmMgLW8gd2FpdC5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54bWFsbG9jX3Rsc2Yu
by5kIC1jIHhtYWxsb2NfdGxzZi5jIC1vIHhtYWxsb2NfdGxzZi5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5yY3VwZGF0ZS5vLmQgLWMgcmN1cGRh
dGUuYyAtbyByY3VwZGF0ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC50bWVtLm8uZCAtYyB0bWVtLmMgLW8gdG1lbS5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50bWVtX3hlbi5vLmQgLWMgdG1lbV94
ZW4uYyAtbyB0bWVtX3hlbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5yYWRpeC10cmVlLm8uZCAtYyByYWRpeC10cmVlLmMgLW8gcmFkaXgtdHJl
ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5yYnRy
ZWUuby5kIC1jIHJidHJlZS5jIC1vIHJidHJlZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5sem8uby5kIC1jIGx6by5jIC1vIGx6by5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54ZW5vcHJvZi5vLmQg
LWMgeGVub3Byb2YuYyAtbyB4ZW5vcHJvZi5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgY29tcGF0IGJ1aWx0X2luLm8NCm1ha2VbNV06
IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9j
b21tb24vY29tcGF0Jw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAuZG9tYWluLm8uZCAtYyBkb21haW4uYyAtbyBkb21haW4ubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAua2VybmVsLm8uZCAtYyBrZXJuZWwu
YyAtbyBrZXJuZWwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAubWVtb3J5Lm8uZCAtYyBtZW1vcnkuYyAtbyBtZW1vcnkubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubXVsdGljYWxsLm8uZCAtYyBtdWx0
aWNhbGwuYyAtbyBtdWx0aWNhbGwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAueGxhdC5vLmQgLWMgeGxhdC5jIC1vIHhsYXQubw0KZ2NjIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGlu
IC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUg
LVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5z
IC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndp
bmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9T
RSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudG1lbV94ZW4uby5kIC1jIHRt
ZW1feGVuLmMgLW8gdG1lbV94ZW4ubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWls
dF9pbi5vIGRvbWFpbi5vIGtlcm5lbC5vIG1lbW9yeS5vIG11bHRpY2FsbC5vIHhsYXQubyB0
bWVtX3hlbi5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9jb21tb24vY29tcGF0Jw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIGh2bSBidWlsdF9pbi5vDQptYWtlWzVd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
Y29tbW9uL2h2bScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnNhdmUuby5kIC1jIHNhdmUuYyAtbyBzYXZlLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAg
LXIgLW8gYnVpbHRfaW4ubyBzYXZlLm8NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1vbi9odm0nDQptYWtlIC1mIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgbGliZWxmIGJ1aWx0
X2luLm8NCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9jb21tb24vbGliZWxmJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAubGliZWxmLXRvb2xzLm8uZCAtYyBsaWJlbGYtdG9vbHMu
YyAtbyBsaWJlbGYtdG9vbHMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAubGliZWxmLWxvYWRlci5vLmQgLWMgbGliZWxmLWxvYWRlci5jIC1vIGxp
YmVsZi1sb2FkZXIubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAubGliZWxmLWRvbWluZm8uby5kIC1jIGxpYmVsZi1kb21pbmZvLmMgLW8gbGliZWxm
LWRvbWluZm8ubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBsaWJlbGYtdGVtcC5vIGxp
YmVsZi10b29scy5vIGxpYmVsZi1sb2FkZXIubyBsaWJlbGYtZG9taW5mby5vDQpvYmpjb3B5
IC0tcmVuYW1lLXNlY3Rpb24gLnRleHQ9LmluaXQudGV4dCAtLXJlbmFtZS1zZWN0aW9uIC5k
YXRhPS5pbml0LmRhdGEgbGliZWxmLXRlbXAubyBsaWJlbGYubw0KbGQgICAgLW1lbGZfeDg2
XzY0ICAtciAtbyBidWlsdF9pbi5vIGxpYmVsZi5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jb21tb24vbGliZWxmJw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZGVjb21wcmVz
cy5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgZGVjb21wcmVzcy5jIC1vIGRlY29tcHJl
c3Mubw0Kb2JqZHVtcCAtaCBkZWNvbXByZXNzLm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCos
MCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBj
YXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8
LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwN
CiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBkZWNvbXByZXNzLm86JG5h
bWUgaXMgMHgkc3oiID4mMjsgXA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHgg
KyAxKTs7IFwNCiAgICAgICAgZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2Vj
dGlvbiAucm9kYXRhPS5pbml0LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3Ry
MS4xPS5pbml0LnJvZGF0YS5zdHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEu
Mj0uaW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEu
ND0uaW5pdC5yb2RhdGEuc3RyMS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9
LmluaXQucm9kYXRhLnN0cjEuOCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5k
YXRhLnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJl
bC5sb2NhbCAtLXJlbmENCm1lLXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVs
LnJvIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVs
LnJvLmxvY2FsIGRlY29tcHJlc3MubyBkZWNvbXByZXNzLmluaXQubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYnVuemlwMi5vLmQgLURJTklUX1NF
Q1RJT05TX09OTFkgLWMgYnVuemlwMi5jIC1vIGJ1bnppcDIubw0Kb2JqZHVtcCAtaCBidW56
aXAyLm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4
IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAg
ICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8LmJzcykgXA0KICAgICAgICAgICAgICAg
IHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwNCiAgICAgICAgICAgICAgICBlY2hvICJF
cnJvcjogc2l6ZSBvZiBidW56aXAyLm86JG5hbWUgaXMgMHgkc3oiID4mMjsgXA0KICAgICAg
ICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAxKTs7IFwNCiAgICAgICAgZXNhYzsgXA0K
IGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhPS5pbml0LnJvZGF0YSAt
LXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4xPS5pbml0LnJvZGF0YS5zdHIxLjEgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0uaW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVu
YW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0uaW5pdC5yb2RhdGEuc3RyMS40IC0tcmVu
YW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9LmluaXQucm9kYXRhLnN0cjEuOCAtLXJlbmFt
ZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5k
YXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5sb2NhbCAtLXJlbmENCm1lLXNlY3Rpb24g
LmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEu
cmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJvLmxvY2FsIGJ1bnppcDIubyBidW56aXAy
LmluaXQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRl
ZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJ
QlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5f
XyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAu
dW54ei5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgdW54ei5jIC1vIHVueHoubw0Kb2Jq
ZHVtcCAtaCB1bnh6Lm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCosMCxnO3B9JyB8IHdoaWxl
IHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBjYXNlICIkbmFtZSIgaW4g
XA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8LmJzcykgXA0KICAgICAg
ICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwNCiAgICAgICAgICAgICAg
ICBlY2hvICJFcnJvcjogc2l6ZSBvZiB1bnh6Lm86JG5hbWUgaXMgMHgkc3oiID4mMjsgXA0K
ICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAxKTs7IFwNCiAgICAgICAgZXNh
YzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhPS5pbml0LnJv
ZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4xPS5pbml0LnJvZGF0YS5zdHIx
LjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0uaW5pdC5yb2RhdGEuc3RyMS4y
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0uaW5pdC5yb2RhdGEuc3RyMS40
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9LmluaXQucm9kYXRhLnN0cjEuOCAt
LXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1zZWN0
aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5sb2NhbCAtLXJlbmENCm1lLXNl
Y3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rpb24g
LmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJvLmxvY2FsIHVueHoubyB1bnh6
LmluaXQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRl
ZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJ
QlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5f
XyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAu
dW5sem1hLm8uZCAtRElOSVRfU0VDVElPTlNfT05MWSAtYyB1bmx6bWEuYyAtbyB1bmx6bWEu
bw0Kb2JqZHVtcCAtaCB1bmx6bWEubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiwwLGc7cH0n
IHwgd2hpbGUgcmVhZCBpZHggbmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNhc2UgIiRu
YW1lIiBpbiBcDQogICAgICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwuYnNzKSBc
DQogICAgICAgICAgICAgICAgdGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0KICAgICAg
ICAgICAgICAgIGVjaG8gIkVycm9yOiBzaXplIG9mIHVubHptYS5vOiRuYW1lIGlzIDB4JHN6
IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0ICQoZXhwciAkaWR4ICsgMSk7OyBcDQog
ICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0
YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMT0uaW5pdC5y
b2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjI9LmluaXQucm9k
YXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQoxLjQ9LmluaXQucm9k
YXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44PS5pbml0LnJvZGF0
YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWw9LmluaXQuZGF0YS5yZWwgLS1y
ZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9LmluaXQuZGF0YS5yZWwubG9jYWwgLS1y
ZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJlbC5ybyAtLXJlbmFt
ZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0uaW5pdC5kYXRhLnJlbC5yby5sb2NhbCB1
bmx6bWEubyB1bmx6bWEuaW5pdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC51bmx6by5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgdW5sem8u
YyAtbyB1bmx6by5vDQpvYmpkdW1wIC1oIHVubHpvLm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiB1bmx6by5vOiRuYW1l
IGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0ICQoZXhwciAkaWR4ICsg
MSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5IC0tcmVuYW1lLXNlY3Rp
b24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEu
MT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjI9
LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQoxLjQ9
LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44PS5p
bml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWw9LmluaXQuZGF0
YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9LmluaXQuZGF0YS5yZWwu
bG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJlbC5y
byAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0uaW5pdC5kYXRhLnJlbC5y
by5sb2NhbCB1bmx6by5vIHVubHpvLmluaXQubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAt
byBidWlsdF9pbi5vIGJpdG1hcC5vIGNvcmVfcGFya2luZy5vIGNwdS5vIGNwdXBvb2wubyBk
b21jdGwubyBkb21haW4ubyBldmVudF9jaGFubmVsLm8gZ3JhbnRfdGFibGUubyBpcnEubyBr
ZXJuZWwubyBrZXloYW5kbGVyLm8ga2V4ZWMubyBsaWIubyBtZW1vcnkubyBtdQ0KbHRpY2Fs
bC5vIG5vdGlmaWVyLm8gcGFnZV9hbGxvYy5vIHByZWVtcHQubyByYW5nZXNldC5vIHNjaGVk
X2NyZWRpdC5vIHNjaGVkX2NyZWRpdDIubyBzY2hlZF9zZWRmLm8gc2NoZWRfYXJpbmM2NTMu
byBzY2hlZHVsZS5vIHNodXRkb3duLm8gc29mdGlycS5vIHNvcnQubyBzcGlubG9jay5vIHN0
b3BfbWFjaGluZQ0KLm8gc3RyaW5nLm8gc3ltYm9scy5vIHN5c2N0bC5vIHRhc2tsZXQubyB0
aW1lLm8gdGltZXIubyB0cmFjZS5vIHZlcnNpb24ubyB2c3ByaW50Zi5vIHdhaXQubyB4bWFs
bG9jX3Rsc2YubyByY3VwZGF0ZS5vIHRtZW0ubyB0bWVtX3hlbi5vIHJhZGl4LXRyZWUubyBy
YnRyZWUubyBsem8ubyB4ZW5vcHJvZi5vIGNvbQ0KcGF0L2J1aWx0X2luLm8gaHZtL2J1aWx0
X2luLm8gbGliZWxmL2J1aWx0X2luLm8gZGVjb21wcmVzcy5pbml0Lm8gYnVuemlwMi5pbml0
Lm8gdW54ei5pbml0Lm8gdW5sem1hLmluaXQubyB1bmx6by5pbml0Lm8NCm1ha2VbNF06IExl
YXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1v
bicNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAt
QyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMgYnVpbHRfaW4ubw0K
bWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2RyaXZlcnMnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vUnVsZXMubWsgLUMgY2hhciBidWlsdF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9jaGFyJw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuY29uc29sZS5v
LmQgLWMgY29uc29sZS5jIC1vIGNvbnNvbGUubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAubnMxNjU1MC5vLmQgLWMgbnMxNjU1MC5jIC1vIG5zMTY1
NTAubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuc2Vy
aWFsLm8uZCAtYyBzZXJpYWwuYyAtbyBzZXJpYWwubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAt
ciAtbyBidWlsdF9pbi5vIGNvbnNvbGUubyBuczE2NTUwLm8gc2VyaWFsLm8NCm1ha2VbNV06
IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2Ry
aXZlcnMvY2hhcicNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9S
dWxlcy5tayAtQyBjcHVmcmVxIGJ1aWx0X2luLm8NCm1ha2VbNV06IEVudGVyaW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2NwdWZyZXEn
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVx
Lm8uZCAtYyBjcHVmcmVxLmMgLW8gY3B1ZnJlcS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxX29uZGVtYW5kLm8uZCAtYyBjcHVmcmVx
X29uZGVtYW5kLmMgLW8gY3B1ZnJlcV9vbmRlbWFuZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxX21pc2NfZ292ZXJub3JzLm8uZCAt
YyBjcHVmcmVxX21pc2NfZ292ZXJub3JzLmMgLW8gY3B1ZnJlcV9taXNjX2dvdmVybm9ycy5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC51dGlsaXR5
Lm8uZCAtYyB1dGlsaXR5LmMgLW8gdXRpbGl0eS5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1y
IC1vIGJ1aWx0X2luLm8gY3B1ZnJlcS5vIGNwdWZyZXFfb25kZW1hbmQubyBjcHVmcmVxX21p
c2NfZ292ZXJub3JzLm8gdXRpbGl0eS5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2NwdWZyZXEnDQptYWtl
IC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgcGNpIGJ1
aWx0X2luLm8NCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3BjaScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnBjaS5vLmQgLWMgcGNpLmMgLW8gcGNpLm8NCmxkICAg
IC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyBwY2kubw0KbWFrZVs1XTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9w
Y2knDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
LUMgcGFzc3Rocm91Z2ggYnVpbHRfaW4ubw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gn
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pb21tdS5v
LmQgLWMgaW9tbXUuYyAtbyBpb21tdS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC5pby5vLmQgLWMgaW8uYyAtbyBpby5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wY2kuby5kIC1jIHBjaS5jIC1vIHBj
aS5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
LUMgdnRkIGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Z0ZCcNCmdj
YyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlh
c2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlv
bi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8t
YnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBp
bmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQt
ZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAt
RFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlvbW11Lm8uZCAt
YyBpb21tdS5jIC1vIGlvbW11Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLmRtYXIuby5kIC1jIGRtYXIuYyAtbyBkbWFyLm8NCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnV0aWxzLm8uZCAtYyB1dGlscy5j
IC1vIHV0aWxzLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnFpbnZhbC5vLmQgLWMgcWludmFsLmMgLW8gcWludmFsLm8NCmdjYyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5v
LWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJy
b3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5v
LXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5v
LXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRh
YmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURI
QVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmludHJlbWFwLm8uZCAtYyBpbnRyZW1h
cC5jIC1vIGludHJlbWFwLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLnF1aXJrcy5vLmQgLWMgcXVpcmtzLmMgLW8gcXVpcmtzLm8NCm1ha2UgLWYg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyB4ODYgYnVpbHRf
aW4ubw0KbWFrZVs3XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkL3g4NicNCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnZ0ZC5vLmQgLWMgdnRkLmMgLW8g
dnRkLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmF0
cy5vLmQgLWMgYXRzLmMgLW8gYXRzLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVp
bHRfaW4ubyB2dGQubyBhdHMubw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQveDg2
Jw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGlvbW11Lm8gZG1hci5v
IHV0aWxzLm8gcWludmFsLm8gaW50cmVtYXAubyBxdWlya3MubyB4ODYvYnVpbHRfaW4ubw0K
bWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgYW1kIGJ1aWx0X2luLm8NCm1ha2VbNl06
IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9k
cml2ZXJzL3Bhc3N0aHJvdWdoL2FtZCcNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3Ry
aWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVk
dW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVy
LWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
ICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3Rv
ciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8t
c3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNf
VklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0
ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFT
X1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BP
SU5URVIgLU1NRCAtTUYgLmlvbW11X2luaXQuby5kIC1jIGlvbW11X2luaXQuYyAtbyBpb21t
dV9pbml0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmlvbW11X21hcC5vLmQgLWMgaW9tbXVfbWFwLmMgLW8gaW9tbXVfbWFwLm8NCmdjYyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRp
biAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRl
IC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9h
dCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJu
cyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53
aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJP
U0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnBjaV9hbWRfaW9tbXUuby5k
IC1jIHBjaV9hbWRfaW9tbXUuYyAtbyBwY2lfYW1kX2lvbW11Lm8NCmdjYyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5v
LWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJy
b3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5v
LXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5v
LXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRh
YmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURI
QVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlvbW11X2ludHIuby5kIC1jIGlvbW11
X2ludHIuYyAtbyBpb21tdV9pbnRyLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3Ry
aWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVk
dW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVy
LWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
ICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3Rv
ciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8t
c3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNf
VklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0
ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFT
X1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BP
SU5URVIgLU1NRCAtTUYgLmlvbW11X2NtZC5vLmQgLWMgaW9tbXVfY21kLmMgLW8gaW9tbXVf
Y21kLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlv
bW11X2d1ZXN0Lm8uZCAtYyBpb21tdV9ndWVzdC5jIC1vIGlvbW11X2d1ZXN0Lm8NCmdjYyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVp
bHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlvbW11X2RldGVjdC5v
LmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgaW9tbXVfZGV0ZWN0LmMgLW8gaW9tbXVfZGV0
ZWN0Lm8NCm9iamR1bXAgLWggaW9tbXVfZGV0ZWN0Lm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBpb21tdV9kZXRlY3Qu
bzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAkKGV4cHIg
JGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0
YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEu
c3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsPS5p
bml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5pbml0LmRh
dGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89LmluaXQuZGF0
YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0
YS5yZWwucm8ubG9jYWwgaW9tbXVfZGV0ZWN0Lm8gaW9tbXVfZGV0ZWN0LmluaXQubw0KZ2Nj
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1i
dWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGlu
Y2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0
LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1l
eHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91
cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1E
VkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaW9tbXVfYWNwaS5v
LmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgaW9tbXVfYWNwaS5jIC1vIGlvbW11X2FjcGku
bw0Kb2JqZHVtcCAtaCBpb21tdV9hY3BpLm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCosMCxn
O3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBjYXNl
ICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8LmJz
cykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwNCiAg
ICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBpb21tdV9hY3BpLm86JG5hbWUg
aXMgMHgkc3oiID4mMjsgXA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAx
KTs7IFwNCiAgICAgICAgZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlv
biAucm9kYXRhPS5pbml0LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4x
PS5pbml0LnJvZGF0YS5zdHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0u
aW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0u
aW5pdC5yb2RhdGEuc3RyMS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9Lmlu
aXQucm9kYXRhLnN0cjEuOCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRh
LnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5s
b2NhbCAtLXJlbmENCm1lLXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJv
IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJv
LmxvY2FsIGlvbW11X2FjcGkubyBpb21tdV9hY3BpLmluaXQubw0KbGQgICAgLW1lbGZfeDg2
XzY0ICAtciAtbyBidWlsdF9pbi5vIGlvbW11X2luaXQubyBpb21tdV9tYXAubyBwY2lfYW1k
X2lvbW11Lm8gaW9tbXVfaW50ci5vIGlvbW11X2NtZC5vIGlvbW11X2d1ZXN0Lm8gaW9tbXVf
ZGV0ZWN0LmluaXQubyBpb21tdV9hY3BpLmluaXQubw0KbWFrZVs2XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9wYXNzdGhy
b3VnaC9hbWQnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVs
ZXMubWsgLUMgeDg2IGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3g4
NicNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmF0cy5v
LmQgLWMgYXRzLmMgLW8gYXRzLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRf
aW4ubyBhdHMubw0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC94ODYnDQpsZCAgICAtbWVs
Zl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8gaW9tbXUubyBpby5vIHBjaS5vIHZ0ZC9idWls
dF9pbi5vIGFtZC9idWlsdF9pbi5vIHg4Ni9idWlsdF9pbi5vDQptYWtlWzVdOiBMZWF2aW5n
IGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3Bh
c3N0aHJvdWdoJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1
bGVzLm1rIC1DIGFjcGkgYnVpbHRfaW4ubw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaScNCmdjYyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVp
bHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnRhYmxlcy5vLmQgLWMg
dGFibGVzLmMgLW8gdGFibGVzLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLm51bWEuby5kIC1jIG51bWEuYyAtbyBudW1hLm8NCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm9zbC5vLmQgLWMgb3NsLmMgLW8g
b3NsLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnBt
c3RhdC5vLmQgLWMgcG1zdGF0LmMgLW8gcG1zdGF0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmh3cmVncy5vLmQgLWMgaHdyZWdzLmMgLW8gaHdy
ZWdzLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnJl
Ym9vdC5vLmQgLWMgcmVib290LmMgLW8gcmVib290Lm8NCm1ha2UgLWYgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyB0YWJsZXMgYnVpbHRfaW4ubw0KbWFr
ZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2RyaXZlcnMvYWNwaS90YWJsZXMnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC50YnV0aWxzLm8uZCAtYyB0YnV0aWxzLmMgLW8gdGJ1dGlscy5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50YmZhZHQu
by5kIC1ESU5JVF9TRUNUSU9OU19PTkxZIC1jIHRiZmFkdC5jIC1vIHRiZmFkdC5vDQpvYmpk
dW1wIC1oIHRiZmFkdC5vIHwgc2VkIC1uICcvWzAtOV0ve3MsMDAqLDAsZztwfScgfCB3aGls
ZSByZWFkIGlkeCBuYW1lIHN6IHJlc3Q7IGRvIFwNCiAgICAgICAgY2FzZSAiJG5hbWUiIGlu
IFwNCiAgICAgICAgLnRleHR8LnRleHQuKnwuZGF0YXwuZGF0YS4qfC5ic3MpIFwNCiAgICAg
ICAgICAgICAgICB0ZXN0ICRzeiAhPSAwIHx8IGNvbnRpbnVlOyBcDQogICAgICAgICAgICAg
ICAgZWNobyAiRXJyb3I6IHNpemUgb2YgdGJmYWR0Lm86JG5hbWUgaXMgMHgkc3oiID4mMjsg
XA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAxKTs7IFwNCiAgICAgICAg
ZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhPS5pbml0
LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4xPS5pbml0LnJvZGF0YS5z
dHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0uaW5pdC5yb2RhdGEuc3Ry
MS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0uaW5pdC5yb2RhdGEuc3Ry
MS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9LmluaXQucm9kYXRhLnN0cjEu
OCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1z
ZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5sb2NhbCAtLXJlbmENCm1l
LXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rp
b24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJvLmxvY2FsIHRiZmFkdC5v
IHRiZmFkdC5pbml0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRl
Y2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1w
aXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5l
cmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4
Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGlj
IC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElU
WV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAt
RF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJP
VUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1N
RCAtTUYgLnRiaW5zdGFsLm8uZCAtRElOSVRfU0VDVElPTlNfT05MWSAtYyB0Ymluc3RhbC5j
IC1vIHRiaW5zdGFsLm8NCm9iamR1bXAgLWggdGJpbnN0YWwubyB8IHNlZCAtbiAnL1swLTld
L3tzLDAwKiwwLGc7cH0nIHwgd2hpbGUgcmVhZCBpZHggbmFtZSBzeiByZXN0OyBkbyBcDQog
ICAgICAgIGNhc2UgIiRuYW1lIiBpbiBcDQogICAgICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8
LmRhdGEuKnwuYnNzKSBcDQogICAgICAgICAgICAgICAgdGVzdCAkc3ogIT0gMCB8fCBjb250
aW51ZTsgXA0KICAgICAgICAgICAgICAgIGVjaG8gIkVycm9yOiBzaXplIG9mIHRiaW5zdGFs
Lm86JG5hbWUgaXMgMHgkc3oiID4mMjsgXA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHBy
ICRpZHggKyAxKTs7IFwNCiAgICAgICAgZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5h
bWUtc2VjdGlvbiAucm9kYXRhPS5pbml0LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2Rh
dGEuc3RyMS4xPS5pbml0LnJvZGF0YS5zdHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRh
LnN0cjEuMj0uaW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5z
dHINCjEuND0uaW5pdC5yb2RhdGEuc3RyMS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5z
dHIxLjg9LmluaXQucm9kYXRhLnN0cjEuOCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0u
aW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5k
YXRhLnJlbC5sb2NhbCAtLXJlbmENCm1lLXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRh
dGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRh
dGEucmVsLnJvLmxvY2FsIHRiaW5zdGFsLm8gdGJpbnN0YWwuaW5pdC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50YnhmYWNlLm8uZCAtRElOSVRf
U0VDVElPTlNfT05MWSAtYyB0YnhmYWNlLmMgLW8gdGJ4ZmFjZS5vDQpvYmpkdW1wIC1oIHRi
eGZhY2UubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiwwLGc7cH0nIHwgd2hpbGUgcmVhZCBp
ZHggbmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNhc2UgIiRuYW1lIiBpbiBcDQogICAg
ICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwuYnNzKSBcDQogICAgICAgICAgICAg
ICAgdGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0KICAgICAgICAgICAgICAgIGVjaG8g
IkVycm9yOiBzaXplIG9mIHRieGZhY2UubzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAg
ICAgICAgICAgICAgZXhpdCAkKGV4cHIgJGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBc
DQogZG9uZQ0Kb2JqY29weSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRh
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAt
LXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVu
YW1lLXNlY3Rpb24gLmRhdGEucmVsPS5pbml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24g
LmRhdGEucmVsLmxvY2FsPS5pbml0LmRhdGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlv
biAuZGF0YS5yZWwucm89LmluaXQuZGF0YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0
YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0YS5yZWwucm8ubG9jYWwgdGJ4ZmFjZS5vIHRieGZh
Y2UuaW5pdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC50Ynhmcm9vdC5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgdGJ4ZnJvb3QuYyAtbyB0
Ynhmcm9vdC5vDQpvYmpkdW1wIC1oIHRieGZyb290Lm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiB0Ynhmcm9vdC5vOiRu
YW1lIGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0ICQoZXhwciAkaWR4
ICsgMSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5IC0tcmVuYW1lLXNl
Y3Rpb24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cjEuMT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIx
LjI9LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQox
LjQ9LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44
PS5pbml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWw9LmluaXQu
ZGF0YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9LmluaXQuZGF0YS5y
ZWwubG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJl
bC5ybyAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0uaW5pdC5kYXRhLnJl
bC5yby5sb2NhbCB0Ynhmcm9vdC5vIHRieGZyb290LmluaXQubw0KbGQgICAgLW1lbGZfeDg2
XzY0ICAtciAtbyBidWlsdF9pbi5vIHRidXRpbHMubyB0YmZhZHQuaW5pdC5vIHRiaW5zdGFs
LmluaXQubyB0YnhmYWNlLmluaXQubyB0Ynhmcm9vdC5pbml0Lm8NCm1ha2VbNl06IExlYXZp
bmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMv
YWNwaS90YWJsZXMnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
UnVsZXMubWsgLUMgdXRpbGl0aWVzIGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2FjcGkv
dXRpbGl0aWVzJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMg
LWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0
aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZu
by1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FU
VFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19Y
RU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
eGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0gg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1N
RiAudXRnbG9iYWwuby5kIC1jIHV0Z2xvYmFsLmMgLW8gdXRnbG9iYWwubw0KZ2NjIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGlu
IC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUg
LVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5z
IC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndp
bmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9T
RSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudXRtaXNjLm8uZCAtRElOSVRf
U0VDVElPTlNfT05MWSAtYyB1dG1pc2MuYyAtbyB1dG1pc2Mubw0Kb2JqZHVtcCAtaCB1dG1p
c2MubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiwwLGc7cH0nIHwgd2hpbGUgcmVhZCBpZHgg
bmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNhc2UgIiRuYW1lIiBpbiBcDQogICAgICAg
IC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwuYnNzKSBcDQogICAgICAgICAgICAgICAg
dGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0KICAgICAgICAgICAgICAgIGVjaG8gIkVy
cm9yOiBzaXplIG9mIHV0bWlzYy5vOiRuYW1lIGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAg
ICAgICAgICBleGl0ICQoZXhwciAkaWR4ICsgMSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBk
b25lDQpvYmpjb3B5IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVu
YW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjI9LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQoxLjQ9LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44PS5pbml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUt
c2VjdGlvbiAuZGF0YS5yZWw9LmluaXQuZGF0YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0
YS5yZWwubG9jYWw9LmluaXQuZGF0YS5yZWwubG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5k
YXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJlbC5ybyAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJl
bC5yby5sb2NhbD0uaW5pdC5kYXRhLnJlbC5yby5sb2NhbCB1dG1pc2MubyB1dG1pc2MuaW5p
dC5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8gdXRnbG9iYWwubyB1
dG1pc2MuaW5pdC5vDQptYWtlWzZdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2FjcGkvdXRpbGl0aWVzJw0KbWFrZSAtZiAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIGFwZWkgYnVpbHRf
aW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaS9hcGVpJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZXJzdC5vLmQgLWMgZXJzdC5jIC1vIGVyc3Qubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYXBlaS1iYXNl
Lm8uZCAtYyBhcGVpLWJhc2UuYyAtbyBhcGVpLWJhc2Uubw0KZ2NjIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0K
b21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAt
V25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3Rh
Y2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVk
LXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVz
IC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0K
X0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05G
SUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYXBlaS1pby5vLmQgLWMgYXBlaS1pby5jIC1v
IGFwZWktaW8ubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGVyc3Qu
byBhcGVpLWJhc2UubyBhcGVpLWlvLm8NCm1ha2VbNl06IExlYXZpbmcgZGlyZWN0b3J5IGAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaS9hcGVpJw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIHRhYmxlcy5vIG51bWEubyBvc2wu
byBwbXN0YXQubyBod3JlZ3MubyByZWJvb3QubyB0YWJsZXMvYnVpbHRfaW4ubyB1dGlsaXRp
ZXMvYnVpbHRfaW4ubyBhcGVpL2J1aWx0X2luLm8NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaScNCm1h
a2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyB2aWRl
byBidWlsdF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy92aWRlbycNCmdjYyAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMN
Cm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJl
ZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMN
Cl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnZnYS5vLmQgLWMgdmdhLmMgLW8gdmdhLm8N
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmZvbnRfOHgx
NC5vLmQgLWMgZm9udF84eDE0LmMgLW8gZm9udF84eDE0Lm8NCmdjYyAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMN
Cm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJl
ZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMN
Cl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmZvbnRfOHgxNi5vLmQgLWMgZm9udF84eDE2
LmMgLW8gZm9udF84eDE2Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLmZvbnRfOHg4Lm8uZCAtYyBmb250Xzh4OC5jIC1vIGZvbnRfOHg4Lm8NCmdj
YyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlh
c2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlv
bi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8t
YnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBp
bmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQt
ZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAt
RFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnZlc2Euby5kIC1j
IHZlc2EuYyAtbyB2ZXNhLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4u
byB2Z2EubyBmb250Xzh4MTQubyBmb250Xzh4MTYubyBmb250Xzh4OC5vIHZlc2Eubw0KbWFr
ZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vZHJpdmVycy92aWRlbycNCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4u
byBjaGFyL2J1aWx0X2luLm8gY3B1ZnJlcS9idWlsdF9pbi5vIHBjaS9idWlsdF9pbi5vIHBh
c3N0aHJvdWdoL2J1aWx0X2luLm8gYWNwaS9idWlsdF9pbi5vIHZpZGVvL2J1aWx0X2luLm8N
Cm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2RyaXZlcnMnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vUnVsZXMubWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94c20gYnVp
bHRfaW4ubw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3hzbScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLnhzbV9jb3JlLm8uZCAtYyB4c21fY29yZS5jIC1vIHhzbV9jb3JlLm8N
CmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyB4c21fY29yZS5vDQptYWtl
WzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi94c20nDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMu
bWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NiBidWlsdF9p
bi5vDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vYXJjaC94ODYnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5hcGljLm8uZCAtYyBhcGljLmMgLW8gYXBpYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5iaXRvcHMuby5kIC1jIGJpdG9w
cy5jIC1vIGJpdG9wcy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5jb21wYXQuby5kIC1jIGNvbXBhdC5jIC1vIGNvbXBhdC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kZWJ1Zy5vLmQgLWMgZGVidWcu
YyAtbyBkZWJ1Zy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5kZWxheS5vLmQgLWMgZGVsYXkuYyAtbyBkZWxheS5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kb21jdGwuby5kIC1jIGRvbWN0bC5jIC1v
IGRvbWN0bC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5kb21haW4uby5kIC1jIGRvbWFpbi5jIC1vIGRvbWFpbi5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5lODIwLm8uZCAtYyBlODIwLmMgLW8gZTgy
MC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5leHRh
YmxlLm8uZCAtYyBleHRhYmxlLmMgLW8gZXh0YWJsZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5mbHVzaHRsYi5vLmQgLWMgZmx1c2h0bGIuYyAt
byBmbHVzaHRsYi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5wbGF0Zm9ybV9oeXBlcmNhbGwuby5kIC1jIHBsYXRmb3JtX2h5cGVyY2FsbC5jIC1v
IHBsYXRmb3JtX2h5cGVyY2FsbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5pMzg3Lm8uZCAtYyBpMzg3LmMgLW8gaTM4Ny5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pODI1OS5vLmQgLWMgaTgyNTku
YyAtbyBpODI1OS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5pb19hcGljLm8uZCAtYyBpb19hcGljLmMgLW8gaW9fYXBpYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tc2kuby5kIC1jIG1zaS5jIC1v
IG1zaS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5p
b3BvcnRfZW11bGF0ZS5vLmQgLWMgaW9wb3J0X2VtdWxhdGUuYyAtbyBpb3BvcnRfZW11bGF0
ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pcnEu
by5kIC1jIGlycS5jIC1vIGlycS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5taWNyb2NvZGVfYW1kLm8uZCAtYyBtaWNyb2NvZGVfYW1kLmMgLW8g
bWljcm9jb2RlX2FtZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5taWNyb2NvZGVfaW50ZWwuby5kIC1jIG1pY3JvY29kZV9pbnRlbC5jIC1vIG1p
Y3JvY29kZV9pbnRlbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5taWNyb2NvZGUuby5kIC1jIG1pY3JvY29kZS5jIC1vIG1pY3JvY29kZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tbS5vLmQgLWMg
bW0uYyAtbyBtbS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5tcHBhcnNlLm8uZCAtYyBtcHBhcnNlLmMgLW8gbXBwYXJzZS5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ubWkuby5kIC1jIG5taS5jIC1v
IG5taS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5u
dW1hLm8uZCAtYyBudW1hLmMgLW8gbnVtYS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5wY2kuby5kIC1jIHBjaS5jIC1vIHBjaS5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wZXJjcHUuby5kIC1jIHBl
cmNwdS5jIC1vIHBlcmNwdS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5waHlzZGV2Lm8uZCAtYyBwaHlzZGV2LmMgLW8gcGh5c2Rldi5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zZXR1cC5vLmQgLWMg
c2V0dXAuYyAtbyBzZXR1cC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5zaHV0ZG93bi5vLmQgLWMgc2h1dGRvd24uYyAtbyBzaHV0ZG93bi5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zbXAuby5kIC1j
IHNtcC5jIC1vIHNtcC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5zbXBib290Lm8uZCAtYyBzbXBib290LmMgLW8gc21wYm9vdC5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zcmF0Lm8uZCAtYyBzcmF0
LmMgLW8gc3JhdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5zdHJpbmcuby5kIC1jIHN0cmluZy5jIC1vIHN0cmluZy5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zeXNjdGwuby5kIC1jIHN5c2N0bC5j
IC1vIHN5c2N0bC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC50aW1lLm8uZCAtYyB0aW1lLmMgLW8gdGltZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50cmFjZS5vLmQgLWMgdHJhY2UuYyAtbyB0cmFj
ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50cmFw
cy5vLmQgLWMgdHJhcHMuYyAtbyB0cmFwcy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC51c2VyY29weS5vLmQgLWMgdXNlcmNvcHkuYyAtbyB1c2Vy
Y29weS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54
ODZfZW11bGF0ZS5vLmQgLWMgeDg2X2VtdWxhdGUuYyAtbyB4ODZfZW11bGF0ZS5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tYWNoaW5lX2tleGVj
Lm8uZCAtYyBtYWNoaW5lX2tleGVjLmMgLW8gbWFjaGluZV9rZXhlYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcmFzaC5vLmQgLWMgY3Jhc2gu
YyAtbyBjcmFzaC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC50Ym9vdC5vLmQgLWMgdGJvb3QuYyAtbyB0Ym9vdC5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ocGV0Lm8uZCAtYyBocGV0LmMgLW8gaHBl
dC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54c3Rh
dGUuby5kIC1jIHhzdGF0ZS5jIC1vIHhzdGF0ZS5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgYWNwaSBidWlsdF9pbi5vDQptYWtlWzVd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYvYWNwaScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRl
Y2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1w
aXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5l
cmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4
Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGlj
IC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElU
WV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAt
RF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJP
VUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1N
RCAtTUYgLmxpYi5vLmQgLWMgbGliLmMgLW8gbGliLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnBvd2VyLm8uZCAtYyBwb3dlci5jIC1vIHBvd2Vy
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnN1c3Bl
bmQuby5kIC1jIHN1c3BlbmQuYyAtbyBzdXNwZW5kLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNwdV9pZGxlLm8uZCAtYyBjcHVfaWRsZS5jIC1v
IGNwdV9pZGxlLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLmNwdWlkbGVfbWVudS5vLmQgLWMgY3B1aWRsZV9tZW51LmMgLW8gY3B1aWRsZV9tZW51
Lm8NCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAt
QyBjcHVmcmVxIGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEnDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxLm8u
ZCAtYyBjcHVmcmVxLmMgLW8gY3B1ZnJlcS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5wb3dlcm5vdy5vLmQgLWMgcG93ZXJub3cuYyAtbyBwb3dl
cm5vdy5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8gY3B1ZnJlcS5v
IHBvd2Vybm93Lm8NCm1ha2VbNl06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2FjcGkvY3B1ZnJlcScNCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmJvb3Quby5kIC1ESU5JVF9TRUNU
SU9OU19PTkxZIC1jIGJvb3QuYyAtbyBib290Lm8NCm9iamR1bXAgLWggYm9vdC5vIHwgc2Vk
IC1uICcvWzAtOV0ve3MsMDAqLDAsZztwfScgfCB3aGlsZSByZWFkIGlkeCBuYW1lIHN6IHJl
c3Q7IGRvIFwNCiAgICAgICAgY2FzZSAiJG5hbWUiIGluIFwNCiAgICAgICAgLnRleHR8LnRl
eHQuKnwuZGF0YXwuZGF0YS4qfC5ic3MpIFwNCiAgICAgICAgICAgICAgICB0ZXN0ICRzeiAh
PSAwIHx8IGNvbnRpbnVlOyBcDQogICAgICAgICAgICAgICAgZWNobyAiRXJyb3I6IHNpemUg
b2YgYm9vdC5vOiRuYW1lIGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0
ICQoZXhwciAkaWR4ICsgMSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlv
biAucm9kYXRhLnN0cjEuMT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24g
LnJvZGF0YS5zdHIxLjI9LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5y
b2RhdGEuc3RyDQoxLjQ9LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5y
b2RhdGEuc3RyMS44PS5pbml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0
YS5yZWw9LmluaXQuZGF0YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9
LmluaXQuZGF0YS5yZWwubG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0u
aW5pdC5kYXRhLnJlbC5ybyAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0u
aW5pdC5kYXRhLnJlbC5yby5sb2NhbCBib290Lm8gYm9vdC5pbml0Lm8NCmdjYyAtRF9fQVNT
RU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1m
bm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLndha2V1cF9wcm90
Lm8uZCAtYyB3YWtldXBfcHJvdC5TIC0NCm8gd2FrZXVwX3Byb3Qubw0KbGQgICAgLW1lbGZf
eDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGxpYi5vIHBvd2VyLm8gc3VzcGVuZC5vIGNwdV9p
ZGxlLm8gY3B1aWRsZV9tZW51Lm8gY3B1ZnJlcS9idWlsdF9pbi5vIGJvb3QuaW5pdC5vIHdh
a2V1cF9wcm90Lm8NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2FjcGknDQptYWtlIC1mIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgY3B1IGJ1aWx0X2luLm8NCm1ha2Vb
NV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9hcmNoL3g4Ni9jcHUnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5hbWQuby5kIC1jIGFtZC5jIC1vIGFtZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jb21tb24uby5kIC1jIGNvbW1vbi5jIC1vIGNv
bW1vbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5p
bnRlbC5vLmQgLWMgaW50ZWwuYyAtbyBpbnRlbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pbnRlbF9jYWNoZWluZm8uby5kIC1jIGludGVsX2Nh
Y2hlaW5mby5jIC1vIGludGVsX2NhY2hlaW5mby5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgbWNoZWNrIGJ1aWx0X2luLm8NCm1ha2Vb
Nl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9hcmNoL3g4Ni9jcHUvbWNoZWNrJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAuYW1kX25vbmZhdGFsLm8uZCAtYyBhbWRfbm9uZmF0YWwuYyAtbyBh
bWRfbm9uZmF0YWwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAuazcuby5kIC1jIGs3LmMgLW8gazcubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAuYW1kX2s4Lm8uZCAtYyBhbWRfazguYyAtbyBhbWRfazgu
bw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJl
Zml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQg
LW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25l
c3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hy
bw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5j
bHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZp
Zy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYW1kX2Yx
MC5vLmQgLWMgYW1kX2YxMC5jIC1vIGFtZF9mMTAubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubWN0ZWxlbS5vLmQgLWMgbWN0ZWxlbS5jIC1vIG1j
dGVsZW0ubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRl
ZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJ
QlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5f
XyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAu
bWNlLm8uZCAtYyBtY2UuYyAtbyBtY2Uubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdy
ZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50
ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAubWNlLWFwZWkuby5kIC1jIG1jZS1hcGVpLmMgLW8gbWNlLWFw
ZWkubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubWNl
X2ludGVsLm8uZCAtYyBtY2VfaW50ZWwuYyAtbyBtY2VfaW50ZWwubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubWNlX2FtZF9xdWlya3Muby5kIC1j
IG1jZV9hbWRfcXVpcmtzLmMgLW8gbWNlX2FtZF9xdWlya3Mubw0KZ2NjIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8t
Yw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJv
ciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8t
c3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFi
bGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
Uw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubm9uLWZhdGFsLm8uZCAtYyBub24tZmF0
YWwuYyAtbyBub24tZmF0YWwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAudm1jZS5vLmQgLWMgdm1jZS5jIC1vIHZtY2Uubw0KbGQgICAgLW1lbGZf
eDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGFtZF9ub25mYXRhbC5vIGs3Lm8gYW1kX2s4Lm8g
YW1kX2YxMC5vIG1jdGVsZW0ubyBtY2UubyBtY2UtYXBlaS5vIG1jZV9pbnRlbC5vIG1jZV9h
bWRfcXVpcmtzLm8gbm9uLWZhdGFsLm8gdm1jZS5vDQptYWtlWzZdOiBMZWF2aW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9jcHUvbWNo
ZWNrJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1r
IC1DIG10cnIgYnVpbHRfaW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2NwdS9tdHJyJw0KZ2NjIC1P
MSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5n
IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFm
dGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWls
dGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1
ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZs
b2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRl
cm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11
bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVS
Qk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZ2VuZXJpYy5vLmQgLWMg
Z2VuZXJpYy5jIC1vIGdlbmVyaWMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAubWFpbi5vLmQgLWMgbWFpbi5jIC1vIG1haW4ubw0KbGQgICAgLW1l
bGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGdlbmVyaWMubyBtYWluLm8NCm1ha2VbNl06
IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2Fy
Y2gveDg2L2NwdS9tdHJyJw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5v
IGFtZC5vIGNvbW1vbi5vIGludGVsLm8gaW50ZWxfY2FjaGVpbmZvLm8gbWNoZWNrL2J1aWx0
X2luLm8gbXRyci9idWlsdF9pbi5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9jcHUnDQptYWtlIC1mIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgZ2VuYXBpYyBidWls
dF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvZ2VuYXBpYycNCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmJpZ3NtcC5vLmQgLWMgYmlnc21wLmMgLW8gYmln
c21wLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLngy
YXBpYy5vLmQgLWMgeDJhcGljLmMgLW8geDJhcGljLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmRlZmF1bHQuby5kIC1jIGRlZmF1bHQuYyAtbyBk
ZWZhdWx0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmRlbGl2ZXJ5Lm8uZCAtYyBkZWxpdmVyeS5jIC1vIGRlbGl2ZXJ5Lm8NCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnByb2JlLm8uZCAtYyBwcm9iZS5j
IC1vIHByb2JlLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnN1bW1pdC5vLmQgLWMgc3VtbWl0LmMgLW8gc3VtbWl0Lm8NCmxkICAgIC1tZWxmX3g4
Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyBiaWdzbXAubyB4MmFwaWMubyBkZWZhdWx0Lm8gZGVs
aXZlcnkubyBwcm9iZS5vIHN1bW1pdC5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9nZW5hcGljJw0KbWFr
ZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIGh2bSBi
dWlsdF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZtJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYXNpZC5vLmQgLWMgYXNpZC5jIC1vIGFzaWQubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZW11bGF0ZS5v
LmQgLWMgZW11bGF0ZS5jIC1vIGVtdWxhdGUubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAuaHBldC5vLmQgLWMgaHBldC5jIC1vIGhwZXQubw0KZ2Nj
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1i
dWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGlu
Y2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0
LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1l
eHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91
cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1E
VkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaHZtLm8uZCAtYyBo
dm0uYyAtbyBodm0ubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAuaTgyNTQuby5kIC1jIGk4MjU0LmMgLW8gaTgyNTQubw0KZ2NjIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8t
Yw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJv
ciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8t
c3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFi
bGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
Uw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaW50ZXJjZXB0Lm8uZCAtYyBpbnRlcmNl
cHQuYyAtbyBpbnRlcmNlcHQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAuaW8uby5kIC1jIGlvLmMgLW8gaW8ubw0KZ2NjIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0K
b21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAt
V25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3Rh
Y2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVk
LXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVz
IC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0K
X0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05G
SUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaXJxLm8uZCAtYyBpcnEuYyAtbyBpcnEubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubXRyci5vLmQg
LWMgbXRyci5jIC1vIG10cnIubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAubmVzdGVkaHZtLm8uZCAtYyBuZXN0ZWRodm0uYyAtbyBuZXN0ZWRodm0u
bw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJl
Zml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQg
LW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25l
c3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hy
bw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5j
bHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZp
Zy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAucG10aW1l
ci5vLmQgLWMgcG10aW1lci5jIC1vIHBtdGltZXIubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAucXVpcmtzLm8uZCAtYyBxdWlya3MuYyAtbyBxdWly
a3Mubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAucnRj
Lm8uZCAtYyBydGMuYyAtbyBydGMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAuc2F2ZS5vLmQgLWMgc2F2ZS5jIC1vIHNhdmUubw0KZ2NjIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGlu
IC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUg
LVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5z
IC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndp
bmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9T
RSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuc3RkdmdhLm8uZCAtYyBzdGR2
Z2EuYyAtbyBzdGR2Z2Eubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQt
ZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGgg
LXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0K
bmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8t
ZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZw
aWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklM
SVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1n
IC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RI
Uk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAt
TU1EIC1NRiAudmlvYXBpYy5vLmQgLWMgdmlvYXBpYy5jIC1vIHZpb2FwaWMubw0KZ2NjIC1P
MSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5n
IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFm
dGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWls
dGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1
ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZs
b2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRl
cm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11
bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVS
Qk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudmlyaWRpYW4uby5kIC1j
IHZpcmlkaWFuLmMgLW8gdmlyaWRpYW4ubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdy
ZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50
ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAudmxhcGljLm8uZCAtYyB2bGFwaWMuYyAtbyB2bGFwaWMubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudm1zaS5vLmQg
LWMgdm1zaS5jIC1vIHZtc2kubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAudnBpYy5vLmQgLWMgdnBpYy5jIC1vIHZwaWMubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudnB0Lm8uZCAtYyB2cHQuYyAtbyB2
cHQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudnBt
dS5vLmQgLWMgdnBtdS5jIC1vIHZwbXUubw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIHN2bSBidWlsdF9pbi5vDQptYWtlWzZdOiBFbnRl
cmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94
ODYvaHZtL3N2bScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLmFzaWQuby5kIC1jIGFzaWQuYyAtbyBhc2lkLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmVtdWxhdGUuby5kIC1jIGVtdWxhdGUuYyAtbyBl
bXVsYXRlLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmludHIuby5kIC1jIGludHIuYyAtbyBpbnRyLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLm5lc3RlZHN2bS5vLmQgLWMgbmVzdGVkc3ZtLmMgLW8g
bmVzdGVkc3ZtLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnN2bS5vLmQgLWMgc3ZtLmMgLW8gc3ZtLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnN2bWRlYnVnLm8uZCAtYyBzdm1kZWJ1Zy5jIC1vIHN2
bWRlYnVnLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LnZtY2Iuby5kIC1jIHZtY2IuYyAtbyB2bWNiLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnZwbXUuby5kIC1jIHZwbXUuYyAtbyB2cG11Lm8NCmdj
YyAtRF9fQVNTRU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmVu
dHJ5Lm8uZCAtYyBlbnRyeS5TIC1vIGVudHJ5Lm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIg
LW8gYnVpbHRfaW4ubyBhc2lkLm8gZW11bGF0ZS5vIGludHIubyBuZXN0ZWRzdm0ubyBzdm0u
byBzdm1kZWJ1Zy5vIHZtY2IubyB2cG11Lm8gZW50cnkubw0KbWFrZVs2XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZt
L3N2bScNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5t
ayAtQyB2bXggYnVpbHRfaW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2h2bS92bXgnDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pbnRyLm8uZCAtYyBpbnRy
LmMgLW8gaW50ci5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5yZWFsbW9kZS5vLmQgLWMgcmVhbG1vZGUuYyAtbyByZWFsbW9kZS5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC52bWNzLm8uZCAtYyB2bWNz
LmMgLW8gdm1jcy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC52bXguby5kIC1jIHZteC5jIC1vIHZteC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC52cG11X2NvcmUyLm8uZCAtYyB2cG11X2NvcmUyLmMg
LW8gdnBtdV9jb3JlMi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC52dm14Lm8uZCAtYyB2dm14LmMgLW8gdnZteC5vDQpnY2MgLURfX0FTU0VNQkxZ
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
DQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1
aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1
ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
DQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5lbnRyeS5vLmQgLWMgZW50
cnkuUyAtbyBlbnRyeS5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8g
aW50ci5vIHJlYWxtb2RlLm8gdm1jcy5vIHZteC5vIHZwbXVfY29yZTIubyB2dm14Lm8gZW50
cnkubw0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZtL3ZteCcNCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIg
LW8gYnVpbHRfaW4ubyBhc2lkLm8gZW11bGF0ZS5vIGhwZXQubyBodm0ubyBpODI1NC5vIGlu
dGVyY2VwdC5vIGlvLm8gaXJxLm8gbXRyci5vIG5lc3RlZGh2bS5vIHBtdGltZXIubyBxdWly
a3MubyBydGMubyBzYXZlLm8gc3RkdmdhLm8gdmlvYXBpYy5vIHZpcmlkaWFuLm8NCiB2bGFw
aWMubyB2bXNpLm8gdnBpYy5vIHZwdC5vIHZwbXUubyBzdm0vYnVpbHRfaW4ubyB2bXgvYnVp
bHRfaW4ubw0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZtJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIG1tIGJ1aWx0X2luLm8NCm1ha2VbNV06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNo
L3g4Ni9tbScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LnBhZ2luZy5vLmQgLWMgcGFnaW5nLmMgLW8gcGFnaW5nLm8NCmdjYyAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMN
Cm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJl
ZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMN
Cl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnAybS5vLmQgLWMgcDJtLmMgLW8gcDJtLm8N
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnAybS1wdC5v
LmQgLWMgcDJtLXB0LmMgLW8gcDJtLXB0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3Rl
Y3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1t
bm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19I
QVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1u
b3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1E
SEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1F
X1BPSU5URVIgLU1NRCAtTUYgLnAybS1lcHQuby5kIC1jIHAybS1lcHQuYyAtbyBwMm0tZXB0
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnAybS1w
b2Quby5kIC1jIHAybS1wb2QuYyAtbyBwMm0tcG9kLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmd1ZXN0X3dhbGtfMi5vLmQgLURHVUVTVF9QQUdJ
TkdfTEVWRUxTPTIgLWMgZ3Vlc3Rfd2Fsay5jIC1vIGd1ZXN0X3dhbGtfMi5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ndWVzdF93YWxrXzMuby5k
IC1ER1VFU1RfUEFHSU5HX0xFVkVMUz0zIC1jIGd1ZXN0X3dhbGsuYyAtbyBndWVzdF93YWxr
XzMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZ3Vl
c3Rfd2Fsa180Lm8uZCAtREdVRVNUX1BBR0lOR19MRVZFTFM9NCAtYyBndWVzdF93YWxrLmMg
LW8gZ3Vlc3Rfd2Fsa180Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLm1lbV9ldmVudC5vLmQgLWMgbWVtX2V2ZW50LmMgLW8gbWVtX2V2ZW50Lm8N
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm1lbV9wYWdp
bmcuby5kIC1jIG1lbV9wYWdpbmcuYyAtbyBtZW1fcGFnaW5nLm8NCmdjYyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5v
LWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJy
b3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5v
LXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5v
LXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRh
YmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURI
QVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm1lbV9zaGFyaW5nLm8uZCAtYyBtZW1f
c2hhcmluZy5jIC1vIG1lbV9zaGFyaW5nLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3Rl
Y3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1t
bm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19I
QVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1u
b3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1E
SEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1F
X1BPSU5URVIgLU1NRCAtTUYgLm1lbV9hY2Nlc3Muby5kIC1jIG1lbV9hY2Nlc3MuYyAtbyBt
ZW1fYWNjZXNzLm8NCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9S
dWxlcy5tayAtQyBzaGFkb3cgYnVpbHRfaW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L21tL3NoYWRv
dycNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNvbW1v
bi5vLmQgLWMgY29tbW9uLmMgLW8gY29tbW9uLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLmd1ZXN0XzIuby5kIC1ER1VFU1RfUEFHSU5HX0xFVkVM
Uz0yIC1jIG11bHRpLmMgLW8gZ3Vlc3RfMi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5ndWVzdF8zLm8uZCAtREdVRVNUX1BBR0lOR19MRVZFTFM9
MyAtYyBtdWx0aS5jIC1vIGd1ZXN0XzMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdy
ZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50
ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAuZ3Vlc3RfNC5vLmQgLURHVUVTVF9QQUdJTkdfTEVWRUxTPTQg
LWMgbXVsdGkuYyAtbyBndWVzdF80Lm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVp
bHRfaW4ubyBjb21tb24ubyBndWVzdF8yLm8gZ3Vlc3RfMy5vIGd1ZXN0XzQubw0KbWFrZVs2
XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYvbW0vc2hhZG93Jw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL1J1bGVzLm1rIC1DIGhhcCBidWlsdF9pbi5vDQptYWtlWzZdOiBFbnRlcmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvbW0v
aGFwJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaGFw
Lm8uZCAtYyBoYXAuYyAtbyBoYXAubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAuZ3Vlc3Rfd2Fsa18ybGV2ZWwuby5kIC1ER1VFU1RfUEFHSU5HX0xF
VkVMUz0yIC1jIGd1ZXN0X3dhbGsuYyAtbyBndWVzdF93YWxrXzJsZXZlbC5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ndWVzdF93YWxrXzNsZXZl
bC5vLmQgLURHVUVTVF9QQUdJTkdfTEVWRUxTPTMgLWMgZ3Vlc3Rfd2Fsay5jIC1vIGd1ZXN0
X3dhbGtfM2xldmVsLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRl
Y2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1w
aXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5l
cmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4
Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGlj
IC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElU
WV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAt
RF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJP
VUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1N
RCAtTUYgLmd1ZXN0X3dhbGtfNGxldmVsLm8uZCAtREdVRVNUX1BBR0lOR19MRVZFTFM9NCAt
YyBndWVzdF93YWxrLmMgLW8gZ3Vlc3Rfd2Fsa180bGV2ZWwubw0KZ2NjIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8t
Yw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJv
ciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8t
c3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFi
bGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
Uw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubmVzdGVkX2hhcC5vLmQgLWMgbmVzdGVk
X2hhcC5jIC1vIG5lc3RlZF9oYXAubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWls
dF9pbi5vIGhhcC5vIGd1ZXN0X3dhbGtfMmxldmVsLm8gZ3Vlc3Rfd2Fsa18zbGV2ZWwubyBn
dWVzdF93YWxrXzRsZXZlbC5vIG5lc3RlZF9oYXAubw0KbWFrZVs2XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvbW0vaGFw
Jw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIHBhZ2luZy5vIHAybS5v
IHAybS1wdC5vIHAybS1lcHQubyBwMm0tcG9kLm8gZ3Vlc3Rfd2Fsa18yLm8gZ3Vlc3Rfd2Fs
a18zLm8gZ3Vlc3Rfd2Fsa180Lm8gbWVtX2V2ZW50Lm8gbWVtX3BhZ2luZy5vIG1lbV9zaGFy
aW5nLm8gbWVtX2FjY2Vzcy5vIA0Kc2hhZG93L2J1aWx0X2luLm8gaGFwL2J1aWx0X2luLm8N
Cm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2FyY2gveDg2L21tJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL1J1bGVzLm1rIC1DIG9wcm9maWxlIGJ1aWx0X2luLm8NCm1ha2VbNV06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni9vcHJvZmlsZScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnhlbm9wcm9mLm8uZCAtYyB4ZW5vcHJvZi5jIC1vIHhlbm9wcm9mLm8NCmdjYyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRp
biAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRl
IC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9h
dCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJu
cyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53
aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJP
U0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm5taV9pbnQuby5kIC1jIG5t
aV9pbnQuYyAtbyBubWlfaW50Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLm9wX21vZGVsX3A0Lm8uZCAtYyBvcF9tb2RlbF9wNC5jIC1vIG9wX21v
ZGVsX3A0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
Lm9wX21vZGVsX3Bwcm8uby5kIC1jIG9wX21vZGVsX3Bwcm8uYyAtbyBvcF9tb2RlbF9wcHJv
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm9wX21v
ZGVsX2F0aGxvbi5vLmQgLWMgb3BfbW9kZWxfYXRobG9uLmMgLW8gb3BfbW9kZWxfYXRobG9u
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmJhY2t0
cmFjZS5vLmQgLWMgYmFja3RyYWNlLmMgLW8gYmFja3RyYWNlLm8NCmxkICAgIC1tZWxmX3g4
Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyB4ZW5vcHJvZi5vIG5taV9pbnQubyBvcF9tb2RlbF9w
NC5vIG9wX21vZGVsX3Bwcm8ubyBvcF9tb2RlbF9hdGhsb24ubyBiYWNrdHJhY2Uubw0KbWFr
ZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vYXJjaC94ODYvb3Byb2ZpbGUnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vUnVsZXMubWsgLUMgeDg2XzY0IGJ1aWx0X2luLm8NCm1ha2VbNV06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni94ODZfNjQnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5tbS5vLmQgLWMgbW0uYyAtbyBtbS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC50cmFwcy5vLmQgLWMgdHJhcHMuYyAtbyB0cmFwcy5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tYWNoaW5lX2tleGVj
Lm8uZCAtYyBtYWNoaW5lX2tleGVjLmMgLW8gbWFjaGluZV9rZXhlYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wY2kuby5kIC1jIHBjaS5jIC1v
IHBjaS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5h
Y3BpX21tY2ZnLm8uZCAtYyBhY3BpX21tY2ZnLmMgLW8gYWNwaV9tbWNmZy5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tbWNvbmYtZmFtMTBoLm8u
ZCAtYyBtbWNvbmYtZmFtMTBoLmMgLW8gbW1jb25mLWZhbTEwaC5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tbWNvbmZpZ182NC5vLmQgLWMgbW1j
b25maWdfNjQuYyAtbyBtbWNvbmZpZ182NC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5tbWNvbmZpZy1zaGFyZWQuby5kIC1jIG1tY29uZmlnLXNo
YXJlZC5jIC1vIG1tY29uZmlnLXNoYXJlZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5jb21wYXQuby5kIC1jIGNvbXBhdC5jIC1vIGNvbXBhdC5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kb21haW4u
by5kIC1jIGRvbWFpbi5jIC1vIGRvbWFpbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5waHlzZGV2Lm8uZCAtYyBwaHlzZGV2LmMgLW8gcGh5c2Rl
di5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wbGF0
Zm9ybV9oeXBlcmNhbGwuby5kIC1jIHBsYXRmb3JtX2h5cGVyY2FsbC5jIC1vIHBsYXRmb3Jt
X2h5cGVyY2FsbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5jcHVfaWRsZS5vLmQgLWMgY3B1X2lkbGUuYyAtbyBjcHVfaWRsZS5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxLm8uZCAtYyBj
cHVmcmVxLmMgLW8gY3B1ZnJlcS5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vUnVsZXMubWsgLUMgY29tcGF0IGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0Jw0KZ2NjIC1EX19BU1NFTUJMWV9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLQ0KYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1mbm8tY29tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbg0K
Y2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aQ0Kb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50Lw0Kdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAuZW50cnkuby5kIC1jIGVudHJ5LlMgLW8gZW50cnkubw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGVudHJ5Lm8NCm1ha2VbNl06IExl
YXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gv
eDg2L3g4Nl82NC9jb21wYXQnDQpnY2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
DQpjbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5lbnRyeS5vLmQgLWMgZW50cnkuUyAtbyBlbnRyeS5vDQpn
Y2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2VuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpDQpv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5n
cHJfc3dpdGNoLm8uZCAtYyBncHJfc3dpdGNoLlMgLW8gDQpncHJfc3dpdGNoLm8NCmdjYyAt
RF9fQVNTRU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hyb25vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNvbXBh
dF9rZXhlYy5vLmQgLWMgY29tcGF0X2tleGVjLlMNCiAtbyBjb21wYXRfa2V4ZWMubw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIG1tLm8gdHJhcHMubyBtYWNoaW5l
X2tleGVjLm8gcGNpLm8gYWNwaV9tbWNmZy5vIG1tY29uZi1mYW0xMGgubyBtbWNvbmZpZ182
NC5vIG1tY29uZmlnLXNoYXJlZC5vIGNvbXBhdC5vIGRvbWFpbi5vIHBoeXNkZXYubyBwbGF0
Zm9ybV9oeXBlcmNhbA0KbC5vIGNwdV9pZGxlLm8gY3B1ZnJlcS5vIGNvbXBhdC9idWlsdF9p
bi5vIGVudHJ5Lm8gZ3ByX3N3aXRjaC5vIGNvbXBhdF9rZXhlYy5vDQptYWtlWzVdOiBMZWF2
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni94ODZfNjQnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5iemltYWdlLm8uZCAtRElOSVRfU0VDVElPTlNfT05MWSAtYyBiemltYWdlLmMgLW8gYnpp
bWFnZS5vDQpvYmpkdW1wIC1oIGJ6aW1hZ2UubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiww
LGc7cH0nIHwgd2hpbGUgcmVhZCBpZHggbmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNh
c2UgIiRuYW1lIiBpbiBcDQogICAgICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwu
YnNzKSBcDQogICAgICAgICAgICAgICAgdGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0K
ICAgICAgICAgICAgICAgIGVjaG8gIkVycm9yOiBzaXplIG9mIGJ6aW1hZ2UubzokbmFtZSBp
cyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAkKGV4cHIgJGlkeCArIDEp
OzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAtLXJlbmFtZS1zZWN0aW9u
IC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjE9
LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4yPS5p
bml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cg0KMS40PS5p
bml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuOD0uaW5p
dC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsPS5pbml0LmRhdGEu
cmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5pbml0LmRhdGEucmVsLmxv
Y2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89LmluaXQuZGF0YS5yZWwucm8g
LS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0YS5yZWwucm8u
bG9jYWwgYnppbWFnZS5vIGJ6aW1hZ2UuaW5pdC5vDQpnY2MgLURfX0FTU0VNQkxZX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4g
LWZuby1jb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luDQpjbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jbGVhcl9wYWdlLm8uZCAtYyBjbGVh
cl9wYWdlLlMgLW8gDQpjbGVhcl9wYWdlLm8NCmdjYyAtRF9fQVNTRU1CTFlfXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi0NCmFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5v
LWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC8NCnZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
U19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNvcHlfcGFnZS5vLmQgLWMgY29weV9wYWdl
LlMgLW8gY28NCnB5X3BhZ2Uubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAuZG1pX3NjYW4uby5kIC1ESU5JVF9TRUNUSU9OU19PTkxZIC1jIGRtaV9z
Y2FuLmMgLW8gZG1pX3NjYW4ubw0Kb2JqZHVtcCAtaCBkbWlfc2Nhbi5vIHwgc2VkIC1uICcv
WzAtOV0ve3MsMDAqLDAsZztwfScgfCB3aGlsZSByZWFkIGlkeCBuYW1lIHN6IHJlc3Q7IGRv
IFwNCiAgICAgICAgY2FzZSAiJG5hbWUiIGluIFwNCiAgICAgICAgLnRleHR8LnRleHQuKnwu
ZGF0YXwuZGF0YS4qfC5ic3MpIFwNCiAgICAgICAgICAgICAgICB0ZXN0ICRzeiAhPSAwIHx8
IGNvbnRpbnVlOyBcDQogICAgICAgICAgICAgICAgZWNobyAiRXJyb3I6IHNpemUgb2YgZG1p
X3NjYW4ubzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAk
KGV4cHIgJGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAt
LXJlbmFtZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24g
LnJvZGF0YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5y
b2RhdGEuc3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9k
YXRhLnN0cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9k
YXRhLnN0cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEu
cmVsPS5pbml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5p
bml0LmRhdGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89Lmlu
aXQuZGF0YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9Lmlu
aXQuZGF0YS5yZWwucm8ubG9jYWwgZG1pX3NjYW4ubyBkbWlfc2Nhbi5pbml0Lm8NCmdjYyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVp
bHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmRvbWFpbl9idWlsZC5v
LmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgZG9tYWluX2J1aWxkLmMgLW8gZG9tYWluX2J1
aWxkLm8NCm9iamR1bXAgLWggZG9tYWluX2J1aWxkLm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBkb21haW5fYnVpbGQu
bzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAkKGV4cHIg
JGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0
YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEu
c3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsPS5p
bml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5pbml0LmRh
dGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89LmluaXQuZGF0
YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0
YS5yZWwucm8ubG9jYWwgZG9tYWluX2J1aWxkLm8gZG9tYWluX2J1aWxkLmluaXQubw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGFwaWMubyBiaXRvcHMubyBjb21w
YXQubyBkZWJ1Zy5vIGRlbGF5Lm8gZG9tY3RsLm8gZG9tYWluLm8gZTgyMC5vIGV4dGFibGUu
byBmbHVzaHRsYi5vIHBsYXRmb3JtX2h5cGVyY2FsbC5vIGkzODcubyBpODI1OS5vIGlvX2Fw
aWMubyBtc2kubyBpbw0KcG9ydF9lbXVsYXRlLm8gaXJxLm8gbWljcm9jb2RlX2FtZC5vIG1p
Y3JvY29kZV9pbnRlbC5vIG1pY3JvY29kZS5vIG1tLm8gbXBwYXJzZS5vIG5taS5vIG51bWEu
byBwY2kubyBwZXJjcHUubyBwaHlzZGV2Lm8gc2V0dXAubyBzaHV0ZG93bi5vIHNtcC5vIHNt
cGJvb3QubyBzcmF0Lm8gc3RyaW5nLm8gc3lzY3RsLg0KbyB0aW1lLm8gdHJhY2UubyB0cmFw
cy5vIHVzZXJjb3B5Lm8geDg2X2VtdWxhdGUubyBtYWNoaW5lX2tleGVjLm8gY3Jhc2gubyB0
Ym9vdC5vIGhwZXQubyB4c3RhdGUubyBhY3BpL2J1aWx0X2luLm8gY3B1L2J1aWx0X2luLm8g
Z2VuYXBpYy9idWlsdF9pbi5vIGh2bS9idWlsdF9pbi5vIG1tL2J1aWx0X2luLm8gbw0KcHJv
ZmlsZS9idWlsdF9pbi5vIHg4Nl82NC9idWlsdF9pbi5vIGJ6aW1hZ2UuaW5pdC5vIGNsZWFy
X3BhZ2UubyBjb3B5X3BhZ2UubyBkbWlfc2Nhbi5pbml0Lm8gZG9tYWluX2J1aWxkLmluaXQu
bw0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vYXJjaC94ODYnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vUnVsZXMubWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jcnlw
dG8gYnVpbHRfaW4ubw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2NyeXB0bycNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnJpam5kYWVsLm8uZCAtYyByaWpuZGFlbC5jIC1vIHJp
am5kYWVsLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LnZtYWMuby5kIC1jIHZtYWMuYyAtbyB2bWFjLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIg
LW8gYnVpbHRfaW4ubyByaWpuZGFlbC5vIHZtYWMubw0KbWFrZVs0XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vY3J5cHRvJw0KbGQgICAg
LW1lbGZfeDg2XzY0ICAtciAtbyBwcmVsaW5rLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9hcmNoL3g4Ni9ib290L2J1aWx0X2luLm8gL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9hcmNoL3g4Ni9lZmkvYnVpbHRfaW4ubyAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveA0KZW4vY29tbW9uL2J1aWx0X2luLm8gL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9kcml2ZXJzL2J1aWx0X2luLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi94c20vYnVpbHRfaW4ubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2FyY2gveDg2L2J1aWx0X2luLm8gL21udC92bQ0KL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2NyeXB0by9idWlsdF9pbi5vDQpnY2MgLVAgLUUgLVVpMzg2IC1EX19BU1NFTUJMWV9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtDQpXZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGlu
IC1mbm8tY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
DQpibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yDQogLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtDQppbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAueGVuLmxkcy5kIC1vIHhlbi5sZHMg
DQp4ZW4ubGRzLlMNCnNlZCAtZSAncy94ZW5cLmxkc1wubzoveGVuXC5sZHM6L2cnIDwueGVu
Lmxkcy5kID4ueGVuLmxkcy5kLm5ldw0KbXYgLWYgLnhlbi5sZHMuZC5uZXcgLnhlbi5sZHMu
ZA0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1D
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vY29tbW9uIHN5bWJvbHMtZHVtbXku
bw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2NvbW1vbicNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLnN5bWJvbHMtZHVtbXkuby5kIC1jIHN5bWJvbHMtZHVtbXkuYyAtbyBzeW1i
b2xzLWR1bW15Lm8NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1vbicNCmxkICAgIC1tZWxmX3g4Nl82NCAgLVQgeGVu
LmxkcyAtTiBwcmVsaW5rLm8gXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2NvbW1vbi9zeW1ib2xzLWR1bW15Lm8gLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi8ueGVuLXN5bXMuMA0Kbm0gLW4gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMCB8IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMvc3ltYm9scyA+L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMu
MC5TDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMuMC5vDQptYWtlWzRd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYnDQpnY2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC4ueGVuLXN5bXMuMC5vLmQgLWMgL21udC92bS94ZW4veGVuDQotdW5zdGFi
bGUuaGcveGVuLy54ZW4tc3ltcy4wLlMgLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMC5vDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NicNCmxkICAgIC1tZWxmX3g4Nl82
NCAgLVQgeGVuLmxkcyAtTiBwcmVsaW5rLm8gXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuLy54ZW4tc3ltcy4wLm8gLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi8ueGVuLXN5bXMuMQ0Kbm0gLW4gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMSB8IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMvc3ltYm9scyA+L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMu
MS5TDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMuMS5vDQptYWtlWzRd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYnDQpnY2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC4ueGVuLXN5bXMuMS5vLmQgLWMgL21udC92bS94ZW4veGVuDQotdW5zdGFi
bGUuaGcveGVuLy54ZW4tc3ltcy4xLlMgLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMS5vDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NicNCmxkICAgIC1tZWxmX3g4Nl82
NCAgLVQgeGVuLmxkcyAtTiBwcmVsaW5rLm8gXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuLy54ZW4tc3ltcy4xLm8gLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi94ZW4tc3ltcw0Kcm0gLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi8ueGVuLXN5bXMuWzAtOV0qDQo6IGxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gcHJlbGlu
ay1lZmkubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2Jvb3Qv
YnVpbHRfaW4ubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1vbi9idWls
dF9pbi5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94DQplbi9kcml2ZXJzL2J1aWx0
X2luLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94c20vYnVpbHRfaW4ubyAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2J1aWx0X2luLm8gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jcnlwdG8vYnVpbHRfaW4ubyBlZmkvYm9v
DQp0LmluaXQubyBlZmkvcnVudGltZS5vIGVmaS9jb21wYXQubw0KZ2NjIC1QIC1FIC1VaTM4
NiAtREVGSSAtRF9fQVNTRU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dA0KeXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbg0KLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBybw0KdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WA0KRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLmVmaS5sZHMuZCAtbyBlZg0KaS5sZHMgeGVuLmxkcy5TDQpzZWQgLWUgJ3MvZWZpXC5s
ZHNcLm86L2VmaVwubGRzOi9nJyA8LmVmaS5sZHMuZCA+LmVmaS5sZHMuZC5uZXcNCm12IC1m
IC5lZmkubGRzLmQubmV3IC5lZmkubGRzLmQNCmdjYyAtRF9fQVNTRU1CTFlfXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi0NCmFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5v
LWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC8NCnZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
U19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnJlbG9jcy1kdW1teS5vLmQgLWMgZWZpL3Jl
bG9jcy1kdW0NCm15LlMgLW8gZWZpL3JlbG9jcy1kdW1teS5vDQpnY2MgLVdhbGwgLVdlcnJv
ciAtV3N0cmljdC1wcm90b3R5cGVzIC1PMiAtZm9taXQtZnJhbWUtcG9pbnRlciAtZm5vLXN0
cmljdC1hbGlhc2luZyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtZyAtbyBlZmkv
bWtyZWxvYyBlZmkvbWtyZWxvYy5jDQo6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAt
LWltYWdlLWJhc2U9MHhmZmZmODJjNDgwMDAwMDAwIC0tc3RhY2s9MCwwIC0taGVhcD0wLDAg
LS1zdHJpcC1kZWJ1ZyAtLXNlY3Rpb24tYWxpZ25tZW50PTB4MjAwMDAwIC0tZmlsZS1hbGln
bm1lbnQ9MHgyMCAtLW1ham9yLWltYWdlLXZlcnNpb249NCAtLW1pDQpub3ItaW1hZ2UtdmVy
c2lvbj0yIC0tbWFqb3Itb3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVyc2lvbj0wIC0tbWFq
b3Itc3Vic3lzdGVtLXZlcnNpb249MiAtLW1pbm9yLXN1YnN5c3RlbS12ZXJzaW9uPTAgLVQg
ZWZpLmxkcyAtTiBwcmVsaW5rLWVmaS5vIGVmaS9yZWxvY3MtZHVtbXkubyAvbW50L3ZtL3hl
bi94DQplbi11bnN0YWJsZS5oZy94ZW4vY29tbW9uL3N5bWJvbHMtZHVtbXkubyAtbyAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjB4ZmZmZjgyYzQ4MDAwMDAw
MC4wICYmICA6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAtLWltYWdlLWJhc2U9MHhm
ZmZmODJjNGMwMDAwMDAwIC0tc3RhDQpjaz0wLDAgLS1oZWFwPTAsMCAtLXN0cmlwLWRlYnVn
IC0tc2VjdGlvbi1hbGlnbm1lbnQ9MHgyMDAwMDAgLS1maWxlLWFsaWdubWVudD0weDIwIC0t
bWFqb3ItaW1hZ2UtdmVyc2lvbj00IC0tbWlub3ItaW1hZ2UtdmVyc2lvbj0yIC0tbWFqb3It
b3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVyc2lvbj0wIC0tbWFqDQpvci1zdWJzeXN0ZW0t
dmVyc2lvbj0yIC0tbWlub3Itc3Vic3lzdGVtLXZlcnNpb249MCAtVCBlZmkubGRzIC1OIHBy
ZWxpbmstZWZpLm8gZWZpL3JlbG9jcy1kdW1teS5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vY29tbW9uL3N5bWJvbHMtZHVtbXkubyAtbyAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFiDQpsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNGMwMDAwMDAwLjAgJiYgOg0KOiBl
ZmkvbWtyZWxvYyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjB4
ZmZmZjgyYzQ4MDAwMDAwMC4wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhl
bi5lZmkuMHhmZmZmODJjNGMwMDAwMDAwLjAgPi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vLnhlbi5lZg0KaS4wci5TDQo6IG5tIC1uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNDgwMDAwMDAwLjAgfCA6IC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvc3ltYm9scyA+L21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4wcy5TDQo6IG1ha2UgLWYgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuLy54ZW4uZWZpLjByLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVu
LmVmaS4wcy5vDQo6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAtLWltYWdlLWJhc2U9
MHhmZmZmODJjNDgwMDAwMDAwIC0tc3RhY2s9MCwwIC0taGVhcD0wLDAgLS1zdHJpcC1kZWJ1
ZyAtLXNlY3Rpb24tYWxpZ25tZW50PTB4MjAwMDAwIC0tZmlsZS1hbGlnbm1lbnQ9MHgyMCAt
LW1ham9yLWltYWdlLXZlcnNpb249NCAtLW1pDQpub3ItaW1hZ2UtdmVyc2lvbj0yIC0tbWFq
b3Itb3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVyc2lvbj0wIC0tbWFqb3Itc3Vic3lzdGVt
LXZlcnNpb249MiAtLW1pbm9yLXN1YnN5c3RlbS12ZXJzaW9uPTAgLVQgZWZpLmxkcyAtTiBw
cmVsaW5rLWVmaS5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vDQoueGVuLmVm
aS4wci5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHMubyAt
byAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjB4ZmZmZjgyYzQ4
MDAwMDAwMC4xICYmICA6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAtLWltYWdlLWJh
c2U9MHhmZmZmDQo4MmM0YzAwMDAwMDAgLS1zdGFjaz0wLDAgLS1oZWFwPTAsMCAtLXN0cmlw
LWRlYnVnIC0tc2VjdGlvbi1hbGlnbm1lbnQ9MHgyMDAwMDAgLS1maWxlLWFsaWdubWVudD0w
eDIwIC0tbWFqb3ItaW1hZ2UtdmVyc2lvbj00IC0tbWlub3ItaW1hZ2UtdmVyc2lvbj0yIC0t
bWFqb3Itb3MtdmVyc2lvbj0yIC0tbWlub3ItDQpvcy12ZXJzaW9uPTAgLS1tYWpvci1zdWJz
eXN0ZW0tdmVyc2lvbj0yIC0tbWlub3Itc3Vic3lzdGVtLXZlcnNpb249MCAtVCBlZmkubGRz
IC1OIHByZWxpbmstZWZpLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVu
LmVmaS4wci5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlDQpuLmVmaS4w
cy5vIC1vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZm
ODJjNGMwMDAwMDAwLjEgJiYgOg0KOiBlZmkvbWtyZWxvYyAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuLy54ZW4uZWZpLjB4ZmZmZjgyYzQ4MDAwMDAwMC4xIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNGMwMDAwMDAwLjEgPi9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZg0KaS4xci5TDQo6IG5tIC1u
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNDgw
MDAwMDAwLjEgfCA6IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvc3lt
Ym9scyA+L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4xcy5TDQo6
IG1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjFyLm8gL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4xcy5vDQo6IGxkIC1taTM4NnBlcCAtLXN1
YnN5c3RlbT0xMCAtLWltYWdlLWJhc2U9MHhmZmZmODJjNDgwMDAwMDAwIC0tc3RhY2s9MCww
IC0taGVhcD0wLDAgLS1zdHJpcC1kZWJ1ZyAtLXNlY3Rpb24tYWxpZ25tZW50PTB4MjAwMDAw
IC0tZmlsZS1hbGlnbm1lbnQ9MHgyMCAtLW1ham9yLWltYWdlLXZlcnNpb249NCAtLW1pDQpu
b3ItaW1hZ2UtdmVyc2lvbj0yIC0tbWFqb3Itb3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVy
c2lvbj0wIC0tbWFqb3Itc3Vic3lzdGVtLXZlcnNpb249MiAtLW1pbm9yLXN1YnN5c3RlbS12
ZXJzaW9uPTAgLVQgZWZpLmxkcyAtTiBwcmVsaW5rLWVmaS5vIFwNCiAgICAgICAgICAgICAg
ICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4xci5vIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMXMubyAtbyAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL3hlbi5lZmkNCmlmIDogZmFsc2U7IHRoZW4gcm0gLWYg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4uZWZpOyBlY2hvICdFRkkgc3Vw
cG9ydCBkaXNhYmxlZCc7IGZpDQpFRkkgc3VwcG9ydCBkaXNhYmxlZA0Kcm0gLWYgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS5bMC05XSoNCmdjYyAtV2FsbCAt
V2Vycm9yIC1Xc3RyaWN0LXByb3RvdHlwZXMgLU8yIC1mb21pdC1mcmFtZS1wb2ludGVyIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1vIGJv
b3QvbWtlbGYzMiBib290L21rZWxmMzIuYw0KLi9ib290L21rZWxmMzIgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4tc3ltcyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL3hlbiAweDEwMDAwMCBcDQogYG5tIC1uciAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL3hlbi1zeW1zIHwgaGVhZCAtbiAxIHwgc2VkIC1lICdzL15cKFteIF0qXCku
Ki8weFwxLydgDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NicNCmd6aXAgLWYgLTkgPCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL3hlbiA+IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4veGVuLmd6Lm5ldw0KbXYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4u
Z3oubmV3IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4veGVuLmd6DQpbIC1kIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvYm9vdCBdIHx8IGluc3Rh
bGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvYm9vdA0KaW5zdGFsbCAtbTA2NDQgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi94ZW4uZ3ogL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9i
b290L3hlbi00LjItdW5zdGFibGUuZ3oNCmxuIC1mIC1zIHhlbi00LjItdW5zdGFibGUuZ3og
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ib290L3hlbi00LjIu
Z3oNCmxuIC1mIC1zIHhlbi00LjItdW5zdGFibGUuZ3ogL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC9ib290L3hlbi00Lmd6DQpsbiAtZiAtcyB4ZW4tNC4yLXVu
c3RhYmxlLmd6IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvYm9v
dC94ZW4uZ3oNCmluc3RhbGwgLW0wNjQ0IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4veGVuLXN5bXMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFs
bC9ib290L3hlbi1zeW1zLTQuMi11bnN0YWJsZQ0KaWYgWyAtciAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3hlbi5lZmkgXTsgdGhlbiBcDQogICAgICAgIFsgLWQgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliL2VmaSBdIHx8IGlu
c3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2xpYi9lZmk7IFwNCiAgICAgICAgaW5zdGFsbCAtbTA2NDQgLXAgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4uZWZpIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi9lZmkveGVuLTQuMi11bnN0YWJsZS5lZmk7
IFwNCiAgICAgICAgbG4gLXNmIHhlbi00LjItdW5zdGFibGUuZWZpIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi9lZmkveGVuLTQuMi5lZmk7IFwN
CiAgICAgICAgbG4gLXNmIHhlbi00LjItdW5zdGFibGUuZWZpIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi9lZmkveGVuLTQuZWZpOyBcDQogICAg
ICAgIGxuIC1zZiB4ZW4tNC4yLXVuc3RhYmxlLmVmaSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9saWIvZWZpL3hlbi5lZmk7IFwNCiAgICAgICAgaWYg
WyAtbiAnL2Jvb3QvZWZpJyAtYSAtbiAnJyBdOyB0aGVuIFwNCiAgICAgICAgICAgICAgICBp
bnN0YWxsIC1tMDY0NCAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3hlbi5l
ZmkgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ib290L2VmaS9l
ZmkvL3hlbi00LjItdW5zdGFibGUuZWZpOyBcDQogICAgICAgIGVsaWYgWyAiL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbCIgPSAiZGlzdC9pbnN0YWxsIiBdOyB0
aGVuIFwNCiAgICAgICAgICAgICAgICBlY2hvICdFRkkgaW5zdGFsbGF0aW9uIG9ubHkgcGFy
dGlhbGx5IGRvbmUgKEVGSV9WRU5ET1Igbm90IHNldCknID4mMjsgXA0KICAgICAgICBmaTsg
XA0KIGZpDQptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbicNCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuJw0KZm9yIGkgaW4gIDsgZG8gbWFrZSAkaS1pbnN0YWxs
IHx8IGV4aXQgMTsgZG9uZQ0KbWFrZSAtQyB0b29scyBxZW11LXhlbi10cmFkaXRpb25hbC1k
aXItZmluZA0KbWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMnDQpzZXQgLWV4OyBcDQogaWYgdGVzdCAtZCBnaXQ6Ly94ZW5i
aXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0OyB0aGVuIFwNCiAgICAg
ICAgbWtkaXIgLXAgcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyOyBcDQogZWxzZSBcDQogICAg
ICAgIGV4cG9ydCBHSVQ9Z2l0OyBcDQogICAgICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy8uLi9zY3JpcHRzL2dpdC1jaGVja291dC5zaCBnaXQ6Ly94ZW5iaXRzLnhl
bnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0IDUwYzU1M2JlNDcyYzlmNGIwNWEw
NTI2YzBhYWU5ODcwOWNhOWZmZmYgcWVtdS14ZW4tdHJhZGl0aW9uDQphbC1kaXI7IFwNCiBm
aQ0KKyB0ZXN0IC1kIGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0
YWJsZS5naXQNCisgZXhwb3J0IEdJVD1naXQNCisgR0lUPWdpdA0KKyAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvLi4vc2NyaXB0cy9naXQtY2hlY2tvdXQuc2ggZ2l0Oi8v
eGVuYml0cy54ZW5zb3VyY2UuY29tL3FlbXUteGVuLXVuc3RhYmxlLmdpdCA1MGM1NTNiZTQ3
MmM5ZjRiMDVhMDUyNmMwYWFlOTg3MDljYTlmZmZmIHFlbXUteGVuLXRyYWRpdGlvbmFsLWRp
cg0KQ2xvbmluZyBpbnRvICdxZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtb3RlLnRtcCcu
Li4NCnJlbW90ZTogQ291bnRpbmcgb2JqZWN0czogMTA2NjY4LCBkb25lLg0KcmVtb3RlOiBD
b21wcmVzc2luZyBvYmplY3RzOiAxMDAlICgyOTEzOC8yOTEzOCksIGRvbmUuDQpyZW1vdGU6
IFRvdGFsIDEwNjY2OCAoZGVsdGEgODE2NjUpLCByZXVzZWQgMTAxODE0IChkZWx0YSA3NzM5
OCkgIA0KUmVjZWl2aW5nIG9iamVjdHM6IDEwMCUgKDEwNjY2OC8xMDY2NjgpLCAzNy41NyBN
aUIgfCAzOTUgS2lCL3MsIGRvbmUuDQpSZXNvbHZpbmcgZGVsdGFzOiAxMDAlICg4MTY2NS84
MTY2NSksIGRvbmUuDQpTd2l0Y2hlZCB0byBhIG5ldyBicmFuY2ggJ2R1bW15Jw0KbWFrZVsx
XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cycNCm1ha2UgLUMgdG9vbHMgcWVtdS14ZW4tZGlyLWZpbmQNCm1ha2VbMV06IEVudGVyaW5n
IGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KaWYgdGVz
dCAtZCBnaXQ6Ly9naXQucWVtdS5vcmcvcWVtdS5naXQgOyB0aGVuIFwNCiAgICAgICAgbWtk
aXIgLXAgcWVtdS14ZW4tZGlyOyBcDQogZWxzZSBcDQogICAgICAgIGV4cG9ydCBHSVQ9Z2l0
OyBcDQogICAgICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy8uLi9zY3Jp
cHRzL2dpdC1jaGVja291dC5zaCBnaXQ6Ly9naXQucWVtdS5vcmcvcWVtdS5naXQgbWFzdGVy
IHFlbXUteGVuLWRpciA7IFwNCiBmaQ0KQ2xvbmluZyBpbnRvICdxZW11LXhlbi1kaXItcmVt
b3RlLnRtcCcuLi4NCnJlbW90ZTogQ291bnRpbmcgb2JqZWN0czogMTEyMzg5LCBkb25lLg0K
cmVtb3RlOiBDb21wcmVzc2luZyBvYmplY3RzOiAxMDAlICgyMzk3OC8yMzk3OCksIGRvbmUu
DQpyZW1vdGU6IFRvdGFsIDExMjM4OSAoZGVsdGEgODg4MTcpLCByZXVzZWQgMTExNDg4IChk
ZWx0YSA4ODA2NCkgIA0KUmVjZWl2aW5nIG9iamVjdHM6IDEwMCUgKDExMjM4OS8xMTIzODkp
LCAzOS45OSBNaUIgfCA3NzUgS2lCL3MsIGRvbmUuDQpSZXNvbHZpbmcgZGVsdGFzOiAxMDAl
ICg4ODgxNy84ODgxNyksIGRvbmUuDQpTd2l0Y2hlZCB0byBhIG5ldyBicmFuY2ggJ2R1bW15
Jw0KbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scycNCm1ha2UgLUMgdG9vbHMgaW5zdGFsbA0KbWFrZVsxXTogRW50ZXJpbmcg
ZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnDQptYWtlWzJd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cycNCm1ha2UgLUMgaW5jbHVkZSBpbnN0YWxsDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3Rv
cnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlJw0KbWFrZSAt
QyB4ZW4tZm9yZWlnbg0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS94ZW4tZm9yZWlnbicNCnB5dGhvbiBt
a2hlYWRlci5weSB4ODZfMzIgeDg2XzMyLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2luY2x1ZGUveGVuLWZvcmVpZ24vLi4vLi4vLi4veGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gteDg2L3hlbi14ODZfMzIuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvaW5jbHUNCmRlL3hlbi1mb3JlaWduLy4uLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9h
cmNoLXg4Ni94ZW4uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVk
ZS94ZW4tZm9yZWlnbi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCnB5dGhv
biBta2hlYWRlci5weSB4ODZfNjQgeDg2XzY0LmggL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2luY2x1ZGUveGVuLWZvcmVpZ24vLi4vLi4vLi4veGVuL2luY2x1ZGUvcHVi
bGljL2FyY2gteDg2L3hlbi14ODZfNjQuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvaW5jbHUNCmRlL3hlbi1mb3JlaWduLy4uLy4uLy4uL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9hcmNoLXg4Ni94ZW4uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5j
bHVkZS94ZW4tZm9yZWlnbi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCnB5
dGhvbiBta2hlYWRlci5weSBpYTY0IGlhNjQuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvaW5jbHVkZS94ZW4tZm9yZWlnbi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJs
aWMvYXJjaC1pYTY0LmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1
ZGUveGVuLWZvcmVpZ24NCi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCnB5
dGhvbiBta2NoZWNrZXIucHkgY2hlY2tlci5jIHg4Nl8zMiB4ODZfNjQgaWE2NA0KZ2NjIC1X
YWxsIC1XZXJyb3IgLVdzdHJpY3QtcHJvdG90eXBlcyAtTzIgLWZvbWl0LWZyYW1lLXBvaW50
ZXIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LW8gY2hlY2tlciBjaGVja2VyLmMNCi4vY2hlY2tlciA+IHRtcC5zaXplDQpkaWZmIC11IHJl
ZmVyZW5jZS5zaXplIHRtcC5zaXplDQpybSB0bXAuc2l6ZQ0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlL3hl
bi1mb3JlaWduJw0KbWtkaXIgLXAgeGVuL2xpYmVsZg0KbG4gLXNmIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9D
T1BZSU5HIHhlbg0KbG4gLXNmIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9p
bmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9hcmNoLWlhNjQuaCAvbW50L3ZtL3hlbi94ZQ0Kbi11bnN0YWJsZS5oZy90b29scy9pbmNs
dWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Nl8zMi5oIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9hcmNoLXg4Nl82NC5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90bw0Kb2xzL2lu
Y2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2NhbGxiYWNrLmggL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGlj
L2RvbTBfb3BzLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUv
Li4vLi4veGVuLw0KaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmggL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2VsZm5v
dGUuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94
ZW4vaW5jbHVkZS9wdWJsaWMvZXZlbnRfY2hhbg0KbmVsLmggL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2ZlYXR1
cmVzLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4v
eGVuL2luY2x1ZGUvcHVibGljL2dyYW50X3RhYmxlLmggL21udC92bS94ZW4veA0KZW4tdW5z
dGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMva2V4ZWMu
aCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4v
aW5jbHVkZS9wdWJsaWMvbWVtX2V2ZW50LmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2luYw0KbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMvbWVtb3J5LmggL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1
ZGUvcHVibGljL25taS5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNs
dWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYw0KL3BoeXNkZXYuaCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMv
cGxhdGZvcm0uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8u
Li8uLi94ZW4vaW5jbHVkZS9wdWJsaWMvc2NoZWQuaCAvbW50L3ZtL3hlbi94ZQ0Kbi11bnN0
YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9zeXNjdGwu
aCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4v
aW5jbHVkZS9wdWJsaWMvdG1lbS5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9pbmNsdWRlLw0KLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL3RyYWNlLmggL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVi
bGljL3ZjcHUuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8u
Li8uLi94ZW4vaW5jbHVkZS9wdWJsaWMvdmVycw0KaW9uLmggL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL3hlbmNv
bW0uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94
ZW4vaW5jbHVkZS9wdWJsaWMveGVuLWNvbXBhdC5oIC9tbnQvdm0veGVuL3hlbg0KLXVuc3Rh
YmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL3hlbi5oIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNs
dWRlL3B1YmxpYy94ZW5vcHJvZi5oIHhlbg0KbG4gLXNmIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWlh
NjQgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVu
L2luY2x1ZGUvcHVibGljL2FyY2gteDg2IC9tbnQvdm0veGVuL3hlbi11bg0Kc3RhYmxlLmhn
L3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2h2bSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJs
aWMvaW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4v
eGVuL2luYw0KbHVkZS9wdWJsaWMveHNtIHhlbg0KbG4gLXNmIC4uL3hlbi1zeXMvTGludXgg
eGVuL3N5cw0KbG4gLXNmIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNs
dWRlLy4uLy4uL3hlbi9pbmNsdWRlL3hlbi9saWJlbGYuaCAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS94ZW4vZWxmc3RydWN0
cy5oIHhlbi9saWJlbGYvDQpsbiAtcyAuLi94ZW4tZm9yZWlnbiB4ZW4vZm9yZWlnbg0KdG91
Y2ggeGVuLy5kaXINCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRl
Ly4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUveGVuL2FyY2gtaWE2NA0K
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4vdG9vbHMv
Y3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vYXJjaC1pYTY0L2h2bQ0KL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5z
dGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC91c3IvaW5jbHVkZS94ZW4vYXJjaC14ODYNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1
IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1
ZGUveGVuL2FyY2gteDg2L2h2bQ0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vZm9y
ZWlnbg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4v
dG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vaHZtDQovbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxs
IC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9pbmNsdWRlL3hlbi9pbw0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vc3lz
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hlbi94c20NCi9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0w
NjQ0IC1wIHhlbi9DT1BZSU5HIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2luY2x1ZGUveGVuDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvaW5jbHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vKi5o
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUv
eGVuDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi90
b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vYXJjaC1pYTY0LyouaCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hlbi9hcmNo
LWlhNjQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4u
L3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9hcmNoLWlhNjQvaHZtLyouaCAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hl
bi9hcmNoLWlhNjQvaHZtDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5j
bHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vYXJjaC14ODYv
Ki5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1
ZGUveGVuL2FyY2gteDg2DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5j
bHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vYXJjaC14ODYv
aHZtLyouaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9p
bmNsdWRlL3hlbi9hcmNoLXg4Ni9odm0NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9m
b3JlaWduLyouaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vz
ci9pbmNsdWRlL3hlbi9mb3JlaWduDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvaW5jbHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vaHZt
LyouaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNs
dWRlL3hlbi9odm0NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRl
Ly4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9pby8qLmggL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vaW8N
Ci9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xz
L2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9zeXMvKi5oIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUveGVuL3N5cw0KL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5z
dGFsbCAtbTA2NDQgLXAgeGVuL3hzbS8qLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4veHNtDQptYWtlWzNdOiBMZWF2aW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUnDQpt
YWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzJw0KbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMnDQptYWtlIC1DIGxpYnhjIGluc3RhbGwNCm1ha2VbM106IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjJw0KbWFrZSBsaWJzDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4YycNCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfY29yZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRf
U09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4u
Ly4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUku
IC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfY29yZS5vIHhjX2NvcmUuYyANCmdjYyAg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0xTX18gLU0NCk1EIC1NRiAueGNfY29yZV94ODYuby5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlz
c2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0NCi94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2NvcmVf
eDg2Lm8geGNfY29yZV94ODYuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfY3B1
cG9vbC5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9j
b21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92
bS8NCnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVk
ZSAtcHRocmVhZCAgLWMgLW8geGNfY3B1cG9vbC5vIHhjX2NwdXBvb2wuYyANCmdjYyAgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RP
T0xTX18gLU0NCk1EIC1NRiAueGNfZG9tYWluLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dO
VV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Npbmct
cHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21haW4ubyB4
Y19kb21haW4uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfZXZ0Y2huLm8uZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtYyAtbyB4Y19ldnRjaG4ubyB4Y19ldnRjaG4uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfZ250dGFiLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2
NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1J
Li4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAt
SS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90
b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19nbnR0YWIubyB4Y19nbnR0YWIuYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbWlzYy5vLmQgIC1EX0xBUkdFRklMRV9T
T1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdt
aXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfbWlz
Yy5vIHhjX21pc2MuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfZmxhc2suby5k
ICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xp
YmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0veGUNCm4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJl
YWQgIC1jIC1vIHhjX2ZsYXNrLm8geGNfZmxhc2suYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfcGh5c2Rldi5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxF
NjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAt
SS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMg
LUkuIC1JL21udC92bS8NCnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4v
dG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfcGh5c2Rldi5vIHhjX3BoeXNkZXYu
YyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfcHJpdmF0ZS5vLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS8NCnhlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8g
eGNfcHJpdmF0ZS5vIHhjX3ByaXZhdGUuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAu
eGNfc2VkZi5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hl
bi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21u
dC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtcHRocmVhZCAgLWMgLW8geGNfc2VkZi5vIHhjX3NlZGYuYyANCmdjYyAgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xT
X18gLU0NCk1EIC1NRiAueGNfY3NjaGVkLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9M
QVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9T
T1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJv
dG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4
Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19jc2NoZWQubyB4Y19j
c2NoZWQuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfY3NjaGVkMi5vLmQgIC1E
X0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxm
IC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS8NCnhlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAg
LWMgLW8geGNfY3NjaGVkMi5vIHhjX2NzY2hlZDIuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfYXJpbmM2NTMuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklM
RTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAg
LUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVz
IC1JLiAtSS9tbnQvdm0NCi94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2FyaW5jNjUzLm8geGNfYXJpbmM2
NTMuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfdGJ1Zi5vLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8g
eGNfdGJ1Zi5vIHhjX3RidWYuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfcG0u
by5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9u
L2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0veGVu
L3gNCmVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0
aHJlYWQgIC1jIC1vIHhjX3BtLm8geGNfcG0uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1N
RiAueGNfY3B1X2hvdHBsdWcuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklM
RTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAg
LUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVz
IC1JLiAtSS9tbnQNCi92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2NwdV9ob3RwbHVnLm8geGNfY3B1
X2hvdHBsdWcuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfcmVzdW1lLm8uZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtYyAtbyB4Y19yZXN1bWUubyB4Y19yZXN1bWUuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfdG1lbS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRf
U09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4u
Ly4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUku
IC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfdG1lbS5vIHhjX3RtZW0uYyANCmdjYyAg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbWVtX2V2ZW50Lm8uZCAgLURfTEFSR0VGSUxFX1NP
VVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21p
c3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3YNCm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19tZW1f
ZXZlbnQubyB4Y19tZW1fZXZlbnQuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNf
bWVtX3BhZ2luZy5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1J
L21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfbWVtX3BhZ2luZy5vIHhjX21lbV9wYWdpbmcu
YyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbWVtX2FjY2Vzcy5vLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1X
ZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC8NCnZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMg
LW8geGNfbWVtX2FjY2Vzcy5vIHhjX21lbV9hY2Nlc3MuYyANCmdjYyAgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0N
Ck1EIC1NRiAueGNfbWVtc2hyLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJ
TEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0Ug
IC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBl
cyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8u
Li90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19tZW1zaHIubyB4Y19tZW1zaHIu
YyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfaGNhbGxfYnVmLm8uZCAgLURfTEFS
R0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdl
cnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3YNCm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAt
byB4Y19oY2FsbF9idWYubyB4Y19oY2FsbF9idWYuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfZm9yZWlnbl9tZW1vcnkuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xB
UkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NP
VVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90
b3R5cGVzIC1JLiAtSS8NCm1udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhj
Ly4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2ZvcmVpZ25fbWVtb3J5
Lm8geGNfZm9yZWlnbl9tZW1vcnkuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueHRs
X2NvcmUuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQv
dm0veGUNCm4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1jIC1vIHh0bF9jb3JlLm8geHRsX2NvcmUuYyANCmdjYyAgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xT
X18gLU0NCk1EIC1NRiAueHRsX2xvZ2dlcl9zdGRpby5vLmQgIC1EX0xBUkdFRklMRV9TT1VS
Q0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
RF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNz
aW5nLXByb3RvdHlwZXMgLUkuIC1JL20NCm50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geHRsX2xvZ2dl
cl9zdGRpby5vIHh0bF9sb2dnZXJfc3RkaW8uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1N
RiAueGNfcGFnZXRhYi5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRf
U09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4u
Ly4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUku
IC1JL21udC92bS8NCnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfcGFnZXRhYi5vIHhjX3BhZ2V0YWIuYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbGludXguby5kICAtRF9MQVJHRUZJTEVf
U09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1X
bWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0veGUNCm4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2xp
bnV4Lm8geGNfbGludXguYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbGludXhf
b3NkZXAuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQN
Ci92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2xpbnV4X29zZGVwLm8geGNfbGludXhfb3NkZXAuYyAN
CmFyIHJjIGxpYnhlbmN0cmwuYSB4Y19jb3JlLm8geGNfY29yZV94ODYubyB4Y19jcHVwb29s
Lm8geGNfZG9tYWluLm8geGNfZXZ0Y2huLm8geGNfZ250dGFiLm8geGNfbWlzYy5vIHhjX2Zs
YXNrLm8geGNfcGh5c2Rldi5vIHhjX3ByaXZhdGUubyB4Y19zZWRmLm8geGNfY3NjaGVkLm8g
eGNfY3NjaGVkMi5vIHhjX2ENCnJpbmM2NTMubyB4Y190YnVmLm8geGNfcG0ubyB4Y19jcHVf
aG90cGx1Zy5vIHhjX3Jlc3VtZS5vIHhjX3RtZW0ubyB4Y19tZW1fZXZlbnQubyB4Y19tZW1f
cGFnaW5nLm8geGNfbWVtX2FjY2Vzcy5vIHhjX21lbXNoci5vIHhjX2hjYWxsX2J1Zi5vIHhj
X2ZvcmVpZ25fbWVtb3J5Lm8geHRsX2NvcmUubyB4dGxfbG8NCmdnZXJfc3RkaW8ubyB4Y19w
YWdldGFiLm8geGNfbGludXgubyB4Y19saW51eF9vc2RlcC5vDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX2NvcmUub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX2NvcmUu
b3BpYyB4Y19jb3JlLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2Nv
cmVfeDg2Lm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VS
Q0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4v
eGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gDQot
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9p
bmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19jb3JlX3g4Ni5vcGljIHhjX2NvcmVf
eDg2LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2NwdXBvb2wub3Bp
Yy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9u
L2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtDQpJL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0
aHJlYWQgIC1mUElDIC1jIC1vIHhjX2NwdXBvb2wub3BpYyB4Y19jcHVwb29sLmMgDQpnY2Mg
IC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2RvbWFpbi5vcGljLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMg
LWMgLW8geGNfZG9tYWluLm9waWMgeGNfZG9tYWluLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpT
X18gLU1NRCAtTUYgLnhjX2V2dGNobi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURf
TEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVf
U09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXBy
b3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGli
eGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZXZ0Y2hu
Lm9waWMgeGNfZXZ0Y2huLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhj
X2dudHRhYi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1J
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZ250dGFiLm9waWMgeGNfZ250dGFi
LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21pc2Mub3BpYy5kICAt
RF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVs
ZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQg
IC1mUElDIC1jIC1vIHhjX21pc2Mub3BpYyB4Y19taXNjLmMgDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX2ZsYXNrLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dO
VV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Npbmct
cHJvdG90eXBlcyAtSS4gLUkvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19mbGFz
ay5vcGljIHhjX2ZsYXNrLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhj
X3BoeXNkZXYub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NP
VVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8u
Li94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAt
DQpJL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xz
L2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX3BoeXNkZXYub3BpYyB4Y19waHlz
ZGV2LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3ByaXZhdGUub3Bp
Yy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9u
L2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtDQpJL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0
aHJlYWQgIC1mUElDIC1jIC1vIHhjX3ByaXZhdGUub3BpYyB4Y19wcml2YXRlLmMgDQpnY2Mg
IC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3NlZGYub3BpYy5kICAtRF9MQVJHRUZJ
TEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9y
IC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1j
IC1vIHhjX3NlZGYub3BpYyB4Y19zZWRmLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1N
RCAtTUYgLnhjX2NzY2hlZC5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNF
ICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlw
ZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfY3NjaGVkLm9waWMg
eGNfY3NjaGVkLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2NzY2hl
ZDIub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtDQpJL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX2NzY2hlZDIub3BpYyB4Y19jc2NoZWQyLmMg
DQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2FyaW5jNjUzLm9waWMuZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gDQotSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtZlBJQyAtYyAtbyB4Y19hcmluYzY1My5vcGljIHhjX2FyaW5jNjUzLmMgDQpnY2MgIC1E
UElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3RidWYub3BpYy5kICAtRF9MQVJHRUZJTEVf
U09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1X
bWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1v
IHhjX3RidWYub3BpYyB4Y190YnVmLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAt
TUYgLnhjX3BtLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LUkvbW50DQovdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19wbS5vcGljIHhjX3BtLmMgDQpn
Y2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2NwdV9ob3RwbHVnLm9waWMuZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtDQpJLiAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtZlBJQyAtYyAtbyB4Y19jcHVfaG90cGx1Zy5vcGljIHhjX2NwdV9ob3RwbHVnLmMgDQpn
Y2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3Jlc3VtZS5vcGljLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1X
ZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQ
SUMgLWMgLW8geGNfcmVzdW1lLm9waWMgeGNfcmVzdW1lLmMgDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX3RtZW0ub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX3RtZW0u
b3BpYyB4Y190bWVtLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21l
bV9ldmVudC5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuDQog
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfbWVtX2V2ZW50Lm9waWMgeGNfbWVt
X2V2ZW50LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21lbV9wYWdp
bmcub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JDQouIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX21lbV9wYWdpbmcub3BpYyB4Y19tZW1fcGFn
aW5nLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21lbV9hY2Nlc3Mu
b3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29t
bW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JDQouIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUg
LXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX21lbV9hY2Nlc3Mub3BpYyB4Y19tZW1fYWNjZXNz
LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21lbXNoci5vcGljLmQg
IC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGli
ZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVh
ZCAgLWZQSUMgLWMgLW8geGNfbWVtc2hyLm9waWMgeGNfbWVtc2hyLmMgDQpnY2MgIC1EUElD
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hF
Tl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2hjYWxsX2J1Zi5vcGljLmQgIC1EX0xBUkdFRklM
RV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3Ig
LVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuDQogLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMg
LW8geGNfaGNhbGxfYnVmLm9waWMgeGNfaGNhbGxfYnVmLmMgDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX2ZvcmVpZ25fbWVtb3J5Lm9waWMuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAt
V21pc3NpbmctcHJvdG90eXBlDQpzIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAt
byB4Y19mb3JlaWduX21lbW9yeS5vcGljIHhjX2ZvcmVpZ25fbWVtb3J5LmMgDQpnY2MgIC1E
UElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnh0bF9jb3JlLm9waWMuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAt
V21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAt
byB4dGxfY29yZS5vcGljIHh0bF9jb3JlLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1N
RCAtTUYgLnh0bF9sb2dnZXJfc3RkaW8ub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzDQogLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHh0bF9sb2dn
ZXJfc3RkaW8ub3BpYyB4dGxfbG9nZ2VyX3N0ZGlvLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpT
X18gLU1NRCAtTUYgLnhjX3BhZ2V0YWIub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtDQpJL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX3BhZ2V0
YWIub3BpYyB4Y19wYWdldGFiLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYg
LnhjX2xpbnV4Lm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LUkvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19saW51eC5vcGljIHhjX2xpbnV4
LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2xpbnV4X29zZGVwLm9w
aWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1v
bi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtDQpJLiAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1w
dGhyZWFkICAtZlBJQyAtYyAtbyB4Y19saW51eF9vc2RlcC5vcGljIHhjX2xpbnV4X29zZGVw
LmMgDQpnY2MgICAgIC1wdGhyZWFkIC1XbCwtc29uYW1lIC1XbCxsaWJ4ZW5jdHJsLnNvLjQu
MiAtc2hhcmVkIC1vIGxpYnhlbmN0cmwuc28uNC4yLjAgeGNfY29yZS5vcGljIHhjX2NvcmVf
eDg2Lm9waWMgeGNfY3B1cG9vbC5vcGljIHhjX2RvbWFpbi5vcGljIHhjX2V2dGNobi5vcGlj
IHhjX2dudHRhYi5vcGljIHhjX21pDQpzYy5vcGljIHhjX2ZsYXNrLm9waWMgeGNfcGh5c2Rl
di5vcGljIHhjX3ByaXZhdGUub3BpYyB4Y19zZWRmLm9waWMgeGNfY3NjaGVkLm9waWMgeGNf
Y3NjaGVkMi5vcGljIHhjX2FyaW5jNjUzLm9waWMgeGNfdGJ1Zi5vcGljIHhjX3BtLm9waWMg
eGNfY3B1X2hvdHBsdWcub3BpYyB4Y19yZXN1bWUub3BpYyB4Y190DQptZW0ub3BpYyB4Y19t
ZW1fZXZlbnQub3BpYyB4Y19tZW1fcGFnaW5nLm9waWMgeGNfbWVtX2FjY2Vzcy5vcGljIHhj
X21lbXNoci5vcGljIHhjX2hjYWxsX2J1Zi5vcGljIHhjX2ZvcmVpZ25fbWVtb3J5Lm9waWMg
eHRsX2NvcmUub3BpYyB4dGxfbG9nZ2VyX3N0ZGlvLm9waWMgeGNfcGFnZXRhYi5vcGljIHhj
X2xpDQpudXgub3BpYyB4Y19saW51eF9vc2RlcC5vcGljIC1sZGwgIA0KbG4gLXNmIGxpYnhl
bmN0cmwuc28uNC4yLjAgbGlieGVuY3RybC5zby40LjINCmxuIC1zZiBsaWJ4ZW5jdHJsLnNv
LjQuMiBsaWJ4ZW5jdHJsLnNvDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhnX3ByaXZh
dGUuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29t
bW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0v
DQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUg
LXB0aHJlYWQgIC1jIC1vIHhnX3ByaXZhdGUubyB4Z19wcml2YXRlLmMgDQpnY2MgIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
U19fIC1NDQpNRCAtTUYgLnhjX3N1c3BlbmQuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tbnQvdm0vDQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX3N1c3BlbmQubyB4
Y19zdXNwZW5kLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbWFpbl9yZXN0
b3JlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2Nv
bW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvDQptbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRl
IC1wdGhyZWFkICAtYyAtbyB4Y19kb21haW5fcmVzdG9yZS5vIHhjX2RvbWFpbl9yZXN0b3Jl
LmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbWFpbl9zYXZlLm8uZCAgLURf
TEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYg
LVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50DQovdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAt
YyAtbyB4Y19kb21haW5fc2F2ZS5vIHhjX2RvbWFpbl9zYXZlLmMgDQpnY2MgIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19f
IC1NDQpNRCAtTUYgLnhjX29mZmxpbmVfcGFnZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0Ug
LURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9H
TlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5n
LXByb3RvdHlwZXMgLUkuIC1JL21uDQp0L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfb2ZmbGluZV9w
YWdlLm8geGNfb2ZmbGluZV9wYWdlLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhj
X2NvbXByZXNzaW9uLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LUkvbW50DQovdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19jb21wcmVzc2lvbi5vIHhjX2NvbXByZXNz
aW9uLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi10b29scy5vLmQgIC1E
X0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxm
IC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92DQptL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAg
LWMgLW8gbGliZWxmLXRvb2xzLm8gLi4vLi4veGVuL2NvbW1vbi9saWJlbGYvbGliZWxmLXRv
b2xzLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi1sb2FkZXIuby5kICAt
RF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVs
ZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvDQp2bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQg
IC1jIC1vIGxpYmVsZi1sb2FkZXIubyAuLi8uLi94ZW4vY29tbW9uL2xpYmVsZi9saWJlbGYt
bG9hZGVyLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi1kb21pbmZvLm8u
ZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9s
aWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50DQovdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhy
ZWFkICAtYyAtbyBsaWJlbGYtZG9taW5mby5vIC4uLy4uL3hlbi9jb21tb24vbGliZWxmL2xp
YmVsZi1kb21pbmZvLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi1yZWxv
Y2F0ZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9j
b21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21uDQp0
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVk
ZSAtcHRocmVhZCAgLWMgLW8gbGliZWxmLXJlbG9jYXRlLm8gLi4vLi4veGVuL2NvbW1vbi9s
aWJlbGYvbGliZWxmLXJlbG9jYXRlLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhj
X2RvbV9jb3JlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VS
Q0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4v
eGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkv
bW50L3ZtDQoveGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9p
bmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21fY29yZS5vIHhjX2RvbV9jb3JlLmMgDQpn
Y2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbV9ib290Lm8uZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAt
V21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtDQoveGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19k
b21fYm9vdC5vIHhjX2RvbV9ib290LmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhj
X2RvbV9lbGZsb2FkZXIuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0
X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUku
Li8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1J
LiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rv
b2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2RvbV9lbGZsb2FkZXIubyB4Y19kb21f
ZWxmbG9hZGVyLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbV9iemltYWdl
bG9hZGVyLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0Ug
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVu
L2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gDQotSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNs
dWRlIC1wdGhyZWFkIC1ESEFWRV9CWkxJQiAtbGJ6MiAgLWMgLW8geGNfZG9tX2J6aW1hZ2Vs
b2FkZXIubyB4Y19kb21fYnppbWFnZWxvYWRlci5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQg
LU1GIC54Y19kb21fYmlubG9hZGVyLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJH
RUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VS
Q0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90
eXBlcyAtSS4gLUkvbQ0KbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8u
Li8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21fYmlubG9hZGVyLm8g
eGNfZG9tX2JpbmxvYWRlci5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54Y19kb21f
Y29tcGF0X2xpbnV4Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LQ0KSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21fY29tcGF0X2xpbnV4Lm8geGNfZG9t
X2NvbXBhdF9saW51eC5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54Y19kb21feDg2
Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1v
bi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtLw0K
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1w
dGhyZWFkICAtYyAtbyB4Y19kb21feDg2Lm8geGNfZG9tX3g4Ni5jIA0KZ2NjICAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNf
XyAtTQ0KTUQgLU1GIC54Y19jcHVpZF94ODYuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tbnQvdg0KbS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2NwdWlkX3g4Ni5v
IHhjX2NwdWlkX3g4Ni5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54Y19odm1fYnVp
bGRfeDg2Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0Ug
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVu
L2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbQ0K
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNs
dWRlIC1wdGhyZWFkICAtYyAtbyB4Y19odm1fYnVpbGRfeDg2Lm8geGNfaHZtX2J1aWxkX3g4
Ni5jIA0KYXIgcmMgbGlieGVuZ3Vlc3QuYSB4Z19wcml2YXRlLm8geGNfc3VzcGVuZC5vIHhj
X2RvbWFpbl9yZXN0b3JlLm8geGNfZG9tYWluX3NhdmUubyB4Y19vZmZsaW5lX3BhZ2UubyB4
Y19jb21wcmVzc2lvbi5vIGxpYmVsZi10b29scy5vIGxpYmVsZi1sb2FkZXIubyBsaWJlbGYt
ZG9taW5mby5vIGxpYmVsZi1yZWxvYw0KYXRlLm8geGNfZG9tX2NvcmUubyB4Y19kb21fYm9v
dC5vIHhjX2RvbV9lbGZsb2FkZXIubyB4Y19kb21fYnppbWFnZWxvYWRlci5vIHhjX2RvbV9i
aW5sb2FkZXIubyB4Y19kb21fY29tcGF0X2xpbnV4Lm8geGNfZG9tX3g4Ni5vIHhjX2NwdWlk
X3g4Ni5vIHhjX2h2bV9idWlsZF94ODYubw0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQg
LU1GIC54Z19wcml2YXRlLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJ
TEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0Ug
IC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBl
cyAtSS4gLQ0KSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8u
Li90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Z19wcml2YXRlLm9waWMg
eGdfcHJpdmF0ZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19zdXNw
ZW5kLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0Ug
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVu
L2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLQ0KSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNs
dWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19zdXNwZW5kLm9waWMgeGNfc3VzcGVuZC5j
IA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21haW5fcmVzdG9yZS5v
cGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21t
b24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZQ0KcyAtSS4gLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAt
cHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9tYWluX3Jlc3RvcmUub3BpYyB4Y19kb21haW5f
cmVzdG9yZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21haW5f
c2F2ZS5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hl
bi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLQ0KSS4gLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9tYWluX3NhdmUub3BpYyB4Y19kb21h
aW5fc2F2ZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19vZmZsaW5l
X3BhZ2Uub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJD
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94
ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIA0KLUkuIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2lu
Y2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX29mZmxpbmVfcGFnZS5vcGljIHhjX29m
ZmxpbmVfcGFnZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19jb21w
cmVzc2lvbi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLQ0KSS4g
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfY29tcHJlc3Npb24ub3BpYyB4Y19j
b21wcmVzc2lvbi5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC5saWJlbGYt
dG9vbHMub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJD
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94
ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLg0KIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2lu
Y2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIGxpYmVsZi10b29scy5vcGljIC4uLy4uL3hl
bi9jb21tb24vbGliZWxmL2xpYmVsZi10b29scy5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19f
IC1NTUQgLU1GIC5saWJlbGYtbG9hZGVyLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dO
VV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Npbmct
cHJvdG90eXBlcyAtSQ0KLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyBsaWJlbGYt
bG9hZGVyLm9waWMgLi4vLi4veGVuL2NvbW1vbi9saWJlbGYvbGliZWxmLWxvYWRlci5jIA0K
Z2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC5saWJlbGYtZG9taW5mby5vcGljLmQg
IC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGli
ZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLQ0KSS4gLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVh
ZCAgLWZQSUMgLWMgLW8gbGliZWxmLWRvbWluZm8ub3BpYyAuLi8uLi94ZW4vY29tbW9uL2xp
YmVsZi9saWJlbGYtZG9taW5mby5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1G
IC5saWJlbGYtcmVsb2NhdGUub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdF
RklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJD
RSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5
cGVzIA0KLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4u
Ly4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIGxpYmVsZi1yZWxvY2F0
ZS5vcGljIC4uLy4uL3hlbi9jb21tb24vbGliZWxmL2xpYmVsZi1yZWxvY2F0ZS5jIA0KZ2Nj
ICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21fY29yZS5vcGljLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1X
ZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIA0KLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQ
SUMgLWMgLW8geGNfZG9tX2NvcmUub3BpYyB4Y19kb21fY29yZS5jIA0KZ2NjICAtRFBJQyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5f
VE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21fYm9vdC5vcGljLmQgIC1EX0xBUkdFRklMRV9T
T1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdt
aXNzaW5nLXByb3RvdHlwZXMgLUkuIA0KLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8g
eGNfZG9tX2Jvb3Qub3BpYyB4Y19kb21fYm9vdC5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19f
IC1NTUQgLU1GIC54Y19kb21fZWxmbG9hZGVyLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJD
RSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1E
X0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Np
bmctcHJvdG90eXBlcw0KIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19k
b21fZWxmbG9hZGVyLm9waWMgeGNfZG9tX2VsZmxvYWRlci5jIA0KZ2NjICAtRFBJQyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9P
TA0KU19fIC1NTUQgLU1GIC54Y19kb21fYnppbWFnZWxvYWRlci5vcGljLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdA0KeXBlcyAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAtREhBVkVf
QlpMSUIgLWxiejIgIC1mUElDIC1jIC1vIHhjX2RvbV9iemltYWdlbG9hZGVyLm9waWMgeGNf
ZG9tX2J6aW1hZ2Vsb2FkZXIuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAtTU1EIC1NRiAu
eGNfZG9tX2JpbmxvYWRlci5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNF
ICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlw
ZXMNCiAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9tX2JpbmxvYWRl
ci5vcGljIHhjX2RvbV9iaW5sb2FkZXIuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAtTU1E
IC1NRiAueGNfZG9tX2NvbXBhdF9saW51eC5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0Ug
LURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9H
TlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5n
LXByb3RvdHkNCnBlcyAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9t
X2NvbXBhdF9saW51eC5vcGljIHhjX2RvbV9jb21wYXRfbGludXguYyANCmdjYyAgLURQSUMg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0wNClNfXyAtTU1EIC1NRiAueGNfZG9tX3g4Ni5vcGljLmQgIC1EX0xBUkdFRklMRV9T
T1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdt
aXNzaW5nLXByb3RvdHlwZXMgLUkuIC0NCkkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8g
eGNfZG9tX3g4Ni5vcGljIHhjX2RvbV94ODYuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAt
TU1EIC1NRiAueGNfY3B1aWRfeDg2Lm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9M
QVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9T
T1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJv
dG90eXBlcyAtSS4NCiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4
Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19jcHVpZF94
ODYub3BpYyB4Y19jcHVpZF94ODYuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAtTU1EIC1N
RiAueGNfaHZtX2J1aWxkX3g4Ni5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFS
R0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09V
UkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3Rv
dHlwZXMNCiAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMv
Li4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfaHZtX2J1aWxk
X3g4Ni5vcGljIHhjX2h2bV9idWlsZF94ODYuYyANCmdjYyAgICAgLVdsLC1zb25hbWUgLVds
LGxpYnhlbmd1ZXN0LnNvLjQuMiAtc2hhcmVkIC1vIGxpYnhlbmd1ZXN0LnNvLjQuMi4wIHhn
X3ByaXZhdGUub3BpYyB4Y19zdXNwZW5kLm9waWMgeGNfZG9tYWluX3Jlc3RvcmUub3BpYyB4
Y19kb21haW5fc2F2ZS5vcGljIHhjX29mZmxpbmVfcGFnZS5vcGljIHhjX2NvbXANCnJlc3Np
b24ub3BpYyBsaWJlbGYtdG9vbHMub3BpYyBsaWJlbGYtbG9hZGVyLm9waWMgbGliZWxmLWRv
bWluZm8ub3BpYyBsaWJlbGYtcmVsb2NhdGUub3BpYyB4Y19kb21fY29yZS5vcGljIHhjX2Rv
bV9ib290Lm9waWMgeGNfZG9tX2VsZmxvYWRlci5vcGljIHhjX2RvbV9iemltYWdlbG9hZGVy
Lm9waWMgeGNfZG8NCm1fYmlubG9hZGVyLm9waWMgeGNfZG9tX2NvbXBhdF9saW51eC5vcGlj
IHhjX2RvbV94ODYub3BpYyB4Y19jcHVpZF94ODYub3BpYyB4Y19odm1fYnVpbGRfeDg2Lm9w
aWMgLURIQVZFX0JaTElCIC1sYnoyIC1seiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvbGlieGMNCi9saWJ4ZW5jdHJsLnNvICANCmxuIC1z
ZiBsaWJ4ZW5ndWVzdC5zby40LjIuMCBsaWJ4ZW5ndWVzdC5zby40LjINCmxuIC1zZiBsaWJ4
ZW5ndWVzdC5zby40LjIgbGlieGVuZ3Vlc3Quc28NCmdjYyAgLURQSUMgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAt
TU1EIC1NRiAueGVuY3RybF9vc2RlcF9FTk9TWVMub3BpYy5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlz
c2luZy1wcm90b3QNCnlwZXMgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhl
bmN0cmxfb3NkZXBfRU5PU1lTLm9waWMgeGVuY3RybF9vc2RlcF9FTk9TWVMuYyANCmdjYyAt
ZyAgICAgLXNoYXJlZCAtbyB4ZW5jdHJsX29zZGVwX0VOT1NZUy5zbyB4ZW5jdHJsX29zZGVw
X0VOT1NZUy5vcGljIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8u
Li8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIA0KbWFrZVs0XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4YycNCi9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9jcm9zcy1p
bnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9p
bnN0YWxsL3Vzci9saWINCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4
Yy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlDQovbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
bTA3NTUgLXAgbGlieGVuY3RybC5zby40LjIuMCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9saWINCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9saWJ4Yy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCBsaWJ4ZW5j
dHJsLmEgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGli
DQpsbiAtc2YgbGlieGVuY3RybC5zby40LjIuMCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9saWIvbGlieGVuY3RybC5zby40LjINCmxuIC1zZiBsaWJ4
ZW5jdHJsLnNvLjQuMiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9saWIvbGlieGVuY3RybC5zbw0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbmN0cmwu
aCB4ZW5jdHJsb3NkZXAuaCB4ZW50b29sbG9nLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZQ0KL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1IC1wIGxp
Ynhlbmd1ZXN0LnNvLjQuMi4wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2xpYg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhj
Ly4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIGxpYnhlbmd1ZXN0LmEgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliDQpsbiAtc2Yg
bGlieGVuZ3Vlc3Quc28uNC4yLjAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3Qv
aW5zdGFsbC91c3IvbGliL2xpYnhlbmd1ZXN0LnNvLjQuMg0KbG4gLXNmIGxpYnhlbmd1ZXN0
LnNvLjQuMiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9s
aWIvbGlieGVuZ3Vlc3Quc28NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW5ndWVzdC5oIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUNCm1h
a2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMnDQptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnDQptYWtlIC1DIGZsYXNrIGluc3Rh
bGwNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL2ZsYXNrJw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2snDQptYWtlIC1DIHV0aWxzIGlu
c3RhbGwNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzJw0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1G
IC5sb2FkcG9saWN5Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzICAtV2FsbCAtZyAtV2Vycm9yIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4uLy4uLy4u
L3Rvb2xzL2xpYg0KeGMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxh
c2svdXRpbHMvLi4vLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8gbG9hZHBvbGljeS5vIGxv
YWRwb2xpY3kuYyANCmdjYyAgICAgbG9hZHBvbGljeS5vICAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4vdG9vbHMvbGlieGMvbGlieGVu
Y3RybC5zbyAtbyBmbGFzay1sb2FkcG9saWN5DQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYg
LnNldGVuZm9yY2Uuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NP
VVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XYWxsIC1nIC1XZXJyb3IgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4v
dG9vbHMvbGliDQp4YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFz
ay91dGlscy8uLi8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyBzZXRlbmZvcmNlLm8gc2V0
ZW5mb3JjZS5jIA0KZ2NjICAgICBzZXRlbmZvcmNlLm8gIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5j
dHJsLnNvIC1vIGZsYXNrLXNldGVuZm9yY2UNCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAu
Z2V0ZW5mb3JjZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdhbGwgLWcgLVdlcnJvciAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90
b29scy9saWINCnhjIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNr
L3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIGdldGVuZm9yY2UubyBnZXRl
bmZvcmNlLmMgDQpnY2MgICAgIGdldGVuZm9yY2UubyAgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0
cmwuc28gLW8gZmxhc2stZ2V0ZW5mb3JjZQ0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5s
YWJlbC1wY2kuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJD
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XYWxsIC1nIC1XZXJyb3IgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4vdG9v
bHMvbGlieA0KYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91
dGlscy8uLi8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyBsYWJlbC1wY2kubyBsYWJlbC1w
Y2kuYyANCmdjYyAgICAgbGFiZWwtcGNpLm8gIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNv
IC1vIGZsYXNrLWxhYmVsLXBjaQ0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5nZXQtYm9v
bC5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAgLVdhbGwgLWcgLVdlcnJvciAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29scy9saWJ4
Yw0KIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4u
Ly4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIGdldC1ib29sLm8gZ2V0LWJvb2wuYyANCmdj
YyAgICAgZ2V0LWJvb2wubyAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zs
YXNrL3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gLW8gZmxhc2st
Z2V0LWJvb2wNCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAuc2V0LWJvb2wuby5kICAtRF9M
QVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgIC1XYWxsIC1nIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4vdG9vbHMvbGlieGMNCiAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29s
cy9pbmNsdWRlICAtYyAtbyBzZXQtYm9vbC5vIHNldC1ib29sLmMgDQpnY2MgICAgIHNldC1i
b29sLm8gIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8u
Li8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIC1vIGZsYXNrLXNldC1ib29sDQov
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4v
dG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2Jpbg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0w
NzU1IC1wIGZsYXNrLWxvYWRwb2xpY3kgZmxhc2stc2V0ZW5mb3JjZSBmbGFzay1nZXRlbmZv
cmNlIGZsYXNrLWxhYmVsLXBjaSBmbGFzay1nZXQtYm9vbCBmbGFzay1zZXQtYg0Kb29sIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NiaW4NCm1ha2Vb
NV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvZmxhc2svdXRpbHMnDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNrJw0KbWFrZVszXTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzaycNCm1ha2Vb
Ml06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMnDQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scycNCm1ha2UgLUMgeGVuc3RvcmUgaW5zdGFsbA0KbWFrZVszXTogRW50
ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVu
c3RvcmUnDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbnN0b3JlX2NsaWVudC5vLmQg
IC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkvDQptbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9pbmNsdWRlICAt
YyAtbyB4ZW5zdG9yZV9jbGllbnQubyB4ZW5zdG9yZV9jbGllbnQuYyANCmdjYyAgLURQSUMg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0wNClNfXyAtTU1EIC1NRiAueHMub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJy
b3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4u
Ly4uL3Rvb2xzL2xpYnhjIC1JL21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
eGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAtRFVTRV9QVEhSRUFEICAtZlBJQyAtYyAt
byB4cy5vcGljIHhzLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhzX2xp
Yi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkvDQpt
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9p
bmNsdWRlICAtZlBJQyAtYyAtbyB4c19saWIub3BpYyB4c19saWIuYyANCmdjYyAgICAgLVds
LC1zb25hbWUgLVdsLGxpYnhlbnN0b3JlLnNvLjMuMCAtc2hhcmVkIC1vIGxpYnhlbnN0b3Jl
LnNvLjMuMC4xIHhzLm9waWMgeHNfbGliLm9waWMgIC1scHRocmVhZCANCmxuIC1zZiBsaWJ4
ZW5zdG9yZS5zby4zLjAuMSBsaWJ4ZW5zdG9yZS5zby4zLjANCmxuIC1zZiBsaWJ4ZW5zdG9y
ZS5zby4zLjAgbGlieGVuc3RvcmUuc28NCmdjYyAgICAgeGVuc3RvcmVfY2xpZW50Lm8gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL3hl
bnN0b3JlL2xpYnhlbnN0b3JlLnNvICAtbyB4ZW5zdG9yZSANCmxuIC1mIHhlbnN0b3JlIHhl
bnN0b3JlLWV4aXN0cw0KbG4gLWYgeGVuc3RvcmUgeGVuc3RvcmUtbGlzdA0KbG4gLWYgeGVu
c3RvcmUgeGVuc3RvcmUtcmVhZA0KbG4gLWYgeGVuc3RvcmUgeGVuc3RvcmUtcm0NCmxuIC1m
IHhlbnN0b3JlIHhlbnN0b3JlLWNobW9kDQpsbiAtZiB4ZW5zdG9yZSB4ZW5zdG9yZS13cml0
ZQ0KbG4gLWYgeGVuc3RvcmUgeGVuc3RvcmUtbHMNCmxuIC1mIHhlbnN0b3JlIHhlbnN0b3Jl
LXdhdGNoDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbnN0b3JlX2NvbnRyb2wuby5k
ICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JDQovbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAg
LWMgLW8geGVuc3RvcmVfY29udHJvbC5vIHhlbnN0b3JlX2NvbnRyb2wuYyANCmdjYyAgICAg
eGVuc3RvcmVfY29udHJvbC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy94ZW5zdG9yZS9saWJ4ZW5zdG9yZS5zbyAgLW8geGVuc3Rv
cmUtY29udHJvbCANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueHMuby5kICAtRF9MQVJH
RUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veGUNCm4tdW5z
dGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geHMu
byB4cy5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54c19saWIuby5kICAtRF9MQVJH
RUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZQ0Kbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geHNf
bGliLm8geHNfbGliLmMgDQphciByY3MgbGlieGVuc3RvcmUuYSB4cy5vIHhzX2xpYi5vDQpn
Y2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhzX3RkYl9kdW1wLm8uZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzICAtV2Vycm9yIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIHhzX3RkYl9k
dW1wLm8geHNfdGRiX2R1bXAuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAudXRpbHMu
by5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94
ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVk
ZSAgLWMgLW8gdXRpbHMubyB1dGlscy5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC50
ZGIuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92
bS94ZW4veA0KZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5j
bHVkZSAgLWMgLW8gdGRiLm8gdGRiLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnRh
bGxvYy5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkvbW50
L3ZtL3hlDQpuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9p
bmNsdWRlICAtYyAtbyB0YWxsb2MubyB0YWxsb2MuYyANCmdjYyAgICAgeHNfdGRiX2R1bXAu
byB1dGlscy5vIHRkYi5vIHRhbGxvYy5vIC1vIHhzX3RkYl9kdW1wIA0KZ2NjICAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNf
XyAtTQ0KTUQgLU1GIC54ZW5zdG9yZWRfY29yZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0Ug
LURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdl
cnJvciAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUv
Li4vLi4vdG9vbHMvbGlieGMgLUkvbQ0KbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy94ZW5zdG9yZS8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyB4ZW5zdG9yZWRfY29yZS5v
IHhlbnN0b3JlZF9jb3JlLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbnN0b3Jl
ZF93YXRjaC5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkv
DQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29s
cy9pbmNsdWRlICAtYyAtbyB4ZW5zdG9yZWRfd2F0Y2gubyB4ZW5zdG9yZWRfd2F0Y2guYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuc3RvcmVkX2RvbWFpbi5vLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkNCi9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyB4
ZW5zdG9yZWRfZG9tYWluLm8geGVuc3RvcmVkX2RvbWFpbi5jIA0KZ2NjICAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAt
TQ0KTUQgLU1GIC54ZW5zdG9yZWRfdHJhbnNhY3Rpb24uby5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
IC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0
b3JlLy4uLy4uL3Rvb2xzL2xpYg0KeGMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geGVuc3RvcmVkX3Ry
YW5zYWN0aW9uLm8geGVuc3RvcmVkX3RyYW5zYWN0aW9uLmMgDQpnY2MgIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1N
DQpNRCAtTUYgLmhhc2h0YWJsZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4g
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9v
bHMvbGlieGMgLUkvbW50L3ZtDQoveGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9y
ZS8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyBoYXNodGFibGUubyBoYXNodGFibGUuYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuc3RvcmVkX2xpbnV4Lm8uZCAgLURfTEFS
R0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzICAtV2Vycm9yIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9saWJ4YyAtSS8NCm1udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIHhl
bnN0b3JlZF9saW51eC5vIHhlbnN0b3JlZF9saW51eC5jIA0KZ2NjICAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0K
TUQgLU1GIC54ZW5zdG9yZWRfcG9zaXguby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xB
UkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3Ig
LUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4u
L3Rvb2xzL2xpYnhjIC1JLw0KbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVu
c3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geGVuc3RvcmVkX3Bvc2l4Lm8geGVu
c3RvcmVkX3Bvc2l4LmMgDQpnY2MgICAgIHhlbnN0b3JlZF9jb3JlLm8geGVuc3RvcmVkX3dh
dGNoLm8geGVuc3RvcmVkX2RvbWFpbi5vIHhlbnN0b3JlZF90cmFuc2FjdGlvbi5vIHhzX2xp
Yi5vIHRhbGxvYy5vIHV0aWxzLm8gdGRiLm8gaGFzaHRhYmxlLm8geGVuc3RvcmVkX2xpbnV4
Lm8geGVuc3RvcmVkX3Bvc2l4Lm8gL21udC92bS94ZW4vDQp4ZW4tdW5zdGFibGUuaGcvdG9v
bHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAgLW8geGVuc3Rv
cmVkIA0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4u
L3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2Jpbg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1
IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NiaW4N
Ci9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUg
LXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVk
ZS94ZW5zdG9yZS1jb21wYXQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Zhci9ydW4veGVuc3RvcmVkDQov
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMv
Y3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC92YXIvbGliL3hlbnN0b3JlZA0KL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1
IC1wIHhlbnN0b3JlZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9zYmluDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUv
Li4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgeGVuc3RvcmUtY29udHJvbCAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCi9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9jcm9z
cy1pbnN0YWxsIC1tMDc1NSAtcCB4ZW5zdG9yZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCnNldCAtZSA7IGZvciBjIGluIHhlbnN0b3JlLWV4
aXN0cyB4ZW5zdG9yZS1saXN0IHhlbnN0b3JlLXJlYWQgeGVuc3RvcmUtcm0geGVuc3RvcmUt
Y2htb2QgeGVuc3RvcmUtd3JpdGUgeGVuc3RvcmUtbHMgeGVuc3RvcmUtd2F0Y2ggOyBkbyBc
DQogICAgICAgIGxuIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvdXNyL2Jpbi94ZW5zdG9yZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9p
bnN0YWxsL3Vzci9iaW4vJHtjfSA7IFwNCiBkb25lDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3
NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGli
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9v
bHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgbGlieGVuc3RvcmUuc28uMy4wLjEgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliDQpsbiAtc2YgbGli
eGVuc3RvcmUuc28uMy4wLjEgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC91c3IvbGliL2xpYnhlbnN0b3JlLnNvLjMuMA0KbG4gLXNmIGxpYnhlbnN0b3JlLnNv
LjMuMCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9saWIv
bGlieGVuc3RvcmUuc28NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5z
dG9yZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCBsaWJ4ZW5zdG9yZS5h
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYg0KL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbnN0b3JlLmggL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZQ0KL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0
IC1wIHhlbnN0b3JlX2xpYi5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2luY2x1ZGUNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCBjb21wYXQveHMu
aCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRl
L3hlbnN0b3JlLWNvbXBhdC94cy5oDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgY29tcGF0
L3hzX2xpYi5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNy
L2luY2x1ZGUveGVuc3RvcmUtY29tcGF0L3hzX2xpYi5oDQpsbiAtc2YgeGVuc3RvcmUtY29t
cGF0L3hzLmggIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNy
L2luY2x1ZGUveHMuaA0KbG4gLXNmIHhlbnN0b3JlLWNvbXBhdC94c19saWIuaCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hzX2xpYi5o
DQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL3hlbnN0b3JlJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVyaW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZSAtQyBtaXNj
IGluc3RhbGwNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MnDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhl
bnBlcmYuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVu
L3hlbi11DQpuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29s
cy94ZW5zdG9yZSAtSS9tbnQvdm0veGVuDQoveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2Mv
Li4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyB4ZW5wZXJmLm8geGVucGVyZi5jIA0KZ2NjICAg
ICAtbyB4ZW5wZXJmIHhlbnBlcmYubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIA0KZ2NjICAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNf
XyAtTQ0KTUQgLU1GIC54ZW5wbS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2xpYnhj
IC1JL21udC92bS94ZW4veGVuLXVucw0KdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29s
cy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9t
aXNjLy4uLy4uL3Rvb2xzL3hlbnN0b3JlIC1JL21udC92bS94ZW4veA0KZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMgIC1jIC1vIHhlbnBtLm8geGVucG0u
YyANCmdjYyAgICAgLW8geGVucG0geGVucG0ubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIA0KZ2NjIC1P
MSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5n
IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFm
dGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9U
T09MU19fIC1NTQ0KRCAtTUYgLnhlbi10bWVtLWxpc3QtcGFyc2UuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2Mv
Li4vLi4vdG9vbHMvbGlieGMgLUkvbW50L3ZtLw0KeGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUgLUkvbQ0KbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scyAgICAg
ICB4ZW4tdG1lbS1saXN0LXBhcnNlLmMgICAtbyB4ZW4tdG1lbS1saXN0LXBhcnNlDQpnY2Mg
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hF
Tl9UT09MU19fIC1NDQpNRCAtTUYgLmd0cmFjZXZpZXcuby5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
IC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8u
Li90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuL3hlDQpuLXVuc3RhYmxlLmhnL3Rvb2xzL21p
c2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0vDQp4ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyBn
dHJhY2V2aWV3Lm8gZ3RyYWNldmlldy5jIA0KZ2NjICAgICAtbyBndHJhY2V2aWV3IGd0cmFj
ZXZpZXcubyAtbG5jdXJzZXMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmd0cmFjZXN0
YXQuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuL3hl
DQpuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94
ZW5zdG9yZSAtSS9tbnQvdm0vDQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9t
aXNjLy4uLy4uL3Rvb2xzICAtYyAtbyBndHJhY2VzdGF0Lm8gZ3RyYWNlc3RhdC5jIA0KZ2Nj
ICAgICAtbyBndHJhY2VzdGF0IGd0cmFjZXN0YXQubyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGVubG9ja3Byb2Yuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklM
RTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAt
SS9tbnQvdm0veGVuL3gNCmVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlz
Yy8uLi8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0NCi94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyB4ZW5sb2NrcHJvZi5vIHhl
bmxvY2twcm9mLmMgDQpnY2MgICAgIC1vIHhlbmxvY2twcm9mIHhlbmxvY2twcm9mLm8gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvbGlieGMv
bGlieGVuY3RybC5zbyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVud2F0Y2hkb2dk
Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvbGlieGMgLUkvbW50L3ZtL3hlbi8NCnhl
bi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVu
c3RvcmUgLUkvbW50L3YNCm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlz
Yy8uLi8uLi90b29scyAgLWMgLW8geGVud2F0Y2hkb2dkLm8geGVud2F0Y2hkb2dkLmMgDQpn
Y2MgICAgIC1vIHhlbndhdGNoZG9nZCB4ZW53YXRjaGRvZ2QubyAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNv
IA0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1hFTl9UT09MU19fIC1NTQ0KRCAtTUYgLnhlbi1kZXRlY3QuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2Mv
Li4vLi4vdG9vbHMvbGlieGMgLUkvbW50L3ZtL3hlbi94ZW4tdQ0KbnN0YWJsZS5oZy90b29s
cy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUgLUkvbW50L3ZtL3hl
bg0KL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scyAgICAg
ICB4ZW4tZGV0ZWN0LmMgICAtbyB4ZW4tZGV0ZWN0DQpnY2MgIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAt
TUYgLnhlbi1odm1jdHguby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0
X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9t
bnQvdm0veGVuL3hlDQpuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rv
b2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8u
Li8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0vDQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyB4ZW4taHZtY3R4Lm8geGVuLWh2
bWN0eC5jIA0KZ2NjICAgICAtbyB4ZW4taHZtY3R4IHhlbi1odm1jdHgubyAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5j
dHJsLnNvIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54ZW4taHZtY3Jhc2guby5kICAt
RF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuLw0KeGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94ZW5zdG9yZSAt
SS9tbnQvdg0KbS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4u
L3Rvb2xzICAtYyAtbyB4ZW4taHZtY3Jhc2gubyB4ZW4taHZtY3Jhc2guYyANCmdjYyAgICAg
LW8geGVuLWh2bWNyYXNoIHhlbi1odm1jcmFzaC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gDQpnY2Mg
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hF
Tl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbi1sb3dtZW1kLm8uZCAgLURfTEFSR0VGSUxFX1NP
VVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
ICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4v
Li4vdG9vbHMvbGlieGMgLUkvbW50L3ZtL3hlbi94DQplbi11bnN0YWJsZS5oZy90b29scy9t
aXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUgLUkvbW50L3ZtDQoveGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scyAgLWMgLW8g
eGVuLWxvd21lbWQubyB4ZW4tbG93bWVtZC5jIA0KZ2NjICAgICAtbyB4ZW4tbG93bWVtZCB4
ZW4tbG93bWVtZC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4u
Ly4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUvbGlieGVuc3Rvcg0KZS5zbyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuLWhwdG9vbC5vLmQgIC1EX0xBUkdFRklM
RV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAgLVdlcnJvciAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNj
Ly4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veGUNCm4tdW5zdGFibGUuaGcvdG9v
bHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL3hlbnN0b3JlIC1JL21udC92bS8N
Cnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMgIC1j
IC1vIHhlbi1ocHRvb2wubyB4ZW4taHB0b29sLmMgDQpnY2MgICAgIC1vIHhlbi1ocHRvb2wg
eGVuLWhwdG9vbC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4u
Ly4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuZ3Vlc3Quc28gDQovbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94ZW5zdG9y
ZS9saWJ4ZW5zdG9yZS5zbyANCnNldCAtZTsgZm9yIGQgaW4gOyBkbyBtYWtlIC1DICRkOyBk
b25lDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9taXNjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NiaW4NCi9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3Rh
bGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvdXNyL2xpYi94ZW4vYmluDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bWlzYy8uLi8uLi90b29scy9weXRob24vaW5zdGFsbC13cmFwICIvdXNyL2Jpbi9weXRob24i
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNzU1IC1wIHhlbmNvbnMgeGVuLWRlDQp0ZWN0IC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2Jpbg0KL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvcHl0aG9uL2luc3RhbGwtd3Jh
cCAiL3Vzci9iaW4vcHl0aG9uIiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bWlzYy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDc1NSAtcCB4bSB4ZW4tYnVndG9v
bA0KIHhlbi1weXRob24tcGF0aCB4ZW5kIHhlbnBlcmYgeHN2aWV3IHhlbnBtIHhlbi10bWVt
LWxpc3QtcGFyc2UgZ3RyYWNldmlldyBndHJhY2VzdGF0IHhlbmxvY2twcm9mIHhlbndhdGNo
ZG9nZCB4ZW4tcmluZ3dhdGNoIHhlbi1odm1jdHggeGVuLWh2bWNyYXNoIHhlbi1sb3dtZW1k
IHhlbi1ocHRvb2wgL21udC92bQ0KL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9zYmluDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8u
Li90b29scy9weXRob24vaW5zdGFsbC13cmFwICIvdXNyL2Jpbi9weXRob24iIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3Rh
bGwgLW0wNzU1IC1wIHhlbnB2bmV0Ym9vdCAvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy9kaXN0L2luc3RhbGwvdXNyL2xpYi94ZW4vYmluDQpzZXQgLWU7IGZvciBkIGluIDsgZG8g
bWFrZSAtQyAkZCBpbnN0YWxsLXJlY3Vyc2U7IGRvbmUNCm1ha2VbM106IExlYXZpbmcgZGly
ZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYycNCm1ha2Vb
Ml06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMnDQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scycNCm1ha2UgLUMgZXhhbXBsZXMgaW5zdGFsbA0KbWFrZVszXTogRW50
ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZXhh
bXBsZXMnDQpbIC1kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwv
ZXRjL3hlbiBdIHx8IFwNCiAgICAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2V4YW1wbGVzLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hlbg0Kc2V0IC1l
OyBmb3IgaSBpbiBSRUFETUUgUkVBRE1FLmluY29tcGF0aWJpbGl0aWVzOyBcDQogICAgIGRv
IFsgLWUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVu
LyRpIF0gfHwgXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZXhh
bXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgJGkgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVuOyBcDQogZG9uZQ0KWyAt
ZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9zaGFyZS9k
b2MveGVuIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvZG9jL3hl
bg0KWyAtZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9z
aGFyZS9kb2MveGVuL2V4YW1wbGVzIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
ZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91
c3Ivc2hhcmUvZG9jL3hlbi9leGFtcGxlcw0Kc2V0IC1lOyBmb3IgaSBpbiB4bWV4YW1wbGUx
ICB4bWV4YW1wbGUyIHhtZXhhbXBsZTMgeG1leGFtcGxlLmh2bSB4bWV4YW1wbGUuaHZtLXN0
dWJkb20geG1leGFtcGxlLnB2LWdydWIgeG1leGFtcGxlLm5iZCB4bWV4YW1wbGUudnRpIHhs
ZXhhbXBsZS5odm0geGxleGFtcGxlLnB2bGludXg7IFwNCiAgICAgZG8gWyAtZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9zaGFyZS9kb2MveGVuL2V4
YW1wbGVzLyRpIF0gfHwgXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgJGkgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvZG9jL3hl
bi9leGFtcGxlczsgXA0KIGRvbmUNClsgLWQgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC9ldGMveGVuIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
ZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9l
dGMveGVuDQpbIC1kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwv
ZXRjL3hlbi9hdXRvIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUg
LXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVuL2F1
dG8NCnNldCAtZTsgZm9yIGkgaW4geGVuZC1jb25maWcuc3hwIHhtLWNvbmZpZy54bWwgeGVu
ZC1wY2ktcXVpcmtzLnN4cCB4ZW5kLXBjaS1wZXJtaXNzaXZlLnN4cCB4bC5jb25mIGNwdXBv
b2w7IFwNCiAgICAgZG8gWyAtZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9p
bnN0YWxsL2V0Yy94ZW4vJGkgXSB8fCBcDQogICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9leGFtcGxlcy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAt
cCAkaSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW47
IFwNCiBkb25lDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2V4YW1wbGVzJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3Rv
cnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFr
ZSAtQyBob3RwbHVnIGluc3RhbGwNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcnDQptYWtlWzRdOiBFbnRl
cmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3Rw
bHVnJw0KbWFrZSAtQyBjb21tb24gaW5zdGFsbA0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9jb21tb24n
DQpybSAtZiAiaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8gIlNCSU5ESVI9XCIvdXNyL3Ni
aW5cIiIgPj4iaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8gIkJJTkRJUj1cIi91c3IvYmlu
XCIiID4+ImhvdHBsdWdwYXRoLnNoIi50bXA7ICBlY2hvICJMSUJFWEVDPVwiL3Vzci9saWIv
eGVuL2JpblwiIiA+PiJob3RwDQpsdWdwYXRoLnNoIi50bXA7ICBlY2hvICJMSUJESVI9XCIv
dXNyL2xpYlwiIiA+PiJob3RwbHVncGF0aC5zaCIudG1wOyAgZWNobyAiU0hBUkVESVI9XCIv
dXNyL3NoYXJlXCIiID4+ImhvdHBsdWdwYXRoLnNoIi50bXA7ICBlY2hvICJQUklWQVRFX0JJ
TkRJUj1cIi91c3IvbGliL3hlbi9iaW5cIiIgPj4iaG90cGx1DQpncGF0aC5zaCIudG1wOyAg
ZWNobyAiWEVORklSTVdBUkVESVI9XCIvdXNyL2xpYi94ZW4vYm9vdFwiIiA+PiJob3RwbHVn
cGF0aC5zaCIudG1wOyAgZWNobyAiWEVOX0NPTkZJR19ESVI9XCIvZXRjL3hlblwiIiA+PiJo
b3RwbHVncGF0aC5zaCIudG1wOyAgZWNobyAiWEVOX1NDUklQVF9ESVI9XCIvZXRjL3hlbi9z
DQpjcmlwdHNcIiIgPj4iaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8gIlhFTl9MT0NLX0RJ
Uj1cIi92YXIvbG9ja1wiIiA+PiJob3RwbHVncGF0aC5zaCIudG1wOyAgZWNobyAiWEVOX1JV
Tl9ESVI9XCIvdmFyL3J1bi94ZW5cIiIgPj4iaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8g
IlhFTl9QQUdJTkdfRElSPVwiDQovdmFyL2xpYi94ZW4veGVucGFnaW5nXCIiID4+ImhvdHBs
dWdwYXRoLnNoIi50bXA7ICAgICAgIGlmICEgY21wIC1zICJob3RwbHVncGF0aC5zaCIudG1w
ICJob3RwbHVncGF0aC5zaCI7IHRoZW4gbXYgLWYgImhvdHBsdWdwYXRoLnNoIi50bXAgImhv
dHBsdWdwYXRoLnNoIjsgZWxzZSBybSAtZiAiaG90cGx1Z3BhDQp0aC5zaCIudG1wOyBmaQ0K
WyAtZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW4v
c2NyaXB0cyBdIHx8IFwNCiAgICAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2hvdHBsdWcvY29tbW9uLy4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0w
NzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hl
bi9zY3JpcHRzDQpzZXQgLWU7IGZvciBpIGluICJob3RwbHVncGF0aC5zaCI7IFwNCiAgICBk
byBcDQogICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvY29t
bW9uLy4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1IC1wICRpIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hlbi9zY3JpcHRzOyBcDQog
ZG9uZQ0Kc2V0IC1lOyBmb3IgaSBpbiA7IFwNCiAgICBkbyBcDQogICAgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvY29tbW9uLy4uLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNjQ0IC1wICRpIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9k
aXN0L2luc3RhbGwvZXRjL3hlbi9zY3JpcHRzOyBcDQogZG9uZQ0KbWFrZVs1XTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVn
L2NvbW1vbicNCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvaG90cGx1ZycNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9y
eSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcnDQptYWtlIC1D
IExpbnV4IGluc3RhbGwNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvTGludXgnDQpbIC1kIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL2luaXQuZCBdIHx8IC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rv
b2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oDQpnL2Rpc3QvaW5zdGFsbC9ldGMvaW5pdC5kDQpbIC1kIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL2RlZmF1bHQgXSB8fCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9MaW51eC8uLi8uLi8uLi90b29scy9jcm9z
cy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuDQpoZy9k
aXN0L2luc3RhbGwvZXRjL2RlZmF1bHQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1
IC1wIGluaXQuZC94ZW5kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvZXRjL2luaXQuZA0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBs
dWcvTGludXgvLi4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgaW5pdC5k
L3hlbmRvbWFpbnMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9l
dGMvaW5pdC5kDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9M
aW51eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDc1NSAtcCBpbml0LmQvc3lz
Y29uZmlnLnhlbmRvbWFpbnMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC9ldGMvZGVmYXVsdC94ZW5kb21haW5zDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvaG90cGx1Zy9MaW51eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1t
MDc1NSAtcCBpbml0LmQveGVuY29tbW9ucyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
ZGlzdC9pbnN0YWxsL2V0Yy9pbml0LmQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1
IC1wIGluaXQuZC9zeXNjb25maWcueGVuY29tbW9ucyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy9kZWZhdWx0L3hlbmNvbW1vbnMNCi9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNzU1IC1wIGluaXQuZC94ZW4td2F0Y2hkb2cgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMvaW5pdC5kDQpbIC1kIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hlbi9zY3JpcHRzIF0gfHwg
XA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9M
aW51eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW4vc2NyaXB0cw0Kc2V0
IC1lOyBmb3IgaSBpbiBuZXR3b3JrLWJyaWRnZSB2aWYtYnJpZGdlIG5ldHdvcmstcm91dGUg
dmlmLXJvdXRlIG5ldHdvcmstbmF0IHZpZi1uYXQgdmlmMiB2aWYtc2V0dXAgYmxvY2sgYmxv
Y2stZW5iZCBibG9jay1uYmQgYmxrdGFwIHZ0cG0gdnRwbS1kZWxldGUgeGVuLWhvdHBsdWct
Y2xlYW51cCBleHRlcg0KbmFsLWRldmljZS1taWdyYXRlIHZzY3NpOyBcDQogICAgIGRvIFwN
CiAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvTGludXgv
Li4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgJGkgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVuL3NjcmlwdHM7IFwNCiBkb25l
DQpzZXQgLWU7IGZvciBpIGluIHhlbi1zY3JpcHQtY29tbW9uLnNoIGxvY2tpbmcuc2ggbG9n
Z2luZy5zaCB4ZW4taG90cGx1Zy1jb21tb24uc2ggeGVuLW5ldHdvcmstY29tbW9uLnNoIHZp
Zi1jb21tb24uc2ggYmxvY2stY29tbW9uLnNoIHZ0cG0tY29tbW9uLnNoIHZ0cG0taG90cGx1
Zy1jb21tb24uc2ggdnRwbS1tDQppZ3JhdGlvbi5zaCB2dHBtLWltcGw7IFwNCiAgICAgZG8g
XA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9MaW51
eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCAkaSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW4vc2NyaXB0czsgXA0KIGRv
bmUNClsgLWQgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMv
aG90cGx1ZyBdIHx8IFwNCiAgICAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2hvdHBsdWcvTGludXgvLi4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3
NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMvaG90
cGx1Zw0Kc2V0IC1lOyBmb3IgaSBpbiB4ZW4tYmFja2VuZC5hZ2VudDsgXA0KICAgICBkbyBc
DQogICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4
Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1IC1wICRpIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL2hvdHBsdWc7IFwNCiBkb25lDQpb
IC1kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3VkZXYg
XSB8fCBcDQogICAgICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3Rw
bHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3VkZXYvcnVsZXMu
ZA0Kc2V0IC1lOyBmb3IgaSBpbiB4ZW4tYmFja2VuZC5ydWxlcyB4ZW5kLnJ1bGVzOyBcDQog
ICAgIGRvIFwNCiAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBs
dWcvTGludXgvLi4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgJGkgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMvdWRldi9ydWxlcy5k
OyBcDQogZG9uZQ0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4Jw0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnJw0K
bWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9ob3RwbHVnJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVyaW5nIGRpcmVjdG9y
eSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZSAtQyB4ZW50cmFj
ZSBpbnN0YWxsDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZScNCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1N
RiAueGVudHJhY2Uuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NP
VVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvbGlieGMgLUkv
bW50L3ZtL3hlbi8NCnhlbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29s
cy9pbmNsdWRlICAtYyAtbyB4ZW50cmFjZS5vIHhlbnRyYWNlLmMgDQpnY2MgICAgIC1vIHhl
bnRyYWNlIHhlbnRyYWNlLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hl
bnRyYWNlLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gDQpnY2MgIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19f
IC1NDQpNRCAtTUYgLnNldHNpemUuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdF
RklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMv
bGlieGMgLUkvbW50L3ZtL3hlbi94DQplbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8u
Li8uLi90b29scy9pbmNsdWRlICAtYyAtbyBzZXRzaXplLm8gc2V0c2l6ZS5jIA0KZ2NjICAg
ICAtbyB4ZW50cmFjZV9zZXRzaXplIHNldHNpemUubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuY3R4Lm8uZCAgLURfTEFSR0VGSUxFX1NP
VVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
ICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnRyYWNl
Ly4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veGUNCm4tdW5zdGFibGUuaGcvdG9v
bHMveGVudHJhY2UvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geGVuY3R4Lm8geGVuY3R4
LmMgDQpnY2MgICAgIC1vIHhlbmN0eCB4ZW5jdHgubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAN
Ci9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NClsgLXogInhlbmN0eCIgXSB8fCAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvY3Jvc3MtaW5z
dGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC91c3IvbGliL3hlbi9iaW4NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy94ZW50cmFjZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9zaGFyZS9tYW4vbWFu
MQ0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnRyYWNlLy4uLy4uL3Rv
b2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NoYXJlL21hbi9tYW44DQovbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
bTA3NTUgLXAgeGVudHJhY2UgeGVudHJhY2Vfc2V0c2l6ZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29scy9weXRob24vaW5zdGFsbC13cmFwICIv
dXNyL2Jpbi9weXRob24iIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW50
cmFjZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDc1NSAtcCB4ZW50cmENCmNlX2Zv
cm1hdCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4N
ClsgLXogInhlbmN0eCIgXSB8fCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
eGVudHJhY2UvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgeGVuY3R4IC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi94ZW4vYmlu
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9v
bHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgeGVudHJhY2VfZm9ybWF0LjEgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvbWFuL21hbjENCi9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29scy9j
cm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW50cmFjZS44IC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NoYXJlL21hbi9tYW44DQptYWtlWzNdOiBMZWF2
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnRy
YWNlJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZSAtQyB4Y3V0aWxzIGluc3RhbGwNCm1h
a2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL3hjdXRpbHMnDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX3Jlc3RvcmUu
by5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuDQov
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xp
YnhjIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4v
dG9vbHMvaW5jbHVkZSAtDQpjIC1vIHhjX3Jlc3RvcmUubyB4Y19yZXN0b3JlLmMgDQpnY2Mg
ICAgIHhjX3Jlc3RvcmUubyAtbyB4Y19yZXN0b3JlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvbGli
eGMvbGlieGVuZ3VlDQpzdC5zbyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfc2F2
ZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4v
eGUNCm4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9pbmNsdWRlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMv
bGlieGMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8u
Li90b29scy9pbmNsdWRlIC1JL20NCm50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
eGN1dGlscy8uLi8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLWMgLW8geGNfc2F2ZS5v
IHhjX3NhdmUuYyANCmdjYyAgICAgeGNfc2F2ZS5vIC1vIHhjX3NhdmUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVu
Y3RybC5zbyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8u
Li90b29scy9saWJ4Yy9saWJ4ZW5ndWVzdC5zbyANCi9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL3hlbnN0b3JlL2xpYnhlbnN0b3JlLnNv
IA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5yZWFkbm90ZXMuby5kICAtRF9MQVJHRUZJ
TEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1
dGlscy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuLw0KeGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvaW5jbHVkZSAt
Yw0KIC1vIHJlYWRub3Rlcy5vIHJlYWRub3Rlcy5jIA0KZ2NjICAgICByZWFkbm90ZXMubyAt
byByZWFkbm90ZXMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMv
Li4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5ndWVzdA0KLnNv
IA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5sc2V2dGNobi5vLmQgIC1EX0xBUkdFRklM
RV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAgLVdlcnJvciAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94Y3V0
aWxzLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veA0KZW4tdW5zdGFibGUuaGcv
dG9vbHMveGN1dGlscy8uLi8uLi90b29scy9pbmNsdWRlIC1jIC1vIGxzZXZ0Y2huLm8gbHNl
dnRjaG4uYyANCmdjYyAgICAgbHNldnRjaG4ubyAtbyBsc2V2dGNobiAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5j
dHJsLnNvIA0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4v
Li4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliL3hlbi9iaW4NCi9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwg
LW0wNzU1IC1wIHhjX3Jlc3RvcmUgeGNfc2F2ZSByZWFkbm90ZXMgbHNldnRjaG4gL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliL3hlbi9iaW4NCm1h
a2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMveGN1dGlscycNCm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnDQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2UgLUMgZmlybXdhcmUg
aW5zdGFsbA0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUnDQpHSVQ9Z2l0IC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS8uLi8uLi9zY3JpcHRzL2dpdC1jaGVja291dC5z
aCBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvc2VhYmlvcy5naXQgcmVsLTEuNi4zLjIgc2VhYmlv
cy1kaXINCkNsb25pbmcgaW50byAnc2VhYmlvcy1kaXItcmVtb3RlLnRtcCcuLi4NCnJlbW90
ZTogQ291bnRpbmcgb2JqZWN0czogNjQ5MCwgZG9uZS4NCnJlbW90ZTogQ29tcHJlc3Npbmcg
b2JqZWN0czogMTAwJSAoMTM5MS8xMzkxKSwgZG9uZS4NCnJlbW90ZTogVG90YWwgNjQ5MCAo
ZGVsdGEgNTE0NyksIHJldXNlZCA2NDIwIChkZWx0YSA1MDk1KSAgICAgDQpSZWNlaXZpbmcg
b2JqZWN0czogMTAwJSAoNjQ5MC82NDkwKSwgMS42MSBNaUIgfCA0MjAgS2lCL3MsIGRvbmUu
DQpSZXNvbHZpbmcgZGVsdGFzOiAxMDAlICg1MTQ3LzUxNDcpLCBkb25lLg0KU3dpdGNoZWQg
dG8gYSBuZXcgYnJhbmNoICdkdW1teScNCmNwIHNlYWJpb3MtY29uZmlnIHNlYWJpb3MtZGly
Ly5jb25maWc7DQptYWtlIFBZVEhPTj1weXRob24gc3ViZGlycy1hbGwNCm1ha2VbNF06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zp
cm13YXJlJw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUnDQptYWtlIC1DIHNlYWJpb3MtZGlyIGFsbA0K
ICBXb3JraW5nIGFyb3VuZCBub24tZnVuY3Rpb25hbCAtY29tYmluZQ0KbWFrZVs2XTogRW50
ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmly
bXdhcmUvc2VhYmlvcy1kaXItcmVtb3RlJw0KICBXb3JraW5nIGFyb3VuZCBub24tZnVuY3Rp
b25hbCAtY29tYmluZQ0KICBCdWlsZCBLY29uZmlnIGNvbmZpZyBmaWxlDQogIENvbXBpbGlu
ZyB3aG9sZSBwcm9ncmFtIG91dC9jY29kZS4xNi5zDQogIENvbXBpbGluZyB0byBhc3NlbWJs
ZXIgb3V0L2FzbS1vZmZzZXRzLnMNCiAgR2VuZXJhdGluZyBvZmZzZXQgZmlsZSBvdXQvYXNt
LW9mZnNldHMuaA0KICBDb21waWxpbmcgKDE2Yml0KSBvdXQvY29kZTE2Lm8NCiAgQ29tcGls
aW5nIHdob2xlIHByb2dyYW0gb3V0L2Njb2RlMzJmbGF0Lm8NCiAgQ29tcGlsaW5nIHdob2xl
IHByb2dyYW0gb3V0L2NvZGUzMnNlZy5vDQogIEJ1aWxkaW5nIGxkIHNjcmlwdHMgKHZlcnNp
b24gIjEuNi4zLjItMjAxMjA2MjdfMTAyNDE4LXZmYXJtIikNCkZpeGVkIHNwYWNlOiAweGUw
NWItMHgxMDAwMCAgdG90YWw6IDgxMDEgIHNsYWNrOiA3ICBQZXJjZW50IHNsYWNrOiAwLjEl
DQoxNmJpdCBzaXplOiAgICAgICAgICAgMzgxNDQNCjMyYml0IHNlZ21lbnRlZCBzaXplOiAx
NDE4DQozMmJpdCBmbGF0IHNpemU6ICAgICAgMTM1MTANCjMyYml0IGZsYXQgaW5pdCBzaXpl
OiA1MzU2OA0KICBMaW5raW5nIG91dC9yb20xNi5vDQogIFN0cmlwcGluZyBvdXQvcm9tMTYu
c3RyaXAubw0KICBMaW5raW5nIG91dC9yb20zMnNlZy5vDQogIFN0cmlwcGluZyBvdXQvcm9t
MzJzZWcuc3RyaXAubw0KICBMaW5raW5nIG91dC9yb20ubw0KICBQcmVwcGluZyBvdXQvYmlv
cy5iaW4NClRvdGFsIHNpemU6IDEwOTEwMCAgRml4ZWQ6IDUzMDcyICBGcmVlOiAyMTk3MiAo
dXNlZCA4My4yJSBvZiAxMjhLaUIgcm9tKQ0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9zZWFiaW9zLWRp
ci1yZW1vdGUnDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUnDQptYWtl
IC1DIHJvbWJpb3MgYWxsDQptYWtlWzZdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zJw0KbWFrZVs3XTog
RW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
ZmlybXdhcmUvcm9tYmlvcycNCm1ha2UgLUMgMzJiaXQgYWxsDQptYWtlWzhdOiBFbnRlcmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2Fy
ZS9yb21iaW9zLzMyYml0Jw0KbWFrZVs5XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvcm9tYmlvcy8zMmJpdCcNCm1h
a2UgLUMgdGNnYmlvcyBhbGwNCm1ha2VbMTBdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zLzMyYml0L3Rj
Z2Jpb3MnDQpnY2MgICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW0zMiAtbWFyY2g9
aTY4NiAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YDQpFTl9UT09MU19fIC1NTUQgLU1GIC50Y2diaW9z
Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1tbm8tdGxzLWRpcmVjdC1zZWctcmVmcyAgLVdlcnJv
ciAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLWZuDQpvLWJ1aWx0aW4g
LW1zb2Z0LWZsb2F0IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13
YXJlL3JvbWJpb3MvMzJiaXQvdGNnYmlvcy8uLi8uLi8uLi8uLi8uLi90b29scy9pbmNsdWRl
IC1JLi4gLUkuLi8uLiAgLWMgLW8gdGNnYmlvcy5vIHRjZ2Jpb3MuYyANCmdjYyAgIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTMyIC1tYXJjaD1pNjg2IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1gNCkVOX1RPT0xTX18gLU1NRCAtTUYgLnRwbV9kcml2ZXJzLm8uZCAgLURfTEFSR0VG
SUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1tbm8tdGxzLWRpcmVjdC1zZWctcmVmcyAgLVdlcnJvciAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMNCiAtZm5vLWJ1aWx0aW4gLW1zb2Z0LWZsb2F0IC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlL3JvbWJpb3MvMzJi
aXQvdGNnYmlvcy8uLi8uLi8uLi8uLi8uLi90b29scy9pbmNsdWRlIC1JLi4gLUkuLi8uLiAg
LWMgLW8gdHBtX2RyaXZlcnMubyB0cG1fZHJpdmVycy5jIA0KbGQgLW1lbGZfaTM4NiAtciB0
Y2diaW9zLm8gdHBtX2RyaXZlcnMubyAtbyB0Y2diaW9zZXh0Lm8NCm1ha2VbMTBdOiBMZWF2
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13
YXJlL3JvbWJpb3MvMzJiaXQvdGNnYmlvcycNCm1ha2VbOV06IExlYXZpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvcm9tYmlvcy8z
MmJpdCcNCm1ha2UgMzJiaXRiaW9zX2ZsYXQuaA0KbWFrZVs5XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvcm9tYmlv
cy8zMmJpdCcNCmdjYyAgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTMyIC1tYXJj
aD1pNjg2IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1gNCkVOX1RPT0xTX18gLU1NRCAtTUYgLjMyYml0
Ymlvcy5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbW5vLXRscy1kaXJlY3Qtc2VnLXJlZnMgIC1X
ZXJyb3IgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC0NCmZuby1idWls
dGluIC1tc29mdC1mbG9hdCAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9m
aXJtd2FyZS9yb21iaW9zLzMyYml0Ly4uLy4uLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkuLiAg
LWMgLW8gMzJiaXRiaW9zLm8gMzJiaXRiaW9zLmMgDQpnY2MgICAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW0zMiAtbWFyY2g9aTY4NiAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YDQpFTl9U
T09MU19fIC1NTUQgLU1GIC51dGlsLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJH
RUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1tbm8tdGxzLWRp
cmVjdC1zZWctcmVmcyAgLVdlcnJvciAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLWZuby1iDQp1aWx0aW4gLW1zb2Z0LWZsb2F0IC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlL3JvbWJpb3MvMzJiaXQvLi4vLi4vLi4vLi4vdG9v
bHMvaW5jbHVkZSAtSS4uICAtYyAtbyB1dGlsLm8gdXRpbC5jIA0KZ2NjICAgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tMzIgLW1hcmNoPWk2ODYgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9f
WA0KRU5fVE9PTFNfXyAtTU1EIC1NRiAucG1tLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1tbm8t
dGxzLWRpcmVjdC1zZWctcmVmcyAgLVdlcnJvciAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLWZuby1idQ0KaWx0aW4gLW1zb2Z0LWZsb2F0IC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlL3JvbWJpb3MvMzJiaXQvLi4vLi4vLi4v
Li4vdG9vbHMvaW5jbHVkZSAtSS4uICAtYyAtbyBwbW0ubyBwbW0uYyANCmxkIC1tZWxmX2kz
ODYgLXMgLXIgMzJiaXRiaW9zLm8gdGNnYmlvcy90Y2diaW9zZXh0Lm8gdXRpbC5vIHBtbS5v
IC1vIDMyYml0Ymlvc19hbGwubw0Kc2ggbWtoZXggaGlnaGJpb3NfYXJyYXkgMzJiaXRiaW9z
X2FsbC5vID4gMzJiaXRiaW9zX2ZsYXQuaA0KbWFrZVs5XTogTGVhdmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zLzMy
Yml0Jw0KbWFrZVs4XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zLzMyYml0Jw0KbWFrZVs3XTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2Fy
ZS9yb21iaW9zJw0KbWFrZSBCSU9TLWJvY2hzLWxhdGVzdA0KbWFrZVs3XTogRW50ZXJpbmcg
ZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUv
cm9tYmlvcycNCmdjYyAtbyBiaW9zc3VtcyBiaW9zc3Vtcy5jDQpnY2MgLURCWF9TTVBfUFJP
Q0VTU09SUz0xIC1FIC1QIHJvbWJpb3MuYyA+IF9yb21iaW9zXy5jDQpiY2MgLW8gcm9tYmlv
cy5zIC1DLWMgLURfX2k4Nl9fIC0wIC1TIF9yb21iaW9zXy5jDQpzZWQgLWUgJ3MvXlwudGV4
dC8vJyAtZSAncy9eXC5kYXRhLy8nIHJvbWJpb3MucyA+IF9yb21iaW9zXy5zDQphczg2IF9y
b21iaW9zXy5zIC1iIHRtcC5iaW4gLXUtIC13LSAtZyAtMCAtaiAtTyAtbCByb21iaW9zLnR4
dA0KcGVybCBtYWtlc3ltLnBlcmwgPCByb21iaW9zLnR4dCA+IHJvbWJpb3Muc3ltDQptdiB0
bXAuYmluIEJJT1MtYm9jaHMtbGF0ZXN0DQouL2Jpb3NzdW1zIEJJT1MtYm9jaHMtbGF0ZXN0
DQoNCg0KUENJLUJpb3MgaGVhZGVyIGF0OiAweEI1QjANCkN1cnJlbnQgY2hlY2tzdW06ICAg
ICAweDU4DQpDYWxjdWxhdGVkIGNoZWNrc3VtOiAgMHg1OCAgDQoNCg0KJFBJUiBoZWFkZXIg
YXQ6ICAgICAweEI5MDANCkN1cnJlbnQgY2hlY2tzdW06ICAgICAweDM3DQpDYWxjdWxhdGVk
IGNoZWNrc3VtOiAgMHgyNw0KICBTZXR0aW5nIGNoZWNrc3VtLg0KDQoNCkJpb3MgY2hlY2tz
dW0gYXQ6ICAgMHhGRkZGDQpDdXJyZW50IGNoZWNrc3VtOiAgICAgMHgwMA0KQ2FsY3VsYXRl
ZCBjaGVja3N1bTogIDB4QUEgIFNldHRpbmcgY2hlY2tzdW0uDQpybSAtZiBfcm9tYmlvc18u
cw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zJw0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3Rv
cnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9z
Jw0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9maXJtd2FyZScNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZSAtQyB2Z2Fi
aW9zIGFsbA0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvdmdhYmlvcycNCmdjYyAtbyBiaW9zc3VtcyBi
aW9zc3Vtcy5jDQpnY2MgLW8gdmJldGFibGVzLWdlbiB2YmV0YWJsZXMtZ2VuLmMNCi4vdmJl
dGFibGVzLWdlbiA+IHZiZXRhYmxlcy5oDQpnY2MgLUUgLVAgdmdhYmlvcy5jICAtRFZCRSAi
LURWR0FCSU9TX0RBVEU9XCJgZGF0ZSAnKyVkICViICVZJ2BcIiIgPiBfdmdhYmlvc18uYw0K
YmNjIC1vIHZnYWJpb3MucyAtQy1jIC1EX19pODZfXyAtUyAtMCBfdmdhYmlvc18uYw0Kc2Vk
IC1lICdzL15cLnRleHQvLycgLWUgJ3MvXlwuZGF0YS8vJyB2Z2FiaW9zLnMgPiBfdmdhYmlv
c18ucw0KYXM4NiBfdmdhYmlvc18ucyAtYiB2Z2FiaW9zLmJpbiAtdSAtdy0gLWcgLTAgLWog
LU8gLWwgdmdhYmlvcy50eHQNCnJtIC1mIF92Z2FiaW9zXy5zIF92Z2FiaW9zXy5jIHZnYWJp
b3Mucw0KY3AgdmdhYmlvcy5iaW4gVkdBQklPUy1sZ3BsLWxhdGVzdC5iaW4NCi4vYmlvc3N1
bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5iaW4NCg0KQmlvcyBjaGVja3N1bSBhdDogICAweDlE
RkYNCkN1cnJlbnQgY2hlY2tzdW06ICAgICAweDAwDQpDYWxjdWxhdGVkIGNoZWNrc3VtOiAg
MHg5NSAgU2V0dGluZyBjaGVja3N1bS4NCmxzIC1sIFZHQUJJT1MtbGdwbC1sYXRlc3QuYmlu
DQotcnctci0tci0tIDEgcm9vdCByb290IDQwNDQ4IGdpdSAyNyAxMDoyNCBWR0FCSU9TLWxn
cGwtbGF0ZXN0LmJpbg0KZ2NjIC1FIC1QIHZnYWJpb3MuYyAgLURWQkUgLURERUJVRyAiLURW
R0FCSU9TX0RBVEU9XCJgZGF0ZSAnKyVkICViICVZJ2BcIiIgPiBfdmdhYmlvcy1kZWJ1Z18u
Yw0KYmNjIC1vIHZnYWJpb3MtZGVidWcucyAtQy1jIC1EX19pODZfXyAtUyAtMCBfdmdhYmlv
cy1kZWJ1Z18uYw0Kc2VkIC1lICdzL15cLnRleHQvLycgLWUgJ3MvXlwuZGF0YS8vJyB2Z2Fi
aW9zLWRlYnVnLnMgPiBfdmdhYmlvcy1kZWJ1Z18ucw0KYXM4NiBfdmdhYmlvcy1kZWJ1Z18u
cyAtYiB2Z2FiaW9zLmRlYnVnLmJpbiAtdSAtdy0gLWcgLTAgLWogLU8gLWwgdmdhYmlvcy5k
ZWJ1Zy50eHQNCnJtIC1mIF92Z2FiaW9zLWRlYnVnXy5zIF92Z2FiaW9zLWRlYnVnXy5jIHZn
YWJpb3MtZGVidWcucw0KY3AgdmdhYmlvcy5kZWJ1Zy5iaW4gVkdBQklPUy1sZ3BsLWxhdGVz
dC5kZWJ1Zy5iaW4NCi4vYmlvc3N1bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5kZWJ1Zy5iaW4N
Cg0KQmlvcyBjaGVja3N1bSBhdDogICAweEExRkYNCkN1cnJlbnQgY2hlY2tzdW06ICAgICAw
eDAwDQpDYWxjdWxhdGVkIGNoZWNrc3VtOiAgMHhBRSAgU2V0dGluZyBjaGVja3N1bS4NCmxz
IC1sIFZHQUJJT1MtbGdwbC1sYXRlc3QuZGVidWcuYmluDQotcnctci0tci0tIDEgcm9vdCBy
b290IDQxNDcyIGdpdSAyNyAxMDoyNCBWR0FCSU9TLWxncGwtbGF0ZXN0LmRlYnVnLmJpbg0K
Z2NjIC1FIC1QIHZnYWJpb3MuYyAgLURDSVJSVVMgLURQQ0lCSU9TICItRFZHQUJJT1NfREFU
RT1cImBkYXRlICcrJWQgJWIgJVknYFwiIiA+IF92Z2FiaW9zLWNpcnJ1c18uYw0KYmNjIC1v
IHZnYWJpb3MtY2lycnVzLnMgLUMtYyAtRF9faTg2X18gLVMgLTAgX3ZnYWJpb3MtY2lycnVz
Xy5jDQpzZWQgLWUgJ3MvXlwudGV4dC8vJyAtZSAncy9eXC5kYXRhLy8nIHZnYWJpb3MtY2ly
cnVzLnMgPiBfdmdhYmlvcy1jaXJydXNfLnMNCmFzODYgX3ZnYWJpb3MtY2lycnVzXy5zIC1i
IHZnYWJpb3MtY2lycnVzLmJpbiAtdSAtdy0gLWcgLTAgLWogLU8gLWwgdmdhYmlvcy1jaXJy
dXMudHh0DQpybSAtZiBfdmdhYmlvcy1jaXJydXNfLnMgX3ZnYWJpb3MtY2lycnVzXy5jIHZn
YWJpb3MtY2lycnVzLnMNCmNwIHZnYWJpb3MtY2lycnVzLmJpbiBWR0FCSU9TLWxncGwtbGF0
ZXN0LmNpcnJ1cy5iaW4NCi4vYmlvc3N1bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5jaXJydXMu
YmluDQoNCkJpb3MgY2hlY2tzdW0gYXQ6ICAgMHg4QkZGDQpDdXJyZW50IGNoZWNrc3VtOiAg
ICAgMHgwMA0KQ2FsY3VsYXRlZCBjaGVja3N1bTogIDB4QUEgIFNldHRpbmcgY2hlY2tzdW0u
DQpscyAtbCBWR0FCSU9TLWxncGwtbGF0ZXN0LmNpcnJ1cy5iaW4NCi1ydy1yLS1yLS0gMSBy
b290IHJvb3QgMzU4NDAgZ2l1IDI3IDEwOjI0IFZHQUJJT1MtbGdwbC1sYXRlc3QuY2lycnVz
LmJpbg0KZ2NjIC1FIC1QIHZnYWJpb3MuYyAgLURDSVJSVVMgLURDSVJSVVNfREVCVUcgLURQ
Q0lCSU9TICItRFZHQUJJT1NfREFURT1cImBkYXRlICcrJWQgJWIgJVknYFwiIiA+IF92Z2Fi
aW9zLWNpcnJ1cy1kZWJ1Z18uYw0KYmNjIC1vIHZnYWJpb3MtY2lycnVzLWRlYnVnLnMgLUMt
YyAtRF9faTg2X18gLVMgLTAgX3ZnYWJpb3MtY2lycnVzLWRlYnVnXy5jDQpzZWQgLWUgJ3Mv
XlwudGV4dC8vJyAtZSAncy9eXC5kYXRhLy8nIHZnYWJpb3MtY2lycnVzLWRlYnVnLnMgPiBf
dmdhYmlvcy1jaXJydXMtZGVidWdfLnMNCmFzODYgX3ZnYWJpb3MtY2lycnVzLWRlYnVnXy5z
IC1iIHZnYWJpb3MtY2lycnVzLmRlYnVnLmJpbiAtdSAtdy0gLWcgLTAgLWogLU8gLWwgdmdh
Ymlvcy1jaXJydXMuZGVidWcudHh0DQpybSAtZiBfdmdhYmlvcy1jaXJydXMtZGVidWdfLnMg
X3ZnYWJpb3MtY2lycnVzLWRlYnVnXy5jIHZnYWJpb3MtY2lycnVzLWRlYnVnLnMNCmNwIHZn
YWJpb3MtY2lycnVzLmRlYnVnLmJpbiBWR0FCSU9TLWxncGwtbGF0ZXN0LmNpcnJ1cy5kZWJ1
Zy5iaW4NCi4vYmlvc3N1bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5jaXJydXMuZGVidWcuYmlu
DQoNCkJpb3MgY2hlY2tzdW0gYXQ6ICAgMHg4QkZGDQpDdXJyZW50IGNoZWNrc3VtOiAgICAg
MHgwMA0KQ2FsY3VsYXRlZCBjaGVja3N1bTogIDB4QzkgIFNldHRpbmcgY2hlY2tzdW0uDQps
cyAtbCBWR0FCSU9TLWxncGwtbGF0ZXN0LmNpcnJ1cy5kZWJ1Zy5iaW4NCi1ydy1yLS1yLS0g
MSByb290IHJvb3QgMzU4NDAgZ2l1IDI3IDEwOjI0IFZHQUJJT1MtbGdwbC1sYXRlc3QuY2ly
cnVzLmRlYnVnLmJpbg0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS92Z2FiaW9zJw0KbWFrZVs1XTogTGVh
dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJt
d2FyZScNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZSAtQyBldGhlcmJvb3QgYWxsDQptYWtl
WzZdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9maXJtd2FyZS9ldGhlcmJvb3QnDQppZiAhIHdnZXQgLU8gX2lweGUudGFyLmd6IGh0
dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzL2lweGUtZ2l0LTlhOTNk
YjNmMDk0NzQ4NGUzMGU3NTNiYmQ2MWExMGIxNzMzNmUyMGUudGFyLmd6OyB0aGVuIFwNCiAg
ICAgICAgZ2l0IGNsb25lIGdpdDovL2dpdC5pcHhlLm9yZy9pcHhlLmdpdCBpcHhlLmdpdDsg
XA0KICAgICAgICAoY2QgaXB4ZS5naXQgJiYgZ2l0IGFyY2hpdmUgLS1mb3JtYXQ9dGFyIC0t
cHJlZml4PWlweGUvIFwNCiAgICAgICAgOWE5M2RiM2YwOTQ3NDg0ZTMwZTc1M2JiZDYxYTEw
YjE3MzM2ZTIwZSB8IGd6aXAgPi4uL19pcHhlLnRhci5neik7IFwNCiAgICAgICAgcm0gLXJm
IGlweGUuZ2l0OyBcDQogZmkNCi0tMjAxMi0wNi0yNyAxMDoyNDoyMi0tICBodHRwOi8veGVu
Yml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcy9pcHhlLWdpdC05YTkzZGIzZjA5NDc0
ODRlMzBlNzUzYmJkNjFhMTBiMTczMzZlMjBlLnRhci5neg0KUmlzb2x1emlvbmUgZGkgeGVu
Yml0cy54ZW5zb3VyY2UuY29tICh4ZW5iaXRzLnhlbnNvdXJjZS5jb20pLi4uIDUwLjU3LjE3
MC4yNDINCkNvbm5lc3Npb25lIGEgeGVuYml0cy54ZW5zb3VyY2UuY29tICh4ZW5iaXRzLnhl
bnNvdXJjZS5jb20pfDUwLjU3LjE3MC4yNDJ8OjgwLi4uIGNvbm5lc3NvLg0KUmljaGllc3Rh
IEhUVFAgaW52aWF0YSwgaW4gYXR0ZXNhIGRpIHJpc3Bvc3RhLi4uIDIwMCBPSw0KTHVuZ2hl
enphOiAyODY3OTk5ICgyLDdNKSBbYXBwbGljYXRpb24veC1nemlwXQ0KU2FsdmF0YWdnaW8g
aW46ICJfaXB4ZS50YXIuZ3oiDQoNCjEwMCVbPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT5dIDIuODY3Ljk5OSAgIDYsNDhNL3MgICBpbiAwLDRzICAgIA0KDQoyMDEyLTA2LTI3IDEw
OjI0OjIyICg2LDQ4IE1CL3MpIC0gIl9pcHhlLnRhci5neiIgc2FsdmF0byBbMjg2Nzk5OS8y
ODY3OTk5XQ0KDQptdiBfaXB4ZS50YXIuZ3ogaXB4ZS50YXIuZ3oNCnJtIC1yZiBpcHhlDQpn
emlwIC1kYyBpcHhlLnRhci5neiB8IHRhciB4ZiAtDQpmb3IgaSBpbiAkKGNhdCBwYXRjaGVz
L3NlcmllcykgOyBkbyAgICAgICAgICAgICAgICAgXA0KICAgICBwYXRjaCAtZCBpcHhlIC1w
MSAtLXF1aWV0IDxwYXRjaGVzLyRpIHx8IGV4aXQgMSA7IFwNCiBkb25lDQpjYXQgQ29uZmln
ID4+aXB4ZS9zcmMvYXJjaC9pMzg2L01ha2VmaWxlDQptYWtlIC1DIGlweGUvc3JjIGJpbi9y
dGw4MTM5LnJvbQ0KbWFrZVs3XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L2lweGUvc3JjJw0Kcm0g
LWYgIGJpbi8qLiogIGJpbi9lcnJvcnMgICAgICAgYmluL05JQyAgICAgICAgIC4vdXRpbC9u
cnYyYiAuL3V0aWwvemJpbiAuL3V0aWwvZWxmMmVmaTMyIC4vdXRpbC9lbGYyZWZpNjQgLi91
dGlsL2VmaXJvbSAuL3V0aWwvaWNjZml4IC4vdXRpbC9laW5mbyBUQUdTIGJpbi9zeW10YWIN
CiAgW01FRElBUlVMRVNdIGV4ZQ0KICBbTUVESUFSVUxFU10gcmF3DQogIFtNRURJQVJVTEVT
XSBoZA0KICBbTUVESUFSVUxFU10gbmJpDQogIFtNRURJQVJVTEVTXSBkc2sNCiAgW01FRElB
UlVMRVNdIGxrcm4NCiAgW01FRElBUlVMRVNdIGtra3B4ZQ0KICBbTUVESUFSVUxFU10ga2tw
eGUNCiAgW01FRElBUlVMRVNdIGtweGUNCiAgW01FRElBUlVMRVNdIHB4ZQ0KICBbTUVESUFS
VUxFU10gbXJvbQ0KICBbTUVESUFSVUxFU10gcm9tDQogIFtSVUxFU10gYXJjaC9pMzg2L2Ry
aXZlcnMvbmV0L3VuZGlpc3IuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uvc3lz
bGludXgvY29tMzJfd3JhcHBlci5TDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9w
eGUvcHhlX2VudHJ5LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2U4
MjBtYW5nbGVyLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L3VzYmRpc2suUw0KICBb
UlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvdW5ucnYyYi5TDQogIFtSVUxFU10gYXJjaC9pMzg2
L3ByZWZpeC91bm5ydjJiMTYuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvdW5kaWxv
YWRlci5TDQogIFtSVUxFU10gYXJjaC9pMzg2L3ByZWZpeC9yb21wcmVmaXguUw0KICBbUlVM
RVNdIGFyY2gvaTM4Ni9wcmVmaXgvcHhlcHJlZml4LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYv
cHJlZml4L251bGxwcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvbmJpcHJl
Zml4LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L21yb21wcmVmaXguUw0KICBbUlVM
RVNdIGFyY2gvaTM4Ni9wcmVmaXgvbWJyLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4
L2xrcm5wcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvbGlicHJlZml4LlMN
CiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L2tweGVwcmVmaXguUw0KICBbUlVMRVNdIGFy
Y2gvaTM4Ni9wcmVmaXgva2tweGVwcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVm
aXgva2trcHhlcHJlZml4LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L2hkcHJlZml4
LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L2V4ZXByZWZpeC5TDQogIFtSVUxFU10g
YXJjaC9pMzg2L3ByZWZpeC9kc2twcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVm
aXgvYm9vdHBhcnQuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni90cmFuc2l0aW9ucy9saWJybS5T
DQogIFtSVUxFU10gYXJjaC9pMzg2L3RyYW5zaXRpb25zL2xpYnBtLlMNCiAgW1JVTEVTXSBh
cmNoL2kzODYvdHJhbnNpdGlvbnMvbGlia2lyLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvdHJh
bnNpdGlvbnMvbGliYTIwLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS92aXJ0YWRkci5T
DQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvc3RhY2suUw0KICBbUlVMRVNdIGFyY2gvaTM4
Ni9jb3JlL3N0YWNrMTYuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9jb3JlL3NldGptcC5TDQog
IFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvcGF0Y2hfY2YuUw0KICBbUlVMRVNdIGFyY2gvaTM4
Ni9jb3JlL2dkYmlkdC5TDQogIFtSVUxFU10gdGVzdHMvZ2Ric3R1Yl90ZXN0LlMNCiAgW1JV
TEVTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaXJvbS5jDQogIFtSVUxFU10gYXJjaC9p
Mzg2L2RyaXZlcnMvbmV0L3VuZGlwcmVsb2FkLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZHJp
dmVycy9uZXQvdW5kaW9ubHkuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9kcml2ZXJzL25ldC91
bmRpbmV0LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaWxvYWQuYw0K
ICBbUlVMRVNdIGFyY2gvaTM4Ni9kcml2ZXJzL25ldC91bmRpLmMNCiAgW1JVTEVTXSBhcmNo
L3g4Ni9wcmVmaXgvZWZpcHJlZml4LmMNCiAgW1JVTEVTXSBhcmNoL3g4Ni9wcmVmaXgvZWZp
ZHJ2cHJlZml4LmMNCiAgW1JVTEVTXSBhcmNoL3g4Ni9pbnRlcmZhY2UvZWZpL2VmaXg4Nl9u
YXAuYw0KICBbUlVMRVNdIGFyY2gveDg2L2NvcmUveDg2X3N0cmluZy5jDQogIFtSVUxFU10g
YXJjaC94ODYvY29yZS9wY2lkaXJlY3QuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9oY2kvY29t
bWFuZHMvcmVib290X2NtZC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2hjaS9jb21tYW5kcy9w
eGVfY21kLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2NvbWJv
b3RfcmVzb2x2LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2Nv
bWJvb3RfY2FsbC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9zeXNsaW51eC9j
b20zMl9jYWxsLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZXBhcmVudC9w
eGVwYXJlbnRfZGhjcC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGVwYXJl
bnQvcHhlcGFyZW50LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZS9weGVf
dW5kaS5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3VkcC5jDQog
IFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3RmdHAuYw0KICBbUlVMRVNd
IGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9wcmVib290LmMNCiAgW1JVTEVTXSBhcmNo
L2kzODYvaW50ZXJmYWNlL3B4ZS9weGVfbG9hZGVyLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYv
aW50ZXJmYWNlL3B4ZS9weGVfZmlsZS5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFj
ZS9weGUvcHhlX2V4aXRfaG9vay5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9w
eGUvcHhlX2NhbGwuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL3Bj
aWJpb3MuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL21lbXRvcF91
bWFsbG9jLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3BjYmlvcy9pbnQxMy5j
DQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvYmlvc190aW1lci5jDQog
IFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvYmlvc19zbWJpb3MuYw0KICBb
UlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL2Jpb3NfbmFwLmMNCiAgW1JVTEVT
XSBhcmNoL2kzODYvaW50ZXJmYWNlL3BjYmlvcy9iaW9zaW50LmMNCiAgW1JVTEVTXSBhcmNo
L2kzODYvaW1hZ2UvcHhlX2ltYWdlLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW1hZ2UvbmJp
LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW1hZ2UvbXVsdGlib290LmMNCiAgW1JVTEVTXSBh
cmNoL2kzODYvaW1hZ2UvZWxmYm9vdC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ltYWdlL2Nv
bWJvb3QuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbWFnZS9jb20zMi5jDQogIFtSVUxFU10g
YXJjaC9pMzg2L2ltYWdlL2J6aW1hZ2UuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbWFnZS9i
b290c2VjdG9yLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL3BucGJp
b3MuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvbWVtbWFwLmMNCiAg
W1JVTEVTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2hpZGVtZW0uYw0KICBbUlVMRVNd
IGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvZmFrZWU4MjAuYw0KICBbUlVMRVNdIGFyY2gv
aTM4Ni9maXJtd2FyZS9wY2Jpb3MvYmlvc19jb25zb2xlLmMNCiAgW1JVTEVTXSBhcmNoL2kz
ODYvZmlybXdhcmUvcGNiaW9zL2Jhc2VtZW0uYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni90cmFu
c2l0aW9ucy9saWJybV9tZ210LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS94ODZfaW8u
Yw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9jb3JlL3ZpZGVvX3N1YnIuYw0KICBbUlVMRVNdIGFy
Y2gvaTM4Ni9jb3JlL3RpbWVyMi5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvcnVudGlt
ZS5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvcmVsb2NhdGUuYw0KICBbUlVMRVNdIGFy
Y2gvaTM4Ni9jb3JlL3JkdHNjX3RpbWVyLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS9w
aWM4MjU5LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS9udWxsdHJhcC5jDQogIFtSVUxF
U10gYXJjaC9pMzg2L2NvcmUvZ2RibWFjaC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUv
ZHVtcHJlZ3MuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9jb3JlL2NwdS5jDQogIFtSVUxFU10g
YXJjaC9pMzg2L2NvcmUvYmFzZW1lbV9wYWNrZXQuYw0KICBbUlVMRVNdIGNvbmZpZy9jb25m
aWdfcm9tcHJlZml4LmMNCiAgW1JVTEVTXSBjb25maWcvY29uZmlnX25ldDgwMjExLmMNCiAg
W1JVTEVTXSBjb25maWcvY29uZmlnX2luZmluaWJhbmQuYw0KICBbUlVMRVNdIGNvbmZpZy9j
b25maWdfZmMuYw0KICBbUlVMRVNdIGNvbmZpZy9jb25maWdfZXRoZXJuZXQuYw0KICBbUlVM
RVNdIGNvbmZpZy9jb25maWcuYw0KICBbUlVMRVNdIHVzci9yb3V0ZS5jDQogIFtSVUxFU10g
dXNyL3B4ZW1lbnUuYw0KICBbUlVMRVNdIHVzci9wcm9tcHQuYw0KICBbUlVMRVNdIHVzci9s
b3Rlc3QuYw0KICBbUlVMRVNdIHVzci9pd21nbXQuYw0KICBbUlVMRVNdIHVzci9pbWdtZ210
LmMNCiAgW1JVTEVTXSB1c3IvaWZtZ210LmMNCiAgW1JVTEVTXSB1c3IvZmNtZ210LmMNCiAg
W1JVTEVTXSB1c3IvZGhjcG1nbXQuYw0KICBbUlVMRVNdIHVzci9hdXRvYm9vdC5jDQogIFtS
VUxFU10gaGNpL2tleW1hcC9rZXltYXBfd28uYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5
bWFwX3VzLmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF91ay5jDQogIFtSVUxFU10g
aGNpL2tleW1hcC9rZXltYXBfdWEuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX3Ro
LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9zci5jDQogIFtSVUxFU10gaGNpL2tl
eW1hcC9rZXltYXBfc2cuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX3J1LmMNCiAg
W1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9yby5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9r
ZXltYXBfcHQuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX3BsLmMNCiAgW1JVTEVT
XSBoY2kva2V5bWFwL2tleW1hcF9uby5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBf
bmwuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX210LmMNCiAgW1JVTEVTXSBoY2kv
a2V5bWFwL2tleW1hcF9tay5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfbHQuYw0K
ICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX2l0LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFw
L2tleW1hcF9pbC5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfaHUuYw0KICBbUlVM
RVNdIGhjaS9rZXltYXAva2V5bWFwX2dyLmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1h
cF9mci5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfZmkuYw0KICBbUlVMRVNdIGhj
aS9rZXltYXAva2V5bWFwX2V0LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9lcy5j
DQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfZGsuYw0KICBbUlVMRVNdIGhjaS9rZXlt
YXAva2V5bWFwX2RlLmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9jei5jDQogIFtS
VUxFU10gaGNpL2tleW1hcC9rZXltYXBfY2YuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5
bWFwX2J5LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9iZy5jDQogIFtSVUxFU10g
aGNpL2tleW1hcC9rZXltYXBfYXouYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX2Fs
LmMNCiAgW1JVTEVTXSBoY2kvbXVjdXJzZXMvd2lkZ2V0cy9lZGl0Ym94LmMNCiAgW1JVTEVT
XSBoY2kvbXVjdXJzZXMvd2luaW5pdC5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2VzL3dpbmRv
d3MuYw0KICBbUlVMRVNdIGhjaS9tdWN1cnNlcy93aW5hdHRycy5jDQogIFtSVUxFU10gaGNp
L211Y3Vyc2VzL3Nsay5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2VzL3ByaW50X25hZHYuYw0K
ICBbUlVMRVNdIGhjaS9tdWN1cnNlcy9wcmludC5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2Vz
L211Y3Vyc2VzLmMNCiAgW1JVTEVTXSBoY2kvbXVjdXJzZXMva2IuYw0KICBbUlVMRVNdIGhj
aS9tdWN1cnNlcy9lZGdpbmcuYw0KICBbUlVMRVNdIGhjaS9tdWN1cnNlcy9jb2xvdXIuYw0K
ICBbUlVMRVNdIGhjaS9tdWN1cnNlcy9jbGVhci5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2Vz
L2Fuc2lfc2NyZWVuLmMNCiAgW1JVTEVTXSBoY2kvbXVjdXJzZXMvYWxlcnQuYw0KICBbUlVM
RVNdIGhjaS90dWkvc2V0dGluZ3NfdWkuYw0KICBbUlVMRVNdIGhjaS90dWkvbG9naW5fdWku
Yw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy92bGFuX2NtZC5jDQogIFtSVUxFU10gaGNpL2Nv
bW1hbmRzL3RpbWVfY21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvc2FuYm9vdF9jbWQu
Yw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9yb3V0ZV9jbWQuYw0KICBbUlVMRVNdIGhjaS9j
b21tYW5kcy9udm9fY21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvbG90ZXN0X2NtZC5j
DQogIFtSVUxFU10gaGNpL2NvbW1hbmRzL2xvZ2luX2NtZC5jDQogIFtSVUxFU10gaGNpL2Nv
bW1hbmRzL2l3bWdtdF9jbWQuYw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9pbWFnZV9jbWQu
Yw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9pZm1nbXRfY21kLmMNCiAgW1JVTEVTXSBoY2kv
Y29tbWFuZHMvZ2Ric3R1Yl9jbWQuYw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9mY21nbXRf
Y21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvZGlnZXN0X2NtZC5jDQogIFtSVUxFU10g
aGNpL2NvbW1hbmRzL2RoY3BfY21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvY29uZmln
X2NtZC5jDQogIFtSVUxFU10gaGNpL2NvbW1hbmRzL2F1dG9ib290X2NtZC5jDQogIFtSVUxF
U10gaGNpL3dpcmVsZXNzX2Vycm9ycy5jDQogIFtSVUxFU10gaGNpL3N0cmVycm9yLmMNCiAg
W1JVTEVTXSBoY2kvc2hlbGwuYw0KICBbUlVMRVNdIGhjaS9yZWFkbGluZS5jDQogIFtSVUxF
U10gaGNpL2xpbnV4X2FyZ3MuYw0KICBbUlVMRVNdIGhjaS9lZGl0c3RyaW5nLmMNCiAgW1JV
TEVTXSBjcnlwdG8vYXh0bHMvc2hhMS5jDQogIFtSVUxFU10gY3J5cHRvL2F4dGxzL3JzYS5j
DQogIFtSVUxFU10gY3J5cHRvL2F4dGxzL2JpZ2ludC5jDQogIFtSVUxFU10gY3J5cHRvL2F4
dGxzL2Flcy5jDQogIFtSVUxFU10gY3J5cHRvL3g1MDkuYw0KICBbUlVMRVNdIGNyeXB0by9z
aGExZXh0cmEuYw0KICBbUlVMRVNdIGNyeXB0by9tZDUuYw0KICBbUlVMRVNdIGNyeXB0by9o
bWFjLmMNCiAgW1JVTEVTXSBjcnlwdG8vY3J5cHRvX251bGwuYw0KICBbUlVMRVNdIGNyeXB0
by9jcmMzMi5jDQogIFtSVUxFU10gY3J5cHRvL2NyYW5kb20uYw0KICBbUlVMRVNdIGNyeXB0
by9jaGFwLmMNCiAgW1JVTEVTXSBjcnlwdG8vY2JjLmMNCiAgW1JVTEVTXSBjcnlwdG8vYXh0
bHNfc2hhMS5jDQogIFtSVUxFU10gY3J5cHRvL2F4dGxzX2Flcy5jDQogIFtSVUxFU10gY3J5
cHRvL2FzbjEuYw0KICBbUlVMRVNdIGNyeXB0by9hcmM0LmMNCiAgW1JVTEVTXSBjcnlwdG8v
YWVzX3dyYXAuYw0KICBbUlVMRVNdIHRlc3RzL3VyaV90ZXN0LmMNCiAgW1JVTEVTXSB0ZXN0
cy91bWFsbG9jX3Rlc3QuYw0KICBbUlVMRVNdIHRlc3RzL3Rlc3QuYw0KICBbUlVMRVNdIHRl
c3RzL21lbWNweV90ZXN0LmMNCiAgW1JVTEVTXSB0ZXN0cy9saXN0X3Rlc3QuYw0KICBbUlVM
RVNdIHRlc3RzL2xpbmVidWZfdGVzdC5jDQogIFtSVUxFU10gdGVzdHMvYm9mbV90ZXN0LmMN
CiAgW1JVTEVTXSBpbnRlcmZhY2UvYm9mbS9ib2ZtLmMNCiAgW1JVTEVTXSBpbnRlcmZhY2Uv
c21iaW9zL3NtYmlvc19zZXR0aW5ncy5jDQogIFtSVUxFU10gaW50ZXJmYWNlL3NtYmlvcy9z
bWJpb3MuYw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX3VtYWxsb2MuYw0KICBbUlVM
RVNdIGludGVyZmFjZS9lZmkvZWZpX3VhY2Nlc3MuYw0KICBbUlVMRVNdIGludGVyZmFjZS9l
ZmkvZWZpX3RpbWVyLmMNCiAgW1JVTEVTXSBpbnRlcmZhY2UvZWZpL2VmaV9zdHJpbmdzLmMN
CiAgW1JVTEVTXSBpbnRlcmZhY2UvZWZpL2VmaV9zdHJlcnJvci5jDQogIFtSVUxFU10gaW50
ZXJmYWNlL2VmaS9lZmlfc25wLmMNCiAgW1JVTEVTXSBpbnRlcmZhY2UvZWZpL2VmaV9zbWJp
b3MuYw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX3BjaS5jDQogIFtSVUxFU10gaW50
ZXJmYWNlL2VmaS9lZmlfaW8uYw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX2luaXQu
Yw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX2RyaXZlci5jDQogIFtSVUxFU10gaW50
ZXJmYWNlL2VmaS9lZmlfY29uc29sZS5jDQogIFtSVUxFU10gaW50ZXJmYWNlL2VmaS9lZmlf
Ym9mbS5jDQogIFtSVUxFU10gZHJpdmVycy9pbmZpbmliYW5kL3FpYjczMjIuYw0KICBbUlVM
RVNdIGRyaXZlcnMvaW5maW5pYmFuZC9saW5kYV9mdy5jDQogIFtSVUxFU10gZHJpdmVycy9p
bmZpbmliYW5kL2xpbmRhLmMNCiAgW1JVTEVTXSBkcml2ZXJzL2luZmluaWJhbmQvaGVybW9u
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL2luZmluaWJhbmQvYXJiZWwuYw0KICBbUlVMRVNdIGRy
aXZlcnMvYml0YmFzaC9zcGlfYml0LmMNCiAgW1JVTEVTXSBkcml2ZXJzL2JpdGJhc2gvaTJj
X2JpdC5jDQogIFtSVUxFU10gZHJpdmVycy9iaXRiYXNoL2JpdGJhc2guYw0KICBbUlVMRVNd
IGRyaXZlcnMvbnZzL3RocmVld2lyZS5jDQogIFtSVUxFU10gZHJpdmVycy9udnMvc3BpLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL252cy9udnN2cGQuYw0KICBbUlVMRVNdIGRyaXZlcnMvbnZz
L252cy5jDQogIFtSVUxFU10gZHJpdmVycy9ibG9jay9zcnAuYw0KICBbUlVMRVNdIGRyaXZl
cnMvYmxvY2svc2NzaS5jDQogIFtSVUxFU10gZHJpdmVycy9ibG9jay9pYmZ0LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL2Jsb2NrL2F0YS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZWZpL3Nu
cG9ubHkuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2VmaS9zbnBuZXQuYw0KICBbUlVMRVNd
IGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV90cmFmZmljLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25l
dC92eGdlL3Z4Z2VfbWFpbi5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvdnhnZS92eGdlX2Nv
bmZpZy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvdnhnZS92eGdlLmMNCiAgW1JVTEVTXSBk
cml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfeG1pdC5jDQogIFtSVUxFU10gZHJpdmVycy9u
ZXQvYXRoL2F0aDlrL2F0aDlrX3JlY3YuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9h
dGg5ay9hdGg5a19tYWluLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRo
OWtfbWFjLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfaW5pdC5j
DQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2h3LmMNCiAgW1JVTEVT
XSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfZWVwcm9tX2RlZi5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbV85Mjg3LmMNCiAgW1JVTEVTXSBkcml2ZXJz
L25ldC9hdGgvYXRoOWsvYXRoOWtfZWVwcm9tXzRrLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25l
dC9hdGgvYXRoOWsvYXRoOWtfY29tbW9uLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgv
YXRoOWsvYXRoOWtfY2FsaWIuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9h
dGg5ay5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19w
aHkuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfbWFj
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAzX2h3LmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAzX2VlcHJvbS5j
DQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19jYWxpYi5j
DQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwMl9waHkuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDJfbWFjLmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX2h3LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX2NhbGliLmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI1MDA4X3BoeS5jDQogIFtSVUxF
U10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FuaS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDVrL2F0aDVrX3Jma2lsbC5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQv
YXRoL2F0aDVrL2F0aDVrX3Jlc2V0LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfcWN1LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtf
cGh5LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfcGN1LmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfaW5pdHZhbHMuYw0KICBbUlVM
RVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19ncGlvLmMNCiAgW1JVTEVTXSBkcml2
ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfZWVwcm9tLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25l
dC9hdGgvYXRoNWsvYXRoNWtfZG1hLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfZGVzYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVr
X2NhcHMuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1ay5jDQogIFtS
VUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX2F0dGFjaC5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvYXRoL2F0aF9yZWdkLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgv
YXRoX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGhfa2V5LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoX2h3LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9y
dGw4MTh4L3J0bDgxOHguYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4
NV9ydGw4MjI1LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ydGw4MTh4L3J0bDgxODUuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4MF9zYTI0MDAuYw0KICBbUlVM
RVNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4MF9tYXgyODIwLmMNCiAgW1JVTEVTXSBk
cml2ZXJzL25ldC9ydGw4MTh4L3J0bDgxODBfZ3JmNTEwMS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvcnRsODE4eC9ydGw4MTgwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9waGFudG9t
L3BoYW50b20uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2lnYnZmL2lnYnZmX3ZmLmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9pZ2J2Zi9pZ2J2Zl9tYnguYw0KICBbUlVMRVNdIGRyaXZl
cnMvbmV0L2lnYnZmL2lnYnZmX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2lnYi9p
Z2JfcGh5LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX252bS5jDQogIFtSVUxF
U10gZHJpdmVycy9uZXQvaWdiL2lnYl9tYW5hZ2UuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0
L2lnYi9pZ2JfbWFpbi5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvaWdiL2lnYl9tYWMuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L2lnYi9pZ2IuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0
L2lnYi9pZ2JfYXBpLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9pZ2IvaWdiXzgyNTc1LmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX3BoeS5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZV9udm0uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0
L2UxMDAwZS9lMTAwMGVfbWFuYWdlLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMGUv
ZTEwMDBlX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfbWFj
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX2ljaDhsYW4uYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGUuYw0KICBbUlVMRVNdIGRyaXZlcnMv
bmV0L2UxMDAwZS9lMTAwMGVfODI1NzEuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAw
ZS9lMTAwMGVfODAwMDNlczJsYW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwL2Ux
MDAwX3BoeS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfbnZtLmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF9tYW5hZ2UuYw0KICBbUlVMRVNdIGRy
aXZlcnMvbmV0L2UxMDAwL2UxMDAwX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2Ux
MDAwL2UxMDAwX21hYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDAuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwX2FwaS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvZTEwMDAvZTEwMDBfODI1NDMuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2Ux
MDAwL2UxMDAwXzgyNTQyLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84
MjU0MS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfODI1NDAuYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0L3dkLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC93ODljODQw
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC92aXJ0aW8tbmV0LmMNCiAgW1JVTEVTXSBkcml2
ZXJzL25ldC92aWEtdmVsb2NpdHkuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3ZpYS1yaGlu
ZS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvdHVsaXAuYw0KICBbUlVMRVNdIGRyaXZlcnMv
bmV0L3RsYW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3RnMy5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvc3VuZGFuY2UuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3NtYzkwMDAuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L3NreTIuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3Nr
Z2UuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3NpczkwMC5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvc2lzMTkwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ydGw4MTM5LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9yODE2OS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvcHJpc20y
X3BseC5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvcHJpc20yX3BjaS5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvcG5pYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvcGNuZXQzMi5jDQog
IFtSVUxFU10gZHJpdmVycy9uZXQvbnM4MzkwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9u
czgzODIwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9uZS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvbmUya19pc2EuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L25hdHNlbWkuYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0L215cmkxMGdlLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9t
dGQ4MHguYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2xlZ2FjeS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvam1lLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9pcG9pYi5jDQogIFtSVUxF
U10gZHJpdmVycy9uZXQvZm9yY2VkZXRoLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ldGhl
cmZhYnJpYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZXBpYzEwMC5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvZWVwcm8uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2VlcHJvMTAwLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9kbWZlLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9k
ZXBjYS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZGF2aWNvbS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvY3M4OXgwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ibngyLmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9iNDQuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0bDFlLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hbWQ4MTExZS5jDQogIFtSVUxFU10gZHJpdmVycy9u
ZXQvM2M5MHguYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0LzNjNXg5LmMNCiAgW1JVTEVTXSBk
cml2ZXJzL25ldC8zYzU5NS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvM2M1MjkuYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0LzNjNTE1LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC8zYzUw
OS1laXNhLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC8zYzUwOS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvM2M1MDMuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL3ZpcnRpby1yaW5nLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL2J1cy92aXJ0aW8tcGNpLmMNCiAgW1JVTEVTXSBkcml2ZXJz
L2J1cy9wY2l2cGQuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL3BjaWV4dHJhLmMNCiAgW1JV
TEVTXSBkcml2ZXJzL2J1cy9wY2kuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL3BjaWJhY2t1
cC5jDQogIFtSVUxFU10gZHJpdmVycy9idXMvbWNhLmMNCiAgW1JVTEVTXSBkcml2ZXJzL2J1
cy9pc2FwbnAuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL2lzYV9pZHMuYw0KICBbUlVMRVNd
IGRyaXZlcnMvYnVzL2lzYS5jDQogIFtSVUxFU10gZHJpdmVycy9idXMvZWlzYS5jDQogIFtS
VUxFU10gaW1hZ2Uvc2VnbWVudC5jDQogIFtSVUxFU10gaW1hZ2Uvc2NyaXB0LmMNCiAgW1JV
TEVTXSBpbWFnZS9lbWJlZGRlZC5jDQogIFtSVUxFU10gaW1hZ2UvZWxmLmMNCiAgW1JVTEVT
XSBpbWFnZS9lZmlfaW1hZ2UuYw0KICBbUlVMRVNdIG5ldC84MDIxMS93cGFfdGtpcC5jDQog
IFtSVUxFU10gbmV0LzgwMjExL3dwYV9wc2suYw0KICBbUlVMRVNdIG5ldC84MDIxMS93cGFf
Y2NtcC5jDQogIFtSVUxFU10gbmV0LzgwMjExL3dwYS5jDQogIFtSVUxFU10gbmV0LzgwMjEx
L3dlcC5jDQogIFtSVUxFU10gbmV0LzgwMjExL3NlYzgwMjExLmMNCiAgW1JVTEVTXSBuZXQv
ODAyMTEvcmM4MDIxMS5jDQogIFtSVUxFU10gbmV0LzgwMjExL25ldDgwMjExLmMNCiAgW1JV
TEVTXSBuZXQvaW5maW5pYmFuZC9pYl9zcnAuYw0KICBbUlVMRVNdIG5ldC9pbmZpbmliYW5k
L2liX3NtYy5jDQogIFtSVUxFU10gbmV0L2luZmluaWJhbmQvaWJfc21hLmMNCiAgW1JVTEVT
XSBuZXQvaW5maW5pYmFuZC9pYl9wYXRocmVjLmMNCiAgW1JVTEVTXSBuZXQvaW5maW5pYmFu
ZC9pYl9wYWNrZXQuYw0KICBbUlVMRVNdIG5ldC9pbmZpbmliYW5kL2liX21pLmMNCiAgW1JV
TEVTXSBuZXQvaW5maW5pYmFuZC9pYl9tY2FzdC5jDQogIFtSVUxFU10gbmV0L2luZmluaWJh
bmQvaWJfY21yYy5jDQogIFtSVUxFU10gbmV0L2luZmluaWJhbmQvaWJfY20uYw0KICBbUlVM
RVNdIG5ldC91ZHAvdGZ0cC5jDQogIFtSVUxFU10gbmV0L3VkcC9zeXNsb2cuYw0KICBbUlVM
RVNdIG5ldC91ZHAvc2xhbS5jDQogIFtSVUxFU10gbmV0L3VkcC9kbnMuYw0KICBbUlVMRVNd
IG5ldC91ZHAvZGhjcC5jDQogIFtSVUxFU10gbmV0L3RjcC9pc2NzaS5jDQogIFtSVUxFU10g
bmV0L3RjcC9odHRwcy5jDQogIFtSVUxFU10gbmV0L3RjcC9odHRwLmMNCiAgW1JVTEVTXSBu
ZXQvdGNwL2Z0cC5jDQogIFtSVUxFU10gbmV0L3ZsYW4uYw0KICBbUlVMRVNdIG5ldC91ZHAu
Yw0KICBbUlVMRVNdIG5ldC90bHMuYw0KICBbUlVMRVNdIG5ldC90Y3BpcC5jDQogIFtSVUxF
U10gbmV0L3RjcC5jDQogIFtSVUxFU10gbmV0L3JldHJ5LmMNCiAgW1JVTEVTXSBuZXQvcmFy
cC5jDQogIFtSVUxFU10gbmV0L251bGxuZXQuYw0KICBbUlVMRVNdIG5ldC9uZXRkZXZfc2V0
dGluZ3MuYw0KICBbUlVMRVNdIG5ldC9uZXRkZXZpY2UuYw0KICBbUlVMRVNdIG5ldC9uZHAu
Yw0KICBbUlVMRVNdIG5ldC9taWkuYw0KICBbUlVMRVNdIG5ldC9pcHY2LmMNCiAgW1JVTEVT
XSBuZXQvaXB2NC5jDQogIFtSVUxFU10gbmV0L2lvYnBhZC5jDQogIFtSVUxFU10gbmV0L2lu
ZmluaWJhbmQuYw0KICBbUlVMRVNdIG5ldC9pY21wdjYuYw0KICBbUlVMRVNdIG5ldC9pY21w
LmMNCiAgW1JVTEVTXSBuZXQvZmNwLmMNCiAgW1JVTEVTXSBuZXQvZmNvZS5jDQogIFtSVUxF
U10gbmV0L2ZjbnMuYw0KICBbUlVMRVNdIG5ldC9mY2Vscy5jDQogIFtSVUxFU10gbmV0L2Zj
LmMNCiAgW1JVTEVTXSBuZXQvZmFrZWRoY3AuYw0KICBbUlVMRVNdIG5ldC9ldGhfc2xvdy5j
DQogIFtSVUxFU10gbmV0L2V0aGVybmV0LmMNCiAgW1JVTEVTXSBuZXQvZWFwb2wuYw0KICBb
UlVMRVNdIG5ldC9kaGNwcGt0LmMNCiAgW1JVTEVTXSBuZXQvZGhjcG9wdHMuYw0KICBbUlVM
RVNdIG5ldC9jYWNoZWRoY3AuYw0KICBbUlVMRVNdIG5ldC9hcnAuYw0KICBbUlVMRVNdIG5l
dC9hb2UuYw0KICBbUlVMRVNdIGNvcmUveGZlci5jDQogIFtSVUxFU10gY29yZS92c3ByaW50
Zi5jDQogIFtSVUxFU10gY29yZS91dWlkLmMNCiAgW1JVTEVTXSBjb3JlL3VyaS5jDQogIFtS
VUxFU10gY29yZS90aW1lci5jDQogIFtSVUxFU10gY29yZS9zdHJ0b3VsbC5jDQogIFtSVUxF
U10gY29yZS9zdHJpbmdleHRyYS5jDQogIFtSVUxFU10gY29yZS9zdHJpbmcuYw0KICBbUlVM
RVNdIGNvcmUvc2V0dGluZ3MuYw0KICBbUlVMRVNdIGNvcmUvc2VyaWFsX2NvbnNvbGUuYw0K
ICBbUlVMRVNdIGNvcmUvc2VyaWFsLmMNCiAgW1JVTEVTXSBjb3JlL3Jlc29sdi5jDQogIFtS
VUxFU10gY29yZS9yZWZjbnQuYw0KICBbUlVMRVNdIGNvcmUvcmFuZG9tLmMNCiAgW1JVTEVT
XSBjb3JlL3Byb2Nlc3MuYw0KICBbUlVMRVNdIGNvcmUvcG9zaXhfaW8uYw0KICBbUlVMRVNd
IGNvcmUvcGNtY2lhLmMNCiAgW1JVTEVTXSBjb3JlL3BjX2tiZC5jDQogIFtSVUxFU10gY29y
ZS9wYXJzZW9wdC5jDQogIFtSVUxFU10gY29yZS9vcGVuLmMNCiAgW1JVTEVTXSBjb3JlL252
by5jDQogIFtSVUxFU10gY29yZS9udWxsX3NhbmJvb3QuYw0KICBbUlVMRVNdIGNvcmUvbnVs
bF9uYXAuYw0KICBbUlVMRVNdIGNvcmUvbW9ub2pvYi5jDQogIFtSVUxFU10gY29yZS9taXNj
LmMNCiAgW1JVTEVTXSBjb3JlL21hbGxvYy5jDQogIFtSVUxFU10gY29yZS9tYWluLmMNCiAg
W1JVTEVTXSBjb3JlL2xpbmVidWYuYw0KICBbUlVMRVNdIGNvcmUvam9iLmMNCiAgW1JVTEVT
XSBjb3JlL2lvYnVmLmMNCiAgW1JVTEVTXSBjb3JlL2ludGVyZmFjZS5jDQogIFtSVUxFU10g
Y29yZS9pbml0LmMNCiAgW1JVTEVTXSBjb3JlL2ltYWdlLmMNCiAgW1JVTEVTXSBjb3JlL2k4
MjM2NS5jDQogIFtSVUxFU10gY29yZS9ody5jDQogIFtSVUxFU10gY29yZS9nZXRvcHQuYw0K
ICBbUlVMRVNdIGNvcmUvZ2V0a2V5LmMNCiAgW1JVTEVTXSBjb3JlL2dkYnVkcC5jDQogIFtS
VUxFU10gY29yZS9nZGJzdHViLmMNCiAgW1JVTEVTXSBjb3JlL2dkYnNlcmlhbC5jDQogIFtS
VUxFU10gY29yZS9mbnJlYy5jDQogIFtSVUxFU10gY29yZS9leGVjLmMNCiAgW1JVTEVTXSBj
b3JlL2Vycm5vLmMNCiAgW1JVTEVTXSBjb3JlL2VkZC5jDQogIFtSVUxFU10gY29yZS9kb3du
bG9hZGVyLmMNCiAgW1JVTEVTXSBjb3JlL2RldmljZS5jDQogIFtSVUxFU10gY29yZS9kZWJ1
Z19tZDUuYw0KICBbUlVMRVNdIGNvcmUvZGVidWcuYw0KICBbUlVMRVNdIGNvcmUvY3d1cmku
Yw0KICBbUlVMRVNdIGNvcmUvY3R5cGUuYw0KICBbUlVMRVNdIGNvcmUvY3Bpby5jDQogIFtS
VUxFU10gY29yZS9jb25zb2xlLmMNCiAgW1JVTEVTXSBjb3JlL2J0ZXh0LmMNCiAgW1JVTEVT
XSBjb3JlL2Jsb2NrZGV2LmMNCiAgW1JVTEVTXSBjb3JlL2JpdG9wcy5jDQogIFtSVUxFU10g
Y29yZS9iaXRtYXAuYw0KICBbUlVMRVNdIGNvcmUvYmFzZW5hbWUuYw0KICBbUlVMRVNdIGNv
cmUvYmFzZTY0LmMNCiAgW1JVTEVTXSBjb3JlL2Jhc2UxNi5jDQogIFtSVUxFU10gY29yZS9h
c3NlcnQuYw0KICBbUlVMRVNdIGNvcmUvYXNwcmludGYuYw0KICBbUlVMRVNdIGNvcmUvYW5z
aWVzYy5jDQogIFtSVUxFU10gY29yZS9hY3BpLmMNCiAgW1JVTEVTXSBsaWJnY2MvX191bW9k
ZGkzLmMNCiAgW1JVTEVTXSBsaWJnY2MvX191ZGl2bW9kZGk0LmMNCiAgW1JVTEVTXSBsaWJn
Y2MvX191ZGl2ZGkzLmMNCiAgW1JVTEVTXSBsaWJnY2MvX19tb2RkaTMuYw0KICBbUlVMRVNd
IGxpYmdjYy9tZW1jcHkuYw0KICBbUlVMRVNdIGxpYmdjYy9pY2MuYw0KICBbUlVMRVNdIGxp
YmdjYy9fX2RpdmRpMy5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaWlz
ci5TDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2NvbTMyX3dyYXBw
ZXIuUw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX2VudHJ5LlMNCiAg
W0RFUFNdIGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvZTgyMG1hbmdsZXIuUw0KICBbREVQ
U10gYXJjaC9pMzg2L3ByZWZpeC91c2JkaXNrLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9wcmVm
aXgvdW5ucnYyYi5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L3VubnJ2MmIxNi5TDQog
IFtERVBTXSBhcmNoL2kzODYvcHJlZml4L3VuZGlsb2FkZXIuUw0KICBbREVQU10gYXJjaC9p
Mzg2L3ByZWZpeC9yb21wcmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L3ByZWZpeC9weGVw
cmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L3ByZWZpeC9udWxscHJlZml4LlMNCiAgW0RF
UFNdIGFyY2gvaTM4Ni9wcmVmaXgvbmJpcHJlZml4LlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9w
cmVmaXgvbXJvbXByZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L21ici5TDQog
IFtERVBTXSBhcmNoL2kzODYvcHJlZml4L2xrcm5wcmVmaXguUw0KICBbREVQU10gYXJjaC9p
Mzg2L3ByZWZpeC9saWJwcmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L3ByZWZpeC9rcHhl
cHJlZml4LlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9wcmVmaXgva2tweGVwcmVmaXguUw0KICBb
REVQU10gYXJjaC9pMzg2L3ByZWZpeC9ra2tweGVwcmVmaXguUw0KICBbREVQU10gYXJjaC9p
Mzg2L3ByZWZpeC9oZHByZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L2V4ZXBy
ZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L2Rza3ByZWZpeC5TDQogIFtERVBT
XSBhcmNoL2kzODYvcHJlZml4L2Jvb3RwYXJ0LlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni90cmFu
c2l0aW9ucy9saWJybS5TDQogIFtERVBTXSBhcmNoL2kzODYvdHJhbnNpdGlvbnMvbGlicG0u
Uw0KICBbREVQU10gYXJjaC9pMzg2L3RyYW5zaXRpb25zL2xpYmtpci5TDQogIFtERVBTXSBh
cmNoL2kzODYvdHJhbnNpdGlvbnMvbGliYTIwLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3Jl
L3ZpcnRhZGRyLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3N0YWNrLlMNCiAgW0RFUFNd
IGFyY2gvaTM4Ni9jb3JlL3N0YWNrMTYuUw0KICBbREVQU10gYXJjaC9pMzg2L2NvcmUvc2V0
am1wLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3BhdGNoX2NmLlMNCiAgW0RFUFNdIGFy
Y2gvaTM4Ni9jb3JlL2dkYmlkdC5TDQogIFtERVBTXSB0ZXN0cy9nZGJzdHViX3Rlc3QuUw0K
ICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGlyb20uYw0KICBbREVQU10gYXJj
aC9pMzg2L2RyaXZlcnMvbmV0L3VuZGlwcmVsb2FkLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9k
cml2ZXJzL25ldC91bmRpb25seS5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQv
dW5kaW5ldC5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaWxvYWQuYw0K
ICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGkuYw0KICBbREVQU10gYXJjaC94
ODYvcHJlZml4L2VmaXByZWZpeC5jDQogIFtERVBTXSBhcmNoL3g4Ni9wcmVmaXgvZWZpZHJ2
cHJlZml4LmMNCiAgW0RFUFNdIGFyY2gveDg2L2ludGVyZmFjZS9lZmkvZWZpeDg2X25hcC5j
DQogIFtERVBTXSBhcmNoL3g4Ni9jb3JlL3g4Nl9zdHJpbmcuYw0KICBbREVQU10gYXJjaC94
ODYvY29yZS9wY2lkaXJlY3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2hjaS9jb21tYW5kcy9y
ZWJvb3RfY21kLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9oY2kvY29tbWFuZHMvcHhlX2NtZC5j
DQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2NvbWJvb3RfcmVzb2x2
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uvc3lzbGludXgvY29tYm9vdF9jYWxs
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uvc3lzbGludXgvY29tMzJfY2FsbC5j
DQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZXBhcmVudC9weGVwYXJlbnRfZGhj
cC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZXBhcmVudC9weGVwYXJlbnQu
Yw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3VuZGkuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3VkcC5jDQogIFtERVBTXSBhcmNoL2kz
ODYvaW50ZXJmYWNlL3B4ZS9weGVfdGZ0cC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJm
YWNlL3B4ZS9weGVfcHJlYm9vdC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4
ZS9weGVfbG9hZGVyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9m
aWxlLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9leGl0X2hvb2su
Yw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX2NhbGwuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvcGNpYmlvcy5jDQogIFtERVBTXSBhcmNo
L2kzODYvaW50ZXJmYWNlL3BjYmlvcy9tZW10b3BfdW1hbGxvYy5jDQogIFtERVBTXSBhcmNo
L2kzODYvaW50ZXJmYWNlL3BjYmlvcy9pbnQxMy5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50
ZXJmYWNlL3BjYmlvcy9iaW9zX3RpbWVyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZh
Y2UvcGNiaW9zL2Jpb3Nfc21iaW9zLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uv
cGNiaW9zL2Jpb3NfbmFwLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9z
L2Jpb3NpbnQuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdlL3B4ZV9pbWFnZS5jDQogIFtE
RVBTXSBhcmNoL2kzODYvaW1hZ2UvbmJpLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9t
dWx0aWJvb3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdlL2VsZmJvb3QuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ltYWdlL2NvbWJvb3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdl
L2NvbTMyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9iemltYWdlLmMNCiAgW0RFUFNd
IGFyY2gvaTM4Ni9pbWFnZS9ib290c2VjdG9yLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9maXJt
d2FyZS9wY2Jpb3MvcG5wYmlvcy5jDQogIFtERVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNi
aW9zL21lbW1hcC5jDQogIFtERVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2hpZGVt
ZW0uYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3BjYmlvcy9mYWtlZTgyMC5jDQog
IFtERVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2Jpb3NfY29uc29sZS5jDQogIFtE
RVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2Jhc2VtZW0uYw0KICBbREVQU10gYXJj
aC9pMzg2L3RyYW5zaXRpb25zL2xpYnJtX21nbXQuYw0KICBbREVQU10gYXJjaC9pMzg2L2Nv
cmUveDg2X2lvLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3ZpZGVvX3N1YnIuYw0KICBb
REVQU10gYXJjaC9pMzg2L2NvcmUvdGltZXIyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3Jl
L3J1bnRpbWUuYw0KICBbREVQU10gYXJjaC9pMzg2L2NvcmUvcmVsb2NhdGUuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2NvcmUvcmR0c2NfdGltZXIuYw0KICBbREVQU10gYXJjaC9pMzg2L2Nv
cmUvcGljODI1OS5jDQogIFtERVBTXSBhcmNoL2kzODYvY29yZS9udWxsdHJhcC5jDQogIFtE
RVBTXSBhcmNoL2kzODYvY29yZS9nZGJtYWNoLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3Jl
L2R1bXByZWdzLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL2NwdS5jDQogIFtERVBTXSBh
cmNoL2kzODYvY29yZS9iYXNlbWVtX3BhY2tldC5jDQogIFtERVBTXSBjb25maWcvY29uZmln
X3JvbXByZWZpeC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX25ldDgwMjExLmMNCiAgW0RF
UFNdIGNvbmZpZy9jb25maWdfaW5maW5pYmFuZC5jDQogIFtERVBTXSBjb25maWcvY29uZmln
X2ZjLmMNCiAgW0RFUFNdIGNvbmZpZy9jb25maWdfZXRoZXJuZXQuYw0KICBbREVQU10gY29u
ZmlnL2NvbmZpZy5jDQogIFtERVBTXSB1c3Ivcm91dGUuYw0KICBbREVQU10gdXNyL3B4ZW1l
bnUuYw0KICBbREVQU10gdXNyL3Byb21wdC5jDQogIFtERVBTXSB1c3IvbG90ZXN0LmMNCiAg
W0RFUFNdIHVzci9pd21nbXQuYw0KICBbREVQU10gdXNyL2ltZ21nbXQuYw0KICBbREVQU10g
dXNyL2lmbWdtdC5jDQogIFtERVBTXSB1c3IvZmNtZ210LmMNCiAgW0RFUFNdIHVzci9kaGNw
bWdtdC5jDQogIFtERVBTXSB1c3IvYXV0b2Jvb3QuYw0KICBbREVQU10gaGNpL2tleW1hcC9r
ZXltYXBfd28uYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfdXMuYw0KICBbREVQU10g
aGNpL2tleW1hcC9rZXltYXBfdWsuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfdWEu
Yw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfdGguYw0KICBbREVQU10gaGNpL2tleW1h
cC9rZXltYXBfc3IuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfc2cuYw0KICBbREVQ
U10gaGNpL2tleW1hcC9rZXltYXBfcnUuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBf
cm8uYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfcHQuYw0KICBbREVQU10gaGNpL2tl
eW1hcC9rZXltYXBfcGwuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfbm8uYw0KICBb
REVQU10gaGNpL2tleW1hcC9rZXltYXBfbmwuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXlt
YXBfbXQuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfbWsuYw0KICBbREVQU10gaGNp
L2tleW1hcC9rZXltYXBfbHQuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfaXQuYw0K
ICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfaWwuYw0KICBbREVQU10gaGNpL2tleW1hcC9r
ZXltYXBfaHUuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZ3IuYw0KICBbREVQU10g
aGNpL2tleW1hcC9rZXltYXBfZnIuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZmku
Yw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZXQuYw0KICBbREVQU10gaGNpL2tleW1h
cC9rZXltYXBfZXMuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZGsuYw0KICBbREVQ
U10gaGNpL2tleW1hcC9rZXltYXBfZGUuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBf
Y3ouYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfY2YuYw0KICBbREVQU10gaGNpL2tl
eW1hcC9rZXltYXBfYnkuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfYmcuYw0KICBb
REVQU10gaGNpL2tleW1hcC9rZXltYXBfYXouYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXlt
YXBfYWwuYw0KICBbREVQU10gaGNpL211Y3Vyc2VzL3dpZGdldHMvZWRpdGJveC5jDQogIFtE
RVBTXSBoY2kvbXVjdXJzZXMvd2luaW5pdC5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvd2lu
ZG93cy5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvd2luYXR0cnMuYw0KICBbREVQU10gaGNp
L211Y3Vyc2VzL3Nsay5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvcHJpbnRfbmFkdi5jDQog
IFtERVBTXSBoY2kvbXVjdXJzZXMvcHJpbnQuYw0KICBbREVQU10gaGNpL211Y3Vyc2VzL211
Y3Vyc2VzLmMNCiAgW0RFUFNdIGhjaS9tdWN1cnNlcy9rYi5jDQogIFtERVBTXSBoY2kvbXVj
dXJzZXMvZWRnaW5nLmMNCiAgW0RFUFNdIGhjaS9tdWN1cnNlcy9jb2xvdXIuYw0KICBbREVQ
U10gaGNpL211Y3Vyc2VzL2NsZWFyLmMNCiAgW0RFUFNdIGhjaS9tdWN1cnNlcy9hbnNpX3Nj
cmVlbi5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvYWxlcnQuYw0KICBbREVQU10gaGNpL3R1
aS9zZXR0aW5nc191aS5jDQogIFtERVBTXSBoY2kvdHVpL2xvZ2luX3VpLmMNCiAgW0RFUFNd
IGhjaS9jb21tYW5kcy92bGFuX2NtZC5jDQogIFtERVBTXSBoY2kvY29tbWFuZHMvdGltZV9j
bWQuYw0KICBbREVQU10gaGNpL2NvbW1hbmRzL3NhbmJvb3RfY21kLmMNCiAgW0RFUFNdIGhj
aS9jb21tYW5kcy9yb3V0ZV9jbWQuYw0KICBbREVQU10gaGNpL2NvbW1hbmRzL252b19jbWQu
Yw0KICBbREVQU10gaGNpL2NvbW1hbmRzL2xvdGVzdF9jbWQuYw0KICBbREVQU10gaGNpL2Nv
bW1hbmRzL2xvZ2luX2NtZC5jDQogIFtERVBTXSBoY2kvY29tbWFuZHMvaXdtZ210X2NtZC5j
DQogIFtERVBTXSBoY2kvY29tbWFuZHMvaW1hZ2VfY21kLmMNCiAgW0RFUFNdIGhjaS9jb21t
YW5kcy9pZm1nbXRfY21kLmMNCiAgW0RFUFNdIGhjaS9jb21tYW5kcy9nZGJzdHViX2NtZC5j
DQogIFtERVBTXSBoY2kvY29tbWFuZHMvZmNtZ210X2NtZC5jDQogIFtERVBTXSBoY2kvY29t
bWFuZHMvZGlnZXN0X2NtZC5jDQogIFtERVBTXSBoY2kvY29tbWFuZHMvZGhjcF9jbWQuYw0K
ICBbREVQU10gaGNpL2NvbW1hbmRzL2NvbmZpZ19jbWQuYw0KICBbREVQU10gaGNpL2NvbW1h
bmRzL2F1dG9ib290X2NtZC5jDQogIFtERVBTXSBoY2kvd2lyZWxlc3NfZXJyb3JzLmMNCiAg
W0RFUFNdIGhjaS9zdHJlcnJvci5jDQogIFtERVBTXSBoY2kvc2hlbGwuYw0KICBbREVQU10g
aGNpL3JlYWRsaW5lLmMNCiAgW0RFUFNdIGhjaS9saW51eF9hcmdzLmMNCiAgW0RFUFNdIGhj
aS9lZGl0c3RyaW5nLmMNCiAgW0RFUFNdIGNyeXB0by9heHRscy9zaGExLmMNCiAgW0RFUFNd
IGNyeXB0by9heHRscy9yc2EuYw0KICBbREVQU10gY3J5cHRvL2F4dGxzL2JpZ2ludC5jDQog
IFtERVBTXSBjcnlwdG8vYXh0bHMvYWVzLmMNCiAgW0RFUFNdIGNyeXB0by94NTA5LmMNCiAg
W0RFUFNdIGNyeXB0by9zaGExZXh0cmEuYw0KICBbREVQU10gY3J5cHRvL21kNS5jDQogIFtE
RVBTXSBjcnlwdG8vaG1hYy5jDQogIFtERVBTXSBjcnlwdG8vY3J5cHRvX251bGwuYw0KICBb
REVQU10gY3J5cHRvL2NyYzMyLmMNCiAgW0RFUFNdIGNyeXB0by9jcmFuZG9tLmMNCiAgW0RF
UFNdIGNyeXB0by9jaGFwLmMNCiAgW0RFUFNdIGNyeXB0by9jYmMuYw0KICBbREVQU10gY3J5
cHRvL2F4dGxzX3NoYTEuYw0KICBbREVQU10gY3J5cHRvL2F4dGxzX2Flcy5jDQogIFtERVBT
XSBjcnlwdG8vYXNuMS5jDQogIFtERVBTXSBjcnlwdG8vYXJjNC5jDQogIFtERVBTXSBjcnlw
dG8vYWVzX3dyYXAuYw0KICBbREVQU10gdGVzdHMvdXJpX3Rlc3QuYw0KICBbREVQU10gdGVz
dHMvdW1hbGxvY190ZXN0LmMNCiAgW0RFUFNdIHRlc3RzL3Rlc3QuYw0KICBbREVQU10gdGVz
dHMvbWVtY3B5X3Rlc3QuYw0KICBbREVQU10gdGVzdHMvbGlzdF90ZXN0LmMNCiAgW0RFUFNd
IHRlc3RzL2xpbmVidWZfdGVzdC5jDQogIFtERVBTXSB0ZXN0cy9ib2ZtX3Rlc3QuYw0KICBb
REVQU10gaW50ZXJmYWNlL2JvZm0vYm9mbS5jDQogIFtERVBTXSBpbnRlcmZhY2Uvc21iaW9z
L3NtYmlvc19zZXR0aW5ncy5jDQogIFtERVBTXSBpbnRlcmZhY2Uvc21iaW9zL3NtYmlvcy5j
DQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV91bWFsbG9jLmMNCiAgW0RFUFNdIGludGVy
ZmFjZS9lZmkvZWZpX3VhY2Nlc3MuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfdGlt
ZXIuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfc3RyaW5ncy5jDQogIFtERVBTXSBp
bnRlcmZhY2UvZWZpL2VmaV9zdHJlcnJvci5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2Vm
aV9zbnAuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfc21iaW9zLmMNCiAgW0RFUFNd
IGludGVyZmFjZS9lZmkvZWZpX3BjaS5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9p
by5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9pbml0LmMNCiAgW0RFUFNdIGludGVy
ZmFjZS9lZmkvZWZpX2RyaXZlci5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9jb25z
b2xlLmMNCiAgW0RFUFNdIGludGVyZmFjZS9lZmkvZWZpX2JvZm0uYw0KICBbREVQU10gZHJp
dmVycy9pbmZpbmliYW5kL3FpYjczMjIuYw0KICBbREVQU10gZHJpdmVycy9pbmZpbmliYW5k
L2xpbmRhX2Z3LmMNCiAgW0RFUFNdIGRyaXZlcnMvaW5maW5pYmFuZC9saW5kYS5jDQogIFtE
RVBTXSBkcml2ZXJzL2luZmluaWJhbmQvaGVybW9uLmMNCiAgW0RFUFNdIGRyaXZlcnMvaW5m
aW5pYmFuZC9hcmJlbC5jDQogIFtERVBTXSBkcml2ZXJzL2JpdGJhc2gvc3BpX2JpdC5jDQog
IFtERVBTXSBkcml2ZXJzL2JpdGJhc2gvaTJjX2JpdC5jDQogIFtERVBTXSBkcml2ZXJzL2Jp
dGJhc2gvYml0YmFzaC5jDQogIFtERVBTXSBkcml2ZXJzL252cy90aHJlZXdpcmUuYw0KICBb
REVQU10gZHJpdmVycy9udnMvc3BpLmMNCiAgW0RFUFNdIGRyaXZlcnMvbnZzL252c3ZwZC5j
DQogIFtERVBTXSBkcml2ZXJzL252cy9udnMuYw0KICBbREVQU10gZHJpdmVycy9ibG9jay9z
cnAuYw0KICBbREVQU10gZHJpdmVycy9ibG9jay9zY3NpLmMNCiAgW0RFUFNdIGRyaXZlcnMv
YmxvY2svaWJmdC5jDQogIFtERVBTXSBkcml2ZXJzL2Jsb2NrL2F0YS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9lZmkvc25wb25seS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lZmkvc25w
bmV0LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV90cmFmZmljLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV9tYWluLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L3Z4Z2UvdnhnZV9jb25maWcuYw0KICBbREVQU10gZHJpdmVycy9uZXQvdnhnZS92eGdlLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a194bWl0LmMNCiAgW0RFUFNd
IGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19yZWN2LmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L2F0aC9hdGg5ay9hdGg5a19tYWluLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9h
dGg5ay9hdGg5a19tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlr
X2luaXQuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2h3LmMNCiAg
W0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb21fZGVmLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb20uYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbV85Mjg3LmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb21fNGsuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvYXRoL2F0aDlrL2F0aDlrX2NvbW1vbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgv
YXRoOWsvYXRoOWtfY2FsaWIuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0
aDlrLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfcGh5
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfbWFjLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfaHcuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19lZXByb20uYw0KICBb
REVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19jYWxpYi5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX3BoeS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX21hYy5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX2h3LmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDJfY2FsaWIuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyNTAwOF9waHkuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvYXRoL2F0aDlrL2F0aDlrX2FuaS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfcmZraWxsLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1
a19yZXNldC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfcWN1LmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19waHkuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX3BjdS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9hdGgvYXRoNWsvYXRoNWtfaW5pdHZhbHMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRo
L2F0aDVrL2F0aDVrX2dwaW8uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0
aDVrX2VlcHJvbS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfZG1h
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19kZXNjLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19jYXBzLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg1ay9hdGg1ay5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfYXR0YWNoLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGhfcmVnZC5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoX21haW4uYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvYXRoL2F0aF9rZXkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aF9ody5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9ydGw4MTh4L3J0bDgxOHguYw0KICBbREVQU10gZHJp
dmVycy9uZXQvcnRsODE4eC9ydGw4MTg1X3J0bDgyMjUuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvcnRsODE4eC9ydGw4MTg1LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRs
ODE4MF9zYTI0MDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTgwX21h
eDI4MjAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTgwX2dyZjUxMDEu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTgwLmMNCiAgW0RFUFNdIGRy
aXZlcnMvbmV0L3BoYW50b20vcGhhbnRvbS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2J2
Zi9pZ2J2Zl92Zi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2J2Zi9pZ2J2Zl9tYnguYw0K
ICBbREVQU10gZHJpdmVycy9uZXQvaWdidmYvaWdidmZfbWFpbi5jDQogIFtERVBTXSBkcml2
ZXJzL25ldC9pZ2IvaWdiX3BoeS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX252
bS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX21hbmFnZS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9pZ2IvaWdiX21haW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdiL2ln
Yl9tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdiL2lnYi5jDQogIFtERVBTXSBkcml2
ZXJzL25ldC9pZ2IvaWdiX2FwaS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiXzgy
NTc1LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfcGh5LmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfbnZtLmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L2UxMDAwZS9lMTAwMGVfbWFuYWdlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAw
ZS9lMTAwMGVfbWFpbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX21h
Yy5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX2ljaDhsYW4uYw0KICBb
REVQU10gZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9lMTAwMGUvZTEwMDBlXzgyNTcxLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9l
MTAwMGVfODAwMDNlczJsYW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBf
cGh5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwX252bS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF9tYW5hZ2UuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvZTEwMDAvZTEwMDBfbWFpbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAw
MF9tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDAuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfYXBpLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2Ux
MDAwL2UxMDAwXzgyNTQzLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwXzgy
NTQyLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwXzgyNTQxLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwXzgyNTQwLmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L3dkLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3c4OWM4NDAuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvdmlydGlvLW5ldC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC92aWEtdmVsb2Np
dHkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvdmlhLXJoaW5lLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L3R1bGlwLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3RsYW4uYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvdGczLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3N1bmRhbmNlLmMNCiAg
W0RFUFNdIGRyaXZlcnMvbmV0L3NtYzkwMDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvc2t5
Mi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9za2dlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L3NpczkwMC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9zaXMxOTAuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvcnRsODEzOS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9yODE2OS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9wcmlzbTJfcGx4LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3By
aXNtMl9wY2kuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcG5pYy5jDQogIFtERVBTXSBkcml2
ZXJzL25ldC9wY25ldDMyLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L25zODM5MC5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9uczgzODIwLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L25lLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L25lMmtfaXNhLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L25hdHNlbWkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvbXlyaTEwZ2UuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvbXRkODB4LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2xlZ2FjeS5jDQog
IFtERVBTXSBkcml2ZXJzL25ldC9qbWUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaXBvaWIu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvZm9yY2VkZXRoLmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L2V0aGVyZmFicmljLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2VwaWMxMDAuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvZWVwcm8uYw0KICBbREVQU10gZHJpdmVycy9uZXQvZWVwcm8x
MDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZG1mZS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9kZXBjYS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9kYXZpY29tLmMNCiAgW0RFUFNdIGRy
aXZlcnMvbmV0L2NzODl4MC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9ibngyLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2I0NC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGwxZS5jDQog
IFtERVBTXSBkcml2ZXJzL25ldC9hbWQ4MTExZS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8z
YzkweC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzV4OS5jDQogIFtERVBTXSBkcml2ZXJz
L25ldC8zYzU5NS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzUyOS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC8zYzUxNS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzUwOS1laXNhLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0LzNjNTA5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0LzNj
NTAzLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL3ZpcnRpby1yaW5nLmMNCiAgW0RFUFNdIGRy
aXZlcnMvYnVzL3ZpcnRpby1wY2kuYw0KICBbREVQU10gZHJpdmVycy9idXMvcGNpdnBkLmMN
CiAgW0RFUFNdIGRyaXZlcnMvYnVzL3BjaWV4dHJhLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVz
L3BjaS5jDQogIFtERVBTXSBkcml2ZXJzL2J1cy9wY2liYWNrdXAuYw0KICBbREVQU10gZHJp
dmVycy9idXMvbWNhLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL2lzYXBucC5jDQogIFtERVBT
XSBkcml2ZXJzL2J1cy9pc2FfaWRzLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL2lzYS5jDQog
IFtERVBTXSBkcml2ZXJzL2J1cy9laXNhLmMNCiAgW0RFUFNdIGltYWdlL3NlZ21lbnQuYw0K
ICBbREVQU10gaW1hZ2Uvc2NyaXB0LmMNCiAgW0RFUFNdIGltYWdlL2VtYmVkZGVkLmMNCiAg
W0RFUFNdIGltYWdlL2VsZi5jDQogIFtERVBTXSBpbWFnZS9lZmlfaW1hZ2UuYw0KICBbREVQ
U10gbmV0LzgwMjExL3dwYV90a2lwLmMNCiAgW0RFUFNdIG5ldC84MDIxMS93cGFfcHNrLmMN
CiAgW0RFUFNdIG5ldC84MDIxMS93cGFfY2NtcC5jDQogIFtERVBTXSBuZXQvODAyMTEvd3Bh
LmMNCiAgW0RFUFNdIG5ldC84MDIxMS93ZXAuYw0KICBbREVQU10gbmV0LzgwMjExL3NlYzgw
MjExLmMNCiAgW0RFUFNdIG5ldC84MDIxMS9yYzgwMjExLmMNCiAgW0RFUFNdIG5ldC84MDIx
MS9uZXQ4MDIxMS5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9pYl9zcnAuYw0KICBbREVQ
U10gbmV0L2luZmluaWJhbmQvaWJfc21jLmMNCiAgW0RFUFNdIG5ldC9pbmZpbmliYW5kL2li
X3NtYS5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9pYl9wYXRocmVjLmMNCiAgW0RFUFNd
IG5ldC9pbmZpbmliYW5kL2liX3BhY2tldC5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9p
Yl9taS5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9pYl9tY2FzdC5jDQogIFtERVBTXSBu
ZXQvaW5maW5pYmFuZC9pYl9jbXJjLmMNCiAgW0RFUFNdIG5ldC9pbmZpbmliYW5kL2liX2Nt
LmMNCiAgW0RFUFNdIG5ldC91ZHAvdGZ0cC5jDQogIFtERVBTXSBuZXQvdWRwL3N5c2xvZy5j
DQogIFtERVBTXSBuZXQvdWRwL3NsYW0uYw0KICBbREVQU10gbmV0L3VkcC9kbnMuYw0KICBb
REVQU10gbmV0L3VkcC9kaGNwLmMNCiAgW0RFUFNdIG5ldC90Y3AvaXNjc2kuYw0KICBbREVQ
U10gbmV0L3RjcC9odHRwcy5jDQogIFtERVBTXSBuZXQvdGNwL2h0dHAuYw0KICBbREVQU10g
bmV0L3RjcC9mdHAuYw0KICBbREVQU10gbmV0L3ZsYW4uYw0KICBbREVQU10gbmV0L3VkcC5j
DQogIFtERVBTXSBuZXQvdGxzLmMNCiAgW0RFUFNdIG5ldC90Y3BpcC5jDQogIFtERVBTXSBu
ZXQvdGNwLmMNCiAgW0RFUFNdIG5ldC9yZXRyeS5jDQogIFtERVBTXSBuZXQvcmFycC5jDQog
IFtERVBTXSBuZXQvbnVsbG5ldC5jDQogIFtERVBTXSBuZXQvbmV0ZGV2X3NldHRpbmdzLmMN
CiAgW0RFUFNdIG5ldC9uZXRkZXZpY2UuYw0KICBbREVQU10gbmV0L25kcC5jDQogIFtERVBT
XSBuZXQvbWlpLmMNCiAgW0RFUFNdIG5ldC9pcHY2LmMNCiAgW0RFUFNdIG5ldC9pcHY0LmMN
CiAgW0RFUFNdIG5ldC9pb2JwYWQuYw0KICBbREVQU10gbmV0L2luZmluaWJhbmQuYw0KICBb
REVQU10gbmV0L2ljbXB2Ni5jDQogIFtERVBTXSBuZXQvaWNtcC5jDQogIFtERVBTXSBuZXQv
ZmNwLmMNCiAgW0RFUFNdIG5ldC9mY29lLmMNCiAgW0RFUFNdIG5ldC9mY25zLmMNCiAgW0RF
UFNdIG5ldC9mY2Vscy5jDQogIFtERVBTXSBuZXQvZmMuYw0KICBbREVQU10gbmV0L2Zha2Vk
aGNwLmMNCiAgW0RFUFNdIG5ldC9ldGhfc2xvdy5jDQogIFtERVBTXSBuZXQvZXRoZXJuZXQu
Yw0KICBbREVQU10gbmV0L2VhcG9sLmMNCiAgW0RFUFNdIG5ldC9kaGNwcGt0LmMNCiAgW0RF
UFNdIG5ldC9kaGNwb3B0cy5jDQogIFtERVBTXSBuZXQvY2FjaGVkaGNwLmMNCiAgW0RFUFNd
IG5ldC9hcnAuYw0KICBbREVQU10gbmV0L2FvZS5jDQogIFtERVBTXSBjb3JlL3hmZXIuYw0K
ICBbREVQU10gY29yZS92c3ByaW50Zi5jDQogIFtERVBTXSBjb3JlL3V1aWQuYw0KICBbREVQ
U10gY29yZS91cmkuYw0KICBbREVQU10gY29yZS90aW1lci5jDQogIFtERVBTXSBjb3JlL3N0
cnRvdWxsLmMNCiAgW0RFUFNdIGNvcmUvc3RyaW5nZXh0cmEuYw0KICBbREVQU10gY29yZS9z
dHJpbmcuYw0KICBbREVQU10gY29yZS9zZXR0aW5ncy5jDQogIFtERVBTXSBjb3JlL3Nlcmlh
bF9jb25zb2xlLmMNCiAgW0RFUFNdIGNvcmUvc2VyaWFsLmMNCiAgW0RFUFNdIGNvcmUvcmVz
b2x2LmMNCiAgW0RFUFNdIGNvcmUvcmVmY250LmMNCiAgW0RFUFNdIGNvcmUvcmFuZG9tLmMN
CiAgW0RFUFNdIGNvcmUvcHJvY2Vzcy5jDQogIFtERVBTXSBjb3JlL3Bvc2l4X2lvLmMNCiAg
W0RFUFNdIGNvcmUvcGNtY2lhLmMNCiAgW0RFUFNdIGNvcmUvcGNfa2JkLmMNCiAgW0RFUFNd
IGNvcmUvcGFyc2VvcHQuYw0KICBbREVQU10gY29yZS9vcGVuLmMNCiAgW0RFUFNdIGNvcmUv
bnZvLmMNCiAgW0RFUFNdIGNvcmUvbnVsbF9zYW5ib290LmMNCiAgW0RFUFNdIGNvcmUvbnVs
bF9uYXAuYw0KICBbREVQU10gY29yZS9tb25vam9iLmMNCiAgW0RFUFNdIGNvcmUvbWlzYy5j
DQogIFtERVBTXSBjb3JlL21hbGxvYy5jDQogIFtERVBTXSBjb3JlL21haW4uYw0KICBbREVQ
U10gY29yZS9saW5lYnVmLmMNCiAgW0RFUFNdIGNvcmUvam9iLmMNCiAgW0RFUFNdIGNvcmUv
aW9idWYuYw0KICBbREVQU10gY29yZS9pbnRlcmZhY2UuYw0KICBbREVQU10gY29yZS9pbml0
LmMNCiAgW0RFUFNdIGNvcmUvaW1hZ2UuYw0KICBbREVQU10gY29yZS9pODIzNjUuYw0KICBb
REVQU10gY29yZS9ody5jDQogIFtERVBTXSBjb3JlL2dldG9wdC5jDQogIFtERVBTXSBjb3Jl
L2dldGtleS5jDQogIFtERVBTXSBjb3JlL2dkYnVkcC5jDQogIFtERVBTXSBjb3JlL2dkYnN0
dWIuYw0KICBbREVQU10gY29yZS9nZGJzZXJpYWwuYw0KICBbREVQU10gY29yZS9mbnJlYy5j
DQogIFtERVBTXSBjb3JlL2V4ZWMuYw0KICBbREVQU10gY29yZS9lcnJuby5jDQogIFtERVBT
XSBjb3JlL2VkZC5jDQogIFtERVBTXSBjb3JlL2Rvd25sb2FkZXIuYw0KICBbREVQU10gY29y
ZS9kZXZpY2UuYw0KICBbREVQU10gY29yZS9kZWJ1Z19tZDUuYw0KICBbREVQU10gY29yZS9k
ZWJ1Zy5jDQogIFtERVBTXSBjb3JlL2N3dXJpLmMNCiAgW0RFUFNdIGNvcmUvY3R5cGUuYw0K
ICBbREVQU10gY29yZS9jcGlvLmMNCiAgW0RFUFNdIGNvcmUvY29uc29sZS5jDQogIFtERVBT
XSBjb3JlL2J0ZXh0LmMNCiAgW0RFUFNdIGNvcmUvYmxvY2tkZXYuYw0KICBbREVQU10gY29y
ZS9iaXRvcHMuYw0KICBbREVQU10gY29yZS9iaXRtYXAuYw0KICBbREVQU10gY29yZS9iYXNl
bmFtZS5jDQogIFtERVBTXSBjb3JlL2Jhc2U2NC5jDQogIFtERVBTXSBjb3JlL2Jhc2UxNi5j
DQogIFtERVBTXSBjb3JlL2Fzc2VydC5jDQogIFtERVBTXSBjb3JlL2FzcHJpbnRmLmMNCiAg
W0RFUFNdIGNvcmUvYW5zaWVzYy5jDQogIFtERVBTXSBjb3JlL2FjcGkuYw0KICBbREVQU10g
bGliZ2NjL19fdW1vZGRpMy5jDQogIFtERVBTXSBsaWJnY2MvX191ZGl2bW9kZGk0LmMNCiAg
W0RFUFNdIGxpYmdjYy9fX3VkaXZkaTMuYw0KICBbREVQU10gbGliZ2NjL19fbW9kZGkzLmMN
CiAgW0RFUFNdIGxpYmdjYy9tZW1jcHkuYw0KICBbREVQU10gbGliZ2NjL2ljYy5jDQogIFtE
RVBTXSBsaWJnY2MvX19kaXZkaTMuYw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvaXB4
ZS9zcmMnDQptYWtlWzddOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvaXB4ZS9zcmMnDQogIFtERVBT
XSBhcmNoL2kzODYvcHJlZml4L3JvbXByZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJl
Zml4L21yb21wcmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGly
b20uYw0KICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGlwcmVsb2FkLmMNCiAg
W0RFUFNdIGFyY2gvaTM4Ni9kcml2ZXJzL25ldC91bmRpb25seS5jDQogIFtERVBTXSBhcmNo
L2kzODYvZHJpdmVycy9uZXQvdW5kaW5ldC5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVy
cy9uZXQvdW5kaWxvYWQuYw0KICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGku
Yw0KICBbREVQU10gYXJjaC94ODYvaW50ZXJmYWNlL2VmaS9lZml4ODZfbmFwLmMNCiAgW0RF
UFNdIGFyY2gveDg2L2NvcmUvcGNpZGlyZWN0LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9oY2kv
Y29tbWFuZHMvcmVib290X2NtZC5jDQogIFtERVBTXSBhcmNoL2kzODYvaGNpL2NvbW1hbmRz
L3B4ZV9jbWQuYw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9zeXNsaW51eC9jb21i
b290X3Jlc29sdi5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2Nv
bWJvb3RfY2FsbC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2Nv
bTMyX2NhbGwuYw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGVwYXJlbnQvcHhl
cGFyZW50X2RoY3AuYw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGVwYXJlbnQv
cHhlcGFyZW50LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV91bmRp
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV91ZHAuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3RmdHAuYw0KICBbREVQU10gYXJjaC9p
Mzg2L2ludGVyZmFjZS9weGUvcHhlX3ByZWJvb3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2lu
dGVyZmFjZS9weGUvcHhlX2xvYWRlci5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNl
L3B4ZS9weGVfZmlsZS5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZS9weGVf
ZXhpdF9ob29rLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9jYWxs
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL3BjaWJpb3MuYw0KICBb
REVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvbWVtdG9wX3VtYWxsb2MuYw0KICBb
REVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvaW50MTMuYw0KICBbREVQU10gYXJj
aC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvYmlvc190aW1lci5jDQogIFtERVBTXSBhcmNoL2kz
ODYvaW50ZXJmYWNlL3BjYmlvcy9iaW9zX3NtYmlvcy5jDQogIFtERVBTXSBhcmNoL2kzODYv
aW50ZXJmYWNlL3BjYmlvcy9iaW9zX25hcC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJm
YWNlL3BjYmlvcy9iaW9zaW50LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9weGVfaW1h
Z2UuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdlL25iaS5jDQogIFtERVBTXSBhcmNoL2kz
ODYvaW1hZ2UvbXVsdGlib290LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9lbGZib290
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9jb21ib290LmMNCiAgW0RFUFNdIGFyY2gv
aTM4Ni9pbWFnZS9jb20zMi5jDQogIFtERVBTXSBhcmNoL2kzODYvaW1hZ2UvYnppbWFnZS5j
DQogIFtERVBTXSBhcmNoL2kzODYvaW1hZ2UvYm9vdHNlY3Rvci5jDQogIFtERVBTXSBhcmNo
L2kzODYvZmlybXdhcmUvcGNiaW9zL3BucGJpb3MuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zp
cm13YXJlL3BjYmlvcy9tZW1tYXAuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3Bj
Ymlvcy9oaWRlbWVtLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvZmFr
ZWU4MjAuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3BjYmlvcy9iaW9zX2NvbnNv
bGUuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3BjYmlvcy9iYXNlbWVtLmMNCiAg
W0RFUFNdIGFyY2gvaTM4Ni90cmFuc2l0aW9ucy9saWJybV9tZ210LmMNCiAgW0RFUFNdIGFy
Y2gvaTM4Ni9jb3JlL3g4Nl9pby5jDQogIFtERVBTXSBhcmNoL2kzODYvY29yZS92aWRlb19z
dWJyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3RpbWVyMi5jDQogIFtERVBTXSBhcmNo
L2kzODYvY29yZS9ydW50aW1lLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3JlbG9jYXRl
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3JkdHNjX3RpbWVyLmMNCiAgW0RFUFNdIGFy
Y2gvaTM4Ni9jb3JlL3BpYzgyNTkuYw0KICBbREVQU10gYXJjaC9pMzg2L2NvcmUvZ2RibWFj
aC5jDQogIFtERVBTXSBhcmNoL2kzODYvY29yZS9kdW1wcmVncy5jDQogIFtERVBTXSBhcmNo
L2kzODYvY29yZS9iYXNlbWVtX3BhY2tldC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX3Jv
bXByZWZpeC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX25ldDgwMjExLmMNCiAgW0RFUFNd
IGNvbmZpZy9jb25maWdfaW5maW5pYmFuZC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX2Zj
LmMNCiAgW0RFUFNdIGNvbmZpZy9jb25maWdfZXRoZXJuZXQuYw0KICBbREVQU10gY29uZmln
L2NvbmZpZy5jDQogIFtERVBTXSB1c3IvcHhlbWVudS5jDQogIFtERVBTXSB1c3IvcHJvbXB0
LmMNCiAgW0RFUFNdIHVzci9pbWdtZ210LmMNCiAgW0RFUFNdIHVzci9pZm1nbXQuYw0KICBb
REVQU10gdXNyL2RoY3BtZ210LmMNCiAgW0RFUFNdIHVzci9hdXRvYm9vdC5jDQogIFtERVBT
XSBoY2kvbXVjdXJzZXMva2IuYw0KICBbREVQU10gaGNpL3R1aS9zZXR0aW5nc191aS5jDQog
IFtERVBTXSBoY2kvY29tbWFuZHMvdGltZV9jbWQuYw0KICBbREVQU10gaGNpL2NvbW1hbmRz
L3NhbmJvb3RfY21kLmMNCiAgW0RFUFNdIGhjaS9jb21tYW5kcy9pbWFnZV9jbWQuYw0KICBb
REVQU10gaGNpL2NvbW1hbmRzL2RpZ2VzdF9jbWQuYw0KICBbREVQU10gdGVzdHMvdW1hbGxv
Y190ZXN0LmMNCiAgW0RFUFNdIHRlc3RzL2JvZm1fdGVzdC5jDQogIFtERVBTXSBpbnRlcmZh
Y2UvYm9mbS9ib2ZtLmMNCiAgW0RFUFNdIGludGVyZmFjZS9zbWJpb3Mvc21iaW9zX3NldHRp
bmdzLmMNCiAgW0RFUFNdIGludGVyZmFjZS9zbWJpb3Mvc21iaW9zLmMNCiAgW0RFUFNdIGlu
dGVyZmFjZS9lZmkvZWZpX3VtYWxsb2MuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlf
dWFjY2Vzcy5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV90aW1lci5jDQogIFtERVBT
XSBpbnRlcmZhY2UvZWZpL2VmaV9zbnAuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlf
c21iaW9zLmMNCiAgW0RFUFNdIGludGVyZmFjZS9lZmkvZWZpX3BjaS5jDQogIFtERVBTXSBp
bnRlcmZhY2UvZWZpL2VmaV9pby5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9kcml2
ZXIuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfYm9mbS5jDQogIFtERVBTXSBkcml2
ZXJzL2luZmluaWJhbmQvcWliNzMyMi5jDQogIFtERVBTXSBkcml2ZXJzL2luZmluaWJhbmQv
bGluZGEuYw0KICBbREVQU10gZHJpdmVycy9pbmZpbmliYW5kL2hlcm1vbi5jDQogIFtERVBT
XSBkcml2ZXJzL2luZmluaWJhbmQvYXJiZWwuYw0KICBbREVQU10gZHJpdmVycy9iaXRiYXNo
L3NwaV9iaXQuYw0KICBbREVQU10gZHJpdmVycy9iaXRiYXNoL2kyY19iaXQuYw0KICBbREVQ
U10gZHJpdmVycy9udnMvdGhyZWV3aXJlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbnZzL3NwaS5j
DQogIFtERVBTXSBkcml2ZXJzL252cy9udnN2cGQuYw0KICBbREVQU10gZHJpdmVycy9ibG9j
ay9zcnAuYw0KICBbREVQU10gZHJpdmVycy9ibG9jay9zY3NpLmMNCiAgW0RFUFNdIGRyaXZl
cnMvYmxvY2svaWJmdC5jDQogIFtERVBTXSBkcml2ZXJzL2Jsb2NrL2F0YS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9lZmkvc25wbmV0LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2Uv
dnhnZV90cmFmZmljLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV9tYWluLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV9jb25maWcuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvdnhnZS92eGdlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9h
dGg5a194bWl0LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19yZWN2
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19tYWluLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19tYWMuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDlrL2F0aDlrX2luaXQuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRo
L2F0aDlrL2F0aDlrX2h3LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5
a19lZXByb21fZGVmLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19l
ZXByb20uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbV85
Mjg3LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb21fNGsu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2NvbW1vbi5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfY2FsaWIuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9h
dGg5ay9hdGg5a19hcjkwMDNfcGh5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5
ay9hdGg5a19hcjkwMDNfbWFjLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9h
dGg5a19hcjkwMDNfaHcuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlr
X2FyOTAwM19lZXByb20uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlr
X2FyOTAwM19jYWxpYi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtf
YXI5MDAyX3BoeS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5
MDAyX21hYy5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAy
X2h3LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDJfY2Fs
aWIuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyNTAwOF9waHku
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FuaS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfcmZraWxsLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg1ay9hdGg1a19yZXNldC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9h
dGgvYXRoNWsvYXRoNWtfcWN1LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9h
dGg1a19waHkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX3BjdS5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfaW5pdHZhbHMuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX2dwaW8uYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX2VlcHJvbS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9hdGgvYXRoNWsvYXRoNWtfZG1hLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1
ay9hdGg1a19kZXNjLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19j
YXBzLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1ay5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfYXR0YWNoLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGhfcmVnZC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoX21h
aW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aF9rZXkuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aF9ody5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9ydGw4MTh4L3J0
bDgxOHguYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTg1X3J0bDgyMjUu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTg1LmMNCiAgW0RFUFNdIGRy
aXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4MF9zYTI0MDAuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvcnRsODE4eC9ydGw4MTgwX21heDI4MjAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRs
ODE4eC9ydGw4MTgwX2dyZjUxMDEuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9y
dGw4MTgwLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3BoYW50b20vcGhhbnRvbS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9pZ2J2Zi9pZ2J2Zl92Zi5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9pZ2J2Zi9pZ2J2Zl9tYnguYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdidmYvaWdidmZf
bWFpbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX3BoeS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9pZ2IvaWdiX252bS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdi
X21hbmFnZS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX21haW4uYw0KICBbREVQ
U10gZHJpdmVycy9uZXQvaWdiL2lnYl9tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdi
L2lnYl9hcGkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdiL2lnYl84MjU3NS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX3BoeS5jDQogIFtERVBTXSBkcml2ZXJz
L25ldC9lMTAwMGUvZTEwMDBlX252bS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMGUv
ZTEwMDBlX21haW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZV9tYWMu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZV9pY2g4bGFuLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfODI1NzEuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvZTEwMDBlL2UxMDAwZV84MDAwM2VzMmxhbi5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9lMTAwMC9lMTAwMF9waHkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBf
bnZtLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwX21haW4uYw0KICBbREVQ
U10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfbWFjLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L2UxMDAwL2UxMDAwX2FwaS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84
MjU0My5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84MjU0Mi5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84MjU0MS5jDQogIFtERVBTXSBkcml2ZXJz
L25ldC9lMTAwMC9lMTAwMF84MjU0MC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC93ODljODQw
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3ZpcnRpby1uZXQuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvdmlhLXZlbG9jaXR5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3ZpYS1yaGluZS5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC90dWxpcC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC90
bGFuLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3RnMy5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9zdW5kYW5jZS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9zbWM5MDAwLmMNCiAgW0RFUFNd
IGRyaXZlcnMvbmV0L3NreTIuYw0KICBbREVQU10gZHJpdmVycy9uZXQvc2tnZS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9zaXM5MDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvc2lzMTkw
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3J0bDgxMzkuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvcjgxNjkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcHJpc20yX3BseC5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9wcmlzbTJfcGNpLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3BuaWMu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvcGNuZXQzMi5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9uczgzOTAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvbnM4MzgyMC5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9uZTJrX2lzYS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9uYXRzZW1pLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L215cmkxMGdlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L210ZDgweC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9sZWdhY3kuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvam1lLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2lwb2liLmMNCiAgW0RFUFNd
IGRyaXZlcnMvbmV0L2ZvcmNlZGV0aC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9ldGhlcmZh
YnJpYy5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lcGljMTAwLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2VlcHJvLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2VlcHJvMTAwLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2RtZmUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZGF2aWNvbS5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9jczg5eDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQv
Ym54Mi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9iNDQuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvYXRsMWUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYW1kODExMWUuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvM2M5MHguYw0KICBbREVQU10gZHJpdmVycy9uZXQvM2M1eDkuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvM2M1OTUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvM2M1Mjku
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvM2M1MTUuYw0KICBbREVQU10gZHJpdmVycy9uZXQv
M2M1MDktZWlzYS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzUwOS5jDQogIFtERVBTXSBk
cml2ZXJzL2J1cy92aXJ0aW8tcmluZy5jDQogIFtERVBTXSBkcml2ZXJzL2J1cy92aXJ0aW8t
cGNpLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL3BjaXZwZC5jDQogIFtERVBTXSBkcml2ZXJz
L2J1cy9wY2lleHRyYS5jDQogIFtERVBTXSBkcml2ZXJzL2J1cy9wY2kuYw0KICBbREVQU10g
ZHJpdmVycy9idXMvcGNpYmFja3VwLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL21jYS5jDQog
IFtERVBTXSBkcml2ZXJzL2J1cy9pc2FwbnAuYw0KICBbREVQU10gZHJpdmVycy9idXMvaXNh
LmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL2Vpc2EuYw0KICBbREVQU10gaW1hZ2Uvc2VnbWVu
dC5jDQogIFtERVBTXSBpbWFnZS9zY3JpcHQuYw0KICBbREVQU10gaW1hZ2UvZW1iZWRkZWQu
Yw0KICBbREVQU10gaW1hZ2UvZWxmLmMNCiAgW0RFUFNdIGltYWdlL2VmaV9pbWFnZS5jDQog
IFtERVBTXSBuZXQvODAyMTEvbmV0ODAyMTEuYw0KICBbREVQU10gbmV0L2luZmluaWJhbmQv
aWJfc3JwLmMNCiAgW0RFUFNdIG5ldC9pbmZpbmliYW5kL2liX3NtYy5jDQogIFtERVBTXSBu
ZXQvaW5maW5pYmFuZC9pYl9zbWEuYw0KICBbREVQU10gbmV0L2luZmluaWJhbmQvaWJfbWku
Yw0KICBbREVQU10gbmV0L3VkcC90ZnRwLmMNCiAgW0RFUFNdIG5ldC91ZHAvc3lzbG9nLmMN
CiAgW0RFUFNdIG5ldC91ZHAvc2xhbS5jDQogIFtERVBTXSBuZXQvdWRwL2Rucy5jDQogIFtE
RVBTXSBuZXQvdWRwL2RoY3AuYw0KICBbREVQU10gbmV0L3RjcC9pc2NzaS5jDQogIFtERVBT
XSBuZXQvdGNwL2h0dHBzLmMNCiAgW0RFUFNdIG5ldC90Y3AvaHR0cC5jDQogIFtERVBTXSBu
ZXQvdGNwL2Z0cC5jDQogIFtERVBTXSBuZXQvdmxhbi5jDQogIFtERVBTXSBuZXQvdGNwLmMN
CiAgW0RFUFNdIG5ldC9yZXRyeS5jDQogIFtERVBTXSBuZXQvbmV0ZGV2X3NldHRpbmdzLmMN
CiAgW0RFUFNdIG5ldC9uZXRkZXZpY2UuYw0KICBbREVQU10gbmV0L2lwdjQuYw0KICBbREVQ
U10gbmV0L2luZmluaWJhbmQuYw0KICBbREVQU10gbmV0L2ZjcC5jDQogIFtERVBTXSBuZXQv
ZmNvZS5jDQogIFtERVBTXSBuZXQvZmMuYw0KICBbREVQU10gbmV0L2Zha2VkaGNwLmMNCiAg
W0RFUFNdIG5ldC9kaGNwcGt0LmMNCiAgW0RFUFNdIG5ldC9kaGNwb3B0cy5jDQogIFtERVBT
XSBuZXQvY2FjaGVkaGNwLmMNCiAgW0RFUFNdIG5ldC9hb2UuYw0KICBbREVQU10gY29yZS90
aW1lci5jDQogIFtERVBTXSBjb3JlL3NldHRpbmdzLmMNCiAgW0RFUFNdIGNvcmUvc2VyaWFs
LmMNCiAgW0RFUFNdIGNvcmUvcmFuZG9tLmMNCiAgW0RFUFNdIGNvcmUvcG9zaXhfaW8uYw0K
ICBbREVQU10gY29yZS9wY19rYmQuYw0KICBbREVQU10gY29yZS9wYXJzZW9wdC5jDQogIFtE
RVBTXSBjb3JlL252by5jDQogIFtERVBTXSBjb3JlL251bGxfc2FuYm9vdC5jDQogIFtERVBT
XSBjb3JlL251bGxfbmFwLmMNCiAgW0RFUFNdIGNvcmUvbW9ub2pvYi5jDQogIFtERVBTXSBj
b3JlL21pc2MuYw0KICBbREVQU10gY29yZS9tYWxsb2MuYw0KICBbREVQU10gY29yZS9tYWlu
LmMNCiAgW0RFUFNdIGNvcmUvaW1hZ2UuYw0KICBbREVQU10gY29yZS9nZXRrZXkuYw0KICBb
REVQU10gY29yZS9nZGJ1ZHAuYw0KICBbREVQU10gY29yZS9mbnJlYy5jDQogIFtERVBTXSBj
b3JlL2V4ZWMuYw0KICBbREVQU10gY29yZS9kb3dubG9hZGVyLmMNCiAgW0RFUFNdIGNvcmUv
ZGVidWcuYw0KICBbREVQU10gY29yZS9jb25zb2xlLmMNCiAgW0RFUFNdIGNvcmUvYmxvY2tk
ZXYuYw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvaXB4ZS9zcmMnDQptYWtlWzddOiBF
bnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9m
aXJtd2FyZS9ldGhlcmJvb3QvaXB4ZS9zcmMnDQogIFtCVUlMRF0gYmluL19fZGl2ZGkzLm8N
CiAgW0JVSUxEXSBiaW4vaWNjLm8NCiAgW0JVSUxEXSBiaW4vbWVtY3B5Lm8NCiAgW0JVSUxE
XSBiaW4vX19tb2RkaTMubw0KICBbQlVJTERdIGJpbi9fX3VkaXZkaTMubw0KICBbQlVJTERd
IGJpbi9fX3VkaXZtb2RkaTQubw0KICBbQlVJTERdIGJpbi9fX3Vtb2RkaTMubw0KICBbQlVJ
TERdIGJpbi9hY3BpLm8NCiAgW0JVSUxEXSBiaW4vYW5zaWVzYy5vDQogIFtCVUlMRF0gYmlu
L2FzcHJpbnRmLm8NCiAgW0JVSUxEXSBiaW4vYXNzZXJ0Lm8NCiAgW0JVSUxEXSBiaW4vYmFz
ZTE2Lm8NCiAgW0JVSUxEXSBiaW4vYmFzZTY0Lm8NCiAgW0JVSUxEXSBiaW4vYmFzZW5hbWUu
bw0KICBbQlVJTERdIGJpbi9iaXRtYXAubw0KICBbQlVJTERdIGJpbi9iaXRvcHMubw0KICBb
QlVJTERdIGJpbi9ibG9ja2Rldi5vDQogIFtCVUlMRF0gYmluL2J0ZXh0Lm8NCiAgW0JVSUxE
XSBiaW4vY29uc29sZS5vDQogIFtCVUlMRF0gYmluL2NwaW8ubw0KICBbQlVJTERdIGJpbi9j
dHlwZS5vDQogIFtCVUlMRF0gYmluL2N3dXJpLm8NCiAgW0JVSUxEXSBiaW4vZGVidWcubw0K
ICBbQlVJTERdIGJpbi9kZWJ1Z19tZDUubw0KICBbQlVJTERdIGJpbi9kZXZpY2Uubw0KICBb
QlVJTERdIGJpbi9kb3dubG9hZGVyLm8NCiAgW0JVSUxEXSBiaW4vZWRkLm8NCiAgW0JVSUxE
XSBiaW4vZXJybm8ubw0KICBbQlVJTERdIGJpbi9leGVjLm8NCiAgW0JVSUxEXSBiaW4vZm5y
ZWMubw0KICBbQlVJTERdIGJpbi9nZGJzZXJpYWwubw0KICBbQlVJTERdIGJpbi9nZGJzdHVi
Lm8NCiAgW0JVSUxEXSBiaW4vZ2RidWRwLm8NCiAgW0JVSUxEXSBiaW4vZ2V0a2V5Lm8NCiAg
W0JVSUxEXSBiaW4vZ2V0b3B0Lm8NCiAgW0JVSUxEXSBiaW4vaHcubw0KICBbQlVJTERdIGJp
bi9pODIzNjUubw0KICBbQlVJTERdIGJpbi9pbWFnZS5vDQogIFtCVUlMRF0gYmluL2luaXQu
bw0KICBbQlVJTERdIGJpbi9pbnRlcmZhY2Uubw0KICBbQlVJTERdIGJpbi9pb2J1Zi5vDQog
IFtCVUlMRF0gYmluL2pvYi5vDQogIFtCVUlMRF0gYmluL2xpbmVidWYubw0KICBbQlVJTERd
IGJpbi9tYWluLm8NCiAgW0JVSUxEXSBiaW4vbWFsbG9jLm8NCiAgW0JVSUxEXSBiaW4vbWlz
Yy5vDQogIFtCVUlMRF0gYmluL21vbm9qb2Iubw0KICBbQlVJTERdIGJpbi9udWxsX25hcC5v
DQogIFtCVUlMRF0gYmluL251bGxfc2FuYm9vdC5vDQogIFtCVUlMRF0gYmluL252by5vDQog
IFtCVUlMRF0gYmluL29wZW4ubw0KICBbQlVJTERdIGJpbi9wYXJzZW9wdC5vDQogIFtCVUlM
RF0gYmluL3BjX2tiZC5vDQogIFtCVUlMRF0gYmluL3BjbWNpYS5vDQogIFtCVUlMRF0gYmlu
L3Bvc2l4X2lvLm8NCiAgW0JVSUxEXSBiaW4vcHJvY2Vzcy5vDQogIFtCVUlMRF0gYmluL3Jh
bmRvbS5vDQogIFtCVUlMRF0gYmluL3JlZmNudC5vDQogIFtCVUlMRF0gYmluL3Jlc29sdi5v
DQogIFtCVUlMRF0gYmluL3NlcmlhbC5vDQogIFtCVUlMRF0gYmluL3NlcmlhbF9jb25zb2xl
Lm8NCiAgW0JVSUxEXSBiaW4vc2V0dGluZ3Mubw0KICBbQlVJTERdIGJpbi9zdHJpbmcubw0K
ICBbQlVJTERdIGJpbi9zdHJpbmdleHRyYS5vDQogIFtCVUlMRF0gYmluL3N0cnRvdWxsLm8N
CiAgW0JVSUxEXSBiaW4vdGltZXIubw0KICBbQlVJTERdIGJpbi91cmkubw0KICBbQlVJTERd
IGJpbi91dWlkLm8NCiAgW0JVSUxEXSBiaW4vdnNwcmludGYubw0KICBbQlVJTERdIGJpbi94
ZmVyLm8NCiAgW0JVSUxEXSBiaW4vYW9lLm8NCiAgW0JVSUxEXSBiaW4vYXJwLm8NCiAgW0JV
SUxEXSBiaW4vY2FjaGVkaGNwLm8NCiAgW0JVSUxEXSBiaW4vZGhjcG9wdHMubw0KICBbQlVJ
TERdIGJpbi9kaGNwcGt0Lm8NCiAgW0JVSUxEXSBiaW4vZWFwb2wubw0KICBbQlVJTERdIGJp
bi9ldGhlcm5ldC5vDQogIFtCVUlMRF0gYmluL2V0aF9zbG93Lm8NCiAgW0JVSUxEXSBiaW4v
ZmFrZWRoY3Aubw0KICBbQlVJTERdIGJpbi9mYy5vDQogIFtCVUlMRF0gYmluL2ZjZWxzLm8N
CiAgW0JVSUxEXSBiaW4vZmNucy5vDQogIFtCVUlMRF0gYmluL2Zjb2Uubw0KICBbQlVJTERd
IGJpbi9mY3Aubw0KICBbQlVJTERdIGJpbi9pY21wLm8NCiAgW0JVSUxEXSBiaW4vaWNtcHY2
Lm8NCiAgW0JVSUxEXSBiaW4vaW5maW5pYmFuZC5vDQogIFtCVUlMRF0gYmluL2lvYnBhZC5v
DQogIFtCVUlMRF0gYmluL2lwdjQubw0KICBbQlVJTERdIGJpbi9pcHY2Lm8NCiAgW0JVSUxE
XSBiaW4vbWlpLm8NCiAgW0JVSUxEXSBiaW4vbmRwLm8NCiAgW0JVSUxEXSBiaW4vbmV0ZGV2
aWNlLm8NCiAgW0JVSUxEXSBiaW4vbmV0ZGV2X3NldHRpbmdzLm8NCiAgW0JVSUxEXSBiaW4v
bnVsbG5ldC5vDQogIFtCVUlMRF0gYmluL3JhcnAubw0KICBbQlVJTERdIGJpbi9yZXRyeS5v
DQogIFtCVUlMRF0gYmluL3RjcC5vDQogIFtCVUlMRF0gYmluL3RjcGlwLm8NCiAgW0JVSUxE
XSBiaW4vdGxzLm8NCiAgW0JVSUxEXSBiaW4vdWRwLm8NCiAgW0JVSUxEXSBiaW4vdmxhbi5v
DQogIFtCVUlMRF0gYmluL2Z0cC5vDQogIFtCVUlMRF0gYmluL2h0dHAubw0KICBbQlVJTERd
IGJpbi9odHRwcy5vDQogIFtCVUlMRF0gYmluL2lzY3NpLm8NCiAgW0JVSUxEXSBiaW4vZGhj
cC5vDQogIFtCVUlMRF0gYmluL2Rucy5vDQogIFtCVUlMRF0gYmluL3NsYW0ubw0KICBbQlVJ
TERdIGJpbi9zeXNsb2cubw0KICBbQlVJTERdIGJpbi90ZnRwLm8NCiAgW0JVSUxEXSBiaW4v
aWJfY20ubw0KICBbQlVJTERdIGJpbi9pYl9jbXJjLm8NCiAgW0JVSUxEXSBiaW4vaWJfbWNh
c3Qubw0KICBbQlVJTERdIGJpbi9pYl9taS5vDQogIFtCVUlMRF0gYmluL2liX3BhY2tldC5v
DQogIFtCVUlMRF0gYmluL2liX3BhdGhyZWMubw0KICBbQlVJTERdIGJpbi9pYl9zbWEubw0K
ICBbQlVJTERdIGJpbi9pYl9zbWMubw0KICBbQlVJTERdIGJpbi9pYl9zcnAubw0KICBbQlVJ
TERdIGJpbi9uZXQ4MDIxMS5vDQogIFtCVUlMRF0gYmluL3JjODAyMTEubw0KICBbQlVJTERd
IGJpbi9zZWM4MDIxMS5vDQogIFtCVUlMRF0gYmluL3dlcC5vDQogIFtCVUlMRF0gYmluL3dw
YS5vDQogIFtCVUlMRF0gYmluL3dwYV9jY21wLm8NCiAgW0JVSUxEXSBiaW4vd3BhX3Bzay5v
DQogIFtCVUlMRF0gYmluL3dwYV90a2lwLm8NCiAgW0JVSUxEXSBiaW4vZWZpX2ltYWdlLm8N
CiAgW0JVSUxEXSBiaW4vZWxmLm8NCiAgW0JVSUxEXSBiaW4vZW1iZWRkZWQubw0KICBbQlVJ
TERdIGJpbi9zY3JpcHQubw0KICBbQlVJTERdIGJpbi9zZWdtZW50Lm8NCiAgW0JVSUxEXSBi
aW4vZWlzYS5vDQogIFtCVUlMRF0gYmluL2lzYS5vDQpkcml2ZXJzL2J1cy9pc2EuYzogSW4g
ZnVuY3Rpb24g4mlzYWJ1c19wcm9iZeI6DQpkcml2ZXJzL2J1cy9pc2EuYzoxMTI6MTg6IGVy
cm9yOiBhcnJheSBzdWJzY3JpcHQgaXMgYWJvdmUgYXJyYXkgYm91bmRzIFstV2Vycm9yPWFy
cmF5LWJvdW5kc10NCmNjMTogYWxsIHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3Jz
DQptYWtlWzddOiAqKiogW2Jpbi9pc2Eub10gRXJyb3IgMQ0KbWFrZVs3XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9l
dGhlcmJvb3QvaXB4ZS9zcmMnDQptYWtlWzZdOiAqKiogW2lweGUvc3JjL2Jpbi9ydGw4MTM5
LnJvbV0gRXJyb3IgMg0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QnDQptYWtlWzVdOiAq
KiogW3N1YmRpci1hbGwtZXRoZXJib290XSBFcnJvciAyDQptYWtlWzVdOiBMZWF2aW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0K
bWFrZVs0XTogKioqIFtzdWJkaXJzLWFsbF0gRXJyb3IgMg0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZScN
Cm1ha2VbM106ICoqKiBbYWxsXSBFcnJvciAyDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9y
eSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZVsy
XTogKioqIFtzdWJkaXItaW5zdGFsbC1maXJtd2FyZV0gRXJyb3IgMg0KbWFrZVsyXTogTGVh
dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1h
a2VbMV06ICoqKiBbc3ViZGlycy1pbnN0YWxsXSBFcnJvciAyDQptYWtlWzFdOiBMZWF2aW5n
IGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZTog
KioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyDQpyb290QHZmYXJtOi9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZyMg
--------------030803080800070300000702--

--------------ms060008070700000805000102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYyNzA4NTQwM1owIwYJKoZIhvcNAQkEMRYEFPb8qNgiPCDiRx5L2FYZQrtr
7lT/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBqp6O+fXpIKwHdX4dk0z1wXx7BktZjsvZSnOtc/kkd
JYl1zyw2FM4bayYb5SdywWXyeMw/JADQy5FKDvq0+372FP9fyOun5071D6Hikd/SQjkmyzCd
XiId3axIaKyQUsI7Xeali/D1bp88nezzgStGwv2YbmPPcNg87SkGovbPe/WvZHMXAsqnPUPd
ZMnacuvAr1jGr0pwZBPFbkzZz98xq+P5DHrJlQYJQ2C7tBur2Al/1hGO0V+ftv7AvsS48Hcr
yFmtl3uAhY6/5sfLbx5j0hKYQqDth4aAd16FVUn3K3Vz0yKP+WbVwpDmoVEAV7B9fDd5YcLZ
WbbpHlKw+K+GAAAAAAAA
--------------ms060008070700000805000102--


--===============7158966147011069039==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7158966147011069039==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 11:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1SjqBi-0004ib-KF; Wed, 27 Jun 2012 11:13:34 +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 1Sjo1X-0001E3-ND
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 08:55:00 +0000
Received: from [85.158.138.51:15062] by server-8.bemta-3.messagelabs.com id
	C3/12-06157-E5ACAEF4; Wed, 27 Jun 2012 08:54:54 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340787276!20836528!1
X-Originating-IP: [82.57.200.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16236 invoked from network); 27 Jun 2012 08:54:36 -0000
Received: from smtp205.alice.it (HELO smtp205.alice.it) (82.57.200.101)
	by server-7.tower-174.messagelabs.com with SMTP;
	27 Jun 2012 08:54:36 -0000
Received: from [192.168.178.50] (82.50.150.238) by smtp205.alice.it
	(8.6.023.02) id 4F421F7B0F1B7C20 for xen-devel@lists.xensource.com;
	Wed, 27 Jun 2012 10:54:33 +0200
Message-ID: <4FEACA2B.4040400@tiscali.it>
Date: Wed, 27 Jun 2012 10:54:03 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Mailman-Approved-At: Wed, 27 Jun 2012 11:13:32 +0000
Subject: [Xen-devel] Build error with xen-unstable changeset
	25517:c6c9d20963d7
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="===============7158966147011069039=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7158966147011069039==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060008070700000805000102"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060008070700000805000102
Content-Type: multipart/mixed;
 boundary="------------030803080800070300000702"

This is a multi-part message in MIME format.
--------------030803080800070300000702
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I had built on Wheezy updated xen-unstable changeset 25517:c6c9d20963d7=20
and I had this build error:
drivers/bus/isa.c: In function =E2isabus_probe=E2:
drivers/bus/isa.c:112:18: error: array subscript is above array bounds=20
[-Werror=3Darray-bounds]
cc1: all warnings being treated as errors
make[7]: *** [bin/isa.o] Error 1
make[7]: Leaving directory=20
`/mnt/vm/xen/xen-unstable.hg/tools/firmware/etherboot/ipxe/src'
make[6]: *** [ipxe/src/bin/rtl8139.rom] Error 2
make[6]: Leaving directory=20
`/mnt/vm/xen/xen-unstable.hg/tools/firmware/etherboot'
make[5]: *** [subdir-all-etherboot] Error 2
make[5]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools'
make: *** [install-tools] Error 2

In attachment full log file.
If you need some additional info please notify me, thanks for any reply.

--------------030803080800070300000702
Content-Type: text/plain; charset=windows-1252;
 name="xenbuild.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xenbuild.log"

cm9vdEB2ZmFybTovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcjIG1ha2UgZGViDQptYWtl
IC1DIHhlbiBpbnN0YWxsDQptYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4nDQptYWtlIC1mIFJ1bGVzLm1rIF9pbnN0YWxsDQpt
YWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4nDQptYWtlIC1DIHRvb2xzDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQpbIC1kIGZpZ2xldCBdICYm
IG1ha2UgLUMgZmlnbGV0DQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvZmlnbGV0Jw0KZ2NjIC1vIGZpZ2xldCBm
aWdsZXQuYw0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vdG9vbHMvZmlnbGV0Jw0KbWFrZSBzeW1ib2xzDQptYWtlWzRdOiBF
bnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMnDQpnY2MgLVdhbGwgLVdlcnJvciAtV3N0cmljdC1wcm90b3R5cGVzIC1PMiAtZm9taXQt
ZnJhbWUtcG9pbnRlciAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtbyBzeW1ib2xzIHN5bWJvbHMuYw0KbWFrZVs0XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQptYWtlWzNd
OiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90
b29scycNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5t
ayBpbmNsdWRlL3hlbi9jb21waWxlLmgNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbicNCm1ha2UgLUMgdG9vbHMNCm1ha2Vb
NF06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi90b29scycNClsgLWQgZmlnbGV0IF0gJiYgbWFrZSAtQyBmaWdsZXQNCm1ha2VbNV06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29s
cy9maWdsZXQnDQptYWtlWzVdOiBgZmlnbGV0JyBpcyB1cCB0byBkYXRlLg0KbWFrZVs1XTog
TGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMvZmlnbGV0Jw0KbWFrZSBzeW1ib2xzDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQptYWtlWzVdOiBgc3lt
Ym9scycgaXMgdXAgdG8gZGF0ZS4NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzJw0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMnDQogX18g
IF9fICAgICAgICAgICAgXyAgXyAgICBfX19fICAgICAgICAgICAgICAgICAgICAgXyAgICAg
ICAgXyAgICAgXyAgICAgIA0KIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAg
XyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyANCiAgXCAgLy8gXyBcICdf
IFwgIHwgfHwgfF8gICBfXykgfF9ffCB8IHwgfCAnXyBcLyBfX3wgX18vIF9gIHwgJ18gXHwg
fC8gXyBcDQogIC8gIFwgIF9fLyB8IHwgfCB8X18gICBffCAvIF9fL3xfX3wgfF98IHwgfCB8
IFxfXyBcIHx8IChffCB8IHxfKSB8IHwgIF9fLw0KIC9fL1xfXF9fX3xffCB8X3wgICAgfF98
KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbicNClsgLWUgaW5jbHVkZS9hc20gXSB8fCBsbiAt
c2YgYXNtLXg4NiBpbmNsdWRlL2FzbQ0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL1J1bGVzLm1rIC1DIGluY2x1ZGUNCm1ha2VbM106IEVudGVyaW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlJw0KbWtkaXIg
LXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShsb25nKScgcHVi
bGljL2NhbGxiYWNrLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L2NhbGxiYWNrLmMu
bmV3DQptdiAtZiBjb21wYXQvY2FsbGJhY2suYy5uZXcgY29tcGF0L2NhbGxiYWNrLmMNCmdj
YyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5v
LWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQt
ZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NF
IC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRl
IHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvY2FsbGJhY2suaSBjb21wYXQv
Y2FsbGJhY2suYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC9jYWxsYmFjay5oIHwgdHIg
J1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQi
ID5jb21wYXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21w
YXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIg
Pj5jb21wYXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL2Nh
bGxiYWNrLmg+IiA+PmNvbXBhdC9jYWxsYmFjay5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEg
cGFjayg0KSIgPj5jb21wYXQvY2FsbGJhY2suaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05
XScgY29tcGF0L2NhbGxiYWNrLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21w
YXQvY2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQv
Y2FsbGJhY2suaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9j
YWxsYmFjay5oLm5ldw0KbXYgLWYgY29tcGF0L2NhbGxiYWNrLmgubmV3IGNvbXBhdC9jYWxs
YmFjay5oDQpta2RpciAtcCBjb21wYXQNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFO
RExFKGxvbmcpJyBwdWJsaWMvZWxmbm90ZS5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBh
dC9lbGZub3RlLmMubmV3DQptdiAtZiBjb21wYXQvZWxmbm90ZS5jLm5ldyBjb21wYXQvZWxm
bm90ZS5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJs
ZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L2VsZm5vdGUu
aSBjb21wYXQvZWxmbm90ZS5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0L2VsZm5vdGUu
aCB8IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5k
ZWYgJGlkIiA+Y29tcGF0L2VsZm5vdGUuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIg
Pj5jb21wYXQvZWxmbm90ZS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0
Lmg+IiA+PmNvbXBhdC9lbGZub3RlLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHB1Ymxp
Yy9lbGZub3RlLmg+IiA+PmNvbXBhdC9lbGZub3RlLmgubmV3OyBcDQogZWNobyAiI3ByYWdt
YSBwYWNrKDQpIiA+PmNvbXBhdC9lbGZub3RlLmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAt
OV0nIGNvbXBhdC9lbGZub3RlLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21w
YXQvZWxmbm90ZS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9l
bGZub3RlLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIgPj5jb21wYXQvZWxm
bm90ZS5oLm5ldw0KbXYgLWYgY29tcGF0L2VsZm5vdGUuaC5uZXcgY29tcGF0L2VsZm5vdGUu
aA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShs
b25nKScgcHVibGljL2V2ZW50X2NoYW5uZWwuaCB8IFwNCiBweXRob24gL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5jb21w
YXQvZXZlbnRfY2hhbm5lbC5jLm5ldw0KbXYgLWYgY29tcGF0L2V2ZW50X2NoYW5uZWwuYy5u
ZXcgY29tcGF0L2V2ZW50X2NoYW5uZWwuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMy
IC1vIGNvbXBhdC9ldmVudF9jaGFubmVsLmkgY29tcGF0L2V2ZW50X2NoYW5uZWwuYw0Kc2V0
IC1lOyBpZD1fJChlY2hvIGNvbXBhdC9ldmVudF9jaGFubmVsLmggfCB0ciAnWzpsb3dlcjpd
LS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBhdC9l
dmVudF9jaGFubmVsLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L2V2
ZW50X2NoYW5uZWwuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIg
Pj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJs
aWMvZXZlbnRfY2hhbm5lbC5oPiIgPj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsgXA0K
IGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsg
XA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvZXZlbnRfY2hhbm5lbC5pIHwgXA0KIHB5
dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWls
ZC1oZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L2V2ZW50X2NoYW5uZWwuaC5uZXc7IFwNCiBl
Y2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQvZXZlbnRfY2hhbm5lbC5oLm5ldzsgXA0K
IGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0L2V2ZW50X2NoYW5uZWwuaC5uZXcN
Cm12IC1mIGNvbXBhdC9ldmVudF9jaGFubmVsLmgubmV3IGNvbXBhdC9ldmVudF9jaGFubmVs
LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
bG9uZyknIHB1YmxpYy9mZWF0dXJlcy5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC9m
ZWF0dXJlcy5jLm5ldw0KbXYgLWYgY29tcGF0L2ZlYXR1cmVzLmMubmV3IGNvbXBhdC9mZWF0
dXJlcy5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJs
ZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L2ZlYXR1cmVz
LmkgY29tcGF0L2ZlYXR1cmVzLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvZmVhdHVy
ZXMuaCB8IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNp
Zm5kZWYgJGlkIiA+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAk
aWQiID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9j
b21wYXQuaD4iID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUg
PHB1YmxpYy9mZWF0dXJlcy5oPiIgPj5jb21wYXQvZmVhdHVyZXMuaC5uZXc7IFwNCiBlY2hv
ICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZ3JlcCAt
diAnXiMgWzAtOV0nIGNvbXBhdC9mZWF0dXJlcy5pIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1oZWFkZXIucHkgfCB1
bmlxID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCki
ID4+Y29tcGF0L2ZlYXR1cmVzLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIg
Pj5jb21wYXQvZmVhdHVyZXMuaC5uZXcNCm12IC1mIGNvbXBhdC9mZWF0dXJlcy5oLm5ldyBj
b21wYXQvZmVhdHVyZXMuaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL2dyYW50X3RhYmxlLmggfCBcDQogcHl0aG9u
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNv
dXJjZS5weSA+Y29tcGF0L2dyYW50X3RhYmxlLmMubmV3DQptdiAtZiBjb21wYXQvZ3JhbnRf
dGFibGUuYy5uZXcgY29tcGF0L2dyYW50X3RhYmxlLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9Q
T0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0
LmggLW0zMiAtbyBjb21wYXQvZ3JhbnRfdGFibGUuaSBjb21wYXQvZ3JhbnRfdGFibGUuYw0K
c2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC9ncmFudF90YWJsZS5oIHwgdHIgJ1s6bG93ZXI6
XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQv
Z3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvZ3Jh
bnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5j
b21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL2dy
YW50X3RhYmxlLmg+IiA+PmNvbXBhdC9ncmFudF90YWJsZS5oLm5ldzsgXA0KIGVjaG8gIiNw
cmFnbWEgcGFjayg0KSIgPj5jb21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBncmVwIC12
ICdeIyBbMC05XScgY29tcGF0L2dyYW50X3RhYmxlLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8
IHVuaXEgPj5jb21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBh
Y2soKSIgPj5jb21wYXQvZ3JhbnRfdGFibGUuaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyog
JGlkICovIiA+PmNvbXBhdC9ncmFudF90YWJsZS5oLm5ldw0KbXYgLWYgY29tcGF0L2dyYW50
X3RhYmxlLmgubmV3IGNvbXBhdC9ncmFudF90YWJsZS5oDQpta2RpciAtcCBjb21wYXQNCmdy
ZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMva2V4ZWMuaCB8
IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21w
YXQtYnVpbGQtc291cmNlLnB5ID5jb21wYXQva2V4ZWMuYy5uZXcNCm12IC1mIGNvbXBhdC9r
ZXhlYy5jLm5ldyBjb21wYXQva2V4ZWMuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMy
IC1vIGNvbXBhdC9rZXhlYy5pIGNvbXBhdC9rZXhlYy5jDQpzZXQgLWU7IGlkPV8kKGVjaG8g
Y29tcGF0L2tleGVjLmggfCB0ciAnWzpsb3dlcjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwN
CiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNk
ZWZpbmUgJGlkIiA+PmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDx4
ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRl
IDxwdWJsaWMva2V4ZWMuaD4iID4+Y29tcGF0L2tleGVjLmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKDQpIiA+PmNvbXBhdC9rZXhlYy5oLm5ldzsgXA0KIGdyZXAgLXYgJ14jIFsw
LTldJyBjb21wYXQva2V4ZWMuaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBh
dC9rZXhlYy5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9rZXhl
Yy5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0L2tleGVjLmgu
bmV3DQptdiAtZiBjb21wYXQva2V4ZWMuaC5uZXcgY29tcGF0L2tleGVjLmgNCm1rZGlyIC1w
IGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobG9uZyknIHB1Ymxp
Yy9tZW1vcnkuaCB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5jb21wYXQvbWVtb3J5LmMubmV3DQpt
diAtZiBjb21wYXQvbWVtb3J5LmMubmV3IGNvbXBhdC9tZW1vcnkuYw0KZ2NjIC1FIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAt
Zm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVibGljL3hl
bi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9tZW1vcnkuaSBjb21wYXQvbWVtb3J5LmMNCnNl
dCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvbWVtb3J5LmggfCB0ciAnWzpsb3dlcjpdLS8uJyAn
Wzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBhdC9tZW1vcnku
aC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvbWVtb3J5LmgubmV3OyBc
DQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L21lbW9yeS5oLm5l
dzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvbWVtb3J5Lmg+IiA+PmNvbXBhdC9tZW1v
cnkuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L21lbW9yeS5o
Lm5ldzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvbWVtb3J5LmkgfCBcDQogcHl0
aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxk
LWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQvbWVtb3J5LmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKCkiID4+Y29tcGF0L21lbW9yeS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAv
KiAkaWQgKi8iID4+Y29tcGF0L21lbW9yeS5oLm5ldw0KbXYgLWYgY29tcGF0L21lbW9yeS5o
Lm5ldyBjb21wYXQvbWVtb3J5LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUobG9uZyknIHB1YmxpYy9ubWkuaCB8IFwNCiBweXRob24gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNl
LnB5ID5jb21wYXQvbm1pLmMubmV3DQptdiAtZiBjb21wYXQvbm1pLmMubmV3IGNvbXBhdC9u
bWkuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
RFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUg
LWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9ubWkuaSBjb21w
YXQvbm1pLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvbm1pLmggfCB0ciAnWzpsb3dl
cjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBh
dC9ubWkuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvbm1pLmgubmV3
OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L25taS5oLm5l
dzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvbm1pLmg+IiA+PmNvbXBhdC9ubWkuaC5u
ZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L25taS5oLm5ldzsgXA0K
IGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvbm1pLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8
IHVuaXEgPj5jb21wYXQvbm1pLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+
Y29tcGF0L25taS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0
L25taS5oLm5ldw0KbXYgLWYgY29tcGF0L25taS5oLm5ldyBjb21wYXQvbm1pLmgNCm1rZGly
IC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobG9uZyknIHB1
YmxpYy9waHlzZGV2LmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L3BoeXNkZXYuYy5u
ZXcNCm12IC1mIGNvbXBhdC9waHlzZGV2LmMubmV3IGNvbXBhdC9waHlzZGV2LmMNCmdjYyAt
RSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlh
c2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlv
bi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1
aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1E
SEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1
YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvcGh5c2Rldi5pIGNvbXBhdC9waHlz
ZGV2LmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvcGh5c2Rldi5oIHwgdHIgJ1s6bG93
ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21w
YXQvcGh5c2Rldi5oLm5ldzsgXA0KIGVjaG8gIiNkZWZpbmUgJGlkIiA+PmNvbXBhdC9waHlz
ZGV2LmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0
L3BoeXNkZXYuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL3BoeXNkZXYuaD4i
ID4+Y29tcGF0L3BoeXNkZXYuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+
Y29tcGF0L3BoeXNkZXYuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L3Bo
eXNkZXYuaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90
b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9waHlzZGV2Lmgu
bmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+Y29tcGF0L3BoeXNkZXYuaC5uZXc7
IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9waHlzZGV2LmgubmV3DQpt
diAtZiBjb21wYXQvcGh5c2Rldi5oLm5ldyBjb21wYXQvcGh5c2Rldi5oDQpta2RpciAtcCBj
b21wYXQNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMv
cGxhdGZvcm0uaCB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5jb21wYXQvcGxhdGZvcm0uYy5uZXcN
Cm12IC1mIGNvbXBhdC9wbGF0Zm9ybS5jLm5ldyBjb21wYXQvcGxhdGZvcm0uYw0KZ2NjIC1F
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVp
bHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZs
b2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRl
cm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11
bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtRFZFUkJPU0UgLURI
QVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUgLWluY2x1ZGUgcHVi
bGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9wbGF0Zm9ybS5pIGNvbXBhdC9wbGF0
Zm9ybS5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0L3BsYXRmb3JtLmggfCB0ciAnWzps
b3dlcjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNv
bXBhdC9wbGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNkZWZpbmUgJGlkIiA+PmNvbXBhdC9w
bGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNv
bXBhdC9wbGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvcGxhdGZv
cm0uaD4iID4+Y29tcGF0L3BsYXRmb3JtLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNr
KDQpIiA+PmNvbXBhdC9wbGF0Zm9ybS5oLm5ldzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBj
b21wYXQvcGxhdGZvcm0uaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9w
bGF0Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9wbGF0
Zm9ybS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8iID4+Y29tcGF0L3BsYXRm
b3JtLmgubmV3DQptdiAtZiBjb21wYXQvcGxhdGZvcm0uaC5uZXcgY29tcGF0L3BsYXRmb3Jt
LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
bG9uZyknIHB1YmxpYy9zY2hlZC5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC9zY2hl
ZC5jLm5ldw0KbXYgLWYgY29tcGF0L3NjaGVkLmMubmV3IGNvbXBhdC9zY2hlZC5jDQpnY2Mg
LUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1i
dWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGlu
Y2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9TRSAt
REhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVkZSBw
dWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L3NjaGVkLmkgY29tcGF0L3NjaGVk
LmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvc2NoZWQuaCB8IHRyICdbOmxvd2VyOl0t
Ly4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYgJGlkIiA+Y29tcGF0L3Nj
aGVkLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3NjaGVkLmgubmV3
OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L3NjaGVkLmgu
bmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHB1YmxpYy9zY2hlZC5oPiIgPj5jb21wYXQvc2No
ZWQuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L3NjaGVkLmgu
bmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC9zY2hlZC5pIHwgXA0KIHB5dGhv
biAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1o
ZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3NjaGVkLmgubmV3OyBcDQogZWNobyAiI3ByYWdt
YSBwYWNrKCkiID4+Y29tcGF0L3NjaGVkLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRp
ZCAqLyIgPj5jb21wYXQvc2NoZWQuaC5uZXcNCm12IC1mIGNvbXBhdC9zY2hlZC5oLm5ldyBj
b21wYXQvc2NoZWQuaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dV
RVNUX0hBTkRMRShsb25nKScgcHVibGljL3RtZW0uaCB8IFwNCiBweXRob24gL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5ID5j
b21wYXQvdG1lbS5jLm5ldw0KbXYgLWYgY29tcGF0L3RtZW0uYy5uZXcgY29tcGF0L3RtZW0u
Yw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
IC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQg
LW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25l
c3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hy
bw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtRFZF
UkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUgLWlu
Y2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC90bWVtLmkgY29tcGF0
L3RtZW0uYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC90bWVtLmggfCB0ciAnWzpsb3dl
cjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBh
dC90bWVtLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3RtZW0uaC5u
ZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvdG1lbS5o
Lm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvdG1lbS5oPiIgPj5jb21wYXQvdG1l
bS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvdG1lbS5oLm5l
dzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvdG1lbS5pIHwgXA0KIHB5dGhvbiAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1oZWFk
ZXIucHkgfCB1bmlxID4+Y29tcGF0L3RtZW0uaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBh
Y2soKSIgPj5jb21wYXQvdG1lbS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQgKi8i
ID4+Y29tcGF0L3RtZW0uaC5uZXcNCm12IC1mIGNvbXBhdC90bWVtLmgubmV3IGNvbXBhdC90
bWVtLmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9IQU5E
TEUobG9uZyknIHB1YmxpYy90cmFjZS5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC90
cmFjZS5jLm5ldw0KbXYgLWYgY29tcGF0L3RyYWNlLmMubmV3IGNvbXBhdC90cmFjZS5jDQpn
Y2MgLUUgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZu
by1idWlsdGluIC1mbm8tDQpjb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9T
RSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FDQpfUE9JTlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVk
ZSBwdWJsaWMveGVuLWNvbXBhdC5oIC1tMzIgLW8gY29tcGF0L3RyYWNlLmkgY29tcGF0L3Ry
YWNlLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvdHJhY2UuaCB8IHRyICdbOmxvd2Vy
Ol0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYgJGlkIiA+Y29tcGF0
L3RyYWNlLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3RyYWNlLmgu
bmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21wYXQuaD4iID4+Y29tcGF0L3RyYWNl
LmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHB1YmxpYy90cmFjZS5oPiIgPj5jb21wYXQv
dHJhY2UuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L3RyYWNl
LmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC90cmFjZS5pIHwgXA0KIHB5
dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWls
ZC1oZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3RyYWNlLmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKCkiID4+Y29tcGF0L3RyYWNlLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8q
ICRpZCAqLyIgPj5jb21wYXQvdHJhY2UuaC5uZXcNCm12IC1mIGNvbXBhdC90cmFjZS5oLm5l
dyBjb21wYXQvdHJhY2UuaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL3ZjcHUuaCB8IFwNCiBweXRob24gL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtc291cmNlLnB5
ID5jb21wYXQvdmNwdS5jLm5ldw0KbXYgLWYgY29tcGF0L3ZjcHUuYy5uZXcgY29tcGF0L3Zj
cHUuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
RFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFyaWFibGUg
LWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC92Y3B1LmkgY29t
cGF0L3ZjcHUuYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNvbXBhdC92Y3B1LmggfCB0ciAnWzps
b3dlcjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNv
bXBhdC92Y3B1LmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3ZjcHUu
aC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvdmNw
dS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNsdWRlIDxwdWJsaWMvdmNwdS5oPiIgPj5jb21wYXQv
dmNwdS5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvdmNwdS5o
Lm5ldzsgXA0KIGdyZXAgLXYgJ14jIFswLTldJyBjb21wYXQvdmNwdS5pIHwgXA0KIHB5dGhv
biAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1o
ZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3ZjcHUuaC5uZXc7IFwNCiBlY2hvICIjcHJhZ21h
IHBhY2soKSIgPj5jb21wYXQvdmNwdS5oLm5ldzsgXA0KIGVjaG8gIiNlbmRpZiAvKiAkaWQg
Ki8iID4+Y29tcGF0L3ZjcHUuaC5uZXcNCm12IC1mIGNvbXBhdC92Y3B1LmgubmV3IGNvbXBh
dC92Y3B1LmgNCm1rZGlyIC1wIGNvbXBhdA0KZ3JlcCAtdiAnREVGSU5FX1hFTl9HVUVTVF9I
QU5ETEUobG9uZyknIHB1YmxpYy92ZXJzaW9uLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29t
cGF0L3ZlcnNpb24uYy5uZXcNCm12IC1mIGNvbXBhdC92ZXJzaW9uLmMubmV3IGNvbXBhdC92
ZXJzaW9uLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlh
YmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvdmVyc2lv
bi5pIGNvbXBhdC92ZXJzaW9uLmMNCnNldCAtZTsgaWQ9XyQoZWNobyBjb21wYXQvdmVyc2lv
bi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBcDQogZWNobyAiI2lm
bmRlZiAkaWQiID5jb21wYXQvdmVyc2lvbi5oLm5ldzsgXA0KIGVjaG8gIiNkZWZpbmUgJGlk
IiA+PmNvbXBhdC92ZXJzaW9uLmgubmV3OyBcDQogZWNobyAiI2luY2x1ZGUgPHhlbi9jb21w
YXQuaD4iID4+Y29tcGF0L3ZlcnNpb24uaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVi
bGljL3ZlcnNpb24uaD4iID4+Y29tcGF0L3ZlcnNpb24uaC5uZXc7IFwNCiBlY2hvICIjcHJh
Z21hIHBhY2soNCkiID4+Y29tcGF0L3ZlcnNpb24uaC5uZXc7IFwNCiBncmVwIC12ICdeIyBb
MC05XScgY29tcGF0L3ZlcnNpb24uaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNv
bXBhdC92ZXJzaW9uLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+Y29tcGF0
L3ZlcnNpb24uaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC92
ZXJzaW9uLmgubmV3DQptdiAtZiBjb21wYXQvdmVyc2lvbi5oLm5ldyBjb21wYXQvdmVyc2lv
bi5oDQpta2RpciAtcCBjb21wYXQNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExF
KGxvbmcpJyBwdWJsaWMveGVuLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L3hlbi5j
Lm5ldw0KbXYgLWYgY29tcGF0L3hlbi5jLm5ldyBjb21wYXQveGVuLmMNCmdjYyAtRSAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4g
LWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1ESEFTX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94
ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQveGVuLmkgY29tcGF0L3hlbi5jDQpzZXQgLWU7
IGlkPV8kKGVjaG8gY29tcGF0L3hlbi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6
XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQveGVuLmgubmV3OyBcDQog
ZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L3hlbi5oLm5ldzsgXA0KIGVjaG8gIiNpbmNs
dWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC94ZW4uaC5uZXc7IFwNCiBlY2hvICIjaW5j
bHVkZSA8cHVibGljL3hlbi5oPiIgPj5jb21wYXQveGVuLmgubmV3OyBcDQogZWNobyAiI3By
YWdtYSBwYWNrKDQpIiA+PmNvbXBhdC94ZW4uaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05
XScgY29tcGF0L3hlbi5pIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1oZWFkZXIucHkgfCB1bmlxID4+Y29tcGF0L3hl
bi5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC94ZW4uaC5uZXc7
IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC94ZW4uaC5uZXcNCm12IC1m
IGNvbXBhdC94ZW4uaC5uZXcgY29tcGF0L3hlbi5oDQpta2RpciAtcCBjb21wYXQNCmdyZXAg
LXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMveGVuY29tbS5oIHwg
XA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBh
dC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC94ZW5jb21tLmMubmV3DQptdiAtZiBjb21wYXQv
eGVuY29tbS5jLm5ldyBjb21wYXQveGVuY29tbS5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9J
TlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5o
IC1tMzIgLW8gY29tcGF0L3hlbmNvbW0uaSBjb21wYXQveGVuY29tbS5jDQpzZXQgLWU7IGlk
PV8kKGVjaG8gY29tcGF0L3hlbmNvbW0uaCB8IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVy
Ol1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYgJGlkIiA+Y29tcGF0L3hlbmNvbW0uaC5uZXc7
IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQveGVuY29tbS5oLm5ldzsgXA0KIGVj
aG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC94ZW5jb21tLmgubmV3OyBc
DQogZWNobyAiI2luY2x1ZGUgPHB1YmxpYy94ZW5jb21tLmg+IiA+PmNvbXBhdC94ZW5jb21t
LmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKDQpIiA+PmNvbXBhdC94ZW5jb21tLmgu
bmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC94ZW5jb21tLmkgfCBcDQogcHl0
aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxk
LWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQveGVuY29tbS5oLm5ldzsgXA0KIGVjaG8gIiNw
cmFnbWEgcGFjaygpIiA+PmNvbXBhdC94ZW5jb21tLmgubmV3OyBcDQogZWNobyAiI2VuZGlm
IC8qICRpZCAqLyIgPj5jb21wYXQveGVuY29tbS5oLm5ldw0KbXYgLWYgY29tcGF0L3hlbmNv
bW0uaC5uZXcgY29tcGF0L3hlbmNvbW0uaA0KbWtkaXIgLXAgY29tcGF0DQpncmVwIC12ICdE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL3hlbm9wcm9mLmggfCBcDQog
cHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1
aWxkLXNvdXJjZS5weSA+Y29tcGF0L3hlbm9wcm9mLmMubmV3DQptdiAtZiBjb21wYXQveGVu
b3Byb2YuYy5uZXcgY29tcGF0L3hlbm9wcm9mLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lO
VEVSIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0Lmgg
LW0zMiAtbyBjb21wYXQveGVub3Byb2YuaSBjb21wYXQveGVub3Byb2YuYw0Kc2V0IC1lOyBp
ZD1fJChlY2hvIGNvbXBhdC94ZW5vcHJvZi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBw
ZXI6XV9fXycpOyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQveGVub3Byb2YuaC5u
ZXc7IFwNCiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQveGVub3Byb2YuaC5uZXc7IFwN
CiBlY2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQveGVub3Byb2YuaC5u
ZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8cHVibGljL3hlbm9wcm9mLmg+IiA+PmNvbXBhdC94
ZW5vcHJvZi5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQveGVu
b3Byb2YuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L3hlbm9wcm9mLmkg
fCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29t
cGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQveGVub3Byb2YuaC5uZXc7IFwN
CiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQveGVub3Byb2YuaC5uZXc7IFwNCiBl
Y2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC94ZW5vcHJvZi5oLm5ldw0KbXYgLWYg
Y29tcGF0L3hlbm9wcm9mLmgubmV3IGNvbXBhdC94ZW5vcHJvZi5oDQpta2RpciAtcCBjb21w
YXQvYXJjaC14ODYNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBw
dWJsaWMvYXJjaC14ODYveGVuLW1jYS5oIHwgXA0KIHB5dGhvbiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3Rvb2xzL2NvbXBhdC1idWlsZC1zb3VyY2UucHkgPmNvbXBhdC9h
cmNoLXg4Ni94ZW4tbWNhLmMubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5j
Lm5ldyBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5jDQpnY2MgLUUgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1mbm8tDQpjb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FDQpfUE9J
TlRFUiAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zDQpldC12YXJpYWJsZSAtaW5jbHVkZSBwdWJsaWMveGVuLWNvbXBhdC5o
IC1tMzIgLW8gY29tcGF0L2FyY2gteDg2L3hlbi1tY2EuaSBjb21wYXQvYXJjaC14ODYveGVu
LW1jYS5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0L2FyY2gteDg2L3hlbi1tY2EuaCB8
IHRyICdbOmxvd2VyOl0tLy4nICdbOnVwcGVyOl1fX18nKTsgXA0KIGVjaG8gIiNpZm5kZWYg
JGlkIiA+Y29tcGF0L2FyY2gteDg2L3hlbi1tY2EuaC5uZXc7IFwNCiBlY2hvICIjZGVmaW5l
ICRpZCIgPj5jb21wYXQvYXJjaC14ODYveGVuLW1jYS5oLm5ldzsgXA0KIGVjaG8gIiNpbmNs
dWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4tbWNhLmgubmV3OyBc
DQogIFwNCiBlY2hvICIjcHJhZ21hIHBhY2soNCkiID4+Y29tcGF0L2FyY2gteDg2L3hlbi1t
Y2EuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L2FyY2gteDg2L3hlbi1t
Y2EuaSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29s
cy9jb21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4t
bWNhLmgubmV3OyBcDQogZWNobyAiI3ByYWdtYSBwYWNrKCkiID4+Y29tcGF0L2FyY2gteDg2
L3hlbi1tY2EuaC5uZXc7IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9h
cmNoLXg4Ni94ZW4tbWNhLmgubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5o
Lm5ldyBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5oDQpta2RpciAtcCBjb21wYXQvYXJjaC14
ODYNCmdyZXAgLXYgJ0RFRklORV9YRU5fR1VFU1RfSEFORExFKGxvbmcpJyBwdWJsaWMvYXJj
aC14ODYveGVuLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L2FyY2gteDg2L3hlbi5j
Lm5ldw0KbXYgLWYgY29tcGF0L2FyY2gteDg2L3hlbi5jLm5ldyBjb21wYXQvYXJjaC14ODYv
eGVuLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZhcmlhYmxl
IC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvYXJjaC14ODYv
eGVuLmkgY29tcGF0L2FyY2gteDg2L3hlbi5jDQpzZXQgLWU7IGlkPV8kKGVjaG8gY29tcGF0
L2FyY2gteDg2L3hlbi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycpOyBc
DQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQvYXJjaC14ODYveGVuLmgubmV3OyBcDQog
ZWNobyAiI2RlZmluZSAkaWQiID4+Y29tcGF0L2FyY2gteDg2L3hlbi5oLm5ldzsgXA0KIGVj
aG8gIiNpbmNsdWRlIDx4ZW4vY29tcGF0Lmg+IiA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4uaC5u
ZXc7IFwNCiAgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvYXJjaC14ODYv
eGVuLmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC9hcmNoLXg4Ni94ZW4u
aSB8IFwNCiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9j
b21wYXQtYnVpbGQtaGVhZGVyLnB5IHwgdW5pcSA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4uaC5u
ZXc7IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQvYXJjaC14ODYveGVuLmgu
bmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIgPj5jb21wYXQvYXJjaC14ODYveGVu
LmgubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODYveGVuLmgubmV3IGNvbXBhdC9hcmNoLXg4
Ni94ZW4uaA0KbWtkaXIgLXAgY29tcGF0L2FyY2gteDg2DQpncmVwIC12ICdERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRShsb25nKScgcHVibGljL2FyY2gteDg2L3hlbi14ODZfMzIuaCB8IFwN
CiBweXRob24gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi90b29scy9jb21wYXQt
YnVpbGQtc291cmNlLnB5ID5jb21wYXQvYXJjaC14ODYveGVuLXg4Nl8zMi5jLm5ldw0KbXYg
LWYgY29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuYy5uZXcgY29tcGF0L2FyY2gteDg2L3hl
bi14ODZfMzIuYw0KZ2NjIC1FIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLQ0KY29tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0
aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZu
by1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FU
VFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19Y
RU5fXyAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRQ0KX1BPSU5URVIgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtcw0KZXQtdmFy
aWFibGUgLWluY2x1ZGUgcHVibGljL3hlbi1jb21wYXQuaCAtbTMyIC1vIGNvbXBhdC9hcmNo
LXg4Ni94ZW4teDg2XzMyLmkgY29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuYw0Kc2V0IC1l
OyBpZD1fJChlY2hvIGNvbXBhdC9hcmNoLXg4Ni94ZW4teDg2XzMyLmggfCB0ciAnWzpsb3dl
cjpdLS8uJyAnWzp1cHBlcjpdX19fJyk7IFwNCiBlY2hvICIjaWZuZGVmICRpZCIgPmNvbXBh
dC9hcmNoLXg4Ni94ZW4teDg2XzMyLmgubmV3OyBcDQogZWNobyAiI2RlZmluZSAkaWQiID4+
Y29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuaC5uZXc7IFwNCiBlY2hvICIjaW5jbHVkZSA8
eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvYXJjaC14ODYveGVuLXg4Nl8zMi5oLm5ldzsgXA0K
ICBcDQogZWNobyAiI3ByYWdtYSBwYWNrKDQpIiA+PmNvbXBhdC9hcmNoLXg4Ni94ZW4teDg2
XzMyLmgubmV3OyBcDQogZ3JlcCAtdiAnXiMgWzAtOV0nIGNvbXBhdC9hcmNoLXg4Ni94ZW4t
eDg2XzMyLmkgfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
dG9vbHMvY29tcGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQvYXJjaC14ODYv
eGVuLXg4Nl8zMi5oLm5ldzsgXA0KIGVjaG8gIiNwcmFnbWEgcGFjaygpIiA+PmNvbXBhdC9h
cmNoLXg4Ni94ZW4teDg2XzMyLmgubmV3OyBcDQogZWNobyAiI2VuZGlmIC8qICRpZCAqLyIg
Pj5jb21wYXQvYXJjaC14ODYveGVuLXg4Nl8zMi5oLm5ldw0KbXYgLWYgY29tcGF0L2FyY2gt
eDg2L3hlbi14ODZfMzIuaC5uZXcgY29tcGF0L2FyY2gteDg2L3hlbi14ODZfMzIuaA0KbWtk
aXIgLXAgY29tcGF0DQpncmVwIC12ICdERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShsb25nKScg
cHVibGljL2FyY2gteDg2XzMyLmggfCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vdG9vbHMvY29tcGF0LWJ1aWxkLXNvdXJjZS5weSA+Y29tcGF0L2FyY2gt
eDg2XzMyLmMubmV3DQptdiAtZiBjb21wYXQvYXJjaC14ODZfMzIuYy5uZXcgY29tcGF0L2Fy
Y2gteDg2XzMyLmMNCmdjYyAtRSAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby0NCmNvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLURWRVJCT1NFIC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUUNCl9QT0lOVEVSIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXMNCmV0LXZh
cmlhYmxlIC1pbmNsdWRlIHB1YmxpYy94ZW4tY29tcGF0LmggLW0zMiAtbyBjb21wYXQvYXJj
aC14ODZfMzIuaSBjb21wYXQvYXJjaC14ODZfMzIuYw0Kc2V0IC1lOyBpZD1fJChlY2hvIGNv
bXBhdC9hcmNoLXg4Nl8zMi5oIHwgdHIgJ1s6bG93ZXI6XS0vLicgJ1s6dXBwZXI6XV9fXycp
OyBcDQogZWNobyAiI2lmbmRlZiAkaWQiID5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7IFwN
CiBlY2hvICIjZGVmaW5lICRpZCIgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7IFwNCiBl
Y2hvICIjaW5jbHVkZSA8eGVuL2NvbXBhdC5oPiIgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5u
ZXc7IFwNCiAgXA0KIGVjaG8gIiNwcmFnbWEgcGFjayg0KSIgPj5jb21wYXQvYXJjaC14ODZf
MzIuaC5uZXc7IFwNCiBncmVwIC12ICdeIyBbMC05XScgY29tcGF0L2FyY2gteDg2XzMyLmkg
fCBcDQogcHl0aG9uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvY29t
cGF0LWJ1aWxkLWhlYWRlci5weSB8IHVuaXEgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7
IFwNCiBlY2hvICIjcHJhZ21hIHBhY2soKSIgPj5jb21wYXQvYXJjaC14ODZfMzIuaC5uZXc7
IFwNCiBlY2hvICIjZW5kaWYgLyogJGlkICovIiA+PmNvbXBhdC9hcmNoLXg4Nl8zMi5oLm5l
dw0KbXYgLWYgY29tcGF0L2FyY2gteDg2XzMyLmgubmV3IGNvbXBhdC9hcmNoLXg4Nl8zMi5o
DQpleHBvcnQgUFlUSE9OPXB5dGhvbjsgXA0KIGdyZXAgLXYgJ15bICAgICBdKiMnIHhsYXQu
bHN0IHwgXA0KIHdoaWxlIHJlYWQgd2hhdCBuYW1lIGhkcjsgZG8gXA0KICAgICAgICAvYmlu
L3NoIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvZ2V0LWZpZWxkcy5z
aCAiJHdoYXQiIGNvbXBhdF8kbmFtZSAkKGVjaG8gY29tcGF0LyRoZHIgfCBzZWQgJ3MsQGFy
Y2hALHg4Nl8zMixnJykgfHwgZXhpdCAkPzsgXA0KIGRvbmUgPmNvbXBhdC94bGF0LmgubmV3
DQptdiAtZiBjb21wYXQveGxhdC5oLm5ldyBjb21wYXQveGxhdC5oDQpmb3IgaSBpbiBwdWJs
aWMvY2FsbGJhY2suaCBwdWJsaWMvZG9tMF9vcHMuaCBwdWJsaWMvZWxmbm90ZS5oIHB1Ymxp
Yy9ldmVudF9jaGFubmVsLmggcHVibGljL2ZlYXR1cmVzLmggcHVibGljL2dyYW50X3RhYmxl
LmggcHVibGljL2tleGVjLmggcHVibGljL21lbV9ldmVudC5oIHB1YmxpYy9tZW1vcnkuaCBw
dWJsDQppYy9ubWkuaCBwdWJsaWMvcGh5c2Rldi5oIHB1YmxpYy9wbGF0Zm9ybS5oIHB1Ymxp
Yy9zY2hlZC5oIHB1YmxpYy90bWVtLmggcHVibGljL3RyYWNlLmggcHVibGljL3ZjcHUuaCBw
dWJsaWMvdmVyc2lvbi5oIHB1YmxpYy94ZW5jb21tLmggcHVibGljL3hlbi1jb21wYXQuaCBw
dWJsaWMveGVuLmggcHVibGljL3hlDQpub3Byb2YuaCBwdWJsaWMvaHZtL2U4MjAuaCBwdWJs
aWMvaHZtL2h2bV9pbmZvX3RhYmxlLmggcHVibGljL2h2bS9odm1fb3AuaCBwdWJsaWMvaHZt
L2lvcmVxLmggcHVibGljL2h2bS9wYXJhbXMuaCBwdWJsaWMvaW8vYmxraWYuaCBwdWJsaWMv
aW8vY29uc29sZS5oIHB1YmxpYy9pby9mYmlmLmggcHVibGljL2lvDQovZnNpZi5oIHB1Ymxp
Yy9pby9rYmRpZi5oIHB1YmxpYy9pby9saWJ4ZW52Y2hhbi5oIHB1YmxpYy9pby9uZXRpZi5o
IHB1YmxpYy9pby9wY2lpZi5oIHB1YmxpYy9pby9wcm90b2NvbHMuaCBwdWJsaWMvaW8vcmlu
Zy5oIHB1YmxpYy9pby90cG1pZi5oIHB1YmxpYy9pby91c2JpZi5oIHB1YmxpYy9pby92c2Nz
aWlmDQouaCBwdWJsaWMvaW8veGVuYnVzLmggcHVibGljL2lvL3hzX3dpcmUuaDsgZG8gZ2Nj
IC1hbnNpIC1pbmNsdWRlIHN0ZGludC5oIC1XYWxsIC1XIC1XZXJyb3IgLVMgLW8gL2Rldi9u
dWxsIC14YyAkaSB8fCBleGl0IDE7IGVjaG8gJGk7IGRvbmUgPmhlYWRlcnMuY2hrLm5ldw0K
bXYgaGVhZGVycy5jaGsubmV3IGhlYWRlcnMuY2hrDQpybSBjb21wYXQveGVuLmMgY29tcGF0
L2tleGVjLmkgY29tcGF0L3RtZW0uaSBjb21wYXQvYXJjaC14ODZfMzIuYyBjb21wYXQvYXJj
aC14ODYveGVuLXg4Nl8zMi5jIGNvbXBhdC9tZW1vcnkuYyBjb21wYXQvc2NoZWQuYyBjb21w
YXQvdmNwdS5jIGNvbXBhdC94ZW4uaSBjb21wYXQvcGh5c2Rldi5pIGNvbXBhdC90DQpyYWNl
LmkgY29tcGF0L2ZlYXR1cmVzLmkgY29tcGF0L2NhbGxiYWNrLmMgY29tcGF0L2V2ZW50X2No
YW5uZWwuaSBjb21wYXQveGVuY29tbS5pIGNvbXBhdC9hcmNoLXg4Ni94ZW4uaSBjb21wYXQv
ZWxmbm90ZS5jIGNvbXBhdC9hcmNoLXg4Ni94ZW4tbWNhLmkgY29tcGF0L3ZlcnNpb24uaSBj
b21wYXQvcGxhdGZvDQpybS5pIGNvbXBhdC9rZXhlYy5jIGNvbXBhdC90bWVtLmMgY29tcGF0
L25taS5pIGNvbXBhdC9lbGZub3RlLmkgY29tcGF0L3BoeXNkZXYuYyBjb21wYXQvdmNwdS5p
IGNvbXBhdC90cmFjZS5jIGNvbXBhdC9mZWF0dXJlcy5jIGNvbXBhdC9ldmVudF9jaGFubmVs
LmMgY29tcGF0L2dyYW50X3RhYmxlLmkgY29tcGF0DQoveGVuY29tbS5jIGNvbXBhdC9hcmNo
LXg4Ni94ZW4uYyBjb21wYXQvYXJjaC14ODYveGVuLW1jYS5jIGNvbXBhdC92ZXJzaW9uLmMg
Y29tcGF0L2FyY2gteDg2XzMyLmkgY29tcGF0L3BsYXRmb3JtLmMgY29tcGF0L21lbW9yeS5p
IGNvbXBhdC9zY2hlZC5pIGNvbXBhdC9ubWkuYyBjb21wYXQvY2FsbGJhY2suaSBjDQpvbXBh
dC94ZW5vcHJvZi5jIGNvbXBhdC94ZW5vcHJvZi5pIGNvbXBhdC9ncmFudF90YWJsZS5jIGNv
bXBhdC9hcmNoLXg4Ni94ZW4teDg2XzMyLmkNCm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUnDQptYWtlIC1mIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgYXJjaC94ODYgYXNt
LW9mZnNldHMucw0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2Jw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbQ0KbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZW5lcg0KaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25vdQ0Kcy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQw0KUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAuYXNtLW9mZnNldHMucy5kIC1TIC1vIGFzbS1vZmZzZXRzLnMg
eDg2XzY0L2FzbS1vZmZzZXRzLmMNCm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2Jw0KbWFrZSAtZiAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIGluY2x1ZGUvYXNtLXg4Ni9hc20t
b2Zmc2V0cy5oDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4nDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbicNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyBhcmNoL3g4NiAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL3hlbg0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2Jw0KbWFrZSAtZiAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vYXJjaC94ODYvYm9vdCBidWlsdF9pbi5vDQptYWtlWzRdOiBFbnRlcmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYv
Ym9vdCcNCm1ha2UgLWYgYnVpbGQzMi5tayByZWxvYy5TDQptYWtlWzVdOiBFbnRlcmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvYm9v
dCcNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW0zMiAtbWFyY2g9aTY4NiAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAtZm5vLXN0YWMNCmstcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV2Vy
cm9yIC1mbm8tYnVpbHRpbiAtbXNvZnQtZmxvYXQgIC1jIC1mcGljIHJlbG9jLmMgLW8gcmVs
b2Mubw0KbGQgLW1lbGZfaTM4NiAtTiAtVHRleHQgMCAtbyByZWxvYy5sbmsgcmVsb2Mubw0K
b2JqY29weSAtTyBiaW5hcnkgcmVsb2MubG5rIHJlbG9jLmJpbg0KKG9kIC12IC10IHggcmVs
b2MuYmluIHwgdHIgLXMgJyAnIHwgYXdrICdOUiA+IDEge3ByaW50IHN9IHtzPSQwfScgfCBc
DQogc2VkICdzLyAvLDB4L2cnIHwgc2VkICdzLywweCQvLycgfCBzZWQgJ3MvXlswLTldKiwv
IC5sb25nIC8nKSA+cmVsb2MuUw0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvYm9vdCcNCmdjYyAtRF9fQVNT
RU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1m
bm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmhlYWQuby5kIC1j
IGhlYWQuUyAtbyBoZWFkLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4u
byBoZWFkLm8NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2Jvb3QnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9hcmNoL3g4Ni9lZmkgYnVpbHRfaW4ubw0KbWFrZVs0XTogRW50ZXJpbmcgZGly
ZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2VmaScN
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnN0dWIuby5k
IC1mc2hvcnQtd2NoYXIgLWMgc3R1Yi5jIC1vIHN0dWIubw0KbGQgICAgLW1lbGZfeDg2XzY0
ICAtciAtbyBidWlsdF9pbi5vIHN0dWIubw0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvZWZpJw0KbWFrZSAt
ZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vY29tbW9uIGJ1aWx0X2luLm8NCm1ha2VbNF06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jb21t
b24nDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5iaXRt
YXAuby5kIC1jIGJpdG1hcC5jIC1vIGJpdG1hcC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jb3JlX3Bhcmtpbmcuby5kIC1jIGNvcmVfcGFya2lu
Zy5jIC1vIGNvcmVfcGFya2luZy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5jcHUuby5kIC1jIGNwdS5jIC1vIGNwdS5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVwb29sLm8uZCAtYyBjcHVwb29s
LmMgLW8gY3B1cG9vbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5kb21jdGwuby5kIC1jIGRvbWN0bC5jIC1vIGRvbWN0bC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kb21haW4uby5kIC1jIGRvbWFp
bi5jIC1vIGRvbWFpbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5ldmVudF9jaGFubmVsLm8uZCAtYyBldmVudF9jaGFubmVsLmMgLW8gZXZlbnRf
Y2hhbm5lbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5ncmFudF90YWJsZS5vLmQgLWMgZ3JhbnRfdGFibGUuYyAtbyBncmFudF90YWJsZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pcnEuby5kIC1j
IGlycS5jIC1vIGlycS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5rZXJuZWwuby5kIC1jIGtlcm5lbC5jIC1vIGtlcm5lbC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5rZXloYW5kbGVyLm8uZCAtYyBr
ZXloYW5kbGVyLmMgLW8ga2V5aGFuZGxlci5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5rZXhlYy5vLmQgLWMga2V4ZWMuYyAtbyBrZXhlYy5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5saWIuby5kIC1j
IGxpYi5jIC1vIGxpYi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5tZW1vcnkuby5kIC1jIG1lbW9yeS5jIC1vIG1lbW9yeS5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tdWx0aWNhbGwuby5kIC1jIG11
bHRpY2FsbC5jIC1vIG11bHRpY2FsbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC5ub3RpZmllci5vLmQgLWMgbm90aWZpZXIuYyAtbyBub3RpZmll
ci5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wYWdl
X2FsbG9jLm8uZCAtYyBwYWdlX2FsbG9jLmMgLW8gcGFnZV9hbGxvYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wcmVlbXB0Lm8uZCAtYyBwcmVl
bXB0LmMgLW8gcHJlZW1wdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5yYW5nZXNldC5vLmQgLWMgcmFuZ2VzZXQuYyAtbyByYW5nZXNldC5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zY2hlZF9jcmVk
aXQuby5kIC1jIHNjaGVkX2NyZWRpdC5jIC1vIHNjaGVkX2NyZWRpdC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zY2hlZF9jcmVkaXQyLm8uZCAt
YyBzY2hlZF9jcmVkaXQyLmMgLW8gc2NoZWRfY3JlZGl0Mi5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zY2hlZF9zZWRmLm8uZCAtYyBzY2hlZF9z
ZWRmLmMgLW8gc2NoZWRfc2VkZi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5zY2hlZF9hcmluYzY1My5vLmQgLWMgc2NoZWRfYXJpbmM2NTMuYyAt
byBzY2hlZF9hcmluYzY1My5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5zY2hlZHVsZS5vLmQgLWMgc2NoZWR1bGUuYyAtbyBzY2hlZHVsZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zaHV0ZG93bi5v
LmQgLWMgc2h1dGRvd24uYyAtbyBzaHV0ZG93bi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zb2Z0aXJxLm8uZCAtYyBzb2Z0aXJxLmMgLW8gc29m
dGlycS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5z
b3J0Lm8uZCAtYyBzb3J0LmMgLW8gc29ydC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5zcGlubG9jay5vLmQgLWMgc3BpbmxvY2suYyAtbyBzcGlu
bG9jay5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5z
dG9wX21hY2hpbmUuby5kIC1jIHN0b3BfbWFjaGluZS5jIC1vIHN0b3BfbWFjaGluZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zdHJpbmcuby5k
IC1jIHN0cmluZy5jIC1vIHN0cmluZy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC5zeW1ib2xzLm8uZCAtYyBzeW1ib2xzLmMgLW8gc3ltYm9scy5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zeXNjdGwu
by5kIC1jIHN5c2N0bC5jIC1vIHN5c2N0bC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC50YXNrbGV0Lm8uZCAtYyB0YXNrbGV0LmMgLW8gdGFza2xl
dC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50aW1l
Lm8uZCAtYyB0aW1lLmMgLW8gdGltZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC50aW1lci5vLmQgLWMgdGltZXIuYyAtbyB0aW1lci5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50cmFjZS5vLmQgLWMg
dHJhY2UuYyAtbyB0cmFjZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC52ZXJzaW9uLm8uZCAtYyB2ZXJzaW9uLmMgLW8gdmVyc2lvbi5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC52c3ByaW50Zi5vLmQg
LWMgdnNwcmludGYuYyAtbyB2c3ByaW50Zi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC53YWl0Lm8uZCAtYyB3YWl0LmMgLW8gd2FpdC5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54bWFsbG9jX3Rsc2Yu
by5kIC1jIHhtYWxsb2NfdGxzZi5jIC1vIHhtYWxsb2NfdGxzZi5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5yY3VwZGF0ZS5vLmQgLWMgcmN1cGRh
dGUuYyAtbyByY3VwZGF0ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC50bWVtLm8uZCAtYyB0bWVtLmMgLW8gdG1lbS5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50bWVtX3hlbi5vLmQgLWMgdG1lbV94
ZW4uYyAtbyB0bWVtX3hlbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5yYWRpeC10cmVlLm8uZCAtYyByYWRpeC10cmVlLmMgLW8gcmFkaXgtdHJl
ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5yYnRy
ZWUuby5kIC1jIHJidHJlZS5jIC1vIHJidHJlZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5sem8uby5kIC1jIGx6by5jIC1vIGx6by5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54ZW5vcHJvZi5vLmQg
LWMgeGVub3Byb2YuYyAtbyB4ZW5vcHJvZi5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgY29tcGF0IGJ1aWx0X2luLm8NCm1ha2VbNV06
IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9j
b21tb24vY29tcGF0Jw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAuZG9tYWluLm8uZCAtYyBkb21haW4uYyAtbyBkb21haW4ubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAua2VybmVsLm8uZCAtYyBrZXJuZWwu
YyAtbyBrZXJuZWwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAubWVtb3J5Lm8uZCAtYyBtZW1vcnkuYyAtbyBtZW1vcnkubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubXVsdGljYWxsLm8uZCAtYyBtdWx0
aWNhbGwuYyAtbyBtdWx0aWNhbGwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAueGxhdC5vLmQgLWMgeGxhdC5jIC1vIHhsYXQubw0KZ2NjIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGlu
IC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUg
LVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5z
IC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndp
bmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9T
RSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudG1lbV94ZW4uby5kIC1jIHRt
ZW1feGVuLmMgLW8gdG1lbV94ZW4ubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWls
dF9pbi5vIGRvbWFpbi5vIGtlcm5lbC5vIG1lbW9yeS5vIG11bHRpY2FsbC5vIHhsYXQubyB0
bWVtX3hlbi5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9jb21tb24vY29tcGF0Jw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIGh2bSBidWlsdF9pbi5vDQptYWtlWzVd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
Y29tbW9uL2h2bScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnNhdmUuby5kIC1jIHNhdmUuYyAtbyBzYXZlLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAg
LXIgLW8gYnVpbHRfaW4ubyBzYXZlLm8NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1vbi9odm0nDQptYWtlIC1mIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgbGliZWxmIGJ1aWx0
X2luLm8NCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9jb21tb24vbGliZWxmJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAubGliZWxmLXRvb2xzLm8uZCAtYyBsaWJlbGYtdG9vbHMu
YyAtbyBsaWJlbGYtdG9vbHMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAubGliZWxmLWxvYWRlci5vLmQgLWMgbGliZWxmLWxvYWRlci5jIC1vIGxp
YmVsZi1sb2FkZXIubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAubGliZWxmLWRvbWluZm8uby5kIC1jIGxpYmVsZi1kb21pbmZvLmMgLW8gbGliZWxm
LWRvbWluZm8ubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBsaWJlbGYtdGVtcC5vIGxp
YmVsZi10b29scy5vIGxpYmVsZi1sb2FkZXIubyBsaWJlbGYtZG9taW5mby5vDQpvYmpjb3B5
IC0tcmVuYW1lLXNlY3Rpb24gLnRleHQ9LmluaXQudGV4dCAtLXJlbmFtZS1zZWN0aW9uIC5k
YXRhPS5pbml0LmRhdGEgbGliZWxmLXRlbXAubyBsaWJlbGYubw0KbGQgICAgLW1lbGZfeDg2
XzY0ICAtciAtbyBidWlsdF9pbi5vIGxpYmVsZi5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jb21tb24vbGliZWxmJw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZGVjb21wcmVz
cy5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgZGVjb21wcmVzcy5jIC1vIGRlY29tcHJl
c3Mubw0Kb2JqZHVtcCAtaCBkZWNvbXByZXNzLm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCos
MCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBj
YXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8
LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwN
CiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBkZWNvbXByZXNzLm86JG5h
bWUgaXMgMHgkc3oiID4mMjsgXA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHgg
KyAxKTs7IFwNCiAgICAgICAgZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2Vj
dGlvbiAucm9kYXRhPS5pbml0LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3Ry
MS4xPS5pbml0LnJvZGF0YS5zdHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEu
Mj0uaW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEu
ND0uaW5pdC5yb2RhdGEuc3RyMS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9
LmluaXQucm9kYXRhLnN0cjEuOCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5k
YXRhLnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJl
bC5sb2NhbCAtLXJlbmENCm1lLXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVs
LnJvIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVs
LnJvLmxvY2FsIGRlY29tcHJlc3MubyBkZWNvbXByZXNzLmluaXQubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYnVuemlwMi5vLmQgLURJTklUX1NF
Q1RJT05TX09OTFkgLWMgYnVuemlwMi5jIC1vIGJ1bnppcDIubw0Kb2JqZHVtcCAtaCBidW56
aXAyLm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4
IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAg
ICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8LmJzcykgXA0KICAgICAgICAgICAgICAg
IHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwNCiAgICAgICAgICAgICAgICBlY2hvICJF
cnJvcjogc2l6ZSBvZiBidW56aXAyLm86JG5hbWUgaXMgMHgkc3oiID4mMjsgXA0KICAgICAg
ICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAxKTs7IFwNCiAgICAgICAgZXNhYzsgXA0K
IGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhPS5pbml0LnJvZGF0YSAt
LXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4xPS5pbml0LnJvZGF0YS5zdHIxLjEgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0uaW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVu
YW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0uaW5pdC5yb2RhdGEuc3RyMS40IC0tcmVu
YW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9LmluaXQucm9kYXRhLnN0cjEuOCAtLXJlbmFt
ZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5k
YXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5sb2NhbCAtLXJlbmENCm1lLXNlY3Rpb24g
LmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEu
cmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJvLmxvY2FsIGJ1bnppcDIubyBidW56aXAy
LmluaXQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRl
ZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJ
QlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5f
XyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAu
dW54ei5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgdW54ei5jIC1vIHVueHoubw0Kb2Jq
ZHVtcCAtaCB1bnh6Lm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCosMCxnO3B9JyB8IHdoaWxl
IHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBjYXNlICIkbmFtZSIgaW4g
XA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8LmJzcykgXA0KICAgICAg
ICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwNCiAgICAgICAgICAgICAg
ICBlY2hvICJFcnJvcjogc2l6ZSBvZiB1bnh6Lm86JG5hbWUgaXMgMHgkc3oiID4mMjsgXA0K
ICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAxKTs7IFwNCiAgICAgICAgZXNh
YzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhPS5pbml0LnJv
ZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4xPS5pbml0LnJvZGF0YS5zdHIx
LjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0uaW5pdC5yb2RhdGEuc3RyMS4y
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0uaW5pdC5yb2RhdGEuc3RyMS40
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9LmluaXQucm9kYXRhLnN0cjEuOCAt
LXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1zZWN0
aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5sb2NhbCAtLXJlbmENCm1lLXNl
Y3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rpb24g
LmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJvLmxvY2FsIHVueHoubyB1bnh6
LmluaXQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRl
ZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJ
QlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5f
XyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAu
dW5sem1hLm8uZCAtRElOSVRfU0VDVElPTlNfT05MWSAtYyB1bmx6bWEuYyAtbyB1bmx6bWEu
bw0Kb2JqZHVtcCAtaCB1bmx6bWEubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiwwLGc7cH0n
IHwgd2hpbGUgcmVhZCBpZHggbmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNhc2UgIiRu
YW1lIiBpbiBcDQogICAgICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwuYnNzKSBc
DQogICAgICAgICAgICAgICAgdGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0KICAgICAg
ICAgICAgICAgIGVjaG8gIkVycm9yOiBzaXplIG9mIHVubHptYS5vOiRuYW1lIGlzIDB4JHN6
IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0ICQoZXhwciAkaWR4ICsgMSk7OyBcDQog
ICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0
YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMT0uaW5pdC5y
b2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjI9LmluaXQucm9k
YXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQoxLjQ9LmluaXQucm9k
YXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44PS5pbml0LnJvZGF0
YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWw9LmluaXQuZGF0YS5yZWwgLS1y
ZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9LmluaXQuZGF0YS5yZWwubG9jYWwgLS1y
ZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJlbC5ybyAtLXJlbmFt
ZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0uaW5pdC5kYXRhLnJlbC5yby5sb2NhbCB1
bmx6bWEubyB1bmx6bWEuaW5pdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC51bmx6by5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgdW5sem8u
YyAtbyB1bmx6by5vDQpvYmpkdW1wIC1oIHVubHpvLm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiB1bmx6by5vOiRuYW1l
IGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0ICQoZXhwciAkaWR4ICsg
MSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5IC0tcmVuYW1lLXNlY3Rp
b24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEu
MT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjI9
LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQoxLjQ9
LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44PS5p
bml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWw9LmluaXQuZGF0
YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9LmluaXQuZGF0YS5yZWwu
bG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJlbC5y
byAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0uaW5pdC5kYXRhLnJlbC5y
by5sb2NhbCB1bmx6by5vIHVubHpvLmluaXQubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAt
byBidWlsdF9pbi5vIGJpdG1hcC5vIGNvcmVfcGFya2luZy5vIGNwdS5vIGNwdXBvb2wubyBk
b21jdGwubyBkb21haW4ubyBldmVudF9jaGFubmVsLm8gZ3JhbnRfdGFibGUubyBpcnEubyBr
ZXJuZWwubyBrZXloYW5kbGVyLm8ga2V4ZWMubyBsaWIubyBtZW1vcnkubyBtdQ0KbHRpY2Fs
bC5vIG5vdGlmaWVyLm8gcGFnZV9hbGxvYy5vIHByZWVtcHQubyByYW5nZXNldC5vIHNjaGVk
X2NyZWRpdC5vIHNjaGVkX2NyZWRpdDIubyBzY2hlZF9zZWRmLm8gc2NoZWRfYXJpbmM2NTMu
byBzY2hlZHVsZS5vIHNodXRkb3duLm8gc29mdGlycS5vIHNvcnQubyBzcGlubG9jay5vIHN0
b3BfbWFjaGluZQ0KLm8gc3RyaW5nLm8gc3ltYm9scy5vIHN5c2N0bC5vIHRhc2tsZXQubyB0
aW1lLm8gdGltZXIubyB0cmFjZS5vIHZlcnNpb24ubyB2c3ByaW50Zi5vIHdhaXQubyB4bWFs
bG9jX3Rsc2YubyByY3VwZGF0ZS5vIHRtZW0ubyB0bWVtX3hlbi5vIHJhZGl4LXRyZWUubyBy
YnRyZWUubyBsem8ubyB4ZW5vcHJvZi5vIGNvbQ0KcGF0L2J1aWx0X2luLm8gaHZtL2J1aWx0
X2luLm8gbGliZWxmL2J1aWx0X2luLm8gZGVjb21wcmVzcy5pbml0Lm8gYnVuemlwMi5pbml0
Lm8gdW54ei5pbml0Lm8gdW5sem1hLmluaXQubyB1bmx6by5pbml0Lm8NCm1ha2VbNF06IExl
YXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1v
bicNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAt
QyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMgYnVpbHRfaW4ubw0K
bWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2RyaXZlcnMnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vUnVsZXMubWsgLUMgY2hhciBidWlsdF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9jaGFyJw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuY29uc29sZS5v
LmQgLWMgY29uc29sZS5jIC1vIGNvbnNvbGUubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAubnMxNjU1MC5vLmQgLWMgbnMxNjU1MC5jIC1vIG5zMTY1
NTAubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuc2Vy
aWFsLm8uZCAtYyBzZXJpYWwuYyAtbyBzZXJpYWwubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAt
ciAtbyBidWlsdF9pbi5vIGNvbnNvbGUubyBuczE2NTUwLm8gc2VyaWFsLm8NCm1ha2VbNV06
IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2Ry
aXZlcnMvY2hhcicNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9S
dWxlcy5tayAtQyBjcHVmcmVxIGJ1aWx0X2luLm8NCm1ha2VbNV06IEVudGVyaW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2NwdWZyZXEn
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVx
Lm8uZCAtYyBjcHVmcmVxLmMgLW8gY3B1ZnJlcS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxX29uZGVtYW5kLm8uZCAtYyBjcHVmcmVx
X29uZGVtYW5kLmMgLW8gY3B1ZnJlcV9vbmRlbWFuZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxX21pc2NfZ292ZXJub3JzLm8uZCAt
YyBjcHVmcmVxX21pc2NfZ292ZXJub3JzLmMgLW8gY3B1ZnJlcV9taXNjX2dvdmVybm9ycy5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC51dGlsaXR5
Lm8uZCAtYyB1dGlsaXR5LmMgLW8gdXRpbGl0eS5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1y
IC1vIGJ1aWx0X2luLm8gY3B1ZnJlcS5vIGNwdWZyZXFfb25kZW1hbmQubyBjcHVmcmVxX21p
c2NfZ292ZXJub3JzLm8gdXRpbGl0eS5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2NwdWZyZXEnDQptYWtl
IC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgcGNpIGJ1
aWx0X2luLm8NCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3BjaScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnBjaS5vLmQgLWMgcGNpLmMgLW8gcGNpLm8NCmxkICAg
IC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyBwY2kubw0KbWFrZVs1XTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9w
Y2knDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
LUMgcGFzc3Rocm91Z2ggYnVpbHRfaW4ubw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gn
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pb21tdS5v
LmQgLWMgaW9tbXUuYyAtbyBpb21tdS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC5pby5vLmQgLWMgaW8uYyAtbyBpby5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wY2kuby5kIC1jIHBjaS5jIC1vIHBj
aS5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
LUMgdnRkIGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Z0ZCcNCmdj
YyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlh
c2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlv
bi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8t
YnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBp
bmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQt
ZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAt
RFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlvbW11Lm8uZCAt
YyBpb21tdS5jIC1vIGlvbW11Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLmRtYXIuby5kIC1jIGRtYXIuYyAtbyBkbWFyLm8NCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnV0aWxzLm8uZCAtYyB1dGlscy5j
IC1vIHV0aWxzLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnFpbnZhbC5vLmQgLWMgcWludmFsLmMgLW8gcWludmFsLm8NCmdjYyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5v
LWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJy
b3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5v
LXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5v
LXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRh
YmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURI
QVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmludHJlbWFwLm8uZCAtYyBpbnRyZW1h
cC5jIC1vIGludHJlbWFwLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLnF1aXJrcy5vLmQgLWMgcXVpcmtzLmMgLW8gcXVpcmtzLm8NCm1ha2UgLWYg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyB4ODYgYnVpbHRf
aW4ubw0KbWFrZVs3XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkL3g4NicNCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnZ0ZC5vLmQgLWMgdnRkLmMgLW8g
dnRkLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmF0
cy5vLmQgLWMgYXRzLmMgLW8gYXRzLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVp
bHRfaW4ubyB2dGQubyBhdHMubw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQveDg2
Jw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGlvbW11Lm8gZG1hci5v
IHV0aWxzLm8gcWludmFsLm8gaW50cmVtYXAubyBxdWlya3MubyB4ODYvYnVpbHRfaW4ubw0K
bWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgYW1kIGJ1aWx0X2luLm8NCm1ha2VbNl06
IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9k
cml2ZXJzL3Bhc3N0aHJvdWdoL2FtZCcNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3Ry
aWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVk
dW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVy
LWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
ICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3Rv
ciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8t
c3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNf
VklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0
ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFT
X1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BP
SU5URVIgLU1NRCAtTUYgLmlvbW11X2luaXQuby5kIC1jIGlvbW11X2luaXQuYyAtbyBpb21t
dV9pbml0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmlvbW11X21hcC5vLmQgLWMgaW9tbXVfbWFwLmMgLW8gaW9tbXVfbWFwLm8NCmdjYyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRp
biAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRl
IC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9h
dCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJu
cyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53
aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJP
U0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnBjaV9hbWRfaW9tbXUuby5k
IC1jIHBjaV9hbWRfaW9tbXUuYyAtbyBwY2lfYW1kX2lvbW11Lm8NCmdjYyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5v
LWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJy
b3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5v
LXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5v
LXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRh
YmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURI
QVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlvbW11X2ludHIuby5kIC1jIGlvbW11
X2ludHIuYyAtbyBpb21tdV9pbnRyLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3Ry
aWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVk
dW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVy
LWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
ICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3Rv
ciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8t
c3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNf
VklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0
ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFT
X1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BP
SU5URVIgLU1NRCAtTUYgLmlvbW11X2NtZC5vLmQgLWMgaW9tbXVfY21kLmMgLW8gaW9tbXVf
Y21kLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlv
bW11X2d1ZXN0Lm8uZCAtYyBpb21tdV9ndWVzdC5jIC1vIGlvbW11X2d1ZXN0Lm8NCmdjYyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVp
bHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmlvbW11X2RldGVjdC5v
LmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgaW9tbXVfZGV0ZWN0LmMgLW8gaW9tbXVfZGV0
ZWN0Lm8NCm9iamR1bXAgLWggaW9tbXVfZGV0ZWN0Lm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBpb21tdV9kZXRlY3Qu
bzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAkKGV4cHIg
JGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0
YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEu
c3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsPS5p
bml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5pbml0LmRh
dGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89LmluaXQuZGF0
YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0
YS5yZWwucm8ubG9jYWwgaW9tbXVfZGV0ZWN0Lm8gaW9tbXVfZGV0ZWN0LmluaXQubw0KZ2Nj
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1i
dWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGlu
Y2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0
LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1l
eHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91
cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1E
VkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaW9tbXVfYWNwaS5v
LmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgaW9tbXVfYWNwaS5jIC1vIGlvbW11X2FjcGku
bw0Kb2JqZHVtcCAtaCBpb21tdV9hY3BpLm8gfCBzZWQgLW4gJy9bMC05XS97cywwMCosMCxn
O3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAgICBjYXNl
ICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRhLip8LmJz
cykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7IFwNCiAg
ICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBpb21tdV9hY3BpLm86JG5hbWUg
aXMgMHgkc3oiID4mMjsgXA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAx
KTs7IFwNCiAgICAgICAgZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlv
biAucm9kYXRhPS5pbml0LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4x
PS5pbml0LnJvZGF0YS5zdHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0u
aW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0u
aW5pdC5yb2RhdGEuc3RyMS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9Lmlu
aXQucm9kYXRhLnN0cjEuOCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRh
LnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5s
b2NhbCAtLXJlbmENCm1lLXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJv
IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJv
LmxvY2FsIGlvbW11X2FjcGkubyBpb21tdV9hY3BpLmluaXQubw0KbGQgICAgLW1lbGZfeDg2
XzY0ICAtciAtbyBidWlsdF9pbi5vIGlvbW11X2luaXQubyBpb21tdV9tYXAubyBwY2lfYW1k
X2lvbW11Lm8gaW9tbXVfaW50ci5vIGlvbW11X2NtZC5vIGlvbW11X2d1ZXN0Lm8gaW9tbXVf
ZGV0ZWN0LmluaXQubyBpb21tdV9hY3BpLmluaXQubw0KbWFrZVs2XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9wYXNzdGhy
b3VnaC9hbWQnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVs
ZXMubWsgLUMgeDg2IGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3g4
NicNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmF0cy5v
LmQgLWMgYXRzLmMgLW8gYXRzLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRf
aW4ubyBhdHMubw0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC94ODYnDQpsZCAgICAtbWVs
Zl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8gaW9tbXUubyBpby5vIHBjaS5vIHZ0ZC9idWls
dF9pbi5vIGFtZC9idWlsdF9pbi5vIHg4Ni9idWlsdF9pbi5vDQptYWtlWzVdOiBMZWF2aW5n
IGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL3Bh
c3N0aHJvdWdoJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1
bGVzLm1rIC1DIGFjcGkgYnVpbHRfaW4ubw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaScNCmdjYyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVp
bHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnRhYmxlcy5vLmQgLWMg
dGFibGVzLmMgLW8gdGFibGVzLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLm51bWEuby5kIC1jIG51bWEuYyAtbyBudW1hLm8NCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm9zbC5vLmQgLWMgb3NsLmMgLW8g
b3NsLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnBt
c3RhdC5vLmQgLWMgcG1zdGF0LmMgLW8gcG1zdGF0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmh3cmVncy5vLmQgLWMgaHdyZWdzLmMgLW8gaHdy
ZWdzLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnJl
Ym9vdC5vLmQgLWMgcmVib290LmMgLW8gcmVib290Lm8NCm1ha2UgLWYgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyB0YWJsZXMgYnVpbHRfaW4ubw0KbWFr
ZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2RyaXZlcnMvYWNwaS90YWJsZXMnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC50YnV0aWxzLm8uZCAtYyB0YnV0aWxzLmMgLW8gdGJ1dGlscy5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50YmZhZHQu
by5kIC1ESU5JVF9TRUNUSU9OU19PTkxZIC1jIHRiZmFkdC5jIC1vIHRiZmFkdC5vDQpvYmpk
dW1wIC1oIHRiZmFkdC5vIHwgc2VkIC1uICcvWzAtOV0ve3MsMDAqLDAsZztwfScgfCB3aGls
ZSByZWFkIGlkeCBuYW1lIHN6IHJlc3Q7IGRvIFwNCiAgICAgICAgY2FzZSAiJG5hbWUiIGlu
IFwNCiAgICAgICAgLnRleHR8LnRleHQuKnwuZGF0YXwuZGF0YS4qfC5ic3MpIFwNCiAgICAg
ICAgICAgICAgICB0ZXN0ICRzeiAhPSAwIHx8IGNvbnRpbnVlOyBcDQogICAgICAgICAgICAg
ICAgZWNobyAiRXJyb3I6IHNpemUgb2YgdGJmYWR0Lm86JG5hbWUgaXMgMHgkc3oiID4mMjsg
XA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHByICRpZHggKyAxKTs7IFwNCiAgICAgICAg
ZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhPS5pbml0
LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4xPS5pbml0LnJvZGF0YS5z
dHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMj0uaW5pdC5yb2RhdGEuc3Ry
MS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHINCjEuND0uaW5pdC5yb2RhdGEuc3Ry
MS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjg9LmluaXQucm9kYXRhLnN0cjEu
OCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0uaW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1z
ZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5kYXRhLnJlbC5sb2NhbCAtLXJlbmENCm1l
LXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRhdGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rp
b24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRhdGEucmVsLnJvLmxvY2FsIHRiZmFkdC5v
IHRiZmFkdC5pbml0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRl
Y2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1w
aXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5l
cmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4
Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGlj
IC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElU
WV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAt
RF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJP
VUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1N
RCAtTUYgLnRiaW5zdGFsLm8uZCAtRElOSVRfU0VDVElPTlNfT05MWSAtYyB0Ymluc3RhbC5j
IC1vIHRiaW5zdGFsLm8NCm9iamR1bXAgLWggdGJpbnN0YWwubyB8IHNlZCAtbiAnL1swLTld
L3tzLDAwKiwwLGc7cH0nIHwgd2hpbGUgcmVhZCBpZHggbmFtZSBzeiByZXN0OyBkbyBcDQog
ICAgICAgIGNhc2UgIiRuYW1lIiBpbiBcDQogICAgICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8
LmRhdGEuKnwuYnNzKSBcDQogICAgICAgICAgICAgICAgdGVzdCAkc3ogIT0gMCB8fCBjb250
aW51ZTsgXA0KICAgICAgICAgICAgICAgIGVjaG8gIkVycm9yOiBzaXplIG9mIHRiaW5zdGFs
Lm86JG5hbWUgaXMgMHgkc3oiID4mMjsgXA0KICAgICAgICAgICAgICAgIGV4aXQgJChleHBy
ICRpZHggKyAxKTs7IFwNCiAgICAgICAgZXNhYzsgXA0KIGRvbmUNCm9iamNvcHkgLS1yZW5h
bWUtc2VjdGlvbiAucm9kYXRhPS5pbml0LnJvZGF0YSAtLXJlbmFtZS1zZWN0aW9uIC5yb2Rh
dGEuc3RyMS4xPS5pbml0LnJvZGF0YS5zdHIxLjEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRh
LnN0cjEuMj0uaW5pdC5yb2RhdGEuc3RyMS4yIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5z
dHINCjEuND0uaW5pdC5yb2RhdGEuc3RyMS40IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5z
dHIxLjg9LmluaXQucm9kYXRhLnN0cjEuOCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbD0u
aW5pdC5kYXRhLnJlbCAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5sb2NhbD0uaW5pdC5k
YXRhLnJlbC5sb2NhbCAtLXJlbmENCm1lLXNlY3Rpb24gLmRhdGEucmVsLnJvPS5pbml0LmRh
dGEucmVsLnJvIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLnJvLmxvY2FsPS5pbml0LmRh
dGEucmVsLnJvLmxvY2FsIHRiaW5zdGFsLm8gdGJpbnN0YWwuaW5pdC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50YnhmYWNlLm8uZCAtRElOSVRf
U0VDVElPTlNfT05MWSAtYyB0YnhmYWNlLmMgLW8gdGJ4ZmFjZS5vDQpvYmpkdW1wIC1oIHRi
eGZhY2UubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiwwLGc7cH0nIHwgd2hpbGUgcmVhZCBp
ZHggbmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNhc2UgIiRuYW1lIiBpbiBcDQogICAg
ICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwuYnNzKSBcDQogICAgICAgICAgICAg
ICAgdGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0KICAgICAgICAgICAgICAgIGVjaG8g
IkVycm9yOiBzaXplIG9mIHRieGZhY2UubzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAg
ICAgICAgICAgICAgZXhpdCAkKGV4cHIgJGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBc
DQogZG9uZQ0Kb2JqY29weSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRh
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAt
LXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVu
YW1lLXNlY3Rpb24gLmRhdGEucmVsPS5pbml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24g
LmRhdGEucmVsLmxvY2FsPS5pbml0LmRhdGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlv
biAuZGF0YS5yZWwucm89LmluaXQuZGF0YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0
YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0YS5yZWwucm8ubG9jYWwgdGJ4ZmFjZS5vIHRieGZh
Y2UuaW5pdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC50Ynhmcm9vdC5vLmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgdGJ4ZnJvb3QuYyAtbyB0
Ynhmcm9vdC5vDQpvYmpkdW1wIC1oIHRieGZyb290Lm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiB0Ynhmcm9vdC5vOiRu
YW1lIGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0ICQoZXhwciAkaWR4
ICsgMSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5IC0tcmVuYW1lLXNl
Y3Rpb24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cjEuMT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIx
LjI9LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQox
LjQ9LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44
PS5pbml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWw9LmluaXQu
ZGF0YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9LmluaXQuZGF0YS5y
ZWwubG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJl
bC5ybyAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0uaW5pdC5kYXRhLnJl
bC5yby5sb2NhbCB0Ynhmcm9vdC5vIHRieGZyb290LmluaXQubw0KbGQgICAgLW1lbGZfeDg2
XzY0ICAtciAtbyBidWlsdF9pbi5vIHRidXRpbHMubyB0YmZhZHQuaW5pdC5vIHRiaW5zdGFs
LmluaXQubyB0YnhmYWNlLmluaXQubyB0Ynhmcm9vdC5pbml0Lm8NCm1ha2VbNl06IExlYXZp
bmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMv
YWNwaS90YWJsZXMnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
UnVsZXMubWsgLUMgdXRpbGl0aWVzIGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2FjcGkv
dXRpbGl0aWVzJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMg
LWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0
aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZu
by1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FU
VFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19Y
RU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
eGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0gg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1N
RiAudXRnbG9iYWwuby5kIC1jIHV0Z2xvYmFsLmMgLW8gdXRnbG9iYWwubw0KZ2NjIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGlu
IC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUg
LVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5z
IC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndp
bmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9T
RSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudXRtaXNjLm8uZCAtRElOSVRf
U0VDVElPTlNfT05MWSAtYyB1dG1pc2MuYyAtbyB1dG1pc2Mubw0Kb2JqZHVtcCAtaCB1dG1p
c2MubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiwwLGc7cH0nIHwgd2hpbGUgcmVhZCBpZHgg
bmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNhc2UgIiRuYW1lIiBpbiBcDQogICAgICAg
IC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwuYnNzKSBcDQogICAgICAgICAgICAgICAg
dGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0KICAgICAgICAgICAgICAgIGVjaG8gIkVy
cm9yOiBzaXplIG9mIHV0bWlzYy5vOiRuYW1lIGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAg
ICAgICAgICBleGl0ICQoZXhwciAkaWR4ICsgMSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBk
b25lDQpvYmpjb3B5IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1y
ZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuMT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVu
YW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjI9LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGEuc3RyDQoxLjQ9LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS44PS5pbml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUt
c2VjdGlvbiAuZGF0YS5yZWw9LmluaXQuZGF0YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0
YS5yZWwubG9jYWw9LmluaXQuZGF0YS5yZWwubG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5k
YXRhLnJlbC5ybz0uaW5pdC5kYXRhLnJlbC5ybyAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJl
bC5yby5sb2NhbD0uaW5pdC5kYXRhLnJlbC5yby5sb2NhbCB1dG1pc2MubyB1dG1pc2MuaW5p
dC5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8gdXRnbG9iYWwubyB1
dG1pc2MuaW5pdC5vDQptYWtlWzZdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9kcml2ZXJzL2FjcGkvdXRpbGl0aWVzJw0KbWFrZSAtZiAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIGFwZWkgYnVpbHRf
aW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaS9hcGVpJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZXJzdC5vLmQgLWMgZXJzdC5jIC1vIGVyc3Qubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYXBlaS1iYXNl
Lm8uZCAtYyBhcGVpLWJhc2UuYyAtbyBhcGVpLWJhc2Uubw0KZ2NjIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0K
b21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAt
V25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3Rh
Y2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVk
LXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVz
IC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0K
X0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05G
SUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYXBlaS1pby5vLmQgLWMgYXBlaS1pby5jIC1v
IGFwZWktaW8ubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGVyc3Qu
byBhcGVpLWJhc2UubyBhcGVpLWlvLm8NCm1ha2VbNl06IExlYXZpbmcgZGlyZWN0b3J5IGAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaS9hcGVpJw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIHRhYmxlcy5vIG51bWEubyBvc2wu
byBwbXN0YXQubyBod3JlZ3MubyByZWJvb3QubyB0YWJsZXMvYnVpbHRfaW4ubyB1dGlsaXRp
ZXMvYnVpbHRfaW4ubyBhcGVpL2J1aWx0X2luLm8NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2RyaXZlcnMvYWNwaScNCm1h
a2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAtQyB2aWRl
byBidWlsdF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vZHJpdmVycy92aWRlbycNCmdjYyAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMN
Cm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJl
ZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMN
Cl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnZnYS5vLmQgLWMgdmdhLmMgLW8gdmdhLm8N
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmZvbnRfOHgx
NC5vLmQgLWMgZm9udF84eDE0LmMgLW8gZm9udF84eDE0Lm8NCmdjYyAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMN
Cm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJl
ZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMN
Cl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmZvbnRfOHgxNi5vLmQgLWMgZm9udF84eDE2
LmMgLW8gZm9udF84eDE2Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLmZvbnRfOHg4Lm8uZCAtYyBmb250Xzh4OC5jIC1vIGZvbnRfOHg4Lm8NCmdj
YyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlh
c2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlv
bi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8t
YnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBp
bmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQt
ZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAt
RFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnZlc2Euby5kIC1j
IHZlc2EuYyAtbyB2ZXNhLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4u
byB2Z2EubyBmb250Xzh4MTQubyBmb250Xzh4MTYubyBmb250Xzh4OC5vIHZlc2Eubw0KbWFr
ZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vZHJpdmVycy92aWRlbycNCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4u
byBjaGFyL2J1aWx0X2luLm8gY3B1ZnJlcS9idWlsdF9pbi5vIHBjaS9idWlsdF9pbi5vIHBh
c3N0aHJvdWdoL2J1aWx0X2luLm8gYWNwaS9idWlsdF9pbi5vIHZpZGVvL2J1aWx0X2luLm8N
Cm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2RyaXZlcnMnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vUnVsZXMubWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94c20gYnVp
bHRfaW4ubw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3hzbScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLnhzbV9jb3JlLm8uZCAtYyB4c21fY29yZS5jIC1vIHhzbV9jb3JlLm8N
CmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyB4c21fY29yZS5vDQptYWtl
WzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi94c20nDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMu
bWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NiBidWlsdF9p
bi5vDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vYXJjaC94ODYnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5hcGljLm8uZCAtYyBhcGljLmMgLW8gYXBpYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5iaXRvcHMuby5kIC1jIGJpdG9w
cy5jIC1vIGJpdG9wcy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5jb21wYXQuby5kIC1jIGNvbXBhdC5jIC1vIGNvbXBhdC5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kZWJ1Zy5vLmQgLWMgZGVidWcu
YyAtbyBkZWJ1Zy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5kZWxheS5vLmQgLWMgZGVsYXkuYyAtbyBkZWxheS5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kb21jdGwuby5kIC1jIGRvbWN0bC5jIC1v
IGRvbWN0bC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5kb21haW4uby5kIC1jIGRvbWFpbi5jIC1vIGRvbWFpbi5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5lODIwLm8uZCAtYyBlODIwLmMgLW8gZTgy
MC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5leHRh
YmxlLm8uZCAtYyBleHRhYmxlLmMgLW8gZXh0YWJsZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5mbHVzaHRsYi5vLmQgLWMgZmx1c2h0bGIuYyAt
byBmbHVzaHRsYi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5wbGF0Zm9ybV9oeXBlcmNhbGwuby5kIC1jIHBsYXRmb3JtX2h5cGVyY2FsbC5jIC1v
IHBsYXRmb3JtX2h5cGVyY2FsbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5pMzg3Lm8uZCAtYyBpMzg3LmMgLW8gaTM4Ny5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pODI1OS5vLmQgLWMgaTgyNTku
YyAtbyBpODI1OS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5pb19hcGljLm8uZCAtYyBpb19hcGljLmMgLW8gaW9fYXBpYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tc2kuby5kIC1jIG1zaS5jIC1v
IG1zaS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5p
b3BvcnRfZW11bGF0ZS5vLmQgLWMgaW9wb3J0X2VtdWxhdGUuYyAtbyBpb3BvcnRfZW11bGF0
ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pcnEu
by5kIC1jIGlycS5jIC1vIGlycS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVu
ZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1h
cml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNo
LWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3Ig
LWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNz
ZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJ
U0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRp
bmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19Q
QVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lO
VEVSIC1NTUQgLU1GIC5taWNyb2NvZGVfYW1kLm8uZCAtYyBtaWNyb2NvZGVfYW1kLmMgLW8g
bWljcm9jb2RlX2FtZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5taWNyb2NvZGVfaW50ZWwuby5kIC1jIG1pY3JvY29kZV9pbnRlbC5jIC1vIG1p
Y3JvY29kZV9pbnRlbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5taWNyb2NvZGUuby5kIC1jIG1pY3JvY29kZS5jIC1vIG1pY3JvY29kZS5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tbS5vLmQgLWMg
bW0uYyAtbyBtbS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5tcHBhcnNlLm8uZCAtYyBtcHBhcnNlLmMgLW8gbXBwYXJzZS5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ubWkuby5kIC1jIG5taS5jIC1v
IG5taS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5u
dW1hLm8uZCAtYyBudW1hLmMgLW8gbnVtYS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5wY2kuby5kIC1jIHBjaS5jIC1vIHBjaS5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wZXJjcHUuby5kIC1jIHBl
cmNwdS5jIC1vIHBlcmNwdS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5waHlzZGV2Lm8uZCAtYyBwaHlzZGV2LmMgLW8gcGh5c2Rldi5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zZXR1cC5vLmQgLWMg
c2V0dXAuYyAtbyBzZXR1cC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFu
dC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0
aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdl
DQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAt
ZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC5zaHV0ZG93bi5vLmQgLWMgc2h1dGRvd24uYyAtbyBzaHV0ZG93bi5vDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zbXAuby5kIC1j
IHNtcC5jIC1vIHNtcC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5zbXBib290Lm8uZCAtYyBzbXBib290LmMgLW8gc21wYm9vdC5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zcmF0Lm8uZCAtYyBzcmF0
LmMgLW8gc3JhdC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5zdHJpbmcuby5kIC1jIHN0cmluZy5jIC1vIHN0cmluZy5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5zeXNjdGwuby5kIC1jIHN5c2N0bC5j
IC1vIHN5c2N0bC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC50aW1lLm8uZCAtYyB0aW1lLmMgLW8gdGltZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50cmFjZS5vLmQgLWMgdHJhY2UuYyAtbyB0cmFj
ZS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC50cmFw
cy5vLmQgLWMgdHJhcHMuYyAtbyB0cmFwcy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC51c2VyY29weS5vLmQgLWMgdXNlcmNvcHkuYyAtbyB1c2Vy
Y29weS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54
ODZfZW11bGF0ZS5vLmQgLWMgeDg2X2VtdWxhdGUuYyAtbyB4ODZfZW11bGF0ZS5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tYWNoaW5lX2tleGVj
Lm8uZCAtYyBtYWNoaW5lX2tleGVjLmMgLW8gbWFjaGluZV9rZXhlYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcmFzaC5vLmQgLWMgY3Jhc2gu
YyAtbyBjcmFzaC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC50Ym9vdC5vLmQgLWMgdGJvb3QuYyAtbyB0Ym9vdC5vDQpnY2MgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1j
DQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1z
dGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1y
ZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJs
ZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFT
DQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ocGV0Lm8uZCAtYyBocGV0LmMgLW8gaHBl
dC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC54c3Rh
dGUuby5kIC1jIHhzdGF0ZS5jIC1vIHhzdGF0ZS5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgYWNwaSBidWlsdF9pbi5vDQptYWtlWzVd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYvYWNwaScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRl
Y2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1w
aXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5l
cmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4
Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGlj
IC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElU
WV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAt
RF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJP
VUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1N
RCAtTUYgLmxpYi5vLmQgLWMgbGliLmMgLW8gbGliLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnBvd2VyLm8uZCAtYyBwb3dlci5jIC1vIHBvd2Vy
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnN1c3Bl
bmQuby5kIC1jIHN1c3BlbmQuYyAtbyBzdXNwZW5kLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNwdV9pZGxlLm8uZCAtYyBjcHVfaWRsZS5jIC1v
IGNwdV9pZGxlLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLmNwdWlkbGVfbWVudS5vLmQgLWMgY3B1aWRsZV9tZW51LmMgLW8gY3B1aWRsZV9tZW51
Lm8NCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAt
QyBjcHVmcmVxIGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEnDQpn
Y2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5v
LWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNv
ZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVk
LWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpu
b3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRl
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmgg
LURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxLm8u
ZCAtYyBjcHVmcmVxLmMgLW8gY3B1ZnJlcS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5wb3dlcm5vdy5vLmQgLWMgcG93ZXJub3cuYyAtbyBwb3dl
cm5vdy5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8gY3B1ZnJlcS5v
IHBvd2Vybm93Lm8NCm1ha2VbNl06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2FjcGkvY3B1ZnJlcScNCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmJvb3Quby5kIC1ESU5JVF9TRUNU
SU9OU19PTkxZIC1jIGJvb3QuYyAtbyBib290Lm8NCm9iamR1bXAgLWggYm9vdC5vIHwgc2Vk
IC1uICcvWzAtOV0ve3MsMDAqLDAsZztwfScgfCB3aGlsZSByZWFkIGlkeCBuYW1lIHN6IHJl
c3Q7IGRvIFwNCiAgICAgICAgY2FzZSAiJG5hbWUiIGluIFwNCiAgICAgICAgLnRleHR8LnRl
eHQuKnwuZGF0YXwuZGF0YS4qfC5ic3MpIFwNCiAgICAgICAgICAgICAgICB0ZXN0ICRzeiAh
PSAwIHx8IGNvbnRpbnVlOyBcDQogICAgICAgICAgICAgICAgZWNobyAiRXJyb3I6IHNpemUg
b2YgYm9vdC5vOiRuYW1lIGlzIDB4JHN6IiA+JjI7IFwNCiAgICAgICAgICAgICAgICBleGl0
ICQoZXhwciAkaWR4ICsgMSk7OyBcDQogICAgICAgIGVzYWM7IFwNCiBkb25lDQpvYmpjb3B5
IC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YT0uaW5pdC5yb2RhdGEgLS1yZW5hbWUtc2VjdGlv
biAucm9kYXRhLnN0cjEuMT0uaW5pdC5yb2RhdGEuc3RyMS4xIC0tcmVuYW1lLXNlY3Rpb24g
LnJvZGF0YS5zdHIxLjI9LmluaXQucm9kYXRhLnN0cjEuMiAtLXJlbmFtZS1zZWN0aW9uIC5y
b2RhdGEuc3RyDQoxLjQ9LmluaXQucm9kYXRhLnN0cjEuNCAtLXJlbmFtZS1zZWN0aW9uIC5y
b2RhdGEuc3RyMS44PS5pbml0LnJvZGF0YS5zdHIxLjggLS1yZW5hbWUtc2VjdGlvbiAuZGF0
YS5yZWw9LmluaXQuZGF0YS5yZWwgLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwubG9jYWw9
LmluaXQuZGF0YS5yZWwubG9jYWwgLS1yZW5hDQptZS1zZWN0aW9uIC5kYXRhLnJlbC5ybz0u
aW5pdC5kYXRhLnJlbC5ybyAtLXJlbmFtZS1zZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbD0u
aW5pdC5kYXRhLnJlbC5yby5sb2NhbCBib290Lm8gYm9vdC5pbml0Lm8NCmdjYyAtRF9fQVNT
RU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1m
bm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXgg
aW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29m
dC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25v
dXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUg
L21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLndha2V1cF9wcm90
Lm8uZCAtYyB3YWtldXBfcHJvdC5TIC0NCm8gd2FrZXVwX3Byb3Qubw0KbGQgICAgLW1lbGZf
eDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGxpYi5vIHBvd2VyLm8gc3VzcGVuZC5vIGNwdV9p
ZGxlLm8gY3B1aWRsZV9tZW51Lm8gY3B1ZnJlcS9idWlsdF9pbi5vIGJvb3QuaW5pdC5vIHdh
a2V1cF9wcm90Lm8NCm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2FjcGknDQptYWtlIC1mIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgY3B1IGJ1aWx0X2luLm8NCm1ha2Vb
NV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9hcmNoL3g4Ni9jcHUnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC5hbWQuby5kIC1jIGFtZC5jIC1vIGFtZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpv
bW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1X
bm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFj
ay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQt
em9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMg
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpf
QUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJ
R19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jb21tb24uby5kIC1jIGNvbW1vbi5jIC1vIGNv
bW1vbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5p
bnRlbC5vLmQgLWMgaW50ZWwuYyAtbyBpbnRlbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pbnRlbF9jYWNoZWluZm8uby5kIC1jIGludGVsX2Nh
Y2hlaW5mby5jIC1vIGludGVsX2NhY2hlaW5mby5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgbWNoZWNrIGJ1aWx0X2luLm8NCm1ha2Vb
Nl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9hcmNoL3g4Ni9jcHUvbWNoZWNrJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAuYW1kX25vbmZhdGFsLm8uZCAtYyBhbWRfbm9uZmF0YWwuYyAtbyBh
bWRfbm9uZmF0YWwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAuazcuby5kIC1jIGs3LmMgLW8gazcubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAuYW1kX2s4Lm8uZCAtYyBhbWRfazguYyAtbyBhbWRfazgu
bw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJl
Zml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQg
LW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25l
c3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hy
bw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5j
bHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZp
Zy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYW1kX2Yx
MC5vLmQgLWMgYW1kX2YxMC5jIC1vIGFtZF9mMTAubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubWN0ZWxlbS5vLmQgLWMgbWN0ZWxlbS5jIC1vIG1j
dGVsZW0ubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRl
ZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJ
QlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5f
XyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAu
bWNlLm8uZCAtYyBtY2UuYyAtbyBtY2Uubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdy
ZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50
ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAubWNlLWFwZWkuby5kIC1jIG1jZS1hcGVpLmMgLW8gbWNlLWFw
ZWkubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubWNl
X2ludGVsLm8uZCAtYyBtY2VfaW50ZWwuYyAtbyBtY2VfaW50ZWwubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubWNlX2FtZF9xdWlya3Muby5kIC1j
IG1jZV9hbWRfcXVpcmtzLmMgLW8gbWNlX2FtZF9xdWlya3Mubw0KZ2NjIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8t
Yw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJv
ciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8t
c3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFi
bGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
Uw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubm9uLWZhdGFsLm8uZCAtYyBub24tZmF0
YWwuYyAtbyBub24tZmF0YWwubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAudm1jZS5vLmQgLWMgdm1jZS5jIC1vIHZtY2Uubw0KbGQgICAgLW1lbGZf
eDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGFtZF9ub25mYXRhbC5vIGs3Lm8gYW1kX2s4Lm8g
YW1kX2YxMC5vIG1jdGVsZW0ubyBtY2UubyBtY2UtYXBlaS5vIG1jZV9pbnRlbC5vIG1jZV9h
bWRfcXVpcmtzLm8gbm9uLWZhdGFsLm8gdm1jZS5vDQptYWtlWzZdOiBMZWF2aW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9jcHUvbWNo
ZWNrJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1r
IC1DIG10cnIgYnVpbHRfaW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2NwdS9tdHJyJw0KZ2NjIC1P
MSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5n
IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFm
dGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWls
dGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1
ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZs
b2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRl
cm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11
bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVS
Qk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZ2VuZXJpYy5vLmQgLWMg
Z2VuZXJpYy5jIC1vIGdlbmVyaWMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAubWFpbi5vLmQgLWMgbWFpbi5jIC1vIG1haW4ubw0KbGQgICAgLW1l
bGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGdlbmVyaWMubyBtYWluLm8NCm1ha2VbNl06
IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2Fy
Y2gveDg2L2NwdS9tdHJyJw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5v
IGFtZC5vIGNvbW1vbi5vIGludGVsLm8gaW50ZWxfY2FjaGVpbmZvLm8gbWNoZWNrL2J1aWx0
X2luLm8gbXRyci9idWlsdF9pbi5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9jcHUnDQptYWtlIC1mIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsgLUMgZ2VuYXBpYyBidWls
dF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvZ2VuYXBpYycNCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmJpZ3NtcC5vLmQgLWMgYmlnc21wLmMgLW8gYmln
c21wLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0
aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMg
LVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5
bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9j
b25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLngy
YXBpYy5vLmQgLWMgeDJhcGljLmMgLW8geDJhcGljLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmRlZmF1bHQuby5kIC1jIGRlZmF1bHQuYyAtbyBk
ZWZhdWx0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmRlbGl2ZXJ5Lm8uZCAtYyBkZWxpdmVyeS5jIC1vIGRlbGl2ZXJ5Lm8NCmdjYyAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAt
Zm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAt
Zm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5k
LXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnByb2JlLm8uZCAtYyBwcm9iZS5j
IC1vIHByb2JlLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnN1bW1pdC5vLmQgLWMgc3VtbWl0LmMgLW8gc3VtbWl0Lm8NCmxkICAgIC1tZWxmX3g4
Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyBiaWdzbXAubyB4MmFwaWMubyBkZWZhdWx0Lm8gZGVs
aXZlcnkubyBwcm9iZS5vIHN1bW1pdC5vDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4Ni9nZW5hcGljJw0KbWFr
ZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIGh2bSBi
dWlsdF9pbi5vDQptYWtlWzVdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZtJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuYXNpZC5vLmQgLWMgYXNpZC5jIC1vIGFzaWQubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZW11bGF0ZS5v
LmQgLWMgZW11bGF0ZS5jIC1vIGVtdWxhdGUubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUg
LW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0ND
X0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkg
LURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJB
TUVfUE9JTlRFUiAtTU1EIC1NRiAuaHBldC5vLmQgLWMgaHBldC5jIC1vIGhwZXQubw0KZ2Nj
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1i
dWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGlu
Y2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0
LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1l
eHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91
cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1E
VkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaHZtLm8uZCAtYyBo
dm0uYyAtbyBodm0ubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVj
bHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBp
cGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVy
aWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZ
X0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1E
X19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9V
R0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1E
IC1NRiAuaTgyNTQuby5kIC1jIGk4MjU0LmMgLW8gaTgyNTQubw0KZ2NjIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8t
Yw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJv
ciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8t
c3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFi
bGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
Uw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaW50ZXJjZXB0Lm8uZCAtYyBpbnRlcmNl
cHQuYyAtbyBpbnRlcmNlcHQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAuaW8uby5kIC1jIGlvLmMgLW8gaW8ubw0KZ2NjIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0K
b21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAt
V25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3Rh
Y2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVk
LXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVz
IC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0K
X0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05G
SUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaXJxLm8uZCAtYyBpcnEuYyAtbyBpcnEubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubXRyci5vLmQg
LWMgbXRyci5jIC1vIG10cnIubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAubmVzdGVkaHZtLm8uZCAtYyBuZXN0ZWRodm0uYyAtbyBuZXN0ZWRodm0u
bw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJl
Zml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQg
LW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25l
c3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hy
bw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5j
bHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZp
Zy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAucG10aW1l
ci5vLmQgLWMgcG10aW1lci5jIC1vIHBtdGltZXIubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21t
b24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25v
LXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2st
cHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpv
bmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1E
R0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FD
UEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdf
RlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAucXVpcmtzLm8uZCAtYyBxdWlya3MuYyAtbyBxdWly
a3Mubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAucnRj
Lm8uZCAtYyBydGMuYyAtbyBydGMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAuc2F2ZS5vLmQgLWMgc2F2ZS5jIC1vIHNhdmUubw0KZ2NjIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGlu
IC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUg
LVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5z
IC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndp
bmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9T
RSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50
ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuc3RkdmdhLm8uZCAtYyBzdGR2
Z2EuYyAtbyBzdGR2Z2Eubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQt
ZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGgg
LXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0K
bmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8t
ZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZw
aWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklM
SVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1n
IC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RI
Uk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAt
TU1EIC1NRiAudmlvYXBpYy5vLmQgLWMgdmlvYXBpYy5jIC1vIHZpb2FwaWMubw0KZ2NjIC1P
MSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5n
IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFm
dGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWls
dGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1
ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZs
b2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRl
cm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11
bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVS
Qk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudmlyaWRpYW4uby5kIC1j
IHZpcmlkaWFuLmMgLW8gdmlyaWRpYW4ubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdy
ZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50
ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAudmxhcGljLm8uZCAtYyB2bGFwaWMuYyAtbyB2bGFwaWMubw0K
Z2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZu
by1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4
IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1z
b2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3Rl
ZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0K
bm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudm1zaS5vLmQg
LWMgdm1zaS5jIC1vIHZtc2kubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAudnBpYy5vLmQgLWMgdnBpYy5jIC1vIHZwaWMubw0KZ2NjIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1m
bm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1t
bm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAt
REhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudnB0Lm8uZCAtYyB2cHQuYyAtbyB2
cHQubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAudnBt
dS5vLmQgLWMgdnBtdS5jIC1vIHZwbXUubw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIHN2bSBidWlsdF9pbi5vDQptYWtlWzZdOiBFbnRl
cmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94
ODYvaHZtL3N2bScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLmFzaWQuby5kIC1jIGFzaWQuYyAtbyBhc2lkLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmVtdWxhdGUuby5kIC1jIGVtdWxhdGUuYyAtbyBl
bXVsYXRlLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmludHIuby5kIC1jIGludHIuYyAtbyBpbnRyLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLm5lc3RlZHN2bS5vLmQgLWMgbmVzdGVkc3ZtLmMgLW8g
bmVzdGVkc3ZtLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnN2bS5vLmQgLWMgc3ZtLmMgLW8gc3ZtLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnN2bWRlYnVnLm8uZCAtYyBzdm1kZWJ1Zy5jIC1vIHN2
bWRlYnVnLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LnZtY2Iuby5kIC1jIHZtY2IuYyAtbyB2bWNiLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnZwbXUuby5kIC1jIHZwbXUuYyAtbyB2cG11Lm8NCmdj
YyAtRF9fQVNTRU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZh
dWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9u
cyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1h
c3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJV
VEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18g
LWluY2x1ZGUgL21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVu
L2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmVu
dHJ5Lm8uZCAtYyBlbnRyeS5TIC1vIGVudHJ5Lm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIg
LW8gYnVpbHRfaW4ubyBhc2lkLm8gZW11bGF0ZS5vIGludHIubyBuZXN0ZWRzdm0ubyBzdm0u
byBzdm1kZWJ1Zy5vIHZtY2IubyB2cG11Lm8gZW50cnkubw0KbWFrZVs2XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZt
L3N2bScNCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5t
ayAtQyB2bXggYnVpbHRfaW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2h2bS92bXgnDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5pbnRyLm8uZCAtYyBpbnRy
LmMgLW8gaW50ci5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5yZWFsbW9kZS5vLmQgLWMgcmVhbG1vZGUuYyAtbyByZWFsbW9kZS5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC52bWNzLm8uZCAtYyB2bWNz
LmMgLW8gdm1jcy5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC52bXguby5kIC1jIHZteC5jIC1vIHZteC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1v
biAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8t
cG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1w
cm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9u
ZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURH
Q0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQ
SSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19G
UkFNRV9QT0lOVEVSIC1NTUQgLU1GIC52cG11X2NvcmUyLm8uZCAtYyB2cG11X2NvcmUyLmMg
LW8gdnBtdV9jb3JlMi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1k
ZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAt
cGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpu
ZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1l
eGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBp
YyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJ
VFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcg
LURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhS
T1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1N
TUQgLU1GIC52dm14Lm8uZCAtYyB2dm14LmMgLW8gdnZteC5vDQpnY2MgLURfX0FTU0VNQkxZ
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
DQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1
aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1
ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
DQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5lbnRyeS5vLmQgLWMgZW50
cnkuUyAtbyBlbnRyeS5vDQpsZCAgICAtbWVsZl94ODZfNjQgIC1yIC1vIGJ1aWx0X2luLm8g
aW50ci5vIHJlYWxtb2RlLm8gdm1jcy5vIHZteC5vIHZwbXVfY29yZTIubyB2dm14Lm8gZW50
cnkubw0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZtL3ZteCcNCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIg
LW8gYnVpbHRfaW4ubyBhc2lkLm8gZW11bGF0ZS5vIGhwZXQubyBodm0ubyBpODI1NC5vIGlu
dGVyY2VwdC5vIGlvLm8gaXJxLm8gbXRyci5vIG5lc3RlZGh2bS5vIHBtdGltZXIubyBxdWly
a3MubyBydGMubyBzYXZlLm8gc3RkdmdhLm8gdmlvYXBpYy5vIHZpcmlkaWFuLm8NCiB2bGFw
aWMubyB2bXNpLm8gdnBpYy5vIHZwdC5vIHZwbXUubyBzdm0vYnVpbHRfaW4ubyB2bXgvYnVp
bHRfaW4ubw0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvaHZtJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1DIG1tIGJ1aWx0X2luLm8NCm1ha2VbNV06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNo
L3g4Ni9tbScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LnBhZ2luZy5vLmQgLWMgcGFnaW5nLmMgLW8gcGFnaW5nLm8NCmdjYyAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMN
Cm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJl
ZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMN
Cl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnAybS5vLmQgLWMgcDJtLmMgLW8gcDJtLm8N
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnAybS1wdC5v
LmQgLWMgcDJtLXB0LmMgLW8gcDJtLXB0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3Rl
Y3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1t
bm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19I
QVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1u
b3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1E
SEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1F
X1BPSU5URVIgLU1NRCAtTUYgLnAybS1lcHQuby5kIC1jIHAybS1lcHQuYyAtbyBwMm0tZXB0
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnAybS1w
b2Quby5kIC1jIHAybS1wb2QuYyAtbyBwMm0tcG9kLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9t
bW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVdu
by1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9h
c20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16
b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAt
REdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9B
Q1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklH
X0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmd1ZXN0X3dhbGtfMi5vLmQgLURHVUVTVF9QQUdJ
TkdfTEVWRUxTPTIgLWMgZ3Vlc3Rfd2Fsay5jIC1vIGd1ZXN0X3dhbGtfMi5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ndWVzdF93YWxrXzMuby5k
IC1ER1VFU1RfUEFHSU5HX0xFVkVMUz0zIC1jIGd1ZXN0X3dhbGsuYyAtbyBndWVzdF93YWxr
XzMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuZ3Vl
c3Rfd2Fsa180Lm8uZCAtREdVRVNUX1BBR0lOR19MRVZFTFM9NCAtYyBndWVzdF93YWxrLmMg
LW8gZ3Vlc3Rfd2Fsa180Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLm1lbV9ldmVudC5vLmQgLWMgbWVtX2V2ZW50LmMgLW8gbWVtX2V2ZW50Lm8N
CmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJh
dGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1m
bm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZp
eCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1t
c29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8N
Cm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1
ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcu
aCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm1lbV9wYWdp
bmcuby5kIC1jIG1lbV9wYWdpbmcuYyAtbyBtZW1fcGFnaW5nLm8NCmdjYyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5v
LWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJy
b3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5v
LXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5v
LXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRh
YmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURI
QVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1E
Q09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm1lbV9zaGFyaW5nLm8uZCAtYyBtZW1f
c2hhcmluZy5jIC1vIG1lbV9zaGFyaW5nLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2
L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3Rl
Y3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1t
bm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19I
QVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1u
b3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1E
SEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1F
X1BPSU5URVIgLU1NRCAtTUYgLm1lbV9hY2Nlc3Muby5kIC1jIG1lbV9hY2Nlc3MuYyAtbyBt
ZW1fYWNjZXNzLm8NCm1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9S
dWxlcy5tayAtQyBzaGFkb3cgYnVpbHRfaW4ubw0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L21tL3NoYWRv
dycNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNvbW1v
bi5vLmQgLWMgY29tbW9uLmMgLW8gY29tbW9uLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLmd1ZXN0XzIuby5kIC1ER1VFU1RfUEFHSU5HX0xFVkVM
Uz0yIC1jIG11bHRpLmMgLW8gZ3Vlc3RfMi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5ndWVzdF8zLm8uZCAtREdVRVNUX1BBR0lOR19MRVZFTFM9
MyAtYyBtdWx0aS5jIC1vIGd1ZXN0XzMubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdy
ZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50
ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1u
by1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAuZ3Vlc3RfNC5vLmQgLURHVUVTVF9QQUdJTkdfTEVWRUxTPTQg
LWMgbXVsdGkuYyAtbyBndWVzdF80Lm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gYnVp
bHRfaW4ubyBjb21tb24ubyBndWVzdF8yLm8gZ3Vlc3RfMy5vIGd1ZXN0XzQubw0KbWFrZVs2
XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYvbW0vc2hhZG93Jw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL1J1bGVzLm1rIC1DIGhhcCBidWlsdF9pbi5vDQptYWtlWzZdOiBFbnRlcmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvbW0v
aGFwJw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRo
cHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1
bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVU
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAt
aW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAuaGFw
Lm8uZCAtYyBoYXAuYyAtbyBoYXAubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1
bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXIt
YXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUg
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUv
YXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9y
IC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1z
c2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19W
SVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3Rk
aW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNf
UEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9J
TlRFUiAtTU1EIC1NRiAuZ3Vlc3Rfd2Fsa18ybGV2ZWwuby5kIC1ER1VFU1RfUEFHSU5HX0xF
VkVMUz0yIC1jIGd1ZXN0X3dhbGsuYyAtbyBndWVzdF93YWxrXzJsZXZlbC5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5ndWVzdF93YWxrXzNsZXZl
bC5vLmQgLURHVUVTVF9QQUdJTkdfTEVWRUxTPTMgLWMgZ3Vlc3Rfd2Fsay5jIC1vIGd1ZXN0
X3dhbGtfM2xldmVsLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAt
ZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNl
dC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRl
Y2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1w
aXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5l
cmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4
Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGlj
IC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElU
WV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAt
RF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJP
VUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1N
RCAtTUYgLmd1ZXN0X3dhbGtfNGxldmVsLm8uZCAtREdVRVNUX1BBR0lOR19MRVZFTFM9NCAt
YyBndWVzdF93YWxrLmMgLW8gZ3Vlc3Rfd2Fsa180bGV2ZWwubw0KZ2NjIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8t
Yw0Kb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJv
ciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUgIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8t
c3RhY2stcHJvdGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFi
bGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
Uw0KX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURD
T05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAubmVzdGVkX2hhcC5vLmQgLWMgbmVzdGVk
X2hhcC5jIC1vIG5lc3RlZF9oYXAubw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWls
dF9pbi5vIGhhcC5vIGd1ZXN0X3dhbGtfMmxldmVsLm8gZ3Vlc3Rfd2Fsa18zbGV2ZWwubyBn
dWVzdF93YWxrXzRsZXZlbC5vIG5lc3RlZF9oYXAubw0KbWFrZVs2XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vYXJjaC94ODYvbW0vaGFw
Jw0KbGQgICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIHBhZ2luZy5vIHAybS5v
IHAybS1wdC5vIHAybS1lcHQubyBwMm0tcG9kLm8gZ3Vlc3Rfd2Fsa18yLm8gZ3Vlc3Rfd2Fs
a18zLm8gZ3Vlc3Rfd2Fsa180Lm8gbWVtX2V2ZW50Lm8gbWVtX3BhZ2luZy5vIG1lbV9zaGFy
aW5nLm8gbWVtX2FjY2Vzcy5vIA0Kc2hhZG93L2J1aWx0X2luLm8gaGFwL2J1aWx0X2luLm8N
Cm1ha2VbNV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2FyY2gveDg2L21tJw0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL1J1bGVzLm1rIC1DIG9wcm9maWxlIGJ1aWx0X2luLm8NCm1ha2VbNV06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni9vcHJvZmlsZScNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAt
Zm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlw
ZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xz
IC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBl
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1m
bm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRl
L3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLnhlbm9wcm9mLm8uZCAtYyB4ZW5vcHJvZi5jIC1vIHhlbm9wcm9mLm8NCmdjYyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRp
biAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRl
IC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9h
dCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJu
cyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53
aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJP
U0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm5taV9pbnQuby5kIC1jIG5t
aV9pbnQuYyAtbyBubWlfaW50Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5k
YW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFy
aXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAt
Zm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklT
SUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGlu
YyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BB
U1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5U
RVIgLU1NRCAtTUYgLm9wX21vZGVsX3A0Lm8uZCAtYyBvcF9tb2RlbF9wNC5jIC1vIG9wX21v
ZGVsX3A0Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
Lm9wX21vZGVsX3Bwcm8uby5kIC1jIG9wX21vZGVsX3Bwcm8uYyAtbyBvcF9tb2RlbF9wcHJv
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLm9wX21v
ZGVsX2F0aGxvbi5vLmQgLWMgb3BfbW9kZWxfYXRobG9uLmMgLW8gb3BfbW9kZWxfYXRobG9u
Lm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHBy
ZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVdu
ZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNo
cm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmJhY2t0
cmFjZS5vLmQgLWMgYmFja3RyYWNlLmMgLW8gYmFja3RyYWNlLm8NCmxkICAgIC1tZWxmX3g4
Nl82NCAgLXIgLW8gYnVpbHRfaW4ubyB4ZW5vcHJvZi5vIG5taV9pbnQubyBvcF9tb2RlbF9w
NC5vIG9wX21vZGVsX3Bwcm8ubyBvcF9tb2RlbF9hdGhsb24ubyBiYWNrdHJhY2Uubw0KbWFr
ZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4vYXJjaC94ODYvb3Byb2ZpbGUnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vUnVsZXMubWsgLUMgeDg2XzY0IGJ1aWx0X2luLm8NCm1ha2VbNV06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni94ODZfNjQnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5tbS5vLmQgLWMgbW0uYyAtbyBtbS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3Jl
ZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRl
ci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9t
YWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0
b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5v
LXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFT
X1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9z
dGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhB
U19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9Q
T0lOVEVSIC1NTUQgLU1GIC50cmFwcy5vLmQgLWMgdHJhcHMuYyAtbyB0cmFwcy5vDQpnY2Mg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1
aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5j
bHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQt
ZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4
dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3Vz
LXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0
aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURW
RVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tYWNoaW5lX2tleGVj
Lm8uZCAtYyBtYWNoaW5lX2tleGVjLmMgLW8gbWFjaGluZV9rZXhlYy5vDQpnY2MgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4g
LWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAt
V2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQg
LWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2lu
ZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wY2kuby5kIC1jIHBjaS5jIC1v
IHBjaS5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdp
dGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25z
IC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFz
eW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4v
Y29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5h
Y3BpX21tY2ZnLm8uZCAtYyBhY3BpX21tY2ZnLmMgLW8gYWNwaV9tbWNmZy5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tbWNvbmYtZmFtMTBoLm8u
ZCAtYyBtbWNvbmYtZmFtMTBoLmMgLW8gbW1jb25mLWZhbTEwaC5vDQpnY2MgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1n
bnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZu
by1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vy
cm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1u
by1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1E
SEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5tbWNvbmZpZ182NC5vLmQgLWMgbW1j
b25maWdfNjQuYyAtbyBtbWNvbmZpZ182NC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5tbWNvbmZpZy1zaGFyZWQuby5kIC1jIG1tY29uZmlnLXNo
YXJlZC5jIC1vIG1tY29uZmlnLXNoYXJlZC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5jb21wYXQuby5kIC1jIGNvbXBhdC5jIC1vIGNvbXBhdC5v
DQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
Zm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVm
aXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAt
bXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVz
dGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJv
DQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNs
dWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmln
LmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5kb21haW4u
by5kIC1jIGRvbWFpbi5jIC1vIGRvbWFpbi5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAt
V3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9p
bnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5waHlzZGV2Lm8uZCAtYyBwaHlzZGV2LmMgLW8gcGh5c2Rl
di5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVs
dCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1X
bmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5j
aHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5wbGF0
Zm9ybV9oeXBlcmNhbGwuby5kIC1jIHBsYXRmb3JtX2h5cGVyY2FsbC5jIC1vIHBsYXRmb3Jt
X2h5cGVyY2FsbC5vDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJp
YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21h
Y2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNl
cHRpb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAt
Zm5vLWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlf
QVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURf
X1hFTl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVk
ZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VH
SCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQg
LU1GIC5jcHVfaWRsZS5vLmQgLWMgY3B1X2lkbGUuYyAtbyBjcHVfaWRsZS5vDQpnY2MgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtZm5vLWJ1aWx0
aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVk
ZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxv
YXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVy
bnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvDQpub3VzLXVu
d2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJC
T1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jcHVmcmVxLm8uZCAtYyBj
cHVmcmVxLmMgLW8gY3B1ZnJlcS5vDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vUnVsZXMubWsgLUMgY29tcGF0IGJ1aWx0X2luLm8NCm1ha2VbNl06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0Jw0KZ2NjIC1EX19BU1NFTUJMWV9fIC1pbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLQ0KYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1mbm8tY29tbW9uIC1X
cmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbg0K
Y2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4
Ni9tYWNoLWdlbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVj
dG9yIC1mbm8tZXhjZXB0aQ0Kb25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAt
bW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hB
U19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5v
c3RkaW5jIC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50Lw0Kdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTX0FDUEkgLURI
QVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVf
UE9JTlRFUiAtTU1EIC1NRiAuZW50cnkuby5kIC1jIGVudHJ5LlMgLW8gZW50cnkubw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGVudHJ5Lm8NCm1ha2VbNl06IExl
YXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gv
eDg2L3g4Nl82NC9jb21wYXQnDQpnY2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24g
LVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBv
aW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2lu
DQpjbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5j
bHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90
ZWN0b3IgLWZuby1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0Nf
SEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
bm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAt
REhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFN
RV9QT0lOVEVSIC1NTUQgLU1GIC5lbnRyeS5vLmQgLWMgZW50cnkuUyAtbyBlbnRyeS5vDQpn
Y2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12
YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3
aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2VuZXJpYyAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVm
YXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpDQpv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklC
VVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5n
cHJfc3dpdGNoLm8uZCAtYyBncHJfc3dpdGNoLlMgLW8gDQpncHJfc3dpdGNoLm8NCmdjYyAt
RF9fQVNTRU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi0NCmFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhw
cmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0
IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAt
V25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3lu
Y2hyb25vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUg
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWlu
Y2x1ZGUgL21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2Nv
bmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNvbXBh
dF9rZXhlYy5vLmQgLWMgY29tcGF0X2tleGVjLlMNCiAtbyBjb21wYXRfa2V4ZWMubw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIG1tLm8gdHJhcHMubyBtYWNoaW5l
X2tleGVjLm8gcGNpLm8gYWNwaV9tbWNmZy5vIG1tY29uZi1mYW0xMGgubyBtbWNvbmZpZ182
NC5vIG1tY29uZmlnLXNoYXJlZC5vIGNvbXBhdC5vIGRvbWFpbi5vIHBoeXNkZXYubyBwbGF0
Zm9ybV9oeXBlcmNhbA0KbC5vIGNwdV9pZGxlLm8gY3B1ZnJlcS5vIGNvbXBhdC9idWlsdF9p
bi5vIGVudHJ5Lm8gZ3ByX3N3aXRjaC5vIGNvbXBhdF9rZXhlYy5vDQptYWtlWzVdOiBMZWF2
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4
Ni94ODZfNjQnDQpnY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtZm5vLWJ1aWx0aW4gLWZuby1jDQpvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZSAgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlDQpuZXJpYyAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
ZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRp
b25zIC1XbmVzdGVkLWV4dGVybnMgLW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5v
LWFzeW5jaHJvDQpub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRU
UklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hF
Tl9fIC1pbmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94
ZW4vY29uZmlnLmggLURWRVJCT1NFIC1ESEFTDQpfQUNQSSAtREhBU19QQVNTVEhST1VHSCAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1G
IC5iemltYWdlLm8uZCAtRElOSVRfU0VDVElPTlNfT05MWSAtYyBiemltYWdlLmMgLW8gYnpp
bWFnZS5vDQpvYmpkdW1wIC1oIGJ6aW1hZ2UubyB8IHNlZCAtbiAnL1swLTldL3tzLDAwKiww
LGc7cH0nIHwgd2hpbGUgcmVhZCBpZHggbmFtZSBzeiByZXN0OyBkbyBcDQogICAgICAgIGNh
c2UgIiRuYW1lIiBpbiBcDQogICAgICAgIC50ZXh0fC50ZXh0Lip8LmRhdGF8LmRhdGEuKnwu
YnNzKSBcDQogICAgICAgICAgICAgICAgdGVzdCAkc3ogIT0gMCB8fCBjb250aW51ZTsgXA0K
ICAgICAgICAgICAgICAgIGVjaG8gIkVycm9yOiBzaXplIG9mIGJ6aW1hZ2UubzokbmFtZSBp
cyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAkKGV4cHIgJGlkeCArIDEp
OzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAtLXJlbmFtZS1zZWN0aW9u
IC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0YS5zdHIxLjE9
LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEuc3RyMS4yPS5p
bml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cg0KMS40PS5p
bml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0cjEuOD0uaW5p
dC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsPS5pbml0LmRhdGEu
cmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5pbml0LmRhdGEucmVsLmxv
Y2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89LmluaXQuZGF0YS5yZWwucm8g
LS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0YS5yZWwucm8u
bG9jYWwgYnppbWFnZS5vIGJ6aW1hZ2UuaW5pdC5vDQpnY2MgLURfX0FTU0VNQkxZX18gLWlu
Y2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25m
aWcuaCAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1h
bGlhc2luZyAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4g
LWZuby1jb21tb24gLVdyZWR1bmRhbnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdl
cnJvciAtV25vLXBvaW50ZXItYXJpdGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luDQpjbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
aW5jbHVkZS9hc20teDg2L21hY2gtZ2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZu
by1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAt
bW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10
YWJsZXMgLURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtbm9zdGRpbmMgLWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0Ug
LURIQVNfQUNQSSAtREhBU19QQVNTVEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
RENPTkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5jbGVhcl9wYWdlLm8uZCAtYyBjbGVh
cl9wYWdlLlMgLW8gDQpjbGVhcl9wYWdlLm8NCmdjYyAtRF9fQVNTRU1CTFlfXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi0NCmFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5v
LWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC8NCnZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
U19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmNvcHlfcGFnZS5vLmQgLWMgY29weV9wYWdl
LlMgLW8gY28NCnB5X3BhZ2Uubw0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLWZuby1idWlsdGluIC1mbm8tYw0Kb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUgIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1n
ZQ0KbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUvYXNt
LXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1m
bm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2Ug
LWZwaWMgLWZuby1hc3luY2hybw0Kbm91cy11bndpbmQtdGFibGVzIC1ER0NDX0hBU19WSVNJ
QklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLW5vc3RkaW5j
IC1nIC1EX19YRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBUw0KX0FDUEkgLURIQVNfUEFT
U1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLURDT05GSUdfRlJBTUVfUE9JTlRF
UiAtTU1EIC1NRiAuZG1pX3NjYW4uby5kIC1ESU5JVF9TRUNUSU9OU19PTkxZIC1jIGRtaV9z
Y2FuLmMgLW8gZG1pX3NjYW4ubw0Kb2JqZHVtcCAtaCBkbWlfc2Nhbi5vIHwgc2VkIC1uICcv
WzAtOV0ve3MsMDAqLDAsZztwfScgfCB3aGlsZSByZWFkIGlkeCBuYW1lIHN6IHJlc3Q7IGRv
IFwNCiAgICAgICAgY2FzZSAiJG5hbWUiIGluIFwNCiAgICAgICAgLnRleHR8LnRleHQuKnwu
ZGF0YXwuZGF0YS4qfC5ic3MpIFwNCiAgICAgICAgICAgICAgICB0ZXN0ICRzeiAhPSAwIHx8
IGNvbnRpbnVlOyBcDQogICAgICAgICAgICAgICAgZWNobyAiRXJyb3I6IHNpemUgb2YgZG1p
X3NjYW4ubzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAk
KGV4cHIgJGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAt
LXJlbmFtZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24g
LnJvZGF0YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5y
b2RhdGEuc3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9k
YXRhLnN0cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9k
YXRhLnN0cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEu
cmVsPS5pbml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5p
bml0LmRhdGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89Lmlu
aXQuZGF0YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9Lmlu
aXQuZGF0YS5yZWwucm8ubG9jYWwgZG1pX3NjYW4ubyBkbWlfc2Nhbi5pbml0Lm8NCmdjYyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVp
bHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNs
dWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1m
bG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0
ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMt
dW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZF
UkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLmRvbWFpbl9idWlsZC5v
LmQgLURJTklUX1NFQ1RJT05TX09OTFkgLWMgZG9tYWluX2J1aWxkLmMgLW8gZG9tYWluX2J1
aWxkLm8NCm9iamR1bXAgLWggZG9tYWluX2J1aWxkLm8gfCBzZWQgLW4gJy9bMC05XS97cyww
MCosMCxnO3B9JyB8IHdoaWxlIHJlYWQgaWR4IG5hbWUgc3ogcmVzdDsgZG8gXA0KICAgICAg
ICBjYXNlICIkbmFtZSIgaW4gXA0KICAgICAgICAudGV4dHwudGV4dC4qfC5kYXRhfC5kYXRh
Lip8LmJzcykgXA0KICAgICAgICAgICAgICAgIHRlc3QgJHN6ICE9IDAgfHwgY29udGludWU7
IFwNCiAgICAgICAgICAgICAgICBlY2hvICJFcnJvcjogc2l6ZSBvZiBkb21haW5fYnVpbGQu
bzokbmFtZSBpcyAweCRzeiIgPiYyOyBcDQogICAgICAgICAgICAgICAgZXhpdCAkKGV4cHIg
JGlkeCArIDEpOzsgXA0KICAgICAgICBlc2FjOyBcDQogZG9uZQ0Kb2JqY29weSAtLXJlbmFt
ZS1zZWN0aW9uIC5yb2RhdGE9LmluaXQucm9kYXRhIC0tcmVuYW1lLXNlY3Rpb24gLnJvZGF0
YS5zdHIxLjE9LmluaXQucm9kYXRhLnN0cjEuMSAtLXJlbmFtZS1zZWN0aW9uIC5yb2RhdGEu
c3RyMS4yPS5pbml0LnJvZGF0YS5zdHIxLjIgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cg0KMS40PS5pbml0LnJvZGF0YS5zdHIxLjQgLS1yZW5hbWUtc2VjdGlvbiAucm9kYXRhLnN0
cjEuOD0uaW5pdC5yb2RhdGEuc3RyMS44IC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsPS5p
bml0LmRhdGEucmVsIC0tcmVuYW1lLXNlY3Rpb24gLmRhdGEucmVsLmxvY2FsPS5pbml0LmRh
dGEucmVsLmxvY2FsIC0tcmVuYQ0KbWUtc2VjdGlvbiAuZGF0YS5yZWwucm89LmluaXQuZGF0
YS5yZWwucm8gLS1yZW5hbWUtc2VjdGlvbiAuZGF0YS5yZWwucm8ubG9jYWw9LmluaXQuZGF0
YS5yZWwucm8ubG9jYWwgZG9tYWluX2J1aWxkLm8gZG9tYWluX2J1aWxkLmluaXQubw0KbGQg
ICAgLW1lbGZfeDg2XzY0ICAtciAtbyBidWlsdF9pbi5vIGFwaWMubyBiaXRvcHMubyBjb21w
YXQubyBkZWJ1Zy5vIGRlbGF5Lm8gZG9tY3RsLm8gZG9tYWluLm8gZTgyMC5vIGV4dGFibGUu
byBmbHVzaHRsYi5vIHBsYXRmb3JtX2h5cGVyY2FsbC5vIGkzODcubyBpODI1OS5vIGlvX2Fw
aWMubyBtc2kubyBpbw0KcG9ydF9lbXVsYXRlLm8gaXJxLm8gbWljcm9jb2RlX2FtZC5vIG1p
Y3JvY29kZV9pbnRlbC5vIG1pY3JvY29kZS5vIG1tLm8gbXBwYXJzZS5vIG5taS5vIG51bWEu
byBwY2kubyBwZXJjcHUubyBwaHlzZGV2Lm8gc2V0dXAubyBzaHV0ZG93bi5vIHNtcC5vIHNt
cGJvb3QubyBzcmF0Lm8gc3RyaW5nLm8gc3lzY3RsLg0KbyB0aW1lLm8gdHJhY2UubyB0cmFw
cy5vIHVzZXJjb3B5Lm8geDg2X2VtdWxhdGUubyBtYWNoaW5lX2tleGVjLm8gY3Jhc2gubyB0
Ym9vdC5vIGhwZXQubyB4c3RhdGUubyBhY3BpL2J1aWx0X2luLm8gY3B1L2J1aWx0X2luLm8g
Z2VuYXBpYy9idWlsdF9pbi5vIGh2bS9idWlsdF9pbi5vIG1tL2J1aWx0X2luLm8gbw0KcHJv
ZmlsZS9idWlsdF9pbi5vIHg4Nl82NC9idWlsdF9pbi5vIGJ6aW1hZ2UuaW5pdC5vIGNsZWFy
X3BhZ2UubyBjb3B5X3BhZ2UubyBkbWlfc2Nhbi5pbml0Lm8gZG9tYWluX2J1aWxkLmluaXQu
bw0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vYXJjaC94ODYnDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vUnVsZXMubWsgLUMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jcnlw
dG8gYnVpbHRfaW4ubw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL2NyeXB0bycNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9u
IC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1w
b2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlICAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZ2UNCm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25l
IC1tbm8tc3NlIC1mcGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdD
Q19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJ
IC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZS
QU1FX1BPSU5URVIgLU1NRCAtTUYgLnJpam5kYWVsLm8uZCAtYyByaWpuZGFlbC5jIC1vIHJp
am5kYWVsLm8NCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1p
d2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UNCm5lcmljIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1k
ZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlv
bnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1mcGljIC1mbm8t
YXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRS
SUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVO
X18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hl
bi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LnZtYWMuby5kIC1jIHZtYWMuYyAtbyB2bWFjLm8NCmxkICAgIC1tZWxmX3g4Nl82NCAgLXIg
LW8gYnVpbHRfaW4ubyByaWpuZGFlbC5vIHZtYWMubw0KbWFrZVs0XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vY3J5cHRvJw0KbGQgICAg
LW1lbGZfeDg2XzY0ICAtciAtbyBwcmVsaW5rLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi9hcmNoL3g4Ni9ib290L2J1aWx0X2luLm8gL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9hcmNoL3g4Ni9lZmkvYnVpbHRfaW4ubyAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveA0KZW4vY29tbW9uL2J1aWx0X2luLm8gL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3hlbi9kcml2ZXJzL2J1aWx0X2luLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi94c20vYnVpbHRfaW4ubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2FyY2gveDg2L2J1aWx0X2luLm8gL21udC92bQ0KL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2NyeXB0by9idWlsdF9pbi5vDQpnY2MgLVAgLUUgLVVpMzg2IC1EX19BU1NFTUJMWV9fIC1p
bmNsdWRlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29u
ZmlnLmggLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtDQpXZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGlu
IC1mbm8tY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1X
ZXJyb3IgLVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
DQpibGUuaGcveGVuL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVu
L2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWdlbmVyaWMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUvYXNtLXg4Ni9tYWNoLWRlZmF1bHQgLW1zb2Z0LWZsb2F0IC1m
bm8tc3RhY2stcHJvdGVjdG9yDQogLWZuby1leGNlcHRpb25zIC1XbmVzdGVkLWV4dGVybnMg
LW1uby1yZWQtem9uZSAtbW5vLXNzZSAtZnBpYyAtZm5vLWFzeW5jaHJvbm91cy11bndpbmQt
dGFibGVzIC1ER0NDX0hBU19WSVNJQklMSVRZX0FUVFJJQlVURSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgLW5vc3RkaW5jIC1nIC1EX19YRU5fXyAtDQppbmNsdWRlIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1ESEFTX0FDUEkgLURIQVNfUEFTU1RIUk9VR0ggLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LURDT05GSUdfRlJBTUVfUE9JTlRFUiAtTU1EIC1NRiAueGVuLmxkcy5kIC1vIHhlbi5sZHMg
DQp4ZW4ubGRzLlMNCnNlZCAtZSAncy94ZW5cLmxkc1wubzoveGVuXC5sZHM6L2cnIDwueGVu
Lmxkcy5kID4ueGVuLmxkcy5kLm5ldw0KbXYgLWYgLnhlbi5sZHMuZC5uZXcgLnhlbi5sZHMu
ZA0KbWFrZSAtZiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL1J1bGVzLm1rIC1D
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vY29tbW9uIHN5bWJvbHMtZHVtbXku
bw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2NvbW1vbicNCmdjYyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1mbm8tYnVpbHRpbiAtZm5vLWMNCm9tbW9uIC1XcmVkdW5kYW50
LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3IgLVduby1wb2ludGVyLWFyaXRo
IC1waXBlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlICAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gtZ2UN
Cm5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14
ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3NlIC1m
cGljIC1mbm8tYXN5bmNocm8NCm5vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJ
TElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAt
ZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9p
bmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVMNCl9BQ1BJIC1ESEFTX1BBU1NU
SFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIg
LU1NRCAtTUYgLnN5bWJvbHMtZHVtbXkuby5kIC1jIHN5bWJvbHMtZHVtbXkuYyAtbyBzeW1i
b2xzLWR1bW15Lm8NCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1vbicNCmxkICAgIC1tZWxmX3g4Nl82NCAgLVQgeGVu
LmxkcyAtTiBwcmVsaW5rLm8gXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuL2NvbW1vbi9zeW1ib2xzLWR1bW15Lm8gLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi8ueGVuLXN5bXMuMA0Kbm0gLW4gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMCB8IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMvc3ltYm9scyA+L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMu
MC5TDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMuMC5vDQptYWtlWzRd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYnDQpnY2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC4ueGVuLXN5bXMuMC5vLmQgLWMgL21udC92bS94ZW4veGVuDQotdW5zdGFi
bGUuaGcveGVuLy54ZW4tc3ltcy4wLlMgLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMC5vDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NicNCmxkICAgIC1tZWxmX3g4Nl82
NCAgLVQgeGVuLmxkcyAtTiBwcmVsaW5rLm8gXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuLy54ZW4tc3ltcy4wLm8gLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi8ueGVuLXN5bXMuMQ0Kbm0gLW4gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMSB8IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9v
bHMvc3ltYm9scyA+L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMu
MS5TDQptYWtlIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vUnVsZXMubWsg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLXN5bXMuMS5vDQptYWtlWzRd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4v
YXJjaC94ODYnDQpnY2MgLURfX0FTU0VNQkxZX18gLWluY2x1ZGUgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL3hlbi9jb25maWcuaCAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tDQphZnRlci1zdGF0ZW1lbnQgLVduby11bnVz
ZWQtYnV0LXNldC12YXJpYWJsZSAtZm5vLWJ1aWx0aW4gLWZuby1jb21tb24gLVdyZWR1bmRh
bnQtZGVjbHMgLWl3aXRocHJlZml4IGluY2x1ZGUgLVdlcnJvciAtV25vLXBvaW50ZXItYXJp
dGggLXBpcGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luDQpjbHVkZSAt
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20teDg2L21hY2gt
Z2VuZXJpYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vaW5jbHVkZS9hc20t
eDg2L21hY2gtZGVmYXVsdCAtbXNvZnQtZmxvYXQgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1leGNlcHRpDQpvbnMgLVduZXN0ZWQtZXh0ZXJucyAtbW5vLXJlZC16b25lIC1tbm8tc3Nl
IC1mcGljIC1mbm8tYXN5bmNocm9ub3VzLXVud2luZC10YWJsZXMgLURHQ0NfSEFTX1ZJU0lC
SUxJVFlfQVRUUklCVVRFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbm9zdGRpbmMg
LWcgLURfX1hFTl9fIC1pbmNsdWRlIC9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi9pbmNsdWRlL3hlbi9jb25maWcuaCAtRFZFUkJPU0UgLURIQVNfQUNQSSAtREhBU19QQVNT
VEhST1VHSCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENPTkZJR19GUkFNRV9QT0lOVEVS
IC1NTUQgLU1GIC4ueGVuLXN5bXMuMS5vLmQgLWMgL21udC92bS94ZW4veGVuDQotdW5zdGFi
bGUuaGcveGVuLy54ZW4tc3ltcy4xLlMgLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi8ueGVuLXN5bXMuMS5vDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NicNCmxkICAgIC1tZWxmX3g4Nl82
NCAgLVQgeGVuLmxkcyAtTiBwcmVsaW5rLm8gXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuLy54ZW4tc3ltcy4xLm8gLW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3hlbi94ZW4tc3ltcw0Kcm0gLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hl
bi8ueGVuLXN5bXMuWzAtOV0qDQo6IGxkICAgIC1tZWxmX3g4Nl82NCAgLXIgLW8gcHJlbGlu
ay1lZmkubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2Jvb3Qv
YnVpbHRfaW4ubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2NvbW1vbi9idWls
dF9pbi5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94DQplbi9kcml2ZXJzL2J1aWx0
X2luLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94c20vYnVpbHRfaW4ubyAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2FyY2gveDg2L2J1aWx0X2luLm8gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9jcnlwdG8vYnVpbHRfaW4ubyBlZmkvYm9v
DQp0LmluaXQubyBlZmkvcnVudGltZS5vIGVmaS9jb21wYXQubw0KZ2NjIC1QIC1FIC1VaTM4
NiAtREVGSSAtRF9fQVNTRU1CTFlfXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1XYWxsIC1Xc3RyaWN0LXByb3Rv
dA0KeXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNs
cyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlw
ZSAtSS9tbnQvdm0veGVuL3hlbg0KLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1nZW5lcmlj
IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNsdWRlL2FzbS14ODYvbWFj
aC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0YWNrLXBybw0KdGVjdG9yIC1mbm8tZXhj
ZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8tcmVkLXpvbmUgLW1uby1zc2UgLWZwaWMg
LWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtREdDQ19IQVNfVklTSUJJTElUWV9B
VFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9f
WA0KRU5fXyAtaW5jbHVkZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1
ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhBU19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdI
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAt
TUYgLmVmaS5sZHMuZCAtbyBlZg0KaS5sZHMgeGVuLmxkcy5TDQpzZWQgLWUgJ3MvZWZpXC5s
ZHNcLm86L2VmaVwubGRzOi9nJyA8LmVmaS5sZHMuZCA+LmVmaS5sZHMuZC5uZXcNCm12IC1m
IC5lZmkubGRzLmQubmV3IC5lZmkubGRzLmQNCmdjYyAtRF9fQVNTRU1CTFlfXyAtaW5jbHVk
ZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5o
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi0NCmFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5v
LWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9y
IC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vaW4NCmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9pbmNs
dWRlL2FzbS14ODYvbWFjaC1nZW5lcmljIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi9pbmNsdWRlL2FzbS14ODYvbWFjaC1kZWZhdWx0IC1tc29mdC1mbG9hdCAtZm5vLXN0
YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGkNCm9ucyAtV25lc3RlZC1leHRlcm5zIC1tbm8t
cmVkLXpvbmUgLW1uby1zc2UgLWZwaWMgLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxl
cyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1ub3N0ZGluYyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL21udC8NCnZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL2luY2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtREhB
U19BQ1BJIC1ESEFTX1BBU1NUSFJPVUdIIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09O
RklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYgLnJlbG9jcy1kdW1teS5vLmQgLWMgZWZpL3Jl
bG9jcy1kdW0NCm15LlMgLW8gZWZpL3JlbG9jcy1kdW1teS5vDQpnY2MgLVdhbGwgLVdlcnJv
ciAtV3N0cmljdC1wcm90b3R5cGVzIC1PMiAtZm9taXQtZnJhbWUtcG9pbnRlciAtZm5vLXN0
cmljdC1hbGlhc2luZyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtZyAtbyBlZmkv
bWtyZWxvYyBlZmkvbWtyZWxvYy5jDQo6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAt
LWltYWdlLWJhc2U9MHhmZmZmODJjNDgwMDAwMDAwIC0tc3RhY2s9MCwwIC0taGVhcD0wLDAg
LS1zdHJpcC1kZWJ1ZyAtLXNlY3Rpb24tYWxpZ25tZW50PTB4MjAwMDAwIC0tZmlsZS1hbGln
bm1lbnQ9MHgyMCAtLW1ham9yLWltYWdlLXZlcnNpb249NCAtLW1pDQpub3ItaW1hZ2UtdmVy
c2lvbj0yIC0tbWFqb3Itb3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVyc2lvbj0wIC0tbWFq
b3Itc3Vic3lzdGVtLXZlcnNpb249MiAtLW1pbm9yLXN1YnN5c3RlbS12ZXJzaW9uPTAgLVQg
ZWZpLmxkcyAtTiBwcmVsaW5rLWVmaS5vIGVmaS9yZWxvY3MtZHVtbXkubyAvbW50L3ZtL3hl
bi94DQplbi11bnN0YWJsZS5oZy94ZW4vY29tbW9uL3N5bWJvbHMtZHVtbXkubyAtbyAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjB4ZmZmZjgyYzQ4MDAwMDAw
MC4wICYmICA6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAtLWltYWdlLWJhc2U9MHhm
ZmZmODJjNGMwMDAwMDAwIC0tc3RhDQpjaz0wLDAgLS1oZWFwPTAsMCAtLXN0cmlwLWRlYnVn
IC0tc2VjdGlvbi1hbGlnbm1lbnQ9MHgyMDAwMDAgLS1maWxlLWFsaWdubWVudD0weDIwIC0t
bWFqb3ItaW1hZ2UtdmVyc2lvbj00IC0tbWlub3ItaW1hZ2UtdmVyc2lvbj0yIC0tbWFqb3It
b3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVyc2lvbj0wIC0tbWFqDQpvci1zdWJzeXN0ZW0t
dmVyc2lvbj0yIC0tbWlub3Itc3Vic3lzdGVtLXZlcnNpb249MCAtVCBlZmkubGRzIC1OIHBy
ZWxpbmstZWZpLm8gZWZpL3JlbG9jcy1kdW1teS5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vY29tbW9uL3N5bWJvbHMtZHVtbXkubyAtbyAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFiDQpsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNGMwMDAwMDAwLjAgJiYgOg0KOiBl
ZmkvbWtyZWxvYyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjB4
ZmZmZjgyYzQ4MDAwMDAwMC4wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhl
bi5lZmkuMHhmZmZmODJjNGMwMDAwMDAwLjAgPi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4vLnhlbi5lZg0KaS4wci5TDQo6IG5tIC1uIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNDgwMDAwMDAwLjAgfCA6IC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvc3ltYm9scyA+L21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4wcy5TDQo6IG1ha2UgLWYgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
eGVuLy54ZW4uZWZpLjByLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVu
LmVmaS4wcy5vDQo6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAtLWltYWdlLWJhc2U9
MHhmZmZmODJjNDgwMDAwMDAwIC0tc3RhY2s9MCwwIC0taGVhcD0wLDAgLS1zdHJpcC1kZWJ1
ZyAtLXNlY3Rpb24tYWxpZ25tZW50PTB4MjAwMDAwIC0tZmlsZS1hbGlnbm1lbnQ9MHgyMCAt
LW1ham9yLWltYWdlLXZlcnNpb249NCAtLW1pDQpub3ItaW1hZ2UtdmVyc2lvbj0yIC0tbWFq
b3Itb3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVyc2lvbj0wIC0tbWFqb3Itc3Vic3lzdGVt
LXZlcnNpb249MiAtLW1pbm9yLXN1YnN5c3RlbS12ZXJzaW9uPTAgLVQgZWZpLmxkcyAtTiBw
cmVsaW5rLWVmaS5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vDQoueGVuLmVm
aS4wci5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHMubyAt
byAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjB4ZmZmZjgyYzQ4
MDAwMDAwMC4xICYmICA6IGxkIC1taTM4NnBlcCAtLXN1YnN5c3RlbT0xMCAtLWltYWdlLWJh
c2U9MHhmZmZmDQo4MmM0YzAwMDAwMDAgLS1zdGFjaz0wLDAgLS1oZWFwPTAsMCAtLXN0cmlw
LWRlYnVnIC0tc2VjdGlvbi1hbGlnbm1lbnQ9MHgyMDAwMDAgLS1maWxlLWFsaWdubWVudD0w
eDIwIC0tbWFqb3ItaW1hZ2UtdmVyc2lvbj00IC0tbWlub3ItaW1hZ2UtdmVyc2lvbj0yIC0t
bWFqb3Itb3MtdmVyc2lvbj0yIC0tbWlub3ItDQpvcy12ZXJzaW9uPTAgLS1tYWpvci1zdWJz
eXN0ZW0tdmVyc2lvbj0yIC0tbWlub3Itc3Vic3lzdGVtLXZlcnNpb249MCAtVCBlZmkubGRz
IC1OIHByZWxpbmstZWZpLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVu
LmVmaS4wci5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlDQpuLmVmaS4w
cy5vIC1vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZm
ODJjNGMwMDAwMDAwLjEgJiYgOg0KOiBlZmkvbWtyZWxvYyAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcveGVuLy54ZW4uZWZpLjB4ZmZmZjgyYzQ4MDAwMDAwMC4xIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNGMwMDAwMDAwLjEgPi9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZg0KaS4xci5TDQo6IG5tIC1u
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMHhmZmZmODJjNDgw
MDAwMDAwLjEgfCA6IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vdG9vbHMvc3lt
Ym9scyA+L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4xcy5TDQo6
IG1ha2UgLWYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi9SdWxlcy5tayAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuLy54ZW4uZWZpLjFyLm8gL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4xcy5vDQo6IGxkIC1taTM4NnBlcCAtLXN1
YnN5c3RlbT0xMCAtLWltYWdlLWJhc2U9MHhmZmZmODJjNDgwMDAwMDAwIC0tc3RhY2s9MCww
IC0taGVhcD0wLDAgLS1zdHJpcC1kZWJ1ZyAtLXNlY3Rpb24tYWxpZ25tZW50PTB4MjAwMDAw
IC0tZmlsZS1hbGlnbm1lbnQ9MHgyMCAtLW1ham9yLWltYWdlLXZlcnNpb249NCAtLW1pDQpu
b3ItaW1hZ2UtdmVyc2lvbj0yIC0tbWFqb3Itb3MtdmVyc2lvbj0yIC0tbWlub3Itb3MtdmVy
c2lvbj0wIC0tbWFqb3Itc3Vic3lzdGVtLXZlcnNpb249MiAtLW1pbm9yLXN1YnN5c3RlbS12
ZXJzaW9uPTAgLVQgZWZpLmxkcyAtTiBwcmVsaW5rLWVmaS5vIFwNCiAgICAgICAgICAgICAg
ICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS4xci5vIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4vLnhlbi5lZmkuMXMubyAtbyAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuL3hlbi5lZmkNCmlmIDogZmFsc2U7IHRoZW4gcm0gLWYg
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4uZWZpOyBlY2hvICdFRkkgc3Vw
cG9ydCBkaXNhYmxlZCc7IGZpDQpFRkkgc3VwcG9ydCBkaXNhYmxlZA0Kcm0gLWYgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi8ueGVuLmVmaS5bMC05XSoNCmdjYyAtV2FsbCAt
V2Vycm9yIC1Xc3RyaWN0LXByb3RvdHlwZXMgLU8yIC1mb21pdC1mcmFtZS1wb2ludGVyIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1vIGJv
b3QvbWtlbGYzMiBib290L21rZWxmMzIuYw0KLi9ib290L21rZWxmMzIgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4tc3ltcyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcveGVuL3hlbiAweDEwMDAwMCBcDQogYG5tIC1uciAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcveGVuL3hlbi1zeW1zIHwgaGVhZCAtbiAxIHwgc2VkIC1lICdzL15cKFteIF0qXCku
Ki8weFwxLydgDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3hlbi9hcmNoL3g4NicNCmd6aXAgLWYgLTkgPCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcveGVuL3hlbiA+IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94
ZW4veGVuLmd6Lm5ldw0KbXYgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4u
Z3oubmV3IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy94ZW4veGVuLmd6DQpbIC1kIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvYm9vdCBdIHx8IGluc3Rh
bGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvYm9vdA0KaW5zdGFsbCAtbTA2NDQgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3hlbi94ZW4uZ3ogL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9i
b290L3hlbi00LjItdW5zdGFibGUuZ3oNCmxuIC1mIC1zIHhlbi00LjItdW5zdGFibGUuZ3og
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ib290L3hlbi00LjIu
Z3oNCmxuIC1mIC1zIHhlbi00LjItdW5zdGFibGUuZ3ogL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC9ib290L3hlbi00Lmd6DQpsbiAtZiAtcyB4ZW4tNC4yLXVu
c3RhYmxlLmd6IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvYm9v
dC94ZW4uZ3oNCmluc3RhbGwgLW0wNjQ0IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy94ZW4veGVuLXN5bXMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFs
bC9ib290L3hlbi1zeW1zLTQuMi11bnN0YWJsZQ0KaWYgWyAtciAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcveGVuL3hlbi5lZmkgXTsgdGhlbiBcDQogICAgICAgIFsgLWQgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliL2VmaSBdIHx8IGlu
c3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2xpYi9lZmk7IFwNCiAgICAgICAgaW5zdGFsbCAtbTA2NDQgLXAgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3hlbi94ZW4uZWZpIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi9lZmkveGVuLTQuMi11bnN0YWJsZS5lZmk7
IFwNCiAgICAgICAgbG4gLXNmIHhlbi00LjItdW5zdGFibGUuZWZpIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi9lZmkveGVuLTQuMi5lZmk7IFwN
CiAgICAgICAgbG4gLXNmIHhlbi00LjItdW5zdGFibGUuZWZpIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi9lZmkveGVuLTQuZWZpOyBcDQogICAg
ICAgIGxuIC1zZiB4ZW4tNC4yLXVuc3RhYmxlLmVmaSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9saWIvZWZpL3hlbi5lZmk7IFwNCiAgICAgICAgaWYg
WyAtbiAnL2Jvb3QvZWZpJyAtYSAtbiAnJyBdOyB0aGVuIFwNCiAgICAgICAgICAgICAgICBp
bnN0YWxsIC1tMDY0NCAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcveGVuL3hlbi5l
ZmkgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ib290L2VmaS9l
ZmkvL3hlbi00LjItdW5zdGFibGUuZWZpOyBcDQogICAgICAgIGVsaWYgWyAiL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbCIgPSAiZGlzdC9pbnN0YWxsIiBdOyB0
aGVuIFwNCiAgICAgICAgICAgICAgICBlY2hvICdFRkkgaW5zdGFsbGF0aW9uIG9ubHkgcGFy
dGlhbGx5IGRvbmUgKEVGSV9WRU5ET1Igbm90IHNldCknID4mMjsgXA0KICAgICAgICBmaTsg
XA0KIGZpDQptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3hlbicNCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcveGVuJw0KZm9yIGkgaW4gIDsgZG8gbWFrZSAkaS1pbnN0YWxs
IHx8IGV4aXQgMTsgZG9uZQ0KbWFrZSAtQyB0b29scyBxZW11LXhlbi10cmFkaXRpb25hbC1k
aXItZmluZA0KbWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMnDQpzZXQgLWV4OyBcDQogaWYgdGVzdCAtZCBnaXQ6Ly94ZW5i
aXRzLnhlbnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0OyB0aGVuIFwNCiAgICAg
ICAgbWtkaXIgLXAgcWVtdS14ZW4tdHJhZGl0aW9uYWwtZGlyOyBcDQogZWxzZSBcDQogICAg
ICAgIGV4cG9ydCBHSVQ9Z2l0OyBcDQogICAgICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy8uLi9zY3JpcHRzL2dpdC1jaGVja291dC5zaCBnaXQ6Ly94ZW5iaXRzLnhl
bnNvdXJjZS5jb20vcWVtdS14ZW4tdW5zdGFibGUuZ2l0IDUwYzU1M2JlNDcyYzlmNGIwNWEw
NTI2YzBhYWU5ODcwOWNhOWZmZmYgcWVtdS14ZW4tdHJhZGl0aW9uDQphbC1kaXI7IFwNCiBm
aQ0KKyB0ZXN0IC1kIGdpdDovL3hlbmJpdHMueGVuc291cmNlLmNvbS9xZW11LXhlbi11bnN0
YWJsZS5naXQNCisgZXhwb3J0IEdJVD1naXQNCisgR0lUPWdpdA0KKyAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvLi4vc2NyaXB0cy9naXQtY2hlY2tvdXQuc2ggZ2l0Oi8v
eGVuYml0cy54ZW5zb3VyY2UuY29tL3FlbXUteGVuLXVuc3RhYmxlLmdpdCA1MGM1NTNiZTQ3
MmM5ZjRiMDVhMDUyNmMwYWFlOTg3MDljYTlmZmZmIHFlbXUteGVuLXRyYWRpdGlvbmFsLWRp
cg0KQ2xvbmluZyBpbnRvICdxZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtb3RlLnRtcCcu
Li4NCnJlbW90ZTogQ291bnRpbmcgb2JqZWN0czogMTA2NjY4LCBkb25lLg0KcmVtb3RlOiBD
b21wcmVzc2luZyBvYmplY3RzOiAxMDAlICgyOTEzOC8yOTEzOCksIGRvbmUuDQpyZW1vdGU6
IFRvdGFsIDEwNjY2OCAoZGVsdGEgODE2NjUpLCByZXVzZWQgMTAxODE0IChkZWx0YSA3NzM5
OCkgIA0KUmVjZWl2aW5nIG9iamVjdHM6IDEwMCUgKDEwNjY2OC8xMDY2NjgpLCAzNy41NyBN
aUIgfCAzOTUgS2lCL3MsIGRvbmUuDQpSZXNvbHZpbmcgZGVsdGFzOiAxMDAlICg4MTY2NS84
MTY2NSksIGRvbmUuDQpTd2l0Y2hlZCB0byBhIG5ldyBicmFuY2ggJ2R1bW15Jw0KbWFrZVsx
XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cycNCm1ha2UgLUMgdG9vbHMgcWVtdS14ZW4tZGlyLWZpbmQNCm1ha2VbMV06IEVudGVyaW5n
IGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KaWYgdGVz
dCAtZCBnaXQ6Ly9naXQucWVtdS5vcmcvcWVtdS5naXQgOyB0aGVuIFwNCiAgICAgICAgbWtk
aXIgLXAgcWVtdS14ZW4tZGlyOyBcDQogZWxzZSBcDQogICAgICAgIGV4cG9ydCBHSVQ9Z2l0
OyBcDQogICAgICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy8uLi9zY3Jp
cHRzL2dpdC1jaGVja291dC5zaCBnaXQ6Ly9naXQucWVtdS5vcmcvcWVtdS5naXQgbWFzdGVy
IHFlbXUteGVuLWRpciA7IFwNCiBmaQ0KQ2xvbmluZyBpbnRvICdxZW11LXhlbi1kaXItcmVt
b3RlLnRtcCcuLi4NCnJlbW90ZTogQ291bnRpbmcgb2JqZWN0czogMTEyMzg5LCBkb25lLg0K
cmVtb3RlOiBDb21wcmVzc2luZyBvYmplY3RzOiAxMDAlICgyMzk3OC8yMzk3OCksIGRvbmUu
DQpyZW1vdGU6IFRvdGFsIDExMjM4OSAoZGVsdGEgODg4MTcpLCByZXVzZWQgMTExNDg4IChk
ZWx0YSA4ODA2NCkgIA0KUmVjZWl2aW5nIG9iamVjdHM6IDEwMCUgKDExMjM4OS8xMTIzODkp
LCAzOS45OSBNaUIgfCA3NzUgS2lCL3MsIGRvbmUuDQpSZXNvbHZpbmcgZGVsdGFzOiAxMDAl
ICg4ODgxNy84ODgxNyksIGRvbmUuDQpTd2l0Y2hlZCB0byBhIG5ldyBicmFuY2ggJ2R1bW15
Jw0KbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scycNCm1ha2UgLUMgdG9vbHMgaW5zdGFsbA0KbWFrZVsxXTogRW50ZXJpbmcg
ZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnDQptYWtlWzJd
OiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cycNCm1ha2UgLUMgaW5jbHVkZSBpbnN0YWxsDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3Rv
cnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlJw0KbWFrZSAt
QyB4ZW4tZm9yZWlnbg0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS94ZW4tZm9yZWlnbicNCnB5dGhvbiBt
a2hlYWRlci5weSB4ODZfMzIgeDg2XzMyLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2luY2x1ZGUveGVuLWZvcmVpZ24vLi4vLi4vLi4veGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gteDg2L3hlbi14ODZfMzIuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvaW5jbHUNCmRlL3hlbi1mb3JlaWduLy4uLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9h
cmNoLXg4Ni94ZW4uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVk
ZS94ZW4tZm9yZWlnbi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCnB5dGhv
biBta2hlYWRlci5weSB4ODZfNjQgeDg2XzY0LmggL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2luY2x1ZGUveGVuLWZvcmVpZ24vLi4vLi4vLi4veGVuL2luY2x1ZGUvcHVi
bGljL2FyY2gteDg2L3hlbi14ODZfNjQuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvaW5jbHUNCmRlL3hlbi1mb3JlaWduLy4uLy4uLy4uL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9hcmNoLXg4Ni94ZW4uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5j
bHVkZS94ZW4tZm9yZWlnbi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCnB5
dGhvbiBta2hlYWRlci5weSBpYTY0IGlhNjQuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvaW5jbHVkZS94ZW4tZm9yZWlnbi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJs
aWMvYXJjaC1pYTY0LmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1
ZGUveGVuLWZvcmVpZ24NCi8uLi8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCnB5
dGhvbiBta2NoZWNrZXIucHkgY2hlY2tlci5jIHg4Nl8zMiB4ODZfNjQgaWE2NA0KZ2NjIC1X
YWxsIC1XZXJyb3IgLVdzdHJpY3QtcHJvdG90eXBlcyAtTzIgLWZvbWl0LWZyYW1lLXBvaW50
ZXIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LW8gY2hlY2tlciBjaGVja2VyLmMNCi4vY2hlY2tlciA+IHRtcC5zaXplDQpkaWZmIC11IHJl
ZmVyZW5jZS5zaXplIHRtcC5zaXplDQpybSB0bXAuc2l6ZQ0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlL3hl
bi1mb3JlaWduJw0KbWtkaXIgLXAgeGVuL2xpYmVsZg0KbG4gLXNmIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9D
T1BZSU5HIHhlbg0KbG4gLXNmIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9p
bmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9hcmNoLWlhNjQuaCAvbW50L3ZtL3hlbi94ZQ0Kbi11bnN0YWJsZS5oZy90b29scy9pbmNs
dWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Nl8zMi5oIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9hcmNoLXg4Nl82NC5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90bw0Kb2xzL2lu
Y2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2NhbGxiYWNrLmggL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGlj
L2RvbTBfb3BzLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUv
Li4vLi4veGVuLw0KaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmggL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2VsZm5v
dGUuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94
ZW4vaW5jbHVkZS9wdWJsaWMvZXZlbnRfY2hhbg0KbmVsLmggL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2ZlYXR1
cmVzLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4v
eGVuL2luY2x1ZGUvcHVibGljL2dyYW50X3RhYmxlLmggL21udC92bS94ZW4veA0KZW4tdW5z
dGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMva2V4ZWMu
aCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4v
aW5jbHVkZS9wdWJsaWMvbWVtX2V2ZW50LmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2luYw0KbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMvbWVtb3J5LmggL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1
ZGUvcHVibGljL25taS5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNs
dWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYw0KL3BoeXNkZXYuaCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJsaWMv
cGxhdGZvcm0uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8u
Li8uLi94ZW4vaW5jbHVkZS9wdWJsaWMvc2NoZWQuaCAvbW50L3ZtL3hlbi94ZQ0Kbi11bnN0
YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9zeXNjdGwu
aCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4v
aW5jbHVkZS9wdWJsaWMvdG1lbS5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9pbmNsdWRlLw0KLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL3RyYWNlLmggL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVi
bGljL3ZjcHUuaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8u
Li8uLi94ZW4vaW5jbHVkZS9wdWJsaWMvdmVycw0KaW9uLmggL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL3hlbmNv
bW0uaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94
ZW4vaW5jbHVkZS9wdWJsaWMveGVuLWNvbXBhdC5oIC9tbnQvdm0veGVuL3hlbg0KLXVuc3Rh
YmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL3hlbi5oIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNs
dWRlL3B1YmxpYy94ZW5vcHJvZi5oIHhlbg0KbG4gLXNmIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWlh
NjQgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVu
L2luY2x1ZGUvcHVibGljL2FyY2gteDg2IC9tbnQvdm0veGVuL3hlbi11bg0Kc3RhYmxlLmhn
L3Rvb2xzL2luY2x1ZGUvLi4vLi4veGVuL2luY2x1ZGUvcHVibGljL2h2bSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS9wdWJs
aWMvaW8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4v
eGVuL2luYw0KbHVkZS9wdWJsaWMveHNtIHhlbg0KbG4gLXNmIC4uL3hlbi1zeXMvTGludXgg
eGVuL3N5cw0KbG4gLXNmIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNs
dWRlLy4uLy4uL3hlbi9pbmNsdWRlL3hlbi9saWJlbGYuaCAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi94ZW4vaW5jbHVkZS94ZW4vZWxmc3RydWN0
cy5oIHhlbi9saWJlbGYvDQpsbiAtcyAuLi94ZW4tZm9yZWlnbiB4ZW4vZm9yZWlnbg0KdG91
Y2ggeGVuLy5kaXINCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRl
Ly4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUveGVuL2FyY2gtaWE2NA0K
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4vdG9vbHMv
Y3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vYXJjaC1pYTY0L2h2bQ0KL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5z
dGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC91c3IvaW5jbHVkZS94ZW4vYXJjaC14ODYNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1
IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1
ZGUveGVuL2FyY2gteDg2L2h2bQ0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vZm9y
ZWlnbg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4v
dG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vaHZtDQovbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxs
IC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9pbmNsdWRlL3hlbi9pbw0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xz
L2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vc3lz
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hlbi94c20NCi9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0w
NjQ0IC1wIHhlbi9DT1BZSU5HIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2luY2x1ZGUveGVuDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvaW5jbHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vKi5o
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUv
eGVuDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5jbHVkZS8uLi8uLi90
b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vYXJjaC1pYTY0LyouaCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hlbi9hcmNo
LWlhNjQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4u
L3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9hcmNoLWlhNjQvaHZtLyouaCAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hl
bi9hcmNoLWlhNjQvaHZtDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5j
bHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vYXJjaC14ODYv
Ki5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1
ZGUveGVuL2FyY2gteDg2DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaW5j
bHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vYXJjaC14ODYv
aHZtLyouaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9p
bmNsdWRlL3hlbi9hcmNoLXg4Ni9odm0NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9m
b3JlaWduLyouaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vz
ci9pbmNsdWRlL3hlbi9mb3JlaWduDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvaW5jbHVkZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW4vaHZt
LyouaCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNs
dWRlL3hlbi9odm0NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRl
Ly4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9pby8qLmggL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4vaW8N
Ci9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9pbmNsdWRlLy4uLy4uL3Rvb2xz
L2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbi9zeXMvKi5oIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUveGVuL3N5cw0KL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5z
dGFsbCAtbTA2NDQgLXAgeGVuL3hzbS8qLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZS94ZW4veHNtDQptYWtlWzNdOiBMZWF2aW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2luY2x1ZGUnDQpt
YWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzJw0KbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMnDQptYWtlIC1DIGxpYnhjIGluc3RhbGwNCm1ha2VbM106IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjJw0KbWFrZSBsaWJzDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4YycNCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfY29yZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRf
U09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4u
Ly4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUku
IC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfY29yZS5vIHhjX2NvcmUuYyANCmdjYyAg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0xTX18gLU0NCk1EIC1NRiAueGNfY29yZV94ODYuby5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlz
c2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0NCi94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2NvcmVf
eDg2Lm8geGNfY29yZV94ODYuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfY3B1
cG9vbC5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9j
b21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92
bS8NCnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVk
ZSAtcHRocmVhZCAgLWMgLW8geGNfY3B1cG9vbC5vIHhjX2NwdXBvb2wuYyANCmdjYyAgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcg
LXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RP
T0xTX18gLU0NCk1EIC1NRiAueGNfZG9tYWluLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dO
VV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Npbmct
cHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21haW4ubyB4
Y19kb21haW4uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfZXZ0Y2huLm8uZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtYyAtbyB4Y19ldnRjaG4ubyB4Y19ldnRjaG4uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfZ250dGFiLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2
NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1J
Li4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAt
SS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90
b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19nbnR0YWIubyB4Y19nbnR0YWIuYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbWlzYy5vLmQgIC1EX0xBUkdFRklMRV9T
T1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdt
aXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfbWlz
Yy5vIHhjX21pc2MuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfZmxhc2suby5k
ICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xp
YmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0veGUNCm4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJl
YWQgIC1jIC1vIHhjX2ZsYXNrLm8geGNfZmxhc2suYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfcGh5c2Rldi5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxF
NjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAt
SS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMg
LUkuIC1JL21udC92bS8NCnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4v
dG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfcGh5c2Rldi5vIHhjX3BoeXNkZXYu
YyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfcHJpdmF0ZS5vLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS8NCnhlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8g
eGNfcHJpdmF0ZS5vIHhjX3ByaXZhdGUuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAu
eGNfc2VkZi5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hl
bi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21u
dC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtcHRocmVhZCAgLWMgLW8geGNfc2VkZi5vIHhjX3NlZGYuYyANCmdjYyAgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xT
X18gLU0NCk1EIC1NRiAueGNfY3NjaGVkLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9M
QVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9T
T1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJv
dG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4
Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19jc2NoZWQubyB4Y19j
c2NoZWQuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfY3NjaGVkMi5vLmQgIC1E
X0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxm
IC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS8NCnhlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAg
LWMgLW8geGNfY3NjaGVkMi5vIHhjX2NzY2hlZDIuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfYXJpbmM2NTMuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklM
RTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAg
LUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVz
IC1JLiAtSS9tbnQvdm0NCi94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2FyaW5jNjUzLm8geGNfYXJpbmM2
NTMuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1z
dHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFi
bGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfdGJ1Zi5vLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8g
eGNfdGJ1Zi5vIHhjX3RidWYuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfcG0u
by5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9u
L2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0veGVu
L3gNCmVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0
aHJlYWQgIC1jIC1vIHhjX3BtLm8geGNfcG0uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1N
RiAueGNfY3B1X2hvdHBsdWcuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklM
RTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAg
LUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVz
IC1JLiAtSS9tbnQNCi92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2NwdV9ob3RwbHVnLm8geGNfY3B1
X2hvdHBsdWcuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfcmVzdW1lLm8uZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtYyAtbyB4Y19yZXN1bWUubyB4Y19yZXN1bWUuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfdG1lbS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRf
U09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4u
Ly4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUku
IC1JL21udC92bS94ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfdG1lbS5vIHhjX3RtZW0uYyANCmdjYyAg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbWVtX2V2ZW50Lm8uZCAgLURfTEFSR0VGSUxFX1NP
VVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
IC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21p
c3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3YNCm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19tZW1f
ZXZlbnQubyB4Y19tZW1fZXZlbnQuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNf
bWVtX3BhZ2luZy5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1J
L21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfbWVtX3BhZ2luZy5vIHhjX21lbV9wYWdpbmcu
YyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbWVtX2FjY2Vzcy5vLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1X
ZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC8NCnZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMg
LW8geGNfbWVtX2FjY2Vzcy5vIHhjX21lbV9hY2Nlc3MuYyANCmdjYyAgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0N
Ck1EIC1NRiAueGNfbWVtc2hyLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJ
TEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0Ug
IC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBl
cyAtSS4gLUkvbW50L3ZtL3gNCmVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8u
Li90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19tZW1zaHIubyB4Y19tZW1zaHIu
YyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJp
Y3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVj
bGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUg
ICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfaGNhbGxfYnVmLm8uZCAgLURfTEFS
R0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdl
cnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3YNCm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAt
byB4Y19oY2FsbF9idWYubyB4Y19oY2FsbF9idWYuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGNfZm9yZWlnbl9tZW1vcnkuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xB
UkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NP
VVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90
b3R5cGVzIC1JLiAtSS8NCm1udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhj
Ly4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2ZvcmVpZ25fbWVtb3J5
Lm8geGNfZm9yZWlnbl9tZW1vcnkuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2lu
dGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0
cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51
c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueHRs
X2NvcmUuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQv
dm0veGUNCm4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1jIC1vIHh0bF9jb3JlLm8geHRsX2NvcmUuYyANCmdjYyAgLU8xIC1m
bm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xT
X18gLU0NCk1EIC1NRiAueHRsX2xvZ2dlcl9zdGRpby5vLmQgIC1EX0xBUkdFRklMRV9TT1VS
Q0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAt
RF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNz
aW5nLXByb3RvdHlwZXMgLUkuIC1JL20NCm50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geHRsX2xvZ2dl
cl9zdGRpby5vIHh0bF9sb2dnZXJfc3RkaW8uYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1N
RiAueGNfcGFnZXRhYi5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRf
U09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4u
Ly4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUku
IC1JL21udC92bS8NCnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfcGFnZXRhYi5vIHhjX3BhZ2V0YWIuYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbGludXguby5kICAtRF9MQVJHRUZJTEVf
U09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1X
bWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0veGUNCm4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2xp
bnV4Lm8geGNfbGludXguYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1t
NjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1w
cm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1
dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfbGludXhf
b3NkZXAuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQN
Ci92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2xpbnV4X29zZGVwLm8geGNfbGludXhfb3NkZXAuYyAN
CmFyIHJjIGxpYnhlbmN0cmwuYSB4Y19jb3JlLm8geGNfY29yZV94ODYubyB4Y19jcHVwb29s
Lm8geGNfZG9tYWluLm8geGNfZXZ0Y2huLm8geGNfZ250dGFiLm8geGNfbWlzYy5vIHhjX2Zs
YXNrLm8geGNfcGh5c2Rldi5vIHhjX3ByaXZhdGUubyB4Y19zZWRmLm8geGNfY3NjaGVkLm8g
eGNfY3NjaGVkMi5vIHhjX2ENCnJpbmM2NTMubyB4Y190YnVmLm8geGNfcG0ubyB4Y19jcHVf
aG90cGx1Zy5vIHhjX3Jlc3VtZS5vIHhjX3RtZW0ubyB4Y19tZW1fZXZlbnQubyB4Y19tZW1f
cGFnaW5nLm8geGNfbWVtX2FjY2Vzcy5vIHhjX21lbXNoci5vIHhjX2hjYWxsX2J1Zi5vIHhj
X2ZvcmVpZ25fbWVtb3J5Lm8geHRsX2NvcmUubyB4dGxfbG8NCmdnZXJfc3RkaW8ubyB4Y19w
YWdldGFiLm8geGNfbGludXgubyB4Y19saW51eF9vc2RlcC5vDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX2NvcmUub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX2NvcmUu
b3BpYyB4Y19jb3JlLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2Nv
cmVfeDg2Lm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VS
Q0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4v
eGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gDQot
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9p
bmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19jb3JlX3g4Ni5vcGljIHhjX2NvcmVf
eDg2LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2NwdXBvb2wub3Bp
Yy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9u
L2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtDQpJL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0
aHJlYWQgIC1mUElDIC1jIC1vIHhjX2NwdXBvb2wub3BpYyB4Y19jcHVwb29sLmMgDQpnY2Mg
IC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2RvbWFpbi5vcGljLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMg
LWMgLW8geGNfZG9tYWluLm9waWMgeGNfZG9tYWluLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpT
X18gLU1NRCAtTUYgLnhjX2V2dGNobi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURf
TEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVf
U09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXBy
b3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGli
eGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZXZ0Y2hu
Lm9waWMgeGNfZXZ0Y2huLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhj
X2dudHRhYi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1J
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZ250dGFiLm9waWMgeGNfZ250dGFi
LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21pc2Mub3BpYy5kICAt
RF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVs
ZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQg
IC1mUElDIC1jIC1vIHhjX21pc2Mub3BpYyB4Y19taXNjLmMgDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX2ZsYXNrLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dO
VV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Npbmct
cHJvdG90eXBlcyAtSS4gLUkvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19mbGFz
ay5vcGljIHhjX2ZsYXNrLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhj
X3BoeXNkZXYub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NP
VVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8u
Li94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAt
DQpJL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xz
L2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX3BoeXNkZXYub3BpYyB4Y19waHlz
ZGV2LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3ByaXZhdGUub3Bp
Yy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9u
L2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtDQpJL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0
aHJlYWQgIC1mUElDIC1jIC1vIHhjX3ByaXZhdGUub3BpYyB4Y19wcml2YXRlLmMgDQpnY2Mg
IC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3NlZGYub3BpYy5kICAtRF9MQVJHRUZJ
TEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9y
IC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1j
IC1vIHhjX3NlZGYub3BpYyB4Y19zZWRmLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1N
RCAtTUYgLnhjX2NzY2hlZC5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNF
ICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlw
ZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfY3NjaGVkLm9waWMg
eGNfY3NjaGVkLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2NzY2hl
ZDIub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtDQpJL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX2NzY2hlZDIub3BpYyB4Y19jc2NoZWQyLmMg
DQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2FyaW5jNjUzLm9waWMuZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gDQotSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtZlBJQyAtYyAtbyB4Y19hcmluYzY1My5vcGljIHhjX2FyaW5jNjUzLmMgDQpnY2MgIC1E
UElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3RidWYub3BpYy5kICAtRF9MQVJHRUZJTEVf
U09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2Fs
bHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1X
bWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1v
IHhjX3RidWYub3BpYyB4Y190YnVmLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAt
TUYgLnhjX3BtLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LUkvbW50DQovdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19wbS5vcGljIHhjX3BtLmMgDQpn
Y2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2NwdV9ob3RwbHVnLm9waWMuZCAg
LURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6
ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJl
bGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtDQpJLiAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFk
ICAtZlBJQyAtYyAtbyB4Y19jcHVfaG90cGx1Zy5vcGljIHhjX2NwdV9ob3RwbHVnLmMgDQpn
Y2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX3Jlc3VtZS5vcGljLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1X
ZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQ
SUMgLWMgLW8geGNfcmVzdW1lLm9waWMgeGNfcmVzdW1lLmMgDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX3RtZW0ub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX3RtZW0u
b3BpYyB4Y190bWVtLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21l
bV9ldmVudC5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuDQog
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfbWVtX2V2ZW50Lm9waWMgeGNfbWVt
X2V2ZW50LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21lbV9wYWdp
bmcub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4v
Y29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JDQouIC1JL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX21lbV9wYWdpbmcub3BpYyB4Y19tZW1fcGFn
aW5nLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21lbV9hY2Nlc3Mu
b3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29t
bW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JDQouIC1JL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUg
LXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX21lbV9hY2Nlc3Mub3BpYyB4Y19tZW1fYWNjZXNz
LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX21lbXNoci5vcGljLmQg
IC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGli
ZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JDQovbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVh
ZCAgLWZQSUMgLWMgLW8geGNfbWVtc2hyLm9waWMgeGNfbWVtc2hyLmMgDQpnY2MgIC1EUElD
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hF
Tl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2hjYWxsX2J1Zi5vcGljLmQgIC1EX0xBUkdFRklM
RV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3Ig
LVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuDQogLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMg
LW8geGNfaGNhbGxfYnVmLm9waWMgeGNfaGNhbGxfYnVmLmMgDQpnY2MgIC1EUElDIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
DQpTX18gLU1NRCAtTUYgLnhjX2ZvcmVpZ25fbWVtb3J5Lm9waWMuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAt
V21pc3NpbmctcHJvdG90eXBlDQpzIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAt
byB4Y19mb3JlaWduX21lbW9yeS5vcGljIHhjX2ZvcmVpZ25fbWVtb3J5LmMgDQpnY2MgIC1E
UElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnh0bF9jb3JlLm9waWMuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAt
V21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAt
byB4dGxfY29yZS5vcGljIHh0bF9jb3JlLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQt
ZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkg
LVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVu
dCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1N
RCAtTUYgLnh0bF9sb2dnZXJfc3RkaW8ub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzDQogLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHh0bF9sb2dn
ZXJfc3RkaW8ub3BpYyB4dGxfbG9nZ2VyX3N0ZGlvLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpT
X18gLU1NRCAtTUYgLnhjX3BhZ2V0YWIub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtDQpJL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX3BhZ2V0
YWIub3BpYyB4Y19wYWdldGFiLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYg
LnhjX2xpbnV4Lm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LUkvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19saW51eC5vcGljIHhjX2xpbnV4
LmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhjX2xpbnV4X29zZGVwLm9w
aWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1v
bi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtDQpJLiAtSS9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1w
dGhyZWFkICAtZlBJQyAtYyAtbyB4Y19saW51eF9vc2RlcC5vcGljIHhjX2xpbnV4X29zZGVw
LmMgDQpnY2MgICAgIC1wdGhyZWFkIC1XbCwtc29uYW1lIC1XbCxsaWJ4ZW5jdHJsLnNvLjQu
MiAtc2hhcmVkIC1vIGxpYnhlbmN0cmwuc28uNC4yLjAgeGNfY29yZS5vcGljIHhjX2NvcmVf
eDg2Lm9waWMgeGNfY3B1cG9vbC5vcGljIHhjX2RvbWFpbi5vcGljIHhjX2V2dGNobi5vcGlj
IHhjX2dudHRhYi5vcGljIHhjX21pDQpzYy5vcGljIHhjX2ZsYXNrLm9waWMgeGNfcGh5c2Rl
di5vcGljIHhjX3ByaXZhdGUub3BpYyB4Y19zZWRmLm9waWMgeGNfY3NjaGVkLm9waWMgeGNf
Y3NjaGVkMi5vcGljIHhjX2FyaW5jNjUzLm9waWMgeGNfdGJ1Zi5vcGljIHhjX3BtLm9waWMg
eGNfY3B1X2hvdHBsdWcub3BpYyB4Y19yZXN1bWUub3BpYyB4Y190DQptZW0ub3BpYyB4Y19t
ZW1fZXZlbnQub3BpYyB4Y19tZW1fcGFnaW5nLm9waWMgeGNfbWVtX2FjY2Vzcy5vcGljIHhj
X21lbXNoci5vcGljIHhjX2hjYWxsX2J1Zi5vcGljIHhjX2ZvcmVpZ25fbWVtb3J5Lm9waWMg
eHRsX2NvcmUub3BpYyB4dGxfbG9nZ2VyX3N0ZGlvLm9waWMgeGNfcGFnZXRhYi5vcGljIHhj
X2xpDQpudXgub3BpYyB4Y19saW51eF9vc2RlcC5vcGljIC1sZGwgIA0KbG4gLXNmIGxpYnhl
bmN0cmwuc28uNC4yLjAgbGlieGVuY3RybC5zby40LjINCmxuIC1zZiBsaWJ4ZW5jdHJsLnNv
LjQuMiBsaWJ4ZW5jdHJsLnNvDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhnX3ByaXZh
dGUuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29t
bW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvdm0v
DQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUg
LXB0aHJlYWQgIC1jIC1vIHhnX3ByaXZhdGUubyB4Z19wcml2YXRlLmMgDQpnY2MgIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1z
dGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVy
LXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09M
U19fIC1NDQpNRCAtTUYgLnhjX3N1c3BlbmQuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tbnQvdm0vDQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX3N1c3BlbmQubyB4
Y19zdXNwZW5kLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbWFpbl9yZXN0
b3JlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2Nv
bW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvDQptbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRl
IC1wdGhyZWFkICAtYyAtbyB4Y19kb21haW5fcmVzdG9yZS5vIHhjX2RvbWFpbl9yZXN0b3Jl
LmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3Ry
aWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2Rl
Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxl
ICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbWFpbl9zYXZlLm8uZCAgLURf
TEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1z
aWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYg
LVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50DQovdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAt
YyAtbyB4Y19kb21haW5fc2F2ZS5vIHhjX2RvbWFpbl9zYXZlLmMgDQpnY2MgIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19f
IC1NDQpNRCAtTUYgLnhjX29mZmxpbmVfcGFnZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0Ug
LURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9H
TlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5n
LXByb3RvdHlwZXMgLUkuIC1JL21uDQp0L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWMgLW8geGNfb2ZmbGluZV9w
YWdlLm8geGNfb2ZmbGluZV9wYWdlLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhj
X2NvbXByZXNzaW9uLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LUkvbW50DQovdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19jb21wcmVzc2lvbi5vIHhjX2NvbXByZXNz
aW9uLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi10b29scy5vLmQgIC1E
X0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUt
c2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxm
IC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21udC92DQptL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAg
LWMgLW8gbGliZWxmLXRvb2xzLm8gLi4vLi4veGVuL2NvbW1vbi9saWJlbGYvbGliZWxmLXRv
b2xzLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi1sb2FkZXIuby5kICAt
RF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVs
ZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLiAtSS9tbnQvDQp2bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQg
IC1jIC1vIGxpYmVsZi1sb2FkZXIubyAuLi8uLi94ZW4vY29tbW9uL2xpYmVsZi9saWJlbGYt
bG9hZGVyLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1m
bm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBl
cyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZh
cmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi1kb21pbmZvLm8u
ZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRp
bWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9s
aWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50DQovdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhy
ZWFkICAtYyAtbyBsaWJlbGYtZG9taW5mby5vIC4uLy4uL3hlbi9jb21tb24vbGliZWxmL2xp
YmVsZi1kb21pbmZvLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmxpYmVsZi1yZWxv
Y2F0ZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9j
b21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIC1JL21uDQp0
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVk
ZSAtcHRocmVhZCAgLWMgLW8gbGliZWxmLXJlbG9jYXRlLm8gLi4vLi4veGVuL2NvbW1vbi9s
aWJlbGYvbGliZWxmLXJlbG9jYXRlLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhj
X2RvbV9jb3JlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VS
Q0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4v
eGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkv
bW50L3ZtDQoveGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9p
bmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21fY29yZS5vIHhjX2RvbV9jb3JlLmMgDQpn
Y2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbV9ib290Lm8uZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAt
V21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtDQoveGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19k
b21fYm9vdC5vIHhjX2RvbV9ib290LmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhj
X2RvbV9lbGZsb2FkZXIuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0
X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUku
Li8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1J
LiAtSS9tDQpudC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rv
b2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2RvbV9lbGZsb2FkZXIubyB4Y19kb21f
ZWxmbG9hZGVyLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1n
IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90
eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0
LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX2RvbV9iemltYWdl
bG9hZGVyLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0Ug
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVu
L2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gDQotSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNs
dWRlIC1wdGhyZWFkIC1ESEFWRV9CWkxJQiAtbGJ6MiAgLWMgLW8geGNfZG9tX2J6aW1hZ2Vs
b2FkZXIubyB4Y19kb21fYnppbWFnZWxvYWRlci5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQg
LU1GIC54Y19kb21fYmlubG9hZGVyLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJH
RUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VS
Q0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90
eXBlcyAtSS4gLUkvbQ0KbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8u
Li8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21fYmlubG9hZGVyLm8g
eGNfZG9tX2JpbmxvYWRlci5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54Y19kb21f
Y29tcGF0X2xpbnV4Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4v
Li4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4g
LQ0KSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29s
cy9pbmNsdWRlIC1wdGhyZWFkICAtYyAtbyB4Y19kb21fY29tcGF0X2xpbnV4Lm8geGNfZG9t
X2NvbXBhdF9saW51eC5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54Y19kb21feDg2
Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1v
bi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbW50L3ZtLw0K
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1w
dGhyZWFkICAtYyAtbyB4Y19kb21feDg2Lm8geGNfZG9tX3g4Ni5jIA0KZ2NjICAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNf
XyAtTQ0KTUQgLU1GIC54Y19jcHVpZF94ODYuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05V
X1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1w
cm90b3R5cGVzIC1JLiAtSS9tbnQvdg0KbS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xp
YnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1jIC1vIHhjX2NwdWlkX3g4Ni5v
IHhjX2NwdWlkX3g4Ni5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54Y19odm1fYnVp
bGRfeDg2Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0Ug
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVu
L2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbQ0K
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNs
dWRlIC1wdGhyZWFkICAtYyAtbyB4Y19odm1fYnVpbGRfeDg2Lm8geGNfaHZtX2J1aWxkX3g4
Ni5jIA0KYXIgcmMgbGlieGVuZ3Vlc3QuYSB4Z19wcml2YXRlLm8geGNfc3VzcGVuZC5vIHhj
X2RvbWFpbl9yZXN0b3JlLm8geGNfZG9tYWluX3NhdmUubyB4Y19vZmZsaW5lX3BhZ2UubyB4
Y19jb21wcmVzc2lvbi5vIGxpYmVsZi10b29scy5vIGxpYmVsZi1sb2FkZXIubyBsaWJlbGYt
ZG9taW5mby5vIGxpYmVsZi1yZWxvYw0KYXRlLm8geGNfZG9tX2NvcmUubyB4Y19kb21fYm9v
dC5vIHhjX2RvbV9lbGZsb2FkZXIubyB4Y19kb21fYnppbWFnZWxvYWRlci5vIHhjX2RvbV9i
aW5sb2FkZXIubyB4Y19kb21fY29tcGF0X2xpbnV4Lm8geGNfZG9tX3g4Ni5vIHhjX2NwdWlk
X3g4Ni5vIHhjX2h2bV9idWlsZF94ODYubw0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1X
YWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg
LVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQg
LU1GIC54Z19wcml2YXRlLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJ
TEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0Ug
IC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBl
cyAtSS4gLQ0KSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8u
Li90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Z19wcml2YXRlLm9waWMg
eGdfcHJpdmF0ZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19zdXNw
ZW5kLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0Ug
LWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVu
L2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLQ0KSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9pbmNs
dWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19zdXNwZW5kLm9waWMgeGNfc3VzcGVuZC5j
IA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21haW5fcmVzdG9yZS5v
cGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21t
b24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZQ0KcyAtSS4gLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAt
cHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9tYWluX3Jlc3RvcmUub3BpYyB4Y19kb21haW5f
cmVzdG9yZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21haW5f
c2F2ZS5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hl
bi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLQ0KSS4gLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9tYWluX3NhdmUub3BpYyB4Y19kb21h
aW5fc2F2ZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02
NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXBy
b3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0
LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19vZmZsaW5l
X3BhZ2Uub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJD
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94
ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIA0KLUkuIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2lu
Y2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhjX29mZmxpbmVfcGFnZS5vcGljIHhjX29m
ZmxpbmVfcGFnZS5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19jb21w
cmVzc2lvbi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4u
L3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLQ0KSS4g
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfY29tcHJlc3Npb24ub3BpYyB4Y19j
b21wcmVzc2lvbi5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC5saWJlbGYt
dG9vbHMub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJD
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJDRSAgLUkuLi8uLi94
ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5cGVzIC1JLg0KIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2lu
Y2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIGxpYmVsZi10b29scy5vcGljIC4uLy4uL3hl
bi9jb21tb24vbGliZWxmL2xpYmVsZi10b29scy5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19f
IC1NTUQgLU1GIC5saWJlbGYtbG9hZGVyLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dO
VV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Npbmct
cHJvdG90eXBlcyAtSQ0KLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyBsaWJlbGYt
bG9hZGVyLm9waWMgLi4vLi4veGVuL2NvbW1vbi9saWJlbGYvbGliZWxmLWxvYWRlci5jIA0K
Z2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0
cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdk
ZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJs
ZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC5saWJlbGYtZG9taW5mby5vcGljLmQg
IC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGli
ZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLQ0KSS4gLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVh
ZCAgLWZQSUMgLWMgLW8gbGliZWxmLWRvbWluZm8ub3BpYyAuLi8uLi94ZW4vY29tbW9uL2xp
YmVsZi9saWJlbGYtZG9taW5mby5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1G
IC5saWJlbGYtcmVsb2NhdGUub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdF
RklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLURfR05VX1NPVVJD
RSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlzc2luZy1wcm90b3R5
cGVzIA0KLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhjLy4u
Ly4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIGxpYmVsZi1yZWxvY2F0
ZS5vcGljIC4uLy4uL3hlbi9jb21tb24vbGliZWxmL2xpYmVsZi1yZWxvY2F0ZS5jIA0KZ2Nj
ICAtRFBJQyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1EX19YRU5fVE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21fY29yZS5vcGljLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1X
ZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlwZXMgLUkuIA0KLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQ
SUMgLWMgLW8geGNfZG9tX2NvcmUub3BpYyB4Y19kb21fY29yZS5jIA0KZ2NjICAtRFBJQyAt
TzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2lu
ZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1h
ZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5f
VE9PTA0KU19fIC1NTUQgLU1GIC54Y19kb21fYm9vdC5vcGljLmQgIC1EX0xBUkdFRklMRV9T
T1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdt
aXNzaW5nLXByb3RvdHlwZXMgLUkuIA0KLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8g
eGNfZG9tX2Jvb3Qub3BpYyB4Y19kb21fYm9vdC5jIA0KZ2NjICAtRFBJQyAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTA0KU19f
IC1NTUQgLU1GIC54Y19kb21fZWxmbG9hZGVyLm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJD
RSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1E
X0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3Np
bmctcHJvdG90eXBlcw0KIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9saWJ4Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19k
b21fZWxmbG9hZGVyLm9waWMgeGNfZG9tX2VsZmxvYWRlci5jIA0KZ2NjICAtRFBJQyAtTzEg
LWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9P
TA0KU19fIC1NTUQgLU1GIC54Y19kb21fYnppbWFnZWxvYWRlci5vcGljLmQgIC1EX0xBUkdF
RklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGlu
Zy1jYWxscyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJy
b3IgLVdtaXNzaW5nLXByb3RvdA0KeXBlcyAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAtREhBVkVf
QlpMSUIgLWxiejIgIC1mUElDIC1jIC1vIHhjX2RvbV9iemltYWdlbG9hZGVyLm9waWMgeGNf
ZG9tX2J6aW1hZ2Vsb2FkZXIuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAtTU1EIC1NRiAu
eGNfZG9tX2JpbmxvYWRlci5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09VUkNF
ICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3RvdHlw
ZXMNCiAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9tX2JpbmxvYWRl
ci5vcGljIHhjX2RvbV9iaW5sb2FkZXIuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAtTU1E
IC1NRiAueGNfZG9tX2NvbXBhdF9saW51eC5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0Ug
LURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9H
TlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5n
LXByb3RvdHkNCnBlcyAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfZG9t
X2NvbXBhdF9saW51eC5vcGljIHhjX2RvbV9jb21wYXRfbGludXguYyANCmdjYyAgLURQSUMg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0wNClNfXyAtTU1EIC1NRiAueGNfZG9tX3g4Ni5vcGljLmQgIC1EX0xBUkdFRklMRV9T
T1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxs
cyAtRF9HTlVfU09VUkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdt
aXNzaW5nLXByb3RvdHlwZXMgLUkuIC0NCkkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8g
eGNfZG9tX3g4Ni5vcGljIHhjX2RvbV94ODYuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAt
TU1EIC1NRiAueGNfY3B1aWRfeDg2Lm9waWMuZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9M
QVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9T
T1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1vbi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJv
dG90eXBlcyAtSS4NCiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4
Yy8uLi8uLi90b29scy9pbmNsdWRlIC1wdGhyZWFkICAtZlBJQyAtYyAtbyB4Y19jcHVpZF94
ODYub3BpYyB4Y19jcHVpZF94ODYuYyANCmdjYyAgLURQSUMgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAtTU1EIC1N
RiAueGNfaHZtX2J1aWxkX3g4Ni5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFS
R0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtRF9HTlVfU09V
UkNFICAtSS4uLy4uL3hlbi9jb21tb24vbGliZWxmIC1XZXJyb3IgLVdtaXNzaW5nLXByb3Rv
dHlwZXMNCiAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMv
Li4vLi4vdG9vbHMvaW5jbHVkZSAtcHRocmVhZCAgLWZQSUMgLWMgLW8geGNfaHZtX2J1aWxk
X3g4Ni5vcGljIHhjX2h2bV9idWlsZF94ODYuYyANCmdjYyAgICAgLVdsLC1zb25hbWUgLVds
LGxpYnhlbmd1ZXN0LnNvLjQuMiAtc2hhcmVkIC1vIGxpYnhlbmd1ZXN0LnNvLjQuMi4wIHhn
X3ByaXZhdGUub3BpYyB4Y19zdXNwZW5kLm9waWMgeGNfZG9tYWluX3Jlc3RvcmUub3BpYyB4
Y19kb21haW5fc2F2ZS5vcGljIHhjX29mZmxpbmVfcGFnZS5vcGljIHhjX2NvbXANCnJlc3Np
b24ub3BpYyBsaWJlbGYtdG9vbHMub3BpYyBsaWJlbGYtbG9hZGVyLm9waWMgbGliZWxmLWRv
bWluZm8ub3BpYyBsaWJlbGYtcmVsb2NhdGUub3BpYyB4Y19kb21fY29yZS5vcGljIHhjX2Rv
bV9ib290Lm9waWMgeGNfZG9tX2VsZmxvYWRlci5vcGljIHhjX2RvbV9iemltYWdlbG9hZGVy
Lm9waWMgeGNfZG8NCm1fYmlubG9hZGVyLm9waWMgeGNfZG9tX2NvbXBhdF9saW51eC5vcGlj
IHhjX2RvbV94ODYub3BpYyB4Y19jcHVpZF94ODYub3BpYyB4Y19odm1fYnVpbGRfeDg2Lm9w
aWMgLURIQVZFX0JaTElCIC1sYnoyIC1seiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvbGlieGMNCi9saWJ4ZW5jdHJsLnNvICANCmxuIC1z
ZiBsaWJ4ZW5ndWVzdC5zby40LjIuMCBsaWJ4ZW5ndWVzdC5zby40LjINCmxuIC1zZiBsaWJ4
ZW5ndWVzdC5zby40LjIgbGlieGVuZ3Vlc3Quc28NCmdjYyAgLURQSUMgLU8xIC1mbm8tb21p
dC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5
OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVt
ZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0wNClNfXyAt
TU1EIC1NRiAueGVuY3RybF9vc2RlcF9FTk9TWVMub3BpYy5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
LURfR05VX1NPVVJDRSAgLUkuLi8uLi94ZW4vY29tbW9uL2xpYmVsZiAtV2Vycm9yIC1XbWlz
c2luZy1wcm90b3QNCnlwZXMgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLXB0aHJlYWQgIC1mUElDIC1jIC1vIHhl
bmN0cmxfb3NkZXBfRU5PU1lTLm9waWMgeGVuY3RybF9vc2RlcF9FTk9TWVMuYyANCmdjYyAt
ZyAgICAgLXNoYXJlZCAtbyB4ZW5jdHJsX29zZGVwX0VOT1NZUy5zbyB4ZW5jdHJsX29zZGVw
X0VOT1NZUy5vcGljIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8u
Li8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIA0KbWFrZVs0XTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4YycNCi9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4Yy8uLi8uLi90b29scy9jcm9zcy1p
bnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9p
bnN0YWxsL3Vzci9saWINCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4
Yy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlDQovbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
bTA3NTUgLXAgbGlieGVuY3RybC5zby40LjIuMCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9saWINCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9saWJ4Yy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCBsaWJ4ZW5j
dHJsLmEgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGli
DQpsbiAtc2YgbGlieGVuY3RybC5zby40LjIuMCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9saWIvbGlieGVuY3RybC5zby40LjINCmxuIC1zZiBsaWJ4
ZW5jdHJsLnNvLjQuMiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9saWIvbGlieGVuY3RybC5zbw0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbmN0cmwu
aCB4ZW5jdHJsb3NkZXAuaCB4ZW50b29sbG9nLmggL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZQ0KL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2xpYnhjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1IC1wIGxp
Ynhlbmd1ZXN0LnNvLjQuMi4wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2xpYg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhj
Ly4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0IC1wIGxpYnhlbmd1ZXN0LmEgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliDQpsbiAtc2Yg
bGlieGVuZ3Vlc3Quc28uNC4yLjAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3Qv
aW5zdGFsbC91c3IvbGliL2xpYnhlbmd1ZXN0LnNvLjQuMg0KbG4gLXNmIGxpYnhlbmd1ZXN0
LnNvLjQuMiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9s
aWIvbGlieGVuZ3Vlc3Quc28NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9s
aWJ4Yy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW5ndWVzdC5oIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2luY2x1ZGUNCm1h
a2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGMnDQptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnDQptYWtlIC1DIGZsYXNrIGluc3Rh
bGwNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL2ZsYXNrJw0KbWFrZVs0XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2snDQptYWtlIC1DIHV0aWxzIGlu
c3RhbGwNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzJw0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1l
LXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxs
IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdu
by11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1G
IC5sb2FkcG9saWN5Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9T
T1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzICAtV2FsbCAtZyAtV2Vycm9yIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4uLy4uLy4u
L3Rvb2xzL2xpYg0KeGMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxh
c2svdXRpbHMvLi4vLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8gbG9hZHBvbGljeS5vIGxv
YWRwb2xpY3kuYyANCmdjYyAgICAgbG9hZHBvbGljeS5vICAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4vdG9vbHMvbGlieGMvbGlieGVu
Y3RybC5zbyAtbyBmbGFzay1sb2FkcG9saWN5DQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUt
cG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwg
LVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25v
LXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYg
LnNldGVuZm9yY2Uuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NP
VVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XYWxsIC1nIC1XZXJyb3IgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4v
dG9vbHMvbGliDQp4YyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFz
ay91dGlscy8uLi8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyBzZXRlbmZvcmNlLm8gc2V0
ZW5mb3JjZS5jIA0KZ2NjICAgICBzZXRlbmZvcmNlLm8gIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5j
dHJsLnNvIC1vIGZsYXNrLXNldGVuZm9yY2UNCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1w
b2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAt
V3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8t
dW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAu
Z2V0ZW5mb3JjZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09V
UkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdhbGwgLWcgLVdlcnJvciAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90
b29scy9saWINCnhjIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNr
L3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIGdldGVuZm9yY2UubyBnZXRl
bmZvcmNlLmMgDQpnY2MgICAgIGdldGVuZm9yY2UubyAgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0
cmwuc28gLW8gZmxhc2stZ2V0ZW5mb3JjZQ0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5s
YWJlbC1wY2kuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJD
RSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XYWxsIC1nIC1XZXJyb3IgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4vdG9v
bHMvbGlieA0KYyAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91
dGlscy8uLi8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyBsYWJlbC1wY2kubyBsYWJlbC1w
Y2kuYyANCmdjYyAgICAgbGFiZWwtcGNpLm8gIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNv
IC1vIGZsYXNrLWxhYmVsLXBjaQ0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5nZXQtYm9v
bC5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAgLVdhbGwgLWcgLVdlcnJvciAtSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29scy9saWJ4
Yw0KIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4u
Ly4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIGdldC1ib29sLm8gZ2V0LWJvb2wuYyANCmdj
YyAgICAgZ2V0LWJvb2wubyAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zs
YXNrL3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gLW8gZmxhc2st
Z2V0LWJvb2wNCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
IC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAuc2V0LWJvb2wuby5kICAtRF9M
QVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNp
YmxpbmctY2FsbHMgIC1XYWxsIC1nIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4vdG9vbHMvbGlieGMNCiAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8uLi8uLi8uLi90b29s
cy9pbmNsdWRlICAtYyAtbyBzZXQtYm9vbC5vIHNldC1ib29sLmMgDQpnY2MgICAgIHNldC1i
b29sLm8gIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzay91dGlscy8u
Li8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIC1vIGZsYXNrLXNldC1ib29sDQov
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmxhc2svdXRpbHMvLi4vLi4vLi4v
dG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2Jpbg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL2ZsYXNrL3V0aWxzLy4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0w
NzU1IC1wIGZsYXNrLWxvYWRwb2xpY3kgZmxhc2stc2V0ZW5mb3JjZSBmbGFzay1nZXRlbmZv
cmNlIGZsYXNrLWxhYmVsLXBjaSBmbGFzay1nZXQtYm9vbCBmbGFzay1zZXQtYg0Kb29sIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NiaW4NCm1ha2Vb
NV06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvZmxhc2svdXRpbHMnDQptYWtlWzRdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2ZsYXNrJw0KbWFrZVszXTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9mbGFzaycNCm1ha2Vb
Ml06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMnDQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scycNCm1ha2UgLUMgeGVuc3RvcmUgaW5zdGFsbA0KbWFrZVszXTogRW50
ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVu
c3RvcmUnDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbnN0b3JlX2NsaWVudC5vLmQg
IC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkvDQptbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9pbmNsdWRlICAt
YyAtbyB4ZW5zdG9yZV9jbGllbnQubyB4ZW5zdG9yZV9jbGllbnQuYyANCmdjYyAgLURQSUMg
LU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24t
YWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVO
X1RPT0wNClNfXyAtTU1EIC1NRiAueHMub3BpYy5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1E
X0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJy
b3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4u
Ly4uL3Rvb2xzL2xpYnhjIC1JL21udC8NCnZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
eGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAtRFVTRV9QVEhSRUFEICAtZlBJQyAtYyAt
byB4cy5vcGljIHhzLmMgDQpnY2MgIC1EUElDIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRl
ciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MDQpTX18gLU1NRCAtTUYgLnhzX2xp
Yi5vcGljLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkvDQpt
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9p
bmNsdWRlICAtZlBJQyAtYyAtbyB4c19saWIub3BpYyB4c19saWIuYyANCmdjYyAgICAgLVds
LC1zb25hbWUgLVdsLGxpYnhlbnN0b3JlLnNvLjMuMCAtc2hhcmVkIC1vIGxpYnhlbnN0b3Jl
LnNvLjMuMC4xIHhzLm9waWMgeHNfbGliLm9waWMgIC1scHRocmVhZCANCmxuIC1zZiBsaWJ4
ZW5zdG9yZS5zby4zLjAuMSBsaWJ4ZW5zdG9yZS5zby4zLjANCmxuIC1zZiBsaWJ4ZW5zdG9y
ZS5zby4zLjAgbGlieGVuc3RvcmUuc28NCmdjYyAgICAgeGVuc3RvcmVfY2xpZW50Lm8gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL3hl
bnN0b3JlL2xpYnhlbnN0b3JlLnNvICAtbyB4ZW5zdG9yZSANCmxuIC1mIHhlbnN0b3JlIHhl
bnN0b3JlLWV4aXN0cw0KbG4gLWYgeGVuc3RvcmUgeGVuc3RvcmUtbGlzdA0KbG4gLWYgeGVu
c3RvcmUgeGVuc3RvcmUtcmVhZA0KbG4gLWYgeGVuc3RvcmUgeGVuc3RvcmUtcm0NCmxuIC1m
IHhlbnN0b3JlIHhlbnN0b3JlLWNobW9kDQpsbiAtZiB4ZW5zdG9yZSB4ZW5zdG9yZS13cml0
ZQ0KbG4gLWYgeGVuc3RvcmUgeGVuc3RvcmUtbHMNCmxuIC1mIHhlbnN0b3JlIHhlbnN0b3Jl
LXdhdGNoDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8t
c3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAt
V2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlh
YmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbnN0b3JlX2NvbnRyb2wuby5k
ICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGlt
aXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JDQovbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAg
LWMgLW8geGVuc3RvcmVfY29udHJvbC5vIHhlbnN0b3JlX2NvbnRyb2wuYyANCmdjYyAgICAg
eGVuc3RvcmVfY29udHJvbC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy94ZW5zdG9yZS9saWJ4ZW5zdG9yZS5zbyAgLW8geGVuc3Rv
cmUtY29udHJvbCANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcg
LWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5
cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQt
dmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueHMuby5kICAtRF9MQVJH
RUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veGUNCm4tdW5z
dGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geHMu
byB4cy5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54c19saWIuby5kICAtRF9MQVJH
RUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxp
bmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZQ0Kbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geHNf
bGliLm8geHNfbGliLmMgDQphciByY3MgbGlieGVuc3RvcmUuYSB4cy5vIHhzX2xpYi5vDQpn
Y2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFs
aWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0
aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURf
X1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhzX3RkYl9kdW1wLm8uZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzICAtV2Vycm9yIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvDQp2bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIHhzX3RkYl9k
dW1wLm8geHNfdGRiX2R1bXAuYyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAudXRpbHMu
by5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94
ZW4NCi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVk
ZSAgLWMgLW8gdXRpbHMubyB1dGlscy5jIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1X
c3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11
bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC50
ZGIuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92
bS94ZW4veA0KZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5j
bHVkZSAgLWMgLW8gdGRiLm8gdGRiLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnRh
bGxvYy5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkvbW50
L3ZtL3hlDQpuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9p
bmNsdWRlICAtYyAtbyB0YWxsb2MubyB0YWxsb2MuYyANCmdjYyAgICAgeHNfdGRiX2R1bXAu
byB1dGlscy5vIHRkYi5vIHRhbGxvYy5vIC1vIHhzX3RkYl9kdW1wIA0KZ2NjICAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNf
XyAtTQ0KTUQgLU1GIC54ZW5zdG9yZWRfY29yZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0Ug
LURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdl
cnJvciAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUv
Li4vLi4vdG9vbHMvbGlieGMgLUkvbQ0KbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy94ZW5zdG9yZS8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyB4ZW5zdG9yZWRfY29yZS5v
IHhlbnN0b3JlZF9jb3JlLmMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbnN0b3Jl
ZF93YXRjaC5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNF
IC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkv
DQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29s
cy9pbmNsdWRlICAtYyAtbyB4ZW5zdG9yZWRfd2F0Y2gubyB4ZW5zdG9yZWRfd2F0Y2guYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuc3RvcmVkX2RvbWFpbi5vLmQgIC1EX0xB
UkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2li
bGluZy1jYWxscyAgLVdlcnJvciAtSS4gLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMgLUkNCi9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyB4
ZW5zdG9yZWRfZG9tYWluLm8geGVuc3RvcmVkX2RvbWFpbi5jIA0KZ2NjICAtTzEgLWZuby1v
bWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdu
dTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0
ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAt
TQ0KTUQgLU1GIC54ZW5zdG9yZWRfdHJhbnNhY3Rpb24uby5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
IC1XZXJyb3IgLUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0
b3JlLy4uLy4uL3Rvb2xzL2xpYg0KeGMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geGVuc3RvcmVkX3Ry
YW5zYWN0aW9uLm8geGVuc3RvcmVkX3RyYW5zYWN0aW9uLmMgDQpnY2MgIC1PMSAtZm5vLW9t
aXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251
OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1N
DQpNRCAtTUYgLmhhc2h0YWJsZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS4g
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9v
bHMvbGlieGMgLUkvbW50L3ZtDQoveGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9y
ZS8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbyBoYXNodGFibGUubyBoYXNodGFibGUuYyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuc3RvcmVkX2xpbnV4Lm8uZCAgLURfTEFS
R0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJs
aW5nLWNhbGxzICAtV2Vycm9yIC1JLiAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9saWJ4YyAtSS8NCm1udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2luY2x1ZGUgIC1jIC1vIHhl
bnN0b3JlZF9saW51eC5vIHhlbnN0b3JlZF9saW51eC5jIA0KZ2NjICAtTzEgLWZuby1vbWl0
LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5
IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1l
bnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0K
TUQgLU1GIC54ZW5zdG9yZWRfcG9zaXguby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xB
UkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3Ig
LUkuIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4u
L3Rvb2xzL2xpYnhjIC1JLw0KbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVu
c3RvcmUvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geGVuc3RvcmVkX3Bvc2l4Lm8geGVu
c3RvcmVkX3Bvc2l4LmMgDQpnY2MgICAgIHhlbnN0b3JlZF9jb3JlLm8geGVuc3RvcmVkX3dh
dGNoLm8geGVuc3RvcmVkX2RvbWFpbi5vIHhlbnN0b3JlZF90cmFuc2FjdGlvbi5vIHhzX2xp
Yi5vIHRhbGxvYy5vIHV0aWxzLm8gdGRiLm8gaGFzaHRhYmxlLm8geGVuc3RvcmVkX2xpbnV4
Lm8geGVuc3RvcmVkX3Bvc2l4Lm8gL21udC92bS94ZW4vDQp4ZW4tdW5zdGFibGUuaGcvdG9v
bHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAgLW8geGVuc3Rv
cmVkIA0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4u
L3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2Jpbg0KL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1
IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NiaW4N
Ci9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUg
LXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVk
ZS94ZW5zdG9yZS1jb21wYXQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Zhci9ydW4veGVuc3RvcmVkDQov
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMv
Y3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC92YXIvbGliL3hlbnN0b3JlZA0KL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1
IC1wIHhlbnN0b3JlZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9zYmluDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUv
Li4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgeGVuc3RvcmUtY29udHJvbCAv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCi9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5zdG9yZS8uLi8uLi90b29scy9jcm9z
cy1pbnN0YWxsIC1tMDc1NSAtcCB4ZW5zdG9yZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCnNldCAtZSA7IGZvciBjIGluIHhlbnN0b3JlLWV4
aXN0cyB4ZW5zdG9yZS1saXN0IHhlbnN0b3JlLXJlYWQgeGVuc3RvcmUtcm0geGVuc3RvcmUt
Y2htb2QgeGVuc3RvcmUtd3JpdGUgeGVuc3RvcmUtbHMgeGVuc3RvcmUtd2F0Y2ggOyBkbyBc
DQogICAgICAgIGxuIC1mIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvdXNyL2Jpbi94ZW5zdG9yZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9p
bnN0YWxsL3Vzci9iaW4vJHtjfSA7IFwNCiBkb25lDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3
NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGli
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVuc3RvcmUvLi4vLi4vdG9v
bHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgbGlieGVuc3RvcmUuc28uMy4wLjEgL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliDQpsbiAtc2YgbGli
eGVuc3RvcmUuc28uMy4wLjEgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC91c3IvbGliL2xpYnhlbnN0b3JlLnNvLjMuMA0KbG4gLXNmIGxpYnhlbnN0b3JlLnNv
LjMuMCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9saWIv
bGlieGVuc3RvcmUuc28NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW5z
dG9yZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCBsaWJ4ZW5zdG9yZS5h
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYg0KL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNjQ0IC1wIHhlbnN0b3JlLmggL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvaW5jbHVkZQ0KL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL3hlbnN0b3JlLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNjQ0
IC1wIHhlbnN0b3JlX2xpYi5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2lu
c3RhbGwvdXNyL2luY2x1ZGUNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94
ZW5zdG9yZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCBjb21wYXQveHMu
aCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRl
L3hlbnN0b3JlLWNvbXBhdC94cy5oDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMveGVuc3RvcmUvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgY29tcGF0
L3hzX2xpYi5oIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNy
L2luY2x1ZGUveGVuc3RvcmUtY29tcGF0L3hzX2xpYi5oDQpsbiAtc2YgeGVuc3RvcmUtY29t
cGF0L3hzLmggIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNy
L2luY2x1ZGUveHMuaA0KbG4gLXNmIHhlbnN0b3JlLWNvbXBhdC94c19saWIuaCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9pbmNsdWRlL3hzX2xpYi5o
DQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL3hlbnN0b3JlJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVyaW5nIGRpcmVj
dG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZSAtQyBtaXNj
IGluc3RhbGwNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MnDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p
bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdz
dHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVu
dXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhl
bnBlcmYuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAt
Zm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVu
L3hlbi11DQpuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1
ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29s
cy94ZW5zdG9yZSAtSS9tbnQvdm0veGVuDQoveGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2Mv
Li4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyB4ZW5wZXJmLm8geGVucGVyZi5jIA0KZ2NjICAg
ICAtbyB4ZW5wZXJmIHhlbnBlcmYubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIA0KZ2NjICAtTzEgLWZu
by1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3Rk
PWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1z
dGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNf
XyAtTQ0KTUQgLU1GIC54ZW5wbS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VG
SUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2xpYnhj
IC1JL21udC92bS94ZW4veGVuLXVucw0KdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29s
cy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9t
aXNjLy4uLy4uL3Rvb2xzL3hlbnN0b3JlIC1JL21udC92bS94ZW4veA0KZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMgIC1jIC1vIHhlbnBtLm8geGVucG0u
YyANCmdjYyAgICAgLW8geGVucG0geGVucG0ubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNvIA0KZ2NjIC1P
MSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5n
IC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFm
dGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9U
T09MU19fIC1NTQ0KRCAtTUYgLnhlbi10bWVtLWxpc3QtcGFyc2UuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2Mv
Li4vLi4vdG9vbHMvbGlieGMgLUkvbW50L3ZtLw0KeGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUgLUkvbQ0KbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scyAgICAg
ICB4ZW4tdG1lbS1saXN0LXBhcnNlLmMgICAtbyB4ZW4tdG1lbS1saXN0LXBhcnNlDQpnY2Mg
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hF
Tl9UT09MU19fIC1NDQpNRCAtTUYgLmd0cmFjZXZpZXcuby5kICAtRF9MQVJHRUZJTEVfU09V
UkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMg
IC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8u
Li90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuL3hlDQpuLXVuc3RhYmxlLmhnL3Rvb2xzL21p
c2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0vDQp4ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyBn
dHJhY2V2aWV3Lm8gZ3RyYWNldmlldy5jIA0KZ2NjICAgICAtbyBndHJhY2V2aWV3IGd0cmFj
ZXZpZXcubyAtbG5jdXJzZXMgDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAt
bTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1i
dXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLmd0cmFjZXN0
YXQuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5v
LW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuL3hl
DQpuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUg
LUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94
ZW5zdG9yZSAtSS9tbnQvdm0vDQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4v
Li4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9t
aXNjLy4uLy4uL3Rvb2xzICAtYyAtbyBndHJhY2VzdGF0Lm8gZ3RyYWNlc3RhdC5jIA0KZ2Nj
ICAgICAtbyBndHJhY2VzdGF0IGd0cmFjZXN0YXQubyANCmdjYyAgLU8xIC1mbm8tb21pdC1m
cmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAt
V2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50
IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1E
IC1NRiAueGVubG9ja3Byb2Yuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklM
RTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAt
SS9tbnQvdm0veGVuL3gNCmVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlz
Yy8uLi8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0NCi94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyB4ZW5sb2NrcHJvZi5vIHhl
bmxvY2twcm9mLmMgDQpnY2MgICAgIC1vIHhlbmxvY2twcm9mIHhlbmxvY2twcm9mLm8gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvbGlieGMv
bGlieGVuY3RybC5zbyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQg
LWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90
b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1z
ZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVud2F0Y2hkb2dk
Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvbGlieGMgLUkvbW50L3ZtL3hlbi8NCnhl
bi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVu
c3RvcmUgLUkvbW50L3YNCm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlz
Yy8uLi8uLi90b29scyAgLWMgLW8geGVud2F0Y2hkb2dkLm8geGVud2F0Y2hkb2dkLmMgDQpn
Y2MgICAgIC1vIHhlbndhdGNoZG9nZCB4ZW53YXRjaGRvZ2QubyAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5jdHJsLnNv
IA0KZ2NjIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1hFTl9UT09MU19fIC1NTQ0KRCAtTUYgLnhlbi1kZXRlY3QuZCAgLURfTEFSR0VGSUxF
X1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNh
bGxzICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2Mv
Li4vLi4vdG9vbHMvbGlieGMgLUkvbW50L3ZtL3hlbi94ZW4tdQ0KbnN0YWJsZS5oZy90b29s
cy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUgLUkvbW50L3ZtL3hl
bg0KL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scyAgICAg
ICB4ZW4tZGV0ZWN0LmMgICAtbyB4ZW4tZGV0ZWN0DQpnY2MgIC1PMSAtZm5vLW9taXQtZnJh
bWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdh
bGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAt
V25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAt
TUYgLnhlbi1odm1jdHguby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0
X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9t
bnQvdm0veGVuL3hlDQpuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rv
b2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8u
Li8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0vDQp4ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzICAtYyAtbyB4ZW4taHZtY3R4Lm8geGVuLWh2
bWN0eC5jIA0KZ2NjICAgICAtbyB4ZW4taHZtY3R4IHhlbi1odm1jdHgubyAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5j
dHJsLnNvIA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5v
LXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMg
LVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJp
YWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC54ZW4taHZtY3Jhc2guby5kICAt
RF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXpl
LXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbWlzYy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuLw0KeGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94ZW5zdG9yZSAt
SS9tbnQvdg0KbS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMv
aW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4u
L3Rvb2xzICAtYyAtbyB4ZW4taHZtY3Jhc2gubyB4ZW4taHZtY3Jhc2guYyANCmdjYyAgICAg
LW8geGVuLWh2bWNyYXNoIHhlbi1odm1jcmFzaC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gDQpnY2Mg
IC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFz
aW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9u
LWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hF
Tl9UT09MU19fIC1NDQpNRCAtTUYgLnhlbi1sb3dtZW1kLm8uZCAgLURfTEFSR0VGSUxFX1NP
VVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
ICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4v
Li4vdG9vbHMvbGlieGMgLUkvbW50L3ZtL3hlbi94DQplbi11bnN0YWJsZS5oZy90b29scy9t
aXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3Rh
YmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUgLUkvbW50L3ZtDQoveGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scyAgLWMgLW8g
eGVuLWxvd21lbWQubyB4ZW4tbG93bWVtZC5jIA0KZ2NjICAgICAtbyB4ZW4tbG93bWVtZCB4
ZW4tbG93bWVtZC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4u
Ly4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMveGVuc3RvcmUvbGlieGVuc3Rvcg0KZS5zbyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuLWhwdG9vbC5vLmQgIC1EX0xBUkdFRklM
RV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAgLVdlcnJvciAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNj
Ly4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veGUNCm4tdW5zdGFibGUuaGcvdG9v
bHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL3hlbnN0b3JlIC1JL21udC92bS8N
Cnhlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy9pbmNsdWRlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMgIC1j
IC1vIHhlbi1ocHRvb2wubyB4ZW4taHB0b29sLmMgDQpnY2MgICAgIC1vIHhlbi1ocHRvb2wg
eGVuLWhwdG9vbC5vIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4u
Ly4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gL21udC92bS94ZW4veGVuLXVuc3RhYmxl
LmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuZ3Vlc3Quc28gDQovbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29scy94ZW5zdG9y
ZS9saWJ4ZW5zdG9yZS5zbyANCnNldCAtZTsgZm9yIGQgaW4gOyBkbyBtYWtlIC1DICRkOyBk
b25lDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9taXNjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NiaW4NCi9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3Rh
bGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvdXNyL2xpYi94ZW4vYmluDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bWlzYy8uLi8uLi90b29scy9weXRob24vaW5zdGFsbC13cmFwICIvdXNyL2Jpbi9weXRob24i
IC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNzU1IC1wIHhlbmNvbnMgeGVuLWRlDQp0ZWN0IC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2Jpbg0KL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL21pc2MvLi4vLi4vdG9vbHMvcHl0aG9uL2luc3RhbGwtd3Jh
cCAiL3Vzci9iaW4vcHl0aG9uIiAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
bWlzYy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDc1NSAtcCB4bSB4ZW4tYnVndG9v
bA0KIHhlbi1weXRob24tcGF0aCB4ZW5kIHhlbnBlcmYgeHN2aWV3IHhlbnBtIHhlbi10bWVt
LWxpc3QtcGFyc2UgZ3RyYWNldmlldyBndHJhY2VzdGF0IHhlbmxvY2twcm9mIHhlbndhdGNo
ZG9nZCB4ZW4tcmluZ3dhdGNoIHhlbi1odm1jdHggeGVuLWh2bWNyYXNoIHhlbi1sb3dtZW1k
IHhlbi1ocHRvb2wgL21udC92bQ0KL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxs
L3Vzci9zYmluDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYy8uLi8u
Li90b29scy9weXRob24vaW5zdGFsbC13cmFwICIvdXNyL2Jpbi9weXRob24iIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9taXNjLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3Rh
bGwgLW0wNzU1IC1wIHhlbnB2bmV0Ym9vdCAvDQptbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy9kaXN0L2luc3RhbGwvdXNyL2xpYi94ZW4vYmluDQpzZXQgLWU7IGZvciBkIGluIDsgZG8g
bWFrZSAtQyAkZCBpbnN0YWxsLXJlY3Vyc2U7IGRvbmUNCm1ha2VbM106IExlYXZpbmcgZGly
ZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbWlzYycNCm1ha2Vb
Ml06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMnDQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scycNCm1ha2UgLUMgZXhhbXBsZXMgaW5zdGFsbA0KbWFrZVszXTogRW50
ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZXhh
bXBsZXMnDQpbIC1kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwv
ZXRjL3hlbiBdIHx8IFwNCiAgICAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2V4YW1wbGVzLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hlbg0Kc2V0IC1l
OyBmb3IgaSBpbiBSRUFETUUgUkVBRE1FLmluY29tcGF0aWJpbGl0aWVzOyBcDQogICAgIGRv
IFsgLWUgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVu
LyRpIF0gfHwgXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZXhh
bXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgJGkgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVuOyBcDQogZG9uZQ0KWyAt
ZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9zaGFyZS9k
b2MveGVuIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvZG9jL3hl
bg0KWyAtZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9z
aGFyZS9kb2MveGVuL2V4YW1wbGVzIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
ZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91
c3Ivc2hhcmUvZG9jL3hlbi9leGFtcGxlcw0Kc2V0IC1lOyBmb3IgaSBpbiB4bWV4YW1wbGUx
ICB4bWV4YW1wbGUyIHhtZXhhbXBsZTMgeG1leGFtcGxlLmh2bSB4bWV4YW1wbGUuaHZtLXN0
dWJkb20geG1leGFtcGxlLnB2LWdydWIgeG1leGFtcGxlLm5iZCB4bWV4YW1wbGUudnRpIHhs
ZXhhbXBsZS5odm0geGxleGFtcGxlLnB2bGludXg7IFwNCiAgICAgZG8gWyAtZSAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9zaGFyZS9kb2MveGVuL2V4
YW1wbGVzLyRpIF0gfHwgXA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9v
bHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgJGkgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvZG9jL3hl
bi9leGFtcGxlczsgXA0KIGRvbmUNClsgLWQgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L2Rpc3QvaW5zdGFsbC9ldGMveGVuIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
ZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9l
dGMveGVuDQpbIC1kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwv
ZXRjL3hlbi9hdXRvIF0gfHwgXA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvZXhhbXBsZXMvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUg
LXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVuL2F1
dG8NCnNldCAtZTsgZm9yIGkgaW4geGVuZC1jb25maWcuc3hwIHhtLWNvbmZpZy54bWwgeGVu
ZC1wY2ktcXVpcmtzLnN4cCB4ZW5kLXBjaS1wZXJtaXNzaXZlLnN4cCB4bC5jb25mIGNwdXBv
b2w7IFwNCiAgICAgZG8gWyAtZSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9p
bnN0YWxsL2V0Yy94ZW4vJGkgXSB8fCBcDQogICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9leGFtcGxlcy8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAt
cCAkaSAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW47
IFwNCiBkb25lDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2V4YW1wbGVzJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3Rv
cnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVy
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFr
ZSAtQyBob3RwbHVnIGluc3RhbGwNCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcnDQptYWtlWzRdOiBFbnRl
cmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3Rw
bHVnJw0KbWFrZSAtQyBjb21tb24gaW5zdGFsbA0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9jb21tb24n
DQpybSAtZiAiaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8gIlNCSU5ESVI9XCIvdXNyL3Ni
aW5cIiIgPj4iaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8gIkJJTkRJUj1cIi91c3IvYmlu
XCIiID4+ImhvdHBsdWdwYXRoLnNoIi50bXA7ICBlY2hvICJMSUJFWEVDPVwiL3Vzci9saWIv
eGVuL2JpblwiIiA+PiJob3RwDQpsdWdwYXRoLnNoIi50bXA7ICBlY2hvICJMSUJESVI9XCIv
dXNyL2xpYlwiIiA+PiJob3RwbHVncGF0aC5zaCIudG1wOyAgZWNobyAiU0hBUkVESVI9XCIv
dXNyL3NoYXJlXCIiID4+ImhvdHBsdWdwYXRoLnNoIi50bXA7ICBlY2hvICJQUklWQVRFX0JJ
TkRJUj1cIi91c3IvbGliL3hlbi9iaW5cIiIgPj4iaG90cGx1DQpncGF0aC5zaCIudG1wOyAg
ZWNobyAiWEVORklSTVdBUkVESVI9XCIvdXNyL2xpYi94ZW4vYm9vdFwiIiA+PiJob3RwbHVn
cGF0aC5zaCIudG1wOyAgZWNobyAiWEVOX0NPTkZJR19ESVI9XCIvZXRjL3hlblwiIiA+PiJo
b3RwbHVncGF0aC5zaCIudG1wOyAgZWNobyAiWEVOX1NDUklQVF9ESVI9XCIvZXRjL3hlbi9z
DQpjcmlwdHNcIiIgPj4iaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8gIlhFTl9MT0NLX0RJ
Uj1cIi92YXIvbG9ja1wiIiA+PiJob3RwbHVncGF0aC5zaCIudG1wOyAgZWNobyAiWEVOX1JV
Tl9ESVI9XCIvdmFyL3J1bi94ZW5cIiIgPj4iaG90cGx1Z3BhdGguc2giLnRtcDsgIGVjaG8g
IlhFTl9QQUdJTkdfRElSPVwiDQovdmFyL2xpYi94ZW4veGVucGFnaW5nXCIiID4+ImhvdHBs
dWdwYXRoLnNoIi50bXA7ICAgICAgIGlmICEgY21wIC1zICJob3RwbHVncGF0aC5zaCIudG1w
ICJob3RwbHVncGF0aC5zaCI7IHRoZW4gbXYgLWYgImhvdHBsdWdwYXRoLnNoIi50bXAgImhv
dHBsdWdwYXRoLnNoIjsgZWxzZSBybSAtZiAiaG90cGx1Z3BhDQp0aC5zaCIudG1wOyBmaQ0K
WyAtZCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW4v
c2NyaXB0cyBdIHx8IFwNCiAgICAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2hvdHBsdWcvY29tbW9uLy4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0w
NzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hl
bi9zY3JpcHRzDQpzZXQgLWU7IGZvciBpIGluICJob3RwbHVncGF0aC5zaCI7IFwNCiAgICBk
byBcDQogICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvY29t
bW9uLy4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1IC1wICRpIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hlbi9zY3JpcHRzOyBcDQog
ZG9uZQ0Kc2V0IC1lOyBmb3IgaSBpbiA7IFwNCiAgICBkbyBcDQogICAgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvY29tbW9uLy4uLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNjQ0IC1wICRpIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9k
aXN0L2luc3RhbGwvZXRjL3hlbi9zY3JpcHRzOyBcDQogZG9uZQ0KbWFrZVs1XTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVn
L2NvbW1vbicNCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvaG90cGx1ZycNCm1ha2VbNF06IEVudGVyaW5nIGRpcmVjdG9y
eSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcnDQptYWtlIC1D
IExpbnV4IGluc3RhbGwNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvTGludXgnDQpbIC1kIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL2luaXQuZCBdIHx8IC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rv
b2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oDQpnL2Rpc3QvaW5zdGFsbC9ldGMvaW5pdC5kDQpbIC1kIC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL2RlZmF1bHQgXSB8fCAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9MaW51eC8uLi8uLi8uLi90b29scy9jcm9z
cy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuDQpoZy9k
aXN0L2luc3RhbGwvZXRjL2RlZmF1bHQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1
IC1wIGluaXQuZC94ZW5kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3Rh
bGwvZXRjL2luaXQuZA0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBs
dWcvTGludXgvLi4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgaW5pdC5k
L3hlbmRvbWFpbnMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9l
dGMvaW5pdC5kDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9M
aW51eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDc1NSAtcCBpbml0LmQvc3lz
Y29uZmlnLnhlbmRvbWFpbnMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC9ldGMvZGVmYXVsdC94ZW5kb21haW5zDQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvdG9vbHMvaG90cGx1Zy9MaW51eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1t
MDc1NSAtcCBpbml0LmQveGVuY29tbW9ucyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
ZGlzdC9pbnN0YWxsL2V0Yy9pbml0LmQNCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1
IC1wIGluaXQuZC9zeXNjb25maWcueGVuY29tbW9ucyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy9kZWZhdWx0L3hlbmNvbW1vbnMNCi9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Ny
b3NzLWluc3RhbGwgLW0wNzU1IC1wIGluaXQuZC94ZW4td2F0Y2hkb2cgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMvaW5pdC5kDQpbIC1kIC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3hlbi9zY3JpcHRzIF0gfHwg
XA0KICAgICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9M
aW51eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW4vc2NyaXB0cw0Kc2V0
IC1lOyBmb3IgaSBpbiBuZXR3b3JrLWJyaWRnZSB2aWYtYnJpZGdlIG5ldHdvcmstcm91dGUg
dmlmLXJvdXRlIG5ldHdvcmstbmF0IHZpZi1uYXQgdmlmMiB2aWYtc2V0dXAgYmxvY2sgYmxv
Y2stZW5iZCBibG9jay1uYmQgYmxrdGFwIHZ0cG0gdnRwbS1kZWxldGUgeGVuLWhvdHBsdWct
Y2xlYW51cCBleHRlcg0KbmFsLWRldmljZS1taWdyYXRlIHZzY3NpOyBcDQogICAgIGRvIFwN
CiAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBsdWcvTGludXgv
Li4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgJGkgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMveGVuL3NjcmlwdHM7IFwNCiBkb25l
DQpzZXQgLWU7IGZvciBpIGluIHhlbi1zY3JpcHQtY29tbW9uLnNoIGxvY2tpbmcuc2ggbG9n
Z2luZy5zaCB4ZW4taG90cGx1Zy1jb21tb24uc2ggeGVuLW5ldHdvcmstY29tbW9uLnNoIHZp
Zi1jb21tb24uc2ggYmxvY2stY29tbW9uLnNoIHZ0cG0tY29tbW9uLnNoIHZ0cG0taG90cGx1
Zy1jb21tb24uc2ggdnRwbS1tDQppZ3JhdGlvbi5zaCB2dHBtLWltcGw7IFwNCiAgICAgZG8g
XA0KICAgICAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvaG90cGx1Zy9MaW51
eC8uLi8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDY0NCAtcCAkaSAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL2V0Yy94ZW4vc2NyaXB0czsgXA0KIGRv
bmUNClsgLWQgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMv
aG90cGx1ZyBdIHx8IFwNCiAgICAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rv
b2xzL2hvdHBsdWcvTGludXgvLi4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3
NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMvaG90
cGx1Zw0Kc2V0IC1lOyBmb3IgaSBpbiB4ZW4tYmFja2VuZC5hZ2VudDsgXA0KICAgICBkbyBc
DQogICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4
Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLW0wNzU1IC1wICRpIC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL2hvdHBsdWc7IFwNCiBkb25lDQpb
IC1kIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3VkZXYg
XSB8fCBcDQogICAgICAgIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3Rw
bHVnL0xpbnV4Ly4uLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvZXRjL3VkZXYvcnVsZXMu
ZA0Kc2V0IC1lOyBmb3IgaSBpbiB4ZW4tYmFja2VuZC5ydWxlcyB4ZW5kLnJ1bGVzOyBcDQog
ICAgIGRvIFwNCiAgICAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2hvdHBs
dWcvTGludXgvLi4vLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgJGkgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC9ldGMvdWRldi9ydWxlcy5k
OyBcDQogZG9uZQ0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnL0xpbnV4Jw0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9ob3RwbHVnJw0K
bWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5o
Zy90b29scy9ob3RwbHVnJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVyaW5nIGRpcmVjdG9y
eSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZSAtQyB4ZW50cmFj
ZSBpbnN0YWxsDQptYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZScNCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFt
ZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2Fs
bCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1X
bm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1N
RiAueGVudHJhY2Uuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NP
VVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvbGlieGMgLUkv
bW50L3ZtL3hlbi8NCnhlbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29s
cy9pbmNsdWRlICAtYyAtbyB4ZW50cmFjZS5vIHhlbnRyYWNlLmMgDQpnY2MgICAgIC1vIHhl
bnRyYWNlIHhlbnRyYWNlLm8gL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hl
bnRyYWNlLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gDQpnY2MgIC1PMSAtZm5v
LW9taXQtZnJhbWUtcG9pbnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9
Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0
YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19f
IC1NDQpNRCAtTUYgLnNldHNpemUuby5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdF
RklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkv
bW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMv
bGlieGMgLUkvbW50L3ZtL3hlbi94DQplbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8u
Li8uLi90b29scy9pbmNsdWRlICAtYyAtbyBzZXRzaXplLm8gc2V0c2l6ZS5jIA0KZ2NjICAg
ICAtbyB4ZW50cmFjZV9zZXRzaXplIHNldHNpemUubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAN
CmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3Qt
YWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFy
YXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAt
RF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGVuY3R4Lm8uZCAgLURfTEFSR0VGSUxFX1NP
VVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxz
ICAtV2Vycm9yIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnRyYWNl
Ly4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veGUNCm4tdW5zdGFibGUuaGcvdG9v
bHMveGVudHJhY2UvLi4vLi4vdG9vbHMvaW5jbHVkZSAgLWMgLW8geGVuY3R4Lm8geGVuY3R4
LmMgDQpnY2MgICAgIC1vIHhlbmN0eCB4ZW5jdHgubyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAN
Ci9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29s
cy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUu
aGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NClsgLXogInhlbmN0eCIgXSB8fCAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvY3Jvc3MtaW5z
dGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5z
dGFsbC91c3IvbGliL3hlbi9iaW4NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy94ZW50cmFjZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1kIC1tMDc1NSAtcCAvbW50
L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9zaGFyZS9tYW4vbWFu
MQ0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnRyYWNlLy4uLy4uL3Rv
b2xzL2Nyb3NzLWluc3RhbGwgLWQgLW0wNzU1IC1wIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NoYXJlL21hbi9tYW44DQovbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAt
bTA3NTUgLXAgeGVudHJhY2UgeGVudHJhY2Vfc2V0c2l6ZSAvbW50L3ZtL3hlbi94ZW4tdW5z
dGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4NCi9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29scy9weXRob24vaW5zdGFsbC13cmFwICIv
dXNyL2Jpbi9weXRob24iIC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW50
cmFjZS8uLi8uLi90b29scy9jcm9zcy1pbnN0YWxsIC1tMDc1NSAtcCB4ZW50cmENCmNlX2Zv
cm1hdCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvZGlzdC9pbnN0YWxsL3Vzci9iaW4N
ClsgLXogInhlbmN0eCIgXSB8fCAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
eGVudHJhY2UvLi4vLi4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtbTA3NTUgLXAgeGVuY3R4IC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL2xpYi94ZW4vYmlu
DQovbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGVudHJhY2UvLi4vLi4vdG9v
bHMvY3Jvc3MtaW5zdGFsbCAtbTA2NDQgLXAgeGVudHJhY2VfZm9ybWF0LjEgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvbWFuL21hbjENCi9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94ZW50cmFjZS8uLi8uLi90b29scy9j
cm9zcy1pbnN0YWxsIC1tMDY0NCAtcCB4ZW50cmFjZS44IC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy9kaXN0L2luc3RhbGwvdXNyL3NoYXJlL21hbi9tYW44DQptYWtlWzNdOiBMZWF2
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hlbnRy
YWNlJw0KbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scycNCm1ha2VbMl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZSAtQyB4Y3V0aWxzIGluc3RhbGwNCm1h
a2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL3hjdXRpbHMnDQpnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTY0
IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJv
dG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlICAgLURfX1hFTl9UT09MU19fIC1NDQpNRCAtTUYgLnhjX3Jlc3RvcmUu
by5kICAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9w
dGltaXplLXNpYmxpbmctY2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuDQov
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xp
YnhjIC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4v
dG9vbHMvaW5jbHVkZSAtDQpjIC1vIHhjX3Jlc3RvcmUubyB4Y19yZXN0b3JlLmMgDQpnY2Mg
ICAgIHhjX3Jlc3RvcmUubyAtbyB4Y19yZXN0b3JlIC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xpYnhjL2xpYnhlbmN0cmwuc28gL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvbGli
eGMvbGlieGVuZ3VlDQpzdC5zbyANCmdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmlj
dC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2Vk
LWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU0NCk1EIC1NRiAueGNfc2F2
ZS5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8t
b3B0aW1pemUtc2libGluZy1jYWxscyAgLVdlcnJvciAtSS9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4v
eGUNCm4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9pbmNsdWRlIC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMv
bGlieGMgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8u
Li90b29scy9pbmNsdWRlIC1JL20NCm50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
eGN1dGlscy8uLi8uLi90b29scy94ZW5zdG9yZSAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLWMgLW8geGNfc2F2ZS5v
IHhjX3NhdmUuYyANCmdjYyAgICAgeGNfc2F2ZS5vIC1vIHhjX3NhdmUgL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvbGlieGMvbGlieGVu
Y3RybC5zbyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8u
Li90b29scy9saWJ4Yy9saWJ4ZW5ndWVzdC5zbyANCi9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL3hlbnN0b3JlL2xpYnhlbnN0b3JlLnNv
IA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5yZWFkbm90ZXMuby5kICAtRF9MQVJHRUZJ
TEVfU09VUkNFIC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmct
Y2FsbHMgIC1XZXJyb3IgLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1
dGlscy8uLi8uLi90b29scy9saWJ4YyAtSS9tbnQvdm0veGVuLw0KeGVuLXVuc3RhYmxlLmhn
L3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvaW5jbHVkZSAtSS9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94
ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4vLi4vdG9vbHMvaW5jbHVkZSAt
Yw0KIC1vIHJlYWRub3Rlcy5vIHJlYWRub3Rlcy5jIA0KZ2NjICAgICByZWFkbm90ZXMubyAt
byByZWFkbm90ZXMgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMv
Li4vLi4vdG9vbHMvbGlieGMvbGlieGVuY3RybC5zbyAvbW50L3ZtL3hlbi94ZW4tdW5zdGFi
bGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5ndWVzdA0KLnNv
IA0KZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW02NCAtZyAtZm5vLXN0cmlj
dC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAg
IC1EX19YRU5fVE9PTFNfXyAtTQ0KTUQgLU1GIC5sc2V2dGNobi5vLmQgIC1EX0xBUkdFRklM
RV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1pemUtc2libGluZy1j
YWxscyAgLVdlcnJvciAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy94Y3V0
aWxzLy4uLy4uL3Rvb2xzL2xpYnhjIC1JL21udC92bS94ZW4veA0KZW4tdW5zdGFibGUuaGcv
dG9vbHMveGN1dGlscy8uLi8uLi90b29scy9pbmNsdWRlIC1jIC1vIGxzZXZ0Y2huLm8gbHNl
dnRjaG4uYyANCmdjYyAgICAgbHNldnRjaG4ubyAtbyBsc2V2dGNobiAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMveGN1dGlscy8uLi8uLi90b29scy9saWJ4Yy9saWJ4ZW5j
dHJsLnNvIA0KL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL3hjdXRpbHMvLi4v
Li4vdG9vbHMvY3Jvc3MtaW5zdGFsbCAtZCAtbTA3NTUgLXAgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliL3hlbi9iaW4NCi9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy94Y3V0aWxzLy4uLy4uL3Rvb2xzL2Nyb3NzLWluc3RhbGwg
LW0wNzU1IC1wIHhjX3Jlc3RvcmUgeGNfc2F2ZSByZWFkbm90ZXMgbHNldnRjaG4gL21udC92
bS94ZW4veGVuLXVuc3RhYmxlLmhnL2Rpc3QvaW5zdGFsbC91c3IvbGliL3hlbi9iaW4NCm1h
a2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMveGN1dGlscycNCm1ha2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hl
bi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnDQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1ha2UgLUMgZmlybXdhcmUg
aW5zdGFsbA0KbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUnDQpHSVQ9Z2l0IC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS8uLi8uLi9zY3JpcHRzL2dpdC1jaGVja291dC5z
aCBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvc2VhYmlvcy5naXQgcmVsLTEuNi4zLjIgc2VhYmlv
cy1kaXINCkNsb25pbmcgaW50byAnc2VhYmlvcy1kaXItcmVtb3RlLnRtcCcuLi4NCnJlbW90
ZTogQ291bnRpbmcgb2JqZWN0czogNjQ5MCwgZG9uZS4NCnJlbW90ZTogQ29tcHJlc3Npbmcg
b2JqZWN0czogMTAwJSAoMTM5MS8xMzkxKSwgZG9uZS4NCnJlbW90ZTogVG90YWwgNjQ5MCAo
ZGVsdGEgNTE0NyksIHJldXNlZCA2NDIwIChkZWx0YSA1MDk1KSAgICAgDQpSZWNlaXZpbmcg
b2JqZWN0czogMTAwJSAoNjQ5MC82NDkwKSwgMS42MSBNaUIgfCA0MjAgS2lCL3MsIGRvbmUu
DQpSZXNvbHZpbmcgZGVsdGFzOiAxMDAlICg1MTQ3LzUxNDcpLCBkb25lLg0KU3dpdGNoZWQg
dG8gYSBuZXcgYnJhbmNoICdkdW1teScNCmNwIHNlYWJpb3MtY29uZmlnIHNlYWJpb3MtZGly
Ly5jb25maWc7DQptYWtlIFBZVEhPTj1weXRob24gc3ViZGlycy1hbGwNCm1ha2VbNF06IEVu
dGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zp
cm13YXJlJw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUnDQptYWtlIC1DIHNlYWJpb3MtZGlyIGFsbA0K
ICBXb3JraW5nIGFyb3VuZCBub24tZnVuY3Rpb25hbCAtY29tYmluZQ0KbWFrZVs2XTogRW50
ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmly
bXdhcmUvc2VhYmlvcy1kaXItcmVtb3RlJw0KICBXb3JraW5nIGFyb3VuZCBub24tZnVuY3Rp
b25hbCAtY29tYmluZQ0KICBCdWlsZCBLY29uZmlnIGNvbmZpZyBmaWxlDQogIENvbXBpbGlu
ZyB3aG9sZSBwcm9ncmFtIG91dC9jY29kZS4xNi5zDQogIENvbXBpbGluZyB0byBhc3NlbWJs
ZXIgb3V0L2FzbS1vZmZzZXRzLnMNCiAgR2VuZXJhdGluZyBvZmZzZXQgZmlsZSBvdXQvYXNt
LW9mZnNldHMuaA0KICBDb21waWxpbmcgKDE2Yml0KSBvdXQvY29kZTE2Lm8NCiAgQ29tcGls
aW5nIHdob2xlIHByb2dyYW0gb3V0L2Njb2RlMzJmbGF0Lm8NCiAgQ29tcGlsaW5nIHdob2xl
IHByb2dyYW0gb3V0L2NvZGUzMnNlZy5vDQogIEJ1aWxkaW5nIGxkIHNjcmlwdHMgKHZlcnNp
b24gIjEuNi4zLjItMjAxMjA2MjdfMTAyNDE4LXZmYXJtIikNCkZpeGVkIHNwYWNlOiAweGUw
NWItMHgxMDAwMCAgdG90YWw6IDgxMDEgIHNsYWNrOiA3ICBQZXJjZW50IHNsYWNrOiAwLjEl
DQoxNmJpdCBzaXplOiAgICAgICAgICAgMzgxNDQNCjMyYml0IHNlZ21lbnRlZCBzaXplOiAx
NDE4DQozMmJpdCBmbGF0IHNpemU6ICAgICAgMTM1MTANCjMyYml0IGZsYXQgaW5pdCBzaXpl
OiA1MzU2OA0KICBMaW5raW5nIG91dC9yb20xNi5vDQogIFN0cmlwcGluZyBvdXQvcm9tMTYu
c3RyaXAubw0KICBMaW5raW5nIG91dC9yb20zMnNlZy5vDQogIFN0cmlwcGluZyBvdXQvcm9t
MzJzZWcuc3RyaXAubw0KICBMaW5raW5nIG91dC9yb20ubw0KICBQcmVwcGluZyBvdXQvYmlv
cy5iaW4NClRvdGFsIHNpemU6IDEwOTEwMCAgRml4ZWQ6IDUzMDcyICBGcmVlOiAyMTk3MiAo
dXNlZCA4My4yJSBvZiAxMjhLaUIgcm9tKQ0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9zZWFiaW9zLWRp
ci1yZW1vdGUnDQptYWtlWzVdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVu
LXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZVs1XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUnDQptYWtl
IC1DIHJvbWJpb3MgYWxsDQptYWtlWzZdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0v
eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zJw0KbWFrZVs3XTog
RW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMv
ZmlybXdhcmUvcm9tYmlvcycNCm1ha2UgLUMgMzJiaXQgYWxsDQptYWtlWzhdOiBFbnRlcmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2Fy
ZS9yb21iaW9zLzMyYml0Jw0KbWFrZVs5XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3Zt
L3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvcm9tYmlvcy8zMmJpdCcNCm1h
a2UgLUMgdGNnYmlvcyBhbGwNCm1ha2VbMTBdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zLzMyYml0L3Rj
Z2Jpb3MnDQpnY2MgICAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW0zMiAtbWFyY2g9
aTY4NiAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0
LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YDQpFTl9UT09MU19fIC1NTUQgLU1GIC50Y2diaW9z
Lm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1v
cHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1tbm8tdGxzLWRpcmVjdC1zZWctcmVmcyAgLVdlcnJv
ciAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLWZuDQpvLWJ1aWx0aW4g
LW1zb2Z0LWZsb2F0IC1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13
YXJlL3JvbWJpb3MvMzJiaXQvdGNnYmlvcy8uLi8uLi8uLi8uLi8uLi90b29scy9pbmNsdWRl
IC1JLi4gLUkuLi8uLiAgLWMgLW8gdGNnYmlvcy5vIHRjZ2Jpb3MuYyANCmdjYyAgIC1PMSAt
Zm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTMyIC1tYXJjaD1pNjg2IC1nIC1mbm8tc3RyaWN0
LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV2RlY2xh
cmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQtc2V0LXZhcmlhYmxlICAg
LURfX1gNCkVOX1RPT0xTX18gLU1NRCAtTUYgLnRwbV9kcml2ZXJzLm8uZCAgLURfTEFSR0VG
SUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5n
LWNhbGxzIC1tbm8tdGxzLWRpcmVjdC1zZWctcmVmcyAgLVdlcnJvciAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMNCiAtZm5vLWJ1aWx0aW4gLW1zb2Z0LWZsb2F0IC1J
L21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlL3JvbWJpb3MvMzJi
aXQvdGNnYmlvcy8uLi8uLi8uLi8uLi8uLi90b29scy9pbmNsdWRlIC1JLi4gLUkuLi8uLiAg
LWMgLW8gdHBtX2RyaXZlcnMubyB0cG1fZHJpdmVycy5jIA0KbGQgLW1lbGZfaTM4NiAtciB0
Y2diaW9zLm8gdHBtX2RyaXZlcnMubyAtbyB0Y2diaW9zZXh0Lm8NCm1ha2VbMTBdOiBMZWF2
aW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13
YXJlL3JvbWJpb3MvMzJiaXQvdGNnYmlvcycNCm1ha2VbOV06IExlYXZpbmcgZGlyZWN0b3J5
IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvcm9tYmlvcy8z
MmJpdCcNCm1ha2UgMzJiaXRiaW9zX2ZsYXQuaA0KbWFrZVs5XTogRW50ZXJpbmcgZGlyZWN0
b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvcm9tYmlv
cy8zMmJpdCcNCmdjYyAgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtbTMyIC1tYXJj
aD1pNjg2IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJp
Y3QtcHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNl
ZC1idXQtc2V0LXZhcmlhYmxlICAgLURfX1gNCkVOX1RPT0xTX18gLU1NRCAtTUYgLjMyYml0
Ymlvcy5vLmQgIC1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1m
bm8tb3B0aW1pemUtc2libGluZy1jYWxscyAtbW5vLXRscy1kaXJlY3Qtc2VnLXJlZnMgIC1X
ZXJyb3IgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1leGNlcHRpb25zIC0NCmZuby1idWls
dGluIC1tc29mdC1mbG9hdCAtSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9m
aXJtd2FyZS9yb21iaW9zLzMyYml0Ly4uLy4uLy4uLy4uL3Rvb2xzL2luY2x1ZGUgLUkuLiAg
LWMgLW8gMzJiaXRiaW9zLm8gMzJiaXRiaW9zLmMgDQpnY2MgICAtTzEgLWZuby1vbWl0LWZy
YW1lLXBvaW50ZXIgLW0zMiAtbWFyY2g9aTY4NiAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAt
c3RkPWdudTk5IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLVduby11bnVzZWQtYnV0LXNldC12YXJpYWJsZSAgIC1EX19YDQpFTl9U
T09MU19fIC1NTUQgLU1GIC51dGlsLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJH
RUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1tbm8tdGxzLWRp
cmVjdC1zZWctcmVmcyAgLVdlcnJvciAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2Vw
dGlvbnMgLWZuby1iDQp1aWx0aW4gLW1zb2Z0LWZsb2F0IC1JL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlL3JvbWJpb3MvMzJiaXQvLi4vLi4vLi4vLi4vdG9v
bHMvaW5jbHVkZSAtSS4uICAtYyAtbyB1dGlsLm8gdXRpbC5jIA0KZ2NjICAgLU8xIC1mbm8t
b21pdC1mcmFtZS1wb2ludGVyIC1tMzIgLW1hcmNoPWk2ODYgLWcgLWZuby1zdHJpY3QtYWxp
YXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRp
b24tYWZ0ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9f
WA0KRU5fVE9PTFNfXyAtTU1EIC1NRiAucG1tLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAt
RF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZuby1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1tbm8t
dGxzLWRpcmVjdC1zZWctcmVmcyAgLVdlcnJvciAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LWV4Y2VwdGlvbnMgLWZuby1idQ0KaWx0aW4gLW1zb2Z0LWZsb2F0IC1JL21udC92bS94ZW4v
eGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlL3JvbWJpb3MvMzJiaXQvLi4vLi4vLi4v
Li4vdG9vbHMvaW5jbHVkZSAtSS4uICAtYyAtbyBwbW0ubyBwbW0uYyANCmxkIC1tZWxmX2kz
ODYgLXMgLXIgMzJiaXRiaW9zLm8gdGNnYmlvcy90Y2diaW9zZXh0Lm8gdXRpbC5vIHBtbS5v
IC1vIDMyYml0Ymlvc19hbGwubw0Kc2ggbWtoZXggaGlnaGJpb3NfYXJyYXkgMzJiaXRiaW9z
X2FsbC5vID4gMzJiaXRiaW9zX2ZsYXQuaA0KbWFrZVs5XTogTGVhdmluZyBkaXJlY3Rvcnkg
YC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zLzMy
Yml0Jw0KbWFrZVs4XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zLzMyYml0Jw0KbWFrZVs3XTogTGVhdmlu
ZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2Fy
ZS9yb21iaW9zJw0KbWFrZSBCSU9TLWJvY2hzLWxhdGVzdA0KbWFrZVs3XTogRW50ZXJpbmcg
ZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUv
cm9tYmlvcycNCmdjYyAtbyBiaW9zc3VtcyBiaW9zc3Vtcy5jDQpnY2MgLURCWF9TTVBfUFJP
Q0VTU09SUz0xIC1FIC1QIHJvbWJpb3MuYyA+IF9yb21iaW9zXy5jDQpiY2MgLW8gcm9tYmlv
cy5zIC1DLWMgLURfX2k4Nl9fIC0wIC1TIF9yb21iaW9zXy5jDQpzZWQgLWUgJ3MvXlwudGV4
dC8vJyAtZSAncy9eXC5kYXRhLy8nIHJvbWJpb3MucyA+IF9yb21iaW9zXy5zDQphczg2IF9y
b21iaW9zXy5zIC1iIHRtcC5iaW4gLXUtIC13LSAtZyAtMCAtaiAtTyAtbCByb21iaW9zLnR4
dA0KcGVybCBtYWtlc3ltLnBlcmwgPCByb21iaW9zLnR4dCA+IHJvbWJpb3Muc3ltDQptdiB0
bXAuYmluIEJJT1MtYm9jaHMtbGF0ZXN0DQouL2Jpb3NzdW1zIEJJT1MtYm9jaHMtbGF0ZXN0
DQoNCg0KUENJLUJpb3MgaGVhZGVyIGF0OiAweEI1QjANCkN1cnJlbnQgY2hlY2tzdW06ICAg
ICAweDU4DQpDYWxjdWxhdGVkIGNoZWNrc3VtOiAgMHg1OCAgDQoNCg0KJFBJUiBoZWFkZXIg
YXQ6ICAgICAweEI5MDANCkN1cnJlbnQgY2hlY2tzdW06ICAgICAweDM3DQpDYWxjdWxhdGVk
IGNoZWNrc3VtOiAgMHgyNw0KICBTZXR0aW5nIGNoZWNrc3VtLg0KDQoNCkJpb3MgY2hlY2tz
dW0gYXQ6ICAgMHhGRkZGDQpDdXJyZW50IGNoZWNrc3VtOiAgICAgMHgwMA0KQ2FsY3VsYXRl
ZCBjaGVja3N1bTogIDB4QUEgIFNldHRpbmcgY2hlY2tzdW0uDQpybSAtZiBfcm9tYmlvc18u
cw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9zJw0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3Rv
cnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9yb21iaW9z
Jw0KbWFrZVs1XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJs
ZS5oZy90b29scy9maXJtd2FyZScNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZSAtQyB2Z2Fi
aW9zIGFsbA0KbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4t
dW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvdmdhYmlvcycNCmdjYyAtbyBiaW9zc3VtcyBi
aW9zc3Vtcy5jDQpnY2MgLW8gdmJldGFibGVzLWdlbiB2YmV0YWJsZXMtZ2VuLmMNCi4vdmJl
dGFibGVzLWdlbiA+IHZiZXRhYmxlcy5oDQpnY2MgLUUgLVAgdmdhYmlvcy5jICAtRFZCRSAi
LURWR0FCSU9TX0RBVEU9XCJgZGF0ZSAnKyVkICViICVZJ2BcIiIgPiBfdmdhYmlvc18uYw0K
YmNjIC1vIHZnYWJpb3MucyAtQy1jIC1EX19pODZfXyAtUyAtMCBfdmdhYmlvc18uYw0Kc2Vk
IC1lICdzL15cLnRleHQvLycgLWUgJ3MvXlwuZGF0YS8vJyB2Z2FiaW9zLnMgPiBfdmdhYmlv
c18ucw0KYXM4NiBfdmdhYmlvc18ucyAtYiB2Z2FiaW9zLmJpbiAtdSAtdy0gLWcgLTAgLWog
LU8gLWwgdmdhYmlvcy50eHQNCnJtIC1mIF92Z2FiaW9zXy5zIF92Z2FiaW9zXy5jIHZnYWJp
b3Mucw0KY3AgdmdhYmlvcy5iaW4gVkdBQklPUy1sZ3BsLWxhdGVzdC5iaW4NCi4vYmlvc3N1
bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5iaW4NCg0KQmlvcyBjaGVja3N1bSBhdDogICAweDlE
RkYNCkN1cnJlbnQgY2hlY2tzdW06ICAgICAweDAwDQpDYWxjdWxhdGVkIGNoZWNrc3VtOiAg
MHg5NSAgU2V0dGluZyBjaGVja3N1bS4NCmxzIC1sIFZHQUJJT1MtbGdwbC1sYXRlc3QuYmlu
DQotcnctci0tci0tIDEgcm9vdCByb290IDQwNDQ4IGdpdSAyNyAxMDoyNCBWR0FCSU9TLWxn
cGwtbGF0ZXN0LmJpbg0KZ2NjIC1FIC1QIHZnYWJpb3MuYyAgLURWQkUgLURERUJVRyAiLURW
R0FCSU9TX0RBVEU9XCJgZGF0ZSAnKyVkICViICVZJ2BcIiIgPiBfdmdhYmlvcy1kZWJ1Z18u
Yw0KYmNjIC1vIHZnYWJpb3MtZGVidWcucyAtQy1jIC1EX19pODZfXyAtUyAtMCBfdmdhYmlv
cy1kZWJ1Z18uYw0Kc2VkIC1lICdzL15cLnRleHQvLycgLWUgJ3MvXlwuZGF0YS8vJyB2Z2Fi
aW9zLWRlYnVnLnMgPiBfdmdhYmlvcy1kZWJ1Z18ucw0KYXM4NiBfdmdhYmlvcy1kZWJ1Z18u
cyAtYiB2Z2FiaW9zLmRlYnVnLmJpbiAtdSAtdy0gLWcgLTAgLWogLU8gLWwgdmdhYmlvcy5k
ZWJ1Zy50eHQNCnJtIC1mIF92Z2FiaW9zLWRlYnVnXy5zIF92Z2FiaW9zLWRlYnVnXy5jIHZn
YWJpb3MtZGVidWcucw0KY3AgdmdhYmlvcy5kZWJ1Zy5iaW4gVkdBQklPUy1sZ3BsLWxhdGVz
dC5kZWJ1Zy5iaW4NCi4vYmlvc3N1bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5kZWJ1Zy5iaW4N
Cg0KQmlvcyBjaGVja3N1bSBhdDogICAweEExRkYNCkN1cnJlbnQgY2hlY2tzdW06ICAgICAw
eDAwDQpDYWxjdWxhdGVkIGNoZWNrc3VtOiAgMHhBRSAgU2V0dGluZyBjaGVja3N1bS4NCmxz
IC1sIFZHQUJJT1MtbGdwbC1sYXRlc3QuZGVidWcuYmluDQotcnctci0tci0tIDEgcm9vdCBy
b290IDQxNDcyIGdpdSAyNyAxMDoyNCBWR0FCSU9TLWxncGwtbGF0ZXN0LmRlYnVnLmJpbg0K
Z2NjIC1FIC1QIHZnYWJpb3MuYyAgLURDSVJSVVMgLURQQ0lCSU9TICItRFZHQUJJT1NfREFU
RT1cImBkYXRlICcrJWQgJWIgJVknYFwiIiA+IF92Z2FiaW9zLWNpcnJ1c18uYw0KYmNjIC1v
IHZnYWJpb3MtY2lycnVzLnMgLUMtYyAtRF9faTg2X18gLVMgLTAgX3ZnYWJpb3MtY2lycnVz
Xy5jDQpzZWQgLWUgJ3MvXlwudGV4dC8vJyAtZSAncy9eXC5kYXRhLy8nIHZnYWJpb3MtY2ly
cnVzLnMgPiBfdmdhYmlvcy1jaXJydXNfLnMNCmFzODYgX3ZnYWJpb3MtY2lycnVzXy5zIC1i
IHZnYWJpb3MtY2lycnVzLmJpbiAtdSAtdy0gLWcgLTAgLWogLU8gLWwgdmdhYmlvcy1jaXJy
dXMudHh0DQpybSAtZiBfdmdhYmlvcy1jaXJydXNfLnMgX3ZnYWJpb3MtY2lycnVzXy5jIHZn
YWJpb3MtY2lycnVzLnMNCmNwIHZnYWJpb3MtY2lycnVzLmJpbiBWR0FCSU9TLWxncGwtbGF0
ZXN0LmNpcnJ1cy5iaW4NCi4vYmlvc3N1bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5jaXJydXMu
YmluDQoNCkJpb3MgY2hlY2tzdW0gYXQ6ICAgMHg4QkZGDQpDdXJyZW50IGNoZWNrc3VtOiAg
ICAgMHgwMA0KQ2FsY3VsYXRlZCBjaGVja3N1bTogIDB4QUEgIFNldHRpbmcgY2hlY2tzdW0u
DQpscyAtbCBWR0FCSU9TLWxncGwtbGF0ZXN0LmNpcnJ1cy5iaW4NCi1ydy1yLS1yLS0gMSBy
b290IHJvb3QgMzU4NDAgZ2l1IDI3IDEwOjI0IFZHQUJJT1MtbGdwbC1sYXRlc3QuY2lycnVz
LmJpbg0KZ2NjIC1FIC1QIHZnYWJpb3MuYyAgLURDSVJSVVMgLURDSVJSVVNfREVCVUcgLURQ
Q0lCSU9TICItRFZHQUJJT1NfREFURT1cImBkYXRlICcrJWQgJWIgJVknYFwiIiA+IF92Z2Fi
aW9zLWNpcnJ1cy1kZWJ1Z18uYw0KYmNjIC1vIHZnYWJpb3MtY2lycnVzLWRlYnVnLnMgLUMt
YyAtRF9faTg2X18gLVMgLTAgX3ZnYWJpb3MtY2lycnVzLWRlYnVnXy5jDQpzZWQgLWUgJ3Mv
XlwudGV4dC8vJyAtZSAncy9eXC5kYXRhLy8nIHZnYWJpb3MtY2lycnVzLWRlYnVnLnMgPiBf
dmdhYmlvcy1jaXJydXMtZGVidWdfLnMNCmFzODYgX3ZnYWJpb3MtY2lycnVzLWRlYnVnXy5z
IC1iIHZnYWJpb3MtY2lycnVzLmRlYnVnLmJpbiAtdSAtdy0gLWcgLTAgLWogLU8gLWwgdmdh
Ymlvcy1jaXJydXMuZGVidWcudHh0DQpybSAtZiBfdmdhYmlvcy1jaXJydXMtZGVidWdfLnMg
X3ZnYWJpb3MtY2lycnVzLWRlYnVnXy5jIHZnYWJpb3MtY2lycnVzLWRlYnVnLnMNCmNwIHZn
YWJpb3MtY2lycnVzLmRlYnVnLmJpbiBWR0FCSU9TLWxncGwtbGF0ZXN0LmNpcnJ1cy5kZWJ1
Zy5iaW4NCi4vYmlvc3N1bXMgVkdBQklPUy1sZ3BsLWxhdGVzdC5jaXJydXMuZGVidWcuYmlu
DQoNCkJpb3MgY2hlY2tzdW0gYXQ6ICAgMHg4QkZGDQpDdXJyZW50IGNoZWNrc3VtOiAgICAg
MHgwMA0KQ2FsY3VsYXRlZCBjaGVja3N1bTogIDB4QzkgIFNldHRpbmcgY2hlY2tzdW0uDQps
cyAtbCBWR0FCSU9TLWxncGwtbGF0ZXN0LmNpcnJ1cy5kZWJ1Zy5iaW4NCi1ydy1yLS1yLS0g
MSByb290IHJvb3QgMzU4NDAgZ2l1IDI3IDEwOjI0IFZHQUJJT1MtbGdwbC1sYXRlc3QuY2ly
cnVzLmRlYnVnLmJpbg0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS92Z2FiaW9zJw0KbWFrZVs1XTogTGVh
dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJt
d2FyZScNCm1ha2VbNV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVu
c3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZSAtQyBldGhlcmJvb3QgYWxsDQptYWtl
WzZdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scy9maXJtd2FyZS9ldGhlcmJvb3QnDQppZiAhIHdnZXQgLU8gX2lweGUudGFyLmd6IGh0
dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzL2lweGUtZ2l0LTlhOTNk
YjNmMDk0NzQ4NGUzMGU3NTNiYmQ2MWExMGIxNzMzNmUyMGUudGFyLmd6OyB0aGVuIFwNCiAg
ICAgICAgZ2l0IGNsb25lIGdpdDovL2dpdC5pcHhlLm9yZy9pcHhlLmdpdCBpcHhlLmdpdDsg
XA0KICAgICAgICAoY2QgaXB4ZS5naXQgJiYgZ2l0IGFyY2hpdmUgLS1mb3JtYXQ9dGFyIC0t
cHJlZml4PWlweGUvIFwNCiAgICAgICAgOWE5M2RiM2YwOTQ3NDg0ZTMwZTc1M2JiZDYxYTEw
YjE3MzM2ZTIwZSB8IGd6aXAgPi4uL19pcHhlLnRhci5neik7IFwNCiAgICAgICAgcm0gLXJm
IGlweGUuZ2l0OyBcDQogZmkNCi0tMjAxMi0wNi0yNyAxMDoyNDoyMi0tICBodHRwOi8veGVu
Yml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcy9pcHhlLWdpdC05YTkzZGIzZjA5NDc0
ODRlMzBlNzUzYmJkNjFhMTBiMTczMzZlMjBlLnRhci5neg0KUmlzb2x1emlvbmUgZGkgeGVu
Yml0cy54ZW5zb3VyY2UuY29tICh4ZW5iaXRzLnhlbnNvdXJjZS5jb20pLi4uIDUwLjU3LjE3
MC4yNDINCkNvbm5lc3Npb25lIGEgeGVuYml0cy54ZW5zb3VyY2UuY29tICh4ZW5iaXRzLnhl
bnNvdXJjZS5jb20pfDUwLjU3LjE3MC4yNDJ8OjgwLi4uIGNvbm5lc3NvLg0KUmljaGllc3Rh
IEhUVFAgaW52aWF0YSwgaW4gYXR0ZXNhIGRpIHJpc3Bvc3RhLi4uIDIwMCBPSw0KTHVuZ2hl
enphOiAyODY3OTk5ICgyLDdNKSBbYXBwbGljYXRpb24veC1nemlwXQ0KU2FsdmF0YWdnaW8g
aW46ICJfaXB4ZS50YXIuZ3oiDQoNCjEwMCVbPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT5dIDIuODY3Ljk5OSAgIDYsNDhNL3MgICBpbiAwLDRzICAgIA0KDQoyMDEyLTA2LTI3IDEw
OjI0OjIyICg2LDQ4IE1CL3MpIC0gIl9pcHhlLnRhci5neiIgc2FsdmF0byBbMjg2Nzk5OS8y
ODY3OTk5XQ0KDQptdiBfaXB4ZS50YXIuZ3ogaXB4ZS50YXIuZ3oNCnJtIC1yZiBpcHhlDQpn
emlwIC1kYyBpcHhlLnRhci5neiB8IHRhciB4ZiAtDQpmb3IgaSBpbiAkKGNhdCBwYXRjaGVz
L3NlcmllcykgOyBkbyAgICAgICAgICAgICAgICAgXA0KICAgICBwYXRjaCAtZCBpcHhlIC1w
MSAtLXF1aWV0IDxwYXRjaGVzLyRpIHx8IGV4aXQgMSA7IFwNCiBkb25lDQpjYXQgQ29uZmln
ID4+aXB4ZS9zcmMvYXJjaC9pMzg2L01ha2VmaWxlDQptYWtlIC1DIGlweGUvc3JjIGJpbi9y
dGw4MTM5LnJvbQ0KbWFrZVs3XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94
ZW4tdW5zdGFibGUuaGcvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L2lweGUvc3JjJw0Kcm0g
LWYgIGJpbi8qLiogIGJpbi9lcnJvcnMgICAgICAgYmluL05JQyAgICAgICAgIC4vdXRpbC9u
cnYyYiAuL3V0aWwvemJpbiAuL3V0aWwvZWxmMmVmaTMyIC4vdXRpbC9lbGYyZWZpNjQgLi91
dGlsL2VmaXJvbSAuL3V0aWwvaWNjZml4IC4vdXRpbC9laW5mbyBUQUdTIGJpbi9zeW10YWIN
CiAgW01FRElBUlVMRVNdIGV4ZQ0KICBbTUVESUFSVUxFU10gcmF3DQogIFtNRURJQVJVTEVT
XSBoZA0KICBbTUVESUFSVUxFU10gbmJpDQogIFtNRURJQVJVTEVTXSBkc2sNCiAgW01FRElB
UlVMRVNdIGxrcm4NCiAgW01FRElBUlVMRVNdIGtra3B4ZQ0KICBbTUVESUFSVUxFU10ga2tw
eGUNCiAgW01FRElBUlVMRVNdIGtweGUNCiAgW01FRElBUlVMRVNdIHB4ZQ0KICBbTUVESUFS
VUxFU10gbXJvbQ0KICBbTUVESUFSVUxFU10gcm9tDQogIFtSVUxFU10gYXJjaC9pMzg2L2Ry
aXZlcnMvbmV0L3VuZGlpc3IuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uvc3lz
bGludXgvY29tMzJfd3JhcHBlci5TDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9w
eGUvcHhlX2VudHJ5LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2U4
MjBtYW5nbGVyLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L3VzYmRpc2suUw0KICBb
UlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvdW5ucnYyYi5TDQogIFtSVUxFU10gYXJjaC9pMzg2
L3ByZWZpeC91bm5ydjJiMTYuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvdW5kaWxv
YWRlci5TDQogIFtSVUxFU10gYXJjaC9pMzg2L3ByZWZpeC9yb21wcmVmaXguUw0KICBbUlVM
RVNdIGFyY2gvaTM4Ni9wcmVmaXgvcHhlcHJlZml4LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYv
cHJlZml4L251bGxwcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvbmJpcHJl
Zml4LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L21yb21wcmVmaXguUw0KICBbUlVM
RVNdIGFyY2gvaTM4Ni9wcmVmaXgvbWJyLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4
L2xrcm5wcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVmaXgvbGlicHJlZml4LlMN
CiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L2tweGVwcmVmaXguUw0KICBbUlVMRVNdIGFy
Y2gvaTM4Ni9wcmVmaXgva2tweGVwcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVm
aXgva2trcHhlcHJlZml4LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L2hkcHJlZml4
LlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvcHJlZml4L2V4ZXByZWZpeC5TDQogIFtSVUxFU10g
YXJjaC9pMzg2L3ByZWZpeC9kc2twcmVmaXguUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9wcmVm
aXgvYm9vdHBhcnQuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni90cmFuc2l0aW9ucy9saWJybS5T
DQogIFtSVUxFU10gYXJjaC9pMzg2L3RyYW5zaXRpb25zL2xpYnBtLlMNCiAgW1JVTEVTXSBh
cmNoL2kzODYvdHJhbnNpdGlvbnMvbGlia2lyLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvdHJh
bnNpdGlvbnMvbGliYTIwLlMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS92aXJ0YWRkci5T
DQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvc3RhY2suUw0KICBbUlVMRVNdIGFyY2gvaTM4
Ni9jb3JlL3N0YWNrMTYuUw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9jb3JlL3NldGptcC5TDQog
IFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvcGF0Y2hfY2YuUw0KICBbUlVMRVNdIGFyY2gvaTM4
Ni9jb3JlL2dkYmlkdC5TDQogIFtSVUxFU10gdGVzdHMvZ2Ric3R1Yl90ZXN0LlMNCiAgW1JV
TEVTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaXJvbS5jDQogIFtSVUxFU10gYXJjaC9p
Mzg2L2RyaXZlcnMvbmV0L3VuZGlwcmVsb2FkLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZHJp
dmVycy9uZXQvdW5kaW9ubHkuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9kcml2ZXJzL25ldC91
bmRpbmV0LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaWxvYWQuYw0K
ICBbUlVMRVNdIGFyY2gvaTM4Ni9kcml2ZXJzL25ldC91bmRpLmMNCiAgW1JVTEVTXSBhcmNo
L3g4Ni9wcmVmaXgvZWZpcHJlZml4LmMNCiAgW1JVTEVTXSBhcmNoL3g4Ni9wcmVmaXgvZWZp
ZHJ2cHJlZml4LmMNCiAgW1JVTEVTXSBhcmNoL3g4Ni9pbnRlcmZhY2UvZWZpL2VmaXg4Nl9u
YXAuYw0KICBbUlVMRVNdIGFyY2gveDg2L2NvcmUveDg2X3N0cmluZy5jDQogIFtSVUxFU10g
YXJjaC94ODYvY29yZS9wY2lkaXJlY3QuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9oY2kvY29t
bWFuZHMvcmVib290X2NtZC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2hjaS9jb21tYW5kcy9w
eGVfY21kLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2NvbWJv
b3RfcmVzb2x2LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2Nv
bWJvb3RfY2FsbC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9zeXNsaW51eC9j
b20zMl9jYWxsLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZXBhcmVudC9w
eGVwYXJlbnRfZGhjcC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGVwYXJl
bnQvcHhlcGFyZW50LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZS9weGVf
dW5kaS5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3VkcC5jDQog
IFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3RmdHAuYw0KICBbUlVMRVNd
IGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9wcmVib290LmMNCiAgW1JVTEVTXSBhcmNo
L2kzODYvaW50ZXJmYWNlL3B4ZS9weGVfbG9hZGVyLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYv
aW50ZXJmYWNlL3B4ZS9weGVfZmlsZS5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFj
ZS9weGUvcHhlX2V4aXRfaG9vay5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9w
eGUvcHhlX2NhbGwuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL3Bj
aWJpb3MuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL21lbXRvcF91
bWFsbG9jLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3BjYmlvcy9pbnQxMy5j
DQogIFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvYmlvc190aW1lci5jDQog
IFtSVUxFU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvYmlvc19zbWJpb3MuYw0KICBb
UlVMRVNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL2Jpb3NfbmFwLmMNCiAgW1JVTEVT
XSBhcmNoL2kzODYvaW50ZXJmYWNlL3BjYmlvcy9iaW9zaW50LmMNCiAgW1JVTEVTXSBhcmNo
L2kzODYvaW1hZ2UvcHhlX2ltYWdlLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW1hZ2UvbmJp
LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvaW1hZ2UvbXVsdGlib290LmMNCiAgW1JVTEVTXSBh
cmNoL2kzODYvaW1hZ2UvZWxmYm9vdC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2ltYWdlL2Nv
bWJvb3QuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbWFnZS9jb20zMi5jDQogIFtSVUxFU10g
YXJjaC9pMzg2L2ltYWdlL2J6aW1hZ2UuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9pbWFnZS9i
b290c2VjdG9yLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL3BucGJp
b3MuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvbWVtbWFwLmMNCiAg
W1JVTEVTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2hpZGVtZW0uYw0KICBbUlVMRVNd
IGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvZmFrZWU4MjAuYw0KICBbUlVMRVNdIGFyY2gv
aTM4Ni9maXJtd2FyZS9wY2Jpb3MvYmlvc19jb25zb2xlLmMNCiAgW1JVTEVTXSBhcmNoL2kz
ODYvZmlybXdhcmUvcGNiaW9zL2Jhc2VtZW0uYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni90cmFu
c2l0aW9ucy9saWJybV9tZ210LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS94ODZfaW8u
Yw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9jb3JlL3ZpZGVvX3N1YnIuYw0KICBbUlVMRVNdIGFy
Y2gvaTM4Ni9jb3JlL3RpbWVyMi5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvcnVudGlt
ZS5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUvcmVsb2NhdGUuYw0KICBbUlVMRVNdIGFy
Y2gvaTM4Ni9jb3JlL3JkdHNjX3RpbWVyLmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS9w
aWM4MjU5LmMNCiAgW1JVTEVTXSBhcmNoL2kzODYvY29yZS9udWxsdHJhcC5jDQogIFtSVUxF
U10gYXJjaC9pMzg2L2NvcmUvZ2RibWFjaC5jDQogIFtSVUxFU10gYXJjaC9pMzg2L2NvcmUv
ZHVtcHJlZ3MuYw0KICBbUlVMRVNdIGFyY2gvaTM4Ni9jb3JlL2NwdS5jDQogIFtSVUxFU10g
YXJjaC9pMzg2L2NvcmUvYmFzZW1lbV9wYWNrZXQuYw0KICBbUlVMRVNdIGNvbmZpZy9jb25m
aWdfcm9tcHJlZml4LmMNCiAgW1JVTEVTXSBjb25maWcvY29uZmlnX25ldDgwMjExLmMNCiAg
W1JVTEVTXSBjb25maWcvY29uZmlnX2luZmluaWJhbmQuYw0KICBbUlVMRVNdIGNvbmZpZy9j
b25maWdfZmMuYw0KICBbUlVMRVNdIGNvbmZpZy9jb25maWdfZXRoZXJuZXQuYw0KICBbUlVM
RVNdIGNvbmZpZy9jb25maWcuYw0KICBbUlVMRVNdIHVzci9yb3V0ZS5jDQogIFtSVUxFU10g
dXNyL3B4ZW1lbnUuYw0KICBbUlVMRVNdIHVzci9wcm9tcHQuYw0KICBbUlVMRVNdIHVzci9s
b3Rlc3QuYw0KICBbUlVMRVNdIHVzci9pd21nbXQuYw0KICBbUlVMRVNdIHVzci9pbWdtZ210
LmMNCiAgW1JVTEVTXSB1c3IvaWZtZ210LmMNCiAgW1JVTEVTXSB1c3IvZmNtZ210LmMNCiAg
W1JVTEVTXSB1c3IvZGhjcG1nbXQuYw0KICBbUlVMRVNdIHVzci9hdXRvYm9vdC5jDQogIFtS
VUxFU10gaGNpL2tleW1hcC9rZXltYXBfd28uYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5
bWFwX3VzLmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF91ay5jDQogIFtSVUxFU10g
aGNpL2tleW1hcC9rZXltYXBfdWEuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX3Ro
LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9zci5jDQogIFtSVUxFU10gaGNpL2tl
eW1hcC9rZXltYXBfc2cuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX3J1LmMNCiAg
W1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9yby5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9r
ZXltYXBfcHQuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX3BsLmMNCiAgW1JVTEVT
XSBoY2kva2V5bWFwL2tleW1hcF9uby5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBf
bmwuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX210LmMNCiAgW1JVTEVTXSBoY2kv
a2V5bWFwL2tleW1hcF9tay5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfbHQuYw0K
ICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX2l0LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFw
L2tleW1hcF9pbC5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfaHUuYw0KICBbUlVM
RVNdIGhjaS9rZXltYXAva2V5bWFwX2dyLmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1h
cF9mci5jDQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfZmkuYw0KICBbUlVMRVNdIGhj
aS9rZXltYXAva2V5bWFwX2V0LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9lcy5j
DQogIFtSVUxFU10gaGNpL2tleW1hcC9rZXltYXBfZGsuYw0KICBbUlVMRVNdIGhjaS9rZXlt
YXAva2V5bWFwX2RlLmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9jei5jDQogIFtS
VUxFU10gaGNpL2tleW1hcC9rZXltYXBfY2YuYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5
bWFwX2J5LmMNCiAgW1JVTEVTXSBoY2kva2V5bWFwL2tleW1hcF9iZy5jDQogIFtSVUxFU10g
aGNpL2tleW1hcC9rZXltYXBfYXouYw0KICBbUlVMRVNdIGhjaS9rZXltYXAva2V5bWFwX2Fs
LmMNCiAgW1JVTEVTXSBoY2kvbXVjdXJzZXMvd2lkZ2V0cy9lZGl0Ym94LmMNCiAgW1JVTEVT
XSBoY2kvbXVjdXJzZXMvd2luaW5pdC5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2VzL3dpbmRv
d3MuYw0KICBbUlVMRVNdIGhjaS9tdWN1cnNlcy93aW5hdHRycy5jDQogIFtSVUxFU10gaGNp
L211Y3Vyc2VzL3Nsay5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2VzL3ByaW50X25hZHYuYw0K
ICBbUlVMRVNdIGhjaS9tdWN1cnNlcy9wcmludC5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2Vz
L211Y3Vyc2VzLmMNCiAgW1JVTEVTXSBoY2kvbXVjdXJzZXMva2IuYw0KICBbUlVMRVNdIGhj
aS9tdWN1cnNlcy9lZGdpbmcuYw0KICBbUlVMRVNdIGhjaS9tdWN1cnNlcy9jb2xvdXIuYw0K
ICBbUlVMRVNdIGhjaS9tdWN1cnNlcy9jbGVhci5jDQogIFtSVUxFU10gaGNpL211Y3Vyc2Vz
L2Fuc2lfc2NyZWVuLmMNCiAgW1JVTEVTXSBoY2kvbXVjdXJzZXMvYWxlcnQuYw0KICBbUlVM
RVNdIGhjaS90dWkvc2V0dGluZ3NfdWkuYw0KICBbUlVMRVNdIGhjaS90dWkvbG9naW5fdWku
Yw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy92bGFuX2NtZC5jDQogIFtSVUxFU10gaGNpL2Nv
bW1hbmRzL3RpbWVfY21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvc2FuYm9vdF9jbWQu
Yw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9yb3V0ZV9jbWQuYw0KICBbUlVMRVNdIGhjaS9j
b21tYW5kcy9udm9fY21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvbG90ZXN0X2NtZC5j
DQogIFtSVUxFU10gaGNpL2NvbW1hbmRzL2xvZ2luX2NtZC5jDQogIFtSVUxFU10gaGNpL2Nv
bW1hbmRzL2l3bWdtdF9jbWQuYw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9pbWFnZV9jbWQu
Yw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9pZm1nbXRfY21kLmMNCiAgW1JVTEVTXSBoY2kv
Y29tbWFuZHMvZ2Ric3R1Yl9jbWQuYw0KICBbUlVMRVNdIGhjaS9jb21tYW5kcy9mY21nbXRf
Y21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvZGlnZXN0X2NtZC5jDQogIFtSVUxFU10g
aGNpL2NvbW1hbmRzL2RoY3BfY21kLmMNCiAgW1JVTEVTXSBoY2kvY29tbWFuZHMvY29uZmln
X2NtZC5jDQogIFtSVUxFU10gaGNpL2NvbW1hbmRzL2F1dG9ib290X2NtZC5jDQogIFtSVUxF
U10gaGNpL3dpcmVsZXNzX2Vycm9ycy5jDQogIFtSVUxFU10gaGNpL3N0cmVycm9yLmMNCiAg
W1JVTEVTXSBoY2kvc2hlbGwuYw0KICBbUlVMRVNdIGhjaS9yZWFkbGluZS5jDQogIFtSVUxF
U10gaGNpL2xpbnV4X2FyZ3MuYw0KICBbUlVMRVNdIGhjaS9lZGl0c3RyaW5nLmMNCiAgW1JV
TEVTXSBjcnlwdG8vYXh0bHMvc2hhMS5jDQogIFtSVUxFU10gY3J5cHRvL2F4dGxzL3JzYS5j
DQogIFtSVUxFU10gY3J5cHRvL2F4dGxzL2JpZ2ludC5jDQogIFtSVUxFU10gY3J5cHRvL2F4
dGxzL2Flcy5jDQogIFtSVUxFU10gY3J5cHRvL3g1MDkuYw0KICBbUlVMRVNdIGNyeXB0by9z
aGExZXh0cmEuYw0KICBbUlVMRVNdIGNyeXB0by9tZDUuYw0KICBbUlVMRVNdIGNyeXB0by9o
bWFjLmMNCiAgW1JVTEVTXSBjcnlwdG8vY3J5cHRvX251bGwuYw0KICBbUlVMRVNdIGNyeXB0
by9jcmMzMi5jDQogIFtSVUxFU10gY3J5cHRvL2NyYW5kb20uYw0KICBbUlVMRVNdIGNyeXB0
by9jaGFwLmMNCiAgW1JVTEVTXSBjcnlwdG8vY2JjLmMNCiAgW1JVTEVTXSBjcnlwdG8vYXh0
bHNfc2hhMS5jDQogIFtSVUxFU10gY3J5cHRvL2F4dGxzX2Flcy5jDQogIFtSVUxFU10gY3J5
cHRvL2FzbjEuYw0KICBbUlVMRVNdIGNyeXB0by9hcmM0LmMNCiAgW1JVTEVTXSBjcnlwdG8v
YWVzX3dyYXAuYw0KICBbUlVMRVNdIHRlc3RzL3VyaV90ZXN0LmMNCiAgW1JVTEVTXSB0ZXN0
cy91bWFsbG9jX3Rlc3QuYw0KICBbUlVMRVNdIHRlc3RzL3Rlc3QuYw0KICBbUlVMRVNdIHRl
c3RzL21lbWNweV90ZXN0LmMNCiAgW1JVTEVTXSB0ZXN0cy9saXN0X3Rlc3QuYw0KICBbUlVM
RVNdIHRlc3RzL2xpbmVidWZfdGVzdC5jDQogIFtSVUxFU10gdGVzdHMvYm9mbV90ZXN0LmMN
CiAgW1JVTEVTXSBpbnRlcmZhY2UvYm9mbS9ib2ZtLmMNCiAgW1JVTEVTXSBpbnRlcmZhY2Uv
c21iaW9zL3NtYmlvc19zZXR0aW5ncy5jDQogIFtSVUxFU10gaW50ZXJmYWNlL3NtYmlvcy9z
bWJpb3MuYw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX3VtYWxsb2MuYw0KICBbUlVM
RVNdIGludGVyZmFjZS9lZmkvZWZpX3VhY2Nlc3MuYw0KICBbUlVMRVNdIGludGVyZmFjZS9l
ZmkvZWZpX3RpbWVyLmMNCiAgW1JVTEVTXSBpbnRlcmZhY2UvZWZpL2VmaV9zdHJpbmdzLmMN
CiAgW1JVTEVTXSBpbnRlcmZhY2UvZWZpL2VmaV9zdHJlcnJvci5jDQogIFtSVUxFU10gaW50
ZXJmYWNlL2VmaS9lZmlfc25wLmMNCiAgW1JVTEVTXSBpbnRlcmZhY2UvZWZpL2VmaV9zbWJp
b3MuYw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX3BjaS5jDQogIFtSVUxFU10gaW50
ZXJmYWNlL2VmaS9lZmlfaW8uYw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX2luaXQu
Yw0KICBbUlVMRVNdIGludGVyZmFjZS9lZmkvZWZpX2RyaXZlci5jDQogIFtSVUxFU10gaW50
ZXJmYWNlL2VmaS9lZmlfY29uc29sZS5jDQogIFtSVUxFU10gaW50ZXJmYWNlL2VmaS9lZmlf
Ym9mbS5jDQogIFtSVUxFU10gZHJpdmVycy9pbmZpbmliYW5kL3FpYjczMjIuYw0KICBbUlVM
RVNdIGRyaXZlcnMvaW5maW5pYmFuZC9saW5kYV9mdy5jDQogIFtSVUxFU10gZHJpdmVycy9p
bmZpbmliYW5kL2xpbmRhLmMNCiAgW1JVTEVTXSBkcml2ZXJzL2luZmluaWJhbmQvaGVybW9u
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL2luZmluaWJhbmQvYXJiZWwuYw0KICBbUlVMRVNdIGRy
aXZlcnMvYml0YmFzaC9zcGlfYml0LmMNCiAgW1JVTEVTXSBkcml2ZXJzL2JpdGJhc2gvaTJj
X2JpdC5jDQogIFtSVUxFU10gZHJpdmVycy9iaXRiYXNoL2JpdGJhc2guYw0KICBbUlVMRVNd
IGRyaXZlcnMvbnZzL3RocmVld2lyZS5jDQogIFtSVUxFU10gZHJpdmVycy9udnMvc3BpLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL252cy9udnN2cGQuYw0KICBbUlVMRVNdIGRyaXZlcnMvbnZz
L252cy5jDQogIFtSVUxFU10gZHJpdmVycy9ibG9jay9zcnAuYw0KICBbUlVMRVNdIGRyaXZl
cnMvYmxvY2svc2NzaS5jDQogIFtSVUxFU10gZHJpdmVycy9ibG9jay9pYmZ0LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL2Jsb2NrL2F0YS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZWZpL3Nu
cG9ubHkuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2VmaS9zbnBuZXQuYw0KICBbUlVMRVNd
IGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV90cmFmZmljLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25l
dC92eGdlL3Z4Z2VfbWFpbi5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvdnhnZS92eGdlX2Nv
bmZpZy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvdnhnZS92eGdlLmMNCiAgW1JVTEVTXSBk
cml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfeG1pdC5jDQogIFtSVUxFU10gZHJpdmVycy9u
ZXQvYXRoL2F0aDlrL2F0aDlrX3JlY3YuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9h
dGg5ay9hdGg5a19tYWluLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRo
OWtfbWFjLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfaW5pdC5j
DQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2h3LmMNCiAgW1JVTEVT
XSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfZWVwcm9tX2RlZi5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbV85Mjg3LmMNCiAgW1JVTEVTXSBkcml2ZXJz
L25ldC9hdGgvYXRoOWsvYXRoOWtfZWVwcm9tXzRrLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25l
dC9hdGgvYXRoOWsvYXRoOWtfY29tbW9uLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgv
YXRoOWsvYXRoOWtfY2FsaWIuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9h
dGg5ay5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19w
aHkuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfbWFj
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAzX2h3LmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAzX2VlcHJvbS5j
DQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19jYWxpYi5j
DQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwMl9waHkuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDJfbWFjLmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX2h3LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX2NhbGliLmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI1MDA4X3BoeS5jDQogIFtSVUxF
U10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FuaS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDVrL2F0aDVrX3Jma2lsbC5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQv
YXRoL2F0aDVrL2F0aDVrX3Jlc2V0LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfcWN1LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtf
cGh5LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfcGN1LmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfaW5pdHZhbHMuYw0KICBbUlVM
RVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19ncGlvLmMNCiAgW1JVTEVTXSBkcml2
ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfZWVwcm9tLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25l
dC9hdGgvYXRoNWsvYXRoNWtfZG1hLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfZGVzYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVr
X2NhcHMuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1ay5jDQogIFtS
VUxFU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX2F0dGFjaC5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvYXRoL2F0aF9yZWdkLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hdGgv
YXRoX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0aC9hdGhfa2V5LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9hdGgvYXRoX2h3LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9y
dGw4MTh4L3J0bDgxOHguYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4
NV9ydGw4MjI1LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ydGw4MTh4L3J0bDgxODUuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4MF9zYTI0MDAuYw0KICBbUlVM
RVNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4MF9tYXgyODIwLmMNCiAgW1JVTEVTXSBk
cml2ZXJzL25ldC9ydGw4MTh4L3J0bDgxODBfZ3JmNTEwMS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvcnRsODE4eC9ydGw4MTgwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9waGFudG9t
L3BoYW50b20uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2lnYnZmL2lnYnZmX3ZmLmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9pZ2J2Zi9pZ2J2Zl9tYnguYw0KICBbUlVMRVNdIGRyaXZl
cnMvbmV0L2lnYnZmL2lnYnZmX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2lnYi9p
Z2JfcGh5LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX252bS5jDQogIFtSVUxF
U10gZHJpdmVycy9uZXQvaWdiL2lnYl9tYW5hZ2UuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0
L2lnYi9pZ2JfbWFpbi5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvaWdiL2lnYl9tYWMuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L2lnYi9pZ2IuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0
L2lnYi9pZ2JfYXBpLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9pZ2IvaWdiXzgyNTc1LmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX3BoeS5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZV9udm0uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0
L2UxMDAwZS9lMTAwMGVfbWFuYWdlLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMGUv
ZTEwMDBlX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfbWFj
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX2ljaDhsYW4uYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGUuYw0KICBbUlVMRVNdIGRyaXZlcnMv
bmV0L2UxMDAwZS9lMTAwMGVfODI1NzEuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAw
ZS9lMTAwMGVfODAwMDNlczJsYW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwL2Ux
MDAwX3BoeS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfbnZtLmMNCiAg
W1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF9tYW5hZ2UuYw0KICBbUlVMRVNdIGRy
aXZlcnMvbmV0L2UxMDAwL2UxMDAwX21haW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2Ux
MDAwL2UxMDAwX21hYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDAuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwX2FwaS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvZTEwMDAvZTEwMDBfODI1NDMuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2Ux
MDAwL2UxMDAwXzgyNTQyLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84
MjU0MS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfODI1NDAuYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0L3dkLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC93ODljODQw
LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC92aXJ0aW8tbmV0LmMNCiAgW1JVTEVTXSBkcml2
ZXJzL25ldC92aWEtdmVsb2NpdHkuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3ZpYS1yaGlu
ZS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvdHVsaXAuYw0KICBbUlVMRVNdIGRyaXZlcnMv
bmV0L3RsYW4uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3RnMy5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvc3VuZGFuY2UuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3NtYzkwMDAuYw0K
ICBbUlVMRVNdIGRyaXZlcnMvbmV0L3NreTIuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3Nr
Z2UuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L3NpczkwMC5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvc2lzMTkwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ydGw4MTM5LmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9yODE2OS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvcHJpc20y
X3BseC5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvcHJpc20yX3BjaS5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvcG5pYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvcGNuZXQzMi5jDQog
IFtSVUxFU10gZHJpdmVycy9uZXQvbnM4MzkwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9u
czgzODIwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9uZS5jDQogIFtSVUxFU10gZHJpdmVy
cy9uZXQvbmUya19pc2EuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L25hdHNlbWkuYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0L215cmkxMGdlLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9t
dGQ4MHguYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2xlZ2FjeS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvam1lLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9pcG9pYi5jDQogIFtSVUxF
U10gZHJpdmVycy9uZXQvZm9yY2VkZXRoLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ldGhl
cmZhYnJpYy5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZXBpYzEwMC5jDQogIFtSVUxFU10g
ZHJpdmVycy9uZXQvZWVwcm8uYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2VlcHJvMTAwLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9kbWZlLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9k
ZXBjYS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvZGF2aWNvbS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvY3M4OXgwLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC9ibngyLmMNCiAgW1JV
TEVTXSBkcml2ZXJzL25ldC9iNDQuYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0L2F0bDFlLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL25ldC9hbWQ4MTExZS5jDQogIFtSVUxFU10gZHJpdmVycy9u
ZXQvM2M5MHguYw0KICBbUlVMRVNdIGRyaXZlcnMvbmV0LzNjNXg5LmMNCiAgW1JVTEVTXSBk
cml2ZXJzL25ldC8zYzU5NS5jDQogIFtSVUxFU10gZHJpdmVycy9uZXQvM2M1MjkuYw0KICBb
UlVMRVNdIGRyaXZlcnMvbmV0LzNjNTE1LmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC8zYzUw
OS1laXNhLmMNCiAgW1JVTEVTXSBkcml2ZXJzL25ldC8zYzUwOS5jDQogIFtSVUxFU10gZHJp
dmVycy9uZXQvM2M1MDMuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL3ZpcnRpby1yaW5nLmMN
CiAgW1JVTEVTXSBkcml2ZXJzL2J1cy92aXJ0aW8tcGNpLmMNCiAgW1JVTEVTXSBkcml2ZXJz
L2J1cy9wY2l2cGQuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL3BjaWV4dHJhLmMNCiAgW1JV
TEVTXSBkcml2ZXJzL2J1cy9wY2kuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL3BjaWJhY2t1
cC5jDQogIFtSVUxFU10gZHJpdmVycy9idXMvbWNhLmMNCiAgW1JVTEVTXSBkcml2ZXJzL2J1
cy9pc2FwbnAuYw0KICBbUlVMRVNdIGRyaXZlcnMvYnVzL2lzYV9pZHMuYw0KICBbUlVMRVNd
IGRyaXZlcnMvYnVzL2lzYS5jDQogIFtSVUxFU10gZHJpdmVycy9idXMvZWlzYS5jDQogIFtS
VUxFU10gaW1hZ2Uvc2VnbWVudC5jDQogIFtSVUxFU10gaW1hZ2Uvc2NyaXB0LmMNCiAgW1JV
TEVTXSBpbWFnZS9lbWJlZGRlZC5jDQogIFtSVUxFU10gaW1hZ2UvZWxmLmMNCiAgW1JVTEVT
XSBpbWFnZS9lZmlfaW1hZ2UuYw0KICBbUlVMRVNdIG5ldC84MDIxMS93cGFfdGtpcC5jDQog
IFtSVUxFU10gbmV0LzgwMjExL3dwYV9wc2suYw0KICBbUlVMRVNdIG5ldC84MDIxMS93cGFf
Y2NtcC5jDQogIFtSVUxFU10gbmV0LzgwMjExL3dwYS5jDQogIFtSVUxFU10gbmV0LzgwMjEx
L3dlcC5jDQogIFtSVUxFU10gbmV0LzgwMjExL3NlYzgwMjExLmMNCiAgW1JVTEVTXSBuZXQv
ODAyMTEvcmM4MDIxMS5jDQogIFtSVUxFU10gbmV0LzgwMjExL25ldDgwMjExLmMNCiAgW1JV
TEVTXSBuZXQvaW5maW5pYmFuZC9pYl9zcnAuYw0KICBbUlVMRVNdIG5ldC9pbmZpbmliYW5k
L2liX3NtYy5jDQogIFtSVUxFU10gbmV0L2luZmluaWJhbmQvaWJfc21hLmMNCiAgW1JVTEVT
XSBuZXQvaW5maW5pYmFuZC9pYl9wYXRocmVjLmMNCiAgW1JVTEVTXSBuZXQvaW5maW5pYmFu
ZC9pYl9wYWNrZXQuYw0KICBbUlVMRVNdIG5ldC9pbmZpbmliYW5kL2liX21pLmMNCiAgW1JV
TEVTXSBuZXQvaW5maW5pYmFuZC9pYl9tY2FzdC5jDQogIFtSVUxFU10gbmV0L2luZmluaWJh
bmQvaWJfY21yYy5jDQogIFtSVUxFU10gbmV0L2luZmluaWJhbmQvaWJfY20uYw0KICBbUlVM
RVNdIG5ldC91ZHAvdGZ0cC5jDQogIFtSVUxFU10gbmV0L3VkcC9zeXNsb2cuYw0KICBbUlVM
RVNdIG5ldC91ZHAvc2xhbS5jDQogIFtSVUxFU10gbmV0L3VkcC9kbnMuYw0KICBbUlVMRVNd
IG5ldC91ZHAvZGhjcC5jDQogIFtSVUxFU10gbmV0L3RjcC9pc2NzaS5jDQogIFtSVUxFU10g
bmV0L3RjcC9odHRwcy5jDQogIFtSVUxFU10gbmV0L3RjcC9odHRwLmMNCiAgW1JVTEVTXSBu
ZXQvdGNwL2Z0cC5jDQogIFtSVUxFU10gbmV0L3ZsYW4uYw0KICBbUlVMRVNdIG5ldC91ZHAu
Yw0KICBbUlVMRVNdIG5ldC90bHMuYw0KICBbUlVMRVNdIG5ldC90Y3BpcC5jDQogIFtSVUxF
U10gbmV0L3RjcC5jDQogIFtSVUxFU10gbmV0L3JldHJ5LmMNCiAgW1JVTEVTXSBuZXQvcmFy
cC5jDQogIFtSVUxFU10gbmV0L251bGxuZXQuYw0KICBbUlVMRVNdIG5ldC9uZXRkZXZfc2V0
dGluZ3MuYw0KICBbUlVMRVNdIG5ldC9uZXRkZXZpY2UuYw0KICBbUlVMRVNdIG5ldC9uZHAu
Yw0KICBbUlVMRVNdIG5ldC9taWkuYw0KICBbUlVMRVNdIG5ldC9pcHY2LmMNCiAgW1JVTEVT
XSBuZXQvaXB2NC5jDQogIFtSVUxFU10gbmV0L2lvYnBhZC5jDQogIFtSVUxFU10gbmV0L2lu
ZmluaWJhbmQuYw0KICBbUlVMRVNdIG5ldC9pY21wdjYuYw0KICBbUlVMRVNdIG5ldC9pY21w
LmMNCiAgW1JVTEVTXSBuZXQvZmNwLmMNCiAgW1JVTEVTXSBuZXQvZmNvZS5jDQogIFtSVUxF
U10gbmV0L2ZjbnMuYw0KICBbUlVMRVNdIG5ldC9mY2Vscy5jDQogIFtSVUxFU10gbmV0L2Zj
LmMNCiAgW1JVTEVTXSBuZXQvZmFrZWRoY3AuYw0KICBbUlVMRVNdIG5ldC9ldGhfc2xvdy5j
DQogIFtSVUxFU10gbmV0L2V0aGVybmV0LmMNCiAgW1JVTEVTXSBuZXQvZWFwb2wuYw0KICBb
UlVMRVNdIG5ldC9kaGNwcGt0LmMNCiAgW1JVTEVTXSBuZXQvZGhjcG9wdHMuYw0KICBbUlVM
RVNdIG5ldC9jYWNoZWRoY3AuYw0KICBbUlVMRVNdIG5ldC9hcnAuYw0KICBbUlVMRVNdIG5l
dC9hb2UuYw0KICBbUlVMRVNdIGNvcmUveGZlci5jDQogIFtSVUxFU10gY29yZS92c3ByaW50
Zi5jDQogIFtSVUxFU10gY29yZS91dWlkLmMNCiAgW1JVTEVTXSBjb3JlL3VyaS5jDQogIFtS
VUxFU10gY29yZS90aW1lci5jDQogIFtSVUxFU10gY29yZS9zdHJ0b3VsbC5jDQogIFtSVUxF
U10gY29yZS9zdHJpbmdleHRyYS5jDQogIFtSVUxFU10gY29yZS9zdHJpbmcuYw0KICBbUlVM
RVNdIGNvcmUvc2V0dGluZ3MuYw0KICBbUlVMRVNdIGNvcmUvc2VyaWFsX2NvbnNvbGUuYw0K
ICBbUlVMRVNdIGNvcmUvc2VyaWFsLmMNCiAgW1JVTEVTXSBjb3JlL3Jlc29sdi5jDQogIFtS
VUxFU10gY29yZS9yZWZjbnQuYw0KICBbUlVMRVNdIGNvcmUvcmFuZG9tLmMNCiAgW1JVTEVT
XSBjb3JlL3Byb2Nlc3MuYw0KICBbUlVMRVNdIGNvcmUvcG9zaXhfaW8uYw0KICBbUlVMRVNd
IGNvcmUvcGNtY2lhLmMNCiAgW1JVTEVTXSBjb3JlL3BjX2tiZC5jDQogIFtSVUxFU10gY29y
ZS9wYXJzZW9wdC5jDQogIFtSVUxFU10gY29yZS9vcGVuLmMNCiAgW1JVTEVTXSBjb3JlL252
by5jDQogIFtSVUxFU10gY29yZS9udWxsX3NhbmJvb3QuYw0KICBbUlVMRVNdIGNvcmUvbnVs
bF9uYXAuYw0KICBbUlVMRVNdIGNvcmUvbW9ub2pvYi5jDQogIFtSVUxFU10gY29yZS9taXNj
LmMNCiAgW1JVTEVTXSBjb3JlL21hbGxvYy5jDQogIFtSVUxFU10gY29yZS9tYWluLmMNCiAg
W1JVTEVTXSBjb3JlL2xpbmVidWYuYw0KICBbUlVMRVNdIGNvcmUvam9iLmMNCiAgW1JVTEVT
XSBjb3JlL2lvYnVmLmMNCiAgW1JVTEVTXSBjb3JlL2ludGVyZmFjZS5jDQogIFtSVUxFU10g
Y29yZS9pbml0LmMNCiAgW1JVTEVTXSBjb3JlL2ltYWdlLmMNCiAgW1JVTEVTXSBjb3JlL2k4
MjM2NS5jDQogIFtSVUxFU10gY29yZS9ody5jDQogIFtSVUxFU10gY29yZS9nZXRvcHQuYw0K
ICBbUlVMRVNdIGNvcmUvZ2V0a2V5LmMNCiAgW1JVTEVTXSBjb3JlL2dkYnVkcC5jDQogIFtS
VUxFU10gY29yZS9nZGJzdHViLmMNCiAgW1JVTEVTXSBjb3JlL2dkYnNlcmlhbC5jDQogIFtS
VUxFU10gY29yZS9mbnJlYy5jDQogIFtSVUxFU10gY29yZS9leGVjLmMNCiAgW1JVTEVTXSBj
b3JlL2Vycm5vLmMNCiAgW1JVTEVTXSBjb3JlL2VkZC5jDQogIFtSVUxFU10gY29yZS9kb3du
bG9hZGVyLmMNCiAgW1JVTEVTXSBjb3JlL2RldmljZS5jDQogIFtSVUxFU10gY29yZS9kZWJ1
Z19tZDUuYw0KICBbUlVMRVNdIGNvcmUvZGVidWcuYw0KICBbUlVMRVNdIGNvcmUvY3d1cmku
Yw0KICBbUlVMRVNdIGNvcmUvY3R5cGUuYw0KICBbUlVMRVNdIGNvcmUvY3Bpby5jDQogIFtS
VUxFU10gY29yZS9jb25zb2xlLmMNCiAgW1JVTEVTXSBjb3JlL2J0ZXh0LmMNCiAgW1JVTEVT
XSBjb3JlL2Jsb2NrZGV2LmMNCiAgW1JVTEVTXSBjb3JlL2JpdG9wcy5jDQogIFtSVUxFU10g
Y29yZS9iaXRtYXAuYw0KICBbUlVMRVNdIGNvcmUvYmFzZW5hbWUuYw0KICBbUlVMRVNdIGNv
cmUvYmFzZTY0LmMNCiAgW1JVTEVTXSBjb3JlL2Jhc2UxNi5jDQogIFtSVUxFU10gY29yZS9h
c3NlcnQuYw0KICBbUlVMRVNdIGNvcmUvYXNwcmludGYuYw0KICBbUlVMRVNdIGNvcmUvYW5z
aWVzYy5jDQogIFtSVUxFU10gY29yZS9hY3BpLmMNCiAgW1JVTEVTXSBsaWJnY2MvX191bW9k
ZGkzLmMNCiAgW1JVTEVTXSBsaWJnY2MvX191ZGl2bW9kZGk0LmMNCiAgW1JVTEVTXSBsaWJn
Y2MvX191ZGl2ZGkzLmMNCiAgW1JVTEVTXSBsaWJnY2MvX19tb2RkaTMuYw0KICBbUlVMRVNd
IGxpYmdjYy9tZW1jcHkuYw0KICBbUlVMRVNdIGxpYmdjYy9pY2MuYw0KICBbUlVMRVNdIGxp
YmdjYy9fX2RpdmRpMy5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaWlz
ci5TDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2NvbTMyX3dyYXBw
ZXIuUw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX2VudHJ5LlMNCiAg
W0RFUFNdIGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvZTgyMG1hbmdsZXIuUw0KICBbREVQ
U10gYXJjaC9pMzg2L3ByZWZpeC91c2JkaXNrLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9wcmVm
aXgvdW5ucnYyYi5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L3VubnJ2MmIxNi5TDQog
IFtERVBTXSBhcmNoL2kzODYvcHJlZml4L3VuZGlsb2FkZXIuUw0KICBbREVQU10gYXJjaC9p
Mzg2L3ByZWZpeC9yb21wcmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L3ByZWZpeC9weGVw
cmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L3ByZWZpeC9udWxscHJlZml4LlMNCiAgW0RF
UFNdIGFyY2gvaTM4Ni9wcmVmaXgvbmJpcHJlZml4LlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9w
cmVmaXgvbXJvbXByZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L21ici5TDQog
IFtERVBTXSBhcmNoL2kzODYvcHJlZml4L2xrcm5wcmVmaXguUw0KICBbREVQU10gYXJjaC9p
Mzg2L3ByZWZpeC9saWJwcmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L3ByZWZpeC9rcHhl
cHJlZml4LlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9wcmVmaXgva2tweGVwcmVmaXguUw0KICBb
REVQU10gYXJjaC9pMzg2L3ByZWZpeC9ra2tweGVwcmVmaXguUw0KICBbREVQU10gYXJjaC9p
Mzg2L3ByZWZpeC9oZHByZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L2V4ZXBy
ZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJlZml4L2Rza3ByZWZpeC5TDQogIFtERVBT
XSBhcmNoL2kzODYvcHJlZml4L2Jvb3RwYXJ0LlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni90cmFu
c2l0aW9ucy9saWJybS5TDQogIFtERVBTXSBhcmNoL2kzODYvdHJhbnNpdGlvbnMvbGlicG0u
Uw0KICBbREVQU10gYXJjaC9pMzg2L3RyYW5zaXRpb25zL2xpYmtpci5TDQogIFtERVBTXSBh
cmNoL2kzODYvdHJhbnNpdGlvbnMvbGliYTIwLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3Jl
L3ZpcnRhZGRyLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3N0YWNrLlMNCiAgW0RFUFNd
IGFyY2gvaTM4Ni9jb3JlL3N0YWNrMTYuUw0KICBbREVQU10gYXJjaC9pMzg2L2NvcmUvc2V0
am1wLlMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3BhdGNoX2NmLlMNCiAgW0RFUFNdIGFy
Y2gvaTM4Ni9jb3JlL2dkYmlkdC5TDQogIFtERVBTXSB0ZXN0cy9nZGJzdHViX3Rlc3QuUw0K
ICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGlyb20uYw0KICBbREVQU10gYXJj
aC9pMzg2L2RyaXZlcnMvbmV0L3VuZGlwcmVsb2FkLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9k
cml2ZXJzL25ldC91bmRpb25seS5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQv
dW5kaW5ldC5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVycy9uZXQvdW5kaWxvYWQuYw0K
ICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGkuYw0KICBbREVQU10gYXJjaC94
ODYvcHJlZml4L2VmaXByZWZpeC5jDQogIFtERVBTXSBhcmNoL3g4Ni9wcmVmaXgvZWZpZHJ2
cHJlZml4LmMNCiAgW0RFUFNdIGFyY2gveDg2L2ludGVyZmFjZS9lZmkvZWZpeDg2X25hcC5j
DQogIFtERVBTXSBhcmNoL3g4Ni9jb3JlL3g4Nl9zdHJpbmcuYw0KICBbREVQU10gYXJjaC94
ODYvY29yZS9wY2lkaXJlY3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2hjaS9jb21tYW5kcy9y
ZWJvb3RfY21kLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9oY2kvY29tbWFuZHMvcHhlX2NtZC5j
DQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2NvbWJvb3RfcmVzb2x2
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uvc3lzbGludXgvY29tYm9vdF9jYWxs
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uvc3lzbGludXgvY29tMzJfY2FsbC5j
DQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZXBhcmVudC9weGVwYXJlbnRfZGhj
cC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZXBhcmVudC9weGVwYXJlbnQu
Yw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3VuZGkuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3VkcC5jDQogIFtERVBTXSBhcmNoL2kz
ODYvaW50ZXJmYWNlL3B4ZS9weGVfdGZ0cC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJm
YWNlL3B4ZS9weGVfcHJlYm9vdC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4
ZS9weGVfbG9hZGVyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9m
aWxlLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9leGl0X2hvb2su
Yw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX2NhbGwuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvcGNpYmlvcy5jDQogIFtERVBTXSBhcmNo
L2kzODYvaW50ZXJmYWNlL3BjYmlvcy9tZW10b3BfdW1hbGxvYy5jDQogIFtERVBTXSBhcmNo
L2kzODYvaW50ZXJmYWNlL3BjYmlvcy9pbnQxMy5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50
ZXJmYWNlL3BjYmlvcy9iaW9zX3RpbWVyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZh
Y2UvcGNiaW9zL2Jpb3Nfc21iaW9zLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2Uv
cGNiaW9zL2Jpb3NfbmFwLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9z
L2Jpb3NpbnQuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdlL3B4ZV9pbWFnZS5jDQogIFtE
RVBTXSBhcmNoL2kzODYvaW1hZ2UvbmJpLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9t
dWx0aWJvb3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdlL2VsZmJvb3QuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ltYWdlL2NvbWJvb3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdl
L2NvbTMyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9iemltYWdlLmMNCiAgW0RFUFNd
IGFyY2gvaTM4Ni9pbWFnZS9ib290c2VjdG9yLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9maXJt
d2FyZS9wY2Jpb3MvcG5wYmlvcy5jDQogIFtERVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNi
aW9zL21lbW1hcC5jDQogIFtERVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2hpZGVt
ZW0uYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3BjYmlvcy9mYWtlZTgyMC5jDQog
IFtERVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2Jpb3NfY29uc29sZS5jDQogIFtE
RVBTXSBhcmNoL2kzODYvZmlybXdhcmUvcGNiaW9zL2Jhc2VtZW0uYw0KICBbREVQU10gYXJj
aC9pMzg2L3RyYW5zaXRpb25zL2xpYnJtX21nbXQuYw0KICBbREVQU10gYXJjaC9pMzg2L2Nv
cmUveDg2X2lvLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3ZpZGVvX3N1YnIuYw0KICBb
REVQU10gYXJjaC9pMzg2L2NvcmUvdGltZXIyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3Jl
L3J1bnRpbWUuYw0KICBbREVQU10gYXJjaC9pMzg2L2NvcmUvcmVsb2NhdGUuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2NvcmUvcmR0c2NfdGltZXIuYw0KICBbREVQU10gYXJjaC9pMzg2L2Nv
cmUvcGljODI1OS5jDQogIFtERVBTXSBhcmNoL2kzODYvY29yZS9udWxsdHJhcC5jDQogIFtE
RVBTXSBhcmNoL2kzODYvY29yZS9nZGJtYWNoLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3Jl
L2R1bXByZWdzLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL2NwdS5jDQogIFtERVBTXSBh
cmNoL2kzODYvY29yZS9iYXNlbWVtX3BhY2tldC5jDQogIFtERVBTXSBjb25maWcvY29uZmln
X3JvbXByZWZpeC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX25ldDgwMjExLmMNCiAgW0RF
UFNdIGNvbmZpZy9jb25maWdfaW5maW5pYmFuZC5jDQogIFtERVBTXSBjb25maWcvY29uZmln
X2ZjLmMNCiAgW0RFUFNdIGNvbmZpZy9jb25maWdfZXRoZXJuZXQuYw0KICBbREVQU10gY29u
ZmlnL2NvbmZpZy5jDQogIFtERVBTXSB1c3Ivcm91dGUuYw0KICBbREVQU10gdXNyL3B4ZW1l
bnUuYw0KICBbREVQU10gdXNyL3Byb21wdC5jDQogIFtERVBTXSB1c3IvbG90ZXN0LmMNCiAg
W0RFUFNdIHVzci9pd21nbXQuYw0KICBbREVQU10gdXNyL2ltZ21nbXQuYw0KICBbREVQU10g
dXNyL2lmbWdtdC5jDQogIFtERVBTXSB1c3IvZmNtZ210LmMNCiAgW0RFUFNdIHVzci9kaGNw
bWdtdC5jDQogIFtERVBTXSB1c3IvYXV0b2Jvb3QuYw0KICBbREVQU10gaGNpL2tleW1hcC9r
ZXltYXBfd28uYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfdXMuYw0KICBbREVQU10g
aGNpL2tleW1hcC9rZXltYXBfdWsuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfdWEu
Yw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfdGguYw0KICBbREVQU10gaGNpL2tleW1h
cC9rZXltYXBfc3IuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfc2cuYw0KICBbREVQ
U10gaGNpL2tleW1hcC9rZXltYXBfcnUuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBf
cm8uYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfcHQuYw0KICBbREVQU10gaGNpL2tl
eW1hcC9rZXltYXBfcGwuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfbm8uYw0KICBb
REVQU10gaGNpL2tleW1hcC9rZXltYXBfbmwuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXlt
YXBfbXQuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfbWsuYw0KICBbREVQU10gaGNp
L2tleW1hcC9rZXltYXBfbHQuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfaXQuYw0K
ICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfaWwuYw0KICBbREVQU10gaGNpL2tleW1hcC9r
ZXltYXBfaHUuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZ3IuYw0KICBbREVQU10g
aGNpL2tleW1hcC9rZXltYXBfZnIuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZmku
Yw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZXQuYw0KICBbREVQU10gaGNpL2tleW1h
cC9rZXltYXBfZXMuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfZGsuYw0KICBbREVQ
U10gaGNpL2tleW1hcC9rZXltYXBfZGUuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBf
Y3ouYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfY2YuYw0KICBbREVQU10gaGNpL2tl
eW1hcC9rZXltYXBfYnkuYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXltYXBfYmcuYw0KICBb
REVQU10gaGNpL2tleW1hcC9rZXltYXBfYXouYw0KICBbREVQU10gaGNpL2tleW1hcC9rZXlt
YXBfYWwuYw0KICBbREVQU10gaGNpL211Y3Vyc2VzL3dpZGdldHMvZWRpdGJveC5jDQogIFtE
RVBTXSBoY2kvbXVjdXJzZXMvd2luaW5pdC5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvd2lu
ZG93cy5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvd2luYXR0cnMuYw0KICBbREVQU10gaGNp
L211Y3Vyc2VzL3Nsay5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvcHJpbnRfbmFkdi5jDQog
IFtERVBTXSBoY2kvbXVjdXJzZXMvcHJpbnQuYw0KICBbREVQU10gaGNpL211Y3Vyc2VzL211
Y3Vyc2VzLmMNCiAgW0RFUFNdIGhjaS9tdWN1cnNlcy9rYi5jDQogIFtERVBTXSBoY2kvbXVj
dXJzZXMvZWRnaW5nLmMNCiAgW0RFUFNdIGhjaS9tdWN1cnNlcy9jb2xvdXIuYw0KICBbREVQ
U10gaGNpL211Y3Vyc2VzL2NsZWFyLmMNCiAgW0RFUFNdIGhjaS9tdWN1cnNlcy9hbnNpX3Nj
cmVlbi5jDQogIFtERVBTXSBoY2kvbXVjdXJzZXMvYWxlcnQuYw0KICBbREVQU10gaGNpL3R1
aS9zZXR0aW5nc191aS5jDQogIFtERVBTXSBoY2kvdHVpL2xvZ2luX3VpLmMNCiAgW0RFUFNd
IGhjaS9jb21tYW5kcy92bGFuX2NtZC5jDQogIFtERVBTXSBoY2kvY29tbWFuZHMvdGltZV9j
bWQuYw0KICBbREVQU10gaGNpL2NvbW1hbmRzL3NhbmJvb3RfY21kLmMNCiAgW0RFUFNdIGhj
aS9jb21tYW5kcy9yb3V0ZV9jbWQuYw0KICBbREVQU10gaGNpL2NvbW1hbmRzL252b19jbWQu
Yw0KICBbREVQU10gaGNpL2NvbW1hbmRzL2xvdGVzdF9jbWQuYw0KICBbREVQU10gaGNpL2Nv
bW1hbmRzL2xvZ2luX2NtZC5jDQogIFtERVBTXSBoY2kvY29tbWFuZHMvaXdtZ210X2NtZC5j
DQogIFtERVBTXSBoY2kvY29tbWFuZHMvaW1hZ2VfY21kLmMNCiAgW0RFUFNdIGhjaS9jb21t
YW5kcy9pZm1nbXRfY21kLmMNCiAgW0RFUFNdIGhjaS9jb21tYW5kcy9nZGJzdHViX2NtZC5j
DQogIFtERVBTXSBoY2kvY29tbWFuZHMvZmNtZ210X2NtZC5jDQogIFtERVBTXSBoY2kvY29t
bWFuZHMvZGlnZXN0X2NtZC5jDQogIFtERVBTXSBoY2kvY29tbWFuZHMvZGhjcF9jbWQuYw0K
ICBbREVQU10gaGNpL2NvbW1hbmRzL2NvbmZpZ19jbWQuYw0KICBbREVQU10gaGNpL2NvbW1h
bmRzL2F1dG9ib290X2NtZC5jDQogIFtERVBTXSBoY2kvd2lyZWxlc3NfZXJyb3JzLmMNCiAg
W0RFUFNdIGhjaS9zdHJlcnJvci5jDQogIFtERVBTXSBoY2kvc2hlbGwuYw0KICBbREVQU10g
aGNpL3JlYWRsaW5lLmMNCiAgW0RFUFNdIGhjaS9saW51eF9hcmdzLmMNCiAgW0RFUFNdIGhj
aS9lZGl0c3RyaW5nLmMNCiAgW0RFUFNdIGNyeXB0by9heHRscy9zaGExLmMNCiAgW0RFUFNd
IGNyeXB0by9heHRscy9yc2EuYw0KICBbREVQU10gY3J5cHRvL2F4dGxzL2JpZ2ludC5jDQog
IFtERVBTXSBjcnlwdG8vYXh0bHMvYWVzLmMNCiAgW0RFUFNdIGNyeXB0by94NTA5LmMNCiAg
W0RFUFNdIGNyeXB0by9zaGExZXh0cmEuYw0KICBbREVQU10gY3J5cHRvL21kNS5jDQogIFtE
RVBTXSBjcnlwdG8vaG1hYy5jDQogIFtERVBTXSBjcnlwdG8vY3J5cHRvX251bGwuYw0KICBb
REVQU10gY3J5cHRvL2NyYzMyLmMNCiAgW0RFUFNdIGNyeXB0by9jcmFuZG9tLmMNCiAgW0RF
UFNdIGNyeXB0by9jaGFwLmMNCiAgW0RFUFNdIGNyeXB0by9jYmMuYw0KICBbREVQU10gY3J5
cHRvL2F4dGxzX3NoYTEuYw0KICBbREVQU10gY3J5cHRvL2F4dGxzX2Flcy5jDQogIFtERVBT
XSBjcnlwdG8vYXNuMS5jDQogIFtERVBTXSBjcnlwdG8vYXJjNC5jDQogIFtERVBTXSBjcnlw
dG8vYWVzX3dyYXAuYw0KICBbREVQU10gdGVzdHMvdXJpX3Rlc3QuYw0KICBbREVQU10gdGVz
dHMvdW1hbGxvY190ZXN0LmMNCiAgW0RFUFNdIHRlc3RzL3Rlc3QuYw0KICBbREVQU10gdGVz
dHMvbWVtY3B5X3Rlc3QuYw0KICBbREVQU10gdGVzdHMvbGlzdF90ZXN0LmMNCiAgW0RFUFNd
IHRlc3RzL2xpbmVidWZfdGVzdC5jDQogIFtERVBTXSB0ZXN0cy9ib2ZtX3Rlc3QuYw0KICBb
REVQU10gaW50ZXJmYWNlL2JvZm0vYm9mbS5jDQogIFtERVBTXSBpbnRlcmZhY2Uvc21iaW9z
L3NtYmlvc19zZXR0aW5ncy5jDQogIFtERVBTXSBpbnRlcmZhY2Uvc21iaW9zL3NtYmlvcy5j
DQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV91bWFsbG9jLmMNCiAgW0RFUFNdIGludGVy
ZmFjZS9lZmkvZWZpX3VhY2Nlc3MuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfdGlt
ZXIuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfc3RyaW5ncy5jDQogIFtERVBTXSBp
bnRlcmZhY2UvZWZpL2VmaV9zdHJlcnJvci5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2Vm
aV9zbnAuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfc21iaW9zLmMNCiAgW0RFUFNd
IGludGVyZmFjZS9lZmkvZWZpX3BjaS5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9p
by5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9pbml0LmMNCiAgW0RFUFNdIGludGVy
ZmFjZS9lZmkvZWZpX2RyaXZlci5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9jb25z
b2xlLmMNCiAgW0RFUFNdIGludGVyZmFjZS9lZmkvZWZpX2JvZm0uYw0KICBbREVQU10gZHJp
dmVycy9pbmZpbmliYW5kL3FpYjczMjIuYw0KICBbREVQU10gZHJpdmVycy9pbmZpbmliYW5k
L2xpbmRhX2Z3LmMNCiAgW0RFUFNdIGRyaXZlcnMvaW5maW5pYmFuZC9saW5kYS5jDQogIFtE
RVBTXSBkcml2ZXJzL2luZmluaWJhbmQvaGVybW9uLmMNCiAgW0RFUFNdIGRyaXZlcnMvaW5m
aW5pYmFuZC9hcmJlbC5jDQogIFtERVBTXSBkcml2ZXJzL2JpdGJhc2gvc3BpX2JpdC5jDQog
IFtERVBTXSBkcml2ZXJzL2JpdGJhc2gvaTJjX2JpdC5jDQogIFtERVBTXSBkcml2ZXJzL2Jp
dGJhc2gvYml0YmFzaC5jDQogIFtERVBTXSBkcml2ZXJzL252cy90aHJlZXdpcmUuYw0KICBb
REVQU10gZHJpdmVycy9udnMvc3BpLmMNCiAgW0RFUFNdIGRyaXZlcnMvbnZzL252c3ZwZC5j
DQogIFtERVBTXSBkcml2ZXJzL252cy9udnMuYw0KICBbREVQU10gZHJpdmVycy9ibG9jay9z
cnAuYw0KICBbREVQU10gZHJpdmVycy9ibG9jay9zY3NpLmMNCiAgW0RFUFNdIGRyaXZlcnMv
YmxvY2svaWJmdC5jDQogIFtERVBTXSBkcml2ZXJzL2Jsb2NrL2F0YS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9lZmkvc25wb25seS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lZmkvc25w
bmV0LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV90cmFmZmljLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV9tYWluLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L3Z4Z2UvdnhnZV9jb25maWcuYw0KICBbREVQU10gZHJpdmVycy9uZXQvdnhnZS92eGdlLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a194bWl0LmMNCiAgW0RFUFNd
IGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19yZWN2LmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L2F0aC9hdGg5ay9hdGg5a19tYWluLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9h
dGg5ay9hdGg5a19tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlr
X2luaXQuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2h3LmMNCiAg
W0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb21fZGVmLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb20uYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbV85Mjg3LmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb21fNGsuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvYXRoL2F0aDlrL2F0aDlrX2NvbW1vbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgv
YXRoOWsvYXRoOWtfY2FsaWIuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0
aDlrLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfcGh5
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfbWFjLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDNfaHcuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19lZXByb20uYw0KICBb
REVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyOTAwM19jYWxpYi5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX3BoeS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX21hYy5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAyX2h3LmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDJfY2FsaWIuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyNTAwOF9waHkuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvYXRoL2F0aDlrL2F0aDlrX2FuaS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfcmZraWxsLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1
a19yZXNldC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfcWN1LmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19waHkuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX3BjdS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9hdGgvYXRoNWsvYXRoNWtfaW5pdHZhbHMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRo
L2F0aDVrL2F0aDVrX2dwaW8uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0
aDVrX2VlcHJvbS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfZG1h
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19kZXNjLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19jYXBzLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg1ay9hdGg1ay5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRo
NWsvYXRoNWtfYXR0YWNoLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGhfcmVnZC5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoX21haW4uYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvYXRoL2F0aF9rZXkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aF9ody5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9ydGw4MTh4L3J0bDgxOHguYw0KICBbREVQU10gZHJp
dmVycy9uZXQvcnRsODE4eC9ydGw4MTg1X3J0bDgyMjUuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvcnRsODE4eC9ydGw4MTg1LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3J0bDgxOHgvcnRs
ODE4MF9zYTI0MDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTgwX21h
eDI4MjAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTgwX2dyZjUxMDEu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTgwLmMNCiAgW0RFUFNdIGRy
aXZlcnMvbmV0L3BoYW50b20vcGhhbnRvbS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2J2
Zi9pZ2J2Zl92Zi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2J2Zi9pZ2J2Zl9tYnguYw0K
ICBbREVQU10gZHJpdmVycy9uZXQvaWdidmYvaWdidmZfbWFpbi5jDQogIFtERVBTXSBkcml2
ZXJzL25ldC9pZ2IvaWdiX3BoeS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX252
bS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX21hbmFnZS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9pZ2IvaWdiX21haW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdiL2ln
Yl9tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdiL2lnYi5jDQogIFtERVBTXSBkcml2
ZXJzL25ldC9pZ2IvaWdiX2FwaS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiXzgy
NTc1LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfcGh5LmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfbnZtLmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L2UxMDAwZS9lMTAwMGVfbWFuYWdlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAw
ZS9lMTAwMGVfbWFpbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX21h
Yy5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX2ljaDhsYW4uYw0KICBb
REVQU10gZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9lMTAwMGUvZTEwMDBlXzgyNTcxLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9l
MTAwMGVfODAwMDNlczJsYW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBf
cGh5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwX252bS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF9tYW5hZ2UuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvZTEwMDAvZTEwMDBfbWFpbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAw
MF9tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDAuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfYXBpLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2Ux
MDAwL2UxMDAwXzgyNTQzLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwXzgy
NTQyLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwXzgyNTQxLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwXzgyNTQwLmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L3dkLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3c4OWM4NDAuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvdmlydGlvLW5ldC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC92aWEtdmVsb2Np
dHkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvdmlhLXJoaW5lLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L3R1bGlwLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3RsYW4uYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvdGczLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3N1bmRhbmNlLmMNCiAg
W0RFUFNdIGRyaXZlcnMvbmV0L3NtYzkwMDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvc2t5
Mi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9za2dlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L3NpczkwMC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9zaXMxOTAuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvcnRsODEzOS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9yODE2OS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9wcmlzbTJfcGx4LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3By
aXNtMl9wY2kuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcG5pYy5jDQogIFtERVBTXSBkcml2
ZXJzL25ldC9wY25ldDMyLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L25zODM5MC5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9uczgzODIwLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L25lLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L25lMmtfaXNhLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L25hdHNlbWkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvbXlyaTEwZ2UuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvbXRkODB4LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2xlZ2FjeS5jDQog
IFtERVBTXSBkcml2ZXJzL25ldC9qbWUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaXBvaWIu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvZm9yY2VkZXRoLmMNCiAgW0RFUFNdIGRyaXZlcnMv
bmV0L2V0aGVyZmFicmljLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2VwaWMxMDAuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvZWVwcm8uYw0KICBbREVQU10gZHJpdmVycy9uZXQvZWVwcm8x
MDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZG1mZS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9kZXBjYS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9kYXZpY29tLmMNCiAgW0RFUFNdIGRy
aXZlcnMvbmV0L2NzODl4MC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9ibngyLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2I0NC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGwxZS5jDQog
IFtERVBTXSBkcml2ZXJzL25ldC9hbWQ4MTExZS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8z
YzkweC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzV4OS5jDQogIFtERVBTXSBkcml2ZXJz
L25ldC8zYzU5NS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzUyOS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC8zYzUxNS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzUwOS1laXNhLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0LzNjNTA5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0LzNj
NTAzLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL3ZpcnRpby1yaW5nLmMNCiAgW0RFUFNdIGRy
aXZlcnMvYnVzL3ZpcnRpby1wY2kuYw0KICBbREVQU10gZHJpdmVycy9idXMvcGNpdnBkLmMN
CiAgW0RFUFNdIGRyaXZlcnMvYnVzL3BjaWV4dHJhLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVz
L3BjaS5jDQogIFtERVBTXSBkcml2ZXJzL2J1cy9wY2liYWNrdXAuYw0KICBbREVQU10gZHJp
dmVycy9idXMvbWNhLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL2lzYXBucC5jDQogIFtERVBT
XSBkcml2ZXJzL2J1cy9pc2FfaWRzLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL2lzYS5jDQog
IFtERVBTXSBkcml2ZXJzL2J1cy9laXNhLmMNCiAgW0RFUFNdIGltYWdlL3NlZ21lbnQuYw0K
ICBbREVQU10gaW1hZ2Uvc2NyaXB0LmMNCiAgW0RFUFNdIGltYWdlL2VtYmVkZGVkLmMNCiAg
W0RFUFNdIGltYWdlL2VsZi5jDQogIFtERVBTXSBpbWFnZS9lZmlfaW1hZ2UuYw0KICBbREVQ
U10gbmV0LzgwMjExL3dwYV90a2lwLmMNCiAgW0RFUFNdIG5ldC84MDIxMS93cGFfcHNrLmMN
CiAgW0RFUFNdIG5ldC84MDIxMS93cGFfY2NtcC5jDQogIFtERVBTXSBuZXQvODAyMTEvd3Bh
LmMNCiAgW0RFUFNdIG5ldC84MDIxMS93ZXAuYw0KICBbREVQU10gbmV0LzgwMjExL3NlYzgw
MjExLmMNCiAgW0RFUFNdIG5ldC84MDIxMS9yYzgwMjExLmMNCiAgW0RFUFNdIG5ldC84MDIx
MS9uZXQ4MDIxMS5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9pYl9zcnAuYw0KICBbREVQ
U10gbmV0L2luZmluaWJhbmQvaWJfc21jLmMNCiAgW0RFUFNdIG5ldC9pbmZpbmliYW5kL2li
X3NtYS5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9pYl9wYXRocmVjLmMNCiAgW0RFUFNd
IG5ldC9pbmZpbmliYW5kL2liX3BhY2tldC5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9p
Yl9taS5jDQogIFtERVBTXSBuZXQvaW5maW5pYmFuZC9pYl9tY2FzdC5jDQogIFtERVBTXSBu
ZXQvaW5maW5pYmFuZC9pYl9jbXJjLmMNCiAgW0RFUFNdIG5ldC9pbmZpbmliYW5kL2liX2Nt
LmMNCiAgW0RFUFNdIG5ldC91ZHAvdGZ0cC5jDQogIFtERVBTXSBuZXQvdWRwL3N5c2xvZy5j
DQogIFtERVBTXSBuZXQvdWRwL3NsYW0uYw0KICBbREVQU10gbmV0L3VkcC9kbnMuYw0KICBb
REVQU10gbmV0L3VkcC9kaGNwLmMNCiAgW0RFUFNdIG5ldC90Y3AvaXNjc2kuYw0KICBbREVQ
U10gbmV0L3RjcC9odHRwcy5jDQogIFtERVBTXSBuZXQvdGNwL2h0dHAuYw0KICBbREVQU10g
bmV0L3RjcC9mdHAuYw0KICBbREVQU10gbmV0L3ZsYW4uYw0KICBbREVQU10gbmV0L3VkcC5j
DQogIFtERVBTXSBuZXQvdGxzLmMNCiAgW0RFUFNdIG5ldC90Y3BpcC5jDQogIFtERVBTXSBu
ZXQvdGNwLmMNCiAgW0RFUFNdIG5ldC9yZXRyeS5jDQogIFtERVBTXSBuZXQvcmFycC5jDQog
IFtERVBTXSBuZXQvbnVsbG5ldC5jDQogIFtERVBTXSBuZXQvbmV0ZGV2X3NldHRpbmdzLmMN
CiAgW0RFUFNdIG5ldC9uZXRkZXZpY2UuYw0KICBbREVQU10gbmV0L25kcC5jDQogIFtERVBT
XSBuZXQvbWlpLmMNCiAgW0RFUFNdIG5ldC9pcHY2LmMNCiAgW0RFUFNdIG5ldC9pcHY0LmMN
CiAgW0RFUFNdIG5ldC9pb2JwYWQuYw0KICBbREVQU10gbmV0L2luZmluaWJhbmQuYw0KICBb
REVQU10gbmV0L2ljbXB2Ni5jDQogIFtERVBTXSBuZXQvaWNtcC5jDQogIFtERVBTXSBuZXQv
ZmNwLmMNCiAgW0RFUFNdIG5ldC9mY29lLmMNCiAgW0RFUFNdIG5ldC9mY25zLmMNCiAgW0RF
UFNdIG5ldC9mY2Vscy5jDQogIFtERVBTXSBuZXQvZmMuYw0KICBbREVQU10gbmV0L2Zha2Vk
aGNwLmMNCiAgW0RFUFNdIG5ldC9ldGhfc2xvdy5jDQogIFtERVBTXSBuZXQvZXRoZXJuZXQu
Yw0KICBbREVQU10gbmV0L2VhcG9sLmMNCiAgW0RFUFNdIG5ldC9kaGNwcGt0LmMNCiAgW0RF
UFNdIG5ldC9kaGNwb3B0cy5jDQogIFtERVBTXSBuZXQvY2FjaGVkaGNwLmMNCiAgW0RFUFNd
IG5ldC9hcnAuYw0KICBbREVQU10gbmV0L2FvZS5jDQogIFtERVBTXSBjb3JlL3hmZXIuYw0K
ICBbREVQU10gY29yZS92c3ByaW50Zi5jDQogIFtERVBTXSBjb3JlL3V1aWQuYw0KICBbREVQ
U10gY29yZS91cmkuYw0KICBbREVQU10gY29yZS90aW1lci5jDQogIFtERVBTXSBjb3JlL3N0
cnRvdWxsLmMNCiAgW0RFUFNdIGNvcmUvc3RyaW5nZXh0cmEuYw0KICBbREVQU10gY29yZS9z
dHJpbmcuYw0KICBbREVQU10gY29yZS9zZXR0aW5ncy5jDQogIFtERVBTXSBjb3JlL3Nlcmlh
bF9jb25zb2xlLmMNCiAgW0RFUFNdIGNvcmUvc2VyaWFsLmMNCiAgW0RFUFNdIGNvcmUvcmVz
b2x2LmMNCiAgW0RFUFNdIGNvcmUvcmVmY250LmMNCiAgW0RFUFNdIGNvcmUvcmFuZG9tLmMN
CiAgW0RFUFNdIGNvcmUvcHJvY2Vzcy5jDQogIFtERVBTXSBjb3JlL3Bvc2l4X2lvLmMNCiAg
W0RFUFNdIGNvcmUvcGNtY2lhLmMNCiAgW0RFUFNdIGNvcmUvcGNfa2JkLmMNCiAgW0RFUFNd
IGNvcmUvcGFyc2VvcHQuYw0KICBbREVQU10gY29yZS9vcGVuLmMNCiAgW0RFUFNdIGNvcmUv
bnZvLmMNCiAgW0RFUFNdIGNvcmUvbnVsbF9zYW5ib290LmMNCiAgW0RFUFNdIGNvcmUvbnVs
bF9uYXAuYw0KICBbREVQU10gY29yZS9tb25vam9iLmMNCiAgW0RFUFNdIGNvcmUvbWlzYy5j
DQogIFtERVBTXSBjb3JlL21hbGxvYy5jDQogIFtERVBTXSBjb3JlL21haW4uYw0KICBbREVQ
U10gY29yZS9saW5lYnVmLmMNCiAgW0RFUFNdIGNvcmUvam9iLmMNCiAgW0RFUFNdIGNvcmUv
aW9idWYuYw0KICBbREVQU10gY29yZS9pbnRlcmZhY2UuYw0KICBbREVQU10gY29yZS9pbml0
LmMNCiAgW0RFUFNdIGNvcmUvaW1hZ2UuYw0KICBbREVQU10gY29yZS9pODIzNjUuYw0KICBb
REVQU10gY29yZS9ody5jDQogIFtERVBTXSBjb3JlL2dldG9wdC5jDQogIFtERVBTXSBjb3Jl
L2dldGtleS5jDQogIFtERVBTXSBjb3JlL2dkYnVkcC5jDQogIFtERVBTXSBjb3JlL2dkYnN0
dWIuYw0KICBbREVQU10gY29yZS9nZGJzZXJpYWwuYw0KICBbREVQU10gY29yZS9mbnJlYy5j
DQogIFtERVBTXSBjb3JlL2V4ZWMuYw0KICBbREVQU10gY29yZS9lcnJuby5jDQogIFtERVBT
XSBjb3JlL2VkZC5jDQogIFtERVBTXSBjb3JlL2Rvd25sb2FkZXIuYw0KICBbREVQU10gY29y
ZS9kZXZpY2UuYw0KICBbREVQU10gY29yZS9kZWJ1Z19tZDUuYw0KICBbREVQU10gY29yZS9k
ZWJ1Zy5jDQogIFtERVBTXSBjb3JlL2N3dXJpLmMNCiAgW0RFUFNdIGNvcmUvY3R5cGUuYw0K
ICBbREVQU10gY29yZS9jcGlvLmMNCiAgW0RFUFNdIGNvcmUvY29uc29sZS5jDQogIFtERVBT
XSBjb3JlL2J0ZXh0LmMNCiAgW0RFUFNdIGNvcmUvYmxvY2tkZXYuYw0KICBbREVQU10gY29y
ZS9iaXRvcHMuYw0KICBbREVQU10gY29yZS9iaXRtYXAuYw0KICBbREVQU10gY29yZS9iYXNl
bmFtZS5jDQogIFtERVBTXSBjb3JlL2Jhc2U2NC5jDQogIFtERVBTXSBjb3JlL2Jhc2UxNi5j
DQogIFtERVBTXSBjb3JlL2Fzc2VydC5jDQogIFtERVBTXSBjb3JlL2FzcHJpbnRmLmMNCiAg
W0RFUFNdIGNvcmUvYW5zaWVzYy5jDQogIFtERVBTXSBjb3JlL2FjcGkuYw0KICBbREVQU10g
bGliZ2NjL19fdW1vZGRpMy5jDQogIFtERVBTXSBsaWJnY2MvX191ZGl2bW9kZGk0LmMNCiAg
W0RFUFNdIGxpYmdjYy9fX3VkaXZkaTMuYw0KICBbREVQU10gbGliZ2NjL19fbW9kZGkzLmMN
CiAgW0RFUFNdIGxpYmdjYy9tZW1jcHkuYw0KICBbREVQU10gbGliZ2NjL2ljYy5jDQogIFtE
RVBTXSBsaWJnY2MvX19kaXZkaTMuYw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvaXB4
ZS9zcmMnDQptYWtlWzddOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11
bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvaXB4ZS9zcmMnDQogIFtERVBT
XSBhcmNoL2kzODYvcHJlZml4L3JvbXByZWZpeC5TDQogIFtERVBTXSBhcmNoL2kzODYvcHJl
Zml4L21yb21wcmVmaXguUw0KICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGly
b20uYw0KICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGlwcmVsb2FkLmMNCiAg
W0RFUFNdIGFyY2gvaTM4Ni9kcml2ZXJzL25ldC91bmRpb25seS5jDQogIFtERVBTXSBhcmNo
L2kzODYvZHJpdmVycy9uZXQvdW5kaW5ldC5jDQogIFtERVBTXSBhcmNoL2kzODYvZHJpdmVy
cy9uZXQvdW5kaWxvYWQuYw0KICBbREVQU10gYXJjaC9pMzg2L2RyaXZlcnMvbmV0L3VuZGku
Yw0KICBbREVQU10gYXJjaC94ODYvaW50ZXJmYWNlL2VmaS9lZml4ODZfbmFwLmMNCiAgW0RF
UFNdIGFyY2gveDg2L2NvcmUvcGNpZGlyZWN0LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9oY2kv
Y29tbWFuZHMvcmVib290X2NtZC5jDQogIFtERVBTXSBhcmNoL2kzODYvaGNpL2NvbW1hbmRz
L3B4ZV9jbWQuYw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9zeXNsaW51eC9jb21i
b290X3Jlc29sdi5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2Nv
bWJvb3RfY2FsbC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3N5c2xpbnV4L2Nv
bTMyX2NhbGwuYw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGVwYXJlbnQvcHhl
cGFyZW50X2RoY3AuYw0KICBbREVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGVwYXJlbnQv
cHhlcGFyZW50LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV91bmRp
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV91ZHAuYw0KICBbREVQ
U10gYXJjaC9pMzg2L2ludGVyZmFjZS9weGUvcHhlX3RmdHAuYw0KICBbREVQU10gYXJjaC9p
Mzg2L2ludGVyZmFjZS9weGUvcHhlX3ByZWJvb3QuYw0KICBbREVQU10gYXJjaC9pMzg2L2lu
dGVyZmFjZS9weGUvcHhlX2xvYWRlci5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNl
L3B4ZS9weGVfZmlsZS5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJmYWNlL3B4ZS9weGVf
ZXhpdF9ob29rLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcHhlL3B4ZV9jYWxs
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbnRlcmZhY2UvcGNiaW9zL3BjaWJpb3MuYw0KICBb
REVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvbWVtdG9wX3VtYWxsb2MuYw0KICBb
REVQU10gYXJjaC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvaW50MTMuYw0KICBbREVQU10gYXJj
aC9pMzg2L2ludGVyZmFjZS9wY2Jpb3MvYmlvc190aW1lci5jDQogIFtERVBTXSBhcmNoL2kz
ODYvaW50ZXJmYWNlL3BjYmlvcy9iaW9zX3NtYmlvcy5jDQogIFtERVBTXSBhcmNoL2kzODYv
aW50ZXJmYWNlL3BjYmlvcy9iaW9zX25hcC5jDQogIFtERVBTXSBhcmNoL2kzODYvaW50ZXJm
YWNlL3BjYmlvcy9iaW9zaW50LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9weGVfaW1h
Z2UuYw0KICBbREVQU10gYXJjaC9pMzg2L2ltYWdlL25iaS5jDQogIFtERVBTXSBhcmNoL2kz
ODYvaW1hZ2UvbXVsdGlib290LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9lbGZib290
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9pbWFnZS9jb21ib290LmMNCiAgW0RFUFNdIGFyY2gv
aTM4Ni9pbWFnZS9jb20zMi5jDQogIFtERVBTXSBhcmNoL2kzODYvaW1hZ2UvYnppbWFnZS5j
DQogIFtERVBTXSBhcmNoL2kzODYvaW1hZ2UvYm9vdHNlY3Rvci5jDQogIFtERVBTXSBhcmNo
L2kzODYvZmlybXdhcmUvcGNiaW9zL3BucGJpb3MuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zp
cm13YXJlL3BjYmlvcy9tZW1tYXAuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3Bj
Ymlvcy9oaWRlbWVtLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9maXJtd2FyZS9wY2Jpb3MvZmFr
ZWU4MjAuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3BjYmlvcy9iaW9zX2NvbnNv
bGUuYw0KICBbREVQU10gYXJjaC9pMzg2L2Zpcm13YXJlL3BjYmlvcy9iYXNlbWVtLmMNCiAg
W0RFUFNdIGFyY2gvaTM4Ni90cmFuc2l0aW9ucy9saWJybV9tZ210LmMNCiAgW0RFUFNdIGFy
Y2gvaTM4Ni9jb3JlL3g4Nl9pby5jDQogIFtERVBTXSBhcmNoL2kzODYvY29yZS92aWRlb19z
dWJyLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3RpbWVyMi5jDQogIFtERVBTXSBhcmNo
L2kzODYvY29yZS9ydW50aW1lLmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3JlbG9jYXRl
LmMNCiAgW0RFUFNdIGFyY2gvaTM4Ni9jb3JlL3JkdHNjX3RpbWVyLmMNCiAgW0RFUFNdIGFy
Y2gvaTM4Ni9jb3JlL3BpYzgyNTkuYw0KICBbREVQU10gYXJjaC9pMzg2L2NvcmUvZ2RibWFj
aC5jDQogIFtERVBTXSBhcmNoL2kzODYvY29yZS9kdW1wcmVncy5jDQogIFtERVBTXSBhcmNo
L2kzODYvY29yZS9iYXNlbWVtX3BhY2tldC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX3Jv
bXByZWZpeC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX25ldDgwMjExLmMNCiAgW0RFUFNd
IGNvbmZpZy9jb25maWdfaW5maW5pYmFuZC5jDQogIFtERVBTXSBjb25maWcvY29uZmlnX2Zj
LmMNCiAgW0RFUFNdIGNvbmZpZy9jb25maWdfZXRoZXJuZXQuYw0KICBbREVQU10gY29uZmln
L2NvbmZpZy5jDQogIFtERVBTXSB1c3IvcHhlbWVudS5jDQogIFtERVBTXSB1c3IvcHJvbXB0
LmMNCiAgW0RFUFNdIHVzci9pbWdtZ210LmMNCiAgW0RFUFNdIHVzci9pZm1nbXQuYw0KICBb
REVQU10gdXNyL2RoY3BtZ210LmMNCiAgW0RFUFNdIHVzci9hdXRvYm9vdC5jDQogIFtERVBT
XSBoY2kvbXVjdXJzZXMva2IuYw0KICBbREVQU10gaGNpL3R1aS9zZXR0aW5nc191aS5jDQog
IFtERVBTXSBoY2kvY29tbWFuZHMvdGltZV9jbWQuYw0KICBbREVQU10gaGNpL2NvbW1hbmRz
L3NhbmJvb3RfY21kLmMNCiAgW0RFUFNdIGhjaS9jb21tYW5kcy9pbWFnZV9jbWQuYw0KICBb
REVQU10gaGNpL2NvbW1hbmRzL2RpZ2VzdF9jbWQuYw0KICBbREVQU10gdGVzdHMvdW1hbGxv
Y190ZXN0LmMNCiAgW0RFUFNdIHRlc3RzL2JvZm1fdGVzdC5jDQogIFtERVBTXSBpbnRlcmZh
Y2UvYm9mbS9ib2ZtLmMNCiAgW0RFUFNdIGludGVyZmFjZS9zbWJpb3Mvc21iaW9zX3NldHRp
bmdzLmMNCiAgW0RFUFNdIGludGVyZmFjZS9zbWJpb3Mvc21iaW9zLmMNCiAgW0RFUFNdIGlu
dGVyZmFjZS9lZmkvZWZpX3VtYWxsb2MuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlf
dWFjY2Vzcy5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV90aW1lci5jDQogIFtERVBT
XSBpbnRlcmZhY2UvZWZpL2VmaV9zbnAuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlf
c21iaW9zLmMNCiAgW0RFUFNdIGludGVyZmFjZS9lZmkvZWZpX3BjaS5jDQogIFtERVBTXSBp
bnRlcmZhY2UvZWZpL2VmaV9pby5jDQogIFtERVBTXSBpbnRlcmZhY2UvZWZpL2VmaV9kcml2
ZXIuYw0KICBbREVQU10gaW50ZXJmYWNlL2VmaS9lZmlfYm9mbS5jDQogIFtERVBTXSBkcml2
ZXJzL2luZmluaWJhbmQvcWliNzMyMi5jDQogIFtERVBTXSBkcml2ZXJzL2luZmluaWJhbmQv
bGluZGEuYw0KICBbREVQU10gZHJpdmVycy9pbmZpbmliYW5kL2hlcm1vbi5jDQogIFtERVBT
XSBkcml2ZXJzL2luZmluaWJhbmQvYXJiZWwuYw0KICBbREVQU10gZHJpdmVycy9iaXRiYXNo
L3NwaV9iaXQuYw0KICBbREVQU10gZHJpdmVycy9iaXRiYXNoL2kyY19iaXQuYw0KICBbREVQ
U10gZHJpdmVycy9udnMvdGhyZWV3aXJlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbnZzL3NwaS5j
DQogIFtERVBTXSBkcml2ZXJzL252cy9udnN2cGQuYw0KICBbREVQU10gZHJpdmVycy9ibG9j
ay9zcnAuYw0KICBbREVQU10gZHJpdmVycy9ibG9jay9zY3NpLmMNCiAgW0RFUFNdIGRyaXZl
cnMvYmxvY2svaWJmdC5jDQogIFtERVBTXSBkcml2ZXJzL2Jsb2NrL2F0YS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9lZmkvc25wbmV0LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2Uv
dnhnZV90cmFmZmljLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV9tYWluLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L3Z4Z2UvdnhnZV9jb25maWcuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvdnhnZS92eGdlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9h
dGg5a194bWl0LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19yZWN2
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19tYWluLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19tYWMuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvYXRoL2F0aDlrL2F0aDlrX2luaXQuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRo
L2F0aDlrL2F0aDlrX2h3LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5
a19lZXByb21fZGVmLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19l
ZXByb20uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2VlcHJvbV85
Mjg3LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19lZXByb21fNGsu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2NvbW1vbi5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfY2FsaWIuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9h
dGg5ay9hdGg5a19hcjkwMDNfcGh5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5
ay9hdGg5a19hcjkwMDNfbWFjLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9h
dGg5a19hcjkwMDNfaHcuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlr
X2FyOTAwM19lZXByb20uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlr
X2FyOTAwM19jYWxpYi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtf
YXI5MDAyX3BoeS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5
MDAyX21hYy5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoOWsvYXRoOWtfYXI5MDAy
X2h3LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg5ay9hdGg5a19hcjkwMDJfY2Fs
aWIuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FyNTAwOF9waHku
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDlrL2F0aDlrX2FuaS5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfcmZraWxsLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGg1ay9hdGg1a19yZXNldC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9h
dGgvYXRoNWsvYXRoNWtfcWN1LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9h
dGg1a19waHkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX3BjdS5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfaW5pdHZhbHMuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX2dwaW8uYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aDVrL2F0aDVrX2VlcHJvbS5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9hdGgvYXRoNWsvYXRoNWtfZG1hLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1
ay9hdGg1a19kZXNjLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1a19j
YXBzLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2F0aC9hdGg1ay9hdGg1ay5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9hdGgvYXRoNWsvYXRoNWtfYXR0YWNoLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2F0aC9hdGhfcmVnZC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9hdGgvYXRoX21h
aW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvYXRoL2F0aF9rZXkuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvYXRoL2F0aF9ody5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9ydGw4MTh4L3J0
bDgxOHguYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTg1X3J0bDgyMjUu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9ydGw4MTg1LmMNCiAgW0RFUFNdIGRy
aXZlcnMvbmV0L3J0bDgxOHgvcnRsODE4MF9zYTI0MDAuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvcnRsODE4eC9ydGw4MTgwX21heDI4MjAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRs
ODE4eC9ydGw4MTgwX2dyZjUxMDEuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcnRsODE4eC9y
dGw4MTgwLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3BoYW50b20vcGhhbnRvbS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9pZ2J2Zi9pZ2J2Zl92Zi5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9pZ2J2Zi9pZ2J2Zl9tYnguYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdidmYvaWdidmZf
bWFpbi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX3BoeS5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9pZ2IvaWdiX252bS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdi
X21hbmFnZS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9pZ2IvaWdiX21haW4uYw0KICBbREVQ
U10gZHJpdmVycy9uZXQvaWdiL2lnYl9tYWMuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdi
L2lnYl9hcGkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvaWdiL2lnYl84MjU3NS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9lMTAwMGUvZTEwMDBlX3BoeS5jDQogIFtERVBTXSBkcml2ZXJz
L25ldC9lMTAwMGUvZTEwMDBlX252bS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMGUv
ZTEwMDBlX21haW4uYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZV9tYWMu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDBlL2UxMDAwZV9pY2g4bGFuLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2UxMDAwZS9lMTAwMGVfODI1NzEuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvZTEwMDBlL2UxMDAwZV84MDAwM2VzMmxhbi5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9lMTAwMC9lMTAwMF9waHkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBf
bnZtLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2UxMDAwL2UxMDAwX21haW4uYw0KICBbREVQ
U10gZHJpdmVycy9uZXQvZTEwMDAvZTEwMDBfbWFjLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L2UxMDAwL2UxMDAwX2FwaS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84
MjU0My5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84MjU0Mi5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9lMTAwMC9lMTAwMF84MjU0MS5jDQogIFtERVBTXSBkcml2ZXJz
L25ldC9lMTAwMC9lMTAwMF84MjU0MC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC93ODljODQw
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3ZpcnRpby1uZXQuYw0KICBbREVQU10gZHJpdmVy
cy9uZXQvdmlhLXZlbG9jaXR5LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3ZpYS1yaGluZS5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC90dWxpcC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC90
bGFuLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3RnMy5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9zdW5kYW5jZS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9zbWM5MDAwLmMNCiAgW0RFUFNd
IGRyaXZlcnMvbmV0L3NreTIuYw0KICBbREVQU10gZHJpdmVycy9uZXQvc2tnZS5jDQogIFtE
RVBTXSBkcml2ZXJzL25ldC9zaXM5MDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvc2lzMTkw
LmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3J0bDgxMzkuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvcjgxNjkuYw0KICBbREVQU10gZHJpdmVycy9uZXQvcHJpc20yX3BseC5jDQogIFtERVBT
XSBkcml2ZXJzL25ldC9wcmlzbTJfcGNpLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L3BuaWMu
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvcGNuZXQzMi5jDQogIFtERVBTXSBkcml2ZXJzL25l
dC9uczgzOTAuYw0KICBbREVQU10gZHJpdmVycy9uZXQvbnM4MzgyMC5jDQogIFtERVBTXSBk
cml2ZXJzL25ldC9uZTJrX2lzYS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9uYXRzZW1pLmMN
CiAgW0RFUFNdIGRyaXZlcnMvbmV0L215cmkxMGdlLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0
L210ZDgweC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9sZWdhY3kuYw0KICBbREVQU10gZHJp
dmVycy9uZXQvam1lLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2lwb2liLmMNCiAgW0RFUFNd
IGRyaXZlcnMvbmV0L2ZvcmNlZGV0aC5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9ldGhlcmZh
YnJpYy5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9lcGljMTAwLmMNCiAgW0RFUFNdIGRyaXZl
cnMvbmV0L2VlcHJvLmMNCiAgW0RFUFNdIGRyaXZlcnMvbmV0L2VlcHJvMTAwLmMNCiAgW0RF
UFNdIGRyaXZlcnMvbmV0L2RtZmUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvZGF2aWNvbS5j
DQogIFtERVBTXSBkcml2ZXJzL25ldC9jczg5eDAuYw0KICBbREVQU10gZHJpdmVycy9uZXQv
Ym54Mi5jDQogIFtERVBTXSBkcml2ZXJzL25ldC9iNDQuYw0KICBbREVQU10gZHJpdmVycy9u
ZXQvYXRsMWUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvYW1kODExMWUuYw0KICBbREVQU10g
ZHJpdmVycy9uZXQvM2M5MHguYw0KICBbREVQU10gZHJpdmVycy9uZXQvM2M1eDkuYw0KICBb
REVQU10gZHJpdmVycy9uZXQvM2M1OTUuYw0KICBbREVQU10gZHJpdmVycy9uZXQvM2M1Mjku
Yw0KICBbREVQU10gZHJpdmVycy9uZXQvM2M1MTUuYw0KICBbREVQU10gZHJpdmVycy9uZXQv
M2M1MDktZWlzYS5jDQogIFtERVBTXSBkcml2ZXJzL25ldC8zYzUwOS5jDQogIFtERVBTXSBk
cml2ZXJzL2J1cy92aXJ0aW8tcmluZy5jDQogIFtERVBTXSBkcml2ZXJzL2J1cy92aXJ0aW8t
cGNpLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL3BjaXZwZC5jDQogIFtERVBTXSBkcml2ZXJz
L2J1cy9wY2lleHRyYS5jDQogIFtERVBTXSBkcml2ZXJzL2J1cy9wY2kuYw0KICBbREVQU10g
ZHJpdmVycy9idXMvcGNpYmFja3VwLmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL21jYS5jDQog
IFtERVBTXSBkcml2ZXJzL2J1cy9pc2FwbnAuYw0KICBbREVQU10gZHJpdmVycy9idXMvaXNh
LmMNCiAgW0RFUFNdIGRyaXZlcnMvYnVzL2Vpc2EuYw0KICBbREVQU10gaW1hZ2Uvc2VnbWVu
dC5jDQogIFtERVBTXSBpbWFnZS9zY3JpcHQuYw0KICBbREVQU10gaW1hZ2UvZW1iZWRkZWQu
Yw0KICBbREVQU10gaW1hZ2UvZWxmLmMNCiAgW0RFUFNdIGltYWdlL2VmaV9pbWFnZS5jDQog
IFtERVBTXSBuZXQvODAyMTEvbmV0ODAyMTEuYw0KICBbREVQU10gbmV0L2luZmluaWJhbmQv
aWJfc3JwLmMNCiAgW0RFUFNdIG5ldC9pbmZpbmliYW5kL2liX3NtYy5jDQogIFtERVBTXSBu
ZXQvaW5maW5pYmFuZC9pYl9zbWEuYw0KICBbREVQU10gbmV0L2luZmluaWJhbmQvaWJfbWku
Yw0KICBbREVQU10gbmV0L3VkcC90ZnRwLmMNCiAgW0RFUFNdIG5ldC91ZHAvc3lzbG9nLmMN
CiAgW0RFUFNdIG5ldC91ZHAvc2xhbS5jDQogIFtERVBTXSBuZXQvdWRwL2Rucy5jDQogIFtE
RVBTXSBuZXQvdWRwL2RoY3AuYw0KICBbREVQU10gbmV0L3RjcC9pc2NzaS5jDQogIFtERVBT
XSBuZXQvdGNwL2h0dHBzLmMNCiAgW0RFUFNdIG5ldC90Y3AvaHR0cC5jDQogIFtERVBTXSBu
ZXQvdGNwL2Z0cC5jDQogIFtERVBTXSBuZXQvdmxhbi5jDQogIFtERVBTXSBuZXQvdGNwLmMN
CiAgW0RFUFNdIG5ldC9yZXRyeS5jDQogIFtERVBTXSBuZXQvbmV0ZGV2X3NldHRpbmdzLmMN
CiAgW0RFUFNdIG5ldC9uZXRkZXZpY2UuYw0KICBbREVQU10gbmV0L2lwdjQuYw0KICBbREVQ
U10gbmV0L2luZmluaWJhbmQuYw0KICBbREVQU10gbmV0L2ZjcC5jDQogIFtERVBTXSBuZXQv
ZmNvZS5jDQogIFtERVBTXSBuZXQvZmMuYw0KICBbREVQU10gbmV0L2Zha2VkaGNwLmMNCiAg
W0RFUFNdIG5ldC9kaGNwcGt0LmMNCiAgW0RFUFNdIG5ldC9kaGNwb3B0cy5jDQogIFtERVBT
XSBuZXQvY2FjaGVkaGNwLmMNCiAgW0RFUFNdIG5ldC9hb2UuYw0KICBbREVQU10gY29yZS90
aW1lci5jDQogIFtERVBTXSBjb3JlL3NldHRpbmdzLmMNCiAgW0RFUFNdIGNvcmUvc2VyaWFs
LmMNCiAgW0RFUFNdIGNvcmUvcmFuZG9tLmMNCiAgW0RFUFNdIGNvcmUvcG9zaXhfaW8uYw0K
ICBbREVQU10gY29yZS9wY19rYmQuYw0KICBbREVQU10gY29yZS9wYXJzZW9wdC5jDQogIFtE
RVBTXSBjb3JlL252by5jDQogIFtERVBTXSBjb3JlL251bGxfc2FuYm9vdC5jDQogIFtERVBT
XSBjb3JlL251bGxfbmFwLmMNCiAgW0RFUFNdIGNvcmUvbW9ub2pvYi5jDQogIFtERVBTXSBj
b3JlL21pc2MuYw0KICBbREVQU10gY29yZS9tYWxsb2MuYw0KICBbREVQU10gY29yZS9tYWlu
LmMNCiAgW0RFUFNdIGNvcmUvaW1hZ2UuYw0KICBbREVQU10gY29yZS9nZXRrZXkuYw0KICBb
REVQU10gY29yZS9nZGJ1ZHAuYw0KICBbREVQU10gY29yZS9mbnJlYy5jDQogIFtERVBTXSBj
b3JlL2V4ZWMuYw0KICBbREVQU10gY29yZS9kb3dubG9hZGVyLmMNCiAgW0RFUFNdIGNvcmUv
ZGVidWcuYw0KICBbREVQU10gY29yZS9jb25zb2xlLmMNCiAgW0RFUFNdIGNvcmUvYmxvY2tk
ZXYuYw0KbWFrZVs3XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0
YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvaXB4ZS9zcmMnDQptYWtlWzddOiBF
bnRlcmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9m
aXJtd2FyZS9ldGhlcmJvb3QvaXB4ZS9zcmMnDQogIFtCVUlMRF0gYmluL19fZGl2ZGkzLm8N
CiAgW0JVSUxEXSBiaW4vaWNjLm8NCiAgW0JVSUxEXSBiaW4vbWVtY3B5Lm8NCiAgW0JVSUxE
XSBiaW4vX19tb2RkaTMubw0KICBbQlVJTERdIGJpbi9fX3VkaXZkaTMubw0KICBbQlVJTERd
IGJpbi9fX3VkaXZtb2RkaTQubw0KICBbQlVJTERdIGJpbi9fX3Vtb2RkaTMubw0KICBbQlVJ
TERdIGJpbi9hY3BpLm8NCiAgW0JVSUxEXSBiaW4vYW5zaWVzYy5vDQogIFtCVUlMRF0gYmlu
L2FzcHJpbnRmLm8NCiAgW0JVSUxEXSBiaW4vYXNzZXJ0Lm8NCiAgW0JVSUxEXSBiaW4vYmFz
ZTE2Lm8NCiAgW0JVSUxEXSBiaW4vYmFzZTY0Lm8NCiAgW0JVSUxEXSBiaW4vYmFzZW5hbWUu
bw0KICBbQlVJTERdIGJpbi9iaXRtYXAubw0KICBbQlVJTERdIGJpbi9iaXRvcHMubw0KICBb
QlVJTERdIGJpbi9ibG9ja2Rldi5vDQogIFtCVUlMRF0gYmluL2J0ZXh0Lm8NCiAgW0JVSUxE
XSBiaW4vY29uc29sZS5vDQogIFtCVUlMRF0gYmluL2NwaW8ubw0KICBbQlVJTERdIGJpbi9j
dHlwZS5vDQogIFtCVUlMRF0gYmluL2N3dXJpLm8NCiAgW0JVSUxEXSBiaW4vZGVidWcubw0K
ICBbQlVJTERdIGJpbi9kZWJ1Z19tZDUubw0KICBbQlVJTERdIGJpbi9kZXZpY2Uubw0KICBb
QlVJTERdIGJpbi9kb3dubG9hZGVyLm8NCiAgW0JVSUxEXSBiaW4vZWRkLm8NCiAgW0JVSUxE
XSBiaW4vZXJybm8ubw0KICBbQlVJTERdIGJpbi9leGVjLm8NCiAgW0JVSUxEXSBiaW4vZm5y
ZWMubw0KICBbQlVJTERdIGJpbi9nZGJzZXJpYWwubw0KICBbQlVJTERdIGJpbi9nZGJzdHVi
Lm8NCiAgW0JVSUxEXSBiaW4vZ2RidWRwLm8NCiAgW0JVSUxEXSBiaW4vZ2V0a2V5Lm8NCiAg
W0JVSUxEXSBiaW4vZ2V0b3B0Lm8NCiAgW0JVSUxEXSBiaW4vaHcubw0KICBbQlVJTERdIGJp
bi9pODIzNjUubw0KICBbQlVJTERdIGJpbi9pbWFnZS5vDQogIFtCVUlMRF0gYmluL2luaXQu
bw0KICBbQlVJTERdIGJpbi9pbnRlcmZhY2Uubw0KICBbQlVJTERdIGJpbi9pb2J1Zi5vDQog
IFtCVUlMRF0gYmluL2pvYi5vDQogIFtCVUlMRF0gYmluL2xpbmVidWYubw0KICBbQlVJTERd
IGJpbi9tYWluLm8NCiAgW0JVSUxEXSBiaW4vbWFsbG9jLm8NCiAgW0JVSUxEXSBiaW4vbWlz
Yy5vDQogIFtCVUlMRF0gYmluL21vbm9qb2Iubw0KICBbQlVJTERdIGJpbi9udWxsX25hcC5v
DQogIFtCVUlMRF0gYmluL251bGxfc2FuYm9vdC5vDQogIFtCVUlMRF0gYmluL252by5vDQog
IFtCVUlMRF0gYmluL29wZW4ubw0KICBbQlVJTERdIGJpbi9wYXJzZW9wdC5vDQogIFtCVUlM
RF0gYmluL3BjX2tiZC5vDQogIFtCVUlMRF0gYmluL3BjbWNpYS5vDQogIFtCVUlMRF0gYmlu
L3Bvc2l4X2lvLm8NCiAgW0JVSUxEXSBiaW4vcHJvY2Vzcy5vDQogIFtCVUlMRF0gYmluL3Jh
bmRvbS5vDQogIFtCVUlMRF0gYmluL3JlZmNudC5vDQogIFtCVUlMRF0gYmluL3Jlc29sdi5v
DQogIFtCVUlMRF0gYmluL3NlcmlhbC5vDQogIFtCVUlMRF0gYmluL3NlcmlhbF9jb25zb2xl
Lm8NCiAgW0JVSUxEXSBiaW4vc2V0dGluZ3Mubw0KICBbQlVJTERdIGJpbi9zdHJpbmcubw0K
ICBbQlVJTERdIGJpbi9zdHJpbmdleHRyYS5vDQogIFtCVUlMRF0gYmluL3N0cnRvdWxsLm8N
CiAgW0JVSUxEXSBiaW4vdGltZXIubw0KICBbQlVJTERdIGJpbi91cmkubw0KICBbQlVJTERd
IGJpbi91dWlkLm8NCiAgW0JVSUxEXSBiaW4vdnNwcmludGYubw0KICBbQlVJTERdIGJpbi94
ZmVyLm8NCiAgW0JVSUxEXSBiaW4vYW9lLm8NCiAgW0JVSUxEXSBiaW4vYXJwLm8NCiAgW0JV
SUxEXSBiaW4vY2FjaGVkaGNwLm8NCiAgW0JVSUxEXSBiaW4vZGhjcG9wdHMubw0KICBbQlVJ
TERdIGJpbi9kaGNwcGt0Lm8NCiAgW0JVSUxEXSBiaW4vZWFwb2wubw0KICBbQlVJTERdIGJp
bi9ldGhlcm5ldC5vDQogIFtCVUlMRF0gYmluL2V0aF9zbG93Lm8NCiAgW0JVSUxEXSBiaW4v
ZmFrZWRoY3Aubw0KICBbQlVJTERdIGJpbi9mYy5vDQogIFtCVUlMRF0gYmluL2ZjZWxzLm8N
CiAgW0JVSUxEXSBiaW4vZmNucy5vDQogIFtCVUlMRF0gYmluL2Zjb2Uubw0KICBbQlVJTERd
IGJpbi9mY3Aubw0KICBbQlVJTERdIGJpbi9pY21wLm8NCiAgW0JVSUxEXSBiaW4vaWNtcHY2
Lm8NCiAgW0JVSUxEXSBiaW4vaW5maW5pYmFuZC5vDQogIFtCVUlMRF0gYmluL2lvYnBhZC5v
DQogIFtCVUlMRF0gYmluL2lwdjQubw0KICBbQlVJTERdIGJpbi9pcHY2Lm8NCiAgW0JVSUxE
XSBiaW4vbWlpLm8NCiAgW0JVSUxEXSBiaW4vbmRwLm8NCiAgW0JVSUxEXSBiaW4vbmV0ZGV2
aWNlLm8NCiAgW0JVSUxEXSBiaW4vbmV0ZGV2X3NldHRpbmdzLm8NCiAgW0JVSUxEXSBiaW4v
bnVsbG5ldC5vDQogIFtCVUlMRF0gYmluL3JhcnAubw0KICBbQlVJTERdIGJpbi9yZXRyeS5v
DQogIFtCVUlMRF0gYmluL3RjcC5vDQogIFtCVUlMRF0gYmluL3RjcGlwLm8NCiAgW0JVSUxE
XSBiaW4vdGxzLm8NCiAgW0JVSUxEXSBiaW4vdWRwLm8NCiAgW0JVSUxEXSBiaW4vdmxhbi5v
DQogIFtCVUlMRF0gYmluL2Z0cC5vDQogIFtCVUlMRF0gYmluL2h0dHAubw0KICBbQlVJTERd
IGJpbi9odHRwcy5vDQogIFtCVUlMRF0gYmluL2lzY3NpLm8NCiAgW0JVSUxEXSBiaW4vZGhj
cC5vDQogIFtCVUlMRF0gYmluL2Rucy5vDQogIFtCVUlMRF0gYmluL3NsYW0ubw0KICBbQlVJ
TERdIGJpbi9zeXNsb2cubw0KICBbQlVJTERdIGJpbi90ZnRwLm8NCiAgW0JVSUxEXSBiaW4v
aWJfY20ubw0KICBbQlVJTERdIGJpbi9pYl9jbXJjLm8NCiAgW0JVSUxEXSBiaW4vaWJfbWNh
c3Qubw0KICBbQlVJTERdIGJpbi9pYl9taS5vDQogIFtCVUlMRF0gYmluL2liX3BhY2tldC5v
DQogIFtCVUlMRF0gYmluL2liX3BhdGhyZWMubw0KICBbQlVJTERdIGJpbi9pYl9zbWEubw0K
ICBbQlVJTERdIGJpbi9pYl9zbWMubw0KICBbQlVJTERdIGJpbi9pYl9zcnAubw0KICBbQlVJ
TERdIGJpbi9uZXQ4MDIxMS5vDQogIFtCVUlMRF0gYmluL3JjODAyMTEubw0KICBbQlVJTERd
IGJpbi9zZWM4MDIxMS5vDQogIFtCVUlMRF0gYmluL3dlcC5vDQogIFtCVUlMRF0gYmluL3dw
YS5vDQogIFtCVUlMRF0gYmluL3dwYV9jY21wLm8NCiAgW0JVSUxEXSBiaW4vd3BhX3Bzay5v
DQogIFtCVUlMRF0gYmluL3dwYV90a2lwLm8NCiAgW0JVSUxEXSBiaW4vZWZpX2ltYWdlLm8N
CiAgW0JVSUxEXSBiaW4vZWxmLm8NCiAgW0JVSUxEXSBiaW4vZW1iZWRkZWQubw0KICBbQlVJ
TERdIGJpbi9zY3JpcHQubw0KICBbQlVJTERdIGJpbi9zZWdtZW50Lm8NCiAgW0JVSUxEXSBi
aW4vZWlzYS5vDQogIFtCVUlMRF0gYmluL2lzYS5vDQpkcml2ZXJzL2J1cy9pc2EuYzogSW4g
ZnVuY3Rpb24g4mlzYWJ1c19wcm9iZeI6DQpkcml2ZXJzL2J1cy9pc2EuYzoxMTI6MTg6IGVy
cm9yOiBhcnJheSBzdWJzY3JpcHQgaXMgYWJvdmUgYXJyYXkgYm91bmRzIFstV2Vycm9yPWFy
cmF5LWJvdW5kc10NCmNjMTogYWxsIHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3Jz
DQptYWtlWzddOiAqKiogW2Jpbi9pc2Eub10gRXJyb3IgMQ0KbWFrZVs3XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9l
dGhlcmJvb3QvaXB4ZS9zcmMnDQptYWtlWzZdOiAqKiogW2lweGUvc3JjL2Jpbi9ydGw4MTM5
LnJvbV0gRXJyb3IgMg0KbWFrZVs2XTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QnDQptYWtlWzVdOiAq
KiogW3N1YmRpci1hbGwtZXRoZXJib290XSBFcnJvciAyDQptYWtlWzVdOiBMZWF2aW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0K
bWFrZVs0XTogKioqIFtzdWJkaXJzLWFsbF0gRXJyb3IgMg0KbWFrZVs0XTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZScN
Cm1ha2VbM106ICoqKiBbYWxsXSBFcnJvciAyDQptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9y
eSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2Zpcm13YXJlJw0KbWFrZVsy
XTogKioqIFtzdWJkaXItaW5zdGFsbC1maXJtd2FyZV0gRXJyb3IgMg0KbWFrZVsyXTogTGVh
dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycNCm1h
a2VbMV06ICoqKiBbc3ViZGlycy1pbnN0YWxsXSBFcnJvciAyDQptYWtlWzFdOiBMZWF2aW5n
IGRpcmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJw0KbWFrZTog
KioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyDQpyb290QHZmYXJtOi9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZyMg
--------------030803080800070300000702--

--------------ms060008070700000805000102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA80wggPJAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDYyNzA4NTQwM1owIwYJKoZIhvcNAQkEMRYEFPb8qNgiPCDiRx5L2FYZQrtr
7lT/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYB
BAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5jMIGm
BgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgIeYzANBgkqhkiG9w0BAQEFAASCAQBqp6O+fXpIKwHdX4dk0z1wXx7BktZjsvZSnOtc/kkd
JYl1zyw2FM4bayYb5SdywWXyeMw/JADQy5FKDvq0+372FP9fyOun5071D6Hikd/SQjkmyzCd
XiId3axIaKyQUsI7Xeali/D1bp88nezzgStGwv2YbmPPcNg87SkGovbPe/WvZHMXAsqnPUPd
ZMnacuvAr1jGr0pwZBPFbkzZz98xq+P5DHrJlQYJQ2C7tBur2Al/1hGO0V+ftv7AvsS48Hcr
yFmtl3uAhY6/5sfLbx5j0hKYQqDth4aAd16FVUn3K3Vz0yKP+WbVwpDmoVEAV7B9fDd5YcLZ
WbbpHlKw+K+GAAAAAAAA
--------------ms060008070700000805000102--


--===============7158966147011069039==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7158966147011069039==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 11:21:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1SjqIy-0005VC-M9; Wed, 27 Jun 2012 11:21:04 +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 1SjqIw-0005V3-Mk
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 11:21:02 +0000
Received: from [85.158.139.83:46651] by server-7.bemta-5.messagelabs.com id
	D4/CD-28276-D9CEAEF4; Wed, 27 Jun 2012 11:21:01 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340796061!28471887!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzM1MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5436 invoked from network); 27 Jun 2012 11:21:01 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 11:21:01 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 27F2A15C6;
	Wed, 27 Jun 2012 14:20:59 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D91EFEC027; Wed, 27 Jun 2012 14:20:59 +0300 (EEST)
Date: Wed, 27 Jun 2012 14:20:59 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120627112059.GH2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
	<1340795523.29172.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340795523.29172.31.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Ren,
	Yongjie" <yongjie.ren@intel.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/2] libxl: set stdvga=1 by default when
 creating a hvm 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="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, Jun 27, 2012 at 12:12:03PM +0100, Ian Campbell wrote:
> On Wed, 2012-06-27 at 11:45 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > > To: Ian Campbell
> > > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.or=
g);
> > > > Stefano Stabellini
> > > > Subject: Re: [PATCH 1/2] libxl: set stdvga=3D1 by default when crea=
ting a hvm
> > > > guest
> > > > =

> > > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > > libxl: set stdvga=3D1 by default when creating a hvm guest
> > > > > >
> > > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > > So, select a standard VGA card with VBE as the default emulated
> > > > graphics device.
> > > > >
> > > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > > switching the default to something more modern seems like a
> > > > reasonable
> > > > > idea, although I'm not sure if we should be doing this for 4.2 at=
 this
> > > > > point.
> > > > >
> > > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > > =

> > > > I think it is a good thing.
> > > > The only thing to keep in mind is that QEMU upstream is switching to
> > > > 16MB of videoram for stdvga. So at some point in the near future
> > > > upstream QEMU will stop working correctly with xen 4.2, unless we b=
ump
> > > > the videoram to 16MB too.
> > > > =

> > > Yes, we should pay attention to this when using upstream QEMU.
> > > =

> > =

> > Earlier there was a discussion about upstream QEMU lacking support
> > for being able to specify/configure the amount of videomem.
> =

> I believe you were going to send a patch documenting this? =

> =


Yep, I'll do that..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 11:21:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 11: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 1SjqIy-0005VC-M9; Wed, 27 Jun 2012 11:21:04 +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 1SjqIw-0005V3-Mk
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 11:21:02 +0000
Received: from [85.158.139.83:46651] by server-7.bemta-5.messagelabs.com id
	D4/CD-28276-D9CEAEF4; Wed, 27 Jun 2012 11:21:01 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340796061!28471887!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzM1MTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5436 invoked from network); 27 Jun 2012 11:21:01 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 11:21:01 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 27F2A15C6;
	Wed, 27 Jun 2012 14:20:59 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D91EFEC027; Wed, 27 Jun 2012 14:20:59 +0300 (EEST)
Date: Wed, 27 Jun 2012 14:20:59 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120627112059.GH2058@reaktio.net>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<20120627104555.GF2058@reaktio.net>
	<1340795523.29172.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340795523.29172.31.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Ren,
	Yongjie" <yongjie.ren@intel.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/2] libxl: set stdvga=1 by default when
 creating a hvm 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="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, Jun 27, 2012 at 12:12:03PM +0100, Ian Campbell wrote:
> On Wed, 2012-06-27 at 11:45 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Jun 27, 2012 at 01:45:49AM +0000, Ren, Yongjie wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > > To: Ian Campbell
> > > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.or=
g);
> > > > Stefano Stabellini
> > > > Subject: Re: [PATCH 1/2] libxl: set stdvga=3D1 by default when crea=
ting a hvm
> > > > guest
> > > > =

> > > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > > libxl: set stdvga=3D1 by default when creating a hvm guest
> > > > > >
> > > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > > So, select a standard VGA card with VBE as the default emulated
> > > > graphics device.
> > > > >
> > > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > > switching the default to something more modern seems like a
> > > > reasonable
> > > > > idea, although I'm not sure if we should be doing this for 4.2 at=
 this
> > > > > point.
> > > > >
> > > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > > > =

> > > > I think it is a good thing.
> > > > The only thing to keep in mind is that QEMU upstream is switching to
> > > > 16MB of videoram for stdvga. So at some point in the near future
> > > > upstream QEMU will stop working correctly with xen 4.2, unless we b=
ump
> > > > the videoram to 16MB too.
> > > > =

> > > Yes, we should pay attention to this when using upstream QEMU.
> > > =

> > =

> > Earlier there was a discussion about upstream QEMU lacking support
> > for being able to specify/configure the amount of videomem.
> =

> I believe you were going to send a patch documenting this? =

> =


Yep, I'll do that..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 12:17:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 12:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjrAo-0006yS-G5; Wed, 27 Jun 2012 12:16:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SjrAn-0006yN-7r
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 12:16:41 +0000
Received: from [85.158.143.99:34789] by server-1.bemta-4.messagelabs.com id
	52/26-24392-8A9FAEF4; Wed, 27 Jun 2012 12:16:40 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340799397!29052966!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1622 invoked from network); 27 Jun 2012 12:16:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 12:16:38 -0000
Received: by obbef5 with SMTP id ef5so2058138obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 05:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BcfD1EdMnH32Pbl0e0pd2qci2UN+n5QcX0hZRJMGi9w=;
	b=C444Jlo8/iBosPc7WAK49ZBgq+yPUHKZyQs+O7j8oSgF/CZwjvFFlsyPAqvFKCBppu
	z/pUUgqMS+0KgaLhrT8kaTKkc8Npgzc9UJ44qxDxIXxxdZng1gQuw4l0bgSdX4g7dS3q
	EEvRgU0L/d38p/Vcd8Z21Th/Tea/zfbH5mhru/U2J7sMWDkfWIZAeG1kDdBlguCezp6e
	hQbah18gcidVW68+JZPoBC9Jz9NYZgS9ejqZ3mA8Xx8UgLEDAPP+oSm0y0xSf54M0LJn
	PrTFAR2tjUXuYrcgwlYwsEm+Pjb4ctbDScCIVAQ8d7fFoCOoi9W8VCvPIaQYeKIIxVTA
	psqg==
MIME-Version: 1.0
Received: by 10.182.222.39 with SMTP id qj7mr11622009obc.16.1340799396451;
	Wed, 27 Jun 2012 05:16:36 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 27 Jun 2012 05:16:35 -0700 (PDT)
In-Reply-To: <1340217533.4998.3.camel@dagon.hellion.org.uk>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
Date: Wed, 27 Jun 2012 20:16:35 +0800
Message-ID: <CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=f46d04447383bd94ef04c3732f19
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d04447383bd94ef04c3732f19
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

New version patch.

-----

tools:libxl: refactor stdvga opinon support.

Be ready to add and describe new vga interface

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

diff -r 592d15bd4d5e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Jun 27 20:06:39 2012 +0800
@@ -189,7 +189,8 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }

-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        if (!b_info->u.hvm.vga.kind)
+            b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 592d15bd4d5e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Jun 27 20:06:39 2012 +0800
@@ -175,8 +175,13 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb=
)),
                     NULL);
         }
-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
+
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
             flexarray_append(dm_args, "-std-vga");
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
         }

         if (b_info->u.hvm.boot) {
@@ -418,8 +423,13 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }

-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
-                flexarray_vappend(dm_args, "-vga", "std", NULL);
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
+            flexarray_vappend(dm_args, "-vga", "std", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
         }

         if (b_info->u.hvm.boot) {
diff -r 592d15bd4d5e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Jun 27 20:06:39 2012 +0800
@@ -125,9 +125,19 @@ libxl_shutdown_reason =3D Enumeration("shu
     (4, "watchdog"),
     ])

+libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
+    (1, "CIRRUS"),
+    (2, "STD"),
+    ], init_val =3D 0)
+
 #
 # Complex libxl types
 #
+
+libxl_vga_interface_info =3D Struct("vga_interface_info", [
+    ("kind",    libxl_vga_interface_type),
+    ])
+
 libxl_vnc_info =3D Struct("vnc_info", [
     ("enable",        libxl_defbool),
     # "address:port" that should be listened on
@@ -286,7 +296,7 @@ libxl_domain_build_info =3D Struct("domain
                                        ("nested_hvm",       libxl_defbool)=
,
                                        ("incr_generationid",libxl_defbool)=
,
                                        ("nographic",        libxl_defbool)=
,
-                                       ("stdvga",           libxl_defbool)=
,
+                                       ("vga",
libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info=
),
                                        # keyboard layout, default is
en-us keyboard
                                        ("keymap",           string),
diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jun 27 20:06:39 2012 +0800
@@ -1256,7 +1256,10 @@ skip_vfb:
 #undef parse_extra_args

     if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
-        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+            if (l)
+                b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_STD;
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);
diff -r 592d15bd4d5e tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Wed Jun 27 20:06:39 2012 +0800
@@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-        printf("\t\t\t(stdvga %s)\n",
-               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind =3D=3D
+                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
+                                      "True" : "False");
         printf("\t\t\t(vnc %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);

On Thu, Jun 21, 2012 at 2:38 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> Sorry for the late response, I seem to have lost this reply on my desktop=
 somewhere...
>
> On Thu, 2012-06-07 at 03:34 +0100, ZhouPeng wrote:
>> On Wed, Jun 6, 2012 at 7:47 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>> > On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
>> >> =A0# Complex libxl types
>> >> =A0#
>> >> +
>> >> +libxl_vga_interface_info =3D Struct("vga_interface_info", [
>> >> + =A0 =A0("type", =A0 =A0libxl_vga_interface_type),
>> >> + =A0 =A0])
>> >
>> > Unfortunately "type" is a reserved word in ocaml (and possibly other
>> > languages, which causes the bindings to fail to build:
>> Thanks for your review.
>>
>> I didn't build against ocaml.
>> I 'make install' in tools/libxl directly.
>> > =A0 =A0 =A0 =A0make[4]: Entering directory `/local/scratch/ianc/devel/=
committer.git/tools/ocaml/libs/xl'
>> > =A0 =A0 =A0 =A0 MLDEP
>> > =A0 =A0 =A0 =A0File "xenlight.ml", line 116, characters 2-6:
>> > =A0 =A0 =A0 =A0Error: Syntax error
>> > =A0 =A0 =A0 =A0 MLI =A0 =A0 =A0xenlight.cmi
>> > =A0 =A0 =A0 =A0File "xenlight.mli", line 116, characters 2-6:
>> > =A0 =A0 =A0 =A0Error: Syntax error: 'end' expected
>> > =A0 =A0 =A0 =A0File "xenlight.mli", line 113, characters 28-31:
>> > =A0 =A0 =A0 =A0Error: This 'sig' might be unmatched
>> >
>> > Ideally we'd make the bindings generator do appropriate substitutions =
on
>> > keywords but the usual workaround is to s/type/kind for the field name=
.
>> >
>> > BTW, I wasn't going to bounce the patch over this but could
>>
>> Sorry, I'm not farmiliar with the vocabulary =A0'bounce',
>> do you mean s/type/kind is necessary or not?
>
> Yes, it is necessary.
>
> By "bounce" I meant ask you to resubmit. IOW I wasn't going to ask you
> to resubmit over the LIBXL_VGA_INTERFACE_TYPE_DEFAULT part, but I
> figured since you needed to fix the ocaml stuff I would mention it.
>
>> I think you mean necessary, right?
>> > LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
>> > the type?
>> do you mean this way below?
>> libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
>> =A0 =A0 (-1, "DEFAULT"),
>> =A0 =A0 (0, "CIRRUS"),
>> =A0 =A0 (1, "STD"),
>> =A0 =A0 ], init_val =3D "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
>>
>> In my understanding, LIBXL_VGA_INTERFACE_TYPE_DEFAULT is not really
>> a meaningful vga type (even not present default vga to use, but just tag=
 the
>> variable has never be initialized, so in meaningless state).
>> It's only used to check if libxl_vga_interface_type var is
>> initialized (whether stdvga setted by vm.cfg), to
>> avoid random value initialized.
>
> Actually, looking at the definition of libxl_vga_interface_type you
> should avoid using 0 as a real thing and then this becomes
> =A0 =A0 =A0 =A0libxl_vga_interface_type =3D Enumeration("vga_interface_ty=
pe", [
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(1, "CIRRUS"),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(2, "STD"),
> =A0 =A0 =A0 =A0])
>
> Since the "default default" is 0 you can test for default just by
> using !b_info.... here.
>
> You'll notice that most other enums in the IDL have this property except
> where the specific values come from elsewhere (like timer mode).
>
> Several enums also include "UNKNOWN" as an explicit entry, which is much
> the same as including "DEFAULT" IMHO.
>
>> It's equal with LIBXL_MEMKB_DEFAULT in this context.
>
> This is semantically a bit different to the enum case.
>
>> It's the same with LIBXL_TIMER_MODE_DEFAULT
>
> TIMER_MODE is not a good example to follow because the specific values
> come from the hypervisor and libxl simple matches them.
>
>> > I'm not sure why we don't do the same for
>> > LIBXL_TIMER_MODE_DEFAULT already.
>> >
>> > Ian.
>> >
>> >
>> >> +
>> >> =A0libxl_vnc_info =3D Struct("vnc_info", [
>> >> =A0 =A0 =A0("enable", =A0 =A0 =A0 =A0libxl_defbool),
>> >> =A0 =A0 =A0# "address:port" that should be listened on
>> >> @@ -281,7 +291,7 @@ libxl_domain_build_info =3D Struct("domain
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("nested_hvm", =A0 =A0 =A0 libxl_defbool),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("incr_generationid",libxl_defbool),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("nographic", =A0 =A0 =A0 =A0libxl_defbool),
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 ("stdvga", =A0 =A0 =A0 =A0 =A0 libxl_defbool),
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 ("vga",
>> >> libxl_vga_interface_info),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("vnc", =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_vnc_info),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 # keyboard layout, default is
>> >> en-us keyboard
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("keymap", =A0 =A0 =A0 =A0 =A0 string),
>> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
>> >> --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Sat Jun 02 08:39:45 201=
2 +0100
>> >> +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:39:37 201=
2 +0800
>> >> @@ -1256,7 +1256,10 @@ skip_vfb:
>> >> =A0#undef parse_extra_args
>> >>
>> >> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> >> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm=
.stdvga, 0);
>> >> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA=
_INTERFACE_TYPE_STD;
>> >> +
>> >> =A0 =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.=
vnc.enable, 0);
>> >> =A0 =A0 =A0 =A0 =A0xlu_cfg_replace_string (config, "vnclisten",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&b=
_info->u.hvm.vnc.listen, 0);
>> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
>> >> --- a/tools/libxl/xl_sxp.c =A0 =A0Sat Jun 02 08:39:45 2012 +0100
>> >> +++ b/tools/libxl/xl_sxp.c =A0 =A0Tue Jun 05 17:39:37 2012 +0800
>> >> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm=
.nested_hvm));
>> >> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(no_incr_generationid %s)\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm=
.incr_generationid));
>> >> - =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n",
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.s=
tdvga));
>> >> + =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type=
 =3D=3D
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0LIBXL_VGA_INTERFACE_TYPE_STD ?
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0"True" : "False");
>> >> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnc %s)\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm=
.vnc.enable));
>> >> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc=
.listen);
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>
>
>
>
>
>
>



--=20
Zhou Peng

--f46d04447383bd94ef04c3732f19
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.stdvga.refactor.v3.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.stdvga.refactor.v3.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h3ydbd8n0

dG9vbHM6bGlieGw6IHJlZmFjdG9yIHN0ZHZnYSBvcGlub24gc3VwcG9ydC4KCkJlIHJlYWR5IHRv
IGFkZCBhbmQgZGVzY3JpYmUgbmV3IHZnYSBpbnRlcmZhY2UKClNpZ25lZC1vZmYtYnk6IFpob3Ug
UGVuZyA8YWlsdnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9s
aWJ4bC9saWJ4bF9jcmVhdGUuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlGcmkg
TWF5IDE4IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRl
LmMJV2VkIEp1biAyNyAyMDowNjozOSAyMDEyICswODAwCkBAIC0xODksNyArMTg5LDggQEAgaW50
IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgICAgICAgICAgaWYgKCFi
X2luZm8tPnUuaHZtLmJvb3QpIHJldHVybiBFUlJPUl9OT01FTTsKICAgICAgICAgfQogCi0gICAg
ICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIGZhbHNl
KTsKKyAgICAgICAgaWYgKCFiX2luZm8tPnUuaHZtLnZnYS5raW5kKQorICAgICAgICAgICAgYl9p
bmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM7CiAg
ICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxl
LCB0cnVlKTsKICAgICAgICAgaWYgKGxpYnhsX2RlZmJvb2xfdmFsKGJfaW5mby0+dS5odm0udm5j
LmVuYWJsZSkpIHsKICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZv
LT51Lmh2bS52bmMuZmluZHVudXNlZCwgdHJ1ZSk7CmRpZmYgLXIgNTkyZDE1YmQ0ZDVlIHRvb2xz
L2xpYnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlGcmkgTWF5IDE4
IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlXZWQgSnVu
IDI3IDIwOjA2OjM5IDIwMTIgKzA4MDAKQEAgLTE3NSw4ICsxNzUsMTMgQEAgc3RhdGljIGNoYXIg
KiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBsaWJ4bF9fc2l6ZWtiX3RvX21iKGJfaW5mby0+dmlkZW9fbWVta2IpKSwKICAgICAg
ICAgICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgIH0KLSAgICAgICAgaWYgKGxpYnhsX2RlZmJv
b2xfdmFsKGJfaW5mby0+dS5odm0uc3RkdmdhKSkgeworCisgICAgICAgIHN3aXRjaCAoYl9pbmZv
LT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQ
RV9TVEQ6CiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItc3RkLXZnYSIp
OworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9U
WVBFX0NJUlJVUzoKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYg
KGJfaW5mby0+dS5odm0uYm9vdCkgewpAQCAtNDE4LDggKzQyMywxMyBAQCBzdGF0aWMgY2hhciAq
KiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5k
KGRtX2FyZ3MsIHNwaWNlb3B0aW9ucyk7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAobGlieGxf
ZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKSB7Ci0gICAgICAgICAgICAgICAgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAic3RkIiwgTlVMTCk7CisgICAgICAgIHN3
aXRjaCAoYl9pbmZvLT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9TVEQ6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdz
LCAiLXZnYSIsICJzdGQiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICBjYXNl
IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CisgICAgICAgICAgICBmbGV4YXJyYXlf
dmFwcGVuZChkbV9hcmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJy
ZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0uYm9vdCkgewpkaWZm
IC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfdHlwZXMuaWRsCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysg
Yi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJV2VkIEp1biAyNyAyMDowNjozOSAyMDEyICsw
ODAwCkBAIC0xMjUsOSArMTI1LDE5IEBAIGxpYnhsX3NodXRkb3duX3JlYXNvbiA9IEVudW1lcmF0
aW9uKCJzaHUKICAgICAoNCwgIndhdGNoZG9nIiksCiAgICAgXSkKIAorbGlieGxfdmdhX2ludGVy
ZmFjZV90eXBlID0gRW51bWVyYXRpb24oInZnYV9pbnRlcmZhY2VfdHlwZSIsIFsKKyAgICAoMSwg
IkNJUlJVUyIpLAorICAgICgyLCAiU1REIiksCisgICAgXSwgaW5pdF92YWwgPSAwKQorCiAjCiAj
IENvbXBsZXggbGlieGwgdHlwZXMKICMKKworbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvID0gU3Ry
dWN0KCJ2Z2FfaW50ZXJmYWNlX2luZm8iLCBbCisgICAgKCJraW5kIiwgICAgbGlieGxfdmdhX2lu
dGVyZmFjZV90eXBlKSwKKyAgICBdKQorCiBsaWJ4bF92bmNfaW5mbyA9IFN0cnVjdCgidm5jX2lu
Zm8iLCBbCiAgICAgKCJlbmFibGUiLCAgICAgICAgbGlieGxfZGVmYm9vbCksCiAgICAgIyAiYWRk
cmVzczpwb3J0IiB0aGF0IHNob3VsZCBiZSBsaXN0ZW5lZCBvbgpAQCAtMjg2LDcgKzI5Niw3IEBA
IGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvID0gU3RydWN0KCJkb21haW4KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICgibmVzdGVkX2h2bSIsICAgICAgIGxpYnhsX2RlZmJv
b2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJpbmNyX2dlbmVy
YXRpb25pZCIsbGlieGxfZGVmYm9vbCksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAoIm5vZ3JhcGhpYyIsICAgICAgICBsaWJ4bF9kZWZib29sKSwKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICgic3RkdmdhIiwgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2wpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJ2Z2EiLCAg
ICAgICAgICAgICAgbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvKSwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgidm5jIiwgICAgICAgICAgICAgIGxpYnhsX3ZuY19pbmZv
KSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMga2V5Ym9hcmQgbGF5
b3V0LCBkZWZhdWx0IGlzIGVuLXVzIGtleWJvYXJkCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoImtleW1hcCIsICAgICAgICAgICBzdHJpbmcpLApkaWZmIC1yIDU5MmQx
NWJkNGQ1ZSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxfY21k
aW1wbC5jCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC94
bF9jbWRpbXBsLmMJV2VkIEp1biAyNyAyMDowNjozOSAyMDEyICswODAwCkBAIC0xMjU2LDcgKzEy
NTYsMTAgQEAgc2tpcF92ZmI6CiAjdW5kZWYgcGFyc2VfZXh0cmFfYXJncwogCiAgICAgaWYgKGNf
aW5mby0+dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pIHsKLSAgICAgICAgeGx1X2NmZ19n
ZXRfZGVmYm9vbChjb25maWcsICJzdGR2Z2EiLCAmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIDApOwor
ICAgICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcoY29uZmlnLCAic3RkdmdhIiwgJmwsIDApKQor
ICAgICAgICAgICAgaWYgKGwpCisgICAgICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2Eua2lu
ZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9TVEQ7CisKICAgICAgICAgeGx1X2NmZ19nZXRf
ZGVmYm9vbChjb25maWcsICJ2bmMiLCAmYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxlLCAwKTsKICAg
ICAgICAgeGx1X2NmZ19yZXBsYWNlX3N0cmluZyAoY29uZmlnLCAidm5jbGlzdGVuIiwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmJfaW5mby0+dS5odm0udm5jLmxpc3RlbiwgMCk7
CmRpZmYgLXIgNTkyZDE1YmQ0ZDVlIHRvb2xzL2xpYnhsL3hsX3N4cC5jCi0tLSBhL3Rvb2xzL2xp
YnhsL3hsX3N4cC5jCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysgYi90b29scy9s
aWJ4bC94bF9zeHAuYwlXZWQgSnVuIDI3IDIwOjA2OjM5IDIwMTIgKzA4MDAKQEAgLTExMCw4ICsx
MTAsOSBAQCB2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRvbWlkLCBsaWJ4bF9kCiAgICAgICAg
ICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLm5lc3RlZF9odm0p
KTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQobm9faW5jcl9nZW5lcmF0aW9uaWQgJXMpXG4iLAog
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5pbmNy
X2dlbmVyYXRpb25pZCkpOwotICAgICAgICBwcmludGYoIlx0XHRcdChzdGR2Z2EgJXMpXG4iLAot
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5zdGR2
Z2EpKTsKKyAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3RkdmdhICVzKVxuIiwgYl9pbmZvLT51Lmh2
bS52Z2Eua2luZCA9PQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMSUJY
TF9WR0FfSU5URVJGQUNFX1RZUEVfU1REID8KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIlRydWUiIDogIkZhbHNlIik7CiAgICAgICAgIHByaW50ZigiXHRcdFx0KHZuYyAl
cylcbiIsCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUu
aHZtLnZuYy5lbmFibGUpKTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jbGlzdGVuICVzKVxu
IiwgYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuKTsK
--f46d04447383bd94ef04c3732f19
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d04447383bd94ef04c3732f19--


From xen-devel-bounces@lists.xen.org Wed Jun 27 12:17:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 12:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjrAo-0006yS-G5; Wed, 27 Jun 2012 12:16:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1SjrAn-0006yN-7r
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 12:16:41 +0000
Received: from [85.158.143.99:34789] by server-1.bemta-4.messagelabs.com id
	52/26-24392-8A9FAEF4; Wed, 27 Jun 2012 12:16:40 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340799397!29052966!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1622 invoked from network); 27 Jun 2012 12:16:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 12:16:38 -0000
Received: by obbef5 with SMTP id ef5so2058138obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 05:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BcfD1EdMnH32Pbl0e0pd2qci2UN+n5QcX0hZRJMGi9w=;
	b=C444Jlo8/iBosPc7WAK49ZBgq+yPUHKZyQs+O7j8oSgF/CZwjvFFlsyPAqvFKCBppu
	z/pUUgqMS+0KgaLhrT8kaTKkc8Npgzc9UJ44qxDxIXxxdZng1gQuw4l0bgSdX4g7dS3q
	EEvRgU0L/d38p/Vcd8Z21Th/Tea/zfbH5mhru/U2J7sMWDkfWIZAeG1kDdBlguCezp6e
	hQbah18gcidVW68+JZPoBC9Jz9NYZgS9ejqZ3mA8Xx8UgLEDAPP+oSm0y0xSf54M0LJn
	PrTFAR2tjUXuYrcgwlYwsEm+Pjb4ctbDScCIVAQ8d7fFoCOoi9W8VCvPIaQYeKIIxVTA
	psqg==
MIME-Version: 1.0
Received: by 10.182.222.39 with SMTP id qj7mr11622009obc.16.1340799396451;
	Wed, 27 Jun 2012 05:16:36 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 27 Jun 2012 05:16:35 -0700 (PDT)
In-Reply-To: <1340217533.4998.3.camel@dagon.hellion.org.uk>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
Date: Wed, 27 Jun 2012 20:16:35 +0800
Message-ID: <CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=f46d04447383bd94ef04c3732f19
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d04447383bd94ef04c3732f19
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

New version patch.

-----

tools:libxl: refactor stdvga opinon support.

Be ready to add and describe new vga interface

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

diff -r 592d15bd4d5e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Jun 27 20:06:39 2012 +0800
@@ -189,7 +189,8 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }

-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        if (!b_info->u.hvm.vga.kind)
+            b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 592d15bd4d5e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Jun 27 20:06:39 2012 +0800
@@ -175,8 +175,13 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb=
)),
                     NULL);
         }
-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
+
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
             flexarray_append(dm_args, "-std-vga");
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
         }

         if (b_info->u.hvm.boot) {
@@ -418,8 +423,13 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }

-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
-                flexarray_vappend(dm_args, "-vga", "std", NULL);
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
+            flexarray_vappend(dm_args, "-vga", "std", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
         }

         if (b_info->u.hvm.boot) {
diff -r 592d15bd4d5e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Jun 27 20:06:39 2012 +0800
@@ -125,9 +125,19 @@ libxl_shutdown_reason =3D Enumeration("shu
     (4, "watchdog"),
     ])

+libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
+    (1, "CIRRUS"),
+    (2, "STD"),
+    ], init_val =3D 0)
+
 #
 # Complex libxl types
 #
+
+libxl_vga_interface_info =3D Struct("vga_interface_info", [
+    ("kind",    libxl_vga_interface_type),
+    ])
+
 libxl_vnc_info =3D Struct("vnc_info", [
     ("enable",        libxl_defbool),
     # "address:port" that should be listened on
@@ -286,7 +296,7 @@ libxl_domain_build_info =3D Struct("domain
                                        ("nested_hvm",       libxl_defbool)=
,
                                        ("incr_generationid",libxl_defbool)=
,
                                        ("nographic",        libxl_defbool)=
,
-                                       ("stdvga",           libxl_defbool)=
,
+                                       ("vga",
libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info=
),
                                        # keyboard layout, default is
en-us keyboard
                                        ("keymap",           string),
diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jun 27 20:06:39 2012 +0800
@@ -1256,7 +1256,10 @@ skip_vfb:
 #undef parse_extra_args

     if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
-        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+            if (l)
+                b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_STD;
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);
diff -r 592d15bd4d5e tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Wed Jun 27 20:06:39 2012 +0800
@@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-        printf("\t\t\t(stdvga %s)\n",
-               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind =3D=3D
+                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
+                                      "True" : "False");
         printf("\t\t\t(vnc %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);

On Thu, Jun 21, 2012 at 2:38 AM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> Sorry for the late response, I seem to have lost this reply on my desktop=
 somewhere...
>
> On Thu, 2012-06-07 at 03:34 +0100, ZhouPeng wrote:
>> On Wed, Jun 6, 2012 at 7:47 PM, Ian Campbell <Ian.Campbell@citrix.com> w=
rote:
>> > On Tue, 2012-06-05 at 12:19 +0100, ZhouPeng wrote:
>> >> =A0# Complex libxl types
>> >> =A0#
>> >> +
>> >> +libxl_vga_interface_info =3D Struct("vga_interface_info", [
>> >> + =A0 =A0("type", =A0 =A0libxl_vga_interface_type),
>> >> + =A0 =A0])
>> >
>> > Unfortunately "type" is a reserved word in ocaml (and possibly other
>> > languages, which causes the bindings to fail to build:
>> Thanks for your review.
>>
>> I didn't build against ocaml.
>> I 'make install' in tools/libxl directly.
>> > =A0 =A0 =A0 =A0make[4]: Entering directory `/local/scratch/ianc/devel/=
committer.git/tools/ocaml/libs/xl'
>> > =A0 =A0 =A0 =A0 MLDEP
>> > =A0 =A0 =A0 =A0File "xenlight.ml", line 116, characters 2-6:
>> > =A0 =A0 =A0 =A0Error: Syntax error
>> > =A0 =A0 =A0 =A0 MLI =A0 =A0 =A0xenlight.cmi
>> > =A0 =A0 =A0 =A0File "xenlight.mli", line 116, characters 2-6:
>> > =A0 =A0 =A0 =A0Error: Syntax error: 'end' expected
>> > =A0 =A0 =A0 =A0File "xenlight.mli", line 113, characters 28-31:
>> > =A0 =A0 =A0 =A0Error: This 'sig' might be unmatched
>> >
>> > Ideally we'd make the bindings generator do appropriate substitutions =
on
>> > keywords but the usual workaround is to s/type/kind for the field name=
.
>> >
>> > BTW, I wasn't going to bounce the patch over this but could
>>
>> Sorry, I'm not farmiliar with the vocabulary =A0'bounce',
>> do you mean s/type/kind is necessary or not?
>
> Yes, it is necessary.
>
> By "bounce" I meant ask you to resubmit. IOW I wasn't going to ask you
> to resubmit over the LIBXL_VGA_INTERFACE_TYPE_DEFAULT part, but I
> figured since you needed to fix the ocaml stuff I would mention it.
>
>> I think you mean necessary, right?
>> > LIBXL_VGA_INTERFACE_TYPE_DEFAULT not be part of the IDL definition of
>> > the type?
>> do you mean this way below?
>> libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
>> =A0 =A0 (-1, "DEFAULT"),
>> =A0 =A0 (0, "CIRRUS"),
>> =A0 =A0 (1, "STD"),
>> =A0 =A0 ], init_val =3D "LIBXL_VGA_INTERFACE_TYPE_DEFAULT")
>>
>> In my understanding, LIBXL_VGA_INTERFACE_TYPE_DEFAULT is not really
>> a meaningful vga type (even not present default vga to use, but just tag=
 the
>> variable has never be initialized, so in meaningless state).
>> It's only used to check if libxl_vga_interface_type var is
>> initialized (whether stdvga setted by vm.cfg), to
>> avoid random value initialized.
>
> Actually, looking at the definition of libxl_vga_interface_type you
> should avoid using 0 as a real thing and then this becomes
> =A0 =A0 =A0 =A0libxl_vga_interface_type =3D Enumeration("vga_interface_ty=
pe", [
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(1, "CIRRUS"),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(2, "STD"),
> =A0 =A0 =A0 =A0])
>
> Since the "default default" is 0 you can test for default just by
> using !b_info.... here.
>
> You'll notice that most other enums in the IDL have this property except
> where the specific values come from elsewhere (like timer mode).
>
> Several enums also include "UNKNOWN" as an explicit entry, which is much
> the same as including "DEFAULT" IMHO.
>
>> It's equal with LIBXL_MEMKB_DEFAULT in this context.
>
> This is semantically a bit different to the enum case.
>
>> It's the same with LIBXL_TIMER_MODE_DEFAULT
>
> TIMER_MODE is not a good example to follow because the specific values
> come from the hypervisor and libxl simple matches them.
>
>> > I'm not sure why we don't do the same for
>> > LIBXL_TIMER_MODE_DEFAULT already.
>> >
>> > Ian.
>> >
>> >
>> >> +
>> >> =A0libxl_vnc_info =3D Struct("vnc_info", [
>> >> =A0 =A0 =A0("enable", =A0 =A0 =A0 =A0libxl_defbool),
>> >> =A0 =A0 =A0# "address:port" that should be listened on
>> >> @@ -281,7 +291,7 @@ libxl_domain_build_info =3D Struct("domain
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("nested_hvm", =A0 =A0 =A0 libxl_defbool),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("incr_generationid",libxl_defbool),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("nographic", =A0 =A0 =A0 =A0libxl_defbool),
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 ("stdvga", =A0 =A0 =A0 =A0 =A0 libxl_defbool),
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 ("vga",
>> >> libxl_vga_interface_info),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("vnc", =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_vnc_info),
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 # keyboard layout, default is
>> >> en-us keyboard
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ("keymap", =A0 =A0 =A0 =A0 =A0 string),
>> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_cmdimpl.c
>> >> --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Sat Jun 02 08:39:45 201=
2 +0100
>> >> +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Tue Jun 05 17:39:37 201=
2 +0800
>> >> @@ -1256,7 +1256,10 @@ skip_vfb:
>> >> =A0#undef parse_extra_args
>> >>
>> >> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> >> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm=
.stdvga, 0);
>> >> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.type =3D LIBXL_VGA=
_INTERFACE_TYPE_STD;
>> >> +
>> >> =A0 =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.=
vnc.enable, 0);
>> >> =A0 =A0 =A0 =A0 =A0xlu_cfg_replace_string (config, "vnclisten",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&b=
_info->u.hvm.vnc.listen, 0);
>> >> diff -r 6bea63e6c780 -r 7bd08f83a2ce tools/libxl/xl_sxp.c
>> >> --- a/tools/libxl/xl_sxp.c =A0 =A0Sat Jun 02 08:39:45 2012 +0100
>> >> +++ b/tools/libxl/xl_sxp.c =A0 =A0Tue Jun 05 17:39:37 2012 +0800
>> >> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm=
.nested_hvm));
>> >> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(no_incr_generationid %s)\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm=
.incr_generationid));
>> >> - =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n",
>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm.s=
tdvga));
>> >> + =A0 =A0 =A0 =A0printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.type=
 =3D=3D
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0LIBXL_VGA_INTERFACE_TYPE_STD ?
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0"True" : "False");
>> >> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnc %s)\n",
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_defbool_to_string(b_info->u.hvm=
.vnc.enable));
>> >> =A0 =A0 =A0 =A0 =A0printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc=
.listen);
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>
>
>
>
>
>
>



--=20
Zhou Peng

--f46d04447383bd94ef04c3732f19
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.stdvga.refactor.v3.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.stdvga.refactor.v3.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h3ydbd8n0

dG9vbHM6bGlieGw6IHJlZmFjdG9yIHN0ZHZnYSBvcGlub24gc3VwcG9ydC4KCkJlIHJlYWR5IHRv
IGFkZCBhbmQgZGVzY3JpYmUgbmV3IHZnYSBpbnRlcmZhY2UKClNpZ25lZC1vZmYtYnk6IFpob3Ug
UGVuZyA8YWlsdnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9s
aWJ4bC9saWJ4bF9jcmVhdGUuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlGcmkg
TWF5IDE4IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRl
LmMJV2VkIEp1biAyNyAyMDowNjozOSAyMDEyICswODAwCkBAIC0xODksNyArMTg5LDggQEAgaW50
IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgICAgICAgICAgaWYgKCFi
X2luZm8tPnUuaHZtLmJvb3QpIHJldHVybiBFUlJPUl9OT01FTTsKICAgICAgICAgfQogCi0gICAg
ICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIGZhbHNl
KTsKKyAgICAgICAgaWYgKCFiX2luZm8tPnUuaHZtLnZnYS5raW5kKQorICAgICAgICAgICAgYl9p
bmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM7CiAg
ICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxl
LCB0cnVlKTsKICAgICAgICAgaWYgKGxpYnhsX2RlZmJvb2xfdmFsKGJfaW5mby0+dS5odm0udm5j
LmVuYWJsZSkpIHsKICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZv
LT51Lmh2bS52bmMuZmluZHVudXNlZCwgdHJ1ZSk7CmRpZmYgLXIgNTkyZDE1YmQ0ZDVlIHRvb2xz
L2xpYnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlGcmkgTWF5IDE4
IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlXZWQgSnVu
IDI3IDIwOjA2OjM5IDIwMTIgKzA4MDAKQEAgLTE3NSw4ICsxNzUsMTMgQEAgc3RhdGljIGNoYXIg
KiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBsaWJ4bF9fc2l6ZWtiX3RvX21iKGJfaW5mby0+dmlkZW9fbWVta2IpKSwKICAgICAg
ICAgICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgIH0KLSAgICAgICAgaWYgKGxpYnhsX2RlZmJv
b2xfdmFsKGJfaW5mby0+dS5odm0uc3RkdmdhKSkgeworCisgICAgICAgIHN3aXRjaCAoYl9pbmZv
LT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQ
RV9TVEQ6CiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItc3RkLXZnYSIp
OworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9U
WVBFX0NJUlJVUzoKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYg
KGJfaW5mby0+dS5odm0uYm9vdCkgewpAQCAtNDE4LDggKzQyMywxMyBAQCBzdGF0aWMgY2hhciAq
KiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5k
KGRtX2FyZ3MsIHNwaWNlb3B0aW9ucyk7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAobGlieGxf
ZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKSB7Ci0gICAgICAgICAgICAgICAgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAic3RkIiwgTlVMTCk7CisgICAgICAgIHN3
aXRjaCAoYl9pbmZvLT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9TVEQ6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdz
LCAiLXZnYSIsICJzdGQiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICBjYXNl
IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CisgICAgICAgICAgICBmbGV4YXJyYXlf
dmFwcGVuZChkbV9hcmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJy
ZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0uYm9vdCkgewpkaWZm
IC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfdHlwZXMuaWRsCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysg
Yi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJV2VkIEp1biAyNyAyMDowNjozOSAyMDEyICsw
ODAwCkBAIC0xMjUsOSArMTI1LDE5IEBAIGxpYnhsX3NodXRkb3duX3JlYXNvbiA9IEVudW1lcmF0
aW9uKCJzaHUKICAgICAoNCwgIndhdGNoZG9nIiksCiAgICAgXSkKIAorbGlieGxfdmdhX2ludGVy
ZmFjZV90eXBlID0gRW51bWVyYXRpb24oInZnYV9pbnRlcmZhY2VfdHlwZSIsIFsKKyAgICAoMSwg
IkNJUlJVUyIpLAorICAgICgyLCAiU1REIiksCisgICAgXSwgaW5pdF92YWwgPSAwKQorCiAjCiAj
IENvbXBsZXggbGlieGwgdHlwZXMKICMKKworbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvID0gU3Ry
dWN0KCJ2Z2FfaW50ZXJmYWNlX2luZm8iLCBbCisgICAgKCJraW5kIiwgICAgbGlieGxfdmdhX2lu
dGVyZmFjZV90eXBlKSwKKyAgICBdKQorCiBsaWJ4bF92bmNfaW5mbyA9IFN0cnVjdCgidm5jX2lu
Zm8iLCBbCiAgICAgKCJlbmFibGUiLCAgICAgICAgbGlieGxfZGVmYm9vbCksCiAgICAgIyAiYWRk
cmVzczpwb3J0IiB0aGF0IHNob3VsZCBiZSBsaXN0ZW5lZCBvbgpAQCAtMjg2LDcgKzI5Niw3IEBA
IGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvID0gU3RydWN0KCJkb21haW4KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICgibmVzdGVkX2h2bSIsICAgICAgIGxpYnhsX2RlZmJv
b2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJpbmNyX2dlbmVy
YXRpb25pZCIsbGlieGxfZGVmYm9vbCksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAoIm5vZ3JhcGhpYyIsICAgICAgICBsaWJ4bF9kZWZib29sKSwKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICgic3RkdmdhIiwgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2wpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJ2Z2EiLCAg
ICAgICAgICAgICAgbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvKSwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgidm5jIiwgICAgICAgICAgICAgIGxpYnhsX3ZuY19pbmZv
KSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMga2V5Ym9hcmQgbGF5
b3V0LCBkZWZhdWx0IGlzIGVuLXVzIGtleWJvYXJkCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoImtleW1hcCIsICAgICAgICAgICBzdHJpbmcpLApkaWZmIC1yIDU5MmQx
NWJkNGQ1ZSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxfY21k
aW1wbC5jCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC94
bF9jbWRpbXBsLmMJV2VkIEp1biAyNyAyMDowNjozOSAyMDEyICswODAwCkBAIC0xMjU2LDcgKzEy
NTYsMTAgQEAgc2tpcF92ZmI6CiAjdW5kZWYgcGFyc2VfZXh0cmFfYXJncwogCiAgICAgaWYgKGNf
aW5mby0+dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pIHsKLSAgICAgICAgeGx1X2NmZ19n
ZXRfZGVmYm9vbChjb25maWcsICJzdGR2Z2EiLCAmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIDApOwor
ICAgICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcoY29uZmlnLCAic3RkdmdhIiwgJmwsIDApKQor
ICAgICAgICAgICAgaWYgKGwpCisgICAgICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2Eua2lu
ZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9TVEQ7CisKICAgICAgICAgeGx1X2NmZ19nZXRf
ZGVmYm9vbChjb25maWcsICJ2bmMiLCAmYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxlLCAwKTsKICAg
ICAgICAgeGx1X2NmZ19yZXBsYWNlX3N0cmluZyAoY29uZmlnLCAidm5jbGlzdGVuIiwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmJfaW5mby0+dS5odm0udm5jLmxpc3RlbiwgMCk7
CmRpZmYgLXIgNTkyZDE1YmQ0ZDVlIHRvb2xzL2xpYnhsL3hsX3N4cC5jCi0tLSBhL3Rvb2xzL2xp
YnhsL3hsX3N4cC5jCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysgYi90b29scy9s
aWJ4bC94bF9zeHAuYwlXZWQgSnVuIDI3IDIwOjA2OjM5IDIwMTIgKzA4MDAKQEAgLTExMCw4ICsx
MTAsOSBAQCB2b2lkIHByaW50Zl9pbmZvX3NleHAoaW50IGRvbWlkLCBsaWJ4bF9kCiAgICAgICAg
ICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLm5lc3RlZF9odm0p
KTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQobm9faW5jcl9nZW5lcmF0aW9uaWQgJXMpXG4iLAog
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5pbmNy
X2dlbmVyYXRpb25pZCkpOwotICAgICAgICBwcmludGYoIlx0XHRcdChzdGR2Z2EgJXMpXG4iLAot
ICAgICAgICAgICAgICAgbGlieGxfZGVmYm9vbF90b19zdHJpbmcoYl9pbmZvLT51Lmh2bS5zdGR2
Z2EpKTsKKyAgICAgICAgcHJpbnRmKCJcdFx0XHQoc3RkdmdhICVzKVxuIiwgYl9pbmZvLT51Lmh2
bS52Z2Eua2luZCA9PQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMSUJY
TF9WR0FfSU5URVJGQUNFX1RZUEVfU1REID8KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIlRydWUiIDogIkZhbHNlIik7CiAgICAgICAgIHByaW50ZigiXHRcdFx0KHZuYyAl
cylcbiIsCiAgICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUu
aHZtLnZuYy5lbmFibGUpKTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jbGlzdGVuICVzKVxu
IiwgYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuKTsK
--f46d04447383bd94ef04c3732f19
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d04447383bd94ef04c3732f19--


From xen-devel-bounces@lists.xen.org Wed Jun 27 12:37:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 12:37: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 1SjrUP-0007CY-BQ; Wed, 27 Jun 2012 12:36: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 1SjrUN-0007CT-Kt
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 12:36:55 +0000
Received: from [193.109.254.147:36435] by server-2.bemta-14.messagelabs.com id
	5E/C4-01735-66EFAEF4; Wed, 27 Jun 2012 12:36:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340800604!1112664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15499 invoked from network); 27 Jun 2012 12:36:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 12:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13246001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 12:36:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 13:36:44 +0100
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 1SjrUC-0007M8-DS;
	Wed, 27 Jun 2012 12:36:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjrUC-0003ic-8T;
	Wed, 27 Jun 2012 13:36:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13374-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 13:36:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13374: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13374 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13374/

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. 13338
 build-i386                    4 xen-build                 fail REGR. vs. 13338
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13338
 build-amd64                   4 xen-build                 fail REGR. vs. 13338

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-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-win   1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 qemuu                c64d5b2a859d81aeccbf036655e9ba67bae095d6
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     blocked 
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  blocked 
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 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 c64d5b2a859d81aeccbf036655e9ba67bae095d6
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Wed Jun 27 10:10:08 2012 +0000

    xenstore: Use <xenstore.h>
    
    In the next release of Xen (4.2), xs.h became deprecated.
    
    upstream-commit: e108a3c110506faf3ef43448be3e0d39ef0ead8f
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 12:37:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 12:37: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 1SjrUP-0007CY-BQ; Wed, 27 Jun 2012 12:36: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 1SjrUN-0007CT-Kt
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 12:36:55 +0000
Received: from [193.109.254.147:36435] by server-2.bemta-14.messagelabs.com id
	5E/C4-01735-66EFAEF4; Wed, 27 Jun 2012 12:36:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1340800604!1112664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15499 invoked from network); 27 Jun 2012 12:36:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 12:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13246001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 12:36:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 13:36:44 +0100
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 1SjrUC-0007M8-DS;
	Wed, 27 Jun 2012 12:36:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjrUC-0003ic-8T;
	Wed, 27 Jun 2012 13:36:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13374-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 13:36:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13374: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13374 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13374/

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. 13338
 build-i386                    4 xen-build                 fail REGR. vs. 13338
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13338
 build-amd64                   4 xen-build                 fail REGR. vs. 13338

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-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-win   1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 qemuu                c64d5b2a859d81aeccbf036655e9ba67bae095d6
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     blocked 
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  blocked 
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 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 c64d5b2a859d81aeccbf036655e9ba67bae095d6
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Wed Jun 27 10:10:08 2012 +0000

    xenstore: Use <xenstore.h>
    
    In the next release of Xen (4.2), xs.h became deprecated.
    
    upstream-commit: e108a3c110506faf3ef43448be3e0d39ef0ead8f
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 12:42:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 12:42: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 1SjrZo-0007LR-43; Wed, 27 Jun 2012 12:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SjrZl-0007LM-TK
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 12:42:30 +0000
Received: from [85.158.143.35:37283] by server-1.bemta-4.messagelabs.com id
	1A/E8-24392-5BFFAEF4; Wed, 27 Jun 2012 12:42:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340800948!12867688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18685 invoked from network); 27 Jun 2012 12:42:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 12:42:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13246124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 12:42:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 13:42:27 +0100
Date: Wed, 27 Jun 2012 13:42:01 +0100
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: <1340787595.29172.16.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271337300.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340721279.3832.143.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
	<1340787595.29172.16.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 4/5] libxc/arm: allocate xenstore and
	console 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, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 19:05 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > > > Allocate two additional pages at the end of the guest physical memory
> > > > for xenstore and console.
> > > > Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> > > > values.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > ---
> > > >  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
> > > >  1 files changed, 22 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > > index bb86139..df2eefe 100644
> > > > --- a/tools/libxc/xc_dom_arm.c
> > > > +++ b/tools/libxc/xc_dom_arm.c
> > > > @@ -25,6 +25,10 @@
> > > >  #include "xg_private.h"
> > > >  #include "xc_dom.h"
> > > >  
> > > > +#define NR_MAGIC_PAGES 2
> > > > +#define CONSOLE_PFN_OFFSET 0
> > > > +#define XENSTORE_PFN_OFFSET 1
> > > > +
> > > >  /* ------------------------------------------------------------------------ */
> > > >  /*
> > > >   * arm guests are hybrid and start off with paging disabled, therefore no
> > > > @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> > > >  static int alloc_magic_pages(struct xc_dom_image *dom)
> > > >  {
> > > >      DOMPRINTF_CALLED(dom->xch);
> > > > -    /* XXX
> > > > -     *   dom->p2m_guest
> > > > -     *   dom->start_info_pfn
> > > > -     *   dom->xenstore_pfn
> > > > -     *   dom->console_pfn
> > > > -     */
> > > >      return 0;
> > > >  }
> > > >  
> > > > @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > > >  {
> > > >      int rc;
> > > >      xen_pfn_t pfn, allocsz, i;
> > > > +    xen_pfn_t store_pfn, console_pfn;
> > > >  
> > > >      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
> > > >              dom->total_pages, dom->rambase_pfn);
> > > >  
> > > >      dom->shadow_enabled = 1;
> > > >  
> > > > -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> > > > +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
> > > >  
> > > >      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
> > > >              dom->rambase_pfn, dom->total_pages );
> > > >      /* setup initial p2m */
> > > > -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> > > > +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
> > > >          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
> > > >  
> > > >      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> > > > @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > > >  
> > > >      /* allocate guest memory */
> > > >      for ( i = rc = allocsz = 0;
> > > > -          (i < dom->total_pages) && !rc;
> > > > +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
> > > >            i += allocsz )
> > > >      {
> > > > -        allocsz = dom->total_pages - i;
> > > > +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
> > > 
> > > All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.
> > > 
> > > Do these pages need to be in p2m_host or would it be fine to just insert
> > > them into the guest p2m individually outside the main allocation logic?
> > 
> > I think it makes sense for them to be in p2m_host. In fact if we try to
> > allocate them later, wouldn't we have the problem of having to extend
> > the guest p2m? We might as well do it here.
> 
> The actual guest p2m is internal to the hypervisor so we never see it at
> the tools layer.
> 
> I'm unsure if we need these magic pages in p2m_host. If we remember the
> gfn of the magic pages that's just as useful as remembering the offset
> in p2m_host and using p2m_host[offset]?

I think that you are right: it is better not to add them to p2m_host.

---

libxc/arm: allocate xenstore and console pages

Allocate two additional pages at the end of the guest physical memory
for xenstore and console.
Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
values.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index bb86139..724e7ad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -25,6 +25,10 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
+#define NR_MAGIC_PAGES 2
+#define CONSOLE_PFN_OFFSET 0
+#define XENSTORE_PFN_OFFSET 1
+
 /* ------------------------------------------------------------------------ */
 /*
  * arm guests are hybrid and start off with paging disabled, therefore no
@@ -46,13 +50,33 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
 
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {
+    int rc, i, allocsz;
+    xen_pfn_t store_pfn, console_pfn, p2m[NR_MAGIC_PAGES];
+
     DOMPRINTF_CALLED(dom->xch);
-    /* XXX
-     *   dom->p2m_guest
-     *   dom->start_info_pfn
-     *   dom->xenstore_pfn
-     *   dom->console_pfn
-     */
+
+    for (i = 0; i < NR_MAGIC_PAGES; i++)
+        p2m[i] = dom->rambase_pfn + dom->total_pages + i;
+
+    for ( i = rc = allocsz = 0;
+          (i < NR_MAGIC_PAGES) && !rc;
+          i += allocsz) {
+        allocsz = NR_MAGIC_PAGES - i;
+        rc = xc_domain_populate_physmap_exact(
+                dom->xch, dom->guest_domid, allocsz,
+                0, 0, &p2m[i]);
+    }
+
+    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
+    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
+            console_pfn);
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
+            store_pfn);
+
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 12:42:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 12:42: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 1SjrZo-0007LR-43; Wed, 27 Jun 2012 12:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SjrZl-0007LM-TK
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 12:42:30 +0000
Received: from [85.158.143.35:37283] by server-1.bemta-4.messagelabs.com id
	1A/E8-24392-5BFFAEF4; Wed, 27 Jun 2012 12:42:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340800948!12867688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18685 invoked from network); 27 Jun 2012 12:42:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 12:42:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13246124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 12:42:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 13:42:27 +0100
Date: Wed, 27 Jun 2012 13:42:01 +0100
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: <1340787595.29172.16.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271337300.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206221634020.27860@kaball.uk.xensource.com>
	<1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340381373-22177-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1340721279.3832.143.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261901110.27860@kaball.uk.xensource.com>
	<1340787595.29172.16.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 4/5] libxc/arm: allocate xenstore and
	console 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, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 19:05 +0100, Stefano Stabellini wrote:
> > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > On Fri, 2012-06-22 at 17:09 +0100, Stefano Stabellini wrote:
> > > > Allocate two additional pages at the end of the guest physical memory
> > > > for xenstore and console.
> > > > Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
> > > > values.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > ---
> > > >  tools/libxc/xc_dom_arm.c |   32 ++++++++++++++++++++++----------
> > > >  1 files changed, 22 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > > index bb86139..df2eefe 100644
> > > > --- a/tools/libxc/xc_dom_arm.c
> > > > +++ b/tools/libxc/xc_dom_arm.c
> > > > @@ -25,6 +25,10 @@
> > > >  #include "xg_private.h"
> > > >  #include "xc_dom.h"
> > > >  
> > > > +#define NR_MAGIC_PAGES 2
> > > > +#define CONSOLE_PFN_OFFSET 0
> > > > +#define XENSTORE_PFN_OFFSET 1
> > > > +
> > > >  /* ------------------------------------------------------------------------ */
> > > >  /*
> > > >   * arm guests are hybrid and start off with paging disabled, therefore no
> > > > @@ -47,12 +51,6 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> > > >  static int alloc_magic_pages(struct xc_dom_image *dom)
> > > >  {
> > > >      DOMPRINTF_CALLED(dom->xch);
> > > > -    /* XXX
> > > > -     *   dom->p2m_guest
> > > > -     *   dom->start_info_pfn
> > > > -     *   dom->xenstore_pfn
> > > > -     *   dom->console_pfn
> > > > -     */
> > > >      return 0;
> > > >  }
> > > >  
> > > > @@ -127,18 +125,19 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > > >  {
> > > >      int rc;
> > > >      xen_pfn_t pfn, allocsz, i;
> > > > +    xen_pfn_t store_pfn, console_pfn;
> > > >  
> > > >      fprintf(stderr, "%s: tot pages %"PRI_xen_pfn" rambase %"PRI_xen_pfn"\n", __func__,
> > > >              dom->total_pages, dom->rambase_pfn);
> > > >  
> > > >      dom->shadow_enabled = 1;
> > > >  
> > > > -    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
> > > > +    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * (dom->total_pages + NR_MAGIC_PAGES));
> > > >  
> > > >      fprintf(stderr, "%s: setup p2m from %"PRI_xen_pfn" for %"PRI_xen_pfn" pages\n", __func__,
> > > >              dom->rambase_pfn, dom->total_pages );
> > > >      /* setup initial p2m */
> > > > -    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
> > > > +    for ( pfn = 0; pfn < (dom->total_pages + NR_MAGIC_PAGES); pfn++ )
> > > >          dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
> > > >  
> > > >      fprintf(stderr, "%s: init'd p2m_host[0] = %"PRI_xen_pfn"\n", __func__, dom->p2m_host[0]);
> > > > @@ -148,10 +147,10 @@ int arch_setup_meminit(struct xc_dom_image *dom)
> > > >  
> > > >      /* allocate guest memory */
> > > >      for ( i = rc = allocsz = 0;
> > > > -          (i < dom->total_pages) && !rc;
> > > > +          (i < dom->total_pages + NR_MAGIC_PAGES) && !rc;
> > > >            i += allocsz )
> > > >      {
> > > > -        allocsz = dom->total_pages - i;
> > > > +        allocsz = (dom->total_pages + NR_MAGIC_PAGES) - i;
> > > 
> > > All these "+ NR_MAGIC_PAGES" are a bit troublesome looking.
> > > 
> > > Do these pages need to be in p2m_host or would it be fine to just insert
> > > them into the guest p2m individually outside the main allocation logic?
> > 
> > I think it makes sense for them to be in p2m_host. In fact if we try to
> > allocate them later, wouldn't we have the problem of having to extend
> > the guest p2m? We might as well do it here.
> 
> The actual guest p2m is internal to the hypervisor so we never see it at
> the tools layer.
> 
> I'm unsure if we need these magic pages in p2m_host. If we remember the
> gfn of the magic pages that's just as useful as remembering the offset
> in p2m_host and using p2m_host[offset]?

I think that you are right: it is better not to add them to p2m_host.

---

libxc/arm: allocate xenstore and console pages

Allocate two additional pages at the end of the guest physical memory
for xenstore and console.
Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding
values.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index bb86139..724e7ad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -25,6 +25,10 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
+#define NR_MAGIC_PAGES 2
+#define CONSOLE_PFN_OFFSET 0
+#define XENSTORE_PFN_OFFSET 1
+
 /* ------------------------------------------------------------------------ */
 /*
  * arm guests are hybrid and start off with paging disabled, therefore no
@@ -46,13 +50,33 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
 
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {
+    int rc, i, allocsz;
+    xen_pfn_t store_pfn, console_pfn, p2m[NR_MAGIC_PAGES];
+
     DOMPRINTF_CALLED(dom->xch);
-    /* XXX
-     *   dom->p2m_guest
-     *   dom->start_info_pfn
-     *   dom->xenstore_pfn
-     *   dom->console_pfn
-     */
+
+    for (i = 0; i < NR_MAGIC_PAGES; i++)
+        p2m[i] = dom->rambase_pfn + dom->total_pages + i;
+
+    for ( i = rc = allocsz = 0;
+          (i < NR_MAGIC_PAGES) && !rc;
+          i += allocsz) {
+        allocsz = NR_MAGIC_PAGES - i;
+        rc = xc_domain_populate_physmap_exact(
+                dom->xch, dom->guest_domid, allocsz,
+                0, 0, &p2m[i]);
+    }
+
+    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
+    store_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_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
+            console_pfn);
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
+            store_pfn);
+
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:12:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:12: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 1Sjs2B-0007g8-2j; Wed, 27 Jun 2012 13:11: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 1Sjs29-0007g1-5L
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:11:49 +0000
Received: from [85.158.143.35:30743] by server-1.bemta-4.messagelabs.com id
	0C/2B-24392-4960BEF4; Wed, 27 Jun 2012 13:11:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340802707!6501208!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28523 invoked from network); 27 Jun 2012 13:11:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 13:11:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 14:11:46 +0100
Message-Id: <4FEB22DF020000780008C389@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 14:12:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340699982.3832.28.camel@zakaz.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 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> hypervisor, blockers:
> 
>     * None

We should evaluate whether getting the vMCE interface into a
sane state ought to be treated as a blocker (see Jinsong's
recent posting about their design work). Otherwise we'll run
into yet another round of compatibility issues when moving on
to 4.3, particularly with respect to migration.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:12:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:12: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 1Sjs2B-0007g8-2j; Wed, 27 Jun 2012 13:11: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 1Sjs29-0007g1-5L
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:11:49 +0000
Received: from [85.158.143.35:30743] by server-1.bemta-4.messagelabs.com id
	0C/2B-24392-4960BEF4; Wed, 27 Jun 2012 13:11:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340802707!6501208!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28523 invoked from network); 27 Jun 2012 13:11:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 13:11:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 14:11:46 +0100
Message-Id: <4FEB22DF020000780008C389@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 14:12:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340699982.3832.28.camel@zakaz.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 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> hypervisor, blockers:
> 
>     * None

We should evaluate whether getting the vMCE interface into a
sane state ought to be treated as a blocker (see Jinsong's
recent posting about their design work). Otherwise we'll run
into yet another round of compatibility issues when moving on
to 4.3, particularly with respect to migration.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:14:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:14: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 1Sjs4e-0007lf-KI; Wed, 27 Jun 2012 13:14:24 +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 1Sjs4d-0007lY-IM
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:14:23 +0000
Received: from [85.158.143.35:52320] by server-2.bemta-4.messagelabs.com id
	A4/70-17938-E270BEF4; Wed, 27 Jun 2012 13:14:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340802849!18323193!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32214 invoked from network); 27 Jun 2012 13:14:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 13:14:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 14:14:08 +0100
Message-Id: <4FEB236C020000780008C392@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 14:14:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 05:51, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> This is updated xen vMCE design foils, according to comments from community 
> recently.
> 
> This foils focus on vMCE part of Xen MCA, so as Keir said, it's some dense.
> Later Will will present a document to elaborate more, including Intel MCA 
> and surrounding features and Xen implementation.

For MCi_CTL2 you probably meant to say "allow setting CMCI_EN
and error count threshold"?

The 2-bank approach also needs to be brought in line with the
current host derived value in MCG_CAP, especially if the code to
implement this new model doesn't make it into 4.2 (which would
generally save a larger value).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:14:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:14: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 1Sjs4e-0007lf-KI; Wed, 27 Jun 2012 13:14:24 +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 1Sjs4d-0007lY-IM
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:14:23 +0000
Received: from [85.158.143.35:52320] by server-2.bemta-4.messagelabs.com id
	A4/70-17938-E270BEF4; Wed, 27 Jun 2012 13:14:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340802849!18323193!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32214 invoked from network); 27 Jun 2012 13:14:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	27 Jun 2012 13:14:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 14:14:08 +0100
Message-Id: <4FEB236C020000780008C392@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 14:14:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 05:51, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> This is updated xen vMCE design foils, according to comments from community 
> recently.
> 
> This foils focus on vMCE part of Xen MCA, so as Keir said, it's some dense.
> Later Will will present a document to elaborate more, including Intel MCA 
> and surrounding features and Xen implementation.

For MCi_CTL2 you probably meant to say "allow setting CMCI_EN
and error count threshold"?

The 2-bank approach also needs to be brought in line with the
current host derived value in MCG_CAP, especially if the code to
implement this new model doesn't make it into 4.2 (which would
generally save a larger value).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:17:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjs7d-0007uI-6w; Wed, 27 Jun 2012 13:17: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 1Sjs7b-0007uA-VJ
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:17:28 +0000
Received: from [85.158.143.99:6523] by server-1.bemta-4.messagelabs.com id
	10/37-24392-7E70BEF4; Wed, 27 Jun 2012 13:17:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340803046!24108072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22795 invoked from network); 27 Jun 2012 13:17:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13247161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:17:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:17:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sjs7Z-0007du-Mp; Wed, 27 Jun 2012 13:17:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sjs7Z-0006TG-Kn;
	Wed, 27 Jun 2012 14:17:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20459.2021.554874.531624@mariner.uk.xensource.com>
Date: Wed, 27 Jun 2012 14:17:25 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.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 v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> Shriram, would you care to take a look at this series and perhaps
> retest it ?
...
> If you would prefer a git branch to a series of patches, you can find
> it here:
>  http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
>  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram<http://xenbits.xen.org/people/iwj/xen-unstable.git#shriram>
> NB that branch is REBASING.
...
> I am not too familiar with the git lingo.. What did you mean by "branch is rebasing" ?
> Am I supposed to do something special, apart from the normal process below:
> git clone git://xen....
> git checkout -b for-shriram origin/for-shriram

Yes, that will work just fine.

The warning about rebasing is because this branch may have its
history rewritten, so if I update it in future you won't be able to
just pull from it to update.  In that case I'll be happy to help out
with instructions.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:17:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjs7d-0007uI-6w; Wed, 27 Jun 2012 13:17: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 1Sjs7b-0007uA-VJ
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:17:28 +0000
Received: from [85.158.143.99:6523] by server-1.bemta-4.messagelabs.com id
	10/37-24392-7E70BEF4; Wed, 27 Jun 2012 13:17:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340803046!24108072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22795 invoked from network); 27 Jun 2012 13:17:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13247161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:17:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:17:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Sjs7Z-0007du-Mp; Wed, 27 Jun 2012 13:17:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Sjs7Z-0006TG-Kn;
	Wed, 27 Jun 2012 14:17:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20459.2021.554874.531624@mariner.uk.xensource.com>
Date: Wed, 27 Jun 2012 14:17:25 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.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 v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> Shriram, would you care to take a look at this series and perhaps
> retest it ?
...
> If you would prefer a git branch to a series of patches, you can find
> it here:
>  http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
>  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram<http://xenbits.xen.org/people/iwj/xen-unstable.git#shriram>
> NB that branch is REBASING.
...
> I am not too familiar with the git lingo.. What did you mean by "branch is rebasing" ?
> Am I supposed to do something special, apart from the normal process below:
> git clone git://xen....
> git checkout -b for-shriram origin/for-shriram

Yes, that will work just fine.

The warning about rebasing is because this branch may have its
history rewritten, so if I update it in future you won't be able to
just pull from it to update.  In that case I'll be happy to help out
with instructions.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:30:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:30: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 1SjsJd-000888-G8; Wed, 27 Jun 2012 13:29:53 +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 1SjsJb-000883-K0
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:29:51 +0000
Received: from [85.158.143.99:35438] by server-2.bemta-4.messagelabs.com id
	9E/B2-17938-ECA0BEF4; Wed, 27 Jun 2012 13:29:50 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340803752!21688574!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1319 invoked from network); 27 Jun 2012 13:29:13 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 13:29:13 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RDT9ou009494
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 06:29:10 -0700
Received: by bkwj10 with SMTP id j10so1059740bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 06:29:07 -0700 (PDT)
Received: by 10.204.145.88 with SMTP id c24mr996240bkv.24.1340803747843; Wed,
	27 Jun 2012 06:29:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 06:28:27 -0700 (PDT)
In-Reply-To: <20459.2021.554874.531624@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<20459.2021.554874.531624@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 09:28:27 -0400
Message-ID: <CAP8mzPNw5tPsfN1Fzud32A7a1xN7ZKRfjkao48-1-7LwGQOJ2Q@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0893326112453824002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0893326112453824002==
Content-Type: multipart/alternative; boundary=00151740259a1a8cf704c374339b

--00151740259a1a8cf704c374339b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 9:17 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain
> save/restore: run in a separate process"):
> > Shriram, would you care to take a look at this series and perhaps
> > retest it ?
> ...
> > If you would prefer a git branch to a series of patches, you can find
> > it here:
> >
> http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
> >  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram<
> http://xenbits.xen.org/people/iwj/xen-unstable.git#shriram>
> > NB that branch is REBASING.
> ...
> > I am not too familiar with the git lingo.. What did you mean by "branch
> is rebasing" ?
> > Am I supposed to do something special, apart from the normal process
> below:
> > git clone git://xen....
> > git checkout -b for-shriram origin/for-shriram
>
> Yes, that will work just fine.
>
> The warning about rebasing is because this branch may have its
> history rewritten, so if I update it in future you won't be able to
> just pull from it to update.  In that case I'll be happy to help out
> with instructions.
>
>
Yep got that. Pulled from that branch and tested. Sent out the results
yesterday (under this thread).


> Regards,
> Ian.
>
>

--00151740259a1a8cf704c374339b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 9:17 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">

Shriram Rajagopalan writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/r=
estore: run in a separate process&quot;):<br>
<div class=3D"im">&gt; Shriram, would you care to take a look at this serie=
s and perhaps<br>
&gt; retest it ?<br>
</div>...<br>
<div class=3D"im">&gt; If you would prefer a git branch to a series of patc=
hes, you can find<br>
&gt; it here:<br>
&gt; =A0<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstab=
le.git;a=3Dshortlog;h=3Drefs/heads/for-shriram" target=3D"_blank">http://xe=
nbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.git;a=3Dshortlog;h=3Drefs=
/heads/for-shriram</a><br>


</div>&gt; =A0git://<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstab=
le.git#shriram" target=3D"_blank">xenbits.xen.org/people/iwj/xen-unstable.g=
it#shriram</a>&lt;<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstable=
.git#shriram" target=3D"_blank">http://xenbits.xen.org/people/iwj/xen-unsta=
ble.git#shriram</a>&gt;<br>


<div class=3D"im">&gt; NB that branch is REBASING.<br>
</div>...<br>
<div class=3D"im">&gt; I am not too familiar with the git lingo.. What did =
you mean by &quot;branch is rebasing&quot; ?<br>
&gt; Am I supposed to do something special, apart from the normal process b=
elow:<br>
&gt; git clone git://xen....<br>
&gt; git checkout -b for-shriram origin/for-shriram<br>
<br>
</div>Yes, that will work just fine.<br>
<br>
The warning about rebasing is because this branch may have its<br>
history rewritten, so if I update it in future you won&#39;t be able to<br>
just pull from it to update. =A0In that case I&#39;ll be happy to help out<=
br>
with instructions.<br>
<br></blockquote><div><br></div><div>Yep got that. Pulled from that branch =
and tested. Sent out the results</div><div>yesterday (under this thread).</=
div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">


Regards,<br>
Ian.<br>
<br>
</blockquote></div><br>

--00151740259a1a8cf704c374339b--


--===============0893326112453824002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0893326112453824002==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 13:30:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:30: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 1SjsJd-000888-G8; Wed, 27 Jun 2012 13:29:53 +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 1SjsJb-000883-K0
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:29:51 +0000
Received: from [85.158.143.99:35438] by server-2.bemta-4.messagelabs.com id
	9E/B2-17938-ECA0BEF4; Wed, 27 Jun 2012 13:29:50 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340803752!21688574!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1319 invoked from network); 27 Jun 2012 13:29:13 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 13:29:13 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RDT9ou009494
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 06:29:10 -0700
Received: by bkwj10 with SMTP id j10so1059740bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 06:29:07 -0700 (PDT)
Received: by 10.204.145.88 with SMTP id c24mr996240bkv.24.1340803747843; Wed,
	27 Jun 2012 06:29:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 06:28:27 -0700 (PDT)
In-Reply-To: <20459.2021.554874.531624@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<20459.2021.554874.531624@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 09:28:27 -0400
Message-ID: <CAP8mzPNw5tPsfN1Fzud32A7a1xN7ZKRfjkao48-1-7LwGQOJ2Q@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0893326112453824002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0893326112453824002==
Content-Type: multipart/alternative; boundary=00151740259a1a8cf704c374339b

--00151740259a1a8cf704c374339b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 9:17 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain
> save/restore: run in a separate process"):
> > Shriram, would you care to take a look at this series and perhaps
> > retest it ?
> ...
> > If you would prefer a git branch to a series of patches, you can find
> > it here:
> >
> http://xenbits.xen.org/gitweb/?p=people/iwj/xen-unstable.git;a=shortlog;h=refs/heads/for-shriram
> >  git://xenbits.xen.org/people/iwj/xen-unstable.git#shriram<
> http://xenbits.xen.org/people/iwj/xen-unstable.git#shriram>
> > NB that branch is REBASING.
> ...
> > I am not too familiar with the git lingo.. What did you mean by "branch
> is rebasing" ?
> > Am I supposed to do something special, apart from the normal process
> below:
> > git clone git://xen....
> > git checkout -b for-shriram origin/for-shriram
>
> Yes, that will work just fine.
>
> The warning about rebasing is because this branch may have its
> history rewritten, so if I update it in future you won't be able to
> just pull from it to update.  In that case I'll be happy to help out
> with instructions.
>
>
Yep got that. Pulled from that branch and tested. Sent out the results
yesterday (under this thread).


> Regards,
> Ian.
>
>

--00151740259a1a8cf704c374339b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 9:17 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">

Shriram Rajagopalan writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/r=
estore: run in a separate process&quot;):<br>
<div class=3D"im">&gt; Shriram, would you care to take a look at this serie=
s and perhaps<br>
&gt; retest it ?<br>
</div>...<br>
<div class=3D"im">&gt; If you would prefer a git branch to a series of patc=
hes, you can find<br>
&gt; it here:<br>
&gt; =A0<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstab=
le.git;a=3Dshortlog;h=3Drefs/heads/for-shriram" target=3D"_blank">http://xe=
nbits.xen.org/gitweb/?p=3Dpeople/iwj/xen-unstable.git;a=3Dshortlog;h=3Drefs=
/heads/for-shriram</a><br>


</div>&gt; =A0git://<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstab=
le.git#shriram" target=3D"_blank">xenbits.xen.org/people/iwj/xen-unstable.g=
it#shriram</a>&lt;<a href=3D"http://xenbits.xen.org/people/iwj/xen-unstable=
.git#shriram" target=3D"_blank">http://xenbits.xen.org/people/iwj/xen-unsta=
ble.git#shriram</a>&gt;<br>


<div class=3D"im">&gt; NB that branch is REBASING.<br>
</div>...<br>
<div class=3D"im">&gt; I am not too familiar with the git lingo.. What did =
you mean by &quot;branch is rebasing&quot; ?<br>
&gt; Am I supposed to do something special, apart from the normal process b=
elow:<br>
&gt; git clone git://xen....<br>
&gt; git checkout -b for-shriram origin/for-shriram<br>
<br>
</div>Yes, that will work just fine.<br>
<br>
The warning about rebasing is because this branch may have its<br>
history rewritten, so if I update it in future you won&#39;t be able to<br>
just pull from it to update. =A0In that case I&#39;ll be happy to help out<=
br>
with instructions.<br>
<br></blockquote><div><br></div><div>Yep got that. Pulled from that branch =
and tested. Sent out the results</div><div>yesterday (under this thread).</=
div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">


Regards,<br>
Ian.<br>
<br>
</blockquote></div><br>

--00151740259a1a8cf704c374339b--


--===============0893326112453824002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0893326112453824002==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 13:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1SjsQJ-0008KL-BV; Wed, 27 Jun 2012 13:36: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 1SjsQH-0008KD-SH
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:36:46 +0000
Received: from [85.158.138.51:42883] by server-8.bemta-3.messagelabs.com id
	5F/96-06157-86C0BEF4; Wed, 27 Jun 2012 13:36:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340804198!29807289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13901 invoked from network); 27 Jun 2012 13:36:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:36:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13247719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:36:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:36:38 +0100
Date: Wed, 27 Jun 2012 14:36:04 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 26 Jun 2012, Rolu wrote:
> On Tue, Jun 26, 2012 at 2:59 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 26 Jun 2012, Rolu wrote:
> >> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Mon, 25 Jun 2012, Jan Beulich wrote:
> >> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> >> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> >> At the same time, adding logging to the guest kernel would
> >> >> >> be nice, to see what value it actually writes (in a current
> >> >> >> kernel this would be in __write_msi_msg()).
> >> >> >>
> >> >> >
> >> >> > Turns out that msg->data here is also 0x4300, so it seems the guest
> >> >> > kernel is producing these values. I caused it to make a stack trace
> >> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> >> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> >> >> > current data field and if it isn't equal to the macro it uses
> >> >> > xen_msi_compose_msg to make a new message, but that function just sets
> >> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> >> >> > then gets passed to __write_msi_msg and that's that. There are no
> >> >> > other writes through __write_msi_msg (except for the same thing for
> >> >> > other devices).
> >> >> >
> >> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> >> >> > decoded as the delivery mode, so it seems the kernel is intentionally
> >> >> > setting it to 3.
> >> >>
> >> >> So that can never have worked properly afaict. Stefano, the
> >> >> code as it is currently - using literal (3 << 8) - is clearly bogus.
> >> >> Your original commit at least had a comment saying that the
> >> >> reserved delivery mode encoding is intentional here, but that
> >> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
> >> >> In any case - the cooperation with qemu apparently doesn't
> >> >> work, as the reserved encoding should never make it through
> >> >> to the hypervisor. Could you explain what the intention here
> >> >> was?
> >> >>
> >> >> And regardless of anything, can the literal numbers please be
> >> >> replaced by proper manifest constants - the "8" here already
> >> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
> >> >> proper symbolic would permit locating where this is being (or
> >> >> really, as it doesn't appear to work supposed to be) consumed
> >> >> in qemu, provided it uses the same definition (i.e. that one
> >> >> should go into one of the public headers).
> >> >
> >> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
> >> > because notifications are not supposed to be delivered as MSI anymore.
> >> >
> >> > This is what should happen:
> >> >
> >> > 1) Linux configures the device with a 0 vector number and the pirq number
> >> > in the address field;
> >> >
> >> > 2) QEMU notices a vector number of 0 and reads the pirq number from the
> >> > address field, passing it to xc_domain_update_msi_irq;
> >> >
> >> > 3) Xen assignes the given pirq to the physical MSI;
> >> >
> >> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
> >> >
> >> > 5) Xen sets the pirq as "IRQ_PT";
> >> >
> >> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
> >> > returns true so Xen calls send_guest_pirq instead.
> >> >
> >> >
> >> > Obviously 6) is not happening. hvm_domain_use_pirq is:
> >> >
> >> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
> >> >
> >> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
> >> > above).
> >>
> >> This appears to be true. I added logging to hvm_pci_msi_assert in
> >> xen/drivers/passthrough/io.c and it indicates that
> >> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
> >> before an unsupported delivery mode message.
> >>
> >> I also log pirq->pirq but I found that most of the time I can't find
> >> this value anywhere else (I'm not sure how to interpret the value,
> >> though). For example, in my last try:
> >>
> >> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
> >> 53. The vast majority are for 54.
> >> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
> >> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
> >> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
> >> but complains it's already mapped.
> >> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
> >> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
> >> 22, 52, 48, 47. Also never 54 or 53.
> >> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
> >> * The qemu log mentions pirq 35, 36 and 37
> >>
> >> It seems pirq values don't always mean the same? Is it a coincidence
> >> that 55 occurs almost everywhere, or is something going wrong with the
> >> other two values (53 and 54 versus 16 and 17)?
> >>
> >> I have three MSI capable devices passed through to the domU, and I do
> >> see groups of three distinct pirqs in the data above - just not the
> >> same ones in every place I look.
> >>
> >> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
> >> > (__startup_pirq doesn't get called), or Xen is erroring out in
> >> > map_domain_emuirq_pirq.
> >>
> >> evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.
> >>
> >> map_domain_emuirq_pirq always gets past the checks in the top half
> >> (i.e. up to the line /* do not store emuirq mappings for pt devices
> >> */), except for one time with pirq=49,emuirq=23 where it finds they
> >> are already mapped.
> >> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
> >> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
> >> directly logged that but it's the only assignment there).
> >>
> >> Interestingly, I get an unsupported delivery mode error for pirq 55
> >> where my logging says pirq->arch.hvm.emuirq is -1, *after*
> >> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.
> >
> > Looking back at your QEMU logs, it seems that pt_msi_setup is not
> > called (or it is not called at the right time), otherwise you should
> > get:
> >
> > pt_msi_setup requested pirq = %d
> >
> > in your logs.
> > Could you try disabling msitranslate? You can do that adding
> >
> > pci_msitranslate=0
> >
> > to your VM config file.
> 
> I tried that, but it didn't work.
> 
> > If that works, probably this (untested) QEMU patch could fix your problem:
> >
> 
> I appreciate the help.
> 
> I applied the patch anyway just to see what would happen (had to edit
> a few dev versus d variable names) but it didn't help. It also breaks
> pt_msi_update, as I get in the qemu log:
> 
> pt_msi_update: Update msi with pirq 2f gvec 0 gflags 302f
> pt_msi_update: Error: Binding of MSI failed.
> pt_msi_update: Error: Unmapping of MSI failed.
> pt_msgctrl_reg_write: Warning: Can not bind MSI for dev 80
> 
> I added some logging to pt_msi_setup (without the patch). It does get
> called, and it does so rather early in the boot process, each time
> right before lines as these:
> 
> pci_intx: intx=1
> register_real_device: Real physical device 00:1b.0 registered successfuly!
> IRQ type = MSI-INTx
> 
> At this point dev->msi->data, addr_hi and addr_lo are all 0, which
> doesn't seem right. Is it being called prematurely?

That's because msitranslate is still enabled somehow, that is a
toolstack bug.
While we fix that bug, could you try this QEMU patch to forcefully disable
msitranslate?

diff --git a/xenstore.c b/xenstore.c
index ac90366..8af280e 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -427,7 +427,7 @@ uint32_t xenstore_read_target(void)
     return target_domid;
 }
 
-#define PT_PCI_MSITRANSLATE_DEFAULT 1
+#define PT_PCI_MSITRANSLATE_DEFAULT 0
 #define PT_PCI_POWER_MANAGEMENT_DEFAULT 0
 int direct_pci_msitranslate;
 int direct_pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1SjsQJ-0008KL-BV; Wed, 27 Jun 2012 13:36: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 1SjsQH-0008KD-SH
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:36:46 +0000
Received: from [85.158.138.51:42883] by server-8.bemta-3.messagelabs.com id
	5F/96-06157-86C0BEF4; Wed, 27 Jun 2012 13:36:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340804198!29807289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13901 invoked from network); 27 Jun 2012 13:36:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:36:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13247719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:36:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:36:38 +0100
Date: Wed, 27 Jun 2012 14:36:04 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 26 Jun 2012, Rolu wrote:
> On Tue, Jun 26, 2012 at 2:59 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Tue, 26 Jun 2012, Rolu wrote:
> >> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
> >> <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Mon, 25 Jun 2012, Jan Beulich wrote:
> >> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
> >> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> >> At the same time, adding logging to the guest kernel would
> >> >> >> be nice, to see what value it actually writes (in a current
> >> >> >> kernel this would be in __write_msi_msg()).
> >> >> >>
> >> >> >
> >> >> > Turns out that msg->data here is also 0x4300, so it seems the guest
> >> >> > kernel is producing these values. I caused it to make a stack trace
> >> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function uses
> >> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It checks the
> >> >> > current data field and if it isn't equal to the macro it uses
> >> >> > xen_msi_compose_msg to make a new message, but that function just sets
> >> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300. This
> >> >> > then gets passed to __write_msi_msg and that's that. There are no
> >> >> > other writes through __write_msi_msg (except for the same thing for
> >> >> > other devices).
> >> >> >
> >> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends up
> >> >> > decoded as the delivery mode, so it seems the kernel is intentionally
> >> >> > setting it to 3.
> >> >>
> >> >> So that can never have worked properly afaict. Stefano, the
> >> >> code as it is currently - using literal (3 << 8) - is clearly bogus.
> >> >> Your original commit at least had a comment saying that the
> >> >> reserved delivery mode encoding is intentional here, but that
> >> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
> >> >> In any case - the cooperation with qemu apparently doesn't
> >> >> work, as the reserved encoding should never make it through
> >> >> to the hypervisor. Could you explain what the intention here
> >> >> was?
> >> >>
> >> >> And regardless of anything, can the literal numbers please be
> >> >> replaced by proper manifest constants - the "8" here already
> >> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
> >> >> proper symbolic would permit locating where this is being (or
> >> >> really, as it doesn't appear to work supposed to be) consumed
> >> >> in qemu, provided it uses the same definition (i.e. that one
> >> >> should go into one of the public headers).
> >> >
> >> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
> >> > because notifications are not supposed to be delivered as MSI anymore.
> >> >
> >> > This is what should happen:
> >> >
> >> > 1) Linux configures the device with a 0 vector number and the pirq number
> >> > in the address field;
> >> >
> >> > 2) QEMU notices a vector number of 0 and reads the pirq number from the
> >> > address field, passing it to xc_domain_update_msi_irq;
> >> >
> >> > 3) Xen assignes the given pirq to the physical MSI;
> >> >
> >> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
> >> >
> >> > 5) Xen sets the pirq as "IRQ_PT";
> >> >
> >> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_pirq
> >> > returns true so Xen calls send_guest_pirq instead.
> >> >
> >> >
> >> > Obviously 6) is not happening. hvm_domain_use_pirq is:
> >> >
> >> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND
> >> >
> >> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
> >> > above).
> >>
> >> This appears to be true. I added logging to hvm_pci_msi_assert in
> >> xen/drivers/passthrough/io.c and it indicates that
> >> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
> >> before an unsupported delivery mode message.
> >>
> >> I also log pirq->pirq but I found that most of the time I can't find
> >> this value anywhere else (I'm not sure how to interpret the value,
> >> though). For example, in my last try:
> >>
> >> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
> >> 53. The vast majority are for 54.
> >> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
> >> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
> >> Never for 54 or 53. It also gets called with pirq=49,emuirq=23 once
> >> but complains it's already mapped.
> >> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
> >> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
> >> 22, 52, 48, 47. Also never 54 or 53.
> >> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16, 17, 55.
> >> * The qemu log mentions pirq 35, 36 and 37
> >>
> >> It seems pirq values don't always mean the same? Is it a coincidence
> >> that 55 occurs almost everywhere, or is something going wrong with the
> >> other two values (53 and 54 versus 16 and 17)?
> >>
> >> I have three MSI capable devices passed through to the domU, and I do
> >> see groups of three distinct pirqs in the data above - just not the
> >> same ones in every place I look.
> >>
> >> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
> >> > (__startup_pirq doesn't get called), or Xen is erroring out in
> >> > map_domain_emuirq_pirq.
> >>
> >> evtchn_bind_pirq gets called, though I'm not sure if it is with the right data.
> >>
> >> map_domain_emuirq_pirq always gets past the checks in the top half
> >> (i.e. up to the line /* do not store emuirq mappings for pt devices
> >> */), except for one time with pirq=49,emuirq=23 where it finds they
> >> are already mapped.
> >> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
> >> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
> >> directly logged that but it's the only assignment there).
> >>
> >> Interestingly, I get an unsupported delivery mode error for pirq 55
> >> where my logging says pirq->arch.hvm.emuirq is -1, *after*
> >> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.
> >
> > Looking back at your QEMU logs, it seems that pt_msi_setup is not
> > called (or it is not called at the right time), otherwise you should
> > get:
> >
> > pt_msi_setup requested pirq = %d
> >
> > in your logs.
> > Could you try disabling msitranslate? You can do that adding
> >
> > pci_msitranslate=0
> >
> > to your VM config file.
> 
> I tried that, but it didn't work.
> 
> > If that works, probably this (untested) QEMU patch could fix your problem:
> >
> 
> I appreciate the help.
> 
> I applied the patch anyway just to see what would happen (had to edit
> a few dev versus d variable names) but it didn't help. It also breaks
> pt_msi_update, as I get in the qemu log:
> 
> pt_msi_update: Update msi with pirq 2f gvec 0 gflags 302f
> pt_msi_update: Error: Binding of MSI failed.
> pt_msi_update: Error: Unmapping of MSI failed.
> pt_msgctrl_reg_write: Warning: Can not bind MSI for dev 80
> 
> I added some logging to pt_msi_setup (without the patch). It does get
> called, and it does so rather early in the boot process, each time
> right before lines as these:
> 
> pci_intx: intx=1
> register_real_device: Real physical device 00:1b.0 registered successfuly!
> IRQ type = MSI-INTx
> 
> At this point dev->msi->data, addr_hi and addr_lo are all 0, which
> doesn't seem right. Is it being called prematurely?

That's because msitranslate is still enabled somehow, that is a
toolstack bug.
While we fix that bug, could you try this QEMU patch to forcefully disable
msitranslate?

diff --git a/xenstore.c b/xenstore.c
index ac90366..8af280e 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -427,7 +427,7 @@ uint32_t xenstore_read_target(void)
     return target_domid;
 }
 
-#define PT_PCI_MSITRANSLATE_DEFAULT 1
+#define PT_PCI_MSITRANSLATE_DEFAULT 0
 #define PT_PCI_POWER_MANAGEMENT_DEFAULT 0
 int direct_pci_msitranslate;
 int direct_pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:38:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1SjsRd-0008OM-Qe; Wed, 27 Jun 2012 13:38: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 1SjsRc-0008OF-4K
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:38:08 +0000
Received: from [85.158.139.83:21525] by server-10.bemta-5.messagelabs.com id
	20/29-02190-FBC0BEF4; Wed, 27 Jun 2012 13:38:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340804286!25821882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24463 invoked from network); 27 Jun 2012 13:38:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 13:38:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 14:38:06 +0100
Message-Id: <4FEB290B020000780008C3BB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 14:38:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3B1592FB.0__="
Subject: [Xen-devel] [PATCH] x86/hvm: increase struct hvm_vcpu_io's
 mmio_large_read[]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part3B1592FB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Since the emulator now supports a few 256-bit memory operations, this
array needs to follow (and the comments should, too).

To limit growth, re-order the mmio_large_write_* fields so that the
two mmio_large_*_bytes fields end up adjacent to each other.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -59,13 +59,13 @@ struct hvm_vcpu_io {
     unsigned long       mmio_gva;
     unsigned long       mmio_gpfn;
=20
-    /* We may read up to m128 as a number of device-model transactions. =
*/
+    /* We may read up to m256 as a number of device-model transactions. =
*/
     paddr_t mmio_large_read_pa;
-    uint8_t mmio_large_read[16];
+    uint8_t mmio_large_read[32];
     unsigned int mmio_large_read_bytes;
-    /* We may write up to m128 as a number of device-model transactions. =
*/
-    paddr_t mmio_large_write_pa;
+    /* We may write up to m256 as a number of device-model transactions. =
*/
     unsigned int mmio_large_write_bytes;
+    paddr_t mmio_large_write_pa;
 };
=20
 #define VMCX_EADDR    (~0ULL)




--=__Part3B1592FB.0__=
Content-Type: text/plain; name="x86-hvm-mmio-large-256bit.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-hvm-mmio-large-256bit.patch"

x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]=0A=0ASince the =
emulator now supports a few 256-bit memory operations, this=0Aarray needs =
to follow (and the comments should, too).=0A=0ATo limit growth, re-order =
the mmio_large_write_* fields so that the=0Atwo mmio_large_*_bytes fields =
end up adjacent to each other.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/include/asm-x86/hvm/vcpu.h=0A+++ b/xen/include/asm-x=
86/hvm/vcpu.h=0A@@ -59,13 +59,13 @@ struct hvm_vcpu_io {=0A     unsigned =
long       mmio_gva;=0A     unsigned long       mmio_gpfn;=0A =0A-    /* =
We may read up to m128 as a number of device-model transactions. */=0A+    =
/* We may read up to m256 as a number of device-model transactions. */=0A  =
   paddr_t mmio_large_read_pa;=0A-    uint8_t mmio_large_read[16];=0A+    =
uint8_t mmio_large_read[32];=0A     unsigned int mmio_large_read_bytes;=0A-=
    /* We may write up to m128 as a number of device-model transactions. =
*/=0A-    paddr_t mmio_large_write_pa;=0A+    /* We may write up to m256 =
as a number of device-model transactions. */=0A     unsigned int mmio_large=
_write_bytes;=0A+    paddr_t mmio_large_write_pa;=0A };=0A =0A #define =
VMCX_EADDR    (~0ULL)=0A
--=__Part3B1592FB.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

--=__Part3B1592FB.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 27 13:38:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1SjsRd-0008OM-Qe; Wed, 27 Jun 2012 13:38: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 1SjsRc-0008OF-4K
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:38:08 +0000
Received: from [85.158.139.83:21525] by server-10.bemta-5.messagelabs.com id
	20/29-02190-FBC0BEF4; Wed, 27 Jun 2012 13:38:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340804286!25821882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24463 invoked from network); 27 Jun 2012 13:38:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 13:38:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 14:38:06 +0100
Message-Id: <4FEB290B020000780008C3BB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 14:38:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3B1592FB.0__="
Subject: [Xen-devel] [PATCH] x86/hvm: increase struct hvm_vcpu_io's
 mmio_large_read[]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part3B1592FB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Since the emulator now supports a few 256-bit memory operations, this
array needs to follow (and the comments should, too).

To limit growth, re-order the mmio_large_write_* fields so that the
two mmio_large_*_bytes fields end up adjacent to each other.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -59,13 +59,13 @@ struct hvm_vcpu_io {
     unsigned long       mmio_gva;
     unsigned long       mmio_gpfn;
=20
-    /* We may read up to m128 as a number of device-model transactions. =
*/
+    /* We may read up to m256 as a number of device-model transactions. =
*/
     paddr_t mmio_large_read_pa;
-    uint8_t mmio_large_read[16];
+    uint8_t mmio_large_read[32];
     unsigned int mmio_large_read_bytes;
-    /* We may write up to m128 as a number of device-model transactions. =
*/
-    paddr_t mmio_large_write_pa;
+    /* We may write up to m256 as a number of device-model transactions. =
*/
     unsigned int mmio_large_write_bytes;
+    paddr_t mmio_large_write_pa;
 };
=20
 #define VMCX_EADDR    (~0ULL)




--=__Part3B1592FB.0__=
Content-Type: text/plain; name="x86-hvm-mmio-large-256bit.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-hvm-mmio-large-256bit.patch"

x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]=0A=0ASince the =
emulator now supports a few 256-bit memory operations, this=0Aarray needs =
to follow (and the comments should, too).=0A=0ATo limit growth, re-order =
the mmio_large_write_* fields so that the=0Atwo mmio_large_*_bytes fields =
end up adjacent to each other.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/include/asm-x86/hvm/vcpu.h=0A+++ b/xen/include/asm-x=
86/hvm/vcpu.h=0A@@ -59,13 +59,13 @@ struct hvm_vcpu_io {=0A     unsigned =
long       mmio_gva;=0A     unsigned long       mmio_gpfn;=0A =0A-    /* =
We may read up to m128 as a number of device-model transactions. */=0A+    =
/* We may read up to m256 as a number of device-model transactions. */=0A  =
   paddr_t mmio_large_read_pa;=0A-    uint8_t mmio_large_read[16];=0A+    =
uint8_t mmio_large_read[32];=0A     unsigned int mmio_large_read_bytes;=0A-=
    /* We may write up to m128 as a number of device-model transactions. =
*/=0A-    paddr_t mmio_large_write_pa;=0A+    /* We may write up to m256 =
as a number of device-model transactions. */=0A     unsigned int mmio_large=
_write_bytes;=0A+    paddr_t mmio_large_write_pa;=0A };=0A =0A #define =
VMCX_EADDR    (~0ULL)=0A
--=__Part3B1592FB.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

--=__Part3B1592FB.0__=--


From xen-devel-bounces@lists.xen.org Wed Jun 27 13:39:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:39: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 1SjsT1-0008VQ-F4; Wed, 27 Jun 2012 13: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 1SjsSz-0008VK-QV
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:39:33 +0000
Received: from [85.158.139.83:49845] by server-3.bemta-5.messagelabs.com id
	C0/A8-03367-41D0BEF4; Wed, 27 Jun 2012 13:39:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340804372!29692977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22081 invoked from network); 27 Jun 2012 13:39:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13247793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:39:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:39:32 +0100
Date: Wed, 27 Jun 2012 14:39:15 +0100
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.1206271436320.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate 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

msitranslate is known to cause problems with some device drivers,
because it sets the real device in MSI mode while making the guest think
is actually in legacy interrupts mode. Some drivers are able to spot this
inconsistency and break (Nvidia drivers for example).

Disable the option by default.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/xenstore.c b/xenstore.c
index ac90366..8af280e 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -427,7 +427,7 @@ uint32_t xenstore_read_target(void)
     return target_domid;
 }
 
-#define PT_PCI_MSITRANSLATE_DEFAULT 1
+#define PT_PCI_MSITRANSLATE_DEFAULT 0
 #define PT_PCI_POWER_MANAGEMENT_DEFAULT 0
 int direct_pci_msitranslate;
 int direct_pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:39:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:39: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 1SjsT1-0008VQ-F4; Wed, 27 Jun 2012 13: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 1SjsSz-0008VK-QV
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:39:33 +0000
Received: from [85.158.139.83:49845] by server-3.bemta-5.messagelabs.com id
	C0/A8-03367-41D0BEF4; Wed, 27 Jun 2012 13:39:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340804372!29692977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22081 invoked from network); 27 Jun 2012 13:39:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13247793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:39:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:39:32 +0100
Date: Wed, 27 Jun 2012 14:39:15 +0100
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.1206271436320.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate 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

msitranslate is known to cause problems with some device drivers,
because it sets the real device in MSI mode while making the guest think
is actually in legacy interrupts mode. Some drivers are able to spot this
inconsistency and break (Nvidia drivers for example).

Disable the option by default.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/xenstore.c b/xenstore.c
index ac90366..8af280e 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -427,7 +427,7 @@ uint32_t xenstore_read_target(void)
     return target_domid;
 }
 
-#define PT_PCI_MSITRANSLATE_DEFAULT 1
+#define PT_PCI_MSITRANSLATE_DEFAULT 0
 #define PT_PCI_POWER_MANAGEMENT_DEFAULT 0
 int direct_pci_msitranslate;
 int direct_pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1Sjsdu-0000LH-KG; Wed, 27 Jun 2012 13:50:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sjsds-0000LC-FZ
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:50:48 +0000
Received: from [193.109.254.147:11809] by server-4.bemta-14.messagelabs.com id
	40/03-02077-7BF0BEF4; Wed, 27 Jun 2012 13:50:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340805046!8894461!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28077 invoked from network); 27 Jun 2012 13:50:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13248192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:46:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:46:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjsZj-0007pS-FY; Wed, 27 Jun 2012 13:46:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjsZj-0004YU-Ei;
	Wed, 27 Jun 2012 14:46:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20459.3767.440030.931642@mariner.uk.xensource.com>
Date: Wed, 27 Jun 2012 14:46:31 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.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 v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> Ian,
>  The code segfaults. Here are the system details and error traces from gdb.

Thanks.

> My setup:
> 
> dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),
>            running latest xen-4.2-unstable (built from your repo)
>            tools stack also built from your repo (which I hope has all the latest patches).
> 
> domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version)
>            with suspend event channel support
> 
> As a sanity check, I tested xl remus with latest tip from xen-unstable
> mercurial repo, c/s: 25496:e08cf97e76f0
> 
> Blackhole replication (to /dev/null) and localhost replication worked as expected
> and the guest recovered properly without any issues.

Thanks for the test runes.  That didn't work entirely properly for
me, even with the xen-unstable baseline.

I did this
   xl -vvvv remus -b -i 100 debian.guest.osstest dummy >remus.log 2>&1 &
The result was that the guest's networking broke.  The guest shows up
in xl list as
   debian.guest.osstest                      7   512     1     ---ss-       5.2
and is still responsive on its pv console.  After I killed the remus
process, the guest's networking was still broken.

At the start, the guest prints this on its console:
  [   36.017241] WARNING: g.e. still in use!
  [   36.021056] WARNING: g.e. still in use!
  [   36.024740] WARNING: g.e. still in use!
  [   36.024763] WARNING: g.e. still in use!

If I try the rune with "localhost" I would have expected, surely, to
see a domain with the incoming migration ?  But I don't.  I tried
killing the `xl remus' process and the guest became wedged.


However, when I apply my series, I can indeed produce an assertion
failure:

 xc: detail: All memory is saved
 xc: error: Could not get domain info (3 = No such process): Internal error
 libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for domain 3077579968: No such process
 xl: libxl_event.c:1426: libxl__ao_inprogress_gc: Assertion `ao->magic == 0xA0FACE00ul' failed.

So I have indeed made matters worse.


> Blackhole replication:
> ================
> xl error:
> ----------
> xc: error: Could not get domain info (3 = No such process): Internal error
> libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for domain 4154075147<tel:4154075147>: No such process
> libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to open qemu save file ?8b: No such file or directory

I don't see that at all.

NB that PV guests may have a qemu for certain disk backends, or
consoles, depending on the configuration.  Can you show me your domain
config ?  Mine is below.

> I also ran xl in GDB to get a stack trace and hopefully some useful debug info.
> gdb traces: http://pastebin.com/7zFwFjW4

I get a different crash - see above.

> Localhost replication: Partial success, but xl still segfaults
>  dmesg shows
>  [ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp 00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]

I see exactly the same thing with `localhost' instead of `dummy'.  And
I see no incoming domain.

I will investigate the crash I see.  In the meantime can you try to
help me see why it doesn't work me even with the baseline ?

Thanks,
Ian.

#
# Configuration file for the Xen instance debian.guest.osstest, created
# by xen-tools 4.2 on Thu Apr  5 16:43:43 2012.
#

#
#  Kernel + memory size
#
#kernel      = '/boot/vmlinuz-2.6.32.57'
#ramdisk     = '/boot/initrd.img-2.6.32.57'

#bootloader = 'pygrub'
bootloader = '/root/strace-pygrub'


memory      = '512'

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'phy:/dev/bedbug/debian.guest.osstest-disk,xvda2,w',
                  'phy:/dev/bedbug/debian.guest.osstest-swap,xvda1,w',
              ]


#
#  Physical volumes
#


#
#  Hostname
#
name        = 'debian.guest.osstest'

#
#  Networking
#
#dhcp        = 'dhcp'
vif         = [ 'mac=5a:36:0e:26:00:01' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash='preserve'




vcpus = 1

extra='console=hvc0 earlyprintk=xen'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1Sjsdu-0000LH-KG; Wed, 27 Jun 2012 13:50:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sjsds-0000LC-FZ
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 13:50:48 +0000
Received: from [193.109.254.147:11809] by server-4.bemta-14.messagelabs.com id
	40/03-02077-7BF0BEF4; Wed, 27 Jun 2012 13:50:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340805046!8894461!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28077 invoked from network); 27 Jun 2012 13:50:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13248192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:46:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:46:31 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjsZj-0007pS-FY; Wed, 27 Jun 2012 13:46:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjsZj-0004YU-Ei;
	Wed, 27 Jun 2012 14:46:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20459.3767.440030.931642@mariner.uk.xensource.com>
Date: Wed, 27 Jun 2012 14:46:31 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.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 v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> Ian,
>  The code segfaults. Here are the system details and error traces from gdb.

Thanks.

> My setup:
> 
> dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),
>            running latest xen-4.2-unstable (built from your repo)
>            tools stack also built from your repo (which I hope has all the latest patches).
> 
> domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version)
>            with suspend event channel support
> 
> As a sanity check, I tested xl remus with latest tip from xen-unstable
> mercurial repo, c/s: 25496:e08cf97e76f0
> 
> Blackhole replication (to /dev/null) and localhost replication worked as expected
> and the guest recovered properly without any issues.

Thanks for the test runes.  That didn't work entirely properly for
me, even with the xen-unstable baseline.

I did this
   xl -vvvv remus -b -i 100 debian.guest.osstest dummy >remus.log 2>&1 &
The result was that the guest's networking broke.  The guest shows up
in xl list as
   debian.guest.osstest                      7   512     1     ---ss-       5.2
and is still responsive on its pv console.  After I killed the remus
process, the guest's networking was still broken.

At the start, the guest prints this on its console:
  [   36.017241] WARNING: g.e. still in use!
  [   36.021056] WARNING: g.e. still in use!
  [   36.024740] WARNING: g.e. still in use!
  [   36.024763] WARNING: g.e. still in use!

If I try the rune with "localhost" I would have expected, surely, to
see a domain with the incoming migration ?  But I don't.  I tried
killing the `xl remus' process and the guest became wedged.


However, when I apply my series, I can indeed produce an assertion
failure:

 xc: detail: All memory is saved
 xc: error: Could not get domain info (3 = No such process): Internal error
 libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for domain 3077579968: No such process
 xl: libxl_event.c:1426: libxl__ao_inprogress_gc: Assertion `ao->magic == 0xA0FACE00ul' failed.

So I have indeed made matters worse.


> Blackhole replication:
> ================
> xl error:
> ----------
> xc: error: Could not get domain info (3 = No such process): Internal error
> libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed for domain 4154075147<tel:4154075147>: No such process
> libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable to open qemu save file ?8b: No such file or directory

I don't see that at all.

NB that PV guests may have a qemu for certain disk backends, or
consoles, depending on the configuration.  Can you show me your domain
config ?  Mine is below.

> I also ran xl in GDB to get a stack trace and hopefully some useful debug info.
> gdb traces: http://pastebin.com/7zFwFjW4

I get a different crash - see above.

> Localhost replication: Partial success, but xl still segfaults
>  dmesg shows
>  [ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp 00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]

I see exactly the same thing with `localhost' instead of `dummy'.  And
I see no incoming domain.

I will investigate the crash I see.  In the meantime can you try to
help me see why it doesn't work me even with the baseline ?

Thanks,
Ian.

#
# Configuration file for the Xen instance debian.guest.osstest, created
# by xen-tools 4.2 on Thu Apr  5 16:43:43 2012.
#

#
#  Kernel + memory size
#
#kernel      = '/boot/vmlinuz-2.6.32.57'
#ramdisk     = '/boot/initrd.img-2.6.32.57'

#bootloader = 'pygrub'
bootloader = '/root/strace-pygrub'


memory      = '512'

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'phy:/dev/bedbug/debian.guest.osstest-disk,xvda2,w',
                  'phy:/dev/bedbug/debian.guest.osstest-swap,xvda1,w',
              ]


#
#  Physical volumes
#


#
#  Hostname
#
name        = 'debian.guest.osstest'

#
#  Networking
#
#dhcp        = 'dhcp'
vif         = [ 'mac=5a:36:0e:26:00:01' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash='preserve'




vcpus = 1

extra='console=hvc0 earlyprintk=xen'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:54:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1SjshA-0000RT-7g; Wed, 27 Jun 2012 13:54:12 +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 1Sjsh8-0000RH-TF
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:54:11 +0000
Received: from [85.158.139.83:60262] by server-11.bemta-5.messagelabs.com id
	40/5D-20400-2801BEF4; Wed, 27 Jun 2012 13:54:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340805249!29811939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2489 invoked from network); 27 Jun 2012 13:54:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:54:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13248485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:54:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:54:08 +0100
Date: Wed, 27 Jun 2012 14:53:52 +0100
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.1206271452190.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: do not ignore the per-device
 msitranslate and power_mgmt opts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ignore the per-device msitranslate and power_mgmt options: they
need to be appended to the bdf.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..d329fa6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -21,6 +21,7 @@
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
 #define PCI_BDF_VDEVFN         "%04x:%02x:%02x.%01x@%02x"
+#define PCI_OPTIONS            "msitranslate=%d,power_mgmt=%d"
 #define PCI_BDF_XSPATH         "%04x-%02x-%02x-%01x"
 
 static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev)
@@ -814,12 +815,14 @@ static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t domid,
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
                           domid);
     if (pcidev->vdevfn) {
-        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN,
+        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN","PCI_OPTIONS,
                         pcidev->domain, pcidev->bus, pcidev->dev,
-                        pcidev->func, pcidev->vdevfn);
+                        pcidev->func, pcidev->vdevfn, pcidev->msitranslate,
+                        pcidev->power_mgmt);
     } else {
-        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
-                        pcidev->bus, pcidev->dev, pcidev->func);
+        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF","PCI_OPTIONS,
+                        pcidev->domain,  pcidev->bus, pcidev->dev,
+                        pcidev->func, pcidev->msitranslate, pcidev->power_mgmt);
     }
 
     libxl__qemu_traditional_cmd(gc, domid, "pci-ins");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:54:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13: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 1SjshA-0000RT-7g; Wed, 27 Jun 2012 13:54:12 +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 1Sjsh8-0000RH-TF
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:54:11 +0000
Received: from [85.158.139.83:60262] by server-11.bemta-5.messagelabs.com id
	40/5D-20400-2801BEF4; Wed, 27 Jun 2012 13:54:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340805249!29811939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2489 invoked from network); 27 Jun 2012 13:54:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:54:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13248485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:54:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:54:08 +0100
Date: Wed, 27 Jun 2012 14:53:52 +0100
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.1206271452190.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: do not ignore the per-device
 msitranslate and power_mgmt opts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ignore the per-device msitranslate and power_mgmt options: they
need to be appended to the bdf.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index de1b79f..d329fa6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -21,6 +21,7 @@
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
 #define PCI_BDF_VDEVFN         "%04x:%02x:%02x.%01x@%02x"
+#define PCI_OPTIONS            "msitranslate=%d,power_mgmt=%d"
 #define PCI_BDF_XSPATH         "%04x-%02x-%02x-%01x"
 
 static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev)
@@ -814,12 +815,14 @@ static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t domid,
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
                           domid);
     if (pcidev->vdevfn) {
-        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN,
+        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN","PCI_OPTIONS,
                         pcidev->domain, pcidev->bus, pcidev->dev,
-                        pcidev->func, pcidev->vdevfn);
+                        pcidev->func, pcidev->vdevfn, pcidev->msitranslate,
+                        pcidev->power_mgmt);
     } else {
-        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
-                        pcidev->bus, pcidev->dev, pcidev->func);
+        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF","PCI_OPTIONS,
+                        pcidev->domain,  pcidev->bus, pcidev->dev,
+                        pcidev->func, pcidev->msitranslate, pcidev->power_mgmt);
     }
 
     libxl__qemu_traditional_cmd(gc, domid, "pci-ins");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:56:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:56: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 1SjsjN-0000Z2-Of; Wed, 27 Jun 2012 13:56:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SjsjM-0000Yu-ST
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:56:28 +0000
Received: from [85.158.143.99:21607] by server-1.bemta-4.messagelabs.com id
	A9/BD-24392-C011BEF4; Wed, 27 Jun 2012 13:56:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340805387!29368258!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26680 invoked from network); 27 Jun 2012 13:56:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:56:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13248557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:56:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:56:27 +0100
Date: Wed, 27 Jun 2012 14:56:11 +0100
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.1206271454210.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] libxl: disable msitranslate 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

msitranslate is known to cause problems with some device drivers,
because it sets the real device in MSI mode while making the guest think
is actually in legacy interrupts mode. Some drivers are able to spot this
inconsistency and break (Nvidia drivers for example).

Disable msitranslate by default.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index afa0af6..c80b9fb 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -562,7 +562,7 @@ static void parse_config_data(const char *config_source,
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
-    int pci_msitranslate = 1;
+    int pci_msitranslate = 0;
     int pci_permissive = 0;
     int e;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 13:56:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 13:56: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 1SjsjN-0000Z2-Of; Wed, 27 Jun 2012 13:56:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SjsjM-0000Yu-ST
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 13:56:28 +0000
Received: from [85.158.143.99:21607] by server-1.bemta-4.messagelabs.com id
	A9/BD-24392-C011BEF4; Wed, 27 Jun 2012 13:56:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340805387!29368258!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26680 invoked from network); 27 Jun 2012 13:56:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 13:56:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13248557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:56:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 14:56:27 +0100
Date: Wed, 27 Jun 2012 14:56:11 +0100
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.1206271454210.27860@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] libxl: disable msitranslate 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

msitranslate is known to cause problems with some device drivers,
because it sets the real device in MSI mode while making the guest think
is actually in legacy interrupts mode. Some drivers are able to spot this
inconsistency and break (Nvidia drivers for example).

Disable msitranslate by default.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index afa0af6..c80b9fb 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -562,7 +562,7 @@ static void parse_config_data(const char *config_source,
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
-    int pci_msitranslate = 1;
+    int pci_msitranslate = 0;
     int pci_permissive = 0;
     int e;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14: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 1Sjsy9-0000zB-SK; Wed, 27 Jun 2012 14:11:45 +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 1Sjsy8-0000z3-K4
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 14:11:44 +0000
Received: from [85.158.143.99:21808] by server-2.bemta-4.messagelabs.com id
	43/6F-17938-F941BEF4; Wed, 27 Jun 2012 14:11:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340806302!23019616!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16388 invoked from network); 27 Jun 2012 14:11:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:11:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200225408"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 09:55:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:55:44 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SjsV5-0007pq-Rd;
	Wed, 27 Jun 2012 14:41:43 +0100
Message-ID: <4FEB0D0E.8010509@eu.citrix.com>
Date: Wed, 27 Jun 2012 14:39:26 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206271436320.27860@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206271436320.27860@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate 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-Transfer-Encoding: 7bit
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/06/12 14:39, Stefano Stabellini wrote:
> msitranslate is known to cause problems with some device drivers,
> because it sets the real device in MSI mode while making the guest think
> is actually in legacy interrupts mode. Some drivers are able to spot this
> inconsistency and break (Nvidia drivers for example).
>
> Disable the option by default.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
This patch has been in XenServer for two releases now.

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 Wed Jun 27 14:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14: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 1Sjsy9-0000zB-SK; Wed, 27 Jun 2012 14:11:45 +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 1Sjsy8-0000z3-K4
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 14:11:44 +0000
Received: from [85.158.143.99:21808] by server-2.bemta-4.messagelabs.com id
	43/6F-17938-F941BEF4; Wed, 27 Jun 2012 14:11:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340806302!23019616!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16388 invoked from network); 27 Jun 2012 14:11:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:11:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200225408"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 09:55:44 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 09:55:44 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SjsV5-0007pq-Rd;
	Wed, 27 Jun 2012 14:41:43 +0100
Message-ID: <4FEB0D0E.8010509@eu.citrix.com>
Date: Wed, 27 Jun 2012 14:39:26 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1206271436320.27860@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1206271436320.27860@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate 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-Transfer-Encoding: 7bit
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/06/12 14:39, Stefano Stabellini wrote:
> msitranslate is known to cause problems with some device drivers,
> because it sets the real device in MSI mode while making the guest think
> is actually in legacy interrupts mode. Some drivers are able to spot this
> inconsistency and break (Nvidia drivers for example).
>
> Disable the option by default.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
This patch has been in XenServer for two releases now.

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 Wed Jun 27 14:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14: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 1SjtZO-0001Tj-Pj; Wed, 27 Jun 2012 14:50:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SjtZM-0001Tb-Ps
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 14:50:13 +0000
Received: from [85.158.143.99:23055] by server-2.bemta-4.messagelabs.com id
	29/79-17938-4AD1BEF4; Wed, 27 Jun 2012 14:50:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340808610!28828334!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2570 invoked from network); 27 Jun 2012 14:50:11 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:50:11 -0000
Received: by eaak12 with SMTP id k12so480110eaa.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 07:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JR/wwNAcJYtZMZU/N3yJs7m6K+mC6WkM0fKSWE9DvEM=;
	b=bWcm4Eu8PCNi1cOTbLPTAxnxCaJih93hQTiE3YxF9j8Xqxy+55uVeOoZyTvgyK2sNK
	SBtizKhuv4pplyy2c8PXYA6PxRzichA0mYH2eb/laDEUUSbT4RWg+iZFVEPOWs1p1V8b
	RkNLKqwYX+m53a2g6vRb5J7IOmvOmjrAaKZjVZHmihiF8SOX+ehgOQoedJe7rpGt0/I0
	ZLBnUe86y836mPpmBI86tKxvJUStIXAteI/ZgvTrBZsCa+ei6wJX91x2IH4yusZHIUtV
	6Kz+9ekMzqzrx7lwUPYXvcasif1Atjmftui/PiwsujlMl9YlMYfyIz53Wse6HhMFrrg2
	glJw==
Received: by 10.14.22.15 with SMTP id s15mr3896499ees.88.1340808609589;
	Wed, 27 Jun 2012 07:50:09 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	y54sm159902116eef.10.2012.06.27.07.50.07
	(version=SSLv3 cipher=OTHER); Wed, 27 Jun 2012 07:50:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 27 Jun 2012 15:50:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC10DC29.36A99%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: increase struct hvm_vcpu_io's
	mmio_large_read[]
Thread-Index: Ac1UdCD8zUotw42i9kKToGdVC98Dww==
In-Reply-To: <4FEB290B020000780008C3BB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/hvm: increase struct hvm_vcpu_io's
 mmio_large_read[]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 14:38, "Jan Beulich" <JBeulich@suse.com> wrote:

> Since the emulator now supports a few 256-bit memory operations, this
> array needs to follow (and the comments should, too).
> 
> To limit growth, re-order the mmio_large_write_* fields so that the
> two mmio_large_*_bytes fields end up adjacent to each other.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -59,13 +59,13 @@ struct hvm_vcpu_io {
>      unsigned long       mmio_gva;
>      unsigned long       mmio_gpfn;
>  
> -    /* We may read up to m128 as a number of device-model transactions. */
> +    /* We may read up to m256 as a number of device-model transactions. */
>      paddr_t mmio_large_read_pa;
> -    uint8_t mmio_large_read[16];
> +    uint8_t mmio_large_read[32];
>      unsigned int mmio_large_read_bytes;
> -    /* We may write up to m128 as a number of device-model transactions. */
> -    paddr_t mmio_large_write_pa;
> +    /* We may write up to m256 as a number of device-model transactions. */
>      unsigned int mmio_large_write_bytes;
> +    paddr_t mmio_large_write_pa;
>  };
>  
>  #define VMCX_EADDR    (~0ULL)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 27 14:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14: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 1SjtZO-0001Tj-Pj; Wed, 27 Jun 2012 14:50:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SjtZM-0001Tb-Ps
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 14:50:13 +0000
Received: from [85.158.143.99:23055] by server-2.bemta-4.messagelabs.com id
	29/79-17938-4AD1BEF4; Wed, 27 Jun 2012 14:50:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340808610!28828334!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2570 invoked from network); 27 Jun 2012 14:50:11 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:50:11 -0000
Received: by eaak12 with SMTP id k12so480110eaa.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 07:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JR/wwNAcJYtZMZU/N3yJs7m6K+mC6WkM0fKSWE9DvEM=;
	b=bWcm4Eu8PCNi1cOTbLPTAxnxCaJih93hQTiE3YxF9j8Xqxy+55uVeOoZyTvgyK2sNK
	SBtizKhuv4pplyy2c8PXYA6PxRzichA0mYH2eb/laDEUUSbT4RWg+iZFVEPOWs1p1V8b
	RkNLKqwYX+m53a2g6vRb5J7IOmvOmjrAaKZjVZHmihiF8SOX+ehgOQoedJe7rpGt0/I0
	ZLBnUe86y836mPpmBI86tKxvJUStIXAteI/ZgvTrBZsCa+ei6wJX91x2IH4yusZHIUtV
	6Kz+9ekMzqzrx7lwUPYXvcasif1Atjmftui/PiwsujlMl9YlMYfyIz53Wse6HhMFrrg2
	glJw==
Received: by 10.14.22.15 with SMTP id s15mr3896499ees.88.1340808609589;
	Wed, 27 Jun 2012 07:50:09 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	y54sm159902116eef.10.2012.06.27.07.50.07
	(version=SSLv3 cipher=OTHER); Wed, 27 Jun 2012 07:50:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 27 Jun 2012 15:50:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC10DC29.36A99%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: increase struct hvm_vcpu_io's
	mmio_large_read[]
Thread-Index: Ac1UdCD8zUotw42i9kKToGdVC98Dww==
In-Reply-To: <4FEB290B020000780008C3BB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/hvm: increase struct hvm_vcpu_io's
 mmio_large_read[]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 14:38, "Jan Beulich" <JBeulich@suse.com> wrote:

> Since the emulator now supports a few 256-bit memory operations, this
> array needs to follow (and the comments should, too).
> 
> To limit growth, re-order the mmio_large_write_* fields so that the
> two mmio_large_*_bytes fields end up adjacent to each other.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -59,13 +59,13 @@ struct hvm_vcpu_io {
>      unsigned long       mmio_gva;
>      unsigned long       mmio_gpfn;
>  
> -    /* We may read up to m128 as a number of device-model transactions. */
> +    /* We may read up to m256 as a number of device-model transactions. */
>      paddr_t mmio_large_read_pa;
> -    uint8_t mmio_large_read[16];
> +    uint8_t mmio_large_read[32];
>      unsigned int mmio_large_read_bytes;
> -    /* We may write up to m128 as a number of device-model transactions. */
> -    paddr_t mmio_large_write_pa;
> +    /* We may write up to m256 as a number of device-model transactions. */
>      unsigned int mmio_large_write_bytes;
> +    paddr_t mmio_large_write_pa;
>  };
>  
>  #define VMCX_EADDR    (~0ULL)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 27 14:53:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjtc9-0001ZA-Bo; Wed, 27 Jun 2012 14:53:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjtc8-0001Z5-NO
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 14:53:04 +0000
Received: from [85.158.138.51:62721] by server-7.bemta-3.messagelabs.com id
	E4/82-10113-A4E1BEF4; Wed, 27 Jun 2012 14:52:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340808777!26925094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19551 invoked from network); 27 Jun 2012 14:52:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 14:52:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:52:57 +0100
Message-ID: <1340808775.29172.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Jun 2012 15:52:55 +0100
In-Reply-To: <4FEB22DF020000780008C389@nat28.tlf.novell.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, blockers:
> > 
> >     * None
> 
> We should evaluate whether getting the vMCE interface into a
> sane state ought to be treated as a blocker (see Jinsong's
> recent posting about their design work). Otherwise we'll run
> into yet another round of compatibility issues when moving on
> to 4.3, particularly with respect to migration.

Isn't this way to late for 4.2 if it's only at the design stage right
now?

Does vMCE exist in Xen unstable today? Did it exist in 4.1?

I think we'll need to just suck it up and accept that migration needs
handling for 4.3.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:53:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14:53:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjtc9-0001ZA-Bo; Wed, 27 Jun 2012 14:53:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Sjtc8-0001Z5-NO
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 14:53:04 +0000
Received: from [85.158.138.51:62721] by server-7.bemta-3.messagelabs.com id
	E4/82-10113-A4E1BEF4; Wed, 27 Jun 2012 14:52:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340808777!26925094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19551 invoked from network); 27 Jun 2012 14:52:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 14:52:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:52:57 +0100
Message-ID: <1340808775.29172.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Jun 2012 15:52:55 +0100
In-Reply-To: <4FEB22DF020000780008C389@nat28.tlf.novell.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, blockers:
> > 
> >     * None
> 
> We should evaluate whether getting the vMCE interface into a
> sane state ought to be treated as a blocker (see Jinsong's
> recent posting about their design work). Otherwise we'll run
> into yet another round of compatibility issues when moving on
> to 4.3, particularly with respect to migration.

Isn't this way to late for 4.2 if it's only at the design stage right
now?

Does vMCE exist in Xen unstable today? Did it exist in 4.1?

I think we'll need to just suck it up and accept that migration needs
handling for 4.3.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:56:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14:56: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 1SjtfJ-0001kp-Lm; Wed, 27 Jun 2012 14:56: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 1SjtfH-0001kV-LZ
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 14:56:19 +0000
Received: from [85.158.143.99:38232] by server-3.bemta-4.messagelabs.com id
	88/0A-05808-21F1BEF4; Wed, 27 Jun 2012 14:56:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340808977!29085212!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27145 invoked from network); 27 Jun 2012 14:56:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	27 Jun 2012 14:56:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 15:56:17 +0100
Message-Id: <4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 15:57:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
	<1340808775.29172.38.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340808775.29172.38.camel@zakaz.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 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
>> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > hypervisor, blockers:
>> > 
>> >     * None
>> 
>> We should evaluate whether getting the vMCE interface into a
>> sane state ought to be treated as a blocker (see Jinsong's
>> recent posting about their design work). Otherwise we'll run
>> into yet another round of compatibility issues when moving on
>> to 4.3, particularly with respect to migration.
> 
> Isn't this way to late for 4.2 if it's only at the design stage right
> now?

That's why I'm bringing this up.

> Does vMCE exist in Xen unstable today? Did it exist in 4.1?

Yes. And what information get migrated is different between
4.1 and 4.2 already.

> I think we'll need to just suck it up and accept that migration needs
> handling for 4.3.

I was hoping to have at least the HVM save records in 4.2 in a
state suitable for 4.3.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:56:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14:56: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 1SjtfJ-0001kp-Lm; Wed, 27 Jun 2012 14:56: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 1SjtfH-0001kV-LZ
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 14:56:19 +0000
Received: from [85.158.143.99:38232] by server-3.bemta-4.messagelabs.com id
	88/0A-05808-21F1BEF4; Wed, 27 Jun 2012 14:56:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340808977!29085212!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27145 invoked from network); 27 Jun 2012 14:56:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	27 Jun 2012 14:56:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 15:56:17 +0100
Message-Id: <4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 15:57:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
	<1340808775.29172.38.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340808775.29172.38.camel@zakaz.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 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
>> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > hypervisor, blockers:
>> > 
>> >     * None
>> 
>> We should evaluate whether getting the vMCE interface into a
>> sane state ought to be treated as a blocker (see Jinsong's
>> recent posting about their design work). Otherwise we'll run
>> into yet another round of compatibility issues when moving on
>> to 4.3, particularly with respect to migration.
> 
> Isn't this way to late for 4.2 if it's only at the design stage right
> now?

That's why I'm bringing this up.

> Does vMCE exist in Xen unstable today? Did it exist in 4.1?

Yes. And what information get migrated is different between
4.1 and 4.2 already.

> I think we'll need to just suck it up and accept that migration needs
> handling for 4.3.

I was hoping to have at least the HVM save records in 4.2 in a
state suitable for 4.3.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:59:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14: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 1Sjti0-00022j-D8; Wed, 27 Jun 2012 14:59: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 1Sjthy-00022T-Rf
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 14:59:07 +0000
Received: from [85.158.138.51:26850] by server-2.bemta-3.messagelabs.com id
	68/A3-10266-ABF1BEF4; Wed, 27 Jun 2012 14:59:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340809145!21661920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26259 invoked from network); 27 Jun 2012 14:59:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 14:59:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:59:04 +0100
Message-ID: <1340809143.29172.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 15:59:03 +0100
In-Reply-To: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 14:56 +0100, Stefano Stabellini wrote:
> msitranslate is known to cause problems with some device drivers,
> because it sets the real device in MSI mode while making the guest think
> is actually in legacy interrupts mode. Some drivers are able to spot this
> inconsistency and break (Nvidia drivers for example).
> 
> Disable msitranslate by default.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I saw a qemu (trad) patch and I see I've got an xl patch further down my
inbox. There is no sequencing requirement here, is there?

I wonder if this field shouyld be a defbool instead of just a bool? I
don't recall why I didn't transition it when I made the defbool stuff.

> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index afa0af6..c80b9fb 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -562,7 +562,7 @@ static void parse_config_data(const char *config_source,
>      XLU_Config *config;
>      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
> -    int pci_msitranslate = 1;
> +    int pci_msitranslate = 0;
>      int pci_permissive = 0;
>      int e;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:59:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14: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 1Sjti0-00022j-D8; Wed, 27 Jun 2012 14:59: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 1Sjthy-00022T-Rf
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 14:59:07 +0000
Received: from [85.158.138.51:26850] by server-2.bemta-3.messagelabs.com id
	68/A3-10266-ABF1BEF4; Wed, 27 Jun 2012 14:59:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340809145!21661920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26259 invoked from network); 27 Jun 2012 14:59:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 14:59:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:59:04 +0100
Message-ID: <1340809143.29172.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 15:59:03 +0100
In-Reply-To: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 14:56 +0100, Stefano Stabellini wrote:
> msitranslate is known to cause problems with some device drivers,
> because it sets the real device in MSI mode while making the guest think
> is actually in legacy interrupts mode. Some drivers are able to spot this
> inconsistency and break (Nvidia drivers for example).
> 
> Disable msitranslate by default.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I saw a qemu (trad) patch and I see I've got an xl patch further down my
inbox. There is no sequencing requirement here, is there?

I wonder if this field shouyld be a defbool instead of just a bool? I
don't recall why I didn't transition it when I made the defbool stuff.

> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index afa0af6..c80b9fb 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -562,7 +562,7 @@ static void parse_config_data(const char *config_source,
>      XLU_Config *config;
>      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
> -    int pci_msitranslate = 1;
> +    int pci_msitranslate = 0;
>      int pci_permissive = 0;
>      int e;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:59:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14:59: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 1SjtiX-00026z-Qg; Wed, 27 Jun 2012 14:59: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 1SjtiW-00026h-Ig
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 14:59:40 +0000
Received: from [193.109.254.147:16378] by server-3.bemta-14.messagelabs.com id
	10/23-08687-BDF1BEF4; Wed, 27 Jun 2012 14:59:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340809178!8799562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27298 invoked from network); 27 Jun 2012 14:59:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 14:59:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:59:37 +0100
Message-ID: <1340809176.29172.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 15:59:36 +0100
In-Reply-To: <alpine.DEB.2.02.1206271452190.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271452190.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: do not ignore the per-device
 msitranslate and power_mgmt opts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 14:53 +0100, Stefano Stabellini wrote:
> Do not ignore the per-device msitranslate and power_mgmt options: they
> need to be appended to the bdf.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index de1b79f..d329fa6 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -21,6 +21,7 @@
>  #define PCI_BDF                "%04x:%02x:%02x.%01x"
>  #define PCI_BDF_SHORT          "%02x:%02x.%01x"
>  #define PCI_BDF_VDEVFN         "%04x:%02x:%02x.%01x@%02x"
> +#define PCI_OPTIONS            "msitranslate=%d,power_mgmt=%d"
>  #define PCI_BDF_XSPATH         "%04x-%02x-%02x-%01x"
>  
>  static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev)
> @@ -814,12 +815,14 @@ static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t domid,
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
>                            domid);
>      if (pcidev->vdevfn) {
> -        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN,
> +        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN","PCI_OPTIONS,
>                          pcidev->domain, pcidev->bus, pcidev->dev,
> -                        pcidev->func, pcidev->vdevfn);
> +                        pcidev->func, pcidev->vdevfn, pcidev->msitranslate,
> +                        pcidev->power_mgmt);
>      } else {
> -        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
> -                        pcidev->bus, pcidev->dev, pcidev->func);
> +        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF","PCI_OPTIONS,
> +                        pcidev->domain,  pcidev->bus, pcidev->dev,
> +                        pcidev->func, pcidev->msitranslate, pcidev->power_mgmt);
>      }
>  
>      libxl__qemu_traditional_cmd(gc, domid, "pci-ins");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 14:59:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 14:59: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 1SjtiX-00026z-Qg; Wed, 27 Jun 2012 14:59: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 1SjtiW-00026h-Ig
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 14:59:40 +0000
Received: from [193.109.254.147:16378] by server-3.bemta-14.messagelabs.com id
	10/23-08687-BDF1BEF4; Wed, 27 Jun 2012 14:59:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340809178!8799562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27298 invoked from network); 27 Jun 2012 14:59:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 14:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 14:59:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:59:37 +0100
Message-ID: <1340809176.29172.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Jun 2012 15:59:36 +0100
In-Reply-To: <alpine.DEB.2.02.1206271452190.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271452190.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: do not ignore the per-device
 msitranslate and power_mgmt opts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 14:53 +0100, Stefano Stabellini wrote:
> Do not ignore the per-device msitranslate and power_mgmt options: they
> need to be appended to the bdf.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index de1b79f..d329fa6 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -21,6 +21,7 @@
>  #define PCI_BDF                "%04x:%02x:%02x.%01x"
>  #define PCI_BDF_SHORT          "%02x:%02x.%01x"
>  #define PCI_BDF_VDEVFN         "%04x:%02x:%02x.%01x@%02x"
> +#define PCI_OPTIONS            "msitranslate=%d,power_mgmt=%d"
>  #define PCI_BDF_XSPATH         "%04x-%02x-%02x-%01x"
>  
>  static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev)
> @@ -814,12 +815,14 @@ static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t domid,
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
>                            domid);
>      if (pcidev->vdevfn) {
> -        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN,
> +        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF_VDEVFN","PCI_OPTIONS,
>                          pcidev->domain, pcidev->bus, pcidev->dev,
> -                        pcidev->func, pcidev->vdevfn);
> +                        pcidev->func, pcidev->vdevfn, pcidev->msitranslate,
> +                        pcidev->power_mgmt);
>      } else {
> -        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
> -                        pcidev->bus, pcidev->dev, pcidev->func);
> +        libxl__xs_write(gc, XBT_NULL, path, PCI_BDF","PCI_OPTIONS,
> +                        pcidev->domain,  pcidev->bus, pcidev->dev,
> +                        pcidev->func, pcidev->msitranslate, pcidev->power_mgmt);
>      }
>  
>      libxl__qemu_traditional_cmd(gc, domid, "pci-ins");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 15:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjtkn-0002QD-D8; Wed, 27 Jun 2012 15:02: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 1Sjtkl-0002Pu-Qm
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 15:02:00 +0000
Received: from [85.158.138.51:51921] by server-3.bemta-3.messagelabs.com id
	4D/FF-26490-2602BEF4; Wed, 27 Jun 2012 15:01:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340809310!28714274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22473 invoked from network); 27 Jun 2012 15:01:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:01:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:01:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 16:01:49 +0100
Message-ID: <1340809307.29172.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Jun 2012 16:01:47 +0100
In-Reply-To: <4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
	<1340808775.29172.38.camel@zakaz.uk.xensource.com>
	<4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 15:57 +0100, Jan Beulich wrote:
> >>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
> >> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > hypervisor, blockers:
> >> > 
> >> >     * None
> >> 
> >> We should evaluate whether getting the vMCE interface into a
> >> sane state ought to be treated as a blocker (see Jinsong's
> >> recent posting about their design work). Otherwise we'll run
> >> into yet another round of compatibility issues when moving on
> >> to 4.3, particularly with respect to migration.
> > 
> > Isn't this way to late for 4.2 if it's only at the design stage right
> > now?
> 
> That's why I'm bringing this up.
> 
> > Does vMCE exist in Xen unstable today? Did it exist in 4.1?
> 
> Yes. And what information get migrated is different between
> 4.1 and 4.2 already.
> 
> > I think we'll need to just suck it up and accept that migration needs
> > handling for 4.3.
> 
> I was hoping to have at least the HVM save records in 4.2 in a
> state suitable for 4.3.

That might be reasonable, I guess it depends what that looks like and
how much real code impact as opposed to just save record it has?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:02:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 15:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjtkn-0002QD-D8; Wed, 27 Jun 2012 15:02: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 1Sjtkl-0002Pu-Qm
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 15:02:00 +0000
Received: from [85.158.138.51:51921] by server-3.bemta-3.messagelabs.com id
	4D/FF-26490-2602BEF4; Wed, 27 Jun 2012 15:01:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340809310!28714274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22473 invoked from network); 27 Jun 2012 15:01:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:01:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13250434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:01:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 16:01:49 +0100
Message-ID: <1340809307.29172.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Jun 2012 16:01:47 +0100
In-Reply-To: <4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
	<1340808775.29172.38.camel@zakaz.uk.xensource.com>
	<4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-06-27 at 15:57 +0100, Jan Beulich wrote:
> >>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
> >> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > hypervisor, blockers:
> >> > 
> >> >     * None
> >> 
> >> We should evaluate whether getting the vMCE interface into a
> >> sane state ought to be treated as a blocker (see Jinsong's
> >> recent posting about their design work). Otherwise we'll run
> >> into yet another round of compatibility issues when moving on
> >> to 4.3, particularly with respect to migration.
> > 
> > Isn't this way to late for 4.2 if it's only at the design stage right
> > now?
> 
> That's why I'm bringing this up.
> 
> > Does vMCE exist in Xen unstable today? Did it exist in 4.1?
> 
> Yes. And what information get migrated is different between
> 4.1 and 4.2 already.
> 
> > I think we'll need to just suck it up and accept that migration needs
> > handling for 4.3.
> 
> I was hoping to have at least the HVM save records in 4.2 in a
> state suitable for 4.3.

That might be reasonable, I guess it depends what that looks like and
how much real code impact as opposed to just save record it has?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:26:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1Sju8K-0003HC-5i; Wed, 27 Jun 2012 15:26:20 +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 1Sju8I-0003H6-Pn
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 15:26:19 +0000
Received: from [85.158.138.51:47569] by server-9.bemta-3.messagelabs.com id
	A8/B5-10419-5162BEF4; Wed, 27 Jun 2012 15:26:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340810773!23473583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19729 invoked from network); 27 Jun 2012 15:26:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:26:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13251056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:26:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 16:26:12 +0100
Date: Wed, 27 Jun 2012 16:25:56 +0100
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: <1340809143.29172.40.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271625280.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
	<1340809143.29172.40.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 27 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-27 at 14:56 +0100, Stefano Stabellini wrote:
> > msitranslate is known to cause problems with some device drivers,
> > because it sets the real device in MSI mode while making the guest think
> > is actually in legacy interrupts mode. Some drivers are able to spot this
> > inconsistency and break (Nvidia drivers for example).
> > 
> > Disable msitranslate by default.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I saw a qemu (trad) patch and I see I've got an xl patch further down my
> inbox. There is no sequencing requirement here, is there?

nope

> I wonder if this field shouyld be a defbool instead of just a bool? I
> don't recall why I didn't transition it when I made the defbool stuff.

I think it could be a defbool

> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index afa0af6..c80b9fb 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -562,7 +562,7 @@ static void parse_config_data(const char *config_source,
> >      XLU_Config *config;
> >      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> >      int pci_power_mgmt = 0;
> > -    int pci_msitranslate = 1;
> > +    int pci_msitranslate = 0;
> >      int pci_permissive = 0;
> >      int e;
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:26:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1Sju8K-0003HC-5i; Wed, 27 Jun 2012 15:26:20 +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 1Sju8I-0003H6-Pn
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 15:26:19 +0000
Received: from [85.158.138.51:47569] by server-9.bemta-3.messagelabs.com id
	A8/B5-10419-5162BEF4; Wed, 27 Jun 2012 15:26:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340810773!23473583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19729 invoked from network); 27 Jun 2012 15:26:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:26:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13251056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:26:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 16:26:12 +0100
Date: Wed, 27 Jun 2012 16:25:56 +0100
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: <1340809143.29172.40.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206271625280.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
	<1340809143.29172.40.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 27 Jun 2012, Ian Campbell wrote:
> On Wed, 2012-06-27 at 14:56 +0100, Stefano Stabellini wrote:
> > msitranslate is known to cause problems with some device drivers,
> > because it sets the real device in MSI mode while making the guest think
> > is actually in legacy interrupts mode. Some drivers are able to spot this
> > inconsistency and break (Nvidia drivers for example).
> > 
> > Disable msitranslate by default.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I saw a qemu (trad) patch and I see I've got an xl patch further down my
> inbox. There is no sequencing requirement here, is there?

nope

> I wonder if this field shouyld be a defbool instead of just a bool? I
> don't recall why I didn't transition it when I made the defbool stuff.

I think it could be a defbool

> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index afa0af6..c80b9fb 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -562,7 +562,7 @@ static void parse_config_data(const char *config_source,
> >      XLU_Config *config;
> >      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> >      int pci_power_mgmt = 0;
> > -    int pci_msitranslate = 1;
> > +    int pci_msitranslate = 0;
> >      int pci_permissive = 0;
> >      int e;
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:28:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1SjuAE-0003Mq-M8; Wed, 27 Jun 2012 15:28: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 1SjuAC-0003Mf-8S
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 15:28:16 +0000
Received: from [85.158.139.83:56095] by server-4.bemta-5.messagelabs.com id
	3E/96-27831-F862BEF4; Wed, 27 Jun 2012 15:28:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340810894!22452146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6016 invoked from network); 27 Jun 2012 15:28:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13251102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:28:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 16:28:13 +0100
Message-ID: <1340810891.29172.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 27 Jun 2012 16:28:11 +0100
In-Reply-To: <CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 20:06:39 2012 +0800
> @@ -1256,7 +1256,10 @@ skip_vfb:
>  #undef parse_extra_args
> 
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +            if (l)
> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;

I think this needs to be:
          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;

so that both "stdvga=0" and "stdvga=1" result in what the user asked for
without relying on the libxl default remaining CIRRUS.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:28:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1SjuAE-0003Mq-M8; Wed, 27 Jun 2012 15:28: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 1SjuAC-0003Mf-8S
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 15:28:16 +0000
Received: from [85.158.139.83:56095] by server-4.bemta-5.messagelabs.com id
	3E/96-27831-F862BEF4; Wed, 27 Jun 2012 15:28:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340810894!22452146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6016 invoked from network); 27 Jun 2012 15:28:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13251102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:28:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 16:28:13 +0100
Message-ID: <1340810891.29172.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Wed, 27 Jun 2012 16:28:11 +0100
In-Reply-To: <CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 20:06:39 2012 +0800
> @@ -1256,7 +1256,10 @@ skip_vfb:
>  #undef parse_extra_args
> 
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +            if (l)
> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;

I think this needs to be:
          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;

so that both "stdvga=0" and "stdvga=1" result in what the user asked for
without relying on the libxl default remaining CIRRUS.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:36:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 15: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 1SjuHp-0003ai-6P; Wed, 27 Jun 2012 15:36: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 1SjuHn-0003ac-1P
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 15:36:07 +0000
Received: from [193.109.254.147:29768] by server-10.bemta-14.messagelabs.com
	id 91/41-05433-6682BEF4; Wed, 27 Jun 2012 15:36:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340811360!8862099!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30696 invoked from network); 27 Jun 2012 15:36:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	27 Jun 2012 15:36:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 16:35:59 +0100
Message-Id: <4FEB44AB020000780008C45D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 16:36:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
	<1340808775.29172.38.camel@zakaz.uk.xensource.com>
	<4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
	<1340809307.29172.43.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340809307.29172.43.camel@zakaz.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 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.06.12 at 17:01, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-27 at 15:57 +0100, Jan Beulich wrote:
>> >>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
>> >> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > hypervisor, blockers:
>> >> > 
>> >> >     * None
>> >> 
>> >> We should evaluate whether getting the vMCE interface into a
>> >> sane state ought to be treated as a blocker (see Jinsong's
>> >> recent posting about their design work). Otherwise we'll run
>> >> into yet another round of compatibility issues when moving on
>> >> to 4.3, particularly with respect to migration.
>> > 
>> > Isn't this way to late for 4.2 if it's only at the design stage right
>> > now?
>> 
>> That's why I'm bringing this up.
>> 
>> > Does vMCE exist in Xen unstable today? Did it exist in 4.1?
>> 
>> Yes. And what information get migrated is different between
>> 4.1 and 4.2 already.
>> 
>> > I think we'll need to just suck it up and accept that migration needs
>> > handling for 4.3.
>> 
>> I was hoping to have at least the HVM save records in 4.2 in a
>> state suitable for 4.3.
> 
> That might be reasonable, I guess it depends what that looks like and
> how much real code impact as opposed to just save record it has?

Certainly. Minimally, code handling the expected to be extended
save record would need to be added though.

In any case, I'd appreciate if you could add this at least to the
nice-to-have section.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:36:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 15: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 1SjuHp-0003ai-6P; Wed, 27 Jun 2012 15:36: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 1SjuHn-0003ac-1P
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 15:36:07 +0000
Received: from [193.109.254.147:29768] by server-10.bemta-14.messagelabs.com
	id 91/41-05433-6682BEF4; Wed, 27 Jun 2012 15:36:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1340811360!8862099!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2OTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30696 invoked from network); 27 Jun 2012 15:36:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	27 Jun 2012 15:36:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Jun 2012 16:35:59 +0100
Message-Id: <4FEB44AB020000780008C45D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 27 Jun 2012 16:36:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<4FEB22DF020000780008C389@nat28.tlf.novell.com>
	<1340808775.29172.38.camel@zakaz.uk.xensource.com>
	<4FEB3B5F020000780008C41E@nat28.tlf.novell.com>
	<1340809307.29172.43.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340809307.29172.43.camel@zakaz.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 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.06.12 at 17:01, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-06-27 at 15:57 +0100, Jan Beulich wrote:
>> >>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:
>> >> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > hypervisor, blockers:
>> >> > 
>> >> >     * None
>> >> 
>> >> We should evaluate whether getting the vMCE interface into a
>> >> sane state ought to be treated as a blocker (see Jinsong's
>> >> recent posting about their design work). Otherwise we'll run
>> >> into yet another round of compatibility issues when moving on
>> >> to 4.3, particularly with respect to migration.
>> > 
>> > Isn't this way to late for 4.2 if it's only at the design stage right
>> > now?
>> 
>> That's why I'm bringing this up.
>> 
>> > Does vMCE exist in Xen unstable today? Did it exist in 4.1?
>> 
>> Yes. And what information get migrated is different between
>> 4.1 and 4.2 already.
>> 
>> > I think we'll need to just suck it up and accept that migration needs
>> > handling for 4.3.
>> 
>> I was hoping to have at least the HVM save records in 4.2 in a
>> state suitable for 4.3.
> 
> That might be reasonable, I guess it depends what that looks like and
> how much real code impact as opposed to just save record it has?

Certainly. Minimally, code handling the expected to be extended
save record would need to be added though.

In any case, I'd appreciate if you could add this at least to the
nice-to-have section.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1SjueE-0004BI-31; Wed, 27 Jun 2012 15:59:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjueC-0004BD-LN
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 15:59:16 +0000
Received: from [85.158.139.83:59072] by server-12.bemta-5.messagelabs.com id
	60/B9-25233-3DD2BEF4; Wed, 27 Jun 2012 15:59:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340812754!27097657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32384 invoked from network); 27 Jun 2012 15:59:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:59:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13251929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:59:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 16:59:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjueA-0000LY-C4; Wed, 27 Jun 2012 15:59:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjueA-0000e6-BE;
	Wed, 27 Jun 2012 16:59:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20459.11730.332905.175948@mariner.uk.xensource.com>
Date: Wed, 27 Jun 2012 16:59:14 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <20459.3767.440030.931642@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> However, when I apply my series, I can indeed produce an assertion
> failure:
...
> So I have indeed made matters worse.

I found two bugs:

1. The void* passed to the callback was being treated as a
libxl__domain_suspend_state* by the remus callbacks; this is a
holdover from a much earlier version of the series.  It should be
converted to a libxl__save_helper_state and then the dss extracted
with CONTAINER_OF.

2. The way remus works means that the toolstack save callback is
invoked more than once, which the helper's implementation was not
prepared to deal with.  Fix this by moving the rewind of the fd into
the helper.

Fixes for these are below.  With this, on top of my series, seem to I
get the same behaviour as with the baseline.  Would you like to try it ?

Thanks,
Ian.

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index abc5932..069aca1 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
@@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc *egc,
 
 static void libxl__remus_domain_checkpoint_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 6332beb..078b7ee 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                                 toolstack_data_buf, toolstack_data_len,
                                 "toolstack data tmpfile", 0);
         if (r) { rc = ERROR_FAIL; goto out; }
-
-        r = lseek(toolstack_data_fd, 0, SEEK_SET);
-        if (r) {
-            LOGE(ERROR, "rewind toolstack data tmpfile");
-            rc = ERROR_FAIL;
-            goto out;
-        }
     }
 
     const unsigned long argnums[] = {
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
index 3bdfa28..772251a 100644
--- a/tools/libxl/libxl_save_helper.c
+++ b/tools/libxl/libxl_save_helper.c
@@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
 {
     assert(toolstack_save_fd > 0);
 
+    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
+    if (r) fail(errno,"rewind toolstack data tmpfile");
+
     *buf = xmalloc(toolstack_save_len);
-    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
     if (r<0) fail(errno,"read toolstack data");
     if (r==0) fail(0,"read toolstack data eof");
 
-    toolstack_save_fd = -1;
     *len = toolstack_save_len;
     return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 15:59:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1SjueE-0004BI-31; Wed, 27 Jun 2012 15:59:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SjueC-0004BD-LN
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 15:59:16 +0000
Received: from [85.158.139.83:59072] by server-12.bemta-5.messagelabs.com id
	60/B9-25233-3DD2BEF4; Wed, 27 Jun 2012 15:59:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340812754!27097657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32384 invoked from network); 27 Jun 2012 15:59:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 15:59:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13251929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:59:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 16:59:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SjueA-0000LY-C4; Wed, 27 Jun 2012 15:59:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SjueA-0000e6-BE;
	Wed, 27 Jun 2012 16:59:14 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20459.11730.332905.175948@mariner.uk.xensource.com>
Date: Wed, 27 Jun 2012 16:59:14 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <20459.3767.440030.931642@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> However, when I apply my series, I can indeed produce an assertion
> failure:
...
> So I have indeed made matters worse.

I found two bugs:

1. The void* passed to the callback was being treated as a
libxl__domain_suspend_state* by the remus callbacks; this is a
holdover from a much earlier version of the series.  It should be
converted to a libxl__save_helper_state and then the dss extracted
with CONTAINER_OF.

2. The way remus works means that the toolstack save callback is
invoked more than once, which the helper's implementation was not
prepared to deal with.  Fix this by moving the rewind of the fd into
the helper.

Fixes for these are below.  With this, on top of my series, seem to I
get the same behaviour as with the baseline.  Would you like to try it ?

Thanks,
Ian.

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index abc5932..069aca1 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
@@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc *egc,
 
 static void libxl__remus_domain_checkpoint_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__egc *egc = dss->shs.egc;
     STATE_AO_GC(dss->ao);
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 6332beb..078b7ee 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                                 toolstack_data_buf, toolstack_data_len,
                                 "toolstack data tmpfile", 0);
         if (r) { rc = ERROR_FAIL; goto out; }
-
-        r = lseek(toolstack_data_fd, 0, SEEK_SET);
-        if (r) {
-            LOGE(ERROR, "rewind toolstack data tmpfile");
-            rc = ERROR_FAIL;
-            goto out;
-        }
     }
 
     const unsigned long argnums[] = {
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
index 3bdfa28..772251a 100644
--- a/tools/libxl/libxl_save_helper.c
+++ b/tools/libxl/libxl_save_helper.c
@@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
 {
     assert(toolstack_save_fd > 0);
 
+    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
+    if (r) fail(errno,"rewind toolstack data tmpfile");
+
     *buf = xmalloc(toolstack_save_len);
-    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
     if (r<0) fail(errno,"read toolstack data");
     if (r==0) fail(0,"read toolstack data eof");
 
-    toolstack_save_fd = -1;
     *len = toolstack_save_len;
     return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 16:07:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16: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 1Sjulm-0004kz-4t; Wed, 27 Jun 2012 16:07: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 1Sjulk-0004ku-UD
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 16:07:05 +0000
Received: from [85.158.143.99:53691] by server-2.bemta-4.messagelabs.com id
	85/4B-17938-8AF2BEF4; Wed, 27 Jun 2012 16:07:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340813220!19791812!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10766 invoked from network); 27 Jun 2012 16:07:02 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 16:07:02 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RG6vTN014254
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:06:59 -0700
Received: by bkwj10 with SMTP id j10so1268343bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:06:56 -0700 (PDT)
Received: by 10.204.150.2 with SMTP id w2mr7782190bkv.101.1340813216284; Wed,
	27 Jun 2012 09:06:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 09:06:15 -0700 (PDT)
In-Reply-To: <20459.3767.440030.931642@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 12:06:15 -0400
Message-ID: <CAP8mzPOaQKvt0cuHU5N3Y5nQ1Ced-9g9H7=CJrKkv0=FrNQbBQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1979954470247439263=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1979954470247439263==
Content-Type: multipart/alternative; boundary=000e0ce041667780fa04c37667d4

--000e0ce041667780fa04c37667d4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 9:46 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain
> save/restore: run in a separate process"):
> > Ian,
> >  The code segfaults. Here are the system details and error traces from
> gdb.
>
> Thanks.
>
> > My setup:
> >
> > dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),
> >            running latest xen-4.2-unstable (built from your repo)
> >            tools stack also built from your repo (which I hope has all
> the latest patches).
> >
> > domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version)
> >            with suspend event channel support
> >
> > As a sanity check, I tested xl remus with latest tip from xen-unstable
> > mercurial repo, c/s: 25496:e08cf97e76f0
> >
> > Blackhole replication (to /dev/null) and localhost replication worked as
> expected
> > and the guest recovered properly without any issues.
>
> Thanks for the test runes.  That didn't work entirely properly for
> me, even with the xen-unstable baseline.
>
> I did this
>   xl -vvvv remus -b -i 100 debian.guest.osstest dummy >remus.log 2>&1 &
> The result was that the guest's networking broke.  The guest shows up
> in xl list as
>   debian.guest.osstest                      7   512     1     ---ss-
> 5.2
> and is still responsive on its pv console.


This is normal. You are suspending every 100ms. So, when you see ---ss-,
you just ended up doing "xl list" right when the guest was suspended. :)

do a xl top and you would see the guest's state oscillate from --b-- to
--s--
depending on the checkpoint interval. Or do xl list multiple times.



> After I killed the remus
> process, the guest's networking was still broken.
>
>
That is strange..  xl remus has literally no networking support on the remus
front.  So, it shouldnt affect anything in the guest. In fact I repeated
your test
on my box , where the guest was continuously pinging a host . Pings
continued
to work. so did ssh.



> At the start, the guest prints this on its console:
>  [   36.017241] WARNING: g.e. still in use!
>  [   36.021056] WARNING: g.e. still in use!
>  [   36.024740] WARNING: g.e. still in use!
>  [   36.024763] WARNING: g.e. still in use!
>
> If I try the rune with "localhost" I would have expected, surely, to
> see a domain with the incoming migration ?  But I don't.  I tried
> killing the `xl remus' process and the guest became wedged.
>
>
With "-b" option the second argument (localhost|dummy) is ignored. Did you
try the command without the -b option, i.e.
xl remus -vvv -e domU localhost

But I was partially able to reproduce some of your test results without your
patches (i.e. on xen-unstable baseline). See end of mail for more details.


> However, when I apply my series, I can indeed produce an assertion
> failure:
>
>  xc: detail: All memory is saved
>  xc: error: Could not get domain info (3 = No such process): Internal error
>  libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed
> for domain 3077579968: No such process
>  xl: libxl_event.c:1426: libxl__ao_inprogress_gc: Assertion `ao->magic ==
> 0xA0FACE00ul' failed.
>
> So I have indeed made matters worse.
>
>
> > Blackhole replication:
> > ================
> > xl error:
> > ----------
> > xc: error: Could not get domain info (3 = No such process): Internal
> error
> > libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed
> for domain 4154075147<tel:4154075147>: No such process
> > libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable
> to open qemu save file ?8b: No such file or directory
>
> I don't see that at all.
>
> NB that PV guests may have a qemu for certain disk backends, or
> consoles, depending on the configuration.  Can you show me your domain
> config ?  Mine is below.
>
>
Ah that explains the qemu related calls.

My Guest config: (from tests on 32bit PV domU w/ suspend event channel
support)

kernel = "/home/kernels/vmlinuz-2.6.32.2-xenu"
memory = 1024
name = "xltest2"
vcpus = 2
vif = [ 'mac=00:16:3e:00:00:01,bridge=eth0' ]
disk = [ 'phy:/dev/drbd1,xvda1,w']
hostname= "rshriram-vm3"
root = "/dev/xvda1 ro"
extra = "console=xvc0 3"
on_poweroff = 'destroy'
on_reboot   = 'destroy'
on_crash    = 'coredump-destroy'

NB: This guest kernel has suspend-event-channel support
which is available in all suse-kernels I suppose. If you would
just like to use mine, the source tarball (2.6.32.2 version + kernel config)
is at http://aramis.nss.cs.ubc.ca/xenolinux-2.6.32.2.tar.gz


> I also ran xl in GDB to get a stack trace and hopefully some useful debug
> info.
> > gdb traces: http://pastebin.com/7zFwFjW4
>
> I get a different crash - see above.
>
> > Localhost replication: Partial success, but xl still segfaults
> >  dmesg shows
> >  [ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp
> 00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]
>
> I see exactly the same thing with `localhost' instead of `dummy'.  And
> I see no incoming domain.
>
> I will investigate the crash I see.  In the meantime can you try to
> help me see why it doesn't work me even with the baseline ?
>
>

I also tested with 64-bit 3.3.0 PV kernel (w/o suspend-event channel
support)

guest config:
kernel = "/home/kernels/vmlinuz-3.3.0-rc1-xenu"
memory = 1024
name = "xl-ubuntu-pv64"
vcpus = 2
vif = [ 'mac=00:16:3e:00:00:03, bridge=eth0' ]
disk = [ 'phy:/dev/vgdrbd/ubuntu-pv64,xvda1,w' ]
hostname= "rshriram-vm1"
root = "/dev/xvda1 ro"
extra = "console=hvc0 3"

With xen-unstable baseline,
Test 1. Blackhole replication
 command: nohup xl remus -vvv -e -b -i 100 xl-ubuntu-pv64 dummy
>blackhole.log 2>&1 &
 result: works (networking included)
debug output:
libxl: debug: libxl_dom.c:687:libxl__domain_suspend_common_callback:
issuing PV suspend request via XenBus control node
libxl: debug: libxl_dom.c:691:libxl__domain_suspend_common_callback: wait
for the guest to acknowledge suspend request
libxl: debug: libxl_dom.c:738:libxl__domain_suspend_common_callback: guest
acknowledged suspend request
libxl: debug: libxl_dom.c:742:libxl__domain_suspend_common_callback: wait
for the guest to suspend
libxl: debug: libxl_dom.c:754:libxl__domain_suspend_common_callback: guest
has suspended

 caveat: killing remus doesnt do a proper cleanup i.e if you killed it
while the domain was
             suspended, it leaves it in the suspended state (where libxl
waits for guest to suspend)
              Its a pain. In xend/python version, I added a handler
(SIGUSR1) , so that one could do
             pkill -USR1 -f remus and gracefully exit remus, without
wedging the domU.

             * I do not know if adding signal handlers is frowned upon in
the xl land :)
               If there is some protocol in place to handle such things, I
would be happy to send
               a patch that ensures that the guest is "resumed" while doing
blackhole replication

Test 2. Localhost replication w/ failover by destroying primary VM
 command: nohup xl remus -vvv -b -i 100 xl-ubuntu-pv64 localhost
>blackhole.log 2>&1 &
 result: works (networking included)

--000e0ce041667780fa04c37667d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 9:46 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">

Shriram Rajagopalan writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/r=
estore: run in a separate process&quot;):<br>
<div class=3D"im">&gt; Ian,<br>
&gt; =A0The code segfaults. Here are the system details and error traces fr=
om gdb.<br>
<br>
</div>Thanks.<br>
<div class=3D"im"><br>
&gt; My setup:<br>
&gt;<br>
&gt; dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0running latest xen-4.2-unstable (built from you=
r repo)<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0tools stack also built from your repo (which I =
hope has all the latest patches).<br>
&gt;<br>
&gt; domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version=
)<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0with suspend event channel support<br>
&gt;<br>
&gt; As a sanity check, I tested xl remus with latest tip from xen-unstable=
<br>
&gt; mercurial repo, c/s: 25496:e08cf97e76f0<br>
&gt;<br>
&gt; Blackhole replication (to /dev/null) and localhost replication worked =
as expected<br>
&gt; and the guest recovered properly without any issues.<br>
<br>
</div>Thanks for the test runes. =A0That didn&#39;t work entirely properly =
for<br>
me, even with the xen-unstable baseline.<br>
<br>
I did this<br>
 =A0 xl -vvvv remus -b -i 100 debian.guest.osstest dummy &gt;remus.log 2&gt=
;&amp;1 &amp;<br>
The result was that the guest&#39;s networking broke. =A0The guest shows up=
<br>
in xl list as<br>
 =A0 debian.guest.osstest =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A07 =A0 =
512 =A0 =A0 1 =A0 =A0 ---ss- =A0 =A0 =A0 5.2<br>
and is still responsive on its pv console. =A0</blockquote><div><br></div><=
div>This is normal. You are suspending every 100ms. So, when you see ---ss-=
,</div><div>you just ended up doing &quot;xl list&quot; right when the gues=
t was suspended. :)</div>

<div><br></div><div>do a xl top and you would see the guest&#39;s state osc=
illate from --b-- to --s--</div><div>depending on the checkpoint interval. =
Or do xl list multiple times.</div><div><br></div><div>=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

After I killed the remus<br>
process, the guest&#39;s networking was still broken.<br>
<br></blockquote><div>=A0</div><div><div>That is strange.. =A0xl remus has =
literally no networking support on the remus</div><div>front. =A0So, it sho=
uldnt affect anything in the guest. In fact I repeated your test</div></div=
>

<div>on my box , where the guest was continuously pinging a host . Pings co=
ntinued</div><div>to work. so did ssh.</div><div><br></div><div>=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">


At the start, the guest prints this on its console:<br>
 =A0[ =A0 36.017241] WARNING: g.e. still in use!<br>
 =A0[ =A0 36.021056] WARNING: g.e. still in use!<br>
 =A0[ =A0 36.024740] WARNING: g.e. still in use!<br>
 =A0[ =A0 36.024763] WARNING: g.e. still in use!<br>
<br>
If I try the rune with &quot;localhost&quot; I would have expected, surely,=
 to<br>
see a domain with the incoming migration ? =A0But I don&#39;t. =A0I tried<b=
r>
killing the `xl remus&#39; process and the guest became wedged.<br>
<br></blockquote><div><br></div><div>With &quot;-b&quot; option the second =
argument (localhost|dummy) is ignored. Did you</div><div>try the command wi=
thout the -b option, i.e.</div><div>xl remus -vvv -e domU localhost=A0</div=
>

<div><br></div><div>But I was partially able to reproduce some of your test=
 results without your</div><div>patches (i.e. on xen-unstable baseline). Se=
e end of mail for more details.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">


<br>
However, when I apply my series, I can indeed produce an assertion<br>
failure:<br>
<br>
=A0xc: detail: All memory is saved<br>
<div class=3D"im">=A0xc: error: Could not get domain info (3 =3D No such pr=
ocess): Internal error<br>
</div>=A0libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume fa=
iled for domain <a href=3D"tel:3077579968" value=3D"+13077579968">307757996=
8</a>: No such process<br>
=A0xl: libxl_event.c:1426: libxl__ao_inprogress_gc: Assertion `ao-&gt;magic=
 =3D=3D 0xA0FACE00ul&#39; failed.<br>
<br>
So I have indeed made matters worse.<br>
<div class=3D"im"><br>
<br>
&gt; Blackhole replication:<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; xl error:<br>
&gt; ----------<br>
&gt; xc: error: Could not get domain info (3 =3D No such process): Internal=
 error<br>
</div>&gt; libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume =
failed for domain <a href=3D"tel:4154075147" value=3D"+14154075147">4154075=
147</a>&lt;tel:<a href=3D"tel:4154075147" value=3D"+14154075147">4154075147=
</a>&gt;: No such process<br>


<div class=3D"im">&gt; libxl: error: libxl_dom.c:1184:libxl__domain_save_de=
vice_model: unable to open qemu save file ?8b: No such file or directory<br=
>
<br>
</div>I don&#39;t see that at all.<br>
<br>
NB that PV guests may have a qemu for certain disk backends, or<br>
consoles, depending on the configuration. =A0Can you show me your domain<br=
>
config ? =A0Mine is below.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>Ah that explai=
ns the qemu related calls.=A0</div><div><br></div><div>My Guest config: (fr=
om tests on 32bit PV domU w/ suspend event channel support)</div><div><br>

</div><div><div>kernel =3D &quot;/home/kernels/vmlinuz-2.6.32.2-xenu&quot;<=
/div><div>memory =3D 1024</div><div>name =3D &quot;xltest2&quot;</div><div>=
vcpus =3D 2</div><div>vif =3D [ &#39;mac=3D00:16:3e:00:00:01,bridge=3Deth0&=
#39; ]</div>

<div>disk =3D [ &#39;phy:/dev/drbd1,xvda1,w&#39;]</div><div>hostname=3D &qu=
ot;rshriram-vm3&quot;</div><div>root =3D &quot;/dev/xvda1 ro&quot;</div><di=
v>extra =3D &quot;console=3Dxvc0 3&quot;</div><div>on_poweroff =3D &#39;des=
troy&#39;</div>

<div>on_reboot =A0 =3D &#39;destroy&#39;</div><div>on_crash =A0 =A0=3D &#39=
;coredump-destroy&#39;</div></div><div><br></div><div>NB: This guest kernel=
 has suspend-event-channel support</div><div>which is available in all suse=
-kernels I suppose. If you would</div>

<div>just like to use mine,=A0the source tarball (2.6.32.2 version + kernel=
 config)</div><div>is at=A0<a href=3D"http://aramis.nss.cs.ubc.ca/xenolinux=
-2.6.32.2.tar.gz">http://aramis.nss.cs.ubc.ca/xenolinux-2.6.32.2.tar.gz</a>=
</div>

<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"=
im">
&gt; I also ran xl in GDB to get a stack trace and hopefully some useful de=
bug info.<br>
&gt; gdb traces: <a href=3D"http://pastebin.com/7zFwFjW4" target=3D"_blank"=
>http://pastebin.com/7zFwFjW4</a><br>
<br>
</div>I get a different crash - see above.<br>
<div class=3D"im"><br>
&gt; Localhost replication: Partial success, but xl still segfaults<br>
&gt; =A0dmesg shows<br>
&gt; =A0[ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp 00007=
fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]<br>
<br>
</div>I see exactly the same thing with `localhost&#39; instead of `dummy&#=
39;. =A0And<br>
I see no incoming domain.<br>
<br>
I will investigate the crash I see. =A0In the meantime can you try to<br>
help me see why it doesn&#39;t work me even with the baseline ?<br>
<br></blockquote><div><br></div><div><br></div><div>I also tested with 64-b=
it 3.3.0 PV kernel (w/o suspend-event channel support)</div><div><br></div>=
<div>guest config:</div><div><div>kernel =3D &quot;/home/kernels/vmlinuz-3.=
3.0-rc1-xenu&quot;</div>

<div>memory =3D 1024</div><div>name =3D &quot;xl-ubuntu-pv64&quot;</div><di=
v>vcpus =3D 2</div><div>vif =3D [ &#39;mac=3D00:16:3e:00:00:03, bridge=3Det=
h0&#39; ]</div><div>disk =3D [ &#39;phy:/dev/vgdrbd/ubuntu-pv64,xvda1,w&#39=
; ]</div>
<div>
hostname=3D &quot;rshriram-vm1&quot;</div><div>root =3D &quot;/dev/xvda1 ro=
&quot;</div><div>extra =3D &quot;console=3Dhvc0 3&quot;</div></div><div><br=
></div><div>With xen-unstable baseline,</div><div>Test 1. Blackhole replica=
tion</div>

<div>=A0command: nohup xl remus -vvv -e -b -i 100 xl-ubuntu-pv64 dummy &gt;=
blackhole.log 2&gt;&amp;1 &amp;</div><div>=A0result: works (networking incl=
uded)</div><div>debug output:</div><div><div>libxl: debug: libxl_dom.c:687:=
libxl__domain_suspend_common_callback: issuing PV suspend request via XenBu=
s control node</div>

<div>libxl: debug: libxl_dom.c:691:libxl__domain_suspend_common_callback: w=
ait for the guest to acknowledge suspend request</div><div>libxl: debug: li=
bxl_dom.c:738:libxl__domain_suspend_common_callback: guest acknowledged sus=
pend request</div>

<div>libxl: debug: libxl_dom.c:742:libxl__domain_suspend_common_callback: w=
ait for the guest to suspend</div><div>libxl: debug: libxl_dom.c:754:libxl_=
_domain_suspend_common_callback: guest has suspended</div><div><br></div>

</div><div>=A0caveat: killing remus doesnt do a proper cleanup i.e if you k=
illed it while the domain was</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0suspende=
d, it leaves it in the suspended state (where libxl waits for guest to susp=
end)</div><div>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Its a pain. In xend/python version, I=A0added a=
 handler (SIGUSR1) , so that one could do</div><div>=A0 =A0 =A0 =A0 =A0 =A0=
 =A0pkill -USR1 -f remus and gracefully exit remus, without wedging the dom=
U.</div><div><br></div><div>

=A0 =A0 =A0 =A0 =A0 =A0 =A0* I do not know if adding signal handlers is fro=
wned upon in the xl land :)</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the=
re is some protocol in place to handle such things, I would be happy to sen=
d</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a patch that ensures that the gu=
est is &quot;resumed&quot; while doing blackhole replication</div>

<div><br></div><div>Test 2. Localhost replication w/ failover by destroying=
 primary VM</div><div><div>=A0command: nohup xl remus -vvv -b -i 100 xl-ubu=
ntu-pv64 localhost &gt;blackhole.log 2&gt;&amp;1 &amp;</div><div>=A0result:=
 works (networking included)</div>

<div><br></div></div></div>

--000e0ce041667780fa04c37667d4--


--===============1979954470247439263==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1979954470247439263==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 16:07:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16: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 1Sjulm-0004kz-4t; Wed, 27 Jun 2012 16:07: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 1Sjulk-0004ku-UD
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 16:07:05 +0000
Received: from [85.158.143.99:53691] by server-2.bemta-4.messagelabs.com id
	85/4B-17938-8AF2BEF4; Wed, 27 Jun 2012 16:07:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340813220!19791812!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10766 invoked from network); 27 Jun 2012 16:07:02 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 16:07:02 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RG6vTN014254
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:06:59 -0700
Received: by bkwj10 with SMTP id j10so1268343bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:06:56 -0700 (PDT)
Received: by 10.204.150.2 with SMTP id w2mr7782190bkv.101.1340813216284; Wed,
	27 Jun 2012 09:06:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 09:06:15 -0700 (PDT)
In-Reply-To: <20459.3767.440030.931642@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 12:06:15 -0400
Message-ID: <CAP8mzPOaQKvt0cuHU5N3Y5nQ1Ced-9g9H7=CJrKkv0=FrNQbBQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1979954470247439263=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1979954470247439263==
Content-Type: multipart/alternative; boundary=000e0ce041667780fa04c37667d4

--000e0ce041667780fa04c37667d4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 9:46 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain
> save/restore: run in a separate process"):
> > Ian,
> >  The code segfaults. Here are the system details and error traces from
> gdb.
>
> Thanks.
>
> > My setup:
> >
> > dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),
> >            running latest xen-4.2-unstable (built from your repo)
> >            tools stack also built from your repo (which I hope has all
> the latest patches).
> >
> > domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version)
> >            with suspend event channel support
> >
> > As a sanity check, I tested xl remus with latest tip from xen-unstable
> > mercurial repo, c/s: 25496:e08cf97e76f0
> >
> > Blackhole replication (to /dev/null) and localhost replication worked as
> expected
> > and the guest recovered properly without any issues.
>
> Thanks for the test runes.  That didn't work entirely properly for
> me, even with the xen-unstable baseline.
>
> I did this
>   xl -vvvv remus -b -i 100 debian.guest.osstest dummy >remus.log 2>&1 &
> The result was that the guest's networking broke.  The guest shows up
> in xl list as
>   debian.guest.osstest                      7   512     1     ---ss-
> 5.2
> and is still responsive on its pv console.


This is normal. You are suspending every 100ms. So, when you see ---ss-,
you just ended up doing "xl list" right when the guest was suspended. :)

do a xl top and you would see the guest's state oscillate from --b-- to
--s--
depending on the checkpoint interval. Or do xl list multiple times.



> After I killed the remus
> process, the guest's networking was still broken.
>
>
That is strange..  xl remus has literally no networking support on the remus
front.  So, it shouldnt affect anything in the guest. In fact I repeated
your test
on my box , where the guest was continuously pinging a host . Pings
continued
to work. so did ssh.



> At the start, the guest prints this on its console:
>  [   36.017241] WARNING: g.e. still in use!
>  [   36.021056] WARNING: g.e. still in use!
>  [   36.024740] WARNING: g.e. still in use!
>  [   36.024763] WARNING: g.e. still in use!
>
> If I try the rune with "localhost" I would have expected, surely, to
> see a domain with the incoming migration ?  But I don't.  I tried
> killing the `xl remus' process and the guest became wedged.
>
>
With "-b" option the second argument (localhost|dummy) is ignored. Did you
try the command without the -b option, i.e.
xl remus -vvv -e domU localhost

But I was partially able to reproduce some of your test results without your
patches (i.e. on xen-unstable baseline). See end of mail for more details.


> However, when I apply my series, I can indeed produce an assertion
> failure:
>
>  xc: detail: All memory is saved
>  xc: error: Could not get domain info (3 = No such process): Internal error
>  libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed
> for domain 3077579968: No such process
>  xl: libxl_event.c:1426: libxl__ao_inprogress_gc: Assertion `ao->magic ==
> 0xA0FACE00ul' failed.
>
> So I have indeed made matters worse.
>
>
> > Blackhole replication:
> > ================
> > xl error:
> > ----------
> > xc: error: Could not get domain info (3 = No such process): Internal
> error
> > libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume failed
> for domain 4154075147<tel:4154075147>: No such process
> > libxl: error: libxl_dom.c:1184:libxl__domain_save_device_model: unable
> to open qemu save file ?8b: No such file or directory
>
> I don't see that at all.
>
> NB that PV guests may have a qemu for certain disk backends, or
> consoles, depending on the configuration.  Can you show me your domain
> config ?  Mine is below.
>
>
Ah that explains the qemu related calls.

My Guest config: (from tests on 32bit PV domU w/ suspend event channel
support)

kernel = "/home/kernels/vmlinuz-2.6.32.2-xenu"
memory = 1024
name = "xltest2"
vcpus = 2
vif = [ 'mac=00:16:3e:00:00:01,bridge=eth0' ]
disk = [ 'phy:/dev/drbd1,xvda1,w']
hostname= "rshriram-vm3"
root = "/dev/xvda1 ro"
extra = "console=xvc0 3"
on_poweroff = 'destroy'
on_reboot   = 'destroy'
on_crash    = 'coredump-destroy'

NB: This guest kernel has suspend-event-channel support
which is available in all suse-kernels I suppose. If you would
just like to use mine, the source tarball (2.6.32.2 version + kernel config)
is at http://aramis.nss.cs.ubc.ca/xenolinux-2.6.32.2.tar.gz


> I also ran xl in GDB to get a stack trace and hopefully some useful debug
> info.
> > gdb traces: http://pastebin.com/7zFwFjW4
>
> I get a different crash - see above.
>
> > Localhost replication: Partial success, but xl still segfaults
> >  dmesg shows
> >  [ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp
> 00007fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]
>
> I see exactly the same thing with `localhost' instead of `dummy'.  And
> I see no incoming domain.
>
> I will investigate the crash I see.  In the meantime can you try to
> help me see why it doesn't work me even with the baseline ?
>
>

I also tested with 64-bit 3.3.0 PV kernel (w/o suspend-event channel
support)

guest config:
kernel = "/home/kernels/vmlinuz-3.3.0-rc1-xenu"
memory = 1024
name = "xl-ubuntu-pv64"
vcpus = 2
vif = [ 'mac=00:16:3e:00:00:03, bridge=eth0' ]
disk = [ 'phy:/dev/vgdrbd/ubuntu-pv64,xvda1,w' ]
hostname= "rshriram-vm1"
root = "/dev/xvda1 ro"
extra = "console=hvc0 3"

With xen-unstable baseline,
Test 1. Blackhole replication
 command: nohup xl remus -vvv -e -b -i 100 xl-ubuntu-pv64 dummy
>blackhole.log 2>&1 &
 result: works (networking included)
debug output:
libxl: debug: libxl_dom.c:687:libxl__domain_suspend_common_callback:
issuing PV suspend request via XenBus control node
libxl: debug: libxl_dom.c:691:libxl__domain_suspend_common_callback: wait
for the guest to acknowledge suspend request
libxl: debug: libxl_dom.c:738:libxl__domain_suspend_common_callback: guest
acknowledged suspend request
libxl: debug: libxl_dom.c:742:libxl__domain_suspend_common_callback: wait
for the guest to suspend
libxl: debug: libxl_dom.c:754:libxl__domain_suspend_common_callback: guest
has suspended

 caveat: killing remus doesnt do a proper cleanup i.e if you killed it
while the domain was
             suspended, it leaves it in the suspended state (where libxl
waits for guest to suspend)
              Its a pain. In xend/python version, I added a handler
(SIGUSR1) , so that one could do
             pkill -USR1 -f remus and gracefully exit remus, without
wedging the domU.

             * I do not know if adding signal handlers is frowned upon in
the xl land :)
               If there is some protocol in place to handle such things, I
would be happy to send
               a patch that ensures that the guest is "resumed" while doing
blackhole replication

Test 2. Localhost replication w/ failover by destroying primary VM
 command: nohup xl remus -vvv -b -i 100 xl-ubuntu-pv64 localhost
>blackhole.log 2>&1 &
 result: works (networking included)

--000e0ce041667780fa04c37667d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 9:46 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">

Shriram Rajagopalan writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/r=
estore: run in a separate process&quot;):<br>
<div class=3D"im">&gt; Ian,<br>
&gt; =A0The code segfaults. Here are the system details and error traces fr=
om gdb.<br>
<br>
</div>Thanks.<br>
<div class=3D"im"><br>
&gt; My setup:<br>
&gt;<br>
&gt; dom0 : ubuntu 64bit, 2.6.32-39 (pvops kernel),<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0running latest xen-4.2-unstable (built from you=
r repo)<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0tools stack also built from your repo (which I =
hope has all the latest patches).<br>
&gt;<br>
&gt; domU: ubuntu 32bit PV, xenolinux kernel (2.6.32.2 - novel suse version=
)<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0with suspend event channel support<br>
&gt;<br>
&gt; As a sanity check, I tested xl remus with latest tip from xen-unstable=
<br>
&gt; mercurial repo, c/s: 25496:e08cf97e76f0<br>
&gt;<br>
&gt; Blackhole replication (to /dev/null) and localhost replication worked =
as expected<br>
&gt; and the guest recovered properly without any issues.<br>
<br>
</div>Thanks for the test runes. =A0That didn&#39;t work entirely properly =
for<br>
me, even with the xen-unstable baseline.<br>
<br>
I did this<br>
 =A0 xl -vvvv remus -b -i 100 debian.guest.osstest dummy &gt;remus.log 2&gt=
;&amp;1 &amp;<br>
The result was that the guest&#39;s networking broke. =A0The guest shows up=
<br>
in xl list as<br>
 =A0 debian.guest.osstest =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A07 =A0 =
512 =A0 =A0 1 =A0 =A0 ---ss- =A0 =A0 =A0 5.2<br>
and is still responsive on its pv console. =A0</blockquote><div><br></div><=
div>This is normal. You are suspending every 100ms. So, when you see ---ss-=
,</div><div>you just ended up doing &quot;xl list&quot; right when the gues=
t was suspended. :)</div>

<div><br></div><div>do a xl top and you would see the guest&#39;s state osc=
illate from --b-- to --s--</div><div>depending on the checkpoint interval. =
Or do xl list multiple times.</div><div><br></div><div>=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

After I killed the remus<br>
process, the guest&#39;s networking was still broken.<br>
<br></blockquote><div>=A0</div><div><div>That is strange.. =A0xl remus has =
literally no networking support on the remus</div><div>front. =A0So, it sho=
uldnt affect anything in the guest. In fact I repeated your test</div></div=
>

<div>on my box , where the guest was continuously pinging a host . Pings co=
ntinued</div><div>to work. so did ssh.</div><div><br></div><div>=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">


At the start, the guest prints this on its console:<br>
 =A0[ =A0 36.017241] WARNING: g.e. still in use!<br>
 =A0[ =A0 36.021056] WARNING: g.e. still in use!<br>
 =A0[ =A0 36.024740] WARNING: g.e. still in use!<br>
 =A0[ =A0 36.024763] WARNING: g.e. still in use!<br>
<br>
If I try the rune with &quot;localhost&quot; I would have expected, surely,=
 to<br>
see a domain with the incoming migration ? =A0But I don&#39;t. =A0I tried<b=
r>
killing the `xl remus&#39; process and the guest became wedged.<br>
<br></blockquote><div><br></div><div>With &quot;-b&quot; option the second =
argument (localhost|dummy) is ignored. Did you</div><div>try the command wi=
thout the -b option, i.e.</div><div>xl remus -vvv -e domU localhost=A0</div=
>

<div><br></div><div>But I was partially able to reproduce some of your test=
 results without your</div><div>patches (i.e. on xen-unstable baseline). Se=
e end of mail for more details.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">


<br>
However, when I apply my series, I can indeed produce an assertion<br>
failure:<br>
<br>
=A0xc: detail: All memory is saved<br>
<div class=3D"im">=A0xc: error: Could not get domain info (3 =3D No such pr=
ocess): Internal error<br>
</div>=A0libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume fa=
iled for domain <a href=3D"tel:3077579968" value=3D"+13077579968">307757996=
8</a>: No such process<br>
=A0xl: libxl_event.c:1426: libxl__ao_inprogress_gc: Assertion `ao-&gt;magic=
 =3D=3D 0xA0FACE00ul&#39; failed.<br>
<br>
So I have indeed made matters worse.<br>
<div class=3D"im"><br>
<br>
&gt; Blackhole replication:<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; xl error:<br>
&gt; ----------<br>
&gt; xc: error: Could not get domain info (3 =3D No such process): Internal=
 error<br>
</div>&gt; libxl: error: libxl.c:388:libxl_domain_resume: xc_domain_resume =
failed for domain <a href=3D"tel:4154075147" value=3D"+14154075147">4154075=
147</a>&lt;tel:<a href=3D"tel:4154075147" value=3D"+14154075147">4154075147=
</a>&gt;: No such process<br>


<div class=3D"im">&gt; libxl: error: libxl_dom.c:1184:libxl__domain_save_de=
vice_model: unable to open qemu save file ?8b: No such file or directory<br=
>
<br>
</div>I don&#39;t see that at all.<br>
<br>
NB that PV guests may have a qemu for certain disk backends, or<br>
consoles, depending on the configuration. =A0Can you show me your domain<br=
>
config ? =A0Mine is below.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>Ah that explai=
ns the qemu related calls.=A0</div><div><br></div><div>My Guest config: (fr=
om tests on 32bit PV domU w/ suspend event channel support)</div><div><br>

</div><div><div>kernel =3D &quot;/home/kernels/vmlinuz-2.6.32.2-xenu&quot;<=
/div><div>memory =3D 1024</div><div>name =3D &quot;xltest2&quot;</div><div>=
vcpus =3D 2</div><div>vif =3D [ &#39;mac=3D00:16:3e:00:00:01,bridge=3Deth0&=
#39; ]</div>

<div>disk =3D [ &#39;phy:/dev/drbd1,xvda1,w&#39;]</div><div>hostname=3D &qu=
ot;rshriram-vm3&quot;</div><div>root =3D &quot;/dev/xvda1 ro&quot;</div><di=
v>extra =3D &quot;console=3Dxvc0 3&quot;</div><div>on_poweroff =3D &#39;des=
troy&#39;</div>

<div>on_reboot =A0 =3D &#39;destroy&#39;</div><div>on_crash =A0 =A0=3D &#39=
;coredump-destroy&#39;</div></div><div><br></div><div>NB: This guest kernel=
 has suspend-event-channel support</div><div>which is available in all suse=
-kernels I suppose. If you would</div>

<div>just like to use mine,=A0the source tarball (2.6.32.2 version + kernel=
 config)</div><div>is at=A0<a href=3D"http://aramis.nss.cs.ubc.ca/xenolinux=
-2.6.32.2.tar.gz">http://aramis.nss.cs.ubc.ca/xenolinux-2.6.32.2.tar.gz</a>=
</div>

<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"=
im">
&gt; I also ran xl in GDB to get a stack trace and hopefully some useful de=
bug info.<br>
&gt; gdb traces: <a href=3D"http://pastebin.com/7zFwFjW4" target=3D"_blank"=
>http://pastebin.com/7zFwFjW4</a><br>
<br>
</div>I get a different crash - see above.<br>
<div class=3D"im"><br>
&gt; Localhost replication: Partial success, but xl still segfaults<br>
&gt; =A0dmesg shows<br>
&gt; =A0[ 1399.254849] xl[4716]: segfault at 0 ip 00007f979483a417 sp 00007=
fffe06043e0 error 6 in libxenlight.so.2.0.0[7f9794807000+4d000]<br>
<br>
</div>I see exactly the same thing with `localhost&#39; instead of `dummy&#=
39;. =A0And<br>
I see no incoming domain.<br>
<br>
I will investigate the crash I see. =A0In the meantime can you try to<br>
help me see why it doesn&#39;t work me even with the baseline ?<br>
<br></blockquote><div><br></div><div><br></div><div>I also tested with 64-b=
it 3.3.0 PV kernel (w/o suspend-event channel support)</div><div><br></div>=
<div>guest config:</div><div><div>kernel =3D &quot;/home/kernels/vmlinuz-3.=
3.0-rc1-xenu&quot;</div>

<div>memory =3D 1024</div><div>name =3D &quot;xl-ubuntu-pv64&quot;</div><di=
v>vcpus =3D 2</div><div>vif =3D [ &#39;mac=3D00:16:3e:00:00:03, bridge=3Det=
h0&#39; ]</div><div>disk =3D [ &#39;phy:/dev/vgdrbd/ubuntu-pv64,xvda1,w&#39=
; ]</div>
<div>
hostname=3D &quot;rshriram-vm1&quot;</div><div>root =3D &quot;/dev/xvda1 ro=
&quot;</div><div>extra =3D &quot;console=3Dhvc0 3&quot;</div></div><div><br=
></div><div>With xen-unstable baseline,</div><div>Test 1. Blackhole replica=
tion</div>

<div>=A0command: nohup xl remus -vvv -e -b -i 100 xl-ubuntu-pv64 dummy &gt;=
blackhole.log 2&gt;&amp;1 &amp;</div><div>=A0result: works (networking incl=
uded)</div><div>debug output:</div><div><div>libxl: debug: libxl_dom.c:687:=
libxl__domain_suspend_common_callback: issuing PV suspend request via XenBu=
s control node</div>

<div>libxl: debug: libxl_dom.c:691:libxl__domain_suspend_common_callback: w=
ait for the guest to acknowledge suspend request</div><div>libxl: debug: li=
bxl_dom.c:738:libxl__domain_suspend_common_callback: guest acknowledged sus=
pend request</div>

<div>libxl: debug: libxl_dom.c:742:libxl__domain_suspend_common_callback: w=
ait for the guest to suspend</div><div>libxl: debug: libxl_dom.c:754:libxl_=
_domain_suspend_common_callback: guest has suspended</div><div><br></div>

</div><div>=A0caveat: killing remus doesnt do a proper cleanup i.e if you k=
illed it while the domain was</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0suspende=
d, it leaves it in the suspended state (where libxl waits for guest to susp=
end)</div><div>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Its a pain. In xend/python version, I=A0added a=
 handler (SIGUSR1) , so that one could do</div><div>=A0 =A0 =A0 =A0 =A0 =A0=
 =A0pkill -USR1 -f remus and gracefully exit remus, without wedging the dom=
U.</div><div><br></div><div>

=A0 =A0 =A0 =A0 =A0 =A0 =A0* I do not know if adding signal handlers is fro=
wned upon in the xl land :)</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the=
re is some protocol in place to handle such things, I would be happy to sen=
d</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a patch that ensures that the gu=
est is &quot;resumed&quot; while doing blackhole replication</div>

<div><br></div><div>Test 2. Localhost replication w/ failover by destroying=
 primary VM</div><div><div>=A0command: nohup xl remus -vvv -b -i 100 xl-ubu=
ntu-pv64 localhost &gt;blackhole.log 2&gt;&amp;1 &amp;</div><div>=A0result:=
 works (networking included)</div>

<div><br></div></div></div>

--000e0ce041667780fa04c37667d4--


--===============1979954470247439263==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1979954470247439263==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 16:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjuoS-0004vm-U3; Wed, 27 Jun 2012 16:09:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SjuoR-0004vb-1K
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 16:09:51 +0000
Received: from [85.158.139.83:28028] by server-12.bemta-5.messagelabs.com id
	DE/D9-25233-E403BEF4; Wed, 27 Jun 2012 16:09:50 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340813387!29818606!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19078 invoked from network); 27 Jun 2012 16:09:48 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 16:09:48 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RG9i9C016657
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:09:45 -0700
Received: by bkwj10 with SMTP id j10so1271721bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:09:43 -0700 (PDT)
Received: by 10.204.155.154 with SMTP id s26mr7401502bkw.129.1340813383154;
	Wed, 27 Jun 2012 09:09:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 09:09:02 -0700 (PDT)
In-Reply-To: <20459.11730.332905.175948@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
	<20459.11730.332905.175948@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 12:09:02 -0400
Message-ID: <CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1492871240793936303=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1492871240793936303==
Content-Type: multipart/alternative; boundary=000e0cdfd88069be1304c3767121

--000e0cdfd88069be1304c3767121
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 11:59 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Ian Jackson writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run
> in a separate process"):
> > However, when I apply my series, I can indeed produce an assertion
> > failure:
> ...
> > So I have indeed made matters worse.
>
> I found two bugs:
>
> 1. The void* passed to the callback was being treated as a
> libxl__domain_suspend_state* by the remus callbacks; this is a
> holdover from a much earlier version of the series.  It should be
> converted to a libxl__save_helper_state and then the dss extracted
> with CONTAINER_OF.
>
> 2. The way remus works means that the toolstack save callback is
> invoked more than once, which the helper's implementation was not
> prepared to deal with.  Fix this by moving the rewind of the fd into
> the helper.
>
> Fixes for these are below.  With this, on top of my series, seem to I
> get the same behaviour as with the baseline.  Would you like to try it ?
>
>
Sure, I ll give it a shot.
Btw, my earlier mail was in response to remus not
working on the baseline setup on your dev environment.



> Thanks,
> Ian.
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index abc5932..069aca1 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void
> *data)
>
>  static int libxl__remus_domain_resume_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>     STATE_AO_GC(dss->ao);
>
>      /* Resumes the domain and the device model */
> @@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc
> *egc,
>
>  static void libxl__remus_domain_checkpoint_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>     libxl__egc *egc = dss->shs.egc;
>     STATE_AO_GC(dss->ao);
>
> diff --git a/tools/libxl/libxl_save_callout.c
> b/tools/libxl/libxl_save_callout.c
> index 6332beb..078b7ee 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc,
> libxl__domain_suspend_state *dss,
>                                 toolstack_data_buf, toolstack_data_len,
>                                  "toolstack data tmpfile", 0);
>          if (r) { rc = ERROR_FAIL; goto out; }
> -
> -        r = lseek(toolstack_data_fd, 0, SEEK_SET);
> -        if (r) {
> -            LOGE(ERROR, "rewind toolstack data tmpfile");
> -            rc = ERROR_FAIL;
> -            goto out;
> -        }
>     }
>
>     const unsigned long argnums[] = {
> diff --git a/tools/libxl/libxl_save_helper.c
> b/tools/libxl/libxl_save_helper.c
> index 3bdfa28..772251a 100644
> --- a/tools/libxl/libxl_save_helper.c
> +++ b/tools/libxl/libxl_save_helper.c
> @@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t
> **buf,
>  {
>     assert(toolstack_save_fd > 0);
>
> +    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
> +    if (r) fail(errno,"rewind toolstack data tmpfile");
> +
>      *buf = xmalloc(toolstack_save_len);
> -    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
> +    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
>     if (r<0) fail(errno,"read toolstack data");
>      if (r==0) fail(0,"read toolstack data eof");
>
> -    toolstack_save_fd = -1;
>     *len = toolstack_save_len;
>     return 0;
>  }
>
>

--000e0cdfd88069be1304c3767121
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 11:59 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">

Ian Jackson writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/restore: =
run in a separate process&quot;):<br>
<div class=3D"im">&gt; However, when I apply my series, I can indeed produc=
e an assertion<br>
&gt; failure:<br>
</div>...<br>
<div class=3D"im">&gt; So I have indeed made matters worse.<br>
<br>
</div>I found two bugs:<br>
<br>
1. The void* passed to the callback was being treated as a<br>
libxl__domain_suspend_state* by the remus callbacks; this is a<br>
holdover from a much earlier version of the series. =A0It should be<br>
converted to a libxl__save_helper_state and then the dss extracted<br>
with CONTAINER_OF.<br>
<br>
2. The way remus works means that the toolstack save callback is<br>
invoked more than once, which the helper&#39;s implementation was not<br>
prepared to deal with. =A0Fix this by moving the rewind of the fd into<br>
the helper.<br>
<br>
Fixes for these are below. =A0With this, on top of my series, seem to I<br>
get the same behaviour as with the baseline. =A0Would you like to try it ?<=
br>
<br></blockquote><div><br></div><div>Sure, I ll give it a shot.</div><div>B=
tw, my earlier mail was in response to remus not</div><div>working on the b=
aseline setup on your dev environment.</div><div><br></div><div>=A0</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
index abc5932..069aca1 100644<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void *d=
ata)<br>
<br>
=A0static int libxl__remus_domain_resume_callback(void *data)<br>
<div class=3D"im">=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
<div class=3D"im">+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_O=
F(shs, *dss, shs);<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
</div> =A0 =A0 /* Resumes the domain and the device model */<br>
@@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc *egc=
,<br>
<br>
=A0static void libxl__remus_domain_checkpoint_callback(void *data)<br>
<div class=3D"im">=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_OF(shs, *dss, shs);=
<br>
 =A0 =A0 libxl__egc *egc =3D dss-&gt;shs.egc;<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_call=
out.c<br>
index 6332beb..078b7ee 100644<br>
--- a/tools/libxl/libxl_save_callout.c<br>
+++ b/tools/libxl/libxl_save_callout.c<br>
@@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__dom=
ain_suspend_state *dss,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 toolstack_=
data_buf, toolstack_data_len,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 &quot;toolstack data tmpfile&quot;, 0);<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 if (r) { rc =3D ERROR_FAIL; goto o=
ut; }<br>
</div><div class=3D"im">-<br>
- =A0 =A0 =A0 =A0r =3D lseek(toolstack_data_fd, 0, SEEK_SET);<br>
- =A0 =A0 =A0 =A0if (r) {<br>
- =A0 =A0 =A0 =A0 =A0 =A0LOGE(ERROR, &quot;rewind toolstack data tmpfile&qu=
ot;);<br>
</div>- =A0 =A0 =A0 =A0 =A0 =A0rc =3D ERROR_FAIL;<br>
- =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
<div class=3D"im">- =A0 =A0 =A0 =A0}<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 const unsigned long argnums[] =3D {<br>
</div>diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save=
_helper.c<br>
index 3bdfa28..772251a 100644<br>
--- a/tools/libxl/libxl_save_helper.c<br>
+++ b/tools/libxl/libxl_save_helper.c<br>
@@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t =
**buf,<br>
=A0{<br>
 =A0 =A0 assert(toolstack_save_fd &gt; 0);<br>
<br>
+ =A0 =A0int r =3D lseek(toolstack_save_fd, 0, SEEK_SET);<br>
+ =A0 =A0if (r) fail(errno,&quot;rewind toolstack data tmpfile&quot;);<br>
+<br>
<div class=3D"im"> =A0 =A0 *buf =3D xmalloc(toolstack_save_len);<br>
- =A0 =A0int r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len=
);<br>
+ =A0 =A0r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len);<b=
r>
 =A0 =A0 if (r&lt;0) fail(errno,&quot;read toolstack data&quot;);<br>
</div><div class=3D"im"> =A0 =A0 if (r=3D=3D0) fail(0,&quot;read toolstack =
data eof&quot;);<br>
<br>
</div>- =A0 =A0toolstack_save_fd =3D -1;<br>
 =A0 =A0 *len =3D toolstack_save_len;<br>
 =A0 =A0 return 0;<br>
=A0}<br>
<br>
</blockquote></div><br>

--000e0cdfd88069be1304c3767121--


--===============1492871240793936303==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1492871240793936303==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 16:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjuoS-0004vm-U3; Wed, 27 Jun 2012 16:09:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SjuoR-0004vb-1K
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 16:09:51 +0000
Received: from [85.158.139.83:28028] by server-12.bemta-5.messagelabs.com id
	DE/D9-25233-E403BEF4; Wed, 27 Jun 2012 16:09:50 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-182.messagelabs.com!1340813387!29818606!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19078 invoked from network); 27 Jun 2012 16:09:48 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 16:09:48 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RG9i9C016657
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:09:45 -0700
Received: by bkwj10 with SMTP id j10so1271721bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:09:43 -0700 (PDT)
Received: by 10.204.155.154 with SMTP id s26mr7401502bkw.129.1340813383154;
	Wed, 27 Jun 2012 09:09:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 09:09:02 -0700 (PDT)
In-Reply-To: <20459.11730.332905.175948@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
	<20459.11730.332905.175948@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 12:09:02 -0400
Message-ID: <CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1492871240793936303=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1492871240793936303==
Content-Type: multipart/alternative; boundary=000e0cdfd88069be1304c3767121

--000e0cdfd88069be1304c3767121
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 11:59 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Ian Jackson writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run
> in a separate process"):
> > However, when I apply my series, I can indeed produce an assertion
> > failure:
> ...
> > So I have indeed made matters worse.
>
> I found two bugs:
>
> 1. The void* passed to the callback was being treated as a
> libxl__domain_suspend_state* by the remus callbacks; this is a
> holdover from a much earlier version of the series.  It should be
> converted to a libxl__save_helper_state and then the dss extracted
> with CONTAINER_OF.
>
> 2. The way remus works means that the toolstack save callback is
> invoked more than once, which the helper's implementation was not
> prepared to deal with.  Fix this by moving the rewind of the fd into
> the helper.
>
> Fixes for these are below.  With this, on top of my series, seem to I
> get the same behaviour as with the baseline.  Would you like to try it ?
>
>
Sure, I ll give it a shot.
Btw, my earlier mail was in response to remus not
working on the baseline setup on your dev environment.



> Thanks,
> Ian.
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index abc5932..069aca1 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void
> *data)
>
>  static int libxl__remus_domain_resume_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>     STATE_AO_GC(dss->ao);
>
>      /* Resumes the domain and the device model */
> @@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc
> *egc,
>
>  static void libxl__remus_domain_checkpoint_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>     libxl__egc *egc = dss->shs.egc;
>     STATE_AO_GC(dss->ao);
>
> diff --git a/tools/libxl/libxl_save_callout.c
> b/tools/libxl/libxl_save_callout.c
> index 6332beb..078b7ee 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc,
> libxl__domain_suspend_state *dss,
>                                 toolstack_data_buf, toolstack_data_len,
>                                  "toolstack data tmpfile", 0);
>          if (r) { rc = ERROR_FAIL; goto out; }
> -
> -        r = lseek(toolstack_data_fd, 0, SEEK_SET);
> -        if (r) {
> -            LOGE(ERROR, "rewind toolstack data tmpfile");
> -            rc = ERROR_FAIL;
> -            goto out;
> -        }
>     }
>
>     const unsigned long argnums[] = {
> diff --git a/tools/libxl/libxl_save_helper.c
> b/tools/libxl/libxl_save_helper.c
> index 3bdfa28..772251a 100644
> --- a/tools/libxl/libxl_save_helper.c
> +++ b/tools/libxl/libxl_save_helper.c
> @@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t
> **buf,
>  {
>     assert(toolstack_save_fd > 0);
>
> +    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
> +    if (r) fail(errno,"rewind toolstack data tmpfile");
> +
>      *buf = xmalloc(toolstack_save_len);
> -    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
> +    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
>     if (r<0) fail(errno,"read toolstack data");
>      if (r==0) fail(0,"read toolstack data eof");
>
> -    toolstack_save_fd = -1;
>     *len = toolstack_save_len;
>     return 0;
>  }
>
>

--000e0cdfd88069be1304c3767121
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 11:59 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">

Ian Jackson writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/restore: =
run in a separate process&quot;):<br>
<div class=3D"im">&gt; However, when I apply my series, I can indeed produc=
e an assertion<br>
&gt; failure:<br>
</div>...<br>
<div class=3D"im">&gt; So I have indeed made matters worse.<br>
<br>
</div>I found two bugs:<br>
<br>
1. The void* passed to the callback was being treated as a<br>
libxl__domain_suspend_state* by the remus callbacks; this is a<br>
holdover from a much earlier version of the series. =A0It should be<br>
converted to a libxl__save_helper_state and then the dss extracted<br>
with CONTAINER_OF.<br>
<br>
2. The way remus works means that the toolstack save callback is<br>
invoked more than once, which the helper&#39;s implementation was not<br>
prepared to deal with. =A0Fix this by moving the rewind of the fd into<br>
the helper.<br>
<br>
Fixes for these are below. =A0With this, on top of my series, seem to I<br>
get the same behaviour as with the baseline. =A0Would you like to try it ?<=
br>
<br></blockquote><div><br></div><div>Sure, I ll give it a shot.</div><div>B=
tw, my earlier mail was in response to remus not</div><div>working on the b=
aseline setup on your dev environment.</div><div><br></div><div>=A0</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
index abc5932..069aca1 100644<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void *d=
ata)<br>
<br>
=A0static int libxl__remus_domain_resume_callback(void *data)<br>
<div class=3D"im">=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
<div class=3D"im">+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_O=
F(shs, *dss, shs);<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
</div> =A0 =A0 /* Resumes the domain and the device model */<br>
@@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc *egc=
,<br>
<br>
=A0static void libxl__remus_domain_checkpoint_callback(void *data)<br>
<div class=3D"im">=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_OF(shs, *dss, shs);=
<br>
 =A0 =A0 libxl__egc *egc =3D dss-&gt;shs.egc;<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_call=
out.c<br>
index 6332beb..078b7ee 100644<br>
--- a/tools/libxl/libxl_save_callout.c<br>
+++ b/tools/libxl/libxl_save_callout.c<br>
@@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__dom=
ain_suspend_state *dss,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 toolstack_=
data_buf, toolstack_data_len,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 &quot;toolstack data tmpfile&quot;, 0);<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 if (r) { rc =3D ERROR_FAIL; goto o=
ut; }<br>
</div><div class=3D"im">-<br>
- =A0 =A0 =A0 =A0r =3D lseek(toolstack_data_fd, 0, SEEK_SET);<br>
- =A0 =A0 =A0 =A0if (r) {<br>
- =A0 =A0 =A0 =A0 =A0 =A0LOGE(ERROR, &quot;rewind toolstack data tmpfile&qu=
ot;);<br>
</div>- =A0 =A0 =A0 =A0 =A0 =A0rc =3D ERROR_FAIL;<br>
- =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
<div class=3D"im">- =A0 =A0 =A0 =A0}<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 const unsigned long argnums[] =3D {<br>
</div>diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save=
_helper.c<br>
index 3bdfa28..772251a 100644<br>
--- a/tools/libxl/libxl_save_helper.c<br>
+++ b/tools/libxl/libxl_save_helper.c<br>
@@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t =
**buf,<br>
=A0{<br>
 =A0 =A0 assert(toolstack_save_fd &gt; 0);<br>
<br>
+ =A0 =A0int r =3D lseek(toolstack_save_fd, 0, SEEK_SET);<br>
+ =A0 =A0if (r) fail(errno,&quot;rewind toolstack data tmpfile&quot;);<br>
+<br>
<div class=3D"im"> =A0 =A0 *buf =3D xmalloc(toolstack_save_len);<br>
- =A0 =A0int r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len=
);<br>
+ =A0 =A0r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len);<b=
r>
 =A0 =A0 if (r&lt;0) fail(errno,&quot;read toolstack data&quot;);<br>
</div><div class=3D"im"> =A0 =A0 if (r=3D=3D0) fail(0,&quot;read toolstack =
data eof&quot;);<br>
<br>
</div>- =A0 =A0toolstack_save_fd =3D -1;<br>
 =A0 =A0 *len =3D toolstack_save_len;<br>
 =A0 =A0 return 0;<br>
=A0}<br>
<br>
</blockquote></div><br>

--000e0cdfd88069be1304c3767121--


--===============1492871240793936303==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1492871240793936303==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 16:43:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16:43: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 1SjvKb-0005JC-Qx; Wed, 27 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SjvKa-0005J7-Im
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 16:43:04 +0000
Received: from [85.158.143.35:25880] by server-2.bemta-4.messagelabs.com id
	76/F6-17938-7183BEF4; Wed, 27 Jun 2012 16:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340815383!15932613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11938 invoked from network); 27 Jun 2012 16:43:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 16:43:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13252748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 16:43:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 17:43:02 +0100
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 1SjvKY-0000nv-IC;
	Wed, 27 Jun 2012 16:43:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjvKY-0000CY-9v;
	Wed, 27 Jun 2012 17:43:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13373-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 17:43:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13373: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13373 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13373/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13372

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13371

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4f92bdf3370c
baseline version:
 xen                  c6c9d20963d7

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25518:4f92bdf3370c
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Jun 27 09:36:43 2012 +0200
    
    docs/xen-headers: allow headers to be symlinks
    
    There's no apparent reason not to permit this, and since we don't
    support out-of-source-tree builds, the least overhead way of doing
    multiple, differently configured (perhaps different architecture)
    builds from a single source tree is to create symlinked build trees.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25517:c6c9d20963d7
user:        Dario Faggioli <raistlin@linux.it>
date:        Tue Jun 26 17:00:20 2012 +0100
    
    libxl: fix a typo in the GCREALLOC_ARRAY macro
    
    Causing a build failure when trying to use it:
    
    xxx: error: expected ';' before ')' token
    xxx: error: expected statement before ')' token
    
    Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Jun 7 19:44:01 2012 +0100

    qemu-xen-trad: fix sys-queue.h usage on BSD systems
    
    BSD systems already have a sys/queue.h file, which has more macros
    than the one Qemu uses, and some header files depend on having that
    macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
    systems and include the native one.
    
    This is not a backport because the original patch is too dificult to
    backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
    
    Doing a diff -bB shows that the Qemu version is just a stripped
    version of the original NetBSD header, with many macros removed, but
    no new ones added.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 16:43:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16:43: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 1SjvKb-0005JC-Qx; Wed, 27 Jun 2012 16: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.Jackson@eu.citrix.com>) id 1SjvKa-0005J7-Im
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 16:43:04 +0000
Received: from [85.158.143.35:25880] by server-2.bemta-4.messagelabs.com id
	76/F6-17938-7183BEF4; Wed, 27 Jun 2012 16:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340815383!15932613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11938 invoked from network); 27 Jun 2012 16:43:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 16:43:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13252748"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 16:43:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 17:43:02 +0100
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 1SjvKY-0000nv-IC;
	Wed, 27 Jun 2012 16:43:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjvKY-0000CY-9v;
	Wed, 27 Jun 2012 17:43:02 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13373-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 17:43:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13373: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13373 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13373/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 13372

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13371

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4f92bdf3370c
baseline version:
 xen                  c6c9d20963d7

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25518:4f92bdf3370c
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Jun 27 09:36:43 2012 +0200
    
    docs/xen-headers: allow headers to be symlinks
    
    There's no apparent reason not to permit this, and since we don't
    support out-of-source-tree builds, the least overhead way of doing
    multiple, differently configured (perhaps different architecture)
    builds from a single source tree is to create symlinked build trees.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25517:c6c9d20963d7
user:        Dario Faggioli <raistlin@linux.it>
date:        Tue Jun 26 17:00:20 2012 +0100
    
    libxl: fix a typo in the GCREALLOC_ARRAY macro
    
    Causing a build failure when trying to use it:
    
    xxx: error: expected ';' before ')' token
    xxx: error: expected statement before ')' token
    
    Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Jun 7 19:44:01 2012 +0100

    qemu-xen-trad: fix sys-queue.h usage on BSD systems
    
    BSD systems already have a sys/queue.h file, which has more macros
    than the one Qemu uses, and some header files depend on having that
    macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
    systems and include the native one.
    
    This is not a backport because the original patch is too dificult to
    backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
    
    Doing a diff -bB shows that the Qemu version is just a stripped
    version of the original NetBSD header, with many macros removed, but
    no new ones added.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 16:43:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16: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 1SjvL1-0005KI-7z; Wed, 27 Jun 2012 16:43:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SjvL0-0005K7-3i
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 16:43:30 +0000
Received: from [193.109.254.147:51493] by server-11.bemta-14.messagelabs.com
	id 1C/99-24843-1383BEF4; Wed, 27 Jun 2012 16:43:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340815406!8892778!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27895 invoked from network); 27 Jun 2012 16:43:27 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 16:43:27 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RGhNBT029637
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:43:24 -0700
Received: by bkwj10 with SMTP id j10so1314693bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:43:21 -0700 (PDT)
Received: by 10.205.136.3 with SMTP id ii3mr41668bkc.101.1340815401460; Wed,
	27 Jun 2012 09:43:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 09:42:41 -0700 (PDT)
In-Reply-To: <CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
	<20459.11730.332905.175948@mariner.uk.xensource.com>
	<CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 12:42:41 -0400
Message-ID: <CAP8mzPM6F=gKB4hGi1JZqkuvYzcOmv8-SfLJODRC5Ls0kkiuUQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8834480936510365647=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8834480936510365647==
Content-Type: multipart/alternative; boundary=000e0ce0d65eb6a3a704c376e9b8

--000e0ce0d65eb6a3a704c376e9b8
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 12:09 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Wed, Jun 27, 2012 at 11:59 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:
>
>> Ian Jackson writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run
>> in a separate process"):
>> > However, when I apply my series, I can indeed produce an assertion
>> > failure:
>> ...
>> > So I have indeed made matters worse.
>>
>> I found two bugs:
>>
>> 1. The void* passed to the callback was being treated as a
>> libxl__domain_suspend_state* by the remus callbacks; this is a
>> holdover from a much earlier version of the series.  It should be
>> converted to a libxl__save_helper_state and then the dss extracted
>> with CONTAINER_OF.
>>
>> 2. The way remus works means that the toolstack save callback is
>> invoked more than once, which the helper's implementation was not
>> prepared to deal with.  Fix this by moving the rewind of the fd into
>> the helper.
>>
>> Fixes for these are below.  With this, on top of my series, seem to I
>> get the same behaviour as with the baseline.  Would you like to try it ?
>>
>>
> Sure, I ll give it a shot.
> Btw, my earlier mail was in response to remus not
> working on the baseline setup on your dev environment.
>
>
The fix works for 2 out of 3 cases
 blackhole replication (xl remus -b)
 localhost replication with failover i.e. destroy primary (xl remus domU
localhost)

However, it crashes the guest for localhost replication, when I destroy the
backup
i.e. xl destroy domU--incoming . The primary guest would generally resume,
but in this
case its in --sc- state.
NB: This seems to happen in baseline xen-unstable too!.

xc: error: unexpected PFN mapping failure pfn 180e map_mfn 43b808 p2m_mfn
43b808: Internal error
libxl: error: libxl_create.c:760:libxl__xc_domain_restore_done: restoring
domain: Resource temporarily unavailable
libxl: error: libxl_create.c:844:domcreate_rebuild_done: cannot (re-)build
domain: -3
libxl: error: libxl.c:1220:libxl_domain_destroy: non-existant domain 17
libxl: error: libxl_create.c:995:domcreate_complete: unable to destroy
domain 17 following failed creation
migration target: Domain creation failed (code -3).
..
Total Data Sent= 12.597 MB
libxl: debug: libxl_dom.c:801:libxl__domain_suspend_common_callback:
issuing PV suspend request via XenBus control node
libxl: debug: libxl_dom.c:805:libxl__domain_suspend_common_callback: wait
for the guest to acknowledge suspend request
libxl: debug: libxl_dom.c:852:libxl__domain_suspend_common_callback: guest
acknowledged suspend request
libxl: debug: libxl_dom.c:856:libxl__domain_suspend_common_callback: wait
for the guest to suspend
libxl: debug: libxl_dom.c:870:libxl__domain_suspend_common_callback: guest
has suspended
pagetables=2,cache_misses=0,emptypages=45
libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated
reading ipc msg header from domain 16 save/restore helper stdout pipe
libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 16
save/restore helper [3148] died due to fatal signal Broken pipe
libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x1b08c80:
complete, rc=-3
libxl: debug: libxl_event.c:1406:libxl__ao__destroy: ao 0x1b08c80: destroy
remus sender: libxl_domain_suspend failed (rc=-3)
Remus: Backup failed? resuming domain at primary.
xc: debug: hypercall buffer: total allocations:2116 total releases:2116
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1729 misses:2 toobig:385




>
>
>> Thanks,
>> Ian.
>>
>> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> index abc5932..069aca1 100644
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
>> @@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void
>> *data)
>>
>>  static int libxl__remus_domain_resume_callback(void *data)
>>  {
>> -    libxl__domain_suspend_state *dss = data;
>> +    libxl__save_helper_state *shs = data;
>> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>>     STATE_AO_GC(dss->ao);
>>
>>      /* Resumes the domain and the device model */
>> @@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc
>> *egc,
>>
>>  static void libxl__remus_domain_checkpoint_callback(void *data)
>>  {
>> -    libxl__domain_suspend_state *dss = data;
>> +    libxl__save_helper_state *shs = data;
>> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>>     libxl__egc *egc = dss->shs.egc;
>>     STATE_AO_GC(dss->ao);
>>
>> diff --git a/tools/libxl/libxl_save_callout.c
>> b/tools/libxl/libxl_save_callout.c
>> index 6332beb..078b7ee 100644
>> --- a/tools/libxl/libxl_save_callout.c
>> +++ b/tools/libxl/libxl_save_callout.c
>> @@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc,
>> libxl__domain_suspend_state *dss,
>>                                 toolstack_data_buf, toolstack_data_len,
>>                                  "toolstack data tmpfile", 0);
>>          if (r) { rc = ERROR_FAIL; goto out; }
>> -
>> -        r = lseek(toolstack_data_fd, 0, SEEK_SET);
>> -        if (r) {
>> -            LOGE(ERROR, "rewind toolstack data tmpfile");
>> -            rc = ERROR_FAIL;
>> -            goto out;
>> -        }
>>     }
>>
>>     const unsigned long argnums[] = {
>> diff --git a/tools/libxl/libxl_save_helper.c
>> b/tools/libxl/libxl_save_helper.c
>> index 3bdfa28..772251a 100644
>> --- a/tools/libxl/libxl_save_helper.c
>> +++ b/tools/libxl/libxl_save_helper.c
>> @@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid,
>> uint8_t **buf,
>>  {
>>     assert(toolstack_save_fd > 0);
>>
>> +    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
>> +    if (r) fail(errno,"rewind toolstack data tmpfile");
>> +
>>      *buf = xmalloc(toolstack_save_len);
>> -    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
>> +    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
>>     if (r<0) fail(errno,"read toolstack data");
>>      if (r==0) fail(0,"read toolstack data eof");
>>
>> -    toolstack_save_fd = -1;
>>     *len = toolstack_save_len;
>>     return 0;
>>  }
>>
>>
>

--000e0ce0d65eb6a3a704c376e9b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 12:09 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:<br><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">

<div class=3D"im">On Wed, Jun 27, 2012 at 11:59 AM, Ian Jackson <span dir=
=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu.citrix.com" target=3D"_blank"=
>Ian.Jackson@eu.citrix.com</a>&gt;</span> wrote:<br></div><div class=3D"gma=
il_quote">

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
Ian Jackson writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/restore: =
run in a separate process&quot;):<br>
<div>&gt; However, when I apply my series, I can indeed produce an assertio=
n<br>
&gt; failure:<br>
</div>...<br>
<div>&gt; So I have indeed made matters worse.<br>
<br>
</div>I found two bugs:<br>
<br>
1. The void* passed to the callback was being treated as a<br>
libxl__domain_suspend_state* by the remus callbacks; this is a<br>
holdover from a much earlier version of the series. =A0It should be<br>
converted to a libxl__save_helper_state and then the dss extracted<br>
with CONTAINER_OF.<br>
<br>
2. The way remus works means that the toolstack save callback is<br>
invoked more than once, which the helper&#39;s implementation was not<br>
prepared to deal with. =A0Fix this by moving the rewind of the fd into<br>
the helper.<br>
<br>
Fixes for these are below. =A0With this, on top of my series, seem to I<br>
get the same behaviour as with the baseline. =A0Would you like to try it ?<=
br>
<br></blockquote><div><br></div></div><div>Sure, I ll give it a shot.</div>=
<div>Btw, my earlier mail was in response to remus not</div><div>working on=
 the baseline setup on your dev environment.</div><div><div class=3D"h5">

<div><br></div></div></div></div></blockquote><div><br></div><div>The fix w=
orks for 2 out of 3 cases</div><div>=A0blackhole replication (xl remus -b)<=
/div><div>=A0localhost replication with failover i.e. destroy primary (xl r=
emus domU localhost)</div>

<div><br></div><div>However, it crashes the guest for localhost replication=
, when I destroy the backup</div><div>i.e. xl destroy domU--incoming . The =
primary guest would generally resume, but in this</div><div>case its in --s=
c- state.</div>

<div>NB: This seems to happen in baseline xen-unstable too!.=A0</div><div><=
br></div><div><div>xc: error: unexpected PFN mapping failure pfn 180e map_m=
fn 43b808 p2m_mfn 43b808: Internal error</div><div>libxl: error: libxl_crea=
te.c:760:libxl__xc_domain_restore_done: restoring domain: Resource temporar=
ily unavailable</div>

<div>libxl: error: libxl_create.c:844:domcreate_rebuild_done: cannot (re-)b=
uild domain: -3</div><div>libxl: error: libxl.c:1220:libxl_domain_destroy: =
non-existant domain 17</div><div>libxl: error: libxl_create.c:995:domcreate=
_complete: unable to destroy domain 17 following failed creation</div>

<div>migration target: Domain creation failed (code -3).</div><div>..</div>=
<div>Total Data Sent=3D 12.597 MB</div><div>libxl: debug: libxl_dom.c:801:l=
ibxl__domain_suspend_common_callback: issuing PV suspend request via XenBus=
 control node</div>

<div>libxl: debug: libxl_dom.c:805:libxl__domain_suspend_common_callback: w=
ait for the guest to acknowledge suspend request</div><div>libxl: debug: li=
bxl_dom.c:852:libxl__domain_suspend_common_callback: guest acknowledged sus=
pend request</div>

<div>libxl: debug: libxl_dom.c:856:libxl__domain_suspend_common_callback: w=
ait for the guest to suspend</div><div>libxl: debug: libxl_dom.c:870:libxl_=
_domain_suspend_common_callback: guest has suspended</div><div>pagetables=
=3D2,cache_misses=3D0,emptypages=3D45</div>

<div>libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream trunca=
ted reading ipc msg header from domain 16 save/restore helper stdout pipe</=
div><div>libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: doma=
in 16 save/restore helper [3148] died due to fatal signal Broken pipe</div>

<div>libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x1b08c80: com=
plete, rc=3D-3</div><div>libxl: debug: libxl_event.c:1406:libxl__ao__destro=
y: ao 0x1b08c80: destroy</div><div>remus sender: libxl_domain_suspend faile=
d (rc=3D-3)</div>

<div>Remus: Backup failed? resuming domain at primary.</div><div>xc: debug:=
 hypercall buffer: total allocations:2116 total releases:2116</div><div>xc:=
 debug: hypercall buffer: current allocations:0 maximum allocations:2</div>

<div>xc: debug: hypercall buffer: cache current size:2</div><div>xc: debug:=
 hypercall buffer: cache hits:1729 misses:2 toobig:385</div></div><div><br>=
</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">

<div class=3D"gmail_quote"><div><div class=3D"h5"><div></div><div>=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
index abc5932..069aca1 100644<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void *d=
ata)<br>
<br>
=A0static int libxl__remus_domain_resume_callback(void *data)<br>
<div>=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
<div>+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_OF(shs, *dss, =
shs);<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
</div> =A0 =A0 /* Resumes the domain and the device model */<br>
@@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc *egc=
,<br>
<br>
=A0static void libxl__remus_domain_checkpoint_callback(void *data)<br>
<div>=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_OF(shs, *dss, shs);=
<br>
 =A0 =A0 libxl__egc *egc =3D dss-&gt;shs.egc;<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_call=
out.c<br>
index 6332beb..078b7ee 100644<br>
--- a/tools/libxl/libxl_save_callout.c<br>
+++ b/tools/libxl/libxl_save_callout.c<br>
@@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__dom=
ain_suspend_state *dss,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 toolstack_=
data_buf, toolstack_data_len,<br>
<div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot=
;toolstack data tmpfile&quot;, 0);<br>
</div><div> =A0 =A0 =A0 =A0 if (r) { rc =3D ERROR_FAIL; goto out; }<br>
</div><div>-<br>
- =A0 =A0 =A0 =A0r =3D lseek(toolstack_data_fd, 0, SEEK_SET);<br>
- =A0 =A0 =A0 =A0if (r) {<br>
- =A0 =A0 =A0 =A0 =A0 =A0LOGE(ERROR, &quot;rewind toolstack data tmpfile&qu=
ot;);<br>
</div>- =A0 =A0 =A0 =A0 =A0 =A0rc =3D ERROR_FAIL;<br>
- =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
<div>- =A0 =A0 =A0 =A0}<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 const unsigned long argnums[] =3D {<br>
</div>diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save=
_helper.c<br>
index 3bdfa28..772251a 100644<br>
--- a/tools/libxl/libxl_save_helper.c<br>
+++ b/tools/libxl/libxl_save_helper.c<br>
@@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t =
**buf,<br>
=A0{<br>
 =A0 =A0 assert(toolstack_save_fd &gt; 0);<br>
<br>
+ =A0 =A0int r =3D lseek(toolstack_save_fd, 0, SEEK_SET);<br>
+ =A0 =A0if (r) fail(errno,&quot;rewind toolstack data tmpfile&quot;);<br>
+<br>
<div> =A0 =A0 *buf =3D xmalloc(toolstack_save_len);<br>
- =A0 =A0int r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len=
);<br>
+ =A0 =A0r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len);<b=
r>
 =A0 =A0 if (r&lt;0) fail(errno,&quot;read toolstack data&quot;);<br>
</div><div> =A0 =A0 if (r=3D=3D0) fail(0,&quot;read toolstack data eof&quot=
;);<br>
<br>
</div>- =A0 =A0toolstack_save_fd =3D -1;<br>
 =A0 =A0 *len =3D toolstack_save_len;<br>
 =A0 =A0 return 0;<br>
=A0}<br>
<br>
</blockquote></div></div></div><br>
</blockquote></div><br>

--000e0ce0d65eb6a3a704c376e9b8--


--===============8834480936510365647==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8834480936510365647==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 16:43:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 16: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 1SjvL1-0005KI-7z; Wed, 27 Jun 2012 16:43:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SjvL0-0005K7-3i
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 16:43:30 +0000
Received: from [193.109.254.147:51493] by server-11.bemta-14.messagelabs.com
	id 1C/99-24843-1383BEF4; Wed, 27 Jun 2012 16:43:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340815406!8892778!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27895 invoked from network); 27 Jun 2012 16:43:27 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 16:43:27 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5RGhNBT029637
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:43:24 -0700
Received: by bkwj10 with SMTP id j10so1314693bkw.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 09:43:21 -0700 (PDT)
Received: by 10.205.136.3 with SMTP id ii3mr41668bkc.101.1340815401460; Wed,
	27 Jun 2012 09:43:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Wed, 27 Jun 2012 09:42:41 -0700 (PDT)
In-Reply-To: <CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
	<20459.11730.332905.175948@mariner.uk.xensource.com>
	<CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 27 Jun 2012 12:42:41 -0400
Message-ID: <CAP8mzPM6F=gKB4hGi1JZqkuvYzcOmv8-SfLJODRC5Ls0kkiuUQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8834480936510365647=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8834480936510365647==
Content-Type: multipart/alternative; boundary=000e0ce0d65eb6a3a704c376e9b8

--000e0ce0d65eb6a3a704c376e9b8
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 27, 2012 at 12:09 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Wed, Jun 27, 2012 at 11:59 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:
>
>> Ian Jackson writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run
>> in a separate process"):
>> > However, when I apply my series, I can indeed produce an assertion
>> > failure:
>> ...
>> > So I have indeed made matters worse.
>>
>> I found two bugs:
>>
>> 1. The void* passed to the callback was being treated as a
>> libxl__domain_suspend_state* by the remus callbacks; this is a
>> holdover from a much earlier version of the series.  It should be
>> converted to a libxl__save_helper_state and then the dss extracted
>> with CONTAINER_OF.
>>
>> 2. The way remus works means that the toolstack save callback is
>> invoked more than once, which the helper's implementation was not
>> prepared to deal with.  Fix this by moving the rewind of the fd into
>> the helper.
>>
>> Fixes for these are below.  With this, on top of my series, seem to I
>> get the same behaviour as with the baseline.  Would you like to try it ?
>>
>>
> Sure, I ll give it a shot.
> Btw, my earlier mail was in response to remus not
> working on the baseline setup on your dev environment.
>
>
The fix works for 2 out of 3 cases
 blackhole replication (xl remus -b)
 localhost replication with failover i.e. destroy primary (xl remus domU
localhost)

However, it crashes the guest for localhost replication, when I destroy the
backup
i.e. xl destroy domU--incoming . The primary guest would generally resume,
but in this
case its in --sc- state.
NB: This seems to happen in baseline xen-unstable too!.

xc: error: unexpected PFN mapping failure pfn 180e map_mfn 43b808 p2m_mfn
43b808: Internal error
libxl: error: libxl_create.c:760:libxl__xc_domain_restore_done: restoring
domain: Resource temporarily unavailable
libxl: error: libxl_create.c:844:domcreate_rebuild_done: cannot (re-)build
domain: -3
libxl: error: libxl.c:1220:libxl_domain_destroy: non-existant domain 17
libxl: error: libxl_create.c:995:domcreate_complete: unable to destroy
domain 17 following failed creation
migration target: Domain creation failed (code -3).
..
Total Data Sent= 12.597 MB
libxl: debug: libxl_dom.c:801:libxl__domain_suspend_common_callback:
issuing PV suspend request via XenBus control node
libxl: debug: libxl_dom.c:805:libxl__domain_suspend_common_callback: wait
for the guest to acknowledge suspend request
libxl: debug: libxl_dom.c:852:libxl__domain_suspend_common_callback: guest
acknowledged suspend request
libxl: debug: libxl_dom.c:856:libxl__domain_suspend_common_callback: wait
for the guest to suspend
libxl: debug: libxl_dom.c:870:libxl__domain_suspend_common_callback: guest
has suspended
pagetables=2,cache_misses=0,emptypages=45
libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated
reading ipc msg header from domain 16 save/restore helper stdout pipe
libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 16
save/restore helper [3148] died due to fatal signal Broken pipe
libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x1b08c80:
complete, rc=-3
libxl: debug: libxl_event.c:1406:libxl__ao__destroy: ao 0x1b08c80: destroy
remus sender: libxl_domain_suspend failed (rc=-3)
Remus: Backup failed? resuming domain at primary.
xc: debug: hypercall buffer: total allocations:2116 total releases:2116
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1729 misses:2 toobig:385




>
>
>> Thanks,
>> Ian.
>>
>> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> index abc5932..069aca1 100644
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
>> @@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void
>> *data)
>>
>>  static int libxl__remus_domain_resume_callback(void *data)
>>  {
>> -    libxl__domain_suspend_state *dss = data;
>> +    libxl__save_helper_state *shs = data;
>> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>>     STATE_AO_GC(dss->ao);
>>
>>      /* Resumes the domain and the device model */
>> @@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc
>> *egc,
>>
>>  static void libxl__remus_domain_checkpoint_callback(void *data)
>>  {
>> -    libxl__domain_suspend_state *dss = data;
>> +    libxl__save_helper_state *shs = data;
>> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>>     libxl__egc *egc = dss->shs.egc;
>>     STATE_AO_GC(dss->ao);
>>
>> diff --git a/tools/libxl/libxl_save_callout.c
>> b/tools/libxl/libxl_save_callout.c
>> index 6332beb..078b7ee 100644
>> --- a/tools/libxl/libxl_save_callout.c
>> +++ b/tools/libxl/libxl_save_callout.c
>> @@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc,
>> libxl__domain_suspend_state *dss,
>>                                 toolstack_data_buf, toolstack_data_len,
>>                                  "toolstack data tmpfile", 0);
>>          if (r) { rc = ERROR_FAIL; goto out; }
>> -
>> -        r = lseek(toolstack_data_fd, 0, SEEK_SET);
>> -        if (r) {
>> -            LOGE(ERROR, "rewind toolstack data tmpfile");
>> -            rc = ERROR_FAIL;
>> -            goto out;
>> -        }
>>     }
>>
>>     const unsigned long argnums[] = {
>> diff --git a/tools/libxl/libxl_save_helper.c
>> b/tools/libxl/libxl_save_helper.c
>> index 3bdfa28..772251a 100644
>> --- a/tools/libxl/libxl_save_helper.c
>> +++ b/tools/libxl/libxl_save_helper.c
>> @@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid,
>> uint8_t **buf,
>>  {
>>     assert(toolstack_save_fd > 0);
>>
>> +    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
>> +    if (r) fail(errno,"rewind toolstack data tmpfile");
>> +
>>      *buf = xmalloc(toolstack_save_len);
>> -    int r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
>> +    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
>>     if (r<0) fail(errno,"read toolstack data");
>>      if (r==0) fail(0,"read toolstack data eof");
>>
>> -    toolstack_save_fd = -1;
>>     *len = toolstack_save_len;
>>     return 0;
>>  }
>>
>>
>

--000e0ce0d65eb6a3a704c376e9b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 12:09 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:<br><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">

<div class=3D"im">On Wed, Jun 27, 2012 at 11:59 AM, Ian Jackson <span dir=
=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu.citrix.com" target=3D"_blank"=
>Ian.Jackson@eu.citrix.com</a>&gt;</span> wrote:<br></div><div class=3D"gma=
il_quote">

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
Ian Jackson writes (&quot;Re: [PATCH v5 00/21] libxl: domain save/restore: =
run in a separate process&quot;):<br>
<div>&gt; However, when I apply my series, I can indeed produce an assertio=
n<br>
&gt; failure:<br>
</div>...<br>
<div>&gt; So I have indeed made matters worse.<br>
<br>
</div>I found two bugs:<br>
<br>
1. The void* passed to the callback was being treated as a<br>
libxl__domain_suspend_state* by the remus callbacks; this is a<br>
holdover from a much earlier version of the series. =A0It should be<br>
converted to a libxl__save_helper_state and then the dss extracted<br>
with CONTAINER_OF.<br>
<br>
2. The way remus works means that the toolstack save callback is<br>
invoked more than once, which the helper&#39;s implementation was not<br>
prepared to deal with. =A0Fix this by moving the rewind of the fd into<br>
the helper.<br>
<br>
Fixes for these are below. =A0With this, on top of my series, seem to I<br>
get the same behaviour as with the baseline. =A0Would you like to try it ?<=
br>
<br></blockquote><div><br></div></div><div>Sure, I ll give it a shot.</div>=
<div>Btw, my earlier mail was in response to remus not</div><div>working on=
 the baseline setup on your dev environment.</div><div><div class=3D"h5">

<div><br></div></div></div></div></blockquote><div><br></div><div>The fix w=
orks for 2 out of 3 cases</div><div>=A0blackhole replication (xl remus -b)<=
/div><div>=A0localhost replication with failover i.e. destroy primary (xl r=
emus domU localhost)</div>

<div><br></div><div>However, it crashes the guest for localhost replication=
, when I destroy the backup</div><div>i.e. xl destroy domU--incoming . The =
primary guest would generally resume, but in this</div><div>case its in --s=
c- state.</div>

<div>NB: This seems to happen in baseline xen-unstable too!.=A0</div><div><=
br></div><div><div>xc: error: unexpected PFN mapping failure pfn 180e map_m=
fn 43b808 p2m_mfn 43b808: Internal error</div><div>libxl: error: libxl_crea=
te.c:760:libxl__xc_domain_restore_done: restoring domain: Resource temporar=
ily unavailable</div>

<div>libxl: error: libxl_create.c:844:domcreate_rebuild_done: cannot (re-)b=
uild domain: -3</div><div>libxl: error: libxl.c:1220:libxl_domain_destroy: =
non-existant domain 17</div><div>libxl: error: libxl_create.c:995:domcreate=
_complete: unable to destroy domain 17 following failed creation</div>

<div>migration target: Domain creation failed (code -3).</div><div>..</div>=
<div>Total Data Sent=3D 12.597 MB</div><div>libxl: debug: libxl_dom.c:801:l=
ibxl__domain_suspend_common_callback: issuing PV suspend request via XenBus=
 control node</div>

<div>libxl: debug: libxl_dom.c:805:libxl__domain_suspend_common_callback: w=
ait for the guest to acknowledge suspend request</div><div>libxl: debug: li=
bxl_dom.c:852:libxl__domain_suspend_common_callback: guest acknowledged sus=
pend request</div>

<div>libxl: debug: libxl_dom.c:856:libxl__domain_suspend_common_callback: w=
ait for the guest to suspend</div><div>libxl: debug: libxl_dom.c:870:libxl_=
_domain_suspend_common_callback: guest has suspended</div><div>pagetables=
=3D2,cache_misses=3D0,emptypages=3D45</div>

<div>libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream trunca=
ted reading ipc msg header from domain 16 save/restore helper stdout pipe</=
div><div>libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: doma=
in 16 save/restore helper [3148] died due to fatal signal Broken pipe</div>

<div>libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x1b08c80: com=
plete, rc=3D-3</div><div>libxl: debug: libxl_event.c:1406:libxl__ao__destro=
y: ao 0x1b08c80: destroy</div><div>remus sender: libxl_domain_suspend faile=
d (rc=3D-3)</div>

<div>Remus: Backup failed? resuming domain at primary.</div><div>xc: debug:=
 hypercall buffer: total allocations:2116 total releases:2116</div><div>xc:=
 debug: hypercall buffer: current allocations:0 maximum allocations:2</div>

<div>xc: debug: hypercall buffer: cache current size:2</div><div>xc: debug:=
 hypercall buffer: cache hits:1729 misses:2 toobig:385</div></div><div><br>=
</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">

<div class=3D"gmail_quote"><div><div class=3D"h5"><div></div><div>=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
index abc5932..069aca1 100644<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -984,7 +984,8 @@ static int libxl__remus_domain_suspend_callback(void *d=
ata)<br>
<br>
=A0static int libxl__remus_domain_resume_callback(void *data)<br>
<div>=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
<div>+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_OF(shs, *dss, =
shs);<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
</div> =A0 =A0 /* Resumes the domain and the device model */<br>
@@ -1002,7 +1003,8 @@ static void remus_checkpoint_dm_saved(libxl__egc *egc=
,<br>
<br>
=A0static void libxl__remus_domain_checkpoint_callback(void *data)<br>
<div>=A0{<br>
- =A0 =A0libxl__domain_suspend_state *dss =3D data;<br>
</div>+ =A0 =A0libxl__save_helper_state *shs =3D data;<br>
+ =A0 =A0libxl__domain_suspend_state *dss =3D CONTAINER_OF(shs, *dss, shs);=
<br>
 =A0 =A0 libxl__egc *egc =3D dss-&gt;shs.egc;<br>
 =A0 =A0 STATE_AO_GC(dss-&gt;ao);<br>
<br>
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_call=
out.c<br>
index 6332beb..078b7ee 100644<br>
--- a/tools/libxl/libxl_save_callout.c<br>
+++ b/tools/libxl/libxl_save_callout.c<br>
@@ -105,13 +105,6 @@ void libxl__xc_domain_save(libxl__egc *egc, libxl__dom=
ain_suspend_state *dss,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 toolstack_=
data_buf, toolstack_data_len,<br>
<div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot=
;toolstack data tmpfile&quot;, 0);<br>
</div><div> =A0 =A0 =A0 =A0 if (r) { rc =3D ERROR_FAIL; goto out; }<br>
</div><div>-<br>
- =A0 =A0 =A0 =A0r =3D lseek(toolstack_data_fd, 0, SEEK_SET);<br>
- =A0 =A0 =A0 =A0if (r) {<br>
- =A0 =A0 =A0 =A0 =A0 =A0LOGE(ERROR, &quot;rewind toolstack data tmpfile&qu=
ot;);<br>
</div>- =A0 =A0 =A0 =A0 =A0 =A0rc =3D ERROR_FAIL;<br>
- =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
<div>- =A0 =A0 =A0 =A0}<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 const unsigned long argnums[] =3D {<br>
</div>diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save=
_helper.c<br>
index 3bdfa28..772251a 100644<br>
--- a/tools/libxl/libxl_save_helper.c<br>
+++ b/tools/libxl/libxl_save_helper.c<br>
@@ -171,12 +171,14 @@ static int toolstack_save_cb(uint32_t domid, uint8_t =
**buf,<br>
=A0{<br>
 =A0 =A0 assert(toolstack_save_fd &gt; 0);<br>
<br>
+ =A0 =A0int r =3D lseek(toolstack_save_fd, 0, SEEK_SET);<br>
+ =A0 =A0if (r) fail(errno,&quot;rewind toolstack data tmpfile&quot;);<br>
+<br>
<div> =A0 =A0 *buf =3D xmalloc(toolstack_save_len);<br>
- =A0 =A0int r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len=
);<br>
+ =A0 =A0r =3D read_exactly(toolstack_save_fd, *buf, toolstack_save_len);<b=
r>
 =A0 =A0 if (r&lt;0) fail(errno,&quot;read toolstack data&quot;);<br>
</div><div> =A0 =A0 if (r=3D=3D0) fail(0,&quot;read toolstack data eof&quot=
;);<br>
<br>
</div>- =A0 =A0toolstack_save_fd =3D -1;<br>
 =A0 =A0 *len =3D toolstack_save_len;<br>
 =A0 =A0 return 0;<br>
=A0}<br>
<br>
</blockquote></div></div></div><br>
</blockquote></div><br>

--000e0ce0d65eb6a3a704c376e9b8--


--===============8834480936510365647==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8834480936510365647==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjviM-0005t7-33; Wed, 27 Jun 2012 17:07:38 +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 1SjviK-0005sr-Pa
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:36 +0000
Received: from [193.109.254.147:61950] by server-12.bemta-14.messagelabs.com
	id DA/D4-30461-7DD3BEF4; Wed, 27 Jun 2012 17:07:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20511 invoked from network); 27 Jun 2012 17:07:35 -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;
	27 Jun 2012 17:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260452"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-GS;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: 71a22d6d940f27d8dfbcfc12d1377e4622f981bd
Message-ID: <71a22d6d940f27d8dfbc.1340816251@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:31 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4] xen,
 pod: Try to reclaim superpages when ballooning 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815812 -3600
# Node ID 71a22d6d940f27d8dfbcfc12d1377e4622f981bd
# Parent  c71f52608fd8867062cc40a1354305f2af17b2c3
xen,pod: Try to reclaim superpages when ballooning down

Windows balloon drivers can typically only get 4k pages from the kernel,
and so hand them back at that level.  Try to regain superpages by checking
the superpage frame that the 4k page is in to see if we can reclaim the whole
thing for the PoD cache.

This also modifies p2m_pod_zero_check_superpage() to return SUPERPAGE_PAGES on
success.

v2:
 - Rewritten to simply to the check as in demand-fault case, without needing
   to know that the p2m entry is a superpage.
 - Also, took out the re-writing of the reclaim loop, leaving it optimized for
   4k pages (by far the most common case), and simplifying the patch.

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -488,6 +488,10 @@ p2m_pod_offline_or_broken_replace(struct
     return;
 }
 
+static int
+p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn);
+
+
 /* This function is needed for two reasons:
  * + To properly handle clearing of PoD entries
  * + To "steal back" memory being freed for the PoD cache, rather than
@@ -505,8 +509,8 @@ p2m_pod_decrease_reservation(struct doma
     int i;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    int steal_for_cache = 0;
-    int pod = 0, nonpod = 0, ram = 0;
+    int steal_for_cache;
+    int pod, nonpod, ram;
 
     gfn_lock(p2m, gpfn, order);
     pod_lock(p2m);    
@@ -516,13 +520,15 @@ p2m_pod_decrease_reservation(struct doma
     if ( p2m->pod.entry_count == 0 )
         goto out_unlock;
 
+    if ( unlikely(d->is_dying) )
+        goto out_unlock;
+
+recount:
+    pod = nonpod = ram = 0;
+
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    if ( unlikely(d->is_dying) )
-        goto out_unlock;
-
-    /* See what's in here. */
     /* FIXME: Add contiguous; query for PSE entries? */
     for ( i=0; i<(1<<order); i++)
     {
@@ -556,7 +562,16 @@ p2m_pod_decrease_reservation(struct doma
         goto out_entry_check;
     }
 
-    /* FIXME: Steal contig 2-meg regions for cache */
+    /* Try to grab entire superpages if possible.  Since the common case is for drivers
+     * to pass back singleton pages, see if we can take the whole page back and mark the
+     * rest PoD. */
+    if ( steal_for_cache
+         && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
+    {
+        /* Since order may be arbitrary, we may have taken more or less
+         * than we were actually asked to; so just re-count from scratch */
+        goto recount;
+    }
 
     /* Process as long as:
      * + There are PoD entries to handle, or
@@ -758,6 +773,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     p2m_pod_cache_add(p2m, mfn_to_page(mfn0), PAGE_ORDER_2M);
     p2m->pod.entry_count += SUPERPAGE_PAGES;
 
+    ret = SUPERPAGE_PAGES;
+
 out_reset:
     if ( reset )
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjviM-0005t7-33; Wed, 27 Jun 2012 17:07:38 +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 1SjviK-0005sr-Pa
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:36 +0000
Received: from [193.109.254.147:61950] by server-12.bemta-14.messagelabs.com
	id DA/D4-30461-7DD3BEF4; Wed, 27 Jun 2012 17:07:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20511 invoked from network); 27 Jun 2012 17:07:35 -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;
	27 Jun 2012 17:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260452"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-GS;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: 71a22d6d940f27d8dfbcfc12d1377e4622f981bd
Message-ID: <71a22d6d940f27d8dfbc.1340816251@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:31 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 4] xen,
 pod: Try to reclaim superpages when ballooning 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815812 -3600
# Node ID 71a22d6d940f27d8dfbcfc12d1377e4622f981bd
# Parent  c71f52608fd8867062cc40a1354305f2af17b2c3
xen,pod: Try to reclaim superpages when ballooning down

Windows balloon drivers can typically only get 4k pages from the kernel,
and so hand them back at that level.  Try to regain superpages by checking
the superpage frame that the 4k page is in to see if we can reclaim the whole
thing for the PoD cache.

This also modifies p2m_pod_zero_check_superpage() to return SUPERPAGE_PAGES on
success.

v2:
 - Rewritten to simply to the check as in demand-fault case, without needing
   to know that the p2m entry is a superpage.
 - Also, took out the re-writing of the reclaim loop, leaving it optimized for
   4k pages (by far the most common case), and simplifying the patch.

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -488,6 +488,10 @@ p2m_pod_offline_or_broken_replace(struct
     return;
 }
 
+static int
+p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn);
+
+
 /* This function is needed for two reasons:
  * + To properly handle clearing of PoD entries
  * + To "steal back" memory being freed for the PoD cache, rather than
@@ -505,8 +509,8 @@ p2m_pod_decrease_reservation(struct doma
     int i;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    int steal_for_cache = 0;
-    int pod = 0, nonpod = 0, ram = 0;
+    int steal_for_cache;
+    int pod, nonpod, ram;
 
     gfn_lock(p2m, gpfn, order);
     pod_lock(p2m);    
@@ -516,13 +520,15 @@ p2m_pod_decrease_reservation(struct doma
     if ( p2m->pod.entry_count == 0 )
         goto out_unlock;
 
+    if ( unlikely(d->is_dying) )
+        goto out_unlock;
+
+recount:
+    pod = nonpod = ram = 0;
+
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    if ( unlikely(d->is_dying) )
-        goto out_unlock;
-
-    /* See what's in here. */
     /* FIXME: Add contiguous; query for PSE entries? */
     for ( i=0; i<(1<<order); i++)
     {
@@ -556,7 +562,16 @@ p2m_pod_decrease_reservation(struct doma
         goto out_entry_check;
     }
 
-    /* FIXME: Steal contig 2-meg regions for cache */
+    /* Try to grab entire superpages if possible.  Since the common case is for drivers
+     * to pass back singleton pages, see if we can take the whole page back and mark the
+     * rest PoD. */
+    if ( steal_for_cache
+         && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
+    {
+        /* Since order may be arbitrary, we may have taken more or less
+         * than we were actually asked to; so just re-count from scratch */
+        goto recount;
+    }
 
     /* Process as long as:
      * + There are PoD entries to handle, or
@@ -758,6 +773,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     p2m_pod_cache_add(p2m, mfn_to_page(mfn0), PAGE_ORDER_2M);
     p2m->pod.entry_count += SUPERPAGE_PAGES;
 
+    ret = SUPERPAGE_PAGES;
+
 out_reset:
     if ( reset )
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjviN-0005tZ-7q; Wed, 27 Jun 2012 17:07:39 +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 1SjviM-0005t6-Ch
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:38 +0000
Received: from [193.109.254.147:23588] by server-4.bemta-14.messagelabs.com id
	52/C5-02077-9DD3BEF4; Wed, 27 Jun 2012 17:07:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20635 invoked from network); 27 Jun 2012 17:07:36 -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;
	27 Jun 2012 17:07:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260455"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-Fi;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: c71f52608fd8867062cc40a1354305f2af17b2c3
Message-ID: <c71f52608fd8867062cc.1340816250@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:30 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4] xen, pod: Only sweep in an emergency,
 and only for 4k 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815812 -3600
# Node ID c71f52608fd8867062cc40a1354305f2af17b2c3
# Parent  ea827c449088a1017b6e5a9564eb33df70f8a9c6
xen,pod: Only sweep in an emergency, and only for 4k pages

Testing has shown that doing sweeps for superpages slows down boot
significantly, but does not result in a significantly higher number of
superpages after boot.  Early sweeping for 4k pages causes superpages
to be broken up unnecessarily.

Only sweep if we're really out of memory.

v2:
 - Move unrelated code-motion hunk to another patch

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -880,34 +880,6 @@ p2m_pod_zero_check(struct p2m_domain *p2
 }
 
 #define POD_SWEEP_LIMIT 1024
-static void
-p2m_pod_emergency_sweep_super(struct p2m_domain *p2m)
-{
-    unsigned long i, start, limit;
-
-    if ( p2m->pod.reclaim_super == 0 )
-    {
-        p2m->pod.reclaim_super = (p2m->pod.max_guest>>PAGE_ORDER_2M)<<PAGE_ORDER_2M;
-        p2m->pod.reclaim_super -= SUPERPAGE_PAGES;
-    }
-    
-    start = p2m->pod.reclaim_super;
-    limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
-
-    for ( i=p2m->pod.reclaim_super ; i > 0 ; i -= SUPERPAGE_PAGES )
-    {
-        p2m_pod_zero_check_superpage(p2m, i);
-        /* Stop if we're past our limit and we have found *something*.
-         *
-         * NB that this is a zero-sum game; we're increasing our cache size
-         * by increasing our 'debt'.  Since we hold the p2m lock,
-         * (entry_count - count) must remain the same. */
-        if ( !page_list_empty(&p2m->pod.super) &&  i < limit )
-            break;
-    }
-
-    p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
-}
 
 /* When populating a new superpage, look at recently populated superpages
  * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
@@ -1022,27 +994,12 @@ p2m_pod_demand_populate(struct p2m_domai
         return 0;
     }
 
-    /* Once we've ballooned down enough that we can fill the remaining
-     * PoD entries from the cache, don't sweep even if the particular
-     * list we want to use is empty: that can lead to thrashing zero pages 
-     * through the cache for no good reason.  */
-    if ( p2m->pod.entry_count > p2m->pod.count )
-    {
+    /* Only sweep if we're actually out of memory.  Doing anything else
+     * causes unnecessary time and fragmentation of superpages in the p2m. */
+    if ( p2m->pod.count == 0 )
+        p2m_pod_emergency_sweep(p2m);
 
-        /* If we're low, start a sweep */
-        if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
-            /* Note that sweeps scan other ranges in the p2m. In an scenario
-             * in which p2m locks are fine-grained, this may result in deadlock.
-             * Using trylock on the gfn's as we sweep would avoid it. */
-            p2m_pod_emergency_sweep_super(p2m);
-
-        if ( page_list_empty(&p2m->pod.single) &&
-             ( ( order == PAGE_ORDER_4K )
-               || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
-            /* Same comment regarding deadlock applies */
-            p2m_pod_emergency_sweep(p2m);
-    }
-
+    /* If the sweep failed, give up. */
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjviO-0005ty-L3; Wed, 27 Jun 2012 17:07:40 +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 1SjviN-0005tJ-37
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:39 +0000
Received: from [85.158.138.51:22400] by server-11.bemta-3.messagelabs.com id
	72/45-02904-ADD3BEF4; Wed, 27 Jun 2012 17:07:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340816855!29742189!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19037 invoked from network); 27 Jun 2012 17:07:37 -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;
	27 Jun 2012 17:07:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260461"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-EE;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:27 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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

xen,pod: Populate-on-demand reclaim improvements

Rework populate-on-demand sweeping

Last summer I did some work on testing whether our PoD sweeping code
was achieving its goals: namely, never crashing unnecessairly,
minimizing boot time, and maximizing the number of superpages in the
p2m table.

This is the resulting patch series.

v2:
 - Move cosmetic code-motion hunk into its own patch
 - Address various comments
 - Include a simplified version of the balloon reclaim reclamation patch

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjviO-0005ty-L3; Wed, 27 Jun 2012 17:07:40 +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 1SjviN-0005tJ-37
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:39 +0000
Received: from [85.158.138.51:22400] by server-11.bemta-3.messagelabs.com id
	72/45-02904-ADD3BEF4; Wed, 27 Jun 2012 17:07:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340816855!29742189!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19037 invoked from network); 27 Jun 2012 17:07:37 -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;
	27 Jun 2012 17:07:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260461"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:33 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-EE;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:27 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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

xen,pod: Populate-on-demand reclaim improvements

Rework populate-on-demand sweeping

Last summer I did some work on testing whether our PoD sweeping code
was achieving its goals: namely, never crashing unnecessairly,
minimizing boot time, and maximizing the number of superpages in the
p2m table.

This is the resulting patch series.

v2:
 - Move cosmetic code-motion hunk into its own patch
 - Address various comments
 - Include a simplified version of the balloon reclaim reclamation patch

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjviN-0005tZ-7q; Wed, 27 Jun 2012 17:07:39 +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 1SjviM-0005t6-Ch
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:38 +0000
Received: from [193.109.254.147:23588] by server-4.bemta-14.messagelabs.com id
	52/C5-02077-9DD3BEF4; Wed, 27 Jun 2012 17:07:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20635 invoked from network); 27 Jun 2012 17:07:36 -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;
	27 Jun 2012 17:07:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260455"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-Fi;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: c71f52608fd8867062cc40a1354305f2af17b2c3
Message-ID: <c71f52608fd8867062cc.1340816250@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:30 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 4] xen, pod: Only sweep in an emergency,
 and only for 4k 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815812 -3600
# Node ID c71f52608fd8867062cc40a1354305f2af17b2c3
# Parent  ea827c449088a1017b6e5a9564eb33df70f8a9c6
xen,pod: Only sweep in an emergency, and only for 4k pages

Testing has shown that doing sweeps for superpages slows down boot
significantly, but does not result in a significantly higher number of
superpages after boot.  Early sweeping for 4k pages causes superpages
to be broken up unnecessarily.

Only sweep if we're really out of memory.

v2:
 - Move unrelated code-motion hunk to another patch

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -880,34 +880,6 @@ p2m_pod_zero_check(struct p2m_domain *p2
 }
 
 #define POD_SWEEP_LIMIT 1024
-static void
-p2m_pod_emergency_sweep_super(struct p2m_domain *p2m)
-{
-    unsigned long i, start, limit;
-
-    if ( p2m->pod.reclaim_super == 0 )
-    {
-        p2m->pod.reclaim_super = (p2m->pod.max_guest>>PAGE_ORDER_2M)<<PAGE_ORDER_2M;
-        p2m->pod.reclaim_super -= SUPERPAGE_PAGES;
-    }
-    
-    start = p2m->pod.reclaim_super;
-    limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
-
-    for ( i=p2m->pod.reclaim_super ; i > 0 ; i -= SUPERPAGE_PAGES )
-    {
-        p2m_pod_zero_check_superpage(p2m, i);
-        /* Stop if we're past our limit and we have found *something*.
-         *
-         * NB that this is a zero-sum game; we're increasing our cache size
-         * by increasing our 'debt'.  Since we hold the p2m lock,
-         * (entry_count - count) must remain the same. */
-        if ( !page_list_empty(&p2m->pod.super) &&  i < limit )
-            break;
-    }
-
-    p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
-}
 
 /* When populating a new superpage, look at recently populated superpages
  * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
@@ -1022,27 +994,12 @@ p2m_pod_demand_populate(struct p2m_domai
         return 0;
     }
 
-    /* Once we've ballooned down enough that we can fill the remaining
-     * PoD entries from the cache, don't sweep even if the particular
-     * list we want to use is empty: that can lead to thrashing zero pages 
-     * through the cache for no good reason.  */
-    if ( p2m->pod.entry_count > p2m->pod.count )
-    {
+    /* Only sweep if we're actually out of memory.  Doing anything else
+     * causes unnecessary time and fragmentation of superpages in the p2m. */
+    if ( p2m->pod.count == 0 )
+        p2m_pod_emergency_sweep(p2m);
 
-        /* If we're low, start a sweep */
-        if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
-            /* Note that sweeps scan other ranges in the p2m. In an scenario
-             * in which p2m locks are fine-grained, this may result in deadlock.
-             * Using trylock on the gfn's as we sweep would avoid it. */
-            p2m_pod_emergency_sweep_super(p2m);
-
-        if ( page_list_empty(&p2m->pod.single) &&
-             ( ( order == PAGE_ORDER_4K )
-               || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
-            /* Same comment regarding deadlock applies */
-            p2m_pod_emergency_sweep(p2m);
-    }
-
+    /* If the sweep failed, give up. */
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjviM-0005tS-Qn; Wed, 27 Jun 2012 17:07:38 +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 1SjviL-0005sr-9P
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:37 +0000
Received: from [193.109.254.147:61995] by server-12.bemta-14.messagelabs.com
	id 4C/D4-30461-8DD3BEF4; Wed, 27 Jun 2012 17:07:36 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20572 invoked from network); 27 Jun 2012 17:07:35 -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;
	27 Jun 2012 17:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260454"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-El;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: b4e1fec1c98f6cbad666a972f473854518c25500
Message-ID: <b4e1fec1c98f6cbad666.1340816248@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:28 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4] xen,pod: Cosmetic code motion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815810 -3600
# Node ID b4e1fec1c98f6cbad666a972f473854518c25500
# Parent  b91ef972029ddaa110af6463171715ab9070c9d8
xen,pod: Cosmetic code motion

No point in doing the assignment if we're just going to crash anyway.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -1022,13 +1022,13 @@ p2m_pod_demand_populate(struct p2m_domai
             p2m_pod_emergency_sweep(p2m);
     }
 
+    if ( p2m->pod.count == 0 )
+        goto out_of_memory;
+
     /* Keep track of the highest gfn demand-populated by a guest fault */
     if ( gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    if ( p2m->pod.count == 0 )
-        goto out_of_memory;
-
     /* Get a page f/ the cache.  A NULL return value indicates that the
      * 2-meg range should be marked singleton PoD, and retried */
     if ( (p = p2m_pod_cache_get(p2m, order)) == NULL )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjviM-0005tS-Qn; Wed, 27 Jun 2012 17:07:38 +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 1SjviL-0005sr-9P
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:37 +0000
Received: from [193.109.254.147:61995] by server-12.bemta-14.messagelabs.com
	id 4C/D4-30461-8DD3BEF4; Wed, 27 Jun 2012 17:07:36 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20572 invoked from network); 27 Jun 2012 17:07:35 -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;
	27 Jun 2012 17:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260454"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-El;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: b4e1fec1c98f6cbad666a972f473854518c25500
Message-ID: <b4e1fec1c98f6cbad666.1340816248@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:28 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 4] xen,pod: Cosmetic code motion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815810 -3600
# Node ID b4e1fec1c98f6cbad666a972f473854518c25500
# Parent  b91ef972029ddaa110af6463171715ab9070c9d8
xen,pod: Cosmetic code motion

No point in doing the assignment if we're just going to crash anyway.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -1022,13 +1022,13 @@ p2m_pod_demand_populate(struct p2m_domai
             p2m_pod_emergency_sweep(p2m);
     }
 
+    if ( p2m->pod.count == 0 )
+        goto out_of_memory;
+
     /* Keep track of the highest gfn demand-populated by a guest fault */
     if ( gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    if ( p2m->pod.count == 0 )
-        goto out_of_memory;
-
     /* Get a page f/ the cache.  A NULL return value indicates that the
      * 2-meg range should be marked singleton PoD, and retried */
     if ( (p = p2m_pod_cache_get(p2m, order)) == NULL )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjviM-0005tF-Eh; Wed, 27 Jun 2012 17:07:38 +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 1SjviK-0005sq-UB
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:37 +0000
Received: from [193.109.254.147:23432] by server-2.bemta-14.messagelabs.com id
	78/35-01735-7DD3BEF4; Wed, 27 Jun 2012 17:07:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20468 invoked from network); 27 Jun 2012 17:07:34 -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;
	27 Jun 2012 17:07:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260451"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-FE;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: ea827c449088a1017b6e5a9564eb33df70f8a9c6
Message-ID: <ea827c449088a1017b6e.1340816249@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:29 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815812 -3600
# Node ID ea827c449088a1017b6e5a9564eb33df70f8a9c6
# Parent  b4e1fec1c98f6cbad666a972f473854518c25500
xen,pod: Zero-check recently populated pages (checklast)

When demand-populating pages due to guest accesses, check recently populated
pages to see if we can reclaim them for the cache.  This should keep the PoD
cache filled when the start-of-day scrubber is going through.

The number 128 was chosen by experiment.  Windows does its page
scrubbing in parallel; while a small nubmer like 4 works well for
single VMs, it breaks down as multiple vcpus are scrubbing different
pages in parallel.  Increasing to 128 works well for higher numbers of
vcpus.

v2:
 - Wrapped some long lines
 - unsigned int for index, unsigned long for array

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -909,6 +909,27 @@ p2m_pod_emergency_sweep_super(struct p2m
     p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
 }
 
+/* When populating a new superpage, look at recently populated superpages
+ * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
+ * the guest OS is done with them. */
+static void
+p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
+{
+    unsigned long check_gfn;
+
+    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
+
+    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
+
+    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
+
+    p2m->pod.last_populated_index =
+        ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
+
+    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m, check_gfn);
+}
+
+
 #define POD_SWEEP_STRIDE  16
 static void
 p2m_pod_emergency_sweep(struct p2m_domain *p2m)
@@ -1066,6 +1087,12 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    /* Check the last guest demand-populate */
+    if ( p2m->pod.entry_count > p2m->pod.count 
+         && order == 9
+         && q & P2M_ALLOC )
+        p2m_pod_check_last_super(p2m, gfn_aligned);
+
     pod_unlock(p2m);
     return 0;
 out_of_memory:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -287,6 +287,10 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+#define POD_HISTORY_MAX 128
+        /* gpfn of last guest superpage demand-populated */
+        unsigned long    last_populated[POD_HISTORY_MAX]; 
+        unsigned int     last_populated_index;
         mm_lock_t        lock;         /* Locking of private pod structs,   *
                                         * not relying on the p2m lock.      */
     } pod;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjviM-0005tF-Eh; Wed, 27 Jun 2012 17:07:38 +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 1SjviK-0005sq-UB
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 17:07:37 +0000
Received: from [193.109.254.147:23432] by server-2.bemta-14.messagelabs.com id
	78/35-01735-7DD3BEF4; Wed, 27 Jun 2012 17:07:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340816853!1995926!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI1OTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20468 invoked from network); 27 Jun 2012 17:07:34 -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;
	27 Jun 2012 17:07:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="200260451"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 13:07:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 13:07:32 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Sjvaj-0005uL-FE;
	Wed, 27 Jun 2012 17:59:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: ea827c449088a1017b6e5a9564eb33df70f8a9c6
Message-ID: <ea827c449088a1017b6e.1340816249@elijah>
In-Reply-To: <patchbomb.1340816247@elijah>
References: <patchbomb.1340816247@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 27 Jun 2012 17:57:29 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 4] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340815812 -3600
# Node ID ea827c449088a1017b6e5a9564eb33df70f8a9c6
# Parent  b4e1fec1c98f6cbad666a972f473854518c25500
xen,pod: Zero-check recently populated pages (checklast)

When demand-populating pages due to guest accesses, check recently populated
pages to see if we can reclaim them for the cache.  This should keep the PoD
cache filled when the start-of-day scrubber is going through.

The number 128 was chosen by experiment.  Windows does its page
scrubbing in parallel; while a small nubmer like 4 works well for
single VMs, it breaks down as multiple vcpus are scrubbing different
pages in parallel.  Increasing to 128 works well for higher numbers of
vcpus.

v2:
 - Wrapped some long lines
 - unsigned int for index, unsigned long for array

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -909,6 +909,27 @@ p2m_pod_emergency_sweep_super(struct p2m
     p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
 }
 
+/* When populating a new superpage, look at recently populated superpages
+ * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
+ * the guest OS is done with them. */
+static void
+p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
+{
+    unsigned long check_gfn;
+
+    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
+
+    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
+
+    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
+
+    p2m->pod.last_populated_index =
+        ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
+
+    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m, check_gfn);
+}
+
+
 #define POD_SWEEP_STRIDE  16
 static void
 p2m_pod_emergency_sweep(struct p2m_domain *p2m)
@@ -1066,6 +1087,12 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    /* Check the last guest demand-populate */
+    if ( p2m->pod.entry_count > p2m->pod.count 
+         && order == 9
+         && q & P2M_ALLOC )
+        p2m_pod_check_last_super(p2m, gfn_aligned);
+
     pod_unlock(p2m);
     return 0;
 out_of_memory:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -287,6 +287,10 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+#define POD_HISTORY_MAX 128
+        /* gpfn of last guest superpage demand-populated */
+        unsigned long    last_populated[POD_HISTORY_MAX]; 
+        unsigned int     last_populated_index;
         mm_lock_t        lock;         /* Locking of private pod structs,   *
                                         * not relying on the p2m lock.      */
     } pod;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:36:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjw9p-00073z-QB; Wed, 27 Jun 2012 17:36: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 1Sjw9o-00073m-HA
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 17:36:00 +0000
Received: from [85.158.138.51:56984] by server-12.bemta-3.messagelabs.com id
	44/F4-30206-F744BEF4; Wed, 27 Jun 2012 17:35:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340818558!29899019!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 27 Jun 2012 17:35:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 17:35:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13253568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 17:35:58 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 18:35:58 +0100
Message-ID: <4FEB4453.1080307@citrix.com>
Date: Wed, 27 Jun 2012 18:35:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
	<4FE9CF7D.3060403@citrix.com>
	<20457.61221.744769.779520@mariner.uk.xensource.com>
In-Reply-To: <20457.61221.744769.779520@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
>>>> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
>>>> +{
>>>> +    STATE_AO_GC(aodev->ao);
>>>> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
>>>> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>>>> +    int rc = 0;
>>> ...
>>>> +out_fail:
>>>> +    assert(rc);
>>>> +    aodev->rc = rc;
>>>> +    device_xsentries_remove(egc, aodev);
>>>> +    return;
>>>> +}
>>> Firstly, I'm not convinced it's really proper for
>>> libxl__initiate_device_connection to call device_xsentries_remove.
>>> After all device_xsentries_remove is part of the implementation of
>>> libxl__initiate_device_remove.
>> This is part of both flows, both device connection and disconnection.
>
> Well then it should have a proper description and a better name,
> perhaps ?

This functions is latter renamed to "device_hotplug_done", which is the 
point where the callback is done. Since this name is only going to be 
there for like two commits, can we leave it like that?

> As it is it looks like you're doing what amounts to "goto"
> from one "function" to another - only we don't notice it like that
> because it's split into multiple ao callbacks.

Yes, that's mainly one of the consequences of having the same exit point 
for all the possible scenarios. Almost every iteration of this series 
has been adding more of this stuff.

>>> And, secondly, does device_xsentries_remove really do what you want ?
>>> It has a test in it which makes it only do its work if action is
>>> DISCONNECT.
>> Yes, that's because it's called by both flows.
>
> If it is called in the connect flow, won't it be a no-op then ?
> Perhaps I'm being excessively dense here.

It is a no-op here, but in latter patches it becomes the exit point for 
the device addition/removal flow, once it is renamed to device_hotplug_done.

>
>>> Isn't the effect of this that if the xs transaction gets a conflict,
>>> we'll rerun the hotplug scripts, etc. ?  I think I may be confused
>>> here, but I don't understand how this transaction loop is supposed to
>>> work and how it is supposed to relate to the interaction with other
>>> domains, scripts, etc.
>> Yes I see your point. We should disconnect the device (execute hotplug
>> scripts) but since the xenstore entries are already gone (because the
>> transaction is not committed successfully) I don't see anyway to do it,
>> we cannot execute those scripts if the backend entries have been lost.
>>
>>> Indeed it seems to me like your arrangements in libxl__device_disk_add
>>> couldn't work if a non-null t was supplied.  libxl__device_disk_add
>>> would do all the writes in the transaction, but not commit it, so that
>>> none of them are visible to anyone, and then wait for the deivde state
>>> to change, which will never happen.
>> I'm not so sure, is it possible to add a watch to a xenstore path that
>> is inside of a not yet committed transaction? If so this will work fine,
>> the transaction will be finished correctly, and the path will be updated
>> to the correct state (2).
>
> AIUI you can add a watch for any path that you like - the path you ask
> to watch doesn't have to exist.  But you won't (necessarily) see
> events for uncommitted transactions.

Yes, but then we will hit a timeout if the transaction is not actually 
committed.

>> If the transaction is not committed successfully, we will get a timeout
>> from the devstate event and exit.
>
> I think that the only way all this could work is if you firstly, in
> one transaction, create enough of the backend for the hotplug scripts
> to run, and then in a second transaction create the rest of the
> backend plus the frontend.

The hotplug scripts require the backend to be in state 2 (it requires 
that the kernel has initialized the device) so it needs to have a full 
backend set up.

>>> I think this code is a symptom of a problem elsewhere.  When adding a
>>> disk to a domain, it should not be necessary to explicitly ask to add
>>> it to the stubdom too.  But this is not your fault, or your problem
>>> right now.
>> So I assume we can leave this for later.
>
> Yes.
>
> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:36:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjw9p-00073z-QB; Wed, 27 Jun 2012 17:36: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 1Sjw9o-00073m-HA
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 17:36:00 +0000
Received: from [85.158.138.51:56984] by server-12.bemta-3.messagelabs.com id
	44/F4-30206-F744BEF4; Wed, 27 Jun 2012 17:35:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340818558!29899019!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 27 Jun 2012 17:35:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 17:35:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="13253568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 17:35:58 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 18:35:58 +0100
Message-ID: <4FEB4453.1080307@citrix.com>
Date: Wed, 27 Jun 2012 18:35:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-7-git-send-email-roger.pau@citrix.com>
	<20452.22522.766301.170343@mariner.uk.xensource.com>
	<4FE9CF7D.3060403@citrix.com>
	<20457.61221.744769.779520@mariner.uk.xensource.com>
In-Reply-To: <20457.61221.744769.779520@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 06/13] libxl: convert
 libxl_device_disk_add to an async op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
>>>> +void libxl__initiate_device_connection(libxl__egc *egc, libxl__ao_device *aodev)
>>>> +{
>>>> +    STATE_AO_GC(aodev->ao);
>>>> +    char *be_path = libxl__device_backend_path(gc, aodev->dev);
>>>> +    char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>>>> +    int rc = 0;
>>> ...
>>>> +out_fail:
>>>> +    assert(rc);
>>>> +    aodev->rc = rc;
>>>> +    device_xsentries_remove(egc, aodev);
>>>> +    return;
>>>> +}
>>> Firstly, I'm not convinced it's really proper for
>>> libxl__initiate_device_connection to call device_xsentries_remove.
>>> After all device_xsentries_remove is part of the implementation of
>>> libxl__initiate_device_remove.
>> This is part of both flows, both device connection and disconnection.
>
> Well then it should have a proper description and a better name,
> perhaps ?

This functions is latter renamed to "device_hotplug_done", which is the 
point where the callback is done. Since this name is only going to be 
there for like two commits, can we leave it like that?

> As it is it looks like you're doing what amounts to "goto"
> from one "function" to another - only we don't notice it like that
> because it's split into multiple ao callbacks.

Yes, that's mainly one of the consequences of having the same exit point 
for all the possible scenarios. Almost every iteration of this series 
has been adding more of this stuff.

>>> And, secondly, does device_xsentries_remove really do what you want ?
>>> It has a test in it which makes it only do its work if action is
>>> DISCONNECT.
>> Yes, that's because it's called by both flows.
>
> If it is called in the connect flow, won't it be a no-op then ?
> Perhaps I'm being excessively dense here.

It is a no-op here, but in latter patches it becomes the exit point for 
the device addition/removal flow, once it is renamed to device_hotplug_done.

>
>>> Isn't the effect of this that if the xs transaction gets a conflict,
>>> we'll rerun the hotplug scripts, etc. ?  I think I may be confused
>>> here, but I don't understand how this transaction loop is supposed to
>>> work and how it is supposed to relate to the interaction with other
>>> domains, scripts, etc.
>> Yes I see your point. We should disconnect the device (execute hotplug
>> scripts) but since the xenstore entries are already gone (because the
>> transaction is not committed successfully) I don't see anyway to do it,
>> we cannot execute those scripts if the backend entries have been lost.
>>
>>> Indeed it seems to me like your arrangements in libxl__device_disk_add
>>> couldn't work if a non-null t was supplied.  libxl__device_disk_add
>>> would do all the writes in the transaction, but not commit it, so that
>>> none of them are visible to anyone, and then wait for the deivde state
>>> to change, which will never happen.
>> I'm not so sure, is it possible to add a watch to a xenstore path that
>> is inside of a not yet committed transaction? If so this will work fine,
>> the transaction will be finished correctly, and the path will be updated
>> to the correct state (2).
>
> AIUI you can add a watch for any path that you like - the path you ask
> to watch doesn't have to exist.  But you won't (necessarily) see
> events for uncommitted transactions.

Yes, but then we will hit a timeout if the transaction is not actually 
committed.

>> If the transaction is not committed successfully, we will get a timeout
>> from the devstate event and exit.
>
> I think that the only way all this could work is if you firstly, in
> one transaction, create enough of the backend for the hotplug scripts
> to run, and then in a second transaction create the rest of the
> backend plus the frontend.

The hotplug scripts require the backend to be in state 2 (it requires 
that the kernel has initialized the device) so it needs to have a full 
backend set up.

>>> I think this code is a symptom of a problem elsewhere.  When adding a
>>> disk to a domain, it should not be necessary to explicitly ask to add
>>> it to the stubdom too.  But this is not your fault, or your problem
>>> right now.
>> So I assume we can leave this for later.
>
> Yes.
>
> Thanks,
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjwI1-0007Hg-Ua; Wed, 27 Jun 2012 17:44:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SjwI0-0007Ha-8z
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 17:44:28 +0000
Received: from [85.158.139.83:35400] by server-4.bemta-5.messagelabs.com id
	A8/19-27831-B764BEF4; Wed, 27 Jun 2012 17:44:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340819066!28548284!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDI1OTAy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14508 invoked from network); 27 Jun 2012 17:44:26 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 17:44:26 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id DEE9338007F;
	Wed, 27 Jun 2012 10:44:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=W3B9do+mLQ0MeHrj5DxB/hmJjTQoD2k42gQTsFRkY1Am
	R2P8zimMlWip6DKX/MLKs7+g4kuoJIqZ9hZ+8R2eNWCdevQWa9mwRsrQLkZz5wqk
	jhCbWhhaeGdwHmz3ugWQj5Uae7mCSzGFCyWi89yHxjTydsm+Nkcrgbk36I1qBEw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=u6+0BpbWj5HPg2CDk6ATMdnN72E=; b=i2evozq9
	M228WQqasppcUTJbPm14Sg7OGO6q7VT8Lzq0tNOqJcbXA3k7tGLHM3KuVPN2KeK4
	O81GHbZm7aJZKRAWgS2ao3QqbdLgFYkTBnm1V9hyVwLI89jCvL+3rwDLkKnwQbl5
	T3tTTIIsew9lgeAwdUqWRvgfvu+SDp9N84E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 903C6380077; 
	Wed, 27 Jun 2012 10:44:11 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 27 Jun 2012 10:44:11 -0700
Message-ID: <f6eefcfd5e7ff3a848cfd09f8b5bb8e6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.8077.1340818561.1399.xen-devel@lists.xen.org>
References: <mailman.8077.1340818561.1399.xen-devel@lists.xen.org>
Date: Wed, 27 Jun 2012 10:44:11 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1340815812 -3600
> # Node ID ea827c449088a1017b6e5a9564eb33df70f8a9c6
> # Parent  b4e1fec1c98f6cbad666a972f473854518c25500
> xen,pod: Zero-check recently populated pages (checklast)
>
> When demand-populating pages due to guest accesses, check recently
> populated
> pages to see if we can reclaim them for the cache.  This should keep the
> PoD
> cache filled when the start-of-day scrubber is going through.
>
> The number 128 was chosen by experiment.  Windows does its page
> scrubbing in parallel; while a small nubmer like 4 works well for
> single VMs, it breaks down as multiple vcpus are scrubbing different
> pages in parallel.  Increasing to 128 works well for higher numbers of
> vcpus.
>
> v2:
>  - Wrapped some long lines
>  - unsigned int for index, unsigned long for array
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -909,6 +909,27 @@ p2m_pod_emergency_sweep_super(struct p2m
>      p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
>  }
>
> +/* When populating a new superpage, look at recently populated superpages
> + * hoping that they've been zeroed.  This will snap up zeroed pages as
> soon as
> + * the guest OS is done with them. */
> +static void
> +p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long
> gfn_aligned)
> +{
> +    unsigned long check_gfn;
> +
> +    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
> +
> +    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
> +
> +    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
> +
> +    p2m->pod.last_populated_index =
> +        ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
> +
> +    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m,
> check_gfn);
> +}
> +
> +
>  #define POD_SWEEP_STRIDE  16
>  static void
>  p2m_pod_emergency_sweep(struct p2m_domain *p2m)
> @@ -1066,6 +1087,12 @@ p2m_pod_demand_populate(struct p2m_domai
>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>      }
>
> +    /* Check the last guest demand-populate */
> +    if ( p2m->pod.entry_count > p2m->pod.count
> +         && order == 9
s/9/PAGE_ORDER_2M/

Otherwise the series looks good to me.
Andres
> +         && q & P2M_ALLOC )
> +        p2m_pod_check_last_super(p2m, gfn_aligned);
> +
>      pod_unlock(p2m);
>      return 0;
>  out_of_memory:
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -287,6 +287,10 @@ struct p2m_domain {
>          unsigned         reclaim_super; /* Last gpfn of a scan */
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest
> demand-populate */
> +#define POD_HISTORY_MAX 128
> +        /* gpfn of last guest superpage demand-populated */
> +        unsigned long    last_populated[POD_HISTORY_MAX];
> +        unsigned int     last_populated_index;
>          mm_lock_t        lock;         /* Locking of private pod structs,
>   *
>                                          * not relying on the p2m lock.
>   */
>      } pod;
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 17:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 17: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 1SjwI1-0007Hg-Ua; Wed, 27 Jun 2012 17:44:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1SjwI0-0007Ha-8z
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 17:44:28 +0000
Received: from [85.158.139.83:35400] by server-4.bemta-5.messagelabs.com id
	A8/19-27831-B764BEF4; Wed, 27 Jun 2012 17:44:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340819066!28548284!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDI1OTAy\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14508 invoked from network); 27 Jun 2012 17:44:26 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-182.messagelabs.com with SMTP;
	27 Jun 2012 17:44:26 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id DEE9338007F;
	Wed, 27 Jun 2012 10:44:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=W3B9do+mLQ0MeHrj5DxB/hmJjTQoD2k42gQTsFRkY1Am
	R2P8zimMlWip6DKX/MLKs7+g4kuoJIqZ9hZ+8R2eNWCdevQWa9mwRsrQLkZz5wqk
	jhCbWhhaeGdwHmz3ugWQj5Uae7mCSzGFCyWi89yHxjTydsm+Nkcrgbk36I1qBEw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=u6+0BpbWj5HPg2CDk6ATMdnN72E=; b=i2evozq9
	M228WQqasppcUTJbPm14Sg7OGO6q7VT8Lzq0tNOqJcbXA3k7tGLHM3KuVPN2KeK4
	O81GHbZm7aJZKRAWgS2ao3QqbdLgFYkTBnm1V9hyVwLI89jCvL+3rwDLkKnwQbl5
	T3tTTIIsew9lgeAwdUqWRvgfvu+SDp9N84E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 903C6380077; 
	Wed, 27 Jun 2012 10:44:11 -0700 (PDT)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 27 Jun 2012 10:44:11 -0700
Message-ID: <f6eefcfd5e7ff3a848cfd09f8b5bb8e6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.8077.1340818561.1399.xen-devel@lists.xen.org>
References: <mailman.8077.1340818561.1399.xen-devel@lists.xen.org>
Date: Wed, 27 Jun 2012 10:44:11 -0700
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1340815812 -3600
> # Node ID ea827c449088a1017b6e5a9564eb33df70f8a9c6
> # Parent  b4e1fec1c98f6cbad666a972f473854518c25500
> xen,pod: Zero-check recently populated pages (checklast)
>
> When demand-populating pages due to guest accesses, check recently
> populated
> pages to see if we can reclaim them for the cache.  This should keep the
> PoD
> cache filled when the start-of-day scrubber is going through.
>
> The number 128 was chosen by experiment.  Windows does its page
> scrubbing in parallel; while a small nubmer like 4 works well for
> single VMs, it breaks down as multiple vcpus are scrubbing different
> pages in parallel.  Increasing to 128 works well for higher numbers of
> vcpus.
>
> v2:
>  - Wrapped some long lines
>  - unsigned int for index, unsigned long for array
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -909,6 +909,27 @@ p2m_pod_emergency_sweep_super(struct p2m
>      p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
>  }
>
> +/* When populating a new superpage, look at recently populated superpages
> + * hoping that they've been zeroed.  This will snap up zeroed pages as
> soon as
> + * the guest OS is done with them. */
> +static void
> +p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long
> gfn_aligned)
> +{
> +    unsigned long check_gfn;
> +
> +    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
> +
> +    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
> +
> +    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
> +
> +    p2m->pod.last_populated_index =
> +        ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
> +
> +    p2m->pod.reclaim_super += p2m_pod_zero_check_superpage(p2m,
> check_gfn);
> +}
> +
> +
>  #define POD_SWEEP_STRIDE  16
>  static void
>  p2m_pod_emergency_sweep(struct p2m_domain *p2m)
> @@ -1066,6 +1087,12 @@ p2m_pod_demand_populate(struct p2m_domai
>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>      }
>
> +    /* Check the last guest demand-populate */
> +    if ( p2m->pod.entry_count > p2m->pod.count
> +         && order == 9
s/9/PAGE_ORDER_2M/

Otherwise the series looks good to me.
Andres
> +         && q & P2M_ALLOC )
> +        p2m_pod_check_last_super(p2m, gfn_aligned);
> +
>      pod_unlock(p2m);
>      return 0;
>  out_of_memory:
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -287,6 +287,10 @@ struct p2m_domain {
>          unsigned         reclaim_super; /* Last gpfn of a scan */
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest
> demand-populate */
> +#define POD_HISTORY_MAX 128
> +        /* gpfn of last guest superpage demand-populated */
> +        unsigned long    last_populated[POD_HISTORY_MAX];
> +        unsigned int     last_populated_index;
>          mm_lock_t        lock;         /* Locking of private pod structs,
>   *
>                                          * not relying on the p2m lock.
>   */
>      } pod;
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 18:07:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 18:07:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjweL-0007aS-24; Wed, 27 Jun 2012 18:07:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1SjweI-0007aN-Nz
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 18:07:31 +0000
Received: from [85.158.143.99:63514] by server-3.bemta-4.messagelabs.com id
	21/4F-05808-1EB4BEF4; Wed, 27 Jun 2012 18:07:29 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340820448!19808983!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27882 invoked from network); 27 Jun 2012 18:07:29 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 18:07:29 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 4BD0C468008
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 18:07:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=postfix; bh=+rpzxbDz0
	R9ewLWLkdSmBBkzuE0=; b=TsgZgu+JC+BQ9jHlTMYT8NkE3zRmMePMkMx22bPAs
	v/YhOxImlOQqS6Og+vmYYhhmNp/55f9EAzn2AJd7a3qTogPOkbmwkhRHoRgSAF8M
	DwxwwKNtPUG5+eEjG5PRF6tS9H+gKEcpfDPkg5IA7uturkTLOSieqbhQdW4mRx1g
	Ek=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=postfix; b=mQy
	p4ca+dQf+PBJ9/nR9YmpMq61qxR8a576jrPK8IjwgzHpfYGKrCyqLWPLFHbX/bGB
	u+aGxF2eLQf8PlmJJDg4R3B7pDqpEXlAapz7x32wjHlbverkZv01N+Rbmc1wh+Yj
	OGmvjb0w3LCvuJBPB2tOkBcXLd+wvcydoRkFu+G0=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id BCA0F468005
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 18:07:30 +0000 (UTC)
Message-ID: <4FEB4BDD.5040205@goirand.fr>
Date: Thu, 28 Jun 2012 02:07:25 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120506 Icedove/3.0.11
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
In-Reply-To: <20448.49637.38489.246434@mariner.uk.xensource.com>
X-Enigmail-Version: 1.0.1
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Thanks for discussing this in a public way!

On 06/20/2012 02:16 AM, Ian Jackson wrote:
> We had one request from a public Xen cloud provider to be provided
> with predisclosure information.  However it appeared to us that they
> didn't meet the size threshold in the process document.
>
> The size threshold is of course open to discussion.
>   
I find the concept of "Xen Cloud provider size threshold"
quite anti competitive. Why would a bigger provider, would
be offered a substantial advantage over the smaller one?

On 06/20/2012 02:16 AM, Ian Jackson wrote:
> One particular issue here which also relates to the predisclosure
> membership criteria, is whether large indirect consumers of Xen should
> be on the predisclosure list in their own right.  That would allow
> them to deploy the fix before the embargo date.  It would also allow
> them to prepare for testing and deployment, before the fix is
> available from their vendor (who would in this scenario also be
> entitled to be a predisclosure list member).
>   

And other hosting providers not in the list? They can be hacked and die,
while the big ones are safe?

Why wouldn't a smaller company know? Can *I* be in the predisclosure list?
If you reject me from such list, why? What's the procedure to be on such
list?

On 06/20/2012 05:45 PM, George Dunlap wrote:
> The only way this would work is if the predisclosure list consisted
> exclusively of software providers, and specifically excluded service
> providers.
I agree, though you might have corner cases.

What if you are *both* software and service provider (eg: I'm working on
Debian and XCP, and my small company provides a hosted Xen service)?

Cheers,

Thomas


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 18:07:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 18:07:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SjweL-0007aS-24; Wed, 27 Jun 2012 18:07:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1SjweI-0007aN-Nz
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 18:07:31 +0000
Received: from [85.158.143.99:63514] by server-3.bemta-4.messagelabs.com id
	21/4F-05808-1EB4BEF4; Wed, 27 Jun 2012 18:07:29 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340820448!19808983!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27882 invoked from network); 27 Jun 2012 18:07:29 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 18:07:29 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 4BD0C468008
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 18:07:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=postfix; bh=+rpzxbDz0
	R9ewLWLkdSmBBkzuE0=; b=TsgZgu+JC+BQ9jHlTMYT8NkE3zRmMePMkMx22bPAs
	v/YhOxImlOQqS6Og+vmYYhhmNp/55f9EAzn2AJd7a3qTogPOkbmwkhRHoRgSAF8M
	DwxwwKNtPUG5+eEjG5PRF6tS9H+gKEcpfDPkg5IA7uturkTLOSieqbhQdW4mRx1g
	Ek=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=postfix; b=mQy
	p4ca+dQf+PBJ9/nR9YmpMq61qxR8a576jrPK8IjwgzHpfYGKrCyqLWPLFHbX/bGB
	u+aGxF2eLQf8PlmJJDg4R3B7pDqpEXlAapz7x32wjHlbverkZv01N+Rbmc1wh+Yj
	OGmvjb0w3LCvuJBPB2tOkBcXLd+wvcydoRkFu+G0=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id BCA0F468005
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 18:07:30 +0000 (UTC)
Message-ID: <4FEB4BDD.5040205@goirand.fr>
Date: Thu, 28 Jun 2012 02:07:25 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120506 Icedove/3.0.11
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
In-Reply-To: <20448.49637.38489.246434@mariner.uk.xensource.com>
X-Enigmail-Version: 1.0.1
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Thanks for discussing this in a public way!

On 06/20/2012 02:16 AM, Ian Jackson wrote:
> We had one request from a public Xen cloud provider to be provided
> with predisclosure information.  However it appeared to us that they
> didn't meet the size threshold in the process document.
>
> The size threshold is of course open to discussion.
>   
I find the concept of "Xen Cloud provider size threshold"
quite anti competitive. Why would a bigger provider, would
be offered a substantial advantage over the smaller one?

On 06/20/2012 02:16 AM, Ian Jackson wrote:
> One particular issue here which also relates to the predisclosure
> membership criteria, is whether large indirect consumers of Xen should
> be on the predisclosure list in their own right.  That would allow
> them to deploy the fix before the embargo date.  It would also allow
> them to prepare for testing and deployment, before the fix is
> available from their vendor (who would in this scenario also be
> entitled to be a predisclosure list member).
>   

And other hosting providers not in the list? They can be hacked and die,
while the big ones are safe?

Why wouldn't a smaller company know? Can *I* be in the predisclosure list?
If you reject me from such list, why? What's the procedure to be on such
list?

On 06/20/2012 05:45 PM, George Dunlap wrote:
> The only way this would work is if the predisclosure list consisted
> exclusively of software providers, and specifically excluded service
> providers.
I agree, though you might have corner cases.

What if you are *both* software and service provider (eg: I'm working on
Debian and XCP, and my small company provides a hosted Xen service)?

Cheers,

Thomas


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 18:27:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 18: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 1SjwxA-0007nP-T8; Wed, 27 Jun 2012 18:27:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ray.danks@se-eng.com>) id 1Sjwx9-0007nK-QN
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 18:27:00 +0000
Received: from [85.158.143.99:53357] by server-2.bemta-4.messagelabs.com id
	7E/5E-17938-3705BEF4; Wed, 27 Jun 2012 18:26:59 +0000
X-Env-Sender: ray.danks@se-eng.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340821617!19663482!1
X-Originating-IP: [75.148.42.21]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21202 invoked from network); 27 Jun 2012 18:26:58 -0000
Received: from 75-148-42-21-colorado.hfc.comcastbusiness.net (HELO
	judge.camp.se-eng.com) (75.148.42.21)
	by server-8.tower-216.messagelabs.com with SMTP;
	27 Jun 2012 18:26:58 -0000
Received: from localhost (localhost [127.0.0.1])
	by judge.camp.se-eng.com (Postfix) with ESMTP id 7C468138F43;
	Wed, 27 Jun 2012 12:26:56 -0600 (MDT)
X-Virus-Scanned: amavisd-new at camp.se-eng.com
Received: from judge.camp.se-eng.com ([127.0.0.1])
	by localhost (judge.camp.se-eng.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id RGuXqs-6Mx1m; Wed, 27 Jun 2012 12:26:52 -0600 (MDT)
Received: from [172.20.202.96] (beast.camp.se-eng.com [172.20.202.96])
	by judge.camp.se-eng.com (Postfix) with ESMTPSA id 93AC9138F41;
	Wed, 27 Jun 2012 12:26:52 -0600 (MDT)
Message-ID: <4FEB50BF.5080606@se-eng.com>
Date: Wed, 27 Jun 2012 12:28:15 -0600
From: Raymond Danks <ray.danks@se-eng.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] OpenEmbedded layer for building Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: ray.danks@se-eng.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1607390191749074503=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1607390191749074503==
Content-Type: multipart/alternative;
 boundary="------------040104090201030209010306"

This is a multi-part message in MIME format.
--------------040104090201030209010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

In reference to cross-compiling and OpenEmbedded on the Xen 4.0 Feature 
Request list on the XenRoadMap, I have constructed and posted a layer, 
meta-xen, that may be used with OpenEmbedded and Yocto distributions for 
including the Xen hypervisor and tools.  The work currently targets the 
Xen 4.1.2 release and the x86_64 target architecture.

http://git.se-eng.com/gitweb/?p=meta-xen.git;a=summary

My focus will continue to be the x86_64 OE target (Xen Dom0), but I am 
open to feedback and contribution for building other target 
architectures as well.  Please let me know if you find this useful or if 
there are any changes/additions you would like to see made.

Thanks,
Ray

Raymond Danks
Sage Electronic Engineering, LLC
http://www.se-eng.com

--------------040104090201030209010306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    In reference to cross-compiling and OpenEmbedded on the Xen 4.0
    Feature Request list on the XenRoadMap, I have constructed and
    posted a layer, meta-xen, that may be used with OpenEmbedded and
    Yocto distributions for including the Xen hypervisor and tools.&nbsp; The
    work currently targets the Xen 4.1.2 release and the x86_64 target
    architecture.<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="http://git.se-eng.com/gitweb/?p=meta-xen.git;a=summary">http://git.se-eng.com/gitweb/?p=meta-xen.git;a=summary</a><br>
    <br>
    My focus will continue to be the x86_64 OE target (Xen Dom0), but I
    am open to feedback and contribution for building other target
    architectures as well.&nbsp; Please let me know if you find this useful
    or if there are any changes/additions you would like to see made.<br>
    <br>
    Thanks,<br>
    Ray<br>
    <br>
    Raymond Danks<br>
    Sage Electronic Engineering, LLC<br>
    <a class="moz-txt-link-freetext" href="http://www.se-eng.com">http://www.se-eng.com</a><br>
  </body>
</html>

--------------040104090201030209010306--


--===============1607390191749074503==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1607390191749074503==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 18:27:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 18: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 1SjwxA-0007nP-T8; Wed, 27 Jun 2012 18:27:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ray.danks@se-eng.com>) id 1Sjwx9-0007nK-QN
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 18:27:00 +0000
Received: from [85.158.143.99:53357] by server-2.bemta-4.messagelabs.com id
	7E/5E-17938-3705BEF4; Wed, 27 Jun 2012 18:26:59 +0000
X-Env-Sender: ray.danks@se-eng.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340821617!19663482!1
X-Originating-IP: [75.148.42.21]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21202 invoked from network); 27 Jun 2012 18:26:58 -0000
Received: from 75-148-42-21-colorado.hfc.comcastbusiness.net (HELO
	judge.camp.se-eng.com) (75.148.42.21)
	by server-8.tower-216.messagelabs.com with SMTP;
	27 Jun 2012 18:26:58 -0000
Received: from localhost (localhost [127.0.0.1])
	by judge.camp.se-eng.com (Postfix) with ESMTP id 7C468138F43;
	Wed, 27 Jun 2012 12:26:56 -0600 (MDT)
X-Virus-Scanned: amavisd-new at camp.se-eng.com
Received: from judge.camp.se-eng.com ([127.0.0.1])
	by localhost (judge.camp.se-eng.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id RGuXqs-6Mx1m; Wed, 27 Jun 2012 12:26:52 -0600 (MDT)
Received: from [172.20.202.96] (beast.camp.se-eng.com [172.20.202.96])
	by judge.camp.se-eng.com (Postfix) with ESMTPSA id 93AC9138F41;
	Wed, 27 Jun 2012 12:26:52 -0600 (MDT)
Message-ID: <4FEB50BF.5080606@se-eng.com>
Date: Wed, 27 Jun 2012 12:28:15 -0600
From: Raymond Danks <ray.danks@se-eng.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] OpenEmbedded layer for building Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: ray.danks@se-eng.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1607390191749074503=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1607390191749074503==
Content-Type: multipart/alternative;
 boundary="------------040104090201030209010306"

This is a multi-part message in MIME format.
--------------040104090201030209010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

In reference to cross-compiling and OpenEmbedded on the Xen 4.0 Feature 
Request list on the XenRoadMap, I have constructed and posted a layer, 
meta-xen, that may be used with OpenEmbedded and Yocto distributions for 
including the Xen hypervisor and tools.  The work currently targets the 
Xen 4.1.2 release and the x86_64 target architecture.

http://git.se-eng.com/gitweb/?p=meta-xen.git;a=summary

My focus will continue to be the x86_64 OE target (Xen Dom0), but I am 
open to feedback and contribution for building other target 
architectures as well.  Please let me know if you find this useful or if 
there are any changes/additions you would like to see made.

Thanks,
Ray

Raymond Danks
Sage Electronic Engineering, LLC
http://www.se-eng.com

--------------040104090201030209010306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    In reference to cross-compiling and OpenEmbedded on the Xen 4.0
    Feature Request list on the XenRoadMap, I have constructed and
    posted a layer, meta-xen, that may be used with OpenEmbedded and
    Yocto distributions for including the Xen hypervisor and tools.&nbsp; The
    work currently targets the Xen 4.1.2 release and the x86_64 target
    architecture.<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="http://git.se-eng.com/gitweb/?p=meta-xen.git;a=summary">http://git.se-eng.com/gitweb/?p=meta-xen.git;a=summary</a><br>
    <br>
    My focus will continue to be the x86_64 OE target (Xen Dom0), but I
    am open to feedback and contribution for building other target
    architectures as well.&nbsp; Please let me know if you find this useful
    or if there are any changes/additions you would like to see made.<br>
    <br>
    Thanks,<br>
    Ray<br>
    <br>
    Raymond Danks<br>
    Sage Electronic Engineering, LLC<br>
    <a class="moz-txt-link-freetext" href="http://www.se-eng.com">http://www.se-eng.com</a><br>
  </body>
</html>

--------------040104090201030209010306--


--===============1607390191749074503==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1607390191749074503==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 18:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 18:43: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 1SjxCp-00082s-Fl; Wed, 27 Jun 2012 18:43:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjxCn-00082k-HY
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 18:43:09 +0000
Received: from [85.158.143.35:35764] by server-3.bemta-4.messagelabs.com id
	4E/75-05808-C345BEF4; Wed, 27 Jun 2012 18:43:08 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340822586!6992198!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21412 invoked from network); 27 Jun 2012 18:43:07 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 18:43:07 -0000
Received: by obbta14 with SMTP id ta14so2393713obb.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 11:43:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=EZlX3qJAQv+YFdDit440kWIA4xDVFgs/1IV2d53Y5kY=;
	b=YqJ8dB9vvXh2FhJdgOvIIgQe0xdf7472SWp+9iIrtzdBrjidPriYkKHn8rdodNJl61
	G5UyUqCXmX8kfZR4FdsxYos/XGffttYHyzp/XHhXOF1hrt7vTvepdPMJmDA9fl5gzglB
	I7X058P0Gyxs0+XPDbOybKS595rCMsnbsZoeABr0jHrxzBMQDPh1O1Vo+j0DzEbGz59r
	j0T6dzo3IS7FLjNXsfqhd3NF7Hgm2MMldJr+7JOL8l8r+uVXWyRogBMgoqZAX0A6g1iC
	JTrDPdoTkoEfCxOZ0ZGzUANpdEyJeJIyZmYXDJ3JYG5IcahQdll/gbSevBvYyJ2J72Iu
	dC8A==
Received: by 10.182.77.167 with SMTP id t7mr11594969obw.79.1340822585913; Wed,
	27 Jun 2012 11:43:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 27 Jun 2012 11:42:45 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Wed, 27 Jun 2012 20:42:45 +0200
Message-ID: <CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQkXr1QaTxconESz4wn3USovYBwVo6cyshc8B8iGao3xMpfUd6F9IDUPOSUN+Op+AiYNh0jC
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 27, 2012 at 3:36 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 26 Jun 2012, Rolu wrote:
>> On Tue, Jun 26, 2012 at 2:59 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 26 Jun 2012, Rolu wrote:
>> >> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Mon, 25 Jun 2012, Jan Beulich wrote:
>> >> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
>> >> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com>=
 wrote:
>> >> >> >> At the same time, adding logging to the guest kernel would
>> >> >> >> be nice, to see what value it actually writes (in a current
>> >> >> >> kernel this would be in __write_msi_msg()).
>> >> >> >>
>> >> >> >
>> >> >> > Turns out that msg->data here is also 0x4300, so it seems the gu=
est
>> >> >> > kernel is producing these values. I caused it to make a stack tr=
ace
>> >> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function u=
ses
>> >> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It check=
s the
>> >> >> > current data field and if it isn't equal to the macro it uses
>> >> >> > xen_msi_compose_msg to make a new message, but that function jus=
t sets
>> >> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300.=
 This
>> >> >> > then gets passed to __write_msi_msg and that's that. There are no
>> >> >> > other writes through __write_msi_msg (except for the same thing =
for
>> >> >> > other devices).
>> >> >> >
>> >> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends =
up
>> >> >> > decoded as the delivery mode, so it seems the kernel is intentio=
nally
>> >> >> > setting it to 3.
>> >> >>
>> >> >> So that can never have worked properly afaict. Stefano, the
>> >> >> code as it is currently - using literal (3 << 8) - is clearly bogu=
s.
>> >> >> Your original commit at least had a comment saying that the
>> >> >> reserved delivery mode encoding is intentional here, but that
>> >> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
>> >> >> In any case - the cooperation with qemu apparently doesn't
>> >> >> work, as the reserved encoding should never make it through
>> >> >> to the hypervisor. Could you explain what the intention here
>> >> >> was?
>> >> >>
>> >> >> And regardless of anything, can the literal numbers please be
>> >> >> replaced by proper manifest constants - the "8" here already
>> >> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
>> >> >> proper symbolic would permit locating where this is being (or
>> >> >> really, as it doesn't appear to work supposed to be) consumed
>> >> >> in qemu, provided it uses the same definition (i.e. that one
>> >> >> should go into one of the public headers).
>> >> >
>> >> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
>> >> > because notifications are not supposed to be delivered as MSI anymo=
re.
>> >> >
>> >> > This is what should happen:
>> >> >
>> >> > 1) Linux configures the device with a 0 vector number and the pirq =
number
>> >> > in the address field;
>> >> >
>> >> > 2) QEMU notices a vector number of 0 and reads the pirq number from=
 the
>> >> > address field, passing it to xc_domain_update_msi_irq;
>> >> >
>> >> > 3) Xen assignes the given pirq to the physical MSI;
>> >> >
>> >> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>> >> >
>> >> > 5) Xen sets the pirq as "IRQ_PT";
>> >> >
>> >> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_=
pirq
>> >> > returns true so Xen calls send_guest_pirq instead.
>> >> >
>> >> >
>> >> > Obviously 6) is not happening. hvm_domain_use_pirq is:
>> >> >
>> >> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq !=3D IRQ_UNBOUND
>> >> >
>> >> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
>> >> > above).
>> >>
>> >> This appears to be true. I added logging to hvm_pci_msi_assert in
>> >> xen/drivers/passthrough/io.c and it indicates that
>> >> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
>> >> before an unsupported delivery mode message.
>> >>
>> >> I also log pirq->pirq but I found that most of the time I can't find
>> >> this value anywhere else (I'm not sure how to interpret the value,
>> >> though). For example, in my last try:
>> >>
>> >> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
>> >> 53. The vast majority are for 54.
>> >> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
>> >> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
>> >> Never for 54 or 53. It also gets called with pirq=3D49,emuirq=3D23 on=
ce
>> >> but complains it's already mapped.
>> >> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
>> >> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
>> >> 22, 52, 48, 47. Also never 54 or 53.
>> >> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16,=
 17, 55.
>> >> * The qemu log mentions pirq 35, 36 and 37
>> >>
>> >> It seems pirq values don't always mean the same? Is it a coincidence
>> >> that 55 occurs almost everywhere, or is something going wrong with the
>> >> other two values (53 and 54 versus 16 and 17)?
>> >>
>> >> I have three MSI capable devices passed through to the domU, and I do
>> >> see groups of three distinct pirqs in the data above - just not the
>> >> same ones in every place I look.
>> >>
>> >> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
>> >> > (__startup_pirq doesn't get called), or Xen is erroring out in
>> >> > map_domain_emuirq_pirq.
>> >>
>> >> evtchn_bind_pirq gets called, though I'm not sure if it is with the r=
ight data.
>> >>
>> >> map_domain_emuirq_pirq always gets past the checks in the top half
>> >> (i.e. up to the line /* do not store emuirq mappings for pt devices
>> >> */), except for one time with pirq=3D49,emuirq=3D23 where it finds th=
ey
>> >> are already mapped.
>> >> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
>> >> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
>> >> directly logged that but it's the only assignment there).
>> >>
>> >> Interestingly, I get an unsupported delivery mode error for pirq 55
>> >> where my logging says pirq->arch.hvm.emuirq is -1, *after*
>> >> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.
>> >
>> > Looking back at your QEMU logs, it seems that pt_msi_setup is not
>> > called (or it is not called at the right time), otherwise you should
>> > get:
>> >
>> > pt_msi_setup requested pirq =3D %d
>> >
>> > in your logs.
>> > Could you try disabling msitranslate? You can do that adding
>> >
>> > pci_msitranslate=3D0
>> >
>> > to your VM config file.
>>
>> I tried that, but it didn't work.
>>
>> > If that works, probably this (untested) QEMU patch could fix your prob=
lem:
>> >
>>
>> I appreciate the help.
>>
>> I applied the patch anyway just to see what would happen (had to edit
>> a few dev versus d variable names) but it didn't help. It also breaks
>> pt_msi_update, as I get in the qemu log:
>>
>> pt_msi_update: Update msi with pirq 2f gvec 0 gflags 302f
>> pt_msi_update: Error: Binding of MSI failed.
>> pt_msi_update: Error: Unmapping of MSI failed.
>> pt_msgctrl_reg_write: Warning: Can not bind MSI for dev 80
>>
>> I added some logging to pt_msi_setup (without the patch). It does get
>> called, and it does so rather early in the boot process, each time
>> right before lines as these:
>>
>> pci_intx: intx=3D1
>> register_real_device: Real physical device 00:1b.0 registered successful=
y!
>> IRQ type =3D MSI-INTx
>>
>> At this point dev->msi->data, addr_hi and addr_lo are all 0, which
>> doesn't seem right. Is it being called prematurely?
>
> That's because msitranslate is still enabled somehow, that is a
> toolstack bug.
> While we fix that bug, could you try this QEMU patch to forcefully disable
> msitranslate?
>

This worked!

The "unsupported delivery mode" message is gone. Sound works, although
there is still occasionally a very short stutter, but I expect that's
a different issue. I've been testing with a KDE desktop with 3D
effects (cube, expo, that sort of stuff) and performance there has
gone up noticeably, from around 30-40 fps in most cases to near 60.

> diff --git a/xenstore.c b/xenstore.c
> index ac90366..8af280e 100644
> --- a/xenstore.c
> +++ b/xenstore.c
> @@ -427,7 +427,7 @@ uint32_t xenstore_read_target(void)
> =A0 =A0 return target_domid;
> =A0}
>
> -#define PT_PCI_MSITRANSLATE_DEFAULT 1
> +#define PT_PCI_MSITRANSLATE_DEFAULT 0
> =A0#define PT_PCI_POWER_MANAGEMENT_DEFAULT 0
> =A0int direct_pci_msitranslate;
> =A0int direct_pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 18:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 18:43: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 1SjxCp-00082s-Fl; Wed, 27 Jun 2012 18:43:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SjxCn-00082k-HY
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 18:43:09 +0000
Received: from [85.158.143.35:35764] by server-3.bemta-4.messagelabs.com id
	4E/75-05808-C345BEF4; Wed, 27 Jun 2012 18:43:08 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340822586!6992198!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21412 invoked from network); 27 Jun 2012 18:43:07 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 18:43:07 -0000
Received: by obbta14 with SMTP id ta14so2393713obb.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 11:43:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=EZlX3qJAQv+YFdDit440kWIA4xDVFgs/1IV2d53Y5kY=;
	b=YqJ8dB9vvXh2FhJdgOvIIgQe0xdf7472SWp+9iIrtzdBrjidPriYkKHn8rdodNJl61
	G5UyUqCXmX8kfZR4FdsxYos/XGffttYHyzp/XHhXOF1hrt7vTvepdPMJmDA9fl5gzglB
	I7X058P0Gyxs0+XPDbOybKS595rCMsnbsZoeABr0jHrxzBMQDPh1O1Vo+j0DzEbGz59r
	j0T6dzo3IS7FLjNXsfqhd3NF7Hgm2MMldJr+7JOL8l8r+uVXWyRogBMgoqZAX0A6g1iC
	JTrDPdoTkoEfCxOZ0ZGzUANpdEyJeJIyZmYXDJ3JYG5IcahQdll/gbSevBvYyJ2J72Iu
	dC8A==
Received: by 10.182.77.167 with SMTP id t7mr11594969obw.79.1340822585913; Wed,
	27 Jun 2012 11:43:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 27 Jun 2012 11:42:45 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Wed, 27 Jun 2012 20:42:45 +0200
Message-ID: <CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQkXr1QaTxconESz4wn3USovYBwVo6cyshc8B8iGao3xMpfUd6F9IDUPOSUN+Op+AiYNh0jC
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 27, 2012 at 3:36 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 26 Jun 2012, Rolu wrote:
>> On Tue, Jun 26, 2012 at 2:59 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Tue, 26 Jun 2012, Rolu wrote:
>> >> On Mon, Jun 25, 2012 at 1:38 PM, Stefano Stabellini
>> >> <stefano.stabellini@eu.citrix.com> wrote:
>> >> > On Mon, 25 Jun 2012, Jan Beulich wrote:
>> >> >> >>> On 24.06.12 at 04:21, Rolu <rolu@roce.org> wrote:
>> >> >> > On Wed, Jun 20, 2012 at 6:03 PM, Jan Beulich <JBeulich@suse.com>=
 wrote:
>> >> >> >> At the same time, adding logging to the guest kernel would
>> >> >> >> be nice, to see what value it actually writes (in a current
>> >> >> >> kernel this would be in __write_msi_msg()).
>> >> >> >>
>> >> >> >
>> >> >> > Turns out that msg->data here is also 0x4300, so it seems the gu=
est
>> >> >> > kernel is producing these values. I caused it to make a stack tr=
ace
>> >> >> > and this pointed back to xen_hvm_setup_msi_irqs. This function u=
ses
>> >> >> > the macro XEN_PIRQ_MSI_DATA, which evaluates to 0x4300. It check=
s the
>> >> >> > current data field and if it isn't equal to the macro it uses
>> >> >> > xen_msi_compose_msg to make a new message, but that function jus=
t sets
>> >> >> > the data field of the message to XEN_PIRQ_MSI_DATA - so, 0x4300.=
 This
>> >> >> > then gets passed to __write_msi_msg and that's that. There are no
>> >> >> > other writes through __write_msi_msg (except for the same thing =
for
>> >> >> > other devices).
>> >> >> >
>> >> >> > The macro XEN_PIRQ_MSI_DATA contains a part (3 << 8) which ends =
up
>> >> >> > decoded as the delivery mode, so it seems the kernel is intentio=
nally
>> >> >> > setting it to 3.
>> >> >>
>> >> >> So that can never have worked properly afaict. Stefano, the
>> >> >> code as it is currently - using literal (3 << 8) - is clearly bogu=
s.
>> >> >> Your original commit at least had a comment saying that the
>> >> >> reserved delivery mode encoding is intentional here, but that
>> >> >> comment got lost with the later introduction of XEN_PIRQ_MSI_DATA.
>> >> >> In any case - the cooperation with qemu apparently doesn't
>> >> >> work, as the reserved encoding should never make it through
>> >> >> to the hypervisor. Could you explain what the intention here
>> >> >> was?
>> >> >>
>> >> >> And regardless of anything, can the literal numbers please be
>> >> >> replaced by proper manifest constants - the "8" here already
>> >> >> has MSI_DATA_DELIVERY_MODE_SHIFT, and giving the 3 a
>> >> >> proper symbolic would permit locating where this is being (or
>> >> >> really, as it doesn't appear to work supposed to be) consumed
>> >> >> in qemu, provided it uses the same definition (i.e. that one
>> >> >> should go into one of the public headers).
>> >> >
>> >> > The (3 << 8) is unimportant. The delivery mode chosen is "reserved"
>> >> > because notifications are not supposed to be delivered as MSI anymo=
re.
>> >> >
>> >> > This is what should happen:
>> >> >
>> >> > 1) Linux configures the device with a 0 vector number and the pirq =
number
>> >> > in the address field;
>> >> >
>> >> > 2) QEMU notices a vector number of 0 and reads the pirq number from=
 the
>> >> > address field, passing it to xc_domain_update_msi_irq;
>> >> >
>> >> > 3) Xen assignes the given pirq to the physical MSI;
>> >> >
>> >> > 4) The guest issues a EVTCHNOP_bind_pirq hypercall;
>> >> >
>> >> > 5) Xen sets the pirq as "IRQ_PT";
>> >> >
>> >> > 6) When Xen tries to inject the MSI into the guest, hvm_domain_use_=
pirq
>> >> > returns true so Xen calls send_guest_pirq instead.
>> >> >
>> >> >
>> >> > Obviously 6) is not happening. hvm_domain_use_pirq is:
>> >> >
>> >> > is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq !=3D IRQ_UNBOUND
>> >> >
>> >> > My guess is that emuirq is IRQ_UNBOUND when it should be IRQ_PT (see
>> >> > above).
>> >>
>> >> This appears to be true. I added logging to hvm_pci_msi_assert in
>> >> xen/drivers/passthrough/io.c and it indicates that
>> >> pirq->arch.hvm.emuirq is -1 (while IRQ_PT is -2) every time right
>> >> before an unsupported delivery mode message.
>> >>
>> >> I also log pirq->pirq but I found that most of the time I can't find
>> >> this value anywhere else (I'm not sure how to interpret the value,
>> >> though). For example, in my last try:
>> >>
>> >> * I get an unsupported delivery mode error for pirq->pirq 55, 54 and
>> >> 53. The vast majority are for 54.
>> >> * I have logging in map_domain_emuirq_pirq in xen/arch/x86/irq.c. It
>> >> gets called with pirq 19, 20, 21, 22, 23, 52, 51, 50, 16, 17, 55.
>> >> Never for 54 or 53. It also gets called with pirq=3D49,emuirq=3D23 on=
ce
>> >> but complains it's already mapped.
>> >> * I have logging in evtchn_bind_pirq in xen/common/event_channel.c. It
>> >> gets called with bind->pirq 16, 17, 51, 55, 49, 29 (twice), 21, 19,
>> >> 22, 52, 48, 47. Also never 54 or 53.
>> >> * map_domain_emuirq_pirq is called from evtchn_bind_pirq for pirq 16,=
 17, 55.
>> >> * The qemu log mentions pirq 35, 36 and 37
>> >>
>> >> It seems pirq values don't always mean the same? Is it a coincidence
>> >> that 55 occurs almost everywhere, or is something going wrong with the
>> >> other two values (53 and 54 versus 16 and 17)?
>> >>
>> >> I have three MSI capable devices passed through to the domU, and I do
>> >> see groups of three distinct pirqs in the data above - just not the
>> >> same ones in every place I look.
>> >>
>> >> > So maybe the guest is not issuing a EVTCHNOP_bind_pirq hypercall
>> >> > (__startup_pirq doesn't get called), or Xen is erroring out in
>> >> > map_domain_emuirq_pirq.
>> >>
>> >> evtchn_bind_pirq gets called, though I'm not sure if it is with the r=
ight data.
>> >>
>> >> map_domain_emuirq_pirq always gets past the checks in the top half
>> >> (i.e. up to the line /* do not store emuirq mappings for pt devices
>> >> */), except for one time with pirq=3D49,emuirq=3D23 where it finds th=
ey
>> >> are already mapped.
>> >> It is called three times with an emuirq of -2, for pirq 16, 17 and 55.
>> >> This implies their info->arch.hvm.emuirq is also set to -2 (haven't
>> >> directly logged that but it's the only assignment there).
>> >>
>> >> Interestingly, I get an unsupported delivery mode error for pirq 55
>> >> where my logging says pirq->arch.hvm.emuirq is -1, *after*
>> >> map_domain_emuirq_pirq was called for pirq 55 and emuirq -2.
>> >
>> > Looking back at your QEMU logs, it seems that pt_msi_setup is not
>> > called (or it is not called at the right time), otherwise you should
>> > get:
>> >
>> > pt_msi_setup requested pirq =3D %d
>> >
>> > in your logs.
>> > Could you try disabling msitranslate? You can do that adding
>> >
>> > pci_msitranslate=3D0
>> >
>> > to your VM config file.
>>
>> I tried that, but it didn't work.
>>
>> > If that works, probably this (untested) QEMU patch could fix your prob=
lem:
>> >
>>
>> I appreciate the help.
>>
>> I applied the patch anyway just to see what would happen (had to edit
>> a few dev versus d variable names) but it didn't help. It also breaks
>> pt_msi_update, as I get in the qemu log:
>>
>> pt_msi_update: Update msi with pirq 2f gvec 0 gflags 302f
>> pt_msi_update: Error: Binding of MSI failed.
>> pt_msi_update: Error: Unmapping of MSI failed.
>> pt_msgctrl_reg_write: Warning: Can not bind MSI for dev 80
>>
>> I added some logging to pt_msi_setup (without the patch). It does get
>> called, and it does so rather early in the boot process, each time
>> right before lines as these:
>>
>> pci_intx: intx=3D1
>> register_real_device: Real physical device 00:1b.0 registered successful=
y!
>> IRQ type =3D MSI-INTx
>>
>> At this point dev->msi->data, addr_hi and addr_lo are all 0, which
>> doesn't seem right. Is it being called prematurely?
>
> That's because msitranslate is still enabled somehow, that is a
> toolstack bug.
> While we fix that bug, could you try this QEMU patch to forcefully disable
> msitranslate?
>

This worked!

The "unsupported delivery mode" message is gone. Sound works, although
there is still occasionally a very short stutter, but I expect that's
a different issue. I've been testing with a KDE desktop with 3D
effects (cube, expo, that sort of stuff) and performance there has
gone up noticeably, from around 30-40 fps in most cases to near 60.

> diff --git a/xenstore.c b/xenstore.c
> index ac90366..8af280e 100644
> --- a/xenstore.c
> +++ b/xenstore.c
> @@ -427,7 +427,7 @@ uint32_t xenstore_read_target(void)
> =A0 =A0 return target_domid;
> =A0}
>
> -#define PT_PCI_MSITRANSLATE_DEFAULT 1
> +#define PT_PCI_MSITRANSLATE_DEFAULT 0
> =A0#define PT_PCI_POWER_MANAGEMENT_DEFAULT 0
> =A0int direct_pci_msitranslate;
> =A0int direct_pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 19:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 19:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjxd6-0008Hh-QH; Wed, 27 Jun 2012 19:10:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1Sjxd5-0008Hc-Ey
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 19:10:19 +0000
Received: from [85.158.138.51:24132] by server-1.bemta-3.messagelabs.com id
	1B/72-14648-A9A5BEF4; Wed, 27 Jun 2012 19:10:18 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340824217!28683792!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3273 invoked from network); 27 Jun 2012 19:10:17 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 19:10:17 -0000
Received: from pyramind.ukuu.org.uk (earthlight.etchedpixels.co.uk
	[81.2.110.250])
	by lxorguk.ukuu.org.uk (8.14.5/8.14.1) with ESMTP id q5RJdYld032041;
	Wed, 27 Jun 2012 20:39:39 +0100
Received: from pyramind.ukuu.org.uk (localhost [127.0.0.1])
	by pyramind.ukuu.org.uk (8.14.5/8.14.5) with ESMTP id q5RJE4j1003440;
	Wed, 27 Jun 2012 20:14:04 +0100
Date: Wed, 27 Jun 2012 20:14:03 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Thomas Goirand <thomas@goirand.fr>
Message-ID: <20120627201403.242daae1@pyramind.ukuu.org.uk>
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 find the concept of "Xen Cloud provider size threshold"
> quite anti competitive. Why would a bigger provider, would
> be offered a substantial advantage over the smaller one?

This came up with end providers for Linux disclosure years back and in the
end we said no for all sorts of reasons. The main one being that it is
nigh on impossible to set a "fair" policy. The fact you'd have to keep
adding/removing people as their size changes or importance changes, and
also the fact that the more people you tell the more leaks you get (note
not 'it might leak', that's a given, the question is how much).

It was also readily apparent that you'd have to have a policy that was
written, approved by lawyers and clear and strong enough to stand a
potential judicial review by an aggreived major vendor, or someone wanting
a cheap PR point against their rivals.

It also creates problem incentives. Cloud provider A who is not in the
cartel will not report bugs that only their rivals who are cartel members
get to see first. They'll instead report it to their friends, fix in
private and then go public. So you fracture the reporting environment, and
you get lots of zero day "fixes" from providers that may well be
inadequate or just badly designed.

There are people who get early disclosures on the kernel, but they don't
get them because the community policy covers them but because they have
three letter initials and undoubtedly intercept and monitor the relevant
security lists 8). They wouldn't be doing their job if they didn't.

> On 06/20/2012 02:16 AM, Ian Jackson wrote:
> > One particular issue here which also relates to the predisclosure
> > membership criteria, is whether large indirect consumers of Xen should
> > be on the predisclosure list in their own right.  That would allow
> > them to deploy the fix before the embargo date.  It would also allow
> > them to prepare for testing and deployment, before the fix is
> > available from their vendor (who would in this scenario also be
> > entitled to be a predisclosure list member).
> >   
> 
> And other hosting providers not in the list? They can be hacked and die,
> while the big ones are safe?
> 
> Why wouldn't a smaller company know? Can *I* be in the predisclosure list?
> If you reject me from such list, why? What's the procedure to be on such
> list?

Your lawyers sue them, or you set up a rival "fair reporting" list and
exclude members of the other predisclosure group, do your own private
fixing and then zero day hand them over to Xen.

Providing your group is well publicised most people will tell both
anyway and given the PR battle will probably favour the 'small oppressed'
division you'll probably get more of the "one group only" bugs. Quite
frankly I'd also expect the small guys to find most of the holes.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 19:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 19:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sjxd6-0008Hh-QH; Wed, 27 Jun 2012 19:10:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1Sjxd5-0008Hc-Ey
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 19:10:19 +0000
Received: from [85.158.138.51:24132] by server-1.bemta-3.messagelabs.com id
	1B/72-14648-A9A5BEF4; Wed, 27 Jun 2012 19:10:18 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340824217!28683792!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3273 invoked from network); 27 Jun 2012 19:10:17 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jun 2012 19:10:17 -0000
Received: from pyramind.ukuu.org.uk (earthlight.etchedpixels.co.uk
	[81.2.110.250])
	by lxorguk.ukuu.org.uk (8.14.5/8.14.1) with ESMTP id q5RJdYld032041;
	Wed, 27 Jun 2012 20:39:39 +0100
Received: from pyramind.ukuu.org.uk (localhost [127.0.0.1])
	by pyramind.ukuu.org.uk (8.14.5/8.14.5) with ESMTP id q5RJE4j1003440;
	Wed, 27 Jun 2012 20:14:04 +0100
Date: Wed, 27 Jun 2012 20:14:03 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Thomas Goirand <thomas@goirand.fr>
Message-ID: <20120627201403.242daae1@pyramind.ukuu.org.uk>
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 find the concept of "Xen Cloud provider size threshold"
> quite anti competitive. Why would a bigger provider, would
> be offered a substantial advantage over the smaller one?

This came up with end providers for Linux disclosure years back and in the
end we said no for all sorts of reasons. The main one being that it is
nigh on impossible to set a "fair" policy. The fact you'd have to keep
adding/removing people as their size changes or importance changes, and
also the fact that the more people you tell the more leaks you get (note
not 'it might leak', that's a given, the question is how much).

It was also readily apparent that you'd have to have a policy that was
written, approved by lawyers and clear and strong enough to stand a
potential judicial review by an aggreived major vendor, or someone wanting
a cheap PR point against their rivals.

It also creates problem incentives. Cloud provider A who is not in the
cartel will not report bugs that only their rivals who are cartel members
get to see first. They'll instead report it to their friends, fix in
private and then go public. So you fracture the reporting environment, and
you get lots of zero day "fixes" from providers that may well be
inadequate or just badly designed.

There are people who get early disclosures on the kernel, but they don't
get them because the community policy covers them but because they have
three letter initials and undoubtedly intercept and monitor the relevant
security lists 8). They wouldn't be doing their job if they didn't.

> On 06/20/2012 02:16 AM, Ian Jackson wrote:
> > One particular issue here which also relates to the predisclosure
> > membership criteria, is whether large indirect consumers of Xen should
> > be on the predisclosure list in their own right.  That would allow
> > them to deploy the fix before the embargo date.  It would also allow
> > them to prepare for testing and deployment, before the fix is
> > available from their vendor (who would in this scenario also be
> > entitled to be a predisclosure list member).
> >   
> 
> And other hosting providers not in the list? They can be hacked and die,
> while the big ones are safe?
> 
> Why wouldn't a smaller company know? Can *I* be in the predisclosure list?
> If you reject me from such list, why? What's the procedure to be on such
> list?

Your lawyers sue them, or you set up a rival "fair reporting" list and
exclude members of the other predisclosure group, do your own private
fixing and then zero day hand them over to Xen.

Providing your group is well publicised most people will tell both
anyway and given the PR battle will probably favour the 'small oppressed'
division you'll probably get more of the "one group only" bugs. Quite
frankly I'd also expect the small guys to find most of the holes.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 19:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 19: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 1SjxeN-0008MJ-Ep; Wed, 27 Jun 2012 19:11:39 +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 1SjxeL-0008MA-Ia
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 19:11:38 +0000
Received: from [85.158.139.83:57777] by server-2.bemta-5.messagelabs.com id
	C3/5D-04598-8EA5BEF4; Wed, 27 Jun 2012 19:11:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340824293!29749154!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIwNzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 844 invoked from network); 27 Jun 2012 19:11:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 19:11:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,486,1336363200"; 
	d="dsl'?log'?scan'208";a="29661165"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:11:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:11:31 -0400
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 1SjxdG-000167-LU;
	Wed, 27 Jun 2012 20:10:30 +0100
Message-ID: <4FEB5AA6.4010403@citrix.com>
Date: Wed, 27 Jun 2012 20:10:30 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Dario Faggioli
	<dario.faggioli@citrix.com>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------030608030106010209090508"
Subject: [Xen-devel] Logical NUMA error during boot, and RFC 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------030608030106010209090508
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

XenServer have recently acquired a quad-socket AMD Interlagos server and
I have been playing around with it, and discovered a logical error in
how Xen detects numa nodes.

The server has 8 NUMA nodes, 4 of which have memory attached (the even
nodes - see SRAT.dsl attached).  This means that that
node_set_online(nodeid) gets called for each node with memory attached. 
Later, in srat_detect_node(), node gets set to 0 if it was NUMA_NO_NODE,
or if not node_online().  This leads to all the processors on the odd
nodes being assigned to node 0, even though the odd nodes are present
(see interlagos-xl-info-n.log)

I present an RFC patch which changes srat_detect_node() to call
node_set_online() for each node, which appears to fix the logic.

Is this a sensible place to set the node online, or is there a better
way to fix this logic?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030608030106010209090508
Content-Type: text/x-dsl; name="SRAT.dsl"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="SRAT.dsl"

/*
 * Intel ACPI Component Architecture
 * AML Disassembler version 20090521
 *
 * Disassembly of SRAT.dat, Wed Jun 27 18:03:58 2012
 *
 * ACPI Data Table [SRAT]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h 0000  4]                    Signature : "SRAT"    /* System Resource Affinity Table */
[004h 0004  4]                 Table Length : 00000520
[008h 0008  1]                     Revision : 02
[009h 0009  1]                     Checksum : D4
[00Ah 0010  6]                       Oem ID : "AMD   "
[010h 0016  8]                 Oem Table ID : "AGESA   "
[018h 0024  4]                 Oem Revision : 00000001
[01Ch 0028  4]              Asl Compiler ID : "AMD "
[020h 0032  4]        Asl Compiler Revision : 00000001

[024h 0036  4]               Table Revision : 00000001
[028h 0040  8]                     Reserved : 0000000000000000

[030h 0048  1]                Subtable Type : 01 <Memory Affinity>
[031h 0049  1]                       Length : 28

[032h 0050  4]             Proximity Domain : 00000000
[036h 0054  2]                     Reserved : 0000
[038h 0056  8]                 Base Address : 0000000000000000
[040h 0064  8]               Address Length : 00000000000A0000
[048h 0072  4]                     Reserved : 00000000
[04Ch 0076  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[050h 0080  8]                     Reserved : 0000000000000000

[058h 0088  1]                Subtable Type : 01 <Memory Affinity>
[059h 0089  1]                       Length : 28

[05Ah 0090  4]             Proximity Domain : 00000000
[05Eh 0094  2]                     Reserved : 0000
[060h 0096  8]                 Base Address : 0000000000100000
[068h 0104  8]               Address Length : 00000000BFF00000
[070h 0112  4]                     Reserved : 00000000
[074h 0116  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[078h 0120  8]                     Reserved : 0000000000000000

[080h 0128  1]                Subtable Type : 01 <Memory Affinity>
[081h 0129  1]                       Length : 28

[082h 0130  4]             Proximity Domain : 00000000
[086h 0134  2]                     Reserved : 0000
[088h 0136  8]                 Base Address : 0000000100000000
[090h 0144  8]               Address Length : 0000000140000000
[098h 0152  4]                     Reserved : 00000000
[09Ch 0156  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[0A0h 0160  8]                     Reserved : 0000000000000000

[0A8h 0168  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0A9h 0169  1]                       Length : 10

[0AAh 0170  1]      Proximity Domain Low(8) : 00
[0ABh 0171  1]                      Apic ID : 00
[0ACh 0172  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0B0h 0176  1]              Local Sapic EID : 00
[0B1h 0177  3]    Proximity Domain High(24) : 000000
[0B4h 0180  4]                     Reserved : 00000000

[0B8h 0184  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0B9h 0185  1]                       Length : 10

[0BAh 0186  1]      Proximity Domain Low(8) : 00
[0BBh 0187  1]                      Apic ID : 01
[0BCh 0188  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0C0h 0192  1]              Local Sapic EID : 00
[0C1h 0193  3]    Proximity Domain High(24) : 000000
[0C4h 0196  4]                     Reserved : 00000000

[0C8h 0200  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0C9h 0201  1]                       Length : 10

[0CAh 0202  1]      Proximity Domain Low(8) : 00
[0CBh 0203  1]                      Apic ID : 02
[0CCh 0204  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0D0h 0208  1]              Local Sapic EID : 00
[0D1h 0209  3]    Proximity Domain High(24) : 000000
[0D4h 0212  4]                     Reserved : 00000000

[0D8h 0216  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0D9h 0217  1]                       Length : 10

[0DAh 0218  1]      Proximity Domain Low(8) : 00
[0DBh 0219  1]                      Apic ID : 03
[0DCh 0220  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0E0h 0224  1]              Local Sapic EID : 00
[0E1h 0225  3]    Proximity Domain High(24) : 000000
[0E4h 0228  4]                     Reserved : 00000000

[0E8h 0232  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0E9h 0233  1]                       Length : 10

[0EAh 0234  1]      Proximity Domain Low(8) : 00
[0EBh 0235  1]                      Apic ID : 04
[0ECh 0236  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0F0h 0240  1]              Local Sapic EID : 00
[0F1h 0241  3]    Proximity Domain High(24) : 000000
[0F4h 0244  4]                     Reserved : 00000000

[0F8h 0248  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0F9h 0249  1]                       Length : 10

[0FAh 0250  1]      Proximity Domain Low(8) : 00
[0FBh 0251  1]                      Apic ID : 05
[0FCh 0252  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[100h 0256  1]              Local Sapic EID : 00
[101h 0257  3]    Proximity Domain High(24) : 000000
[104h 0260  4]                     Reserved : 00000000

[108h 0264  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[109h 0265  1]                       Length : 10

[10Ah 0266  1]      Proximity Domain Low(8) : 00
[10Bh 0267  1]                      Apic ID : 06
[10Ch 0268  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[110h 0272  1]              Local Sapic EID : 00
[111h 0273  3]    Proximity Domain High(24) : 000000
[114h 0276  4]                     Reserved : 00000000

[118h 0280  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[119h 0281  1]                       Length : 10

[11Ah 0282  1]      Proximity Domain Low(8) : 00
[11Bh 0283  1]                      Apic ID : 07
[11Ch 0284  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[120h 0288  1]              Local Sapic EID : 00
[121h 0289  3]    Proximity Domain High(24) : 000000
[124h 0292  4]                     Reserved : 00000000

[128h 0296  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[129h 0297  1]                       Length : 10

[12Ah 0298  1]      Proximity Domain Low(8) : 01
[12Bh 0299  1]                      Apic ID : 08
[12Ch 0300  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[130h 0304  1]              Local Sapic EID : 00
[131h 0305  3]    Proximity Domain High(24) : 000000
[134h 0308  4]                     Reserved : 00000000

[138h 0312  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[139h 0313  1]                       Length : 10

[13Ah 0314  1]      Proximity Domain Low(8) : 01
[13Bh 0315  1]                      Apic ID : 09
[13Ch 0316  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[140h 0320  1]              Local Sapic EID : 00
[141h 0321  3]    Proximity Domain High(24) : 000000
[144h 0324  4]                     Reserved : 00000000

[148h 0328  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[149h 0329  1]                       Length : 10

[14Ah 0330  1]      Proximity Domain Low(8) : 01
[14Bh 0331  1]                      Apic ID : 0A
[14Ch 0332  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[150h 0336  1]              Local Sapic EID : 00
[151h 0337  3]    Proximity Domain High(24) : 000000
[154h 0340  4]                     Reserved : 00000000

[158h 0344  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[159h 0345  1]                       Length : 10

[15Ah 0346  1]      Proximity Domain Low(8) : 01
[15Bh 0347  1]                      Apic ID : 0B
[15Ch 0348  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[160h 0352  1]              Local Sapic EID : 00
[161h 0353  3]    Proximity Domain High(24) : 000000
[164h 0356  4]                     Reserved : 00000000

[168h 0360  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[169h 0361  1]                       Length : 10

[16Ah 0362  1]      Proximity Domain Low(8) : 01
[16Bh 0363  1]                      Apic ID : 0C
[16Ch 0364  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[170h 0368  1]              Local Sapic EID : 00
[171h 0369  3]    Proximity Domain High(24) : 000000
[174h 0372  4]                     Reserved : 00000000

[178h 0376  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[179h 0377  1]                       Length : 10

[17Ah 0378  1]      Proximity Domain Low(8) : 01
[17Bh 0379  1]                      Apic ID : 0D
[17Ch 0380  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[180h 0384  1]              Local Sapic EID : 00
[181h 0385  3]    Proximity Domain High(24) : 000000
[184h 0388  4]                     Reserved : 00000000

[188h 0392  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[189h 0393  1]                       Length : 10

[18Ah 0394  1]      Proximity Domain Low(8) : 01
[18Bh 0395  1]                      Apic ID : 0E
[18Ch 0396  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[190h 0400  1]              Local Sapic EID : 00
[191h 0401  3]    Proximity Domain High(24) : 000000
[194h 0404  4]                     Reserved : 00000000

[198h 0408  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[199h 0409  1]                       Length : 10

[19Ah 0410  1]      Proximity Domain Low(8) : 01
[19Bh 0411  1]                      Apic ID : 0F
[19Ch 0412  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1A0h 0416  1]              Local Sapic EID : 00
[1A1h 0417  3]    Proximity Domain High(24) : 000000
[1A4h 0420  4]                     Reserved : 00000000

[1A8h 0424  1]                Subtable Type : 01 <Memory Affinity>
[1A9h 0425  1]                       Length : 28

[1AAh 0426  4]             Proximity Domain : 00000002
[1AEh 0430  2]                     Reserved : 0000
[1B0h 0432  8]                 Base Address : 0000000240000000
[1B8h 0440  8]               Address Length : 0000000200000000
[1C0h 0448  4]                     Reserved : 00000000
[1C4h 0452  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[1C8h 0456  8]                     Reserved : 0000000000000000

[1D0h 0464  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[1D1h 0465  1]                       Length : 10

[1D2h 0466  1]      Proximity Domain Low(8) : 02
[1D3h 0467  1]                      Apic ID : 20
[1D4h 0468  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1D8h 0472  1]              Local Sapic EID : 00
[1D9h 0473  3]    Proximity Domain High(24) : 000000
[1DCh 0476  4]                     Reserved : 00000000

[1E0h 0480  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[1E1h 0481  1]                       Length : 10

[1E2h 0482  1]      Proximity Domain Low(8) : 02
[1E3h 0483  1]                      Apic ID : 21
[1E4h 0484  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1E8h 0488  1]              Local Sapic EID : 00
[1E9h 0489  3]    Proximity Domain High(24) : 000000
[1ECh 0492  4]                     Reserved : 00000000

[1F0h 0496  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[1F1h 0497  1]                       Length : 10

[1F2h 0498  1]      Proximity Domain Low(8) : 02
[1F3h 0499  1]                      Apic ID : 22
[1F4h 0500  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1F8h 0504  1]              Local Sapic EID : 00
[1F9h 0505  3]    Proximity Domain High(24) : 000000
[1FCh 0508  4]                     Reserved : 00000000

[200h 0512  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[201h 0513  1]                       Length : 10

[202h 0514  1]      Proximity Domain Low(8) : 02
[203h 0515  1]                      Apic ID : 23
[204h 0516  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[208h 0520  1]              Local Sapic EID : 00
[209h 0521  3]    Proximity Domain High(24) : 000000
[20Ch 0524  4]                     Reserved : 00000000

[210h 0528  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[211h 0529  1]                       Length : 10

[212h 0530  1]      Proximity Domain Low(8) : 02
[213h 0531  1]                      Apic ID : 24
[214h 0532  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[218h 0536  1]              Local Sapic EID : 00
[219h 0537  3]    Proximity Domain High(24) : 000000
[21Ch 0540  4]                     Reserved : 00000000

[220h 0544  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[221h 0545  1]                       Length : 10

[222h 0546  1]      Proximity Domain Low(8) : 02
[223h 0547  1]                      Apic ID : 25
[224h 0548  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[228h 0552  1]              Local Sapic EID : 00
[229h 0553  3]    Proximity Domain High(24) : 000000
[22Ch 0556  4]                     Reserved : 00000000

[230h 0560  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[231h 0561  1]                       Length : 10

[232h 0562  1]      Proximity Domain Low(8) : 02
[233h 0563  1]                      Apic ID : 26
[234h 0564  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[238h 0568  1]              Local Sapic EID : 00
[239h 0569  3]    Proximity Domain High(24) : 000000
[23Ch 0572  4]                     Reserved : 00000000

[240h 0576  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[241h 0577  1]                       Length : 10

[242h 0578  1]      Proximity Domain Low(8) : 02
[243h 0579  1]                      Apic ID : 27
[244h 0580  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[248h 0584  1]              Local Sapic EID : 00
[249h 0585  3]    Proximity Domain High(24) : 000000
[24Ch 0588  4]                     Reserved : 00000000

[250h 0592  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[251h 0593  1]                       Length : 10

[252h 0594  1]      Proximity Domain Low(8) : 03
[253h 0595  1]                      Apic ID : 28
[254h 0596  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[258h 0600  1]              Local Sapic EID : 00
[259h 0601  3]    Proximity Domain High(24) : 000000
[25Ch 0604  4]                     Reserved : 00000000

[260h 0608  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[261h 0609  1]                       Length : 10

[262h 0610  1]      Proximity Domain Low(8) : 03
[263h 0611  1]                      Apic ID : 29
[264h 0612  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[268h 0616  1]              Local Sapic EID : 00
[269h 0617  3]    Proximity Domain High(24) : 000000
[26Ch 0620  4]                     Reserved : 00000000

[270h 0624  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[271h 0625  1]                       Length : 10

[272h 0626  1]      Proximity Domain Low(8) : 03
[273h 0627  1]                      Apic ID : 2A
[274h 0628  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[278h 0632  1]              Local Sapic EID : 00
[279h 0633  3]    Proximity Domain High(24) : 000000
[27Ch 0636  4]                     Reserved : 00000000

[280h 0640  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[281h 0641  1]                       Length : 10

[282h 0642  1]      Proximity Domain Low(8) : 03
[283h 0643  1]                      Apic ID : 2B
[284h 0644  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[288h 0648  1]              Local Sapic EID : 00
[289h 0649  3]    Proximity Domain High(24) : 000000
[28Ch 0652  4]                     Reserved : 00000000

[290h 0656  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[291h 0657  1]                       Length : 10

[292h 0658  1]      Proximity Domain Low(8) : 03
[293h 0659  1]                      Apic ID : 2C
[294h 0660  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[298h 0664  1]              Local Sapic EID : 00
[299h 0665  3]    Proximity Domain High(24) : 000000
[29Ch 0668  4]                     Reserved : 00000000

[2A0h 0672  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2A1h 0673  1]                       Length : 10

[2A2h 0674  1]      Proximity Domain Low(8) : 03
[2A3h 0675  1]                      Apic ID : 2D
[2A4h 0676  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[2A8h 0680  1]              Local Sapic EID : 00
[2A9h 0681  3]    Proximity Domain High(24) : 000000
[2ACh 0684  4]                     Reserved : 00000000

[2B0h 0688  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2B1h 0689  1]                       Length : 10

[2B2h 0690  1]      Proximity Domain Low(8) : 03
[2B3h 0691  1]                      Apic ID : 2E
[2B4h 0692  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[2B8h 0696  1]              Local Sapic EID : 00
[2B9h 0697  3]    Proximity Domain High(24) : 000000
[2BCh 0700  4]                     Reserved : 00000000

[2C0h 0704  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2C1h 0705  1]                       Length : 10

[2C2h 0706  1]      Proximity Domain Low(8) : 03
[2C3h 0707  1]                      Apic ID : 2F
[2C4h 0708  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[2C8h 0712  1]              Local Sapic EID : 00
[2C9h 0713  3]    Proximity Domain High(24) : 000000
[2CCh 0716  4]                     Reserved : 00000000

[2D0h 0720  1]                Subtable Type : 01 <Memory Affinity>
[2D1h 0721  1]                       Length : 28

[2D2h 0722  4]             Proximity Domain : 00000004
[2D6h 0726  2]                     Reserved : 0000
[2D8h 0728  8]                 Base Address : 0000000440000000
[2E0h 0736  8]               Address Length : 0000000200000000
[2E8h 0744  4]                     Reserved : 00000000
[2ECh 0748  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[2F0h 0752  8]                     Reserved : 0000000000000000

[2F8h 0760  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2F9h 0761  1]                       Length : 10

[2FAh 0762  1]      Proximity Domain Low(8) : 04
[2FBh 0763  1]                      Apic ID : 40
[2FCh 0764  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[300h 0768  1]              Local Sapic EID : 00
[301h 0769  3]    Proximity Domain High(24) : 000000
[304h 0772  4]                     Reserved : 00000000

[308h 0776  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[309h 0777  1]                       Length : 10

[30Ah 0778  1]      Proximity Domain Low(8) : 04
[30Bh 0779  1]                      Apic ID : 41
[30Ch 0780  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[310h 0784  1]              Local Sapic EID : 00
[311h 0785  3]    Proximity Domain High(24) : 000000
[314h 0788  4]                     Reserved : 00000000

[318h 0792  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[319h 0793  1]                       Length : 10

[31Ah 0794  1]      Proximity Domain Low(8) : 04
[31Bh 0795  1]                      Apic ID : 42
[31Ch 0796  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[320h 0800  1]              Local Sapic EID : 00
[321h 0801  3]    Proximity Domain High(24) : 000000
[324h 0804  4]                     Reserved : 00000000

[328h 0808  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[329h 0809  1]                       Length : 10

[32Ah 0810  1]      Proximity Domain Low(8) : 04
[32Bh 0811  1]                      Apic ID : 43
[32Ch 0812  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[330h 0816  1]              Local Sapic EID : 00
[331h 0817  3]    Proximity Domain High(24) : 000000
[334h 0820  4]                     Reserved : 00000000

[338h 0824  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[339h 0825  1]                       Length : 10

[33Ah 0826  1]      Proximity Domain Low(8) : 04
[33Bh 0827  1]                      Apic ID : 44
[33Ch 0828  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[340h 0832  1]              Local Sapic EID : 00
[341h 0833  3]    Proximity Domain High(24) : 000000
[344h 0836  4]                     Reserved : 00000000

[348h 0840  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[349h 0841  1]                       Length : 10

[34Ah 0842  1]      Proximity Domain Low(8) : 04
[34Bh 0843  1]                      Apic ID : 45
[34Ch 0844  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[350h 0848  1]              Local Sapic EID : 00
[351h 0849  3]    Proximity Domain High(24) : 000000
[354h 0852  4]                     Reserved : 00000000

[358h 0856  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[359h 0857  1]                       Length : 10

[35Ah 0858  1]      Proximity Domain Low(8) : 04
[35Bh 0859  1]                      Apic ID : 46
[35Ch 0860  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[360h 0864  1]              Local Sapic EID : 00
[361h 0865  3]    Proximity Domain High(24) : 000000
[364h 0868  4]                     Reserved : 00000000

[368h 0872  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[369h 0873  1]                       Length : 10

[36Ah 0874  1]      Proximity Domain Low(8) : 04
[36Bh 0875  1]                      Apic ID : 47
[36Ch 0876  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[370h 0880  1]              Local Sapic EID : 00
[371h 0881  3]    Proximity Domain High(24) : 000000
[374h 0884  4]                     Reserved : 00000000

[378h 0888  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[379h 0889  1]                       Length : 10

[37Ah 0890  1]      Proximity Domain Low(8) : 05
[37Bh 0891  1]                      Apic ID : 48
[37Ch 0892  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[380h 0896  1]              Local Sapic EID : 00
[381h 0897  3]    Proximity Domain High(24) : 000000
[384h 0900  4]                     Reserved : 00000000

[388h 0904  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[389h 0905  1]                       Length : 10

[38Ah 0906  1]      Proximity Domain Low(8) : 05
[38Bh 0907  1]                      Apic ID : 49
[38Ch 0908  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[390h 0912  1]              Local Sapic EID : 00
[391h 0913  3]    Proximity Domain High(24) : 000000
[394h 0916  4]                     Reserved : 00000000

[398h 0920  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[399h 0921  1]                       Length : 10

[39Ah 0922  1]      Proximity Domain Low(8) : 05
[39Bh 0923  1]                      Apic ID : 4A
[39Ch 0924  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3A0h 0928  1]              Local Sapic EID : 00
[3A1h 0929  3]    Proximity Domain High(24) : 000000
[3A4h 0932  4]                     Reserved : 00000000

[3A8h 0936  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3A9h 0937  1]                       Length : 10

[3AAh 0938  1]      Proximity Domain Low(8) : 05
[3ABh 0939  1]                      Apic ID : 4B
[3ACh 0940  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3B0h 0944  1]              Local Sapic EID : 00
[3B1h 0945  3]    Proximity Domain High(24) : 000000
[3B4h 0948  4]                     Reserved : 00000000

[3B8h 0952  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3B9h 0953  1]                       Length : 10

[3BAh 0954  1]      Proximity Domain Low(8) : 05
[3BBh 0955  1]                      Apic ID : 4C
[3BCh 0956  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3C0h 0960  1]              Local Sapic EID : 00
[3C1h 0961  3]    Proximity Domain High(24) : 000000
[3C4h 0964  4]                     Reserved : 00000000

[3C8h 0968  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3C9h 0969  1]                       Length : 10

[3CAh 0970  1]      Proximity Domain Low(8) : 05
[3CBh 0971  1]                      Apic ID : 4D
[3CCh 0972  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3D0h 0976  1]              Local Sapic EID : 00
[3D1h 0977  3]    Proximity Domain High(24) : 000000
[3D4h 0980  4]                     Reserved : 00000000

[3D8h 0984  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3D9h 0985  1]                       Length : 10

[3DAh 0986  1]      Proximity Domain Low(8) : 05
[3DBh 0987  1]                      Apic ID : 4E
[3DCh 0988  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3E0h 0992  1]              Local Sapic EID : 00
[3E1h 0993  3]    Proximity Domain High(24) : 000000
[3E4h 0996  4]                     Reserved : 00000000

[3E8h 1000  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3E9h 1001  1]                       Length : 10

[3EAh 1002  1]      Proximity Domain Low(8) : 05
[3EBh 1003  1]                      Apic ID : 4F
[3ECh 1004  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3F0h 1008  1]              Local Sapic EID : 00
[3F1h 1009  3]    Proximity Domain High(24) : 000000
[3F4h 1012  4]                     Reserved : 00000000

[3F8h 1016  1]                Subtable Type : 01 <Memory Affinity>
[3F9h 1017  1]                       Length : 28

[3FAh 1018  4]             Proximity Domain : 00000006
[3FEh 1022  2]                     Reserved : 0000
[400h 1024  8]                 Base Address : 0000000640000000
[408h 1032  8]               Address Length : 00000001FF000000
[410h 1040  4]                     Reserved : 00000000
[414h 1044  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[418h 1048  8]                     Reserved : 0000000000000000

[420h 1056  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[421h 1057  1]                       Length : 10

[422h 1058  1]      Proximity Domain Low(8) : 06
[423h 1059  1]                      Apic ID : 60
[424h 1060  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[428h 1064  1]              Local Sapic EID : 00
[429h 1065  3]    Proximity Domain High(24) : 000000
[42Ch 1068  4]                     Reserved : 00000000

[430h 1072  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[431h 1073  1]                       Length : 10

[432h 1074  1]      Proximity Domain Low(8) : 06
[433h 1075  1]                      Apic ID : 61
[434h 1076  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[438h 1080  1]              Local Sapic EID : 00
[439h 1081  3]    Proximity Domain High(24) : 000000
[43Ch 1084  4]                     Reserved : 00000000

[440h 1088  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[441h 1089  1]                       Length : 10

[442h 1090  1]      Proximity Domain Low(8) : 06
[443h 1091  1]                      Apic ID : 62
[444h 1092  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[448h 1096  1]              Local Sapic EID : 00
[449h 1097  3]    Proximity Domain High(24) : 000000
[44Ch 1100  4]                     Reserved : 00000000

[450h 1104  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[451h 1105  1]                       Length : 10

[452h 1106  1]      Proximity Domain Low(8) : 06
[453h 1107  1]                      Apic ID : 63
[454h 1108  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[458h 1112  1]              Local Sapic EID : 00
[459h 1113  3]    Proximity Domain High(24) : 000000
[45Ch 1116  4]                     Reserved : 00000000

[460h 1120  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[461h 1121  1]                       Length : 10

[462h 1122  1]      Proximity Domain Low(8) : 06
[463h 1123  1]                      Apic ID : 64
[464h 1124  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[468h 1128  1]              Local Sapic EID : 00
[469h 1129  3]    Proximity Domain High(24) : 000000
[46Ch 1132  4]                     Reserved : 00000000

[470h 1136  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[471h 1137  1]                       Length : 10

[472h 1138  1]      Proximity Domain Low(8) : 06
[473h 1139  1]                      Apic ID : 65
[474h 1140  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[478h 1144  1]              Local Sapic EID : 00
[479h 1145  3]    Proximity Domain High(24) : 000000
[47Ch 1148  4]                     Reserved : 00000000

[480h 1152  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[481h 1153  1]                       Length : 10

[482h 1154  1]      Proximity Domain Low(8) : 06
[483h 1155  1]                      Apic ID : 66
[484h 1156  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[488h 1160  1]              Local Sapic EID : 00
[489h 1161  3]    Proximity Domain High(24) : 000000
[48Ch 1164  4]                     Reserved : 00000000

[490h 1168  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[491h 1169  1]                       Length : 10

[492h 1170  1]      Proximity Domain Low(8) : 06
[493h 1171  1]                      Apic ID : 67
[494h 1172  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[498h 1176  1]              Local Sapic EID : 00
[499h 1177  3]    Proximity Domain High(24) : 000000
[49Ch 1180  4]                     Reserved : 00000000

[4A0h 1184  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4A1h 1185  1]                       Length : 10

[4A2h 1186  1]      Proximity Domain Low(8) : 07
[4A3h 1187  1]                      Apic ID : 68
[4A4h 1188  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4A8h 1192  1]              Local Sapic EID : 00
[4A9h 1193  3]    Proximity Domain High(24) : 000000
[4ACh 1196  4]                     Reserved : 00000000

[4B0h 1200  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4B1h 1201  1]                       Length : 10

[4B2h 1202  1]      Proximity Domain Low(8) : 07
[4B3h 1203  1]                      Apic ID : 69
[4B4h 1204  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4B8h 1208  1]              Local Sapic EID : 00
[4B9h 1209  3]    Proximity Domain High(24) : 000000
[4BCh 1212  4]                     Reserved : 00000000

[4C0h 1216  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4C1h 1217  1]                       Length : 10

[4C2h 1218  1]      Proximity Domain Low(8) : 07
[4C3h 1219  1]                      Apic ID : 6A
[4C4h 1220  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4C8h 1224  1]              Local Sapic EID : 00
[4C9h 1225  3]    Proximity Domain High(24) : 000000
[4CCh 1228  4]                     Reserved : 00000000

[4D0h 1232  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4D1h 1233  1]                       Length : 10

[4D2h 1234  1]      Proximity Domain Low(8) : 07
[4D3h 1235  1]                      Apic ID : 6B
[4D4h 1236  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4D8h 1240  1]              Local Sapic EID : 00
[4D9h 1241  3]    Proximity Domain High(24) : 000000
[4DCh 1244  4]                     Reserved : 00000000

[4E0h 1248  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4E1h 1249  1]                       Length : 10

[4E2h 1250  1]      Proximity Domain Low(8) : 07
[4E3h 1251  1]                      Apic ID : 6C
[4E4h 1252  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4E8h 1256  1]              Local Sapic EID : 00
[4E9h 1257  3]    Proximity Domain High(24) : 000000
[4ECh 1260  4]                     Reserved : 00000000

[4F0h 1264  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4F1h 1265  1]                       Length : 10

[4F2h 1266  1]      Proximity Domain Low(8) : 07
[4F3h 1267  1]                      Apic ID : 6D
[4F4h 1268  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4F8h 1272  1]              Local Sapic EID : 00
[4F9h 1273  3]    Proximity Domain High(24) : 000000
[4FCh 1276  4]                     Reserved : 00000000

[500h 1280  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[501h 1281  1]                       Length : 10

[502h 1282  1]      Proximity Domain Low(8) : 07
[503h 1283  1]                      Apic ID : 6E
[504h 1284  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[508h 1288  1]              Local Sapic EID : 00
[509h 1289  3]    Proximity Domain High(24) : 000000
[50Ch 1292  4]                     Reserved : 00000000

[510h 1296  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[511h 1297  1]                       Length : 10

[512h 1298  1]      Proximity Domain Low(8) : 07
[513h 1299  1]                      Apic ID : 6F
[514h 1300  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[518h 1304  1]              Local Sapic EID : 00
[519h 1305  3]    Proximity Domain High(24) : 000000
[51Ch 1308  4]                     Reserved : 00000000

Raw Table Data

  0000: 53 52 41 54 20 05 00 00 02 D4 41 4D 44 20 20 20  SRAT .....AMD   
  0010: 41 47 45 53 41 20 20 20 01 00 00 00 41 4D 44 20  AGESA   ....AMD 
  0020: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0030: 01 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .(..............
  0040: 00 00 0A 00 00 00 00 00 00 00 00 00 01 00 00 00  ................
  0050: 00 00 00 00 00 00 00 00 01 28 00 00 00 00 00 00  .........(......
  0060: 00 00 10 00 00 00 00 00 00 00 F0 BF 00 00 00 00  ................
  0070: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0080: 01 28 00 00 00 00 00 00 00 00 00 00 01 00 00 00  .(..............
  0090: 00 00 00 40 01 00 00 00 00 00 00 00 01 00 00 00  ...@............
  00A0: 00 00 00 00 00 00 00 00 00 10 00 00 01 00 00 00  ................
  00B0: 00 00 00 00 00 00 00 00 00 10 00 01 01 00 00 00  ................
  00C0: 00 00 00 00 00 00 00 00 00 10 00 02 01 00 00 00  ................
  00D0: 00 00 00 00 00 00 00 00 00 10 00 03 01 00 00 00  ................
  00E0: 00 00 00 00 00 00 00 00 00 10 00 04 01 00 00 00  ................
  00F0: 00 00 00 00 00 00 00 00 00 10 00 05 01 00 00 00  ................
  0100: 00 00 00 00 00 00 00 00 00 10 00 06 01 00 00 00  ................
  0110: 00 00 00 00 00 00 00 00 00 10 00 07 01 00 00 00  ................
  0120: 00 00 00 00 00 00 00 00 00 10 01 08 01 00 00 00  ................
  0130: 00 00 00 00 00 00 00 00 00 10 01 09 01 00 00 00  ................
  0140: 00 00 00 00 00 00 00 00 00 10 01 0A 01 00 00 00  ................
  0150: 00 00 00 00 00 00 00 00 00 10 01 0B 01 00 00 00  ................
  0160: 00 00 00 00 00 00 00 00 00 10 01 0C 01 00 00 00  ................
  0170: 00 00 00 00 00 00 00 00 00 10 01 0D 01 00 00 00  ................
  0180: 00 00 00 00 00 00 00 00 00 10 01 0E 01 00 00 00  ................
  0190: 00 00 00 00 00 00 00 00 00 10 01 0F 01 00 00 00  ................
  01A0: 00 00 00 00 00 00 00 00 01 28 02 00 00 00 00 00  .........(......
  01B0: 00 00 00 40 02 00 00 00 00 00 00 00 02 00 00 00  ...@............
  01C0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  01D0: 00 10 02 20 01 00 00 00 00 00 00 00 00 00 00 00  ... ............
  01E0: 00 10 02 21 01 00 00 00 00 00 00 00 00 00 00 00  ...!............
  01F0: 00 10 02 22 01 00 00 00 00 00 00 00 00 00 00 00  ..."............
  0200: 00 10 02 23 01 00 00 00 00 00 00 00 00 00 00 00  ...#............
  0210: 00 10 02 24 01 00 00 00 00 00 00 00 00 00 00 00  ...$............
  0220: 00 10 02 25 01 00 00 00 00 00 00 00 00 00 00 00  ...%............
  0230: 00 10 02 26 01 00 00 00 00 00 00 00 00 00 00 00  ...&............
  0240: 00 10 02 27 01 00 00 00 00 00 00 00 00 00 00 00  ...'............
  0250: 00 10 03 28 01 00 00 00 00 00 00 00 00 00 00 00  ...(............
  0260: 00 10 03 29 01 00 00 00 00 00 00 00 00 00 00 00  ...)............
  0270: 00 10 03 2A 01 00 00 00 00 00 00 00 00 00 00 00  ...*............
  0280: 00 10 03 2B 01 00 00 00 00 00 00 00 00 00 00 00  ...+............
  0290: 00 10 03 2C 01 00 00 00 00 00 00 00 00 00 00 00  ...,............
  02A0: 00 10 03 2D 01 00 00 00 00 00 00 00 00 00 00 00  ...-............
  02B0: 00 10 03 2E 01 00 00 00 00 00 00 00 00 00 00 00  ................
  02C0: 00 10 03 2F 01 00 00 00 00 00 00 00 00 00 00 00  .../............
  02D0: 01 28 04 00 00 00 00 00 00 00 00 40 04 00 00 00  .(.........@....
  02E0: 00 00 00 00 02 00 00 00 00 00 00 00 01 00 00 00  ................
  02F0: 00 00 00 00 00 00 00 00 00 10 04 40 01 00 00 00  ...........@....
  0300: 00 00 00 00 00 00 00 00 00 10 04 41 01 00 00 00  ...........A....
  0310: 00 00 00 00 00 00 00 00 00 10 04 42 01 00 00 00  ...........B....
  0320: 00 00 00 00 00 00 00 00 00 10 04 43 01 00 00 00  ...........C....
  0330: 00 00 00 00 00 00 00 00 00 10 04 44 01 00 00 00  ...........D....
  0340: 00 00 00 00 00 00 00 00 00 10 04 45 01 00 00 00  ...........E....
  0350: 00 00 00 00 00 00 00 00 00 10 04 46 01 00 00 00  ...........F....
  0360: 00 00 00 00 00 00 00 00 00 10 04 47 01 00 00 00  ...........G....
  0370: 00 00 00 00 00 00 00 00 00 10 05 48 01 00 00 00  ...........H....
  0380: 00 00 00 00 00 00 00 00 00 10 05 49 01 00 00 00  ...........I....
  0390: 00 00 00 00 00 00 00 00 00 10 05 4A 01 00 00 00  ...........J....
  03A0: 00 00 00 00 00 00 00 00 00 10 05 4B 01 00 00 00  ...........K....
  03B0: 00 00 00 00 00 00 00 00 00 10 05 4C 01 00 00 00  ...........L....
  03C0: 00 00 00 00 00 00 00 00 00 10 05 4D 01 00 00 00  ...........M....
  03D0: 00 00 00 00 00 00 00 00 00 10 05 4E 01 00 00 00  ...........N....
  03E0: 00 00 00 00 00 00 00 00 00 10 05 4F 01 00 00 00  ...........O....
  03F0: 00 00 00 00 00 00 00 00 01 28 06 00 00 00 00 00  .........(......
  0400: 00 00 00 40 06 00 00 00 00 00 00 FF 01 00 00 00  ...@............
  0410: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0420: 00 10 06 60 01 00 00 00 00 00 00 00 00 00 00 00  ...`............
  0430: 00 10 06 61 01 00 00 00 00 00 00 00 00 00 00 00  ...a............
  0440: 00 10 06 62 01 00 00 00 00 00 00 00 00 00 00 00  ...b............
  0450: 00 10 06 63 01 00 00 00 00 00 00 00 00 00 00 00  ...c............
  0460: 00 10 06 64 01 00 00 00 00 00 00 00 00 00 00 00  ...d............
  0470: 00 10 06 65 01 00 00 00 00 00 00 00 00 00 00 00  ...e............
  0480: 00 10 06 66 01 00 00 00 00 00 00 00 00 00 00 00  ...f............
  0490: 00 10 06 67 01 00 00 00 00 00 00 00 00 00 00 00  ...g............
  04A0: 00 10 07 68 01 00 00 00 00 00 00 00 00 00 00 00  ...h............
  04B0: 00 10 07 69 01 00 00 00 00 00 00 00 00 00 00 00  ...i............
  04C0: 00 10 07 6A 01 00 00 00 00 00 00 00 00 00 00 00  ...j............
  04D0: 00 10 07 6B 01 00 00 00 00 00 00 00 00 00 00 00  ...k............
  04E0: 00 10 07 6C 01 00 00 00 00 00 00 00 00 00 00 00  ...l............
  04F0: 00 10 07 6D 01 00 00 00 00 00 00 00 00 00 00 00  ...m............
  0500: 00 10 07 6E 01 00 00 00 00 00 00 00 00 00 00 00  ...n............
  0510: 00 10 07 6F 01 00 00 00 00 00 00 00 00 00 00 00  ...o............

--------------030608030106010209090508
Content-Type: text/x-log; name="interlagos-xl-info-n.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="interlagos-xl-info-n.log"

host                   : bos-r815-1
release                : 2.6.32.43-0.4.1.xs1.5.50.696.170738xen
version                : #1 SMP Mon Jun 18 09:27:43 EDT 2012
machine                : i686
nr_cpus                : 64
max_cpu_id             : 63
nr_nodes               : 4
cores_per_socket       : 8
threads_per_core       : 2
cpu_mhz                : 2600
hw_caps                : 178bf3ff:2fd3fbff:00000000:00001710:12982203:00000000:01c9bfff:00000000
virt_caps              : hvm hvm_directio
total_memory           : 32742
free_memory            : 31502
free_cpus              : 0
cpu_topology           :
cpu:    core    socket     node
  0:       0        0        0
  1:       1        0        0
  2:       2        0        0
  3:       3        0        0
  4:       4        0        0
  5:       5        0        0
  6:       6        0        0
  7:       7        0        0
  8:       8        0        0
  9:       9        0        0
 10:      10        0        0
 11:      11        0        0
 12:      12        0        0
 13:      13        0        0
 14:      14        0        0
 15:      15        0        0
 16:       0        1        2
 17:       1        1        2
 18:       2        1        2
 19:       3        1        2
 20:       4        1        2
 21:       5        1        2
 22:       6        1        2
 23:       7        1        2
 24:       8        1        0
 25:       9        1        0
 26:      10        1        0
 27:      11        1        0
 28:      12        1        0
 29:      13        1        0
 30:      14        1        0
 31:      15        1        0
 32:       0        2        4
 33:       1        2        4
 34:       2        2        4
 35:       3        2        4
 36:       4        2        4
 37:       5        2        4
 38:       6        2        4
 39:       7        2        4
 40:       8        2        0
 41:       9        2        0
 42:      10        2        0
 43:      11        2        0
 44:      12        2        0
 45:      13        2        0
 46:      14        2        0
 47:      15        2        0
 48:       0        3        6
 49:       1        3        6
 50:       2        3        6
 51:       3        3        6
 52:       4        3        6
 53:       5        3        6
 54:       6        3        6
 55:       7        3        6
 56:       8        3        0
 57:       9        3        0
 58:      10        3        0
 59:      11        3        0
 60:      12        3        0
 61:      13        3        0
 62:      14        3        0
 63:      15        3        0
numa_info              : none
xen_major              : 4
xen_minor              : 1
xen_extra              : .2
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=0xfdc00000
xen_changeset          : Wed Jun 27 19:34:58 2012 +0100 23517:b004f4ef0cff
xen_commandline        : com1=115200,8n1 console=com1,vga loglvl=all cpuinfo mem=1024G dom0_mem=752M,max:752M watchdog_timeout=300 cpuid_mask_xsave_eax=0 lowmem_emergency_pool=1M crashkernel=64M@32M dom0_max_vcpus=4
cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
cc_compile_by          : andrewcoop
cc_compile_domain      : uk.xensource.com
cc_compile_date        : Wed Jun 27 14:34:59 EDT 2012
xend_config_format     : 4

--------------030608030106010209090508
Content-Type: text/x-patch; name="RFC-fix-numa-online.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="RFC-fix-numa-online.patch"

# HG changeset patch
# Parent c6c9d20963d7c5d8022a8cbe6bdaea359804f284
diff -r c6c9d20963d7 -r a0a7f546f22e xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -195,8 +195,10 @@ void __devinit srat_detect_node(int cpu)
     u32 apicid = x86_cpu_to_apicid[cpu];
 
     node = apicid_to_node[apicid];
-    if ( node == NUMA_NO_NODE || !node_online(node) )
+    if ( node == NUMA_NO_NODE )
         node = 0;
+
+    node_set_online(node);
     numa_set_node(cpu, node);
 
     if ( opt_cpu_info && acpi_numa > 0 )

--------------030608030106010209090508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030608030106010209090508--


From xen-devel-bounces@lists.xen.org Wed Jun 27 19:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 19: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 1SjxeN-0008MJ-Ep; Wed, 27 Jun 2012 19:11:39 +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 1SjxeL-0008MA-Ia
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 19:11:38 +0000
Received: from [85.158.139.83:57777] by server-2.bemta-5.messagelabs.com id
	C3/5D-04598-8EA5BEF4; Wed, 27 Jun 2012 19:11:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340824293!29749154!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTIwNzI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 844 invoked from network); 27 Jun 2012 19:11:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 19:11:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,486,1336363200"; 
	d="dsl'?log'?scan'208";a="29661165"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 15:11:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 27 Jun 2012 15:11:31 -0400
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 1SjxdG-000167-LU;
	Wed, 27 Jun 2012 20:10:30 +0100
Message-ID: <4FEB5AA6.4010403@citrix.com>
Date: Wed, 27 Jun 2012 20:10:30 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Dario Faggioli
	<dario.faggioli@citrix.com>
X-Enigmail-Version: 1.4.2
Content-Type: multipart/mixed; boundary="------------030608030106010209090508"
Subject: [Xen-devel] Logical NUMA error during boot, and RFC 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------030608030106010209090508
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

XenServer have recently acquired a quad-socket AMD Interlagos server and
I have been playing around with it, and discovered a logical error in
how Xen detects numa nodes.

The server has 8 NUMA nodes, 4 of which have memory attached (the even
nodes - see SRAT.dsl attached).  This means that that
node_set_online(nodeid) gets called for each node with memory attached. 
Later, in srat_detect_node(), node gets set to 0 if it was NUMA_NO_NODE,
or if not node_online().  This leads to all the processors on the odd
nodes being assigned to node 0, even though the odd nodes are present
(see interlagos-xl-info-n.log)

I present an RFC patch which changes srat_detect_node() to call
node_set_online() for each node, which appears to fix the logic.

Is this a sensible place to set the node online, or is there a better
way to fix this logic?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030608030106010209090508
Content-Type: text/x-dsl; name="SRAT.dsl"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="SRAT.dsl"

/*
 * Intel ACPI Component Architecture
 * AML Disassembler version 20090521
 *
 * Disassembly of SRAT.dat, Wed Jun 27 18:03:58 2012
 *
 * ACPI Data Table [SRAT]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h 0000  4]                    Signature : "SRAT"    /* System Resource Affinity Table */
[004h 0004  4]                 Table Length : 00000520
[008h 0008  1]                     Revision : 02
[009h 0009  1]                     Checksum : D4
[00Ah 0010  6]                       Oem ID : "AMD   "
[010h 0016  8]                 Oem Table ID : "AGESA   "
[018h 0024  4]                 Oem Revision : 00000001
[01Ch 0028  4]              Asl Compiler ID : "AMD "
[020h 0032  4]        Asl Compiler Revision : 00000001

[024h 0036  4]               Table Revision : 00000001
[028h 0040  8]                     Reserved : 0000000000000000

[030h 0048  1]                Subtable Type : 01 <Memory Affinity>
[031h 0049  1]                       Length : 28

[032h 0050  4]             Proximity Domain : 00000000
[036h 0054  2]                     Reserved : 0000
[038h 0056  8]                 Base Address : 0000000000000000
[040h 0064  8]               Address Length : 00000000000A0000
[048h 0072  4]                     Reserved : 00000000
[04Ch 0076  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[050h 0080  8]                     Reserved : 0000000000000000

[058h 0088  1]                Subtable Type : 01 <Memory Affinity>
[059h 0089  1]                       Length : 28

[05Ah 0090  4]             Proximity Domain : 00000000
[05Eh 0094  2]                     Reserved : 0000
[060h 0096  8]                 Base Address : 0000000000100000
[068h 0104  8]               Address Length : 00000000BFF00000
[070h 0112  4]                     Reserved : 00000000
[074h 0116  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[078h 0120  8]                     Reserved : 0000000000000000

[080h 0128  1]                Subtable Type : 01 <Memory Affinity>
[081h 0129  1]                       Length : 28

[082h 0130  4]             Proximity Domain : 00000000
[086h 0134  2]                     Reserved : 0000
[088h 0136  8]                 Base Address : 0000000100000000
[090h 0144  8]               Address Length : 0000000140000000
[098h 0152  4]                     Reserved : 00000000
[09Ch 0156  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[0A0h 0160  8]                     Reserved : 0000000000000000

[0A8h 0168  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0A9h 0169  1]                       Length : 10

[0AAh 0170  1]      Proximity Domain Low(8) : 00
[0ABh 0171  1]                      Apic ID : 00
[0ACh 0172  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0B0h 0176  1]              Local Sapic EID : 00
[0B1h 0177  3]    Proximity Domain High(24) : 000000
[0B4h 0180  4]                     Reserved : 00000000

[0B8h 0184  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0B9h 0185  1]                       Length : 10

[0BAh 0186  1]      Proximity Domain Low(8) : 00
[0BBh 0187  1]                      Apic ID : 01
[0BCh 0188  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0C0h 0192  1]              Local Sapic EID : 00
[0C1h 0193  3]    Proximity Domain High(24) : 000000
[0C4h 0196  4]                     Reserved : 00000000

[0C8h 0200  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0C9h 0201  1]                       Length : 10

[0CAh 0202  1]      Proximity Domain Low(8) : 00
[0CBh 0203  1]                      Apic ID : 02
[0CCh 0204  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0D0h 0208  1]              Local Sapic EID : 00
[0D1h 0209  3]    Proximity Domain High(24) : 000000
[0D4h 0212  4]                     Reserved : 00000000

[0D8h 0216  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0D9h 0217  1]                       Length : 10

[0DAh 0218  1]      Proximity Domain Low(8) : 00
[0DBh 0219  1]                      Apic ID : 03
[0DCh 0220  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0E0h 0224  1]              Local Sapic EID : 00
[0E1h 0225  3]    Proximity Domain High(24) : 000000
[0E4h 0228  4]                     Reserved : 00000000

[0E8h 0232  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0E9h 0233  1]                       Length : 10

[0EAh 0234  1]      Proximity Domain Low(8) : 00
[0EBh 0235  1]                      Apic ID : 04
[0ECh 0236  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[0F0h 0240  1]              Local Sapic EID : 00
[0F1h 0241  3]    Proximity Domain High(24) : 000000
[0F4h 0244  4]                     Reserved : 00000000

[0F8h 0248  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[0F9h 0249  1]                       Length : 10

[0FAh 0250  1]      Proximity Domain Low(8) : 00
[0FBh 0251  1]                      Apic ID : 05
[0FCh 0252  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[100h 0256  1]              Local Sapic EID : 00
[101h 0257  3]    Proximity Domain High(24) : 000000
[104h 0260  4]                     Reserved : 00000000

[108h 0264  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[109h 0265  1]                       Length : 10

[10Ah 0266  1]      Proximity Domain Low(8) : 00
[10Bh 0267  1]                      Apic ID : 06
[10Ch 0268  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[110h 0272  1]              Local Sapic EID : 00
[111h 0273  3]    Proximity Domain High(24) : 000000
[114h 0276  4]                     Reserved : 00000000

[118h 0280  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[119h 0281  1]                       Length : 10

[11Ah 0282  1]      Proximity Domain Low(8) : 00
[11Bh 0283  1]                      Apic ID : 07
[11Ch 0284  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[120h 0288  1]              Local Sapic EID : 00
[121h 0289  3]    Proximity Domain High(24) : 000000
[124h 0292  4]                     Reserved : 00000000

[128h 0296  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[129h 0297  1]                       Length : 10

[12Ah 0298  1]      Proximity Domain Low(8) : 01
[12Bh 0299  1]                      Apic ID : 08
[12Ch 0300  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[130h 0304  1]              Local Sapic EID : 00
[131h 0305  3]    Proximity Domain High(24) : 000000
[134h 0308  4]                     Reserved : 00000000

[138h 0312  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[139h 0313  1]                       Length : 10

[13Ah 0314  1]      Proximity Domain Low(8) : 01
[13Bh 0315  1]                      Apic ID : 09
[13Ch 0316  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[140h 0320  1]              Local Sapic EID : 00
[141h 0321  3]    Proximity Domain High(24) : 000000
[144h 0324  4]                     Reserved : 00000000

[148h 0328  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[149h 0329  1]                       Length : 10

[14Ah 0330  1]      Proximity Domain Low(8) : 01
[14Bh 0331  1]                      Apic ID : 0A
[14Ch 0332  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[150h 0336  1]              Local Sapic EID : 00
[151h 0337  3]    Proximity Domain High(24) : 000000
[154h 0340  4]                     Reserved : 00000000

[158h 0344  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[159h 0345  1]                       Length : 10

[15Ah 0346  1]      Proximity Domain Low(8) : 01
[15Bh 0347  1]                      Apic ID : 0B
[15Ch 0348  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[160h 0352  1]              Local Sapic EID : 00
[161h 0353  3]    Proximity Domain High(24) : 000000
[164h 0356  4]                     Reserved : 00000000

[168h 0360  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[169h 0361  1]                       Length : 10

[16Ah 0362  1]      Proximity Domain Low(8) : 01
[16Bh 0363  1]                      Apic ID : 0C
[16Ch 0364  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[170h 0368  1]              Local Sapic EID : 00
[171h 0369  3]    Proximity Domain High(24) : 000000
[174h 0372  4]                     Reserved : 00000000

[178h 0376  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[179h 0377  1]                       Length : 10

[17Ah 0378  1]      Proximity Domain Low(8) : 01
[17Bh 0379  1]                      Apic ID : 0D
[17Ch 0380  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[180h 0384  1]              Local Sapic EID : 00
[181h 0385  3]    Proximity Domain High(24) : 000000
[184h 0388  4]                     Reserved : 00000000

[188h 0392  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[189h 0393  1]                       Length : 10

[18Ah 0394  1]      Proximity Domain Low(8) : 01
[18Bh 0395  1]                      Apic ID : 0E
[18Ch 0396  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[190h 0400  1]              Local Sapic EID : 00
[191h 0401  3]    Proximity Domain High(24) : 000000
[194h 0404  4]                     Reserved : 00000000

[198h 0408  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[199h 0409  1]                       Length : 10

[19Ah 0410  1]      Proximity Domain Low(8) : 01
[19Bh 0411  1]                      Apic ID : 0F
[19Ch 0412  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1A0h 0416  1]              Local Sapic EID : 00
[1A1h 0417  3]    Proximity Domain High(24) : 000000
[1A4h 0420  4]                     Reserved : 00000000

[1A8h 0424  1]                Subtable Type : 01 <Memory Affinity>
[1A9h 0425  1]                       Length : 28

[1AAh 0426  4]             Proximity Domain : 00000002
[1AEh 0430  2]                     Reserved : 0000
[1B0h 0432  8]                 Base Address : 0000000240000000
[1B8h 0440  8]               Address Length : 0000000200000000
[1C0h 0448  4]                     Reserved : 00000000
[1C4h 0452  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[1C8h 0456  8]                     Reserved : 0000000000000000

[1D0h 0464  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[1D1h 0465  1]                       Length : 10

[1D2h 0466  1]      Proximity Domain Low(8) : 02
[1D3h 0467  1]                      Apic ID : 20
[1D4h 0468  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1D8h 0472  1]              Local Sapic EID : 00
[1D9h 0473  3]    Proximity Domain High(24) : 000000
[1DCh 0476  4]                     Reserved : 00000000

[1E0h 0480  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[1E1h 0481  1]                       Length : 10

[1E2h 0482  1]      Proximity Domain Low(8) : 02
[1E3h 0483  1]                      Apic ID : 21
[1E4h 0484  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1E8h 0488  1]              Local Sapic EID : 00
[1E9h 0489  3]    Proximity Domain High(24) : 000000
[1ECh 0492  4]                     Reserved : 00000000

[1F0h 0496  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[1F1h 0497  1]                       Length : 10

[1F2h 0498  1]      Proximity Domain Low(8) : 02
[1F3h 0499  1]                      Apic ID : 22
[1F4h 0500  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[1F8h 0504  1]              Local Sapic EID : 00
[1F9h 0505  3]    Proximity Domain High(24) : 000000
[1FCh 0508  4]                     Reserved : 00000000

[200h 0512  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[201h 0513  1]                       Length : 10

[202h 0514  1]      Proximity Domain Low(8) : 02
[203h 0515  1]                      Apic ID : 23
[204h 0516  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[208h 0520  1]              Local Sapic EID : 00
[209h 0521  3]    Proximity Domain High(24) : 000000
[20Ch 0524  4]                     Reserved : 00000000

[210h 0528  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[211h 0529  1]                       Length : 10

[212h 0530  1]      Proximity Domain Low(8) : 02
[213h 0531  1]                      Apic ID : 24
[214h 0532  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[218h 0536  1]              Local Sapic EID : 00
[219h 0537  3]    Proximity Domain High(24) : 000000
[21Ch 0540  4]                     Reserved : 00000000

[220h 0544  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[221h 0545  1]                       Length : 10

[222h 0546  1]      Proximity Domain Low(8) : 02
[223h 0547  1]                      Apic ID : 25
[224h 0548  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[228h 0552  1]              Local Sapic EID : 00
[229h 0553  3]    Proximity Domain High(24) : 000000
[22Ch 0556  4]                     Reserved : 00000000

[230h 0560  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[231h 0561  1]                       Length : 10

[232h 0562  1]      Proximity Domain Low(8) : 02
[233h 0563  1]                      Apic ID : 26
[234h 0564  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[238h 0568  1]              Local Sapic EID : 00
[239h 0569  3]    Proximity Domain High(24) : 000000
[23Ch 0572  4]                     Reserved : 00000000

[240h 0576  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[241h 0577  1]                       Length : 10

[242h 0578  1]      Proximity Domain Low(8) : 02
[243h 0579  1]                      Apic ID : 27
[244h 0580  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[248h 0584  1]              Local Sapic EID : 00
[249h 0585  3]    Proximity Domain High(24) : 000000
[24Ch 0588  4]                     Reserved : 00000000

[250h 0592  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[251h 0593  1]                       Length : 10

[252h 0594  1]      Proximity Domain Low(8) : 03
[253h 0595  1]                      Apic ID : 28
[254h 0596  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[258h 0600  1]              Local Sapic EID : 00
[259h 0601  3]    Proximity Domain High(24) : 000000
[25Ch 0604  4]                     Reserved : 00000000

[260h 0608  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[261h 0609  1]                       Length : 10

[262h 0610  1]      Proximity Domain Low(8) : 03
[263h 0611  1]                      Apic ID : 29
[264h 0612  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[268h 0616  1]              Local Sapic EID : 00
[269h 0617  3]    Proximity Domain High(24) : 000000
[26Ch 0620  4]                     Reserved : 00000000

[270h 0624  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[271h 0625  1]                       Length : 10

[272h 0626  1]      Proximity Domain Low(8) : 03
[273h 0627  1]                      Apic ID : 2A
[274h 0628  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[278h 0632  1]              Local Sapic EID : 00
[279h 0633  3]    Proximity Domain High(24) : 000000
[27Ch 0636  4]                     Reserved : 00000000

[280h 0640  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[281h 0641  1]                       Length : 10

[282h 0642  1]      Proximity Domain Low(8) : 03
[283h 0643  1]                      Apic ID : 2B
[284h 0644  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[288h 0648  1]              Local Sapic EID : 00
[289h 0649  3]    Proximity Domain High(24) : 000000
[28Ch 0652  4]                     Reserved : 00000000

[290h 0656  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[291h 0657  1]                       Length : 10

[292h 0658  1]      Proximity Domain Low(8) : 03
[293h 0659  1]                      Apic ID : 2C
[294h 0660  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[298h 0664  1]              Local Sapic EID : 00
[299h 0665  3]    Proximity Domain High(24) : 000000
[29Ch 0668  4]                     Reserved : 00000000

[2A0h 0672  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2A1h 0673  1]                       Length : 10

[2A2h 0674  1]      Proximity Domain Low(8) : 03
[2A3h 0675  1]                      Apic ID : 2D
[2A4h 0676  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[2A8h 0680  1]              Local Sapic EID : 00
[2A9h 0681  3]    Proximity Domain High(24) : 000000
[2ACh 0684  4]                     Reserved : 00000000

[2B0h 0688  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2B1h 0689  1]                       Length : 10

[2B2h 0690  1]      Proximity Domain Low(8) : 03
[2B3h 0691  1]                      Apic ID : 2E
[2B4h 0692  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[2B8h 0696  1]              Local Sapic EID : 00
[2B9h 0697  3]    Proximity Domain High(24) : 000000
[2BCh 0700  4]                     Reserved : 00000000

[2C0h 0704  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2C1h 0705  1]                       Length : 10

[2C2h 0706  1]      Proximity Domain Low(8) : 03
[2C3h 0707  1]                      Apic ID : 2F
[2C4h 0708  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[2C8h 0712  1]              Local Sapic EID : 00
[2C9h 0713  3]    Proximity Domain High(24) : 000000
[2CCh 0716  4]                     Reserved : 00000000

[2D0h 0720  1]                Subtable Type : 01 <Memory Affinity>
[2D1h 0721  1]                       Length : 28

[2D2h 0722  4]             Proximity Domain : 00000004
[2D6h 0726  2]                     Reserved : 0000
[2D8h 0728  8]                 Base Address : 0000000440000000
[2E0h 0736  8]               Address Length : 0000000200000000
[2E8h 0744  4]                     Reserved : 00000000
[2ECh 0748  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[2F0h 0752  8]                     Reserved : 0000000000000000

[2F8h 0760  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[2F9h 0761  1]                       Length : 10

[2FAh 0762  1]      Proximity Domain Low(8) : 04
[2FBh 0763  1]                      Apic ID : 40
[2FCh 0764  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[300h 0768  1]              Local Sapic EID : 00
[301h 0769  3]    Proximity Domain High(24) : 000000
[304h 0772  4]                     Reserved : 00000000

[308h 0776  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[309h 0777  1]                       Length : 10

[30Ah 0778  1]      Proximity Domain Low(8) : 04
[30Bh 0779  1]                      Apic ID : 41
[30Ch 0780  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[310h 0784  1]              Local Sapic EID : 00
[311h 0785  3]    Proximity Domain High(24) : 000000
[314h 0788  4]                     Reserved : 00000000

[318h 0792  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[319h 0793  1]                       Length : 10

[31Ah 0794  1]      Proximity Domain Low(8) : 04
[31Bh 0795  1]                      Apic ID : 42
[31Ch 0796  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[320h 0800  1]              Local Sapic EID : 00
[321h 0801  3]    Proximity Domain High(24) : 000000
[324h 0804  4]                     Reserved : 00000000

[328h 0808  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[329h 0809  1]                       Length : 10

[32Ah 0810  1]      Proximity Domain Low(8) : 04
[32Bh 0811  1]                      Apic ID : 43
[32Ch 0812  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[330h 0816  1]              Local Sapic EID : 00
[331h 0817  3]    Proximity Domain High(24) : 000000
[334h 0820  4]                     Reserved : 00000000

[338h 0824  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[339h 0825  1]                       Length : 10

[33Ah 0826  1]      Proximity Domain Low(8) : 04
[33Bh 0827  1]                      Apic ID : 44
[33Ch 0828  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[340h 0832  1]              Local Sapic EID : 00
[341h 0833  3]    Proximity Domain High(24) : 000000
[344h 0836  4]                     Reserved : 00000000

[348h 0840  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[349h 0841  1]                       Length : 10

[34Ah 0842  1]      Proximity Domain Low(8) : 04
[34Bh 0843  1]                      Apic ID : 45
[34Ch 0844  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[350h 0848  1]              Local Sapic EID : 00
[351h 0849  3]    Proximity Domain High(24) : 000000
[354h 0852  4]                     Reserved : 00000000

[358h 0856  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[359h 0857  1]                       Length : 10

[35Ah 0858  1]      Proximity Domain Low(8) : 04
[35Bh 0859  1]                      Apic ID : 46
[35Ch 0860  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[360h 0864  1]              Local Sapic EID : 00
[361h 0865  3]    Proximity Domain High(24) : 000000
[364h 0868  4]                     Reserved : 00000000

[368h 0872  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[369h 0873  1]                       Length : 10

[36Ah 0874  1]      Proximity Domain Low(8) : 04
[36Bh 0875  1]                      Apic ID : 47
[36Ch 0876  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[370h 0880  1]              Local Sapic EID : 00
[371h 0881  3]    Proximity Domain High(24) : 000000
[374h 0884  4]                     Reserved : 00000000

[378h 0888  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[379h 0889  1]                       Length : 10

[37Ah 0890  1]      Proximity Domain Low(8) : 05
[37Bh 0891  1]                      Apic ID : 48
[37Ch 0892  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[380h 0896  1]              Local Sapic EID : 00
[381h 0897  3]    Proximity Domain High(24) : 000000
[384h 0900  4]                     Reserved : 00000000

[388h 0904  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[389h 0905  1]                       Length : 10

[38Ah 0906  1]      Proximity Domain Low(8) : 05
[38Bh 0907  1]                      Apic ID : 49
[38Ch 0908  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[390h 0912  1]              Local Sapic EID : 00
[391h 0913  3]    Proximity Domain High(24) : 000000
[394h 0916  4]                     Reserved : 00000000

[398h 0920  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[399h 0921  1]                       Length : 10

[39Ah 0922  1]      Proximity Domain Low(8) : 05
[39Bh 0923  1]                      Apic ID : 4A
[39Ch 0924  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3A0h 0928  1]              Local Sapic EID : 00
[3A1h 0929  3]    Proximity Domain High(24) : 000000
[3A4h 0932  4]                     Reserved : 00000000

[3A8h 0936  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3A9h 0937  1]                       Length : 10

[3AAh 0938  1]      Proximity Domain Low(8) : 05
[3ABh 0939  1]                      Apic ID : 4B
[3ACh 0940  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3B0h 0944  1]              Local Sapic EID : 00
[3B1h 0945  3]    Proximity Domain High(24) : 000000
[3B4h 0948  4]                     Reserved : 00000000

[3B8h 0952  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3B9h 0953  1]                       Length : 10

[3BAh 0954  1]      Proximity Domain Low(8) : 05
[3BBh 0955  1]                      Apic ID : 4C
[3BCh 0956  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3C0h 0960  1]              Local Sapic EID : 00
[3C1h 0961  3]    Proximity Domain High(24) : 000000
[3C4h 0964  4]                     Reserved : 00000000

[3C8h 0968  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3C9h 0969  1]                       Length : 10

[3CAh 0970  1]      Proximity Domain Low(8) : 05
[3CBh 0971  1]                      Apic ID : 4D
[3CCh 0972  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3D0h 0976  1]              Local Sapic EID : 00
[3D1h 0977  3]    Proximity Domain High(24) : 000000
[3D4h 0980  4]                     Reserved : 00000000

[3D8h 0984  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3D9h 0985  1]                       Length : 10

[3DAh 0986  1]      Proximity Domain Low(8) : 05
[3DBh 0987  1]                      Apic ID : 4E
[3DCh 0988  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3E0h 0992  1]              Local Sapic EID : 00
[3E1h 0993  3]    Proximity Domain High(24) : 000000
[3E4h 0996  4]                     Reserved : 00000000

[3E8h 1000  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[3E9h 1001  1]                       Length : 10

[3EAh 1002  1]      Proximity Domain Low(8) : 05
[3EBh 1003  1]                      Apic ID : 4F
[3ECh 1004  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[3F0h 1008  1]              Local Sapic EID : 00
[3F1h 1009  3]    Proximity Domain High(24) : 000000
[3F4h 1012  4]                     Reserved : 00000000

[3F8h 1016  1]                Subtable Type : 01 <Memory Affinity>
[3F9h 1017  1]                       Length : 28

[3FAh 1018  4]             Proximity Domain : 00000006
[3FEh 1022  2]                     Reserved : 0000
[400h 1024  8]                 Base Address : 0000000640000000
[408h 1032  8]               Address Length : 00000001FF000000
[410h 1040  4]                     Reserved : 00000000
[414h 1044  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
                              Hot Pluggable : 0
                               Non-Volatile : 0
[418h 1048  8]                     Reserved : 0000000000000000

[420h 1056  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[421h 1057  1]                       Length : 10

[422h 1058  1]      Proximity Domain Low(8) : 06
[423h 1059  1]                      Apic ID : 60
[424h 1060  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[428h 1064  1]              Local Sapic EID : 00
[429h 1065  3]    Proximity Domain High(24) : 000000
[42Ch 1068  4]                     Reserved : 00000000

[430h 1072  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[431h 1073  1]                       Length : 10

[432h 1074  1]      Proximity Domain Low(8) : 06
[433h 1075  1]                      Apic ID : 61
[434h 1076  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[438h 1080  1]              Local Sapic EID : 00
[439h 1081  3]    Proximity Domain High(24) : 000000
[43Ch 1084  4]                     Reserved : 00000000

[440h 1088  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[441h 1089  1]                       Length : 10

[442h 1090  1]      Proximity Domain Low(8) : 06
[443h 1091  1]                      Apic ID : 62
[444h 1092  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[448h 1096  1]              Local Sapic EID : 00
[449h 1097  3]    Proximity Domain High(24) : 000000
[44Ch 1100  4]                     Reserved : 00000000

[450h 1104  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[451h 1105  1]                       Length : 10

[452h 1106  1]      Proximity Domain Low(8) : 06
[453h 1107  1]                      Apic ID : 63
[454h 1108  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[458h 1112  1]              Local Sapic EID : 00
[459h 1113  3]    Proximity Domain High(24) : 000000
[45Ch 1116  4]                     Reserved : 00000000

[460h 1120  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[461h 1121  1]                       Length : 10

[462h 1122  1]      Proximity Domain Low(8) : 06
[463h 1123  1]                      Apic ID : 64
[464h 1124  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[468h 1128  1]              Local Sapic EID : 00
[469h 1129  3]    Proximity Domain High(24) : 000000
[46Ch 1132  4]                     Reserved : 00000000

[470h 1136  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[471h 1137  1]                       Length : 10

[472h 1138  1]      Proximity Domain Low(8) : 06
[473h 1139  1]                      Apic ID : 65
[474h 1140  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[478h 1144  1]              Local Sapic EID : 00
[479h 1145  3]    Proximity Domain High(24) : 000000
[47Ch 1148  4]                     Reserved : 00000000

[480h 1152  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[481h 1153  1]                       Length : 10

[482h 1154  1]      Proximity Domain Low(8) : 06
[483h 1155  1]                      Apic ID : 66
[484h 1156  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[488h 1160  1]              Local Sapic EID : 00
[489h 1161  3]    Proximity Domain High(24) : 000000
[48Ch 1164  4]                     Reserved : 00000000

[490h 1168  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[491h 1169  1]                       Length : 10

[492h 1170  1]      Proximity Domain Low(8) : 06
[493h 1171  1]                      Apic ID : 67
[494h 1172  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[498h 1176  1]              Local Sapic EID : 00
[499h 1177  3]    Proximity Domain High(24) : 000000
[49Ch 1180  4]                     Reserved : 00000000

[4A0h 1184  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4A1h 1185  1]                       Length : 10

[4A2h 1186  1]      Proximity Domain Low(8) : 07
[4A3h 1187  1]                      Apic ID : 68
[4A4h 1188  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4A8h 1192  1]              Local Sapic EID : 00
[4A9h 1193  3]    Proximity Domain High(24) : 000000
[4ACh 1196  4]                     Reserved : 00000000

[4B0h 1200  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4B1h 1201  1]                       Length : 10

[4B2h 1202  1]      Proximity Domain Low(8) : 07
[4B3h 1203  1]                      Apic ID : 69
[4B4h 1204  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4B8h 1208  1]              Local Sapic EID : 00
[4B9h 1209  3]    Proximity Domain High(24) : 000000
[4BCh 1212  4]                     Reserved : 00000000

[4C0h 1216  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4C1h 1217  1]                       Length : 10

[4C2h 1218  1]      Proximity Domain Low(8) : 07
[4C3h 1219  1]                      Apic ID : 6A
[4C4h 1220  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4C8h 1224  1]              Local Sapic EID : 00
[4C9h 1225  3]    Proximity Domain High(24) : 000000
[4CCh 1228  4]                     Reserved : 00000000

[4D0h 1232  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4D1h 1233  1]                       Length : 10

[4D2h 1234  1]      Proximity Domain Low(8) : 07
[4D3h 1235  1]                      Apic ID : 6B
[4D4h 1236  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4D8h 1240  1]              Local Sapic EID : 00
[4D9h 1241  3]    Proximity Domain High(24) : 000000
[4DCh 1244  4]                     Reserved : 00000000

[4E0h 1248  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4E1h 1249  1]                       Length : 10

[4E2h 1250  1]      Proximity Domain Low(8) : 07
[4E3h 1251  1]                      Apic ID : 6C
[4E4h 1252  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4E8h 1256  1]              Local Sapic EID : 00
[4E9h 1257  3]    Proximity Domain High(24) : 000000
[4ECh 1260  4]                     Reserved : 00000000

[4F0h 1264  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[4F1h 1265  1]                       Length : 10

[4F2h 1266  1]      Proximity Domain Low(8) : 07
[4F3h 1267  1]                      Apic ID : 6D
[4F4h 1268  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[4F8h 1272  1]              Local Sapic EID : 00
[4F9h 1273  3]    Proximity Domain High(24) : 000000
[4FCh 1276  4]                     Reserved : 00000000

[500h 1280  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[501h 1281  1]                       Length : 10

[502h 1282  1]      Proximity Domain Low(8) : 07
[503h 1283  1]                      Apic ID : 6E
[504h 1284  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[508h 1288  1]              Local Sapic EID : 00
[509h 1289  3]    Proximity Domain High(24) : 000000
[50Ch 1292  4]                     Reserved : 00000000

[510h 1296  1]                Subtable Type : 00 <Processor Local APIC/SAPIC Affinity>
[511h 1297  1]                       Length : 10

[512h 1298  1]      Proximity Domain Low(8) : 07
[513h 1299  1]                      Apic ID : 6F
[514h 1300  4]        Flags (decoded below) : 00000001
                                    Enabled : 1
[518h 1304  1]              Local Sapic EID : 00
[519h 1305  3]    Proximity Domain High(24) : 000000
[51Ch 1308  4]                     Reserved : 00000000

Raw Table Data

  0000: 53 52 41 54 20 05 00 00 02 D4 41 4D 44 20 20 20  SRAT .....AMD   
  0010: 41 47 45 53 41 20 20 20 01 00 00 00 41 4D 44 20  AGESA   ....AMD 
  0020: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0030: 01 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .(..............
  0040: 00 00 0A 00 00 00 00 00 00 00 00 00 01 00 00 00  ................
  0050: 00 00 00 00 00 00 00 00 01 28 00 00 00 00 00 00  .........(......
  0060: 00 00 10 00 00 00 00 00 00 00 F0 BF 00 00 00 00  ................
  0070: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0080: 01 28 00 00 00 00 00 00 00 00 00 00 01 00 00 00  .(..............
  0090: 00 00 00 40 01 00 00 00 00 00 00 00 01 00 00 00  ...@............
  00A0: 00 00 00 00 00 00 00 00 00 10 00 00 01 00 00 00  ................
  00B0: 00 00 00 00 00 00 00 00 00 10 00 01 01 00 00 00  ................
  00C0: 00 00 00 00 00 00 00 00 00 10 00 02 01 00 00 00  ................
  00D0: 00 00 00 00 00 00 00 00 00 10 00 03 01 00 00 00  ................
  00E0: 00 00 00 00 00 00 00 00 00 10 00 04 01 00 00 00  ................
  00F0: 00 00 00 00 00 00 00 00 00 10 00 05 01 00 00 00  ................
  0100: 00 00 00 00 00 00 00 00 00 10 00 06 01 00 00 00  ................
  0110: 00 00 00 00 00 00 00 00 00 10 00 07 01 00 00 00  ................
  0120: 00 00 00 00 00 00 00 00 00 10 01 08 01 00 00 00  ................
  0130: 00 00 00 00 00 00 00 00 00 10 01 09 01 00 00 00  ................
  0140: 00 00 00 00 00 00 00 00 00 10 01 0A 01 00 00 00  ................
  0150: 00 00 00 00 00 00 00 00 00 10 01 0B 01 00 00 00  ................
  0160: 00 00 00 00 00 00 00 00 00 10 01 0C 01 00 00 00  ................
  0170: 00 00 00 00 00 00 00 00 00 10 01 0D 01 00 00 00  ................
  0180: 00 00 00 00 00 00 00 00 00 10 01 0E 01 00 00 00  ................
  0190: 00 00 00 00 00 00 00 00 00 10 01 0F 01 00 00 00  ................
  01A0: 00 00 00 00 00 00 00 00 01 28 02 00 00 00 00 00  .........(......
  01B0: 00 00 00 40 02 00 00 00 00 00 00 00 02 00 00 00  ...@............
  01C0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  01D0: 00 10 02 20 01 00 00 00 00 00 00 00 00 00 00 00  ... ............
  01E0: 00 10 02 21 01 00 00 00 00 00 00 00 00 00 00 00  ...!............
  01F0: 00 10 02 22 01 00 00 00 00 00 00 00 00 00 00 00  ..."............
  0200: 00 10 02 23 01 00 00 00 00 00 00 00 00 00 00 00  ...#............
  0210: 00 10 02 24 01 00 00 00 00 00 00 00 00 00 00 00  ...$............
  0220: 00 10 02 25 01 00 00 00 00 00 00 00 00 00 00 00  ...%............
  0230: 00 10 02 26 01 00 00 00 00 00 00 00 00 00 00 00  ...&............
  0240: 00 10 02 27 01 00 00 00 00 00 00 00 00 00 00 00  ...'............
  0250: 00 10 03 28 01 00 00 00 00 00 00 00 00 00 00 00  ...(............
  0260: 00 10 03 29 01 00 00 00 00 00 00 00 00 00 00 00  ...)............
  0270: 00 10 03 2A 01 00 00 00 00 00 00 00 00 00 00 00  ...*............
  0280: 00 10 03 2B 01 00 00 00 00 00 00 00 00 00 00 00  ...+............
  0290: 00 10 03 2C 01 00 00 00 00 00 00 00 00 00 00 00  ...,............
  02A0: 00 10 03 2D 01 00 00 00 00 00 00 00 00 00 00 00  ...-............
  02B0: 00 10 03 2E 01 00 00 00 00 00 00 00 00 00 00 00  ................
  02C0: 00 10 03 2F 01 00 00 00 00 00 00 00 00 00 00 00  .../............
  02D0: 01 28 04 00 00 00 00 00 00 00 00 40 04 00 00 00  .(.........@....
  02E0: 00 00 00 00 02 00 00 00 00 00 00 00 01 00 00 00  ................
  02F0: 00 00 00 00 00 00 00 00 00 10 04 40 01 00 00 00  ...........@....
  0300: 00 00 00 00 00 00 00 00 00 10 04 41 01 00 00 00  ...........A....
  0310: 00 00 00 00 00 00 00 00 00 10 04 42 01 00 00 00  ...........B....
  0320: 00 00 00 00 00 00 00 00 00 10 04 43 01 00 00 00  ...........C....
  0330: 00 00 00 00 00 00 00 00 00 10 04 44 01 00 00 00  ...........D....
  0340: 00 00 00 00 00 00 00 00 00 10 04 45 01 00 00 00  ...........E....
  0350: 00 00 00 00 00 00 00 00 00 10 04 46 01 00 00 00  ...........F....
  0360: 00 00 00 00 00 00 00 00 00 10 04 47 01 00 00 00  ...........G....
  0370: 00 00 00 00 00 00 00 00 00 10 05 48 01 00 00 00  ...........H....
  0380: 00 00 00 00 00 00 00 00 00 10 05 49 01 00 00 00  ...........I....
  0390: 00 00 00 00 00 00 00 00 00 10 05 4A 01 00 00 00  ...........J....
  03A0: 00 00 00 00 00 00 00 00 00 10 05 4B 01 00 00 00  ...........K....
  03B0: 00 00 00 00 00 00 00 00 00 10 05 4C 01 00 00 00  ...........L....
  03C0: 00 00 00 00 00 00 00 00 00 10 05 4D 01 00 00 00  ...........M....
  03D0: 00 00 00 00 00 00 00 00 00 10 05 4E 01 00 00 00  ...........N....
  03E0: 00 00 00 00 00 00 00 00 00 10 05 4F 01 00 00 00  ...........O....
  03F0: 00 00 00 00 00 00 00 00 01 28 06 00 00 00 00 00  .........(......
  0400: 00 00 00 40 06 00 00 00 00 00 00 FF 01 00 00 00  ...@............
  0410: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0420: 00 10 06 60 01 00 00 00 00 00 00 00 00 00 00 00  ...`............
  0430: 00 10 06 61 01 00 00 00 00 00 00 00 00 00 00 00  ...a............
  0440: 00 10 06 62 01 00 00 00 00 00 00 00 00 00 00 00  ...b............
  0450: 00 10 06 63 01 00 00 00 00 00 00 00 00 00 00 00  ...c............
  0460: 00 10 06 64 01 00 00 00 00 00 00 00 00 00 00 00  ...d............
  0470: 00 10 06 65 01 00 00 00 00 00 00 00 00 00 00 00  ...e............
  0480: 00 10 06 66 01 00 00 00 00 00 00 00 00 00 00 00  ...f............
  0490: 00 10 06 67 01 00 00 00 00 00 00 00 00 00 00 00  ...g............
  04A0: 00 10 07 68 01 00 00 00 00 00 00 00 00 00 00 00  ...h............
  04B0: 00 10 07 69 01 00 00 00 00 00 00 00 00 00 00 00  ...i............
  04C0: 00 10 07 6A 01 00 00 00 00 00 00 00 00 00 00 00  ...j............
  04D0: 00 10 07 6B 01 00 00 00 00 00 00 00 00 00 00 00  ...k............
  04E0: 00 10 07 6C 01 00 00 00 00 00 00 00 00 00 00 00  ...l............
  04F0: 00 10 07 6D 01 00 00 00 00 00 00 00 00 00 00 00  ...m............
  0500: 00 10 07 6E 01 00 00 00 00 00 00 00 00 00 00 00  ...n............
  0510: 00 10 07 6F 01 00 00 00 00 00 00 00 00 00 00 00  ...o............

--------------030608030106010209090508
Content-Type: text/x-log; name="interlagos-xl-info-n.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="interlagos-xl-info-n.log"

host                   : bos-r815-1
release                : 2.6.32.43-0.4.1.xs1.5.50.696.170738xen
version                : #1 SMP Mon Jun 18 09:27:43 EDT 2012
machine                : i686
nr_cpus                : 64
max_cpu_id             : 63
nr_nodes               : 4
cores_per_socket       : 8
threads_per_core       : 2
cpu_mhz                : 2600
hw_caps                : 178bf3ff:2fd3fbff:00000000:00001710:12982203:00000000:01c9bfff:00000000
virt_caps              : hvm hvm_directio
total_memory           : 32742
free_memory            : 31502
free_cpus              : 0
cpu_topology           :
cpu:    core    socket     node
  0:       0        0        0
  1:       1        0        0
  2:       2        0        0
  3:       3        0        0
  4:       4        0        0
  5:       5        0        0
  6:       6        0        0
  7:       7        0        0
  8:       8        0        0
  9:       9        0        0
 10:      10        0        0
 11:      11        0        0
 12:      12        0        0
 13:      13        0        0
 14:      14        0        0
 15:      15        0        0
 16:       0        1        2
 17:       1        1        2
 18:       2        1        2
 19:       3        1        2
 20:       4        1        2
 21:       5        1        2
 22:       6        1        2
 23:       7        1        2
 24:       8        1        0
 25:       9        1        0
 26:      10        1        0
 27:      11        1        0
 28:      12        1        0
 29:      13        1        0
 30:      14        1        0
 31:      15        1        0
 32:       0        2        4
 33:       1        2        4
 34:       2        2        4
 35:       3        2        4
 36:       4        2        4
 37:       5        2        4
 38:       6        2        4
 39:       7        2        4
 40:       8        2        0
 41:       9        2        0
 42:      10        2        0
 43:      11        2        0
 44:      12        2        0
 45:      13        2        0
 46:      14        2        0
 47:      15        2        0
 48:       0        3        6
 49:       1        3        6
 50:       2        3        6
 51:       3        3        6
 52:       4        3        6
 53:       5        3        6
 54:       6        3        6
 55:       7        3        6
 56:       8        3        0
 57:       9        3        0
 58:      10        3        0
 59:      11        3        0
 60:      12        3        0
 61:      13        3        0
 62:      14        3        0
 63:      15        3        0
numa_info              : none
xen_major              : 4
xen_minor              : 1
xen_extra              : .2
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=0xfdc00000
xen_changeset          : Wed Jun 27 19:34:58 2012 +0100 23517:b004f4ef0cff
xen_commandline        : com1=115200,8n1 console=com1,vga loglvl=all cpuinfo mem=1024G dom0_mem=752M,max:752M watchdog_timeout=300 cpuid_mask_xsave_eax=0 lowmem_emergency_pool=1M crashkernel=64M@32M dom0_max_vcpus=4
cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
cc_compile_by          : andrewcoop
cc_compile_domain      : uk.xensource.com
cc_compile_date        : Wed Jun 27 14:34:59 EDT 2012
xend_config_format     : 4

--------------030608030106010209090508
Content-Type: text/x-patch; name="RFC-fix-numa-online.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="RFC-fix-numa-online.patch"

# HG changeset patch
# Parent c6c9d20963d7c5d8022a8cbe6bdaea359804f284
diff -r c6c9d20963d7 -r a0a7f546f22e xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -195,8 +195,10 @@ void __devinit srat_detect_node(int cpu)
     u32 apicid = x86_cpu_to_apicid[cpu];
 
     node = apicid_to_node[apicid];
-    if ( node == NUMA_NO_NODE || !node_online(node) )
+    if ( node == NUMA_NO_NODE )
         node = 0;
+
+    node_set_online(node);
     numa_set_node(cpu, node);
 
     if ( opt_cpu_info && acpi_numa > 0 )

--------------030608030106010209090508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030608030106010209090508--


From xen-devel-bounces@lists.xen.org Wed Jun 27 19:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 19: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 1Sjxwo-0000D6-Cf; Wed, 27 Jun 2012 19:30:42 +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 1Sjxwm-0000D1-9F
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 19:30:40 +0000
Received: from [85.158.143.35:48068] by server-3.bemta-4.messagelabs.com id
	A2/21-05808-F5F5BEF4; Wed, 27 Jun 2012 19:30:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340825437!14377348!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6874 invoked from network); 27 Jun 2012 19:30:37 -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;
	27 Jun 2012 19:30:37 -0000
Received: from 225-68-ftth.onsneteindhoven.nl ([88.159.68.225]:56571
	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 1Sjxso-0006zQ-38; Wed, 27 Jun 2012 21:26:34 +0200
Date: Wed, 27 Jun 2012 21:30:31 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <86102031.20120627213031@eikelenboom.it>
To: Thomas Goirand <thomas@goirand.fr>
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Thomas,

Wednesday, June 27, 2012, 8:07:25 PM, you wrote:

> Hi Ian,

> Thanks for discussing this in a public way!

> On 06/20/2012 02:16 AM, Ian Jackson wrote:
>> We had one request from a public Xen cloud provider to be provided
>> with predisclosure information.  However it appeared to us that they
>> didn't meet the size threshold in the process document.
>>
>> The size threshold is of course open to discussion.
>>   
> I find the concept of "Xen Cloud provider size threshold"
> quite anti competitive. Why would a bigger provider, would
> be offered a substantial advantage over the smaller one?

> On 06/20/2012 02:16 AM, Ian Jackson wrote:
>> One particular issue here which also relates to the predisclosure
>> membership criteria, is whether large indirect consumers of Xen should
>> be on the predisclosure list in their own right.  That would allow
>> them to deploy the fix before the embargo date.  It would also allow
>> them to prepare for testing and deployment, before the fix is
>> available from their vendor (who would in this scenario also be
>> entitled to be a predisclosure list member).
>>   

> And other hosting providers not in the list? They can be hacked and die,
> while the big ones are safe?

> Why wouldn't a smaller company know? Can *I* be in the predisclosure list?
> If you reject me from such list, why? What's the procedure to be on such
> list?

I think it's all a trade-off between:
A) Informing as much stakeholders as possible about the threat
B) Not informing anyone with malicious intentions

And the assumptions that have been made are:
C) Employees of large companies have a small chance of having malicious intentions
D) The risk of informing someone with a malicious intention rises when more people are included on the list

Well while D would probably be true .. C) is indeed more questionable

It's also the question if larger companies don't break the embargo by informing their customers who aren't on the list, with as end result a rumor spreading in public.

On the other hand i see no ways to circumvent any of these, except by fixing the threat ASAP and keeping the embargo time as short as possible.


> On 06/20/2012 05:45 PM, George Dunlap wrote:
>> The only way this would work is if the predisclosure list consisted
>> exclusively of software providers, and specifically excluded service
>> providers.
> I agree, though you might have corner cases.

> What if you are *both* software and service provider (eg: I'm working on
> Debian and XCP, and my small company provides a hosted Xen service)?

> Cheers,

> Thomas






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 19:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 19: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 1Sjxwo-0000D6-Cf; Wed, 27 Jun 2012 19:30:42 +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 1Sjxwm-0000D1-9F
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 19:30:40 +0000
Received: from [85.158.143.35:48068] by server-3.bemta-4.messagelabs.com id
	A2/21-05808-F5F5BEF4; Wed, 27 Jun 2012 19:30:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340825437!14377348!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6874 invoked from network); 27 Jun 2012 19:30:37 -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;
	27 Jun 2012 19:30:37 -0000
Received: from 225-68-ftth.onsneteindhoven.nl ([88.159.68.225]:56571
	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 1Sjxso-0006zQ-38; Wed, 27 Jun 2012 21:26:34 +0200
Date: Wed, 27 Jun 2012 21:30:31 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <86102031.20120627213031@eikelenboom.it>
To: Thomas Goirand <thomas@goirand.fr>
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Thomas,

Wednesday, June 27, 2012, 8:07:25 PM, you wrote:

> Hi Ian,

> Thanks for discussing this in a public way!

> On 06/20/2012 02:16 AM, Ian Jackson wrote:
>> We had one request from a public Xen cloud provider to be provided
>> with predisclosure information.  However it appeared to us that they
>> didn't meet the size threshold in the process document.
>>
>> The size threshold is of course open to discussion.
>>   
> I find the concept of "Xen Cloud provider size threshold"
> quite anti competitive. Why would a bigger provider, would
> be offered a substantial advantage over the smaller one?

> On 06/20/2012 02:16 AM, Ian Jackson wrote:
>> One particular issue here which also relates to the predisclosure
>> membership criteria, is whether large indirect consumers of Xen should
>> be on the predisclosure list in their own right.  That would allow
>> them to deploy the fix before the embargo date.  It would also allow
>> them to prepare for testing and deployment, before the fix is
>> available from their vendor (who would in this scenario also be
>> entitled to be a predisclosure list member).
>>   

> And other hosting providers not in the list? They can be hacked and die,
> while the big ones are safe?

> Why wouldn't a smaller company know? Can *I* be in the predisclosure list?
> If you reject me from such list, why? What's the procedure to be on such
> list?

I think it's all a trade-off between:
A) Informing as much stakeholders as possible about the threat
B) Not informing anyone with malicious intentions

And the assumptions that have been made are:
C) Employees of large companies have a small chance of having malicious intentions
D) The risk of informing someone with a malicious intention rises when more people are included on the list

Well while D would probably be true .. C) is indeed more questionable

It's also the question if larger companies don't break the embargo by informing their customers who aren't on the list, with as end result a rumor spreading in public.

On the other hand i see no ways to circumvent any of these, except by fixing the threat ASAP and keeping the embargo time as short as possible.


> On 06/20/2012 05:45 PM, George Dunlap wrote:
>> The only way this would work is if the predisclosure list consisted
>> exclusively of software providers, and specifically excluded service
>> providers.
> I agree, though you might have corner cases.

> What if you are *both* software and service provider (eg: I'm working on
> Debian and XCP, and my small company provides a hosted Xen service)?

> Cheers,

> Thomas






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 20:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1SjyvU-0000fa-5P; Wed, 27 Jun 2012 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 <Ian.Jackson@eu.citrix.com>) id 1SjyvS-0000fO-5D
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 20:33:22 +0000
Received: from [85.158.143.35:53787] by server-3.bemta-4.messagelabs.com id
	4E/76-05808-11E6BEF4; Wed, 27 Jun 2012 20:33:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340829200!6573380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18092 invoked from network); 27 Jun 2012 20:33:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 20:33:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,487,1336348800"; d="scan'208";a="13255625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 20:33:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 21:33:20 +0100
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 1SjyvQ-0002ap-Av;
	Wed, 27 Jun 2012 20:33:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjyvP-0000Qi-Nz;
	Wed, 27 Jun 2012 21:33:19 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13375-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 21:33:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13375: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13375 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13375/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 20:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 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 1SjyvU-0000fa-5P; Wed, 27 Jun 2012 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 <Ian.Jackson@eu.citrix.com>) id 1SjyvS-0000fO-5D
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 20:33:22 +0000
Received: from [85.158.143.35:53787] by server-3.bemta-4.messagelabs.com id
	4E/76-05808-11E6BEF4; Wed, 27 Jun 2012 20:33:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340829200!6573380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxNzY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18092 invoked from network); 27 Jun 2012 20:33:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 20:33:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,487,1336348800"; d="scan'208";a="13255625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jun 2012 20:33:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 27 Jun 2012 21:33:20 +0100
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 1SjyvQ-0002ap-Av;
	Wed, 27 Jun 2012 20:33:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SjyvP-0000Qi-Nz;
	Wed, 27 Jun 2012 21:33:19 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13375-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Jun 2012 21:33:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13375: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13375 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13375/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 21:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 21:19: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 1Sjze2-0001Uh-NQ; Wed, 27 Jun 2012 21:19:26 +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 1Sjze0-0001Uc-IR
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 21:19:24 +0000
Received: from [193.109.254.147:3377] by server-3.bemta-14.messagelabs.com id
	DE/F5-08687-BD87BEF4; Wed, 27 Jun 2012 21:19:23 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340831963!8965211!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 27 Jun 2012 21:19:23 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 21:19:23 -0000
Received: by eaaa12 with SMTP id a12so765987eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 14:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=glCMUYUf0kQLCVWllbMhSmk1PNDS5+fN17rxhisuWrs=;
	b=N7Z551Z+XN34gXvqqIkbKhMpbWYFd9NvvIgR2/6RWVWBTgk2h/4OY+iI6tw0QhzKob
	12lpmCNkGUnbugBfeiZj5g8jIZF6EdcVYBllLnu3/TmiWOByKnRO8hBZVD6GHYjSq0DU
	X34HeDZ4gk6GEVCE/g54VAmmCirkE1iWeUey8qO2YPqj2LmQ+Wo6YOYgPb7SSsR16/Fj
	PhQ0kceffvcRn0Cx3IShWpCvaY3BoRjAkb1XPYW+2T9FDk8AZXhWoAWmPm1LvGCmqkRT
	mo9nlGFcrnxUsLmvcAaP32oDFK6WIWCZT/rwsMVZZvPOicYnKbQMPRTI8NnG614wg4ur
	EWWg==
MIME-Version: 1.0
Received: by 10.14.119.73 with SMTP id m49mr4350527eeh.187.1340831962915; Wed,
	27 Jun 2012 14:19:22 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Wed, 27 Jun 2012 14:19:22 -0700 (PDT)
In-Reply-To: <20120619173410.GW2058@reaktio.net>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<20120619164107.GA24413@phenom.dumpdata.com>
	<CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
	<20120619173410.GW2058@reaktio.net>
Date: Wed, 27 Jun 2012 17:19:22 -0400
Message-ID: <CAGj-7pVdTYD0jAn2NAWJV5Wqw_mCi0XvKhYK_iPh6Wq3eAKRow@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> And while you're at it try new Xen aswell :)
> So Xen 4.1.2+ and Linux 3.4.2+.
>
I tried the same scenario with Xen 4.1.2 and Linux 3.4.3 and it
worked. The only different thing I did was to create the bridges in
dom0 and netback-domU manually instead of using Xen script
'network-bridge'.

Shakeel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 21:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 21:19: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 1Sjze2-0001Uh-NQ; Wed, 27 Jun 2012 21:19:26 +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 1Sjze0-0001Uc-IR
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 21:19:24 +0000
Received: from [193.109.254.147:3377] by server-3.bemta-14.messagelabs.com id
	DE/F5-08687-BD87BEF4; Wed, 27 Jun 2012 21:19:23 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340831963!8965211!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 27 Jun 2012 21:19:23 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 21:19:23 -0000
Received: by eaaa12 with SMTP id a12so765987eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 14:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=glCMUYUf0kQLCVWllbMhSmk1PNDS5+fN17rxhisuWrs=;
	b=N7Z551Z+XN34gXvqqIkbKhMpbWYFd9NvvIgR2/6RWVWBTgk2h/4OY+iI6tw0QhzKob
	12lpmCNkGUnbugBfeiZj5g8jIZF6EdcVYBllLnu3/TmiWOByKnRO8hBZVD6GHYjSq0DU
	X34HeDZ4gk6GEVCE/g54VAmmCirkE1iWeUey8qO2YPqj2LmQ+Wo6YOYgPb7SSsR16/Fj
	PhQ0kceffvcRn0Cx3IShWpCvaY3BoRjAkb1XPYW+2T9FDk8AZXhWoAWmPm1LvGCmqkRT
	mo9nlGFcrnxUsLmvcAaP32oDFK6WIWCZT/rwsMVZZvPOicYnKbQMPRTI8NnG614wg4ur
	EWWg==
MIME-Version: 1.0
Received: by 10.14.119.73 with SMTP id m49mr4350527eeh.187.1340831962915; Wed,
	27 Jun 2012 14:19:22 -0700 (PDT)
Received: by 10.14.29.13 with HTTP; Wed, 27 Jun 2012 14:19:22 -0700 (PDT)
In-Reply-To: <20120619173410.GW2058@reaktio.net>
References: <CAGj-7pXQuEhfZcWmpmUkp7VdnqbbP3qZh0ZqS_TMVg8FrXd0Rw@mail.gmail.com>
	<CAGj-7pVpoePA=RDMNL3c4hpGhOdFMZDW83piVCMYO--pELFqmg@mail.gmail.com>
	<20120619164107.GA24413@phenom.dumpdata.com>
	<CAGj-7pXrkdJtQsxw-mL2E=S59qDgSC5-e9G4CNAvGfz3jVrxGw@mail.gmail.com>
	<20120619173410.GW2058@reaktio.net>
Date: Wed, 27 Jun 2012 17:19:22 -0400
Message-ID: <CAGj-7pVdTYD0jAn2NAWJV5Wqw_mCi0XvKhYK_iPh6Wq3eAKRow@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Fwd: netback (Network backend) in domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> And while you're at it try new Xen aswell :)
> So Xen 4.1.2+ and Linux 3.4.2+.
>
I tried the same scenario with Xen 4.1.2 and Linux 3.4.3 and it
worked. The only different thing I did was to create the bridges in
dom0 and netback-domU manually instead of using Xen script
'network-bridge'.

Shakeel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 22:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 22: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 1Sk0hl-00028L-Kz; Wed, 27 Jun 2012 22:27:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ran_h@rad.com>) id 1Sk0hj-00028G-F7
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 22:27:19 +0000
Received: from [85.158.138.51:30514] by server-3.bemta-3.messagelabs.com id
	6F/92-26490-6C88BEF4; Wed, 27 Jun 2012 22:27:18 +0000
X-Env-Sender: ran_h@rad.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340836036!11202970!1
X-Originating-IP: [96.56.27.202]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_IMAGE_ONLY_28,
	HTML_MESSAGE,UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29364 invoked from network); 27 Jun 2012 22:27:17 -0000
Received: from ool-60381bca.static.optonline.net (HELO radusa.com)
	(96.56.27.202)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 22:27:17 -0000
Received: from Internal Mail-Server by mailgateway (envelope-from
	ran?h@rad.com)
	with AES128-SHA encrypted SMTP; 27 Jun 2012 18:27:15 -0400
Received: from EXUS4.ad.rad.co.il ([fe80::5030:5af6:3913:4ec8]) by
	exus4.ad.rad.co.il ([fe80::5030:5af6:3913:4ec8%13]) with mapi id
	14.02.0298.004; Wed, 27 Jun 2012 18:27:15 -0400
From: RAN HYSLER <ran_h@rad.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: VM Capacity on Intel's X.86
Thread-Index: Ac1UtAD5d5Ybwe4GT9Kt8yG4z0e9mA==
Date: Wed, 27 Jun 2012 22:27:15 +0000
Message-ID: <36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1@exus4.ad.rad.co.il>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.103.150]
MIME-Version: 1.0
Subject: [Xen-devel] VM Capacity on Intel's X.86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3759249686560131002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3759249686560131002==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_"

--_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

I want to use Xen's hypervisor infrastructure on a X.86 Gladden dual core 1=
.5Ghz (it has a  1GE full duplex processing capacity).

I was wondering if anyone knows :


1)      How many concurrent Linux-based VMs will the hypervisor be able to =
support ?

2)      Is there a PPS limitation ? If so, what is the max value ? (per VM =
and total)

3)      Is there a memory limitation ? If so, what is the max value ? (per =
VM and total)

Any help will be much appreciated.

Thanks,

Ron.


[http://prm.radusa.com/images/5y.jpg]

<http://www.radusa.com/12/Warranty/23442/>[http://prm.radusa.com/images/RAD=
242.jpg]<http://www.radusa.com/12/RAD-Industry-Awards/23316/>

--_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_
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"=
>
<style>
<!--
@font-face
	{font-family:"Cambria Math"}
@font-face
	{font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif"}
span.EmailStyle17
	{font-family:"Calibri","sans-serif";
	color:windowtext}
.MsoChpDefault
	{}
@page WordSection1
	{margin:1.0in 1.0in 1.0in 1.0in}
div.WordSection1
	{}
ol
	{margin-bottom:0in}
ul
	{margin-bottom:0in}
-->
</style>
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi All,</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">I want to use Xen&#8217;s hypervisor infrastructure =
on a X.86 <span style=3D"color:black">
Gladden </span>dual core 1.5Ghz (it has a &nbsp;1GE full duplex processing =
capacity).</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">I was wondering if anyone knows :</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D""=
>1)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span><span dir=3D"LTR"></span>How many concurrent Linux-based VMs =
will the hypervisor be able to support ?
</p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D""=
>2)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span><span dir=3D"LTR"></span>Is there a PPS limitation ? If so, w=
hat is the max value ? (per VM and total)</p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D""=
>3)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span><span dir=3D"LTR"></span>Is there a memory limitation ? If so=
, what is the max value ? (per VM and total)</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">Any help will be much appreciated.</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">Thanks,</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">Ron.</p>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<br>
<a href=3D"http://www.radusa.com/12/Warranty/23442/"><img src=3D"http://prm=
.radusa.com/images/5y.jpg"><br>
<br>
</a><a href=3D"http://www.radusa.com/12/RAD-Industry-Awards/23316/"><img sr=
c=3D"http://prm.radusa.com/images/RAD242.jpg"></a>
</body>
</html>

--_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_--


--===============3759249686560131002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3759249686560131002==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 22:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 22: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 1Sk0hl-00028L-Kz; Wed, 27 Jun 2012 22:27:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ran_h@rad.com>) id 1Sk0hj-00028G-F7
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 22:27:19 +0000
Received: from [85.158.138.51:30514] by server-3.bemta-3.messagelabs.com id
	6F/92-26490-6C88BEF4; Wed, 27 Jun 2012 22:27:18 +0000
X-Env-Sender: ran_h@rad.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340836036!11202970!1
X-Originating-IP: [96.56.27.202]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_IMAGE_ONLY_28,
	HTML_MESSAGE,UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29364 invoked from network); 27 Jun 2012 22:27:17 -0000
Received: from ool-60381bca.static.optonline.net (HELO radusa.com)
	(96.56.27.202)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jun 2012 22:27:17 -0000
Received: from Internal Mail-Server by mailgateway (envelope-from
	ran?h@rad.com)
	with AES128-SHA encrypted SMTP; 27 Jun 2012 18:27:15 -0400
Received: from EXUS4.ad.rad.co.il ([fe80::5030:5af6:3913:4ec8]) by
	exus4.ad.rad.co.il ([fe80::5030:5af6:3913:4ec8%13]) with mapi id
	14.02.0298.004; Wed, 27 Jun 2012 18:27:15 -0400
From: RAN HYSLER <ran_h@rad.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: VM Capacity on Intel's X.86
Thread-Index: Ac1UtAD5d5Ybwe4GT9Kt8yG4z0e9mA==
Date: Wed, 27 Jun 2012 22:27:15 +0000
Message-ID: <36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1@exus4.ad.rad.co.il>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.103.150]
MIME-Version: 1.0
Subject: [Xen-devel] VM Capacity on Intel's X.86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3759249686560131002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3759249686560131002==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_"

--_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

I want to use Xen's hypervisor infrastructure on a X.86 Gladden dual core 1=
.5Ghz (it has a  1GE full duplex processing capacity).

I was wondering if anyone knows :


1)      How many concurrent Linux-based VMs will the hypervisor be able to =
support ?

2)      Is there a PPS limitation ? If so, what is the max value ? (per VM =
and total)

3)      Is there a memory limitation ? If so, what is the max value ? (per =
VM and total)

Any help will be much appreciated.

Thanks,

Ron.


[http://prm.radusa.com/images/5y.jpg]

<http://www.radusa.com/12/Warranty/23442/>[http://prm.radusa.com/images/RAD=
242.jpg]<http://www.radusa.com/12/RAD-Industry-Awards/23316/>

--_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_
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"=
>
<style>
<!--
@font-face
	{font-family:"Cambria Math"}
@font-face
	{font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif"}
span.EmailStyle17
	{font-family:"Calibri","sans-serif";
	color:windowtext}
.MsoChpDefault
	{}
@page WordSection1
	{margin:1.0in 1.0in 1.0in 1.0in}
div.WordSection1
	{}
ol
	{margin-bottom:0in}
ul
	{margin-bottom:0in}
-->
</style>
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi All,</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">I want to use Xen&#8217;s hypervisor infrastructure =
on a X.86 <span style=3D"color:black">
Gladden </span>dual core 1.5Ghz (it has a &nbsp;1GE full duplex processing =
capacity).</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">I was wondering if anyone knows :</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D""=
>1)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span><span dir=3D"LTR"></span>How many concurrent Linux-based VMs =
will the hypervisor be able to support ?
</p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D""=
>2)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span><span dir=3D"LTR"></span>Is there a PPS limitation ? If so, w=
hat is the max value ? (per VM and total)</p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D""=
>3)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span><span dir=3D"LTR"></span>Is there a memory limitation ? If so=
, what is the max value ? (per VM and total)</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">Any help will be much appreciated.</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">Thanks,</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">Ron.</p>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<br>
<a href=3D"http://www.radusa.com/12/Warranty/23442/"><img src=3D"http://prm=
.radusa.com/images/5y.jpg"><br>
<br>
</a><a href=3D"http://www.radusa.com/12/RAD-Industry-Awards/23316/"><img sr=
c=3D"http://prm.radusa.com/images/RAD242.jpg"></a>
</body>
</html>

--_000_36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1exus4adradcoil_--


--===============3759249686560131002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3759249686560131002==--


From xen-devel-bounces@lists.xen.org Wed Jun 27 23:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 23:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk1Uq-0002Si-Qh; Wed, 27 Jun 2012 23:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyclonusj@gmail.com>) id 1Sk1Up-0002Sd-Mp
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 23:18:03 +0000
Received: from [85.158.143.35:41514] by server-2.bemta-4.messagelabs.com id
	E2/92-17938-AA49BEF4; Wed, 27 Jun 2012 23:18:02 +0000
X-Env-Sender: cyclonusj@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340839079!12963389!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19929 invoked from network); 27 Jun 2012 23:18:01 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 23:18:01 -0000
Received: by dajz8 with SMTP id z8so2628868daj.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 16:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=A1Yuz/FPUdPgJypAYGcflcgQWlscxMXWhiXKgyRT8Z8=;
	b=NJKzhslBZpCA0fRFnrK5HUwQhIsdC0h0UaOw2urfFgc6IGnRTAQAPkoVmwc/CtnydM
	vZbKI9Q/+zCM6UfJtBIDofl1VlesYt9pW43qVSb8L26zpYJMD3clSYdkxdyzuZafMZ/r
	THZtI9UjDelVnwkpIOA17t3Sweidxow0O6i8J0pqICVEPuhhnt39Roq1MO7d0MO9YJw+
	5Kv+dozoOWB7FvpPFsT2PJa2EGsIo0aP/RigoqgxBIcZ0un4wMKnBKMROpne48duEsgo
	vR32mJN9eCI1G3Aay2gBLGud/XjwYGbS9uCxeC99VOkbd+hXjLSJmFqff9wopbyz8QXk
	Yfig==
Received: by 10.68.228.102 with SMTP id sh6mr94724pbc.134.1340839079291;
	Wed, 27 Jun 2012 16:17:59 -0700 (PDT)
Received: from gmail.com (searspoint.nvidia.com. [216.228.112.21])
	by mx.google.com with ESMTPS id rg9sm97219pbc.67.2012.06.27.16.17.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 27 Jun 2012 16:17:58 -0700 (PDT)
Date: Wed, 27 Jun 2012 16:17:56 -0700
From: Cyclonus J <cyclonusj@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120627231755.GA1021@gmail.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120510153457.GB6389@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, May 10, 2012 at 11:34:57AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 21, 2012 at 06:53:35PM -0800, Jason Garrett-Glaser wrote:
> > On Fri, Feb 10, 2012 at 7:34 AM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > > The attached patch fixes RH BZ #742032, #787403, and #745574
> > > and touch x86 subsystem.
> > >
> > > The patch description gives a very good overview of the problem and
> > > one solution. The one solution it chooses is not the most architectur=
ally
> > > sound but it does not cause performance degradation. If this your
> > > first time reading this, please read the patch first and then come ba=
ck to
> > > this cover letter as I've some perf numbers and more detailed explana=
tion here.
> > >
> > > A bit of overview of the __page_change_attr_set_clr:
> > >
> > > Its purpose is to change page attributes from one type to another.
> > > It is important to understand that the entrance that code:
> > > __page_change_attr_set_clr is guarded by cpa_lock spin-lock - which m=
akes
> > > that whole code be single threaded.
> > >
> > > Albeit it seems that if debug mode is turned on, it can run in parall=
el. The
> > > effect of using the posted patch is that __page_change_attr_set_clr()=
 will be
> > > affected when we change caching attributes on 4KB pages and/or the NX=
 flag.
> > >
> > > The execution of __page_change_attr_set_clr is concentrated in
> > > (looked for ioremap_* and set_pages_*):
> > > =A0- during bootup ("Write protecting the ..")
> > > =A0- suspend/resume and graphic adapters evicting their buffers from =
the card
> > > =A0 to RAM (which is usually done during suspend but can be done via =
the
> > > =A0 'evict' attribute in debugfs)
> > > =A0- when setting the memory for the cursor (AGP cards using i8xx chi=
pset) -
> > > =A0 done during bootup and startup of Xserver.
> > > =A0- setting up memory for Intel GTT scratch (i9xx) page (done during=
 bootup)
> > > =A0- payload (purgatory code) for kexec (done during kexec -l).
> > > =A0- ioremap_* during PCI devices load - InfiniBand and video cards l=
ike to use
> > > =A0 ioremap_wc.
> > > =A0- Intel, radeon, nouveau running into memory pressure and evicting=
 pages from
> > > =A0 their GEM/TTM pool (once an hour or so if compiling a lot with on=
ly 4GB).
> > >
> > > These are the cases I found when running on baremetal (and Xen) using=
 a normal
> > > Fedora Core 16 distro.
> > >
> > > The alternate solution to the problem I am trying to solve, which is =
much
> > > more architecturally sound (but has some perf disadvantages) is to wr=
ap
> > > the pte_flags with paravirt call everywhere. For that these patches t=
wo patches:
> > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-parav=
irt-xen-Introduce-pte_flags.patch
> > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-parav=
irt-xen-Optimize-pte_flags-by-marking-it-as.patch
> > >
> > > make the pte_flags function (after bootup and patching with alternati=
ve asm)
> > > look as so:
> > >
> > > =A0 48 89 f8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0%rdi,=
%rax
> > > =A0 66 66 66 90 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data32 data32 xchg=
 %ax,%ax
> > >
> > > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very we=
ll on Intel
> > > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - th=
at I found out
> > > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compile=
d in (but the tracer
> > > is set to the default 'nop'). If I disable that specific config optio=
n the numbers
> > > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) o=
n the AMD box.
> > > Interestingly enough I only see these on AMD machines - not on the In=
tel ones.
> > =

> > The AMD software optimization manual says that -- at least on some
> > chips -- too many prefixes forces the instruction decoder into a slow
> > mode (basically microcoded) where it takes literally dozens of cycles
> > for a single instruction.  I believe more than 2 prefixes will do
> > this; check the manual itself for specifics.
> =

> I've been digging in to this during my "free" time to figure out what
> is going on. Sadly, haven't progressed much besides writting a set of pat=
ches
> that would add the 'notrace' to the pvops calls and playing with
> those patches.
> =

> In other words - still not sure what is happening.

I would like to spend some time looking into this issue as it blocks my
project in some cases.

I saw a temporary fix 8eaffa67b43e99ae581622c5133e20b0f48bcef1 went into 3.=
3 to disable
PAT support on dom0. May I ask what would be the recommended fix to support=
 PAT on dom0? =

Will it be a possible solution to make Xen use the same PAT settings as Lin=
ux? Sorry, I don't =

know the background why Xen is doing this differently.

Suggestions?

Thanks,
CJ

> > =

> > Jason
> > =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> --
> 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 Wed Jun 27 23:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 23:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk1Uq-0002Si-Qh; Wed, 27 Jun 2012 23:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyclonusj@gmail.com>) id 1Sk1Up-0002Sd-Mp
	for xen-devel@lists.xensource.com; Wed, 27 Jun 2012 23:18:03 +0000
Received: from [85.158.143.35:41514] by server-2.bemta-4.messagelabs.com id
	E2/92-17938-AA49BEF4; Wed, 27 Jun 2012 23:18:02 +0000
X-Env-Sender: cyclonusj@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340839079!12963389!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19929 invoked from network); 27 Jun 2012 23:18:01 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 23:18:01 -0000
Received: by dajz8 with SMTP id z8so2628868daj.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 16:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=A1Yuz/FPUdPgJypAYGcflcgQWlscxMXWhiXKgyRT8Z8=;
	b=NJKzhslBZpCA0fRFnrK5HUwQhIsdC0h0UaOw2urfFgc6IGnRTAQAPkoVmwc/CtnydM
	vZbKI9Q/+zCM6UfJtBIDofl1VlesYt9pW43qVSb8L26zpYJMD3clSYdkxdyzuZafMZ/r
	THZtI9UjDelVnwkpIOA17t3Sweidxow0O6i8J0pqICVEPuhhnt39Roq1MO7d0MO9YJw+
	5Kv+dozoOWB7FvpPFsT2PJa2EGsIo0aP/RigoqgxBIcZ0un4wMKnBKMROpne48duEsgo
	vR32mJN9eCI1G3Aay2gBLGud/XjwYGbS9uCxeC99VOkbd+hXjLSJmFqff9wopbyz8QXk
	Yfig==
Received: by 10.68.228.102 with SMTP id sh6mr94724pbc.134.1340839079291;
	Wed, 27 Jun 2012 16:17:59 -0700 (PDT)
Received: from gmail.com (searspoint.nvidia.com. [216.228.112.21])
	by mx.google.com with ESMTPS id rg9sm97219pbc.67.2012.06.27.16.17.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 27 Jun 2012 16:17:58 -0700 (PDT)
Date: Wed, 27 Jun 2012 16:17:56 -0700
From: Cyclonus J <cyclonusj@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120627231755.GA1021@gmail.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120510153457.GB6389@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, May 10, 2012 at 11:34:57AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 21, 2012 at 06:53:35PM -0800, Jason Garrett-Glaser wrote:
> > On Fri, Feb 10, 2012 at 7:34 AM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > > The attached patch fixes RH BZ #742032, #787403, and #745574
> > > and touch x86 subsystem.
> > >
> > > The patch description gives a very good overview of the problem and
> > > one solution. The one solution it chooses is not the most architectur=
ally
> > > sound but it does not cause performance degradation. If this your
> > > first time reading this, please read the patch first and then come ba=
ck to
> > > this cover letter as I've some perf numbers and more detailed explana=
tion here.
> > >
> > > A bit of overview of the __page_change_attr_set_clr:
> > >
> > > Its purpose is to change page attributes from one type to another.
> > > It is important to understand that the entrance that code:
> > > __page_change_attr_set_clr is guarded by cpa_lock spin-lock - which m=
akes
> > > that whole code be single threaded.
> > >
> > > Albeit it seems that if debug mode is turned on, it can run in parall=
el. The
> > > effect of using the posted patch is that __page_change_attr_set_clr()=
 will be
> > > affected when we change caching attributes on 4KB pages and/or the NX=
 flag.
> > >
> > > The execution of __page_change_attr_set_clr is concentrated in
> > > (looked for ioremap_* and set_pages_*):
> > > =A0- during bootup ("Write protecting the ..")
> > > =A0- suspend/resume and graphic adapters evicting their buffers from =
the card
> > > =A0 to RAM (which is usually done during suspend but can be done via =
the
> > > =A0 'evict' attribute in debugfs)
> > > =A0- when setting the memory for the cursor (AGP cards using i8xx chi=
pset) -
> > > =A0 done during bootup and startup of Xserver.
> > > =A0- setting up memory for Intel GTT scratch (i9xx) page (done during=
 bootup)
> > > =A0- payload (purgatory code) for kexec (done during kexec -l).
> > > =A0- ioremap_* during PCI devices load - InfiniBand and video cards l=
ike to use
> > > =A0 ioremap_wc.
> > > =A0- Intel, radeon, nouveau running into memory pressure and evicting=
 pages from
> > > =A0 their GEM/TTM pool (once an hour or so if compiling a lot with on=
ly 4GB).
> > >
> > > These are the cases I found when running on baremetal (and Xen) using=
 a normal
> > > Fedora Core 16 distro.
> > >
> > > The alternate solution to the problem I am trying to solve, which is =
much
> > > more architecturally sound (but has some perf disadvantages) is to wr=
ap
> > > the pte_flags with paravirt call everywhere. For that these patches t=
wo patches:
> > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-parav=
irt-xen-Introduce-pte_flags.patch
> > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-parav=
irt-xen-Optimize-pte_flags-by-marking-it-as.patch
> > >
> > > make the pte_flags function (after bootup and patching with alternati=
ve asm)
> > > look as so:
> > >
> > > =A0 48 89 f8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0%rdi,=
%rax
> > > =A0 66 66 66 90 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data32 data32 xchg=
 %ax,%ax
> > >
> > > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very we=
ll on Intel
> > > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - th=
at I found out
> > > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compile=
d in (but the tracer
> > > is set to the default 'nop'). If I disable that specific config optio=
n the numbers
> > > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) o=
n the AMD box.
> > > Interestingly enough I only see these on AMD machines - not on the In=
tel ones.
> > =

> > The AMD software optimization manual says that -- at least on some
> > chips -- too many prefixes forces the instruction decoder into a slow
> > mode (basically microcoded) where it takes literally dozens of cycles
> > for a single instruction.  I believe more than 2 prefixes will do
> > this; check the manual itself for specifics.
> =

> I've been digging in to this during my "free" time to figure out what
> is going on. Sadly, haven't progressed much besides writting a set of pat=
ches
> that would add the 'notrace' to the pvops calls and playing with
> those patches.
> =

> In other words - still not sure what is happening.

I would like to spend some time looking into this issue as it blocks my
project in some cases.

I saw a temporary fix 8eaffa67b43e99ae581622c5133e20b0f48bcef1 went into 3.=
3 to disable
PAT support on dom0. May I ask what would be the recommended fix to support=
 PAT on dom0? =

Will it be a possible solution to make Xen use the same PAT settings as Lin=
ux? Sorry, I don't =

know the background why Xen is doing this differently.

Suggestions?

Thanks,
CJ

> > =

> > Jason
> > =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> --
> 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 Wed Jun 27 23:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 23: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 1Sk1V4-0002TH-7G; Wed, 27 Jun 2012 23:18:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1Sk1V2-0002TB-St
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 23:18:17 +0000
Received: from [85.158.138.51:41704] by server-2.bemta-3.messagelabs.com id
	06/D9-10266-8B49BEF4; Wed, 27 Jun 2012 23:18:16 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340839094!25842502!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16636 invoked from network); 27 Jun 2012 23:18:15 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 23:18:15 -0000
Received: by lbok6 with SMTP id k6so2829916lbo.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 16:18:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=izE/dfyZyKCUIKr7gEE7eNnC0k2dLGyztbxL5oq6tmk=;
	b=gNAorgFKHPUP/vJ3DBuehFH87Iq3PgtAPjUKBWciPJ2iNs5AUPgXnJJ5fIJoJFJ2M6
	6XRSu7lY2cvksFSXIbXZ8U3o6EM+GVvKK/I6kpx2laVMEcKiKcZgLWK3kowO/wG91G0A
	rEVmpNJmTUbb7Z1ED3BysjrVW523ougcimzAIDPc3ghUULi+YCVJaZoSPpt6KiuEYMpe
	D9W+gVoZFaA0522FLM3suYPdbIDGMk8+dWjPXLwovkveQPHNp3xeR/HAldn8HwV79St7
	C/gK4xSWYauaZf8X2Yw5j0jL8Ys6Dek02466WJJ7tumzh49VVJ4KoaiLPzMOjndtUv+0
	Flew==
MIME-Version: 1.0
Received: by 10.112.47.231 with SMTP id g7mr53547lbn.29.1340839094535; Wed, 27
	Jun 2012 16:18:14 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Wed, 27 Jun 2012 16:18:14 -0700 (PDT)
In-Reply-To: <CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
Date: Wed, 27 Jun 2012 16:18:14 -0700
Message-ID: <CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Rolu <rolu@roce.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 25, 2012 at 7:51 PM, Rolu <rolu@roce.org> wrote:
>
> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> > Hi, I was playing around with a MSI capable virtual device (so far
> > submitted as patches only) in the upstream qemu tree but having
> > trouble getting it to work on a Xen hvm guest. The device happens to
> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
> > works fine in a Xen guest when I switch the device's=A0code to force
> > usage of legacy interrupts with upstream QEMU. With MSI based
> > interrupts, the device works fine on a KVM guest but as stated before,
> > not on a Xen guest. After digging a bit, it appears, the reason for
> > the failure in Xen guests is that the MSI data register in the Xen
> > guest ends up with a value of 4300 where the Deliver Mode value of 3
> > happens to be reserved (per spec) and therefore illegal. The
> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> > illegal (per expectation) causing all commands issued by the guest OS
> > on the device to timeout.
> >
> > Given this above scenario, I was wondering if anyone can shed some
> > light on how to debug this further for Xen. Something I would
> > specifically like to know is where the MSI data register configuration
> > actually happens. Is it done by some code specific to Xen and within
> > the Xen codebase or it all done within QEMU?
> >
>
> This seems like the same issue I ran into, though in my case it is
> with passed through physical devices. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
> the older messages in that thread for more info on what's going on. No
> fix yet but help debugging is very welcome.

Thanks Rolu for pointing out the other thread - it was very useful.
Some of the symptoms appear to be identical in my case. However, I am
not using a pass-through device. Instead, in my case it's a fully
virtualized device pretty much identical to a raw file backed disk
image where the controller is pvscsi rather than lsi. Therefore I
guess some of the latter discussion in the other thread around
pass-through specific areas of code in qemu are not relevant? Please
correct me if I am wrong. Also note that I am using upstream qemu
where neither the #define for PT_PCI_MSITRANSLATE_DEFAULT nor
xenstore.c exsits (which is where Stefano's suggested change appeared
to be).

So far, here's what I am observing in the hvm linux guest :

On the guest side, as discussed in the other thread,
xen_hvm_setup_msi_irqs is invoked for the device and a value of 0x4300
is being by xen_msi_compose_msg that is written in the data register.
On the qemu (upstream) side, when the virtualized controller is trying
to complete a request, it's invoking the following chain of calls ->
stl_le_phys -> xen_apic_mem_write -> xen_hvm_inject_msi
On the xen side, this ends up in: hvmop_inject_msi -> hvm_inject_msi
-> vmsi_deliver. vmsi_deliver, as previously discussed, rejects the
delivery mode of 0x3.

Is the above sequence of interactions the expected path for a HVM
guest trying to use a fully virtualized device/controller that uses
MSI in upstream qemu? If so, if a standard linux guest always
populates the value of 0x4300 in the MSI data register through
xen_hvm_setup_msi_irqs, how are MSI notifications from a device in
qemu supposed to work given the delivery type of 0x3 is indeed
reserved and bypass the the vmsi_deliver check?

Thanks,
Deep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Jun 27 23:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Jun 2012 23: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 1Sk1V4-0002TH-7G; Wed, 27 Jun 2012 23:18:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1Sk1V2-0002TB-St
	for xen-devel@lists.xen.org; Wed, 27 Jun 2012 23:18:17 +0000
Received: from [85.158.138.51:41704] by server-2.bemta-3.messagelabs.com id
	06/D9-10266-8B49BEF4; Wed, 27 Jun 2012 23:18:16 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340839094!25842502!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16636 invoked from network); 27 Jun 2012 23:18:15 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jun 2012 23:18:15 -0000
Received: by lbok6 with SMTP id k6so2829916lbo.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 16:18:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=izE/dfyZyKCUIKr7gEE7eNnC0k2dLGyztbxL5oq6tmk=;
	b=gNAorgFKHPUP/vJ3DBuehFH87Iq3PgtAPjUKBWciPJ2iNs5AUPgXnJJ5fIJoJFJ2M6
	6XRSu7lY2cvksFSXIbXZ8U3o6EM+GVvKK/I6kpx2laVMEcKiKcZgLWK3kowO/wG91G0A
	rEVmpNJmTUbb7Z1ED3BysjrVW523ougcimzAIDPc3ghUULi+YCVJaZoSPpt6KiuEYMpe
	D9W+gVoZFaA0522FLM3suYPdbIDGMk8+dWjPXLwovkveQPHNp3xeR/HAldn8HwV79St7
	C/gK4xSWYauaZf8X2Yw5j0jL8Ys6Dek02466WJJ7tumzh49VVJ4KoaiLPzMOjndtUv+0
	Flew==
MIME-Version: 1.0
Received: by 10.112.47.231 with SMTP id g7mr53547lbn.29.1340839094535; Wed, 27
	Jun 2012 16:18:14 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Wed, 27 Jun 2012 16:18:14 -0700 (PDT)
In-Reply-To: <CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
Date: Wed, 27 Jun 2012 16:18:14 -0700
Message-ID: <CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Rolu <rolu@roce.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 25, 2012 at 7:51 PM, Rolu <rolu@roce.org> wrote:
>
> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> > Hi, I was playing around with a MSI capable virtual device (so far
> > submitted as patches only) in the upstream qemu tree but having
> > trouble getting it to work on a Xen hvm guest. The device happens to
> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
> > works fine in a Xen guest when I switch the device's=A0code to force
> > usage of legacy interrupts with upstream QEMU. With MSI based
> > interrupts, the device works fine on a KVM guest but as stated before,
> > not on a Xen guest. After digging a bit, it appears, the reason for
> > the failure in Xen guests is that the MSI data register in the Xen
> > guest ends up with a value of 4300 where the Deliver Mode value of 3
> > happens to be reserved (per spec) and therefore illegal. The
> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> > illegal (per expectation) causing all commands issued by the guest OS
> > on the device to timeout.
> >
> > Given this above scenario, I was wondering if anyone can shed some
> > light on how to debug this further for Xen. Something I would
> > specifically like to know is where the MSI data register configuration
> > actually happens. Is it done by some code specific to Xen and within
> > the Xen codebase or it all done within QEMU?
> >
>
> This seems like the same issue I ran into, though in my case it is
> with passed through physical devices. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
> the older messages in that thread for more info on what's going on. No
> fix yet but help debugging is very welcome.

Thanks Rolu for pointing out the other thread - it was very useful.
Some of the symptoms appear to be identical in my case. However, I am
not using a pass-through device. Instead, in my case it's a fully
virtualized device pretty much identical to a raw file backed disk
image where the controller is pvscsi rather than lsi. Therefore I
guess some of the latter discussion in the other thread around
pass-through specific areas of code in qemu are not relevant? Please
correct me if I am wrong. Also note that I am using upstream qemu
where neither the #define for PT_PCI_MSITRANSLATE_DEFAULT nor
xenstore.c exsits (which is where Stefano's suggested change appeared
to be).

So far, here's what I am observing in the hvm linux guest :

On the guest side, as discussed in the other thread,
xen_hvm_setup_msi_irqs is invoked for the device and a value of 0x4300
is being by xen_msi_compose_msg that is written in the data register.
On the qemu (upstream) side, when the virtualized controller is trying
to complete a request, it's invoking the following chain of calls ->
stl_le_phys -> xen_apic_mem_write -> xen_hvm_inject_msi
On the xen side, this ends up in: hvmop_inject_msi -> hvm_inject_msi
-> vmsi_deliver. vmsi_deliver, as previously discussed, rejects the
delivery mode of 0x3.

Is the above sequence of interactions the expected path for a HVM
guest trying to use a fully virtualized device/controller that uses
MSI in upstream qemu? If so, if a standard linux guest always
populates the value of 0x4300 in the MSI data register through
xen_hvm_setup_msi_irqs, how are MSI notifications from a device in
qemu supposed to work given the delivery type of 0x3 is indeed
reserved and bypass the the vmsi_deliver check?

Thanks,
Deep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 00:28:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 00:28: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 1Sk2Zz-0003MA-Mm; Thu, 28 Jun 2012 00:27:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sk2Zx-0003M5-Kz
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 00:27:25 +0000
Received: from [193.109.254.147:14935] by server-1.bemta-14.messagelabs.com id
	7F/B9-24612-CE4ABEF4; Thu, 28 Jun 2012 00:27:24 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340843243!8909606!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13636 invoked from network); 28 Jun 2012 00:27:24 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 00:27:24 -0000
Received: by obbta14 with SMTP id ta14so2872361obb.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 17:27:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=fF/sjmtWzDiyBBh6NRuJah2Qe4L9rSqLyx0IyGE0M/4=;
	b=mglqrH27VjJ4aZt9Fl8r+2F89nI/nXT7RuUBXdNcXCZYFN5dIvMNNtyxA/UJDXCdge
	sfuTkSeC8lCYvqhdV6lBCGUonNhQiGwkMW7sbq6u48lIJT8O3I7TQdisJTvKrYaJAw6T
	eOalPIzYz1PGKdqiXJ/BfTVosfbrPy0E4/wpan2pfoKgExBg+jGZOFuETnEV4jdHFugG
	3t5SHUWmi+C8jbGlyC3UorPBTXb6KQTt9OPDQA0dnfNylEGGzTd3e5MmUp0NiUPZIIlI
	QFXrlioN8i7xUZAlfdeOqBpL1BFZq0C2xzJik0pWJ+eelGxqBaSdFhaK7SAyxv+h8i1B
	V2ug==
Received: by 10.60.2.35 with SMTP id 3mr22558962oer.63.1340843242470; Wed, 27
	Jun 2012 17:27:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 27 Jun 2012 17:27:02 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Thu, 28 Jun 2012 02:27:02 +0200
Message-ID: <CABs9EjmO0ngu32ObjM8+4vSUebGzEoOnyuRACOTuMJp1+eiAMQ@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQn/h6FdUHxXYCGwkw72ghjqorQyKDDyQc/h15MrNUqu9Pm81mYcXvam0ySlzj3vO413ROJ5
Subject: [Xen-devel] pt_iomul_init 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

In my qemu logs I get lines like this:

pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0

This happens once for every pci device I pass through to the domU the
log is about. I wondered what this meant and had a look.

I found that register_real_device calls pt_iomul_init. This function
then tries to open /dev/xen/pci_iomul, which doesn't exist, and gives
the error. Basically, what happens is just what the error says, but I
still didn't know why.

I eventually traced the function back to the patch introduced by
http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg01218.html.
It describes it as using a PCI IO space multiplexer for big iron
servers with more than 16 PCIe slots. What I'm using isn't like that.
I don't have or need a multiplexing driver, as far as I'm aware, so it
seems the error is harmless.

What I also found was people trying to get pci passthrough working,
and wondering if that error had something to do with their issues.
This was also why I first started searching information about the
error. If you pass through a device to a HVM domU and you don't have
the multiplexing driver, you will get the error, causing confusion.

So, for the benefit of future people like me, I'd like to either
clarify the error, or (preferably) just make it go away. I'd like some
input on what people think is the best way to go about this.

* Is there a way for pt_iomul_init or register_real_device to know
that there isn't an IO multiplexer, so there is no point in trying to
initialize it?
* Maybe a configuration file switch that defaults to off?
* Reword the message so it doesn't claim there is an error? "You do
not appear to have a PCI IO space multiplexer driver. Can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 00:28:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 00:28: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 1Sk2Zz-0003MA-Mm; Thu, 28 Jun 2012 00:27:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Sk2Zx-0003M5-Kz
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 00:27:25 +0000
Received: from [193.109.254.147:14935] by server-1.bemta-14.messagelabs.com id
	7F/B9-24612-CE4ABEF4; Thu, 28 Jun 2012 00:27:24 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340843243!8909606!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13636 invoked from network); 28 Jun 2012 00:27:24 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 00:27:24 -0000
Received: by obbta14 with SMTP id ta14so2872361obb.32
	for <xen-devel@lists.xen.org>; Wed, 27 Jun 2012 17:27:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=fF/sjmtWzDiyBBh6NRuJah2Qe4L9rSqLyx0IyGE0M/4=;
	b=mglqrH27VjJ4aZt9Fl8r+2F89nI/nXT7RuUBXdNcXCZYFN5dIvMNNtyxA/UJDXCdge
	sfuTkSeC8lCYvqhdV6lBCGUonNhQiGwkMW7sbq6u48lIJT8O3I7TQdisJTvKrYaJAw6T
	eOalPIzYz1PGKdqiXJ/BfTVosfbrPy0E4/wpan2pfoKgExBg+jGZOFuETnEV4jdHFugG
	3t5SHUWmi+C8jbGlyC3UorPBTXb6KQTt9OPDQA0dnfNylEGGzTd3e5MmUp0NiUPZIIlI
	QFXrlioN8i7xUZAlfdeOqBpL1BFZq0C2xzJik0pWJ+eelGxqBaSdFhaK7SAyxv+h8i1B
	V2ug==
Received: by 10.60.2.35 with SMTP id 3mr22558962oer.63.1340843242470; Wed, 27
	Jun 2012 17:27:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.62.166 with HTTP; Wed, 27 Jun 2012 17:27:02 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Thu, 28 Jun 2012 02:27:02 +0200
Message-ID: <CABs9EjmO0ngu32ObjM8+4vSUebGzEoOnyuRACOTuMJp1+eiAMQ@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQn/h6FdUHxXYCGwkw72ghjqorQyKDDyQc/h15MrNUqu9Pm81mYcXvam0ySlzj3vO413ROJ5
Subject: [Xen-devel] pt_iomul_init 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

In my qemu logs I get lines like this:

pt_iomul_init: Error: pt_iomul_init can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0

This happens once for every pci device I pass through to the domU the
log is about. I wondered what this meant and had a look.

I found that register_real_device calls pt_iomul_init. This function
then tries to open /dev/xen/pci_iomul, which doesn't exist, and gives
the error. Basically, what happens is just what the error says, but I
still didn't know why.

I eventually traced the function back to the patch introduced by
http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg01218.html.
It describes it as using a PCI IO space multiplexer for big iron
servers with more than 16 PCIe slots. What I'm using isn't like that.
I don't have or need a multiplexing driver, as far as I'm aware, so it
seems the error is harmless.

What I also found was people trying to get pci passthrough working,
and wondering if that error had something to do with their issues.
This was also why I first started searching information about the
error. If you pass through a device to a HVM domU and you don't have
the multiplexing driver, you will get the error, causing confusion.

So, for the benefit of future people like me, I'd like to either
clarify the error, or (preferably) just make it go away. I'd like some
input on what people think is the best way to go about this.

* Is there a way for pt_iomul_init or register_real_device to know
that there isn't an IO multiplexer, so there is no point in trying to
initialize it?
* Maybe a configuration file switch that defaults to off?
* Reword the message so it doesn't claim there is an error? "You do
not appear to have a PCI IO space multiplexer driver. Can't open file
/dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 01:42:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 01: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 1Sk3kL-0007g0-5Q; Thu, 28 Jun 2012 01:42:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1Sk3kJ-0007fu-Gk
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 01:42:11 +0000
Received: from [85.158.143.35:15349] by server-3.bemta-4.messagelabs.com id
	35/FD-05808-276BBEF4; Thu, 28 Jun 2012 01:42:10 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340847729!14408406!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27900 invoked from network); 28 Jun 2012 01:42:10 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 01:42:10 -0000
Received: by obbef5 with SMTP id ef5so3366814obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 18:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=EhoGjxYuReKvRq3ph/KQNpabuqi4GqPYjBQjnFq0cvs=;
	b=Wz1IPvx55tpY4kxGa1CJEhvcuEl3DzotmyrzMOW82ELIzxdDptSjcc80FqaGRMOxgm
	SP5Fdw5n5koAbbWPuWIhjBinJrEzeV864q8rvPu3pLt3X3BVAsXKfSh4Og5nU69hnd0A
	5hV9MZ3K1Ew8y2GNRvhl/zfAKrx8/62Im9qcAyr8E8PrMtTgB4w7NVsorPxdTITeqmDx
	s6fRZwp/IWhjWd3GFJv5WilakUpZdo4q1Og1I2BpEJm6N4f8mswtBc5klvimj1TGQzNq
	BnfaRy7cqk+91kNwhOnHPShbq0uCqxEJtfWtJuu5qRhYMFMotyYsqzdDIJmsV5pRp2dA
	X+Yg==
MIME-Version: 1.0
Received: by 10.60.28.101 with SMTP id a5mr22723621oeh.69.1340847728731; Wed,
	27 Jun 2012 18:42:08 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 27 Jun 2012 18:42:08 -0700 (PDT)
In-Reply-To: <1340810891.29172.50.camel@zakaz.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
Date: Thu, 28 Jun 2012 09:42:08 +0800
Message-ID: <CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
>> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c =A0Fri May 18 16:19:21 2012 +0100
>> +++ b/tools/libxl/xl_cmdimpl.c =A0Wed Jun 27 20:06:39 2012 +0800
>> @@ -1256,7 +1256,10 @@ skip_vfb:
>> =A0#undef parse_extra_args
>>
>> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.st=
dvga, 0);
>> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D LIBXL_VGA_IN=
TERFACE_TYPE_STD;
>
> I think this needs to be:
> =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D l ? \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 LIBXL_VGA_INTERFACE_TYPE_STD : \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>
> so that both "stdvga=3D0" and "stdvga=3D1" result in what the user asked =
for
> without relying on the libxl default remaining CIRRUS.

IMHO, this make simple to be complex.

I think the check  and set-default later in libxl_create.c as a whole is en=
ough.
+        if (!b_info->u.hvm.vga.kind)
+            b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_CIRRUS;

'as a whole' here, I means if more vga type added in the future, we
don't need to set the default
one by one, redundantly.
> Ian.
>

-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 01:42:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 01: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 1Sk3kL-0007g0-5Q; Thu, 28 Jun 2012 01:42:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1Sk3kJ-0007fu-Gk
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 01:42:11 +0000
Received: from [85.158.143.35:15349] by server-3.bemta-4.messagelabs.com id
	35/FD-05808-276BBEF4; Thu, 28 Jun 2012 01:42:10 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340847729!14408406!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27900 invoked from network); 28 Jun 2012 01:42:10 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 01:42:10 -0000
Received: by obbef5 with SMTP id ef5so3366814obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Jun 2012 18:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=EhoGjxYuReKvRq3ph/KQNpabuqi4GqPYjBQjnFq0cvs=;
	b=Wz1IPvx55tpY4kxGa1CJEhvcuEl3DzotmyrzMOW82ELIzxdDptSjcc80FqaGRMOxgm
	SP5Fdw5n5koAbbWPuWIhjBinJrEzeV864q8rvPu3pLt3X3BVAsXKfSh4Og5nU69hnd0A
	5hV9MZ3K1Ew8y2GNRvhl/zfAKrx8/62Im9qcAyr8E8PrMtTgB4w7NVsorPxdTITeqmDx
	s6fRZwp/IWhjWd3GFJv5WilakUpZdo4q1Og1I2BpEJm6N4f8mswtBc5klvimj1TGQzNq
	BnfaRy7cqk+91kNwhOnHPShbq0uCqxEJtfWtJuu5qRhYMFMotyYsqzdDIJmsV5pRp2dA
	X+Yg==
MIME-Version: 1.0
Received: by 10.60.28.101 with SMTP id a5mr22723621oeh.69.1340847728731; Wed,
	27 Jun 2012 18:42:08 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Wed, 27 Jun 2012 18:42:08 -0700 (PDT)
In-Reply-To: <1340810891.29172.50.camel@zakaz.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
Date: Thu, 28 Jun 2012 09:42:08 +0800
Message-ID: <CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
>> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c =A0Fri May 18 16:19:21 2012 +0100
>> +++ b/tools/libxl/xl_cmdimpl.c =A0Wed Jun 27 20:06:39 2012 +0800
>> @@ -1256,7 +1256,10 @@ skip_vfb:
>> =A0#undef parse_extra_args
>>
>> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.st=
dvga, 0);
>> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D LIBXL_VGA_IN=
TERFACE_TYPE_STD;
>
> I think this needs to be:
> =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D l ? \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 LIBXL_VGA_INTERFACE_TYPE_STD : \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>
> so that both "stdvga=3D0" and "stdvga=3D1" result in what the user asked =
for
> without relying on the libxl default remaining CIRRUS.

IMHO, this make simple to be complex.

I think the check  and set-default later in libxl_create.c as a whole is en=
ough.
+        if (!b_info->u.hvm.vga.kind)
+            b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_CIRRUS;

'as a whole' here, I means if more vga type added in the future, we
don't need to set the default
one by one, redundantly.
> Ian.
>

-- =

Zhou Peng

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 02:00:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 02:00: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 1Sk41v-00088n-Tr; Thu, 28 Jun 2012 02:00: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 1Sk41t-000841-Ha
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 02:00:21 +0000
Received: from [85.158.138.51:22395] by server-12.bemta-3.messagelabs.com id
	F0/CF-30206-4BABBEF4; Thu, 28 Jun 2012 02:00:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340848819!20992865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19949 invoked from network); 28 Jun 2012 02:00:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 02:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,488,1336348800"; d="scan'208";a="13257537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 02:00:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 03:00:18 +0100
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 1Sk41q-0004LS-EQ;
	Thu, 28 Jun 2012 02:00:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sk41q-0001LG-AD;
	Thu, 28 Jun 2012 03:00:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13376-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 03:00:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13376: 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 13376 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13376/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 13373
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 13373 pass in 13376

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13371

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13373 never pass

version targeted for testing:
 xen                  4f92bdf3370c
baseline version:
 xen                  c6c9d20963d7

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=4f92bdf3370c
+ . 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 4f92bdf3370c
+ branch=xen-unstable
+ revision=4f92bdf3370c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 4f92bdf3370c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 02:00:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 02:00: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 1Sk41v-00088n-Tr; Thu, 28 Jun 2012 02:00: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 1Sk41t-000841-Ha
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 02:00:21 +0000
Received: from [85.158.138.51:22395] by server-12.bemta-3.messagelabs.com id
	F0/CF-30206-4BABBEF4; Thu, 28 Jun 2012 02:00:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340848819!20992865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19949 invoked from network); 28 Jun 2012 02:00:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 02:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,488,1336348800"; d="scan'208";a="13257537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 02:00:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 03:00:18 +0100
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 1Sk41q-0004LS-EQ;
	Thu, 28 Jun 2012 02:00:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sk41q-0001LG-AD;
	Thu, 28 Jun 2012 03:00:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13376-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 03:00:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13376: 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 13376 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13376/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 13373
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 13373 pass in 13376

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13371

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13373 never pass

version targeted for testing:
 xen                  4f92bdf3370c
baseline version:
 xen                  c6c9d20963d7

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=4f92bdf3370c
+ . 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 4f92bdf3370c
+ branch=xen-unstable
+ revision=4f92bdf3370c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 4f92bdf3370c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 02:27:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 02:27: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 1Sk4RX-000055-AG; Thu, 28 Jun 2012 02:26:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sk4RV-000050-Q0
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 02:26:49 +0000
Received: from [193.109.254.147:50033] by server-5.bemta-14.messagelabs.com id
	5D/31-04343-9E0CBEF4; Thu, 28 Jun 2012 02:26:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340850408!3759157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16545 invoked from network); 28 Jun 2012 02:26:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 02:26:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,488,1336348800"; d="scan'208";a="13257606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 02:26:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 03:26:47 +0100
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 1Sk4RT-0004UH-M9;
	Thu, 28 Jun 2012 02:26:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sk4RT-00065W-IG;
	Thu, 28 Jun 2012 03:26:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13378-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 03:26:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13378: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13378 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13378/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13375 REGR. vs. 13338

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13375
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install         fail pass in 13375
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13375
 test-amd64-amd64-qemuu-win   12 guest-localmigrate/x10      fail pass in 13375

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 13375 never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop        fail in 13375 never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check      fail in 13375 never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 02:27:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 02:27: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 1Sk4RX-000055-AG; Thu, 28 Jun 2012 02:26:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Sk4RV-000050-Q0
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 02:26:49 +0000
Received: from [193.109.254.147:50033] by server-5.bemta-14.messagelabs.com id
	5D/31-04343-9E0CBEF4; Thu, 28 Jun 2012 02:26:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340850408!3759157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16545 invoked from network); 28 Jun 2012 02:26:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 02:26:48 -0000
X-IronPort-AV: E=Sophos;i="4.77,488,1336348800"; d="scan'208";a="13257606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 02:26:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 03:26:47 +0100
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 1Sk4RT-0004UH-M9;
	Thu, 28 Jun 2012 02:26:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sk4RT-00065W-IG;
	Thu, 28 Jun 2012 03:26:47 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13378-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 03:26:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13378: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13378 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13378/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13375 REGR. vs. 13338

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13375
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install         fail pass in 13375
 test-amd64-i386-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13375
 test-amd64-amd64-qemuu-win   12 guest-localmigrate/x10      fail pass in 13375

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 13375 never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop        fail in 13375 never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check      fail in 13375 never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 02:39:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 02:39:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk4dM-0000GE-IU; Thu, 28 Jun 2012 02:39:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Sk4dL-0000G9-4V
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 02:39:03 +0000
Received: from [85.158.138.51:31616] by server-9.bemta-3.messagelabs.com id
	1E/CD-10419-6C3CBEF4; Thu, 28 Jun 2012 02:39:02 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340851140!29954013!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22983 invoked from network); 28 Jun 2012 02:39:00 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 02:39:00 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Jun 2012 19:38:56 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="159042129"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 27 Jun 2012 19:38:55 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Jun 2012 19:38:55 -0700
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; Wed, 27 Jun 2012 19:38:54 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 10:38:52 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v3 ]libxl: allow to allocate cpumap with specific size
Thread-Index: Ac1U1ydQEQXsxZTtQxOXfa22gL87fg==
Date: Thu, 28 Jun 2012 02:38:52 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
	specific 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

Change from v2:
Rebase on top of latest head.

Currently, libxl_cpumap_alloc()allocate the cpumap with size of number of physical cpus. In some place, we may want to allocate specific size of cpumap.
This patch allow to pass a argument to specific the size that you want to allocate. If pass 0, it means the size is equal to number of physical cpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c       Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl.c       Wed Jun 27 10:38:16 2012 +0800
@@ -570,7 +570,7 @@ static int cpupool_info(libxl__gc *gc,
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap))
+    if (libxl_cpumap_alloc(CTX, &info->cpumap, 0))
         goto out;
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);

@@ -3287,7 +3287,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
     }

     for (*nb_vcpu = 0; *nb_vcpu <= domaininfo.max_vcpu_id; ++*nb_vcpu, ++ptr) {
-        if (libxl_cpumap_alloc(ctx, &ptr->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &ptr->cpumap, 0)) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpumap");
             return NULL;
         }
@@ -4040,8 +4040,8 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     if ((info->cpupool_id != poolid) || (info->n_dom))
         goto out;

-    rc = ERROR_NOMEM;
-    if (libxl_cpumap_alloc(ctx, &cpumap))
+    rc = libxl_cpumap_alloc(ctx, &cpumap, 0);
+    if (rc)
         goto out;

     memcpy(cpumap.map, info->cpumap, cpumap.size);
diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl_create.c        Wed Jun 27 10:38:16 2012 +0800
@@ -205,8 +205,8 @@ int libxl__domain_build_info_setdefault(
         b_info->cur_vcpus = 1;

     if (!b_info->cpumap.size) {
-        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
-            return ERROR_NOMEM;
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
+            return ERROR_FAIL;
         libxl_cpumap_set_any(&b_info->cpumap);
     }

diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl_utils.c Wed Jun 27 10:38:16 2012 +0800
@@ -489,19 +489,19 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus)
 {
-    int max_cpus;
     int sz;

-    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus < 0)
+        return ERROR_INVAL;
+    if (max_cpus == 0)
+        max_cpus = libxl_get_max_cpus(ctx);
     if (max_cpus == 0)
         return ERROR_FAIL;

     sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
-        return ERROR_NOMEM;
+    cpumap->map = libxl__calloc(NULL, sizeof(*cpumap->map), sz);
     cpumap->size = sz;
     return 0;
 }
diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl_utils.h Wed Jun 27 10:38:16 2012 +0800
@@ -63,7 +63,7 @@ int libxl_devid_to_device_nic(libxl_ctx
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus);
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 10:38:16 2012 +0800
@@ -503,7 +503,7 @@ static int vcpupin_parse(char *cpu, libx
         return 0;
     }

-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap, 0)) {
         fprintf(stderr, "Error: Failed to allocate cpumap.\n");
         return ENOMEM;
     }
@@ -656,7 +656,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -692,7 +692,7 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -1779,7 +1779,9 @@ start:
     if (vcpu_to_pcpu) {
         libxl_cpumap vcpu_cpumap;

-        libxl_cpumap_alloc(ctx, &vcpu_cpumap);
+        ret = libxl_cpumap_alloc(ctx, &vcpu_cpumap, 0);
+        if (ret)
+            goto error_out;
         for (i = 0; i < d_config.b_info.max_vcpus; i++) {

             if (vcpu_to_pcpu[i] != -1) {
@@ -4051,7 +4053,7 @@ static void vcpupin(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         goto vcpupin_out;
     }

@@ -4108,7 +4110,7 @@ static void vcpuset(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "libxl_cpumap_alloc failed\n");
         return;
     }
@@ -5921,7 +5923,7 @@ int main_cpupoolcreate(int argc, char **
         fprintf(stderr, "libxl_get_freecpus failed\n");
         goto out_cfg;
     }
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         goto out_cfg;
     }
@@ -6289,7 +6291,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 02:39:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 02:39:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk4dM-0000GE-IU; Thu, 28 Jun 2012 02:39:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Sk4dL-0000G9-4V
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 02:39:03 +0000
Received: from [85.158.138.51:31616] by server-9.bemta-3.messagelabs.com id
	1E/CD-10419-6C3CBEF4; Thu, 28 Jun 2012 02:39:02 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340851140!29954013!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22983 invoked from network); 28 Jun 2012 02:39:00 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 02:39:00 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Jun 2012 19:38:56 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="159042129"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 27 Jun 2012 19:38:55 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Jun 2012 19:38:55 -0700
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; Wed, 27 Jun 2012 19:38:54 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 10:38:52 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v3 ]libxl: allow to allocate cpumap with specific size
Thread-Index: Ac1U1ydQEQXsxZTtQxOXfa22gL87fg==
Date: Thu, 28 Jun 2012 02:38:52 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
	specific 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

Change from v2:
Rebase on top of latest head.

Currently, libxl_cpumap_alloc()allocate the cpumap with size of number of physical cpus. In some place, we may want to allocate specific size of cpumap.
This patch allow to pass a argument to specific the size that you want to allocate. If pass 0, it means the size is equal to number of physical cpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c       Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl.c       Wed Jun 27 10:38:16 2012 +0800
@@ -570,7 +570,7 @@ static int cpupool_info(libxl__gc *gc,
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap))
+    if (libxl_cpumap_alloc(CTX, &info->cpumap, 0))
         goto out;
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);

@@ -3287,7 +3287,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
     }

     for (*nb_vcpu = 0; *nb_vcpu <= domaininfo.max_vcpu_id; ++*nb_vcpu, ++ptr) {
-        if (libxl_cpumap_alloc(ctx, &ptr->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &ptr->cpumap, 0)) {
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpumap");
             return NULL;
         }
@@ -4040,8 +4040,8 @@ int libxl_cpupool_destroy(libxl_ctx *ctx
     if ((info->cpupool_id != poolid) || (info->n_dom))
         goto out;

-    rc = ERROR_NOMEM;
-    if (libxl_cpumap_alloc(ctx, &cpumap))
+    rc = libxl_cpumap_alloc(ctx, &cpumap, 0);
+    if (rc)
         goto out;

     memcpy(cpumap.map, info->cpumap, cpumap.size);
diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl_create.c        Wed Jun 27 10:38:16 2012 +0800
@@ -205,8 +205,8 @@ int libxl__domain_build_info_setdefault(
         b_info->cur_vcpus = 1;

     if (!b_info->cpumap.size) {
-        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
-            return ERROR_NOMEM;
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
+            return ERROR_FAIL;
         libxl_cpumap_set_any(&b_info->cpumap);
     }

diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl_utils.c Wed Jun 27 10:38:16 2012 +0800
@@ -489,19 +489,19 @@ int libxl_mac_to_device_nic(libxl_ctx *c
     return rc;
 }

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap)
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus)
 {
-    int max_cpus;
     int sz;

-    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus < 0)
+        return ERROR_INVAL;
+    if (max_cpus == 0)
+        max_cpus = libxl_get_max_cpus(ctx);
     if (max_cpus == 0)
         return ERROR_FAIL;

     sz = (max_cpus + 7) / 8;
-    cpumap->map = calloc(sz, sizeof(*cpumap->map));
-    if (!cpumap->map)
-        return ERROR_NOMEM;
+    cpumap->map = libxl__calloc(NULL, sizeof(*cpumap->map), sz);
     cpumap->size = sz;
     return 0;
 }
diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/libxl_utils.h Wed Jun 27 10:38:16 2012 +0800
@@ -63,7 +63,7 @@ int libxl_devid_to_device_nic(libxl_ctx
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);

-int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap);
+int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus);
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
diff -r c6c9d20963d7 -r 079fce9e5557 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Tue Jun 26 17:00:20 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 10:38:16 2012 +0800
@@ -503,7 +503,7 @@ static int vcpupin_parse(char *cpu, libx
         return 0;
     }

-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap, 0)) {
         fprintf(stderr, "Error: Failed to allocate cpumap.\n");
         return ENOMEM;
     }
@@ -656,7 +656,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -692,7 +692,7 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);

-        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
             exit(1);
         }
@@ -1779,7 +1779,9 @@ start:
     if (vcpu_to_pcpu) {
         libxl_cpumap vcpu_cpumap;

-        libxl_cpumap_alloc(ctx, &vcpu_cpumap);
+        ret = libxl_cpumap_alloc(ctx, &vcpu_cpumap, 0);
+        if (ret)
+            goto error_out;
         for (i = 0; i < d_config.b_info.max_vcpus; i++) {

             if (vcpu_to_pcpu[i] != -1) {
@@ -4051,7 +4053,7 @@ static void vcpupin(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         goto vcpupin_out;
     }

@@ -4108,7 +4110,7 @@ static void vcpuset(const char *d, const

     find_domain(d);

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "libxl_cpumap_alloc failed\n");
         return;
     }
@@ -5921,7 +5923,7 @@ int main_cpupoolcreate(int argc, char **
         fprintf(stderr, "libxl_get_freecpus failed\n");
         goto out_cfg;
     }
-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         goto out_cfg;
     }
@@ -6289,7 +6291,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }

-    if (libxl_cpumap_alloc(ctx, &cpumap)) {
+    if (libxl_cpumap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
         libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 03:25:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 03:25:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk5Lt-0000ZH-GH; Thu, 28 Jun 2012 03:25:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Sk5Lr-0000ZC-U0
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 03:25:04 +0000
Received: from [85.158.139.83:57078] by server-6.bemta-5.messagelabs.com id
	62/E3-11348-F8ECBEF4; Thu, 28 Jun 2012 03:25:03 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340853901!27167766!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzEwOA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10707 invoked from network); 28 Jun 2012 03:25:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 03:25:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 27 Jun 2012 20:24:57 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="185904266"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 27 Jun 2012 20:24:57 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Jun 2012 20:24:57 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 11:24:56 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v4 ]libxl: allow to set more than 31 vcpus
Thread-Index: Ac1U3Zab8eClqEylRqq6/5gVFTxMtg==
Date: Thu, 28 Jun 2012 03:24:56 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1BD99F@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v4 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 from v3:
Rebased on latest head
Add cpu limit check, the max vcpus of guest is 128.
According Ian's comments, modified some codes to make the logic more reasonable.
Except the following one:
> +        while (l-- > 0)
> +            libxl_cpumap_set((&b_info->avail_vcpus), l);
Ian: This while loop is == libxl_cpumap_set_any.
yang: No, it's different. libxl_cpumap_set_any() will set all bits with the granularity of byte. This may wrong when calling libxl_cpumap_count_set.

Change from v2:
Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
According to Ian's comments, modified some codes to make the logic more reasonable.

In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r 079fce9e5557 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_create.c        Thu Jun 28 10:25:33 2012 +0800
@@ -22,6 +22,7 @@

 #include <xc_dom.h>
 #include <xenguest.h>
+#include <xen/hvm/hvm_info_table.h>

 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -201,8 +202,12 @@ int libxl__domain_build_info_setdefault(

     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
-    if (!b_info->cur_vcpus)
-        b_info->cur_vcpus = 1;
+    if (!b_info->avail_vcpus.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
+            return ERROR_FAIL;
+        libxl_cpumap_set(&b_info->avail_vcpus, 0);
+    } else if(b_info->avail_vcpus.size > HVM_MAX_VCPUS)
+        return ERROR_FAIL;

     if (!b_info->cpumap.size) {
         if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
diff -r 079fce9e5557 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c    Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_dm.c    Thu Jun 28 10:25:33 2012 +0800
@@ -160,6 +160,8 @@ static char ** libxl__build_device_model
     }
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
+        int nr_set_cpus = 0;
+        char *s;

         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
@@ -200,11 +202,13 @@ static char ** libxl__build_device_model
                               libxl__sprintf(gc, "%d", b_info->max_vcpus),
                               NULL);
         }
-        if (b_info->cur_vcpus) {
-            flexarray_vappend(dm_args, "-vcpu_avail",
-                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
-                              NULL);
-        }
+
+        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
+        flexarray_vappend(dm_args, "-vcpu_avail",
+                              libxl__sprintf(gc, "%s", s), NULL);
+        free(s);
+
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
@@ -443,11 +447,14 @@ static char ** libxl__build_device_model
         }
         if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (b_info->cur_vcpus)
+            if (b_info->avail_vcpus.size) {
+                int nr_set_cpus = 0;
+                nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
                                                          b_info->max_vcpus,
-                                                         b_info->cur_vcpus));
-            else
+                                                         nr_set_cpus));
+            } else
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d",
                                                          b_info->max_vcpus));
         }
diff -r 079fce9e5557 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c   Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_dom.c   Thu Jun 28 10:25:33 2012 +0800
@@ -199,8 +199,8 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
-                            ? "offline" : "online";
+        ents[12+(i*2)+1] = libxl_cpumap_test(&info->avail_vcpus, i)
+                            ? "online" : "offline";
     }

     hvm_ents = NULL;
@@ -354,7 +354,7 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
-    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
+    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
     va_hvm->checksum -= sum;
diff -r 079fce9e5557 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl       Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_types.idl       Thu Jun 28 10:25:33 2012 +0800
@@ -237,7 +237,7 @@ libxl_domain_sched_params = Struct("doma

 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
-    ("cur_vcpus",       integer),
+    ("avail_vcpus",     libxl_cpumap),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
diff -r 079fce9e5557 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_utils.c Thu Jun 28 10:25:33 2012 +0800
@@ -511,7 +511,7 @@ void libxl_cpumap_dispose(libxl_cpumap *
     free(map->map);
 }

-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
+int libxl_cpumap_test(const libxl_cpumap *cpumap, int cpu)
 {
     if (cpu >= cpumap->size * 8)
         return 0;
@@ -532,6 +532,31 @@ void libxl_cpumap_reset(libxl_cpumap *cp
     cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
 }

+int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
+{
+    int i, nr_set_cpus = 0;
+    libxl_for_each_set_cpu(i, *cpumap)
+        nr_set_cpus++;
+
+    return nr_set_cpus;
+}
+
+/* NB. caller is responsible for freeing the memory */
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
+{
+    int i = cpumap->size;
+    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 3);
+    char *q = p;
+    strncpy(p, "0x", 2);
+    p += 2;
+    while(--i >= 0) {
+        sprintf(p, "%02x", cpumap->map[i]);
+        p += 2;
+    }
+    *p = '\0';
+    return q;
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff -r 079fce9e5557 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_utils.h Thu Jun 28 10:25:33 2012 +0800
@@ -64,9 +64,11 @@ int libxl_vdev_to_device_disk(libxl_ctx
                                libxl_device_disk *disk);

 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus);
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
+int libxl_cpumap_test(const libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
     memset(cpumap->map, -1, cpumap->size);
diff -r 079fce9e5557 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 28 10:25:33 2012 +0800
@@ -647,7 +647,14 @@ static void parse_config_data(const char

     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
-        b_info->cur_vcpus = (1 << l) - 1;
+
+        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+        libxl_cpumap_set_none(&b_info->avail_vcpus);
+        while (l-- > 0)
+            libxl_cpumap_set((&b_info->avail_vcpus), l);
     }

     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 03:25:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 03:25:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk5Lt-0000ZH-GH; Thu, 28 Jun 2012 03:25:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Sk5Lr-0000ZC-U0
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 03:25:04 +0000
Received: from [85.158.139.83:57078] by server-6.bemta-5.messagelabs.com id
	62/E3-11348-F8ECBEF4; Thu, 28 Jun 2012 03:25:03 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340853901!27167766!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzEwOA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10707 invoked from network); 28 Jun 2012 03:25:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 03:25:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 27 Jun 2012 20:24:57 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="185904266"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 27 Jun 2012 20:24:57 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Jun 2012 20:24:57 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 11:24:56 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v4 ]libxl: allow to set more than 31 vcpus
Thread-Index: Ac1U3Zab8eClqEylRqq6/5gVFTxMtg==
Date: Thu, 28 Jun 2012 03:24:56 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1BD99F@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: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH v4 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 from v3:
Rebased on latest head
Add cpu limit check, the max vcpus of guest is 128.
According Ian's comments, modified some codes to make the logic more reasonable.
Except the following one:
> +        while (l-- > 0)
> +            libxl_cpumap_set((&b_info->avail_vcpus), l);
Ian: This while loop is == libxl_cpumap_set_any.
yang: No, it's different. libxl_cpumap_set_any() will set all bits with the granularity of byte. This may wrong when calling libxl_cpumap_count_set.

Change from v2:
Add function libxl_cpumap_to_hex_string to covert cpumap to hex string.
According to Ian's comments, modified some codes to make the logic more reasonable.

In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

diff -r 079fce9e5557 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_create.c        Thu Jun 28 10:25:33 2012 +0800
@@ -22,6 +22,7 @@

 #include <xc_dom.h>
 #include <xenguest.h>
+#include <xen/hvm/hvm_info_table.h>

 void libxl_domain_config_init(libxl_domain_config *d_config)
 {
@@ -201,8 +202,12 @@ int libxl__domain_build_info_setdefault(

     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
-    if (!b_info->cur_vcpus)
-        b_info->cur_vcpus = 1;
+    if (!b_info->avail_vcpus.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->avail_vcpus, 1))
+            return ERROR_FAIL;
+        libxl_cpumap_set(&b_info->avail_vcpus, 0);
+    } else if(b_info->avail_vcpus.size > HVM_MAX_VCPUS)
+        return ERROR_FAIL;

     if (!b_info->cpumap.size) {
         if (libxl_cpumap_alloc(CTX, &b_info->cpumap, 0))
diff -r 079fce9e5557 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c    Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_dm.c    Thu Jun 28 10:25:33 2012 +0800
@@ -160,6 +160,8 @@ static char ** libxl__build_device_model
     }
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
+        int nr_set_cpus = 0;
+        char *s;

         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
@@ -200,11 +202,13 @@ static char ** libxl__build_device_model
                               libxl__sprintf(gc, "%d", b_info->max_vcpus),
                               NULL);
         }
-        if (b_info->cur_vcpus) {
-            flexarray_vappend(dm_args, "-vcpu_avail",
-                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
-                              NULL);
-        }
+
+        nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
+        flexarray_vappend(dm_args, "-vcpu_avail",
+                              libxl__sprintf(gc, "%s", s), NULL);
+        free(s);
+
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
                 char *smac = libxl__sprintf(gc,
@@ -443,11 +447,14 @@ static char ** libxl__build_device_model
         }
         if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (b_info->cur_vcpus)
+            if (b_info->avail_vcpus.size) {
+                int nr_set_cpus = 0;
+                nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
+
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
                                                          b_info->max_vcpus,
-                                                         b_info->cur_vcpus));
-            else
+                                                         nr_set_cpus));
+            } else
                 flexarray_append(dm_args, libxl__sprintf(gc, "%d",
                                                          b_info->max_vcpus));
         }
diff -r 079fce9e5557 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c   Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_dom.c   Thu Jun 28 10:25:33 2012 +0800
@@ -199,8 +199,8 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[11] = libxl__sprintf(gc, "%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)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
-                            ? "offline" : "online";
+        ents[12+(i*2)+1] = libxl_cpumap_test(&info->avail_vcpus, i)
+                            ? "online" : "offline";
     }

     hvm_ents = NULL;
@@ -354,7 +354,7 @@ static int hvm_build_set_params(xc_inter
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
     va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
-    memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
+    memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size);
     for (i = 0, sum = 0; i < va_hvm->length; i++)
         sum += ((uint8_t *) va_hvm)[i];
     va_hvm->checksum -= sum;
diff -r 079fce9e5557 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl       Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_types.idl       Thu Jun 28 10:25:33 2012 +0800
@@ -237,7 +237,7 @@ libxl_domain_sched_params = Struct("doma

 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
-    ("cur_vcpus",       integer),
+    ("avail_vcpus",     libxl_cpumap),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
diff -r 079fce9e5557 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_utils.c Thu Jun 28 10:25:33 2012 +0800
@@ -511,7 +511,7 @@ void libxl_cpumap_dispose(libxl_cpumap *
     free(map->map);
 }

-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
+int libxl_cpumap_test(const libxl_cpumap *cpumap, int cpu)
 {
     if (cpu >= cpumap->size * 8)
         return 0;
@@ -532,6 +532,31 @@ void libxl_cpumap_reset(libxl_cpumap *cp
     cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
 }

+int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
+{
+    int i, nr_set_cpus = 0;
+    libxl_for_each_set_cpu(i, *cpumap)
+        nr_set_cpus++;
+
+    return nr_set_cpus;
+}
+
+/* NB. caller is responsible for freeing the memory */
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
+{
+    int i = cpumap->size;
+    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 3);
+    char *q = p;
+    strncpy(p, "0x", 2);
+    p += 2;
+    while(--i >= 0) {
+        sprintf(p, "%02x", cpumap->map[i]);
+        p += 2;
+    }
+    *p = '\0';
+    return q;
+}
+
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff -r 079fce9e5557 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/libxl_utils.h Thu Jun 28 10:25:33 2012 +0800
@@ -64,9 +64,11 @@ int libxl_vdev_to_device_disk(libxl_ctx
                                libxl_device_disk *disk);

 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus);
-int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
+int libxl_cpumap_test(const libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
+char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
     memset(cpumap->map, -1, cpumap->size);
diff -r 079fce9e5557 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Wed Jun 27 10:38:16 2012 +0800
+++ b/tools/libxl/xl_cmdimpl.c  Thu Jun 28 10:25:33 2012 +0800
@@ -647,7 +647,14 @@ static void parse_config_data(const char

     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
-        b_info->cur_vcpus = (1 << l) - 1;
+
+        if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+        libxl_cpumap_set_none(&b_info->avail_vcpus);
+        while (l-- > 0)
+            libxl_cpumap_set((&b_info->avail_vcpus), l);
     }

     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 05:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 05: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 1Sk7M5-0001HL-4j; Thu, 28 Jun 2012 05:33: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 1Sk7M3-0001HG-Hu
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 05:33:23 +0000
Received: from [193.109.254.147:12640] by server-1.bemta-14.messagelabs.com id
	1B/39-24612-2ACEBEF4; Thu, 28 Jun 2012 05:33:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340861602!2121376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17252 invoked from network); 28 Jun 2012 05:33:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 05:33:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13258626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 05:33:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:33:21 +0100
Message-ID: <1340861601.5210.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 28 Jun 2012 06:33:21 +0100
In-Reply-To: <CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 02:42 +0100, ZhouPeng wrote:
> On Wed, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> >> --- a/tools/libxl/xl_cmdimpl.c  Fri May 18 16:19:21 2012 +0100
> >> +++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 20:06:39 2012 +0800
> >> @@ -1256,7 +1256,10 @@ skip_vfb:
> >>  #undef parse_extra_args
> >>
> >>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> >> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> >> +            if (l)
> >> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
> >
> > I think this needs to be:
> >          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;
> >
> > so that both "stdvga=0" and "stdvga=1" result in what the user asked for
> > without relying on the libxl default remaining CIRRUS.
> 
> IMHO, this make simple to be complex.
> 
> I think the check  and set-default later in libxl_create.c as a whole is enough.

This is in libxl, as I said above xl should not rely on the default
remaining CIRRUS.

If the user says "stdvga=0" then xl needs to explicitly ask for CIRRUS,
despite the fact that it currently happens to be the default.

If we make the libxl default BLARGLE in the future then stdvga=0 still
needs to mean CIRRUS.

> +        if (!b_info->u.hvm.vga.kind)
> +            b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> 
> 'as a whole' here, I means if more vga type added in the future, we
> don't need to set the default one by one, redundantly.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 05:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 05: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 1Sk7M5-0001HL-4j; Thu, 28 Jun 2012 05:33: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 1Sk7M3-0001HG-Hu
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 05:33:23 +0000
Received: from [193.109.254.147:12640] by server-1.bemta-14.messagelabs.com id
	1B/39-24612-2ACEBEF4; Thu, 28 Jun 2012 05:33:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340861602!2121376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17252 invoked from network); 28 Jun 2012 05:33:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 05:33:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13258626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 05:33:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:33:21 +0100
Message-ID: <1340861601.5210.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 28 Jun 2012 06:33:21 +0100
In-Reply-To: <CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 02:42 +0100, ZhouPeng wrote:
> On Wed, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> >> --- a/tools/libxl/xl_cmdimpl.c  Fri May 18 16:19:21 2012 +0100
> >> +++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 20:06:39 2012 +0800
> >> @@ -1256,7 +1256,10 @@ skip_vfb:
> >>  #undef parse_extra_args
> >>
> >>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> >> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> >> +            if (l)
> >> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
> >
> > I think this needs to be:
> >          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;
> >
> > so that both "stdvga=0" and "stdvga=1" result in what the user asked for
> > without relying on the libxl default remaining CIRRUS.
> 
> IMHO, this make simple to be complex.
> 
> I think the check  and set-default later in libxl_create.c as a whole is enough.

This is in libxl, as I said above xl should not rely on the default
remaining CIRRUS.

If the user says "stdvga=0" then xl needs to explicitly ask for CIRRUS,
despite the fact that it currently happens to be the default.

If we make the libxl default BLARGLE in the future then stdvga=0 still
needs to mean CIRRUS.

> +        if (!b_info->u.hvm.vga.kind)
> +            b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> 
> 'as a whole' here, I means if more vga type added in the future, we
> don't need to set the default one by one, redundantly.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 06:47:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 06:47: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 1Sk8VB-0001yN-I9; Thu, 28 Jun 2012 06:46:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk8V9-0001yI-Ua
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 06:46:52 +0000
Received: from [85.158.138.51:35114] by server-9.bemta-3.messagelabs.com id
	A8/5E-10419-BDDFBEF4; Thu, 28 Jun 2012 06:46:51 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340866008!21019255!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1NTMxNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6202 invoked from network); 28 Jun 2012 06:46:49 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 06:46:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340866009; x=1372402009;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=gMtAXPeulaxOjOquX2UjV05eOVfzg3KdDrgn3rOqUXA=;
	b=Q8N/DM63vbxLzq0g6DwlnX+LJ/QCf0STnWG9Vmdo4NNHjLLDv7DctkfO
	1xVS3UhQayGfmHhFNQ97DZXhqI6pYw==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="401630476"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 06:46:46 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S6kjZY011398; Thu, 28 Jun 2012 06:46:45 GMT
MIME-Version: 1.0
X-Mercurial-Node: 34e47ba2612efdf0b2d601e288de1ac5a406eb53
Message-Id: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 28 Jun 2012 06:46:18 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

All of the other "list" verbs are of the form "$noun-list". For
example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
Additionally, many people have well trained muscle memory from years
of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
in "command not implemented".

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
@@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
 int main_shutdown(int argc, char **argv);
 int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
-int main_list_vm(int argc, char **argv);
+int main_vm_list(int argc, char **argv);
 int main_create(int argc, char **argv);
 int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
@@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
     return 0;
 }
 
-int main_list_vm(int argc, char **argv)
+int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
@@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
-    { "list-vm",
-      &main_list_vm, 0, 0,
-      "List the VMs,without DOM0",
+    { "vm-list",
+      &main_vm_list, 0, 0,
+      "List the VMs, without DOM0",
       "",
     },
     { "info",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 06:47:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 06:47: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 1Sk8VB-0001yN-I9; Thu, 28 Jun 2012 06:46:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk8V9-0001yI-Ua
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 06:46:52 +0000
Received: from [85.158.138.51:35114] by server-9.bemta-3.messagelabs.com id
	A8/5E-10419-BDDFBEF4; Thu, 28 Jun 2012 06:46:51 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340866008!21019255!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1NTMxNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6202 invoked from network); 28 Jun 2012 06:46:49 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 06:46:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340866009; x=1372402009;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=gMtAXPeulaxOjOquX2UjV05eOVfzg3KdDrgn3rOqUXA=;
	b=Q8N/DM63vbxLzq0g6DwlnX+LJ/QCf0STnWG9Vmdo4NNHjLLDv7DctkfO
	1xVS3UhQayGfmHhFNQ97DZXhqI6pYw==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="401630476"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 06:46:46 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S6kjZY011398; Thu, 28 Jun 2012 06:46:45 GMT
MIME-Version: 1.0
X-Mercurial-Node: 34e47ba2612efdf0b2d601e288de1ac5a406eb53
Message-Id: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 28 Jun 2012 06:46:18 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

All of the other "list" verbs are of the form "$noun-list". For
example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
Additionally, many people have well trained muscle memory from years
of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
in "command not implemented".

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
@@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
 int main_shutdown(int argc, char **argv);
 int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
-int main_list_vm(int argc, char **argv);
+int main_vm_list(int argc, char **argv);
 int main_create(int argc, char **argv);
 int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
@@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
     return 0;
 }
 
-int main_list_vm(int argc, char **argv)
+int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
@@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
-    { "list-vm",
-      &main_list_vm, 0, 0,
-      "List the VMs,without DOM0",
+    { "vm-list",
+      &main_vm_list, 0, 0,
+      "List the VMs, without DOM0",
       "",
     },
     { "info",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 06:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 06: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 1Sk8hO-000289-R0; Thu, 28 Jun 2012 06:59: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 1Sk8hN-000284-HP
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 06:59:29 +0000
Received: from [193.109.254.147:13948] by server-10.bemta-14.messagelabs.com
	id 39/B5-05433-0D00CEF4; Thu, 28 Jun 2012 06:59:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340866761!2132222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11487 invoked from network); 28 Jun 2012 06:59:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 06:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13259559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:59:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 07:59:16 +0100
Message-ID: <1340866756.5210.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 07:59:16 +0100
In-Reply-To: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> All of the other "list" verbs are of the form "$noun-list". For
> example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> Additionally, many people have well trained muscle memory from years
> of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> in "command not implemented".

Which did xm have list-vm or vm-list (or neither?) 

Aside: I'd love for someone to implement (for 4.3) a better error
message than "command not implemented". At the least printing out the
list of clashing options, or even git style "Did you mean" when you make
a typo.

> 
> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl.h
> --- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
> @@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
>  int main_shutdown(int argc, char **argv);
>  int main_reboot(int argc, char **argv);
>  int main_list(int argc, char **argv);
> -int main_list_vm(int argc, char **argv);
> +int main_vm_list(int argc, char **argv);
>  int main_create(int argc, char **argv);
>  int main_config_update(int argc, char **argv);
>  int main_button_press(int argc, char **argv);
> diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
>      return 0;
>  }
>  
> -int main_list_vm(int argc, char **argv)
> +int main_vm_list(int argc, char **argv)
>  {
>      int opt;
>  
> -    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
> +    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
>          return opt;
>  
>      list_vm();
> diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
>        "Set the number of active VCPUs allowed for the domain",
>        "<Domain> <vCPUs>",
>      },
> -    { "list-vm",
> -      &main_list_vm, 0, 0,
> -      "List the VMs,without DOM0",
> +    { "vm-list",
> +      &main_vm_list, 0, 0,
> +      "List the VMs, without DOM0",
>        "",
>      },
>      { "info",



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 06:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 06: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 1Sk8hO-000289-R0; Thu, 28 Jun 2012 06:59: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 1Sk8hN-000284-HP
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 06:59:29 +0000
Received: from [193.109.254.147:13948] by server-10.bemta-14.messagelabs.com
	id 39/B5-05433-0D00CEF4; Thu, 28 Jun 2012 06:59:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340866761!2132222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11487 invoked from network); 28 Jun 2012 06:59:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 06:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13259559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:59:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 07:59:16 +0100
Message-ID: <1340866756.5210.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 07:59:16 +0100
In-Reply-To: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> All of the other "list" verbs are of the form "$noun-list". For
> example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> Additionally, many people have well trained muscle memory from years
> of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> in "command not implemented".

Which did xm have list-vm or vm-list (or neither?) 

Aside: I'd love for someone to implement (for 4.3) a better error
message than "command not implemented". At the least printing out the
list of clashing options, or even git style "Did you mean" when you make
a typo.

> 
> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl.h
> --- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
> @@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
>  int main_shutdown(int argc, char **argv);
>  int main_reboot(int argc, char **argv);
>  int main_list(int argc, char **argv);
> -int main_list_vm(int argc, char **argv);
> +int main_vm_list(int argc, char **argv);
>  int main_create(int argc, char **argv);
>  int main_config_update(int argc, char **argv);
>  int main_button_press(int argc, char **argv);
> diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
>      return 0;
>  }
>  
> -int main_list_vm(int argc, char **argv)
> +int main_vm_list(int argc, char **argv)
>  {
>      int opt;
>  
> -    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
> +    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
>          return opt;
>  
>      list_vm();
> diff -r 32034d1914a6 -r 34e47ba2612e tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
>        "Set the number of active VCPUs allowed for the domain",
>        "<Domain> <vCPUs>",
>      },
> -    { "list-vm",
> -      &main_list_vm, 0, 0,
> -      "List the VMs,without DOM0",
> +    { "vm-list",
> +      &main_vm_list, 0, 0,
> +      "List the VMs, without DOM0",
>        "",
>      },
>      { "info",



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:05:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:05: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 1Sk8mq-0002dz-3S; Thu, 28 Jun 2012 07:05: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 1Sk8mo-0002dk-01
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 07:05:06 +0000
Received: from [85.158.139.83:44651] by server-9.bemta-5.messagelabs.com id
	AB/6A-01069-1220CEF4; Thu, 28 Jun 2012 07:05:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340867104!29362597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24492 invoked from network); 28 Jun 2012 07:05:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:05:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13259663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 07:05:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 08:05:03 +0100
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 1Sk8ml-00065w-Gq;
	Thu, 28 Jun 2012 07:05:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sk8ml-0002rL-85;
	Thu, 28 Jun 2012 08:05:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13379-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 08:05:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13379: 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 13379 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13379/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13376
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 13376 pass in 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13376 like 13373

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4f92bdf3370c
baseline version:
 xen                  4f92bdf3370c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:05:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:05: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 1Sk8mq-0002dz-3S; Thu, 28 Jun 2012 07:05: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 1Sk8mo-0002dk-01
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 07:05:06 +0000
Received: from [85.158.139.83:44651] by server-9.bemta-5.messagelabs.com id
	AB/6A-01069-1220CEF4; Thu, 28 Jun 2012 07:05:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340867104!29362597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24492 invoked from network); 28 Jun 2012 07:05:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:05:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13259663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 07:05:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 08:05:03 +0100
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 1Sk8ml-00065w-Gq;
	Thu, 28 Jun 2012 07:05:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Sk8ml-0002rL-85;
	Thu, 28 Jun 2012 08:05:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13379-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 08:05:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13379: 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 13379 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13379/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13376
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 13376 pass in 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13376 like 13373

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4f92bdf3370c
baseline version:
 xen                  4f92bdf3370c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07: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 1Sk96b-00030C-83; Thu, 28 Jun 2012 07:25:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Sk96Z-000307-Lo
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:25:32 +0000
Received: from [193.109.254.147:26269] by server-12.bemta-14.messagelabs.com
	id 2C/0F-30461-AE60CEF4; Thu, 28 Jun 2012 07:25:30 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340868328!3286759!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1123 invoked from network); 28 Jun 2012 07:25:29 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-27.messagelabs.com with SMTP;
	28 Jun 2012 07:25:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 00:25:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="163845070"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 28 Jun 2012 00:25:27 -0700
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; Thu, 28 Jun 2012 00:25:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 15:25:25 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Dario Faggioli <raistlin@linux.it>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
	placement of guests on NUMA nodes
Thread-Index: AQHNSxlR+Fwf5woVCUSe6XXnSjJ2Z5cPZo6A
Date: Thu, 28 Jun 2012 07:25:24 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
In-Reply-To: <81f18379bb3d4d9397d1.1339779876@Solace>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli wrote on 2012-06-16:
> If a domain does not have a VCPU affinity, try to pin it automatically
> to some PCPUs. This is done taking into account the NUMA characteristics
> of the host. In fact, we look for a combination of host's NUMA nodes
> with enough free memory and number of PCPUs for the new domain, and pin
> it to the VCPUs of those nodes.
> 
> Once we know which ones, among all the possible combinations, represents
> valid placement candidates for a domain, use some heuistics for deciding
> which is the best. For instance, smaller candidates are considered to be
> better, both from the domain's point of view (fewer memory spreading
> among nodes) and from the system as a whole point of view (fewer memoy
> fragmentation).  In case of candidates of equal sizes (i.e., with the
> same number of nodes), the one with the greater amount of memory wins,
> as this is also good for keeping memory fragmentation under control.
> 
> This all happens internally to libxl, and no API for driving the mechanism is
> provided for now. This matches what xend already does.
we should consider the basic IONUMA. I mean when a guest with a device assigned, 
from the point of view of performance, it's better to allocated the memory from the node 
which the device belongs to.
Furthermore, we need consider the guest NUMA(I am working on it now) and live migration.

Best regards,
Yang

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * This patches incorporates the changes from both "libxl, xl: enable automatic
>    placement of guests on NUMA nodes" and "libxl, xl: heuristics for
>    reordering NUMA placement candidates" from v1. * The logic of the
>    algorithm is basically the same as in v1, but the splitting of it in
>    the various functions has been completely redesigned from scratch. *
>    No public API for placement or candidate generation is now exposed,
>    everything happens within libxl, as agreed during v1 review. * The
>    relevant documentation have been moved near the actual functions and
>    features. Also, the amount and (hopefully!) the quality of the
>    documentation has been improved a lot, as requested. * All the
>    comments about using the proper libxl facilities and helpers for
>    allocations, etc., have been considered and applied. * This patch
>    still bails out from NUMA optimizations if it find out cpupools are
>    being utilized. It is next patch that makes the two things interact
>    properly, as suggested during review.
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -111,8 +111,8 @@ created online and the remainder will be
> 
>  =item B<cpus="CPU-LIST">
> -List of which cpus the guest is allowed to use. Default behavior is
> -`all cpus`. A C<CPU-LIST> may be specified as follows:
> +List of which cpus the guest is allowed to use. By default xl will (via
> +libxl) pick some cpus (see below). A C<CPU-LIST> may be specified as follows:
> 
>  =over 4
> @@ -132,6 +132,12 @@ run on cpu #3 of the host.
> 
>  =back
> +If this option is not specified, libxl automatically tries to place the
> new +domain on the host's NUMA nodes (provided the host has more than
> one NUMA +node) by pinning it to the cpus of those nodes. An heuristical
> approach is +utilized with the goals of maximizing performance for the
> domain and, at +the same time, achieving efficient utilization of the
> host's CPUs and RAM. +
>  =item B<cpu_weight=WEIGHT>
>  
>  A domain with a weight of 512 will get twice as much CPU as a domain
> 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
> @@ -95,6 +95,459 @@ out:
>      return sched;
>  }
> +/* + * What follows are helpers for generating all the k-combinations +
> * without repetitions of a set S with n elements in it. Formally + *
> speaking, they are subsets of k distinct elements of S and, if + * S is
> n elements big, the number of k-combinations is equal to + * the
> binomial coefficient (n k), which means we get exactly + * n!/(k! * (n -
> k)!) subsets, all of them with k elements. + * + * The various subset
> are geneated one after the other by calling + * comb_init() first, and,
> after that, comb_next() + * (n k)-1 times. An iterator is used to store
> the curent status + * of the whole generation operation (i.e.,
> basically, the last + * combination that has been generated). As soon as
> all + * combinations have been generated, comb_next() will + * start
> returning 0 instead of 1. It is of course impotant that + * the same
> instance of the iterator and the same values for + * n and k are used
> for each call. If that doesn't happen, the + * result is unspecified. +
> * + * The algorithm is a well known one, and it produces the + *
> combinations in such a way that they (well, more precisely, + * their
> indexes it the array/map representing the set) come in + * lexicogaphic
> order. + * + * For example, with n = 5 and k = 3, calling comb_init() +
> * will generate { 0, 1, 2 }, while subsequent valid calls to + *
> comb_next() will produce the following: + * { { 0, 1, 2 }, { 0, 1, 3 },
> { 0, 1, 4 }, + *   { 0, 2, 3 }, { 0, 2, 4 }, { 0, 3, 4 }, + *   { 1, 2,
> 3 }, { 1, 2, 4 }, { 1, 3, 4 }, + *   { 2, 3, 4 } } + * + * This is used
> by the automatic NUMA placement logic below. + */ +typedef int*
> comb_iter_t; + +static int comb_init(libxl__gc *gc, comb_iter_t *it, int
> n, int k) +{ +    comb_iter_t new_iter; +    int i; + +    if (n < k) + 
>       return 0; + +    /* First set is always { 0, 1, 2, ..., k-1 } */ +
>    GCNEW_ARRAY(new_iter, k); +    for (i = 0; i < k; i++) +       
> new_iter[i] = i; + +    *it = new_iter; +    return 1; +} + +static int
> comb_next(comb_iter_t it, int n, int k) +{ +    int i; + +    /* +     *
> The idea here is to find the leftmost element from where +     * we
> should start incrementing the indexes of the iterator. +     * This
> means looking for the highest index that can be increased +     * while
> still producing value smaller than n-1. In the example +     * above,
> when dealing with { 0, 1, 4 }, such an element is the +     * second
> one, as the third is already equal to 4 (which actually +     * is n-1).
> +     * Once we found from where to start, we increment that element +  
>   * and overide the right-hand rest of the iterator with its +     *
> successors, thus achieving lexicographic ordering. +     * +     *
> Regarding the termination of the generation process, when we +     *
> manage in bringing n-k at the very first position of the iterator, +    
> * we know that is the last valid combination ( { 2, 3, 4 }, with +     *
> n - k = 5 - 2 = 2, in the example above), and thus we start +     *
> returning 0 as soon as we cross that border. +     */ +    for (i = k -
> 1; it[i] == n - k + i; i--) { +        if (i <= 0) +            return
> 0; +    } +    for (it[i]++, i++; i < k; i++) +        it[i] = it[i - 1]
> + 1; +    return 1; +} + +/* NUMA automatic placement (see
> libxl_internal.h for details) */ + +/* + * This function turns a
> k-combination iterator into a node map. + * This means the bits in the
> node map corresponding to the indexes + * of the given combination are
> the ones that will be set. + * For example, if the iterator represents
> the combination { 0, 2, 4}, + * the node map will have bits #0, #2 and
> #4 set to one and i thus + * will point to node 0, node 2 and and node
> 4. + */ +static void comb_get_nodemap(comb_iter_t it, libxl_bitmap
> *nodemap, int k) +{ +    int i; + +    libxl_bitmap_set_none(nodemap); +
>    for (i = 0; i < k; i++) +        libxl_bitmap_set(nodemap, it[i]); +}
> + +/* Retrieve the number of cpus that the nodes that are part of the
> nodemap + * span. */ +static int nodemap_to_nodes_cpus(libxl_cputopology
> *tinfo, int nr_cpus, +                                 const
> libxl_bitmap *nodemap) +{ +    int i, nodes_cpus = 0; + +    for (i = 0;
> i < nr_cpus; i++) { +        if (libxl_bitmap_test(nodemap,
> tinfo[i].node)) +            nodes_cpus++; +    } +    return
> nodes_cpus; +} + +/* Retrieve the amount of free memory within the
> nodemap */ +static uint32_t nodemap_to_free_memkb(libxl_numainfo *ninfo,
> +                                      libxl_bitmap *nodemap) +{ +   
> uint32_t free_memkb = 0; +    int i; + +    libxl_for_each_set_bit(i,
> *nodemap) +        free_memkb += ninfo[i].free / 1024; + +    return
> free_memkb; +} + +/* Retrieve the number of domains that can potentially
> run on the cpus + * the nodes that are part of the nodemap. */ +static
> int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tinfo, +    
>                             const libxl_bitmap *nodemap) +{ +   
> libxl_dominfo *dinfo = NULL; +    libxl_bitmap dom_nodemap; +    int
> nr_doms, nr_cpus; +    int nr_domains = 0; +    int i, j, k; + +   
> dinfo = libxl_list_domain(CTX, &nr_doms); +    if (dinfo == NULL) +     
>   return ERROR_FAIL; + +    if (libxl_node_bitmap_alloc(CTX,
> &dom_nodemap) < 0) { +        nr_domains = ERROR_FAIL; +        goto
> out; +    } + +    for (i = 0; i < nr_doms; i++) { +       
> libxl_vcpuinfo *vinfo; +        int nr_vcpus; + +        vinfo =
> libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_cpus); +        if
> (vinfo == NULL) +            continue; + +       
> libxl_bitmap_set_none(&dom_nodemap); +        for (j = 0; j < nr_vcpus;
> j++) { +            libxl_for_each_set_bit(k, vinfo[j].cpumap) +        
>        libxl_bitmap_set(&dom_nodemap, tinfo[k].node); +        } + +    
>    libxl_for_each_set_bit(j, dom_nodemap) { +            if
> (libxl_bitmap_test(nodemap, j)) { +                nr_domains++; +      
>          goto found; +            } +        } + found: +       
> libxl_vcpuinfo_list_free(vinfo, nr_vcpus); +    } + + out: +   
> libxl_bitmap_dispose(&dom_nodemap); +    libxl_dominfo_list_free(dinfo,
> nr_doms); +    return nr_domains; +} + +/* + * This function tries to
> figure out if the host has a consistent number + * of cpus along all its
> NUMA nodes. In fact, if that is the case, we can + * calculate the
> minimum number of nodes needed for a domain by just + * dividing its
> total number of vcpus by this value computed here. + * However, we are
> not allowed to assume that all the nodes have the + * same number of
> cpus. Therefore, in case discrepancies among different + * nodes are
> found, this function just returns 0 and the caller needs + * to sort out
> things in some other way. + */ +static int
> cpus_per_node_count(libxl_cputopology *tinfo, int nr_cpus, +            
>                   libxl_numainfo *ninfo, int nr_nodes) +{ +    int
> cpus_per_node = 0; +    int j, i; + +    /* This makes sense iff # of
> PCPUs is the same for all nodes */ +    for (j = 0; j < nr_nodes; j++) {
> +        int curr_cpus = 0; + +        for (i = 0; i < nr_cpus; i++) { +
>            if (tinfo[i].node == j) +                curr_cpus++; +      
>  } +        /* So, if the above does not hold, turn the whole thing off!
> */ +        cpus_per_node = cpus_per_node == 0 ? curr_cpus :
> cpus_per_node; +        if (cpus_per_node != curr_cpus) +           
> return 0; +    } +    return cpus_per_node; +} + +/* Get all the
> placement candidates satisfying some specific conditions */ +int
> libxl__get_numa_candidates(libxl__gc *gc, +                             
>  uint32_t min_free_memkb, int min_cpus, +                              
> int min_nodes, int max_nodes, +                              
> libxl__numa_candidate *cndts[], int *nr_cndts) +{ +   
> libxl__numa_candidate *new_cndts = NULL; +    libxl_cputopology *tinfo =
> NULL; +    libxl_numainfo *ninfo = NULL; +    libxl_bitmap nodemap; +   
> int nr_nodes, nr_cpus; +    int array_size, rc; + +    /* Get platform
> info and prepare the map for testing the combinations */ +    ninfo =
> libxl_get_numainfo(CTX, &nr_nodes); +    if (ninfo == NULL) +       
> return ERROR_FAIL; +    /* If we don't have at least 2 nodes, it is
> useless to proceed */ +    if (nr_nodes < 2) { +        rc = 0; +       
> goto out; +    } + +    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus); +
>    if (tinfo == NULL) { +        rc = ERROR_FAIL; +        goto out; +  
>  } + +    rc = libxl_node_bitmap_alloc(CTX, &nodemap); +    if (rc) +   
>     goto out; + +    /* +     * Round up and down some of the
> constraints. For instance, the minimum +     * number of cpus a
> candidate should have must at least be non-negative. +     * Regarding
> the minimum number of NUMA nodes, if 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 +     * from 1 otherwise). The maximum number of nodes should not
> exceed the +     * number of existent NUMA nodes on the host, or the
> candidate genaration +     * won't work properly. +     */ +    min_cpus
> = min_cpus <= 0 ? 0 : min_cpus; +    if (min_nodes <= 0) { +        int
> cpus_per_node; + +        cpus_per_node = cpus_per_node_count(tinfo,
> nr_cpus, ninfo, nr_nodes); +        if (cpus_per_node == 0) +           
> min_nodes = 1; +        else +            min_nodes = (min_cpus +
> cpus_per_node - 1) / cpus_per_node; +    } +    min_nodes = min_nodes >
> nr_nodes ? nr_nodes : min_nodes; +    if (max_nodes <= 0) +       
> max_nodes = nr_nodes; +    else +        max_nodes = max_nodes >
> nr_nodes ? nr_nodes : max_nodes; +    if (min_nodes > max_nodes) { +    
>    rc = ERROR_INVAL; +        goto out; +    } + +    /* Initialize the
> local storage for the combinations */ +    *nr_cndts = 0; +   
> array_size = nr_nodes; +    GCNEW_ARRAY(new_cndts, array_size); + +   
> /* Generate all the combinations of any size from min_nodes to +     *
> max_nodes (see comb_init() and comb_next()). */ +    while (min_nodes <=
> max_nodes) { +        comb_iter_t comb_iter; +        int comb_ok; + +  
>      /* +	 * And here it is. Each step of this cycle generates a
> combination of +	 * nodes as big as min_nodes mandates.  Each of these
> combinations is +	 * checked against the constraints provided by the
> caller (namely, +	 * amount of free memory and number of cpus) and it
> becomes an actual +	 * placement candidate iff it passes the check. +   
>      */ +        for (comb_ok = comb_init(gc, &comb_iter, nr_nodes,
> min_nodes); comb_ok; +             comb_ok = comb_next(comb_iter,
> nr_nodes, min_nodes)) { +            uint32_t nodes_free_memkb; +       
>     int nodes_cpus; + +            comb_get_nodemap(comb_iter, &nodemap,
> min_nodes); + +            /* If there is not enough memoy in this
> combination, skip it +             * and go generating the next one...
> */ +            nodes_free_memkb = nodemap_to_free_memkb(ninfo,
> &nodemap); +            if (min_free_memkb > 0 && nodes_free_memkb <
> min_free_memkb) +                continue; + +            /* And the
> same applies if this combination is short in cpus */ +           
> nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap); +         
>   if (min_cpus > 0 && nodes_cpus < min_cpus) +                continue;
> + +            /* +             * Conditions are met, we can add this
> combination to the +             * NUMA placement candidates list. We
> first make sure there +             * is enough space in there, and then
> we initialize the new +             * candidate element with the node
> map corresponding to the +             * combination we are dealing
> with. Memory allocation for +             * expanding the array that
> hosts the list happens in chunks +             * equal to the number of
> NUMA nodes in the system (to +             * avoid allocating memory
> each and every time we find a +             * new candidate). +         
>    */ +            if (*nr_cndts == array_size) +               
> array_size += nr_nodes; +            GCREALLOC_ARRAY(new_cndts,
> array_size); + +            libxl__numa_candidate_alloc(gc,
> &new_cndts[*nr_cndts]); +           
> libxl__numa_candidate_put_nodemap(gc, &new_cndts[*nr_cndts], +          
>                                    &nodemap); +           
> new_cndts[*nr_cndts].nr_domains = +                                   
> nodemap_to_nr_domains(gc, tinfo, &nodemap); +           
> new_cndts[*nr_cndts].free_memkb = nodes_free_memkb; +           
> new_cndts[*nr_cndts].nr_nodes = min_nodes; +           
> new_cndts[*nr_cndts].nr_cpus = nodes_cpus; + +            LOG(DEBUG,
> "NUMA placement candidate #%d found: nr_nodes=%d, " +                   
>    "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts, +                     
>  min_nodes, new_cndts[*nr_cndts].nr_cpus, +                      
> new_cndts[*nr_cndts].free_memkb / 1024); + +            (*nr_cndts)++; +
>        } +        min_nodes++; +    } + +    *cndts = new_cndts; + out:
> +    libxl_bitmap_dispose(&nodemap); +   
> libxl_cputopology_list_free(tinfo, nr_cpus); +   
> libxl_numainfo_list_free(ninfo, nr_nodes); +    return rc; +} + +void
> libxl__sort_numa_candidates(libxl__numa_candidate cndts[], int nr_cndts,
> +                                 libxl__numa_candidate_cmpf cmpf) +{ + 
>   /* Reorder candidates (see the comparison function for +     * the
> details on the heuristics) */ +    qsort(cndts, nr_cndts,
> sizeof(cndts[0]), cmpf); +} + +/* + * The NUMA placement candidates are
> reordered according to the following + * heuristics: + *  - candidates
> involving fewer nodes come first. In case two (or + *    more)
> candidates span the same number of nodes, + *  - candidates with greater
> amount of free memory come first. In + *    case two (or more)
> candidates differ in their amount of free + *    memory by less than
> 10%, + *  - candidates with fewer domains insisting on them at the time
> of + *    this call come first. + */ +static int numa_cmpf(const void
> *v1, const void *v2) +{ +    const libxl__numa_candidate *c1 = (const
> libxl__numa_candidate*) v1; +    const libxl__numa_candidate *c2 =
> (const libxl__numa_candidate*) v2; +    double mem_diff =
> labs(c1->free_memkb - c2->free_memkb); +    double mem_avg =
> (c1->free_memkb + c2->free_memkb) / 2.0; + +    if (c1->nr_nodes !=
> c2->nr_nodes) +        return c1->nr_nodes - c2->nr_nodes; + +    if
> ((mem_diff / mem_avg) * 100.0 < 10.0 && +        c1->nr_domains !=
> c2->nr_domains) +        return c1->nr_domains - c2->nr_domains; + +   
> return c2->free_memkb - c1->free_memkb; +} + +/* The actual automatic
> NUMA placement routine */ +static int numa_place_domain(libxl__gc *gc,
> libxl_domain_build_info *info) +{ +    int nr_candidates = 0; +   
> libxl__numa_candidate *candidates = NULL; +    libxl_bitmap
> candidate_nodemap; +    libxl_cpupoolinfo *pinfo; +    int nr_pools, rc
> = 0; +    uint32_t memkb; + +    /* First of all, if cpupools are in
> use, better not to mess with them */ +    pinfo =
> libxl_list_cpupool(CTX, &nr_pools); +    if (!pinfo) +        return
> ERROR_FAIL; +    if (nr_pools > 1) { +        LOG(NOTICE, "skipping NUMA
> placement as cpupools are in use"); +        goto out; +    } + +    rc
> = libxl_domain_need_memory(CTX, info, &memkb); +    if (rc) +       
> goto out; +    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) { +
>        rc = ERROR_FAIL; +        goto out; +    } + +    /* Find all the
> candidates with enough free memory and at least +     * as much pcpus as
> the domain has vcpus.  */ +    rc = libxl__get_numa_candidates(gc,
> memkb, info->max_vcpus, 0, 0, +                                   
> &candidates, &nr_candidates); +    if (rc) +        goto out; + +   
> LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates); + +   
> /* No suitable placement candidates. We just return without touching the
> +     * domain's info->cpumap. It will have affinity with all
> nodes/cpus. */ +    if (nr_candidates == 0) +        goto out; + +    /*
> Bring the best candidate in front of the list --> candidates[0] */ +   
> if (nr_candidates > 1) +        libxl__sort_numa_candidates(candidates,
> nr_candidates, numa_cmpf); + +    /* +     * At this point, the first
> candidate in the array is the one we want. +     * Go for it by mapping
> its node map to the domain's info->cpumap. +     */ +   
> libxl__numa_candidate_get_nodemap(gc, &candidates[0],
> &candidate_nodemap); +    rc = libxl_nodemap_to_cpumap(CTX,
> &candidate_nodemap, &info->cpumap); +    if (rc) +        goto out; + + 
>   LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and " +  
>              "%"PRIu32" KB free selected", candidates[0].nr_nodes, +    
>            candidates[0].nr_cpus, candidates[0].free_memkb / 1024); + +
> out: +    libxl_bitmap_dispose(&candidate_nodemap); +   
> libxl_cpupoolinfo_list_free(pinfo, nr_pools); +    return rc; +} +
>  int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>                libxl_domain_build_info *info, libxl__domain_build_state
> *state)
>  {
> @@ -104,7 +557,22 @@ int libxl__build_pre(libxl__gc *gc, uint
>      uint32_t rtc_timeoffset;
>      
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +
> +    /*
> +     * 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 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,
> +     * whatever that turns out to be.
> +     */
> +    if (libxl_bitmap_is_full(&info->cpumap)) {
> +        int rc = numa_place_domain(gc, info);
> +        if (rc)
> +            return rc;
> +    }
>      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,
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
>  #define CTX_LOCK (libxl__ctx_lock(CTX))
>  #define CTX_UNLOCK (libxl__ctx_unlock(CTX))
> +/* + * Automatic NUMA placement + * + * These functions and data
> structures deal with the initial placement of a + * domain onto the host
> NUMA nodes. + * + * The key concept here is the one of "numa placement
> candidate" (or jusr "numa + * candidate", "placement candidate" or even
> "candidate"), which basically is a + * set of nodes whose
> characteristics have been successfully checked against + * some specific
> requirements. More pecisely, a candidate is the nodemap + * associated
> with one of the possible subset of the host NUMA nodes providing + * a
> certain amount of free memory, or a given number of cpus, or even both +
> * (depending in what the caller wants). For convenience of use, some of
> this + * information are stored within the candidate itselfs, instead of
> always being + * dynamically computed. A candidate can consist of just
> one, up to all the + * available nodes on the host (the latter being, of
> course, not ideal).  For + * instance, looking for a numa candidates
> with 2GB of free memoy means we want + * all the possible subsets of the
> host NUMA nodes with, cumulatively, at least + * 2GB of free memory.
> That could be possible by just using one particular + * node, or may
> require more nodes, depending on the characteristics of the + * host, on
> how many domains have been created already, on how big they are, + *
> etc. + * + * The intended usage is as follows: + *  1. by, fist of all,
> calling libxl__get_numa_candidates(), and specifying + *     the proper
> constraints to it (e.g., the amount of memory a domain need + *     as
> the minimum amount of free memory fo the candidates) one can build + *  
>   up a whole set of suitable placing alternatives for a domain; + *  2.
> after that, one specific candidate should be chosen. That can happen + *
>     by looking at their various characteristics; + *  3. the chosen
> candidate's nodemap should be utilized for computing the + *     actual
> affinity of the domain which, given the curent NUMA support + *     in
> the hypervisor, is what determines the placement of the domain's + *    
> vcpus and memory. + * + * To make phase 2 even easier, a sorting helper
> function for the list of + * candidates is povided in the form of
> libxl__sort_numa_candidates(). The only + * that is needed is defining a
> comparison function, containing the chriteria + * for deciding, given
> two candidates, which one is 'better'. Depending on how + * the
> comparison function is defined, the best candidate (where, of course, +
> * best is defined with respect to the heuristics implemented in the
> comparison + * function itself, libxl__numa_candidate_cmpf()) could
> become the first o the + * last element of the list. + * + *
> Summarizing, achieving automatic NUMA placement is just a matter of + *
> obtaining the list of suitable placement candidates, perhaps asking for
> each + * of them to provide at least the amount of memory the domain
> needs. After + * that just implement a comparison function by means of
> the various helpers + * retrieving the relevant information about the
> candidates themselves. + * Finally, call the sorting helper function and
> use the candidate that became + * (typically) the first element of the
> list fo determining the domain's + * affinity. + */ + +typedef struct {
> +    int nr_cpus, nr_nodes; +    int nr_domains; +    uint32_t
> free_memkb; +    libxl_bitmap nodemap; +} libxl__numa_candidate; + +/* +
> * This generates the list of NUMA placement candidates satisfying some +
> * specific conditions. If min_nodes and/or max_nodes are not 0, their
> value is + * used to determine the minimum and maximum number of nodes
> that are allow to + * be present in each candidate. If min_nodes and/or
> max_nodes are 0, the + * minimum and maximum number of nodes to be used
> are automatically selected by + * the implementation (and that will
> likely be just 1 node for the minimum and + * the total number of
> existent nodes for the maximum). Re min_free_memkb and + * min_cpu, if
> not 0, they specify the caller only wants candidates with at + * least
> that amount of free memory and that number of cpus, respectively. If + *
> min_free_memkb and/or min_cpus are 0, the candidates' free memory and
> number + * of cpus won't be checked at all, which means a candidate will
> always be + * considered suitable wrt the specific constraint.  cndts is
> where the list of + * exactly nr_cndts candidates is returned. Note
> that, in case no candidates + * are found at all, the function returns
> successfully, but with nr_cndts equal + * to zero. + */ +_hidden int
> libxl__get_numa_candidates(libxl__gc *gc, +                             
>   uint32_t min_free_memkb, int min_cpus, +                              
>  int min_nodes, int max_nodes, +                               
> libxl__numa_candidate *cndts[], int *nr_cndts); + +/* allocation and
> deallocation for placement candidates */ +static inline int
> libxl__numa_candidate_alloc(libxl__gc *gc, +                            
>                  libxl__numa_candidate *cndt) +{ +    return
> libxl_node_bitmap_alloc(CTX, &cndt->nodemap); +} +static inline void
> libxl__numa_candidate_dispose(libxl__numa_candidate *cndt) +{ +   
> libxl_bitmap_dispose(&cndt->nodemap); +} +static inline void
> libxl__numacandidate_list_free(libxl__numa_candidate *cndts, +          
>                                        int nr_cndts) +{ +    int i; + + 
>   for (i = 0; i < nr_cndts; i++) +       
> libxl__numa_candidate_dispose(&cndts[i]); +    free(cndts); +} + +/*
> retrieve (in nodemap) the node map associated to placement candidate
> cndt */ +static inline +void libxl__numa_candidate_get_nodemap(libxl__gc
> *gc, +                                       const libxl__numa_candidate
> *cndt, +                                       libxl_bitmap *nodemap) +{
> +    libxl_bitmap_copy(CTX, nodemap, &cndt->nodemap); +} +/* set the
> node map of placement candidate cndt to match nodemap */ +static inline
> +void libxl__numa_candidate_put_nodemap(libxl__gc *gc, +                
>                       libxl__numa_candidate *cndt, +                    
>                   const libxl_bitmap *nodemap) +{ +   
> libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap); +} + +/* signature for
> the comparison function between two candidates c1 and c2 + * (the thid
> parameter is provided to enable thread safety). */ +typedef int
> (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2); +/* sort
> the list of candidates in cndts (an array with nr_cndts elements in + *
> it) using cmpf for comparing two candidates. Uses libc's qsort(). */
> +_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
> +                                         int nr_cndts, +               
>                          libxl__numa_candidate_cmpf cmpf);
> 
>  /*
>   * Inserts "elm_new" into the sorted list "head".
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 07:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07: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 1Sk96b-00030C-83; Thu, 28 Jun 2012 07:25:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Sk96Z-000307-Lo
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:25:32 +0000
Received: from [193.109.254.147:26269] by server-12.bemta-14.messagelabs.com
	id 2C/0F-30461-AE60CEF4; Thu, 28 Jun 2012 07:25:30 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340868328!3286759!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1123 invoked from network); 28 Jun 2012 07:25:29 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-27.messagelabs.com with SMTP;
	28 Jun 2012 07:25:29 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 00:25:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="163845070"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 28 Jun 2012 00:25:27 -0700
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; Thu, 28 Jun 2012 00:25:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 15:25:25 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Dario Faggioli <raistlin@linux.it>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
	placement of guests on NUMA nodes
Thread-Index: AQHNSxlR+Fwf5woVCUSe6XXnSjJ2Z5cPZo6A
Date: Thu, 28 Jun 2012 07:25:24 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
In-Reply-To: <81f18379bb3d4d9397d1.1339779876@Solace>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli wrote on 2012-06-16:
> If a domain does not have a VCPU affinity, try to pin it automatically
> to some PCPUs. This is done taking into account the NUMA characteristics
> of the host. In fact, we look for a combination of host's NUMA nodes
> with enough free memory and number of PCPUs for the new domain, and pin
> it to the VCPUs of those nodes.
> 
> Once we know which ones, among all the possible combinations, represents
> valid placement candidates for a domain, use some heuistics for deciding
> which is the best. For instance, smaller candidates are considered to be
> better, both from the domain's point of view (fewer memory spreading
> among nodes) and from the system as a whole point of view (fewer memoy
> fragmentation).  In case of candidates of equal sizes (i.e., with the
> same number of nodes), the one with the greater amount of memory wins,
> as this is also good for keeping memory fragmentation under control.
> 
> This all happens internally to libxl, and no API for driving the mechanism is
> provided for now. This matches what xend already does.
we should consider the basic IONUMA. I mean when a guest with a device assigned, 
from the point of view of performance, it's better to allocated the memory from the node 
which the device belongs to.
Furthermore, we need consider the guest NUMA(I am working on it now) and live migration.

Best regards,
Yang

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Changes from v1:
>  * This patches incorporates the changes from both "libxl, xl: enable automatic
>    placement of guests on NUMA nodes" and "libxl, xl: heuristics for
>    reordering NUMA placement candidates" from v1. * The logic of the
>    algorithm is basically the same as in v1, but the splitting of it in
>    the various functions has been completely redesigned from scratch. *
>    No public API for placement or candidate generation is now exposed,
>    everything happens within libxl, as agreed during v1 review. * The
>    relevant documentation have been moved near the actual functions and
>    features. Also, the amount and (hopefully!) the quality of the
>    documentation has been improved a lot, as requested. * All the
>    comments about using the proper libxl facilities and helpers for
>    allocations, etc., have been considered and applied. * This patch
>    still bails out from NUMA optimizations if it find out cpupools are
>    being utilized. It is next patch that makes the two things interact
>    properly, as suggested during review.
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -111,8 +111,8 @@ created online and the remainder will be
> 
>  =item B<cpus="CPU-LIST">
> -List of which cpus the guest is allowed to use. Default behavior is
> -`all cpus`. A C<CPU-LIST> may be specified as follows:
> +List of which cpus the guest is allowed to use. By default xl will (via
> +libxl) pick some cpus (see below). A C<CPU-LIST> may be specified as follows:
> 
>  =over 4
> @@ -132,6 +132,12 @@ run on cpu #3 of the host.
> 
>  =back
> +If this option is not specified, libxl automatically tries to place the
> new +domain on the host's NUMA nodes (provided the host has more than
> one NUMA +node) by pinning it to the cpus of those nodes. An heuristical
> approach is +utilized with the goals of maximizing performance for the
> domain and, at +the same time, achieving efficient utilization of the
> host's CPUs and RAM. +
>  =item B<cpu_weight=WEIGHT>
>  
>  A domain with a weight of 512 will get twice as much CPU as a domain
> 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
> @@ -95,6 +95,459 @@ out:
>      return sched;
>  }
> +/* + * What follows are helpers for generating all the k-combinations +
> * without repetitions of a set S with n elements in it. Formally + *
> speaking, they are subsets of k distinct elements of S and, if + * S is
> n elements big, the number of k-combinations is equal to + * the
> binomial coefficient (n k), which means we get exactly + * n!/(k! * (n -
> k)!) subsets, all of them with k elements. + * + * The various subset
> are geneated one after the other by calling + * comb_init() first, and,
> after that, comb_next() + * (n k)-1 times. An iterator is used to store
> the curent status + * of the whole generation operation (i.e.,
> basically, the last + * combination that has been generated). As soon as
> all + * combinations have been generated, comb_next() will + * start
> returning 0 instead of 1. It is of course impotant that + * the same
> instance of the iterator and the same values for + * n and k are used
> for each call. If that doesn't happen, the + * result is unspecified. +
> * + * The algorithm is a well known one, and it produces the + *
> combinations in such a way that they (well, more precisely, + * their
> indexes it the array/map representing the set) come in + * lexicogaphic
> order. + * + * For example, with n = 5 and k = 3, calling comb_init() +
> * will generate { 0, 1, 2 }, while subsequent valid calls to + *
> comb_next() will produce the following: + * { { 0, 1, 2 }, { 0, 1, 3 },
> { 0, 1, 4 }, + *   { 0, 2, 3 }, { 0, 2, 4 }, { 0, 3, 4 }, + *   { 1, 2,
> 3 }, { 1, 2, 4 }, { 1, 3, 4 }, + *   { 2, 3, 4 } } + * + * This is used
> by the automatic NUMA placement logic below. + */ +typedef int*
> comb_iter_t; + +static int comb_init(libxl__gc *gc, comb_iter_t *it, int
> n, int k) +{ +    comb_iter_t new_iter; +    int i; + +    if (n < k) + 
>       return 0; + +    /* First set is always { 0, 1, 2, ..., k-1 } */ +
>    GCNEW_ARRAY(new_iter, k); +    for (i = 0; i < k; i++) +       
> new_iter[i] = i; + +    *it = new_iter; +    return 1; +} + +static int
> comb_next(comb_iter_t it, int n, int k) +{ +    int i; + +    /* +     *
> The idea here is to find the leftmost element from where +     * we
> should start incrementing the indexes of the iterator. +     * This
> means looking for the highest index that can be increased +     * while
> still producing value smaller than n-1. In the example +     * above,
> when dealing with { 0, 1, 4 }, such an element is the +     * second
> one, as the third is already equal to 4 (which actually +     * is n-1).
> +     * Once we found from where to start, we increment that element +  
>   * and overide the right-hand rest of the iterator with its +     *
> successors, thus achieving lexicographic ordering. +     * +     *
> Regarding the termination of the generation process, when we +     *
> manage in bringing n-k at the very first position of the iterator, +    
> * we know that is the last valid combination ( { 2, 3, 4 }, with +     *
> n - k = 5 - 2 = 2, in the example above), and thus we start +     *
> returning 0 as soon as we cross that border. +     */ +    for (i = k -
> 1; it[i] == n - k + i; i--) { +        if (i <= 0) +            return
> 0; +    } +    for (it[i]++, i++; i < k; i++) +        it[i] = it[i - 1]
> + 1; +    return 1; +} + +/* NUMA automatic placement (see
> libxl_internal.h for details) */ + +/* + * This function turns a
> k-combination iterator into a node map. + * This means the bits in the
> node map corresponding to the indexes + * of the given combination are
> the ones that will be set. + * For example, if the iterator represents
> the combination { 0, 2, 4}, + * the node map will have bits #0, #2 and
> #4 set to one and i thus + * will point to node 0, node 2 and and node
> 4. + */ +static void comb_get_nodemap(comb_iter_t it, libxl_bitmap
> *nodemap, int k) +{ +    int i; + +    libxl_bitmap_set_none(nodemap); +
>    for (i = 0; i < k; i++) +        libxl_bitmap_set(nodemap, it[i]); +}
> + +/* Retrieve the number of cpus that the nodes that are part of the
> nodemap + * span. */ +static int nodemap_to_nodes_cpus(libxl_cputopology
> *tinfo, int nr_cpus, +                                 const
> libxl_bitmap *nodemap) +{ +    int i, nodes_cpus = 0; + +    for (i = 0;
> i < nr_cpus; i++) { +        if (libxl_bitmap_test(nodemap,
> tinfo[i].node)) +            nodes_cpus++; +    } +    return
> nodes_cpus; +} + +/* Retrieve the amount of free memory within the
> nodemap */ +static uint32_t nodemap_to_free_memkb(libxl_numainfo *ninfo,
> +                                      libxl_bitmap *nodemap) +{ +   
> uint32_t free_memkb = 0; +    int i; + +    libxl_for_each_set_bit(i,
> *nodemap) +        free_memkb += ninfo[i].free / 1024; + +    return
> free_memkb; +} + +/* Retrieve the number of domains that can potentially
> run on the cpus + * the nodes that are part of the nodemap. */ +static
> int nodemap_to_nr_domains(libxl__gc *gc, libxl_cputopology *tinfo, +    
>                             const libxl_bitmap *nodemap) +{ +   
> libxl_dominfo *dinfo = NULL; +    libxl_bitmap dom_nodemap; +    int
> nr_doms, nr_cpus; +    int nr_domains = 0; +    int i, j, k; + +   
> dinfo = libxl_list_domain(CTX, &nr_doms); +    if (dinfo == NULL) +     
>   return ERROR_FAIL; + +    if (libxl_node_bitmap_alloc(CTX,
> &dom_nodemap) < 0) { +        nr_domains = ERROR_FAIL; +        goto
> out; +    } + +    for (i = 0; i < nr_doms; i++) { +       
> libxl_vcpuinfo *vinfo; +        int nr_vcpus; + +        vinfo =
> libxl_list_vcpu(CTX, dinfo[i].domid, &nr_vcpus, &nr_cpus); +        if
> (vinfo == NULL) +            continue; + +       
> libxl_bitmap_set_none(&dom_nodemap); +        for (j = 0; j < nr_vcpus;
> j++) { +            libxl_for_each_set_bit(k, vinfo[j].cpumap) +        
>        libxl_bitmap_set(&dom_nodemap, tinfo[k].node); +        } + +    
>    libxl_for_each_set_bit(j, dom_nodemap) { +            if
> (libxl_bitmap_test(nodemap, j)) { +                nr_domains++; +      
>          goto found; +            } +        } + found: +       
> libxl_vcpuinfo_list_free(vinfo, nr_vcpus); +    } + + out: +   
> libxl_bitmap_dispose(&dom_nodemap); +    libxl_dominfo_list_free(dinfo,
> nr_doms); +    return nr_domains; +} + +/* + * This function tries to
> figure out if the host has a consistent number + * of cpus along all its
> NUMA nodes. In fact, if that is the case, we can + * calculate the
> minimum number of nodes needed for a domain by just + * dividing its
> total number of vcpus by this value computed here. + * However, we are
> not allowed to assume that all the nodes have the + * same number of
> cpus. Therefore, in case discrepancies among different + * nodes are
> found, this function just returns 0 and the caller needs + * to sort out
> things in some other way. + */ +static int
> cpus_per_node_count(libxl_cputopology *tinfo, int nr_cpus, +            
>                   libxl_numainfo *ninfo, int nr_nodes) +{ +    int
> cpus_per_node = 0; +    int j, i; + +    /* This makes sense iff # of
> PCPUs is the same for all nodes */ +    for (j = 0; j < nr_nodes; j++) {
> +        int curr_cpus = 0; + +        for (i = 0; i < nr_cpus; i++) { +
>            if (tinfo[i].node == j) +                curr_cpus++; +      
>  } +        /* So, if the above does not hold, turn the whole thing off!
> */ +        cpus_per_node = cpus_per_node == 0 ? curr_cpus :
> cpus_per_node; +        if (cpus_per_node != curr_cpus) +           
> return 0; +    } +    return cpus_per_node; +} + +/* Get all the
> placement candidates satisfying some specific conditions */ +int
> libxl__get_numa_candidates(libxl__gc *gc, +                             
>  uint32_t min_free_memkb, int min_cpus, +                              
> int min_nodes, int max_nodes, +                              
> libxl__numa_candidate *cndts[], int *nr_cndts) +{ +   
> libxl__numa_candidate *new_cndts = NULL; +    libxl_cputopology *tinfo =
> NULL; +    libxl_numainfo *ninfo = NULL; +    libxl_bitmap nodemap; +   
> int nr_nodes, nr_cpus; +    int array_size, rc; + +    /* Get platform
> info and prepare the map for testing the combinations */ +    ninfo =
> libxl_get_numainfo(CTX, &nr_nodes); +    if (ninfo == NULL) +       
> return ERROR_FAIL; +    /* If we don't have at least 2 nodes, it is
> useless to proceed */ +    if (nr_nodes < 2) { +        rc = 0; +       
> goto out; +    } + +    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus); +
>    if (tinfo == NULL) { +        rc = ERROR_FAIL; +        goto out; +  
>  } + +    rc = libxl_node_bitmap_alloc(CTX, &nodemap); +    if (rc) +   
>     goto out; + +    /* +     * Round up and down some of the
> constraints. For instance, the minimum +     * number of cpus a
> candidate should have must at least be non-negative. +     * Regarding
> the minimum number of NUMA nodes, if 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 +     * from 1 otherwise). The maximum number of nodes should not
> exceed the +     * number of existent NUMA nodes on the host, or the
> candidate genaration +     * won't work properly. +     */ +    min_cpus
> = min_cpus <= 0 ? 0 : min_cpus; +    if (min_nodes <= 0) { +        int
> cpus_per_node; + +        cpus_per_node = cpus_per_node_count(tinfo,
> nr_cpus, ninfo, nr_nodes); +        if (cpus_per_node == 0) +           
> min_nodes = 1; +        else +            min_nodes = (min_cpus +
> cpus_per_node - 1) / cpus_per_node; +    } +    min_nodes = min_nodes >
> nr_nodes ? nr_nodes : min_nodes; +    if (max_nodes <= 0) +       
> max_nodes = nr_nodes; +    else +        max_nodes = max_nodes >
> nr_nodes ? nr_nodes : max_nodes; +    if (min_nodes > max_nodes) { +    
>    rc = ERROR_INVAL; +        goto out; +    } + +    /* Initialize the
> local storage for the combinations */ +    *nr_cndts = 0; +   
> array_size = nr_nodes; +    GCNEW_ARRAY(new_cndts, array_size); + +   
> /* Generate all the combinations of any size from min_nodes to +     *
> max_nodes (see comb_init() and comb_next()). */ +    while (min_nodes <=
> max_nodes) { +        comb_iter_t comb_iter; +        int comb_ok; + +  
>      /* +	 * And here it is. Each step of this cycle generates a
> combination of +	 * nodes as big as min_nodes mandates.  Each of these
> combinations is +	 * checked against the constraints provided by the
> caller (namely, +	 * amount of free memory and number of cpus) and it
> becomes an actual +	 * placement candidate iff it passes the check. +   
>      */ +        for (comb_ok = comb_init(gc, &comb_iter, nr_nodes,
> min_nodes); comb_ok; +             comb_ok = comb_next(comb_iter,
> nr_nodes, min_nodes)) { +            uint32_t nodes_free_memkb; +       
>     int nodes_cpus; + +            comb_get_nodemap(comb_iter, &nodemap,
> min_nodes); + +            /* If there is not enough memoy in this
> combination, skip it +             * and go generating the next one...
> */ +            nodes_free_memkb = nodemap_to_free_memkb(ninfo,
> &nodemap); +            if (min_free_memkb > 0 && nodes_free_memkb <
> min_free_memkb) +                continue; + +            /* And the
> same applies if this combination is short in cpus */ +           
> nodes_cpus = nodemap_to_nodes_cpus(tinfo, nr_cpus, &nodemap); +         
>   if (min_cpus > 0 && nodes_cpus < min_cpus) +                continue;
> + +            /* +             * Conditions are met, we can add this
> combination to the +             * NUMA placement candidates list. We
> first make sure there +             * is enough space in there, and then
> we initialize the new +             * candidate element with the node
> map corresponding to the +             * combination we are dealing
> with. Memory allocation for +             * expanding the array that
> hosts the list happens in chunks +             * equal to the number of
> NUMA nodes in the system (to +             * avoid allocating memory
> each and every time we find a +             * new candidate). +         
>    */ +            if (*nr_cndts == array_size) +               
> array_size += nr_nodes; +            GCREALLOC_ARRAY(new_cndts,
> array_size); + +            libxl__numa_candidate_alloc(gc,
> &new_cndts[*nr_cndts]); +           
> libxl__numa_candidate_put_nodemap(gc, &new_cndts[*nr_cndts], +          
>                                    &nodemap); +           
> new_cndts[*nr_cndts].nr_domains = +                                   
> nodemap_to_nr_domains(gc, tinfo, &nodemap); +           
> new_cndts[*nr_cndts].free_memkb = nodes_free_memkb; +           
> new_cndts[*nr_cndts].nr_nodes = min_nodes; +           
> new_cndts[*nr_cndts].nr_cpus = nodes_cpus; + +            LOG(DEBUG,
> "NUMA placement candidate #%d found: nr_nodes=%d, " +                   
>    "nr_cpus=%d, free_memkb=%"PRIu32"", *nr_cndts, +                     
>  min_nodes, new_cndts[*nr_cndts].nr_cpus, +                      
> new_cndts[*nr_cndts].free_memkb / 1024); + +            (*nr_cndts)++; +
>        } +        min_nodes++; +    } + +    *cndts = new_cndts; + out:
> +    libxl_bitmap_dispose(&nodemap); +   
> libxl_cputopology_list_free(tinfo, nr_cpus); +   
> libxl_numainfo_list_free(ninfo, nr_nodes); +    return rc; +} + +void
> libxl__sort_numa_candidates(libxl__numa_candidate cndts[], int nr_cndts,
> +                                 libxl__numa_candidate_cmpf cmpf) +{ + 
>   /* Reorder candidates (see the comparison function for +     * the
> details on the heuristics) */ +    qsort(cndts, nr_cndts,
> sizeof(cndts[0]), cmpf); +} + +/* + * The NUMA placement candidates are
> reordered according to the following + * heuristics: + *  - candidates
> involving fewer nodes come first. In case two (or + *    more)
> candidates span the same number of nodes, + *  - candidates with greater
> amount of free memory come first. In + *    case two (or more)
> candidates differ in their amount of free + *    memory by less than
> 10%, + *  - candidates with fewer domains insisting on them at the time
> of + *    this call come first. + */ +static int numa_cmpf(const void
> *v1, const void *v2) +{ +    const libxl__numa_candidate *c1 = (const
> libxl__numa_candidate*) v1; +    const libxl__numa_candidate *c2 =
> (const libxl__numa_candidate*) v2; +    double mem_diff =
> labs(c1->free_memkb - c2->free_memkb); +    double mem_avg =
> (c1->free_memkb + c2->free_memkb) / 2.0; + +    if (c1->nr_nodes !=
> c2->nr_nodes) +        return c1->nr_nodes - c2->nr_nodes; + +    if
> ((mem_diff / mem_avg) * 100.0 < 10.0 && +        c1->nr_domains !=
> c2->nr_domains) +        return c1->nr_domains - c2->nr_domains; + +   
> return c2->free_memkb - c1->free_memkb; +} + +/* The actual automatic
> NUMA placement routine */ +static int numa_place_domain(libxl__gc *gc,
> libxl_domain_build_info *info) +{ +    int nr_candidates = 0; +   
> libxl__numa_candidate *candidates = NULL; +    libxl_bitmap
> candidate_nodemap; +    libxl_cpupoolinfo *pinfo; +    int nr_pools, rc
> = 0; +    uint32_t memkb; + +    /* First of all, if cpupools are in
> use, better not to mess with them */ +    pinfo =
> libxl_list_cpupool(CTX, &nr_pools); +    if (!pinfo) +        return
> ERROR_FAIL; +    if (nr_pools > 1) { +        LOG(NOTICE, "skipping NUMA
> placement as cpupools are in use"); +        goto out; +    } + +    rc
> = libxl_domain_need_memory(CTX, info, &memkb); +    if (rc) +       
> goto out; +    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap)) { +
>        rc = ERROR_FAIL; +        goto out; +    } + +    /* Find all the
> candidates with enough free memory and at least +     * as much pcpus as
> the domain has vcpus.  */ +    rc = libxl__get_numa_candidates(gc,
> memkb, info->max_vcpus, 0, 0, +                                   
> &candidates, &nr_candidates); +    if (rc) +        goto out; + +   
> LOG(DETAIL, "%d NUMA placement candidates found", nr_candidates); + +   
> /* No suitable placement candidates. We just return without touching the
> +     * domain's info->cpumap. It will have affinity with all
> nodes/cpus. */ +    if (nr_candidates == 0) +        goto out; + +    /*
> Bring the best candidate in front of the list --> candidates[0] */ +   
> if (nr_candidates > 1) +        libxl__sort_numa_candidates(candidates,
> nr_candidates, numa_cmpf); + +    /* +     * At this point, the first
> candidate in the array is the one we want. +     * Go for it by mapping
> its node map to the domain's info->cpumap. +     */ +   
> libxl__numa_candidate_get_nodemap(gc, &candidates[0],
> &candidate_nodemap); +    rc = libxl_nodemap_to_cpumap(CTX,
> &candidate_nodemap, &info->cpumap); +    if (rc) +        goto out; + + 
>   LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and " +  
>              "%"PRIu32" KB free selected", candidates[0].nr_nodes, +    
>            candidates[0].nr_cpus, candidates[0].free_memkb / 1024); + +
> out: +    libxl_bitmap_dispose(&candidate_nodemap); +   
> libxl_cpupoolinfo_list_free(pinfo, nr_pools); +    return rc; +} +
>  int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>                libxl_domain_build_info *info, libxl__domain_build_state
> *state)
>  {
> @@ -104,7 +557,22 @@ int libxl__build_pre(libxl__gc *gc, uint
>      uint32_t rtc_timeoffset;
>      
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +
> +    /*
> +     * 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 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,
> +     * whatever that turns out to be.
> +     */
> +    if (libxl_bitmap_is_full(&info->cpumap)) {
> +        int rc = numa_place_domain(gc, info);
> +        if (rc)
> +            return rc;
> +    }
>      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,
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2021,6 +2021,134 @@ static inline void libxl__ctx_unlock(lib
>  #define CTX_LOCK (libxl__ctx_lock(CTX))
>  #define CTX_UNLOCK (libxl__ctx_unlock(CTX))
> +/* + * Automatic NUMA placement + * + * These functions and data
> structures deal with the initial placement of a + * domain onto the host
> NUMA nodes. + * + * The key concept here is the one of "numa placement
> candidate" (or jusr "numa + * candidate", "placement candidate" or even
> "candidate"), which basically is a + * set of nodes whose
> characteristics have been successfully checked against + * some specific
> requirements. More pecisely, a candidate is the nodemap + * associated
> with one of the possible subset of the host NUMA nodes providing + * a
> certain amount of free memory, or a given number of cpus, or even both +
> * (depending in what the caller wants). For convenience of use, some of
> this + * information are stored within the candidate itselfs, instead of
> always being + * dynamically computed. A candidate can consist of just
> one, up to all the + * available nodes on the host (the latter being, of
> course, not ideal).  For + * instance, looking for a numa candidates
> with 2GB of free memoy means we want + * all the possible subsets of the
> host NUMA nodes with, cumulatively, at least + * 2GB of free memory.
> That could be possible by just using one particular + * node, or may
> require more nodes, depending on the characteristics of the + * host, on
> how many domains have been created already, on how big they are, + *
> etc. + * + * The intended usage is as follows: + *  1. by, fist of all,
> calling libxl__get_numa_candidates(), and specifying + *     the proper
> constraints to it (e.g., the amount of memory a domain need + *     as
> the minimum amount of free memory fo the candidates) one can build + *  
>   up a whole set of suitable placing alternatives for a domain; + *  2.
> after that, one specific candidate should be chosen. That can happen + *
>     by looking at their various characteristics; + *  3. the chosen
> candidate's nodemap should be utilized for computing the + *     actual
> affinity of the domain which, given the curent NUMA support + *     in
> the hypervisor, is what determines the placement of the domain's + *    
> vcpus and memory. + * + * To make phase 2 even easier, a sorting helper
> function for the list of + * candidates is povided in the form of
> libxl__sort_numa_candidates(). The only + * that is needed is defining a
> comparison function, containing the chriteria + * for deciding, given
> two candidates, which one is 'better'. Depending on how + * the
> comparison function is defined, the best candidate (where, of course, +
> * best is defined with respect to the heuristics implemented in the
> comparison + * function itself, libxl__numa_candidate_cmpf()) could
> become the first o the + * last element of the list. + * + *
> Summarizing, achieving automatic NUMA placement is just a matter of + *
> obtaining the list of suitable placement candidates, perhaps asking for
> each + * of them to provide at least the amount of memory the domain
> needs. After + * that just implement a comparison function by means of
> the various helpers + * retrieving the relevant information about the
> candidates themselves. + * Finally, call the sorting helper function and
> use the candidate that became + * (typically) the first element of the
> list fo determining the domain's + * affinity. + */ + +typedef struct {
> +    int nr_cpus, nr_nodes; +    int nr_domains; +    uint32_t
> free_memkb; +    libxl_bitmap nodemap; +} libxl__numa_candidate; + +/* +
> * This generates the list of NUMA placement candidates satisfying some +
> * specific conditions. If min_nodes and/or max_nodes are not 0, their
> value is + * used to determine the minimum and maximum number of nodes
> that are allow to + * be present in each candidate. If min_nodes and/or
> max_nodes are 0, the + * minimum and maximum number of nodes to be used
> are automatically selected by + * the implementation (and that will
> likely be just 1 node for the minimum and + * the total number of
> existent nodes for the maximum). Re min_free_memkb and + * min_cpu, if
> not 0, they specify the caller only wants candidates with at + * least
> that amount of free memory and that number of cpus, respectively. If + *
> min_free_memkb and/or min_cpus are 0, the candidates' free memory and
> number + * of cpus won't be checked at all, which means a candidate will
> always be + * considered suitable wrt the specific constraint.  cndts is
> where the list of + * exactly nr_cndts candidates is returned. Note
> that, in case no candidates + * are found at all, the function returns
> successfully, but with nr_cndts equal + * to zero. + */ +_hidden int
> libxl__get_numa_candidates(libxl__gc *gc, +                             
>   uint32_t min_free_memkb, int min_cpus, +                              
>  int min_nodes, int max_nodes, +                               
> libxl__numa_candidate *cndts[], int *nr_cndts); + +/* allocation and
> deallocation for placement candidates */ +static inline int
> libxl__numa_candidate_alloc(libxl__gc *gc, +                            
>                  libxl__numa_candidate *cndt) +{ +    return
> libxl_node_bitmap_alloc(CTX, &cndt->nodemap); +} +static inline void
> libxl__numa_candidate_dispose(libxl__numa_candidate *cndt) +{ +   
> libxl_bitmap_dispose(&cndt->nodemap); +} +static inline void
> libxl__numacandidate_list_free(libxl__numa_candidate *cndts, +          
>                                        int nr_cndts) +{ +    int i; + + 
>   for (i = 0; i < nr_cndts; i++) +       
> libxl__numa_candidate_dispose(&cndts[i]); +    free(cndts); +} + +/*
> retrieve (in nodemap) the node map associated to placement candidate
> cndt */ +static inline +void libxl__numa_candidate_get_nodemap(libxl__gc
> *gc, +                                       const libxl__numa_candidate
> *cndt, +                                       libxl_bitmap *nodemap) +{
> +    libxl_bitmap_copy(CTX, nodemap, &cndt->nodemap); +} +/* set the
> node map of placement candidate cndt to match nodemap */ +static inline
> +void libxl__numa_candidate_put_nodemap(libxl__gc *gc, +                
>                       libxl__numa_candidate *cndt, +                    
>                   const libxl_bitmap *nodemap) +{ +   
> libxl_bitmap_copy(CTX, &cndt->nodemap, nodemap); +} + +/* signature for
> the comparison function between two candidates c1 and c2 + * (the thid
> parameter is provided to enable thread safety). */ +typedef int
> (*libxl__numa_candidate_cmpf)(const void *v1, const void *v2); +/* sort
> the list of candidates in cndts (an array with nr_cndts elements in + *
> it) using cmpf for comparing two candidates. Uses libc's qsort(). */
> +_hidden void libxl__sort_numa_candidates(libxl__numa_candidate cndts[],
> +                                         int nr_cndts, +               
>                          libxl__numa_candidate_cmpf cmpf);
> 
>  /*
>   * Inserts "elm_new" into the sorted list "head".
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 07:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07: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 1Sk99O-00037Z-0X; Thu, 28 Jun 2012 07:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk99M-00037U-VR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:28:25 +0000
Received: from [85.158.138.51:11464] by server-10.bemta-3.messagelabs.com id
	86/86-01753-3970CEF4; Thu, 28 Jun 2012 07:28:19 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340868497!27038240!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzgwMzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8522 invoked from network); 28 Jun 2012 07:28:19 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:28:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340868499; x=1372404499;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=+XcrYj3RHBgu/kEVRDveBM1WKzjFYBw9r087ItuClZM=;
	b=ME8GgGcB6XBPbvkKNYqXCzHz0moyihCvNUGpT7q2DwpEAarJb6Ho+PyA
	cUHze4KTiVuL/r6rMfnml7pBZHXiyA==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="255254453"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 07:28:16 +0000
Received: from ex10-hub-36002.ant.amazon.com (ex10-hub-36002.sea32.amazon.com
	[10.250.1.7])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S7SFZ2013581
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 28 Jun 2012 07:28:15 GMT
Received: from US-SEA-R8XVZTX (10.224.80.43) by ex10-hub-36002.ant.amazon.com
	(10.250.1.7) with Microsoft SMTP Server id 14.2.247.3;
	Thu, 28 Jun 2012 00:28:11 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Thu, 28 Jun 2012
	00:28:10 -0700
Date: Thu, 28 Jun 2012 00:28:10 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628072810.GA9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340866756.5210.9.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Wed, Jun 27, 2012 at 11:59:16PM -0700, Ian Campbell wrote:
> On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > All of the other "list" verbs are of the form "$noun-list". For
> > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > Additionally, many people have well trained muscle memory from years
> > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > in "command not implemented".
> 
> Which did xm have list-vm or vm-list (or neither?) 

Neither.

> Aside: I'd love for someone to implement (for 4.3) a better error
> message than "command not implemented". At the least printing out the
> list of clashing options, or even git style "Did you mean" when you make
> a typo.

That would definitely be nice to have.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07: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 1Sk99O-00037Z-0X; Thu, 28 Jun 2012 07:28:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk99M-00037U-VR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:28:25 +0000
Received: from [85.158.138.51:11464] by server-10.bemta-3.messagelabs.com id
	86/86-01753-3970CEF4; Thu, 28 Jun 2012 07:28:19 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340868497!27038240!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gMzgwMzA=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8522 invoked from network); 28 Jun 2012 07:28:19 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:28:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340868499; x=1372404499;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=+XcrYj3RHBgu/kEVRDveBM1WKzjFYBw9r087ItuClZM=;
	b=ME8GgGcB6XBPbvkKNYqXCzHz0moyihCvNUGpT7q2DwpEAarJb6Ho+PyA
	cUHze4KTiVuL/r6rMfnml7pBZHXiyA==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="255254453"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 07:28:16 +0000
Received: from ex10-hub-36002.ant.amazon.com (ex10-hub-36002.sea32.amazon.com
	[10.250.1.7])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S7SFZ2013581
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 28 Jun 2012 07:28:15 GMT
Received: from US-SEA-R8XVZTX (10.224.80.43) by ex10-hub-36002.ant.amazon.com
	(10.250.1.7) with Microsoft SMTP Server id 14.2.247.3;
	Thu, 28 Jun 2012 00:28:11 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Thu, 28 Jun 2012
	00:28:10 -0700
Date: Thu, 28 Jun 2012 00:28:10 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628072810.GA9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340866756.5210.9.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Wed, Jun 27, 2012 at 11:59:16PM -0700, Ian Campbell wrote:
> On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > All of the other "list" verbs are of the form "$noun-list". For
> > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > Additionally, many people have well trained muscle memory from years
> > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > in "command not implemented".
> 
> Which did xm have list-vm or vm-list (or neither?) 

Neither.

> Aside: I'd love for someone to implement (for 4.3) a better error
> message than "command not implemented". At the least printing out the
> list of clashing options, or even git style "Did you mean" when you make
> a typo.

That would definitely be nice to have.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:36:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07: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 1Sk9H3-0003LB-UN; Thu, 28 Jun 2012 07:36: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 1Sk9H2-0003L6-IJ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:36:20 +0000
Received: from [193.109.254.147:25354] by server-10.bemta-14.messagelabs.com
	id 02/DA-05433-3790CEF4; Thu, 28 Jun 2012 07:36:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340868978!8955032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24757 invoked from network); 28 Jun 2012 07:36:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13260347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 07:36:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 08:36:18 +0100
Message-ID: <1340868977.5210.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 08:36:17 +0100
In-Reply-To: <20120628072810.GA9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
	<20120628072810.GA9080@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 08:28 +0100, Matt Wilson wrote:
> On Wed, Jun 27, 2012 at 11:59:16PM -0700, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > > All of the other "list" verbs are of the form "$noun-list". For
> > > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > > Additionally, many people have well trained muscle memory from years
> > > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > > in "command not implemented".
> > 
> > Which did xm have list-vm or vm-list (or neither?) 
> 
> Neither.

In which case I would ack the patch except you forgot to update
docs/man/xl*.pod.? (hrm, somehow list-vm isn't there -- can you add
vm-list anyway?)

Ian.

> 
> > Aside: I'd love for someone to implement (for 4.3) a better error
> > message than "command not implemented". At the least printing out the
> > list of clashing options, or even git style "Did you mean" when you make
> > a typo.
> 
> That would definitely be nice to have.
> 
> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:36:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07: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 1Sk9H3-0003LB-UN; Thu, 28 Jun 2012 07:36: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 1Sk9H2-0003L6-IJ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:36:20 +0000
Received: from [193.109.254.147:25354] by server-10.bemta-14.messagelabs.com
	id 02/DA-05433-3790CEF4; Thu, 28 Jun 2012 07:36:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340868978!8955032!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24757 invoked from network); 28 Jun 2012 07:36:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13260347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 07:36:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 08:36:18 +0100
Message-ID: <1340868977.5210.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 08:36:17 +0100
In-Reply-To: <20120628072810.GA9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
	<20120628072810.GA9080@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 08:28 +0100, Matt Wilson wrote:
> On Wed, Jun 27, 2012 at 11:59:16PM -0700, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > > All of the other "list" verbs are of the form "$noun-list". For
> > > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > > Additionally, many people have well trained muscle memory from years
> > > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > > in "command not implemented".
> > 
> > Which did xm have list-vm or vm-list (or neither?) 
> 
> Neither.

In which case I would ack the patch except you forgot to update
docs/man/xl*.pod.? (hrm, somehow list-vm isn't there -- can you add
vm-list anyway?)

Ian.

> 
> > Aside: I'd love for someone to implement (for 4.3) a better error
> > message than "command not implemented". At the least printing out the
> > list of clashing options, or even git style "Did you mean" when you make
> > a typo.
> 
> That would definitely be nice to have.
> 
> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:38:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:38: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 1Sk9It-0003Qd-E8; Thu, 28 Jun 2012 07:38:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk9Is-0003QV-1U
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:38:14 +0000
Received: from [85.158.138.51:41988] by server-8.bemta-3.messagelabs.com id
	8E/FB-06157-4E90CEF4; Thu, 28 Jun 2012 07:38:12 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340869089!20785757!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk2MDYw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31886 invoked from network); 28 Jun 2012 07:38:12 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:38:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340869092; x=1372405092;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=vpaKCG/4dq91oTj4233YRZmGfZA8AGjo0WmMWycgulY=;
	b=Bo1LtkKqGh+B+p898PoSPMmsYhi0qx807rBln7vI59imADRlerkC7BMr
	0knj5AJxq8pOMXofJ/VEBpJRnU/jRw==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="988522884"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 07:38:00 +0000
Received: from ex10-hub-9004.ant.amazon.com (ex10-hub-9004.ant.amazon.com
	[10.185.137.182])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S7c0JU024034
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 28 Jun 2012 07:38:00 GMT
Received: from US-SEA-R8XVZTX (10.224.80.43) by ex10-hub-9004.ant.amazon.com
	(10.185.137.182) with Microsoft SMTP Server id 14.2.247.3;
	Thu, 28 Jun 2012 00:37:59 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Thu, 28 Jun 2012
	00:37:58 -0700
Date: Thu, 28 Jun 2012 00:37:58 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628073758.GB9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
	<20120628072810.GA9080@US-SEA-R8XVZTX>
	<1340868977.5210.18.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340868977.5210.18.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, Jun 28, 2012 at 12:36:17AM -0700, Ian Campbell wrote:
> > > On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > > > All of the other "list" verbs are of the form "$noun-list". For
> > > > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > > > Additionally, many people have well trained muscle memory from years
> > > > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > > > in "command not implemented".
> > > 
> > > Which did xm have list-vm or vm-list (or neither?) 
> > 
> > Neither.
> 
> In which case I would ack the patch except you forgot to update
> docs/man/xl*.pod.? (hrm, somehow list-vm isn't there -- can you add
> vm-list anyway?)

I grepped for list-vm in the whole xen source tree, trying to make
sure that I updated any corresponding docs. I guess that means I
didn't notice it not being documented at all. :-P

v2 in a moment.

Matt


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:38:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:38: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 1Sk9It-0003Qd-E8; Thu, 28 Jun 2012 07:38:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk9Is-0003QV-1U
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:38:14 +0000
Received: from [85.158.138.51:41988] by server-8.bemta-3.messagelabs.com id
	8E/FB-06157-4E90CEF4; Thu, 28 Jun 2012 07:38:12 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340869089!20785757!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk2MDYw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31886 invoked from network); 28 Jun 2012 07:38:12 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:38:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340869092; x=1372405092;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=vpaKCG/4dq91oTj4233YRZmGfZA8AGjo0WmMWycgulY=;
	b=Bo1LtkKqGh+B+p898PoSPMmsYhi0qx807rBln7vI59imADRlerkC7BMr
	0knj5AJxq8pOMXofJ/VEBpJRnU/jRw==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="988522884"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 07:38:00 +0000
Received: from ex10-hub-9004.ant.amazon.com (ex10-hub-9004.ant.amazon.com
	[10.185.137.182])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S7c0JU024034
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 28 Jun 2012 07:38:00 GMT
Received: from US-SEA-R8XVZTX (10.224.80.43) by ex10-hub-9004.ant.amazon.com
	(10.185.137.182) with Microsoft SMTP Server id 14.2.247.3;
	Thu, 28 Jun 2012 00:37:59 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Thu, 28 Jun 2012
	00:37:58 -0700
Date: Thu, 28 Jun 2012 00:37:58 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628073758.GB9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
	<20120628072810.GA9080@US-SEA-R8XVZTX>
	<1340868977.5210.18.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340868977.5210.18.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, Jun 28, 2012 at 12:36:17AM -0700, Ian Campbell wrote:
> > > On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > > > All of the other "list" verbs are of the form "$noun-list". For
> > > > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > > > Additionally, many people have well trained muscle memory from years
> > > > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > > > in "command not implemented".
> > > 
> > > Which did xm have list-vm or vm-list (or neither?) 
> > 
> > Neither.
> 
> In which case I would ack the patch except you forgot to update
> docs/man/xl*.pod.? (hrm, somehow list-vm isn't there -- can you add
> vm-list anyway?)

I grepped for list-vm in the whole xen source tree, trying to make
sure that I updated any corresponding docs. I guess that means I
didn't notice it not being documented at all. :-P

v2 in a moment.

Matt


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:41:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:41: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 1Sk9M2-0003aC-1C; Thu, 28 Jun 2012 07:41: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 1Sk9M0-0003a4-3y
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:41:28 +0000
Received: from [85.158.138.51:33008] by server-3.bemta-3.messagelabs.com id
	95/8B-26490-7AA0CEF4; Thu, 28 Jun 2012 07:41:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340869286!27040392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19430 invoked from network); 28 Jun 2012 07:41:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:41:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13260429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 07:41:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 08:41:26 +0100
Message-ID: <1340869285.5210.19.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 08:41:25 +0100
In-Reply-To: <20120628073758.GB9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
	<20120628072810.GA9080@US-SEA-R8XVZTX>
	<1340868977.5210.18.camel@dagon.hellion.org.uk>
	<20120628073758.GB9080@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 08:37 +0100, Matt Wilson wrote:
> On Thu, Jun 28, 2012 at 12:36:17AM -0700, Ian Campbell wrote:
> > > > On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > > > > All of the other "list" verbs are of the form "$noun-list". For
> > > > > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > > > > Additionally, many people have well trained muscle memory from years
> > > > > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > > > > in "command not implemented".
> > > > 
> > > > Which did xm have list-vm or vm-list (or neither?) 
> > > 
> > > Neither.
> > 
> > In which case I would ack the patch except you forgot to update
> > docs/man/xl*.pod.? (hrm, somehow list-vm isn't there -- can you add
> > vm-list anyway?)
> 
> I grepped for list-vm in the whole xen source tree, trying to make
> sure that I updated any corresponding docs. I guess that means I
> didn't notice it not being documented at all. :-P

I only double checked because I'm pretty sure xl.pod.1 was started with
a grep over xl_cmdtable.c so I can't see how we missed it...

> v2 in a moment.

Thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:41:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:41: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 1Sk9M2-0003aC-1C; Thu, 28 Jun 2012 07:41: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 1Sk9M0-0003a4-3y
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:41:28 +0000
Received: from [85.158.138.51:33008] by server-3.bemta-3.messagelabs.com id
	95/8B-26490-7AA0CEF4; Thu, 28 Jun 2012 07:41:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340869286!27040392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19430 invoked from network); 28 Jun 2012 07:41:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:41:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13260429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 07:41:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 08:41:26 +0100
Message-ID: <1340869285.5210.19.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 08:41:25 +0100
In-Reply-To: <20120628073758.GB9080@US-SEA-R8XVZTX>
References: <34e47ba2612efdf0b2d6.1340865978@kaos-source-31003.sea31.amazon.com>
	<1340866756.5210.9.camel@dagon.hellion.org.uk>
	<20120628072810.GA9080@US-SEA-R8XVZTX>
	<1340868977.5210.18.camel@dagon.hellion.org.uk>
	<20120628073758.GB9080@US-SEA-R8XVZTX>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 08:37 +0100, Matt Wilson wrote:
> On Thu, Jun 28, 2012 at 12:36:17AM -0700, Ian Campbell wrote:
> > > > On Thu, 2012-06-28 at 07:46 +0100, Matt Wilson wrote:
> > > > > All of the other "list" verbs are of the form "$noun-list". For
> > > > > example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> > > > > Additionally, many people have well trained muscle memory from years
> > > > > of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> > > > > in "command not implemented".
> > > > 
> > > > Which did xm have list-vm or vm-list (or neither?) 
> > > 
> > > Neither.
> > 
> > In which case I would ack the patch except you forgot to update
> > docs/man/xl*.pod.? (hrm, somehow list-vm isn't there -- can you add
> > vm-list anyway?)
> 
> I grepped for list-vm in the whole xen source tree, trying to make
> sure that I updated any corresponding docs. I guess that means I
> didn't notice it not being documented at all. :-P

I only double checked because I'm pretty sure xl.pod.1 was started with
a grep over xl_cmdtable.c so I can't see how we missed it...

> v2 in a moment.

Thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:49:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:49: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 1Sk9TV-0003mc-V6; Thu, 28 Jun 2012 07:49: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 1Sk9TU-0003mX-E7
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:49:12 +0000
Received: from [193.109.254.147:46786] by server-5.bemta-14.messagelabs.com id
	0D/B9-04343-77C0CEF4; Thu, 28 Jun 2012 07:49:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340869748!8957586!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI3MzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8550 invoked from network); 28 Jun 2012 07:49:10 -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;
	28 Jun 2012 07:49:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336363200"; d="scan'208";a="200340082"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 03:49:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 03:49:06 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Sk9K2-0002Rf-B4;
	Thu, 28 Jun 2012 08:39:26 +0100
MIME-Version: 1.0
X-Mercurial-Node: bffb9db1332434164c444eb019e5ec6694529a72
Message-ID: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 28 Jun 2012 08:39:26 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340869061 -3600
# Node ID bffb9db1332434164c444eb019e5ec6694529a72
# Parent  6507f3b61e343d29cd04fb380282a5a039640874
docs: Use lists.xen.org not lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
@@ -1082,7 +1082,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+greatfully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 
diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 08:37:41 2012 +0100
@@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
 
 =head1 BUGS
 
-Send bugs to xen-devel@lists.xensource.com, see
+Send bugs to xen-devel@lists.xen.org, see
 http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xlcpupool.cfg.pod.5
--- a/docs/man/xlcpupool.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xlcpupool.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
@@ -111,7 +111,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+greatfully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:49:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:49: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 1Sk9TV-0003mc-V6; Thu, 28 Jun 2012 07:49: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 1Sk9TU-0003mX-E7
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:49:12 +0000
Received: from [193.109.254.147:46786] by server-5.bemta-14.messagelabs.com id
	0D/B9-04343-77C0CEF4; Thu, 28 Jun 2012 07:49:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340869748!8957586!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI3MzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8550 invoked from network); 28 Jun 2012 07:49:10 -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;
	28 Jun 2012 07:49:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336363200"; d="scan'208";a="200340082"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 03:49:07 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 03:49:06 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1Sk9K2-0002Rf-B4;
	Thu, 28 Jun 2012 08:39:26 +0100
MIME-Version: 1.0
X-Mercurial-Node: bffb9db1332434164c444eb019e5ec6694529a72
Message-ID: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 28 Jun 2012 08:39:26 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340869061 -3600
# Node ID bffb9db1332434164c444eb019e5ec6694529a72
# Parent  6507f3b61e343d29cd04fb380282a5a039640874
docs: Use lists.xen.org not lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
@@ -1082,7 +1082,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+greatfully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 
diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 08:37:41 2012 +0100
@@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
 
 =head1 BUGS
 
-Send bugs to xen-devel@lists.xensource.com, see
+Send bugs to xen-devel@lists.xen.org, see
 http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xlcpupool.cfg.pod.5
--- a/docs/man/xlcpupool.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xlcpupool.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
@@ -111,7 +111,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+greatfully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 07:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:57: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 1Sk9az-00048R-GM; Thu, 28 Jun 2012 07:56:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1Sk9ax-00048K-QV
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 07:56:56 +0000
Received: from [85.158.138.51:42267] by server-5.bemta-3.messagelabs.com id
	45/6B-01572-24E0CEF4; Thu, 28 Jun 2012 07:56:50 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340870208!30012438!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29786 invoked from network); 28 Jun 2012 07:56:49 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:56:49 -0000
Received: by obbef5 with SMTP id ef5so3956563obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Jun 2012 00:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=xbrXd5OcC5Rlgv8ugSlZh+u17aKZG1eRz35qSfsUKT4=;
	b=aHWzesUNXwYGF2F8pki24ppTuzJDOmjZ5r9CF3alTX5pWmtuiiHXCu3QJPl6MevCkV
	fLif1W6sFHXEbdf+QT5Uv3m8c9DSG4E4URQBZugVcZv6ydCccf8ux3ONu7MbabU1uqdM
	ewLHhEirCzJjCUn8vJnIBzHunpkBHCh8HgMvDiNKq5KPuKdaE1NXdltKw6GFBxk6a5ce
	FMIUG2dR0i12C2wVwdPebHdWkiCW7txYYuC2wwYZhw13Nm9aUBC2kg/rh6ydtjIb4wwr
	0YzocpnoDMZcmGoY9URNxe8Jgquw22xjTP7ZewZbZuxSZnkD5+MxU1G9qLJnWdMrFA24
	J2vA==
MIME-Version: 1.0
Received: by 10.182.13.74 with SMTP id f10mr959104obc.36.1340870207429; Thu,
	28 Jun 2012 00:56:47 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Thu, 28 Jun 2012 00:56:47 -0700 (PDT)
In-Reply-To: <1340861601.5210.6.camel@dagon.hellion.org.uk>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
	<1340861601.5210.6.camel@dagon.hellion.org.uk>
Date: Thu, 28 Jun 2012 15:56:47 +0800
Message-ID: <CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=f46d0444ee3d675bcf04c383ac00
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d0444ee3d675bcf04c383ac00
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

version 4

Thanks.
--

tools:libxl: refactor stdvga opinon support.

Be ready to add and describe new vga interface

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

diff -r 592d15bd4d5e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_create.c	Thu Jun 28 15:50:10 2012 +0800
@@ -189,7 +189,8 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }

-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        if (!b_info->u.hvm.vga.kind)
+            b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 592d15bd4d5e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Jun 28 15:50:10 2012 +0800
@@ -175,8 +175,13 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb=
)),
                     NULL);
         }
-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
+
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
             flexarray_append(dm_args, "-std-vga");
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
         }

         if (b_info->u.hvm.boot) {
@@ -418,8 +423,13 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }

-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
-                flexarray_vappend(dm_args, "-vga", "std", NULL);
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
+            flexarray_vappend(dm_args, "-vga", "std", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
         }

         if (b_info->u.hvm.boot) {
diff -r 592d15bd4d5e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Thu Jun 28 15:50:10 2012 +0800
@@ -125,9 +125,19 @@ libxl_shutdown_reason =3D Enumeration("shu
     (4, "watchdog"),
     ])

+libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
+    (1, "CIRRUS"),
+    (2, "STD"),
+    ], init_val =3D 0)
+
 #
 # Complex libxl types
 #
+
+libxl_vga_interface_info =3D Struct("vga_interface_info", [
+    ("kind",    libxl_vga_interface_type),
+    ])
+
 libxl_vnc_info =3D Struct("vnc_info", [
     ("enable",        libxl_defbool),
     # "address:port" that should be listened on
@@ -286,7 +296,7 @@ libxl_domain_build_info =3D Struct("domain
                                        ("nested_hvm",       libxl_defbool)=
,
                                        ("incr_generationid",libxl_defbool)=
,
                                        ("nographic",        libxl_defbool)=
,
-                                       ("stdvga",           libxl_defbool)=
,
+                                       ("vga",
libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info=
),
                                        # keyboard layout, default is
en-us keyboard
                                        ("keymap",           string),
diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 15:50:10 2012 +0800
@@ -1256,7 +1256,10 @@ skip_vfb:
 #undef parse_extra_args

     if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
-        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+            b_info->u.hvm.vga.kind =3D l ? LIBXL_VGA_INTERFACE_TYPE_STD :
+                                         LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);
diff -r 592d15bd4d5e tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Thu Jun 28 15:50:10 2012 +0800
@@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-        printf("\t\t\t(stdvga %s)\n",
-               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind =3D=3D
+                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
+                                      "True" : "False");
         printf("\t\t\t(vnc %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);

On Thu, Jun 28, 2012 at 1:33 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Thu, 2012-06-28 at 02:42 +0100, ZhouPeng wrote:
>> On Wed, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com>=
 wrote:
>> >> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
>> >> --- a/tools/libxl/xl_cmdimpl.c =A0Fri May 18 16:19:21 2012 +0100
>> >> +++ b/tools/libxl/xl_cmdimpl.c =A0Wed Jun 27 20:06:39 2012 +0800
>> >> @@ -1256,7 +1256,10 @@ skip_vfb:
>> >> =A0#undef parse_extra_args
>> >>
>> >> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> >> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm=
.stdvga, 0);
>> >> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D LIBXL_VGA=
_INTERFACE_TYPE_STD;
>> >
>> > I think this needs to be:
>> > =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D l ? \
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 LIBXL_VGA_INTERFACE_TYPE_STD : \
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>> >
>> > so that both "stdvga=3D0" and "stdvga=3D1" result in what the user ask=
ed for
>> > without relying on the libxl default remaining CIRRUS.
>>
>> IMHO, this make simple to be complex.
>>
>> I think the check =A0and set-default later in libxl_create.c as a whole =
is enough.
>
> This is in libxl, as I said above xl should not rely on the default
> remaining CIRRUS.
>
> If the user says "stdvga=3D0" then xl needs to explicitly ask for CIRRUS,
> despite the fact that it currently happens to be the default.
>
> If we make the libxl default BLARGLE in the future then stdvga=3D0 still
> needs to mean CIRRUS.
>
>> + =A0 =A0 =A0 =A0if (!b_info->u.hvm.vga.kind)
>> + =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_=
TYPE_CIRRUS;
>>
>> 'as a whole' here, I means if more vga type added in the future, we
>> don't need to set the default one by one, redundantly.
>



--=20
Zhou Peng

--f46d0444ee3d675bcf04c383ac00
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.stdvga.refactor.v4.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.stdvga.refactor.v4.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h3zjgcxm0

dG9vbHM6bGlieGw6IHJlZmFjdG9yIHN0ZHZnYSBvcGlub24gc3VwcG9ydC4KCkJlIHJlYWR5IHRv
IGFkZCBhbmQgZGVzY3JpYmUgbmV3IHZnYSBpbnRlcmZhY2UKClNpZ25lZC1vZmYtYnk6IFpob3Ug
UGVuZyA8YWlsdnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9s
aWJ4bC9saWJ4bF9jcmVhdGUuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlGcmkg
TWF5IDE4IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRl
LmMJVGh1IEp1biAyOCAxNTo1MDoxMCAyMDEyICswODAwCkBAIC0xODksNyArMTg5LDggQEAgaW50
IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgICAgICAgICAgaWYgKCFi
X2luZm8tPnUuaHZtLmJvb3QpIHJldHVybiBFUlJPUl9OT01FTTsKICAgICAgICAgfQogCi0gICAg
ICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIGZhbHNl
KTsKKyAgICAgICAgaWYgKCFiX2luZm8tPnUuaHZtLnZnYS5raW5kKQorICAgICAgICAgICAgYl9p
bmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM7CiAg
ICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxl
LCB0cnVlKTsKICAgICAgICAgaWYgKGxpYnhsX2RlZmJvb2xfdmFsKGJfaW5mby0+dS5odm0udm5j
LmVuYWJsZSkpIHsKICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZv
LT51Lmh2bS52bmMuZmluZHVudXNlZCwgdHJ1ZSk7CmRpZmYgLXIgNTkyZDE1YmQ0ZDVlIHRvb2xz
L2xpYnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlGcmkgTWF5IDE4
IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlUaHUgSnVu
IDI4IDE1OjUwOjEwIDIwMTIgKzA4MDAKQEAgLTE3NSw4ICsxNzUsMTMgQEAgc3RhdGljIGNoYXIg
KiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBsaWJ4bF9fc2l6ZWtiX3RvX21iKGJfaW5mby0+dmlkZW9fbWVta2IpKSwKICAgICAg
ICAgICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgIH0KLSAgICAgICAgaWYgKGxpYnhsX2RlZmJv
b2xfdmFsKGJfaW5mby0+dS5odm0uc3RkdmdhKSkgeworCisgICAgICAgIHN3aXRjaCAoYl9pbmZv
LT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQ
RV9TVEQ6CiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItc3RkLXZnYSIp
OworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9U
WVBFX0NJUlJVUzoKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYg
KGJfaW5mby0+dS5odm0uYm9vdCkgewpAQCAtNDE4LDggKzQyMywxMyBAQCBzdGF0aWMgY2hhciAq
KiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5k
KGRtX2FyZ3MsIHNwaWNlb3B0aW9ucyk7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAobGlieGxf
ZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKSB7Ci0gICAgICAgICAgICAgICAgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAic3RkIiwgTlVMTCk7CisgICAgICAgIHN3
aXRjaCAoYl9pbmZvLT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9TVEQ6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdz
LCAiLXZnYSIsICJzdGQiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICBjYXNl
IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CisgICAgICAgICAgICBmbGV4YXJyYXlf
dmFwcGVuZChkbV9hcmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJy
ZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0uYm9vdCkgewpkaWZm
IC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfdHlwZXMuaWRsCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysg
Yi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJVGh1IEp1biAyOCAxNTo1MDoxMCAyMDEyICsw
ODAwCkBAIC0xMjUsOSArMTI1LDE5IEBAIGxpYnhsX3NodXRkb3duX3JlYXNvbiA9IEVudW1lcmF0
aW9uKCJzaHUKICAgICAoNCwgIndhdGNoZG9nIiksCiAgICAgXSkKIAorbGlieGxfdmdhX2ludGVy
ZmFjZV90eXBlID0gRW51bWVyYXRpb24oInZnYV9pbnRlcmZhY2VfdHlwZSIsIFsKKyAgICAoMSwg
IkNJUlJVUyIpLAorICAgICgyLCAiU1REIiksCisgICAgXSwgaW5pdF92YWwgPSAwKQorCiAjCiAj
IENvbXBsZXggbGlieGwgdHlwZXMKICMKKworbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvID0gU3Ry
dWN0KCJ2Z2FfaW50ZXJmYWNlX2luZm8iLCBbCisgICAgKCJraW5kIiwgICAgbGlieGxfdmdhX2lu
dGVyZmFjZV90eXBlKSwKKyAgICBdKQorCiBsaWJ4bF92bmNfaW5mbyA9IFN0cnVjdCgidm5jX2lu
Zm8iLCBbCiAgICAgKCJlbmFibGUiLCAgICAgICAgbGlieGxfZGVmYm9vbCksCiAgICAgIyAiYWRk
cmVzczpwb3J0IiB0aGF0IHNob3VsZCBiZSBsaXN0ZW5lZCBvbgpAQCAtMjg2LDcgKzI5Niw3IEBA
IGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvID0gU3RydWN0KCJkb21haW4KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICgibmVzdGVkX2h2bSIsICAgICAgIGxpYnhsX2RlZmJv
b2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJpbmNyX2dlbmVy
YXRpb25pZCIsbGlieGxfZGVmYm9vbCksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAoIm5vZ3JhcGhpYyIsICAgICAgICBsaWJ4bF9kZWZib29sKSwKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICgic3RkdmdhIiwgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2wpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJ2Z2EiLCAg
ICAgICAgICAgICAgbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvKSwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgidm5jIiwgICAgICAgICAgICAgIGxpYnhsX3ZuY19pbmZv
KSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMga2V5Ym9hcmQgbGF5
b3V0LCBkZWZhdWx0IGlzIGVuLXVzIGtleWJvYXJkCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoImtleW1hcCIsICAgICAgICAgICBzdHJpbmcpLApkaWZmIC1yIDU5MmQx
NWJkNGQ1ZSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxfY21k
aW1wbC5jCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC94
bF9jbWRpbXBsLmMJVGh1IEp1biAyOCAxNTo1MDoxMCAyMDEyICswODAwCkBAIC0xMjU2LDcgKzEy
NTYsMTAgQEAgc2tpcF92ZmI6CiAjdW5kZWYgcGFyc2VfZXh0cmFfYXJncwogCiAgICAgaWYgKGNf
aW5mby0+dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pIHsKLSAgICAgICAgeGx1X2NmZ19n
ZXRfZGVmYm9vbChjb25maWcsICJzdGR2Z2EiLCAmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIDApOwor
ICAgICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcoY29uZmlnLCAic3RkdmdhIiwgJmwsIDApKQor
ICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9IGwgPyBMSUJYTF9WR0FfSU5URVJG
QUNFX1RZUEVfU1REIDoKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
TElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJUlJVUzsKKwogICAgICAgICB4bHVfY2ZnX2dldF9k
ZWZib29sKGNvbmZpZywgInZuYyIsICZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIDApOwogICAg
ICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nIChjb25maWcsICJ2bmNsaXN0ZW4iLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuLCAwKTsK
ZGlmZiAtciA1OTJkMTViZDRkNWUgdG9vbHMvbGlieGwveGxfc3hwLmMKLS0tIGEvdG9vbHMvbGli
eGwveGxfc3hwLmMJRnJpIE1heSAxOCAxNjoxOToyMSAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xp
YnhsL3hsX3N4cC5jCVRodSBKdW4gMjggMTU6NTA6MTAgMjAxMiArMDgwMApAQCAtMTEwLDggKzEx
MCw5IEBAIHZvaWQgcHJpbnRmX2luZm9fc2V4cChpbnQgZG9taWQsIGxpYnhsX2QKICAgICAgICAg
ICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ubmVzdGVkX2h2bSkp
OwogICAgICAgICBwcmludGYoIlx0XHRcdChub19pbmNyX2dlbmVyYXRpb25pZCAlcylcbiIsCiAg
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLmluY3Jf
Z2VuZXJhdGlvbmlkKSk7Ci0gICAgICAgIHByaW50ZigiXHRcdFx0KHN0ZHZnYSAlcylcbiIsCi0g
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnN0ZHZn
YSkpOworICAgICAgICBwcmludGYoIlx0XHRcdChzdGR2Z2EgJXMpXG4iLCBiX2luZm8tPnUuaHZt
LnZnYS5raW5kID09CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExJQlhM
X1ZHQV9JTlRFUkZBQ0VfVFlQRV9TVEQgPworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAiVHJ1ZSIgOiAiRmFsc2UiKTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jICVz
KVxuIiwKICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5o
dm0udm5jLmVuYWJsZSkpOwogICAgICAgICBwcmludGYoIlx0XHRcdCh2bmNsaXN0ZW4gJXMpXG4i
LCBiX2luZm8tPnUuaHZtLnZuYy5saXN0ZW4pOwo=
--f46d0444ee3d675bcf04c383ac00
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d0444ee3d675bcf04c383ac00--


From xen-devel-bounces@lists.xen.org Thu Jun 28 07:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 07:57: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 1Sk9az-00048R-GM; Thu, 28 Jun 2012 07:56:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1Sk9ax-00048K-QV
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 07:56:56 +0000
Received: from [85.158.138.51:42267] by server-5.bemta-3.messagelabs.com id
	45/6B-01572-24E0CEF4; Thu, 28 Jun 2012 07:56:50 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340870208!30012438!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29786 invoked from network); 28 Jun 2012 07:56:49 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:56:49 -0000
Received: by obbef5 with SMTP id ef5so3956563obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Jun 2012 00:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=xbrXd5OcC5Rlgv8ugSlZh+u17aKZG1eRz35qSfsUKT4=;
	b=aHWzesUNXwYGF2F8pki24ppTuzJDOmjZ5r9CF3alTX5pWmtuiiHXCu3QJPl6MevCkV
	fLif1W6sFHXEbdf+QT5Uv3m8c9DSG4E4URQBZugVcZv6ydCccf8ux3ONu7MbabU1uqdM
	ewLHhEirCzJjCUn8vJnIBzHunpkBHCh8HgMvDiNKq5KPuKdaE1NXdltKw6GFBxk6a5ce
	FMIUG2dR0i12C2wVwdPebHdWkiCW7txYYuC2wwYZhw13Nm9aUBC2kg/rh6ydtjIb4wwr
	0YzocpnoDMZcmGoY9URNxe8Jgquw22xjTP7ZewZbZuxSZnkD5+MxU1G9qLJnWdMrFA24
	J2vA==
MIME-Version: 1.0
Received: by 10.182.13.74 with SMTP id f10mr959104obc.36.1340870207429; Thu,
	28 Jun 2012 00:56:47 -0700 (PDT)
Received: by 10.182.75.131 with HTTP; Thu, 28 Jun 2012 00:56:47 -0700 (PDT)
In-Reply-To: <1340861601.5210.6.camel@dagon.hellion.org.uk>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
	<1340861601.5210.6.camel@dagon.hellion.org.uk>
Date: Thu, 28 Jun 2012 15:56:47 +0800
Message-ID: <CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=f46d0444ee3d675bcf04c383ac00
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d0444ee3d675bcf04c383ac00
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

version 4

Thanks.
--

tools:libxl: refactor stdvga opinon support.

Be ready to add and describe new vga interface

Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

diff -r 592d15bd4d5e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_create.c	Thu Jun 28 15:50:10 2012 +0800
@@ -189,7 +189,8 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }

-        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        if (!b_info->u.hvm.vga.kind)
+            b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
diff -r 592d15bd4d5e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Jun 28 15:50:10 2012 +0800
@@ -175,8 +175,13 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb=
)),
                     NULL);
         }
-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
+
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
             flexarray_append(dm_args, "-std-vga");
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            break;
         }

         if (b_info->u.hvm.boot) {
@@ -418,8 +423,13 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }

-        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
-                flexarray_vappend(dm_args, "-vga", "std", NULL);
+        switch (b_info->u.hvm.vga.kind) {
+        case LIBXL_VGA_INTERFACE_TYPE_STD:
+            flexarray_vappend(dm_args, "-vga", "std", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
+            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
         }

         if (b_info->u.hvm.boot) {
diff -r 592d15bd4d5e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Thu Jun 28 15:50:10 2012 +0800
@@ -125,9 +125,19 @@ libxl_shutdown_reason =3D Enumeration("shu
     (4, "watchdog"),
     ])

+libxl_vga_interface_type =3D Enumeration("vga_interface_type", [
+    (1, "CIRRUS"),
+    (2, "STD"),
+    ], init_val =3D 0)
+
 #
 # Complex libxl types
 #
+
+libxl_vga_interface_info =3D Struct("vga_interface_info", [
+    ("kind",    libxl_vga_interface_type),
+    ])
+
 libxl_vnc_info =3D Struct("vnc_info", [
     ("enable",        libxl_defbool),
     # "address:port" that should be listened on
@@ -286,7 +296,7 @@ libxl_domain_build_info =3D Struct("domain
                                        ("nested_hvm",       libxl_defbool)=
,
                                        ("incr_generationid",libxl_defbool)=
,
                                        ("nographic",        libxl_defbool)=
,
-                                       ("stdvga",           libxl_defbool)=
,
+                                       ("vga",
libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info=
),
                                        # keyboard layout, default is
en-us keyboard
                                        ("keymap",           string),
diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 15:50:10 2012 +0800
@@ -1256,7 +1256,10 @@ skip_vfb:
 #undef parse_extra_args

     if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
-        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+            b_info->u.hvm.vga.kind =3D l ? LIBXL_VGA_INTERFACE_TYPE_STD :
+                                         LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);
diff -r 592d15bd4d5e tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Fri May 18 16:19:21 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Thu Jun 28 15:50:10 2012 +0800
@@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-        printf("\t\t\t(stdvga %s)\n",
-               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind =3D=3D
+                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
+                                      "True" : "False");
         printf("\t\t\t(vnc %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);

On Thu, Jun 28, 2012 at 1:33 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Thu, 2012-06-28 at 02:42 +0100, ZhouPeng wrote:
>> On Wed, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com>=
 wrote:
>> >> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
>> >> --- a/tools/libxl/xl_cmdimpl.c =A0Fri May 18 16:19:21 2012 +0100
>> >> +++ b/tools/libxl/xl_cmdimpl.c =A0Wed Jun 27 20:06:39 2012 +0800
>> >> @@ -1256,7 +1256,10 @@ skip_vfb:
>> >> =A0#undef parse_extra_args
>> >>
>> >> =A0 =A0 =A0if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> >> - =A0 =A0 =A0 =A0xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm=
.stdvga, 0);
>> >> + =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> >> + =A0 =A0 =A0 =A0 =A0 =A0if (l)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D LIBXL_VGA=
_INTERFACE_TYPE_STD;
>> >
>> > I think this needs to be:
>> > =A0 =A0 =A0 =A0 =A0if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D l ? \
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 LIBXL_VGA_INTERFACE_TYPE_STD : \
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>> >
>> > so that both "stdvga=3D0" and "stdvga=3D1" result in what the user ask=
ed for
>> > without relying on the libxl default remaining CIRRUS.
>>
>> IMHO, this make simple to be complex.
>>
>> I think the check =A0and set-default later in libxl_create.c as a whole =
is enough.
>
> This is in libxl, as I said above xl should not rely on the default
> remaining CIRRUS.
>
> If the user says "stdvga=3D0" then xl needs to explicitly ask for CIRRUS,
> despite the fact that it currently happens to be the default.
>
> If we make the libxl default BLARGLE in the future then stdvga=3D0 still
> needs to mean CIRRUS.
>
>> + =A0 =A0 =A0 =A0if (!b_info->u.hvm.vga.kind)
>> + =A0 =A0 =A0 =A0 =A0 =A0b_info->u.hvm.vga.kind =3D LIBXL_VGA_INTERFACE_=
TYPE_CIRRUS;
>>
>> 'as a whole' here, I means if more vga type added in the future, we
>> don't need to set the default one by one, redundantly.
>



--=20
Zhou Peng

--f46d0444ee3d675bcf04c383ac00
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.stdvga.refactor.v4.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.stdvga.refactor.v4.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h3zjgcxm0

dG9vbHM6bGlieGw6IHJlZmFjdG9yIHN0ZHZnYSBvcGlub24gc3VwcG9ydC4KCkJlIHJlYWR5IHRv
IGFkZCBhbmQgZGVzY3JpYmUgbmV3IHZnYSBpbnRlcmZhY2UKClNpZ25lZC1vZmYtYnk6IFpob3Ug
UGVuZyA8YWlsdnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9s
aWJ4bC9saWJ4bF9jcmVhdGUuYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlGcmkg
TWF5IDE4IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRl
LmMJVGh1IEp1biAyOCAxNTo1MDoxMCAyMDEyICswODAwCkBAIC0xODksNyArMTg5LDggQEAgaW50
IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgICAgICAgICAgaWYgKCFi
X2luZm8tPnUuaHZtLmJvb3QpIHJldHVybiBFUlJPUl9OT01FTTsKICAgICAgICAgfQogCi0gICAg
ICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIGZhbHNl
KTsKKyAgICAgICAgaWYgKCFiX2luZm8tPnUuaHZtLnZnYS5raW5kKQorICAgICAgICAgICAgYl9p
bmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM7CiAg
ICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZvLT51Lmh2bS52bmMuZW5hYmxl
LCB0cnVlKTsKICAgICAgICAgaWYgKGxpYnhsX2RlZmJvb2xfdmFsKGJfaW5mby0+dS5odm0udm5j
LmVuYWJsZSkpIHsKICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVmYXVsdCgmYl9pbmZv
LT51Lmh2bS52bmMuZmluZHVudXNlZCwgdHJ1ZSk7CmRpZmYgLXIgNTkyZDE1YmQ0ZDVlIHRvb2xz
L2xpYnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlGcmkgTWF5IDE4
IDE2OjE5OjIxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZG0uYwlUaHUgSnVu
IDI4IDE1OjUwOjEwIDIwMTIgKzA4MDAKQEAgLTE3NSw4ICsxNzUsMTMgQEAgc3RhdGljIGNoYXIg
KiogbGlieGxfX2J1aWxkX2RldmljZV9tb2RlbAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBsaWJ4bF9fc2l6ZWtiX3RvX21iKGJfaW5mby0+dmlkZW9fbWVta2IpKSwKICAgICAg
ICAgICAgICAgICAgICAgTlVMTCk7CiAgICAgICAgIH0KLSAgICAgICAgaWYgKGxpYnhsX2RlZmJv
b2xfdmFsKGJfaW5mby0+dS5odm0uc3RkdmdhKSkgeworCisgICAgICAgIHN3aXRjaCAoYl9pbmZv
LT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQ
RV9TVEQ6CiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsICItc3RkLXZnYSIp
OworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9U
WVBFX0NJUlJVUzoKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYg
KGJfaW5mby0+dS5odm0uYm9vdCkgewpAQCAtNDE4LDggKzQyMywxMyBAQCBzdGF0aWMgY2hhciAq
KiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5k
KGRtX2FyZ3MsIHNwaWNlb3B0aW9ucyk7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAobGlieGxf
ZGVmYm9vbF92YWwoYl9pbmZvLT51Lmh2bS5zdGR2Z2EpKSB7Ci0gICAgICAgICAgICAgICAgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAic3RkIiwgTlVMTCk7CisgICAgICAgIHN3
aXRjaCAoYl9pbmZvLT51Lmh2bS52Z2Eua2luZCkgeworICAgICAgICBjYXNlIExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9TVEQ6CisgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdz
LCAiLXZnYSIsICJzdGQiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICBjYXNl
IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CisgICAgICAgICAgICBmbGV4YXJyYXlf
dmFwcGVuZChkbV9hcmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJy
ZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0uYm9vdCkgewpkaWZm
IC1yIDU5MmQxNWJkNGQ1ZSB0b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfdHlwZXMuaWRsCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysg
Yi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJVGh1IEp1biAyOCAxNTo1MDoxMCAyMDEyICsw
ODAwCkBAIC0xMjUsOSArMTI1LDE5IEBAIGxpYnhsX3NodXRkb3duX3JlYXNvbiA9IEVudW1lcmF0
aW9uKCJzaHUKICAgICAoNCwgIndhdGNoZG9nIiksCiAgICAgXSkKIAorbGlieGxfdmdhX2ludGVy
ZmFjZV90eXBlID0gRW51bWVyYXRpb24oInZnYV9pbnRlcmZhY2VfdHlwZSIsIFsKKyAgICAoMSwg
IkNJUlJVUyIpLAorICAgICgyLCAiU1REIiksCisgICAgXSwgaW5pdF92YWwgPSAwKQorCiAjCiAj
IENvbXBsZXggbGlieGwgdHlwZXMKICMKKworbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvID0gU3Ry
dWN0KCJ2Z2FfaW50ZXJmYWNlX2luZm8iLCBbCisgICAgKCJraW5kIiwgICAgbGlieGxfdmdhX2lu
dGVyZmFjZV90eXBlKSwKKyAgICBdKQorCiBsaWJ4bF92bmNfaW5mbyA9IFN0cnVjdCgidm5jX2lu
Zm8iLCBbCiAgICAgKCJlbmFibGUiLCAgICAgICAgbGlieGxfZGVmYm9vbCksCiAgICAgIyAiYWRk
cmVzczpwb3J0IiB0aGF0IHNob3VsZCBiZSBsaXN0ZW5lZCBvbgpAQCAtMjg2LDcgKzI5Niw3IEBA
IGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvID0gU3RydWN0KCJkb21haW4KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICgibmVzdGVkX2h2bSIsICAgICAgIGxpYnhsX2RlZmJv
b2wpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJpbmNyX2dlbmVy
YXRpb25pZCIsbGlieGxfZGVmYm9vbCksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAoIm5vZ3JhcGhpYyIsICAgICAgICBsaWJ4bF9kZWZib29sKSwKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICgic3RkdmdhIiwgICAgICAgICAgIGxpYnhsX2Rl
ZmJvb2wpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJ2Z2EiLCAg
ICAgICAgICAgICAgbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvKSwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgidm5jIiwgICAgICAgICAgICAgIGxpYnhsX3ZuY19pbmZv
KSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMga2V5Ym9hcmQgbGF5
b3V0LCBkZWZhdWx0IGlzIGVuLXVzIGtleWJvYXJkCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoImtleW1hcCIsICAgICAgICAgICBzdHJpbmcpLApkaWZmIC1yIDU5MmQx
NWJkNGQ1ZSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0tIGEvdG9vbHMvbGlieGwveGxfY21k
aW1wbC5jCUZyaSBNYXkgMTggMTY6MTk6MjEgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC94
bF9jbWRpbXBsLmMJVGh1IEp1biAyOCAxNTo1MDoxMCAyMDEyICswODAwCkBAIC0xMjU2LDcgKzEy
NTYsMTAgQEAgc2tpcF92ZmI6CiAjdW5kZWYgcGFyc2VfZXh0cmFfYXJncwogCiAgICAgaWYgKGNf
aW5mby0+dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pIHsKLSAgICAgICAgeGx1X2NmZ19n
ZXRfZGVmYm9vbChjb25maWcsICJzdGR2Z2EiLCAmYl9pbmZvLT51Lmh2bS5zdGR2Z2EsIDApOwor
ICAgICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcoY29uZmlnLCAic3RkdmdhIiwgJmwsIDApKQor
ICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9IGwgPyBMSUJYTF9WR0FfSU5URVJG
QUNFX1RZUEVfU1REIDoKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
TElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJUlJVUzsKKwogICAgICAgICB4bHVfY2ZnX2dldF9k
ZWZib29sKGNvbmZpZywgInZuYyIsICZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIDApOwogICAg
ICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nIChjb25maWcsICJ2bmNsaXN0ZW4iLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuLCAwKTsK
ZGlmZiAtciA1OTJkMTViZDRkNWUgdG9vbHMvbGlieGwveGxfc3hwLmMKLS0tIGEvdG9vbHMvbGli
eGwveGxfc3hwLmMJRnJpIE1heSAxOCAxNjoxOToyMSAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xp
YnhsL3hsX3N4cC5jCVRodSBKdW4gMjggMTU6NTA6MTAgMjAxMiArMDgwMApAQCAtMTEwLDggKzEx
MCw5IEBAIHZvaWQgcHJpbnRmX2luZm9fc2V4cChpbnQgZG9taWQsIGxpYnhsX2QKICAgICAgICAg
ICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5odm0ubmVzdGVkX2h2bSkp
OwogICAgICAgICBwcmludGYoIlx0XHRcdChub19pbmNyX2dlbmVyYXRpb25pZCAlcylcbiIsCiAg
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLmluY3Jf
Z2VuZXJhdGlvbmlkKSk7Ci0gICAgICAgIHByaW50ZigiXHRcdFx0KHN0ZHZnYSAlcylcbiIsCi0g
ICAgICAgICAgICAgICBsaWJ4bF9kZWZib29sX3RvX3N0cmluZyhiX2luZm8tPnUuaHZtLnN0ZHZn
YSkpOworICAgICAgICBwcmludGYoIlx0XHRcdChzdGR2Z2EgJXMpXG4iLCBiX2luZm8tPnUuaHZt
LnZnYS5raW5kID09CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExJQlhM
X1ZHQV9JTlRFUkZBQ0VfVFlQRV9TVEQgPworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAiVHJ1ZSIgOiAiRmFsc2UiKTsKICAgICAgICAgcHJpbnRmKCJcdFx0XHQodm5jICVz
KVxuIiwKICAgICAgICAgICAgICAgIGxpYnhsX2RlZmJvb2xfdG9fc3RyaW5nKGJfaW5mby0+dS5o
dm0udm5jLmVuYWJsZSkpOwogICAgICAgICBwcmludGYoIlx0XHRcdCh2bmNsaXN0ZW4gJXMpXG4i
LCBiX2luZm8tPnUuaHZtLnZuYy5saXN0ZW4pOwo=
--f46d0444ee3d675bcf04c383ac00
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d0444ee3d675bcf04c383ac00--


From xen-devel-bounces@lists.xen.org Thu Jun 28 08:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk9dk-0004IO-7x; Thu, 28 Jun 2012 07:59:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk9dj-0004IE-28
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:59:47 +0000
Received: from [85.158.143.99:56376] by server-2.bemta-4.messagelabs.com id
	07/C8-17938-2FE0CEF4; Thu, 28 Jun 2012 07:59:46 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340870383!19886000!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk2MDYw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9485 invoked from network); 28 Jun 2012 07:59:45 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:59:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340870385; x=1372406385;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=P18W8rhAXPQmFAOUtI5ujFoqXPOU7CH3/65livL/0J0=;
	b=bHgr+Y8c94AyHdv+myBoVYBJZAV0aNyGoWpcs+m4EUpNTqWKufXMD4DI
	xmYJOhqvI34RUivFpR/eg24i62IXAQ==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="988528593"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 07:59:43 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S7xgFS000679; Thu, 28 Jun 2012 07:59:42 GMT
MIME-Version: 1.0
X-Mercurial-Node: 5b1ed71c74d6758665138b3ba307370f53bd9451
Message-Id: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 28 Jun 2012 07:59:22 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

All of the other "list" verbs are of the form "$noun-list". For
example: "pci-list", "vcpu-list", "network-list", "block-list", etc.

Additionally, many people have well trained muscle memory from years
of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
in "command not implemented".

Finally, this command was missing from the xl man page.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
@@ -617,6 +617,18 @@ different run state is appropriate.  Pin
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
+=item B<vm-list>
+
+Prints information about all domains except for dom0.
+
+B<EXAMPLE>
+
+An example format for the list is as follows:
+
+UUID                                  ID    name
+59e1cf6c-6ab9-4879-90e7-adc8d1c63bf5  2    win
+50bc8f75-81d0-4d53-b2e6-95cb44e2682e  3    linux
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
@@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
 int main_shutdown(int argc, char **argv);
 int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
-int main_list_vm(int argc, char **argv);
+int main_vm_list(int argc, char **argv);
 int main_create(int argc, char **argv);
 int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
@@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
     return 0;
 }
 
-int main_list_vm(int argc, char **argv)
+int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
@@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
-    { "list-vm",
-      &main_list_vm, 0, 0,
-      "List the VMs,without DOM0",
+    { "vm-list",
+      &main_vm_list, 0, 0,
+      "List the VMs, without DOM0",
       "",
     },
     { "info",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sk9dk-0004IO-7x; Thu, 28 Jun 2012 07:59:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1Sk9dj-0004IE-28
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 07:59:47 +0000
Received: from [85.158.143.99:56376] by server-2.bemta-4.messagelabs.com id
	07/C8-17938-2FE0CEF4; Thu, 28 Jun 2012 07:59:46 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340870383!19886000!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk2MDYw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9485 invoked from network); 28 Jun 2012 07:59:45 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 07:59:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340870385; x=1372406385;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=P18W8rhAXPQmFAOUtI5ujFoqXPOU7CH3/65livL/0J0=;
	b=bHgr+Y8c94AyHdv+myBoVYBJZAV0aNyGoWpcs+m4EUpNTqWKufXMD4DI
	xmYJOhqvI34RUivFpR/eg24i62IXAQ==;
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="988528593"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 07:59:43 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5S7xgFS000679; Thu, 28 Jun 2012 07:59:42 GMT
MIME-Version: 1.0
X-Mercurial-Node: 5b1ed71c74d6758665138b3ba307370f53bd9451
Message-Id: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 28 Jun 2012 07:59:22 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

All of the other "list" verbs are of the form "$noun-list". For
example: "pci-list", "vcpu-list", "network-list", "block-list", etc.

Additionally, many people have well trained muscle memory from years
of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
in "command not implemented".

Finally, this command was missing from the xl man page.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
@@ -617,6 +617,18 @@ different run state is appropriate.  Pin
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
+=item B<vm-list>
+
+Prints information about all domains except for dom0.
+
+B<EXAMPLE>
+
+An example format for the list is as follows:
+
+UUID                                  ID    name
+59e1cf6c-6ab9-4879-90e7-adc8d1c63bf5  2    win
+50bc8f75-81d0-4d53-b2e6-95cb44e2682e  3    linux
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
@@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
 int main_shutdown(int argc, char **argv);
 int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
-int main_list_vm(int argc, char **argv);
+int main_vm_list(int argc, char **argv);
 int main_create(int argc, char **argv);
 int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
@@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
     return 0;
 }
 
-int main_list_vm(int argc, char **argv)
+int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
@@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
-    { "list-vm",
-      &main_list_vm, 0, 0,
-      "List the VMs,without DOM0",
+    { "vm-list",
+      &main_vm_list, 0, 0,
+      "List the VMs, without DOM0",
       "",
     },
     { "info",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:10:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1Sk9ne-00053U-HM; Thu, 28 Jun 2012 08:10:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1Sk9nd-00053L-7F
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:10:01 +0000
Received: from [85.158.143.35:50768] by server-1.bemta-4.messagelabs.com id
	96/3F-24392-8511CEF4; Thu, 28 Jun 2012 08:10:00 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340870999!7512098!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15742 invoked from network); 28 Jun 2012 08:09:59 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 08:09:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 01:09:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="163859582"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 28 Jun 2012 01:09:54 -0700
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; Thu, 28 Jun 2012 01:09:54 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 16:09:53 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
	guest
Thread-Index: Ac1TYUb9qkj/ISJ7SGCLemLA1RFKQgAW/s4iABGm4ZD//98yAP/93aYw
Date: Thu, 28 Jun 2012 08:09:52 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10101B6D@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<1340782140.14761.4.camel@dagon.hellion.org.uk>
In-Reply-To: <1340782140.14761.4.camel@dagon.hellion.org.uk>
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: "Tim	\(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, June 27, 2012 3:29 PM
> To: Ren, Yongjie
> Cc: Stefano Stabellini; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org)
> Subject: RE: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> guest
> 
> On Wed, 2012-06-27 at 02:45 +0100, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > To: Ian Campbell
> > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > > Stefano Stabellini
> > > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a
> hvm
> > > guest
> > >
> > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > > >
> > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > So, select a standard VGA card with VBE as the default emulated
> > > graphics device.
> > > >
> > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > switching the default to something more modern seems like a
> > > reasonable
> > > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > > point.
> > > >
> > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > >
> > > I think it is a good thing.
> > > The only thing to keep in mind is that QEMU upstream is switching to
> > > 16MB of videoram for stdvga. So at some point in the near future
> > > upstream QEMU will stop working correctly with xen 4.2, unless we
> bump
> > > the videoram to 16MB too.
> > >
> > Yes, we should pay attention to this when using upstream QEMU.
> >
> > >
> > > > > It's also a workaround for the following bug.
> > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > > >
> > > > Do you understand the root cause of that bug?
> > > >
> > I don't understand the root cause.
> >
> > > > It's hard to see how detaching a VF relates to the VGA emulation in
> use.
> > > > Can you explain it? Are you sure you aren't just masking the real issue
> > > > here?
> > >
> > It's strange that detaching a VF may break the graphics display.
> > As it only happens when 'stdvga=0', it might not be a normal usage.
> >
> > > Indeed. We cannot possibly accept the patch on the basis that it looks
> > > like it is masking an unrelated pci-passthrough bug.
> > >
> > I don't want to mask that bug, either. :-)
> > The following sentence is quoted from xl.cfg man page.
> > "If your guest supports VBE 2.0 or later (e.g. Windows XP onwards)
> > then you should enable this (stdvga option)."
> > If we set 'stdvga=1', we will not meet the bug (#1812).
> > I assume many Xen users (including me) are not very familiar with
> 'stdvga' and
> > will leave it as default (it's 0 before my patch).
> > If then, users may meet something *strange* like bug #1812.
> > I don't think it's friendly to end users, so I set the default value
> > of 'stdvga' to '1'.
> 
> There are good reasons which justify setting stdvga=1 by default. But
> anything to do with #1812 is not one of them. It is obviously wrong to
> justify making an unrelated configuration change on the basis that it
> hides a bug by default without first understanding the reasons for the
> bug.
> 
> I certainly hope you are not planning to close #1812 and stop
> investigating it if we change the stdvga default.
> 
Sure, I don't want to close bug #1812. As I'm not familiar with this, 
if someone want to fix it, I'll co-work with him/her about this issue. 
e.g. help to reproduce it or do some testing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:10:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1Sk9ne-00053U-HM; Thu, 28 Jun 2012 08:10:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1Sk9nd-00053L-7F
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:10:01 +0000
Received: from [85.158.143.35:50768] by server-1.bemta-4.messagelabs.com id
	96/3F-24392-8511CEF4; Thu, 28 Jun 2012 08:10:00 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340870999!7512098!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkxODc0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15742 invoked from network); 28 Jun 2012 08:09:59 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 08:09:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 01:09:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="163859582"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 28 Jun 2012 01:09:54 -0700
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; Thu, 28 Jun 2012 01:09:54 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 16:09:53 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
	guest
Thread-Index: Ac1TYUb9qkj/ISJ7SGCLemLA1RFKQgAW/s4iABGm4ZD//98yAP/93aYw
Date: Thu, 28 Jun 2012 08:09:52 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10101B6D@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100FEA45@SHSMSX101.ccr.corp.intel.com>
	<1340717554.3832.107.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206261746140.27860@kaball.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1010076A@SHSMSX101.ccr.corp.intel.com>
	<1340782140.14761.4.camel@dagon.hellion.org.uk>
In-Reply-To: <1340782140.14761.4.camel@dagon.hellion.org.uk>
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: "Tim	\(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: set stdvga=1 by default when
 creating a hvm 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

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, June 27, 2012 3:29 PM
> To: Ren, Yongjie
> Cc: Stefano Stabellini; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org)
> Subject: RE: [PATCH 1/2] libxl: set stdvga=1 by default when creating a hvm
> guest
> 
> On Wed, 2012-06-27 at 02:45 +0100, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Wednesday, June 27, 2012 1:00 AM
> > > To: Ian Campbell
> > > Cc: Ren, Yongjie; xen-devel@lists.xen.org; Ian Jackson; Tim (Xen.org);
> > > Stefano Stabellini
> > > Subject: Re: [PATCH 1/2] libxl: set stdvga=1 by default when creating a
> hvm
> > > guest
> > >
> > > On Tue, 26 Jun 2012, Ian Campbell wrote:
> > > > On Tue, 2012-06-26 at 07:02 +0100, Ren, Yongjie wrote:
> > > > > libxl: set stdvga=1 by default when creating a hvm guest
> > > > >
> > > > > Most of the modern OSes (e.g. Windows XP, Windows 7, RHEL6.x,
> > > Ubuntu, Fedora) support VBE 2.0 or later.
> > > > > So, select a standard VGA card with VBE as the default emulated
> > > graphics device.
> > > >
> > > > I'm not expert on the graphics side of HVM, but on the face of it
> > > > switching the default to something more modern seems like a
> > > reasonable
> > > > idea, although I'm not sure if we should be doing this for 4.2 at this
> > > > point.
> > > >
> > > > I've CCd Tim and Stefano for input from the HVM and QEMU sides.
> > >
> > > I think it is a good thing.
> > > The only thing to keep in mind is that QEMU upstream is switching to
> > > 16MB of videoram for stdvga. So at some point in the near future
> > > upstream QEMU will stop working correctly with xen 4.2, unless we
> bump
> > > the videoram to 16MB too.
> > >
> > Yes, we should pay attention to this when using upstream QEMU.
> >
> > >
> > > > > It's also a workaround for the following bug.
> > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > > >
> > > > Do you understand the root cause of that bug?
> > > >
> > I don't understand the root cause.
> >
> > > > It's hard to see how detaching a VF relates to the VGA emulation in
> use.
> > > > Can you explain it? Are you sure you aren't just masking the real issue
> > > > here?
> > >
> > It's strange that detaching a VF may break the graphics display.
> > As it only happens when 'stdvga=0', it might not be a normal usage.
> >
> > > Indeed. We cannot possibly accept the patch on the basis that it looks
> > > like it is masking an unrelated pci-passthrough bug.
> > >
> > I don't want to mask that bug, either. :-)
> > The following sentence is quoted from xl.cfg man page.
> > "If your guest supports VBE 2.0 or later (e.g. Windows XP onwards)
> > then you should enable this (stdvga option)."
> > If we set 'stdvga=1', we will not meet the bug (#1812).
> > I assume many Xen users (including me) are not very familiar with
> 'stdvga' and
> > will leave it as default (it's 0 before my patch).
> > If then, users may meet something *strange* like bug #1812.
> > I don't think it's friendly to end users, so I set the default value
> > of 'stdvga' to '1'.
> 
> There are good reasons which justify setting stdvga=1 by default. But
> anything to do with #1812 is not one of them. It is obviously wrong to
> justify making an unrelated configuration change on the basis that it
> hides a bug by default without first understanding the reasons for the
> bug.
> 
> I certainly hope you are not planning to close #1812 and stop
> investigating it if we change the stdvga default.
> 
Sure, I don't want to close bug #1812. As I'm not familiar with this, 
if someone want to fix it, I'll co-work with him/her about this issue. 
e.g. help to reproduce it or do some testing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1Sk9pM-000581-1C; Thu, 28 Jun 2012 08:11: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 1Sk9pK-00057q-BI
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:11:46 +0000
Received: from [85.158.138.51:50527] by server-2.bemta-3.messagelabs.com id
	3A/E6-10266-1C11CEF4; Thu, 28 Jun 2012 08:11:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340871104!21851337!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17870 invoked from network); 28 Jun 2012 08:11:44 -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 Jun 2012 08:11:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sk9pG-0008Q5-Sm; Thu, 28 Jun 2012 08:11:42 +0000
Date: Thu, 28 Jun 2012 09:11:42 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628081142.GA32085@ocelot.phlegethon.org>
References: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not
	lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0100 on 28 Jun (1340872766), Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1340869061 -3600
> # Node ID bffb9db1332434164c444eb019e5ec6694529a72
> # Parent  6507f3b61e343d29cd04fb380282a5a039640874
> docs: Use lists.xen.org not lists.xensource.com
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
> @@ -1082,7 +1082,7 @@ XXX).  However all options are included 
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing

May as well s/greatful/grateful/ while you're editing this line. :)
(and again below).

Cheers,

Tim.

>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Jun 28 08:37:41 2012 +0100
> @@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
>  
>  =head1 BUGS
>  
> -Send bugs to xen-devel@lists.xensource.com, see
> +Send bugs to xen-devel@lists.xen.org, see
>  http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xlcpupool.cfg.pod.5
> --- a/docs/man/xlcpupool.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xlcpupool.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
> @@ -111,7 +111,7 @@ XXX).  However all options are included 
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing
>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 08:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1Sk9pM-000581-1C; Thu, 28 Jun 2012 08:11: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 1Sk9pK-00057q-BI
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:11:46 +0000
Received: from [85.158.138.51:50527] by server-2.bemta-3.messagelabs.com id
	3A/E6-10266-1C11CEF4; Thu, 28 Jun 2012 08:11:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340871104!21851337!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17870 invoked from network); 28 Jun 2012 08:11:44 -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 Jun 2012 08:11:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Sk9pG-0008Q5-Sm; Thu, 28 Jun 2012 08:11:42 +0000
Date: Thu, 28 Jun 2012 09:11:42 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628081142.GA32085@ocelot.phlegethon.org>
References: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not
	lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:39 +0100 on 28 Jun (1340872766), Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1340869061 -3600
> # Node ID bffb9db1332434164c444eb019e5ec6694529a72
> # Parent  6507f3b61e343d29cd04fb380282a5a039640874
> docs: Use lists.xen.org not lists.xensource.com
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
> @@ -1082,7 +1082,7 @@ XXX).  However all options are included 
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing

May as well s/greatful/grateful/ while you're editing this line. :)
(and again below).

Cheers,

Tim.

>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Jun 28 08:37:41 2012 +0100
> @@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
>  
>  =head1 BUGS
>  
> -Send bugs to xen-devel@lists.xensource.com, see
> +Send bugs to xen-devel@lists.xen.org, see
>  http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xlcpupool.cfg.pod.5
> --- a/docs/man/xlcpupool.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xlcpupool.cfg.pod.5	Thu Jun 28 08:37:41 2012 +0100
> @@ -111,7 +111,7 @@ XXX).  However all options are included 
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing
>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 08:27:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkA40-0005MO-1C; Thu, 28 Jun 2012 08:26:56 +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 1SkA3y-0005MJ-BN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:26:54 +0000
Received: from [193.109.254.147:6688] by server-11.bemta-14.messagelabs.com id
	6B/51-24843-D451CEF4; Thu, 28 Jun 2012 08:26:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340872011!8966535!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25494 invoked from network); 28 Jun 2012 08:26:52 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:26:52 -0000
Received: by eekd41 with SMTP id d41so732783eek.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 01:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UCYZO5xRaBYVXM7PPR7NZATZKfsh89gWqeWV/XCqolE=;
	b=f8bqNbiCeGy4cGRO7+u8vxZpzUi/VqK84QBKOvxcYuc4pLcRB1vcyGry7Lxk2HYb+6
	P8mHYmB3w9p5MTN6x260zJKgUiFmOAB8+6s3Jwg55DrkcOUvZNtZ1ic7j3ZuG3YQMWdV
	QOFT2ZvJ6yWTXMvuX2hnurPUtX+HMXuHYLKnz610OtOLPIfPM63fTyMy6TJg27SApY6+
	weFR1uhBwDBawoFg+CPBxAhdmw8IFkS1uiBrglQtoPdCIwdxotR8rFV7dUpEgF+gYbBs
	MOJerE2zQKZiTHF0KE+i5E+59kZu0ylYvOzhBgLXlgR12jYfAZ2GxLvwQ6d2ExjLrave
	TWRw==
Received: by 10.14.28.11 with SMTP id f11mr210886eea.136.1340872011395;
	Thu, 28 Jun 2012 01:26:51 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id t3sm166729142eeb.15.2012.06.28.01.26.49
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 01:26:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 28 Jun 2012 09:26:43 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC11D3D3.442F5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] docs: Use lists.xen.org not
	lists.xensource.com
Thread-Index: Ac1VB7+GovBMpJjt2UG3iXvC4QdoBg==
In-Reply-To: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not
 lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 08:39, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1340869061 -3600
> # Node ID bffb9db1332434164c444eb019e5ec6694529a72
> # Parent  6507f3b61e343d29cd04fb380282a5a039640874
> docs: Use lists.xen.org not lists.xensource.com
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

s/greatful/grateful/

Acked-by: Keir Fraser <keir@xen.org>

> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5 Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5 Thu Jun 28 08:37:41 2012 +0100
> @@ -1082,7 +1082,7 @@ XXX).  However all options are included
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing
>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1 Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.pod.1 Thu Jun 28 08:37:41 2012 +0100
> @@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
>  
>  =head1 BUGS
>  
> -Send bugs to xen-devel@lists.xensource.com, see
> +Send bugs to xen-devel@lists.xen.org, see
>  http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xlcpupool.cfg.pod.5
> --- a/docs/man/xlcpupool.cfg.pod.5 Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xlcpupool.cfg.pod.5 Thu Jun 28 08:37:41 2012 +0100
> @@ -111,7 +111,7 @@ XXX).  However all options are included
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing
>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 08:27:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkA40-0005MO-1C; Thu, 28 Jun 2012 08:26:56 +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 1SkA3y-0005MJ-BN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:26:54 +0000
Received: from [193.109.254.147:6688] by server-11.bemta-14.messagelabs.com id
	6B/51-24843-D451CEF4; Thu, 28 Jun 2012 08:26:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340872011!8966535!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25494 invoked from network); 28 Jun 2012 08:26:52 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:26:52 -0000
Received: by eekd41 with SMTP id d41so732783eek.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 01:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UCYZO5xRaBYVXM7PPR7NZATZKfsh89gWqeWV/XCqolE=;
	b=f8bqNbiCeGy4cGRO7+u8vxZpzUi/VqK84QBKOvxcYuc4pLcRB1vcyGry7Lxk2HYb+6
	P8mHYmB3w9p5MTN6x260zJKgUiFmOAB8+6s3Jwg55DrkcOUvZNtZ1ic7j3ZuG3YQMWdV
	QOFT2ZvJ6yWTXMvuX2hnurPUtX+HMXuHYLKnz610OtOLPIfPM63fTyMy6TJg27SApY6+
	weFR1uhBwDBawoFg+CPBxAhdmw8IFkS1uiBrglQtoPdCIwdxotR8rFV7dUpEgF+gYbBs
	MOJerE2zQKZiTHF0KE+i5E+59kZu0ylYvOzhBgLXlgR12jYfAZ2GxLvwQ6d2ExjLrave
	TWRw==
Received: by 10.14.28.11 with SMTP id f11mr210886eea.136.1340872011395;
	Thu, 28 Jun 2012 01:26:51 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id t3sm166729142eeb.15.2012.06.28.01.26.49
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 01:26:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 28 Jun 2012 09:26:43 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC11D3D3.442F5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] docs: Use lists.xen.org not
	lists.xensource.com
Thread-Index: Ac1VB7+GovBMpJjt2UG3iXvC4QdoBg==
In-Reply-To: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not
 lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 08:39, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1340869061 -3600
> # Node ID bffb9db1332434164c444eb019e5ec6694529a72
> # Parent  6507f3b61e343d29cd04fb380282a5a039640874
> docs: Use lists.xen.org not lists.xensource.com
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

s/greatful/grateful/

Acked-by: Keir Fraser <keir@xen.org>

> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5 Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5 Thu Jun 28 08:37:41 2012 +0100
> @@ -1082,7 +1082,7 @@ XXX).  However all options are included
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing
>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1 Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xl.pod.1 Thu Jun 28 08:37:41 2012 +0100
> @@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
>  
>  =head1 BUGS
>  
> -Send bugs to xen-devel@lists.xensource.com, see
> +Send bugs to xen-devel@lists.xen.org, see
>  http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
> diff -r 6507f3b61e34 -r bffb9db13324 docs/man/xlcpupool.cfg.pod.5
> --- a/docs/man/xlcpupool.cfg.pod.5 Wed Jun 27 16:21:53 2012 +0100
> +++ b/docs/man/xlcpupool.cfg.pod.5 Thu Jun 28 08:37:41 2012 +0100
> @@ -111,7 +111,7 @@ XXX).  However all options are included
>  fully documented.
>  
>  Patches to improve incomplete items (or any other item) would be
> -greatfully received on the xen-devel@lists.xensource.com mailing
> +greatfully received on the xen-devel@lists.xen.org mailing
>  list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
>  information on how to submit a patch to Xen.
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 08:35:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:35: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 1SkABh-0005j4-Jm; Thu, 28 Jun 2012 08:34:53 +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 1SkABg-0005ix-6J
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:34:52 +0000
Received: from [193.109.254.147:10665] by server-6.bemta-14.messagelabs.com id
	C4/B2-08993-B271CEF4; Thu, 28 Jun 2012 08:34:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340872489!3301351!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI3MzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14536 invoked from network); 28 Jun 2012 08:34:50 -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;
	28 Jun 2012 08:34:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336363200"; d="scan'208";a="200342912"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 04:34:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 04:34:48 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkABc-0003zY-9G;
	Thu, 28 Jun 2012 09:34:48 +0100
MIME-Version: 1.0
X-Mercurial-Node: 79d58c0f37158a0c26e0fd586d3de35441f1a4fe
Message-ID: <79d58c0f37158a0c26e0.1340872488@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 28 Jun 2012 09:34:48 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2] docs: Use lists.xen.org not
	lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340872476 -3600
# Node ID 79d58c0f37158a0c26e0fd586d3de35441f1a4fe
# Parent  6507f3b61e343d29cd04fb380282a5a039640874
docs: Use lists.xen.org not lists.xensource.com

s/greatfully/gratefully/ while I'm there.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>

diff -r 6507f3b61e34 -r 79d58c0f3715 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 09:34:36 2012 +0100
@@ -1082,7 +1082,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+gratefully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 
diff -r 6507f3b61e34 -r 79d58c0f3715 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 09:34:36 2012 +0100
@@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
 
 =head1 BUGS
 
-Send bugs to xen-devel@lists.xensource.com, see
+Send bugs to xen-devel@lists.xen.org, see
 http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
diff -r 6507f3b61e34 -r 79d58c0f3715 docs/man/xlcpupool.cfg.pod.5
--- a/docs/man/xlcpupool.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xlcpupool.cfg.pod.5	Thu Jun 28 09:34:36 2012 +0100
@@ -111,7 +111,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+gratefully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:35:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:35: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 1SkABh-0005j4-Jm; Thu, 28 Jun 2012 08:34:53 +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 1SkABg-0005ix-6J
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:34:52 +0000
Received: from [193.109.254.147:10665] by server-6.bemta-14.messagelabs.com id
	C4/B2-08993-B271CEF4; Thu, 28 Jun 2012 08:34:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340872489!3301351!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI3MzU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14536 invoked from network); 28 Jun 2012 08:34:50 -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;
	28 Jun 2012 08:34:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336363200"; d="scan'208";a="200342912"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 04:34:48 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 04:34:48 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkABc-0003zY-9G;
	Thu, 28 Jun 2012 09:34:48 +0100
MIME-Version: 1.0
X-Mercurial-Node: 79d58c0f37158a0c26e0fd586d3de35441f1a4fe
Message-ID: <79d58c0f37158a0c26e0.1340872488@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 28 Jun 2012 09:34:48 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2] docs: Use lists.xen.org not
	lists.xensource.com
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340872476 -3600
# Node ID 79d58c0f37158a0c26e0fd586d3de35441f1a4fe
# Parent  6507f3b61e343d29cd04fb380282a5a039640874
docs: Use lists.xen.org not lists.xensource.com

s/greatfully/gratefully/ while I'm there.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>

diff -r 6507f3b61e34 -r 79d58c0f3715 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 09:34:36 2012 +0100
@@ -1082,7 +1082,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+gratefully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 
diff -r 6507f3b61e34 -r 79d58c0f3715 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 09:34:36 2012 +0100
@@ -1255,5 +1255,5 @@ L<http://wiki.xen.org/wiki/Paravirt_Linu
 
 =head1 BUGS
 
-Send bugs to xen-devel@lists.xensource.com, see
+Send bugs to xen-devel@lists.xen.org, see
 http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
diff -r 6507f3b61e34 -r 79d58c0f3715 docs/man/xlcpupool.cfg.pod.5
--- a/docs/man/xlcpupool.cfg.pod.5	Wed Jun 27 16:21:53 2012 +0100
+++ b/docs/man/xlcpupool.cfg.pod.5	Thu Jun 28 09:34:36 2012 +0100
@@ -111,7 +111,7 @@ XXX).  However all options are included 
 fully documented.
 
 Patches to improve incomplete items (or any other item) would be
-greatfully received on the xen-devel@lists.xensource.com mailing
+gratefully received on the xen-devel@lists.xen.org mailing
 list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
 information on how to submit a patch to Xen.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:36:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAD1-0005oH-2f; Thu, 28 Jun 2012 08:36:15 +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 1SkACz-0005o7-G7
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:36:13 +0000
Received: from [85.158.139.83:56656] by server-3.bemta-5.messagelabs.com id
	19/FE-03367-C771CEF4; Thu, 28 Jun 2012 08:36:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340872570!27209685!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32679 invoked from network); 28 Jun 2012 08:36:11 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:36:11 -0000
Received: by qaeb19 with SMTP id b19so3117780qae.11
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 01:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=rMUPWPwLOJ78dDqq5GZ8Rn+m9EdU2xaxlxKI6dvBkXE=;
	b=kg0PlZUOIaxiq21XHgdK7AesxRdrcqb+jXpTr5vKc/RsWKz44TPN8fPUfblPApsjjF
	OaIA3tREAGbd4xq4MzwAI4kbwwm4Zk0IXkeQSj20RGccGHEw4+b1Q4rz9nIE5ZpHCnNL
	SKDmxNWU2h8jzabBD6ydV5ravBV1mGeq1hcj1vUp7ZViWmcuqOjF9q87jAlzeUmXoQba
	dwcx5SAKvhbBpdhCmdDkfcvMjN8k6l84Cv90LZEQ2Kfo4xtDLUzWsVYxoKuv9uZ6psHO
	A9yv6LnTZCfo0nDHEeaZAQHHQrIEO2bRzp2Kmej9g7snqphjAvcNsBpK+xtU1T5fUEQh
	z89w==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr2048062qap.6.1340872570466; Thu,
	28 Jun 2012 01:36:10 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 01:36:09 -0700 (PDT)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
Date: Thu, 28 Jun 2012 09:36:09 +0100
X-Google-Sender-Auth: ogBn_mrOcQnaxXWsZYSNGLW4zI8
Message-ID: <CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 8:25 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
>> This all happens internally to libxl, and no API for driving the mechanism is
>> provided for now. This matches what xend already does.
> we should consider the basic IONUMA. I mean when a guest with a device assigned,
> from the point of view of performance, it's better to allocated the memory from the node
> which the device belongs to.
> Furthermore, we need consider the guest NUMA(I am working on it now) and live migration.

Just to help set the context for these patch series: We have lots of
big plans for NUMA in the 4.3 release (and are always glad for input
and help!), but the current goal is just to have *something* for the
upcoming 4.2 release.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:36:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAD1-0005oH-2f; Thu, 28 Jun 2012 08:36:15 +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 1SkACz-0005o7-G7
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:36:13 +0000
Received: from [85.158.139.83:56656] by server-3.bemta-5.messagelabs.com id
	19/FE-03367-C771CEF4; Thu, 28 Jun 2012 08:36:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340872570!27209685!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32679 invoked from network); 28 Jun 2012 08:36:11 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:36:11 -0000
Received: by qaeb19 with SMTP id b19so3117780qae.11
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 01:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=rMUPWPwLOJ78dDqq5GZ8Rn+m9EdU2xaxlxKI6dvBkXE=;
	b=kg0PlZUOIaxiq21XHgdK7AesxRdrcqb+jXpTr5vKc/RsWKz44TPN8fPUfblPApsjjF
	OaIA3tREAGbd4xq4MzwAI4kbwwm4Zk0IXkeQSj20RGccGHEw4+b1Q4rz9nIE5ZpHCnNL
	SKDmxNWU2h8jzabBD6ydV5ravBV1mGeq1hcj1vUp7ZViWmcuqOjF9q87jAlzeUmXoQba
	dwcx5SAKvhbBpdhCmdDkfcvMjN8k6l84Cv90LZEQ2Kfo4xtDLUzWsVYxoKuv9uZ6psHO
	A9yv6LnTZCfo0nDHEeaZAQHHQrIEO2bRzp2Kmej9g7snqphjAvcNsBpK+xtU1T5fUEQh
	z89w==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr2048062qap.6.1340872570466; Thu,
	28 Jun 2012 01:36:10 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 01:36:09 -0700 (PDT)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
Date: Thu, 28 Jun 2012 09:36:09 +0100
X-Google-Sender-Auth: ogBn_mrOcQnaxXWsZYSNGLW4zI8
Message-ID: <CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 8:25 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
>> This all happens internally to libxl, and no API for driving the mechanism is
>> provided for now. This matches what xend already does.
> we should consider the basic IONUMA. I mean when a guest with a device assigned,
> from the point of view of performance, it's better to allocated the memory from the node
> which the device belongs to.
> Furthermore, we need consider the guest NUMA(I am working on it now) and live migration.

Just to help set the context for these patch series: We have lots of
big plans for NUMA in the 4.3 release (and are always glad for input
and help!), but the current goal is just to have *something* for the
upcoming 4.2 release.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:36:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAD2-0005on-Je; Thu, 28 Jun 2012 08:36: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 1SkAD1-0005oF-B6
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:36:15 +0000
Received: from [85.158.138.51:55296] by server-9.bemta-3.messagelabs.com id
	11/1B-10419-E771CEF4; Thu, 28 Jun 2012 08:36:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340872573!29913924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25372 invoked from network); 28 Jun 2012 08:36:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:36:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:35:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 09:35:42 +0100
Message-ID: <1340872541.10942.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 09:35:41 +0100
In-Reply-To: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 08:59 +0100, Matt Wilson wrote:
> All of the other "list" verbs are of the form "$noun-list". For
> example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> 
> Additionally, many people have well trained muscle memory from years
> of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> in "command not implemented".
> 
> Finally, this command was missing from the xl man page.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I think this appropriate for 4.2.

> 
> diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
>  this, by ensuring certain VCPUs can only run on certain physical
>  CPUs.
>  
> +=item B<vm-list>
> +
> +Prints information about all domains except for dom0.
> +
> +B<EXAMPLE>
> +
> +An example format for the list is as follows:
> +
> +UUID                                  ID    name
> +59e1cf6c-6ab9-4879-90e7-adc8d1c63bf5  2    win
> +50bc8f75-81d0-4d53-b2e6-95cb44e2682e  3    linux
> +
>  =item B<vncviewer> [I<OPTIONS>] I<domain-id>
>  
>  Attach to domain's VNC server, forking a vncviewer process.
> diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl.h
> --- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
> @@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
>  int main_shutdown(int argc, char **argv);
>  int main_reboot(int argc, char **argv);
>  int main_list(int argc, char **argv);
> -int main_list_vm(int argc, char **argv);
> +int main_vm_list(int argc, char **argv);
>  int main_create(int argc, char **argv);
>  int main_config_update(int argc, char **argv);
>  int main_button_press(int argc, char **argv);
> diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
>      return 0;
>  }
>  
> -int main_list_vm(int argc, char **argv)
> +int main_vm_list(int argc, char **argv)
>  {
>      int opt;
>  
> -    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
> +    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
>          return opt;
>  
>      list_vm();
> diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
>        "Set the number of active VCPUs allowed for the domain",
>        "<Domain> <vCPUs>",
>      },
> -    { "list-vm",
> -      &main_list_vm, 0, 0,
> -      "List the VMs,without DOM0",
> +    { "vm-list",
> +      &main_vm_list, 0, 0,
> +      "List the VMs, without DOM0",
>        "",
>      },
>      { "info",



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:36:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAD2-0005on-Je; Thu, 28 Jun 2012 08:36: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 1SkAD1-0005oF-B6
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:36:15 +0000
Received: from [85.158.138.51:55296] by server-9.bemta-3.messagelabs.com id
	11/1B-10419-E771CEF4; Thu, 28 Jun 2012 08:36:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340872573!29913924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25372 invoked from network); 28 Jun 2012 08:36:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:36:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:35:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 09:35:42 +0100
Message-ID: <1340872541.10942.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Thu, 28 Jun 2012 09:35:41 +0100
In-Reply-To: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 08:59 +0100, Matt Wilson wrote:
> All of the other "list" verbs are of the form "$noun-list". For
> example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> 
> Additionally, many people have well trained muscle memory from years
> of typing "xm li". "xl li" was ambiguous due to "xl list-vm" resulted
> in "command not implemented".
> 
> Finally, this command was missing from the xl man page.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I think this appropriate for 4.2.

> 
> diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
>  this, by ensuring certain VCPUs can only run on certain physical
>  CPUs.
>  
> +=item B<vm-list>
> +
> +Prints information about all domains except for dom0.
> +
> +B<EXAMPLE>
> +
> +An example format for the list is as follows:
> +
> +UUID                                  ID    name
> +59e1cf6c-6ab9-4879-90e7-adc8d1c63bf5  2    win
> +50bc8f75-81d0-4d53-b2e6-95cb44e2682e  3    linux
> +
>  =item B<vncviewer> [I<OPTIONS>] I<domain-id>
>  
>  Attach to domain's VNC server, forking a vncviewer process.
> diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl.h
> --- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
> @@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
>  int main_shutdown(int argc, char **argv);
>  int main_reboot(int argc, char **argv);
>  int main_list(int argc, char **argv);
> -int main_list_vm(int argc, char **argv);
> +int main_vm_list(int argc, char **argv);
>  int main_create(int argc, char **argv);
>  int main_config_update(int argc, char **argv);
>  int main_button_press(int argc, char **argv);
> diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
>      return 0;
>  }
>  
> -int main_list_vm(int argc, char **argv)
> +int main_vm_list(int argc, char **argv)
>  {
>      int opt;
>  
> -    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
> +    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
>          return opt;
>  
>      list_vm();
> diff -r 32034d1914a6 -r 5b1ed71c74d6 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
> @@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
>        "Set the number of active VCPUs allowed for the domain",
>        "<Domain> <vCPUs>",
>      },
> -    { "list-vm",
> -      &main_list_vm, 0, 0,
> -      "List the VMs,without DOM0",
> +    { "vm-list",
> +      &main_vm_list, 0, 0,
> +      "List the VMs, without DOM0",
>        "",
>      },
>      { "info",



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAHB-0006PW-DA; Thu, 28 Jun 2012 08:40: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 1SkAH9-0006P9-VO
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:40:32 +0000
Received: from [85.158.138.51:42406] by server-5.bemta-3.messagelabs.com id
	D5/4C-01572-A781CEF4; Thu, 28 Jun 2012 08:40:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340872825!25905895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7273 invoked from network); 28 Jun 2012 08:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:40:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 09:40:24 +0100
Message-ID: <1340872823.10942.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 28 Jun 2012 09:40:23 +0100
In-Reply-To: <CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
	<1340861601.5210.6.camel@dagon.hellion.org.uk>
	<CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 08:56 +0100, ZhouPeng wrote:
> version 4
> 
> Thanks.
> --
> 
> tools:libxl: refactor stdvga opinon support.
> 
> Be ready to add and describe new vga interface
> 
> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 592d15bd4d5e tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/libxl_create.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -189,7 +189,8 @@ int libxl__domain_build_info_setdefault(
>              if (!b_info->u.hvm.boot) return ERROR_NOMEM;
>          }
> 
> -        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
> +        if (!b_info->u.hvm.vga.kind)
> +            b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>          libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
>          if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>              libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
> diff -r 592d15bd4d5e tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/libxl_dm.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -175,8 +175,13 @@ static char ** libxl__build_device_model
>                                     libxl__sizekb_to_mb(b_info->video_memkb)),
>                      NULL);
>          }
> -        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
> +
> +        switch (b_info->u.hvm.vga.kind) {
> +        case LIBXL_VGA_INTERFACE_TYPE_STD:
>              flexarray_append(dm_args, "-std-vga");
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
> +            break;
>          }
> 
>          if (b_info->u.hvm.boot) {
> @@ -418,8 +423,13 @@ static char ** libxl__build_device_model
>              flexarray_append(dm_args, spiceoptions);
>          }
> 
> -        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
> -                flexarray_vappend(dm_args, "-vga", "std", NULL);
> +        switch (b_info->u.hvm.vga.kind) {
> +        case LIBXL_VGA_INTERFACE_TYPE_STD:
> +            flexarray_vappend(dm_args, "-vga", "std", NULL);
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
> +            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            break;
>          }
> 
>          if (b_info->u.hvm.boot) {
> diff -r 592d15bd4d5e tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/libxl_types.idl	Thu Jun 28 15:50:10 2012 +0800
> @@ -125,9 +125,19 @@ libxl_shutdown_reason = Enumeration("shu
>      (4, "watchdog"),
>      ])
> 
> +libxl_vga_interface_type = Enumeration("vga_interface_type", [
> +    (1, "CIRRUS"),
> +    (2, "STD"),
> +    ], init_val = 0)
> +
>  #
>  # Complex libxl types
>  #
> +
> +libxl_vga_interface_info = Struct("vga_interface_info", [
> +    ("kind",    libxl_vga_interface_type),
> +    ])
> +
>  libxl_vnc_info = Struct("vnc_info", [
>      ("enable",        libxl_defbool),
>      # "address:port" that should be listened on
> @@ -286,7 +296,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("nested_hvm",       libxl_defbool),
>                                         ("incr_generationid",libxl_defbool),
>                                         ("nographic",        libxl_defbool),
> -                                       ("stdvga",           libxl_defbool),
> +                                       ("vga",
> libxl_vga_interface_info),
>                                         ("vnc",              libxl_vnc_info),
>                                         # keyboard layout, default is
> en-us keyboard
>                                         ("keymap",           string),
> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -1256,7 +1256,10 @@ skip_vfb:
>  #undef parse_extra_args
> 
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> +        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;
> +
>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
>          xlu_cfg_replace_string (config, "vnclisten",
>                                  &b_info->u.hvm.vnc.listen, 0);
> diff -r 592d15bd4d5e tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/xl_sxp.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
>          printf("\t\t\t(no_incr_generationid %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
> -        printf("\t\t\t(stdvga %s)\n",
> -               libxl_defbool_to_string(b_info->u.hvm.stdvga));
> +        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind ==
> +                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
> +                                      "True" : "False");
>          printf("\t\t\t(vnc %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
>          printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> 
> On Thu, Jun 28, 2012 at 1:33 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-06-28 at 02:42 +0100, ZhouPeng wrote:
> >> On Wed, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> >> >> --- a/tools/libxl/xl_cmdimpl.c  Fri May 18 16:19:21 2012 +0100
> >> >> +++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 20:06:39 2012 +0800
> >> >> @@ -1256,7 +1256,10 @@ skip_vfb:
> >> >>  #undef parse_extra_args
> >> >>
> >> >>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >> >> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> >> >> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> >> >> +            if (l)
> >> >> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
> >> >
> >> > I think this needs to be:
> >> >          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;
> >> >
> >> > so that both "stdvga=0" and "stdvga=1" result in what the user asked for
> >> > without relying on the libxl default remaining CIRRUS.
> >>
> >> IMHO, this make simple to be complex.
> >>
> >> I think the check  and set-default later in libxl_create.c as a whole is enough.
> >
> > This is in libxl, as I said above xl should not rely on the default
> > remaining CIRRUS.
> >
> > If the user says "stdvga=0" then xl needs to explicitly ask for CIRRUS,
> > despite the fact that it currently happens to be the default.
> >
> > If we make the libxl default BLARGLE in the future then stdvga=0 still
> > needs to mean CIRRUS.
> >
> >> +        if (!b_info->u.hvm.vga.kind)
> >> +            b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> >>
> >> 'as a whole' here, I means if more vga type added in the future, we
> >> don't need to set the default one by one, redundantly.
> >
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAHB-0006PW-DA; Thu, 28 Jun 2012 08:40: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 1SkAH9-0006P9-VO
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:40:32 +0000
Received: from [85.158.138.51:42406] by server-5.bemta-3.messagelabs.com id
	D5/4C-01572-A781CEF4; Thu, 28 Jun 2012 08:40:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340872825!25905895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7273 invoked from network); 28 Jun 2012 08:40:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:40:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:40:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 09:40:24 +0100
Message-ID: <1340872823.10942.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ZhouPeng <zpengxen@gmail.com>
Date: Thu, 28 Jun 2012 09:40:23 +0100
In-Reply-To: <CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
	<1340861601.5210.6.camel@dagon.hellion.org.uk>
	<CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 08:56 +0100, ZhouPeng wrote:
> version 4
> 
> Thanks.
> --
> 
> tools:libxl: refactor stdvga opinon support.
> 
> Be ready to add and describe new vga interface
> 
> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 592d15bd4d5e tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/libxl_create.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -189,7 +189,8 @@ int libxl__domain_build_info_setdefault(
>              if (!b_info->u.hvm.boot) return ERROR_NOMEM;
>          }
> 
> -        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
> +        if (!b_info->u.hvm.vga.kind)
> +            b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>          libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
>          if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
>              libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
> diff -r 592d15bd4d5e tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/libxl_dm.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -175,8 +175,13 @@ static char ** libxl__build_device_model
>                                     libxl__sizekb_to_mb(b_info->video_memkb)),
>                      NULL);
>          }
> -        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
> +
> +        switch (b_info->u.hvm.vga.kind) {
> +        case LIBXL_VGA_INTERFACE_TYPE_STD:
>              flexarray_append(dm_args, "-std-vga");
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
> +            break;
>          }
> 
>          if (b_info->u.hvm.boot) {
> @@ -418,8 +423,13 @@ static char ** libxl__build_device_model
>              flexarray_append(dm_args, spiceoptions);
>          }
> 
> -        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
> -                flexarray_vappend(dm_args, "-vga", "std", NULL);
> +        switch (b_info->u.hvm.vga.kind) {
> +        case LIBXL_VGA_INTERFACE_TYPE_STD:
> +            flexarray_vappend(dm_args, "-vga", "std", NULL);
> +            break;
> +        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
> +            flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            break;
>          }
> 
>          if (b_info->u.hvm.boot) {
> diff -r 592d15bd4d5e tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/libxl_types.idl	Thu Jun 28 15:50:10 2012 +0800
> @@ -125,9 +125,19 @@ libxl_shutdown_reason = Enumeration("shu
>      (4, "watchdog"),
>      ])
> 
> +libxl_vga_interface_type = Enumeration("vga_interface_type", [
> +    (1, "CIRRUS"),
> +    (2, "STD"),
> +    ], init_val = 0)
> +
>  #
>  # Complex libxl types
>  #
> +
> +libxl_vga_interface_info = Struct("vga_interface_info", [
> +    ("kind",    libxl_vga_interface_type),
> +    ])
> +
>  libxl_vnc_info = Struct("vnc_info", [
>      ("enable",        libxl_defbool),
>      # "address:port" that should be listened on
> @@ -286,7 +296,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("nested_hvm",       libxl_defbool),
>                                         ("incr_generationid",libxl_defbool),
>                                         ("nographic",        libxl_defbool),
> -                                       ("stdvga",           libxl_defbool),
> +                                       ("vga",
> libxl_vga_interface_info),
>                                         ("vnc",              libxl_vnc_info),
>                                         # keyboard layout, default is
> en-us keyboard
>                                         ("keymap",           string),
> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -1256,7 +1256,10 @@ skip_vfb:
>  #undef parse_extra_args
> 
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> +        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;
> +
>          xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
>          xlu_cfg_replace_string (config, "vnclisten",
>                                  &b_info->u.hvm.vnc.listen, 0);
> diff -r 592d15bd4d5e tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Fri May 18 16:19:21 2012 +0100
> +++ b/tools/libxl/xl_sxp.c	Thu Jun 28 15:50:10 2012 +0800
> @@ -110,8 +110,9 @@ void printf_info_sexp(int domid, libxl_d
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
>          printf("\t\t\t(no_incr_generationid %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
> -        printf("\t\t\t(stdvga %s)\n",
> -               libxl_defbool_to_string(b_info->u.hvm.stdvga));
> +        printf("\t\t\t(stdvga %s)\n", b_info->u.hvm.vga.kind ==
> +                                      LIBXL_VGA_INTERFACE_TYPE_STD ?
> +                                      "True" : "False");
>          printf("\t\t\t(vnc %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
>          printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
> 
> On Thu, Jun 28, 2012 at 1:33 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-06-28 at 02:42 +0100, ZhouPeng wrote:
> >> On Wed, Jun 27, 2012 at 11:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> diff -r 592d15bd4d5e tools/libxl/xl_cmdimpl.c
> >> >> --- a/tools/libxl/xl_cmdimpl.c  Fri May 18 16:19:21 2012 +0100
> >> >> +++ b/tools/libxl/xl_cmdimpl.c  Wed Jun 27 20:06:39 2012 +0800
> >> >> @@ -1256,7 +1256,10 @@ skip_vfb:
> >> >>  #undef parse_extra_args
> >> >>
> >> >>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> >> >> -        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
> >> >> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> >> >> +            if (l)
> >> >> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
> >> >
> >> > I think this needs to be:
> >> >          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;
> >> >
> >> > so that both "stdvga=0" and "stdvga=1" result in what the user asked for
> >> > without relying on the libxl default remaining CIRRUS.
> >>
> >> IMHO, this make simple to be complex.
> >>
> >> I think the check  and set-default later in libxl_create.c as a whole is enough.
> >
> > This is in libxl, as I said above xl should not rely on the default
> > remaining CIRRUS.
> >
> > If the user says "stdvga=0" then xl needs to explicitly ask for CIRRUS,
> > despite the fact that it currently happens to be the default.
> >
> > If we make the libxl default BLARGLE in the future then stdvga=0 still
> > needs to mean CIRRUS.
> >
> >> +        if (!b_info->u.hvm.vga.kind)
> >> +            b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> >>
> >> 'as a whole' here, I means if more vga type added in the future, we
> >> don't need to set the default one by one, redundantly.
> >
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:42:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:42:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAIt-0006ck-1t; Thu, 28 Jun 2012 08:42:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkAIr-0006cW-Fj
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:42:17 +0000
Received: from [193.109.254.147:50833] by server-8.bemta-14.messagelabs.com id
	80/3D-30743-8E81CEF4; Thu, 28 Jun 2012 08:42:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340872932!9004213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13117 invoked from network); 28 Jun 2012 08:42:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:42:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:42:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 09:42:12 +0100
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 1SkAIm-0006bt-0f;
	Thu, 28 Jun 2012 08:42:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkAIl-0003CR-Us;
	Thu, 28 Jun 2012 09:42:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13380-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 09:42:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13380: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13380 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13380/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 13338

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:42:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:42:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAIt-0006ck-1t; Thu, 28 Jun 2012 08:42:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkAIr-0006cW-Fj
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:42:17 +0000
Received: from [193.109.254.147:50833] by server-8.bemta-14.messagelabs.com id
	80/3D-30743-8E81CEF4; Thu, 28 Jun 2012 08:42:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340872932!9004213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13117 invoked from network); 28 Jun 2012 08:42:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:42:12 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:42:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 09:42:12 +0100
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 1SkAIm-0006bt-0f;
	Thu, 28 Jun 2012 08:42:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkAIl-0003CR-Us;
	Thu, 28 Jun 2012 09:42:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13380-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 09:42:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13380: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13380 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13380/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 13338

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:44:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:44: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 1SkAKf-0006mj-NR; Thu, 28 Jun 2012 08:44: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 1SkAKe-0006mZ-8M
	for Xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:44:08 +0000
Received: from [85.158.139.83:58560] by server-4.bemta-5.messagelabs.com id
	B8/D4-27831-7591CEF4; Thu, 28 Jun 2012 08:44:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340873046!28643977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11768 invoked from network); 28 Jun 2012 08:44:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:44:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 09:44:06 +0100
Message-ID: <1340873045.10942.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 28 Jun 2012 09:44:05 +0100
In-Reply-To: <20120626181707.4203d336@mantra.us.oracle.com>
References: <20120626181707.4203d336@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: status 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 Wed, 2012-06-27 at 02:17 +0100, Mukesh Rathor wrote:
> Hi Guys,
> 
> Just a quick status update. I refreshed my trees and then debugged as
> the code had changed a lot. I'm again few weeks behind from the latest
> tree on both linux and xen. After the refresh, I ran into few issues:
> 
>    - xenstored is using gnttab interface that will not work for hybrid
>      For now I just disabled it.

OOI what's the conflict?

>    - libxl has changed a lot, so for now, I'm only supporting 
>           disk = ['phy:/dev/loop1,xvda,w']

I'd have thought disk backend would be unrelated to hybrid, other than
any backend which uses gnttab I guess (hrm, maybe that's all except for
blkback.).

[...]
> Once I finish the changes for hyb_vcpu union, I should be able to get
> things working again. Then I'll refresh the linux tree, keeping xen the
> same, and test it all out and submit linux patch. After that I'll
> refresh xen tree and keeping same linux, test it out, and submit patch. 

We'd probably want to have both patches reviewed before accepting
either, wouldn't we? We don't want to commit to an interface on one side
before reviewing the other. (I'm not sure if you mean "submit" as in
"RFC" or as in "please commit this").

That needed necessarily mean they come through simultaneously though,
although review of one might be limited without the other.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:44:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:44: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 1SkAKf-0006mj-NR; Thu, 28 Jun 2012 08:44: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 1SkAKe-0006mZ-8M
	for Xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:44:08 +0000
Received: from [85.158.139.83:58560] by server-4.bemta-5.messagelabs.com id
	B8/D4-27831-7591CEF4; Thu, 28 Jun 2012 08:44:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340873046!28643977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMxOTg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11768 invoked from network); 28 Jun 2012 08:44:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 08:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13261912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 08:44:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 09:44:06 +0100
Message-ID: <1340873045.10942.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 28 Jun 2012 09:44:05 +0100
In-Reply-To: <20120626181707.4203d336@mantra.us.oracle.com>
References: <20120626181707.4203d336@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: status 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 Wed, 2012-06-27 at 02:17 +0100, Mukesh Rathor wrote:
> Hi Guys,
> 
> Just a quick status update. I refreshed my trees and then debugged as
> the code had changed a lot. I'm again few weeks behind from the latest
> tree on both linux and xen. After the refresh, I ran into few issues:
> 
>    - xenstored is using gnttab interface that will not work for hybrid
>      For now I just disabled it.

OOI what's the conflict?

>    - libxl has changed a lot, so for now, I'm only supporting 
>           disk = ['phy:/dev/loop1,xvda,w']

I'd have thought disk backend would be unrelated to hybrid, other than
any backend which uses gnttab I guess (hrm, maybe that's all except for
blkback.).

[...]
> Once I finish the changes for hyb_vcpu union, I should be able to get
> things working again. Then I'll refresh the linux tree, keeping xen the
> same, and test it all out and submit linux patch. After that I'll
> refresh xen tree and keeping same linux, test it out, and submit patch. 

We'd probably want to have both patches reviewed before accepting
either, wouldn't we? We don't want to commit to an interface on one side
before reviewing the other. (I'm not sure if you mean "submit" as in
"RFC" or as in "please commit this").

That needed necessarily mean they come through simultaneously though,
although review of one might be limited without the other.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:50:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAQF-00079R-HD; Thu, 28 Jun 2012 08:49: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 1SkAQE-00079H-NM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:49:54 +0000
Received: from [85.158.138.51:30381] by server-11.bemta-3.messagelabs.com id
	52/7C-02904-1BA1CEF4; Thu, 28 Jun 2012 08:49:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340873393!11274394!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22771 invoked from network); 28 Jun 2012 08:49:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 08:49:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 09:49:52 +0100
Message-Id: <4FEC36F8020000780008C63F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 09:50:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjmO0ngu32ObjM8+4vSUebGzEoOnyuRACOTuMJp1+eiAMQ@mail.gmail.com>
In-Reply-To: <CABs9EjmO0ngu32ObjM8+4vSUebGzEoOnyuRACOTuMJp1+eiAMQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pt_iomul_init 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

>>> On 28.06.12 at 02:27, Rolu <rolu@roce.org> wrote:
> * Is there a way for pt_iomul_init or register_real_device to know
> that there isn't an IO multiplexer, so there is no point in trying to
> initialize it?

For that, it needs to look at the /dev entry. Its absence says that
there is no multiplexer (was never ported to pv-ops).

Perhaps a better thing to look into would be whether the code
paths later trying to use the multiplexer are conditional upon
something that can also be used to control its initialization (i.e.
see whether initialization can be avoided even if a multiplexer
exists, but isn't needed for a particular device).

> * Maybe a configuration file switch that defaults to off?

Sounds odd.

> * Reword the message so it doesn't claim there is an error? "You do
> not appear to have a PCI IO space multiplexer driver. Can't open file
> /dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0"

This is an error if multiplexing is needed. Whether one can tell
from user space whether it is needed 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 Thu Jun 28 08:50:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAQF-00079R-HD; Thu, 28 Jun 2012 08:49: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 1SkAQE-00079H-NM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:49:54 +0000
Received: from [85.158.138.51:30381] by server-11.bemta-3.messagelabs.com id
	52/7C-02904-1BA1CEF4; Thu, 28 Jun 2012 08:49:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340873393!11274394!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22771 invoked from network); 28 Jun 2012 08:49:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 08:49:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 09:49:52 +0100
Message-Id: <4FEC36F8020000780008C63F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 09:50:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjmO0ngu32ObjM8+4vSUebGzEoOnyuRACOTuMJp1+eiAMQ@mail.gmail.com>
In-Reply-To: <CABs9EjmO0ngu32ObjM8+4vSUebGzEoOnyuRACOTuMJp1+eiAMQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pt_iomul_init 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

>>> On 28.06.12 at 02:27, Rolu <rolu@roce.org> wrote:
> * Is there a way for pt_iomul_init or register_real_device to know
> that there isn't an IO multiplexer, so there is no point in trying to
> initialize it?

For that, it needs to look at the /dev entry. Its absence says that
there is no multiplexer (was never ported to pv-ops).

Perhaps a better thing to look into would be whether the code
paths later trying to use the multiplexer are conditional upon
something that can also be used to control its initialization (i.e.
see whether initialization can be avoided even if a multiplexer
exists, but isn't needed for a particular device).

> * Maybe a configuration file switch that defaults to off?

Sounds odd.

> * Reword the message so it doesn't claim there is an error? "You do
> not appear to have a PCI IO space multiplexer driver. Can't open file
> /dev/xen/pci_iomul: No such file or directory: 0x0:0x14.0x0"

This is an error if multiplexing is needed. Whether one can tell
from user space whether it is needed 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 Thu Jun 28 08:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAV4-0007bF-J6; Thu, 28 Jun 2012 08:54:54 +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 1SkAV2-0007as-Pi
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:54:53 +0000
Received: from [193.109.254.147:36855] by server-1.bemta-14.messagelabs.com id
	8D/64-24612-CDB1CEF4; Thu, 28 Jun 2012 08:54:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340873686!8818526!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyMTc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2717 invoked from network); 28 Jun 2012 08:54:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-27.messagelabs.com with SMTP;
	28 Jun 2012 08:54:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 01:54:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="txt'?scan'208";a="163875263"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 28 Jun 2012 01:54:43 -0700
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; Thu, 28 Jun 2012 01:54:43 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 16:54:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVGbW1l9vq4iTRyWE8p2SJy8j95cPaWDw
Date: Thu, 28 Jun 2012 08:54:40 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
In-Reply-To: <4FEB236C020000780008C392@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="_002_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan Beulich wrote:
>>>> On 27.06.12 at 05:51, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> This is updated xen vMCE design foils, according to comments from
>> community recently.=20
>>=20
>> This foils focus on vMCE part of Xen MCA, so as Keir said, it's some
>> dense. Later Will will present a document to elaborate more,
>> including Intel MCA and surrounding features and Xen implementation.
>=20
> For MCi_CTL2 you probably meant to say "allow setting CMCI_EN
> and error count threshold"?

Yes, exactly! the words is w/ subtle but important different meaning.

>=20
> The 2-bank approach also needs to be brought in line with the
> current host derived value in MCG_CAP, especially if the code to
> implement this new model doesn't make it into 4.2 (which would
> generally save a larger value).
>=20
> Jan

Let me repeat in my word to avoid misunderstanding about your concern:
Your concern rooted from the history patch (c/s 24887, as attached) which u=
sed to solve vMCE migration issue caused from bank number. I guess the patc=
h was not in xen4.1.x but would be in xen 4.2 release recently (right? and =
when will xen 4.2 release?)
Per my understanding, you want us to make sure our new vMCE model compatibl=
e w/ olde vMCE. For example if our patch in xen 4.3 release, you want to ma=
ke sure a guest migrate from xen 4.2 to 4.3 would not broken. Is this your =
concern?

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Thu, 28 Jun 2012 08:54:39 GMT";
	modification-date="Thu, 28 Jun 2012 08:54:39 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; Wed, 15 Feb 2012 19:04:26 +0800
Received: from fmsmsx108.amr.corp.intel.com (10.19.9.228) by
 SHSMSX101.ccr.corp.intel.com (10.239.4.153) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Wed, 15 Feb 2012 19:04:25 +0800
Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by
 FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Wed, 15 Feb 2012 03:04:24 -0800
Received: from azsmga001.ch.intel.com (10.2.17.19) by rrsmsx601-1.rr.intel.com
 (10.31.0.151) with Microsoft SMTP Server id 8.2.255.0; Wed, 15 Feb 2012
 04:03:48 -0700
Received: from azsmga102.ch.intel.com ([10.2.16.52])  by
 azsmga001-1.ch.intel.com with ESMTP; 15 Feb 2012 03:03:46 -0800
Received: from lists.xen.org ([50.57.142.19])  by mga14.intel.com with ESMTP;
 15 Feb 2012 03:03:44 -0800
Received: from localhost ([127.0.0.1] helo=lists.xen.org)	by lists.xen.org
 with esmtp (Exim 4.72)	(envelope-from
 <xen-devel-bounces@lists.xensource.com>)	id 1Rxcbo-0008F8-C8; Wed, 15 Feb
 2012 11:01:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])	by lists.xen.org with
 esmtp (Exim 4.72)	(envelope-from <JBeulich@suse.com>) id 1Rxcbm-0008EN-Ur	for
 xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:01:11 +0000
Received: (qmail 24767 invoked from network); 15 Feb 2012 11:01:03 -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; 15 Feb 2012 11:01:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com	with Novell_GroupWise; Wed,
 15 Feb 2012 11:01:04 +0000
From: Jan Beulich <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
CC: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 2/2] x86/vMCE: save/restore MCA capabilities
Thread-Topic: [Xen-devel] [PATCH 2/2] x86/vMCE: save/restore MCA capabilities
Thread-Index: AQHM69GUIaRbcUEjU0SZ9CYw3vbbqA==
Sender: "xen-devel-bounces@lists.xensource.com"
	<xen-devel-bounces@lists.xensource.com>
Date: Wed, 15 Feb 2012 11:01:02 +0000
Message-ID: <4F3B9E7E0200007800073218@nat28.tlf.novell.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: rrsmsx601.amr.corp.intel.com
X-MS-Has-Attach: yes
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.71,315,1320652800";
    d="scan'208";a="794129760"
x-mailman-version: 2.1.13
errors-to: xen-devel-bounces@lists.xensource.com
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AgcBAAjU304yOY4TmWdsb2JhbAAtFoIFqFEiAQEBAQEICwsHFB4HgXQGAQEMAQoNHwoeCwMDAQIGAjUPBAgDASQ1EwWIBAakPQGSN4d0gl1jBIx0KAF1hDWCJJIj
x-env-sender: JBeulich@suse.com
x-originating-ip: [130.57.49.28]
x-msg-ref: server-13.tower-174.messagelabs.com!1329303662!8301262!1
x-viruschecked: Checked
x-starscan-version: 6.5.5; banners=-,-,-
x-beenthere: xen-devel@lists.xensource.com
list-id: Xen developer discussion <xen-devel.lists.xensource.com>
list-post: <mailto:xen-devel@lists.xensource.com>
x-spamreason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
Content-Type: multipart/mixed;
	boundary="_003_4F3B9E7E0200007800073218nat28tlfnovellcom_"
MIME-Version: 1.0

--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8AB1E9C344A8F84FB012A9ADB2E5E536@intel.com>
Content-Transfer-Encoding: quoted-printable

This allows migration to a host with less MCA banks than the source
host had, while without this patch accesses to the excess banks' MSRs
caused #GP-s in the guest after migration (and it depended on the guest
kernel whether this would be fatal).

A fundamental question is whether we should also save/restore MCG_CTL
and MCi_CTL, as the HVM save record would better be defined to the
complete state that needs saving from the beginning (I'm unsure whether
the save/restore logic allows for future extension of an existing
record).

Of course, this change is expected to make migration from new to older
Xen impossible (again I'm unsure what the save/restore logic does with
records it doesn't even know about).

The (trivial) tools side change may seem unrelated, but the code should
have been that way from the beginning to allow the hypervisor to look
at currently unused ext_vcpucontext fields without risking to read
garbage when those fields get a meaning assigned in the future. This
isn't being enforced here - should it be? (Obviously, for backwards
compatibility, the hypervisor must assume these fields to be clear only
when the extended context's size exceeds the old original one.)

A future addition to this change might be to allow configuration of the
number of banks and other MCA capabilities for a guest before it starts
(i.e. to not inherits the values seen on the first host it runs on).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); break=
;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern unsigned int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_b=
anks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_ba=
nks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_ba=
nks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)
            nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;
     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;
     dom_vmce(d)->nr_injection =3D 0;
=20
@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.mcg_cap =3D g_mcg_cap;
+}
+
+int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+{
+    if ( caps & ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    {
+        dprintk(XENLOG_G_ERR, "%s restore: unsupported MCA capabilities"
+                " %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",
+                is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,
+                v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);
+        return -EPERM;
+    }
+
+    v->arch.mcg_cap =3D caps;
+    return 0;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *va=
l)
+{
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +146,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -162,39 +182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D vmce->mcg_cap;
+        *val =3D cur->arch.mcg_cap;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Always 0 if no CTL support */
-        *val =3D vmce->mcg_ctl & h_mcg_ctl;
+        if ( cur->arch.mcg_cap & MCG_CTL_P )
+            *val =3D vmce->mcg_ctl & h_mcg_ctl;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +221,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +247,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +285,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", val);
         /* For HVM guest, this is the point for deleting vMCE injection no=
de */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +312,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0=
;
         break;
     }
=20
@@ -301,6 +320,46 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .caps =3D v->arch.mcg_cap
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL )
+    {
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
+        err =3D -EINVAL;
+    }
+    else
+        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+
+    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
+    vmce_init_vcpu(v);
+
     if ( is_hvm_domain(d) )
     {
         rc =3D hvm_vcpu_initialise(v);
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->mcg_cap =3D v->arch.mcg_cap;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,10 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
+                              sizeof(evc->mcg_cap) )
+                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been us=
ed,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint64_t mcg_cap;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -16,7 +16,6 @@ struct bank_entry {
 struct domain_mca_msrs
 {
     /* Guest should not change below values after DOM boot up */
-    uint64_t mcg_cap;
     uint64_t mcg_ctl;
     uint64_t mcg_status;
     uint64_t *mci_ctl;
@@ -28,6 +27,8 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
+extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint64_t caps;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint64_aligned_t mcg_cap;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;



--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Description: x86-vmce-sr.patch
Content-Disposition: attachment; filename="x86-vmce-sr.patch"; size=16665;
	creation-date="Wed, 15 Feb 2012 11:04:26 GMT";
	modification-date="Wed, 15 Feb 2012 11:04:26 GMT"
Content-ID: <D3C3E22374CA4A47B197E04B09C1C586@intel.com>
Content-Transfer-Encoding: base64

eDg2L3ZNQ0U6IHNhdmUvcmVzdG9yZSBNQ0EgY2FwYWJpbGl0aWVzCgpUaGlzIGFsbG93cyBtaWdy
YXRpb24gdG8gYSBob3N0IHdpdGggbGVzcyBNQ0EgYmFua3MgdGhhbiB0aGUgc291cmNlCmhvc3Qg
aGFkLCB3aGlsZSB3aXRob3V0IHRoaXMgcGF0Y2ggYWNjZXNzZXMgdG8gdGhlIGV4Y2VzcyBiYW5r
cycgTVNScwpjYXVzZWQgI0dQLXMgaW4gdGhlIGd1ZXN0IGFmdGVyIG1pZ3JhdGlvbiAoYW5kIGl0
IGRlcGVuZGVkIG9uIHRoZSBndWVzdAprZXJuZWwgd2hldGhlciB0aGlzIHdvdWxkIGJlIGZhdGFs
KS4KCkEgZnVuZGFtZW50YWwgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBzaG91bGQgYWxzbyBzYXZl
L3Jlc3RvcmUgTUNHX0NUTAphbmQgTUNpX0NUTCwgYXMgdGhlIEhWTSBzYXZlIHJlY29yZCB3b3Vs
ZCBiZXR0ZXIgYmUgZGVmaW5lZCB0byB0aGUKY29tcGxldGUgc3RhdGUgdGhhdCBuZWVkcyBzYXZp
bmcgZnJvbSB0aGUgYmVnaW5uaW5nIChJJ20gdW5zdXJlIHdoZXRoZXIKdGhlIHNhdmUvcmVzdG9y
ZSBsb2dpYyBhbGxvd3MgZm9yIGZ1dHVyZSBleHRlbnNpb24gb2YgYW4gZXhpc3RpbmcKcmVjb3Jk
KS4KCk9mIGNvdXJzZSwgdGhpcyBjaGFuZ2UgaXMgZXhwZWN0ZWQgdG8gbWFrZSBtaWdyYXRpb24g
ZnJvbSBuZXcgdG8gb2xkZXIKWGVuIGltcG9zc2libGUgKGFnYWluIEknbSB1bnN1cmUgd2hhdCB0
aGUgc2F2ZS9yZXN0b3JlIGxvZ2ljIGRvZXMgd2l0aApyZWNvcmRzIGl0IGRvZXNuJ3QgZXZlbiBr
bm93IGFib3V0KS4KClRoZSAodHJpdmlhbCkgdG9vbHMgc2lkZSBjaGFuZ2UgbWF5IHNlZW0gdW5y
ZWxhdGVkLCBidXQgdGhlIGNvZGUgc2hvdWxkCmhhdmUgYmVlbiB0aGF0IHdheSBmcm9tIHRoZSBi
ZWdpbm5pbmcgdG8gYWxsb3cgdGhlIGh5cGVydmlzb3IgdG8gbG9vawphdCBjdXJyZW50bHkgdW51
c2VkIGV4dF92Y3B1Y29udGV4dCBmaWVsZHMgd2l0aG91dCByaXNraW5nIHRvIHJlYWQKZ2FyYmFn
ZSB3aGVuIHRob3NlIGZpZWxkcyBnZXQgYSBtZWFuaW5nIGFzc2lnbmVkIGluIHRoZSBmdXR1cmUu
IFRoaXMKaXNuJ3QgYmVpbmcgZW5mb3JjZWQgaGVyZSAtIHNob3VsZCBpdCBiZT8gKE9idmlvdXNs
eSwgZm9yIGJhY2t3YXJkcwpjb21wYXRpYmlsaXR5LCB0aGUgaHlwZXJ2aXNvciBtdXN0IGFzc3Vt
ZSB0aGVzZSBmaWVsZHMgdG8gYmUgY2xlYXIgb25seQp3aGVuIHRoZSBleHRlbmRlZCBjb250ZXh0
J3Mgc2l6ZSBleGNlZWRzIHRoZSBvbGQgb3JpZ2luYWwgb25lLikKCkEgZnV0dXJlIGFkZGl0aW9u
IHRvIHRoaXMgY2hhbmdlIG1pZ2h0IGJlIHRvIGFsbG93IGNvbmZpZ3VyYXRpb24gb2YgdGhlCm51
bWJlciBvZiBiYW5rcyBhbmQgb3RoZXIgTUNBIGNhcGFiaWxpdGllcyBmb3IgYSBndWVzdCBiZWZv
cmUgaXQgc3RhcnRzCihpLmUuIHRvIG5vdCBpbmhlcml0cyB0aGUgdmFsdWVzIHNlZW4gb24gdGhl
IGZpcnN0IGhvc3QgaXQgcnVucyBvbikuCgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJl
dWxpY2hAc3VzZS5jb20+CgotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCisrKyBi
L3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMKQEAgLTE4NzksNiArMTg3OSw3IEBAIGludCB4
Y19kb21haW5fc2F2ZSh4Y19pbnRlcmZhY2UgKnhjaCwgaW4KIAogICAgICAgICBkb21jdGwuY21k
ID0gWEVOX0RPTUNUTF9nZXRfZXh0X3ZjcHVjb250ZXh0OwogICAgICAgICBkb21jdGwuZG9tYWlu
ID0gZG9tOworICAgICAgICBtZW1zZXQoJmRvbWN0bC51LCAwLCBzaXplb2YoZG9tY3RsLnUpKTsK
ICAgICAgICAgZG9tY3RsLnUuZXh0X3ZjcHVjb250ZXh0LnZjcHUgPSBpOwogICAgICAgICBpZiAo
IHhjX2RvbWN0bCh4Y2gsICZkb21jdGwpIDwgMCApCiAgICAgICAgIHsKLS0tIGEvdG9vbHMvbWlz
Yy94ZW4taHZtY3R4LmMKKysrIGIvdG9vbHMvbWlzYy94ZW4taHZtY3R4LmMKQEAgLTM4Myw2ICsz
ODMsMTMgQEAgc3RhdGljIHZvaWQgZHVtcF92aXJpZGlhbl92Y3B1KHZvaWQpCiAgICAgICAgICAg
ICh1bnNpZ25lZCBsb25nIGxvbmcpIHAuYXBpY19hc3Npc3QpOyAgICAgICAgICAgCiB9CiAKK3N0
YXRpYyB2b2lkIGR1bXBfdm1jZV92Y3B1KHZvaWQpCit7CisgICAgSFZNX1NBVkVfVFlQRShWTUNF
X1ZDUFUpIHA7CisgICAgUkVBRChwKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6IGNhcHMg
JSIgUFJJeDY0ICJcbiIsIHAuY2Fwcyk7Cit9CisKIGludCBtYWluKGludCBhcmdjLCBjaGFyICoq
YXJndikKIHsKICAgICBpbnQgZW50cnksIGRvbWlkOwpAQCAtNDQ5LDYgKzQ1Niw3IEBAIGludCBt
YWluKGludCBhcmdjLCBjaGFyICoqYXJndikKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKE1U
UlIpOiBkdW1wX210cnIoKTsgYnJlYWs7CiAgICAgICAgIGNhc2UgSFZNX1NBVkVfQ09ERShWSVJJ
RElBTl9ET01BSU4pOiBkdW1wX3ZpcmlkaWFuX2RvbWFpbigpOyBicmVhazsKICAgICAgICAgY2Fz
ZSBIVk1fU0FWRV9DT0RFKFZJUklESUFOX1ZDUFUpOiBkdW1wX3ZpcmlkaWFuX3ZjcHUoKTsgYnJl
YWs7CisgICAgICAgIGNhc2UgSFZNX1NBVkVfQ09ERShWTUNFX1ZDUFUpOiBkdW1wX3ZtY2VfdmNw
dSgpOyBicmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKEVORCk6IGJyZWFrOwogICAg
ICAgICBkZWZhdWx0OgogICAgICAgICAgICAgcHJpbnRmKCIgKiogRG9uJ3QgdW5kZXJzdGFuZCB0
eXBlICV1OiBza2lwcGluZ1xuIiwKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgK
KysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgKQEAgLTMsNiArMyw3IEBACiAjZGVm
aW5lIF9NQ0VfSAogCiAjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQu
aD4KICNpbmNsdWRlIDx4ZW4vc21wLmg+CiAjaW5jbHVkZSA8YXNtL3R5cGVzLmg+CiAjaW5jbHVk
ZSA8YXNtL3RyYXBzLmg+CkBAIC01NCw4ICs1NSw4IEBAIGludCB1bm1tYXBfYnJva2VuX3BhZ2Uo
c3RydWN0IGRvbWFpbiAqZCwKIHU2NCBtY2VfY2FwX2luaXQodm9pZCk7CiBleHRlcm4gdW5zaWdu
ZWQgaW50IGZpcnN0YmFuazsKIAotaW50IGludGVsX21jZV9yZG1zcih1aW50MzJfdCBtc3IsIHVp
bnQ2NF90ICp2YWwpOwotaW50IGludGVsX21jZV93cm1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90
IHZhbCk7CitpbnQgaW50ZWxfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICosIHVpbnQzMl90
IG1zciwgdWludDY0X3QgKnZhbCk7CitpbnQgaW50ZWxfbWNlX3dybXNyKHN0cnVjdCB2Y3B1ICos
IHVpbnQzMl90IG1zciwgdWludDY0X3QgdmFsKTsKIAogc3RydWN0IG1jaW5mb19leHRlbmRlZCAq
aW50ZWxfZ2V0X2V4dGVuZGVkX21zcnMoCiAgICAgc3RydWN0IG1jaW5mb19nbG9iYWwgKm1pZywg
c3RydWN0IG1jX2luZm8gKm1pKTsKQEAgLTE3MSwxOCArMTcyLDIwIEBAIGludCB2bWNlX2RvbWFp
bl9pbmplY3Qoc3RydWN0IG1jaW5mb19iYW4KIAogZXh0ZXJuIGludCB2bWNlX2luaXQoc3RydWN0
IGNwdWluZm9feDg2ICpjKTsKIAotc3RhdGljIGlubGluZSBpbnQgbWNlX3ZlbmRvcl9iYW5rX21z
cih1aW50MzJfdCBtc3IpCitzdGF0aWMgaW5saW5lIGludCBtY2VfdmVuZG9yX2JhbmtfbXNyKGNv
bnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IpCiB7CiAgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9JTlRFTCAmJgotICAgICAgICAgbXNyID49IE1T
Ul9JQTMyX01DMF9DVEwyICYmIG1zciA8IChNU1JfSUEzMl9NQzBfQ1RMMiArIG5yX21jZV9iYW5r
cykgKQorICAgICAgICAgbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCisgICAgICAgICBtc3Ig
PCBNU1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCiAg
ICAgICAgICAgcmV0dXJuIDE7CiAgICAgcmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbmxpbmUgaW50
IG1jZV9iYW5rX21zcih1aW50MzJfdCBtc3IpCitzdGF0aWMgaW5saW5lIGludCBtY2VfYmFua19t
c3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zcikKIHsKLSAgICBpZiAoIChtc3Ig
Pj0gTVNSX0lBMzJfTUMwX0NUTCAmJiBtc3IgPCBNU1JfSUEzMl9NQ3hfQ1RMKG5yX21jZV9iYW5r
cykpIHx8Ci0gICAgICAgIG1jZV92ZW5kb3JfYmFua19tc3IobXNyKSApCisgICAgaWYgKCAobXNy
ID49IE1TUl9JQTMyX01DMF9DVEwgJiYKKyAgICAgICAgICBtc3IgPCBNU1JfSUEzMl9NQ3hfQ1RM
KHYtPmFyY2gubWNnX2NhcCAmIE1DR19DQVBfQ09VTlQpKSB8fAorICAgICAgICAgbWNlX3ZlbmRv
cl9iYW5rX21zcih2LCBtc3IpICkKICAgICAgICAgcmV0dXJuIDE7CiAgICAgcmV0dXJuIDA7CiB9
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCisrKyBiL3hlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCkBAIC0xNDIxLDExICsxNDIxLDEyIEBAIGVudW0g
bWNoZWNrX3R5cGUgaW50ZWxfbWNoZWNrX2luaXQoc3RydWMKIH0KIAogLyogaW50ZWwgc3BlY2lm
aWMgTUNBIE1TUiAqLwotaW50IGludGVsX21jZV93cm1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90
IHZhbCkKK2ludCBpbnRlbF9tY2Vfd3Jtc3Ioc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zciwg
dWludDY0X3QgdmFsKQogewogICAgIGludCByZXQgPSAwOwogCi0gICAgaWYgKG1zciA+PSBNU1Jf
SUEzMl9NQzBfQ1RMMiAmJiBtc3IgPCAoTVNSX0lBMzJfTUMwX0NUTDIgKyBucl9tY2VfYmFua3Mp
KQorICAgIGlmICggbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCisgICAgICAgICBtc3IgPCBN
U1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCiAgICAg
ewogICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIldlIGhhdmUgZGlzYWJsZWQgQ01DSSBj
YXBhYmlsaXR5LCAiCiAgICAgICAgICAgICAgICAgICJHdWVzdCBzaG91bGQgbm90IHdyaXRlIHRo
aXMgTVNSIVxuIik7CkBAIC0xNDM1LDExICsxNDM2LDEyIEBAIGludCBpbnRlbF9tY2Vfd3Jtc3Io
dWludDMyX3QgbXNyLCB1aW50NjQKICAgICByZXR1cm4gcmV0OwogfQogCi1pbnQgaW50ZWxfbWNl
X3JkbXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKK2ludCBpbnRlbF9tY2VfcmRtc3Io
Y29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKIHsKICAg
ICBpbnQgcmV0ID0gMDsKIAotICAgIGlmIChtc3IgPj0gTVNSX0lBMzJfTUMwX0NUTDIgJiYgbXNy
IDwgKE1TUl9JQTMyX01DMF9DVEwyICsgbnJfbWNlX2JhbmtzKSkKKyAgICBpZiAoIG1zciA+PSBN
U1JfSUEzMl9NQzBfQ1RMMiAmJgorICAgICAgICAgbXNyIDwgTVNSX0lBMzJfTUN4X0NUTDIodi0+
YXJjaC5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQogICAgIHsKICAgICAgICAgbWNlX3ByaW50
ayhNQ0VfUVVJRVQsICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJpbGl0eSwgIgogICAgICAg
ICAgICAgICAgICAiR3Vlc3Qgc2hvdWxkIG5vdCByZWFkIHRoaXMgTVNSIVxuIik7Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYworKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVj
ay92bWNlLmMKQEAgLTEwLDYgKzEwLDcgQEAKICNpbmNsdWRlIDx4ZW4vZGVsYXkuaD4KICNpbmNs
dWRlIDx4ZW4vc21wLmg+CiAjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8eGVuL2h2bS9z
YXZlLmg+CiAjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPHB1YmxpYy9zeXNj
dGwuaD4KICNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CkBAIC00Miw3ICs0Myw2IEBAIGludCB2bWNl
X2luaXRfbXNyKHN0cnVjdCBkb21haW4gKmQpCiAgICAgICAgICAgIG5yX21jZV9iYW5rcyAqIHNp
emVvZigqZG9tX3ZtY2UoZCktPm1jaV9jdGwpKTsKIAogICAgIGRvbV92bWNlKGQpLT5tY2dfc3Rh
dHVzID0gMHgwOwotICAgIGRvbV92bWNlKGQpLT5tY2dfY2FwID0gZ19tY2dfY2FwOwogICAgIGRv
bV92bWNlKGQpLT5tY2dfY3RsID0gfih1aW50NjRfdCkweDA7CiAgICAgZG9tX3ZtY2UoZCktPm5y
X2luamVjdGlvbiA9IDA7CiAKQEAgLTYxLDIxICs2MSw0MSBAQCB2b2lkIHZtY2VfZGVzdHJveV9t
c3Ioc3RydWN0IGRvbWFpbiAqZCkKICAgICBkb21fdm1jZShkKSA9IE5VTEw7CiB9CiAKLXN0YXRp
YyBpbnQgYmFua19tY2VfcmRtc3Ioc3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3QgbXNyLCB1aW50
NjRfdCAqdmFsKQordm9pZCB2bWNlX2luaXRfdmNwdShzdHJ1Y3QgdmNwdSAqdikKIHsKLSAgICBp
bnQgYmFuaywgcmV0ID0gMTsKLSAgICBzdHJ1Y3QgZG9tYWluX21jYV9tc3JzICp2bWNlID0gZG9t
X3ZtY2UoZCk7CisgICAgdi0+YXJjaC5tY2dfY2FwID0gZ19tY2dfY2FwOworfQorCitpbnQgdm1j
ZV9yZXN0b3JlX3ZjcHUoc3RydWN0IHZjcHUgKnYsIHVpbnQ2NF90IGNhcHMpCit7CisgICAgaWYg
KCBjYXBzICYgfmdfbWNnX2NhcCAmIH5NQ0dfQ0FQX0NPVU5UICYgfk1DR19DVExfUCApCisgICAg
eworICAgICAgICBkcHJpbnRrKFhFTkxPR19HX0VSUiwgIiVzIHJlc3RvcmU6IHVuc3VwcG9ydGVk
IE1DQSBjYXBhYmlsaXRpZXMiCisgICAgICAgICAgICAgICAgIiAlIyIgUFJJeDY0ICIgZm9yIGQl
ZDp2JXUgKHN1cHBvcnRlZDogJSNMeClcbiIsCisgICAgICAgICAgICAgICAgaXNfaHZtX3ZjcHUo
dikgPyAiSFZNIiA6ICJQViIsIGNhcHMsIHYtPmRvbWFpbi0+ZG9tYWluX2lkLAorICAgICAgICAg
ICAgICAgIHYtPnZjcHVfaWQsIGdfbWNnX2NhcCAmIH5NQ0dfQ0FQX0NPVU5UKTsKKyAgICAgICAg
cmV0dXJuIC1FUEVSTTsKKyAgICB9CisKKyAgICB2LT5hcmNoLm1jZ19jYXAgPSBjYXBzOworICAg
IHJldHVybiAwOworfQorCitzdGF0aWMgaW50IGJhbmtfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2
Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCit7CisgICAgaW50IHJldCA9IDE7
CisgICAgdW5zaWduZWQgaW50IGJhbmsgPSAobXNyIC0gTVNSX0lBMzJfTUMwX0NUTCkgLyA0Owor
ICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZSh2LT5kb21haW4pOwog
ICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKIAotICAgIGJhbmsgPSAobXNyIC0gTVNSX0lB
MzJfTUMwX0NUTCkgLyA0OwotICAgIGlmICggYmFuayA+PSBucl9tY2VfYmFua3MgKQotICAgICAg
ICByZXR1cm4gLTE7CisgICAgKnZhbCA9IDA7CiAKICAgICBzd2l0Y2ggKCBtc3IgJiAoTVNSX0lB
MzJfTUMwX0NUTCB8IDMpICkKICAgICB7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfQ1RMOgotICAg
ICAgICAqdmFsID0gdm1jZS0+bWNpX2N0bFtiYW5rXSAmCi0gICAgICAgICAgICAoaF9tY2lfY3Ry
bCA/IGhfbWNpX2N0cmxbYmFua10gOiB+MFVMKTsKKyAgICAgICAgaWYgKCBiYW5rIDwgbnJfbWNl
X2JhbmtzICkKKyAgICAgICAgICAgICp2YWwgPSB2bWNlLT5tY2lfY3RsW2JhbmtdICYKKyAgICAg
ICAgICAgICAgICAgICAoaF9tY2lfY3RybCA/IGhfbWNpX2N0cmxbYmFua10gOiB+MFVMKTsKICAg
ICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRtc3IgTUMldV9DVEwgMHglIlBS
SXg2NCJcbiIsCiAgICAgICAgICAgICAgICAgICAgYmFuaywgKnZhbCk7CiAgICAgICAgIGJyZWFr
OwpAQCAtMTI2LDcgKzE0Niw3IEBAIHN0YXRpYyBpbnQgYmFua19tY2VfcmRtc3Ioc3RydWN0IGRv
bWFpbiAKICAgICAgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yICkKICAgICAg
ICAgewogICAgICAgICBjYXNlIFg4Nl9WRU5ET1JfSU5URUw6Ci0gICAgICAgICAgICByZXQgPSBp
bnRlbF9tY2VfcmRtc3IobXNyLCB2YWwpOworICAgICAgICAgICAgcmV0ID0gaW50ZWxfbWNlX3Jk
bXNyKHYsIG1zciwgdmFsKTsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBkZWZhdWx0Ogog
ICAgICAgICAgICAgcmV0ID0gMDsKQEAgLTE0NSwxMyArMTY1LDEzIEBAIHN0YXRpYyBpbnQgYmFu
a19tY2VfcmRtc3Ioc3RydWN0IGRvbWFpbiAKICAqLwogaW50IHZtY2VfcmRtc3IodWludDMyX3Qg
bXNyLCB1aW50NjRfdCAqdmFsKQogewotICAgIHN0cnVjdCBkb21haW4gKmQgPSBjdXJyZW50LT5k
b21haW47Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9IGRvbV92bWNlKGQpOwor
ICAgIGNvbnN0IHN0cnVjdCB2Y3B1ICpjdXIgPSBjdXJyZW50OworICAgIHN0cnVjdCBkb21haW5f
bWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZShjdXItPmRvbWFpbik7CiAgICAgaW50IHJldCA9IDE7
CiAKICAgICAqdmFsID0gMDsKIAotICAgIHNwaW5fbG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOwor
ICAgIHNwaW5fbG9jaygmdm1jZS0+bG9jayk7CiAKICAgICBzd2l0Y2ggKCBtc3IgKQogICAgIHsK
QEAgLTE2MiwzOSArMTgyLDM4IEBAIGludCB2bWNlX3JkbXNyKHVpbnQzMl90IG1zciwgdWludDY0
X3QgKnYKICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogcmRtc3IgTUNHX1NUQVRVUyAweCUi
UFJJeDY0IlxuIiwgKnZhbCk7CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgTVNSX0lBMzJfTUNH
X0NBUDoKLSAgICAgICAgKnZhbCA9IHZtY2UtPm1jZ19jYXA7CisgICAgICAgICp2YWwgPSBjdXIt
PmFyY2gubWNnX2NhcDsKICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRt
c3IgTUNHX0NBUCAweCUiUFJJeDY0IlxuIiwKICAgICAgICAgICAgICAgICAgICAqdmFsKTsKICAg
ICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfQ1RMOgogICAgICAgICAvKiBBbHdh
eXMgMCBpZiBubyBDVEwgc3VwcG9ydCAqLwotICAgICAgICAqdmFsID0gdm1jZS0+bWNnX2N0bCAm
IGhfbWNnX2N0bDsKKyAgICAgICAgaWYgKCBjdXItPmFyY2gubWNnX2NhcCAmIE1DR19DVExfUCAp
CisgICAgICAgICAgICAqdmFsID0gdm1jZS0+bWNnX2N0bCAmIGhfbWNnX2N0bDsKICAgICAgICAg
bWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRtc3IgTUNHX0NUTCAweCUiUFJJeDY0Ilxu
IiwKICAgICAgICAgICAgICAgICAgICAqdmFsKTsKICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVs
dDoKLSAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNyKG1zcikgPyBiYW5rX21jZV9yZG1zcihkLCBt
c3IsIHZhbCkgOiAwOworICAgICAgICByZXQgPSBtY2VfYmFua19tc3IoY3VyLCBtc3IpID8gYmFu
a19tY2VfcmRtc3IoY3VyLCBtc3IsIHZhbCkgOiAwOwogICAgICAgICBicmVhazsKICAgICB9CiAK
LSAgICBzcGluX3VubG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOworICAgIHNwaW5fdW5sb2NrKCZ2
bWNlLT5sb2NrKTsKICAgICByZXR1cm4gcmV0OwogfQogCi1zdGF0aWMgaW50IGJhbmtfbWNlX3dy
bXNyKHN0cnVjdCBkb21haW4gKmQsIHUzMiBtc3IsIHU2NCB2YWwpCitzdGF0aWMgaW50IGJhbmtf
bWNlX3dybXNyKHN0cnVjdCB2Y3B1ICp2LCB1MzIgbXNyLCB1NjQgdmFsKQogewotICAgIGludCBi
YW5rLCByZXQgPSAxOwotICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1j
ZShkKTsKKyAgICBpbnQgcmV0ID0gMTsKKyAgICB1bnNpZ25lZCBpbnQgYmFuayA9IChtc3IgLSBN
U1JfSUEzMl9NQzBfQ1RMKSAvIDQ7CisgICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9
IGRvbV92bWNlKHYtPmRvbWFpbik7CiAgICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5ID0gTlVM
TDsKIAotICAgIGJhbmsgPSAobXNyIC0gTVNSX0lBMzJfTUMwX0NUTCkgLyA0OwotICAgIGlmICgg
YmFuayA+PSBucl9tY2VfYmFua3MgKQotICAgICAgICByZXR1cm4gLUVJTlZBTDsKLQogICAgIHN3
aXRjaCAoIG1zciAmIChNU1JfSUEzMl9NQzBfQ1RMIHwgMykgKQogICAgIHsKICAgICBjYXNlIE1T
Ul9JQTMyX01DMF9DVEw6Ci0gICAgICAgIHZtY2UtPm1jaV9jdGxbYmFua10gPSB2YWw7CisgICAg
ICAgIGlmICggYmFuayA8IG5yX21jZV9iYW5rcyApCisgICAgICAgICAgICB2bWNlLT5tY2lfY3Rs
W2JhbmtdID0gdmFsOwogICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9TVEFU
VVM6CiAgICAgICAgIC8qIEdpdmUgdGhlIGZpcnN0IGVudHJ5IG9mIHRoZSBsaXN0LCBpdCBjb3Jy
ZXNwb25kcyB0byBjdXJyZW50CkBAIC0yMDIsOSArMjIxLDkgQEAgc3RhdGljIGludCBiYW5rX21j
ZV93cm1zcihzdHJ1Y3QgZG9tYWluIAogICAgICAgICAgKiB0aGUgZ3Vlc3QsIHRoaXMgbm9kZSB3
aWxsIGJlIGRlbGV0ZWQuCiAgICAgICAgICAqIE9ubHkgZXJyb3IgYmFuayBpcyB3cml0dGVuLiBO
b24tZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KICAgICAgICAgICovCi0gICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJmRvbV92bWNlKGQpLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKICAgICAgICAgewotICAgICAgICAg
ICAgZW50cnkgPSBsaXN0X2VudHJ5KGRvbV92bWNlKGQpLT5pbXBhY3RfaGVhZGVyLm5leHQsCisg
ICAgICAgICAgICBlbnRyeSA9IGxpc3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsK
ICAgICAgICAgICAgIGlmICggZW50cnktPmJhbmsgPT0gYmFuayApCiAgICAgICAgICAgICAgICAg
ZW50cnktPm1jaV9zdGF0dXMgPSB2YWw7CkBAIC0yMjgsNyArMjQ3LDcgQEAgc3RhdGljIGludCBi
YW5rX21jZV93cm1zcihzdHJ1Y3QgZG9tYWluIAogICAgICAgICBzd2l0Y2ggKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgKQogICAgICAgICB7CiAgICAgICAgIGNhc2UgWDg2X1ZFTkRPUl9JTlRF
TDoKLSAgICAgICAgICAgIHJldCA9IGludGVsX21jZV93cm1zcihtc3IsIHZhbCk7CisgICAgICAg
ICAgICByZXQgPSBpbnRlbF9tY2Vfd3Jtc3IodiwgbXNyLCB2YWwpOwogICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAgICByZXQgPSAwOwpAQCAtMjQ3LDkgKzI2
Niw5IEBAIHN0YXRpYyBpbnQgYmFua19tY2Vfd3Jtc3Ioc3RydWN0IGRvbWFpbiAKICAqLwogaW50
IHZtY2Vfd3Jtc3IodTMyIG1zciwgdTY0IHZhbCkKIHsKLSAgICBzdHJ1Y3QgZG9tYWluICpkID0g
Y3VycmVudC0+ZG9tYWluOworICAgIHN0cnVjdCB2Y3B1ICpjdXIgPSBjdXJyZW50OwogICAgIHN0
cnVjdCBiYW5rX2VudHJ5ICplbnRyeSA9IE5VTEw7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNy
cyAqdm1jZSA9IGRvbV92bWNlKGQpOworICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2Ug
PSBkb21fdm1jZShjdXItPmRvbWFpbik7CiAgICAgaW50IHJldCA9IDE7CiAKICAgICBpZiAoICFn
X21jZ19jYXAgKQpAQCAtMjY2LDcgKzI4NSw3IEBAIGludCB2bWNlX3dybXNyKHUzMiBtc3IsIHU2
NCB2YWwpCiAgICAgICAgIHZtY2UtPm1jZ19zdGF0dXMgPSB2YWw7CiAgICAgICAgIG1jZV9wcmlu
dGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHdybXNyIE1DR19TVEFUVVMgJSJQUkl4NjQiXG4iLCB2YWwp
OwogICAgICAgICAvKiBGb3IgSFZNIGd1ZXN0LCB0aGlzIGlzIHRoZSBwb2ludCBmb3IgZGVsZXRp
bmcgdk1DRSBpbmplY3Rpb24gbm9kZSAqLwotICAgICAgICBpZiAoIGQtPmlzX2h2bSAmJiAodm1j
ZS0+bnJfaW5qZWN0aW9uID4gMCkgKQorICAgICAgICBpZiAoIGlzX2h2bV92Y3B1KGN1cikgJiYg
KHZtY2UtPm5yX2luamVjdGlvbiA+IDApICkKICAgICAgICAgewogICAgICAgICAgICAgdm1jZS0+
bnJfaW5qZWN0aW9uLS07IC8qIFNob3VsZCBiZSAwICovCiAgICAgICAgICAgICBpZiAoICFsaXN0
X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCkBAIC0yOTMsNyArMzEyLDcgQEAgaW50IHZt
Y2Vfd3Jtc3IodTMyIG1zciwgdTY0IHZhbCkKICAgICAgICAgcmV0ID0gLTE7CiAgICAgICAgIGJy
ZWFrOwogICAgIGRlZmF1bHQ6Ci0gICAgICAgIHJldCA9IG1jZV9iYW5rX21zcihtc3IpID8gYmFu
a19tY2Vfd3Jtc3IoZCwgbXNyLCB2YWwpIDogMDsKKyAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNy
KGN1ciwgbXNyKSA/IGJhbmtfbWNlX3dybXNyKGN1ciwgbXNyLCB2YWwpIDogMDsKICAgICAgICAg
YnJlYWs7CiAgICAgfQogCkBAIC0zMDEsNiArMzIwLDQ2IEBAIGludCB2bWNlX3dybXNyKHUzMiBt
c3IsIHU2NCB2YWwpCiAgICAgcmV0dXJuIHJldDsKIH0KIAorc3RhdGljIGludCB2bWNlX3NhdmVf
dmNwdV9jdHh0KHN0cnVjdCBkb21haW4gKmQsIGh2bV9kb21haW5fY29udGV4dF90ICpoKQorewor
ICAgIHN0cnVjdCB2Y3B1ICp2OworICAgIGludCBlcnIgPSAwOworCisgICAgZm9yX2VhY2hfdmNw
dSggZCwgdiApIHsKKyAgICAgICAgc3RydWN0IGh2bV92bWNlX3ZjcHUgY3R4dCA9IHsKKyAgICAg
ICAgICAgIC5jYXBzID0gdi0+YXJjaC5tY2dfY2FwCisgICAgICAgIH07CisKKyAgICAgICAgZXJy
ID0gaHZtX3NhdmVfZW50cnkoVk1DRV9WQ1BVLCB2LT52Y3B1X2lkLCBoLCAmY3R4dCk7CisgICAg
ICAgIGlmICggZXJyICkKKyAgICAgICAgICAgIGJyZWFrOworICAgIH0KKworICAgIHJldHVybiBl
cnI7Cit9CisKK3N0YXRpYyBpbnQgdm1jZV9sb2FkX3ZjcHVfY3R4dChzdHJ1Y3QgZG9tYWluICpk
LCBodm1fZG9tYWluX2NvbnRleHRfdCAqaCkKK3sKKyAgICB1bnNpZ25lZCBpbnQgdmNwdWlkID0g
aHZtX2xvYWRfaW5zdGFuY2UoaCk7CisgICAgc3RydWN0IHZjcHUgKnY7CisgICAgc3RydWN0IGh2
bV92bWNlX3ZjcHUgY3R4dDsKKyAgICBpbnQgZXJyOworCisgICAgaWYgKCB2Y3B1aWQgPj0gZC0+
bWF4X3ZjcHVzIHx8ICh2ID0gZC0+dmNwdVt2Y3B1aWRdKSA9PSBOVUxMICkKKyAgICB7CisgICAg
ICAgIGRwcmludGsoWEVOTE9HX0dfRVJSLCAiSFZNIHJlc3RvcmU6IGRvbSVkIGhhcyBubyB2Y3B1
JXVcbiIsCisgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkLCB2Y3B1aWQpOworICAgICAgICBl
cnIgPSAtRUlOVkFMOworICAgIH0KKyAgICBlbHNlCisgICAgICAgIGVyciA9IGh2bV9sb2FkX2Vu
dHJ5KFZNQ0VfVkNQVSwgaCwgJmN0eHQpOworCisgICAgcmV0dXJuIGVyciA/OiB2bWNlX3Jlc3Rv
cmVfdmNwdSh2LCBjdHh0LmNhcHMpOworfQorCitIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFZN
Q0VfVkNQVSwgdm1jZV9zYXZlX3ZjcHVfY3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
dm1jZV9sb2FkX3ZjcHVfY3R4dCwgMSwgSFZNU1JfUEVSX1ZDUFUpOworCiBpbnQgaW5qZWN0X3Zt
Y2Uoc3RydWN0IGRvbWFpbiAqZCkKIHsKICAgICBpbnQgY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgp
OwotLS0gYS94ZW4vYXJjaC94ODYvZG9tYWluLmMKKysrIGIveGVuL2FyY2gveDg2L2RvbWFpbi5j
CkBAIC00MjIsNiArNDIyLDggQEAgaW50IHZjcHVfaW5pdGlhbGlzZShzdHJ1Y3QgdmNwdSAqdikK
ICAgICBpZiAoIChyYyA9IHZjcHVfaW5pdF9mcHUodikpICE9IDAgKQogICAgICAgICByZXR1cm4g
cmM7CiAKKyAgICB2bWNlX2luaXRfdmNwdSh2KTsKKwogICAgIGlmICggaXNfaHZtX2RvbWFpbihk
KSApCiAgICAgewogICAgICAgICByYyA9IGh2bV92Y3B1X2luaXRpYWxpc2Uodik7Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9kb21jdGwuYworKysgYi94ZW4vYXJjaC94ODYvZG9tY3RsLmMKQEAgLTEwMjcs
MTEgKzEwMjcsMTIgQEAgbG9uZyBhcmNoX2RvX2RvbWN0bCgKICAgICAgICAgICAgICAgICBldmMt
PnN5c2NhbGwzMl9jYWxsYmFja19laXAgICAgPSAwOwogICAgICAgICAgICAgICAgIGV2Yy0+c3lz
Y2FsbDMyX2Rpc2FibGVzX2V2ZW50cyA9IDA7CiAgICAgICAgICAgICB9CisgICAgICAgICAgICBl
dmMtPm1jZ19jYXAgPSB2LT5hcmNoLm1jZ19jYXA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZQog
ICAgICAgICB7CiAgICAgICAgICAgICByZXQgPSAtRUlOVkFMOwotICAgICAgICAgICAgaWYgKCBl
dmMtPnNpemUgIT0gc2l6ZW9mKCpldmMpICkKKyAgICAgICAgICAgIGlmICggZXZjLT5zaXplIDwg
b2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2dfY2FwKSApCiAgICAgICAgICAgICAgICAgZ290byBl
eHRfdmNwdWNvbnRleHRfb3V0OwogI2lmZGVmIF9feDg2XzY0X18KICAgICAgICAgICAgIGlmICgg
IWlzX2h2bV9kb21haW4oZCkgKQpAQCAtMTA1OSw2ICsxMDYwLDEwIEBAIGxvbmcgYXJjaF9kb19k
b21jdGwoCiAgICAgICAgICAgICAgICAgIChldmMtPnN5c2NhbGwzMl9jYWxsYmFja19jcyAmIH4z
KSB8fAogICAgICAgICAgICAgICAgICBldmMtPnN5c2NhbGwzMl9jYWxsYmFja19laXAgKQogICAg
ICAgICAgICAgICAgIGdvdG8gZXh0X3ZjcHVjb250ZXh0X291dDsKKworICAgICAgICAgICAgaWYg
KCBldmMtPnNpemUgPj0gb2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2dfY2FwKSArCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YoZXZjLT5tY2dfY2FwKSApCisgICAgICAgICAg
ICAgICAgcmV0ID0gdm1jZV9yZXN0b3JlX3ZjcHUodiwgZXZjLT5tY2dfY2FwKTsKICAgICAgICAg
fQogCiAgICAgICAgIHJldCA9IDA7Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaApAQCAtNDg4LDYgKzQ4OCw4IEBAIHN0
cnVjdCBhcmNoX3ZjcHUKICAgICAvKiBUaGlzIHZhcmlhYmxlIGRldGVybWluZXMgd2hldGhlciBu
b25sYXp5IGV4dGVuZGVkIHN0YXRlIGhhcyBiZWVuIHVzZWQsCiAgICAgICogYW5kIHRodXMgc2hv
dWxkIGJlIHNhdmVkL3Jlc3RvcmVkLiAqLwogICAgIGJvb2xfdCBub25sYXp5X3hzdGF0ZV91c2Vk
OworCisgICAgdWludDY0X3QgbWNnX2NhcDsKICAgICAKICAgICBzdHJ1Y3QgcGFnaW5nX3ZjcHUg
cGFnaW5nOwogCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNlLmgKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tY2UuaApAQCAtMTYsNyArMTYsNiBAQCBzdHJ1Y3QgYmFua19lbnRyeSB7CiBz
dHJ1Y3QgZG9tYWluX21jYV9tc3JzCiB7CiAgICAgLyogR3Vlc3Qgc2hvdWxkIG5vdCBjaGFuZ2Ug
YmVsb3cgdmFsdWVzIGFmdGVyIERPTSBib290IHVwICovCi0gICAgdWludDY0X3QgbWNnX2NhcDsK
ICAgICB1aW50NjRfdCBtY2dfY3RsOwogICAgIHVpbnQ2NF90IG1jZ19zdGF0dXM7CiAgICAgdWlu
dDY0X3QgKm1jaV9jdGw7CkBAIC0yOCw2ICsyNyw4IEBAIHN0cnVjdCBkb21haW5fbWNhX21zcnMK
IC8qIEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwogZXh0ZXJuIGludCB2bWNlX2lu
aXRfbXNyKHN0cnVjdCBkb21haW4gKmQpOwogZXh0ZXJuIHZvaWQgdm1jZV9kZXN0cm95X21zcihz
dHJ1Y3QgZG9tYWluICpkKTsKK2V4dGVybiB2b2lkIHZtY2VfaW5pdF92Y3B1KHN0cnVjdCB2Y3B1
ICopOworZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqLCB1aW50NjRf
dCBjYXBzKTsKIGV4dGVybiBpbnQgdm1jZV93cm1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90IHZh
bCk7CiBleHRlcm4gaW50IHZtY2VfcmRtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCAqdmFsKTsK
IAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvaHZtL3NhdmUuaAorKysgYi94ZW4v
aW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvaHZtL3NhdmUuaApAQCAtNTg1LDkgKzU4NSwxNSBAQCBz
dHJ1Y3QgaHZtX3ZpcmlkaWFuX3ZjcHVfY29udGV4dCB7CiAKIERFQ0xBUkVfSFZNX1NBVkVfVFlQ
RShWSVJJRElBTl9WQ1BVLCAxNywgc3RydWN0IGh2bV92aXJpZGlhbl92Y3B1X2NvbnRleHQpOwog
CitzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSB7CisgICAgdWludDY0X3QgY2FwczsKK307CisKK0RFQ0xB
UkVfSFZNX1NBVkVfVFlQRShWTUNFX1ZDUFUsIDE4LCBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSk7CisK
IC8qIAogICogTGFyZ2VzdCB0eXBlLWNvZGUgaW4gdXNlCiAgKi8KLSNkZWZpbmUgSFZNX1NBVkVf
Q09ERV9NQVggMTcKKyNkZWZpbmUgSFZNX1NBVkVfQ09ERV9NQVggMTgKIAogI2VuZGlmIC8qIF9f
WEVOX1BVQkxJQ19IVk1fU0FWRV9YODZfSF9fICovCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9k
b21jdGwuaAorKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgKQEAgLTU1OSw3ICs1NTks
NyBAQCBzdHJ1Y3QgeGVuX2RvbWN0bF9leHRfdmNwdWNvbnRleHQgewogICAgIHVpbnQzMl90ICAg
ICAgICAgdmNwdTsKICAgICAvKgogICAgICAqIFNFVDogU2l6ZSBvZiBzdHJ1Y3QgKElOKQotICAg
ICAqIEdFVDogU2l6ZSBvZiBzdHJ1Y3QgKE9VVCkKKyAgICAgKiBHRVQ6IFNpemUgb2Ygc3RydWN0
IChPVVQsIHVwIHRvIDEyOCBieXRlcykKICAgICAgKi8KICAgICB1aW50MzJfdCAgICAgICAgIHNp
emU7CiAjaWYgZGVmaW5lZChfX2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82NF9fKQpAQCAtNTcx
LDYgKzU3MSw3IEBAIHN0cnVjdCB4ZW5fZG9tY3RsX2V4dF92Y3B1Y29udGV4dCB7CiAgICAgdWlu
dDE2X3QgICAgICAgICBzeXNlbnRlcl9jYWxsYmFja19jczsKICAgICB1aW50OF90ICAgICAgICAg
IHN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHM7CiAgICAgdWludDhfdCAgICAgICAgICBzeXNlbnRl
cl9kaXNhYmxlc19ldmVudHM7CisgICAgdWludDY0X2FsaWduZWRfdCBtY2dfY2FwOwogI2VuZGlm
CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9leHRfdmNwdWNvbnRleHQgeGVuX2RvbWN0
bF9leHRfdmNwdWNvbnRleHRfdDsK

--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=142;
	creation-date="Wed, 15 Feb 2012 11:04:26 GMT";
	modification-date="Wed, 15 Feb 2012 11:04:26 GMT"
Content-ID: <B8D27E4B2EB93741A96203690282D776@intel.com>
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QNClhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tDQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwNCg==

--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_--

--_002_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Jun 28 08:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08: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 1SkAV4-0007bF-J6; Thu, 28 Jun 2012 08:54:54 +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 1SkAV2-0007as-Pi
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 08:54:53 +0000
Received: from [193.109.254.147:36855] by server-1.bemta-14.messagelabs.com id
	8D/64-24612-CDB1CEF4; Thu, 28 Jun 2012 08:54:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340873686!8818526!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyMTc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2717 invoked from network); 28 Jun 2012 08:54:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-27.messagelabs.com with SMTP;
	28 Jun 2012 08:54:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 01:54:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="txt'?scan'208";a="163875263"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 28 Jun 2012 01:54:43 -0700
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; Thu, 28 Jun 2012 01:54:43 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 16:54:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVGbW1l9vq4iTRyWE8p2SJy8j95cPaWDw
Date: Thu, 28 Jun 2012 08:54:40 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
In-Reply-To: <4FEB236C020000780008C392@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="_002_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan Beulich wrote:
>>>> On 27.06.12 at 05:51, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> This is updated xen vMCE design foils, according to comments from
>> community recently.=20
>>=20
>> This foils focus on vMCE part of Xen MCA, so as Keir said, it's some
>> dense. Later Will will present a document to elaborate more,
>> including Intel MCA and surrounding features and Xen implementation.
>=20
> For MCi_CTL2 you probably meant to say "allow setting CMCI_EN
> and error count threshold"?

Yes, exactly! the words is w/ subtle but important different meaning.

>=20
> The 2-bank approach also needs to be brought in line with the
> current host derived value in MCG_CAP, especially if the code to
> implement this new model doesn't make it into 4.2 (which would
> generally save a larger value).
>=20
> Jan

Let me repeat in my word to avoid misunderstanding about your concern:
Your concern rooted from the history patch (c/s 24887, as attached) which u=
sed to solve vMCE migration issue caused from bank number. I guess the patc=
h was not in xen4.1.x but would be in xen 4.2 release recently (right? and =
when will xen 4.2 release?)
Per my understanding, you want us to make sure our new vMCE model compatibl=
e w/ olde vMCE. For example if our patch in xen 4.3 release, you want to ma=
ke sure a guest migrate from xen 4.2 to 4.3 would not broken. Is this your =
concern?

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Thu, 28 Jun 2012 08:54:39 GMT";
	modification-date="Thu, 28 Jun 2012 08:54:39 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; Wed, 15 Feb 2012 19:04:26 +0800
Received: from fmsmsx108.amr.corp.intel.com (10.19.9.228) by
 SHSMSX101.ccr.corp.intel.com (10.239.4.153) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Wed, 15 Feb 2012 19:04:25 +0800
Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by
 FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Wed, 15 Feb 2012 03:04:24 -0800
Received: from azsmga001.ch.intel.com (10.2.17.19) by rrsmsx601-1.rr.intel.com
 (10.31.0.151) with Microsoft SMTP Server id 8.2.255.0; Wed, 15 Feb 2012
 04:03:48 -0700
Received: from azsmga102.ch.intel.com ([10.2.16.52])  by
 azsmga001-1.ch.intel.com with ESMTP; 15 Feb 2012 03:03:46 -0800
Received: from lists.xen.org ([50.57.142.19])  by mga14.intel.com with ESMTP;
 15 Feb 2012 03:03:44 -0800
Received: from localhost ([127.0.0.1] helo=lists.xen.org)	by lists.xen.org
 with esmtp (Exim 4.72)	(envelope-from
 <xen-devel-bounces@lists.xensource.com>)	id 1Rxcbo-0008F8-C8; Wed, 15 Feb
 2012 11:01:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])	by lists.xen.org with
 esmtp (Exim 4.72)	(envelope-from <JBeulich@suse.com>) id 1Rxcbm-0008EN-Ur	for
 xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:01:11 +0000
Received: (qmail 24767 invoked from network); 15 Feb 2012 11:01:03 -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; 15 Feb 2012 11:01:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com	with Novell_GroupWise; Wed,
 15 Feb 2012 11:01:04 +0000
From: Jan Beulich <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
CC: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 2/2] x86/vMCE: save/restore MCA capabilities
Thread-Topic: [Xen-devel] [PATCH 2/2] x86/vMCE: save/restore MCA capabilities
Thread-Index: AQHM69GUIaRbcUEjU0SZ9CYw3vbbqA==
Sender: "xen-devel-bounces@lists.xensource.com"
	<xen-devel-bounces@lists.xensource.com>
Date: Wed, 15 Feb 2012 11:01:02 +0000
Message-ID: <4F3B9E7E0200007800073218@nat28.tlf.novell.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: rrsmsx601.amr.corp.intel.com
X-MS-Has-Attach: yes
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.71,315,1320652800";
    d="scan'208";a="794129760"
x-mailman-version: 2.1.13
errors-to: xen-devel-bounces@lists.xensource.com
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AgcBAAjU304yOY4TmWdsb2JhbAAtFoIFqFEiAQEBAQEICwsHFB4HgXQGAQEMAQoNHwoeCwMDAQIGAjUPBAgDASQ1EwWIBAakPQGSN4d0gl1jBIx0KAF1hDWCJJIj
x-env-sender: JBeulich@suse.com
x-originating-ip: [130.57.49.28]
x-msg-ref: server-13.tower-174.messagelabs.com!1329303662!8301262!1
x-viruschecked: Checked
x-starscan-version: 6.5.5; banners=-,-,-
x-beenthere: xen-devel@lists.xensource.com
list-id: Xen developer discussion <xen-devel.lists.xensource.com>
list-post: <mailto:xen-devel@lists.xensource.com>
x-spamreason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
Content-Type: multipart/mixed;
	boundary="_003_4F3B9E7E0200007800073218nat28tlfnovellcom_"
MIME-Version: 1.0

--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8AB1E9C344A8F84FB012A9ADB2E5E536@intel.com>
Content-Transfer-Encoding: quoted-printable

This allows migration to a host with less MCA banks than the source
host had, while without this patch accesses to the excess banks' MSRs
caused #GP-s in the guest after migration (and it depended on the guest
kernel whether this would be fatal).

A fundamental question is whether we should also save/restore MCG_CTL
and MCi_CTL, as the HVM save record would better be defined to the
complete state that needs saving from the beginning (I'm unsure whether
the save/restore logic allows for future extension of an existing
record).

Of course, this change is expected to make migration from new to older
Xen impossible (again I'm unsure what the save/restore logic does with
records it doesn't even know about).

The (trivial) tools side change may seem unrelated, but the code should
have been that way from the beginning to allow the hypervisor to look
at currently unused ext_vcpucontext fields without risking to read
garbage when those fields get a meaning assigned in the future. This
isn't being enforced here - should it be? (Obviously, for backwards
compatibility, the hypervisor must assume these fields to be clear only
when the extended context's size exceeds the old original one.)

A future addition to this change might be to allow configuration of the
number of banks and other MCA capabilities for a guest before it starts
(i.e. to not inherits the values seen on the first host it runs on).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); break=
;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern unsigned int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_b=
anks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_ba=
nks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_ba=
nks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)
            nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;
     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;
     dom_vmce(d)->nr_injection =3D 0;
=20
@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.mcg_cap =3D g_mcg_cap;
+}
+
+int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+{
+    if ( caps & ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    {
+        dprintk(XENLOG_G_ERR, "%s restore: unsupported MCA capabilities"
+                " %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",
+                is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,
+                v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);
+        return -EPERM;
+    }
+
+    v->arch.mcg_cap =3D caps;
+    return 0;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *va=
l)
+{
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +146,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -162,39 +182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D vmce->mcg_cap;
+        *val =3D cur->arch.mcg_cap;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Always 0 if no CTL support */
-        *val =3D vmce->mcg_ctl & h_mcg_ctl;
+        if ( cur->arch.mcg_cap & MCG_CTL_P )
+            *val =3D vmce->mcg_ctl & h_mcg_ctl;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +221,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +247,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +285,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", val);
         /* For HVM guest, this is the point for deleting vMCE injection no=
de */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +312,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0=
;
         break;
     }
=20
@@ -301,6 +320,46 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .caps =3D v->arch.mcg_cap
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL )
+    {
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
+        err =3D -EINVAL;
+    }
+    else
+        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+
+    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
+    vmce_init_vcpu(v);
+
     if ( is_hvm_domain(d) )
     {
         rc =3D hvm_vcpu_initialise(v);
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->mcg_cap =3D v->arch.mcg_cap;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,10 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
+                              sizeof(evc->mcg_cap) )
+                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been us=
ed,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint64_t mcg_cap;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -16,7 +16,6 @@ struct bank_entry {
 struct domain_mca_msrs
 {
     /* Guest should not change below values after DOM boot up */
-    uint64_t mcg_cap;
     uint64_t mcg_ctl;
     uint64_t mcg_status;
     uint64_t *mci_ctl;
@@ -28,6 +27,8 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
+extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint64_t caps;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint64_aligned_t mcg_cap;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;



--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Description: x86-vmce-sr.patch
Content-Disposition: attachment; filename="x86-vmce-sr.patch"; size=16665;
	creation-date="Wed, 15 Feb 2012 11:04:26 GMT";
	modification-date="Wed, 15 Feb 2012 11:04:26 GMT"
Content-ID: <D3C3E22374CA4A47B197E04B09C1C586@intel.com>
Content-Transfer-Encoding: base64

eDg2L3ZNQ0U6IHNhdmUvcmVzdG9yZSBNQ0EgY2FwYWJpbGl0aWVzCgpUaGlzIGFsbG93cyBtaWdy
YXRpb24gdG8gYSBob3N0IHdpdGggbGVzcyBNQ0EgYmFua3MgdGhhbiB0aGUgc291cmNlCmhvc3Qg
aGFkLCB3aGlsZSB3aXRob3V0IHRoaXMgcGF0Y2ggYWNjZXNzZXMgdG8gdGhlIGV4Y2VzcyBiYW5r
cycgTVNScwpjYXVzZWQgI0dQLXMgaW4gdGhlIGd1ZXN0IGFmdGVyIG1pZ3JhdGlvbiAoYW5kIGl0
IGRlcGVuZGVkIG9uIHRoZSBndWVzdAprZXJuZWwgd2hldGhlciB0aGlzIHdvdWxkIGJlIGZhdGFs
KS4KCkEgZnVuZGFtZW50YWwgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBzaG91bGQgYWxzbyBzYXZl
L3Jlc3RvcmUgTUNHX0NUTAphbmQgTUNpX0NUTCwgYXMgdGhlIEhWTSBzYXZlIHJlY29yZCB3b3Vs
ZCBiZXR0ZXIgYmUgZGVmaW5lZCB0byB0aGUKY29tcGxldGUgc3RhdGUgdGhhdCBuZWVkcyBzYXZp
bmcgZnJvbSB0aGUgYmVnaW5uaW5nIChJJ20gdW5zdXJlIHdoZXRoZXIKdGhlIHNhdmUvcmVzdG9y
ZSBsb2dpYyBhbGxvd3MgZm9yIGZ1dHVyZSBleHRlbnNpb24gb2YgYW4gZXhpc3RpbmcKcmVjb3Jk
KS4KCk9mIGNvdXJzZSwgdGhpcyBjaGFuZ2UgaXMgZXhwZWN0ZWQgdG8gbWFrZSBtaWdyYXRpb24g
ZnJvbSBuZXcgdG8gb2xkZXIKWGVuIGltcG9zc2libGUgKGFnYWluIEknbSB1bnN1cmUgd2hhdCB0
aGUgc2F2ZS9yZXN0b3JlIGxvZ2ljIGRvZXMgd2l0aApyZWNvcmRzIGl0IGRvZXNuJ3QgZXZlbiBr
bm93IGFib3V0KS4KClRoZSAodHJpdmlhbCkgdG9vbHMgc2lkZSBjaGFuZ2UgbWF5IHNlZW0gdW5y
ZWxhdGVkLCBidXQgdGhlIGNvZGUgc2hvdWxkCmhhdmUgYmVlbiB0aGF0IHdheSBmcm9tIHRoZSBi
ZWdpbm5pbmcgdG8gYWxsb3cgdGhlIGh5cGVydmlzb3IgdG8gbG9vawphdCBjdXJyZW50bHkgdW51
c2VkIGV4dF92Y3B1Y29udGV4dCBmaWVsZHMgd2l0aG91dCByaXNraW5nIHRvIHJlYWQKZ2FyYmFn
ZSB3aGVuIHRob3NlIGZpZWxkcyBnZXQgYSBtZWFuaW5nIGFzc2lnbmVkIGluIHRoZSBmdXR1cmUu
IFRoaXMKaXNuJ3QgYmVpbmcgZW5mb3JjZWQgaGVyZSAtIHNob3VsZCBpdCBiZT8gKE9idmlvdXNs
eSwgZm9yIGJhY2t3YXJkcwpjb21wYXRpYmlsaXR5LCB0aGUgaHlwZXJ2aXNvciBtdXN0IGFzc3Vt
ZSB0aGVzZSBmaWVsZHMgdG8gYmUgY2xlYXIgb25seQp3aGVuIHRoZSBleHRlbmRlZCBjb250ZXh0
J3Mgc2l6ZSBleGNlZWRzIHRoZSBvbGQgb3JpZ2luYWwgb25lLikKCkEgZnV0dXJlIGFkZGl0aW9u
IHRvIHRoaXMgY2hhbmdlIG1pZ2h0IGJlIHRvIGFsbG93IGNvbmZpZ3VyYXRpb24gb2YgdGhlCm51
bWJlciBvZiBiYW5rcyBhbmQgb3RoZXIgTUNBIGNhcGFiaWxpdGllcyBmb3IgYSBndWVzdCBiZWZv
cmUgaXQgc3RhcnRzCihpLmUuIHRvIG5vdCBpbmhlcml0cyB0aGUgdmFsdWVzIHNlZW4gb24gdGhl
IGZpcnN0IGhvc3QgaXQgcnVucyBvbikuCgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJl
dWxpY2hAc3VzZS5jb20+CgotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCisrKyBi
L3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMKQEAgLTE4NzksNiArMTg3OSw3IEBAIGludCB4
Y19kb21haW5fc2F2ZSh4Y19pbnRlcmZhY2UgKnhjaCwgaW4KIAogICAgICAgICBkb21jdGwuY21k
ID0gWEVOX0RPTUNUTF9nZXRfZXh0X3ZjcHVjb250ZXh0OwogICAgICAgICBkb21jdGwuZG9tYWlu
ID0gZG9tOworICAgICAgICBtZW1zZXQoJmRvbWN0bC51LCAwLCBzaXplb2YoZG9tY3RsLnUpKTsK
ICAgICAgICAgZG9tY3RsLnUuZXh0X3ZjcHVjb250ZXh0LnZjcHUgPSBpOwogICAgICAgICBpZiAo
IHhjX2RvbWN0bCh4Y2gsICZkb21jdGwpIDwgMCApCiAgICAgICAgIHsKLS0tIGEvdG9vbHMvbWlz
Yy94ZW4taHZtY3R4LmMKKysrIGIvdG9vbHMvbWlzYy94ZW4taHZtY3R4LmMKQEAgLTM4Myw2ICsz
ODMsMTMgQEAgc3RhdGljIHZvaWQgZHVtcF92aXJpZGlhbl92Y3B1KHZvaWQpCiAgICAgICAgICAg
ICh1bnNpZ25lZCBsb25nIGxvbmcpIHAuYXBpY19hc3Npc3QpOyAgICAgICAgICAgCiB9CiAKK3N0
YXRpYyB2b2lkIGR1bXBfdm1jZV92Y3B1KHZvaWQpCit7CisgICAgSFZNX1NBVkVfVFlQRShWTUNF
X1ZDUFUpIHA7CisgICAgUkVBRChwKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6IGNhcHMg
JSIgUFJJeDY0ICJcbiIsIHAuY2Fwcyk7Cit9CisKIGludCBtYWluKGludCBhcmdjLCBjaGFyICoq
YXJndikKIHsKICAgICBpbnQgZW50cnksIGRvbWlkOwpAQCAtNDQ5LDYgKzQ1Niw3IEBAIGludCBt
YWluKGludCBhcmdjLCBjaGFyICoqYXJndikKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKE1U
UlIpOiBkdW1wX210cnIoKTsgYnJlYWs7CiAgICAgICAgIGNhc2UgSFZNX1NBVkVfQ09ERShWSVJJ
RElBTl9ET01BSU4pOiBkdW1wX3ZpcmlkaWFuX2RvbWFpbigpOyBicmVhazsKICAgICAgICAgY2Fz
ZSBIVk1fU0FWRV9DT0RFKFZJUklESUFOX1ZDUFUpOiBkdW1wX3ZpcmlkaWFuX3ZjcHUoKTsgYnJl
YWs7CisgICAgICAgIGNhc2UgSFZNX1NBVkVfQ09ERShWTUNFX1ZDUFUpOiBkdW1wX3ZtY2VfdmNw
dSgpOyBicmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKEVORCk6IGJyZWFrOwogICAg
ICAgICBkZWZhdWx0OgogICAgICAgICAgICAgcHJpbnRmKCIgKiogRG9uJ3QgdW5kZXJzdGFuZCB0
eXBlICV1OiBza2lwcGluZ1xuIiwKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgK
KysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgKQEAgLTMsNiArMyw3IEBACiAjZGVm
aW5lIF9NQ0VfSAogCiAjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQu
aD4KICNpbmNsdWRlIDx4ZW4vc21wLmg+CiAjaW5jbHVkZSA8YXNtL3R5cGVzLmg+CiAjaW5jbHVk
ZSA8YXNtL3RyYXBzLmg+CkBAIC01NCw4ICs1NSw4IEBAIGludCB1bm1tYXBfYnJva2VuX3BhZ2Uo
c3RydWN0IGRvbWFpbiAqZCwKIHU2NCBtY2VfY2FwX2luaXQodm9pZCk7CiBleHRlcm4gdW5zaWdu
ZWQgaW50IGZpcnN0YmFuazsKIAotaW50IGludGVsX21jZV9yZG1zcih1aW50MzJfdCBtc3IsIHVp
bnQ2NF90ICp2YWwpOwotaW50IGludGVsX21jZV93cm1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90
IHZhbCk7CitpbnQgaW50ZWxfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICosIHVpbnQzMl90
IG1zciwgdWludDY0X3QgKnZhbCk7CitpbnQgaW50ZWxfbWNlX3dybXNyKHN0cnVjdCB2Y3B1ICos
IHVpbnQzMl90IG1zciwgdWludDY0X3QgdmFsKTsKIAogc3RydWN0IG1jaW5mb19leHRlbmRlZCAq
aW50ZWxfZ2V0X2V4dGVuZGVkX21zcnMoCiAgICAgc3RydWN0IG1jaW5mb19nbG9iYWwgKm1pZywg
c3RydWN0IG1jX2luZm8gKm1pKTsKQEAgLTE3MSwxOCArMTcyLDIwIEBAIGludCB2bWNlX2RvbWFp
bl9pbmplY3Qoc3RydWN0IG1jaW5mb19iYW4KIAogZXh0ZXJuIGludCB2bWNlX2luaXQoc3RydWN0
IGNwdWluZm9feDg2ICpjKTsKIAotc3RhdGljIGlubGluZSBpbnQgbWNlX3ZlbmRvcl9iYW5rX21z
cih1aW50MzJfdCBtc3IpCitzdGF0aWMgaW5saW5lIGludCBtY2VfdmVuZG9yX2JhbmtfbXNyKGNv
bnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IpCiB7CiAgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9JTlRFTCAmJgotICAgICAgICAgbXNyID49IE1T
Ul9JQTMyX01DMF9DVEwyICYmIG1zciA8IChNU1JfSUEzMl9NQzBfQ1RMMiArIG5yX21jZV9iYW5r
cykgKQorICAgICAgICAgbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCisgICAgICAgICBtc3Ig
PCBNU1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCiAg
ICAgICAgICAgcmV0dXJuIDE7CiAgICAgcmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbmxpbmUgaW50
IG1jZV9iYW5rX21zcih1aW50MzJfdCBtc3IpCitzdGF0aWMgaW5saW5lIGludCBtY2VfYmFua19t
c3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zcikKIHsKLSAgICBpZiAoIChtc3Ig
Pj0gTVNSX0lBMzJfTUMwX0NUTCAmJiBtc3IgPCBNU1JfSUEzMl9NQ3hfQ1RMKG5yX21jZV9iYW5r
cykpIHx8Ci0gICAgICAgIG1jZV92ZW5kb3JfYmFua19tc3IobXNyKSApCisgICAgaWYgKCAobXNy
ID49IE1TUl9JQTMyX01DMF9DVEwgJiYKKyAgICAgICAgICBtc3IgPCBNU1JfSUEzMl9NQ3hfQ1RM
KHYtPmFyY2gubWNnX2NhcCAmIE1DR19DQVBfQ09VTlQpKSB8fAorICAgICAgICAgbWNlX3ZlbmRv
cl9iYW5rX21zcih2LCBtc3IpICkKICAgICAgICAgcmV0dXJuIDE7CiAgICAgcmV0dXJuIDA7CiB9
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCisrKyBiL3hlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCkBAIC0xNDIxLDExICsxNDIxLDEyIEBAIGVudW0g
bWNoZWNrX3R5cGUgaW50ZWxfbWNoZWNrX2luaXQoc3RydWMKIH0KIAogLyogaW50ZWwgc3BlY2lm
aWMgTUNBIE1TUiAqLwotaW50IGludGVsX21jZV93cm1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90
IHZhbCkKK2ludCBpbnRlbF9tY2Vfd3Jtc3Ioc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zciwg
dWludDY0X3QgdmFsKQogewogICAgIGludCByZXQgPSAwOwogCi0gICAgaWYgKG1zciA+PSBNU1Jf
SUEzMl9NQzBfQ1RMMiAmJiBtc3IgPCAoTVNSX0lBMzJfTUMwX0NUTDIgKyBucl9tY2VfYmFua3Mp
KQorICAgIGlmICggbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCisgICAgICAgICBtc3IgPCBN
U1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCiAgICAg
ewogICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIldlIGhhdmUgZGlzYWJsZWQgQ01DSSBj
YXBhYmlsaXR5LCAiCiAgICAgICAgICAgICAgICAgICJHdWVzdCBzaG91bGQgbm90IHdyaXRlIHRo
aXMgTVNSIVxuIik7CkBAIC0xNDM1LDExICsxNDM2LDEyIEBAIGludCBpbnRlbF9tY2Vfd3Jtc3Io
dWludDMyX3QgbXNyLCB1aW50NjQKICAgICByZXR1cm4gcmV0OwogfQogCi1pbnQgaW50ZWxfbWNl
X3JkbXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKK2ludCBpbnRlbF9tY2VfcmRtc3Io
Y29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKIHsKICAg
ICBpbnQgcmV0ID0gMDsKIAotICAgIGlmIChtc3IgPj0gTVNSX0lBMzJfTUMwX0NUTDIgJiYgbXNy
IDwgKE1TUl9JQTMyX01DMF9DVEwyICsgbnJfbWNlX2JhbmtzKSkKKyAgICBpZiAoIG1zciA+PSBN
U1JfSUEzMl9NQzBfQ1RMMiAmJgorICAgICAgICAgbXNyIDwgTVNSX0lBMzJfTUN4X0NUTDIodi0+
YXJjaC5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQogICAgIHsKICAgICAgICAgbWNlX3ByaW50
ayhNQ0VfUVVJRVQsICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJpbGl0eSwgIgogICAgICAg
ICAgICAgICAgICAiR3Vlc3Qgc2hvdWxkIG5vdCByZWFkIHRoaXMgTVNSIVxuIik7Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYworKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVj
ay92bWNlLmMKQEAgLTEwLDYgKzEwLDcgQEAKICNpbmNsdWRlIDx4ZW4vZGVsYXkuaD4KICNpbmNs
dWRlIDx4ZW4vc21wLmg+CiAjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8eGVuL2h2bS9z
YXZlLmg+CiAjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPHB1YmxpYy9zeXNj
dGwuaD4KICNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CkBAIC00Miw3ICs0Myw2IEBAIGludCB2bWNl
X2luaXRfbXNyKHN0cnVjdCBkb21haW4gKmQpCiAgICAgICAgICAgIG5yX21jZV9iYW5rcyAqIHNp
emVvZigqZG9tX3ZtY2UoZCktPm1jaV9jdGwpKTsKIAogICAgIGRvbV92bWNlKGQpLT5tY2dfc3Rh
dHVzID0gMHgwOwotICAgIGRvbV92bWNlKGQpLT5tY2dfY2FwID0gZ19tY2dfY2FwOwogICAgIGRv
bV92bWNlKGQpLT5tY2dfY3RsID0gfih1aW50NjRfdCkweDA7CiAgICAgZG9tX3ZtY2UoZCktPm5y
X2luamVjdGlvbiA9IDA7CiAKQEAgLTYxLDIxICs2MSw0MSBAQCB2b2lkIHZtY2VfZGVzdHJveV9t
c3Ioc3RydWN0IGRvbWFpbiAqZCkKICAgICBkb21fdm1jZShkKSA9IE5VTEw7CiB9CiAKLXN0YXRp
YyBpbnQgYmFua19tY2VfcmRtc3Ioc3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3QgbXNyLCB1aW50
NjRfdCAqdmFsKQordm9pZCB2bWNlX2luaXRfdmNwdShzdHJ1Y3QgdmNwdSAqdikKIHsKLSAgICBp
bnQgYmFuaywgcmV0ID0gMTsKLSAgICBzdHJ1Y3QgZG9tYWluX21jYV9tc3JzICp2bWNlID0gZG9t
X3ZtY2UoZCk7CisgICAgdi0+YXJjaC5tY2dfY2FwID0gZ19tY2dfY2FwOworfQorCitpbnQgdm1j
ZV9yZXN0b3JlX3ZjcHUoc3RydWN0IHZjcHUgKnYsIHVpbnQ2NF90IGNhcHMpCit7CisgICAgaWYg
KCBjYXBzICYgfmdfbWNnX2NhcCAmIH5NQ0dfQ0FQX0NPVU5UICYgfk1DR19DVExfUCApCisgICAg
eworICAgICAgICBkcHJpbnRrKFhFTkxPR19HX0VSUiwgIiVzIHJlc3RvcmU6IHVuc3VwcG9ydGVk
IE1DQSBjYXBhYmlsaXRpZXMiCisgICAgICAgICAgICAgICAgIiAlIyIgUFJJeDY0ICIgZm9yIGQl
ZDp2JXUgKHN1cHBvcnRlZDogJSNMeClcbiIsCisgICAgICAgICAgICAgICAgaXNfaHZtX3ZjcHUo
dikgPyAiSFZNIiA6ICJQViIsIGNhcHMsIHYtPmRvbWFpbi0+ZG9tYWluX2lkLAorICAgICAgICAg
ICAgICAgIHYtPnZjcHVfaWQsIGdfbWNnX2NhcCAmIH5NQ0dfQ0FQX0NPVU5UKTsKKyAgICAgICAg
cmV0dXJuIC1FUEVSTTsKKyAgICB9CisKKyAgICB2LT5hcmNoLm1jZ19jYXAgPSBjYXBzOworICAg
IHJldHVybiAwOworfQorCitzdGF0aWMgaW50IGJhbmtfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2
Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCit7CisgICAgaW50IHJldCA9IDE7
CisgICAgdW5zaWduZWQgaW50IGJhbmsgPSAobXNyIC0gTVNSX0lBMzJfTUMwX0NUTCkgLyA0Owor
ICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZSh2LT5kb21haW4pOwog
ICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKIAotICAgIGJhbmsgPSAobXNyIC0gTVNSX0lB
MzJfTUMwX0NUTCkgLyA0OwotICAgIGlmICggYmFuayA+PSBucl9tY2VfYmFua3MgKQotICAgICAg
ICByZXR1cm4gLTE7CisgICAgKnZhbCA9IDA7CiAKICAgICBzd2l0Y2ggKCBtc3IgJiAoTVNSX0lB
MzJfTUMwX0NUTCB8IDMpICkKICAgICB7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfQ1RMOgotICAg
ICAgICAqdmFsID0gdm1jZS0+bWNpX2N0bFtiYW5rXSAmCi0gICAgICAgICAgICAoaF9tY2lfY3Ry
bCA/IGhfbWNpX2N0cmxbYmFua10gOiB+MFVMKTsKKyAgICAgICAgaWYgKCBiYW5rIDwgbnJfbWNl
X2JhbmtzICkKKyAgICAgICAgICAgICp2YWwgPSB2bWNlLT5tY2lfY3RsW2JhbmtdICYKKyAgICAg
ICAgICAgICAgICAgICAoaF9tY2lfY3RybCA/IGhfbWNpX2N0cmxbYmFua10gOiB+MFVMKTsKICAg
ICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRtc3IgTUMldV9DVEwgMHglIlBS
SXg2NCJcbiIsCiAgICAgICAgICAgICAgICAgICAgYmFuaywgKnZhbCk7CiAgICAgICAgIGJyZWFr
OwpAQCAtMTI2LDcgKzE0Niw3IEBAIHN0YXRpYyBpbnQgYmFua19tY2VfcmRtc3Ioc3RydWN0IGRv
bWFpbiAKICAgICAgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yICkKICAgICAg
ICAgewogICAgICAgICBjYXNlIFg4Nl9WRU5ET1JfSU5URUw6Ci0gICAgICAgICAgICByZXQgPSBp
bnRlbF9tY2VfcmRtc3IobXNyLCB2YWwpOworICAgICAgICAgICAgcmV0ID0gaW50ZWxfbWNlX3Jk
bXNyKHYsIG1zciwgdmFsKTsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBkZWZhdWx0Ogog
ICAgICAgICAgICAgcmV0ID0gMDsKQEAgLTE0NSwxMyArMTY1LDEzIEBAIHN0YXRpYyBpbnQgYmFu
a19tY2VfcmRtc3Ioc3RydWN0IGRvbWFpbiAKICAqLwogaW50IHZtY2VfcmRtc3IodWludDMyX3Qg
bXNyLCB1aW50NjRfdCAqdmFsKQogewotICAgIHN0cnVjdCBkb21haW4gKmQgPSBjdXJyZW50LT5k
b21haW47Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9IGRvbV92bWNlKGQpOwor
ICAgIGNvbnN0IHN0cnVjdCB2Y3B1ICpjdXIgPSBjdXJyZW50OworICAgIHN0cnVjdCBkb21haW5f
bWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZShjdXItPmRvbWFpbik7CiAgICAgaW50IHJldCA9IDE7
CiAKICAgICAqdmFsID0gMDsKIAotICAgIHNwaW5fbG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOwor
ICAgIHNwaW5fbG9jaygmdm1jZS0+bG9jayk7CiAKICAgICBzd2l0Y2ggKCBtc3IgKQogICAgIHsK
QEAgLTE2MiwzOSArMTgyLDM4IEBAIGludCB2bWNlX3JkbXNyKHVpbnQzMl90IG1zciwgdWludDY0
X3QgKnYKICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogcmRtc3IgTUNHX1NUQVRVUyAweCUi
UFJJeDY0IlxuIiwgKnZhbCk7CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgTVNSX0lBMzJfTUNH
X0NBUDoKLSAgICAgICAgKnZhbCA9IHZtY2UtPm1jZ19jYXA7CisgICAgICAgICp2YWwgPSBjdXIt
PmFyY2gubWNnX2NhcDsKICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRt
c3IgTUNHX0NBUCAweCUiUFJJeDY0IlxuIiwKICAgICAgICAgICAgICAgICAgICAqdmFsKTsKICAg
ICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfQ1RMOgogICAgICAgICAvKiBBbHdh
eXMgMCBpZiBubyBDVEwgc3VwcG9ydCAqLwotICAgICAgICAqdmFsID0gdm1jZS0+bWNnX2N0bCAm
IGhfbWNnX2N0bDsKKyAgICAgICAgaWYgKCBjdXItPmFyY2gubWNnX2NhcCAmIE1DR19DVExfUCAp
CisgICAgICAgICAgICAqdmFsID0gdm1jZS0+bWNnX2N0bCAmIGhfbWNnX2N0bDsKICAgICAgICAg
bWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRtc3IgTUNHX0NUTCAweCUiUFJJeDY0Ilxu
IiwKICAgICAgICAgICAgICAgICAgICAqdmFsKTsKICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVs
dDoKLSAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNyKG1zcikgPyBiYW5rX21jZV9yZG1zcihkLCBt
c3IsIHZhbCkgOiAwOworICAgICAgICByZXQgPSBtY2VfYmFua19tc3IoY3VyLCBtc3IpID8gYmFu
a19tY2VfcmRtc3IoY3VyLCBtc3IsIHZhbCkgOiAwOwogICAgICAgICBicmVhazsKICAgICB9CiAK
LSAgICBzcGluX3VubG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOworICAgIHNwaW5fdW5sb2NrKCZ2
bWNlLT5sb2NrKTsKICAgICByZXR1cm4gcmV0OwogfQogCi1zdGF0aWMgaW50IGJhbmtfbWNlX3dy
bXNyKHN0cnVjdCBkb21haW4gKmQsIHUzMiBtc3IsIHU2NCB2YWwpCitzdGF0aWMgaW50IGJhbmtf
bWNlX3dybXNyKHN0cnVjdCB2Y3B1ICp2LCB1MzIgbXNyLCB1NjQgdmFsKQogewotICAgIGludCBi
YW5rLCByZXQgPSAxOwotICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1j
ZShkKTsKKyAgICBpbnQgcmV0ID0gMTsKKyAgICB1bnNpZ25lZCBpbnQgYmFuayA9IChtc3IgLSBN
U1JfSUEzMl9NQzBfQ1RMKSAvIDQ7CisgICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9
IGRvbV92bWNlKHYtPmRvbWFpbik7CiAgICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5ID0gTlVM
TDsKIAotICAgIGJhbmsgPSAobXNyIC0gTVNSX0lBMzJfTUMwX0NUTCkgLyA0OwotICAgIGlmICgg
YmFuayA+PSBucl9tY2VfYmFua3MgKQotICAgICAgICByZXR1cm4gLUVJTlZBTDsKLQogICAgIHN3
aXRjaCAoIG1zciAmIChNU1JfSUEzMl9NQzBfQ1RMIHwgMykgKQogICAgIHsKICAgICBjYXNlIE1T
Ul9JQTMyX01DMF9DVEw6Ci0gICAgICAgIHZtY2UtPm1jaV9jdGxbYmFua10gPSB2YWw7CisgICAg
ICAgIGlmICggYmFuayA8IG5yX21jZV9iYW5rcyApCisgICAgICAgICAgICB2bWNlLT5tY2lfY3Rs
W2JhbmtdID0gdmFsOwogICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9TVEFU
VVM6CiAgICAgICAgIC8qIEdpdmUgdGhlIGZpcnN0IGVudHJ5IG9mIHRoZSBsaXN0LCBpdCBjb3Jy
ZXNwb25kcyB0byBjdXJyZW50CkBAIC0yMDIsOSArMjIxLDkgQEAgc3RhdGljIGludCBiYW5rX21j
ZV93cm1zcihzdHJ1Y3QgZG9tYWluIAogICAgICAgICAgKiB0aGUgZ3Vlc3QsIHRoaXMgbm9kZSB3
aWxsIGJlIGRlbGV0ZWQuCiAgICAgICAgICAqIE9ubHkgZXJyb3IgYmFuayBpcyB3cml0dGVuLiBO
b24tZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KICAgICAgICAgICovCi0gICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJmRvbV92bWNlKGQpLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKICAgICAgICAgewotICAgICAgICAg
ICAgZW50cnkgPSBsaXN0X2VudHJ5KGRvbV92bWNlKGQpLT5pbXBhY3RfaGVhZGVyLm5leHQsCisg
ICAgICAgICAgICBlbnRyeSA9IGxpc3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsK
ICAgICAgICAgICAgIGlmICggZW50cnktPmJhbmsgPT0gYmFuayApCiAgICAgICAgICAgICAgICAg
ZW50cnktPm1jaV9zdGF0dXMgPSB2YWw7CkBAIC0yMjgsNyArMjQ3LDcgQEAgc3RhdGljIGludCBi
YW5rX21jZV93cm1zcihzdHJ1Y3QgZG9tYWluIAogICAgICAgICBzd2l0Y2ggKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgKQogICAgICAgICB7CiAgICAgICAgIGNhc2UgWDg2X1ZFTkRPUl9JTlRF
TDoKLSAgICAgICAgICAgIHJldCA9IGludGVsX21jZV93cm1zcihtc3IsIHZhbCk7CisgICAgICAg
ICAgICByZXQgPSBpbnRlbF9tY2Vfd3Jtc3IodiwgbXNyLCB2YWwpOwogICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAgICByZXQgPSAwOwpAQCAtMjQ3LDkgKzI2
Niw5IEBAIHN0YXRpYyBpbnQgYmFua19tY2Vfd3Jtc3Ioc3RydWN0IGRvbWFpbiAKICAqLwogaW50
IHZtY2Vfd3Jtc3IodTMyIG1zciwgdTY0IHZhbCkKIHsKLSAgICBzdHJ1Y3QgZG9tYWluICpkID0g
Y3VycmVudC0+ZG9tYWluOworICAgIHN0cnVjdCB2Y3B1ICpjdXIgPSBjdXJyZW50OwogICAgIHN0
cnVjdCBiYW5rX2VudHJ5ICplbnRyeSA9IE5VTEw7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNy
cyAqdm1jZSA9IGRvbV92bWNlKGQpOworICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2Ug
PSBkb21fdm1jZShjdXItPmRvbWFpbik7CiAgICAgaW50IHJldCA9IDE7CiAKICAgICBpZiAoICFn
X21jZ19jYXAgKQpAQCAtMjY2LDcgKzI4NSw3IEBAIGludCB2bWNlX3dybXNyKHUzMiBtc3IsIHU2
NCB2YWwpCiAgICAgICAgIHZtY2UtPm1jZ19zdGF0dXMgPSB2YWw7CiAgICAgICAgIG1jZV9wcmlu
dGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHdybXNyIE1DR19TVEFUVVMgJSJQUkl4NjQiXG4iLCB2YWwp
OwogICAgICAgICAvKiBGb3IgSFZNIGd1ZXN0LCB0aGlzIGlzIHRoZSBwb2ludCBmb3IgZGVsZXRp
bmcgdk1DRSBpbmplY3Rpb24gbm9kZSAqLwotICAgICAgICBpZiAoIGQtPmlzX2h2bSAmJiAodm1j
ZS0+bnJfaW5qZWN0aW9uID4gMCkgKQorICAgICAgICBpZiAoIGlzX2h2bV92Y3B1KGN1cikgJiYg
KHZtY2UtPm5yX2luamVjdGlvbiA+IDApICkKICAgICAgICAgewogICAgICAgICAgICAgdm1jZS0+
bnJfaW5qZWN0aW9uLS07IC8qIFNob3VsZCBiZSAwICovCiAgICAgICAgICAgICBpZiAoICFsaXN0
X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCkBAIC0yOTMsNyArMzEyLDcgQEAgaW50IHZt
Y2Vfd3Jtc3IodTMyIG1zciwgdTY0IHZhbCkKICAgICAgICAgcmV0ID0gLTE7CiAgICAgICAgIGJy
ZWFrOwogICAgIGRlZmF1bHQ6Ci0gICAgICAgIHJldCA9IG1jZV9iYW5rX21zcihtc3IpID8gYmFu
a19tY2Vfd3Jtc3IoZCwgbXNyLCB2YWwpIDogMDsKKyAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNy
KGN1ciwgbXNyKSA/IGJhbmtfbWNlX3dybXNyKGN1ciwgbXNyLCB2YWwpIDogMDsKICAgICAgICAg
YnJlYWs7CiAgICAgfQogCkBAIC0zMDEsNiArMzIwLDQ2IEBAIGludCB2bWNlX3dybXNyKHUzMiBt
c3IsIHU2NCB2YWwpCiAgICAgcmV0dXJuIHJldDsKIH0KIAorc3RhdGljIGludCB2bWNlX3NhdmVf
dmNwdV9jdHh0KHN0cnVjdCBkb21haW4gKmQsIGh2bV9kb21haW5fY29udGV4dF90ICpoKQorewor
ICAgIHN0cnVjdCB2Y3B1ICp2OworICAgIGludCBlcnIgPSAwOworCisgICAgZm9yX2VhY2hfdmNw
dSggZCwgdiApIHsKKyAgICAgICAgc3RydWN0IGh2bV92bWNlX3ZjcHUgY3R4dCA9IHsKKyAgICAg
ICAgICAgIC5jYXBzID0gdi0+YXJjaC5tY2dfY2FwCisgICAgICAgIH07CisKKyAgICAgICAgZXJy
ID0gaHZtX3NhdmVfZW50cnkoVk1DRV9WQ1BVLCB2LT52Y3B1X2lkLCBoLCAmY3R4dCk7CisgICAg
ICAgIGlmICggZXJyICkKKyAgICAgICAgICAgIGJyZWFrOworICAgIH0KKworICAgIHJldHVybiBl
cnI7Cit9CisKK3N0YXRpYyBpbnQgdm1jZV9sb2FkX3ZjcHVfY3R4dChzdHJ1Y3QgZG9tYWluICpk
LCBodm1fZG9tYWluX2NvbnRleHRfdCAqaCkKK3sKKyAgICB1bnNpZ25lZCBpbnQgdmNwdWlkID0g
aHZtX2xvYWRfaW5zdGFuY2UoaCk7CisgICAgc3RydWN0IHZjcHUgKnY7CisgICAgc3RydWN0IGh2
bV92bWNlX3ZjcHUgY3R4dDsKKyAgICBpbnQgZXJyOworCisgICAgaWYgKCB2Y3B1aWQgPj0gZC0+
bWF4X3ZjcHVzIHx8ICh2ID0gZC0+dmNwdVt2Y3B1aWRdKSA9PSBOVUxMICkKKyAgICB7CisgICAg
ICAgIGRwcmludGsoWEVOTE9HX0dfRVJSLCAiSFZNIHJlc3RvcmU6IGRvbSVkIGhhcyBubyB2Y3B1
JXVcbiIsCisgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkLCB2Y3B1aWQpOworICAgICAgICBl
cnIgPSAtRUlOVkFMOworICAgIH0KKyAgICBlbHNlCisgICAgICAgIGVyciA9IGh2bV9sb2FkX2Vu
dHJ5KFZNQ0VfVkNQVSwgaCwgJmN0eHQpOworCisgICAgcmV0dXJuIGVyciA/OiB2bWNlX3Jlc3Rv
cmVfdmNwdSh2LCBjdHh0LmNhcHMpOworfQorCitIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFZN
Q0VfVkNQVSwgdm1jZV9zYXZlX3ZjcHVfY3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
dm1jZV9sb2FkX3ZjcHVfY3R4dCwgMSwgSFZNU1JfUEVSX1ZDUFUpOworCiBpbnQgaW5qZWN0X3Zt
Y2Uoc3RydWN0IGRvbWFpbiAqZCkKIHsKICAgICBpbnQgY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgp
OwotLS0gYS94ZW4vYXJjaC94ODYvZG9tYWluLmMKKysrIGIveGVuL2FyY2gveDg2L2RvbWFpbi5j
CkBAIC00MjIsNiArNDIyLDggQEAgaW50IHZjcHVfaW5pdGlhbGlzZShzdHJ1Y3QgdmNwdSAqdikK
ICAgICBpZiAoIChyYyA9IHZjcHVfaW5pdF9mcHUodikpICE9IDAgKQogICAgICAgICByZXR1cm4g
cmM7CiAKKyAgICB2bWNlX2luaXRfdmNwdSh2KTsKKwogICAgIGlmICggaXNfaHZtX2RvbWFpbihk
KSApCiAgICAgewogICAgICAgICByYyA9IGh2bV92Y3B1X2luaXRpYWxpc2Uodik7Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9kb21jdGwuYworKysgYi94ZW4vYXJjaC94ODYvZG9tY3RsLmMKQEAgLTEwMjcs
MTEgKzEwMjcsMTIgQEAgbG9uZyBhcmNoX2RvX2RvbWN0bCgKICAgICAgICAgICAgICAgICBldmMt
PnN5c2NhbGwzMl9jYWxsYmFja19laXAgICAgPSAwOwogICAgICAgICAgICAgICAgIGV2Yy0+c3lz
Y2FsbDMyX2Rpc2FibGVzX2V2ZW50cyA9IDA7CiAgICAgICAgICAgICB9CisgICAgICAgICAgICBl
dmMtPm1jZ19jYXAgPSB2LT5hcmNoLm1jZ19jYXA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZQog
ICAgICAgICB7CiAgICAgICAgICAgICByZXQgPSAtRUlOVkFMOwotICAgICAgICAgICAgaWYgKCBl
dmMtPnNpemUgIT0gc2l6ZW9mKCpldmMpICkKKyAgICAgICAgICAgIGlmICggZXZjLT5zaXplIDwg
b2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2dfY2FwKSApCiAgICAgICAgICAgICAgICAgZ290byBl
eHRfdmNwdWNvbnRleHRfb3V0OwogI2lmZGVmIF9feDg2XzY0X18KICAgICAgICAgICAgIGlmICgg
IWlzX2h2bV9kb21haW4oZCkgKQpAQCAtMTA1OSw2ICsxMDYwLDEwIEBAIGxvbmcgYXJjaF9kb19k
b21jdGwoCiAgICAgICAgICAgICAgICAgIChldmMtPnN5c2NhbGwzMl9jYWxsYmFja19jcyAmIH4z
KSB8fAogICAgICAgICAgICAgICAgICBldmMtPnN5c2NhbGwzMl9jYWxsYmFja19laXAgKQogICAg
ICAgICAgICAgICAgIGdvdG8gZXh0X3ZjcHVjb250ZXh0X291dDsKKworICAgICAgICAgICAgaWYg
KCBldmMtPnNpemUgPj0gb2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2dfY2FwKSArCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YoZXZjLT5tY2dfY2FwKSApCisgICAgICAgICAg
ICAgICAgcmV0ID0gdm1jZV9yZXN0b3JlX3ZjcHUodiwgZXZjLT5tY2dfY2FwKTsKICAgICAgICAg
fQogCiAgICAgICAgIHJldCA9IDA7Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaApAQCAtNDg4LDYgKzQ4OCw4IEBAIHN0
cnVjdCBhcmNoX3ZjcHUKICAgICAvKiBUaGlzIHZhcmlhYmxlIGRldGVybWluZXMgd2hldGhlciBu
b25sYXp5IGV4dGVuZGVkIHN0YXRlIGhhcyBiZWVuIHVzZWQsCiAgICAgICogYW5kIHRodXMgc2hv
dWxkIGJlIHNhdmVkL3Jlc3RvcmVkLiAqLwogICAgIGJvb2xfdCBub25sYXp5X3hzdGF0ZV91c2Vk
OworCisgICAgdWludDY0X3QgbWNnX2NhcDsKICAgICAKICAgICBzdHJ1Y3QgcGFnaW5nX3ZjcHUg
cGFnaW5nOwogCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNlLmgKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9tY2UuaApAQCAtMTYsNyArMTYsNiBAQCBzdHJ1Y3QgYmFua19lbnRyeSB7CiBz
dHJ1Y3QgZG9tYWluX21jYV9tc3JzCiB7CiAgICAgLyogR3Vlc3Qgc2hvdWxkIG5vdCBjaGFuZ2Ug
YmVsb3cgdmFsdWVzIGFmdGVyIERPTSBib290IHVwICovCi0gICAgdWludDY0X3QgbWNnX2NhcDsK
ICAgICB1aW50NjRfdCBtY2dfY3RsOwogICAgIHVpbnQ2NF90IG1jZ19zdGF0dXM7CiAgICAgdWlu
dDY0X3QgKm1jaV9jdGw7CkBAIC0yOCw2ICsyNyw4IEBAIHN0cnVjdCBkb21haW5fbWNhX21zcnMK
IC8qIEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwogZXh0ZXJuIGludCB2bWNlX2lu
aXRfbXNyKHN0cnVjdCBkb21haW4gKmQpOwogZXh0ZXJuIHZvaWQgdm1jZV9kZXN0cm95X21zcihz
dHJ1Y3QgZG9tYWluICpkKTsKK2V4dGVybiB2b2lkIHZtY2VfaW5pdF92Y3B1KHN0cnVjdCB2Y3B1
ICopOworZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqLCB1aW50NjRf
dCBjYXBzKTsKIGV4dGVybiBpbnQgdm1jZV93cm1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90IHZh
bCk7CiBleHRlcm4gaW50IHZtY2VfcmRtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCAqdmFsKTsK
IAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvaHZtL3NhdmUuaAorKysgYi94ZW4v
aW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvaHZtL3NhdmUuaApAQCAtNTg1LDkgKzU4NSwxNSBAQCBz
dHJ1Y3QgaHZtX3ZpcmlkaWFuX3ZjcHVfY29udGV4dCB7CiAKIERFQ0xBUkVfSFZNX1NBVkVfVFlQ
RShWSVJJRElBTl9WQ1BVLCAxNywgc3RydWN0IGh2bV92aXJpZGlhbl92Y3B1X2NvbnRleHQpOwog
CitzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSB7CisgICAgdWludDY0X3QgY2FwczsKK307CisKK0RFQ0xB
UkVfSFZNX1NBVkVfVFlQRShWTUNFX1ZDUFUsIDE4LCBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSk7CisK
IC8qIAogICogTGFyZ2VzdCB0eXBlLWNvZGUgaW4gdXNlCiAgKi8KLSNkZWZpbmUgSFZNX1NBVkVf
Q09ERV9NQVggMTcKKyNkZWZpbmUgSFZNX1NBVkVfQ09ERV9NQVggMTgKIAogI2VuZGlmIC8qIF9f
WEVOX1BVQkxJQ19IVk1fU0FWRV9YODZfSF9fICovCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9k
b21jdGwuaAorKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgKQEAgLTU1OSw3ICs1NTks
NyBAQCBzdHJ1Y3QgeGVuX2RvbWN0bF9leHRfdmNwdWNvbnRleHQgewogICAgIHVpbnQzMl90ICAg
ICAgICAgdmNwdTsKICAgICAvKgogICAgICAqIFNFVDogU2l6ZSBvZiBzdHJ1Y3QgKElOKQotICAg
ICAqIEdFVDogU2l6ZSBvZiBzdHJ1Y3QgKE9VVCkKKyAgICAgKiBHRVQ6IFNpemUgb2Ygc3RydWN0
IChPVVQsIHVwIHRvIDEyOCBieXRlcykKICAgICAgKi8KICAgICB1aW50MzJfdCAgICAgICAgIHNp
emU7CiAjaWYgZGVmaW5lZChfX2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82NF9fKQpAQCAtNTcx
LDYgKzU3MSw3IEBAIHN0cnVjdCB4ZW5fZG9tY3RsX2V4dF92Y3B1Y29udGV4dCB7CiAgICAgdWlu
dDE2X3QgICAgICAgICBzeXNlbnRlcl9jYWxsYmFja19jczsKICAgICB1aW50OF90ICAgICAgICAg
IHN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHM7CiAgICAgdWludDhfdCAgICAgICAgICBzeXNlbnRl
cl9kaXNhYmxlc19ldmVudHM7CisgICAgdWludDY0X2FsaWduZWRfdCBtY2dfY2FwOwogI2VuZGlm
CiB9OwogdHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9leHRfdmNwdWNvbnRleHQgeGVuX2RvbWN0
bF9leHRfdmNwdWNvbnRleHRfdDsK

--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=142;
	creation-date="Wed, 15 Feb 2012 11:04:26 GMT";
	modification-date="Wed, 15 Feb 2012 11:04:26 GMT"
Content-ID: <B8D27E4B2EB93741A96203690282D776@intel.com>
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QNClhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tDQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwNCg==

--_003_4F3B9E7E0200007800073218nat28tlfnovellcom_--

--_002_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335263B9DSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Jun 28 08:57:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:57: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 1SkAXD-0007uU-RP; Thu, 28 Jun 2012 08:57:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SkAXB-0007uB-RQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:57:06 +0000
Received: from [85.158.139.83:44825] by server-12.bemta-5.messagelabs.com id
	D3/9B-25233-06C1CEF4; Thu, 28 Jun 2012 08:57:04 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340873822!22572768!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzU5MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27550 invoked from network); 28 Jun 2012 08:57:03 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 08:57:03 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 01:57:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="185998778"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 28 Jun 2012 01:57:02 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 01:57:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 16:57:00 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Matt Wilson <msw@amazon.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Xen 4.2 Release Plan / TODO
Thread-Index: AQHNU9sUxWhIrFwv0U6Vg1v6HegEPpcMkgQAgAAeJgCAAr6+cA==
Date: Thu, 28 Jun 2012 08:56:59 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10101CDF@SHSMSX101.ccr.corp.intel.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
	<20120626210906.GA14905@phenom.dumpdata.com>
	<20120626225700.GB8676@US-SEA-R8XVZTX>
In-Reply-To: <20120626225700.GB8676@US-SEA-R8XVZTX>
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: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Matt Wilson
> Sent: Wednesday, June 27, 2012 6:57 AM
> To: Konrad Rzeszutek Wilk
> Cc: Ian Campbell; xen-devel
> Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
> 
> On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> > > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> > > >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> > > >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > >
> > > This may be a problem with the guest, rather than a problem with Xen
> > > or the toolstack. I tested on a domU running a 3.2.20-based Linux
> > > kernel. The domU kernel didn't automatically enable the vCPUs after
> > > calling "xl vcpu-set" to increase the allocation.
> > > [...]
> > >
> > > I've added this as a comment to the bugzilla.
> >
> > That is a generic bug - its a race in the generic code where
> > the cpuX directory is created; then udev kicks off and tries to
> > echo 1 > cpuX/online (but online hasn't been created yet); the
> cpu-hotplug
> > code creates 'online' directory.
> >
> > I've asked Greg KH about it, and here is his take:
> > https://lkml.org/lkml/2012/4/30/198
> >
> > But I never got to prep a patch. If somebody gets to do it before me,
> > I owe them a beer!
> 
> My problem was that I didn't even have a udev rule to auto-online
> hotplugged CPUs. Everything works as expected after adding the rule
> suggested on the wiki:
> http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug
> 
> I'm thinking that the bug report is just this well hashed out
> problem. For historical reference, here's the thread discussing the
> behavior change in pv-ops kernels:
>   http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html
> 
Hi Matt, thanks for the useful status.
According to my testing on xen-unstable(#25517) with linux3.4.3 dom0 and RHEL6.2
hvm guest, 'xl vcpu-set' can increase the number of the vCPU for guest. But it
can't decrease the number of vCPU. After trying to decrease the number of vCPU,
the number of the onlined CPU in /sys/devices/system/cpu/ or /proc/cpuinfo is not
changed.

But I can do "echo 0 > /sys/devices/system/cpu/cpu3/online" to offline the CPU3
in the guest even if I didn't use any command line like 'xl vcpu-set'.

Also, I can do "echo 1 > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:03/eject"
to remove CPU3 in the guest.

Note that 'CPU3' can be any CPU except for CPU0.

Also add a comment in the bugzilla.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:57:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:57: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 1SkAXD-0007uU-RP; Thu, 28 Jun 2012 08:57:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1SkAXB-0007uB-RQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:57:06 +0000
Received: from [85.158.139.83:44825] by server-12.bemta-5.messagelabs.com id
	D3/9B-25233-06C1CEF4; Thu, 28 Jun 2012 08:57:04 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340873822!22572768!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzU5MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27550 invoked from network); 28 Jun 2012 08:57:03 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 08:57:03 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 01:57:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="185998778"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 28 Jun 2012 01:57:02 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 01:57:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 16:57:00 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Matt Wilson <msw@amazon.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Xen 4.2 Release Plan / TODO
Thread-Index: AQHNU9sUxWhIrFwv0U6Vg1v6HegEPpcMkgQAgAAeJgCAAr6+cA==
Date: Thu, 28 Jun 2012 08:56:59 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10101CDF@SHSMSX101.ccr.corp.intel.com>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
	<20120626203151.GA8676@US-SEA-R8XVZTX>
	<20120626210906.GA14905@phenom.dumpdata.com>
	<20120626225700.GB8676@US-SEA-R8XVZTX>
In-Reply-To: <20120626225700.GB8676@US-SEA-R8XVZTX>
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: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Matt Wilson
> Sent: Wednesday, June 27, 2012 6:57 AM
> To: Konrad Rzeszutek Wilk
> Cc: Ian Campbell; xen-devel
> Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
> 
> On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:
> > > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:
> > > >     * [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
> > > >       http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > >
> > > This may be a problem with the guest, rather than a problem with Xen
> > > or the toolstack. I tested on a domU running a 3.2.20-based Linux
> > > kernel. The domU kernel didn't automatically enable the vCPUs after
> > > calling "xl vcpu-set" to increase the allocation.
> > > [...]
> > >
> > > I've added this as a comment to the bugzilla.
> >
> > That is a generic bug - its a race in the generic code where
> > the cpuX directory is created; then udev kicks off and tries to
> > echo 1 > cpuX/online (but online hasn't been created yet); the
> cpu-hotplug
> > code creates 'online' directory.
> >
> > I've asked Greg KH about it, and here is his take:
> > https://lkml.org/lkml/2012/4/30/198
> >
> > But I never got to prep a patch. If somebody gets to do it before me,
> > I owe them a beer!
> 
> My problem was that I didn't even have a udev rule to auto-online
> hotplugged CPUs. Everything works as expected after adding the rule
> suggested on the wiki:
> http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug
> 
> I'm thinking that the bug report is just this well hashed out
> problem. For historical reference, here's the thread discussing the
> behavior change in pv-ops kernels:
>   http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html
> 
Hi Matt, thanks for the useful status.
According to my testing on xen-unstable(#25517) with linux3.4.3 dom0 and RHEL6.2
hvm guest, 'xl vcpu-set' can increase the number of the vCPU for guest. But it
can't decrease the number of vCPU. After trying to decrease the number of vCPU,
the number of the onlined CPU in /sys/devices/system/cpu/ or /proc/cpuinfo is not
changed.

But I can do "echo 0 > /sys/devices/system/cpu/cpu3/online" to offline the CPU3
in the guest even if I didn't use any command line like 'xl vcpu-set'.

Also, I can do "echo 1 > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:03/eject"
to remove CPU3 in the guest.

Note that 'CPU3' can be any CPU except for CPU0.

Also add a comment in the bugzilla.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAYv-00086B-Cp; Thu, 28 Jun 2012 08:58: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 1SkAYt-000861-Is
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:58:51 +0000
Received: from [85.158.138.51:7735] by server-5.bemta-3.messagelabs.com id
	FA/CD-01572-ACC1CEF4; Thu, 28 Jun 2012 08:58:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340873930!23599048!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9799 invoked from network); 28 Jun 2012 08:58:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 08:58:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 09:58:50 +0100
Message-Id: <4FEC3916020000780008C649@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 09:59:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "RAN HYSLER" <ran_h@rad.com>
References: <36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1@exus4.ad.rad.co.il>
In-Reply-To: <36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1@exus4.ad.rad.co.il>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] VM Capacity on Intel's X.86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 00:27, RAN HYSLER <ran_h@rad.com> wrote:
> I want to use Xen's hypervisor infrastructure on a X.86 Gladden dual core 
> 1.5Ghz (it has a  1GE full duplex processing capacity).

This is not really a question to be raised on xen-devel, imo. Please
use xen-users instead...

> I was wondering if anyone knows :
> 
> 
> 1)      How many concurrent Linux-based VMs will the hypervisor be able to 
> support ?
> 
> 2)      Is there a PPS limitation ? If so, what is the max value ? (per VM 
> and total)
> 
> 3)      Is there a memory limitation ? If so, what is the max value ? (per 
> VM and total)

... and look for readily available information first (see
http://wiki.xen.org/wiki/Xen_Release_Features).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 08:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 08:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAYv-00086B-Cp; Thu, 28 Jun 2012 08:58: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 1SkAYt-000861-Is
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 08:58:51 +0000
Received: from [85.158.138.51:7735] by server-5.bemta-3.messagelabs.com id
	FA/CD-01572-ACC1CEF4; Thu, 28 Jun 2012 08:58:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340873930!23599048!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9799 invoked from network); 28 Jun 2012 08:58:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 08:58:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 09:58:50 +0100
Message-Id: <4FEC3916020000780008C649@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 09:59:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "RAN HYSLER" <ran_h@rad.com>
References: <36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1@exus4.ad.rad.co.il>
In-Reply-To: <36E02E39C6FA1E4B84BEB3C73D3B82A8835B07D1@exus4.ad.rad.co.il>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] VM Capacity on Intel's X.86
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 00:27, RAN HYSLER <ran_h@rad.com> wrote:
> I want to use Xen's hypervisor infrastructure on a X.86 Gladden dual core 
> 1.5Ghz (it has a  1GE full duplex processing capacity).

This is not really a question to be raised on xen-devel, imo. Please
use xen-users instead...

> I was wondering if anyone knows :
> 
> 
> 1)      How many concurrent Linux-based VMs will the hypervisor be able to 
> support ?
> 
> 2)      Is there a PPS limitation ? If so, what is the max value ? (per VM 
> and total)
> 
> 3)      Is there a memory limitation ? If so, what is the max value ? (per 
> VM and total)

... and look for readily available information first (see
http://wiki.xen.org/wiki/Xen_Release_Features).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAi9-0000AC-HG; Thu, 28 Jun 2012 09:08: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 1SkAi7-0000A7-SD
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:08:24 +0000
Received: from [85.158.138.51:17363] by server-11.bemta-3.messagelabs.com id
	C8/98-02904-20F1CEF4; Thu, 28 Jun 2012 09:08:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340874497!29922120!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21550 invoked from network); 28 Jun 2012 09:08:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 09:08:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 10:08:17 +0100
Message-Id: <4FEC3B4A020000780008C673@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 10:08:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 10:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>> The 2-bank approach also needs to be brought in line with the
>> current host derived value in MCG_CAP, especially if the code to
>> implement this new model doesn't make it into 4.2 (which would
>> generally save a larger value).
> 
> Let me repeat in my word to avoid misunderstanding about your concern:
> Your concern rooted from the history patch (c/s 24887, as attached) which 
> used to solve vMCE migration issue caused from bank number. I guess the patch 
> was not in xen4.1.x but would be in xen 4.2 release recently (right? and when 
> will xen 4.2 release?)

4.2 is in feature freeze right now, preparing for the release.

> Per my understanding, you want us to make sure our new vMCE model compatible 
> w/ olde vMCE. For example if our patch in xen 4.3 release, you want to make 
> sure a guest migrate from xen 4.2 to 4.3 would not broken. Is this your 
> concern?

Yes. If we can't get the save/restore records adjusted in time
for 4.2, compatibility with 4.2 would be a requirement. If we
manage to get the necessary adjustments done in time, and if
they're not too intrusive (i.e. would be acceptable at this late
stage of the development cycle), then the concern could be
dropped from an upstream perspective due to the lack of
support in 4.1 (and hence no backward compatibility issues).
BUT this isn't as simple from a product usage point of view: As
the save/restore code currently in -unstable was coded up to
address a problem observed by SLE11 SP2 users, we already
backported those patches. So compatibility will be a requirement
in any case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:08:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkAi9-0000AC-HG; Thu, 28 Jun 2012 09:08: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 1SkAi7-0000A7-SD
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:08:24 +0000
Received: from [85.158.138.51:17363] by server-11.bemta-3.messagelabs.com id
	C8/98-02904-20F1CEF4; Thu, 28 Jun 2012 09:08:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340874497!29922120!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21550 invoked from network); 28 Jun 2012 09:08:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 09:08:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 10:08:17 +0100
Message-Id: <4FEC3B4A020000780008C673@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 10:08:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 10:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>> The 2-bank approach also needs to be brought in line with the
>> current host derived value in MCG_CAP, especially if the code to
>> implement this new model doesn't make it into 4.2 (which would
>> generally save a larger value).
> 
> Let me repeat in my word to avoid misunderstanding about your concern:
> Your concern rooted from the history patch (c/s 24887, as attached) which 
> used to solve vMCE migration issue caused from bank number. I guess the patch 
> was not in xen4.1.x but would be in xen 4.2 release recently (right? and when 
> will xen 4.2 release?)

4.2 is in feature freeze right now, preparing for the release.

> Per my understanding, you want us to make sure our new vMCE model compatible 
> w/ olde vMCE. For example if our patch in xen 4.3 release, you want to make 
> sure a guest migrate from xen 4.2 to 4.3 would not broken. Is this your 
> concern?

Yes. If we can't get the save/restore records adjusted in time
for 4.2, compatibility with 4.2 would be a requirement. If we
manage to get the necessary adjustments done in time, and if
they're not too intrusive (i.e. would be acceptable at this late
stage of the development cycle), then the concern could be
dropped from an upstream perspective due to the lack of
support in 4.1 (and hence no backward compatibility issues).
BUT this isn't as simple from a product usage point of view: As
the save/restore code currently in -unstable was coded up to
address a problem observed by SLE11 SP2 users, we already
backported those patches. So compatibility will be a requirement
in any case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:23:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:23: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 1SkAwK-0000NZ-Uz; Thu, 28 Jun 2012 09:23:04 +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 1SkAwJ-0000NU-CQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:23:03 +0000
Received: from [193.109.254.147:3133] by server-3.bemta-14.messagelabs.com id
	DC/C7-08687-6722CEF4; Thu, 28 Jun 2012 09:23:02 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340875378!8980958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5904 invoked from network); 28 Jun 2012 09:22:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:22:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13263135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:22:58 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:22:58 +0100
Message-ID: <4FEC2248.4080005@citrix.com>
Date: Thu, 28 Jun 2012 10:22:16 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340787043.29172.10.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFR1ZSwgMjAxMi0wNi0yNiBhdCAxNzo1OCArMDEwMCwg
UGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIFR1ZSwgSnVuIDI2LCAyMDEyIGF0IDA1OjIw
OjM1UE0gKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+IElhbiBKYWNrc29uIHdyb3Rl
Ogo+Pj4+IFJvZ2VyIFBhdSBNb25uZSB3cml0ZXMgKCJbUEFUQ0ggdjYgMTAvMTNdIGxpYnhsOiBz
ZXQgbmljIHR5cGUgdG8gVklGIGJ5IGRlZmF1bHQiKToKPj4+Pj4gU2V0IHRoZSBkZWZhdWx0IHZh
bHVlIGZvciBuaWMgaW50ZXJmYWNlcyB0byBWSUYsIHNpbmNlIGl0IHVzZWQgdG8gYmUKPj4+Pj4g
SU9FTVUsIGV2ZW4gZm9yIFBWIGd1ZXN0cy4KPj4+PiBJZiB5b3VyIHJlbmFtaW5nIG9mIElPRU1V
IHRvIFZJRl9JT0VNVSBpcyBjb3JyZWN0LCBkb2VzIHRoaXMgbm90IHN0b3AKPj4+PiBIVk0gZ3Vl
c3RzIGdldHRpbmcgZW11bGF0ZWQgbmV0d29yayBpbnRlcmZhY2VzIGJ5IGRlZmF1bHQgPwo+Pj4g
WWVzLCBpZiB5b3Ugd2FudCBlbXVsYXRlZCBpbnRlcmZhY2VzIHdpdGggSFZNIGd1ZXN0cyB5b3Ug
c2hvdWxkIHVzZQo+Pj4gJ3R5cGU9aW9lbXUnLCB0aGF0J3MgaG93IGl0IGhhcyBhbHdheXMgYmVl
biByaWdodD8KPj4+Cj4+IFdpdGggWGVuIDQuMSB5b3UgZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9
aW9lbXUiLiBFbXVsYXRlZCBpbnRlcmZhY2VzIHNlZW0gdG8gd29yayBPSyB3aXRob3V0ICJ0eXBl
PWlvZW11Ii4KPj4gKGF0IGxlYXN0IHdpdGggeG0veGVuZCkuIEFuZCBpZiB5b3UgYWN0dWFsbHkg
ZG8gYWRkICJ0eXBlPWlvZW11IiBpdCB3aWxsIGJyZWFrIFBWSFZNIGZvciBMaW51eCBndWVzdHMu
Lgo+Pgo+PiBRdW90ZSBmcm9tOiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuTGludXhQVm9u
SFZNZHJpdmVycwo+Pgo+PiAiTk9URSEgSWYgeW91IGhhdmUgInR5cGU9aW9lbXUiIHNwZWNpZmll
ZCBmb3IgdGhlICJ2aWYiLWxpbmUsIFBWSFZNCj4+IGRyaXZlcnMgV0lMTCBOT1Qgd29yayEgRG9u
J3Qgc3BlY2lmeSAidHlwZSIgcGFyYW1ldGVyIGZvciB0aGUgdmlmLgo+PiAod2l0aCB0eXBlPWlv
ZW11IHRoZSBwdmh2bSBuaWMgaW4gdGhlIFZNIHdpbGwgaGF2ZSBtYWMgYWRkcmVzcyBmdWxsIG9m
Cj4+IHplcm9lcyAtIGFuZCB0aHVzIHdvbid0IHdvcmshKS4gIgo+Cj4gbWFjPTAwOjAwOjAwOjAw
OjAwIGlzIGNlcnRhaW5seSBhIGJ1ZywgaWYgKGxpYil4bCBiZWhhdmVzIHRoaXMgd2F5IHRvbwo+
IHRoZW4gd2Ugc2hvdWxkIGZpeCBpdC4KPgo+IEJ1dCBzdXJlbHkgdHlwZT1pb2VtdSBpcyBzdXBw
b3NlZCB0byBtZWFuICJvbmx5IGVtdWxhdGVkIj8gSW4gd2hpY2ggY2FzZQo+IHRoZSBhY3R1YWwg
eGVuZCBidWcgaXMgdGhhdCBpdCBjcmVhdGVkIGEgUFYgVklGIGF0IGFsbC4KCkN1cnJlbnRseSB0
aGVyZSdzIG5vIG5ldHdvcmsgdHlwZSB0aGF0IG1lYW5zICJlbXVsYXRlZCBvbmx5Iiwgd2UgaGF2
ZSAKVklGIGFuZCBWSUZfSU9FTVUuCgo+IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhlcmU/IEkgdGhp
bmsgdGhleSBhcmUsIHdpdGggdGhlaXIgKGxpYil4bAo+IGJlaGF2aW91cjoKPgo+IAkJUFYJCQkJ
SFZNCj4gdHlwZT1pb2VtdQltZWFuaW5nbGVzcyAvIGFuIGVycm9yCQllbXVsYXRlZCBkZXZpY2Ug
KyBwYXJhdmlydCBWSUYqCj4gdHlwZT12aWYJcGFyYXZpcnQgVklGIGRldmljZSomCQlwYXJhdmly
dCBWSUYgZGV2aWNlIG9ubHkmCgpZb3UgYXJlIG1pc3NpbmcgYSByb3csIHRoZSBkZWZhdWx0IG9u
ZSB3aGVuIHVzZXIgZG9lc24ndCBzcGVjaWZ5IAphbnl0aGluZywgdGhpcyBjdXJyZW50bHkgaXM6
CgoJUFYJCQkJSFZNCmRlZmF1bHQJbmljIHR5cGUgaXMgc2V0IHRvIElFT01VCW5pYyB0eXBlIGlz
IHNldCB0byBJT0VNVQoKSW4gdGhlIHBhc3QgdGhpcyB3YXMgbm90IGEgcHJvYmxlbSwgc2luY2Ug
d2hlbiB0aGUgZ3Vlc3QgaXMgUFYsIHdlIApkaWRuJ3QgbGF1bmNoIFFlbXUsIGFuZCB0aHVzIHRo
ZSB0YXAgZGV2aWNlIHdhcyBuZXZlciBjcmVhdGVkIGFuZCB0aGUgCmhvdHBsdWcgc2NyaXB0cyB3
ZXJlIG5vdCBsYXVuY2hlZC4gTm93IHRoYXQgd2UgbGF1bmNoIGhvdHBsdWcgc2NyaXB0cyAKZnJv
bSBsaWJ4bCB0aGlzIGlzIGEgcHJvYmxlbSwgYmVjYXVzZSB3aGVuIHdlIGNhbGwgbGlieGxfZGV2
aWNlX25pY19hZGQsIApsaWJ4bCBoYXMgbm8gaWRlYSBpZiB0aGUgZG9tYWluIGlzIGEgUFYgb3Ig
SFZNIGd1ZXN0LCBhbmQgb25seSBzZWVzIHRoZSAKbmV0d29yayB0eXBlLCB3aGljaCBpcyBzZXQg
dG8gSU9FTVUgYnkgZGVmYXVsdC4KClRoaXMgaXMgdGhlIG1haW4gcHJvYmxlbSwgSSB0aGluayBp
dCBzaG91bGQgYmUgb2sgdG8gbGVhdmUgdGhlIGRlZmF1bHQgCnR5cGUgYXMgSU9FTVUgaW4gbGli
eGxfX2RldmljZV9uaWNfc2V0ZGVmYXVsdCBhbmQgc2V0IHRoZSB0eXBlIG1hbnVhbGx5IAp0byBW
SUYgZm9yIFBWIGd1ZXN0cyBpbiAKbGlieGxfY3JlYXRlLmM6bGlieGxfX2RvbWFpbl9idWlsZF9p
bmZvX3NldGRlZmF1bHQsIGRvZXMgdGhpcyBzb3VuZCBvaz8KCj4gV2hlcmUgKiA9PSBjdXJyZW50
IGxpYih4bCkgZGVmYXVsdCBhbmQmICA9PSBwcm9wb3NlZCBkZWZhdWx0IGFmdGVyIHRoaXMgY2hh
bmdlLgo+IGFuZDoKPiAgICAgICAgICB0eXBlPWlvZW11ID0+CUxJQlhMX05JQ19UWVBFX0lPRU1V
IHRvIGJlIHJlbmFtZWQgTElCWExfTklDX1RZUEVfVklGX0lPRU1VLgo+ICAgICAgICAgIHR5cGU9
dmlmID0+CUxJQlhMX05JVl9UWVBFX1ZJRiwgbm8gcmVuYW1pbmcgcHJvcG9zZWQuCj4KPiBCdXQg
aWYgbXkgdGFibGUgaXMgY29ycmVjdCB0aGVuIExJQlhMX05JQ19UWVBFX1ZJRl9JT0VNVSBpcyB0
aGUgcmlnaHQKPiBkZWZhdWx0IGFuZCBzaG91bGRuJ3QgYmUgY2hhbmdlZC4gUm9nZXIgY2FuIHlv
dSBlaXRoZXIgY29uZmlybSBvcgo+IGNvcnJlY3QgbXkgdGFibGUuCj4KPiBJYW4uCj4KCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:23:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:23: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 1SkAwK-0000NZ-Uz; Thu, 28 Jun 2012 09:23:04 +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 1SkAwJ-0000NU-CQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:23:03 +0000
Received: from [193.109.254.147:3133] by server-3.bemta-14.messagelabs.com id
	DC/C7-08687-6722CEF4; Thu, 28 Jun 2012 09:23:02 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340875378!8980958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5904 invoked from network); 28 Jun 2012 09:22:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:22:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13263135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:22:58 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:22:58 +0100
Message-ID: <4FEC2248.4080005@citrix.com>
Date: Thu, 28 Jun 2012 10:22:16 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340787043.29172.10.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFR1ZSwgMjAxMi0wNi0yNiBhdCAxNzo1OCArMDEwMCwg
UGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIFR1ZSwgSnVuIDI2LCAyMDEyIGF0IDA1OjIw
OjM1UE0gKzAxMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+IElhbiBKYWNrc29uIHdyb3Rl
Ogo+Pj4+IFJvZ2VyIFBhdSBNb25uZSB3cml0ZXMgKCJbUEFUQ0ggdjYgMTAvMTNdIGxpYnhsOiBz
ZXQgbmljIHR5cGUgdG8gVklGIGJ5IGRlZmF1bHQiKToKPj4+Pj4gU2V0IHRoZSBkZWZhdWx0IHZh
bHVlIGZvciBuaWMgaW50ZXJmYWNlcyB0byBWSUYsIHNpbmNlIGl0IHVzZWQgdG8gYmUKPj4+Pj4g
SU9FTVUsIGV2ZW4gZm9yIFBWIGd1ZXN0cy4KPj4+PiBJZiB5b3VyIHJlbmFtaW5nIG9mIElPRU1V
IHRvIFZJRl9JT0VNVSBpcyBjb3JyZWN0LCBkb2VzIHRoaXMgbm90IHN0b3AKPj4+PiBIVk0gZ3Vl
c3RzIGdldHRpbmcgZW11bGF0ZWQgbmV0d29yayBpbnRlcmZhY2VzIGJ5IGRlZmF1bHQgPwo+Pj4g
WWVzLCBpZiB5b3Ugd2FudCBlbXVsYXRlZCBpbnRlcmZhY2VzIHdpdGggSFZNIGd1ZXN0cyB5b3Ug
c2hvdWxkIHVzZQo+Pj4gJ3R5cGU9aW9lbXUnLCB0aGF0J3MgaG93IGl0IGhhcyBhbHdheXMgYmVl
biByaWdodD8KPj4+Cj4+IFdpdGggWGVuIDQuMSB5b3UgZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9
aW9lbXUiLiBFbXVsYXRlZCBpbnRlcmZhY2VzIHNlZW0gdG8gd29yayBPSyB3aXRob3V0ICJ0eXBl
PWlvZW11Ii4KPj4gKGF0IGxlYXN0IHdpdGggeG0veGVuZCkuIEFuZCBpZiB5b3UgYWN0dWFsbHkg
ZG8gYWRkICJ0eXBlPWlvZW11IiBpdCB3aWxsIGJyZWFrIFBWSFZNIGZvciBMaW51eCBndWVzdHMu
Lgo+Pgo+PiBRdW90ZSBmcm9tOiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuTGludXhQVm9u
SFZNZHJpdmVycwo+Pgo+PiAiTk9URSEgSWYgeW91IGhhdmUgInR5cGU9aW9lbXUiIHNwZWNpZmll
ZCBmb3IgdGhlICJ2aWYiLWxpbmUsIFBWSFZNCj4+IGRyaXZlcnMgV0lMTCBOT1Qgd29yayEgRG9u
J3Qgc3BlY2lmeSAidHlwZSIgcGFyYW1ldGVyIGZvciB0aGUgdmlmLgo+PiAod2l0aCB0eXBlPWlv
ZW11IHRoZSBwdmh2bSBuaWMgaW4gdGhlIFZNIHdpbGwgaGF2ZSBtYWMgYWRkcmVzcyBmdWxsIG9m
Cj4+IHplcm9lcyAtIGFuZCB0aHVzIHdvbid0IHdvcmshKS4gIgo+Cj4gbWFjPTAwOjAwOjAwOjAw
OjAwIGlzIGNlcnRhaW5seSBhIGJ1ZywgaWYgKGxpYil4bCBiZWhhdmVzIHRoaXMgd2F5IHRvbwo+
IHRoZW4gd2Ugc2hvdWxkIGZpeCBpdC4KPgo+IEJ1dCBzdXJlbHkgdHlwZT1pb2VtdSBpcyBzdXBw
b3NlZCB0byBtZWFuICJvbmx5IGVtdWxhdGVkIj8gSW4gd2hpY2ggY2FzZQo+IHRoZSBhY3R1YWwg
eGVuZCBidWcgaXMgdGhhdCBpdCBjcmVhdGVkIGEgUFYgVklGIGF0IGFsbC4KCkN1cnJlbnRseSB0
aGVyZSdzIG5vIG5ldHdvcmsgdHlwZSB0aGF0IG1lYW5zICJlbXVsYXRlZCBvbmx5Iiwgd2UgaGF2
ZSAKVklGIGFuZCBWSUZfSU9FTVUuCgo+IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhlcmU/IEkgdGhp
bmsgdGhleSBhcmUsIHdpdGggdGhlaXIgKGxpYil4bAo+IGJlaGF2aW91cjoKPgo+IAkJUFYJCQkJ
SFZNCj4gdHlwZT1pb2VtdQltZWFuaW5nbGVzcyAvIGFuIGVycm9yCQllbXVsYXRlZCBkZXZpY2Ug
KyBwYXJhdmlydCBWSUYqCj4gdHlwZT12aWYJcGFyYXZpcnQgVklGIGRldmljZSomCQlwYXJhdmly
dCBWSUYgZGV2aWNlIG9ubHkmCgpZb3UgYXJlIG1pc3NpbmcgYSByb3csIHRoZSBkZWZhdWx0IG9u
ZSB3aGVuIHVzZXIgZG9lc24ndCBzcGVjaWZ5IAphbnl0aGluZywgdGhpcyBjdXJyZW50bHkgaXM6
CgoJUFYJCQkJSFZNCmRlZmF1bHQJbmljIHR5cGUgaXMgc2V0IHRvIElFT01VCW5pYyB0eXBlIGlz
IHNldCB0byBJT0VNVQoKSW4gdGhlIHBhc3QgdGhpcyB3YXMgbm90IGEgcHJvYmxlbSwgc2luY2Ug
d2hlbiB0aGUgZ3Vlc3QgaXMgUFYsIHdlIApkaWRuJ3QgbGF1bmNoIFFlbXUsIGFuZCB0aHVzIHRo
ZSB0YXAgZGV2aWNlIHdhcyBuZXZlciBjcmVhdGVkIGFuZCB0aGUgCmhvdHBsdWcgc2NyaXB0cyB3
ZXJlIG5vdCBsYXVuY2hlZC4gTm93IHRoYXQgd2UgbGF1bmNoIGhvdHBsdWcgc2NyaXB0cyAKZnJv
bSBsaWJ4bCB0aGlzIGlzIGEgcHJvYmxlbSwgYmVjYXVzZSB3aGVuIHdlIGNhbGwgbGlieGxfZGV2
aWNlX25pY19hZGQsIApsaWJ4bCBoYXMgbm8gaWRlYSBpZiB0aGUgZG9tYWluIGlzIGEgUFYgb3Ig
SFZNIGd1ZXN0LCBhbmQgb25seSBzZWVzIHRoZSAKbmV0d29yayB0eXBlLCB3aGljaCBpcyBzZXQg
dG8gSU9FTVUgYnkgZGVmYXVsdC4KClRoaXMgaXMgdGhlIG1haW4gcHJvYmxlbSwgSSB0aGluayBp
dCBzaG91bGQgYmUgb2sgdG8gbGVhdmUgdGhlIGRlZmF1bHQgCnR5cGUgYXMgSU9FTVUgaW4gbGli
eGxfX2RldmljZV9uaWNfc2V0ZGVmYXVsdCBhbmQgc2V0IHRoZSB0eXBlIG1hbnVhbGx5IAp0byBW
SUYgZm9yIFBWIGd1ZXN0cyBpbiAKbGlieGxfY3JlYXRlLmM6bGlieGxfX2RvbWFpbl9idWlsZF9p
bmZvX3NldGRlZmF1bHQsIGRvZXMgdGhpcyBzb3VuZCBvaz8KCj4gV2hlcmUgKiA9PSBjdXJyZW50
IGxpYih4bCkgZGVmYXVsdCBhbmQmICA9PSBwcm9wb3NlZCBkZWZhdWx0IGFmdGVyIHRoaXMgY2hh
bmdlLgo+IGFuZDoKPiAgICAgICAgICB0eXBlPWlvZW11ID0+CUxJQlhMX05JQ19UWVBFX0lPRU1V
IHRvIGJlIHJlbmFtZWQgTElCWExfTklDX1RZUEVfVklGX0lPRU1VLgo+ICAgICAgICAgIHR5cGU9
dmlmID0+CUxJQlhMX05JVl9UWVBFX1ZJRiwgbm8gcmVuYW1pbmcgcHJvcG9zZWQuCj4KPiBCdXQg
aWYgbXkgdGFibGUgaXMgY29ycmVjdCB0aGVuIExJQlhMX05JQ19UWVBFX1ZJRl9JT0VNVSBpcyB0
aGUgcmlnaHQKPiBkZWZhdWx0IGFuZCBzaG91bGRuJ3QgYmUgY2hhbmdlZC4gUm9nZXIgY2FuIHlv
dSBlaXRoZXIgY29uZmlybSBvcgo+IGNvcnJlY3QgbXkgdGFibGUuCj4KPiBJYW4uCj4KCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkB0l-0000VL-LG; Thu, 28 Jun 2012 09:27: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 1SkB0j-0000VF-RM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:27:38 +0000
Received: from [85.158.143.35:9931] by server-2.bemta-4.messagelabs.com id
	6B/6E-17938-9832CEF4; Thu, 28 Jun 2012 09:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340875620!15373721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4069 invoked from network); 28 Jun 2012 09:27:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:27:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13263271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:27:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:27:00 +0100
Message-ID: <1340875618.10942.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 10:26:58 +0100
In-Reply-To: <4FEC2248.4080005@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

T24gVGh1LCAyMDEyLTA2LTI4IGF0IDEwOjIyICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gVHVlLCAyMDEyLTA2LTI2IGF0IDE3OjU4ICsw
MTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZToKPiA+PiBPbiBUdWUsIEp1biAyNiwgMjAxMiBh
dCAwNToyMDozNVBNICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4+IElhbiBKYWNr
c29uIHdyb3RlOgo+ID4+Pj4gUm9nZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltQQVRDSCB2NiAxMC8x
M10gbGlieGw6IHNldCBuaWMgdHlwZSB0byBWSUYgYnkgZGVmYXVsdCIpOgo+ID4+Pj4+IFNldCB0
aGUgZGVmYXVsdCB2YWx1ZSBmb3IgbmljIGludGVyZmFjZXMgdG8gVklGLCBzaW5jZSBpdCB1c2Vk
IHRvIGJlCj4gPj4+Pj4gSU9FTVUsIGV2ZW4gZm9yIFBWIGd1ZXN0cy4KPiA+Pj4+IElmIHlvdXIg
cmVuYW1pbmcgb2YgSU9FTVUgdG8gVklGX0lPRU1VIGlzIGNvcnJlY3QsIGRvZXMgdGhpcyBub3Qg
c3RvcAo+ID4+Pj4gSFZNIGd1ZXN0cyBnZXR0aW5nIGVtdWxhdGVkIG5ldHdvcmsgaW50ZXJmYWNl
cyBieSBkZWZhdWx0ID8KPiA+Pj4gWWVzLCBpZiB5b3Ugd2FudCBlbXVsYXRlZCBpbnRlcmZhY2Vz
IHdpdGggSFZNIGd1ZXN0cyB5b3Ugc2hvdWxkIHVzZQo+ID4+PiAndHlwZT1pb2VtdScsIHRoYXQn
cyBob3cgaXQgaGFzIGFsd2F5cyBiZWVuIHJpZ2h0Pwo+ID4+Pgo+ID4+IFdpdGggWGVuIDQuMSB5
b3UgZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9aW9lbXUiLiBFbXVsYXRlZCBpbnRlcmZhY2VzIHNl
ZW0gdG8gd29yayBPSyB3aXRob3V0ICJ0eXBlPWlvZW11Ii4KPiA+PiAoYXQgbGVhc3Qgd2l0aCB4
bS94ZW5kKS4gQW5kIGlmIHlvdSBhY3R1YWxseSBkbyBhZGQgInR5cGU9aW9lbXUiIGl0IHdpbGwg
YnJlYWsgUFZIVk0gZm9yIExpbnV4IGd1ZXN0cy4uCj4gPj4KPiA+PiBRdW90ZSBmcm9tOiBodHRw
Oi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuTGludXhQVm9uSFZNZHJpdmVycwo+ID4+Cj4gPj4gIk5P
VEUhIElmIHlvdSBoYXZlICJ0eXBlPWlvZW11IiBzcGVjaWZpZWQgZm9yIHRoZSAidmlmIi1saW5l
LCBQVkhWTQo+ID4+IGRyaXZlcnMgV0lMTCBOT1Qgd29yayEgRG9uJ3Qgc3BlY2lmeSAidHlwZSIg
cGFyYW1ldGVyIGZvciB0aGUgdmlmLgo+ID4+ICh3aXRoIHR5cGU9aW9lbXUgdGhlIHB2aHZtIG5p
YyBpbiB0aGUgVk0gd2lsbCBoYXZlIG1hYyBhZGRyZXNzIGZ1bGwgb2YKPiA+PiB6ZXJvZXMgLSBh
bmQgdGh1cyB3b24ndCB3b3JrISkuICIKPiA+Cj4gPiBtYWM9MDA6MDA6MDA6MDA6MDAgaXMgY2Vy
dGFpbmx5IGEgYnVnLCBpZiAobGliKXhsIGJlaGF2ZXMgdGhpcyB3YXkgdG9vCj4gPiB0aGVuIHdl
IHNob3VsZCBmaXggaXQuCj4gPgo+ID4gQnV0IHN1cmVseSB0eXBlPWlvZW11IGlzIHN1cHBvc2Vk
IHRvIG1lYW4gIm9ubHkgZW11bGF0ZWQiPyBJbiB3aGljaCBjYXNlCj4gPiB0aGUgYWN0dWFsIHhl
bmQgYnVnIGlzIHRoYXQgaXQgY3JlYXRlZCBhIFBWIFZJRiBhdCBhbGwuCj4gCj4gQ3VycmVudGx5
IHRoZXJlJ3Mgbm8gbmV0d29yayB0eXBlIHRoYXQgbWVhbnMgImVtdWxhdGVkIG9ubHkiLCB3ZSBo
YXZlIAo+IFZJRiBhbmQgVklGX0lPRU1VLgoKQWgsIG9rLCB5ZXMgSSdtIGNvbmZ1c2VkLgoKPiA+
IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhlcmU/IEkgdGhpbmsgdGhleSBhcmUsIHdpdGggdGhlaXIg
KGxpYil4bAo+ID4gYmVoYXZpb3VyOgo+ID4KPiA+IAkJUFYJCQkJSFZNCj4gPiB0eXBlPWlvZW11
CW1lYW5pbmdsZXNzIC8gYW4gZXJyb3IJCWVtdWxhdGVkIGRldmljZSArIHBhcmF2aXJ0IFZJRioK
PiA+IHR5cGU9dmlmCXBhcmF2aXJ0IFZJRiBkZXZpY2UqJgkJcGFyYXZpcnQgVklGIGRldmljZSBv
bmx5Jgo+IAo+IFlvdSBhcmUgbWlzc2luZyBhIHJvdywgdGhlIGRlZmF1bHQgb25lIHdoZW4gdXNl
ciBkb2Vzbid0IHNwZWNpZnkgCj4gYW55dGhpbmcsCgpUaGF0IHdhcyBzdXBwb3NlZCB0byBiZSBp
bmRpY2F0ZWQgYnkgdGhlICogKG5vdykgYW5kICYgKGFmdGVyIHlvdXIKcGF0Y2gpIHN5bWJvbHMg
YWJvdmUuCgo+ICB0aGlzIGN1cnJlbnRseSBpczoKPiAKPiAJUFYJCQkJSFZNCj4gZGVmYXVsdAlu
aWMgdHlwZSBpcyBzZXQgdG8gSUVPTVUJbmljIHR5cGUgaXMgc2V0IHRvIElPRU1VCj4gCj4gSW4g
dGhlIHBhc3QgdGhpcyB3YXMgbm90IGEgcHJvYmxlbSwgc2luY2Ugd2hlbiB0aGUgZ3Vlc3QgaXMg
UFYsIHdlIAo+IGRpZG4ndCBsYXVuY2ggUWVtdSwgYW5kIHRodXMgdGhlIHRhcCBkZXZpY2Ugd2Fz
IG5ldmVyIGNyZWF0ZWQgYW5kIHRoZSAKPiBob3RwbHVnIHNjcmlwdHMgd2VyZSBub3QgbGF1bmNo
ZWQuIE5vdyB0aGF0IHdlIGxhdW5jaCBob3RwbHVnIHNjcmlwdHMgCj4gZnJvbSBsaWJ4bCB0aGlz
IGlzIGEgcHJvYmxlbSwgYmVjYXVzZSB3aGVuIHdlIGNhbGwgbGlieGxfZGV2aWNlX25pY19hZGQs
IAo+IGxpYnhsIGhhcyBubyBpZGVhIGlmIHRoZSBkb21haW4gaXMgYSBQViBvciBIVk0gZ3Vlc3Qs
IGFuZCBvbmx5IHNlZXMgdGhlIAo+IG5ldHdvcmsgdHlwZSwgd2hpY2ggaXMgc2V0IHRvIElPRU1V
IGJ5IGRlZmF1bHQuCgpJdCBoYXMgYSBkb21pZCBzbyBpdCBjYW4gYXNrIGFuZC9vciBwcm9wYWdh
dGUgaXQgZG93biB0byBzZXRkZWZhdWx0cy4KCj4gVGhpcyBpcyB0aGUgbWFpbiBwcm9ibGVtLCBJ
IHRoaW5rIGl0IHNob3VsZCBiZSBvayB0byBsZWF2ZSB0aGUgZGVmYXVsdCAKPiB0eXBlIGFzIElP
RU1VIGluIGxpYnhsX19kZXZpY2VfbmljX3NldGRlZmF1bHQgYW5kIHNldCB0aGUgdHlwZSBtYW51
YWxseSAKPiB0byBWSUYgZm9yIFBWIGd1ZXN0cyBpbiAKPiBsaWJ4bF9jcmVhdGUuYzpsaWJ4bF9f
ZG9tYWluX2J1aWxkX2luZm9fc2V0ZGVmYXVsdCwgZG9lcyB0aGlzIHNvdW5kIG9rPwoKRG9lcyBi
dWlsZGluZm8gc2V0ZGVmYXVsdCBoYXZlIHRoZSBuZWNlc3NhcnkgcG9pbnRlciB0byBnZXQgYXQg
dGhlIHZpZnM/CkkgZG9uJ3QgdGhpbmsgaXQgZG9lcy4KCj4gCj4gPiBXaGVyZSAqID09IGN1cnJl
bnQgbGliKHhsKSBkZWZhdWx0IGFuZCYgID09IHByb3Bvc2VkIGRlZmF1bHQgYWZ0ZXIgdGhpcyBj
aGFuZ2UuCj4gPiBhbmQ6Cj4gPiAgICAgICAgICB0eXBlPWlvZW11ID0+CUxJQlhMX05JQ19UWVBF
X0lPRU1VIHRvIGJlIHJlbmFtZWQgTElCWExfTklDX1RZUEVfVklGX0lPRU1VLgo+ID4gICAgICAg
ICAgdHlwZT12aWYgPT4JTElCWExfTklWX1RZUEVfVklGLCBubyByZW5hbWluZyBwcm9wb3NlZC4K
PiA+Cj4gPiBCdXQgaWYgbXkgdGFibGUgaXMgY29ycmVjdCB0aGVuIExJQlhMX05JQ19UWVBFX1ZJ
Rl9JT0VNVSBpcyB0aGUgcmlnaHQKPiA+IGRlZmF1bHQgYW5kIHNob3VsZG4ndCBiZSBjaGFuZ2Vk
LiBSb2dlciBjYW4geW91IGVpdGhlciBjb25maXJtIG9yCj4gPiBjb3JyZWN0IG15IHRhYmxlLgo+
ID4KPiA+IElhbi4KPiA+Cj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkB0l-0000VL-LG; Thu, 28 Jun 2012 09:27: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 1SkB0j-0000VF-RM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:27:38 +0000
Received: from [85.158.143.35:9931] by server-2.bemta-4.messagelabs.com id
	6B/6E-17938-9832CEF4; Thu, 28 Jun 2012 09:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340875620!15373721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4069 invoked from network); 28 Jun 2012 09:27:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:27:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13263271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:27:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:27:00 +0100
Message-ID: <1340875618.10942.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 10:26:58 +0100
In-Reply-To: <4FEC2248.4080005@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

T24gVGh1LCAyMDEyLTA2LTI4IGF0IDEwOjIyICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gVHVlLCAyMDEyLTA2LTI2IGF0IDE3OjU4ICsw
MTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZToKPiA+PiBPbiBUdWUsIEp1biAyNiwgMjAxMiBh
dCAwNToyMDozNVBNICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4+IElhbiBKYWNr
c29uIHdyb3RlOgo+ID4+Pj4gUm9nZXIgUGF1IE1vbm5lIHdyaXRlcyAoIltQQVRDSCB2NiAxMC8x
M10gbGlieGw6IHNldCBuaWMgdHlwZSB0byBWSUYgYnkgZGVmYXVsdCIpOgo+ID4+Pj4+IFNldCB0
aGUgZGVmYXVsdCB2YWx1ZSBmb3IgbmljIGludGVyZmFjZXMgdG8gVklGLCBzaW5jZSBpdCB1c2Vk
IHRvIGJlCj4gPj4+Pj4gSU9FTVUsIGV2ZW4gZm9yIFBWIGd1ZXN0cy4KPiA+Pj4+IElmIHlvdXIg
cmVuYW1pbmcgb2YgSU9FTVUgdG8gVklGX0lPRU1VIGlzIGNvcnJlY3QsIGRvZXMgdGhpcyBub3Qg
c3RvcAo+ID4+Pj4gSFZNIGd1ZXN0cyBnZXR0aW5nIGVtdWxhdGVkIG5ldHdvcmsgaW50ZXJmYWNl
cyBieSBkZWZhdWx0ID8KPiA+Pj4gWWVzLCBpZiB5b3Ugd2FudCBlbXVsYXRlZCBpbnRlcmZhY2Vz
IHdpdGggSFZNIGd1ZXN0cyB5b3Ugc2hvdWxkIHVzZQo+ID4+PiAndHlwZT1pb2VtdScsIHRoYXQn
cyBob3cgaXQgaGFzIGFsd2F5cyBiZWVuIHJpZ2h0Pwo+ID4+Pgo+ID4+IFdpdGggWGVuIDQuMSB5
b3UgZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9aW9lbXUiLiBFbXVsYXRlZCBpbnRlcmZhY2VzIHNl
ZW0gdG8gd29yayBPSyB3aXRob3V0ICJ0eXBlPWlvZW11Ii4KPiA+PiAoYXQgbGVhc3Qgd2l0aCB4
bS94ZW5kKS4gQW5kIGlmIHlvdSBhY3R1YWxseSBkbyBhZGQgInR5cGU9aW9lbXUiIGl0IHdpbGwg
YnJlYWsgUFZIVk0gZm9yIExpbnV4IGd1ZXN0cy4uCj4gPj4KPiA+PiBRdW90ZSBmcm9tOiBodHRw
Oi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuTGludXhQVm9uSFZNZHJpdmVycwo+ID4+Cj4gPj4gIk5P
VEUhIElmIHlvdSBoYXZlICJ0eXBlPWlvZW11IiBzcGVjaWZpZWQgZm9yIHRoZSAidmlmIi1saW5l
LCBQVkhWTQo+ID4+IGRyaXZlcnMgV0lMTCBOT1Qgd29yayEgRG9uJ3Qgc3BlY2lmeSAidHlwZSIg
cGFyYW1ldGVyIGZvciB0aGUgdmlmLgo+ID4+ICh3aXRoIHR5cGU9aW9lbXUgdGhlIHB2aHZtIG5p
YyBpbiB0aGUgVk0gd2lsbCBoYXZlIG1hYyBhZGRyZXNzIGZ1bGwgb2YKPiA+PiB6ZXJvZXMgLSBh
bmQgdGh1cyB3b24ndCB3b3JrISkuICIKPiA+Cj4gPiBtYWM9MDA6MDA6MDA6MDA6MDAgaXMgY2Vy
dGFpbmx5IGEgYnVnLCBpZiAobGliKXhsIGJlaGF2ZXMgdGhpcyB3YXkgdG9vCj4gPiB0aGVuIHdl
IHNob3VsZCBmaXggaXQuCj4gPgo+ID4gQnV0IHN1cmVseSB0eXBlPWlvZW11IGlzIHN1cHBvc2Vk
IHRvIG1lYW4gIm9ubHkgZW11bGF0ZWQiPyBJbiB3aGljaCBjYXNlCj4gPiB0aGUgYWN0dWFsIHhl
bmQgYnVnIGlzIHRoYXQgaXQgY3JlYXRlZCBhIFBWIFZJRiBhdCBhbGwuCj4gCj4gQ3VycmVudGx5
IHRoZXJlJ3Mgbm8gbmV0d29yayB0eXBlIHRoYXQgbWVhbnMgImVtdWxhdGVkIG9ubHkiLCB3ZSBo
YXZlIAo+IFZJRiBhbmQgVklGX0lPRU1VLgoKQWgsIG9rLCB5ZXMgSSdtIGNvbmZ1c2VkLgoKPiA+
IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhlcmU/IEkgdGhpbmsgdGhleSBhcmUsIHdpdGggdGhlaXIg
KGxpYil4bAo+ID4gYmVoYXZpb3VyOgo+ID4KPiA+IAkJUFYJCQkJSFZNCj4gPiB0eXBlPWlvZW11
CW1lYW5pbmdsZXNzIC8gYW4gZXJyb3IJCWVtdWxhdGVkIGRldmljZSArIHBhcmF2aXJ0IFZJRioK
PiA+IHR5cGU9dmlmCXBhcmF2aXJ0IFZJRiBkZXZpY2UqJgkJcGFyYXZpcnQgVklGIGRldmljZSBv
bmx5Jgo+IAo+IFlvdSBhcmUgbWlzc2luZyBhIHJvdywgdGhlIGRlZmF1bHQgb25lIHdoZW4gdXNl
ciBkb2Vzbid0IHNwZWNpZnkgCj4gYW55dGhpbmcsCgpUaGF0IHdhcyBzdXBwb3NlZCB0byBiZSBp
bmRpY2F0ZWQgYnkgdGhlICogKG5vdykgYW5kICYgKGFmdGVyIHlvdXIKcGF0Y2gpIHN5bWJvbHMg
YWJvdmUuCgo+ICB0aGlzIGN1cnJlbnRseSBpczoKPiAKPiAJUFYJCQkJSFZNCj4gZGVmYXVsdAlu
aWMgdHlwZSBpcyBzZXQgdG8gSUVPTVUJbmljIHR5cGUgaXMgc2V0IHRvIElPRU1VCj4gCj4gSW4g
dGhlIHBhc3QgdGhpcyB3YXMgbm90IGEgcHJvYmxlbSwgc2luY2Ugd2hlbiB0aGUgZ3Vlc3QgaXMg
UFYsIHdlIAo+IGRpZG4ndCBsYXVuY2ggUWVtdSwgYW5kIHRodXMgdGhlIHRhcCBkZXZpY2Ugd2Fz
IG5ldmVyIGNyZWF0ZWQgYW5kIHRoZSAKPiBob3RwbHVnIHNjcmlwdHMgd2VyZSBub3QgbGF1bmNo
ZWQuIE5vdyB0aGF0IHdlIGxhdW5jaCBob3RwbHVnIHNjcmlwdHMgCj4gZnJvbSBsaWJ4bCB0aGlz
IGlzIGEgcHJvYmxlbSwgYmVjYXVzZSB3aGVuIHdlIGNhbGwgbGlieGxfZGV2aWNlX25pY19hZGQs
IAo+IGxpYnhsIGhhcyBubyBpZGVhIGlmIHRoZSBkb21haW4gaXMgYSBQViBvciBIVk0gZ3Vlc3Qs
IGFuZCBvbmx5IHNlZXMgdGhlIAo+IG5ldHdvcmsgdHlwZSwgd2hpY2ggaXMgc2V0IHRvIElPRU1V
IGJ5IGRlZmF1bHQuCgpJdCBoYXMgYSBkb21pZCBzbyBpdCBjYW4gYXNrIGFuZC9vciBwcm9wYWdh
dGUgaXQgZG93biB0byBzZXRkZWZhdWx0cy4KCj4gVGhpcyBpcyB0aGUgbWFpbiBwcm9ibGVtLCBJ
IHRoaW5rIGl0IHNob3VsZCBiZSBvayB0byBsZWF2ZSB0aGUgZGVmYXVsdCAKPiB0eXBlIGFzIElP
RU1VIGluIGxpYnhsX19kZXZpY2VfbmljX3NldGRlZmF1bHQgYW5kIHNldCB0aGUgdHlwZSBtYW51
YWxseSAKPiB0byBWSUYgZm9yIFBWIGd1ZXN0cyBpbiAKPiBsaWJ4bF9jcmVhdGUuYzpsaWJ4bF9f
ZG9tYWluX2J1aWxkX2luZm9fc2V0ZGVmYXVsdCwgZG9lcyB0aGlzIHNvdW5kIG9rPwoKRG9lcyBi
dWlsZGluZm8gc2V0ZGVmYXVsdCBoYXZlIHRoZSBuZWNlc3NhcnkgcG9pbnRlciB0byBnZXQgYXQg
dGhlIHZpZnM/CkkgZG9uJ3QgdGhpbmsgaXQgZG9lcy4KCj4gCj4gPiBXaGVyZSAqID09IGN1cnJl
bnQgbGliKHhsKSBkZWZhdWx0IGFuZCYgID09IHByb3Bvc2VkIGRlZmF1bHQgYWZ0ZXIgdGhpcyBj
aGFuZ2UuCj4gPiBhbmQ6Cj4gPiAgICAgICAgICB0eXBlPWlvZW11ID0+CUxJQlhMX05JQ19UWVBF
X0lPRU1VIHRvIGJlIHJlbmFtZWQgTElCWExfTklDX1RZUEVfVklGX0lPRU1VLgo+ID4gICAgICAg
ICAgdHlwZT12aWYgPT4JTElCWExfTklWX1RZUEVfVklGLCBubyByZW5hbWluZyBwcm9wb3NlZC4K
PiA+Cj4gPiBCdXQgaWYgbXkgdGFibGUgaXMgY29ycmVjdCB0aGVuIExJQlhMX05JQ19UWVBFX1ZJ
Rl9JT0VNVSBpcyB0aGUgcmlnaHQKPiA+IGRlZmF1bHQgYW5kIHNob3VsZG4ndCBiZSBjaGFuZ2Vk
LiBSb2dlciBjYW4geW91IGVpdGhlciBjb25maXJtIG9yCj4gPiBjb3JyZWN0IG15IHRhYmxlLgo+
ID4KPiA+IElhbi4KPiA+Cj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkB1b-0000Yf-38; Thu, 28 Jun 2012 09:28:31 +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 1SkB1Z-0000YX-Iv
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:28:29 +0000
Received: from [85.158.139.83:40877] by server-7.bemta-5.messagelabs.com id
	1D/4F-28276-CB32CEF4; Thu, 28 Jun 2012 09:28:28 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340875707!28655564!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8674 invoked from network); 28 Jun 2012 09:28:27 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:28:27 -0000
Received: by eaak12 with SMTP id k12so785276eaa.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 02:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jjgytFGqGCiwSiyWcuT2Z5+6VAZHdof1IE54haaG60o=;
	b=OMiDq1t9O05hLvTK3+q3w+SvKct5dT6d5Xhc0KO3eKivO8r4vXFDI8I+f2EI9Er0ZG
	iKcPXIk3n7iTTGhu41GpAaobMa6kA9Sqfl0lQFi1WmZXlmrgpkqqT1Q+JwqnD6OEvtai
	I81uLWJFeCZtcAIVl/DS9OV24nE6afEKo7JWNj9v4wNxSZgouIGH5R3OijB1WRAhGcN5
	YQd55qv47xqepJ/DCbjcx5OGoRVOZex7Q5H8MR/j4s5L1RSV79m4w04X6UV5kPKBJ8oP
	g0sl1Z8tIji4RNarWlGS5zvVEP9y9mFvLK2lk9jmuggHrcTLclhf47HVAr3UJ3rQTHf1
	KRBA==
Received: by 10.14.100.197 with SMTP id z45mr282217eef.54.1340875707142;
	Thu, 28 Jun 2012 02:28:27 -0700 (PDT)
Received: from [172.16.26.11] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id a16sm167298330eeg.0.2012.06.28.02.28.24
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 02:28:25 -0700 (PDT)
Message-ID: <4FEC23B7.7020802@xen.org>
Date: Thu, 28 Jun 2012 10:28:23 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
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

>>/  1. Purpose of the process/
>>
>>/  The first point is that we think the security vulnerability process/
>>/  document should have an explanation of what its goals are.  This would/
>>/  have greatly assisted us when making some of the more difficult/
>>/  decisions./
>
> The security vulnerability process document should most definitely
> encapsulate both explicit guidance and broad tenets that can be used
> to make tough calls. I think that these should be explicitly called
> out in front matter as an evolutionary part of the process. Tenets
> should always be open to being refined or redefined as Xen.org
> projects grow and usage shifts.

I wanted to dive a little bit into the purpose of the process as the
discussion will otherwise get stuck on detail. Also into the actors
in a security vulnerability and their interest.

1.1: The Xen.org Security team, whose task is to administer the process
and act as referee if needed: the process should provide clarity and
ensure that the team can be seen as referee. The process needs to be
clear enough to avoid a chance that members of the team are accused of
being partial.

1.2: Discoverer of the vulnerability: The process must provide an
incentive for the discover to report the issue to the project. If we
get the process wrong, the consequence will be that vulnerabilities
will not be reported to us. That would be detrimental to all
stake-holders as it will increase days-of-risk for everybody else.
E.g. if the embargo period is too long. Not sure what other factors
motivate a discoverer.

1.3: Developers within the project, who will be task to find a fix
as quickly as possible.

1.4: 3rd parties that may need to be contacted in order to develop a
fix to understand the issue and advise the security team (in the case
of CVE-2012-0217 hardware vendors).

1.5: Developers of downstream projects/distros consuming Xen and
distributing it (FOSS or commercial), who will apply the fix to
their project/distro.

1.6: Other direct consumers of Xen (e.g. service providers). Their
main goal of the process would be to reduce days-of-risk for
themselves. The issue being that deploying a fix can take a long time.
Another issue is that providing a fix before somebody else is a
competitive advantage.

1.7: Indirect consumers of Xen. With all the same motivations than
direct consumers.

A couple of observations:
1) The further you get down the list, the more people are involved,
the greater the risk that information will leak.
2) Groups 1.1 - 1.4 necessarily need to be involved to create a fix,
as otherwise there won't be a fix for the other groups.
3) Groups 1.6 - 1.7 are directly impacted by days-of-risk
4) Groups 1.1, 1.3 & 1.5 are impacted insofar that the reputation
of their organisation may be damaged if the situation is not handled
well.
  
Of course the ultimate goal of the process should be to minimize
days-of-risk for everyone. To do this, the process has to balance the
following factors to reduce days-of-risk

A) Provide incentive for vulnerabilities to be reported to Xen.org
security team in the first place
B) Time it takes to develop a fix
C) Time it takes downstream projects/distros to apply it
D) Time it takes to deploy fixes for consumers (1.6 & 1.7)
E) Reduce the possibility of a leak (keep pre-disclosure list small)
F) Avoid the perception that members of the pre-disclosure list have
an unfair advantage
  
Looking at the existing pre-disclosure list shows that it contains
parties from all groups. This opens Xen.org up to criticism that some
members of the pre-disclosure have an uncertain advantage, which has
already been highlighted earlier in this discussion.

To be honest, I don't really see a way to satisfy all needs:
- Restrict membership of disclosure lists to stake-holders 1.1, 1.2,
   1.3 and 1.5 with members of 1.4 drawn in as needed and full public
   disclosure afterwards as to who was consulted.
- Of course it may be desirable to get advice from members of groups
   1.6 and 1.7. Or is it? If it is, a different approach may be to have
   a merit rather than size based selection criteria for members of 1.6
   and 1.7 (e.g. something along the lines of "contributions" to the
   community, but that would need to be measurable - or even some sort
   of elections). But it is hard to see how this would work in practice.
   Of course such an would have the advantage that a member of that group
   that used mbership to gain an unfair advantage over others could be
   removed from the pre-disclosure list.
- Another possible approach may be a two-stage pre-disclosure
   - Stage 1: Groups 1.1, 1.2, 1.3 and 1.5 with 1.4 as needed
   - Stage 2: Groups 1.6 and 1.7 (with a relatively weak membership
     criterion such as being a service provider - but then how does
     this differ from being public and who would administer?)
- Another option may be to delegate more difficult issues on
   principle to an independent organisation such as OCERT.

Best Regards
Lars
P.S.: I just wanted to make clear that these are my personal views and reflect
in no way any position of Xen.org or my employer.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkB1b-0000Yf-38; Thu, 28 Jun 2012 09:28:31 +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 1SkB1Z-0000YX-Iv
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:28:29 +0000
Received: from [85.158.139.83:40877] by server-7.bemta-5.messagelabs.com id
	1D/4F-28276-CB32CEF4; Thu, 28 Jun 2012 09:28:28 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340875707!28655564!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8674 invoked from network); 28 Jun 2012 09:28:27 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:28:27 -0000
Received: by eaak12 with SMTP id k12so785276eaa.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 02:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=jjgytFGqGCiwSiyWcuT2Z5+6VAZHdof1IE54haaG60o=;
	b=OMiDq1t9O05hLvTK3+q3w+SvKct5dT6d5Xhc0KO3eKivO8r4vXFDI8I+f2EI9Er0ZG
	iKcPXIk3n7iTTGhu41GpAaobMa6kA9Sqfl0lQFi1WmZXlmrgpkqqT1Q+JwqnD6OEvtai
	I81uLWJFeCZtcAIVl/DS9OV24nE6afEKo7JWNj9v4wNxSZgouIGH5R3OijB1WRAhGcN5
	YQd55qv47xqepJ/DCbjcx5OGoRVOZex7Q5H8MR/j4s5L1RSV79m4w04X6UV5kPKBJ8oP
	g0sl1Z8tIji4RNarWlGS5zvVEP9y9mFvLK2lk9jmuggHrcTLclhf47HVAr3UJ3rQTHf1
	KRBA==
Received: by 10.14.100.197 with SMTP id z45mr282217eef.54.1340875707142;
	Thu, 28 Jun 2012 02:28:27 -0700 (PDT)
Received: from [172.16.26.11] (b0fb70a7.bb.sky.com. [176.251.112.167])
	by mx.google.com with ESMTPS id a16sm167298330eeg.0.2012.06.28.02.28.24
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 02:28:25 -0700 (PDT)
Message-ID: <4FEC23B7.7020802@xen.org>
Date: Thu, 28 Jun 2012 10:28:23 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
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

>>/  1. Purpose of the process/
>>
>>/  The first point is that we think the security vulnerability process/
>>/  document should have an explanation of what its goals are.  This would/
>>/  have greatly assisted us when making some of the more difficult/
>>/  decisions./
>
> The security vulnerability process document should most definitely
> encapsulate both explicit guidance and broad tenets that can be used
> to make tough calls. I think that these should be explicitly called
> out in front matter as an evolutionary part of the process. Tenets
> should always be open to being refined or redefined as Xen.org
> projects grow and usage shifts.

I wanted to dive a little bit into the purpose of the process as the
discussion will otherwise get stuck on detail. Also into the actors
in a security vulnerability and their interest.

1.1: The Xen.org Security team, whose task is to administer the process
and act as referee if needed: the process should provide clarity and
ensure that the team can be seen as referee. The process needs to be
clear enough to avoid a chance that members of the team are accused of
being partial.

1.2: Discoverer of the vulnerability: The process must provide an
incentive for the discover to report the issue to the project. If we
get the process wrong, the consequence will be that vulnerabilities
will not be reported to us. That would be detrimental to all
stake-holders as it will increase days-of-risk for everybody else.
E.g. if the embargo period is too long. Not sure what other factors
motivate a discoverer.

1.3: Developers within the project, who will be task to find a fix
as quickly as possible.

1.4: 3rd parties that may need to be contacted in order to develop a
fix to understand the issue and advise the security team (in the case
of CVE-2012-0217 hardware vendors).

1.5: Developers of downstream projects/distros consuming Xen and
distributing it (FOSS or commercial), who will apply the fix to
their project/distro.

1.6: Other direct consumers of Xen (e.g. service providers). Their
main goal of the process would be to reduce days-of-risk for
themselves. The issue being that deploying a fix can take a long time.
Another issue is that providing a fix before somebody else is a
competitive advantage.

1.7: Indirect consumers of Xen. With all the same motivations than
direct consumers.

A couple of observations:
1) The further you get down the list, the more people are involved,
the greater the risk that information will leak.
2) Groups 1.1 - 1.4 necessarily need to be involved to create a fix,
as otherwise there won't be a fix for the other groups.
3) Groups 1.6 - 1.7 are directly impacted by days-of-risk
4) Groups 1.1, 1.3 & 1.5 are impacted insofar that the reputation
of their organisation may be damaged if the situation is not handled
well.
  
Of course the ultimate goal of the process should be to minimize
days-of-risk for everyone. To do this, the process has to balance the
following factors to reduce days-of-risk

A) Provide incentive for vulnerabilities to be reported to Xen.org
security team in the first place
B) Time it takes to develop a fix
C) Time it takes downstream projects/distros to apply it
D) Time it takes to deploy fixes for consumers (1.6 & 1.7)
E) Reduce the possibility of a leak (keep pre-disclosure list small)
F) Avoid the perception that members of the pre-disclosure list have
an unfair advantage
  
Looking at the existing pre-disclosure list shows that it contains
parties from all groups. This opens Xen.org up to criticism that some
members of the pre-disclosure have an uncertain advantage, which has
already been highlighted earlier in this discussion.

To be honest, I don't really see a way to satisfy all needs:
- Restrict membership of disclosure lists to stake-holders 1.1, 1.2,
   1.3 and 1.5 with members of 1.4 drawn in as needed and full public
   disclosure afterwards as to who was consulted.
- Of course it may be desirable to get advice from members of groups
   1.6 and 1.7. Or is it? If it is, a different approach may be to have
   a merit rather than size based selection criteria for members of 1.6
   and 1.7 (e.g. something along the lines of "contributions" to the
   community, but that would need to be measurable - or even some sort
   of elections). But it is hard to see how this would work in practice.
   Of course such an would have the advantage that a member of that group
   that used mbership to gain an unfair advantage over others could be
   removed from the pre-disclosure list.
- Another possible approach may be a two-stage pre-disclosure
   - Stage 1: Groups 1.1, 1.2, 1.3 and 1.5 with 1.4 as needed
   - Stage 2: Groups 1.6 and 1.7 (with a relatively weak membership
     criterion such as being a service provider - but then how does
     this differ from being public and who would administer?)
- Another option may be to delegate more difficult issues on
   principle to an independent organisation such as OCERT.

Best Regards
Lars
P.S.: I just wanted to make clear that these are my personal views and reflect
in no way any position of Xen.org or my employer.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:29:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkB26-0000cl-Mq; Thu, 28 Jun 2012 09:29:02 +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 1SkB25-0000cP-2r
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:29:01 +0000
Received: from [85.158.143.99:37440] by server-1.bemta-4.messagelabs.com id
	3B/D3-24392-BD32CEF4; Thu, 28 Jun 2012 09:28:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340875739!17944704!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16895 invoked from network); 28 Jun 2012 09:28:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:28:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13263333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:28:58 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:28:58 +0100
Message-ID: <4FEC23B1.8030904@citrix.com>
Date: Thu, 28 Jun 2012 10:28:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
In-Reply-To: <4FEC2248.4080005@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 v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
> In the past this was not a problem, since when the guest is PV, we
> didn't launch Qemu, and thus the tap device was never created and the
> hotplug scripts were not launched. Now that we launch hotplug scripts
> from libxl this is a problem, because when we call libxl_device_nic_add,
> libxl has no idea if the domain is a PV or HVM guest, and only sees the
> network type, which is set to IOEMU by default.
>
> This is the main problem, I think it should be ok to leave the default
> type as IOEMU in libxl__device_nic_setdefault and set the type manually
> to VIF for PV guests in
> libxl_create.c:libxl__domain_build_info_setdefault, does this sound ok?

My bad, libxl__domain_build_info_setdefault doesn't have access to
libxl_domain_config, I will search for another place...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:29:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkB26-0000cl-Mq; Thu, 28 Jun 2012 09:29:02 +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 1SkB25-0000cP-2r
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:29:01 +0000
Received: from [85.158.143.99:37440] by server-1.bemta-4.messagelabs.com id
	3B/D3-24392-BD32CEF4; Thu, 28 Jun 2012 09:28:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340875739!17944704!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16895 invoked from network); 28 Jun 2012 09:28:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:28:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208";a="13263333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:28:58 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:28:58 +0100
Message-ID: <4FEC23B1.8030904@citrix.com>
Date: Thu, 28 Jun 2012 10:28:17 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
In-Reply-To: <4FEC2248.4080005@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 v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne wrote:
> In the past this was not a problem, since when the guest is PV, we
> didn't launch Qemu, and thus the tap device was never created and the
> hotplug scripts were not launched. Now that we launch hotplug scripts
> from libxl this is a problem, because when we call libxl_device_nic_add,
> libxl has no idea if the domain is a PV or HVM guest, and only sees the
> network type, which is set to IOEMU by default.
>
> This is the main problem, I think it should be ok to leave the default
> type as IOEMU in libxl__device_nic_setdefault and set the type manually
> to VIF for PV guests in
> libxl_create.c:libxl__domain_build_info_setdefault, does this sound ok?

My bad, libxl__domain_build_info_setdefault doesn't have access to
libxl_domain_config, I will search for another place...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBD8-00013z-Rz; Thu, 28 Jun 2012 09:40:26 +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 1SkBD6-00013u-Qr
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:40:25 +0000
Received: from [85.158.143.35:2503] by server-1.bemta-4.messagelabs.com id
	BD/4C-24392-8862CEF4; Thu, 28 Jun 2012 09:40:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340876412!13836389!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyMTc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27240 invoked from network); 28 Jun 2012 09:40:13 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 09:40:13 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 02:40:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="159152952"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga001.jf.intel.com with ESMTP; 28 Jun 2012 02:40:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 02:40:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 17:40:09 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVQ2m1l9vq4iTRyWE8p2SJy8j95cPc0zw
Date: Thu, 28 Jun 2012 09:40:08 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
In-Reply-To: <4FEC3B4A020000780008C673@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.06.12 at 10:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>> The 2-bank approach also needs to be brought in line with the
>>> current host derived value in MCG_CAP, especially if the code to
>>> implement this new model doesn't make it into 4.2 (which would
>>> generally save a larger value).
>> 
>> Let me repeat in my word to avoid misunderstanding about your
>> concern: 
>> Your concern rooted from the history patch (c/s 24887, as attached)
>> which used to solve vMCE migration issue caused from bank number. I
>> guess the patch was not in xen4.1.x but would be in xen 4.2 release
>> recently (right? and when will xen 4.2 release?)
> 
> 4.2 is in feature freeze right now, preparing for the release.
> 
>> Per my understanding, you want us to make sure our new vMCE model
>> compatible w/ olde vMCE. For example if our patch in xen 4.3
>> release, you want to make sure a guest migrate from xen 4.2 to 4.3
>> would not broken. Is this your concern?
> 
> Yes. If we can't get the save/restore records adjusted in time
> for 4.2, compatibility with 4.2 would be a requirement. If we
> manage to get the necessary adjustments done in time, and if
> they're not too intrusive (i.e. would be acceptable at this late
> stage of the development cycle), then the concern could be
> dropped from an upstream perspective due to the lack of
> support in 4.1 (and hence no backward compatibility issues).
> BUT this isn't as simple from a product usage point of view: As
> the save/restore code currently in -unstable was coded up to
> address a problem observed by SLE11 SP2 users, we already
> backported those patches. So compatibility will be a requirement
> in any case.
> 
> Jan

A basic point of new vMCE is, it get rid of old vMCE, start setting up a new model from the very beginning. From coding point of view, backward compatibility issue would be dirty and troublesome.

The point is, old vMCE interface is host-based while new vMCE is pure s/w defined, hence troubles come from the interface heterogeneous (if need keep compatibility). The basic assumption of live migration from A to B is, A and B basically at same page, so it could be migrated by setting the smallest common feature/capability set (via cpuid, command line, etc.). However, old vMCE and new vMCE are quite different and cannot controlled effectively. For example, old vMCE has MCG_CTL but new vMCE doesn't, and new vMCE has CMCI support (and MCi_CTL2) but old vMCE doesn't. I even doubt the feasibility of keeping compatibility w/ old vMCE. An example is, it's hard to migrate between Intel cpu and AMD cpu.

So I would like to push new vMCE as quickly as possible. What's the timeline of vMCE developing that xen 4.2 could accept? I wonder if we could make major components of vMCE done before xen 4.2 timeline, and leave the surrounding features and the corner cases done 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 Thu Jun 28 09:40:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBD8-00013z-Rz; Thu, 28 Jun 2012 09:40:26 +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 1SkBD6-00013u-Qr
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:40:25 +0000
Received: from [85.158.143.35:2503] by server-1.bemta-4.messagelabs.com id
	BD/4C-24392-8862CEF4; Thu, 28 Jun 2012 09:40:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340876412!13836389!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkyMTc4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27240 invoked from network); 28 Jun 2012 09:40:13 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 09:40:13 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 28 Jun 2012 02:40:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="159152952"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga001.jf.intel.com with ESMTP; 28 Jun 2012 02:40:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 02:40:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 17:40:09 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVQ2m1l9vq4iTRyWE8p2SJy8j95cPc0zw
Date: Thu, 28 Jun 2012 09:40:08 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
In-Reply-To: <4FEC3B4A020000780008C673@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.06.12 at 10:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>> The 2-bank approach also needs to be brought in line with the
>>> current host derived value in MCG_CAP, especially if the code to
>>> implement this new model doesn't make it into 4.2 (which would
>>> generally save a larger value).
>> 
>> Let me repeat in my word to avoid misunderstanding about your
>> concern: 
>> Your concern rooted from the history patch (c/s 24887, as attached)
>> which used to solve vMCE migration issue caused from bank number. I
>> guess the patch was not in xen4.1.x but would be in xen 4.2 release
>> recently (right? and when will xen 4.2 release?)
> 
> 4.2 is in feature freeze right now, preparing for the release.
> 
>> Per my understanding, you want us to make sure our new vMCE model
>> compatible w/ olde vMCE. For example if our patch in xen 4.3
>> release, you want to make sure a guest migrate from xen 4.2 to 4.3
>> would not broken. Is this your concern?
> 
> Yes. If we can't get the save/restore records adjusted in time
> for 4.2, compatibility with 4.2 would be a requirement. If we
> manage to get the necessary adjustments done in time, and if
> they're not too intrusive (i.e. would be acceptable at this late
> stage of the development cycle), then the concern could be
> dropped from an upstream perspective due to the lack of
> support in 4.1 (and hence no backward compatibility issues).
> BUT this isn't as simple from a product usage point of view: As
> the save/restore code currently in -unstable was coded up to
> address a problem observed by SLE11 SP2 users, we already
> backported those patches. So compatibility will be a requirement
> in any case.
> 
> Jan

A basic point of new vMCE is, it get rid of old vMCE, start setting up a new model from the very beginning. From coding point of view, backward compatibility issue would be dirty and troublesome.

The point is, old vMCE interface is host-based while new vMCE is pure s/w defined, hence troubles come from the interface heterogeneous (if need keep compatibility). The basic assumption of live migration from A to B is, A and B basically at same page, so it could be migrated by setting the smallest common feature/capability set (via cpuid, command line, etc.). However, old vMCE and new vMCE are quite different and cannot controlled effectively. For example, old vMCE has MCG_CTL but new vMCE doesn't, and new vMCE has CMCI support (and MCi_CTL2) but old vMCE doesn't. I even doubt the feasibility of keeping compatibility w/ old vMCE. An example is, it's hard to migrate between Intel cpu and AMD cpu.

So I would like to push new vMCE as quickly as possible. What's the timeline of vMCE developing that xen 4.2 could accept? I wonder if we could make major components of vMCE done before xen 4.2 timeline, and leave the surrounding features and the corner cases done 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 Thu Jun 28 09:42:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBEt-00018d-BW; Thu, 28 Jun 2012 09:42:15 +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 1SkBEs-00018U-Is
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:42:14 +0000
Received: from [85.158.138.51:50453] by server-1.bemta-3.messagelabs.com id
	BF/77-14648-5F62CEF4; Thu, 28 Jun 2012 09:42:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340876529!21057096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32444 invoked from network); 28 Jun 2012 09:42:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:42:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13263787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:42:04 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:42:03 +0100
Message-ID: <4FEC26C2.6070901@citrix.com>
Date: Thu, 28 Jun 2012 10:41:22 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340875618.10942.14.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFRodSwgMjAxMi0wNi0yOCBhdCAxMDoyMiArMDEwMCwg
Um9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4+PiBPbiBUdWUs
IDIwMTItMDYtMjYgYXQgMTc6NTggKzAxMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgo+Pj4+
IE9uIFR1ZSwgSnVuIDI2LCAyMDEyIGF0IDA1OjIwOjM1UE0gKzAxMDAsIFJvZ2VyIFBhdSBNb25u
ZSB3cm90ZToKPj4+Pj4gSWFuIEphY2tzb24gd3JvdGU6Cj4+Pj4+PiBSb2dlciBQYXUgTW9ubmUg
d3JpdGVzICgiW1BBVENIIHY2IDEwLzEzXSBsaWJ4bDogc2V0IG5pYyB0eXBlIHRvIFZJRiBieSBk
ZWZhdWx0Iik6Cj4+Pj4+Pj4gU2V0IHRoZSBkZWZhdWx0IHZhbHVlIGZvciBuaWMgaW50ZXJmYWNl
cyB0byBWSUYsIHNpbmNlIGl0IHVzZWQgdG8gYmUKPj4+Pj4+PiBJT0VNVSwgZXZlbiBmb3IgUFYg
Z3Vlc3RzLgo+Pj4+Pj4gSWYgeW91ciByZW5hbWluZyBvZiBJT0VNVSB0byBWSUZfSU9FTVUgaXMg
Y29ycmVjdCwgZG9lcyB0aGlzIG5vdCBzdG9wCj4+Pj4+PiBIVk0gZ3Vlc3RzIGdldHRpbmcgZW11
bGF0ZWQgbmV0d29yayBpbnRlcmZhY2VzIGJ5IGRlZmF1bHQgPwo+Pj4+PiBZZXMsIGlmIHlvdSB3
YW50IGVtdWxhdGVkIGludGVyZmFjZXMgd2l0aCBIVk0gZ3Vlc3RzIHlvdSBzaG91bGQgdXNlCj4+
Pj4+ICd0eXBlPWlvZW11JywgdGhhdCdzIGhvdyBpdCBoYXMgYWx3YXlzIGJlZW4gcmlnaHQ/Cj4+
Pj4+Cj4+Pj4gV2l0aCBYZW4gNC4xIHlvdSBkb24ndCBoYXZlIHRvIHVzZSAidHlwZT1pb2VtdSIu
IEVtdWxhdGVkIGludGVyZmFjZXMgc2VlbSB0byB3b3JrIE9LIHdpdGhvdXQgInR5cGU9aW9lbXUi
Lgo+Pj4+IChhdCBsZWFzdCB3aXRoIHhtL3hlbmQpLiBBbmQgaWYgeW91IGFjdHVhbGx5IGRvIGFk
ZCAidHlwZT1pb2VtdSIgaXQgd2lsbCBicmVhayBQVkhWTSBmb3IgTGludXggZ3Vlc3RzLi4KPj4+
Pgo+Pj4+IFF1b3RlIGZyb206IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9YZW5MaW51eFBWb25I
Vk1kcml2ZXJzCj4+Pj4KPj4+PiAiTk9URSEgSWYgeW91IGhhdmUgInR5cGU9aW9lbXUiIHNwZWNp
ZmllZCBmb3IgdGhlICJ2aWYiLWxpbmUsIFBWSFZNCj4+Pj4gZHJpdmVycyBXSUxMIE5PVCB3b3Jr
ISBEb24ndCBzcGVjaWZ5ICJ0eXBlIiBwYXJhbWV0ZXIgZm9yIHRoZSB2aWYuCj4+Pj4gKHdpdGgg
dHlwZT1pb2VtdSB0aGUgcHZodm0gbmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3Mg
ZnVsbCBvZgo+Pj4+IHplcm9lcyAtIGFuZCB0aHVzIHdvbid0IHdvcmshKS4gIgo+Pj4gbWFjPTAw
OjAwOjAwOjAwOjAwIGlzIGNlcnRhaW5seSBhIGJ1ZywgaWYgKGxpYil4bCBiZWhhdmVzIHRoaXMg
d2F5IHRvbwo+Pj4gdGhlbiB3ZSBzaG91bGQgZml4IGl0Lgo+Pj4KPj4+IEJ1dCBzdXJlbHkgdHlw
ZT1pb2VtdSBpcyBzdXBwb3NlZCB0byBtZWFuICJvbmx5IGVtdWxhdGVkIj8gSW4gd2hpY2ggY2Fz
ZQo+Pj4gdGhlIGFjdHVhbCB4ZW5kIGJ1ZyBpcyB0aGF0IGl0IGNyZWF0ZWQgYSBQViBWSUYgYXQg
YWxsLgo+PiBDdXJyZW50bHkgdGhlcmUncyBubyBuZXR3b3JrIHR5cGUgdGhhdCBtZWFucyAiZW11
bGF0ZWQgb25seSIsIHdlIGhhdmUKPj4gVklGIGFuZCBWSUZfSU9FTVUuCj4KPiBBaCwgb2ssIHll
cyBJJ20gY29uZnVzZWQuCj4KPj4+IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhlcmU/IEkgdGhpbmsg
dGhleSBhcmUsIHdpdGggdGhlaXIgKGxpYil4bAo+Pj4gYmVoYXZpb3VyOgo+Pj4KPj4+IAkJUFYJ
CQkJSFZNCj4+PiB0eXBlPWlvZW11CW1lYW5pbmdsZXNzIC8gYW4gZXJyb3IJCWVtdWxhdGVkIGRl
dmljZSArIHBhcmF2aXJ0IFZJRioKPj4+IHR5cGU9dmlmCXBhcmF2aXJ0IFZJRiBkZXZpY2UqJgkJ
cGFyYXZpcnQgVklGIGRldmljZSBvbmx5Jgo+PiBZb3UgYXJlIG1pc3NpbmcgYSByb3csIHRoZSBk
ZWZhdWx0IG9uZSB3aGVuIHVzZXIgZG9lc24ndCBzcGVjaWZ5Cj4+IGFueXRoaW5nLAo+Cj4gVGhh
dCB3YXMgc3VwcG9zZWQgdG8gYmUgaW5kaWNhdGVkIGJ5IHRoZSAqIChub3cpIGFuZCYgIChhZnRl
ciB5b3VyCj4gcGF0Y2gpIHN5bWJvbHMgYWJvdmUuCj4KPj4gICB0aGlzIGN1cnJlbnRseSBpczoK
Pj4KPj4gCVBWCQkJCUhWTQo+PiBkZWZhdWx0CW5pYyB0eXBlIGlzIHNldCB0byBJRU9NVQluaWMg
dHlwZSBpcyBzZXQgdG8gSU9FTVUKPj4KPj4gSW4gdGhlIHBhc3QgdGhpcyB3YXMgbm90IGEgcHJv
YmxlbSwgc2luY2Ugd2hlbiB0aGUgZ3Vlc3QgaXMgUFYsIHdlCj4+IGRpZG4ndCBsYXVuY2ggUWVt
dSwgYW5kIHRodXMgdGhlIHRhcCBkZXZpY2Ugd2FzIG5ldmVyIGNyZWF0ZWQgYW5kIHRoZQo+PiBo
b3RwbHVnIHNjcmlwdHMgd2VyZSBub3QgbGF1bmNoZWQuIE5vdyB0aGF0IHdlIGxhdW5jaCBob3Rw
bHVnIHNjcmlwdHMKPj4gZnJvbSBsaWJ4bCB0aGlzIGlzIGEgcHJvYmxlbSwgYmVjYXVzZSB3aGVu
IHdlIGNhbGwgbGlieGxfZGV2aWNlX25pY19hZGQsCj4+IGxpYnhsIGhhcyBubyBpZGVhIGlmIHRo
ZSBkb21haW4gaXMgYSBQViBvciBIVk0gZ3Vlc3QsIGFuZCBvbmx5IHNlZXMgdGhlCj4+IG5ldHdv
cmsgdHlwZSwgd2hpY2ggaXMgc2V0IHRvIElPRU1VIGJ5IGRlZmF1bHQuCj4KPiBJdCBoYXMgYSBk
b21pZCBzbyBpdCBjYW4gYXNrIGFuZC9vciBwcm9wYWdhdGUgaXQgZG93biB0byBzZXRkZWZhdWx0
cy4KCkkgdGhpbmsgdGhlIG1vc3Qgc3VpdGFibGUgcGxhY2UgaXMgCmxpYnhsX2NyZWF0ZS5jOmlu
aXRpYXRlX2RvbWFpbl9jcmVhdGUsIHdoaWNoIGFsc28gc2V0cyB0aGUgZGVmYXVsdHMgZm9yIApk
aXNrIGRldmljZXMsIHNvIEkgdGhpbmsgaXQncyBhZGVxdWF0ZSB0byBwbGFjZSBzb21ldGhpbmcg
bGlrZToKCmlmIChkX2NvbmZpZy0+Y19pbmZvLnR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfUFYp
IHsKICAgICBmb3IgKGkgPSAwOyBpIDwgZF9jb25maWctPm51bV92aWZzOyBpKyspIHsKICAgICAg
ICAgZF9jb25maWctPnZpZnNbaV0ubmljdHlwZSA9IExJQlhMX05JQ19UWVBFX1ZJRjsKICAgICB9
Cn0KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:42:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:42:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBEt-00018d-BW; Thu, 28 Jun 2012 09:42:15 +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 1SkBEs-00018U-Is
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:42:14 +0000
Received: from [85.158.138.51:50453] by server-1.bemta-3.messagelabs.com id
	BF/77-14648-5F62CEF4; Thu, 28 Jun 2012 09:42:13 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340876529!21057096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32444 invoked from network); 28 Jun 2012 09:42:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:42:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13263787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:42:04 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:42:03 +0100
Message-ID: <4FEC26C2.6070901@citrix.com>
Date: Thu, 28 Jun 2012 10:41:22 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340875618.10942.14.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-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

SWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFRodSwgMjAxMi0wNi0yOCBhdCAxMDoyMiArMDEwMCwg
Um9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4+PiBPbiBUdWUs
IDIwMTItMDYtMjYgYXQgMTc6NTggKzAxMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgo+Pj4+
IE9uIFR1ZSwgSnVuIDI2LCAyMDEyIGF0IDA1OjIwOjM1UE0gKzAxMDAsIFJvZ2VyIFBhdSBNb25u
ZSB3cm90ZToKPj4+Pj4gSWFuIEphY2tzb24gd3JvdGU6Cj4+Pj4+PiBSb2dlciBQYXUgTW9ubmUg
d3JpdGVzICgiW1BBVENIIHY2IDEwLzEzXSBsaWJ4bDogc2V0IG5pYyB0eXBlIHRvIFZJRiBieSBk
ZWZhdWx0Iik6Cj4+Pj4+Pj4gU2V0IHRoZSBkZWZhdWx0IHZhbHVlIGZvciBuaWMgaW50ZXJmYWNl
cyB0byBWSUYsIHNpbmNlIGl0IHVzZWQgdG8gYmUKPj4+Pj4+PiBJT0VNVSwgZXZlbiBmb3IgUFYg
Z3Vlc3RzLgo+Pj4+Pj4gSWYgeW91ciByZW5hbWluZyBvZiBJT0VNVSB0byBWSUZfSU9FTVUgaXMg
Y29ycmVjdCwgZG9lcyB0aGlzIG5vdCBzdG9wCj4+Pj4+PiBIVk0gZ3Vlc3RzIGdldHRpbmcgZW11
bGF0ZWQgbmV0d29yayBpbnRlcmZhY2VzIGJ5IGRlZmF1bHQgPwo+Pj4+PiBZZXMsIGlmIHlvdSB3
YW50IGVtdWxhdGVkIGludGVyZmFjZXMgd2l0aCBIVk0gZ3Vlc3RzIHlvdSBzaG91bGQgdXNlCj4+
Pj4+ICd0eXBlPWlvZW11JywgdGhhdCdzIGhvdyBpdCBoYXMgYWx3YXlzIGJlZW4gcmlnaHQ/Cj4+
Pj4+Cj4+Pj4gV2l0aCBYZW4gNC4xIHlvdSBkb24ndCBoYXZlIHRvIHVzZSAidHlwZT1pb2VtdSIu
IEVtdWxhdGVkIGludGVyZmFjZXMgc2VlbSB0byB3b3JrIE9LIHdpdGhvdXQgInR5cGU9aW9lbXUi
Lgo+Pj4+IChhdCBsZWFzdCB3aXRoIHhtL3hlbmQpLiBBbmQgaWYgeW91IGFjdHVhbGx5IGRvIGFk
ZCAidHlwZT1pb2VtdSIgaXQgd2lsbCBicmVhayBQVkhWTSBmb3IgTGludXggZ3Vlc3RzLi4KPj4+
Pgo+Pj4+IFF1b3RlIGZyb206IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9YZW5MaW51eFBWb25I
Vk1kcml2ZXJzCj4+Pj4KPj4+PiAiTk9URSEgSWYgeW91IGhhdmUgInR5cGU9aW9lbXUiIHNwZWNp
ZmllZCBmb3IgdGhlICJ2aWYiLWxpbmUsIFBWSFZNCj4+Pj4gZHJpdmVycyBXSUxMIE5PVCB3b3Jr
ISBEb24ndCBzcGVjaWZ5ICJ0eXBlIiBwYXJhbWV0ZXIgZm9yIHRoZSB2aWYuCj4+Pj4gKHdpdGgg
dHlwZT1pb2VtdSB0aGUgcHZodm0gbmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3Mg
ZnVsbCBvZgo+Pj4+IHplcm9lcyAtIGFuZCB0aHVzIHdvbid0IHdvcmshKS4gIgo+Pj4gbWFjPTAw
OjAwOjAwOjAwOjAwIGlzIGNlcnRhaW5seSBhIGJ1ZywgaWYgKGxpYil4bCBiZWhhdmVzIHRoaXMg
d2F5IHRvbwo+Pj4gdGhlbiB3ZSBzaG91bGQgZml4IGl0Lgo+Pj4KPj4+IEJ1dCBzdXJlbHkgdHlw
ZT1pb2VtdSBpcyBzdXBwb3NlZCB0byBtZWFuICJvbmx5IGVtdWxhdGVkIj8gSW4gd2hpY2ggY2Fz
ZQo+Pj4gdGhlIGFjdHVhbCB4ZW5kIGJ1ZyBpcyB0aGF0IGl0IGNyZWF0ZWQgYSBQViBWSUYgYXQg
YWxsLgo+PiBDdXJyZW50bHkgdGhlcmUncyBubyBuZXR3b3JrIHR5cGUgdGhhdCBtZWFucyAiZW11
bGF0ZWQgb25seSIsIHdlIGhhdmUKPj4gVklGIGFuZCBWSUZfSU9FTVUuCj4KPiBBaCwgb2ssIHll
cyBJJ20gY29uZnVzZWQuCj4KPj4+IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhlcmU/IEkgdGhpbmsg
dGhleSBhcmUsIHdpdGggdGhlaXIgKGxpYil4bAo+Pj4gYmVoYXZpb3VyOgo+Pj4KPj4+IAkJUFYJ
CQkJSFZNCj4+PiB0eXBlPWlvZW11CW1lYW5pbmdsZXNzIC8gYW4gZXJyb3IJCWVtdWxhdGVkIGRl
dmljZSArIHBhcmF2aXJ0IFZJRioKPj4+IHR5cGU9dmlmCXBhcmF2aXJ0IFZJRiBkZXZpY2UqJgkJ
cGFyYXZpcnQgVklGIGRldmljZSBvbmx5Jgo+PiBZb3UgYXJlIG1pc3NpbmcgYSByb3csIHRoZSBk
ZWZhdWx0IG9uZSB3aGVuIHVzZXIgZG9lc24ndCBzcGVjaWZ5Cj4+IGFueXRoaW5nLAo+Cj4gVGhh
dCB3YXMgc3VwcG9zZWQgdG8gYmUgaW5kaWNhdGVkIGJ5IHRoZSAqIChub3cpIGFuZCYgIChhZnRl
ciB5b3VyCj4gcGF0Y2gpIHN5bWJvbHMgYWJvdmUuCj4KPj4gICB0aGlzIGN1cnJlbnRseSBpczoK
Pj4KPj4gCVBWCQkJCUhWTQo+PiBkZWZhdWx0CW5pYyB0eXBlIGlzIHNldCB0byBJRU9NVQluaWMg
dHlwZSBpcyBzZXQgdG8gSU9FTVUKPj4KPj4gSW4gdGhlIHBhc3QgdGhpcyB3YXMgbm90IGEgcHJv
YmxlbSwgc2luY2Ugd2hlbiB0aGUgZ3Vlc3QgaXMgUFYsIHdlCj4+IGRpZG4ndCBsYXVuY2ggUWVt
dSwgYW5kIHRodXMgdGhlIHRhcCBkZXZpY2Ugd2FzIG5ldmVyIGNyZWF0ZWQgYW5kIHRoZQo+PiBo
b3RwbHVnIHNjcmlwdHMgd2VyZSBub3QgbGF1bmNoZWQuIE5vdyB0aGF0IHdlIGxhdW5jaCBob3Rw
bHVnIHNjcmlwdHMKPj4gZnJvbSBsaWJ4bCB0aGlzIGlzIGEgcHJvYmxlbSwgYmVjYXVzZSB3aGVu
IHdlIGNhbGwgbGlieGxfZGV2aWNlX25pY19hZGQsCj4+IGxpYnhsIGhhcyBubyBpZGVhIGlmIHRo
ZSBkb21haW4gaXMgYSBQViBvciBIVk0gZ3Vlc3QsIGFuZCBvbmx5IHNlZXMgdGhlCj4+IG5ldHdv
cmsgdHlwZSwgd2hpY2ggaXMgc2V0IHRvIElPRU1VIGJ5IGRlZmF1bHQuCj4KPiBJdCBoYXMgYSBk
b21pZCBzbyBpdCBjYW4gYXNrIGFuZC9vciBwcm9wYWdhdGUgaXQgZG93biB0byBzZXRkZWZhdWx0
cy4KCkkgdGhpbmsgdGhlIG1vc3Qgc3VpdGFibGUgcGxhY2UgaXMgCmxpYnhsX2NyZWF0ZS5jOmlu
aXRpYXRlX2RvbWFpbl9jcmVhdGUsIHdoaWNoIGFsc28gc2V0cyB0aGUgZGVmYXVsdHMgZm9yIApk
aXNrIGRldmljZXMsIHNvIEkgdGhpbmsgaXQncyBhZGVxdWF0ZSB0byBwbGFjZSBzb21ldGhpbmcg
bGlrZToKCmlmIChkX2NvbmZpZy0+Y19pbmZvLnR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfUFYp
IHsKICAgICBmb3IgKGkgPSAwOyBpIDwgZF9jb25maWctPm51bV92aWZzOyBpKyspIHsKICAgICAg
ICAgZF9jb25maWctPnZpZnNbaV0ubmljdHlwZSA9IExJQlhMX05JQ19UWVBFX1ZJRjsKICAgICB9
Cn0KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:52:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkBOK-0001M4-Dm; Thu, 28 Jun 2012 09:52: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 1SkBOJ-0001Lz-8x
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:51:59 +0000
Received: from [85.158.143.35:45775] by server-2.bemta-4.messagelabs.com id
	E2/70-17938-E392CEF4; Thu, 28 Jun 2012 09:51:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340877055!7100906!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20236 invoked from network); 28 Jun 2012 09:50:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 09:50:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 10:50:54 +0100
Message-Id: <4FEC454C020000780008C6A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 10:51:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FEB5AA6.4010403@citrix.com>
In-Reply-To: <4FEB5AA6.4010403@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Logical NUMA error during boot, and RFC 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 27.06.12 at 21:10, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> XenServer have recently acquired a quad-socket AMD Interlagos server and
> I have been playing around with it, and discovered a logical error in
> how Xen detects numa nodes.
> 
> The server has 8 NUMA nodes, 4 of which have memory attached (the even
> nodes - see SRAT.dsl attached).  This means that that
> node_set_online(nodeid) gets called for each node with memory attached. 
> Later, in srat_detect_node(), node gets set to 0 if it was NUMA_NO_NODE,
> or if not node_online().  This leads to all the processors on the odd
> nodes being assigned to node 0, even though the odd nodes are present
> (see interlagos-xl-info-n.log)
> 
> I present an RFC patch which changes srat_detect_node() to call
> node_set_online() for each node, which appears to fix the logic.
> 
> Is this a sensible place to set the node online, or is there a better
> way to fix this logic?

While the place looks sensible, it has the possible problem of
potentially adding bits to the online map pretty late in the game.

As the memory-related invocations of node_set_online() come
out of numa_initmem_init()/acpi_scan_nodes(), perhaps the
(boot time) CPU-related ones should be done there too (I'd
still keep the adjustment you're already doing, to also cover
hotplug CPUs)?

Jan

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:52:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkBOK-0001M4-Dm; Thu, 28 Jun 2012 09:52: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 1SkBOJ-0001Lz-8x
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:51:59 +0000
Received: from [85.158.143.35:45775] by server-2.bemta-4.messagelabs.com id
	E2/70-17938-E392CEF4; Thu, 28 Jun 2012 09:51:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340877055!7100906!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20236 invoked from network); 28 Jun 2012 09:50:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 09:50:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 10:50:54 +0100
Message-Id: <4FEC454C020000780008C6A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 10:51:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4FEB5AA6.4010403@citrix.com>
In-Reply-To: <4FEB5AA6.4010403@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Logical NUMA error during boot, and RFC 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 27.06.12 at 21:10, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> XenServer have recently acquired a quad-socket AMD Interlagos server and
> I have been playing around with it, and discovered a logical error in
> how Xen detects numa nodes.
> 
> The server has 8 NUMA nodes, 4 of which have memory attached (the even
> nodes - see SRAT.dsl attached).  This means that that
> node_set_online(nodeid) gets called for each node with memory attached. 
> Later, in srat_detect_node(), node gets set to 0 if it was NUMA_NO_NODE,
> or if not node_online().  This leads to all the processors on the odd
> nodes being assigned to node 0, even though the odd nodes are present
> (see interlagos-xl-info-n.log)
> 
> I present an RFC patch which changes srat_detect_node() to call
> node_set_online() for each node, which appears to fix the logic.
> 
> Is this a sensible place to set the node online, or is there a better
> way to fix this logic?

While the place looks sensible, it has the possible problem of
potentially adding bits to the online map pretty late in the game.

As the memory-related invocations of node_set_online() come
out of numa_initmem_init()/acpi_scan_nodes(), perhaps the
(boot time) CPU-related ones should be done there too (I'd
still keep the adjustment you're already doing, to also cover
hotplug CPUs)?

Jan

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:54:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:54: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 1SkBQ7-0001R3-TZ; Thu, 28 Jun 2012 09:53:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SkBQ6-0001Qv-Bk
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:53:50 +0000
Received: from [85.158.143.99:60017] by server-3.bemta-4.messagelabs.com id
	A3/98-05808-DA92CEF4; Thu, 28 Jun 2012 09:53:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340877229!29516609!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6761 invoked from network); 28 Jun 2012 09:53:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:53:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:53:49 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:53:49 +0100
Message-ID: <4FEC2983.5040500@citrix.com>
Date: Thu, 28 Jun 2012 10:53:07 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
	<20457.61377.77775.31123@mariner.uk.xensource.com>
In-Reply-To: <20457.61377.77775.31123@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
>> Ian Jackson wrote:
>>> Should we rename the functions libxl_*nic* or the structures *vif* ?
>>> Or should we rename both, to "net" perhaps ?
>> I think we should either rename the strucutres to nic also (because the
>> also hold ioemu cards), or get rid of nic/vif an name everything net.
>
> Can you try to rename everything to `net' and see if that turns out to
> be an impenetrable yak ?

I think it is much more easy to rename everything to nic, which provides 
the same level of abstraction from my PoV. Renaming everything to net 
it's a rather very big change. Would you be ok with that change?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:54:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:54: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 1SkBQ7-0001R3-TZ; Thu, 28 Jun 2012 09:53:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1SkBQ6-0001Qv-Bk
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:53:50 +0000
Received: from [85.158.143.99:60017] by server-3.bemta-4.messagelabs.com id
	A3/98-05808-DA92CEF4; Thu, 28 Jun 2012 09:53:49 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340877229!29516609!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6761 invoked from network); 28 Jun 2012 09:53:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:53:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:53:49 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 10:53:49 +0100
Message-ID: <4FEC2983.5040500@citrix.com>
Date: Thu, 28 Jun 2012 10:53:07 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
	<20457.61377.77775.31123@mariner.uk.xensource.com>
In-Reply-To: <20457.61377.77775.31123@mariner.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
>> Ian Jackson wrote:
>>> Should we rename the functions libxl_*nic* or the structures *vif* ?
>>> Or should we rename both, to "net" perhaps ?
>> I think we should either rename the strucutres to nic also (because the
>> also hold ioemu cards), or get rid of nic/vif an name everything net.
>
> Can you try to rename everything to `net' and see if that turns out to
> be an impenetrable yak ?

I think it is much more easy to rename everything to nic, which provides 
the same level of abstraction from my PoV. Renaming everything to net 
it's a rather very big change. Would you be ok with that change?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkBQd-0001TW-AS; Thu, 28 Jun 2012 09:54: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 1SkBQc-0001TI-JQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:54:22 +0000
Received: from [193.109.254.147:64014] by server-11.bemta-14.messagelabs.com
	id 5B/CF-24843-DC92CEF4; Thu, 28 Jun 2012 09:54:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340877258!8834787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24436 invoked from network); 28 Jun 2012 09:54:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:54:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:54:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:54:18 +0100
Message-ID: <1340877257.10942.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 10:54:17 +0100
In-Reply-To: <4FEC26C2.6070901@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

T24gVGh1LCAyMDEyLTA2LTI4IGF0IDEwOjQxICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gVGh1LCAyMDEyLTA2LTI4IGF0IDEwOjIyICsw
MTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+
PiBPbiBUdWUsIDIwMTItMDYtMjYgYXQgMTc6NTggKzAxMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdy
b3RlOgo+ID4+Pj4gT24gVHVlLCBKdW4gMjYsIDIwMTIgYXQgMDU6MjA6MzVQTSArMDEwMCwgUm9n
ZXIgUGF1IE1vbm5lIHdyb3RlOgo+ID4+Pj4+IElhbiBKYWNrc29uIHdyb3RlOgo+ID4+Pj4+PiBS
b2dlciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY2IDEwLzEzXSBsaWJ4bDogc2V0IG5pYyB0
eXBlIHRvIFZJRiBieSBkZWZhdWx0Iik6Cj4gPj4+Pj4+PiBTZXQgdGhlIGRlZmF1bHQgdmFsdWUg
Zm9yIG5pYyBpbnRlcmZhY2VzIHRvIFZJRiwgc2luY2UgaXQgdXNlZCB0byBiZQo+ID4+Pj4+Pj4g
SU9FTVUsIGV2ZW4gZm9yIFBWIGd1ZXN0cy4KPiA+Pj4+Pj4gSWYgeW91ciByZW5hbWluZyBvZiBJ
T0VNVSB0byBWSUZfSU9FTVUgaXMgY29ycmVjdCwgZG9lcyB0aGlzIG5vdCBzdG9wCj4gPj4+Pj4+
IEhWTSBndWVzdHMgZ2V0dGluZyBlbXVsYXRlZCBuZXR3b3JrIGludGVyZmFjZXMgYnkgZGVmYXVs
dCA/Cj4gPj4+Pj4gWWVzLCBpZiB5b3Ugd2FudCBlbXVsYXRlZCBpbnRlcmZhY2VzIHdpdGggSFZN
IGd1ZXN0cyB5b3Ugc2hvdWxkIHVzZQo+ID4+Pj4+ICd0eXBlPWlvZW11JywgdGhhdCdzIGhvdyBp
dCBoYXMgYWx3YXlzIGJlZW4gcmlnaHQ/Cj4gPj4+Pj4KPiA+Pj4+IFdpdGggWGVuIDQuMSB5b3Ug
ZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9aW9lbXUiLiBFbXVsYXRlZCBpbnRlcmZhY2VzIHNlZW0g
dG8gd29yayBPSyB3aXRob3V0ICJ0eXBlPWlvZW11Ii4KPiA+Pj4+IChhdCBsZWFzdCB3aXRoIHht
L3hlbmQpLiBBbmQgaWYgeW91IGFjdHVhbGx5IGRvIGFkZCAidHlwZT1pb2VtdSIgaXQgd2lsbCBi
cmVhayBQVkhWTSBmb3IgTGludXggZ3Vlc3RzLi4KPiA+Pj4+Cj4gPj4+PiBRdW90ZSBmcm9tOiBo
dHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuTGludXhQVm9uSFZNZHJpdmVycwo+ID4+Pj4KPiA+
Pj4+ICJOT1RFISBJZiB5b3UgaGF2ZSAidHlwZT1pb2VtdSIgc3BlY2lmaWVkIGZvciB0aGUgInZp
ZiItbGluZSwgUFZIVk0KPiA+Pj4+IGRyaXZlcnMgV0lMTCBOT1Qgd29yayEgRG9uJ3Qgc3BlY2lm
eSAidHlwZSIgcGFyYW1ldGVyIGZvciB0aGUgdmlmLgo+ID4+Pj4gKHdpdGggdHlwZT1pb2VtdSB0
aGUgcHZodm0gbmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3MgZnVsbCBvZgo+ID4+
Pj4gemVyb2VzIC0gYW5kIHRodXMgd29uJ3Qgd29yayEpLiAiCj4gPj4+IG1hYz0wMDowMDowMDow
MDowMCBpcyBjZXJ0YWlubHkgYSBidWcsIGlmIChsaWIpeGwgYmVoYXZlcyB0aGlzIHdheSB0b28K
PiA+Pj4gdGhlbiB3ZSBzaG91bGQgZml4IGl0Lgo+ID4+Pgo+ID4+PiBCdXQgc3VyZWx5IHR5cGU9
aW9lbXUgaXMgc3VwcG9zZWQgdG8gbWVhbiAib25seSBlbXVsYXRlZCI/IEluIHdoaWNoIGNhc2UK
PiA+Pj4gdGhlIGFjdHVhbCB4ZW5kIGJ1ZyBpcyB0aGF0IGl0IGNyZWF0ZWQgYSBQViBWSUYgYXQg
YWxsLgo+ID4+IEN1cnJlbnRseSB0aGVyZSdzIG5vIG5ldHdvcmsgdHlwZSB0aGF0IG1lYW5zICJl
bXVsYXRlZCBvbmx5Iiwgd2UgaGF2ZQo+ID4+IFZJRiBhbmQgVklGX0lPRU1VLgo+ID4KPiA+IEFo
LCBvaywgeWVzIEknbSBjb25mdXNlZC4KPiA+Cj4gPj4+IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhl
cmU/IEkgdGhpbmsgdGhleSBhcmUsIHdpdGggdGhlaXIgKGxpYil4bAo+ID4+PiBiZWhhdmlvdXI6
Cj4gPj4+Cj4gPj4+IAkJUFYJCQkJSFZNCj4gPj4+IHR5cGU9aW9lbXUJbWVhbmluZ2xlc3MgLyBh
biBlcnJvcgkJZW11bGF0ZWQgZGV2aWNlICsgcGFyYXZpcnQgVklGKgo+ID4+PiB0eXBlPXZpZglw
YXJhdmlydCBWSUYgZGV2aWNlKiYJCXBhcmF2aXJ0IFZJRiBkZXZpY2Ugb25seSYKPiA+PiBZb3Ug
YXJlIG1pc3NpbmcgYSByb3csIHRoZSBkZWZhdWx0IG9uZSB3aGVuIHVzZXIgZG9lc24ndCBzcGVj
aWZ5Cj4gPj4gYW55dGhpbmcsCj4gPgo+ID4gVGhhdCB3YXMgc3VwcG9zZWQgdG8gYmUgaW5kaWNh
dGVkIGJ5IHRoZSAqIChub3cpIGFuZCYgIChhZnRlciB5b3VyCj4gPiBwYXRjaCkgc3ltYm9scyBh
Ym92ZS4KPiA+Cj4gPj4gICB0aGlzIGN1cnJlbnRseSBpczoKPiA+Pgo+ID4+IAlQVgkJCQlIVk0K
PiA+PiBkZWZhdWx0CW5pYyB0eXBlIGlzIHNldCB0byBJRU9NVQluaWMgdHlwZSBpcyBzZXQgdG8g
SU9FTVUKPiA+Pgo+ID4+IEluIHRoZSBwYXN0IHRoaXMgd2FzIG5vdCBhIHByb2JsZW0sIHNpbmNl
IHdoZW4gdGhlIGd1ZXN0IGlzIFBWLCB3ZQo+ID4+IGRpZG4ndCBsYXVuY2ggUWVtdSwgYW5kIHRo
dXMgdGhlIHRhcCBkZXZpY2Ugd2FzIG5ldmVyIGNyZWF0ZWQgYW5kIHRoZQo+ID4+IGhvdHBsdWcg
c2NyaXB0cyB3ZXJlIG5vdCBsYXVuY2hlZC4gTm93IHRoYXQgd2UgbGF1bmNoIGhvdHBsdWcgc2Ny
aXB0cwo+ID4+IGZyb20gbGlieGwgdGhpcyBpcyBhIHByb2JsZW0sIGJlY2F1c2Ugd2hlbiB3ZSBj
YWxsIGxpYnhsX2RldmljZV9uaWNfYWRkLAo+ID4+IGxpYnhsIGhhcyBubyBpZGVhIGlmIHRoZSBk
b21haW4gaXMgYSBQViBvciBIVk0gZ3Vlc3QsIGFuZCBvbmx5IHNlZXMgdGhlCj4gPj4gbmV0d29y
ayB0eXBlLCB3aGljaCBpcyBzZXQgdG8gSU9FTVUgYnkgZGVmYXVsdC4KPiA+Cj4gPiBJdCBoYXMg
YSBkb21pZCBzbyBpdCBjYW4gYXNrIGFuZC9vciBwcm9wYWdhdGUgaXQgZG93biB0byBzZXRkZWZh
dWx0cy4KPiAKPiBJIHRoaW5rIHRoZSBtb3N0IHN1aXRhYmxlIHBsYWNlIGlzIAo+IGxpYnhsX2Ny
ZWF0ZS5jOmluaXRpYXRlX2RvbWFpbl9jcmVhdGUsIHdoaWNoIGFsc28gc2V0cyB0aGUgZGVmYXVs
dHMgZm9yIAo+IGRpc2sgZGV2aWNlcywgCgouLiBieSBjYWxsaW5nIHNldGRlZmF1bHRzIHRob3Vn
aC4KCkknZCBsaWtlIHRvIGtlZXAgYWxsIHN1Y2ggbG9naWMgaW4gc2V0ZGVmYXVsdHMgYXMgZmFy
IGFzIHBvc3NpYmxlLgoKbGlieGxfX2RldmljX25pY19zZXRkZWZhdXRscyBpcyBhbiBpbnRlcm5h
bCBmdW5jdGlvbiBzbyB3ZSBjYW4gYWRkCmVpdGhlciBhIGRvbWlkIG9yIHR5cGUgcGFyYW1ldGVy
IHF1aXRlIGVhc2lseS4gQXJlIHRoZXJlIGFueSBjYWxsc2l0ZXMKd2hpY2ggd291bGQgYmUgdW5h
YmxlIHRvIHByb3ZpZGUgb25lIG9yIHRoZSBvdGhlciBvZiB0aG9zZT8KClByb2JhYmx5IGRvbWlk
IGlzIGJlc3QsIHdpdGggc2V0ZGVmYXVsdHMgY2FsbGluZyBsaWJ4bF9fZG9tYWluX3R5cGUgYXMK
bmVjZXNzYXJ5LgoKPiBzbyBJIHRoaW5rIGl0J3MgYWRlcXVhdGUgdG8gcGxhY2Ugc29tZXRoaW5n
IGxpa2U6Cj4gCj4gaWYgKGRfY29uZmlnLT5jX2luZm8udHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQ
RV9QVikgewo+ICAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fdmlmczsgaSsrKSB7
Cj4gICAgICAgICAgZF9jb25maWctPnZpZnNbaV0ubmljdHlwZSA9IExJQlhMX05JQ19UWVBFX1ZJ
RjsKPiAgICAgIH0KPiB9Cj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09: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 1SkBQd-0001TW-AS; Thu, 28 Jun 2012 09:54: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 1SkBQc-0001TI-JQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:54:22 +0000
Received: from [193.109.254.147:64014] by server-11.bemta-14.messagelabs.com
	id 5B/CF-24843-DC92CEF4; Thu, 28 Jun 2012 09:54:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340877258!8834787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24436 invoked from network); 28 Jun 2012 09:54:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:54:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:54:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:54:18 +0100
Message-ID: <1340877257.10942.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 10:54:17 +0100
In-Reply-To: <4FEC26C2.6070901@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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

T24gVGh1LCAyMDEyLTA2LTI4IGF0IDEwOjQxICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gVGh1LCAyMDEyLTA2LTI4IGF0IDEwOjIyICsw
MTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4gSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+
PiBPbiBUdWUsIDIwMTItMDYtMjYgYXQgMTc6NTggKzAxMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdy
b3RlOgo+ID4+Pj4gT24gVHVlLCBKdW4gMjYsIDIwMTIgYXQgMDU6MjA6MzVQTSArMDEwMCwgUm9n
ZXIgUGF1IE1vbm5lIHdyb3RlOgo+ID4+Pj4+IElhbiBKYWNrc29uIHdyb3RlOgo+ID4+Pj4+PiBS
b2dlciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY2IDEwLzEzXSBsaWJ4bDogc2V0IG5pYyB0
eXBlIHRvIFZJRiBieSBkZWZhdWx0Iik6Cj4gPj4+Pj4+PiBTZXQgdGhlIGRlZmF1bHQgdmFsdWUg
Zm9yIG5pYyBpbnRlcmZhY2VzIHRvIFZJRiwgc2luY2UgaXQgdXNlZCB0byBiZQo+ID4+Pj4+Pj4g
SU9FTVUsIGV2ZW4gZm9yIFBWIGd1ZXN0cy4KPiA+Pj4+Pj4gSWYgeW91ciByZW5hbWluZyBvZiBJ
T0VNVSB0byBWSUZfSU9FTVUgaXMgY29ycmVjdCwgZG9lcyB0aGlzIG5vdCBzdG9wCj4gPj4+Pj4+
IEhWTSBndWVzdHMgZ2V0dGluZyBlbXVsYXRlZCBuZXR3b3JrIGludGVyZmFjZXMgYnkgZGVmYXVs
dCA/Cj4gPj4+Pj4gWWVzLCBpZiB5b3Ugd2FudCBlbXVsYXRlZCBpbnRlcmZhY2VzIHdpdGggSFZN
IGd1ZXN0cyB5b3Ugc2hvdWxkIHVzZQo+ID4+Pj4+ICd0eXBlPWlvZW11JywgdGhhdCdzIGhvdyBp
dCBoYXMgYWx3YXlzIGJlZW4gcmlnaHQ/Cj4gPj4+Pj4KPiA+Pj4+IFdpdGggWGVuIDQuMSB5b3Ug
ZG9uJ3QgaGF2ZSB0byB1c2UgInR5cGU9aW9lbXUiLiBFbXVsYXRlZCBpbnRlcmZhY2VzIHNlZW0g
dG8gd29yayBPSyB3aXRob3V0ICJ0eXBlPWlvZW11Ii4KPiA+Pj4+IChhdCBsZWFzdCB3aXRoIHht
L3hlbmQpLiBBbmQgaWYgeW91IGFjdHVhbGx5IGRvIGFkZCAidHlwZT1pb2VtdSIgaXQgd2lsbCBi
cmVhayBQVkhWTSBmb3IgTGludXggZ3Vlc3RzLi4KPiA+Pj4+Cj4gPj4+PiBRdW90ZSBmcm9tOiBo
dHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuTGludXhQVm9uSFZNZHJpdmVycwo+ID4+Pj4KPiA+
Pj4+ICJOT1RFISBJZiB5b3UgaGF2ZSAidHlwZT1pb2VtdSIgc3BlY2lmaWVkIGZvciB0aGUgInZp
ZiItbGluZSwgUFZIVk0KPiA+Pj4+IGRyaXZlcnMgV0lMTCBOT1Qgd29yayEgRG9uJ3Qgc3BlY2lm
eSAidHlwZSIgcGFyYW1ldGVyIGZvciB0aGUgdmlmLgo+ID4+Pj4gKHdpdGggdHlwZT1pb2VtdSB0
aGUgcHZodm0gbmljIGluIHRoZSBWTSB3aWxsIGhhdmUgbWFjIGFkZHJlc3MgZnVsbCBvZgo+ID4+
Pj4gemVyb2VzIC0gYW5kIHRodXMgd29uJ3Qgd29yayEpLiAiCj4gPj4+IG1hYz0wMDowMDowMDow
MDowMCBpcyBjZXJ0YWlubHkgYSBidWcsIGlmIChsaWIpeGwgYmVoYXZlcyB0aGlzIHdheSB0b28K
PiA+Pj4gdGhlbiB3ZSBzaG91bGQgZml4IGl0Lgo+ID4+Pgo+ID4+PiBCdXQgc3VyZWx5IHR5cGU9
aW9lbXUgaXMgc3VwcG9zZWQgdG8gbWVhbiAib25seSBlbXVsYXRlZCI/IEluIHdoaWNoIGNhc2UK
PiA+Pj4gdGhlIGFjdHVhbCB4ZW5kIGJ1ZyBpcyB0aGF0IGl0IGNyZWF0ZWQgYSBQViBWSUYgYXQg
YWxsLgo+ID4+IEN1cnJlbnRseSB0aGVyZSdzIG5vIG5ldHdvcmsgdHlwZSB0aGF0IG1lYW5zICJl
bXVsYXRlZCBvbmx5Iiwgd2UgaGF2ZQo+ID4+IFZJRiBhbmQgVklGX0lPRU1VLgo+ID4KPiA+IEFo
LCBvaywgeWVzIEknbSBjb25mdXNlZC4KPiA+Cj4gPj4+IFdoYXQgYXJlIHRoZSBvcHRpb25zIGhl
cmU/IEkgdGhpbmsgdGhleSBhcmUsIHdpdGggdGhlaXIgKGxpYil4bAo+ID4+PiBiZWhhdmlvdXI6
Cj4gPj4+Cj4gPj4+IAkJUFYJCQkJSFZNCj4gPj4+IHR5cGU9aW9lbXUJbWVhbmluZ2xlc3MgLyBh
biBlcnJvcgkJZW11bGF0ZWQgZGV2aWNlICsgcGFyYXZpcnQgVklGKgo+ID4+PiB0eXBlPXZpZglw
YXJhdmlydCBWSUYgZGV2aWNlKiYJCXBhcmF2aXJ0IFZJRiBkZXZpY2Ugb25seSYKPiA+PiBZb3Ug
YXJlIG1pc3NpbmcgYSByb3csIHRoZSBkZWZhdWx0IG9uZSB3aGVuIHVzZXIgZG9lc24ndCBzcGVj
aWZ5Cj4gPj4gYW55dGhpbmcsCj4gPgo+ID4gVGhhdCB3YXMgc3VwcG9zZWQgdG8gYmUgaW5kaWNh
dGVkIGJ5IHRoZSAqIChub3cpIGFuZCYgIChhZnRlciB5b3VyCj4gPiBwYXRjaCkgc3ltYm9scyBh
Ym92ZS4KPiA+Cj4gPj4gICB0aGlzIGN1cnJlbnRseSBpczoKPiA+Pgo+ID4+IAlQVgkJCQlIVk0K
PiA+PiBkZWZhdWx0CW5pYyB0eXBlIGlzIHNldCB0byBJRU9NVQluaWMgdHlwZSBpcyBzZXQgdG8g
SU9FTVUKPiA+Pgo+ID4+IEluIHRoZSBwYXN0IHRoaXMgd2FzIG5vdCBhIHByb2JsZW0sIHNpbmNl
IHdoZW4gdGhlIGd1ZXN0IGlzIFBWLCB3ZQo+ID4+IGRpZG4ndCBsYXVuY2ggUWVtdSwgYW5kIHRo
dXMgdGhlIHRhcCBkZXZpY2Ugd2FzIG5ldmVyIGNyZWF0ZWQgYW5kIHRoZQo+ID4+IGhvdHBsdWcg
c2NyaXB0cyB3ZXJlIG5vdCBsYXVuY2hlZC4gTm93IHRoYXQgd2UgbGF1bmNoIGhvdHBsdWcgc2Ny
aXB0cwo+ID4+IGZyb20gbGlieGwgdGhpcyBpcyBhIHByb2JsZW0sIGJlY2F1c2Ugd2hlbiB3ZSBj
YWxsIGxpYnhsX2RldmljZV9uaWNfYWRkLAo+ID4+IGxpYnhsIGhhcyBubyBpZGVhIGlmIHRoZSBk
b21haW4gaXMgYSBQViBvciBIVk0gZ3Vlc3QsIGFuZCBvbmx5IHNlZXMgdGhlCj4gPj4gbmV0d29y
ayB0eXBlLCB3aGljaCBpcyBzZXQgdG8gSU9FTVUgYnkgZGVmYXVsdC4KPiA+Cj4gPiBJdCBoYXMg
YSBkb21pZCBzbyBpdCBjYW4gYXNrIGFuZC9vciBwcm9wYWdhdGUgaXQgZG93biB0byBzZXRkZWZh
dWx0cy4KPiAKPiBJIHRoaW5rIHRoZSBtb3N0IHN1aXRhYmxlIHBsYWNlIGlzIAo+IGxpYnhsX2Ny
ZWF0ZS5jOmluaXRpYXRlX2RvbWFpbl9jcmVhdGUsIHdoaWNoIGFsc28gc2V0cyB0aGUgZGVmYXVs
dHMgZm9yIAo+IGRpc2sgZGV2aWNlcywgCgouLiBieSBjYWxsaW5nIHNldGRlZmF1bHRzIHRob3Vn
aC4KCkknZCBsaWtlIHRvIGtlZXAgYWxsIHN1Y2ggbG9naWMgaW4gc2V0ZGVmYXVsdHMgYXMgZmFy
IGFzIHBvc3NpYmxlLgoKbGlieGxfX2RldmljX25pY19zZXRkZWZhdXRscyBpcyBhbiBpbnRlcm5h
bCBmdW5jdGlvbiBzbyB3ZSBjYW4gYWRkCmVpdGhlciBhIGRvbWlkIG9yIHR5cGUgcGFyYW1ldGVy
IHF1aXRlIGVhc2lseS4gQXJlIHRoZXJlIGFueSBjYWxsc2l0ZXMKd2hpY2ggd291bGQgYmUgdW5h
YmxlIHRvIHByb3ZpZGUgb25lIG9yIHRoZSBvdGhlciBvZiB0aG9zZT8KClByb2JhYmx5IGRvbWlk
IGlzIGJlc3QsIHdpdGggc2V0ZGVmYXVsdHMgY2FsbGluZyBsaWJ4bF9fZG9tYWluX3R5cGUgYXMK
bmVjZXNzYXJ5LgoKPiBzbyBJIHRoaW5rIGl0J3MgYWRlcXVhdGUgdG8gcGxhY2Ugc29tZXRoaW5n
IGxpa2U6Cj4gCj4gaWYgKGRfY29uZmlnLT5jX2luZm8udHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQ
RV9QVikgewo+ICAgICAgZm9yIChpID0gMDsgaSA8IGRfY29uZmlnLT5udW1fdmlmczsgaSsrKSB7
Cj4gICAgICAgICAgZF9jb25maWctPnZpZnNbaV0ubmljdHlwZSA9IExJQlhMX05JQ19UWVBFX1ZJ
RjsKPiAgICAgIH0KPiB9Cj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 28 09:55:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:55: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 1SkBRD-0001YL-Sf; Thu, 28 Jun 2012 09:54: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 1SkBRC-0001Xx-MJ
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:54:58 +0000
Received: from [85.158.143.35:11025] by server-3.bemta-4.messagelabs.com id
	B4/EA-05808-2F92CEF4; Thu, 28 Jun 2012 09:54:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340877297!15381402!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 707 invoked from network); 28 Jun 2012 09:54:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 09:54:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 10:54:56 +0100
Message-Id: <4FEC463E020000780008C6A7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 10:55:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> So I would like to push new vMCE as quickly as possible. What's the timeline 
> of vMCE developing that xen 4.2 could accept?

Weeks ago, really. See http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
and follow-ups - we'd really only consider getting the save/restore
interface into forward compatible shape as acceptable.

> I wonder if we could make major 
> components of vMCE done before xen 4.2 timeline, and leave the surrounding 
> features and the corner cases done later?

Unfortunately it's likely going to be even less. However, if split
that way, chances are things could go into e.g. 4.2.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 Jun 28 09:55:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:55: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 1SkBRD-0001YL-Sf; Thu, 28 Jun 2012 09:54: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 1SkBRC-0001Xx-MJ
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:54:58 +0000
Received: from [85.158.143.35:11025] by server-3.bemta-4.messagelabs.com id
	B4/EA-05808-2F92CEF4; Thu, 28 Jun 2012 09:54:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340877297!15381402!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 707 invoked from network); 28 Jun 2012 09:54:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	28 Jun 2012 09:54:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 10:54:56 +0100
Message-Id: <4FEC463E020000780008C6A7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 10:55:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> So I would like to push new vMCE as quickly as possible. What's the timeline 
> of vMCE developing that xen 4.2 could accept?

Weeks ago, really. See http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
and follow-ups - we'd really only consider getting the save/restore
interface into forward compatible shape as acceptable.

> I wonder if we could make major 
> components of vMCE done before xen 4.2 timeline, and leave the surrounding 
> features and the corner cases done later?

Unfortunately it's likely going to be even less. However, if split
that way, chances are things could go into e.g. 4.2.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 Jun 28 09:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:57: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 1SkBTA-0001mV-Ja; Thu, 28 Jun 2012 09:57: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 1SkBT9-0001mG-5S
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:56:59 +0000
Received: from [85.158.143.99:24269] by server-2.bemta-4.messagelabs.com id
	13/2A-17938-A6A2CEF4; Thu, 28 Jun 2012 09:56:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340877417!26181129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15490 invoked from network); 28 Jun 2012 09:56:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:56:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:56:57 +0100
Message-ID: <1340877416.10942.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 10:56:56 +0100
In-Reply-To: <4FEC2983.5040500@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
	<20457.61377.77775.31123@mariner.uk.xensource.com>
	<4FEC2983.5040500@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 10:53 +0100, Roger Pau Monne wrote:
> Ian Jackson wrote:
> > Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
> >> Ian Jackson wrote:
> >>> Should we rename the functions libxl_*nic* or the structures *vif* ?
> >>> Or should we rename both, to "net" perhaps ?
> >> I think we should either rename the strucutres to nic also (because the
> >> also hold ioemu cards), or get rid of nic/vif an name everything net.
> >
> > Can you try to rename everything to `net' and see if that turns out to
> > be an impenetrable yak ?
> 
> I think it is much more easy to rename everything to nic, which provides 
> the same level of abstraction from my PoV. Renaming everything to net 
> it's a rather very big change. Would you be ok with that change?

I'd be happy with nic, I think it fits better with libxl_device_disk
anyway. (if it were libxl_device_net would be more analogous to
libxl_device_storage 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 Thu Jun 28 09:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:57: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 1SkBTA-0001mV-Ja; Thu, 28 Jun 2012 09:57: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 1SkBT9-0001mG-5S
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 09:56:59 +0000
Received: from [85.158.143.99:24269] by server-2.bemta-4.messagelabs.com id
	13/2A-17938-A6A2CEF4; Thu, 28 Jun 2012 09:56:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340877417!26181129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15490 invoked from network); 28 Jun 2012 09:56:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:56:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:56:57 +0100
Message-ID: <1340877416.10942.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 10:56:56 +0100
In-Reply-To: <4FEC2983.5040500@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
	<20457.61377.77775.31123@mariner.uk.xensource.com>
	<4FEC2983.5040500@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 10:53 +0100, Roger Pau Monne wrote:
> Ian Jackson wrote:
> > Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
> >> Ian Jackson wrote:
> >>> Should we rename the functions libxl_*nic* or the structures *vif* ?
> >>> Or should we rename both, to "net" perhaps ?
> >> I think we should either rename the strucutres to nic also (because the
> >> also hold ioemu cards), or get rid of nic/vif an name everything net.
> >
> > Can you try to rename everything to `net' and see if that turns out to
> > be an impenetrable yak ?
> 
> I think it is much more easy to rename everything to nic, which provides 
> the same level of abstraction from my PoV. Renaming everything to net 
> it's a rather very big change. Would you be ok with that change?

I'd be happy with nic, I think it fits better with libxl_device_disk
anyway. (if it were libxl_device_net would be more analogous to
libxl_device_storage 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 Thu Jun 28 09:58:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:58: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 1SkBUs-00020K-Pp; Thu, 28 Jun 2012 09:58: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 1SkBUq-0001zt-VP
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:58:45 +0000
Received: from [85.158.143.35:36765] by server-2.bemta-4.messagelabs.com id
	9D/6D-17938-4DA2CEF4; Thu, 28 Jun 2012 09:58:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340877515!14483856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15784 invoked from network); 28 Jun 2012 09:58:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:58:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:58:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:58:35 +0100
Message-ID: <1340877513.10942.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 28 Jun 2012 10:58:33 +0100
In-Reply-To: <4FEC463E020000780008C6A7@nat28.tlf.novell.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jinsong Liu <jinsong.liu@intel.com>, Tony Luck <tony.luck@intel.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ashok Raj <ashok.raj@intel.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Donald D
	Dugger <donald.d.dugger@intel.com>, Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>, Susie Li <susie.li@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 10:55 +0100, Jan Beulich wrote:
> >>> On 28.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> > So I would like to push new vMCE as quickly as possible. What's the timeline 
> > of vMCE developing that xen 4.2 could accept?
> 
> Weeks ago, really. See http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
> and follow-ups - we'd really only consider getting the save/restore
> interface into forward compatible shape as acceptable.

Yes it really is far to late to considering entire new features at this
stage.

Ian.

> 
> > I wonder if we could make major 
> > components of vMCE done before xen 4.2 timeline, and leave the surrounding 
> > features and the corner cases done later?
> 
> Unfortunately it's likely going to be even less. However, if split
> that way, chances are things could go into e.g. 4.2.1.
> 
> 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 Jun 28 09:58:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 09:58: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 1SkBUs-00020K-Pp; Thu, 28 Jun 2012 09:58: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 1SkBUq-0001zt-VP
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 09:58:45 +0000
Received: from [85.158.143.35:36765] by server-2.bemta-4.messagelabs.com id
	9D/6D-17938-4DA2CEF4; Thu, 28 Jun 2012 09:58:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340877515!14483856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15784 invoked from network); 28 Jun 2012 09:58:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 09:58:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 09:58:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:58:35 +0100
Message-ID: <1340877513.10942.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 28 Jun 2012 10:58:33 +0100
In-Reply-To: <4FEC463E020000780008C6A7@nat28.tlf.novell.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jinsong Liu <jinsong.liu@intel.com>, Tony Luck <tony.luck@intel.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ashok Raj <ashok.raj@intel.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Donald D
	Dugger <donald.d.dugger@intel.com>, Will Auld <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>, Susie Li <susie.li@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 10:55 +0100, Jan Beulich wrote:
> >>> On 28.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> > So I would like to push new vMCE as quickly as possible. What's the timeline 
> > of vMCE developing that xen 4.2 could accept?
> 
> Weeks ago, really. See http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
> and follow-ups - we'd really only consider getting the save/restore
> interface into forward compatible shape as acceptable.

Yes it really is far to late to considering entire new features at this
stage.

Ian.

> 
> > I wonder if we could make major 
> > components of vMCE done before xen 4.2 timeline, and leave the surrounding 
> > features and the corner cases done later?
> 
> Unfortunately it's likely going to be even less. However, if split
> that way, chances are things could go into e.g. 4.2.1.
> 
> 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 Jun 28 10:08:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:08: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 1SkBdw-0002rE-GR; Thu, 28 Jun 2012 10:08:08 +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 1SkBdv-0002r5-2O
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:08:07 +0000
Received: from [85.158.139.83:20907] by server-9.bemta-5.messagelabs.com id
	4E/DE-01069-60D2CEF4; Thu, 28 Jun 2012 10:08:06 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340878085!25984562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7909 invoked from network); 28 Jun 2012 10:08:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:08:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:08:02 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:08:02 +0100
Message-ID: <4FEC2CD9.3070007@citrix.com>
Date: Thu, 28 Jun 2012 11:07:21 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
	<1340877257.10942.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340877257.10942.21.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-28 at 10:41 +0100, Roger Pau Monne wrote:
>> I think the most suitable place is
>> libxl_create.c:initiate_domain_create, which also sets the defaults for
>> disk devices,
>
> .. by calling setdefaults though.

Yes, sorry.

>
> I'd like to keep all such logic in setdefaults as far as possible.
>
> libxl__devic_nic_setdefautls is an internal function so we can add
> either a domid or type parameter quite easily. Are there any callsites
> which would be unable to provide one or the other of those?
>
> Probably domid is best, with setdefaults calling libxl__domain_type as
> necessary.

I think it would be appropriate to pass domid to every setdefault 
function, even if it's only used by nic now:

libxl__device_disk_setdefault
libxl__device_nic_setdefault
libxl__device_vfb_setdefault
libxl__device_vkb_setdefault
libxl__device_pci_setdefault

To keep the symmetry, are you ok with that?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:08:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:08: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 1SkBdw-0002rE-GR; Thu, 28 Jun 2012 10:08:08 +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 1SkBdv-0002r5-2O
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:08:07 +0000
Received: from [85.158.139.83:20907] by server-9.bemta-5.messagelabs.com id
	4E/DE-01069-60D2CEF4; Thu, 28 Jun 2012 10:08:06 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340878085!25984562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7909 invoked from network); 28 Jun 2012 10:08:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:08:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264660"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:08:02 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:08:02 +0100
Message-ID: <4FEC2CD9.3070007@citrix.com>
Date: Thu, 28 Jun 2012 11:07:21 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
	<1340877257.10942.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340877257.10942.21.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-28 at 10:41 +0100, Roger Pau Monne wrote:
>> I think the most suitable place is
>> libxl_create.c:initiate_domain_create, which also sets the defaults for
>> disk devices,
>
> .. by calling setdefaults though.

Yes, sorry.

>
> I'd like to keep all such logic in setdefaults as far as possible.
>
> libxl__devic_nic_setdefautls is an internal function so we can add
> either a domid or type parameter quite easily. Are there any callsites
> which would be unable to provide one or the other of those?
>
> Probably domid is best, with setdefaults calling libxl__domain_type as
> necessary.

I think it would be appropriate to pass domid to every setdefault 
function, even if it's only used by nic now:

libxl__device_disk_setdefault
libxl__device_nic_setdefault
libxl__device_vfb_setdefault
libxl__device_vkb_setdefault
libxl__device_pci_setdefault

To keep the symmetry, are you ok with that?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBeQ-0002tn-Tn; Thu, 28 Jun 2012 10: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 1SkBeP-0002tW-R6
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:08:37 +0000
Received: from [85.158.138.51:38453] by server-9.bemta-3.messagelabs.com id
	1B/14-10419-42D2CEF4; Thu, 28 Jun 2012 10:08:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340878115!28794377!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24976 invoked from network); 28 Jun 2012 10:08:36 -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;
	28 Jun 2012 10:08:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="200350041"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:08:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:08:34 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkBeM-0006WM-42;
	Thu, 28 Jun 2012 11:08:34 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: seabios@seabios.org
Date: Thu, 28 Jun 2012 11:08:31 +0100
Message-ID: <1340878114-12815-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.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/3] enable Xen support 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 25b2b1b..8120ff7 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -13,7 +13,7 @@ menu "General Features"
     config XEN
         depends on !COREBOOT
         bool "Build for Xen HVM"
-        default n
+        default y
         help
             Configure to be used by xen hvmloader, for a HVM guest.
 
-- 
1.7.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 Jun 28 10:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBeQ-0002tn-Tn; Thu, 28 Jun 2012 10: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 1SkBeP-0002tW-R6
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:08:37 +0000
Received: from [85.158.138.51:38453] by server-9.bemta-3.messagelabs.com id
	1B/14-10419-42D2CEF4; Thu, 28 Jun 2012 10:08:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340878115!28794377!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24976 invoked from network); 28 Jun 2012 10:08:36 -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;
	28 Jun 2012 10:08:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="200350041"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:08:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:08:34 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkBeM-0006WM-42;
	Thu, 28 Jun 2012 11:08:34 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: seabios@seabios.org
Date: Thu, 28 Jun 2012 11:08:31 +0100
Message-ID: <1340878114-12815-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.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/3] enable Xen support 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 25b2b1b..8120ff7 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -13,7 +13,7 @@ menu "General Features"
     config XEN
         depends on !COREBOOT
         bool "Build for Xen HVM"
-        default n
+        default y
         help
             Configure to be used by xen hvmloader, for a HVM guest.
 
-- 
1.7.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 Jun 28 10:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBeS-0002u2-AI; Thu, 28 Jun 2012 10:08:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBeQ-0002tZ-IF
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:08:38 +0000
Received: from [85.158.138.51:38549] by server-6.bemta-3.messagelabs.com id
	85/81-11602-52D2CEF4; Thu, 28 Jun 2012 10:08:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340878115!28794377!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25052 invoked from network); 28 Jun 2012 10:08:37 -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;
	28 Jun 2012 10:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="200350042"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:08:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:08:34 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkBeM-0006WM-60;
	Thu, 28 Jun 2012 11:08:34 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: seabios@seabios.org
Date: Thu, 28 Jun 2012 11:08:32 +0100
Message-ID: <1340878114-12815-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.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 2/3] Xen: Autodetect debug I/O port at runtime
	instead of via Kconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allows a common image which supports Xen to still print debug

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/Kconfig  |    7 -------
 src/output.c |    4 +++-
 src/util.h   |    1 +
 src/xen.c    |    6 ++++++
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 8120ff7..8932c9e 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -361,11 +361,4 @@ menu "Debugging"
             information by outputing strings in a special port present in the
             IO space.
 
-    config DEBUG_IO_PORT
-        depends on DEBUG_IO
-        hex "Debug IO port address"
-        default 0x0402
-        help
-            Bochs uses the 0x0402 address by default, whereas Xen
-            makes the 0xe9 IO address available for guests use.
 endmenu
diff --git a/src/output.c b/src/output.c
index 37c4942..83de7f4 100644
--- a/src/output.c
+++ b/src/output.c
@@ -23,6 +23,8 @@ struct putcinfo {
 
 #define DEBUG_TIMEOUT 100000
 
+u16 DebugOutputPort VAR16VISIBLE = 0x402;
+
 void
 debug_serial_setup(void)
 {
@@ -77,7 +79,7 @@ putc_debug(struct putcinfo *action, char c)
         return;
     if (CONFIG_DEBUG_IO)
         // Send character to debug port.
-        outb(c, CONFIG_DEBUG_IO_PORT);
+        outb(c, GET_GLOBAL(DebugOutputPort));
     if (c == '\n')
         debug_serial('\r');
     debug_serial(c);
diff --git a/src/util.h b/src/util.h
index dbee0e5..ef8ec7c 100644
--- a/src/util.h
+++ b/src/util.h
@@ -231,6 +231,7 @@ int wait_preempt(void);
 void check_preempt(void);
 
 // output.c
+extern u16 DebugOutputPort;
 void debug_serial_setup(void);
 void panic(const char *fmt, ...)
     __attribute__ ((format (printf, 1, 2))) __noreturn;
diff --git a/src/xen.c b/src/xen.c
index b18cca2..41aab98 100644
--- a/src/xen.c
+++ b/src/xen.c
@@ -65,6 +65,10 @@ void xen_probe(void)
         dprintf(1, "Found hypervisor signature \"%s\" at %x\n",
                 signature, base);
         if (strcmp(signature, "XenVMMXenVMM") == 0) {
+            /* Set debug_io_port first, so the following messages work. */
+            DebugOutputPort = 0xe9;
+            dprintf(1, "SeaBIOS (version %s)\n\n", VERSION);
+            dprintf(1, "Found Xen hypervisor signature at %x\n", base);
             if ((eax - base) < 2)
                 panic("Insufficient Xen cpuid leaves. eax=%x at base %x\n",
                       eax, base);
@@ -72,6 +76,8 @@ void xen_probe(void)
             break;
         }
     }
+    if (!xen_cpuid_base)
+        dprintf(1, "No Xen hypervisor found.\n");
 }
 
 static int hypercall_xen_version( int cmd, void *arg)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBeS-0002u2-AI; Thu, 28 Jun 2012 10:08:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBeQ-0002tZ-IF
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:08:38 +0000
Received: from [85.158.138.51:38549] by server-6.bemta-3.messagelabs.com id
	85/81-11602-52D2CEF4; Thu, 28 Jun 2012 10:08:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340878115!28794377!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25052 invoked from network); 28 Jun 2012 10:08:37 -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;
	28 Jun 2012 10:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="200350042"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:08:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:08:34 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkBeM-0006WM-60;
	Thu, 28 Jun 2012 11:08:34 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: seabios@seabios.org
Date: Thu, 28 Jun 2012 11:08:32 +0100
Message-ID: <1340878114-12815-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.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 2/3] Xen: Autodetect debug I/O port at runtime
	instead of via Kconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allows a common image which supports Xen to still print debug

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/Kconfig  |    7 -------
 src/output.c |    4 +++-
 src/util.h   |    1 +
 src/xen.c    |    6 ++++++
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 8120ff7..8932c9e 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -361,11 +361,4 @@ menu "Debugging"
             information by outputing strings in a special port present in the
             IO space.
 
-    config DEBUG_IO_PORT
-        depends on DEBUG_IO
-        hex "Debug IO port address"
-        default 0x0402
-        help
-            Bochs uses the 0x0402 address by default, whereas Xen
-            makes the 0xe9 IO address available for guests use.
 endmenu
diff --git a/src/output.c b/src/output.c
index 37c4942..83de7f4 100644
--- a/src/output.c
+++ b/src/output.c
@@ -23,6 +23,8 @@ struct putcinfo {
 
 #define DEBUG_TIMEOUT 100000
 
+u16 DebugOutputPort VAR16VISIBLE = 0x402;
+
 void
 debug_serial_setup(void)
 {
@@ -77,7 +79,7 @@ putc_debug(struct putcinfo *action, char c)
         return;
     if (CONFIG_DEBUG_IO)
         // Send character to debug port.
-        outb(c, CONFIG_DEBUG_IO_PORT);
+        outb(c, GET_GLOBAL(DebugOutputPort));
     if (c == '\n')
         debug_serial('\r');
     debug_serial(c);
diff --git a/src/util.h b/src/util.h
index dbee0e5..ef8ec7c 100644
--- a/src/util.h
+++ b/src/util.h
@@ -231,6 +231,7 @@ int wait_preempt(void);
 void check_preempt(void);
 
 // output.c
+extern u16 DebugOutputPort;
 void debug_serial_setup(void);
 void panic(const char *fmt, ...)
     __attribute__ ((format (printf, 1, 2))) __noreturn;
diff --git a/src/xen.c b/src/xen.c
index b18cca2..41aab98 100644
--- a/src/xen.c
+++ b/src/xen.c
@@ -65,6 +65,10 @@ void xen_probe(void)
         dprintf(1, "Found hypervisor signature \"%s\" at %x\n",
                 signature, base);
         if (strcmp(signature, "XenVMMXenVMM") == 0) {
+            /* Set debug_io_port first, so the following messages work. */
+            DebugOutputPort = 0xe9;
+            dprintf(1, "SeaBIOS (version %s)\n\n", VERSION);
+            dprintf(1, "Found Xen hypervisor signature at %x\n", base);
             if ((eax - base) < 2)
                 panic("Insufficient Xen cpuid leaves. eax=%x at base %x\n",
                       eax, base);
@@ -72,6 +76,8 @@ void xen_probe(void)
             break;
         }
     }
+    if (!xen_cpuid_base)
+        dprintf(1, "No Xen hypervisor found.\n");
 }
 
 static int hypercall_xen_version( int cmd, void *arg)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:09:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:09: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 1SkBem-0002yR-OP; Thu, 28 Jun 2012 10:09:00 +0000
Resent-Date: Thu, 28 Jun 2012 10:09:00 +0000
Resent-Message-Id: <E1SkBem-0002yR-OP@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBem-0002xH-0F
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:09:00 +0000
Received: from [85.158.138.51:10756] by server-9.bemta-3.messagelabs.com id
	F5/35-10419-B3D2CEF4; Thu, 28 Jun 2012 10:08:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340878139!28794485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26932 invoked from network); 28 Jun 2012 10:08:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:08:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:08:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:08:58 +0100
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "seabios@seabios.org" <seabios@seabios.org>
Thread-Topic: [PATCH 0/3] Fixes for running under Xen
Message-ID: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-evolution-format: text/plain
MIME-Version: 1.0
Resent-From: Ian Campbell <Ian.Campbell@citrix.com>
Resent-To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 11:08:57 +0100
X-Mailer: Evolution 3.2.2-1 
Subject: [Xen-devel] [PATCH 0/3] Fixes for running 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

The following are a few issues discovered in the course of investigating
Debian bug #678042 [0], including the fix for that actual bug (which is
cause by Xen not supporting SMM mode).

The following changes since commit 9166c4ae6d21d49bd97e0fb42eea2ffd6dd6f06d:

  Xen: add definition of xen_hypercall_page (2012-06-27 21:07:24 -0400)

are available in the git repository at:
  git://xenbits.xen.org/people/ianc/seabios.git bugfixes

Ian Campbell (3):
      enable Xen support by default.
      Xen: Autodetect debug I/O port at runtime instead of via Kconfig
      SMM: Disable use of SMM when running under Xen

 src/Kconfig  |    9 +--------
 src/output.c |    4 +++-
 src/smm.c    |    3 +++
 src/util.h   |    1 +
 src/xen.c    |    6 ++++++
 5 files changed, 14 insertions(+), 9 deletions(-)

Thanks,
Ian.

[0] http://bugs.debian.org/678042


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:09:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:09: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 1SkBem-0002yR-OP; Thu, 28 Jun 2012 10:09:00 +0000
Resent-Date: Thu, 28 Jun 2012 10:09:00 +0000
Resent-Message-Id: <E1SkBem-0002yR-OP@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBem-0002xH-0F
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:09:00 +0000
Received: from [85.158.138.51:10756] by server-9.bemta-3.messagelabs.com id
	F5/35-10419-B3D2CEF4; Thu, 28 Jun 2012 10:08:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340878139!28794485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26932 invoked from network); 28 Jun 2012 10:08:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:08:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:08:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:08:58 +0100
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "seabios@seabios.org" <seabios@seabios.org>
Thread-Topic: [PATCH 0/3] Fixes for running under Xen
Message-ID: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-evolution-format: text/plain
MIME-Version: 1.0
Resent-From: Ian Campbell <Ian.Campbell@citrix.com>
Resent-To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 11:08:57 +0100
X-Mailer: Evolution 3.2.2-1 
Subject: [Xen-devel] [PATCH 0/3] Fixes for running 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

The following are a few issues discovered in the course of investigating
Debian bug #678042 [0], including the fix for that actual bug (which is
cause by Xen not supporting SMM mode).

The following changes since commit 9166c4ae6d21d49bd97e0fb42eea2ffd6dd6f06d:

  Xen: add definition of xen_hypercall_page (2012-06-27 21:07:24 -0400)

are available in the git repository at:
  git://xenbits.xen.org/people/ianc/seabios.git bugfixes

Ian Campbell (3):
      enable Xen support by default.
      Xen: Autodetect debug I/O port at runtime instead of via Kconfig
      SMM: Disable use of SMM when running under Xen

 src/Kconfig  |    9 +--------
 src/output.c |    4 +++-
 src/smm.c    |    3 +++
 src/util.h   |    1 +
 src/xen.c    |    6 ++++++
 5 files changed, 14 insertions(+), 9 deletions(-)

Thanks,
Ian.

[0] http://bugs.debian.org/678042


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10: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 1SkBf5-000333-5M; Thu, 28 Jun 2012 10:09:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBf3-00032l-VX
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:09:18 +0000
Received: from [85.158.143.35:65180] by server-3.bemta-4.messagelabs.com id
	F0/C9-05808-D4D2CEF4; Thu, 28 Jun 2012 10:09:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340878115!6675105!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23338 invoked from network); 28 Jun 2012 10:08:36 -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;
	28 Jun 2012 10:08:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="29728539"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:08:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:08:34 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkBeM-0006WM-7u;
	Thu, 28 Jun 2012 11:08:34 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: seabios@seabios.org
Date: Thu, 28 Jun 2012 11:08:33 +0100
Message-ID: <1340878114-12815-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.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/3] SMM: Disable use of SMM when running 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

Xen does not support SMM mode.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/smm.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/smm.c b/src/smm.c
index 72e5e88..d0d1476 100644
--- a/src/smm.c
+++ b/src/smm.c
@@ -10,6 +10,7 @@
 #include "config.h" // CONFIG_*
 #include "ioport.h" // outb
 #include "pci_ids.h" // PCI_VENDOR_ID_INTEL
+#include "xen.h" // usingXen
 
 ASM32FLAT(
     ".global smm_relocation_start\n"
@@ -151,6 +152,8 @@ smm_init(void)
         return;
     if (!CONFIG_USE_SMM)
         return;
+    if (usingXen())
+	return;
 
     dprintf(3, "init smm\n");
     pci_find_init_device(smm_init_tbl, 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 Jun 28 10:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10: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 1SkBf5-000333-5M; Thu, 28 Jun 2012 10:09:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBf3-00032l-VX
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:09:18 +0000
Received: from [85.158.143.35:65180] by server-3.bemta-4.messagelabs.com id
	F0/C9-05808-D4D2CEF4; Thu, 28 Jun 2012 10:09:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340878115!6675105!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23338 invoked from network); 28 Jun 2012 10:08:36 -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;
	28 Jun 2012 10:08:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="29728539"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:08:34 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:08:34 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkBeM-0006WM-7u;
	Thu, 28 Jun 2012 11:08:34 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: seabios@seabios.org
Date: Thu, 28 Jun 2012 11:08:33 +0100
Message-ID: <1340878114-12815-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.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/3] SMM: Disable use of SMM when running 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

Xen does not support SMM mode.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/smm.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/smm.c b/src/smm.c
index 72e5e88..d0d1476 100644
--- a/src/smm.c
+++ b/src/smm.c
@@ -10,6 +10,7 @@
 #include "config.h" // CONFIG_*
 #include "ioport.h" // outb
 #include "pci_ids.h" // PCI_VENDOR_ID_INTEL
+#include "xen.h" // usingXen
 
 ASM32FLAT(
     ".global smm_relocation_start\n"
@@ -151,6 +152,8 @@ smm_init(void)
         return;
     if (!CONFIG_USE_SMM)
         return;
+    if (usingXen())
+	return;
 
     dprintf(3, "init smm\n");
     pci_find_init_device(smm_init_tbl, 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 Jun 28 10:10:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10: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 1SkBgC-0003Id-Kv; Thu, 28 Jun 2012 10:10:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBgA-0003IM-UW
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:10:27 +0000
Received: from [193.109.254.147:65318] by server-4.bemta-14.messagelabs.com id
	A7/93-02077-29D2CEF4; Thu, 28 Jun 2012 10:10:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340878216!2153725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18820 invoked from network); 28 Jun 2012 10:10:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:10:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:10:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:10:13 +0100
Message-ID: <1340878212.10942.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 11:10:12 +0100
In-Reply-To: <4FEC2CD9.3070007@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
	<1340877257.10942.21.camel@zakaz.uk.xensource.com>
	<4FEC2CD9.3070007@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 11:07 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Thu, 2012-06-28 at 10:41 +0100, Roger Pau Monne wrote:
> >> I think the most suitable place is
> >> libxl_create.c:initiate_domain_create, which also sets the defaults for
> >> disk devices,
> >
> > .. by calling setdefaults though.
> 
> Yes, sorry.
> 
> >
> > I'd like to keep all such logic in setdefaults as far as possible.
> >
> > libxl__devic_nic_setdefautls is an internal function so we can add
> > either a domid or type parameter quite easily. Are there any callsites
> > which would be unable to provide one or the other of those?
> >
> > Probably domid is best, with setdefaults calling libxl__domain_type as
> > necessary.
> 
> I think it would be appropriate to pass domid to every setdefault 
> function, even if it's only used by nic now:
> 
> libxl__device_disk_setdefault
> libxl__device_nic_setdefault
> libxl__device_vfb_setdefault
> libxl__device_vkb_setdefault
> libxl__device_pci_setdefault
> 
> To keep the symmetry, are you ok with that?

Lets make that cleanup in 4.3 and just do the necessary 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 Thu Jun 28 10:10:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10: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 1SkBgC-0003Id-Kv; Thu, 28 Jun 2012 10:10:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBgA-0003IM-UW
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:10:27 +0000
Received: from [193.109.254.147:65318] by server-4.bemta-14.messagelabs.com id
	A7/93-02077-29D2CEF4; Thu, 28 Jun 2012 10:10:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1340878216!2153725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18820 invoked from network); 28 Jun 2012 10:10:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:10:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:10:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:10:13 +0100
Message-ID: <1340878212.10942.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 28 Jun 2012 11:10:12 +0100
In-Reply-To: <4FEC2CD9.3070007@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
	<1340877257.10942.21.camel@zakaz.uk.xensource.com>
	<4FEC2CD9.3070007@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF by
 default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 11:07 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Thu, 2012-06-28 at 10:41 +0100, Roger Pau Monne wrote:
> >> I think the most suitable place is
> >> libxl_create.c:initiate_domain_create, which also sets the defaults for
> >> disk devices,
> >
> > .. by calling setdefaults though.
> 
> Yes, sorry.
> 
> >
> > I'd like to keep all such logic in setdefaults as far as possible.
> >
> > libxl__devic_nic_setdefautls is an internal function so we can add
> > either a domid or type parameter quite easily. Are there any callsites
> > which would be unable to provide one or the other of those?
> >
> > Probably domid is best, with setdefaults calling libxl__domain_type as
> > necessary.
> 
> I think it would be appropriate to pass domid to every setdefault 
> function, even if it's only used by nic now:
> 
> libxl__device_disk_setdefault
> libxl__device_nic_setdefault
> libxl__device_vfb_setdefault
> libxl__device_vkb_setdefault
> libxl__device_pci_setdefault
> 
> To keep the symmetry, are you ok with that?

Lets make that cleanup in 4.3 and just do the necessary 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 Thu Jun 28 10:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBi6-0003b4-Dp; Thu, 28 Jun 2012 10:12:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkBi5-0003ah-8L
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:12:25 +0000
Received: from [85.158.138.51:43888] by server-9.bemta-3.messagelabs.com id
	E4/90-10419-80E2CEF4; Thu, 28 Jun 2012 10:12:24 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340878343!30044022!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26988 invoked from network); 28 Jun 2012 10:12:23 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 10:12:23 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79188664; Thu, 28 Jun 2012 12:12:23 +0200
Message-ID: <1340878329.21008.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Thu, 28 Jun 2012 12:12:09 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0548755802828270494=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0548755802828270494==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-urcEBA0ROBoTojz+3cpn"


--=-urcEBA0ROBoTojz+3cpn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 07:25 +0000, Zhang, Yang Z wrote:
> > This all happens internally to libxl, and no API for driving the mechan=
ism is
> > provided for now. This matches what xend already does.
> we should consider the basic IONUMA. I mean when a guest with a device as=
signed,=20
> from the point of view of performance, it's better to allocated the memor=
y from the node=20
> which the device belongs to.
>
That sure makes sense, and it would be a very useful extension!

> Furthermore, we need consider the guest NUMA(I am working on it now) and =
live migration.
>=20
Great. Can you share, either here on or a separate thread some more
details about what you mean by both "guest NUMA" and "live migration" in
this context?

As George said, that would be 4.3 material, but I'm still very
interested. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-urcEBA0ROBoTojz+3cpn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sLfkACgkQk4XaBE3IOsQhGQCeL9c5a/6vJXYr2nsASgj5ci1N
crMAoKF95g11CA5bxh9r/JXsVhkFXndj
=GoZR
-----END PGP SIGNATURE-----

--=-urcEBA0ROBoTojz+3cpn--



--===============0548755802828270494==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0548755802828270494==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 10:12:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBi6-0003b4-Dp; Thu, 28 Jun 2012 10:12:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkBi5-0003ah-8L
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:12:25 +0000
Received: from [85.158.138.51:43888] by server-9.bemta-3.messagelabs.com id
	E4/90-10419-80E2CEF4; Thu, 28 Jun 2012 10:12:24 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340878343!30044022!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26988 invoked from network); 28 Jun 2012 10:12:23 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 10:12:23 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79188664; Thu, 28 Jun 2012 12:12:23 +0200
Message-ID: <1340878329.21008.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Thu, 28 Jun 2012 12:12:09 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0548755802828270494=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0548755802828270494==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-urcEBA0ROBoTojz+3cpn"


--=-urcEBA0ROBoTojz+3cpn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 07:25 +0000, Zhang, Yang Z wrote:
> > This all happens internally to libxl, and no API for driving the mechan=
ism is
> > provided for now. This matches what xend already does.
> we should consider the basic IONUMA. I mean when a guest with a device as=
signed,=20
> from the point of view of performance, it's better to allocated the memor=
y from the node=20
> which the device belongs to.
>
That sure makes sense, and it would be a very useful extension!

> Furthermore, we need consider the guest NUMA(I am working on it now) and =
live migration.
>=20
Great. Can you share, either here on or a separate thread some more
details about what you mean by both "guest NUMA" and "live migration" in
this context?

As George said, that would be 4.3 material, but I'm still very
interested. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-urcEBA0ROBoTojz+3cpn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sLfkACgkQk4XaBE3IOsQhGQCeL9c5a/6vJXYr2nsASgj5ci1N
crMAoKF95g11CA5bxh9r/JXsVhkFXndj
=GoZR
-----END PGP SIGNATURE-----

--=-urcEBA0ROBoTojz+3cpn--



--===============0548755802828270494==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0548755802828270494==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 10:16:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:16: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 1SkBlp-0003z8-8c; Thu, 28 Jun 2012 10:16:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBln-0003z3-6V
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:16:15 +0000
Received: from [193.109.254.147:54023] by server-10.bemta-14.messagelabs.com
	id 1C/61-05433-EEE2CEF4; Thu, 28 Jun 2012 10:16:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340878573!9029440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1581 invoked from network); 28 Jun 2012 10:16:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:16:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:16:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:16:13 +0100
Message-ID: <1340878572.10942.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "seabios@seabios.org" <seabios@seabios.org>
Date: Thu, 28 Jun 2012 11:16:12 +0100
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/3] Fixes for running 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

Sorry, forgot to CC xen-devel on the 0/3 mail, and obviously when I
bounced it to xen-devel it didn't make it into the CC line either.
Please CC both lists if you happen to reply...

On Thu, 2012-06-28 at 11:08 +0100, Ian Campbell wrote:
> The following are a few issues discovered in the course of investigating
> Debian bug #678042 [0], including the fix for that actual bug (which is
> cause by Xen not supporting SMM mode).
> 
> The following changes since commit 9166c4ae6d21d49bd97e0fb42eea2ffd6dd6f06d:
> 
>   Xen: add definition of xen_hypercall_page (2012-06-27 21:07:24 -0400)
> 
> are available in the git repository at:
>   git://xenbits.xen.org/people/ianc/seabios.git bugfixes
> 
> Ian Campbell (3):
>       enable Xen support by default.
>       Xen: Autodetect debug I/O port at runtime instead of via Kconfig
>       SMM: Disable use of SMM when running under Xen
> 
>  src/Kconfig  |    9 +--------
>  src/output.c |    4 +++-
>  src/smm.c    |    3 +++
>  src/util.h   |    1 +
>  src/xen.c    |    6 ++++++
>  5 files changed, 14 insertions(+), 9 deletions(-)
> 
> Thanks,
> Ian.
> 
> [0] http://bugs.debian.org/678042
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 10:16:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:16: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 1SkBlp-0003z8-8c; Thu, 28 Jun 2012 10:16:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkBln-0003z3-6V
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:16:15 +0000
Received: from [193.109.254.147:54023] by server-10.bemta-14.messagelabs.com
	id 1C/61-05433-EEE2CEF4; Thu, 28 Jun 2012 10:16:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340878573!9029440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1581 invoked from network); 28 Jun 2012 10:16:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:16:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:16:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:16:13 +0100
Message-ID: <1340878572.10942.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "seabios@seabios.org" <seabios@seabios.org>
Date: Thu, 28 Jun 2012 11:16:12 +0100
In-Reply-To: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
References: <1340878070.10942.29.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/3] Fixes for running 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

Sorry, forgot to CC xen-devel on the 0/3 mail, and obviously when I
bounced it to xen-devel it didn't make it into the CC line either.
Please CC both lists if you happen to reply...

On Thu, 2012-06-28 at 11:08 +0100, Ian Campbell wrote:
> The following are a few issues discovered in the course of investigating
> Debian bug #678042 [0], including the fix for that actual bug (which is
> cause by Xen not supporting SMM mode).
> 
> The following changes since commit 9166c4ae6d21d49bd97e0fb42eea2ffd6dd6f06d:
> 
>   Xen: add definition of xen_hypercall_page (2012-06-27 21:07:24 -0400)
> 
> are available in the git repository at:
>   git://xenbits.xen.org/people/ianc/seabios.git bugfixes
> 
> Ian Campbell (3):
>       enable Xen support by default.
>       Xen: Autodetect debug I/O port at runtime instead of via Kconfig
>       SMM: Disable use of SMM when running under Xen
> 
>  src/Kconfig  |    9 +--------
>  src/output.c |    4 +++-
>  src/smm.c    |    3 +++
>  src/util.h   |    1 +
>  src/xen.c    |    6 ++++++
>  5 files changed, 14 insertions(+), 9 deletions(-)
> 
> Thanks,
> Ian.
> 
> [0] http://bugs.debian.org/678042
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBpo-00047L-T2; Thu, 28 Jun 2012 10:20:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkBpo-00047C-0T
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:20:24 +0000
Received: from [85.158.139.83:30502] by server-12.bemta-5.messagelabs.com id
	AB/16-25233-7EF2CEF4; Thu, 28 Jun 2012 10:20:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340878822!27235767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2810 invoked from network); 28 Jun 2012 10:20:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:19:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:19:38 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkBp4-0007A4-B0;
	Thu, 28 Jun 2012 10:19:38 +0000
Received: by spongy (Postfix, from userid 2023)	id 07F1434062B; Thu, 28 Jun
	2012 11:19:57 +0100 (BST)
Date: Thu, 28 Jun 2012 11:19:57 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120628101957.GA7935@spongy>
References: <20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120625090537.GC1488@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/06 10:05, Tim Deegan wrote:
> At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > >> On 14/06 03:56, Tim Deegan wrote:
> > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > >> > > Are you talking about having different version of V4V driver run=
ning
> > >> > > in the same VM?
> > >> >
> > >> > Yes.
> > >> >
> > >> > > I don't think that is a problem they both interact with Xen via
> > >> > > hypercall directly so if they follow the v4v hypercall interface=
 it's
> > >> > > all fine.
> > >> >
> > >> > AFAICS if they both try to register the same port then one of them=
 will
> > >> > silently get its ring discarded. =A0And if they both try to commun=
icate
> > >> > with the same remote port their entries on the pending lists will =
get
> > >> > merged (which is probably not too bad). =A0I think the possibility=
 for
> > >> > confusion depends on how you use the service. =A0Still, it seems b=
etter
> > >> > than the xenstore case, anyway. :)
> > >> >
> > >>
> > >> Not silently, register_ring will return an error.
> > >
> > > Will it? =A0It looks to me like v4v_ring_add just clobbers the old MFN
> > > list.
> > >
> > =

> > Ha yes. It does that now but I think it should return an error
> > informing up the stack that a ring has already been registered.
> =

> Actually, I think it's deliberate, to allow a guest to re-register all
> its rings after a suspend/resume or migration, without having to worry
> about whether it was actually migrated into a new domain or not. =

> =


Yes your are right. The driver will still try to register but a correct err=
or
code could tell it weather or not it has been done.


> That raises the question of how a v4v client ought to handle migration;
> doesn't it have to rely on other OS components to notify it that one has
> happened?
>

Migration will cause the connection to close and the event will propagated
up the stack.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBpo-00047L-T2; Thu, 28 Jun 2012 10:20:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkBpo-00047C-0T
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:20:24 +0000
Received: from [85.158.139.83:30502] by server-12.bemta-5.messagelabs.com id
	AB/16-25233-7EF2CEF4; Thu, 28 Jun 2012 10:20:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340878822!27235767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2810 invoked from network); 28 Jun 2012 10:20:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13264990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:19:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:19:38 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkBp4-0007A4-B0;
	Thu, 28 Jun 2012 10:19:38 +0000
Received: by spongy (Postfix, from userid 2023)	id 07F1434062B; Thu, 28 Jun
	2012 11:19:57 +0100 (BST)
Date: Thu, 28 Jun 2012 11:19:57 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120628101957.GA7935@spongy>
References: <20120607114031.GP70339@ocelot.phlegethon.org>
	<20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120625090537.GC1488@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/06 10:05, Tim Deegan wrote:
> At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > >> On 14/06 03:56, Tim Deegan wrote:
> > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > >> > > Are you talking about having different version of V4V driver run=
ning
> > >> > > in the same VM?
> > >> >
> > >> > Yes.
> > >> >
> > >> > > I don't think that is a problem they both interact with Xen via
> > >> > > hypercall directly so if they follow the v4v hypercall interface=
 it's
> > >> > > all fine.
> > >> >
> > >> > AFAICS if they both try to register the same port then one of them=
 will
> > >> > silently get its ring discarded. =A0And if they both try to commun=
icate
> > >> > with the same remote port their entries on the pending lists will =
get
> > >> > merged (which is probably not too bad). =A0I think the possibility=
 for
> > >> > confusion depends on how you use the service. =A0Still, it seems b=
etter
> > >> > than the xenstore case, anyway. :)
> > >> >
> > >>
> > >> Not silently, register_ring will return an error.
> > >
> > > Will it? =A0It looks to me like v4v_ring_add just clobbers the old MFN
> > > list.
> > >
> > =

> > Ha yes. It does that now but I think it should return an error
> > informing up the stack that a ring has already been registered.
> =

> Actually, I think it's deliberate, to allow a guest to re-register all
> its rings after a suspend/resume or migration, without having to worry
> about whether it was actually migrated into a new domain or not. =

> =


Yes your are right. The driver will still try to register but a correct err=
or
code could tell it weather or not it has been done.


> That raises the question of how a v4v client ought to handle migration;
> doesn't it have to rely on other OS components to notify it that one has
> happened?
>

Migration will cause the connection to close and the event will propagated
up the stack.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:29:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkByi-0004Jx-Vt; Thu, 28 Jun 2012 10:29:36 +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 1SkByh-0004Js-Rv
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:29:36 +0000
Received: from [85.158.138.51:46309] by server-6.bemta-3.messagelabs.com id
	8B/77-11602-F023CEF4; Thu, 28 Jun 2012 10:29:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340879372!11299012!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 488 invoked from network); 28 Jun 2012 10:29:34 -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;
	28 Jun 2012 10:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="200351590"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:29:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:29:32 -0400
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 1SkByd-00071N-ST;
	Thu, 28 Jun 2012 11:29:31 +0100
Message-ID: <4FEC320B.7050309@citrix.com>
Date: Thu, 28 Jun 2012 11:29:31 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FEB5AA6.4010403@citrix.com>
	<4FEC454C020000780008C6A4@nat28.tlf.novell.com>
In-Reply-To: <4FEC454C020000780008C6A4@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Logical NUMA error during boot, and RFC 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 28/06/12 10:51, Jan Beulich wrote:
>>>> On 27.06.12 at 21:10, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> XenServer have recently acquired a quad-socket AMD Interlagos server and
>> I have been playing around with it, and discovered a logical error in
>> how Xen detects numa nodes.
>>
>> The server has 8 NUMA nodes, 4 of which have memory attached (the even
>> nodes - see SRAT.dsl attached).  This means that that
>> node_set_online(nodeid) gets called for each node with memory attached. 
>> Later, in srat_detect_node(), node gets set to 0 if it was NUMA_NO_NODE,
>> or if not node_online().  This leads to all the processors on the odd
>> nodes being assigned to node 0, even though the odd nodes are present
>> (see interlagos-xl-info-n.log)
>>
>> I present an RFC patch which changes srat_detect_node() to call
>> node_set_online() for each node, which appears to fix the logic.
>>
>> Is this a sensible place to set the node online, or is there a better
>> way to fix this logic?
> While the place looks sensible, it has the possible problem of
> potentially adding bits to the online map pretty late in the game.
>
> As the memory-related invocations of node_set_online() come
> out of numa_initmem_init()/acpi_scan_nodes(), perhaps the
> (boot time) CPU-related ones should be done there too (I'd
> still keep the adjustment you're already doing, to also cover
> hotplug CPUs)?
>
> Jan
>

I have been doing quite a bit more testing this morning, and have come
to some sad conclusions.

This specific server is a Dell R815 loner, with 8x4GiB DIMMs, with 2
DIMMs hanging off each socket.  As each socket is an interlagos
processor, there are 4 memory controllers (with 8 DIMM slots as they are
dual channel)

What this means is that per socket, one node has half of its available
DIMMs filled, and the other node has no memory.  The performance
implications are severe, but as it appears that almost all combinations
of RAM you can select on the Dell website will leads to poor or worse
performance, I can foresee many systems like this in the future.  (I
don't wish to single Dell out here, other than it happens to be the
provider of the server I am testing.  Other server providers suffer the
same issues)

As to the problem at hand, I will investigate the numa code some more
and see about setting it up earlier.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:29:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkByi-0004Jx-Vt; Thu, 28 Jun 2012 10:29:36 +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 1SkByh-0004Js-Rv
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:29:36 +0000
Received: from [85.158.138.51:46309] by server-6.bemta-3.messagelabs.com id
	8B/77-11602-F023CEF4; Thu, 28 Jun 2012 10:29:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340879372!11299012!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 488 invoked from network); 28 Jun 2012 10:29:34 -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;
	28 Jun 2012 10:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336363200"; d="scan'208";a="200351590"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 06:29:32 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 06:29:32 -0400
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 1SkByd-00071N-ST;
	Thu, 28 Jun 2012 11:29:31 +0100
Message-ID: <4FEC320B.7050309@citrix.com>
Date: Thu, 28 Jun 2012 11:29:31 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120602 Thunderbird/13.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4FEB5AA6.4010403@citrix.com>
	<4FEC454C020000780008C6A4@nat28.tlf.novell.com>
In-Reply-To: <4FEC454C020000780008C6A4@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.2
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Logical NUMA error during boot, and RFC 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 28/06/12 10:51, Jan Beulich wrote:
>>>> On 27.06.12 at 21:10, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> XenServer have recently acquired a quad-socket AMD Interlagos server and
>> I have been playing around with it, and discovered a logical error in
>> how Xen detects numa nodes.
>>
>> The server has 8 NUMA nodes, 4 of which have memory attached (the even
>> nodes - see SRAT.dsl attached).  This means that that
>> node_set_online(nodeid) gets called for each node with memory attached. 
>> Later, in srat_detect_node(), node gets set to 0 if it was NUMA_NO_NODE,
>> or if not node_online().  This leads to all the processors on the odd
>> nodes being assigned to node 0, even though the odd nodes are present
>> (see interlagos-xl-info-n.log)
>>
>> I present an RFC patch which changes srat_detect_node() to call
>> node_set_online() for each node, which appears to fix the logic.
>>
>> Is this a sensible place to set the node online, or is there a better
>> way to fix this logic?
> While the place looks sensible, it has the possible problem of
> potentially adding bits to the online map pretty late in the game.
>
> As the memory-related invocations of node_set_online() come
> out of numa_initmem_init()/acpi_scan_nodes(), perhaps the
> (boot time) CPU-related ones should be done there too (I'd
> still keep the adjustment you're already doing, to also cover
> hotplug CPUs)?
>
> Jan
>

I have been doing quite a bit more testing this morning, and have come
to some sad conclusions.

This specific server is a Dell R815 loner, with 8x4GiB DIMMs, with 2
DIMMs hanging off each socket.  As each socket is an interlagos
processor, there are 4 memory controllers (with 8 DIMM slots as they are
dual channel)

What this means is that per socket, one node has half of its available
DIMMs filled, and the other node has no memory.  The performance
implications are severe, but as it appears that almost all combinations
of RAM you can select on the Dell website will leads to poor or worse
performance, I can foresee many systems like this in the future.  (I
don't wish to single Dell out here, other than it happens to be the
provider of the server I am testing.  Other server providers suffer the
same issues)

As to the problem at hand, I will investigate the numa code some more
and see about setting it up earlier.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBzc-0004Mq-Do; Thu, 28 Jun 2012 10:30: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 1SkBza-0004Mg-Mu
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:30:30 +0000
Received: from [85.158.143.99:49623] by server-2.bemta-4.messagelabs.com id
	CC/8B-17938-5423CEF4; Thu, 28 Jun 2012 10:30:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340879428!24303285!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31682 invoked from network); 28 Jun 2012 10:30: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; 28 Jun 2012 10:30:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkBzV-000A86-QN; Thu, 28 Jun 2012 10:30:25 +0000
Date: Thu, 28 Jun 2012 11:30:25 +0100
From: Tim Deegan <tim@xen.org>
To: "Hao, Xudong" <xudong.hao@intel.com>
Message-ID: <20120628103025.GB34995@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Shan, Haitao" <haitao.shan@intel.com>, "keir@xen.org" <keir@xen.org>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 05:31 +0000 on 26 Jun (1340688686), Hao, Xudong wrote:
> > - Have you measured what difference this makes?  I take it it improves
> >   performance during live migration but it would be good to know how much
> >   before taking on extra code.
> 
> We did live migration performance testing with patches, it's
> embarrassed to say but the result show there is no performance gain
> and no performance loss indeed.

Ah. 

But maybe they have some performance advantage for guests with
graphics-heavy workloads (by making the VRAM tracking faster)?
Could you test that to see if that's the case?

If it's not, I think you'll understand if we don't take these patches.

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 Jun 28 10:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkBzc-0004Mq-Do; Thu, 28 Jun 2012 10:30: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 1SkBza-0004Mg-Mu
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:30:30 +0000
Received: from [85.158.143.99:49623] by server-2.bemta-4.messagelabs.com id
	CC/8B-17938-5423CEF4; Thu, 28 Jun 2012 10:30:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340879428!24303285!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31682 invoked from network); 28 Jun 2012 10:30: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; 28 Jun 2012 10:30:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkBzV-000A86-QN; Thu, 28 Jun 2012 10:30:25 +0000
Date: Thu, 28 Jun 2012 11:30:25 +0100
From: Tim Deegan <tim@xen.org>
To: "Hao, Xudong" <xudong.hao@intel.com>
Message-ID: <20120628103025.GB34995@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Shan, Haitao" <haitao.shan@intel.com>, "keir@xen.org" <keir@xen.org>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 05:31 +0000 on 26 Jun (1340688686), Hao, Xudong wrote:
> > - Have you measured what difference this makes?  I take it it improves
> >   performance during live migration but it would be good to know how much
> >   before taking on extra code.
> 
> We did live migration performance testing with patches, it's
> embarrassed to say but the result show there is no performance gain
> and no performance loss indeed.

Ah. 

But maybe they have some performance advantage for guests with
graphics-heavy workloads (by making the VRAM tracking faster)?
Could you test that to see if that's the case?

If it's not, I think you'll understand if we don't take these patches.

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 Jun 28 10:38:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10: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 1SkC7W-0004j6-Co; Thu, 28 Jun 2012 10:38:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkC7U-0004j1-7y
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:38:40 +0000
Received: from [85.158.143.99:54460] by server-2.bemta-4.messagelabs.com id
	DD/0B-17938-F243CEF4; Thu, 28 Jun 2012 10:38:39 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340879919!24278607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8356 invoked from network); 28 Jun 2012 10:38:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13265515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:38:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:38:39 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkC7S-0007IX-JN;
	Thu, 28 Jun 2012 10:38:38 +0000
Received: by spongy (Postfix, from userid 2023)	id 490BE34062B; Thu, 28 Jun
	2012 11:38:58 +0100 (BST)
Date: Thu, 28 Jun 2012 11:38:58 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628103858.GB7935@spongy>
References: <20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340721486.3832.145.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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/06 03:38, Ian Campbell wrote:
> Hi,
> 
> Sorry it's taken me so long to get round to responding to this.
> 
> On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > >> On 14/06 03:56, Tim Deegan wrote:
> > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > >> > > Are you talking about having different version of V4V driver running
> > > >> > > in the same VM?
> > > >> >
> > > >> > Yes.
> > > >> >
> > > >> > > I don't think that is a problem they both interact with Xen via
> > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > >> > > all fine.
> > > >> >
> > > >> > AFAICS if they both try to register the same port then one of them will
> > > >> > silently get its ring discarded.  And if they both try to communicate
> > > >> > with the same remote port their entries on the pending lists will get
> > > >> > merged (which is probably not too bad).  I think the possibility for
> > > >> > confusion depends on how you use the service.  Still, it seems better
> > > >> > than the xenstore case, anyway. :)
> > > >> >
> > > >>
> > > >> Not silently, register_ring will return an error.
> > > >
> > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > list.
> > > >
> > > 
> > > Ha yes. It does that now but I think it should return an error
> > > informing up the stack that a ring has already been registered.
> > 
> > Actually, I think it's deliberate, to allow a guest to re-register all
> > its rings after a suspend/resume or migration, without having to worry
> > about whether it was actually migrated into a new domain or not. 
> 
> Which takes us back to the original issue Tim asked about with
> cohabitation of multiple (perhaps just plain buggy or even malicious)
> v4v clients in a single domain, doesn't it?
> 

There is nothing wrong the two v4v driver running in the same guest.
The probably that Tim reported was about trying to create two connections
on the same port. Today with the code that I've submited in the RFC
one will overwrite the other silently which isn't a good thing, that can
easily be changed to notify which one got registered up the stack.

> If one of the reasons for not using xenstore is the inability for
> multiple clients to co-exist then there is no point moving to a
> different scheme with the same (even if lesser) issue. Up until now v4v
> has only been used by XenClient so it has avoided this issue but if we
> take it upstream then presumably the potential for this sort of problem
> to creep in comes back.
> 
> Some other things from my notes...
> 
> Can you remind me of the reasoning behind using VIRQ_V4V instead of
> regular event channels? I can't see any reason why these
> shouldn't/couldn't be regular event channels demuxed in the usual way.
> 

No good reason, the virq can be changed to a event channel. We thought
that event channels required other machinery to function. If we can
deal with the event channel in the v4v driver directly I don't have any
problem changing it to a event channel. What I have in mind is if one
would want to use v4v in a rombios for instance where you can't rely
on any of the xen pv driver code to be present.

> Are you going to submit any client code? I think the most important of
> these would be code to make libvchan able to use v4v if it is available
> (and both ends agree), but any other client code (like the sockets
> interface overlay I've heard about) would be interesting to see too.
> 

Yes. I still have to submit the kernel driver code and the v4v library that
talks to it. But now that you've pointed out that we might be able to use
an event channel instead of a virq, I think we might event be able to have
a driver in userspace only.

> Have you had any contact from any one else who is interested in building
> stuff with these interfaces? (This is just curiosity about potential
> wider usage)
> 

Today in XenClient we use this interface for:
  - USB transport between dom0 and guest
  - RPC bus beween dom0 and domU
  - Cross domain Citrix ICA connections.

The good thing that this interface can offer is a transport
for all the existing networking programs. I haven't had
any contact from people interested in building stuff with these
interfaces but I think V4V has quite a lot to offer already in
term of thing at the top that can use it.

> I think you and Tim have been discussing access control -- can we get a
> summary of what this is going to look like going forward. I suppose
> there will be tools for manipulating this stuff -- can you post them?
> 

I'll post a new series this week that will include some of a feedback
and the access control.

> The patches need plenty of documentation adding to them, both in the
> interface docs in xen/include/public (marked up such that it comes out
> nicely in docs/html aka
> http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
> design docs and any other useful material you have under docs itself.
> 

I agree such change need a lot of document. Once we agreed on the interfaces
I will start working on a complete documentation for them. 

> Are we generally happy that we could run e.g. block or net traffic over
> this channel? As it stands for example the single VIRQ would seem to
> provide a scalability limit to how many disks and nics a domain could
> have. Are there any other considerations we need to take into account
> here?
> 
> Lastly -- have you given any thoughts to making the copy operation
> asynchronous? This might allow us to take advantage of copy offload
> hardware in the future?
>

A CPU copy already has to happen once in the guest to put it in the
ring so the second copy that is done in Xen will be really cheap because
it's very linkely going to be in the cache. I don't doing async copy in Xen
will have a huge impact on the performance.

Thanks for taking the time to review.
Jean


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:38:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10: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 1SkC7W-0004j6-Co; Thu, 28 Jun 2012 10:38:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkC7U-0004j1-7y
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:38:40 +0000
Received: from [85.158.143.99:54460] by server-2.bemta-4.messagelabs.com id
	DD/0B-17938-F243CEF4; Thu, 28 Jun 2012 10:38:39 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340879919!24278607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8356 invoked from network); 28 Jun 2012 10:38:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13265515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:38:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:38:39 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkC7S-0007IX-JN;
	Thu, 28 Jun 2012 10:38:38 +0000
Received: by spongy (Postfix, from userid 2023)	id 490BE34062B; Thu, 28 Jun
	2012 11:38:58 +0100 (BST)
Date: Thu, 28 Jun 2012 11:38:58 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628103858.GB7935@spongy>
References: <20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340721486.3832.145.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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/06 03:38, Ian Campbell wrote:
> Hi,
> 
> Sorry it's taken me so long to get round to responding to this.
> 
> On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > >> On 14/06 03:56, Tim Deegan wrote:
> > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > >> > > Are you talking about having different version of V4V driver running
> > > >> > > in the same VM?
> > > >> >
> > > >> > Yes.
> > > >> >
> > > >> > > I don't think that is a problem they both interact with Xen via
> > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > >> > > all fine.
> > > >> >
> > > >> > AFAICS if they both try to register the same port then one of them will
> > > >> > silently get its ring discarded.  And if they both try to communicate
> > > >> > with the same remote port their entries on the pending lists will get
> > > >> > merged (which is probably not too bad).  I think the possibility for
> > > >> > confusion depends on how you use the service.  Still, it seems better
> > > >> > than the xenstore case, anyway. :)
> > > >> >
> > > >>
> > > >> Not silently, register_ring will return an error.
> > > >
> > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > list.
> > > >
> > > 
> > > Ha yes. It does that now but I think it should return an error
> > > informing up the stack that a ring has already been registered.
> > 
> > Actually, I think it's deliberate, to allow a guest to re-register all
> > its rings after a suspend/resume or migration, without having to worry
> > about whether it was actually migrated into a new domain or not. 
> 
> Which takes us back to the original issue Tim asked about with
> cohabitation of multiple (perhaps just plain buggy or even malicious)
> v4v clients in a single domain, doesn't it?
> 

There is nothing wrong the two v4v driver running in the same guest.
The probably that Tim reported was about trying to create two connections
on the same port. Today with the code that I've submited in the RFC
one will overwrite the other silently which isn't a good thing, that can
easily be changed to notify which one got registered up the stack.

> If one of the reasons for not using xenstore is the inability for
> multiple clients to co-exist then there is no point moving to a
> different scheme with the same (even if lesser) issue. Up until now v4v
> has only been used by XenClient so it has avoided this issue but if we
> take it upstream then presumably the potential for this sort of problem
> to creep in comes back.
> 
> Some other things from my notes...
> 
> Can you remind me of the reasoning behind using VIRQ_V4V instead of
> regular event channels? I can't see any reason why these
> shouldn't/couldn't be regular event channels demuxed in the usual way.
> 

No good reason, the virq can be changed to a event channel. We thought
that event channels required other machinery to function. If we can
deal with the event channel in the v4v driver directly I don't have any
problem changing it to a event channel. What I have in mind is if one
would want to use v4v in a rombios for instance where you can't rely
on any of the xen pv driver code to be present.

> Are you going to submit any client code? I think the most important of
> these would be code to make libvchan able to use v4v if it is available
> (and both ends agree), but any other client code (like the sockets
> interface overlay I've heard about) would be interesting to see too.
> 

Yes. I still have to submit the kernel driver code and the v4v library that
talks to it. But now that you've pointed out that we might be able to use
an event channel instead of a virq, I think we might event be able to have
a driver in userspace only.

> Have you had any contact from any one else who is interested in building
> stuff with these interfaces? (This is just curiosity about potential
> wider usage)
> 

Today in XenClient we use this interface for:
  - USB transport between dom0 and guest
  - RPC bus beween dom0 and domU
  - Cross domain Citrix ICA connections.

The good thing that this interface can offer is a transport
for all the existing networking programs. I haven't had
any contact from people interested in building stuff with these
interfaces but I think V4V has quite a lot to offer already in
term of thing at the top that can use it.

> I think you and Tim have been discussing access control -- can we get a
> summary of what this is going to look like going forward. I suppose
> there will be tools for manipulating this stuff -- can you post them?
> 

I'll post a new series this week that will include some of a feedback
and the access control.

> The patches need plenty of documentation adding to them, both in the
> interface docs in xen/include/public (marked up such that it comes out
> nicely in docs/html aka
> http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
> design docs and any other useful material you have under docs itself.
> 

I agree such change need a lot of document. Once we agreed on the interfaces
I will start working on a complete documentation for them. 

> Are we generally happy that we could run e.g. block or net traffic over
> this channel? As it stands for example the single VIRQ would seem to
> provide a scalability limit to how many disks and nics a domain could
> have. Are there any other considerations we need to take into account
> here?
> 
> Lastly -- have you given any thoughts to making the copy operation
> asynchronous? This might allow us to take advantage of copy offload
> hardware in the future?
>

A CPU copy already has to happen once in the guest to put it in the
ring so the second copy that is done in Xen will be really cheap because
it's very linkely going to be in the cache. I don't doing async copy in Xen
will have a huge impact on the performance.

Thanks for taking the time to review.
Jean


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:50:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkCIt-0004v0-O3; Thu, 28 Jun 2012 10:50: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 1SkCIs-0004uv-Lp
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:50:26 +0000
Received: from [85.158.143.35:4492] by server-2.bemta-4.messagelabs.com id
	F1/00-17938-1F63CEF4; Thu, 28 Jun 2012 10:50:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340880624!13853684!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19199 invoked from network); 28 Jun 2012 10:50:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:50:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13265785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:49:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:49:56 +0100
Date: Thu, 28 Jun 2012 11:49:28 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 27 Jun 2012, Rolu wrote:
> > That's because msitranslate is still enabled somehow, that is a
> > toolstack bug.
> > While we fix that bug, could you try this QEMU patch to forcefully disable
> > msitranslate?
> >
> 
> This worked!
> 
> The "unsupported delivery mode" message is gone. Sound works, although
> there is still occasionally a very short stutter, but I expect that's
> a different issue. I've been testing with a KDE desktop with 3D
> effects (cube, expo, that sort of stuff) and performance there has
> gone up noticeably, from around 30-40 fps in most cases to near 60.

Great, good to hear!
Now that we have narrowed down the issue to msitranslate (that should be
disabled by default anyway), I would like to fix it entirely if possible.
Could you please try the appended patch, without any other patches
(therefore msitranslate would still be enabled)?

Thanks for testing!!

---


diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..fc8c49f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -3841,21 +3841,18 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev,
                 PT_LOG("guest enabling MSI, disable MSI-INTx translation\n");
                 pt_disable_msi_translate(ptdev);
             }
-            else
+            /* Init physical one */
+            PT_LOG("setup msi for dev %x\n", pd->devfn);
+            if (pt_msi_setup(ptdev))
             {
-                /* Init physical one */
-                PT_LOG("setup msi for dev %x\n", pd->devfn);
-                if (pt_msi_setup(ptdev))
-                {
-		    /* We do not broadcast the error to the framework code, so
-		     * that MSI errors are contained in MSI emulation code and
-		     * QEMU can go on running.
-		     * Guest MSI would be actually not working.
-		     */
-		    *value &= ~PCI_MSI_FLAGS_ENABLE;
-		    PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
-		    return 0;
-                }
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
+                return 0;
             }
             if (pt_msi_update(ptdev))
             {
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..73f737d 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -263,16 +263,8 @@ void pt_disable_msi_translate(struct pt_dev *dev)
     uint8_t e_device = 0;
     uint8_t e_intx = 0;
 
-    /* MSI_ENABLE bit should be disabed until the new handler is set */
-    msi_set_enable(dev, 0);
-
-    e_device = PCI_SLOT(dev->dev.devfn);
-    e_intx = pci_intx(dev);
-
-    if (xc_domain_unbind_pt_irq(xc_handle, domid, dev->msi->pirq,
-                                 PT_IRQ_TYPE_MSI_TRANSLATE, 0,
-                                 e_device, e_intx, 0))
-        PT_LOG("Error: Unbinding pt irq for MSI-INTx failed!\n");
+    pt_msi_disable(dev);
+    dev->msi->flags |= MSI_FLAG_UNINIT;
 
     if (dev->machine_irq)
     {
@@ -280,8 +272,6 @@ void pt_disable_msi_translate(struct pt_dev *dev)
                                        0, e_device, e_intx))
             PT_LOG("Error: Rebinding of interrupt failed!\n");
     }
-
-    dev->msi_trans_en = 0;
 }
 
 static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:50:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkCIt-0004v0-O3; Thu, 28 Jun 2012 10:50: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 1SkCIs-0004uv-Lp
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:50:26 +0000
Received: from [85.158.143.35:4492] by server-2.bemta-4.messagelabs.com id
	F1/00-17938-1F63CEF4; Thu, 28 Jun 2012 10:50:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340880624!13853684!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19199 invoked from network); 28 Jun 2012 10:50:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 10:50:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13265785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:49:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 11:49:56 +0100
Date: Thu, 28 Jun 2012 11:49:28 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 27 Jun 2012, Rolu wrote:
> > That's because msitranslate is still enabled somehow, that is a
> > toolstack bug.
> > While we fix that bug, could you try this QEMU patch to forcefully disable
> > msitranslate?
> >
> 
> This worked!
> 
> The "unsupported delivery mode" message is gone. Sound works, although
> there is still occasionally a very short stutter, but I expect that's
> a different issue. I've been testing with a KDE desktop with 3D
> effects (cube, expo, that sort of stuff) and performance there has
> gone up noticeably, from around 30-40 fps in most cases to near 60.

Great, good to hear!
Now that we have narrowed down the issue to msitranslate (that should be
disabled by default anyway), I would like to fix it entirely if possible.
Could you please try the appended patch, without any other patches
(therefore msitranslate would still be enabled)?

Thanks for testing!!

---


diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..fc8c49f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -3841,21 +3841,18 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev,
                 PT_LOG("guest enabling MSI, disable MSI-INTx translation\n");
                 pt_disable_msi_translate(ptdev);
             }
-            else
+            /* Init physical one */
+            PT_LOG("setup msi for dev %x\n", pd->devfn);
+            if (pt_msi_setup(ptdev))
             {
-                /* Init physical one */
-                PT_LOG("setup msi for dev %x\n", pd->devfn);
-                if (pt_msi_setup(ptdev))
-                {
-		    /* We do not broadcast the error to the framework code, so
-		     * that MSI errors are contained in MSI emulation code and
-		     * QEMU can go on running.
-		     * Guest MSI would be actually not working.
-		     */
-		    *value &= ~PCI_MSI_FLAGS_ENABLE;
-		    PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
-		    return 0;
-                }
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
+                return 0;
             }
             if (pt_msi_update(ptdev))
             {
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..73f737d 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -263,16 +263,8 @@ void pt_disable_msi_translate(struct pt_dev *dev)
     uint8_t e_device = 0;
     uint8_t e_intx = 0;
 
-    /* MSI_ENABLE bit should be disabed until the new handler is set */
-    msi_set_enable(dev, 0);
-
-    e_device = PCI_SLOT(dev->dev.devfn);
-    e_intx = pci_intx(dev);
-
-    if (xc_domain_unbind_pt_irq(xc_handle, domid, dev->msi->pirq,
-                                 PT_IRQ_TYPE_MSI_TRANSLATE, 0,
-                                 e_device, e_intx, 0))
-        PT_LOG("Error: Unbinding pt irq for MSI-INTx failed!\n");
+    pt_msi_disable(dev);
+    dev->msi->flags |= MSI_FLAG_UNINIT;
 
     if (dev->machine_irq)
     {
@@ -280,8 +272,6 @@ void pt_disable_msi_translate(struct pt_dev *dev)
                                        0, e_device, e_intx))
             PT_LOG("Error: Rebinding of interrupt failed!\n");
     }
-
-    dev->msi_trans_en = 0;
 }
 
 static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 10:50:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:50:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCJ4-0004vR-3o; Thu, 28 Jun 2012 10:50: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 1SkCJ2-0004vK-If
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:50:36 +0000
Received: from [85.158.139.83:42077] by server-11.bemta-5.messagelabs.com id
	4C/B1-20400-BF63CEF4; Thu, 28 Jun 2012 10:50:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340880634!22599880!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21338 invoked from network); 28 Jun 2012 10:50:35 -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; 28 Jun 2012 10:50:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCIz-000AO5-24; Thu, 28 Jun 2012 10:50:33 +0000
Date: Thu, 28 Jun 2012 11:50:33 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120628105033.GC34995@ocelot.phlegethon.org>
References: <20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120628103858.GB7935@spongy>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 11:38 +0100 on 28 Jun (1340883538), Jean Guyader wrote:
> On 26/06 03:38, Ian Campbell wrote:
> > Lastly -- have you given any thoughts to making the copy operation
> > asynchronous? This might allow us to take advantage of copy offload
> > hardware in the future?
> 
> A CPU copy already has to happen once in the guest to put it in the
> ring

I don't understand -- isn't the vector-send operation designed to have
Xen do a single copy from scattered sources into the destination ring?
So the sender could be zero-copy?

> so the second copy that is done in Xen will be really cheap because
> it's very linkely going to be in the cache.  I don't doing async copy
> in Xen will have a huge impact on the performance.

Using a DMA engine to do the copy could free up CPU cycles that Xen
could use for other vcpus, so even if there isn't a throughput increase
on the v4v channel, there could be a benefit to the system as a whole.
We could do that with synchronous copies, pausing the vcpu while the
copy happens, but I think to get full throughput we'd want to pipeline a
few writes ahead.

Anyway, that's all very forward-looking: AFAICS there's no need to
address it right now except to be careful not to bake things into the
interface that would stop us doing this later on.

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 Jun 28 10:50:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 10:50:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCJ4-0004vR-3o; Thu, 28 Jun 2012 10:50: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 1SkCJ2-0004vK-If
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 10:50:36 +0000
Received: from [85.158.139.83:42077] by server-11.bemta-5.messagelabs.com id
	4C/B1-20400-BF63CEF4; Thu, 28 Jun 2012 10:50:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340880634!22599880!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21338 invoked from network); 28 Jun 2012 10:50:35 -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; 28 Jun 2012 10:50:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCIz-000AO5-24; Thu, 28 Jun 2012 10:50:33 +0000
Date: Thu, 28 Jun 2012 11:50:33 +0100
From: Tim Deegan <tim@xen.org>
To: Jean Guyader <jean.guyader@citrix.com>
Message-ID: <20120628105033.GC34995@ocelot.phlegethon.org>
References: <20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120628103858.GB7935@spongy>
User-Agent: Mutt/1.4.2.1i
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 11:38 +0100 on 28 Jun (1340883538), Jean Guyader wrote:
> On 26/06 03:38, Ian Campbell wrote:
> > Lastly -- have you given any thoughts to making the copy operation
> > asynchronous? This might allow us to take advantage of copy offload
> > hardware in the future?
> 
> A CPU copy already has to happen once in the guest to put it in the
> ring

I don't understand -- isn't the vector-send operation designed to have
Xen do a single copy from scattered sources into the destination ring?
So the sender could be zero-copy?

> so the second copy that is done in Xen will be really cheap because
> it's very linkely going to be in the cache.  I don't doing async copy
> in Xen will have a huge impact on the performance.

Using a DMA engine to do the copy could free up CPU cycles that Xen
could use for other vcpus, so even if there isn't a throughput increase
on the v4v channel, there could be a benefit to the system as a whole.
We could do that with synchronous copies, pausing the vcpu while the
copy happens, but I think to get full throughput we'd want to pipeline a
few writes ahead.

Anyway, that's all very forward-looking: AFAICS there's no need to
address it right now except to be careful not to bake things into the
interface that would stop us doing this later on.

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 Jun 28 11:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkCSN-0005Eq-63; Thu, 28 Jun 2012 11:00:15 +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 1SkCSL-0005Ei-Bm
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:00:13 +0000
Received: from [85.158.143.99:35141] by server-3.bemta-4.messagelabs.com id
	F3/4D-05808-C393CEF4; Thu, 28 Jun 2012 11:00:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340881209!23178614!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6986 invoked from network); 28 Jun 2012 11:00:09 -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 Jun 2012 11:00:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCSG-000AVX-3e; Thu, 28 Jun 2012 11:00:08 +0000
Date: Thu, 28 Jun 2012 12:00:08 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110008.GD34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-17-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-17-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 17/40] arm: implement vpl011 (UART)
	emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:29 +0000 on 26 Jun (1340706581), Ian Campbell wrote:
> This is not interended to provide a full emulation, but rather just enough to
> satisfy the use made by Linux' boot time decompressor code (which is too early
> for DT etc)
> 
> 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 Jun 28 11:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkCSN-0005Eq-63; Thu, 28 Jun 2012 11:00:15 +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 1SkCSL-0005Ei-Bm
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:00:13 +0000
Received: from [85.158.143.99:35141] by server-3.bemta-4.messagelabs.com id
	F3/4D-05808-C393CEF4; Thu, 28 Jun 2012 11:00:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340881209!23178614!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6986 invoked from network); 28 Jun 2012 11:00:09 -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 Jun 2012 11:00:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCSG-000AVX-3e; Thu, 28 Jun 2012 11:00:08 +0000
Date: Thu, 28 Jun 2012 12:00:08 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110008.GD34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-17-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-17-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 17/40] arm: implement vpl011 (UART)
	emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:29 +0000 on 26 Jun (1340706581), Ian Campbell wrote:
> This is not interended to provide a full emulation, but rather just enough to
> satisfy the use made by Linux' boot time decompressor code (which is too early
> for DT etc)
> 
> 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 Jun 28 11:02:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkCUg-0005KC-NS; Thu, 28 Jun 2012 11:02: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 1SkCUf-0005K5-RQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:02:37 +0000
Received: from [85.158.143.35:48845] by server-1.bemta-4.messagelabs.com id
	F3/7A-24392-DC93CEF4; Thu, 28 Jun 2012 11:02:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340881353!6688322!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31824 invoked from network); 28 Jun 2012 11:02:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 11:02:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCUa-000AXJ-S0; Thu, 28 Jun 2012 11:02:32 +0000
Date: Thu, 28 Jun 2012 12:02:32 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110232.GE34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-28-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-28-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 28/40] arm: enable data-cache at the same
	time as enabling the MMU, not before
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:29 +0000 on 26 Jun (1340706592), Ian Campbell wrote:
> With enough warnings enabled the model seemed to be complaining that pages
> cached before paging was enabled had been mapped with to inconsistent sets of
> attributes. I'm not convinced that isn't a model issue, nor am I convinced
> this has really fixed anything, but it seems sensible enough.
> 
> 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 Jun 28 11:02:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkCUg-0005KC-NS; Thu, 28 Jun 2012 11:02: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 1SkCUf-0005K5-RQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:02:37 +0000
Received: from [85.158.143.35:48845] by server-1.bemta-4.messagelabs.com id
	F3/7A-24392-DC93CEF4; Thu, 28 Jun 2012 11:02:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340881353!6688322!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31824 invoked from network); 28 Jun 2012 11:02:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 11:02:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCUa-000AXJ-S0; Thu, 28 Jun 2012 11:02:32 +0000
Date: Thu, 28 Jun 2012 12:02:32 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110232.GE34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-28-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-28-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 28/40] arm: enable data-cache at the same
	time as enabling the MMU, not before
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:29 +0000 on 26 Jun (1340706592), Ian Campbell wrote:
> With enough warnings enabled the model seemed to be complaining that pages
> cached before paging was enabled had been mapped with to inconsistent sets of
> attributes. I'm not convinced that isn't a model issue, nor am I convinced
> this has really fixed anything, but it seems sensible enough.
> 
> 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 Jun 28 11:05:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCXe-0005ZW-AB; Thu, 28 Jun 2012 11:05:42 +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 1SkCXc-0005ZO-V0
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:05:41 +0000
Received: from [85.158.143.99:18730] by server-3.bemta-4.messagelabs.com id
	1B/E8-05808-48A3CEF4; Thu, 28 Jun 2012 11:05:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340881538!24311088!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13205 invoked from network); 28 Jun 2012 11:05:39 -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; 28 Jun 2012 11:05:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCXa-000Aa1-D3; Thu, 28 Jun 2012 11:05:38 +0000
Date: Thu, 28 Jun 2012 12:05:38 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110538.GF34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-33-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-33-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 33/40] arm: unwind allocations etc on
	arch_domain_create_failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:29 +0000 on 26 Jun (1340706597), Ian Campbell wrote:
> This involves adding the necessary teardown/free functions for some modules.
> 
> Don't initialise full arch domain state for the idle domain, it's not needed.
> 
> 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 Jun 28 11:05:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCXe-0005ZW-AB; Thu, 28 Jun 2012 11:05:42 +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 1SkCXc-0005ZO-V0
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:05:41 +0000
Received: from [85.158.143.99:18730] by server-3.bemta-4.messagelabs.com id
	1B/E8-05808-48A3CEF4; Thu, 28 Jun 2012 11:05:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340881538!24311088!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13205 invoked from network); 28 Jun 2012 11:05:39 -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; 28 Jun 2012 11:05:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCXa-000Aa1-D3; Thu, 28 Jun 2012 11:05:38 +0000
Date: Thu, 28 Jun 2012 12:05:38 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110538.GF34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-33-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-33-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 33/40] arm: unwind allocations etc on
	arch_domain_create_failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:29 +0000 on 26 Jun (1340706597), Ian Campbell wrote:
> This involves adding the necessary teardown/free functions for some modules.
> 
> Don't initialise full arch domain state for the idle domain, it's not needed.
> 
> 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 Jun 28 11:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCYj-0005ed-Ok; Thu, 28 Jun 2012 11:06:49 +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 1SkCYi-0005eP-1x
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:06:48 +0000
Received: from [85.158.143.99:43711] by server-3.bemta-4.messagelabs.com id
	CD/2B-05808-7CA3CEF4; Thu, 28 Jun 2012 11:06:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340881606!19785463!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1542 invoked from network); 28 Jun 2012 11:06:46 -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 Jun 2012 11:06:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCYg-000Aaz-Bo; Thu, 28 Jun 2012 11:06:46 +0000
Date: Thu, 28 Jun 2012 12:06:46 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110646.GG34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-37-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-37-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 37/40] arm: implement VGCF_online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 +0000 on 26 Jun (1340706601), 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 Jun 28 11:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCYj-0005ed-Ok; Thu, 28 Jun 2012 11:06:49 +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 1SkCYi-0005eP-1x
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:06:48 +0000
Received: from [85.158.143.99:43711] by server-3.bemta-4.messagelabs.com id
	CD/2B-05808-7CA3CEF4; Thu, 28 Jun 2012 11:06:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340881606!19785463!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1542 invoked from network); 28 Jun 2012 11:06:46 -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 Jun 2012 11:06:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkCYg-000Aaz-Bo; Thu, 28 Jun 2012 11:06:46 +0000
Date: Thu, 28 Jun 2012 12:06:46 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120628110646.GG34995@ocelot.phlegethon.org>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-37-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340706604-1313-37-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 37/40] arm: implement VGCF_online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 +0000 on 26 Jun (1340706601), 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 Jun 28 11:24:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:24: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 1SkCpX-0005vs-DB; Thu, 28 Jun 2012 11:24:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkCpW-0005vn-Q3
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:24:11 +0000
Received: from [85.158.138.51:3669] by server-10.bemta-3.messagelabs.com id
	3D/B2-01753-9DE3CEF4; Thu, 28 Jun 2012 11:24:09 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340882648!25945581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10210 invoked from network); 28 Jun 2012 11:24:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:24:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13266872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:24:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 12:24:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkCpU-0007bf-Br;
	Thu, 28 Jun 2012 11:24:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 1E6DB340F57; Thu, 28 Jun
	2012 12:24:28 +0100 (BST)
Date: Thu, 28 Jun 2012 12:24:28 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120628112428.GA15863@spongy>
References: <20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<20120628105033.GC34995@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120628105033.GC34995@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 11:50, Tim Deegan wrote:
> At 11:38 +0100 on 28 Jun (1340883538), Jean Guyader wrote:
> > On 26/06 03:38, Ian Campbell wrote:
> > > Lastly -- have you given any thoughts to making the copy operation
> > > asynchronous? This might allow us to take advantage of copy offload
> > > hardware in the future?
> > 
> > A CPU copy already has to happen once in the guest to put it in the
> > ring
> 
> I don't understand -- isn't the vector-send operation designed to have
> Xen do a single copy from scattered sources into the destination ring?
> So the sender could be zero-copy?
> 

Yes sorry that is right. On send a get a pointer from the guest
and then Xen memcpy the data on the receiver's ring.

So the second copy that will probably happened between the ring
and some memory in the receiver will be mostly free.

> > so the second copy that is done in Xen will be really cheap because
> > it's very linkely going to be in the cache.  I don't doing async copy
> > in Xen will have a huge impact on the performance.
> 
> Using a DMA engine to do the copy could free up CPU cycles that Xen
> could use for other vcpus, so even if there isn't a throughput increase
> on the v4v channel, there could be a benefit to the system as a whole.
> We could do that with synchronous copies, pausing the vcpu while the
> copy happens, but I think to get full throughput we'd want to pipeline a
> few writes ahead.
> 

Maybe if you ring is big enough and if the guest sends very big buffer to be
copied that will makes sence to use async copy like i/oat or DMA.

> Anyway, that's all very forward-looking: AFAICS there's no need to
> address it right now except to be careful not to bake things into the
> interface that would stop us doing this later on.
> 


Jean


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 11:24:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:24: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 1SkCpX-0005vs-DB; Thu, 28 Jun 2012 11:24:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkCpW-0005vn-Q3
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:24:11 +0000
Received: from [85.158.138.51:3669] by server-10.bemta-3.messagelabs.com id
	3D/B2-01753-9DE3CEF4; Thu, 28 Jun 2012 11:24:09 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340882648!25945581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10210 invoked from network); 28 Jun 2012 11:24:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:24:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13266872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:24:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 12:24:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkCpU-0007bf-Br;
	Thu, 28 Jun 2012 11:24:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 1E6DB340F57; Thu, 28 Jun
	2012 12:24:28 +0100 (BST)
Date: Thu, 28 Jun 2012 12:24:28 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120628112428.GA15863@spongy>
References: <20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<20120628105033.GC34995@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120628105033.GC34995@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 11:50, Tim Deegan wrote:
> At 11:38 +0100 on 28 Jun (1340883538), Jean Guyader wrote:
> > On 26/06 03:38, Ian Campbell wrote:
> > > Lastly -- have you given any thoughts to making the copy operation
> > > asynchronous? This might allow us to take advantage of copy offload
> > > hardware in the future?
> > 
> > A CPU copy already has to happen once in the guest to put it in the
> > ring
> 
> I don't understand -- isn't the vector-send operation designed to have
> Xen do a single copy from scattered sources into the destination ring?
> So the sender could be zero-copy?
> 

Yes sorry that is right. On send a get a pointer from the guest
and then Xen memcpy the data on the receiver's ring.

So the second copy that will probably happened between the ring
and some memory in the receiver will be mostly free.

> > so the second copy that is done in Xen will be really cheap because
> > it's very linkely going to be in the cache.  I don't doing async copy
> > in Xen will have a huge impact on the performance.
> 
> Using a DMA engine to do the copy could free up CPU cycles that Xen
> could use for other vcpus, so even if there isn't a throughput increase
> on the v4v channel, there could be a benefit to the system as a whole.
> We could do that with synchronous copies, pausing the vcpu while the
> copy happens, but I think to get full throughput we'd want to pipeline a
> few writes ahead.
> 

Maybe if you ring is big enough and if the guest sends very big buffer to be
copied that will makes sence to use async copy like i/oat or DMA.

> Anyway, that's all very forward-looking: AFAICS there's no need to
> address it right now except to be careful not to bake things into the
> interface that would stop us doing this later on.
> 


Jean


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 11:24:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCpz-0005xg-Pz; Thu, 28 Jun 2012 11:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkCpy-0005xX-OS
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:24:38 +0000
Received: from [85.158.143.35:43012] by server-3.bemta-4.messagelabs.com id
	44/6D-05808-6FE3CEF4; Thu, 28 Jun 2012 11:24:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340882677!16082387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22855 invoked from network); 28 Jun 2012 11:24:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:24:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13266885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:24:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 12:24:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkCpv-0007bo-6Z; Thu, 28 Jun 2012 11:24:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkCpv-0001RJ-3r;
	Thu, 28 Jun 2012 12:24:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.16115.51503.221162@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 12:24:35 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPM6F=gKB4hGi1JZqkuvYzcOmv8-SfLJODRC5Ls0kkiuUQ@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
	<20459.11730.332905.175948@mariner.uk.xensource.com>
	<CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
	<CAP8mzPM6F=gKB4hGi1JZqkuvYzcOmv8-SfLJODRC5Ls0kkiuUQ@mail.gmail.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 v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> Btw, my earlier mail was in response to remus not
> working on the baseline setup on your dev environment.

Right, thanks.

> The fix works for 2 out of 3 cases
>  blackhole replication (xl remus -b)
>  localhost replication with failover i.e. destroy primary (xl remus domU localhost)

Good.

> However, it crashes the guest for localhost replication, when I destroy the backup
> i.e. xl destroy domU--incoming . The primary guest would generally resume, but in this
> case its in --sc- state.
> NB: This seems to happen in baseline xen-unstable too!.

So in this case my series, with the fixup patch I sent, is no worse
than baseline xen-unstable ?

In that case I think the best thing would probably be for me to resend
my series with the fixups integrated, and commit it to xen-unstable
while we look into the remus problems.  Would that be OK with you ?

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 Jun 28 11:24:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkCpz-0005xg-Pz; Thu, 28 Jun 2012 11:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkCpy-0005xX-OS
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:24:38 +0000
Received: from [85.158.143.35:43012] by server-3.bemta-4.messagelabs.com id
	44/6D-05808-6FE3CEF4; Thu, 28 Jun 2012 11:24:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340882677!16082387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22855 invoked from network); 28 Jun 2012 11:24:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:24:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,490,1336348800"; d="scan'208";a="13266885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:24:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 12:24:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkCpv-0007bo-6Z; Thu, 28 Jun 2012 11:24:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkCpv-0001RJ-3r;
	Thu, 28 Jun 2012 12:24:35 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.16115.51503.221162@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 12:24:35 +0100
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPM6F=gKB4hGi1JZqkuvYzcOmv8-SfLJODRC5Ls0kkiuUQ@mail.gmail.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20457.63648.864838.199205@mariner.uk.xensource.com>
	<CAP8mzPNS34tci-dTM0ucsWQyR9exxjD8WqksYvUEO7H7HMgQmg@mail.gmail.com>
	<CAP8mzPO2GWc26Sd72zjrRUYQ5kgod=DbOeTRLSH3DtEbtc-taQ@mail.gmail.com>
	<20459.3767.440030.931642@mariner.uk.xensource.com>
	<20459.11730.332905.175948@mariner.uk.xensource.com>
	<CAP8mzPOLED3CTHh4_YfqXcb0MF4WGdsPWM_1JX4MktS_4OU6vQ@mail.gmail.com>
	<CAP8mzPM6F=gKB4hGi1JZqkuvYzcOmv8-SfLJODRC5Ls0kkiuUQ@mail.gmail.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 v5 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [PATCH v5 00/21] libxl: domain save/restore: run in a separate process"):
> Btw, my earlier mail was in response to remus not
> working on the baseline setup on your dev environment.

Right, thanks.

> The fix works for 2 out of 3 cases
>  blackhole replication (xl remus -b)
>  localhost replication with failover i.e. destroy primary (xl remus domU localhost)

Good.

> However, it crashes the guest for localhost replication, when I destroy the backup
> i.e. xl destroy domU--incoming . The primary guest would generally resume, but in this
> case its in --sc- state.
> NB: This seems to happen in baseline xen-unstable too!.

So in this case my series, with the fixup patch I sent, is no worse
than baseline xen-unstable ?

In that case I think the best thing would probably be for me to resend
my series with the fixups integrated, and commit it to xen-unstable
while we look into the remus problems.  Would that be OK with you ?

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 Jun 28 11:34:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkCzK-0006Hw-Vr; Thu, 28 Jun 2012 11:34: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 1SkCzJ-0006Hn-C9
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:34:17 +0000
Received: from [193.109.254.147:52876] by server-7.bemta-14.messagelabs.com id
	83/16-29827-8314CEF4; Thu, 28 Jun 2012 11:34:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340883255!8858193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2317 invoked from network); 28 Jun 2012 11:34:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:34:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 12:34:14 +0100
Message-ID: <1340883253.10942.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 12:34:13 +0100
In-Reply-To: <20120628103858.GB7935@spongy>
References: <20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> On 26/06 03:38, Ian Campbell wrote:
> > Hi,
> > 
> > Sorry it's taken me so long to get round to responding to this.
> > 
> > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > >> > > Are you talking about having different version of V4V driver running
> > > > >> > > in the same VM?
> > > > >> >
> > > > >> > Yes.
> > > > >> >
> > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > >> > > all fine.
> > > > >> >
> > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > >> > with the same remote port their entries on the pending lists will get
> > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > >> > than the xenstore case, anyway. :)
> > > > >> >
> > > > >>
> > > > >> Not silently, register_ring will return an error.
> > > > >
> > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > list.
> > > > >
> > > > 
> > > > Ha yes. It does that now but I think it should return an error
> > > > informing up the stack that a ring has already been registered.
> > > 
> > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > its rings after a suspend/resume or migration, without having to worry
> > > about whether it was actually migrated into a new domain or not. 
> > 
> > Which takes us back to the original issue Tim asked about with
> > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > v4v clients in a single domain, doesn't it?
> > 
> 
> There is nothing wrong the two v4v driver running in the same guest.
> The probably that Tim reported was about trying to create two connections
> on the same port. Today with the code that I've submited in the RFC
> one will overwrite the other silently which isn't a good thing, that can
> easily be changed to notify which one got registered up the stack.

So they'd somehow need to randomise (and retry) their use of source
ports in order to co-exist?

Speaking of ports, is there a registry somewhere of the well known port
numbers and/or any scheme for administering these? (a text file in the
repo would be find by me).

> > If one of the reasons for not using xenstore is the inability for
> > multiple clients to co-exist then there is no point moving to a
> > different scheme with the same (even if lesser) issue. Up until now v4v
> > has only been used by XenClient so it has avoided this issue but if we
> > take it upstream then presumably the potential for this sort of problem
> > to creep in comes back.
> > 
> > Some other things from my notes...
> > 
> > Can you remind me of the reasoning behind using VIRQ_V4V instead of
> > regular event channels? I can't see any reason why these
> > shouldn't/couldn't be regular event channels demuxed in the usual way.
> > 
> 
> No good reason, the virq can be changed to a event channel. We thought
> that event channels required other machinery to function. If we can
> deal with the event channel in the v4v driver directly I don't have any
> problem changing it to a event channel. What I have in mind is if one
> would want to use v4v in a rombios for instance where you can't rely
> on any of the xen pv driver code to be present.

I think that will be ok -- under the hood a VIRQ is just an evtchn too
so if you can make the VIRQ work you can a regular evtchn work too.

> > Are you going to submit any client code? I think the most important of
> > these would be code to make libvchan able to use v4v if it is available
> > (and both ends agree), but any other client code (like the sockets
> > interface overlay I've heard about) would be interesting to see too.
> > 
> 
> Yes. I still have to submit the kernel driver code and the v4v library that
> talks to it. But now that you've pointed out that we might be able to use
> an event channel instead of a virq, I think we might event be able to have
> a driver in userspace only.

That would be a nice property to have!

> > The patches need plenty of documentation adding to them, both in the
> > interface docs in xen/include/public (marked up such that it comes out
> > nicely in docs/html aka
> > http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
> > design docs and any other useful material you have under docs itself.
> > 
> 
> I agree such change need a lot of document. Once we agreed on the interfaces
> I will start working on a complete documentation for 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 Thu Jun 28 11:34:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkCzK-0006Hw-Vr; Thu, 28 Jun 2012 11:34: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 1SkCzJ-0006Hn-C9
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:34:17 +0000
Received: from [193.109.254.147:52876] by server-7.bemta-14.messagelabs.com id
	83/16-29827-8314CEF4; Thu, 28 Jun 2012 11:34:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340883255!8858193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2317 invoked from network); 28 Jun 2012 11:34:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:34:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 12:34:14 +0100
Message-ID: <1340883253.10942.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 12:34:13 +0100
In-Reply-To: <20120628103858.GB7935@spongy>
References: <20120607153657.GX70339@ocelot.phlegethon.org>
	<20120613104858.GC23207@boiler.cam.xci-test.com>
	<20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> On 26/06 03:38, Ian Campbell wrote:
> > Hi,
> > 
> > Sorry it's taken me so long to get round to responding to this.
> > 
> > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > >> > > Are you talking about having different version of V4V driver running
> > > > >> > > in the same VM?
> > > > >> >
> > > > >> > Yes.
> > > > >> >
> > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > >> > > all fine.
> > > > >> >
> > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > >> > with the same remote port their entries on the pending lists will get
> > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > >> > than the xenstore case, anyway. :)
> > > > >> >
> > > > >>
> > > > >> Not silently, register_ring will return an error.
> > > > >
> > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > list.
> > > > >
> > > > 
> > > > Ha yes. It does that now but I think it should return an error
> > > > informing up the stack that a ring has already been registered.
> > > 
> > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > its rings after a suspend/resume or migration, without having to worry
> > > about whether it was actually migrated into a new domain or not. 
> > 
> > Which takes us back to the original issue Tim asked about with
> > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > v4v clients in a single domain, doesn't it?
> > 
> 
> There is nothing wrong the two v4v driver running in the same guest.
> The probably that Tim reported was about trying to create two connections
> on the same port. Today with the code that I've submited in the RFC
> one will overwrite the other silently which isn't a good thing, that can
> easily be changed to notify which one got registered up the stack.

So they'd somehow need to randomise (and retry) their use of source
ports in order to co-exist?

Speaking of ports, is there a registry somewhere of the well known port
numbers and/or any scheme for administering these? (a text file in the
repo would be find by me).

> > If one of the reasons for not using xenstore is the inability for
> > multiple clients to co-exist then there is no point moving to a
> > different scheme with the same (even if lesser) issue. Up until now v4v
> > has only been used by XenClient so it has avoided this issue but if we
> > take it upstream then presumably the potential for this sort of problem
> > to creep in comes back.
> > 
> > Some other things from my notes...
> > 
> > Can you remind me of the reasoning behind using VIRQ_V4V instead of
> > regular event channels? I can't see any reason why these
> > shouldn't/couldn't be regular event channels demuxed in the usual way.
> > 
> 
> No good reason, the virq can be changed to a event channel. We thought
> that event channels required other machinery to function. If we can
> deal with the event channel in the v4v driver directly I don't have any
> problem changing it to a event channel. What I have in mind is if one
> would want to use v4v in a rombios for instance where you can't rely
> on any of the xen pv driver code to be present.

I think that will be ok -- under the hood a VIRQ is just an evtchn too
so if you can make the VIRQ work you can a regular evtchn work too.

> > Are you going to submit any client code? I think the most important of
> > these would be code to make libvchan able to use v4v if it is available
> > (and both ends agree), but any other client code (like the sockets
> > interface overlay I've heard about) would be interesting to see too.
> > 
> 
> Yes. I still have to submit the kernel driver code and the v4v library that
> talks to it. But now that you've pointed out that we might be able to use
> an event channel instead of a virq, I think we might event be able to have
> a driver in userspace only.

That would be a nice property to have!

> > The patches need plenty of documentation adding to them, both in the
> > interface docs in xen/include/public (marked up such that it comes out
> > nicely in docs/html aka
> > http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
> > design docs and any other useful material you have under docs itself.
> > 
> 
> I agree such change need a lot of document. Once we agreed on the interfaces
> I will start working on a complete documentation for 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 Thu Jun 28 11:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkD7i-0006XR-4E; Thu, 28 Jun 2012 11:42:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkD7h-0006XM-5n
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:42:57 +0000
Received: from [193.109.254.147:9639] by server-8.bemta-14.messagelabs.com id
	7E/1B-30743-0434CEF4; Thu, 28 Jun 2012 11:42:56 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340883775!9015474!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16496 invoked from network); 28 Jun 2012 11:42:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:42:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:42:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 12:42:55 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkD7f-0007kh-6D;
	Thu, 28 Jun 2012 11:42:55 +0000
Received: by spongy (Postfix, from userid 2023)	id EDF7C340F57; Thu, 28 Jun
	2012 12:43:14 +0100 (BST)
Date: Thu, 28 Jun 2012 12:43:14 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628114314.GB15863@spongy>
References: <20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340883253.10942.38.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 12:34, Ian Campbell wrote:
> On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > On 26/06 03:38, Ian Campbell wrote:
> > > Hi,
> > > 
> > > Sorry it's taken me so long to get round to responding to this.
> > > 
> > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > >> > > in the same VM?
> > > > > >> >
> > > > > >> > Yes.
> > > > > >> >
> > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > >> > > all fine.
> > > > > >> >
> > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > >> > than the xenstore case, anyway. :)
> > > > > >> >
> > > > > >>
> > > > > >> Not silently, register_ring will return an error.
> > > > > >
> > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > list.
> > > > > >
> > > > > 
> > > > > Ha yes. It does that now but I think it should return an error
> > > > > informing up the stack that a ring has already been registered.
> > > > 
> > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > its rings after a suspend/resume or migration, without having to worry
> > > > about whether it was actually migrated into a new domain or not. 
> > > 
> > > Which takes us back to the original issue Tim asked about with
> > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > v4v clients in a single domain, doesn't it?
> > > 
> > 
> > There is nothing wrong the two v4v driver running in the same guest.
> > The probably that Tim reported was about trying to create two connections
> > on the same port. Today with the code that I've submited in the RFC
> > one will overwrite the other silently which isn't a good thing, that can
> > easily be changed to notify which one got registered up the stack.
> 
> So they'd somehow need to randomise (and retry) their use of source
> ports in order to co-exist?
>

That can be assimilated to two userspace programs trying to bind to the
same TCP port. I think it's not v4v's responsability to solve this problem.

> Speaking of ports, is there a registry somewhere of the well known port
> numbers and/or any scheme for administering these? (a text file in the
> repo would be find by me).
> 

Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
then for the rest we can have a file in the repo to reference them.

> > > If one of the reasons for not using xenstore is the inability for
> > > multiple clients to co-exist then there is no point moving to a
> > > different scheme with the same (even if lesser) issue. Up until now v4v
> > > has only been used by XenClient so it has avoided this issue but if we
> > > take it upstream then presumably the potential for this sort of problem
> > > to creep in comes back.
> > > 
> > > Some other things from my notes...
> > > 
> > > Can you remind me of the reasoning behind using VIRQ_V4V instead of
> > > regular event channels? I can't see any reason why these
> > > shouldn't/couldn't be regular event channels demuxed in the usual way.
> > > 
> > 
> > No good reason, the virq can be changed to a event channel. We thought
> > that event channels required other machinery to function. If we can
> > deal with the event channel in the v4v driver directly I don't have any
> > problem changing it to a event channel. What I have in mind is if one
> > would want to use v4v in a rombios for instance where you can't rely
> > on any of the xen pv driver code to be present.
> 
> I think that will be ok -- under the hood a VIRQ is just an evtchn too
> so if you can make the VIRQ work you can a regular evtchn work too.
> 
> > > Are you going to submit any client code? I think the most important of
> > > these would be code to make libvchan able to use v4v if it is available
> > > (and both ends agree), but any other client code (like the sockets
> > > interface overlay I've heard about) would be interesting to see too.
> > > 
> > 
> > Yes. I still have to submit the kernel driver code and the v4v library that
> > talks to it. But now that you've pointed out that we might be able to use
> > an event channel instead of a virq, I think we might event be able to have
> > a driver in userspace only.
> 
> That would be a nice property to have!
> 
> > > The patches need plenty of documentation adding to them, both in the
> > > interface docs in xen/include/public (marked up such that it comes out
> > > nicely in docs/html aka
> > > http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
> > > design docs and any other useful material you have under docs itself.
> > > 
> > 
> > I agree such change need a lot of document. Once we agreed on the interfaces
> > I will start working on a complete documentation for them. 
> 
> Thanks!
> 

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 11:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11: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 1SkD7i-0006XR-4E; Thu, 28 Jun 2012 11:42:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkD7h-0006XM-5n
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:42:57 +0000
Received: from [193.109.254.147:9639] by server-8.bemta-14.messagelabs.com id
	7E/1B-30743-0434CEF4; Thu, 28 Jun 2012 11:42:56 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340883775!9015474!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16496 invoked from network); 28 Jun 2012 11:42:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:42:55 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:42:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 12:42:55 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkD7f-0007kh-6D;
	Thu, 28 Jun 2012 11:42:55 +0000
Received: by spongy (Postfix, from userid 2023)	id EDF7C340F57; Thu, 28 Jun
	2012 12:43:14 +0100 (BST)
Date: Thu, 28 Jun 2012 12:43:14 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628114314.GB15863@spongy>
References: <20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340883253.10942.38.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 12:34, Ian Campbell wrote:
> On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > On 26/06 03:38, Ian Campbell wrote:
> > > Hi,
> > > 
> > > Sorry it's taken me so long to get round to responding to this.
> > > 
> > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > >> > > in the same VM?
> > > > > >> >
> > > > > >> > Yes.
> > > > > >> >
> > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > >> > > all fine.
> > > > > >> >
> > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > >> > than the xenstore case, anyway. :)
> > > > > >> >
> > > > > >>
> > > > > >> Not silently, register_ring will return an error.
> > > > > >
> > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > list.
> > > > > >
> > > > > 
> > > > > Ha yes. It does that now but I think it should return an error
> > > > > informing up the stack that a ring has already been registered.
> > > > 
> > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > its rings after a suspend/resume or migration, without having to worry
> > > > about whether it was actually migrated into a new domain or not. 
> > > 
> > > Which takes us back to the original issue Tim asked about with
> > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > v4v clients in a single domain, doesn't it?
> > > 
> > 
> > There is nothing wrong the two v4v driver running in the same guest.
> > The probably that Tim reported was about trying to create two connections
> > on the same port. Today with the code that I've submited in the RFC
> > one will overwrite the other silently which isn't a good thing, that can
> > easily be changed to notify which one got registered up the stack.
> 
> So they'd somehow need to randomise (and retry) their use of source
> ports in order to co-exist?
>

That can be assimilated to two userspace programs trying to bind to the
same TCP port. I think it's not v4v's responsability to solve this problem.

> Speaking of ports, is there a registry somewhere of the well known port
> numbers and/or any scheme for administering these? (a text file in the
> repo would be find by me).
> 

Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
then for the rest we can have a file in the repo to reference them.

> > > If one of the reasons for not using xenstore is the inability for
> > > multiple clients to co-exist then there is no point moving to a
> > > different scheme with the same (even if lesser) issue. Up until now v4v
> > > has only been used by XenClient so it has avoided this issue but if we
> > > take it upstream then presumably the potential for this sort of problem
> > > to creep in comes back.
> > > 
> > > Some other things from my notes...
> > > 
> > > Can you remind me of the reasoning behind using VIRQ_V4V instead of
> > > regular event channels? I can't see any reason why these
> > > shouldn't/couldn't be regular event channels demuxed in the usual way.
> > > 
> > 
> > No good reason, the virq can be changed to a event channel. We thought
> > that event channels required other machinery to function. If we can
> > deal with the event channel in the v4v driver directly I don't have any
> > problem changing it to a event channel. What I have in mind is if one
> > would want to use v4v in a rombios for instance where you can't rely
> > on any of the xen pv driver code to be present.
> 
> I think that will be ok -- under the hood a VIRQ is just an evtchn too
> so if you can make the VIRQ work you can a regular evtchn work too.
> 
> > > Are you going to submit any client code? I think the most important of
> > > these would be code to make libvchan able to use v4v if it is available
> > > (and both ends agree), but any other client code (like the sockets
> > > interface overlay I've heard about) would be interesting to see too.
> > > 
> > 
> > Yes. I still have to submit the kernel driver code and the v4v library that
> > talks to it. But now that you've pointed out that we might be able to use
> > an event channel instead of a virq, I think we might event be able to have
> > a driver in userspace only.
> 
> That would be a nice property to have!
> 
> > > The patches need plenty of documentation adding to them, both in the
> > > interface docs in xen/include/public (marked up such that it comes out
> > > nicely in docs/html aka
> > > http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
> > > design docs and any other useful material you have under docs itself.
> > > 
> > 
> > I agree such change need a lot of document. Once we agreed on the interfaces
> > I will start working on a complete documentation for them. 
> 
> Thanks!
> 

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 11:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:46: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 1SkDBD-0006dc-P4; Thu, 28 Jun 2012 11: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 1SkDBC-0006dX-VV
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:46:35 +0000
Received: from [85.158.143.99:36251] by server-2.bemta-4.messagelabs.com id
	CD/46-17938-A144CEF4; Thu, 28 Jun 2012 11:46:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340883993!19794013!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32407 invoked from network); 28 Jun 2012 11:46:33 -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 Jun 2012 11:46:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkDB9-000B5l-HN; Thu, 28 Jun 2012 11:46:31 +0000
Date: Thu, 28 Jun 2012 12:46:31 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120628114631.GI34995@ocelot.phlegethon.org>
References: <b3a8ef4c556cc9a2d310.1340117300@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b3a8ef4c556cc9a2d310.1340117300@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Clean up unshare path for foreign
	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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:48 -0400 on 19 Jun (1340102900), Andres Lagar-Cavilla wrote:
> In its current shape, if Xen unshares a foreign gfn successfully while building
> a foreign writable map, it is left with a reference to the old shared page in
> the "target" var.
> 
> Instead, push unsharing request down on the initial get_page_from_gfn call,
> which will DTRT.
> 
> This allows for greatly simplifying the unshare related condition handling,
> removing ugly comments and s86_64 ifdef-ery.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 11:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:46: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 1SkDBD-0006dc-P4; Thu, 28 Jun 2012 11: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 1SkDBC-0006dX-VV
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:46:35 +0000
Received: from [85.158.143.99:36251] by server-2.bemta-4.messagelabs.com id
	CD/46-17938-A144CEF4; Thu, 28 Jun 2012 11:46:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340883993!19794013!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32407 invoked from network); 28 Jun 2012 11:46:33 -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 Jun 2012 11:46:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkDB9-000B5l-HN; Thu, 28 Jun 2012 11:46:31 +0000
Date: Thu, 28 Jun 2012 12:46:31 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120628114631.GI34995@ocelot.phlegethon.org>
References: <b3a8ef4c556cc9a2d310.1340117300@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b3a8ef4c556cc9a2d310.1340117300@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Clean up unshare path for foreign
	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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:48 -0400 on 19 Jun (1340102900), Andres Lagar-Cavilla wrote:
> In its current shape, if Xen unshares a foreign gfn successfully while building
> a foreign writable map, it is left with a reference to the old shared page in
> the "target" var.
> 
> Instead, push unsharing request down on the initial get_page_from_gfn call,
> which will DTRT.
> 
> This allows for greatly simplifying the unshare related condition handling,
> removing ugly comments and s86_64 ifdef-ery.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 11:59:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:59: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 1SkDNF-0006qT-2V; Thu, 28 Jun 2012 11:59: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 1SkDND-0006qO-OL
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:58:59 +0000
Received: from [85.158.143.35:54501] by server-3.bemta-4.messagelabs.com id
	42/FC-05808-3074CEF4; Thu, 28 Jun 2012 11:58:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340884738!13870812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20819 invoked from network); 28 Jun 2012 11:58:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:58:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11: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.213.0;
	Thu, 28 Jun 2012 12:58:55 +0100
Message-ID: <1340884734.10942.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 12:58:54 +0100
In-Reply-To: <20120628114314.GB15863@spongy>
References: <20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> On 28/06 12:34, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > On 26/06 03:38, Ian Campbell wrote:
> > > > Hi,
> > > > 
> > > > Sorry it's taken me so long to get round to responding to this.
> > > > 
> > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > >> > > in the same VM?
> > > > > > >> >
> > > > > > >> > Yes.
> > > > > > >> >
> > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > >> > > all fine.
> > > > > > >> >
> > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > >> > than the xenstore case, anyway. :)
> > > > > > >> >
> > > > > > >>
> > > > > > >> Not silently, register_ring will return an error.
> > > > > > >
> > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > list.
> > > > > > >
> > > > > > 
> > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > informing up the stack that a ring has already been registered.
> > > > > 
> > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > about whether it was actually migrated into a new domain or not. 
> > > > 
> > > > Which takes us back to the original issue Tim asked about with
> > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > v4v clients in a single domain, doesn't it?
> > > > 
> > > 
> > > There is nothing wrong the two v4v driver running in the same guest.
> > > The probably that Tim reported was about trying to create two connections
> > > on the same port. Today with the code that I've submited in the RFC
> > > one will overwrite the other silently which isn't a good thing, that can
> > > easily be changed to notify which one got registered up the stack.
> > 
> > So they'd somehow need to randomise (and retry) their use of source
> > ports in order to co-exist?
> >
> 
> That can be assimilated to two userspace programs trying to bind to the
> same TCP port. I think it's not v4v's responsability to solve this problem.

An application using TCP doesn't need to worry about choosing its own
source port though.

Or does this only effect destination / listening ports?

> 
> > Speaking of ports, is there a registry somewhere of the well known port
> > numbers and/or any scheme for administering these? (a text file in the
> > repo would be find by me).
> > 
> 
> Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
> then for the rest we can have a file in the repo to reference them.

OK.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 11:59:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 11:59: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 1SkDNF-0006qT-2V; Thu, 28 Jun 2012 11:59: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 1SkDND-0006qO-OL
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 11:58:59 +0000
Received: from [85.158.143.35:54501] by server-3.bemta-4.messagelabs.com id
	42/FC-05808-3074CEF4; Thu, 28 Jun 2012 11:58:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340884738!13870812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20819 invoked from network); 28 Jun 2012 11:58:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 11:58:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11: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.213.0;
	Thu, 28 Jun 2012 12:58:55 +0100
Message-ID: <1340884734.10942.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 12:58:54 +0100
In-Reply-To: <20120628114314.GB15863@spongy>
References: <20120613114427.GA21809@ocelot.phlegethon.org>
	<CAEBdQ93xnCFQzGTAsizYEVq+nUUp-xqnRJ_aoqt6pojD7MTc-Q@mail.gmail.com>
	<20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> On 28/06 12:34, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > On 26/06 03:38, Ian Campbell wrote:
> > > > Hi,
> > > > 
> > > > Sorry it's taken me so long to get round to responding to this.
> > > > 
> > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > >> > > in the same VM?
> > > > > > >> >
> > > > > > >> > Yes.
> > > > > > >> >
> > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > >> > > all fine.
> > > > > > >> >
> > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > >> > than the xenstore case, anyway. :)
> > > > > > >> >
> > > > > > >>
> > > > > > >> Not silently, register_ring will return an error.
> > > > > > >
> > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > list.
> > > > > > >
> > > > > > 
> > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > informing up the stack that a ring has already been registered.
> > > > > 
> > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > about whether it was actually migrated into a new domain or not. 
> > > > 
> > > > Which takes us back to the original issue Tim asked about with
> > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > v4v clients in a single domain, doesn't it?
> > > > 
> > > 
> > > There is nothing wrong the two v4v driver running in the same guest.
> > > The probably that Tim reported was about trying to create two connections
> > > on the same port. Today with the code that I've submited in the RFC
> > > one will overwrite the other silently which isn't a good thing, that can
> > > easily be changed to notify which one got registered up the stack.
> > 
> > So they'd somehow need to randomise (and retry) their use of source
> > ports in order to co-exist?
> >
> 
> That can be assimilated to two userspace programs trying to bind to the
> same TCP port. I think it's not v4v's responsability to solve this problem.

An application using TCP doesn't need to worry about choosing its own
source port though.

Or does this only effect destination / listening ports?

> 
> > Speaking of ports, is there a registry somewhere of the well known port
> > numbers and/or any scheme for administering these? (a text file in the
> > repo would be find by me).
> > 
> 
> Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
> then for the rest we can have a file in the repo to reference them.

OK.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:05:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkDT1-0007G5-Hd; Thu, 28 Jun 2012 12:04:59 +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 1SkDT0-0007Fy-BQ
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:04:58 +0000
Received: from [193.109.254.147:33638] by server-12.bemta-14.messagelabs.com
	id 19/31-30461-9684CEF4; Thu, 28 Jun 2012 12:04:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340885096!8865578!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29105 invoked from network); 28 Jun 2012 12:04:56 -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; 28 Jun 2012 12:04:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkDSy-000BJd-2y; Thu, 28 Jun 2012 12:04:56 +0000
Date: Thu, 28 Jun 2012 13:04:56 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628120456.GJ34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<b4e1fec1c98f6cbad666.1340816248@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b4e1fec1c98f6cbad666.1340816248@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 4] xen,pod: Cosmetic code motion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:57 +0100 on 27 Jun (1340819848), George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1340815810 -3600
> # Node ID b4e1fec1c98f6cbad666a972f473854518c25500
> # Parent  b91ef972029ddaa110af6463171715ab9070c9d8
> xen,pod: Cosmetic code motion
> 
> No point in doing the assignment if we're just going to crash anyway.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:05:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkDT1-0007G5-Hd; Thu, 28 Jun 2012 12:04:59 +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 1SkDT0-0007Fy-BQ
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:04:58 +0000
Received: from [193.109.254.147:33638] by server-12.bemta-14.messagelabs.com
	id 19/31-30461-9684CEF4; Thu, 28 Jun 2012 12:04:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340885096!8865578!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29105 invoked from network); 28 Jun 2012 12:04:56 -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; 28 Jun 2012 12:04:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkDSy-000BJd-2y; Thu, 28 Jun 2012 12:04:56 +0000
Date: Thu, 28 Jun 2012 13:04:56 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628120456.GJ34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<b4e1fec1c98f6cbad666.1340816248@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b4e1fec1c98f6cbad666.1340816248@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 4] xen,pod: Cosmetic code motion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:57 +0100 on 27 Jun (1340819848), George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1340815810 -3600
> # Node ID b4e1fec1c98f6cbad666a972f473854518c25500
> # Parent  b91ef972029ddaa110af6463171715ab9070c9d8
> xen,pod: Cosmetic code motion
> 
> No point in doing the assignment if we're just going to crash anyway.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12: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 1SkDYx-0007WJ-VI; Thu, 28 Jun 2012 12:11:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkDYv-0007WD-Ib
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:11:05 +0000
Received: from [85.158.143.35:29512] by server-1.bemta-4.messagelabs.com id
	1E/38-24392-8D94CEF4; Thu, 28 Jun 2012 12:11:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340885457!7134928!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15194 invoked from network); 28 Jun 2012 12:11:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:11:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 12:10:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 13:10:37 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkDYT-0007tl-7n;
	Thu, 28 Jun 2012 12:10:37 +0000
Received: by spongy (Postfix, from userid 2023)	id 0A92A340F57; Thu, 28 Jun
	2012 13:10:56 +0100 (BST)
Date: Thu, 28 Jun 2012 13:10:56 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628121056.GC15863@spongy>
References: <20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340884734.10942.39.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 12:58, Ian Campbell wrote:
> On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > On 28/06 12:34, Ian Campbell wrote:
> > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > Hi,
> > > > > 
> > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > 
> > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > >> > > in the same VM?
> > > > > > > >> >
> > > > > > > >> > Yes.
> > > > > > > >> >
> > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > >> > > all fine.
> > > > > > > >> >
> > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > >
> > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > list.
> > > > > > > >
> > > > > > > 
> > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > informing up the stack that a ring has already been registered.
> > > > > > 
> > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > 
> > > > > Which takes us back to the original issue Tim asked about with
> > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > v4v clients in a single domain, doesn't it?
> > > > > 
> > > > 
> > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > The probably that Tim reported was about trying to create two connections
> > > > on the same port. Today with the code that I've submited in the RFC
> > > > one will overwrite the other silently which isn't a good thing, that can
> > > > easily be changed to notify which one got registered up the stack.
> > > 
> > > So they'd somehow need to randomise (and retry) their use of source
> > > ports in order to co-exist?
> > >
> > 
> > That can be assimilated to two userspace programs trying to bind to the
> > same TCP port. I think it's not v4v's responsability to solve this problem.
> 
> An application using TCP doesn't need to worry about choosing its own
> source port though.
> 
> Or does this only effect destination / listening ports?
> 

The guest v4v driver knows which port are in used so if you put port 0
we will pick a random unused number for the source port.

Jean

> > 
> > > Speaking of ports, is there a registry somewhere of the well known port
> > > numbers and/or any scheme for administering these? (a text file in the
> > > repo would be find by me).
> > > 
> > 
> > Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
> > then for the rest we can have a file in the repo to reference them.
> 
> OK.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12: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 1SkDYx-0007WJ-VI; Thu, 28 Jun 2012 12:11:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkDYv-0007WD-Ib
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:11:05 +0000
Received: from [85.158.143.35:29512] by server-1.bemta-4.messagelabs.com id
	1E/38-24392-8D94CEF4; Thu, 28 Jun 2012 12:11:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340885457!7134928!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15194 invoked from network); 28 Jun 2012 12:11:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:11:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13267985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 12:10:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 13:10:37 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkDYT-0007tl-7n;
	Thu, 28 Jun 2012 12:10:37 +0000
Received: by spongy (Postfix, from userid 2023)	id 0A92A340F57; Thu, 28 Jun
	2012 13:10:56 +0100 (BST)
Date: Thu, 28 Jun 2012 13:10:56 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628121056.GC15863@spongy>
References: <20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340884734.10942.39.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 12:58, Ian Campbell wrote:
> On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > On 28/06 12:34, Ian Campbell wrote:
> > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > Hi,
> > > > > 
> > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > 
> > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > >> > > in the same VM?
> > > > > > > >> >
> > > > > > > >> > Yes.
> > > > > > > >> >
> > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > >> > > all fine.
> > > > > > > >> >
> > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > >
> > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > list.
> > > > > > > >
> > > > > > > 
> > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > informing up the stack that a ring has already been registered.
> > > > > > 
> > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > 
> > > > > Which takes us back to the original issue Tim asked about with
> > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > v4v clients in a single domain, doesn't it?
> > > > > 
> > > > 
> > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > The probably that Tim reported was about trying to create two connections
> > > > on the same port. Today with the code that I've submited in the RFC
> > > > one will overwrite the other silently which isn't a good thing, that can
> > > > easily be changed to notify which one got registered up the stack.
> > > 
> > > So they'd somehow need to randomise (and retry) their use of source
> > > ports in order to co-exist?
> > >
> > 
> > That can be assimilated to two userspace programs trying to bind to the
> > same TCP port. I think it's not v4v's responsability to solve this problem.
> 
> An application using TCP doesn't need to worry about choosing its own
> source port though.
> 
> Or does this only effect destination / listening ports?
> 

The guest v4v driver knows which port are in used so if you put port 0
we will pick a random unused number for the source port.

Jean

> > 
> > > Speaking of ports, is there a registry somewhere of the well known port
> > > numbers and/or any scheme for administering these? (a text file in the
> > > repo would be find by me).
> > > 
> > 
> > Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
> > then for the rest we can have a file in the repo to reference them.
> 
> OK.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:15:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:15: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 1SkDch-0007gV-Kz; Thu, 28 Jun 2012 12:14:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SkDcf-0007gM-PI
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:14:57 +0000
Received: from [85.158.143.99:16339] by server-3.bemta-4.messagelabs.com id
	08/5C-05808-1CA4CEF4; Thu, 28 Jun 2012 12:14:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340885695!22539108!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3495 invoked from network); 28 Jun 2012 12:14:56 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:14:56 -0000
Received: by qcab12 with SMTP id b12so167330qca.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 05:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=KHyTtFNuiZyVczd2hkdZFwbyTp2XpAPqFa1VYt1Rxpk=;
	b=Y0EIxVORS5mBQcnRGUW3BzMP5x1knRosmJ88pGpbwFuOtUaPuISabeJsToqR6qO6Pa
	pytgeax2Euff6gQdYGjQUHk0YQnR45DaEe1QtR43j+TPiX4GW2bWGFFbtKLpPT454lCm
	ZYYLqkSdlFYR+SDFZfSgjiVXtfsJYAIvk82paDolYWGywQ5Q5z/uL9QQVKAIweIDtv9N
	ghEUhlNf+bMzd5Z+/Q03QLr0waOxQVYMQvfK4qpMM68u9sGBq6VcJem7Eu3hb7U9fTNg
	VvW8rlfOgmsRUeBCoMdQgIcHpEcIP1q/5w7JgNQnb5TP8tXHxtLNekPbDOP4uBkOEto7
	gc9Q==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr2928474qap.6.1340885694609; Thu,
	28 Jun 2012 05:14:54 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 05:14:54 -0700 (PDT)
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
Date: Thu, 28 Jun 2012 13:14:54 +0100
X-Google-Sender-Auth: j4DYrQyye1dFiNet7b8XBo3l5co
Message-ID: <CAFLBxZab3z3aSbD-qBAsS_-rW5_6mdOmnucBNnKYF4T9UtV6QQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 26, 2012 at 6:31 AM, Hao, Xudong <xudong.hao@intel.com> wrote:
>> -----Original Message-----
>> From: Tim Deegan [mailto:tim@xen.org]
>> Sent: Monday, June 25, 2012 5:02 PM
>> To: Hao, Xudong
>> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
>> JBeulich@suse.com
>> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
>>
>> At 09:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
>> > Changes from v1:
>> > - Move hap_has_dirty_bit and hap_has_access_bit definition from patch =
3 to
>> patch2.
>> > - define them as bool_t instead of int.
>> >
>> > Extended Page Tables introduce two bit: access bit and dirty bit, A/D =
bits
>> > enable VMMs to efficiently implement memory management and page
>> classification
>> > algorithms to optimize VM memory operations.
>> >
>> > This series of patches enable EPT dirty bit feature for guest live mig=
ration.
>>
>> Thanks for this. =A0I have a few high-level questions:
>>
>> - You're proposing this for after 4.2, right?
>>
>
> Yes, they are not targeted to 4.2.
>
>> - Have you measured what difference this makes? =A0I take it it improves
>> =A0 performance during live migration but it would be good to know how m=
uch
>> =A0 before taking on extra code.
>>
>
> We did live migration performance testing with patches, it's embarrassed =
to say but the result show there is no performance gain and no performance =
loss indeed.

What exactly did you measure?  If you measured the speed of the
migration itself on an empty system, it might not be noticeable; but
if, for instance, it increased the performance of a workload running
*inside* the guest during the migration, or if it decreased the cpu
usage of qemu during the migraiton, that might be worth it.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:15:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:15: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 1SkDch-0007gV-Kz; Thu, 28 Jun 2012 12:14:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SkDcf-0007gM-PI
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:14:57 +0000
Received: from [85.158.143.99:16339] by server-3.bemta-4.messagelabs.com id
	08/5C-05808-1CA4CEF4; Thu, 28 Jun 2012 12:14:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340885695!22539108!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3495 invoked from network); 28 Jun 2012 12:14:56 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:14:56 -0000
Received: by qcab12 with SMTP id b12so167330qca.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 05:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=KHyTtFNuiZyVczd2hkdZFwbyTp2XpAPqFa1VYt1Rxpk=;
	b=Y0EIxVORS5mBQcnRGUW3BzMP5x1knRosmJ88pGpbwFuOtUaPuISabeJsToqR6qO6Pa
	pytgeax2Euff6gQdYGjQUHk0YQnR45DaEe1QtR43j+TPiX4GW2bWGFFbtKLpPT454lCm
	ZYYLqkSdlFYR+SDFZfSgjiVXtfsJYAIvk82paDolYWGywQ5Q5z/uL9QQVKAIweIDtv9N
	ghEUhlNf+bMzd5Z+/Q03QLr0waOxQVYMQvfK4qpMM68u9sGBq6VcJem7Eu3hb7U9fTNg
	VvW8rlfOgmsRUeBCoMdQgIcHpEcIP1q/5w7JgNQnb5TP8tXHxtLNekPbDOP4uBkOEto7
	gc9Q==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr2928474qap.6.1340885694609; Thu,
	28 Jun 2012 05:14:54 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 05:14:54 -0700 (PDT)
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
Date: Thu, 28 Jun 2012 13:14:54 +0100
X-Google-Sender-Auth: j4DYrQyye1dFiNet7b8XBo3l5co
Message-ID: <CAFLBxZab3z3aSbD-qBAsS_-rW5_6mdOmnucBNnKYF4T9UtV6QQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 26, 2012 at 6:31 AM, Hao, Xudong <xudong.hao@intel.com> wrote:
>> -----Original Message-----
>> From: Tim Deegan [mailto:tim@xen.org]
>> Sent: Monday, June 25, 2012 5:02 PM
>> To: Hao, Xudong
>> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
>> JBeulich@suse.com
>> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
>>
>> At 09:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
>> > Changes from v1:
>> > - Move hap_has_dirty_bit and hap_has_access_bit definition from patch =
3 to
>> patch2.
>> > - define them as bool_t instead of int.
>> >
>> > Extended Page Tables introduce two bit: access bit and dirty bit, A/D =
bits
>> > enable VMMs to efficiently implement memory management and page
>> classification
>> > algorithms to optimize VM memory operations.
>> >
>> > This series of patches enable EPT dirty bit feature for guest live mig=
ration.
>>
>> Thanks for this. =A0I have a few high-level questions:
>>
>> - You're proposing this for after 4.2, right?
>>
>
> Yes, they are not targeted to 4.2.
>
>> - Have you measured what difference this makes? =A0I take it it improves
>> =A0 performance during live migration but it would be good to know how m=
uch
>> =A0 before taking on extra code.
>>
>
> We did live migration performance testing with patches, it's embarrassed =
to say but the result show there is no performance gain and no performance =
loss indeed.

What exactly did you measure?  If you measured the speed of the
migration itself on an empty system, it might not be noticeable; but
if, for instance, it increased the performance of a workload running
*inside* the guest during the migration, or if it decreased the cpu
usage of qemu during the migraiton, that might be worth it.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:29:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkDqs-0007sZ-2M; Thu, 28 Jun 2012 12:29:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SkDqr-0007sU-Ci
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:29:37 +0000
Received: from [193.109.254.147:8099] by server-12.bemta-14.messagelabs.com id
	0E/24-30461-03E4CEF4; Thu, 28 Jun 2012 12:29:36 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340886575!8984019!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20561 invoked from network); 28 Jun 2012 12:29:36 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:29:36 -0000
Received: by qabj34 with SMTP id j34so1626438qab.11
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 05:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=t4yfShfy5od7UNOzc8iRAwuIkVzwrOK11tueNf5Kztk=;
	b=CxUPrDRnsc/BzOStmXtjgazp7b+YSFDfWCivRcyVKDm9+Kktopgdl1ND4CVEnlGpwD
	MWeQMqIOzSN03YYjl39LiWjTeAIJLdh8Y6ctJ9pQWKtRLlxKl5B7xlqGRSuip449Drro
	vfz41SqGIMk7mM22twZ6R3aO0ccDHWFcoso3hZdLy3dAJyGU9rAq3NMs4aIGU4LhlGR8
	rYziywgh+1zkBgx1PqRESC2/jEb+PvWdY3p0HPuC0BxUm+T0iWzd5gDqW7LGzB+k4QQC
	PLSXpx62Dtju4yr7qepBZJGKvZWEXJi/IgRQh0Td0vzz2PsJWPhlwfPhW8rHYqt3MXN4
	oi0Q==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr2996183qap.6.1340886574826; Thu,
	28 Jun 2012 05:29:34 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 05:29:34 -0700 (PDT)
In-Reply-To: <4FEC320B.7050309@citrix.com>
References: <4FEB5AA6.4010403@citrix.com>
	<4FEC454C020000780008C6A4@nat28.tlf.novell.com>
	<4FEC320B.7050309@citrix.com>
Date: Thu, 28 Jun 2012 13:29:34 +0100
X-Google-Sender-Auth: nGWvpfetrY9VaS0TwtCmngeyzRU
Message-ID: <CAFLBxZbsxo+ybOTo5eVtc1aMLAt81vTOR+hQk+UcBTrzYCabDg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Dario Faggioli <dario.faggioli@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] Logical NUMA error during boot, and RFC 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="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, Jun 28, 2012 at 11:29 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> What this means is that per socket, one node has half of its available
> DIMMs filled, and the other node has no memory. =A0The performance
> implications are severe, but as it appears that almost all combinations
> of RAM you can select on the Dell website will leads to poor or worse
> performance, I can foresee many systems like this in the future. =A0(I
> don't wish to single Dell out here, other than it happens to be the
> provider of the server I am testing. =A0Other server providers suffer the
> same issues)

Wow, that sounds almost more like AMP (asymmetric multiprocessing) than NUM=
A...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:29:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkDqs-0007sZ-2M; Thu, 28 Jun 2012 12:29:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1SkDqr-0007sU-Ci
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:29:37 +0000
Received: from [193.109.254.147:8099] by server-12.bemta-14.messagelabs.com id
	0E/24-30461-03E4CEF4; Thu, 28 Jun 2012 12:29:36 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340886575!8984019!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20561 invoked from network); 28 Jun 2012 12:29:36 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:29:36 -0000
Received: by qabj34 with SMTP id j34so1626438qab.11
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 05:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=t4yfShfy5od7UNOzc8iRAwuIkVzwrOK11tueNf5Kztk=;
	b=CxUPrDRnsc/BzOStmXtjgazp7b+YSFDfWCivRcyVKDm9+Kktopgdl1ND4CVEnlGpwD
	MWeQMqIOzSN03YYjl39LiWjTeAIJLdh8Y6ctJ9pQWKtRLlxKl5B7xlqGRSuip449Drro
	vfz41SqGIMk7mM22twZ6R3aO0ccDHWFcoso3hZdLy3dAJyGU9rAq3NMs4aIGU4LhlGR8
	rYziywgh+1zkBgx1PqRESC2/jEb+PvWdY3p0HPuC0BxUm+T0iWzd5gDqW7LGzB+k4QQC
	PLSXpx62Dtju4yr7qepBZJGKvZWEXJi/IgRQh0Td0vzz2PsJWPhlwfPhW8rHYqt3MXN4
	oi0Q==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr2996183qap.6.1340886574826; Thu,
	28 Jun 2012 05:29:34 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 05:29:34 -0700 (PDT)
In-Reply-To: <4FEC320B.7050309@citrix.com>
References: <4FEB5AA6.4010403@citrix.com>
	<4FEC454C020000780008C6A4@nat28.tlf.novell.com>
	<4FEC320B.7050309@citrix.com>
Date: Thu, 28 Jun 2012 13:29:34 +0100
X-Google-Sender-Auth: nGWvpfetrY9VaS0TwtCmngeyzRU
Message-ID: <CAFLBxZbsxo+ybOTo5eVtc1aMLAt81vTOR+hQk+UcBTrzYCabDg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Dario Faggioli <dario.faggioli@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] Logical NUMA error during boot, and RFC 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="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, Jun 28, 2012 at 11:29 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> What this means is that per socket, one node has half of its available
> DIMMs filled, and the other node has no memory. =A0The performance
> implications are severe, but as it appears that almost all combinations
> of RAM you can select on the Dell website will leads to poor or worse
> performance, I can foresee many systems like this in the future. =A0(I
> don't wish to single Dell out here, other than it happens to be the
> provider of the server I am testing. =A0Other server providers suffer the
> same issues)

Wow, that sounds almost more like AMP (asymmetric multiprocessing) than NUM=
A...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:37:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkDxz-00085u-VA; Thu, 28 Jun 2012 12:36:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkDxz-00085p-55
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:36:59 +0000
Received: from [193.109.254.147:15711] by server-4.bemta-14.messagelabs.com id
	E7/CE-02077-AEF4CEF4; Thu, 28 Jun 2012 12:36:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340887017!9012238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8284 invoked from network); 28 Jun 2012 12:36:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13268704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 12:36:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 13:36:57 +0100
Message-ID: <1340887016.10942.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 13:36:56 +0100
In-Reply-To: <20120628121056.GC15863@spongy>
References: <20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
> On 28/06 12:58, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > > On 28/06 12:34, Ian Campbell wrote:
> > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > > 
> > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > > >> > > in the same VM?
> > > > > > > > >> >
> > > > > > > > >> > Yes.
> > > > > > > > >> >
> > > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > > >> > > all fine.
> > > > > > > > >> >
> > > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > > >
> > > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > > list.
> > > > > > > > >
> > > > > > > > 
> > > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > > informing up the stack that a ring has already been registered.
> > > > > > > 
> > > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > > 
> > > > > > Which takes us back to the original issue Tim asked about with
> > > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > > v4v clients in a single domain, doesn't it?
> > > > > > 
> > > > > 
> > > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > > The probably that Tim reported was about trying to create two connections
> > > > > on the same port. Today with the code that I've submited in the RFC
> > > > > one will overwrite the other silently which isn't a good thing, that can
> > > > > easily be changed to notify which one got registered up the stack.
> > > > 
> > > > So they'd somehow need to randomise (and retry) their use of source
> > > > ports in order to co-exist?
> > > >
> > > 
> > > That can be assimilated to two userspace programs trying to bind to the
> > > same TCP port. I think it's not v4v's responsability to solve this problem.
> > 
> > An application using TCP doesn't need to worry about choosing its own
> > source port though.
> > 
> > Or does this only effect destination / listening ports?
> > 
> 
> The guest v4v driver knows which port are in used so if you put port 0
> we will pick a random unused number for the source port.

Except when there are two such drivers each doesn't know which the other
one is using.

Ian.

> 
> Jean
> 
> > > 
> > > > Speaking of ports, is there a registry somewhere of the well known port
> > > > numbers and/or any scheme for administering these? (a text file in the
> > > > repo would be find by me).
> > > > 
> > > 
> > > Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
> > > then for the rest we can have a file in the repo to reference them.
> > 
> > OK.
> > 
> > Ian.
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:37:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkDxz-00085u-VA; Thu, 28 Jun 2012 12:36:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkDxz-00085p-55
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:36:59 +0000
Received: from [193.109.254.147:15711] by server-4.bemta-14.messagelabs.com id
	E7/CE-02077-AEF4CEF4; Thu, 28 Jun 2012 12:36:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340887017!9012238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8284 invoked from network); 28 Jun 2012 12:36:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13268704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 12:36:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 13:36:57 +0100
Message-ID: <1340887016.10942.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 13:36:56 +0100
In-Reply-To: <20120628121056.GC15863@spongy>
References: <20120614145608.GG90181@ocelot.phlegethon.org>
	<20120614151043.GB24063@spongy>
	<20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
> On 28/06 12:58, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > > On 28/06 12:34, Ian Campbell wrote:
> > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > > 
> > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > > >> > > in the same VM?
> > > > > > > > >> >
> > > > > > > > >> > Yes.
> > > > > > > > >> >
> > > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > > >> > > all fine.
> > > > > > > > >> >
> > > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > > >
> > > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > > list.
> > > > > > > > >
> > > > > > > > 
> > > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > > informing up the stack that a ring has already been registered.
> > > > > > > 
> > > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > > 
> > > > > > Which takes us back to the original issue Tim asked about with
> > > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > > v4v clients in a single domain, doesn't it?
> > > > > > 
> > > > > 
> > > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > > The probably that Tim reported was about trying to create two connections
> > > > > on the same port. Today with the code that I've submited in the RFC
> > > > > one will overwrite the other silently which isn't a good thing, that can
> > > > > easily be changed to notify which one got registered up the stack.
> > > > 
> > > > So they'd somehow need to randomise (and retry) their use of source
> > > > ports in order to co-exist?
> > > >
> > > 
> > > That can be assimilated to two userspace programs trying to bind to the
> > > same TCP port. I think it's not v4v's responsability to solve this problem.
> > 
> > An application using TCP doesn't need to worry about choosing its own
> > source port though.
> > 
> > Or does this only effect destination / listening ports?
> > 
> 
> The guest v4v driver knows which port are in used so if you put port 0
> we will pick a random unused number for the source port.

Except when there are two such drivers each doesn't know which the other
one is using.

Ian.

> 
> Jean
> 
> > > 
> > > > Speaking of ports, is there a registry somewhere of the well known port
> > > > numbers and/or any scheme for administering these? (a text file in the
> > > > repo would be find by me).
> > > > 
> > > 
> > > Port numbers are 32 bits, by convention the first 65535 will match the TCP onces,
> > > then for the rest we can have a file in the repo to reference them.
> > 
> > OK.
> > 
> > Ian.
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:41:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12: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 1SkE24-0008Gb-Ks; Thu, 28 Jun 2012 12:41:12 +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 1SkE23-0008GW-FD
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:41:11 +0000
Received: from [85.158.143.99:18364] by server-1.bemta-4.messagelabs.com id
	F8/AC-24392-6E05CEF4; Thu, 28 Jun 2012 12:41:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340887268!21886154!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzQ1NDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3327 invoked from network); 28 Jun 2012 12:41:09 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 12:41:09 -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 D3A9A1A6C;
	Thu, 28 Jun 2012 15:41:06 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 80936EC027; Thu, 28 Jun 2012 15:41:06 +0300 (EEST)
Date: Thu, 28 Jun 2012 15:41:06 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Dario Faggioli <raistlin@linux.it>
Message-ID: <20120628124106.GL2058@reaktio.net>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340878329.21008.2.camel@Solace>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 12:12:09PM +0200, Dario Faggioli wrote:
> On Thu, 2012-06-28 at 07:25 +0000, Zhang, Yang Z wrote:
> > > This all happens internally to libxl, and no API for driving the mechanism is
> > > provided for now. This matches what xend already does.
> > we should consider the basic IONUMA. I mean when a guest with a device assigned, 
> > from the point of view of performance, it's better to allocated the memory from the node 
> > which the device belongs to.
> >
> That sure makes sense, and it would be a very useful extension!
> 
> > Furthermore, we need consider the guest NUMA(I am working on it now) and live migration.
> > 
> Great. Can you share, either here on or a separate thread some more
> details about what you mean by both "guest NUMA" and "live migration" in
> this context?
> 
> As George said, that would be 4.3 material, but I'm still very
> interested. :-)
> 

For the mailinglist archives.. 

here are the Xen guest VM NUMA slides from XenSummit 2010:
http://www.slideshare.net/xen_com_mgr/nakajima-numafinal
http://www.slideshare.net/xen_com_mgr/dulloor-xensummit

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:41:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12: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 1SkE24-0008Gb-Ks; Thu, 28 Jun 2012 12:41:12 +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 1SkE23-0008GW-FD
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:41:11 +0000
Received: from [85.158.143.99:18364] by server-1.bemta-4.messagelabs.com id
	F8/AC-24392-6E05CEF4; Thu, 28 Jun 2012 12:41:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340887268!21886154!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzQ1NDQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3327 invoked from network); 28 Jun 2012 12:41:09 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 12:41:09 -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 D3A9A1A6C;
	Thu, 28 Jun 2012 15:41:06 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 80936EC027; Thu, 28 Jun 2012 15:41:06 +0300 (EEST)
Date: Thu, 28 Jun 2012 15:41:06 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Dario Faggioli <raistlin@linux.it>
Message-ID: <20120628124106.GL2058@reaktio.net>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340878329.21008.2.camel@Solace>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 12:12:09PM +0200, Dario Faggioli wrote:
> On Thu, 2012-06-28 at 07:25 +0000, Zhang, Yang Z wrote:
> > > This all happens internally to libxl, and no API for driving the mechanism is
> > > provided for now. This matches what xend already does.
> > we should consider the basic IONUMA. I mean when a guest with a device assigned, 
> > from the point of view of performance, it's better to allocated the memory from the node 
> > which the device belongs to.
> >
> That sure makes sense, and it would be a very useful extension!
> 
> > Furthermore, we need consider the guest NUMA(I am working on it now) and live migration.
> > 
> Great. Can you share, either here on or a separate thread some more
> details about what you mean by both "guest NUMA" and "live migration" in
> this context?
> 
> As George said, that would be 4.3 material, but I'm still very
> interested. :-)
> 

For the mailinglist archives.. 

here are the Xen guest VM NUMA slides from XenSummit 2010:
http://www.slideshare.net/xen_com_mgr/nakajima-numafinal
http://www.slideshare.net/xen_com_mgr/dulloor-xensummit

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:41:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:41: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 1SkE2P-0008Iu-69; Thu, 28 Jun 2012 12:41:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jajcus@jajcus.net>) id 1SkE2O-0008IL-9Q
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:41:32 +0000
Received: from [193.109.254.147:16566] by server-8.bemta-14.messagelabs.com id
	28/66-30743-AF05CEF4; Thu, 28 Jun 2012 12:41:30 +0000
X-Env-Sender: jajcus@jajcus.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340887288!9061500!1
X-Originating-IP: [84.205.176.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18604 invoked from network); 28 Jun 2012 12:41:28 -0000
Received: from tropek.jajcus.net (HELO tropek.jajcus.net) (84.205.176.49)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 12:41:28 -0000
Received: from localhost (jajo.ipv6.eggsoft.pl [IPv6:2001:6a0:117::1])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by tropek.jajcus.net (Postfix) with ESMTPSA id 3F9705002;
	Thu, 28 Jun 2012 14:41:27 +0200 (CEST)
Date: Thu, 28 Jun 2012 14:41:26 +0200
From: Jacek Konieczny <jajcus@jajcus.net>
To: xen-users@lists.xen.org
Message-ID: <20120628124126.GD26969@jajo.eggsoft>
References: <20120614094138.GC29342@jajo.eggsoft>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614094138.GC29342@jajo.eggsoft>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [SOLVED] Re: [Xen-users] Very slow VBD writes in domU
 under Linux 3.3, ok under 3.0.x
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVGh1LCBKdW4gMTQsIDIwMTIgYXQgMTE6NDE6MzhBTSArMDIwMCwgSmFjZWsgS29uaWVjem55
IHdyb3RlOgo+IEFmdGVyIHVwZ3JhZGluZyBteSBEb21VcyB0byBMaW51eCBrZXJuZWwgMy4zLjAg
SSBoYXZlIG5vdGljZWQgc29tZQo+IGFwcGxpY2F0aW9ucyBhcmUgX2luY2VyaWJseV8gc2xvdy4g
RXZlbnR1YWxseSBJIGZvdW50IG91dCB0aGF0IGFyZSBzb21lCj4gZmlsZXN5c3RlbSB3cml0ZXMg
YmxvY2tpbmcgZm9yIGxvbmcgdGltZS4KWy4uLl0KPiBbcm9vdEB2cGJ4MTUgfl0jIHRpbWUgZGQg
aWY9L2Rldi96ZXJvIGJzPTEwMjQgY291bnQ9MTAwMDAgb2Y9L2Rldi94dmRjMSAKPiAxMDI0MDAw
MCBieXRlcyAoMTAgTUIpIGNvcGllZCwgNTIuOTM2NiBzLCAxOTMga0Ivcwo+ICAgIDg4LjIzcyBy
ZWFsICAgICAwLjAwcyB1c2VyICAgICAwLjM2cyBzeXN0ZW0KWy4uLl0KPiB3aGlsZSBibG9ja2Vk
Ogo+IAo+IFtyb290QHZwYngxNSB+XSMgY2F0IC9wcm9jL2BwaWRvZiBkZGAvc3RhY2sgICAgCj4g
WzxjMDE2ODkxYT5dIGNoZWNrX3ByZWVtcHRfY3VycisweDZhLzB4ODAKPiBbPGMwMTA5ZjNjPl0g
eGVuX2Nsb2Nrc291cmNlX3JlYWQrMHgyYy8weDYwCj4gWzxjMDE3OWYxMD5dIGt0aW1lX2dldF90
cysweGYwLzB4MTIwCgpJIGhhdmUgbWFuYWdlZCB0byB1cGdyYWRlIG15IGltYWdlIHRvIGtlcm5l
bCAzLjQuNCDigJMgdGhhdCBzdGlsbCBkaWRuJ3QKaGVscCwgYnV0IHdoZW4gSSBzd2l0Y2hlZCB0
byBhIDY0LWJpdCBrZXJuZWwsIHRoZSBwcm9ibGVtIGRpc2FwcGVhcmVkLgoKSSBoYXZlIGJlZW4g
dXNpbmcgNjQtYml0IGh5cGVydmlzb3IgZm9yIHllYXJzIG5vdywgYnV0IHRoZSBkb21VIGtlcm5l
bHMKd2VyZSBhbHdheXMgMzItYml0LiBVcGdyYWRpbmcgZG9tMCBrZXJuZWwgdG8gNjQtYml0IGRp
ZCBub3QgY2hhbmdlCmFueXRoaW5nLgoKSSBhbSBub3QgMTAwJSBzdXJlIGlmIGl0IGlzIHRoZSBr
ZXJuZWwgYXJjaGl0ZWN0dXJlIGNoYW5nZXMgb3Igc29tZQpkaWZmZXJlbmNlIGluIGtlcm5lbCBj
b25maWd1cmF0aW9ucyAoc29tZSBvcHRpb25zIHdoaWNoIHdoZXJlIGVuYWJsZWQKaW4gMzItYml0
IGtlcm5lbCB3aGVyZSBhdXRvbWF0aWNhbGx5IGRpc2FibGVkIHdoZW4gY29tcGlsaW5nIGZvcgo2
NC1iaXQpLCBidXQgSSBjYW5ub3QgZmluZCBhbnkgc3VjaCBvYnZpb3VzIHNldHRpbmcgY2hhbmdl
LgoKQW55d2F5LCB1c2luZyA2NC1iaXQga2VybmVsIGZpeGVzIHRoZSBwcm9ibGVtIGZvciBtZSBh
bmQgdGhhdCBpcyBnb29kCmVub3VnaC4gU2luY2UgSSBhbSBhYmxlIHRvIHVzZSBhIDY0LWJpdCBr
ZXJuZWwgSSBoYXZlIG5vIHJlYXNvbiB0byB1c2UKMzIgYml0IExpbnV4IGtlcm5lbHMgdW5kZXIg
WGVuIGFueSBtb3JlLgoKR3JlZXRzLAogICAgICAgIEphY2VrCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:41:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:41: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 1SkE2P-0008Iu-69; Thu, 28 Jun 2012 12:41:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jajcus@jajcus.net>) id 1SkE2O-0008IL-9Q
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:41:32 +0000
Received: from [193.109.254.147:16566] by server-8.bemta-14.messagelabs.com id
	28/66-30743-AF05CEF4; Thu, 28 Jun 2012 12:41:30 +0000
X-Env-Sender: jajcus@jajcus.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340887288!9061500!1
X-Originating-IP: [84.205.176.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18604 invoked from network); 28 Jun 2012 12:41:28 -0000
Received: from tropek.jajcus.net (HELO tropek.jajcus.net) (84.205.176.49)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 12:41:28 -0000
Received: from localhost (jajo.ipv6.eggsoft.pl [IPv6:2001:6a0:117::1])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by tropek.jajcus.net (Postfix) with ESMTPSA id 3F9705002;
	Thu, 28 Jun 2012 14:41:27 +0200 (CEST)
Date: Thu, 28 Jun 2012 14:41:26 +0200
From: Jacek Konieczny <jajcus@jajcus.net>
To: xen-users@lists.xen.org
Message-ID: <20120628124126.GD26969@jajo.eggsoft>
References: <20120614094138.GC29342@jajo.eggsoft>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120614094138.GC29342@jajo.eggsoft>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [SOLVED] Re: [Xen-users] Very slow VBD writes in domU
 under Linux 3.3, ok under 3.0.x
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVGh1LCBKdW4gMTQsIDIwMTIgYXQgMTE6NDE6MzhBTSArMDIwMCwgSmFjZWsgS29uaWVjem55
IHdyb3RlOgo+IEFmdGVyIHVwZ3JhZGluZyBteSBEb21VcyB0byBMaW51eCBrZXJuZWwgMy4zLjAg
SSBoYXZlIG5vdGljZWQgc29tZQo+IGFwcGxpY2F0aW9ucyBhcmUgX2luY2VyaWJseV8gc2xvdy4g
RXZlbnR1YWxseSBJIGZvdW50IG91dCB0aGF0IGFyZSBzb21lCj4gZmlsZXN5c3RlbSB3cml0ZXMg
YmxvY2tpbmcgZm9yIGxvbmcgdGltZS4KWy4uLl0KPiBbcm9vdEB2cGJ4MTUgfl0jIHRpbWUgZGQg
aWY9L2Rldi96ZXJvIGJzPTEwMjQgY291bnQ9MTAwMDAgb2Y9L2Rldi94dmRjMSAKPiAxMDI0MDAw
MCBieXRlcyAoMTAgTUIpIGNvcGllZCwgNTIuOTM2NiBzLCAxOTMga0Ivcwo+ICAgIDg4LjIzcyBy
ZWFsICAgICAwLjAwcyB1c2VyICAgICAwLjM2cyBzeXN0ZW0KWy4uLl0KPiB3aGlsZSBibG9ja2Vk
Ogo+IAo+IFtyb290QHZwYngxNSB+XSMgY2F0IC9wcm9jL2BwaWRvZiBkZGAvc3RhY2sgICAgCj4g
WzxjMDE2ODkxYT5dIGNoZWNrX3ByZWVtcHRfY3VycisweDZhLzB4ODAKPiBbPGMwMTA5ZjNjPl0g
eGVuX2Nsb2Nrc291cmNlX3JlYWQrMHgyYy8weDYwCj4gWzxjMDE3OWYxMD5dIGt0aW1lX2dldF90
cysweGYwLzB4MTIwCgpJIGhhdmUgbWFuYWdlZCB0byB1cGdyYWRlIG15IGltYWdlIHRvIGtlcm5l
bCAzLjQuNCDigJMgdGhhdCBzdGlsbCBkaWRuJ3QKaGVscCwgYnV0IHdoZW4gSSBzd2l0Y2hlZCB0
byBhIDY0LWJpdCBrZXJuZWwsIHRoZSBwcm9ibGVtIGRpc2FwcGVhcmVkLgoKSSBoYXZlIGJlZW4g
dXNpbmcgNjQtYml0IGh5cGVydmlzb3IgZm9yIHllYXJzIG5vdywgYnV0IHRoZSBkb21VIGtlcm5l
bHMKd2VyZSBhbHdheXMgMzItYml0LiBVcGdyYWRpbmcgZG9tMCBrZXJuZWwgdG8gNjQtYml0IGRp
ZCBub3QgY2hhbmdlCmFueXRoaW5nLgoKSSBhbSBub3QgMTAwJSBzdXJlIGlmIGl0IGlzIHRoZSBr
ZXJuZWwgYXJjaGl0ZWN0dXJlIGNoYW5nZXMgb3Igc29tZQpkaWZmZXJlbmNlIGluIGtlcm5lbCBj
b25maWd1cmF0aW9ucyAoc29tZSBvcHRpb25zIHdoaWNoIHdoZXJlIGVuYWJsZWQKaW4gMzItYml0
IGtlcm5lbCB3aGVyZSBhdXRvbWF0aWNhbGx5IGRpc2FibGVkIHdoZW4gY29tcGlsaW5nIGZvcgo2
NC1iaXQpLCBidXQgSSBjYW5ub3QgZmluZCBhbnkgc3VjaCBvYnZpb3VzIHNldHRpbmcgY2hhbmdl
LgoKQW55d2F5LCB1c2luZyA2NC1iaXQga2VybmVsIGZpeGVzIHRoZSBwcm9ibGVtIGZvciBtZSBh
bmQgdGhhdCBpcyBnb29kCmVub3VnaC4gU2luY2UgSSBhbSBhYmxlIHRvIHVzZSBhIDY0LWJpdCBr
ZXJuZWwgSSBoYXZlIG5vIHJlYXNvbiB0byB1c2UKMzIgYml0IExpbnV4IGtlcm5lbHMgdW5kZXIg
WGVuIGFueSBtb3JlLgoKR3JlZXRzLAogICAgICAgIEphY2VrCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:45:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkE5v-0000LL-Ly; Thu, 28 Jun 2012 12:45: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 1SkE5u-0000L6-O3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:45:10 +0000
Received: from [193.109.254.147:12123] by server-4.bemta-14.messagelabs.com id
	8A/66-02077-5D15CEF4; Thu, 28 Jun 2012 12:45:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340887508!9014049!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18739 invoked from network); 28 Jun 2012 12:45:08 -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; 28 Jun 2012 12:45:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkE5s-000BpB-3I; Thu, 28 Jun 2012 12:45:08 +0000
Date: Thu, 28 Jun 2012 13:45:08 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628124508.GK34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<71a22d6d940f27d8dfbc.1340816251@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <71a22d6d940f27d8dfbc.1340816251@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4 of 4] xen,
	pod: Try to reclaim superpages when ballooning 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

At 17:57 +0100 on 27 Jun (1340819851), George Dunlap wrote:
> xen,pod: Try to reclaim superpages when ballooning down
> 
> Windows balloon drivers can typically only get 4k pages from the kernel,
> and so hand them back at that level.  Try to regain superpages by checking
> the superpage frame that the 4k page is in to see if we can reclaim the whole
> thing for the PoD cache.
> 
> This also modifies p2m_pod_zero_check_superpage() to return SUPERPAGE_PAGES on
> success.
> 
> v2:
>  - Rewritten to simply to the check as in demand-fault case, without needing
>    to know that the p2m entry is a superpage.
>  - Also, took out the re-writing of the reclaim loop, leaving it optimized for
>    4k pages (by far the most common case), and simplifying the patch.
> 

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 Jun 28 12:45:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkE5v-0000LL-Ly; Thu, 28 Jun 2012 12:45: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 1SkE5u-0000L6-O3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:45:10 +0000
Received: from [193.109.254.147:12123] by server-4.bemta-14.messagelabs.com id
	8A/66-02077-5D15CEF4; Thu, 28 Jun 2012 12:45:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340887508!9014049!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18739 invoked from network); 28 Jun 2012 12:45:08 -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; 28 Jun 2012 12:45:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkE5s-000BpB-3I; Thu, 28 Jun 2012 12:45:08 +0000
Date: Thu, 28 Jun 2012 13:45:08 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628124508.GK34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<71a22d6d940f27d8dfbc.1340816251@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <71a22d6d940f27d8dfbc.1340816251@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4 of 4] xen,
	pod: Try to reclaim superpages when ballooning 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

At 17:57 +0100 on 27 Jun (1340819851), George Dunlap wrote:
> xen,pod: Try to reclaim superpages when ballooning down
> 
> Windows balloon drivers can typically only get 4k pages from the kernel,
> and so hand them back at that level.  Try to regain superpages by checking
> the superpage frame that the 4k page is in to see if we can reclaim the whole
> thing for the PoD cache.
> 
> This also modifies p2m_pod_zero_check_superpage() to return SUPERPAGE_PAGES on
> success.
> 
> v2:
>  - Rewritten to simply to the check as in demand-fault case, without needing
>    to know that the p2m entry is a superpage.
>  - Also, took out the re-writing of the reclaim loop, leaving it optimized for
>    4k pages (by far the most common case), and simplifying the patch.
> 

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 Jun 28 12:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkE6r-0000Rg-58; Thu, 28 Jun 2012 12:46: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 1SkE6q-0000RN-Ac
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:46:08 +0000
Received: from [85.158.139.83:28973] by server-1.bemta-5.messagelabs.com id
	90/18-19721-F025CEF4; Thu, 28 Jun 2012 12:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340887566!24830711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3945 invoked from network); 28 Jun 2012 12:46:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13268955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 12:46:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 13:46:06 +0100
Message-ID: <1340887564.10942.47.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, 28 Jun 2012 13:46:04 +0100
In-Reply-To: <1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH V2 16/40] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:29 +0100, Ian Campbell wrote:
> Rename p2m_create_entry to p2m_create_table since it can now only be used to
> insert non-leaf entries into the page table.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

This change should also have incorporated the following which somehow
ended up in
         [PATCH V2 22/40] arm: use correct attributes for mappings in copy_from_paddr()
I'll move them over...

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 6efe23c..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,13 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
 #define MATTR_DEV     0x1
 #define MATTR_MEM     0xf
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkE6r-0000Rg-58; Thu, 28 Jun 2012 12:46: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 1SkE6q-0000RN-Ac
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 12:46:08 +0000
Received: from [85.158.139.83:28973] by server-1.bemta-5.messagelabs.com id
	90/18-19721-F025CEF4; Thu, 28 Jun 2012 12:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340887566!24830711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3945 invoked from network); 28 Jun 2012 12:46:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 12:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13268955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 12:46:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 13:46:06 +0100
Message-ID: <1340887564.10942.47.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, 28 Jun 2012 13:46:04 +0100
In-Reply-To: <1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH V2 16/40] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 11:29 +0100, Ian Campbell wrote:
> Rename p2m_create_entry to p2m_create_table since it can now only be used to
> insert non-leaf entries into the page table.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

This change should also have incorporated the following which somehow
ended up in
         [PATCH V2 22/40] arm: use correct attributes for mappings in copy_from_paddr()
I'll move them over...

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 6efe23c..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,13 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
 #define MATTR_DEV     0x1
 #define MATTR_MEM     0xf
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 12:48:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:48: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 1SkE92-0000e7-M2; Thu, 28 Jun 2012 12: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 1SkE90-0000dv-Ne
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:48:22 +0000
Received: from [85.158.143.99:32920] by server-2.bemta-4.messagelabs.com id
	6A/82-17938-5925CEF4; Thu, 28 Jun 2012 12:48:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340887701!17989025!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21164 invoked from network); 28 Jun 2012 12:48:21 -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; 28 Jun 2012 12:48:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkE8y-000Brn-JZ; Thu, 28 Jun 2012 12:48:20 +0000
Date: Thu, 28 Jun 2012 13:48:20 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628124820.GL34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<c71f52608fd8867062cc.1340816250@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c71f52608fd8867062cc.1340816250@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] xen, pod: Only sweep in an emergency,
	and only for 4k pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:57 +0100 on 27 Jun (1340819850), George Dunlap wrote:
> xen,pod: Only sweep in an emergency, and only for 4k pages
> 
> Testing has shown that doing sweeps for superpages slows down boot
> significantly, but does not result in a significantly higher number of
> superpages after boot.  Early sweeping for 4k pages causes superpages
> to be broken up unnecessarily.
> 
> Only sweep if we're really out of memory.
> 
> v2:
>  - Move unrelated code-motion hunk to another patch
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.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 Jun 28 12:48:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:48: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 1SkE92-0000e7-M2; Thu, 28 Jun 2012 12: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 1SkE90-0000dv-Ne
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:48:22 +0000
Received: from [85.158.143.99:32920] by server-2.bemta-4.messagelabs.com id
	6A/82-17938-5925CEF4; Thu, 28 Jun 2012 12:48:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340887701!17989025!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21164 invoked from network); 28 Jun 2012 12:48:21 -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; 28 Jun 2012 12:48:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkE8y-000Brn-JZ; Thu, 28 Jun 2012 12:48:20 +0000
Date: Thu, 28 Jun 2012 13:48:20 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628124820.GL34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<c71f52608fd8867062cc.1340816250@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c71f52608fd8867062cc.1340816250@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] xen, pod: Only sweep in an emergency,
	and only for 4k pages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:57 +0100 on 27 Jun (1340819850), George Dunlap wrote:
> xen,pod: Only sweep in an emergency, and only for 4k pages
> 
> Testing has shown that doing sweeps for superpages slows down boot
> significantly, but does not result in a significantly higher number of
> superpages after boot.  Early sweeping for 4k pages causes superpages
> to be broken up unnecessarily.
> 
> Only sweep if we're really out of memory.
> 
> v2:
>  - Move unrelated code-motion hunk to another patch
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.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 Jun 28 12:48:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12: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 1SkE9N-0000gs-2I; Thu, 28 Jun 2012 12:48:45 +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 1SkE9L-0000gU-B5
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:48:43 +0000
Received: from [85.158.139.83:3583] by server-12.bemta-5.messagelabs.com id
	ED/BC-25233-AA25CEF4; Thu, 28 Jun 2012 12:48:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340887721!25706888!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10622 invoked from network); 28 Jun 2012 12:48:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 12:48:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkE9I-000BsG-Qz; Thu, 28 Jun 2012 12:48:40 +0000
Date: Thu, 28 Jun 2012 13:48:40 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628124840.GM34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<ea827c449088a1017b6e.1340816249@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ea827c449088a1017b6e.1340816249@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xen,
	pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:57 +0100 on 27 Jun (1340819849), George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1340815812 -3600
> # Node ID ea827c449088a1017b6e5a9564eb33df70f8a9c6
> # Parent  b4e1fec1c98f6cbad666a972f473854518c25500
> xen,pod: Zero-check recently populated pages (checklast)
> 
> When demand-populating pages due to guest accesses, check recently populated
> pages to see if we can reclaim them for the cache.  This should keep the PoD
> cache filled when the start-of-day scrubber is going through.
> 
> The number 128 was chosen by experiment.  Windows does its page
> scrubbing in parallel; while a small nubmer like 4 works well for
> single VMs, it breaks down as multiple vcpus are scrubbing different
> pages in parallel.  Increasing to 128 works well for higher numbers of
> vcpus.
> 
> v2:
>  - Wrapped some long lines
>  - unsigned int for index, unsigned long for array
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.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 Jun 28 12:48:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12: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 1SkE9N-0000gs-2I; Thu, 28 Jun 2012 12:48:45 +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 1SkE9L-0000gU-B5
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:48:43 +0000
Received: from [85.158.139.83:3583] by server-12.bemta-5.messagelabs.com id
	ED/BC-25233-AA25CEF4; Thu, 28 Jun 2012 12:48:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340887721!25706888!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10622 invoked from network); 28 Jun 2012 12:48:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 12:48:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkE9I-000BsG-Qz; Thu, 28 Jun 2012 12:48:40 +0000
Date: Thu, 28 Jun 2012 13:48:40 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628124840.GM34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<ea827c449088a1017b6e.1340816249@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ea827c449088a1017b6e.1340816249@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] xen,
	pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:57 +0100 on 27 Jun (1340819849), George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1340815812 -3600
> # Node ID ea827c449088a1017b6e5a9564eb33df70f8a9c6
> # Parent  b4e1fec1c98f6cbad666a972f473854518c25500
> xen,pod: Zero-check recently populated pages (checklast)
> 
> When demand-populating pages due to guest accesses, check recently populated
> pages to see if we can reclaim them for the cache.  This should keep the PoD
> cache filled when the start-of-day scrubber is going through.
> 
> The number 128 was chosen by experiment.  Windows does its page
> scrubbing in parallel; while a small nubmer like 4 works well for
> single VMs, it breaks down as multiple vcpus are scrubbing different
> pages in parallel.  Increasing to 128 works well for higher numbers of
> vcpus.
> 
> v2:
>  - Wrapped some long lines
>  - unsigned int for index, unsigned long for array
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.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 Jun 28 12:54:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:54: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 1SkEEK-00014D-QN; Thu, 28 Jun 2012 12:53: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 1SkEEJ-000147-Jm
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:53:51 +0000
Received: from [85.158.143.35:28338] by server-2.bemta-4.messagelabs.com id
	E8/BB-17938-ED35CEF4; Thu, 28 Jun 2012 12:53:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340888002!7143228!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4617 invoked from network); 28 Jun 2012 12:53:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 12:53:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkEDq-000Bvh-6J; Thu, 28 Jun 2012 12:53:22 +0000
Date: Thu, 28 Jun 2012 13:53:22 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628125322.GN34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1340816247@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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

At 17:57 +0100 on 27 Jun (1340819847), George Dunlap wrote:
> xen,pod: Populate-on-demand reclaim improvements
> 
> Rework populate-on-demand sweeping
> 
> Last summer I did some work on testing whether our PoD sweeping code
> was achieving its goals: namely, never crashing unnecessairly,
> minimizing boot time, and maximizing the number of superpages in the
> p2m table.
> 
> This is the resulting patch series.

I've acked these, but only applied 1/4, because:

 - patch 4 needs an S-o-B line;
 - patch 2 can't go in before patch 4 because it depends on the new
   return value of p2m_pod_zero_check_superpage(); and
 - patch 3 can't go in before patch 2 or it removes the only caller of
   p2m_pod_zero_check_superpage() and breaks the build. :)

If you reshuffle them as 4, 2, 3, add an S-o-B and address Andres's
comment about the order constant, I'll push them straight in next time.

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 Jun 28 12:54:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 12:54: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 1SkEEK-00014D-QN; Thu, 28 Jun 2012 12:53: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 1SkEEJ-000147-Jm
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 12:53:51 +0000
Received: from [85.158.143.35:28338] by server-2.bemta-4.messagelabs.com id
	E8/BB-17938-ED35CEF4; Thu, 28 Jun 2012 12:53:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340888002!7143228!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4617 invoked from network); 28 Jun 2012 12:53:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 12:53:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkEDq-000Bvh-6J; Thu, 28 Jun 2012 12:53:22 +0000
Date: Thu, 28 Jun 2012 13:53:22 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628125322.GN34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1340816247@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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

At 17:57 +0100 on 27 Jun (1340819847), George Dunlap wrote:
> xen,pod: Populate-on-demand reclaim improvements
> 
> Rework populate-on-demand sweeping
> 
> Last summer I did some work on testing whether our PoD sweeping code
> was achieving its goals: namely, never crashing unnecessairly,
> minimizing boot time, and maximizing the number of superpages in the
> p2m table.
> 
> This is the resulting patch series.

I've acked these, but only applied 1/4, because:

 - patch 4 needs an S-o-B line;
 - patch 2 can't go in before patch 4 because it depends on the new
   return value of p2m_pod_zero_check_superpage(); and
 - patch 3 can't go in before patch 2 or it removes the only caller of
   p2m_pod_zero_check_superpage() and breaks the build. :)

If you reshuffle them as 4, 2, 3, add an S-o-B and address Andres's
comment about the order constant, I'll push them straight in next time.

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 Jun 28 13:01:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkELc-0001Ht-N4; Thu, 28 Jun 2012 13:01:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkELb-0001Hn-EO
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:01:23 +0000
Received: from [193.109.254.147:48354] by server-7.bemta-14.messagelabs.com id
	1D/3F-29827-2A55CEF4; Thu, 28 Jun 2012 13:01:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340888480!9101319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4285 invoked from network); 28 Jun 2012 13:01:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:01:20 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:01:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:01:13 +0100
Date: Thu, 28 Jun 2012 14:00:46 +0100
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: <1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281400400.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-16-git-send-email-ian.campbell@citrix.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] [PATCH V2 16/40] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Rename p2m_create_entry to p2m_create_table since it can now only be used to
> insert non-leaf entries into the page table.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/p2m.c         |   22 ++++++++++++----------
>  xen/include/asm-arm/page.h |    6 ++++--
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ec41d38..35bfa2f 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
>      return -ENOSYS;
>  }
>  
> -static int p2m_create_entry(struct domain *d,
> +/* Allocate a new page table page and hook it in via the given entry */
> +static int p2m_create_table(struct domain *d,
>                              lpae_t *entry)
>  {
>      struct p2m_domain *p2m = &d->arch.p2m;
> @@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
>      clear_page(p);
>      unmap_domain_page(p);
>  
> -    pte = mfn_to_p2m_entry(page_to_mfn(page));
> +    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
>  
>      write_pte(entry, pte);
>  
> @@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
>                       int alloc,
>                       paddr_t start_gpaddr,
>                       paddr_t end_gpaddr,
> -                     paddr_t maddr)
> +                     paddr_t maddr,
> +                     int mattr)
>  {
>      int rc;
>      struct p2m_domain *p2m = &d->arch.p2m;
> @@ -140,7 +142,7 @@ static int create_p2m_entries(struct domain *d,
>      {
>          if ( !first[first_table_offset(addr)].p2m.valid )
>          {
> -            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
> +            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
>              if ( rc < 0 ) {
>                  printk("p2m_populate_ram: L1 failed\n");
>                  goto out;
> @@ -159,7 +161,7 @@ static int create_p2m_entries(struct domain *d,
>  
>          if ( !second[second_table_offset(addr)].p2m.valid )
>          {
> -            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
> +            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
>              if ( rc < 0 ) {
>                  printk("p2m_populate_ram: L2 failed\n");
>                  goto out;
> @@ -198,11 +200,11 @@ static int create_p2m_entries(struct domain *d,
>                  goto out;
>              }
>  
> -            pte = mfn_to_p2m_entry(page_to_mfn(page));
> +            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
>  
>              write_pte(&third[third_table_offset(addr)], pte);
>          } else {
> -            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
> +            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
>              write_pte(&third[third_table_offset(addr)], pte);
>              maddr += PAGE_SIZE;
>          }
> @@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
>                       paddr_t start,
>                       paddr_t end)
>  {
> -    return create_p2m_entries(d, 1, start, end, 0);
> +    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
>  }
>  
>  int map_mmio_regions(struct domain *d,
> @@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
>                       paddr_t end_gaddr,
>                       paddr_t maddr)
>  {
> -    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> +    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
>  }
>  
>  int guest_physmap_add_page(struct domain *d,
> @@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
>  {
>      return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
>                                (gpfn + (1<<page_order)) << PAGE_SHIFT,
> -                              mfn << PAGE_SHIFT);
> +                              mfn << PAGE_SHIFT, MATTR_MEM);
>  }
>  
>  void guest_physmap_remove_page(struct domain *d,
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 183ba5f..2783c30 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -46,6 +46,8 @@
>  #define DEV_WC        BUFFERABLE
>  #define DEV_CACHED    WRITEBACK
>  
> +#define MATTR_DEV     0x1
> +#define MATTR_MEM     0xf
>  
>  #ifndef __ASSEMBLY__
>  
> @@ -187,7 +189,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
>      return e;
>  }
>  
> -static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
> +static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
>  {
>      paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
>      lpae_t e = (lpae_t) {
> @@ -196,7 +198,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
>          .p2m.sh = LPAE_SH_OUTER,
>          .p2m.write = 1,
>          .p2m.read = 1,
> -        .p2m.mattr = 0xf,
> +        .p2m.mattr = mattr,
>          .p2m.table = 1,
>          .p2m.valid = 1,
>      };
> -- 
> 1.7.9.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 Thu Jun 28 13:01:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkELc-0001Ht-N4; Thu, 28 Jun 2012 13:01:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkELb-0001Hn-EO
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:01:23 +0000
Received: from [193.109.254.147:48354] by server-7.bemta-14.messagelabs.com id
	1D/3F-29827-2A55CEF4; Thu, 28 Jun 2012 13:01:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340888480!9101319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4285 invoked from network); 28 Jun 2012 13:01:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:01:20 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:01:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:01:13 +0100
Date: Thu, 28 Jun 2012 14:00:46 +0100
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: <1340706604-1313-16-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281400400.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-16-git-send-email-ian.campbell@citrix.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] [PATCH V2 16/40] arm: allow p2m to be created with
 specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012, Ian Campbell wrote:
> Rename p2m_create_entry to p2m_create_table since it can now only be used to
> insert non-leaf entries into the page table.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/p2m.c         |   22 ++++++++++++----------
>  xen/include/asm-arm/page.h |    6 ++++--
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ec41d38..35bfa2f 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
>      return -ENOSYS;
>  }
>  
> -static int p2m_create_entry(struct domain *d,
> +/* Allocate a new page table page and hook it in via the given entry */
> +static int p2m_create_table(struct domain *d,
>                              lpae_t *entry)
>  {
>      struct p2m_domain *p2m = &d->arch.p2m;
> @@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
>      clear_page(p);
>      unmap_domain_page(p);
>  
> -    pte = mfn_to_p2m_entry(page_to_mfn(page));
> +    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
>  
>      write_pte(entry, pte);
>  
> @@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
>                       int alloc,
>                       paddr_t start_gpaddr,
>                       paddr_t end_gpaddr,
> -                     paddr_t maddr)
> +                     paddr_t maddr,
> +                     int mattr)
>  {
>      int rc;
>      struct p2m_domain *p2m = &d->arch.p2m;
> @@ -140,7 +142,7 @@ static int create_p2m_entries(struct domain *d,
>      {
>          if ( !first[first_table_offset(addr)].p2m.valid )
>          {
> -            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
> +            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
>              if ( rc < 0 ) {
>                  printk("p2m_populate_ram: L1 failed\n");
>                  goto out;
> @@ -159,7 +161,7 @@ static int create_p2m_entries(struct domain *d,
>  
>          if ( !second[second_table_offset(addr)].p2m.valid )
>          {
> -            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
> +            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
>              if ( rc < 0 ) {
>                  printk("p2m_populate_ram: L2 failed\n");
>                  goto out;
> @@ -198,11 +200,11 @@ static int create_p2m_entries(struct domain *d,
>                  goto out;
>              }
>  
> -            pte = mfn_to_p2m_entry(page_to_mfn(page));
> +            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
>  
>              write_pte(&third[third_table_offset(addr)], pte);
>          } else {
> -            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
> +            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
>              write_pte(&third[third_table_offset(addr)], pte);
>              maddr += PAGE_SIZE;
>          }
> @@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
>                       paddr_t start,
>                       paddr_t end)
>  {
> -    return create_p2m_entries(d, 1, start, end, 0);
> +    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
>  }
>  
>  int map_mmio_regions(struct domain *d,
> @@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
>                       paddr_t end_gaddr,
>                       paddr_t maddr)
>  {
> -    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> +    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
>  }
>  
>  int guest_physmap_add_page(struct domain *d,
> @@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
>  {
>      return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
>                                (gpfn + (1<<page_order)) << PAGE_SHIFT,
> -                              mfn << PAGE_SHIFT);
> +                              mfn << PAGE_SHIFT, MATTR_MEM);
>  }
>  
>  void guest_physmap_remove_page(struct domain *d,
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 183ba5f..2783c30 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -46,6 +46,8 @@
>  #define DEV_WC        BUFFERABLE
>  #define DEV_CACHED    WRITEBACK
>  
> +#define MATTR_DEV     0x1
> +#define MATTR_MEM     0xf
>  
>  #ifndef __ASSEMBLY__
>  
> @@ -187,7 +189,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
>      return e;
>  }
>  
> -static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
> +static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
>  {
>      paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
>      lpae_t e = (lpae_t) {
> @@ -196,7 +198,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
>          .p2m.sh = LPAE_SH_OUTER,
>          .p2m.write = 1,
>          .p2m.read = 1,
> -        .p2m.mattr = 0xf,
> +        .p2m.mattr = mattr,
>          .p2m.table = 1,
>          .p2m.valid = 1,
>      };
> -- 
> 1.7.9.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 Thu Jun 28 13:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEMm-0001LP-5f; Thu, 28 Jun 2012 13:02: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 1SkEMk-0001L8-IR
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:02:34 +0000
Received: from [193.109.254.147:30848] by server-3.bemta-14.messagelabs.com id
	A1/69-08687-9E55CEF4; Thu, 28 Jun 2012 13:02:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340888552!2164927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8647 invoked from network); 28 Jun 2012 13:02:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:02:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:02:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:02:27 +0100
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 1SkEMd-0008BG-No;
	Thu, 28 Jun 2012 13:02:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkEMd-0005eK-An;
	Thu, 28 Jun 2012 14:02:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13381-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 14:02:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13381: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13381 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13381/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 13338

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEMm-0001LP-5f; Thu, 28 Jun 2012 13:02: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 1SkEMk-0001L8-IR
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:02:34 +0000
Received: from [193.109.254.147:30848] by server-3.bemta-14.messagelabs.com id
	A1/69-08687-9E55CEF4; Thu, 28 Jun 2012 13:02:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340888552!2164927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8647 invoked from network); 28 Jun 2012 13:02:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:02:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:02:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:02:27 +0100
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 1SkEMd-0008BG-No;
	Thu, 28 Jun 2012 13:02:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkEMd-0005eK-An;
	Thu, 28 Jun 2012 14:02:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13381-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 14:02:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13381: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13381 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13381/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 13338

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkENY-0001Rz-JK; Thu, 28 Jun 2012 13:03:24 +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 1SkENW-0001Rp-UA
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:03:23 +0000
Received: from [85.158.139.83:35267] by server-10.bemta-5.messagelabs.com id
	95/33-02190-A165CEF4; Thu, 28 Jun 2012 13:03:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340888600!29893100!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7054 invoked from network); 28 Jun 2012 13:03:20 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:03:20 -0000
Received: by eaak12 with SMTP id k12so875386eaa.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 06:03:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VIAMgPCNcdDPQ9MOWxV5xOA6oxfwvA0se0DWyTkovoA=;
	b=uwx6b3i9VifQhtB6dMFgyZA/dOtNeboxJUBx3z5Knp5MkTyjrf2zeW5BfWYRyvCfLZ
	zzD9+P2SkwqMXdKSD+7fQftO+yKW+KHp/VYo8oA49VuFLcrIBr+aT5YJUV1fbTl/A+Qb
	v70IOWdmfLbR5cLTnM27wiy6cZuJifwABAAZfzYQuk6U7DpVb6GpD+Oid654R/I2WofM
	jhIfnAJkz7iBxVBFOJHJ3c8BlTakCZjf1FJC1z0UWpCufQ+x4fstoQkyAT6H3mdjUW2M
	vmd17YYlvZMdHBOVhyJidkXNl19ibzb95QxG+iEaVBKslNVufqZR8urfgNFLj4AvhK2Q
	MBbw==
Received: by 10.14.100.68 with SMTP id y44mr460643eef.69.1340888600079;
	Thu, 28 Jun 2012 06:03:20 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id u56sm5545787eef.7.2012.06.28.06.03.18
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 06:03:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 28 Jun 2012 14:03:10 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC12149E.444D1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
Thread-Index: Ac1VLl4l7gPy87YPWkGQG4iXSeLfAA==
In-Reply-To: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 11:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
> as the whole function domain_pause_for_debugger() is pointless to be
> compiled when there's no arch support, simply introduce another HAS_*
> macro, enabled only on x86.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

How did arch/arm build at all then, previously, with this function present
for a long time in common code? Would a better fix be just to move the
function to arch/x86/domain.c, since it is only called by arch/x86?

 -- Keir

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_EHCI := y
>  HAS_KEXEC := y
> +HAS_GDBSX := y
>  xenoprof := y
>  
>  #
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>          vcpu_check_shutdown(v);
>  }
>  
> +#ifdef HAS_GDBSX
>  void domain_pause_for_debugger(void)
>  {
>      struct domain *d = current->domain;
> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>      if (current->arch.gdbsx_vcpu_event == 0)
>          send_global_virq(VIRQ_DEBUGGER);
>  }
> +#endif
>  
>  /* Complete domain destroy after RCU readers are not holding old references.
> */
>  static void complete_domain_destroy(struct rcu_head *head)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 13:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkENY-0001Rz-JK; Thu, 28 Jun 2012 13:03:24 +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 1SkENW-0001Rp-UA
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:03:23 +0000
Received: from [85.158.139.83:35267] by server-10.bemta-5.messagelabs.com id
	95/33-02190-A165CEF4; Thu, 28 Jun 2012 13:03:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1340888600!29893100!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7054 invoked from network); 28 Jun 2012 13:03:20 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:03:20 -0000
Received: by eaak12 with SMTP id k12so875386eaa.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 06:03:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VIAMgPCNcdDPQ9MOWxV5xOA6oxfwvA0se0DWyTkovoA=;
	b=uwx6b3i9VifQhtB6dMFgyZA/dOtNeboxJUBx3z5Knp5MkTyjrf2zeW5BfWYRyvCfLZ
	zzD9+P2SkwqMXdKSD+7fQftO+yKW+KHp/VYo8oA49VuFLcrIBr+aT5YJUV1fbTl/A+Qb
	v70IOWdmfLbR5cLTnM27wiy6cZuJifwABAAZfzYQuk6U7DpVb6GpD+Oid654R/I2WofM
	jhIfnAJkz7iBxVBFOJHJ3c8BlTakCZjf1FJC1z0UWpCufQ+x4fstoQkyAT6H3mdjUW2M
	vmd17YYlvZMdHBOVhyJidkXNl19ibzb95QxG+iEaVBKslNVufqZR8urfgNFLj4AvhK2Q
	MBbw==
Received: by 10.14.100.68 with SMTP id y44mr460643eef.69.1340888600079;
	Thu, 28 Jun 2012 06:03:20 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id u56sm5545787eef.7.2012.06.28.06.03.18
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 06:03:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 28 Jun 2012 14:03:10 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC12149E.444D1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
Thread-Index: Ac1VLl4l7gPy87YPWkGQG4iXSeLfAA==
In-Reply-To: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 11:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
> as the whole function domain_pause_for_debugger() is pointless to be
> compiled when there's no arch support, simply introduce another HAS_*
> macro, enabled only on x86.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

How did arch/arm build at all then, previously, with this function present
for a long time in common code? Would a better fix be just to move the
function to arch/x86/domain.c, since it is only called by arch/x86?

 -- Keir

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_EHCI := y
>  HAS_KEXEC := y
> +HAS_GDBSX := y
>  xenoprof := y
>  
>  #
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>          vcpu_check_shutdown(v);
>  }
>  
> +#ifdef HAS_GDBSX
>  void domain_pause_for_debugger(void)
>  {
>      struct domain *d = current->domain;
> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>      if (current->arch.gdbsx_vcpu_event == 0)
>          send_global_virq(VIRQ_DEBUGGER);
>  }
> +#endif
>  
>  /* Complete domain destroy after RCU readers are not holding old references.
> */
>  static void complete_domain_destroy(struct rcu_head *head)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 28 13:04:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEOS-0001Zj-7L; Thu, 28 Jun 2012 13:04:20 +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 1SkEOQ-0001ZP-S3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:04:19 +0000
Received: from [85.158.143.99:51024] by server-2.bemta-4.messagelabs.com id
	42/10-17938-2565CEF4; Thu, 28 Jun 2012 13:04:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340888656!23205092!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22225 invoked from network); 28 Jun 2012 13:04:17 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:04:17 -0000
Received: by qcad1 with SMTP id d1so174045qca.30
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Jun 2012 06:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=j8Cr1BV55K3tv9oZ8YcxTa5+tZnbPwn3zJTELRUebP8=;
	b=fsgnsW6mhkwc5A75HHauGsO+JHvPcElxwd9X5Vjtu6JkJZ1KZYwUOiif+oTeC0pZsx
	dK0MaQhYlI6PtZU5pbDzSZBNhKlRK3RnAJOTCBzNWtQ/Ip5eBq++g1qZJhUD5oyOuRqm
	uKb3domk2qxNSXb61ioQeHdSW1exIjZ/D/vtRfOeGG+er0tNS5chaZTvaaAOoLw7GOPK
	zebTZ1av+5DJEZrDRB1+bf4XiX+HIQ3+lTAAKtQoBAe9/tcXJoc1Z3W30aS/aw3XpnP8
	b9Fb88GZURQilUwRIUUTgh0m5NcvuIE+/LK2S8v68hszy0X9NjvTYhkdaWdY5MpUHxcC
	T1PQ==
MIME-Version: 1.0
Received: by 10.229.69.30 with SMTP id x30mr793385qci.13.1340888655891; Thu,
	28 Jun 2012 06:04:15 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 06:04:15 -0700 (PDT)
In-Reply-To: <20120628125322.GN34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<20120628125322.GN34995@ocelot.phlegethon.org>
Date: Thu, 28 Jun 2012 14:04:15 +0100
X-Google-Sender-Auth: jSxFM-tilX8ixEY1rvUW_349leU
Message-ID: <CAFLBxZashQ9ecqeL6h-uCA6Tp2cQRoVnoNxX7CshGy0=ySZUUw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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="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, Jun 28, 2012 at 1:53 PM, Tim Deegan <tim@xen.org> wrote:
> At 17:57 +0100 on 27 Jun (1340819847), George Dunlap wrote:
>> xen,pod: Populate-on-demand reclaim improvements
>>
>> Rework populate-on-demand sweeping
>>
>> Last summer I did some work on testing whether our PoD sweeping code
>> was achieving its goals: namely, never crashing unnecessairly,
>> minimizing boot time, and maximizing the number of superpages in the
>> p2m table.
>>
>> This is the resulting patch series.
>
> I've acked these, but only applied 1/4, because:
>
> =A0- patch 4 needs an S-o-B line;
> =A0- patch 2 can't go in before patch 4 because it depends on the new
> =A0 return value of p2m_pod_zero_check_superpage(); and
> =A0- patch 3 can't go in before patch 2 or it removes the only caller of
> =A0 p2m_pod_zero_check_superpage() and breaks the build. :)
>
> If you reshuffle them as 4, 2, 3, add an S-o-B and address Andres's
> comment about the order constant, I'll push them straight in next time.

Oops!  Reordering sounds good.  I should have a respin this afternoon.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:04:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEOS-0001Zj-7L; Thu, 28 Jun 2012 13:04:20 +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 1SkEOQ-0001ZP-S3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:04:19 +0000
Received: from [85.158.143.99:51024] by server-2.bemta-4.messagelabs.com id
	42/10-17938-2565CEF4; Thu, 28 Jun 2012 13:04:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340888656!23205092!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22225 invoked from network); 28 Jun 2012 13:04:17 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:04:17 -0000
Received: by qcad1 with SMTP id d1so174045qca.30
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Jun 2012 06:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=j8Cr1BV55K3tv9oZ8YcxTa5+tZnbPwn3zJTELRUebP8=;
	b=fsgnsW6mhkwc5A75HHauGsO+JHvPcElxwd9X5Vjtu6JkJZ1KZYwUOiif+oTeC0pZsx
	dK0MaQhYlI6PtZU5pbDzSZBNhKlRK3RnAJOTCBzNWtQ/Ip5eBq++g1qZJhUD5oyOuRqm
	uKb3domk2qxNSXb61ioQeHdSW1exIjZ/D/vtRfOeGG+er0tNS5chaZTvaaAOoLw7GOPK
	zebTZ1av+5DJEZrDRB1+bf4XiX+HIQ3+lTAAKtQoBAe9/tcXJoc1Z3W30aS/aw3XpnP8
	b9Fb88GZURQilUwRIUUTgh0m5NcvuIE+/LK2S8v68hszy0X9NjvTYhkdaWdY5MpUHxcC
	T1PQ==
MIME-Version: 1.0
Received: by 10.229.69.30 with SMTP id x30mr793385qci.13.1340888655891; Thu,
	28 Jun 2012 06:04:15 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 06:04:15 -0700 (PDT)
In-Reply-To: <20120628125322.GN34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<20120628125322.GN34995@ocelot.phlegethon.org>
Date: Thu, 28 Jun 2012 14:04:15 +0100
X-Google-Sender-Auth: jSxFM-tilX8ixEY1rvUW_349leU
Message-ID: <CAFLBxZashQ9ecqeL6h-uCA6Tp2cQRoVnoNxX7CshGy0=ySZUUw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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="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, Jun 28, 2012 at 1:53 PM, Tim Deegan <tim@xen.org> wrote:
> At 17:57 +0100 on 27 Jun (1340819847), George Dunlap wrote:
>> xen,pod: Populate-on-demand reclaim improvements
>>
>> Rework populate-on-demand sweeping
>>
>> Last summer I did some work on testing whether our PoD sweeping code
>> was achieving its goals: namely, never crashing unnecessairly,
>> minimizing boot time, and maximizing the number of superpages in the
>> p2m table.
>>
>> This is the resulting patch series.
>
> I've acked these, but only applied 1/4, because:
>
> =A0- patch 4 needs an S-o-B line;
> =A0- patch 2 can't go in before patch 4 because it depends on the new
> =A0 return value of p2m_pod_zero_check_superpage(); and
> =A0- patch 3 can't go in before patch 2 or it removes the only caller of
> =A0 p2m_pod_zero_check_superpage() and breaks the build. :)
>
> If you reshuffle them as 4, 2, 3, add an S-o-B and address Andres's
> comment about the order constant, I'll push them straight in next time.

Oops!  Reordering sounds good.  I should have a respin this afternoon.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:04:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEOq-0001dd-Km; Thu, 28 Jun 2012 13:04:44 +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 1SkEOo-0001d8-Ig
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:04:42 +0000
Received: from [85.158.139.83:52210] by server-12.bemta-5.messagelabs.com id
	AC/56-25233-9665CEF4; Thu, 28 Jun 2012 13:04:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340888680!26024242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18671 invoked from network); 28 Jun 2012 13:04:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:04:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:04:40 +0100
Date: Thu, 28 Jun 2012 14:04:13 +0100
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: <1340706604-1313-21-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281403280.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-21-git-send-email-ian.campbell@citrix.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] [PATCH V2 21/40] arm: implement
 vcpu_show_execution_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 Tue, 26 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/dummy.S |    1 -
>  xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
>  2 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 03f7489..cab9522 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
>  DUMMY(arch_get_info_guest);
>  DUMMY(arch_vcpu_reset);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
>  DUMMY(get_page);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index d8eb5a9..f5f43da 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
>      panic("Error during %s-to-physical address translation\n", when);
>  }
>  
> -void show_registers(struct cpu_user_regs *regs)
> +struct reg_ctxt {
> +    uint32_t sctlr;
> +    uint32_t ttbr0, ttbr1, ttbcr;
> +};
> +static void _show_registers(struct cpu_user_regs *regs,
> +                            struct reg_ctxt *ctxt,
> +                            int guest_mode)
>  {
>      static const char *mode_strings[] = {
>         [PSR_MODE_USR] = "USR",
> @@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
>      print_xen_info();
>      printk("CPU:    %d\n", smp_processor_id());
>      printk("PC:     %08"PRIx32, regs->pc);
> -    if ( !guest_mode(regs) )
> +    if ( !guest_mode )
>              print_symbol(" %s", regs->pc);
>      printk("\n");
>      printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
> @@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
>      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);
>  
> -    if ( guest_mode(regs) )
> +    if ( guest_mode )
>      {
>          printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
>                 regs->sp_usr, regs->lr_usr, regs->cpsr);
> @@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
>                 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",
> -               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
> -        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
> +               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
> +        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
>          printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
>          printk("\n");
>      }
> @@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
>      printk("\n");
>  }
>  
> +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);
> +    _show_registers(regs, &ctxt, guest_mode(regs));
> +}
> +
> +void vcpu_show_registers(const struct vcpu *v)
> +{
> +    struct reg_ctxt ctxt;
> +    ctxt.sctlr = v->arch.sctlr;
> +    ctxt.ttbcr = 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);
> +}
> +
>  static void show_guest_stack(struct cpu_user_regs *regs)
>  {
>      printk("GUEST STACK GOES HERE\n");
> @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
>      show_stack(regs);
>  }
>  
> +void vcpu_show_execution_state(struct vcpu *v)
> +{
> +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> +           v->domain->domain_id, v->vcpu_id);
> +
> +    if ( v == current )
> +    {
> +        show_execution_state(guest_cpu_user_regs());
> +        return;
> +    }
> +
> +    vcpu_pause(v); /* acceptably dangerous */
> +
> +    vcpu_show_registers(v);
> +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
> +
> +    vcpu_unpause(v);
> +}
> +
>  static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
>  {
>      printk("Unexpected Trap: %s\n", msg);
> -- 
> 1.7.9.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 Thu Jun 28 13:04:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEOq-0001dd-Km; Thu, 28 Jun 2012 13:04:44 +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 1SkEOo-0001d8-Ig
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:04:42 +0000
Received: from [85.158.139.83:52210] by server-12.bemta-5.messagelabs.com id
	AC/56-25233-9665CEF4; Thu, 28 Jun 2012 13:04:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340888680!26024242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18671 invoked from network); 28 Jun 2012 13:04:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:04:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:04:40 +0100
Date: Thu, 28 Jun 2012 14:04:13 +0100
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: <1340706604-1313-21-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281403280.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-21-git-send-email-ian.campbell@citrix.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] [PATCH V2 21/40] arm: implement
 vcpu_show_execution_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 Tue, 26 Jun 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/dummy.S |    1 -
>  xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
>  2 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 03f7489..cab9522 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
>  DUMMY(arch_get_info_guest);
>  DUMMY(arch_vcpu_reset);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
>  DUMMY(get_page);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index d8eb5a9..f5f43da 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
>      panic("Error during %s-to-physical address translation\n", when);
>  }
>  
> -void show_registers(struct cpu_user_regs *regs)
> +struct reg_ctxt {
> +    uint32_t sctlr;
> +    uint32_t ttbr0, ttbr1, ttbcr;
> +};
> +static void _show_registers(struct cpu_user_regs *regs,
> +                            struct reg_ctxt *ctxt,
> +                            int guest_mode)
>  {
>      static const char *mode_strings[] = {
>         [PSR_MODE_USR] = "USR",
> @@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
>      print_xen_info();
>      printk("CPU:    %d\n", smp_processor_id());
>      printk("PC:     %08"PRIx32, regs->pc);
> -    if ( !guest_mode(regs) )
> +    if ( !guest_mode )
>              print_symbol(" %s", regs->pc);
>      printk("\n");
>      printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
> @@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
>      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);
>  
> -    if ( guest_mode(regs) )
> +    if ( guest_mode )
>      {
>          printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
>                 regs->sp_usr, regs->lr_usr, regs->cpsr);
> @@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
>                 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",
> -               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
> -        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
> +               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
> +        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
>          printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
>          printk("\n");
>      }
> @@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
>      printk("\n");
>  }
>  
> +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);
> +    _show_registers(regs, &ctxt, guest_mode(regs));
> +}
> +
> +void vcpu_show_registers(const struct vcpu *v)
> +{
> +    struct reg_ctxt ctxt;
> +    ctxt.sctlr = v->arch.sctlr;
> +    ctxt.ttbcr = 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);
> +}
> +
>  static void show_guest_stack(struct cpu_user_regs *regs)
>  {
>      printk("GUEST STACK GOES HERE\n");
> @@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
>      show_stack(regs);
>  }
>  
> +void vcpu_show_execution_state(struct vcpu *v)
> +{
> +    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
> +           v->domain->domain_id, v->vcpu_id);
> +
> +    if ( v == current )
> +    {
> +        show_execution_state(guest_cpu_user_regs());
> +        return;
> +    }
> +
> +    vcpu_pause(v); /* acceptably dangerous */
> +
> +    vcpu_show_registers(v);
> +    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
> +        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
> +
> +    vcpu_unpause(v);
> +}
> +
>  static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
>  {
>      printk("Unexpected Trap: %s\n", msg);
> -- 
> 1.7.9.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 Thu Jun 28 13:07:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:07: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 1SkERI-00020Q-SJ; Thu, 28 Jun 2012 13:07:16 +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 1SkERH-000204-Bq
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:07:15 +0000
Received: from [85.158.139.83:15559] by server-12.bemta-5.messagelabs.com id
	D6/AF-25233-FF65CEF4; Thu, 28 Jun 2012 13:07:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340888830!25710779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2132 invoked from network); 28 Jun 2012 13:07:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:07:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:07:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:07:02 +0100
Date: Thu, 28 Jun 2012 14:06:34 +0100
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: <1340706604-1313-26-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281406270.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-26-git-send-email-ian.campbell@citrix.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] [PATCH V2 26/40] arm: use interrupt safe spin locks
 in vgic_vcpu_inject_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 Tue, 26 Jun 2012, Ian Campbell wrote:
> This function can be called in both interrupt and regular context.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/vgic.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index af3523f..91d6166 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      uint8_t priority;
>      struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
>      struct pending_irq *iter, *n = irq_to_pending(v, irq);
> +    unsigned long flags;
>  
>      /* irq still pending */
>      if (!list_empty(&n->inflight))
> @@ -566,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>  
>      gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
>  
> -    spin_lock(&v->arch.vgic.lock);
> +    spin_lock_irqsave(&v->arch.vgic.lock, flags);
>      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
>      {
>          if ( iter->priority > priority )
> @@ -577,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>          }
>      }
>      list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
> -    spin_unlock(&v->arch.vgic.lock);
> +    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>      /* we have a new higher priority irq, inject it into the guest */
>  }
>  
> -- 
> 1.7.9.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 Thu Jun 28 13:07:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:07: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 1SkERI-00020Q-SJ; Thu, 28 Jun 2012 13:07:16 +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 1SkERH-000204-Bq
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:07:15 +0000
Received: from [85.158.139.83:15559] by server-12.bemta-5.messagelabs.com id
	D6/AF-25233-FF65CEF4; Thu, 28 Jun 2012 13:07:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340888830!25710779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2132 invoked from network); 28 Jun 2012 13:07:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:07:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:07:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:07:02 +0100
Date: Thu, 28 Jun 2012 14:06:34 +0100
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: <1340706604-1313-26-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281406270.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-26-git-send-email-ian.campbell@citrix.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] [PATCH V2 26/40] arm: use interrupt safe spin locks
 in vgic_vcpu_inject_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 Tue, 26 Jun 2012, Ian Campbell wrote:
> This function can be called in both interrupt and regular context.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/vgic.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index af3523f..91d6166 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      uint8_t priority;
>      struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
>      struct pending_irq *iter, *n = irq_to_pending(v, irq);
> +    unsigned long flags;
>  
>      /* irq still pending */
>      if (!list_empty(&n->inflight))
> @@ -566,7 +567,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>  
>      gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
>  
> -    spin_lock(&v->arch.vgic.lock);
> +    spin_lock_irqsave(&v->arch.vgic.lock, flags);
>      list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
>      {
>          if ( iter->priority > priority )
> @@ -577,7 +578,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>          }
>      }
>      list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
> -    spin_unlock(&v->arch.vgic.lock);
> +    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>      /* we have a new higher priority irq, inject it into the guest */
>  }
>  
> -- 
> 1.7.9.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 Thu Jun 28 13:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkET4-0002Fp-Cq; Thu, 28 Jun 2012 13:09: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 1SkET2-0002Fb-So
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:09:05 +0000
Received: from [85.158.143.35:2042] by server-3.bemta-4.messagelabs.com id
	84/40-05808-0775CEF4; Thu, 28 Jun 2012 13:09:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340888923!13099702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23552 invoked from network); 28 Jun 2012 13:08:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:08:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:08:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:08:43 +0100
Date: Thu, 28 Jun 2012 14:08:16 +0100
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: <1340706604-1313-25-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281408110.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-25-git-send-email-ian.campbell@citrix.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] [PATCH V2 25/40] arm: split pending SPIs (global)
 out from pending PPIs and SGIs (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

On Tue, 26 Jun 2012, Ian Campbell wrote:
> This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
> seems more logical.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/vgic.c          |   12 +++++++-----
>  xen/include/asm-arm/domain.h |   10 ++++++++++
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 629a0da..af3523f 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
>      d->arch.vgic.shared_irqs =
>          xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      d->arch.vgic.pending_irqs =
> -        xmalloc_array(struct pending_irq,
> -                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
> -    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
> +        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> +    for (i=0; i<d->arch.vgic.nr_lines; i++)
>          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
>      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
>          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> @@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
>  
>      spin_lock_init(&v->arch.vgic.private_irqs.lock);
>  
> +    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> +    for (i = 0; i < 32; i++)
> +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> +
>      /* For SGI and PPI the target is always this CPU */
>      for ( i = 0 ; i < 8 ; i++ )
>          v->arch.vgic.private_irqs.itargets[i] =
> @@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>      /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
>       * are used for SPIs; the rests are used for per cpu irqs */
>      if ( irq < 32 )
> -        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
> -            + v->domain->arch.vgic.nr_lines];
> +        n = &v->arch.vgic.pending_irqs[irq];
>      else
>          n = &v->domain->arch.vgic.pending_irqs[irq - 32];
>      return n;
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 620b26e..32deb52 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -46,6 +46,10 @@ struct arch_domain
>          int ctlr;
>          int nr_lines;
>          struct vgic_irq_rank *shared_irqs;
> +        /*
> +         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
> +         * struct arch_vcpu.
> +         */
>          struct pending_irq *pending_irqs;
>      } vgic;
>  
> @@ -114,7 +118,13 @@ struct arch_vcpu
>      uint32_t gic_lr[64];
>  
>      struct {
> +        /*
> +         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
> +         * struct arch_domain.
> +         */
> +        struct pending_irq pending_irqs[32];
>          struct vgic_irq_rank private_irqs;
> +
>          /* This list is ordered by IRQ priority and it is used to keep
>           * track of the IRQs that the VGIC injected into the guest.
>           * Depending on the availability of LR registers, the IRQs might
> -- 
> 1.7.9.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 Thu Jun 28 13:09:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkET4-0002Fp-Cq; Thu, 28 Jun 2012 13:09: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 1SkET2-0002Fb-So
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:09:05 +0000
Received: from [85.158.143.35:2042] by server-3.bemta-4.messagelabs.com id
	84/40-05808-0775CEF4; Thu, 28 Jun 2012 13:09:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340888923!13099702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23552 invoked from network); 28 Jun 2012 13:08:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:08:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13269650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:08:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:08:43 +0100
Date: Thu, 28 Jun 2012 14:08:16 +0100
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: <1340706604-1313-25-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1206281408110.27860@kaball.uk.xensource.com>
References: <1340706574.3832.57.camel@zakaz.uk.xensource.com>
	<1340706604-1313-1-git-send-email-ian.campbell@citrix.com>
	<1340706604-1313-25-git-send-email-ian.campbell@citrix.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] [PATCH V2 25/40] arm: split pending SPIs (global)
 out from pending PPIs and SGIs (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

On Tue, 26 Jun 2012, Ian Campbell wrote:
> This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
> seems more logical.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/vgic.c          |   12 +++++++-----
>  xen/include/asm-arm/domain.h |   10 ++++++++++
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 629a0da..af3523f 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
>      d->arch.vgic.shared_irqs =
>          xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      d->arch.vgic.pending_irqs =
> -        xmalloc_array(struct pending_irq,
> -                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
> -    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
> +        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
> +    for (i=0; i<d->arch.vgic.nr_lines; i++)
>          INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
>      for (i=0; i<DOMAIN_NR_RANKS(d); i++)
>          spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
> @@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
>  
>      spin_lock_init(&v->arch.vgic.private_irqs.lock);
>  
> +    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
> +    for (i = 0; i < 32; i++)
> +        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
> +
>      /* For SGI and PPI the target is always this CPU */
>      for ( i = 0 ; i < 8 ; i++ )
>          v->arch.vgic.private_irqs.itargets[i] =
> @@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>      /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
>       * are used for SPIs; the rests are used for per cpu irqs */
>      if ( irq < 32 )
> -        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
> -            + v->domain->arch.vgic.nr_lines];
> +        n = &v->arch.vgic.pending_irqs[irq];
>      else
>          n = &v->domain->arch.vgic.pending_irqs[irq - 32];
>      return n;
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 620b26e..32deb52 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -46,6 +46,10 @@ struct arch_domain
>          int ctlr;
>          int nr_lines;
>          struct vgic_irq_rank *shared_irqs;
> +        /*
> +         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
> +         * struct arch_vcpu.
> +         */
>          struct pending_irq *pending_irqs;
>      } vgic;
>  
> @@ -114,7 +118,13 @@ struct arch_vcpu
>      uint32_t gic_lr[64];
>  
>      struct {
> +        /*
> +         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
> +         * struct arch_domain.
> +         */
> +        struct pending_irq pending_irqs[32];
>          struct vgic_irq_rank private_irqs;
> +
>          /* This list is ordered by IRQ priority and it is used to keep
>           * track of the IRQs that the VGIC injected into the guest.
>           * Depending on the availability of LR registers, the IRQs might
> -- 
> 1.7.9.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 Thu Jun 28 13:11:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEVg-0002XK-Vb; Thu, 28 Jun 2012 13:11: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 1SkEVg-0002XB-2b
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:11:48 +0000
Received: from [85.158.143.99:25868] by server-2.bemta-4.messagelabs.com id
	7A/0F-17938-3185CEF4; Thu, 28 Jun 2012 13:11:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340889106!17994257!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10694 invoked from network); 28 Jun 2012 13:11:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 13:11:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 14:12:05 +0100
Message-Id: <4FEC7460020000780008C821@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 14:12:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
	<CC12149E.444D1%keir@xen.org>
In-Reply-To: <CC12149E.444D1%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:03, Keir Fraser <keir@xen.org> wrote:
> On 25/06/2012 11:54, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
>> as the whole function domain_pause_for_debugger() is pointless to be
>> compiled when there's no arch support, simply introduce another HAS_*
>> macro, enabled only on x86.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> How did arch/arm build at all then, previously, with this function present
> for a long time in common code?

Prior to said c/s adding a reference to ->arch.gdbsx_vcpu_event,
the function wasn't arch-specific at all.

> Would a better fix be just to move the
> function to arch/x86/domain.c, since it is only called by arch/x86?

I'd say no - the function really ought to be generic. Any arch
wanting gdbsx support would have to add a respective field to
its arch_vcpu. Or alternatively the field itself should get moved
into struct vcpu, perhaps dependent upon some CONFIG_*.
(This is also why I didn't want to put in e.g. a CONFIG_X86
conditional, which would have been a smaller change.)

Jan

>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>>  
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>>  HAS_NS16550 := y
>>  HAS_EHCI := y
>>  HAS_KEXEC := y
>> +HAS_GDBSX := y
>>  xenoprof := y
>>  
>>  #
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>>          vcpu_check_shutdown(v);
>>  }
>>  
>> +#ifdef HAS_GDBSX
>>  void domain_pause_for_debugger(void)
>>  {
>>      struct domain *d = current->domain;
>> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>>      if (current->arch.gdbsx_vcpu_event == 0)
>>          send_global_virq(VIRQ_DEBUGGER);
>>  }
>> +#endif
>>  
>>  /* Complete domain destroy after RCU readers are not holding old 
> references.
>> */
>>  static void complete_domain_destroy(struct rcu_head *head)
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/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 Jun 28 13:11:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEVg-0002XK-Vb; Thu, 28 Jun 2012 13:11: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 1SkEVg-0002XB-2b
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:11:48 +0000
Received: from [85.158.143.99:25868] by server-2.bemta-4.messagelabs.com id
	7A/0F-17938-3185CEF4; Thu, 28 Jun 2012 13:11:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1340889106!17994257!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10694 invoked from network); 28 Jun 2012 13:11:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 13:11:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 14:12:05 +0100
Message-Id: <4FEC7460020000780008C821@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 14:12:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4FE85F77020000780008BAB7@nat28.tlf.novell.com>
	<CC12149E.444D1%keir@xen.org>
In-Reply-To: <CC12149E.444D1%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:03, Keir Fraser <keir@xen.org> wrote:
> On 25/06/2012 11:54, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
>> as the whole function domain_pause_for_debugger() is pointless to be
>> compiled when there's no arch support, simply introduce another HAS_*
>> macro, enabled only on x86.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> How did arch/arm build at all then, previously, with this function present
> for a long time in common code?

Prior to said c/s adding a reference to ->arch.gdbsx_vcpu_event,
the function wasn't arch-specific at all.

> Would a better fix be just to move the
> function to arch/x86/domain.c, since it is only called by arch/x86?

I'd say no - the function really ought to be generic. Any arch
wanting gdbsx support would have to add a respective field to
its arch_vcpu. Or alternatively the field itself should get moved
into struct vcpu, perhaps dependent upon some CONFIG_*.
(This is also why I didn't want to put in e.g. a CONFIG_X86
conditional, which would have been a smaller change.)

Jan

>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>>  
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>>  HAS_NS16550 := y
>>  HAS_EHCI := y
>>  HAS_KEXEC := y
>> +HAS_GDBSX := y
>>  xenoprof := y
>>  
>>  #
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>>          vcpu_check_shutdown(v);
>>  }
>>  
>> +#ifdef HAS_GDBSX
>>  void domain_pause_for_debugger(void)
>>  {
>>      struct domain *d = current->domain;
>> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>>      if (current->arch.gdbsx_vcpu_event == 0)
>>          send_global_virq(VIRQ_DEBUGGER);
>>  }
>> +#endif
>>  
>>  /* Complete domain destroy after RCU readers are not holding old 
> references.
>> */
>>  static void complete_domain_destroy(struct rcu_head *head)
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/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 Jun 28 13:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:30: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 1SkEnX-00030z-Cm; Thu, 28 Jun 2012 13:30:15 +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 1SkEnV-00030g-5V
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:30:13 +0000
Received: from [85.158.138.51:50938] by server-9.bemta-3.messagelabs.com id
	C9/F5-10419-36C5CEF4; Thu, 28 Jun 2012 13:30:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340890211!28902279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7605 invoked from network); 28 Jun 2012 13:30:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:30:10 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:30:10 +0100
Message-ID: <4FEC5C39.4080606@citrix.com>
Date: Thu, 28 Jun 2012 14:29:29 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
	<1340877257.10942.21.camel@zakaz.uk.xensource.com>
	<4FEC2CD9.3070007@citrix.com>
	<1340878212.10942.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340878212.10942.30.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-28 at 11:07 +0100, Roger Pau Monne wrote:
>> Ian Campbell wrote:
>>> On Thu, 2012-06-28 at 10:41 +0100, Roger Pau Monne wrote:
>>>> I think the most suitable place is
>>>> libxl_create.c:initiate_domain_create, which also sets the defaults for
>>>> disk devices,
>>> .. by calling setdefaults though.
>> Yes, sorry.
>>
>>> I'd like to keep all such logic in setdefaults as far as possible.
>>>
>>> libxl__devic_nic_setdefautls is an internal function so we can add
>>> either a domid or type parameter quite easily. Are there any callsites
>>> which would be unable to provide one or the other of those?
>>>
>>> Probably domid is best, with setdefaults calling libxl__domain_type as
>>> necessary.
>> I think it would be appropriate to pass domid to every setdefault
>> function, even if it's only used by nic now:
>>
>> libxl__device_disk_setdefault
>> libxl__device_nic_setdefault
>> libxl__device_vfb_setdefault
>> libxl__device_vkb_setdefault
>> libxl__device_pci_setdefault
>>
>> To keep the symmetry, are you ok with that?
>
> Lets make that cleanup in 4.3 and just do the necessary for 4.2.

Ok, I've just changed libxl__device_nic_setdefault to take a domid 
parameter.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:30:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:30: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 1SkEnX-00030z-Cm; Thu, 28 Jun 2012 13:30:15 +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 1SkEnV-00030g-5V
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:30:13 +0000
Received: from [85.158.138.51:50938] by server-9.bemta-3.messagelabs.com id
	C9/F5-10419-36C5CEF4; Thu, 28 Jun 2012 13:30:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340890211!28902279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7605 invoked from network); 28 Jun 2012 13:30:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:30:10 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:30:10 +0100
Message-ID: <4FEC5C39.4080606@citrix.com>
Date: Thu, 28 Jun 2012 14:29:29 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-11-git-send-email-roger.pau@citrix.com>
	<20452.22966.110320.601890@mariner.uk.xensource.com>
	<4FE9E153.1050309@citrix.com> <20120626165808.GC2058@reaktio.net>
	<1340787043.29172.10.camel@zakaz.uk.xensource.com>
	<4FEC2248.4080005@citrix.com>
	<1340875618.10942.14.camel@zakaz.uk.xensource.com>
	<4FEC26C2.6070901@citrix.com>
	<1340877257.10942.21.camel@zakaz.uk.xensource.com>
	<4FEC2CD9.3070007@citrix.com>
	<1340878212.10942.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340878212.10942.30.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF 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-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-28 at 11:07 +0100, Roger Pau Monne wrote:
>> Ian Campbell wrote:
>>> On Thu, 2012-06-28 at 10:41 +0100, Roger Pau Monne wrote:
>>>> I think the most suitable place is
>>>> libxl_create.c:initiate_domain_create, which also sets the defaults for
>>>> disk devices,
>>> .. by calling setdefaults though.
>> Yes, sorry.
>>
>>> I'd like to keep all such logic in setdefaults as far as possible.
>>>
>>> libxl__devic_nic_setdefautls is an internal function so we can add
>>> either a domid or type parameter quite easily. Are there any callsites
>>> which would be unable to provide one or the other of those?
>>>
>>> Probably domid is best, with setdefaults calling libxl__domain_type as
>>> necessary.
>> I think it would be appropriate to pass domid to every setdefault
>> function, even if it's only used by nic now:
>>
>> libxl__device_disk_setdefault
>> libxl__device_nic_setdefault
>> libxl__device_vfb_setdefault
>> libxl__device_vkb_setdefault
>> libxl__device_pci_setdefault
>>
>> To keep the symmetry, are you ok with that?
>
> Lets make that cleanup in 4.3 and just do the necessary for 4.2.

Ok, I've just changed libxl__device_nic_setdefault to take a domid 
parameter.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkEoT-00037L-Vw; Thu, 28 Jun 2012 13:31:13 +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 1SkEoT-00037A-2D
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:31:13 +0000
Received: from [85.158.138.51:25396] by server-4.bemta-3.messagelabs.com id
	33/D0-17105-B9C5CEF4; Thu, 28 Jun 2012 13:31:07 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340890266!21106104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22067 invoked from network); 28 Jun 2012 13:31:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:31:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:30:47 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:30:47 +0100
Message-ID: <4FEC5C5F.2000304@citrix.com>
Date: Thu, 28 Jun 2012 14:30:07 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
	<20457.61377.77775.31123@mariner.uk.xensource.com>
	<4FEC2983.5040500@citrix.com>
	<1340877416.10942.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340877416.10942.22.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-28 at 10:53 +0100, Roger Pau Monne wrote:
>> Ian Jackson wrote:
>>> Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
>>>> Ian Jackson wrote:
>>>>> Should we rename the functions libxl_*nic* or the structures *vif* ?
>>>>> Or should we rename both, to "net" perhaps ?
>>>> I think we should either rename the strucutres to nic also (because the
>>>> also hold ioemu cards), or get rid of nic/vif an name everything net.
>>> Can you try to rename everything to `net' and see if that turns out to
>>> be an impenetrable yak ?
>> I think it is much more easy to rename everything to nic, which provides
>> the same level of abstraction from my PoV. Renaming everything to net
>> it's a rather very big change. Would you be ok with that change?
>
> I'd be happy with nic, I think it fits better with libxl_device_disk
> anyway. (if it were libxl_device_net would be more analogous to
> libxl_device_storage or something)

Done, I've added a pre-patch to rename every *vif* to nic.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:31:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkEoT-00037L-Vw; Thu, 28 Jun 2012 13:31:13 +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 1SkEoT-00037A-2D
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:31:13 +0000
Received: from [85.158.138.51:25396] by server-4.bemta-3.messagelabs.com id
	33/D0-17105-B9C5CEF4; Thu, 28 Jun 2012 13:31:07 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340890266!21106104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22067 invoked from network); 28 Jun 2012 13:31:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:31:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:30:47 +0000
Received: from dhcp-3-120.uk.xensource.com (10.80.3.120) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:30:47 +0100
Message-ID: <4FEC5C5F.2000304@citrix.com>
Date: Thu, 28 Jun 2012 14:30:07 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com>
	<1339676475-33265-8-git-send-email-roger.pau@citrix.com>
	<20452.22802.102071.107153@mariner.uk.xensource.com>
	<4FE9E091.2090001@citrix.com>
	<20457.61377.77775.31123@mariner.uk.xensource.com>
	<4FEC2983.5040500@citrix.com>
	<1340877416.10942.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340877416.10942.22.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 07/13] libxl: convert
 libxl_device_nic_add to an async operation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Campbell wrote:
> On Thu, 2012-06-28 at 10:53 +0100, Roger Pau Monne wrote:
>> Ian Jackson wrote:
>>> Roger Pau Monne writes ("Re: [PATCH v6 07/13] libxl: convert libxl_device_nic_add to an async operation"):
>>>> Ian Jackson wrote:
>>>>> Should we rename the functions libxl_*nic* or the structures *vif* ?
>>>>> Or should we rename both, to "net" perhaps ?
>>>> I think we should either rename the strucutres to nic also (because the
>>>> also hold ioemu cards), or get rid of nic/vif an name everything net.
>>> Can you try to rename everything to `net' and see if that turns out to
>>> be an impenetrable yak ?
>> I think it is much more easy to rename everything to nic, which provides
>> the same level of abstraction from my PoV. Renaming everything to net
>> it's a rather very big change. Would you be ok with that change?
>
> I'd be happy with nic, I think it fits better with libxl_device_disk
> anyway. (if it were libxl_device_net would be more analogous to
> libxl_device_storage or something)

Done, I've added a pre-patch to rename every *vif* to nic.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkEvN-0003cz-1L; Thu, 28 Jun 2012 13:38: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 1SkEvL-0003cq-BR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:38:20 +0000
Received: from [85.158.138.51:46915] by server-10.bemta-3.messagelabs.com id
	6D/62-01753-A4E5CEF4; Thu, 28 Jun 2012 13:38:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340890696!30090692!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9479 invoked from network); 28 Jun 2012 13:38:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:38:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:38:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:38:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkEvH-0008NP-SP; Thu, 28 Jun 2012 13:38:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkEvH-0005aO-RC;
	Thu, 28 Jun 2012 14:38:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.24135.825405.29982@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 14:38:15 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> This is v5 of my series to asyncify save/restore, rebased to tip and
> retested.  There are minor changes to 3 patches, as discussed on-list,
> marked with "*" below:
...
>   * 06/21 libxl: domain save/restore: run in a separate process
...
> However, first I will invite Shriram to check that Remus is still
> working.  (I can't conveniently do this with this message due to
> shoddiness in git-send-email.)

Following testing by Shriram (thanks) I have an updated version of
06/21.  For the sake of everyone's sanity (and your MUAs) I shan't
repost the whole series.

Here is v6 of 06/21, which is simply the previous one with my earlier
fixup patch folded in.

CC Ian Campbell since he'd acked the previous one.  Ian, I have left
your ack on this version.  I trust that's OK.

Thanks,
Ian.


From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: domain save/restore: run in a separate process

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

-
Changes in v6:
 * The void* passed to the callback was being treated as a
   libxl__domain_suspend_state* by the remus callbacks; this is a
   holdover from a much earlier version of the series.  It is now
   properly converted to a libxl__save_helper_state and then the dss
   extracted with CONTAINER_OF.
 * The way remus works means that the toolstack save callback is
   invoked more than once, which the helper's implementation was not
   prepared to deal with.  Fix this by moving the rewind of the fd
   into the helper.

Changes in v5:
 * assert that preserve_fds are >2.

Changes in v4:
 * Migration stream fd is handled specially by the run_helper
   function, rather than simply being a numarg.  Specifically:
     - dup it to a safe fd number if necessary.
     - clear cloexec flag fd before execing helper
 * Toolstack data fd argument to run_helper replaced with
   generic preserve_fds array, which get cloexec cleared.
 * libxl__xc_domain_save uses supplied callback function pointer,
   rather than calling libxl__toolstack_save directly;
   toolstack data save callback is only supplied to libxc if
   in-libxl caller supplied a callback.
 * libxl-save-helper is not needlessly linked against libxl.
 * Code which prepares pipes for helper clarified.
 * Deal properly with, and log properly, POLLPRI/POLLERR on
   pipe to save helper.
 * Spelling fix in perl script comment.
 * In message generator, use better names for the ends of serial
   conditional here documents.
 * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.

---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   22 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   42 +++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  361 +++++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  283 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1146 insertions(+), 40 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..ddc2624 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -169,7 +183,9 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9c3c671..7b92539 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -662,7 +662,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -702,7 +703,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -722,10 +722,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c44dec0..0e0dbee 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,16 +467,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -529,9 +533,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -597,9 +602,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -739,9 +745,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -810,6 +816,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -823,7 +831,8 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
@@ -836,7 +845,8 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
@@ -864,7 +874,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -925,8 +936,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -935,10 +945,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7cf1b04..1a7b526 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..a6abcda 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,30 @@
 
 #include "libxl_internal.h"
 
+/* stream_fd is as from the caller (eventually, the application).
+ * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
+ * The actual fd value is not included in the supplied argnums; rather
+ * it will be automatically supplied by run_helper as the 2nd argument.
+ *
+ * preserve_fds are fds that the caller is intending to pass to the
+ * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
+ * An entry may be -1 in which case it will be ignored.
+ */
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg,
+                       int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +51,337 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc, toolstack_data_fd = -1;
+    uint32_t toolstack_data_len = 0;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    if (dss->shs.callbacks.save.toolstack_save) {
+        r = dss->shs.callbacks.save.toolstack_save
+            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        dss->shs.toolstack_data_file = tmpfile();
+        if (!dss->shs.toolstack_data_file) {
+            LOGE(ERROR, "cannot create toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+        r = libxl_write_exactly(CTX, toolstack_data_fd,
+                                toolstack_data_buf, toolstack_data_len,
+                                "toolstack data tmpfile", 0);
+        if (r) { rc = ERROR_FAIL; goto out; }
+    }
+
+    const unsigned long argnums[] = {
+        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               &toolstack_data_fd, 1,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[4 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    const char **stream_fd_arg = arg++;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    int childfd;
+    for (childfd=0; childfd<2; childfd++) {
+        /* Setting up the pipe for the child's fd childfd */
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
+        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
+        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
+        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        if (stream_fd <= 2) {
+            stream_fd = dup(stream_fd);
+            if (stream_fd < 0) {
+                LOGE(ERROR,"dup migration stream fd");
+                exit(-1);
+            }
+        }
+        libxl_fd_set_cloexec(CTX, stream_fd, 0);
+        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
+
+        for (i=0; i<num_preserve_fds; i++)
+            if (preserve_fds[i] >= 0) {
+                assert(preserve_fds[i] > 2);
+                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
+            }
+
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & (POLLERR|POLLPRI)) {
+        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
+            shs->stdout_what, revents);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..772251a
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,283 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
+    if (r) fail(errno,"rewind toolstack data tmpfile");
+
+    *buf = xmalloc(toolstack_save_len);
+    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        if (toolstack_save_fd >= 0)
+            helper_save_callbacks.toolstack_save = toolstack_save_cb;
+
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..c45986e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,397 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copious debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .=
+        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END_BOTH
+
+#include "libxl_internal.h"
+
+END_CALLOUT
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END_HELPER
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END_ALWAYS
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END_DEBUG
+    switch (mtype) {
+
+END_ALWAYS
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END_DEBUG
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END_ALWAYS
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name",
+               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
+    int r = ${helper}_getreply(user);
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END_DEBUG
+    return r;
+END_ALWAYS
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
tg: (52b6131..) t/xen/xc.save-restore-protocol (depends on: t/xen/xl.ao.suspend.pre)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkEvN-0003cz-1L; Thu, 28 Jun 2012 13:38: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 1SkEvL-0003cq-BR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:38:20 +0000
Received: from [85.158.138.51:46915] by server-10.bemta-3.messagelabs.com id
	6D/62-01753-A4E5CEF4; Thu, 28 Jun 2012 13:38:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340890696!30090692!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9479 invoked from network); 28 Jun 2012 13:38:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:38:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:38:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:38:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkEvH-0008NP-SP; Thu, 28 Jun 2012 13:38:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkEvH-0005aO-RC;
	Thu, 28 Jun 2012 14:38:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.24135.825405.29982@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 14:38:15 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> This is v5 of my series to asyncify save/restore, rebased to tip and
> retested.  There are minor changes to 3 patches, as discussed on-list,
> marked with "*" below:
...
>   * 06/21 libxl: domain save/restore: run in a separate process
...
> However, first I will invite Shriram to check that Remus is still
> working.  (I can't conveniently do this with this message due to
> shoddiness in git-send-email.)

Following testing by Shriram (thanks) I have an updated version of
06/21.  For the sake of everyone's sanity (and your MUAs) I shan't
repost the whole series.

Here is v6 of 06/21, which is simply the previous one with my earlier
fixup patch folded in.

CC Ian Campbell since he'd acked the previous one.  Ian, I have left
your ack on this version.  I trust that's OK.

Thanks,
Ian.


From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: domain save/restore: run in a separate process

libxenctrl expects to be able to simply run the save or restore
operation synchronously.  This won't work well in a process which is
trying to handle multiple domains.

The options are:

 - Block such a whole process (eg, the whole of libvirt) while
   migration completes (or until it fails).

 - Create a thread to run xc_domain_save and xc_domain_restore on.
   This is quite unpalatable.  Multithreaded programming is error
   prone enough without generating threads in libraries, particularly
   if the thread does some very complex operation.

 - Fork and run the operation in the child without execing.  This is
   no good because we would need to negotiate with the caller about
   fds we would inherit (and we might be a very large process).

 - Fork and exec a helper.

Of these options the latter is the most palatable.

Consequently:

 * A new helper program libxl-save-helper (which does both save and
   restore).  It will be installed in /usr/lib/xen/bin.  It does not
   link against libxl, only libxc, and its error handling does not
   need to be very advanced.  It does contain a plumbing through of
   the logging interface into the callback stream.

 * A small ad-hoc protocol between the helper and libxl which allows
   log messages and the libxc callbacks to be passed up and down.
   Protocol doc comment is in libxl_save_helper.c.

 * To avoid a lot of tedium the marshalling boilerplate (stubs for the
   helper and the callback decoder for libxl) is generated with a
   small perl script.

 * Implement new functionality to spawn the helper, monitor its
   output, provide responses, and check on its exit status.

 * The functions libxl__xc_domain_restore_done and
   libxl__xc_domain_save_done now turn out to want be called in the
   same place.  So make their state argument a void* so that the two
   functions are type compatible.

The domain save path still writes the qemu savefile synchronously.
This will need to be fixed in a subsequent patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

-
Changes in v6:
 * The void* passed to the callback was being treated as a
   libxl__domain_suspend_state* by the remus callbacks; this is a
   holdover from a much earlier version of the series.  It is now
   properly converted to a libxl__save_helper_state and then the dss
   extracted with CONTAINER_OF.
 * The way remus works means that the toolstack save callback is
   invoked more than once, which the helper's implementation was not
   prepared to deal with.  Fix this by moving the rewind of the fd
   into the helper.

Changes in v5:
 * assert that preserve_fds are >2.

Changes in v4:
 * Migration stream fd is handled specially by the run_helper
   function, rather than simply being a numarg.  Specifically:
     - dup it to a safe fd number if necessary.
     - clear cloexec flag fd before execing helper
 * Toolstack data fd argument to run_helper replaced with
   generic preserve_fds array, which get cloexec cleared.
 * libxl__xc_domain_save uses supplied callback function pointer,
   rather than calling libxl__toolstack_save directly;
   toolstack data save callback is only supplied to libxc if
   in-libxl caller supplied a callback.
 * libxl-save-helper is not needlessly linked against libxl.
 * Code which prepares pipes for helper clarified.
 * Deal properly with, and log properly, POLLPRI/POLLERR on
   pipe to save helper.
 * Spelling fix in perl script comment.
 * In message generator, use better names for the ends of serial
   conditional here documents.
 * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)

Changes in v3:
 * Suppress errno value in debug message when helper reports successful
   completion.
 * Significant consequential changes to cope with changes to
   earlier patches in the series.

Changes in v2:
 * Helper path can be overridden by an environment variable for testing.
 * Add a couple of debug logging messages re toolstack data.
 * Fixes from testing.
 * Helper protocol message lengths (and numbers) are 16-bit which
   more clearly avoids piling lots of junk on the stack.
 * Merged with remus changes.
 * Callback implementations in libxl now called via pointers
   so remus can have its own callbacks.
 * Better namespace prefixes on autogenerated names etc.
 * Autogenerator can generate debugging printfs too.

---
 .gitignore                         |    1 +
 .hgignore                          |    2 +
 tools/libxl/Makefile               |   22 ++-
 tools/libxl/libxl_create.c         |   22 ++-
 tools/libxl/libxl_dom.c            |   42 +++--
 tools/libxl/libxl_internal.h       |   56 +++++-
 tools/libxl/libxl_save_callout.c   |  361 +++++++++++++++++++++++++++++++-
 tools/libxl/libxl_save_helper.c    |  283 +++++++++++++++++++++++++
 tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
 9 files changed, 1146 insertions(+), 40 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7770e54..3451e52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,6 +353,7 @@ 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
diff --git a/.hgignore b/.hgignore
index 27d8f79..05304ea 100644
--- a/.hgignore
+++ b/.hgignore
@@ -180,9 +180,11 @@
 ^tools/libxl/_.*\.c$
 ^tools/libxl/libxlu_cfg_y\.output$
 ^tools/libxl/xl$
+^tools/libxl/libxl-save-helper$
 ^tools/libxl/testidl$
 ^tools/libxl/testidl\.c$
 ^tools/libxl/tmp\..*$
+^tools/libxl/.*\.new$
 ^tools/libvchan/vchan-node[12]$
 ^tools/libaio/src/.*\.ol$
 ^tools/libaio/src/.*\.os$
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1d8b80a..ddc2624 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o \
 			libxl_json.o libxl_aoutils.o \
-			libxl_save_callout.o \
+			libxl_save_callout.o _libxl_save_msgs_callout.o \
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
+	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
+AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
 $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 
-CLIENTS = xl testidl
+CLIENTS = xl testidl libxl-save-helper
 
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
 
+SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
+$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
 testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
@@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
 	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
+_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
+_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
+		libxl_save_msgs_gen.pl
+	$(PERL) -w $< $@ >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl.h: _libxl_types.h
 libxl_json.h: _libxl_types_json.h
 libxl_internal.h: _libxl_types_internal.h _paths.h
@@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
+libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -169,7 +183,9 @@ install: all
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
+	$(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
 	$(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
 	ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9c3c671..7b92539 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -662,7 +662,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
-    struct restore_callbacks *const callbacks = &dcs->callbacks;
+    libxl__srm_restore_autogen_callbacks *const callbacks =
+        &dcs->shs.callbacks.restore.a;
 
     if (rc) domcreate_rebuild_done(egc, dcs, rc);
 
@@ -702,7 +703,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         callbacks->toolstack_restore = libxl__toolstack_restore;
-        callbacks->data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -722,10 +722,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
-void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                   libxl__domain_create_state *dcs,
+void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
+          unsigned long console_mfn, unsigned long genidad, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
+    STATE_AO_GC(dcs->ao);
+    libxl__domain_build_state *const state = &dcs->build_state;
+
+    state->store_mfn =            store_mfn;
+    state->console_mfn =          console_mfn;
+    state->vm_generationid_addr = genidad;
+    shs->need_results =           0;
+}
+
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                    int ret, int retval, int errnoval)
 {
+    libxl__domain_create_state *dcs = dcs_void;
     STATE_AO_GC(dcs->ao);
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c44dec0..0e0dbee 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -467,16 +467,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
-        uint32_t size, void *data)
+                             uint32_t size, void *user)
 {
-    libxl__gc *gc = data;
-    libxl_ctx *ctx = gc->owner;
+    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;
     struct libxl__physmap_info* pi;
     char *xs_path;
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
+
     if (size < sizeof(version) + sizeof(count)) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
         return -1;
@@ -529,9 +533,10 @@ static void domain_suspend_done(libxl__egc *egc,
 /*----- callbacks, called by xc_domain_save -----*/
 
 int libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned int enable, void *data)
+                               (int domid, unsigned enable, void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     char *path;
     bool rc;
@@ -597,9 +602,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-int libxl__domain_suspend_common_callback(void *data)
+int libxl__domain_suspend_common_callback(void *user)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = user;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
     unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
     int ret;
@@ -739,9 +745,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
-        uint32_t *len, void *data)
+        uint32_t *len, void *dss_void)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
     int i = 0;
     char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
@@ -810,6 +816,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
         ptr += sizeof(struct libxl__physmap_info) + namelen;
     }
 
+    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
+
     return 0;
 }
 
@@ -823,7 +831,8 @@ static int libxl__remus_domain_suspend_callback(void *data)
 
 static int libxl__remus_domain_resume_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
 
     /* Resumes the domain and the device model */
@@ -836,7 +845,8 @@ static int libxl__remus_domain_resume_callback(void *data)
 
 static int libxl__remus_domain_checkpoint_callback(void *data)
 {
-    libxl__domain_suspend_state *dss = data;
+    libxl__save_helper_state *shs = data;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     STATE_AO_GC(dss->ao);
 
     /* This would go into tailbuf. */
@@ -864,7 +874,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     const int live = dss->live;
     const int debug = dss->debug;
     const libxl_domain_remus_info *const r_info = dss->remus;
-    struct save_callbacks *const callbacks = &dss->callbacks;
+    libxl__srm_save_autogen_callbacks *const callbacks =
+        &dss->shs.callbacks.save.a;
 
     switch (type) {
     case LIBXL_DOMAIN_TYPE_HVM: {
@@ -925,8 +936,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
         callbacks->suspend = libxl__domain_suspend_common_callback;
 
     callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
-    callbacks->toolstack_save = libxl__toolstack_save;
-    callbacks->data = dss;
+    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
 
     libxl__xc_domain_save(egc, dss, vm_generationid_addr);
     return;
@@ -935,10 +945,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     domain_suspend_done(egc, dss, rc);
 }
 
-void libxl__xc_domain_save_done(libxl__egc *egc,
-                                libxl__domain_suspend_state *dss,
+void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
                                 int rc, int retval, int errnoval)
 {
+    libxl__domain_suspend_state *dss = dss_void;
     STATE_AO_GC(dss->ao);
 
     /* Convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7cf1b04..1a7b526 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -54,6 +54,7 @@
 
 #include "libxl.h"
 #include "_paths.h"
+#include "_libxl_save_msgs_callout.h"
 
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
@@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
 _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
 
 
+/*----- Save/restore helper (used by creation and suspend) -----*/
+
+typedef struct libxl__srm_save_callbacks {
+    libxl__srm_save_autogen_callbacks a;
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
+                          uint32_t *len, void *data);
+} libxl__srm_save_callbacks;
+
+typedef struct libxl__srm_restore_callbacks {
+    libxl__srm_restore_autogen_callbacks a;
+} libxl__srm_restore_callbacks;
+
+/* a pointer to this struct is also passed as "user" to the
+ * save callout helper callback functions */
+typedef struct libxl__save_helper_state {
+    /* public, caller of run_helper initialises */
+    libxl__ao *ao;
+    uint32_t domid;
+    union {
+        libxl__srm_save_callbacks save;
+        libxl__srm_restore_callbacks restore;
+    } callbacks;
+    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
+    void (*completion_callback)(libxl__egc *egc, void *caller_state,
+                                int rc, int retval, int errnoval);
+    void *caller_state;
+    int need_results; /* set to 0 or 1 by caller of run_helper;
+                       * if set to 1 then the ultimate caller's
+                       * results function must set it to 0 */
+    /* private */
+    int rc;
+    int completed; /* retval/errnoval valid iff completed */
+    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
+    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
+    libxl__ev_fd readable;
+    libxl__ev_child child;
+    const char *stdin_what, *stdout_what;
+    FILE *toolstack_data_file;
+
+    libxl__egc *egc; /* valid only for duration of each event callback;
+                      * is here in this struct for the benefit of the
+                      * marshalling and xc callback functions */
+} libxl__save_helper_state;
+
+
 /*----- Domain suspend (save) state structure -----*/
 
 typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
@@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
     int xcflags;
     int guest_responded;
     int interval; /* checkpoint interval (for Remus) */
-    struct save_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 
@@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
     libxl__stub_dm_spawn_state dmss;
         /* If we're not doing stubdom, we use only dmss.dm,
          * for the non-stubdom device model. */
-    struct restore_callbacks callbacks;
+    libxl__save_helper_state shs;
 };
 
 /*----- Domain suspend (save) functions -----*/
@@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_save_done(libxl__egc*,
-                                        libxl__domain_suspend_state*,
+_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
                                         int rc, int retval, int errnoval);
 
 _hidden int libxl__domain_suspend_common_callback(void *data);
@@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
 /* If rc==0 then retval is the return value from xc_domain_save
  * and errnoval is the errno value it provided.
  * If rc!=0, retval and errnoval are undefined. */
-_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
-                                           libxl__domain_create_state *dcs,
+_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
 
 
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 1b481ab..a6abcda 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -16,6 +16,30 @@
 
 #include "libxl_internal.h"
 
+/* stream_fd is as from the caller (eventually, the application).
+ * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
+ * The actual fd value is not included in the supplied argnums; rather
+ * it will be automatically supplied by run_helper as the 2nd argument.
+ *
+ * preserve_fds are fds that the caller is intending to pass to the
+ * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
+ * An entry may be -1 in which case it will be ignored.
+ */
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg,
+                       int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums);
+
+static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status);
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
+
+/*----- entrypoints -----*/
+
 void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
                               int hvm, int pae, int superpages,
                               int no_incr_generationid)
@@ -27,22 +51,337 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
     const int restore_fd = dcs->restore_fd;
     libxl__domain_build_state *const state = &dcs->build_state;
 
-    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
-                              state->store_port, &state->store_mfn,
-                              state->store_domid, state->console_port,
-                              &state->console_mfn, state->console_domid,
-                              hvm, pae, superpages, no_incr_generationid,
-                              &state->vm_generationid_addr, &dcs->callbacks);
-    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
+        (&dcs->shs.callbacks.restore.a);
+
+    const unsigned long argnums[] = {
+        domid,
+        state->store_port,
+        state->store_domid, state->console_port,
+        state->console_domid,
+        hvm, pae, superpages, no_incr_generationid,
+        cbflags,
+    };
+
+    dcs->shs.ao = ao;
+    dcs->shs.domid = domid;
+    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
+    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
+    dcs->shs.caller_state = dcs;
+    dcs->shs.need_results = 1;
+    dcs->shs.toolstack_data_file = 0;
+
+    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
+               argnums, ARRAY_SIZE(argnums));
 }
 
 void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
                            unsigned long vm_generationid_addr)
 {
     STATE_AO_GC(dss->ao);
-    int r;
+    int r, rc, toolstack_data_fd = -1;
+    uint32_t toolstack_data_len = 0;
+
+    /* Resources we need to free */
+    uint8_t *toolstack_data_buf = 0;
+
+    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
+        (&dss->shs.callbacks.save.a);
+
+    if (dss->shs.callbacks.save.toolstack_save) {
+        r = dss->shs.callbacks.save.toolstack_save
+            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
+        if (r) { rc = ERROR_FAIL; goto out; }
+
+        dss->shs.toolstack_data_file = tmpfile();
+        if (!dss->shs.toolstack_data_file) {
+            LOGE(ERROR, "cannot create toolstack data tmpfile");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
+
+        r = libxl_write_exactly(CTX, toolstack_data_fd,
+                                toolstack_data_buf, toolstack_data_len,
+                                "toolstack data tmpfile", 0);
+        if (r) { rc = ERROR_FAIL; goto out; }
+    }
+
+    const unsigned long argnums[] = {
+        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
+        toolstack_data_fd, toolstack_data_len,
+        cbflags,
+    };
+
+    dss->shs.ao = ao;
+    dss->shs.domid = dss->domid;
+    dss->shs.recv_callback = libxl__srm_callout_received_save;
+    dss->shs.completion_callback = libxl__xc_domain_save_done;
+    dss->shs.caller_state = dss;
+    dss->shs.need_results = 0;
+
+    free(toolstack_data_buf);
+
+    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
+               &toolstack_data_fd, 1,
+               argnums, ARRAY_SIZE(argnums));
+    return;
+
+ out:
+    free(toolstack_data_buf);
+    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
+
+    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
+}
+
+
+/*----- helper execution -----*/
+
+static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
+                       const char *mode_arg, int stream_fd,
+                       const int *preserve_fds, int num_preserve_fds,
+                       const unsigned long *argnums, int num_argnums)
+{
+    STATE_AO_GC(shs->ao);
+    const char *args[4 + num_argnums];
+    const char **arg = args;
+    int i, rc;
+
+    /* Resources we must free */
+    libxl__carefd *childs_pipes[2] = { 0,0 };
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    shs->rc = 0;
+    shs->completed = 0;
+    shs->pipes[0] = shs->pipes[1] = 0;
+    libxl__ev_fd_init(&shs->readable);
+    libxl__ev_child_init(&shs->child);
+
+    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                " stdin pipe", domid);
+    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
+                                 " stdout pipe", domid);
+
+    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
+    *arg++ = mode_arg;
+    const char **stream_fd_arg = arg++;
+    for (i=0; i<num_argnums; i++)
+        *arg++ = GCSPRINTF("%lu", argnums[i]);
+    *arg++ = 0;
+    assert(arg == args + ARRAY_SIZE(args));
+
+    libxl__carefd_begin();
+    int childfd;
+    for (childfd=0; childfd<2; childfd++) {
+        /* Setting up the pipe for the child's fd childfd */
+        int fds[2];
+        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
+        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
+        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
+        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
+        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
+    }
+    libxl__carefd_unlock();
+
+    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
+    if (!pid) {
+        if (stream_fd <= 2) {
+            stream_fd = dup(stream_fd);
+            if (stream_fd < 0) {
+                LOGE(ERROR,"dup migration stream fd");
+                exit(-1);
+            }
+        }
+        libxl_fd_set_cloexec(CTX, stream_fd, 0);
+        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
+
+        for (i=0; i<num_preserve_fds; i++)
+            if (preserve_fds[i] >= 0) {
+                assert(preserve_fds[i] > 2);
+                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
+            }
+
+        libxl__exec(gc,
+                    libxl__carefd_fd(childs_pipes[0]),
+                    libxl__carefd_fd(childs_pipes[1]),
+                    -1,
+                    args[0], (char**)args, 0);
+    }
+
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+
+    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
+                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
+    if (rc) goto out;
+    return;
+
+ out:
+    libxl__carefd_close(childs_pipes[0]);
+    libxl__carefd_close(childs_pipes[1]);
+    helper_failed(egc, shs, rc);;
+}
+
+static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
+                          int rc)
+{
+    STATE_AO_GC(shs->ao);
+
+    if (!shs->rc)
+        shs->rc = rc;
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+
+    if (!libxl__ev_child_inuse(&shs->child)) {
+        helper_done(egc, shs);
+        return;
+    }
+
+    int r = kill(shs->child.pid, SIGKILL);
+    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
+                (unsigned long)shs->child.pid);
+}
+
+static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
+    STATE_AO_GC(shs->ao);
+    int rc, errnoval;
+
+    if (revents & (POLLERR|POLLPRI)) {
+        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
+            shs->stdout_what, revents);
+        rc = ERROR_FAIL;
+ out:
+        /* this is here because otherwise we bypass the decl of msg[] */
+        helper_failed(egc, shs, rc);
+        return;
+    }
+
+    uint16_t msglen;
+    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
+                                  shs->stdout_what, "ipc msg header");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    unsigned char msg[msglen];
+    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
+                                  shs->stdout_what, "ipc msg body");
+    if (errnoval) { rc = ERROR_FAIL; goto out; }
+
+    shs->egc = egc;
+    shs->recv_callback(msg, msglen, shs);
+    shs->egc = 0;
+    return;
+}
+
+static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
+                          pid_t pid, int status)
+{
+    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
+    STATE_AO_GC(shs->ao);
+
+    /* Convenience aliases */
+    const uint32_t domid = shs->domid;
+
+    const char *what =
+        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
+
+    if (status) {
+        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (shs->need_results) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without providing results",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    if (!shs->completed) {
+        if (!shs->rc)
+            LOG(ERROR,"%s exited without signaling completion",what);
+        shs->rc = ERROR_FAIL;
+    }
+
+    helper_done(egc, shs);
+    return;
+}
+
+static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
+{
+    STATE_AO_GC(shs->ao);
+
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
+    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
+    assert(!libxl__ev_child_inuse(&shs->child));
+    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
+
+    shs->egc = egc;
+    shs->completion_callback(egc, shs->caller_state,
+                             shs->rc, shs->retval, shs->errnoval);
+    shs->egc = 0;
+}
+
+/*----- generic helpers for the autogenerated code -----*/
+
+const libxl__srm_save_autogen_callbacks*
+libxl__srm_callout_get_callbacks_save(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.save.a;
+}
+
+const libxl__srm_restore_autogen_callbacks*
+libxl__srm_callout_get_callbacks_restore(void *user)
+{
+    libxl__save_helper_state *shs = user;
+    return &shs->callbacks.restore.a;
+}
+
+void libxl__srm_callout_sendreply(int r, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    STATE_AO_GC(shs->ao);
+    int errnoval;
+
+    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
+                                   &r, sizeof(r), shs->stdin_what,
+                                   "callback return value");
+    if (errnoval)
+        helper_failed(egc, shs, ERROR_FAIL);
+}
+
+void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
+                  const char *context, const char *formatted, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
+}
+
+void libxl__srm_callout_callback_progress(const char *context,
+                   const char *doing_what, unsigned long done,
+                   unsigned long total, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
+    xtl_progress(CTX->lg, context, doing_what, done, total);
+}
+
+int libxl__srm_callout_callback_complete(int retval, int errnoval,
+                                         void *user)
+{
+    libxl__save_helper_state *shs = user;
+    STATE_AO_GC(shs->ao);
 
-    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
-                       &dss->callbacks, dss->hvm, vm_generationid_addr);
-    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
+    shs->completed = 1;
+    shs->retval = retval;
+    shs->errnoval = errnoval;
+    libxl__ev_fd_deregister(gc, &shs->readable);
+    return 0;
 }
diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
new file mode 100644
index 0000000..772251a
--- /dev/null
+++ b/tools/libxl/libxl_save_helper.c
@@ -0,0 +1,283 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * The libxl-save-helper utility speaks a protocol to its caller for
+ * the callbacks.  The protocol is as follows.
+ *
+ * The helper talks on stdin and stdout, in binary in machine
+ * endianness.  The helper speaks first, and only when it has a
+ * callback to make.  It writes a 16-bit number being the message
+ * length, and then the message body.
+ *
+ * Each message starts with a 16-bit number indicating which of the
+ * messages it is, and then some arguments in a binary marshalled form.
+ * If the callback does not need a reply (it returns void), the helper
+ * just continues.  Otherwise the helper waits for its caller to send a
+ * single int which is to be the return value from the callback.
+ *
+ * Where feasible the stubs and callbacks have prototypes identical to
+ * those required by xc_domain_save and xc_domain_restore, so that the
+ * autogenerated functions can be used/provided directly.
+ *
+ * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <assert.h>
+#include <inttypes.h>
+
+#include "libxl.h"
+
+#include "xenctrl.h"
+#include "xenguest.h"
+#include "_libxl_save_msgs_helper.h"
+
+/*----- globals -----*/
+
+static const char *program = "libxl-save-helper";
+static xentoollog_logger *logger;
+static xc_interface *xch;
+
+/*----- error handling -----*/
+
+static void fail(int errnoval, const char *fmt, ...)
+    __attribute__((noreturn,format(printf,2,3)));
+static void fail(int errnoval, const char *fmt, ...)
+{
+    va_list al;
+    va_start(al,fmt);
+    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
+    exit(-1);
+}
+
+static int read_exactly(int fd, void *buf, size_t len)
+/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
+{
+    while (len) {
+        ssize_t r = read(fd, buf, len);
+        if (r<=0) return r;
+        assert(r <= len);
+        len -= r;
+        buf = (char*)buf + r;
+    }
+    return 1;
+}
+
+static void *xmalloc(size_t sz)
+{
+    if (!sz) return 0;
+    void *r = malloc(sz);
+    if (!r) { perror("memory allocation failed"); exit(-1); }
+    return r;
+}
+
+/*----- logger -----*/
+
+typedef struct {
+    xentoollog_logger vtable;
+} xentoollog_logger_tellparent;
+
+static void tellparent_vmessage(xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                int errnoval,
+                                const char *context,
+                                const char *format,
+                                va_list al)
+{
+    char *formatted;
+    int r = vasprintf(&formatted, format, al);
+    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
+    helper_stub_log(level, errnoval, context, formatted, 0);
+    free(formatted);
+}
+
+static void tellparent_progress(struct xentoollog_logger *logger_in,
+                                const char *context,
+                                const char *doing_what, int percent,
+                                unsigned long done, unsigned long total)
+{
+    helper_stub_progress(context, doing_what, done, total, 0);
+}
+
+static void tellparent_destroy(struct xentoollog_logger *logger_in)
+{
+    abort();
+}
+
+static xentoollog_logger_tellparent *createlogger_tellparent(void)
+{
+    xentoollog_logger_tellparent newlogger;
+    return XTL_NEW_LOGGER(tellparent, newlogger);
+}
+
+/*----- helper functions called by autogenerated stubs -----*/
+
+unsigned char * helper_allocbuf(int len, void *user)
+{
+    return xmalloc(len);
+}
+
+static void transmit(const unsigned char *msg, int len, void *user)
+{
+    while (len) {
+        int r = write(1, msg, len);
+        if (r<0) { perror("write"); exit(-1); }
+        assert(r >= 0);
+        assert(r <= len);
+        len -= r;
+        msg += r;
+    }
+}
+
+void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
+{
+    assert(len_in < 64*1024);
+    uint16_t len = len_in;
+    transmit((const void*)&len, sizeof(len), user);
+    transmit(msg_freed, len, user);
+    free(msg_freed);
+}
+
+int helper_getreply(void *user)
+{
+    int v;
+    int r = read_exactly(0, &v, sizeof(v));
+    if (r<=0) exit(-2);
+    return v;
+}
+
+/*----- other callbacks -----*/
+
+static int toolstack_save_fd;
+static uint32_t toolstack_save_len;
+
+static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
+                             uint32_t *len, void *data)
+{
+    assert(toolstack_save_fd > 0);
+
+    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
+    if (r) fail(errno,"rewind toolstack data tmpfile");
+
+    *buf = xmalloc(toolstack_save_len);
+    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
+    if (r<0) fail(errno,"read toolstack data");
+    if (r==0) fail(0,"read toolstack data eof");
+
+    *len = toolstack_save_len;
+    return 0;
+}
+
+static void startup(const char *op) {
+    logger = (xentoollog_logger*)createlogger_tellparent();
+    if (!logger) {
+        fprintf(stderr, "%s: cannot initialise logger\n", program);
+        exit(-1);
+    }
+
+    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
+
+    xch = xc_interface_open(logger,logger,0);
+    if (!xch) fail(errno,"xc_interface_open failed");
+}
+
+static void complete(int retval) {
+    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
+    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
+    helper_stub_complete(retval,errnoval,0);
+    exit(0);
+}
+
+static struct save_callbacks helper_save_callbacks;
+static struct restore_callbacks helper_restore_callbacks;
+
+int main(int argc, char **argv)
+{
+    int r;
+
+#define NEXTARG (++argv, assert(*argv), *argv)
+
+    const char *mode = *++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);
+        assert(!*++argv);
+
+        if (toolstack_save_fd >= 0)
+            helper_save_callbacks.toolstack_save = toolstack_save_cb;
+
+        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);
+        complete(r);
+
+    } else if (!strcmp(mode,"--restore-domain")) {
+
+        int io_fd =                atoi(NEXTARG);
+        uint32_t dom =             strtoul(NEXTARG,0,10);
+        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
+        domid_t store_domid =      strtoul(NEXTARG,0,10);
+        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
+        domid_t console_domid =    strtoul(NEXTARG,0,10);
+        unsigned int hvm =         strtoul(NEXTARG,0,10);
+        unsigned int pae =         strtoul(NEXTARG,0,10);
+        int superpages =           strtoul(NEXTARG,0,10);
+        int no_incr_genidad =      strtoul(NEXTARG,0,10);
+        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        assert(!*++argv);
+
+        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
+
+        unsigned long store_mfn = 0;
+        unsigned long console_mfn = 0;
+        unsigned long genidad = 0;
+
+        startup("restore");
+        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
+                              store_domid, console_evtchn, &console_mfn,
+                              console_domid, hvm, pae, superpages,
+                              no_incr_genidad, &genidad,
+                              &helper_restore_callbacks);
+        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
+        complete(r);
+
+    } else {
+        assert(!"unexpected mode argument");
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
new file mode 100755
index 0000000..c45986e
--- /dev/null
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -0,0 +1,397 @@
+#!/usr/bin/perl -w
+
+use warnings;
+use strict;
+use POSIX;
+
+our $debug = 0; # produce copious debugging output at run-time?
+
+our @msgs = (
+    # flags:
+    #   s  - applicable to save
+    #   r  - applicable to restore
+    #   c  - function pointer in callbacks struct rather than fixed function
+    #   x  - function pointer is in struct {save,restore}_callbacks
+    #         and its null-ness needs to be passed through to the helper's xc
+    #   W  - needs a return value; callback is synchronous
+    [  1, 'sr',     "log",                   [qw(uint32_t level
+                                                 uint32_t errnoval
+                                                 STRING context
+                                                 STRING formatted)] ],
+    [  2, 'sr',     "progress",              [qw(STRING context
+                                                 STRING doing_what),
+                                                'unsigned long', 'done',
+                                                'unsigned long', 'total'] ],
+    [  3, 'scxW',   "suspend", [] ],         
+    [  4, 'scxW',   "postcopy", [] ],        
+    [  5, 'scxW',   "checkpoint", [] ],      
+    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
+                                              unsigned enable)] ],
+    #                toolstack_save          done entirely `by hand'
+    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
+                                                BLOCK tsdata)] ],
+    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
+                                              'unsigned long', 'console_mfn',
+                                              'unsigned long', 'genidad'] ],
+    [  9, 'srW',    "complete",              [qw(int retval
+                                                 int errnoval)] ],
+);
+
+#----------------------------------------
+
+our %cbs;
+our %func;
+our %func_ah;
+our @outfuncs;
+our %out_decls;
+our %out_body;
+our %msgnum_used;
+
+die unless @ARGV==1;
+die if $ARGV[0] =~ m/^-/;
+
+our ($intendedout) = @ARGV;
+
+$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
+my ($want_ah, $ch) = ($1, $2);
+
+my $declprefix = '';
+
+foreach my $ah (qw(callout helper)) {
+    $out_body{$ah} .=
+        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
+#include "libxl_osdeps.h"
+
+#include <assert.h>
+#include <string.h>
+#include <stdint.h>
+#include <limits.h>
+END_BOTH
+
+#include "libxl_internal.h"
+
+END_CALLOUT
+
+#include "_libxl_save_msgs_${ah}.h"
+#include <xenctrl.h>
+#include <xenguest.h>
+
+END_HELPER
+}
+
+die $want_ah unless defined $out_body{$want_ah};
+
+sub f_decl ($$$$) {
+    my ($name, $ah, $c_rtype, $c_decl) = @_;
+    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
+    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
+    $func_ah{$name} = $ah;
+}
+
+sub f_more ($$) {
+    my ($name, $addbody) = @_;
+    $func{$name} ||= '';
+    $func{$name} .= $addbody;
+    push @outfuncs, $name;
+}
+
+our $libxl = "libxl__srm";
+our $callback = "${libxl}_callout_callback";
+our $receiveds = "${libxl}_callout_received";
+our $sendreply = "${libxl}_callout_sendreply";
+our $getcallbacks = "${libxl}_callout_get_callbacks";
+our $enumcallbacks = "${libxl}_callout_enumcallbacks";
+sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
+
+f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
+
+our $helper = "helper";
+our $encode = "${helper}_stub";
+our $allocbuf = "${helper}_allocbuf";
+our $transmit = "${helper}_transmitmsg";
+our $getreply = "${helper}_getreply";
+our $setcallbacks = "${helper}_setcallbacks";
+
+f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
+f_decl($transmit, 'helper', 'void',
+       '(unsigned char *msg_freed, int len, void *user)');
+f_decl($getreply, 'helper', 'int', '(void *user)');
+
+sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
+
+$out_body{'callout'} .= <<END;
+static int bytes_get(const unsigned char **msg,
+		     const unsigned char *const endmsg,
+		     void *result, int rlen)
+{
+    if (endmsg - *msg < rlen) return 0;
+    memcpy(result,*msg,rlen);
+    *msg += rlen;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void bytes_put(unsigned char *const buf, int *len,
+		      const void *value, int vlen)
+{
+    assert(vlen < INT_MAX/2 - *len);
+    if (buf)
+	memcpy(buf + *len, value, vlen);
+    *len += vlen;
+}
+
+END
+
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+    my $typeid = typeid($simpletype);
+    $out_body{'callout'} .= <<END;
+static int ${typeid}_get(const unsigned char **msg,
+                        const unsigned char *const endmsg,
+                        $simpletype *result)
+{
+    return bytes_get(msg, endmsg, result, sizeof(*result));
+}
+
+END
+    $out_body{'helper'} .= <<END;
+static void ${typeid}_put(unsigned char *const buf, int *len,
+			 const $simpletype value)
+{
+    bytes_put(buf, len, &value, sizeof(value));
+}
+
+END
+}
+
+$out_body{'callout'} .= <<END;
+static int BLOCK_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const uint8_t **result, uint32_t *result_size)
+{
+    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
+    if (endmsg - *msg < *result_size) return 0;
+    *result = (const void*)*msg;
+    *msg += *result_size;
+    return 1;
+}
+
+static int STRING_get(const unsigned char **msg,
+                      const unsigned char *const endmsg,
+                      const char **result)
+{
+    const uint8_t *data;
+    uint32_t datalen;
+    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
+    if (datalen == 0) return 0;
+    if (data[datalen-1] != '\\0') return 0;
+    *result = (const void*)data;
+    return 1;
+}
+
+END
+$out_body{'helper'} .= <<END;
+static void BLOCK_put(unsigned char *const buf,
+                      int *len,
+		      const uint8_t *bytes, uint32_t size)
+{
+    uint32_t_put(buf, len, size);
+    bytes_put(buf, len, bytes, size);
+}
+    
+static void STRING_put(unsigned char *const buf,
+		       int *len,
+		       const char *string)
+{
+    size_t slen = strlen(string);
+    assert(slen < INT_MAX / 4);
+    assert(slen < (uint32_t)0x40000000);
+    BLOCK_put(buf, len, (const void*)string, slen+1);
+}
+    
+END
+
+foreach my $sr (qw(save restore)) {
+    f_decl("${getcallbacks}_${sr}", 'callout',
+           "const ".cbtype($sr)." *",
+           "(void *data)");
+
+    f_decl("${receiveds}_${sr}", 'callout', 'int',
+	   "(const unsigned char *msg, uint32_t len, void *user)");
+
+    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
+           "(const ".cbtype($sr)." *cbs)");
+    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
+
+    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
+           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
+
+    f_more("${receiveds}_${sr}",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    const unsigned char *const endmsg = msg + len;
+    uint16_t mtype;
+    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
+END_ALWAYS
+    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
+END_DEBUG
+    switch (mtype) {
+
+END_ALWAYS
+
+    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
+}
+
+foreach my $msginfo (@msgs) {
+    my ($msgnum, $flags, $name, $args) = @$msginfo;
+    die if $msgnum_used{$msgnum}++;
+
+    my $f_more_sr = sub {
+        my ($contents_spec, $fnamebase) = @_;
+        $fnamebase ||= "${receiveds}";
+        foreach my $sr (qw(save restore)) {
+            $sr =~ m/^./;
+            next unless $flags =~ m/$&/;
+            my $contents = (!ref $contents_spec) ? $contents_spec :
+                $contents_spec->($sr);
+            f_more("${fnamebase}_${sr}", $contents);
+        }
+    };
+
+    $f_more_sr->("    case $msgnum: { /* $name */\n");
+    if ($flags =~ m/W/) {
+        $f_more_sr->("        int r;\n");
+    }
+
+    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
+    my $c_decl = '(';
+    my $c_callback_args = '';
+
+    f_more("${encode}_$name",
+           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
+    unsigned char *buf = 0;
+    int len = 0, allocd = 0;
+
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
+END_DEBUG
+    for (;;) {
+        uint16_t_put(buf, &len, $msgnum /* $name */);
+END_ALWAYS
+
+    my @args = @$args;
+    my $c_recv = '';
+    my ($argtype, $arg);
+    while (($argtype, $arg, @args) = @args) {
+	my $typeid = typeid($argtype);
+        my $c_args = "$arg";
+        my $c_get_args = "&$arg";
+	if ($argtype eq 'STRING') {
+	    $c_decl .= "const char *$arg, ";
+	    $f_more_sr->("        const char *$arg;\n");
+        } elsif ($argtype eq 'BLOCK') {
+            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
+            $c_args .= ", ${arg}_size";
+            $c_get_args .= ",&${arg}_size";
+	    $f_more_sr->("        const uint8_t *$arg;\n".
+                         "        uint32_t ${arg}_size;\n");
+	} else {
+	    $c_decl .= "$argtype $arg, ";
+	    $f_more_sr->("        $argtype $arg;\n");
+	}
+	$c_callback_args .= "$c_args, ";
+	$c_recv.=
+            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
+        f_more("${encode}_$name", "	${typeid}_put(buf, &len, $c_args);\n");
+    }
+    $f_more_sr->($c_recv);
+    $c_decl .= "void *user)";
+    $c_callback_args .= "user";
+
+    $f_more_sr->("        if (msg != endmsg) return 0;\n");
+
+    my $c_callback;
+    if ($flags !~ m/c/) {
+        $c_callback = "${callback}_$name";
+    } else {
+        $f_more_sr->(sub {
+            my ($sr) = @_;
+            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
+            return
+          "        const ".cbtype($sr)." *const cbs =\n".
+            "            ${getcallbacks}_${sr}(user);\n";
+                       });
+        $c_callback = "cbs->${name}";
+    }
+    my $c_make_callback = "$c_callback($c_callback_args)";
+    if ($flags !~ m/W/) {
+	$f_more_sr->("        $c_make_callback;\n");
+    } else {
+        $f_more_sr->("        r = $c_make_callback;\n".
+                     "        $sendreply(r, user);\n");
+	f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
+    }
+    if ($flags =~ m/x/) {
+        my $c_v = "(1u<<$msgnum)";
+        my $c_cb = "cbs->$name";
+        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
+        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
+                     $setcallbacks);
+    }
+    $f_more_sr->("        return 1;\n    }\n\n");
+    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
+    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
+    f_more("${encode}_$name",
+"        if (buf) break;
+        buf = ${helper}_allocbuf(len, user);
+        assert(buf);
+        allocd = len;
+        len = 0;
+    }
+    assert(len == allocd);
+    ${transmit}(buf, len, user);
+");
+    if ($flags =~ m/W/) {
+	f_more("${encode}_$name",
+               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
+    int r = ${helper}_getreply(user);
+END_ALWAYS
+    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
+END_DEBUG
+    return r;
+END_ALWAYS
+    }
+}
+
+print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
+
+foreach my $sr (qw(save restore)) {
+    f_more("${enumcallbacks}_${sr}",
+           "    return cbflags;\n");
+    f_more("${receiveds}_${sr}",
+           "    default:\n".
+           "        return 0;\n".
+           "    }");
+    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
+    if ($ch eq 'h') {
+        print $cbs{$sr} or die $!;
+        print "struct ${sr}_callbacks;\n";
+    }
+}
+
+if ($ch eq 'c') {
+    foreach my $name (@outfuncs) {
+        next unless defined $func{$name};
+        $func{$name} .= "}\n\n";
+        $out_body{$func_ah{$name}} .= $func{$name};
+        delete $func{$name};
+    }
+    print $out_body{$want_ah} or die $!;
+} else {
+    foreach my $name (sort keys %out_decls) {
+        next unless $func_ah{$name} eq $want_ah;
+        print $out_decls{$name} or die $!;
+    }
+}
+
+close STDOUT or die $!;
-- 
tg: (52b6131..) t/xen/xc.save-restore-protocol (depends on: t/xen/xl.ao.suspend.pre)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:38:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEvn-0003fY-Ld; Thu, 28 Jun 2012 13:38:47 +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 1SkEvm-0003fJ-NW
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:38:46 +0000
Received: from [85.158.138.51:14521] by server-4.bemta-3.messagelabs.com id
	51/8F-17105-56E5CEF4; Thu, 28 Jun 2012 13:38:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340890724!29916320!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzU5MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10509 invoked from network); 28 Jun 2012 13:38:45 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 13:38:45 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 06:38:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171110192"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 28 Jun 2012 06:38:39 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 06:38:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 21:38:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVRQt1l9vq4iTRyWE8p2SJy8j95cPtZ2g
Date: Thu, 28 Jun 2012 13:38:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
In-Reply-To: <4FEC463E020000780008C6A7@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> So I would like to push new vMCE as quickly as possible. What's the
>> timeline of vMCE developing that xen 4.2 could accept?
> 
> Weeks ago, really. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
> and follow-ups - we'd really only consider getting the save/restore 
> interface into forward compatible shape as acceptable.
> 
>> I wonder if we could make major
>> components of vMCE done before xen 4.2 timeline, and leave the
>> surrounding features and the corner cases done later?
> 
> Unfortunately it's likely going to be even less. However, if split
> that way, chances are things could go into e.g. 4.2.1.
> 
> Jan

So let's look at current vMCE status first:
1). functionally it work abnormally for guest (but tolerated by some guest like linux/solaris);
2). before xen 4.1 it blocks migration when migrate from big bank to small bank platform;

We may try some middle steps, minimal adjusting for xen 4.2 release (to avoid futher compatible issue at xen 4.2.1, 4.3, ...):
1). we don't handle vMCE function bugs, only make sure migration works OK;
2). update vMCE interface to a middle clean status:
    * remove MCG_CTL (otherwise we have to add this useless MSR at new vMCE);
    * stick all 1's to MCi_CTL (avoid semantic difference);
    * for MCG_CAP, clear MCG_CTL_P, limit to 2 banks (otherwise dirty code have to be added at new vMCE);

Thoughts?

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 Jun 28 13:38:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEvn-0003fY-Ld; Thu, 28 Jun 2012 13:38:47 +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 1SkEvm-0003fJ-NW
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:38:46 +0000
Received: from [85.158.138.51:14521] by server-4.bemta-3.messagelabs.com id
	51/8F-17105-56E5CEF4; Thu, 28 Jun 2012 13:38:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340890724!29916320!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzU5MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10509 invoked from network); 28 Jun 2012 13:38:45 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 13:38:45 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 06:38:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171110192"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 28 Jun 2012 06:38:39 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 06:38:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Thu, 28 Jun 2012 21:38:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVRQt1l9vq4iTRyWE8p2SJy8j95cPtZ2g
Date: Thu, 28 Jun 2012 13:38:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
In-Reply-To: <4FEC463E020000780008C6A7@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> So I would like to push new vMCE as quickly as possible. What's the
>> timeline of vMCE developing that xen 4.2 could accept?
> 
> Weeks ago, really. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
> and follow-ups - we'd really only consider getting the save/restore 
> interface into forward compatible shape as acceptable.
> 
>> I wonder if we could make major
>> components of vMCE done before xen 4.2 timeline, and leave the
>> surrounding features and the corner cases done later?
> 
> Unfortunately it's likely going to be even less. However, if split
> that way, chances are things could go into e.g. 4.2.1.
> 
> Jan

So let's look at current vMCE status first:
1). functionally it work abnormally for guest (but tolerated by some guest like linux/solaris);
2). before xen 4.1 it blocks migration when migrate from big bank to small bank platform;

We may try some middle steps, minimal adjusting for xen 4.2 release (to avoid futher compatible issue at xen 4.2.1, 4.3, ...):
1). we don't handle vMCE function bugs, only make sure migration works OK;
2). update vMCE interface to a middle clean status:
    * remove MCG_CTL (otherwise we have to add this useless MSR at new vMCE);
    * stick all 1's to MCi_CTL (avoid semantic difference);
    * for MCG_CAP, clear MCG_CTL_P, limit to 2 banks (otherwise dirty code have to be added at new vMCE);

Thoughts?

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 Jun 28 13:42:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEz4-0003zm-AX; Thu, 28 Jun 2012 13:42: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 1SkEz2-0003zL-V2
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:42:09 +0000
Received: from [85.158.138.51:28106] by server-6.bemta-3.messagelabs.com id
	28/F7-11602-03F5CEF4; Thu, 28 Jun 2012 13:42:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340890927!20869886!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16482 invoked from network); 28 Jun 2012 13:42:07 -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; 28 Jun 2012 13:42:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkEyy-000CWB-Ht; Thu, 28 Jun 2012 13:42:04 +0000
Date: Thu, 28 Jun 2012 14:42:04 +0100
From: Tim Deegan <tim@xen.org>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20120628134204.GP34995@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-4-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340157467-19553-4-git-send-email-xudong.hao@intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, haitao.shan@intel.com, JBeulich@suse.com,
	xiantao.zhang@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
	update_dirty_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

At 09:57 +0800 on 20 Jun (1340186266), Xudong Hao wrote:
> @@ -83,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain *d)
>  static int hap_disable_vram_tracking(struct domain *d)
>  {
>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
> +    p2m_type_t p2mt = p2m_ram_rw;
>  
>      if ( !dirty_vram )
>          return -EINVAL;
>  
> +    /* With hap dirty bit, p2m type cannot be changed from p2m_ram_logdirty
> +     * to p2m_ram_rw when first fault is met. Actually, there is no such
> +     * fault occurred.
> +     */
> +    if ( hap_has_dirty_bit )
> +        p2mt = p2m_ram_logdirty;
> +
>      paging_lock(d);
>      d->arch.paging.mode &= ~PG_log_dirty;
>      paging_unlock(d);
>  
>      /* set l1e entries of P2M table with normal mode */
>      p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
> -                          p2m_ram_logdirty, p2m_ram_rw);
> +                          p2mt, p2m_ram_rw);

What's the intent of this change?  

AFAICS it will break the hap_has_dirty_bit==0 case, by basically making
that p2m_change_type_range() into a noop.

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain *d,
>      p2m_unlock(p2m);
>  }
>  
> +void p2m_query_entry_global(struct domain *d, int mask)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    ASSERT(p2m);
> +    p2m_lock(p2m);
> +    p2m->query_entry_global(p2m, mask);
> +    p2m_unlock(p2m);
> +}
> +

Given that when you implement this, it's basically just the same as
p2m_change_type_global() with p2m_ram_logdirty for both types:

 - Why not just use p2m_change_type_global() instead of adding the new
   function pointer?
 - If you do need a new function pointer, this name is very confusing:
   it's not doing any kind of query.

> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
>      int i4, i3, i2;
>  
>      domain_pause(d);
> -    paging_lock(d);
>  
>      clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
> +    if ( clean )
> +    {
> +        /* We need to further call clean_dirty_bitmap() functions of specific
> +         * paging modes (shadow or hap).  Safe because the domain is paused.
> +         * And this call must be made before actually transferring the dirty
> +         * bitmap since with HW hap dirty bit support, dirty bitmap is
> +         * produced by hooking on this call. */
> +        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
> +    }

> +    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
> +    {
> +        d->arch.paging.log_dirty.update_dirty_bitmap(d);
> +    }

Doesn't this end up doing _two_ passes over the p2m table?

I think it would be better to leave the clean() op at the end of the
function, and arrange for it to be a noop in the EPT/D-bit case.  Then
with the addition of this update_dirty_bitmap() call, the p2m only gets
walked once, for all configurations.

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 Jun 28 13:42:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkEz4-0003zm-AX; Thu, 28 Jun 2012 13:42: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 1SkEz2-0003zL-V2
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:42:09 +0000
Received: from [85.158.138.51:28106] by server-6.bemta-3.messagelabs.com id
	28/F7-11602-03F5CEF4; Thu, 28 Jun 2012 13:42:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340890927!20869886!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16482 invoked from network); 28 Jun 2012 13:42:07 -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; 28 Jun 2012 13:42:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkEyy-000CWB-Ht; Thu, 28 Jun 2012 13:42:04 +0000
Date: Thu, 28 Jun 2012 14:42:04 +0100
From: Tim Deegan <tim@xen.org>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20120628134204.GP34995@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-4-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340157467-19553-4-git-send-email-xudong.hao@intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, haitao.shan@intel.com, JBeulich@suse.com,
	xiantao.zhang@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
	update_dirty_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

At 09:57 +0800 on 20 Jun (1340186266), Xudong Hao wrote:
> @@ -83,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain *d)
>  static int hap_disable_vram_tracking(struct domain *d)
>  {
>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
> +    p2m_type_t p2mt = p2m_ram_rw;
>  
>      if ( !dirty_vram )
>          return -EINVAL;
>  
> +    /* With hap dirty bit, p2m type cannot be changed from p2m_ram_logdirty
> +     * to p2m_ram_rw when first fault is met. Actually, there is no such
> +     * fault occurred.
> +     */
> +    if ( hap_has_dirty_bit )
> +        p2mt = p2m_ram_logdirty;
> +
>      paging_lock(d);
>      d->arch.paging.mode &= ~PG_log_dirty;
>      paging_unlock(d);
>  
>      /* set l1e entries of P2M table with normal mode */
>      p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
> -                          p2m_ram_logdirty, p2m_ram_rw);
> +                          p2mt, p2m_ram_rw);

What's the intent of this change?  

AFAICS it will break the hap_has_dirty_bit==0 case, by basically making
that p2m_change_type_range() into a noop.

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain *d,
>      p2m_unlock(p2m);
>  }
>  
> +void p2m_query_entry_global(struct domain *d, int mask)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    ASSERT(p2m);
> +    p2m_lock(p2m);
> +    p2m->query_entry_global(p2m, mask);
> +    p2m_unlock(p2m);
> +}
> +

Given that when you implement this, it's basically just the same as
p2m_change_type_global() with p2m_ram_logdirty for both types:

 - Why not just use p2m_change_type_global() instead of adding the new
   function pointer?
 - If you do need a new function pointer, this name is very confusing:
   it's not doing any kind of query.

> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
>      int i4, i3, i2;
>  
>      domain_pause(d);
> -    paging_lock(d);
>  
>      clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
> +    if ( clean )
> +    {
> +        /* We need to further call clean_dirty_bitmap() functions of specific
> +         * paging modes (shadow or hap).  Safe because the domain is paused.
> +         * And this call must be made before actually transferring the dirty
> +         * bitmap since with HW hap dirty bit support, dirty bitmap is
> +         * produced by hooking on this call. */
> +        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
> +    }

> +    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
> +    {
> +        d->arch.paging.log_dirty.update_dirty_bitmap(d);
> +    }

Doesn't this end up doing _two_ passes over the p2m table?

I think it would be better to leave the clean() op at the end of the
function, and arrange for it to be a noop in the EPT/D-bit case.  Then
with the addition of this update_dirty_bitmap() call, the p2m only gets
walked once, for all configurations.

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 Jun 28 13:43:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:43: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 1SkEzl-00044M-P6; Thu, 28 Jun 2012 13:42:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkEzk-000441-6O
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:42:52 +0000
Received: from [85.158.138.51:35131] by server-6.bemta-3.messagelabs.com id
	B9/59-11602-B5F5CEF4; Thu, 28 Jun 2012 13:42:51 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340890970!11340874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19782 invoked from network); 28 Jun 2012 13:42:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:42:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:42:49 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkEzh-0008P1-5F;
	Thu, 28 Jun 2012 13:42:49 +0000
Received: by spongy (Postfix, from userid 2023)	id 0E95B340F57; Thu, 28 Jun
	2012 14:43:09 +0100 (BST)
Date: Thu, 28 Jun 2012 14:43:09 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628134308.GD15863@spongy>
References: <20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
	<1340887016.10942.42.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340887016.10942.42.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 01:36, Ian Campbell wrote:
> On Thu, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
> > On 28/06 12:58, Ian Campbell wrote:
> > > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > > > On 28/06 12:34, Ian Campbell wrote:
> > > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > > > 
> > > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > > > >> > > in the same VM?
> > > > > > > > > >> >
> > > > > > > > > >> > Yes.
> > > > > > > > > >> >
> > > > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > > > >> > > all fine.
> > > > > > > > > >> >
> > > > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > > > >
> > > > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > > > list.
> > > > > > > > > >
> > > > > > > > > 
> > > > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > > > informing up the stack that a ring has already been registered.
> > > > > > > > 
> > > > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > > > 
> > > > > > > Which takes us back to the original issue Tim asked about with
> > > > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > > > v4v clients in a single domain, doesn't it?
> > > > > > > 
> > > > > > 
> > > > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > > > The probably that Tim reported was about trying to create two connections
> > > > > > on the same port. Today with the code that I've submited in the RFC
> > > > > > one will overwrite the other silently which isn't a good thing, that can
> > > > > > easily be changed to notify which one got registered up the stack.
> > > > > 
> > > > > So they'd somehow need to randomise (and retry) their use of source
> > > > > ports in order to co-exist?
> > > > >
> > > > 
> > > > That can be assimilated to two userspace programs trying to bind to the
> > > > same TCP port. I think it's not v4v's responsability to solve this problem.
> > > 
> > > An application using TCP doesn't need to worry about choosing its own
> > > source port though.
> > > 
> > > Or does this only effect destination / listening ports?
> > > 
> > 
> > The guest v4v driver knows which port are in used so if you put port 0
> > we will pick a random unused number for the source port.
> 
> Except when there are two such drivers each doesn't know which the other
> one is using.
> 

Then the kernel will try to register the ring and the hypercall will fail
because it's already registered.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:43:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:43: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 1SkEzl-00044M-P6; Thu, 28 Jun 2012 13:42:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkEzk-000441-6O
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:42:52 +0000
Received: from [85.158.138.51:35131] by server-6.bemta-3.messagelabs.com id
	B9/59-11602-B5F5CEF4; Thu, 28 Jun 2012 13:42:51 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340890970!11340874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19782 invoked from network); 28 Jun 2012 13:42:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:42:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 14:42:49 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkEzh-0008P1-5F;
	Thu, 28 Jun 2012 13:42:49 +0000
Received: by spongy (Postfix, from userid 2023)	id 0E95B340F57; Thu, 28 Jun
	2012 14:43:09 +0100 (BST)
Date: Thu, 28 Jun 2012 14:43:09 +0100
From: Jean Guyader <jean.guyader@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628134308.GD15863@spongy>
References: <20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
	<1340887016.10942.42.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340887016.10942.42.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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 28/06 01:36, Ian Campbell wrote:
> On Thu, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
> > On 28/06 12:58, Ian Campbell wrote:
> > > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > > > On 28/06 12:34, Ian Campbell wrote:
> > > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > > > 
> > > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > > > >> > > in the same VM?
> > > > > > > > > >> >
> > > > > > > > > >> > Yes.
> > > > > > > > > >> >
> > > > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > > > >> > > all fine.
> > > > > > > > > >> >
> > > > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > > > >
> > > > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > > > list.
> > > > > > > > > >
> > > > > > > > > 
> > > > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > > > informing up the stack that a ring has already been registered.
> > > > > > > > 
> > > > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > > > 
> > > > > > > Which takes us back to the original issue Tim asked about with
> > > > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > > > v4v clients in a single domain, doesn't it?
> > > > > > > 
> > > > > > 
> > > > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > > > The probably that Tim reported was about trying to create two connections
> > > > > > on the same port. Today with the code that I've submited in the RFC
> > > > > > one will overwrite the other silently which isn't a good thing, that can
> > > > > > easily be changed to notify which one got registered up the stack.
> > > > > 
> > > > > So they'd somehow need to randomise (and retry) their use of source
> > > > > ports in order to co-exist?
> > > > >
> > > > 
> > > > That can be assimilated to two userspace programs trying to bind to the
> > > > same TCP port. I think it's not v4v's responsability to solve this problem.
> > > 
> > > An application using TCP doesn't need to worry about choosing its own
> > > source port though.
> > > 
> > > Or does this only effect destination / listening ports?
> > > 
> > 
> > The guest v4v driver knows which port are in used so if you put port 0
> > we will pick a random unused number for the source port.
> 
> Except when there are two such drivers each doesn't know which the other
> one is using.
> 

Then the kernel will try to register the ring and the hypercall will fail
because it's already registered.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkF4V-0004Nn-Iq; Thu, 28 Jun 2012 13:47:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkF4T-0004Nh-Js
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:47:45 +0000
Received: from [85.158.143.99:57677] by server-1.bemta-4.messagelabs.com id
	E8/2E-24392-0806CEF4; Thu, 28 Jun 2012 13:47:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340891264!29014929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19427 invoked from network); 28 Jun 2012 13:47:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:47:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:47:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 14:47:43 +0100
Message-ID: <1340891262.10942.51.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 14:47:42 +0100
In-Reply-To: <20120628134308.GD15863@spongy>
References: <20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
	<1340887016.10942.42.camel@zakaz.uk.xensource.com>
	<20120628134308.GD15863@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 14:43 +0100, Jean Guyader wrote:
> On 28/06 01:36, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
> > > On 28/06 12:58, Ian Campbell wrote:
> > > > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > > > > On 28/06 12:34, Ian Campbell wrote:
> > > > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > > > > 
> > > > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > > > > >> > > in the same VM?
> > > > > > > > > > >> >
> > > > > > > > > > >> > Yes.
> > > > > > > > > > >> >
> > > > > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > > > > >> > > all fine.
> > > > > > > > > > >> >
> > > > > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > > > > >
> > > > > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > > > > list.
> > > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > > > > informing up the stack that a ring has already been registered.
> > > > > > > > > 
> > > > > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > > > > 
> > > > > > > > Which takes us back to the original issue Tim asked about with
> > > > > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > > > > v4v clients in a single domain, doesn't it?
> > > > > > > > 
> > > > > > > 
> > > > > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > > > > The probably that Tim reported was about trying to create two connections
> > > > > > > on the same port. Today with the code that I've submited in the RFC
> > > > > > > one will overwrite the other silently which isn't a good thing, that can
> > > > > > > easily be changed to notify which one got registered up the stack.
> > > > > > 
> > > > > > So they'd somehow need to randomise (and retry) their use of source
> > > > > > ports in order to co-exist?
> > > > > >
> > > > > 
> > > > > That can be assimilated to two userspace programs trying to bind to the
> > > > > same TCP port. I think it's not v4v's responsability to solve this problem.
> > > > 
> > > > An application using TCP doesn't need to worry about choosing its own
> > > > source port though.
> > > > 
> > > > Or does this only effect destination / listening ports?
> > > > 
> > > 
> > > The guest v4v driver knows which port are in used so if you put port 0
> > > we will pick a random unused number for the source port.
> > 
> > Except when there are two such drivers each doesn't know which the other
> > one is using.
> > 
> 
> Then the kernel will try to register the ring and the hypercall will fail
> because it's already registered.

At which point what happens? How do two unrelated V4V drivers co-exist
given 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 Jun 28 13:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkF4V-0004Nn-Iq; Thu, 28 Jun 2012 13:47:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkF4T-0004Nh-Js
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:47:45 +0000
Received: from [85.158.143.99:57677] by server-1.bemta-4.messagelabs.com id
	E8/2E-24392-0806CEF4; Thu, 28 Jun 2012 13:47:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340891264!29014929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19427 invoked from network); 28 Jun 2012 13:47:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:47:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13270964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:47:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 14:47:43 +0100
Message-ID: <1340891262.10942.51.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jean Guyader <jean.guyader@citrix.com>
Date: Thu, 28 Jun 2012 14:47:42 +0100
In-Reply-To: <20120628134308.GD15863@spongy>
References: <20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
	<1340887016.10942.42.camel@zakaz.uk.xensource.com>
	<20120628134308.GD15863@spongy>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to 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, 2012-06-28 at 14:43 +0100, Jean Guyader wrote:
> On 28/06 01:36, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
> > > On 28/06 12:58, Ian Campbell wrote:
> > > > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
> > > > > On 28/06 12:34, Ian Campbell wrote:
> > > > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
> > > > > > > On 26/06 03:38, Ian Campbell wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Sorry it's taken me so long to get round to responding to this.
> > > > > > > > 
> > > > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
> > > > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote:
> > > > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
> > > > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote:
> > > > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
> > > > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote:
> > > > > > > > > > >> > > Are you talking about having different version of V4V driver running
> > > > > > > > > > >> > > in the same VM?
> > > > > > > > > > >> >
> > > > > > > > > > >> > Yes.
> > > > > > > > > > >> >
> > > > > > > > > > >> > > I don't think that is a problem they both interact with Xen via
> > > > > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's
> > > > > > > > > > >> > > all fine.
> > > > > > > > > > >> >
> > > > > > > > > > >> > AFAICS if they both try to register the same port then one of them will
> > > > > > > > > > >> > silently get its ring discarded.  And if they both try to communicate
> > > > > > > > > > >> > with the same remote port their entries on the pending lists will get
> > > > > > > > > > >> > merged (which is probably not too bad).  I think the possibility for
> > > > > > > > > > >> > confusion depends on how you use the service.  Still, it seems better
> > > > > > > > > > >> > than the xenstore case, anyway. :)
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >> Not silently, register_ring will return an error.
> > > > > > > > > > >
> > > > > > > > > > > Will it?  It looks to me like v4v_ring_add just clobbers the old MFN
> > > > > > > > > > > list.
> > > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > > Ha yes. It does that now but I think it should return an error
> > > > > > > > > > informing up the stack that a ring has already been registered.
> > > > > > > > > 
> > > > > > > > > Actually, I think it's deliberate, to allow a guest to re-register all
> > > > > > > > > its rings after a suspend/resume or migration, without having to worry
> > > > > > > > > about whether it was actually migrated into a new domain or not. 
> > > > > > > > 
> > > > > > > > Which takes us back to the original issue Tim asked about with
> > > > > > > > cohabitation of multiple (perhaps just plain buggy or even malicious)
> > > > > > > > v4v clients in a single domain, doesn't it?
> > > > > > > > 
> > > > > > > 
> > > > > > > There is nothing wrong the two v4v driver running in the same guest.
> > > > > > > The probably that Tim reported was about trying to create two connections
> > > > > > > on the same port. Today with the code that I've submited in the RFC
> > > > > > > one will overwrite the other silently which isn't a good thing, that can
> > > > > > > easily be changed to notify which one got registered up the stack.
> > > > > > 
> > > > > > So they'd somehow need to randomise (and retry) their use of source
> > > > > > ports in order to co-exist?
> > > > > >
> > > > > 
> > > > > That can be assimilated to two userspace programs trying to bind to the
> > > > > same TCP port. I think it's not v4v's responsability to solve this problem.
> > > > 
> > > > An application using TCP doesn't need to worry about choosing its own
> > > > source port though.
> > > > 
> > > > Or does this only effect destination / listening ports?
> > > > 
> > > 
> > > The guest v4v driver knows which port are in used so if you put port 0
> > > we will pick a random unused number for the source port.
> > 
> > Except when there are two such drivers each doesn't know which the other
> > one is using.
> > 
> 
> Then the kernel will try to register the ring and the hypercall will fail
> because it's already registered.

At which point what happens? How do two unrelated V4V drivers co-exist
given 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 Jun 28 13:50:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkF76-0004UJ-4l; Thu, 28 Jun 2012 13:50: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 1SkF74-0004UB-TV
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:50:27 +0000
Received: from [85.158.143.35:48293] by server-2.bemta-4.messagelabs.com id
	71/3A-17938-2216CEF4; Thu, 28 Jun 2012 13:50:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340891417!16128056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13120 invoked from network); 28 Jun 2012 13:50:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13271041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:50:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 14:50:17 +0100
Message-ID: <1340891415.10942.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 14:50:15 +0100
In-Reply-To: <20460.24135.825405.29982@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 14:38 +0100, Ian Jackson wrote:
> I wrote:
> > This is v5 of my series to asyncify save/restore, rebased to tip and
> > retested.  There are minor changes to 3 patches, as discussed on-list,
> > marked with "*" below:
> ...
> >   * 06/21 libxl: domain save/restore: run in a separate process
> ...
> > However, first I will invite Shriram to check that Remus is still
> > working.  (I can't conveniently do this with this message due to
> > shoddiness in git-send-email.)
> 
> Following testing by Shriram (thanks) I have an updated version of
> 06/21.  For the sake of everyone's sanity (and your MUAs) I shan't
> repost the whole series.
> 
> Here is v6 of 06/21, which is simply the previous one with my earlier
> fixup patch folded in.
> 
> CC Ian Campbell since he'd acked the previous one.  Ian, I have left
> your ack on this version.  I trust that's OK.

Absolutely fine.

Does this mean this series is now ready to go in?

I did wonder when I saw the incremental patch if some of those internal
callback pointers could perhaps be properly typed instead of void
(because they all end up taking the same pointer type), but lets not
worry about that here.

Ian.

> 
> Thanks,
> Ian.
> 
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: domain save/restore: run in a separate process
> 
> libxenctrl expects to be able to simply run the save or restore
> operation synchronously.  This won't work well in a process which is
> trying to handle multiple domains.
> 
> The options are:
> 
>  - Block such a whole process (eg, the whole of libvirt) while
>    migration completes (or until it fails).
> 
>  - Create a thread to run xc_domain_save and xc_domain_restore on.
>    This is quite unpalatable.  Multithreaded programming is error
>    prone enough without generating threads in libraries, particularly
>    if the thread does some very complex operation.
> 
>  - Fork and run the operation in the child without execing.  This is
>    no good because we would need to negotiate with the caller about
>    fds we would inherit (and we might be a very large process).
> 
>  - Fork and exec a helper.
> 
> Of these options the latter is the most palatable.
> 
> Consequently:
> 
>  * A new helper program libxl-save-helper (which does both save and
>    restore).  It will be installed in /usr/lib/xen/bin.  It does not
>    link against libxl, only libxc, and its error handling does not
>    need to be very advanced.  It does contain a plumbing through of
>    the logging interface into the callback stream.
> 
>  * A small ad-hoc protocol between the helper and libxl which allows
>    log messages and the libxc callbacks to be passed up and down.
>    Protocol doc comment is in libxl_save_helper.c.
> 
>  * To avoid a lot of tedium the marshalling boilerplate (stubs for the
>    helper and the callback decoder for libxl) is generated with a
>    small perl script.
> 
>  * Implement new functionality to spawn the helper, monitor its
>    output, provide responses, and check on its exit status.
> 
>  * The functions libxl__xc_domain_restore_done and
>    libxl__xc_domain_save_done now turn out to want be called in the
>    same place.  So make their state argument a void* so that the two
>    functions are type compatible.
> 
> The domain save path still writes the qemu savefile synchronously.
> This will need to be fixed in a subsequent patch.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> -
> Changes in v6:
>  * The void* passed to the callback was being treated as a
>    libxl__domain_suspend_state* by the remus callbacks; this is a
>    holdover from a much earlier version of the series.  It is now
>    properly converted to a libxl__save_helper_state and then the dss
>    extracted with CONTAINER_OF.
>  * The way remus works means that the toolstack save callback is
>    invoked more than once, which the helper's implementation was not
>    prepared to deal with.  Fix this by moving the rewind of the fd
>    into the helper.
> 
> Changes in v5:
>  * assert that preserve_fds are >2.
> 
> Changes in v4:
>  * Migration stream fd is handled specially by the run_helper
>    function, rather than simply being a numarg.  Specifically:
>      - dup it to a safe fd number if necessary.
>      - clear cloexec flag fd before execing helper
>  * Toolstack data fd argument to run_helper replaced with
>    generic preserve_fds array, which get cloexec cleared.
>  * libxl__xc_domain_save uses supplied callback function pointer,
>    rather than calling libxl__toolstack_save directly;
>    toolstack data save callback is only supplied to libxc if
>    in-libxl caller supplied a callback.
>  * libxl-save-helper is not needlessly linked against libxl.
>  * Code which prepares pipes for helper clarified.
>  * Deal properly with, and log properly, POLLPRI/POLLERR on
>    pipe to save helper.
>  * Spelling fix in perl script comment.
>  * In message generator, use better names for the ends of serial
>    conditional here documents.
>  * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
> 
> Changes in v3:
>  * Suppress errno value in debug message when helper reports successful
>    completion.
>  * Significant consequential changes to cope with changes to
>    earlier patches in the series.
> 
> Changes in v2:
>  * Helper path can be overridden by an environment variable for testing.
>  * Add a couple of debug logging messages re toolstack data.
>  * Fixes from testing.
>  * Helper protocol message lengths (and numbers) are 16-bit which
>    more clearly avoids piling lots of junk on the stack.
>  * Merged with remus changes.
>  * Callback implementations in libxl now called via pointers
>    so remus can have its own callbacks.
>  * Better namespace prefixes on autogenerated names etc.
>  * Autogenerator can generate debugging printfs too.
> 
> ---
>  .gitignore                         |    1 +
>  .hgignore                          |    2 +
>  tools/libxl/Makefile               |   22 ++-
>  tools/libxl/libxl_create.c         |   22 ++-
>  tools/libxl/libxl_dom.c            |   42 +++--
>  tools/libxl/libxl_internal.h       |   56 +++++-
>  tools/libxl/libxl_save_callout.c   |  361 +++++++++++++++++++++++++++++++-
>  tools/libxl/libxl_save_helper.c    |  283 +++++++++++++++++++++++++
>  tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
>  9 files changed, 1146 insertions(+), 40 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 7770e54..3451e52 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -353,6 +353,7 @@ 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
> diff --git a/.hgignore b/.hgignore
> index 27d8f79..05304ea 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -180,9 +180,11 @@
>  ^tools/libxl/_.*\.c$
>  ^tools/libxl/libxlu_cfg_y\.output$
>  ^tools/libxl/xl$
> +^tools/libxl/libxl-save-helper$
>  ^tools/libxl/testidl$
>  ^tools/libxl/testidl\.c$
>  ^tools/libxl/tmp\..*$
> +^tools/libxl/.*\.new$
>  ^tools/libvchan/vchan-node[12]$
>  ^tools/libaio/src/.*\.ol$
>  ^tools/libaio/src/.*\.os$
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 1d8b80a..ddc2624 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o \
>                         libxl_json.o libxl_aoutils.o \
> -                       libxl_save_callout.o \
> +                       libxl_save_callout.o _libxl_save_msgs_callout.o \
>                         libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
> 
> -AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
> +AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
> +       _libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
>  AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
> +AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
>  LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
>         libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
>  $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
> 
> -CLIENTS = xl testidl
> +CLIENTS = xl testidl libxl-save-helper
> 
>  XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
>  $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
>  $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
>  $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
> 
> +SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
> +$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
> +
>  testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
>  testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
>         $(PYTHON) gentest.py libxl_types.idl testidl.c.new
> @@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
>         perl $^ --prefix=libxl >$@.new
>         $(call move-if-changed,$@.new,$@)
> 
> +_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
> +_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
> +               libxl_save_msgs_gen.pl
> +       $(PERL) -w $< $@ >$@.new
> +       $(call move-if-changed,$@.new,$@)
> +
>  libxl.h: _libxl_types.h
>  libxl_json.h: _libxl_types_json.h
>  libxl_internal.h: _libxl_types_internal.h _paths.h
> @@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
> 
> +libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
> +       $(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> +
>  testidl: testidl.o libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> 
> @@ -169,7 +183,9 @@ install: all
>         $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
>         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
>         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
> +       $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
>         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
>         $(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
>         ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
>         ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 9c3c671..7b92539 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -662,7 +662,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>      libxl_domain_build_info *const info = &d_config->b_info;
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> -    struct restore_callbacks *const callbacks = &dcs->callbacks;
> +    libxl__srm_restore_autogen_callbacks *const callbacks =
> +        &dcs->shs.callbacks.restore.a;
> 
>      if (rc) domcreate_rebuild_done(egc, dcs, rc);
> 
> @@ -702,7 +703,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>          pae = libxl_defbool_val(info->u.hvm.pae);
>          no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
>          callbacks->toolstack_restore = libxl__toolstack_restore;
> -        callbacks->data = gc;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
> @@ -722,10 +722,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>      libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
>  }
> 
> -void libxl__xc_domain_restore_done(libxl__egc *egc,
> -                                   libxl__domain_create_state *dcs,
> +void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
> +          unsigned long console_mfn, unsigned long genidad, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
> +    STATE_AO_GC(dcs->ao);
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +
> +    state->store_mfn =            store_mfn;
> +    state->console_mfn =          console_mfn;
> +    state->vm_generationid_addr = genidad;
> +    shs->need_results =           0;
> +}
> +
> +void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
>                                     int ret, int retval, int errnoval)
>  {
> +    libxl__domain_create_state *dcs = dcs_void;
>      STATE_AO_GC(dcs->ao);
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      char **vments = NULL, **localents = NULL;
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index c44dec0..0e0dbee 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -467,16 +467,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>  }
> 
>  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> -        uint32_t size, void *data)
> +                             uint32_t size, void *user)
>  {
> -    libxl__gc *gc = data;
> -    libxl_ctx *ctx = gc->owner;
> +    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;
>      struct libxl__physmap_info* pi;
>      char *xs_path;
> 
> +    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
> +
>      if (size < sizeof(version) + sizeof(count)) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
>          return -1;
> @@ -529,9 +533,10 @@ static void domain_suspend_done(libxl__egc *egc,
>  /*----- callbacks, called by xc_domain_save -----*/
> 
>  int libxl__domain_suspend_common_switch_qemu_logdirty
> -                               (int domid, unsigned int enable, void *data)
> +                               (int domid, unsigned enable, void *user)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = user;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
>      char *path;
>      bool rc;
> @@ -597,9 +602,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
>      return 0;
>  }
> 
> -int libxl__domain_suspend_common_callback(void *data)
> +int libxl__domain_suspend_common_callback(void *user)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = user;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
>      unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
>      int ret;
> @@ -739,9 +745,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
>  }
> 
>  int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> -        uint32_t *len, void *data)
> +        uint32_t *len, void *dss_void)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__domain_suspend_state *dss = dss_void;
>      STATE_AO_GC(dss->ao);
>      int i = 0;
>      char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
> @@ -810,6 +816,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
>          ptr += sizeof(struct libxl__physmap_info) + namelen;
>      }
> 
> +    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
> +
>      return 0;
>  }
> 
> @@ -823,7 +831,8 @@ static int libxl__remus_domain_suspend_callback(void *data)
> 
>  static int libxl__remus_domain_resume_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
> 
>      /* Resumes the domain and the device model */
> @@ -836,7 +845,8 @@ static int libxl__remus_domain_resume_callback(void *data)
> 
>  static int libxl__remus_domain_checkpoint_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
> 
>      /* This would go into tailbuf. */
> @@ -864,7 +874,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>      const int live = dss->live;
>      const int debug = dss->debug;
>      const libxl_domain_remus_info *const r_info = dss->remus;
> -    struct save_callbacks *const callbacks = &dss->callbacks;
> +    libxl__srm_save_autogen_callbacks *const callbacks =
> +        &dss->shs.callbacks.save.a;
> 
>      switch (type) {
>      case LIBXL_DOMAIN_TYPE_HVM: {
> @@ -925,8 +936,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>          callbacks->suspend = libxl__domain_suspend_common_callback;
> 
>      callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
> -    callbacks->toolstack_save = libxl__toolstack_save;
> -    callbacks->data = dss;
> +    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
> 
>      libxl__xc_domain_save(egc, dss, vm_generationid_addr);
>      return;
> @@ -935,10 +945,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>      domain_suspend_done(egc, dss, rc);
>  }
> 
> -void libxl__xc_domain_save_done(libxl__egc *egc,
> -                                libxl__domain_suspend_state *dss,
> +void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
>                                  int rc, int retval, int errnoval)
>  {
> +    libxl__domain_suspend_state *dss = dss_void;
>      STATE_AO_GC(dss->ao);
> 
>      /* Convenience aliases */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 7cf1b04..1a7b526 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -54,6 +54,7 @@
> 
>  #include "libxl.h"
>  #include "_paths.h"
> +#include "_libxl_save_msgs_callout.h"
> 
>  #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
>  #define _hidden __attribute__((visibility("hidden")))
> @@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
>  _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
> 
> 
> +/*----- Save/restore helper (used by creation and suspend) -----*/
> +
> +typedef struct libxl__srm_save_callbacks {
> +    libxl__srm_save_autogen_callbacks a;
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
> +                          uint32_t *len, void *data);
> +} libxl__srm_save_callbacks;
> +
> +typedef struct libxl__srm_restore_callbacks {
> +    libxl__srm_restore_autogen_callbacks a;
> +} libxl__srm_restore_callbacks;
> +
> +/* a pointer to this struct is also passed as "user" to the
> + * save callout helper callback functions */
> +typedef struct libxl__save_helper_state {
> +    /* public, caller of run_helper initialises */
> +    libxl__ao *ao;
> +    uint32_t domid;
> +    union {
> +        libxl__srm_save_callbacks save;
> +        libxl__srm_restore_callbacks restore;
> +    } callbacks;
> +    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
> +    void (*completion_callback)(libxl__egc *egc, void *caller_state,
> +                                int rc, int retval, int errnoval);
> +    void *caller_state;
> +    int need_results; /* set to 0 or 1 by caller of run_helper;
> +                       * if set to 1 then the ultimate caller's
> +                       * results function must set it to 0 */
> +    /* private */
> +    int rc;
> +    int completed; /* retval/errnoval valid iff completed */
> +    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
> +    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
> +    libxl__ev_fd readable;
> +    libxl__ev_child child;
> +    const char *stdin_what, *stdout_what;
> +    FILE *toolstack_data_file;
> +
> +    libxl__egc *egc; /* valid only for duration of each event callback;
> +                      * is here in this struct for the benefit of the
> +                      * marshalling and xc callback functions */
> +} libxl__save_helper_state;
> +
> +
>  /*----- Domain suspend (save) state structure -----*/
> 
>  typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
> @@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
>      int xcflags;
>      int guest_responded;
>      int interval; /* checkpoint interval (for Remus) */
> -    struct save_callbacks callbacks;
> +    libxl__save_helper_state shs;
>  };
> 
> 
> @@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
>      libxl__stub_dm_spawn_state dmss;
>          /* If we're not doing stubdom, we use only dmss.dm,
>           * for the non-stubdom device model. */
> -    struct restore_callbacks callbacks;
> +    libxl__save_helper_state shs;
>  };
> 
>  /*----- Domain suspend (save) functions -----*/
> @@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
>  /* If rc==0 then retval is the return value from xc_domain_save
>   * and errnoval is the errno value it provided.
>   * If rc!=0, retval and errnoval are undefined. */
> -_hidden void libxl__xc_domain_save_done(libxl__egc*,
> -                                        libxl__domain_suspend_state*,
> +_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
>                                          int rc, int retval, int errnoval);
> 
>  _hidden int libxl__domain_suspend_common_callback(void *data);
> @@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
>  /* If rc==0 then retval is the return value from xc_domain_save
>   * and errnoval is the errno value it provided.
>   * If rc!=0, retval and errnoval are undefined. */
> -_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
> -                                           libxl__domain_create_state *dcs,
> +_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
>                                             int rc, int retval, int errnoval);
> 
> 
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> index 1b481ab..a6abcda 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -16,6 +16,30 @@
> 
>  #include "libxl_internal.h"
> 
> +/* stream_fd is as from the caller (eventually, the application).
> + * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
> + * The actual fd value is not included in the supplied argnums; rather
> + * it will be automatically supplied by run_helper as the 2nd argument.
> + *
> + * preserve_fds are fds that the caller is intending to pass to the
> + * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
> + * An entry may be -1 in which case it will be ignored.
> + */
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg,
> +                       int stream_fd,
> +                       const int *preserve_fds, int num_preserve_fds,
> +                       const unsigned long *argnums, int num_argnums);
> +
> +static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status);
> +static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
> +
> +/*----- entrypoints -----*/
> +
>  void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>                                int hvm, int pae, int superpages,
>                                int no_incr_generationid)
> @@ -27,22 +51,337 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> 
> -    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
> -                              state->store_port, &state->store_mfn,
> -                              state->store_domid, state->console_port,
> -                              &state->console_mfn, state->console_domid,
> -                              hvm, pae, superpages, no_incr_generationid,
> -                              &state->vm_generationid_addr, &dcs->callbacks);
> -    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
> +        (&dcs->shs.callbacks.restore.a);
> +
> +    const unsigned long argnums[] = {
> +        domid,
> +        state->store_port,
> +        state->store_domid, state->console_port,
> +        state->console_domid,
> +        hvm, pae, superpages, no_incr_generationid,
> +        cbflags,
> +    };
> +
> +    dcs->shs.ao = ao;
> +    dcs->shs.domid = domid;
> +    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
> +    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
> +    dcs->shs.caller_state = dcs;
> +    dcs->shs.need_results = 1;
> +    dcs->shs.toolstack_data_file = 0;
> +
> +    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
> +               argnums, ARRAY_SIZE(argnums));
>  }
> 
>  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
>                             unsigned long vm_generationid_addr)
>  {
>      STATE_AO_GC(dss->ao);
> -    int r;
> +    int r, rc, toolstack_data_fd = -1;
> +    uint32_t toolstack_data_len = 0;
> +
> +    /* Resources we need to free */
> +    uint8_t *toolstack_data_buf = 0;
> +
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> +        (&dss->shs.callbacks.save.a);
> +
> +    if (dss->shs.callbacks.save.toolstack_save) {
> +        r = dss->shs.callbacks.save.toolstack_save
> +            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
> +        if (r) { rc = ERROR_FAIL; goto out; }
> +
> +        dss->shs.toolstack_data_file = tmpfile();
> +        if (!dss->shs.toolstack_data_file) {
> +            LOGE(ERROR, "cannot create toolstack data tmpfile");
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
> +
> +        r = libxl_write_exactly(CTX, toolstack_data_fd,
> +                                toolstack_data_buf, toolstack_data_len,
> +                                "toolstack data tmpfile", 0);
> +        if (r) { rc = ERROR_FAIL; goto out; }
> +    }
> +
> +    const unsigned long argnums[] = {
> +        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
> +        toolstack_data_fd, toolstack_data_len,
> +        cbflags,
> +    };
> +
> +    dss->shs.ao = ao;
> +    dss->shs.domid = dss->domid;
> +    dss->shs.recv_callback = libxl__srm_callout_received_save;
> +    dss->shs.completion_callback = libxl__xc_domain_save_done;
> +    dss->shs.caller_state = dss;
> +    dss->shs.need_results = 0;
> +
> +    free(toolstack_data_buf);
> +
> +    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
> +               &toolstack_data_fd, 1,
> +               argnums, ARRAY_SIZE(argnums));
> +    return;
> +
> + out:
> +    free(toolstack_data_buf);
> +    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
> +
> +    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
> +}
> +
> +
> +/*----- helper execution -----*/
> +
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int stream_fd,
> +                       const int *preserve_fds, int num_preserve_fds,
> +                       const unsigned long *argnums, int num_argnums)
> +{
> +    STATE_AO_GC(shs->ao);
> +    const char *args[4 + num_argnums];
> +    const char **arg = args;
> +    int i, rc;
> +
> +    /* Resources we must free */
> +    libxl__carefd *childs_pipes[2] = { 0,0 };
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    shs->rc = 0;
> +    shs->completed = 0;
> +    shs->pipes[0] = shs->pipes[1] = 0;
> +    libxl__ev_fd_init(&shs->readable);
> +    libxl__ev_child_init(&shs->child);
> +
> +    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                " stdin pipe", domid);
> +    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                 " stdout pipe", domid);
> +
> +    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
> +    *arg++ = mode_arg;
> +    const char **stream_fd_arg = arg++;
> +    for (i=0; i<num_argnums; i++)
> +        *arg++ = GCSPRINTF("%lu", argnums[i]);
> +    *arg++ = 0;
> +    assert(arg == args + ARRAY_SIZE(args));
> +
> +    libxl__carefd_begin();
> +    int childfd;
> +    for (childfd=0; childfd<2; childfd++) {
> +        /* Setting up the pipe for the child's fd childfd */
> +        int fds[2];
> +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> +        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
> +        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
> +        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
> +        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
> +    }
> +    libxl__carefd_unlock();
> +
> +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> +    if (!pid) {
> +        if (stream_fd <= 2) {
> +            stream_fd = dup(stream_fd);
> +            if (stream_fd < 0) {
> +                LOGE(ERROR,"dup migration stream fd");
> +                exit(-1);
> +            }
> +        }
> +        libxl_fd_set_cloexec(CTX, stream_fd, 0);
> +        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
> +
> +        for (i=0; i<num_preserve_fds; i++)
> +            if (preserve_fds[i] >= 0) {
> +                assert(preserve_fds[i] > 2);
> +                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
> +            }
> +
> +        libxl__exec(gc,
> +                    libxl__carefd_fd(childs_pipes[0]),
> +                    libxl__carefd_fd(childs_pipes[1]),
> +                    -1,
> +                    args[0], (char**)args, 0);
> +    }
> +
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +
> +    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
> +                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
> +    if (rc) goto out;
> +    return;
> +
> + out:
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +    helper_failed(egc, shs, rc);;
> +}
> +
> +static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
> +                          int rc)
> +{
> +    STATE_AO_GC(shs->ao);
> +
> +    if (!shs->rc)
> +        shs->rc = rc;
> +
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +
> +    if (!libxl__ev_child_inuse(&shs->child)) {
> +        helper_done(egc, shs);
> +        return;
> +    }
> +
> +    int r = kill(shs->child.pid, SIGKILL);
> +    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
> +                (unsigned long)shs->child.pid);
> +}
> +
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
> +    STATE_AO_GC(shs->ao);
> +    int rc, errnoval;
> +
> +    if (revents & (POLLERR|POLLPRI)) {
> +        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
> +            shs->stdout_what, revents);
> +        rc = ERROR_FAIL;
> + out:
> +        /* this is here because otherwise we bypass the decl of msg[] */
> +        helper_failed(egc, shs, rc);
> +        return;
> +    }
> +
> +    uint16_t msglen;
> +    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
> +                                  shs->stdout_what, "ipc msg header");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    unsigned char msg[msglen];
> +    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
> +                                  shs->stdout_what, "ipc msg body");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    shs->egc = egc;
> +    shs->recv_callback(msg, msglen, shs);
> +    shs->egc = 0;
> +    return;
> +}
> +
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
> +    STATE_AO_GC(shs->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    const char *what =
> +        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
> +
> +    if (status) {
> +        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (shs->need_results) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without providing results",what);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (!shs->completed) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without signaling completion",what);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    helper_done(egc, shs);
> +    return;
> +}
> +
> +static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
> +{
> +    STATE_AO_GC(shs->ao);
> +
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
> +    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
> +    assert(!libxl__ev_child_inuse(&shs->child));
> +    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
> +
> +    shs->egc = egc;
> +    shs->completion_callback(egc, shs->caller_state,
> +                             shs->rc, shs->retval, shs->errnoval);
> +    shs->egc = 0;
> +}
> +
> +/*----- generic helpers for the autogenerated code -----*/
> +
> +const libxl__srm_save_autogen_callbacks*
> +libxl__srm_callout_get_callbacks_save(void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    return &shs->callbacks.save.a;
> +}
> +
> +const libxl__srm_restore_autogen_callbacks*
> +libxl__srm_callout_get_callbacks_restore(void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    return &shs->callbacks.restore.a;
> +}
> +
> +void libxl__srm_callout_sendreply(int r, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    libxl__egc *egc = shs->egc;
> +    STATE_AO_GC(shs->ao);
> +    int errnoval;
> +
> +    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
> +                                   &r, sizeof(r), shs->stdin_what,
> +                                   "callback return value");
> +    if (errnoval)
> +        helper_failed(egc, shs, ERROR_FAIL);
> +}
> +
> +void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
> +                  const char *context, const char *formatted, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    STATE_AO_GC(shs->ao);
> +    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
> +}
> +
> +void libxl__srm_callout_callback_progress(const char *context,
> +                   const char *doing_what, unsigned long done,
> +                   unsigned long total, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    STATE_AO_GC(shs->ao);
> +    xtl_progress(CTX->lg, context, doing_what, done, total);
> +}
> +
> +int libxl__srm_callout_callback_complete(int retval, int errnoval,
> +                                         void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    STATE_AO_GC(shs->ao);
> 
> -    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
> -                       &dss->callbacks, dss->hvm, vm_generationid_addr);
> -    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
> +    shs->completed = 1;
> +    shs->retval = retval;
> +    shs->errnoval = errnoval;
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +    return 0;
>  }
> diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
> new file mode 100644
> index 0000000..772251a
> --- /dev/null
> +++ b/tools/libxl/libxl_save_helper.c
> @@ -0,0 +1,283 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +/*
> + * The libxl-save-helper utility speaks a protocol to its caller for
> + * the callbacks.  The protocol is as follows.
> + *
> + * The helper talks on stdin and stdout, in binary in machine
> + * endianness.  The helper speaks first, and only when it has a
> + * callback to make.  It writes a 16-bit number being the message
> + * length, and then the message body.
> + *
> + * Each message starts with a 16-bit number indicating which of the
> + * messages it is, and then some arguments in a binary marshalled form.
> + * If the callback does not need a reply (it returns void), the helper
> + * just continues.  Otherwise the helper waits for its caller to send a
> + * single int which is to be the return value from the callback.
> + *
> + * Where feasible the stubs and callbacks have prototypes identical to
> + * those required by xc_domain_save and xc_domain_restore, so that the
> + * autogenerated functions can be used/provided directly.
> + *
> + * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
> + */
> +
> +#include "libxl_osdeps.h"
> +
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <assert.h>
> +#include <inttypes.h>
> +
> +#include "libxl.h"
> +
> +#include "xenctrl.h"
> +#include "xenguest.h"
> +#include "_libxl_save_msgs_helper.h"
> +
> +/*----- globals -----*/
> +
> +static const char *program = "libxl-save-helper";
> +static xentoollog_logger *logger;
> +static xc_interface *xch;
> +
> +/*----- error handling -----*/
> +
> +static void fail(int errnoval, const char *fmt, ...)
> +    __attribute__((noreturn,format(printf,2,3)));
> +static void fail(int errnoval, const char *fmt, ...)
> +{
> +    va_list al;
> +    va_start(al,fmt);
> +    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
> +    exit(-1);
> +}
> +
> +static int read_exactly(int fd, void *buf, size_t len)
> +/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
> +{
> +    while (len) {
> +        ssize_t r = read(fd, buf, len);
> +        if (r<=0) return r;
> +        assert(r <= len);
> +        len -= r;
> +        buf = (char*)buf + r;
> +    }
> +    return 1;
> +}
> +
> +static void *xmalloc(size_t sz)
> +{
> +    if (!sz) return 0;
> +    void *r = malloc(sz);
> +    if (!r) { perror("memory allocation failed"); exit(-1); }
> +    return r;
> +}
> +
> +/*----- logger -----*/
> +
> +typedef struct {
> +    xentoollog_logger vtable;
> +} xentoollog_logger_tellparent;
> +
> +static void tellparent_vmessage(xentoollog_logger *logger_in,
> +                                xentoollog_level level,
> +                                int errnoval,
> +                                const char *context,
> +                                const char *format,
> +                                va_list al)
> +{
> +    char *formatted;
> +    int r = vasprintf(&formatted, format, al);
> +    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
> +    helper_stub_log(level, errnoval, context, formatted, 0);
> +    free(formatted);
> +}
> +
> +static void tellparent_progress(struct xentoollog_logger *logger_in,
> +                                const char *context,
> +                                const char *doing_what, int percent,
> +                                unsigned long done, unsigned long total)
> +{
> +    helper_stub_progress(context, doing_what, done, total, 0);
> +}
> +
> +static void tellparent_destroy(struct xentoollog_logger *logger_in)
> +{
> +    abort();
> +}
> +
> +static xentoollog_logger_tellparent *createlogger_tellparent(void)
> +{
> +    xentoollog_logger_tellparent newlogger;
> +    return XTL_NEW_LOGGER(tellparent, newlogger);
> +}
> +
> +/*----- helper functions called by autogenerated stubs -----*/
> +
> +unsigned char * helper_allocbuf(int len, void *user)
> +{
> +    return xmalloc(len);
> +}
> +
> +static void transmit(const unsigned char *msg, int len, void *user)
> +{
> +    while (len) {
> +        int r = write(1, msg, len);
> +        if (r<0) { perror("write"); exit(-1); }
> +        assert(r >= 0);
> +        assert(r <= len);
> +        len -= r;
> +        msg += r;
> +    }
> +}
> +
> +void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
> +{
> +    assert(len_in < 64*1024);
> +    uint16_t len = len_in;
> +    transmit((const void*)&len, sizeof(len), user);
> +    transmit(msg_freed, len, user);
> +    free(msg_freed);
> +}
> +
> +int helper_getreply(void *user)
> +{
> +    int v;
> +    int r = read_exactly(0, &v, sizeof(v));
> +    if (r<=0) exit(-2);
> +    return v;
> +}
> +
> +/*----- other callbacks -----*/
> +
> +static int toolstack_save_fd;
> +static uint32_t toolstack_save_len;
> +
> +static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
> +                             uint32_t *len, void *data)
> +{
> +    assert(toolstack_save_fd > 0);
> +
> +    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
> +    if (r) fail(errno,"rewind toolstack data tmpfile");
> +
> +    *buf = xmalloc(toolstack_save_len);
> +    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
> +    if (r<0) fail(errno,"read toolstack data");
> +    if (r==0) fail(0,"read toolstack data eof");
> +
> +    *len = toolstack_save_len;
> +    return 0;
> +}
> +
> +static void startup(const char *op) {
> +    logger = (xentoollog_logger*)createlogger_tellparent();
> +    if (!logger) {
> +        fprintf(stderr, "%s: cannot initialise logger\n", program);
> +        exit(-1);
> +    }
> +
> +    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
> +
> +    xch = xc_interface_open(logger,logger,0);
> +    if (!xch) fail(errno,"xc_interface_open failed");
> +}
> +
> +static void complete(int retval) {
> +    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
> +    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
> +    helper_stub_complete(retval,errnoval,0);
> +    exit(0);
> +}
> +
> +static struct save_callbacks helper_save_callbacks;
> +static struct restore_callbacks helper_restore_callbacks;
> +
> +int main(int argc, char **argv)
> +{
> +    int r;
> +
> +#define NEXTARG (++argv, assert(*argv), *argv)
> +
> +    const char *mode = *++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);
> +        assert(!*++argv);
> +
> +        if (toolstack_save_fd >= 0)
> +            helper_save_callbacks.toolstack_save = toolstack_save_cb;
> +
> +        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);
> +        complete(r);
> +
> +    } else if (!strcmp(mode,"--restore-domain")) {
> +
> +        int io_fd =                atoi(NEXTARG);
> +        uint32_t dom =             strtoul(NEXTARG,0,10);
> +        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
> +        domid_t store_domid =      strtoul(NEXTARG,0,10);
> +        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
> +        domid_t console_domid =    strtoul(NEXTARG,0,10);
> +        unsigned int hvm =         strtoul(NEXTARG,0,10);
> +        unsigned int pae =         strtoul(NEXTARG,0,10);
> +        int superpages =           strtoul(NEXTARG,0,10);
> +        int no_incr_genidad =      strtoul(NEXTARG,0,10);
> +        unsigned cbflags =         strtoul(NEXTARG,0,10);
> +        assert(!*++argv);
> +
> +        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
> +
> +        unsigned long store_mfn = 0;
> +        unsigned long console_mfn = 0;
> +        unsigned long genidad = 0;
> +
> +        startup("restore");
> +        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
> +                              store_domid, console_evtchn, &console_mfn,
> +                              console_domid, hvm, pae, superpages,
> +                              no_incr_genidad, &genidad,
> +                              &helper_restore_callbacks);
> +        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
> +        complete(r);
> +
> +    } else {
> +        assert(!"unexpected mode argument");
> +    }
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> new file mode 100755
> index 0000000..c45986e
> --- /dev/null
> +++ b/tools/libxl/libxl_save_msgs_gen.pl
> @@ -0,0 +1,397 @@
> +#!/usr/bin/perl -w
> +
> +use warnings;
> +use strict;
> +use POSIX;
> +
> +our $debug = 0; # produce copious debugging output at run-time?
> +
> +our @msgs = (
> +    # flags:
> +    #   s  - applicable to save
> +    #   r  - applicable to restore
> +    #   c  - function pointer in callbacks struct rather than fixed function
> +    #   x  - function pointer is in struct {save,restore}_callbacks
> +    #         and its null-ness needs to be passed through to the helper's xc
> +    #   W  - needs a return value; callback is synchronous
> +    [  1, 'sr',     "log",                   [qw(uint32_t level
> +                                                 uint32_t errnoval
> +                                                 STRING context
> +                                                 STRING formatted)] ],
> +    [  2, 'sr',     "progress",              [qw(STRING context
> +                                                 STRING doing_what),
> +                                                'unsigned long', 'done',
> +                                                'unsigned long', 'total'] ],
> +    [  3, 'scxW',   "suspend", [] ],
> +    [  4, 'scxW',   "postcopy", [] ],
> +    [  5, 'scxW',   "checkpoint", [] ],
> +    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
> +                                              unsigned enable)] ],
> +    #                toolstack_save          done entirely `by hand'
> +    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
> +                                                BLOCK tsdata)] ],
> +    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
> +                                              'unsigned long', 'console_mfn',
> +                                              'unsigned long', 'genidad'] ],
> +    [  9, 'srW',    "complete",              [qw(int retval
> +                                                 int errnoval)] ],
> +);
> +
> +#----------------------------------------
> +
> +our %cbs;
> +our %func;
> +our %func_ah;
> +our @outfuncs;
> +our %out_decls;
> +our %out_body;
> +our %msgnum_used;
> +
> +die unless @ARGV==1;
> +die if $ARGV[0] =~ m/^-/;
> +
> +our ($intendedout) = @ARGV;
> +
> +$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
> +my ($want_ah, $ch) = ($1, $2);
> +
> +my $declprefix = '';
> +
> +foreach my $ah (qw(callout helper)) {
> +    $out_body{$ah} .=
> +        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
> +#include "libxl_osdeps.h"
> +
> +#include <assert.h>
> +#include <string.h>
> +#include <stdint.h>
> +#include <limits.h>
> +END_BOTH
> +
> +#include "libxl_internal.h"
> +
> +END_CALLOUT
> +
> +#include "_libxl_save_msgs_${ah}.h"
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +END_HELPER
> +}
> +
> +die $want_ah unless defined $out_body{$want_ah};
> +
> +sub f_decl ($$$$) {
> +    my ($name, $ah, $c_rtype, $c_decl) = @_;
> +    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
> +    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
> +    $func_ah{$name} = $ah;
> +}
> +
> +sub f_more ($$) {
> +    my ($name, $addbody) = @_;
> +    $func{$name} ||= '';
> +    $func{$name} .= $addbody;
> +    push @outfuncs, $name;
> +}
> +
> +our $libxl = "libxl__srm";
> +our $callback = "${libxl}_callout_callback";
> +our $receiveds = "${libxl}_callout_received";
> +our $sendreply = "${libxl}_callout_sendreply";
> +our $getcallbacks = "${libxl}_callout_get_callbacks";
> +our $enumcallbacks = "${libxl}_callout_enumcallbacks";
> +sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
> +
> +f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
> +
> +our $helper = "helper";
> +our $encode = "${helper}_stub";
> +our $allocbuf = "${helper}_allocbuf";
> +our $transmit = "${helper}_transmitmsg";
> +our $getreply = "${helper}_getreply";
> +our $setcallbacks = "${helper}_setcallbacks";
> +
> +f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
> +f_decl($transmit, 'helper', 'void',
> +       '(unsigned char *msg_freed, int len, void *user)');
> +f_decl($getreply, 'helper', 'int', '(void *user)');
> +
> +sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
> +
> +$out_body{'callout'} .= <<END;
> +static int bytes_get(const unsigned char **msg,
> +                    const unsigned char *const endmsg,
> +                    void *result, int rlen)
> +{
> +    if (endmsg - *msg < rlen) return 0;
> +    memcpy(result,*msg,rlen);
> +    *msg += rlen;
> +    return 1;
> +}
> +
> +END
> +$out_body{'helper'} .= <<END;
> +static void bytes_put(unsigned char *const buf, int *len,
> +                     const void *value, int vlen)
> +{
> +    assert(vlen < INT_MAX/2 - *len);
> +    if (buf)
> +       memcpy(buf + *len, value, vlen);
> +    *len += vlen;
> +}
> +
> +END
> +
> +foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
> +    my $typeid = typeid($simpletype);
> +    $out_body{'callout'} .= <<END;
> +static int ${typeid}_get(const unsigned char **msg,
> +                        const unsigned char *const endmsg,
> +                        $simpletype *result)
> +{
> +    return bytes_get(msg, endmsg, result, sizeof(*result));
> +}
> +
> +END
> +    $out_body{'helper'} .= <<END;
> +static void ${typeid}_put(unsigned char *const buf, int *len,
> +                        const $simpletype value)
> +{
> +    bytes_put(buf, len, &value, sizeof(value));
> +}
> +
> +END
> +}
> +
> +$out_body{'callout'} .= <<END;
> +static int BLOCK_get(const unsigned char **msg,
> +                      const unsigned char *const endmsg,
> +                      const uint8_t **result, uint32_t *result_size)
> +{
> +    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
> +    if (endmsg - *msg < *result_size) return 0;
> +    *result = (const void*)*msg;
> +    *msg += *result_size;
> +    return 1;
> +}
> +
> +static int STRING_get(const unsigned char **msg,
> +                      const unsigned char *const endmsg,
> +                      const char **result)
> +{
> +    const uint8_t *data;
> +    uint32_t datalen;
> +    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
> +    if (datalen == 0) return 0;
> +    if (data[datalen-1] != '\\0') return 0;
> +    *result = (const void*)data;
> +    return 1;
> +}
> +
> +END
> +$out_body{'helper'} .= <<END;
> +static void BLOCK_put(unsigned char *const buf,
> +                      int *len,
> +                     const uint8_t *bytes, uint32_t size)
> +{
> +    uint32_t_put(buf, len, size);
> +    bytes_put(buf, len, bytes, size);
> +}
> +
> +static void STRING_put(unsigned char *const buf,
> +                      int *len,
> +                      const char *string)
> +{
> +    size_t slen = strlen(string);
> +    assert(slen < INT_MAX / 4);
> +    assert(slen < (uint32_t)0x40000000);
> +    BLOCK_put(buf, len, (const void*)string, slen+1);
> +}
> +
> +END
> +
> +foreach my $sr (qw(save restore)) {
> +    f_decl("${getcallbacks}_${sr}", 'callout',
> +           "const ".cbtype($sr)." *",
> +           "(void *data)");
> +
> +    f_decl("${receiveds}_${sr}", 'callout', 'int',
> +          "(const unsigned char *msg, uint32_t len, void *user)");
> +
> +    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
> +           "(const ".cbtype($sr)." *cbs)");
> +    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
> +
> +    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
> +           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
> +
> +    f_more("${receiveds}_${sr}",
> +           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
> +    const unsigned char *const endmsg = msg + len;
> +    uint16_t mtype;
> +    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
> +END_ALWAYS
> +    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
> +END_DEBUG
> +    switch (mtype) {
> +
> +END_ALWAYS
> +
> +    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
> +}
> +
> +foreach my $msginfo (@msgs) {
> +    my ($msgnum, $flags, $name, $args) = @$msginfo;
> +    die if $msgnum_used{$msgnum}++;
> +
> +    my $f_more_sr = sub {
> +        my ($contents_spec, $fnamebase) = @_;
> +        $fnamebase ||= "${receiveds}";
> +        foreach my $sr (qw(save restore)) {
> +            $sr =~ m/^./;
> +            next unless $flags =~ m/$&/;
> +            my $contents = (!ref $contents_spec) ? $contents_spec :
> +                $contents_spec->($sr);
> +            f_more("${fnamebase}_${sr}", $contents);
> +        }
> +    };
> +
> +    $f_more_sr->("    case $msgnum: { /* $name */\n");
> +    if ($flags =~ m/W/) {
> +        $f_more_sr->("        int r;\n");
> +    }
> +
> +    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
> +    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
> +    my $c_decl = '(';
> +    my $c_callback_args = '';
> +
> +    f_more("${encode}_$name",
> +           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
> +    unsigned char *buf = 0;
> +    int len = 0, allocd = 0;
> +
> +END_ALWAYS
> +    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
> +END_DEBUG
> +    for (;;) {
> +        uint16_t_put(buf, &len, $msgnum /* $name */);
> +END_ALWAYS
> +
> +    my @args = @$args;
> +    my $c_recv = '';
> +    my ($argtype, $arg);
> +    while (($argtype, $arg, @args) = @args) {
> +       my $typeid = typeid($argtype);
> +        my $c_args = "$arg";
> +        my $c_get_args = "&$arg";
> +       if ($argtype eq 'STRING') {
> +           $c_decl .= "const char *$arg, ";
> +           $f_more_sr->("        const char *$arg;\n");
> +        } elsif ($argtype eq 'BLOCK') {
> +            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
> +            $c_args .= ", ${arg}_size";
> +            $c_get_args .= ",&${arg}_size";
> +           $f_more_sr->("        const uint8_t *$arg;\n".
> +                         "        uint32_t ${arg}_size;\n");
> +       } else {
> +           $c_decl .= "$argtype $arg, ";
> +           $f_more_sr->("        $argtype $arg;\n");
> +       }
> +       $c_callback_args .= "$c_args, ";
> +       $c_recv.=
> +            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
> +        f_more("${encode}_$name", "    ${typeid}_put(buf, &len, $c_args);\n");
> +    }
> +    $f_more_sr->($c_recv);
> +    $c_decl .= "void *user)";
> +    $c_callback_args .= "user";
> +
> +    $f_more_sr->("        if (msg != endmsg) return 0;\n");
> +
> +    my $c_callback;
> +    if ($flags !~ m/c/) {
> +        $c_callback = "${callback}_$name";
> +    } else {
> +        $f_more_sr->(sub {
> +            my ($sr) = @_;
> +            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
> +            return
> +          "        const ".cbtype($sr)." *const cbs =\n".
> +            "            ${getcallbacks}_${sr}(user);\n";
> +                       });
> +        $c_callback = "cbs->${name}";
> +    }
> +    my $c_make_callback = "$c_callback($c_callback_args)";
> +    if ($flags !~ m/W/) {
> +       $f_more_sr->("        $c_make_callback;\n");
> +    } else {
> +        $f_more_sr->("        r = $c_make_callback;\n".
> +                     "        $sendreply(r, user);\n");
> +       f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
> +    }
> +    if ($flags =~ m/x/) {
> +        my $c_v = "(1u<<$msgnum)";
> +        my $c_cb = "cbs->$name";
> +        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
> +        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
> +                     $setcallbacks);
> +    }
> +    $f_more_sr->("        return 1;\n    }\n\n");
> +    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
> +    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
> +    f_more("${encode}_$name",
> +"        if (buf) break;
> +        buf = ${helper}_allocbuf(len, user);
> +        assert(buf);
> +        allocd = len;
> +        len = 0;
> +    }
> +    assert(len == allocd);
> +    ${transmit}(buf, len, user);
> +");
> +    if ($flags =~ m/W/) {
> +       f_more("${encode}_$name",
> +               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
> +    int r = ${helper}_getreply(user);
> +END_ALWAYS
> +    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
> +END_DEBUG
> +    return r;
> +END_ALWAYS
> +    }
> +}
> +
> +print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
> +
> +foreach my $sr (qw(save restore)) {
> +    f_more("${enumcallbacks}_${sr}",
> +           "    return cbflags;\n");
> +    f_more("${receiveds}_${sr}",
> +           "    default:\n".
> +           "        return 0;\n".
> +           "    }");
> +    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
> +    if ($ch eq 'h') {
> +        print $cbs{$sr} or die $!;
> +        print "struct ${sr}_callbacks;\n";
> +    }
> +}
> +
> +if ($ch eq 'c') {
> +    foreach my $name (@outfuncs) {
> +        next unless defined $func{$name};
> +        $func{$name} .= "}\n\n";
> +        $out_body{$func_ah{$name}} .= $func{$name};
> +        delete $func{$name};
> +    }
> +    print $out_body{$want_ah} or die $!;
> +} else {
> +    foreach my $name (sort keys %out_decls) {
> +        next unless $func_ah{$name} eq $want_ah;
> +        print $out_decls{$name} or die $!;
> +    }
> +}
> +
> +close STDOUT or die $!;
> --
> tg: (52b6131..) t/xen/xc.save-restore-protocol (depends on: t/xen/xl.ao.suspend.pre)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:50:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkF76-0004UJ-4l; Thu, 28 Jun 2012 13:50: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 1SkF74-0004UB-TV
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:50:27 +0000
Received: from [85.158.143.35:48293] by server-2.bemta-4.messagelabs.com id
	71/3A-17938-2216CEF4; Thu, 28 Jun 2012 13:50:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340891417!16128056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13120 invoked from network); 28 Jun 2012 13:50:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13271041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 13:50:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 14:50:17 +0100
Message-ID: <1340891415.10942.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 14:50:15 +0100
In-Reply-To: <20460.24135.825405.29982@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 14:38 +0100, Ian Jackson wrote:
> I wrote:
> > This is v5 of my series to asyncify save/restore, rebased to tip and
> > retested.  There are minor changes to 3 patches, as discussed on-list,
> > marked with "*" below:
> ...
> >   * 06/21 libxl: domain save/restore: run in a separate process
> ...
> > However, first I will invite Shriram to check that Remus is still
> > working.  (I can't conveniently do this with this message due to
> > shoddiness in git-send-email.)
> 
> Following testing by Shriram (thanks) I have an updated version of
> 06/21.  For the sake of everyone's sanity (and your MUAs) I shan't
> repost the whole series.
> 
> Here is v6 of 06/21, which is simply the previous one with my earlier
> fixup patch folded in.
> 
> CC Ian Campbell since he'd acked the previous one.  Ian, I have left
> your ack on this version.  I trust that's OK.

Absolutely fine.

Does this mean this series is now ready to go in?

I did wonder when I saw the incremental patch if some of those internal
callback pointers could perhaps be properly typed instead of void
(because they all end up taking the same pointer type), but lets not
worry about that here.

Ian.

> 
> Thanks,
> Ian.
> 
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: domain save/restore: run in a separate process
> 
> libxenctrl expects to be able to simply run the save or restore
> operation synchronously.  This won't work well in a process which is
> trying to handle multiple domains.
> 
> The options are:
> 
>  - Block such a whole process (eg, the whole of libvirt) while
>    migration completes (or until it fails).
> 
>  - Create a thread to run xc_domain_save and xc_domain_restore on.
>    This is quite unpalatable.  Multithreaded programming is error
>    prone enough without generating threads in libraries, particularly
>    if the thread does some very complex operation.
> 
>  - Fork and run the operation in the child without execing.  This is
>    no good because we would need to negotiate with the caller about
>    fds we would inherit (and we might be a very large process).
> 
>  - Fork and exec a helper.
> 
> Of these options the latter is the most palatable.
> 
> Consequently:
> 
>  * A new helper program libxl-save-helper (which does both save and
>    restore).  It will be installed in /usr/lib/xen/bin.  It does not
>    link against libxl, only libxc, and its error handling does not
>    need to be very advanced.  It does contain a plumbing through of
>    the logging interface into the callback stream.
> 
>  * A small ad-hoc protocol between the helper and libxl which allows
>    log messages and the libxc callbacks to be passed up and down.
>    Protocol doc comment is in libxl_save_helper.c.
> 
>  * To avoid a lot of tedium the marshalling boilerplate (stubs for the
>    helper and the callback decoder for libxl) is generated with a
>    small perl script.
> 
>  * Implement new functionality to spawn the helper, monitor its
>    output, provide responses, and check on its exit status.
> 
>  * The functions libxl__xc_domain_restore_done and
>    libxl__xc_domain_save_done now turn out to want be called in the
>    same place.  So make their state argument a void* so that the two
>    functions are type compatible.
> 
> The domain save path still writes the qemu savefile synchronously.
> This will need to be fixed in a subsequent patch.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> -
> Changes in v6:
>  * The void* passed to the callback was being treated as a
>    libxl__domain_suspend_state* by the remus callbacks; this is a
>    holdover from a much earlier version of the series.  It is now
>    properly converted to a libxl__save_helper_state and then the dss
>    extracted with CONTAINER_OF.
>  * The way remus works means that the toolstack save callback is
>    invoked more than once, which the helper's implementation was not
>    prepared to deal with.  Fix this by moving the rewind of the fd
>    into the helper.
> 
> Changes in v5:
>  * assert that preserve_fds are >2.
> 
> Changes in v4:
>  * Migration stream fd is handled specially by the run_helper
>    function, rather than simply being a numarg.  Specifically:
>      - dup it to a safe fd number if necessary.
>      - clear cloexec flag fd before execing helper
>  * Toolstack data fd argument to run_helper replaced with
>    generic preserve_fds array, which get cloexec cleared.
>  * libxl__xc_domain_save uses supplied callback function pointer,
>    rather than calling libxl__toolstack_save directly;
>    toolstack data save callback is only supplied to libxc if
>    in-libxl caller supplied a callback.
>  * libxl-save-helper is not needlessly linked against libxl.
>  * Code which prepares pipes for helper clarified.
>  * Deal properly with, and log properly, POLLPRI/POLLERR on
>    pipe to save helper.
>  * Spelling fix in perl script comment.
>  * In message generator, use better names for the ends of serial
>    conditional here documents.
>  * Makefile does $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
> 
> Changes in v3:
>  * Suppress errno value in debug message when helper reports successful
>    completion.
>  * Significant consequential changes to cope with changes to
>    earlier patches in the series.
> 
> Changes in v2:
>  * Helper path can be overridden by an environment variable for testing.
>  * Add a couple of debug logging messages re toolstack data.
>  * Fixes from testing.
>  * Helper protocol message lengths (and numbers) are 16-bit which
>    more clearly avoids piling lots of junk on the stack.
>  * Merged with remus changes.
>  * Callback implementations in libxl now called via pointers
>    so remus can have its own callbacks.
>  * Better namespace prefixes on autogenerated names etc.
>  * Autogenerator can generate debugging printfs too.
> 
> ---
>  .gitignore                         |    1 +
>  .hgignore                          |    2 +
>  tools/libxl/Makefile               |   22 ++-
>  tools/libxl/libxl_create.c         |   22 ++-
>  tools/libxl/libxl_dom.c            |   42 +++--
>  tools/libxl/libxl_internal.h       |   56 +++++-
>  tools/libxl/libxl_save_callout.c   |  361 +++++++++++++++++++++++++++++++-
>  tools/libxl/libxl_save_helper.c    |  283 +++++++++++++++++++++++++
>  tools/libxl/libxl_save_msgs_gen.pl |  397 ++++++++++++++++++++++++++++++++++++
>  9 files changed, 1146 insertions(+), 40 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 7770e54..3451e52 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -353,6 +353,7 @@ 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
> diff --git a/.hgignore b/.hgignore
> index 27d8f79..05304ea 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -180,9 +180,11 @@
>  ^tools/libxl/_.*\.c$
>  ^tools/libxl/libxlu_cfg_y\.output$
>  ^tools/libxl/xl$
> +^tools/libxl/libxl-save-helper$
>  ^tools/libxl/testidl$
>  ^tools/libxl/testidl\.c$
>  ^tools/libxl/tmp\..*$
> +^tools/libxl/.*\.new$
>  ^tools/libvchan/vchan-node[12]$
>  ^tools/libaio/src/.*\.ol$
>  ^tools/libaio/src/.*\.os$
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 1d8b80a..ddc2624 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -67,25 +67,30 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
>                         libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
>                         libxl_internal.o libxl_utils.o libxl_uuid.o \
>                         libxl_json.o libxl_aoutils.o \
> -                       libxl_save_callout.o \
> +                       libxl_save_callout.o _libxl_save_msgs_callout.o \
>                         libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> 
>  $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl) -include $(XEN_ROOT)/tools/config.h
> 
> -AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h
> +AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
> +       _libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
>  AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
> +AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
>  LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
>         libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
>  $(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
> 
> -CLIENTS = xl testidl
> +CLIENTS = xl testidl libxl-save-helper
> 
>  XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
>  $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
>  $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
>  $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
> 
> +SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
> +$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
> +
>  testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
>  testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
>         $(PYTHON) gentest.py libxl_types.idl testidl.c.new
> @@ -117,6 +122,12 @@ _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE
>         perl $^ --prefix=libxl >$@.new
>         $(call move-if-changed,$@.new,$@)
> 
> +_libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
> +_libxl_save_msgs_helper.h _libxl_save_msgs_callout.h: \
> +               libxl_save_msgs_gen.pl
> +       $(PERL) -w $< $@ >$@.new
> +       $(call move-if-changed,$@.new,$@)
> +
>  libxl.h: _libxl_types.h
>  libxl_json.h: _libxl_types_json.h
>  libxl_internal.h: _libxl_types_internal.h _paths.h
> @@ -159,6 +170,9 @@ libxlutil.a: $(LIBXLU_OBJS)
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
> 
> +libxl-save-helper: $(SAVE_HELPER_OBJS) libxenlight.so
> +       $(CC) $(LDFLAGS) -o $@ $(SAVE_HELPER_OBJS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
> +
>  testidl: testidl.o libxlutil.so libxenlight.so
>         $(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> 
> @@ -169,7 +183,9 @@ install: all
>         $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
>         $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
>         $(INSTALL_DIR) $(DESTDIR)$(XEN_RUN_DIR)
> +       $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR)
>         $(INSTALL_PROG) xl $(DESTDIR)$(SBINDIR)
> +       $(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(PRIVATE_BINDIR)
>         $(INSTALL_PROG) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
>         ln -sf libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenlight.so.$(MAJOR)
>         ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 9c3c671..7b92539 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -662,7 +662,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>      libxl_domain_build_info *const info = &d_config->b_info;
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> -    struct restore_callbacks *const callbacks = &dcs->callbacks;
> +    libxl__srm_restore_autogen_callbacks *const callbacks =
> +        &dcs->shs.callbacks.restore.a;
> 
>      if (rc) domcreate_rebuild_done(egc, dcs, rc);
> 
> @@ -702,7 +703,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>          pae = libxl_defbool_val(info->u.hvm.pae);
>          no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
>          callbacks->toolstack_restore = libxl__toolstack_restore;
> -        callbacks->data = gc;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
> @@ -722,10 +722,24 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>      libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
>  }
> 
> -void libxl__xc_domain_restore_done(libxl__egc *egc,
> -                                   libxl__domain_create_state *dcs,
> +void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
> +          unsigned long console_mfn, unsigned long genidad, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
> +    STATE_AO_GC(dcs->ao);
> +    libxl__domain_build_state *const state = &dcs->build_state;
> +
> +    state->store_mfn =            store_mfn;
> +    state->console_mfn =          console_mfn;
> +    state->vm_generationid_addr = genidad;
> +    shs->need_results =           0;
> +}
> +
> +void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
>                                     int ret, int retval, int errnoval)
>  {
> +    libxl__domain_create_state *dcs = dcs_void;
>      STATE_AO_GC(dcs->ao);
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      char **vments = NULL, **localents = NULL;
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index c44dec0..0e0dbee 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -467,16 +467,20 @@ static inline char *restore_helper(libxl__gc *gc, uint32_t domid,
>  }
> 
>  int libxl__toolstack_restore(uint32_t domid, const uint8_t *buf,
> -        uint32_t size, void *data)
> +                             uint32_t size, void *user)
>  {
> -    libxl__gc *gc = data;
> -    libxl_ctx *ctx = gc->owner;
> +    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;
>      struct libxl__physmap_info* pi;
>      char *xs_path;
> 
> +    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
> +
>      if (size < sizeof(version) + sizeof(count)) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
>          return -1;
> @@ -529,9 +533,10 @@ static void domain_suspend_done(libxl__egc *egc,
>  /*----- callbacks, called by xc_domain_save -----*/
> 
>  int libxl__domain_suspend_common_switch_qemu_logdirty
> -                               (int domid, unsigned int enable, void *data)
> +                               (int domid, unsigned enable, void *user)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = user;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
>      char *path;
>      bool rc;
> @@ -597,9 +602,10 @@ int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
>      return 0;
>  }
> 
> -int libxl__domain_suspend_common_callback(void *data)
> +int libxl__domain_suspend_common_callback(void *user)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = user;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
>      unsigned long hvm_s_state = 0, hvm_pvdrv = 0;
>      int ret;
> @@ -739,9 +745,9 @@ static inline char *save_helper(libxl__gc *gc, uint32_t domid,
>  }
> 
>  int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> -        uint32_t *len, void *data)
> +        uint32_t *len, void *dss_void)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__domain_suspend_state *dss = dss_void;
>      STATE_AO_GC(dss->ao);
>      int i = 0;
>      char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
> @@ -810,6 +816,8 @@ int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
>          ptr += sizeof(struct libxl__physmap_info) + namelen;
>      }
> 
> +    LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, *len);
> +
>      return 0;
>  }
> 
> @@ -823,7 +831,8 @@ static int libxl__remus_domain_suspend_callback(void *data)
> 
>  static int libxl__remus_domain_resume_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
> 
>      /* Resumes the domain and the device model */
> @@ -836,7 +845,8 @@ static int libxl__remus_domain_resume_callback(void *data)
> 
>  static int libxl__remus_domain_checkpoint_callback(void *data)
>  {
> -    libxl__domain_suspend_state *dss = data;
> +    libxl__save_helper_state *shs = data;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      STATE_AO_GC(dss->ao);
> 
>      /* This would go into tailbuf. */
> @@ -864,7 +874,8 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>      const int live = dss->live;
>      const int debug = dss->debug;
>      const libxl_domain_remus_info *const r_info = dss->remus;
> -    struct save_callbacks *const callbacks = &dss->callbacks;
> +    libxl__srm_save_autogen_callbacks *const callbacks =
> +        &dss->shs.callbacks.save.a;
> 
>      switch (type) {
>      case LIBXL_DOMAIN_TYPE_HVM: {
> @@ -925,8 +936,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>          callbacks->suspend = libxl__domain_suspend_common_callback;
> 
>      callbacks->switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
> -    callbacks->toolstack_save = libxl__toolstack_save;
> -    callbacks->data = dss;
> +    dss->shs.callbacks.save.toolstack_save = libxl__toolstack_save;
> 
>      libxl__xc_domain_save(egc, dss, vm_generationid_addr);
>      return;
> @@ -935,10 +945,10 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
>      domain_suspend_done(egc, dss, rc);
>  }
> 
> -void libxl__xc_domain_save_done(libxl__egc *egc,
> -                                libxl__domain_suspend_state *dss,
> +void libxl__xc_domain_save_done(libxl__egc *egc, void *dss_void,
>                                  int rc, int retval, int errnoval)
>  {
> +    libxl__domain_suspend_state *dss = dss_void;
>      STATE_AO_GC(dss->ao);
> 
>      /* Convenience aliases */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 7cf1b04..1a7b526 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -54,6 +54,7 @@
> 
>  #include "libxl.h"
>  #include "_paths.h"
> +#include "_libxl_save_msgs_callout.h"
> 
>  #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
>  #define _hidden __attribute__((visibility("hidden")))
> @@ -1773,6 +1774,51 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc);
>  _hidden int libxl__datacopier_start(libxl__datacopier_state *dc);
> 
> 
> +/*----- Save/restore helper (used by creation and suspend) -----*/
> +
> +typedef struct libxl__srm_save_callbacks {
> +    libxl__srm_save_autogen_callbacks a;
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf,
> +                          uint32_t *len, void *data);
> +} libxl__srm_save_callbacks;
> +
> +typedef struct libxl__srm_restore_callbacks {
> +    libxl__srm_restore_autogen_callbacks a;
> +} libxl__srm_restore_callbacks;
> +
> +/* a pointer to this struct is also passed as "user" to the
> + * save callout helper callback functions */
> +typedef struct libxl__save_helper_state {
> +    /* public, caller of run_helper initialises */
> +    libxl__ao *ao;
> +    uint32_t domid;
> +    union {
> +        libxl__srm_save_callbacks save;
> +        libxl__srm_restore_callbacks restore;
> +    } callbacks;
> +    int (*recv_callback)(const unsigned char *msg, uint32_t len, void *user);
> +    void (*completion_callback)(libxl__egc *egc, void *caller_state,
> +                                int rc, int retval, int errnoval);
> +    void *caller_state;
> +    int need_results; /* set to 0 or 1 by caller of run_helper;
> +                       * if set to 1 then the ultimate caller's
> +                       * results function must set it to 0 */
> +    /* private */
> +    int rc;
> +    int completed; /* retval/errnoval valid iff completed */
> +    int retval, errnoval; /* from xc_domain_save / xc_domain_restore */
> +    libxl__carefd *pipes[2]; /* 0 = helper's stdin, 1 = helper's stdout */
> +    libxl__ev_fd readable;
> +    libxl__ev_child child;
> +    const char *stdin_what, *stdout_what;
> +    FILE *toolstack_data_file;
> +
> +    libxl__egc *egc; /* valid only for duration of each event callback;
> +                      * is here in this struct for the benefit of the
> +                      * marshalling and xc callback functions */
> +} libxl__save_helper_state;
> +
> +
>  /*----- Domain suspend (save) state structure -----*/
> 
>  typedef struct libxl__domain_suspend_state libxl__domain_suspend_state;
> @@ -1798,7 +1844,7 @@ struct libxl__domain_suspend_state {
>      int xcflags;
>      int guest_responded;
>      int interval; /* checkpoint interval (for Remus) */
> -    struct save_callbacks callbacks;
> +    libxl__save_helper_state shs;
>  };
> 
> 
> @@ -1910,7 +1956,7 @@ struct libxl__domain_create_state {
>      libxl__stub_dm_spawn_state dmss;
>          /* If we're not doing stubdom, we use only dmss.dm,
>           * for the non-stubdom device model. */
> -    struct restore_callbacks callbacks;
> +    libxl__save_helper_state shs;
>  };
> 
>  /*----- Domain suspend (save) functions -----*/
> @@ -1926,8 +1972,7 @@ _hidden void libxl__xc_domain_save(libxl__egc*, libxl__domain_suspend_state*,
>  /* If rc==0 then retval is the return value from xc_domain_save
>   * and errnoval is the errno value it provided.
>   * If rc!=0, retval and errnoval are undefined. */
> -_hidden void libxl__xc_domain_save_done(libxl__egc*,
> -                                        libxl__domain_suspend_state*,
> +_hidden void libxl__xc_domain_save_done(libxl__egc*, void *dss_void,
>                                          int rc, int retval, int errnoval);
> 
>  _hidden int libxl__domain_suspend_common_callback(void *data);
> @@ -1945,8 +1990,7 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
>  /* If rc==0 then retval is the return value from xc_domain_save
>   * and errnoval is the errno value it provided.
>   * If rc!=0, retval and errnoval are undefined. */
> -_hidden void libxl__xc_domain_restore_done(libxl__egc *egc,
> -                                           libxl__domain_create_state *dcs,
> +_hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
>                                             int rc, int retval, int errnoval);
> 
> 
> diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
> index 1b481ab..a6abcda 100644
> --- a/tools/libxl/libxl_save_callout.c
> +++ b/tools/libxl/libxl_save_callout.c
> @@ -16,6 +16,30 @@
> 
>  #include "libxl_internal.h"
> 
> +/* stream_fd is as from the caller (eventually, the application).
> + * It may be 0, 1 or 2, in which case we need to dup it elsewhere.
> + * The actual fd value is not included in the supplied argnums; rather
> + * it will be automatically supplied by run_helper as the 2nd argument.
> + *
> + * preserve_fds are fds that the caller is intending to pass to the
> + * helper so which need cloexec clearing.  They may not be 0, 1 or 2.
> + * An entry may be -1 in which case it will be ignored.
> + */
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg,
> +                       int stream_fd,
> +                       const int *preserve_fds, int num_preserve_fds,
> +                       const unsigned long *argnums, int num_argnums);
> +
> +static void helper_failed(libxl__egc*, libxl__save_helper_state *shs, int rc);
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status);
> +static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs);
> +
> +/*----- entrypoints -----*/
> +
>  void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>                                int hvm, int pae, int superpages,
>                                int no_incr_generationid)
> @@ -27,22 +51,337 @@ void libxl__xc_domain_restore(libxl__egc *egc, libxl__domain_create_state *dcs,
>      const int restore_fd = dcs->restore_fd;
>      libxl__domain_build_state *const state = &dcs->build_state;
> 
> -    int r = xc_domain_restore(CTX->xch, restore_fd, domid,
> -                              state->store_port, &state->store_mfn,
> -                              state->store_domid, state->console_port,
> -                              &state->console_mfn, state->console_domid,
> -                              hvm, pae, superpages, no_incr_generationid,
> -                              &state->vm_generationid_addr, &dcs->callbacks);
> -    libxl__xc_domain_restore_done(egc, dcs, 0, r, errno);
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_restore
> +        (&dcs->shs.callbacks.restore.a);
> +
> +    const unsigned long argnums[] = {
> +        domid,
> +        state->store_port,
> +        state->store_domid, state->console_port,
> +        state->console_domid,
> +        hvm, pae, superpages, no_incr_generationid,
> +        cbflags,
> +    };
> +
> +    dcs->shs.ao = ao;
> +    dcs->shs.domid = domid;
> +    dcs->shs.recv_callback = libxl__srm_callout_received_restore;
> +    dcs->shs.completion_callback = libxl__xc_domain_restore_done;
> +    dcs->shs.caller_state = dcs;
> +    dcs->shs.need_results = 1;
> +    dcs->shs.toolstack_data_file = 0;
> +
> +    run_helper(egc, &dcs->shs, "--restore-domain", restore_fd, 0,0,
> +               argnums, ARRAY_SIZE(argnums));
>  }
> 
>  void libxl__xc_domain_save(libxl__egc *egc, libxl__domain_suspend_state *dss,
>                             unsigned long vm_generationid_addr)
>  {
>      STATE_AO_GC(dss->ao);
> -    int r;
> +    int r, rc, toolstack_data_fd = -1;
> +    uint32_t toolstack_data_len = 0;
> +
> +    /* Resources we need to free */
> +    uint8_t *toolstack_data_buf = 0;
> +
> +    unsigned cbflags = libxl__srm_callout_enumcallbacks_save
> +        (&dss->shs.callbacks.save.a);
> +
> +    if (dss->shs.callbacks.save.toolstack_save) {
> +        r = dss->shs.callbacks.save.toolstack_save
> +            (dss->domid, &toolstack_data_buf, &toolstack_data_len, dss);
> +        if (r) { rc = ERROR_FAIL; goto out; }
> +
> +        dss->shs.toolstack_data_file = tmpfile();
> +        if (!dss->shs.toolstack_data_file) {
> +            LOGE(ERROR, "cannot create toolstack data tmpfile");
> +            rc = ERROR_FAIL;
> +            goto out;
> +        }
> +        toolstack_data_fd = fileno(dss->shs.toolstack_data_file);
> +
> +        r = libxl_write_exactly(CTX, toolstack_data_fd,
> +                                toolstack_data_buf, toolstack_data_len,
> +                                "toolstack data tmpfile", 0);
> +        if (r) { rc = ERROR_FAIL; goto out; }
> +    }
> +
> +    const unsigned long argnums[] = {
> +        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
> +        toolstack_data_fd, toolstack_data_len,
> +        cbflags,
> +    };
> +
> +    dss->shs.ao = ao;
> +    dss->shs.domid = dss->domid;
> +    dss->shs.recv_callback = libxl__srm_callout_received_save;
> +    dss->shs.completion_callback = libxl__xc_domain_save_done;
> +    dss->shs.caller_state = dss;
> +    dss->shs.need_results = 0;
> +
> +    free(toolstack_data_buf);
> +
> +    run_helper(egc, &dss->shs, "--save-domain", dss->fd,
> +               &toolstack_data_fd, 1,
> +               argnums, ARRAY_SIZE(argnums));
> +    return;
> +
> + out:
> +    free(toolstack_data_buf);
> +    if (dss->shs.toolstack_data_file) fclose(dss->shs.toolstack_data_file);
> +
> +    libxl__xc_domain_save_done(egc, dss, rc, 0, 0);
> +}
> +
> +
> +/*----- helper execution -----*/
> +
> +static void run_helper(libxl__egc *egc, libxl__save_helper_state *shs,
> +                       const char *mode_arg, int stream_fd,
> +                       const int *preserve_fds, int num_preserve_fds,
> +                       const unsigned long *argnums, int num_argnums)
> +{
> +    STATE_AO_GC(shs->ao);
> +    const char *args[4 + num_argnums];
> +    const char **arg = args;
> +    int i, rc;
> +
> +    /* Resources we must free */
> +    libxl__carefd *childs_pipes[2] = { 0,0 };
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    shs->rc = 0;
> +    shs->completed = 0;
> +    shs->pipes[0] = shs->pipes[1] = 0;
> +    libxl__ev_fd_init(&shs->readable);
> +    libxl__ev_child_init(&shs->child);
> +
> +    shs->stdin_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                " stdin pipe", domid);
> +    shs->stdout_what = GCSPRINTF("domain %"PRIu32" save/restore helper"
> +                                 " stdout pipe", domid);
> +
> +    *arg++ = getenv("LIBXL_SAVE_HELPER") ?: LIBEXEC "/" "libxl-save-helper";
> +    *arg++ = mode_arg;
> +    const char **stream_fd_arg = arg++;
> +    for (i=0; i<num_argnums; i++)
> +        *arg++ = GCSPRINTF("%lu", argnums[i]);
> +    *arg++ = 0;
> +    assert(arg == args + ARRAY_SIZE(args));
> +
> +    libxl__carefd_begin();
> +    int childfd;
> +    for (childfd=0; childfd<2; childfd++) {
> +        /* Setting up the pipe for the child's fd childfd */
> +        int fds[2];
> +        if (libxl_pipe(CTX,fds)) { rc = ERROR_FAIL; goto out; }
> +        int childs_end = childfd==0 ? 0 /*read*/  : 1 /*write*/;
> +        int our_end    = childfd==0 ? 1 /*write*/ : 0 /*read*/;
> +        childs_pipes[childfd] = libxl__carefd_record(CTX, fds[childs_end]);
> +        shs->pipes[childfd] =   libxl__carefd_record(CTX, fds[our_end]);
> +    }
> +    libxl__carefd_unlock();
> +
> +    pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
> +    if (!pid) {
> +        if (stream_fd <= 2) {
> +            stream_fd = dup(stream_fd);
> +            if (stream_fd < 0) {
> +                LOGE(ERROR,"dup migration stream fd");
> +                exit(-1);
> +            }
> +        }
> +        libxl_fd_set_cloexec(CTX, stream_fd, 0);
> +        *stream_fd_arg = GCSPRINTF("%d", stream_fd);
> +
> +        for (i=0; i<num_preserve_fds; i++)
> +            if (preserve_fds[i] >= 0) {
> +                assert(preserve_fds[i] > 2);
> +                libxl_fd_set_cloexec(CTX, preserve_fds[i], 0);
> +            }
> +
> +        libxl__exec(gc,
> +                    libxl__carefd_fd(childs_pipes[0]),
> +                    libxl__carefd_fd(childs_pipes[1]),
> +                    -1,
> +                    args[0], (char**)args, 0);
> +    }
> +
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +
> +    rc = libxl__ev_fd_register(gc, &shs->readable, helper_stdout_readable,
> +                               libxl__carefd_fd(shs->pipes[1]), POLLIN|POLLPRI);
> +    if (rc) goto out;
> +    return;
> +
> + out:
> +    libxl__carefd_close(childs_pipes[0]);
> +    libxl__carefd_close(childs_pipes[1]);
> +    helper_failed(egc, shs, rc);;
> +}
> +
> +static void helper_failed(libxl__egc *egc, libxl__save_helper_state *shs,
> +                          int rc)
> +{
> +    STATE_AO_GC(shs->ao);
> +
> +    if (!shs->rc)
> +        shs->rc = rc;
> +
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +
> +    if (!libxl__ev_child_inuse(&shs->child)) {
> +        helper_done(egc, shs);
> +        return;
> +    }
> +
> +    int r = kill(shs->child.pid, SIGKILL);
> +    if (r) LOGE(WARN, "failed to kill save/restore helper [%lu]",
> +                (unsigned long)shs->child.pid);
> +}
> +
> +static void helper_stdout_readable(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ev, *shs, readable);
> +    STATE_AO_GC(shs->ao);
> +    int rc, errnoval;
> +
> +    if (revents & (POLLERR|POLLPRI)) {
> +        LOG(ERROR, "%s signaled POLLERR|POLLPRI (%#x)",
> +            shs->stdout_what, revents);
> +        rc = ERROR_FAIL;
> + out:
> +        /* this is here because otherwise we bypass the decl of msg[] */
> +        helper_failed(egc, shs, rc);
> +        return;
> +    }
> +
> +    uint16_t msglen;
> +    errnoval = libxl_read_exactly(CTX, fd, &msglen, sizeof(msglen),
> +                                  shs->stdout_what, "ipc msg header");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    unsigned char msg[msglen];
> +    errnoval = libxl_read_exactly(CTX, fd, msg, msglen,
> +                                  shs->stdout_what, "ipc msg body");
> +    if (errnoval) { rc = ERROR_FAIL; goto out; }
> +
> +    shs->egc = egc;
> +    shs->recv_callback(msg, msglen, shs);
> +    shs->egc = 0;
> +    return;
> +}
> +
> +static void helper_exited(libxl__egc *egc, libxl__ev_child *ch,
> +                          pid_t pid, int status)
> +{
> +    libxl__save_helper_state *shs = CONTAINER_OF(ch, *shs, child);
> +    STATE_AO_GC(shs->ao);
> +
> +    /* Convenience aliases */
> +    const uint32_t domid = shs->domid;
> +
> +    const char *what =
> +        GCSPRINTF("domain %"PRIu32" save/restore helper", domid);
> +
> +    if (status) {
> +        libxl_report_child_exitstatus(CTX, XTL_ERROR, what, pid, status);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (shs->need_results) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without providing results",what);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    if (!shs->completed) {
> +        if (!shs->rc)
> +            LOG(ERROR,"%s exited without signaling completion",what);
> +        shs->rc = ERROR_FAIL;
> +    }
> +
> +    helper_done(egc, shs);
> +    return;
> +}
> +
> +static void helper_done(libxl__egc *egc, libxl__save_helper_state *shs)
> +{
> +    STATE_AO_GC(shs->ao);
> +
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +    libxl__carefd_close(shs->pipes[0]);  shs->pipes[0] = 0;
> +    libxl__carefd_close(shs->pipes[1]);  shs->pipes[1] = 0;
> +    assert(!libxl__ev_child_inuse(&shs->child));
> +    if (shs->toolstack_data_file) fclose(shs->toolstack_data_file);
> +
> +    shs->egc = egc;
> +    shs->completion_callback(egc, shs->caller_state,
> +                             shs->rc, shs->retval, shs->errnoval);
> +    shs->egc = 0;
> +}
> +
> +/*----- generic helpers for the autogenerated code -----*/
> +
> +const libxl__srm_save_autogen_callbacks*
> +libxl__srm_callout_get_callbacks_save(void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    return &shs->callbacks.save.a;
> +}
> +
> +const libxl__srm_restore_autogen_callbacks*
> +libxl__srm_callout_get_callbacks_restore(void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    return &shs->callbacks.restore.a;
> +}
> +
> +void libxl__srm_callout_sendreply(int r, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    libxl__egc *egc = shs->egc;
> +    STATE_AO_GC(shs->ao);
> +    int errnoval;
> +
> +    errnoval = libxl_write_exactly(CTX, libxl__carefd_fd(shs->pipes[0]),
> +                                   &r, sizeof(r), shs->stdin_what,
> +                                   "callback return value");
> +    if (errnoval)
> +        helper_failed(egc, shs, ERROR_FAIL);
> +}
> +
> +void libxl__srm_callout_callback_log(uint32_t level, uint32_t errnoval,
> +                  const char *context, const char *formatted, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    STATE_AO_GC(shs->ao);
> +    xtl_log(CTX->lg, level, errnoval, context, "%s", formatted);
> +}
> +
> +void libxl__srm_callout_callback_progress(const char *context,
> +                   const char *doing_what, unsigned long done,
> +                   unsigned long total, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    STATE_AO_GC(shs->ao);
> +    xtl_progress(CTX->lg, context, doing_what, done, total);
> +}
> +
> +int libxl__srm_callout_callback_complete(int retval, int errnoval,
> +                                         void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    STATE_AO_GC(shs->ao);
> 
> -    r = xc_domain_save(CTX->xch, dss->fd, dss->domid, 0, 0, dss->xcflags,
> -                       &dss->callbacks, dss->hvm, vm_generationid_addr);
> -    libxl__xc_domain_save_done(egc, dss, 0, r, errno);
> +    shs->completed = 1;
> +    shs->retval = retval;
> +    shs->errnoval = errnoval;
> +    libxl__ev_fd_deregister(gc, &shs->readable);
> +    return 0;
>  }
> diff --git a/tools/libxl/libxl_save_helper.c b/tools/libxl/libxl_save_helper.c
> new file mode 100644
> index 0000000..772251a
> --- /dev/null
> +++ b/tools/libxl/libxl_save_helper.c
> @@ -0,0 +1,283 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +/*
> + * The libxl-save-helper utility speaks a protocol to its caller for
> + * the callbacks.  The protocol is as follows.
> + *
> + * The helper talks on stdin and stdout, in binary in machine
> + * endianness.  The helper speaks first, and only when it has a
> + * callback to make.  It writes a 16-bit number being the message
> + * length, and then the message body.
> + *
> + * Each message starts with a 16-bit number indicating which of the
> + * messages it is, and then some arguments in a binary marshalled form.
> + * If the callback does not need a reply (it returns void), the helper
> + * just continues.  Otherwise the helper waits for its caller to send a
> + * single int which is to be the return value from the callback.
> + *
> + * Where feasible the stubs and callbacks have prototypes identical to
> + * those required by xc_domain_save and xc_domain_restore, so that the
> + * autogenerated functions can be used/provided directly.
> + *
> + * The actual messages are in the array @msgs in libxl_save_msgs_gen.pl
> + */
> +
> +#include "libxl_osdeps.h"
> +
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <assert.h>
> +#include <inttypes.h>
> +
> +#include "libxl.h"
> +
> +#include "xenctrl.h"
> +#include "xenguest.h"
> +#include "_libxl_save_msgs_helper.h"
> +
> +/*----- globals -----*/
> +
> +static const char *program = "libxl-save-helper";
> +static xentoollog_logger *logger;
> +static xc_interface *xch;
> +
> +/*----- error handling -----*/
> +
> +static void fail(int errnoval, const char *fmt, ...)
> +    __attribute__((noreturn,format(printf,2,3)));
> +static void fail(int errnoval, const char *fmt, ...)
> +{
> +    va_list al;
> +    va_start(al,fmt);
> +    xtl_logv(logger,XTL_ERROR,errnoval,program,fmt,al);
> +    exit(-1);
> +}
> +
> +static int read_exactly(int fd, void *buf, size_t len)
> +/* returns 0 if we get eof, even if we got it midway through; 1 if ok */
> +{
> +    while (len) {
> +        ssize_t r = read(fd, buf, len);
> +        if (r<=0) return r;
> +        assert(r <= len);
> +        len -= r;
> +        buf = (char*)buf + r;
> +    }
> +    return 1;
> +}
> +
> +static void *xmalloc(size_t sz)
> +{
> +    if (!sz) return 0;
> +    void *r = malloc(sz);
> +    if (!r) { perror("memory allocation failed"); exit(-1); }
> +    return r;
> +}
> +
> +/*----- logger -----*/
> +
> +typedef struct {
> +    xentoollog_logger vtable;
> +} xentoollog_logger_tellparent;
> +
> +static void tellparent_vmessage(xentoollog_logger *logger_in,
> +                                xentoollog_level level,
> +                                int errnoval,
> +                                const char *context,
> +                                const char *format,
> +                                va_list al)
> +{
> +    char *formatted;
> +    int r = vasprintf(&formatted, format, al);
> +    if (r < 0) { perror("memory allocation failed during logging"); exit(-1); }
> +    helper_stub_log(level, errnoval, context, formatted, 0);
> +    free(formatted);
> +}
> +
> +static void tellparent_progress(struct xentoollog_logger *logger_in,
> +                                const char *context,
> +                                const char *doing_what, int percent,
> +                                unsigned long done, unsigned long total)
> +{
> +    helper_stub_progress(context, doing_what, done, total, 0);
> +}
> +
> +static void tellparent_destroy(struct xentoollog_logger *logger_in)
> +{
> +    abort();
> +}
> +
> +static xentoollog_logger_tellparent *createlogger_tellparent(void)
> +{
> +    xentoollog_logger_tellparent newlogger;
> +    return XTL_NEW_LOGGER(tellparent, newlogger);
> +}
> +
> +/*----- helper functions called by autogenerated stubs -----*/
> +
> +unsigned char * helper_allocbuf(int len, void *user)
> +{
> +    return xmalloc(len);
> +}
> +
> +static void transmit(const unsigned char *msg, int len, void *user)
> +{
> +    while (len) {
> +        int r = write(1, msg, len);
> +        if (r<0) { perror("write"); exit(-1); }
> +        assert(r >= 0);
> +        assert(r <= len);
> +        len -= r;
> +        msg += r;
> +    }
> +}
> +
> +void helper_transmitmsg(unsigned char *msg_freed, int len_in, void *user)
> +{
> +    assert(len_in < 64*1024);
> +    uint16_t len = len_in;
> +    transmit((const void*)&len, sizeof(len), user);
> +    transmit(msg_freed, len, user);
> +    free(msg_freed);
> +}
> +
> +int helper_getreply(void *user)
> +{
> +    int v;
> +    int r = read_exactly(0, &v, sizeof(v));
> +    if (r<=0) exit(-2);
> +    return v;
> +}
> +
> +/*----- other callbacks -----*/
> +
> +static int toolstack_save_fd;
> +static uint32_t toolstack_save_len;
> +
> +static int toolstack_save_cb(uint32_t domid, uint8_t **buf,
> +                             uint32_t *len, void *data)
> +{
> +    assert(toolstack_save_fd > 0);
> +
> +    int r = lseek(toolstack_save_fd, 0, SEEK_SET);
> +    if (r) fail(errno,"rewind toolstack data tmpfile");
> +
> +    *buf = xmalloc(toolstack_save_len);
> +    r = read_exactly(toolstack_save_fd, *buf, toolstack_save_len);
> +    if (r<0) fail(errno,"read toolstack data");
> +    if (r==0) fail(0,"read toolstack data eof");
> +
> +    *len = toolstack_save_len;
> +    return 0;
> +}
> +
> +static void startup(const char *op) {
> +    logger = (xentoollog_logger*)createlogger_tellparent();
> +    if (!logger) {
> +        fprintf(stderr, "%s: cannot initialise logger\n", program);
> +        exit(-1);
> +    }
> +
> +    xtl_log(logger,XTL_DEBUG,0,program,"starting %s",op);
> +
> +    xch = xc_interface_open(logger,logger,0);
> +    if (!xch) fail(errno,"xc_interface_open failed");
> +}
> +
> +static void complete(int retval) {
> +    int errnoval = retval ? errno : 0; /* suppress irrelevant errnos */
> +    xtl_log(logger,XTL_DEBUG,errnoval,program,"complete r=%d",retval);
> +    helper_stub_complete(retval,errnoval,0);
> +    exit(0);
> +}
> +
> +static struct save_callbacks helper_save_callbacks;
> +static struct restore_callbacks helper_restore_callbacks;
> +
> +int main(int argc, char **argv)
> +{
> +    int r;
> +
> +#define NEXTARG (++argv, assert(*argv), *argv)
> +
> +    const char *mode = *++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);
> +        assert(!*++argv);
> +
> +        if (toolstack_save_fd >= 0)
> +            helper_save_callbacks.toolstack_save = toolstack_save_cb;
> +
> +        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);
> +        complete(r);
> +
> +    } else if (!strcmp(mode,"--restore-domain")) {
> +
> +        int io_fd =                atoi(NEXTARG);
> +        uint32_t dom =             strtoul(NEXTARG,0,10);
> +        unsigned store_evtchn =    strtoul(NEXTARG,0,10);
> +        domid_t store_domid =      strtoul(NEXTARG,0,10);
> +        unsigned console_evtchn =  strtoul(NEXTARG,0,10);
> +        domid_t console_domid =    strtoul(NEXTARG,0,10);
> +        unsigned int hvm =         strtoul(NEXTARG,0,10);
> +        unsigned int pae =         strtoul(NEXTARG,0,10);
> +        int superpages =           strtoul(NEXTARG,0,10);
> +        int no_incr_genidad =      strtoul(NEXTARG,0,10);
> +        unsigned cbflags =         strtoul(NEXTARG,0,10);
> +        assert(!*++argv);
> +
> +        helper_setcallbacks_restore(&helper_restore_callbacks, cbflags);
> +
> +        unsigned long store_mfn = 0;
> +        unsigned long console_mfn = 0;
> +        unsigned long genidad = 0;
> +
> +        startup("restore");
> +        r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
> +                              store_domid, console_evtchn, &console_mfn,
> +                              console_domid, hvm, pae, superpages,
> +                              no_incr_genidad, &genidad,
> +                              &helper_restore_callbacks);
> +        helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
> +        complete(r);
> +
> +    } else {
> +        assert(!"unexpected mode argument");
> +    }
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_save_msgs_gen.pl b/tools/libxl/libxl_save_msgs_gen.pl
> new file mode 100755
> index 0000000..c45986e
> --- /dev/null
> +++ b/tools/libxl/libxl_save_msgs_gen.pl
> @@ -0,0 +1,397 @@
> +#!/usr/bin/perl -w
> +
> +use warnings;
> +use strict;
> +use POSIX;
> +
> +our $debug = 0; # produce copious debugging output at run-time?
> +
> +our @msgs = (
> +    # flags:
> +    #   s  - applicable to save
> +    #   r  - applicable to restore
> +    #   c  - function pointer in callbacks struct rather than fixed function
> +    #   x  - function pointer is in struct {save,restore}_callbacks
> +    #         and its null-ness needs to be passed through to the helper's xc
> +    #   W  - needs a return value; callback is synchronous
> +    [  1, 'sr',     "log",                   [qw(uint32_t level
> +                                                 uint32_t errnoval
> +                                                 STRING context
> +                                                 STRING formatted)] ],
> +    [  2, 'sr',     "progress",              [qw(STRING context
> +                                                 STRING doing_what),
> +                                                'unsigned long', 'done',
> +                                                'unsigned long', 'total'] ],
> +    [  3, 'scxW',   "suspend", [] ],
> +    [  4, 'scxW',   "postcopy", [] ],
> +    [  5, 'scxW',   "checkpoint", [] ],
> +    [  6, 'scxW',   "switch_qemu_logdirty",  [qw(int domid
> +                                              unsigned enable)] ],
> +    #                toolstack_save          done entirely `by hand'
> +    [  7, 'rcxW',   "toolstack_restore",     [qw(uint32_t domid
> +                                                BLOCK tsdata)] ],
> +    [  8, 'r',      "restore_results",       ['unsigned long', 'store_mfn',
> +                                              'unsigned long', 'console_mfn',
> +                                              'unsigned long', 'genidad'] ],
> +    [  9, 'srW',    "complete",              [qw(int retval
> +                                                 int errnoval)] ],
> +);
> +
> +#----------------------------------------
> +
> +our %cbs;
> +our %func;
> +our %func_ah;
> +our @outfuncs;
> +our %out_decls;
> +our %out_body;
> +our %msgnum_used;
> +
> +die unless @ARGV==1;
> +die if $ARGV[0] =~ m/^-/;
> +
> +our ($intendedout) = @ARGV;
> +
> +$intendedout =~ m/([a-z]+)\.([ch])$/ or die;
> +my ($want_ah, $ch) = ($1, $2);
> +
> +my $declprefix = '';
> +
> +foreach my $ah (qw(callout helper)) {
> +    $out_body{$ah} .=
> +        <<END_BOTH.($ah eq 'callout' ? <<END_CALLOUT : <<END_HELPER);
> +#include "libxl_osdeps.h"
> +
> +#include <assert.h>
> +#include <string.h>
> +#include <stdint.h>
> +#include <limits.h>
> +END_BOTH
> +
> +#include "libxl_internal.h"
> +
> +END_CALLOUT
> +
> +#include "_libxl_save_msgs_${ah}.h"
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +END_HELPER
> +}
> +
> +die $want_ah unless defined $out_body{$want_ah};
> +
> +sub f_decl ($$$$) {
> +    my ($name, $ah, $c_rtype, $c_decl) = @_;
> +    $out_decls{$name} = "${declprefix}$c_rtype $name$c_decl;\n";
> +    $func{$name} = "$c_rtype $name$c_decl\n{\n" . ($func{$name} || '');
> +    $func_ah{$name} = $ah;
> +}
> +
> +sub f_more ($$) {
> +    my ($name, $addbody) = @_;
> +    $func{$name} ||= '';
> +    $func{$name} .= $addbody;
> +    push @outfuncs, $name;
> +}
> +
> +our $libxl = "libxl__srm";
> +our $callback = "${libxl}_callout_callback";
> +our $receiveds = "${libxl}_callout_received";
> +our $sendreply = "${libxl}_callout_sendreply";
> +our $getcallbacks = "${libxl}_callout_get_callbacks";
> +our $enumcallbacks = "${libxl}_callout_enumcallbacks";
> +sub cbtype ($) { "${libxl}_".$_[0]."_autogen_callbacks"; };
> +
> +f_decl($sendreply, 'callout', 'void', "(int r, void *user)");
> +
> +our $helper = "helper";
> +our $encode = "${helper}_stub";
> +our $allocbuf = "${helper}_allocbuf";
> +our $transmit = "${helper}_transmitmsg";
> +our $getreply = "${helper}_getreply";
> +our $setcallbacks = "${helper}_setcallbacks";
> +
> +f_decl($allocbuf, 'helper', 'unsigned char *', '(int len, void *user)');
> +f_decl($transmit, 'helper', 'void',
> +       '(unsigned char *msg_freed, int len, void *user)');
> +f_decl($getreply, 'helper', 'int', '(void *user)');
> +
> +sub typeid ($) { my ($t) = @_; $t =~ s/\W/_/; return $t; };
> +
> +$out_body{'callout'} .= <<END;
> +static int bytes_get(const unsigned char **msg,
> +                    const unsigned char *const endmsg,
> +                    void *result, int rlen)
> +{
> +    if (endmsg - *msg < rlen) return 0;
> +    memcpy(result,*msg,rlen);
> +    *msg += rlen;
> +    return 1;
> +}
> +
> +END
> +$out_body{'helper'} .= <<END;
> +static void bytes_put(unsigned char *const buf, int *len,
> +                     const void *value, int vlen)
> +{
> +    assert(vlen < INT_MAX/2 - *len);
> +    if (buf)
> +       memcpy(buf + *len, value, vlen);
> +    *len += vlen;
> +}
> +
> +END
> +
> +foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
> +    my $typeid = typeid($simpletype);
> +    $out_body{'callout'} .= <<END;
> +static int ${typeid}_get(const unsigned char **msg,
> +                        const unsigned char *const endmsg,
> +                        $simpletype *result)
> +{
> +    return bytes_get(msg, endmsg, result, sizeof(*result));
> +}
> +
> +END
> +    $out_body{'helper'} .= <<END;
> +static void ${typeid}_put(unsigned char *const buf, int *len,
> +                        const $simpletype value)
> +{
> +    bytes_put(buf, len, &value, sizeof(value));
> +}
> +
> +END
> +}
> +
> +$out_body{'callout'} .= <<END;
> +static int BLOCK_get(const unsigned char **msg,
> +                      const unsigned char *const endmsg,
> +                      const uint8_t **result, uint32_t *result_size)
> +{
> +    if (!uint32_t_get(msg,endmsg,result_size)) return 0;
> +    if (endmsg - *msg < *result_size) return 0;
> +    *result = (const void*)*msg;
> +    *msg += *result_size;
> +    return 1;
> +}
> +
> +static int STRING_get(const unsigned char **msg,
> +                      const unsigned char *const endmsg,
> +                      const char **result)
> +{
> +    const uint8_t *data;
> +    uint32_t datalen;
> +    if (!BLOCK_get(msg,endmsg,&data,&datalen)) return 0;
> +    if (datalen == 0) return 0;
> +    if (data[datalen-1] != '\\0') return 0;
> +    *result = (const void*)data;
> +    return 1;
> +}
> +
> +END
> +$out_body{'helper'} .= <<END;
> +static void BLOCK_put(unsigned char *const buf,
> +                      int *len,
> +                     const uint8_t *bytes, uint32_t size)
> +{
> +    uint32_t_put(buf, len, size);
> +    bytes_put(buf, len, bytes, size);
> +}
> +
> +static void STRING_put(unsigned char *const buf,
> +                      int *len,
> +                      const char *string)
> +{
> +    size_t slen = strlen(string);
> +    assert(slen < INT_MAX / 4);
> +    assert(slen < (uint32_t)0x40000000);
> +    BLOCK_put(buf, len, (const void*)string, slen+1);
> +}
> +
> +END
> +
> +foreach my $sr (qw(save restore)) {
> +    f_decl("${getcallbacks}_${sr}", 'callout',
> +           "const ".cbtype($sr)." *",
> +           "(void *data)");
> +
> +    f_decl("${receiveds}_${sr}", 'callout', 'int',
> +          "(const unsigned char *msg, uint32_t len, void *user)");
> +
> +    f_decl("${enumcallbacks}_${sr}", 'callout', 'unsigned',
> +           "(const ".cbtype($sr)." *cbs)");
> +    f_more("${enumcallbacks}_${sr}", "    unsigned cbflags = 0;\n");
> +
> +    f_decl("${setcallbacks}_${sr}", 'helper', 'void',
> +           "(struct ${sr}_callbacks *cbs, unsigned cbflags)");
> +
> +    f_more("${receiveds}_${sr}",
> +           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
> +    const unsigned char *const endmsg = msg + len;
> +    uint16_t mtype;
> +    if (!uint16_t_get(&msg,endmsg,&mtype)) return 0;
> +END_ALWAYS
> +    fprintf(stderr,"libxl callout receiver: got len=%u mtype=%u\\n",len,mtype);
> +END_DEBUG
> +    switch (mtype) {
> +
> +END_ALWAYS
> +
> +    $cbs{$sr} = "typedef struct ".cbtype($sr)." {\n";
> +}
> +
> +foreach my $msginfo (@msgs) {
> +    my ($msgnum, $flags, $name, $args) = @$msginfo;
> +    die if $msgnum_used{$msgnum}++;
> +
> +    my $f_more_sr = sub {
> +        my ($contents_spec, $fnamebase) = @_;
> +        $fnamebase ||= "${receiveds}";
> +        foreach my $sr (qw(save restore)) {
> +            $sr =~ m/^./;
> +            next unless $flags =~ m/$&/;
> +            my $contents = (!ref $contents_spec) ? $contents_spec :
> +                $contents_spec->($sr);
> +            f_more("${fnamebase}_${sr}", $contents);
> +        }
> +    };
> +
> +    $f_more_sr->("    case $msgnum: { /* $name */\n");
> +    if ($flags =~ m/W/) {
> +        $f_more_sr->("        int r;\n");
> +    }
> +
> +    my $c_rtype_helper = $flags =~ m/W/ ? 'int' : 'void';
> +    my $c_rtype_callout = $flags =~ m/W/ ? 'int' : 'void';
> +    my $c_decl = '(';
> +    my $c_callback_args = '';
> +
> +    f_more("${encode}_$name",
> +           <<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS);
> +    unsigned char *buf = 0;
> +    int len = 0, allocd = 0;
> +
> +END_ALWAYS
> +    fprintf(stderr,"libxl-save-helper: encoding $name\\n");
> +END_DEBUG
> +    for (;;) {
> +        uint16_t_put(buf, &len, $msgnum /* $name */);
> +END_ALWAYS
> +
> +    my @args = @$args;
> +    my $c_recv = '';
> +    my ($argtype, $arg);
> +    while (($argtype, $arg, @args) = @args) {
> +       my $typeid = typeid($argtype);
> +        my $c_args = "$arg";
> +        my $c_get_args = "&$arg";
> +       if ($argtype eq 'STRING') {
> +           $c_decl .= "const char *$arg, ";
> +           $f_more_sr->("        const char *$arg;\n");
> +        } elsif ($argtype eq 'BLOCK') {
> +            $c_decl .= "const uint8_t *$arg, uint32_t ${arg}_size, ";
> +            $c_args .= ", ${arg}_size";
> +            $c_get_args .= ",&${arg}_size";
> +           $f_more_sr->("        const uint8_t *$arg;\n".
> +                         "        uint32_t ${arg}_size;\n");
> +       } else {
> +           $c_decl .= "$argtype $arg, ";
> +           $f_more_sr->("        $argtype $arg;\n");
> +       }
> +       $c_callback_args .= "$c_args, ";
> +       $c_recv.=
> +            "        if (!${typeid}_get(&msg,endmsg,$c_get_args)) return 0;\n";
> +        f_more("${encode}_$name", "    ${typeid}_put(buf, &len, $c_args);\n");
> +    }
> +    $f_more_sr->($c_recv);
> +    $c_decl .= "void *user)";
> +    $c_callback_args .= "user";
> +
> +    $f_more_sr->("        if (msg != endmsg) return 0;\n");
> +
> +    my $c_callback;
> +    if ($flags !~ m/c/) {
> +        $c_callback = "${callback}_$name";
> +    } else {
> +        $f_more_sr->(sub {
> +            my ($sr) = @_;
> +            $cbs{$sr} .= "    $c_rtype_callout (*${name})$c_decl;\n";
> +            return
> +          "        const ".cbtype($sr)." *const cbs =\n".
> +            "            ${getcallbacks}_${sr}(user);\n";
> +                       });
> +        $c_callback = "cbs->${name}";
> +    }
> +    my $c_make_callback = "$c_callback($c_callback_args)";
> +    if ($flags !~ m/W/) {
> +       $f_more_sr->("        $c_make_callback;\n");
> +    } else {
> +        $f_more_sr->("        r = $c_make_callback;\n".
> +                     "        $sendreply(r, user);\n");
> +       f_decl($sendreply, 'callout', 'void', '(int r, void *user)');
> +    }
> +    if ($flags =~ m/x/) {
> +        my $c_v = "(1u<<$msgnum)";
> +        my $c_cb = "cbs->$name";
> +        $f_more_sr->("    if ($c_cb) cbflags |= $c_v;\n", $enumcallbacks);
> +        $f_more_sr->("    $c_cb = (cbflags & $c_v) ? ${encode}_${name} : 0;\n",
> +                     $setcallbacks);
> +    }
> +    $f_more_sr->("        return 1;\n    }\n\n");
> +    f_decl("${callback}_$name", 'callout', $c_rtype_callout, $c_decl);
> +    f_decl("${encode}_$name", 'helper', $c_rtype_helper, $c_decl);
> +    f_more("${encode}_$name",
> +"        if (buf) break;
> +        buf = ${helper}_allocbuf(len, user);
> +        assert(buf);
> +        allocd = len;
> +        len = 0;
> +    }
> +    assert(len == allocd);
> +    ${transmit}(buf, len, user);
> +");
> +    if ($flags =~ m/W/) {
> +       f_more("${encode}_$name",
> +               (<<END_ALWAYS.($debug ? <<END_DEBUG : '').<<END_ALWAYS));
> +    int r = ${helper}_getreply(user);
> +END_ALWAYS
> +    fprintf(stderr,"libxl-save-helper: $name got reply %d\\n",r);
> +END_DEBUG
> +    return r;
> +END_ALWAYS
> +    }
> +}
> +
> +print "/* AUTOGENERATED by $0 DO NOT EDIT */\n\n" or die $!;
> +
> +foreach my $sr (qw(save restore)) {
> +    f_more("${enumcallbacks}_${sr}",
> +           "    return cbflags;\n");
> +    f_more("${receiveds}_${sr}",
> +           "    default:\n".
> +           "        return 0;\n".
> +           "    }");
> +    $cbs{$sr} .= "} ".cbtype($sr).";\n\n";
> +    if ($ch eq 'h') {
> +        print $cbs{$sr} or die $!;
> +        print "struct ${sr}_callbacks;\n";
> +    }
> +}
> +
> +if ($ch eq 'c') {
> +    foreach my $name (@outfuncs) {
> +        next unless defined $func{$name};
> +        $func{$name} .= "}\n\n";
> +        $out_body{$func_ah{$name}} .= $func{$name};
> +        delete $func{$name};
> +    }
> +    print $out_body{$want_ah} or die $!;
> +} else {
> +    foreach my $name (sort keys %out_decls) {
> +        next unless $func_ah{$name} eq $want_ah;
> +        print $out_decls{$name} or die $!;
> +    }
> +}
> +
> +close STDOUT or die $!;
> --
> tg: (52b6131..) t/xen/xc.save-restore-protocol (depends on: t/xen/xl.ao.suspend.pre)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:52: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 1SkF8Q-0004an-S0; Thu, 28 Jun 2012 13:51:50 +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 1SkF8P-0004ad-Bh
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:51:49 +0000
Received: from [85.158.139.83:13277] by server-8.bemta-5.messagelabs.com id
	3C/B8-10278-4716CEF4; Thu, 28 Jun 2012 13:51:48 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340891506!29454256!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29590 invoked from network); 28 Jun 2012 13:51:47 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:51:47 -0000
Received: by qafl39 with SMTP id l39so45843qaf.9
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Jun 2012 06:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=mVsJALOWkkTJyrqlpFsLBkWwP+lSDljEt5FRhquugvs=;
	b=XTU7zuYHuzql6M/gaU/Zspm+CWJZeyIPqzVBrY12lq0NxkO37hMuxNT45i41aM12Fm
	tqTMxXmY2CMdWwcANuWsb39iHWs/PHEgo3DeMlEMI36ID29eEkddRnDa1AHDmFIcWZr2
	Z50F91knY7uxDhYXqXyK2yCjeN7KRbl+nWDr06rQ98+gdH84JK55NRVttWmairMvWR/d
	eidBFl0xAIFa+oAYrr4Hxwer71lHy0G8TMY4V8cI8rpMvCDoQL+Yoiw4rG/qszdpWqmP
	4RSEiI58n0PepLZmxRnOl1bwhsX3415qLXdFUJqVUWSeJfv0SJQ9vOPCyABXhDfPQf7Y
	9JVg==
MIME-Version: 1.0
Received: by 10.224.59.19 with SMTP id j19mr3336189qah.25.1340891506417; Thu,
	28 Jun 2012 06:51:46 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 06:51:46 -0700 (PDT)
In-Reply-To: <20120628125322.GN34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<20120628125322.GN34995@ocelot.phlegethon.org>
Date: Thu, 28 Jun 2012 14:51:46 +0100
X-Google-Sender-Auth: HEbaswxERDZLYEB_GV9gfuCGBe0
Message-ID: <CAFLBxZaqhaSvXktKtCNUe9CkdKjAYr0Gc5-eS0LbWRsdenY5mQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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="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, Jun 28, 2012 at 1:53 PM, Tim Deegan <tim@xen.org> wrote:
> At 17:57 +0100 on 27 Jun (1340819847), George Dunlap wrote:
>> xen,pod: Populate-on-demand reclaim improvements
>>
>> Rework populate-on-demand sweeping
>>
>> Last summer I did some work on testing whether our PoD sweeping code
>> was achieving its goals: namely, never crashing unnecessairly,
>> minimizing boot time, and maximizing the number of superpages in the
>> p2m table.
>>
>> This is the resulting patch series.
>
> I've acked these, but only applied 1/4, because:
>
> =A0- patch 4 needs an S-o-B line;
> =A0- patch 2 can't go in before patch 4 because it depends on the new
> =A0 return value of p2m_pod_zero_check_superpage(); and

Hmm -- that's actually not right, and the only reason it doesn't cause
problems is because of the code taken out in patch 3.

Man, I hate having to clean up after sloppy coders! ;-)

But unfortunately that means 2 and 3 will probably lack Acks when they
come back.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13:52: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 1SkF8Q-0004an-S0; Thu, 28 Jun 2012 13:51:50 +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 1SkF8P-0004ad-Bh
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 13:51:49 +0000
Received: from [85.158.139.83:13277] by server-8.bemta-5.messagelabs.com id
	3C/B8-10278-4716CEF4; Thu, 28 Jun 2012 13:51:48 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340891506!29454256!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29590 invoked from network); 28 Jun 2012 13:51:47 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:51:47 -0000
Received: by qafl39 with SMTP id l39so45843qaf.9
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Jun 2012 06:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=mVsJALOWkkTJyrqlpFsLBkWwP+lSDljEt5FRhquugvs=;
	b=XTU7zuYHuzql6M/gaU/Zspm+CWJZeyIPqzVBrY12lq0NxkO37hMuxNT45i41aM12Fm
	tqTMxXmY2CMdWwcANuWsb39iHWs/PHEgo3DeMlEMI36ID29eEkddRnDa1AHDmFIcWZr2
	Z50F91knY7uxDhYXqXyK2yCjeN7KRbl+nWDr06rQ98+gdH84JK55NRVttWmairMvWR/d
	eidBFl0xAIFa+oAYrr4Hxwer71lHy0G8TMY4V8cI8rpMvCDoQL+Yoiw4rG/qszdpWqmP
	4RSEiI58n0PepLZmxRnOl1bwhsX3415qLXdFUJqVUWSeJfv0SJQ9vOPCyABXhDfPQf7Y
	9JVg==
MIME-Version: 1.0
Received: by 10.224.59.19 with SMTP id j19mr3336189qah.25.1340891506417; Thu,
	28 Jun 2012 06:51:46 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 06:51:46 -0700 (PDT)
In-Reply-To: <20120628125322.GN34995@ocelot.phlegethon.org>
References: <patchbomb.1340816247@elijah>
	<20120628125322.GN34995@ocelot.phlegethon.org>
Date: Thu, 28 Jun 2012 14:51:46 +0100
X-Google-Sender-Auth: HEbaswxERDZLYEB_GV9gfuCGBe0
Message-ID: <CAFLBxZaqhaSvXktKtCNUe9CkdKjAYr0Gc5-eS0LbWRsdenY5mQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] xen,
	pod: Populate-on-demand reclaim 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="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, Jun 28, 2012 at 1:53 PM, Tim Deegan <tim@xen.org> wrote:
> At 17:57 +0100 on 27 Jun (1340819847), George Dunlap wrote:
>> xen,pod: Populate-on-demand reclaim improvements
>>
>> Rework populate-on-demand sweeping
>>
>> Last summer I did some work on testing whether our PoD sweeping code
>> was achieving its goals: namely, never crashing unnecessairly,
>> minimizing boot time, and maximizing the number of superpages in the
>> p2m table.
>>
>> This is the resulting patch series.
>
> I've acked these, but only applied 1/4, because:
>
> =A0- patch 4 needs an S-o-B line;
> =A0- patch 2 can't go in before patch 4 because it depends on the new
> =A0 return value of p2m_pod_zero_check_superpage(); and

Hmm -- that's actually not right, and the only reason it doesn't cause
problems is because of the code taken out in patch 3.

Man, I hate having to clean up after sloppy coders! ;-)

But unfortunately that means 2 and 3 will probably lack Acks when they
come back.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 13:52:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkF8y-0004ez-8i; Thu, 28 Jun 2012 13:52: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 1SkF8x-0004ed-C4
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:52:23 +0000
Received: from [85.158.139.83:38325] by server-2.bemta-5.messagelabs.com id
	EF/ED-04598-6916CEF4; Thu, 28 Jun 2012 13:52:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340891541!22773647!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31368 invoked from network); 28 Jun 2012 13:52:21 -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 Jun 2012 13:52:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkF8u-000CeU-Vy; Thu, 28 Jun 2012 13:52:20 +0000
Date: Thu, 28 Jun 2012 14:52:20 +0100
From: Tim Deegan <tim@xen.org>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20120628135220.GQ34995@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-5-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340157467-19553-5-git-send-email-xudong.hao@intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, haitao.shan@intel.com, JBeulich@suse.com,
	xiantao.zhang@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest
	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

At 09:57 +0800 on 20 Jun (1340186267), Xudong Hao wrote:
> @@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
>                                                      entry->mfn);
>              break;
>          case p2m_ram_logdirty:
> +            entry->w = hap_has_dirty_bit;
> +            entry->r = entry->x = 1;
> +            /* Not necessarily need to clear A bit, but it is safe anyway */
> +            entry->a = entry->d = 0;
> +            break;

I think it's better not to clear the A bit - it will just cause the
hardware to issue extra writes to set it.

> @@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
>  
>          if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
>              ept_change_entry_type_page(_mfn(epte[i].mfn),
> -                                       ept_page_level - 1, ot, nt);
> +                                       ept_page_level - 1, ot, nt, d, mask);
>          else
>          {
>              e = atomic_read_ept_entry(&epte[i]);
>              if ( e.sa_p2mt != ot )
>                  continue;
>  
> +            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
> +            {
> +                int j, nr_pages;
> +                struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +                for ( j = 0, nr_pages = 1; j < ept_page_level;
> +                      j++, nr_pages *= 512 ) {}
> +                for ( j = 0; j < nr_pages; j++ )
> +                    paging_mark_dirty(d, e.mfn + j);
> +
> +                /* split super page to 4k page, so that dirty bitmap can 
> +                 * map the dirty page
> +                 */
> +                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
> +                    continue;

AIUI this code splits log-dirty superpages _after_ they are first seen
to be dirty.  So the first time they're dirtied, the entire superpage is
marked, but OTOH if they're never dirtied you don't need to split.  Is
that right?  If so, I think it needs a comment explaining it.  It took
me a few minutes to understand this code and convince myself it was
safe. :)

> +                atomic_write_ept_entry(&epte[i], e);
> +            }
>              e.sa_p2mt = nt;
>              ept_p2m_type_to_flags(&e, nt, e.access);
> +            if (!mask)
> +                e.a = e.d = 0;

Again, probably best to leave the A-bit set.

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 Jun 28 13:52:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkF8y-0004ez-8i; Thu, 28 Jun 2012 13:52: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 1SkF8x-0004ed-C4
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:52:23 +0000
Received: from [85.158.139.83:38325] by server-2.bemta-5.messagelabs.com id
	EF/ED-04598-6916CEF4; Thu, 28 Jun 2012 13:52:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340891541!22773647!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31368 invoked from network); 28 Jun 2012 13:52:21 -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 Jun 2012 13:52:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkF8u-000CeU-Vy; Thu, 28 Jun 2012 13:52:20 +0000
Date: Thu, 28 Jun 2012 14:52:20 +0100
From: Tim Deegan <tim@xen.org>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20120628135220.GQ34995@ocelot.phlegethon.org>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-5-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340157467-19553-5-git-send-email-xudong.hao@intel.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, haitao.shan@intel.com, JBeulich@suse.com,
	xiantao.zhang@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest
	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

At 09:57 +0800 on 20 Jun (1340186267), Xudong Hao wrote:
> @@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_acces
>                                                      entry->mfn);
>              break;
>          case p2m_ram_logdirty:
> +            entry->w = hap_has_dirty_bit;
> +            entry->r = entry->x = 1;
> +            /* Not necessarily need to clear A bit, but it is safe anyway */
> +            entry->a = entry->d = 0;
> +            break;

I think it's better not to clear the A bit - it will just cause the
hardware to issue extra writes to set it.

> @@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t ept_page_mfn, int ept_page_level,
>  
>          if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
>              ept_change_entry_type_page(_mfn(epte[i].mfn),
> -                                       ept_page_level - 1, ot, nt);
> +                                       ept_page_level - 1, ot, nt, d, mask);
>          else
>          {
>              e = atomic_read_ept_entry(&epte[i]);
>              if ( e.sa_p2mt != ot )
>                  continue;
>  
> +            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
> +            {
> +                int j, nr_pages;
> +                struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +                for ( j = 0, nr_pages = 1; j < ept_page_level;
> +                      j++, nr_pages *= 512 ) {}
> +                for ( j = 0; j < nr_pages; j++ )
> +                    paging_mark_dirty(d, e.mfn + j);
> +
> +                /* split super page to 4k page, so that dirty bitmap can 
> +                 * map the dirty page
> +                 */
> +                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
> +                    continue;

AIUI this code splits log-dirty superpages _after_ they are first seen
to be dirty.  So the first time they're dirtied, the entire superpage is
marked, but OTOH if they're never dirtied you don't need to split.  Is
that right?  If so, I think it needs a comment explaining it.  It took
me a few minutes to understand this code and convince myself it was
safe. :)

> +                atomic_write_ept_entry(&epte[i], e);
> +            }
>              e.sa_p2mt = nt;
>              ept_p2m_type_to_flags(&e, nt, e.access);
> +            if (!mask)
> +                e.a = e.d = 0;

Again, probably best to leave the A-bit set.

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 Jun 28 13:53:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkF9s-0004lh-Md; Thu, 28 Jun 2012 13:53:20 +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 1SkF9r-0004lQ-Ba
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:53:19 +0000
Received: from [193.109.254.147:19393] by server-11.bemta-14.messagelabs.com
	id AA/19-24843-EC16CEF4; Thu, 28 Jun 2012 13:53:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340891597!6618448!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8942 invoked from network); 28 Jun 2012 13:53:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:53:18 -0000
Received: by eekd41 with SMTP id d41so878179eek.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 06:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=TFCEWXOE1NX/t6Bswubctg7TT11f1qx2ng5pofops8o=;
	b=f11KwS7tckoiiRZka0WFBFbocZUJRkK+CEgRNHTrvZdlNdR4MYiet3gvg6a/XiEc5B
	0JKzI70+xAyYtOEc0pdg9FTsN1sfZeIAnRXMQDcEg0KTIkOr4o4Oq4PjtwXQKU/7qxDs
	zQf4ngqlUaCDgBvrCJLkzFLSfTRpRneYB7CEp/iOQtfHnKqOjM1eRHWgGzv1fvsKBW2k
	cNFKOecW02mE7US91WEHTYVDqYrI3bIcZcNsBht2YUv6cVJMwAkInOSc9saKYc6GEmX1
	XTReNZTFuvblOop2+CyPll9Wmi5XbMe2GoRTNGKLg8/ebz3KsL0eDo1Xb1U7JfZ3Dxm3
	cXZg==
Received: by 10.14.96.68 with SMTP id q44mr500067eef.182.1340891597386;
	Thu, 28 Jun 2012 06:53:17 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	o16sm169479316eeb.13.2012.06.28.06.53.16
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 06:53:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 28 Jun 2012 14:53:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC122058.44500%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
Thread-Index: Ac1VNVt6y61K+K/Sw0GH7X5gyAVnJA==
In-Reply-To: <4FEC7460020000780008C821@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 14:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 28.06.12 at 15:03, Keir Fraser <keir@xen.org> wrote:
>> On 25/06/2012 11:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
>>> as the whole function domain_pause_for_debugger() is pointless to be
>>> compiled when there's no arch support, simply introduce another HAS_*
>>> macro, enabled only on x86.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> How did arch/arm build at all then, previously, with this function present
>> for a long time in common code?
> 
> Prior to said c/s adding a reference to ->arch.gdbsx_vcpu_event,
> the function wasn't arch-specific at all.

Ah yes, of course. :)

>> Would a better fix be just to move the
>> function to arch/x86/domain.c, since it is only called by arch/x86?
> 
> I'd say no - the function really ought to be generic. Any arch
> wanting gdbsx support would have to add a respective field to
> its arch_vcpu. Or alternatively the field itself should get moved
> into struct vcpu, perhaps dependent upon some CONFIG_*.
> (This is also why I didn't want to put in e.g. a CONFIG_X86
> conditional, which would have been a smaller change.)

Well, fine then.

Acked-by: Keir Fraser <keir@xen.org>

> Jan
> 
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>>>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>>> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>>>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>>>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>>>  
>>> --- a/xen/arch/x86/Rules.mk
>>> +++ b/xen/arch/x86/Rules.mk
>>> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>>>  HAS_NS16550 := y
>>>  HAS_EHCI := y
>>>  HAS_KEXEC := y
>>> +HAS_GDBSX := y
>>>  xenoprof := y
>>>  
>>>  #
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>>>          vcpu_check_shutdown(v);
>>>  }
>>>  
>>> +#ifdef HAS_GDBSX
>>>  void domain_pause_for_debugger(void)
>>>  {
>>>      struct domain *d = current->domain;
>>> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>>>      if (current->arch.gdbsx_vcpu_event == 0)
>>>          send_global_virq(VIRQ_DEBUGGER);
>>>  }
>>> +#endif
>>>  
>>>  /* Complete domain destroy after RCU readers are not holding old
>> references.
>>> */
>>>  static void complete_domain_destroy(struct rcu_head *head)
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Jun 28 13:53:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 13: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 1SkF9s-0004lh-Md; Thu, 28 Jun 2012 13:53:20 +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 1SkF9r-0004lQ-Ba
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 13:53:19 +0000
Received: from [193.109.254.147:19393] by server-11.bemta-14.messagelabs.com
	id AA/19-24843-EC16CEF4; Thu, 28 Jun 2012 13:53:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340891597!6618448!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8942 invoked from network); 28 Jun 2012 13:53:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 13:53:18 -0000
Received: by eekd41 with SMTP id d41so878179eek.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 06:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=TFCEWXOE1NX/t6Bswubctg7TT11f1qx2ng5pofops8o=;
	b=f11KwS7tckoiiRZka0WFBFbocZUJRkK+CEgRNHTrvZdlNdR4MYiet3gvg6a/XiEc5B
	0JKzI70+xAyYtOEc0pdg9FTsN1sfZeIAnRXMQDcEg0KTIkOr4o4Oq4PjtwXQKU/7qxDs
	zQf4ngqlUaCDgBvrCJLkzFLSfTRpRneYB7CEp/iOQtfHnKqOjM1eRHWgGzv1fvsKBW2k
	cNFKOecW02mE7US91WEHTYVDqYrI3bIcZcNsBht2YUv6cVJMwAkInOSc9saKYc6GEmX1
	XTReNZTFuvblOop2+CyPll9Wmi5XbMe2GoRTNGKLg8/ebz3KsL0eDo1Xb1U7JfZ3Dxm3
	cXZg==
Received: by 10.14.96.68 with SMTP id q44mr500067eef.182.1340891597386;
	Thu, 28 Jun 2012 06:53:17 -0700 (PDT)
Received: from [192.168.1.3] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25]) by mx.google.com with ESMTPS id
	o16sm169479316eeb.13.2012.06.28.06.53.16
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 06:53:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 28 Jun 2012 14:53:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC122058.44500%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
Thread-Index: Ac1VNVt6y61K+K/Sw0GH7X5gyAVnJA==
In-Reply-To: <4FEC7460020000780008C821@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] arm: fix build after c/s 25477:e12e0b038219
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/06/2012 14:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 28.06.12 at 15:03, Keir Fraser <keir@xen.org> wrote:
>> On 25/06/2012 11:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Only x86 currently has a struct vcpu field arch.gdbsx_vcpu_event. But
>>> as the whole function domain_pause_for_debugger() is pointless to be
>>> compiled when there's no arch support, simply introduce another HAS_*
>>> macro, enabled only on x86.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> How did arch/arm build at all then, previously, with this function present
>> for a long time in common code?
> 
> Prior to said c/s adding a reference to ->arch.gdbsx_vcpu_event,
> the function wasn't arch-specific at all.

Ah yes, of course. :)

>> Would a better fix be just to move the
>> function to arch/x86/domain.c, since it is only called by arch/x86?
> 
> I'd say no - the function really ought to be generic. Any arch
> wanting gdbsx support would have to add a respective field to
> its arch_vcpu. Or alternatively the field itself should get moved
> into struct vcpu, perhaps dependent upon some CONFIG_*.
> (This is also why I didn't want to put in e.g. a CONFIG_X86
> conditional, which would have been a smaller change.)

Well, fine then.

Acked-by: Keir Fraser <keir@xen.org>

> Jan
> 
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTE
>>>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>>>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>>>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>>> +CFLAGS-$(HAS_GDBSX)     += -DHAS_GDBSX
>>>  CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>>>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>>>  
>>> --- a/xen/arch/x86/Rules.mk
>>> +++ b/xen/arch/x86/Rules.mk
>>> @@ -9,6 +9,7 @@ HAS_PASSTHROUGH := y
>>>  HAS_NS16550 := y
>>>  HAS_EHCI := y
>>>  HAS_KEXEC := y
>>> +HAS_GDBSX := y
>>>  xenoprof := y
>>>  
>>>  #
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -612,6 +612,7 @@ void vcpu_end_shutdown_deferral(struct v
>>>          vcpu_check_shutdown(v);
>>>  }
>>>  
>>> +#ifdef HAS_GDBSX
>>>  void domain_pause_for_debugger(void)
>>>  {
>>>      struct domain *d = current->domain;
>>> @@ -628,6 +629,7 @@ void domain_pause_for_debugger(void)
>>>      if (current->arch.gdbsx_vcpu_event == 0)
>>>          send_global_virq(VIRQ_DEBUGGER);
>>>  }
>>> +#endif
>>>  
>>>  /* Complete domain destroy after RCU readers are not holding old
>> references.
>>> */
>>>  static void complete_domain_destroy(struct rcu_head *head)
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Jun 28 14:00:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFGZ-0005Bb-JF; Thu, 28 Jun 2012 14:00: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 1SkFGX-0005BW-Sf
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:00:14 +0000
Received: from [85.158.143.99:9567] by server-2.bemta-4.messagelabs.com id
	92/7C-17938-D636CEF4; Thu, 28 Jun 2012 14:00:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340892011!29570868!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21826 invoked from network); 28 Jun 2012 14:00:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 14:00:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 15:01:35 +0100
Message-Id: <4FEC7FB8020000780008C885@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 15:00:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:38, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 28.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> So I would like to push new vMCE as quickly as possible. What's the
>>> timeline of vMCE developing that xen 4.2 could accept?
>> 
>> Weeks ago, really. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html 
>> and follow-ups - we'd really only consider getting the save/restore 
>> interface into forward compatible shape as acceptable.
>> 
>>> I wonder if we could make major
>>> components of vMCE done before xen 4.2 timeline, and leave the
>>> surrounding features and the corner cases done later?
>> 
>> Unfortunately it's likely going to be even less. However, if split
>> that way, chances are things could go into e.g. 4.2.1.
>> 
>> Jan
> 
> So let's look at current vMCE status first:
> 1). functionally it work abnormally for guest (but tolerated by some guest 
> like linux/solaris);
> 2). before xen 4.1 it blocks migration when migrate from big bank to small 
> bank platform;

Before 4.2 you mean (in 4.1 we only have this as a backport in SLE11).

> We may try some middle steps, minimal adjusting for xen 4.2 release (to 
> avoid futher compatible issue at xen 4.2.1, 4.3, ...):
> 1). we don't handle vMCE function bugs, only make sure migration works OK;

That's the minimal goal.

> 2). update vMCE interface to a middle clean status:
>     * remove MCG_CTL (otherwise we have to add this useless MSR at new 
> vMCE);
>     * stick all 1's to MCi_CTL (avoid semantic difference);
>     * for MCG_CAP, clear MCG_CTL_P, limit to 2 banks (otherwise dirty code 
> have to be added at new vMCE);

Whether that's acceptable would need to be seen when code
is ready.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:00:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFGZ-0005Bb-JF; Thu, 28 Jun 2012 14:00: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 1SkFGX-0005BW-Sf
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:00:14 +0000
Received: from [85.158.143.99:9567] by server-2.bemta-4.messagelabs.com id
	92/7C-17938-D636CEF4; Thu, 28 Jun 2012 14:00:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1340892011!29570868!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21826 invoked from network); 28 Jun 2012 14:00:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 14:00:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 15:01:35 +0100
Message-Id: <4FEC7FB8020000780008C885@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 15:00:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>,
 "Will Auld" <will.auld@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tony Luck <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ashok Raj <ashok.raj@intel.com>, Yunhong Jiang <yunhong.jiang@intel.com>,
	Susie Li <susie.li@intel.com>, Haitao Shan <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 15:38, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 28.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> So I would like to push new vMCE as quickly as possible. What's the
>>> timeline of vMCE developing that xen 4.2 could accept?
>> 
>> Weeks ago, really. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html 
>> and follow-ups - we'd really only consider getting the save/restore 
>> interface into forward compatible shape as acceptable.
>> 
>>> I wonder if we could make major
>>> components of vMCE done before xen 4.2 timeline, and leave the
>>> surrounding features and the corner cases done later?
>> 
>> Unfortunately it's likely going to be even less. However, if split
>> that way, chances are things could go into e.g. 4.2.1.
>> 
>> Jan
> 
> So let's look at current vMCE status first:
> 1). functionally it work abnormally for guest (but tolerated by some guest 
> like linux/solaris);
> 2). before xen 4.1 it blocks migration when migrate from big bank to small 
> bank platform;

Before 4.2 you mean (in 4.1 we only have this as a backport in SLE11).

> We may try some middle steps, minimal adjusting for xen 4.2 release (to 
> avoid futher compatible issue at xen 4.2.1, 4.3, ...):
> 1). we don't handle vMCE function bugs, only make sure migration works OK;

That's the minimal goal.

> 2). update vMCE interface to a middle clean status:
>     * remove MCG_CTL (otherwise we have to add this useless MSR at new 
> vMCE);
>     * stick all 1's to MCi_CTL (avoid semantic difference);
>     * for MCG_CAP, clear MCG_CTL_P, limit to 2 banks (otherwise dirty code 
> have to be added at new vMCE);

Whether that's acceptable would need to be seen when code
is ready.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:08:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkFOA-0005Lo-Fw; Thu, 28 Jun 2012 14:08:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkFO8-0005Lj-MJ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:08:04 +0000
Received: from [85.158.138.51:53123] by server-5.bemta-3.messagelabs.com id
	4E/0F-01572-3456CEF4; Thu, 28 Jun 2012 14:08:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340892482!21114547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16570 invoked from network); 28 Jun 2012 14:08:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:08:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13271763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:08:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:08:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFO5-0000fa-P7; Thu, 28 Jun 2012 14:08:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkF74-0005bI-8z;
	Thu, 28 Jun 2012 14:50:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.24844.245310.751828@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 14:50:04 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: add a new Array type to the IDL"):
> libxl: add a new Array type to the IDL
> 
> And make all the required infrastructure updates to enable this.
> 
> Since there are currently no uses of this type there is no change to
> the generated code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Great, thanks.

Dario, I take it you'll pick this up into your series so I don't need
to apply it separately.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:08:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkFOA-0005Lo-Fw; Thu, 28 Jun 2012 14:08:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkFO8-0005Lj-MJ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:08:04 +0000
Received: from [85.158.138.51:53123] by server-5.bemta-3.messagelabs.com id
	4E/0F-01572-3456CEF4; Thu, 28 Jun 2012 14:08:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340892482!21114547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16570 invoked from network); 28 Jun 2012 14:08:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:08:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13271763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:08:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:08:02 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFO5-0000fa-P7; Thu, 28 Jun 2012 14:08:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkF74-0005bI-8z;
	Thu, 28 Jun 2012 14:50:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.24844.245310.751828@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 14:50:04 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: add a new Array type to the IDL"):
> libxl: add a new Array type to the IDL
> 
> And make all the required infrastructure updates to enable this.
> 
> Since there are currently no uses of this type there is no change to
> the generated code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Great, thanks.

Dario, I take it you'll pick this up into your series so I don't need
to apply it separately.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:14:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkFUF-0005Yc-Ba; Thu, 28 Jun 2012 14:14: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 1SkFUE-0005YX-Do
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:14:22 +0000
Received: from [85.158.143.99:3702] by server-3.bemta-4.messagelabs.com id
	BA/56-05808-DB66CEF4; Thu, 28 Jun 2012 14:14:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340892860!26237415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15493 invoked from network); 28 Jun 2012 14:14:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:14:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13271935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:14:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:14:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFUC-0000hq-7C; Thu, 28 Jun 2012 14:14:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkFUC-0005dE-5V;
	Thu, 28 Jun 2012 15:14:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.26300.153067.650353@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:14:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340792106.29172.22.camel@zakaz.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
	<1340792106.29172.22.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL"):
> > Since there are currently no uses of this type there is no change to
> > the generated code.
> 
> But for reference if I add Dario's numa info type:

Thanks for providing that.  That's what I was looking at before and it
looked reasonable then.  I'm happy with it now 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 Jun 28 14:14:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkFUF-0005Yc-Ba; Thu, 28 Jun 2012 14:14: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 1SkFUE-0005YX-Do
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:14:22 +0000
Received: from [85.158.143.99:3702] by server-3.bemta-4.messagelabs.com id
	BA/56-05808-DB66CEF4; Thu, 28 Jun 2012 14:14:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340892860!26237415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15493 invoked from network); 28 Jun 2012 14:14:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:14:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13271935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:14:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:14:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFUC-0000hq-7C; Thu, 28 Jun 2012 14:14:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkFUC-0005dE-5V;
	Thu, 28 Jun 2012 15:14:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.26300.153067.650353@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:14:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340792106.29172.22.camel@zakaz.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
	<1340792106.29172.22.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL"):
> > Since there are currently no uses of this type there is no change to
> > the generated code.
> 
> But for reference if I add Dario's numa info type:

Thanks for providing that.  That's what I was looking at before and it
looked reasonable then.  I'm happy with it now 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 Jun 28 14:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkFZx-0005nX-A5; Thu, 28 Jun 2012 14:20:17 +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 1SkFZv-0005n2-Ep
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:20:15 +0000
Received: from [85.158.143.35:2646] by server-2.bemta-4.messagelabs.com id
	90/F4-17938-E186CEF4; Thu, 28 Jun 2012 14:20:14 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340893205!14546774!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6692 invoked from network); 28 Jun 2012 14:20:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:20:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; 
	d="asc'?scan'208";a="13272093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:20:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:20:04 +0100
Message-ID: <1340893203.21008.3.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 16:20:03 +0200
In-Reply-To: <20460.24844.245310.751828@mariner.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
	<20460.24844.245310.751828@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2792323196276579796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2792323196276579796==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-/0z8ZPruwPDS8mRq9bmV"

--=-/0z8ZPruwPDS8mRq9bmV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 14:50 +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>=20
> Great, thanks.
>=20
> Dario, I take it you'll pick this up into your series so I don't need
> to apply it separately.
>=20
That's fine.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-/0z8ZPruwPDS8mRq9bmV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/saBMACgkQk4XaBE3IOsQ+QgCcCk2OJxTC0Hw6a8S7AatbnE/h
EscAn2zROIy6joe5MCHTytJAKYXrBW10
=/9m6
-----END PGP SIGNATURE-----

--=-/0z8ZPruwPDS8mRq9bmV--


--===============2792323196276579796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2792323196276579796==--


From xen-devel-bounces@lists.xen.org Thu Jun 28 14:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkFZx-0005nX-A5; Thu, 28 Jun 2012 14:20:17 +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 1SkFZv-0005n2-Ep
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:20:15 +0000
Received: from [85.158.143.35:2646] by server-2.bemta-4.messagelabs.com id
	90/F4-17938-E186CEF4; Thu, 28 Jun 2012 14:20:14 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340893205!14546774!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6692 invoked from network); 28 Jun 2012 14:20:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:20:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; 
	d="asc'?scan'208";a="13272093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:20:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:20:04 +0100
Message-ID: <1340893203.21008.3.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 16:20:03 +0200
In-Reply-To: <20460.24844.245310.751828@mariner.uk.xensource.com>
References: <03b641aa89f979a1670b.1340791844@cosworth.uk.xensource.com>
	<20460.24844.245310.751828@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add a new Array type to the IDL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2792323196276579796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2792323196276579796==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-/0z8ZPruwPDS8mRq9bmV"

--=-/0z8ZPruwPDS8mRq9bmV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 14:50 +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Tested-by: Dario Faggioli <dario.faggioli@citrix.com>
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>=20
> Great, thanks.
>=20
> Dario, I take it you'll pick this up into your series so I don't need
> to apply it separately.
>=20
That's fine.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-/0z8ZPruwPDS8mRq9bmV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/saBMACgkQk4XaBE3IOsQ+QgCcCk2OJxTC0Hw6a8S7AatbnE/h
EscAn2zROIy6joe5MCHTytJAKYXrBW10
=/9m6
-----END PGP SIGNATURE-----

--=-/0z8ZPruwPDS8mRq9bmV--


--===============2792323196276579796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2792323196276579796==--


From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkFeI-00061q-0D; Thu, 28 Jun 2012 14:24: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 1SkFeG-00061a-3P
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:24:44 +0000
Received: from [85.158.139.83:11890] by server-6.bemta-5.messagelabs.com id
	4C/5E-11348-B296CEF4; Thu, 28 Jun 2012 14:24:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340893482!18742169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12972 invoked from network); 28 Jun 2012 14:24:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:24:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:24:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:24:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFeE-0000nE-94; Thu, 28 Jun 2012 14:24:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkFeE-0005eA-76;
	Thu, 28 Jun 2012 15:24:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.26922.21629.642044@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:24:42 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340891415.10942.53.camel@zakaz.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
	<1340891415.10942.53.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH v6 00/21] libxl: domain save/restore: run in a separate process"):
> Does this mean this series is now ready to go in?

I think so.  I'm just giving Shriram a chance to object.

> I did wonder when I saw the incremental patch if some of those internal
> callback pointers could perhaps be properly typed instead of void
> (because they all end up taking the same pointer type), but lets not
> worry about that here.

The void*'s come from the libxc API.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkFeI-00061q-0D; Thu, 28 Jun 2012 14:24: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 1SkFeG-00061a-3P
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:24:44 +0000
Received: from [85.158.139.83:11890] by server-6.bemta-5.messagelabs.com id
	4C/5E-11348-B296CEF4; Thu, 28 Jun 2012 14:24:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340893482!18742169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12972 invoked from network); 28 Jun 2012 14:24:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:24:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:24:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:24:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFeE-0000nE-94; Thu, 28 Jun 2012 14:24:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkFeE-0005eA-76;
	Thu, 28 Jun 2012 15:24:42 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.26922.21629.642044@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:24:42 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340891415.10942.53.camel@zakaz.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
	<1340891415.10942.53.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH v6 00/21] libxl: domain save/restore: run in a separate process"):
> Does this mean this series is now ready to go in?

I think so.  I'm just giving Shriram a chance to object.

> I did wonder when I saw the incremental patch if some of those internal
> callback pointers could perhaps be properly typed instead of void
> (because they all end up taking the same pointer type), but lets not
> worry about that here.

The void*'s come from the libxc API.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFei-00065m-JY; Thu, 28 Jun 2012 14:25:12 +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 1SkFeg-00065U-V8
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:11 +0000
Received: from [85.158.143.35:7304] by server-1.bemta-4.messagelabs.com id
	66/96-24392-6496CEF4; Thu, 28 Jun 2012 14:25:10 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340893506!16126060!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27859 invoked from network); 28 Jun 2012 14:25: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;
	28 Jun 2012 14:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200378843"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-3g;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9de241075c7f622758f00223805b0279635ff4d9
Message-ID: <9de241075c7f622758f0.1340893183@elijah>
In-Reply-To: <patchbomb.1340893181@elijah>
References: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:43 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3 v3] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340893083 -3600
# Node ID 9de241075c7f622758f00223805b0279635ff4d9
# Parent  fb0187ae8a20d0850dea0cd3e4167503411e5950
xen,pod: Zero-check recently populated pages (checklast)

When demand-populating pages due to guest accesses, check recently populated
pages to see if we can reclaim them for the cache.  This should keep the PoD
cache filled when the start-of-day scrubber is going through.

The number 128 was chosen by experiment.  Windows does its page
scrubbing in parallel; while a small nubmer like 4 works well for
single VMs, it breaks down as multiple vcpus are scrubbing different
pages in parallel.  Increasing to 128 works well for higher numbers of
vcpus.

v2:
 - Wrapped some long lines
 - unsigned int for index, unsigned long for array
v3:
 - Use PAGE_ORDER_2M instead of 9
 - Removed inappropriate use of p2m_pod_zero_check_superpage() return value

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -926,6 +926,27 @@ p2m_pod_emergency_sweep_super(struct p2m
     p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
 }
 
+/* When populating a new superpage, look at recently populated superpages
+ * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
+ * the guest OS is done with them. */
+static void
+p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
+{
+    unsigned long check_gfn;
+
+    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
+
+    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
+
+    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
+
+    p2m->pod.last_populated_index =
+        ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
+
+    p2m_pod_zero_check_superpage(p2m, check_gfn);
+}
+
+
 #define POD_SWEEP_STRIDE  16
 static void
 p2m_pod_emergency_sweep(struct p2m_domain *p2m)
@@ -1083,6 +1104,12 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    /* Check the last guest demand-populate */
+    if ( p2m->pod.entry_count > p2m->pod.count 
+         && (order == PAGE_ORDER_2M)
+         && (q & P2M_ALLOC) )
+        p2m_pod_check_last_super(p2m, gfn_aligned);
+
     pod_unlock(p2m);
     return 0;
 out_of_memory:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -287,6 +287,10 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+#define POD_HISTORY_MAX 128
+        /* gpfn of last guest superpage demand-populated */
+        unsigned long    last_populated[POD_HISTORY_MAX]; 
+        unsigned int     last_populated_index;
         mm_lock_t        lock;         /* Locking of private pod structs,   *
                                         * not relying on the p2m lock.      */
     } pod;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFei-00065m-JY; Thu, 28 Jun 2012 14:25:12 +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 1SkFeg-00065U-V8
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:11 +0000
Received: from [85.158.143.35:7304] by server-1.bemta-4.messagelabs.com id
	66/96-24392-6496CEF4; Thu, 28 Jun 2012 14:25:10 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340893506!16126060!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27859 invoked from network); 28 Jun 2012 14:25: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;
	28 Jun 2012 14:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200378843"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-3g;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9de241075c7f622758f00223805b0279635ff4d9
Message-ID: <9de241075c7f622758f0.1340893183@elijah>
In-Reply-To: <patchbomb.1340893181@elijah>
References: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:43 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3 v3] xen,
 pod: Zero-check recently populated pages (checklast)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340893083 -3600
# Node ID 9de241075c7f622758f00223805b0279635ff4d9
# Parent  fb0187ae8a20d0850dea0cd3e4167503411e5950
xen,pod: Zero-check recently populated pages (checklast)

When demand-populating pages due to guest accesses, check recently populated
pages to see if we can reclaim them for the cache.  This should keep the PoD
cache filled when the start-of-day scrubber is going through.

The number 128 was chosen by experiment.  Windows does its page
scrubbing in parallel; while a small nubmer like 4 works well for
single VMs, it breaks down as multiple vcpus are scrubbing different
pages in parallel.  Increasing to 128 works well for higher numbers of
vcpus.

v2:
 - Wrapped some long lines
 - unsigned int for index, unsigned long for array
v3:
 - Use PAGE_ORDER_2M instead of 9
 - Removed inappropriate use of p2m_pod_zero_check_superpage() return value

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -926,6 +926,27 @@ p2m_pod_emergency_sweep_super(struct p2m
     p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
 }
 
+/* When populating a new superpage, look at recently populated superpages
+ * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
+ * the guest OS is done with them. */
+static void
+p2m_pod_check_last_super(struct p2m_domain *p2m, unsigned long gfn_aligned)
+{
+    unsigned long check_gfn;
+
+    ASSERT(p2m->pod.last_populated_index < POD_HISTORY_MAX);
+
+    check_gfn = p2m->pod.last_populated[p2m->pod.last_populated_index];
+
+    p2m->pod.last_populated[p2m->pod.last_populated_index] = gfn_aligned;
+
+    p2m->pod.last_populated_index =
+        ( p2m->pod.last_populated_index + 1 ) % POD_HISTORY_MAX;
+
+    p2m_pod_zero_check_superpage(p2m, check_gfn);
+}
+
+
 #define POD_SWEEP_STRIDE  16
 static void
 p2m_pod_emergency_sweep(struct p2m_domain *p2m)
@@ -1083,6 +1104,12 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    /* Check the last guest demand-populate */
+    if ( p2m->pod.entry_count > p2m->pod.count 
+         && (order == PAGE_ORDER_2M)
+         && (q & P2M_ALLOC) )
+        p2m_pod_check_last_super(p2m, gfn_aligned);
+
     pod_unlock(p2m);
     return 0;
 out_of_memory:
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -287,6 +287,10 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+#define POD_HISTORY_MAX 128
+        /* gpfn of last guest superpage demand-populated */
+        unsigned long    last_populated[POD_HISTORY_MAX]; 
+        unsigned int     last_populated_index;
         mm_lock_t        lock;         /* Locking of private pod structs,   *
                                         * not relying on the p2m lock.      */
     } pod;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFem-00066Y-DT; Thu, 28 Jun 2012 14:25:16 +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 1SkFek-000663-0u
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:14 +0000
Received: from [85.158.138.51:53307] by server-9.bemta-3.messagelabs.com id
	2E/05-10419-4496CEF4; Thu, 28 Jun 2012 14:25:08 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340893506!27129488!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22314 invoked from network); 28 Jun 2012 14:25:07 -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;
	28 Jun 2012 14:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="29758086"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-3D;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
X-Mercurial-Node: fb0187ae8a20d0850dea0cd3e4167503411e5950
Message-ID: <fb0187ae8a20d0850dea.1340893182@elijah>
In-Reply-To: <patchbomb.1340893181@elijah>
References: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:42 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3 v3] xen,
 pod: Try to reclaim superpages when ballooning 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340893080 -3600
# Node ID fb0187ae8a20d0850dea0cd3e4167503411e5950
# Parent  52f1b8a4f9a4cb454b6fea1220cc6a09cf401a42
xen,pod: Try to reclaim superpages when ballooning down

Windows balloon drivers can typically only get 4k pages from the kernel,
and so hand them back at that level.  Try to regain superpages by checking
the superpage frame that the 4k page is in to see if we can reclaim the whole
thing for the PoD cache.

This also modifies p2m_pod_zero_check_superpage() to return SUPERPAGE_PAGES on
success.

v2:
 - Rewritten to simply to the check as in demand-fault case, without needing
   to know that the p2m entry is a superpage.
 - Also, took out the re-writing of the reclaim loop, leaving it optimized for
   4k pages (by far the most common case), and simplifying the patch.
v3:
 - Add SoB

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -488,6 +488,10 @@ p2m_pod_offline_or_broken_replace(struct
     return;
 }
 
+static int
+p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn);
+
+
 /* This function is needed for two reasons:
  * + To properly handle clearing of PoD entries
  * + To "steal back" memory being freed for the PoD cache, rather than
@@ -505,8 +509,8 @@ p2m_pod_decrease_reservation(struct doma
     int i;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    int steal_for_cache = 0;
-    int pod = 0, nonpod = 0, ram = 0;
+    int steal_for_cache;
+    int pod, nonpod, ram;
 
     gfn_lock(p2m, gpfn, order);
     pod_lock(p2m);    
@@ -516,13 +520,15 @@ p2m_pod_decrease_reservation(struct doma
     if ( p2m->pod.entry_count == 0 )
         goto out_unlock;
 
+    if ( unlikely(d->is_dying) )
+        goto out_unlock;
+
+recount:
+    pod = nonpod = ram = 0;
+
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    if ( unlikely(d->is_dying) )
-        goto out_unlock;
-
-    /* See what's in here. */
     /* FIXME: Add contiguous; query for PSE entries? */
     for ( i=0; i<(1<<order); i++)
     {
@@ -556,7 +562,16 @@ p2m_pod_decrease_reservation(struct doma
         goto out_entry_check;
     }
 
-    /* FIXME: Steal contig 2-meg regions for cache */
+    /* Try to grab entire superpages if possible.  Since the common case is for drivers
+     * to pass back singleton pages, see if we can take the whole page back and mark the
+     * rest PoD. */
+    if ( steal_for_cache
+         && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
+    {
+        /* Since order may be arbitrary, we may have taken more or less
+         * than we were actually asked to; so just re-count from scratch */
+        goto recount;
+    }
 
     /* Process as long as:
      * + There are PoD entries to handle, or
@@ -758,6 +773,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     p2m_pod_cache_add(p2m, mfn_to_page(mfn0), PAGE_ORDER_2M);
     p2m->pod.entry_count += SUPERPAGE_PAGES;
 
+    ret = SUPERPAGE_PAGES;
+
 out_reset:
     if ( reset )
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFem-00066Y-DT; Thu, 28 Jun 2012 14:25:16 +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 1SkFek-000663-0u
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:14 +0000
Received: from [85.158.138.51:53307] by server-9.bemta-3.messagelabs.com id
	2E/05-10419-4496CEF4; Thu, 28 Jun 2012 14:25:08 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1340893506!27129488!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22314 invoked from network); 28 Jun 2012 14:25:07 -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;
	28 Jun 2012 14:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="29758086"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-3D;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
X-Mercurial-Node: fb0187ae8a20d0850dea0cd3e4167503411e5950
Message-ID: <fb0187ae8a20d0850dea.1340893182@elijah>
In-Reply-To: <patchbomb.1340893181@elijah>
References: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:42 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3 v3] xen,
 pod: Try to reclaim superpages when ballooning 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340893080 -3600
# Node ID fb0187ae8a20d0850dea0cd3e4167503411e5950
# Parent  52f1b8a4f9a4cb454b6fea1220cc6a09cf401a42
xen,pod: Try to reclaim superpages when ballooning down

Windows balloon drivers can typically only get 4k pages from the kernel,
and so hand them back at that level.  Try to regain superpages by checking
the superpage frame that the 4k page is in to see if we can reclaim the whole
thing for the PoD cache.

This also modifies p2m_pod_zero_check_superpage() to return SUPERPAGE_PAGES on
success.

v2:
 - Rewritten to simply to the check as in demand-fault case, without needing
   to know that the p2m entry is a superpage.
 - Also, took out the re-writing of the reclaim loop, leaving it optimized for
   4k pages (by far the most common case), and simplifying the patch.
v3:
 - Add SoB

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -488,6 +488,10 @@ p2m_pod_offline_or_broken_replace(struct
     return;
 }
 
+static int
+p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn);
+
+
 /* This function is needed for two reasons:
  * + To properly handle clearing of PoD entries
  * + To "steal back" memory being freed for the PoD cache, rather than
@@ -505,8 +509,8 @@ p2m_pod_decrease_reservation(struct doma
     int i;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    int steal_for_cache = 0;
-    int pod = 0, nonpod = 0, ram = 0;
+    int steal_for_cache;
+    int pod, nonpod, ram;
 
     gfn_lock(p2m, gpfn, order);
     pod_lock(p2m);    
@@ -516,13 +520,15 @@ p2m_pod_decrease_reservation(struct doma
     if ( p2m->pod.entry_count == 0 )
         goto out_unlock;
 
+    if ( unlikely(d->is_dying) )
+        goto out_unlock;
+
+recount:
+    pod = nonpod = ram = 0;
+
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    if ( unlikely(d->is_dying) )
-        goto out_unlock;
-
-    /* See what's in here. */
     /* FIXME: Add contiguous; query for PSE entries? */
     for ( i=0; i<(1<<order); i++)
     {
@@ -556,7 +562,16 @@ p2m_pod_decrease_reservation(struct doma
         goto out_entry_check;
     }
 
-    /* FIXME: Steal contig 2-meg regions for cache */
+    /* Try to grab entire superpages if possible.  Since the common case is for drivers
+     * to pass back singleton pages, see if we can take the whole page back and mark the
+     * rest PoD. */
+    if ( steal_for_cache
+         && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
+    {
+        /* Since order may be arbitrary, we may have taken more or less
+         * than we were actually asked to; so just re-count from scratch */
+        goto recount;
+    }
 
     /* Process as long as:
      * + There are PoD entries to handle, or
@@ -758,6 +773,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     p2m_pod_cache_add(p2m, mfn_to_page(mfn0), PAGE_ORDER_2M);
     p2m->pod.entry_count += SUPERPAGE_PAGES;
 
+    ret = SUPERPAGE_PAGES;
+
 out_reset:
     if ( reset )
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFek-000666-0A; Thu, 28 Jun 2012 14:25:14 +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 1SkFei-00065i-FV
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:12 +0000
Received: from [85.158.143.35:62960] by server-2.bemta-4.messagelabs.com id
	8B/CD-17938-7496CEF4; Thu, 28 Jun 2012 14:25:11 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340893506!16126060!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28013 invoked from network); 28 Jun 2012 14:25:08 -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;
	28 Jun 2012 14:25:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200378844"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-46;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
X-Mercurial-Node: 90f2f1728f906b1fb2e2d70e5a88b54d0fc190d8
Message-ID: <90f2f1728f906b1fb2e2.1340893184@elijah>
In-Reply-To: <patchbomb.1340893181@elijah>
References: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:44 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3 v3] xen, pod: Only sweep in an emergency,
 and only for 4k 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340893085 -3600
# Node ID 90f2f1728f906b1fb2e2d70e5a88b54d0fc190d8
# Parent  9de241075c7f622758f00223805b0279635ff4d9
xen,pod: Only sweep in an emergency, and only for 4k pages

Testing has shown that doing sweeps for superpages slows down boot
significantly, but does not result in a significantly higher number of
superpages after boot.  Early sweeping for 4k pages causes superpages
to be broken up unnecessarily.

Only sweep if we're really out of memory.

v2:
 - Move unrelated code-motion hunk to another patch
v3:
 - Remove now-unused reclaim_super from pod struct

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -897,34 +897,6 @@ p2m_pod_zero_check(struct p2m_domain *p2
 }
 
 #define POD_SWEEP_LIMIT 1024
-static void
-p2m_pod_emergency_sweep_super(struct p2m_domain *p2m)
-{
-    unsigned long i, start, limit;
-
-    if ( p2m->pod.reclaim_super == 0 )
-    {
-        p2m->pod.reclaim_super = (p2m->pod.max_guest>>PAGE_ORDER_2M)<<PAGE_ORDER_2M;
-        p2m->pod.reclaim_super -= SUPERPAGE_PAGES;
-    }
-    
-    start = p2m->pod.reclaim_super;
-    limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
-
-    for ( i=p2m->pod.reclaim_super ; i > 0 ; i -= SUPERPAGE_PAGES )
-    {
-        p2m_pod_zero_check_superpage(p2m, i);
-        /* Stop if we're past our limit and we have found *something*.
-         *
-         * NB that this is a zero-sum game; we're increasing our cache size
-         * by increasing our 'debt'.  Since we hold the p2m lock,
-         * (entry_count - count) must remain the same. */
-        if ( !page_list_empty(&p2m->pod.super) &&  i < limit )
-            break;
-    }
-
-    p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
-}
 
 /* When populating a new superpage, look at recently populated superpages
  * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
@@ -1039,27 +1011,12 @@ p2m_pod_demand_populate(struct p2m_domai
         return 0;
     }
 
-    /* Once we've ballooned down enough that we can fill the remaining
-     * PoD entries from the cache, don't sweep even if the particular
-     * list we want to use is empty: that can lead to thrashing zero pages 
-     * through the cache for no good reason.  */
-    if ( p2m->pod.entry_count > p2m->pod.count )
-    {
+    /* Only sweep if we're actually out of memory.  Doing anything else
+     * causes unnecessary time and fragmentation of superpages in the p2m. */
+    if ( p2m->pod.count == 0 )
+        p2m_pod_emergency_sweep(p2m);
 
-        /* If we're low, start a sweep */
-        if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
-            /* Note that sweeps scan other ranges in the p2m. In an scenario
-             * in which p2m locks are fine-grained, this may result in deadlock.
-             * Using trylock on the gfn's as we sweep would avoid it. */
-            p2m_pod_emergency_sweep_super(p2m);
-
-        if ( page_list_empty(&p2m->pod.single) &&
-             ( ( order == PAGE_ORDER_4K )
-               || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
-            /* Same comment regarding deadlock applies */
-            p2m_pod_emergency_sweep(p2m);
-    }
-
+    /* If the sweep failed, give up. */
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -284,7 +284,6 @@ struct p2m_domain {
                          single;       /* Non-super lists                   */
         int              count,        /* # of pages in cache lists         */
                          entry_count;  /* # of pages in p2m marked pod      */
-        unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
 #define POD_HISTORY_MAX 128

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFek-000666-0A; Thu, 28 Jun 2012 14:25:14 +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 1SkFei-00065i-FV
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:12 +0000
Received: from [85.158.143.35:62960] by server-2.bemta-4.messagelabs.com id
	8B/CD-17938-7496CEF4; Thu, 28 Jun 2012 14:25:11 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340893506!16126060!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28013 invoked from network); 28 Jun 2012 14:25:08 -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;
	28 Jun 2012 14:25:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200378844"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-46;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
X-Mercurial-Node: 90f2f1728f906b1fb2e2d70e5a88b54d0fc190d8
Message-ID: <90f2f1728f906b1fb2e2.1340893184@elijah>
In-Reply-To: <patchbomb.1340893181@elijah>
References: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:44 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3 v3] xen, pod: Only sweep in an emergency,
 and only for 4k 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

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1340893085 -3600
# Node ID 90f2f1728f906b1fb2e2d70e5a88b54d0fc190d8
# Parent  9de241075c7f622758f00223805b0279635ff4d9
xen,pod: Only sweep in an emergency, and only for 4k pages

Testing has shown that doing sweeps for superpages slows down boot
significantly, but does not result in a significantly higher number of
superpages after boot.  Early sweeping for 4k pages causes superpages
to be broken up unnecessarily.

Only sweep if we're really out of memory.

v2:
 - Move unrelated code-motion hunk to another patch
v3:
 - Remove now-unused reclaim_super from pod struct

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -897,34 +897,6 @@ p2m_pod_zero_check(struct p2m_domain *p2
 }
 
 #define POD_SWEEP_LIMIT 1024
-static void
-p2m_pod_emergency_sweep_super(struct p2m_domain *p2m)
-{
-    unsigned long i, start, limit;
-
-    if ( p2m->pod.reclaim_super == 0 )
-    {
-        p2m->pod.reclaim_super = (p2m->pod.max_guest>>PAGE_ORDER_2M)<<PAGE_ORDER_2M;
-        p2m->pod.reclaim_super -= SUPERPAGE_PAGES;
-    }
-    
-    start = p2m->pod.reclaim_super;
-    limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
-
-    for ( i=p2m->pod.reclaim_super ; i > 0 ; i -= SUPERPAGE_PAGES )
-    {
-        p2m_pod_zero_check_superpage(p2m, i);
-        /* Stop if we're past our limit and we have found *something*.
-         *
-         * NB that this is a zero-sum game; we're increasing our cache size
-         * by increasing our 'debt'.  Since we hold the p2m lock,
-         * (entry_count - count) must remain the same. */
-        if ( !page_list_empty(&p2m->pod.super) &&  i < limit )
-            break;
-    }
-
-    p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0;
-}
 
 /* When populating a new superpage, look at recently populated superpages
  * hoping that they've been zeroed.  This will snap up zeroed pages as soon as 
@@ -1039,27 +1011,12 @@ p2m_pod_demand_populate(struct p2m_domai
         return 0;
     }
 
-    /* Once we've ballooned down enough that we can fill the remaining
-     * PoD entries from the cache, don't sweep even if the particular
-     * list we want to use is empty: that can lead to thrashing zero pages 
-     * through the cache for no good reason.  */
-    if ( p2m->pod.entry_count > p2m->pod.count )
-    {
+    /* Only sweep if we're actually out of memory.  Doing anything else
+     * causes unnecessary time and fragmentation of superpages in the p2m. */
+    if ( p2m->pod.count == 0 )
+        p2m_pod_emergency_sweep(p2m);
 
-        /* If we're low, start a sweep */
-        if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
-            /* Note that sweeps scan other ranges in the p2m. In an scenario
-             * in which p2m locks are fine-grained, this may result in deadlock.
-             * Using trylock on the gfn's as we sweep would avoid it. */
-            p2m_pod_emergency_sweep_super(p2m);
-
-        if ( page_list_empty(&p2m->pod.single) &&
-             ( ( order == PAGE_ORDER_4K )
-               || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
-            /* Same comment regarding deadlock applies */
-            p2m_pod_emergency_sweep(p2m);
-    }
-
+    /* If the sweep failed, give up. */
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -284,7 +284,6 @@ struct p2m_domain {
                          single;       /* Non-super lists                   */
         int              count,        /* # of pages in cache lists         */
                          entry_count;  /* # of pages in p2m marked pod      */
-        unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
 #define POD_HISTORY_MAX 128

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFew-00069t-Qz; Thu, 28 Jun 2012 14:25:26 +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 1SkFev-00069G-VS
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:26 +0000
Received: from [85.158.143.35:2283] by server-3.bemta-4.messagelabs.com id
	71/3C-05808-5596CEF4; Thu, 28 Jun 2012 14:25:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340893508!15445838!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11149 invoked from network); 28 Jun 2012 14:25:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200378845"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-2g;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3 v3] xen,
	pod: Populate-on-demand reclaim 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

xen,pod: Populate-on-demand reclaim improvements

Rework populate-on-demand sweeping

Last summer I did some work on testing whether our PoD sweeping code
was achieving its goals: namely, never crashing unnecessairly,
minimizing boot time, and maximizing the number of superpages in the
p2m table.

This is the resulting patch series.

v2:
 - Move cosmetic code-motion hunk into its own patch
 - Address various comments
 - Include a simplified version of the balloon reclaim reclamation patch
v3:
 - Remove code motion patch (already checked in)
 - Move balloon patch to front
 - Add SoB to balloon patch
 - More clean-ups to "checklast" and remove-supersweep patches

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:25:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:25: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 1SkFew-00069t-Qz; Thu, 28 Jun 2012 14:25:26 +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 1SkFev-00069G-VS
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:25:26 +0000
Received: from [85.158.143.35:2283] by server-3.bemta-4.messagelabs.com id
	71/3C-05808-5596CEF4; Thu, 28 Jun 2012 14:25:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340893508!15445838!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11149 invoked from network); 28 Jun 2012 14:25:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200378845"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 10:25:05 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 10:25:04 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1SkFbd-0005Br-2g;
	Thu, 28 Jun 2012 15:22:01 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340893181@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 28 Jun 2012 15:19:41 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3 v3] xen,
	pod: Populate-on-demand reclaim 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

xen,pod: Populate-on-demand reclaim improvements

Rework populate-on-demand sweeping

Last summer I did some work on testing whether our PoD sweeping code
was achieving its goals: namely, never crashing unnecessairly,
minimizing boot time, and maximizing the number of superpages in the
p2m table.

This is the resulting patch series.

v2:
 - Move cosmetic code-motion hunk into its own patch
 - Address various comments
 - Include a simplified version of the balloon reclaim reclamation patch
v3:
 - Remove code motion patch (already checked in)
 - Move balloon patch to front
 - Add SoB to balloon patch
 - More clean-ups to "checklast" and remove-supersweep patches

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:37:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFq4-0006uH-35; Thu, 28 Jun 2012 14:36:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SkFq2-0006uC-Q4
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:36:55 +0000
Received: from [85.158.139.83:19145] by server-6.bemta-5.messagelabs.com id
	5C/8B-11348-50C6CEF4; Thu, 28 Jun 2012 14:36:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340894211!25731247!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMjMyNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 28 Jun 2012 14:36:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 14:36:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5SEaTIO005302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Jun 2012 14:36:30 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
	q5SEaRPq016874
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Jun 2012 14:36:28 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
	q5SEaPLi022246; Thu, 28 Jun 2012 09:36:26 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 07:36:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EBA6D4029B; Thu, 28 Jun 2012 10:28:36 -0400 (EDT)
Date: Thu, 28 Jun 2012 10:28:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: cyclonusj@gmail.com, marmarek@invisiblethingslab.com, hpa@zytor.com
Message-ID: <20120628142836.GE8956@phenom.dumpdata.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120627231755.GA1021@gmail.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, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 27, 2012 at 04:17:56PM -0700, Cyclonus J wrote:
> On Thu, May 10, 2012 at 11:34:57AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 21, 2012 at 06:53:35PM -0800, Jason Garrett-Glaser wrote:
> > > On Fri, Feb 10, 2012 at 7:34 AM, Konrad Rzeszutek Wilk
> > > <konrad.wilk@oracle.com> wrote:
> > > > The attached patch fixes RH BZ #742032, #787403, and #745574
> > > > and touch x86 subsystem.
> > > >
> > > > The patch description gives a very good overview of the problem and
> > > > one solution. The one solution it chooses is not the most architect=
urally
> > > > sound but it does not cause performance degradation. If this your
> > > > first time reading this, please read the patch first and then come =
back to
> > > > this cover letter as I've some perf numbers and more detailed expla=
nation here.
> > > >
> > > > A bit of overview of the __page_change_attr_set_clr:
> > > >
> > > > Its purpose is to change page attributes from one type to another.
> > > > It is important to understand that the entrance that code:
> > > > __page_change_attr_set_clr is guarded by cpa_lock spin-lock - which=
 makes
> > > > that whole code be single threaded.
> > > >
> > > > Albeit it seems that if debug mode is turned on, it can run in para=
llel. The
> > > > effect of using the posted patch is that __page_change_attr_set_clr=
() will be
> > > > affected when we change caching attributes on 4KB pages and/or the =
NX flag.
> > > >
> > > > The execution of __page_change_attr_set_clr is concentrated in
> > > > (looked for ioremap_* and set_pages_*):
> > > > =A0- during bootup ("Write protecting the ..")
> > > > =A0- suspend/resume and graphic adapters evicting their buffers fro=
m the card
> > > > =A0 to RAM (which is usually done during suspend but can be done vi=
a the
> > > > =A0 'evict' attribute in debugfs)
> > > > =A0- when setting the memory for the cursor (AGP cards using i8xx c=
hipset) -
> > > > =A0 done during bootup and startup of Xserver.
> > > > =A0- setting up memory for Intel GTT scratch (i9xx) page (done duri=
ng bootup)
> > > > =A0- payload (purgatory code) for kexec (done during kexec -l).
> > > > =A0- ioremap_* during PCI devices load - InfiniBand and video cards=
 like to use
> > > > =A0 ioremap_wc.
> > > > =A0- Intel, radeon, nouveau running into memory pressure and evicti=
ng pages from
> > > > =A0 their GEM/TTM pool (once an hour or so if compiling a lot with =
only 4GB).
> > > >
> > > > These are the cases I found when running on baremetal (and Xen) usi=
ng a normal
> > > > Fedora Core 16 distro.
> > > >
> > > > The alternate solution to the problem I am trying to solve, which i=
s much
> > > > more architecturally sound (but has some perf disadvantages) is to =
wrap
> > > > the pte_flags with paravirt call everywhere. For that these patches=
 two patches:
> > > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-par=
avirt-xen-Introduce-pte_flags.patch
> > > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-par=
avirt-xen-Optimize-pte_flags-by-marking-it-as.patch
> > > >
> > > > make the pte_flags function (after bootup and patching with alterna=
tive asm)
> > > > look as so:
> > > >
> > > > =A0 48 89 f8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0%rd=
i,%rax
> > > > =A0 66 66 66 90 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data32 data32 xc=
hg %ax,%ax
> > > >
> > > > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very =
well on Intel
> > > > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - =
that I found out
> > > > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compi=
led in (but the tracer
> > > > is set to the default 'nop'). If I disable that specific config opt=
ion the numbers
> > > > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled)=
 on the AMD box.
> > > > Interestingly enough I only see these on AMD machines - not on the =
Intel ones.
> > > =

> > > The AMD software optimization manual says that -- at least on some
> > > chips -- too many prefixes forces the instruction decoder into a slow
> > > mode (basically microcoded) where it takes literally dozens of cycles
> > > for a single instruction.  I believe more than 2 prefixes will do
> > > this; check the manual itself for specifics.
> > =

> > I've been digging in to this during my "free" time to figure out what
> > is going on. Sadly, haven't progressed much besides writting a set of p=
atches
> > that would add the 'notrace' to the pvops calls and playing with
> > those patches.
> > =

> > In other words - still not sure what is happening.
> =

> I would like to spend some time looking into this issue as it blocks my
> project in some cases.

Ah, somebody else pinged me about this too. Let me CC them here.
> =

> I saw a temporary fix 8eaffa67b43e99ae581622c5133e20b0f48bcef1 went into =
3.3 to disable
> PAT support on dom0. May I ask what would be the recommended fix to suppo=
rt PAT on dom0? =

> Will it be a possible solution to make Xen use the same PAT settings as L=
inux? Sorry, I don't =

> know the background why Xen is doing this differently.
> =

> Suggestions?

You could use those two patches I mentioned in the thread and revert the te=
mporary fix.
That should get PAT support working - but .. that would be for your own tree
and wouldn't be in mainline.

The issues I had - with the CONFIG_FUNCTION_TRACER, I hadn't had a chance t=
o dig
deeper in it. I would recommend for you to tree a simple test-case (I used =
kernelbench)
to see if the patches cause a regression or not on baremetal.

Make sure to start the kernel in high CPU frequency (meaning the performanc=
e governor)
otherwise your results could be skewed.

Peter mentioned to me had some ideas about software PAT table lookup. I am =
not
exactly sure what he meant by that.

Just to summarize, there were two ways proposed to fix this:

 1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
     pte_val (pvops call) instead of pte_flag (native). Here is the patch:
     http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dcommitd=
iff;h=3D4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
     (no perf regressions across all platforms)

 2). Introduce a new pvops call - pte_flags, which would make pte_flags
     (which currently is doing just a bit mask) be pvops-fied.
     http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravi=
rt-xen-Introduce-pte_flags.patch
     http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravi=
rt-xen-Optimize-pte_flags-by-marking-it-as.patch
     (weird results on AMD, other platforms had no perf degradations)

  3). (not posted), was to do 2), but alter the alternative_asm and instead=
 use asm_goto to
     make the compiler use less registers and hopefully reduce the code:
     http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dshortlo=
g;h=3Drefs/heads/devel/mmu-perf
     But the results I got showed worst performance on baremetal.. which wa=
s weird?
     Perhaps it is compiler related - never got to follow up on it.


I also chatted with the core Xen hypervisor folks about adding in the conte=
xt switch code
to alter the PAT layout - but they were not keen a about it - and I am not =
sure how much
CPU cycles one loses by doing a wrmsr to the PAT register on every guest co=
ntext switch
(worst case when on has a pvops kernel and a old-style one - where the WC b=
it would differ)?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:37:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFq4-0006uH-35; Thu, 28 Jun 2012 14:36:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SkFq2-0006uC-Q4
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:36:55 +0000
Received: from [85.158.139.83:19145] by server-6.bemta-5.messagelabs.com id
	5C/8B-11348-50C6CEF4; Thu, 28 Jun 2012 14:36:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340894211!25731247!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxMjMyNg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 28 Jun 2012 14:36:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 14:36:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5SEaTIO005302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Jun 2012 14:36:30 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
	q5SEaRPq016874
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Jun 2012 14:36:28 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
	q5SEaPLi022246; Thu, 28 Jun 2012 09:36:26 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 07:36:26 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EBA6D4029B; Thu, 28 Jun 2012 10:28:36 -0400 (EDT)
Date: Thu, 28 Jun 2012 10:28:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: cyclonusj@gmail.com, marmarek@invisiblethingslab.com, hpa@zytor.com
Message-ID: <20120628142836.GE8956@phenom.dumpdata.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120627231755.GA1021@gmail.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, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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, Jun 27, 2012 at 04:17:56PM -0700, Cyclonus J wrote:
> On Thu, May 10, 2012 at 11:34:57AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 21, 2012 at 06:53:35PM -0800, Jason Garrett-Glaser wrote:
> > > On Fri, Feb 10, 2012 at 7:34 AM, Konrad Rzeszutek Wilk
> > > <konrad.wilk@oracle.com> wrote:
> > > > The attached patch fixes RH BZ #742032, #787403, and #745574
> > > > and touch x86 subsystem.
> > > >
> > > > The patch description gives a very good overview of the problem and
> > > > one solution. The one solution it chooses is not the most architect=
urally
> > > > sound but it does not cause performance degradation. If this your
> > > > first time reading this, please read the patch first and then come =
back to
> > > > this cover letter as I've some perf numbers and more detailed expla=
nation here.
> > > >
> > > > A bit of overview of the __page_change_attr_set_clr:
> > > >
> > > > Its purpose is to change page attributes from one type to another.
> > > > It is important to understand that the entrance that code:
> > > > __page_change_attr_set_clr is guarded by cpa_lock spin-lock - which=
 makes
> > > > that whole code be single threaded.
> > > >
> > > > Albeit it seems that if debug mode is turned on, it can run in para=
llel. The
> > > > effect of using the posted patch is that __page_change_attr_set_clr=
() will be
> > > > affected when we change caching attributes on 4KB pages and/or the =
NX flag.
> > > >
> > > > The execution of __page_change_attr_set_clr is concentrated in
> > > > (looked for ioremap_* and set_pages_*):
> > > > =A0- during bootup ("Write protecting the ..")
> > > > =A0- suspend/resume and graphic adapters evicting their buffers fro=
m the card
> > > > =A0 to RAM (which is usually done during suspend but can be done vi=
a the
> > > > =A0 'evict' attribute in debugfs)
> > > > =A0- when setting the memory for the cursor (AGP cards using i8xx c=
hipset) -
> > > > =A0 done during bootup and startup of Xserver.
> > > > =A0- setting up memory for Intel GTT scratch (i9xx) page (done duri=
ng bootup)
> > > > =A0- payload (purgatory code) for kexec (done during kexec -l).
> > > > =A0- ioremap_* during PCI devices load - InfiniBand and video cards=
 like to use
> > > > =A0 ioremap_wc.
> > > > =A0- Intel, radeon, nouveau running into memory pressure and evicti=
ng pages from
> > > > =A0 their GEM/TTM pool (once an hour or so if compiling a lot with =
only 4GB).
> > > >
> > > > These are the cases I found when running on baremetal (and Xen) usi=
ng a normal
> > > > Fedora Core 16 distro.
> > > >
> > > > The alternate solution to the problem I am trying to solve, which i=
s much
> > > > more architecturally sound (but has some perf disadvantages) is to =
wrap
> > > > the pte_flags with paravirt call everywhere. For that these patches=
 two patches:
> > > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-par=
avirt-xen-Introduce-pte_flags.patch
> > > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-par=
avirt-xen-Optimize-pte_flags-by-marking-it-as.patch
> > > >
> > > > make the pte_flags function (after bootup and patching with alterna=
tive asm)
> > > > look as so:
> > > >
> > > > =A0 48 89 f8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0%rd=
i,%rax
> > > > =A0 66 66 66 90 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data32 data32 xc=
hg %ax,%ax
> > > >
> > > > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very =
well on Intel
> > > > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - =
that I found out
> > > > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compi=
led in (but the tracer
> > > > is set to the default 'nop'). If I disable that specific config opt=
ion the numbers
> > > > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled)=
 on the AMD box.
> > > > Interestingly enough I only see these on AMD machines - not on the =
Intel ones.
> > > =

> > > The AMD software optimization manual says that -- at least on some
> > > chips -- too many prefixes forces the instruction decoder into a slow
> > > mode (basically microcoded) where it takes literally dozens of cycles
> > > for a single instruction.  I believe more than 2 prefixes will do
> > > this; check the manual itself for specifics.
> > =

> > I've been digging in to this during my "free" time to figure out what
> > is going on. Sadly, haven't progressed much besides writting a set of p=
atches
> > that would add the 'notrace' to the pvops calls and playing with
> > those patches.
> > =

> > In other words - still not sure what is happening.
> =

> I would like to spend some time looking into this issue as it blocks my
> project in some cases.

Ah, somebody else pinged me about this too. Let me CC them here.
> =

> I saw a temporary fix 8eaffa67b43e99ae581622c5133e20b0f48bcef1 went into =
3.3 to disable
> PAT support on dom0. May I ask what would be the recommended fix to suppo=
rt PAT on dom0? =

> Will it be a possible solution to make Xen use the same PAT settings as L=
inux? Sorry, I don't =

> know the background why Xen is doing this differently.
> =

> Suggestions?

You could use those two patches I mentioned in the thread and revert the te=
mporary fix.
That should get PAT support working - but .. that would be for your own tree
and wouldn't be in mainline.

The issues I had - with the CONFIG_FUNCTION_TRACER, I hadn't had a chance t=
o dig
deeper in it. I would recommend for you to tree a simple test-case (I used =
kernelbench)
to see if the patches cause a regression or not on baremetal.

Make sure to start the kernel in high CPU frequency (meaning the performanc=
e governor)
otherwise your results could be skewed.

Peter mentioned to me had some ideas about software PAT table lookup. I am =
not
exactly sure what he meant by that.

Just to summarize, there were two ways proposed to fix this:

 1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
     pte_val (pvops call) instead of pte_flag (native). Here is the patch:
     http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dcommitd=
iff;h=3D4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
     (no perf regressions across all platforms)

 2). Introduce a new pvops call - pte_flags, which would make pte_flags
     (which currently is doing just a bit mask) be pvops-fied.
     http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravi=
rt-xen-Introduce-pte_flags.patch
     http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravi=
rt-xen-Optimize-pte_flags-by-marking-it-as.patch
     (weird results on AMD, other platforms had no perf degradations)

  3). (not posted), was to do 2), but alter the alternative_asm and instead=
 use asm_goto to
     make the compiler use less registers and hopefully reduce the code:
     http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dshortlo=
g;h=3Drefs/heads/devel/mmu-perf
     But the results I got showed worst performance on baremetal.. which wa=
s weird?
     Perhaps it is compiler related - never got to follow up on it.


I also chatted with the core Xen hypervisor folks about adding in the conte=
xt switch code
to alter the PAT layout - but they were not keen a about it - and I am not =
sure how much
CPU cycles one loses by doing a wrmsr to the PAT register on every guest co=
ntext switch
(worst case when on has a pvops kernel and a old-style one - where the WC b=
it would differ)?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFvl-00078i-17; Thu, 28 Jun 2012 14:42:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkFvj-00078c-HS
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:42:47 +0000
Received: from [193.109.254.147:46298] by server-1.bemta-14.messagelabs.com id
	49/E9-24612-66D6CEF4; Thu, 28 Jun 2012 14:42:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340894562!9018405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8601 invoked from network); 28 Jun 2012 14:42:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:42:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:42:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:42:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFvd-0000ux-PK; Thu, 28 Jun 2012 14:42:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkFvd-0001do-AI;
	Thu, 28 Jun 2012 15:42:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28000.665737.623933@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:42:40 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1206271625280.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
	<1340809143.29172.40.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206271625280.27860@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] libxl: disable msitranslate by default"):
> On Wed, 27 Jun 2012, Ian Campbell wrote:
> > I saw a qemu (trad) patch and I see I've got an xl patch further down my
> > inbox. There is no sequencing requirement here, is there?
> 
> nope

Thanks.

> > I wonder if this field shouyld be a defbool instead of just a bool? I
> > don't recall why I didn't transition it when I made the defbool stuff.
> 
> I think it could be a defbool

I'll apply the patch as-is but perhaps a followup to change it to a
defbool would be good ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFvl-00078i-17; Thu, 28 Jun 2012 14:42:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkFvj-00078c-HS
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:42:47 +0000
Received: from [193.109.254.147:46298] by server-1.bemta-14.messagelabs.com id
	49/E9-24612-66D6CEF4; Thu, 28 Jun 2012 14:42:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1340894562!9018405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8601 invoked from network); 28 Jun 2012 14:42:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:42:43 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:42:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:42:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkFvd-0000ux-PK; Thu, 28 Jun 2012 14:42:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkFvd-0001do-AI;
	Thu, 28 Jun 2012 15:42:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28000.665737.623933@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:42:40 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1206271625280.27860@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
	<1340809143.29172.40.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206271625280.27860@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate by default
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("Re: [Xen-devel] libxl: disable msitranslate by default"):
> On Wed, 27 Jun 2012, Ian Campbell wrote:
> > I saw a qemu (trad) patch and I see I've got an xl patch further down my
> > inbox. There is no sequencing requirement here, is there?
> 
> nope

Thanks.

> > I wonder if this field shouyld be a defbool instead of just a bool? I
> > don't recall why I didn't transition it when I made the defbool stuff.
> 
> I think it could be a defbool

I'll apply the patch as-is but perhaps a followup to change it to a
defbool would be good ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:43: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 1SkFvv-00079N-E9; Thu, 28 Jun 2012 14:42:59 +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 1SkFvu-000793-Gr
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:42:58 +0000
Received: from [85.158.139.83:19827] by server-6.bemta-5.messagelabs.com id
	17/39-11348-17D6CEF4; Thu, 28 Jun 2012 14:42:57 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340894575!18746351!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8385 invoked from network); 28 Jun 2012 14:42:56 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 14:42:56 -0000
Received: from hanvin-mobl6.amr.corp.intel.com (jfdmzpr05-ext.jf.intel.com
	[134.134.139.74]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q5SEgIgU000845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Thu, 28 Jun 2012 07:42:19 -0700
Message-ID: <4FEC6D44.8080807@zytor.com>
Date: Thu, 28 Jun 2012 07:42:12 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
In-Reply-To: <20120628142836.GE8956@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.2
Cc: xen-devel@lists.xensource.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, cyclonusj@gmail.com
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
> 
> Peter mentioned to me had some ideas about software PAT table lookup. I am not
> exactly sure what he meant by that.
> 

I could see the kernel have programmable PAT values rather than fixed if
and only if it can be showed to have no measurable performance impact.

> Just to summarize, there were two ways proposed to fix this:
> 
>  1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
>      pte_val (pvops call) instead of pte_flag (native). Here is the patch:
>      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
>      (no perf regressions across all platforms)
> 
>  2). Introduce a new pvops call - pte_flags, which would make pte_flags
>      (which currently is doing just a bit mask) be pvops-fied.
>      http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravirt-xen-Introduce-pte_flags.patch
>      http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch
>      (weird results on AMD, other platforms had no perf degradations)
> 
>   3). (not posted), was to do 2), but alter the alternative_asm and instead use asm_goto to
>      make the compiler use less registers and hopefully reduce the code:
>      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/mmu-perf
>      But the results I got showed worst performance on baremetal.. which was weird?
>      Perhaps it is compiler related - never got to follow up on it.
> 

OK, let me be blunt: I will unconditionally veto any of these.

> 
> I also chatted with the core Xen hypervisor folks about adding in the context switch code
> to alter the PAT layout - but they were not keen a about it - and I am not sure how much
> CPU cycles one loses by doing a wrmsr to the PAT register on every guest context switch
> (worst case when on has a pvops kernel and a old-style one - where the WC bit would differ)?
> 

And you're comparing that to a bunch of new pvops calls?  The discussion
shouldn't even have started until you had ruled out this solution and
had data to show it.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:43: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 1SkFvv-00079N-E9; Thu, 28 Jun 2012 14:42:59 +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 1SkFvu-000793-Gr
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:42:58 +0000
Received: from [85.158.139.83:19827] by server-6.bemta-5.messagelabs.com id
	17/39-11348-17D6CEF4; Thu, 28 Jun 2012 14:42:57 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340894575!18746351!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8385 invoked from network); 28 Jun 2012 14:42:56 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 14:42:56 -0000
Received: from hanvin-mobl6.amr.corp.intel.com (jfdmzpr05-ext.jf.intel.com
	[134.134.139.74]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q5SEgIgU000845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Thu, 28 Jun 2012 07:42:19 -0700
Message-ID: <4FEC6D44.8080807@zytor.com>
Date: Thu, 28 Jun 2012 07:42:12 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
In-Reply-To: <20120628142836.GE8956@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.2
Cc: xen-devel@lists.xensource.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, cyclonusj@gmail.com
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
> 
> Peter mentioned to me had some ideas about software PAT table lookup. I am not
> exactly sure what he meant by that.
> 

I could see the kernel have programmable PAT values rather than fixed if
and only if it can be showed to have no measurable performance impact.

> Just to summarize, there were two ways proposed to fix this:
> 
>  1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
>      pte_val (pvops call) instead of pte_flag (native). Here is the patch:
>      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
>      (no perf regressions across all platforms)
> 
>  2). Introduce a new pvops call - pte_flags, which would make pte_flags
>      (which currently is doing just a bit mask) be pvops-fied.
>      http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravirt-xen-Introduce-pte_flags.patch
>      http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch
>      (weird results on AMD, other platforms had no perf degradations)
> 
>   3). (not posted), was to do 2), but alter the alternative_asm and instead use asm_goto to
>      make the compiler use less registers and hopefully reduce the code:
>      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/mmu-perf
>      But the results I got showed worst performance on baremetal.. which was weird?
>      Perhaps it is compiler related - never got to follow up on it.
> 

OK, let me be blunt: I will unconditionally veto any of these.

> 
> I also chatted with the core Xen hypervisor folks about adding in the context switch code
> to alter the PAT layout - but they were not keen a about it - and I am not sure how much
> CPU cycles one loses by doing a wrmsr to the PAT register on every guest context switch
> (worst case when on has a pvops kernel and a old-style one - where the WC bit would differ)?
> 

And you're comparing that to a bunch of new pvops calls?  The discussion
shouldn't even have started until you had ruled out this solution and
had data to show it.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:44:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFx9-0007Gw-Tb; Thu, 28 Jun 2012 14:44: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 1SkFx8-0007Gj-ES
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:44:14 +0000
Received: from [85.158.143.35:30846] by server-1.bemta-4.messagelabs.com id
	0B/5A-24392-DBD6CEF4; Thu, 28 Jun 2012 14:44:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340894653!6910136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6831 invoked from network); 28 Jun 2012 14:44:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:44:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:44:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:44:12 +0100
Message-ID: <1340894650.10942.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 15:44:10 +0100
In-Reply-To: <20460.26922.21629.642044@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
	<1340891415.10942.53.camel@zakaz.uk.xensource.com>
	<20460.26922.21629.642044@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 15:24 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH v6 00/21] libxl: domain save/restore: run in a separate process"):
> > Does this mean this series is now ready to go in?
> 
> I think so.  I'm just giving Shriram a chance to object.

OK.

> > I did wonder when I saw the incremental patch if some of those internal
> > callback pointers could perhaps be properly typed instead of void
> > (because they all end up taking the same pointer type), but lets not
> > worry about that here.
> 
> The void*'s come from the libxc API.

Ah, I thought they were internal, nevermind.

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:44:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkFx9-0007Gw-Tb; Thu, 28 Jun 2012 14:44: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 1SkFx8-0007Gj-ES
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:44:14 +0000
Received: from [85.158.143.35:30846] by server-1.bemta-4.messagelabs.com id
	0B/5A-24392-DBD6CEF4; Thu, 28 Jun 2012 14:44:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340894653!6910136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6831 invoked from network); 28 Jun 2012 14:44:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:44:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:44:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:44:12 +0100
Message-ID: <1340894650.10942.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 15:44:10 +0100
In-Reply-To: <20460.26922.21629.642044@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
	<1340891415.10942.53.camel@zakaz.uk.xensource.com>
	<20460.26922.21629.642044@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
 a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 15:24 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH v6 00/21] libxl: domain save/restore: run in a separate process"):
> > Does this mean this series is now ready to go in?
> 
> I think so.  I'm just giving Shriram a chance to object.

OK.

> > I did wonder when I saw the incremental patch if some of those internal
> > callback pointers could perhaps be properly typed instead of void
> > (because they all end up taking the same pointer type), but lets not
> > worry about that here.
> 
> The void*'s come from the libxc API.

Ah, I thought they were internal, nevermind.

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:48:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:48: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 1SkG0l-0007Wn-Hd; Thu, 28 Jun 2012 14:47: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 1SkG0j-0007Wb-Ob
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:47:57 +0000
Received: from [85.158.143.35:58589] by server-2.bemta-4.messagelabs.com id
	05/68-17938-D9E6CEF4; Thu, 28 Jun 2012 14:47:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340894872!15451001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22450 invoked from network); 28 Jun 2012 14:47:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:47:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:47:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:47:51 +0100
Message-ID: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 15:47:50 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/21 V3] arm: boot a dom1 to "Calibrating delay
 loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bunch of this series went in in the last batch and Tim & Stefano have
now acked a bunch more.

As before, in the list:
        An "A" in the list below indicates that I think the patch has
        sufficient Acked-by's to be committed (assuming the
        prerequisites can go in).

        An "X" means I don't consider this patch for committing.

        A "!" means I didn't consider review comments yet.

Once #06 has an ack I intend to commit #01..#15 and #21.

#21 isn't an ARM patch but has acks from both Keir and Jan.

#06 derives from "use interrupt safe spin locks in vgic_vcpu_inject_irq"
but has enough new stuff that I didn't feel comfortable carrying
Stefano's ack over.

#18 requires #17 which I haven't addressed review on yet and which
likely requires considerable cleanup anyhow.

A     01 arm: allow p2m to be created with specific MATTR.
A     02 arm: implement vpl011 (UART) emulator.
A     03 arm: implement vcpu_show_execution_state
A     04 arm: use correct attributes for mappings in copy_from_paddr()
A     05 arm: split pending SPIs (global) out from pending PPIs and SGIs (per CPU)
      06 arm: make vgic lock safe for use in interrupt context.
A     07 arm: map GICV in all domains, not just dom0.
A     08 arm: enable data-cache at the same time as enabling the MMU, not before
A     09 arm: Upgrade guest barriers to Outer-Shareable. Enable Protected Table Walk.
A     10 arm: gic.lock can be taken in interrupt context, so lock appropriately.
A     11 arm: context switch virtual timer registers
A     12 arm: the hyp timer seems to work in newer model versions, default to using it.
A     13 arm: unwind allocations etc on arch_domain_create_failure
A     14 arm: move PSR flag definitions into interface, for tools use.
A     15 arm: fix typo s/approprately/appropriately/g
 X!   16 HACK: arm: initial XENMAPSPACE_gmfn_foreign
  !   17 libxc: add ARM support to xc_dom (PV domain building)
A     18 arm: implement VGCF_online
 X!   19 HACK: add simple xcbuild
 X!   20 HACK: arm: disable hypercall continuations.
A     21 xen: add assertion in default_vcpu0_location to protect against broken masks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:48:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:48: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 1SkG0l-0007Wn-Hd; Thu, 28 Jun 2012 14:47: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 1SkG0j-0007Wb-Ob
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:47:57 +0000
Received: from [85.158.143.35:58589] by server-2.bemta-4.messagelabs.com id
	05/68-17938-D9E6CEF4; Thu, 28 Jun 2012 14:47:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340894872!15451001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22450 invoked from network); 28 Jun 2012 14:47:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:47:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:47:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:47:51 +0100
Message-ID: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 15:47:50 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/21 V3] arm: boot a dom1 to "Calibrating delay
 loop" then hang
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bunch of this series went in in the last batch and Tim & Stefano have
now acked a bunch more.

As before, in the list:
        An "A" in the list below indicates that I think the patch has
        sufficient Acked-by's to be committed (assuming the
        prerequisites can go in).

        An "X" means I don't consider this patch for committing.

        A "!" means I didn't consider review comments yet.

Once #06 has an ack I intend to commit #01..#15 and #21.

#21 isn't an ARM patch but has acks from both Keir and Jan.

#06 derives from "use interrupt safe spin locks in vgic_vcpu_inject_irq"
but has enough new stuff that I didn't feel comfortable carrying
Stefano's ack over.

#18 requires #17 which I haven't addressed review on yet and which
likely requires considerable cleanup anyhow.

A     01 arm: allow p2m to be created with specific MATTR.
A     02 arm: implement vpl011 (UART) emulator.
A     03 arm: implement vcpu_show_execution_state
A     04 arm: use correct attributes for mappings in copy_from_paddr()
A     05 arm: split pending SPIs (global) out from pending PPIs and SGIs (per CPU)
      06 arm: make vgic lock safe for use in interrupt context.
A     07 arm: map GICV in all domains, not just dom0.
A     08 arm: enable data-cache at the same time as enabling the MMU, not before
A     09 arm: Upgrade guest barriers to Outer-Shareable. Enable Protected Table Walk.
A     10 arm: gic.lock can be taken in interrupt context, so lock appropriately.
A     11 arm: context switch virtual timer registers
A     12 arm: the hyp timer seems to work in newer model versions, default to using it.
A     13 arm: unwind allocations etc on arch_domain_create_failure
A     14 arm: move PSR flag definitions into interface, for tools use.
A     15 arm: fix typo s/approprately/appropriately/g
 X!   16 HACK: arm: initial XENMAPSPACE_gmfn_foreign
  !   17 libxc: add ARM support to xc_dom (PV domain building)
A     18 arm: implement VGCF_online
 X!   19 HACK: add simple xcbuild
 X!   20 HACK: arm: disable hypercall continuations.
A     21 xen: add assertion in default_vcpu0_location to protect against broken masks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkG3K-0007fO-3w; Thu, 28 Jun 2012 14:50: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 1SkG3J-0007fC-99
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:50:37 +0000
Received: from [85.158.143.35:17605] by server-3.bemta-4.messagelabs.com id
	0C/6C-05808-C3F6CEF4; Thu, 28 Jun 2012 14:50:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340895034!15451685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4018 invoked from network); 28 Jun 2012 14:50:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:50:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG3F-0000xX-Q0; Thu, 28 Jun 2012 14:50:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG3F-00035t-P2;
	Thu, 28 Jun 2012 15:50:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28473.761058.752184@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:33 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FEB0D0E.8010509@eu.citrix.com>
References: <alpine.DEB.2.02.1206271436320.27860@kaball.uk.xensource.com>
	<4FEB0D0E.8010509@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate
	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

George Dunlap writes ("Re: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate by default"):
> On 27/06/12 14:39, Stefano Stabellini wrote:
> > msitranslate is known to cause problems with some device drivers,
> > because it sets the real device in MSI mode while making the guest think
> > is actually in legacy interrupts mode. Some drivers are able to spot this
> > inconsistency and break (Nvidia drivers for example).
> >
> > Disable the option by default.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> This patch has been in XenServer for two releases now.
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkG3K-0007fO-3w; Thu, 28 Jun 2012 14:50: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 1SkG3J-0007fC-99
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:50:37 +0000
Received: from [85.158.143.35:17605] by server-3.bemta-4.messagelabs.com id
	0C/6C-05808-C3F6CEF4; Thu, 28 Jun 2012 14:50:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340895034!15451685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4018 invoked from network); 28 Jun 2012 14:50:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:50:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG3F-0000xX-Q0; Thu, 28 Jun 2012 14:50:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG3F-00035t-P2;
	Thu, 28 Jun 2012 15:50:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28473.761058.752184@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:33 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FEB0D0E.8010509@eu.citrix.com>
References: <alpine.DEB.2.02.1206271436320.27860@kaball.uk.xensource.com>
	<4FEB0D0E.8010509@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate
	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

George Dunlap writes ("Re: [Xen-devel] [PATCH] qemu-traditional: disable msitranslate by default"):
> On 27/06/12 14:39, Stefano Stabellini wrote:
> > msitranslate is known to cause problems with some device drivers,
> > because it sets the real device in MSI mode while making the guest think
> > is actually in legacy interrupts mode. Some drivers are able to spot this
> > inconsistency and break (Nvidia drivers for example).
> >
> > Disable the option by default.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> This patch has been in XenServer for two releases now.
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkG3L-0007fc-Gj; Thu, 28 Jun 2012 14:50:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG3J-0007fC-Tk
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:50:38 +0000
Received: from [85.158.143.35:56437] by server-3.bemta-4.messagelabs.com id
	F4/7C-05808-D3F6CEF4; Thu, 28 Jun 2012 14:50:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340895028!7170793!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20747 invoked from network); 28 Jun 2012 14:50:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG3E-0000xU-Oi; Thu, 28 Jun 2012 14:50:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG3E-00035m-Nh;
	Thu, 28 Jun 2012 15:50:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28472.721046.121709@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:32 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340809176.29172.41.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1206271452190.27860@kaball.uk.xensource.com>
	<1340809176.29172.41.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: do not ignore the per-device
 msitranslate and power_mgmt opts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: do not ignore the per-device msitranslate and power_mgmt opts"):
> On Wed, 2012-06-27 at 14:53 +0100, Stefano Stabellini wrote:
> > Do not ignore the per-device msitranslate and power_mgmt options: they
> > need to be appended to the bdf.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkG3L-0007fc-Gj; Thu, 28 Jun 2012 14:50:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG3J-0007fC-Tk
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:50:38 +0000
Received: from [85.158.143.35:56437] by server-3.bemta-4.messagelabs.com id
	F4/7C-05808-D3F6CEF4; Thu, 28 Jun 2012 14:50:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340895028!7170793!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20747 invoked from network); 28 Jun 2012 14:50:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG3E-0000xU-Oi; Thu, 28 Jun 2012 14:50:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG3E-00035m-Nh;
	Thu, 28 Jun 2012 15:50:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28472.721046.121709@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:32 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340809176.29172.41.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1206271452190.27860@kaball.uk.xensource.com>
	<1340809176.29172.41.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: do not ignore the per-device
 msitranslate and power_mgmt opts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: do not ignore the per-device msitranslate and power_mgmt opts"):
> On Wed, 2012-06-27 at 14:53 +0100, Stefano Stabellini wrote:
> > Do not ignore the per-device msitranslate and power_mgmt options: they
> > need to be appended to the bdf.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkG3L-0007fl-SN; Thu, 28 Jun 2012 14:50:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG3K-0007fJ-Eq
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:50:38 +0000
Received: from [85.158.143.35:17704] by server-1.bemta-4.messagelabs.com id
	A5/66-24392-D3F6CEF4; Thu, 28 Jun 2012 14:50:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340895028!7170793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20469 invoked from network); 28 Jun 2012 14:50:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:50:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG39-0000xQ-QW; Thu, 28 Jun 2012 14:50:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG39-00035g-PQ;
	Thu, 28 Jun 2012 15:50:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28467.772367.167343@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:27 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340809143.29172.40.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
	<1340809143.29172.40.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate 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

Ian Campbell writes ("Re: [Xen-devel] libxl: disable msitranslate by default"):
> On Wed, 2012-06-27 at 14:56 +0100, Stefano Stabellini wrote:
> > msitranslate is known to cause problems with some device drivers,
> > because it sets the real device in MSI mode while making the guest think
> > is actually in legacy interrupts mode. Some drivers are able to spot this
> > inconsistency and break (Nvidia drivers for example).
> > 
> > Disable msitranslate by default.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14: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 1SkG3L-0007fl-SN; Thu, 28 Jun 2012 14:50:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG3K-0007fJ-Eq
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:50:38 +0000
Received: from [85.158.143.35:17704] by server-1.bemta-4.messagelabs.com id
	A5/66-24392-D3F6CEF4; Thu, 28 Jun 2012 14:50:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340895028!7170793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20469 invoked from network); 28 Jun 2012 14:50:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:50:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG39-0000xQ-QW; Thu, 28 Jun 2012 14:50:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG39-00035g-PQ;
	Thu, 28 Jun 2012 15:50:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28467.772367.167343@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:27 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340809143.29172.40.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1206271454210.27860@kaball.uk.xensource.com>
	<1340809143.29172.40.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: disable msitranslate 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

Ian Campbell writes ("Re: [Xen-devel] libxl: disable msitranslate by default"):
> On Wed, 2012-06-27 at 14:56 +0100, Stefano Stabellini wrote:
> > msitranslate is known to cause problems with some device drivers,
> > because it sets the real device in MSI mode while making the guest think
> > is actually in legacy interrupts mode. Some drivers are able to spot this
> > inconsistency and break (Nvidia drivers for example).
> > 
> > Disable msitranslate by default.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:51:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkG46-0007o7-As; Thu, 28 Jun 2012 14:51:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG45-0007no-0H
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:51:25 +0000
Received: from [85.158.143.35:2233] by server-1.bemta-4.messagelabs.com id
	BB/D7-24392-C6F6CEF4; Thu, 28 Jun 2012 14:51:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340895082!16132661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2441 invoked from network); 28 Jun 2012 14:51:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:51:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG3G-0000xb-T6; Thu, 28 Jun 2012 14:50:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG3G-00035x-S4;
	Thu, 28 Jun 2012 15:50:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28474.857041.182937@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340726773.3832.162.camel@zakaz.uk.xensource.com>
References: <e764d52618f736bdc58a.1340726463@Solace>
	<1340726773.3832.162.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: document the memory ownership of
 some 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: document the memory ownership of some functions"):
> On Tue, 2012-06-26 at 17:01 +0100, Dario Faggioli wrote:
> > Specifying they allocate dynamic memory that needs to be explicitly freed.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:51:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkG46-0007o7-As; Thu, 28 Jun 2012 14:51:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG45-0007no-0H
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 14:51:25 +0000
Received: from [85.158.143.35:2233] by server-1.bemta-4.messagelabs.com id
	BB/D7-24392-C6F6CEF4; Thu, 28 Jun 2012 14:51:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340895082!16132661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2441 invoked from network); 28 Jun 2012 14:51:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:51:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:50:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:50:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG3G-0000xb-T6; Thu, 28 Jun 2012 14:50:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG3G-00035x-S4;
	Thu, 28 Jun 2012 15:50:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28474.857041.182937@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:50:34 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340726773.3832.162.camel@zakaz.uk.xensource.com>
References: <e764d52618f736bdc58a.1340726463@Solace>
	<1340726773.3832.162.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: document the memory ownership of
 some 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: document the memory ownership of some functions"):
> On Tue, 2012-06-26 at 17:01 +0100, Dario Faggioli wrote:
> > Specifying they allocate dynamic memory that needs to be explicitly freed.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkG6l-0008Ao-35; Thu, 28 Jun 2012 14:54:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG6j-0008AZ-R3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:54:10 +0000
Received: from [85.158.138.51:7598] by server-9.bemta-3.messagelabs.com id
	2C/20-10419-1107CEF4; Thu, 28 Jun 2012 14:54:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340895247!28920752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21996 invoked from network); 28 Jun 2012 14:54:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:54:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:54:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:54:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG6g-0000yw-FA; Thu, 28 Jun 2012 14:54:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG6f-00020O-O9;
	Thu, 28 Jun 2012 15:54:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28683.727280.950983@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:54:03 +0100
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap
	with	specific 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

Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> Change from v2:
> Rebase on top of latest head.
> 
> Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> number of physical cpus. In some place, we may want to allocate
> specific size of cpumap.  This patch allow to pass a argument to
> specific the size that you want to allocate. If pass 0, it means the
> size is equal to number of physical cpus.

Isn't this same objective achieved in a more general way by Dario's
  [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap
?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkG6l-0008Ao-35; Thu, 28 Jun 2012 14:54:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkG6j-0008AZ-R3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:54:10 +0000
Received: from [85.158.138.51:7598] by server-9.bemta-3.messagelabs.com id
	2C/20-10419-1107CEF4; Thu, 28 Jun 2012 14:54:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340895247!28920752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21996 invoked from network); 28 Jun 2012 14:54:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:54:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13272954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:54:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 15:54:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkG6g-0000yw-FA; Thu, 28 Jun 2012 14:54:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkG6f-00020O-O9;
	Thu, 28 Jun 2012 15:54:05 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.28683.727280.950983@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 15:54:03 +0100
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap
	with	specific 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

Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> Change from v2:
> Rebase on top of latest head.
> 
> Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> number of physical cpus. In some place, we may want to allocate
> specific size of cpumap.  This patch allow to pass a argument to
> specific the size that you want to allocate. If pass 0, it means the
> size is equal to number of physical cpus.

Isn't this same objective achieved in a more general way by Dario's
  [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap
?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:59:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:59: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 1SkGBQ-0008Ux-3T; Thu, 28 Jun 2012 14:59: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 1SkGBO-0008Uq-D3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:58:58 +0000
Received: from [85.158.138.51:53367] by server-4.bemta-3.messagelabs.com id
	96/BA-17105-1317CEF4; Thu, 28 Jun 2012 14:58:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340895536!30088689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17079 invoked from network); 28 Jun 2012 14:58:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:58:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:58:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:58:56 +0100
Message-ID: <1340895534.10942.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 15:58:54 +0100
In-Reply-To: <20460.28683.727280.950983@mariner.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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 Thu, 2012-06-28 at 15:54 +0100, Ian Jackson wrote:
> Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> > Change from v2:
> > Rebase on top of latest head.
> > 
> > Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> > number of physical cpus. In some place, we may want to allocate
> > specific size of cpumap.  This patch allow to pass a argument to
> > specific the size that you want to allocate. If pass 0, it means the
> > size is equal to number of physical cpus.
> 
> Isn't this same objective achieved in a more general way by Dario's
>   [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap

Didn't Dario's patch build on this one, or perhaps incorporate it?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 14:59:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 14:59: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 1SkGBQ-0008Ux-3T; Thu, 28 Jun 2012 14:59: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 1SkGBO-0008Uq-D3
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 14:58:58 +0000
Received: from [85.158.138.51:53367] by server-4.bemta-3.messagelabs.com id
	96/BA-17105-1317CEF4; Thu, 28 Jun 2012 14:58:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340895536!30088689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17079 invoked from network); 28 Jun 2012 14:58:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 14:58:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 14:58:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 15:58:56 +0100
Message-ID: <1340895534.10942.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 15:58:54 +0100
In-Reply-To: <20460.28683.727280.950983@mariner.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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 Thu, 2012-06-28 at 15:54 +0100, Ian Jackson wrote:
> Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> > Change from v2:
> > Rebase on top of latest head.
> > 
> > Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> > number of physical cpus. In some place, we may want to allocate
> > specific size of cpumap.  This patch allow to pass a argument to
> > specific the size that you want to allocate. If pass 0, it means the
> > size is equal to number of physical cpus.
> 
> Isn't this same objective achieved in a more general way by Dario's
>   [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap

Didn't Dario's patch build on this one, or perhaps incorporate it?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:00: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 1SkGDA-0000Bx-KV; Thu, 28 Jun 2012 15:00: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 1SkGD9-0000Br-IN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:00:47 +0000
Received: from [85.158.143.99:60638] by server-3.bemta-4.messagelabs.com id
	BB/9F-05808-E917CEF4; Thu, 28 Jun 2012 15:00:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340895637!19981248!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15120 invoked from network); 28 Jun 2012 15:00:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:00:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:00:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 16:00:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkGCz-000110-Hk; Thu, 28 Jun 2012 15:00:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkGCz-00081L-FK;
	Thu, 28 Jun 2012 16:00:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.29077.462105.714019@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 16:00:37 +0100
To: <xen-devel@lists.xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] hgignore/gitignore: add
	xen/arch/x86/boot/reloc.bin, .lnk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 just pushed the patch below.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1340895564 -3600
# Node ID 39b056330de08c3d79cd000c340a7de39c0940d6
# Parent  e541c488a4eef80947a5f5b49696fc57ad4e3497
hgignore/gitignore: add xen/arch/x86/boot/reloc.bin, .lnk

25479:61dfb3da56b0 added a .PRECIOUS which causes these files to be
left over more often.  They should have been ignored already, though.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e541c488a4ee -r 39b056330de0 .gitignore
--- a/.gitignore	Thu Jun 28 15:49:53 2012 +0100
+++ b/.gitignore	Thu Jun 28 15:59:24 2012 +0100
@@ -296,6 +296,8 @@ 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
diff -r e541c488a4ee -r 39b056330de0 .hgignore
--- a/.hgignore	Thu Jun 28 15:49:53 2012 +0100
+++ b/.hgignore	Thu Jun 28 15:59:24 2012 +0100
@@ -322,7 +322,9 @@
 ^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\.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-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:00: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 1SkGDA-0000Bx-KV; Thu, 28 Jun 2012 15:00: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 1SkGD9-0000Br-IN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:00:47 +0000
Received: from [85.158.143.99:60638] by server-3.bemta-4.messagelabs.com id
	BB/9F-05808-E917CEF4; Thu, 28 Jun 2012 15:00:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340895637!19981248!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15120 invoked from network); 28 Jun 2012 15:00:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:00:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:00:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 16:00:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkGCz-000110-Hk; Thu, 28 Jun 2012 15:00:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkGCz-00081L-FK;
	Thu, 28 Jun 2012 16:00:37 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.29077.462105.714019@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 16:00:37 +0100
To: <xen-devel@lists.xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] hgignore/gitignore: add
	xen/arch/x86/boot/reloc.bin, .lnk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 just pushed the patch below.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1340895564 -3600
# Node ID 39b056330de08c3d79cd000c340a7de39c0940d6
# Parent  e541c488a4eef80947a5f5b49696fc57ad4e3497
hgignore/gitignore: add xen/arch/x86/boot/reloc.bin, .lnk

25479:61dfb3da56b0 added a .PRECIOUS which causes these files to be
left over more often.  They should have been ignored already, though.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e541c488a4ee -r 39b056330de0 .gitignore
--- a/.gitignore	Thu Jun 28 15:49:53 2012 +0100
+++ b/.gitignore	Thu Jun 28 15:59:24 2012 +0100
@@ -296,6 +296,8 @@ 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
diff -r e541c488a4ee -r 39b056330de0 .hgignore
--- a/.hgignore	Thu Jun 28 15:49:53 2012 +0100
+++ b/.hgignore	Thu Jun 28 15:59:24 2012 +0100
@@ -322,7 +322,9 @@
 ^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\.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-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIT-0000ew-0p; Thu, 28 Jun 2012 15:06:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGIR-0000eQ-Sr
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:16 +0000
Received: from [85.158.143.99:5324] by server-3.bemta-4.messagelabs.com id
	F3/7A-05808-7E27CEF4; Thu, 28 Jun 2012 15:06:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30677 invoked from network); 28 Jun 2012 15:06:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385346"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Jx;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:52 +0000
Message-ID: <1340894890-4369-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/21] arm: use correct attributes for mappings
	in copy_from_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

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/setup.h |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..2d56130 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, attrindx);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d6c0178..fd70553 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..6433b4e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIT-0000ew-0p; Thu, 28 Jun 2012 15:06:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGIR-0000eQ-Sr
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:16 +0000
Received: from [85.158.143.99:5324] by server-3.bemta-4.messagelabs.com id
	F3/7A-05808-7E27CEF4; Thu, 28 Jun 2012 15:06:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30677 invoked from network); 28 Jun 2012 15:06:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385346"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Jx;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:52 +0000
Message-ID: <1340894890-4369-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/21] arm: use correct attributes for mappings
	in copy_from_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

The DTB is in RAM (hence bufferable), kernel is in flash and therefor requires
a device type mapping (hence dev shared).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c       |    8 ++++----
 xen/arch/arm/setup.c        |    2 +-
 xen/include/asm-arm/setup.h |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 130d488..2d56130 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -39,7 +39,7 @@ struct minimal_dtb_header {
  * @paddr: source physical address
  * @len: length to copy
  */
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
@@ -51,7 +51,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
         s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
-        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, p, attrindx);
         memcpy(dst, src + s, l);
 
         paddr += l;
@@ -111,7 +111,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -151,7 +151,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE, DEV_SHARED);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d6c0178..fd70553 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -122,7 +122,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: handle other payloads too.
      */
     device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
-    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size, BUFFERABLE);
 
     /* Add non-xenheap memory */
     init_boot_pages(pfn_to_paddr(xenheap_mfn_start + xenheap_pages),
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 05ff89e..6433b4e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,7 +3,7 @@
 
 #include <public/version.h>
 
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx);
 
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fG-DJ; Thu, 28 Jun 2012 15:06: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 1SkGIS-0000eQ-Ol
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:16 +0000
Received: from [85.158.143.99:45726] by server-3.bemta-4.messagelabs.com id
	7E/7A-05808-8E27CEF4; Thu, 28 Jun 2012 15:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30996 invoked from network); 28 Jun 2012 15:06:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385347"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-P5;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:54 +0000
Message-ID: <1340894890-4369-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/21] arm: make vgic lock safe for use in
	interrupt context.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In particular vgic_vcpu_inject_irq can be called in both interupt and regular
context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/gic.c  |    4 ++--
 xen/arch/arm/vgic.c |   11 ++++++-----
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..1e60d3b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -604,14 +604,14 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         }
         spin_unlock(&gic.lock);
 
-        spin_lock(&current->arch.vgic.lock);
+        spin_lock_irq(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
         if ( p->desc != NULL ) {
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
         list_del_init(&p->inflight);
-        spin_unlock(&current->arch.vgic.lock);
+        spin_unlock_irq(&current->arch.vgic.lock);
 
         i++;
     }
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..a217151 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -114,8 +114,8 @@ int vcpu_vgic_init(struct vcpu *v)
     return 0;
 }
 
-#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
-#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+#define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
 
 #define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
 #define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,18 +567,18 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
         {
             list_add_tail(&n->inflight, &iter->inflight);
-            spin_unlock(&v->arch.vgic.lock);
+            spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
             return;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fG-DJ; Thu, 28 Jun 2012 15:06: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 1SkGIS-0000eQ-Ol
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:16 +0000
Received: from [85.158.143.99:45726] by server-3.bemta-4.messagelabs.com id
	7E/7A-05808-8E27CEF4; Thu, 28 Jun 2012 15:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30996 invoked from network); 28 Jun 2012 15:06:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385347"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-P5;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:54 +0000
Message-ID: <1340894890-4369-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/21] arm: make vgic lock safe for use in
	interrupt context.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In particular vgic_vcpu_inject_irq can be called in both interupt and regular
context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/gic.c  |    4 ++--
 xen/arch/arm/vgic.c |   11 ++++++-----
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 339c327..1e60d3b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -604,14 +604,14 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         }
         spin_unlock(&gic.lock);
 
-        spin_lock(&current->arch.vgic.lock);
+        spin_lock_irq(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
         if ( p->desc != NULL ) {
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
         list_del_init(&p->inflight);
-        spin_unlock(&current->arch.vgic.lock);
+        spin_unlock_irq(&current->arch.vgic.lock);
 
         i++;
     }
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index af3523f..a217151 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -114,8 +114,8 @@ int vcpu_vgic_init(struct vcpu *v)
     return 0;
 }
 
-#define vgic_lock(v)   spin_lock(&(v)->domain->arch.vgic.lock)
-#define vgic_unlock(v) spin_unlock(&(v)->domain->arch.vgic.lock)
+#define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
+#define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
 
 #define vgic_lock_rank(v, r) spin_lock(&(r)->lock)
 #define vgic_unlock_rank(v, r) spin_unlock(&(r)->lock)
@@ -550,6 +550,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
+    unsigned long flags;
 
     /* irq still pending */
     if (!list_empty(&n->inflight))
@@ -566,18 +567,18 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 
     gic_set_guest_irq(irq, GICH_LR_PENDING, priority);
 
-    spin_lock(&v->arch.vgic.lock);
+    spin_lock_irqsave(&v->arch.vgic.lock, flags);
     list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
     {
         if ( iter->priority > priority )
         {
             list_add_tail(&n->inflight, &iter->inflight);
-            spin_unlock(&v->arch.vgic.lock);
+            spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
             return;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
-    spin_unlock(&v->arch.vgic.lock);
+    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
 }
 
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fc-PV; Thu, 28 Jun 2012 15:06: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 1SkGIS-0000em-KT
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:16 +0000
Received: from [85.158.139.83:18755] by server-12.bemta-5.messagelabs.com id
	D4/90-25233-7E27CEF4; Thu, 28 Jun 2012 15:06:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340895973!29995351!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19877 invoked from network); 28 Jun 2012 15:06:15 -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 Jun 2012 15:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="29764295"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Dz;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:49 +0000
Message-ID: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/21] arm: allow p2m to be created with
	specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename p2m_create_entry to p2m_create_table since it can now only be used to
insert non-leaf entries into the page table.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/p2m.c         |   22 ++++++++++++----------
 xen/include/asm-arm/page.h |   21 +++++++++++++++++++--
 2 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cf12870..5f20246 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
     return -ENOSYS;
 }
 
-static int p2m_create_entry(struct domain *d,
+/* Allocate a new page table page and hook it in via the given entry */
+static int p2m_create_table(struct domain *d,
                             lpae_t *entry)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -142,7 +144,7 @@ static int create_p2m_entries(struct domain *d,
     {
         if ( !first[first_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L1 failed\n");
                 goto out;
@@ -161,7 +163,7 @@ static int create_p2m_entries(struct domain *d,
 
         if ( !second[second_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L2 failed\n");
                 goto out;
@@ -200,11 +202,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 4c3fd0d..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,15 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -187,7 +204,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -196,7 +213,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fc-PV; Thu, 28 Jun 2012 15:06: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 1SkGIS-0000em-KT
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:16 +0000
Received: from [85.158.139.83:18755] by server-12.bemta-5.messagelabs.com id
	D4/90-25233-7E27CEF4; Thu, 28 Jun 2012 15:06:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340895973!29995351!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19877 invoked from network); 28 Jun 2012 15:06:15 -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 Jun 2012 15:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="29764295"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Dz;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:49 +0000
Message-ID: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/21] arm: allow p2m to be created with
	specific MATTR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rename p2m_create_entry to p2m_create_table since it can now only be used to
insert non-leaf entries into the page table.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/p2m.c         |   22 ++++++++++++----------
 xen/include/asm-arm/page.h |   21 +++++++++++++++++++--
 2 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cf12870..5f20246 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -91,7 +91,8 @@ int p2m_pod_decrease_reservation(struct domain *d,
     return -ENOSYS;
 }
 
-static int p2m_create_entry(struct domain *d,
+/* Allocate a new page table page and hook it in via the given entry */
+static int p2m_create_table(struct domain *d,
                             lpae_t *entry)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -111,7 +112,7 @@ static int p2m_create_entry(struct domain *d,
     clear_page(p);
     unmap_domain_page(p);
 
-    pte = mfn_to_p2m_entry(page_to_mfn(page));
+    pte = mfn_to_p2m_entry(page_to_mfn(page), MATTR_MEM);
 
     write_pte(entry, pte);
 
@@ -122,7 +123,8 @@ static int create_p2m_entries(struct domain *d,
                      int alloc,
                      paddr_t start_gpaddr,
                      paddr_t end_gpaddr,
-                     paddr_t maddr)
+                     paddr_t maddr,
+                     int mattr)
 {
     int rc;
     struct p2m_domain *p2m = &d->arch.p2m;
@@ -142,7 +144,7 @@ static int create_p2m_entries(struct domain *d,
     {
         if ( !first[first_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &first[first_table_offset(addr)]);
+            rc = p2m_create_table(d, &first[first_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L1 failed\n");
                 goto out;
@@ -161,7 +163,7 @@ static int create_p2m_entries(struct domain *d,
 
         if ( !second[second_table_offset(addr)].p2m.valid )
         {
-            rc = p2m_create_entry(d, &second[second_table_offset(addr)]);
+            rc = p2m_create_table(d, &second[second_table_offset(addr)]);
             if ( rc < 0 ) {
                 printk("p2m_populate_ram: L2 failed\n");
                 goto out;
@@ -200,11 +202,11 @@ static int create_p2m_entries(struct domain *d,
                 goto out;
             }
 
-            pte = mfn_to_p2m_entry(page_to_mfn(page));
+            pte = mfn_to_p2m_entry(page_to_mfn(page), mattr);
 
             write_pte(&third[third_table_offset(addr)], pte);
         } else {
-            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT);
+            lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr);
             write_pte(&third[third_table_offset(addr)], pte);
             maddr += PAGE_SIZE;
         }
@@ -226,7 +228,7 @@ int p2m_populate_ram(struct domain *d,
                      paddr_t start,
                      paddr_t end)
 {
-    return create_p2m_entries(d, 1, start, end, 0);
+    return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -234,7 +236,7 @@ int map_mmio_regions(struct domain *d,
                      paddr_t end_gaddr,
                      paddr_t maddr)
 {
-    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
+    return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV);
 }
 
 int guest_physmap_add_page(struct domain *d,
@@ -244,7 +246,7 @@ int guest_physmap_add_page(struct domain *d,
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
                               (gpfn + (1<<page_order)) << PAGE_SHIFT,
-                              mfn << PAGE_SHIFT);
+                              mfn << PAGE_SHIFT, MATTR_MEM);
 }
 
 void guest_physmap_remove_page(struct domain *d,
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 4c3fd0d..2b6c1780 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -36,6 +36,14 @@
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
 
+/*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
 #define UNCACHED      0x0
 #define BUFFERABLE    0x1
 #define WRITETHROUGH  0x2
@@ -46,6 +54,15 @@
 #define DEV_WC        BUFFERABLE
 #define DEV_CACHED    WRITEBACK
 
+/*
+ * Stage 2 Memory Type.
+ *
+ * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
+ * table entry.
+ *
+ */
+#define MATTR_DEV     0x1
+#define MATTR_MEM     0xf
 
 #ifndef __ASSEMBLY__
 
@@ -187,7 +204,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn)
     return e;
 }
 
-static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
+static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 {
     paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
     lpae_t e = (lpae_t) {
@@ -196,7 +213,7 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn)
         .p2m.sh = LPAE_SH_OUTER,
         .p2m.write = 1,
         .p2m.read = 1,
-        .p2m.mattr = 0xf,
+        .p2m.mattr = mattr,
         .p2m.table = 1,
         .p2m.valid = 1,
     };
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIX-0000h2-I7; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fL-7L
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.139.83:19102] by server-2.bemta-5.messagelabs.com id
	9D/97-04598-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340895975!30039441!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19670 invoked from network); 28 Jun 2012 15:06:17 -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;
	28 Jun 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385353"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-UQ;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:57 +0000
Message-ID: <1340894890-4369-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/21] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Upgrading barriers is conservative and may not be necessary.

Protected Table Walk traps stage 1 page tables which refer to device memory
(per stage 2) using a non-device mapping. This generally indicates a guest
error but trapping it as a fault for now helps us know if something odd is
going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c     |    2 +-
 xen/include/asm-arm/processor.h |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1b19e54..a9e7f43 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -333,7 +333,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 81924a4..9b3c9dd 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -76,6 +76,10 @@
 #define HCR_TWI         (1<<13)
 #define HCR_DC          (1<<12)
 #define HCR_BSU_MASK    (3<<10)
+#define HCR_BSU_NONE     (0<<10)
+#define HCR_BSU_INNER    (1<<10)
+#define HCR_BSU_OUTER    (2<<10)
+#define HCR_BSU_FULL     (3<<10)
 #define HCR_FB          (1<<9)
 #define HCR_VA          (1<<8)
 #define HCR_VI          (1<<7)
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIX-0000h2-I7; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fL-7L
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.139.83:19102] by server-2.bemta-5.messagelabs.com id
	9D/97-04598-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340895975!30039441!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19670 invoked from network); 28 Jun 2012 15:06:17 -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;
	28 Jun 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385353"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-UQ;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:57 +0000
Message-ID: <1340894890-4369-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/21] arm: Upgrade guest barriers to
	Outer-Shareable. Enable Protected Table Walk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Upgrading barriers is conservative and may not be necessary.

Protected Table Walk traps stage 1 page tables which refer to device memory
(per stage 2) using a non-device mapping. This generally indicates a guest
error but trapping it as a fault for now helps us know if something odd is
going on.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c     |    2 +-
 xen/include/asm-arm/processor.h |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1b19e54..a9e7f43 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -333,7 +333,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 81924a4..9b3c9dd 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -76,6 +76,10 @@
 #define HCR_TWI         (1<<13)
 #define HCR_DC          (1<<12)
 #define HCR_BSU_MASK    (3<<10)
+#define HCR_BSU_NONE     (0<<10)
+#define HCR_BSU_INNER    (1<<10)
+#define HCR_BSU_OUTER    (2<<10)
+#define HCR_BSU_FULL     (3<<10)
 #define HCR_FB          (1<<9)
 #define HCR_VA          (1<<8)
 #define HCR_VI          (1<<7)
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIW-0000gF-5b; Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fD-FR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:18 +0000
Received: from [85.158.143.99:45805] by server-1.bemta-4.messagelabs.com id
	3A/83-24392-9E27CEF4; Thu, 28 Jun 2012 15:06:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31020 invoked from network); 28 Jun 2012 15:06:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385349"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Rf;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:55 +0000
Message-ID: <1340894890-4369-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/21] arm: map GICV in all domains,
	not just 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

This requires that we allocate all p2m pages from domheap without a particular
dom because max pages is not setup yet so there is no allocation available to
us.

At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.

Also we seem to have been calling p2m_alloc_table twice for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c       |   10 +++++++---
 xen/arch/arm/domain_build.c |    5 -----
 xen/arch/arm/gic.c          |    7 ++-----
 xen/arch/arm/gic.h          |    2 +-
 xen/arch/arm/p2m.c          |    3 ++-
 5 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d11be78..a7b7d4a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -323,10 +323,13 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         if ( (rc = p2m_alloc_table(d)) != 0 )
             goto fail;
-    }
 
-    if ( (rc = domain_vgic_init(d)) != 0 )
-        goto fail;
+        if ( (rc = gicv_setup(d)) != 0 )
+            goto fail;
+
+        if ( (rc = domain_vgic_init(d)) != 0 )
+            goto fail;
+    }
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
@@ -334,6 +337,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     rc = 0;
 fail:
+    /*XXX unwind allocations etc */
     return rc;
 }
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72e775c..1b19e54 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
 
     d->max_pages = ~0U;
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
-        return rc;
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
@@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
     printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
     map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
 
-    gicv_setup(d);
-
     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
     gic_route_irq_to_guest(d, 34, "timer0");
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1e60d3b..b304923 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -541,14 +541,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     do_IRQ(regs, irq, is_fiq);
 }
 
-void gicv_setup(struct domain *d)
+int gicv_setup(struct domain *d)
 {
     /* map the gic virtual cpu interface in the gic cpu interface region of
      * the guest */
-    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
-           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
-           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
-    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
                         GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..018d820 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
-extern void gicv_setup(struct domain *d);
+extern int gicv_setup(struct domain *d);
 
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5f20246..67bfeba 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
+#include "gic.h"
 
 void dump_p2m_lookup(struct domain *d, paddr_t addr)
 {
@@ -102,7 +103,7 @@ static int p2m_create_table(struct domain *d,
 
     BUG_ON(entry->p2m.valid);
 
-    page = alloc_domheap_page(d, 0);
+    page = alloc_domheap_page(NULL, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIW-0000gF-5b; Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fD-FR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:18 +0000
Received: from [85.158.143.99:45805] by server-1.bemta-4.messagelabs.com id
	3A/83-24392-9E27CEF4; Thu, 28 Jun 2012 15:06:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31020 invoked from network); 28 Jun 2012 15:06:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385349"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Rf;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:55 +0000
Message-ID: <1340894890-4369-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/21] arm: map GICV in all domains,
	not just 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

This requires that we allocate all p2m pages from domheap without a particular
dom because max pages is not setup yet so there is no allocation available to
us.

At some point we should create a separate p2m allocation (similar to x86's shadow allocation) and use that.

Also we seem to have been calling p2m_alloc_table twice for dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c       |   10 +++++++---
 xen/arch/arm/domain_build.c |    5 -----
 xen/arch/arm/gic.c          |    7 ++-----
 xen/arch/arm/gic.h          |    2 +-
 xen/arch/arm/p2m.c          |    3 ++-
 5 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d11be78..a7b7d4a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -323,10 +323,13 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         if ( (rc = p2m_alloc_table(d)) != 0 )
             goto fail;
-    }
 
-    if ( (rc = domain_vgic_init(d)) != 0 )
-        goto fail;
+        if ( (rc = gicv_setup(d)) != 0 )
+            goto fail;
+
+        if ( (rc = domain_vgic_init(d)) != 0 )
+            goto fail;
+    }
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
@@ -334,6 +337,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
     rc = 0;
 fail:
+    /*XXX unwind allocations etc */
     return rc;
 }
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72e775c..1b19e54 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -270,9 +270,6 @@ int construct_dom0(struct domain *d)
 
     d->max_pages = ~0U;
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
-        return rc;
-
     rc = prepare_dtb(d, &kinfo);
     if ( rc < 0 )
         return rc;
@@ -288,8 +285,6 @@ int construct_dom0(struct domain *d)
     printk("Map VGIC MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x2C008000ULL, 0x2DFFFFFFULL);
     map_mmio_regions(d, 0x2C008000, 0x2DFFFFFF, 0x2C008000);
 
-    gicv_setup(d);
-
     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
     gic_route_irq_to_guest(d, 34, "timer0");
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1e60d3b..b304923 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -541,14 +541,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
     do_IRQ(regs, irq, is_fiq);
 }
 
-void gicv_setup(struct domain *d)
+int gicv_setup(struct domain *d)
 {
     /* map the gic virtual cpu interface in the gic cpu interface region of
      * the guest */
-    printk("mapping GICC at %#"PRIx32" to %#"PRIx32"\n",
-           GIC_BASE_ADDRESS + GIC_CR_OFFSET,
-           GIC_BASE_ADDRESS + GIC_VR_OFFSET);
-    map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
+    return map_mmio_regions(d, GIC_BASE_ADDRESS + GIC_CR_OFFSET,
                         GIC_BASE_ADDRESS + GIC_CR_OFFSET + (2 * PAGE_SIZE) - 1,
                         GIC_BASE_ADDRESS + GIC_VR_OFFSET);
 }
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index ac9cf3a..018d820 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -148,7 +148,7 @@ extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
-extern void gicv_setup(struct domain *d);
+extern int gicv_setup(struct domain *d);
 
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5f20246..67bfeba 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/domain_page.h>
 #include <asm/flushtlb.h>
+#include "gic.h"
 
 void dump_p2m_lookup(struct domain *d, paddr_t addr)
 {
@@ -102,7 +103,7 @@ static int p2m_create_table(struct domain *d,
 
     BUG_ON(entry->p2m.valid);
 
-    page = alloc_domheap_page(d, 0);
+    page = alloc_domheap_page(NULL, 0);
     if ( page == NULL )
         return -ENOMEM;
 
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIW-0000gf-Ua; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fK-1U
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.139.83:45378] by server-9.bemta-5.messagelabs.com id
	65/E9-01069-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340895976!18750508!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12126 invoked from network); 28 Jun 2012 15:06:17 -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;
	28 Jun 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385352"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-T5;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:56 +0000
Message-ID: <1340894890-4369-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/21] arm: enable data-cache at the same time
	as enabling the MMU, not before
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/head.S |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..cdbe011 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache disabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -210,7 +211,7 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIX-0000hK-To; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fN-8Y
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.139.83:45383] by server-11.bemta-5.messagelabs.com id
	32/41-20400-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340895975!30039441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19563 invoked from network); 28 Jun 2012 15:06:16 -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;
	28 Jun 2012 15:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385350"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-MW;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:53 +0000
Message-ID: <1340894890-4369-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/21] arm: split pending SPIs (global) out from
	pending PPIs and SGIs (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

This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
seems more logical.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vgic.c          |   12 +++++++-----
 xen/include/asm-arm/domain.h |   10 ++++++++++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 629a0da..af3523f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.shared_irqs =
         xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     d->arch.vgic.pending_irqs =
-        xmalloc_array(struct pending_irq,
-                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
-    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+    for (i=0; i<d->arch.vgic.nr_lines; i++)
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
@@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     spin_lock_init(&v->arch.vgic.private_irqs.lock);
 
+    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
+    for (i = 0; i < 32; i++)
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+
     /* For SGI and PPI the target is always this CPU */
     for ( i = 0 ; i < 8 ; i++ )
         v->arch.vgic.private_irqs.itargets[i] =
@@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
     /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
-        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
-            + v->domain->arch.vgic.nr_lines];
+        n = &v->arch.vgic.pending_irqs[irq];
     else
         n = &v->domain->arch.vgic.pending_irqs[irq - 32];
     return n;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 620b26e..32deb52 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -46,6 +46,10 @@ struct arch_domain
         int ctlr;
         int nr_lines;
         struct vgic_irq_rank *shared_irqs;
+        /*
+         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
+         * struct arch_vcpu.
+         */
         struct pending_irq *pending_irqs;
     } vgic;
 
@@ -114,7 +118,13 @@ struct arch_vcpu
     uint32_t gic_lr[64];
 
     struct {
+        /*
+         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
+         * struct arch_domain.
+         */
+        struct pending_irq pending_irqs[32];
         struct vgic_irq_rank private_irqs;
+
         /* This list is ordered by IRQ priority and it is used to keep
          * track of the IRQs that the VGIC injected into the guest.
          * Depending on the availability of LR registers, the IRQs might
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIY-0000hY-Ab; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fD-Lw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.143.99:5625] by server-1.bemta-4.messagelabs.com id
	2C/93-24392-BE27CEF4; Thu, 28 Jun 2012 15:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31095 invoked from network); 28 Jun 2012 15:06:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385356"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Fg;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:50 +0000
Message-ID: <1340894890-4369-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/21] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    5 ++
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  145 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 ++++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 80387fd..d11be78 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -327,6 +328,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    /* Domain 0 gets a real UART not an emulated one */
+    if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..5dc8b28
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,145 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_START 0x1c090000
+#define UART0_END   (UART0_START+65536)
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    ASSERT( d->domain_id );
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        return -ENOMEM;
+
+    return 0;
+
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= UART0_START && addr < UART0_END;
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        /* ignore any status bits */
+        uart0_print_char((int)((*r) & 0xFF));
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 8907f22..620b26e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIX-0000hK-To; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fN-8Y
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.139.83:45383] by server-11.bemta-5.messagelabs.com id
	32/41-20400-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1340895975!30039441!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19563 invoked from network); 28 Jun 2012 15:06:16 -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;
	28 Jun 2012 15:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385350"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-MW;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:53 +0000
Message-ID: <1340894890-4369-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/21] arm: split pending SPIs (global) out from
	pending PPIs and SGIs (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

This tracks SPIs in struct arch_domain and PPIs+SGIs in struct arch_vcpu which
seems more logical.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vgic.c          |   12 +++++++-----
 xen/include/asm-arm/domain.h |   10 ++++++++++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 629a0da..af3523f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -82,9 +82,8 @@ int domain_vgic_init(struct domain *d)
     d->arch.vgic.shared_irqs =
         xmalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     d->arch.vgic.pending_irqs =
-        xmalloc_array(struct pending_irq,
-                d->arch.vgic.nr_lines + (32 * d->max_vcpus));
-    for (i=0; i<d->arch.vgic.nr_lines + (32 * d->max_vcpus); i++)
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+    for (i=0; i<d->arch.vgic.nr_lines; i++)
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
     for (i=0; i<DOMAIN_NR_RANKS(d); i++)
         spin_lock_init(&d->arch.vgic.shared_irqs[i].lock);
@@ -98,6 +97,10 @@ int vcpu_vgic_init(struct vcpu *v)
 
     spin_lock_init(&v->arch.vgic.private_irqs.lock);
 
+    memset(&v->arch.vgic.pending_irqs, 0, sizeof(v->arch.vgic.pending_irqs));
+    for (i = 0; i < 32; i++)
+        INIT_LIST_HEAD(&v->arch.vgic.pending_irqs[i].inflight);
+
     /* For SGI and PPI the target is always this CPU */
     for ( i = 0 ; i < 8 ; i++ )
         v->arch.vgic.private_irqs.itargets[i] =
@@ -535,8 +538,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
     /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
-        n = &v->domain->arch.vgic.pending_irqs[irq + (v->vcpu_id * 32)
-            + v->domain->arch.vgic.nr_lines];
+        n = &v->arch.vgic.pending_irqs[irq];
     else
         n = &v->domain->arch.vgic.pending_irqs[irq - 32];
     return n;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 620b26e..32deb52 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -46,6 +46,10 @@ struct arch_domain
         int ctlr;
         int nr_lines;
         struct vgic_irq_rank *shared_irqs;
+        /*
+         * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
+         * struct arch_vcpu.
+         */
         struct pending_irq *pending_irqs;
     } vgic;
 
@@ -114,7 +118,13 @@ struct arch_vcpu
     uint32_t gic_lr[64];
 
     struct {
+        /*
+         * SGIs and PPIs are per-VCPU, SPIs are domain global and in
+         * struct arch_domain.
+         */
+        struct pending_irq pending_irqs[32];
         struct vgic_irq_rank private_irqs;
+
         /* This list is ordered by IRQ priority and it is used to keep
          * track of the IRQs that the VGIC injected into the guest.
          * Depending on the availability of LR registers, the IRQs might
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIW-0000gf-Ua; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fK-1U
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.139.83:45378] by server-9.bemta-5.messagelabs.com id
	65/E9-01069-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340895976!18750508!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12126 invoked from network); 28 Jun 2012 15:06:17 -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;
	28 Jun 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385352"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-T5;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:56 +0000
Message-ID: <1340894890-4369-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/21] arm: enable data-cache at the same time
	as enabling the MMU, not before
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 enough warnings enabled the model seemed to be complaining that pages
cached before paging was enabled had been mapped with to inconsistent sets of
attributes. I'm not convinced that isn't a model issue, nor am I convinced
this has really fixed anything, but it seems sensible enough.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/head.S |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9a7714a..cdbe011 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,10 +148,11 @@ hyp:
 	 * Exceptions in LE ARM,
 	 * Low-latency IRQs disabled,
 	 * Write-implies-XN disabled (for now),
-	 * I-cache and d-cache enabled,
+	 * D-cache disabled (for now),
+	 * I-cache enabled,
 	 * Alignment checking enabled,
 	 * MMU translation disabled (for now). */
-	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A)
 	mcr   CP32(r0, HSCTLR)
 
 	/* Write Xen's PT's paddr into the HTTBR */
@@ -210,7 +211,7 @@ pt_ready:
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
 	mrc   CP32(r0, HSCTLR)
-	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
 	dsb                          /* Flush PTE writes and finish reads */
 	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
 	isb                          /* Now, flush the icache */
-- 
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 Thu Jun 28 15:06:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIY-0000hY-Ab; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fD-Lw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.143.99:5625] by server-1.bemta-4.messagelabs.com id
	2C/93-24392-BE27CEF4; Thu, 28 Jun 2012 15:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31095 invoked from network); 28 Jun 2012 15:06:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385356"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Fg;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:50 +0000
Message-ID: <1340894890-4369-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/21] arm: implement vpl011 (UART) emulator.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not interended to provide a full emulation, but rather just enough to
satisfy the use made by Linux' boot time decompressor code (which is too early
for DT etc)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/Makefile        |    1 +
 xen/arch/arm/domain.c        |    5 ++
 xen/arch/arm/io.c            |    1 +
 xen/arch/arm/io.h            |    1 +
 xen/arch/arm/vpl011.c        |  145 ++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vpl011.h        |   34 ++++++++++
 xen/include/asm-arm/domain.h |    8 ++
 7 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/vpl011.c
 create mode 100644 xen/arch/arm/vpl011.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9440a21..5a87ba6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o
 obj-y += vtimer.o
+obj-y += vpl011.o
 
 #obj-bin-y += ....o
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 80387fd..d11be78 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 
 #include "gic.h"
 #include "vtimer.h"
+#include "vpl011.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -327,6 +328,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vgic_init(d)) != 0 )
         goto fail;
 
+    /* Domain 0 gets a real UART not an emulated one */
+    if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
+        goto fail;
+
     rc = 0;
 fail:
     return rc;
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 4461225..18f6164 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -25,6 +25,7 @@
 static const struct mmio_handler *const mmio_handlers[] =
 {
     &vgic_distr_mmio_handler,
+    &uart0_mmio_handler,
 };
 #define MMIO_HANDLER_NR ARRAY_SIZE(mmio_handlers)
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 8cc5ca7..9a507f5 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -40,6 +40,7 @@ struct mmio_handler {
 };
 
 extern const struct mmio_handler vgic_distr_mmio_handler;
+extern const struct mmio_handler uart0_mmio_handler;
 
 extern int handle_mmio(mmio_info_t *info);
 
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
new file mode 100644
index 0000000..5dc8b28
--- /dev/null
+++ b/xen/arch/arm/vpl011.c
@@ -0,0 +1,145 @@
+/*
+ * xen/arch/arm/vpl011.c
+ *
+ * ARM PL011 UART Emulator (DEBUG)
+ *
+ * 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.
+ */
+
+/*
+ * This is not intended to be a full emulation of a PL011
+ * device. Rather it is intended to provide a sufficient veneer of one
+ * that early code (such as Linux's boot time decompressor) which
+ * hardcodes output directly to such a device are able to make progress.
+ *
+ * This device is not intended to be enumerable or exposed to the OS
+ * (e.g. via Device Tree).
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/errno.h>
+#include <xen/ctype.h>
+
+#include "io.h"
+
+#define UART0_START 0x1c090000
+#define UART0_END   (UART0_START+65536)
+
+#define UARTDR 0x000
+#define UARTFR 0x018
+
+int domain_uart0_init(struct domain *d)
+{
+    ASSERT( d->domain_id );
+
+    spin_lock_init(&d->arch.uart0.lock);
+    d->arch.uart0.idx = 0;
+
+    d->arch.uart0.buf = xzalloc_array(char, VPL011_BUF_SIZE);
+    if ( !d->arch.uart0.buf )
+        return -ENOMEM;
+
+    return 0;
+
+}
+
+static void uart0_print_char(char c)
+{
+    struct vpl011 *uart = &current->domain->arch.uart0;
+
+    /* Accept only printable characters, newline, and horizontal tab. */
+    if ( !isprint(c) && (c != '\n') && (c != '\t') )
+        return ;
+
+    spin_lock(&uart->lock);
+    uart->buf[uart->idx++] = c;
+    if ( (uart->idx == (VPL011_BUF_SIZE - 2)) || (c == '\n') )
+    {
+        if ( c != '\n' )
+            uart->buf[uart->idx++] = '\n';
+        uart->buf[uart->idx] = '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s",
+               current->domain->domain_id, uart->buf);
+        uart->idx = 0;
+    }
+    spin_unlock(&uart->lock);
+}
+
+static int uart0_mmio_check(struct vcpu *v, paddr_t addr)
+{
+    return addr >= UART0_START && addr < UART0_END;
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        *r = 0;
+        return 1;
+    case UARTFR:
+        *r = 0x87; /* All holding registers empty, ready to send etc */
+        return 1;
+    default:
+        printk("VPL011: unhandled read r%d offset %#08x\n",
+               dabt.reg, offset);
+        domain_crash_synchronous();
+    }
+}
+
+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 = &regs->r0 + dabt.reg;
+    int offset = (int)(info->gpa - UART0_START);
+
+    switch ( offset )
+    {
+    case UARTDR:
+        /* ignore any status bits */
+        uart0_print_char((int)((*r) & 0xFF));
+        return 1;
+    case UARTFR:
+        /* Silently ignore */
+        return 1;
+    default:
+        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+               dabt.reg, *r, offset);
+        domain_crash_synchronous();
+    }
+}
+
+const struct mmio_handler uart0_mmio_handler = {
+    .check_handler = uart0_mmio_check,
+    .read_handler  = uart0_mmio_read,
+    .write_handler = uart0_mmio_write,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
new file mode 100644
index 0000000..952d812
--- /dev/null
+++ b/xen/arch/arm/vpl011.h
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/vpl011.h
+ *
+ * ARM PL011 Emulation Support
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_VPL011_H__
+#define __ARCH_ARM_VPL011_H__
+
+extern int domain_uart0_init(struct domain *d);
+
+#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 8907f22..620b26e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,6 +48,14 @@ struct arch_domain
         struct vgic_irq_rank *shared_irqs;
         struct pending_irq *pending_irqs;
     } vgic;
+
+    struct vpl011 {
+#define VPL011_BUF_SIZE 128
+        char                  *buf;
+        int                    idx;
+        spinlock_t             lock;
+    } uart0;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
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 Thu Jun 28 15:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIY-0000ho-Ma; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fy-UH
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:20 +0000
Received: from [85.158.139.83:19153] by server-1.bemta-5.messagelabs.com id
	91/A3-19721-BE27CEF4; Thu, 28 Jun 2012 15:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340895976!18750508!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12165 invoked from network); 28 Jun 2012 15:06:18 -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;
	28 Jun 2012 15:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385354"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-IZ;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:51 +0000
Message-ID: <1340894890-4369-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/21] arm: implement vcpu_show_execution_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 03f7489..cab9522 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
 DUMMY(get_page);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d8eb5a9..f5f43da 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
     panic("Error during %s-to-physical address translation\n", when);
 }
 
-void show_registers(struct cpu_user_regs *regs)
+struct reg_ctxt {
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+};
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
     print_xen_info();
     printk("CPU:    %d\n", smp_processor_id());
     printk("PC:     %08"PRIx32, regs->pc);
-    if ( !guest_mode(regs) )
+    if ( !guest_mode )
             print_symbol(" %s", regs->pc);
     printk("\n");
     printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
@@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
     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);
 
-    if ( guest_mode(regs) )
+    if ( guest_mode )
     {
         printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
                regs->sp_usr, regs->lr_usr, regs->cpsr);
@@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
                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",
-               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
-        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
         printk("\n");
     }
@@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
     printk("\n");
 }
 
+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);
+    _show_registers(regs, &ctxt, guest_mode(regs));
+}
+
+void vcpu_show_registers(const struct vcpu *v)
+{
+    struct reg_ctxt ctxt;
+    ctxt.sctlr = v->arch.sctlr;
+    ctxt.ttbcr = 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);
+}
+
 static void show_guest_stack(struct cpu_user_regs *regs)
 {
     printk("GUEST STACK GOES HERE\n");
@@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
     show_stack(regs);
 }
 
+void vcpu_show_execution_state(struct vcpu *v)
+{
+    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
+           v->domain->domain_id, v->vcpu_id);
+
+    if ( v == current )
+    {
+        show_execution_state(guest_cpu_user_regs());
+        return;
+    }
+
+    vcpu_pause(v); /* acceptably dangerous */
+
+    vcpu_show_registers(v);
+    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
+        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
+
+    vcpu_unpause(v);
+}
+
 static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
-- 
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 Thu Jun 28 15:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIY-0000ho-Ma; Thu, 28 Jun 2012 15:06: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 1SkGIV-0000fy-UH
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:20 +0000
Received: from [85.158.139.83:19153] by server-1.bemta-5.messagelabs.com id
	91/A3-19721-BE27CEF4; Thu, 28 Jun 2012 15:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340895976!18750508!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12165 invoked from network); 28 Jun 2012 15:06:18 -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;
	28 Jun 2012 15:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385354"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:13 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-IZ;
	Thu, 28 Jun 2012 15:48:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:51 +0000
Message-ID: <1340894890-4369-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/21] arm: implement vcpu_show_execution_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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/traps.c |   56 +++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 03f7489..cab9522 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -21,7 +21,6 @@ DUMMY(pirq_set_affinity);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_vcpu_reset);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
 DUMMY(get_page);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d8eb5a9..f5f43da 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -170,7 +170,13 @@ void panic_PAR(uint64_t par, const char *when)
     panic("Error during %s-to-physical address translation\n", when);
 }
 
-void show_registers(struct cpu_user_regs *regs)
+struct reg_ctxt {
+    uint32_t sctlr;
+    uint32_t ttbr0, ttbr1, ttbcr;
+};
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -187,7 +193,7 @@ void show_registers(struct cpu_user_regs *regs)
     print_xen_info();
     printk("CPU:    %d\n", smp_processor_id());
     printk("PC:     %08"PRIx32, regs->pc);
-    if ( !guest_mode(regs) )
+    if ( !guest_mode )
             print_symbol(" %s", regs->pc);
     printk("\n");
     printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
@@ -199,7 +205,7 @@ void show_registers(struct cpu_user_regs *regs)
     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);
 
-    if ( guest_mode(regs) )
+    if ( guest_mode )
     {
         printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
                regs->sp_usr, regs->lr_usr, regs->cpsr);
@@ -217,8 +223,8 @@ void show_registers(struct cpu_user_regs *regs)
                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",
-               READ_CP32(TTBR0), READ_CP32(TTBR1), READ_CP32(TTBCR));
-        printk("SCTLR %08"PRIx32"\n", READ_CP32(SCTLR));
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+        printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
         printk("\n");
     }
@@ -241,6 +247,26 @@ void show_registers(struct cpu_user_regs *regs)
     printk("\n");
 }
 
+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);
+    _show_registers(regs, &ctxt, guest_mode(regs));
+}
+
+void vcpu_show_registers(const struct vcpu *v)
+{
+    struct reg_ctxt ctxt;
+    ctxt.sctlr = v->arch.sctlr;
+    ctxt.ttbcr = 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);
+}
+
 static void show_guest_stack(struct cpu_user_regs *regs)
 {
     printk("GUEST STACK GOES HERE\n");
@@ -334,6 +360,26 @@ void show_execution_state(struct cpu_user_regs *regs)
     show_stack(regs);
 }
 
+void vcpu_show_execution_state(struct vcpu *v)
+{
+    printk("*** Dumping Dom%d vcpu#%d state: ***\n",
+           v->domain->domain_id, v->vcpu_id);
+
+    if ( v == current )
+    {
+        show_execution_state(guest_cpu_user_regs());
+        return;
+    }
+
+    vcpu_pause(v); /* acceptably dangerous */
+
+    vcpu_show_registers(v);
+    if ( !usr_mode(&v->arch.cpu_info->guest_cpu_user_regs) )
+        show_guest_stack(&v->arch.cpu_info->guest_cpu_user_regs);
+
+    vcpu_unpause(v);
+}
+
 static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
-- 
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 Thu Jun 28 15:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIW-0000gS-Ij; Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fD-VN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.143.99:45888] by server-1.bemta-4.messagelabs.com id
	03/93-24392-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31058 invoked from network); 28 Jun 2012 15:06:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385351"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Vm;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:58 +0000
Message-ID: <1340894890-4369-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/21] arm: gic.lock can be taken in interrupt
	context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 particular it is taken by gic_set_guest_irq which is called by
vgic_vcpu_inject_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b304923..ee83825 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -329,19 +329,19 @@ int __init gic_init(void)
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
 void __cpuinit gic_init_secondary_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_init();
     gic_hyp_init();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 /* Shut down the per-CPU GIC interface */
 void gic_disable_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_disable();
     gic_hyp_disable();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 void gic_route_irqs(void)
@@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
 
     events_maintenance(current);
 
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
 
     if ( list_empty(&gic.lr_pending) )
     {
@@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &gic.lr_pending);
 
 out:
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
     return;
 }
 
@@ -557,7 +557,7 @@ static void events_maintenance(struct vcpu *v)
             (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
 
     if (!already_pending && gic.event_mask != 0) {
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
                         sizeof(uint64_t), i)) < sizeof(uint64_t)) {
 
@@ -567,7 +567,7 @@ static void events_maintenance(struct vcpu *v)
 
             i++;
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
     }
 }
 
@@ -583,7 +583,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                               sizeof(eisr), i)) < sizeof(eisr)) {
         struct pending_irq *p;
 
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
@@ -599,7 +599,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         } else {
             gic_inject_irq_stop();
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
 
         spin_lock_irq(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
-- 
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 Thu Jun 28 15:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:06: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 1SkGIW-0000gS-Ij; Thu, 28 Jun 2012 15:06: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 1SkGIU-0000fD-VN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:06:19 +0000
Received: from [85.158.143.99:45888] by server-1.bemta-4.messagelabs.com id
	03/93-24392-AE27CEF4; Thu, 28 Jun 2012 15:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340895972!28709949!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31058 invoked from network); 28 Jun 2012 15:06:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200385351"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:06:12 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:06:12 -0400
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 1SkG0w-000630-Vm;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:58 +0000
Message-ID: <1340894890-4369-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/21] arm: gic.lock can be taken in interrupt
	context, so lock appropriately.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 particular it is taken by gic_set_guest_irq which is called by
vgic_vcpu_inject_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b304923..ee83825 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -329,19 +329,19 @@ int __init gic_init(void)
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
 void __cpuinit gic_init_secondary_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_init();
     gic_hyp_init();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 /* Shut down the per-CPU GIC interface */
 void gic_disable_cpu(void)
 {
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
     gic_cpu_disable();
     gic_hyp_disable();
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
 }
 
 void gic_route_irqs(void)
@@ -439,7 +439,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
 
     events_maintenance(current);
 
-    spin_lock(&gic.lock);
+    spin_lock_irq(&gic.lock);
 
     if ( list_empty(&gic.lr_pending) )
     {
@@ -465,7 +465,7 @@ void gic_set_guest_irq(unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &gic.lr_pending);
 
 out:
-    spin_unlock(&gic.lock);
+    spin_unlock_irq(&gic.lock);
     return;
 }
 
@@ -557,7 +557,7 @@ static void events_maintenance(struct vcpu *v)
             (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
 
     if (!already_pending && gic.event_mask != 0) {
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         while ((i = find_next_bit((const long unsigned int *) &gic.event_mask,
                         sizeof(uint64_t), i)) < sizeof(uint64_t)) {
 
@@ -567,7 +567,7 @@ static void events_maintenance(struct vcpu *v)
 
             i++;
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
     }
 }
 
@@ -583,7 +583,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                               sizeof(eisr), i)) < sizeof(eisr)) {
         struct pending_irq *p;
 
-        spin_lock(&gic.lock);
+        spin_lock_irq(&gic.lock);
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
@@ -599,7 +599,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         } else {
             gic_inject_irq_stop();
         }
-        spin_unlock(&gic.lock);
+        spin_unlock_irq(&gic.lock);
 
         spin_lock_irq(&current->arch.vgic.lock);
         p = irq_to_pending(current, virq);
-- 
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 Thu Jun 28 15:08:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:08: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 1SkGKO-0001Zl-EK; Thu, 28 Jun 2012 15:08:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkGKN-0001ZM-AM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:08:15 +0000
Received: from [85.158.139.83:40141] by server-8.bemta-5.messagelabs.com id
	03/49-10278-E537CEF4; Thu, 28 Jun 2012 15:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340896094!30010696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28312 invoked from network); 28 Jun 2012 15:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 16:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkGKJ-00013Q-Vi; Thu, 28 Jun 2012 15:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkGKJ-00083i-UY;
	Thu, 28 Jun 2012 16:08:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.29531.933964.18000@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 16:08:11 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.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
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

Matt Wilson writes ("[Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
>  this, by ensuring certain VCPUs can only run on certain physical
>  CPUs.
>  
> +=item B<vm-list>
> +
> +Prints information about all domains except for dom0.

Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
etc. ?  IMO it should, and the docs should say so.

If it doesn't then that's IMO a bug but stubdoms are a bit buggy
anyway so I don't regard fixing that as a blocker for this patch.  But
I think we should introduce docs that are correct.

If you and Ian agree, perhaps you'd like to clarify that (and perhaps
change the usage message too).

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 Jun 28 15:08:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:08: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 1SkGKO-0001Zl-EK; Thu, 28 Jun 2012 15:08:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkGKN-0001ZM-AM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:08:15 +0000
Received: from [85.158.139.83:40141] by server-8.bemta-5.messagelabs.com id
	03/49-10278-E537CEF4; Thu, 28 Jun 2012 15:08:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340896094!30010696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28312 invoked from network); 28 Jun 2012 15:08:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:08:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:08:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 16:08:12 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkGKJ-00013Q-Vi; Thu, 28 Jun 2012 15:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkGKJ-00083i-UY;
	Thu, 28 Jun 2012 16:08:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.29531.933964.18000@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 16:08:11 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.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
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

Matt Wilson writes ("[Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
>  this, by ensuring certain VCPUs can only run on certain physical
>  CPUs.
>  
> +=item B<vm-list>
> +
> +Prints information about all domains except for dom0.

Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
etc. ?  IMO it should, and the docs should say so.

If it doesn't then that's IMO a bug but stubdoms are a bit buggy
anyway so I don't regard fixing that as a blocker for this patch.  But
I think we should introduce docs that are correct.

If you and Ian agree, perhaps you'd like to clarify that (and perhaps
change the usage message too).

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 Jun 28 15:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:11: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 1SkGNR-0002H5-6F; Thu, 28 Jun 2012 15:11:25 +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 1SkGNP-0002Gg-L2
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:11:23 +0000
Received: from [85.158.143.35:48836] by server-1.bemta-4.messagelabs.com id
	1A/7C-24392-A147CEF4; Thu, 28 Jun 2012 15:11:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340896280!13130562!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24979 invoked from network); 28 Jun 2012 15:11:22 -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;
	28 Jun 2012 15:11:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200386207"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:11:17 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:11:16 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SkGNI-0006rJ-3l;
	Thu, 28 Jun 2012 16:11:16 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 16:10:33 +0100
Message-ID: <1340896233-9523-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: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] autoconf: correctly parse *_INCLUDES and
	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Parse those options correctly, since the "+=" operator is not valid.
Also added CPPFLAGS, so headers checks don't give strange results.

Please rerun configure after applying.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/m4/set_cflags_ldflags.m4 |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/m4/set_cflags_ldflags.m4 b/tools/m4/set_cflags_ldflags.m4
index 7e357ba..cbad3c1 100644
--- a/tools/m4/set_cflags_ldflags.m4
+++ b/tools/m4/set_cflags_ldflags.m4
@@ -1,20 +1,20 @@
 AC_DEFUN([AX_SET_FLAGS],
-[for cflag in $PREPEND_INCLUDES
+[for cppflag in $PREPEND_INCLUDES
 do
-    PREPEND_CFLAGS+=" -I$cflag"
+    PREPEND_CPPFLAGS="$PREPEND_CPPFLAGS -I$cppflag"
 done
 for ldflag in $PREPEND_LIB
 do
-    PREPEND_LDFLAGS+=" -L$ldflag"
+    PREPEND_LDFLAGS="$PREPEND_LDFLAGS -L$ldflag"
 done
-for cflag in $APPEND_INCLUDES
+for cppflag in $APPEND_INCLUDES
 do
-    APPEND_CFLAGS+=" -I$cflag"
+    APPEND_CPPFLAGS="$APPEND_CPPFLAGS -I$cppflag"
 done
 for ldflag in $APPEND_LIB
 do
-    APPEND_LDFLAGS+=" -L$ldflag"
+    APPEND_LDFLAGS="$APPEND_LDFLAGS -L$ldflag"
 done
-CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
+CPPFLAGS="$PREPEND_CPPFLAGS $CPPFLAGS $APPEND_CPPFLAGS"
 LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"])
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:11: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 1SkGNR-0002H5-6F; Thu, 28 Jun 2012 15:11:25 +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 1SkGNP-0002Gg-L2
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:11:23 +0000
Received: from [85.158.143.35:48836] by server-1.bemta-4.messagelabs.com id
	1A/7C-24392-A147CEF4; Thu, 28 Jun 2012 15:11:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340896280!13130562!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24979 invoked from network); 28 Jun 2012 15:11:22 -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;
	28 Jun 2012 15:11:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336363200"; d="scan'208";a="200386207"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:11:17 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:11:16 -0400
Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<roger.pau@citrix.com>)	id 1SkGNI-0006rJ-3l;
	Thu, 28 Jun 2012 16:11:16 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 16:10:33 +0100
Message-ID: <1340896233-9523-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: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] autoconf: correctly parse *_INCLUDES and
	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Parse those options correctly, since the "+=" operator is not valid.
Also added CPPFLAGS, so headers checks don't give strange results.

Please rerun configure after applying.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/m4/set_cflags_ldflags.m4 |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/m4/set_cflags_ldflags.m4 b/tools/m4/set_cflags_ldflags.m4
index 7e357ba..cbad3c1 100644
--- a/tools/m4/set_cflags_ldflags.m4
+++ b/tools/m4/set_cflags_ldflags.m4
@@ -1,20 +1,20 @@
 AC_DEFUN([AX_SET_FLAGS],
-[for cflag in $PREPEND_INCLUDES
+[for cppflag in $PREPEND_INCLUDES
 do
-    PREPEND_CFLAGS+=" -I$cflag"
+    PREPEND_CPPFLAGS="$PREPEND_CPPFLAGS -I$cppflag"
 done
 for ldflag in $PREPEND_LIB
 do
-    PREPEND_LDFLAGS+=" -L$ldflag"
+    PREPEND_LDFLAGS="$PREPEND_LDFLAGS -L$ldflag"
 done
-for cflag in $APPEND_INCLUDES
+for cppflag in $APPEND_INCLUDES
 do
-    APPEND_CFLAGS+=" -I$cflag"
+    APPEND_CPPFLAGS="$APPEND_CPPFLAGS -I$cppflag"
 done
 for ldflag in $APPEND_LIB
 do
-    APPEND_LDFLAGS+=" -L$ldflag"
+    APPEND_LDFLAGS="$APPEND_LDFLAGS -L$ldflag"
 done
-CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
+CPPFLAGS="$PREPEND_CPPFLAGS $CPPFLAGS $APPEND_CPPFLAGS"
 LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"])
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:12:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGOl-0002ST-Mr; Thu, 28 Jun 2012 15:12: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 1SkGOj-0002SG-Og
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:12:45 +0000
Received: from [85.158.138.51:17403] by server-7.bemta-3.messagelabs.com id
	2C/11-10113-6647CEF4; Thu, 28 Jun 2012 15:12:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340896357!28862736!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9751 invoked from network); 28 Jun 2012 15:12:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:12:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:12:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 16:12:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkGOX-00015L-Ux; Thu, 28 Jun 2012 15:12:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkGOX-00084v-Tv;
	Thu, 28 Jun 2012 16:12:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.29793.913077.572591@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 16:12:33 +0100
To: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>, Ian Campbell
	<ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>,
	<20120628081142.GA32085@ocelot.phlegethon.org>,
	<CC11D3D3.442F5%keir@xen.org>
References: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
	<CC11D3D3.442F5%keir@xen.org>
	<20120628081142.GA32085@ocelot.phlegethon.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] [PATCH] docs: Use lists.xen.org not
	lists.xensource.com [and 2 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 ("[Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> docs: Use lists.xen.org not lists.xensource.com

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Tim Deegan writes ("Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> May as well s/greatful/grateful/ while you're editing this line. :)
> (and again below).

I did 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 Jun 28 15:12:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGOl-0002ST-Mr; Thu, 28 Jun 2012 15:12: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 1SkGOj-0002SG-Og
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:12:45 +0000
Received: from [85.158.138.51:17403] by server-7.bemta-3.messagelabs.com id
	2C/11-10113-6647CEF4; Thu, 28 Jun 2012 15:12:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340896357!28862736!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9751 invoked from network); 28 Jun 2012 15:12:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:12:37 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:12:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 16:12:37 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkGOX-00015L-Ux; Thu, 28 Jun 2012 15:12:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkGOX-00084v-Tv;
	Thu, 28 Jun 2012 16:12:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.29793.913077.572591@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 16:12:33 +0100
To: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>, Ian Campbell
	<ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>,
	<20120628081142.GA32085@ocelot.phlegethon.org>,
	<CC11D3D3.442F5%keir@xen.org>
References: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
	<CC11D3D3.442F5%keir@xen.org>
	<20120628081142.GA32085@ocelot.phlegethon.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] [PATCH] docs: Use lists.xen.org not
	lists.xensource.com [and 2 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 ("[Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> docs: Use lists.xen.org not lists.xensource.com

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Tim Deegan writes ("Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> May as well s/greatful/grateful/ while you're editing this line. :)
> (and again below).

I did 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 Jun 28 15:13:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:13: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 1SkGPi-0002Zd-9e; Thu, 28 Jun 2012 15:13: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 1SkGPh-0002ZH-2X
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:13:45 +0000
Received: from [85.158.143.35:65162] by server-3.bemta-4.messagelabs.com id
	BE/B8-05808-8A47CEF4; Thu, 28 Jun 2012 15:13:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340896422!14559873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32461 invoked from network); 28 Jun 2012 15:13:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15: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.213.0;
	Thu, 28 Jun 2012 16:13:42 +0100
Message-ID: <1340896420.10942.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 16:13:40 +0100
In-Reply-To: <20460.29793.913077.572591@mariner.uk.xensource.com>
References: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
	<CC11D3D3.442F5%keir@xen.org>
	<20120628081142.GA32085@ocelot.phlegethon.org>
	<20460.29793.913077.572591@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "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] [PATCH] docs: Use lists.xen.org not
 lists.xensource.com [and 2 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 16:12 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> > docs: Use lists.xen.org not lists.xensource.com
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Tim Deegan writes ("Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> > May as well s/greatful/grateful/ while you're editing this line. :)
> > (and again below).
> 
> I did this.

So did I in my resend which you haven't got to yet ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:13:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:13: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 1SkGPi-0002Zd-9e; Thu, 28 Jun 2012 15:13: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 1SkGPh-0002ZH-2X
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:13:45 +0000
Received: from [85.158.143.35:65162] by server-3.bemta-4.messagelabs.com id
	BE/B8-05808-8A47CEF4; Thu, 28 Jun 2012 15:13:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340896422!14559873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32461 invoked from network); 28 Jun 2012 15:13:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15: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.213.0;
	Thu, 28 Jun 2012 16:13:42 +0100
Message-ID: <1340896420.10942.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 16:13:40 +0100
In-Reply-To: <20460.29793.913077.572591@mariner.uk.xensource.com>
References: <bffb9db1332434164c44.1340869166@cosworth.uk.xensource.com>
	<CC11D3D3.442F5%keir@xen.org>
	<20120628081142.GA32085@ocelot.phlegethon.org>
	<20460.29793.913077.572591@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "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] [PATCH] docs: Use lists.xen.org not
 lists.xensource.com [and 2 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 16:12 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> > docs: Use lists.xen.org not lists.xensource.com
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Tim Deegan writes ("Re: [Xen-devel] [PATCH] docs: Use lists.xen.org not lists.xensource.com"):
> > May as well s/greatful/grateful/ while you're editing this line. :)
> > (and again below).
> 
> I did this.

So did I in my resend which you haven't got to yet ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:15:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:15: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 1SkGQz-0002kO-P3; Thu, 28 Jun 2012 15:15:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGQx-0002k4-Kd
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:15:04 +0000
Received: from [85.158.138.51:5067] by server-2.bemta-3.messagelabs.com id
	01/FC-10266-6F47CEF4; Thu, 28 Jun 2012 15:15:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340896502!23684718!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17013 invoked from network); 28 Jun 2012 15:15:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:15:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:15:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 16:15:01 +0100
Message-ID: <1340896499.10942.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 16:14:59 +0100
In-Reply-To: <20460.29531.933964.18000@mariner.uk.xensource.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
	<20460.29531.933964.18000@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Matt Wilson <msw@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 16:08 +0100, Ian Jackson wrote:
> Matt Wilson writes ("[Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> > diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> > @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
> >  this, by ensuring certain VCPUs can only run on certain physical
> >  CPUs.
> >  
> > +=item B<vm-list>
> > +
> > +Prints information about all domains except for dom0.
> 
> Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
> etc. ?  IMO it should, and the docs should say so.

Usually we would say "guest" rather than "domain" to convey this (a
guest might consist of multiple domains).

> If it doesn't then that's IMO a bug but stubdoms are a bit buggy
> anyway so I don't regard fixing that as a blocker for this patch.  But
> I think we should introduce docs that are correct.
> 
> If you and Ian agree, perhaps you'd like to clarify that (and perhaps
> change the usage message too).

I'm happy for the docs to change to reflect what we want but I don't
want to delay this patch actually making the implementation match.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:15:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:15: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 1SkGQz-0002kO-P3; Thu, 28 Jun 2012 15:15:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGQx-0002k4-Kd
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:15:04 +0000
Received: from [85.158.138.51:5067] by server-2.bemta-3.messagelabs.com id
	01/FC-10266-6F47CEF4; Thu, 28 Jun 2012 15:15:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340896502!23684718!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17013 invoked from network); 28 Jun 2012 15:15:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:15:02 -0000
X-IronPort-AV: E=Sophos;i="4.77,491,1336348800"; d="scan'208";a="13273576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:15:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 16:15:01 +0100
Message-ID: <1340896499.10942.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 16:14:59 +0100
In-Reply-To: <20460.29531.933964.18000@mariner.uk.xensource.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
	<20460.29531.933964.18000@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Matt Wilson <msw@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, 2012-06-28 at 16:08 +0100, Ian Jackson wrote:
> Matt Wilson writes ("[Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> > diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> > @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
> >  this, by ensuring certain VCPUs can only run on certain physical
> >  CPUs.
> >  
> > +=item B<vm-list>
> > +
> > +Prints information about all domains except for dom0.
> 
> Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
> etc. ?  IMO it should, and the docs should say so.

Usually we would say "guest" rather than "domain" to convey this (a
guest might consist of multiple domains).

> If it doesn't then that's IMO a bug but stubdoms are a bit buggy
> anyway so I don't regard fixing that as a blocker for this patch.  But
> I think we should introduce docs that are correct.
> 
> If you and Ian agree, perhaps you'd like to clarify that (and perhaps
> change the usage message too).

I'm happy for the docs to change to reflect what we want but I don't
want to delay this patch actually making the implementation match.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:16:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGSW-0002wB-8p; Thu, 28 Jun 2012 15:16:40 +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 1SkGSU-0002vq-ND
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:16:38 +0000
Received: from [193.109.254.147:57231] by server-12.bemta-14.messagelabs.com
	id AF/69-30461-5557CEF4; Thu, 28 Jun 2012 15:16:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340896597!9132768!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7233 invoked from network); 28 Jun 2012 15:16:37 -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; 28 Jun 2012 15:16:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkGSS-000Dhe-S7; Thu, 28 Jun 2012 15:16:36 +0000
Date: Thu, 28 Jun 2012 16:16:36 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628151636.GA48670@ocelot.phlegethon.org>
References: <patchbomb.1340893181@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1340893181@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 v3] xen,
	pod: Populate-on-demand reclaim 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

At 15:19 +0100 on 28 Jun (1340896781), George Dunlap wrote:
> xen,pod: Populate-on-demand reclaim improvements
> 
> Rework populate-on-demand sweeping
> 
> Last summer I did some work on testing whether our PoD sweeping code
> was achieving its goals: namely, never crashing unnecessairly,
> minimizing boot time, and maximizing the number of superpages in the
> p2m table.
> 
> This is the resulting patch series.

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 Jun 28 15:16:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGSW-0002wB-8p; Thu, 28 Jun 2012 15:16:40 +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 1SkGSU-0002vq-ND
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:16:38 +0000
Received: from [193.109.254.147:57231] by server-12.bemta-14.messagelabs.com
	id AF/69-30461-5557CEF4; Thu, 28 Jun 2012 15:16:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1340896597!9132768!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7233 invoked from network); 28 Jun 2012 15:16:37 -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; 28 Jun 2012 15:16:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkGSS-000Dhe-S7; Thu, 28 Jun 2012 15:16:36 +0000
Date: Thu, 28 Jun 2012 16:16:36 +0100
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20120628151636.GA48670@ocelot.phlegethon.org>
References: <patchbomb.1340893181@elijah>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1340893181@elijah>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 v3] xen,
	pod: Populate-on-demand reclaim 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

At 15:19 +0100 on 28 Jun (1340896781), George Dunlap wrote:
> xen,pod: Populate-on-demand reclaim improvements
> 
> Rework populate-on-demand sweeping
> 
> Last summer I did some work on testing whether our PoD sweeping code
> was achieving its goals: namely, never crashing unnecessairly,
> minimizing boot time, and maximizing the number of superpages in the
> p2m table.
> 
> This is the resulting patch series.

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 Jun 28 15:18:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:18: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 1SkGTs-00036A-Oj; Thu, 28 Jun 2012 15:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SkGTr-00035y-KC
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:18:03 +0000
Received: from [85.158.143.35:33792] by server-1.bemta-4.messagelabs.com id
	BF/47-24392-AA57CEF4; Thu, 28 Jun 2012 15:18:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340896682!6748736!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14033 invoked from network); 28 Jun 2012 15:18:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 15:18:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkGTp-000Dir-Qm; Thu, 28 Jun 2012 15:18:01 +0000
Date: Thu, 28 Jun 2012 16:18:01 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628151801.GB48670@ocelot.phlegethon.org>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:39 +0100 on 26 Jun (1340703582), Ian Campbell wrote:
> hypervisor, nice to have:
> 
>     * PoD performance improvements (George Dunlap, and reviewed
>       awaiting repost)

Reposted, and applied: DONE.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:18:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:18: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 1SkGTs-00036A-Oj; Thu, 28 Jun 2012 15:18:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1SkGTr-00035y-KC
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:18:03 +0000
Received: from [85.158.143.35:33792] by server-1.bemta-4.messagelabs.com id
	BF/47-24392-AA57CEF4; Thu, 28 Jun 2012 15:18:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340896682!6748736!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14033 invoked from network); 28 Jun 2012 15:18:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 15:18:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1SkGTp-000Dir-Qm; Thu, 28 Jun 2012 15:18:01 +0000
Date: Thu, 28 Jun 2012 16:18:01 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628151801.GB48670@ocelot.phlegethon.org>
References: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340699982.3832.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:39 +0100 on 26 Jun (1340703582), Ian Campbell wrote:
> hypervisor, nice to have:
> 
>     * PoD performance improvements (George Dunlap, and reviewed
>       awaiting repost)

Reposted, and applied: DONE.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:18:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkGUR-0003AG-6R; Thu, 28 Jun 2012 15:18:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SkGUP-00039r-GI
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:18:37 +0000
Received: from [193.109.254.147:30075] by server-12.bemta-14.messagelabs.com
	id D3/3C-30461-CC57CEF4; Thu, 28 Jun 2012 15:18:36 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340896713!2245562!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26212 invoked from network); 28 Jun 2012 15:18:35 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 15:18:35 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5SFIUKD009774
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 08:18:32 -0700
Received: by bkwj10 with SMTP id j10so2363571bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 08:18:29 -0700 (PDT)
Received: by 10.204.154.138 with SMTP id o10mr1495546bkw.34.1340896709476;
	Thu, 28 Jun 2012 08:18:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Thu, 28 Jun 2012 08:17:49 -0700 (PDT)
In-Reply-To: <20460.26922.21629.642044@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
	<1340891415.10942.53.camel@zakaz.uk.xensource.com>
	<20460.26922.21629.642044@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 28 Jun 2012 11:17:49 -0400
Message-ID: <CAP8mzPMBswx7q0fT21HKnHV2JACAN=-tVa3EKHOKSwmQhvq2Yg@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3671055743261617097=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3671055743261617097==
Content-Type: multipart/alternative; boundary=0015175df2160c805904c389d866

--0015175df2160c805904c389d866
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 28, 2012 at 10:24 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Ian Campbell writes ("Re: [PATCH v6 00/21] libxl: domain save/restore: run
> in a separate process"):
> > Does this mean this series is now ready to go in?
>
> I think so.  I'm just giving Shriram a chance to object.
>
>
I have no objections. I just finished testing the series with
xm (to ensure xend/remus was not broken). xl remus also fails over properly.
Things are good on that front.

But for the test case where I kill the backup (even with remote
host replication), xl still crashes
the primary. [xend works properly in this case]. xl error output is at the
end of the mail.

Either way, I have no objections to this series.
Tested-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>


There is a more pressing matter that I just noticed.
The performance is extremely abysmal! Especially with xl.
Here is a comparative analysis between xend/remus and xl/remus
for a PV domU w/ and w/o suspend-event channel.

What is being measured ? time to suspend + time to resume
 I am primarily concerned with the time to suspend and time to resume.
With event channel, this should be on the order of 1ms or so. With
xenstore,
I would expect this to be max 5-7ms.
NB: This does not include the memcpy phase in xc_domain_save

Results: 32-bit PV domU w/ suspend event channel (2.6.32.2 xenolinux kernel)
xl-remus: ~1ms
xend-remus: ~1ms

So, for guests with suspend event channel support,
remus with xl/xend has the same suspend/resume overhead.

64-bit PV domU w/o suspend event channel (3.3.0 upstream kernel)
xl-remus: ~202ms !!!
xend-remus: ~2.2ms

This 202ms figure is same in both IanJ's tree and the baseline xen-unstable.

Looking back at the logs, this has been the same since January.
Is there some fixed timeout lurking in the code somewhere ?


====
xl error output, when killing backup VM (it crashes primary VM instead of
resuming
it properly)
libxl: error: libxl_create.c:760:libxl__xc_domain_restore_done: restoring
domain: Resource temporarily unavailable
libxl: error: libxl_create.c:844:domcreate_rebuild_done: cannot (re-)build
domain: -3
libxl: error: libxl.c:1220:libxl_domain_destroy: non-existant domain 24
libxl: error: libxl_create.c:995:domcreate_complete: unable to destroy
domain 24 following failed creation
migration target: Domain creation failed (code -3).
pagetables=2,cache_misses=0,emptypages=41
libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated
reading ipc msg header from domain 3 save/restore helper stdout pipe
libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 3
save/restore helper [5620] died due to fatal signal Broken pipe
remus sender: libxl_domain_suspend failed (rc=-3)
Remus: Backup failed? resuming domain at primary.


thanks
shriram

--0015175df2160c805904c389d866
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 28, 2012 at 10:24 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">



Ian Campbell writes (&quot;Re: [PATCH v6 00/21] libxl: domain save/restore:=
 run in a separate process&quot;):<br>
<div>&gt; Does this mean this series is now ready to go in?<br>
<br>
</div>I think so. =A0I&#39;m just giving Shriram a chance to object.<br>
<div><br></div></blockquote><div><br></div><div>I have no objections. I jus=
t finished testing the series with</div><div>xm (to ensure xend/remus was n=
ot broken).=A0xl remus also fails over properly.</div><div>Things are good =
on that front.</div>


<div><br></div><div>But for the test case where I kill the backup (even wit=
h remote host=A0replication), xl still crashes</div><div>the primary. [xend=
 works properly in this case]. xl error output is at the end of the mail.</=
div>

<div><br></div><div>Either way, I have no objections to this series.</div><=
div>Tested-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca=
">rshriram@cs.ubc.ca</a>&gt;</div><div><br></div><div><br></div><div>There =
is a more pressing matter that I just noticed.</div>

<div>The performance is extremely abysmal! Especially with xl.</div><div>He=
re is a comparative analysis between xend/remus and xl/remus=A0</div><div>f=
or a PV domU w/ and w/o suspend-event channel.</div>
<div><br></div><div>What is being measured ?=A0time to suspend + time to re=
sume</div><div>=A0I am primarily concerned with the time to suspend and tim=
e to resume.=A0</div><div>With event channel,=A0this should be on the order=
 of 1ms or so. With xenstore,=A0</div>


<div>I would expect this to be max 5-7ms.</div><div>NB: This does not inclu=
de the memcpy phase in xc_domain_save</div>
<div><br></div><div>Results:=A032-bit PV domU w/ suspend event channel (2.6=
.32.2 xenolinux kernel)</div><div>xl-remus: ~1ms</div><div>xend-remus: ~1ms=
</div><div><br></div><div>So, for guests with suspend event channel support=
,=A0</div>


<div>remus with xl/xend has the same suspend/resume overhead.</div>
<div><br></div><div>64-bit PV domU w/o suspend event channel (3.3.0 upstrea=
m kernel)</div><div><div>xl-remus: ~202ms !!!</div><div>xend-remus: ~2.2ms<=
/div></div><div><br></div><div>This 202ms figure is same in both IanJ&#39;s=
 tree and the baseline xen-unstable.</div>



<div><br></div><div>Looking back at the logs, this has been the same since =
January.=A0</div><div>Is there some fixed=A0timeout lurking in the code som=
ewhere ?</div><div><br></div><div><br></div><div>=3D=3D=3D=3D</div><div>xl =
error output, when killing backup VM (it crashes primary VM instead of resu=
ming</div>

<div>it properly)</div><div><div><div>libxl: error: libxl_create.c:760:libx=
l__xc_domain_restore_done: restoring domain: Resource temporarily unavailab=
le</div><div>libxl: error: libxl_create.c:844:domcreate_rebuild_done: canno=
t (re-)build domain: -3</div>

<div>libxl: error: libxl.c:1220:libxl_domain_destroy: non-existant domain 2=
4</div><div>libxl: error: libxl_create.c:995:domcreate_complete: unable to =
destroy domain 24 following failed creation</div><div>migration target: Dom=
ain creation failed (code -3).</div>

<div>pagetables=3D2,cache_misses=3D0,emptypages=3D41</div><div>libxl: error=
: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading ipc m=
sg header from domain 3 save/restore helper stdout pipe</div><div>libxl: er=
ror: libxl_exec.c:129:libxl_report_child_exitstatus: domain 3 save/restore =
helper [5620] died due to fatal signal Broken pipe</div>

<div>remus sender: libxl_domain_suspend failed (rc=3D-3)</div><div>Remus: B=
ackup failed? resuming domain at primary.</div></div></div><div><br></div><=
div><br></div><div>thanks</div><div>shriram</div></div>

--0015175df2160c805904c389d866--


--===============3671055743261617097==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3671055743261617097==--


From xen-devel-bounces@lists.xen.org Thu Jun 28 15:18:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkGUR-0003AG-6R; Thu, 28 Jun 2012 15:18:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1SkGUP-00039r-GI
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:18:37 +0000
Received: from [193.109.254.147:30075] by server-12.bemta-14.messagelabs.com
	id D3/3C-30461-CC57CEF4; Thu, 28 Jun 2012 15:18:36 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340896713!2245562!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26212 invoked from network); 28 Jun 2012 15:18:35 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 15:18:35 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q5SFIUKD009774
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 08:18:32 -0700
Received: by bkwj10 with SMTP id j10so2363571bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 08:18:29 -0700 (PDT)
Received: by 10.204.154.138 with SMTP id o10mr1495546bkw.34.1340896709476;
	Thu, 28 Jun 2012 08:18:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.152.215 with HTTP; Thu, 28 Jun 2012 08:17:49 -0700 (PDT)
In-Reply-To: <20460.26922.21629.642044@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
	<1340891415.10942.53.camel@zakaz.uk.xensource.com>
	<20460.26922.21629.642044@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 28 Jun 2012 11:17:49 -0400
Message-ID: <CAP8mzPMBswx7q0fT21HKnHV2JACAN=-tVa3EKHOKSwmQhvq2Yg@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in
	a separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3671055743261617097=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3671055743261617097==
Content-Type: multipart/alternative; boundary=0015175df2160c805904c389d866

--0015175df2160c805904c389d866
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 28, 2012 at 10:24 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Ian Campbell writes ("Re: [PATCH v6 00/21] libxl: domain save/restore: run
> in a separate process"):
> > Does this mean this series is now ready to go in?
>
> I think so.  I'm just giving Shriram a chance to object.
>
>
I have no objections. I just finished testing the series with
xm (to ensure xend/remus was not broken). xl remus also fails over properly.
Things are good on that front.

But for the test case where I kill the backup (even with remote
host replication), xl still crashes
the primary. [xend works properly in this case]. xl error output is at the
end of the mail.

Either way, I have no objections to this series.
Tested-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>


There is a more pressing matter that I just noticed.
The performance is extremely abysmal! Especially with xl.
Here is a comparative analysis between xend/remus and xl/remus
for a PV domU w/ and w/o suspend-event channel.

What is being measured ? time to suspend + time to resume
 I am primarily concerned with the time to suspend and time to resume.
With event channel, this should be on the order of 1ms or so. With
xenstore,
I would expect this to be max 5-7ms.
NB: This does not include the memcpy phase in xc_domain_save

Results: 32-bit PV domU w/ suspend event channel (2.6.32.2 xenolinux kernel)
xl-remus: ~1ms
xend-remus: ~1ms

So, for guests with suspend event channel support,
remus with xl/xend has the same suspend/resume overhead.

64-bit PV domU w/o suspend event channel (3.3.0 upstream kernel)
xl-remus: ~202ms !!!
xend-remus: ~2.2ms

This 202ms figure is same in both IanJ's tree and the baseline xen-unstable.

Looking back at the logs, this has been the same since January.
Is there some fixed timeout lurking in the code somewhere ?


====
xl error output, when killing backup VM (it crashes primary VM instead of
resuming
it properly)
libxl: error: libxl_create.c:760:libxl__xc_domain_restore_done: restoring
domain: Resource temporarily unavailable
libxl: error: libxl_create.c:844:domcreate_rebuild_done: cannot (re-)build
domain: -3
libxl: error: libxl.c:1220:libxl_domain_destroy: non-existant domain 24
libxl: error: libxl_create.c:995:domcreate_complete: unable to destroy
domain 24 following failed creation
migration target: Domain creation failed (code -3).
pagetables=2,cache_misses=0,emptypages=41
libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated
reading ipc msg header from domain 3 save/restore helper stdout pipe
libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 3
save/restore helper [5620] died due to fatal signal Broken pipe
remus sender: libxl_domain_suspend failed (rc=-3)
Remus: Backup failed? resuming domain at primary.


thanks
shriram

--0015175df2160c805904c389d866
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 28, 2012 at 10:24 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">



Ian Campbell writes (&quot;Re: [PATCH v6 00/21] libxl: domain save/restore:=
 run in a separate process&quot;):<br>
<div>&gt; Does this mean this series is now ready to go in?<br>
<br>
</div>I think so. =A0I&#39;m just giving Shriram a chance to object.<br>
<div><br></div></blockquote><div><br></div><div>I have no objections. I jus=
t finished testing the series with</div><div>xm (to ensure xend/remus was n=
ot broken).=A0xl remus also fails over properly.</div><div>Things are good =
on that front.</div>


<div><br></div><div>But for the test case where I kill the backup (even wit=
h remote host=A0replication), xl still crashes</div><div>the primary. [xend=
 works properly in this case]. xl error output is at the end of the mail.</=
div>

<div><br></div><div>Either way, I have no objections to this series.</div><=
div>Tested-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca=
">rshriram@cs.ubc.ca</a>&gt;</div><div><br></div><div><br></div><div>There =
is a more pressing matter that I just noticed.</div>

<div>The performance is extremely abysmal! Especially with xl.</div><div>He=
re is a comparative analysis between xend/remus and xl/remus=A0</div><div>f=
or a PV domU w/ and w/o suspend-event channel.</div>
<div><br></div><div>What is being measured ?=A0time to suspend + time to re=
sume</div><div>=A0I am primarily concerned with the time to suspend and tim=
e to resume.=A0</div><div>With event channel,=A0this should be on the order=
 of 1ms or so. With xenstore,=A0</div>


<div>I would expect this to be max 5-7ms.</div><div>NB: This does not inclu=
de the memcpy phase in xc_domain_save</div>
<div><br></div><div>Results:=A032-bit PV domU w/ suspend event channel (2.6=
.32.2 xenolinux kernel)</div><div>xl-remus: ~1ms</div><div>xend-remus: ~1ms=
</div><div><br></div><div>So, for guests with suspend event channel support=
,=A0</div>


<div>remus with xl/xend has the same suspend/resume overhead.</div>
<div><br></div><div>64-bit PV domU w/o suspend event channel (3.3.0 upstrea=
m kernel)</div><div><div>xl-remus: ~202ms !!!</div><div>xend-remus: ~2.2ms<=
/div></div><div><br></div><div>This 202ms figure is same in both IanJ&#39;s=
 tree and the baseline xen-unstable.</div>



<div><br></div><div>Looking back at the logs, this has been the same since =
January.=A0</div><div>Is there some fixed=A0timeout lurking in the code som=
ewhere ?</div><div><br></div><div><br></div><div>=3D=3D=3D=3D</div><div>xl =
error output, when killing backup VM (it crashes primary VM instead of resu=
ming</div>

<div>it properly)</div><div><div><div>libxl: error: libxl_create.c:760:libx=
l__xc_domain_restore_done: restoring domain: Resource temporarily unavailab=
le</div><div>libxl: error: libxl_create.c:844:domcreate_rebuild_done: canno=
t (re-)build domain: -3</div>

<div>libxl: error: libxl.c:1220:libxl_domain_destroy: non-existant domain 2=
4</div><div>libxl: error: libxl_create.c:995:domcreate_complete: unable to =
destroy domain 24 following failed creation</div><div>migration target: Dom=
ain creation failed (code -3).</div>

<div>pagetables=3D2,cache_misses=3D0,emptypages=3D41</div><div>libxl: error=
: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading ipc m=
sg header from domain 3 save/restore helper stdout pipe</div><div>libxl: er=
ror: libxl_exec.c:129:libxl_report_child_exitstatus: domain 3 save/restore =
helper [5620] died due to fatal signal Broken pipe</div>

<div>remus sender: libxl_domain_suspend failed (rc=3D-3)</div><div>Remus: B=
ackup failed? resuming domain at primary.</div></div></div><div><br></div><=
div><br></div><div>thanks</div><div>shriram</div></div>

--0015175df2160c805904c389d866--


--===============3671055743261617097==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3671055743261617097==--


From xen-devel-bounces@lists.xen.org Thu Jun 28 15:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGXv-0003Ud-1k; Thu, 28 Jun 2012 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 <raistlin@linux.it>) id 1SkGXt-0003UT-LS
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:22:13 +0000
Received: from [85.158.139.83:57581] by server-11.bemta-5.messagelabs.com id
	3A/27-20400-4A67CEF4; Thu, 28 Jun 2012 15:22:12 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340896932!26055790!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21425 invoked from network); 28 Jun 2012 15:22:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 15:22:12 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79198862; Thu, 28 Jun 2012 17:22:11 +0200
Message-ID: <1340896924.21008.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 28 Jun 2012 17:22:04 +0200
In-Reply-To: <1340895534.10942.64.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
	<1340895534.10942.64.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============1335179672897997416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1335179672897997416==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-WIxObYJT0cOgTNZ2mLll"


--=-WIxObYJT0cOgTNZ2mLll
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 15:58 +0100, Ian Campbell wrote:
> On Thu, 2012-06-28 at 15:54 +0100, Ian Jackson wrote:
> > Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate =
cpumap with specific size"):
> > > Change from v2:
> > > Rebase on top of latest head.
> > >=20
> > > Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> > > number of physical cpus. In some place, we may want to allocate
> > > specific size of cpumap.  This patch allow to pass a argument to
> > > specific the size that you want to allocate. If pass 0, it means the
> > > size is equal to number of physical cpus.
> >=20
> > Isn't this same objective achieved in a more general way by Dario's
> >   [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap
>=20
Well, there's sure is a clash, as I'm changing the name of map data
structure. If you check this in, I'll rebase mine one on top of it.


> Didn't Dario's patch build on this one, or perhaps incorporate it?
>=20
No, or at least not yet, as this patch is not in yet. Anyway, that's of
course possible, just decide what you prefer. :-)

Merging this patch and my 05/10 won't be that hard, and I can take care
of it, and the same should apply to this "[Xen-devel] [PATCH v4 ]libxl:
allow to set more than 31 vcpus".

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-WIxObYJT0cOgTNZ2mLll
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sdpwACgkQk4XaBE3IOsSdlgCfZ+q4r8Lw/wL0PetmSXrNk3oI
4hYAn3bwYbTjIH6suz1+Z6COYQ7tSnyh
=mF1t
-----END PGP SIGNATURE-----

--=-WIxObYJT0cOgTNZ2mLll--



--===============1335179672897997416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1335179672897997416==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 15:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGXv-0003Ud-1k; Thu, 28 Jun 2012 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 <raistlin@linux.it>) id 1SkGXt-0003UT-LS
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:22:13 +0000
Received: from [85.158.139.83:57581] by server-11.bemta-5.messagelabs.com id
	3A/27-20400-4A67CEF4; Thu, 28 Jun 2012 15:22:12 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340896932!26055790!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21425 invoked from network); 28 Jun 2012 15:22:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 15:22:12 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79198862; Thu, 28 Jun 2012 17:22:11 +0200
Message-ID: <1340896924.21008.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 28 Jun 2012 17:22:04 +0200
In-Reply-To: <1340895534.10942.64.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
	<1340895534.10942.64.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============1335179672897997416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1335179672897997416==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-WIxObYJT0cOgTNZ2mLll"


--=-WIxObYJT0cOgTNZ2mLll
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 15:58 +0100, Ian Campbell wrote:
> On Thu, 2012-06-28 at 15:54 +0100, Ian Jackson wrote:
> > Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate =
cpumap with specific size"):
> > > Change from v2:
> > > Rebase on top of latest head.
> > >=20
> > > Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> > > number of physical cpus. In some place, we may want to allocate
> > > specific size of cpumap.  This patch allow to pass a argument to
> > > specific the size that you want to allocate. If pass 0, it means the
> > > size is equal to number of physical cpus.
> >=20
> > Isn't this same objective achieved in a more general way by Dario's
> >   [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap
>=20
Well, there's sure is a clash, as I'm changing the name of map data
structure. If you check this in, I'll rebase mine one on top of it.


> Didn't Dario's patch build on this one, or perhaps incorporate it?
>=20
No, or at least not yet, as this patch is not in yet. Anyway, that's of
course possible, just decide what you prefer. :-)

Merging this patch and my 05/10 won't be that hard, and I can take care
of it, and the same should apply to this "[Xen-devel] [PATCH v4 ]libxl:
allow to set more than 31 vcpus".

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-WIxObYJT0cOgTNZ2mLll
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sdpwACgkQk4XaBE3IOsSdlgCfZ+q4r8Lw/wL0PetmSXrNk3oI
4hYAn3bwYbTjIH6suz1+Z6COYQ7tSnyh
=mF1t
-----END PGP SIGNATURE-----

--=-WIxObYJT0cOgTNZ2mLll--



--===============1335179672897997416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1335179672897997416==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiJ-0003nT-CP; Thu, 28 Jun 2012 15:32: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 1SkGiH-0003nM-S8
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:32:58 +0000
Received: from [85.158.143.35:33471] by server-2.bemta-4.messagelabs.com id
	4D/75-17938-9297CEF4; Thu, 28 Jun 2012 15:32:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340897575!18574305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32195 invoked from network); 28 Jun 2012 15:32:56 -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;
	28 Jun 2012 15:32:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="29768607"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-L4;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:09 +0000
Message-ID: <1340894890-4369-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 21/21] xen: add assertion in
	default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 setting up the cpu sibling/etc masks on ARM I accidentally and
incorrectly omitted a CPU from it's own sibling mask which caused this
function to return an invalid cpu number which caused errors later when we
tried to access per_cpu data for that invalid cpu.

Add an assert to catch this in the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
---
 xen/common/domctl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..7ca6b08 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -192,6 +192,7 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
     cpu = cpumask_first(&cpu_exclude_map);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
+    ASSERT(cpu < nr_cpu_ids);
     for_each_cpu(i, online)
     {
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiJ-0003nT-CP; Thu, 28 Jun 2012 15:32: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 1SkGiH-0003nM-S8
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:32:58 +0000
Received: from [85.158.143.35:33471] by server-2.bemta-4.messagelabs.com id
	4D/75-17938-9297CEF4; Thu, 28 Jun 2012 15:32:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340897575!18574305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32195 invoked from network); 28 Jun 2012 15:32:56 -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;
	28 Jun 2012 15:32:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="29768607"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-L4;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:09 +0000
Message-ID: <1340894890-4369-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 21/21] xen: add assertion in
	default_vcpu0_location to protect against broken masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 setting up the cpu sibling/etc masks on ARM I accidentally and
incorrectly omitted a CPU from it's own sibling mask which caused this
function to return an invalid cpu number which caused errors later when we
tried to access per_cpu data for that invalid cpu.

Add an assert to catch this in the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
---
 xen/common/domctl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9f1a9ad..7ca6b08 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -192,6 +192,7 @@ static unsigned int default_vcpu0_location(cpumask_t *online)
     cpu = cpumask_first(&cpu_exclude_map);
     if ( cpumask_weight(&cpu_exclude_map) > 1 )
         cpu = cpumask_next(cpu, &cpu_exclude_map);
+    ASSERT(cpu < nr_cpu_ids);
     for_each_cpu(i, online)
     {
         if ( cpumask_test_cpu(i, &cpu_exclude_map) )
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiO-0003pi-HO; Thu, 28 Jun 2012 15:33: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 1SkGiM-0003nf-BQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [85.158.139.83:35927] by server-9.bemta-5.messagelabs.com id
	7C/54-01069-E297CEF4; Thu, 28 Jun 2012 15:33:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25052 invoked from network); 28 Jun 2012 15:33:01 -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;
	28 Jun 2012 15:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389643"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:56 -0400
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 1SkG0x-000630-AE;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:03 +0000
Message-ID: <1340894890-4369-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/21] arm: fix typo
	s/approprately/appropriately/g
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index f3e4d1a..9511c45 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -102,7 +102,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long ng:1;         /* Not-Global */
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz:12;       /* Must be zero */
 
@@ -137,7 +137,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long sbz4:1;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz3:12;
 
@@ -162,7 +162,7 @@ typedef struct {
 
     unsigned long pad2:10;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
 
     unsigned long pad1:24;
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiK-0003nr-P6; Thu, 28 Jun 2012 15:33: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 1SkGiJ-0003nS-Jp
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:32:59 +0000
Received: from [85.158.139.83:35629] by server-12.bemta-5.messagelabs.com id
	A5/AA-25233-A297CEF4; Thu, 28 Jun 2012 15:32:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24828 invoked from network); 28 Jun 2012 15:32:58 -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;
	28 Jun 2012 15:32:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389629"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-4k;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:00 +0000
Message-ID: <1340894890-4369-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/21] arm: the hyp timer seems to work in newer
	model versions, default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 437dc71..1587fa2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -27,8 +27,12 @@
 #include <xen/time.h>
 #include <asm/system.h>
 
-/* Unfortunately the hypervisor timer interrupt appears to be buggy */
-#define USE_HYP_TIMER 0
+/*
+ * Unfortunately the hypervisor timer interrupt appears to be buggy in
+ * some versions of the model. Disable this to use the physical timer
+ * instead.
+ */
+#define USE_HYP_TIMER 1
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiO-0003pi-HO; Thu, 28 Jun 2012 15:33: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 1SkGiM-0003nf-BQ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [85.158.139.83:35927] by server-9.bemta-5.messagelabs.com id
	7C/54-01069-E297CEF4; Thu, 28 Jun 2012 15:33:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25052 invoked from network); 28 Jun 2012 15:33:01 -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;
	28 Jun 2012 15:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389643"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:56 -0400
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 1SkG0x-000630-AE;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:03 +0000
Message-ID: <1340894890-4369-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/21] arm: fix typo
	s/approprately/appropriately/g
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index f3e4d1a..9511c45 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -102,7 +102,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long ng:1;         /* Not-Global */
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz:12;       /* Must be zero */
 
@@ -137,7 +137,7 @@ typedef struct {
     unsigned long af:1;         /* Access Flag */
     unsigned long sbz4:1;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
     unsigned long sbz3:12;
 
@@ -162,7 +162,7 @@ typedef struct {
 
     unsigned long pad2:10;
 
-    /* The base address must be approprately aligned for Block entries */
+    /* The base address must be appropriately aligned for Block entries */
     unsigned long base:28;      /* Base address of block or next table */
 
     unsigned long pad1:24;
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiK-0003nr-P6; Thu, 28 Jun 2012 15:33: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 1SkGiJ-0003nS-Jp
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:32:59 +0000
Received: from [85.158.139.83:35629] by server-12.bemta-5.messagelabs.com id
	A5/AA-25233-A297CEF4; Thu, 28 Jun 2012 15:32:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24828 invoked from network); 28 Jun 2012 15:32:58 -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;
	28 Jun 2012 15:32:58 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389629"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:54 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-4k;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:00 +0000
Message-ID: <1340894890-4369-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/21] arm: the hyp timer seems to work in newer
	model versions, default to using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 437dc71..1587fa2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -27,8 +27,12 @@
 #include <xen/time.h>
 #include <asm/system.h>
 
-/* Unfortunately the hypervisor timer interrupt appears to be buggy */
-#define USE_HYP_TIMER 0
+/*
+ * Unfortunately the hypervisor timer interrupt appears to be buggy in
+ * some versions of the model. Disable this to use the physical timer
+ * instead.
+ */
+#define USE_HYP_TIMER 1
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiN-0003pI-MK; Thu, 28 Jun 2012 15:33: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 1SkGiL-0003ny-N7
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:01 +0000
Received: from [85.158.139.83:15608] by server-10.bemta-5.messagelabs.com id
	8B/76-02190-C297CEF4; Thu, 28 Jun 2012 15:33:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340897577!26058016!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 28 Jun 2012 15:32:59 -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 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389633"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-69;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:01 +0000
Message-ID: <1340894890-4369-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/21] arm: unwind allocations etc on
	arch_domain_create_failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding the necessary teardown/free functions for some modules.

Don't initialise full arch domain state for the idle domain, it's not needed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c     |   42 +++++++++++++++++++++++++-----------------
 xen/arch/arm/gic.h        |    3 +++
 xen/arch/arm/p2m.c        |   15 +++++++++++++++
 xen/arch/arm/vgic.c       |    6 ++++++
 xen/arch/arm/vpl011.c     |    5 +++++
 xen/arch/arm/vpl011.h     |    1 +
 xen/include/asm-arm/p2m.h |    3 +++
 7 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2b5515d..ac6a30d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -317,37 +317,45 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    /* Idle domains do not need this setup */
+    if ( is_idle_domain(d) )
+        return 0;
+
     rc = -ENOMEM;
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
-    if ( !is_idle_domain(d) )
-    {
-        rc = -ENOMEM;
-        if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
-            goto fail;
+    if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
+        goto fail;
 
-        clear_page(d->shared_info);
-        share_xen_page_with_guest(
-                virt_to_page(d->shared_info), d, XENSHARE_writable);
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+        virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-        if ( (rc = p2m_alloc_table(d)) != 0 )
-            goto fail;
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        goto fail;
 
-        if ( (rc = gicv_setup(d)) != 0 )
-            goto fail;
+    if ( (rc = gicv_setup(d)) != 0 )
+        goto fail;
 
-        if ( (rc = domain_vgic_init(d)) != 0 )
-            goto fail;
-    }
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
         goto fail;
 
-    rc = 0;
+    return 0;
+
 fail:
-    /*XXX unwind allocations etc */
+    d->is_dying = DOMDYING_dead;
+    free_xenheap_page(d->shared_info);
+
+    p2m_teardown(d);
+
+    domain_vgic_free(d);
+    domain_uart0_free(d);
+
     return rc;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 018d820..e36d6ad 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -125,7 +125,10 @@
 #define VGIC_IRQ_EVTCHN_CALLBACK 31
 
 extern int domain_vgic_init(struct domain *d);
+extern void domain_vgic_free(struct domain *d);
+
 extern int vcpu_vgic_init(struct vcpu *v);
+
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 67bfeba..073216b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -288,6 +288,21 @@ int p2m_alloc_table(struct domain *d)
     return 0;
 }
 
+void p2m_teardown(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *pg;
+
+    spin_lock(&p2m->lock);
+
+    while ( (pg = page_list_remove_head(&p2m->pages)) )
+        free_domheap_page(pg);
+
+    p2m->first_level = NULL;
+
+    spin_unlock(&p2m->lock);
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index a217151..f2fa927 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,12 @@ int domain_vgic_init(struct domain *d)
     return 0;
 }
 
+void domain_vgic_free(struct domain *d)
+{
+    xfree(d->arch.vgic.shared_irqs);
+    xfree(d->arch.vgic.pending_irqs);
+}
+
 int vcpu_vgic_init(struct vcpu *v)
 {
     int i;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dc8b28..1522667 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -56,6 +56,11 @@ int domain_uart0_init(struct domain *d)
 
 }
 
+void domain_uart0_free(struct domain *d)
+{
+    xfree(d->arch.uart0.buf);
+}
+
 static void uart0_print_char(char c)
 {
     struct vpl011 *uart = &current->domain->arch.uart0;
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
index 952d812..eabd99d 100644
--- a/xen/arch/arm/vpl011.h
+++ b/xen/arch/arm/vpl011.h
@@ -21,6 +21,7 @@
 #define __ARCH_ARM_VPL011_H__
 
 extern int domain_uart0_init(struct domain *d);
+extern void domain_uart0_free(struct domain *d);
 
 #endif
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 666bb88..14e71bf 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,6 +23,9 @@ struct p2m_domain {
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 
+/* Return all the p2m resources to Xen. */
+void p2m_teardown(struct domain *d);
+
 /* Allocate a new p2m table for a domain.
  *
  * Returns 0 for success or -errno.
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiL-0003o1-3x; Thu, 28 Jun 2012 15:33:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiK-0003ne-Ei
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:00 +0000
Received: from [85.158.139.83:15510] by server-11.bemta-5.messagelabs.com id
	0A/CA-20400-B297CEF4; Thu, 28 Jun 2012 15:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24904 invoked from network); 28 Jun 2012 15:32:59 -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;
	28 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389630"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-H5;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:07 +0000
Message-ID: <1340894890-4369-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 19/21] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on init-xenstore-domain.c.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xcutils/Makefile  |    6 ++-
 tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 tools/xcutils/xcbuild.c

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 6c502f1..dcd2c84 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -11,7 +11,7 @@
 XEN_ROOT	= $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-PROGRAMS = xc_restore xc_save readnotes lsevtchn
+PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
 
 CFLAGS += -Werror
 
@@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 
 .PHONY: all
 all: build
@@ -32,6 +33,9 @@ xc_restore: xc_restore.o
 xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xcbuild: xcbuild.o
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
 
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
new file mode 100644
index 0000000..54f5c38
--- /dev/null
+++ b/tools/xcutils/xcbuild.c
@@ -0,0 +1,100 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#include <errno.h>
+
+#include <xenctrl.h>
+#include <xentoollog.h>
+#include <xc_dom.h>
+
+int main(int argc, char **argv)
+{
+	xentoollog_logger *logger;
+	xc_interface *xch;
+	int rv;
+	const char *image;
+	uint32_t domid;
+	xen_domain_handle_t handle;
+	int maxmem = 128; /* MB */
+	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
+	struct xc_dom_image *dom;
+
+	image = (argc < 2) ? "guest.img" : argv[1];
+	printf("Image: %s\n", image);
+	printf("Memory: %dKB\n", memory_kb);
+
+	logger = (xentoollog_logger*)
+		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
+	if ( logger == NULL )
+	{
+		perror("xtl_createlogger_stdiostream");
+		exit(1);
+	}
+
+	xch = xc_interface_open(logger, logger, 0);
+	if ( xch == NULL )
+	{
+		perror("xc_interface_open");
+		exit(1);
+	}
+
+	rv = xc_dom_loginit(xch);
+	if (rv) return rv;
+
+	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	//if (rv) return rv;
+
+	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
+	printf("xc_domain_create: %d (%d)\n", rv, errno);
+	if ( rv < 0 )
+	{
+		perror("xc_domain_create");
+		exit(1);
+	}
+
+	printf("building dom%d\n", domid);
+
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if ( rv < 0)
+	{
+		perror("xc_domain_max_vcpus");
+		exit(1);
+	}
+
+	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
+	if ( rv < 0)
+	{
+		perror("xc_domain_setmaxmem");
+		exit(1);
+	}
+
+	dom = xc_dom_allocate(xch, "", NULL);
+	rv = xc_dom_kernel_file(dom, image);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_unpause(xch, domid);
+	if ( rv )
+	{
+		perror("xc_domain_unpause");
+		exit(1);
+	}
+
+	xc_interface_close(xch);
+
+	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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiN-0003pI-MK; Thu, 28 Jun 2012 15:33: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 1SkGiL-0003ny-N7
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:01 +0000
Received: from [85.158.139.83:15608] by server-10.bemta-5.messagelabs.com id
	8B/76-02190-C297CEF4; Thu, 28 Jun 2012 15:33:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340897577!26058016!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 28 Jun 2012 15:32:59 -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 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389633"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-69;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:01 +0000
Message-ID: <1340894890-4369-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/21] arm: unwind allocations etc on
	arch_domain_create_failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This involves adding the necessary teardown/free functions for some modules.

Don't initialise full arch domain state for the idle domain, it's not needed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c     |   42 +++++++++++++++++++++++++-----------------
 xen/arch/arm/gic.h        |    3 +++
 xen/arch/arm/p2m.c        |   15 +++++++++++++++
 xen/arch/arm/vgic.c       |    6 ++++++
 xen/arch/arm/vpl011.c     |    5 +++++
 xen/arch/arm/vpl011.h     |    1 +
 xen/include/asm-arm/p2m.h |    3 +++
 7 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2b5515d..ac6a30d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -317,37 +317,45 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
     int rc;
 
+    /* Idle domains do not need this setup */
+    if ( is_idle_domain(d) )
+        return 0;
+
     rc = -ENOMEM;
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
-    if ( !is_idle_domain(d) )
-    {
-        rc = -ENOMEM;
-        if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
-            goto fail;
+    if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
+        goto fail;
 
-        clear_page(d->shared_info);
-        share_xen_page_with_guest(
-                virt_to_page(d->shared_info), d, XENSHARE_writable);
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+        virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-        if ( (rc = p2m_alloc_table(d)) != 0 )
-            goto fail;
+    if ( (rc = p2m_alloc_table(d)) != 0 )
+        goto fail;
 
-        if ( (rc = gicv_setup(d)) != 0 )
-            goto fail;
+    if ( (rc = gicv_setup(d)) != 0 )
+        goto fail;
 
-        if ( (rc = domain_vgic_init(d)) != 0 )
-            goto fail;
-    }
+    if ( (rc = domain_vgic_init(d)) != 0 )
+        goto fail;
 
     /* Domain 0 gets a real UART not an emulated one */
     if ( d->domain_id && (rc = domain_uart0_init(d)) != 0 )
         goto fail;
 
-    rc = 0;
+    return 0;
+
 fail:
-    /*XXX unwind allocations etc */
+    d->is_dying = DOMDYING_dead;
+    free_xenheap_page(d->shared_info);
+
+    p2m_teardown(d);
+
+    domain_vgic_free(d);
+    domain_uart0_free(d);
+
     return rc;
 }
 
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 018d820..e36d6ad 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -125,7 +125,10 @@
 #define VGIC_IRQ_EVTCHN_CALLBACK 31
 
 extern int domain_vgic_init(struct domain *d);
+extern void domain_vgic_free(struct domain *d);
+
 extern int vcpu_vgic_init(struct vcpu *v);
+
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 67bfeba..073216b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -288,6 +288,21 @@ int p2m_alloc_table(struct domain *d)
     return 0;
 }
 
+void p2m_teardown(struct domain *d)
+{
+    struct p2m_domain *p2m = &d->arch.p2m;
+    struct page_info *pg;
+
+    spin_lock(&p2m->lock);
+
+    while ( (pg = page_list_remove_head(&p2m->pages)) )
+        free_domheap_page(pg);
+
+    p2m->first_level = NULL;
+
+    spin_unlock(&p2m->lock);
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index a217151..f2fa927 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,12 @@ int domain_vgic_init(struct domain *d)
     return 0;
 }
 
+void domain_vgic_free(struct domain *d)
+{
+    xfree(d->arch.vgic.shared_irqs);
+    xfree(d->arch.vgic.pending_irqs);
+}
+
 int vcpu_vgic_init(struct vcpu *v)
 {
     int i;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dc8b28..1522667 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -56,6 +56,11 @@ int domain_uart0_init(struct domain *d)
 
 }
 
+void domain_uart0_free(struct domain *d)
+{
+    xfree(d->arch.uart0.buf);
+}
+
 static void uart0_print_char(char c)
 {
     struct vpl011 *uart = &current->domain->arch.uart0;
diff --git a/xen/arch/arm/vpl011.h b/xen/arch/arm/vpl011.h
index 952d812..eabd99d 100644
--- a/xen/arch/arm/vpl011.h
+++ b/xen/arch/arm/vpl011.h
@@ -21,6 +21,7 @@
 #define __ARCH_ARM_VPL011_H__
 
 extern int domain_uart0_init(struct domain *d);
+extern void domain_uart0_free(struct domain *d);
 
 #endif
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 666bb88..14e71bf 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,6 +23,9 @@ struct p2m_domain {
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 
+/* Return all the p2m resources to Xen. */
+void p2m_teardown(struct domain *d);
+
 /* Allocate a new p2m table for a domain.
  *
  * Returns 0 for success or -errno.
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiN-0003p7-A3; Thu, 28 Jun 2012 15:33:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiL-0003nw-DR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:01 +0000
Received: from [193.109.254.147:59069] by server-11.bemta-14.messagelabs.com
	id 7F/97-24843-C297CEF4; Thu, 28 Jun 2012 15:33:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340897578!9024442!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16734 invoked from network); 28 Jun 2012 15:32:59 -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;
	28 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389635"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-26;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:59 +0000
Message-ID: <1340894890-4369-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/21] arm: context switch virtual timer
	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/domain.c        |   10 ++++++++++
 xen/include/asm-arm/cpregs.h |    3 +++
 xen/include/asm-arm/domain.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a7b7d4a..2b5515d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -49,6 +49,11 @@ static void ctxt_switch_from(struct vcpu *p)
     p->arch.tpidruro = READ_CP32(TPIDRURO);
     p->arch.tpidrprw = READ_CP32(TPIDRPRW);
 
+    /* Arch timer */
+    p->arch.cntvoff = READ_CP64(CNTVOFF);
+    p->arch.cntv_cval = READ_CP64(CNTV_CVAL);
+    p->arch.cntv_ctl = READ_CP32(CNTV_CTL);
+
     /* 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);
@@ -128,6 +133,11 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_CP32(n->arch.mair1, MAIR1);
     isb();
 
+    /* Arch timer */
+    WRITE_CP64(n->arch.cntvoff, CNTVOFF);
+    WRITE_CP64(n->arch.cntv_cval, CNTV_CVAL);
+    WRITE_CP32(n->arch.cntv_ctl, CNTV_CTL);
+
     /* Control Registers */
     WRITE_CP32(n->arch.actlr, ACTLR);
     WRITE_CP32(n->arch.sctlr, SCTLR);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index bd46942..34a9e93 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -238,10 +238,13 @@
 #define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
 #define CNTVCT          p15,1,c14       /* Time counter value + offset */
 #define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTV_CVAL       p15,3,c14       /* Virt. Timer comparator */
 #define CNTVOFF         p15,4,c14       /* Time counter offset */
 #define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
 #define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
 #define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTV_TVAL       p15,0,c14,c3,0  /* Virt. Timer value */
+#define CNTV_CTL        p15,0,c14,c3,1  /* Virt. TImer control register */
 #define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
 
 /* CP15 CR15: Implementation Defined Registers */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 32deb52..230ea8c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,11 @@ struct arch_vcpu
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
 
+    /* Arch timers */
+    uint64_t cntvoff;
+    uint64_t cntv_cval;
+    uint32_t cntv_ctl;
+
     /* CP 15 */
     uint32_t csselr;
 
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiM-0003ov-UZ; Thu, 28 Jun 2012 15:33: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 1SkGiL-0003ni-5U
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:01 +0000
Received: from [85.158.139.83:35772] by server-7.bemta-5.messagelabs.com id
	85/FC-28276-C297CEF4; Thu, 28 Jun 2012 15:33:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24967 invoked from network); 28 Jun 2012 15:32:59 -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;
	28 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389632"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-BR;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:04 +0000
Message-ID: <1340894890-4369-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/21] HACK: arm: initial
	XENMAPSPACE_gmfn_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

Should use same interface as hybrid x86.
---
 xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
 xen/arch/x86/mm.c             |    2 ++
 xen/include/public/arch-arm.h |    1 +
 xen/include/public/memory.h   |   12 +++++++-----
 4 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 40ac176..d369ee3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -470,12 +470,32 @@ static int xenmem_add_to_physmap_once(
 
     switch ( xatp->space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( xatp->idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+
+        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            printk("bad p2m lookup\n");
+            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+        mfn = maddr >> PAGE_SHIFT;
+        rcu_unlock_domain(od);
+        break;
+    }
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c543f03..8190fa0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4573,6 +4573,8 @@ static int xenmem_add_to_physmap_once(
             mfn = idx;
             page = mfn_to_page(mfn);
             break;
+        case XENMAPSPACE_gmfn_foreign:
+            return -ENOSYS;
         }
         default:
             break;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eb1add9..7ebe966 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
 #define XEN_LEGACY_MAX_VCPUS 1
 
 typedef uint32_t xen_ulong_t;
+#define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiO-0003pW-3i; Thu, 28 Jun 2012 15:33:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiL-0003nw-Uw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [193.109.254.147:55947] by server-11.bemta-14.messagelabs.com
	id D2/A7-24843-D297CEF4; Thu, 28 Jun 2012 15:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340897578!9024442!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16818 invoked from network); 28 Jun 2012 15:33:00 -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;
	28 Jun 2012 15:33:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389641"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-IT;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:08 +0000
Message-ID: <1340894890-4369-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 20/21] HACK: arm: disable hypercall
	continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/sched.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..15fa6b4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
 
+#ifdef CONFIG_ARM
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiL-0003oC-HD; Thu, 28 Jun 2012 15:33:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiK-0003nf-F3
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:00 +0000
Received: from [85.158.139.83:35715] by server-9.bemta-5.messagelabs.com id
	05/34-01069-B297CEF4; Thu, 28 Jun 2012 15:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340897577!26058016!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9804 invoked from network); 28 Jun 2012 15:32:59 -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 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389631"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-8t;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:02 +0000
Message-ID: <1340894890-4369-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/21] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/entry.S            |    1 +
 xen/include/asm-arm/page.h      |    2 ++
 xen/include/asm-arm/processor.h |   21 ---------------------
 xen/include/asm-arm/system.h    |    2 +-
 xen/include/public/arch-arm.h   |   23 ++++++++++++++++++++++-
 5 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 5bc3906..2ff32a1 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
+#include <public/xen.h>
 
 #define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
 #define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 2b6c1780..f3e4d1a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -2,6 +2,8 @@
 #define __ARM_PAGE_H__
 
 #include <xen/config.h>
+#include <public/xen.h>
+#include <asm/processor.h>
 
 #define PADDR_BITS              40
 #define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9b3c9dd..3849b23 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -3,27 +3,6 @@
 
 #include <asm/cpregs.h>
 
-/* PSR bits (CPSR, SPSR)*/
-
-/* 0-4: Mode */
-#define PSR_MODE_MASK 0x1f
-#define PSR_MODE_USR 0x10
-#define PSR_MODE_FIQ 0x11
-#define PSR_MODE_IRQ 0x12
-#define PSR_MODE_SVC 0x13
-#define PSR_MODE_MON 0x16
-#define PSR_MODE_ABT 0x17
-#define PSR_MODE_HYP 0x1a
-#define PSR_MODE_UND 0x1b
-#define PSR_MODE_SYS 0x1f
-
-#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 */
-#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
-
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 7963ea5..216ef1f 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -3,7 +3,7 @@
 #define __ASM_SYSTEM_H
 
 #include <xen/lib.h>
-#include <asm/processor.h>
+#include <public/arch-arm.h>
 
 #define nop() \
     asm volatile ( "nop" )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e915cbf..eb1add9 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -138,7 +138,28 @@ struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif
+#endif /* ifndef __ASSEMBLY __ */
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#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 */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiN-0003p7-A3; Thu, 28 Jun 2012 15:33:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiL-0003nw-DR
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:01 +0000
Received: from [193.109.254.147:59069] by server-11.bemta-14.messagelabs.com
	id 7F/97-24843-C297CEF4; Thu, 28 Jun 2012 15:33:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340897578!9024442!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16734 invoked from network); 28 Jun 2012 15:32:59 -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;
	28 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389635"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-26;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:47:59 +0000
Message-ID: <1340894890-4369-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/21] arm: context switch virtual timer
	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/domain.c        |   10 ++++++++++
 xen/include/asm-arm/cpregs.h |    3 +++
 xen/include/asm-arm/domain.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a7b7d4a..2b5515d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -49,6 +49,11 @@ static void ctxt_switch_from(struct vcpu *p)
     p->arch.tpidruro = READ_CP32(TPIDRURO);
     p->arch.tpidrprw = READ_CP32(TPIDRPRW);
 
+    /* Arch timer */
+    p->arch.cntvoff = READ_CP64(CNTVOFF);
+    p->arch.cntv_cval = READ_CP64(CNTV_CVAL);
+    p->arch.cntv_ctl = READ_CP32(CNTV_CTL);
+
     /* 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);
@@ -128,6 +133,11 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_CP32(n->arch.mair1, MAIR1);
     isb();
 
+    /* Arch timer */
+    WRITE_CP64(n->arch.cntvoff, CNTVOFF);
+    WRITE_CP64(n->arch.cntv_cval, CNTV_CVAL);
+    WRITE_CP32(n->arch.cntv_ctl, CNTV_CTL);
+
     /* Control Registers */
     WRITE_CP32(n->arch.actlr, ACTLR);
     WRITE_CP32(n->arch.sctlr, SCTLR);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index bd46942..34a9e93 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -238,10 +238,13 @@
 #define CNTP_CTL        p15,0,c14,c2,1  /* Physical Timer control register */
 #define CNTVCT          p15,1,c14       /* Time counter value + offset */
 #define CNTP_CVAL       p15,2,c14       /* Physical Timer comparator */
+#define CNTV_CVAL       p15,3,c14       /* Virt. Timer comparator */
 #define CNTVOFF         p15,4,c14       /* Time counter offset */
 #define CNTHCTL         p15,4,c14,c1,0  /* Time counter hyp. control */
 #define CNTHP_TVAL      p15,4,c14,c2,0  /* Hyp. Timer value */
 #define CNTHP_CTL       p15,4,c14,c2,1  /* Hyp. Timer control register */
+#define CNTV_TVAL       p15,0,c14,c3,0  /* Virt. Timer value */
+#define CNTV_CTL        p15,0,c14,c3,1  /* Virt. TImer control register */
 #define CNTHP_CVAL      p15,6,c14       /* Hyp. Timer comparator */
 
 /* CP15 CR15: Implementation Defined Registers */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 32deb52..230ea8c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,11 @@ struct arch_vcpu
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
 
+    /* Arch timers */
+    uint64_t cntvoff;
+    uint64_t cntv_cval;
+    uint32_t cntv_ctl;
+
     /* CP 15 */
     uint32_t csselr;
 
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiM-0003ov-UZ; Thu, 28 Jun 2012 15:33: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 1SkGiL-0003ni-5U
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:01 +0000
Received: from [85.158.139.83:35772] by server-7.bemta-5.messagelabs.com id
	85/FC-28276-C297CEF4; Thu, 28 Jun 2012 15:33:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24967 invoked from network); 28 Jun 2012 15:32:59 -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;
	28 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389632"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-BR;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:04 +0000
Message-ID: <1340894890-4369-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/21] HACK: arm: initial
	XENMAPSPACE_gmfn_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

Should use same interface as hybrid x86.
---
 xen/arch/arm/mm.c             |   32 ++++++++++++++++++++++++++------
 xen/arch/x86/mm.c             |    2 ++
 xen/include/public/arch-arm.h |    1 +
 xen/include/public/memory.h   |   12 +++++++-----
 4 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 40ac176..d369ee3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -470,12 +470,32 @@ static int xenmem_add_to_physmap_once(
 
     switch ( xatp->space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( xatp->idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+
+        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            printk("bad p2m lookup\n");
+            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+        mfn = maddr >> PAGE_SHIFT;
+        rcu_unlock_domain(od);
+        break;
+    }
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c543f03..8190fa0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4573,6 +4573,8 @@ static int xenmem_add_to_physmap_once(
             mfn = idx;
             page = mfn_to_page(mfn);
             break;
+        case XENMAPSPACE_gmfn_foreign:
+            return -ENOSYS;
         }
         default:
             break;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index eb1add9..7ebe966 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -121,6 +121,7 @@ typedef uint64_t xen_pfn_t;
 #define XEN_LEGACY_MAX_VCPUS 1
 
 typedef uint32_t xen_ulong_t;
+#define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..b2adfbe 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -212,11 +212,13 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiL-0003o1-3x; Thu, 28 Jun 2012 15:33:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiK-0003ne-Ei
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:00 +0000
Received: from [85.158.139.83:15510] by server-11.bemta-5.messagelabs.com id
	0A/CA-20400-B297CEF4; Thu, 28 Jun 2012 15:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24904 invoked from network); 28 Jun 2012 15:32:59 -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;
	28 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389630"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-H5;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:07 +0000
Message-ID: <1340894890-4369-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 19/21] HACK: add simple xcbuild
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on init-xenstore-domain.c.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xcutils/Makefile  |    6 ++-
 tools/xcutils/xcbuild.c |  100 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 1 deletions(-)
 create mode 100644 tools/xcutils/xcbuild.c

diff --git a/tools/xcutils/Makefile b/tools/xcutils/Makefile
index 6c502f1..dcd2c84 100644
--- a/tools/xcutils/Makefile
+++ b/tools/xcutils/Makefile
@@ -11,7 +11,7 @@
 XEN_ROOT	= $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-PROGRAMS = xc_restore xc_save readnotes lsevtchn
+PROGRAMS = xc_restore xc_save readnotes lsevtchn xcbuild
 
 CFLAGS += -Werror
 
@@ -19,6 +19,7 @@ CFLAGS_xc_restore.o := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_xc_save.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 CFLAGS_readnotes.o  := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 CFLAGS_lsevtchn.o   := $(CFLAGS_libxenctrl)
+CFLAGS_xcbuild.o    := $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest)
 
 .PHONY: all
 all: build
@@ -32,6 +33,9 @@ xc_restore: xc_restore.o
 xc_save: xc_save.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xcbuild: xcbuild.o
+	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
+
 readnotes: readnotes.o
 	$(CC) $(LDFLAGS) $^ -o $@ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(APPEND_LDFLAGS)
 
diff --git a/tools/xcutils/xcbuild.c b/tools/xcutils/xcbuild.c
new file mode 100644
index 0000000..54f5c38
--- /dev/null
+++ b/tools/xcutils/xcbuild.c
@@ -0,0 +1,100 @@
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#include <errno.h>
+
+#include <xenctrl.h>
+#include <xentoollog.h>
+#include <xc_dom.h>
+
+int main(int argc, char **argv)
+{
+	xentoollog_logger *logger;
+	xc_interface *xch;
+	int rv;
+	const char *image;
+	uint32_t domid;
+	xen_domain_handle_t handle;
+	int maxmem = 128; /* MB */
+	int memory_kb = 2*(maxmem + 1)*1024; /* bit of slack... */
+	struct xc_dom_image *dom;
+
+	image = (argc < 2) ? "guest.img" : argv[1];
+	printf("Image: %s\n", image);
+	printf("Memory: %dKB\n", memory_kb);
+
+	logger = (xentoollog_logger*)
+		xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
+	if ( logger == NULL )
+	{
+		perror("xtl_createlogger_stdiostream");
+		exit(1);
+	}
+
+	xch = xc_interface_open(logger, logger, 0);
+	if ( xch == NULL )
+	{
+		perror("xc_interface_open");
+		exit(1);
+	}
+
+	rv = xc_dom_loginit(xch);
+	if (rv) return rv;
+
+	//rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	//if (rv) return rv;
+
+	rv = xc_domain_create(xch, 0 /* ssid */, handle, 0 /* flags */, &domid);
+	printf("xc_domain_create: %d (%d)\n", rv, errno);
+	if ( rv < 0 )
+	{
+		perror("xc_domain_create");
+		exit(1);
+	}
+
+	printf("building dom%d\n", domid);
+
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if ( rv < 0)
+	{
+		perror("xc_domain_max_vcpus");
+		exit(1);
+	}
+
+	rv = xc_domain_setmaxmem(xch, domid, memory_kb);
+	if ( rv < 0)
+	{
+		perror("xc_domain_setmaxmem");
+		exit(1);
+	}
+
+	dom = xc_dom_allocate(xch, "", NULL);
+	rv = xc_dom_kernel_file(dom, image);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, 2*maxmem);/* XXX */
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_unpause(xch, domid);
+	if ( rv )
+	{
+		perror("xc_domain_unpause");
+		exit(1);
+	}
+
+	xc_interface_close(xch);
+
+	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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiL-0003oC-HD; Thu, 28 Jun 2012 15:33:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiK-0003nf-F3
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:00 +0000
Received: from [85.158.139.83:35715] by server-9.bemta-5.messagelabs.com id
	05/34-01069-B297CEF4; Thu, 28 Jun 2012 15:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340897577!26058016!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9804 invoked from network); 28 Jun 2012 15:32:59 -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 Jun 2012 15:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389631"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:55 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:54 -0400
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 1SkG0x-000630-8t;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:02 +0000
Message-ID: <1340894890-4369-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/21] arm: move PSR flag definitions into
	interface, for tools use.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/entry.S            |    1 +
 xen/include/asm-arm/page.h      |    2 ++
 xen/include/asm-arm/processor.h |   21 ---------------------
 xen/include/asm-arm/system.h    |    2 +-
 xen/include/public/arch-arm.h   |   23 ++++++++++++++++++++++-
 5 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 5bc3906..2ff32a1 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
+#include <public/xen.h>
 
 #define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
 #define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 2b6c1780..f3e4d1a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -2,6 +2,8 @@
 #define __ARM_PAGE_H__
 
 #include <xen/config.h>
+#include <public/xen.h>
+#include <asm/processor.h>
 
 #define PADDR_BITS              40
 #define PADDR_MASK              ((1ULL << PADDR_BITS)-1)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9b3c9dd..3849b23 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -3,27 +3,6 @@
 
 #include <asm/cpregs.h>
 
-/* PSR bits (CPSR, SPSR)*/
-
-/* 0-4: Mode */
-#define PSR_MODE_MASK 0x1f
-#define PSR_MODE_USR 0x10
-#define PSR_MODE_FIQ 0x11
-#define PSR_MODE_IRQ 0x12
-#define PSR_MODE_SVC 0x13
-#define PSR_MODE_MON 0x16
-#define PSR_MODE_ABT 0x17
-#define PSR_MODE_HYP 0x1a
-#define PSR_MODE_UND 0x1b
-#define PSR_MODE_SYS 0x1f
-
-#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 */
-#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
-
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_EAE    0x80000000
 #define TTBCR_N_MASK 0x07
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 7963ea5..216ef1f 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -3,7 +3,7 @@
 #define __ASM_SYSTEM_H
 
 #include <xen/lib.h>
-#include <asm/processor.h>
+#include <public/arch-arm.h>
 
 #define nop() \
     asm volatile ( "nop" )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e915cbf..eb1add9 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -138,7 +138,28 @@ struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif
+#endif /* ifndef __ASSEMBLY __ */
+
+/* PSR bits (CPSR, SPSR)*/
+
+/* 0-4: Mode */
+#define PSR_MODE_MASK 0x1f
+#define PSR_MODE_USR 0x10
+#define PSR_MODE_FIQ 0x11
+#define PSR_MODE_IRQ 0x12
+#define PSR_MODE_SVC 0x13
+#define PSR_MODE_MON 0x16
+#define PSR_MODE_ABT 0x17
+#define PSR_MODE_HYP 0x1a
+#define PSR_MODE_UND 0x1b
+#define PSR_MODE_SYS 0x1f
+
+#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 */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
 
-- 
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 Thu Jun 28 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGiO-0003pW-3i; Thu, 28 Jun 2012 15:33:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkGiL-0003nw-Uw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [193.109.254.147:55947] by server-11.bemta-14.messagelabs.com
	id D2/A7-24843-D297CEF4; Thu, 28 Jun 2012 15:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340897578!9024442!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16818 invoked from network); 28 Jun 2012 15:33:00 -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;
	28 Jun 2012 15:33:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389641"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-IT;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:08 +0000
Message-ID: <1340894890-4369-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 20/21] HACK: arm: disable hypercall
	continuations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/sched.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..15fa6b4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -577,10 +577,14 @@ unsigned long hypercall_create_continuation(
     unsigned int op, const char *format, ...);
 void hypercall_cancel_continuation(void);
 
+#ifdef CONFIG_ARM
+#define hypercall_preempt_check() (0)
+#else
 #define hypercall_preempt_check() (unlikely(    \
         softirq_pending(smp_processor_id()) |   \
         local_events_need_delivery()            \
     ))
+#endif
 
 extern struct domain *domain_list;
 
-- 
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 Thu Jun 28 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGiP-0003qX-Vp; Thu, 28 Jun 2012 15:33: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 1SkGiM-0003oG-FZ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [85.158.139.83:35850] by server-3.bemta-5.messagelabs.com id
	D6/26-03367-D297CEF4; Thu, 28 Jun 2012 15:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25003 invoked from network); 28 Jun 2012 15:33:00 -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;
	28 Jun 2012 15:33:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389637"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-Fk;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:06 +0000
Message-ID: <1340894890-4369-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 18/21] arm: implement VGCF_online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 tools/libxc/xc_dom_arm.c      |    2 ++
 xen/arch/arm/domain.c         |    5 ++++-
 xen/include/public/arch-arm.h |    4 ++++
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 9099cad..bea409b 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -96,6 +96,8 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
 
     ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
+    ctxt->flags = VGCF_online;
+
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
            ctxt->user_regs.cpsr, ctxt->user_regs.pc);
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ac6a30d..f61568b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -416,7 +416,10 @@ int arch_set_info_guest(
     v->arch.ttbr1 = ctxt->ttbr1;
     v->arch.ttbcr = ctxt->ttbcr;
 
-    clear_bit(_VPF_down, &v->pause_flags);
+    if ( ctxt->flags & VGCF_online )
+        clear_bit(_VPF_down, &v->pause_flags);
+    else
+        set_bit(_VPF_down, &v->pause_flags);
 
     return 0;
 }
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7ebe966..6e0fe47 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,10 @@ typedef uint32_t xen_ulong_t;
 #define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
+#define _VGCF_online                   0
+#define VGCF_online                    (1<<_VGCF_online)
+    uint32_t flags;                         /* VGCF_* */
+
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
 
     uint32_t sctlr;
-- 
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 Thu Jun 28 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGiP-0003qX-Vp; Thu, 28 Jun 2012 15:33: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 1SkGiM-0003oG-FZ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [85.158.139.83:35850] by server-3.bemta-5.messagelabs.com id
	D6/26-03367-D297CEF4; Thu, 28 Jun 2012 15:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1340897575!29477555!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25003 invoked from network); 28 Jun 2012 15:33:00 -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;
	28 Jun 2012 15:33:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389637"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:57 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-Fk;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:06 +0000
Message-ID: <1340894890-4369-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 18/21] arm: implement VGCF_online
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 tools/libxc/xc_dom_arm.c      |    2 ++
 xen/arch/arm/domain.c         |    5 ++++-
 xen/include/public/arch-arm.h |    4 ++++
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 9099cad..bea409b 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -96,6 +96,8 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
 
     ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
+    ctxt->flags = VGCF_online;
+
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
            ctxt->user_regs.cpsr, ctxt->user_regs.pc);
 
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ac6a30d..f61568b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -416,7 +416,10 @@ int arch_set_info_guest(
     v->arch.ttbr1 = ctxt->ttbr1;
     v->arch.ttbcr = ctxt->ttbcr;
 
-    clear_bit(_VPF_down, &v->pause_flags);
+    if ( ctxt->flags & VGCF_online )
+        clear_bit(_VPF_down, &v->pause_flags);
+    else
+        set_bit(_VPF_down, &v->pause_flags);
 
     return 0;
 }
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 7ebe966..6e0fe47 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -124,6 +124,10 @@ typedef uint32_t xen_ulong_t;
 #define PRI_xen_ulong PRIx32
 
 struct vcpu_guest_context {
+#define _VGCF_online                   0
+#define VGCF_online                    (1<<_VGCF_online)
+    uint32_t flags;                         /* VGCF_* */
+
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
 
     uint32_t sctlr;
-- 
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 Thu Jun 28 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGiP-0003qA-48; Thu, 28 Jun 2012 15:33: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 1SkGiM-0003ny-8F
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [85.158.139.83:35891] by server-10.bemta-5.messagelabs.com id
	49/86-02190-D297CEF4; Thu, 28 Jun 2012 15:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340897577!26058016!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10162 invoked from network); 28 Jun 2012 15:33:00 -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 Jun 2012 15:33:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389638"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-EB;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:05 +0000
Message-ID: <1340894890-4369-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 17/21] libxc: add ARM support to xc_dom (PV
	domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Includes ARM zImage support.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 6 files changed, 315 insertions(+), 9 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ca38cbd..a01d457 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
 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_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 2aef64a..4db8fad 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -93,6 +93,7 @@ struct xc_dom_image {
     void *p2m_guest;
 
     /* physical memory */
+    xen_pfn_t rambase_pfn;
     xen_pfn_t total_pages;
     struct xc_dom_phys *phys_pages;
     int realmodearea_log;
@@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
@@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
 {
     if (xc_dom_feature_translated(dom))
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 /* --- arch bits --------------------------------------------------- */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 122d0e8..9099cad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -18,14 +18,138 @@
  * Copyright (c) 2011, Citrix Systems
  */
 #include <inttypes.h>
+
 #include <xen/xen.h>
+#include <xen/io/protocols.h>
+
 #include "xg_private.h"
 #include "xc_dom.h"
 
+/* ------------------------------------------------------------------------ */
+/*
+ * arm guests are hybrid and start off with paging disabled, therefore no
+ * pagetables and nothing to do here.
+ */
+static int count_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+static int setup_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX
+     *   dom->p2m_guest
+     *   dom->start_info_pfn
+     *   dom->xenstore_pfn
+     *   dom->console_pfn
+     */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int start_info_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
+{
+    vcpu_guest_context_t *ctxt = ptr;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    /* clear everything */
+    memset(ctxt, 0, sizeof(*ctxt));
+
+    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
+
+    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
+    ctxt->user_regs.r3 = 0xdeadbeef;
+    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
+    ctxt->ttbr0 = 0;
+    ctxt->ttbr1 = 0;
+    ctxt->ttbcr = 0; /* Defined Reset Value */
+
+    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static struct xc_dom_arch xc_dom_32 = {
+    .guest_type = "xen-3.0-armv7l",
+    .native_protocol = XEN_IO_PROTO_ABI_ARM,
+    .page_shift = PAGE_SHIFT_ARM,
+    .sizeof_pfn = 8,
+    .alloc_magic_pages = alloc_magic_pages,
+    .count_pgtables = count_pgtables_arm,
+    .setup_pgtables = setup_pgtables_arm,
+    .start_info = start_info_arm,
+    .shared_info = shared_info_arm,
+    .vcpu = vcpu_arm,
+};
+
+static void __init register_arch_hooks(void)
+{
+    xc_dom_register_arch_hooks(&xc_dom_32);
+}
+
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
-    errno = ENOSYS;
-    return -1;
+    int rc;
+    xen_pfn_t pfn, allocsz, i;
+
+    dom->shadow_enabled = 1;
+
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+
+    /* setup initial p2m */
+    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
+
+    /* allocate guest memory */
+    for ( i = rc = allocsz = 0;
+          (i < dom->total_pages) && !rc;
+          i += allocsz )
+    {
+        allocsz = dom->total_pages - i;
+        if ( allocsz > 1024*1024 )
+            allocsz = 1024*1024;
+
+        rc = xc_domain_populate_physmap_exact(
+            dom->xch, dom->guest_domid, allocsz,
+            0, 0, &dom->p2m_host[i]);
+    }
+
+    return 0;
 }
 
 int arch_setup_bootearly(struct xc_dom_image *dom)
@@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
 
 int arch_setup_bootlate(struct xc_dom_image *dom)
 {
-    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    /* XXX
+     *   map shared info
+     *   map grant tables
+     *   setup shared info
+     */
     return 0;
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
new file mode 100644
index 0000000..220176d
--- /dev/null
+++ b/tools/libxc/xc_dom_armzimageloader.c
@@ -0,0 +1,167 @@
+/*
+ * Xen domain builder -- ARM zImage bits
+ *
+ * Parse and load ARM zImage kernel images.
+ *
+ * Copyright (C) 2012, Citrix Systems.
+ *
+ * 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
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#include <arpa/inet.h> /* XXX ntohl is not the right function... */
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t end;
+
+    if ( dom->kernel_blob == NULL )
+    {
+        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                     "%s: no kernel image loaded", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    zimage = (uint32_t *)dom->kernel_blob;
+    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    /*
+     * Check for an appended DTB.
+     */
+    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
+        struct minimal_dtb_header *dtb_hdr;
+        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
+        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
+            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
+            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
+        }
+    }
+
+    dom->kernel_size = end;
+
+    return 0;
+}
+
+static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t start, entry_addr;
+    uint64_t v_start, v_end;
+    uint64_t rambase = 0x80000000; /* XXX */
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    zimage = (uint32_t *)dom->kernel_blob;
+
+    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
+
+    v_start = rambase + 0x8000; /* XXX */
+    v_end = v_start + dom->kernel_size;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+
+    if (start == 0)
+        entry_addr = v_start;
+    else
+        entry_addr = start;
+
+    /* find kernel segment */
+    dom->kernel_seg.vstart = v_start;
+    dom->kernel_seg.vend   = v_end;
+
+    dom->parms.virt_entry = entry_addr;
+
+    dom->guest_type = "xen-3.0-armv7l";
+    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
+              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
+    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
+              __FUNCTION__, dom->guest_type,
+              dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    return 0;
+}
+
+static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
+{
+    void *dst;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
+
+    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
+              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
+              __func__, dom->kernel_size, dom->kernel_blob, dst);
+
+    memcpy(dst, dom->kernel_blob, dom->kernel_size);
+
+    return 0;
+}
+
+static struct xc_dom_loader zimage_loader = {
+    .name = "Linux zImage (ARM)",
+    .probe = xc_dom_probe_zimage_kernel,
+    .parser = xc_dom_parse_zimage_kernel,
+    .loader = xc_dom_load_zimage_kernel,
+};
+
+static void __init register_loader(void)
+{
+    xc_dom_register_loader(&zimage_loader);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fea9de5..b0d48d5 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
                         xen_pfn_t count)
 {
     struct xc_dom_phys *phys;
+    xen_pfn_t offset;
     unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
     char *mode = "unset";
 
-    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
+    offset = pfn-dom->rambase_pfn;
+    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
          count > dom->total_pages ||
-         pfn > dom->total_pages - count )
+         offset > dom->total_pages - count )
     {
-        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
-                  __FUNCTION__, pfn, dom->total_pages);
+        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
+                  __FUNCTION__, pfn, offset, dom->total_pages);
         return NULL;
     }
 
@@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
     dom->parms.virt_hv_start_low = UNSET_ADDR;
     dom->parms.elf_paddr_offset = UNSET_ADDR;
 
+    dom->rambase_pfn = 0;
+
     dom->alloc_malloc += sizeof(*dom);
     return dom;
 
diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
index a29fa26..a271942 100644
--- a/tools/libxc/xg_private.h
+++ b/tools/libxc/xg_private.h
@@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
+#define PAGE_SHIFT_ARM          12
+#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
+#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
+
 #define PAGE_SHIFT_X86          12
 #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
 #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-- 
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 Thu Jun 28 15:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:33:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGiP-0003qA-48; Thu, 28 Jun 2012 15:33: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 1SkGiM-0003ny-8F
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:33:02 +0000
Received: from [85.158.139.83:35891] by server-10.bemta-5.messagelabs.com id
	49/86-02190-D297CEF4; Thu, 28 Jun 2012 15:33:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340897577!26058016!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjI5NjI=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10162 invoked from network); 28 Jun 2012 15:33:00 -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 Jun 2012 15:33:00 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336363200"; d="scan'208";a="200389638"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:32:58 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:32:55 -0400
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 1SkG0x-000630-EB;
	Thu, 28 Jun 2012 15:48:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 14:48:05 +0000
Message-ID: <1340894890-4369-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
References: <1340894870.10942.63.camel@zakaz.uk.xensource.com>
	<1340894890-4369-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 17/21] libxc: add ARM support to xc_dom (PV
	domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Includes ARM zImage support.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/Makefile                 |    1 +
 tools/libxc/xc_dom.h                 |    5 +-
 tools/libxc/xc_dom_arm.c             |  135 +++++++++++++++++++++++++++-
 tools/libxc/xc_dom_armzimageloader.c |  167 ++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_core.c            |   12 ++-
 tools/libxc/xg_private.h             |    4 +
 6 files changed, 315 insertions(+), 9 deletions(-)
 create mode 100644 tools/libxc/xc_dom_armzimageloader.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ca38cbd..a01d457 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -59,6 +59,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c
 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_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 2aef64a..4db8fad 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -93,6 +93,7 @@ struct xc_dom_image {
     void *p2m_guest;
 
     /* physical memory */
+    xen_pfn_t rambase_pfn;
     xen_pfn_t total_pages;
     struct xc_dom_phys *phys_pages;
     int realmodearea_log;
@@ -286,7 +287,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
@@ -294,7 +295,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
 {
     if (xc_dom_feature_translated(dom))
         return pfn;
-    return dom->p2m_host[pfn];
+    return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
 /* --- arch bits --------------------------------------------------- */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 122d0e8..9099cad 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -18,14 +18,138 @@
  * Copyright (c) 2011, Citrix Systems
  */
 #include <inttypes.h>
+
 #include <xen/xen.h>
+#include <xen/io/protocols.h>
+
 #include "xg_private.h"
 #include "xc_dom.h"
 
+/* ------------------------------------------------------------------------ */
+/*
+ * arm guests are hybrid and start off with paging disabled, therefore no
+ * pagetables and nothing to do here.
+ */
+static int count_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+static int setup_pgtables_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX
+     *   dom->p2m_guest
+     *   dom->start_info_pfn
+     *   dom->xenstore_pfn
+     *   dom->console_pfn
+     */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int start_info_arm(struct xc_dom_image *dom)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+static int shared_info_arm(struct xc_dom_image *dom, void *ptr)
+{
+    DOMPRINTF_CALLED(dom->xch);
+    /* XXX */
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
+{
+    vcpu_guest_context_t *ctxt = ptr;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    /* clear everything */
+    memset(ctxt, 0, sizeof(*ctxt));
+
+    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r1 = 2272; /* Machine NR: Versatile Express */
+
+    ctxt->user_regs.r2 = 0xffffffff; //devicetree_seg //dtb_paddr; //atags or dtb /* XXX using APPEND right now */
+    ctxt->user_regs.r3 = 0xdeadbeef;
+    ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
+    ctxt->ttbr0 = 0;
+    ctxt->ttbr1 = 0;
+    ctxt->ttbcr = 0; /* Defined Reset Value */
+
+    ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
+
+    DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static struct xc_dom_arch xc_dom_32 = {
+    .guest_type = "xen-3.0-armv7l",
+    .native_protocol = XEN_IO_PROTO_ABI_ARM,
+    .page_shift = PAGE_SHIFT_ARM,
+    .sizeof_pfn = 8,
+    .alloc_magic_pages = alloc_magic_pages,
+    .count_pgtables = count_pgtables_arm,
+    .setup_pgtables = setup_pgtables_arm,
+    .start_info = start_info_arm,
+    .shared_info = shared_info_arm,
+    .vcpu = vcpu_arm,
+};
+
+static void __init register_arch_hooks(void)
+{
+    xc_dom_register_arch_hooks(&xc_dom_32);
+}
+
 int arch_setup_meminit(struct xc_dom_image *dom)
 {
-    errno = ENOSYS;
-    return -1;
+    int rc;
+    xen_pfn_t pfn, allocsz, i;
+
+    dom->shadow_enabled = 1;
+
+    dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages);
+
+    /* setup initial p2m */
+    for ( pfn = 0; pfn < dom->total_pages; pfn++ )
+        dom->p2m_host[pfn] = pfn + dom->rambase_pfn;
+
+    /* allocate guest memory */
+    for ( i = rc = allocsz = 0;
+          (i < dom->total_pages) && !rc;
+          i += allocsz )
+    {
+        allocsz = dom->total_pages - i;
+        if ( allocsz > 1024*1024 )
+            allocsz = 1024*1024;
+
+        rc = xc_domain_populate_physmap_exact(
+            dom->xch, dom->guest_domid, allocsz,
+            0, 0, &dom->p2m_host[i]);
+    }
+
+    return 0;
 }
 
 int arch_setup_bootearly(struct xc_dom_image *dom)
@@ -36,9 +160,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom)
 
 int arch_setup_bootlate(struct xc_dom_image *dom)
 {
-    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    /* XXX
+     *   map shared info
+     *   map grant tables
+     *   setup shared info
+     */
     return 0;
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c
new file mode 100644
index 0000000..220176d
--- /dev/null
+++ b/tools/libxc/xc_dom_armzimageloader.c
@@ -0,0 +1,167 @@
+/*
+ * Xen domain builder -- ARM zImage bits
+ *
+ * Parse and load ARM zImage kernel images.
+ *
+ * Copyright (C) 2012, Citrix Systems.
+ *
+ * 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
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#include <arpa/inet.h> /* XXX ntohl is not the right function... */
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t end;
+
+    if ( dom->kernel_blob == NULL )
+    {
+        xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+                     "%s: no kernel image loaded", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    zimage = (uint32_t *)dom->kernel_blob;
+    if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC )
+    {
+        xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__);
+        return -EINVAL;
+    }
+
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    /*
+     * Check for an appended DTB.
+     */
+    if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) {
+        struct minimal_dtb_header *dtb_hdr;
+        dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end);
+        if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) {
+            xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__);
+            end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size);
+        }
+    }
+
+    dom->kernel_size = end;
+
+    return 0;
+}
+
+static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom)
+{
+    uint32_t *zimage;
+    uint32_t start, entry_addr;
+    uint64_t v_start, v_end;
+    uint64_t rambase = 0x80000000; /* XXX */
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    zimage = (uint32_t *)dom->kernel_blob;
+
+    dom->rambase_pfn = rambase >> XC_PAGE_SHIFT;
+
+    v_start = rambase + 0x8000; /* XXX */
+    v_end = v_start + dom->kernel_size;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+
+    if (start == 0)
+        entry_addr = v_start;
+    else
+        entry_addr = start;
+
+    /* find kernel segment */
+    dom->kernel_seg.vstart = v_start;
+    dom->kernel_seg.vend   = v_end;
+
+    dom->parms.virt_entry = entry_addr;
+
+    dom->guest_type = "xen-3.0-armv7l";
+    DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn,
+              __FUNCTION__, dom->guest_type, dom->rambase_pfn);
+    DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "",
+              __FUNCTION__, dom->guest_type,
+              dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    return 0;
+}
+
+static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom)
+{
+    void *dst;
+
+    DOMPRINTF_CALLED(dom->xch);
+
+    dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
+
+    DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64,
+              __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend);
+    DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p",
+              __func__, dom->kernel_size, dom->kernel_blob, dst);
+
+    memcpy(dst, dom->kernel_blob, dom->kernel_size);
+
+    return 0;
+}
+
+static struct xc_dom_loader zimage_loader = {
+    .name = "Linux zImage (ARM)",
+    .probe = xc_dom_probe_zimage_kernel,
+    .parser = xc_dom_parse_zimage_kernel,
+    .loader = xc_dom_load_zimage_kernel,
+};
+
+static void __init register_loader(void)
+{
+    xc_dom_register_loader(&zimage_loader);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fea9de5..b0d48d5 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn,
                         xen_pfn_t count)
 {
     struct xc_dom_phys *phys;
+    xen_pfn_t offset;
     unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom);
     char *mode = "unset";
 
-    if ( pfn > dom->total_pages ||    /* multiple checks to avoid overflows */
+    offset = pfn-dom->rambase_pfn;
+    if ( offset > dom->total_pages ||    /* multiple checks to avoid overflows */
          count > dom->total_pages ||
-         pfn > dom->total_pages - count )
+         offset > dom->total_pages - count )
     {
-        DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
-                  __FUNCTION__, pfn, dom->total_pages);
+        DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")",
+                  __FUNCTION__, pfn, offset, dom->total_pages);
         return NULL;
     }
 
@@ -599,6 +601,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
     dom->parms.virt_hv_start_low = UNSET_ADDR;
     dom->parms.elf_paddr_offset = UNSET_ADDR;
 
+    dom->rambase_pfn = 0;
+
     dom->alloc_malloc += sizeof(*dom);
     return dom;
 
diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h
index a29fa26..a271942 100644
--- a/tools/libxc/xg_private.h
+++ b/tools/libxc/xg_private.h
@@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t;
 #define l4_table_offset(_a) l4_table_offset_x86_64(_a)
 #endif
 
+#define PAGE_SHIFT_ARM          12
+#define PAGE_SIZE_ARM           (1UL << PAGE_SHIFT_ARM)
+#define PAGE_MASK_ARM           (~(PAGE_SIZE_ARM-1))
+
 #define PAGE_SHIFT_X86          12
 #define PAGE_SIZE_X86           (1UL << PAGE_SHIFT_X86)
 #define PAGE_MASK_X86           (~(PAGE_SIZE_X86-1))
-- 
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 Thu Jun 28 15:33:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGil-0004AW-JN; Thu, 28 Jun 2012 15:33: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 1SkGik-00048b-5O
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:33:26 +0000
Received: from [85.158.138.51:15509] by server-9.bemta-3.messagelabs.com id
	4B/EF-10419-4497CEF4; Thu, 28 Jun 2012 15:33:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340897604!21885420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4884 invoked from network); 28 Jun 2012 15:33:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:33:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336348800"; d="scan'208";a="13274224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:33:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 16:33:14 +0100
Message-ID: <1340897592.10942.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 28 Jun 2012 16:33:12 +0100
In-Reply-To: <1340896924.21008.9.camel@Solace>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
	<1340895534.10942.64.camel@zakaz.uk.xensource.com>
	<1340896924.21008.9.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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 Thu, 2012-06-28 at 16:22 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-28 at 15:58 +0100, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 15:54 +0100, Ian Jackson wrote:
> > > Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> > > > Change from v2:
> > > > Rebase on top of latest head.
> > > > 
> > > > Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> > > > number of physical cpus. In some place, we may want to allocate
> > > > specific size of cpumap.  This patch allow to pass a argument to
> > > > specific the size that you want to allocate. If pass 0, it means the
> > > > size is equal to number of physical cpus.
> > > 
> > > Isn't this same objective achieved in a more general way by Dario's
> > >   [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap
> > 
> Well, there's sure is a clash, as I'm changing the name of map data
> structure. If you check this in, I'll rebase mine one on top of it.
> 
> 
> > Didn't Dario's patch build on this one, or perhaps incorporate it?
> > 
> No, or at least not yet, as this patch is not in yet. Anyway, that's of
> course possible, just decide what you prefer. :-)
> 
> Merging this patch and my 05/10 won't be that hard, and I can take care
> of it, and the same should apply to this "[Xen-devel] [PATCH v4 ]libxl:
> allow to set more than 31 vcpus".

If you don't mind I think we should take this and the 31 cpus one
(assuming they are otherwise acked) now and the numa one can be rebased
on 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 Jun 28 15:33:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15: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 1SkGil-0004AW-JN; Thu, 28 Jun 2012 15:33: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 1SkGik-00048b-5O
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:33:26 +0000
Received: from [85.158.138.51:15509] by server-9.bemta-3.messagelabs.com id
	4B/EF-10419-4497CEF4; Thu, 28 Jun 2012 15:33:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340897604!21885420!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4884 invoked from network); 28 Jun 2012 15:33:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 15:33:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,492,1336348800"; d="scan'208";a="13274224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 15:33:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 16:33:14 +0100
Message-ID: <1340897592.10942.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 28 Jun 2012 16:33:12 +0100
In-Reply-To: <1340896924.21008.9.camel@Solace>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
	<1340895534.10942.64.camel@zakaz.uk.xensource.com>
	<1340896924.21008.9.camel@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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 Thu, 2012-06-28 at 16:22 +0100, Dario Faggioli wrote:
> On Thu, 2012-06-28 at 15:58 +0100, Ian Campbell wrote:
> > On Thu, 2012-06-28 at 15:54 +0100, Ian Jackson wrote:
> > > Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> > > > Change from v2:
> > > > Rebase on top of latest head.
> > > > 
> > > > Currently, libxl_cpumap_alloc()allocate the cpumap with size of
> > > > number of physical cpus. In some place, we may want to allocate
> > > > specific size of cpumap.  This patch allow to pass a argument to
> > > > specific the size that you want to allocate. If pass 0, it means the
> > > > size is equal to number of physical cpus.
> > > 
> > > Isn't this same objective achieved in a more general way by Dario's
> > >   [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap
> > 
> Well, there's sure is a clash, as I'm changing the name of map data
> structure. If you check this in, I'll rebase mine one on top of it.
> 
> 
> > Didn't Dario's patch build on this one, or perhaps incorporate it?
> > 
> No, or at least not yet, as this patch is not in yet. Anyway, that's of
> course possible, just decide what you prefer. :-)
> 
> Merging this patch and my 05/10 won't be that hard, and I can take care
> of it, and the same should apply to this "[Xen-devel] [PATCH v4 ]libxl:
> allow to set more than 31 vcpus".

If you don't mind I think we should take this and the 31 cpus one
(assuming they are otherwise acked) now and the numa one can be rebased
on 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 Jun 28 15:37:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGmk-0005VO-FH; Thu, 28 Jun 2012 15:37: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 1SkGmi-0005V3-SG
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:37:33 +0000
Received: from [85.158.139.83:20287] by server-9.bemta-5.messagelabs.com id
	9C/43-01069-B3A7CEF4; Thu, 28 Jun 2012 15:37:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340897851!24867907!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8350 invoked from network); 28 Jun 2012 15:37:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 15:37:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 16:37:29 +0100
Message-Id: <4FEC9686020000780008C9BB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 16:38:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
	<4FEC6D44.8080807@zytor.com>
In-Reply-To: <4FEC6D44.8080807@zytor.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Suresh B Siddha <suresh.b.siddha@intel.com>,
	x86@kernel.org, Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, cyclonusj@gmail.com
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:42, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 06/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
>> I also chatted with the core Xen hypervisor folks about adding in the 
> context switch code
>> to alter the PAT layout - but they were not keen a about it - and I am not 
> sure how much
>> CPU cycles one loses by doing a wrmsr to the PAT register on every guest 
> context switch
>> (worst case when on has a pvops kernel and a old-style one - where the WC bit 
> would differ)?
>> 
> 
> And you're comparing that to a bunch of new pvops calls?  The discussion
> shouldn't even have started until you had ruled out this solution and
> had data to show it.

That's definitely not an option: Xen itself may be (and is, under
certain circumstances at least) using WC page table entries, so
we can't allow on-the-fly changes to the meaning of the various
indexes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:37:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkGmk-0005VO-FH; Thu, 28 Jun 2012 15:37: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 1SkGmi-0005V3-SG
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:37:33 +0000
Received: from [85.158.139.83:20287] by server-9.bemta-5.messagelabs.com id
	9C/43-01069-B3A7CEF4; Thu, 28 Jun 2012 15:37:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340897851!24867907!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8350 invoked from network); 28 Jun 2012 15:37:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 15:37:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Jun 2012 16:37:29 +0100
Message-Id: <4FEC9686020000780008C9BB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 28 Jun 2012 16:38:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
	<4FEC6D44.8080807@zytor.com>
In-Reply-To: <4FEC6D44.8080807@zytor.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Suresh B Siddha <suresh.b.siddha@intel.com>,
	x86@kernel.org, Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, cyclonusj@gmail.com
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 16:42, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 06/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
>> I also chatted with the core Xen hypervisor folks about adding in the 
> context switch code
>> to alter the PAT layout - but they were not keen a about it - and I am not 
> sure how much
>> CPU cycles one loses by doing a wrmsr to the PAT register on every guest 
> context switch
>> (worst case when on has a pvops kernel and a old-style one - where the WC bit 
> would differ)?
>> 
> 
> And you're comparing that to a bunch of new pvops calls?  The discussion
> shouldn't even have started until you had ruled out this solution and
> had data to show it.

That's definitely not an option: Xen itself may be (and is, under
certain circumstances at least) using WC page table entries, so
we can't allow on-the-fly changes to the meaning of the various
indexes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:40:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:40: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 1SkGpt-0005tX-4N; Thu, 28 Jun 2012 15:40:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkGpr-0005tS-EG
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:40:47 +0000
Received: from [85.158.143.99:39987] by server-3.bemta-4.messagelabs.com id
	B6/A5-05808-EFA7CEF4; Thu, 28 Jun 2012 15:40:46 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340898045!29038657!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29310 invoked from network); 28 Jun 2012 15:40:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 15:40:45 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79199822; Thu, 28 Jun 2012 17:40:45 +0200
Message-ID: <1340898039.21008.11.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 28 Jun 2012 17:40:39 +0200
In-Reply-To: <1340897592.10942.71.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
	<1340895534.10942.64.camel@zakaz.uk.xensource.com>
	<1340896924.21008.9.camel@Solace>
	<1340897592.10942.71.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============5820293994236116678=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5820293994236116678==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-K16cST2OCh3GPrpPRPlx"


--=-K16cST2OCh3GPrpPRPlx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 16:33 +0100, Ian Campbell wrote:
> > Merging this patch and my 05/10 won't be that hard, and I can take care
> > of it, and the same should apply to this "[Xen-devel] [PATCH v4 ]libxl:
> > allow to set more than 31 vcpus".
>=20
> If you don't mind I think we should take this and the 31 cpus one
> (assuming they are otherwise acked) now and the numa one can be rebased
> on it.
>=20
As I said, feel free to do whatever you wish, I'll rebase the NUMA
series on top of whatever will be in the repository at the time of
posting! :-P

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-K16cST2OCh3GPrpPRPlx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sevcACgkQk4XaBE3IOsQAmgCfdcR/5nUa+ezLF3nqU7Im82xZ
ocwAoKHgNjvxPumM5QDQ88yeSrFPdT3t
=3Prm
-----END PGP SIGNATURE-----

--=-K16cST2OCh3GPrpPRPlx--



--===============5820293994236116678==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5820293994236116678==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 15:40:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:40: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 1SkGpt-0005tX-4N; Thu, 28 Jun 2012 15:40:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkGpr-0005tS-EG
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 15:40:47 +0000
Received: from [85.158.143.99:39987] by server-3.bemta-4.messagelabs.com id
	B6/A5-05808-EFA7CEF4; Thu, 28 Jun 2012 15:40:46 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1340898045!29038657!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29310 invoked from network); 28 Jun 2012 15:40:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 15:40:45 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79199822; Thu, 28 Jun 2012 17:40:45 +0200
Message-ID: <1340898039.21008.11.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 28 Jun 2012 17:40:39 +0200
In-Reply-To: <1340897592.10942.71.camel@zakaz.uk.xensource.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
	<20460.28683.727280.950983@mariner.uk.xensource.com>
	<1340895534.10942.64.camel@zakaz.uk.xensource.com>
	<1340896924.21008.9.camel@Solace>
	<1340897592.10942.71.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with
 specific 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: multipart/mixed; boundary="===============5820293994236116678=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5820293994236116678==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-K16cST2OCh3GPrpPRPlx"


--=-K16cST2OCh3GPrpPRPlx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 16:33 +0100, Ian Campbell wrote:
> > Merging this patch and my 05/10 won't be that hard, and I can take care
> > of it, and the same should apply to this "[Xen-devel] [PATCH v4 ]libxl:
> > allow to set more than 31 vcpus".
>=20
> If you don't mind I think we should take this and the 31 cpus one
> (assuming they are otherwise acked) now and the numa one can be rebased
> on it.
>=20
As I said, feel free to do whatever you wish, I'll rebase the NUMA
series on top of whatever will be in the repository at the time of
posting! :-P

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-K16cST2OCh3GPrpPRPlx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sevcACgkQk4XaBE3IOsQAmgCfdcR/5nUa+ezLF3nqU7Im82xZ
ocwAoKHgNjvxPumM5QDQ88yeSrFPdT3t
=3Prm
-----END PGP SIGNATURE-----

--=-K16cST2OCh3GPrpPRPlx--



--===============5820293994236116678==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5820293994236116678==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 15:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkH7K-0006XB-Em; Thu, 28 Jun 2012 15:58: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 1SkH7I-0006X6-RH
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:58:49 +0000
Received: from [85.158.139.83:15959] by server-10.bemta-5.messagelabs.com id
	9C/87-02190-73F7CEF4; Thu, 28 Jun 2012 15:58:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340899125!28741851!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9767 invoked from network); 28 Jun 2012 15:58:46 -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;
	28 Jun 2012 15:58:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336363200"; d="scan'208";a="29772453"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:58:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:58:35 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SkH75-0008SB-N4	for xen-devel@lists.xen.org;
	Thu, 28 Jun 2012 16:58:35 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SkH75-0000Qo-CK	for
	xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:58:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: b2481fe8a39516413d35494eb5a3cb96aebb7eef
Message-ID: <b2481fe8a39516413d35.1340899114@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 28 Jun 2012 16:58:34 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] docs: various typos
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1340899046 -3600
# Node ID b2481fe8a39516413d35494eb5a3cb96aebb7eef
# Parent  3ea92ea1490fbe4a174f0d4d8fc3c6acfecd1b97
docs: various typos

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 16:57:26 2012 +0100
@@ -202,7 +202,7 @@ configuration
         
 =item B<rename-restart>
 
-rename the domain which terminated, and thenimmediately create a new
+rename the domain which terminated, and then immediately create a new
 domain with the same configuration as the original
 
 =item B<preserve>
@@ -357,7 +357,7 @@ guest B<DDDD> and B<BB> are C<0000:00>. 
 
 =item B<KEY=VALUE>
 
-Posible B<KEY>s are:
+Possible B<KEY>s are:
 
 =over 4
 
@@ -387,7 +387,7 @@ enable this option only for trusted VMs 
 =item B<pci_permissive=BOOLEAN>
 
 (PV only) Changes the default value of 'permissive' for all PCI
-devices for this VM.  This can still be overriden on a per-device
+devices for this VM.  This can still be overridden on a per-device
 basis. This option should be enabled with caution: it gives the guest
 much more control over the device, which may have security or
 stability implications.  It is recommended to enable this option only
@@ -436,7 +436,7 @@ specific what meaning this has).
 =item B<e820_host=BOOLEAN>
 
 Selects whether to expose the host e820 (memory map) to the guest via
-the virtual e820. When this option is false the guest psuedo-physical
+the virtual e820. When this option is false the guest pseudo-physical
 address space consists of a single contiguous RAM region. When this
 option is specified the virtual e820 instead reflects the host e820
 and contains the same PCI holes. The total amount of RAM represented
@@ -446,10 +446,10 @@ it is layed out.
 Exposing the host e820 to the guest gives the guest kernel the
 opportunity to set aside the required part of its pseudo-physical
 address space in order to provide address space to map passedthrough
-PCI devices. It is guest Operaring System dependant whether this
+PCI devices. It is guest Operating System dependant whether this
 option is required, specifically it is required when using a mainline
 Linux ("pvops") kernel. This option defaults to true if any PCI
-passthrough devices are configued and false otherwise. If you do not
+passthrough devices are configured and false otherwise. If you do not
 configure any passthrough devices at domain creation time but expect
 to hotplug devices later then you should set this option. Conversely
 if your particular guest kernel does not require this behaviour then
@@ -580,7 +580,7 @@ has no effect on a guest with multiple v
 always include these tables. This option is enabled by default and you
 should usually omit it but it may be necessary to disable these
 firmware tables when using certain older guest Operating
-Systems. These tables have been superceded by newer constructs within
+Systems. These tables have been superseded by newer constructs within
 the ACPI tables. (X86 only)
 
 =item B<nx=BOOLEAN>
@@ -763,7 +763,7 @@ Simple DirectMedia Layer). The default i
 =item B<opengl=BOOLEAN>
 
 Enable OpenGL acceleration of the SDL display. Only effects machines
-using B<device_model_version="qemu-xen-traditonal"> and only if the
+using B<device_model_version="qemu-xen-traditional"> and only if the
 device-model was compiled with OpenGL support. Disabled by default.
 
 =item B<nographic=BOOLEAN>
@@ -903,7 +903,7 @@ device-model will become the default in 
 =back
 
 It is recommended to accept the default value for new guests.  If
-you have existing guests then, depeending on the nature of the guest
+you have existing guests then, depending on the nature of the guest
 Operating System, you may wish to force them to use the device
 model which they were installed with.
 
@@ -926,19 +926,19 @@ Assign an XSM security label to the devi
 
 =item B<device_model_args=[ "ARG", "ARG", ...]>
 
-Pass additional arbitrary options on the devide-model command
+Pass additional arbitrary options on the device-model command
 line. Each element in the list is passed as an option to the
 device-model.
 
 =item B<device_model_args_pv=[ "ARG", "ARG", ...]>
 
-Pass additional arbitrary options on the devide-model command line for
+Pass additional arbitrary options on the device-model command line for
 a PV device model only. Each element in the list is passed as an
 option to the device-model.
 
 =item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
 
-Pass additional arbitrary options on the devide-model command line for
+Pass additional arbitrary options on the device-model command line for
 an HVM device model only. Each element in the list is passed as an
 option to the device-model.
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 16:57:26 2012 +0100
@@ -50,7 +50,7 @@ setup the bridge.
 =item B<autoballoon>
 
 If you specify the amount of memory dom0 has, passing B<dom0_mem> to
-Xen, it is highly reccomended to disable B<autoballoon>. Edit
+Xen, it is highly recommended to disable B<autoballoon>. Edit
 B</etc/xen/xl.conf> and set it to 0.
 
 =item run xl as B<root>
@@ -808,7 +808,7 @@ the ratelimit (see below).
 
 Ratelimit attempts to limit the number of schedules per second.  It
 sets a minimum amount of time (in microseconds) a VM must run before
-we will allow a higher-prioirty VM to pre-empt it.  The default value
+we will allow a higher-priority VM to pre-empt it.  The default value
 is 1000 microseconds (1ms).  Valid range is 100 to 500000 (500ms).
 The ratelimit length must be lower than the timeslice length.
 
@@ -1233,7 +1233,7 @@ We need better documentation for:
 
 =item B<tmem>
 
-Trascendent Memory.
+Transcendent Memory.
 
 =back
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xm.pod.1
--- a/docs/man/xm.pod.1	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xm.pod.1	Thu Jun 28 16:57:26 2012 +0100
@@ -117,7 +117,7 @@ on the command line are replaced by the 
 
 =item B<-F=FILE>, B<--config=FILE>
 
-Use the given SXP formated configuration script.
+Use the given SXP formatted configuration script.
 SXP is the underlying configuration format used by Xen.
 SXP configuration scripts can be hand-written or generated
 from Python configuration scripts, using the -n
@@ -430,7 +430,7 @@ on the command line are replaced by the 
 
 =item B<-F=FILE>, B<--config=FILE>
 
-Use the given SXP formated configuration script.
+Use the given SXP formatted configuration script.
 SXP is the underlying configuration format used by Xen.
 SXP configuration scripts can be hand-written or generated
 from Python configuration scripts, using the -n
diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xmdomain.cfg.pod.5
--- a/docs/man/xmdomain.cfg.pod.5	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xmdomain.cfg.pod.5	Thu Jun 28 16:57:26 2012 +0100
@@ -53,7 +53,7 @@ xen kernel.
 The amount of RAM, in megabytes, to allocate to the domain when it
 starts.  Allocating insufficient memory for a domain may produce
 extremely bizarre behavior.  If there isn't enough free memory left on
-the machine to fulfill this request, the domain will fail to start.
+the machine to fulfil this request, the domain will fail to start.
 
 Xen does not support overcommit of memory, so the total memory of all
 guests (+ 64 MB needed for Xen) must be less than or equal to the
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/distro_mapping.txt
--- a/docs/misc/distro_mapping.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/distro_mapping.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -22,6 +22,6 @@ one must grep for the above elements and
 
 For example if a new distro uses /etc/bork as its config dir, it's not
 sufficient to set CONFIG_LEAF_DIR=bork; one must also add tests for the
-existance of the bork dir in every context where config files are read.
+existence of the bork dir in every context where config files are read.
 
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/kexec_and_kdump.txt
--- a/docs/misc/kexec_and_kdump.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/kexec_and_kdump.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -3,8 +3,8 @@
 Kexec and Kdump for Xen
 =======================
 
-This is a breif guide to using Kexec and Kdump in conjunction with Xen.
-This functionaly works at the level of the hypervisor and dom0 kernel.
+This is a brief guide to using Kexec and Kdump in conjunction with Xen.
+This functionally works at the level of the hypervisor and dom0 kernel.
 And will thus affect all guests running on a machine.
 
 At this stage it does not work in conjunction with domU kernels.
@@ -33,7 +33,7 @@ Linux -> Xen   | first kernel       | se
 ---------------+--------------------+--------------------
 Linux -> Linux | first kernel       | second kernel
 
-If you are kexecing to Xen then you will also need to preapare the second
+If you are kexecing to Xen then you will also need to prepare the second
 hypervisor and dom0 kernel that will run after kexec. These may be the same
 as the first hypervisor and dom0 kernel that are used before kexec if you
 are kexecing from Xen to Xen.
@@ -176,7 +176,7 @@ running kernel.
 On x86 systems the crash kernel may be either
 - A uncompressed vmlinux image if the kernel is not relocatable
 - A compressed bzImage or vmlinuz image if the kernel is relocatable
-- Relocatability is crontroled by the CONFIG_RELOCATABLE kernel
+- Relocatability is controlled by the CONFIG_RELOCATABLE kernel
   compile configuration parameter. This option may not be available
   depending on the kernel version
 On ia64
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/tscmode.txt
--- a/docs/misc/tscmode.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/tscmode.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -121,7 +121,7 @@ may not remain) synchronized as "TSC-uns
 
 As a result of TSC's sordid history, two classes of applications use
 TSC: old applications designed for single processors, and the most recent
-enteprise applications which require high-frequency high-precision
+enterprise applications which require high-frequency high-precision
 timestamping.
 
 We will refer to apps that might break if running on a TSC-unsafe
@@ -151,13 +151,13 @@ instructions to trap.  This trap can be 
 then transparently "emulate" the results of the rdtsc instruction and
 return control to the code following the rdtsc instruction.
 
-To provide a "safe" TSC, i.e. to ensure both TSC monontonicity and a
+To provide a "safe" TSC, i.e. to ensure both TSC monotonicity and a
 fixed rate, Xen provides rdtsc emulation whenever necessary or when
 explicitly specified by a per-VM configuration option.  TSC emulation is
 relatively slow -- roughly 15-20 times slower than the rdtsc instruction
 when executed natively.  However, except when an OS or application uses
 the rdtsc instruction at a high frequency (e.g. more than about 10,000 times
-per second per processor), this performance degradation is not noticable
+per second per processor), this performance degradation is not noticeable
 (i.e. <0.3%).  And, TSC emulation is nearly always faster than
 OS-provided alternatives (e.g. Linux's gettimeofday).  For environments
 where it is certain that all apps are TSC-resilient (e.g.
@@ -196,7 +196,7 @@ all apps running in this virtual machine
 apps must either be TSC-resilient or pvrdtscp-modified.  Second,
 highest performance is only obtained on TSC-safe machines that
 support the rdtscp instruction; when running on older machines,
-rdtscp is emulated and thus slower.  For more information on PVRTSCP,
+rdtscp is emulated and thus slower.  For more information on PVRDTSCP,
 see below.
 
 Finally, tsc_mode==1 always enables TSC emulation, regardless of
@@ -243,7 +243,7 @@ saved, restore this domain will fail.
 There is another cpuid-related complication: The x86 cpuid instruction is
 non-privileged.  HVM domains are configured to always trap this instruction
 to Xen, where Xen can "filter" the result.  In a PV OS, all cpuid instructions
-have been replaced by a parvirtualized equivalent of the cpuid instruction
+have been replaced by a paravirtualized equivalent of the cpuid instruction
 ("pvcpuid") and also trap to Xen.  But apps in a PV guest that use a
 cpuid instruction execute it directly, without a trap to Xen.  As a result,
 an app may directly examine the physical TSC Invariant cpuid bit and make
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/vtpm.txt
--- a/docs/misc/vtpm.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/vtpm.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -78,7 +78,7 @@ ramdisk = "/xen/initrd_domU/U1_ramdisk.i
 memory = 32
 name = "TPMUserDomain0"
 vtpm = ['instance=1,backend=0']
-root = "/dev/ram0 cosole=tty ro"
+root = "/dev/ram0 console=tty ro"
 vif = ['backend=0']
 
 In the above configuration file the line 'vtpm = ...' provides
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xen-command-line.markdown	Thu Jun 28 16:57:26 2012 +0100
@@ -89,7 +89,7 @@ common, and only has an effect if your s
 
 The `acpi=noirq` option causes Xen to not parse the ACPI MADT table
 looking for IO-APIC entries.  This is also not common, and any system
-which requries this option to function should be blacklisted.
+which requires this option to function should be blacklisted.
 Additionally, this will not prevent Xen from finding IO-APIC entries
 from the MP tables.
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xenstore.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -202,7 +202,7 @@ WATCH			<wpath>|<token>|?
 	readable, some notifications may have been lost).
 
 WATCH_EVENT					<epath>|<token>|
-	Unsolicited `reply' generated for matching modfication events
+	Unsolicited `reply' generated for matching modification events
 	as described above.  req_id and tx_id are both 0.
 
 	<epath> is the event's path, ie the actual path that was
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xl-disk-configuration.txt
--- a/docs/misc/xl-disk-configuration.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xl-disk-configuration.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -72,7 +72,7 @@ Special syntax:
    syntax in the configuration file, it consumes the whole rest of the
    <diskspec>.  Therefore in that case it must come last.  This is
    permissible even if an empty value for the target was already
-   specifed as a positional parameter.  This is the only way to
+   specified as a positional parameter.  This is the only way to
    specify a target string containing metacharacters such as commas
    and (in some cases) colons, which would otherwise be
    misinterpreted.
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Thu Jun 28 16:57:26 2012 +0100
@@ -89,7 +89,7 @@ are:
 
   * `rtl8139` (default) -- Realtek RTL8139
   * `e1000` -- Intel E1000 
-  * in principal any device supported by your device model
+  * in principle any device supported by your device model
 
 ### vifname
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xsm-flask.txt
--- a/docs/misc/xsm-flask.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xsm-flask.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -226,7 +226,7 @@ 1) xen command line parameters
 	To boot the platform into enforcing mode, which means that the policy is
 	loaded and enforced, append 'flask_enforcing=1' on the grub line.
 	
-	This parameter may also be changed through the flask hyercall.
+	This parameter may also be changed through the flask hypercall.
 	
 	b) flask_enabled
 	

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 15:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 15:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkH7K-0006XB-Em; Thu, 28 Jun 2012 15:58: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 1SkH7I-0006X6-RH
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 15:58:49 +0000
Received: from [85.158.139.83:15959] by server-10.bemta-5.messagelabs.com id
	9C/87-02190-73F7CEF4; Thu, 28 Jun 2012 15:58:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1340899125!28741851!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNTI0Mzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9767 invoked from network); 28 Jun 2012 15:58:46 -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;
	28 Jun 2012 15:58:46 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336363200"; d="scan'208";a="29772453"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 11:58:37 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 28 Jun 2012 11:58:35 -0400
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1SkH75-0008SB-N4	for xen-devel@lists.xen.org;
	Thu, 28 Jun 2012 16:58:35 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1SkH75-0000Qo-CK	for
	xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:58:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: b2481fe8a39516413d35494eb5a3cb96aebb7eef
Message-ID: <b2481fe8a39516413d35.1340899114@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 28 Jun 2012 16:58:34 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] docs: various typos
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1340899046 -3600
# Node ID b2481fe8a39516413d35494eb5a3cb96aebb7eef
# Parent  3ea92ea1490fbe4a174f0d4d8fc3c6acfecd1b97
docs: various typos

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Jun 28 16:57:26 2012 +0100
@@ -202,7 +202,7 @@ configuration
         
 =item B<rename-restart>
 
-rename the domain which terminated, and thenimmediately create a new
+rename the domain which terminated, and then immediately create a new
 domain with the same configuration as the original
 
 =item B<preserve>
@@ -357,7 +357,7 @@ guest B<DDDD> and B<BB> are C<0000:00>. 
 
 =item B<KEY=VALUE>
 
-Posible B<KEY>s are:
+Possible B<KEY>s are:
 
 =over 4
 
@@ -387,7 +387,7 @@ enable this option only for trusted VMs 
 =item B<pci_permissive=BOOLEAN>
 
 (PV only) Changes the default value of 'permissive' for all PCI
-devices for this VM.  This can still be overriden on a per-device
+devices for this VM.  This can still be overridden on a per-device
 basis. This option should be enabled with caution: it gives the guest
 much more control over the device, which may have security or
 stability implications.  It is recommended to enable this option only
@@ -436,7 +436,7 @@ specific what meaning this has).
 =item B<e820_host=BOOLEAN>
 
 Selects whether to expose the host e820 (memory map) to the guest via
-the virtual e820. When this option is false the guest psuedo-physical
+the virtual e820. When this option is false the guest pseudo-physical
 address space consists of a single contiguous RAM region. When this
 option is specified the virtual e820 instead reflects the host e820
 and contains the same PCI holes. The total amount of RAM represented
@@ -446,10 +446,10 @@ it is layed out.
 Exposing the host e820 to the guest gives the guest kernel the
 opportunity to set aside the required part of its pseudo-physical
 address space in order to provide address space to map passedthrough
-PCI devices. It is guest Operaring System dependant whether this
+PCI devices. It is guest Operating System dependant whether this
 option is required, specifically it is required when using a mainline
 Linux ("pvops") kernel. This option defaults to true if any PCI
-passthrough devices are configued and false otherwise. If you do not
+passthrough devices are configured and false otherwise. If you do not
 configure any passthrough devices at domain creation time but expect
 to hotplug devices later then you should set this option. Conversely
 if your particular guest kernel does not require this behaviour then
@@ -580,7 +580,7 @@ has no effect on a guest with multiple v
 always include these tables. This option is enabled by default and you
 should usually omit it but it may be necessary to disable these
 firmware tables when using certain older guest Operating
-Systems. These tables have been superceded by newer constructs within
+Systems. These tables have been superseded by newer constructs within
 the ACPI tables. (X86 only)
 
 =item B<nx=BOOLEAN>
@@ -763,7 +763,7 @@ Simple DirectMedia Layer). The default i
 =item B<opengl=BOOLEAN>
 
 Enable OpenGL acceleration of the SDL display. Only effects machines
-using B<device_model_version="qemu-xen-traditonal"> and only if the
+using B<device_model_version="qemu-xen-traditional"> and only if the
 device-model was compiled with OpenGL support. Disabled by default.
 
 =item B<nographic=BOOLEAN>
@@ -903,7 +903,7 @@ device-model will become the default in 
 =back
 
 It is recommended to accept the default value for new guests.  If
-you have existing guests then, depeending on the nature of the guest
+you have existing guests then, depending on the nature of the guest
 Operating System, you may wish to force them to use the device
 model which they were installed with.
 
@@ -926,19 +926,19 @@ Assign an XSM security label to the devi
 
 =item B<device_model_args=[ "ARG", "ARG", ...]>
 
-Pass additional arbitrary options on the devide-model command
+Pass additional arbitrary options on the device-model command
 line. Each element in the list is passed as an option to the
 device-model.
 
 =item B<device_model_args_pv=[ "ARG", "ARG", ...]>
 
-Pass additional arbitrary options on the devide-model command line for
+Pass additional arbitrary options on the device-model command line for
 a PV device model only. Each element in the list is passed as an
 option to the device-model.
 
 =item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
 
-Pass additional arbitrary options on the devide-model command line for
+Pass additional arbitrary options on the device-model command line for
 an HVM device model only. Each element in the list is passed as an
 option to the device-model.
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 16:57:26 2012 +0100
@@ -50,7 +50,7 @@ setup the bridge.
 =item B<autoballoon>
 
 If you specify the amount of memory dom0 has, passing B<dom0_mem> to
-Xen, it is highly reccomended to disable B<autoballoon>. Edit
+Xen, it is highly recommended to disable B<autoballoon>. Edit
 B</etc/xen/xl.conf> and set it to 0.
 
 =item run xl as B<root>
@@ -808,7 +808,7 @@ the ratelimit (see below).
 
 Ratelimit attempts to limit the number of schedules per second.  It
 sets a minimum amount of time (in microseconds) a VM must run before
-we will allow a higher-prioirty VM to pre-empt it.  The default value
+we will allow a higher-priority VM to pre-empt it.  The default value
 is 1000 microseconds (1ms).  Valid range is 100 to 500000 (500ms).
 The ratelimit length must be lower than the timeslice length.
 
@@ -1233,7 +1233,7 @@ We need better documentation for:
 
 =item B<tmem>
 
-Trascendent Memory.
+Transcendent Memory.
 
 =back
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xm.pod.1
--- a/docs/man/xm.pod.1	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xm.pod.1	Thu Jun 28 16:57:26 2012 +0100
@@ -117,7 +117,7 @@ on the command line are replaced by the 
 
 =item B<-F=FILE>, B<--config=FILE>
 
-Use the given SXP formated configuration script.
+Use the given SXP formatted configuration script.
 SXP is the underlying configuration format used by Xen.
 SXP configuration scripts can be hand-written or generated
 from Python configuration scripts, using the -n
@@ -430,7 +430,7 @@ on the command line are replaced by the 
 
 =item B<-F=FILE>, B<--config=FILE>
 
-Use the given SXP formated configuration script.
+Use the given SXP formatted configuration script.
 SXP is the underlying configuration format used by Xen.
 SXP configuration scripts can be hand-written or generated
 from Python configuration scripts, using the -n
diff -r 3ea92ea1490f -r b2481fe8a395 docs/man/xmdomain.cfg.pod.5
--- a/docs/man/xmdomain.cfg.pod.5	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/man/xmdomain.cfg.pod.5	Thu Jun 28 16:57:26 2012 +0100
@@ -53,7 +53,7 @@ xen kernel.
 The amount of RAM, in megabytes, to allocate to the domain when it
 starts.  Allocating insufficient memory for a domain may produce
 extremely bizarre behavior.  If there isn't enough free memory left on
-the machine to fulfill this request, the domain will fail to start.
+the machine to fulfil this request, the domain will fail to start.
 
 Xen does not support overcommit of memory, so the total memory of all
 guests (+ 64 MB needed for Xen) must be less than or equal to the
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/distro_mapping.txt
--- a/docs/misc/distro_mapping.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/distro_mapping.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -22,6 +22,6 @@ one must grep for the above elements and
 
 For example if a new distro uses /etc/bork as its config dir, it's not
 sufficient to set CONFIG_LEAF_DIR=bork; one must also add tests for the
-existance of the bork dir in every context where config files are read.
+existence of the bork dir in every context where config files are read.
 
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/kexec_and_kdump.txt
--- a/docs/misc/kexec_and_kdump.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/kexec_and_kdump.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -3,8 +3,8 @@
 Kexec and Kdump for Xen
 =======================
 
-This is a breif guide to using Kexec and Kdump in conjunction with Xen.
-This functionaly works at the level of the hypervisor and dom0 kernel.
+This is a brief guide to using Kexec and Kdump in conjunction with Xen.
+This functionally works at the level of the hypervisor and dom0 kernel.
 And will thus affect all guests running on a machine.
 
 At this stage it does not work in conjunction with domU kernels.
@@ -33,7 +33,7 @@ Linux -> Xen   | first kernel       | se
 ---------------+--------------------+--------------------
 Linux -> Linux | first kernel       | second kernel
 
-If you are kexecing to Xen then you will also need to preapare the second
+If you are kexecing to Xen then you will also need to prepare the second
 hypervisor and dom0 kernel that will run after kexec. These may be the same
 as the first hypervisor and dom0 kernel that are used before kexec if you
 are kexecing from Xen to Xen.
@@ -176,7 +176,7 @@ running kernel.
 On x86 systems the crash kernel may be either
 - A uncompressed vmlinux image if the kernel is not relocatable
 - A compressed bzImage or vmlinuz image if the kernel is relocatable
-- Relocatability is crontroled by the CONFIG_RELOCATABLE kernel
+- Relocatability is controlled by the CONFIG_RELOCATABLE kernel
   compile configuration parameter. This option may not be available
   depending on the kernel version
 On ia64
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/tscmode.txt
--- a/docs/misc/tscmode.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/tscmode.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -121,7 +121,7 @@ may not remain) synchronized as "TSC-uns
 
 As a result of TSC's sordid history, two classes of applications use
 TSC: old applications designed for single processors, and the most recent
-enteprise applications which require high-frequency high-precision
+enterprise applications which require high-frequency high-precision
 timestamping.
 
 We will refer to apps that might break if running on a TSC-unsafe
@@ -151,13 +151,13 @@ instructions to trap.  This trap can be 
 then transparently "emulate" the results of the rdtsc instruction and
 return control to the code following the rdtsc instruction.
 
-To provide a "safe" TSC, i.e. to ensure both TSC monontonicity and a
+To provide a "safe" TSC, i.e. to ensure both TSC monotonicity and a
 fixed rate, Xen provides rdtsc emulation whenever necessary or when
 explicitly specified by a per-VM configuration option.  TSC emulation is
 relatively slow -- roughly 15-20 times slower than the rdtsc instruction
 when executed natively.  However, except when an OS or application uses
 the rdtsc instruction at a high frequency (e.g. more than about 10,000 times
-per second per processor), this performance degradation is not noticable
+per second per processor), this performance degradation is not noticeable
 (i.e. <0.3%).  And, TSC emulation is nearly always faster than
 OS-provided alternatives (e.g. Linux's gettimeofday).  For environments
 where it is certain that all apps are TSC-resilient (e.g.
@@ -196,7 +196,7 @@ all apps running in this virtual machine
 apps must either be TSC-resilient or pvrdtscp-modified.  Second,
 highest performance is only obtained on TSC-safe machines that
 support the rdtscp instruction; when running on older machines,
-rdtscp is emulated and thus slower.  For more information on PVRTSCP,
+rdtscp is emulated and thus slower.  For more information on PVRDTSCP,
 see below.
 
 Finally, tsc_mode==1 always enables TSC emulation, regardless of
@@ -243,7 +243,7 @@ saved, restore this domain will fail.
 There is another cpuid-related complication: The x86 cpuid instruction is
 non-privileged.  HVM domains are configured to always trap this instruction
 to Xen, where Xen can "filter" the result.  In a PV OS, all cpuid instructions
-have been replaced by a parvirtualized equivalent of the cpuid instruction
+have been replaced by a paravirtualized equivalent of the cpuid instruction
 ("pvcpuid") and also trap to Xen.  But apps in a PV guest that use a
 cpuid instruction execute it directly, without a trap to Xen.  As a result,
 an app may directly examine the physical TSC Invariant cpuid bit and make
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/vtpm.txt
--- a/docs/misc/vtpm.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/vtpm.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -78,7 +78,7 @@ ramdisk = "/xen/initrd_domU/U1_ramdisk.i
 memory = 32
 name = "TPMUserDomain0"
 vtpm = ['instance=1,backend=0']
-root = "/dev/ram0 cosole=tty ro"
+root = "/dev/ram0 console=tty ro"
 vif = ['backend=0']
 
 In the above configuration file the line 'vtpm = ...' provides
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xen-command-line.markdown	Thu Jun 28 16:57:26 2012 +0100
@@ -89,7 +89,7 @@ common, and only has an effect if your s
 
 The `acpi=noirq` option causes Xen to not parse the ACPI MADT table
 looking for IO-APIC entries.  This is also not common, and any system
-which requries this option to function should be blacklisted.
+which requires this option to function should be blacklisted.
 Additionally, this will not prevent Xen from finding IO-APIC entries
 from the MP tables.
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xenstore.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -202,7 +202,7 @@ WATCH			<wpath>|<token>|?
 	readable, some notifications may have been lost).
 
 WATCH_EVENT					<epath>|<token>|
-	Unsolicited `reply' generated for matching modfication events
+	Unsolicited `reply' generated for matching modification events
 	as described above.  req_id and tx_id are both 0.
 
 	<epath> is the event's path, ie the actual path that was
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xl-disk-configuration.txt
--- a/docs/misc/xl-disk-configuration.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xl-disk-configuration.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -72,7 +72,7 @@ Special syntax:
    syntax in the configuration file, it consumes the whole rest of the
    <diskspec>.  Therefore in that case it must come last.  This is
    permissible even if an empty value for the target was already
-   specifed as a positional parameter.  This is the only way to
+   specified as a positional parameter.  This is the only way to
    specify a target string containing metacharacters such as commas
    and (in some cases) colons, which would otherwise be
    misinterpreted.
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Thu Jun 28 16:57:26 2012 +0100
@@ -89,7 +89,7 @@ are:
 
   * `rtl8139` (default) -- Realtek RTL8139
   * `e1000` -- Intel E1000 
-  * in principal any device supported by your device model
+  * in principle any device supported by your device model
 
 ### vifname
 
diff -r 3ea92ea1490f -r b2481fe8a395 docs/misc/xsm-flask.txt
--- a/docs/misc/xsm-flask.txt	Thu Jun 28 15:18:05 2012 +0100
+++ b/docs/misc/xsm-flask.txt	Thu Jun 28 16:57:26 2012 +0100
@@ -226,7 +226,7 @@ 1) xen command line parameters
 	To boot the platform into enforcing mode, which means that the policy is
 	loaded and enforced, append 'flask_enforcing=1' on the grub line.
 	
-	This parameter may also be changed through the flask hyercall.
+	This parameter may also be changed through the flask hypercall.
 	
 	b) flask_enabled
 	

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHQR-0007NH-FL; Thu, 28 Jun 2012 16:18:35 +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 1SkHQQ-0007NC-7j
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:18:34 +0000
Received: from [193.109.254.147:65438] by server-6.bemta-14.messagelabs.com id
	34/B4-08993-9D38CEF4; Thu, 28 Jun 2012 16:18:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340900312!9032837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2998 invoked from network); 28 Jun 2012 16:18:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:18:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:18:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:18:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkHQN-0001TL-QQ; Thu, 28 Jun 2012 16:18:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkHQN-0008Aa-Nf;
	Thu, 28 Jun 2012 17:18:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.33751.709907.977385@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 17:18:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340896499.10942.70.camel@zakaz.uk.xensource.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
	<20460.29531.933964.18000@mariner.uk.xensource.com>
	<1340896499.10942.70.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Matt Wilson <msw@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> On Thu, 2012-06-28 at 16:08 +0100, Ian Jackson wrote:
> > Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
> > etc. ?  IMO it should, and the docs should say so.
> 
> Usually we would say "guest" rather than "domain" to convey this (a
> guest might consist of multiple domains).

Yes, that's the right terminology.

> > If it doesn't then that's IMO a bug but stubdoms are a bit buggy
> > anyway so I don't regard fixing that as a blocker for this patch.  But
> > I think we should introduce docs that are correct.
> > 
> > If you and Ian agree, perhaps you'd like to clarify that (and perhaps
> > change the usage message too).
> 
> I'm happy for the docs to change to reflect what we want but I don't
> want to delay this patch actually making the implementation match.

Exactly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHQR-0007NH-FL; Thu, 28 Jun 2012 16:18:35 +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 1SkHQQ-0007NC-7j
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:18:34 +0000
Received: from [193.109.254.147:65438] by server-6.bemta-14.messagelabs.com id
	34/B4-08993-9D38CEF4; Thu, 28 Jun 2012 16:18:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340900312!9032837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2998 invoked from network); 28 Jun 2012 16:18:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:18:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:18:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:18:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkHQN-0001TL-QQ; Thu, 28 Jun 2012 16:18:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkHQN-0008Aa-Nf;
	Thu, 28 Jun 2012 17:18:31 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.33751.709907.977385@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 17:18:31 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340896499.10942.70.camel@zakaz.uk.xensource.com>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
	<20460.29531.933964.18000@mariner.uk.xensource.com>
	<1340896499.10942.70.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Matt Wilson <msw@amazon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> On Thu, 2012-06-28 at 16:08 +0100, Ian Jackson wrote:
> > Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
> > etc. ?  IMO it should, and the docs should say so.
> 
> Usually we would say "guest" rather than "domain" to convey this (a
> guest might consist of multiple domains).

Yes, that's the right terminology.

> > If it doesn't then that's IMO a bug but stubdoms are a bit buggy
> > anyway so I don't regard fixing that as a blocker for this patch.  But
> > I think we should introduce docs that are correct.
> > 
> > If you and Ian agree, perhaps you'd like to clarify that (and perhaps
> > change the usage message too).
> 
> I'm happy for the docs to change to reflect what we want but I don't
> want to delay this patch actually making the implementation match.

Exactly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYj-0007fh-5z; Thu, 28 Jun 2012 16:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f7-Sw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:07 +0000
Received: from [85.158.143.99:11168] by server-2.bemta-4.messagelabs.com id
	69/70-17938-AD58CEF4; Thu, 28 Jun 2012 16:27:06 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9102 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WH-CI;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 53BA5340F57; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:23 +0100
Message-ID: <1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Introduce the global virq VIRQ_V4V

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/public/xen.h   |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)


--------------true
Content-Type: text/x-patch; name="0002-v4v-Introduce-VIRQ_V4V.patch"
Content-Disposition: attachment;
	filename="0002-v4v-Introduce-VIRQ_V4V.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..e138600 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -107,6 +107,7 @@ static int virq_is_global(uint32_t virq)
     case VIRQ_TIMER:
     case VIRQ_DEBUG:
     case VIRQ_XENOPROF:
+    case VIRQ_V4V:
         rc =3D 0;
         break;
     case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..033cbba 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,7 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_CON_RING   8  /* G. (DOM0) Bytes received on console       =
     */
 #define VIRQ_PCPU_STATE 9  /* G. (DOM0) PCPU state changed              =
     */
 #define VIRQ_MEM_EVENT  10 /* G. (DOM0) A memory event has occured      =
     */
-#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient                =
     */
+#define VIRQ_V4V        11 /* G. V4V event has occurred                 =
     */
 #define VIRQ_ENOMEM     12 /* G. (DOM0) Low on heap memory       */
=20
 /* Architecture-specific VIRQ definitions. */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYj-0007fh-5z; Thu, 28 Jun 2012 16:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f7-Sw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:07 +0000
Received: from [85.158.143.99:11168] by server-2.bemta-4.messagelabs.com id
	69/70-17938-AD58CEF4; Thu, 28 Jun 2012 16:27:06 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9102 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WH-CI;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 53BA5340F57; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:23 +0100
Message-ID: <1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Introduce the global virq VIRQ_V4V

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/public/xen.h   |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)


--------------true
Content-Type: text/x-patch; name="0002-v4v-Introduce-VIRQ_V4V.patch"
Content-Disposition: attachment;
	filename="0002-v4v-Introduce-VIRQ_V4V.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..e138600 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -107,6 +107,7 @@ static int virq_is_global(uint32_t virq)
     case VIRQ_TIMER:
     case VIRQ_DEBUG:
     case VIRQ_XENOPROF:
+    case VIRQ_V4V:
         rc =3D 0;
         break;
     case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..033cbba 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,7 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_CON_RING   8  /* G. (DOM0) Bytes received on console       =
     */
 #define VIRQ_PCPU_STATE 9  /* G. (DOM0) PCPU state changed              =
     */
 #define VIRQ_MEM_EVENT  10 /* G. (DOM0) A memory event has occured      =
     */
-#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient                =
     */
+#define VIRQ_V4V        11 /* G. V4V event has occurred                 =
     */
 #define VIRQ_ENOMEM     12 /* G. (DOM0) Low on heap memory       */
=20
 /* Architecture-specific VIRQ definitions. */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYi-0007fT-EQ; Thu, 28 Jun 2012 16:27:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f8-Cw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:06 +0000
Received: from [85.158.143.99:15856] by server-3.bemta-4.messagelabs.com id
	AF/86-05808-9D58CEF4; Thu, 28 Jun 2012 16:27:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9070 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WB-3A;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 1EA52340F57; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:21 +0100
Message-ID: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] RFC: V4V (v2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable

V4V is a copy based inter vm communication system.

Please have a look at this thread for more detail
about V4V.
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html

This patch series is work in progress but I wanted to
post it early enough so I can get feedback from people.

v2 changes:
  - Cleanup plugin header
  - Include basic access control
  - Use guest_handle_for_field
changes requested not a v2:
  - Switch to event channel instead of virq

Jean Guyader (5):
  xen: add ssize_t
  v4v: Introduce VIRQ_V4V
  xen: Enforce introduce guest_handle_for_field
  xen: Add V4V implementation
  v4v: Introduce basic access control to V4V

 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/event_channel.c         |    1 +
 xen/common/v4v.c                   | 2020 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-arm/types.h        |    1 +
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/asm-x86/types.h        |    6 +
 xen/include/public/v4v.h           |  243 +++++
 xen/include/public/xen.h           |    4 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/v4v.h              |  213 ++++
 15 files changed, 2517 insertions(+), 6 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

--=20
1.7.9.5


--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYi-0007fa-Ph; Thu, 28 Jun 2012 16:27:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f7-Cy
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:06 +0000
Received: from [85.158.143.99:15861] by server-2.bemta-4.messagelabs.com id
	26/70-17938-9D58CEF4; Thu, 28 Jun 2012 16:27:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9064 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WE-6x;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 36F1E341A45; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 17:26:22 +0100
Message-ID: <1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] xen: add ssize_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/asm-arm/types.h |    1 +
 xen/include/asm-x86/types.h |    6 ++++++
 2 files changed, 7 insertions(+)


--------------true
Content-Type: text/x-patch; name="0001-xen-add-ssize_t.patch"
Content-Disposition: attachment; filename="0001-xen-add-ssize_t.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..d2c5612 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -35,6 +35,7 @@ typedef u64 paddr_t;
 #define PRIpaddr "016llx"
=20
 typedef unsigned long size_t;
+typedef long ssize_t;
=20
 typedef char bool_t;
 #define test_and_set_bool(b)   xchg(&(b), 1)
diff --git a/xen/include/asm-x86/types.h b/xen/include/asm-x86/types.h
index 1c4c5d5..bb7ffc2 100644
--- a/xen/include/asm-x86/types.h
+++ b/xen/include/asm-x86/types.h
@@ -59,6 +59,12 @@ typedef char bool_t;
 #define test_and_set_bool(b)   xchg(&(b), 1)
 #define test_and_clear_bool(b) xchg(&(b), 0)
=20
+#if defined(__i386__)
+typedef int ssize_t;
+#else /* __x86_64 */
+typedef long ssize_t;
+#endif
+
 #endif /* __ASSEMBLY__ */
=20
 #endif /* __X86_TYPES_H__ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYj-0007fo-IR; Thu, 28 Jun 2012 16:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f8-Sm
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:07 +0000
Received: from [85.158.143.99:11153] by server-3.bemta-4.messagelabs.com id
	01/96-05808-9D58CEF4; Thu, 28 Jun 2012 16:27:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9087 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WK-Fx;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 7C259341A45; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 17:26:24 +0100
Message-ID: <1340900786-21802-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] xen: Enforce introduce
	guest_handle_for_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


This helper turns a field of a GUEST_HANDLE in
a GUEST_HANDLE.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/asm-x86/guest_access.h |    3 +++
 1 file changed, 3 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-Enforce-introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0003-xen-Enforce-introduce-guest_handle_for_field.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/gue=
st_access.h
index 2b429c2..e3ac1d6 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -51,6 +51,9 @@
     (XEN_GUEST_HANDLE(type)) { _x };            \
 })
=20
+#define guest_handle_for_field(hnd, type, fld)          \
+    ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
+
 #define guest_handle_from_ptr(ptr, type)        \
     ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
 #define const_guest_handle_from_ptr(ptr, type)  \

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYj-0007fo-IR; Thu, 28 Jun 2012 16:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f8-Sm
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:07 +0000
Received: from [85.158.143.99:11153] by server-3.bemta-4.messagelabs.com id
	01/96-05808-9D58CEF4; Thu, 28 Jun 2012 16:27:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9087 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WK-Fx;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 7C259341A45; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 17:26:24 +0100
Message-ID: <1340900786-21802-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] xen: Enforce introduce
	guest_handle_for_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


This helper turns a field of a GUEST_HANDLE in
a GUEST_HANDLE.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/asm-x86/guest_access.h |    3 +++
 1 file changed, 3 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-Enforce-introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0003-xen-Enforce-introduce-guest_handle_for_field.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/gue=
st_access.h
index 2b429c2..e3ac1d6 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -51,6 +51,9 @@
     (XEN_GUEST_HANDLE(type)) { _x };            \
 })
=20
+#define guest_handle_for_field(hnd, type, fld)          \
+    ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
+
 #define guest_handle_from_ptr(ptr, type)        \
     ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
 #define const_guest_handle_from_ptr(ptr, type)  \

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYi-0007fa-Ph; Thu, 28 Jun 2012 16:27:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f7-Cy
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:06 +0000
Received: from [85.158.143.99:15861] by server-2.bemta-4.messagelabs.com id
	26/70-17938-9D58CEF4; Thu, 28 Jun 2012 16:27:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9064 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WE-6x;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 36F1E341A45; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Jun 2012 17:26:22 +0100
Message-ID: <1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] xen: add ssize_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/asm-arm/types.h |    1 +
 xen/include/asm-x86/types.h |    6 ++++++
 2 files changed, 7 insertions(+)


--------------true
Content-Type: text/x-patch; name="0001-xen-add-ssize_t.patch"
Content-Disposition: attachment; filename="0001-xen-add-ssize_t.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..d2c5612 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -35,6 +35,7 @@ typedef u64 paddr_t;
 #define PRIpaddr "016llx"
=20
 typedef unsigned long size_t;
+typedef long ssize_t;
=20
 typedef char bool_t;
 #define test_and_set_bool(b)   xchg(&(b), 1)
diff --git a/xen/include/asm-x86/types.h b/xen/include/asm-x86/types.h
index 1c4c5d5..bb7ffc2 100644
--- a/xen/include/asm-x86/types.h
+++ b/xen/include/asm-x86/types.h
@@ -59,6 +59,12 @@ typedef char bool_t;
 #define test_and_set_bool(b)   xchg(&(b), 1)
 #define test_and_clear_bool(b) xchg(&(b), 0)
=20
+#if defined(__i386__)
+typedef int ssize_t;
+#else /* __x86_64 */
+typedef long ssize_t;
+#endif
+
 #endif /* __ASSEMBLY__ */
=20
 #endif /* __X86_TYPES_H__ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYi-0007fT-EQ; Thu, 28 Jun 2012 16:27:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYg-0007f8-Cw
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:06 +0000
Received: from [85.158.143.99:15856] by server-3.bemta-4.messagelabs.com id
	AF/86-05808-9D58CEF4; Thu, 28 Jun 2012 16:27:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9070 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:26:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:26:08 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WB-3A;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 1EA52340F57; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:21 +0100
Message-ID: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] RFC: V4V (v2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable

V4V is a copy based inter vm communication system.

Please have a look at this thread for more detail
about V4V.
http://lists.xen.org/archives/html/xen-devel/2012-05/msg01866.html

This patch series is work in progress but I wanted to
post it early enough so I can get feedback from people.

v2 changes:
  - Cleanup plugin header
  - Include basic access control
  - Use guest_handle_for_field
changes requested not a v2:
  - Switch to event channel instead of virq

Jean Guyader (5):
  xen: add ssize_t
  v4v: Introduce VIRQ_V4V
  xen: Enforce introduce guest_handle_for_field
  xen: Add V4V implementation
  v4v: Introduce basic access control to V4V

 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/event_channel.c         |    1 +
 xen/common/v4v.c                   | 2020 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-arm/types.h        |    1 +
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/asm-x86/types.h        |    6 +
 xen/include/public/v4v.h           |  243 +++++
 xen/include/public/xen.h           |    4 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/v4v.h              |  213 ++++
 15 files changed, 2517 insertions(+), 6 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

--=20
1.7.9.5


--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYj-0007fv-VD; Thu, 28 Jun 2012 16:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYh-0007f8-KN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:07 +0000
Received: from [85.158.143.99:11163] by server-3.bemta-4.messagelabs.com id
	91/96-05808-AD58CEF4; Thu, 28 Jun 2012 16:27:06 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9074 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16: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.213.0; Thu, 28 Jun 2012 17:26:09 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WO-LK;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id AF2C8341A45; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:26 +0100
Message-ID: <1340900786-21802-6-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] v4v: Introduce basic access control to V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/v4v.c         |  265 ++++++++++++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h |    3 +
 xen/include/xen/v4v.h    |   26 +++++
 3 files changed, 294 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0005-v4v-Introduce-basic-access-control-to-V4V.patch"
Content-Disposition: attachment;
	filename="0005-v4v-Introduce-basic-access-control-to-V4V.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/v4v.c b/xen/common/v4v.c
index e589fda..381fcdd 100644
--- a/xen/common/v4v.c
+++ b/xen/common/v4v.c
@@ -43,6 +43,7 @@
 #endif
=20
=20
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
=20
 DEFINE_XEN_GUEST_HANDLE (uint8_t);
 static struct v4v_ring_info *v4v_ring_find_info (struct domain *d,
@@ -1312,7 +1313,221 @@ v4v_notify (struct domain *d,
     return ret;
 }
=20
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule (struct v4v_viptables_rule_node *rule)
+{
+  if (rule =3D=3D NULL)
+    {
+      printk("(null)\n");
+      return;
+    }
+
+  if (rule->accept =3D=3D 1)
+    printk("ACCEPT");
+  else
+    printk("REJECT");
+
+  printk(" ");
+
+  if (rule->src.domain =3D=3D DOMID_INVALID)
+    printk("*");
+  else
+    printk("%i", rule->src.domain);
+
+  printk(":");
+
+  if (rule->src.port =3D=3D -1)
+    printk("*");
+  else
+    printk("%i", rule->src.port);
+
+  printk(" -> ");
+
+  if (rule->dst.domain =3D=3D DOMID_INVALID)
+    printk("*");
+  else
+    printk("%i", rule->dst.domain);
=20
+  printk(":");
+
+  if (rule->dst.port =3D=3D -1)
+    printk("*");
+  else
+    printk("%i", rule->dst.port);
+
+  printk("\n");
+}
+#endif /* V4V_DEBUG */
+
+int
+v4v_viptables_add (struct domain *src_d, XEN_GUEST_HANDLE(v4v_viptables_=
rule_t) rule,
+                   int32_t position)
+{
+  struct v4v_viptables_rule_node* new;
+  struct list_head* tmp;
+
+  /* First rule is n.1 */
+  position--;
+
+  new =3D xmalloc (struct v4v_viptables_rule_node);
+
+  if (copy_field_from_guest (new, rule, src))
+    return -EFAULT;
+  if (copy_field_from_guest (new, rule, dst))
+    return -EFAULT;
+  if (copy_field_from_guest (new, rule, accept))
+    return -EFAULT;
+
+#ifdef V4V_DEBUG
+  printk(KERN_ERR "VIPTables: ");
+  v4v_viptables_print_rule(new);
+#endif /* V4V_DEBUG */
+
+  tmp =3D &viprules;
+  while (position !=3D 0 && tmp->next !=3D &viprules)
+    {
+      tmp =3D tmp->next;
+      position--;
+    }
+  list_add(&new->list, tmp);
+
+  return 0;
+}
+
+int
+v4v_viptables_del (struct domain *src_d, XEN_GUEST_HANDLE(v4v_viptables_=
rule_t) rule,
+                   int32_t position)
+{
+  struct list_head *tmp =3D NULL;
+  struct list_head *next =3D NULL;
+  struct v4v_viptables_rule_node *node;
+  struct v4v_viptables_rule *r;
+
+  if (position !=3D -1)
+    {
+      /* We want to delete the rule number <position> */
+      tmp =3D &viprules;
+      while (position !=3D 0 && tmp->next !=3D &viprules)
+        {
+          tmp =3D tmp->next;
+          position--;
+        }
+    }
+  else if (!guest_handle_is_null(rule))
+    {
+      /* We want to delete the rule <rule> */
+      r =3D xmalloc (struct v4v_viptables_rule);
+
+      if (copy_field_from_guest (r, rule, src))
+        return -EFAULT;
+      if (copy_field_from_guest (r, rule, dst))
+        return -EFAULT;
+      if (copy_field_from_guest (r, rule, accept))
+        return -EFAULT;
+
+      list_for_each(tmp, &viprules)
+        {
+          node =3D list_entry(tmp, struct v4v_viptables_rule_node, list)=
;
+
+          if ((node->src.domain =3D=3D r->src.domain) &&
+              (node->src.port   =3D=3D r->src.port)   &&
+              (node->dst.domain =3D=3D r->dst.domain) &&
+              (node->dst.port   =3D=3D r->dst.port))
+            {
+              position =3D 0;
+              break;
+            }
+        }
+      xfree(r);
+    }
+  else
+    {
+      /* We want to flush the rules! */
+      printk(KERN_ERR "VIPTables: flushing rules\n");
+      list_for_each_safe(tmp, next, &viprules)
+        {
+          node =3D list_entry(tmp, struct v4v_viptables_rule_node, list)=
;
+          list_del(tmp);
+          xfree(node);
+        }
+    }
+
+#ifdef V4V_DEBUG
+  if (position =3D=3D 0 && tmp !=3D &viprules)
+    {
+      printk(KERN_ERR "VIPTables: deleting rule: ");
+      node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+      v4v_viptables_print_rule(node);
+      list_del(tmp);
+      xfree(node);
+    }
+#endif /* V4V_DEBUG */
+
+  return 0;
+}
+
+static size_t
+v4v_viptables_list (struct domain *src_d, XEN_GUEST_HANDLE(v4v_viptables=
_list_t) list_hnd)
+{
+  struct list_head *ptr;
+  struct v4v_viptables_rule_node *node;
+  struct v4v_viptables_list rules_list;
+  uint32_t nbrules;
+
+  memset(&rules_list, 0, sizeof (rules_list));
+  if (copy_field_from_guest (&rules_list, list_hnd, nb_rules))
+      return -EFAULT;
+
+  ptr =3D viprules.next;
+  while (rules_list.nb_rules !=3D 0 && ptr->next !=3D &viprules)
+  {
+      ptr =3D ptr->next;
+      rules_list.start_rule--;
+  }
+
+  if (rules_list.nb_rules !=3D 0)
+      return -EFAULT;
+
+  nbrules =3D 0;
+  while (nbrules < rules_list.nb_rules && ptr !=3D &viprules)
+  {
+      node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+      rules_list.rules[rules_list.nb_rules].src =3D node->src;
+      rules_list.rules[rules_list.nb_rules].dst =3D node->dst;
+      rules_list.rules[rules_list.nb_rules].accept =3D node->accept;
+
+      nbrules++;
+      ptr =3D ptr->next;
+  }
+
+  if (copy_to_guest(list_hnd, &rules_list, 1))
+      return -EFAULT;
+
+  return 0;
+}
+
+static size_t
+v4v_viptables_check (v4v_addr_t * src, v4v_addr_t * dst)
+{
+  struct list_head *ptr;
+  struct v4v_viptables_rule_node *node;
+
+  list_for_each(ptr, &viprules)
+    {
+      node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+      if ((node->src.domain =3D=3D DOMID_INVALID || node->src.domain =3D=
=3D src->domain) &&
+          (node->src.port   =3D=3D -1            || node->src.port   =3D=
=3D src->port)   &&
+          (node->dst.domain =3D=3D DOMID_INVALID || node->dst.domain =3D=
=3D dst->domain) &&
+          (node->dst.port   =3D=3D -1            || node->dst.port   =3D=
=3D dst->port))
+        return !node->accept;
+    }
+
+  /* Defaulting to ACCEPT */
+  return 0;
+}
=20
 /*Hypercall to do the send*/
 static size_t
@@ -1351,6 +1566,15 @@ v4v_send (struct domain *src_d, v4v_addr_t * src_a=
ddr,
         return -ECONNREFUSED;
     }
=20
+    if (v4v_viptables_check(src_addr, dst_addr) !=3D 0)
+    {
+      read_unlock (&v4v_lock);
+      printk(KERN_ERR "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+             src_addr->domain, src_addr->port,
+             dst_addr->domain, dst_addr->port);
+      return -ECONNREFUSED;
+    }
+
     do
     {
         if ( !dst_d->v4v )
@@ -1437,6 +1661,15 @@ v4v_sendv (struct domain *src_d, v4v_addr_t * src_=
addr,
         return -ECONNREFUSED;
     }
=20
+    if (v4v_viptables_check(src_addr, dst_addr) !=3D 0)
+    {
+      read_unlock (&v4v_lock);
+      printk(KERN_ERR "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+             src_addr->domain, src_addr->port,
+             dst_addr->domain, dst_addr->port);
+      return -ECONNREFUSED;
+    }
+
     do
     {
         if ( !dst_d->v4v )
@@ -1596,6 +1829,38 @@ do_v4v_op (int cmd, XEN_GUEST_HANDLE (void) arg1,
                 rc =3D v4v_notify (d, ring_data_hnd);
                 break;
             }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg4;
+                XEN_GUEST_HANDLE (v4v_viptables_rule_t) rule_hnd =3D
+                    guest_handle_cast (arg1, v4v_viptables_rule_t);
+                rc =3D -EPERM;
+                if (!IS_PRIV(d))
+                    goto out;
+                rc =3D v4v_viptables_add (d, rule_hnd, position);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg4;
+                XEN_GUEST_HANDLE (v4v_viptables_rule_t) rule_hnd =3D
+                    guest_handle_cast (arg1, v4v_viptables_rule_t);
+                rc =3D -EPERM;
+                if (!IS_PRIV(d))
+                    goto out;
+                rc =3D v4v_viptables_del (d, rule_hnd, position);
+                break;
+            }
+        case V4VOP_viptables_list:
+            {
+                XEN_GUEST_HANDLE (v4v_viptables_list_t) rules_list_hnd =3D
+                    guest_handle_cast(arg1, v4v_viptables_list_t);
+                rc =3D -EPERM;
+                if (!IS_PRIV(d))
+                    goto out;
+                rc =3D v4v_viptables_list (d, rules_list_hnd);
+                break;
+            }
         default:
             rc =3D -ENOSYS;
             break;
diff --git a/xen/include/public/v4v.h b/xen/include/public/v4v.h
index 197770e..d8ca507 100644
--- a/xen/include/public/v4v.h
+++ b/xen/include/public/v4v.h
@@ -213,6 +213,9 @@
  *               NULL, NULL, nent, 0)
  */
=20
+#define V4VOP_viptables_add     6
+#define V4VOP_viptables_del     7
+#define V4VOP_viptables_list    8
=20
 #define V4VOP_sendv		5
 /*
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
index 641a6a8..e5b4cb7 100644
--- a/xen/include/xen/v4v.h
+++ b/xen/include/xen/v4v.h
@@ -103,6 +103,32 @@ struct v4v_ring_message_header
     uint8_t data[0];
 } V4V_PACKED;
=20
+typedef struct v4v_viptables_rule
+{
+    struct v4v_addr src;
+    struct v4v_addr dst;
+    uint32_t accept;
+} V4V_PACKED v4v_viptables_rule_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+
+struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    struct v4v_addr src;
+    struct v4v_addr dst;
+    uint32_t accept;
+} V4V_PACKED;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+    struct v4v_viptables_rule rules[0];
+} V4V_PACKED v4v_viptables_list_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
 /*
  * Helper functions
  */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHYj-0007fv-VD; Thu, 28 Jun 2012 16:27:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHYh-0007f8-KN
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:27:07 +0000
Received: from [85.158.143.99:11163] by server-3.bemta-4.messagelabs.com id
	91/96-05808-AD58CEF4; Thu, 28 Jun 2012 16:27:06 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340900824!22590530!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9074 invoked from network); 28 Jun 2012 16:27:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:27:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16: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.213.0; Thu, 28 Jun 2012 17:26:09 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WO-LK;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id AF2C8341A45; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:26 +0100
Message-ID: <1340900786-21802-6-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] v4v: Introduce basic access control to V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/v4v.c         |  265 ++++++++++++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h |    3 +
 xen/include/xen/v4v.h    |   26 +++++
 3 files changed, 294 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0005-v4v-Introduce-basic-access-control-to-V4V.patch"
Content-Disposition: attachment;
	filename="0005-v4v-Introduce-basic-access-control-to-V4V.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/v4v.c b/xen/common/v4v.c
index e589fda..381fcdd 100644
--- a/xen/common/v4v.c
+++ b/xen/common/v4v.c
@@ -43,6 +43,7 @@
 #endif
=20
=20
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
=20
 DEFINE_XEN_GUEST_HANDLE (uint8_t);
 static struct v4v_ring_info *v4v_ring_find_info (struct domain *d,
@@ -1312,7 +1313,221 @@ v4v_notify (struct domain *d,
     return ret;
 }
=20
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule (struct v4v_viptables_rule_node *rule)
+{
+  if (rule =3D=3D NULL)
+    {
+      printk("(null)\n");
+      return;
+    }
+
+  if (rule->accept =3D=3D 1)
+    printk("ACCEPT");
+  else
+    printk("REJECT");
+
+  printk(" ");
+
+  if (rule->src.domain =3D=3D DOMID_INVALID)
+    printk("*");
+  else
+    printk("%i", rule->src.domain);
+
+  printk(":");
+
+  if (rule->src.port =3D=3D -1)
+    printk("*");
+  else
+    printk("%i", rule->src.port);
+
+  printk(" -> ");
+
+  if (rule->dst.domain =3D=3D DOMID_INVALID)
+    printk("*");
+  else
+    printk("%i", rule->dst.domain);
=20
+  printk(":");
+
+  if (rule->dst.port =3D=3D -1)
+    printk("*");
+  else
+    printk("%i", rule->dst.port);
+
+  printk("\n");
+}
+#endif /* V4V_DEBUG */
+
+int
+v4v_viptables_add (struct domain *src_d, XEN_GUEST_HANDLE(v4v_viptables_=
rule_t) rule,
+                   int32_t position)
+{
+  struct v4v_viptables_rule_node* new;
+  struct list_head* tmp;
+
+  /* First rule is n.1 */
+  position--;
+
+  new =3D xmalloc (struct v4v_viptables_rule_node);
+
+  if (copy_field_from_guest (new, rule, src))
+    return -EFAULT;
+  if (copy_field_from_guest (new, rule, dst))
+    return -EFAULT;
+  if (copy_field_from_guest (new, rule, accept))
+    return -EFAULT;
+
+#ifdef V4V_DEBUG
+  printk(KERN_ERR "VIPTables: ");
+  v4v_viptables_print_rule(new);
+#endif /* V4V_DEBUG */
+
+  tmp =3D &viprules;
+  while (position !=3D 0 && tmp->next !=3D &viprules)
+    {
+      tmp =3D tmp->next;
+      position--;
+    }
+  list_add(&new->list, tmp);
+
+  return 0;
+}
+
+int
+v4v_viptables_del (struct domain *src_d, XEN_GUEST_HANDLE(v4v_viptables_=
rule_t) rule,
+                   int32_t position)
+{
+  struct list_head *tmp =3D NULL;
+  struct list_head *next =3D NULL;
+  struct v4v_viptables_rule_node *node;
+  struct v4v_viptables_rule *r;
+
+  if (position !=3D -1)
+    {
+      /* We want to delete the rule number <position> */
+      tmp =3D &viprules;
+      while (position !=3D 0 && tmp->next !=3D &viprules)
+        {
+          tmp =3D tmp->next;
+          position--;
+        }
+    }
+  else if (!guest_handle_is_null(rule))
+    {
+      /* We want to delete the rule <rule> */
+      r =3D xmalloc (struct v4v_viptables_rule);
+
+      if (copy_field_from_guest (r, rule, src))
+        return -EFAULT;
+      if (copy_field_from_guest (r, rule, dst))
+        return -EFAULT;
+      if (copy_field_from_guest (r, rule, accept))
+        return -EFAULT;
+
+      list_for_each(tmp, &viprules)
+        {
+          node =3D list_entry(tmp, struct v4v_viptables_rule_node, list)=
;
+
+          if ((node->src.domain =3D=3D r->src.domain) &&
+              (node->src.port   =3D=3D r->src.port)   &&
+              (node->dst.domain =3D=3D r->dst.domain) &&
+              (node->dst.port   =3D=3D r->dst.port))
+            {
+              position =3D 0;
+              break;
+            }
+        }
+      xfree(r);
+    }
+  else
+    {
+      /* We want to flush the rules! */
+      printk(KERN_ERR "VIPTables: flushing rules\n");
+      list_for_each_safe(tmp, next, &viprules)
+        {
+          node =3D list_entry(tmp, struct v4v_viptables_rule_node, list)=
;
+          list_del(tmp);
+          xfree(node);
+        }
+    }
+
+#ifdef V4V_DEBUG
+  if (position =3D=3D 0 && tmp !=3D &viprules)
+    {
+      printk(KERN_ERR "VIPTables: deleting rule: ");
+      node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+      v4v_viptables_print_rule(node);
+      list_del(tmp);
+      xfree(node);
+    }
+#endif /* V4V_DEBUG */
+
+  return 0;
+}
+
+static size_t
+v4v_viptables_list (struct domain *src_d, XEN_GUEST_HANDLE(v4v_viptables=
_list_t) list_hnd)
+{
+  struct list_head *ptr;
+  struct v4v_viptables_rule_node *node;
+  struct v4v_viptables_list rules_list;
+  uint32_t nbrules;
+
+  memset(&rules_list, 0, sizeof (rules_list));
+  if (copy_field_from_guest (&rules_list, list_hnd, nb_rules))
+      return -EFAULT;
+
+  ptr =3D viprules.next;
+  while (rules_list.nb_rules !=3D 0 && ptr->next !=3D &viprules)
+  {
+      ptr =3D ptr->next;
+      rules_list.start_rule--;
+  }
+
+  if (rules_list.nb_rules !=3D 0)
+      return -EFAULT;
+
+  nbrules =3D 0;
+  while (nbrules < rules_list.nb_rules && ptr !=3D &viprules)
+  {
+      node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+      rules_list.rules[rules_list.nb_rules].src =3D node->src;
+      rules_list.rules[rules_list.nb_rules].dst =3D node->dst;
+      rules_list.rules[rules_list.nb_rules].accept =3D node->accept;
+
+      nbrules++;
+      ptr =3D ptr->next;
+  }
+
+  if (copy_to_guest(list_hnd, &rules_list, 1))
+      return -EFAULT;
+
+  return 0;
+}
+
+static size_t
+v4v_viptables_check (v4v_addr_t * src, v4v_addr_t * dst)
+{
+  struct list_head *ptr;
+  struct v4v_viptables_rule_node *node;
+
+  list_for_each(ptr, &viprules)
+    {
+      node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+      if ((node->src.domain =3D=3D DOMID_INVALID || node->src.domain =3D=
=3D src->domain) &&
+          (node->src.port   =3D=3D -1            || node->src.port   =3D=
=3D src->port)   &&
+          (node->dst.domain =3D=3D DOMID_INVALID || node->dst.domain =3D=
=3D dst->domain) &&
+          (node->dst.port   =3D=3D -1            || node->dst.port   =3D=
=3D dst->port))
+        return !node->accept;
+    }
+
+  /* Defaulting to ACCEPT */
+  return 0;
+}
=20
 /*Hypercall to do the send*/
 static size_t
@@ -1351,6 +1566,15 @@ v4v_send (struct domain *src_d, v4v_addr_t * src_a=
ddr,
         return -ECONNREFUSED;
     }
=20
+    if (v4v_viptables_check(src_addr, dst_addr) !=3D 0)
+    {
+      read_unlock (&v4v_lock);
+      printk(KERN_ERR "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+             src_addr->domain, src_addr->port,
+             dst_addr->domain, dst_addr->port);
+      return -ECONNREFUSED;
+    }
+
     do
     {
         if ( !dst_d->v4v )
@@ -1437,6 +1661,15 @@ v4v_sendv (struct domain *src_d, v4v_addr_t * src_=
addr,
         return -ECONNREFUSED;
     }
=20
+    if (v4v_viptables_check(src_addr, dst_addr) !=3D 0)
+    {
+      read_unlock (&v4v_lock);
+      printk(KERN_ERR "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+             src_addr->domain, src_addr->port,
+             dst_addr->domain, dst_addr->port);
+      return -ECONNREFUSED;
+    }
+
     do
     {
         if ( !dst_d->v4v )
@@ -1596,6 +1829,38 @@ do_v4v_op (int cmd, XEN_GUEST_HANDLE (void) arg1,
                 rc =3D v4v_notify (d, ring_data_hnd);
                 break;
             }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg4;
+                XEN_GUEST_HANDLE (v4v_viptables_rule_t) rule_hnd =3D
+                    guest_handle_cast (arg1, v4v_viptables_rule_t);
+                rc =3D -EPERM;
+                if (!IS_PRIV(d))
+                    goto out;
+                rc =3D v4v_viptables_add (d, rule_hnd, position);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg4;
+                XEN_GUEST_HANDLE (v4v_viptables_rule_t) rule_hnd =3D
+                    guest_handle_cast (arg1, v4v_viptables_rule_t);
+                rc =3D -EPERM;
+                if (!IS_PRIV(d))
+                    goto out;
+                rc =3D v4v_viptables_del (d, rule_hnd, position);
+                break;
+            }
+        case V4VOP_viptables_list:
+            {
+                XEN_GUEST_HANDLE (v4v_viptables_list_t) rules_list_hnd =3D
+                    guest_handle_cast(arg1, v4v_viptables_list_t);
+                rc =3D -EPERM;
+                if (!IS_PRIV(d))
+                    goto out;
+                rc =3D v4v_viptables_list (d, rules_list_hnd);
+                break;
+            }
         default:
             rc =3D -ENOSYS;
             break;
diff --git a/xen/include/public/v4v.h b/xen/include/public/v4v.h
index 197770e..d8ca507 100644
--- a/xen/include/public/v4v.h
+++ b/xen/include/public/v4v.h
@@ -213,6 +213,9 @@
  *               NULL, NULL, nent, 0)
  */
=20
+#define V4VOP_viptables_add     6
+#define V4VOP_viptables_del     7
+#define V4VOP_viptables_list    8
=20
 #define V4VOP_sendv		5
 /*
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
index 641a6a8..e5b4cb7 100644
--- a/xen/include/xen/v4v.h
+++ b/xen/include/xen/v4v.h
@@ -103,6 +103,32 @@ struct v4v_ring_message_header
     uint8_t data[0];
 } V4V_PACKED;
=20
+typedef struct v4v_viptables_rule
+{
+    struct v4v_addr src;
+    struct v4v_addr dst;
+    uint32_t accept;
+} V4V_PACKED v4v_viptables_rule_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+
+struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    struct v4v_addr src;
+    struct v4v_addr dst;
+    uint32_t accept;
+} V4V_PACKED;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+    struct v4v_viptables_rule rules[0];
+} V4V_PACKED v4v_viptables_list_t;
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
 /*
  * Helper functions
  */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:29:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16:29: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 1SkHaR-000838-Lc; Thu, 28 Jun 2012 16:28: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 1SkHaQ-00082n-1y
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 16:28:54 +0000
Received: from [85.158.138.51:47036] by server-10.bemta-3.messagelabs.com id
	2F/C3-01753-5468CEF4; Thu, 28 Jun 2012 16:28:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340900932!21142391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26040 invoked from network); 28 Jun 2012 16:28:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:28:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:28:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:28:52 +0100
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 1SkHaN-0001XI-Vu;
	Thu, 28 Jun 2012 16:28:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkHaN-0005tz-MF;
	Thu, 28 Jun 2012 17:28:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13382-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 17:28:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13382: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13382 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13382/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13338
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13338
 build-amd64                   4 xen-build                 fail REGR. vs. 13338

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-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:29:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16:29: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 1SkHaR-000838-Lc; Thu, 28 Jun 2012 16:28: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 1SkHaQ-00082n-1y
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 16:28:54 +0000
Received: from [85.158.138.51:47036] by server-10.bemta-3.messagelabs.com id
	2F/C3-01753-5468CEF4; Thu, 28 Jun 2012 16:28:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340900932!21142391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26040 invoked from network); 28 Jun 2012 16:28:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:28:52 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:28:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:28:52 +0100
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 1SkHaN-0001XI-Vu;
	Thu, 28 Jun 2012 16:28:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkHaN-0005tz-MF;
	Thu, 28 Jun 2012 17:28:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13382-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 17:28:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13382: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13382 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13382/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13338
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13338
 build-amd64                   4 xen-build                 fail REGR. vs. 13338

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-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-win  13 guest-stop                   fail   never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-qemuu-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemuu-win-vcpus1                          blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-amd64-qemuu-win                                   blocked 
 test-amd64-i386-qemuu-win                                    blocked 
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                blocked 
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHhd-0000GE-L9; Thu, 28 Jun 2012 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 <jean.guyader@gmail.com>) id 1SkHhb-0000G9-Sa
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:36:20 +0000
Received: from [85.158.143.35:24206] by server-3.bemta-4.messagelabs.com id
	8D/21-05808-3088CEF4; Thu, 28 Jun 2012 16:36:19 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340901375!4621894!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18174 invoked from network); 28 Jun 2012 16:36:16 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:36:16 -0000
Received: by vcbfo13 with SMTP id fo13so2066545vcb.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 09:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=f9vqxOu4Ph/8jrIRiRMf+i1WR50f248cO6mfblQLWK4=;
	b=uHImtwZ1CjVNhZtF/19LsxRhSJlVwjfxqMqxURzjfdod+Ms0A9tclmoh1Ug5/bjeXK
	Oo+K/HkRQvLCPW9zpUJUOZGqRRBFiv+bPO3vgbfTdzSbQD/0h6EmuDcl5q/ukTS6X9sw
	ctkUVCc6+WxpcCBcqTEpT1FnTuvo354iBvLuR6tpdM+3Uuxd4jxLuJPmmxamEukHuUAh
	QurkePEE+6BeaB97VmOmruZF9HE0iRaUKphoXh6gmn9x64JuJarl3ZkpzzRsI2ncDywb
	f5dS03XT8u4RtkY/hA09B6Yzy6A6y5x1oP41C8M5alZEiVTPqP3TmN0B1vMt+rUB3o+T
	71dQ==
Received: by 10.220.219.71 with SMTP id ht7mr2255725vcb.3.1340901375431; Thu,
	28 Jun 2012 09:36:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Thu, 28 Jun 2012 09:35:55 -0700 (PDT)
In-Reply-To: <1340891262.10942.51.camel@zakaz.uk.xensource.com>
References: <20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
	<1340887016.10942.42.camel@zakaz.uk.xensource.com>
	<20120628134308.GD15863@spongy>
	<1340891262.10942.51.camel@zakaz.uk.xensource.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 28 Jun 2012 17:35:55 +0100
Message-ID: <CAEBdQ92ZqQ7DedsDXTvMUxdgJT+6j8t1XNGBbpK2gWtPvEdySw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28 June 2012 14:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-06-28 at 14:43 +0100, Jean Guyader wrote:
>> On 28/06 01:36, Ian Campbell wrote:
>> > On Thu, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
>> > > On 28/06 12:58, Ian Campbell wrote:
>> > > > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
>> > > > > On 28/06 12:34, Ian Campbell wrote:
>> > > > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
>> > > > > > > On 26/06 03:38, Ian Campbell wrote:
>> > > > > > > > Hi,
>> > > > > > > >
>> > > > > > > > Sorry it's taken me so long to get round to responding to =
this.
>> > > > > > > >
>> > > > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
>> > > > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrot=
e:
>> > > > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
>> > > > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader =
wrote:
>> > > > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
>> > > > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyad=
er wrote:
>> > > > > > > > > > >> > > Are you talking about having different version =
of V4V driver running
>> > > > > > > > > > >> > > in the same VM?
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > Yes.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > > I don't think that is a problem they both inter=
act with Xen via
>> > > > > > > > > > >> > > hypercall directly so if they follow the v4v hy=
percall interface it's
>> > > > > > > > > > >> > > all fine.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > AFAICS if they both try to register the same port=
 then one of them will
>> > > > > > > > > > >> > silently get its ring discarded. =A0And if they b=
oth try to communicate
>> > > > > > > > > > >> > with the same remote port their entries on the pe=
nding lists will get
>> > > > > > > > > > >> > merged (which is probably not too bad). =A0I thin=
k the possibility for
>> > > > > > > > > > >> > confusion depends on how you use the service. =A0=
Still, it seems better
>> > > > > > > > > > >> > than the xenstore case, anyway. :)
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > > >> Not silently, register_ring will return an error.
>> > > > > > > > > > >
>> > > > > > > > > > > Will it? =A0It looks to me like v4v_ring_add just cl=
obbers the old MFN
>> > > > > > > > > > > list.
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Ha yes. It does that now but I think it should return =
an error
>> > > > > > > > > > informing up the stack that a ring has already been re=
gistered.
>> > > > > > > > >
>> > > > > > > > > Actually, I think it's deliberate, to allow a guest to r=
e-register all
>> > > > > > > > > its rings after a suspend/resume or migration, without h=
aving to worry
>> > > > > > > > > about whether it was actually migrated into a new domain=
 or not.
>> > > > > > > >
>> > > > > > > > Which takes us back to the original issue Tim asked about =
with
>> > > > > > > > cohabitation of multiple (perhaps just plain buggy or even=
 malicious)
>> > > > > > > > v4v clients in a single domain, doesn't it?
>> > > > > > > >
>> > > > > > >
>> > > > > > > There is nothing wrong the two v4v driver running in the sam=
e guest.
>> > > > > > > The probably that Tim reported was about trying to create tw=
o connections
>> > > > > > > on the same port. Today with the code that I've submited in =
the RFC
>> > > > > > > one will overwrite the other silently which isn't a good thi=
ng, that can
>> > > > > > > easily be changed to notify which one got registered up the =
stack.
>> > > > > >
>> > > > > > So they'd somehow need to randomise (and retry) their use of s=
ource
>> > > > > > ports in order to co-exist?
>> > > > > >
>> > > > >
>> > > > > That can be assimilated to two userspace programs trying to bind=
 to the
>> > > > > same TCP port. I think it's not v4v's responsability to solve th=
is problem.
>> > > >
>> > > > An application using TCP doesn't need to worry about choosing its =
own
>> > > > source port though.
>> > > >
>> > > > Or does this only effect destination / listening ports?
>> > > >
>> > >
>> > > The guest v4v driver knows which port are in used so if you put port=
 0
>> > > we will pick a random unused number for the source port.
>> >
>> > Except when there are two such drivers each doesn't know which the oth=
er
>> > one is using.
>> >
>>
>> Then the kernel will try to register the ring and the hypercall will fail
>> because it's already registered.
>
> At which point what happens? How do two unrelated V4V drivers co-exist
> given this?
>

It happens when both driver will start registering their rings and if they =
are
using the same port. One will get a success out of the hypercall the other =
one
a failure. If we are in the case that user space used 0 for port we
will retry with
another random port number until it succeed.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHhd-0000GE-L9; Thu, 28 Jun 2012 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 <jean.guyader@gmail.com>) id 1SkHhb-0000G9-Sa
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:36:20 +0000
Received: from [85.158.143.35:24206] by server-3.bemta-4.messagelabs.com id
	8D/21-05808-3088CEF4; Thu, 28 Jun 2012 16:36:19 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340901375!4621894!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18174 invoked from network); 28 Jun 2012 16:36:16 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:36:16 -0000
Received: by vcbfo13 with SMTP id fo13so2066545vcb.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 09:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=f9vqxOu4Ph/8jrIRiRMf+i1WR50f248cO6mfblQLWK4=;
	b=uHImtwZ1CjVNhZtF/19LsxRhSJlVwjfxqMqxURzjfdod+Ms0A9tclmoh1Ug5/bjeXK
	Oo+K/HkRQvLCPW9zpUJUOZGqRRBFiv+bPO3vgbfTdzSbQD/0h6EmuDcl5q/ukTS6X9sw
	ctkUVCc6+WxpcCBcqTEpT1FnTuvo354iBvLuR6tpdM+3Uuxd4jxLuJPmmxamEukHuUAh
	QurkePEE+6BeaB97VmOmruZF9HE0iRaUKphoXh6gmn9x64JuJarl3ZkpzzRsI2ncDywb
	f5dS03XT8u4RtkY/hA09B6Yzy6A6y5x1oP41C8M5alZEiVTPqP3TmN0B1vMt+rUB3o+T
	71dQ==
Received: by 10.220.219.71 with SMTP id ht7mr2255725vcb.3.1340901375431; Thu,
	28 Jun 2012 09:36:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Thu, 28 Jun 2012 09:35:55 -0700 (PDT)
In-Reply-To: <1340891262.10942.51.camel@zakaz.uk.xensource.com>
References: <20120614153556.GI90181@ocelot.phlegethon.org>
	<CAEBdQ91E5yr=vi6wz682qrWsPe5DC0RMoJ_sYrLWm69JZ_6hEw@mail.gmail.com>
	<20120625090537.GC1488@ocelot.phlegethon.org>
	<1340721486.3832.145.camel@zakaz.uk.xensource.com>
	<20120628103858.GB7935@spongy>
	<1340883253.10942.38.camel@zakaz.uk.xensource.com>
	<20120628114314.GB15863@spongy>
	<1340884734.10942.39.camel@zakaz.uk.xensource.com>
	<20120628121056.GC15863@spongy>
	<1340887016.10942.42.camel@zakaz.uk.xensource.com>
	<20120628134308.GD15863@spongy>
	<1340891262.10942.51.camel@zakaz.uk.xensource.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 28 Jun 2012 17:35:55 +0100
Message-ID: <CAEBdQ92ZqQ7DedsDXTvMUxdgJT+6j8t1XNGBbpK2gWtPvEdySw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jean Guyader <jean.guyader@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28 June 2012 14:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-06-28 at 14:43 +0100, Jean Guyader wrote:
>> On 28/06 01:36, Ian Campbell wrote:
>> > On Thu, 2012-06-28 at 13:10 +0100, Jean Guyader wrote:
>> > > On 28/06 12:58, Ian Campbell wrote:
>> > > > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote:
>> > > > > On 28/06 12:34, Ian Campbell wrote:
>> > > > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote:
>> > > > > > > On 26/06 03:38, Ian Campbell wrote:
>> > > > > > > > Hi,
>> > > > > > > >
>> > > > > > > > Sorry it's taken me so long to get round to responding to =
this.
>> > > > > > > >
>> > > > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote:
>> > > > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrot=
e:
>> > > > > > > > > > On 14 June 2012 16:35, Tim Deegan <tim@xen.org> wrote:
>> > > > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader =
wrote:
>> > > > > > > > > > >> On 14/06 03:56, Tim Deegan wrote:
>> > > > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyad=
er wrote:
>> > > > > > > > > > >> > > Are you talking about having different version =
of V4V driver running
>> > > > > > > > > > >> > > in the same VM?
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > Yes.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > > I don't think that is a problem they both inter=
act with Xen via
>> > > > > > > > > > >> > > hypercall directly so if they follow the v4v hy=
percall interface it's
>> > > > > > > > > > >> > > all fine.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > AFAICS if they both try to register the same port=
 then one of them will
>> > > > > > > > > > >> > silently get its ring discarded. =A0And if they b=
oth try to communicate
>> > > > > > > > > > >> > with the same remote port their entries on the pe=
nding lists will get
>> > > > > > > > > > >> > merged (which is probably not too bad). =A0I thin=
k the possibility for
>> > > > > > > > > > >> > confusion depends on how you use the service. =A0=
Still, it seems better
>> > > > > > > > > > >> > than the xenstore case, anyway. :)
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > > >> Not silently, register_ring will return an error.
>> > > > > > > > > > >
>> > > > > > > > > > > Will it? =A0It looks to me like v4v_ring_add just cl=
obbers the old MFN
>> > > > > > > > > > > list.
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Ha yes. It does that now but I think it should return =
an error
>> > > > > > > > > > informing up the stack that a ring has already been re=
gistered.
>> > > > > > > > >
>> > > > > > > > > Actually, I think it's deliberate, to allow a guest to r=
e-register all
>> > > > > > > > > its rings after a suspend/resume or migration, without h=
aving to worry
>> > > > > > > > > about whether it was actually migrated into a new domain=
 or not.
>> > > > > > > >
>> > > > > > > > Which takes us back to the original issue Tim asked about =
with
>> > > > > > > > cohabitation of multiple (perhaps just plain buggy or even=
 malicious)
>> > > > > > > > v4v clients in a single domain, doesn't it?
>> > > > > > > >
>> > > > > > >
>> > > > > > > There is nothing wrong the two v4v driver running in the sam=
e guest.
>> > > > > > > The probably that Tim reported was about trying to create tw=
o connections
>> > > > > > > on the same port. Today with the code that I've submited in =
the RFC
>> > > > > > > one will overwrite the other silently which isn't a good thi=
ng, that can
>> > > > > > > easily be changed to notify which one got registered up the =
stack.
>> > > > > >
>> > > > > > So they'd somehow need to randomise (and retry) their use of s=
ource
>> > > > > > ports in order to co-exist?
>> > > > > >
>> > > > >
>> > > > > That can be assimilated to two userspace programs trying to bind=
 to the
>> > > > > same TCP port. I think it's not v4v's responsability to solve th=
is problem.
>> > > >
>> > > > An application using TCP doesn't need to worry about choosing its =
own
>> > > > source port though.
>> > > >
>> > > > Or does this only effect destination / listening ports?
>> > > >
>> > >
>> > > The guest v4v driver knows which port are in used so if you put port=
 0
>> > > we will pick a random unused number for the source port.
>> >
>> > Except when there are two such drivers each doesn't know which the oth=
er
>> > one is using.
>> >
>>
>> Then the kernel will try to register the ring and the hypercall will fail
>> because it's already registered.
>
> At which point what happens? How do two unrelated V4V drivers co-exist
> given this?
>

It happens when both driver will start registering their rings and if they =
are
using the same port. One will get a success out of the hypercall the other =
one
a failure. If we are in the case that user space used 0 for port we
will retry with
another random port number until it succeed.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHjp-0000NM-6O; Thu, 28 Jun 2012 16:38:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHjm-0000N8-3Z
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:38:35 +0000
Received: from [85.158.138.51:53681] by server-6.bemta-3.messagelabs.com id
	22/D9-11602-9888CEF4; Thu, 28 Jun 2012 16:38:33 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340901512!21143495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17436 invoked from network); 28 Jun 2012 16:38:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:38:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:38:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:38:31 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WN-J2;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 97AE9340F57; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:25 +0100
Message-ID: <1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/v4v.c                   | 1755 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  240 +++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/v4v.h              |  187 ++++
 11 files changed, 2211 insertions(+), 5 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0004-xen-Add-V4V-implementation.patch"
Content-Disposition: attachment;
	filename="0004-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..6f2d70e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3124,7 +3124,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hy=
percalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #else /* defined(__x86_64__) */
@@ -3209,7 +3210,8 @@ static hvm_hypercall_t *hvm_hypercall64_table[NR_hy=
percalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3226,7 +3228,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hy=
percalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #endif /* defined(__x86_64__) */
diff --git a/xen/arch/x86/x86_32/entry.S b/xen/arch/x86/x86_32/entry.S
index 2982679..b3e0da4 100644
--- a/xen/arch/x86/x86_32/entry.S
+++ b/xen/arch/x86/x86_32/entry.S
@@ -700,6 +700,7 @@ ENTRY(hypercall_table)
         .long do_domctl
         .long do_kexec_op
         .long do_tmem_op
+        .long do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/4)
         .long do_ni_hypercall
         .endr
@@ -748,6 +749,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec_op          */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index f49ff2d..28615f9 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 6 /* do_v4v_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 3836260..918fa59 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -699,6 +699,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -747,6 +748,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9eba8bc..fe3c72c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y +=3D tmem_xen.o
 obj-y +=3D radix-tree.o
 obj-y +=3D rbtree.o
 obj-y +=3D lzo.o
+obj-y +=3D v4v.o
=20
 obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma un=
lzo,$(n).init.o)
=20
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8840202..9539d88 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm =3D 1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D=
 1u<<2,
-           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5 };
+           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5,
+           INIT_v4v =3D 1u<<6 };
     int init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -219,6 +220,7 @@ struct domain *domain_create(
     spin_lock_init(&d->hypercall_deadlock_mutex);
     INIT_PAGE_LIST_HEAD(&d->page_list);
     INIT_PAGE_LIST_HEAD(&d->xenpage_list);
+    rwlock_init(&d->v4v_lock);
=20
     spin_lock_init(&d->node_affinity_lock);
     d->node_affinity =3D NODE_MASK_ALL;
@@ -274,6 +276,10 @@ struct domain *domain_create(
             goto fail;
         init_status |=3D INIT_gnttab;
=20
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+
         poolid =3D 0;
=20
         d->mem_event =3D xzalloc(struct mem_event_per_domain);
@@ -313,6 +319,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -466,6 +474,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying =3D DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..e589fda
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1755 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#include <xen/config.h>
+#include <xen/mm.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/v4v.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <asm/paging.h>
+#include <asm/p2m.h>
+#include <xen/keyhandler.h>
+#include <xen/v4v_utils.h>
+
+#ifdef V4V_DEBUG
+#define MY_FILE "v4v.c"
+#define v4v_dprintk(format, args...)                    \
+    do {                                                \
+        printk("%s:%d " format,                         \
+               MY_FILE, __LINE__, ## args );            \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+
+
+DEFINE_XEN_GUEST_HANDLE (uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info (struct domain *d,
+                                                 struct v4v_ring_id *id)=
;
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr (struct domain *=
d,
+                                                         struct v4v_addr=
 *a,
+                                                         domid_t p);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK (v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void
+v4v_hexdump (void *_p, int len)
+{
+    uint8_t *buf =3D (uint8_t *) _p;
+    int i, j;
+
+    for (i =3D 0; i < len; i +=3D 16)
+    {
+        printk (KERN_ERR "%p:", &buf[i]);
+        for (j =3D 0; j < 16; ++j)
+        {
+            int k =3D i + j;
+            if (k < len)
+                printk (" %02x", buf[k]);
+            else
+                printk ("   ");
+        }
+        printk (" ");
+
+        for (j =3D 0; j < 16; ++j)
+        {
+            int k =3D i + j;
+            if (k < len)
+                printk ("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k]=
 : '.');
+            else
+                printk (" ");
+        }
+        printk ("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain (struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+    send_guest_vcpu_virq (d->vcpu[0], VIRQ_V4V);
+}
+
+static void
+v4v_signal_domid (domid_t id)
+{
+    struct domain *d =3D get_domain_by_id (id);
+    if (!d)
+        return;
+    v4v_signal_domain (d);
+    put_domain (d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+/* called must have L3 */
+static void
+v4v_ring_unmap (struct v4v_ring_info *ring_info)
+{
+    int i;
+    for (i =3D 0; i < ring_info->npage; ++i)
+    {
+        if (!ring_info->mfn_mapping[i])
+            continue;
+        v4v_dprintk("");
+        v4v_dprintk("unmapping page %p from %p\n",
+                (void*) mfn_x (ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+
+        unmap_domain_page (ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] =3D NULL;
+    }
+}
+
+/* called must have L3 */
+static uint8_t *
+v4v_ring_map_page (struct v4v_ring_info *ring_info, int i)
+{
+    if (i >=3D ring_info->npage)
+        return NULL;
+    if (ring_info->mfn_mapping[i])
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] =3D map_domain_page (mfn_x (ring_info->mfn=
s[i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+            (void *) mfn_x (ring_info->mfns[i]),
+            ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_from_guest_ring (void *_dst, struct v4v_ring_info *ring_info,
+                            uint32_t offset, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst =3D _dst;
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        src =3D v4v_ring_map_page (ring_info, page);
+
+        if (!src)
+        {
+            return -EFAULT;
+        }
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                dst, src, offset,
+                (int) (PAGE_SIZE - offset));
+        memcpy (dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        dst +=3D PAGE_SIZE - offset;
+        offset =3D 0;
+    }
+
+    src =3D v4v_ring_map_page (ring_info, page);
+    if (!src)
+    {
+        return -EFAULT;
+    }
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy (dst, src + offset, len);
+
+    return 0;
+}
+
+
+/* called must have L3 */
+static int
+v4v_update_tx_ptr (struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst =3D v4v_ring_map_page (ring_info, 0);
+    volatile uint32_t *p =3D (uint32_t *)(dst + offsetof (v4v_ring_t, tx=
_ptr));
+
+    if (!dst)
+        return -EFAULT;
+    *p =3D tx_ptr;
+    return 0;
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_to_guest_ring (struct v4v_ring_info *ring_info, uint32_t offs=
et,
+        void *_src, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+    uint8_t *src =3D _src;
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        dst =3D v4v_ring_map_page (ring_info, page);
+
+        if (!dst)
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+#ifdef V4V_DEBUG
+        v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+                dst, offset, src,
+                (int) (PAGE_SIZE - offset));
+        v4v_hexdump (src, PAGE_SIZE - offset);
+        v4v_hexdump (dst + offset, PAGE_SIZE - offset);
+#endif
+        memcpy (dst + offset, src, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D (PAGE_SIZE - offset);
+        src +=3D (PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page (ring_info, page);
+
+    if (!dst)
+    {
+        v4v_dprintk("attempted to map page %d of %d\n", page, ring_info-=
>npage);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+            dst, offset, src, len);
+    v4v_hexdump (src, len);
+    v4v_hexdump (dst + offset, len);
+#endif
+    memcpy (dst + offset, src, len);
+
+    return 0;
+}
+
+/*called must have L3*/
+static int
+v4v_memcpy_to_guest_ring_from_guest(struct v4v_ring_info *ring_info,
+                                    uint32_t offset,
+                                    XEN_GUEST_HANDLE (uint8_t) src_hnd,
+                                    uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page (ring_info, page);
+
+        if ( !dst )
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+        v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                    dst, offset, (void *) src_hnd.p,
+                    (int) (PAGE_SIZE - offset));
+        if ( copy_from_guest ((dst + offset), src_hnd, PAGE_SIZE - offse=
t) )
+        {
+            v4v_dprintk("copy_from_guest failed\n");
+            return -EFAULT;
+        }
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        guest_handle_add_offset (src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page (ring_info, page);
+    if (!dst)
+    {
+        v4v_dprintk("v4v_ring_map failed\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                dst, offset, (void *) src_hnd.p, len);
+    if ( copy_from_guest ((dst + offset), src_hnd, len) )
+    {
+        v4v_dprintk("copy_from_guest failed\n");
+        return -EFAULT;
+    }
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr (struct domain *d, struct v4v_ring_info *ring_inf=
o,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage =3D=3D 0 )
+        return -1;
+
+    ringp =3D map_domain_page (mfn_x (ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *) mfn_x (ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    *rx_ptr =3D *(volatile uint32_t *) &ringp->rx_ptr;
+
+    unmap_domain_page (mfn_x (ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space (struct domain * d, struct v4v_ring_info * rin=
g_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr =3D ring_info->tx_ptr;
+    ring.len =3D ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=3D%d rx_ptr=3D%d\n",
+                (int) ring.tx_ptr, (int) ring.rx_ptr);
+    if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret =3D ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret +=3D ring.len;
+
+    ret -=3D sizeof (struct v4v_ring_message_header);
+    ret -=3D V4V_ROUNDUP (1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+/*caller must have L3*/
+static size_t
+v4v_ringbuf_insert (struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    struct v4v_ring_id *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE (void) buf_hnd_void, uint32_t len)
+{
+    XEN_GUEST_HANDLE (uint8_t) buf_hnd =3D
+        guest_handle_cast (buf_hnd_void, uint8_t);
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    int32_t happy_ret =3D len;
+    int32_t ret =3D 0;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header)) >=
=3D
+            ring_info->len )
+    {
+        v4v_dprintk("EMSGSIZE\n");
+        return -EMSGSIZE;
+    }
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring (&ring, ring_info,
+                                                0, sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header=
)) >=3D sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.protocol =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_=
ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        sp =3D ring.len - ring.tx_ptr;
+
+        if ( len > sp )
+        {
+            if ((ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                            ring.tx_ptr + sizeof (v4v_ring_t),
+                            buf_hnd, sp)))
+                break;
+
+            ring.tx_ptr =3D 0;
+            len -=3D sp;
+            guest_handle_add_offset (buf_hnd, sp);
+        }
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        buf_hnd, len)) )
+            break;
+
+        ring.tx_ptr +=3D V4V_ROUNDUP (len);
+
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        mb ();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+
+}
+
+static ssize_t
+v4v_iov_count (XEN_GUEST_HANDLE (v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest (&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret +=3D iov.iov_len;
+        guest_handle_add_offset (iovs, 1);
+    }
+
+    return ret;
+}
+
+/*caller must have L3*/
+static ssize_t
+v4v_ringbuf_insertv (struct domain *d,
+                     struct v4v_ring_info *ring_info,
+                     struct v4v_ring_id *src_id, uint32_t proto,
+                     XEN_GUEST_HANDLE (v4v_iov_t) iovs, uint32_t niov,
+                     uint32_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    int32_t happy_ret;
+    int32_t ret =3D 0;
+
+    happy_ret =3D len;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header) ) =
>=3D
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring (&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header=
) ) >=3D sp)
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.protocol =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_=
ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE (uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest (&iov, iovs, 1) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            buf_hnd.p =3D (uint8_t *) iov.iov_base; //FIXME
+            len =3D iov.iov_len;
+
+            if ( unlikely (!guest_handle_okay (buf_hnd, len)) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            sp =3D ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                if ( (ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_=
info,
+                                ring.tx_ptr +
+                                sizeof (v4v_ring_t),
+                                buf_hnd, sp)) )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset (buf_hnd, sp);
+            }
+
+            if ( (ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_info=
,
+                            ring.tx_ptr +
+                            sizeof (v4v_ring_t),
+                            buf_hnd, len)) )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if (ring.tx_ptr =3D=3D ring_info->len)
+                ring.tx_ptr =3D 0;
+
+            guest_handle_add_offset (iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr =3D V4V_ROUNDUP (ring.tx_ptr);
+
+        if ( ring.tx_ptr >=3D ring_info->len )
+            ring.tx_ptr -=3D ring_info->len;
+
+        mb ();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent (struct v4v_pending_ent *ent)
+{
+    hlist_del (&ent->node);
+    xfree (ent);
+}
+
+/*caller must have L3 */
+static void
+v4v_pending_remove_all (struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent (pending_ent);
+}
+
+/*Caller must hold L1 */
+static void
+v4v_pending_notify (struct domain *caller_d, struct hlist_head *to_notif=
y)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, to_notify, node)
+    {
+        hlist_del (&pending_ent->node);
+        v4v_signal_domid (pending_ent->id);
+        xfree (pending_ent);
+    }
+
+}
+
+/*caller must have R(L2) */
+static void
+v4v_pending_find (struct v4v_ring_info *ring_info, uint32_t payload_spac=
e,
+        struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    spin_lock (&ring_info->lock);
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, nod=
e)
+    {
+        if (payload_space >=3D ent->len)
+        {
+            hlist_del (&ent->node);
+            hlist_add_head (&ent->node, to_notify);
+        }
+    }
+    spin_unlock (&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue (struct v4v_ring_info *ring_info, domid_t src_id, int =
len)
+{
+    struct v4v_pending_ent *ent =3D xmalloc (struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len =3D len;
+    ent->id =3D src_id;
+
+    hlist_add_head (&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue (struct v4v_ring_info *ring_info, domid_t src_id, in=
t len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry (ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id =3D=3D src_id )
+        {
+            if ( ent->len < len )
+                ent->len =3D len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue (ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel (struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, nod=
e)
+    {
+        if ( ent->id =3D=3D src_id)
+        {
+            hlist_del (&ent->node);
+            xfree (ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data (struct domain *src_d,
+                    XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest (&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=3D%d,ent.ring.port=3D=
%u\n",
+                (int) ent.ring.domain, (int) ent.ring.port);
+
+    ent.flags =3D 0;
+
+    dst_d =3D get_domain_by_id (ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock (&dst_d->v4v->lock);
+        ring_info =3D v4v_ring_find_info_by_addr (dst_d, &ent.ring,
+                                                src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |=3D V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =3D
+                ring_info->len - sizeof (struct v4v_ring_message_header)=
 -
+                V4V_ROUNDUP (1);
+            spin_lock (&ring_info->lock);
+
+            space_avail =3D v4v_ringbuf_payload_space (dst_d, ring_info)=
;
+
+            if ( space_avail >=3D ent.space_required )
+            {
+                v4v_pending_cancel (ring_info, src_d->domain_id);
+                ent.flags |=3D V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue (ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |=3D V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock (&ring_info->lock);
+
+            if ( space_avail =3D=3D ent.max_message_size )
+                ent.flags |=3D V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain (dst_d);
+
+    if ( copy_field_to_guest (data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas (struct domain *d, int nent,
+                     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd=
)
+{
+    int ret =3D 0;
+
+    read_lock (&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret =3D v4v_fill_ring_data (d, data_ent_hnd);
+        guest_handle_add_offset (data_ent_hnd, 1);
+    }
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns (struct domain *d, struct v4v_ring_info *ring_info,
+                    uint32_t npage, XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd=
)
+{
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret =3D 0;
+
+    if ((npage << PAGE_SHIFT) < ring_info->len)
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    mfns =3D xmalloc_array (mfn_t, npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping =3D xmalloc_array (uint8_t *, npage);
+    if ( !mfn_mapping )
+    {
+        xfree (mfns);
+        return -ENOMEM;
+    }
+
+    for (i =3D 0; i < npage; ++i)
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset (&pfn, pfn_hnd, i, 1) )
+        {
+            ret =3D -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn =3D mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn"=
 ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        page =3D mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_m=
fn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        mfns[i] =3D _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long) pfn, (unsigned long) mfn_x (mfns[=
i]));
+        mfn_mapping[i] =3D NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage =3D npage;
+        ring_info->mfns =3D mfns;
+        ring_info->mfn_mapping =3D mfn_mapping;
+    }
+    else
+    {
+        j =3D i;
+        for ( i =3D 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree (mfn_mapping);
+        xfree (mfns);
+        v4v_dprintk("");
+    }
+    return ret;
+}
+
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info (struct domain *d, struct v4v_ring_id *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    hash =3D v4v_hash_fn (id);
+
+    v4v_dprintk("ring_find_info: d->v4v=3D%p, d->v4v->ring_hash[%d]=3D%p=
 id=3D%p\n",
+                d->v4v, (int) hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=3D%d id.addr.domain=3D%d i=
d.addr.partner=3D%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[hash], nod=
e)
+    {
+        if ( !memcmp (id, &ring_info->id, sizeof (*id)) )
+        {
+            v4v_dprintk("ring_find_info: ring_info=3D%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr (struct domain *d, struct v4v_addr *a, domid_=
t p)
+{
+    struct v4v_ring_id id;
+    struct v4v_ring_info *ret;
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port =3D a->port;
+    id.addr.domain =3D d->domain_id;
+    id.partner =3D p;
+
+    ret =3D v4v_ring_find_info (d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner =3D V4V_DOMID_NONE;
+
+    return v4v_ring_find_info (d, &id);
+}
+
+/*caller must hold W(L2) */
+static void v4v_ring_remove_mfns (struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    if ( ring_info->mfns )
+    {
+        for ( i=3D0; i < ring_info->npage; ++i )
+            if (mfn_x(ring_info->mfns[i]) !=3D 0)
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i]))=
);
+        xfree (ring_info->mfns);
+    }
+    ring_info->mfns =3D NULL;
+}
+
+/*caller must hold W(L2) */
+static void
+v4v_ring_remove_info (struct v4v_ring_info *ring_info)
+{
+    v4v_pending_remove_all (ring_info);
+
+    hlist_del (&ring_info->node);
+    v4v_ring_remove_mfns(ring_info);
+    xfree (ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hn=
d)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    read_lock (&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+
+        write_lock (&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info (d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info (ring_info);
+
+        write_unlock (&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk( "ENOENT\n" );
+            ret =3D -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd,
+              uint32_t npage, XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert =3D 0;
+    int ret =3D 0;
+
+    if ( (long) ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUND=
UP (1) +
+                     V4V_ROUNDUP (1))) || (V4V_ROUNDUP (ring.len) !=3D r=
ing.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+        if ( copy_field_to_guest (ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >=3D ring.len)
+                || (V4V_ROUNDUP (ring.tx_ptr) !=3D ring.tx_ptr) )
+        {
+            ring.tx_ptr =3D ring.rx_ptr;
+        }
+        copy_field_to_guest (ring_hnd, &ring, tx_ptr);
+
+        read_lock (&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info (d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock (&d->v4v->lock);
+            ring_info =3D xmalloc (struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret =3D -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init (&ring_info->lock);
+            INIT_HLIST_HEAD (&ring_info->pending);
+            ring_info->mfns =3D NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed. If mfn list was already
+             * populated remove the MFN's from list and then add
+             * the new list.
+             */
+            printk(KERN_INFO "v4v: dom%d re-registering existing ring, c=
learing MFN list\n",
+                    current->domain->domain_id);
+            v4v_ring_remove_mfns(ring_info);
+        }
+
+        spin_lock (&ring_info->lock);
+        ring_info->id =3D ring.id;
+        ring_info->len =3D ring.len;
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        ring_info->ring =3D ring_hnd;
+        if ( ring_info->mfns )
+            xfree (ring_info->mfns);
+        ret =3D v4v_find_ring_mfns (d, ring_info, npage, pfn_hnd);
+        spin_unlock (&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock (&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash =3D v4v_hash_fn (&ring.id);
+            write_lock (&d->v4v->lock);
+            hlist_add_head (&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock (&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+/*Caller must hold v4v_lock and hash_lock*/
+static void
+v4v_notify_ring (struct domain *d, struct v4v_ring_info *ring_info,
+        struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    spin_lock (&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space (d, ring_info);
+    spin_unlock (&ring_info->lock);
+
+    v4v_pending_find (ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify (struct domain *d,
+            XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD (to_notify);
+    int i;
+    int ret =3D 0;
+
+    read_lock (&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock (&d->v4v->lock);
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe (ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring (d, ring_info, &to_notify);
+        }
+    }
+    read_unlock (&d->v4v->lock);
+
+    if ( !hlist_empty (&to_notify) )
+    {
+        v4v_pending_notify (d, &to_notify);
+    }
+
+    do
+    {
+        if ( !guest_handle_is_null (ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest (&ring_data, ring_data_hnd, magic=
) )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic !=3D V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), E=
INVAL\n",
+                        ring_data.magic, V4V_RING_MAGIC);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if (copy_from_guest (&ring_data, ring_data_hnd, 1))
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd=
;
+                ring_data_ent_hnd =3D
+                    guest_handle_for_field(ring_data_hnd, v4v_ring_data_=
ent_t, ring[0]);
+                ret =3D v4v_fill_ring_datas (d, ring_data.nent, ring_dat=
a_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+
+    return ret;
+}
+
+
+
+/*Hypercall to do the send*/
+static size_t
+v4v_send (struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE (void) buf, size_t len)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id (dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk("!dst_d->v4v, ECONNREFUSED\n");
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domai=
n);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk("!ring_info\n");
+        }
+        else
+        {
+            spin_lock (&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insert (dst_d, ring_info, &src_id, proto, bu=
f, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("ret =3D=3D EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, le=
n))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if (ret >=3D 0)
+            {
+                v4v_signal_domain (dst_d);
+            }
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*Hypercall to do the send*/
+static size_t
+v4v_sendv (struct domain *src_d, v4v_addr_t * src_addr,
+           v4v_addr_t * dst_addr, uint32_t proto,
+           XEN_GUEST_HANDLE (v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if (!src_d->v4v)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id (dst_addr->domain);
+    if (!dst_d)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret =3D -ECONNREFUSED;
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domai=
n);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            uint32_t len =3D v4v_iov_count (iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret =3D len;
+                break;
+            }
+
+            spin_lock (&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insertv (dst_d, ring_info, &src_id, proto, i=
ovs,
+                        niov, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, le=
n))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if ( ret >=3D 0 )
+            {
+                v4v_signal_domain (dst_d);
+            }
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op (int cmd, XEN_GUEST_HANDLE (void) arg1,
+           XEN_GUEST_HANDLE (void) arg2,
+           XEN_GUEST_HANDLE (void) arg3, uint32_t arg4, uint32_t arg5)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%p,%d,%d)\n", cmd,
+                (void *) arg1.p, (void *) arg2.p, (void *) arg3.p,
+                (int) arg4, (int) arg5);
+
+    domain_lock (d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast (arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd =3D
+                    guest_handle_cast (arg2, v4v_pfn_t);
+                uint32_t npage =3D arg4;
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                if ( unlikely (!guest_handle_okay (pfn_hnd, npage)) )
+                    goto out;
+                rc =3D v4v_ring_add (d, ring_hnd, npage, pfn_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast (arg1, v4v_ring_t);
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                rc =3D v4v_ring_remove (d, ring_hnd);
+                break;
+            }
+        case V4VOP_send:
+            {
+                v4v_addr_t src, dst;
+                uint32_t len =3D arg4;
+                uint32_t protocol =3D arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =3D
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =3D
+                    guest_handle_cast (arg2, v4v_addr_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                rc =3D v4v_send (d, &src, &dst, protocol, arg3, len);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                v4v_addr_t src, dst;
+                uint32_t niov =3D arg4;
+                uint32_t protocol =3D arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =3D
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =3D
+                    guest_handle_cast (arg2, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_iov_t) iovs =3D
+                    guest_handle_cast (arg3, v4v_iov_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (iovs, niov)) )
+                    goto out;
+
+                rc =3D v4v_sendv (d, &src, &dst, protocol, iovs, niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd =3D
+                    guest_handle_cast (arg1, v4v_ring_data_t);
+                rc =3D v4v_notify (d, ring_data_hnd);
+                break;
+            }
+        default:
+            rc =3D -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock (d);
+    v4v_dprintk("<-do_v4v_op()=3D%d\n", (int) rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy (struct domain *d)
+{
+    int i;
+
+    BUG_ON (!d->is_dying);
+    write_lock (&v4v_lock);
+
+    v4v_dprintk("d->v=3D%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe (ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info (ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock (&v4v_lock);
+}
+
+int
+v4v_init (struct domain *d)
+{
+    struct v4v_domain *v4v;
+    int i;
+
+    v4v =3D xmalloc (struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rwlock_init (&v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        INIT_HLIST_HEAD (&v4v->ring_hash[i]);
+    }
+
+    write_lock (&v4v_lock);
+    d->v4v =3D v4v;
+    write_unlock (&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring (struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk (KERN_ERR "  ring: domid=3D%d port=3D0x%08x partner=3D%d npag=
e=3D%d\n",
+            (int) d->domain_id, (int) ring_info->id.addr.port,
+            (int) ring_info->id.partner, (int) ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &rx_ptr) )
+    {
+        printk (KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk (KERN_ERR "   tx_ptr=3D%d rx_ptr=3D%d len=3D%d\n",
+            (int) ring_info->tx_ptr, (int) rx_ptr, (int) ring_info->len)=
;
+}
+
+static void
+dump_domain_rings (struct domain *d)
+{
+    int i;
+
+    printk (KERN_ERR " domain %d:\n", (int) d->domain_id);
+
+    read_lock (&d->v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[i], no=
de)
+            dump_domain_ring (d, ring_info);
+    }
+    read_unlock (&d->v4v->lock);
+
+    printk (KERN_ERR "\n");
+    v4v_signal_domain (d);
+}
+
+static void
+dump_rings (unsigned char key)
+{
+    struct domain *d;
+
+    printk (KERN_ERR "\n\nV4V ring dump:\n");
+    read_lock (&v4v_lock);
+
+    rcu_read_lock (&domlist_read_lock);
+
+    for_each_domain (d) dump_domain_rings (d);
+
+    rcu_read_unlock (&domlist_read_lock);
+
+    read_unlock (&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D {
+    .diagnostic =3D 1,
+    .u.fn =3D dump_rings,
+    .desc =3D "dump v4v ring states and intterupt"
+};
+
+static int __init
+setup_dump_rings (void)
+{
+    register_keyhandler ('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall (setup_dump_rings);
+
+
+/*
+ * 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/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..197770e
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,240 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_PROTO_DGRAM		0x3c2c1db8
+#define V4V_PROTO_STREAM 	0x70f6a8e5
+
+#ifdef __i386__
+# define V4V_RING_MAGIC         0xdf6977f231abd910ULL
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302dULL
+#else
+# define V4V_RING_MAGIC         0xdf6977f231abd910
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302d
+#endif
+#define V4V_DOMID_INVALID       (0x7FFFU)
+#define V4V_DOMID_NONE          V4V_DOMID_INVALID
+#define V4V_DOMID_ANY           V4V_DOMID_INVALID
+#define V4V_PORT_NONE           0
+
+/*
+ * struct v4v_iov
+ * {
+ *      64 bits: iov_base
+ *      64 bits: iov_len
+ * }
+ */
+
+/*
+ * struct v4v_addr
+ * {
+ *      32 bits: port
+ *      16 bits: domid
+ * }
+ */
+
+/*
+ * v4v_ring_id
+ * {
+ *      struct v4v_addr: addr
+ *      16 bits: partner
+ * }
+ */
+
+/*
+ * v4v_ring
+ * {
+ *      64 bits: magic
+ *      v4v_rind_id: id
+ *      32 bits: len
+ *      32 bits: rx_ptr
+ *      32 bits: tx_ptr
+ *      64 bits: padding
+ *      ... : ring
+ * }
+ *
+ * id:
+ * xen only looks at this during register/unregister
+ * and will fill in id.addr.domain
+ *
+ * rx_ptr: rx pointer, modified by domain
+ * tx_ptr: tx pointer, modified by xen
+ */
+
+#ifdef __i386__
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92aULL
+#else
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92a
+#endif
+
+#define V4V_RING_DATA_F_EMPTY       1U << 0 /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      1U << 1 /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     1U << 2 /* Pending interrupt exists =
- do not
+                                               rely on this field - for
+                                               profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  1U << 3 /* Sufficient space to queue
+                                               space_required bytes exis=
ts */
+
+/*
+ * v4v_ring_data_ent
+ * {
+ *      v4v_addr: ring
+ *      16 bits: flags
+ *      16 bits: padding
+ *      32 bits: space_required
+ *      32 bits: max_message_size
+ * }
+ */
+
+/*
+ * v4v_ring_data
+ * {
+ *      64 bits: magic (V4V_RING_DATA_MAGIC)
+ *      32 bits: nent
+ *      32 bits: padding
+ *      256 bits: reserved
+ *      ... : v4v_ring_data_ent
+ * }
+ */
+
+
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+/*
+ * Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+
+/*
+ * v4v_stream_header
+ * {
+ *      32 bits: flags
+ *      32 bits: conid
+ * }
+ */
+
+/*
+ * v4v_ring_message_header
+ * {
+ *      32 bits: len
+ *      v4v_addr: source
+ *      32 bits: protocol
+ *      ... : data
+ * }
+ */
+
+/*
+ * HYPERCALLS
+ */
+
+#define V4VOP_register_ring 	1
+/*
+ * Registers a ring with Xen, if a ring with the same v4v_ring_id exists=
,
+ * this ring takes its place, registration will not change tx_ptr
+ * unless it is invalid
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           v4v_ring, XEN_GUEST_HANDLE(v4v_pfn),
+ *           NULL, npage, 0)
+ */
+
+
+#define V4VOP_unregister_ring 	2
+/*
+ * Unregister a ring.
+ *
+ * v4v_hypercall(V4VOP_send, v4v_ring, NULL, NULL, 0, 0)
+ */
+
+#define V4VOP_send 		3
+/*
+ * Sends len bytes of buf to dst, giving src as the source address (xen =
will
+ * ignore src->domain and put your domain in the actually message), xen
+ * first looks for a ring with id.addr=3D=3Ddst and id.partner=3D=3Dsend=
ing_domain
+ * if that fails it looks for id.addr=3D=3Ddst and id.partner=3D=3DDOMID=
_ANY.
+ * protocol is the 32 bit protocol number used from the message
+ * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * v4v_hypercall(V4VOP_send,
+ *               v4v_addr src,
+ *               v4v_addr dst,
+ *               void* buf,
+ *               uint32_t len,
+ *               uint32_t protocol)
+ */
+
+
+#define V4VOP_notify 		4
+/* Asks xen for information about other rings in the system
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is the=
re
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * v4v_hypercall(V4VOP_notify,
+ *               XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *               NULL, NULL, nent, 0)
+ */
+
+
+#define V4VOP_sendv		5
+/*
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * v4v_hypercall(V4VOP_sendv,
+ *               v4v_addr src,
+ *               v4v_addr dst,
+ *               v4v_iov iov,
+ *               uint32_t niov,
+ *               uint32_t protocol)
+ */
+
+#endif /* __XEN_PUBLIC_V4V_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/public/xen.h b/xen/include/public/xen.h
index 033cbba..dce0338 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -99,7 +99,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient *=
/
+#define __HYPERVISOR_v4v_op               39
=20
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..457e3f2 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,6 +23,7 @@
 #include <public/sysctl.h>
 #include <public/vcpu.h>
 #include <public/mem_event.h>
+#include <xen/v4v.h>
=20
 #ifdef CONFIG_COMPAT
 #include <compat/vcpu.h>
@@ -350,6 +351,10 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    rwlock_t v4v_lock;
+    struct v4v_domain *v4v;
 };
=20
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..641a6a8
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,187 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/spinlock.h>
+#include <xen/smp.h>
+#include <xen/shared.h>
+#include <xen/list.h>
+#include <public/v4v.h>
+
+#define V4V_HTABLE_SIZE 32
+
+#define V4V_PACKED __attribute__ ((packed))
+
+/*
+ * Structures
+ */
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint64_t iov_len;
+} V4V_PACKED v4v_iov_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+} V4V_PACKED v4v_addr_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+
+typedef struct v4v_ring_id
+{
+    struct v4v_addr addr;
+    domid_t partner;
+} V4V_PACKED v4v_ring_id_t;
+
+typedef uint64_t v4v_pfn_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
+
+typedef struct v4v_ring
+{
+    uint64_t magic;
+    struct v4v_ring_id id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint64_t reserved[4];
+    uint8_t ring[0];
+} V4V_PACKED v4v_ring_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+
+typedef struct v4v_ring_data_ent
+{
+    struct v4v_addr ring;
+    uint16_t flags;
+    uint16_t pad0;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} V4V_PACKED v4v_ring_data_ent_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t padding;
+    uint64_t reserved[4];
+    v4v_ring_data_ent_t ring[0];
+} V4V_PACKED v4v_ring_data_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+} V4V_PACKED;
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    struct v4v_addr source;
+    uint32_t protocol;
+    uint8_t data[0];
+} V4V_PACKED;
+
+/*
+ * Helper functions
+ */
+
+
+static inline uint16_t
+v4v_hash_fn (struct v4v_ring_id *id)
+{
+  uint16_t ret;
+  ret =3D (uint16_t) (id->addr.port >> 16);
+  ret ^=3D (uint16_t) id->addr.port;
+  ret ^=3D id->addr.domain;
+  ret ^=3D id->partner;
+
+  ret &=3D (V4V_HTABLE_SIZE-1);
+
+  return ret;
+}
+
+struct v4v_pending_ent
+{
+  struct hlist_node node;
+  domid_t id;
+  uint32_t len;
+} V4V_PACKED;
+
+
+struct v4v_ring_info
+{
+  /* next node in the hash, protected by L2  */
+  struct hlist_node node;
+  /* this ring's id, protected by L2 */
+  struct v4v_ring_id id;
+  /* L3 */
+  spinlock_t lock;
+  /* cached length of the ring (from ring->len), protected by L3 */
+  uint32_t len;
+  uint32_t npage;
+  /* cached tx pointer location, protected by L3 */
+  uint32_t tx_ptr;
+  /* guest ring, protected by L3 */
+  XEN_GUEST_HANDLE(v4v_ring_t) ring;
+  /* mapped ring pages protected by L3*/
+  uint8_t **mfn_mapping;
+  /* list of mfns of guest ring */
+  mfn_t *mfns;
+  /* list of struct v4v_pending_ent for this ring, L3 */
+  struct hlist_head pending;
+} V4V_PACKED;
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+struct v4v_domain
+{
+  /* L2 */
+  rwlock_t lock;
+  /* protected by L2 */
+  struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+} V4V_PACKED;
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                XEN_GUEST_HANDLE (void) arg3,
+                uint32_t arg4,
+                uint32_t arg5);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16: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 1SkHjp-0000NM-6O; Thu, 28 Jun 2012 16:38:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@citrix.com>) id 1SkHjm-0000N8-3Z
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 16:38:35 +0000
Received: from [85.158.138.51:53681] by server-6.bemta-3.messagelabs.com id
	22/D9-11602-9888CEF4; Thu, 28 Jun 2012 16:38:33 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340901512!21143495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17436 invoked from network); 28 Jun 2012 16:38:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:38:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:38:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:38:31 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@citrix.com>)	id 1SkHXk-0001WN-J2;
	Thu, 28 Jun 2012 16:26:08 +0000
Received: by spongy (Postfix, from userid 2023)	id 97AE9340F57; Thu, 28 Jun
	2012 17:26:28 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 28 Jun 2012 17:26:25 +0100
Message-ID: <1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/arch/x86/hvm/hvm.c             |    9 +-
 xen/arch/x86/x86_32/entry.S        |    2 +
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   11 +-
 xen/common/v4v.c                   | 1755 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  240 +++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    5 +
 xen/include/xen/v4v.h              |  187 ++++
 11 files changed, 2211 insertions(+), 5 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0004-xen-Add-V4V-implementation.patch"
Content-Disposition: attachment;
	filename="0004-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0d495d..6f2d70e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3124,7 +3124,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hy=
percalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #else /* defined(__x86_64__) */
@@ -3209,7 +3210,8 @@ static hvm_hypercall_t *hvm_hypercall64_table[NR_hy=
percalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3226,7 +3228,8 @@ static hvm_hypercall_t *hvm_hypercall32_table[NR_hy=
percalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #endif /* defined(__x86_64__) */
diff --git a/xen/arch/x86/x86_32/entry.S b/xen/arch/x86/x86_32/entry.S
index 2982679..b3e0da4 100644
--- a/xen/arch/x86/x86_32/entry.S
+++ b/xen/arch/x86/x86_32/entry.S
@@ -700,6 +700,7 @@ ENTRY(hypercall_table)
         .long do_domctl
         .long do_kexec_op
         .long do_tmem_op
+        .long do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/4)
         .long do_ni_hypercall
         .endr
@@ -748,6 +749,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec_op          */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index f49ff2d..28615f9 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 6 /* do_v4v_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 3836260..918fa59 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -699,6 +699,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -747,6 +748,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 6 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9eba8bc..fe3c72c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y +=3D tmem_xen.o
 obj-y +=3D radix-tree.o
 obj-y +=3D rbtree.o
 obj-y +=3D lzo.o
+obj-y +=3D v4v.o
=20
 obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma un=
lzo,$(n).init.o)
=20
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8840202..9539d88 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm =3D 1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D=
 1u<<2,
-           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5 };
+           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5,
+           INIT_v4v =3D 1u<<6 };
     int init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -219,6 +220,7 @@ struct domain *domain_create(
     spin_lock_init(&d->hypercall_deadlock_mutex);
     INIT_PAGE_LIST_HEAD(&d->page_list);
     INIT_PAGE_LIST_HEAD(&d->xenpage_list);
+    rwlock_init(&d->v4v_lock);
=20
     spin_lock_init(&d->node_affinity_lock);
     d->node_affinity =3D NODE_MASK_ALL;
@@ -274,6 +276,10 @@ struct domain *domain_create(
             goto fail;
         init_status |=3D INIT_gnttab;
=20
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+
         poolid =3D 0;
=20
         d->mem_event =3D xzalloc(struct mem_event_per_domain);
@@ -313,6 +319,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -466,6 +474,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying =3D DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..e589fda
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1755 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#include <xen/config.h>
+#include <xen/mm.h>
+#include <xen/compat.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/domain.h>
+#include <xen/v4v.h>
+#include <xen/event.h>
+#include <xen/guest_access.h>
+#include <asm/paging.h>
+#include <asm/p2m.h>
+#include <xen/keyhandler.h>
+#include <xen/v4v_utils.h>
+
+#ifdef V4V_DEBUG
+#define MY_FILE "v4v.c"
+#define v4v_dprintk(format, args...)                    \
+    do {                                                \
+        printk("%s:%d " format,                         \
+               MY_FILE, __LINE__, ## args );            \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+
+
+DEFINE_XEN_GUEST_HANDLE (uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info (struct domain *d,
+                                                 struct v4v_ring_id *id)=
;
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr (struct domain *=
d,
+                                                         struct v4v_addr=
 *a,
+                                                         domid_t p);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK (v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void
+v4v_hexdump (void *_p, int len)
+{
+    uint8_t *buf =3D (uint8_t *) _p;
+    int i, j;
+
+    for (i =3D 0; i < len; i +=3D 16)
+    {
+        printk (KERN_ERR "%p:", &buf[i]);
+        for (j =3D 0; j < 16; ++j)
+        {
+            int k =3D i + j;
+            if (k < len)
+                printk (" %02x", buf[k]);
+            else
+                printk ("   ");
+        }
+        printk (" ");
+
+        for (j =3D 0; j < 16; ++j)
+        {
+            int k =3D i + j;
+            if (k < len)
+                printk ("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k]=
 : '.');
+            else
+                printk (" ");
+        }
+        printk ("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain (struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+    send_guest_vcpu_virq (d->vcpu[0], VIRQ_V4V);
+}
+
+static void
+v4v_signal_domid (domid_t id)
+{
+    struct domain *d =3D get_domain_by_id (id);
+    if (!d)
+        return;
+    v4v_signal_domain (d);
+    put_domain (d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+/* called must have L3 */
+static void
+v4v_ring_unmap (struct v4v_ring_info *ring_info)
+{
+    int i;
+    for (i =3D 0; i < ring_info->npage; ++i)
+    {
+        if (!ring_info->mfn_mapping[i])
+            continue;
+        v4v_dprintk("");
+        v4v_dprintk("unmapping page %p from %p\n",
+                (void*) mfn_x (ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+
+        unmap_domain_page (ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] =3D NULL;
+    }
+}
+
+/* called must have L3 */
+static uint8_t *
+v4v_ring_map_page (struct v4v_ring_info *ring_info, int i)
+{
+    if (i >=3D ring_info->npage)
+        return NULL;
+    if (ring_info->mfn_mapping[i])
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] =3D map_domain_page (mfn_x (ring_info->mfn=
s[i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+            (void *) mfn_x (ring_info->mfns[i]),
+            ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_from_guest_ring (void *_dst, struct v4v_ring_info *ring_info,
+                            uint32_t offset, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst =3D _dst;
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        src =3D v4v_ring_map_page (ring_info, page);
+
+        if (!src)
+        {
+            return -EFAULT;
+        }
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                dst, src, offset,
+                (int) (PAGE_SIZE - offset));
+        memcpy (dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        dst +=3D PAGE_SIZE - offset;
+        offset =3D 0;
+    }
+
+    src =3D v4v_ring_map_page (ring_info, page);
+    if (!src)
+    {
+        return -EFAULT;
+    }
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy (dst, src + offset, len);
+
+    return 0;
+}
+
+
+/* called must have L3 */
+static int
+v4v_update_tx_ptr (struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst =3D v4v_ring_map_page (ring_info, 0);
+    volatile uint32_t *p =3D (uint32_t *)(dst + offsetof (v4v_ring_t, tx=
_ptr));
+
+    if (!dst)
+        return -EFAULT;
+    *p =3D tx_ptr;
+    return 0;
+}
+
+/* called must have L3 */
+static int
+v4v_memcpy_to_guest_ring (struct v4v_ring_info *ring_info, uint32_t offs=
et,
+        void *_src, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+    uint8_t *src =3D _src;
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ((offset + len) > PAGE_SIZE)
+    {
+        dst =3D v4v_ring_map_page (ring_info, page);
+
+        if (!dst)
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+#ifdef V4V_DEBUG
+        v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+                dst, offset, src,
+                (int) (PAGE_SIZE - offset));
+        v4v_hexdump (src, PAGE_SIZE - offset);
+        v4v_hexdump (dst + offset, PAGE_SIZE - offset);
+#endif
+        memcpy (dst + offset, src, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D (PAGE_SIZE - offset);
+        src +=3D (PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page (ring_info, page);
+
+    if (!dst)
+    {
+        v4v_dprintk("attempted to map page %d of %d\n", page, ring_info-=
>npage);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    v4v_dprintk("memcpy(%p+%d,%p,%d)\n",
+            dst, offset, src, len);
+    v4v_hexdump (src, len);
+    v4v_hexdump (dst + offset, len);
+#endif
+    memcpy (dst + offset, src, len);
+
+    return 0;
+}
+
+/*called must have L3*/
+static int
+v4v_memcpy_to_guest_ring_from_guest(struct v4v_ring_info *ring_info,
+                                    uint32_t offset,
+                                    XEN_GUEST_HANDLE (uint8_t) src_hnd,
+                                    uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page (ring_info, page);
+
+        if ( !dst )
+        {
+            v4v_dprintk("!dst\n");
+            return -EFAULT;
+        }
+
+        v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                    dst, offset, (void *) src_hnd.p,
+                    (int) (PAGE_SIZE - offset));
+        if ( copy_from_guest ((dst + offset), src_hnd, PAGE_SIZE - offse=
t) )
+        {
+            v4v_dprintk("copy_from_guest failed\n");
+            return -EFAULT;
+        }
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        guest_handle_add_offset (src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page (ring_info, page);
+    if (!dst)
+    {
+        v4v_dprintk("v4v_ring_map failed\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("copy_from_guest(%p+%d,%p,%d)\n",
+                dst, offset, (void *) src_hnd.p, len);
+    if ( copy_from_guest ((dst + offset), src_hnd, len) )
+    {
+        v4v_dprintk("copy_from_guest failed\n");
+        return -EFAULT;
+    }
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr (struct domain *d, struct v4v_ring_info *ring_inf=
o,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage =3D=3D 0 )
+        return -1;
+
+    ringp =3D map_domain_page (mfn_x (ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *) mfn_x (ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    *rx_ptr =3D *(volatile uint32_t *) &ringp->rx_ptr;
+
+    unmap_domain_page (mfn_x (ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space (struct domain * d, struct v4v_ring_info * rin=
g_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr =3D ring_info->tx_ptr;
+    ring.len =3D ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=3D%d rx_ptr=3D%d\n",
+                (int) ring.tx_ptr, (int) ring.rx_ptr);
+    if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret =3D ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret +=3D ring.len;
+
+    ret -=3D sizeof (struct v4v_ring_message_header);
+    ret -=3D V4V_ROUNDUP (1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+/*caller must have L3*/
+static size_t
+v4v_ringbuf_insert (struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    struct v4v_ring_id *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE (void) buf_hnd_void, uint32_t len)
+{
+    XEN_GUEST_HANDLE (uint8_t) buf_hnd =3D
+        guest_handle_cast (buf_hnd_void, uint8_t);
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    int32_t happy_ret =3D len;
+    int32_t ret =3D 0;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header)) >=
=3D
+            ring_info->len )
+    {
+        v4v_dprintk("EMSGSIZE\n");
+        return -EMSGSIZE;
+    }
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring (&ring, ring_info,
+                                                0, sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header=
)) >=3D sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.protocol =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_=
ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        sp =3D ring.len - ring.tx_ptr;
+
+        if ( len > sp )
+        {
+            if ((ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                            ring.tx_ptr + sizeof (v4v_ring_t),
+                            buf_hnd, sp)))
+                break;
+
+            ring.tx_ptr =3D 0;
+            len -=3D sp;
+            guest_handle_add_offset (buf_hnd, sp);
+        }
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        buf_hnd, len)) )
+            break;
+
+        ring.tx_ptr +=3D V4V_ROUNDUP (len);
+
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        mb ();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+
+}
+
+static ssize_t
+v4v_iov_count (XEN_GUEST_HANDLE (v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest (&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret +=3D iov.iov_len;
+        guest_handle_add_offset (iovs, 1);
+    }
+
+    return ret;
+}
+
+/*caller must have L3*/
+static ssize_t
+v4v_ringbuf_insertv (struct domain *d,
+                     struct v4v_ring_info *ring_info,
+                     struct v4v_ring_id *src_id, uint32_t proto,
+                     XEN_GUEST_HANDLE (v4v_iov_t) iovs, uint32_t niov,
+                     uint32_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    int32_t happy_ret;
+    int32_t ret =3D 0;
+
+    happy_ret =3D len;
+
+    if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header) ) =
>=3D
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring (&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if (sp < 0)
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP (len) + sizeof (struct v4v_ring_message_header=
) ) >=3D sp)
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.protocol =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring (ring_info,
+                                              ring.tx_ptr + sizeof (v4v_=
ring_t),
+                                              &mh, sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE (uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest (&iov, iovs, 1) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            buf_hnd.p =3D (uint8_t *) iov.iov_base; //FIXME
+            len =3D iov.iov_len;
+
+            if ( unlikely (!guest_handle_okay (buf_hnd, len)) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            sp =3D ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                if ( (ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_=
info,
+                                ring.tx_ptr +
+                                sizeof (v4v_ring_t),
+                                buf_hnd, sp)) )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset (buf_hnd, sp);
+            }
+
+            if ( (ret =3D v4v_memcpy_to_guest_ring_from_guest (ring_info=
,
+                            ring.tx_ptr +
+                            sizeof (v4v_ring_t),
+                            buf_hnd, len)) )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if (ring.tx_ptr =3D=3D ring_info->len)
+                ring.tx_ptr =3D 0;
+
+            guest_handle_add_offset (iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr =3D V4V_ROUNDUP (ring.tx_ptr);
+
+        if ( ring.tx_ptr >=3D ring_info->len )
+            ring.tx_ptr -=3D ring_info->len;
+
+        mb ();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap (ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent (struct v4v_pending_ent *ent)
+{
+    hlist_del (&ent->node);
+    xfree (ent);
+}
+
+/*caller must have L3 */
+static void
+v4v_pending_remove_all (struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent (pending_ent);
+}
+
+/*Caller must hold L1 */
+static void
+v4v_pending_notify (struct domain *caller_d, struct hlist_head *to_notif=
y)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    hlist_for_each_entry_safe (pending_ent, node, next, to_notify, node)
+    {
+        hlist_del (&pending_ent->node);
+        v4v_signal_domid (pending_ent->id);
+        xfree (pending_ent);
+    }
+
+}
+
+/*caller must have R(L2) */
+static void
+v4v_pending_find (struct v4v_ring_info *ring_info, uint32_t payload_spac=
e,
+        struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    spin_lock (&ring_info->lock);
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, nod=
e)
+    {
+        if (payload_space >=3D ent->len)
+        {
+            hlist_del (&ent->node);
+            hlist_add_head (&ent->node, to_notify);
+        }
+    }
+    spin_unlock (&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue (struct v4v_ring_info *ring_info, domid_t src_id, int =
len)
+{
+    struct v4v_pending_ent *ent =3D xmalloc (struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len =3D len;
+    ent->id =3D src_id;
+
+    hlist_add_head (&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue (struct v4v_ring_info *ring_info, domid_t src_id, in=
t len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry (ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id =3D=3D src_id )
+        {
+            if ( ent->len < len )
+                ent->len =3D len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue (ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel (struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe (ent, node, next, &ring_info->pending, nod=
e)
+    {
+        if ( ent->id =3D=3D src_id)
+        {
+            hlist_del (&ent->node);
+            xfree (ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data (struct domain *src_d,
+                    XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest (&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=3D%d,ent.ring.port=3D=
%u\n",
+                (int) ent.ring.domain, (int) ent.ring.port);
+
+    ent.flags =3D 0;
+
+    dst_d =3D get_domain_by_id (ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock (&dst_d->v4v->lock);
+        ring_info =3D v4v_ring_find_info_by_addr (dst_d, &ent.ring,
+                                                src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |=3D V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =3D
+                ring_info->len - sizeof (struct v4v_ring_message_header)=
 -
+                V4V_ROUNDUP (1);
+            spin_lock (&ring_info->lock);
+
+            space_avail =3D v4v_ringbuf_payload_space (dst_d, ring_info)=
;
+
+            if ( space_avail >=3D ent.space_required )
+            {
+                v4v_pending_cancel (ring_info, src_d->domain_id);
+                ent.flags |=3D V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue (ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |=3D V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock (&ring_info->lock);
+
+            if ( space_avail =3D=3D ent.max_message_size )
+                ent.flags |=3D V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain (dst_d);
+
+    if ( copy_field_to_guest (data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas (struct domain *d, int nent,
+                     XEN_GUEST_HANDLE (v4v_ring_data_ent_t) data_ent_hnd=
)
+{
+    int ret =3D 0;
+
+    read_lock (&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret =3D v4v_fill_ring_data (d, data_ent_hnd);
+        guest_handle_add_offset (data_ent_hnd, 1);
+    }
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns (struct domain *d, struct v4v_ring_info *ring_info,
+                    uint32_t npage, XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd=
)
+{
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret =3D 0;
+
+    if ((npage << PAGE_SHIFT) < ring_info->len)
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    mfns =3D xmalloc_array (mfn_t, npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping =3D xmalloc_array (uint8_t *, npage);
+    if ( !mfn_mapping )
+    {
+        xfree (mfns);
+        return -ENOMEM;
+    }
+
+    for (i =3D 0; i < npage; ++i)
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset (&pfn, pfn_hnd, i, 1) )
+        {
+            ret =3D -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn =3D mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn"=
 ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        page =3D mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_m=
fn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        mfns[i] =3D _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long) pfn, (unsigned long) mfn_x (mfns[=
i]));
+        mfn_mapping[i] =3D NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage =3D npage;
+        ring_info->mfns =3D mfns;
+        ring_info->mfn_mapping =3D mfn_mapping;
+    }
+    else
+    {
+        j =3D i;
+        for ( i =3D 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree (mfn_mapping);
+        xfree (mfns);
+        v4v_dprintk("");
+    }
+    return ret;
+}
+
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info (struct domain *d, struct v4v_ring_id *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    hash =3D v4v_hash_fn (id);
+
+    v4v_dprintk("ring_find_info: d->v4v=3D%p, d->v4v->ring_hash[%d]=3D%p=
 id=3D%p\n",
+                d->v4v, (int) hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=3D%d id.addr.domain=3D%d i=
d.addr.partner=3D%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[hash], nod=
e)
+    {
+        if ( !memcmp (id, &ring_info->id, sizeof (*id)) )
+        {
+            v4v_dprintk("ring_find_info: ring_info=3D%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+/* caller must hold R(L2) */
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr (struct domain *d, struct v4v_addr *a, domid_=
t p)
+{
+    struct v4v_ring_id id;
+    struct v4v_ring_info *ret;
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port =3D a->port;
+    id.addr.domain =3D d->domain_id;
+    id.partner =3D p;
+
+    ret =3D v4v_ring_find_info (d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner =3D V4V_DOMID_NONE;
+
+    return v4v_ring_find_info (d, &id);
+}
+
+/*caller must hold W(L2) */
+static void v4v_ring_remove_mfns (struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    if ( ring_info->mfns )
+    {
+        for ( i=3D0; i < ring_info->npage; ++i )
+            if (mfn_x(ring_info->mfns[i]) !=3D 0)
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i]))=
);
+        xfree (ring_info->mfns);
+    }
+    ring_info->mfns =3D NULL;
+}
+
+/*caller must hold W(L2) */
+static void
+v4v_ring_remove_info (struct v4v_ring_info *ring_info)
+{
+    v4v_pending_remove_all (ring_info);
+
+    hlist_del (&ring_info->node);
+    v4v_ring_remove_mfns(ring_info);
+    xfree (ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hn=
d)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    read_lock (&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+
+        write_lock (&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info (d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info (ring_info);
+
+        write_unlock (&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk( "ENOENT\n" );
+            ret =3D -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add (struct domain *d, XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd,
+              uint32_t npage, XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert =3D 0;
+    int ret =3D 0;
+
+    if ( (long) ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest (&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUND=
UP (1) +
+                     V4V_ROUNDUP (1))) || (V4V_ROUNDUP (ring.len) !=3D r=
ing.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+        if ( copy_field_to_guest (ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >=3D ring.len)
+                || (V4V_ROUNDUP (ring.tx_ptr) !=3D ring.tx_ptr) )
+        {
+            ring.tx_ptr =3D ring.rx_ptr;
+        }
+        copy_field_to_guest (ring_hnd, &ring, tx_ptr);
+
+        read_lock (&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info (d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock (&d->v4v->lock);
+            ring_info =3D xmalloc (struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret =3D -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init (&ring_info->lock);
+            INIT_HLIST_HEAD (&ring_info->pending);
+            ring_info->mfns =3D NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed. If mfn list was already
+             * populated remove the MFN's from list and then add
+             * the new list.
+             */
+            printk(KERN_INFO "v4v: dom%d re-registering existing ring, c=
learing MFN list\n",
+                    current->domain->domain_id);
+            v4v_ring_remove_mfns(ring_info);
+        }
+
+        spin_lock (&ring_info->lock);
+        ring_info->id =3D ring.id;
+        ring_info->len =3D ring.len;
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        ring_info->ring =3D ring_hnd;
+        if ( ring_info->mfns )
+            xfree (ring_info->mfns);
+        ret =3D v4v_find_ring_mfns (d, ring_info, npage, pfn_hnd);
+        spin_unlock (&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock (&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash =3D v4v_hash_fn (&ring.id);
+            write_lock (&d->v4v->lock);
+            hlist_add_head (&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock (&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+/*Caller must hold v4v_lock and hash_lock*/
+static void
+v4v_notify_ring (struct domain *d, struct v4v_ring_info *ring_info,
+        struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    spin_lock (&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space (d, ring_info);
+    spin_unlock (&ring_info->lock);
+
+    v4v_pending_find (ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify (struct domain *d,
+            XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD (to_notify);
+    int i;
+    int ret =3D 0;
+
+    read_lock (&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock (&d->v4v->lock);
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe (ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring (d, ring_info, &to_notify);
+        }
+    }
+    read_unlock (&d->v4v->lock);
+
+    if ( !hlist_empty (&to_notify) )
+    {
+        v4v_pending_notify (d, &to_notify);
+    }
+
+    do
+    {
+        if ( !guest_handle_is_null (ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest (&ring_data, ring_data_hnd, magic=
) )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic !=3D V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), E=
INVAL\n",
+                        ring_data.magic, V4V_RING_MAGIC);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if (copy_from_guest (&ring_data, ring_data_hnd, 1))
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_ent_t) ring_data_ent_hnd=
;
+                ring_data_ent_hnd =3D
+                    guest_handle_for_field(ring_data_hnd, v4v_ring_data_=
ent_t, ring[0]);
+                ret =3D v4v_fill_ring_datas (d, ring_data.nent, ring_dat=
a_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock (&v4v_lock);
+
+    return ret;
+}
+
+
+
+/*Hypercall to do the send*/
+static size_t
+v4v_send (struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE (void) buf, size_t len)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id (dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk("!dst_d->v4v, ECONNREFUSED\n");
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domai=
n);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk("!ring_info\n");
+        }
+        else
+        {
+            spin_lock (&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insert (dst_d, ring_info, &src_id, proto, bu=
f, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("ret =3D=3D EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, le=
n))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if (ret >=3D 0)
+            {
+                v4v_signal_domain (dst_d);
+            }
+        }
+        read_unlock (&dst_d->v4v->lock);
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*Hypercall to do the send*/
+static size_t
+v4v_sendv (struct domain *src_d, v4v_addr_t * src_addr,
+           v4v_addr_t * dst_addr, uint32_t proto,
+           XEN_GUEST_HANDLE (v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    struct v4v_ring_id src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock (&v4v_lock);
+    if (!src_d->v4v)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id (dst_addr->domain);
+    if (!dst_d)
+    {
+        read_unlock (&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret =3D -ECONNREFUSED;
+            break;
+        }
+
+        read_lock (&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr (dst_d, dst_addr, src_addr->domai=
n);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            uint32_t len =3D v4v_iov_count (iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret =3D len;
+                break;
+            }
+
+            spin_lock (&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insertv (dst_d, ring_info, &src_id, proto, i=
ovs,
+                        niov, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if (v4v_pending_requeue (ring_info, src_d->domain_id, le=
n))
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock (&ring_info->lock);
+
+            if ( ret >=3D 0 )
+            {
+                v4v_signal_domain (dst_d);
+            }
+
+        }
+        read_unlock (&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain (dst_d);
+    read_unlock (&v4v_lock);
+    return ret;
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op (int cmd, XEN_GUEST_HANDLE (void) arg1,
+           XEN_GUEST_HANDLE (void) arg2,
+           XEN_GUEST_HANDLE (void) arg3, uint32_t arg4, uint32_t arg5)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%p,%d,%d)\n", cmd,
+                (void *) arg1.p, (void *) arg2.p, (void *) arg3.p,
+                (int) arg4, (int) arg5);
+
+    domain_lock (d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast (arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE (v4v_pfn_t) pfn_hnd =3D
+                    guest_handle_cast (arg2, v4v_pfn_t);
+                uint32_t npage =3D arg4;
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                if ( unlikely (!guest_handle_okay (pfn_hnd, npage)) )
+                    goto out;
+                rc =3D v4v_ring_add (d, ring_hnd, npage, pfn_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast (arg1, v4v_ring_t);
+                if ( unlikely (!guest_handle_okay (ring_hnd, 1)) )
+                    goto out;
+                rc =3D v4v_ring_remove (d, ring_hnd);
+                break;
+            }
+        case V4VOP_send:
+            {
+                v4v_addr_t src, dst;
+                uint32_t len =3D arg4;
+                uint32_t protocol =3D arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =3D
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =3D
+                    guest_handle_cast (arg2, v4v_addr_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                rc =3D v4v_send (d, &src, &dst, protocol, arg3, len);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                v4v_addr_t src, dst;
+                uint32_t niov =3D arg4;
+                uint32_t protocol =3D arg5;
+                XEN_GUEST_HANDLE (v4v_addr_t) src_hnd =3D
+                    guest_handle_cast (arg1, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_addr_t) dst_hnd =3D
+                    guest_handle_cast (arg2, v4v_addr_t);
+                XEN_GUEST_HANDLE (v4v_iov_t) iovs =3D
+                    guest_handle_cast (arg3, v4v_iov_t);
+
+                if ( unlikely (!guest_handle_okay (src_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&src, src_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (dst_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest (&dst, dst_hnd, 1) )
+                    goto out;
+
+                if ( unlikely (!guest_handle_okay (iovs, niov)) )
+                    goto out;
+
+                rc =3D v4v_sendv (d, &src, &dst, protocol, iovs, niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE (v4v_ring_data_t) ring_data_hnd =3D
+                    guest_handle_cast (arg1, v4v_ring_data_t);
+                rc =3D v4v_notify (d, ring_data_hnd);
+                break;
+            }
+        default:
+            rc =3D -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock (d);
+    v4v_dprintk("<-do_v4v_op()=3D%d\n", (int) rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy (struct domain *d)
+{
+    int i;
+
+    BUG_ON (!d->is_dying);
+    write_lock (&v4v_lock);
+
+    v4v_dprintk("d->v=3D%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe (ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info (ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock (&v4v_lock);
+}
+
+int
+v4v_init (struct domain *d)
+{
+    struct v4v_domain *v4v;
+    int i;
+
+    v4v =3D xmalloc (struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rwlock_init (&v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        INIT_HLIST_HEAD (&v4v->ring_hash[i]);
+    }
+
+    write_lock (&v4v_lock);
+    d->v4v =3D v4v;
+    write_unlock (&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring (struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk (KERN_ERR "  ring: domid=3D%d port=3D0x%08x partner=3D%d npag=
e=3D%d\n",
+            (int) d->domain_id, (int) ring_info->id.addr.port,
+            (int) ring_info->id.partner, (int) ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr (d, ring_info, &rx_ptr) )
+    {
+        printk (KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk (KERN_ERR "   tx_ptr=3D%d rx_ptr=3D%d len=3D%d\n",
+            (int) ring_info->tx_ptr, (int) rx_ptr, (int) ring_info->len)=
;
+}
+
+static void
+dump_domain_rings (struct domain *d)
+{
+    int i;
+
+    printk (KERN_ERR " domain %d:\n", (int) d->domain_id);
+
+    read_lock (&d->v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry (ring_info, node, &d->v4v->ring_hash[i], no=
de)
+            dump_domain_ring (d, ring_info);
+    }
+    read_unlock (&d->v4v->lock);
+
+    printk (KERN_ERR "\n");
+    v4v_signal_domain (d);
+}
+
+static void
+dump_rings (unsigned char key)
+{
+    struct domain *d;
+
+    printk (KERN_ERR "\n\nV4V ring dump:\n");
+    read_lock (&v4v_lock);
+
+    rcu_read_lock (&domlist_read_lock);
+
+    for_each_domain (d) dump_domain_rings (d);
+
+    rcu_read_unlock (&domlist_read_lock);
+
+    read_unlock (&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D {
+    .diagnostic =3D 1,
+    .u.fn =3D dump_rings,
+    .desc =3D "dump v4v ring states and intterupt"
+};
+
+static int __init
+setup_dump_rings (void)
+{
+    register_keyhandler ('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall (setup_dump_rings);
+
+
+/*
+ * 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/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..197770e
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,240 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_PROTO_DGRAM		0x3c2c1db8
+#define V4V_PROTO_STREAM 	0x70f6a8e5
+
+#ifdef __i386__
+# define V4V_RING_MAGIC         0xdf6977f231abd910ULL
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302dULL
+#else
+# define V4V_RING_MAGIC         0xdf6977f231abd910
+# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302d
+#endif
+#define V4V_DOMID_INVALID       (0x7FFFU)
+#define V4V_DOMID_NONE          V4V_DOMID_INVALID
+#define V4V_DOMID_ANY           V4V_DOMID_INVALID
+#define V4V_PORT_NONE           0
+
+/*
+ * struct v4v_iov
+ * {
+ *      64 bits: iov_base
+ *      64 bits: iov_len
+ * }
+ */
+
+/*
+ * struct v4v_addr
+ * {
+ *      32 bits: port
+ *      16 bits: domid
+ * }
+ */
+
+/*
+ * v4v_ring_id
+ * {
+ *      struct v4v_addr: addr
+ *      16 bits: partner
+ * }
+ */
+
+/*
+ * v4v_ring
+ * {
+ *      64 bits: magic
+ *      v4v_rind_id: id
+ *      32 bits: len
+ *      32 bits: rx_ptr
+ *      32 bits: tx_ptr
+ *      64 bits: padding
+ *      ... : ring
+ * }
+ *
+ * id:
+ * xen only looks at this during register/unregister
+ * and will fill in id.addr.domain
+ *
+ * rx_ptr: rx pointer, modified by domain
+ * tx_ptr: tx pointer, modified by xen
+ */
+
+#ifdef __i386__
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92aULL
+#else
+#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92a
+#endif
+
+#define V4V_RING_DATA_F_EMPTY       1U << 0 /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      1U << 1 /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     1U << 2 /* Pending interrupt exists =
- do not
+                                               rely on this field - for
+                                               profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  1U << 3 /* Sufficient space to queue
+                                               space_required bytes exis=
ts */
+
+/*
+ * v4v_ring_data_ent
+ * {
+ *      v4v_addr: ring
+ *      16 bits: flags
+ *      16 bits: padding
+ *      32 bits: space_required
+ *      32 bits: max_message_size
+ * }
+ */
+
+/*
+ * v4v_ring_data
+ * {
+ *      64 bits: magic (V4V_RING_DATA_MAGIC)
+ *      32 bits: nent
+ *      32 bits: padding
+ *      256 bits: reserved
+ *      ... : v4v_ring_data_ent
+ * }
+ */
+
+
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+/*
+ * Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+
+/*
+ * v4v_stream_header
+ * {
+ *      32 bits: flags
+ *      32 bits: conid
+ * }
+ */
+
+/*
+ * v4v_ring_message_header
+ * {
+ *      32 bits: len
+ *      v4v_addr: source
+ *      32 bits: protocol
+ *      ... : data
+ * }
+ */
+
+/*
+ * HYPERCALLS
+ */
+
+#define V4VOP_register_ring 	1
+/*
+ * Registers a ring with Xen, if a ring with the same v4v_ring_id exists=
,
+ * this ring takes its place, registration will not change tx_ptr
+ * unless it is invalid
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           v4v_ring, XEN_GUEST_HANDLE(v4v_pfn),
+ *           NULL, npage, 0)
+ */
+
+
+#define V4VOP_unregister_ring 	2
+/*
+ * Unregister a ring.
+ *
+ * v4v_hypercall(V4VOP_send, v4v_ring, NULL, NULL, 0, 0)
+ */
+
+#define V4VOP_send 		3
+/*
+ * Sends len bytes of buf to dst, giving src as the source address (xen =
will
+ * ignore src->domain and put your domain in the actually message), xen
+ * first looks for a ring with id.addr=3D=3Ddst and id.partner=3D=3Dsend=
ing_domain
+ * if that fails it looks for id.addr=3D=3Ddst and id.partner=3D=3DDOMID=
_ANY.
+ * protocol is the 32 bit protocol number used from the message
+ * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * v4v_hypercall(V4VOP_send,
+ *               v4v_addr src,
+ *               v4v_addr dst,
+ *               void* buf,
+ *               uint32_t len,
+ *               uint32_t protocol)
+ */
+
+
+#define V4VOP_notify 		4
+/* Asks xen for information about other rings in the system
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is the=
re
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * v4v_hypercall(V4VOP_notify,
+ *               XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *               NULL, NULL, nent, 0)
+ */
+
+
+#define V4VOP_sendv		5
+/*
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * v4v_hypercall(V4VOP_sendv,
+ *               v4v_addr src,
+ *               v4v_addr dst,
+ *               v4v_iov iov,
+ *               uint32_t niov,
+ *               uint32_t protocol)
+ */
+
+#endif /* __XEN_PUBLIC_V4V_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/public/xen.h b/xen/include/public/xen.h
index 033cbba..dce0338 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -99,7 +99,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient *=
/
+#define __HYPERVISOR_v4v_op               39
=20
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..457e3f2 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -23,6 +23,7 @@
 #include <public/sysctl.h>
 #include <public/vcpu.h>
 #include <public/mem_event.h>
+#include <xen/v4v.h>
=20
 #ifdef CONFIG_COMPAT
 #include <compat/vcpu.h>
@@ -350,6 +351,10 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    rwlock_t v4v_lock;
+    struct v4v_domain *v4v;
 };
=20
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..641a6a8
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,187 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * 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
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/spinlock.h>
+#include <xen/smp.h>
+#include <xen/shared.h>
+#include <xen/list.h>
+#include <public/v4v.h>
+
+#define V4V_HTABLE_SIZE 32
+
+#define V4V_PACKED __attribute__ ((packed))
+
+/*
+ * Structures
+ */
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint64_t iov_len;
+} V4V_PACKED v4v_iov_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+} V4V_PACKED v4v_addr_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+
+typedef struct v4v_ring_id
+{
+    struct v4v_addr addr;
+    domid_t partner;
+} V4V_PACKED v4v_ring_id_t;
+
+typedef uint64_t v4v_pfn_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
+
+typedef struct v4v_ring
+{
+    uint64_t magic;
+    struct v4v_ring_id id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint64_t reserved[4];
+    uint8_t ring[0];
+} V4V_PACKED v4v_ring_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+
+typedef struct v4v_ring_data_ent
+{
+    struct v4v_addr ring;
+    uint16_t flags;
+    uint16_t pad0;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} V4V_PACKED v4v_ring_data_ent_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t padding;
+    uint64_t reserved[4];
+    v4v_ring_data_ent_t ring[0];
+} V4V_PACKED v4v_ring_data_t;
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+} V4V_PACKED;
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    struct v4v_addr source;
+    uint32_t protocol;
+    uint8_t data[0];
+} V4V_PACKED;
+
+/*
+ * Helper functions
+ */
+
+
+static inline uint16_t
+v4v_hash_fn (struct v4v_ring_id *id)
+{
+  uint16_t ret;
+  ret =3D (uint16_t) (id->addr.port >> 16);
+  ret ^=3D (uint16_t) id->addr.port;
+  ret ^=3D id->addr.domain;
+  ret ^=3D id->partner;
+
+  ret &=3D (V4V_HTABLE_SIZE-1);
+
+  return ret;
+}
+
+struct v4v_pending_ent
+{
+  struct hlist_node node;
+  domid_t id;
+  uint32_t len;
+} V4V_PACKED;
+
+
+struct v4v_ring_info
+{
+  /* next node in the hash, protected by L2  */
+  struct hlist_node node;
+  /* this ring's id, protected by L2 */
+  struct v4v_ring_id id;
+  /* L3 */
+  spinlock_t lock;
+  /* cached length of the ring (from ring->len), protected by L3 */
+  uint32_t len;
+  uint32_t npage;
+  /* cached tx pointer location, protected by L3 */
+  uint32_t tx_ptr;
+  /* guest ring, protected by L3 */
+  XEN_GUEST_HANDLE(v4v_ring_t) ring;
+  /* mapped ring pages protected by L3*/
+  uint8_t **mfn_mapping;
+  /* list of mfns of guest ring */
+  mfn_t *mfns;
+  /* list of struct v4v_pending_ent for this ring, L3 */
+  struct hlist_head pending;
+} V4V_PACKED;
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+struct v4v_domain
+{
+  /* L2 */
+  rwlock_t lock;
+  /* protected by L2 */
+  struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+} V4V_PACKED;
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                XEN_GUEST_HANDLE (void) arg3,
+                uint32_t arg4,
+                uint32_t arg5);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Jun 28 16:52:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkHx5-0000jl-Pu; Thu, 28 Jun 2012 16:52: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 1SkHx4-0000jc-CP
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 16:52:18 +0000
Received: from [85.158.139.83:46126] by server-8.bemta-5.messagelabs.com id
	A8/1F-10278-1CB8CEF4; Thu, 28 Jun 2012 16:52:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340902336!25756023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16745 invoked from network); 28 Jun 2012 16:52:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:52:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:52:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:52:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkHx2-0001f3-3a; Thu, 28 Jun 2012 16:52:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkHx1-0004Pv-VX;
	Thu, 28 Jun 2012 17:52:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.35770.95918.935337@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 17:52:10 +0100
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BD99F@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD99F@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Zhang, Yang Z writes ("[Xen-devel] [PATCH v4 ]libxl: allow to set more than 31 vcpus"):
> In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
> In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

Thanks,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I also fixed one trivial style error (a missing space).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:52:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16:52:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkHx5-0000jl-Pu; Thu, 28 Jun 2012 16:52: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 1SkHx4-0000jc-CP
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 16:52:18 +0000
Received: from [85.158.139.83:46126] by server-8.bemta-5.messagelabs.com id
	A8/1F-10278-1CB8CEF4; Thu, 28 Jun 2012 16:52:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340902336!25756023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16745 invoked from network); 28 Jun 2012 16:52:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:52:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:52:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:52:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkHx2-0001f3-3a; Thu, 28 Jun 2012 16:52:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkHx1-0004Pv-VX;
	Thu, 28 Jun 2012 17:52:15 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.35770.95918.935337@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 17:52:10 +0100
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BD99F@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD99F@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 ]libxl: allow to set more than 31 vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Zhang, Yang Z writes ("[Xen-devel] [PATCH v4 ]libxl: allow to set more than 31 vcpus"):
> In current implementation, it uses integer to record current avail cpus and this only allows user to specify 31 vcpus. 
> In following patch, it uses cpumap instead integer which make more sense than before. Also there is no limit to the max vcpus.
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>

Thanks,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I also fixed one trivial style error (a missing space).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 16:52:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16:52: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 1SkHx9-0000k3-64; Thu, 28 Jun 2012 16:52: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 1SkHx7-0000js-24
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 16:52:21 +0000
Received: from [85.158.139.83:46363] by server-5.bemta-5.messagelabs.com id
	14/60-02722-4CB8CEF4; Thu, 28 Jun 2012 16:52:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340902336!25756023!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 28 Jun 2012 16:52:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:52:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:52:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkHx5-0001f7-FW; Thu, 28 Jun 2012 16:52:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkHx5-0004Q5-Eh;
	Thu, 28 Jun 2012 17:52:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.35779.442492.495234@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 17:52:19 +0100
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap
	with	specific 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

Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> Currently, libxl_cpumap_alloc()allocate the cpumap with size of number of physical cpus. In some place, we may want to allocate specific size of cpumap.
> This patch allow to pass a argument to specific the size that you want to allocate. If pass 0, it means the size is equal to number of physical cpus.
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.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 Thu Jun 28 16:52:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 16:52: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 1SkHx9-0000k3-64; Thu, 28 Jun 2012 16:52: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 1SkHx7-0000js-24
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 16:52:21 +0000
Received: from [85.158.139.83:46363] by server-5.bemta-5.messagelabs.com id
	14/60-02722-4CB8CEF4; Thu, 28 Jun 2012 16:52:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340902336!25756023!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16814 invoked from network); 28 Jun 2012 16:52:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 16:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13275986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 16:52:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 17:52:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkHx5-0001f7-FW; Thu, 28 Jun 2012 16:52:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkHx5-0004Q5-Eh;
	Thu, 28 Jun 2012 17:52:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.35779.442492.495234@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 17:52:19 +0100
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E1BD8EE@SHSMSX101.ccr.corp.intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap
	with	specific 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

Zhang, Yang Z writes ("[Xen-devel] [PATCH v3 ]libxl: allow to allocate cpumap with specific size"):
> Currently, libxl_cpumap_alloc()allocate the cpumap with size of number of physical cpus. In some place, we may want to allocate specific size of cpumap.
> This patch allow to pass a argument to specific the size that you want to allocate. If pass 0, it means the size is equal to number of physical cpus.
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.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 Thu Jun 28 17:03:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkI7U-00015k-DT; Thu, 28 Jun 2012 17:03:04 +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 1SkI7T-00015f-I0
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 17:03:03 +0000
Received: from [85.158.138.51:34862] by server-3.bemta-3.messagelabs.com id
	34/9C-26490-64E8CEF4; Thu, 28 Jun 2012 17:03:02 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340902981!28943643!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzU5MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24595 invoked from network); 28 Jun 2012 17:03:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 17:03:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 10:02:58 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="186181395"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 28 Jun 2012 10:02:58 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 10:02:58 -0700
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; Thu, 28 Jun 2012 10:02:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 01:02:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVTZw1l9vq4iTRyWE8p2SJy8j95cP7aOQ
Date: Thu, 28 Jun 2012 17:02:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335265284@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
	<4FEC7FB8020000780008C885@nat28.tlf.novell.com>
In-Reply-To: <4FEC7FB8020000780008C885@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.06.12 at 15:38, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 28.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> So I would like to push new vMCE as quickly as possible. What's the
>>>> timeline of vMCE developing that xen 4.2 could accept?
>>> 
>>> Weeks ago, really. See
>>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
>>> and follow-ups - we'd really only consider getting the save/restore
>>> interface into forward compatible shape as acceptable.
>>> 
>>>> I wonder if we could make major
>>>> components of vMCE done before xen 4.2 timeline, and leave the
>>>> surrounding features and the corner cases done later?
>>> 
>>> Unfortunately it's likely going to be even less. However, if split
>>> that way, chances are things could go into e.g. 4.2.1.
>>> 
>>> Jan
>> 
>> So let's look at current vMCE status first:
>> 1). functionally it work abnormally for guest (but tolerated by some
>> guest like linux/solaris); 2). before xen 4.1 it blocks migration
>> when migrate from big bank to small bank platform;
> 
> Before 4.2 you mean (in 4.1 we only have this as a backport in SLE11).

Yes.

> 
>> We may try some middle steps, minimal adjusting for xen 4.2 release
>> (to avoid futher compatible issue at xen 4.2.1, 4.3, ...):
>> 1). we don't handle vMCE function bugs, only make sure migration
>> works OK; 
> 
> That's the minimal goal.

You mean to fix current vMCE function bugs in xen 4.2? That would involve much work hence too late for xen 4.2. In fact the bugs currently tolerated by guest, so it's important but non-urgent.

What we need to do urgently is to adjust current vMCE interface a little so that
1). it would not block xen 4.2 live migration
2). it would not bring compatibility issues to new vMCE in the future
These 2 points are our minimal targets for xen 4.2

Thanks,
Jinsong

> 
>> 2). update vMCE interface to a middle clean status:
>>     * remove MCG_CTL (otherwise we have to add this useless MSR at
>> new vMCE); 
>>     * stick all 1's to MCi_CTL (avoid semantic difference);
>>     * for MCG_CAP, clear MCG_CTL_P, limit to 2 banks (otherwise
>> dirty code have to be added at new vMCE);
> 
> Whether that's acceptable would need to be seen when code
> is ready.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:03:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkI7U-00015k-DT; Thu, 28 Jun 2012 17:03:04 +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 1SkI7T-00015f-I0
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 17:03:03 +0000
Received: from [85.158.138.51:34862] by server-3.bemta-3.messagelabs.com id
	34/9C-26490-64E8CEF4; Thu, 28 Jun 2012 17:03:02 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340902981!28943643!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4NzU5MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24595 invoked from network); 28 Jun 2012 17:03:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-174.messagelabs.com with SMTP;
	28 Jun 2012 17:03:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 10:02:58 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="186181395"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 28 Jun 2012 10:02:58 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 10:02:58 -0700
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; Thu, 28 Jun 2012 10:02:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 01:02:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Auld, Will" <will.auld@intel.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [xen vMCE RFC V0.2] xen vMCE design
Thread-Index: AQHNVTZw1l9vq4iTRyWE8p2SJy8j95cP7aOQ
Date: Thu, 28 Jun 2012 17:02:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335265284@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
	<4FEC7FB8020000780008C885@nat28.tlf.novell.com>
In-Reply-To: <4FEC7FB8020000780008C885@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: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>, "Raj,
	Ashok" <ashok.raj@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Li,
	Susie" <susie.li@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.06.12 at 15:38, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 28.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> So I would like to push new vMCE as quickly as possible. What's the
>>>> timeline of vMCE developing that xen 4.2 could accept?
>>> 
>>> Weeks ago, really. See
>>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html
>>> and follow-ups - we'd really only consider getting the save/restore
>>> interface into forward compatible shape as acceptable.
>>> 
>>>> I wonder if we could make major
>>>> components of vMCE done before xen 4.2 timeline, and leave the
>>>> surrounding features and the corner cases done later?
>>> 
>>> Unfortunately it's likely going to be even less. However, if split
>>> that way, chances are things could go into e.g. 4.2.1.
>>> 
>>> Jan
>> 
>> So let's look at current vMCE status first:
>> 1). functionally it work abnormally for guest (but tolerated by some
>> guest like linux/solaris); 2). before xen 4.1 it blocks migration
>> when migrate from big bank to small bank platform;
> 
> Before 4.2 you mean (in 4.1 we only have this as a backport in SLE11).

Yes.

> 
>> We may try some middle steps, minimal adjusting for xen 4.2 release
>> (to avoid futher compatible issue at xen 4.2.1, 4.3, ...):
>> 1). we don't handle vMCE function bugs, only make sure migration
>> works OK; 
> 
> That's the minimal goal.

You mean to fix current vMCE function bugs in xen 4.2? That would involve much work hence too late for xen 4.2. In fact the bugs currently tolerated by guest, so it's important but non-urgent.

What we need to do urgently is to adjust current vMCE interface a little so that
1). it would not block xen 4.2 live migration
2). it would not bring compatibility issues to new vMCE in the future
These 2 points are our minimal targets for xen 4.2

Thanks,
Jinsong

> 
>> 2). update vMCE interface to a middle clean status:
>>     * remove MCG_CTL (otherwise we have to add this useless MSR at
>> new vMCE); 
>>     * stick all 1's to MCi_CTL (avoid semantic difference);
>>     * for MCG_CAP, clear MCG_CTL_P, limit to 2 banks (otherwise
>> dirty code have to be added at new vMCE);
> 
> Whether that's acceptable would need to be seen when code
> is ready.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:03:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:03: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 1SkI7r-000170-QE; Thu, 28 Jun 2012 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 <raistlin@linux.it>) id 1SkI7q-00016m-CS
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:03:26 +0000
Received: from [85.158.139.83:50614] by server-10.bemta-5.messagelabs.com id
	AA/A2-02190-D5E8CEF4; Thu, 28 Jun 2012 17:03:25 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340903004!29346672!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9127 invoked from network); 28 Jun 2012 17:03:24 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 17:03:24 -0000
Received: from [83.211.176.2] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79201468; Thu, 28 Jun 2012 19:03:24 +0200
Message-ID: <1340902989.17236.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 28 Jun 2012 19:03:09 +0200
In-Reply-To: <20120628124106.GL2058@reaktio.net>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace> <20120628124106.GL2058@reaktio.net>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0198859601833357598=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0198859601833357598==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Yvgw4pLroJiMjenPh7PQ"


--=-Yvgw4pLroJiMjenPh7PQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 15:41 +0300, Pasi K=C3=A4rkk=C3=A4inen wrote:
> > > Furthermore, we need consider the guest NUMA(I am working on it now) =
and live migration.
> > >=20
> > Great. Can you share, either here on or a separate thread some more
> > details about what you mean by both "guest NUMA" and "live migration" i=
n
> > this context?
> >=20
> > As George said, that would be 4.3 material, but I'm still very
> > interested. :-)
> >=20
>=20
> For the mailinglist archives..=20
>=20
:-)

> here are the Xen guest VM NUMA slides from XenSummit 2010:
> http://www.slideshare.net/xen_com_mgr/nakajima-numafinal
> http://www.slideshare.net/xen_com_mgr/dulloor-xensummit
>=20
Yes, I know this slides, and I've also looked at most of the code
they're referring to. That's all very interesting and it's well
worthwhile to keep that in mind for future steps in the field of NUMA
support. In particular, virtual topology awareness of the guest is
something really important to have, and I'll be happy to
discuss/work/contribute/help on it in the near future.

However, I'm still not sure I see how that ("guest NUMA") and live
migration should affect (either now or during 4.3 dev cycle) the initial
placement of a domain... That's what I was asking.


Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Yvgw4pLroJiMjenPh7PQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sjk0ACgkQk4XaBE3IOsThjQCfU0q9gnlA1aE/AijIjgk/jtJa
QuwAoIRM4V8WJ04SFNBvJ1QUZ0a+ggFa
=l27p
-----END PGP SIGNATURE-----

--=-Yvgw4pLroJiMjenPh7PQ--



--===============0198859601833357598==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0198859601833357598==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 17:03:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:03: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 1SkI7r-000170-QE; Thu, 28 Jun 2012 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 <raistlin@linux.it>) id 1SkI7q-00016m-CS
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:03:26 +0000
Received: from [85.158.139.83:50614] by server-10.bemta-5.messagelabs.com id
	AA/A2-02190-D5E8CEF4; Thu, 28 Jun 2012 17:03:25 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340903004!29346672!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9127 invoked from network); 28 Jun 2012 17:03:24 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-182.messagelabs.com with SMTP;
	28 Jun 2012 17:03:24 -0000
Received: from [83.211.176.2] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79201468; Thu, 28 Jun 2012 19:03:24 +0200
Message-ID: <1340902989.17236.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 28 Jun 2012 19:03:09 +0200
In-Reply-To: <20120628124106.GL2058@reaktio.net>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace> <20120628124106.GL2058@reaktio.net>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0198859601833357598=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0198859601833357598==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Yvgw4pLroJiMjenPh7PQ"


--=-Yvgw4pLroJiMjenPh7PQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-06-28 at 15:41 +0300, Pasi K=C3=A4rkk=C3=A4inen wrote:
> > > Furthermore, we need consider the guest NUMA(I am working on it now) =
and live migration.
> > >=20
> > Great. Can you share, either here on or a separate thread some more
> > details about what you mean by both "guest NUMA" and "live migration" i=
n
> > this context?
> >=20
> > As George said, that would be 4.3 material, but I'm still very
> > interested. :-)
> >=20
>=20
> For the mailinglist archives..=20
>=20
:-)

> here are the Xen guest VM NUMA slides from XenSummit 2010:
> http://www.slideshare.net/xen_com_mgr/nakajima-numafinal
> http://www.slideshare.net/xen_com_mgr/dulloor-xensummit
>=20
Yes, I know this slides, and I've also looked at most of the code
they're referring to. That's all very interesting and it's well
worthwhile to keep that in mind for future steps in the field of NUMA
support. In particular, virtual topology awareness of the guest is
something really important to have, and I'll be happy to
discuss/work/contribute/help on it in the near future.

However, I'm still not sure I see how that ("guest NUMA") and live
migration should affect (either now or during 4.3 dev cycle) the initial
placement of a domain... That's what I was asking.


Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Yvgw4pLroJiMjenPh7PQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/sjk0ACgkQk4XaBE3IOsThjQCfU0q9gnlA1aE/AijIjgk/jtJa
QuwAoIRM4V8WJ04SFNBvJ1QUZ0a+ggFa
=l27p
-----END PGP SIGNATURE-----

--=-Yvgw4pLroJiMjenPh7PQ--



--===============0198859601833357598==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0198859601833357598==--



From xen-devel-bounces@lists.xen.org Thu Jun 28 17:07:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17: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 1SkIBa-0001WR-OD; Thu, 28 Jun 2012 17:07:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SkIBZ-0001WE-4K
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:07:17 +0000
Received: from [85.158.138.51:60574] by server-12.bemta-3.messagelabs.com id
	D9/08-30206-44F8CEF4; Thu, 28 Jun 2012 17:07:16 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340903230!28944281!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1NTUwMg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1381 invoked from network); 28 Jun 2012 17:07:15 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:07:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340903235; x=1372439235;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=8CcyJEiSyTOX8+w/4KIwXyWvwcqWgSIsI2MrlEeeOrE=;
	b=eotOy3H5fK46hTG5d+mWNVTMfgyrq6ZIFBvV880IfIXzG7YK/nEpiho9
	/4jN/3vmzsEh3n/gVWZXeOExyQ4GrA==;
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="401862403"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 17:07:07 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5SH76UZ029213; Thu, 28 Jun 2012 17:07:06 GMT
MIME-Version: 1.0
X-Mercurial-Node: a84d4165d5f8cc05f4f8a2264baf5294ada314ff
Message-Id: <a84d4165d5f8cc05f4f8.1340903211@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 28 Jun 2012 17:06:51 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] xl: rename "list-vm" command to "vm-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

All of the other "list" verbs are of the form "$noun-list". For
example: "pci-list", "vcpu-list", "network-list", "block-list", etc.

Additionally, many people have well trained muscle memory from years
of typing "xm li". "xl li" was ambiguous due to "xl list-vm", thus
resulting in "command not implemented".

Finally, this command was missing from the xl man page.

Signed-off-by: Matt Wilson <msw@amazon.com>

Changes since v2:
 * Document the command as showing only guests

Changes since v1:
 * Add documentation

diff -r 32034d1914a6 -r a84d4165d5f8 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
@@ -617,6 +617,19 @@ different run state is appropriate.  Pin
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
+=item B<vm-list>
+
+Prints information about guests. This list excludes information about
+service or auxiliary domains such as dom0 and stubdoms.
+
+B<EXAMPLE>
+
+An example format for the list is as follows:
+
+UUID                                  ID    name
+59e1cf6c-6ab9-4879-90e7-adc8d1c63bf5  2    win
+50bc8f75-81d0-4d53-b2e6-95cb44e2682e  3    linux
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
diff -r 32034d1914a6 -r a84d4165d5f8 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
@@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
 int main_shutdown(int argc, char **argv);
 int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
-int main_list_vm(int argc, char **argv);
+int main_vm_list(int argc, char **argv);
 int main_create(int argc, char **argv);
 int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
diff -r 32034d1914a6 -r a84d4165d5f8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
@@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
     return 0;
 }
 
-int main_list_vm(int argc, char **argv)
+int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
diff -r 32034d1914a6 -r a84d4165d5f8 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
@@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
-    { "list-vm",
-      &main_list_vm, 0, 0,
-      "List the VMs,without DOM0",
+    { "vm-list",
+      &main_vm_list, 0, 0,
+      "List guest domains, excluding dom0, stubdoms, etc.",
       "",
     },
     { "info",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:07:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17: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 1SkIBa-0001WR-OD; Thu, 28 Jun 2012 17:07:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SkIBZ-0001WE-4K
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:07:17 +0000
Received: from [85.158.138.51:60574] by server-12.bemta-3.messagelabs.com id
	D9/08-30206-44F8CEF4; Thu, 28 Jun 2012 17:07:16 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340903230!28944281!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE1NTUwMg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1381 invoked from network); 28 Jun 2012 17:07:15 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:07:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340903235; x=1372439235;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=8CcyJEiSyTOX8+w/4KIwXyWvwcqWgSIsI2MrlEeeOrE=;
	b=eotOy3H5fK46hTG5d+mWNVTMfgyrq6ZIFBvV880IfIXzG7YK/nEpiho9
	/4jN/3vmzsEh3n/gVWZXeOExyQ4GrA==;
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="401862403"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 17:07:07 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5SH76UZ029213; Thu, 28 Jun 2012 17:07:06 GMT
MIME-Version: 1.0
X-Mercurial-Node: a84d4165d5f8cc05f4f8a2264baf5294ada314ff
Message-Id: <a84d4165d5f8cc05f4f8.1340903211@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 28 Jun 2012 17:06:51 +0000
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] xl: rename "list-vm" command to "vm-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

All of the other "list" verbs are of the form "$noun-list". For
example: "pci-list", "vcpu-list", "network-list", "block-list", etc.

Additionally, many people have well trained muscle memory from years
of typing "xm li". "xl li" was ambiguous due to "xl list-vm", thus
resulting in "command not implemented".

Finally, this command was missing from the xl man page.

Signed-off-by: Matt Wilson <msw@amazon.com>

Changes since v2:
 * Document the command as showing only guests

Changes since v1:
 * Add documentation

diff -r 32034d1914a6 -r a84d4165d5f8 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
@@ -617,6 +617,19 @@ different run state is appropriate.  Pin
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
+=item B<vm-list>
+
+Prints information about guests. This list excludes information about
+service or auxiliary domains such as dom0 and stubdoms.
+
+B<EXAMPLE>
+
+An example format for the list is as follows:
+
+UUID                                  ID    name
+59e1cf6c-6ab9-4879-90e7-adc8d1c63bf5  2    win
+50bc8f75-81d0-4d53-b2e6-95cb44e2682e  3    linux
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
diff -r 32034d1914a6 -r a84d4165d5f8 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl.h	Thu Jun 28 06:34:26 2012 +0000
@@ -54,7 +54,7 @@ int main_destroy(int argc, char **argv);
 int main_shutdown(int argc, char **argv);
 int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
-int main_list_vm(int argc, char **argv);
+int main_vm_list(int argc, char **argv);
 int main_create(int argc, char **argv);
 int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
diff -r 32034d1914a6 -r a84d4165d5f8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jun 28 06:34:26 2012 +0000
@@ -3623,11 +3623,11 @@ int main_list(int argc, char **argv)
     return 0;
 }
 
-int main_list_vm(int argc, char **argv)
+int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "list-vm", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
diff -r 32034d1914a6 -r a84d4165d5f8 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Jun 07 19:46:57 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Jun 28 06:34:26 2012 +0000
@@ -214,9 +214,9 @@ struct cmd_spec cmd_table[] = {
       "Set the number of active VCPUs allowed for the domain",
       "<Domain> <vCPUs>",
     },
-    { "list-vm",
-      &main_list_vm, 0, 0,
-      "List the VMs,without DOM0",
+    { "vm-list",
+      &main_vm_list, 0, 0,
+      "List guest domains, excluding dom0, stubdoms, etc.",
       "",
     },
     { "info",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:07:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkIC4-0001ak-5P; Thu, 28 Jun 2012 17:07:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SkIC3-0001aO-52
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:07:47 +0000
Received: from [85.158.138.51:14517] by server-8.bemta-3.messagelabs.com id
	2D/99-06157-26F8CEF4; Thu, 28 Jun 2012 17:07:46 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340903263!29957007!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk2MjM2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23595 invoked from network); 28 Jun 2012 17:07:45 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:07:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340903265; x=1372439265;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=gWZvDtqWjkuMyNEkQ69n2cwlssLjoYyH+E+K13hEZOY=;
	b=lz78LHo0cjPNaCHBX17VFiHOg6gf4FFJXiZVNXSfXvtclti4d83g5Etz
	TvRXJAj4iG6Bnl0DFgR9VHvlVrI8cA==;
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="988741712"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 17:07:28 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5SH7SPR019406
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 28 Jun 2012 17:07:28 GMT
Received: from US-SEA-R8XVZTX (10.224.80.38) by ex10-hub-31005.ant.amazon.com
	(10.185.176.12) with Microsoft SMTP Server id 14.2.247.3;
	Thu, 28 Jun 2012 10:07:11 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Thu, 28 Jun 2012
	10:07:10 -0700
Date: Thu, 28 Jun 2012 10:07:10 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120628170710.GC9080@US-SEA-R8XVZTX>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
	<20460.29531.933964.18000@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20460.29531.933964.18000@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, Jun 28, 2012 at 08:08:11AM -0700, Ian Jackson wrote:
> Matt Wilson writes ("[Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> > diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> > @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
> >  this, by ensuring certain VCPUs can only run on certain physical
> >  CPUs.
> >  
> > +=item B<vm-list>
> > +
> > +Prints information about all domains except for dom0.
> 
> Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
> etc. ?  IMO it should, and the docs should say so.

The command uses libxl_list_vm(), which does skip stubdoms by checking
libxl_is_stubdom()

> If it doesn't then that's IMO a bug but stubdoms are a bit buggy
> anyway so I don't regard fixing that as a blocker for this patch.  But
> I think we should introduce docs that are correct.
> 
> If you and Ian agree, perhaps you'd like to clarify that (and perhaps
> change the usage message too).

v3, coming up.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:07:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkIC4-0001ak-5P; Thu, 28 Jun 2012 17:07:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1SkIC3-0001aO-52
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:07:47 +0000
Received: from [85.158.138.51:14517] by server-8.bemta-3.messagelabs.com id
	2D/99-06157-26F8CEF4; Thu, 28 Jun 2012 17:07:46 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1340903263!29957007!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjk2MjM2\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23595 invoked from network); 28 Jun 2012 17:07:45 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:07:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1340903265; x=1372439265;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=gWZvDtqWjkuMyNEkQ69n2cwlssLjoYyH+E+K13hEZOY=;
	b=lz78LHo0cjPNaCHBX17VFiHOg6gf4FFJXiZVNXSfXvtclti4d83g5Etz
	TvRXJAj4iG6Bnl0DFgR9VHvlVrI8cA==;
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="988741712"
Received: from smtp-in-9001.sea19.amazon.com ([10.186.144.32])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2012 17:07:28 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q5SH7SPR019406
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 28 Jun 2012 17:07:28 GMT
Received: from US-SEA-R8XVZTX (10.224.80.38) by ex10-hub-31005.ant.amazon.com
	(10.185.176.12) with Microsoft SMTP Server id 14.2.247.3;
	Thu, 28 Jun 2012 10:07:11 -0700
Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Thu, 28 Jun 2012
	10:07:10 -0700
Date: Thu, 28 Jun 2012 10:07:10 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120628170710.GC9080@US-SEA-R8XVZTX>
References: <5b1ed71c74d675866513.1340870362@kaos-source-31003.sea31.amazon.com>
	<20460.29531.933964.18000@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20460.29531.933964.18000@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Cc: Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-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 Thu, Jun 28, 2012 at 08:08:11AM -0700, Ian Jackson wrote:
> Matt Wilson writes ("[Xen-devel] [PATCH] xl: rename "list-vm" command to "vm-list""):
> > diff -r 32034d1914a6 -r 5b1ed71c74d6 docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Thu Jun 07 19:46:57 2012 +0100
> > +++ b/docs/man/xl.pod.1	Thu Jun 28 06:34:26 2012 +0000
> > @@ -617,6 +617,18 @@ different run state is appropriate.  Pin
> >  this, by ensuring certain VCPUs can only run on certain physical
> >  CPUs.
> >  
> > +=item B<vm-list>
> > +
> > +Prints information about all domains except for dom0.
> 
> Doesn't it also exclude dm stubdoms, service domains (stub xenstored),
> etc. ?  IMO it should, and the docs should say so.

The command uses libxl_list_vm(), which does skip stubdoms by checking
libxl_is_stubdom()

> If it doesn't then that's IMO a bug but stubdoms are a bit buggy
> anyway so I don't regard fixing that as a blocker for this patch.  But
> I think we should introduce docs that are correct.
> 
> If you and Ian agree, perhaps you'd like to clarify that (and perhaps
> change the usage message too).

v3, coming up.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17: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 1SkILd-000244-8I; Thu, 28 Jun 2012 17:17: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 1SkILb-00023z-Gu
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:17:39 +0000
Received: from [85.158.138.51:55819] by server-11.bemta-3.messagelabs.com id
	F9/ED-02904-FA19CEF4; Thu, 28 Jun 2012 17:17:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340903855!30132636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15833 invoked from network); 28 Jun 2012 17:17:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13276374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:17:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:17:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkILW-0001oA-KE	for xen-devel@lists.xen.org;
	Thu, 28 Jun 2012 17:17:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkILW-0000hw-JI	for
	xen-devel@lists.xen.org; Thu, 28 Jun 2012 18:17:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.37294.349060.11806@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:17:34 +0100
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] libxl: Add a gc to libxl_cpumap_alloc,
	..._to_hex_string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 need to be slotted into my save/restore series, since a new case
of libxl__*alloc(0,...) was just added.

Thanks,
Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Add a gc to libxl_cpumap_alloc, ..._to_hex_string

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.  And this means that passing 0
to libxl__calloc is going to be wrong.

libxl_cpumap_alloc doesn't have a gc but passes 0 to libxl_calloc
Fix this by:
 - introducing an `out' label and an rc variable
 - replacing the returns with  rc = ERROR_BLAH; goto out;
 - adding uses of GC_INIT and GC_FREE.
 - changing NULL to NOGC in the call to libxl__calloc

Likewise fix libxl_cpumap_to_hex_string by:
 - adding a libxl_ctx* parameter and updating the one call site
 - adding uses of GC_INIT and GC_FREE.
 - changing NULL to NOGC in the call to libxl__zalloc

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl_dm.c    |    2 +-
 tools/libxl/libxl_utils.c |   28 ++++++++++++++++++++--------
 tools/libxl/libxl_utils.h |    2 +-
 3 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 2edc734..936e307 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -204,7 +204,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
         }
 
         nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
-        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
+        s = libxl_cpumap_to_hex_string(CTX, &b_info->avail_vcpus);
         flexarray_vappend(dm_args, "-vcpu_avail",
                               libxl__sprintf(gc, "%s", s), NULL);
         free(s);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d07a5a7..7073062 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -491,19 +491,29 @@ int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
 
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus)
 {
+    GC_INIT(ctx);
     int sz;
+    int rc;
 
-    if (max_cpus < 0)
-        return ERROR_INVAL;
+    if (max_cpus < 0) {
+        rc = ERROR_INVAL;
+        goto out;
+    }
     if (max_cpus == 0)
         max_cpus = libxl_get_max_cpus(ctx);
-    if (max_cpus == 0)
-        return ERROR_FAIL;
+    if (max_cpus == 0) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     sz = (max_cpus + 7) / 8;
-    cpumap->map = libxl__calloc(NULL, sizeof(*cpumap->map), sz);
+    cpumap->map = libxl__calloc(NOGC, sizeof(*cpumap->map), sz);
     cpumap->size = sz;
-    return 0;
+
+    rc = 0;
+ out:
+    GC_FREE;
+    return rc;
 }
 
 void libxl_cpumap_dispose(libxl_cpumap *map)
@@ -542,10 +552,11 @@ int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
 }
 
 /* NB. caller is responsible for freeing the memory */
-char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
+char *libxl_cpumap_to_hex_string(libxl_ctx *ctx, const libxl_cpumap *cpumap)
 {
+    GC_INIT(ctx);
     int i = cpumap->size;
-    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 3);
+    char *p = libxl__zalloc(NOGC, cpumap->size * 2 + 3);
     char *q = p;
     strncpy(p, "0x", 2);
     p += 2;
@@ -554,6 +565,7 @@ char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
         p += 2;
     }
     *p = '\0';
+    GC_FREE;
     return q;
 }
 
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index a762734..05a269a 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -68,7 +68,7 @@ int libxl_cpumap_test(const libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
-char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
+char *libxl_cpumap_to_hex_string(libxl_ctx *ctx, const libxl_cpumap *cpumap);
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
     memset(cpumap->map, -1, cpumap->size);
-- 
tg: (197c736..) t/xen/xl.nogc.add-gcs.cpumap (depends on: t/xen/xl.nogc.add-gcs)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17: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 1SkILd-000244-8I; Thu, 28 Jun 2012 17:17: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 1SkILb-00023z-Gu
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:17:39 +0000
Received: from [85.158.138.51:55819] by server-11.bemta-3.messagelabs.com id
	F9/ED-02904-FA19CEF4; Thu, 28 Jun 2012 17:17:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340903855!30132636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15833 invoked from network); 28 Jun 2012 17:17:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13276374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:17:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:17:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkILW-0001oA-KE	for xen-devel@lists.xen.org;
	Thu, 28 Jun 2012 17:17:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkILW-0000hw-JI	for
	xen-devel@lists.xen.org; Thu, 28 Jun 2012 18:17:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.37294.349060.11806@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:17:34 +0100
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] libxl: Add a gc to libxl_cpumap_alloc,
	..._to_hex_string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 need to be slotted into my save/restore series, since a new case
of libxl__*alloc(0,...) was just added.

Thanks,
Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Add a gc to libxl_cpumap_alloc, ..._to_hex_string

In the next patch we are going to change the definition of NOGC to
require a local variable libxl__gc *gc.  And this means that passing 0
to libxl__calloc is going to be wrong.

libxl_cpumap_alloc doesn't have a gc but passes 0 to libxl_calloc
Fix this by:
 - introducing an `out' label and an rc variable
 - replacing the returns with  rc = ERROR_BLAH; goto out;
 - adding uses of GC_INIT and GC_FREE.
 - changing NULL to NOGC in the call to libxl__calloc

Likewise fix libxl_cpumap_to_hex_string by:
 - adding a libxl_ctx* parameter and updating the one call site
 - adding uses of GC_INIT and GC_FREE.
 - changing NULL to NOGC in the call to libxl__zalloc

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl_dm.c    |    2 +-
 tools/libxl/libxl_utils.c |   28 ++++++++++++++++++++--------
 tools/libxl/libxl_utils.h |    2 +-
 3 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 2edc734..936e307 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -204,7 +204,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
         }
 
         nr_set_cpus = libxl_cpumap_count_set(&b_info->avail_vcpus);
-        s = libxl_cpumap_to_hex_string(&b_info->avail_vcpus);
+        s = libxl_cpumap_to_hex_string(CTX, &b_info->avail_vcpus);
         flexarray_vappend(dm_args, "-vcpu_avail",
                               libxl__sprintf(gc, "%s", s), NULL);
         free(s);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d07a5a7..7073062 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -491,19 +491,29 @@ int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
 
 int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus)
 {
+    GC_INIT(ctx);
     int sz;
+    int rc;
 
-    if (max_cpus < 0)
-        return ERROR_INVAL;
+    if (max_cpus < 0) {
+        rc = ERROR_INVAL;
+        goto out;
+    }
     if (max_cpus == 0)
         max_cpus = libxl_get_max_cpus(ctx);
-    if (max_cpus == 0)
-        return ERROR_FAIL;
+    if (max_cpus == 0) {
+        rc = ERROR_FAIL;
+        goto out;
+    }
 
     sz = (max_cpus + 7) / 8;
-    cpumap->map = libxl__calloc(NULL, sizeof(*cpumap->map), sz);
+    cpumap->map = libxl__calloc(NOGC, sizeof(*cpumap->map), sz);
     cpumap->size = sz;
-    return 0;
+
+    rc = 0;
+ out:
+    GC_FREE;
+    return rc;
 }
 
 void libxl_cpumap_dispose(libxl_cpumap *map)
@@ -542,10 +552,11 @@ int libxl_cpumap_count_set(const libxl_cpumap *cpumap)
 }
 
 /* NB. caller is responsible for freeing the memory */
-char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
+char *libxl_cpumap_to_hex_string(libxl_ctx *ctx, const libxl_cpumap *cpumap)
 {
+    GC_INIT(ctx);
     int i = cpumap->size;
-    char *p = libxl__zalloc(NULL, cpumap->size * 2 + 3);
+    char *p = libxl__zalloc(NOGC, cpumap->size * 2 + 3);
     char *q = p;
     strncpy(p, "0x", 2);
     p += 2;
@@ -554,6 +565,7 @@ char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap)
         p += 2;
     }
     *p = '\0';
+    GC_FREE;
     return q;
 }
 
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index a762734..05a269a 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -68,7 +68,7 @@ int libxl_cpumap_test(const libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 int libxl_cpumap_count_set(const libxl_cpumap *cpumap);
-char *libxl_cpumap_to_hex_string(const libxl_cpumap *cpumap);
+char *libxl_cpumap_to_hex_string(libxl_ctx *ctx, const libxl_cpumap *cpumap);
 static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
 {
     memset(cpumap->map, -1, cpumap->size);
-- 
tg: (197c736..) t/xen/xl.nogc.add-gcs.cpumap (depends on: t/xen/xl.nogc.add-gcs)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:45: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 1SkIln-00030Z-8L; Thu, 28 Jun 2012 17:44: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 1SkIll-00030U-Rk
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:44:41 +0000
Received: from [85.158.139.83:9132] by server-10.bemta-5.messagelabs.com id
	45/52-02190-9089CEF4; Thu, 28 Jun 2012 17:44:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340905480!25763095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6213 invoked from network); 28 Jun 2012 17:44:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:44:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13276929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:44:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:44:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkIlj-0001yv-RN; Thu, 28 Jun 2012 17:44:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkIlj-0000Iz-Nh;
	Thu, 28 Jun 2012 18:44:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.38919.637262.145163@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:44:39 +0100
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <royger@gmail.com>
In-Reply-To: <CAPLaKK6wfMzum+i6qV8DGyMCucsEa+AofW-AFpdJVkF9uy2Znw@mail.gmail.com>
References: <20460.37294.349060.11806@mariner.uk.xensource.com>
	<CAPLaKK6wfMzum+i6qV8DGyMCucsEa+AofW-AFpdJVkF9uy2Znw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Add a gc to libxl_cpumap_alloc,
 ..._to_hex_string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] libxl: Add a gc to libxl=
_cpumap_alloc, ..._to_hex_string"):
> On Thu, Jun 28, 2012 at 6:17 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> =
wrote:
> > This need to be slotted into my save/restore series, since a new case
> > of libxl__*alloc(0,...) was just added.
> =

> Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Thanks, and also to Dario, for the review.  I have committed this now.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:45: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 1SkIln-00030Z-8L; Thu, 28 Jun 2012 17:44: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 1SkIll-00030U-Rk
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:44:41 +0000
Received: from [85.158.139.83:9132] by server-10.bemta-5.messagelabs.com id
	45/52-02190-9089CEF4; Thu, 28 Jun 2012 17:44:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1340905480!25763095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6213 invoked from network); 28 Jun 2012 17:44:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:44:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13276929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:44:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:44:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkIlj-0001yv-RN; Thu, 28 Jun 2012 17:44:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkIlj-0000Iz-Nh;
	Thu, 28 Jun 2012 18:44:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.38919.637262.145163@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:44:39 +0100
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <royger@gmail.com>
In-Reply-To: <CAPLaKK6wfMzum+i6qV8DGyMCucsEa+AofW-AFpdJVkF9uy2Znw@mail.gmail.com>
References: <20460.37294.349060.11806@mariner.uk.xensource.com>
	<CAPLaKK6wfMzum+i6qV8DGyMCucsEa+AofW-AFpdJVkF9uy2Znw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Add a gc to libxl_cpumap_alloc,
 ..._to_hex_string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] libxl: Add a gc to libxl=
_cpumap_alloc, ..._to_hex_string"):
> On Thu, Jun 28, 2012 at 6:17 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> =
wrote:
> > This need to be slotted into my save/restore series, since a new case
> > of libxl__*alloc(0,...) was just added.
> =

> Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Thanks, and also to Dario, for the review.  I have committed this now.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkImP-00032U-M7; Thu, 28 Jun 2012 17:45: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 1SkImM-00032E-MM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:45:20 +0000
Received: from [85.158.138.51:10068] by server-5.bemta-3.messagelabs.com id
	11/7B-01572-D289CEF4; Thu, 28 Jun 2012 17:45:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340905515!23707849!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17625 invoked from network); 28 Jun 2012 17:45:16 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:45:16 -0000
Received: by qcab12 with SMTP id b12so375327qca.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 10:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2GLWMyt8Sg+3BMxGt+4dKf+pEu41EDG4UX7qtecbPdo=;
	b=qmzMg5YwMPvZUBSxaqmaSd1VoobgWFxr953xtWzxwOAgqFwH30v5xojQmRfEUnY2SA
	oVxr8L33JwzV2O/xsFkaLcy+/CZBylODGKLT1SicktxLzXfvxUwSUoDIVJx0sR7k3/qg
	0ioUIA41FWXs35h8DUYh89MghsSNfjBg+I8GVtumaZlMq0X2QA6pLTPCez2ByGdUAO3B
	wD6YLmebpY6zlXUB9fkxy3GzLllLnhHaU1mJhNP83a3bb5BzRuicSigME72qAjAf/C5G
	d6DcvRQvXbV8XoEmLMaUJd7Hrq3ytdMG9kXxJZF3n2Y1PnyOnIyqwbeHEe7SZHxaZRIa
	Vbtw==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr4646213qap.6.1340905515024; Thu,
	28 Jun 2012 10:45:15 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 10:45:14 -0700 (PDT)
In-Reply-To: <20120623194214.GF2640@US-SEA-R8XVZTX>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<20120623194214.GF2640@US-SEA-R8XVZTX>
Date: Thu, 28 Jun 2012 18:45:14 +0100
X-Google-Sender-Auth: Am9hEWzm9zXV-Yq_Xxu7XhIJmjI
Message-ID: <CAFLBxZYRFTTHxsF4KbAvDx6e-rrwjaPsFsjf4KTuvQtayW3E2A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matt Wilson <msw@amazon.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sat, Jun 23, 2012 at 8:42 PM, Matt Wilson <msw@amazon.com> wrote:
> But taking a step back, I propose that a core tenet of the security
> response process should be to reduce days-of-risk for all consumers of
> Xen.org projects, whether direct or indirect, to zero. Days-of-risk
> can be fuzzy to measure, so we could define this as the number of days
> between when a security problem is publicly known (e.g. through
> evidence of exploitation in the wild or a public announcement) and
> when the problem has been addressed such that there is no longer any
> risk (e.g., through a Xen consumer deploying a fixed version from a
> vendor or an infrastructure provider doing the same on a consumer=92s
> behalf.)

Minimizing overall risk for all users of Xen certainly is the end goal
of the "responsible disclosure" process.  However, there seem to be
two flaws in the way you are defining "days-of-risk" (from how you
seem to be using and arguing about the term):
* It assumes risk on any given day is 0 or 1
* It assumes that, in the absence of evidence to the contrary, risk is
0 until the vulnerability is published by members of the
pre-disclosure list.

If those two things were true, then your policy recommendations below
might make sense.

Unfortunately, neither are true.  The real risk begins the date
software with that vulnerability is *deployed*.  From that time
software with a vulnerability is first *deployed* until the time
software with the fix is deployed, every user of that software is at
risk.  Any black hat could have been looking at the code and wondering
the same thing that the original reporter was wondering.  In this case
even more so, because Linux introduced a patch to fix the
vulnerability for them in 2006.  There must have been any number of
black hats who looked at that vulnerability and wondered if other
operating systems were vulnerable, and discovered that they were.  So
having "0 days-of-risk" for a vulnerability disclosure process is, by
definition, impossible.

Now clearly, the risk greatly increases when the vulnerability is
announced.  But any discussion of whether, and which service providers
may be included in the vulnerability disclosure process must
acknowledge that:
1. *All* service providers, and indeed all users whether they provide
service or not, are at risk every hour that a fix is not deployed on
their systems
2. Any disclosure which allows some users to patch before others gives
an advantage to those users (whether by allowing them to actually
patch their systems before the embargo period, or allowing them to
prepare the patching system so that they can be down within an hour)

And I'm going to suggest something else which I think is true, and
relevant to the discussion:
3. A large majority of deployed Xen instances are run by people not on
the pre-disclosure list.

>> Of course this needs to deal clearly with the common stituation of an
>> organisation running Xen which is a direct consumer of Xen.org source
>> code.
>
> Indeed. If a goal of the process is to reduce days-of-risk for all
> consumers of Xen.org projects to zero, coordinating package updates
> only from software vendors will not achieve it.

But "coordinating package updates only" may minimize the total risk to
all users, by allowing more users to deploy sooner.

> This may be a reasonable starting point for general issues, but I
> think that the overall impact and complexity of an issue needs to be
> considered when establishing a timeline.

I guess in part it means on what you mean by "complexity of the issue":
* In this particular case, we ended up having to coordinate with other
vulnerable projects; that is rather an exception to the rule, and
should of course have special consideration.  (Although, I might argue
that we should have told the other projects, but simply not mentioned
in our disclosure that they may be vulnerable -- i.e., make the
announcement similar to Linux's 2006 reporting of the same
vulnerability.)
* You may mean "difficulty in coming up with a fix".  I think this can
be addressed by setting the disclosure period from the time that a
*fix* is available, not the time the vulnerability is known.
* You may mean, "difficulty in deploying the fix".  In this case, it
was a simple case of recompiling the hypervisor and rebooting* -- as
such, the deployment is probably as simple as it will ever get.

(* The complexity of doing unsupported things, like hot-patching the
hypervisor, shouldn't be considered IMHO.  If hot-patching is
valuable, work should be done to make that a supported feature.)

> Parties that are *active* in the coordinated disclosure, for example
> by building patched versions of products or services built on Xen,
> need to have access to as much technical information as possible in
> order to validate the fix and their ports. Those that are passive, who
> may be deploying a pre-release fixed version from a vendor, do not
> need access to these materials.

I think this distinction is important to consider.

This is not to you, but to everyone:  Can I suggest that as much as
possible, we don't use poorly-defined terms like "direct" and
"indirect"?  As far as I know we have the people listed below; we
should try to come up with clear terms for each of them.

* Software vendors, who take upstream Xen and package it into
something else and provide that software to users
* Users
 - "Private" users, who take Xen in some form and use it for themselves
 - Service providers, who use Xen to provide
infrastructure-as-a-service to others. (I think that's the right
*AAS...)
 - Service clients, who buy IAAS services from service providers.

The "Users" group can also be divided another way:
* Those that only consume software vendors' updates
* Those that apply their own patches to xen.org (or software vendors' updat=
es)
I don't think "passive" and "active" users really conveys the right
idea, but it will have to do for now.

So the question is: given that we can't have all active users on the
pre-disclosure list, what justification is there for having some of
them on the list?

 -George

(I think we should pretty much assume that unless explicitly stated,
all opinions are the opinions of the individuals, not the
organizations they work for.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkImP-00032U-M7; Thu, 28 Jun 2012 17:45: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 1SkImM-00032E-MM
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:45:20 +0000
Received: from [85.158.138.51:10068] by server-5.bemta-3.messagelabs.com id
	11/7B-01572-D289CEF4; Thu, 28 Jun 2012 17:45:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1340905515!23707849!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17625 invoked from network); 28 Jun 2012 17:45:16 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:45:16 -0000
Received: by qcab12 with SMTP id b12so375327qca.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 10:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2GLWMyt8Sg+3BMxGt+4dKf+pEu41EDG4UX7qtecbPdo=;
	b=qmzMg5YwMPvZUBSxaqmaSd1VoobgWFxr953xtWzxwOAgqFwH30v5xojQmRfEUnY2SA
	oVxr8L33JwzV2O/xsFkaLcy+/CZBylODGKLT1SicktxLzXfvxUwSUoDIVJx0sR7k3/qg
	0ioUIA41FWXs35h8DUYh89MghsSNfjBg+I8GVtumaZlMq0X2QA6pLTPCez2ByGdUAO3B
	wD6YLmebpY6zlXUB9fkxy3GzLllLnhHaU1mJhNP83a3bb5BzRuicSigME72qAjAf/C5G
	d6DcvRQvXbV8XoEmLMaUJd7Hrq3ytdMG9kXxJZF3n2Y1PnyOnIyqwbeHEe7SZHxaZRIa
	Vbtw==
MIME-Version: 1.0
Received: by 10.224.110.73 with SMTP id m9mr4646213qap.6.1340905515024; Thu,
	28 Jun 2012 10:45:15 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Thu, 28 Jun 2012 10:45:14 -0700 (PDT)
In-Reply-To: <20120623194214.GF2640@US-SEA-R8XVZTX>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<20120623194214.GF2640@US-SEA-R8XVZTX>
Date: Thu, 28 Jun 2012 18:45:14 +0100
X-Google-Sender-Auth: Am9hEWzm9zXV-Yq_Xxu7XhIJmjI
Message-ID: <CAFLBxZYRFTTHxsF4KbAvDx6e-rrwjaPsFsjf4KTuvQtayW3E2A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matt Wilson <msw@amazon.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sat, Jun 23, 2012 at 8:42 PM, Matt Wilson <msw@amazon.com> wrote:
> But taking a step back, I propose that a core tenet of the security
> response process should be to reduce days-of-risk for all consumers of
> Xen.org projects, whether direct or indirect, to zero. Days-of-risk
> can be fuzzy to measure, so we could define this as the number of days
> between when a security problem is publicly known (e.g. through
> evidence of exploitation in the wild or a public announcement) and
> when the problem has been addressed such that there is no longer any
> risk (e.g., through a Xen consumer deploying a fixed version from a
> vendor or an infrastructure provider doing the same on a consumer=92s
> behalf.)

Minimizing overall risk for all users of Xen certainly is the end goal
of the "responsible disclosure" process.  However, there seem to be
two flaws in the way you are defining "days-of-risk" (from how you
seem to be using and arguing about the term):
* It assumes risk on any given day is 0 or 1
* It assumes that, in the absence of evidence to the contrary, risk is
0 until the vulnerability is published by members of the
pre-disclosure list.

If those two things were true, then your policy recommendations below
might make sense.

Unfortunately, neither are true.  The real risk begins the date
software with that vulnerability is *deployed*.  From that time
software with a vulnerability is first *deployed* until the time
software with the fix is deployed, every user of that software is at
risk.  Any black hat could have been looking at the code and wondering
the same thing that the original reporter was wondering.  In this case
even more so, because Linux introduced a patch to fix the
vulnerability for them in 2006.  There must have been any number of
black hats who looked at that vulnerability and wondered if other
operating systems were vulnerable, and discovered that they were.  So
having "0 days-of-risk" for a vulnerability disclosure process is, by
definition, impossible.

Now clearly, the risk greatly increases when the vulnerability is
announced.  But any discussion of whether, and which service providers
may be included in the vulnerability disclosure process must
acknowledge that:
1. *All* service providers, and indeed all users whether they provide
service or not, are at risk every hour that a fix is not deployed on
their systems
2. Any disclosure which allows some users to patch before others gives
an advantage to those users (whether by allowing them to actually
patch their systems before the embargo period, or allowing them to
prepare the patching system so that they can be down within an hour)

And I'm going to suggest something else which I think is true, and
relevant to the discussion:
3. A large majority of deployed Xen instances are run by people not on
the pre-disclosure list.

>> Of course this needs to deal clearly with the common stituation of an
>> organisation running Xen which is a direct consumer of Xen.org source
>> code.
>
> Indeed. If a goal of the process is to reduce days-of-risk for all
> consumers of Xen.org projects to zero, coordinating package updates
> only from software vendors will not achieve it.

But "coordinating package updates only" may minimize the total risk to
all users, by allowing more users to deploy sooner.

> This may be a reasonable starting point for general issues, but I
> think that the overall impact and complexity of an issue needs to be
> considered when establishing a timeline.

I guess in part it means on what you mean by "complexity of the issue":
* In this particular case, we ended up having to coordinate with other
vulnerable projects; that is rather an exception to the rule, and
should of course have special consideration.  (Although, I might argue
that we should have told the other projects, but simply not mentioned
in our disclosure that they may be vulnerable -- i.e., make the
announcement similar to Linux's 2006 reporting of the same
vulnerability.)
* You may mean "difficulty in coming up with a fix".  I think this can
be addressed by setting the disclosure period from the time that a
*fix* is available, not the time the vulnerability is known.
* You may mean, "difficulty in deploying the fix".  In this case, it
was a simple case of recompiling the hypervisor and rebooting* -- as
such, the deployment is probably as simple as it will ever get.

(* The complexity of doing unsupported things, like hot-patching the
hypervisor, shouldn't be considered IMHO.  If hot-patching is
valuable, work should be done to make that a supported feature.)

> Parties that are *active* in the coordinated disclosure, for example
> by building patched versions of products or services built on Xen,
> need to have access to as much technical information as possible in
> order to validate the fix and their ports. Those that are passive, who
> may be deploying a pre-release fixed version from a vendor, do not
> need access to these materials.

I think this distinction is important to consider.

This is not to you, but to everyone:  Can I suggest that as much as
possible, we don't use poorly-defined terms like "direct" and
"indirect"?  As far as I know we have the people listed below; we
should try to come up with clear terms for each of them.

* Software vendors, who take upstream Xen and package it into
something else and provide that software to users
* Users
 - "Private" users, who take Xen in some form and use it for themselves
 - Service providers, who use Xen to provide
infrastructure-as-a-service to others. (I think that's the right
*AAS...)
 - Service clients, who buy IAAS services from service providers.

The "Users" group can also be divided another way:
* Those that only consume software vendors' updates
* Those that apply their own patches to xen.org (or software vendors' updat=
es)
I don't think "passive" and "active" users really conveys the right
idea, but it will have to do for now.

So the question is: given that we can't have all active users on the
pre-disclosure list, what justification is there for having some of
them on the list?

 -George

(I think we should pretty much assume that unless explicitly stated,
all opinions are the opinions of the individuals, not the
organizations they work for.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17: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 1SkImb-00033S-2U; Thu, 28 Jun 2012 17:45: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 1SkIma-00033H-1c
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:45:32 +0000
Received: from [85.158.138.51:11107] by server-7.bemta-3.messagelabs.com id
	18/73-10113-B389CEF4; Thu, 28 Jun 2012 17:45:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340905530!26023312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11348 invoked from network); 28 Jun 2012 17:45:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:45:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13276939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:45:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:45:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkImY-0001zD-0y; Thu, 28 Jun 2012 17:45:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkImY-0000J3-02;
	Thu, 28 Jun 2012 18:45:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.38969.988104.243956@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:45:29 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <20460.24135.825405.29982@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("[PATCH v6 00/21] libxl: domain save/restore: run in a separate process"):
> Following testing by Shriram (thanks) I have an updated version of
> 06/21.  For the sake of everyone's sanity (and your MUAs) I shan't
> repost the whole series.
> 
> Here is v6 of 06/21, which is simply the previous one with my earlier
> fixup patch folded in.

I have now rebased these to cope with a couple of minor conflicts,
dealt with the one missing NOGC conversion, and pushed it.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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 Thu Jun 28 17:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17: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 1SkImb-00033S-2U; Thu, 28 Jun 2012 17:45: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 1SkIma-00033H-1c
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:45:32 +0000
Received: from [85.158.138.51:11107] by server-7.bemta-3.messagelabs.com id
	18/73-10113-B389CEF4; Thu, 28 Jun 2012 17:45:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1340905530!26023312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11348 invoked from network); 28 Jun 2012 17:45:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:45:30 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13276939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:45:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:45:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkImY-0001zD-0y; Thu, 28 Jun 2012 17:45:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkImY-0000J3-02;
	Thu, 28 Jun 2012 18:45:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.38969.988104.243956@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:45:29 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <20460.24135.825405.29982@mariner.uk.xensource.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<20460.24135.825405.29982@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [PATCH v6 00/21] libxl: domain save/restore: run in a
 separate process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("[PATCH v6 00/21] libxl: domain save/restore: run in a separate process"):
> Following testing by Shriram (thanks) I have an updated version of
> 06/21.  For the sake of everyone's sanity (and your MUAs) I shan't
> repost the whole series.
> 
> Here is v6 of 06/21, which is simply the previous one with my earlier
> fixup patch folded in.

I have now rebased these to cope with a couple of minor conflicts,
dealt with the one missing NOGC conversion, and pushed it.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

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 Thu Jun 28 17:57:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:57: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 1SkIxv-0003RZ-9o; Thu, 28 Jun 2012 17:57: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 1SkIxu-0003RU-74
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:57:14 +0000
Received: from [85.158.143.99:37189] by server-1.bemta-4.messagelabs.com id
	1B/E3-24392-9FA9CEF4; Thu, 28 Jun 2012 17:57:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340906233!22603051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13131 invoked from network); 28 Jun 2012 17:57:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:57:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13277065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:56:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:56:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkIxL-00022y-9j	for xen-devel@lists.xen.org;
	Thu, 28 Jun 2012 17:56:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkIxL-0000TC-8v	for
	xen-devel@lists.xen.org; Thu, 28 Jun 2012 18:56:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.39639.262519.539480@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:56:39 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1340733318-21099-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<1340733318-21099-16-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 15/21] libxl: Get compiler to warn about
	gc_opt==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

Ian Jackson writes ("[PATCH 15/21] libxl: Get compiler to warn about gc_opt==NULL"):
> Since it used to be legal to pass gc_opt==NULL, and there are various
> patches floating about and under development which do so, add a
> compiler annotation which makes the build fail when that is done.
> 
> This turns a runtime crash into a build failure, and should ensure
> that we don't accidentally commit a broken combination of patches.

I would just like to mention that this did indeed today save me from
committing a broken combination of patches :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 17:57:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 17:57: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 1SkIxv-0003RZ-9o; Thu, 28 Jun 2012 17:57: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 1SkIxu-0003RU-74
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:57:14 +0000
Received: from [85.158.143.99:37189] by server-1.bemta-4.messagelabs.com id
	1B/E3-24392-9FA9CEF4; Thu, 28 Jun 2012 17:57:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340906233!22603051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13131 invoked from network); 28 Jun 2012 17:57:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:57:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13277065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 17:56:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 18:56:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkIxL-00022y-9j	for xen-devel@lists.xen.org;
	Thu, 28 Jun 2012 17:56:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkIxL-0000TC-8v	for
	xen-devel@lists.xen.org; Thu, 28 Jun 2012 18:56:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20460.39639.262519.539480@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:56:39 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <1340733318-21099-16-git-send-email-ian.jackson@eu.citrix.com>
References: <1340733318-21099-1-git-send-email-ian.jackson@eu.citrix.com>
	<1340733318-21099-16-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 15/21] libxl: Get compiler to warn about
	gc_opt==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

Ian Jackson writes ("[PATCH 15/21] libxl: Get compiler to warn about gc_opt==NULL"):
> Since it used to be legal to pass gc_opt==NULL, and there are various
> patches floating about and under development which do so, add a
> compiler annotation which makes the build fail when that is done.
> 
> This turns a runtime crash into a build failure, and should ensure
> that we don't accidentally commit a broken combination of patches.

I would just like to mention that this did indeed today save me from
committing a broken combination of patches :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 18:01:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 18:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkJ2C-0003eA-Vr; Thu, 28 Jun 2012 18:01:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1SkId4-0002hu-NB
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:35:42 +0000
Received: from [85.158.143.99:15285] by server-3.bemta-4.messagelabs.com id
	A5/8E-05808-EE59CEF4; Thu, 28 Jun 2012 17:35:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340904940!19860743!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 28 Jun 2012 17:35:41 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:35:41 -0000
Received: by bkwj10 with SMTP id j10so2534994bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 10:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=A3JrKOTbAxfwMlqgtRxg0tLqtFJe9V24kxAEU0A1dx8=;
	b=P5wKBm9/fmkoEVX2+nqwQYtwDoya4exTPVd/hcOYSJuZSIlul8Kl6eeQ0qhfrCOoe5
	mi0XRIFbOBC8MwfVu/Ym4Pnpm+kdgtABaUJh5HyfJfugEzO11v2Q4Z3KILRsu/97+qyx
	3WB8UMEseSzThWYjXGYw0YqrlihcU6+ikYN/D3U90KvXoAUwJgYi58lyPucXdAEv9+uQ
	RfIitcVg3Q55MalITNFGkI1c3nELHDlsOzUgJfxAZC5c/xFzgD3ldswOvLRmzRZV/0Ja
	Xwzq17y2nAT4DDYzMNx0nwU/kSUO1fdyL1CNxMfhHuf/25AoCZ3eJRdanHJtfSGS+wYA
	/Fjw==
MIME-Version: 1.0
Received: by 10.152.147.33 with SMTP id th1mr3183554lab.9.1340904940425; Thu,
	28 Jun 2012 10:35:40 -0700 (PDT)
Received: by 10.114.3.20 with HTTP; Thu, 28 Jun 2012 10:35:40 -0700 (PDT)
In-Reply-To: <20460.37294.349060.11806@mariner.uk.xensource.com>
References: <20460.37294.349060.11806@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:35:40 +0100
Message-ID: <CAPLaKK6wfMzum+i6qV8DGyMCucsEa+AofW-AFpdJVkF9uy2Znw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <royger@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailman-Approved-At: Thu, 28 Jun 2012 18:01:39 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Add a gc to libxl_cpumap_alloc,
	..._to_hex_string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVGh1LCBKdW4gMjgsIDIwMTIgYXQgNjoxNyBQTSwgSWFuIEphY2tzb24gPElhbi5KYWNrc29u
QGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+IFRoaXMgbmVlZCB0byBiZSBzbG90dGVkIGludG8gbXkg
c2F2ZS9yZXN0b3JlIHNlcmllcywgc2luY2UgYSBuZXcgY2FzZQo+IG9mIGxpYnhsX18qYWxsb2Mo
MCwuLi4pIHdhcyBqdXN0IGFkZGVkLgo+Cj4gVGhhbmtzLAo+IElhbi4KPgo+IEZyb206IElhbiBK
YWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgo+IFN1YmplY3Q6IFtQQVRDSF0gbGli
eGw6IEFkZCBhIGdjIHRvIGxpYnhsX2NwdW1hcF9hbGxvYywgLi4uX3RvX2hleF9zdHJpbmcKPgo+
IEluIHRoZSBuZXh0IHBhdGNoIHdlIGFyZSBnb2luZyB0byBjaGFuZ2UgdGhlIGRlZmluaXRpb24g
b2YgTk9HQyB0bwo+IHJlcXVpcmUgYSBsb2NhbCB2YXJpYWJsZSBsaWJ4bF9fZ2MgKmdjLiDCoEFu
ZCB0aGlzIG1lYW5zIHRoYXQgcGFzc2luZyAwCj4gdG8gbGlieGxfX2NhbGxvYyBpcyBnb2luZyB0
byBiZSB3cm9uZy4KPgo+IGxpYnhsX2NwdW1hcF9hbGxvYyBkb2Vzbid0IGhhdmUgYSBnYyBidXQg
cGFzc2VzIDAgdG8gbGlieGxfY2FsbG9jCj4gRml4IHRoaXMgYnk6Cj4gwqAtIGludHJvZHVjaW5n
IGFuIGBvdXQnIGxhYmVsIGFuZCBhbiByYyB2YXJpYWJsZQo+IMKgLSByZXBsYWNpbmcgdGhlIHJl
dHVybnMgd2l0aCDCoHJjID0gRVJST1JfQkxBSDsgZ290byBvdXQ7Cj4gwqAtIGFkZGluZyB1c2Vz
IG9mIEdDX0lOSVQgYW5kIEdDX0ZSRUUuCj4gwqAtIGNoYW5naW5nIE5VTEwgdG8gTk9HQyBpbiB0
aGUgY2FsbCB0byBsaWJ4bF9fY2FsbG9jCj4KPiBMaWtld2lzZSBmaXggbGlieGxfY3B1bWFwX3Rv
X2hleF9zdHJpbmcgYnk6Cj4gwqAtIGFkZGluZyBhIGxpYnhsX2N0eCogcGFyYW1ldGVyIGFuZCB1
cGRhdGluZyB0aGUgb25lIGNhbGwgc2l0ZQo+IMKgLSBhZGRpbmcgdXNlcyBvZiBHQ19JTklUIGFu
ZCBHQ19GUkVFLgo+IMKgLSBjaGFuZ2luZyBOVUxMIHRvIE5PR0MgaW4gdGhlIGNhbGwgdG8gbGli
eGxfX3phbGxvYwo+Cj4gU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1
LmNpdHJpeC5jb20+CgpBY2tlZC1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwu
dXBjLmVkdT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 28 18:01:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 18:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkJ2C-0003eA-Vr; Thu, 28 Jun 2012 18:01:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1SkId4-0002hu-NB
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 17:35:42 +0000
Received: from [85.158.143.99:15285] by server-3.bemta-4.messagelabs.com id
	A5/8E-05808-EE59CEF4; Thu, 28 Jun 2012 17:35:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340904940!19860743!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 28 Jun 2012 17:35:41 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 17:35:41 -0000
Received: by bkwj10 with SMTP id j10so2534994bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 10:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=A3JrKOTbAxfwMlqgtRxg0tLqtFJe9V24kxAEU0A1dx8=;
	b=P5wKBm9/fmkoEVX2+nqwQYtwDoya4exTPVd/hcOYSJuZSIlul8Kl6eeQ0qhfrCOoe5
	mi0XRIFbOBC8MwfVu/Ym4Pnpm+kdgtABaUJh5HyfJfugEzO11v2Q4Z3KILRsu/97+qyx
	3WB8UMEseSzThWYjXGYw0YqrlihcU6+ikYN/D3U90KvXoAUwJgYi58lyPucXdAEv9+uQ
	RfIitcVg3Q55MalITNFGkI1c3nELHDlsOzUgJfxAZC5c/xFzgD3ldswOvLRmzRZV/0Ja
	Xwzq17y2nAT4DDYzMNx0nwU/kSUO1fdyL1CNxMfhHuf/25AoCZ3eJRdanHJtfSGS+wYA
	/Fjw==
MIME-Version: 1.0
Received: by 10.152.147.33 with SMTP id th1mr3183554lab.9.1340904940425; Thu,
	28 Jun 2012 10:35:40 -0700 (PDT)
Received: by 10.114.3.20 with HTTP; Thu, 28 Jun 2012 10:35:40 -0700 (PDT)
In-Reply-To: <20460.37294.349060.11806@mariner.uk.xensource.com>
References: <20460.37294.349060.11806@mariner.uk.xensource.com>
Date: Thu, 28 Jun 2012 18:35:40 +0100
Message-ID: <CAPLaKK6wfMzum+i6qV8DGyMCucsEa+AofW-AFpdJVkF9uy2Znw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <royger@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailman-Approved-At: Thu, 28 Jun 2012 18:01:39 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Add a gc to libxl_cpumap_alloc,
	..._to_hex_string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVGh1LCBKdW4gMjgsIDIwMTIgYXQgNjoxNyBQTSwgSWFuIEphY2tzb24gPElhbi5KYWNrc29u
QGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+IFRoaXMgbmVlZCB0byBiZSBzbG90dGVkIGludG8gbXkg
c2F2ZS9yZXN0b3JlIHNlcmllcywgc2luY2UgYSBuZXcgY2FzZQo+IG9mIGxpYnhsX18qYWxsb2Mo
MCwuLi4pIHdhcyBqdXN0IGFkZGVkLgo+Cj4gVGhhbmtzLAo+IElhbi4KPgo+IEZyb206IElhbiBK
YWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgo+IFN1YmplY3Q6IFtQQVRDSF0gbGli
eGw6IEFkZCBhIGdjIHRvIGxpYnhsX2NwdW1hcF9hbGxvYywgLi4uX3RvX2hleF9zdHJpbmcKPgo+
IEluIHRoZSBuZXh0IHBhdGNoIHdlIGFyZSBnb2luZyB0byBjaGFuZ2UgdGhlIGRlZmluaXRpb24g
b2YgTk9HQyB0bwo+IHJlcXVpcmUgYSBsb2NhbCB2YXJpYWJsZSBsaWJ4bF9fZ2MgKmdjLiDCoEFu
ZCB0aGlzIG1lYW5zIHRoYXQgcGFzc2luZyAwCj4gdG8gbGlieGxfX2NhbGxvYyBpcyBnb2luZyB0
byBiZSB3cm9uZy4KPgo+IGxpYnhsX2NwdW1hcF9hbGxvYyBkb2Vzbid0IGhhdmUgYSBnYyBidXQg
cGFzc2VzIDAgdG8gbGlieGxfY2FsbG9jCj4gRml4IHRoaXMgYnk6Cj4gwqAtIGludHJvZHVjaW5n
IGFuIGBvdXQnIGxhYmVsIGFuZCBhbiByYyB2YXJpYWJsZQo+IMKgLSByZXBsYWNpbmcgdGhlIHJl
dHVybnMgd2l0aCDCoHJjID0gRVJST1JfQkxBSDsgZ290byBvdXQ7Cj4gwqAtIGFkZGluZyB1c2Vz
IG9mIEdDX0lOSVQgYW5kIEdDX0ZSRUUuCj4gwqAtIGNoYW5naW5nIE5VTEwgdG8gTk9HQyBpbiB0
aGUgY2FsbCB0byBsaWJ4bF9fY2FsbG9jCj4KPiBMaWtld2lzZSBmaXggbGlieGxfY3B1bWFwX3Rv
X2hleF9zdHJpbmcgYnk6Cj4gwqAtIGFkZGluZyBhIGxpYnhsX2N0eCogcGFyYW1ldGVyIGFuZCB1
cGRhdGluZyB0aGUgb25lIGNhbGwgc2l0ZQo+IMKgLSBhZGRpbmcgdXNlcyBvZiBHQ19JTklUIGFu
ZCBHQ19GUkVFLgo+IMKgLSBjaGFuZ2luZyBOVUxMIHRvIE5PR0MgaW4gdGhlIGNhbGwgdG8gbGli
eGxfX3phbGxvYwo+Cj4gU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1
LmNpdHJpeC5jb20+CgpBY2tlZC1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwu
dXBjLmVkdT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Jun 28 18:19:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkJJG-000418-Jc; Thu, 28 Jun 2012 18:19:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SkJJF-000413-3j
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 18:19:17 +0000
Received: from [85.158.138.51:43456] by server-12.bemta-3.messagelabs.com id
	66/40-30206-420ACEF4; Thu, 28 Jun 2012 18:19:16 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340907553!21911225!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA5NjAxNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18738 invoked from network); 28 Jun 2012 18:19:15 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 18:19:15 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 28 Jun 2012 23:49:13 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 28 Jun 2012 23:49:08 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q5SIJ6Lv48365778
	for <xen-devel@lists.xensource.com>; Thu, 28 Jun 2012 23:49:07 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q5SNmpMf010173
	for <xen-devel@lists.xensource.com>; Fri, 29 Jun 2012 09:48:53 +1000
Received: from [9.79.192.186] ([9.79.192.186])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q5SNmmc0009880; Fri, 29 Jun 2012 09:48:48 +1000
Message-ID: <4FEC9FB7.3000608@linux.vnet.ibm.com>
Date: Thu, 28 Jun 2012 23:47:27 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
	<4F9A78CF.7070005@linux.vnet.ibm.com>
	<20120427155318.GI6833@redhat.com>
In-Reply-To: <20120427155318.GI6833@redhat.com>
x-cbid: 12062818-8878-0000-0000-000003110FE0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/27/2012 09:23 PM, Gleb Natapov wrote:
> On Fri, Apr 27, 2012 at 04:15:35PM +0530, Raghavendra K T wrote:
>> On 04/24/2012 03:29 PM, Gleb Natapov wrote:
>>> On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
>>>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>>>
>>>> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>>>>
>>>> The presence of these hypercalls is indicated to guest via
>>>> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>>>>
>>>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>>> Signed-off-by: Suzuki Poulose<suzuki@in.ibm.com>
>>>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>>> ---
>> [...]
>>>> +/*
>>>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>>>> + *
>>>> + * @apicid - apicid of vcpu to be kicked.
>>>> + */
>>>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>>>> +{
>>>> +	struct kvm_vcpu *vcpu = NULL;
>>>> +	int i;
>>>> +
>>>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>>>> +		if (!kvm_apic_present(vcpu))
>>>> +			continue;
>>>> +
>>>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>>>> +			break;
>>>> +	}
>>>> +	if (vcpu) {
>>>> +		/*
>>>> +		 * Setting unhalt flag here can result in spurious runnable
>>>> +		 * state when unhalt reset does not happen in vcpu_block.
>>>> +		 * But that is harmless since that should soon result in halt.
>>>> +		 */
>>>> +		vcpu->arch.pv.pv_unhalted = 1;
>>>> +		/* We need everybody see unhalt before vcpu unblocks */
>>>> +		smp_mb();
>>>> +		kvm_vcpu_kick(vcpu);
>>>> +	}
>>>> +}
>>> This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
>>> can use one of reserved delivery modes as PV delivery mode. We will
>>> disallow guest to trigger it through apic interface, so this will not be
>>> part of ABI and can be changed at will.
[...]
>> kvm/x86.c
>> =========
>> kvm_pv_kick_cpu_op()
>> {
>>
>>   struct kvm_lapic_irq lapic_irq;
>>
>>   lapic_irq.shorthand = 0;
>>   lapic_irq.dest_mode = 0;
>>   lapic_irq.dest_id = apicid;
>>
>>   lapic_irq.delivery_mode = PV_DELIVERY_MODE;
>>   kvm_irq_delivery_to_apic(kvm, 0,&lapic_irq );
>>
>> }
>>
>> kvm/lapic.c
>> ==========
>> _apic_accept_irq()
>> {
>> ...
>> case APIC_DM_REMRD:
>>                  result = 1;
>>                  vcpu->pv_unhalted = 1
>>                  smp_mb();
>>                  kvm_make_request(KVM_REQ_EVENT, vcpu);
>>                  kvm_vcpu_kick(vcpu);
>>                  break;
>>
>> ...
>> }
>>
>> here using PV_DELIVERY_MODE = APIC_DM_REMRD, which was unused.
>>
> Yes, this is what I mean except that PV_DELIVERY_MODE should be
> number defined as reserved by Intel spec.
>

Hi Gleb, Avi,

This had been TODO in my V8 patches.
I 'll fold this into V9 (while rebasing to
3.5-rc).
Please let me know if it is OK.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 18:19:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 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 1SkJJG-000418-Jc; Thu, 28 Jun 2012 18:19:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1SkJJF-000413-3j
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 18:19:17 +0000
Received: from [85.158.138.51:43456] by server-12.bemta-3.messagelabs.com id
	66/40-30206-420ACEF4; Thu, 28 Jun 2012 18:19:16 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340907553!21911225!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA5NjAxNA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18738 invoked from network); 28 Jun 2012 18:19:15 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Jun 2012 18:19:15 -0000
Received: from /spool/local
	by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Thu, 28 Jun 2012 23:49:13 +0530
Received: from d28relay04.in.ibm.com (9.184.220.61)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Thu, 28 Jun 2012 23:49:08 +0530
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q5SIJ6Lv48365778
	for <xen-devel@lists.xensource.com>; Thu, 28 Jun 2012 23:49:07 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q5SNmpMf010173
	for <xen-devel@lists.xensource.com>; Fri, 29 Jun 2012 09:48:53 +1000
Received: from [9.79.192.186] ([9.79.192.186])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q5SNmmc0009880; Fri, 29 Jun 2012 09:48:48 +1000
Message-ID: <4FEC9FB7.3000608@linux.vnet.ibm.com>
Date: Thu, 28 Jun 2012 23:47:27 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com>
	<20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com>
	<20120424095923.GS15413@redhat.com>
	<4F9A78CF.7070005@linux.vnet.ibm.com>
	<20120427155318.GI6833@redhat.com>
In-Reply-To: <20120427155318.GI6833@redhat.com>
x-cbid: 12062818-8878-0000-0000-000003110FE0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, X86 <x86@kernel.org>,
	KVM <kvm@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Alexander Graf <agraf@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall
 to KVM hypervisor to support pv-ticketlocks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/27/2012 09:23 PM, Gleb Natapov wrote:
> On Fri, Apr 27, 2012 at 04:15:35PM +0530, Raghavendra K T wrote:
>> On 04/24/2012 03:29 PM, Gleb Natapov wrote:
>>> On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
>>>> From: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>>>
>>>> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
>>>>
>>>> The presence of these hypercalls is indicated to guest via
>>>> KVM_FEATURE_PV_UNHALT/KVM_CAP_PV_UNHALT.
>>>>
>>>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>>> Signed-off-by: Suzuki Poulose<suzuki@in.ibm.com>
>>>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>>> ---
>> [...]
>>>> +/*
>>>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>>>> + *
>>>> + * @apicid - apicid of vcpu to be kicked.
>>>> + */
>>>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>>>> +{
>>>> +	struct kvm_vcpu *vcpu = NULL;
>>>> +	int i;
>>>> +
>>>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>>>> +		if (!kvm_apic_present(vcpu))
>>>> +			continue;
>>>> +
>>>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>>>> +			break;
>>>> +	}
>>>> +	if (vcpu) {
>>>> +		/*
>>>> +		 * Setting unhalt flag here can result in spurious runnable
>>>> +		 * state when unhalt reset does not happen in vcpu_block.
>>>> +		 * But that is harmless since that should soon result in halt.
>>>> +		 */
>>>> +		vcpu->arch.pv.pv_unhalted = 1;
>>>> +		/* We need everybody see unhalt before vcpu unblocks */
>>>> +		smp_mb();
>>>> +		kvm_vcpu_kick(vcpu);
>>>> +	}
>>>> +}
>>> This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
>>> can use one of reserved delivery modes as PV delivery mode. We will
>>> disallow guest to trigger it through apic interface, so this will not be
>>> part of ABI and can be changed at will.
[...]
>> kvm/x86.c
>> =========
>> kvm_pv_kick_cpu_op()
>> {
>>
>>   struct kvm_lapic_irq lapic_irq;
>>
>>   lapic_irq.shorthand = 0;
>>   lapic_irq.dest_mode = 0;
>>   lapic_irq.dest_id = apicid;
>>
>>   lapic_irq.delivery_mode = PV_DELIVERY_MODE;
>>   kvm_irq_delivery_to_apic(kvm, 0,&lapic_irq );
>>
>> }
>>
>> kvm/lapic.c
>> ==========
>> _apic_accept_irq()
>> {
>> ...
>> case APIC_DM_REMRD:
>>                  result = 1;
>>                  vcpu->pv_unhalted = 1
>>                  smp_mb();
>>                  kvm_make_request(KVM_REQ_EVENT, vcpu);
>>                  kvm_vcpu_kick(vcpu);
>>                  break;
>>
>> ...
>> }
>>
>> here using PV_DELIVERY_MODE = APIC_DM_REMRD, which was unused.
>>
> Yes, this is what I mean except that PV_DELIVERY_MODE should be
> number defined as reserved by Intel spec.
>

Hi Gleb, Avi,

This had been TODO in my V8 patches.
I 'll fold this into V9 (while rebasing to
3.5-rc).
Please let me know if it is OK.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 18:26:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 18:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkJQN-0004Ca-LE; Thu, 28 Jun 2012 18:26:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1SkJQL-0004CV-QZ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 18:26:38 +0000
Received: from [193.109.254.147:16894] by server-12.bemta-14.messagelabs.com
	id 71/1A-30461-DD1ACEF4; Thu, 28 Jun 2012 18:26:37 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340907995!9085580!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20336 invoked from network); 28 Jun 2012 18:26:36 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 18:26:36 -0000
Received: from pyramind.ukuu.org.uk (earthlight.etchedpixels.co.uk
	[81.2.110.250])
	by lxorguk.ukuu.org.uk (8.14.5/8.14.1) with ESMTP id q5SJ0AvP010103;
	Thu, 28 Jun 2012 20:00:15 +0100
Received: from pyramind.ukuu.org.uk (localhost [127.0.0.1])
	by pyramind.ukuu.org.uk (8.14.5/8.14.5) with ESMTP id q5SIUcJq008356;
	Thu, 28 Jun 2012 19:30:38 +0100
Date: Thu, 28 Jun 2012 19:30:37 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20120628193037.4a7c10c2@pyramind.ukuu.org.uk>
In-Reply-To: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> I think this should be done via (perhaps silent) consensus on the
> pre-discosure list. Leaving the embargo time line determination
> entirely to the discoverer isn't really suitable. 

Reality check. If the reporter decides to give you a date you are given a
date, if they decide to not negotiate that date then you can either meet
it or leave your customers vulnerable when it is published.

A lot of reporters are hostile to extensions and slowness because there
is a long history of process abuse elsewhere.

> I think having hardware vendors involved is really only necessary
> when hardware related issues need to be dealt with.

Which can be done on a case by case basis.

> As indicated above, this should not be permitted, due to
> fairness considerations. Otherwise we should not place
> restrictions on who might be on the list at least as an observer.

For any GPL code elements you cannot create a contractual basis for
preventing code release. It's a violation of the GPL "additional
restrictions" rule. At best you can trust everyone to be sensible.

> Just the same we allow individual vendors to communicate -
> acknowledge the fact that there is a vulnerability, identifiers, and
> expected embargo deadline.

You also need to end it the moment a third party publishes any info, or
you'll get into stupid situations where only those who signed up to it
can't talk about it (eg the infamous pentium lockup bug)

> > 8. Predisclosure subscription process, and email address criteria

Email is not a trustworthy medium. The linux security list  was in the
past intercepted.

> > We need a clear policy about releasing proof of concept exploits -
> > whether, when and who to.
> 
> This I think could (and perhaps should) be really be left to the
> discoverer, as this may be considered intellectual property.

They ought to be in the regression suite if possible.

On the fixes side also remember some vendors may choose to ship fixes
that differ from the "official" one.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 18:26:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 18:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkJQN-0004Ca-LE; Thu, 28 Jun 2012 18:26:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1SkJQL-0004CV-QZ
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 18:26:38 +0000
Received: from [193.109.254.147:16894] by server-12.bemta-14.messagelabs.com
	id 71/1A-30461-DD1ACEF4; Thu, 28 Jun 2012 18:26:37 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340907995!9085580!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20336 invoked from network); 28 Jun 2012 18:26:36 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 18:26:36 -0000
Received: from pyramind.ukuu.org.uk (earthlight.etchedpixels.co.uk
	[81.2.110.250])
	by lxorguk.ukuu.org.uk (8.14.5/8.14.1) with ESMTP id q5SJ0AvP010103;
	Thu, 28 Jun 2012 20:00:15 +0100
Received: from pyramind.ukuu.org.uk (localhost [127.0.0.1])
	by pyramind.ukuu.org.uk (8.14.5/8.14.5) with ESMTP id q5SIUcJq008356;
	Thu, 28 Jun 2012 19:30:38 +0100
Date: Thu, 28 Jun 2012 19:30:37 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20120628193037.4a7c10c2@pyramind.ukuu.org.uk>
In-Reply-To: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> I think this should be done via (perhaps silent) consensus on the
> pre-discosure list. Leaving the embargo time line determination
> entirely to the discoverer isn't really suitable. 

Reality check. If the reporter decides to give you a date you are given a
date, if they decide to not negotiate that date then you can either meet
it or leave your customers vulnerable when it is published.

A lot of reporters are hostile to extensions and slowness because there
is a long history of process abuse elsewhere.

> I think having hardware vendors involved is really only necessary
> when hardware related issues need to be dealt with.

Which can be done on a case by case basis.

> As indicated above, this should not be permitted, due to
> fairness considerations. Otherwise we should not place
> restrictions on who might be on the list at least as an observer.

For any GPL code elements you cannot create a contractual basis for
preventing code release. It's a violation of the GPL "additional
restrictions" rule. At best you can trust everyone to be sensible.

> Just the same we allow individual vendors to communicate -
> acknowledge the fact that there is a vulnerability, identifiers, and
> expected embargo deadline.

You also need to end it the moment a third party publishes any info, or
you'll get into stupid situations where only those who signed up to it
can't talk about it (eg the infamous pentium lockup bug)

> > 8. Predisclosure subscription process, and email address criteria

Email is not a trustworthy medium. The linux security list  was in the
past intercepted.

> > We need a clear policy about releasing proof of concept exploits -
> > whether, when and who to.
> 
> This I think could (and perhaps should) be really be left to the
> discoverer, as this may be considered intellectual property.

They ought to be in the regression suite if possible.

On the fixes side also remember some vendors may choose to ship fixes
that differ from the "official" one.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 20:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 20: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 1SkLeO-0006Ya-Ry; Thu, 28 Jun 2012 20:49: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 1SkLeM-0006YV-PD
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 20:49:15 +0000
Received: from [85.158.138.51:36749] by server-11.bemta-3.messagelabs.com id
	BF/E3-02904-543CCEF4; Thu, 28 Jun 2012 20:49:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340916548!21992238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3463 invoked from network); 28 Jun 2012 20:49:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 20:49:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13278530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 20:49:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 21:49:07 +0100
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 1SkLeF-00032a-Iv;
	Thu, 28 Jun 2012 20:49:07 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkLeF-0004BW-8s;
	Thu, 28 Jun 2012 21:49:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13383-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 21:49:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13383 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13376

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  52f1b8a4f9a4
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25521:52f1b8a4f9a4
tag:         tip
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Wed Jun 27 17:50:10 2012 +0100
    
    xen,pod: Cosmetic code motion
    
    No point in doing the assignment if we're just going to crash anyway.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    
    
changeset:   25520:2d9f3b010901
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jun 28 12:45:09 2012 +0100
    
    x86/mm: Clean up unshare path for foreign mappings
    
    In its current shape, if Xen unshares a foreign gfn successfully while building
    a foreign writable map, it is left with a reference to the old shared page in
    the "target" var.
    
    Instead, push unsharing request down on the initial get_page_from_gfn call,
    which will DTRT.
    
    This allows for greatly simplifying the unshare related condition handling,
    removing ugly comments and s86_64 ifdef-ery.
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   25519:fdc1f16d382c
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Jun 28 13:36:08 2012 +0200
    
    x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]
    
    Since the emulator now supports a few 256-bit memory operations, this
    array needs to follow (and the comments should, too).
    
    To limit growth, re-order the mmio_large_write_* fields so that the
    two mmio_large_*_bytes fields end up adjacent to each other.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25518:4f92bdf3370c
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Jun 27 09:36:43 2012 +0200
    
    docs/xen-headers: allow headers to be symlinks
    
    There's no apparent reason not to permit this, and since we don't
    support out-of-source-tree builds, the least overhead way of doing
    multiple, differently configured (perhaps different architecture)
    builds from a single source tree is to create symlinked build trees.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Jun 7 19:44:01 2012 +0100

    qemu-xen-trad: fix sys-queue.h usage on BSD systems
    
    BSD systems already have a sys/queue.h file, which has more macros
    than the one Qemu uses, and some header files depend on having that
    macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
    systems and include the native one.
    
    This is not a backport because the original patch is too dificult to
    backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
    
    Doing a diff -bB shows that the Qemu version is just a stripped
    version of the original NetBSD header, with many macros removed, but
    no new ones added.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 20:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 20: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 1SkLeO-0006Ya-Ry; Thu, 28 Jun 2012 20:49: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 1SkLeM-0006YV-PD
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 20:49:15 +0000
Received: from [85.158.138.51:36749] by server-11.bemta-3.messagelabs.com id
	BF/E3-02904-543CCEF4; Thu, 28 Jun 2012 20:49:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340916548!21992238!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3463 invoked from network); 28 Jun 2012 20:49:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 20:49:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="13278530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 20:49:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 28 Jun 2012 21:49:07 +0100
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 1SkLeF-00032a-Iv;
	Thu, 28 Jun 2012 20:49:07 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkLeF-0004BW-8s;
	Thu, 28 Jun 2012 21:49:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13383-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 21:49:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13383 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail like 13376

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  52f1b8a4f9a4
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25521:52f1b8a4f9a4
tag:         tip
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Wed Jun 27 17:50:10 2012 +0100
    
    xen,pod: Cosmetic code motion
    
    No point in doing the assignment if we're just going to crash anyway.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    
    
changeset:   25520:2d9f3b010901
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jun 28 12:45:09 2012 +0100
    
    x86/mm: Clean up unshare path for foreign mappings
    
    In its current shape, if Xen unshares a foreign gfn successfully while building
    a foreign writable map, it is left with a reference to the old shared page in
    the "target" var.
    
    Instead, push unsharing request down on the initial get_page_from_gfn call,
    which will DTRT.
    
    This allows for greatly simplifying the unshare related condition handling,
    removing ugly comments and s86_64 ifdef-ery.
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   25519:fdc1f16d382c
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Jun 28 13:36:08 2012 +0200
    
    x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]
    
    Since the emulator now supports a few 256-bit memory operations, this
    array needs to follow (and the comments should, too).
    
    To limit growth, re-order the mmio_large_write_* fields so that the
    two mmio_large_*_bytes fields end up adjacent to each other.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25518:4f92bdf3370c
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Jun 27 09:36:43 2012 +0200
    
    docs/xen-headers: allow headers to be symlinks
    
    There's no apparent reason not to permit this, and since we don't
    support out-of-source-tree builds, the least overhead way of doing
    multiple, differently configured (perhaps different architecture)
    builds from a single source tree is to create symlinked build trees.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Jun 7 19:44:01 2012 +0100

    qemu-xen-trad: fix sys-queue.h usage on BSD systems
    
    BSD systems already have a sys/queue.h file, which has more macros
    than the one Qemu uses, and some header files depend on having that
    macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
    systems and include the native one.
    
    This is not a backport because the original patch is too dificult to
    backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
    
    Doing a diff -bB shows that the Qemu version is just a stripped
    version of the original NetBSD header, with many macros removed, but
    no new ones added.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 20:52:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 20:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkLhW-0006lK-4I; Thu, 28 Jun 2012 20:52:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1SkLhU-0006l4-4p
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 20:52:28 +0000
Received: from [193.109.254.147:2745] by server-12.bemta-14.messagelabs.com id
	B7/9E-30461-B04CCEF4; Thu, 28 Jun 2012 20:52:27 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340916746!9101347!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5753 invoked from network); 28 Jun 2012 20:52:26 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 20:52:26 -0000
Received: by bkwj10 with SMTP id j10so2746104bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 13:52:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=+WGY3vZAcpWLoaYALwxOHud6Pr346E1N12JcnhYx1QY=;
	b=tnviFmJZ+MfD/7C8C4YegRC4vhtO68D30CIx2/YRYwKNE7EGncN6s48TL8Fjx0DMet
	DdgDRNQ3BCfgV1rAt3fPRcvS42ysL4HX571jFu6mfbaPDIdjQXTslIyVrmZ/Wlr6RLTG
	gNY1H8uAaqpELiaP/ZqrkAi0P+z+fsFWODPrRJKba53mhHxnlqf2baKzfMerwpjsUMAP
	3KhaoDLWGbbcdSoU+XdZ9AXhX9q41jnHrBodjCVUA/g8m6UIO9XAVeMMX0w3Mv9kltfR
	RPi5e2YxuXzAmC2SvmpKjlYxZZKFy3w05moowMip7LSOJ2xQ/M1M5tbjLzfUyGOeFzR4
	gheA==
MIME-Version: 1.0
Received: by 10.152.131.68 with SMTP id ok4mr3684475lab.47.1340916745969; Thu,
	28 Jun 2012 13:52:25 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Thu, 28 Jun 2012 13:52:25 -0700 (PDT)
In-Reply-To: <CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
Date: Thu, 28 Jun 2012 13:52:25 -0700
Message-ID: <CABg=H3NGemrrkKWXEfEet8hWGN5_qvm3aS33NvdKfWhzgvUUMw@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Rolu <rolu@roce.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 27, 2012 at 4:18 PM, Deep Debroy <ddebroy@gmail.com> wrote:
> On Mon, Jun 25, 2012 at 7:51 PM, Rolu <rolu@roce.org> wrote:
>>
>> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
>> > Hi, I was playing around with a MSI capable virtual device (so far
>> > submitted as patches only) in the upstream qemu tree but having
>> > trouble getting it to work on a Xen hvm guest. The device happens to
>> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
>> > works fine in a Xen guest when I switch the device's=A0code to force
>> > usage of legacy interrupts with upstream QEMU. With MSI based
>> > interrupts, the device works fine on a KVM guest but as stated before,
>> > not on a Xen guest. After digging a bit, it appears, the reason for
>> > the failure in Xen guests is that the MSI data register in the Xen
>> > guest ends up with a value of 4300 where the Deliver Mode value of 3
>> > happens to be reserved (per spec) and therefore illegal. The
>> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
>> > illegal (per expectation) causing all commands issued by the guest OS
>> > on the device to timeout.
>> >
>> > Given this above scenario, I was wondering if anyone can shed some
>> > light on how to debug this further for Xen. Something I would
>> > specifically like to know is where the MSI data register configuration
>> > actually happens. Is it done by some code specific to Xen and within
>> > the Xen codebase or it all done within QEMU?
>> >
>>
>> This seems like the same issue I ran into, though in my case it is
>> with passed through physical devices. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
>> the older messages in that thread for more info on what's going on. No
>> fix yet but help debugging is very welcome.
>
> Thanks Rolu for pointing out the other thread - it was very useful.
> Some of the symptoms appear to be identical in my case. However, I am
> not using a pass-through device. Instead, in my case it's a fully
> virtualized device pretty much identical to a raw file backed disk
> image where the controller is pvscsi rather than lsi. Therefore I
> guess some of the latter discussion in the other thread around
> pass-through specific areas of code in qemu are not relevant? Please
> correct me if I am wrong. Also note that I am using upstream qemu
> where neither the #define for PT_PCI_MSITRANSLATE_DEFAULT nor
> xenstore.c exsits (which is where Stefano's suggested change appeared
> to be).
>
> So far, here's what I am observing in the hvm linux guest :
>
> On the guest side, as discussed in the other thread,
> xen_hvm_setup_msi_irqs is invoked for the device and a value of 0x4300
> is being by xen_msi_compose_msg that is written in the data register.
> On the qemu (upstream) side, when the virtualized controller is trying
> to complete a request, it's invoking the following chain of calls ->
> stl_le_phys -> xen_apic_mem_write -> xen_hvm_inject_msi
> On the xen side, this ends up in: hvmop_inject_msi -> hvm_inject_msi
> -> vmsi_deliver. vmsi_deliver, as previously discussed, rejects the
> delivery mode of 0x3.
>
> Is the above sequence of interactions the expected path for a HVM
> guest trying to use a fully virtualized device/controller that uses
> MSI in upstream qemu? If so, if a standard linux guest always
> populates the value of 0x4300 in the MSI data register through
> xen_hvm_setup_msi_irqs, how are MSI notifications from a device in
> qemu supposed to work given the delivery type of 0x3 is indeed
> reserved and bypass the the vmsi_deliver check?
>
> Thanks,
> Deep

I wanted to see whether the HVM guest can interact with the MSI
virtualized controller properly without any of the Xen-specific code
in the linux kernel kicking in (i.e. allowing the regular PCI/MSI code
in linux to fire). So I rebuilt the kernel with CONFIG_XEN disabled
such that pci_xen_hvm_init no longer sets x86_msi.*msi_irqs to xen
specific routines like xen_hvm_setup_msi_irqs which is where the
0x4300 is getting populated. This seems to work properly. The MSI data
register for the controller ends up getting a valid value like 0x4049,
vmsi_deliver no longer complains, all MSI notifications are delivered
in the expected way to the guest and the raw, file-backed disks
attached to the controller showing up in fdisk -l.

My conclusion: the linux kernel's xen specific code, specifically
routines like xen_hvm_setup_msi_irqs, need to be tweaked to work with
fully virtualized qemu devices that use MSI. I will follow-up
regarding that on LKML.

Thanks,
Deep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 20:52:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 20:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkLhW-0006lK-4I; Thu, 28 Jun 2012 20:52:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1SkLhU-0006l4-4p
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 20:52:28 +0000
Received: from [193.109.254.147:2745] by server-12.bemta-14.messagelabs.com id
	B7/9E-30461-B04CCEF4; Thu, 28 Jun 2012 20:52:27 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1340916746!9101347!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5753 invoked from network); 28 Jun 2012 20:52:26 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 20:52:26 -0000
Received: by bkwj10 with SMTP id j10so2746104bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 13:52:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=+WGY3vZAcpWLoaYALwxOHud6Pr346E1N12JcnhYx1QY=;
	b=tnviFmJZ+MfD/7C8C4YegRC4vhtO68D30CIx2/YRYwKNE7EGncN6s48TL8Fjx0DMet
	DdgDRNQ3BCfgV1rAt3fPRcvS42ysL4HX571jFu6mfbaPDIdjQXTslIyVrmZ/Wlr6RLTG
	gNY1H8uAaqpELiaP/ZqrkAi0P+z+fsFWODPrRJKba53mhHxnlqf2baKzfMerwpjsUMAP
	3KhaoDLWGbbcdSoU+XdZ9AXhX9q41jnHrBodjCVUA/g8m6UIO9XAVeMMX0w3Mv9kltfR
	RPi5e2YxuXzAmC2SvmpKjlYxZZKFy3w05moowMip7LSOJ2xQ/M1M5tbjLzfUyGOeFzR4
	gheA==
MIME-Version: 1.0
Received: by 10.152.131.68 with SMTP id ok4mr3684475lab.47.1340916745969; Thu,
	28 Jun 2012 13:52:25 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Thu, 28 Jun 2012 13:52:25 -0700 (PDT)
In-Reply-To: <CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
Date: Thu, 28 Jun 2012 13:52:25 -0700
Message-ID: <CABg=H3NGemrrkKWXEfEet8hWGN5_qvm3aS33NvdKfWhzgvUUMw@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Rolu <rolu@roce.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 27, 2012 at 4:18 PM, Deep Debroy <ddebroy@gmail.com> wrote:
> On Mon, Jun 25, 2012 at 7:51 PM, Rolu <rolu@roce.org> wrote:
>>
>> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
>> > Hi, I was playing around with a MSI capable virtual device (so far
>> > submitted as patches only) in the upstream qemu tree but having
>> > trouble getting it to work on a Xen hvm guest. The device happens to
>> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
>> > works fine in a Xen guest when I switch the device's=A0code to force
>> > usage of legacy interrupts with upstream QEMU. With MSI based
>> > interrupts, the device works fine on a KVM guest but as stated before,
>> > not on a Xen guest. After digging a bit, it appears, the reason for
>> > the failure in Xen guests is that the MSI data register in the Xen
>> > guest ends up with a value of 4300 where the Deliver Mode value of 3
>> > happens to be reserved (per spec) and therefore illegal. The
>> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
>> > illegal (per expectation) causing all commands issued by the guest OS
>> > on the device to timeout.
>> >
>> > Given this above scenario, I was wondering if anyone can shed some
>> > light on how to debug this further for Xen. Something I would
>> > specifically like to know is where the MSI data register configuration
>> > actually happens. Is it done by some code specific to Xen and within
>> > the Xen codebase or it all done within QEMU?
>> >
>>
>> This seems like the same issue I ran into, though in my case it is
>> with passed through physical devices. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
>> the older messages in that thread for more info on what's going on. No
>> fix yet but help debugging is very welcome.
>
> Thanks Rolu for pointing out the other thread - it was very useful.
> Some of the symptoms appear to be identical in my case. However, I am
> not using a pass-through device. Instead, in my case it's a fully
> virtualized device pretty much identical to a raw file backed disk
> image where the controller is pvscsi rather than lsi. Therefore I
> guess some of the latter discussion in the other thread around
> pass-through specific areas of code in qemu are not relevant? Please
> correct me if I am wrong. Also note that I am using upstream qemu
> where neither the #define for PT_PCI_MSITRANSLATE_DEFAULT nor
> xenstore.c exsits (which is where Stefano's suggested change appeared
> to be).
>
> So far, here's what I am observing in the hvm linux guest :
>
> On the guest side, as discussed in the other thread,
> xen_hvm_setup_msi_irqs is invoked for the device and a value of 0x4300
> is being by xen_msi_compose_msg that is written in the data register.
> On the qemu (upstream) side, when the virtualized controller is trying
> to complete a request, it's invoking the following chain of calls ->
> stl_le_phys -> xen_apic_mem_write -> xen_hvm_inject_msi
> On the xen side, this ends up in: hvmop_inject_msi -> hvm_inject_msi
> -> vmsi_deliver. vmsi_deliver, as previously discussed, rejects the
> delivery mode of 0x3.
>
> Is the above sequence of interactions the expected path for a HVM
> guest trying to use a fully virtualized device/controller that uses
> MSI in upstream qemu? If so, if a standard linux guest always
> populates the value of 0x4300 in the MSI data register through
> xen_hvm_setup_msi_irqs, how are MSI notifications from a device in
> qemu supposed to work given the delivery type of 0x3 is indeed
> reserved and bypass the the vmsi_deliver check?
>
> Thanks,
> Deep

I wanted to see whether the HVM guest can interact with the MSI
virtualized controller properly without any of the Xen-specific code
in the linux kernel kicking in (i.e. allowing the regular PCI/MSI code
in linux to fire). So I rebuilt the kernel with CONFIG_XEN disabled
such that pci_xen_hvm_init no longer sets x86_msi.*msi_irqs to xen
specific routines like xen_hvm_setup_msi_irqs which is where the
0x4300 is getting populated. This seems to work properly. The MSI data
register for the controller ends up getting a valid value like 0x4049,
vmsi_deliver no longer complains, all MSI notifications are delivered
in the expected way to the guest and the raw, file-backed disks
attached to the controller showing up in fdisk -l.

My conclusion: the linux kernel's xen specific code, specifically
routines like xen_hvm_setup_msi_irqs, need to be tweaked to work with
fully virtualized qemu devices that use MSI. I will follow-up
regarding that on LKML.

Thanks,
Deep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:00:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21: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 1SkLom-000773-11; Thu, 28 Jun 2012 21:00:00 +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 1SkLok-00076x-Pa
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 20:59:59 +0000
Received: from [85.158.138.51:19209] by server-7.bemta-3.messagelabs.com id
	55/C8-10113-DC5CCEF4; Thu, 28 Jun 2012 20:59:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340917195!30159930!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjA5Nzg0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11151 invoked from network); 28 Jun 2012 20:59:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 20:59:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5SKxrmS000324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Jun 2012 20:59:54 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
	q5SKxqmB003574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Jun 2012 20:59:53 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
	q5SKxqm1031984; Thu, 28 Jun 2012 15:59:52 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 13:59:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ACD0D4029A; Thu, 28 Jun 2012 16:52:03 -0400 (EDT)
Date: Thu, 28 Jun 2012 16:52:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Rolu <rolu@roce.org>
Message-ID: <20120628205203.GA25097@phenom.dumpdata.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Deep Debroy <ddebroy@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 26, 2012 at 04:51:29AM +0200, Rolu wrote:
> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> > Hi, I was playing around with a MSI capable virtual device (so far
> > submitted as patches only) in the upstream qemu tree but having
> > trouble getting it to work on a Xen hvm guest. The device happens to
> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
> > works fine in a Xen guest when I switch the device's=A0code to force
> > usage of legacy interrupts with upstream QEMU. With MSI based
> > interrupts, the device works fine on a KVM guest but as stated before,
> > not on a Xen guest. After digging a bit, it appears, the reason for
> > the failure in Xen guests is that the MSI data register in the Xen
> > guest ends up with a value of 4300 where the Deliver Mode value of 3
> > happens to be reserved (per spec) and therefore illegal. The
> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> > illegal (per expectation) causing all commands issued by the guest OS
> > on the device to timeout.
> >
> > Given this above scenario, I was wondering if anyone can shed some
> > light on how to debug this further for Xen. Something I would
> > specifically like to know is where the MSI data register configuration
> > actually happens. Is it done by some code specific to Xen and within
> > the Xen codebase or it all done within QEMU?
> >
> =

> This seems like the same issue I ran into, though in my case it is
> with passed through physical devices. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
> the older messages in that thread for more info on what's going on. No
> fix yet but help debugging is very welcome.

Huh? You said in http://lists.xen.org/archives/html/xen-devel/2012-06/msg01=
653.html
"This worked!"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:00:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21: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 1SkLom-000773-11; Thu, 28 Jun 2012 21:00:00 +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 1SkLok-00076x-Pa
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 20:59:59 +0000
Received: from [85.158.138.51:19209] by server-7.bemta-3.messagelabs.com id
	55/C8-10113-DC5CCEF4; Thu, 28 Jun 2012 20:59:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340917195!30159930!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjA5Nzg0\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11151 invoked from network); 28 Jun 2012 20:59:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jun 2012 20:59:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5SKxrmS000324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Jun 2012 20:59:54 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
	q5SKxqmB003574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Jun 2012 20:59:53 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
	q5SKxqm1031984; Thu, 28 Jun 2012 15:59:52 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 13:59:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ACD0D4029A; Thu, 28 Jun 2012 16:52:03 -0400 (EDT)
Date: Thu, 28 Jun 2012 16:52:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Rolu <rolu@roce.org>
Message-ID: <20120628205203.GA25097@phenom.dumpdata.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Deep Debroy <ddebroy@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 26, 2012 at 04:51:29AM +0200, Rolu wrote:
> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> > Hi, I was playing around with a MSI capable virtual device (so far
> > submitted as patches only) in the upstream qemu tree but having
> > trouble getting it to work on a Xen hvm guest. The device happens to
> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
> > works fine in a Xen guest when I switch the device's=A0code to force
> > usage of legacy interrupts with upstream QEMU. With MSI based
> > interrupts, the device works fine on a KVM guest but as stated before,
> > not on a Xen guest. After digging a bit, it appears, the reason for
> > the failure in Xen guests is that the MSI data register in the Xen
> > guest ends up with a value of 4300 where the Deliver Mode value of 3
> > happens to be reserved (per spec) and therefore illegal. The
> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> > illegal (per expectation) causing all commands issued by the guest OS
> > on the device to timeout.
> >
> > Given this above scenario, I was wondering if anyone can shed some
> > light on how to debug this further for Xen. Something I would
> > specifically like to know is where the MSI data register configuration
> > actually happens. Is it done by some code specific to Xen and within
> > the Xen codebase or it all done within QEMU?
> >
> =

> This seems like the same issue I ran into, though in my case it is
> with passed through physical devices. See
> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
> the older messages in that thread for more info on what's going on. No
> fix yet but help debugging is very welcome.

Huh? You said in http://lists.xen.org/archives/html/xen-devel/2012-06/msg01=
653.html
"This worked!"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:26:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkME2-0007aJ-Ex; Thu, 28 Jun 2012 21:26:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1SkME1-0007a9-4v
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 21:26:05 +0000
Received: from [85.158.143.35:4011] by server-3.bemta-4.messagelabs.com id
	F9/58-05808-CEBCCEF4; Thu, 28 Jun 2012 21:26:04 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340918763!4659868!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19088 invoked from network); 28 Jun 2012 21:26:03 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 21:26:03 -0000
Received: by bkwj10 with SMTP id j10so2777910bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 14:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=V+QjP2bX+pxGPR4U3q/AgRRiW8u+5lnKlGkfRsmXPa0=;
	b=url+zk8vkuA7L7FAWZTFJAaJUBNeUIWaul4hIjIoVKffEnevT5RJTsbP8wrAGgDbzX
	hc70+jO8D5GB3G78/PubLDWhLYuoaxSep9Bixtb9Q+8QXyyJbwY8TG/1pM2cZBPjVNk4
	fsNpL1hFmnSSRq0V0QF6BcScl5PYukG65ImZndVmmSvd/iB+e7f1IQLiWE3bhWM+8HeW
	gWd8bqgDIo+j6bDwaEsNgX/eJmEu4PclVRMnIlff30UQC7Z32GWqUHaLINgpETO09s6P
	99thdxTD0y8AjB1+UNVEdX/f7iIDO6i1Lv5lHJOYHRnmACbm59Rerg6DF0gI2aECNmev
	og+g==
MIME-Version: 1.0
Received: by 10.152.131.68 with SMTP id ok4mr3785304lab.47.1340918763064; Thu,
	28 Jun 2012 14:26:03 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Thu, 28 Jun 2012 14:26:03 -0700 (PDT)
In-Reply-To: <20120628205203.GA25097@phenom.dumpdata.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<20120628205203.GA25097@phenom.dumpdata.com>
Date: Thu, 28 Jun 2012 14:26:03 -0700
Message-ID: <CABg=H3NU6Nqb-f=0k+AsxOf6+oU3sagxGY0djCPGS9B4ghZU8A@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Rolu <rolu@roce.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 28, 2012 at 1:52 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jun 26, 2012 at 04:51:29AM +0200, Rolu wrote:
>> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
>> > Hi, I was playing around with a MSI capable virtual device (so far
>> > submitted as patches only) in the upstream qemu tree but having
>> > trouble getting it to work on a Xen hvm guest. The device happens to
>> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
>> > works fine in a Xen guest when I switch the device's=A0code to force
>> > usage of legacy interrupts with upstream QEMU. With MSI based
>> > interrupts, the device works fine on a KVM guest but as stated before,
>> > not on a Xen guest. After digging a bit, it appears, the reason for
>> > the failure in Xen guests is that the MSI data register in the Xen
>> > guest ends up with a value of 4300 where the Deliver Mode value of 3
>> > happens to be reserved (per spec) and therefore illegal. The
>> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
>> > illegal (per expectation) causing all commands issued by the guest OS
>> > on the device to timeout.
>> >
>> > Given this above scenario, I was wondering if anyone can shed some
>> > light on how to debug this further for Xen. Something I would
>> > specifically like to know is where the MSI data register configuration
>> > actually happens. Is it done by some code specific to Xen and within
>> > the Xen codebase or it all done within QEMU?
>> >
>>
>> This seems like the same issue I ran into, though in my case it is
>> with passed through physical devices. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
>> the older messages in that thread for more info on what's going on. No
>> fix yet but help debugging is very welcome.
>
> Huh? You said in http://lists.xen.org/archives/html/xen-devel/2012-06/msg=
01653.html
> "This worked!"

Hi Konrad, I believe Rolu's response in the thread you pointed to was
with respect to pass-through devices. This current thread is not about
pass-through devices but for a fully virtualized qemu device -
specifically a disk controller that is exposing raw-image backed files
from the host the guest as disks, very similar to the default LSI scsi
controller in qemu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:26:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkME2-0007aJ-Ex; Thu, 28 Jun 2012 21:26:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ddebroy@gmail.com>) id 1SkME1-0007a9-4v
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 21:26:05 +0000
Received: from [85.158.143.35:4011] by server-3.bemta-4.messagelabs.com id
	F9/58-05808-CEBCCEF4; Thu, 28 Jun 2012 21:26:04 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340918763!4659868!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19088 invoked from network); 28 Jun 2012 21:26:03 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 21:26:03 -0000
Received: by bkwj10 with SMTP id j10so2777910bkw.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 14:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=V+QjP2bX+pxGPR4U3q/AgRRiW8u+5lnKlGkfRsmXPa0=;
	b=url+zk8vkuA7L7FAWZTFJAaJUBNeUIWaul4hIjIoVKffEnevT5RJTsbP8wrAGgDbzX
	hc70+jO8D5GB3G78/PubLDWhLYuoaxSep9Bixtb9Q+8QXyyJbwY8TG/1pM2cZBPjVNk4
	fsNpL1hFmnSSRq0V0QF6BcScl5PYukG65ImZndVmmSvd/iB+e7f1IQLiWE3bhWM+8HeW
	gWd8bqgDIo+j6bDwaEsNgX/eJmEu4PclVRMnIlff30UQC7Z32GWqUHaLINgpETO09s6P
	99thdxTD0y8AjB1+UNVEdX/f7iIDO6i1Lv5lHJOYHRnmACbm59Rerg6DF0gI2aECNmev
	og+g==
MIME-Version: 1.0
Received: by 10.152.131.68 with SMTP id ok4mr3785304lab.47.1340918763064; Thu,
	28 Jun 2012 14:26:03 -0700 (PDT)
Received: by 10.114.62.78 with HTTP; Thu, 28 Jun 2012 14:26:03 -0700 (PDT)
In-Reply-To: <20120628205203.GA25097@phenom.dumpdata.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<20120628205203.GA25097@phenom.dumpdata.com>
Date: Thu, 28 Jun 2012 14:26:03 -0700
Message-ID: <CABg=H3NU6Nqb-f=0k+AsxOf6+oU3sagxGY0djCPGS9B4ghZU8A@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Rolu <rolu@roce.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 28, 2012 at 1:52 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jun 26, 2012 at 04:51:29AM +0200, Rolu wrote:
>> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
>> > Hi, I was playing around with a MSI capable virtual device (so far
>> > submitted as patches only) in the upstream qemu tree but having
>> > trouble getting it to work on a Xen hvm guest. The device happens to
>> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
>> > works fine in a Xen guest when I switch the device's=A0code to force
>> > usage of legacy interrupts with upstream QEMU. With MSI based
>> > interrupts, the device works fine on a KVM guest but as stated before,
>> > not on a Xen guest. After digging a bit, it appears, the reason for
>> > the failure in Xen guests is that the MSI data register in the Xen
>> > guest ends up with a value of 4300 where the Deliver Mode value of 3
>> > happens to be reserved (per spec) and therefore illegal. The
>> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
>> > illegal (per expectation) causing all commands issued by the guest OS
>> > on the device to timeout.
>> >
>> > Given this above scenario, I was wondering if anyone can shed some
>> > light on how to debug this further for Xen. Something I would
>> > specifically like to know is where the MSI data register configuration
>> > actually happens. Is it done by some code specific to Xen and within
>> > the Xen codebase or it all done within QEMU?
>> >
>>
>> This seems like the same issue I ran into, though in my case it is
>> with passed through physical devices. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
>> the older messages in that thread for more info on what's going on. No
>> fix yet but help debugging is very welcome.
>
> Huh? You said in http://lists.xen.org/archives/html/xen-devel/2012-06/msg=
01653.html
> "This worked!"

Hi Konrad, I believe Rolu's response in the thread you pointed to was
with respect to pass-through devices. This current thread is not about
pass-through devices but for a fully virtualized qemu device -
specifically a disk controller that is exposing raw-image backed files
from the host the guest as disks, very similar to the default LSI scsi
controller in qemu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkMFR-0007hD-6O; Thu, 28 Jun 2012 21:27:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkMFP-0007gy-CD
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 21:27:31 +0000
Received: from [85.158.143.35:8730] by server-3.bemta-4.messagelabs.com id
	5E/E8-05808-24CCCEF4; Thu, 28 Jun 2012 21:27:30 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340918848!13185399!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4150 invoked from network); 28 Jun 2012 21:27:29 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 21:27:29 -0000
Received: by yenl1 with SMTP id l1so2651197yen.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 14:27:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=yomklQOmPOGPctWTZlqANiQVLEyTB7L34bMcsrpwE0k=;
	b=CIWBLvOt9K6oE+6CY/RFoxkOveOIuv/mHvQ4jtVrYxT+STmavbJmgRSJJOdsU/BbPS
	FECp1jnIgNDoMG02ZNtpAnL0RgiR75hOB76PLZiW/BrCNA2InK3d3WBzPjK3vJ+Y+KNP
	yejwIBAwmuWpJU++cjrovNi1uomgCgyILAw5Uuk2bit0oW+hFDeLb2/S42Ax8SGVVi8X
	Hv0bZyMto/pthCDnlrx1js4norZ/pwSNvhajGo4/GWLOiKz60R6xaZTY6Ph3OvwJNRGW
	Uu+njSY5gJR8Awrgo71UjAnsTySCkkxpC0wMMgHJYtfPLvsvPetwQ/LtoMUpaEPPW8Wu
	MXzg==
Received: by 10.50.171.41 with SMTP id ar9mr731185igc.56.1340918848145; Thu,
	28 Jun 2012 14:27:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Thu, 28 Jun 2012 14:27:08 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <20120628205203.GA25097@phenom.dumpdata.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<20120628205203.GA25097@phenom.dumpdata.com>
From: Rolu <rolu@roce.org>
Date: Thu, 28 Jun 2012 23:27:08 +0200
Message-ID: <CABs9Ej=v9+XAYckRKE9FK6UrO6bHFm+QfuX9pFjEWJA20oFyfw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Gm-Message-State: ALoCoQm0TC3kEhE8I7DxH1MfVdRuFpfyODcBkJUrfTVMGJjeJi6i3oQpgZOn4sk5T7Z3NriEuAGP
Cc: Deep Debroy <ddebroy@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 28, 2012 at 10:52 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jun 26, 2012 at 04:51:29AM +0200, Rolu wrote:
>> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
>> > Hi, I was playing around with a MSI capable virtual device (so far
>> > submitted as patches only) in the upstream qemu tree but having
>> > trouble getting it to work on a Xen hvm guest. The device happens to
>> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
>> > works fine in a Xen guest when I switch the device's=A0code to force
>> > usage of legacy interrupts with upstream QEMU. With MSI based
>> > interrupts, the device works fine on a KVM guest but as stated before,
>> > not on a Xen guest. After digging a bit, it appears, the reason for
>> > the failure in Xen guests is that the MSI data register in the Xen
>> > guest ends up with a value of 4300 where the Deliver Mode value of 3
>> > happens to be reserved (per spec) and therefore illegal. The
>> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
>> > illegal (per expectation) causing all commands issued by the guest OS
>> > on the device to timeout.
>> >
>> > Given this above scenario, I was wondering if anyone can shed some
>> > light on how to debug this further for Xen. Something I would
>> > specifically like to know is where the MSI data register configuration
>> > actually happens. Is it done by some code specific to Xen and within
>> > the Xen codebase or it all done within QEMU?
>> >
>>
>> This seems like the same issue I ran into, though in my case it is
>> with passed through physical devices. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
>> the older messages in that thread for more info on what's going on. No
>> fix yet but help debugging is very welcome.
>
> Huh? You said in http://lists.xen.org/archives/html/xen-devel/2012-06/msg=
01653.html
> "This worked!"

That's a day and a half later.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkMFR-0007hD-6O; Thu, 28 Jun 2012 21:27:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkMFP-0007gy-CD
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 21:27:31 +0000
Received: from [85.158.143.35:8730] by server-3.bemta-4.messagelabs.com id
	5E/E8-05808-24CCCEF4; Thu, 28 Jun 2012 21:27:30 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1340918848!13185399!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4150 invoked from network); 28 Jun 2012 21:27:29 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 21:27:29 -0000
Received: by yenl1 with SMTP id l1so2651197yen.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 14:27:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=yomklQOmPOGPctWTZlqANiQVLEyTB7L34bMcsrpwE0k=;
	b=CIWBLvOt9K6oE+6CY/RFoxkOveOIuv/mHvQ4jtVrYxT+STmavbJmgRSJJOdsU/BbPS
	FECp1jnIgNDoMG02ZNtpAnL0RgiR75hOB76PLZiW/BrCNA2InK3d3WBzPjK3vJ+Y+KNP
	yejwIBAwmuWpJU++cjrovNi1uomgCgyILAw5Uuk2bit0oW+hFDeLb2/S42Ax8SGVVi8X
	Hv0bZyMto/pthCDnlrx1js4norZ/pwSNvhajGo4/GWLOiKz60R6xaZTY6Ph3OvwJNRGW
	Uu+njSY5gJR8Awrgo71UjAnsTySCkkxpC0wMMgHJYtfPLvsvPetwQ/LtoMUpaEPPW8Wu
	MXzg==
Received: by 10.50.171.41 with SMTP id ar9mr731185igc.56.1340918848145; Thu,
	28 Jun 2012 14:27:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Thu, 28 Jun 2012 14:27:08 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <20120628205203.GA25097@phenom.dumpdata.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<20120628205203.GA25097@phenom.dumpdata.com>
From: Rolu <rolu@roce.org>
Date: Thu, 28 Jun 2012 23:27:08 +0200
Message-ID: <CABs9Ej=v9+XAYckRKE9FK6UrO6bHFm+QfuX9pFjEWJA20oFyfw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Gm-Message-State: ALoCoQm0TC3kEhE8I7DxH1MfVdRuFpfyODcBkJUrfTVMGJjeJi6i3oQpgZOn4sk5T7Z3NriEuAGP
Cc: Deep Debroy <ddebroy@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
	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="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, Jun 28, 2012 at 10:52 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Jun 26, 2012 at 04:51:29AM +0200, Rolu wrote:
>> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
>> > Hi, I was playing around with a MSI capable virtual device (so far
>> > submitted as patches only) in the upstream qemu tree but having
>> > trouble getting it to work on a Xen hvm guest. The device happens to
>> > be a QEMU implementation of VMWare's pvscsi controller.=A0The device
>> > works fine in a Xen guest when I switch the device's=A0code to force
>> > usage of legacy interrupts with upstream QEMU. With MSI based
>> > interrupts, the device works fine on a KVM guest but as stated before,
>> > not on a Xen guest. After digging a bit, it appears, the reason for
>> > the failure in Xen guests is that the MSI data register in the Xen
>> > guest ends up with a value of 4300 where the Deliver Mode value of 3
>> > happens to be reserved (per spec) and therefore illegal. The
>> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
>> > illegal (per expectation) causing all commands issued by the guest OS
>> > on the device to timeout.
>> >
>> > Given this above scenario, I was wondering if anyone can shed some
>> > light on how to debug this further for Xen. Something I would
>> > specifically like to know is where the MSI data register configuration
>> > actually happens. Is it done by some code specific to Xen and within
>> > the Xen codebase or it all done within QEMU?
>> >
>>
>> This seems like the same issue I ran into, though in my case it is
>> with passed through physical devices. See
>> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
>> the older messages in that thread for more info on what's going on. No
>> fix yet but help debugging is very welcome.
>
> Huh? You said in http://lists.xen.org/archives/html/xen-devel/2012-06/msg=
01653.html
> "This worked!"

That's a day and a half later.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:46:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21:46: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 1SkMXu-000872-V8; Thu, 28 Jun 2012 21:46:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkMXt-00086x-Fr
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 21:46:37 +0000
Received: from [85.158.139.83:62416] by server-7.bemta-5.messagelabs.com id
	8C/A5-28276-CB0DCEF4; Thu, 28 Jun 2012 21:46:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340919995!22833573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8231 invoked from network); 28 Jun 2012 21:46:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 21:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,494,1336348800"; d="scan'208";a="13279072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 21: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.213.0; Thu, 28 Jun 2012 22:46:35 +0100
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 1SkMXr-0003N3-0u;
	Thu, 28 Jun 2012 21: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 1SkMXq-00043I-Qm;
	Thu, 28 Jun 2012 22:46:34 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13384-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 22:46:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13384: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13384 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13384/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build     fail in 13382 REGR. vs. 13338
 build-amd64-oldkern           4 xen-build        fail in 13382 REGR. vs. 13338
 build-amd64                   4 xen-build        fail in 13382 REGR. vs. 13338

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13381
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10      fail pass in 13382
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13381 pass in 13384

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13381 like 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win  13 guest-stop            fail in 13381 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)  blocked in 13382 n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)  blocked in 13382 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)       blocked in 13382 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)    blocked in 13382 n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)        blocked in 13382 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)        blocked in 13382 n/a

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 21:46:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 21:46: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 1SkMXu-000872-V8; Thu, 28 Jun 2012 21:46:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkMXt-00086x-Fr
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 21:46:37 +0000
Received: from [85.158.139.83:62416] by server-7.bemta-5.messagelabs.com id
	8C/A5-28276-CB0DCEF4; Thu, 28 Jun 2012 21:46:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340919995!22833573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDMzNDk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8231 invoked from network); 28 Jun 2012 21:46:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 21:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,494,1336348800"; d="scan'208";a="13279072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jun 2012 21: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.213.0; Thu, 28 Jun 2012 22:46:35 +0100
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 1SkMXr-0003N3-0u;
	Thu, 28 Jun 2012 21: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 1SkMXq-00043I-Qm;
	Thu, 28 Jun 2012 22:46:34 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13384-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Jun 2012 22:46:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13384: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13384 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13384/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build     fail in 13382 REGR. vs. 13338
 build-amd64-oldkern           4 xen-build        fail in 13382 REGR. vs. 13338
 build-amd64                   4 xen-build        fail in 13382 REGR. vs. 13338

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 13381
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10      fail pass in 13382
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13381 pass in 13384

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 13381 like 13338

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win  13 guest-stop            fail in 13381 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)  blocked in 13382 n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)  blocked in 13382 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-amd64-xl-qemuu-win  1 xen-build-check(1)       blocked in 13382 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)    blocked in 13382 n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)        blocked in 13382 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1) blocked in 13382 n/a
 test-amd64-amd64-qemuu-win    1 xen-build-check(1)        blocked in 13382 n/a

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit dbaf62769e1bfa7636208a4f00ea2331f5c40685
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Jun 27 12:49:50 2012 +0000

    Fix backport error introduced by f1cf76785270ebc9798c82ad5f7419129bde7e56
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 23:13:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 23:13: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 1SkNtb-0000ZC-0G; Thu, 28 Jun 2012 23:13:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkNtY-0000Z7-Qj
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 23:13:05 +0000
Received: from [85.158.138.51:49297] by server-10.bemta-3.messagelabs.com id
	CA/52-01753-BF4ECEF4; Thu, 28 Jun 2012 23:12:59 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340925177!21186162!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 28 Jun 2012 23:12:58 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 23:12:58 -0000
Received: by obbta14 with SMTP id ta14so4820875obb.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 16:12:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=ViHMbcwE9zeLEjFuyTgSwUus7DM2phZFhPZQapow1U0=;
	b=hjwjhTHGN8inCnv8ayPoD0SEdKoqmp0necrW9miiMTHov+7bWrOzLVk33VmkCLuB+7
	UsJYk6Uc+LCKECKkJuhMuWN4eAIgCQh2/MSihIv2zcPRM5teNGiCS/nwhogJ/1IMEw7i
	xOn3BUNLmdRhNEbL/DmM5A9HiOPYAsOP/BJs7p4ZtkwG6baD6imVg1tX5zISelWzHdl/
	RPnZWQfY/qe8HmIC9B0H9oseYs7F3QJmIaJrywGiQA8csMtnFNVp+FGFTnHLPSNHZ7UO
	c/bpUPPqAyDLdl3f8Hn/8P30WQMK2Pkfv2Dk8EH8FMAp1fRj3/d+vi7ttkgaNsBi+f42
	aj8Q==
Received: by 10.50.187.200 with SMTP id fu8mr73838igc.6.1340925177228; Thu, 28
	Jun 2012 16:12:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Thu, 28 Jun 2012 16:12:36 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Fri, 29 Jun 2012 01:12:36 +0200
Message-ID: <CABs9EjkNahhM0Ua=defNR+WVsEbj5k_HZLzfO5m0EHQTC8+xDw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQneuLubAhw/8D4a1fQfwg0ouO1/5TxsAfFMPXRdH27I7aRX07ryWpv/9q9ztJBeaG1aGgvL
Subject: [Xen-devel] A question about PCI passthrough device BAR memory 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

I am passing through to a domU (among other things) two USB
controllers. Here is the lspci -v output on the dom0:

00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced
Host Controller #1 (rev 04) (prog-if 20 [EHCI])
	Subsystem: ASRock Incorporation Device 1e26
	Flags: bus master, medium devsel, latency 0, IRQ 23
	Memory at f7d17000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
	Kernel driver in use: pciback

And here is the same device's output in the domU:

00:07.0 USB controller: Intel Corporation Panther Point USB Enhanced
Host Controller #1 (rev 04) (prog-if 20 [EHCI])
	Subsystem: ASRock Incorporation Device 1e26
	Flags: bus master, medium devsel, latency 64, IRQ 44
	Memory at f3056000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [50] Power Management version 2
	Kernel driver in use: ehci_hcd

The output for the other controller is essentially the same.

The peculiar thing here is that the domU thinks it has a 4K memory
area while the dom0 says it's just 1K. The controllers work, and I
don't know enough about the PCI subsystems to say if this could cause
issues, but it seems things could go wrong if the domU ever decides to
use the other 3K of memory.

I had a look at how this value was calculated. I found that the guest
will write all ones to the BAR and then reads it, and the size of the
memory area is determined by how many bits come back as zero (per the
PCI specs). In qemu, in hw/pass-through.c, pt_bar_reg_write and
pt_bar_reg_read are responsible for emulating the writing and reading.
In pt_bar_reg_read, there is:

/* align resource size (memory type only) */
PT_GET_EMUL_SIZE(base->bar_flag, r_size);

For memory type BAR this macro changes r_size to:

(((r_size) + XC_PAGE_SIZE - 1) & ~(XC_PAGE_SIZE - 1));

This looks like it rounds r_size up to the next multiple of
XC_PAGE_SIZE, and logging confirms this is changing r_size from 0x400
to 0x1000. This ends up giving the guest the rounded up size, instead
of the real size.

So,
* is this an actual potential problem, or will something else ensure
that the guest isn't going to try to use the extra memory?
* if it needs fixing, how can it be done? I've looked through the code
but I'm not sure how to fix it without breaking other things.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 23:13:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 23:13: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 1SkNtb-0000ZC-0G; Thu, 28 Jun 2012 23:13:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkNtY-0000Z7-Qj
	for xen-devel@lists.xen.org; Thu, 28 Jun 2012 23:13:05 +0000
Received: from [85.158.138.51:49297] by server-10.bemta-3.messagelabs.com id
	CA/52-01753-BF4ECEF4; Thu, 28 Jun 2012 23:12:59 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340925177!21186162!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 28 Jun 2012 23:12:58 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jun 2012 23:12:58 -0000
Received: by obbta14 with SMTP id ta14so4820875obb.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 16:12:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:from:date:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=ViHMbcwE9zeLEjFuyTgSwUus7DM2phZFhPZQapow1U0=;
	b=hjwjhTHGN8inCnv8ayPoD0SEdKoqmp0necrW9miiMTHov+7bWrOzLVk33VmkCLuB+7
	UsJYk6Uc+LCKECKkJuhMuWN4eAIgCQh2/MSihIv2zcPRM5teNGiCS/nwhogJ/1IMEw7i
	xOn3BUNLmdRhNEbL/DmM5A9HiOPYAsOP/BJs7p4ZtkwG6baD6imVg1tX5zISelWzHdl/
	RPnZWQfY/qe8HmIC9B0H9oseYs7F3QJmIaJrywGiQA8csMtnFNVp+FGFTnHLPSNHZ7UO
	c/bpUPPqAyDLdl3f8Hn/8P30WQMK2Pkfv2Dk8EH8FMAp1fRj3/d+vi7ttkgaNsBi+f42
	aj8Q==
Received: by 10.50.187.200 with SMTP id fu8mr73838igc.6.1340925177228; Thu, 28
	Jun 2012 16:12:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Thu, 28 Jun 2012 16:12:36 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
From: Rolu <rolu@roce.org>
Date: Fri, 29 Jun 2012 01:12:36 +0200
Message-ID: <CABs9EjkNahhM0Ua=defNR+WVsEbj5k_HZLzfO5m0EHQTC8+xDw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQneuLubAhw/8D4a1fQfwg0ouO1/5TxsAfFMPXRdH27I7aRX07ryWpv/9q9ztJBeaG1aGgvL
Subject: [Xen-devel] A question about PCI passthrough device BAR memory 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

I am passing through to a domU (among other things) two USB
controllers. Here is the lspci -v output on the dom0:

00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced
Host Controller #1 (rev 04) (prog-if 20 [EHCI])
	Subsystem: ASRock Incorporation Device 1e26
	Flags: bus master, medium devsel, latency 0, IRQ 23
	Memory at f7d17000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
	Kernel driver in use: pciback

And here is the same device's output in the domU:

00:07.0 USB controller: Intel Corporation Panther Point USB Enhanced
Host Controller #1 (rev 04) (prog-if 20 [EHCI])
	Subsystem: ASRock Incorporation Device 1e26
	Flags: bus master, medium devsel, latency 64, IRQ 44
	Memory at f3056000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [50] Power Management version 2
	Kernel driver in use: ehci_hcd

The output for the other controller is essentially the same.

The peculiar thing here is that the domU thinks it has a 4K memory
area while the dom0 says it's just 1K. The controllers work, and I
don't know enough about the PCI subsystems to say if this could cause
issues, but it seems things could go wrong if the domU ever decides to
use the other 3K of memory.

I had a look at how this value was calculated. I found that the guest
will write all ones to the BAR and then reads it, and the size of the
memory area is determined by how many bits come back as zero (per the
PCI specs). In qemu, in hw/pass-through.c, pt_bar_reg_write and
pt_bar_reg_read are responsible for emulating the writing and reading.
In pt_bar_reg_read, there is:

/* align resource size (memory type only) */
PT_GET_EMUL_SIZE(base->bar_flag, r_size);

For memory type BAR this macro changes r_size to:

(((r_size) + XC_PAGE_SIZE - 1) & ~(XC_PAGE_SIZE - 1));

This looks like it rounds r_size up to the next multiple of
XC_PAGE_SIZE, and logging confirms this is changing r_size from 0x400
to 0x1000. This ends up giving the guest the rounded up size, instead
of the real size.

So,
* is this an actual potential problem, or will something else ensure
that the guest isn't going to try to use the extra memory?
* if it needs fixing, how can it be done? I've looked through the code
but I'm not sure how to fix it without breaking other things.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 23:56:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 23: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 1SkOZ1-0000vw-GC; Thu, 28 Jun 2012 23:55:55 +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 1SkOZ0-0000vr-Nf
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 23:55:54 +0000
Received: from [85.158.143.99:63603] by server-1.bemta-4.messagelabs.com id
	A1/40-24392-90FECEF4; Thu, 28 Jun 2012 23:55:53 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340927752!21977866!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11429 invoked from network); 28 Jun 2012 23:55:53 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-11.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 23:55:53 -0000
Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net
	[74.93.104.98])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 7EBDC584AB1;
	Thu, 28 Jun 2012 16:55:51 -0700 (PDT)
Date: Thu, 28 Jun 2012 16:55:50 -0700 (PDT)
Message-Id: <20120628.165550.1816352825092253548.davem@davemloft.net>
To: annie.li@oracle.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
References: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
X-Mailer: Mew version 6.5 on Emacs 24.0.97 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: kurt.hackel@oracle.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: annie.li@oracle.com
Date: Wed, 27 Jun 2012 18:46:58 +0800

> From: Annie Li <Annie.li@oracle.com>
> 
> After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
> However, no dequeue action is called in this situation, it is likely that
> tx_queue constains freed SKB. This patch should fix this issue, and it is
> based on 3.5.0-rc4+.
> 
> This issue is found through code inspection, no bug is seen with it currently.
> I run netperf test for several hours, and no network regression was found.
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>

I lack the expertiece necessary to properly review this, so I really
need a Xen expert to look this over.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Jun 28 23:56:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Jun 2012 23: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 1SkOZ1-0000vw-GC; Thu, 28 Jun 2012 23:55:55 +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 1SkOZ0-0000vr-Nf
	for xen-devel@lists.xensource.com; Thu, 28 Jun 2012 23:55:54 +0000
Received: from [85.158.143.99:63603] by server-1.bemta-4.messagelabs.com id
	A1/40-24392-90FECEF4; Thu, 28 Jun 2012 23:55:53 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-11.tower-216.messagelabs.com!1340927752!21977866!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11429 invoked from network); 28 Jun 2012 23:55:53 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-11.tower-216.messagelabs.com with SMTP;
	28 Jun 2012 23:55:53 -0000
Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net
	[74.93.104.98])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 7EBDC584AB1;
	Thu, 28 Jun 2012 16:55:51 -0700 (PDT)
Date: Thu, 28 Jun 2012 16:55:50 -0700 (PDT)
Message-Id: <20120628.165550.1816352825092253548.davem@davemloft.net>
To: annie.li@oracle.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
References: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
X-Mailer: Mew version 6.5 on Emacs 24.0.97 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: kurt.hackel@oracle.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: annie.li@oracle.com
Date: Wed, 27 Jun 2012 18:46:58 +0800

> From: Annie Li <Annie.li@oracle.com>
> 
> After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
> However, no dequeue action is called in this situation, it is likely that
> tx_queue constains freed SKB. This patch should fix this issue, and it is
> based on 3.5.0-rc4+.
> 
> This issue is found through code inspection, no bug is seen with it currently.
> I run netperf test for several hours, and no network regression was found.
> 
> Signed-off-by: Annie Li <annie.li@oracle.com>

I lack the expertiece necessary to properly review this, so I really
need a Xen expert to look this over.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 00:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 00:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkOlo-0001ge-R0; Fri, 29 Jun 2012 00:09:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkOln-0001gZ-7l
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 00:09:07 +0000
Received: from [193.109.254.147:4784] by server-10.bemta-14.messagelabs.com id
	CC/D8-05433-222FCEF4; Fri, 29 Jun 2012 00:09:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340928545!2298849!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24230 invoked from network); 29 Jun 2012 00:09:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 00:09:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,494,1336348800"; d="scan'208";a="13279912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 00:09:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 01:09:05 +0100
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 1SkOll-0004Bs-3d;
	Fri, 29 Jun 2012 00:09:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkOlk-00066s-Lb;
	Fri, 29 Jun 2012 01:09:04 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13385-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 01:09:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13385 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13385/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  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-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-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-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  0455d8317631
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 863 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 Jun 29 00:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 00:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkOlo-0001ge-R0; Fri, 29 Jun 2012 00:09:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkOln-0001gZ-7l
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 00:09:07 +0000
Received: from [193.109.254.147:4784] by server-10.bemta-14.messagelabs.com id
	CC/D8-05433-222FCEF4; Fri, 29 Jun 2012 00:09:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340928545!2298849!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24230 invoked from network); 29 Jun 2012 00:09:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 00:09:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,494,1336348800"; d="scan'208";a="13279912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 00:09:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 01:09:05 +0100
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 1SkOll-0004Bs-3d;
	Fri, 29 Jun 2012 00:09:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkOlk-00066s-Lb;
	Fri, 29 Jun 2012 01:09:04 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13385-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 01:09:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13385 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13385/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  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-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-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-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  0455d8317631
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 863 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 Jun 29 01:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01:00: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 1SkPZO-0004ey-2k; Fri, 29 Jun 2012 01:00:22 +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 1SkPZM-0004RE-OM
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 01:00:20 +0000
Received: from [85.158.143.35:23351] by server-2.bemta-4.messagelabs.com id
	1B/20-17938-42EFCEF4; Fri, 29 Jun 2012 01:00:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340931617!6819693!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEwOTU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25247 invoked from network); 29 Jun 2012 01:00:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 01:00:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5T10AON003045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 01:00:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5T109Vt022586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 01:00:10 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
	q5T109N7025942; Thu, 28 Jun 2012 20:00:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 18:00:08 -0700
Date: Thu, 28 Jun 2012 18:00:07 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628180007.06bb3fd3@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
level process, is running with XEN_EMULATE_PREFIX cpuid. I am
wondering if the prefix is statically put there, or how its put there?

For hybrid, the hvm container traps cpuid, so we don't need to prefix
cpuid. Less code if I don't have to worry about trapping the invalid
op. There seems places where the cpuid is run without the xen prefix in
user mode.

BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
just return cpuid values, as that's what would happen without the HVM
container.

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 Jun 29 01:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01:00: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 1SkPZO-0004ey-2k; Fri, 29 Jun 2012 01:00:22 +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 1SkPZM-0004RE-OM
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 01:00:20 +0000
Received: from [85.158.143.35:23351] by server-2.bemta-4.messagelabs.com id
	1B/20-17938-42EFCEF4; Fri, 29 Jun 2012 01:00:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340931617!6819693!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEwOTU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25247 invoked from network); 29 Jun 2012 01:00:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 01:00:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5T10AON003045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 01:00:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5T109Vt022586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 01:00:10 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
	q5T109N7025942; Thu, 28 Jun 2012 20:00:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 18:00:08 -0700
Date: Thu, 28 Jun 2012 18:00:07 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120628180007.06bb3fd3@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
level process, is running with XEN_EMULATE_PREFIX cpuid. I am
wondering if the prefix is statically put there, or how its put there?

For hybrid, the hvm container traps cpuid, so we don't need to prefix
cpuid. Less code if I don't have to worry about trapping the invalid
op. There seems places where the cpuid is run without the xen prefix in
user mode.

BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
just return cpuid values, as that's what would happen without the HVM
container.

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 Jun 29 01:17:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01: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 1SkPpY-0006FU-Mk; Fri, 29 Jun 2012 01:17: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 1SkPpX-0006FP-LC
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 01:17:03 +0000
Received: from [85.158.143.35:12891] by server-3.bemta-4.messagelabs.com id
	3E/17-05808-E020DEF4; Fri, 29 Jun 2012 01:17:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340932621!6821418!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEwOTU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2673 invoked from network); 29 Jun 2012 01:17:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 01:17:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5T1GtT8014380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 01:16:56 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
	q5T1GsHb025044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 01:16:55 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
	q5T1GsTg001763; Thu, 28 Jun 2012 20:16:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 18:16:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E65F74029A; Thu, 28 Jun 2012 21:09:03 -0400 (EDT)
Date: Thu, 28 Jun 2012 21:09:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120629010903.GC4902@phenom.dumpdata.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120628180007.06bb3fd3@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 06:00:07PM -0700, Mukesh Rathor wrote:
> Hi,
> 
> Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
> level process, is running with XEN_EMULATE_PREFIX cpuid. I am
> wondering if the prefix is statically put there, or how its put there?

That is impressive. It should be only be in the kernel via the pvops
cpuid call which does this:

 252         asm(XEN_EMULATE_PREFIX "cpuid"
 253                 : "=a" (*ax),
 254                   "=b" (*bx),
 255                   "=c" (*cx),
 256                   "=d" (*dx)
 257                 : "0" (*ax), "2" (*cx));
 258 


> 
> For hybrid, the hvm container traps cpuid, so we don't need to prefix
> cpuid. Less code if I don't have to worry about trapping the invalid
> op. There seems places where the cpuid is run without the xen prefix in
> user mode.

Right, you can make the .cpuid pvops call point to the native.

> 
> BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
> just return cpuid values, as that's what would happen without the HVM
> container.

You mean in PV mode in user-space you would get the unfiltered cpuid value?
Yes, that is true. Which is why I am surprised that dm_mapper (are you sure
it is not a kernel thread?) is doing that.

> 
> thanks,
> Mukesh
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 29 01:17:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01: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 1SkPpY-0006FU-Mk; Fri, 29 Jun 2012 01:17: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 1SkPpX-0006FP-LC
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 01:17:03 +0000
Received: from [85.158.143.35:12891] by server-3.bemta-4.messagelabs.com id
	3E/17-05808-E020DEF4; Fri, 29 Jun 2012 01:17:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340932621!6821418!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEwOTU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2673 invoked from network); 29 Jun 2012 01:17:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 01:17:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5T1GtT8014380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 01:16:56 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
	q5T1GsHb025044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 01:16:55 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
	q5T1GsTg001763; Thu, 28 Jun 2012 20:16:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 18:16:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E65F74029A; Thu, 28 Jun 2012 21:09:03 -0400 (EDT)
Date: Thu, 28 Jun 2012 21:09:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120629010903.GC4902@phenom.dumpdata.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120628180007.06bb3fd3@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 06:00:07PM -0700, Mukesh Rathor wrote:
> Hi,
> 
> Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
> level process, is running with XEN_EMULATE_PREFIX cpuid. I am
> wondering if the prefix is statically put there, or how its put there?

That is impressive. It should be only be in the kernel via the pvops
cpuid call which does this:

 252         asm(XEN_EMULATE_PREFIX "cpuid"
 253                 : "=a" (*ax),
 254                   "=b" (*bx),
 255                   "=c" (*cx),
 256                   "=d" (*dx)
 257                 : "0" (*ax), "2" (*cx));
 258 


> 
> For hybrid, the hvm container traps cpuid, so we don't need to prefix
> cpuid. Less code if I don't have to worry about trapping the invalid
> op. There seems places where the cpuid is run without the xen prefix in
> user mode.

Right, you can make the .cpuid pvops call point to the native.

> 
> BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
> just return cpuid values, as that's what would happen without the HVM
> container.

You mean in PV mode in user-space you would get the unfiltered cpuid value?
Yes, that is true. Which is why I am surprised that dm_mapper (are you sure
it is not a kernel thread?) is doing that.

> 
> thanks,
> Mukesh
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 29 01:26:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01: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 1SkPyS-0006On-Nm; Fri, 29 Jun 2012 01:26:16 +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 1SkPyR-0006Oi-Bs
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 01:26:15 +0000
Received: from [193.109.254.147:44571] by server-8.bemta-14.messagelabs.com id
	89/C5-30743-6340DEF4; Fri, 29 Jun 2012 01:26:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340933171!2256441!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEwOTU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27923 invoked from network); 29 Jun 2012 01:26:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 01:26:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5T1Q6BF019511
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 01:26:07 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
	q5T1Q6OL024616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 01:26:06 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
	q5T1Q53p016189; Thu, 28 Jun 2012 20:26:05 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 18:26:05 -0700
Date: Thu, 28 Jun 2012 18:26:02 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120628182602.6cc9b432@mantra.us.oracle.com>
In-Reply-To: <20120629010903.GC4902@phenom.dumpdata.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012 21:09:03 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Jun 28, 2012 at 06:00:07PM -0700, Mukesh Rathor wrote:
> > Hi,
> > 
> > Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
> > level process, is running with XEN_EMULATE_PREFIX cpuid. I am
> > wondering if the prefix is statically put there, or how its put
> > there?
> 
> That is impressive. It should be only be in the kernel via the pvops
> cpuid call which does this:
> 
>  252         asm(XEN_EMULATE_PREFIX "cpuid"
>  253                 : "=a" (*ax),
>  254                   "=b" (*bx),
>  255                   "=c" (*cx),
>  256                   "=d" (*dx)
>  257                 : "0" (*ax), "2" (*cx));
>  258 
> 
> 
> > 
> > For hybrid, the hvm container traps cpuid, so we don't need to
> > prefix cpuid. Less code if I don't have to worry about trapping the
> > invalid op. There seems places where the cpuid is run without the
> > xen prefix in user mode.
> 
> Right, you can make the .cpuid pvops call point to the native.

Yup. In the kernel I do that already.

> > 
> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user
> > mode, I just return cpuid values, as that's what would happen
> > without the HVM container.
> 
> You mean in PV mode in user-space you would get the unfiltered cpuid
> value? Yes, that is true. Which is why I am surprised that dm_mapper
> (are you sure it is not a kernel thread?) is doing that.

User mode:

RIP: 0x0000000000400692 CS: 0x0033

[0]xkdb> dd 0x0000000000400680 32 0
0000000000400680:  89f88953e5894855 db8500000000b9d3
0000000000400690:  0f6e65780b0f0574 4e89045e890689a2

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 Jun 29 01:26:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01: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 1SkPyS-0006On-Nm; Fri, 29 Jun 2012 01:26:16 +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 1SkPyR-0006Oi-Bs
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 01:26:15 +0000
Received: from [193.109.254.147:44571] by server-8.bemta-14.messagelabs.com id
	89/C5-30743-6340DEF4; Fri, 29 Jun 2012 01:26:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340933171!2256441!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEwOTU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27923 invoked from network); 29 Jun 2012 01:26:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 01:26:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5T1Q6BF019511
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 01:26:07 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
	q5T1Q6OL024616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 01:26:06 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
	q5T1Q53p016189; Thu, 28 Jun 2012 20:26:05 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Jun 2012 18:26:05 -0700
Date: Thu, 28 Jun 2012 18:26:02 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120628182602.6cc9b432@mantra.us.oracle.com>
In-Reply-To: <20120629010903.GC4902@phenom.dumpdata.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 Jun 2012 21:09:03 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Jun 28, 2012 at 06:00:07PM -0700, Mukesh Rathor wrote:
> > Hi,
> > 
> > Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
> > level process, is running with XEN_EMULATE_PREFIX cpuid. I am
> > wondering if the prefix is statically put there, or how its put
> > there?
> 
> That is impressive. It should be only be in the kernel via the pvops
> cpuid call which does this:
> 
>  252         asm(XEN_EMULATE_PREFIX "cpuid"
>  253                 : "=a" (*ax),
>  254                   "=b" (*bx),
>  255                   "=c" (*cx),
>  256                   "=d" (*dx)
>  257                 : "0" (*ax), "2" (*cx));
>  258 
> 
> 
> > 
> > For hybrid, the hvm container traps cpuid, so we don't need to
> > prefix cpuid. Less code if I don't have to worry about trapping the
> > invalid op. There seems places where the cpuid is run without the
> > xen prefix in user mode.
> 
> Right, you can make the .cpuid pvops call point to the native.

Yup. In the kernel I do that already.

> > 
> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user
> > mode, I just return cpuid values, as that's what would happen
> > without the HVM container.
> 
> You mean in PV mode in user-space you would get the unfiltered cpuid
> value? Yes, that is true. Which is why I am surprised that dm_mapper
> (are you sure it is not a kernel thread?) is doing that.

User mode:

RIP: 0x0000000000400692 CS: 0x0033

[0]xkdb> dd 0x0000000000400680 32 0
0000000000400680:  89f88953e5894855 db8500000000b9d3
0000000000400690:  0f6e65780b0f0574 4e89045e890689a2

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 Jun 29 01:43:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01:43: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 1SkQEI-0006iu-7N; Fri, 29 Jun 2012 01:42:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkQEG-0006ip-8L
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 01:42:36 +0000
Received: from [85.158.138.51:27691] by server-9.bemta-3.messagelabs.com id
	1B/FD-10419-B080DEF4; Fri, 29 Jun 2012 01:42:35 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340934153!22015404!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3609 invoked from network); 29 Jun 2012 01:42:34 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 01:42:34 -0000
Received: by ghrr14 with SMTP id r14so2775041ghr.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 18:42:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=D4inBqW/nO9xV004wvPpAiZzLppNkKlzEmDV6Z+23z4=;
	b=i20Ztf6LLud4eZ5RL9LiVNaeicxDKujkq+7FpraJl6QAjH25SlP0Yf9IQV1U758U+t
	v5IrlaruIJblVkXeaPITHTOrN1TojfHdLaUiZ6VerO993ukFaJr8kflgmKiagXdSCNLW
	4Zf/ooZxBFJnWzREHMPPpb+xYdDLfrvXGABZzgkFIF5z4VsqYenr1I3u/yEzXsDfvaRy
	j4ySNRYJt7qWj/kzBUzBOjGLvbOp/wQGtClFwxLPWXQpuI3fg9yLDu6A67JPNDSG5c9T
	v88+HfEqeLqi3hsdxF1SWP4xa8ac+NOfWFQlunA39t+2UOiRXmNZ4Uem/7jqUfOKk1Yi
	ErfQ==
Received: by 10.42.66.13 with SMTP id n13mr1450477ici.39.1340934152618; Thu,
	28 Jun 2012 18:42:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Thu, 28 Jun 2012 18:42:12 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
	<alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Fri, 29 Jun 2012 03:42:12 +0200
Message-ID: <CABs9Ejn1Z_skEnEfj9y51=NQ5b3yipq9F5o9BeP-LnfZnuo1Lw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQlUymSi0Pr58E3POx10mq5T0wnV+Wn1/js05FZiqsa9xnot2kDNxsWmu+4d1glNA+idDr1b
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 12:49 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 27 Jun 2012, Rolu wrote:
>> > That's because msitranslate is still enabled somehow, that is a
>> > toolstack bug.
>> > While we fix that bug, could you try this QEMU patch to forcefully disable
>> > msitranslate?
>> >
>>
>> This worked!
>>
>> The "unsupported delivery mode" message is gone. Sound works, although
>> there is still occasionally a very short stutter, but I expect that's
>> a different issue. I've been testing with a KDE desktop with 3D
>> effects (cube, expo, that sort of stuff) and performance there has
>> gone up noticeably, from around 30-40 fps in most cases to near 60.
>
> Great, good to hear!
> Now that we have narrowed down the issue to msitranslate (that should be
> disabled by default anyway), I would like to fix it entirely if possible.
> Could you please try the appended patch, without any other patches
> (therefore msitranslate would still be enabled)?
>
> Thanks for testing!!
>

I've reverted the previous patch and applied this one, and I'm pleased
to report it's still working. Thanks for your help!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 01:43:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 01:43: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 1SkQEI-0006iu-7N; Fri, 29 Jun 2012 01:42:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkQEG-0006ip-8L
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 01:42:36 +0000
Received: from [85.158.138.51:27691] by server-9.bemta-3.messagelabs.com id
	1B/FD-10419-B080DEF4; Fri, 29 Jun 2012 01:42:35 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340934153!22015404!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3609 invoked from network); 29 Jun 2012 01:42:34 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 01:42:34 -0000
Received: by ghrr14 with SMTP id r14so2775041ghr.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 18:42:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=D4inBqW/nO9xV004wvPpAiZzLppNkKlzEmDV6Z+23z4=;
	b=i20Ztf6LLud4eZ5RL9LiVNaeicxDKujkq+7FpraJl6QAjH25SlP0Yf9IQV1U758U+t
	v5IrlaruIJblVkXeaPITHTOrN1TojfHdLaUiZ6VerO993ukFaJr8kflgmKiagXdSCNLW
	4Zf/ooZxBFJnWzREHMPPpb+xYdDLfrvXGABZzgkFIF5z4VsqYenr1I3u/yEzXsDfvaRy
	j4ySNRYJt7qWj/kzBUzBOjGLvbOp/wQGtClFwxLPWXQpuI3fg9yLDu6A67JPNDSG5c9T
	v88+HfEqeLqi3hsdxF1SWP4xa8ac+NOfWFQlunA39t+2UOiRXmNZ4Uem/7jqUfOKk1Yi
	ErfQ==
Received: by 10.42.66.13 with SMTP id n13mr1450477ici.39.1340934152618; Thu,
	28 Jun 2012 18:42:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Thu, 28 Jun 2012 18:42:12 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
	<alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
From: Rolu <rolu@roce.org>
Date: Fri, 29 Jun 2012 03:42:12 +0200
Message-ID: <CABs9Ejn1Z_skEnEfj9y51=NQ5b3yipq9F5o9BeP-LnfZnuo1Lw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQlUymSi0Pr58E3POx10mq5T0wnV+Wn1/js05FZiqsa9xnot2kDNxsWmu+4d1glNA+idDr1b
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 12:49 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 27 Jun 2012, Rolu wrote:
>> > That's because msitranslate is still enabled somehow, that is a
>> > toolstack bug.
>> > While we fix that bug, could you try this QEMU patch to forcefully disable
>> > msitranslate?
>> >
>>
>> This worked!
>>
>> The "unsupported delivery mode" message is gone. Sound works, although
>> there is still occasionally a very short stutter, but I expect that's
>> a different issue. I've been testing with a KDE desktop with 3D
>> effects (cube, expo, that sort of stuff) and performance there has
>> gone up noticeably, from around 30-40 fps in most cases to near 60.
>
> Great, good to hear!
> Now that we have narrowed down the issue to msitranslate (that should be
> disabled by default anyway), I would like to fix it entirely if possible.
> Could you please try the appended patch, without any other patches
> (therefore msitranslate would still be enabled)?
>
> Thanks for testing!!
>

I've reverted the previous patch and applied this one, and I'm pleased
to report it's still working. Thanks for your help!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 02:20:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 02: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 1SkQop-0007QP-Cm; Fri, 29 Jun 2012 02:20: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 1SkQon-0007QK-QC
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 02:20:22 +0000
Received: from [85.158.138.51:48699] by server-8.bemta-3.messagelabs.com id
	30/2B-06157-4E01DEF4; Fri, 29 Jun 2012 02:20:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340936413!30184838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20434 invoked from network); 29 Jun 2012 02:20:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 02:20:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,495,1336348800"; d="scan'208";a="13280737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 02:20:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 03:20:12 +0100
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 1SkQoe-0004tH-FR;
	Fri, 29 Jun 2012 02:20:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkQoe-0002mI-EF;
	Fri, 29 Jun 2012 03:20:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13387-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 03:20:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13387: 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 13387 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13387/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail pass in 13384
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13384 pass in 13387
 test-i386-i386-xl-qemuu-win 12 guest-localmigrate/x10 fail in 13384 pass in 13387

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13384 never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=dbaf62769e1bfa7636208a4f00ea2331f5c40685
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable dbaf62769e1bfa7636208a4f00ea2331f5c40685
+ branch=qemu-upstream-unstable
+ revision=dbaf62769e1bfa7636208a4f00ea2331f5c40685
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git dbaf62769e1bfa7636208a4f00ea2331f5c40685:master
Counting objects: 16   
Counting objects: 28, done.
Compressing objects:  16% (1/6)   
Compressing objects:  33% (2/6)   
Compressing objects:  50% (3/6)   
Compressing objects:  66% (4/6)   
Compressing objects:  83% (5/6)   
Compressing objects: 100% (6/6)   
Compressing objects: 100% (6/6), done.
Writing objects:   5% (1/19)   
Writing objects:  10% (2/19)   
Writing objects:  15% (3/19)   
Writing objects:  21% (4/19)   
Writing objects:  31% (6/19)   
Writing objects:  42% (8/19)   
Writing objects:  47% (9/19)   
Writing objects:  52% (10/19)   
Writing objects:  57% (11/19)   
Writing objects:  63% (12/19)   
Writing objects:  68% (13/19)   
Writing objects:  73% (14/19)   
Writing objects:  78% (15/19)   
Writing objects:  84% (16/19)   
Writing objects:  89% (17/19)   
Writing objects:  94% (18/19)   
Writing objects: 100% (19/19)   
Writing objects: 100% (19/19), 2.38 KiB, done.
Total 19 (delta 15), reused 17 (delta 13)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   4e87850..dbaf627  dbaf62769e1bfa7636208a4f00ea2331f5c40685 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 02:20:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 02: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 1SkQop-0007QP-Cm; Fri, 29 Jun 2012 02:20: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 1SkQon-0007QK-QC
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 02:20:22 +0000
Received: from [85.158.138.51:48699] by server-8.bemta-3.messagelabs.com id
	30/2B-06157-4E01DEF4; Fri, 29 Jun 2012 02:20:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340936413!30184838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20434 invoked from network); 29 Jun 2012 02:20:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 02:20:13 -0000
X-IronPort-AV: E=Sophos;i="4.77,495,1336348800"; d="scan'208";a="13280737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 02:20:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 03:20:12 +0100
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 1SkQoe-0004tH-FR;
	Fri, 29 Jun 2012 02:20:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkQoe-0002mI-EF;
	Fri, 29 Jun 2012 03:20:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13387-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 03:20:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13387: 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 13387 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13387/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail pass in 13384
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail in 13384 pass in 13387
 test-i386-i386-xl-qemuu-win 12 guest-localmigrate/x10 fail in 13384 pass in 13387

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-i386-i386-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-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 13384 never pass

version targeted for testing:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685
baseline version:
 qemuu                4e8785001421e97c4f1c18d27ce77d717f9561d4

------------------------------------------------------------
People who touched revisions under test:
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=dbaf62769e1bfa7636208a4f00ea2331f5c40685
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push qemu-upstream-unstable dbaf62769e1bfa7636208a4f00ea2331f5c40685
+ branch=qemu-upstream-unstable
+ revision=dbaf62769e1bfa7636208a4f00ea2331f5c40685
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-unstable
+ '[' xqemuu = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree qemu-upstream-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git dbaf62769e1bfa7636208a4f00ea2331f5c40685:master
Counting objects: 16   
Counting objects: 28, done.
Compressing objects:  16% (1/6)   
Compressing objects:  33% (2/6)   
Compressing objects:  50% (3/6)   
Compressing objects:  66% (4/6)   
Compressing objects:  83% (5/6)   
Compressing objects: 100% (6/6)   
Compressing objects: 100% (6/6), done.
Writing objects:   5% (1/19)   
Writing objects:  10% (2/19)   
Writing objects:  15% (3/19)   
Writing objects:  21% (4/19)   
Writing objects:  31% (6/19)   
Writing objects:  42% (8/19)   
Writing objects:  47% (9/19)   
Writing objects:  52% (10/19)   
Writing objects:  57% (11/19)   
Writing objects:  63% (12/19)   
Writing objects:  68% (13/19)   
Writing objects:  73% (14/19)   
Writing objects:  78% (15/19)   
Writing objects:  84% (16/19)   
Writing objects:  89% (17/19)   
Writing objects:  94% (18/19)   
Writing objects: 100% (19/19)   
Writing objects: 100% (19/19), 2.38 KiB, done.
Total 19 (delta 15), reused 17 (delta 13)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   4e87850..dbaf627  dbaf62769e1bfa7636208a4f00ea2331f5c40685 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 03:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 03: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 1SkS3k-0000Dx-FW; Fri, 29 Jun 2012 03:39:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkS3j-0000Ds-A2
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 03:39:51 +0000
Received: from [193.109.254.147:45742] by server-2.bemta-14.messagelabs.com id
	C9/DD-01735-6832DEF4; Fri, 29 Jun 2012 03:39:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340941189!9119128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7659 invoked from network); 29 Jun 2012 03:39:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 03:39:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,495,1336348800"; d="scan'208";a="13281051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 03:39:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 04:39:22 +0100
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 1SkS3G-0005JM-9g;
	Fri, 29 Jun 2012 03:39:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkS3G-0006dq-96;
	Fri, 29 Jun 2012 04:39:22 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13389-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 04:39:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13389: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13389 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13389/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  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-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-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-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  0455d8317631
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 863 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 Jun 29 03:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 03: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 1SkS3k-0000Dx-FW; Fri, 29 Jun 2012 03:39:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkS3j-0000Ds-A2
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 03:39:51 +0000
Received: from [193.109.254.147:45742] by server-2.bemta-14.messagelabs.com id
	C9/DD-01735-6832DEF4; Fri, 29 Jun 2012 03:39:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1340941189!9119128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7659 invoked from network); 29 Jun 2012 03:39:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 03:39:49 -0000
X-IronPort-AV: E=Sophos;i="4.77,495,1336348800"; d="scan'208";a="13281051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 03:39:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 04:39:22 +0100
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 1SkS3G-0005JM-9g;
	Fri, 29 Jun 2012 03:39:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkS3G-0006dq-96;
	Fri, 29 Jun 2012 04:39:22 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13389-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 04:39:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13389: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13389 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13389/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  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-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-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-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  0455d8317631
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 863 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 Jun 29 05:29:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 05:29: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 1SkTlh-0001Yq-NR; Fri, 29 Jun 2012 05:29:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SkTlg-0001Yj-Ai
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 05:29:20 +0000
Received: from [85.158.143.35:27946] by server-3.bemta-4.messagelabs.com id
	D4/93-05808-F2D3DEF4; Fri, 29 Jun 2012 05:29:19 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340947758!14011432!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyMTU2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23635 invoked from network); 29 Jun 2012 05:29:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 05:29:18 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 28 Jun 2012 22:29:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="186461703"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 28 Jun 2012 22:29:17 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 22:29:17 -0700
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; Thu, 28 Jun 2012 22:29:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.220]) by
	SHSMSX151.ccr.corp.intel.com ([10.239.6.50]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 13:29:15 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Dario Faggioli <raistlin@linux.it>, Pasi K?rkk?inen <pasik@iki.fi>
Thread-Topic: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
	placement of guests on NUMA nodes
Thread-Index: AQHNSxlR+Fwf5woVCUSe6XXnSjJ2Z5cPZo6A//+qF4CAACmeAIAASTeAgAEJfuA=
Date: Fri, 29 Jun 2012 05:29:14 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1D5F48@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace> <20120628124106.GL2058@reaktio.net>
	<1340902989.17236.5.camel@Solace>
In-Reply-To: <1340902989.17236.5.camel@Solace>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RGFyaW8gRmFnZ2lvbGkgd3JvdGUgb24gMjAxMi0wNi0yOToNCj4gT24gVGh1LCAyMDEyLTA2LTI4
IGF0IDE1OjQxICswMzAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZToNCj4+Pj4gRnVydGhlcm1v
cmUsIHdlIG5lZWQgY29uc2lkZXIgdGhlIGd1ZXN0IE5VTUEoSSBhbSB3b3JraW5nIG9uIGl0IG5v
dykNCj4+Pj4gYW5kIGxpdmUgbWlncmF0aW9uLg0KPj4+PiANCj4+PiBHcmVhdC4gQ2FuIHlvdSBz
aGFyZSwgZWl0aGVyIGhlcmUgb24gb3IgYSBzZXBhcmF0ZSB0aHJlYWQgc29tZSBtb3JlDQo+Pj4g
ZGV0YWlscyBhYm91dCB3aGF0IHlvdSBtZWFuIGJ5IGJvdGggImd1ZXN0IE5VTUEiIGFuZCAibGl2
ZSBtaWdyYXRpb24iIGluDQo+Pj4gdGhpcyBjb250ZXh0Pw0KPj4+IA0KPj4+IEFzIEdlb3JnZSBz
YWlkLCB0aGF0IHdvdWxkIGJlIDQuMyBtYXRlcmlhbCwgYnV0IEknbSBzdGlsbCB2ZXJ5DQo+Pj4g
aW50ZXJlc3RlZC4gOi0pDQo+Pj4gDQo+PiANCj4+IEZvciB0aGUgbWFpbGluZ2xpc3QgYXJjaGl2
ZXMuLg0KPj4gDQo+IDotKQ0KPiANCj4+IGhlcmUgYXJlIHRoZSBYZW4gZ3Vlc3QgVk0gTlVNQSBz
bGlkZXMgZnJvbSBYZW5TdW1taXQgMjAxMDoNCj4+IGh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQv
eGVuX2NvbV9tZ3IvbmFrYWppbWEtbnVtYWZpbmFsDQo+PiBodHRwOi8vd3d3LnNsaWRlc2hhcmUu
bmV0L3hlbl9jb21fbWdyL2R1bGxvb3IteGVuc3VtbWl0DQo+PiANCj4gWWVzLCBJIGtub3cgdGhp
cyBzbGlkZXMsIGFuZCBJJ3ZlIGFsc28gbG9va2VkIGF0IG1vc3Qgb2YgdGhlIGNvZGUNCj4gdGhl
eSdyZSByZWZlcnJpbmcgdG8uIFRoYXQncyBhbGwgdmVyeSBpbnRlcmVzdGluZyBhbmQgaXQncyB3
ZWxsDQo+IHdvcnRod2hpbGUgdG8ga2VlcCB0aGF0IGluIG1pbmQgZm9yIGZ1dHVyZSBzdGVwcyBp
biB0aGUgZmllbGQgb2YgTlVNQQ0KPiBzdXBwb3J0LiBJbiBwYXJ0aWN1bGFyLCB2aXJ0dWFsIHRv
cG9sb2d5IGF3YXJlbmVzcyBvZiB0aGUgZ3Vlc3QgaXMNCj4gc29tZXRoaW5nIHJlYWxseSBpbXBv
cnRhbnQgdG8gaGF2ZSwgYW5kIEknbGwgYmUgaGFwcHkgdG8NCj4gZGlzY3Vzcy93b3JrL2NvbnRy
aWJ1dGUvaGVscCBvbiBpdCBpbiB0aGUgbmVhciBmdXR1cmUuDQo+IA0KPiBIb3dldmVyLCBJJ20g
c3RpbGwgbm90IHN1cmUgSSBzZWUgaG93IHRoYXQgKCJndWVzdCBOVU1BIikgYW5kIGxpdmUNCj4g
bWlncmF0aW9uIHNob3VsZCBhZmZlY3QgKGVpdGhlciBub3cgb3IgZHVyaW5nIDQuMyBkZXYgY3lj
bGUpIHRoZSBpbml0aWFsDQo+IHBsYWNlbWVudCBvZiBhIGRvbWFpbi4uLiBUaGF0J3Mgd2hhdCBJ
IHdhcyBhc2tpbmcuDQoNCldoZW4gZG9pbmcgbWlncmF0aW9uLCBpZiB0aGUgdGFyZ2V0IG1hY2hp
bmUgaXMgYWJsZSB0byBwcm92aWRlIHRoZSBzYW1lIG1lbW9yeSBmcmFtZXdvcmsgZm9yIHRoZSBn
dWVzdCwgd2UgbmVlZCB0byBjb25zaWRlciBpdCBmaXJzdGx5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpZ
YW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Jun 29 05:29:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 05:29: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 1SkTlh-0001Yq-NR; Fri, 29 Jun 2012 05:29:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SkTlg-0001Yj-Ai
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 05:29:20 +0000
Received: from [85.158.143.35:27946] by server-3.bemta-4.messagelabs.com id
	D4/93-05808-F2D3DEF4; Fri, 29 Jun 2012 05:29:19 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340947758!14011432!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyMTU2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23635 invoked from network); 29 Jun 2012 05:29:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 05:29:18 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 28 Jun 2012 22:29:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="186461703"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 28 Jun 2012 22:29:17 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 22:29:17 -0700
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; Thu, 28 Jun 2012 22:29:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.220]) by
	SHSMSX151.ccr.corp.intel.com ([10.239.6.50]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 13:29:15 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Dario Faggioli <raistlin@linux.it>, Pasi K?rkk?inen <pasik@iki.fi>
Thread-Topic: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
	placement of guests on NUMA nodes
Thread-Index: AQHNSxlR+Fwf5woVCUSe6XXnSjJ2Z5cPZo6A//+qF4CAACmeAIAASTeAgAEJfuA=
Date: Fri, 29 Jun 2012 05:29:14 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1D5F48@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace> <20120628124106.GL2058@reaktio.net>
	<1340902989.17236.5.camel@Solace>
In-Reply-To: <1340902989.17236.5.camel@Solace>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RGFyaW8gRmFnZ2lvbGkgd3JvdGUgb24gMjAxMi0wNi0yOToNCj4gT24gVGh1LCAyMDEyLTA2LTI4
IGF0IDE1OjQxICswMzAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZToNCj4+Pj4gRnVydGhlcm1v
cmUsIHdlIG5lZWQgY29uc2lkZXIgdGhlIGd1ZXN0IE5VTUEoSSBhbSB3b3JraW5nIG9uIGl0IG5v
dykNCj4+Pj4gYW5kIGxpdmUgbWlncmF0aW9uLg0KPj4+PiANCj4+PiBHcmVhdC4gQ2FuIHlvdSBz
aGFyZSwgZWl0aGVyIGhlcmUgb24gb3IgYSBzZXBhcmF0ZSB0aHJlYWQgc29tZSBtb3JlDQo+Pj4g
ZGV0YWlscyBhYm91dCB3aGF0IHlvdSBtZWFuIGJ5IGJvdGggImd1ZXN0IE5VTUEiIGFuZCAibGl2
ZSBtaWdyYXRpb24iIGluDQo+Pj4gdGhpcyBjb250ZXh0Pw0KPj4+IA0KPj4+IEFzIEdlb3JnZSBz
YWlkLCB0aGF0IHdvdWxkIGJlIDQuMyBtYXRlcmlhbCwgYnV0IEknbSBzdGlsbCB2ZXJ5DQo+Pj4g
aW50ZXJlc3RlZC4gOi0pDQo+Pj4gDQo+PiANCj4+IEZvciB0aGUgbWFpbGluZ2xpc3QgYXJjaGl2
ZXMuLg0KPj4gDQo+IDotKQ0KPiANCj4+IGhlcmUgYXJlIHRoZSBYZW4gZ3Vlc3QgVk0gTlVNQSBz
bGlkZXMgZnJvbSBYZW5TdW1taXQgMjAxMDoNCj4+IGh0dHA6Ly93d3cuc2xpZGVzaGFyZS5uZXQv
eGVuX2NvbV9tZ3IvbmFrYWppbWEtbnVtYWZpbmFsDQo+PiBodHRwOi8vd3d3LnNsaWRlc2hhcmUu
bmV0L3hlbl9jb21fbWdyL2R1bGxvb3IteGVuc3VtbWl0DQo+PiANCj4gWWVzLCBJIGtub3cgdGhp
cyBzbGlkZXMsIGFuZCBJJ3ZlIGFsc28gbG9va2VkIGF0IG1vc3Qgb2YgdGhlIGNvZGUNCj4gdGhl
eSdyZSByZWZlcnJpbmcgdG8uIFRoYXQncyBhbGwgdmVyeSBpbnRlcmVzdGluZyBhbmQgaXQncyB3
ZWxsDQo+IHdvcnRod2hpbGUgdG8ga2VlcCB0aGF0IGluIG1pbmQgZm9yIGZ1dHVyZSBzdGVwcyBp
biB0aGUgZmllbGQgb2YgTlVNQQ0KPiBzdXBwb3J0LiBJbiBwYXJ0aWN1bGFyLCB2aXJ0dWFsIHRv
cG9sb2d5IGF3YXJlbmVzcyBvZiB0aGUgZ3Vlc3QgaXMNCj4gc29tZXRoaW5nIHJlYWxseSBpbXBv
cnRhbnQgdG8gaGF2ZSwgYW5kIEknbGwgYmUgaGFwcHkgdG8NCj4gZGlzY3Vzcy93b3JrL2NvbnRy
aWJ1dGUvaGVscCBvbiBpdCBpbiB0aGUgbmVhciBmdXR1cmUuDQo+IA0KPiBIb3dldmVyLCBJJ20g
c3RpbGwgbm90IHN1cmUgSSBzZWUgaG93IHRoYXQgKCJndWVzdCBOVU1BIikgYW5kIGxpdmUNCj4g
bWlncmF0aW9uIHNob3VsZCBhZmZlY3QgKGVpdGhlciBub3cgb3IgZHVyaW5nIDQuMyBkZXYgY3lj
bGUpIHRoZSBpbml0aWFsDQo+IHBsYWNlbWVudCBvZiBhIGRvbWFpbi4uLiBUaGF0J3Mgd2hhdCBJ
IHdhcyBhc2tpbmcuDQoNCldoZW4gZG9pbmcgbWlncmF0aW9uLCBpZiB0aGUgdGFyZ2V0IG1hY2hp
bmUgaXMgYWJsZSB0byBwcm92aWRlIHRoZSBzYW1lIG1lbW9yeSBmcmFtZXdvcmsgZm9yIHRoZSBn
dWVzdCwgd2UgbmVlZCB0byBjb25zaWRlciBpdCBmaXJzdGx5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpZ
YW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Jun 29 05:31:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 05:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkTnL-0001dX-6l; Fri, 29 Jun 2012 05:31:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agasheac@gmail.com>) id 1SkTnJ-0001dN-LA
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 05:31:01 +0000
Received: from [85.158.139.83:42477] by server-6.bemta-5.messagelabs.com id
	79/B9-11348-49D3DEF4; Fri, 29 Jun 2012 05:31:00 +0000
X-Env-Sender: agasheac@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340947858!30073749!1
X-Originating-IP: [209.85.214.173]
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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7518 invoked from network); 29 Jun 2012 05:31:00 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 05:31:00 -0000
Received: by obbta14 with SMTP id ta14so5329490obb.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 22:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=PMCusD1VolYHoZxW8JTNdOENaCXqJ0Y/zVw0DGbnBJ8=;
	b=HvgkxmHlh3vlsKoF7T7bYf/rB45XLzwyAN9y/0zIvFv1BEUFGeRnVyf6tmPf/Be008
	1Ee11FaeHe30itiVdpH6QZNs6LGHOkfu4Wfpu3Bq6MR+LM1H5OYPvbRe2gRSjFmaUPNd
	S8MklhcQ7c56SjGe2gF4H3IVWZGKblM49ZW3BxvzcUt8mb2sDNXcnqaJSeYRKWkksAQL
	6xH7Neyxu4C7Ejssgbmjhaww5tML+Ne9aPJ3Kl7dMqz5Cg/RGYazL9JxXJI9MdMqQ6eW
	c7kgEM1tiSaz6qIoPI/SyAViEbmm5IhnsQoIXThBlsLeI+ANy1RV+JPU0YYjrjqNWKrF
	lN7A==
MIME-Version: 1.0
Received: by 10.50.10.197 with SMTP id k5mr124555igb.39.1340947858559; Thu, 28
	Jun 2012 22:30:58 -0700 (PDT)
Received: by 10.42.136.134 with HTTP; Thu, 28 Jun 2012 22:30:58 -0700 (PDT)
Date: Fri, 29 Jun 2012 11:00:58 +0530
Message-ID: <CAMQ5s73cJ_aqXeZG_4ms7Y35azkR7SbOj1g61mn419RjdfuipA@mail.gmail.com>
From: =?UTF-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhyA=?=
	<agasheac@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen-4.1.2 cross compilation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6170785406773383318=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6170785406773383318==
Content-Type: multipart/alternative; boundary=14dae9340929c5948104c395c0f1

--14dae9340929c5948104c395c0f1
Content-Type: text/plain; charset=ISO-8859-1

Hi

Is anybody tried cross compilation of xen-4.1.2 on x86 with target machine
as x86_64. I managed to cross compile it but dom0 fails during boot without
any failure message.

Is anybody has any pointers to check for or any boot parameter for xen
image to get some messages

Thanks,
Aniket

--14dae9340929c5948104c395c0f1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<br><br>Is anybody tried cross compilation of xen-4.1.2 on x86 with targe=
t machine as x86_64. I managed to cross compile it but dom0 fails during bo=
ot without any failure message.<br><br>Is anybody has any pointers to check=
 for or any boot parameter for xen image to get some messages<br>
<br>Thanks,<br>Aniket<br>

--14dae9340929c5948104c395c0f1--


--===============6170785406773383318==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6170785406773383318==--


From xen-devel-bounces@lists.xen.org Fri Jun 29 05:31:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 05:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkTnL-0001dX-6l; Fri, 29 Jun 2012 05:31:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agasheac@gmail.com>) id 1SkTnJ-0001dN-LA
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 05:31:01 +0000
Received: from [85.158.139.83:42477] by server-6.bemta-5.messagelabs.com id
	79/B9-11348-49D3DEF4; Fri, 29 Jun 2012 05:31:00 +0000
X-Env-Sender: agasheac@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1340947858!30073749!1
X-Originating-IP: [209.85.214.173]
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-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7518 invoked from network); 29 Jun 2012 05:31:00 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 05:31:00 -0000
Received: by obbta14 with SMTP id ta14so5329490obb.32
	for <xen-devel@lists.xen.org>; Thu, 28 Jun 2012 22:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=PMCusD1VolYHoZxW8JTNdOENaCXqJ0Y/zVw0DGbnBJ8=;
	b=HvgkxmHlh3vlsKoF7T7bYf/rB45XLzwyAN9y/0zIvFv1BEUFGeRnVyf6tmPf/Be008
	1Ee11FaeHe30itiVdpH6QZNs6LGHOkfu4Wfpu3Bq6MR+LM1H5OYPvbRe2gRSjFmaUPNd
	S8MklhcQ7c56SjGe2gF4H3IVWZGKblM49ZW3BxvzcUt8mb2sDNXcnqaJSeYRKWkksAQL
	6xH7Neyxu4C7Ejssgbmjhaww5tML+Ne9aPJ3Kl7dMqz5Cg/RGYazL9JxXJI9MdMqQ6eW
	c7kgEM1tiSaz6qIoPI/SyAViEbmm5IhnsQoIXThBlsLeI+ANy1RV+JPU0YYjrjqNWKrF
	lN7A==
MIME-Version: 1.0
Received: by 10.50.10.197 with SMTP id k5mr124555igb.39.1340947858559; Thu, 28
	Jun 2012 22:30:58 -0700 (PDT)
Received: by 10.42.136.134 with HTTP; Thu, 28 Jun 2012 22:30:58 -0700 (PDT)
Date: Fri, 29 Jun 2012 11:00:58 +0530
Message-ID: <CAMQ5s73cJ_aqXeZG_4ms7Y35azkR7SbOj1g61mn419RjdfuipA@mail.gmail.com>
From: =?UTF-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhyA=?=
	<agasheac@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen-4.1.2 cross compilation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6170785406773383318=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6170785406773383318==
Content-Type: multipart/alternative; boundary=14dae9340929c5948104c395c0f1

--14dae9340929c5948104c395c0f1
Content-Type: text/plain; charset=ISO-8859-1

Hi

Is anybody tried cross compilation of xen-4.1.2 on x86 with target machine
as x86_64. I managed to cross compile it but dom0 fails during boot without
any failure message.

Is anybody has any pointers to check for or any boot parameter for xen
image to get some messages

Thanks,
Aniket

--14dae9340929c5948104c395c0f1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<br><br>Is anybody tried cross compilation of xen-4.1.2 on x86 with targe=
t machine as x86_64. I managed to cross compile it but dom0 fails during bo=
ot without any failure message.<br><br>Is anybody has any pointers to check=
 for or any boot parameter for xen image to get some messages<br>
<br>Thanks,<br>Aniket<br>

--14dae9340929c5948104c395c0f1--


--===============6170785406773383318==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6170785406773383318==--


From xen-devel-bounces@lists.xen.org Fri Jun 29 05:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 05:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkTui-00025W-42; Fri, 29 Jun 2012 05:38:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SkTug-00025Q-Pp
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 05:38:39 +0000
Received: from [85.158.143.35:62623] by server-3.bemta-4.messagelabs.com id
	7A/68-05808-E5F3DEF4; Fri, 29 Jun 2012 05:38:38 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340948317!16242752!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4Nzk3Mg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16518 invoked from network); 29 Jun 2012 05:38:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 05:38:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 22:38:18 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171498639"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 28 Jun 2012 22:38:18 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 22:38:17 -0700
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; Thu, 28 Jun 2012 22:38:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.220]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.244]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 13:38:16 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
	placement of guests on NUMA nodes
Thread-Index: AQHNSxlR+Fwf5woVCUSe6XXnSjJ2Z5cPZo6A//+PRICAAeUZgA==
Date: Fri, 29 Jun 2012 05:38:15 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1D6F7C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
In-Reply-To: <CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote on 2012-06-28:
> On Thu, Jun 28, 2012 at 8:25 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
>>> This all happens internally to libxl, and no API for driving the mechanism is
>>> provided for now. This matches what xend already does.
>> we should consider the basic IONUMA. I mean when a guest with a device
>> assigned, from the point of view of performance, it's better to
>> allocated the memory from the node which the device belongs to.
>> Furthermore, we need consider the guest NUMA(I am working on it now) and
> live migration.
> 
> Just to help set the context for these patch series: We have lots of
> big plans for NUMA in the 4.3 release (and are always glad for input
> and help!), but the current goal is just to have *something* for the
> upcoming 4.2 release.

Nice to hear you guys have the big plans fo NUMA things. :)

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 05:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 05:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkTui-00025W-42; Fri, 29 Jun 2012 05:38:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1SkTug-00025Q-Pp
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 05:38:39 +0000
Received: from [85.158.143.35:62623] by server-3.bemta-4.messagelabs.com id
	7A/68-05808-E5F3DEF4; Fri, 29 Jun 2012 05:38:38 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340948317!16242752!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4Nzk3Mg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16518 invoked from network); 29 Jun 2012 05:38:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 05:38:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2012 22:38:18 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171498639"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 28 Jun 2012 22:38:18 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Jun 2012 22:38:17 -0700
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; Thu, 28 Jun 2012 22:38:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.220]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.244]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 13:38:16 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
	placement of guests on NUMA nodes
Thread-Index: AQHNSxlR+Fwf5woVCUSe6XXnSjJ2Z5cPZo6A//+PRICAAeUZgA==
Date: Fri, 29 Jun 2012 05:38:15 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E1D6F7C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
In-Reply-To: <CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote on 2012-06-28:
> On Thu, Jun 28, 2012 at 8:25 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
>>> This all happens internally to libxl, and no API for driving the mechanism is
>>> provided for now. This matches what xend already does.
>> we should consider the basic IONUMA. I mean when a guest with a device
>> assigned, from the point of view of performance, it's better to
>> allocated the memory from the node which the device belongs to.
>> Furthermore, we need consider the guest NUMA(I am working on it now) and
> live migration.
> 
> Just to help set the context for these patch series: We have lots of
> big plans for NUMA in the 4.3 release (and are always glad for input
> and help!), but the current goal is just to have *something* for the
> upcoming 4.2 release.

Nice to hear you guys have the big plans fo NUMA things. :)

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 06:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 06:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkV8L-0002lA-8y; Fri, 29 Jun 2012 06:56: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 1SkV8J-0002l5-Tz
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 06:56:48 +0000
Received: from [85.158.138.51:34176] by server-1.bemta-3.messagelabs.com id
	BD/5A-14648-AA15DEF4; Fri, 29 Jun 2012 06:56:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340953002!30143505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18734 invoked from network); 29 Jun 2012 06:56:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 06:56:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,496,1336348800"; d="scan'208";a="13282235"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 06:56: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.213.0;
	Fri, 29 Jun 2012 07:56:41 +0100
Message-ID: <1340953001.5953.2.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 07:56:41 +0100
In-Reply-To: <osstest-13383-mainreport@xen.org>
References: <osstest-13383-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:
> flight 13383 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379

This run was before the migration series went in.

I don't see much of interest in the logs, seems like the guest did
actually start.

The new commits which went into this flight seem fairly benign, at least
from the PoV of starting a PV guest:

[...]
> changeset:   25521:52f1b8a4f9a4
> tag:         tip
> user:        George Dunlap <george.dunlap@eu.citrix.com>
> date:        Wed Jun 27 17:50:10 2012 +0100
>     
>     xen,pod: Cosmetic code motion
>     
>     No point in doing the assignment if we're just going to crash anyway.
>     
>     Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>     
>     
> changeset:   25520:2d9f3b010901
> user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
> date:        Thu Jun 28 12:45:09 2012 +0100
>     
>     x86/mm: Clean up unshare path for foreign mappings
>     
>     In its current shape, if Xen unshares a foreign gfn successfully while building
>     a foreign writable map, it is left with a reference to the old shared page in
>     the "target" var.
>     
>     Instead, push unsharing request down on the initial get_page_from_gfn call,
>     which will DTRT.
>     
>     This allows for greatly simplifying the unshare related condition handling,
>     removing ugly comments and s86_64 ifdef-ery.
>     
>     Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>     Acked-by: Tim Deegan <tim@xen.org>
>     Committed-by: Tim Deegan <tim@xen.org>
>     
>     
> changeset:   25519:fdc1f16d382c
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Thu Jun 28 13:36:08 2012 +0200
>     
>     x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]
>     
>     Since the emulator now supports a few 256-bit memory operations, this
>     array needs to follow (and the comments should, too).
>     
>     To limit growth, re-order the mmio_large_write_* fields so that the
>     two mmio_large_*_bytes fields end up adjacent to each other.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25518:4f92bdf3370c
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Wed Jun 27 09:36:43 2012 +0200
>     
>     docs/xen-headers: allow headers to be symlinks
>     
>     There's no apparent reason not to permit this, and since we don't
>     support out-of-source-tree builds, the least overhead way of doing
>     multiple, differently configured (perhaps different architecture)
>     builds from a single source tree is to create symlinked build trees.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
>     
>     
> ========================================
> commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
> Author: Roger Pau Monne <roger.pau@citrix.com>
> Date:   Thu Jun 7 19:44:01 2012 +0100
> 
>     qemu-xen-trad: fix sys-queue.h usage on BSD systems
>     
>     BSD systems already have a sys/queue.h file, which has more macros
>     than the one Qemu uses, and some header files depend on having that
>     macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
>     systems and include the native one.
>     
>     This is not a backport because the original patch is too dificult to
>     backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
>     
>     Doing a diff -bB shows that the Qemu version is just a stripped
>     version of the original NetBSD header, with many macros removed, but
>     no new ones added.
>     
>     Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>     Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Ian Jackson <ian.jackson@eu.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 Fri Jun 29 06:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 06:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkV8L-0002lA-8y; Fri, 29 Jun 2012 06:56: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 1SkV8J-0002l5-Tz
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 06:56:48 +0000
Received: from [85.158.138.51:34176] by server-1.bemta-3.messagelabs.com id
	BD/5A-14648-AA15DEF4; Fri, 29 Jun 2012 06:56:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340953002!30143505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18734 invoked from network); 29 Jun 2012 06:56:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 06:56:42 -0000
X-IronPort-AV: E=Sophos;i="4.77,496,1336348800"; d="scan'208";a="13282235"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 06:56: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.213.0;
	Fri, 29 Jun 2012 07:56:41 +0100
Message-ID: <1340953001.5953.2.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 07:56:41 +0100
In-Reply-To: <osstest-13383-mainreport@xen.org>
References: <osstest-13383-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:
> flight 13383 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379

This run was before the migration series went in.

I don't see much of interest in the logs, seems like the guest did
actually start.

The new commits which went into this flight seem fairly benign, at least
from the PoV of starting a PV guest:

[...]
> changeset:   25521:52f1b8a4f9a4
> tag:         tip
> user:        George Dunlap <george.dunlap@eu.citrix.com>
> date:        Wed Jun 27 17:50:10 2012 +0100
>     
>     xen,pod: Cosmetic code motion
>     
>     No point in doing the assignment if we're just going to crash anyway.
>     
>     Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>     
>     
> changeset:   25520:2d9f3b010901
> user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
> date:        Thu Jun 28 12:45:09 2012 +0100
>     
>     x86/mm: Clean up unshare path for foreign mappings
>     
>     In its current shape, if Xen unshares a foreign gfn successfully while building
>     a foreign writable map, it is left with a reference to the old shared page in
>     the "target" var.
>     
>     Instead, push unsharing request down on the initial get_page_from_gfn call,
>     which will DTRT.
>     
>     This allows for greatly simplifying the unshare related condition handling,
>     removing ugly comments and s86_64 ifdef-ery.
>     
>     Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>     Acked-by: Tim Deegan <tim@xen.org>
>     Committed-by: Tim Deegan <tim@xen.org>
>     
>     
> changeset:   25519:fdc1f16d382c
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Thu Jun 28 13:36:08 2012 +0200
>     
>     x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]
>     
>     Since the emulator now supports a few 256-bit memory operations, this
>     array needs to follow (and the comments should, too).
>     
>     To limit growth, re-order the mmio_large_write_* fields so that the
>     two mmio_large_*_bytes fields end up adjacent to each other.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25518:4f92bdf3370c
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Wed Jun 27 09:36:43 2012 +0200
>     
>     docs/xen-headers: allow headers to be symlinks
>     
>     There's no apparent reason not to permit this, and since we don't
>     support out-of-source-tree builds, the least overhead way of doing
>     multiple, differently configured (perhaps different architecture)
>     builds from a single source tree is to create symlinked build trees.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
>     
>     
> ========================================
> commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
> Author: Roger Pau Monne <roger.pau@citrix.com>
> Date:   Thu Jun 7 19:44:01 2012 +0100
> 
>     qemu-xen-trad: fix sys-queue.h usage on BSD systems
>     
>     BSD systems already have a sys/queue.h file, which has more macros
>     than the one Qemu uses, and some header files depend on having that
>     macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
>     systems and include the native one.
>     
>     This is not a backport because the original patch is too dificult to
>     backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
>     
>     Doing a diff -bB shows that the Qemu version is just a stripped
>     version of the original NetBSD header, with many macros removed, but
>     no new ones added.
>     
>     Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>     Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Ian Jackson <ian.jackson@eu.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 Fri Jun 29 07:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkVHB-0003Gb-Rd; Fri, 29 Jun 2012 07:05: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 1SkVHA-0003GW-8o
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:05:56 +0000
Received: from [193.109.254.147:47139] by server-5.bemta-14.messagelabs.com id
	1A/B3-04343-3D35DEF4; Fri, 29 Jun 2012 07:05:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340953554!2338252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19271 invoked from network); 29 Jun 2012 07:05:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 07:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,496,1336348800"; d="scan'208";a="13282355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 07:05:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 08:05:53 +0100
Message-ID: <1340953553.5953.5.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 08:05:53 +0100
In-Reply-To: <osstest-13385-mainreport@xen.org>
References: <osstest-13385-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 01:09 +0100, xen.org wrote:
> flight 13385 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13385/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 13379

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF ._libxl_save_msgs_helper.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls  -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/osstest/build.13385.build-amd64/xen-unstable/tools/libxl/../../tools/libxc -I/home/osstest/build.13385.build-amd64/xen-unstable/tools/libxl/../../tools/include  -c -o _libxl_save_msgs_helper.o _libxl_save_msgs_helper.c 
In file included from libxl_save_helper.c:44:
libxl.h:346:26: error: _libxl_types.h: No such file or directory
In file included from libxl_save_helper.c:44:
libxl.h:348: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
[...etc...]
./libxl_event.h:66: error: expected ';' before 'void'
make[3]: *** [libxl_save_helper.o] Error 1
make[3]: *** Waiting for unfinished jobs....
Parsing libxl_types_internal.idl
Parsing libxl_types.idl

Dependencies on the autogenerated code aren't quite right.

8<---------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340953509 -3600
# Node ID c5b08c577c7fba45724f4a0f84abf576c6299b9c
# Parent  0455d8317631b74c436fd2fadc6dc1c0cc86cb86
libxl: make libxl-save-helper depend on the autogenerated code targets

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0455d8317631 -r c5b08c577c7f tools/libxl/Makefile
--- a/tools/libxl/Makefile	Thu Jun 28 18:43:28 2012 +0100
+++ b/tools/libxl/Makefile	Fri Jun 29 08:05:09 2012 +0100
@@ -100,7 +100,7 @@ testidl.c: libxl_types.idl gentest.py li
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
 
 %.c %.h:: %.y
 	@rm -f $*.[ch]
@@ -134,7 +134,7 @@ libxl_internal.h: _libxl_types_internal.
 libxl_internal_json.h: _libxl_types_internal_json.h
 xl.h: _paths.h
 
-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): libxl.h
 $(LIBXL_OBJS): libxl_internal.h
 
 _libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py idl.py



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkVHB-0003Gb-Rd; Fri, 29 Jun 2012 07:05: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 1SkVHA-0003GW-8o
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:05:56 +0000
Received: from [193.109.254.147:47139] by server-5.bemta-14.messagelabs.com id
	1A/B3-04343-3D35DEF4; Fri, 29 Jun 2012 07:05:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340953554!2338252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19271 invoked from network); 29 Jun 2012 07:05:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 07:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,496,1336348800"; d="scan'208";a="13282355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 07:05:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 08:05:53 +0100
Message-ID: <1340953553.5953.5.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 08:05:53 +0100
In-Reply-To: <osstest-13385-mainreport@xen.org>
References: <osstest-13385-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 01:09 +0100, xen.org wrote:
> flight 13385 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13385/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 13379

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF ._libxl_save_msgs_helper.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls  -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/osstest/build.13385.build-amd64/xen-unstable/tools/libxl/../../tools/libxc -I/home/osstest/build.13385.build-amd64/xen-unstable/tools/libxl/../../tools/include  -c -o _libxl_save_msgs_helper.o _libxl_save_msgs_helper.c 
In file included from libxl_save_helper.c:44:
libxl.h:346:26: error: _libxl_types.h: No such file or directory
In file included from libxl_save_helper.c:44:
libxl.h:348: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
[...etc...]
./libxl_event.h:66: error: expected ';' before 'void'
make[3]: *** [libxl_save_helper.o] Error 1
make[3]: *** Waiting for unfinished jobs....
Parsing libxl_types_internal.idl
Parsing libxl_types.idl

Dependencies on the autogenerated code aren't quite right.

8<---------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340953509 -3600
# Node ID c5b08c577c7fba45724f4a0f84abf576c6299b9c
# Parent  0455d8317631b74c436fd2fadc6dc1c0cc86cb86
libxl: make libxl-save-helper depend on the autogenerated code targets

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0455d8317631 -r c5b08c577c7f tools/libxl/Makefile
--- a/tools/libxl/Makefile	Thu Jun 28 18:43:28 2012 +0100
+++ b/tools/libxl/Makefile	Fri Jun 29 08:05:09 2012 +0100
@@ -100,7 +100,7 @@ testidl.c: libxl_types.idl gentest.py li
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
 
 %.c %.h:: %.y
 	@rm -f $*.[ch]
@@ -134,7 +134,7 @@ libxl_internal.h: _libxl_types_internal.
 libxl_internal_json.h: _libxl_types_internal_json.h
 xl.h: _paths.h
 
-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): libxl.h
 $(LIBXL_OBJS): libxl_internal.h
 
 _libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py idl.py



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:18:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:18: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 1SkVSw-0003Qd-EG; Fri, 29 Jun 2012 07:18: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 1SkVSu-0003QY-FM
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:18:04 +0000
Received: from [85.158.143.35:53682] by server-1.bemta-4.messagelabs.com id
	0F/0E-24392-BA65DEF4; Fri, 29 Jun 2012 07:18:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340954282!7024697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24335 invoked from network); 29 Jun 2012 07:18:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 07:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13282538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 07:18:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 08:18:02 +0100
Message-ID: <1340954281.5953.10.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 08:18:01 +0100
In-Reply-To: <osstest-13389-mainreport@xen.org>
References: <osstest-13389-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13389: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 04:39 +0100, xen.org wrote:
>  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379

        migration target: Ready to receive domain.
        Saving to migration stream new xl format (info 0x0/0x0/661)
        Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/661)
         Savefile contains xl domain config
        WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
        xl: libxl_xshelp.c:174: libxl__xs_transaction_start: Assertion `!*t' failed.

8<---------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340954225 -3600
# Node ID 75c5ca9f6111226c06fc5da8071b160b6ac7904b
# Parent  c5b08c577c7fba45724f4a0f84abf576c6299b9c
libxl: libxl__xs_transaction_commit should always clear the transaction.

This includes the EAGAIN case.

Users are of the form:

   xs_transaction_t t = 0;

   for (;;) {
        rc = libxl__xs_transaction_start(gc, &t);

	rc = stuff
	if (rc) goto out;
	...more...

        rc = libxl__xs_transaction_commit(gc, &t);
        if (!rc) break;
        if (rc<0) goto out;
    }
  ...
 out:

So in EAGAIN (commit -> +1) we will go round the loop again and call start
which leads to:
    xl: libxl_xshelp.c:174: libxl__xs_transaction_start: Assertion `!*t' failed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c5b08c577c7f -r 75c5ca9f6111 tools/libxl/libxl_xshelp.c
--- a/tools/libxl/libxl_xshelp.c	Fri Jun 29 08:05:09 2012 +0100
+++ b/tools/libxl/libxl_xshelp.c	Fri Jun 29 08:17:05 2012 +0100
@@ -185,10 +185,10 @@ int libxl__xs_transaction_commit(libxl__
     assert(*t);
 
     if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        *t = 0;
         if (errno == EAGAIN)
             return +1;
 
-        *t = 0;
         LOGE(ERROR, "could not commit xenstore transaction");
         return ERROR_FAIL;
     }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:18:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:18: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 1SkVSw-0003Qd-EG; Fri, 29 Jun 2012 07:18: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 1SkVSu-0003QY-FM
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:18:04 +0000
Received: from [85.158.143.35:53682] by server-1.bemta-4.messagelabs.com id
	0F/0E-24392-BA65DEF4; Fri, 29 Jun 2012 07:18:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1340954282!7024697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24335 invoked from network); 29 Jun 2012 07:18:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 07:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13282538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 07:18:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 08:18:02 +0100
Message-ID: <1340954281.5953.10.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 08:18:01 +0100
In-Reply-To: <osstest-13389-mainreport@xen.org>
References: <osstest-13389-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13389: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 04:39 +0100, xen.org wrote:
>  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379

        migration target: Ready to receive domain.
        Saving to migration stream new xl format (info 0x0/0x0/661)
        Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/661)
         Savefile contains xl domain config
        WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
        xl: libxl_xshelp.c:174: libxl__xs_transaction_start: Assertion `!*t' failed.

8<---------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340954225 -3600
# Node ID 75c5ca9f6111226c06fc5da8071b160b6ac7904b
# Parent  c5b08c577c7fba45724f4a0f84abf576c6299b9c
libxl: libxl__xs_transaction_commit should always clear the transaction.

This includes the EAGAIN case.

Users are of the form:

   xs_transaction_t t = 0;

   for (;;) {
        rc = libxl__xs_transaction_start(gc, &t);

	rc = stuff
	if (rc) goto out;
	...more...

        rc = libxl__xs_transaction_commit(gc, &t);
        if (!rc) break;
        if (rc<0) goto out;
    }
  ...
 out:

So in EAGAIN (commit -> +1) we will go round the loop again and call start
which leads to:
    xl: libxl_xshelp.c:174: libxl__xs_transaction_start: Assertion `!*t' failed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c5b08c577c7f -r 75c5ca9f6111 tools/libxl/libxl_xshelp.c
--- a/tools/libxl/libxl_xshelp.c	Fri Jun 29 08:05:09 2012 +0100
+++ b/tools/libxl/libxl_xshelp.c	Fri Jun 29 08:17:05 2012 +0100
@@ -185,10 +185,10 @@ int libxl__xs_transaction_commit(libxl__
     assert(*t);
 
     if (!xs_transaction_end(CTX->xsh, *t, 0)) {
+        *t = 0;
         if (errno == EAGAIN)
             return +1;
 
-        *t = 0;
         LOGE(ERROR, "could not commit xenstore transaction");
         return ERROR_FAIL;
     }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:23:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkVXt-0003kW-SI; Fri, 29 Jun 2012 07:23:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkVXs-0003kM-8Q
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:23:12 +0000
Received: from [85.158.139.83:52027] by server-11.bemta-5.messagelabs.com id
	8B/F2-20400-FD75DEF4; Fri, 29 Jun 2012 07:23:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340954591!22751169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4006 invoked from network); 29 Jun 2012 07:23:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 07:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13282617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 07:23:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 08:23:10 +0100
Message-ID: <1340954589.5953.12.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Fri, 29 Jun 2012 08:23:09 +0100
In-Reply-To: <20120628.165550.1816352825092253548.davem@davemloft.net>
References: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
	<20120628.165550.1816352825092253548.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 00:55 +0100, David Miller wrote:
> From: annie.li@oracle.com
> Date: Wed, 27 Jun 2012 18:46:58 +0800
> 
> > From: Annie Li <Annie.li@oracle.com>
> > 
> > After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
> > However, no dequeue action is called in this situation, it is likely that
> > tx_queue constains freed SKB. This patch should fix this issue, and it is
> > based on 3.5.0-rc4+.
> > 
> > This issue is found through code inspection, no bug is seen with it currently.
> > I run netperf test for several hours, and no network regression was found.
> > 
> > Signed-off-by: Annie Li <annie.li@oracle.com>
> 
> I lack the expertiece necessary to properly review this, so I really
> need a Xen expert to look this over.

Sorry, I put it to one side waiting for the repost to netdev and then
forgot about it...

Yes, this change looks good to me:

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:23:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkVXt-0003kW-SI; Fri, 29 Jun 2012 07:23:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkVXs-0003kM-8Q
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:23:12 +0000
Received: from [85.158.139.83:52027] by server-11.bemta-5.messagelabs.com id
	8B/F2-20400-FD75DEF4; Fri, 29 Jun 2012 07:23:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340954591!22751169!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4006 invoked from network); 29 Jun 2012 07:23:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 07:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13282617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 07:23:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 08:23:10 +0100
Message-ID: <1340954589.5953.12.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Fri, 29 Jun 2012 08:23:09 +0100
In-Reply-To: <20120628.165550.1816352825092253548.davem@davemloft.net>
References: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
	<20120628.165550.1816352825092253548.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 00:55 +0100, David Miller wrote:
> From: annie.li@oracle.com
> Date: Wed, 27 Jun 2012 18:46:58 +0800
> 
> > From: Annie Li <Annie.li@oracle.com>
> > 
> > After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
> > However, no dequeue action is called in this situation, it is likely that
> > tx_queue constains freed SKB. This patch should fix this issue, and it is
> > based on 3.5.0-rc4+.
> > 
> > This issue is found through code inspection, no bug is seen with it currently.
> > I run netperf test for several hours, and no network regression was found.
> > 
> > Signed-off-by: Annie Li <annie.li@oracle.com>
> 
> I lack the expertiece necessary to properly review this, so I really
> need a Xen expert to look this over.

Sorry, I put it to one side waiting for the repost to netdev and then
forgot about it...

Yes, this change looks good to me:

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:51:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07: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 1SkVyV-0004RN-0h; Fri, 29 Jun 2012 07:50:43 +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 1SkVyT-0004RG-B5
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:50:41 +0000
Received: from [85.158.138.51:55355] by server-10.bemta-3.messagelabs.com id
	75/7F-01753-05E5DEF4; Fri, 29 Jun 2012 07:50:40 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340956239!21000322!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15488 invoked from network); 29 Jun 2012 07:50:39 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-6.tower-174.messagelabs.com with SMTP;
	29 Jun 2012 07:50:39 -0000
Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net
	[74.93.104.98])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id EFD81584C70;
	Fri, 29 Jun 2012 00:50:38 -0700 (PDT)
Date: Fri, 29 Jun 2012 00:50:37 -0700 (PDT)
Message-Id: <20120629.005037.1477386520087362696.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1340954589.5953.12.camel@dagon.hellion.org.uk>
References: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
	<20120628.165550.1816352825092253548.davem@davemloft.net>
	<1340954589.5953.12.camel@dagon.hellion.org.uk>
X-Mailer: Mew version 6.5 on Emacs 24.0.97 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, annie.li@oracle.com, xen-devel@lists.xensource.com,
	kurt.hackel@oracle.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Fri, 29 Jun 2012 08:23:09 +0100

> On Fri, 2012-06-29 at 00:55 +0100, David Miller wrote:
>> From: annie.li@oracle.com
>> Date: Wed, 27 Jun 2012 18:46:58 +0800
>> 
>> > From: Annie Li <Annie.li@oracle.com>
>> > 
>> > After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
>> > However, no dequeue action is called in this situation, it is likely that
>> > tx_queue constains freed SKB. This patch should fix this issue, and it is
>> > based on 3.5.0-rc4+.
>> > 
>> > This issue is found through code inspection, no bug is seen with it currently.
>> > I run netperf test for several hours, and no network regression was found.
>> > 
>> > Signed-off-by: Annie Li <annie.li@oracle.com>
>> 
>> I lack the expertiece necessary to properly review this, so I really
>> need a Xen expert to look this over.
> 
> Sorry, I put it to one side waiting for the repost to netdev and then
> forgot about it...
> 
> Yes, this change looks good to me:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, applied to net-next.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:51:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07: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 1SkVyV-0004RN-0h; Fri, 29 Jun 2012 07:50:43 +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 1SkVyT-0004RG-B5
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:50:41 +0000
Received: from [85.158.138.51:55355] by server-10.bemta-3.messagelabs.com id
	75/7F-01753-05E5DEF4; Fri, 29 Jun 2012 07:50:40 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340956239!21000322!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15488 invoked from network); 29 Jun 2012 07:50:39 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-6.tower-174.messagelabs.com with SMTP;
	29 Jun 2012 07:50:39 -0000
Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net
	[74.93.104.98])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id EFD81584C70;
	Fri, 29 Jun 2012 00:50:38 -0700 (PDT)
Date: Fri, 29 Jun 2012 00:50:37 -0700 (PDT)
Message-Id: <20120629.005037.1477386520087362696.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1340954589.5953.12.camel@dagon.hellion.org.uk>
References: <1340794018-17274-1-git-send-email-annie.li@oracle.com>
	<20120628.165550.1816352825092253548.davem@davemloft.net>
	<1340954589.5953.12.camel@dagon.hellion.org.uk>
X-Mailer: Mew version 6.5 on Emacs 24.0.97 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, annie.li@oracle.com, xen-devel@lists.xensource.com,
	kurt.hackel@oracle.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/1] xen/netback: only non-freed SKB is
 queued into tx_queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Fri, 29 Jun 2012 08:23:09 +0100

> On Fri, 2012-06-29 at 00:55 +0100, David Miller wrote:
>> From: annie.li@oracle.com
>> Date: Wed, 27 Jun 2012 18:46:58 +0800
>> 
>> > From: Annie Li <Annie.li@oracle.com>
>> > 
>> > After SKB is queued into tx_queue, it will be freed if request_gop is NULL.
>> > However, no dequeue action is called in this situation, it is likely that
>> > tx_queue constains freed SKB. This patch should fix this issue, and it is
>> > based on 3.5.0-rc4+.
>> > 
>> > This issue is found through code inspection, no bug is seen with it currently.
>> > I run netperf test for several hours, and no network regression was found.
>> > 
>> > Signed-off-by: Annie Li <annie.li@oracle.com>
>> 
>> I lack the expertiece necessary to properly review this, so I really
>> need a Xen expert to look this over.
> 
> Sorry, I put it to one side waiting for the repost to netdev and then
> forgot about it...
> 
> Yes, this change looks good to me:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, applied to net-next.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:51:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkVyp-0004Ss-Dx; Fri, 29 Jun 2012 07:51:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkVyo-0004Sd-C4
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 07:51:02 +0000
Received: from [85.158.143.99:59070] by server-2.bemta-4.messagelabs.com id
	79/DE-17938-56E5DEF4; Fri, 29 Jun 2012 07:51:01 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340956259!23336637!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyMTU2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18152 invoked from network); 29 Jun 2012 07:50:59 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 07:50:59 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 29 Jun 2012 00:50:58 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171532033"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 29 Jun 2012 00:50:58 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 00:50:58 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 00:50:57 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.220]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 15:50:56 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest
	live migration
Thread-Index: AQHNVTVCgrIw+0SUNkag8kO/2PKTnpcQ647g
Date: Fri, 29 Jun 2012 07:50:56 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE263C2@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-5-git-send-email-xudong.hao@intel.com>
	<20120628135220.GQ34995@ocelot.phlegethon.org>
In-Reply-To: <20120628135220.GQ34995@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest
 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

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Thursday, June 28, 2012 9:52 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest live
> migration
> 
> At 09:57 +0800 on 20 Jun (1340186267), Xudong Hao wrote:
> > @@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t
> *entry, p2m_type_t type, p2m_acces
> >
> entry->mfn);
> >              break;
> >          case p2m_ram_logdirty:
> > +            entry->w = hap_has_dirty_bit;
> > +            entry->r = entry->x = 1;
> > +            /* Not necessarily need to clear A bit, but it is safe anyway */
> > +            entry->a = entry->d = 0;
> > +            break;
> 
> I think it's better not to clear the A bit - it will just cause the
> hardware to issue extra writes to set it.
> 

It's ok for me to not clear A bit here.

> > @@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t
> ept_page_mfn, int ept_page_level,
> >
> >          if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
> >              ept_change_entry_type_page(_mfn(epte[i].mfn),
> > -                                       ept_page_level - 1, ot, nt);
> > +                                       ept_page_level - 1, ot, nt, d,
> mask);
> >          else
> >          {
> >              e = atomic_read_ept_entry(&epte[i]);
> >              if ( e.sa_p2mt != ot )
> >                  continue;
> >
> > +            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
> > +            {
> > +                int j, nr_pages;
> > +                struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +                for ( j = 0, nr_pages = 1; j < ept_page_level;
> > +                      j++, nr_pages *= 512 ) {}
> > +                for ( j = 0; j < nr_pages; j++ )
> > +                    paging_mark_dirty(d, e.mfn + j);
> > +
> > +                /* split super page to 4k page, so that dirty bitmap can
> > +                 * map the dirty page
> > +                 */
> > +                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
> > +                    continue;
> 
> AIUI this code splits log-dirty superpages _after_ they are first seen
> to be dirty.  So the first time they're dirtied, the entire superpage is
> marked, but OTOH if they're never dirtied you don't need to split.  Is
> that right?  

Right, it did need to split superpage which aren't dirtyied.

> If so, I think it needs a comment explaining it.  It took

I will add comment in code.

> me a few minutes to understand this code and convince myself it was
> safe. :)
> 
> > +                atomic_write_ept_entry(&epte[i], e);
> > +            }
> >              e.sa_p2mt = nt;
> >              ept_p2m_type_to_flags(&e, nt, e.access);
> > +            if (!mask)
> > +                e.a = e.d = 0;
> 
> Again, probably best to leave the A-bit set.
> 

Will remove A bit clearing here.

> 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 Jun 29 07:51:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkVyp-0004Ss-Dx; Fri, 29 Jun 2012 07:51:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkVyo-0004Sd-C4
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 07:51:02 +0000
Received: from [85.158.143.99:59070] by server-2.bemta-4.messagelabs.com id
	79/DE-17938-56E5DEF4; Fri, 29 Jun 2012 07:51:01 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1340956259!23336637!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyMTU2Ng==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18152 invoked from network); 29 Jun 2012 07:50:59 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 07:50:59 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 29 Jun 2012 00:50:58 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171532033"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 29 Jun 2012 00:50:58 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 00:50:58 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 00:50:57 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.220]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 15:50:56 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest
	live migration
Thread-Index: AQHNVTVCgrIw+0SUNkag8kO/2PKTnpcQ647g
Date: Fri, 29 Jun 2012 07:50:56 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE263C2@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-5-git-send-email-xudong.hao@intel.com>
	<20120628135220.GQ34995@ocelot.phlegethon.org>
In-Reply-To: <20120628135220.GQ34995@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest
 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

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Thursday, June 28, 2012 9:52 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH v2 4/4] xen: enable EPT dirty bit for guest live
> migration
> 
> At 09:57 +0800 on 20 Jun (1340186267), Xudong Hao wrote:
> > @@ -69,6 +70,11 @@ static void ept_p2m_type_to_flags(ept_entry_t
> *entry, p2m_type_t type, p2m_acces
> >
> entry->mfn);
> >              break;
> >          case p2m_ram_logdirty:
> > +            entry->w = hap_has_dirty_bit;
> > +            entry->r = entry->x = 1;
> > +            /* Not necessarily need to clear A bit, but it is safe anyway */
> > +            entry->a = entry->d = 0;
> > +            break;
> 
> I think it's better not to clear the A bit - it will just cause the
> hardware to issue extra writes to set it.
> 

It's ok for me to not clear A bit here.

> > @@ -760,15 +770,33 @@ static void ept_change_entry_type_page(mfn_t
> ept_page_mfn, int ept_page_level,
> >
> >          if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
> >              ept_change_entry_type_page(_mfn(epte[i].mfn),
> > -                                       ept_page_level - 1, ot, nt);
> > +                                       ept_page_level - 1, ot, nt, d,
> mask);
> >          else
> >          {
> >              e = atomic_read_ept_entry(&epte[i]);
> >              if ( e.sa_p2mt != ot )
> >                  continue;
> >
> > +            if ( e.d && (e.sa_p2mt == p2m_ram_logdirty) )
> > +            {
> > +                int j, nr_pages;
> > +                struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +                for ( j = 0, nr_pages = 1; j < ept_page_level;
> > +                      j++, nr_pages *= 512 ) {}
> > +                for ( j = 0; j < nr_pages; j++ )
> > +                    paging_mark_dirty(d, e.mfn + j);
> > +
> > +                /* split super page to 4k page, so that dirty bitmap can
> > +                 * map the dirty page
> > +                 */
> > +                if ( !ept_split_super_page(p2m, &e, ept_page_level, 0) )
> > +                    continue;
> 
> AIUI this code splits log-dirty superpages _after_ they are first seen
> to be dirty.  So the first time they're dirtied, the entire superpage is
> marked, but OTOH if they're never dirtied you don't need to split.  Is
> that right?  

Right, it did need to split superpage which aren't dirtyied.

> If so, I think it needs a comment explaining it.  It took

I will add comment in code.

> me a few minutes to understand this code and convince myself it was
> safe. :)
> 
> > +                atomic_write_ept_entry(&epte[i], e);
> > +            }
> >              e.sa_p2mt = nt;
> >              ept_p2m_type_to_flags(&e, nt, e.access);
> > +            if (!mask)
> > +                e.a = e.d = 0;
> 
> Again, probably best to leave the A-bit set.
> 

Will remove A bit clearing here.

> 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 Jun 29 07:51:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07: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 1SkVyy-0004U8-Qi; Fri, 29 Jun 2012 07:51: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 1SkVyx-0004Tt-V0
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 07:51:12 +0000
Received: from [85.158.143.35:25150] by server-2.bemta-4.messagelabs.com id
	F6/2F-17938-F6E5DEF4; Fri, 29 Jun 2012 07:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340956252!14676037!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24309 invoked from network); 29 Jun 2012 07:50:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 07:50:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 08:50:52 +0100
Message-Id: <4FED7AA9020000780008CBE5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 08:51:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjkNahhM0Ua=defNR+WVsEbj5k_HZLzfO5m0EHQTC8+xDw@mail.gmail.com>
In-Reply-To: <CABs9EjkNahhM0Ua=defNR+WVsEbj5k_HZLzfO5m0EHQTC8+xDw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] A question about PCI passthrough device BAR memory
 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 29.06.12 at 01:12, Rolu <rolu@roce.org> wrote:
> I am passing through to a domU (among other things) two USB
> controllers. Here is the lspci -v output on the dom0:
> 
> 00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced
> Host Controller #1 (rev 04) (prog-if 20 [EHCI])
> 	Subsystem: ASRock Incorporation Device 1e26
> 	Flags: bus master, medium devsel, latency 0, IRQ 23
> 	Memory at f7d17000 (32-bit, non-prefetchable) [size=1K]
> 	Capabilities: [50] Power Management version 2
> 	Capabilities: [58] Debug port: BAR=1 offset=00a0
> 	Capabilities: [98] PCI Advanced Features
> 	Kernel driver in use: pciback
> 
> And here is the same device's output in the domU:
> 
> 00:07.0 USB controller: Intel Corporation Panther Point USB Enhanced
> Host Controller #1 (rev 04) (prog-if 20 [EHCI])
> 	Subsystem: ASRock Incorporation Device 1e26
> 	Flags: bus master, medium devsel, latency 64, IRQ 44
> 	Memory at f3056000 (32-bit, non-prefetchable) [size=4K]
> 	Capabilities: [50] Power Management version 2
> 	Kernel driver in use: ehci_hcd
> 
> The output for the other controller is essentially the same.
> 
> The peculiar thing here is that the domU thinks it has a 4K memory
> area while the dom0 says it's just 1K. The controllers work, and I
> don't know enough about the PCI subsystems to say if this could cause
> issues, but it seems things could go wrong if the domU ever decides to
> use the other 3K of memory.
> 
> I had a look at how this value was calculated. I found that the guest
> will write all ones to the BAR and then reads it, and the size of the
> memory area is determined by how many bits come back as zero (per the
> PCI specs). In qemu, in hw/pass-through.c, pt_bar_reg_write and
> pt_bar_reg_read are responsible for emulating the writing and reading.
> In pt_bar_reg_read, there is:
> 
> /* align resource size (memory type only) */
> PT_GET_EMUL_SIZE(base->bar_flag, r_size);
> 
> For memory type BAR this macro changes r_size to:
> 
> (((r_size) + XC_PAGE_SIZE - 1) & ~(XC_PAGE_SIZE - 1));
> 
> This looks like it rounds r_size up to the next multiple of
> XC_PAGE_SIZE, and logging confirms this is changing r_size from 0x400
> to 0x1000. This ends up giving the guest the rounded up size, instead
> of the real size.
> 
> So,
> * is this an actual potential problem, or will something else ensure
> that the guest isn't going to try to use the extra memory?

I think it is wrong for qemu-dm to not honor the original size. A
driver handling different device versions/implementations could
look at this and adapt its behavior accordingly (and would likely
fail then).

The second aspect to this - making sure the guest doesn't access
some other guest's (or the host's) MMIO space is something to be
taken care of in the host, actually. The host has to re-assign
(or assign in the first place, should the firmware not have done
so) resources such that no two devices to be passed through to
a guest share the same PAGE_SIZE region for their MMIO blocks.

In the non-pvops kernel we have special code and command line
options for this, but I believe this became redundant with other
code and options in the upstream kernels by now (just never
got around to go in and check how much redundancy there is
and could hence be eliminated).

In any case, these are things that - afaict - need manual admin
action to get right _before_ passing through any device to a
guest.

> * if it needs fixing, how can it be done? I've looked through the code
> but I'm not sure how to fix it without breaking other things.

Since qemu ought to be able to find out the real device's BAR
sizes, it shouldn't be that difficult to make it use that value in
the config space access emulation rather than the rounded
up one - in the worst case it would have to track two values
instead of one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:51:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07: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 1SkVyy-0004U8-Qi; Fri, 29 Jun 2012 07:51: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 1SkVyx-0004Tt-V0
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 07:51:12 +0000
Received: from [85.158.143.35:25150] by server-2.bemta-4.messagelabs.com id
	F6/2F-17938-F6E5DEF4; Fri, 29 Jun 2012 07:51:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340956252!14676037!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24309 invoked from network); 29 Jun 2012 07:50:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 07:50:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 08:50:52 +0100
Message-Id: <4FED7AA9020000780008CBE5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 08:51:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rolu" <rolu@roce.org>
References: <CABs9EjkNahhM0Ua=defNR+WVsEbj5k_HZLzfO5m0EHQTC8+xDw@mail.gmail.com>
In-Reply-To: <CABs9EjkNahhM0Ua=defNR+WVsEbj5k_HZLzfO5m0EHQTC8+xDw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] A question about PCI passthrough device BAR memory
 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 29.06.12 at 01:12, Rolu <rolu@roce.org> wrote:
> I am passing through to a domU (among other things) two USB
> controllers. Here is the lspci -v output on the dom0:
> 
> 00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced
> Host Controller #1 (rev 04) (prog-if 20 [EHCI])
> 	Subsystem: ASRock Incorporation Device 1e26
> 	Flags: bus master, medium devsel, latency 0, IRQ 23
> 	Memory at f7d17000 (32-bit, non-prefetchable) [size=1K]
> 	Capabilities: [50] Power Management version 2
> 	Capabilities: [58] Debug port: BAR=1 offset=00a0
> 	Capabilities: [98] PCI Advanced Features
> 	Kernel driver in use: pciback
> 
> And here is the same device's output in the domU:
> 
> 00:07.0 USB controller: Intel Corporation Panther Point USB Enhanced
> Host Controller #1 (rev 04) (prog-if 20 [EHCI])
> 	Subsystem: ASRock Incorporation Device 1e26
> 	Flags: bus master, medium devsel, latency 64, IRQ 44
> 	Memory at f3056000 (32-bit, non-prefetchable) [size=4K]
> 	Capabilities: [50] Power Management version 2
> 	Kernel driver in use: ehci_hcd
> 
> The output for the other controller is essentially the same.
> 
> The peculiar thing here is that the domU thinks it has a 4K memory
> area while the dom0 says it's just 1K. The controllers work, and I
> don't know enough about the PCI subsystems to say if this could cause
> issues, but it seems things could go wrong if the domU ever decides to
> use the other 3K of memory.
> 
> I had a look at how this value was calculated. I found that the guest
> will write all ones to the BAR and then reads it, and the size of the
> memory area is determined by how many bits come back as zero (per the
> PCI specs). In qemu, in hw/pass-through.c, pt_bar_reg_write and
> pt_bar_reg_read are responsible for emulating the writing and reading.
> In pt_bar_reg_read, there is:
> 
> /* align resource size (memory type only) */
> PT_GET_EMUL_SIZE(base->bar_flag, r_size);
> 
> For memory type BAR this macro changes r_size to:
> 
> (((r_size) + XC_PAGE_SIZE - 1) & ~(XC_PAGE_SIZE - 1));
> 
> This looks like it rounds r_size up to the next multiple of
> XC_PAGE_SIZE, and logging confirms this is changing r_size from 0x400
> to 0x1000. This ends up giving the guest the rounded up size, instead
> of the real size.
> 
> So,
> * is this an actual potential problem, or will something else ensure
> that the guest isn't going to try to use the extra memory?

I think it is wrong for qemu-dm to not honor the original size. A
driver handling different device versions/implementations could
look at this and adapt its behavior accordingly (and would likely
fail then).

The second aspect to this - making sure the guest doesn't access
some other guest's (or the host's) MMIO space is something to be
taken care of in the host, actually. The host has to re-assign
(or assign in the first place, should the firmware not have done
so) resources such that no two devices to be passed through to
a guest share the same PAGE_SIZE region for their MMIO blocks.

In the non-pvops kernel we have special code and command line
options for this, but I believe this became redundant with other
code and options in the upstream kernels by now (just never
got around to go in and check how much redundancy there is
and could hence be eliminated).

In any case, these are things that - afaict - need manual admin
action to get right _before_ passing through any device to a
guest.

> * if it needs fixing, how can it be done? I've looked through the code
> but I'm not sure how to fix it without breaking other things.

Since qemu ought to be able to find out the real device's BAR
sizes, it shouldn't be that difficult to make it use that value in
the config space access emulation rather than the rounded
up one - in the worst case it would have to track two values
instead of one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:54:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07: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 1SkW1z-0004mA-Dn; Fri, 29 Jun 2012 07:54: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 1SkW1y-0004lz-51
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:54:18 +0000
Received: from [85.158.143.99:19011] by server-3.bemta-4.messagelabs.com id
	13/D6-05808-92F5DEF4; Fri, 29 Jun 2012 07:54:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340956456!28818029!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNjcwMTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNjcwMTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10916 invoked from network); 29 Jun 2012 07:54:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Jun 2012 07:54:16 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0KFDQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-047.pools.arcor-ip.net [88.65.90.47])
	by smtp.strato.de (joses mo88) (RZmta 29.19 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id X02ad3o5T59FjI ;
	Fri, 29 Jun 2012 09:54:16 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5940F18637; Fri, 29 Jun 2012 09:54:08 +0200 (CEST)
Date: Fri, 29 Jun 2012 09:54:08 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120629075408.GA27455@aepfle.de>
References: <3a8cd926cd23170cd9d2.1339598492@probook.site>
	<1340727870.3832.168.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340727870.3832.168.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, Ian Campbell wrote:

> On Wed, 2012-06-13 at 15:41 +0100, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1339598410 -7200
> > # Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
> > # Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
> > tools: use --docdir option from configure
> 
> Not just tools: but also docs: since one of the effects of this patch is
> that some "make *doc*" commands now require one to run ./configure
> first.
> 
> Are we happy with that?

I dont care.
Was it a common usage pattern to just run make docs?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:54:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07: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 1SkW1z-0004mA-Dn; Fri, 29 Jun 2012 07:54: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 1SkW1y-0004lz-51
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:54:18 +0000
Received: from [85.158.143.99:19011] by server-3.bemta-4.messagelabs.com id
	13/D6-05808-92F5DEF4; Fri, 29 Jun 2012 07:54:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340956456!28818029!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNjcwMTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNjcwMTk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10916 invoked from network); 29 Jun 2012 07:54:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Jun 2012 07:54:16 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0KFDQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-047.pools.arcor-ip.net [88.65.90.47])
	by smtp.strato.de (joses mo88) (RZmta 29.19 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id X02ad3o5T59FjI ;
	Fri, 29 Jun 2012 09:54:16 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5940F18637; Fri, 29 Jun 2012 09:54:08 +0200 (CEST)
Date: Fri, 29 Jun 2012 09:54:08 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120629075408.GA27455@aepfle.de>
References: <3a8cd926cd23170cd9d2.1339598492@probook.site>
	<1340727870.3832.168.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1340727870.3832.168.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jun 26, Ian Campbell wrote:

> On Wed, 2012-06-13 at 15:41 +0100, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1339598410 -7200
> > # Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
> > # Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
> > tools: use --docdir option from configure
> 
> Not just tools: but also docs: since one of the effects of this patch is
> that some "make *doc*" commands now require one to run ./configure
> first.
> 
> Are we happy with that?

I dont care.
Was it a common usage pattern to just run make docs?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:56:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:56: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 1SkW3X-0004v1-Si; Fri, 29 Jun 2012 07:55: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 1SkW3X-0004uu-9r
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:55:55 +0000
Received: from [85.158.139.83:32085] by server-8.bemta-5.messagelabs.com id
	BA/30-10278-A8F5DEF4; Fri, 29 Jun 2012 07:55:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340956554!22756684!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29857 invoked from network); 29 Jun 2012 07:55:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 07:55:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 08:55:53 +0100
Message-Id: <4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 08:56:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
In-Reply-To: <20120628180007.06bb3fd3@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	IanCampbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
> just return cpuid values, as that's what would happen without the HVM
> container.

Which means you're not leveraging one of the things you could
gain from hybrid (after all, returning the native value to user
mode is one of the weaknesses of PV).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 07:56:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 07:56: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 1SkW3X-0004v1-Si; Fri, 29 Jun 2012 07:55: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 1SkW3X-0004uu-9r
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 07:55:55 +0000
Received: from [85.158.139.83:32085] by server-8.bemta-5.messagelabs.com id
	BA/30-10278-A8F5DEF4; Fri, 29 Jun 2012 07:55:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340956554!22756684!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29857 invoked from network); 29 Jun 2012 07:55:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 07:55:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 08:55:53 +0100
Message-Id: <4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 08:56:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
In-Reply-To: <20120628180007.06bb3fd3@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	IanCampbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
> just return cpuid values, as that's what would happen without the HVM
> container.

Which means you're not leveraging one of the things you could
gain from hybrid (after all, returning the native value to user
mode is one of the weaknesses of PV).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:05:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWCJ-0005pg-1p; Fri, 29 Jun 2012 08:04: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 1SkWCH-0005pb-ED
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:04:57 +0000
Received: from [85.158.143.99:36183] by server-3.bemta-4.messagelabs.com id
	20/09-05808-7A16DEF4; Fri, 29 Jun 2012 08:04:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340957095!22684176!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31706 invoked from network); 29 Jun 2012 08:04:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 08:04:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:04:55 +0100
Message-Id: <4FED7DF4020000780008CC11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:05:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: add ssize_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:

If this is really needed (which I doubt, looking at the two users
and their - respectively - sole callers), then for x86 please put
the definitions alongside the size_t ones.

Until the need for the type is shown, this is a NAK from 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 Jun 29 08:05:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWCJ-0005pg-1p; Fri, 29 Jun 2012 08:04: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 1SkWCH-0005pb-ED
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:04:57 +0000
Received: from [85.158.143.99:36183] by server-3.bemta-4.messagelabs.com id
	20/09-05808-7A16DEF4; Fri, 29 Jun 2012 08:04:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340957095!22684176!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31706 invoked from network); 29 Jun 2012 08:04:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 08:04:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:04:55 +0100
Message-Id: <4FED7DF4020000780008CC11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:05:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: add ssize_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:

If this is really needed (which I doubt, looking at the two users
and their - respectively - sole callers), then for x86 please put
the definitions alongside the size_t ones.

Until the need for the type is shown, this is a NAK from 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 Jun 29 08:07:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWEO-0005x6-Ib; Fri, 29 Jun 2012 08:07: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 1SkWEM-0005x0-VT
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:07:07 +0000
Received: from [85.158.143.35:19348] by server-3.bemta-4.messagelabs.com id
	8B/AC-05808-A226DEF4; Fri, 29 Jun 2012 08:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340957225!14035982!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13140 invoked from network); 29 Jun 2012 08:07:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 08:07:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:07:05 +0100
Message-Id: <4FED7E77020000780008CC16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:07:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:

This appears to be unchanged from v1, so the inconsistency
between implementation (per-vCPU vIRQ) and documentation
(global vIRQ) remains.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:07:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWEO-0005x6-Ib; Fri, 29 Jun 2012 08:07: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 1SkWEM-0005x0-VT
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:07:07 +0000
Received: from [85.158.143.35:19348] by server-3.bemta-4.messagelabs.com id
	8B/AC-05808-A226DEF4; Fri, 29 Jun 2012 08:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340957225!14035982!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13140 invoked from network); 29 Jun 2012 08:07:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 08:07:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:07:05 +0100
Message-Id: <4FED7E77020000780008CC16@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:07:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:

This appears to be unchanged from v1, so the inconsistency
between implementation (per-vCPU vIRQ) and documentation
(global vIRQ) remains.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:07:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 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 1SkWEZ-0005y8-Un; Fri, 29 Jun 2012 08:07: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 1SkWEY-0005xy-RK
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:07:18 +0000
Received: from [85.158.139.83:38764] by server-11.bemta-5.messagelabs.com id
	D9/E3-20400-5326DEF4; Fri, 29 Jun 2012 08:07:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340957237!24964402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15147 invoked from network); 29 Jun 2012 08:07:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:07:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:07:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:07:17 +0100
Message-ID: <1340957235.10942.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 29 Jun 2012 09:07:15 +0100
In-Reply-To: <4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 08:56 +0100, Jan Beulich wrote:
> >>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
> > just return cpuid values, as that's what would happen without the HVM
> > container.
> 
> Which means you're not leveraging one of the things you could
> gain from hybrid (after all, returning the native value to user
> mode is one of the weaknesses of PV).

cpuid masking could happen in the HVM layer too, couldn't it?

Probably "XEN_EMULATE_PREFIX cpuid" and raw "cpuid" ought to return the
same set of PV values in hybrid?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:07:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 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 1SkWEZ-0005y8-Un; Fri, 29 Jun 2012 08:07: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 1SkWEY-0005xy-RK
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:07:18 +0000
Received: from [85.158.139.83:38764] by server-11.bemta-5.messagelabs.com id
	D9/E3-20400-5326DEF4; Fri, 29 Jun 2012 08:07:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340957237!24964402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15147 invoked from network); 29 Jun 2012 08:07:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:07:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:07:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:07:17 +0100
Message-ID: <1340957235.10942.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 29 Jun 2012 09:07:15 +0100
In-Reply-To: <4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 08:56 +0100, Jan Beulich wrote:
> >>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
> > just return cpuid values, as that's what would happen without the HVM
> > container.
> 
> Which means you're not leveraging one of the things you could
> gain from hybrid (after all, returning the native value to user
> mode is one of the weaknesses of PV).

cpuid masking could happen in the HVM layer too, couldn't it?

Probably "XEN_EMULATE_PREFIX cpuid" and raw "cpuid" ought to return the
same set of PV values in hybrid?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:09:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWGj-0006Ar-Fj; Fri, 29 Jun 2012 08: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.Campbell@citrix.com>) id 1SkWGi-0006Al-9p
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:09:32 +0000
Received: from [85.158.143.99:11811] by server-3.bemta-4.messagelabs.com id
	19/B1-05808-BB26DEF4; Fri, 29 Jun 2012 08:09:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340957370!20091207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4113 invoked from network); 29 Jun 2012 08:09:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:09:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:09:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:09:30 +0100
Message-ID: <1340957369.10942.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 29 Jun 2012 09:09:29 +0100
In-Reply-To: <20120628182602.6cc9b432@mantra.us.oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 02:26 +0100, Mukesh Rathor wrote:
> On Thu, 28 Jun 2012 21:09:03 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Thu, Jun 28, 2012 at 06:00:07PM -0700, Mukesh Rathor wrote:
> > > Hi,
> > > 
> > > Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
> > > level process, is running with XEN_EMULATE_PREFIX cpuid. I am
> > > wondering if the prefix is statically put there, or how its put
> > > there?
> > 
> > That is impressive. It should be only be in the kernel via the pvops
> > cpuid call which does this:
> > 
> >  252         asm(XEN_EMULATE_PREFIX "cpuid"
> >  253                 : "=a" (*ax),
> >  254                   "=b" (*bx),
> >  255                   "=c" (*cx),
> >  256                   "=d" (*dx)
> >  257                 : "0" (*ax), "2" (*cx));
> >  258 
> > 
> > 
> > > 
> > > For hybrid, the hvm container traps cpuid, so we don't need to
> > > prefix cpuid. Less code if I don't have to worry about trapping the
> > > invalid op. There seems places where the cpuid is run without the
> > > xen prefix in user mode.
> > 
> > Right, you can make the .cpuid pvops call point to the native.
> 
> Yup. In the kernel I do that already.
> 
> > > 
> > > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user
> > > mode, I just return cpuid values, as that's what would happen
> > > without the HVM container.
> > 
> > You mean in PV mode in user-space you would get the unfiltered cpuid
> > value? Yes, that is true. Which is why I am surprised that dm_mapper
> > (are you sure it is not a kernel thread?) is doing that.
> 
> User mode:
> 
> RIP: 0x0000000000400692 CS: 0x0033

CS 0x033 could still be kernel mode on regular PV 64 bit, but I suppose
not on hybrid?

It's unlikely but not impossible for a userspace developer to have done
some "Xen magic" and used the prefix in userspace.

What version of dm_mapper do you have? I checked the version in Debian
Sid and it doesn't do this (at least not directly).

Are you able to run the dm_mapper process under gdb and inspect it to
find the prefix?

Ian.

> 
> [0]xkdb> dd 0x0000000000400680 32 0
> 0000000000400680:  89f88953e5894855 db8500000000b9d3
> 0000000000400690:  0f6e65780b0f0574 4e89045e890689a2
> 
> thanks,
> Mukesh
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 29 08:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:09:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWGj-0006Ar-Fj; Fri, 29 Jun 2012 08: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.Campbell@citrix.com>) id 1SkWGi-0006Al-9p
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:09:32 +0000
Received: from [85.158.143.99:11811] by server-3.bemta-4.messagelabs.com id
	19/B1-05808-BB26DEF4; Fri, 29 Jun 2012 08:09:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1340957370!20091207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4113 invoked from network); 29 Jun 2012 08:09:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:09:31 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:09:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:09:30 +0100
Message-ID: <1340957369.10942.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 29 Jun 2012 09:09:29 +0100
In-Reply-To: <20120628182602.6cc9b432@mantra.us.oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 02:26 +0100, Mukesh Rathor wrote:
> On Thu, 28 Jun 2012 21:09:03 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Thu, Jun 28, 2012 at 06:00:07PM -0700, Mukesh Rathor wrote:
> > > Hi,
> > > 
> > > Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
> > > level process, is running with XEN_EMULATE_PREFIX cpuid. I am
> > > wondering if the prefix is statically put there, or how its put
> > > there?
> > 
> > That is impressive. It should be only be in the kernel via the pvops
> > cpuid call which does this:
> > 
> >  252         asm(XEN_EMULATE_PREFIX "cpuid"
> >  253                 : "=a" (*ax),
> >  254                   "=b" (*bx),
> >  255                   "=c" (*cx),
> >  256                   "=d" (*dx)
> >  257                 : "0" (*ax), "2" (*cx));
> >  258 
> > 
> > 
> > > 
> > > For hybrid, the hvm container traps cpuid, so we don't need to
> > > prefix cpuid. Less code if I don't have to worry about trapping the
> > > invalid op. There seems places where the cpuid is run without the
> > > xen prefix in user mode.
> > 
> > Right, you can make the .cpuid pvops call point to the native.
> 
> Yup. In the kernel I do that already.
> 
> > > 
> > > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user
> > > mode, I just return cpuid values, as that's what would happen
> > > without the HVM container.
> > 
> > You mean in PV mode in user-space you would get the unfiltered cpuid
> > value? Yes, that is true. Which is why I am surprised that dm_mapper
> > (are you sure it is not a kernel thread?) is doing that.
> 
> User mode:
> 
> RIP: 0x0000000000400692 CS: 0x0033

CS 0x033 could still be kernel mode on regular PV 64 bit, but I suppose
not on hybrid?

It's unlikely but not impossible for a userspace developer to have done
some "Xen magic" and used the prefix in userspace.

What version of dm_mapper do you have? I checked the version in Debian
Sid and it doesn't do this (at least not directly).

Are you able to run the dm_mapper process under gdb and inspect it to
find the prefix?

Ian.

> 
> [0]xkdb> dd 0x0000000000400680 32 0
> 0000000000400680:  89f88953e5894855 db8500000000b9d3
> 0000000000400690:  0f6e65780b0f0574 4e89045e890689a2
> 
> thanks,
> Mukesh
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 29 08:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWHO-0006GH-2f; Fri, 29 Jun 2012 08:10:14 +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 1SkWHM-0006Fs-G5
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:10:12 +0000
Received: from [85.158.143.35:43888] by server-1.bemta-4.messagelabs.com id
	02/7A-24392-3E26DEF4; Fri, 29 Jun 2012 08:10:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340957409!18690592!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4687 invoked from network); 29 Jun 2012 08:10:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 08:10:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:10:08 +0100
Message-Id: <4FED7F2E020000780008CC20@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:10:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>,<xen-devel@lists.xen.org>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-4-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-4-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH 3/5] xen: Enforce introduce
 guest_handle_for_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

>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
> This helper turns a field of a GUEST_HANDLE in
> a GUEST_HANDLE.
> 
> Signed-off-by: Jean Guyader <jean.guyader@citrix.com>

Minor or not - this patch is not from you originally.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWHO-0006GH-2f; Fri, 29 Jun 2012 08:10:14 +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 1SkWHM-0006Fs-G5
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:10:12 +0000
Received: from [85.158.143.35:43888] by server-1.bemta-4.messagelabs.com id
	02/7A-24392-3E26DEF4; Fri, 29 Jun 2012 08:10:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340957409!18690592!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4687 invoked from network); 29 Jun 2012 08:10:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 08:10:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:10:08 +0100
Message-Id: <4FED7F2E020000780008CC20@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:10:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>,<xen-devel@lists.xen.org>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-4-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-4-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH 3/5] xen: Enforce introduce
 guest_handle_for_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

>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
> This helper turns a field of a GUEST_HANDLE in
> a GUEST_HANDLE.
> 
> Signed-off-by: Jean Guyader <jean.guyader@citrix.com>

Minor or not - this patch is not from you originally.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:10:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWHu-0006LQ-Ga; Fri, 29 Jun 2012 08:10:46 +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 1SkWHt-0006L5-8c
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:10:45 +0000
Received: from [193.109.254.147:27597] by server-12.bemta-14.messagelabs.com
	id 40/69-30461-4036DEF4; Fri, 29 Jun 2012 08:10:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340957439!9127156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7089 invoked from network); 29 Jun 2012 08:10:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:10:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:10:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:10:37 +0100
Message-ID: <1340957436.10942.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 29 Jun 2012 09:10:36 +0100
In-Reply-To: <20120629075408.GA27455@aepfle.de>
References: <3a8cd926cd23170cd9d2.1339598492@probook.site>
	<1340727870.3832.168.camel@zakaz.uk.xensource.com>
	<20120629075408.GA27455@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 08:54 +0100, Olaf Hering wrote:
> On Tue, Jun 26, Ian Campbell wrote:
> 
> > On Wed, 2012-06-13 at 15:41 +0100, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1339598410 -7200
> > > # Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
> > > # Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
> > > tools: use --docdir option from configure
> > 
> > Not just tools: but also docs: since one of the effects of this patch is
> > that some "make *doc*" commands now require one to run ./configure
> > first.
> > 
> > Are we happy with that?
> 
> I dont care.
> Was it a common usage pattern to just run make docs?

I don't know about common but e.g. the script which populates
http://xenbits.xen.org/docs/unstable/ does. I don't mind updating that
one but I just wanted to see if anyone else had an opinion.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:10:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWHu-0006LQ-Ga; Fri, 29 Jun 2012 08:10:46 +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 1SkWHt-0006L5-8c
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:10:45 +0000
Received: from [193.109.254.147:27597] by server-12.bemta-14.messagelabs.com
	id 40/69-30461-4036DEF4; Fri, 29 Jun 2012 08:10:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1340957439!9127156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7089 invoked from network); 29 Jun 2012 08:10:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:10:39 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:10:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:10:37 +0100
Message-ID: <1340957436.10942.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 29 Jun 2012 09:10:36 +0100
In-Reply-To: <20120629075408.GA27455@aepfle.de>
References: <3a8cd926cd23170cd9d2.1339598492@probook.site>
	<1340727870.3832.168.camel@zakaz.uk.xensource.com>
	<20120629075408.GA27455@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: use --docdir option from configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 08:54 +0100, Olaf Hering wrote:
> On Tue, Jun 26, Ian Campbell wrote:
> 
> > On Wed, 2012-06-13 at 15:41 +0100, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1339598410 -7200
> > > # Node ID 3a8cd926cd23170cd9d2eb127ef1e1074b369c04
> > > # Parent  9d6fb03ba8e9266bbfd7a8dc92eb540a7b0a42f7
> > > tools: use --docdir option from configure
> > 
> > Not just tools: but also docs: since one of the effects of this patch is
> > that some "make *doc*" commands now require one to run ./configure
> > first.
> > 
> > Are we happy with that?
> 
> I dont care.
> Was it a common usage pattern to just run make docs?

I don't know about common but e.g. the script which populates
http://xenbits.xen.org/docs/unstable/ does. I don't mind updating that
one but I just wanted to see if anyone else had an opinion.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:14:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWLY-0006j7-5k; Fri, 29 Jun 2012 08:14: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 1SkWLW-0006iz-JJ
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:30 +0000
Received: from [85.158.138.51:58545] by server-10.bemta-3.messagelabs.com id
	9A/F4-01753-5E36DEF4; Fri, 29 Jun 2012 08:14:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340957667!21241258!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5800 invoked from network); 29 Jun 2012 08:14:28 -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;
	29 Jun 2012 08:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482997"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-R1;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: 77993401a44fad90f1c3f75d28d497e0551c8530
Message-ID: <77993401a44fad90f1c3.1340957651@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 4 of 4 V2] xl: initialise domid to an explicitly
	invalid 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340956702 -3600
# Node ID 77993401a44fad90f1c3f75d28d497e0551c8530
# Parent  426b2f7429a792b9e54cbb8439d357c8edbd350a
xl: initialise domid to an explicitly invalid value

also ensure it is invalid whenever we destroy the domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 426b2f7429a7 -r 77993401a44f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jun 29 08:58:19 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 29 08:58:22 2012 +0100
@@ -68,7 +68,8 @@ libxl_ctx *ctx;
 xlchild children[child_max];
 
 /* when we operate on a domain, it is this one: */
-static uint32_t domid;
+#define INVALID_DOMID ~0
+static uint32_t domid = INVALID_DOMID;
 static const char *common_domname;
 static int fd_lock = -1;
 
@@ -1396,6 +1397,7 @@ static int handle_domain_death(uint32_t 
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1458,6 +1460,12 @@ static int preserve_domain(uint32_t domi
     LOG("Preserving domain %d %s with suffix%s", domid, d_config->c_info.name, stime);
     rc = libxl_domain_preserve(ctx, domid, &d_config->c_info, stime, new_uuid);
 
+    /*
+     * Although domid still exists it is no longer the one we are concerned
+     * with.
+     */
+    domid = INVALID_DOMID;
+
     return rc == 0 ? 1 : 0;
 }
 
@@ -1745,7 +1753,7 @@ static int create_domain(struct domain_c
         goto out;
 
 start:
-    domid = -1;
+    assert(domid == INVALID_DOMID);
 
     rc = acquire_lock();
     if (rc < 0)
@@ -1994,8 +2002,10 @@ start:
 
 error_out:
     release_lock();
-    if (libxl_domid_valid_guest(domid))
+    if (libxl_domid_valid_guest(domid)) {
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
+    }
 
 out:
     if (logfile != 2)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:14:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWLY-0006j7-5k; Fri, 29 Jun 2012 08:14: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 1SkWLW-0006iz-JJ
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:30 +0000
Received: from [85.158.138.51:58545] by server-10.bemta-3.messagelabs.com id
	9A/F4-01753-5E36DEF4; Fri, 29 Jun 2012 08:14:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1340957667!21241258!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5800 invoked from network); 29 Jun 2012 08:14:28 -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;
	29 Jun 2012 08:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482997"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-R1;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: 77993401a44fad90f1c3f75d28d497e0551c8530
Message-ID: <77993401a44fad90f1c3.1340957651@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:11 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 4 of 4 V2] xl: initialise domid to an explicitly
	invalid 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340956702 -3600
# Node ID 77993401a44fad90f1c3f75d28d497e0551c8530
# Parent  426b2f7429a792b9e54cbb8439d357c8edbd350a
xl: initialise domid to an explicitly invalid value

also ensure it is invalid whenever we destroy the domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 426b2f7429a7 -r 77993401a44f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jun 29 08:58:19 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jun 29 08:58:22 2012 +0100
@@ -68,7 +68,8 @@ libxl_ctx *ctx;
 xlchild children[child_max];
 
 /* when we operate on a domain, it is this one: */
-static uint32_t domid;
+#define INVALID_DOMID ~0
+static uint32_t domid = INVALID_DOMID;
 static const char *common_domname;
 static int fd_lock = -1;
 
@@ -1396,6 +1397,7 @@ static int handle_domain_death(uint32_t 
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
         LOG("Domain %d needs to be cleaned up: destroying the domain", domid);
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
@@ -1458,6 +1460,12 @@ static int preserve_domain(uint32_t domi
     LOG("Preserving domain %d %s with suffix%s", domid, d_config->c_info.name, stime);
     rc = libxl_domain_preserve(ctx, domid, &d_config->c_info, stime, new_uuid);
 
+    /*
+     * Although domid still exists it is no longer the one we are concerned
+     * with.
+     */
+    domid = INVALID_DOMID;
+
     return rc == 0 ? 1 : 0;
 }
 
@@ -1745,7 +1753,7 @@ static int create_domain(struct domain_c
         goto out;
 
 start:
-    domid = -1;
+    assert(domid == INVALID_DOMID);
 
     rc = acquire_lock();
     if (rc < 0)
@@ -1994,8 +2002,10 @@ start:
 
 error_out:
     release_lock();
-    if (libxl_domid_valid_guest(domid))
+    if (libxl_domid_valid_guest(domid)) {
         libxl_domain_destroy(ctx, domid);
+        domid = INVALID_DOMID;
+    }
 
 out:
     if (logfile != 2)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:14:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWLk-0006kH-IX; Fri, 29 Jun 2012 08:14: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 1SkWLi-0006k9-NE
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:42 +0000
Received: from [85.158.143.99:48584] by server-2.bemta-4.messagelabs.com id
	6D/75-17938-1F36DEF4; Fri, 29 Jun 2012 08:14:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340957664!24446832!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5219 invoked from network); 29 Jun 2012 08:14:25 -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;
	29 Jun 2012 08:14:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482995"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-QM;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: 426b2f7429a792b9e54cbb8439d357c8edbd350a
Message-ID: <426b2f7429a792b9e54c.1340957650@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 3 of 4 V2] libxl: log on failure in cpupool_info
 and libxl__domain_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340956699 -3600
# Node ID 426b2f7429a792b9e54cbb8439d357c8edbd350a
# Parent  763756d2590c84816782e2ffc2102c774366ed50
libxl: log on failure in cpupool_info and libxl__domain_cpupool

Also in cpupool_info propagate the failure value from
libxl_cpumap_alloc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 763756d2590c -r 426b2f7429a7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jun 29 08:58:19 2012 +0100
@@ -571,16 +571,27 @@ static int cpupool_info(libxl__gc *gc,
 
     xcinfo = xc_cpupool_getinfo(CTX->xch, poolid);
     if (xcinfo == NULL)
+    {
+        LOGE(ERROR, "failed to get info for cpupool%d\n", poolid);
         return ERROR_FAIL;
+    }
 
     if (exact && xcinfo->cpupool_id != poolid)
+    {
+        LOG(ERROR, "got info for cpupool%d, wanted cpupool%d\n",
+            xcinfo->cpupool_id, poolid);
         goto out;
+    }
 
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap, 0))
+    rc = libxl_cpumap_alloc(CTX, &info->cpumap, 0);
+    if (rc)
+    {
+        LOG(ERROR, "unable to allocate cpumap %d\n", rc);
         goto out;
+    }
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
 
     rc = 0;
diff -r 763756d2590c -r 426b2f7429a7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 29 08:58:19 2012 +0100
@@ -64,10 +64,15 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
     ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
     if (ret != 1)
+    {
+        LOGE(ERROR, "getinfolist failed %d\n", ret);
         return ERROR_FAIL;
+    }
     if (info.domain != domid)
+    {
+        LOGE(ERROR, "got info for dom%d, wanted dom%d\n", info.domain, domid);
         return ERROR_FAIL;
-
+    }
     return info.cpupool;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:14:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWLk-0006kH-IX; Fri, 29 Jun 2012 08:14: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 1SkWLi-0006k9-NE
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:42 +0000
Received: from [85.158.143.99:48584] by server-2.bemta-4.messagelabs.com id
	6D/75-17938-1F36DEF4; Fri, 29 Jun 2012 08:14:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1340957664!24446832!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5219 invoked from network); 29 Jun 2012 08:14:25 -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;
	29 Jun 2012 08:14:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482995"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-QM;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: 426b2f7429a792b9e54cbb8439d357c8edbd350a
Message-ID: <426b2f7429a792b9e54c.1340957650@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:10 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 3 of 4 V2] libxl: log on failure in cpupool_info
 and libxl__domain_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340956699 -3600
# Node ID 426b2f7429a792b9e54cbb8439d357c8edbd350a
# Parent  763756d2590c84816782e2ffc2102c774366ed50
libxl: log on failure in cpupool_info and libxl__domain_cpupool

Also in cpupool_info propagate the failure value from
libxl_cpumap_alloc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 763756d2590c -r 426b2f7429a7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jun 29 08:58:19 2012 +0100
@@ -571,16 +571,27 @@ static int cpupool_info(libxl__gc *gc,
 
     xcinfo = xc_cpupool_getinfo(CTX->xch, poolid);
     if (xcinfo == NULL)
+    {
+        LOGE(ERROR, "failed to get info for cpupool%d\n", poolid);
         return ERROR_FAIL;
+    }
 
     if (exact && xcinfo->cpupool_id != poolid)
+    {
+        LOG(ERROR, "got info for cpupool%d, wanted cpupool%d\n",
+            xcinfo->cpupool_id, poolid);
         goto out;
+    }
 
     info->poolid = xcinfo->cpupool_id;
     info->sched = xcinfo->sched_id;
     info->n_dom = xcinfo->n_dom;
-    if (libxl_cpumap_alloc(CTX, &info->cpumap, 0))
+    rc = libxl_cpumap_alloc(CTX, &info->cpumap, 0);
+    if (rc)
+    {
+        LOG(ERROR, "unable to allocate cpumap %d\n", rc);
         goto out;
+    }
     memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
 
     rc = 0;
diff -r 763756d2590c -r 426b2f7429a7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 29 08:58:19 2012 +0100
@@ -64,10 +64,15 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
     ret = xc_domain_getinfolist(CTX->xch, domid, 1, &info);
     if (ret != 1)
+    {
+        LOGE(ERROR, "getinfolist failed %d\n", ret);
         return ERROR_FAIL;
+    }
     if (info.domain != domid)
+    {
+        LOGE(ERROR, "got info for dom%d, wanted dom%d\n", info.domain, domid);
         return ERROR_FAIL;
-
+    }
     return info.cpupool;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:14:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:14: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 1SkWLl-0006kp-UJ; Fri, 29 Jun 2012 08:14: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 1SkWLl-0006ka-Dq
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:45 +0000
Received: from [85.158.143.35:31898] by server-1.bemta-4.messagelabs.com id
	85/91-24392-4F36DEF4; Fri, 29 Jun 2012 08:14:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340957648!7296745!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4222 invoked from network); 29 Jun 2012 08:14:23 -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;
	29 Jun 2012 08:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482993"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-Ow;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: d12ad3958ca787f565ba0fe67d7e97706314e46d
Message-ID: <d12ad3958ca787f565ba.1340957648@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 1 of 4 V2] libxl: initialise cpupoolinfo in
 libxl__domain_scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340956631 -3600
# Node ID d12ad3958ca787f565ba0fe67d7e97706314e46d
# Parent  850af6e1985ed0ed0393846c1aae749e2742de8a
libxl: initialise cpupoolinfo in libxl__domain_scheduler

If libxl_cpupool_info fails then we would call
libxl_cpupoolinfo_dispose on an uninitialised struct, and possibly
free an invalid pointer.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 850af6e1985e -r d12ad3958ca7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
@@ -81,6 +81,7 @@ libxl_scheduler libxl__domain_scheduler(
     if (cpupool < 0)
         return sched;
 
+    libxl_cpupoolinfo_init(&poolinfo);
     rc = libxl_cpupool_info(CTX, &poolinfo, cpupool);
     if (rc < 0)
         goto out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:14:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:14: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 1SkWLl-0006kp-UJ; Fri, 29 Jun 2012 08:14: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 1SkWLl-0006ka-Dq
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:45 +0000
Received: from [85.158.143.35:31898] by server-1.bemta-4.messagelabs.com id
	85/91-24392-4F36DEF4; Fri, 29 Jun 2012 08:14:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340957648!7296745!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4222 invoked from network); 29 Jun 2012 08:14:23 -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;
	29 Jun 2012 08:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482993"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-Ow;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: d12ad3958ca787f565ba0fe67d7e97706314e46d
Message-ID: <d12ad3958ca787f565ba.1340957648@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:08 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 1 of 4 V2] libxl: initialise cpupoolinfo in
 libxl__domain_scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340956631 -3600
# Node ID d12ad3958ca787f565ba0fe67d7e97706314e46d
# Parent  850af6e1985ed0ed0393846c1aae749e2742de8a
libxl: initialise cpupoolinfo in libxl__domain_scheduler

If libxl_cpupool_info fails then we would call
libxl_cpupoolinfo_dispose on an uninitialised struct, and possibly
free an invalid pointer.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 850af6e1985e -r d12ad3958ca7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
@@ -81,6 +81,7 @@ libxl_scheduler libxl__domain_scheduler(
     if (cpupool < 0)
         return sched;
 
+    libxl_cpupoolinfo_init(&poolinfo);
     rc = libxl_cpupool_info(CTX, &poolinfo, cpupool);
     if (rc < 0)
         goto out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:15:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWLv-0006nA-As; Fri, 29 Jun 2012 08:14: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 1SkWLu-0006mh-3q
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:54 +0000
Received: from [85.158.143.35:15968] by server-2.bemta-4.messagelabs.com id
	0B/C5-17938-DF36DEF4; Fri, 29 Jun 2012 08:14:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340957648!7296745!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4390 invoked from network); 29 Jun 2012 08:14:25 -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;
	29 Jun 2012 08:14:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482994"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-PW;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: 763756d2590c84816782e2ffc2102c774366ed50
Message-ID: <763756d2590c84816782.1340957649@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 2 of 4 V2] libxl: correct type of cpupool
	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 Ian Campbell <ian.campbell@citrix.com>
# Date 1340956631 -3600
# Node ID 763756d2590c84816782e2ffc2102c774366ed50
# Parent  d12ad3958ca787f565ba0fe67d7e97706314e46d
libxl: correct type of cpupool variable.

libxl__domain_cpupool returns int and can return ERROR_* so we need to
use a signed type.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d12ad3958ca7 -r 763756d2590c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
@@ -73,7 +73,7 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
 libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid)
 {
-    uint32_t cpupool = libxl__domain_cpupool(gc, domid);
+    int cpupool = libxl__domain_cpupool(gc, domid);
     libxl_cpupoolinfo poolinfo;
     libxl_scheduler sched = LIBXL_SCHEDULER_UNKNOWN;
     int rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:15:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWLv-0006nA-As; Fri, 29 Jun 2012 08:14: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 1SkWLu-0006mh-3q
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:14:54 +0000
Received: from [85.158.143.35:15968] by server-2.bemta-4.messagelabs.com id
	0B/C5-17938-DF36DEF4; Fri, 29 Jun 2012 08:14:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340957648!7296745!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4390 invoked from network); 29 Jun 2012 08:14:25 -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;
	29 Jun 2012 08:14:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482994"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-PW;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
X-Mercurial-Node: 763756d2590c84816782e2ffc2102c774366ed50
Message-ID: <763756d2590c84816782.1340957649@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1340957647@cosworth.uk.xensource.com>
References: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:09 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 2 of 4 V2] libxl: correct type of cpupool
	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 Ian Campbell <ian.campbell@citrix.com>
# Date 1340956631 -3600
# Node ID 763756d2590c84816782e2ffc2102c774366ed50
# Parent  d12ad3958ca787f565ba0fe67d7e97706314e46d
libxl: correct type of cpupool variable.

libxl__domain_cpupool returns int and can return ERROR_* so we need to
use a signed type.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d12ad3958ca7 -r 763756d2590c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
+++ b/tools/libxl/libxl_dom.c	Fri Jun 29 08:57:11 2012 +0100
@@ -73,7 +73,7 @@ int libxl__domain_cpupool(libxl__gc *gc,
 
 libxl_scheduler libxl__domain_scheduler(libxl__gc *gc, uint32_t domid)
 {
-    uint32_t cpupool = libxl__domain_cpupool(gc, domid);
+    int cpupool = libxl__domain_cpupool(gc, domid);
     libxl_cpupoolinfo poolinfo;
     libxl_scheduler sched = LIBXL_SCHEDULER_UNKNOWN;
     int rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWMr-00071I-Pj; Fri, 29 Jun 2012 08:15: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 1SkWMq-00070t-Mm
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:15:52 +0000
Received: from [85.158.143.35:22883] by server-2.bemta-4.messagelabs.com id
	55/B7-17938-7346DEF4; Fri, 29 Jun 2012 08:15:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340957648!7296745!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4465 invoked from network); 29 Jun 2012 08:14:28 -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;
	29 Jun 2012 08:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482996"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-O8;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 0 of 4 V2] xl: guest reboot cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These are miscellaneous fixes I noticed while tracking down the guest
reboot failures in light 13302, previously posted as 'xl: fix guest
reboot failures'.

The reboot issue is already fixed but these remained outstanding. I've
rebased to current tip and fixed the trivial conflict in cpupool_info.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWMr-00071I-Pj; Fri, 29 Jun 2012 08:15: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 1SkWMq-00070t-Mm
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:15:52 +0000
Received: from [85.158.143.35:22883] by server-2.bemta-4.messagelabs.com id
	55/B7-17938-7346DEF4; Fri, 29 Jun 2012 08:15:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1340957648!7296745!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjMwOTE=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4465 invoked from network); 29 Jun 2012 08:14:28 -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;
	29 Jun 2012 08:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336363200"; d="scan'208";a="200482996"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 04:14:08 -0400
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 04:14:08 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1SkWL9-0000Uq-O8;
	Fri, 29 Jun 2012 09:14:07 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1340957647@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 29 Jun 2012 09:14:07 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, Dario Faggioli <raistlin@linux.it>
Subject: [Xen-devel] [PATCH 0 of 4 V2] xl: guest reboot cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These are miscellaneous fixes I noticed while tracking down the guest
reboot failures in light 13302, previously posted as 'xl: fix guest
reboot failures'.

The reboot issue is already fixed but these remained outstanding. I've
rebased to current tip and fixed the trivial conflict in cpupool_info.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWXa-0007Zw-JJ; Fri, 29 Jun 2012 08:26:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkWXZ-0007Zp-NW
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:26:57 +0000
Received: from [193.109.254.147:46202] by server-11.bemta-14.messagelabs.com
	id 66/CD-24843-0D66DEF4; Fri, 29 Jun 2012 08:26:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340958416!6746730!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18755 invoked from network); 29 Jun 2012 08:26:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:26:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:26:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:26:55 +0100
Message-ID: <1340958413.10942.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 29 Jun 2012 09:26:53 +0100
In-Reply-To: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
References: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 16:21 +0100, Anthony PERARD wrote:
> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
> parameter. This patch changes the ownership of the buifioreq event channel to
> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
> 
> This patch introduces an helper to replace a xen port.
> 
> This fix the initialization of QEMU inside the stubdomain.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Thought I'd already acked this but apparently not. This fixes stub
domains for me.

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>

CCing Hypervisor maintainers...

> ---
> Change:
>   - an helper
>   - the replacement of the buferioreq evtchn is inside iorp->lock now.
> 
>  xen/arch/x86/hvm/hvm.c |   37 ++++++++++++++++++++++++++++---------
>  1 files changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e0d495d..e8e86c0 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3664,6 +3664,21 @@ static int hvmop_flush_tlb_all(void)
>      return 0;
>  }
>  
> +static int hvm_replace_event_channel(struct vcpu *v, uint64_t remote_domid,
> +                                     int *port)
> +{
> +    int old_port, new_port;
> +
> +    new_port = alloc_unbound_xen_event_channel(v, remote_domid, NULL);
> +    if ( new_port < 0 )
> +        return new_port;
> +
> +    /* xchg() ensures that only we free_xen_event_channel() */
> +    old_port = xchg(port, new_port);
> +    free_xen_event_channel(v, old_port);
> +    return 0;
> +}
> +
>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>  
>  {
> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>                  iorp = &d->arch.hvm_domain.ioreq;
>                  for_each_vcpu ( d, v )
>                  {
> -                    int old_port, new_port;
> -                    new_port = alloc_unbound_xen_event_channel(
> -                        v, a.value, NULL);
> -                    if ( new_port < 0 )
> -                    {
> -                        rc = new_port;
> +                    rc = hvm_replace_event_channel(v, a.value,
> +                                                   &v->arch.hvm_vcpu.xen_port);
> +                    if ( rc )
>                          break;
> +
> +                    if ( v->vcpu_id == 0 )
> +                    {
> +                        spin_lock(&iorp->lock);
> +                        rc = hvm_replace_event_channel(v, a.value,
> +                            (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
> +                        spin_unlock(&iorp->lock);
> +                        if ( rc )
> +                            break;
>                      }
> -                    /* xchg() ensures that only we free_xen_event_channel() */
> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
> -                    free_xen_event_channel(v, old_port);
> +
>                      spin_lock(&iorp->lock);
>                      if ( iorp->va != NULL )
>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWXa-0007Zw-JJ; Fri, 29 Jun 2012 08:26:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkWXZ-0007Zp-NW
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:26:57 +0000
Received: from [193.109.254.147:46202] by server-11.bemta-14.messagelabs.com
	id 66/CD-24843-0D66DEF4; Fri, 29 Jun 2012 08:26:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340958416!6746730!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18755 invoked from network); 29 Jun 2012 08:26:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:26:56 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13283914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:26:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:26:55 +0100
Message-ID: <1340958413.10942.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 29 Jun 2012 09:26:53 +0100
In-Reply-To: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
References: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-06-26 at 16:21 +0100, Anthony PERARD wrote:
> This is a missing part from the previous patch that add the BUFIOREQ_EVTCHN
> parameter. This patch changes the ownership of the buifioreq event channel to
> the stubdom (when HVM_PARAM_DM_DOMAIN is set within the stubdom).
> 
> This patch introduces an helper to replace a xen port.
> 
> This fix the initialization of QEMU inside the stubdomain.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Thought I'd already acked this but apparently not. This fixes stub
domains for me.

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>

CCing Hypervisor maintainers...

> ---
> Change:
>   - an helper
>   - the replacement of the buferioreq evtchn is inside iorp->lock now.
> 
>  xen/arch/x86/hvm/hvm.c |   37 ++++++++++++++++++++++++++++---------
>  1 files changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e0d495d..e8e86c0 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3664,6 +3664,21 @@ static int hvmop_flush_tlb_all(void)
>      return 0;
>  }
>  
> +static int hvm_replace_event_channel(struct vcpu *v, uint64_t remote_domid,
> +                                     int *port)
> +{
> +    int old_port, new_port;
> +
> +    new_port = alloc_unbound_xen_event_channel(v, remote_domid, NULL);
> +    if ( new_port < 0 )
> +        return new_port;
> +
> +    /* xchg() ensures that only we free_xen_event_channel() */
> +    old_port = xchg(port, new_port);
> +    free_xen_event_channel(v, old_port);
> +    return 0;
> +}
> +
>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>  
>  {
> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>                  iorp = &d->arch.hvm_domain.ioreq;
>                  for_each_vcpu ( d, v )
>                  {
> -                    int old_port, new_port;
> -                    new_port = alloc_unbound_xen_event_channel(
> -                        v, a.value, NULL);
> -                    if ( new_port < 0 )
> -                    {
> -                        rc = new_port;
> +                    rc = hvm_replace_event_channel(v, a.value,
> +                                                   &v->arch.hvm_vcpu.xen_port);
> +                    if ( rc )
>                          break;
> +
> +                    if ( v->vcpu_id == 0 )
> +                    {
> +                        spin_lock(&iorp->lock);
> +                        rc = hvm_replace_event_channel(v, a.value,
> +                            (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
> +                        spin_unlock(&iorp->lock);
> +                        if ( rc )
> +                            break;
>                      }
> -                    /* xchg() ensures that only we free_xen_event_channel() */
> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
> -                    free_xen_event_channel(v, old_port);
> +
>                      spin_lock(&iorp->lock);
>                      if ( iorp->va != NULL )
>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:32:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWcw-0007s3-GL; Fri, 29 Jun 2012 08:32:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SkWcu-0007ru-8B
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:32:28 +0000
Received: from [85.158.139.83:14581] by server-3.bemta-5.messagelabs.com id
	80/CB-03367-B186DEF4; Fri, 29 Jun 2012 08:32:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340958746!22765453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29038 invoked from network); 29 Jun 2012 08:32:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 08:32:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:32:26 +0100
Message-Id: <4FED8467020000780008CC68@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:33:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
> --- /dev/null
> +++ b/xen/include/public/v4v.h
> @@ -0,0 +1,240 @@
> +/******************************************************************************
> + * V4V
> + *
> + * Version 2 of v2v (Virtual-to-Virtual)
> + *
> + * Copyright (c) 2010, Citrix Systems
> + *
> + * 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
> + */
> +
> +#ifndef __XEN_PUBLIC_V4V_H__
> +#define __XEN_PUBLIC_V4V_H__
> +
> +#include "xen.h"
> +
> +/*
> + * Structure definitions
> + */
> +
> +#define V4V_PROTO_DGRAM		0x3c2c1db8
> +#define V4V_PROTO_STREAM 	0x70f6a8e5
> +
> +#ifdef __i386__

How about ARM?

> +# define V4V_RING_MAGIC         0xdf6977f231abd910ULL
> +# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302dULL

Is there any reason these can't be also used for 64-bit?

> +#else
> +# define V4V_RING_MAGIC         0xdf6977f231abd910
> +# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302d
> +#endif
> +#define V4V_DOMID_INVALID       (0x7FFFU)

Any reason not to use DOMID_INVALID instead?

> +#define V4V_DOMID_NONE          V4V_DOMID_INVALID
> +#define V4V_DOMID_ANY           V4V_DOMID_INVALID
> +#define V4V_PORT_NONE           0
> +
> +/*
> + * struct v4v_iov
> + * {
> + *      64 bits: iov_base
> + *      64 bits: iov_len
> + * }
> + */

What's the point of not defining the types here?

> +
> +/*
> + * struct v4v_addr
> + * {
> + *      32 bits: port
> + *      16 bits: domid
> + * }
> + */
> +
> +/*
> + * v4v_ring_id
> + * {
> + *      struct v4v_addr: addr
> + *      16 bits: partner
> + * }
> + */
> +
> +/*
> + * v4v_ring
> + * {
> + *      64 bits: magic
> + *      v4v_rind_id: id
> + *      32 bits: len
> + *      32 bits: rx_ptr
> + *      32 bits: tx_ptr
> + *      64 bits: padding
> + *      ... : ring
> + * }
> + *
> + * id:
> + * xen only looks at this during register/unregister
> + * and will fill in id.addr.domain
> + *
> + * rx_ptr: rx pointer, modified by domain
> + * tx_ptr: tx pointer, modified by xen
> + */
> +
> +#ifdef __i386__
> +#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92aULL

Same here as above.

> +#else
> +#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92a
> +#endif
> +
> +#define V4V_RING_DATA_F_EMPTY       1U << 0 /* Ring is empty */
> +#define V4V_RING_DATA_F_EXISTS      1U << 1 /* Ring exists */
> +#define V4V_RING_DATA_F_PENDING     1U << 2 /* Pending interrupt exists - do not
> +                                               rely on this field - for
> +                                               profiling only */
> +#define V4V_RING_DATA_F_SUFFICIENT  1U << 3 /* Sufficient space to queue
> +                                               space_required bytes exists */
> +
> +/*
> + * v4v_ring_data_ent
> + * {
> + *      v4v_addr: ring
> + *      16 bits: flags
> + *      16 bits: padding
> + *      32 bits: space_required
> + *      32 bits: max_message_size
> + * }
> + */
> +
> +/*
> + * v4v_ring_data
> + * {
> + *      64 bits: magic (V4V_RING_DATA_MAGIC)
> + *      32 bits: nent
> + *      32 bits: padding
> + *      256 bits: reserved
> + *      ... : v4v_ring_data_ent
> + * }
> + */
> +
> +
> +#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
> +/*
> + * Messages on the ring are padded to 128 bits
> + * Len here refers to the exact length of the data not including the
> + * 128 bit header. The message uses
> + * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
> + */
> +
> +/*
> + * v4v_stream_header
> + * {
> + *      32 bits: flags
> + *      32 bits: conid
> + * }
> + */
> +
> +/*
> + * v4v_ring_message_header
> + * {
> + *      32 bits: len
> + *      v4v_addr: source
> + *      32 bits: protocol
> + *      ... : data
> + * }
> + */
> +
> +/*
> + * HYPERCALLS
> + */
> +
> +#define V4VOP_register_ring 	1
> +/*
> + * Registers a ring with Xen, if a ring with the same v4v_ring_id exists,
> + * this ring takes its place, registration will not change tx_ptr
> + * unless it is invalid
> + *
> + * do_v4v_op(V4VOP_unregister_ring,
> + *           v4v_ring, XEN_GUEST_HANDLE(v4v_pfn),
> + *           NULL, npage, 0)
> + */
> +
> +
> +#define V4VOP_unregister_ring 	2
> +/*
> + * Unregister a ring.
> + *
> + * v4v_hypercall(V4VOP_send, v4v_ring, NULL, NULL, 0, 0)

Assuming this and the earlier do_v4v_op() refer to the same
thing, please use a single name consistently.

> + */
> +
> +#define V4VOP_send 		3
> +/*
> + * Sends len bytes of buf to dst, giving src as the source address (xen will
> + * ignore src->domain and put your domain in the actually message), xen
> + * first looks for a ring with id.addr==dst and id.partner==sending_domain
> + * if that fails it looks for id.addr==dst and id.partner==DOMID_ANY.
> + * protocol is the 32 bit protocol number used from the message
> + * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
> + * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
> + * sufficient space becomes available
> + *
> + * v4v_hypercall(V4VOP_send,
> + *               v4v_addr src,
> + *               v4v_addr dst,
> + *               void* buf,
> + *               uint32_t len,
> + *               uint32_t protocol)
> + */
> +
> +
> +#define V4VOP_notify 		4
> +/* Asks xen for information about other rings in the system
> + *
> + * ent->ring is the v4v_addr_t of the ring you want information on
> + * the same matching rules are used as for V4VOP_send.
> + *
> + * ent->space_required  if this field is not null xen will check
> + * that there is space in the destination ring for this many bytes
> + * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
> + * and CANCEL any pending interrupt for that ent->ring, if insufficient
> + * space is available it will schedule an interrupt and the flag will
> + * not be set.
> + *
> + * The flags are set by xen when notify replies
> + * V4V_RING_DATA_F_EMPTY	ring is empty
> + * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
> + * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is there
> + * V4V_RING_DATA_F_EXISTS	ring exists
> + *
> + * v4v_hypercall(V4VOP_notify,
> + *               XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
> + *               NULL, NULL, nent, 0)
> + */
> +
> +
> +#define V4VOP_sendv		5
> +/*
> + * Identical to V4VOP_send except rather than buf and len it takes
> + * an array of v4v_iov and a length of the array.
> + *
> + * v4v_hypercall(V4VOP_sendv,
> + *               v4v_addr src,
> + *               v4v_addr dst,
> + *               v4v_iov iov,
> + *               uint32_t niov,
> + *               uint32_t protocol)
> + */
> +
> +#endif /* __XEN_PUBLIC_V4V_H__ */
> --- /dev/null
> +++ b/xen/include/xen/v4v.h
> @@ -0,0 +1,187 @@
> +/******************************************************************************
> + * V4V
> + *
> + * Version 2 of v2v (Virtual-to-Virtual)
> + *
> + * Copyright (c) 2010, Citrix Systems
> + *
> + * 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
> + */
> +
> +#ifndef __V4V_PRIVATE_H__
> +#define __V4V_PRIVATE_H__
> +
> +#include <xen/config.h>
> +#include <xen/types.h>
> +#include <xen/spinlock.h>
> +#include <xen/smp.h>
> +#include <xen/shared.h>
> +#include <xen/list.h>
> +#include <public/v4v.h>
> +
> +#define V4V_HTABLE_SIZE 32
> +
> +#define V4V_PACKED __attribute__ ((packed))
> +
> +/*
> + * Structures
> + */
> +
> +typedef struct v4v_iov
> +{
> +    uint64_t iov_base;
> +    uint64_t iov_len;
> +} V4V_PACKED v4v_iov_t;

While you moved this to a private header now, I continue to
think that none of the uses of V4V_PACKED are actually
warranted (and hence these can't serve as reason for moving
these public definitions into a private header). Use explicit
padding fields, and you ought to be fine.

> +DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
> +
> +typedef struct v4v_addr
> +{
> +    uint32_t port;
> +    domid_t domain;
> +} V4V_PACKED v4v_addr_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
> +
> +typedef struct v4v_ring_id
> +{
> +    struct v4v_addr addr;
> +    domid_t partner;
> +} V4V_PACKED v4v_ring_id_t;
> +
> +typedef uint64_t v4v_pfn_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
> +
> +typedef struct v4v_ring
> +{
> +    uint64_t magic;
> +    struct v4v_ring_id id;
> +    uint32_t len;
> +    uint32_t rx_ptr;
> +    uint32_t tx_ptr;
> +    uint64_t reserved[4];
> +    uint8_t ring[0];
> +} V4V_PACKED v4v_ring_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);

If moved into the public header (where they belong imo), apart
from this one none of the guest handle defines should actually be
there, as there's no guest interface that would make use of them
(they're used internally to v4v.c only).

Also, conventionally there's no space before the opening
parenthesis here.

Jan

> +
> +typedef struct v4v_ring_data_ent
> +{
> +    struct v4v_addr ring;
> +    uint16_t flags;
> +    uint16_t pad0;
> +    uint32_t space_required;
> +    uint32_t max_message_size;
> +} V4V_PACKED v4v_ring_data_ent_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
> +
> +typedef struct v4v_ring_data
> +{
> +    uint64_t magic;
> +    uint32_t nent;
> +    uint32_t padding;
> +    uint64_t reserved[4];
> +    v4v_ring_data_ent_t ring[0];
> +} V4V_PACKED v4v_ring_data_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> +
> +struct v4v_stream_header
> +{
> +    uint32_t flags;
> +    uint32_t conid;
> +} V4V_PACKED;
> +
> +struct v4v_ring_message_header
> +{
> +    uint32_t len;
> +    struct v4v_addr source;
> +    uint32_t protocol;
> +    uint8_t data[0];
> +} V4V_PACKED;
> +
> +/*
> + * Helper functions
> + */
> +
> +
> +static inline uint16_t
> +v4v_hash_fn (struct v4v_ring_id *id)
> +{
> +  uint16_t ret;
> +  ret = (uint16_t) (id->addr.port >> 16);
> +  ret ^= (uint16_t) id->addr.port;
> +  ret ^= id->addr.domain;
> +  ret ^= id->partner;
> +
> +  ret &= (V4V_HTABLE_SIZE-1);
> +
> +  return ret;
> +}
> +
> +struct v4v_pending_ent
> +{
> +  struct hlist_node node;
> +  domid_t id;
> +  uint32_t len;
> +} V4V_PACKED;
> +
> +
> +struct v4v_ring_info
> +{
> +  /* next node in the hash, protected by L2  */
> +  struct hlist_node node;
> +  /* this ring's id, protected by L2 */
> +  struct v4v_ring_id id;
> +  /* L3 */
> +  spinlock_t lock;
> +  /* cached length of the ring (from ring->len), protected by L3 */
> +  uint32_t len;
> +  uint32_t npage;
> +  /* cached tx pointer location, protected by L3 */
> +  uint32_t tx_ptr;
> +  /* guest ring, protected by L3 */
> +  XEN_GUEST_HANDLE(v4v_ring_t) ring;
> +  /* mapped ring pages protected by L3*/
> +  uint8_t **mfn_mapping;
> +  /* list of mfns of guest ring */
> +  mfn_t *mfns;
> +  /* list of struct v4v_pending_ent for this ring, L3 */
> +  struct hlist_head pending;
> +} V4V_PACKED;
> +
> +/*
> + * The value of the v4v element in a struct domain is
> + * protected by the global lock L1
> + */
> +struct v4v_domain
> +{
> +  /* L2 */
> +  rwlock_t lock;
> +  /* protected by L2 */
> +  struct hlist_head ring_hash[V4V_HTABLE_SIZE];
> +} V4V_PACKED;
> +
> +void v4v_destroy(struct domain *d);
> +int v4v_init(struct domain *d);
> +long do_v4v_op (int cmd,
> +                XEN_GUEST_HANDLE (void) arg1,
> +                XEN_GUEST_HANDLE (void) arg2,
> +                XEN_GUEST_HANDLE (void) arg3,
> +                uint32_t arg4,
> +                uint32_t arg5);
> +
> +#endif /* __V4V_PRIVATE_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:32:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWcw-0007s3-GL; Fri, 29 Jun 2012 08:32:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SkWcu-0007ru-8B
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:32:28 +0000
Received: from [85.158.139.83:14581] by server-3.bemta-5.messagelabs.com id
	80/CB-03367-B186DEF4; Fri, 29 Jun 2012 08:32:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340958746!22765453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29038 invoked from network); 29 Jun 2012 08:32:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 08:32:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:32:26 +0100
Message-Id: <4FED8467020000780008CC68@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:33:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
> --- /dev/null
> +++ b/xen/include/public/v4v.h
> @@ -0,0 +1,240 @@
> +/******************************************************************************
> + * V4V
> + *
> + * Version 2 of v2v (Virtual-to-Virtual)
> + *
> + * Copyright (c) 2010, Citrix Systems
> + *
> + * 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
> + */
> +
> +#ifndef __XEN_PUBLIC_V4V_H__
> +#define __XEN_PUBLIC_V4V_H__
> +
> +#include "xen.h"
> +
> +/*
> + * Structure definitions
> + */
> +
> +#define V4V_PROTO_DGRAM		0x3c2c1db8
> +#define V4V_PROTO_STREAM 	0x70f6a8e5
> +
> +#ifdef __i386__

How about ARM?

> +# define V4V_RING_MAGIC         0xdf6977f231abd910ULL
> +# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302dULL

Is there any reason these can't be also used for 64-bit?

> +#else
> +# define V4V_RING_MAGIC         0xdf6977f231abd910
> +# define V4V_PFN_LIST_MAGIC     0x91dd6159045b302d
> +#endif
> +#define V4V_DOMID_INVALID       (0x7FFFU)

Any reason not to use DOMID_INVALID instead?

> +#define V4V_DOMID_NONE          V4V_DOMID_INVALID
> +#define V4V_DOMID_ANY           V4V_DOMID_INVALID
> +#define V4V_PORT_NONE           0
> +
> +/*
> + * struct v4v_iov
> + * {
> + *      64 bits: iov_base
> + *      64 bits: iov_len
> + * }
> + */

What's the point of not defining the types here?

> +
> +/*
> + * struct v4v_addr
> + * {
> + *      32 bits: port
> + *      16 bits: domid
> + * }
> + */
> +
> +/*
> + * v4v_ring_id
> + * {
> + *      struct v4v_addr: addr
> + *      16 bits: partner
> + * }
> + */
> +
> +/*
> + * v4v_ring
> + * {
> + *      64 bits: magic
> + *      v4v_rind_id: id
> + *      32 bits: len
> + *      32 bits: rx_ptr
> + *      32 bits: tx_ptr
> + *      64 bits: padding
> + *      ... : ring
> + * }
> + *
> + * id:
> + * xen only looks at this during register/unregister
> + * and will fill in id.addr.domain
> + *
> + * rx_ptr: rx pointer, modified by domain
> + * tx_ptr: tx pointer, modified by xen
> + */
> +
> +#ifdef __i386__
> +#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92aULL

Same here as above.

> +#else
> +#define V4V_RING_DATA_MAGIC	0x4ce4d30fbc82e92a
> +#endif
> +
> +#define V4V_RING_DATA_F_EMPTY       1U << 0 /* Ring is empty */
> +#define V4V_RING_DATA_F_EXISTS      1U << 1 /* Ring exists */
> +#define V4V_RING_DATA_F_PENDING     1U << 2 /* Pending interrupt exists - do not
> +                                               rely on this field - for
> +                                               profiling only */
> +#define V4V_RING_DATA_F_SUFFICIENT  1U << 3 /* Sufficient space to queue
> +                                               space_required bytes exists */
> +
> +/*
> + * v4v_ring_data_ent
> + * {
> + *      v4v_addr: ring
> + *      16 bits: flags
> + *      16 bits: padding
> + *      32 bits: space_required
> + *      32 bits: max_message_size
> + * }
> + */
> +
> +/*
> + * v4v_ring_data
> + * {
> + *      64 bits: magic (V4V_RING_DATA_MAGIC)
> + *      32 bits: nent
> + *      32 bits: padding
> + *      256 bits: reserved
> + *      ... : v4v_ring_data_ent
> + * }
> + */
> +
> +
> +#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
> +/*
> + * Messages on the ring are padded to 128 bits
> + * Len here refers to the exact length of the data not including the
> + * 128 bit header. The message uses
> + * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
> + */
> +
> +/*
> + * v4v_stream_header
> + * {
> + *      32 bits: flags
> + *      32 bits: conid
> + * }
> + */
> +
> +/*
> + * v4v_ring_message_header
> + * {
> + *      32 bits: len
> + *      v4v_addr: source
> + *      32 bits: protocol
> + *      ... : data
> + * }
> + */
> +
> +/*
> + * HYPERCALLS
> + */
> +
> +#define V4VOP_register_ring 	1
> +/*
> + * Registers a ring with Xen, if a ring with the same v4v_ring_id exists,
> + * this ring takes its place, registration will not change tx_ptr
> + * unless it is invalid
> + *
> + * do_v4v_op(V4VOP_unregister_ring,
> + *           v4v_ring, XEN_GUEST_HANDLE(v4v_pfn),
> + *           NULL, npage, 0)
> + */
> +
> +
> +#define V4VOP_unregister_ring 	2
> +/*
> + * Unregister a ring.
> + *
> + * v4v_hypercall(V4VOP_send, v4v_ring, NULL, NULL, 0, 0)

Assuming this and the earlier do_v4v_op() refer to the same
thing, please use a single name consistently.

> + */
> +
> +#define V4VOP_send 		3
> +/*
> + * Sends len bytes of buf to dst, giving src as the source address (xen will
> + * ignore src->domain and put your domain in the actually message), xen
> + * first looks for a ring with id.addr==dst and id.partner==sending_domain
> + * if that fails it looks for id.addr==dst and id.partner==DOMID_ANY.
> + * protocol is the 32 bit protocol number used from the message
> + * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
> + * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
> + * sufficient space becomes available
> + *
> + * v4v_hypercall(V4VOP_send,
> + *               v4v_addr src,
> + *               v4v_addr dst,
> + *               void* buf,
> + *               uint32_t len,
> + *               uint32_t protocol)
> + */
> +
> +
> +#define V4VOP_notify 		4
> +/* Asks xen for information about other rings in the system
> + *
> + * ent->ring is the v4v_addr_t of the ring you want information on
> + * the same matching rules are used as for V4VOP_send.
> + *
> + * ent->space_required  if this field is not null xen will check
> + * that there is space in the destination ring for this many bytes
> + * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
> + * and CANCEL any pending interrupt for that ent->ring, if insufficient
> + * space is available it will schedule an interrupt and the flag will
> + * not be set.
> + *
> + * The flags are set by xen when notify replies
> + * V4V_RING_DATA_F_EMPTY	ring is empty
> + * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
> + * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is there
> + * V4V_RING_DATA_F_EXISTS	ring exists
> + *
> + * v4v_hypercall(V4VOP_notify,
> + *               XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
> + *               NULL, NULL, nent, 0)
> + */
> +
> +
> +#define V4VOP_sendv		5
> +/*
> + * Identical to V4VOP_send except rather than buf and len it takes
> + * an array of v4v_iov and a length of the array.
> + *
> + * v4v_hypercall(V4VOP_sendv,
> + *               v4v_addr src,
> + *               v4v_addr dst,
> + *               v4v_iov iov,
> + *               uint32_t niov,
> + *               uint32_t protocol)
> + */
> +
> +#endif /* __XEN_PUBLIC_V4V_H__ */
> --- /dev/null
> +++ b/xen/include/xen/v4v.h
> @@ -0,0 +1,187 @@
> +/******************************************************************************
> + * V4V
> + *
> + * Version 2 of v2v (Virtual-to-Virtual)
> + *
> + * Copyright (c) 2010, Citrix Systems
> + *
> + * 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
> + */
> +
> +#ifndef __V4V_PRIVATE_H__
> +#define __V4V_PRIVATE_H__
> +
> +#include <xen/config.h>
> +#include <xen/types.h>
> +#include <xen/spinlock.h>
> +#include <xen/smp.h>
> +#include <xen/shared.h>
> +#include <xen/list.h>
> +#include <public/v4v.h>
> +
> +#define V4V_HTABLE_SIZE 32
> +
> +#define V4V_PACKED __attribute__ ((packed))
> +
> +/*
> + * Structures
> + */
> +
> +typedef struct v4v_iov
> +{
> +    uint64_t iov_base;
> +    uint64_t iov_len;
> +} V4V_PACKED v4v_iov_t;

While you moved this to a private header now, I continue to
think that none of the uses of V4V_PACKED are actually
warranted (and hence these can't serve as reason for moving
these public definitions into a private header). Use explicit
padding fields, and you ought to be fine.

> +DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
> +
> +typedef struct v4v_addr
> +{
> +    uint32_t port;
> +    domid_t domain;
> +} V4V_PACKED v4v_addr_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
> +
> +typedef struct v4v_ring_id
> +{
> +    struct v4v_addr addr;
> +    domid_t partner;
> +} V4V_PACKED v4v_ring_id_t;
> +
> +typedef uint64_t v4v_pfn_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
> +
> +typedef struct v4v_ring
> +{
> +    uint64_t magic;
> +    struct v4v_ring_id id;
> +    uint32_t len;
> +    uint32_t rx_ptr;
> +    uint32_t tx_ptr;
> +    uint64_t reserved[4];
> +    uint8_t ring[0];
> +} V4V_PACKED v4v_ring_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);

If moved into the public header (where they belong imo), apart
from this one none of the guest handle defines should actually be
there, as there's no guest interface that would make use of them
(they're used internally to v4v.c only).

Also, conventionally there's no space before the opening
parenthesis here.

Jan

> +
> +typedef struct v4v_ring_data_ent
> +{
> +    struct v4v_addr ring;
> +    uint16_t flags;
> +    uint16_t pad0;
> +    uint32_t space_required;
> +    uint32_t max_message_size;
> +} V4V_PACKED v4v_ring_data_ent_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
> +
> +typedef struct v4v_ring_data
> +{
> +    uint64_t magic;
> +    uint32_t nent;
> +    uint32_t padding;
> +    uint64_t reserved[4];
> +    v4v_ring_data_ent_t ring[0];
> +} V4V_PACKED v4v_ring_data_t;
> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
> +
> +struct v4v_stream_header
> +{
> +    uint32_t flags;
> +    uint32_t conid;
> +} V4V_PACKED;
> +
> +struct v4v_ring_message_header
> +{
> +    uint32_t len;
> +    struct v4v_addr source;
> +    uint32_t protocol;
> +    uint8_t data[0];
> +} V4V_PACKED;
> +
> +/*
> + * Helper functions
> + */
> +
> +
> +static inline uint16_t
> +v4v_hash_fn (struct v4v_ring_id *id)
> +{
> +  uint16_t ret;
> +  ret = (uint16_t) (id->addr.port >> 16);
> +  ret ^= (uint16_t) id->addr.port;
> +  ret ^= id->addr.domain;
> +  ret ^= id->partner;
> +
> +  ret &= (V4V_HTABLE_SIZE-1);
> +
> +  return ret;
> +}
> +
> +struct v4v_pending_ent
> +{
> +  struct hlist_node node;
> +  domid_t id;
> +  uint32_t len;
> +} V4V_PACKED;
> +
> +
> +struct v4v_ring_info
> +{
> +  /* next node in the hash, protected by L2  */
> +  struct hlist_node node;
> +  /* this ring's id, protected by L2 */
> +  struct v4v_ring_id id;
> +  /* L3 */
> +  spinlock_t lock;
> +  /* cached length of the ring (from ring->len), protected by L3 */
> +  uint32_t len;
> +  uint32_t npage;
> +  /* cached tx pointer location, protected by L3 */
> +  uint32_t tx_ptr;
> +  /* guest ring, protected by L3 */
> +  XEN_GUEST_HANDLE(v4v_ring_t) ring;
> +  /* mapped ring pages protected by L3*/
> +  uint8_t **mfn_mapping;
> +  /* list of mfns of guest ring */
> +  mfn_t *mfns;
> +  /* list of struct v4v_pending_ent for this ring, L3 */
> +  struct hlist_head pending;
> +} V4V_PACKED;
> +
> +/*
> + * The value of the v4v element in a struct domain is
> + * protected by the global lock L1
> + */
> +struct v4v_domain
> +{
> +  /* L2 */
> +  rwlock_t lock;
> +  /* protected by L2 */
> +  struct hlist_head ring_hash[V4V_HTABLE_SIZE];
> +} V4V_PACKED;
> +
> +void v4v_destroy(struct domain *d);
> +int v4v_init(struct domain *d);
> +long do_v4v_op (int cmd,
> +                XEN_GUEST_HANDLE (void) arg1,
> +                XEN_GUEST_HANDLE (void) arg2,
> +                XEN_GUEST_HANDLE (void) arg3,
> +                uint32_t arg4,
> +                uint32_t arg5);
> +
> +#endif /* __V4V_PRIVATE_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWfb-0008CJ-1f; Fri, 29 Jun 2012 08:35:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SkWfZ-0008CC-Oz
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:35:13 +0000
Received: from [85.158.138.51:27083] by server-3.bemta-3.messagelabs.com id
	29/B7-26490-0C86DEF4; Fri, 29 Jun 2012 08:35:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340958909!29043390!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7295 invoked from network); 29 Jun 2012 08:35:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	29 Jun 2012 08:35:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:15:00 +0100
Message-Id: <4FED8052020000780008CC32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:15:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
	<1340957235.10942.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340957235.10942.72.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 10:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-06-29 at 08:56 +0100, Jan Beulich wrote:
>> >>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
>> > just return cpuid values, as that's what would happen without the HVM
>> > container.
>> 
>> Which means you're not leveraging one of the things you could
>> gain from hybrid (after all, returning the native value to user
>> mode is one of the weaknesses of PV).
> 
> cpuid masking could happen in the HVM layer too, couldn't it?

But CPUID masking is rather limited (after all that's why CPUID
faulting got added later).

> Probably "XEN_EMULATE_PREFIX cpuid" and raw "cpuid" ought to return the
> same set of PV values in hybrid?

Yes, that's what I would think.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkWfb-0008CJ-1f; Fri, 29 Jun 2012 08:35:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SkWfZ-0008CC-Oz
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:35:13 +0000
Received: from [85.158.138.51:27083] by server-3.bemta-3.messagelabs.com id
	29/B7-26490-0C86DEF4; Fri, 29 Jun 2012 08:35:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1340958909!29043390!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7295 invoked from network); 29 Jun 2012 08:35:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	29 Jun 2012 08:35:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:15:00 +0100
Message-Id: <4FED8052020000780008CC32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:15:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
	<1340957235.10942.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1340957235.10942.72.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 10:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-06-29 at 08:56 +0100, Jan Beulich wrote:
>> >>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user mode, I
>> > just return cpuid values, as that's what would happen without the HVM
>> > container.
>> 
>> Which means you're not leveraging one of the things you could
>> gain from hybrid (after all, returning the native value to user
>> mode is one of the weaknesses of PV).
> 
> cpuid masking could happen in the HVM layer too, couldn't it?

But CPUID masking is rather limited (after all that's why CPUID
faulting got added later).

> Probably "XEN_EMULATE_PREFIX cpuid" and raw "cpuid" ought to return the
> same set of PV values in hybrid?

Yes, that's what I would think.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWkp-0008Qx-QO; Fri, 29 Jun 2012 08:40: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 1SkWko-0008Qs-Oe
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:40:39 +0000
Received: from [85.158.138.51:57036] by server-10.bemta-3.messagelabs.com id
	DD/7A-01753-10A6DEF4; Fri, 29 Jun 2012 08:40:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340959232!21011347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2553 invoked from network); 29 Jun 2012 08:40:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13284209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:40:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:40:11 +0100
Message-ID: <1340959209.10942.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 09:40:09 +0100
In-Reply-To: <1340953001.5953.2.camel@dagon.hellion.org.uk>
References: <osstest-13383-mainreport@xen.org>
	<1340953001.5953.2.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 07:56 +0100, Ian Campbell wrote:
> On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:
> > flight 13383 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379
> 
> This run was before the migration series went in.
> 
> I don't see much of interest in the logs, seems like the guest did
> actually start.

http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/16.ts-guest-start.log has:
2012-06-28 15:21:47 Z executing ssh ... root@10.80.249.56 xm list
2012-06-28 15:21:48 Z guest debian.guest.osstest state is r
2012-06-28 15:21:48 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: waiting 40s...
2012-06-28 15:21:48 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: no active lease (waiting) ...
2012-06-28 15:22:06 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: ping gave (256): PING 10.80.251.54 (10.80.251.54) 56(84) bytes of data. |  | --- 10.80.251.54 ping statistics --- | 5 packets transmitted, 0 received, 100% packet loss, time XXXms |  |  (waiting) ...
...

but
http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/dhcpleases-debian.nolease contains:
        lease 10.80.251.54 {
          starts 3 2012/06/27 14:10:01;
          ends 3 2012/06/27 14:40:01;
          tstp 3 2012/06/27 14:40:01;
          cltt 3 2012/06/27 14:10:01;
          binding state free;
          hardware ethernet 00:00:1a:1b:01:a1;
          uid "\001\000\000\032\033\001\241";
        }

Which has a mismatched mac address? dhcpleases-debian.new seems to have
the same.

> The new commits which went into this flight seem fairly benign, at least
> from the PoV of starting a PV guest:
> 
> [...]
> > changeset:   25521:52f1b8a4f9a4
> > tag:         tip
> > user:        George Dunlap <george.dunlap@eu.citrix.com>
> > date:        Wed Jun 27 17:50:10 2012 +0100
> >     
> >     xen,pod: Cosmetic code motion
> >     
> >     No point in doing the assignment if we're just going to crash anyway.
> >     
> >     Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> >     
> >     
> > changeset:   25520:2d9f3b010901
> > user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > date:        Thu Jun 28 12:45:09 2012 +0100
> >     
> >     x86/mm: Clean up unshare path for foreign mappings
> >     
> >     In its current shape, if Xen unshares a foreign gfn successfully while building
> >     a foreign writable map, it is left with a reference to the old shared page in
> >     the "target" var.
> >     
> >     Instead, push unsharing request down on the initial get_page_from_gfn call,
> >     which will DTRT.
> >     
> >     This allows for greatly simplifying the unshare related condition handling,
> >     removing ugly comments and s86_64 ifdef-ery.
> >     
> >     Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >     Acked-by: Tim Deegan <tim@xen.org>
> >     Committed-by: Tim Deegan <tim@xen.org>
> >     
> >     
> > changeset:   25519:fdc1f16d382c
> > user:        Jan Beulich <jbeulich@suse.com>
> > date:        Thu Jun 28 13:36:08 2012 +0200
> >     
> >     x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]
> >     
> >     Since the emulator now supports a few 256-bit memory operations, this
> >     array needs to follow (and the comments should, too).
> >     
> >     To limit growth, re-order the mmio_large_write_* fields so that the
> >     two mmio_large_*_bytes fields end up adjacent to each other.
> >     
> >     Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >     Acked-by: Keir Fraser <keir@xen.org>
> >     
> >     
> > changeset:   25518:4f92bdf3370c
> > user:        Jan Beulich <jbeulich@suse.com>
> > date:        Wed Jun 27 09:36:43 2012 +0200
> >     
> >     docs/xen-headers: allow headers to be symlinks
> >     
> >     There's no apparent reason not to permit this, and since we don't
> >     support out-of-source-tree builds, the least overhead way of doing
> >     multiple, differently configured (perhaps different architecture)
> >     builds from a single source tree is to create symlinked build trees.
> >     
> >     Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >     
> >     
> > ========================================
> > commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > Author: Roger Pau Monne <roger.pau@citrix.com>
> > Date:   Thu Jun 7 19:44:01 2012 +0100
> > 
> >     qemu-xen-trad: fix sys-queue.h usage on BSD systems
> >     
> >     BSD systems already have a sys/queue.h file, which has more macros
> >     than the one Qemu uses, and some header files depend on having that
> >     macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
> >     systems and include the native one.
> >     
> >     This is not a backport because the original patch is too dificult to
> >     backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
> >     
> >     Doing a diff -bB shows that the Qemu version is just a stripped
> >     version of the original NetBSD header, with many macros removed, but
> >     no new ones added.
> >     
> >     Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> >     Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >     Acked-by: Ian Jackson <ian.jackson@eu.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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWkp-0008Qx-QO; Fri, 29 Jun 2012 08:40: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 1SkWko-0008Qs-Oe
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 08:40:39 +0000
Received: from [85.158.138.51:57036] by server-10.bemta-3.messagelabs.com id
	DD/7A-01753-10A6DEF4; Fri, 29 Jun 2012 08:40:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340959232!21011347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM1Nzk=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2553 invoked from network); 29 Jun 2012 08:40:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 08:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13284209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 08:40:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 09:40:11 +0100
Message-ID: <1340959209.10942.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 09:40:09 +0100
In-Reply-To: <1340953001.5953.2.camel@dagon.hellion.org.uk>
References: <osstest-13383-mainreport@xen.org>
	<1340953001.5953.2.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 07:56 +0100, Ian Campbell wrote:
> On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:
> > flight 13383 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379
> 
> This run was before the migration series went in.
> 
> I don't see much of interest in the logs, seems like the guest did
> actually start.

http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/16.ts-guest-start.log has:
2012-06-28 15:21:47 Z executing ssh ... root@10.80.249.56 xm list
2012-06-28 15:21:48 Z guest debian.guest.osstest state is r
2012-06-28 15:21:48 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: waiting 40s...
2012-06-28 15:21:48 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: no active lease (waiting) ...
2012-06-28 15:22:06 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: ping gave (256): PING 10.80.251.54 (10.80.251.54) 56(84) bytes of data. |  | --- 10.80.251.54 ping statistics --- | 5 packets transmitted, 0 received, 100% packet loss, time XXXms |  |  (waiting) ...
...

but
http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/dhcpleases-debian.nolease contains:
        lease 10.80.251.54 {
          starts 3 2012/06/27 14:10:01;
          ends 3 2012/06/27 14:40:01;
          tstp 3 2012/06/27 14:40:01;
          cltt 3 2012/06/27 14:10:01;
          binding state free;
          hardware ethernet 00:00:1a:1b:01:a1;
          uid "\001\000\000\032\033\001\241";
        }

Which has a mismatched mac address? dhcpleases-debian.new seems to have
the same.

> The new commits which went into this flight seem fairly benign, at least
> from the PoV of starting a PV guest:
> 
> [...]
> > changeset:   25521:52f1b8a4f9a4
> > tag:         tip
> > user:        George Dunlap <george.dunlap@eu.citrix.com>
> > date:        Wed Jun 27 17:50:10 2012 +0100
> >     
> >     xen,pod: Cosmetic code motion
> >     
> >     No point in doing the assignment if we're just going to crash anyway.
> >     
> >     Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> >     
> >     
> > changeset:   25520:2d9f3b010901
> > user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > date:        Thu Jun 28 12:45:09 2012 +0100
> >     
> >     x86/mm: Clean up unshare path for foreign mappings
> >     
> >     In its current shape, if Xen unshares a foreign gfn successfully while building
> >     a foreign writable map, it is left with a reference to the old shared page in
> >     the "target" var.
> >     
> >     Instead, push unsharing request down on the initial get_page_from_gfn call,
> >     which will DTRT.
> >     
> >     This allows for greatly simplifying the unshare related condition handling,
> >     removing ugly comments and s86_64 ifdef-ery.
> >     
> >     Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >     Acked-by: Tim Deegan <tim@xen.org>
> >     Committed-by: Tim Deegan <tim@xen.org>
> >     
> >     
> > changeset:   25519:fdc1f16d382c
> > user:        Jan Beulich <jbeulich@suse.com>
> > date:        Thu Jun 28 13:36:08 2012 +0200
> >     
> >     x86/hvm: increase struct hvm_vcpu_io's mmio_large_read[]
> >     
> >     Since the emulator now supports a few 256-bit memory operations, this
> >     array needs to follow (and the comments should, too).
> >     
> >     To limit growth, re-order the mmio_large_write_* fields so that the
> >     two mmio_large_*_bytes fields end up adjacent to each other.
> >     
> >     Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >     Acked-by: Keir Fraser <keir@xen.org>
> >     
> >     
> > changeset:   25518:4f92bdf3370c
> > user:        Jan Beulich <jbeulich@suse.com>
> > date:        Wed Jun 27 09:36:43 2012 +0200
> >     
> >     docs/xen-headers: allow headers to be symlinks
> >     
> >     There's no apparent reason not to permit this, and since we don't
> >     support out-of-source-tree builds, the least overhead way of doing
> >     multiple, differently configured (perhaps different architecture)
> >     builds from a single source tree is to create symlinked build trees.
> >     
> >     Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >     
> >     
> > ========================================
> > commit 50c553be472c9f4b05a0526c0aae98709ca9ffff
> > Author: Roger Pau Monne <roger.pau@citrix.com>
> > Date:   Thu Jun 7 19:44:01 2012 +0100
> > 
> >     qemu-xen-trad: fix sys-queue.h usage on BSD systems
> >     
> >     BSD systems already have a sys/queue.h file, which has more macros
> >     than the one Qemu uses, and some header files depend on having that
> >     macros defined (sys/disk.h for example). Disable sys-queue.h on BSD
> >     systems and include the native one.
> >     
> >     This is not a backport because the original patch is too dificult to
> >     backport, it's commit 72cf2d4f0e181d0d3a3122e04129c58a95da713e.
> >     
> >     Doing a diff -bB shows that the Qemu version is just a stripped
> >     version of the original NetBSD header, with many macros removed, but
> >     no new ones added.
> >     
> >     Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> >     Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >     Acked-by: Ian Jackson <ian.jackson@eu.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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:47: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 1SkWqn-00008A-KG; Fri, 29 Jun 2012 08:46:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkWqm-000085-4k
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:46:48 +0000
Received: from [85.158.143.99:46799] by server-3.bemta-4.messagelabs.com id
	51/24-05808-77B6DEF4; Fri, 29 Jun 2012 08:46:47 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340959606!24480860!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4Nzk3Mg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24018 invoked from network); 29 Jun 2012 08:46:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 08:46:46 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Jun 2012 01:46:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171552581"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 29 Jun 2012 01:46:45 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 01:46:45 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.220]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 16:46:43 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
	update_dirty_bitmap
Thread-Index: AQHNVTPcIx7FzW7kakeITSU9R4u2fpcQ7XHA
Date: Fri, 29 Jun 2012 08:46:43 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE2846C@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-4-git-send-email-xudong.hao@intel.com>
	<20120628134204.GP34995@ocelot.phlegethon.org>
In-Reply-To: <20120628134204.GP34995@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
 update_dirty_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

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Thursday, June 28, 2012 9:42 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
> update_dirty_bitmap
> 
> At 09:57 +0800 on 20 Jun (1340186266), Xudong Hao wrote:
> > @@ -83,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain
> *d)
> >  static int hap_disable_vram_tracking(struct domain *d)
> >  {
> >      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
> > +    p2m_type_t p2mt = p2m_ram_rw;
> >
> >      if ( !dirty_vram )
> >          return -EINVAL;
> >
> > +    /* With hap dirty bit, p2m type cannot be changed from
> p2m_ram_logdirty
> > +     * to p2m_ram_rw when first fault is met. Actually, there is no such
> > +     * fault occurred.
> > +     */
> > +    if ( hap_has_dirty_bit )
> > +        p2mt = p2m_ram_logdirty;
> > +
> >      paging_lock(d);
> >      d->arch.paging.mode &= ~PG_log_dirty;
> >      paging_unlock(d);
> >
> >      /* set l1e entries of P2M table with normal mode */
> >      p2m_change_type_range(d, dirty_vram->begin_pfn,
> dirty_vram->end_pfn,
> > -                          p2m_ram_logdirty, p2m_ram_rw);
> > +                          p2mt, p2m_ram_rw);
> 
> What's the intent of this change?
> 
> AFAICS it will break the hap_has_dirty_bit==0 case, by basically making
> that p2m_change_type_range() into a noop.
> 

Thanks for the review, it's a code mistake indeed.
It should be: 
      p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
+                          p2m_ram_logdirty, p2mt);


> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain
> *d,
> >      p2m_unlock(p2m);
> >  }
> >
> > +void p2m_query_entry_global(struct domain *d, int mask)
> > +{
> > +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +    ASSERT(p2m);
> > +    p2m_lock(p2m);
> > +    p2m->query_entry_global(p2m, mask);
> > +    p2m_unlock(p2m);
> > +}
> > +
> 
> Given that when you implement this, it's basically just the same as
> p2m_change_type_global() with p2m_ram_logdirty for both types:
> 
>  - Why not just use p2m_change_type_global() instead of adding the new
>    function pointer?

Because it's need to add a mask to indentify D bit or not, I do not want to change current ept_change_entry_type_global() interface. So add a new function pointer.

>  - If you do need a new function pointer, this name is very confusing:
>    it's not doing any kind of query.
> 

The new function query dirty page in whole p2m table and update the dirty bitmap. 

> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct
> xen_domctl_shadow_op *sc)
> >      int i4, i3, i2;
> >
> >      domain_pause(d);
> > -    paging_lock(d);
> >
> >      clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
> > +    if ( clean )
> > +    {
> > +        /* We need to further call clean_dirty_bitmap() functions of
> specific
> > +         * paging modes (shadow or hap).  Safe because the domain is
> paused.
> > +         * And this call must be made before actually transferring the
> dirty
> > +         * bitmap since with HW hap dirty bit support, dirty bitmap is
> > +         * produced by hooking on this call. */
> > +        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
> > +    }
> 
> > +    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
> > +    {
> > +        d->arch.paging.log_dirty.update_dirty_bitmap(d);
> > +    }
> 
> Doesn't this end up doing _two_ passes over the p2m table?
> 

Oh, it does 2 passes over the p2m table. I wanted to differentiate the CLEAN and PEEK op by variable "clean" and "peek", seems peek=1 even when it's a CLEAN hapercall.
I do the following modification: 
+    if ( (sc->op == XEN_DOMCTL_SHADOW_OP_PEEK) && d->arch.paging.log_dirty.update_dirty_bitmap)
+    {
+        d->arch.paging.log_dirty.update_dirty_bitmap(d);
+    }

> I think it would be better to leave the clean() op at the end of the
> function, and arrange for it to be a noop in the EPT/D-bit case.  Then

We need to clean D bit in clean() op for the EPT/D bit case. How about the modification above?
 
> with the addition of this update_dirty_bitmap() call, the p2m only gets
> walked once, for all configurations.
> 
> 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 Jun 29 08:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08:47: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 1SkWqn-00008A-KG; Fri, 29 Jun 2012 08:46:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkWqm-000085-4k
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:46:48 +0000
Received: from [85.158.143.99:46799] by server-3.bemta-4.messagelabs.com id
	51/24-05808-77B6DEF4; Fri, 29 Jun 2012 08:46:47 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1340959606!24480860!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDI4Nzk3Mg==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24018 invoked from network); 29 Jun 2012 08:46:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 08:46:46 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Jun 2012 01:46:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="171552581"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 29 Jun 2012 01:46:45 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 01:46:45 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.220]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 16:46:43 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
	update_dirty_bitmap
Thread-Index: AQHNVTPcIx7FzW7kakeITSU9R4u2fpcQ7XHA
Date: Fri, 29 Jun 2012 08:46:43 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE2846C@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<1340157467-19553-4-git-send-email-xudong.hao@intel.com>
	<20120628134204.GP34995@ocelot.phlegethon.org>
In-Reply-To: <20120628134204.GP34995@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
 update_dirty_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

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Thursday, June 28, 2012 9:42 PM
> To: Hao, Xudong
> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xiantao;
> JBeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH v2 3/4] xen: introduce new function
> update_dirty_bitmap
> 
> At 09:57 +0800 on 20 Jun (1340186266), Xudong Hao wrote:
> > @@ -83,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain
> *d)
> >  static int hap_disable_vram_tracking(struct domain *d)
> >  {
> >      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
> > +    p2m_type_t p2mt = p2m_ram_rw;
> >
> >      if ( !dirty_vram )
> >          return -EINVAL;
> >
> > +    /* With hap dirty bit, p2m type cannot be changed from
> p2m_ram_logdirty
> > +     * to p2m_ram_rw when first fault is met. Actually, there is no such
> > +     * fault occurred.
> > +     */
> > +    if ( hap_has_dirty_bit )
> > +        p2mt = p2m_ram_logdirty;
> > +
> >      paging_lock(d);
> >      d->arch.paging.mode &= ~PG_log_dirty;
> >      paging_unlock(d);
> >
> >      /* set l1e entries of P2M table with normal mode */
> >      p2m_change_type_range(d, dirty_vram->begin_pfn,
> dirty_vram->end_pfn,
> > -                          p2m_ram_logdirty, p2m_ram_rw);
> > +                          p2mt, p2m_ram_rw);
> 
> What's the intent of this change?
> 
> AFAICS it will break the hap_has_dirty_bit==0 case, by basically making
> that p2m_change_type_range() into a noop.
> 

Thanks for the review, it's a code mistake indeed.
It should be: 
      p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
+                          p2m_ram_logdirty, p2mt);


> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain
> *d,
> >      p2m_unlock(p2m);
> >  }
> >
> > +void p2m_query_entry_global(struct domain *d, int mask)
> > +{
> > +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +    ASSERT(p2m);
> > +    p2m_lock(p2m);
> > +    p2m->query_entry_global(p2m, mask);
> > +    p2m_unlock(p2m);
> > +}
> > +
> 
> Given that when you implement this, it's basically just the same as
> p2m_change_type_global() with p2m_ram_logdirty for both types:
> 
>  - Why not just use p2m_change_type_global() instead of adding the new
>    function pointer?

Because it's need to add a mask to indentify D bit or not, I do not want to change current ept_change_entry_type_global() interface. So add a new function pointer.

>  - If you do need a new function pointer, this name is very confusing:
>    it's not doing any kind of query.
> 

The new function query dirty page in whole p2m table and update the dirty bitmap. 

> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct
> xen_domctl_shadow_op *sc)
> >      int i4, i3, i2;
> >
> >      domain_pause(d);
> > -    paging_lock(d);
> >
> >      clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
> > +    if ( clean )
> > +    {
> > +        /* We need to further call clean_dirty_bitmap() functions of
> specific
> > +         * paging modes (shadow or hap).  Safe because the domain is
> paused.
> > +         * And this call must be made before actually transferring the
> dirty
> > +         * bitmap since with HW hap dirty bit support, dirty bitmap is
> > +         * produced by hooking on this call. */
> > +        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
> > +    }
> 
> > +    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
> > +    {
> > +        d->arch.paging.log_dirty.update_dirty_bitmap(d);
> > +    }
> 
> Doesn't this end up doing _two_ passes over the p2m table?
> 

Oh, it does 2 passes over the p2m table. I wanted to differentiate the CLEAN and PEEK op by variable "clean" and "peek", seems peek=1 even when it's a CLEAN hapercall.
I do the following modification: 
+    if ( (sc->op == XEN_DOMCTL_SHADOW_OP_PEEK) && d->arch.paging.log_dirty.update_dirty_bitmap)
+    {
+        d->arch.paging.log_dirty.update_dirty_bitmap(d);
+    }

> I think it would be better to leave the clean() op at the end of the
> function, and arrange for it to be a noop in the EPT/D-bit case.  Then

We need to clean D bit in clean() op for the EPT/D bit case. How about the modification above?
 
> with the addition of this update_dirty_bitmap() call, the p2m only gets
> walked once, for all configurations.
> 
> 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 Jun 29 08:50:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWtv-0000Gq-HQ; Fri, 29 Jun 2012 08:50:03 +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 1SkWtt-0000Gi-Tv
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:50:02 +0000
Received: from [85.158.143.99:10532] by server-3.bemta-4.messagelabs.com id
	7D/E9-05808-93C6DEF4; Fri, 29 Jun 2012 08:50:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340959800!19955903!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18537 invoked from network); 29 Jun 2012 08:50:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 08:50:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:50:00 +0100
Message-Id: <4FED8886020000780008CC7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:50:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
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] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op, 
> XEN_GUEST_HANDLE(void) arg)
>                  iorp = &d->arch.hvm_domain.ioreq;
>                  for_each_vcpu ( d, v )
>                  {
> -                    int old_port, new_port;
> -                    new_port = alloc_unbound_xen_event_channel(
> -                        v, a.value, NULL);
> -                    if ( new_port < 0 )
> -                    {
> -                        rc = new_port;
> +                    rc = hvm_replace_event_channel(v, a.value,
> +                                                   &v->arch.hvm_vcpu.xen_port);
> +                    if ( rc )
>                          break;
> +
> +                    if ( v->vcpu_id == 0 )

Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
is valid (as otherwise free_xen_event_channel() will BUG_ON() on
it)?

> +                    {
> +                        spin_lock(&iorp->lock);
> +                        rc = hvm_replace_event_channel(v, a.value,
> +                            (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
> +                        spin_unlock(&iorp->lock);
> +                        if ( rc )
> +                            break;
>                      }

My first preference would be for this to be moved out of the
loop. If it has to remain in the loop for some reason, then the
next best option would be to move this into the iorp->lock
protected region immediately below.

Jan

> -                    /* xchg() ensures that only we free_xen_event_channel() */
> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
> -                    free_xen_event_channel(v, old_port);
> +
>                      spin_lock(&iorp->lock);
>                      if ( iorp->va != NULL )
>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 08:50:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 08: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 1SkWtv-0000Gq-HQ; Fri, 29 Jun 2012 08:50:03 +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 1SkWtt-0000Gi-Tv
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 08:50:02 +0000
Received: from [85.158.143.99:10532] by server-3.bemta-4.messagelabs.com id
	7D/E9-05808-93C6DEF4; Fri, 29 Jun 2012 08:50:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1340959800!19955903!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NTQ=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18537 invoked from network); 29 Jun 2012 08:50:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	29 Jun 2012 08:50:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 09:50:00 +0100
Message-Id: <4FED8886020000780008CC7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 09:50:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1340724087-7814-1-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
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] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op, 
> XEN_GUEST_HANDLE(void) arg)
>                  iorp = &d->arch.hvm_domain.ioreq;
>                  for_each_vcpu ( d, v )
>                  {
> -                    int old_port, new_port;
> -                    new_port = alloc_unbound_xen_event_channel(
> -                        v, a.value, NULL);
> -                    if ( new_port < 0 )
> -                    {
> -                        rc = new_port;
> +                    rc = hvm_replace_event_channel(v, a.value,
> +                                                   &v->arch.hvm_vcpu.xen_port);
> +                    if ( rc )
>                          break;
> +
> +                    if ( v->vcpu_id == 0 )

Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
is valid (as otherwise free_xen_event_channel() will BUG_ON() on
it)?

> +                    {
> +                        spin_lock(&iorp->lock);
> +                        rc = hvm_replace_event_channel(v, a.value,
> +                            (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
> +                        spin_unlock(&iorp->lock);
> +                        if ( rc )
> +                            break;
>                      }

My first preference would be for this to be moved out of the
loop. If it has to remain in the loop for some reason, then the
next best option would be to move this into the iorp->lock
protected region immediately below.

Jan

> -                    /* xchg() ensures that only we free_xen_event_channel() */
> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
> -                    free_xen_event_channel(v, old_port);
> +
>                      spin_lock(&iorp->lock);
>                      if ( iorp->va != NULL )
>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 09:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkXUQ-0001Is-Hl; Fri, 29 Jun 2012 09:27:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkXUO-0001Im-QB
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:27:45 +0000
Received: from [85.158.143.35:4959] by server-2.bemta-4.messagelabs.com id
	DD/6B-17938-0157DEF4; Fri, 29 Jun 2012 09:27:44 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340962047!15593512!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMzAxMjk4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4601 invoked from network); 29 Jun 2012 09:27:28 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 09:27:28 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 29 Jun 2012 02:27:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="162170838"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 29 Jun 2012 02:27:26 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 02:27:26 -0700
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, 29 Jun 2012 02:27:26 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX151.ccr.corp.intel.com ([10.239.6.50]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 17:27:12 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNUrFAT/njWom2N0+Is+zDJD5/bZcMEOKQgAL1rYCAAgapEA==
Date: Fri, 29 Jun 2012 09:27:12 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE284E7@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
	<20120628103025.GB34995@ocelot.phlegethon.org>
In-Reply-To: <20120628103025.GB34995@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>, "keir@xen.org" <keir@xen.org>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Thursday, June 28, 2012 6:30 PM
> To: Hao, Xudong
> Cc: keir@xen.org; Shan, Haitao; JBeulich@suse.com; Zhang, Xiantao;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> 
> At 05:31 +0000 on 26 Jun (1340688686), Hao, Xudong wrote:
> > > - Have you measured what difference this makes?  I take it it improves
> > >   performance during live migration but it would be good to know how
> much
> > >   before taking on extra code.
> >
> > We did live migration performance testing with patches, it's
> > embarrassed to say but the result show there is no performance gain
> > and no performance loss indeed.
> 
> Ah.
> 
> But maybe they have some performance advantage for guests with
> graphics-heavy workloads (by making the VRAM tracking faster)?
> Could you test that to see if that's the case?
> 

Ok, I'll test it.

> If it's not, I think you'll understand if we don't take these patches.
> 
> 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 Jun 29 09:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkXUQ-0001Is-Hl; Fri, 29 Jun 2012 09:27:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkXUO-0001Im-QB
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:27:45 +0000
Received: from [85.158.143.35:4959] by server-2.bemta-4.messagelabs.com id
	DD/6B-17938-0157DEF4; Fri, 29 Jun 2012 09:27:44 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340962047!15593512!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMzAxMjk4\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4601 invoked from network); 29 Jun 2012 09:27:28 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 09:27:28 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 29 Jun 2012 02:27:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="162170838"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 29 Jun 2012 02:27:26 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 29 Jun 2012 02:27:26 -0700
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, 29 Jun 2012 02:27:26 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX151.ccr.corp.intel.com ([10.239.6.50]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 17:27:12 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNUrFAT/njWom2N0+Is+zDJD5/bZcMEOKQgAL1rYCAAgapEA==
Date: Fri, 29 Jun 2012 09:27:12 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE284E7@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
	<20120628103025.GB34995@ocelot.phlegethon.org>
In-Reply-To: <20120628103025.GB34995@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>, "keir@xen.org" <keir@xen.org>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Thursday, June 28, 2012 6:30 PM
> To: Hao, Xudong
> Cc: keir@xen.org; Shan, Haitao; JBeulich@suse.com; Zhang, Xiantao;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> 
> At 05:31 +0000 on 26 Jun (1340688686), Hao, Xudong wrote:
> > > - Have you measured what difference this makes?  I take it it improves
> > >   performance during live migration but it would be good to know how
> much
> > >   before taking on extra code.
> >
> > We did live migration performance testing with patches, it's
> > embarrassed to say but the result show there is no performance gain
> > and no performance loss indeed.
> 
> Ah.
> 
> But maybe they have some performance advantage for guests with
> graphics-heavy workloads (by making the VRAM tracking faster)?
> Could you test that to see if that's the case?
> 

Ok, I'll test it.

> If it's not, I think you'll understand if we don't take these patches.
> 
> 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 Jun 29 09:32:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09: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 1SkXYW-0001Rt-8F; Fri, 29 Jun 2012 09:32:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkXYU-0001Rl-V2
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:31:59 +0000
Received: from [85.158.139.83:35236] by server-3.bemta-5.messagelabs.com id
	A0/8D-03367-D067DEF4; Fri, 29 Jun 2012 09:31:57 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340962315!30131333!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMzAxNTAw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11051 invoked from network); 29 Jun 2012 09:31:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 09:31:56 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 29 Jun 2012 02:31:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="117312361"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 29 Jun 2012 02:31:55 -0700
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; Fri, 29 Jun 2012 02:31:54 -0700
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; Fri, 29 Jun 2012 02:31:54 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX151.ccr.corp.intel.com ([10.239.6.50]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 17:31:53 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNUrFAT/njWom2N0+Is+zDJD5/bZcMEOKQgAMS3wCAAemuUA==
Date: Fri, 29 Jun 2012 09:31:53 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE2850B@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
	<CAFLBxZab3z3aSbD-qBAsS_-rW5_6mdOmnucBNnKYF4T9UtV6QQ@mail.gmail.com>
In-Reply-To: <CAFLBxZab3z3aSbD-qBAsS_-rW5_6mdOmnucBNnKYF4T9UtV6QQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang, 
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
> Dunlap
> Sent: Thursday, June 28, 2012 8:15 PM
> To: Hao, Xudong
> Cc: Tim Deegan; keir@xen.org; Shan, Haitao; JBeulich@suse.com; Zhang,
> Xiantao; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> =

> On Tue, Jun 26, 2012 at 6:31 AM, Hao, Xudong <xudong.hao@intel.com>
> wrote:
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xen.org]
> >> Sent: Monday, June 25, 2012 5:02 PM
> >> To: Hao, Xudong
> >> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xianta=
o;
> >> JBeulich@suse.com
> >> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> >>
> >> At 09:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
> >> > Changes from v1:
> >> > - Move hap_has_dirty_bit and hap_has_access_bit definition from patc=
h 3
> to
> >> patch2.
> >> > - define them as bool_t instead of int.
> >> >
> >> > Extended Page Tables introduce two bit: access bit and dirty bit, A/=
D bits
> >> > enable VMMs to efficiently implement memory management and page
> >> classification
> >> > algorithms to optimize VM memory operations.
> >> >
> >> > This series of patches enable EPT dirty bit feature for guest live m=
igration.
> >>
> >> Thanks for this. =A0I have a few high-level questions:
> >>
> >> - You're proposing this for after 4.2, right?
> >>
> >
> > Yes, they are not targeted to 4.2.
> >
> >> - Have you measured what difference this makes? =A0I take it it improv=
es
> >> =A0 performance during live migration but it would be good to know how
> much
> >> =A0 before taking on extra code.
> >>
> >
> > We did live migration performance testing with patches, it's embarrasse=
d to
> say but the result show there is no performance gain and no performance l=
oss
> indeed.
> =

> What exactly did you measure?  If you measured the speed of the
> migration itself on an empty system, it might not be noticeable; but
> if, for instance, it increased the performance of a workload running
> *inside* the guest during the migration, =


Measured both idle guest and w/workload(specjbb) running guest migration.

> or if it decreased the cpu
> usage of qemu during the migraiton, that might be worth it.
> =


Thanks this point, will look at if cpu usage decreasing.

>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 09:32:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09: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 1SkXYW-0001Rt-8F; Fri, 29 Jun 2012 09:32:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xudong.hao@intel.com>) id 1SkXYU-0001Rl-V2
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:31:59 +0000
Received: from [85.158.139.83:35236] by server-3.bemta-5.messagelabs.com id
	A0/8D-03367-D067DEF4; Fri, 29 Jun 2012 09:31:57 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340962315!30131333!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMzAxNTAw\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11051 invoked from network); 29 Jun 2012 09:31:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 09:31:56 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 29 Jun 2012 02:31:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="117312361"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 29 Jun 2012 02:31:55 -0700
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; Fri, 29 Jun 2012 02:31:54 -0700
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; Fri, 29 Jun 2012 02:31:54 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.244]) by
	SHSMSX151.ccr.corp.intel.com ([10.239.6.50]) with mapi id
	14.01.0355.002; Fri, 29 Jun 2012 17:31:53 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
Thread-Index: AQHNUrFAT/njWom2N0+Is+zDJD5/bZcMEOKQgAMS3wCAAemuUA==
Date: Fri, 29 Jun 2012 09:31:53 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FE2850B@SHSMSX102.ccr.corp.intel.com>
References: <1340157467-19553-1-git-send-email-xudong.hao@intel.com>
	<20120625090201.GB1488@ocelot.phlegethon.org>
	<403610A45A2B5242BD291EDAE8B37D300FE02769@SHSMSX102.ccr.corp.intel.com>
	<CAFLBxZab3z3aSbD-qBAsS_-rW5_6mdOmnucBNnKYF4T9UtV6QQ@mail.gmail.com>
In-Reply-To: <CAFLBxZab3z3aSbD-qBAsS_-rW5_6mdOmnucBNnKYF4T9UtV6QQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, "Shan, Haitao" <haitao.shan@intel.com>,
	Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>, "Zhang, 
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
> Dunlap
> Sent: Thursday, June 28, 2012 8:15 PM
> To: Hao, Xudong
> Cc: Tim Deegan; keir@xen.org; Shan, Haitao; JBeulich@suse.com; Zhang,
> Xiantao; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> =

> On Tue, Jun 26, 2012 at 6:31 AM, Hao, Xudong <xudong.hao@intel.com>
> wrote:
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xen.org]
> >> Sent: Monday, June 25, 2012 5:02 PM
> >> To: Hao, Xudong
> >> Cc: xen-devel@lists.xen.org; Shan, Haitao; keir@xen.org; Zhang, Xianta=
o;
> >> JBeulich@suse.com
> >> Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: enable EPT A/D bit feature
> >>
> >> At 09:57 +0800 on 20 Jun (1340186263), Xudong Hao wrote:
> >> > Changes from v1:
> >> > - Move hap_has_dirty_bit and hap_has_access_bit definition from patc=
h 3
> to
> >> patch2.
> >> > - define them as bool_t instead of int.
> >> >
> >> > Extended Page Tables introduce two bit: access bit and dirty bit, A/=
D bits
> >> > enable VMMs to efficiently implement memory management and page
> >> classification
> >> > algorithms to optimize VM memory operations.
> >> >
> >> > This series of patches enable EPT dirty bit feature for guest live m=
igration.
> >>
> >> Thanks for this. =A0I have a few high-level questions:
> >>
> >> - You're proposing this for after 4.2, right?
> >>
> >
> > Yes, they are not targeted to 4.2.
> >
> >> - Have you measured what difference this makes? =A0I take it it improv=
es
> >> =A0 performance during live migration but it would be good to know how
> much
> >> =A0 before taking on extra code.
> >>
> >
> > We did live migration performance testing with patches, it's embarrasse=
d to
> say but the result show there is no performance gain and no performance l=
oss
> indeed.
> =

> What exactly did you measure?  If you measured the speed of the
> migration itself on an empty system, it might not be noticeable; but
> if, for instance, it increased the performance of a workload running
> *inside* the guest during the migration, =


Measured both idle guest and w/workload(specjbb) running guest migration.

> or if it decreased the cpu
> usage of qemu during the migraiton, that might be worth it.
> =


Thanks this point, will look at if cpu usage decreasing.

>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 09:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkXeZ-000268-Vj; Fri, 29 Jun 2012 09:38:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkXeZ-000261-8q
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:38:15 +0000
Received: from [85.158.139.83:33601] by server-6.bemta-5.messagelabs.com id
	16/97-11348-6877DEF4; Fri, 29 Jun 2012 09:38:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340962693!27422142!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 29 Jun 2012 09:38:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 09:38:13 -0000
Received: from [83.211.176.2] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79214486; Fri, 29 Jun 2012 11:38:13 +0200
Message-ID: <1340962685.5711.0.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 29 Jun 2012 11:38:05 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1D5F48@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace> <20120628124106.GL2058@reaktio.net>
	<1340902989.17236.5.camel@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1D5F48@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6077595640562927361=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6077595640562927361==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-sNVaO5EHjENQqQlG5AVN"


--=-sNVaO5EHjENQqQlG5AVN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-29 at 05:29 +0000, Zhang, Yang Z wrote:=20
> > However, I'm still not sure I see how that ("guest NUMA") and live
> > migration should affect (either now or during 4.3 dev cycle) the initia=
l
> > placement of a domain... That's what I was asking.
>=20
> When doing migration, if the target machine is able to provide the same m=
emory framework for the guest, we need to consider it firstly.
>
Ok, I see, and I think it make sense. Thanks for replying. :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-sNVaO5EHjENQqQlG5AVN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/td30ACgkQk4XaBE3IOsRd/ACeM+caDPbBBdAXClxKqBst3kGh
6NwAn1mt4d6HWzG8sFY6Vt8evEn/Gps4
=zOgT
-----END PGP SIGNATURE-----

--=-sNVaO5EHjENQqQlG5AVN--



--===============6077595640562927361==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6077595640562927361==--



From xen-devel-bounces@lists.xen.org Fri Jun 29 09:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09:38:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkXeZ-000268-Vj; Fri, 29 Jun 2012 09:38:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkXeZ-000261-8q
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:38:15 +0000
Received: from [85.158.139.83:33601] by server-6.bemta-5.messagelabs.com id
	16/97-11348-6877DEF4; Fri, 29 Jun 2012 09:38:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340962693!27422142!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 29 Jun 2012 09:38:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 09:38:13 -0000
Received: from [83.211.176.2] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79214486; Fri, 29 Jun 2012 11:38:13 +0200
Message-ID: <1340962685.5711.0.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 29 Jun 2012 11:38:05 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1D5F48@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<1340878329.21008.2.camel@Solace> <20120628124106.GL2058@reaktio.net>
	<1340902989.17236.5.camel@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1D5F48@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6077595640562927361=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6077595640562927361==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-sNVaO5EHjENQqQlG5AVN"


--=-sNVaO5EHjENQqQlG5AVN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-29 at 05:29 +0000, Zhang, Yang Z wrote:=20
> > However, I'm still not sure I see how that ("guest NUMA") and live
> > migration should affect (either now or during 4.3 dev cycle) the initia=
l
> > placement of a domain... That's what I was asking.
>=20
> When doing migration, if the target machine is able to provide the same m=
emory framework for the guest, we need to consider it firstly.
>
Ok, I see, and I think it make sense. Thanks for replying. :-)

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-sNVaO5EHjENQqQlG5AVN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/td30ACgkQk4XaBE3IOsRd/ACeM+caDPbBBdAXClxKqBst3kGh
6NwAn1mt4d6HWzG8sFY6Vt8evEn/Gps4
=zOgT
-----END PGP SIGNATURE-----

--=-sNVaO5EHjENQqQlG5AVN--



--===============6077595640562927361==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6077595640562927361==--



From xen-devel-bounces@lists.xen.org Fri Jun 29 09:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09:47: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 1SkXmZ-0002LW-0f; Fri, 29 Jun 2012 09:46:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkXmY-0002LP-1D
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:46:30 +0000
Received: from [85.158.139.83:11882] by server-5.bemta-5.messagelabs.com id
	92/AF-02722-5797DEF4; Fri, 29 Jun 2012 09:46:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340963188!24987088!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5399 invoked from network); 29 Jun 2012 09:46:28 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 09:46:28 -0000
Received: from [83.211.176.2] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79214696; Fri, 29 Jun 2012 11:46:27 +0200
Message-ID: <1340963186.5711.8.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 29 Jun 2012 11:46:26 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1D6F7C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E1D6F7C@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8573993442738418571=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8573993442738418571==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-XkGvUSH24obAUQXaWF4Q"


--=-XkGvUSH24obAUQXaWF4Q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-29 at 05:38 +0000, Zhang, Yang Z wrote:=20
> > Just to help set the context for these patch series: We have lots of
> > big plans for NUMA in the 4.3 release (and are always glad for input
> > and help!), but the current goal is just to have *something* for the
> > upcoming 4.2 release.
>=20
> Nice to hear you guys have the big plans fo NUMA things. :)
>=20
Yes, we actually do! :-)

So, as you mentioned you're working on related stuff, do you think it
would be useful to try to coordinate a bit? You know, just to avoid
duplicating the efforts too much, and achieving the best result with
minimum strain...

I think even just opening a new thread on this mailing list would do,
but I'm open to any other solution anyone has in mind. For the records,
I plan to talk about NUMA at and during XenSummit too (although I still
don't know whether my talk has been accepted or not :-D).

Just let me (again, you and/or anyone else) know your thoughts and
preferences are. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-XkGvUSH24obAUQXaWF4Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/teXIACgkQk4XaBE3IOsRO4wCfV8V5tE3tteKlXST3tjT7E8IK
ABIAn2c0U8q5Wajfr2EKUGyoVnVROemg
=8gfW
-----END PGP SIGNATURE-----

--=-XkGvUSH24obAUQXaWF4Q--



--===============8573993442738418571==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8573993442738418571==--



From xen-devel-bounces@lists.xen.org Fri Jun 29 09:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09:47: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 1SkXmZ-0002LW-0f; Fri, 29 Jun 2012 09:46:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1SkXmY-0002LP-1D
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 09:46:30 +0000
Received: from [85.158.139.83:11882] by server-5.bemta-5.messagelabs.com id
	92/AF-02722-5797DEF4; Fri, 29 Jun 2012 09:46:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1340963188!24987088!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5399 invoked from network); 29 Jun 2012 09:46:28 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	29 Jun 2012 09:46:28 -0000
Received: from [83.211.176.2] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 79214696; Fri, 29 Jun 2012 11:46:27 +0200
Message-ID: <1340963186.5711.8.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Date: Fri, 29 Jun 2012 11:46:26 +0200
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E1D6F7C@SHSMSX101.ccr.corp.intel.com>
References: <patchbomb.1339779868@Solace>
	<81f18379bb3d4d9397d1.1339779876@Solace>
	<A9667DDFB95DB7438FA9D7D576C3D87E1BDD1C@SHSMSX101.ccr.corp.intel.com>
	<CAFLBxZa3XNMjicbvM4L86quTuq+xJ9YzY4oYXDoG=T6PhBzE8g@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E1D6F7C@SHSMSX101.ccr.corp.intel.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08 of 10 v2] libxl: enable automatic
 placement of guests on NUMA nodes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8573993442738418571=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8573993442738418571==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-XkGvUSH24obAUQXaWF4Q"


--=-XkGvUSH24obAUQXaWF4Q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-29 at 05:38 +0000, Zhang, Yang Z wrote:=20
> > Just to help set the context for these patch series: We have lots of
> > big plans for NUMA in the 4.3 release (and are always glad for input
> > and help!), but the current goal is just to have *something* for the
> > upcoming 4.2 release.
>=20
> Nice to hear you guys have the big plans fo NUMA things. :)
>=20
Yes, we actually do! :-)

So, as you mentioned you're working on related stuff, do you think it
would be useful to try to coordinate a bit? You know, just to avoid
duplicating the efforts too much, and achieving the best result with
minimum strain...

I think even just opening a new thread on this mailing list would do,
but I'm open to any other solution anyone has in mind. For the records,
I plan to talk about NUMA at and during XenSummit too (although I still
don't know whether my talk has been accepted or not :-D).

Just let me (again, you and/or anyone else) know your thoughts and
preferences are. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-XkGvUSH24obAUQXaWF4Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAk/teXIACgkQk4XaBE3IOsRO4wCfV8V5tE3tteKlXST3tjT7E8IK
ABIAn2c0U8q5Wajfr2EKUGyoVnVROemg
=8gfW
-----END PGP SIGNATURE-----

--=-XkGvUSH24obAUQXaWF4Q--



--===============8573993442738418571==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8573993442738418571==--



From xen-devel-bounces@lists.xen.org Fri Jun 29 09:59:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09: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 1SkXyq-0002WW-9l; Fri, 29 Jun 2012 09:59:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SkXyo-0002WR-92
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 09:59:10 +0000
Received: from [85.158.143.35:29531] by server-3.bemta-4.messagelabs.com id
	C5/FF-05808-D6C7DEF4; Fri, 29 Jun 2012 09:59:09 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340963948!16294488!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18775 invoked from network); 29 Jun 2012 09:59:09 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Jun 2012 09:59:09 -0000
Received: from mail64-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id
	14.1.225.23; Fri, 29 Jun 2012 09:57:18 +0000
Received: from mail64-va3 (localhost [127.0.0.1])	by mail64-va3-R.bigfish.com
	(Postfix) with ESMTP id 7599F602E4;
	Fri, 29 Jun 2012 09:57:18 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzzz2dh668h839hd25he5bhf0ah)
Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3
	(MessageSwitch) id 1340963836605022_17950;
	Fri, 29 Jun 2012 09:57:16 +0000 (UTC)
Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.245])	by
	mail64-va3.bigfish.com (Postfix) with ESMTP id 84BD834004F;
	Fri, 29 Jun 2012 09:57:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server id
	14.1.225.23; Fri, 29 Jun 2012 09:57:16 +0000
X-WSS-ID: 0M6DIED-01-0N6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D6E4102800D;	Fri, 29 Jun 2012 04:59:01 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 29 Jun 2012 04:59:21 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 29 Jun 2012 04:59:01 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 29 Jun 2012
	05:59:00 -0400
Message-ID: <4FED7C5F.1040908@amd.com>
Date: Fri, 29 Jun 2012 11:58:55 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
	<4FEC7FB8020000780008C885@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335265284@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335265284@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Nakajima,
	Jun" <jun.nakajima@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Susie" <susie.li@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Feedback from the AMD side:

slide 2:
- PV guests are supposed to install a MCE trap handler
  which reads the MSR values from struct mcinfo_bank.
  Hence it is unclear where the #GP should come from.
  Same for HVM guests which have a PV MCE "driver"
  (those are very rare in reality).

slide 3:
- unclear what "Weird per-domain MSRs" means
- unclear what "Unnatural MCE injection semantics" means

slide 4:
- typo: interace -> interface :-)
- enable UCR-related capabilities, but only on Intel machines
- Filter non-SRAO/SRAR banks:
  Rename it to "Let guest see northbridge bank only to the guest"

slide 7:
- ignore/disable CMCI and CTL2 on AMD

slide 8:
- Filter non-SRAO/SRAR banks:
  Rename it to "Let guest see northbridge bank only to the guest"
- Question: Should we allow the guest to inject errors? Does it make
  sense?
- always disable MCi_CTL2 on AMD

slide 9:
- Model specific issue: Also affects AMD as some models have
  l3 cache and some do not.
  E.g. it does not make sense to report l3 cache errors to guests


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 09:59:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 09: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 1SkXyq-0002WW-9l; Fri, 29 Jun 2012 09:59:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1SkXyo-0002WR-92
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 09:59:10 +0000
Received: from [85.158.143.35:29531] by server-3.bemta-4.messagelabs.com id
	C5/FF-05808-D6C7DEF4; Fri, 29 Jun 2012 09:59:09 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340963948!16294488!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18775 invoked from network); 29 Jun 2012 09:59:09 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Jun 2012 09:59:09 -0000
Received: from mail64-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id
	14.1.225.23; Fri, 29 Jun 2012 09:57:18 +0000
Received: from mail64-va3 (localhost [127.0.0.1])	by mail64-va3-R.bigfish.com
	(Postfix) with ESMTP id 7599F602E4;
	Fri, 29 Jun 2012 09:57:18 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzzz2dh668h839hd25he5bhf0ah)
Received: from mail64-va3 (localhost.localdomain [127.0.0.1]) by mail64-va3
	(MessageSwitch) id 1340963836605022_17950;
	Fri, 29 Jun 2012 09:57:16 +0000 (UTC)
Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.245])	by
	mail64-va3.bigfish.com (Postfix) with ESMTP id 84BD834004F;
	Fri, 29 Jun 2012 09:57:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server id
	14.1.225.23; Fri, 29 Jun 2012 09:57:16 +0000
X-WSS-ID: 0M6DIED-01-0N6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D6E4102800D;	Fri, 29 Jun 2012 04:59:01 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 29 Jun 2012 04:59:21 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 29 Jun 2012 04:59:01 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 29 Jun 2012
	05:59:00 -0400
Message-ID: <4FED7C5F.1040908@amd.com>
Date: Fri, 29 Jun 2012 11:58:55 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233525D395@SHSMSX101.ccr.corp.intel.com>
	<4FEB236C020000780008C392@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263B9D@SHSMSX101.ccr.corp.intel.com>
	<4FEC3B4A020000780008C673@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335263D6C@SHSMSX101.ccr.corp.intel.com>
	<4FEC463E020000780008C6A7@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335264914@SHSMSX101.ccr.corp.intel.com>
	<4FEC7FB8020000780008C885@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335265284@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335265284@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Nakajima,
	Jun" <jun.nakajima@intel.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>, "Auld,
	Will" <will.auld@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Susie" <susie.li@intel.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>
Subject: Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Feedback from the AMD side:

slide 2:
- PV guests are supposed to install a MCE trap handler
  which reads the MSR values from struct mcinfo_bank.
  Hence it is unclear where the #GP should come from.
  Same for HVM guests which have a PV MCE "driver"
  (those are very rare in reality).

slide 3:
- unclear what "Weird per-domain MSRs" means
- unclear what "Unnatural MCE injection semantics" means

slide 4:
- typo: interace -> interface :-)
- enable UCR-related capabilities, but only on Intel machines
- Filter non-SRAO/SRAR banks:
  Rename it to "Let guest see northbridge bank only to the guest"

slide 7:
- ignore/disable CMCI and CTL2 on AMD

slide 8:
- Filter non-SRAO/SRAR banks:
  Rename it to "Let guest see northbridge bank only to the guest"
- Question: Should we allow the guest to inject errors? Does it make
  sense?
- always disable MCi_CTL2 on AMD

slide 9:
- Model specific issue: Also affects AMD as some models have
  l3 cache and some do not.
  E.g. it does not make sense to report l3 cache errors to guests


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:01:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkY0i-0002ez-PQ; Fri, 29 Jun 2012 10:01:08 +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 1SkY0i-0002er-3L
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:01:08 +0000
Received: from [85.158.138.51:61103] by server-3.bemta-3.messagelabs.com id
	2B/F4-26490-EDC7DEF4; Fri, 29 Jun 2012 10:01:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340964060!11499456!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10396 invoked from network); 29 Jun 2012 10:01:01 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:01:01 -0000
Received: by qcab12 with SMTP id b12so804638qca.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=w5q6ixyGB4qouKyKvP7w7DxbgJzMsAYHpmnK3NmMDxA=;
	b=oWusQVZBqPBY/OeCheDX3h8+uy0HJ3cPhq+S8OIBaC6v+n1fIdlyzRFhBip+DuaoHS
	ML7jjrQss/jG9uszfGfGJ7xIZPnfVb6+28wSWvN6rhT3/zqcBv4ZjESuFOk+Tct60PuG
	MrblVxqnxrvpYFzGxcmZwrmOtoB8tSvwxY8ZCVhu0Sqdq27R97VOPnsl9XcFeadI3tza
	1g92FhYxYwO3mkxL6J1g+KlbTxg1yW1pnBi0bo9meSXnM9fOIijwEiOu6mh7uIaWMh3v
	x1S/1k8fwPesNu75Jfo8p5ltNSdBEje/qWwoMtajZ4VQqN9m3FTGb57IWjZNZLMUz1YO
	4lEA==
MIME-Version: 1.0
Received: by 10.229.135.77 with SMTP id m13mr323233qct.12.1340964060181; Fri,
	29 Jun 2012 03:01:00 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 29 Jun 2012 03:01:00 -0700 (PDT)
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
Date: Fri, 29 Jun 2012 11:01:00 +0100
X-Google-Sender-Auth: 4ZoviIZ9VXITXfdQABy3UqP5Roc
Message-ID: <CAFLBxZYWnW_d8YDeFdzjdUhyysqxd12gPU4Pr6Rj7LQjtLwx+A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Thomas Goirand <thomas@goirand.fr>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 27, 2012 at 7:07 PM, Thomas Goirand <thomas@goirand.fr> wrote:
> On 06/20/2012 05:45 PM, George Dunlap wrote:
>> The only way this would work is if the predisclosure list consisted
>> exclusively of software providers, and specifically excluded service
>> providers.
> I agree, though you might have corner cases.
>
> What if you are *both* software and service provider (eg: I'm working on
> Debian and XCP, and my small company provides a hosted Xen service)?

If we do make a rule that only software providers can be on the list,
and not service providers, then ideally you should try to separate the
roles.  If you are on the list as a software provider, you should use
that information only to prepare patches; but not deploy them on your
own systems until the embargo date.

In a way, the question is very similar to asking, "I'm working on
Debian and XCP, and my best friend owns a small company that provides
a hosted Xen service."  If you told your friend about the
vulnerability, you would be breaking the security embargo (and giving
your friend an unfair advantage over other hosting services), and
would be at risk of being removed from the list if someone found out.
If you wear two "hats", as it were, the same would be true if your
developer "hat" told your service provider "hat": actually updating
your systems before the embargo would (I think) be considered breaking
the embargo, and would be giving yourself an unfair advantage over
other hosting services.

(All of the above discussion is, of course, only valid in the
hypothetical situation that we don't allow service providers to be on
the list.)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:01:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkY0i-0002ez-PQ; Fri, 29 Jun 2012 10:01:08 +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 1SkY0i-0002er-3L
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:01:08 +0000
Received: from [85.158.138.51:61103] by server-3.bemta-3.messagelabs.com id
	2B/F4-26490-EDC7DEF4; Fri, 29 Jun 2012 10:01:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1340964060!11499456!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10396 invoked from network); 29 Jun 2012 10:01:01 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:01:01 -0000
Received: by qcab12 with SMTP id b12so804638qca.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=w5q6ixyGB4qouKyKvP7w7DxbgJzMsAYHpmnK3NmMDxA=;
	b=oWusQVZBqPBY/OeCheDX3h8+uy0HJ3cPhq+S8OIBaC6v+n1fIdlyzRFhBip+DuaoHS
	ML7jjrQss/jG9uszfGfGJ7xIZPnfVb6+28wSWvN6rhT3/zqcBv4ZjESuFOk+Tct60PuG
	MrblVxqnxrvpYFzGxcmZwrmOtoB8tSvwxY8ZCVhu0Sqdq27R97VOPnsl9XcFeadI3tza
	1g92FhYxYwO3mkxL6J1g+KlbTxg1yW1pnBi0bo9meSXnM9fOIijwEiOu6mh7uIaWMh3v
	x1S/1k8fwPesNu75Jfo8p5ltNSdBEje/qWwoMtajZ4VQqN9m3FTGb57IWjZNZLMUz1YO
	4lEA==
MIME-Version: 1.0
Received: by 10.229.135.77 with SMTP id m13mr323233qct.12.1340964060181; Fri,
	29 Jun 2012 03:01:00 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 29 Jun 2012 03:01:00 -0700 (PDT)
In-Reply-To: <4FEB4BDD.5040205@goirand.fr>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FEB4BDD.5040205@goirand.fr>
Date: Fri, 29 Jun 2012 11:01:00 +0100
X-Google-Sender-Auth: 4ZoviIZ9VXITXfdQABy3UqP5Roc
Message-ID: <CAFLBxZYWnW_d8YDeFdzjdUhyysqxd12gPU4Pr6Rj7LQjtLwx+A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Thomas Goirand <thomas@goirand.fr>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 27, 2012 at 7:07 PM, Thomas Goirand <thomas@goirand.fr> wrote:
> On 06/20/2012 05:45 PM, George Dunlap wrote:
>> The only way this would work is if the predisclosure list consisted
>> exclusively of software providers, and specifically excluded service
>> providers.
> I agree, though you might have corner cases.
>
> What if you are *both* software and service provider (eg: I'm working on
> Debian and XCP, and my small company provides a hosted Xen service)?

If we do make a rule that only software providers can be on the list,
and not service providers, then ideally you should try to separate the
roles.  If you are on the list as a software provider, you should use
that information only to prepare patches; but not deploy them on your
own systems until the embargo date.

In a way, the question is very similar to asking, "I'm working on
Debian and XCP, and my best friend owns a small company that provides
a hosted Xen service."  If you told your friend about the
vulnerability, you would be breaking the security embargo (and giving
your friend an unfair advantage over other hosting services), and
would be at risk of being removed from the list if someone found out.
If you wear two "hats", as it were, the same would be true if your
developer "hat" told your service provider "hat": actually updating
your systems before the embargo would (I think) be considered breaking
the embargo, and would be giving yourself an unfair advantage over
other hosting services.

(All of the above discussion is, of course, only valid in the
hypothetical situation that we don't allow service providers to be on
the list.)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:03:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkY3B-0002tE-LS; Fri, 29 Jun 2012 10:03:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkY3A-0002t3-44
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:03:40 +0000
Received: from [85.158.143.99:37667] by server-1.bemta-4.messagelabs.com id
	A2/DA-24392-B7D7DEF4; Fri, 29 Jun 2012 10:03:39 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340964216!28847124!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30519 invoked from network); 29 Jun 2012 10:03:37 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:03:37 -0000
Received: by vcbfo13 with SMTP id fo13so2681891vcb.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:03:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=vAAYfzoRRA/iZFUMcN4xusEaVswpkMYHLQB5CtwQ0lQ=;
	b=NtgwSJBIKNXReOQwPtQXb+JMDAXlmCQ5N4HBwLJOPkRxnnv5s9qk/mWlHR70RUzmbO
	Wov1P+1bqX62p+bdS4dQi731ZFVGpULOBdcSe+Tv4T7O5mGaJXuHjvUwsazOeM5khcFa
	bSxmj0hNfvRgRLfLBeoFJ3DhFh/QtllHe7VK1/s5nmIcJ70FcemeZHC2/ZX+N8yFk3rG
	RtHIYdH7AZsuJj5JIvQsqjMXobNXV8lw0TWCz5YMP+cNBqgrg0x7NgR14AQ3UyS9MPZE
	w+Mc6y7WPJkfXLCbVpZKAV+wB3s8THwzrJeFMrPjIPGfW/uEXCIl5bKYhs7vRuyE9oNU
	9ptg==
Received: by 10.52.98.226 with SMTP id el2mr472785vdb.119.1340964216526; Fri,
	29 Jun 2012 03:03:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Fri, 29 Jun 2012 03:03:16 -0700 (PDT)
In-Reply-To: <4FED8467020000780008CC68@nat28.tlf.novell.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
	<4FED8467020000780008CC68@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Fri, 29 Jun 2012 11:03:16 +0100
Message-ID: <CAEBdQ905mtzq3SYXn1SfCYHrENS4sFKN_U6wqNJi5osro-=ZkA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 29 June 2012 09:33, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>> --- /dev/null
>> +++ b/xen/include/public/v4v.h
>> @@ -0,0 +1,240 @@
>> +/**********************************************************************=
********
>> + * V4V
>> + *
>> + * Version 2 of v2v (Virtual-to-Virtual)
>> + *
>> + * Copyright (c) 2010, Citrix Systems
>> + *
>> + * 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. =A0See 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 =A002111-13=
07 =A0USA
>> + */
>> +
>> +#ifndef __XEN_PUBLIC_V4V_H__
>> +#define __XEN_PUBLIC_V4V_H__
>> +
>> +#include "xen.h"
>> +
>> +/*
>> + * Structure definitions
>> + */
>> +
>> +#define V4V_PROTO_DGRAM =A0 =A0 =A0 =A0 =A0 =A0 =A00x3c2c1db8
>> +#define V4V_PROTO_STREAM =A0 =A0 0x70f6a8e5
>> +
>> +#ifdef __i386__
>
> How about ARM?
>
>> +# define V4V_RING_MAGIC =A0 =A0 =A0 =A0 0xdf6977f231abd910ULL
>> +# define V4V_PFN_LIST_MAGIC =A0 =A0 0x91dd6159045b302dULL
>
> Is there any reason these can't be also used for 64-bit?
>
>> +#else
>> +# define V4V_RING_MAGIC =A0 =A0 =A0 =A0 0xdf6977f231abd910
>> +# define V4V_PFN_LIST_MAGIC =A0 =A0 0x91dd6159045b302d
>> +#endif
>> +#define V4V_DOMID_INVALID =A0 =A0 =A0 (0x7FFFU)
>
> Any reason not to use DOMID_INVALID instead?
>

DOMID_INVALID has changed in the last releases we wanted to have our
definition so
it will be stable accross Xen 3.* Xen 4.*.

>> +#define V4V_DOMID_NONE =A0 =A0 =A0 =A0 =A0V4V_DOMID_INVALID
>> +#define V4V_DOMID_ANY =A0 =A0 =A0 =A0 =A0 V4V_DOMID_INVALID
>> +#define V4V_PORT_NONE =A0 =A0 =A0 =A0 =A0 0
>> +
>> +/*
>> + * struct v4v_iov
>> + * {
>> + * =A0 =A0 =A064 bits: iov_base
>> + * =A0 =A0 =A064 bits: iov_len
>> + * }
>> + */
>
> What's the point of not defining the types here?

Answer bellow.

>
>> +
>> +/*
>> + * struct v4v_addr
>> + * {
>> + * =A0 =A0 =A032 bits: port
>> + * =A0 =A0 =A016 bits: domid
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring_id
>> + * {
>> + * =A0 =A0 =A0struct v4v_addr: addr
>> + * =A0 =A0 =A016 bits: partner
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring
>> + * {
>> + * =A0 =A0 =A064 bits: magic
>> + * =A0 =A0 =A0v4v_rind_id: id
>> + * =A0 =A0 =A032 bits: len
>> + * =A0 =A0 =A032 bits: rx_ptr
>> + * =A0 =A0 =A032 bits: tx_ptr
>> + * =A0 =A0 =A064 bits: padding
>> + * =A0 =A0 =A0... : ring
>> + * }
>> + *
>> + * id:
>> + * xen only looks at this during register/unregister
>> + * and will fill in id.addr.domain
>> + *
>> + * rx_ptr: rx pointer, modified by domain
>> + * tx_ptr: tx pointer, modified by xen
>> + */
>> +
>> +#ifdef __i386__
>> +#define V4V_RING_DATA_MAGIC =A00x4ce4d30fbc82e92aULL
>
> Same here as above.
>
>> +#else
>> +#define V4V_RING_DATA_MAGIC =A00x4ce4d30fbc82e92a
>> +#endif
>> +
>> +#define V4V_RING_DATA_F_EMPTY =A0 =A0 =A0 1U << 0 /* Ring is empty */
>> +#define V4V_RING_DATA_F_EXISTS =A0 =A0 =A01U << 1 /* Ring exists */
>> +#define V4V_RING_DATA_F_PENDING =A0 =A0 1U << 2 /* Pending interrupt ex=
ists - do not
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 rely on this field - for
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 profiling only */
>> +#define V4V_RING_DATA_F_SUFFICIENT =A01U << 3 /* Sufficient space to qu=
eue
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 space_required bytes exists */
>> +
>> +/*
>> + * v4v_ring_data_ent
>> + * {
>> + * =A0 =A0 =A0v4v_addr: ring
>> + * =A0 =A0 =A016 bits: flags
>> + * =A0 =A0 =A016 bits: padding
>> + * =A0 =A0 =A032 bits: space_required
>> + * =A0 =A0 =A032 bits: max_message_size
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring_data
>> + * {
>> + * =A0 =A0 =A064 bits: magic (V4V_RING_DATA_MAGIC)
>> + * =A0 =A0 =A032 bits: nent
>> + * =A0 =A0 =A032 bits: padding
>> + * =A0 =A0 =A0256 bits: reserved
>> + * =A0 =A0 =A0... : v4v_ring_data_ent
>> + * }
>> + */
>> +
>> +
>> +#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
>> +/*
>> + * Messages on the ring are padded to 128 bits
>> + * Len here refers to the exact length of the data not including the
>> + * 128 bit header. The message uses
>> + * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
>> + */
>> +
>> +/*
>> + * v4v_stream_header
>> + * {
>> + * =A0 =A0 =A032 bits: flags
>> + * =A0 =A0 =A032 bits: conid
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring_message_header
>> + * {
>> + * =A0 =A0 =A032 bits: len
>> + * =A0 =A0 =A0v4v_addr: source
>> + * =A0 =A0 =A032 bits: protocol
>> + * =A0 =A0 =A0... : data
>> + * }
>> + */
>> +
>> +/*
>> + * HYPERCALLS
>> + */
>> +
>> +#define V4VOP_register_ring =A01
>> +/*
>> + * Registers a ring with Xen, if a ring with the same v4v_ring_id exist=
s,
>> + * this ring takes its place, registration will not change tx_ptr
>> + * unless it is invalid
>> + *
>> + * do_v4v_op(V4VOP_unregister_ring,
>> + * =A0 =A0 =A0 =A0 =A0 v4v_ring, XEN_GUEST_HANDLE(v4v_pfn),
>> + * =A0 =A0 =A0 =A0 =A0 NULL, npage, 0)
>> + */
>> +
>> +
>> +#define V4VOP_unregister_ring =A0 =A0 =A0 =A02
>> +/*
>> + * Unregister a ring.
>> + *
>> + * v4v_hypercall(V4VOP_send, v4v_ring, NULL, NULL, 0, 0)
>
> Assuming this and the earlier do_v4v_op() refer to the same
> thing, please use a single name consistently.
>

Ack.

>> + */
>> +
>> +#define V4VOP_send =A0 =A0 =A0 =A0 =A0 3
>> +/*
>> + * Sends len bytes of buf to dst, giving src as the source address (xen=
 will
>> + * ignore src->domain and put your domain in the actually message), xen
>> + * first looks for a ring with id.addr=3D=3Ddst and id.partner=3D=3Dsen=
ding_domain
>> + * if that fails it looks for id.addr=3D=3Ddst and id.partner=3D=3DDOMI=
D_ANY.
>> + * protocol is the 32 bit protocol number used from the message
>> + * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
>> + * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
>> + * sufficient space becomes available
>> + *
>> + * v4v_hypercall(V4VOP_send,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr src,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr dst,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 void* buf,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t len,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t protocol)
>> + */
>> +
>> +
>> +#define V4VOP_notify =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4
>> +/* Asks xen for information about other rings in the system
>> + *
>> + * ent->ring is the v4v_addr_t of the ring you want information on
>> + * the same matching rules are used as for V4VOP_send.
>> + *
>> + * ent->space_required =A0if this field is not null xen will check
>> + * that there is space in the destination ring for this many bytes
>> + * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
>> + * and CANCEL any pending interrupt for that ent->ring, if insufficient
>> + * space is available it will schedule an interrupt and the flag will
>> + * not be set.
>> + *
>> + * The flags are set by xen when notify replies
>> + * V4V_RING_DATA_F_EMPTY =A0 =A0 ring is empty
>> + * V4V_RING_DATA_F_PENDING =A0 interrupt is pending - don't rely on this
>> + * V4V_RING_DATA_F_SUFFICIENT =A0 =A0 =A0 =A0sufficient space for space=
_required is there
>> + * V4V_RING_DATA_F_EXISTS =A0 =A0ring exists
>> + *
>> + * v4v_hypercall(V4VOP_notify,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL, NULL, nent, 0)
>> + */
>> +
>> +
>> +#define V4VOP_sendv =A0 =A0 =A0 =A0 =A05
>> +/*
>> + * Identical to V4VOP_send except rather than buf and len it takes
>> + * an array of v4v_iov and a length of the array.
>> + *
>> + * v4v_hypercall(V4VOP_sendv,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr src,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr dst,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_iov iov,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t niov,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t protocol)
>> + */
>> +
>> +#endif /* __XEN_PUBLIC_V4V_H__ */
>> --- /dev/null
>> +++ b/xen/include/xen/v4v.h
>> @@ -0,0 +1,187 @@
>> +/**********************************************************************=
********
>> + * V4V
>> + *
>> + * Version 2 of v2v (Virtual-to-Virtual)
>> + *
>> + * Copyright (c) 2010, Citrix Systems
>> + *
>> + * 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. =A0See 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 =A002111-13=
07 =A0USA
>> + */
>> +
>> +#ifndef __V4V_PRIVATE_H__
>> +#define __V4V_PRIVATE_H__
>> +
>> +#include <xen/config.h>
>> +#include <xen/types.h>
>> +#include <xen/spinlock.h>
>> +#include <xen/smp.h>
>> +#include <xen/shared.h>
>> +#include <xen/list.h>
>> +#include <public/v4v.h>
>> +
>> +#define V4V_HTABLE_SIZE 32
>> +
>> +#define V4V_PACKED __attribute__ ((packed))
>> +
>> +/*
>> + * Structures
>> + */
>> +
>> +typedef struct v4v_iov
>> +{
>> + =A0 =A0uint64_t iov_base;
>> + =A0 =A0uint64_t iov_len;
>> +} V4V_PACKED v4v_iov_t;
>
> While you moved this to a private header now, I continue to
> think that none of the uses of V4V_PACKED are actually
> warranted (and hence these can't serve as reason for moving
> these public definitions into a private header). Use explicit
> padding fields, and you ought to be fine.
>

Answer bellow.

>> +DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
>> +
>> +typedef struct v4v_addr
>> +{
>> + =A0 =A0uint32_t port;
>> + =A0 =A0domid_t domain;
>> +} V4V_PACKED v4v_addr_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
>> +
>> +typedef struct v4v_ring_id
>> +{
>> + =A0 =A0struct v4v_addr addr;
>> + =A0 =A0domid_t partner;
>> +} V4V_PACKED v4v_ring_id_t;
>> +

This structure is really the one that cause trouble. domid_t is 16b
and v4v_addr_t is used
inside v4v_ring_t. I would like the structure to remind as close as we
can from the original version
as we already versions in the field. Having explicit padding will make
all the structures different
which will make much harder to write a driver that will support the
two versions of the API.

Also most all the consumer of those headers will have to rewrite the
structure anyway, for instance
the Linux kernel have it's own naming convention, macros definitions
which are different, etc..

>> +typedef uint64_t v4v_pfn_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
>> +
>> +typedef struct v4v_ring
>> +{
>> + =A0 =A0uint64_t magic;
>> + =A0 =A0struct v4v_ring_id id;
>> + =A0 =A0uint32_t len;
>> + =A0 =A0uint32_t rx_ptr;
>> + =A0 =A0uint32_t tx_ptr;
>> + =A0 =A0uint64_t reserved[4];
>> + =A0 =A0uint8_t ring[0];
>> +} V4V_PACKED v4v_ring_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
>
> If moved into the public header (where they belong imo), apart
> from this one none of the guest handle defines should actually be
> there, as there's no guest interface that would make use of them
> (they're used internally to v4v.c only).
>
> Also, conventionally there's no space before the opening
> parenthesis here.
>
> Jan
>
>> +
>> +typedef struct v4v_ring_data_ent
>> +{
>> + =A0 =A0struct v4v_addr ring;
>> + =A0 =A0uint16_t flags;
>> + =A0 =A0uint16_t pad0;
>> + =A0 =A0uint32_t space_required;
>> + =A0 =A0uint32_t max_message_size;
>> +} V4V_PACKED v4v_ring_data_ent_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
>> +
>> +typedef struct v4v_ring_data
>> +{
>> + =A0 =A0uint64_t magic;
>> + =A0 =A0uint32_t nent;
>> + =A0 =A0uint32_t padding;
>> + =A0 =A0uint64_t reserved[4];
>> + =A0 =A0v4v_ring_data_ent_t ring[0];
>> +} V4V_PACKED v4v_ring_data_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
>> +
>> +struct v4v_stream_header
>> +{
>> + =A0 =A0uint32_t flags;
>> + =A0 =A0uint32_t conid;
>> +} V4V_PACKED;
>> +
>> +struct v4v_ring_message_header
>> +{
>> + =A0 =A0uint32_t len;
>> + =A0 =A0struct v4v_addr source;
>> + =A0 =A0uint32_t protocol;
>> + =A0 =A0uint8_t data[0];
>> +} V4V_PACKED;
>> +
>> +/*
>> + * Helper functions
>> + */
>> +
>> +
>> +static inline uint16_t
>> +v4v_hash_fn (struct v4v_ring_id *id)
>> +{
>> + =A0uint16_t ret;
>> + =A0ret =3D (uint16_t) (id->addr.port >> 16);
>> + =A0ret ^=3D (uint16_t) id->addr.port;
>> + =A0ret ^=3D id->addr.domain;
>> + =A0ret ^=3D id->partner;
>> +
>> + =A0ret &=3D (V4V_HTABLE_SIZE-1);
>> +
>> + =A0return ret;
>> +}
>> +
>> +struct v4v_pending_ent
>> +{
>> + =A0struct hlist_node node;
>> + =A0domid_t id;
>> + =A0uint32_t len;
>> +} V4V_PACKED;
>> +
>> +
>> +struct v4v_ring_info
>> +{
>> + =A0/* next node in the hash, protected by L2 =A0*/
>> + =A0struct hlist_node node;
>> + =A0/* this ring's id, protected by L2 */
>> + =A0struct v4v_ring_id id;
>> + =A0/* L3 */
>> + =A0spinlock_t lock;
>> + =A0/* cached length of the ring (from ring->len), protected by L3 */
>> + =A0uint32_t len;
>> + =A0uint32_t npage;
>> + =A0/* cached tx pointer location, protected by L3 */
>> + =A0uint32_t tx_ptr;
>> + =A0/* guest ring, protected by L3 */
>> + =A0XEN_GUEST_HANDLE(v4v_ring_t) ring;
>> + =A0/* mapped ring pages protected by L3*/
>> + =A0uint8_t **mfn_mapping;
>> + =A0/* list of mfns of guest ring */
>> + =A0mfn_t *mfns;
>> + =A0/* list of struct v4v_pending_ent for this ring, L3 */
>> + =A0struct hlist_head pending;
>> +} V4V_PACKED;
>> +
>> +/*
>> + * The value of the v4v element in a struct domain is
>> + * protected by the global lock L1
>> + */
>> +struct v4v_domain
>> +{
>> + =A0/* L2 */
>> + =A0rwlock_t lock;
>> + =A0/* protected by L2 */
>> + =A0struct hlist_head ring_hash[V4V_HTABLE_SIZE];
>> +} V4V_PACKED;
>> +
>> +void v4v_destroy(struct domain *d);
>> +int v4v_init(struct domain *d);
>> +long do_v4v_op (int cmd,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XEN_GUEST_HANDLE (void) arg1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XEN_GUEST_HANDLE (void) arg2,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XEN_GUEST_HANDLE (void) arg3,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t arg4,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t arg5);
>> +
>> +#endif /* __V4V_PRIVATE_H__ */
>

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:03:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkY3B-0002tE-LS; Fri, 29 Jun 2012 10:03:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkY3A-0002t3-44
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:03:40 +0000
Received: from [85.158.143.99:37667] by server-1.bemta-4.messagelabs.com id
	A2/DA-24392-B7D7DEF4; Fri, 29 Jun 2012 10:03:39 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340964216!28847124!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30519 invoked from network); 29 Jun 2012 10:03:37 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:03:37 -0000
Received: by vcbfo13 with SMTP id fo13so2681891vcb.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:03:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=vAAYfzoRRA/iZFUMcN4xusEaVswpkMYHLQB5CtwQ0lQ=;
	b=NtgwSJBIKNXReOQwPtQXb+JMDAXlmCQ5N4HBwLJOPkRxnnv5s9qk/mWlHR70RUzmbO
	Wov1P+1bqX62p+bdS4dQi731ZFVGpULOBdcSe+Tv4T7O5mGaJXuHjvUwsazOeM5khcFa
	bSxmj0hNfvRgRLfLBeoFJ3DhFh/QtllHe7VK1/s5nmIcJ70FcemeZHC2/ZX+N8yFk3rG
	RtHIYdH7AZsuJj5JIvQsqjMXobNXV8lw0TWCz5YMP+cNBqgrg0x7NgR14AQ3UyS9MPZE
	w+Mc6y7WPJkfXLCbVpZKAV+wB3s8THwzrJeFMrPjIPGfW/uEXCIl5bKYhs7vRuyE9oNU
	9ptg==
Received: by 10.52.98.226 with SMTP id el2mr472785vdb.119.1340964216526; Fri,
	29 Jun 2012 03:03:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Fri, 29 Jun 2012 03:03:16 -0700 (PDT)
In-Reply-To: <4FED8467020000780008CC68@nat28.tlf.novell.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
	<4FED8467020000780008CC68@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Fri, 29 Jun 2012 11:03:16 +0100
Message-ID: <CAEBdQ905mtzq3SYXn1SfCYHrENS4sFKN_U6wqNJi5osro-=ZkA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 29 June 2012 09:33, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>> --- /dev/null
>> +++ b/xen/include/public/v4v.h
>> @@ -0,0 +1,240 @@
>> +/**********************************************************************=
********
>> + * V4V
>> + *
>> + * Version 2 of v2v (Virtual-to-Virtual)
>> + *
>> + * Copyright (c) 2010, Citrix Systems
>> + *
>> + * 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. =A0See 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 =A002111-13=
07 =A0USA
>> + */
>> +
>> +#ifndef __XEN_PUBLIC_V4V_H__
>> +#define __XEN_PUBLIC_V4V_H__
>> +
>> +#include "xen.h"
>> +
>> +/*
>> + * Structure definitions
>> + */
>> +
>> +#define V4V_PROTO_DGRAM =A0 =A0 =A0 =A0 =A0 =A0 =A00x3c2c1db8
>> +#define V4V_PROTO_STREAM =A0 =A0 0x70f6a8e5
>> +
>> +#ifdef __i386__
>
> How about ARM?
>
>> +# define V4V_RING_MAGIC =A0 =A0 =A0 =A0 0xdf6977f231abd910ULL
>> +# define V4V_PFN_LIST_MAGIC =A0 =A0 0x91dd6159045b302dULL
>
> Is there any reason these can't be also used for 64-bit?
>
>> +#else
>> +# define V4V_RING_MAGIC =A0 =A0 =A0 =A0 0xdf6977f231abd910
>> +# define V4V_PFN_LIST_MAGIC =A0 =A0 0x91dd6159045b302d
>> +#endif
>> +#define V4V_DOMID_INVALID =A0 =A0 =A0 (0x7FFFU)
>
> Any reason not to use DOMID_INVALID instead?
>

DOMID_INVALID has changed in the last releases we wanted to have our
definition so
it will be stable accross Xen 3.* Xen 4.*.

>> +#define V4V_DOMID_NONE =A0 =A0 =A0 =A0 =A0V4V_DOMID_INVALID
>> +#define V4V_DOMID_ANY =A0 =A0 =A0 =A0 =A0 V4V_DOMID_INVALID
>> +#define V4V_PORT_NONE =A0 =A0 =A0 =A0 =A0 0
>> +
>> +/*
>> + * struct v4v_iov
>> + * {
>> + * =A0 =A0 =A064 bits: iov_base
>> + * =A0 =A0 =A064 bits: iov_len
>> + * }
>> + */
>
> What's the point of not defining the types here?

Answer bellow.

>
>> +
>> +/*
>> + * struct v4v_addr
>> + * {
>> + * =A0 =A0 =A032 bits: port
>> + * =A0 =A0 =A016 bits: domid
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring_id
>> + * {
>> + * =A0 =A0 =A0struct v4v_addr: addr
>> + * =A0 =A0 =A016 bits: partner
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring
>> + * {
>> + * =A0 =A0 =A064 bits: magic
>> + * =A0 =A0 =A0v4v_rind_id: id
>> + * =A0 =A0 =A032 bits: len
>> + * =A0 =A0 =A032 bits: rx_ptr
>> + * =A0 =A0 =A032 bits: tx_ptr
>> + * =A0 =A0 =A064 bits: padding
>> + * =A0 =A0 =A0... : ring
>> + * }
>> + *
>> + * id:
>> + * xen only looks at this during register/unregister
>> + * and will fill in id.addr.domain
>> + *
>> + * rx_ptr: rx pointer, modified by domain
>> + * tx_ptr: tx pointer, modified by xen
>> + */
>> +
>> +#ifdef __i386__
>> +#define V4V_RING_DATA_MAGIC =A00x4ce4d30fbc82e92aULL
>
> Same here as above.
>
>> +#else
>> +#define V4V_RING_DATA_MAGIC =A00x4ce4d30fbc82e92a
>> +#endif
>> +
>> +#define V4V_RING_DATA_F_EMPTY =A0 =A0 =A0 1U << 0 /* Ring is empty */
>> +#define V4V_RING_DATA_F_EXISTS =A0 =A0 =A01U << 1 /* Ring exists */
>> +#define V4V_RING_DATA_F_PENDING =A0 =A0 1U << 2 /* Pending interrupt ex=
ists - do not
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 rely on this field - for
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 profiling only */
>> +#define V4V_RING_DATA_F_SUFFICIENT =A01U << 3 /* Sufficient space to qu=
eue
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 space_required bytes exists */
>> +
>> +/*
>> + * v4v_ring_data_ent
>> + * {
>> + * =A0 =A0 =A0v4v_addr: ring
>> + * =A0 =A0 =A016 bits: flags
>> + * =A0 =A0 =A016 bits: padding
>> + * =A0 =A0 =A032 bits: space_required
>> + * =A0 =A0 =A032 bits: max_message_size
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring_data
>> + * {
>> + * =A0 =A0 =A064 bits: magic (V4V_RING_DATA_MAGIC)
>> + * =A0 =A0 =A032 bits: nent
>> + * =A0 =A0 =A032 bits: padding
>> + * =A0 =A0 =A0256 bits: reserved
>> + * =A0 =A0 =A0... : v4v_ring_data_ent
>> + * }
>> + */
>> +
>> +
>> +#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
>> +/*
>> + * Messages on the ring are padded to 128 bits
>> + * Len here refers to the exact length of the data not including the
>> + * 128 bit header. The message uses
>> + * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
>> + */
>> +
>> +/*
>> + * v4v_stream_header
>> + * {
>> + * =A0 =A0 =A032 bits: flags
>> + * =A0 =A0 =A032 bits: conid
>> + * }
>> + */
>> +
>> +/*
>> + * v4v_ring_message_header
>> + * {
>> + * =A0 =A0 =A032 bits: len
>> + * =A0 =A0 =A0v4v_addr: source
>> + * =A0 =A0 =A032 bits: protocol
>> + * =A0 =A0 =A0... : data
>> + * }
>> + */
>> +
>> +/*
>> + * HYPERCALLS
>> + */
>> +
>> +#define V4VOP_register_ring =A01
>> +/*
>> + * Registers a ring with Xen, if a ring with the same v4v_ring_id exist=
s,
>> + * this ring takes its place, registration will not change tx_ptr
>> + * unless it is invalid
>> + *
>> + * do_v4v_op(V4VOP_unregister_ring,
>> + * =A0 =A0 =A0 =A0 =A0 v4v_ring, XEN_GUEST_HANDLE(v4v_pfn),
>> + * =A0 =A0 =A0 =A0 =A0 NULL, npage, 0)
>> + */
>> +
>> +
>> +#define V4VOP_unregister_ring =A0 =A0 =A0 =A02
>> +/*
>> + * Unregister a ring.
>> + *
>> + * v4v_hypercall(V4VOP_send, v4v_ring, NULL, NULL, 0, 0)
>
> Assuming this and the earlier do_v4v_op() refer to the same
> thing, please use a single name consistently.
>

Ack.

>> + */
>> +
>> +#define V4VOP_send =A0 =A0 =A0 =A0 =A0 3
>> +/*
>> + * Sends len bytes of buf to dst, giving src as the source address (xen=
 will
>> + * ignore src->domain and put your domain in the actually message), xen
>> + * first looks for a ring with id.addr=3D=3Ddst and id.partner=3D=3Dsen=
ding_domain
>> + * if that fails it looks for id.addr=3D=3Ddst and id.partner=3D=3DDOMI=
D_ANY.
>> + * protocol is the 32 bit protocol number used from the message
>> + * most likely V4V_PROTO_DGRAM or STREAM. If insufficient space exists
>> + * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
>> + * sufficient space becomes available
>> + *
>> + * v4v_hypercall(V4VOP_send,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr src,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr dst,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 void* buf,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t len,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t protocol)
>> + */
>> +
>> +
>> +#define V4VOP_notify =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4
>> +/* Asks xen for information about other rings in the system
>> + *
>> + * ent->ring is the v4v_addr_t of the ring you want information on
>> + * the same matching rules are used as for V4VOP_send.
>> + *
>> + * ent->space_required =A0if this field is not null xen will check
>> + * that there is space in the destination ring for this many bytes
>> + * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
>> + * and CANCEL any pending interrupt for that ent->ring, if insufficient
>> + * space is available it will schedule an interrupt and the flag will
>> + * not be set.
>> + *
>> + * The flags are set by xen when notify replies
>> + * V4V_RING_DATA_F_EMPTY =A0 =A0 ring is empty
>> + * V4V_RING_DATA_F_PENDING =A0 interrupt is pending - don't rely on this
>> + * V4V_RING_DATA_F_SUFFICIENT =A0 =A0 =A0 =A0sufficient space for space=
_required is there
>> + * V4V_RING_DATA_F_EXISTS =A0 =A0ring exists
>> + *
>> + * v4v_hypercall(V4VOP_notify,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL, NULL, nent, 0)
>> + */
>> +
>> +
>> +#define V4VOP_sendv =A0 =A0 =A0 =A0 =A05
>> +/*
>> + * Identical to V4VOP_send except rather than buf and len it takes
>> + * an array of v4v_iov and a length of the array.
>> + *
>> + * v4v_hypercall(V4VOP_sendv,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr src,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_addr dst,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 v4v_iov iov,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t niov,
>> + * =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t protocol)
>> + */
>> +
>> +#endif /* __XEN_PUBLIC_V4V_H__ */
>> --- /dev/null
>> +++ b/xen/include/xen/v4v.h
>> @@ -0,0 +1,187 @@
>> +/**********************************************************************=
********
>> + * V4V
>> + *
>> + * Version 2 of v2v (Virtual-to-Virtual)
>> + *
>> + * Copyright (c) 2010, Citrix Systems
>> + *
>> + * 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. =A0See 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 =A002111-13=
07 =A0USA
>> + */
>> +
>> +#ifndef __V4V_PRIVATE_H__
>> +#define __V4V_PRIVATE_H__
>> +
>> +#include <xen/config.h>
>> +#include <xen/types.h>
>> +#include <xen/spinlock.h>
>> +#include <xen/smp.h>
>> +#include <xen/shared.h>
>> +#include <xen/list.h>
>> +#include <public/v4v.h>
>> +
>> +#define V4V_HTABLE_SIZE 32
>> +
>> +#define V4V_PACKED __attribute__ ((packed))
>> +
>> +/*
>> + * Structures
>> + */
>> +
>> +typedef struct v4v_iov
>> +{
>> + =A0 =A0uint64_t iov_base;
>> + =A0 =A0uint64_t iov_len;
>> +} V4V_PACKED v4v_iov_t;
>
> While you moved this to a private header now, I continue to
> think that none of the uses of V4V_PACKED are actually
> warranted (and hence these can't serve as reason for moving
> these public definitions into a private header). Use explicit
> padding fields, and you ought to be fine.
>

Answer bellow.

>> +DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
>> +
>> +typedef struct v4v_addr
>> +{
>> + =A0 =A0uint32_t port;
>> + =A0 =A0domid_t domain;
>> +} V4V_PACKED v4v_addr_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
>> +
>> +typedef struct v4v_ring_id
>> +{
>> + =A0 =A0struct v4v_addr addr;
>> + =A0 =A0domid_t partner;
>> +} V4V_PACKED v4v_ring_id_t;
>> +

This structure is really the one that cause trouble. domid_t is 16b
and v4v_addr_t is used
inside v4v_ring_t. I would like the structure to remind as close as we
can from the original version
as we already versions in the field. Having explicit padding will make
all the structures different
which will make much harder to write a driver that will support the
two versions of the API.

Also most all the consumer of those headers will have to rewrite the
structure anyway, for instance
the Linux kernel have it's own naming convention, macros definitions
which are different, etc..

>> +typedef uint64_t v4v_pfn_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
>> +
>> +typedef struct v4v_ring
>> +{
>> + =A0 =A0uint64_t magic;
>> + =A0 =A0struct v4v_ring_id id;
>> + =A0 =A0uint32_t len;
>> + =A0 =A0uint32_t rx_ptr;
>> + =A0 =A0uint32_t tx_ptr;
>> + =A0 =A0uint64_t reserved[4];
>> + =A0 =A0uint8_t ring[0];
>> +} V4V_PACKED v4v_ring_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
>
> If moved into the public header (where they belong imo), apart
> from this one none of the guest handle defines should actually be
> there, as there's no guest interface that would make use of them
> (they're used internally to v4v.c only).
>
> Also, conventionally there's no space before the opening
> parenthesis here.
>
> Jan
>
>> +
>> +typedef struct v4v_ring_data_ent
>> +{
>> + =A0 =A0struct v4v_addr ring;
>> + =A0 =A0uint16_t flags;
>> + =A0 =A0uint16_t pad0;
>> + =A0 =A0uint32_t space_required;
>> + =A0 =A0uint32_t max_message_size;
>> +} V4V_PACKED v4v_ring_data_ent_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
>> +
>> +typedef struct v4v_ring_data
>> +{
>> + =A0 =A0uint64_t magic;
>> + =A0 =A0uint32_t nent;
>> + =A0 =A0uint32_t padding;
>> + =A0 =A0uint64_t reserved[4];
>> + =A0 =A0v4v_ring_data_ent_t ring[0];
>> +} V4V_PACKED v4v_ring_data_t;
>> +DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
>> +
>> +struct v4v_stream_header
>> +{
>> + =A0 =A0uint32_t flags;
>> + =A0 =A0uint32_t conid;
>> +} V4V_PACKED;
>> +
>> +struct v4v_ring_message_header
>> +{
>> + =A0 =A0uint32_t len;
>> + =A0 =A0struct v4v_addr source;
>> + =A0 =A0uint32_t protocol;
>> + =A0 =A0uint8_t data[0];
>> +} V4V_PACKED;
>> +
>> +/*
>> + * Helper functions
>> + */
>> +
>> +
>> +static inline uint16_t
>> +v4v_hash_fn (struct v4v_ring_id *id)
>> +{
>> + =A0uint16_t ret;
>> + =A0ret =3D (uint16_t) (id->addr.port >> 16);
>> + =A0ret ^=3D (uint16_t) id->addr.port;
>> + =A0ret ^=3D id->addr.domain;
>> + =A0ret ^=3D id->partner;
>> +
>> + =A0ret &=3D (V4V_HTABLE_SIZE-1);
>> +
>> + =A0return ret;
>> +}
>> +
>> +struct v4v_pending_ent
>> +{
>> + =A0struct hlist_node node;
>> + =A0domid_t id;
>> + =A0uint32_t len;
>> +} V4V_PACKED;
>> +
>> +
>> +struct v4v_ring_info
>> +{
>> + =A0/* next node in the hash, protected by L2 =A0*/
>> + =A0struct hlist_node node;
>> + =A0/* this ring's id, protected by L2 */
>> + =A0struct v4v_ring_id id;
>> + =A0/* L3 */
>> + =A0spinlock_t lock;
>> + =A0/* cached length of the ring (from ring->len), protected by L3 */
>> + =A0uint32_t len;
>> + =A0uint32_t npage;
>> + =A0/* cached tx pointer location, protected by L3 */
>> + =A0uint32_t tx_ptr;
>> + =A0/* guest ring, protected by L3 */
>> + =A0XEN_GUEST_HANDLE(v4v_ring_t) ring;
>> + =A0/* mapped ring pages protected by L3*/
>> + =A0uint8_t **mfn_mapping;
>> + =A0/* list of mfns of guest ring */
>> + =A0mfn_t *mfns;
>> + =A0/* list of struct v4v_pending_ent for this ring, L3 */
>> + =A0struct hlist_head pending;
>> +} V4V_PACKED;
>> +
>> +/*
>> + * The value of the v4v element in a struct domain is
>> + * protected by the global lock L1
>> + */
>> +struct v4v_domain
>> +{
>> + =A0/* L2 */
>> + =A0rwlock_t lock;
>> + =A0/* protected by L2 */
>> + =A0struct hlist_head ring_hash[V4V_HTABLE_SIZE];
>> +} V4V_PACKED;
>> +
>> +void v4v_destroy(struct domain *d);
>> +int v4v_init(struct domain *d);
>> +long do_v4v_op (int cmd,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XEN_GUEST_HANDLE (void) arg1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XEN_GUEST_HANDLE (void) arg2,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XEN_GUEST_HANDLE (void) arg3,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t arg4,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t arg5);
>> +
>> +#endif /* __V4V_PRIVATE_H__ */
>

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkY9K-0003Fi-HZ; Fri, 29 Jun 2012 10:10:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkY9J-0003FZ-4Z
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:10:01 +0000
Received: from [85.158.143.99:29950] by server-2.bemta-4.messagelabs.com id
	33/7A-17938-8FE7DEF4; Fri, 29 Jun 2012 10:10:00 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340964599!29428140!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4830 invoked from network); 29 Jun 2012 10:10:00 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:10:00 -0000
Received: by vcbfo13 with SMTP id fo13so2685847vcb.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=aR0vLLQAaT3kX3GJQZkZupsuPTmOEeCrTmUbxmXTAxI=;
	b=T3HuMAkpjze1pmcXl6xl7k5qHZxtcwc2Q1+WGdqEs/RjSPdTG3vnKrN9tYy9EZEsOg
	L9cM0fGYqYzhqhjSoF3qHPPmxNJ1MJ+JD0g1sXkXc7ONnvbPhUkHsdUW6waoNUnuMynt
	LFvicE4S0HnAvzlTLAK5ceOXkVURkFaT1SWliX/4ihO1OLIzlAjjrEaWeKCsQcKb8fFx
	x6X++IEl/fIdXGHUoBeBC7HkKRSBYFIwotbXsokToxibCQG1rwDJGlp58jy8WiuVORb2
	DKESwrpFbsvPg5veEVff9LklZcq5FrubQvAbJC9OPyz+z6yV2OMqtDk2vqe8S1NjdarA
	fTkQ==
Received: by 10.220.153.75 with SMTP id j11mr601652vcw.32.1340964598766; Fri,
	29 Jun 2012 03:09:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Fri, 29 Jun 2012 03:09:38 -0700 (PDT)
In-Reply-To: <4FED7DF4020000780008CC11@nat28.tlf.novell.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
	<4FED7DF4020000780008CC11@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Fri, 29 Jun 2012 11:09:38 +0100
Message-ID: <CAEBdQ90WFT2sLaKPr6y7GcWJ+GWFm4yUdPgU6g7oz57admhNew@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: add ssize_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 June 2012 09:05, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>
> If this is really needed (which I doubt, looking at the two users
> and their - respectively - sole callers), then for x86 please put
> the definitions alongside the size_t ones.
>
> Until the need for the type is shown, this is a NAK from me.
>

The ssize_t can't be replaced with a size_t because the functions that use it
can return negative number and size_t is unsigned.

ssize_t could be replaced by a long long which will work for all the
case 32 and 64b.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkY9K-0003Fi-HZ; Fri, 29 Jun 2012 10:10:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkY9J-0003FZ-4Z
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:10:01 +0000
Received: from [85.158.143.99:29950] by server-2.bemta-4.messagelabs.com id
	33/7A-17938-8FE7DEF4; Fri, 29 Jun 2012 10:10:00 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340964599!29428140!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4830 invoked from network); 29 Jun 2012 10:10:00 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:10:00 -0000
Received: by vcbfo13 with SMTP id fo13so2685847vcb.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=aR0vLLQAaT3kX3GJQZkZupsuPTmOEeCrTmUbxmXTAxI=;
	b=T3HuMAkpjze1pmcXl6xl7k5qHZxtcwc2Q1+WGdqEs/RjSPdTG3vnKrN9tYy9EZEsOg
	L9cM0fGYqYzhqhjSoF3qHPPmxNJ1MJ+JD0g1sXkXc7ONnvbPhUkHsdUW6waoNUnuMynt
	LFvicE4S0HnAvzlTLAK5ceOXkVURkFaT1SWliX/4ihO1OLIzlAjjrEaWeKCsQcKb8fFx
	x6X++IEl/fIdXGHUoBeBC7HkKRSBYFIwotbXsokToxibCQG1rwDJGlp58jy8WiuVORb2
	DKESwrpFbsvPg5veEVff9LklZcq5FrubQvAbJC9OPyz+z6yV2OMqtDk2vqe8S1NjdarA
	fTkQ==
Received: by 10.220.153.75 with SMTP id j11mr601652vcw.32.1340964598766; Fri,
	29 Jun 2012 03:09:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Fri, 29 Jun 2012 03:09:38 -0700 (PDT)
In-Reply-To: <4FED7DF4020000780008CC11@nat28.tlf.novell.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
	<4FED7DF4020000780008CC11@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Fri, 29 Jun 2012 11:09:38 +0100
Message-ID: <CAEBdQ90WFT2sLaKPr6y7GcWJ+GWFm4yUdPgU6g7oz57admhNew@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: add ssize_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 June 2012 09:05, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>
> If this is really needed (which I doubt, looking at the two users
> and their - respectively - sole callers), then for x86 please put
> the definitions alongside the size_t ones.
>
> Until the need for the type is shown, this is a NAK from me.
>

The ssize_t can't be replaced with a size_t because the functions that use it
can return negative number and size_t is unsigned.

ssize_t could be replaced by a long long which will work for all the
case 32 and 64b.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:11:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:11: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 1SkYAF-0003Iy-Vl; Fri, 29 Jun 2012 10:10:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkYAD-0003Il-PG
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:10:58 +0000
Received: from [193.109.254.147:36147] by server-11.bemta-14.messagelabs.com
	id BC/FE-24843-13F7DEF4; Fri, 29 Jun 2012 10:10:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340964656!2328008!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1412 invoked from network); 29 Jun 2012 10:10:56 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:10:56 -0000
Received: by eaak12 with SMTP id k12so1513242eaa.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:10:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GgS/lj9Rmy+4TUhEkPhkDl3mnbEikmRFDlNM2UysZGQ=;
	b=01aYuByD/xDlGx1KjdOwFP873ibAAtJ5IPSk3g1T12T+4CcKEDeNF4aqxHaYX1NO3L
	tyW1Bz0+7vjmgeOtMjoKEygeOB9wGoMKz9+YT/Xw33qYBwuOddS+jE6hGNq7RP1kFbXO
	0oJAqoB/Pi/vy3B3NxZq8v/vaKuPHCksbLEqjIOpxeblJqWmePUeHd4v8s73k/NxRQ6G
	Duh+cpzsfp0G6toezlnWJ5nRioW2U6FZA90A7N7WtS9aFoe6QxWu1427gKSPe0uwi6Da
	ND7loPrSn3aqloFHxeuOEV8F2CJYSpWi3rUoxx/I9tWOap4uXn7NoYtivAolh5hEt9m+
	Unrg==
Received: by 10.14.22.5 with SMTP id s5mr418108ees.226.1340964655994;
	Fri, 29 Jun 2012 03:10:55 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id e48sm6275323eea.12.2012.06.29.03.10.52
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 03:10:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 11:10:48 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <CC133DB8.37278%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
Thread-Index: Ac1V33Q/zwwsOzvYPU6KErVBY9UcjA==
In-Reply-To: <4FED8886020000780008CC7B@nat28.tlf.novell.com>
Mime-version: 1.0
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 V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 09:50, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 26.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
>> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE(void) arg)
>>                  iorp = &d->arch.hvm_domain.ioreq;
>>                  for_each_vcpu ( d, v )
>>                  {
>> -                    int old_port, new_port;
>> -                    new_port = alloc_unbound_xen_event_channel(
>> -                        v, a.value, NULL);
>> -                    if ( new_port < 0 )
>> -                    {
>> -                        rc = new_port;
>> +                    rc = hvm_replace_event_channel(v, a.value,
>> +               
>> &v->arch.hvm_vcpu.xen_port);
>> +                    if ( rc )
>>                          break;
>> +
>> +                    if ( v->vcpu_id == 0 )
> 
> Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
> is valid (as otherwise free_xen_event_channel() will BUG_ON() on
> it)?

No, params[HVM_PARAM_BUFIOREQ_EVTCHN] is guaranteed valid.

>> +                    {
>> +                        spin_lock(&iorp->lock);
>> +                        rc = hvm_replace_event_channel(v, a.value,
>> +               
>> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
>> +                        spin_unlock(&iorp->lock);
>> +                        if ( rc )
>> +                            break;
>>                      }
> 
> My first preference would be for this to be moved out of the
> loop. If it has to remain in the loop for some reason, then the
> next best option would be to move this into the iorp->lock
> protected region immediately below.

Agree on moving it out of the loop. But why would you want it protected by
iorp->lock?

 -- Keir

> Jan
> 
>> -                    /* xchg() ensures that only we free_xen_event_channel()
>> */
>> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
>> -                    free_xen_event_channel(v, old_port);
>> +
>>                      spin_lock(&iorp->lock);
>>                      if ( iorp->va != NULL )
>>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 29 10:11:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:11: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 1SkYAF-0003Iy-Vl; Fri, 29 Jun 2012 10:10:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkYAD-0003Il-PG
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:10:58 +0000
Received: from [193.109.254.147:36147] by server-11.bemta-14.messagelabs.com
	id BC/FE-24843-13F7DEF4; Fri, 29 Jun 2012 10:10:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340964656!2328008!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1412 invoked from network); 29 Jun 2012 10:10:56 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:10:56 -0000
Received: by eaak12 with SMTP id k12so1513242eaa.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:10:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GgS/lj9Rmy+4TUhEkPhkDl3mnbEikmRFDlNM2UysZGQ=;
	b=01aYuByD/xDlGx1KjdOwFP873ibAAtJ5IPSk3g1T12T+4CcKEDeNF4aqxHaYX1NO3L
	tyW1Bz0+7vjmgeOtMjoKEygeOB9wGoMKz9+YT/Xw33qYBwuOddS+jE6hGNq7RP1kFbXO
	0oJAqoB/Pi/vy3B3NxZq8v/vaKuPHCksbLEqjIOpxeblJqWmePUeHd4v8s73k/NxRQ6G
	Duh+cpzsfp0G6toezlnWJ5nRioW2U6FZA90A7N7WtS9aFoe6QxWu1427gKSPe0uwi6Da
	ND7loPrSn3aqloFHxeuOEV8F2CJYSpWi3rUoxx/I9tWOap4uXn7NoYtivAolh5hEt9m+
	Unrg==
Received: by 10.14.22.5 with SMTP id s5mr418108ees.226.1340964655994;
	Fri, 29 Jun 2012 03:10:55 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id e48sm6275323eea.12.2012.06.29.03.10.52
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 03:10:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 11:10:48 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <CC133DB8.37278%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
Thread-Index: Ac1V33Q/zwwsOzvYPU6KErVBY9UcjA==
In-Reply-To: <4FED8886020000780008CC7B@nat28.tlf.novell.com>
Mime-version: 1.0
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 V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 09:50, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 26.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
>> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE(void) arg)
>>                  iorp = &d->arch.hvm_domain.ioreq;
>>                  for_each_vcpu ( d, v )
>>                  {
>> -                    int old_port, new_port;
>> -                    new_port = alloc_unbound_xen_event_channel(
>> -                        v, a.value, NULL);
>> -                    if ( new_port < 0 )
>> -                    {
>> -                        rc = new_port;
>> +                    rc = hvm_replace_event_channel(v, a.value,
>> +               
>> &v->arch.hvm_vcpu.xen_port);
>> +                    if ( rc )
>>                          break;
>> +
>> +                    if ( v->vcpu_id == 0 )
> 
> Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
> is valid (as otherwise free_xen_event_channel() will BUG_ON() on
> it)?

No, params[HVM_PARAM_BUFIOREQ_EVTCHN] is guaranteed valid.

>> +                    {
>> +                        spin_lock(&iorp->lock);
>> +                        rc = hvm_replace_event_channel(v, a.value,
>> +               
>> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
>> +                        spin_unlock(&iorp->lock);
>> +                        if ( rc )
>> +                            break;
>>                      }
> 
> My first preference would be for this to be moved out of the
> loop. If it has to remain in the loop for some reason, then the
> next best option would be to move this into the iorp->lock
> protected region immediately below.

Agree on moving it out of the loop. But why would you want it protected by
iorp->lock?

 -- Keir

> Jan
> 
>> -                    /* xchg() ensures that only we free_xen_event_channel()
>> */
>> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
>> -                    free_xen_event_channel(v, old_port);
>> +
>>                      spin_lock(&iorp->lock);
>>                      if ( iorp->va != NULL )
>>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Jun 29 10:12:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYBh-0003Pz-Ep; Fri, 29 Jun 2012 10:12:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkYBg-0003Pp-9S
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:12:28 +0000
Received: from [193.109.254.147:5819] by server-11.bemta-14.messagelabs.com id
	CD/51-24843-B8F7DEF4; Fri, 29 Jun 2012 10:12:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340964746!4042739!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1027 invoked from network); 29 Jun 2012 10:12:26 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:12:26 -0000
Received: by eaak12 with SMTP id k12so1513915eaa.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cYmO6NsKCLBGtRRxwJBNrm+25/rqaq6GDcJtONWFmv8=;
	b=MjuUQ7IFAHGeCG6MwV1qZGhQzaKyCIjjRwoBkAHDDCFIQA7FnxRMDM58spAvqcAeMo
	qhsQdtAEmorUJy2hcg4g8lKPU5j8SUUmiyJdvBrhIs+zHuDjUMyu9p8OpNxqX0gwJ4jr
	bO0wbdqOQN/OTrgK0oN9DKpZzS/15EcT+yyEIBAbtGZLba4hP6IFQOGtJhdrqYlA89NK
	ceYkFURjBtmY/XoiB8zSXDLYp12W6rhC4I5dsSvlrj/Q1eBx1SvqjdRN79g6si+k+awi
	kT6ahDCgPFzNHlp79sz3TU1rqggxR5rdVRrvZmUvvCZPZ+ZytvGVcgdSFnV1UoPuDUwT
	yGhg==
Received: by 10.14.29.71 with SMTP id h47mr500632eea.129.1340964745706;
	Fri, 29 Jun 2012 03:12:25 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id m46sm6304854eeh.9.2012.06.29.03.12.24
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 03:12:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 11:12:20 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <CC133E14.37279%keir.xen@gmail.com>
Thread-Topic: [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.
Thread-Index: Ac1V36sV9bT+SzKRO0S+SVlwsjetEA==
In-Reply-To: <1340958413.10942.81.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 09:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> +static int hvm_replace_event_channel(struct vcpu *v, uint64_t remote_domid,
>> +                                     int *port)

int *p_port?...

>> +{
>> +    int old_port, new_port;
>> +
>> +    new_port = alloc_unbound_xen_event_channel(v, remote_domid, NULL);
>> +    if ( new_port < 0 )
>> +        return new_port;
>> +
>> +    /* xchg() ensures that only we free_xen_event_channel() */
>> +    old_port = xchg(port, new_port);

...Would make this line a little bit clearer imo.

>> +    free_xen_event_channel(v, old_port);
>> +    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 Jun 29 10:12:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYBh-0003Pz-Ep; Fri, 29 Jun 2012 10:12:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkYBg-0003Pp-9S
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:12:28 +0000
Received: from [193.109.254.147:5819] by server-11.bemta-14.messagelabs.com id
	CD/51-24843-B8F7DEF4; Fri, 29 Jun 2012 10:12:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1340964746!4042739!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1027 invoked from network); 29 Jun 2012 10:12:26 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:12:26 -0000
Received: by eaak12 with SMTP id k12so1513915eaa.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cYmO6NsKCLBGtRRxwJBNrm+25/rqaq6GDcJtONWFmv8=;
	b=MjuUQ7IFAHGeCG6MwV1qZGhQzaKyCIjjRwoBkAHDDCFIQA7FnxRMDM58spAvqcAeMo
	qhsQdtAEmorUJy2hcg4g8lKPU5j8SUUmiyJdvBrhIs+zHuDjUMyu9p8OpNxqX0gwJ4jr
	bO0wbdqOQN/OTrgK0oN9DKpZzS/15EcT+yyEIBAbtGZLba4hP6IFQOGtJhdrqYlA89NK
	ceYkFURjBtmY/XoiB8zSXDLYp12W6rhC4I5dsSvlrj/Q1eBx1SvqjdRN79g6si+k+awi
	kT6ahDCgPFzNHlp79sz3TU1rqggxR5rdVRrvZmUvvCZPZ+ZytvGVcgdSFnV1UoPuDUwT
	yGhg==
Received: by 10.14.29.71 with SMTP id h47mr500632eea.129.1340964745706;
	Fri, 29 Jun 2012 03:12:25 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id m46sm6304854eeh.9.2012.06.29.03.12.24
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 03:12:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 11:12:20 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <CC133E14.37279%keir.xen@gmail.com>
Thread-Topic: [PATCH V2] xen: Fix BUFIOREQ evtchn init for a stubdom.
Thread-Index: Ac1V36sV9bT+SzKRO0S+SVlwsjetEA==
In-Reply-To: <1340958413.10942.81.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 09:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> +static int hvm_replace_event_channel(struct vcpu *v, uint64_t remote_domid,
>> +                                     int *port)

int *p_port?...

>> +{
>> +    int old_port, new_port;
>> +
>> +    new_port = alloc_unbound_xen_event_channel(v, remote_domid, NULL);
>> +    if ( new_port < 0 )
>> +        return new_port;
>> +
>> +    /* xchg() ensures that only we free_xen_event_channel() */
>> +    old_port = xchg(port, new_port);

...Would make this line a little bit clearer imo.

>> +    free_xen_event_channel(v, old_port);
>> +    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 Jun 29 10:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYDd-0003bh-8b; Fri, 29 Jun 2012 10:14: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 1SkYDb-0003bS-Ab
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:14:27 +0000
Received: from [85.158.138.51:9237] by server-9.bemta-3.messagelabs.com id
	F4/0F-10419-2008DEF4; Fri, 29 Jun 2012 10:14:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340964865!21032940!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11840 invoked from network); 29 Jun 2012 10:14:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:14:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:14:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 11:14:25 +0100
Message-ID: <1340964863.10942.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 29 Jun 2012 11:14:23 +0100
In-Reply-To: <CC133DB8.37278%keir.xen@gmail.com>
References: <CC133DB8.37278%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 11:10 +0100, Keir Fraser wrote:
> On 29/06/2012 09:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
> >>>> On 26.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
> >> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op,
> >> XEN_GUEST_HANDLE(void) arg)
> >>                  iorp = &d->arch.hvm_domain.ioreq;
> >>                  for_each_vcpu ( d, v )
> >>                  {
> >> -                    int old_port, new_port;
> >> -                    new_port = alloc_unbound_xen_event_channel(
> >> -                        v, a.value, NULL);
> >> -                    if ( new_port < 0 )
> >> -                    {
> >> -                        rc = new_port;
> >> +                    rc = hvm_replace_event_channel(v, a.value,
> >> +               
> >> &v->arch.hvm_vcpu.xen_port);
> >> +                    if ( rc )
> >>                          break;
> >> +
> >> +                    if ( v->vcpu_id == 0 )
> > 
> > Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
> > is valid (as otherwise free_xen_event_channel() will BUG_ON() on
> > it)?
> 
> No, params[HVM_PARAM_BUFIOREQ_EVTCHN] is guaranteed valid.
> 
> >> +                    {
> >> +                        spin_lock(&iorp->lock);
> >> +                        rc = hvm_replace_event_channel(v, a.value,
> >> +               
> >> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
> >> +                        spin_unlock(&iorp->lock);
> >> +                        if ( rc )
> >> +                            break;
> >>                      }
> > 
> > My first preference would be for this to be moved out of the
> > loop. If it has to remain in the loop for some reason, then the
> > next best option would be to move this into the iorp->lock
> > protected region immediately below.
> 
> Agree on moving it out of the loop. But why would you want it protected by
> iorp->lock?

I suggested it because the user of the field locks with that lock.

I think that even with the xchg there is still scope for the old event
channel to be in use in hvm_buffered_io_send after it has been replaced.
The xchg just protects against concurrent freeing.

Ian.

> 
>  -- Keir
> 
> > Jan
> > 
> >> -                    /* xchg() ensures that only we free_xen_event_channel()
> >> */
> >> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
> >> -                    free_xen_event_channel(v, old_port);
> >> +
> >>                      spin_lock(&iorp->lock);
> >>                      if ( iorp->va != NULL )
> >>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Jun 29 10:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYDd-0003bh-8b; Fri, 29 Jun 2012 10:14: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 1SkYDb-0003bS-Ab
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:14:27 +0000
Received: from [85.158.138.51:9237] by server-9.bemta-3.messagelabs.com id
	F4/0F-10419-2008DEF4; Fri, 29 Jun 2012 10:14:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340964865!21032940!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11840 invoked from network); 29 Jun 2012 10:14:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:14:25 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:14:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 11:14:25 +0100
Message-ID: <1340964863.10942.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 29 Jun 2012 11:14:23 +0100
In-Reply-To: <CC133DB8.37278%keir.xen@gmail.com>
References: <CC133DB8.37278%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 11:10 +0100, Keir Fraser wrote:
> On 29/06/2012 09:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
> >>>> On 26.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
> >> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op,
> >> XEN_GUEST_HANDLE(void) arg)
> >>                  iorp = &d->arch.hvm_domain.ioreq;
> >>                  for_each_vcpu ( d, v )
> >>                  {
> >> -                    int old_port, new_port;
> >> -                    new_port = alloc_unbound_xen_event_channel(
> >> -                        v, a.value, NULL);
> >> -                    if ( new_port < 0 )
> >> -                    {
> >> -                        rc = new_port;
> >> +                    rc = hvm_replace_event_channel(v, a.value,
> >> +               
> >> &v->arch.hvm_vcpu.xen_port);
> >> +                    if ( rc )
> >>                          break;
> >> +
> >> +                    if ( v->vcpu_id == 0 )
> > 
> > Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
> > is valid (as otherwise free_xen_event_channel() will BUG_ON() on
> > it)?
> 
> No, params[HVM_PARAM_BUFIOREQ_EVTCHN] is guaranteed valid.
> 
> >> +                    {
> >> +                        spin_lock(&iorp->lock);
> >> +                        rc = hvm_replace_event_channel(v, a.value,
> >> +               
> >> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
> >> +                        spin_unlock(&iorp->lock);
> >> +                        if ( rc )
> >> +                            break;
> >>                      }
> > 
> > My first preference would be for this to be moved out of the
> > loop. If it has to remain in the loop for some reason, then the
> > next best option would be to move this into the iorp->lock
> > protected region immediately below.
> 
> Agree on moving it out of the loop. But why would you want it protected by
> iorp->lock?

I suggested it because the user of the field locks with that lock.

I think that even with the xchg there is still scope for the old event
channel to be in use in hvm_buffered_io_send after it has been replaced.
The xchg just protects against concurrent freeing.

Ian.

> 
>  -- Keir
> 
> > Jan
> > 
> >> -                    /* xchg() ensures that only we free_xen_event_channel()
> >> */
> >> -                    old_port = xchg(&v->arch.hvm_vcpu.xen_port, new_port);
> >> -                    free_xen_event_channel(v, old_port);
> >> +
> >>                      spin_lock(&iorp->lock);
> >>                      if ( iorp->va != NULL )
> >>                          get_ioreq(v)->vp_eport = v->arch.hvm_vcpu.xen_port;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Jun 29 10:19:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:19: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 1SkYIQ-0003qE-Vo; Fri, 29 Jun 2012 10:19:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkYIP-0003q7-Bh
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:19:25 +0000
Received: from [85.158.143.35:64252] by server-2.bemta-4.messagelabs.com id
	97/1B-17938-C218DEF4; Fri, 29 Jun 2012 10:19:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340965163!6899667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 550 invoked from network); 29 Jun 2012 10:19:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:19:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:19:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYIN-0007Ws-5x; Fri, 29 Jun 2012 10:19:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYIN-000197-3P;
	Fri, 29 Jun 2012 11:19:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.33067.85570.464176@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:19:23 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340954281.5953.10.camel@dagon.hellion.org.uk>
References: <osstest-13389-mainreport@xen.org>
	<1340954281.5953.10.camel@dagon.hellion.org.uk>
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] 13389: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13389: regressions - FAIL"):
> On Fri, 2012-06-29 at 04:39 +0100, xen.org wrote:
> >  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379
> 
>         migration target: Ready to receive domain.
>         Saving to migration stream new xl format (info 0x0/0x0/661)
>         Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/661)
>          Savefile contains xl domain config
>         WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
>         xl: libxl_xshelp.c:174: libxl__xs_transaction_start: Assertion `!*t' failed.

Oh dear, sorry.

> libxl: libxl__xs_transaction_commit should always clear the transaction.

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 Fri Jun 29 10:19:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:19: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 1SkYIQ-0003qE-Vo; Fri, 29 Jun 2012 10:19:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkYIP-0003q7-Bh
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:19:25 +0000
Received: from [85.158.143.35:64252] by server-2.bemta-4.messagelabs.com id
	97/1B-17938-C218DEF4; Fri, 29 Jun 2012 10:19:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340965163!6899667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 550 invoked from network); 29 Jun 2012 10:19:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:19:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:19:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYIN-0007Ws-5x; Fri, 29 Jun 2012 10:19:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYIN-000197-3P;
	Fri, 29 Jun 2012 11:19:23 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.33067.85570.464176@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:19:23 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340954281.5953.10.camel@dagon.hellion.org.uk>
References: <osstest-13389-mainreport@xen.org>
	<1340954281.5953.10.camel@dagon.hellion.org.uk>
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] 13389: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13389: regressions - FAIL"):
> On Fri, 2012-06-29 at 04:39 +0100, xen.org wrote:
> >  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379
> 
>         migration target: Ready to receive domain.
>         Saving to migration stream new xl format (info 0x0/0x0/661)
>         Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/661)
>          Savefile contains xl domain config
>         WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
>         xl: libxl_xshelp.c:174: libxl__xs_transaction_start: Assertion `!*t' failed.

Oh dear, sorry.

> libxl: libxl__xs_transaction_commit should always clear the transaction.

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 Fri Jun 29 10:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYKX-0003vx-GM; Fri, 29 Jun 2012 10:21:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkYKW-0003vp-Pn
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:21:36 +0000
Received: from [85.158.143.35:44344] by server-1.bemta-4.messagelabs.com id
	41/BC-24392-0B18DEF4; Fri, 29 Jun 2012 10:21:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340965294!15606991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29920 invoked from network); 29 Jun 2012 10:21:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:21:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:21:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:21:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYKT-0007XX-U9; Fri, 29 Jun 2012 10:21:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYKT-00019E-T1;
	Fri, 29 Jun 2012 11:21:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.33192.911129.681722@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:21:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340953001.5953.2.camel@dagon.hellion.org.uk>
References: <osstest-13383-mainreport@xen.org>
	<1340953001.5953.2.camel@dagon.hellion.org.uk>
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] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13383: regressions - FAIL"):
> On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:
...
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379
> 
> This run was before the migration series went in.

This is a rather worrying probably-nondeterministic failure, since the
same kind of guest is started in the same way in other
non-(non-localhost-migration) tests.  It's an ordinary Debian PV
guest.  I'll go and look at the logs and see if I see anything.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYKX-0003vx-GM; Fri, 29 Jun 2012 10:21:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkYKW-0003vp-Pn
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:21:36 +0000
Received: from [85.158.143.35:44344] by server-1.bemta-4.messagelabs.com id
	41/BC-24392-0B18DEF4; Fri, 29 Jun 2012 10:21:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1340965294!15606991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29920 invoked from network); 29 Jun 2012 10:21:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:21:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:21:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:21:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYKT-0007XX-U9; Fri, 29 Jun 2012 10:21:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYKT-00019E-T1;
	Fri, 29 Jun 2012 11:21:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.33192.911129.681722@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:21:28 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340953001.5953.2.camel@dagon.hellion.org.uk>
References: <osstest-13383-mainreport@xen.org>
	<1340953001.5953.2.camel@dagon.hellion.org.uk>
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] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13383: regressions - FAIL"):
> On Thu, 2012-06-28 at 21:49 +0100, xen.org wrote:
...
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pair         16 guest-start               fail REGR. vs. 13379
> 
> This run was before the migration series went in.

This is a rather worrying probably-nondeterministic failure, since the
same kind of guest is started in the same way in other
non-(non-localhost-migration) tests.  It's an ordinary Debian PV
guest.  I'll go and look at the logs and see if I see anything.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:25:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYNf-00045x-3q; Fri, 29 Jun 2012 10:24: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 1SkYNd-00045p-Nz
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:24:50 +0000
Received: from [85.158.138.51:51615] by server-9.bemta-3.messagelabs.com id
	E1/ED-10419-C628DEF4; Fri, 29 Jun 2012 10:24:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340965483!30233837!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27898 invoked from network); 29 Jun 2012 10:24: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 SMTP;
	29 Jun 2012 10:24:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:24:43 +0100
Message-Id: <4FED9EB7020000780008CCF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:25:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <4FED8886020000780008CC7B@nat28.tlf.novell.com>
	<CC133DB8.37278%keir.xen@gmail.com>
In-Reply-To: <CC133DB8.37278%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
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] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:10, Keir Fraser <keir.xen@gmail.com> wrote:
> On 29/06/2012 09:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 26.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
>>> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op,
>>> XEN_GUEST_HANDLE(void) arg)
>>>                  iorp = &d->arch.hvm_domain.ioreq;
>>>                  for_each_vcpu ( d, v )
>>>                  {
>>> -                    int old_port, new_port;
>>> -                    new_port = alloc_unbound_xen_event_channel(
>>> -                        v, a.value, NULL);
>>> -                    if ( new_port < 0 )
>>> -                    {
>>> -                        rc = new_port;
>>> +                    rc = hvm_replace_event_channel(v, a.value,
>>> +               
>>> &v->arch.hvm_vcpu.xen_port);
>>> +                    if ( rc )
>>>                          break;
>>> +
>>> +                    if ( v->vcpu_id == 0 )
>> 
>> Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
>> is valid (as otherwise free_xen_event_channel() will BUG_ON() on
>> it)?
> 
> No, params[HVM_PARAM_BUFIOREQ_EVTCHN] is guaranteed valid.

Oh, I see, this is being set by hvm_vcpu_initialize(), and read-only
to any external entity.

>>> +                    {
>>> +                        spin_lock(&iorp->lock);
>>> +                        rc = hvm_replace_event_channel(v, a.value,
>>> +               
>>> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
>>> +                        spin_unlock(&iorp->lock);
>>> +                        if ( rc )
>>> +                            break;
>>>                      }
>> 
>> My first preference would be for this to be moved out of the
>> loop. If it has to remain in the loop for some reason, then the
>> next best option would be to move this into the iorp->lock
>> protected region immediately below.
> 
> Agree on moving it out of the loop. But why would you want it protected by
> iorp->lock?

That's a question to Anthony - I just saw that the same lock is
being used here and a few lines down.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:25:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYNf-00045x-3q; Fri, 29 Jun 2012 10:24: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 1SkYNd-00045p-Nz
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:24:50 +0000
Received: from [85.158.138.51:51615] by server-9.bemta-3.messagelabs.com id
	E1/ED-10419-C628DEF4; Fri, 29 Jun 2012 10:24:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340965483!30233837!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27898 invoked from network); 29 Jun 2012 10:24: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 SMTP;
	29 Jun 2012 10:24:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:24:43 +0100
Message-Id: <4FED9EB7020000780008CCF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:25:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <4FED8886020000780008CC7B@nat28.tlf.novell.com>
	<CC133DB8.37278%keir.xen@gmail.com>
In-Reply-To: <CC133DB8.37278%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
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] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:10, Keir Fraser <keir.xen@gmail.com> wrote:
> On 29/06/2012 09:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 26.06.12 at 17:21, Anthony PERARD <anthony.perard@citrix.com> wrote:
>>> @@ -3777,17 +3792,21 @@ long do_hvm_op(unsigned long op,
>>> XEN_GUEST_HANDLE(void) arg)
>>>                  iorp = &d->arch.hvm_domain.ioreq;
>>>                  for_each_vcpu ( d, v )
>>>                  {
>>> -                    int old_port, new_port;
>>> -                    new_port = alloc_unbound_xen_event_channel(
>>> -                        v, a.value, NULL);
>>> -                    if ( new_port < 0 )
>>> -                    {
>>> -                        rc = new_port;
>>> +                    rc = hvm_replace_event_channel(v, a.value,
>>> +               
>>> &v->arch.hvm_vcpu.xen_port);
>>> +                    if ( rc )
>>>                          break;
>>> +
>>> +                    if ( v->vcpu_id == 0 )
>> 
>> Don't you also have to check params[HVM_PARAM_BUFIOREQ_EVTCHN]
>> is valid (as otherwise free_xen_event_channel() will BUG_ON() on
>> it)?
> 
> No, params[HVM_PARAM_BUFIOREQ_EVTCHN] is guaranteed valid.

Oh, I see, this is being set by hvm_vcpu_initialize(), and read-only
to any external entity.

>>> +                    {
>>> +                        spin_lock(&iorp->lock);
>>> +                        rc = hvm_replace_event_channel(v, a.value,
>>> +               
>>> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
>>> +                        spin_unlock(&iorp->lock);
>>> +                        if ( rc )
>>> +                            break;
>>>                      }
>> 
>> My first preference would be for this to be moved out of the
>> loop. If it has to remain in the loop for some reason, then the
>> next best option would be to move this into the iorp->lock
>> protected region immediately below.
> 
> Agree on moving it out of the loop. But why would you want it protected by
> iorp->lock?

That's a question to Anthony - I just saw that the same lock is
being used here and a few lines down.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:26:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYPB-0004Cd-Js; Fri, 29 Jun 2012 10:26:25 +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 1SkYP9-0004CW-Ph
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:26:24 +0000
Received: from [85.158.138.51:9616] by server-5.bemta-3.messagelabs.com id
	C9/40-01572-FC28DEF4; Fri, 29 Jun 2012 10:26:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340965581!30234249!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2695 invoked from network); 29 Jun 2012 10:26:22 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:26:22 -0000
Received: by qcab12 with SMTP id b12so815748qca.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=yWh7l4y4gFuUr7SZKfg+MS5ChePB7RLgZTTipGiZpo4=;
	b=PBhN3+d29WQH8dgQQlMeWxwScsI4tfCPMsnpxrGeW/SRsNbwCsH3IsklJvFPi+GFEm
	FCNPRWjqNJDP2IstRgjVEyp59neCkXS5Wt+hOTHifAEYJ1xrhaVh8um+Q7nHDAVMf560
	i9zzWWltwKUe2jOo2UmoRcr+wsXkHCTR6ryipkcUwCenkkEKsz4P8dZKaJe3hHBmFlkY
	n6Kr4D4sNoBDx/FBQ/2WF9wlBa478tL6vzXTW+SgTDW6fx6S+d2felc97QcAieeAyo2P
	dLZPcKevyKacrMkuoaD1hgy9AKzWkTK0N+tWeoIigVpOsQhw3Y5tMwiMYrDfITNNxo9X
	s5XQ==
MIME-Version: 1.0
Received: by 10.229.136.142 with SMTP id r14mr395158qct.70.1340965580620; Fri,
	29 Jun 2012 03:26:20 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 29 Jun 2012 03:26:20 -0700 (PDT)
In-Reply-To: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
Date: Fri, 29 Jun 2012 11:26:20 +0100
X-Google-Sender-Auth: JESiBHwpMtiQMq_1XxlN0a_T54k
Message-ID: <CAFLBxZbck55xeN065UHbBbMyOoMiqMirSiVDctYr71UxwSMSkQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
> As to downstreams, I think only direct ones should be involved in
> any decision making processes. Indirect ones might be allowed on
> the list, but exclusively as observers. Mis-use of the observer role
> (e.g. as in influencing those participating in decision making in
> undue ways), should it become known, should result in removal of
> list membership.

Do we have an outline of who should decide that someone has mis-used
their role, what kind of appeal process there is (if any), and when
and under what conditions a person or organization can be reinstated
to the list?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:26:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYPB-0004Cd-Js; Fri, 29 Jun 2012 10:26:25 +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 1SkYP9-0004CW-Ph
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:26:24 +0000
Received: from [85.158.138.51:9616] by server-5.bemta-3.messagelabs.com id
	C9/40-01572-FC28DEF4; Fri, 29 Jun 2012 10:26:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1340965581!30234249!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2695 invoked from network); 29 Jun 2012 10:26:22 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:26:22 -0000
Received: by qcab12 with SMTP id b12so815748qca.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=yWh7l4y4gFuUr7SZKfg+MS5ChePB7RLgZTTipGiZpo4=;
	b=PBhN3+d29WQH8dgQQlMeWxwScsI4tfCPMsnpxrGeW/SRsNbwCsH3IsklJvFPi+GFEm
	FCNPRWjqNJDP2IstRgjVEyp59neCkXS5Wt+hOTHifAEYJ1xrhaVh8um+Q7nHDAVMf560
	i9zzWWltwKUe2jOo2UmoRcr+wsXkHCTR6ryipkcUwCenkkEKsz4P8dZKaJe3hHBmFlkY
	n6Kr4D4sNoBDx/FBQ/2WF9wlBa478tL6vzXTW+SgTDW6fx6S+d2felc97QcAieeAyo2P
	dLZPcKevyKacrMkuoaD1hgy9AKzWkTK0N+tWeoIigVpOsQhw3Y5tMwiMYrDfITNNxo9X
	s5XQ==
MIME-Version: 1.0
Received: by 10.229.136.142 with SMTP id r14mr395158qct.70.1340965580620; Fri,
	29 Jun 2012 03:26:20 -0700 (PDT)
Received: by 10.229.42.11 with HTTP; Fri, 29 Jun 2012 03:26:20 -0700 (PDT)
In-Reply-To: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
Date: Fri, 29 Jun 2012 11:26:20 +0100
X-Google-Sender-Auth: JESiBHwpMtiQMq_1XxlN0a_T54k
Message-ID: <CAFLBxZbck55xeN065UHbBbMyOoMiqMirSiVDctYr71UxwSMSkQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
> As to downstreams, I think only direct ones should be involved in
> any decision making processes. Indirect ones might be allowed on
> the list, but exclusively as observers. Mis-use of the observer role
> (e.g. as in influencing those participating in decision making in
> undue ways), should it become known, should result in removal of
> list membership.

Do we have an outline of who should decide that someone has mis-used
their role, what kind of appeal process there is (if any), and when
and under what conditions a person or organization can be reinstated
to the list?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:28:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkYQd-0004J1-39; Fri, 29 Jun 2012 10:27: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 1SkYQc-0004Iv-8C
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:27:54 +0000
Received: from [85.158.138.51:33727] by server-7.bemta-3.messagelabs.com id
	F1/80-10113-9238DEF4; Fri, 29 Jun 2012 10:27:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340965670!30150379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19806 invoked from network); 29 Jun 2012 10:27:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:27:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:27:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYQX-0007aL-Vm; Fri, 29 Jun 2012 10:27:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYQX-0001A6-Uh;
	Fri, 29 Jun 2012 11:27:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.33573.935985.770675@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:27:49 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340953553.5953.5.camel@dagon.hellion.org.uk>
References: <osstest-13385-mainreport@xen.org>
	<1340953553.5953.5.camel@dagon.hellion.org.uk>
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] 13385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13385: regressions - FAIL"):
> In file included from libxl_save_helper.c:44:
> libxl.h:346:26: error: _libxl_types.h: No such file or directory

Thanks for looking into this.  I guess it WFM because I normally have
everything in ccache, and I'm just (un)lucky.

> libxl: make libxl-save-helper depend on the autogenerated code targets

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> diff -r 0455d8317631 -r c5b08c577c7f tools/libxl/Makefile
...
> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)

This part is of course the entirely correct fix; I should have done
this.

> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): libxl.h
>  $(LIBXL_OBJS): libxl_internal.h

This part is mad but currently necessary.  The root cause of the
problem is, as you guessed (pers. comm.), this:

  libxl.h: _libxl_types.h
  libxl_json.h: _libxl_types_json.h
  libxl_internal.h: _libxl_types_internal.h _paths.h
  libxl_internal_json.h: _libxl_types_internal_json.h

and this:

  AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h

Note lack of _libsl_types*.h.

I think we can wait with fixing this until post-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 Fri Jun 29 10:28:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkYQd-0004J1-39; Fri, 29 Jun 2012 10:27: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 1SkYQc-0004Iv-8C
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:27:54 +0000
Received: from [85.158.138.51:33727] by server-7.bemta-3.messagelabs.com id
	F1/80-10113-9238DEF4; Fri, 29 Jun 2012 10:27:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340965670!30150379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19806 invoked from network); 29 Jun 2012 10:27:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13287746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:27:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:27:50 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYQX-0007aL-Vm; Fri, 29 Jun 2012 10:27:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYQX-0001A6-Uh;
	Fri, 29 Jun 2012 11:27:49 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.33573.935985.770675@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:27:49 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340953553.5953.5.camel@dagon.hellion.org.uk>
References: <osstest-13385-mainreport@xen.org>
	<1340953553.5953.5.camel@dagon.hellion.org.uk>
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] 13385: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13385: regressions - FAIL"):
> In file included from libxl_save_helper.c:44:
> libxl.h:346:26: error: _libxl_types.h: No such file or directory

Thanks for looking into this.  I guess it WFM because I normally have
everything in ccache, and I'm just (un)lucky.

> libxl: make libxl-save-helper depend on the autogenerated code targets

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> diff -r 0455d8317631 -r c5b08c577c7f tools/libxl/Makefile
...
> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)

This part is of course the entirely correct fix; I should have done
this.

> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): libxl.h
>  $(LIBXL_OBJS): libxl_internal.h

This part is mad but currently necessary.  The root cause of the
problem is, as you guessed (pers. comm.), this:

  libxl.h: _libxl_types.h
  libxl_json.h: _libxl_types_json.h
  libxl_internal.h: _libxl_types_internal.h _paths.h
  libxl_internal_json.h: _libxl_types_internal_json.h

and this:

  AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h

Note lack of _libsl_types*.h.

I think we can wait with fixing this until post-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 Fri Jun 29 10:33:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:33: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 1SkYW2-0004cf-Tq; Fri, 29 Jun 2012 10:33:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkYW1-0004cW-DK
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:33:29 +0000
Received: from [85.158.143.99:19888] by server-1.bemta-4.messagelabs.com id
	5B/01-24392-8748DEF4; Fri, 29 Jun 2012 10:33:28 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340966006!26389581!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21407 invoked from network); 29 Jun 2012 10:33:28 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:33:28 -0000
Received: by vbbfn1 with SMTP id fn1so2695544vbb.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=iM8ML27qjgfhvAI1CpRN3bMnfhM6IaK1Qv/9dUxwWrY=;
	b=BDUwcD0ydnvE9wfW9InoZmUAG91tpjWsVRypGCOrM3+tLN5W6+Q9YriLnUmQJg3sWn
	XpVPahIP/pNW49uYtFU7cQ/EguGp+fqgX9kIpUJsBW5xOhze88zDLVITxDz2A/FdHxsT
	WYTAJzuU+fo13t8XDEUqOKKRkKY72wnPwbQEj7kVO0SMZvmUtc2A8Znfuf7XpPQq14RV
	GWiDOn4+XSAxFDEl89xPSrnEwlXXdQL346Ss2pNp3Rgx5ia5Q8iCQsxn8Pyk0bvoUSx0
	TDbDS7e63YSDgnP4y7cJRatWTS2Ha9SlhX0HYZcBFGHb//5xMkBfeMZAis1AGw4b1LgN
	mejw==
Received: by 10.52.98.226 with SMTP id el2mr544379vdb.119.1340966006344; Fri,
	29 Jun 2012 03:33:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Fri, 29 Jun 2012 03:33:06 -0700 (PDT)
In-Reply-To: <4FED7E77020000780008CC16@nat28.tlf.novell.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
	<4FED7E77020000780008CC16@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Fri, 29 Jun 2012 11:33:06 +0100
Message-ID: <CAEBdQ9313Hu3T9Vqvie9f8EHR08DEAGBQixEgc5AJBReQaT_YA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 June 2012 09:07, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>
> This appears to be unchanged from v1, so the inconsistency
> between implementation (per-vCPU vIRQ) and documentation
> (global vIRQ) remains.
>

Yes, I will change this once I've switched to event channel in a new version.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:33:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:33: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 1SkYW2-0004cf-Tq; Fri, 29 Jun 2012 10:33:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkYW1-0004cW-DK
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:33:29 +0000
Received: from [85.158.143.99:19888] by server-1.bemta-4.messagelabs.com id
	5B/01-24392-8748DEF4; Fri, 29 Jun 2012 10:33:28 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340966006!26389581!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21407 invoked from network); 29 Jun 2012 10:33:28 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:33:28 -0000
Received: by vbbfn1 with SMTP id fn1so2695544vbb.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=iM8ML27qjgfhvAI1CpRN3bMnfhM6IaK1Qv/9dUxwWrY=;
	b=BDUwcD0ydnvE9wfW9InoZmUAG91tpjWsVRypGCOrM3+tLN5W6+Q9YriLnUmQJg3sWn
	XpVPahIP/pNW49uYtFU7cQ/EguGp+fqgX9kIpUJsBW5xOhze88zDLVITxDz2A/FdHxsT
	WYTAJzuU+fo13t8XDEUqOKKRkKY72wnPwbQEj7kVO0SMZvmUtc2A8Znfuf7XpPQq14RV
	GWiDOn4+XSAxFDEl89xPSrnEwlXXdQL346Ss2pNp3Rgx5ia5Q8iCQsxn8Pyk0bvoUSx0
	TDbDS7e63YSDgnP4y7cJRatWTS2Ha9SlhX0HYZcBFGHb//5xMkBfeMZAis1AGw4b1LgN
	mejw==
Received: by 10.52.98.226 with SMTP id el2mr544379vdb.119.1340966006344; Fri,
	29 Jun 2012 03:33:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Fri, 29 Jun 2012 03:33:06 -0700 (PDT)
In-Reply-To: <4FED7E77020000780008CC16@nat28.tlf.novell.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-3-git-send-email-jean.guyader@citrix.com>
	<4FED7E77020000780008CC16@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Fri, 29 Jun 2012 11:33:06 +0100
Message-ID: <CAEBdQ9313Hu3T9Vqvie9f8EHR08DEAGBQixEgc5AJBReQaT_YA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/5] v4v: Introduce VIRQ_V4V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 June 2012 09:07, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>
> This appears to be unchanged from v1, so the inconsistency
> between implementation (per-vCPU vIRQ) and documentation
> (global vIRQ) remains.
>

Yes, I will change this once I've switched to event channel in a new version.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:35:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkYXz-0004qG-EG; Fri, 29 Jun 2012 10:35: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 1SkYXy-0004qA-60
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:35:30 +0000
Received: from [193.109.254.147:42301] by server-11.bemta-14.messagelabs.com
	id 7E/C4-24843-1F48DEF4; Fri, 29 Jun 2012 10:35:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340966128!9048060!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28669 invoked from network); 29 Jun 2012 10:35: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 SMTP;
	29 Jun 2012 10:35:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:35:28 +0100
Message-Id: <4FEDA13A020000780008CD19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:36:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
	<4FED8467020000780008CC68@nat28.tlf.novell.com>
	<CAEBdQ905mtzq3SYXn1SfCYHrENS4sFKN_U6wqNJi5osro-=ZkA@mail.gmail.com>
In-Reply-To: <CAEBdQ905mtzq3SYXn1SfCYHrENS4sFKN_U6wqNJi5osro-=ZkA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:03, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 29 June 2012 09:33, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>>> +typedef struct v4v_ring_id
>>> +{
>>> +    struct v4v_addr addr;
>>> +    domid_t partner;
>>> +} V4V_PACKED v4v_ring_id_t;
>>> +
> 
> This structure is really the one that cause trouble. domid_t is 16b
> and v4v_addr_t is used
> inside v4v_ring_t. I would like the structure to remind as close as we
> can from the original version
> as we already versions in the field. Having explicit padding will make
> all the structures different
> which will make much harder to write a driver that will support the
> two versions of the API.

Oh, I see, "partner" would end up on a different offset if the
packed attribute was removed from v4v_addr_t. But that
could still be solved by making this type a union:

typedef union v4v_ring_id
{
    struct v4v_addr addr;
    struct {
        uint32_t port;
        domid_t domain;
        domid_t partner;
    } full;
} v4v_ring_id_t;

That would guarantee binary compatibility. And you could even
achieve source compatibility for gcc users by making the naming
of the second structure conditional upon __GNUC__ being
undefined (or adding a second instance of the same, just
unnamed structure within a respective #ifdef - that would make
it possible to write code that can be compiled by both gcc and
non-gcc, yet existing gcc-only code would need changing).

> Also most all the consumer of those headers will have to rewrite the
> structure anyway, for instance
> the Linux kernel have it's own naming convention, macros definitions
> which are different, etc..

Such can usually be done via scripts, so having a fully defined
public header is still worthwhile.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:35:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkYXz-0004qG-EG; Fri, 29 Jun 2012 10:35: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 1SkYXy-0004qA-60
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:35:30 +0000
Received: from [193.109.254.147:42301] by server-11.bemta-14.messagelabs.com
	id 7E/C4-24843-1F48DEF4; Fri, 29 Jun 2012 10:35:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340966128!9048060!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28669 invoked from network); 29 Jun 2012 10:35: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 SMTP;
	29 Jun 2012 10:35:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:35:28 +0100
Message-Id: <4FEDA13A020000780008CD19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:36:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-5-git-send-email-jean.guyader@citrix.com>
	<4FED8467020000780008CC68@nat28.tlf.novell.com>
	<CAEBdQ905mtzq3SYXn1SfCYHrENS4sFKN_U6wqNJi5osro-=ZkA@mail.gmail.com>
In-Reply-To: <CAEBdQ905mtzq3SYXn1SfCYHrENS4sFKN_U6wqNJi5osro-=ZkA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:03, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 29 June 2012 09:33, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>>> +typedef struct v4v_ring_id
>>> +{
>>> +    struct v4v_addr addr;
>>> +    domid_t partner;
>>> +} V4V_PACKED v4v_ring_id_t;
>>> +
> 
> This structure is really the one that cause trouble. domid_t is 16b
> and v4v_addr_t is used
> inside v4v_ring_t. I would like the structure to remind as close as we
> can from the original version
> as we already versions in the field. Having explicit padding will make
> all the structures different
> which will make much harder to write a driver that will support the
> two versions of the API.

Oh, I see, "partner" would end up on a different offset if the
packed attribute was removed from v4v_addr_t. But that
could still be solved by making this type a union:

typedef union v4v_ring_id
{
    struct v4v_addr addr;
    struct {
        uint32_t port;
        domid_t domain;
        domid_t partner;
    } full;
} v4v_ring_id_t;

That would guarantee binary compatibility. And you could even
achieve source compatibility for gcc users by making the naming
of the second structure conditional upon __GNUC__ being
undefined (or adding a second instance of the same, just
unnamed structure within a respective #ifdef - that would make
it possible to write code that can be compiled by both gcc and
non-gcc, yet existing gcc-only code would need changing).

> Also most all the consumer of those headers will have to rewrite the
> structure anyway, for instance
> the Linux kernel have it's own naming convention, macros definitions
> which are different, etc..

Such can usually be done via scripts, so having a fully defined
public header is still worthwhile.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:37:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYZm-000518-8Q; Fri, 29 Jun 2012 10:37:22 +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 1SkYZl-00050z-Ng
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:37:21 +0000
Received: from [193.109.254.147:5932] by server-4.bemta-14.messagelabs.com id
	E3/B0-02077-0658DEF4; Fri, 29 Jun 2012 10:37:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340966240!9048537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5726 invoked from network); 29 Jun 2012 10:37:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	29 Jun 2012 10:37:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:37:19 +0100
Message-Id: <4FEDA1AD020000780008CD1C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:38:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
	<4FED7DF4020000780008CC11@nat28.tlf.novell.com>
	<CAEBdQ90WFT2sLaKPr6y7GcWJ+GWFm4yUdPgU6g7oz57admhNew@mail.gmail.com>
In-Reply-To: <CAEBdQ90WFT2sLaKPr6y7GcWJ+GWFm4yUdPgU6g7oz57admhNew@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: add ssize_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:09, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 29 June 2012 09:05, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>>
>> If this is really needed (which I doubt, looking at the two users
>> and their - respectively - sole callers), then for x86 please put
>> the definitions alongside the size_t ones.
>>
>> Until the need for the type is shown, this is a NAK from me.
>>
> 
> The ssize_t can't be replaced with a size_t because the functions that use 
> it can return negative number and size_t is unsigned.

Did you really look at the users? One stores the ssize_t value
in a uint32_t (losing the signedness), and the other stores it
into an int (losing the wider size).

> ssize_t could be replaced by a long long which will work for all the
> case 32 and 64b.

A long would do as well.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:37:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYZm-000518-8Q; Fri, 29 Jun 2012 10:37:22 +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 1SkYZl-00050z-Ng
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:37:21 +0000
Received: from [193.109.254.147:5932] by server-4.bemta-14.messagelabs.com id
	E3/B0-02077-0658DEF4; Fri, 29 Jun 2012 10:37:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340966240!9048537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5726 invoked from network); 29 Jun 2012 10:37:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	29 Jun 2012 10:37:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:37:19 +0100
Message-Id: <4FEDA1AD020000780008CD1C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:38:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <1340900786-21802-1-git-send-email-jean.guyader@citrix.com>
	<1340900786-21802-2-git-send-email-jean.guyader@citrix.com>
	<4FED7DF4020000780008CC11@nat28.tlf.novell.com>
	<CAEBdQ90WFT2sLaKPr6y7GcWJ+GWFm4yUdPgU6g7oz57admhNew@mail.gmail.com>
In-Reply-To: <CAEBdQ90WFT2sLaKPr6y7GcWJ+GWFm4yUdPgU6g7oz57admhNew@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jean Guyader <jean.guyader@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] xen: add ssize_t
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:09, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 29 June 2012 09:05, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@citrix.com> wrote:
>>
>> If this is really needed (which I doubt, looking at the two users
>> and their - respectively - sole callers), then for x86 please put
>> the definitions alongside the size_t ones.
>>
>> Until the need for the type is shown, this is a NAK from me.
>>
> 
> The ssize_t can't be replaced with a size_t because the functions that use 
> it can return negative number and size_t is unsigned.

Did you really look at the users? One stores the ssize_t value
in a uint32_t (losing the signedness), and the other stores it
into an int (losing the wider size).

> ssize_t could be replaced by a long long which will work for all the
> case 32 and 64b.

A long would do as well.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkYaT-00055L-Mi; Fri, 29 Jun 2012 10:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkYaS-000557-7x
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:38:04 +0000
Received: from [85.158.143.35:13065] by server-2.bemta-4.messagelabs.com id
	2D/4B-17938-B858DEF4; Fri, 29 Jun 2012 10:38:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340966282!14072053!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23698 invoked from network); 29 Jun 2012 10:38:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:38:02 -0000
Received: by eekd41 with SMTP id d41so1500767eek.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=r4PDOGx+L/M+5S/YrhQ8jgiTCHjInxeHNDt1i4+4T6c=;
	b=GA4hBeQsx0ClDGji4p1dBbEvVrc+/dg3E+crXyK3hXxUvdnEQPuC7obROU/Ac44r6q
	SKm0v2lYzLPsJs4qZG3NHxESIAI0N4KRCvh9WiJPmKVoOl+0MnnGLNjp6w1vCtj8xk3L
	sqbpt4Iz9OkUmfYRcX6vDxKM9eT5I5BgDnBBXJLtovlp4qSZ4e3sTao1hfDDihZqm9aE
	8vfBSu07DtWnAnYjapy7pyeUcawQYTN3BARBYhiHk5m24Ly2592n6N39uWF3d/pgDHuE
	sYmoscSlSxKiZ2tdB3gRSIEZ99LsLISf6ojYPos5vwYHv/xqhxJAzdTXtSC+i8rtetVx
	PvcQ==
Received: by 10.14.99.206 with SMTP id x54mr511704eef.94.1340966282062;
	Fri, 29 Jun 2012 03:38:02 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id a16sm6570912eeg.0.2012.06.29.03.38.00
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 03:38:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 11:37:56 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC134414.3728C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
Thread-Index: Ac1V4z6c40xcIfBWJkKbT6sBl5shzg==
In-Reply-To: <1340964863.10942.89.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 11:14, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> Agree on moving it out of the loop. But why would you want it protected by
>> iorp->lock?
> 
> I suggested it because the user of the field locks with that lock.

That lock is really protecting access to the shared bufioreq page. The
evtchn notify could equally well be moved outside the lock.

> I think that even with the xchg there is still scope for the old event
> channel to be in use in hvm_buffered_io_send after it has been replaced.
> The xchg just protects against concurrent freeing.

A. This would be equally true for the per-vcpu hvm_vcpu.xen_port; but
B. We avoid such races by domain_pause()ing when changing
HVM_PARAM_DM_DOMAIN; and
C. In practice we only set HVM_PARAM_DM_DOMAIN before the guest starts to
run anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkYaT-00055L-Mi; Fri, 29 Jun 2012 10:38:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkYaS-000557-7x
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:38:04 +0000
Received: from [85.158.143.35:13065] by server-2.bemta-4.messagelabs.com id
	2D/4B-17938-B858DEF4; Fri, 29 Jun 2012 10:38:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1340966282!14072053!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23698 invoked from network); 29 Jun 2012 10:38:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:38:02 -0000
Received: by eekd41 with SMTP id d41so1500767eek.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 03:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=r4PDOGx+L/M+5S/YrhQ8jgiTCHjInxeHNDt1i4+4T6c=;
	b=GA4hBeQsx0ClDGji4p1dBbEvVrc+/dg3E+crXyK3hXxUvdnEQPuC7obROU/Ac44r6q
	SKm0v2lYzLPsJs4qZG3NHxESIAI0N4KRCvh9WiJPmKVoOl+0MnnGLNjp6w1vCtj8xk3L
	sqbpt4Iz9OkUmfYRcX6vDxKM9eT5I5BgDnBBXJLtovlp4qSZ4e3sTao1hfDDihZqm9aE
	8vfBSu07DtWnAnYjapy7pyeUcawQYTN3BARBYhiHk5m24Ly2592n6N39uWF3d/pgDHuE
	sYmoscSlSxKiZ2tdB3gRSIEZ99LsLISf6ojYPos5vwYHv/xqhxJAzdTXtSC+i8rtetVx
	PvcQ==
Received: by 10.14.99.206 with SMTP id x54mr511704eef.94.1340966282062;
	Fri, 29 Jun 2012 03:38:02 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id a16sm6570912eeg.0.2012.06.29.03.38.00
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 03:38:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 11:37:56 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC134414.3728C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
Thread-Index: Ac1V4z6c40xcIfBWJkKbT6sBl5shzg==
In-Reply-To: <1340964863.10942.89.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 11:14, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> Agree on moving it out of the loop. But why would you want it protected by
>> iorp->lock?
> 
> I suggested it because the user of the field locks with that lock.

That lock is really protecting access to the shared bufioreq page. The
evtchn notify could equally well be moved outside the lock.

> I think that even with the xchg there is still scope for the old event
> channel to be in use in hvm_buffered_io_send after it has been replaced.
> The xchg just protects against concurrent freeing.

A. This would be equally true for the per-vcpu hvm_vcpu.xen_port; but
B. We avoid such races by domain_pause()ing when changing
HVM_PARAM_DM_DOMAIN; and
C. In practice we only set HVM_PARAM_DM_DOMAIN before the guest starts to
run anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYcf-0005Il-9a; Fri, 29 Jun 2012 10: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 1SkYcd-0005IX-MR
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:40:19 +0000
Received: from [85.158.143.35:29659] by server-1.bemta-4.messagelabs.com id
	28/3C-24392-3168DEF4; Fri, 29 Jun 2012 10:40:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340966417!11649423!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27688 invoked from network); 29 Jun 2012 10:40:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 10:40:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:40:17 +0100
Message-Id: <4FEDA25F020000780008CD3F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:41:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
	<CAFLBxZbck55xeN065UHbBbMyOoMiqMirSiVDctYr71UxwSMSkQ@mail.gmail.com>
In-Reply-To: <CAFLBxZbck55xeN065UHbBbMyOoMiqMirSiVDctYr71UxwSMSkQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:26, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> As to downstreams, I think only direct ones should be involved in
>> any decision making processes. Indirect ones might be allowed on
>> the list, but exclusively as observers. Mis-use of the observer role
>> (e.g. as in influencing those participating in decision making in
>> undue ways), should it become known, should result in removal of
>> list membership.
> 
> Do we have an outline of who should decide that someone has mis-used
> their role, what kind of appeal process there is (if any), and when
> and under what conditions a person or organization can be reinstated
> to the list?

If common sense can't be applied here (and from how subsequent
discussion went I'm afraid it can't be), I don't think we can come
up with a definition that can't be put under attack by someone for
what would appear to be not completely illegitimate reasons.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYcf-0005Il-9a; Fri, 29 Jun 2012 10: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 1SkYcd-0005IX-MR
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:40:19 +0000
Received: from [85.158.143.35:29659] by server-1.bemta-4.messagelabs.com id
	28/3C-24392-3168DEF4; Fri, 29 Jun 2012 10:40:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340966417!11649423!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27688 invoked from network); 29 Jun 2012 10:40:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	29 Jun 2012 10:40:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 11:40:17 +0100
Message-Id: <4FEDA25F020000780008CD3F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 11:41:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<4FE1AAB6020000780008AC16@nat28.tlf.novell.com>
	<CAFLBxZbck55xeN065UHbBbMyOoMiqMirSiVDctYr71UxwSMSkQ@mail.gmail.com>
In-Reply-To: <CAFLBxZbck55xeN065UHbBbMyOoMiqMirSiVDctYr71UxwSMSkQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.06.12 at 12:26, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> As to downstreams, I think only direct ones should be involved in
>> any decision making processes. Indirect ones might be allowed on
>> the list, but exclusively as observers. Mis-use of the observer role
>> (e.g. as in influencing those participating in decision making in
>> undue ways), should it become known, should result in removal of
>> list membership.
> 
> Do we have an outline of who should decide that someone has mis-used
> their role, what kind of appeal process there is (if any), and when
> and under what conditions a person or organization can be reinstated
> to the list?

If common sense can't be applied here (and from how subsequent
discussion went I'm afraid it can't be), I don't think we can come
up with a definition that can't be put under attack by someone for
what would appear to be not completely illegitimate reasons.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:42:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYe7-0005Rn-Tf; Fri, 29 Jun 2012 10:41: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 1SkYe5-0005Rb-P8
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:41:50 +0000
Received: from [85.158.138.51:59683] by server-4.bemta-3.messagelabs.com id
	35/8C-17105-C668DEF4; Fri, 29 Jun 2012 10:41:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340966507!30152921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3140 invoked from network); 29 Jun 2012 10:41:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:41:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13288115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:41:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:41:47 +0100
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 1SkYe2-0007gW-TV;
	Fri, 29 Jun 2012 10:41:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkYe2-0008Ku-Sy;
	Fri, 29 Jun 2012 11:41:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13394-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 11:41:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13394 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13394/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate  fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail REGR. vs. 13376

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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-win        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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  0455d8317631
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 863 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 Jun 29 10:42:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYe7-0005Rn-Tf; Fri, 29 Jun 2012 10:41: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 1SkYe5-0005Rb-P8
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:41:50 +0000
Received: from [85.158.138.51:59683] by server-4.bemta-3.messagelabs.com id
	35/8C-17105-C668DEF4; Fri, 29 Jun 2012 10:41:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1340966507!30152921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3140 invoked from network); 29 Jun 2012 10:41:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:41:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13288115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:41:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:41:47 +0100
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 1SkYe2-0007gW-TV;
	Fri, 29 Jun 2012 10:41:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkYe2-0008Ku-Sy;
	Fri, 29 Jun 2012 11:41:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13394-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 11:41:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13394 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13394/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate  fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail REGR. vs. 13376

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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-win        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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  0455d8317631
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 863 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 Jun 29 10:45:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYhh-0005e7-Kx; Fri, 29 Jun 2012 10:45: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 1SkYhg-0005dy-2H
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:45:32 +0000
Received: from [85.158.143.35:65027] by server-1.bemta-4.messagelabs.com id
	B4/15-24392-B478DEF4; Fri, 29 Jun 2012 10:45:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340966711!14715204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1306 invoked from network); 29 Jun 2012 10:45:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:45:20 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13288199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:45:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 11:45:11 +0100
Message-ID: <1340966708.10942.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 29 Jun 2012 11:45:08 +0100
In-Reply-To: <CC134414.3728C%keir.xen@gmail.com>
References: <CC134414.3728C%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 11:37 +0100, Keir Fraser wrote:
> On 29/06/2012 11:14, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >> Agree on moving it out of the loop. But why would you want it protected by
> >> iorp->lock?
> > 
> > I suggested it because the user of the field locks with that lock.
> 
> That lock is really protecting access to the shared bufioreq page. The
> evtchn notify could equally well be moved outside the lock.

OK.

> > I think that even with the xchg there is still scope for the old event
> > channel to be in use in hvm_buffered_io_send after it has been replaced.
> > The xchg just protects against concurrent freeing.
> 
> A. This would be equally true for the per-vcpu hvm_vcpu.xen_port; but
> B. We avoid such races by domain_pause()ing when changing
> HVM_PARAM_DM_DOMAIN; and
> C. In practice we only set HVM_PARAM_DM_DOMAIN before the guest starts to
> run anyway.

I thought we locked the update of xen_port too -- but actually that's
only the update of get_ioreq(v)->vp_eport, which is locked against
iorp->va changing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:45:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYhh-0005e7-Kx; Fri, 29 Jun 2012 10:45: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 1SkYhg-0005dy-2H
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 10:45:32 +0000
Received: from [85.158.143.35:65027] by server-1.bemta-4.messagelabs.com id
	B4/15-24392-B478DEF4; Fri, 29 Jun 2012 10:45:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1340966711!14715204!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1306 invoked from network); 29 Jun 2012 10:45:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:45:20 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13288199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:45:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 11:45:11 +0100
Message-ID: <1340966708.10942.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 29 Jun 2012 11:45:08 +0100
In-Reply-To: <CC134414.3728C%keir.xen@gmail.com>
References: <CC134414.3728C%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 11:37 +0100, Keir Fraser wrote:
> On 29/06/2012 11:14, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >> Agree on moving it out of the loop. But why would you want it protected by
> >> iorp->lock?
> > 
> > I suggested it because the user of the field locks with that lock.
> 
> That lock is really protecting access to the shared bufioreq page. The
> evtchn notify could equally well be moved outside the lock.

OK.

> > I think that even with the xchg there is still scope for the old event
> > channel to be in use in hvm_buffered_io_send after it has been replaced.
> > The xchg just protects against concurrent freeing.
> 
> A. This would be equally true for the per-vcpu hvm_vcpu.xen_port; but
> B. We avoid such races by domain_pause()ing when changing
> HVM_PARAM_DM_DOMAIN; and
> C. In practice we only set HVM_PARAM_DM_DOMAIN before the guest starts to
> run anyway.

I thought we locked the update of xen_port too -- but actually that's
only the update of get_ioreq(v)->vp_eport, which is locked against
iorp->va changing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:56:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYsF-0005y1-6a; Fri, 29 Jun 2012 10:56:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkYsD-0005xw-Qe
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:56:26 +0000
Received: from [85.158.143.35:28067] by server-3.bemta-4.messagelabs.com id
	4E/1A-05808-9D98DEF4; Fri, 29 Jun 2012 10:56:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340967375!18727070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19683 invoked from network); 29 Jun 2012 10:56:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13288525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:55:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYrn-0007oB-K8; Fri, 29 Jun 2012 10:55:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYrn-0001C7-J0;
	Fri, 29 Jun 2012 11:55:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.35263.383919.120201@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:55:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340959209.10942.84.camel@zakaz.uk.xensource.com>
References: <osstest-13383-mainreport@xen.org>
	<1340953001.5953.2.camel@dagon.hellion.org.uk>
	<1340959209.10942.84.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-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13383: regressions - FAIL"):
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/dhcpleases-debian.nolease contains:
>         lease 10.80.251.54 {
>           starts 3 2012/06/27 14:10:01;
>           ends 3 2012/06/27 14:40:01;
>           tstp 3 2012/06/27 14:40:01;
>           cltt 3 2012/06/27 14:10:01;
>           binding state free;
>           hardware ethernet 00:00:1a:1b:01:a1;
>           uid "\001\000\000\032\033\001\241";
>         }
> 
> Which has a mismatched mac address? dhcpleases-debian.new seems to have
> the same.

Note "binding state free".  Ie that's an old lease.  Later we see:
          lease 10.80.251.54 {
            starts 4 2012/06/28 15:21:52;
            ends 4 2012/06/28 15:51:52;
            cltt 4 2012/06/28 15:21:52;
            binding state active;
            next binding state free;
            hardware ethernet 5a:36:0e:47:00:09;
          }

The guest console log says:
    Listening on LPF/eth0/5a:36:0e:47:00:09
    Sending on   LPF/eth0/5a:36:0e:47:00:09
    Sending on   Socket/fallback
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
    DHCPOFFER from 10.80.248.4
    DHCPREQUEST on eth0 to 255.255.255.255 port 67
    DHCPACK from 10.80.248.4
    bound to 10.80.251.54 -- renewal in 854 seconds.
    done.

So that all does seem consistent.

But even so:

    2012-06-28 15:22:06 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: ping gave (256): PING 10.80.251.54 (10.80.251.54) 56(84) bytes of data. |  | --- 10.80.251.54 ping statistics --- | 5 packets transmitted, 0 received, 100% packet loss, time XXXms |  |  (waiting) ...

The same happens at at least 15:22:34 and perhaps a few times in
between.

It would seem that either something broke in the guest or host between
the successful dhcp negotiation, or there was a transient network
problem of some kind.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 10:56:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 10: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 1SkYsF-0005y1-6a; Fri, 29 Jun 2012 10:56:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkYsD-0005xw-Qe
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 10:56:26 +0000
Received: from [85.158.143.35:28067] by server-3.bemta-4.messagelabs.com id
	4E/1A-05808-9D98DEF4; Fri, 29 Jun 2012 10:56:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1340967375!18727070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19683 invoked from network); 29 Jun 2012 10:56:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 10:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13288525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 10:55:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 11:55:59 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkYrn-0007oB-K8; Fri, 29 Jun 2012 10:55:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkYrn-0001C7-J0;
	Fri, 29 Jun 2012 11:55:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.35263.383919.120201@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 11:55:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340959209.10942.84.camel@zakaz.uk.xensource.com>
References: <osstest-13383-mainreport@xen.org>
	<1340953001.5953.2.camel@dagon.hellion.org.uk>
	<1340959209.10942.84.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-unstable test] 13383: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13383: regressions - FAIL"):
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/test-amd64-i386-pair/dhcpleases-debian.nolease contains:
>         lease 10.80.251.54 {
>           starts 3 2012/06/27 14:10:01;
>           ends 3 2012/06/27 14:40:01;
>           tstp 3 2012/06/27 14:40:01;
>           cltt 3 2012/06/27 14:10:01;
>           binding state free;
>           hardware ethernet 00:00:1a:1b:01:a1;
>           uid "\001\000\000\032\033\001\241";
>         }
> 
> Which has a mismatched mac address? dhcpleases-debian.new seems to have
> the same.

Note "binding state free".  Ie that's an old lease.  Later we see:
          lease 10.80.251.54 {
            starts 4 2012/06/28 15:21:52;
            ends 4 2012/06/28 15:51:52;
            cltt 4 2012/06/28 15:21:52;
            binding state active;
            next binding state free;
            hardware ethernet 5a:36:0e:47:00:09;
          }

The guest console log says:
    Listening on LPF/eth0/5a:36:0e:47:00:09
    Sending on   LPF/eth0/5a:36:0e:47:00:09
    Sending on   Socket/fallback
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
    DHCPOFFER from 10.80.248.4
    DHCPREQUEST on eth0 to 255.255.255.255 port 67
    DHCPACK from 10.80.248.4
    bound to 10.80.251.54 -- renewal in 854 seconds.
    done.

So that all does seem consistent.

But even so:

    2012-06-28 15:22:06 Z guest debian.guest.osstest 5a:36:0e:47:00:09 22 link/ip/tcp: ping gave (256): PING 10.80.251.54 (10.80.251.54) 56(84) bytes of data. |  | --- 10.80.251.54 ping statistics --- | 5 packets transmitted, 0 received, 100% packet loss, time XXXms |  |  (waiting) ...

The same happens at at least 15:22:34 and perhaps a few times in
between.

It would seem that either something broke in the guest or host between
the successful dhcp negotiation, or there was a transient network
problem of some kind.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:05:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkZ0W-0006Z8-QI; Fri, 29 Jun 2012 11:05:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkZ0V-0006Yu-6G
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 11:04:59 +0000
Received: from [85.158.139.83:52160] by server-5.bemta-5.messagelabs.com id
	A8/24-02722-ADB8DEF4; Fri, 29 Jun 2012 11:04:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340967897!27442041!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12240 invoked from network); 29 Jun 2012 11:04:57 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:04:57 -0000
Received: by eaak12 with SMTP id k12so1533479eaa.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 04:04:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Yz4Y2U7aBgqtO2HlBVzmiSoyggEEqB5JIUjTCba9kvs=;
	b=P2pIOGEqmIEaNKo+Yfwd0vd+SGjwItVfkqglmNQFiS65XNSnGFcATNjYiQuGiZzhC2
	YtvcU+Lf1PCCepCpJQWEqK8xZCfvHgX1dvP8802O1x/9r84GXf2I6rlam9E+lEv3ZlM2
	eCEGhRm9GI0gbaQQHWUhlQ0gsC6GsrCRYHmYGdye/gA48mDjHmcBZp2frSU5Ae0Zu2MD
	v4d21E0e39XZoedkJ6iSSmS4PNcOdCukY1kRBLs/TN30zK8OpwWTFHO6XewKbFM28QSo
	gysbD3XTjeYg+BkkLh64aWCJrGKA4u8OiJUggozV1m18dy4Z4+/44tkN6O8b+lvEp1cB
	ECBA==
Received: by 10.14.100.144 with SMTP id z16mr538662eef.50.1340967897515;
	Fri, 29 Jun 2012 04:04:57 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id q53sm6751111eef.8.2012.06.29.04.04.54
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 04:04:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 12:04:50 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <CC134A62.372A3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
Thread-Index: Ac1V5wChE88sRfV+R02nS2yTTZDEdg==
In-Reply-To: <4FED9EB7020000780008CCF5@nat28.tlf.novell.com>
Mime-version: 1.0
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] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 11:25, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> +                    {
>>>> +                        spin_lock(&iorp->lock);
>>>> +                        rc = hvm_replace_event_channel(v, a.value,
>>>> +             
>>>> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
>>>> +                        spin_unlock(&iorp->lock);
>>>> +                        if ( rc )
>>>> +                            break;
>>>>                      }
>>> 
>>> My first preference would be for this to be moved out of the
>>> loop. If it has to remain in the loop for some reason, then the
>>> next best option would be to move this into the iorp->lock
>>> protected region immediately below.
>> 
>> Agree on moving it out of the loop. But why would you want it protected by
>> iorp->lock?
> 
> That's a question to Anthony - I just saw that the same lock is
> being used here and a few lines down.

Ah, I see. It is not necessary to take the lock in the above code fragment.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:05:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkZ0W-0006Z8-QI; Fri, 29 Jun 2012 11:05:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1SkZ0V-0006Yu-6G
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 11:04:59 +0000
Received: from [85.158.139.83:52160] by server-5.bemta-5.messagelabs.com id
	A8/24-02722-ADB8DEF4; Fri, 29 Jun 2012 11:04:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340967897!27442041!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12240 invoked from network); 29 Jun 2012 11:04:57 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:04:57 -0000
Received: by eaak12 with SMTP id k12so1533479eaa.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 04:04:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Yz4Y2U7aBgqtO2HlBVzmiSoyggEEqB5JIUjTCba9kvs=;
	b=P2pIOGEqmIEaNKo+Yfwd0vd+SGjwItVfkqglmNQFiS65XNSnGFcATNjYiQuGiZzhC2
	YtvcU+Lf1PCCepCpJQWEqK8xZCfvHgX1dvP8802O1x/9r84GXf2I6rlam9E+lEv3ZlM2
	eCEGhRm9GI0gbaQQHWUhlQ0gsC6GsrCRYHmYGdye/gA48mDjHmcBZp2frSU5Ae0Zu2MD
	v4d21E0e39XZoedkJ6iSSmS4PNcOdCukY1kRBLs/TN30zK8OpwWTFHO6XewKbFM28QSo
	gysbD3XTjeYg+BkkLh64aWCJrGKA4u8OiJUggozV1m18dy4Z4+/44tkN6O8b+lvEp1cB
	ECBA==
Received: by 10.14.100.144 with SMTP id z16mr538662eef.50.1340967897515;
	Fri, 29 Jun 2012 04:04:57 -0700 (PDT)
Received: from [192.168.1.84] (host81-152-17-25.range81-152.btcentralplus.com.
	[81.152.17.25])
	by mx.google.com with ESMTPS id q53sm6751111eef.8.2012.06.29.04.04.54
	(version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 04:04:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 29 Jun 2012 12:04:50 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <CC134A62.372A3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
	stubdom.
Thread-Index: Ac1V5wChE88sRfV+R02nS2yTTZDEdg==
In-Reply-To: <4FED9EB7020000780008CCF5@nat28.tlf.novell.com>
Mime-version: 1.0
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] [PATCH V2] xen: Fix BUFIOREQ evtchn init for a
 stubdom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/06/2012 11:25, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> +                    {
>>>> +                        spin_lock(&iorp->lock);
>>>> +                        rc = hvm_replace_event_channel(v, a.value,
>>>> +             
>>>> (int*)&v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN]);
>>>> +                        spin_unlock(&iorp->lock);
>>>> +                        if ( rc )
>>>> +                            break;
>>>>                      }
>>> 
>>> My first preference would be for this to be moved out of the
>>> loop. If it has to remain in the loop for some reason, then the
>>> next best option would be to move this into the iorp->lock
>>> protected region immediately below.
>> 
>> Agree on moving it out of the loop. But why would you want it protected by
>> iorp->lock?
> 
> That's a question to Anthony - I just saw that the same lock is
> being used here and a few lines down.

Ah, I see. It is not necessary to take the lock in the above code fragment.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:11:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZ6b-0006uP-6F; Fri, 29 Jun 2012 11:11:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkZ6Z-0006uI-GR
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 11:11:15 +0000
Received: from [193.109.254.147:25686] by server-11.bemta-14.messagelabs.com
	id D2/76-24843-25D8DEF4; Fri, 29 Jun 2012 11:11:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340968273!9056307!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6380 invoked from network); 29 Jun 2012 11:11:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:11:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:10:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:10:47 +0100
Date: Fri, 29 Jun 2012 12:10:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Deep Debroy <ddebroy@gmail.com>
In-Reply-To: <CABg=H3NGemrrkKWXEfEet8hWGN5_qvm3aS33NvdKfWhzgvUUMw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206291112590.27860@kaball.uk.xensource.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
	<CABg=H3NGemrrkKWXEfEet8hWGN5_qvm3aS33NvdKfWhzgvUUMw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-372388876-1340965137=:27860"
Content-ID: <alpine.DEB.2.02.1206291119020.27860@kaball.uk.xensource.com>
Cc: Rolu <rolu@roce.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
 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

--1342847746-372388876-1340965137=:27860
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.02.1206291119021.27860@kaball.uk.xensource.com>

On Thu, 28 Jun 2012, Deep Debroy wrote:
> On Wed, Jun 27, 2012 at 4:18 PM, Deep Debroy <ddebroy@gmail.com> wrote:
> > On Mon, Jun 25, 2012 at 7:51 PM, Rolu <rolu@roce.org> wrote:
> >>
> >> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> >> > Hi, I was playing around with a MSI capable virtual device (so far
> >> > submitted as patches only) in the upstream qemu tree but having
> >> > trouble getting it to work on a Xen hvm guest. The device happens to
> >> > be a QEMU implementation of VMWare's pvscsi controller. The device
> >> > works fine in a Xen guest when I switch the device's code to force
> >> > usage of legacy interrupts with upstream QEMU. With MSI based
> >> > interrupts, the device works fine on a KVM guest but as stated before,
> >> > not on a Xen guest. After digging a bit, it appears, the reason for
> >> > the failure in Xen guests is that the MSI data register in the Xen
> >> > guest ends up with a value of 4300 where the Deliver Mode value of 3
> >> > happens to be reserved (per spec) and therefore illegal. The
> >> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> >> > illegal (per expectation) causing all commands issued by the guest OS
> >> > on the device to timeout.
> >> >
> >> > Given this above scenario, I was wondering if anyone can shed some
> >> > light on how to debug this further for Xen. Something I would
> >> > specifically like to know is where the MSI data register configuration
> >> > actually happens. Is it done by some code specific to Xen and within
> >> > the Xen codebase or it all done within QEMU?
> >> >
> >>
> >> This seems like the same issue I ran into, though in my case it is
> >> with passed through physical devices. See
> >> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
> >> the older messages in that thread for more info on what's going on. No
> >> fix yet but help debugging is very welcome.
> >
> > Thanks Rolu for pointing out the other thread - it was very useful.
> > Some of the symptoms appear to be identical in my case. However, I am
> > not using a pass-through device. Instead, in my case it's a fully
> > virtualized device pretty much identical to a raw file backed disk
> > image where the controller is pvscsi rather than lsi. Therefore I
> > guess some of the latter discussion in the other thread around
> > pass-through specific areas of code in qemu are not relevant? Please
> > correct me if I am wrong. Also note that I am using upstream qemu
> > where neither the #define for PT_PCI_MSITRANSLATE_DEFAULT nor
> > xenstore.c exsits (which is where Stefano's suggested change appeared
> > to be).
> >
> > So far, here's what I am observing in the hvm linux guest :
> >
> > On the guest side, as discussed in the other thread,
> > xen_hvm_setup_msi_irqs is invoked for the device and a value of 0x4300
> > is being by xen_msi_compose_msg that is written in the data register.
> > On the qemu (upstream) side, when the virtualized controller is trying
> > to complete a request, it's invoking the following chain of calls ->
> > stl_le_phys -> xen_apic_mem_write -> xen_hvm_inject_msi
> > On the xen side, this ends up in: hvmop_inject_msi -> hvm_inject_msi
> > -> vmsi_deliver. vmsi_deliver, as previously discussed, rejects the
> > delivery mode of 0x3.
> >
> > Is the above sequence of interactions the expected path for a HVM
> > guest trying to use a fully virtualized device/controller that uses
> > MSI in upstream qemu? If so, if a standard linux guest always
> > populates the value of 0x4300 in the MSI data register through
> > xen_hvm_setup_msi_irqs, how are MSI notifications from a device in
> > qemu supposed to work given the delivery type of 0x3 is indeed
> > reserved and bypass the the vmsi_deliver check?
> >
> I wanted to see whether the HVM guest can interact with the MSI
> virtualized controller properly without any of the Xen-specific code
> in the linux kernel kicking in (i.e. allowing the regular PCI/MSI code
> in linux to fire). So I rebuilt the kernel with CONFIG_XEN disabled
> such that pci_xen_hvm_init no longer sets x86_msi.*msi_irqs to xen
> specific routines like xen_hvm_setup_msi_irqs which is where the
> 0x4300 is getting populated. This seems to work properly. The MSI data
> register for the controller ends up getting a valid value like 0x4049,
> vmsi_deliver no longer complains, all MSI notifications are delivered
> in the expected way to the guest and the raw, file-backed disks
> attached to the controller showing up in fdisk -l.
> 
> My conclusion: the linux kernel's xen specific code, specifically
> routines like xen_hvm_setup_msi_irqs, need to be tweaked to work with
> fully virtualized qemu devices that use MSI. I will follow-up
> regarding that on LKML.

Thanks for your analysis of the problem, I think it is correct: Linux PV
on HVM is trying to setup an event channel delivery for the MSI as it
always does (therefore choosing 0x3 as delivery mode).
However emulated devices in QEMU don't support that.
To be honest emulated devices in QEMU didn't support MSIs at all until
very recently, so this is why we are seeing this issue only now.

Could you please try this Xen patch and let me know if it makes things
better?


diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index a90927a..f44f3b9 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -281,6 +281,31 @@ void hvm_inject_msi(struct domain *d, uint64_t addr, uint32_t data)
         >> MSI_DATA_TRIGGER_SHIFT;
     uint8_t vector = data & MSI_DATA_VECTOR_MASK;
 
+    if ( !vector )
+    {
+        int pirq = ((addr >> 32) & 0xffffff00) | ((addr >> 12) & 0xff);
+        if ( pirq > 0 )
+        {
+            struct pirq *info = pirq_info(d, pirq);
+
+            /* if it is the first time, allocate the pirq */
+            if (info->arch.hvm.emuirq == IRQ_UNBOUND)
+            {
+                spin_lock(&d->event_lock);
+                map_domain_emuirq_pirq(d, pirq, IRQ_MSI_EMU);
+                spin_unlock(&d->event_lock);
+            } else if (info->arch.hvm.emuirq != IRQ_MSI_EMU)
+            {
+                printk("%s: pirq %d does not correspond to an emulated MSI\n", __func__, pirq);
+                return;
+            }
+            send_guest_pirq(d, info);
+            return;
+        } else {
+            printk("%s: error getting pirq from MSI: pirq = %d\n", __func__, pirq);
+        }
+    }
+
     vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
 }
 
diff --git a/xen/include/asm-x86/irq.h b/xen/include/asm-x86/irq.h
index 40e2245..066f64d 100644
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -188,6 +188,7 @@ void cleanup_domain_irq_mapping(struct domain *);
 })
 #define IRQ_UNBOUND -1
 #define IRQ_PT -2
+#define IRQ_MSI_EMU -3
 
 bool_t cpu_has_pending_apic_eoi(void);
 
--1342847746-372388876-1340965137=:27860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-372388876-1340965137=:27860--


From xen-devel-bounces@lists.xen.org Fri Jun 29 11:11:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZ6b-0006uP-6F; Fri, 29 Jun 2012 11:11:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkZ6Z-0006uI-GR
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 11:11:15 +0000
Received: from [193.109.254.147:25686] by server-11.bemta-14.messagelabs.com
	id D2/76-24843-25D8DEF4; Fri, 29 Jun 2012 11:11:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1340968273!9056307!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6380 invoked from network); 29 Jun 2012 11:11:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:11:14 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:10:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:10:47 +0100
Date: Fri, 29 Jun 2012 12:10:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Deep Debroy <ddebroy@gmail.com>
In-Reply-To: <CABg=H3NGemrrkKWXEfEet8hWGN5_qvm3aS33NvdKfWhzgvUUMw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206291112590.27860@kaball.uk.xensource.com>
References: <CABg=H3MbiDchKBtWC8YLVMFgKn2b5aN3ZqA=fSe7Gdmr0ts3Ew@mail.gmail.com>
	<CABs9EjmBkeBTD_QMEzGT-bX6hNuW6=s_6q3iL3ukLoqN+C9+gg@mail.gmail.com>
	<CABg=H3N=PmvSqgpWZq9dGfMQsfQ_u5u+7AjLAzsGURcXuEzt+A@mail.gmail.com>
	<CABg=H3NGemrrkKWXEfEet8hWGN5_qvm3aS33NvdKfWhzgvUUMw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-372388876-1340965137=:27860"
Content-ID: <alpine.DEB.2.02.1206291119020.27860@kaball.uk.xensource.com>
Cc: Rolu <rolu@roce.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] MSI message data register configuration in Xen
 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

--1342847746-372388876-1340965137=:27860
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.02.1206291119021.27860@kaball.uk.xensource.com>

On Thu, 28 Jun 2012, Deep Debroy wrote:
> On Wed, Jun 27, 2012 at 4:18 PM, Deep Debroy <ddebroy@gmail.com> wrote:
> > On Mon, Jun 25, 2012 at 7:51 PM, Rolu <rolu@roce.org> wrote:
> >>
> >> On Tue, Jun 26, 2012 at 4:38 AM, Deep Debroy <ddebroy@gmail.com> wrote:
> >> > Hi, I was playing around with a MSI capable virtual device (so far
> >> > submitted as patches only) in the upstream qemu tree but having
> >> > trouble getting it to work on a Xen hvm guest. The device happens to
> >> > be a QEMU implementation of VMWare's pvscsi controller. The device
> >> > works fine in a Xen guest when I switch the device's code to force
> >> > usage of legacy interrupts with upstream QEMU. With MSI based
> >> > interrupts, the device works fine on a KVM guest but as stated before,
> >> > not on a Xen guest. After digging a bit, it appears, the reason for
> >> > the failure in Xen guests is that the MSI data register in the Xen
> >> > guest ends up with a value of 4300 where the Deliver Mode value of 3
> >> > happens to be reserved (per spec) and therefore illegal. The
> >> > vmsi_deliver routine in Xen rejects MSI interrupts with such data as
> >> > illegal (per expectation) causing all commands issued by the guest OS
> >> > on the device to timeout.
> >> >
> >> > Given this above scenario, I was wondering if anyone can shed some
> >> > light on how to debug this further for Xen. Something I would
> >> > specifically like to know is where the MSI data register configuration
> >> > actually happens. Is it done by some code specific to Xen and within
> >> > the Xen codebase or it all done within QEMU?
> >> >
> >>
> >> This seems like the same issue I ran into, though in my case it is
> >> with passed through physical devices. See
> >> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01423.html and
> >> the older messages in that thread for more info on what's going on. No
> >> fix yet but help debugging is very welcome.
> >
> > Thanks Rolu for pointing out the other thread - it was very useful.
> > Some of the symptoms appear to be identical in my case. However, I am
> > not using a pass-through device. Instead, in my case it's a fully
> > virtualized device pretty much identical to a raw file backed disk
> > image where the controller is pvscsi rather than lsi. Therefore I
> > guess some of the latter discussion in the other thread around
> > pass-through specific areas of code in qemu are not relevant? Please
> > correct me if I am wrong. Also note that I am using upstream qemu
> > where neither the #define for PT_PCI_MSITRANSLATE_DEFAULT nor
> > xenstore.c exsits (which is where Stefano's suggested change appeared
> > to be).
> >
> > So far, here's what I am observing in the hvm linux guest :
> >
> > On the guest side, as discussed in the other thread,
> > xen_hvm_setup_msi_irqs is invoked for the device and a value of 0x4300
> > is being by xen_msi_compose_msg that is written in the data register.
> > On the qemu (upstream) side, when the virtualized controller is trying
> > to complete a request, it's invoking the following chain of calls ->
> > stl_le_phys -> xen_apic_mem_write -> xen_hvm_inject_msi
> > On the xen side, this ends up in: hvmop_inject_msi -> hvm_inject_msi
> > -> vmsi_deliver. vmsi_deliver, as previously discussed, rejects the
> > delivery mode of 0x3.
> >
> > Is the above sequence of interactions the expected path for a HVM
> > guest trying to use a fully virtualized device/controller that uses
> > MSI in upstream qemu? If so, if a standard linux guest always
> > populates the value of 0x4300 in the MSI data register through
> > xen_hvm_setup_msi_irqs, how are MSI notifications from a device in
> > qemu supposed to work given the delivery type of 0x3 is indeed
> > reserved and bypass the the vmsi_deliver check?
> >
> I wanted to see whether the HVM guest can interact with the MSI
> virtualized controller properly without any of the Xen-specific code
> in the linux kernel kicking in (i.e. allowing the regular PCI/MSI code
> in linux to fire). So I rebuilt the kernel with CONFIG_XEN disabled
> such that pci_xen_hvm_init no longer sets x86_msi.*msi_irqs to xen
> specific routines like xen_hvm_setup_msi_irqs which is where the
> 0x4300 is getting populated. This seems to work properly. The MSI data
> register for the controller ends up getting a valid value like 0x4049,
> vmsi_deliver no longer complains, all MSI notifications are delivered
> in the expected way to the guest and the raw, file-backed disks
> attached to the controller showing up in fdisk -l.
> 
> My conclusion: the linux kernel's xen specific code, specifically
> routines like xen_hvm_setup_msi_irqs, need to be tweaked to work with
> fully virtualized qemu devices that use MSI. I will follow-up
> regarding that on LKML.

Thanks for your analysis of the problem, I think it is correct: Linux PV
on HVM is trying to setup an event channel delivery for the MSI as it
always does (therefore choosing 0x3 as delivery mode).
However emulated devices in QEMU don't support that.
To be honest emulated devices in QEMU didn't support MSIs at all until
very recently, so this is why we are seeing this issue only now.

Could you please try this Xen patch and let me know if it makes things
better?


diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index a90927a..f44f3b9 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -281,6 +281,31 @@ void hvm_inject_msi(struct domain *d, uint64_t addr, uint32_t data)
         >> MSI_DATA_TRIGGER_SHIFT;
     uint8_t vector = data & MSI_DATA_VECTOR_MASK;
 
+    if ( !vector )
+    {
+        int pirq = ((addr >> 32) & 0xffffff00) | ((addr >> 12) & 0xff);
+        if ( pirq > 0 )
+        {
+            struct pirq *info = pirq_info(d, pirq);
+
+            /* if it is the first time, allocate the pirq */
+            if (info->arch.hvm.emuirq == IRQ_UNBOUND)
+            {
+                spin_lock(&d->event_lock);
+                map_domain_emuirq_pirq(d, pirq, IRQ_MSI_EMU);
+                spin_unlock(&d->event_lock);
+            } else if (info->arch.hvm.emuirq != IRQ_MSI_EMU)
+            {
+                printk("%s: pirq %d does not correspond to an emulated MSI\n", __func__, pirq);
+                return;
+            }
+            send_guest_pirq(d, info);
+            return;
+        } else {
+            printk("%s: error getting pirq from MSI: pirq = %d\n", __func__, pirq);
+        }
+    }
+
     vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
 }
 
diff --git a/xen/include/asm-x86/irq.h b/xen/include/asm-x86/irq.h
index 40e2245..066f64d 100644
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -188,6 +188,7 @@ void cleanup_domain_irq_mapping(struct domain *);
 })
 #define IRQ_UNBOUND -1
 #define IRQ_PT -2
+#define IRQ_MSI_EMU -3
 
 bool_t cpu_has_pending_apic_eoi(void);
 
--1342847746-372388876-1340965137=:27860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-372388876-1340965137=:27860--


From xen-devel-bounces@lists.xen.org Fri Jun 29 11:11:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZ6y-0006wd-Jq; Fri, 29 Jun 2012 11:11:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkZ6x-0006wN-CY
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 11:11:39 +0000
Received: from [85.158.138.51:6139] by server-12.bemta-3.messagelabs.com id
	62/F1-30206-A6D8DEF4; Fri, 29 Jun 2012 11:11:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340968297!30197455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21107 invoked from network); 29 Jun 2012 11:11:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:11:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:11:33 +0100
Date: Fri, 29 Jun 2012 12:11:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9Ejn1Z_skEnEfj9y51=NQ5b3yipq9F5o9BeP-LnfZnuo1Lw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206291210470.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
	<alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
	<CABs9Ejn1Z_skEnEfj9y51=NQ5b3yipq9F5o9BeP-LnfZnuo1Lw@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012, Rolu wrote:
> On Thu, Jun 28, 2012 at 12:49 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 27 Jun 2012, Rolu wrote:
> >> > That's because msitranslate is still enabled somehow, that is a
> >> > toolstack bug.
> >> > While we fix that bug, could you try this QEMU patch to forcefully disable
> >> > msitranslate?
> >> >
> >>
> >> This worked!
> >>
> >> The "unsupported delivery mode" message is gone. Sound works, although
> >> there is still occasionally a very short stutter, but I expect that's
> >> a different issue. I've been testing with a KDE desktop with 3D
> >> effects (cube, expo, that sort of stuff) and performance there has
> >> gone up noticeably, from around 30-40 fps in most cases to near 60.
> >
> > Great, good to hear!
> > Now that we have narrowed down the issue to msitranslate (that should be
> > disabled by default anyway), I would like to fix it entirely if possible.
> > Could you please try the appended patch, without any other patches
> > (therefore msitranslate would still be enabled)?
> >
> > Thanks for testing!!
> >
> 
> I've reverted the previous patch and applied this one, and I'm pleased
> to report it's still working. Thanks for your help!
> 

Thanks for testing! I am going to send the patch and add your tested-by.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:11:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZ6y-0006wd-Jq; Fri, 29 Jun 2012 11:11:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkZ6x-0006wN-CY
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 11:11:39 +0000
Received: from [85.158.138.51:6139] by server-12.bemta-3.messagelabs.com id
	62/F1-30206-A6D8DEF4; Fri, 29 Jun 2012 11:11:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1340968297!30197455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21107 invoked from network); 29 Jun 2012 11:11:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:11:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:11:33 +0100
Date: Fri, 29 Jun 2012 12:11:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rolu <rolu@roce.org>
In-Reply-To: <CABs9Ejn1Z_skEnEfj9y51=NQ5b3yipq9F5o9BeP-LnfZnuo1Lw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206291210470.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
	<alpine.DEB.2.02.1206281128591.27860@kaball.uk.xensource.com>
	<CABs9Ejn1Z_skEnEfj9y51=NQ5b3yipq9F5o9BeP-LnfZnuo1Lw@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>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Issue with MSI in a HVM domU with several passed
 through PCI devices
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012, Rolu wrote:
> On Thu, Jun 28, 2012 at 12:49 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 27 Jun 2012, Rolu wrote:
> >> > That's because msitranslate is still enabled somehow, that is a
> >> > toolstack bug.
> >> > While we fix that bug, could you try this QEMU patch to forcefully disable
> >> > msitranslate?
> >> >
> >>
> >> This worked!
> >>
> >> The "unsupported delivery mode" message is gone. Sound works, although
> >> there is still occasionally a very short stutter, but I expect that's
> >> a different issue. I've been testing with a KDE desktop with 3D
> >> effects (cube, expo, that sort of stuff) and performance there has
> >> gone up noticeably, from around 30-40 fps in most cases to near 60.
> >
> > Great, good to hear!
> > Now that we have narrowed down the issue to msitranslate (that should be
> > disabled by default anyway), I would like to fix it entirely if possible.
> > Could you please try the appended patch, without any other patches
> > (therefore msitranslate would still be enabled)?
> >
> > Thanks for testing!!
> >
> 
> I've reverted the previous patch and applied this one, and I'm pleased
> to report it's still working. Thanks for your help!
> 

Thanks for testing! I am going to send the patch and add your tested-by.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:21:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11:21: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 1SkZGC-0007Hj-KZ; Fri, 29 Jun 2012 11:21: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 1SkZGA-0007Hb-QI
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 11:21:11 +0000
Received: from [85.158.139.83:41873] by server-11.bemta-5.messagelabs.com id
	8F/58-20400-6AF8DEF4; Fri, 29 Jun 2012 11:21:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340968869!18895007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19309 invoked from network); 29 Jun 2012 11:21:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:21:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:20:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:20:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkZFv-0007yi-Ng; Fri, 29 Jun 2012 11:20:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkZFv-0001FE-Mb;
	Fri, 29 Jun 2012 12:20:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.36759.685003.44867@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 12:20:55 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13394-mainreport@xen.org>
References: <osstest-13394-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13394: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379

The logs show this:

  libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out

And in xenstore:

  /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)

And in the source code:

  $ grep -R logdirty qemu-upstream-unstable.git/*
  $

So the upstream qemu does not participate properly in the migration
protocol.  And anyway this protocol seems to involve xenstore and I
would have expected it to do something with QMP.  But there is no code
in libxl to do this (and never has been) and no code in upstream qemu
to do it either.

That means we'll get memory corruption in migrated guests with the new
qemu: any time qemu writes to guest memory, it needs to trigger a
logdirty update so that the write is properly transferred to the
migration target domain.

With the old libxl we didn't notice this apart from random failures.
With my new migration code, particularly
   25542:1883e5c71a87
   libxl: wait for qemu to acknowledge logdirty command
this turns into a hard failure.

I will add this as an allowable test failure pending a proper fix.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:21:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11:21: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 1SkZGC-0007Hj-KZ; Fri, 29 Jun 2012 11:21: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 1SkZGA-0007Hb-QI
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 11:21:11 +0000
Received: from [85.158.139.83:41873] by server-11.bemta-5.messagelabs.com id
	8F/58-20400-6AF8DEF4; Fri, 29 Jun 2012 11:21:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1340968869!18895007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19309 invoked from network); 29 Jun 2012 11:21:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:21:09 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:20:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:20:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkZFv-0007yi-Ng; Fri, 29 Jun 2012 11:20:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkZFv-0001FE-Mb;
	Fri, 29 Jun 2012 12:20:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.36759.685003.44867@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 12:20:55 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13394-mainreport@xen.org>
References: <osstest-13394-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 13394: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379

The logs show this:

  libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out

And in xenstore:

  /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)

And in the source code:

  $ grep -R logdirty qemu-upstream-unstable.git/*
  $

So the upstream qemu does not participate properly in the migration
protocol.  And anyway this protocol seems to involve xenstore and I
would have expected it to do something with QMP.  But there is no code
in libxl to do this (and never has been) and no code in upstream qemu
to do it either.

That means we'll get memory corruption in migrated guests with the new
qemu: any time qemu writes to guest memory, it needs to trigger a
logdirty update so that the write is properly transferred to the
migration target domain.

With the old libxl we didn't notice this apart from random failures.
With my new migration code, particularly
   25542:1883e5c71a87
   libxl: wait for qemu to acknowledge logdirty command
this turns into a hard failure.

I will add this as an allowable test failure pending a proper fix.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:22:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZHR-0007NN-3U; Fri, 29 Jun 2012 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1SkZHP-0007ND-P9
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 11:22:28 +0000
Received: from [85.158.139.83:54400] by server-8.bemta-5.messagelabs.com id
	3F/79-10278-3FF8DEF4; Fri, 29 Jun 2012 11:22:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340968946!30155836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14579 invoked from network); 29 Jun 2012 11:22:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:22:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:22:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:22:26 +0100
Date: Fri, 29 Jun 2012 12:21:57 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
In-Reply-To: <CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206291211320.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: rolu@roce.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen-trad: fix msi_translate with PV event
	delivery
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 switching from msitranslate to straight msi we need to make sure
that we respect PV event delivery for the msi if the guest asked for it:

- completely disable MSI on the device in pt_disable_msi_translate;
- then enable MSI again (pt_msi_setup), mapping the correct pirq to it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Rolu <rolu@roce.org>

---

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..fc8c49f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -3841,21 +3841,18 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev,
                 PT_LOG("guest enabling MSI, disable MSI-INTx translation\n");
                 pt_disable_msi_translate(ptdev);
             }
-            else
+            /* Init physical one */
+            PT_LOG("setup msi for dev %x\n", pd->devfn);
+            if (pt_msi_setup(ptdev))
             {
-                /* Init physical one */
-                PT_LOG("setup msi for dev %x\n", pd->devfn);
-                if (pt_msi_setup(ptdev))
-                {
-		    /* We do not broadcast the error to the framework code, so
-		     * that MSI errors are contained in MSI emulation code and
-		     * QEMU can go on running.
-		     * Guest MSI would be actually not working.
-		     */
-		    *value &= ~PCI_MSI_FLAGS_ENABLE;
-		    PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
-		    return 0;
-                }
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
+                return 0;
             }
             if (pt_msi_update(ptdev))
             {
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..73f737d 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -263,16 +263,8 @@ void pt_disable_msi_translate(struct pt_dev *dev)
     uint8_t e_device = 0;
     uint8_t e_intx = 0;
 
-    /* MSI_ENABLE bit should be disabed until the new handler is set */
-    msi_set_enable(dev, 0);
-
-    e_device = PCI_SLOT(dev->dev.devfn);
-    e_intx = pci_intx(dev);
-
-    if (xc_domain_unbind_pt_irq(xc_handle, domid, dev->msi->pirq,
-                                 PT_IRQ_TYPE_MSI_TRANSLATE, 0,
-                                 e_device, e_intx, 0))
-        PT_LOG("Error: Unbinding pt irq for MSI-INTx failed!\n");
+    pt_msi_disable(dev);
+    dev->msi->flags |= MSI_FLAG_UNINIT;
 
     if (dev->machine_irq)
     {
@@ -280,8 +272,6 @@ void pt_disable_msi_translate(struct pt_dev *dev)
                                        0, e_device, e_intx))
             PT_LOG("Error: Rebinding of interrupt failed!\n");
     }
-
-    dev->msi_trans_en = 0;
 }
 
 static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:22:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZHR-0007NN-3U; Fri, 29 Jun 2012 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1SkZHP-0007ND-P9
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 11:22:28 +0000
Received: from [85.158.139.83:54400] by server-8.bemta-5.messagelabs.com id
	3F/79-10278-3FF8DEF4; Fri, 29 Jun 2012 11:22:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1340968946!30155836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14579 invoked from network); 29 Jun 2012 11:22:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:22:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:22:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 12:22:26 +0100
Date: Fri, 29 Jun 2012 12:21:57 +0100
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
In-Reply-To: <CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1206291211320.27860@kaball.uk.xensource.com>
References: <CABs9EjnLJ4ibhFEU0niEeciqu+y9GhqzD7YPkoTg-DijZqaqXw@mail.gmail.com>
	<4FE06671020000780008A946@nat28.tlf.novell.com>
	<CABs9EjnqSSnZ5dY-bGTVVn9kq+w3rnBGiNEKWQizZFDe_AXV1w@mail.gmail.com>
	<4FE21084020000780008AE60@nat28.tlf.novell.com>
	<CABs9Ejk2Fz9VWup26X32JkCYzQTN2pke3NGUiXfjCZczuGC+tw@mail.gmail.com>
	<4FE83444020000780008BA00@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1206251212120.27860@kaball.uk.xensource.com>
	<CABs9EjkibDNKkbXz4Gq_hNuPkgYU9NZYzhcvZySa6vX-7Bp2SQ@mail.gmail.com>
	<alpine.DEB.2.02.1206261349200.27860@kaball.uk.xensource.com>
	<CABs9Ej=3JPgRexVaTSFj3A1WX_O9+USAZy4XMnHxRHWJFzia=w@mail.gmail.com>
	<alpine.DEB.2.02.1206271401520.27860@kaball.uk.xensource.com>
	<CABs9Ej=63Coc9Soi4wbbM63d-Cm=AmcDj1AsRg62dYpicoqvvQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: rolu@roce.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen-trad: fix msi_translate with PV event
	delivery
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 switching from msitranslate to straight msi we need to make sure
that we respect PV event delivery for the msi if the guest asked for it:

- completely disable MSI on the device in pt_disable_msi_translate;
- then enable MSI again (pt_msi_setup), mapping the correct pirq to it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Rolu <rolu@roce.org>

---

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..fc8c49f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -3841,21 +3841,18 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev,
                 PT_LOG("guest enabling MSI, disable MSI-INTx translation\n");
                 pt_disable_msi_translate(ptdev);
             }
-            else
+            /* Init physical one */
+            PT_LOG("setup msi for dev %x\n", pd->devfn);
+            if (pt_msi_setup(ptdev))
             {
-                /* Init physical one */
-                PT_LOG("setup msi for dev %x\n", pd->devfn);
-                if (pt_msi_setup(ptdev))
-                {
-		    /* We do not broadcast the error to the framework code, so
-		     * that MSI errors are contained in MSI emulation code and
-		     * QEMU can go on running.
-		     * Guest MSI would be actually not working.
-		     */
-		    *value &= ~PCI_MSI_FLAGS_ENABLE;
-		    PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
-		    return 0;
-                }
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_LOG("Warning: Can not map MSI for dev %x\n", pd->devfn);
+                return 0;
             }
             if (pt_msi_update(ptdev))
             {
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..73f737d 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -263,16 +263,8 @@ void pt_disable_msi_translate(struct pt_dev *dev)
     uint8_t e_device = 0;
     uint8_t e_intx = 0;
 
-    /* MSI_ENABLE bit should be disabed until the new handler is set */
-    msi_set_enable(dev, 0);
-
-    e_device = PCI_SLOT(dev->dev.devfn);
-    e_intx = pci_intx(dev);
-
-    if (xc_domain_unbind_pt_irq(xc_handle, domid, dev->msi->pirq,
-                                 PT_IRQ_TYPE_MSI_TRANSLATE, 0,
-                                 e_device, e_intx, 0))
-        PT_LOG("Error: Unbinding pt irq for MSI-INTx failed!\n");
+    pt_msi_disable(dev);
+    dev->msi->flags |= MSI_FLAG_UNINIT;
 
     if (dev->machine_irq)
     {
@@ -280,8 +272,6 @@ void pt_disable_msi_translate(struct pt_dev *dev)
                                        0, e_device, e_intx))
             PT_LOG("Error: Rebinding of interrupt failed!\n");
     }
-
-    dev->msi_trans_en = 0;
 }
 
 static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 11:47:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZfn-0008DT-3U; Fri, 29 Jun 2012 11:47: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 1SkZfm-0008DN-0L
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 11:47:38 +0000
Received: from [85.158.138.51:52855] by server-11.bemta-3.messagelabs.com id
	21/E1-02904-9D59DEF4; Fri, 29 Jun 2012 11:47:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340970456!22106643!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3028 invoked from network); 29 Jun 2012 11:47:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:47:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:47:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 12:47:36 +0100
Message-ID: <1340970454.10942.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 12:47:34 +0100
In-Reply-To: <20461.36759.685003.44867@mariner.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> 
> The logs show this:
> 
>   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> 
> And in xenstore:
> 
>   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> 
> And in the source code:
> 
>   $ grep -R logdirty qemu-upstream-unstable.git/*
>   $
> 
> So the upstream qemu does not participate properly in the migration
> protocol.  And anyway this protocol seems to involve xenstore and I
> would have expected it to do something with QMP.  But there is no code
> in libxl to do this (and never has been) and no code in upstream qemu
> to do it either.
> 
> That means we'll get memory corruption in migrated guests with the new
> qemu: any time qemu writes to guest memory, it needs to trigger a
> logdirty update so that the write is properly transferred to the
> migration target domain.
> 
> With the old libxl we didn't notice this apart from random failures.
> With my new migration code, particularly
>    25542:1883e5c71a87
>    libxl: wait for qemu to acknowledge logdirty command
> this turns into a hard failure.
> 
> I will add this as an allowable test failure pending a proper fix.

Thanks for investigating. It does appear that this has always been
broken.

Do we think this is a blocker for 4.2?

It certainly prevents us from suggesting that we support HVM migration
with the (non-default) upstream qemu.

If we can't fix this for 4.2 (e.g. because we need to get patches into
upstream qemu or because the libxl side is too involved) we should at a
minimum make libxl reject attempts to migrate such domains with an
appropriate error message.

How does this impact the use of upstream qemu for PV guest backends vs
migration? I *think* they don't require log-dirty support, but I'm not
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 Jun 29 11:47:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 11: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 1SkZfn-0008DT-3U; Fri, 29 Jun 2012 11:47: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 1SkZfm-0008DN-0L
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 11:47:38 +0000
Received: from [85.158.138.51:52855] by server-11.bemta-3.messagelabs.com id
	21/E1-02904-9D59DEF4; Fri, 29 Jun 2012 11:47:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340970456!22106643!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3028 invoked from network); 29 Jun 2012 11:47:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 11:47:36 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13289863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 11:47:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 12:47:36 +0100
Message-ID: <1340970454.10942.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 12:47:34 +0100
In-Reply-To: <20461.36759.685003.44867@mariner.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> 
> The logs show this:
> 
>   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> 
> And in xenstore:
> 
>   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> 
> And in the source code:
> 
>   $ grep -R logdirty qemu-upstream-unstable.git/*
>   $
> 
> So the upstream qemu does not participate properly in the migration
> protocol.  And anyway this protocol seems to involve xenstore and I
> would have expected it to do something with QMP.  But there is no code
> in libxl to do this (and never has been) and no code in upstream qemu
> to do it either.
> 
> That means we'll get memory corruption in migrated guests with the new
> qemu: any time qemu writes to guest memory, it needs to trigger a
> logdirty update so that the write is properly transferred to the
> migration target domain.
> 
> With the old libxl we didn't notice this apart from random failures.
> With my new migration code, particularly
>    25542:1883e5c71a87
>    libxl: wait for qemu to acknowledge logdirty command
> this turns into a hard failure.
> 
> I will add this as an allowable test failure pending a proper fix.

Thanks for investigating. It does appear that this has always been
broken.

Do we think this is a blocker for 4.2?

It certainly prevents us from suggesting that we support HVM migration
with the (non-default) upstream qemu.

If we can't fix this for 4.2 (e.g. because we need to get patches into
upstream qemu or because the libxl side is too involved) we should at a
minimum make libxl reject attempts to migrate such domains with an
appropriate error message.

How does this impact the use of upstream qemu for PV guest backends vs
migration? I *think* they don't require log-dirty support, but I'm not
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 Jun 29 12:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaKg-0000Qf-61; Fri, 29 Jun 2012 12:29:54 +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 1SkaKe-0000Qa-Dd
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:29:52 +0000
Received: from [193.109.254.147:37659] by server-7.bemta-14.messagelabs.com id
	66/BC-29827-FBF9DEF4; Fri, 29 Jun 2012 12:29:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340972990!6802741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7316 invoked from network); 29 Jun 2012 12:29:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:29:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13290929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:29:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 13:29:50 +0100
Date: Fri, 29 Jun 2012 13:29:32 +0100
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: <1340970454.10942.97.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.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.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > 
> > The logs show this:
> > 
> >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > 
> > And in xenstore:
> > 
> >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > 
> > And in the source code:
> > 
> >   $ grep -R logdirty qemu-upstream-unstable.git/*
> >   $
> > 
> > So the upstream qemu does not participate properly in the migration
> > protocol.  And anyway this protocol seems to involve xenstore and I
> > would have expected it to do something with QMP.  But there is no code
> > in libxl to do this (and never has been) and no code in upstream qemu
> > to do it either.
> > 
> > That means we'll get memory corruption in migrated guests with the new
> > qemu: any time qemu writes to guest memory, it needs to trigger a
> > logdirty update so that the write is properly transferred to the
> > migration target domain.
> > 
> > With the old libxl we didn't notice this apart from random failures.
> > With my new migration code, particularly
> >    25542:1883e5c71a87
> >    libxl: wait for qemu to acknowledge logdirty command
> > this turns into a hard failure.
> > 
> > I will add this as an allowable test failure pending a proper fix.
> 
> Thanks for investigating. It does appear that this has always been
> broken.
> 
> Do we think this is a blocker for 4.2?

I wouldn't consider it a blocker, given that upstream QEMU is not the
default for HVM guests.


> It certainly prevents us from suggesting that we support HVM migration
> with the (non-default) upstream qemu.
> 
> If we can't fix this for 4.2 (e.g. because we need to get patches into
> upstream qemu or because the libxl side is too involved) we should at a
> minimum make libxl reject attempts to migrate such domains with an
> appropriate error message.

We do need to get patches in QEMU to fix this but we could backport them in
qemu-upstream-unstable (and ask for backports to the stable trees).


> How does this impact the use of upstream qemu for PV guest backends vs
> migration? I *think* they don't require log-dirty support, but I'm not
> sure.
 
It does not affect qemu for PV guests.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 12:30:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaKg-0000Qf-61; Fri, 29 Jun 2012 12:29:54 +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 1SkaKe-0000Qa-Dd
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:29:52 +0000
Received: from [193.109.254.147:37659] by server-7.bemta-14.messagelabs.com id
	66/BC-29827-FBF9DEF4; Fri, 29 Jun 2012 12:29:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340972990!6802741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7316 invoked from network); 29 Jun 2012 12:29:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:29:51 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13290929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:29:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 13:29:50 +0100
Date: Fri, 29 Jun 2012 13:29:32 +0100
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: <1340970454.10942.97.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.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.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > 
> > The logs show this:
> > 
> >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > 
> > And in xenstore:
> > 
> >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > 
> > And in the source code:
> > 
> >   $ grep -R logdirty qemu-upstream-unstable.git/*
> >   $
> > 
> > So the upstream qemu does not participate properly in the migration
> > protocol.  And anyway this protocol seems to involve xenstore and I
> > would have expected it to do something with QMP.  But there is no code
> > in libxl to do this (and never has been) and no code in upstream qemu
> > to do it either.
> > 
> > That means we'll get memory corruption in migrated guests with the new
> > qemu: any time qemu writes to guest memory, it needs to trigger a
> > logdirty update so that the write is properly transferred to the
> > migration target domain.
> > 
> > With the old libxl we didn't notice this apart from random failures.
> > With my new migration code, particularly
> >    25542:1883e5c71a87
> >    libxl: wait for qemu to acknowledge logdirty command
> > this turns into a hard failure.
> > 
> > I will add this as an allowable test failure pending a proper fix.
> 
> Thanks for investigating. It does appear that this has always been
> broken.
> 
> Do we think this is a blocker for 4.2?

I wouldn't consider it a blocker, given that upstream QEMU is not the
default for HVM guests.


> It certainly prevents us from suggesting that we support HVM migration
> with the (non-default) upstream qemu.
> 
> If we can't fix this for 4.2 (e.g. because we need to get patches into
> upstream qemu or because the libxl side is too involved) we should at a
> minimum make libxl reject attempts to migrate such domains with an
> appropriate error message.

We do need to get patches in QEMU to fix this but we could backport them in
qemu-upstream-unstable (and ask for backports to the stable trees).


> How does this impact the use of upstream qemu for PV guest backends vs
> migration? I *think* they don't require log-dirty support, but I'm not
> sure.
 
It does not affect qemu for PV guests.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 12:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaNc-0000bA-Nc; Fri, 29 Jun 2012 12:32:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkaNb-0000b5-Gi
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:32:55 +0000
Received: from [85.158.143.35:57859] by server-3.bemta-4.messagelabs.com id
	0D/EF-05808-670ADEF4; Fri, 29 Jun 2012 12:32:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340973173!4788894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18455 invoked from network); 29 Jun 2012 12:32:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13291013"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:32:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 13:32:53 +0100
Message-ID: <1340973172.10942.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 29 Jun 2012 13:32:52 +0100
In-Reply-To: <alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 13:29 +0100, Stefano Stabellini wrote:
> On Fri, 29 Jun 2012, Ian Campbell wrote:
> > On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > > Tests which did not succeed and are blocking,
> > > > including tests which could not be run:
> > > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > > 
> > > The logs show this:
> > > 
> > >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > > 
> > > And in xenstore:
> > > 
> > >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > > 
> > > And in the source code:
> > > 
> > >   $ grep -R logdirty qemu-upstream-unstable.git/*
> > >   $
> > > 
> > > So the upstream qemu does not participate properly in the migration
> > > protocol.  And anyway this protocol seems to involve xenstore and I
> > > would have expected it to do something with QMP.  But there is no code
> > > in libxl to do this (and never has been) and no code in upstream qemu
> > > to do it either.
> > > 
> > > That means we'll get memory corruption in migrated guests with the new
> > > qemu: any time qemu writes to guest memory, it needs to trigger a
> > > logdirty update so that the write is properly transferred to the
> > > migration target domain.
> > > 
> > > With the old libxl we didn't notice this apart from random failures.
> > > With my new migration code, particularly
> > >    25542:1883e5c71a87
> > >    libxl: wait for qemu to acknowledge logdirty command
> > > this turns into a hard failure.
> > > 
> > > I will add this as an allowable test failure pending a proper fix.
> > 
> > Thanks for investigating. It does appear that this has always been
> > broken.
> > 
> > Do we think this is a blocker for 4.2?
> 
> I wouldn't consider it a blocker, given that upstream QEMU is not the
> default for HVM guests.
> 
> 
> > It certainly prevents us from suggesting that we support HVM migration
> > with the (non-default) upstream qemu.
> > 
> > If we can't fix this for 4.2 (e.g. because we need to get patches into
> > upstream qemu or because the libxl side is too involved) we should at a
> > minimum make libxl reject attempts to migrate such domains with an
> > appropriate error message.
> 
> We do need to get patches in QEMU to fix this but we could backport them in
> qemu-upstream-unstable (and ask for backports to the stable trees).

Can we do that in time for 4.2? It's pretty late in the day.

I think we need to consider either achieving this or adding the
appropriate error message as a blocker. Hopefully the former but falling
back to the latter if it comes to it.

> > How does this impact the use of upstream qemu for PV guest backends vs
> > migration? I *think* they don't require log-dirty support, but I'm not
> > sure.
>  
> It does not affect qemu for PV guests.

Great.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 12:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaNc-0000bA-Nc; Fri, 29 Jun 2012 12:32:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkaNb-0000b5-Gi
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:32:55 +0000
Received: from [85.158.143.35:57859] by server-3.bemta-4.messagelabs.com id
	0D/EF-05808-670ADEF4; Fri, 29 Jun 2012 12:32:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1340973173!4788894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18455 invoked from network); 29 Jun 2012 12:32:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13291013"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:32:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 13:32:53 +0100
Message-ID: <1340973172.10942.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 29 Jun 2012 13:32:52 +0100
In-Reply-To: <alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 13:29 +0100, Stefano Stabellini wrote:
> On Fri, 29 Jun 2012, Ian Campbell wrote:
> > On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > > Tests which did not succeed and are blocking,
> > > > including tests which could not be run:
> > > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > > 
> > > The logs show this:
> > > 
> > >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > > 
> > > And in xenstore:
> > > 
> > >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > > 
> > > And in the source code:
> > > 
> > >   $ grep -R logdirty qemu-upstream-unstable.git/*
> > >   $
> > > 
> > > So the upstream qemu does not participate properly in the migration
> > > protocol.  And anyway this protocol seems to involve xenstore and I
> > > would have expected it to do something with QMP.  But there is no code
> > > in libxl to do this (and never has been) and no code in upstream qemu
> > > to do it either.
> > > 
> > > That means we'll get memory corruption in migrated guests with the new
> > > qemu: any time qemu writes to guest memory, it needs to trigger a
> > > logdirty update so that the write is properly transferred to the
> > > migration target domain.
> > > 
> > > With the old libxl we didn't notice this apart from random failures.
> > > With my new migration code, particularly
> > >    25542:1883e5c71a87
> > >    libxl: wait for qemu to acknowledge logdirty command
> > > this turns into a hard failure.
> > > 
> > > I will add this as an allowable test failure pending a proper fix.
> > 
> > Thanks for investigating. It does appear that this has always been
> > broken.
> > 
> > Do we think this is a blocker for 4.2?
> 
> I wouldn't consider it a blocker, given that upstream QEMU is not the
> default for HVM guests.
> 
> 
> > It certainly prevents us from suggesting that we support HVM migration
> > with the (non-default) upstream qemu.
> > 
> > If we can't fix this for 4.2 (e.g. because we need to get patches into
> > upstream qemu or because the libxl side is too involved) we should at a
> > minimum make libxl reject attempts to migrate such domains with an
> > appropriate error message.
> 
> We do need to get patches in QEMU to fix this but we could backport them in
> qemu-upstream-unstable (and ask for backports to the stable trees).

Can we do that in time for 4.2? It's pretty late in the day.

I think we need to consider either achieving this or adding the
appropriate error message as a blocker. Hopefully the former but falling
back to the latter if it comes to it.

> > How does this impact the use of upstream qemu for PV guest backends vs
> > migration? I *think* they don't require log-dirty support, but I'm not
> > sure.
>  
> It does not affect qemu for PV guests.

Great.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 12:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaRU-0000l4-CL; Fri, 29 Jun 2012 12:36:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkaRT-0000kx-KC
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:36:55 +0000
Received: from [85.158.143.35:25507] by server-2.bemta-4.messagelabs.com id
	8A/9E-17938-661ADEF4; Fri, 29 Jun 2012 12:36:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340973414!16857606!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12550 invoked from network); 29 Jun 2012 12:36:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:36:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13291098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:36:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 13:36:54 +0100
Date: Fri, 29 Jun 2012 13:36:36 +0100
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: <1340973172.10942.98.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.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.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-29 at 13:29 +0100, Stefano Stabellini wrote:
> > On Fri, 29 Jun 2012, Ian Campbell wrote:
> > > On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > > > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > > > Tests which did not succeed and are blocking,
> > > > > including tests which could not be run:
> > > > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > > > 
> > > > The logs show this:
> > > > 
> > > >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > > > 
> > > > And in xenstore:
> > > > 
> > > >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > > > 
> > > > And in the source code:
> > > > 
> > > >   $ grep -R logdirty qemu-upstream-unstable.git/*
> > > >   $
> > > > 
> > > > So the upstream qemu does not participate properly in the migration
> > > > protocol.  And anyway this protocol seems to involve xenstore and I
> > > > would have expected it to do something with QMP.  But there is no code
> > > > in libxl to do this (and never has been) and no code in upstream qemu
> > > > to do it either.
> > > > 
> > > > That means we'll get memory corruption in migrated guests with the new
> > > > qemu: any time qemu writes to guest memory, it needs to trigger a
> > > > logdirty update so that the write is properly transferred to the
> > > > migration target domain.
> > > > 
> > > > With the old libxl we didn't notice this apart from random failures.
> > > > With my new migration code, particularly
> > > >    25542:1883e5c71a87
> > > >    libxl: wait for qemu to acknowledge logdirty command
> > > > this turns into a hard failure.
> > > > 
> > > > I will add this as an allowable test failure pending a proper fix.
> > > 
> > > Thanks for investigating. It does appear that this has always been
> > > broken.
> > > 
> > > Do we think this is a blocker for 4.2?
> > 
> > I wouldn't consider it a blocker, given that upstream QEMU is not the
> > default for HVM guests.
> > 
> > 
> > > It certainly prevents us from suggesting that we support HVM migration
> > > with the (non-default) upstream qemu.
> > > 
> > > If we can't fix this for 4.2 (e.g. because we need to get patches into
> > > upstream qemu or because the libxl side is too involved) we should at a
> > > minimum make libxl reject attempts to migrate such domains with an
> > > appropriate error message.
> > 
> > We do need to get patches in QEMU to fix this but we could backport them in
> > qemu-upstream-unstable (and ask for backports to the stable trees).
> 
> Can we do that in time for 4.2? It's pretty late in the day.
> 
> I think we need to consider either achieving this or adding the
> appropriate error message as a blocker. Hopefully the former but falling
> back to the latter if it comes to it.

I think we should add an appropriate error message as a blocker. We
should also try to fix this on the QEMU side, but given that the QEMU
1.0 stable tree is pretty much unmaintaned, we won't be able to backport
the fix there, so we cannot be sure that a distro will end up with a
QEMU with or without the fix.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 12:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaRU-0000l4-CL; Fri, 29 Jun 2012 12:36:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1SkaRT-0000kx-KC
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:36:55 +0000
Received: from [85.158.143.35:25507] by server-2.bemta-4.messagelabs.com id
	8A/9E-17938-661ADEF4; Fri, 29 Jun 2012 12:36:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1340973414!16857606!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12550 invoked from network); 29 Jun 2012 12:36:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:36:54 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13291098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:36:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 13:36:54 +0100
Date: Fri, 29 Jun 2012 13:36:36 +0100
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: <1340973172.10942.98.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.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.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012, Ian Campbell wrote:
> On Fri, 2012-06-29 at 13:29 +0100, Stefano Stabellini wrote:
> > On Fri, 29 Jun 2012, Ian Campbell wrote:
> > > On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > > > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > > > Tests which did not succeed and are blocking,
> > > > > including tests which could not be run:
> > > > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > > > 
> > > > The logs show this:
> > > > 
> > > >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > > > 
> > > > And in xenstore:
> > > > 
> > > >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > > > 
> > > > And in the source code:
> > > > 
> > > >   $ grep -R logdirty qemu-upstream-unstable.git/*
> > > >   $
> > > > 
> > > > So the upstream qemu does not participate properly in the migration
> > > > protocol.  And anyway this protocol seems to involve xenstore and I
> > > > would have expected it to do something with QMP.  But there is no code
> > > > in libxl to do this (and never has been) and no code in upstream qemu
> > > > to do it either.
> > > > 
> > > > That means we'll get memory corruption in migrated guests with the new
> > > > qemu: any time qemu writes to guest memory, it needs to trigger a
> > > > logdirty update so that the write is properly transferred to the
> > > > migration target domain.
> > > > 
> > > > With the old libxl we didn't notice this apart from random failures.
> > > > With my new migration code, particularly
> > > >    25542:1883e5c71a87
> > > >    libxl: wait for qemu to acknowledge logdirty command
> > > > this turns into a hard failure.
> > > > 
> > > > I will add this as an allowable test failure pending a proper fix.
> > > 
> > > Thanks for investigating. It does appear that this has always been
> > > broken.
> > > 
> > > Do we think this is a blocker for 4.2?
> > 
> > I wouldn't consider it a blocker, given that upstream QEMU is not the
> > default for HVM guests.
> > 
> > 
> > > It certainly prevents us from suggesting that we support HVM migration
> > > with the (non-default) upstream qemu.
> > > 
> > > If we can't fix this for 4.2 (e.g. because we need to get patches into
> > > upstream qemu or because the libxl side is too involved) we should at a
> > > minimum make libxl reject attempts to migrate such domains with an
> > > appropriate error message.
> > 
> > We do need to get patches in QEMU to fix this but we could backport them in
> > qemu-upstream-unstable (and ask for backports to the stable trees).
> 
> Can we do that in time for 4.2? It's pretty late in the day.
> 
> I think we need to consider either achieving this or adding the
> appropriate error message as a blocker. Hopefully the former but falling
> back to the latter if it comes to it.

I think we should add an appropriate error message as a blocker. We
should also try to fix this on the QEMU side, but given that the QEMU
1.0 stable tree is pretty much unmaintaned, we won't be able to backport
the fix there, so we cannot be sure that a distro will end up with a
QEMU with or without the fix.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 12:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaZg-00015D-C1; Fri, 29 Jun 2012 12:45: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 1SkaZe-000158-Es
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:45:22 +0000
Received: from [193.109.254.147:10257] by server-5.bemta-14.messagelabs.com id
	6E/FE-04343-163ADEF4; Fri, 29 Jun 2012 12:45:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340973918!2362707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29827 invoked from network); 29 Jun 2012 12:45:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:45:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13291276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:45:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 13:45:18 +0100
Message-ID: <1340973916.10942.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 29 Jun 2012 13:45:16 +0100
In-Reply-To: <alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 13:36 +0100, Stefano Stabellini wrote:
> On Fri, 29 Jun 2012, Ian Campbell wrote:
> > On Fri, 2012-06-29 at 13:29 +0100, Stefano Stabellini wrote:
> > > On Fri, 29 Jun 2012, Ian Campbell wrote:
> > > > On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > > > > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > > > > Tests which did not succeed and are blocking,
> > > > > > including tests which could not be run:
> > > > > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > > > > 
> > > > > The logs show this:
> > > > > 
> > > > >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > > > > 
> > > > > And in xenstore:
> > > > > 
> > > > >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > > > > 
> > > > > And in the source code:
> > > > > 
> > > > >   $ grep -R logdirty qemu-upstream-unstable.git/*
> > > > >   $
> > > > > 
> > > > > So the upstream qemu does not participate properly in the migration
> > > > > protocol.  And anyway this protocol seems to involve xenstore and I
> > > > > would have expected it to do something with QMP.  But there is no code
> > > > > in libxl to do this (and never has been) and no code in upstream qemu
> > > > > to do it either.
> > > > > 
> > > > > That means we'll get memory corruption in migrated guests with the new
> > > > > qemu: any time qemu writes to guest memory, it needs to trigger a
> > > > > logdirty update so that the write is properly transferred to the
> > > > > migration target domain.
> > > > > 
> > > > > With the old libxl we didn't notice this apart from random failures.
> > > > > With my new migration code, particularly
> > > > >    25542:1883e5c71a87
> > > > >    libxl: wait for qemu to acknowledge logdirty command
> > > > > this turns into a hard failure.
> > > > > 
> > > > > I will add this as an allowable test failure pending a proper fix.
> > > > 
> > > > Thanks for investigating. It does appear that this has always been
> > > > broken.
> > > > 
> > > > Do we think this is a blocker for 4.2?
> > > 
> > > I wouldn't consider it a blocker, given that upstream QEMU is not the
> > > default for HVM guests.
> > > 
> > > 
> > > > It certainly prevents us from suggesting that we support HVM migration
> > > > with the (non-default) upstream qemu.
> > > > 
> > > > If we can't fix this for 4.2 (e.g. because we need to get patches into
> > > > upstream qemu or because the libxl side is too involved) we should at a
> > > > minimum make libxl reject attempts to migrate such domains with an
> > > > appropriate error message.
> > > 
> > > We do need to get patches in QEMU to fix this but we could backport them in
> > > qemu-upstream-unstable (and ask for backports to the stable trees).
> > 
> > Can we do that in time for 4.2? It's pretty late in the day.
> > 
> > I think we need to consider either achieving this or adding the
> > appropriate error message as a blocker. Hopefully the former but falling
> > back to the latter if it comes to it.
> 
> I think we should add an appropriate error message as a blocker. We
> should also try to fix this on the QEMU side, but given that the QEMU
> 1.0 stable tree is pretty much unmaintaned, we won't be able to backport
> the fix there, so we cannot be sure that a distro will end up with a
> QEMU with or without the fix.

Agreed. I'll add this to the 4.2 TODO list.

If we can get support into the mainline qemu then as a stretch goal we
can consider whether libxl can auto detect the availability of the
feature and react accordingly.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 12:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 12: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 1SkaZg-00015D-C1; Fri, 29 Jun 2012 12:45: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 1SkaZe-000158-Es
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 12:45:22 +0000
Received: from [193.109.254.147:10257] by server-5.bemta-14.messagelabs.com id
	6E/FE-04343-163ADEF4; Fri, 29 Jun 2012 12:45:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1340973918!2362707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29827 invoked from network); 29 Jun 2012 12:45:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 12:45:18 -0000
X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="13291276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 12:45:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 13:45:18 +0100
Message-ID: <1340973916.10942.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 29 Jun 2012 13:45:16 +0100
In-Reply-To: <alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13394: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 13:36 +0100, Stefano Stabellini wrote:
> On Fri, 29 Jun 2012, Ian Campbell wrote:
> > On Fri, 2012-06-29 at 13:29 +0100, Stefano Stabellini wrote:
> > > On Fri, 29 Jun 2012, Ian Campbell wrote:
> > > > On Fri, 2012-06-29 at 12:20 +0100, Ian Jackson wrote:
> > > > > xen.org writes ("[xen-unstable test] 13394: regressions - FAIL"):
> > > > > > Tests which did not succeed and are blocking,
> > > > > > including tests which could not be run:
> > > > > >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate fail REGR. vs. 13379
> > > > > 
> > > > > The logs show this:
> > > > > 
> > > > >   libxl: error: libxl_dom.c:632:switch_logdirty_timeout: logdirty switch: wait for device model timed out
> > > > > 
> > > > > And in xenstore:
> > > > > 
> > > > >   /local/domain/0/device-model/5/logdirty/cmd = "enable"   (n0)
> > > > > 
> > > > > And in the source code:
> > > > > 
> > > > >   $ grep -R logdirty qemu-upstream-unstable.git/*
> > > > >   $
> > > > > 
> > > > > So the upstream qemu does not participate properly in the migration
> > > > > protocol.  And anyway this protocol seems to involve xenstore and I
> > > > > would have expected it to do something with QMP.  But there is no code
> > > > > in libxl to do this (and never has been) and no code in upstream qemu
> > > > > to do it either.
> > > > > 
> > > > > That means we'll get memory corruption in migrated guests with the new
> > > > > qemu: any time qemu writes to guest memory, it needs to trigger a
> > > > > logdirty update so that the write is properly transferred to the
> > > > > migration target domain.
> > > > > 
> > > > > With the old libxl we didn't notice this apart from random failures.
> > > > > With my new migration code, particularly
> > > > >    25542:1883e5c71a87
> > > > >    libxl: wait for qemu to acknowledge logdirty command
> > > > > this turns into a hard failure.
> > > > > 
> > > > > I will add this as an allowable test failure pending a proper fix.
> > > > 
> > > > Thanks for investigating. It does appear that this has always been
> > > > broken.
> > > > 
> > > > Do we think this is a blocker for 4.2?
> > > 
> > > I wouldn't consider it a blocker, given that upstream QEMU is not the
> > > default for HVM guests.
> > > 
> > > 
> > > > It certainly prevents us from suggesting that we support HVM migration
> > > > with the (non-default) upstream qemu.
> > > > 
> > > > If we can't fix this for 4.2 (e.g. because we need to get patches into
> > > > upstream qemu or because the libxl side is too involved) we should at a
> > > > minimum make libxl reject attempts to migrate such domains with an
> > > > appropriate error message.
> > > 
> > > We do need to get patches in QEMU to fix this but we could backport them in
> > > qemu-upstream-unstable (and ask for backports to the stable trees).
> > 
> > Can we do that in time for 4.2? It's pretty late in the day.
> > 
> > I think we need to consider either achieving this or adding the
> > appropriate error message as a blocker. Hopefully the former but falling
> > back to the latter if it comes to it.
> 
> I think we should add an appropriate error message as a blocker. We
> should also try to fix this on the QEMU side, but given that the QEMU
> 1.0 stable tree is pretty much unmaintaned, we won't be able to backport
> the fix there, so we cannot be sure that a distro will end up with a
> QEMU with or without the fix.

Agreed. I'll add this to the 4.2 TODO list.

If we can get support into the mainline qemu then as a stretch goal we
can consider whether libxl can auto detect the availability of the
feature and react accordingly.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:24:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1Skc6w-0003hR-6i; Fri, 29 Jun 2012 14:23: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 1Skc6u-0003hC-FN
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:23:48 +0000
Received: from [85.158.138.51:23753] by server-3.bemta-3.messagelabs.com id
	7F/8B-26490-37ABDEF4; Fri, 29 Jun 2012 14:23:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340979826!22078620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 29 Jun 2012 14:23:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	29 Jun 2012 14:23:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 15:23:47 +0100
Message-Id: <4FEDD6BF020000780008CDE5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 15:24:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFD1508F.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: improve CR0 read/write
	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>
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.

--=__PartFFD1508F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the only bit in CR0 permitted to be changed by PV guests being TS,
optimize the handling towards that: Keep a cached value in a per-CPU
variable, and issue HYPERVISOR_fpu_taskswitch hypercalls for updates in
all but the unusual case should something in the system still try to
modify another bit (the attempt of which would then be logged by the
hypervisor).

This removes the need to have the hypervisor emulate MOV to/from CR0
instructions in all halfway frequently executed code paths.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/kernel/cpu/common-xen.c
+++ b/arch/i386/kernel/cpu/common-xen.c
@@ -32,6 +32,9 @@ EXPORT_PER_CPU_SYMBOL(cpu_gdt_descr);
 #ifndef CONFIG_XEN
 DEFINE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);
 EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack);
+#else
+DEFINE_PER_CPU(unsigned int, xen_x86_cr0);
+EXPORT_PER_CPU_SYMBOL(xen_x86_cr0);
 #endif
=20
 static int cachesize_override __cpuinitdata =3D -1;
@@ -681,6 +684,7 @@ old_gdt:
 	cpu_gdt_descr->size =3D GDT_SIZE - 1;
  	cpu_gdt_descr->address =3D (unsigned long)gdt;
 #else
+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();
 	if (cpu =3D=3D 0 && cpu_gdt_descr->address =3D=3D 0) {
 		gdt =3D (struct desc_struct *)alloc_bootmem_pages(PAGE_SIZE=
);
 		/* alloc_bootmem_pages panics on failure, so no check */
--- a/arch/i386/kernel/process-xen.c
+++ b/arch/i386/kernel/process-xen.c
@@ -641,6 +641,8 @@ struct task_struct fastcall * __switch_t
 	BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));
 	if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL)))
 		BUG();
+	if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch)
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;
=20
 	/*
 	 * Restore %fs and %gs if needed.
--- a/arch/i386/kernel/traps-xen.c
+++ b/arch/i386/kernel/traps-xen.c
@@ -1057,6 +1057,7 @@ asmlinkage void math_state_restore(struc
 	struct task_struct *tsk =3D thread->task;
=20
 	/* NB. 'clts' is done for us by Xen during virtual trap. */
+	__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS;
 	if (!tsk_used_math(tsk))
 		init_fpu(tsk);
 	restore_fpu(tsk);
--- a/arch/x86_64/kernel/process-xen.c
+++ b/arch/x86_64/kernel/process-xen.c
@@ -574,6 +574,8 @@ __switch_to(struct task_struct *prev_p,=20
 	BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));
 	if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL)))
 		BUG();
+	if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch)
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;
=20
 	/*=20
 	 * Switch DS and ES.
--- a/arch/x86_64/kernel/setup64-xen.c
+++ b/arch/x86_64/kernel/setup64-xen.c
@@ -126,6 +126,9 @@ void __init setup_per_cpu_areas(void)
 }=20
=20
 #ifdef CONFIG_XEN
+DEFINE_PER_CPU(unsigned long, xen_x86_cr0);
+EXPORT_PER_CPU_SYMBOL(xen_x86_cr0);
+
 static void switch_pt(void)
 {
 	xen_pt_switch(__pa_symbol(init_level4_pgt));
@@ -174,6 +177,7 @@ void pda_init(int cpu)
 	if (HYPERVISOR_set_segment_base(SEGBASE_GS_KERNEL,
 					(unsigned long)pda))
 		BUG();
+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();
 #endif
 	pda->cpunumber =3D cpu;=20
 	pda->irqcount =3D -1;
--- a/arch/x86_64/kernel/traps-xen.c
+++ b/arch/x86_64/kernel/traps-xen.c
@@ -1075,8 +1075,9 @@ asmlinkage void __attribute__((weak)) mc
 asmlinkage void math_state_restore(void)
 {
 	struct task_struct *me =3D current;
-        /* clts(); */ /* 'clts' is done for us by Xen during virtual =
trap. */
=20
+	/* NB. 'clts' is done for us by Xen during virtual trap. */
+	__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS;
 	if (!used_math())
 		init_fpu(me);
 	restore_fpu_checking(&me->thread.i387.fxsave);
--- a/include/asm-i386/mach-xen/asm/system.h
+++ b/include/asm-i386/mach-xen/asm/system.h
@@ -2,8 +2,10 @@
 #define __ASM_SYSTEM_H
=20
 #include <linux/kernel.h>
+#include <linux/threads.h>
 #include <asm/segment.h>
 #include <asm/cpufeature.h>
+#include <asm/percpu.h>
 #include <linux/bitops.h> /* for LOCK_PREFIX */
 #include <asm/synch_bitops.h>
 #include <asm/hypervisor.h>
@@ -90,15 +91,30 @@ __asm__ __volatile__ ("movw %%dx,%1\n\t"
 #define savesegment(seg, value) \
 	asm volatile("mov %%" #seg ",%0":"=3Drm" (value))
=20
-#define read_cr0() ({ \
+DECLARE_PER_CPU(unsigned int, xen_x86_cr0);
+
+#define raw_read_cr0() ({ \
 	unsigned int __dummy; \
 	__asm__ __volatile__( \
 		"movl %%cr0,%0\n\t" \
 		:"=3Dr" (__dummy)); \
 	__dummy; \
 })
-#define write_cr0(x) \
-	__asm__ __volatile__("movl %0,%%cr0": :"r" (x))
+#define read_cr0() __get_cpu_var(xen_x86_cr0)
+#define write_cr0(x) do { \
+	unsigned int x__ =3D (x); \
+	switch (x__ ^ __get_cpu_var(xen_x86_cr0)) { \
+	case 0: \
+		continue; \
+	case X86_CR0_TS: \
+		HYPERVISOR_fpu_taskswitch(!!(x__ & X86_CR0_TS)); \
+		break; \
+	default: \
+		__asm__ __volatile__("movl %0,%%cr0": :"r" (x__)); \
+		break; \
+	} \
+	__get_cpu_var(xen_x86_cr0) =3D x__; \
+} while (0)
=20
 #define read_cr2() (current_vcpu_info()->arch.cr2)
 #define write_cr2(x) \
@@ -142,8 +158,19 @@ __asm__ __volatile__ ("movw %%dx,%1\n\t"
 /*
  * Clear and set 'TS' bit respectively
  */
-#define clts() (HYPERVISOR_fpu_taskswitch(0))
-#define stts() (HYPERVISOR_fpu_taskswitch(1))
+#define X86_CR0_TS 8
+#define clts() ({ \
+	if (__get_cpu_var(xen_x86_cr0) & X86_CR0_TS) { \
+		HYPERVISOR_fpu_taskswitch(0); \
+		__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS; \
+	} \
+})
+#define stts() ({ \
+	if (!(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS)) { \
+		HYPERVISOR_fpu_taskswitch(1); \
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; \
+	} \
+})
=20
 #endif	/* __KERNEL__ */
=20
--- a/include/asm-x86_64/mach-xen/asm/system.h
+++ b/include/asm-x86_64/mach-xen/asm/system.h
@@ -7,7 +7,7 @@
=20
 #include <asm/synch_bitops.h>
 #include <asm/hypervisor.h>
-#include <xen/interface/arch-x86_64.h>
+#include <asm/percpu.h>
=20
 #ifdef __KERNEL__
=20
@@ -71,18 +71,41 @@ struct alt_instr {
 /*
  * Clear and set 'TS' bit respectively
  */
-#define clts() (HYPERVISOR_fpu_taskswitch(0))
+#define X86_CR0_TS 8
+#define clts() ({ \
+	if (__get_cpu_var(xen_x86_cr0) & X86_CR0_TS) { \
+		HYPERVISOR_fpu_taskswitch(0); \
+		__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS; \
+	} \
+})
=20
-static inline unsigned long read_cr0(void)
+DECLARE_PER_CPU(unsigned long, xen_x86_cr0);
+
+static inline unsigned long raw_read_cr0(void)
 {=20
 	unsigned long cr0;
 	asm volatile("movq %%cr0,%0" : "=3Dr" (cr0));
 	return cr0;
 }=20
=20
+static inline unsigned long read_cr0(void)
+{
+	return __get_cpu_var(xen_x86_cr0);
+}
+
 static inline void write_cr0(unsigned long val)=20
 {=20
-	asm volatile("movq %0,%%cr0" :: "r" (val));
+	switch (val ^ __get_cpu_var(xen_x86_cr0)) {
+	case 0:
+		return;
+	case X86_CR0_TS:
+		HYPERVISOR_fpu_taskswitch(!!(val & X86_CR0_TS));
+		break;
+	default:
+		asm volatile("movq %0,%%cr0" :: "r" (val));
+		break;
+	}
+	__get_cpu_var(xen_x86_cr0) =3D val;
 }=20
=20
 #define read_cr3() ({ \
@@ -103,7 +126,12 @@ static inline void write_cr4(unsigned lo
 	asm volatile("movq %0,%%cr4" :: "r" (val));
 }=20
=20
-#define stts() (HYPERVISOR_fpu_taskswitch(1))
+#define stts() ({ \
+	if (!(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS)) { \
+		HYPERVISOR_fpu_taskswitch(1); \
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; \
+	} \
+})
=20
 #define wbinvd() \
 	__asm__ __volatile__ ("wbinvd": : :"memory");



--=__PartFFD1508F.0__=
Content-Type: text/plain; name="xen-x86-cr0.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-x86-cr0.patch"

x86: improve CR0 read/write handling=0A=0AWith the only bit in CR0 =
permitted to be changed by PV guests being TS,=0Aoptimize the handling =
towards that: Keep a cached value in a per-CPU=0Avariable, and issue =
HYPERVISOR_fpu_taskswitch hypercalls for updates in=0Aall but the unusual =
case should something in the system still try to=0Amodify another bit (the =
attempt of which would then be logged by the=0Ahypervisor).=0A=0AThis =
removes the need to have the hypervisor emulate MOV to/from CR0=0Ainstructi=
ons in all halfway frequently executed code paths.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/arch/i386/kernel/cpu/common-xen.c=0A=
+++ b/arch/i386/kernel/cpu/common-xen.c=0A@@ -32,6 +32,9 @@ EXPORT_PER_CPU_=
SYMBOL(cpu_gdt_descr);=0A #ifndef CONFIG_XEN=0A DEFINE_PER_CPU(unsigned =
char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);=0A EXPORT_PER_CPU_SYMBOL(cpu_=
16bit_stack);=0A+#else=0A+DEFINE_PER_CPU(unsigned int, xen_x86_cr0);=0A+EXP=
ORT_PER_CPU_SYMBOL(xen_x86_cr0);=0A #endif=0A =0A static int cachesize_over=
ride __cpuinitdata =3D -1;=0A@@ -681,6 +684,7 @@ old_gdt:=0A 	cpu_gdt_des=
cr->size =3D GDT_SIZE - 1;=0A  	cpu_gdt_descr->address =3D (unsigned =
long)gdt;=0A #else=0A+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();=0A 	=
if (cpu =3D=3D 0 && cpu_gdt_descr->address =3D=3D 0) {=0A 		=
gdt =3D (struct desc_struct *)alloc_bootmem_pages(PAGE_SIZE);=0A 		=
/* alloc_bootmem_pages panics on failure, so no check */=0A--- a/arch/i386/=
kernel/process-xen.c=0A+++ b/arch/i386/kernel/process-xen.c=0A@@ -641,6 =
+641,8 @@ struct task_struct fastcall * __switch_t=0A 	BUG_ON(mcl > _mcl =
+ ARRAY_SIZE(_mcl));=0A 	if (unlikely(HYPERVISOR_multicall_check(_mc=
l, mcl - _mcl, NULL)))=0A 		BUG();=0A+	if (_mcl->op =
=3D=3D __HYPERVISOR_fpu_taskswitch)=0A+		__get_cpu_var(xen_x86_cr0) =
|=3D X86_CR0_TS;=0A =0A 	/*=0A 	 * Restore %fs and %gs if =
needed.=0A--- a/arch/i386/kernel/traps-xen.c=0A+++ b/arch/i386/kernel/traps=
-xen.c=0A@@ -1057,6 +1057,7 @@ asmlinkage void math_state_restore(struc=0A =
	struct task_struct *tsk =3D thread->task;=0A =0A 	/* NB. =
'clts' is done for us by Xen during virtual trap. */=0A+	__get_cpu_v=
ar(xen_x86_cr0) &=3D ~X86_CR0_TS;=0A 	if (!tsk_used_math(tsk))=0A 		=
init_fpu(tsk);=0A 	restore_fpu(tsk);=0A--- a/arch/x86_64/kernel/proces=
s-xen.c=0A+++ b/arch/x86_64/kernel/process-xen.c=0A@@ -574,6 +574,8 @@ =
__switch_to(struct task_struct *prev_p, =0A 	BUG_ON(mcl > _mcl + =
ARRAY_SIZE(_mcl));=0A 	if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl =
- _mcl, NULL)))=0A 		BUG();=0A+	if (_mcl->op =3D=3D =
__HYPERVISOR_fpu_taskswitch)=0A+		__get_cpu_var(xen_x86_cr0) =
|=3D X86_CR0_TS;=0A =0A 	/* =0A 	 * Switch DS and ES.=0A--- =
a/arch/x86_64/kernel/setup64-xen.c=0A+++ b/arch/x86_64/kernel/setup64-xen.c=
=0A@@ -126,6 +126,9 @@ void __init setup_per_cpu_areas(void)=0A } =0A =0A =
#ifdef CONFIG_XEN=0A+DEFINE_PER_CPU(unsigned long, xen_x86_cr0);=0A+EXPORT_=
PER_CPU_SYMBOL(xen_x86_cr0);=0A+=0A static void switch_pt(void)=0A {=0A 	=
xen_pt_switch(__pa_symbol(init_level4_pgt));=0A@@ -174,6 +177,7 @@ void =
pda_init(int cpu)=0A 	if (HYPERVISOR_set_segment_base(SEGBASE_GS_KERNEL,=
=0A 					(unsigned long)pda))=0A 		=
BUG();=0A+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();=0A =
#endif=0A 	pda->cpunumber =3D cpu; =0A 	pda->irqcount =3D =
-1;=0A--- a/arch/x86_64/kernel/traps-xen.c=0A+++ b/arch/x86_64/kernel/traps=
-xen.c=0A@@ -1075,8 +1075,9 @@ asmlinkage void __attribute__((weak)) mc=0A =
asmlinkage void math_state_restore(void)=0A {=0A 	struct task_struct =
*me =3D current;=0A-        /* clts(); */ /* 'clts' is done for us by Xen =
during virtual trap. */=0A =0A+	/* NB. 'clts' is done for us by Xen during =
virtual trap. */=0A+	__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS;=0A 	=
if (!used_math())=0A 		init_fpu(me);=0A 	restore_fpu_checkin=
g(&me->thread.i387.fxsave);=0A--- a/include/asm-i386/mach-xen/asm/system.h=
=0A+++ b/include/asm-i386/mach-xen/asm/system.h=0A@@ -2,8 +2,10 @@=0A =
#define __ASM_SYSTEM_H=0A =0A #include <linux/kernel.h>=0A+#include =
<linux/threads.h>=0A #include <asm/segment.h>=0A #include <asm/cpufeature.h=
>=0A+#include <asm/percpu.h>=0A #include <linux/bitops.h> /* for LOCK_PREFI=
X */=0A #include <asm/synch_bitops.h>=0A #include <asm/hypervisor.h>=0A@@ =
-90,15 +91,30 @@ __asm__ __volatile__ ("movw %%dx,%1\n\t"=0A #define =
savesegment(seg, value) \=0A 	asm volatile("mov %%" #seg ",%0":"=3Drm" =
(value))=0A =0A-#define read_cr0() ({ \=0A+DECLARE_PER_CPU(unsigned int, =
xen_x86_cr0);=0A+=0A+#define raw_read_cr0() ({ \=0A 	unsigned int =
__dummy; \=0A 	__asm__ __volatile__( \=0A 		"movl %%cr0,%0\n\t"=
 \=0A 		:"=3Dr" (__dummy)); \=0A 	__dummy; \=0A })=0A-#define=
 write_cr0(x) \=0A-	__asm__ __volatile__("movl %0,%%cr0": :"r" =
(x))=0A+#define read_cr0() __get_cpu_var(xen_x86_cr0)=0A+#define write_cr0(=
x) do { \=0A+	unsigned int x__ =3D (x); \=0A+	switch (x__ ^ __get_cpu_var=
(xen_x86_cr0)) { \=0A+	case 0: \=0A+		continue; \=0A+	case =
X86_CR0_TS: \=0A+		HYPERVISOR_fpu_taskswitch(!!(x__ & =
X86_CR0_TS)); \=0A+		break; \=0A+	default: \=0A+		=
__asm__ __volatile__("movl %0,%%cr0": :"r" (x__)); \=0A+		=
break; \=0A+	} \=0A+	__get_cpu_var(xen_x86_cr0) =3D x__; \=0A+} while =
(0)=0A =0A #define read_cr2() (current_vcpu_info()->arch.cr2)=0A #define =
write_cr2(x) \=0A@@ -142,8 +158,19 @@ __asm__ __volatile__ ("movw =
%%dx,%1\n\t"=0A /*=0A  * Clear and set 'TS' bit respectively=0A  */=0A-#def=
ine clts() (HYPERVISOR_fpu_taskswitch(0))=0A-#define stts() (HYPERVISOR_fpu=
_taskswitch(1))=0A+#define X86_CR0_TS 8=0A+#define clts() ({ \=0A+	if =
(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS) { \=0A+		HYPERVISOR_=
fpu_taskswitch(0); \=0A+		__get_cpu_var(xen_x86_cr0) &=3D =
~X86_CR0_TS; \=0A+	} \=0A+})=0A+#define stts() ({ \=0A+	if =
(!(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS)) { \=0A+		HYPERVISOR_=
fpu_taskswitch(1); \=0A+		__get_cpu_var(xen_x86_cr0) |=3D =
X86_CR0_TS; \=0A+	} \=0A+})=0A =0A #endif	/* __KERNEL__ */=0A =0A--- =
a/include/asm-x86_64/mach-xen/asm/system.h=0A+++ b/include/asm-x86_64/mach-=
xen/asm/system.h=0A@@ -7,7 +7,7 @@=0A =0A #include <asm/synch_bitops.h>=0A =
#include <asm/hypervisor.h>=0A-#include <xen/interface/arch-x86_64.h>=0A+#i=
nclude <asm/percpu.h>=0A =0A #ifdef __KERNEL__=0A =0A@@ -71,18 +71,41 @@ =
struct alt_instr {=0A /*=0A  * Clear and set 'TS' bit respectively=0A  =
*/=0A-#define clts() (HYPERVISOR_fpu_taskswitch(0))=0A+#define X86_CR0_TS =
8=0A+#define clts() ({ \=0A+	if (__get_cpu_var(xen_x86_cr0) & X86_CR0_TS=
) { \=0A+		HYPERVISOR_fpu_taskswitch(0); \=0A+		=
__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS; \=0A+	} \=0A+})=0A =
=0A-static inline unsigned long read_cr0(void)=0A+DECLARE_PER_CPU(unsigned =
long, xen_x86_cr0);=0A+=0A+static inline unsigned long raw_read_cr0(void)=
=0A { =0A 	unsigned long cr0;=0A 	asm volatile("movq %%cr0,%0" : =
"=3Dr" (cr0));=0A 	return cr0;=0A } =0A =0A+static inline unsigned =
long read_cr0(void)=0A+{=0A+	return __get_cpu_var(xen_x86_cr0);=0A+}=0A+=
=0A static inline void write_cr0(unsigned long val) =0A { =0A-	asm =
volatile("movq %0,%%cr0" :: "r" (val));=0A+	switch (val ^ __get_cpu_var=
(xen_x86_cr0)) {=0A+	case 0:=0A+		return;=0A+	case =
X86_CR0_TS:=0A+		HYPERVISOR_fpu_taskswitch(!!(val & X86_CR0_TS));=0A=
+		break;=0A+	default:=0A+		asm volatile("movq =
%0,%%cr0" :: "r" (val));=0A+		break;=0A+	}=0A+	__get_cpu_v=
ar(xen_x86_cr0) =3D val;=0A } =0A =0A #define read_cr3() ({ \=0A@@ -103,7 =
+126,12 @@ static inline void write_cr4(unsigned lo=0A 	asm volatile("movq =
%0,%%cr4" :: "r" (val));=0A } =0A =0A-#define stts() (HYPERVISOR_fpu_tasksw=
itch(1))=0A+#define stts() ({ \=0A+	if (!(__get_cpu_var(xen_x86_cr0) & =
X86_CR0_TS)) { \=0A+		HYPERVISOR_fpu_taskswitch(1); \=0A+		=
__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; \=0A+	} \=0A+})=0A =0A =
#define wbinvd() \=0A 	__asm__ __volatile__ ("wbinvd": : :"memory");=0A
--=__PartFFD1508F.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

--=__PartFFD1508F.0__=--


From xen-devel-bounces@lists.xen.org Fri Jun 29 14:24:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1Skc6w-0003hR-6i; Fri, 29 Jun 2012 14:23: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 1Skc6u-0003hC-FN
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:23:48 +0000
Received: from [85.158.138.51:23753] by server-3.bemta-3.messagelabs.com id
	7F/8B-26490-37ABDEF4; Fri, 29 Jun 2012 14:23:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340979826!22078620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 29 Jun 2012 14:23:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	29 Jun 2012 14:23:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 15:23:47 +0100
Message-Id: <4FEDD6BF020000780008CDE5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 15:24:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFD1508F.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: improve CR0 read/write
	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>
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.

--=__PartFFD1508F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the only bit in CR0 permitted to be changed by PV guests being TS,
optimize the handling towards that: Keep a cached value in a per-CPU
variable, and issue HYPERVISOR_fpu_taskswitch hypercalls for updates in
all but the unusual case should something in the system still try to
modify another bit (the attempt of which would then be logged by the
hypervisor).

This removes the need to have the hypervisor emulate MOV to/from CR0
instructions in all halfway frequently executed code paths.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/kernel/cpu/common-xen.c
+++ b/arch/i386/kernel/cpu/common-xen.c
@@ -32,6 +32,9 @@ EXPORT_PER_CPU_SYMBOL(cpu_gdt_descr);
 #ifndef CONFIG_XEN
 DEFINE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);
 EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack);
+#else
+DEFINE_PER_CPU(unsigned int, xen_x86_cr0);
+EXPORT_PER_CPU_SYMBOL(xen_x86_cr0);
 #endif
=20
 static int cachesize_override __cpuinitdata =3D -1;
@@ -681,6 +684,7 @@ old_gdt:
 	cpu_gdt_descr->size =3D GDT_SIZE - 1;
  	cpu_gdt_descr->address =3D (unsigned long)gdt;
 #else
+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();
 	if (cpu =3D=3D 0 && cpu_gdt_descr->address =3D=3D 0) {
 		gdt =3D (struct desc_struct *)alloc_bootmem_pages(PAGE_SIZE=
);
 		/* alloc_bootmem_pages panics on failure, so no check */
--- a/arch/i386/kernel/process-xen.c
+++ b/arch/i386/kernel/process-xen.c
@@ -641,6 +641,8 @@ struct task_struct fastcall * __switch_t
 	BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));
 	if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL)))
 		BUG();
+	if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch)
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;
=20
 	/*
 	 * Restore %fs and %gs if needed.
--- a/arch/i386/kernel/traps-xen.c
+++ b/arch/i386/kernel/traps-xen.c
@@ -1057,6 +1057,7 @@ asmlinkage void math_state_restore(struc
 	struct task_struct *tsk =3D thread->task;
=20
 	/* NB. 'clts' is done for us by Xen during virtual trap. */
+	__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS;
 	if (!tsk_used_math(tsk))
 		init_fpu(tsk);
 	restore_fpu(tsk);
--- a/arch/x86_64/kernel/process-xen.c
+++ b/arch/x86_64/kernel/process-xen.c
@@ -574,6 +574,8 @@ __switch_to(struct task_struct *prev_p,=20
 	BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));
 	if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL)))
 		BUG();
+	if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch)
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;
=20
 	/*=20
 	 * Switch DS and ES.
--- a/arch/x86_64/kernel/setup64-xen.c
+++ b/arch/x86_64/kernel/setup64-xen.c
@@ -126,6 +126,9 @@ void __init setup_per_cpu_areas(void)
 }=20
=20
 #ifdef CONFIG_XEN
+DEFINE_PER_CPU(unsigned long, xen_x86_cr0);
+EXPORT_PER_CPU_SYMBOL(xen_x86_cr0);
+
 static void switch_pt(void)
 {
 	xen_pt_switch(__pa_symbol(init_level4_pgt));
@@ -174,6 +177,7 @@ void pda_init(int cpu)
 	if (HYPERVISOR_set_segment_base(SEGBASE_GS_KERNEL,
 					(unsigned long)pda))
 		BUG();
+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();
 #endif
 	pda->cpunumber =3D cpu;=20
 	pda->irqcount =3D -1;
--- a/arch/x86_64/kernel/traps-xen.c
+++ b/arch/x86_64/kernel/traps-xen.c
@@ -1075,8 +1075,9 @@ asmlinkage void __attribute__((weak)) mc
 asmlinkage void math_state_restore(void)
 {
 	struct task_struct *me =3D current;
-        /* clts(); */ /* 'clts' is done for us by Xen during virtual =
trap. */
=20
+	/* NB. 'clts' is done for us by Xen during virtual trap. */
+	__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS;
 	if (!used_math())
 		init_fpu(me);
 	restore_fpu_checking(&me->thread.i387.fxsave);
--- a/include/asm-i386/mach-xen/asm/system.h
+++ b/include/asm-i386/mach-xen/asm/system.h
@@ -2,8 +2,10 @@
 #define __ASM_SYSTEM_H
=20
 #include <linux/kernel.h>
+#include <linux/threads.h>
 #include <asm/segment.h>
 #include <asm/cpufeature.h>
+#include <asm/percpu.h>
 #include <linux/bitops.h> /* for LOCK_PREFIX */
 #include <asm/synch_bitops.h>
 #include <asm/hypervisor.h>
@@ -90,15 +91,30 @@ __asm__ __volatile__ ("movw %%dx,%1\n\t"
 #define savesegment(seg, value) \
 	asm volatile("mov %%" #seg ",%0":"=3Drm" (value))
=20
-#define read_cr0() ({ \
+DECLARE_PER_CPU(unsigned int, xen_x86_cr0);
+
+#define raw_read_cr0() ({ \
 	unsigned int __dummy; \
 	__asm__ __volatile__( \
 		"movl %%cr0,%0\n\t" \
 		:"=3Dr" (__dummy)); \
 	__dummy; \
 })
-#define write_cr0(x) \
-	__asm__ __volatile__("movl %0,%%cr0": :"r" (x))
+#define read_cr0() __get_cpu_var(xen_x86_cr0)
+#define write_cr0(x) do { \
+	unsigned int x__ =3D (x); \
+	switch (x__ ^ __get_cpu_var(xen_x86_cr0)) { \
+	case 0: \
+		continue; \
+	case X86_CR0_TS: \
+		HYPERVISOR_fpu_taskswitch(!!(x__ & X86_CR0_TS)); \
+		break; \
+	default: \
+		__asm__ __volatile__("movl %0,%%cr0": :"r" (x__)); \
+		break; \
+	} \
+	__get_cpu_var(xen_x86_cr0) =3D x__; \
+} while (0)
=20
 #define read_cr2() (current_vcpu_info()->arch.cr2)
 #define write_cr2(x) \
@@ -142,8 +158,19 @@ __asm__ __volatile__ ("movw %%dx,%1\n\t"
 /*
  * Clear and set 'TS' bit respectively
  */
-#define clts() (HYPERVISOR_fpu_taskswitch(0))
-#define stts() (HYPERVISOR_fpu_taskswitch(1))
+#define X86_CR0_TS 8
+#define clts() ({ \
+	if (__get_cpu_var(xen_x86_cr0) & X86_CR0_TS) { \
+		HYPERVISOR_fpu_taskswitch(0); \
+		__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS; \
+	} \
+})
+#define stts() ({ \
+	if (!(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS)) { \
+		HYPERVISOR_fpu_taskswitch(1); \
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; \
+	} \
+})
=20
 #endif	/* __KERNEL__ */
=20
--- a/include/asm-x86_64/mach-xen/asm/system.h
+++ b/include/asm-x86_64/mach-xen/asm/system.h
@@ -7,7 +7,7 @@
=20
 #include <asm/synch_bitops.h>
 #include <asm/hypervisor.h>
-#include <xen/interface/arch-x86_64.h>
+#include <asm/percpu.h>
=20
 #ifdef __KERNEL__
=20
@@ -71,18 +71,41 @@ struct alt_instr {
 /*
  * Clear and set 'TS' bit respectively
  */
-#define clts() (HYPERVISOR_fpu_taskswitch(0))
+#define X86_CR0_TS 8
+#define clts() ({ \
+	if (__get_cpu_var(xen_x86_cr0) & X86_CR0_TS) { \
+		HYPERVISOR_fpu_taskswitch(0); \
+		__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS; \
+	} \
+})
=20
-static inline unsigned long read_cr0(void)
+DECLARE_PER_CPU(unsigned long, xen_x86_cr0);
+
+static inline unsigned long raw_read_cr0(void)
 {=20
 	unsigned long cr0;
 	asm volatile("movq %%cr0,%0" : "=3Dr" (cr0));
 	return cr0;
 }=20
=20
+static inline unsigned long read_cr0(void)
+{
+	return __get_cpu_var(xen_x86_cr0);
+}
+
 static inline void write_cr0(unsigned long val)=20
 {=20
-	asm volatile("movq %0,%%cr0" :: "r" (val));
+	switch (val ^ __get_cpu_var(xen_x86_cr0)) {
+	case 0:
+		return;
+	case X86_CR0_TS:
+		HYPERVISOR_fpu_taskswitch(!!(val & X86_CR0_TS));
+		break;
+	default:
+		asm volatile("movq %0,%%cr0" :: "r" (val));
+		break;
+	}
+	__get_cpu_var(xen_x86_cr0) =3D val;
 }=20
=20
 #define read_cr3() ({ \
@@ -103,7 +126,12 @@ static inline void write_cr4(unsigned lo
 	asm volatile("movq %0,%%cr4" :: "r" (val));
 }=20
=20
-#define stts() (HYPERVISOR_fpu_taskswitch(1))
+#define stts() ({ \
+	if (!(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS)) { \
+		HYPERVISOR_fpu_taskswitch(1); \
+		__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; \
+	} \
+})
=20
 #define wbinvd() \
 	__asm__ __volatile__ ("wbinvd": : :"memory");



--=__PartFFD1508F.0__=
Content-Type: text/plain; name="xen-x86-cr0.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-x86-cr0.patch"

x86: improve CR0 read/write handling=0A=0AWith the only bit in CR0 =
permitted to be changed by PV guests being TS,=0Aoptimize the handling =
towards that: Keep a cached value in a per-CPU=0Avariable, and issue =
HYPERVISOR_fpu_taskswitch hypercalls for updates in=0Aall but the unusual =
case should something in the system still try to=0Amodify another bit (the =
attempt of which would then be logged by the=0Ahypervisor).=0A=0AThis =
removes the need to have the hypervisor emulate MOV to/from CR0=0Ainstructi=
ons in all halfway frequently executed code paths.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/arch/i386/kernel/cpu/common-xen.c=0A=
+++ b/arch/i386/kernel/cpu/common-xen.c=0A@@ -32,6 +32,9 @@ EXPORT_PER_CPU_=
SYMBOL(cpu_gdt_descr);=0A #ifndef CONFIG_XEN=0A DEFINE_PER_CPU(unsigned =
char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);=0A EXPORT_PER_CPU_SYMBOL(cpu_=
16bit_stack);=0A+#else=0A+DEFINE_PER_CPU(unsigned int, xen_x86_cr0);=0A+EXP=
ORT_PER_CPU_SYMBOL(xen_x86_cr0);=0A #endif=0A =0A static int cachesize_over=
ride __cpuinitdata =3D -1;=0A@@ -681,6 +684,7 @@ old_gdt:=0A 	cpu_gdt_des=
cr->size =3D GDT_SIZE - 1;=0A  	cpu_gdt_descr->address =3D (unsigned =
long)gdt;=0A #else=0A+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();=0A 	=
if (cpu =3D=3D 0 && cpu_gdt_descr->address =3D=3D 0) {=0A 		=
gdt =3D (struct desc_struct *)alloc_bootmem_pages(PAGE_SIZE);=0A 		=
/* alloc_bootmem_pages panics on failure, so no check */=0A--- a/arch/i386/=
kernel/process-xen.c=0A+++ b/arch/i386/kernel/process-xen.c=0A@@ -641,6 =
+641,8 @@ struct task_struct fastcall * __switch_t=0A 	BUG_ON(mcl > _mcl =
+ ARRAY_SIZE(_mcl));=0A 	if (unlikely(HYPERVISOR_multicall_check(_mc=
l, mcl - _mcl, NULL)))=0A 		BUG();=0A+	if (_mcl->op =
=3D=3D __HYPERVISOR_fpu_taskswitch)=0A+		__get_cpu_var(xen_x86_cr0) =
|=3D X86_CR0_TS;=0A =0A 	/*=0A 	 * Restore %fs and %gs if =
needed.=0A--- a/arch/i386/kernel/traps-xen.c=0A+++ b/arch/i386/kernel/traps=
-xen.c=0A@@ -1057,6 +1057,7 @@ asmlinkage void math_state_restore(struc=0A =
	struct task_struct *tsk =3D thread->task;=0A =0A 	/* NB. =
'clts' is done for us by Xen during virtual trap. */=0A+	__get_cpu_v=
ar(xen_x86_cr0) &=3D ~X86_CR0_TS;=0A 	if (!tsk_used_math(tsk))=0A 		=
init_fpu(tsk);=0A 	restore_fpu(tsk);=0A--- a/arch/x86_64/kernel/proces=
s-xen.c=0A+++ b/arch/x86_64/kernel/process-xen.c=0A@@ -574,6 +574,8 @@ =
__switch_to(struct task_struct *prev_p, =0A 	BUG_ON(mcl > _mcl + =
ARRAY_SIZE(_mcl));=0A 	if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl =
- _mcl, NULL)))=0A 		BUG();=0A+	if (_mcl->op =3D=3D =
__HYPERVISOR_fpu_taskswitch)=0A+		__get_cpu_var(xen_x86_cr0) =
|=3D X86_CR0_TS;=0A =0A 	/* =0A 	 * Switch DS and ES.=0A--- =
a/arch/x86_64/kernel/setup64-xen.c=0A+++ b/arch/x86_64/kernel/setup64-xen.c=
=0A@@ -126,6 +126,9 @@ void __init setup_per_cpu_areas(void)=0A } =0A =0A =
#ifdef CONFIG_XEN=0A+DEFINE_PER_CPU(unsigned long, xen_x86_cr0);=0A+EXPORT_=
PER_CPU_SYMBOL(xen_x86_cr0);=0A+=0A static void switch_pt(void)=0A {=0A 	=
xen_pt_switch(__pa_symbol(init_level4_pgt));=0A@@ -174,6 +177,7 @@ void =
pda_init(int cpu)=0A 	if (HYPERVISOR_set_segment_base(SEGBASE_GS_KERNEL,=
=0A 					(unsigned long)pda))=0A 		=
BUG();=0A+	__get_cpu_var(xen_x86_cr0) =3D raw_read_cr0();=0A =
#endif=0A 	pda->cpunumber =3D cpu; =0A 	pda->irqcount =3D =
-1;=0A--- a/arch/x86_64/kernel/traps-xen.c=0A+++ b/arch/x86_64/kernel/traps=
-xen.c=0A@@ -1075,8 +1075,9 @@ asmlinkage void __attribute__((weak)) mc=0A =
asmlinkage void math_state_restore(void)=0A {=0A 	struct task_struct =
*me =3D current;=0A-        /* clts(); */ /* 'clts' is done for us by Xen =
during virtual trap. */=0A =0A+	/* NB. 'clts' is done for us by Xen during =
virtual trap. */=0A+	__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS;=0A 	=
if (!used_math())=0A 		init_fpu(me);=0A 	restore_fpu_checkin=
g(&me->thread.i387.fxsave);=0A--- a/include/asm-i386/mach-xen/asm/system.h=
=0A+++ b/include/asm-i386/mach-xen/asm/system.h=0A@@ -2,8 +2,10 @@=0A =
#define __ASM_SYSTEM_H=0A =0A #include <linux/kernel.h>=0A+#include =
<linux/threads.h>=0A #include <asm/segment.h>=0A #include <asm/cpufeature.h=
>=0A+#include <asm/percpu.h>=0A #include <linux/bitops.h> /* for LOCK_PREFI=
X */=0A #include <asm/synch_bitops.h>=0A #include <asm/hypervisor.h>=0A@@ =
-90,15 +91,30 @@ __asm__ __volatile__ ("movw %%dx,%1\n\t"=0A #define =
savesegment(seg, value) \=0A 	asm volatile("mov %%" #seg ",%0":"=3Drm" =
(value))=0A =0A-#define read_cr0() ({ \=0A+DECLARE_PER_CPU(unsigned int, =
xen_x86_cr0);=0A+=0A+#define raw_read_cr0() ({ \=0A 	unsigned int =
__dummy; \=0A 	__asm__ __volatile__( \=0A 		"movl %%cr0,%0\n\t"=
 \=0A 		:"=3Dr" (__dummy)); \=0A 	__dummy; \=0A })=0A-#define=
 write_cr0(x) \=0A-	__asm__ __volatile__("movl %0,%%cr0": :"r" =
(x))=0A+#define read_cr0() __get_cpu_var(xen_x86_cr0)=0A+#define write_cr0(=
x) do { \=0A+	unsigned int x__ =3D (x); \=0A+	switch (x__ ^ __get_cpu_var=
(xen_x86_cr0)) { \=0A+	case 0: \=0A+		continue; \=0A+	case =
X86_CR0_TS: \=0A+		HYPERVISOR_fpu_taskswitch(!!(x__ & =
X86_CR0_TS)); \=0A+		break; \=0A+	default: \=0A+		=
__asm__ __volatile__("movl %0,%%cr0": :"r" (x__)); \=0A+		=
break; \=0A+	} \=0A+	__get_cpu_var(xen_x86_cr0) =3D x__; \=0A+} while =
(0)=0A =0A #define read_cr2() (current_vcpu_info()->arch.cr2)=0A #define =
write_cr2(x) \=0A@@ -142,8 +158,19 @@ __asm__ __volatile__ ("movw =
%%dx,%1\n\t"=0A /*=0A  * Clear and set 'TS' bit respectively=0A  */=0A-#def=
ine clts() (HYPERVISOR_fpu_taskswitch(0))=0A-#define stts() (HYPERVISOR_fpu=
_taskswitch(1))=0A+#define X86_CR0_TS 8=0A+#define clts() ({ \=0A+	if =
(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS) { \=0A+		HYPERVISOR_=
fpu_taskswitch(0); \=0A+		__get_cpu_var(xen_x86_cr0) &=3D =
~X86_CR0_TS; \=0A+	} \=0A+})=0A+#define stts() ({ \=0A+	if =
(!(__get_cpu_var(xen_x86_cr0) & X86_CR0_TS)) { \=0A+		HYPERVISOR_=
fpu_taskswitch(1); \=0A+		__get_cpu_var(xen_x86_cr0) |=3D =
X86_CR0_TS; \=0A+	} \=0A+})=0A =0A #endif	/* __KERNEL__ */=0A =0A--- =
a/include/asm-x86_64/mach-xen/asm/system.h=0A+++ b/include/asm-x86_64/mach-=
xen/asm/system.h=0A@@ -7,7 +7,7 @@=0A =0A #include <asm/synch_bitops.h>=0A =
#include <asm/hypervisor.h>=0A-#include <xen/interface/arch-x86_64.h>=0A+#i=
nclude <asm/percpu.h>=0A =0A #ifdef __KERNEL__=0A =0A@@ -71,18 +71,41 @@ =
struct alt_instr {=0A /*=0A  * Clear and set 'TS' bit respectively=0A  =
*/=0A-#define clts() (HYPERVISOR_fpu_taskswitch(0))=0A+#define X86_CR0_TS =
8=0A+#define clts() ({ \=0A+	if (__get_cpu_var(xen_x86_cr0) & X86_CR0_TS=
) { \=0A+		HYPERVISOR_fpu_taskswitch(0); \=0A+		=
__get_cpu_var(xen_x86_cr0) &=3D ~X86_CR0_TS; \=0A+	} \=0A+})=0A =
=0A-static inline unsigned long read_cr0(void)=0A+DECLARE_PER_CPU(unsigned =
long, xen_x86_cr0);=0A+=0A+static inline unsigned long raw_read_cr0(void)=
=0A { =0A 	unsigned long cr0;=0A 	asm volatile("movq %%cr0,%0" : =
"=3Dr" (cr0));=0A 	return cr0;=0A } =0A =0A+static inline unsigned =
long read_cr0(void)=0A+{=0A+	return __get_cpu_var(xen_x86_cr0);=0A+}=0A+=
=0A static inline void write_cr0(unsigned long val) =0A { =0A-	asm =
volatile("movq %0,%%cr0" :: "r" (val));=0A+	switch (val ^ __get_cpu_var=
(xen_x86_cr0)) {=0A+	case 0:=0A+		return;=0A+	case =
X86_CR0_TS:=0A+		HYPERVISOR_fpu_taskswitch(!!(val & X86_CR0_TS));=0A=
+		break;=0A+	default:=0A+		asm volatile("movq =
%0,%%cr0" :: "r" (val));=0A+		break;=0A+	}=0A+	__get_cpu_v=
ar(xen_x86_cr0) =3D val;=0A } =0A =0A #define read_cr3() ({ \=0A@@ -103,7 =
+126,12 @@ static inline void write_cr4(unsigned lo=0A 	asm volatile("movq =
%0,%%cr4" :: "r" (val));=0A } =0A =0A-#define stts() (HYPERVISOR_fpu_tasksw=
itch(1))=0A+#define stts() ({ \=0A+	if (!(__get_cpu_var(xen_x86_cr0) & =
X86_CR0_TS)) { \=0A+		HYPERVISOR_fpu_taskswitch(1); \=0A+		=
__get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; \=0A+	} \=0A+})=0A =0A =
#define wbinvd() \=0A 	__asm__ __volatile__ ("wbinvd": : :"memory");=0A
--=__PartFFD1508F.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

--=__PartFFD1508F.0__=--


From xen-devel-bounces@lists.xen.org Fri Jun 29 14:29:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcC6-00045G-9j; Fri, 29 Jun 2012 14:29:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SkcC4-00044w-Tz
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:29:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340980141!9291068!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22139 invoked from network); 29 Jun 2012 14:29:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	29 Jun 2012 14:29:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 15:29:02 +0100
Message-Id: <4FEDD7FB020000780008CDF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 15:29:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBA9415CB.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: make xor block handling
	uniform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartBA9415CB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Irrespective of the elimination of raw CR0 reads and writes, any of the
methods requiring access to the floating point/XMM state still perform
worse than the integer register based ones (at least as long as the
virtual CR0.TS is set upon entry). Thus un-define XOR_SELECT_TEMPLATE
in both 32- and 64-bit.

On 64-bit additionally make the integer register based routines
available for selection in the first place, and remove the duplicate
code in the Xen specific header in favor of a small adjustment to the
native one (using read_cr0()/clts()/write_cr0() instead of open coded
accesses in the inline assembly).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- /dev/null
+++ b/include/asm-i386/mach-xen/asm/xor.h
@@ -0,0 +1,3 @@
+#include_next <asm/xor.h>
+
+#undef XOR_SELECT_TEMPLATE
--- a/include/asm-x86_64/mach-xen/asm/xor.h
+++ b/include/asm-x86_64/mach-xen/asm/xor.h
@@ -1,328 +1,17 @@
-/*
- * x86-64 changes / gcc fixes from Andi Kleen.=20
- * Copyright 2002 Andi Kleen, SuSE Labs.
- *
- * This hasn't been optimized for the hammer yet, but there are likely
- * no advantages to be gotten from x86-64 here anyways.
- */
+#include_next <asm/xor.h>
=20
-typedef struct { unsigned long a,b; } __attribute__((aligned(16))) =
xmm_store_t;
+#undef XOR_SELECT_TEMPLATE
=20
-/* Doesn't use gcc to save the XMM registers, because there is no easy =
way to=20
-   tell it to do a clts before the register saving. */
-#define XMMS_SAVE do {				\
-	preempt_disable();			\
-	if (!(current_thread_info()->status & TS_USEDFPU))	\
-		clts();				\
-	__asm__ __volatile__ ( 			\
-		"movups %%xmm0,(%1)	;\n\t"	\
-		"movups %%xmm1,0x10(%1)	;\n\t"	\
-		"movups %%xmm2,0x20(%1)	;\n\t"	\
-		"movups %%xmm3,0x30(%1)	;\n\t"	\
-		: "=3D&r" (cr0)			\
-		: "r" (xmm_save) 		\
-		: "memory");			\
-} while(0)
-
-#define XMMS_RESTORE do {			\
-	asm volatile (				\
-		"sfence			;\n\t"	\
-		"movups (%1),%%xmm0	;\n\t"	\
-		"movups 0x10(%1),%%xmm1	;\n\t"	\
-		"movups 0x20(%1),%%xmm2	;\n\t"	\
-		"movups 0x30(%1),%%xmm3	;\n\t"	\
-		:				\
-		: "r" (cr0), "r" (xmm_save)	\
-		: "memory");			\
-	if (!(current_thread_info()->status & TS_USEDFPU))	\
-		stts();				\
-	preempt_enable();			\
-} while(0)
-
-#define OFFS(x)		"16*("#x")"
-#define PF_OFFS(x)	"256+16*("#x")"
-#define	PF0(x)		"	prefetchnta "PF_OFFS(x)"(%[p1])		=
;\n"
-#define LD(x,y)		"       movaps   "OFFS(x)"(%[p1]), =
%%xmm"#y"	;\n"
-#define ST(x,y)		"       movaps %%xmm"#y",   "OFFS(x)"(%[p1]=
)	;\n"
-#define PF1(x)		"	prefetchnta "PF_OFFS(x)"(%[p2])		=
;\n"
-#define PF2(x)		"	prefetchnta "PF_OFFS(x)"(%[p3])		=
;\n"
-#define PF3(x)		"	prefetchnta "PF_OFFS(x)"(%[p4])		=
;\n"
-#define PF4(x)		"	prefetchnta "PF_OFFS(x)"(%[p5])		=
;\n"
-#define PF5(x)		"	prefetchnta "PF_OFFS(x)"(%[p6])		=
;\n"
-#define XO1(x,y)	"       xorps   "OFFS(x)"(%[p2]), %%xmm"#y"	=
;\n"
-#define XO2(x,y)	"       xorps   "OFFS(x)"(%[p3]), %%xmm"#y"	=
;\n"
-#define XO3(x,y)	"       xorps   "OFFS(x)"(%[p4]), %%xmm"#y"	=
;\n"
-#define XO4(x,y)	"       xorps   "OFFS(x)"(%[p5]), %%xmm"#y"	=
;\n"
-#define XO5(x,y)	"       xorps   "OFFS(x)"(%[p6]), %%xmm"#y"	=
;\n"
-
-
-static void
-xor_sse_2(unsigned long bytes, unsigned long *p1, unsigned long *p2)
-{
-        unsigned int lines =3D bytes >> 8;
-	unsigned long cr0;
-	xmm_store_t xmm_save[4];
-
-	XMMS_SAVE;
-
-        asm volatile (
-#undef BLOCK
-#define BLOCK(i) \
-		LD(i,0)					\
-			LD(i+1,1)			\
-		PF1(i)					\
-				PF1(i+2)		\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]           ;\n"
-		"		decl %[cnt] ; jnz 1b"
-	: [p1] "+r" (p1), [p2] "+r" (p2), [cnt] "+r" (lines)
-	: [inc] "r" (256UL)=20
-        : "memory");
-
-	XMMS_RESTORE;
-}
-
-static void
-xor_sse_3(unsigned long bytes, unsigned long *p1, unsigned long *p2,
-	  unsigned long *p3)
-{
-	unsigned int lines =3D bytes >> 8;
-	xmm_store_t xmm_save[4];
-	unsigned long cr0;
-
-	XMMS_SAVE;
-
-        __asm__ __volatile__ (
-#undef BLOCK
-#define BLOCK(i) \
-		PF1(i)					\
-				PF1(i+2)		\
-		LD(i,0)					\
-			LD(i+1,1)			\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF2(i)					\
-				PF2(i+2)		\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		XO2(i,0)				\
-			XO2(i+1,1)			\
-				XO2(i+2,2)		\
-					XO2(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]          ;\n"
-        "       addq %[inc], %[p3]           ;\n"
-		"		decl %[cnt] ; jnz 1b"
-	: [cnt] "+r" (lines),
-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3)
-	: [inc] "r" (256UL)
-	: "memory");=20
-	XMMS_RESTORE;
-}
-
-static void
-xor_sse_4(unsigned long bytes, unsigned long *p1, unsigned long *p2,
-	  unsigned long *p3, unsigned long *p4)
-{
-	unsigned int lines =3D bytes >> 8;
-	xmm_store_t xmm_save[4];=20
-	unsigned long cr0;
-
-	XMMS_SAVE;
-
-        __asm__ __volatile__ (
-#undef BLOCK
-#define BLOCK(i) \
-		PF1(i)					\
-				PF1(i+2)		\
-		LD(i,0)					\
-			LD(i+1,1)			\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF2(i)					\
-				PF2(i+2)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		PF3(i)					\
-				PF3(i+2)		\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO2(i,0)				\
-			XO2(i+1,1)			\
-				XO2(i+2,2)		\
-					XO2(i+3,3)	\
-		XO3(i,0)				\
-			XO3(i+1,1)			\
-				XO3(i+2,2)		\
-					XO3(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]           ;\n"
-        "       addq %[inc], %[p3]           ;\n"
-        "       addq %[inc], %[p4]           ;\n"
-	"	decl %[cnt] ; jnz 1b"
-	: [cnt] "+c" (lines),
-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] "+r" (p4)
-	: [inc] "r" (256UL)
-        : "memory" );
-
-	XMMS_RESTORE;
-}
-
-static void
-xor_sse_5(unsigned long bytes, unsigned long *p1, unsigned long *p2,
-	  unsigned long *p3, unsigned long *p4, unsigned long *p5)
-{
-        unsigned int lines =3D bytes >> 8;
-	xmm_store_t xmm_save[4];
-	unsigned long cr0;
-
-	XMMS_SAVE;
-
-        __asm__ __volatile__ (
-#undef BLOCK
-#define BLOCK(i) \
-		PF1(i)					\
-				PF1(i+2)		\
-		LD(i,0)					\
-			LD(i+1,1)			\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF2(i)					\
-				PF2(i+2)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		PF3(i)					\
-				PF3(i+2)		\
-		XO2(i,0)				\
-			XO2(i+1,1)			\
-				XO2(i+2,2)		\
-					XO2(i+3,3)	\
-		PF4(i)					\
-				PF4(i+2)		\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO3(i,0)				\
-			XO3(i+1,1)			\
-				XO3(i+2,2)		\
-					XO3(i+3,3)	\
-		XO4(i,0)				\
-			XO4(i+1,1)			\
-				XO4(i+2,2)		\
-					XO4(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]           ;\n"
-        "       addq %[inc], %[p3]           ;\n"
-        "       addq %[inc], %[p4]           ;\n"
-        "       addq %[inc], %[p5]           ;\n"
-	"	decl %[cnt] ; jnz 1b"
-	: [cnt] "+c" (lines),
-  	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] "+r" =
(p4),=20
-	  [p5] "+r" (p5)
-	: [inc] "r" (256UL)
-	: "memory");
-
-	XMMS_RESTORE;
-}
-
-static struct xor_block_template xor_block_sse =3D {
-        .name =3D "generic_sse",
-        .do_2 =3D xor_sse_2,
-        .do_3 =3D xor_sse_3,
-        .do_4 =3D xor_sse_4,
-        .do_5 =3D xor_sse_5,
-};
+/* Also try the generic routines.  */
+#undef XOR_TRY_TEMPLATES
+#include <asm-generic/xor.h>
=20
 #undef XOR_TRY_TEMPLATES
-#define XOR_TRY_TEMPLATES				\
-	do {						\
+#define XOR_TRY_TEMPLATES			\
+	do {					\
+		xor_speed(&xor_block_8regs);	\
+		xor_speed(&xor_block_8regs_p);	\
+		xor_speed(&xor_block_32regs);	\
+		xor_speed(&xor_block_32regs_p);	\
 		xor_speed(&xor_block_sse);	\
 	} while (0)
-
-/* We force the use of the SSE xor block because it can write around L2.
-   We may also be able to load into the L1 only depending on how the cpu
-   deals with a load to a line that is being prefetched.  */
-#define XOR_SELECT_TEMPLATE(FASTEST) (&xor_block_sse)
--- a/include/asm-x86_64/xor.h
+++ b/include/asm-x86_64/xor.h
@@ -39,14 +39,14 @@ typedef struct { unsigned long a,b; } __
    tell it to do a clts before the register saving. */
 #define XMMS_SAVE do {				\
 	preempt_disable();			\
+	cr0 =3D read_cr0();			\
+	clts();					\
 	asm volatile (				\
-		"movq %%cr0,%0		;\n\t"	\
-		"clts			;\n\t"	\
 		"movups %%xmm0,(%1)	;\n\t"	\
 		"movups %%xmm1,0x10(%1)	;\n\t"	\
 		"movups %%xmm2,0x20(%1)	;\n\t"	\
 		"movups %%xmm3,0x30(%1)	;\n\t"	\
-		: "=3D&r" (cr0)			\
+		: "+r" (cr0)			\
 		: "r" (xmm_save) 		\
 		: "memory");			\
 } while(0)
@@ -58,10 +58,10 @@ typedef struct { unsigned long a,b; } __
 		"movups 0x10(%1),%%xmm1	;\n\t"	\
 		"movups 0x20(%1),%%xmm2	;\n\t"	\
 		"movups 0x30(%1),%%xmm3	;\n\t"	\
-		"movq 	%0,%%cr0	;\n\t"	\
 		:				\
 		: "r" (cr0), "r" (xmm_save)	\
 		: "memory");			\
+	write_cr0(cr0);				\
 	preempt_enable();			\
 } while(0)
=20



--=__PartBA9415CB.0__=
Content-Type: text/plain; name="xen-x86-xor-unify.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-x86-xor-unify.patch"

x86: make xor block handling uniform=0A=0AIrrespective of the elimination =
of raw CR0 reads and writes, any of the=0Amethods requiring access to the =
floating point/XMM state still perform=0Aworse than the integer register =
based ones (at least as long as the=0Avirtual CR0.TS is set upon entry). =
Thus un-define XOR_SELECT_TEMPLATE=0Ain both 32- and 64-bit.=0A=0AOn =
64-bit additionally make the integer register based routines=0Aavailable =
for selection in the first place, and remove the duplicate=0Acode in the =
Xen specific header in favor of a small adjustment to the=0Anative one =
(using read_cr0()/clts()/write_cr0() instead of open coded=0Aaccesses in =
the inline assembly).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- /dev/null=0A+++ b/include/asm-i386/mach-xen/asm/xor.h=0A@@ -0,0 =
+1,3 @@=0A+#include_next <asm/xor.h>=0A+=0A+#undef XOR_SELECT_TEMPLATE=0A--=
- a/include/asm-x86_64/mach-xen/asm/xor.h=0A+++ b/include/asm-x86_64/mach-x=
en/asm/xor.h=0A@@ -1,328 +1,17 @@=0A-/*=0A- * x86-64 changes / gcc fixes =
from Andi Kleen. =0A- * Copyright 2002 Andi Kleen, SuSE Labs.=0A- *=0A- * =
This hasn't been optimized for the hammer yet, but there are likely=0A- * =
no advantages to be gotten from x86-64 here anyways.=0A- */=0A+#include_nex=
t <asm/xor.h>=0A =0A-typedef struct { unsigned long a,b; } __attribute__((a=
ligned(16))) xmm_store_t;=0A+#undef XOR_SELECT_TEMPLATE=0A =0A-/* Doesn't =
use gcc to save the XMM registers, because there is no easy way to =0A-   =
tell it to do a clts before the register saving. */=0A-#define XMMS_SAVE =
do {				\=0A-	preempt_disable();			=
\=0A-	if (!(current_thread_info()->status & TS_USEDFPU))	\=0A-		=
clts();				\=0A-	__asm__ __volatile__ ( 			=
\=0A-		"movups %%xmm0,(%1)	;\n\t"	\=0A-		"movups =
%%xmm1,0x10(%1)	;\n\t"	\=0A-		"movups %%xmm2,0x20(%1)	;\n\t"	=
\=0A-		"movups %%xmm3,0x30(%1)	;\n\t"	\=0A-		: "=3D&r" =
(cr0)			\=0A-		: "r" (xmm_save) 		=
\=0A-		: "memory");			\=0A-} while(0)=0A-=0A-#def=
ine XMMS_RESTORE do {			\=0A-	asm volatile (			=
	\=0A-		"sfence			;\n\t"	\=0A-		=
"movups (%1),%%xmm0	;\n\t"	\=0A-		"movups 0x10(%1),%%xmm1	=
;\n\t"	\=0A-		"movups 0x20(%1),%%xmm2	;\n\t"	\=0A-		=
"movups 0x30(%1),%%xmm3	;\n\t"	\=0A-		:				=
\=0A-		: "r" (cr0), "r" (xmm_save)	\=0A-		: =
"memory");			\=0A-	if (!(current_thread_info()->status=
 & TS_USEDFPU))	\=0A-		stts();				\=0A-	=
preempt_enable();			\=0A-} while(0)=0A-=0A-#define =
OFFS(x)		"16*("#x")"=0A-#define PF_OFFS(x)	"256+16*("#x")"=0A-=
#define	PF0(x)		"	prefetchnta "PF_OFFS(x)"(%[p1])		=
;\n"=0A-#define LD(x,y)		"       movaps   "OFFS(x)"(%[p1]), =
%%xmm"#y"	;\n"=0A-#define ST(x,y)		"       movaps %%xmm"#y",  =
 "OFFS(x)"(%[p1])	;\n"=0A-#define PF1(x)		"	prefetchnta=
 "PF_OFFS(x)"(%[p2])		;\n"=0A-#define PF2(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p3])		;\n"=0A-#define PF3(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p4])		;\n"=0A-#define PF4(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p5])		;\n"=0A-#define PF5(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p6])		;\n"=0A-#define XO1(x,y)	"  =
     xorps   "OFFS(x)"(%[p2]), %%xmm"#y"	;\n"=0A-#define XO2(x,y)	=
"       xorps   "OFFS(x)"(%[p3]), %%xmm"#y"	;\n"=0A-#define XO3(x,y)	=
"       xorps   "OFFS(x)"(%[p4]), %%xmm"#y"	;\n"=0A-#define XO4(x,y)	=
"       xorps   "OFFS(x)"(%[p5]), %%xmm"#y"	;\n"=0A-#define XO5(x,y)	=
"       xorps   "OFFS(x)"(%[p6]), %%xmm"#y"	;\n"=0A-=0A-=0A-static =
void=0A-xor_sse_2(unsigned long bytes, unsigned long *p1, unsigned long =
*p2)=0A-{=0A-        unsigned int lines =3D bytes >> 8;=0A-	unsigned =
long cr0;=0A-	xmm_store_t xmm_save[4];=0A-=0A-	XMMS_SAVE;=0A-=0A- =
       asm volatile (=0A-#undef BLOCK=0A-#define BLOCK(i) \=0A-		=
LD(i,0)					\=0A-			LD(i+1,1)	=
		\=0A-		PF1(i)					=
\=0A-				PF1(i+2)		\=0A-			=
	LD(i+2,2)		\=0A-					=
LD(i+3,3)	\=0A-		PF0(i+4)				=
\=0A-				PF0(i+6)		\=0A-		=
XO1(i,0)				\=0A-			XO1(i+1,1)	=
		\=0A-				XO1(i+2,2)		=
\=0A-					XO1(i+3,3)	\=0A-		=
ST(i,0)					\=0A-			ST(i+1,1)	=
		\=0A-				ST(i+2,2)		=
\=0A-					ST(i+3,3)	\=0A-=0A-=0A-		=
PF0(0)=0A-				PF0(2)=0A-=0A-	" .align 32		=
	;\n"=0A-        " 1:                            ;\n"=0A-=0A-		=
BLOCK(0)=0A-		BLOCK(4)=0A-		BLOCK(8)=0A-		=
BLOCK(12)=0A-=0A-        "       addq %[inc], %[p1]           ;\n"=0A-     =
   "       addq %[inc], %[p2]           ;\n"=0A-		"		=
decl %[cnt] ; jnz 1b"=0A-	: [p1] "+r" (p1), [p2] "+r" (p2), [cnt] =
"+r" (lines)=0A-	: [inc] "r" (256UL) =0A-        : "memory");=0A-=0A=
-	XMMS_RESTORE;=0A-}=0A-=0A-static void=0A-xor_sse_3(unsigned long =
bytes, unsigned long *p1, unsigned long *p2,=0A-	  unsigned long =
*p3)=0A-{=0A-	unsigned int lines =3D bytes >> 8;=0A-	xmm_store_t =
xmm_save[4];=0A-	unsigned long cr0;=0A-=0A-	XMMS_SAVE;=0A-=0A- =
       __asm__ __volatile__ (=0A-#undef BLOCK=0A-#define BLOCK(i) \=0A-		=
PF1(i)					\=0A-				=
PF1(i+2)		\=0A-		LD(i,0)					=
\=0A-			LD(i+1,1)			\=0A-			=
	LD(i+2,2)		\=0A-					=
LD(i+3,3)	\=0A-		PF2(i)					=
\=0A-				PF2(i+2)		\=0A-		=
PF0(i+4)				\=0A-				=
PF0(i+6)		\=0A-		XO1(i,0)				=
\=0A-			XO1(i+1,1)			\=0A-			=
	XO1(i+2,2)		\=0A-					=
XO1(i+3,3)	\=0A-		XO2(i,0)				=
\=0A-			XO2(i+1,1)			\=0A-			=
	XO2(i+2,2)		\=0A-					=
XO2(i+3,3)	\=0A-		ST(i,0)					=
\=0A-			ST(i+1,1)			\=0A-			=
	ST(i+2,2)		\=0A-					=
ST(i+3,3)	\=0A-=0A-=0A-		PF0(0)=0A-				=
PF0(2)=0A-=0A-	" .align 32			;\n"=0A-        " 1:       =
                     ;\n"=0A-=0A-		BLOCK(0)=0A-		=
BLOCK(4)=0A-		BLOCK(8)=0A-		BLOCK(12)=0A-=0A-        " =
      addq %[inc], %[p1]           ;\n"=0A-        "       addq %[inc], =
%[p2]          ;\n"=0A-        "       addq %[inc], %[p3]           =
;\n"=0A-		"		decl %[cnt] ; jnz 1b"=0A-	: =
[cnt] "+r" (lines),=0A-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" =
(p3)=0A-	: [inc] "r" (256UL)=0A-	: "memory"); =0A-	XMMS_RESTOR=
E;=0A-}=0A-=0A-static void=0A-xor_sse_4(unsigned long bytes, unsigned long =
*p1, unsigned long *p2,=0A-	  unsigned long *p3, unsigned long =
*p4)=0A-{=0A-	unsigned int lines =3D bytes >> 8;=0A-	xmm_store_t =
xmm_save[4]; =0A-	unsigned long cr0;=0A-=0A-	XMMS_SAVE;=0A-=0A- =
       __asm__ __volatile__ (=0A-#undef BLOCK=0A-#define BLOCK(i) \=0A-		=
PF1(i)					\=0A-				=
PF1(i+2)		\=0A-		LD(i,0)					=
\=0A-			LD(i+1,1)			\=0A-			=
	LD(i+2,2)		\=0A-					=
LD(i+3,3)	\=0A-		PF2(i)					=
\=0A-				PF2(i+2)		\=0A-		=
XO1(i,0)				\=0A-			XO1(i+1,1)	=
		\=0A-				XO1(i+2,2)		=
\=0A-					XO1(i+3,3)	\=0A-		=
PF3(i)					\=0A-				=
PF3(i+2)		\=0A-		PF0(i+4)				=
\=0A-				PF0(i+6)		\=0A-		=
XO2(i,0)				\=0A-			XO2(i+1,1)	=
		\=0A-				XO2(i+2,2)		=
\=0A-					XO2(i+3,3)	\=0A-		=
XO3(i,0)				\=0A-			XO3(i+1,1)	=
		\=0A-				XO3(i+2,2)		=
\=0A-					XO3(i+3,3)	\=0A-		=
ST(i,0)					\=0A-			ST(i+1,1)	=
		\=0A-				ST(i+2,2)		=
\=0A-					ST(i+3,3)	\=0A-=0A-=0A-		=
PF0(0)=0A-				PF0(2)=0A-=0A-	" .align 32		=
	;\n"=0A-        " 1:                            ;\n"=0A-=0A-		=
BLOCK(0)=0A-		BLOCK(4)=0A-		BLOCK(8)=0A-		=
BLOCK(12)=0A-=0A-        "       addq %[inc], %[p1]           ;\n"=0A-     =
   "       addq %[inc], %[p2]           ;\n"=0A-        "       addq =
%[inc], %[p3]           ;\n"=0A-        "       addq %[inc], %[p4]         =
  ;\n"=0A-	"	decl %[cnt] ; jnz 1b"=0A-	: [cnt] "+c" =
(lines),=0A-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] =
"+r" (p4)=0A-	: [inc] "r" (256UL)=0A-        : "memory" );=0A-=0A-	=
XMMS_RESTORE;=0A-}=0A-=0A-static void=0A-xor_sse_5(unsigned long bytes, =
unsigned long *p1, unsigned long *p2,=0A-	  unsigned long *p3, =
unsigned long *p4, unsigned long *p5)=0A-{=0A-        unsigned int lines =
=3D bytes >> 8;=0A-	xmm_store_t xmm_save[4];=0A-	unsigned long =
cr0;=0A-=0A-	XMMS_SAVE;=0A-=0A-        __asm__ __volatile__ (=0A-#undef =
BLOCK=0A-#define BLOCK(i) \=0A-		PF1(i)					=
\=0A-				PF1(i+2)		\=0A-		=
LD(i,0)					\=0A-			LD(i+1,1)	=
		\=0A-				LD(i+2,2)		=
\=0A-					LD(i+3,3)	\=0A-		=
PF2(i)					\=0A-				=
PF2(i+2)		\=0A-		XO1(i,0)				=
\=0A-			XO1(i+1,1)			\=0A-			=
	XO1(i+2,2)		\=0A-					=
XO1(i+3,3)	\=0A-		PF3(i)					=
\=0A-				PF3(i+2)		\=0A-		=
XO2(i,0)				\=0A-			XO2(i+1,1)	=
		\=0A-				XO2(i+2,2)		=
\=0A-					XO2(i+3,3)	\=0A-		=
PF4(i)					\=0A-				=
PF4(i+2)		\=0A-		PF0(i+4)				=
\=0A-				PF0(i+6)		\=0A-		=
XO3(i,0)				\=0A-			XO3(i+1,1)	=
		\=0A-				XO3(i+2,2)		=
\=0A-					XO3(i+3,3)	\=0A-		=
XO4(i,0)				\=0A-			XO4(i+1,1)	=
		\=0A-				XO4(i+2,2)		=
\=0A-					XO4(i+3,3)	\=0A-		=
ST(i,0)					\=0A-			ST(i+1,1)	=
		\=0A-				ST(i+2,2)		=
\=0A-					ST(i+3,3)	\=0A-=0A-=0A-		=
PF0(0)=0A-				PF0(2)=0A-=0A-	" .align 32		=
	;\n"=0A-        " 1:                            ;\n"=0A-=0A-		=
BLOCK(0)=0A-		BLOCK(4)=0A-		BLOCK(8)=0A-		=
BLOCK(12)=0A-=0A-        "       addq %[inc], %[p1]           ;\n"=0A-     =
   "       addq %[inc], %[p2]           ;\n"=0A-        "       addq =
%[inc], %[p3]           ;\n"=0A-        "       addq %[inc], %[p4]         =
  ;\n"=0A-        "       addq %[inc], %[p5]           ;\n"=0A-	"	=
decl %[cnt] ; jnz 1b"=0A-	: [cnt] "+c" (lines),=0A-  	  [p1] =
"+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] "+r" (p4), =0A-	  [p5] =
"+r" (p5)=0A-	: [inc] "r" (256UL)=0A-	: "memory");=0A-=0A-	XMMS_RESTOR=
E;=0A-}=0A-=0A-static struct xor_block_template xor_block_sse =3D {=0A-    =
    .name =3D "generic_sse",=0A-        .do_2 =3D xor_sse_2,=0A-        =
.do_3 =3D xor_sse_3,=0A-        .do_4 =3D xor_sse_4,=0A-        .do_5 =3D =
xor_sse_5,=0A-};=0A+/* Also try the generic routines.  */=0A+#undef =
XOR_TRY_TEMPLATES=0A+#include <asm-generic/xor.h>=0A =0A #undef XOR_TRY_TEM=
PLATES=0A-#define XOR_TRY_TEMPLATES				\=0A-	do =
{						\=0A+#define XOR_TRY_TEMPLA=
TES			\=0A+	do {					=
\=0A+		xor_speed(&xor_block_8regs);	\=0A+		xor_speed(&=
xor_block_8regs_p);	\=0A+		xor_speed(&xor_block_32regs);	=
\=0A+		xor_speed(&xor_block_32regs_p);	\=0A 		xor_speed(&=
xor_block_sse);	\=0A 	} while (0)=0A-=0A-/* We force the use of the SSE =
xor block because it can write around L2.=0A-   We may also be able to =
load into the L1 only depending on how the cpu=0A-   deals with a load to =
a line that is being prefetched.  */=0A-#define XOR_SELECT_TEMPLATE(FASTEST=
) (&xor_block_sse)=0A--- a/include/asm-x86_64/xor.h=0A+++ b/include/asm-x86=
_64/xor.h=0A@@ -39,14 +39,14 @@ typedef struct { unsigned long a,b; } =
__=0A    tell it to do a clts before the register saving. */=0A #define =
XMMS_SAVE do {				\=0A 	preempt_disable();		=
	\=0A+	cr0 =3D read_cr0();			\=0A+	clts();		=
			\=0A 	asm volatile (				=
\=0A-		"movq %%cr0,%0		;\n\t"	\=0A-		"clts		=
	;\n\t"	\=0A 		"movups %%xmm0,(%1)	;\n\t"	\=0A 		=
"movups %%xmm1,0x10(%1)	;\n\t"	\=0A 		"movups %%xmm2,0x20(%1)	=
;\n\t"	\=0A 		"movups %%xmm3,0x30(%1)	;\n\t"	\=0A-		: =
"=3D&r" (cr0)			\=0A+		: "+r" (cr0)			=
\=0A 		: "r" (xmm_save) 		\=0A 		: =
"memory");			\=0A } while(0)=0A@@ -58,10 +58,10 @@ =
typedef struct { unsigned long a,b; } __=0A 		"movups 0x10(%1),%%=
xmm1	;\n\t"	\=0A 		"movups 0x20(%1),%%xmm2	;\n\t"	\=0A 		=
"movups 0x30(%1),%%xmm3	;\n\t"	\=0A-		"movq 	%0,%%cr0	=
;\n\t"	\=0A 		:				\=0A 		: =
"r" (cr0), "r" (xmm_save)	\=0A 		: "memory");			=
\=0A+	write_cr0(cr0);				\=0A 	preempt_enable();	=
		\=0A } while(0)=0A =0A
--=__PartBA9415CB.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

--=__PartBA9415CB.0__=--


From xen-devel-bounces@lists.xen.org Fri Jun 29 14:29:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcC6-00045G-9j; Fri, 29 Jun 2012 14:29:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1SkcC4-00044w-Tz
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:29:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1340980141!9291068!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2Nzc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22139 invoked from network); 29 Jun 2012 14:29:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	29 Jun 2012 14:29:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 29 Jun 2012 15:29:02 +0100
Message-Id: <4FEDD7FB020000780008CDF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 29 Jun 2012 15:29:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBA9415CB.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/x86: make xor block handling
	uniform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartBA9415CB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Irrespective of the elimination of raw CR0 reads and writes, any of the
methods requiring access to the floating point/XMM state still perform
worse than the integer register based ones (at least as long as the
virtual CR0.TS is set upon entry). Thus un-define XOR_SELECT_TEMPLATE
in both 32- and 64-bit.

On 64-bit additionally make the integer register based routines
available for selection in the first place, and remove the duplicate
code in the Xen specific header in favor of a small adjustment to the
native one (using read_cr0()/clts()/write_cr0() instead of open coded
accesses in the inline assembly).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- /dev/null
+++ b/include/asm-i386/mach-xen/asm/xor.h
@@ -0,0 +1,3 @@
+#include_next <asm/xor.h>
+
+#undef XOR_SELECT_TEMPLATE
--- a/include/asm-x86_64/mach-xen/asm/xor.h
+++ b/include/asm-x86_64/mach-xen/asm/xor.h
@@ -1,328 +1,17 @@
-/*
- * x86-64 changes / gcc fixes from Andi Kleen.=20
- * Copyright 2002 Andi Kleen, SuSE Labs.
- *
- * This hasn't been optimized for the hammer yet, but there are likely
- * no advantages to be gotten from x86-64 here anyways.
- */
+#include_next <asm/xor.h>
=20
-typedef struct { unsigned long a,b; } __attribute__((aligned(16))) =
xmm_store_t;
+#undef XOR_SELECT_TEMPLATE
=20
-/* Doesn't use gcc to save the XMM registers, because there is no easy =
way to=20
-   tell it to do a clts before the register saving. */
-#define XMMS_SAVE do {				\
-	preempt_disable();			\
-	if (!(current_thread_info()->status & TS_USEDFPU))	\
-		clts();				\
-	__asm__ __volatile__ ( 			\
-		"movups %%xmm0,(%1)	;\n\t"	\
-		"movups %%xmm1,0x10(%1)	;\n\t"	\
-		"movups %%xmm2,0x20(%1)	;\n\t"	\
-		"movups %%xmm3,0x30(%1)	;\n\t"	\
-		: "=3D&r" (cr0)			\
-		: "r" (xmm_save) 		\
-		: "memory");			\
-} while(0)
-
-#define XMMS_RESTORE do {			\
-	asm volatile (				\
-		"sfence			;\n\t"	\
-		"movups (%1),%%xmm0	;\n\t"	\
-		"movups 0x10(%1),%%xmm1	;\n\t"	\
-		"movups 0x20(%1),%%xmm2	;\n\t"	\
-		"movups 0x30(%1),%%xmm3	;\n\t"	\
-		:				\
-		: "r" (cr0), "r" (xmm_save)	\
-		: "memory");			\
-	if (!(current_thread_info()->status & TS_USEDFPU))	\
-		stts();				\
-	preempt_enable();			\
-} while(0)
-
-#define OFFS(x)		"16*("#x")"
-#define PF_OFFS(x)	"256+16*("#x")"
-#define	PF0(x)		"	prefetchnta "PF_OFFS(x)"(%[p1])		=
;\n"
-#define LD(x,y)		"       movaps   "OFFS(x)"(%[p1]), =
%%xmm"#y"	;\n"
-#define ST(x,y)		"       movaps %%xmm"#y",   "OFFS(x)"(%[p1]=
)	;\n"
-#define PF1(x)		"	prefetchnta "PF_OFFS(x)"(%[p2])		=
;\n"
-#define PF2(x)		"	prefetchnta "PF_OFFS(x)"(%[p3])		=
;\n"
-#define PF3(x)		"	prefetchnta "PF_OFFS(x)"(%[p4])		=
;\n"
-#define PF4(x)		"	prefetchnta "PF_OFFS(x)"(%[p5])		=
;\n"
-#define PF5(x)		"	prefetchnta "PF_OFFS(x)"(%[p6])		=
;\n"
-#define XO1(x,y)	"       xorps   "OFFS(x)"(%[p2]), %%xmm"#y"	=
;\n"
-#define XO2(x,y)	"       xorps   "OFFS(x)"(%[p3]), %%xmm"#y"	=
;\n"
-#define XO3(x,y)	"       xorps   "OFFS(x)"(%[p4]), %%xmm"#y"	=
;\n"
-#define XO4(x,y)	"       xorps   "OFFS(x)"(%[p5]), %%xmm"#y"	=
;\n"
-#define XO5(x,y)	"       xorps   "OFFS(x)"(%[p6]), %%xmm"#y"	=
;\n"
-
-
-static void
-xor_sse_2(unsigned long bytes, unsigned long *p1, unsigned long *p2)
-{
-        unsigned int lines =3D bytes >> 8;
-	unsigned long cr0;
-	xmm_store_t xmm_save[4];
-
-	XMMS_SAVE;
-
-        asm volatile (
-#undef BLOCK
-#define BLOCK(i) \
-		LD(i,0)					\
-			LD(i+1,1)			\
-		PF1(i)					\
-				PF1(i+2)		\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]           ;\n"
-		"		decl %[cnt] ; jnz 1b"
-	: [p1] "+r" (p1), [p2] "+r" (p2), [cnt] "+r" (lines)
-	: [inc] "r" (256UL)=20
-        : "memory");
-
-	XMMS_RESTORE;
-}
-
-static void
-xor_sse_3(unsigned long bytes, unsigned long *p1, unsigned long *p2,
-	  unsigned long *p3)
-{
-	unsigned int lines =3D bytes >> 8;
-	xmm_store_t xmm_save[4];
-	unsigned long cr0;
-
-	XMMS_SAVE;
-
-        __asm__ __volatile__ (
-#undef BLOCK
-#define BLOCK(i) \
-		PF1(i)					\
-				PF1(i+2)		\
-		LD(i,0)					\
-			LD(i+1,1)			\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF2(i)					\
-				PF2(i+2)		\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		XO2(i,0)				\
-			XO2(i+1,1)			\
-				XO2(i+2,2)		\
-					XO2(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]          ;\n"
-        "       addq %[inc], %[p3]           ;\n"
-		"		decl %[cnt] ; jnz 1b"
-	: [cnt] "+r" (lines),
-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3)
-	: [inc] "r" (256UL)
-	: "memory");=20
-	XMMS_RESTORE;
-}
-
-static void
-xor_sse_4(unsigned long bytes, unsigned long *p1, unsigned long *p2,
-	  unsigned long *p3, unsigned long *p4)
-{
-	unsigned int lines =3D bytes >> 8;
-	xmm_store_t xmm_save[4];=20
-	unsigned long cr0;
-
-	XMMS_SAVE;
-
-        __asm__ __volatile__ (
-#undef BLOCK
-#define BLOCK(i) \
-		PF1(i)					\
-				PF1(i+2)		\
-		LD(i,0)					\
-			LD(i+1,1)			\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF2(i)					\
-				PF2(i+2)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		PF3(i)					\
-				PF3(i+2)		\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO2(i,0)				\
-			XO2(i+1,1)			\
-				XO2(i+2,2)		\
-					XO2(i+3,3)	\
-		XO3(i,0)				\
-			XO3(i+1,1)			\
-				XO3(i+2,2)		\
-					XO3(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]           ;\n"
-        "       addq %[inc], %[p3]           ;\n"
-        "       addq %[inc], %[p4]           ;\n"
-	"	decl %[cnt] ; jnz 1b"
-	: [cnt] "+c" (lines),
-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] "+r" (p4)
-	: [inc] "r" (256UL)
-        : "memory" );
-
-	XMMS_RESTORE;
-}
-
-static void
-xor_sse_5(unsigned long bytes, unsigned long *p1, unsigned long *p2,
-	  unsigned long *p3, unsigned long *p4, unsigned long *p5)
-{
-        unsigned int lines =3D bytes >> 8;
-	xmm_store_t xmm_save[4];
-	unsigned long cr0;
-
-	XMMS_SAVE;
-
-        __asm__ __volatile__ (
-#undef BLOCK
-#define BLOCK(i) \
-		PF1(i)					\
-				PF1(i+2)		\
-		LD(i,0)					\
-			LD(i+1,1)			\
-				LD(i+2,2)		\
-					LD(i+3,3)	\
-		PF2(i)					\
-				PF2(i+2)		\
-		XO1(i,0)				\
-			XO1(i+1,1)			\
-				XO1(i+2,2)		\
-					XO1(i+3,3)	\
-		PF3(i)					\
-				PF3(i+2)		\
-		XO2(i,0)				\
-			XO2(i+1,1)			\
-				XO2(i+2,2)		\
-					XO2(i+3,3)	\
-		PF4(i)					\
-				PF4(i+2)		\
-		PF0(i+4)				\
-				PF0(i+6)		\
-		XO3(i,0)				\
-			XO3(i+1,1)			\
-				XO3(i+2,2)		\
-					XO3(i+3,3)	\
-		XO4(i,0)				\
-			XO4(i+1,1)			\
-				XO4(i+2,2)		\
-					XO4(i+3,3)	\
-		ST(i,0)					\
-			ST(i+1,1)			\
-				ST(i+2,2)		\
-					ST(i+3,3)	\
-
-
-		PF0(0)
-				PF0(2)
-
-	" .align 32			;\n"
-        " 1:                            ;\n"
-
-		BLOCK(0)
-		BLOCK(4)
-		BLOCK(8)
-		BLOCK(12)
-
-        "       addq %[inc], %[p1]           ;\n"
-        "       addq %[inc], %[p2]           ;\n"
-        "       addq %[inc], %[p3]           ;\n"
-        "       addq %[inc], %[p4]           ;\n"
-        "       addq %[inc], %[p5]           ;\n"
-	"	decl %[cnt] ; jnz 1b"
-	: [cnt] "+c" (lines),
-  	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] "+r" =
(p4),=20
-	  [p5] "+r" (p5)
-	: [inc] "r" (256UL)
-	: "memory");
-
-	XMMS_RESTORE;
-}
-
-static struct xor_block_template xor_block_sse =3D {
-        .name =3D "generic_sse",
-        .do_2 =3D xor_sse_2,
-        .do_3 =3D xor_sse_3,
-        .do_4 =3D xor_sse_4,
-        .do_5 =3D xor_sse_5,
-};
+/* Also try the generic routines.  */
+#undef XOR_TRY_TEMPLATES
+#include <asm-generic/xor.h>
=20
 #undef XOR_TRY_TEMPLATES
-#define XOR_TRY_TEMPLATES				\
-	do {						\
+#define XOR_TRY_TEMPLATES			\
+	do {					\
+		xor_speed(&xor_block_8regs);	\
+		xor_speed(&xor_block_8regs_p);	\
+		xor_speed(&xor_block_32regs);	\
+		xor_speed(&xor_block_32regs_p);	\
 		xor_speed(&xor_block_sse);	\
 	} while (0)
-
-/* We force the use of the SSE xor block because it can write around L2.
-   We may also be able to load into the L1 only depending on how the cpu
-   deals with a load to a line that is being prefetched.  */
-#define XOR_SELECT_TEMPLATE(FASTEST) (&xor_block_sse)
--- a/include/asm-x86_64/xor.h
+++ b/include/asm-x86_64/xor.h
@@ -39,14 +39,14 @@ typedef struct { unsigned long a,b; } __
    tell it to do a clts before the register saving. */
 #define XMMS_SAVE do {				\
 	preempt_disable();			\
+	cr0 =3D read_cr0();			\
+	clts();					\
 	asm volatile (				\
-		"movq %%cr0,%0		;\n\t"	\
-		"clts			;\n\t"	\
 		"movups %%xmm0,(%1)	;\n\t"	\
 		"movups %%xmm1,0x10(%1)	;\n\t"	\
 		"movups %%xmm2,0x20(%1)	;\n\t"	\
 		"movups %%xmm3,0x30(%1)	;\n\t"	\
-		: "=3D&r" (cr0)			\
+		: "+r" (cr0)			\
 		: "r" (xmm_save) 		\
 		: "memory");			\
 } while(0)
@@ -58,10 +58,10 @@ typedef struct { unsigned long a,b; } __
 		"movups 0x10(%1),%%xmm1	;\n\t"	\
 		"movups 0x20(%1),%%xmm2	;\n\t"	\
 		"movups 0x30(%1),%%xmm3	;\n\t"	\
-		"movq 	%0,%%cr0	;\n\t"	\
 		:				\
 		: "r" (cr0), "r" (xmm_save)	\
 		: "memory");			\
+	write_cr0(cr0);				\
 	preempt_enable();			\
 } while(0)
=20



--=__PartBA9415CB.0__=
Content-Type: text/plain; name="xen-x86-xor-unify.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-x86-xor-unify.patch"

x86: make xor block handling uniform=0A=0AIrrespective of the elimination =
of raw CR0 reads and writes, any of the=0Amethods requiring access to the =
floating point/XMM state still perform=0Aworse than the integer register =
based ones (at least as long as the=0Avirtual CR0.TS is set upon entry). =
Thus un-define XOR_SELECT_TEMPLATE=0Ain both 32- and 64-bit.=0A=0AOn =
64-bit additionally make the integer register based routines=0Aavailable =
for selection in the first place, and remove the duplicate=0Acode in the =
Xen specific header in favor of a small adjustment to the=0Anative one =
(using read_cr0()/clts()/write_cr0() instead of open coded=0Aaccesses in =
the inline assembly).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- /dev/null=0A+++ b/include/asm-i386/mach-xen/asm/xor.h=0A@@ -0,0 =
+1,3 @@=0A+#include_next <asm/xor.h>=0A+=0A+#undef XOR_SELECT_TEMPLATE=0A--=
- a/include/asm-x86_64/mach-xen/asm/xor.h=0A+++ b/include/asm-x86_64/mach-x=
en/asm/xor.h=0A@@ -1,328 +1,17 @@=0A-/*=0A- * x86-64 changes / gcc fixes =
from Andi Kleen. =0A- * Copyright 2002 Andi Kleen, SuSE Labs.=0A- *=0A- * =
This hasn't been optimized for the hammer yet, but there are likely=0A- * =
no advantages to be gotten from x86-64 here anyways.=0A- */=0A+#include_nex=
t <asm/xor.h>=0A =0A-typedef struct { unsigned long a,b; } __attribute__((a=
ligned(16))) xmm_store_t;=0A+#undef XOR_SELECT_TEMPLATE=0A =0A-/* Doesn't =
use gcc to save the XMM registers, because there is no easy way to =0A-   =
tell it to do a clts before the register saving. */=0A-#define XMMS_SAVE =
do {				\=0A-	preempt_disable();			=
\=0A-	if (!(current_thread_info()->status & TS_USEDFPU))	\=0A-		=
clts();				\=0A-	__asm__ __volatile__ ( 			=
\=0A-		"movups %%xmm0,(%1)	;\n\t"	\=0A-		"movups =
%%xmm1,0x10(%1)	;\n\t"	\=0A-		"movups %%xmm2,0x20(%1)	;\n\t"	=
\=0A-		"movups %%xmm3,0x30(%1)	;\n\t"	\=0A-		: "=3D&r" =
(cr0)			\=0A-		: "r" (xmm_save) 		=
\=0A-		: "memory");			\=0A-} while(0)=0A-=0A-#def=
ine XMMS_RESTORE do {			\=0A-	asm volatile (			=
	\=0A-		"sfence			;\n\t"	\=0A-		=
"movups (%1),%%xmm0	;\n\t"	\=0A-		"movups 0x10(%1),%%xmm1	=
;\n\t"	\=0A-		"movups 0x20(%1),%%xmm2	;\n\t"	\=0A-		=
"movups 0x30(%1),%%xmm3	;\n\t"	\=0A-		:				=
\=0A-		: "r" (cr0), "r" (xmm_save)	\=0A-		: =
"memory");			\=0A-	if (!(current_thread_info()->status=
 & TS_USEDFPU))	\=0A-		stts();				\=0A-	=
preempt_enable();			\=0A-} while(0)=0A-=0A-#define =
OFFS(x)		"16*("#x")"=0A-#define PF_OFFS(x)	"256+16*("#x")"=0A-=
#define	PF0(x)		"	prefetchnta "PF_OFFS(x)"(%[p1])		=
;\n"=0A-#define LD(x,y)		"       movaps   "OFFS(x)"(%[p1]), =
%%xmm"#y"	;\n"=0A-#define ST(x,y)		"       movaps %%xmm"#y",  =
 "OFFS(x)"(%[p1])	;\n"=0A-#define PF1(x)		"	prefetchnta=
 "PF_OFFS(x)"(%[p2])		;\n"=0A-#define PF2(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p3])		;\n"=0A-#define PF3(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p4])		;\n"=0A-#define PF4(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p5])		;\n"=0A-#define PF5(x)		"	=
prefetchnta "PF_OFFS(x)"(%[p6])		;\n"=0A-#define XO1(x,y)	"  =
     xorps   "OFFS(x)"(%[p2]), %%xmm"#y"	;\n"=0A-#define XO2(x,y)	=
"       xorps   "OFFS(x)"(%[p3]), %%xmm"#y"	;\n"=0A-#define XO3(x,y)	=
"       xorps   "OFFS(x)"(%[p4]), %%xmm"#y"	;\n"=0A-#define XO4(x,y)	=
"       xorps   "OFFS(x)"(%[p5]), %%xmm"#y"	;\n"=0A-#define XO5(x,y)	=
"       xorps   "OFFS(x)"(%[p6]), %%xmm"#y"	;\n"=0A-=0A-=0A-static =
void=0A-xor_sse_2(unsigned long bytes, unsigned long *p1, unsigned long =
*p2)=0A-{=0A-        unsigned int lines =3D bytes >> 8;=0A-	unsigned =
long cr0;=0A-	xmm_store_t xmm_save[4];=0A-=0A-	XMMS_SAVE;=0A-=0A- =
       asm volatile (=0A-#undef BLOCK=0A-#define BLOCK(i) \=0A-		=
LD(i,0)					\=0A-			LD(i+1,1)	=
		\=0A-		PF1(i)					=
\=0A-				PF1(i+2)		\=0A-			=
	LD(i+2,2)		\=0A-					=
LD(i+3,3)	\=0A-		PF0(i+4)				=
\=0A-				PF0(i+6)		\=0A-		=
XO1(i,0)				\=0A-			XO1(i+1,1)	=
		\=0A-				XO1(i+2,2)		=
\=0A-					XO1(i+3,3)	\=0A-		=
ST(i,0)					\=0A-			ST(i+1,1)	=
		\=0A-				ST(i+2,2)		=
\=0A-					ST(i+3,3)	\=0A-=0A-=0A-		=
PF0(0)=0A-				PF0(2)=0A-=0A-	" .align 32		=
	;\n"=0A-        " 1:                            ;\n"=0A-=0A-		=
BLOCK(0)=0A-		BLOCK(4)=0A-		BLOCK(8)=0A-		=
BLOCK(12)=0A-=0A-        "       addq %[inc], %[p1]           ;\n"=0A-     =
   "       addq %[inc], %[p2]           ;\n"=0A-		"		=
decl %[cnt] ; jnz 1b"=0A-	: [p1] "+r" (p1), [p2] "+r" (p2), [cnt] =
"+r" (lines)=0A-	: [inc] "r" (256UL) =0A-        : "memory");=0A-=0A=
-	XMMS_RESTORE;=0A-}=0A-=0A-static void=0A-xor_sse_3(unsigned long =
bytes, unsigned long *p1, unsigned long *p2,=0A-	  unsigned long =
*p3)=0A-{=0A-	unsigned int lines =3D bytes >> 8;=0A-	xmm_store_t =
xmm_save[4];=0A-	unsigned long cr0;=0A-=0A-	XMMS_SAVE;=0A-=0A- =
       __asm__ __volatile__ (=0A-#undef BLOCK=0A-#define BLOCK(i) \=0A-		=
PF1(i)					\=0A-				=
PF1(i+2)		\=0A-		LD(i,0)					=
\=0A-			LD(i+1,1)			\=0A-			=
	LD(i+2,2)		\=0A-					=
LD(i+3,3)	\=0A-		PF2(i)					=
\=0A-				PF2(i+2)		\=0A-		=
PF0(i+4)				\=0A-				=
PF0(i+6)		\=0A-		XO1(i,0)				=
\=0A-			XO1(i+1,1)			\=0A-			=
	XO1(i+2,2)		\=0A-					=
XO1(i+3,3)	\=0A-		XO2(i,0)				=
\=0A-			XO2(i+1,1)			\=0A-			=
	XO2(i+2,2)		\=0A-					=
XO2(i+3,3)	\=0A-		ST(i,0)					=
\=0A-			ST(i+1,1)			\=0A-			=
	ST(i+2,2)		\=0A-					=
ST(i+3,3)	\=0A-=0A-=0A-		PF0(0)=0A-				=
PF0(2)=0A-=0A-	" .align 32			;\n"=0A-        " 1:       =
                     ;\n"=0A-=0A-		BLOCK(0)=0A-		=
BLOCK(4)=0A-		BLOCK(8)=0A-		BLOCK(12)=0A-=0A-        " =
      addq %[inc], %[p1]           ;\n"=0A-        "       addq %[inc], =
%[p2]          ;\n"=0A-        "       addq %[inc], %[p3]           =
;\n"=0A-		"		decl %[cnt] ; jnz 1b"=0A-	: =
[cnt] "+r" (lines),=0A-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" =
(p3)=0A-	: [inc] "r" (256UL)=0A-	: "memory"); =0A-	XMMS_RESTOR=
E;=0A-}=0A-=0A-static void=0A-xor_sse_4(unsigned long bytes, unsigned long =
*p1, unsigned long *p2,=0A-	  unsigned long *p3, unsigned long =
*p4)=0A-{=0A-	unsigned int lines =3D bytes >> 8;=0A-	xmm_store_t =
xmm_save[4]; =0A-	unsigned long cr0;=0A-=0A-	XMMS_SAVE;=0A-=0A- =
       __asm__ __volatile__ (=0A-#undef BLOCK=0A-#define BLOCK(i) \=0A-		=
PF1(i)					\=0A-				=
PF1(i+2)		\=0A-		LD(i,0)					=
\=0A-			LD(i+1,1)			\=0A-			=
	LD(i+2,2)		\=0A-					=
LD(i+3,3)	\=0A-		PF2(i)					=
\=0A-				PF2(i+2)		\=0A-		=
XO1(i,0)				\=0A-			XO1(i+1,1)	=
		\=0A-				XO1(i+2,2)		=
\=0A-					XO1(i+3,3)	\=0A-		=
PF3(i)					\=0A-				=
PF3(i+2)		\=0A-		PF0(i+4)				=
\=0A-				PF0(i+6)		\=0A-		=
XO2(i,0)				\=0A-			XO2(i+1,1)	=
		\=0A-				XO2(i+2,2)		=
\=0A-					XO2(i+3,3)	\=0A-		=
XO3(i,0)				\=0A-			XO3(i+1,1)	=
		\=0A-				XO3(i+2,2)		=
\=0A-					XO3(i+3,3)	\=0A-		=
ST(i,0)					\=0A-			ST(i+1,1)	=
		\=0A-				ST(i+2,2)		=
\=0A-					ST(i+3,3)	\=0A-=0A-=0A-		=
PF0(0)=0A-				PF0(2)=0A-=0A-	" .align 32		=
	;\n"=0A-        " 1:                            ;\n"=0A-=0A-		=
BLOCK(0)=0A-		BLOCK(4)=0A-		BLOCK(8)=0A-		=
BLOCK(12)=0A-=0A-        "       addq %[inc], %[p1]           ;\n"=0A-     =
   "       addq %[inc], %[p2]           ;\n"=0A-        "       addq =
%[inc], %[p3]           ;\n"=0A-        "       addq %[inc], %[p4]         =
  ;\n"=0A-	"	decl %[cnt] ; jnz 1b"=0A-	: [cnt] "+c" =
(lines),=0A-	  [p1] "+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] =
"+r" (p4)=0A-	: [inc] "r" (256UL)=0A-        : "memory" );=0A-=0A-	=
XMMS_RESTORE;=0A-}=0A-=0A-static void=0A-xor_sse_5(unsigned long bytes, =
unsigned long *p1, unsigned long *p2,=0A-	  unsigned long *p3, =
unsigned long *p4, unsigned long *p5)=0A-{=0A-        unsigned int lines =
=3D bytes >> 8;=0A-	xmm_store_t xmm_save[4];=0A-	unsigned long =
cr0;=0A-=0A-	XMMS_SAVE;=0A-=0A-        __asm__ __volatile__ (=0A-#undef =
BLOCK=0A-#define BLOCK(i) \=0A-		PF1(i)					=
\=0A-				PF1(i+2)		\=0A-		=
LD(i,0)					\=0A-			LD(i+1,1)	=
		\=0A-				LD(i+2,2)		=
\=0A-					LD(i+3,3)	\=0A-		=
PF2(i)					\=0A-				=
PF2(i+2)		\=0A-		XO1(i,0)				=
\=0A-			XO1(i+1,1)			\=0A-			=
	XO1(i+2,2)		\=0A-					=
XO1(i+3,3)	\=0A-		PF3(i)					=
\=0A-				PF3(i+2)		\=0A-		=
XO2(i,0)				\=0A-			XO2(i+1,1)	=
		\=0A-				XO2(i+2,2)		=
\=0A-					XO2(i+3,3)	\=0A-		=
PF4(i)					\=0A-				=
PF4(i+2)		\=0A-		PF0(i+4)				=
\=0A-				PF0(i+6)		\=0A-		=
XO3(i,0)				\=0A-			XO3(i+1,1)	=
		\=0A-				XO3(i+2,2)		=
\=0A-					XO3(i+3,3)	\=0A-		=
XO4(i,0)				\=0A-			XO4(i+1,1)	=
		\=0A-				XO4(i+2,2)		=
\=0A-					XO4(i+3,3)	\=0A-		=
ST(i,0)					\=0A-			ST(i+1,1)	=
		\=0A-				ST(i+2,2)		=
\=0A-					ST(i+3,3)	\=0A-=0A-=0A-		=
PF0(0)=0A-				PF0(2)=0A-=0A-	" .align 32		=
	;\n"=0A-        " 1:                            ;\n"=0A-=0A-		=
BLOCK(0)=0A-		BLOCK(4)=0A-		BLOCK(8)=0A-		=
BLOCK(12)=0A-=0A-        "       addq %[inc], %[p1]           ;\n"=0A-     =
   "       addq %[inc], %[p2]           ;\n"=0A-        "       addq =
%[inc], %[p3]           ;\n"=0A-        "       addq %[inc], %[p4]         =
  ;\n"=0A-        "       addq %[inc], %[p5]           ;\n"=0A-	"	=
decl %[cnt] ; jnz 1b"=0A-	: [cnt] "+c" (lines),=0A-  	  [p1] =
"+r" (p1), [p2] "+r" (p2), [p3] "+r" (p3), [p4] "+r" (p4), =0A-	  [p5] =
"+r" (p5)=0A-	: [inc] "r" (256UL)=0A-	: "memory");=0A-=0A-	XMMS_RESTOR=
E;=0A-}=0A-=0A-static struct xor_block_template xor_block_sse =3D {=0A-    =
    .name =3D "generic_sse",=0A-        .do_2 =3D xor_sse_2,=0A-        =
.do_3 =3D xor_sse_3,=0A-        .do_4 =3D xor_sse_4,=0A-        .do_5 =3D =
xor_sse_5,=0A-};=0A+/* Also try the generic routines.  */=0A+#undef =
XOR_TRY_TEMPLATES=0A+#include <asm-generic/xor.h>=0A =0A #undef XOR_TRY_TEM=
PLATES=0A-#define XOR_TRY_TEMPLATES				\=0A-	do =
{						\=0A+#define XOR_TRY_TEMPLA=
TES			\=0A+	do {					=
\=0A+		xor_speed(&xor_block_8regs);	\=0A+		xor_speed(&=
xor_block_8regs_p);	\=0A+		xor_speed(&xor_block_32regs);	=
\=0A+		xor_speed(&xor_block_32regs_p);	\=0A 		xor_speed(&=
xor_block_sse);	\=0A 	} while (0)=0A-=0A-/* We force the use of the SSE =
xor block because it can write around L2.=0A-   We may also be able to =
load into the L1 only depending on how the cpu=0A-   deals with a load to =
a line that is being prefetched.  */=0A-#define XOR_SELECT_TEMPLATE(FASTEST=
) (&xor_block_sse)=0A--- a/include/asm-x86_64/xor.h=0A+++ b/include/asm-x86=
_64/xor.h=0A@@ -39,14 +39,14 @@ typedef struct { unsigned long a,b; } =
__=0A    tell it to do a clts before the register saving. */=0A #define =
XMMS_SAVE do {				\=0A 	preempt_disable();		=
	\=0A+	cr0 =3D read_cr0();			\=0A+	clts();		=
			\=0A 	asm volatile (				=
\=0A-		"movq %%cr0,%0		;\n\t"	\=0A-		"clts		=
	;\n\t"	\=0A 		"movups %%xmm0,(%1)	;\n\t"	\=0A 		=
"movups %%xmm1,0x10(%1)	;\n\t"	\=0A 		"movups %%xmm2,0x20(%1)	=
;\n\t"	\=0A 		"movups %%xmm3,0x30(%1)	;\n\t"	\=0A-		: =
"=3D&r" (cr0)			\=0A+		: "+r" (cr0)			=
\=0A 		: "r" (xmm_save) 		\=0A 		: =
"memory");			\=0A } while(0)=0A@@ -58,10 +58,10 @@ =
typedef struct { unsigned long a,b; } __=0A 		"movups 0x10(%1),%%=
xmm1	;\n\t"	\=0A 		"movups 0x20(%1),%%xmm2	;\n\t"	\=0A 		=
"movups 0x30(%1),%%xmm3	;\n\t"	\=0A-		"movq 	%0,%%cr0	=
;\n\t"	\=0A 		:				\=0A 		: =
"r" (cr0), "r" (xmm_save)	\=0A 		: "memory");			=
\=0A+	write_cr0(cr0);				\=0A 	preempt_enable();	=
		\=0A } while(0)=0A =0A
--=__PartBA9415CB.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

--=__PartBA9415CB.0__=--


From xen-devel-bounces@lists.xen.org Fri Jun 29 14:40:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcMI-0004dT-Id; Fri, 29 Jun 2012 14:39:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcMH-0004dO-H7
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:39:41 +0000
Received: from [85.158.139.83:29876] by server-10.bemta-5.messagelabs.com id
	D2/FA-02190-C2EBDEF4; Fri, 29 Jun 2012 14:39:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340980780!22979767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5174 invoked from network); 29 Jun 2012 14:39:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:39:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:39:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcMF-0000b3-5F; Fri, 29 Jun 2012 14:39:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcMF-0006WM-2p;
	Fri, 29 Jun 2012 15:39:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.48683.50315.766843@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:39:39 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340896233-9523-1-git-send-email-roger.pau@citrix.com>
References: <1340896233-9523-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] autoconf: correctly parse *_INCLUDES
	and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
> Parse those options correctly, since the "+=" operator is not valid.
> Also added CPPFLAGS, so headers checks don't give strange results.
> 
> Please rerun configure after applying.
> 
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Christoph Egger <Christoph.Egger@amd.com>
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:40:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcMI-0004dT-Id; Fri, 29 Jun 2012 14:39:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcMH-0004dO-H7
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:39:41 +0000
Received: from [85.158.139.83:29876] by server-10.bemta-5.messagelabs.com id
	D2/FA-02190-C2EBDEF4; Fri, 29 Jun 2012 14:39:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1340980780!22979767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5174 invoked from network); 29 Jun 2012 14:39:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:39:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:39:39 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcMF-0000b3-5F; Fri, 29 Jun 2012 14:39:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcMF-0006WM-2p;
	Fri, 29 Jun 2012 15:39:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.48683.50315.766843@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:39:39 +0100
To: Roger Pau Monne <roger.pau@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340896233-9523-1-git-send-email-roger.pau@citrix.com>
References: <1340896233-9523-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] autoconf: correctly parse *_INCLUDES
	and	*_LIB env vars
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
> Parse those options correctly, since the "+=" operator is not valid.
> Also added CPPFLAGS, so headers checks don't give strange results.
> 
> Please rerun configure after applying.
> 
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Christoph Egger <Christoph.Egger@amd.com>
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcPt-0004uj-Tb; Fri, 29 Jun 2012 14:43: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 1SkcPs-0004uR-4q
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:43:24 +0000
Received: from [85.158.138.51:23571] by server-1.bemta-3.messagelabs.com id
	7A/D2-14648-B0FBDEF4; Fri, 29 Jun 2012 14:43:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340981002!21090594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 29 Jun 2012 14:43:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:43:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:43:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcPq-0000cG-8J; Fri, 29 Jun 2012 14:43:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcPq-0006ZK-6W;
	Fri, 29 Jun 2012 15:43:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.48906.189607.20745@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:43:22 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b2481fe8a39516413d35.1340899114@whitby.uk.xensource.com>
References: <b2481fe8a39516413d35.1340899114@whitby.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: various typos
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[Xen-devel] [PATCH] docs: various typos"):
> docs: various typos

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcPt-0004uj-Tb; Fri, 29 Jun 2012 14:43: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 1SkcPs-0004uR-4q
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:43:24 +0000
Received: from [85.158.138.51:23571] by server-1.bemta-3.messagelabs.com id
	7A/D2-14648-B0FBDEF4; Fri, 29 Jun 2012 14:43:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1340981002!21090594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 29 Jun 2012 14:43:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:43:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:43:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcPq-0000cG-8J; Fri, 29 Jun 2012 14:43:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcPq-0006ZK-6W;
	Fri, 29 Jun 2012 15:43:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.48906.189607.20745@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:43:22 +0100
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b2481fe8a39516413d35.1340899114@whitby.uk.xensource.com>
References: <b2481fe8a39516413d35.1340899114@whitby.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: various typos
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[Xen-devel] [PATCH] docs: various typos"):
> docs: various typos

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:43:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcQ5-0004wB-AA; Fri, 29 Jun 2012 14:43:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcQ4-0004vy-KF
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:43:36 +0000
Received: from [85.158.138.51:24795] by server-12.bemta-3.messagelabs.com id
	26/BF-30206-71FBDEF4; Fri, 29 Jun 2012 14:43:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340981015!29065715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11231 invoked from network); 29 Jun 2012 14:43:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:43:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:43:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:43:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcQ2-0000cN-Px; Fri, 29 Jun 2012 14:43:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcQ2-0006ZU-P6;
	Fri, 29 Jun 2012 15:43:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.48918.765400.392158@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:43:34 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a84d4165d5f8cc05f4f8.1340903211@kaos-source-31003.sea31.amazon.com>
References: <a84d4165d5f8cc05f4f8.1340903211@kaos-source-31003.sea31.amazon.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
Subject: Re: [Xen-devel] [PATCH v3] xl: rename "list-vm" command to "vm-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

Matt Wilson writes ("[Xen-devel] [PATCH v3] xl: rename "list-vm" command to "vm-list""):
> All of the other "list" verbs are of the form "$noun-list". For
> example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> 
> Additionally, many people have well trained muscle memory from years
> of typing "xm li". "xl li" was ambiguous due to "xl list-vm", thus
> resulting in "command not implemented".
> 
> Finally, this command was missing from the xl man page.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:43:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcQ5-0004wB-AA; Fri, 29 Jun 2012 14:43:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcQ4-0004vy-KF
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:43:36 +0000
Received: from [85.158.138.51:24795] by server-12.bemta-3.messagelabs.com id
	26/BF-30206-71FBDEF4; Fri, 29 Jun 2012 14:43:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1340981015!29065715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11231 invoked from network); 29 Jun 2012 14:43:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:43:35 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:43:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:43:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcQ2-0000cN-Px; Fri, 29 Jun 2012 14:43:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcQ2-0006ZU-P6;
	Fri, 29 Jun 2012 15:43:34 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.48918.765400.392158@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:43:34 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a84d4165d5f8cc05f4f8.1340903211@kaos-source-31003.sea31.amazon.com>
References: <a84d4165d5f8cc05f4f8.1340903211@kaos-source-31003.sea31.amazon.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
Subject: Re: [Xen-devel] [PATCH v3] xl: rename "list-vm" command to "vm-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

Matt Wilson writes ("[Xen-devel] [PATCH v3] xl: rename "list-vm" command to "vm-list""):
> All of the other "list" verbs are of the form "$noun-list". For
> example: "pci-list", "vcpu-list", "network-list", "block-list", etc.
> 
> Additionally, many people have well trained muscle memory from years
> of typing "xm li". "xl li" was ambiguous due to "xl list-vm", thus
> resulting in "command not implemented".
> 
> Finally, this command was missing from the xl man page.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:45:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcRk-0005Co-8k; Fri, 29 Jun 2012 14:45:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcRi-0005CW-VW
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:45:19 +0000
Received: from [85.158.143.99:41760] by server-2.bemta-4.messagelabs.com id
	AF/53-17938-E7FBDEF4; Fri, 29 Jun 2012 14:45:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340981116!26443630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9335 invoked from network); 29 Jun 2012 14:45:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:45:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:45:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcRg-0000cv-5Q; Fri, 29 Jun 2012 14:45:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcRg-0006Zs-4X;
	Fri, 29 Jun 2012 15:45:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49020.125023.198959@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:45:16 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> The following fixes recent test failures reboot a guest (e.g. flight
> 13302).

Patches 2..5:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

1 was applied earlier.

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 Jun 29 14:45:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcRk-0005Co-8k; Fri, 29 Jun 2012 14:45:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcRi-0005CW-VW
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:45:19 +0000
Received: from [85.158.143.99:41760] by server-2.bemta-4.messagelabs.com id
	AF/53-17938-E7FBDEF4; Fri, 29 Jun 2012 14:45:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1340981116!26443630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9335 invoked from network); 29 Jun 2012 14:45:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:45:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:45:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcRg-0000cv-5Q; Fri, 29 Jun 2012 14:45:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcRg-0006Zs-4X;
	Fri, 29 Jun 2012 15:45:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49020.125023.198959@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:45:16 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1340362609@cosworth.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> The following fixes recent test failures reboot a guest (e.g. flight
> 13302).

Patches 2..5:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

1 was applied earlier.

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 Jun 29 14:48:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 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 1SkcUi-0005Sd-0B; Fri, 29 Jun 2012 14:48:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcUg-0005SO-9M
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:48:22 +0000
Received: from [85.158.143.35:46446] by server-2.bemta-4.messagelabs.com id
	1A/28-17938-530CDEF4; Fri, 29 Jun 2012 14:48:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340981301!16349085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23922 invoked from network); 29 Jun 2012 14:48:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:48:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:48:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:48:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcUe-0000e5-9a; Fri, 29 Jun 2012 14:48:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcUe-0006aH-8V;
	Fri, 29 Jun 2012 15:48:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49204.15647.401794@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:48:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340638948.3832.25.camel@zakaz.uk.xensource.com>
References: <4FE43D1C.8020600@citrix.com>
	<20120625152705.GB4210@phenom.dumpdata.com>
	<1340638948.3832.25.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS
 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

Ian Campbell writes ("Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS file"):
> The original patch is:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:48:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 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 1SkcUi-0005Sd-0B; Fri, 29 Jun 2012 14:48:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcUg-0005SO-9M
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:48:22 +0000
Received: from [85.158.143.35:46446] by server-2.bemta-4.messagelabs.com id
	1A/28-17938-530CDEF4; Fri, 29 Jun 2012 14:48:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340981301!16349085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23922 invoked from network); 29 Jun 2012 14:48:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:48:21 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:48:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:48:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcUe-0000e5-9a; Fri, 29 Jun 2012 14:48:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcUe-0006aH-8V;
	Fri, 29 Jun 2012 15:48:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49204.15647.401794@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:48:20 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340638948.3832.25.camel@zakaz.uk.xensource.com>
References: <4FE43D1C.8020600@citrix.com>
	<20120625152705.GB4210@phenom.dumpdata.com>
	<1340638948.3832.25.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS
 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

Ian Campbell writes ("Re: [Xen-devel] Update xen-devel email address in the MAINTAINERS file"):
> The original patch is:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:50:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14:50: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 1SkcWR-0005bi-Gg; Fri, 29 Jun 2012 14:50:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkcWQ-0005bH-0T
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:50:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340981404!2443780!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2379 invoked from network); 29 Jun 2012 14:50:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:50:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:48:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 15:48:57 +0100
Message-ID: <1340981336.10942.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 15:48:56 +0100
In-Reply-To: <20461.49020.125023.198959@mariner.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<20461.49020.125023.198959@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 15:45 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > The following fixes recent test failures reboot a guest (e.g. flight
> > 13302).
> 
> Patches 2..5:

I sent out a V2 of this series with the (trivial) reject fixed. I guess
you fixed that yourself?

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> 1 was applied earlier.
> 
> 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 Jun 29 14:50:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14:50: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 1SkcWR-0005bi-Gg; Fri, 29 Jun 2012 14:50:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkcWQ-0005bH-0T
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:50:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1340981404!2443780!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2379 invoked from network); 29 Jun 2012 14:50:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:50:04 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13294917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:48:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 15:48:57 +0100
Message-ID: <1340981336.10942.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 15:48:56 +0100
In-Reply-To: <20461.49020.125023.198959@mariner.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<20461.49020.125023.198959@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 15:45 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > The following fixes recent test failures reboot a guest (e.g. flight
> > 13302).
> 
> Patches 2..5:

I sent out a V2 of this series with the (trivial) reject fixed. I guess
you fixed that yourself?

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> 1 was applied earlier.
> 
> 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 Jun 29 14:52:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcYL-0005ou-N7; Fri, 29 Jun 2012 14:52:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcYJ-0005oU-S8
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:52:08 +0000
Received: from [85.158.143.99:31778] by server-1.bemta-4.messagelabs.com id
	BE/7D-24392-711CDEF4; Fri, 29 Jun 2012 14:52:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340981526!29833810!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22226 invoked from network); 29 Jun 2012 14:52:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:52:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13295003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:51:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:51:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcXX-0000gX-2s; Fri, 29 Jun 2012 14:51:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcXX-0006ap-1s;
	Fri, 29 Jun 2012 15:51:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49383.43916.927258@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:51:19 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340981336.10942.128.camel@zakaz.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<20461.49020.125023.198959@mariner.uk.xensource.com>
	<1340981336.10942.128.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0 of 5] xl: fix guest reboot failures"):
> On Fri, 2012-06-29 at 15:45 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > > The following fixes recent test failures reboot a guest (e.g. flight
> > > 13302).
> > 
> > Patches 2..5:
> 
> I sent out a V2 of this series with the (trivial) reject fixed. I guess
> you fixed that yourself?

I just replied to the wrong 0 of 5.  There wasn't any reject and I
applied v2 of the series.

Sorry for the confusion.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:52:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1SkcYL-0005ou-N7; Fri, 29 Jun 2012 14:52:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcYJ-0005oU-S8
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:52:08 +0000
Received: from [85.158.143.99:31778] by server-1.bemta-4.messagelabs.com id
	BE/7D-24392-711CDEF4; Fri, 29 Jun 2012 14:52:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1340981526!29833810!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22226 invoked from network); 29 Jun 2012 14:52:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:52:06 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13295003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:51:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:51:19 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcXX-0000gX-2s; Fri, 29 Jun 2012 14:51:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcXX-0006ap-1s;
	Fri, 29 Jun 2012 15:51:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49383.43916.927258@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:51:19 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340981336.10942.128.camel@zakaz.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<20461.49020.125023.198959@mariner.uk.xensource.com>
	<1340981336.10942.128.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0 of 5] xl: fix guest reboot failures"):
> On Fri, 2012-06-29 at 15:45 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > > The following fixes recent test failures reboot a guest (e.g. flight
> > > 13302).
> > 
> > Patches 2..5:
> 
> I sent out a V2 of this series with the (trivial) reject fixed. I guess
> you fixed that yourself?

I just replied to the wrong 0 of 5.  There wasn't any reject and I
applied v2 of the series.

Sorry for the confusion.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14:53: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 1SkcZN-0005yR-6L; Fri, 29 Jun 2012 14:53:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcZL-0005y1-Ld
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:53:11 +0000
Received: from [85.158.143.35:51120] by server-1.bemta-4.messagelabs.com id
	9A/FE-24392-751CDEF4; Fri, 29 Jun 2012 14:53:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340981587!11706132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8914 invoked from network); 29 Jun 2012 14:53:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13295062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:52:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:52:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcZ5-0000h6-Mo; Fri, 29 Jun 2012 14:52:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcZ5-0006b5-Lx;
	Fri, 29 Jun 2012 15:52:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49479.666036.529138@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:52:55 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
References: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] tools: honour --libdir when it is passed
	to	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("[Xen-devel] [PATCH v3] tools: honour --libdir when it is passed to ./configure"):
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Thanks for this.  FYI I intend to commit this before 4.2rc1.  However
I think it has a good chance of breaking something (eg, the test
pushes).

So I want to wait until we don't have a big patch series also waiting
in staging.

I've marked the message to return but please do feel free to remind me
if I seem to have forgotten 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 Jun 29 14:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14:53: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 1SkcZN-0005yR-6L; Fri, 29 Jun 2012 14:53:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkcZL-0005y1-Ld
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:53:11 +0000
Received: from [85.158.143.35:51120] by server-1.bemta-4.messagelabs.com id
	9A/FE-24392-751CDEF4; Fri, 29 Jun 2012 14:53:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1340981587!11706132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8914 invoked from network); 29 Jun 2012 14:53:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13295062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:52:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 15:52:55 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkcZ5-0000h6-Mo; Fri, 29 Jun 2012 14:52:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkcZ5-0006b5-Lx;
	Fri, 29 Jun 2012 15:52:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.49479.666036.529138@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 15:52:55 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
References: <177d5f1e353fe4001f69.1340485933@kaos-source-31003.sea31.amazon.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] tools: honour --libdir when it is passed
	to	./configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matt Wilson writes ("[Xen-devel] [PATCH v3] tools: honour --libdir when it is passed to ./configure"):
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Thanks for this.  FYI I intend to commit this before 4.2rc1.  However
I think it has a good chance of breaking something (eg, the test
pushes).

So I want to wait until we don't have a big patch series also waiting
in staging.

I've marked the message to return but please do feel free to remind me
if I seem to have forgotten 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 Jun 29 14:54:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1Skcah-0006AH-MS; Fri, 29 Jun 2012 14:54: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 1Skcag-0006A4-Ic
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:54:34 +0000
Received: from [85.158.139.83:39330] by server-6.bemta-5.messagelabs.com id
	E3/03-11348-9A1CDEF4; Fri, 29 Jun 2012 14:54:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340981673!27491419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31006 invoked from network); 29 Jun 2012 14:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13295116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:54:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 15:54:32 +0100
Message-ID: <1340981671.10942.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 15:54:31 +0100
In-Reply-To: <20461.49383.43916.927258@mariner.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<20461.49020.125023.198959@mariner.uk.xensource.com>
	<1340981336.10942.128.camel@zakaz.uk.xensource.com>
	<20461.49383.43916.927258@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 15:51 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > On Fri, 2012-06-29 at 15:45 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > > > The following fixes recent test failures reboot a guest (e.g. flight
> > > > 13302).
> > > 
> > > Patches 2..5:
> > 
> > I sent out a V2 of this series with the (trivial) reject fixed. I guess
> > you fixed that yourself?
> 
> I just replied to the wrong 0 of 5.  There wasn't any reject and I
> applied v2 of the series.

Grand!

> Sorry for the confusion.

No worries.

Ian.

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 14:54:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 14: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 1Skcah-0006AH-MS; Fri, 29 Jun 2012 14:54: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 1Skcag-0006A4-Ic
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 14:54:34 +0000
Received: from [85.158.139.83:39330] by server-6.bemta-5.messagelabs.com id
	E3/03-11348-9A1CDEF4; Fri, 29 Jun 2012 14:54:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1340981673!27491419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31006 invoked from network); 29 Jun 2012 14:54:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 14:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13295116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 14:54:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 15:54:32 +0100
Message-ID: <1340981671.10942.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 15:54:31 +0100
In-Reply-To: <20461.49383.43916.927258@mariner.uk.xensource.com>
References: <patchbomb.1340362609@cosworth.uk.xensource.com>
	<20461.49020.125023.198959@mariner.uk.xensource.com>
	<1340981336.10942.128.camel@zakaz.uk.xensource.com>
	<20461.49383.43916.927258@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 15:51 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > On Fri, 2012-06-29 at 15:45 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("[Xen-devel] [PATCH 0 of 5] xl: fix guest reboot failures"):
> > > > The following fixes recent test failures reboot a guest (e.g. flight
> > > > 13302).
> > > 
> > > Patches 2..5:
> > 
> > I sent out a V2 of this series with the (trivial) reject fixed. I guess
> > you fixed that yourself?
> 
> I just replied to the wrong 0 of 5.  There wasn't any reject and I
> applied v2 of the series.

Grand!

> Sorry for the confusion.

No worries.

Ian.

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 15:48:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 15:48: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 1SkdQX-0007V7-Pl; Fri, 29 Jun 2012 15:48: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 1SkdQW-0007V1-Hn
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 15:48:08 +0000
Received: from [85.158.138.51:36209] by server-6.bemta-3.messagelabs.com id
	16/C5-11602-73ECDEF4; Fri, 29 Jun 2012 15:48:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340984887!22096111!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 29 Jun 2012 15:48:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 15:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 15:48:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 16:48:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkdQU-00013S-SG; Fri, 29 Jun 2012 15:48:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkdQU-0006fg-OS;
	Fri, 29 Jun 2012 16:48:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.52790.615264.828985@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 16:48:06 +0100
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FE85DFF020000780008BA95@nat28.tlf.novell.com>
References: <4FE85DFF020000780008BA95@nat28.tlf.novell.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] qemu-traditional/xendisk: properly update
 stats in ioreq_release()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[Xen-devel] [PATCH] qemu-traditional/xendisk: properly update stats in ioreq_release()"):
> While for the "normal" case (called from blk_send_response_all())
> decrementing requests_finished is correct, doing so in the parse error
> case is wrong; requests_inflight needs to be decremented instead.
> 
> upstream-commit: ed5477664369c1e9de23b0e7e8f16a418573bd2a

Thanks, committed to qemu-xen-traditional.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 15:48:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 15:48: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 1SkdQX-0007V7-Pl; Fri, 29 Jun 2012 15:48: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 1SkdQW-0007V1-Hn
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 15:48:08 +0000
Received: from [85.158.138.51:36209] by server-6.bemta-3.messagelabs.com id
	16/C5-11602-73ECDEF4; Fri, 29 Jun 2012 15:48:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340984887!22096111!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 29 Jun 2012 15:48:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 15:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 15:48:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 16:48:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkdQU-00013S-SG; Fri, 29 Jun 2012 15:48:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkdQU-0006fg-OS;
	Fri, 29 Jun 2012 16:48:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.52790.615264.828985@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 16:48:06 +0100
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FE85DFF020000780008BA95@nat28.tlf.novell.com>
References: <4FE85DFF020000780008BA95@nat28.tlf.novell.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] qemu-traditional/xendisk: properly update
 stats in ioreq_release()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[Xen-devel] [PATCH] qemu-traditional/xendisk: properly update stats in ioreq_release()"):
> While for the "normal" case (called from blk_send_response_all())
> decrementing requests_finished is correct, doing so in the parse error
> case is wrong; requests_inflight needs to be decremented instead.
> 
> upstream-commit: ed5477664369c1e9de23b0e7e8f16a418573bd2a

Thanks, committed to qemu-xen-traditional.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 15:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 15:49: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 1SkdRf-0007YR-8U; Fri, 29 Jun 2012 15:49:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1SkdRd-0007YI-IB
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 15:49:17 +0000
Received: from [85.158.143.99:62983] by server-1.bemta-4.messagelabs.com id
	88/CE-24392-C7ECDEF4; Fri, 29 Jun 2012 15:49:16 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340984955!29499159!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4260 invoked from network); 29 Jun 2012 15:49:16 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 15:49:16 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 5D220FE291
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:49:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=postfix; bh=pgbaFo5qv
	i3J9jvPMCy3JQVKi1w=; b=vEHjk1dcah/ZSaT4ryPeBR40C/NTLEH3Bzn/mEmce
	BfwpWLuQZxmMYjj17SMfqAIT2CIiiviz+kVwgT86ZzvjvrLGf1E+VUpPk94dFHRu
	xsmqsVgXK8xELe0PbChyFkdqwRsZ4aGFYaYTnzkL7r3GBcmQznQL/bF93aj3S3mv
	s4=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=postfix; b=Z8F
	SxVvDbtXjCPOkP04lJew5G3pS+dr04cz4vdCRvj6kAJbBcjXMyue0zx02o9v4qb/
	67l/LTbfxGrLtjCt+xcGn/BqKu/7TkSwd7Tfoku5989QbqsMXqMPiQiT/SsZkWUV
	4D31gtpoYpA69hWanMtfFE5HTtlT6SmYYBZzdLrA=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id 79C04FE28C
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:49:04 +0000 (UTC)
Message-ID: <4FEDCE59.6020003@goirand.fr>
Date: Fri, 29 Jun 2012 23:48:41 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120506 Icedove/3.0.11
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>	<4FEB4BDD.5040205@goirand.fr>
	<CAFLBxZYWnW_d8YDeFdzjdUhyysqxd12gPU4Pr6Rj7LQjtLwx+A@mail.gmail.com>
In-Reply-To: <CAFLBxZYWnW_d8YDeFdzjdUhyysqxd12gPU4Pr6Rj7LQjtLwx+A@mail.gmail.com>
X-Enigmail-Version: 1.0.1
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/29/2012 06:01 PM, George Dunlap wrote:
> On Wed, Jun 27, 2012 at 7:07 PM, Thomas Goirand <thomas@goirand.fr> wrote:
>> On 06/20/2012 05:45 PM, George Dunlap wrote:
>>> The only way this would work is if the predisclosure list consisted
>>> exclusively of software providers, and specifically excluded service
>>> providers.
>> I agree, though you might have corner cases.
>>
>> What if you are *both* software and service provider (eg: I'm working on
>> Debian and XCP, and my small company provides a hosted Xen service)?
> 
> If we do make a rule that only software providers can be on the list,
> and not service providers, then ideally you should try to separate the
> roles.  If you are on the list as a software provider, you should use
> that information only to prepare patches; but not deploy them on your
> own systems until the embargo date.
> 
> In a way, the question is very similar to asking, "I'm working on
> Debian and XCP, and my best friend owns a small company that provides
> a hosted Xen service."  If you told your friend about the
> vulnerability, you would be breaking the security embargo (and giving
> your friend an unfair advantage over other hosting services), and
> would be at risk of being removed from the list if someone found out.
> If you wear two "hats", as it were, the same would be true if your
> developer "hat" told your service provider "hat": actually updating
> your systems before the embargo would (I think) be considered breaking
> the embargo, and would be giving yourself an unfair advantage over
> other hosting services.
> 
> (All of the above discussion is, of course, only valid in the
> hypothetical situation that we don't allow service providers to be on
> the list.)
> 
>  -George

Exactly what I think as well. I'm happy you wrote the above.

Thomas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 15:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 15:49: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 1SkdRf-0007YR-8U; Fri, 29 Jun 2012 15:49:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1SkdRd-0007YI-IB
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 15:49:17 +0000
Received: from [85.158.143.99:62983] by server-1.bemta-4.messagelabs.com id
	88/CE-24392-C7ECDEF4; Fri, 29 Jun 2012 15:49:16 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-5.tower-216.messagelabs.com!1340984955!29499159!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4260 invoked from network); 29 Jun 2012 15:49:16 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 15:49:16 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 5D220FE291
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:49:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=postfix; bh=pgbaFo5qv
	i3J9jvPMCy3JQVKi1w=; b=vEHjk1dcah/ZSaT4ryPeBR40C/NTLEH3Bzn/mEmce
	BfwpWLuQZxmMYjj17SMfqAIT2CIiiviz+kVwgT86ZzvjvrLGf1E+VUpPk94dFHRu
	xsmqsVgXK8xELe0PbChyFkdqwRsZ4aGFYaYTnzkL7r3GBcmQznQL/bF93aj3S3mv
	s4=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=postfix; b=Z8F
	SxVvDbtXjCPOkP04lJew5G3pS+dr04cz4vdCRvj6kAJbBcjXMyue0zx02o9v4qb/
	67l/LTbfxGrLtjCt+xcGn/BqKu/7TkSwd7Tfoku5989QbqsMXqMPiQiT/SsZkWUV
	4D31gtpoYpA69hWanMtfFE5HTtlT6SmYYBZzdLrA=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id 79C04FE28C
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:49:04 +0000 (UTC)
Message-ID: <4FEDCE59.6020003@goirand.fr>
Date: Fri, 29 Jun 2012 23:48:41 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120506 Icedove/3.0.11
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>	<4FEB4BDD.5040205@goirand.fr>
	<CAFLBxZYWnW_d8YDeFdzjdUhyysqxd12gPU4Pr6Rj7LQjtLwx+A@mail.gmail.com>
In-Reply-To: <CAFLBxZYWnW_d8YDeFdzjdUhyysqxd12gPU4Pr6Rj7LQjtLwx+A@mail.gmail.com>
X-Enigmail-Version: 1.0.1
Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/29/2012 06:01 PM, George Dunlap wrote:
> On Wed, Jun 27, 2012 at 7:07 PM, Thomas Goirand <thomas@goirand.fr> wrote:
>> On 06/20/2012 05:45 PM, George Dunlap wrote:
>>> The only way this would work is if the predisclosure list consisted
>>> exclusively of software providers, and specifically excluded service
>>> providers.
>> I agree, though you might have corner cases.
>>
>> What if you are *both* software and service provider (eg: I'm working on
>> Debian and XCP, and my small company provides a hosted Xen service)?
> 
> If we do make a rule that only software providers can be on the list,
> and not service providers, then ideally you should try to separate the
> roles.  If you are on the list as a software provider, you should use
> that information only to prepare patches; but not deploy them on your
> own systems until the embargo date.
> 
> In a way, the question is very similar to asking, "I'm working on
> Debian and XCP, and my best friend owns a small company that provides
> a hosted Xen service."  If you told your friend about the
> vulnerability, you would be breaking the security embargo (and giving
> your friend an unfair advantage over other hosting services), and
> would be at risk of being removed from the list if someone found out.
> If you wear two "hats", as it were, the same would be true if your
> developer "hat" told your service provider "hat": actually updating
> your systems before the embargo would (I think) be considered breaking
> the embargo, and would be giving yourself an unfair advantage over
> other hosting services.
> 
> (All of the above discussion is, of course, only valid in the
> hypothetical situation that we don't allow service providers to be on
> the list.)
> 
>  -George

Exactly what I think as well. I'm happy you wrote the above.

Thomas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16: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 1Skdeh-0008FE-Jv; Fri, 29 Jun 2012 16:02:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Skdeg-0008F6-6c
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:02:46 +0000
Received: from [85.158.138.51:24934] by server-5.bemta-3.messagelabs.com id
	F8/DF-01572-5A1DDEF4; Fri, 29 Jun 2012 16:02:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340985764!22160201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30732 invoked from network); 29 Jun 2012 16:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:01:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 17:01:43 +0100
Message-ID: <1340985702.10942.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 29 Jun 2012 17:01:42 +0100
In-Reply-To: <alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] Rlibxl: refuse to try and migrate an HVM guest
 using 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

> I think we should add an appropriate error message as a blocker. We
> should also try to fix this on the QEMU side, but given that the QEMU
> 1.0 stable tree is pretty much unmaintaned, we won't be able to backport
> the fix there, so we cannot be sure that a distro will end up with a
> QEMU with or without the fix.

How about this for the time being, we can always revert or enhance as
necessary before 4.2.

8<----------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340985595 -3600
# Node ID a0c1c8c585e03279f9ea149bc2951d0df900717e
# Parent  d849ca2ef197dbf0e731aa4726da0eb3e2801280
libxl: refuse to try and migrate an HVM guest using qemu-xen

libxl/qemu-upstream currently do not collude together to enable log-dirty mode
and therefore migrations are unsafe. Refuse to even try for now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d849ca2ef197 -r a0c1c8c585e0 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jun 29 15:57:28 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jun 29 16:59:55 2012 +0100
@@ -746,6 +746,17 @@ int libxl_domain_suspend(libxl_ctx *ctx,
         goto out_err;
     }
 
+    libxl_device_model_version dm =
+        libxl__device_model_version_running(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_HVM &&
+        dm == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN &&
+        flags & LIBXL_SUSPEND_LIVE) {
+        LOG(ERROR, "cannot live migrate HVM domains with qemu-xen device-model");
+        rc = ERROR_FAIL;
+        goto out_err;
+
+    }
+
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16: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 1Skdeh-0008FE-Jv; Fri, 29 Jun 2012 16:02:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Skdeg-0008F6-6c
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:02:46 +0000
Received: from [85.158.138.51:24934] by server-5.bemta-3.messagelabs.com id
	F8/DF-01572-5A1DDEF4; Fri, 29 Jun 2012 16:02:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1340985764!22160201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30732 invoked from network); 29 Jun 2012 16:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:01:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 17:01:43 +0100
Message-ID: <1340985702.10942.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 29 Jun 2012 17:01:42 +0100
In-Reply-To: <alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] Rlibxl: refuse to try and migrate an HVM guest
 using 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

> I think we should add an appropriate error message as a blocker. We
> should also try to fix this on the QEMU side, but given that the QEMU
> 1.0 stable tree is pretty much unmaintaned, we won't be able to backport
> the fix there, so we cannot be sure that a distro will end up with a
> QEMU with or without the fix.

How about this for the time being, we can always revert or enhance as
necessary before 4.2.

8<----------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1340985595 -3600
# Node ID a0c1c8c585e03279f9ea149bc2951d0df900717e
# Parent  d849ca2ef197dbf0e731aa4726da0eb3e2801280
libxl: refuse to try and migrate an HVM guest using qemu-xen

libxl/qemu-upstream currently do not collude together to enable log-dirty mode
and therefore migrations are unsafe. Refuse to even try for now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d849ca2ef197 -r a0c1c8c585e0 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jun 29 15:57:28 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jun 29 16:59:55 2012 +0100
@@ -746,6 +746,17 @@ int libxl_domain_suspend(libxl_ctx *ctx,
         goto out_err;
     }
 
+    libxl_device_model_version dm =
+        libxl__device_model_version_running(gc, domid);
+    if (type == LIBXL_DOMAIN_TYPE_HVM &&
+        dm == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN &&
+        flags & LIBXL_SUSPEND_LIVE) {
+        LOG(ERROR, "cannot live migrate HVM domains with qemu-xen device-model");
+        rc = ERROR_FAIL;
+        goto out_err;
+
+    }
+
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Skdeo-0008Fw-57; Fri, 29 Jun 2012 16:02:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skdem-0008Fl-RA
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:02:52 +0000
Received: from [85.158.143.99:48068] by server-1.bemta-4.messagelabs.com id
	7C/FE-24392-CA1DDEF4; Fri, 29 Jun 2012 16:02:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340985764!28921923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32624 invoked from network); 29 Jun 2012 16:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:02:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:02:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skddw-00018B-Eu; Fri, 29 Jun 2012 16:02:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skddw-0007CB-E5;
	Fri, 29 Jun 2012 17:02:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.53624.422657.883263@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:02:00 +0100
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FE85D22020000780008BA8F@nat28.tlf.novell.com>
References: <4FE85D22020000780008BA8F@nat28.tlf.novell.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] qemu-traditional/xendisk: set maximum
 number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("[Xen-devel] [PATCH] qemu-traditional/xendisk: set maximum number of grants to be used"):
> Legacy (non-pvops) gntdev drivers may require this to be done when the
> number of grants intended to be used simultaneously exceeds a certain
> driver specific default limit.

Committed to qemu-xen-traditional, 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 Jun 29 16:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Skdeo-0008Fw-57; Fri, 29 Jun 2012 16:02:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skdem-0008Fl-RA
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:02:52 +0000
Received: from [85.158.143.99:48068] by server-1.bemta-4.messagelabs.com id
	7C/FE-24392-CA1DDEF4; Fri, 29 Jun 2012 16:02:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1340985764!28921923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32624 invoked from network); 29 Jun 2012 16:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:02:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:02:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skddw-00018B-Eu; Fri, 29 Jun 2012 16:02:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skddw-0007CB-E5;
	Fri, 29 Jun 2012 17:02:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.53624.422657.883263@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:02:00 +0100
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FE85D22020000780008BA8F@nat28.tlf.novell.com>
References: <4FE85D22020000780008BA8F@nat28.tlf.novell.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] qemu-traditional/xendisk: set maximum
 number of grants to be used
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("[Xen-devel] [PATCH] qemu-traditional/xendisk: set maximum number of grants to be used"):
> Legacy (non-pvops) gntdev drivers may require this to be done when the
> number of grants intended to be used simultaneously exceeds a certain
> driver specific default limit.

Committed to qemu-xen-traditional, 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 Jun 29 16:04:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Skdfi-0008P3-K5; Fri, 29 Jun 2012 16:03: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 1Skdfg-0008Oh-O1
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:03:48 +0000
Received: from [85.158.138.51:5402] by server-4.bemta-3.messagelabs.com id
	88/4B-17105-3E1DDEF4; Fri, 29 Jun 2012 16:03:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340985827!30328489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6342 invoked from network); 29 Jun 2012 16:03:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:03:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:03:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:03:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdfe-00018k-Kb; Fri, 29 Jun 2012 16:03:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skdfe-0007ET-Je;
	Fri, 29 Jun 2012 17:03:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.53730.596591.328470@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:03:46 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340985702.10942.136.camel@zakaz.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
	<1340985702.10942.136.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Rlibxl: refuse to try and migrate an HVM
 guest using 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 Campbell writes ("[PATCH] Rlibxl: refuse to try and migrate an HVM guest using qemu-xen"):
> > I think we should add an appropriate error message as a blocker. We
> > should also try to fix this on the QEMU side, but given that the QEMU
> > 1.0 stable tree is pretty much unmaintaned, we won't be able to backport
> > the fix there, so we cannot be sure that a distro will end up with a
> > QEMU with or without the fix.
> 
> How about this for the time being, we can always revert or enhance as
> necessary before 4.2.
...
> +    libxl_device_model_version dm =
> +        libxl__device_model_version_running(gc, domid);

libxl__device_model_version_running can return -1.  (Its error
handling is pretty bad but that's no excuse for making matters worse.)
I suggest we retcon it as returning a libxl error code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:04:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Skdfi-0008P3-K5; Fri, 29 Jun 2012 16:03: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 1Skdfg-0008Oh-O1
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:03:48 +0000
Received: from [85.158.138.51:5402] by server-4.bemta-3.messagelabs.com id
	88/4B-17105-3E1DDEF4; Fri, 29 Jun 2012 16:03:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1340985827!30328489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6342 invoked from network); 29 Jun 2012 16:03:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:03:47 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:03:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:03:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdfe-00018k-Kb; Fri, 29 Jun 2012 16:03:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skdfe-0007ET-Je;
	Fri, 29 Jun 2012 17:03:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.53730.596591.328470@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:03:46 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1340985702.10942.136.camel@zakaz.uk.xensource.com>
References: <osstest-13394-mainreport@xen.org>
	<20461.36759.685003.44867@mariner.uk.xensource.com>
	<1340970454.10942.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291327130.27860@kaball.uk.xensource.com>
	<1340973172.10942.98.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1206291334430.27860@kaball.uk.xensource.com>
	<1340985702.10942.136.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Rlibxl: refuse to try and migrate an HVM
 guest using 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 Campbell writes ("[PATCH] Rlibxl: refuse to try and migrate an HVM guest using qemu-xen"):
> > I think we should add an appropriate error message as a blocker. We
> > should also try to fix this on the QEMU side, but given that the QEMU
> > 1.0 stable tree is pretty much unmaintaned, we won't be able to backport
> > the fix there, so we cannot be sure that a distro will end up with a
> > QEMU with or without the fix.
> 
> How about this for the time being, we can always revert or enhance as
> necessary before 4.2.
...
> +    libxl_device_model_version dm =
> +        libxl__device_model_version_running(gc, domid);

libxl__device_model_version_running can return -1.  (Its error
handling is pretty bad but that's no excuse for making matters worse.)
I suggest we retcon it as returning a libxl error code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkdjH-0000Nk-8r; Fri, 29 Jun 2012 16:07:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkdjG-0000Nf-6z
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:07:30 +0000
Received: from [85.158.143.35:31903] by server-1.bemta-4.messagelabs.com id
	26/E4-24392-1C2DDEF4; Fri, 29 Jun 2012 16:07:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340986046!3927139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32172 invoked from network); 29 Jun 2012 16:07:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:07:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:07:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdiv-00019w-Nw; Fri, 29 Jun 2012 16:07:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skdiv-0007F2-Mw;
	Fri, 29 Jun 2012 17:07:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.53933.513298.47352@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:07:09 +0100
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FE85E80020000780008BA99@nat28.tlf.novell.com>
References: <4FE85E80020000780008BA99@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Rolu <rolu@roce.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional/passthrough: fix
 off-by-one in PCI config space register index check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("[Xen-devel] [PATCH] qemu-traditional/passthrough: fix off-by-one in PCI config space register index check"):
> Register 255 (0xff) is still valid to be accessed.
> 
> Reported-by: Rolu <rolu@roce.org>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks reasonable to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkdjH-0000Nk-8r; Fri, 29 Jun 2012 16:07:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkdjG-0000Nf-6z
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:07:30 +0000
Received: from [85.158.143.35:31903] by server-1.bemta-4.messagelabs.com id
	26/E4-24392-1C2DDEF4; Fri, 29 Jun 2012 16:07:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1340986046!3927139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32172 invoked from network); 29 Jun 2012 16:07:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:07:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:07:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdiv-00019w-Nw; Fri, 29 Jun 2012 16:07:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skdiv-0007F2-Mw;
	Fri, 29 Jun 2012 17:07:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.53933.513298.47352@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:07:09 +0100
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4FE85E80020000780008BA99@nat28.tlf.novell.com>
References: <4FE85E80020000780008BA99@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Rolu <rolu@roce.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-traditional/passthrough: fix
 off-by-one in PCI config space register index check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("[Xen-devel] [PATCH] qemu-traditional/passthrough: fix off-by-one in PCI config space register index check"):
> Register 255 (0xff) is still valid to be accessed.
> 
> Reported-by: Rolu <rolu@roce.org>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks reasonable to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:13:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:13: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 1Skdof-0000dA-52; Fri, 29 Jun 2012 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 <Ian.Jackson@eu.citrix.com>) id 1Skdod-0000d5-NN
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:13:04 +0000
Received: from [85.158.143.35:14252] by server-2.bemta-4.messagelabs.com id
	CF/1D-17938-F04DDEF4; Fri, 29 Jun 2012 16:13:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340986377!16365303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24387 invoked from network); 29 Jun 2012 16:12:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:12:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:12:56 +0100
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 1SkdoW-0001Bs-NQ;
	Fri, 29 Jun 2012 16:12:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkdoW-0000p7-BV;
	Fri, 29 Jun 2012 17:12:56 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13399-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 17:12:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13399: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13399 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13399/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate  fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail REGR. vs. 13376

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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-win        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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a2abb62aedbe
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 913 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 Jun 29 16:13:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:13: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 1Skdof-0000dA-52; Fri, 29 Jun 2012 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 <Ian.Jackson@eu.citrix.com>) id 1Skdod-0000d5-NN
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:13:04 +0000
Received: from [85.158.143.35:14252] by server-2.bemta-4.messagelabs.com id
	CF/1D-17938-F04DDEF4; Fri, 29 Jun 2012 16:13:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1340986377!16365303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24387 invoked from network); 29 Jun 2012 16:12:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:12:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:12:56 +0100
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 1SkdoW-0001Bs-NQ;
	Fri, 29 Jun 2012 16:12:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1SkdoW-0000p7-BV;
	Fri, 29 Jun 2012 17:12:56 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13399-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 17:12:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13399: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13399 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13399/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate  fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13379
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail REGR. vs. 13376

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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-win        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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a2abb62aedbe
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@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>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 913 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 Jun 29 16:14:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:14: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 1Skdq2-0000hC-KV; Fri, 29 Jun 2012 16:14:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skdq0-0000h0-Ef
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:14:28 +0000
Received: from [85.158.139.83:21479] by server-10.bemta-5.messagelabs.com id
	91/A1-02190-364DDEF4; Fri, 29 Jun 2012 16:14:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340986467!26259500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26645 invoked from network); 29 Jun 2012 16:14:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:14:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:14:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:14:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdpy-0001CL-Od; Fri, 29 Jun 2012 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 1Skdpy-0007I5-Nl;
	Fri, 29 Jun 2012 17:14:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.54370.720728.938339@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:14:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340193727.4906.52.camel@zakaz.uk.xensource.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
	<4FE1D674020000780008ACA4@nat28.tlf.novell.com>
	<1340193727.4906.52.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] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] x86-64/EFI: document building and usage"):
> On Wed, 2012-06-20 at 12:56 +0100, Jan Beulich wrote:
> > I didn't consider this, but I can certainly convert it if that's what
> > is preferred these days.
> 
> I think it's generally preferred for new stuff if the author is willing
> (i.e. we'd still rather have .txt than nothing)

I'm not sure we want to let the best be the enemy of the good.

Shouldn't we commit this as-is and perhaps update it to markdown
later ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:14:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:14: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 1Skdq2-0000hC-KV; Fri, 29 Jun 2012 16:14:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skdq0-0000h0-Ef
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:14:28 +0000
Received: from [85.158.139.83:21479] by server-10.bemta-5.messagelabs.com id
	91/A1-02190-364DDEF4; Fri, 29 Jun 2012 16:14:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1340986467!26259500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26645 invoked from network); 29 Jun 2012 16:14:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:14:27 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13296992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:14:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:14:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdpy-0001CL-Od; Fri, 29 Jun 2012 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 1Skdpy-0007I5-Nl;
	Fri, 29 Jun 2012 17:14:26 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.54370.720728.938339@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:14:26 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340193727.4906.52.camel@zakaz.uk.xensource.com>
References: <4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
	<4FE1D674020000780008ACA4@nat28.tlf.novell.com>
	<1340193727.4906.52.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] [PATCH] x86-64/EFI: document building and usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] x86-64/EFI: document building and usage"):
> On Wed, 2012-06-20 at 12:56 +0100, Jan Beulich wrote:
> > I didn't consider this, but I can certainly convert it if that's what
> > is preferred these days.
> 
> I think it's generally preferred for new stuff if the author is willing
> (i.e. we'd still rather have .txt than nothing)

I'm not sure we want to let the best be the enemy of the good.

Shouldn't we commit this as-is and perhaps update it to markdown
later ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:15:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16: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 1Skdr5-0000m3-2x; Fri, 29 Jun 2012 16:15:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skdr4-0000lo-2g
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:15:34 +0000
Received: from [85.158.143.99:50357] by server-2.bemta-4.messagelabs.com id
	EE/BF-17938-5A4DDEF4; Fri, 29 Jun 2012 16:15:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340986532!22791514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14810 invoked from network); 29 Jun 2012 16:15:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:15:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:15:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:15:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdr2-0001Ci-HS; Fri, 29 Jun 2012 16:15:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skdr2-0007IJ-GY;
	Fri, 29 Jun 2012 17:15:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.54436.478882.863973@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:15:32 +0100
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340193727.4906.52.camel@zakaz.uk.xensource.com>,
	<20461.54370.720728.938339@mariner.uk.xensource.com>,
	<4FE1E656020000780008AD62@nat28.tlf.novell.com>
References: <4FE1E656020000780008AD62@nat28.tlf.novell.com>
	<4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
	<4FE1D674020000780008ACA4@nat28.tlf.novell.com>
	<1340193727.4906.52.camel@zakaz.uk.xensource.com>
	<20461.54370.720728.938339@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
	[and 2 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] x86-64/EFI: document building and usage"):
> I'm not sure we want to let the best be the enemy of the good.
> 
> Shouldn't we commit this as-is and perhaps update it to markdown
> later ?

Ah never mind, just seen v2.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:15:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16: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 1Skdr5-0000m3-2x; Fri, 29 Jun 2012 16:15:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skdr4-0000lo-2g
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:15:34 +0000
Received: from [85.158.143.99:50357] by server-2.bemta-4.messagelabs.com id
	EE/BF-17938-5A4DDEF4; Fri, 29 Jun 2012 16:15:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1340986532!22791514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14810 invoked from network); 29 Jun 2012 16:15:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:15:33 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:15:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:15:32 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Skdr2-0001Ci-HS; Fri, 29 Jun 2012 16:15:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Skdr2-0007IJ-GY;
	Fri, 29 Jun 2012 17:15:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.54436.478882.863973@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:15:32 +0100
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340193727.4906.52.camel@zakaz.uk.xensource.com>,
	<20461.54370.720728.938339@mariner.uk.xensource.com>,
	<4FE1E656020000780008AD62@nat28.tlf.novell.com>
References: <4FE1E656020000780008AD62@nat28.tlf.novell.com>
	<4FE199A4020000780008ABC3@nat28.tlf.novell.com>
	<1340192110.4906.33.camel@zakaz.uk.xensource.com>
	<4FE1D674020000780008ACA4@nat28.tlf.novell.com>
	<1340193727.4906.52.camel@zakaz.uk.xensource.com>
	<20461.54370.720728.938339@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: document building and usage
	[and 2 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] x86-64/EFI: document building and usage"):
> I'm not sure we want to let the best be the enemy of the good.
> 
> Shouldn't we commit this as-is and perhaps update it to markdown
> later ?

Ah never mind, just seen v2.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:29:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16: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 1Ske4P-0001LR-D8; Fri, 29 Jun 2012 16:29: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 1Ske4N-0001LM-AJ
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:29:19 +0000
Received: from [85.158.139.83:17254] by server-9.bemta-5.messagelabs.com id
	02/B9-01069-ED7DDEF4; Fri, 29 Jun 2012 16:29:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340987357!22866323!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18198 invoked from network); 29 Jun 2012 16:29:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:29:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:29:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:29:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ske4K-0001HL-Fj; Fri, 29 Jun 2012 16:29:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ske4K-0007JV-EX;
	Fri, 29 Jun 2012 17:29:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55260.431307.425828@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:29:16 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <fe85a8d600800524917c.1340288390@Solace>
References: <fe85a8d600800524917c.1340288390@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: improve the comments for sedf
	parameters	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

Dario Faggioli writes ("[Xen-devel] [PATCH] xl: improve the comments for sedf parameters checking"):
> As agreed during review of what has become 513d5e196e23.

Thanks.  I'm afraid it doesn't apply to tip though.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:29:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16: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 1Ske4P-0001LR-D8; Fri, 29 Jun 2012 16:29: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 1Ske4N-0001LM-AJ
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:29:19 +0000
Received: from [85.158.139.83:17254] by server-9.bemta-5.messagelabs.com id
	02/B9-01069-ED7DDEF4; Fri, 29 Jun 2012 16:29:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1340987357!22866323!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18198 invoked from network); 29 Jun 2012 16:29:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:29:17 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:29:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:29:16 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ske4K-0001HL-Fj; Fri, 29 Jun 2012 16:29:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ske4K-0007JV-EX;
	Fri, 29 Jun 2012 17:29:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55260.431307.425828@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:29:16 +0100
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <fe85a8d600800524917c.1340288390@Solace>
References: <fe85a8d600800524917c.1340288390@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: improve the comments for sedf
	parameters	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

Dario Faggioli writes ("[Xen-devel] [PATCH] xl: improve the comments for sedf parameters checking"):
> As agreed during review of what has become 513d5e196e23.

Thanks.  I'm afraid it doesn't apply to tip though.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:33: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 1Ske7p-0001Wa-1Y; Fri, 29 Jun 2012 16:32:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ske7n-0001WG-KI
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:32:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340987553!3608268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8145 invoked from network); 29 Jun 2012 16:32:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:32:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:32:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:32:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ske7R-0001IR-40; Fri, 29 Jun 2012 16:32:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ske7R-0007U1-2t;
	Fri, 29 Jun 2012 17:32:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55453.74510.342185@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:32:29 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340872823.10942.6.camel@zakaz.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
	<1340861601.5210.6.camel@dagon.hellion.org.uk>
	<CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
	<1340872823.10942.6.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: ZhouPeng <zpengxen@gmail.com>,
	"Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2"):
> On Thu, 2012-06-28 at 08:56 +0100, ZhouPeng wrote:
> > version 4
> > 
> > Thanks.
> > --
> > 
> > tools:libxl: refactor stdvga opinon support.
> > 
> > Be ready to add and describe new vga interface
> > 
> > Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:33: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 1Ske7p-0001Wa-1Y; Fri, 29 Jun 2012 16:32:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ske7n-0001WG-KI
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:32:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340987553!3608268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8145 invoked from network); 29 Jun 2012 16:32:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:32:34 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:32:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:32:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ske7R-0001IR-40; Fri, 29 Jun 2012 16:32:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ske7R-0007U1-2t;
	Fri, 29 Jun 2012 17:32:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55453.74510.342185@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:32:29 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340872823.10942.6.camel@zakaz.uk.xensource.com>
References: <CAAh7U5M=5F=jJQPskTF_C2Dzmo1A2rbgvhSgCoMeDJnm7J=Q-g@mail.gmail.com>
	<1338983231.32319.65.camel@zakaz.uk.xensource.com>
	<CAAh7U5MPenxZH_bj3h2A+Y=Vko6KMK-nncRfm5nLkifM8jC1DA@mail.gmail.com>
	<1340217533.4998.3.camel@dagon.hellion.org.uk>
	<CAAh7U5NqDOjffUgSxyuYeR6hH=SAYobB=1e91MZc6MEnoSB2xw@mail.gmail.com>
	<1340810891.29172.50.camel@zakaz.uk.xensource.com>
	<CAAh7U5MXH+M-wgCW4dHUsSFsTux_wA=QARR_uZugHyL9rs3ejA@mail.gmail.com>
	<1340861601.5210.6.camel@dagon.hellion.org.uk>
	<CAAh7U5O_CUgkMTGdNuKoAcDRkWY5aBpSf9PxhfMpnod7c9sxFg@mail.gmail.com>
	<1340872823.10942.6.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: ZhouPeng <zpengxen@gmail.com>,
	"Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/3] libxl:refactor stdvga option support v2"):
> On Thu, 2012-06-28 at 08:56 +0100, ZhouPeng wrote:
> > version 4
> > 
> > Thanks.
> > --
> > 
> > tools:libxl: refactor stdvga opinon support.
> > 
> > Be ready to add and describe new vga interface
> > 
> > Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:36:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:36: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 1SkeB5-0001xc-QM; Fri, 29 Jun 2012 16:36:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkeB4-0001xI-KW
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:36:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340987767!6851552!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6468 invoked from network); 29 Jun 2012 16:36:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:36:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:35:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:35:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkeAm-0001JU-1i; Fri, 29 Jun 2012 16:35:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkeAm-0007Ui-0i;
	Fri, 29 Jun 2012 17:35:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55660.6290.647214@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:35:56 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340728125.3832.170.camel@zakaz.uk.xensource.com>
References: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
	<1340728125.3832.170.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] [PATCH] docs/xen-headers: allow headers to be
 symlinks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] docs/xen-headers: allow headers to be symlinks"):
> On Thu, 2012-06-21 at 13:20 +0100, Jan Beulich wrote:
> > There's no apparent reason not to permit this, and since we don't
> > support out-of-source-tree builds, the least overhead way of doing
> > multiple, differently configured (perhaps different architecture)
> > builds from a single source tree is to create symlinked build trees.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Seems reasonable and applying the patch resulted in no change in the
> output on this end:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Indeed, this is correct.  I see it's been applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:36:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:36: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 1SkeB5-0001xc-QM; Fri, 29 Jun 2012 16:36:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkeB4-0001xI-KW
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 16:36:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1340987767!6851552!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6468 invoked from network); 29 Jun 2012 16:36:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:36:08 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:35:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:35:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkeAm-0001JU-1i; Fri, 29 Jun 2012 16:35:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkeAm-0007Ui-0i;
	Fri, 29 Jun 2012 17:35:56 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55660.6290.647214@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:35:56 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1340728125.3832.170.camel@zakaz.uk.xensource.com>
References: <4FE32DB2020000780008B138@nat28.tlf.novell.com>
	<1340728125.3832.170.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] [PATCH] docs/xen-headers: allow headers to be
 symlinks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] docs/xen-headers: allow headers to be symlinks"):
> On Thu, 2012-06-21 at 13:20 +0100, Jan Beulich wrote:
> > There's no apparent reason not to permit this, and since we don't
> > support out-of-source-tree builds, the least overhead way of doing
> > multiple, differently configured (perhaps different architecture)
> > builds from a single source tree is to create symlinked build trees.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Seems reasonable and applying the patch resulted in no change in the
> output on this end:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Indeed, this is correct.  I see it's been applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:37:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:37: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 1SkeCG-00023T-9a; Fri, 29 Jun 2012 16:37: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 1SkeCE-00023B-3I
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:37:26 +0000
Received: from [85.158.139.83:12649] by server-10.bemta-5.messagelabs.com id
	AA/F8-02190-5C9DDEF4; Fri, 29 Jun 2012 16:37:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340987844!29534921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31772 invoked from network); 29 Jun 2012 16:37:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:37:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:37:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:37:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkeBp-0001Jt-9D; Fri, 29 Jun 2012 16:37:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkeBp-0007W3-8M;
	Fri, 29 Jun 2012 17:37:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55725.244923.558604@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:37:01 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <849fe346b05a3265894e.1340285500@elijah>
References: <849fe346b05a3265894e.1340285500@elijah>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: Clarify 'xend is running' error message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] xl: Clarify 'xend is running' error message"):
> xl: Clarify 'xend is running' error message

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 16:37:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 16:37: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 1SkeCG-00023T-9a; Fri, 29 Jun 2012 16:37: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 1SkeCE-00023B-3I
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 16:37:26 +0000
Received: from [85.158.139.83:12649] by server-10.bemta-5.messagelabs.com id
	AA/F8-02190-5C9DDEF4; Fri, 29 Jun 2012 16:37:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1340987844!29534921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31772 invoked from network); 29 Jun 2012 16:37:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 16:37:24 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13297374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 16:37:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 29 Jun 2012 17:37:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1SkeBp-0001Jt-9D; Fri, 29 Jun 2012 16:37:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1SkeBp-0007W3-8M;
	Fri, 29 Jun 2012 17:37:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20461.55725.244923.558604@mariner.uk.xensource.com>
Date: Fri, 29 Jun 2012 17:37:01 +0100
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <849fe346b05a3265894e.1340285500@elijah>
References: <849fe346b05a3265894e.1340285500@elijah>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: Clarify 'xend is running' error message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH] xl: Clarify 'xend is running' error message"):
> xl: Clarify 'xend is running' error message

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 18:16:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 18:16: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 1Skfjd-0003dY-JH; Fri, 29 Jun 2012 18:16:01 +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 1Skfjb-0003dT-TD
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 18:16:00 +0000
Received: from [85.158.138.51:16739] by server-6.bemta-3.messagelabs.com id
	E3/08-11602-FD0FDEF4; Fri, 29 Jun 2012 18:15:59 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340993757!22117406!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEyMjI1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5078 invoked from network); 29 Jun 2012 18:15:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Jun 2012 18:15:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TIFoJT021422
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 18:15:51 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
	q5TIFoNG029015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 18:15:50 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
	q5TIFnga016102; Fri, 29 Jun 2012 13:15:49 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 11:15:49 -0700
Date: Fri, 29 Jun 2012 11:15:46 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120629111546.50e36f52@mantra.us.oracle.com>
In-Reply-To: <1340957369.10942.74.camel@zakaz.uk.xensource.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 09:09:29 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-06-29 at 02:26 +0100, Mukesh Rathor wrote:
> > On Thu, 28 Jun 2012 21:09:03 -0400
> 
> CS 0x033 could still be kernel mode on regular PV 64 bit, but I
> suppose not on hybrid?

correct, not on hybrid, unless some bug! But then the RIP also
appears user mode.


> It's unlikely but not impossible for a userspace developer to have
> done some "Xen magic" and used the prefix in userspace.
> 
> What version of dm_mapper do you have? I checked the version in Debian
> Sid and it doesn't do this (at least not directly).
> 
> Are you able to run the dm_mapper process under gdb and inspect it to
> find the prefix?

Well, let me take that back. dm_mapper is the last printk, but it could
be anything after that or that. 

Unfortunately, it's dom0 and during boot, so can't run gdb on it. I am
hacking the kernel now to print every user process name in schedule.

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 Jun 29 18:16:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 18:16: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 1Skfjd-0003dY-JH; Fri, 29 Jun 2012 18:16:01 +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 1Skfjb-0003dT-TD
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 18:16:00 +0000
Received: from [85.158.138.51:16739] by server-6.bemta-3.messagelabs.com id
	E3/08-11602-FD0FDEF4; Fri, 29 Jun 2012 18:15:59 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1340993757!22117406!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEyMjI1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5078 invoked from network); 29 Jun 2012 18:15:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Jun 2012 18:15:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TIFoJT021422
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 18:15:51 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
	q5TIFoNG029015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 18:15:50 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
	q5TIFnga016102; Fri, 29 Jun 2012 13:15:49 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 11:15:49 -0700
Date: Fri, 29 Jun 2012 11:15:46 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120629111546.50e36f52@mantra.us.oracle.com>
In-Reply-To: <1340957369.10942.74.camel@zakaz.uk.xensource.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 09:09:29 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-06-29 at 02:26 +0100, Mukesh Rathor wrote:
> > On Thu, 28 Jun 2012 21:09:03 -0400
> 
> CS 0x033 could still be kernel mode on regular PV 64 bit, but I
> suppose not on hybrid?

correct, not on hybrid, unless some bug! But then the RIP also
appears user mode.


> It's unlikely but not impossible for a userspace developer to have
> done some "Xen magic" and used the prefix in userspace.
> 
> What version of dm_mapper do you have? I checked the version in Debian
> Sid and it doesn't do this (at least not directly).
> 
> Are you able to run the dm_mapper process under gdb and inspect it to
> find the prefix?

Well, let me take that back. dm_mapper is the last printk, but it could
be anything after that or that. 

Unfortunately, it's dom0 and during boot, so can't run gdb on it. I am
hacking the kernel now to print every user process name in schedule.

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 Jun 29 18:42:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 18:42: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 1Skg8t-00043K-W7; Fri, 29 Jun 2012 18:42:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Skg8s-00043F-Rv
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 18:42:06 +0000
Received: from [85.158.143.35:15792] by server-2.bemta-4.messagelabs.com id
	E2/E5-17938-EF6FDEF4; Fri, 29 Jun 2012 18:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340995325!16400195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19312 invoked from network); 29 Jun 2012 18:42:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 18:42:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13298637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 18:42:05 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 19:42:05 +0100
Message-ID: <1340995324.5953.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 19:42:04 +0100
In-Reply-To: <20461.55260.431307.425828@mariner.uk.xensource.com>
References: <fe85a8d600800524917c.1340288390@Solace>
	<20461.55260.431307.425828@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: improve the comments for sedf
 parameters	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

On Fri, 2012-06-29 at 17:29 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[Xen-devel] [PATCH] xl: improve the comments for sedf parameters checking"):
> > As agreed during review of what has become 513d5e196e23.
> 
> Thanks.  I'm afraid it doesn't apply to tip though.

This code got moved to libxl while we were trying to fixup this stuff
and the equivalent to this patch was applied to libxl as part of
25494:836db8c4b9f9 "libxl: fix validation of scheduling parameters for
sedf".

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 18:42:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 18:42: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 1Skg8t-00043K-W7; Fri, 29 Jun 2012 18:42:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Skg8s-00043F-Rv
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 18:42:06 +0000
Received: from [85.158.143.35:15792] by server-2.bemta-4.messagelabs.com id
	E2/E5-17938-EF6FDEF4; Fri, 29 Jun 2012 18:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340995325!16400195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM3MDU=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19312 invoked from network); 29 Jun 2012 18:42:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 18:42:05 -0000
X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="13298637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 18:42:05 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 19:42:05 +0100
Message-ID: <1340995324.5953.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 29 Jun 2012 19:42:04 +0100
In-Reply-To: <20461.55260.431307.425828@mariner.uk.xensource.com>
References: <fe85a8d600800524917c.1340288390@Solace>
	<20461.55260.431307.425828@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: Dario Faggioli <raistlin@linux.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: improve the comments for sedf
 parameters	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

On Fri, 2012-06-29 at 17:29 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[Xen-devel] [PATCH] xl: improve the comments for sedf parameters checking"):
> > As agreed during review of what has become 513d5e196e23.
> 
> Thanks.  I'm afraid it doesn't apply to tip though.

This code got moved to libxl while we were trying to fixup this stuff
and the equivalent to this patch was applied to libxl as part of
25494:836db8c4b9f9 "libxl: fix validation of scheduling parameters for
sedf".

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 19:08:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 19:08: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 1SkgXp-0004VY-7d; Fri, 29 Jun 2012 19:07:53 +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 1SkgXn-0004VT-Nk
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 19:07:51 +0000
Received: from [85.158.143.35:52260] by server-2.bemta-4.messagelabs.com id
	4C/92-17938-60DFDEF4; Fri, 29 Jun 2012 19:07:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340996868!16402951!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEyMjI1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19345 invoked from network); 29 Jun 2012 19:07:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 19:07:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TJ7hOh001954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 19:07:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5TJ7f7R008475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 19:07:42 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
	q5TJ7f4n010736; Fri, 29 Jun 2012 14:07:41 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 12:07:41 -0700
Date: Fri, 29 Jun 2012 12:07:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120629120738.425781e5@mantra.us.oracle.com>
In-Reply-To: <20120629111546.50e36f52@mantra.us.oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.camel@zakaz.uk.xensource.com>
	<20120629111546.50e36f52@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 11:15:46 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > It's unlikely but not impossible for a userspace developer to have
> > done some "Xen magic" and used the prefix in userspace.
> > 
> > What version of dm_mapper do you have? I checked the version in
> > Debian Sid and it doesn't do this (at least not directly).
> > 
> > Are you able to run the dm_mapper process under gdb and inspect it
> > to find the prefix?
> 
> Well, let me take that back. dm_mapper is the last printk, but it
> could be anything after that or that. 
> 
> Unfortunately, it's dom0 and during boot, so can't run gdb on it. I am
> hacking the kernel now to print every user process name in schedule.

Ah, it's "xen-detect" coming in right after dm_mapper. I see the
xen prefix in it. Hmm... let me see if I can add some run time check
for hybrid dom0, then won't have to worry about invalid_op trap. Less
code that way. That's the end goal anyways...

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 Jun 29 19:08:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 19:08: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 1SkgXp-0004VY-7d; Fri, 29 Jun 2012 19:07:53 +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 1SkgXn-0004VT-Nk
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 19:07:51 +0000
Received: from [85.158.143.35:52260] by server-2.bemta-4.messagelabs.com id
	4C/92-17938-60DFDEF4; Fri, 29 Jun 2012 19:07:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1340996868!16402951!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEyMjI1\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19345 invoked from network); 29 Jun 2012 19:07:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 19:07:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TJ7hOh001954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 19:07:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5TJ7f7R008475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 19:07:42 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
	q5TJ7f4n010736; Fri, 29 Jun 2012 14:07:41 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 12:07:41 -0700
Date: Fri, 29 Jun 2012 12:07:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120629120738.425781e5@mantra.us.oracle.com>
In-Reply-To: <20120629111546.50e36f52@mantra.us.oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.camel@zakaz.uk.xensource.com>
	<20120629111546.50e36f52@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 11:15:46 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > It's unlikely but not impossible for a userspace developer to have
> > done some "Xen magic" and used the prefix in userspace.
> > 
> > What version of dm_mapper do you have? I checked the version in
> > Debian Sid and it doesn't do this (at least not directly).
> > 
> > Are you able to run the dm_mapper process under gdb and inspect it
> > to find the prefix?
> 
> Well, let me take that back. dm_mapper is the last printk, but it
> could be anything after that or that. 
> 
> Unfortunately, it's dom0 and during boot, so can't run gdb on it. I am
> hacking the kernel now to print every user process name in schedule.

Ah, it's "xen-detect" coming in right after dm_mapper. I see the
xen prefix in it. Hmm... let me see if I can add some run time check
for hybrid dom0, then won't have to worry about invalid_op trap. Less
code that way. That's the end goal anyways...

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 Jun 29 19:45:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 19: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 1Skh7d-0004vp-A3; Fri, 29 Jun 2012 19:44:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Skh7b-0004vi-WD
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 19:44:52 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340999084!3628466!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17393 invoked from network); 29 Jun 2012 19:44:45 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 19:44:45 -0000
Received: by ggnp1 with SMTP id p1so3629823ggn.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 12:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=FkAygdE1NWxNoilE7WSE13h9AiC7GjQ9i5gJ1WeEaYg=;
	b=aSn1Y9qwxjrUyg53KlVWV3vEnZkdhGZaTOktEiiaa01I2ohnpGQutlIG9Prr9EUXBz
	DdMETNvAxZX6gQCxePO8ZuDiZhCBc6la0RjZN9EXQootT5vL+pclpV+lyb9FDlm3WJBa
	P3UoAjb8QVJ26H5hIKqxRY7+3Ik3PYZvJV4+BOiy+aG9mju7cT2lLsceV/3GIt4C7qwu
	fc0RxNp1wEALNPPZr7HuAFLmVTEDPNFrwCkpxQENeO6rVOQiGAHnjVampUACDB3Am0rc
	sQSWIP40K3KR9jcWRU5oGDj4viv00BuoMFV4S/dRHArk/peQu6UUjIrO+425xLBBV7p3
	Th3w==
Received: by 10.236.190.5 with SMTP id d5mr4804282yhn.49.1340999083941;
	Fri, 29 Jun 2012 12:44:43 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id q10sm4099290anm.16.2012.06.29.12.44.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 12:44:43 -0700 (PDT)
Message-ID: <4FEE05A7.5070004@gmail.com>
Date: Fri, 29 Jun 2012 15:44:39 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6326843354689566560=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6326843354689566560==
Content-Type: multipart/alternative;
 boundary="------------020702020402080403070802"

This is a multi-part message in MIME format.
--------------020702020402080403070802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo 
don't know how updated it is, BUT at the top it said:
-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------


    _Xen 4.1 xl tools notes _

  * Only devices with FLR capabilities are supported.
  * Passing through a PCI card without FLR capability will result an error.

To check if your PCI devices have FLR function, check in this wiki, [How 
can I check if PCI device supports FLR (Function Level Reset) ? 
<http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F>] 


If you see output with "FLReset-" then your PCI device don't support FLR 
function. If output have "FLReset+" then it does.

As this time of writing, June 2012, there are very very few PCI devices 
support FLR function.
-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------


THAN was reading here: 
http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F 
at the bottom of the page where it says:

-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------


    _How can I check if PCI device supports FLR (Function Level Reset)? _

Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the 
DevCap <http://wiki.xen.org/wiki?title=DevCap&action=edit&redlink=1> field.

If you are Ubuntu/Debian user don't forget to add sudo at front, 
otherwise, you won't get the result you should get.

sudo lspci -vv | egrep -i --colour flreset

The above line should get root access for lspci program and show colour 
with flreset it found from output

-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------

I did that and ALL of my devices it listed showed "FLReset-", there were 
only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed 
"FLReset+"

SO, I have been trying to get my ATI FirePro V7900 Video Card to 
passthru to a Windows 7 Ultimate DomU with no luck so far AND was 
wondering how critical was for that device to show as "FLReset+"?

1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-", 
does that mean it is impossible to get it fully working in a Win7 DomU?
2.) Does having the feature "FLReset+" depend on the motherboard BIOS, 
motherboard hardware or the BIOS onboard the Video Card that could be 
updated to get back the "FLReset+" so you can have the FLR reset 
functionality?

I just spent a lot of time and money building this computer for the 
purpose of getting Xen to work (So far still working on that), i would 
just hate to see all of that go to waste, SO hoping someone could answer 
the above concerns... :)

Thank you as always


--------------020702020402080403070802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I was reading the Wiki page here: <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/VTd_HowTo">http://wiki.xen.org/wiki/VTd_HowTo</a>
    don't know how updated it is, BUT at the top it said:<br>
    --------------------
    --------------------
    --------------------
    --------------------
    --------------------
    --------------------
    <h2> <u><span class="mw-headline"> <small>Xen 4.1 xl tools notes </small></span></u></h2>
    <ul>
      <li> Only devices with FLR capabilities are supported.
      </li>
      <li> Passing through a PCI card without FLR capability will result
        an error.
      </li>
    </ul>
    <p>To check if your PCI devices have FLR function, check in this
      wiki, [<a
href="http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F"
        class="external text"
title="http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F"
        rel="nofollow">How can I check if PCI device supports FLR
        (Function Level Reset)&nbsp;?</a>]
    </p>
    <p>If you see output with "FLReset-" then your PCI device don't
      support FLR function. If output have "FLReset+" then it does.
    </p>
    <p>As this time of writing, June 2012, there are very very few PCI
      devices support FLR function.<br>
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------<br>
    </p>
    <p><br>
      THAN was reading here:
      <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F">http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F</a>

      at the bottom of the page where it says:<br>
    </p>
    <p>
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
    </p>
    <h2> <u><span class="mw-headline"> <small>How can I check if PCI
            device supports FLR (Function Level Reset)? </small></span></u></h2>
    <p>Run "lspci -vv" (in dom0) and check if the device has "FLReset+"
      in the <a
href="http://wiki.xen.org/wiki?title=DevCap&amp;action=edit&amp;redlink=1"
        class="new" title="DevCap (page does not exist)">DevCap</a>
      field.
    </p>
    <p>If you are Ubuntu/Debian user don't forget to add sudo at front,
      otherwise, you won't get the result you should get. </p>
    <p>sudo lspci -vv | egrep -i --colour flreset
    </p>
    <p>The above line should get root access for lspci program and show
      colour with flreset it found from output
    </p>
    <p>
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------<br>
    </p>
    <p>I did that and ALL of my devices it listed showed "FLReset-",
      there were only 3x "Etron Technology, Inc. EJ168 USB3.0"
      controllers that showed "FLReset+"<br>
    </p>
    <p>SO, I have been trying to get my ATI FirePro V7900 Video Card to
      passthru to a Windows 7 Ultimate DomU with no luck so far AND was
      wondering how critical was for that device to show as&nbsp;"FLReset+"?<br>
    </p>
    <p>1.) Since my VGA card and AUDIO component of it, shows up as
      "FLReset-", does that mean it is impossible to get it fully
      working in a Win7 DomU?<br>
      2.) Does having the feature "FLReset+" depend on the motherboard
      BIOS, motherboard hardware or the BIOS onboard the Video Card that
      could be updated to get back the "FLReset+" so you can have the
      FLR reset functionality?<br>
    </p>
    <p>I just spent a lot of time and money building this computer for
      the purpose of getting Xen to work (So far still working on that),
      i would just hate to see all of that go to waste, SO hoping
      someone could answer the above concerns... :) <br>
    </p>
    <p>Thank you as always<br>
    </p>
  </body>
</html>

--------------020702020402080403070802--


--===============6326843354689566560==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6326843354689566560==--


From xen-devel-bounces@lists.xen.org Fri Jun 29 19:45:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 19: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 1Skh7d-0004vp-A3; Fri, 29 Jun 2012 19:44:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Skh7b-0004vi-WD
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 19:44:52 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1340999084!3628466!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17393 invoked from network); 29 Jun 2012 19:44:45 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 19:44:45 -0000
Received: by ggnp1 with SMTP id p1so3629823ggn.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 12:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=FkAygdE1NWxNoilE7WSE13h9AiC7GjQ9i5gJ1WeEaYg=;
	b=aSn1Y9qwxjrUyg53KlVWV3vEnZkdhGZaTOktEiiaa01I2ohnpGQutlIG9Prr9EUXBz
	DdMETNvAxZX6gQCxePO8ZuDiZhCBc6la0RjZN9EXQootT5vL+pclpV+lyb9FDlm3WJBa
	P3UoAjb8QVJ26H5hIKqxRY7+3Ik3PYZvJV4+BOiy+aG9mju7cT2lLsceV/3GIt4C7qwu
	fc0RxNp1wEALNPPZr7HuAFLmVTEDPNFrwCkpxQENeO6rVOQiGAHnjVampUACDB3Am0rc
	sQSWIP40K3KR9jcWRU5oGDj4viv00BuoMFV4S/dRHArk/peQu6UUjIrO+425xLBBV7p3
	Th3w==
Received: by 10.236.190.5 with SMTP id d5mr4804282yhn.49.1340999083941;
	Fri, 29 Jun 2012 12:44:43 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id q10sm4099290anm.16.2012.06.29.12.44.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 12:44:43 -0700 (PDT)
Message-ID: <4FEE05A7.5070004@gmail.com>
Date: Fri, 29 Jun 2012 15:44:39 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6326843354689566560=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6326843354689566560==
Content-Type: multipart/alternative;
 boundary="------------020702020402080403070802"

This is a multi-part message in MIME format.
--------------020702020402080403070802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo 
don't know how updated it is, BUT at the top it said:
-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------


    _Xen 4.1 xl tools notes _

  * Only devices with FLR capabilities are supported.
  * Passing through a PCI card without FLR capability will result an error.

To check if your PCI devices have FLR function, check in this wiki, [How 
can I check if PCI device supports FLR (Function Level Reset) ? 
<http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F>] 


If you see output with "FLReset-" then your PCI device don't support FLR 
function. If output have "FLReset+" then it does.

As this time of writing, June 2012, there are very very few PCI devices 
support FLR function.
-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------


THAN was reading here: 
http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F 
at the bottom of the page where it says:

-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------


    _How can I check if PCI device supports FLR (Function Level Reset)? _

Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the 
DevCap <http://wiki.xen.org/wiki?title=DevCap&action=edit&redlink=1> field.

If you are Ubuntu/Debian user don't forget to add sudo at front, 
otherwise, you won't get the result you should get.

sudo lspci -vv | egrep -i --colour flreset

The above line should get root access for lspci program and show colour 
with flreset it found from output

-------------------- -------------------- -------------------- 
-------------------- -------------------- --------------------

I did that and ALL of my devices it listed showed "FLReset-", there were 
only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed 
"FLReset+"

SO, I have been trying to get my ATI FirePro V7900 Video Card to 
passthru to a Windows 7 Ultimate DomU with no luck so far AND was 
wondering how critical was for that device to show as "FLReset+"?

1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-", 
does that mean it is impossible to get it fully working in a Win7 DomU?
2.) Does having the feature "FLReset+" depend on the motherboard BIOS, 
motherboard hardware or the BIOS onboard the Video Card that could be 
updated to get back the "FLReset+" so you can have the FLR reset 
functionality?

I just spent a lot of time and money building this computer for the 
purpose of getting Xen to work (So far still working on that), i would 
just hate to see all of that go to waste, SO hoping someone could answer 
the above concerns... :)

Thank you as always


--------------020702020402080403070802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I was reading the Wiki page here: <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/VTd_HowTo">http://wiki.xen.org/wiki/VTd_HowTo</a>
    don't know how updated it is, BUT at the top it said:<br>
    --------------------
    --------------------
    --------------------
    --------------------
    --------------------
    --------------------
    <h2> <u><span class="mw-headline"> <small>Xen 4.1 xl tools notes </small></span></u></h2>
    <ul>
      <li> Only devices with FLR capabilities are supported.
      </li>
      <li> Passing through a PCI card without FLR capability will result
        an error.
      </li>
    </ul>
    <p>To check if your PCI devices have FLR function, check in this
      wiki, [<a
href="http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F"
        class="external text"
title="http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F"
        rel="nofollow">How can I check if PCI device supports FLR
        (Function Level Reset)&nbsp;?</a>]
    </p>
    <p>If you see output with "FLReset-" then your PCI device don't
      support FLR function. If output have "FLReset+" then it does.
    </p>
    <p>As this time of writing, June 2012, there are very very few PCI
      devices support FLR function.<br>
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------<br>
    </p>
    <p><br>
      THAN was reading here:
      <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F">http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F</a>

      at the bottom of the page where it says:<br>
    </p>
    <p>
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
    </p>
    <h2> <u><span class="mw-headline"> <small>How can I check if PCI
            device supports FLR (Function Level Reset)? </small></span></u></h2>
    <p>Run "lspci -vv" (in dom0) and check if the device has "FLReset+"
      in the <a
href="http://wiki.xen.org/wiki?title=DevCap&amp;action=edit&amp;redlink=1"
        class="new" title="DevCap (page does not exist)">DevCap</a>
      field.
    </p>
    <p>If you are Ubuntu/Debian user don't forget to add sudo at front,
      otherwise, you won't get the result you should get. </p>
    <p>sudo lspci -vv | egrep -i --colour flreset
    </p>
    <p>The above line should get root access for lspci program and show
      colour with flreset it found from output
    </p>
    <p>
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------
      --------------------<br>
    </p>
    <p>I did that and ALL of my devices it listed showed "FLReset-",
      there were only 3x "Etron Technology, Inc. EJ168 USB3.0"
      controllers that showed "FLReset+"<br>
    </p>
    <p>SO, I have been trying to get my ATI FirePro V7900 Video Card to
      passthru to a Windows 7 Ultimate DomU with no luck so far AND was
      wondering how critical was for that device to show as&nbsp;"FLReset+"?<br>
    </p>
    <p>1.) Since my VGA card and AUDIO component of it, shows up as
      "FLReset-", does that mean it is impossible to get it fully
      working in a Win7 DomU?<br>
      2.) Does having the feature "FLReset+" depend on the motherboard
      BIOS, motherboard hardware or the BIOS onboard the Video Card that
      could be updated to get back the "FLReset+" so you can have the
      FLR reset functionality?<br>
    </p>
    <p>I just spent a lot of time and money building this computer for
      the purpose of getting Xen to work (So far still working on that),
      i would just hate to see all of that go to waste, SO hoping
      someone could answer the above concerns... :) <br>
    </p>
    <p>Thank you as always<br>
    </p>
  </body>
</html>

--------------020702020402080403070802--


--===============6326843354689566560==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6326843354689566560==--


From xen-devel-bounces@lists.xen.org Fri Jun 29 20:24:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 20:24: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 1Skhjj-0005QN-IM; Fri, 29 Jun 2012 20:24:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Skhjh-0005QI-5M
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 20:24:13 +0000
Received: from [85.158.143.99:47240] by server-1.bemta-4.messagelabs.com id
	F3/D3-24392-CEE0EEF4; Fri, 29 Jun 2012 20:24:12 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1341001450!20077823!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8024 invoked from network); 29 Jun 2012 20:24:11 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 20:24:11 -0000
Received: by yenl1 with SMTP id l1so3687057yen.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 13:24:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=pO/6y/LPkVR5ffSRQOCfQR71buXT3I3jgz8BP7f728Y=;
	b=VtcGuFGKE5VT08J1tfur9nnxAOMBavWkWaXkj0hMjQPiq+/fQGQjHMrNlPZbseFUed
	4ulhc3a28BuL/Ff6/PGOfIDj6yYDt+oE7iGXv37sSVLESO9UaI0g6X7k/pqVhyaUVUYq
	vXxUwSE7AbkiBsLkXmWZLEN7k+0MHCw0eBJrInXksNkFSFkn/lZXCPC6Fuw0ayGPTWj2
	ue1SHIumD7ImhlI+YwszW7eFDoSi5YqmPIOba5lGzJmHrGCmRYKne5v9zbVCOGJ6KfkQ
	fKjfo9aYmiX7WDPLQKV8BRs7V3toQLKfZOsWxHQ5KFHcZVFvdPNg8zIZc1H74Nx7gQOH
	mCzQ==
Received: by 10.42.155.73 with SMTP id t9mr1753964icw.48.1341001449960; Fri,
	29 Jun 2012 13:24:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Fri, 29 Jun 2012 13:23:49 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FEE05A7.5070004@gmail.com>
References: <4FEE05A7.5070004@gmail.com>
From: Rolu <rolu@roce.org>
Date: Fri, 29 Jun 2012 22:23:49 +0200
Message-ID: <CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
To: cyberhawk001@gmail.com
X-Gm-Message-State: ALoCoQk7HHPNalvPXFq+TEdJOIzOnDSQ+Wwst4gTZaLVjjZXr8sxsziay+59pazjK9eCOIZCwy/w
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
	DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 29, 2012 at 9:44 PM,  <cyberhawk001@gmail.com> wrote:
> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo don't
> know how updated it is, BUT at the top it said:
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
> Xen 4.1 xl tools notes
>
> Only devices with FLR capabilities are supported.
> Passing through a PCI card without FLR capability will result an error.
>
> To check if your PCI devices have FLR function, check in this wiki, [How =
can
> I check if PCI device supports FLR (Function Level Reset)=A0?]
>
> If you see output with "FLReset-" then your PCI device don't support FLR
> function. If output have "FLReset+" then it does.
>
> As this time of writing, June 2012, there are very very few PCI devices
> support FLR function.
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
>
> THAN was reading here:
> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_devic=
e_supports_FLR_.28Function_Level_Reset.29_.3F
> at the bottom of the page where it says:
>
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
> How can I check if PCI device supports FLR (Function Level Reset)?
>
> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
> DevCap field.
>
> If you are Ubuntu/Debian user don't forget to add sudo at front, otherwis=
e,
> you won't get the result you should get.
>
> sudo lspci -vv | egrep -i --colour flreset
>
> The above line should get root access for lspci program and show colour w=
ith
> flreset it found from output
>
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
> I did that and ALL of my devices it listed showed "FLReset-", there were
> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
> "FLReset+"
>
> SO, I have been trying to get my ATI FirePro V7900 Video Card to passthru=
 to
> a Windows 7 Ultimate DomU with no luck so far AND was wondering how criti=
cal
> was for that device to show as=A0"FLReset+"?
>
> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
> does that mean it is impossible to get it fully working in a Win7 DomU?

I have a video card (Radeon HD 6670) with FLReset- passed through to a
linux domU as a secondary video card (i.e. it boots from the built in
emulated card, not the Radeon) and it works. The FLReset doesn't seem
mandatory.

I am running the latest xen 4.2 unstable though.

> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
> motherboard hardware or the BIOS onboard the Video Card that could be
> updated to get back the "FLReset+" so you can have the FLR reset
> functionality?

I think it depends on the card's hardware. It has to implement this
functionality. A firmware update for the card could maybe add it, but
I haven't heard of any that do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 20:24:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 20:24: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 1Skhjj-0005QN-IM; Fri, 29 Jun 2012 20:24:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1Skhjh-0005QI-5M
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 20:24:13 +0000
Received: from [85.158.143.99:47240] by server-1.bemta-4.messagelabs.com id
	F3/D3-24392-CEE0EEF4; Fri, 29 Jun 2012 20:24:12 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1341001450!20077823!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8024 invoked from network); 29 Jun 2012 20:24:11 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 20:24:11 -0000
Received: by yenl1 with SMTP id l1so3687057yen.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 13:24:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=pO/6y/LPkVR5ffSRQOCfQR71buXT3I3jgz8BP7f728Y=;
	b=VtcGuFGKE5VT08J1tfur9nnxAOMBavWkWaXkj0hMjQPiq+/fQGQjHMrNlPZbseFUed
	4ulhc3a28BuL/Ff6/PGOfIDj6yYDt+oE7iGXv37sSVLESO9UaI0g6X7k/pqVhyaUVUYq
	vXxUwSE7AbkiBsLkXmWZLEN7k+0MHCw0eBJrInXksNkFSFkn/lZXCPC6Fuw0ayGPTWj2
	ue1SHIumD7ImhlI+YwszW7eFDoSi5YqmPIOba5lGzJmHrGCmRYKne5v9zbVCOGJ6KfkQ
	fKjfo9aYmiX7WDPLQKV8BRs7V3toQLKfZOsWxHQ5KFHcZVFvdPNg8zIZc1H74Nx7gQOH
	mCzQ==
Received: by 10.42.155.73 with SMTP id t9mr1753964icw.48.1341001449960; Fri,
	29 Jun 2012 13:24:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Fri, 29 Jun 2012 13:23:49 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FEE05A7.5070004@gmail.com>
References: <4FEE05A7.5070004@gmail.com>
From: Rolu <rolu@roce.org>
Date: Fri, 29 Jun 2012 22:23:49 +0200
Message-ID: <CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
To: cyberhawk001@gmail.com
X-Gm-Message-State: ALoCoQk7HHPNalvPXFq+TEdJOIzOnDSQ+Wwst4gTZaLVjjZXr8sxsziay+59pazjK9eCOIZCwy/w
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
	DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 29, 2012 at 9:44 PM,  <cyberhawk001@gmail.com> wrote:
> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo don't
> know how updated it is, BUT at the top it said:
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
> Xen 4.1 xl tools notes
>
> Only devices with FLR capabilities are supported.
> Passing through a PCI card without FLR capability will result an error.
>
> To check if your PCI devices have FLR function, check in this wiki, [How =
can
> I check if PCI device supports FLR (Function Level Reset)=A0?]
>
> If you see output with "FLReset-" then your PCI device don't support FLR
> function. If output have "FLReset+" then it does.
>
> As this time of writing, June 2012, there are very very few PCI devices
> support FLR function.
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
>
> THAN was reading here:
> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_devic=
e_supports_FLR_.28Function_Level_Reset.29_.3F
> at the bottom of the page where it says:
>
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
> How can I check if PCI device supports FLR (Function Level Reset)?
>
> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
> DevCap field.
>
> If you are Ubuntu/Debian user don't forget to add sudo at front, otherwis=
e,
> you won't get the result you should get.
>
> sudo lspci -vv | egrep -i --colour flreset
>
> The above line should get root access for lspci program and show colour w=
ith
> flreset it found from output
>
> -------------------- -------------------- --------------------
> -------------------- -------------------- --------------------
>
> I did that and ALL of my devices it listed showed "FLReset-", there were
> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
> "FLReset+"
>
> SO, I have been trying to get my ATI FirePro V7900 Video Card to passthru=
 to
> a Windows 7 Ultimate DomU with no luck so far AND was wondering how criti=
cal
> was for that device to show as=A0"FLReset+"?
>
> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
> does that mean it is impossible to get it fully working in a Win7 DomU?

I have a video card (Radeon HD 6670) with FLReset- passed through to a
linux domU as a secondary video card (i.e. it boots from the built in
emulated card, not the Radeon) and it works. The FLReset doesn't seem
mandatory.

I am running the latest xen 4.2 unstable though.

> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
> motherboard hardware or the BIOS onboard the Video Card that could be
> updated to get back the "FLReset+" so you can have the FLR reset
> functionality?

I think it depends on the card's hardware. It has to implement this
functionality. A firmware update for the card could maybe add it, but
I haven't heard of any that do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 21:18:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 21: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 1SkiaB-0007pS-BO; Fri, 29 Jun 2012 21:18:27 +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 1Skia9-0007pN-W9
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 21:18:26 +0000
Received: from [85.158.139.83:45301] by server-7.bemta-5.messagelabs.com id
	00/4F-28276-1AB1EEF4; Fri, 29 Jun 2012 21:18:25 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1341004702!23027325!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxNTk4MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9079 invoked from network); 29 Jun 2012 21:18:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Jun 2012 21:18:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TLIGb7025855
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 21:18:17 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
	q5TLIFjC001421
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 21:18:16 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
	q5TLIFnM027939; Fri, 29 Jun 2012 16:18:15 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 14:18:14 -0700
Date: Fri, 29 Jun 2012 14:18:12 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20120629141812.6ca72375@mantra.us.oracle.com>
In-Reply-To: <4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<4FED7BD7020000780008CBFB@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	IanCampbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 08:56:39 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user
> > mode, I just return cpuid values, as that's what would happen
> > without the HVM container.
> 
> Which means you're not leveraging one of the things you could
> gain from hybrid (after all, returning the native value to user
> mode is one of the weaknesses of PV).
> 
> Jan
> 

Easy, fixed. So, now, for both kernel/user I return pv_cpuid.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 21:18:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 21: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 1SkiaB-0007pS-BO; Fri, 29 Jun 2012 21:18:27 +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 1Skia9-0007pN-W9
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 21:18:26 +0000
Received: from [85.158.139.83:45301] by server-7.bemta-5.messagelabs.com id
	00/4F-28276-1AB1EEF4; Fri, 29 Jun 2012 21:18:25 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1341004702!23027325!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxNTk4MA==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9079 invoked from network); 29 Jun 2012 21:18:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Jun 2012 21:18:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TLIGb7025855
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 21:18:17 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
	q5TLIFjC001421
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 21:18:16 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
	q5TLIFnM027939; Fri, 29 Jun 2012 16:18:15 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 14:18:14 -0700
Date: Fri, 29 Jun 2012 14:18:12 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20120629141812.6ca72375@mantra.us.oracle.com>
In-Reply-To: <4FED7BD7020000780008CBFB@nat28.tlf.novell.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<4FED7BD7020000780008CBFB@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	IanCampbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 08:56:39 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 29.06.12 at 03:00, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user
> > mode, I just return cpuid values, as that's what would happen
> > without the HVM container.
> 
> Which means you're not leveraging one of the things you could
> gain from hybrid (after all, returning the native value to user
> mode is one of the weaknesses of PV).
> 
> Jan
> 

Easy, fixed. So, now, for both kernel/user I return pv_cpuid.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 21:47:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 21: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 1Skj24-0008GE-P8; Fri, 29 Jun 2012 21:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Skj22-0008G9-V6
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 21:47:15 +0000
Received: from [85.158.143.35:43676] by server-2.bemta-4.messagelabs.com id
	50/D3-17938-2622EEF4; Fri, 29 Jun 2012 21:47:14 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1341006431!4874321!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25829 invoked from network); 29 Jun 2012 21:47:13 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 21:47:13 -0000
Received: by ghrr14 with SMTP id r14so3767007ghr.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 14:47:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=qiYUuMy51E4k914l5m3qryMoc553HhUNXpZpAyYPT7o=;
	b=tMMIATnkZed3YDQvMowkw5Bu//uA9AgzJRD2gUy1rMiGZtynEWNe8+12tWd9fcGwF2
	/EAm0ks6TuMn3dP4HGkt1N6u56LUAN7b7Wn9BkDaLijBJBHv+B1iNHkTybq4U1MhbFm9
	cGhCgwA26tkxLmGcYyLYX/zhdBu3uzATrsqXyk/2Tg76SKbOxCH0Dv6L6sYoLcF2LuHa
	XEjSAtm3cBvsHuJsFkETbbKpjeblbdD/fJXdrL8dFXwq75cUA5g4sllyxQ8sRtEflaZK
	U0TOjCb4y76IDMRJC4hxqbyN6OYiHSfM5u8mCvgsQnp9A0siU3r/p899fBb//XzgJCnN
	moSg==
Received: by 10.101.165.13 with SMTP id s13mr1507957ano.1.1341006431053;
	Fri, 29 Jun 2012 14:47:11 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id a64sm8567004yhe.11.2012.06.29.14.47.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 14:47:10 -0700 (PDT)
Message-ID: <4FEE225A.3060405@gmail.com>
Date: Fri, 29 Jun 2012 17:47:06 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
In-Reply-To: <CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
 DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 6/29/2012 4:23 PM, Rolu wrote:
> On Fri, Jun 29, 2012 at 9:44 PM,  <cyberhawk001@gmail.com> wrote:
>> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo don't
>> know how updated it is, BUT at the top it said:
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>> Xen 4.1 xl tools notes
>>
>> Only devices with FLR capabilities are supported.
>> Passing through a PCI card without FLR capability will result an error.
>>
>> To check if your PCI devices have FLR function, check in this wiki, [How can
>> I check if PCI device supports FLR (Function Level Reset) ?]
>>
>> If you see output with "FLReset-" then your PCI device don't support FLR
>> function. If output have "FLReset+" then it does.
>>
>> As this time of writing, June 2012, there are very very few PCI devices
>> support FLR function.
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>>
>> THAN was reading here:
>> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F
>> at the bottom of the page where it says:
>>
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>> How can I check if PCI device supports FLR (Function Level Reset)?
>>
>> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
>> DevCap field.
>>
>> If you are Ubuntu/Debian user don't forget to add sudo at front, otherwise,
>> you won't get the result you should get.
>>
>> sudo lspci -vv | egrep -i --colour flreset
>>
>> The above line should get root access for lspci program and show colour with
>> flreset it found from output
>>
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>> I did that and ALL of my devices it listed showed "FLReset-", there were
>> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
>> "FLReset+"
>>
>> SO, I have been trying to get my ATI FirePro V7900 Video Card to passthru to
>> a Windows 7 Ultimate DomU with no luck so far AND was wondering how critical
>> was for that device to show as "FLReset+"?
>>
>> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
>> does that mean it is impossible to get it fully working in a Win7 DomU?
> I have a video card (Radeon HD 6670) with FLReset- passed through to a
> linux domU as a secondary video card (i.e. it boots from the built in
> emulated card, not the Radeon) and it works. The FLReset doesn't seem
> mandatory.
>
> I am running the latest xen 4.2 unstable though.


SO, what DomU are you using? That means you were able to install the 
Video drivers inside the DomU for your HD6670 card and you can reboot 
the DomU without issues and video still works?


>> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
>> motherboard hardware or the BIOS onboard the Video Card that could be
>> updated to get back the "FLReset+" so you can have the FLR reset
>> functionality?
> I think it depends on the card's hardware. It has to implement this
> functionality. A firmware update for the card could maybe add it, but
> I haven't heard of any that do.

Ya, so far i have not read or heard about this feature, BUT i know the 
FLR rest issues is quite the problem with Windows VMs, probably the same 
thing i am having issues with not working. Once i boot into Win7, 
install the ATI drivers, than reboot the DomU, and it just hangs at the 
"Starting Windows" black screen and never gets past it. I have read a 
bunch of things and will do more trial and error things, but for now 
just wondered about that "FLReset+" as stated on Wiki.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 21:47:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 21: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 1Skj24-0008GE-P8; Fri, 29 Jun 2012 21:47:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Skj22-0008G9-V6
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 21:47:15 +0000
Received: from [85.158.143.35:43676] by server-2.bemta-4.messagelabs.com id
	50/D3-17938-2622EEF4; Fri, 29 Jun 2012 21:47:14 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1341006431!4874321!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25829 invoked from network); 29 Jun 2012 21:47:13 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 21:47:13 -0000
Received: by ghrr14 with SMTP id r14so3767007ghr.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 14:47:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=qiYUuMy51E4k914l5m3qryMoc553HhUNXpZpAyYPT7o=;
	b=tMMIATnkZed3YDQvMowkw5Bu//uA9AgzJRD2gUy1rMiGZtynEWNe8+12tWd9fcGwF2
	/EAm0ks6TuMn3dP4HGkt1N6u56LUAN7b7Wn9BkDaLijBJBHv+B1iNHkTybq4U1MhbFm9
	cGhCgwA26tkxLmGcYyLYX/zhdBu3uzATrsqXyk/2Tg76SKbOxCH0Dv6L6sYoLcF2LuHa
	XEjSAtm3cBvsHuJsFkETbbKpjeblbdD/fJXdrL8dFXwq75cUA5g4sllyxQ8sRtEflaZK
	U0TOjCb4y76IDMRJC4hxqbyN6OYiHSfM5u8mCvgsQnp9A0siU3r/p899fBb//XzgJCnN
	moSg==
Received: by 10.101.165.13 with SMTP id s13mr1507957ano.1.1341006431053;
	Fri, 29 Jun 2012 14:47:11 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id a64sm8567004yhe.11.2012.06.29.14.47.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 14:47:10 -0700 (PDT)
Message-ID: <4FEE225A.3060405@gmail.com>
Date: Fri, 29 Jun 2012 17:47:06 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
In-Reply-To: <CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
 DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 6/29/2012 4:23 PM, Rolu wrote:
> On Fri, Jun 29, 2012 at 9:44 PM,  <cyberhawk001@gmail.com> wrote:
>> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo don't
>> know how updated it is, BUT at the top it said:
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>> Xen 4.1 xl tools notes
>>
>> Only devices with FLR capabilities are supported.
>> Passing through a PCI card without FLR capability will result an error.
>>
>> To check if your PCI devices have FLR function, check in this wiki, [How can
>> I check if PCI device supports FLR (Function Level Reset) ?]
>>
>> If you see output with "FLReset-" then your PCI device don't support FLR
>> function. If output have "FLReset+" then it does.
>>
>> As this time of writing, June 2012, there are very very few PCI devices
>> support FLR function.
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>>
>> THAN was reading here:
>> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F
>> at the bottom of the page where it says:
>>
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>> How can I check if PCI device supports FLR (Function Level Reset)?
>>
>> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
>> DevCap field.
>>
>> If you are Ubuntu/Debian user don't forget to add sudo at front, otherwise,
>> you won't get the result you should get.
>>
>> sudo lspci -vv | egrep -i --colour flreset
>>
>> The above line should get root access for lspci program and show colour with
>> flreset it found from output
>>
>> -------------------- -------------------- --------------------
>> -------------------- -------------------- --------------------
>>
>> I did that and ALL of my devices it listed showed "FLReset-", there were
>> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
>> "FLReset+"
>>
>> SO, I have been trying to get my ATI FirePro V7900 Video Card to passthru to
>> a Windows 7 Ultimate DomU with no luck so far AND was wondering how critical
>> was for that device to show as "FLReset+"?
>>
>> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
>> does that mean it is impossible to get it fully working in a Win7 DomU?
> I have a video card (Radeon HD 6670) with FLReset- passed through to a
> linux domU as a secondary video card (i.e. it boots from the built in
> emulated card, not the Radeon) and it works. The FLReset doesn't seem
> mandatory.
>
> I am running the latest xen 4.2 unstable though.


SO, what DomU are you using? That means you were able to install the 
Video drivers inside the DomU for your HD6670 card and you can reboot 
the DomU without issues and video still works?


>> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
>> motherboard hardware or the BIOS onboard the Video Card that could be
>> updated to get back the "FLReset+" so you can have the FLR reset
>> functionality?
> I think it depends on the card's hardware. It has to implement this
> functionality. A firmware update for the card could maybe add it, but
> I haven't heard of any that do.

Ya, so far i have not read or heard about this feature, BUT i know the 
FLR rest issues is quite the problem with Windows VMs, probably the same 
thing i am having issues with not working. Once i boot into Win7, 
install the ATI drivers, than reboot the DomU, and it just hangs at the 
"Starting Windows" black screen and never gets past it. I have read a 
bunch of things and will do more trial and error things, but for now 
just wondered about that "FLReset+" as stated on Wiki.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 21:52:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 21:52: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 1Skj7G-0008O6-Gg; Fri, 29 Jun 2012 21:52:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyclonusj@gmail.com>) id 1Skj7F-0008Nz-Pl
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 21:52:37 +0000
X-Env-Sender: cyclonusj@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1341006748!9273775!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20476 invoked from network); 29 Jun 2012 21:52:30 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 21:52:30 -0000
Received: by dajz8 with SMTP id z8so6242061daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 29 Jun 2012 14:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=P+9bU9huUlu8A6E0cb+g3NtlExS9LWUNW3BGdTae69w=;
	b=mtMY8iIcI7D+GxsRL9VzWeBEjhXaDFSDqDoVgoCYKTEbS7Boq+WfQA0xCUCfu/2KI8
	ZXD8AXLHf6UAUDrU15awtk7sRbhVUnwCq9tCKFEThddwHGAibixek7CTSei4HIK9ykj6
	lDmXRRp4Rqq7F3q/0jzJZgwtKjBmoU3LzxjB1keDydPIagq7TniERimpldNAdAXE0KHS
	PI1Hcwg3MbjdWhfNo5hfcjj5IrF7+F7prJtaEXRHMrvonGFbpDyl4MRTJrAL93QCYC57
	TMPnJKxAKhdPJ2PhkURWD4CBWCtdW+1IScOBcGqeTG52aA/Fvno0XmyHd+h+8d39oie2
	wE3Q==
Received: by 10.66.86.199 with SMTP id r7mr283920paz.1.1341006748528;
	Fri, 29 Jun 2012 14:52:28 -0700 (PDT)
Received: from gmail.com (searspoint.nvidia.com. [216.228.112.21])
	by mx.google.com with ESMTPS id os3sm6580682pbb.41.2012.06.29.14.52.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 14:52:27 -0700 (PDT)
Date: Fri, 29 Jun 2012 14:52:25 -0700
From: Cyclonus J <cyclonusj@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120629215225.GA7544@gmail.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
	<4FEC6D44.8080807@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FEC6D44.8080807@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 07:42:12AM -0700, H. Peter Anvin wrote:
> On 06/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
> > 
> > Peter mentioned to me had some ideas about software PAT table lookup. I am not
> > exactly sure what he meant by that.
> > 
> 
> I could see the kernel have programmable PAT values rather than fixed if
> and only if it can be showed to have no measurable performance impact.
> 
> > Just to summarize, there were two ways proposed to fix this:
> > 
> >  1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
> >      pte_val (pvops call) instead of pte_flag (native). Here is the patch:
> >      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
> >      (no perf regressions across all platforms)
> > 
> >  2). Introduce a new pvops call - pte_flags, which would make pte_flags
> >      (which currently is doing just a bit mask) be pvops-fied.
> >      http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravirt-xen-Introduce-pte_flags.patch
> >      http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch
> >      (weird results on AMD, other platforms had no perf degradations)
> > 
> >   3). (not posted), was to do 2), but alter the alternative_asm and instead use asm_goto to
> >      make the compiler use less registers and hopefully reduce the code:
> >      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/mmu-perf
> >      But the results I got showed worst performance on baremetal.. which was weird?
> >      Perhaps it is compiler related - never got to follow up on it.
> > 
> 
> OK, let me be blunt: I will unconditionally veto any of these.

Peter,

hmm, It looks like option 1 doesn't have any perf regression, but it is still
not acceptable? That is fine. If you prefer to have a software PAT table lookup, could you provide
some details so I can try to get something align that direction?

CJ

> 
> > 
> > I also chatted with the core Xen hypervisor folks about adding in the context switch code
> > to alter the PAT layout - but they were not keen a about it - and I am not sure how much
> > CPU cycles one loses by doing a wrmsr to the PAT register on every guest context switch
> > (worst case when on has a pvops kernel and a old-style one - where the WC bit would differ)?
> > 
> 
> And you're comparing that to a bunch of new pvops calls?  The discussion
> shouldn't even have started until you had ruled out this solution and
> had data to show it.
> 
> 	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 21:52:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 21:52: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 1Skj7G-0008O6-Gg; Fri, 29 Jun 2012 21:52:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyclonusj@gmail.com>) id 1Skj7F-0008Nz-Pl
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 21:52:37 +0000
X-Env-Sender: cyclonusj@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1341006748!9273775!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20476 invoked from network); 29 Jun 2012 21:52:30 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 21:52:30 -0000
Received: by dajz8 with SMTP id z8so6242061daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 29 Jun 2012 14:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=P+9bU9huUlu8A6E0cb+g3NtlExS9LWUNW3BGdTae69w=;
	b=mtMY8iIcI7D+GxsRL9VzWeBEjhXaDFSDqDoVgoCYKTEbS7Boq+WfQA0xCUCfu/2KI8
	ZXD8AXLHf6UAUDrU15awtk7sRbhVUnwCq9tCKFEThddwHGAibixek7CTSei4HIK9ykj6
	lDmXRRp4Rqq7F3q/0jzJZgwtKjBmoU3LzxjB1keDydPIagq7TniERimpldNAdAXE0KHS
	PI1Hcwg3MbjdWhfNo5hfcjj5IrF7+F7prJtaEXRHMrvonGFbpDyl4MRTJrAL93QCYC57
	TMPnJKxAKhdPJ2PhkURWD4CBWCtdW+1IScOBcGqeTG52aA/Fvno0XmyHd+h+8d39oie2
	wE3Q==
Received: by 10.66.86.199 with SMTP id r7mr283920paz.1.1341006748528;
	Fri, 29 Jun 2012 14:52:28 -0700 (PDT)
Received: from gmail.com (searspoint.nvidia.com. [216.228.112.21])
	by mx.google.com with ESMTPS id os3sm6580682pbb.41.2012.06.29.14.52.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 14:52:27 -0700 (PDT)
Date: Fri, 29 Jun 2012 14:52:25 -0700
From: Cyclonus J <cyclonusj@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120629215225.GA7544@gmail.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
	<4FEC6D44.8080807@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FEC6D44.8080807@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Jun 28, 2012 at 07:42:12AM -0700, H. Peter Anvin wrote:
> On 06/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
> > 
> > Peter mentioned to me had some ideas about software PAT table lookup. I am not
> > exactly sure what he meant by that.
> > 
> 
> I could see the kernel have programmable PAT values rather than fixed if
> and only if it can be showed to have no measurable performance impact.
> 
> > Just to summarize, there were two ways proposed to fix this:
> > 
> >  1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
> >      pte_val (pvops call) instead of pte_flag (native). Here is the patch:
> >      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
> >      (no perf regressions across all platforms)
> > 
> >  2). Introduce a new pvops call - pte_flags, which would make pte_flags
> >      (which currently is doing just a bit mask) be pvops-fied.
> >      http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravirt-xen-Introduce-pte_flags.patch
> >      http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch
> >      (weird results on AMD, other platforms had no perf degradations)
> > 
> >   3). (not posted), was to do 2), but alter the alternative_asm and instead use asm_goto to
> >      make the compiler use less registers and hopefully reduce the code:
> >      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/mmu-perf
> >      But the results I got showed worst performance on baremetal.. which was weird?
> >      Perhaps it is compiler related - never got to follow up on it.
> > 
> 
> OK, let me be blunt: I will unconditionally veto any of these.

Peter,

hmm, It looks like option 1 doesn't have any perf regression, but it is still
not acceptable? That is fine. If you prefer to have a software PAT table lookup, could you provide
some details so I can try to get something align that direction?

CJ

> 
> > 
> > I also chatted with the core Xen hypervisor folks about adding in the context switch code
> > to alter the PAT layout - but they were not keen a about it - and I am not sure how much
> > CPU cycles one loses by doing a wrmsr to the PAT register on every guest context switch
> > (worst case when on has a pvops kernel and a old-style one - where the WC bit would differ)?
> > 
> 
> And you're comparing that to a bunch of new pvops calls?  The discussion
> shouldn't even have started until you had ruled out this solution and
> had data to show it.
> 
> 	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 22:04:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22:04: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 1SkjIp-0000BZ-P2; Fri, 29 Jun 2012 22:04:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkjIo-0000BT-Rh
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 22:04:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1341007468!9329632!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM4NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29174 invoked from network); 29 Jun 2012 22:04:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 22:04:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,500,1336348800"; d="scan'208";a="13300620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 22:04:14 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 23:04:14 +0100
Message-ID: <1341007454.5953.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 29 Jun 2012 23:04:14 +0100
In-Reply-To: <20120629120738.425781e5@mantra.us.oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.camel@zakaz.uk.xensource.com>
	<20120629111546.50e36f52@mantra.us.oracle.com>
	<20120629120738.425781e5@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 20:07 +0100, Mukesh Rathor wrote:
> On Fri, 29 Jun 2012 11:15:46 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > > It's unlikely but not impossible for a userspace developer to have
> > > done some "Xen magic" and used the prefix in userspace.
> > > 
> > > What version of dm_mapper do you have? I checked the version in
> > > Debian Sid and it doesn't do this (at least not directly).
> > > 
> > > Are you able to run the dm_mapper process under gdb and inspect it
> > > to find the prefix?
> > 
> > Well, let me take that back. dm_mapper is the last printk, but it
> > could be anything after that or that. 
> > 
> > Unfortunately, it's dom0 and during boot, so can't run gdb on it. I am
> > hacking the kernel now to print every user process name in schedule.
> 
> Ah, it's "xen-detect" coming in right after dm_mapper. I see the
> xen prefix in it. Hmm... let me see if I can add some run time check
> for hybrid dom0, then won't have to worry about invalid_op trap. Less
> code that way. That's the end goal anyways...

I don't think reducing code should come at the expense of adding special
cases for hybrid to userspace programs...

I think you'll have to handle the invalid op, it can't be that much
code, can 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 Jun 29 22:04:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22:04: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 1SkjIp-0000BZ-P2; Fri, 29 Jun 2012 22:04:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1SkjIo-0000BT-Rh
	for Xen-devel@lists.xensource.com; Fri, 29 Jun 2012 22:04:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1341007468!9329632!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM4NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29174 invoked from network); 29 Jun 2012 22:04:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 22:04:29 -0000
X-IronPort-AV: E=Sophos;i="4.77,500,1336348800"; d="scan'208";a="13300620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jun 2012 22:04:14 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 29 Jun 2012 23:04:14 +0100
Message-ID: <1341007454.5953.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 29 Jun 2012 23:04:14 +0100
In-Reply-To: <20120629120738.425781e5@mantra.us.oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.camel@zakaz.uk.xensource.com>
	<20120629111546.50e36f52@mantra.us.oracle.com>
	<20120629120738.425781e5@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1+b1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-06-29 at 20:07 +0100, Mukesh Rathor wrote:
> On Fri, 29 Jun 2012 11:15:46 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > > It's unlikely but not impossible for a userspace developer to have
> > > done some "Xen magic" and used the prefix in userspace.
> > > 
> > > What version of dm_mapper do you have? I checked the version in
> > > Debian Sid and it doesn't do this (at least not directly).
> > > 
> > > Are you able to run the dm_mapper process under gdb and inspect it
> > > to find the prefix?
> > 
> > Well, let me take that back. dm_mapper is the last printk, but it
> > could be anything after that or that. 
> > 
> > Unfortunately, it's dom0 and during boot, so can't run gdb on it. I am
> > hacking the kernel now to print every user process name in schedule.
> 
> Ah, it's "xen-detect" coming in right after dm_mapper. I see the
> xen prefix in it. Hmm... let me see if I can add some run time check
> for hybrid dom0, then won't have to worry about invalid_op trap. Less
> code that way. That's the end goal anyways...

I don't think reducing code should come at the expense of adding special
cases for hybrid to userspace programs...

I think you'll have to handle the invalid op, it can't be that much
code, can 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 Jun 29 22:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22: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 1SkjQg-0000XP-Nn; Fri, 29 Jun 2012 22:12:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkjQf-0000XK-64
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 22:12:41 +0000
Received: from [85.158.139.83:26390] by server-11.bemta-5.messagelabs.com id
	94/70-20400-8582EEF4; Fri, 29 Jun 2012 22:12:40 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1341007958!25106200!1
X-Originating-IP: [209.85.213.50]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3546 invoked from network); 29 Jun 2012 22:12:39 -0000
Received: from mail-yw0-f50.google.com (HELO mail-yw0-f50.google.com)
	(209.85.213.50)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 22:12:39 -0000
Received: by yhjj63 with SMTP id j63so3923393yhj.37
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:12:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=K+2UfPqpdnHsoTxE0xTjfZMfaFbgl7iaF7DuTR12+ck=;
	b=DzHF86s/5QGGt+fy0Qb664gDtINOMTHqIeCcZDZAzmLVNAHU4v2Ehyihk3vx3AEdXw
	nAghkWv1ZH5zbeF3pSstEQ8Gz16ujP95/GzYTL4iRo9K2p2e8Svfhbm9r+BzTP5A+BdK
	hebV7AI9OC/0cmBm3b3i2uNB9r0hHWvbNRSWOCkIYNrHflzP4Kf6IEDeGXSR2bT4U7SG
	+75H2xFRXNHutUbYdykCxJKdVgLuKAVMn1YUxuL+oETGpSs+3NcV6EfJ9T9eLpWyh9Ia
	elMTGR9ao0QN8DaY55l49R+qcHTGBr80CKV+mZku8rVyDiRFfNG7GegtHfSKHb/5MpGs
	XHkw==
Received: by 10.50.184.230 with SMTP id ex6mr2381573igc.6.1341007957918; Fri,
	29 Jun 2012 15:12:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Fri, 29 Jun 2012 15:12:17 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FEE225A.3060405@gmail.com>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
	<4FEE225A.3060405@gmail.com>
From: Rolu <rolu@roce.org>
Date: Sat, 30 Jun 2012 00:12:17 +0200
Message-ID: <CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
To: cyberhawk001@gmail.com
X-Gm-Message-State: ALoCoQn4WBSnPMgKjfV6rgGZILcT/kKIuDLZcTlDbyIsW4Ntp/9775MBlrts8SxUlW4GLA8fzkSM
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
	DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 29, 2012 at 11:47 PM,  <cyberhawk001@gmail.com> wrote:
> On 6/29/2012 4:23 PM, Rolu wrote:
>>
>> On Fri, Jun 29, 2012 at 9:44 PM, =A0<cyberhawk001@gmail.com> wrote:
>>>
>>> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo
>>> don't
>>> know how updated it is, BUT at the top it said:
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>> Xen 4.1 xl tools notes
>>>
>>> Only devices with FLR capabilities are supported.
>>> Passing through a PCI card without FLR capability will result an error.
>>>
>>> To check if your PCI devices have FLR function, check in this wiki, [How
>>> can
>>> I check if PCI device supports FLR (Function Level Reset) ?]
>>>
>>> If you see output with "FLReset-" then your PCI device don't support FLR
>>> function. If output have "FLReset+" then it does.
>>>
>>> As this time of writing, June 2012, there are very very few PCI devices
>>> support FLR function.
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>>
>>> THAN was reading here:
>>>
>>> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_dev=
ice_supports_FLR_.28Function_Level_Reset.29_.3F
>>> at the bottom of the page where it says:
>>>
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>> How can I check if PCI device supports FLR (Function Level Reset)?
>>>
>>> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
>>> DevCap field.
>>>
>>> If you are Ubuntu/Debian user don't forget to add sudo at front,
>>> otherwise,
>>> you won't get the result you should get.
>>>
>>> sudo lspci -vv | egrep -i --colour flreset
>>>
>>> The above line should get root access for lspci program and show colour
>>> with
>>> flreset it found from output
>>>
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>> I did that and ALL of my devices it listed showed "FLReset-", there were
>>> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
>>> "FLReset+"
>>>
>>> SO, I have been trying to get my ATI FirePro V7900 Video Card to passth=
ru
>>> to
>>> a Windows 7 Ultimate DomU with no luck so far AND was wondering how
>>> critical
>>> was for that device to show as "FLReset+"?
>>>
>>> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
>>> does that mean it is impossible to get it fully working in a Win7 DomU?
>>
>> I have a video card (Radeon HD 6670) with FLReset- passed through to a
>> linux domU as a secondary video card (i.e. it boots from the built in
>> emulated card, not the Radeon) and it works. The FLReset doesn't seem
>> mandatory.
>>
>> I am running the latest xen 4.2 unstable though.
>
>
>
> SO, what DomU are you using? That means you were able to install the Video
> drivers inside the DomU for your HD6670 card and you can reboot the DomU
> without issues and video still works?

Ubuntu 12.04, with ATI's drivers. Yes, it works.

>>> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
>>> motherboard hardware or the BIOS onboard the Video Card that could be
>>> updated to get back the "FLReset+" so you can have the FLR reset
>>> functionality?
>>
>> I think it depends on the card's hardware. It has to implement this
>> functionality. A firmware update for the card could maybe add it, but
>> I haven't heard of any that do.
>
>
> Ya, so far i have not read or heard about this feature, BUT i know the FLR
> rest issues is quite the problem with Windows VMs, probably the same thin=
g i
> am having issues with not working. Once i boot into Win7, install the ATI
> drivers, than reboot the DomU, and it just hangs at the "Starting Windows"
> black screen and never gets past it. I have read a bunch of things and wi=
ll
> do more trial and error things, but for now just wondered about that
> "FLReset+" as stated on Wiki.
>

I don't have a windows 7 VM so I don't know if windows has a problem
with it. Are you using it as a primary or secondary video card?
Secondary seems easier to get to work.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 22:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22: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 1SkjQg-0000XP-Nn; Fri, 29 Jun 2012 22:12:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rolu@roce.org>) id 1SkjQf-0000XK-64
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 22:12:41 +0000
Received: from [85.158.139.83:26390] by server-11.bemta-5.messagelabs.com id
	94/70-20400-8582EEF4; Fri, 29 Jun 2012 22:12:40 +0000
X-Env-Sender: rolu@roce.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1341007958!25106200!1
X-Originating-IP: [209.85.213.50]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3546 invoked from network); 29 Jun 2012 22:12:39 -0000
Received: from mail-yw0-f50.google.com (HELO mail-yw0-f50.google.com)
	(209.85.213.50)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 22:12:39 -0000
Received: by yhjj63 with SMTP id j63so3923393yhj.37
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:12:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=K+2UfPqpdnHsoTxE0xTjfZMfaFbgl7iaF7DuTR12+ck=;
	b=DzHF86s/5QGGt+fy0Qb664gDtINOMTHqIeCcZDZAzmLVNAHU4v2Ehyihk3vx3AEdXw
	nAghkWv1ZH5zbeF3pSstEQ8Gz16ujP95/GzYTL4iRo9K2p2e8Svfhbm9r+BzTP5A+BdK
	hebV7AI9OC/0cmBm3b3i2uNB9r0hHWvbNRSWOCkIYNrHflzP4Kf6IEDeGXSR2bT4U7SG
	+75H2xFRXNHutUbYdykCxJKdVgLuKAVMn1YUxuL+oETGpSs+3NcV6EfJ9T9eLpWyh9Ia
	elMTGR9ao0QN8DaY55l49R+qcHTGBr80CKV+mZku8rVyDiRFfNG7GegtHfSKHb/5MpGs
	XHkw==
Received: by 10.50.184.230 with SMTP id ex6mr2381573igc.6.1341007957918; Fri,
	29 Jun 2012 15:12:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.251.68 with HTTP; Fri, 29 Jun 2012 15:12:17 -0700 (PDT)
X-Originating-IP: [83.117.16.239]
In-Reply-To: <4FEE225A.3060405@gmail.com>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
	<4FEE225A.3060405@gmail.com>
From: Rolu <rolu@roce.org>
Date: Sat, 30 Jun 2012 00:12:17 +0200
Message-ID: <CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
To: cyberhawk001@gmail.com
X-Gm-Message-State: ALoCoQn4WBSnPMgKjfV6rgGZILcT/kKIuDLZcTlDbyIsW4Ntp/9775MBlrts8SxUlW4GLA8fzkSM
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
	DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Jun 29, 2012 at 11:47 PM,  <cyberhawk001@gmail.com> wrote:
> On 6/29/2012 4:23 PM, Rolu wrote:
>>
>> On Fri, Jun 29, 2012 at 9:44 PM, =A0<cyberhawk001@gmail.com> wrote:
>>>
>>> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo
>>> don't
>>> know how updated it is, BUT at the top it said:
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>> Xen 4.1 xl tools notes
>>>
>>> Only devices with FLR capabilities are supported.
>>> Passing through a PCI card without FLR capability will result an error.
>>>
>>> To check if your PCI devices have FLR function, check in this wiki, [How
>>> can
>>> I check if PCI device supports FLR (Function Level Reset) ?]
>>>
>>> If you see output with "FLReset-" then your PCI device don't support FLR
>>> function. If output have "FLReset+" then it does.
>>>
>>> As this time of writing, June 2012, there are very very few PCI devices
>>> support FLR function.
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>>
>>> THAN was reading here:
>>>
>>> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_dev=
ice_supports_FLR_.28Function_Level_Reset.29_.3F
>>> at the bottom of the page where it says:
>>>
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>> How can I check if PCI device supports FLR (Function Level Reset)?
>>>
>>> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
>>> DevCap field.
>>>
>>> If you are Ubuntu/Debian user don't forget to add sudo at front,
>>> otherwise,
>>> you won't get the result you should get.
>>>
>>> sudo lspci -vv | egrep -i --colour flreset
>>>
>>> The above line should get root access for lspci program and show colour
>>> with
>>> flreset it found from output
>>>
>>> -------------------- -------------------- --------------------
>>> -------------------- -------------------- --------------------
>>>
>>> I did that and ALL of my devices it listed showed "FLReset-", there were
>>> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
>>> "FLReset+"
>>>
>>> SO, I have been trying to get my ATI FirePro V7900 Video Card to passth=
ru
>>> to
>>> a Windows 7 Ultimate DomU with no luck so far AND was wondering how
>>> critical
>>> was for that device to show as "FLReset+"?
>>>
>>> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
>>> does that mean it is impossible to get it fully working in a Win7 DomU?
>>
>> I have a video card (Radeon HD 6670) with FLReset- passed through to a
>> linux domU as a secondary video card (i.e. it boots from the built in
>> emulated card, not the Radeon) and it works. The FLReset doesn't seem
>> mandatory.
>>
>> I am running the latest xen 4.2 unstable though.
>
>
>
> SO, what DomU are you using? That means you were able to install the Video
> drivers inside the DomU for your HD6670 card and you can reboot the DomU
> without issues and video still works?

Ubuntu 12.04, with ATI's drivers. Yes, it works.

>>> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
>>> motherboard hardware or the BIOS onboard the Video Card that could be
>>> updated to get back the "FLReset+" so you can have the FLR reset
>>> functionality?
>>
>> I think it depends on the card's hardware. It has to implement this
>> functionality. A firmware update for the card could maybe add it, but
>> I haven't heard of any that do.
>
>
> Ya, so far i have not read or heard about this feature, BUT i know the FLR
> rest issues is quite the problem with Windows VMs, probably the same thin=
g i
> am having issues with not working. Once i boot into Win7, install the ATI
> drivers, than reboot the DomU, and it just hangs at the "Starting Windows"
> black screen and never gets past it. I have read a bunch of things and wi=
ll
> do more trial and error things, but for now just wondered about that
> "FLReset+" as stated on Wiki.
>

I don't have a windows 7 VM so I don't know if windows has a problem
with it. Are you using it as a primary or secondary video card?
Secondary seems easier to get to work.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 22:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Skjdo-0000hv-70; Fri, 29 Jun 2012 22:26:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Skjdm-0000hq-HG
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 22:26:14 +0000
Received: from [85.158.138.51:28599] by server-2.bemta-3.messagelabs.com id
	38/3F-10266-58B2EEF4; Fri, 29 Jun 2012 22:26:13 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1341008771!30347511!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3065 invoked from network); 29 Jun 2012 22:26:12 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 22:26:12 -0000
Received: by ghrr14 with SMTP id r14so3798527ghr.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:26:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=Jr4H6OAj57i33E+2Xb9uvO5rrlvNcl3t+dMqKe5cflk=;
	b=g6AwdU7pGMx4o0nwJWeoR+mTGKUYrkhsHu013vmUMxbrrHD1NAAaLYRPEYUDwc+pQe
	KSA/KLqeSx8fdYXL01ucT0uE3rUpgfI14YWkywgWS3FaMRNMKj//JaSjN1SBxVbbagaH
	27CPG8/H0JN43xsYWO1hABJN/obfhs+zqA6gjjb9P8pSe9JBWKgYEXjb2Mxp+xVRtOjy
	YskLHOesGkx0khNQJ+yKXv/bmN2vJteED6ewAbmhu46k3Xc9o+zzDMdYnJ3kDg9QQ/WJ
	St/krIJZJHa4xCHaDV/bg0kw4re1PW2XwPTOKyyKuT+Ui/Ey8hUAJSAWTZfPZaYv/YXA
	tCqw==
Received: by 10.236.109.229 with SMTP id s65mr5822111yhg.10.1341008771016;
	Fri, 29 Jun 2012 15:26:11 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id m43sm8781007yhi.13.2012.06.29.15.26.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 15:26:10 -0700 (PDT)
Message-ID: <4FEE2B7E.4060901@gmail.com>
Date: Fri, 29 Jun 2012 18:26:06 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
	<4FEE225A.3060405@gmail.com>
	<CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
In-Reply-To: <CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
 DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 6/29/2012 6:12 PM, Rolu wrote:
> On Fri, Jun 29, 2012 at 11:47 PM,  <cyberhawk001@gmail.com> wrote:
>> On 6/29/2012 4:23 PM, Rolu wrote:
>>> On Fri, Jun 29, 2012 at 9:44 PM,  <cyberhawk001@gmail.com> wrote:
>>>> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo
>>>> don't
>>>> know how updated it is, BUT at the top it said:
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>> Xen 4.1 xl tools notes
>>>>
>>>> Only devices with FLR capabilities are supported.
>>>> Passing through a PCI card without FLR capability will result an error.
>>>>
>>>> To check if your PCI devices have FLR function, check in this wiki, [How
>>>> can
>>>> I check if PCI device supports FLR (Function Level Reset) ?]
>>>>
>>>> If you see output with "FLReset-" then your PCI device don't support FLR
>>>> function. If output have "FLReset+" then it does.
>>>>
>>>> As this time of writing, June 2012, there are very very few PCI devices
>>>> support FLR function.
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>>
>>>> THAN was reading here:
>>>>
>>>> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F
>>>> at the bottom of the page where it says:
>>>>
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>> How can I check if PCI device supports FLR (Function Level Reset)?
>>>>
>>>> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
>>>> DevCap field.
>>>>
>>>> If you are Ubuntu/Debian user don't forget to add sudo at front,
>>>> otherwise,
>>>> you won't get the result you should get.
>>>>
>>>> sudo lspci -vv | egrep -i --colour flreset
>>>>
>>>> The above line should get root access for lspci program and show colour
>>>> with
>>>> flreset it found from output
>>>>
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>> I did that and ALL of my devices it listed showed "FLReset-", there were
>>>> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
>>>> "FLReset+"
>>>>
>>>> SO, I have been trying to get my ATI FirePro V7900 Video Card to passthru
>>>> to
>>>> a Windows 7 Ultimate DomU with no luck so far AND was wondering how
>>>> critical
>>>> was for that device to show as "FLReset+"?
>>>>
>>>> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
>>>> does that mean it is impossible to get it fully working in a Win7 DomU?
>>> I have a video card (Radeon HD 6670) with FLReset- passed through to a
>>> linux domU as a secondary video card (i.e. it boots from the built in
>>> emulated card, not the Radeon) and it works. The FLReset doesn't seem
>>> mandatory.
>>>
>>> I am running the latest xen 4.2 unstable though.
>>
>>
>> SO, what DomU are you using? That means you were able to install the Video
>> drivers inside the DomU for your HD6670 card and you can reboot the DomU
>> without issues and video still works?
> Ubuntu 12.04, with ATI's drivers. Yes, it works.
>
>>>> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
>>>> motherboard hardware or the BIOS onboard the Video Card that could be
>>>> updated to get back the "FLReset+" so you can have the FLR reset
>>>> functionality?
>>> I think it depends on the card's hardware. It has to implement this
>>> functionality. A firmware update for the card could maybe add it, but
>>> I haven't heard of any that do.
>>
>> Ya, so far i have not read or heard about this feature, BUT i know the FLR
>> rest issues is quite the problem with Windows VMs, probably the same thing i
>> am having issues with not working. Once i boot into Win7, install the ATI
>> drivers, than reboot the DomU, and it just hangs at the "Starting Windows"
>> black screen and never gets past it. I have read a bunch of things and will
>> do more trial and error things, but for now just wondered about that
>> "FLReset+" as stated on Wiki.
>>
> I don't have a windows 7 VM so I don't know if windows has a problem
> with it. Are you using it as a primary or secondary video card?
> Secondary seems easier to get to work.
>
SO i have heard, but I have been trying to get it to work using 
Secondary VGA Passthru. I tried Primary once and, for a lack of a better 
term, all hell broke loose during DomU boot as QEMU pretty much shut 
down....lol. Granted, i didn't try very hard and didn't apply any 
patched or anything, maybe some day if that feature is a bit more stable 
and there are actual guides on how to make it work, i will try again than.

It probably doesn't make any difference, BUT at the first set of trial 
and error, i had a GeForce 7600GS in PCIex16 Slot#1 so i have video in 
Dom0, than had my ATI FirePro V7900 in the PCIex16 Slot#2 hidden to 
passthru. Now i am trying it with the ATI FirePro V7900 in the PCIex16 
Slot#1 and an older PCI VGA card so i have video in Dom0.

I am using Xen 4.2 Rev25494, so almost the latest. For now i am only 
trying to get Win7 DomU to work, later on will move to Ubuntu. I do know 
that Windows has a lot of issues with FLR and not resetting the VGA 
card, just have to find the right steps to make it get over it. My 
USB3.0 works fine and no issues being passed thru, SO figured since that 
was the only PCI device that had "FLReset+", maybe that was making it 
work correctly as compared to VGA.

BUT, thanks for the reply and i will keep playing with it til i get 
something to work.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 22:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Skjdo-0000hv-70; Fri, 29 Jun 2012 22:26:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyberhawk001@gmail.com>) id 1Skjdm-0000hq-HG
	for xen-devel@lists.xen.org; Fri, 29 Jun 2012 22:26:14 +0000
Received: from [85.158.138.51:28599] by server-2.bemta-3.messagelabs.com id
	38/3F-10266-58B2EEF4; Fri, 29 Jun 2012 22:26:13 +0000
X-Env-Sender: cyberhawk001@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1341008771!30347511!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3065 invoked from network); 29 Jun 2012 22:26:12 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jun 2012 22:26:12 -0000
Received: by ghrr14 with SMTP id r14so3798527ghr.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 15:26:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=Jr4H6OAj57i33E+2Xb9uvO5rrlvNcl3t+dMqKe5cflk=;
	b=g6AwdU7pGMx4o0nwJWeoR+mTGKUYrkhsHu013vmUMxbrrHD1NAAaLYRPEYUDwc+pQe
	KSA/KLqeSx8fdYXL01ucT0uE3rUpgfI14YWkywgWS3FaMRNMKj//JaSjN1SBxVbbagaH
	27CPG8/H0JN43xsYWO1hABJN/obfhs+zqA6gjjb9P8pSe9JBWKgYEXjb2Mxp+xVRtOjy
	YskLHOesGkx0khNQJ+yKXv/bmN2vJteED6ewAbmhu46k3Xc9o+zzDMdYnJ3kDg9QQ/WJ
	St/krIJZJHa4xCHaDV/bg0kw4re1PW2XwPTOKyyKuT+Ui/Ey8hUAJSAWTZfPZaYv/YXA
	tCqw==
Received: by 10.236.109.229 with SMTP id s65mr5822111yhg.10.1341008771016;
	Fri, 29 Jun 2012 15:26:11 -0700 (PDT)
Received: from [192.168.1.2] (c-66-177-73-176.hsd1.fl.comcast.net.
	[66.177.73.176])
	by mx.google.com with ESMTPS id m43sm8781007yhi.13.2012.06.29.15.26.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 29 Jun 2012 15:26:10 -0700 (PDT)
Message-ID: <4FEE2B7E.4060901@gmail.com>
Date: Fri, 29 Jun 2012 18:26:06 -0400
From: cyberhawk001@gmail.com
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
	<4FEE225A.3060405@gmail.com>
	<CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
In-Reply-To: <CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
 DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 6/29/2012 6:12 PM, Rolu wrote:
> On Fri, Jun 29, 2012 at 11:47 PM,  <cyberhawk001@gmail.com> wrote:
>> On 6/29/2012 4:23 PM, Rolu wrote:
>>> On Fri, Jun 29, 2012 at 9:44 PM,  <cyberhawk001@gmail.com> wrote:
>>>> I was reading the Wiki page here: http://wiki.xen.org/wiki/VTd_HowTo
>>>> don't
>>>> know how updated it is, BUT at the top it said:
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>> Xen 4.1 xl tools notes
>>>>
>>>> Only devices with FLR capabilities are supported.
>>>> Passing through a PCI card without FLR capability will result an error.
>>>>
>>>> To check if your PCI devices have FLR function, check in this wiki, [How
>>>> can
>>>> I check if PCI device supports FLR (Function Level Reset) ?]
>>>>
>>>> If you see output with "FLReset-" then your PCI device don't support FLR
>>>> function. If output have "FLReset+" then it does.
>>>>
>>>> As this time of writing, June 2012, there are very very few PCI devices
>>>> support FLR function.
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>>
>>>> THAN was reading here:
>>>>
>>>> http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F
>>>> at the bottom of the page where it says:
>>>>
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>> How can I check if PCI device supports FLR (Function Level Reset)?
>>>>
>>>> Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
>>>> DevCap field.
>>>>
>>>> If you are Ubuntu/Debian user don't forget to add sudo at front,
>>>> otherwise,
>>>> you won't get the result you should get.
>>>>
>>>> sudo lspci -vv | egrep -i --colour flreset
>>>>
>>>> The above line should get root access for lspci program and show colour
>>>> with
>>>> flreset it found from output
>>>>
>>>> -------------------- -------------------- --------------------
>>>> -------------------- -------------------- --------------------
>>>>
>>>> I did that and ALL of my devices it listed showed "FLReset-", there were
>>>> only 3x "Etron Technology, Inc. EJ168 USB3.0" controllers that showed
>>>> "FLReset+"
>>>>
>>>> SO, I have been trying to get my ATI FirePro V7900 Video Card to passthru
>>>> to
>>>> a Windows 7 Ultimate DomU with no luck so far AND was wondering how
>>>> critical
>>>> was for that device to show as "FLReset+"?
>>>>
>>>> 1.) Since my VGA card and AUDIO component of it, shows up as "FLReset-",
>>>> does that mean it is impossible to get it fully working in a Win7 DomU?
>>> I have a video card (Radeon HD 6670) with FLReset- passed through to a
>>> linux domU as a secondary video card (i.e. it boots from the built in
>>> emulated card, not the Radeon) and it works. The FLReset doesn't seem
>>> mandatory.
>>>
>>> I am running the latest xen 4.2 unstable though.
>>
>>
>> SO, what DomU are you using? That means you were able to install the Video
>> drivers inside the DomU for your HD6670 card and you can reboot the DomU
>> without issues and video still works?
> Ubuntu 12.04, with ATI's drivers. Yes, it works.
>
>>>> 2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
>>>> motherboard hardware or the BIOS onboard the Video Card that could be
>>>> updated to get back the "FLReset+" so you can have the FLR reset
>>>> functionality?
>>> I think it depends on the card's hardware. It has to implement this
>>> functionality. A firmware update for the card could maybe add it, but
>>> I haven't heard of any that do.
>>
>> Ya, so far i have not read or heard about this feature, BUT i know the FLR
>> rest issues is quite the problem with Windows VMs, probably the same thing i
>> am having issues with not working. Once i boot into Win7, install the ATI
>> drivers, than reboot the DomU, and it just hangs at the "Starting Windows"
>> black screen and never gets past it. I have read a bunch of things and will
>> do more trial and error things, but for now just wondered about that
>> "FLReset+" as stated on Wiki.
>>
> I don't have a windows 7 VM so I don't know if windows has a problem
> with it. Are you using it as a primary or secondary video card?
> Secondary seems easier to get to work.
>
SO i have heard, but I have been trying to get it to work using 
Secondary VGA Passthru. I tried Primary once and, for a lack of a better 
term, all hell broke loose during DomU boot as QEMU pretty much shut 
down....lol. Granted, i didn't try very hard and didn't apply any 
patched or anything, maybe some day if that feature is a bit more stable 
and there are actual guides on how to make it work, i will try again than.

It probably doesn't make any difference, BUT at the first set of trial 
and error, i had a GeForce 7600GS in PCIex16 Slot#1 so i have video in 
Dom0, than had my ATI FirePro V7900 in the PCIex16 Slot#2 hidden to 
passthru. Now i am trying it with the ATI FirePro V7900 in the PCIex16 
Slot#1 and an older PCI VGA card so i have video in Dom0.

I am using Xen 4.2 Rev25494, so almost the latest. For now i am only 
trying to get Win7 DomU to work, later on will move to Ubuntu. I do know 
that Windows has a lot of issues with FLR and not resetting the VGA 
card, just have to find the right steps to make it get over it. My 
USB3.0 works fine and no issues being passed thru, SO figured since that 
was the only PCI device that had "FLReset+", maybe that was making it 
work correctly as compared to VGA.

BUT, thanks for the reply and i will keep playing with it til i get 
something to work.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 22:30:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22:30: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 1SkjhX-0000ql-7E; Fri, 29 Jun 2012 22:30:07 +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 1SkjhW-0000qe-4T
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 22:30:06 +0000
Received: from [85.158.143.99:54971] by server-2.bemta-4.messagelabs.com id
	58/31-17938-D6C2EEF4; Fri, 29 Jun 2012 22:30:05 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1341009002!24535272!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22284 invoked from network); 29 Jun 2012 22:30:04 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 22:30:04 -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 q5TMTaZA003081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 15:29:37 -0700
Message-ID: <4FEE2C4B.7040405@zytor.com>
Date: Fri, 29 Jun 2012 15:29:31 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Cyclonus J <cyclonusj@gmail.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
	<4FEC6D44.8080807@zytor.com> <20120629215225.GA7544@gmail.com>
In-Reply-To: <20120629215225.GA7544@gmail.com>
X-Enigmail-Version: 1.4.2
Cc: xen-devel@lists.xensource.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/29/2012 02:52 PM, Cyclonus J wrote:
> 
> Peter,
> 
> hmm, It looks like option 1 doesn't have any perf regression, but it is still
> not acceptable? That is fine. If you prefer to have a software PAT table lookup, could you provide
> some details so I can try to get something align that direction?
> 

It has no perf regression, but it really buries deep in the code a
strange abstraction which only happens to work on Xen and is confusing
as hell.

The idea with a software PAT table is that the PAT numbers used by the
kernel should come from a table in the kernel instead of being
hard-coded.  That might take some work, and it remains to be seen if it
is practical.

It *may* be that we need to hard-code 0 as WB, still, but that should be
true on any sane platform.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 22:30:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22:30: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 1SkjhX-0000ql-7E; Fri, 29 Jun 2012 22:30:07 +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 1SkjhW-0000qe-4T
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 22:30:06 +0000
Received: from [85.158.143.99:54971] by server-2.bemta-4.messagelabs.com id
	58/31-17938-D6C2EEF4; Fri, 29 Jun 2012 22:30:05 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1341009002!24535272!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22284 invoked from network); 29 Jun 2012 22:30:04 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 22:30:04 -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 q5TMTaZA003081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 15:29:37 -0700
Message-ID: <4FEE2C4B.7040405@zytor.com>
Date: Fri, 29 Jun 2012 15:29:31 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Cyclonus J <cyclonusj@gmail.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<CABS55+BFrDUV-WR=nx+d6+ZJngpuZnh41DZ3NYU4adFqaxqaNA@mail.gmail.com>
	<20120510153457.GB6389@phenom.dumpdata.com>
	<20120627231755.GA1021@gmail.com>
	<20120628142836.GE8956@phenom.dumpdata.com>
	<4FEC6D44.8080807@zytor.com> <20120629215225.GA7544@gmail.com>
In-Reply-To: <20120629215225.GA7544@gmail.com>
X-Enigmail-Version: 1.4.2
Cc: xen-devel@lists.xensource.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	Jason Garrett-Glaser <jason@x264.com>,
	marmarek@invisiblethingslab.com, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/29/2012 02:52 PM, Cyclonus J wrote:
> 
> Peter,
> 
> hmm, It looks like option 1 doesn't have any perf regression, but it is still
> not acceptable? That is fine. If you prefer to have a software PAT table lookup, could you provide
> some details so I can try to get something align that direction?
> 

It has no perf regression, but it really buries deep in the code a
strange abstraction which only happens to work on Xen and is confusing
as hell.

The idea with a software PAT table is that the PAT numbers used by the
kernel should come from a table in the kernel instead of being
hard-coded.  That might take some work, and it remains to be seen if it
is practical.

It *may* be that we need to hard-code 0 as WB, still, but that should be
true on any sane platform.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Jun 29 22:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22: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 1Skk5F-0001I9-CB; Fri, 29 Jun 2012 22:54: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 1Skk5E-0001I4-75
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 22:54:36 +0000
Received: from [85.158.143.99:58622] by server-1.bemta-4.messagelabs.com id
	36/D5-24392-B223EEF4; Fri, 29 Jun 2012 22:54:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1341010473!26497113!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxNDc1Mw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10853 invoked from network); 29 Jun 2012 22:54:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 22:54:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TMsSGf025783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 22:54:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5TMsRMt026120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 22:54:28 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
	q5TMsR0o010542; Fri, 29 Jun 2012 17:54:27 -0500
Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 15:50:12 -0700
ORGANIZATION: Oracle Corporation
MIME-Version: 1.0
Message-ID: <20120629155000.5152d544@mantra.us.oracle.com>
Date: Fri, 29 Jun 2012 15:50:00 -0700 (PDT)
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.camel@zakaz.uk.xensource.com>
	<20120629111546.50e36f52@mantra.us.oracle.com>
	<20120629120738.425781e5@mantra.us.oracle.com>
	<1341007454.5953.18.camel@dagon.hellion.org.uk>
In-Reply-To: <1341007454.5953.18.camel@dagon.hellion.org.uk>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 15:04:14 -0700 (PDT)
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-06-29 at 20:07 +0100, Mukesh Rathor wrote:
> 
> I don't think reducing code should come at the expense of adding
> special cases for hybrid to userspace programs...
> 
> I think you'll have to handle the invalid op, it can't be that much
> code, can it?

Not a whole lot of code, but other than xen-detect, just curious,
what is the possibility of any user level using XEN_EMULATE_PREFIX cpuid?
The kernel won't, since it's only the hybrid running in hvm container,
and it's modified to use native cpuid. The user level can just run
cpuid and will be trapped in vmexit handler to call pv_cpuid().

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 Jun 29 22:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 29 Jun 2012 22: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 1Skk5F-0001I9-CB; Fri, 29 Jun 2012 22:54: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 1Skk5E-0001I4-75
	for xen-devel@lists.xensource.com; Fri, 29 Jun 2012 22:54:36 +0000
Received: from [85.158.143.99:58622] by server-1.bemta-4.messagelabs.com id
	36/D5-24392-B223EEF4; Fri, 29 Jun 2012 22:54:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1341010473!26497113!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDYxNDc1Mw==\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10853 invoked from network); 29 Jun 2012 22:54:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Jun 2012 22:54:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5TMsSGf025783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 29 Jun 2012 22:54:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5TMsRMt026120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 29 Jun 2012 22:54:28 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
	q5TMsR0o010542; Fri, 29 Jun 2012 17:54:27 -0500
Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 15:50:12 -0700
ORGANIZATION: Oracle Corporation
MIME-Version: 1.0
Message-ID: <20120629155000.5152d544@mantra.us.oracle.com>
Date: Fri, 29 Jun 2012 15:50:00 -0700 (PDT)
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.com>
	<20120628182602.6cc9b432@mantra.us.oracle.com>
	<1340957369.10942.74.camel@zakaz.uk.xensource.com>
	<20120629111546.50e36f52@mantra.us.oracle.com>
	<20120629120738.425781e5@mantra.us.oracle.com>
	<1341007454.5953.18.camel@dagon.hellion.org.uk>
In-Reply-To: <1341007454.5953.18.camel@dagon.hellion.org.uk>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 29 Jun 2012 15:04:14 -0700 (PDT)
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-06-29 at 20:07 +0100, Mukesh Rathor wrote:
> 
> I don't think reducing code should come at the expense of adding
> special cases for hybrid to userspace programs...
> 
> I think you'll have to handle the invalid op, it can't be that much
> code, can it?

Not a whole lot of code, but other than xen-detect, just curious,
what is the possibility of any user level using XEN_EMULATE_PREFIX cpuid?
The kernel won't, since it's only the hybrid running in hvm container,
and it's modified to use native cpuid. The user level can just run
cpuid and will be trapped in vmexit handler to call pv_cpuid().

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 Jun 30 01:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 01: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 1SkmvN-0007UG-Ta; Sat, 30 Jun 2012 01:56:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SkmvM-0007UB-4Z
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 01:56:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1341021388!2512216!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEzMzU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8639 invoked from network); 30 Jun 2012 01:56:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jun 2012 01:56:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5U1uMYr001226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 30 Jun 2012 01:56: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
	q5U1uKC6015040
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 30 Jun 2012 01:56:21 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
	q5U1uIkm023845; Fri, 29 Jun 2012 20:56:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 18:56:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C006D4029A; Fri, 29 Jun 2012 21:48:25 -0400 (EDT)
Date: Fri, 29 Jun 2012 21:48:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120630014825.GA7003@phenom.dumpdata.com>
References: <4FE1C423.6070001@amd.com>
	<20120620145127.GD12787@phenom.dumpdata.com>
	<4FE32DDA.10204@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE32DDA.10204@amd.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 <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >>I tried to find something obvious, but to no avail. At least the new
> >>E820 looks sane, nothing that would prevent the mapping of the
> >>requested regions. Reverting this commit will not work easily on
> >>newer kernels, also is probably not desirable.
> >
> >The one thing that comes to my mind is the 1-1 mapping having
> >some issues. Can you boot the kernel with 'debug loglevel=8'. That should
> >print something like this:
> >
> >Setting pfn cfef0->cfef7 to 1-1
> >or such during bootup.
> 
> Hmm, I couldn't trigger such messages. Do I need some magic config
> to enable them? So far I have (among others):
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_VM=y
> CONFIG_DEBUG_VIRTUAL=y
> CONFIG_DEBUG_MEMORY_INIT=y

They should show up as part of the bootup process:

# dmesg | head
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.5.0-rc4upstream-00211-g9acc7bd (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Thu Jun 28 18:09:41 EDT 2012
[    0.000000] Command line: debug memblock=debug console=tty console=hvc0 earlyprintk=xen loglevel=10 initcall_debug xen-pciback.hide=(04:00.0)
[    0.000000] Disabled fast string operations
[    0.000000] Freeing 9a-100 pfn range: 102 pages freed
[    0.000000] 1-1 mapping on 9a->100
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] 1-1 mapping on 20000->20200
[    0.000000] 1-1 mapping on 40000->40200


> 
> >>
> >>But it does not show on every machine here, so the machine E820
> >>could actually be a differentiator. This particular box was a dual
> >>socket Barcelona server with 12GB of memory.
> >>
> >>This whole PV memory management goes beyond my knowledge, so I'd
> >>like to ask for help on this issue.
> >>If you need more information (I attached the boot log, which shows
> >>the two E820 tables), please ask. I can also quickly do some
> >>experiments if needed.
> >
> >This is strange one - the P2M code should fetch the MFN (so it should
> >give you cfef0) whenever anybody asks for that. Lets double-check that.
> >
> >Can you try this little module?
> 
> Right, it chokes. Mapping memory below 1MB works:
> # insmod testxenmap.ko pfn=0xf8
> # rmmod testxenmap
> # dmesg
> ...
> [   60.369526] va is 0xffff8800000f8000
> [   60.369533] acpi:00000000: 80 dc 0f 00 00 ff 00 00 00 00 00 00 00
> 00 00 00  ................
> [   60.369536] acpi:00000010: 52 53 44 20 50 54 52 20 4a 50 54 4c 54
> 44 20 02  RSD PTR JPTLTD .
> [   60.369538] acpi:00000020: 20 0f ef cf 24 00 00 00 64 0f ef cf 00
> 00 00 00   ...$...d.......
> ....
> you see the magic "RSD PTR " string here, at 0x20 the 32bit address
> of the actual tables (0xcfef0f20), which we try next:
> # insmod testxenmap.ko pfn=0xcfef0
> insmod: error inserting 'testxenmap.ko': -1 Invalid parameters
> # dmesg
> ....
> [  351.964914] ------------[ cut here ]------------
> [  351.964924] WARNING: at /src/linux-2.6/xentest/testxenmap.c:24
> acpitest_init+0x5e/0x1000 [testxenmap]()
> [  351.964926] Hardware name: empty
> [  351.964928] We get cfef0 instead of ffffffffffffffff!

Is cfef0 part of the 1-1 mapping and in ACPI? On my box I see this:

# dmesg | head -30 | grep bc55
[    0.000000] 1-1 mapping on bc558->bc5ac
[    0.000000] Xen: [mem 0x0000000040200000-0x00000000bc557fff] usable
[    0.000000] Xen: [mem 0x00000000bc558000-0x00000000bc560fff] ACPI data

So the E820 has it marked a ACPI data and sure enough I also see this:

[    0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL  DQ67SW   00000016 INTL 20051117)

Let me see what I get with the little module.

> [  351.964933] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
> [  351.964936] Pid: 4937, comm: insmod Tainted: G        W  O
> 3.5.0-rc3+ #106
> [  351.964938] Call Trace:
> [  351.964944]  [<ffffffffa000a05e>] ? acpitest_init+0x5e/0x1000
> [testxenmap]
> [  351.964953]  [<ffffffff81050747>] warn_slowpath_common+0x80/0x98
> [  351.964956]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
> [  351.964959]  [<ffffffff810507f3>] warn_slowpath_fmt+0x41/0x43
> [  351.964963]  [<ffffffffa000a05e>] acpitest_init+0x5e/0x1000 [testxenmap]
> [  351.964966]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
> [  351.964971]  [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
> [  351.964976]  [<ffffffff81094512>] sys_init_module+0xbf/0x24b
> [  351.964982]  [<ffffffff816bb826>] cstar_dispatch+0x7/0x21
> [  351.964985] ---[ end trace 4eaa2a86a8e2da24 ]---
> [  351.964987] raw p2m (cfef0) gives us: ffffffffffffffff
> 
> starting the kernel without dom0_mem (where acpidump works
> flawlessly) also makes the module crash, although only at the point
> dumping the buffer (so this could be a different issue):


Yeah, that is b/c the pfn_to_mfn is trying to use an tree that woudl
not be initialized.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 30 01:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 01: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 1SkmvN-0007UG-Ta; Sat, 30 Jun 2012 01:56:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SkmvM-0007UB-4Z
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 01:56:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1341021388!2512216!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEzMzU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8639 invoked from network); 30 Jun 2012 01:56:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jun 2012 01:56:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5U1uMYr001226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 30 Jun 2012 01:56: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
	q5U1uKC6015040
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 30 Jun 2012 01:56:21 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
	q5U1uIkm023845; Fri, 29 Jun 2012 20:56:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 18:56:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C006D4029A; Fri, 29 Jun 2012 21:48:25 -0400 (EDT)
Date: Fri, 29 Jun 2012 21:48:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120630014825.GA7003@phenom.dumpdata.com>
References: <4FE1C423.6070001@amd.com>
	<20120620145127.GD12787@phenom.dumpdata.com>
	<4FE32DDA.10204@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FE32DDA.10204@amd.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 <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >>I tried to find something obvious, but to no avail. At least the new
> >>E820 looks sane, nothing that would prevent the mapping of the
> >>requested regions. Reverting this commit will not work easily on
> >>newer kernels, also is probably not desirable.
> >
> >The one thing that comes to my mind is the 1-1 mapping having
> >some issues. Can you boot the kernel with 'debug loglevel=8'. That should
> >print something like this:
> >
> >Setting pfn cfef0->cfef7 to 1-1
> >or such during bootup.
> 
> Hmm, I couldn't trigger such messages. Do I need some magic config
> to enable them? So far I have (among others):
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_VM=y
> CONFIG_DEBUG_VIRTUAL=y
> CONFIG_DEBUG_MEMORY_INIT=y

They should show up as part of the bootup process:

# dmesg | head
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.5.0-rc4upstream-00211-g9acc7bd (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Thu Jun 28 18:09:41 EDT 2012
[    0.000000] Command line: debug memblock=debug console=tty console=hvc0 earlyprintk=xen loglevel=10 initcall_debug xen-pciback.hide=(04:00.0)
[    0.000000] Disabled fast string operations
[    0.000000] Freeing 9a-100 pfn range: 102 pages freed
[    0.000000] 1-1 mapping on 9a->100
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] 1-1 mapping on 20000->20200
[    0.000000] 1-1 mapping on 40000->40200


> 
> >>
> >>But it does not show on every machine here, so the machine E820
> >>could actually be a differentiator. This particular box was a dual
> >>socket Barcelona server with 12GB of memory.
> >>
> >>This whole PV memory management goes beyond my knowledge, so I'd
> >>like to ask for help on this issue.
> >>If you need more information (I attached the boot log, which shows
> >>the two E820 tables), please ask. I can also quickly do some
> >>experiments if needed.
> >
> >This is strange one - the P2M code should fetch the MFN (so it should
> >give you cfef0) whenever anybody asks for that. Lets double-check that.
> >
> >Can you try this little module?
> 
> Right, it chokes. Mapping memory below 1MB works:
> # insmod testxenmap.ko pfn=0xf8
> # rmmod testxenmap
> # dmesg
> ...
> [   60.369526] va is 0xffff8800000f8000
> [   60.369533] acpi:00000000: 80 dc 0f 00 00 ff 00 00 00 00 00 00 00
> 00 00 00  ................
> [   60.369536] acpi:00000010: 52 53 44 20 50 54 52 20 4a 50 54 4c 54
> 44 20 02  RSD PTR JPTLTD .
> [   60.369538] acpi:00000020: 20 0f ef cf 24 00 00 00 64 0f ef cf 00
> 00 00 00   ...$...d.......
> ....
> you see the magic "RSD PTR " string here, at 0x20 the 32bit address
> of the actual tables (0xcfef0f20), which we try next:
> # insmod testxenmap.ko pfn=0xcfef0
> insmod: error inserting 'testxenmap.ko': -1 Invalid parameters
> # dmesg
> ....
> [  351.964914] ------------[ cut here ]------------
> [  351.964924] WARNING: at /src/linux-2.6/xentest/testxenmap.c:24
> acpitest_init+0x5e/0x1000 [testxenmap]()
> [  351.964926] Hardware name: empty
> [  351.964928] We get cfef0 instead of ffffffffffffffff!

Is cfef0 part of the 1-1 mapping and in ACPI? On my box I see this:

# dmesg | head -30 | grep bc55
[    0.000000] 1-1 mapping on bc558->bc5ac
[    0.000000] Xen: [mem 0x0000000040200000-0x00000000bc557fff] usable
[    0.000000] Xen: [mem 0x00000000bc558000-0x00000000bc560fff] ACPI data

So the E820 has it marked a ACPI data and sure enough I also see this:

[    0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL  DQ67SW   00000016 INTL 20051117)

Let me see what I get with the little module.

> [  351.964933] Modules linked in: testxenmap(O+) [last unloaded: testxenmap]
> [  351.964936] Pid: 4937, comm: insmod Tainted: G        W  O
> 3.5.0-rc3+ #106
> [  351.964938] Call Trace:
> [  351.964944]  [<ffffffffa000a05e>] ? acpitest_init+0x5e/0x1000
> [testxenmap]
> [  351.964953]  [<ffffffff81050747>] warn_slowpath_common+0x80/0x98
> [  351.964956]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
> [  351.964959]  [<ffffffff810507f3>] warn_slowpath_fmt+0x41/0x43
> [  351.964963]  [<ffffffffa000a05e>] acpitest_init+0x5e/0x1000 [testxenmap]
> [  351.964966]  [<ffffffffa000a000>] ? 0xffffffffa0009fff
> [  351.964971]  [<ffffffff8100215a>] do_one_initcall+0x7a/0x134
> [  351.964976]  [<ffffffff81094512>] sys_init_module+0xbf/0x24b
> [  351.964982]  [<ffffffff816bb826>] cstar_dispatch+0x7/0x21
> [  351.964985] ---[ end trace 4eaa2a86a8e2da24 ]---
> [  351.964987] raw p2m (cfef0) gives us: ffffffffffffffff
> 
> starting the kernel without dom0_mem (where acpidump works
> flawlessly) also makes the module crash, although only at the point
> dumping the buffer (so this could be a different issue):


Yeah, that is b/c the pfn_to_mfn is trying to use an tree that woudl
not be initialized.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 30 02:28:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 02:28:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SknPQ-0008F2-O5; Sat, 30 Jun 2012 02:27:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SknPP-0008Ex-2T
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 02:27:39 +0000
Received: from [85.158.143.35:21141] by server-3.bemta-4.messagelabs.com id
	B4/B9-05808-A146EEF4; Sat, 30 Jun 2012 02:27:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1341023256!14449177!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEzMzU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24768 invoked from network); 30 Jun 2012 02:27:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jun 2012 02:27:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5U2RV7D016166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 30 Jun 2012 02:27:32 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5U2RUrB006271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 30 Jun 2012 02:27:31 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
	q5U2RTkl005068; Fri, 29 Jun 2012 21:27:29 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 19:27:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 777B54029A; Fri, 29 Jun 2012 22:19:36 -0400 (EDT)
Date: Fri, 29 Jun 2012 22:19:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120630021936.GA27100@phenom.dumpdata.com>
References: <4FE1C423.6070001@amd.com>
	<20120620145127.GD12787@phenom.dumpdata.com>
	<4FE32DDA.10204@amd.com>
	<20120630014825.GA7003@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120630014825.GA7003@phenom.dumpdata.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 <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > [  351.964914] ------------[ cut here ]------------
> > [  351.964924] WARNING: at /src/linux-2.6/xentest/testxenmap.c:24
> > acpitest_init+0x5e/0x1000 [testxenmap]()
> > [  351.964926] Hardware name: empty
> > [  351.964928] We get cfef0 instead of ffffffffffffffff!
> 
> Is cfef0 part of the 1-1 mapping and in ACPI? On my box I see this:
> 
> # dmesg | head -30 | grep bc55
> [    0.000000] 1-1 mapping on bc558->bc5ac
> [    0.000000] Xen: [mem 0x0000000040200000-0x00000000bc557fff] usable
> [    0.000000] Xen: [mem 0x00000000bc558000-0x00000000bc560fff] ACPI data
> 
> So the E820 has it marked a ACPI data and sure enough I also see this:
> 
> [    0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL  DQ67SW   00000016 INTL 20051117)
> 
> Let me see what I get with the little module.

So:
[    0.000000] 1-1 mapping on 9a->100
[    0.000000] 1-1 mapping on 20000->20200
[    0.000000] 1-1 mapping on 40000->40200
[    0.000000] 1-1 mapping on bc558->bc5ac
[    0.000000] 1-1 mapping on bc5b4->bc8c5
[    0.000000] 1-1 mapping on bc8c6->bcb7c
[    0.000000] 1-1 mapping on bcd00->100000

> dmesg | grep ACPI: | head
[    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02  INTEL)
[    0.000000] ACPI: XSDT 00000000bc558070 00064 (v01 INTEL  DQ67SW   01072009 AMI  00010013)
[    0.000000] ACPI: FACP 00000000bc55fb50 000F4 (v04 INTEL  DQ67SW   01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL  DQ67SW   00000016 INTL 20051117)
[    0.000000] ACPI: FACS 00000000bc8dbf80 00040
[    0.000000] ACPI: APIC 00000000bc55fc48 00072 (v03 INTEL  DQ67SW   01072009 AMI  00010013)
[    0.000000] ACPI: TCPA 00000000bc55fcc0 00032 (v02 INTEL  DQ67SW   00000001 MSFT 01000013)
[    0.000000] ACPI: SSDT 00000000bc55fcf8 00102 (v01 INTEL  DQ67SW   00000001 MSFT 03000001)
[    0.000000] ACPI: MCFG 00000000bc55fe00 0003C (v01 INTEL  DQ67SW   01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000bc55fe40 00038 (v01 INTEL  DQ67SW   01072009 AMI. 00000004)

02:11:06 # 42 :~/
> rmmod acpidump;insmod /acpidump.ko pfn=0xbc55e

02:11:15 # 43 :~/
> rmmod acpidump;insmod /acpidump.ko pfn=0xbc559

02:11:26 # 44 :~/
> rmmod acpidump;insmod /acpidump.ko pfn=0xbc558
insmod: error inserting '/acpidump.ko': -1 Invalid parameters

2:16:37 # 8 :/data/ 
> insmod /acpidump.ko pfn=0xbc5ac
insmod: error inserting '/acpidump.ko': -1 Invalid parameters

02:16:45 # 10 :/data/
> dmesg | grep p2m
[  389.847683] raw p2m (bc558) gives us: ffffffffffffffff
[  701.348502] raw p2m (bc5ac) gives us: ffffffffffffffff

Huh? Looks like I can access the ACPI regions (bc559 had a bunch of stuff),
but _not_ on the boundary PFNs.

Plot thickens - but sadly I won't be able to do much until Thursday.

I think the issue is somewhere in set_phys_range_identity. This
loop:
 767         for (pfn = pfn_s; pfn < pfn_e; pfn++)
 768                 if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
 769                         break;
 770 

Probably needs pfn <= pfn_e. But that still does not explain
why pfn_s is failing.

Or maybe in the pfn_to_mfn machinary. It certainly has a lot of
overrides in it. If you were to instrument any of those to print
out more details on the offending PFNs that could help.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 30 02:28:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 02:28:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SknPQ-0008F2-O5; Sat, 30 Jun 2012 02:27:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1SknPP-0008Ex-2T
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 02:27:39 +0000
Received: from [85.158.143.35:21141] by server-3.bemta-4.messagelabs.com id
	B4/B9-05808-A146EEF4; Sat, 30 Jun 2012 02:27:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1341023256!14449177!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNjEzMzU5\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24768 invoked from network); 30 Jun 2012 02:27:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jun 2012 02:27:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q5U2RV7D016166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 30 Jun 2012 02:27:32 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q5U2RUrB006271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 30 Jun 2012 02:27:31 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
	q5U2RTkl005068; Fri, 29 Jun 2012 21:27:29 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 29 Jun 2012 19:27:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 777B54029A; Fri, 29 Jun 2012 22:19:36 -0400 (EDT)
Date: Fri, 29 Jun 2012 22:19:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120630021936.GA27100@phenom.dumpdata.com>
References: <4FE1C423.6070001@amd.com>
	<20120620145127.GD12787@phenom.dumpdata.com>
	<4FE32DDA.10204@amd.com>
	<20120630014825.GA7003@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120630014825.GA7003@phenom.dumpdata.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 <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] acpidump crashes on some machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > [  351.964914] ------------[ cut here ]------------
> > [  351.964924] WARNING: at /src/linux-2.6/xentest/testxenmap.c:24
> > acpitest_init+0x5e/0x1000 [testxenmap]()
> > [  351.964926] Hardware name: empty
> > [  351.964928] We get cfef0 instead of ffffffffffffffff!
> 
> Is cfef0 part of the 1-1 mapping and in ACPI? On my box I see this:
> 
> # dmesg | head -30 | grep bc55
> [    0.000000] 1-1 mapping on bc558->bc5ac
> [    0.000000] Xen: [mem 0x0000000040200000-0x00000000bc557fff] usable
> [    0.000000] Xen: [mem 0x00000000bc558000-0x00000000bc560fff] ACPI data
> 
> So the E820 has it marked a ACPI data and sure enough I also see this:
> 
> [    0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL  DQ67SW   00000016 INTL 20051117)
> 
> Let me see what I get with the little module.

So:
[    0.000000] 1-1 mapping on 9a->100
[    0.000000] 1-1 mapping on 20000->20200
[    0.000000] 1-1 mapping on 40000->40200
[    0.000000] 1-1 mapping on bc558->bc5ac
[    0.000000] 1-1 mapping on bc5b4->bc8c5
[    0.000000] 1-1 mapping on bc8c6->bcb7c
[    0.000000] 1-1 mapping on bcd00->100000

> dmesg | grep ACPI: | head
[    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02  INTEL)
[    0.000000] ACPI: XSDT 00000000bc558070 00064 (v01 INTEL  DQ67SW   01072009 AMI  00010013)
[    0.000000] ACPI: FACP 00000000bc55fb50 000F4 (v04 INTEL  DQ67SW   01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 00000000bc558168 079E1 (v02 INTEL  DQ67SW   00000016 INTL 20051117)
[    0.000000] ACPI: FACS 00000000bc8dbf80 00040
[    0.000000] ACPI: APIC 00000000bc55fc48 00072 (v03 INTEL  DQ67SW   01072009 AMI  00010013)
[    0.000000] ACPI: TCPA 00000000bc55fcc0 00032 (v02 INTEL  DQ67SW   00000001 MSFT 01000013)
[    0.000000] ACPI: SSDT 00000000bc55fcf8 00102 (v01 INTEL  DQ67SW   00000001 MSFT 03000001)
[    0.000000] ACPI: MCFG 00000000bc55fe00 0003C (v01 INTEL  DQ67SW   01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000bc55fe40 00038 (v01 INTEL  DQ67SW   01072009 AMI. 00000004)

02:11:06 # 42 :~/
> rmmod acpidump;insmod /acpidump.ko pfn=0xbc55e

02:11:15 # 43 :~/
> rmmod acpidump;insmod /acpidump.ko pfn=0xbc559

02:11:26 # 44 :~/
> rmmod acpidump;insmod /acpidump.ko pfn=0xbc558
insmod: error inserting '/acpidump.ko': -1 Invalid parameters

2:16:37 # 8 :/data/ 
> insmod /acpidump.ko pfn=0xbc5ac
insmod: error inserting '/acpidump.ko': -1 Invalid parameters

02:16:45 # 10 :/data/
> dmesg | grep p2m
[  389.847683] raw p2m (bc558) gives us: ffffffffffffffff
[  701.348502] raw p2m (bc5ac) gives us: ffffffffffffffff

Huh? Looks like I can access the ACPI regions (bc559 had a bunch of stuff),
but _not_ on the boundary PFNs.

Plot thickens - but sadly I won't be able to do much until Thursday.

I think the issue is somewhere in set_phys_range_identity. This
loop:
 767         for (pfn = pfn_s; pfn < pfn_e; pfn++)
 768                 if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
 769                         break;
 770 

Probably needs pfn <= pfn_e. But that still does not explain
why pfn_s is failing.

Or maybe in the pfn_to_mfn machinary. It certainly has a lot of
overrides in it. If you were to instrument any of those to print
out more details on the offending PFNs that could help.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 30 03:52:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 03: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 1SkojD-0000o1-8f; Sat, 30 Jun 2012 03:52:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkojB-0000nw-Ny
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 03:52:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1341028323!4178418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM4NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18966 invoked from network); 30 Jun 2012 03:52:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 03:52:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,501,1336348800"; d="scan'208";a="13301874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jun 2012 03:52:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 30 Jun 2012 04:52:02 +0100
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 1Skoj4-00051w-3U;
	Sat, 30 Jun 2012 03:52:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Skoj4-0004mu-1Q;
	Sat, 30 Jun 2012 04:52:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13407-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 30 Jun 2012 04:52:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13407: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13407 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13407/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13379
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13379
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail like 13379
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  like 13373

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  165eb54e57c0
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
  Zhou Peng <ailvpeng25@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1063 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 Jun 30 03:52:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 03: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 1SkojD-0000o1-8f; Sat, 30 Jun 2012 03:52:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1SkojB-0000nw-Ny
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 03:52:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1341028323!4178418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDM4NDg=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18966 invoked from network); 30 Jun 2012 03:52:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 03:52:03 -0000
X-IronPort-AV: E=Sophos;i="4.77,501,1336348800"; d="scan'208";a="13301874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jun 2012 03:52:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 30 Jun 2012 04:52:02 +0100
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 1Skoj4-00051w-3U;
	Sat, 30 Jun 2012 03:52:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Skoj4-0004mu-1Q;
	Sat, 30 Jun 2012 04:52:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13407-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 30 Jun 2012 04:52:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13407: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13407 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13407/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13379
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13379
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail like 13379
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  like 13373

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  165eb54e57c0
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
  Zhou Peng <ailvpeng25@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1063 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 Jun 30 05:29:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 05:29: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 1SkqF0-00023V-V9; Sat, 30 Jun 2012 05:29:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <devildavidwang@gmail.com>) id 1SkqEz-00023Q-Mq
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 05:29:05 +0000
X-Env-Sender: devildavidwang@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1341034136!2526099!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21009 invoked from network); 30 Jun 2012 05:28:56 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 05:28:56 -0000
Received: by eekd41 with SMTP id d41so1772311eek.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 22:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=sEq7KSnWHnUQcPtmba0GD53YdJEFyEn244ELdICU/cw=;
	b=G3Ce3BTrB4wSzB5voU3Cpok1LP0t9ZZ8EaU19XZL1N2fqFURFGIzF7pxPJC8f5miHf
	KqejJZ8PMrUmtu2TAdW5WZdosL02vhyzvGq80buzVWdS1MEKo6ItlL8JFbE3BLi/eMHd
	q4d+iB77JqEH5TLTrcDMQn7ukZH4HabZrLMqJMTStd2h+ifE5nMpAMnCfIenSqG3ptFj
	T7MdQcI4EtR7KexV5m7Ew6KOW1BSxci8vAF2jK1hQ7ET1mmGrOChoP9Lg/zH4APZFIpa
	FnTtQZG5kBkkc0ziziHXLReObJ/rZ2SuJf8hIhfTEeggLREV36NZQ7ubrWkQjX1F1VMv
	QJYA==
MIME-Version: 1.0
Received: by 10.14.99.206 with SMTP id x54mr1265436eef.94.1341034136608; Fri,
	29 Jun 2012 22:28:56 -0700 (PDT)
Received: by 10.14.186.10 with HTTP; Fri, 29 Jun 2012 22:28:56 -0700 (PDT)
Date: Sat, 30 Jun 2012 13:28:56 +0800
Message-ID: <CAKMyoBWTHXoyRqZdkebyzd2Qa8zXc=-zOzT14=DaJc9rrJ1r7Q@mail.gmail.com>
From: =?UTF-8?B?546L5Yev5by6?= <devildavidwang@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] If i have ONLY ONE graphic card,
	can i passthrou i to 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: multipart/mixed; boundary="===============9002633688282725407=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9002633688282725407==
Content-Type: multipart/alternative; boundary=bcaec52be7d9581e6404c3a9d754

--bcaec52be7d9581e6404c3a9d754
Content-Type: text/plain; charset=ISO-8859-1

i has only one graphic card, and i want to passthrou it, but i always
failed, when i execeute:

*echo -n "0000:03:00.0" > /sys/bus/pci/drivers/nouveau/bind*
*echo -n "0000:03:00.0" > /sys/bus/pci/drivers/pciback/bind*
*
*
The terminal promts:
*bash: echo: write error: No such device*
*
*
* *It will succeed when i passthrou some
other device(such as my wireless network adaptor)

Anyone can tell me if i can achive this?thx ahead.

--bcaec52be7d9581e6404c3a9d754
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

i=A0has=A0only=A0one=A0graphic=A0card,=A0and=A0i=A0want=A0to=A0passthrou=A0=
it,=A0but=A0i=A0always=A0failed,=A0when=A0i=A0execeute:<div><br></div><div>=
<strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vertical-=
align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#39;Lib=
eration Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;text-al=
ign:left">echo -n &quot;0000:03:00.0&quot; &gt; /sys/bus/pci/drivers/nouvea=
u/bind</strong></div>
<div><strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vert=
ical-align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#3=
9;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;te=
xt-align:left"><strong style=3D"margin:0px;padding:0px;border:0px;vertical-=
align:baseline">echo -n &quot;0000:03:00.0&quot; &gt; /sys/bus/pci/drivers/=
pciback/bind</strong></strong></div>
<div><strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vert=
ical-align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#3=
9;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;te=
xt-align:left"><strong style=3D"margin:0px;padding:0px;border:0px;vertical-=
align:baseline"><span style=3D"font-family:arial;font-size:small;font-weigh=
t:normal;line-height:normal;text-align:-webkit-auto"><br>
</span></strong></strong></div><div>The=A0terminal=A0promts:</div><div><str=
ong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vertical-alig=
n:baseline;background-color:rgb(255,255,255);font-family:Arial,&#39;Liberat=
ion Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;text-align:=
left">bash: echo: write error: No such device</strong></div>
<div><strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vert=
ical-align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#3=
9;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;te=
xt-align:left"><br>
</strong></div><div><strong style=3D"margin:0px;padding:0px;border:0px;font=
-size:14px;vertical-align:baseline;background-color:rgb(255,255,255);font-f=
amily:Arial,&#39;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line=
-height:18px;text-align:left"><span style=3D"font-family:arial;font-size:sm=
all;font-weight:normal;line-height:normal;text-align:-webkit-auto">=A0</spa=
n></strong>It=A0will=A0succeed=A0when=A0i=A0passthrou=A0some other=A0device=
(such=A0as=A0my=A0wireless=A0network=A0adaptor)</div>
<div><br></div><div>Anyone=A0can=A0tell=A0me=A0if=A0i=A0can=A0achive=A0this=
?thx=A0ahead.</div>

--bcaec52be7d9581e6404c3a9d754--


--===============9002633688282725407==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9002633688282725407==--


From xen-devel-bounces@lists.xen.org Sat Jun 30 05:29:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 05:29: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 1SkqF0-00023V-V9; Sat, 30 Jun 2012 05:29:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <devildavidwang@gmail.com>) id 1SkqEz-00023Q-Mq
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 05:29:05 +0000
X-Env-Sender: devildavidwang@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1341034136!2526099!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21009 invoked from network); 30 Jun 2012 05:28:56 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 05:28:56 -0000
Received: by eekd41 with SMTP id d41so1772311eek.32
	for <xen-devel@lists.xen.org>; Fri, 29 Jun 2012 22:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=sEq7KSnWHnUQcPtmba0GD53YdJEFyEn244ELdICU/cw=;
	b=G3Ce3BTrB4wSzB5voU3Cpok1LP0t9ZZ8EaU19XZL1N2fqFURFGIzF7pxPJC8f5miHf
	KqejJZ8PMrUmtu2TAdW5WZdosL02vhyzvGq80buzVWdS1MEKo6ItlL8JFbE3BLi/eMHd
	q4d+iB77JqEH5TLTrcDMQn7ukZH4HabZrLMqJMTStd2h+ifE5nMpAMnCfIenSqG3ptFj
	T7MdQcI4EtR7KexV5m7Ew6KOW1BSxci8vAF2jK1hQ7ET1mmGrOChoP9Lg/zH4APZFIpa
	FnTtQZG5kBkkc0ziziHXLReObJ/rZ2SuJf8hIhfTEeggLREV36NZQ7ubrWkQjX1F1VMv
	QJYA==
MIME-Version: 1.0
Received: by 10.14.99.206 with SMTP id x54mr1265436eef.94.1341034136608; Fri,
	29 Jun 2012 22:28:56 -0700 (PDT)
Received: by 10.14.186.10 with HTTP; Fri, 29 Jun 2012 22:28:56 -0700 (PDT)
Date: Sat, 30 Jun 2012 13:28:56 +0800
Message-ID: <CAKMyoBWTHXoyRqZdkebyzd2Qa8zXc=-zOzT14=DaJc9rrJ1r7Q@mail.gmail.com>
From: =?UTF-8?B?546L5Yev5by6?= <devildavidwang@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] If i have ONLY ONE graphic card,
	can i passthrou i to 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: multipart/mixed; boundary="===============9002633688282725407=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9002633688282725407==
Content-Type: multipart/alternative; boundary=bcaec52be7d9581e6404c3a9d754

--bcaec52be7d9581e6404c3a9d754
Content-Type: text/plain; charset=ISO-8859-1

i has only one graphic card, and i want to passthrou it, but i always
failed, when i execeute:

*echo -n "0000:03:00.0" > /sys/bus/pci/drivers/nouveau/bind*
*echo -n "0000:03:00.0" > /sys/bus/pci/drivers/pciback/bind*
*
*
The terminal promts:
*bash: echo: write error: No such device*
*
*
* *It will succeed when i passthrou some
other device(such as my wireless network adaptor)

Anyone can tell me if i can achive this?thx ahead.

--bcaec52be7d9581e6404c3a9d754
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

i=A0has=A0only=A0one=A0graphic=A0card,=A0and=A0i=A0want=A0to=A0passthrou=A0=
it,=A0but=A0i=A0always=A0failed,=A0when=A0i=A0execeute:<div><br></div><div>=
<strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vertical-=
align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#39;Lib=
eration Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;text-al=
ign:left">echo -n &quot;0000:03:00.0&quot; &gt; /sys/bus/pci/drivers/nouvea=
u/bind</strong></div>
<div><strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vert=
ical-align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#3=
9;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;te=
xt-align:left"><strong style=3D"margin:0px;padding:0px;border:0px;vertical-=
align:baseline">echo -n &quot;0000:03:00.0&quot; &gt; /sys/bus/pci/drivers/=
pciback/bind</strong></strong></div>
<div><strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vert=
ical-align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#3=
9;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;te=
xt-align:left"><strong style=3D"margin:0px;padding:0px;border:0px;vertical-=
align:baseline"><span style=3D"font-family:arial;font-size:small;font-weigh=
t:normal;line-height:normal;text-align:-webkit-auto"><br>
</span></strong></strong></div><div>The=A0terminal=A0promts:</div><div><str=
ong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vertical-alig=
n:baseline;background-color:rgb(255,255,255);font-family:Arial,&#39;Liberat=
ion Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;text-align:=
left">bash: echo: write error: No such device</strong></div>
<div><strong style=3D"margin:0px;padding:0px;border:0px;font-size:14px;vert=
ical-align:baseline;background-color:rgb(255,255,255);font-family:Arial,&#3=
9;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line-height:18px;te=
xt-align:left"><br>
</strong></div><div><strong style=3D"margin:0px;padding:0px;border:0px;font=
-size:14px;vertical-align:baseline;background-color:rgb(255,255,255);font-f=
amily:Arial,&#39;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;line=
-height:18px;text-align:left"><span style=3D"font-family:arial;font-size:sm=
all;font-weight:normal;line-height:normal;text-align:-webkit-auto">=A0</spa=
n></strong>It=A0will=A0succeed=A0when=A0i=A0passthrou=A0some other=A0device=
(such=A0as=A0my=A0wireless=A0network=A0adaptor)</div>
<div><br></div><div>Anyone=A0can=A0tell=A0me=A0if=A0i=A0can=A0achive=A0this=
?thx=A0ahead.</div>

--bcaec52be7d9581e6404c3a9d754--


--===============9002633688282725407==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9002633688282725407==--


From xen-devel-bounces@lists.xen.org Sat Jun 30 07:24:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 07:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sks2Y-0003WL-HY; Sat, 30 Jun 2012 07:24:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1Sks2W-0003WG-AW
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 07:24:20 +0000
Received: from [85.158.139.83:13277] by server-9.bemta-5.messagelabs.com id
	15/4C-01069-3A9AEEF4; Sat, 30 Jun 2012 07:24:19 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1341041055!26331925!1
X-Originating-IP: [220.181.15.8]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gOTcwMw==\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gOTcwMw==\n,HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4387 invoked from network); 30 Jun 2012 07:24:17 -0000
Received: from m15-8.126.com (HELO m15-8.126.com) (220.181.15.8)
	by server-7.tower-182.messagelabs.com with SMTP;
	30 Jun 2012 07:24:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=NsXKQq6llMqGNUzzvrl4Dw8FOk6WFb05cnGl
	5+eyftM=; b=mRyFXMsbB6hLWfO/Y0+P7/bMi+MAesTpwbbdwLUMc458unOZsx+2
	WOAScfv4vu7dt2+WQ/11aaDTM56ZXh3INwSC+Esg9mFxxDvaT2F7fZmFbXJcrLY3
	EVU7it5Dh7jd57Af1pyY69qPukj/lHibV/1j3yKbETuf6ncKoaPgCGo=
Received: from hxkhust$126.com ( [115.156.232.40] ) by ajax-webmail-wmsvr8
	(Coremail) ; Sat, 30 Jun 2012 15:24:13 +0800 (CST)
X-Originating-IP: [115.156.232.40]
Date: Sat, 30 Jun 2012 15:24:13 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: Qz83PmZvb3Rlcl9odG09NDA4Ojgx
MIME-Version: 1.0
Message-ID: <137ef2ca.1bc95.1383c468eaf.Coremail.hxkhust@126.com>
X-CM-TRANSID: CMqowGAp0EGdqe5PAv03AA--.4092W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiExvdBU0vKtkmxQABsj
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] block-raw-posix.c and block-raw-win32.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: multipart/mixed; boundary="===============5789328849541935066=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5789328849541935066==
Content-Type: multipart/alternative; 
	boundary="----=_Part_297626_856115043.1341041053358"

------=_Part_297626_856115043.1341041053358
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,guys!In the directory of /xen-4.1.2/tools/ioemu-qemu-xen ,there are two files ,block-raw-posix.c and block-raw-win32.c,which both define the BlockDriver bdrv_raw.what is the difference between them ?hxkhust
------=_Part_297626_856115043.1341041053358
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><pre style="line-height: 25px; ">Hi,guys!</pre><pre style="line-height: 25px; ">In the directory of /xen-4.1.2/tools/ioemu-qemu-xen ,there are two files ,block-raw-posix.c and block-raw-win32.c,which both define the BlockDriver bdrv_raw.what is the difference between them ?</pre><pre style="line-height: 25px; ">hxkhust</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_297626_856115043.1341041053358--



--===============5789328849541935066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5789328849541935066==--



From xen-devel-bounces@lists.xen.org Sat Jun 30 07:24:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 07:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sks2Y-0003WL-HY; Sat, 30 Jun 2012 07:24:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1Sks2W-0003WG-AW
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 07:24:20 +0000
Received: from [85.158.139.83:13277] by server-9.bemta-5.messagelabs.com id
	15/4C-01069-3A9AEEF4; Sat, 30 Jun 2012 07:24:19 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1341041055!26331925!1
X-Originating-IP: [220.181.15.8]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gOTcwMw==\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gOTcwMw==\n,HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4387 invoked from network); 30 Jun 2012 07:24:17 -0000
Received: from m15-8.126.com (HELO m15-8.126.com) (220.181.15.8)
	by server-7.tower-182.messagelabs.com with SMTP;
	30 Jun 2012 07:24:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=NsXKQq6llMqGNUzzvrl4Dw8FOk6WFb05cnGl
	5+eyftM=; b=mRyFXMsbB6hLWfO/Y0+P7/bMi+MAesTpwbbdwLUMc458unOZsx+2
	WOAScfv4vu7dt2+WQ/11aaDTM56ZXh3INwSC+Esg9mFxxDvaT2F7fZmFbXJcrLY3
	EVU7it5Dh7jd57Af1pyY69qPukj/lHibV/1j3yKbETuf6ncKoaPgCGo=
Received: from hxkhust$126.com ( [115.156.232.40] ) by ajax-webmail-wmsvr8
	(Coremail) ; Sat, 30 Jun 2012 15:24:13 +0800 (CST)
X-Originating-IP: [115.156.232.40]
Date: Sat, 30 Jun 2012 15:24:13 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: Qz83PmZvb3Rlcl9odG09NDA4Ojgx
MIME-Version: 1.0
Message-ID: <137ef2ca.1bc95.1383c468eaf.Coremail.hxkhust@126.com>
X-CM-TRANSID: CMqowGAp0EGdqe5PAv03AA--.4092W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiExvdBU0vKtkmxQABsj
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] block-raw-posix.c and block-raw-win32.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: multipart/mixed; boundary="===============5789328849541935066=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5789328849541935066==
Content-Type: multipart/alternative; 
	boundary="----=_Part_297626_856115043.1341041053358"

------=_Part_297626_856115043.1341041053358
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,guys!In the directory of /xen-4.1.2/tools/ioemu-qemu-xen ,there are two files ,block-raw-posix.c and block-raw-win32.c,which both define the BlockDriver bdrv_raw.what is the difference between them ?hxkhust
------=_Part_297626_856115043.1341041053358
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><pre style="line-height: 25px; ">Hi,guys!</pre><pre style="line-height: 25px; ">In the directory of /xen-4.1.2/tools/ioemu-qemu-xen ,there are two files ,block-raw-posix.c and block-raw-win32.c,which both define the BlockDriver bdrv_raw.what is the difference between them ?</pre><pre style="line-height: 25px; ">hxkhust</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_297626_856115043.1341041053358--



--===============5789328849541935066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5789328849541935066==--



From xen-devel-bounces@lists.xen.org Sat Jun 30 10:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 10:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkvE8-00068Y-Uq; Sat, 30 Jun 2012 10:48:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkvE6-00068T-NO
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 10:48:30 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1341053302!9363991!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14358 invoked from network); 30 Jun 2012 10:48:23 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 10:48:23 -0000
Received: by vcbfo13 with SMTP id fo13so3467131vcb.32
	for <xen-devel@lists.xen.org>; Sat, 30 Jun 2012 03:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=DerlQtVhzZnX/7AtVap5SbSubl9xXfR4+0dfCj8Jtqc=;
	b=ySdPNKVrpGyovMLHmCf1farKE6PTDxyMsma7Xb0En3XJ+BjIqKZDRFdXqvmtVn3PJ2
	bRH2JVl6uwIIUp+DR2h7NWomH9tVH5oNTYTpYdYv58ohicQwLzv9Sl6fmotkGdDO4tQB
	Ne7keXmVfM6qUHLCp8XY0diuqz9PJztYmskbR3+hEonbt4dNzNLcB90XzQO67An8KpDo
	WHh6JDSd8lbRDhD9SM4MwlGfYF7KuDH6WvWstoxOhCf4Xrob5lJf0EdiBm5rttjRhaU2
	dsk5IDTKND48Y4y/nael/D7YHAPVLStTUwE89dZZDREIUNNzFntGNIOHZ28wg7AukPKi
	squw==
Received: by 10.52.178.170 with SMTP id cz10mr2341658vdc.44.1341053302380;
	Sat, 30 Jun 2012 03:48:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Sat, 30 Jun 2012 03:48:02 -0700 (PDT)
In-Reply-To: <CAKMyoBWTHXoyRqZdkebyzd2Qa8zXc=-zOzT14=DaJc9rrJ1r7Q@mail.gmail.com>
References: <CAKMyoBWTHXoyRqZdkebyzd2Qa8zXc=-zOzT14=DaJc9rrJ1r7Q@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 30 Jun 2012 11:48:02 +0100
Message-ID: <CAEBdQ91unW1ahb1cCXPXh_xVN+agsF44CG_HXJFYU1pX4mO5FA@mail.gmail.com>
To: =?UTF-8?B?546L5Yev5by6?= <devildavidwang@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] If i have ONLY ONE graphic card,
 can i passthrou i to 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IGVjaG8gLW4gIjAwMDA6MDM6MDAuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9ub3V2ZWF1L3Vu
YmluZAogZWNobyAtbiAiMDAwMDowMzowMC4wIiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaWJh
Y2svbmV3X3Nsb3QKIGVjaG8gLW4gIjAwMDA6MDM6MDAuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVy
cy9wY2liYWNrL2JpbmQKCgpPbiAzMCBKdW5lIDIwMTIgMDY6MjgsIOeOi+WHr+W8uiA8ZGV2aWxk
YXZpZHdhbmdAZ21haWwuY29tPiB3cm90ZToKPiBpwqBoYXPCoG9ubHnCoG9uZcKgZ3JhcGhpY8Kg
Y2FyZCzCoGFuZMKgacKgd2FudMKgdG/CoHBhc3N0aHJvdcKgaXQswqBidXTCoGnCoGFsd2F5c8Kg
ZmFpbGVkLMKgd2hlbsKgacKgZXhlY2V1dGU6Cj4KPiBlY2hvIC1uICIwMDAwOjAzOjAwLjAiID4g
L3N5cy9idXMvcGNpL2RyaXZlcnMvbm91dmVhdS9iaW5kCj4gZWNobyAtbiAiMDAwMDowMzowMC4w
IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaWJhY2svYmluZAo+Cj4gVGhlwqB0ZXJtaW5hbMKg
cHJvbXRzOgo+IGJhc2g6IGVjaG86IHdyaXRlIGVycm9yOiBObyBzdWNoIGRldmljZQo+Cj4gwqBJ
dMKgd2lsbMKgc3VjY2VlZMKgd2hlbsKgacKgcGFzc3Rocm91wqBzb21lCj4gb3RoZXLCoGRldmlj
ZShzdWNowqBhc8KgbXnCoHdpcmVsZXNzwqBuZXR3b3JrwqBhZGFwdG9yKQo+Cj4gQW55b25lwqBj
YW7CoHRlbGzCoG1lwqBpZsKgacKgY2FuwqBhY2hpdmXCoHRoaXM/dGh4wqBhaGVhZC4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sat Jun 30 10:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 10:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1SkvE8-00068Y-Uq; Sat, 30 Jun 2012 10:48:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1SkvE6-00068T-NO
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 10:48:30 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1341053302!9363991!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14358 invoked from network); 30 Jun 2012 10:48:23 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 10:48:23 -0000
Received: by vcbfo13 with SMTP id fo13so3467131vcb.32
	for <xen-devel@lists.xen.org>; Sat, 30 Jun 2012 03:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=DerlQtVhzZnX/7AtVap5SbSubl9xXfR4+0dfCj8Jtqc=;
	b=ySdPNKVrpGyovMLHmCf1farKE6PTDxyMsma7Xb0En3XJ+BjIqKZDRFdXqvmtVn3PJ2
	bRH2JVl6uwIIUp+DR2h7NWomH9tVH5oNTYTpYdYv58ohicQwLzv9Sl6fmotkGdDO4tQB
	Ne7keXmVfM6qUHLCp8XY0diuqz9PJztYmskbR3+hEonbt4dNzNLcB90XzQO67An8KpDo
	WHh6JDSd8lbRDhD9SM4MwlGfYF7KuDH6WvWstoxOhCf4Xrob5lJf0EdiBm5rttjRhaU2
	dsk5IDTKND48Y4y/nael/D7YHAPVLStTUwE89dZZDREIUNNzFntGNIOHZ28wg7AukPKi
	squw==
Received: by 10.52.178.170 with SMTP id cz10mr2341658vdc.44.1341053302380;
	Sat, 30 Jun 2012 03:48:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.113.65 with HTTP; Sat, 30 Jun 2012 03:48:02 -0700 (PDT)
In-Reply-To: <CAKMyoBWTHXoyRqZdkebyzd2Qa8zXc=-zOzT14=DaJc9rrJ1r7Q@mail.gmail.com>
References: <CAKMyoBWTHXoyRqZdkebyzd2Qa8zXc=-zOzT14=DaJc9rrJ1r7Q@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 30 Jun 2012 11:48:02 +0100
Message-ID: <CAEBdQ91unW1ahb1cCXPXh_xVN+agsF44CG_HXJFYU1pX4mO5FA@mail.gmail.com>
To: =?UTF-8?B?546L5Yev5by6?= <devildavidwang@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] If i have ONLY ONE graphic card,
 can i passthrou i to 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IGVjaG8gLW4gIjAwMDA6MDM6MDAuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9ub3V2ZWF1L3Vu
YmluZAogZWNobyAtbiAiMDAwMDowMzowMC4wIiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaWJh
Y2svbmV3X3Nsb3QKIGVjaG8gLW4gIjAwMDA6MDM6MDAuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVy
cy9wY2liYWNrL2JpbmQKCgpPbiAzMCBKdW5lIDIwMTIgMDY6MjgsIOeOi+WHr+W8uiA8ZGV2aWxk
YXZpZHdhbmdAZ21haWwuY29tPiB3cm90ZToKPiBpwqBoYXPCoG9ubHnCoG9uZcKgZ3JhcGhpY8Kg
Y2FyZCzCoGFuZMKgacKgd2FudMKgdG/CoHBhc3N0aHJvdcKgaXQswqBidXTCoGnCoGFsd2F5c8Kg
ZmFpbGVkLMKgd2hlbsKgacKgZXhlY2V1dGU6Cj4KPiBlY2hvIC1uICIwMDAwOjAzOjAwLjAiID4g
L3N5cy9idXMvcGNpL2RyaXZlcnMvbm91dmVhdS9iaW5kCj4gZWNobyAtbiAiMDAwMDowMzowMC4w
IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaWJhY2svYmluZAo+Cj4gVGhlwqB0ZXJtaW5hbMKg
cHJvbXRzOgo+IGJhc2g6IGVjaG86IHdyaXRlIGVycm9yOiBObyBzdWNoIGRldmljZQo+Cj4gwqBJ
dMKgd2lsbMKgc3VjY2VlZMKgd2hlbsKgacKgcGFzc3Rocm91wqBzb21lCj4gb3RoZXLCoGRldmlj
ZShzdWNowqBhc8KgbXnCoHdpcmVsZXNzwqBuZXR3b3JrwqBhZGFwdG9yKQo+Cj4gQW55b25lwqBj
YW7CoHRlbGzCoG1lwqBpZsKgacKgY2FuwqBhY2hpdmXCoHRoaXM/dGh4wqBhaGVhZC4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sat Jun 30 11:49:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 11:49: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 1SkwAR-0007BL-D7; Sat, 30 Jun 2012 11:48:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SkwAQ-0007BG-97
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 11:48:46 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1341056919!9390570!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Mzc0ODc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11215 invoked from network); 30 Jun 2012 11:48:39 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jun 2012 11:48:39 -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 75C0B1057;
	Sat, 30 Jun 2012 14:48:38 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 47B372005D; Sat, 30 Jun 2012 14:48:38 +0300 (EEST)
Date: Sat, 30 Jun 2012 14:48:38 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: cyberhawk001@gmail.com
Message-ID: <20120630114837.GT2058@reaktio.net>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
	<4FEE225A.3060405@gmail.com>
	<CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
	<4FEE2B7E.4060901@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FEE2B7E.4060901@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
 DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 29, 2012 at 06:26:06PM -0400, cyberhawk001@gmail.com wrote:
> >Ubuntu 12.04, with ATI's drivers. Yes, it works.
> >
> >>>>2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
> >>>>motherboard hardware or the BIOS onboard the Video Card that could be
> >>>>updated to get back the "FLReset+" so you can have the FLR reset
> >>>>functionality?
> >>>I think it depends on the card's hardware. It has to implement this
> >>>functionality. A firmware update for the card could maybe add it, but
> >>>I haven't heard of any that do.
> >>
> >>Ya, so far i have not read or heard about this feature, BUT i know the FLR
> >>rest issues is quite the problem with Windows VMs, probably the same thing i
> >>am having issues with not working. Once i boot into Win7, install the ATI
> >>drivers, than reboot the DomU, and it just hangs at the "Starting Windows"
> >>black screen and never gets past it. I have read a bunch of things and will
> >>do more trial and error things, but for now just wondered about that
> >>"FLReset+" as stated on Wiki.
> >>
> >I don't have a windows 7 VM so I don't know if windows has a problem
> >with it. Are you using it as a primary or secondary video card?
> >Secondary seems easier to get to work.
> >
> SO i have heard, but I have been trying to get it to work using
> Secondary VGA Passthru. I tried Primary once and, for a lack of a
> better term, all hell broke loose during DomU boot as QEMU pretty
> much shut down....lol. Granted, i didn't try very hard and didn't
> apply any patched or anything, maybe some day if that feature is a
> bit more stable and there are actual guides on how to make it work,
> i will try again than.
> 
> It probably doesn't make any difference, BUT at the first set of
> trial and error, i had a GeForce 7600GS in PCIex16 Slot#1 so i have
> video in Dom0, than had my ATI FirePro V7900 in the PCIex16 Slot#2
> hidden to passthru. Now i am trying it with the ATI FirePro V7900 in
> the PCIex16 Slot#1 and an older PCI VGA card so i have video in
> Dom0.
> 
> I am using Xen 4.2 Rev25494, so almost the latest. For now i am only
> trying to get Win7 DomU to work, later on will move to Ubuntu. I do
> know that Windows has a lot of issues with FLR and not resetting the
> VGA card, just have to find the right steps to make it get over it.
> My USB3.0 works fine and no issues being passed thru, SO figured
> since that was the only PCI device that had "FLReset+", maybe that
> was making it work correctly as compared to VGA.
> 
> BUT, thanks for the reply and i will keep playing with it til i get
> something to work.
> 

Btw you probably want to try with xm/xend toolstack aswell.. 
just to verify if it's any different there.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 30 11:49:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 11:49: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 1SkwAR-0007BL-D7; Sat, 30 Jun 2012 11:48:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1SkwAQ-0007BG-97
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 11:48:46 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1341056919!9390570!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Mzc0ODc=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11215 invoked from network); 30 Jun 2012 11:48:39 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jun 2012 11:48:39 -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 75C0B1057;
	Sat, 30 Jun 2012 14:48:38 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 47B372005D; Sat, 30 Jun 2012 14:48:38 +0300 (EEST)
Date: Sat, 30 Jun 2012 14:48:38 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: cyberhawk001@gmail.com
Message-ID: <20120630114837.GT2058@reaktio.net>
References: <4FEE05A7.5070004@gmail.com>
	<CABs9EjnHrv9FH=ikdEZB_jyyP-27Lzx4f5BxFSDUWkDdq_h4ig@mail.gmail.com>
	<4FEE225A.3060405@gmail.com>
	<CABs9Ejmf4Ti8wWwbQmXfVDQHBJc=6+R13Qo0_7fvwZAaeh-kAA@mail.gmail.com>
	<4FEE2B7E.4060901@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4FEE2B7E.4060901@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] How vital is having "FLReset+" for VGA Passthru in
 DomU?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Jun 29, 2012 at 06:26:06PM -0400, cyberhawk001@gmail.com wrote:
> >Ubuntu 12.04, with ATI's drivers. Yes, it works.
> >
> >>>>2.) Does having the feature "FLReset+" depend on the motherboard BIOS,
> >>>>motherboard hardware or the BIOS onboard the Video Card that could be
> >>>>updated to get back the "FLReset+" so you can have the FLR reset
> >>>>functionality?
> >>>I think it depends on the card's hardware. It has to implement this
> >>>functionality. A firmware update for the card could maybe add it, but
> >>>I haven't heard of any that do.
> >>
> >>Ya, so far i have not read or heard about this feature, BUT i know the FLR
> >>rest issues is quite the problem with Windows VMs, probably the same thing i
> >>am having issues with not working. Once i boot into Win7, install the ATI
> >>drivers, than reboot the DomU, and it just hangs at the "Starting Windows"
> >>black screen and never gets past it. I have read a bunch of things and will
> >>do more trial and error things, but for now just wondered about that
> >>"FLReset+" as stated on Wiki.
> >>
> >I don't have a windows 7 VM so I don't know if windows has a problem
> >with it. Are you using it as a primary or secondary video card?
> >Secondary seems easier to get to work.
> >
> SO i have heard, but I have been trying to get it to work using
> Secondary VGA Passthru. I tried Primary once and, for a lack of a
> better term, all hell broke loose during DomU boot as QEMU pretty
> much shut down....lol. Granted, i didn't try very hard and didn't
> apply any patched or anything, maybe some day if that feature is a
> bit more stable and there are actual guides on how to make it work,
> i will try again than.
> 
> It probably doesn't make any difference, BUT at the first set of
> trial and error, i had a GeForce 7600GS in PCIex16 Slot#1 so i have
> video in Dom0, than had my ATI FirePro V7900 in the PCIex16 Slot#2
> hidden to passthru. Now i am trying it with the ATI FirePro V7900 in
> the PCIex16 Slot#1 and an older PCI VGA card so i have video in
> Dom0.
> 
> I am using Xen 4.2 Rev25494, so almost the latest. For now i am only
> trying to get Win7 DomU to work, later on will move to Ubuntu. I do
> know that Windows has a lot of issues with FLR and not resetting the
> VGA card, just have to find the right steps to make it get over it.
> My USB3.0 works fine and no issues being passed thru, SO figured
> since that was the only PCI device that had "FLReset+", maybe that
> was making it work correctly as compared to VGA.
> 
> BUT, thanks for the reply and i will keep playing with it til i get
> something to work.
> 

Btw you probably want to try with xm/xend toolstack aswell.. 
just to verify if it's any different there.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Jun 30 15:42:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 15: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 1Skzo7-0002KM-Ba; Sat, 30 Jun 2012 15:41:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skzo6-0002KH-Lj
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 15:41:58 +0000
Received: from [85.158.143.99:6542] by server-3.bemta-4.messagelabs.com id
	70/D2-05808-54E1FEF4; Sat, 30 Jun 2012 15:41:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1341070917!22901886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDQwNDY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21621 invoked from network); 30 Jun 2012 15:41:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 15:41:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,502,1336348800"; d="scan'208";a="13305124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jun 2012 15:41:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 30 Jun 2012 16:41:57 +0100
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 1Skzo4-0000Ub-LA;
	Sat, 30 Jun 2012 15:41:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Skzo4-00074d-Af;
	Sat, 30 Jun 2012 16:41:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13413-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 30 Jun 2012 16:41:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13413: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13413 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13413/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13379
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13379
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail like 13379
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  like 13373

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7ef0b3122c0e
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
  Zhou Peng <ailvpeng25@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1067 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 Jun 30 15:42:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 15: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 1Skzo7-0002KM-Ba; Sat, 30 Jun 2012 15:41:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Skzo6-0002KH-Lj
	for xen-devel@lists.xensource.com; Sat, 30 Jun 2012 15:41:58 +0000
Received: from [85.158.143.99:6542] by server-3.bemta-4.messagelabs.com id
	70/D2-05808-54E1FEF4; Sat, 30 Jun 2012 15:41:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1341070917!22901886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDQwNDY=\n
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21621 invoked from network); 30 Jun 2012 15:41:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 15:41:57 -0000
X-IronPort-AV: E=Sophos;i="4.77,502,1336348800"; d="scan'208";a="13305124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jun 2012 15:41:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 30 Jun 2012 16:41:57 +0100
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 1Skzo4-0000Ub-LA;
	Sat, 30 Jun 2012 15:41:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Skzo4-00074d-Af;
	Sat, 30 Jun 2012 16:41:56 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13413-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 30 Jun 2012 16:41:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13413: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13413 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13413/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 13379
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 13379
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 13379
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 13379
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13379
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13379

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail like 13379
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  like 13373

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  7ef0b3122c0e
baseline version:
 xen                  4f92bdf3370c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dario Faggioli <raistlin@linux.it>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Roger Pau Monne <roger.pau@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yang Zhang <yang.z.zhang@Intel.com>
  Zhou Peng <ailvpeng25@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 1067 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 Jun 30 20:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 20:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sl4UJ-0006A5-Ne; Sat, 30 Jun 2012 20:41:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jackyzt98@gmail.com>) id 1Skz4M-0001bg-Ms
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 14:54:42 +0000
X-Env-Sender: jackyzt98@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1341068074!9230552!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2401 invoked from network); 30 Jun 2012 14:54:35 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 14:54:35 -0000
Received: by qcab12 with SMTP id b12so1509065qca.32
	for <xen-devel@lists.xen.org>; Sat, 30 Jun 2012 07:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=0YcigUnfZfdPWhcRjAh4/w52q9ic38elf0fm0dTzf24=;
	b=mNIMUolPQZTPZGGVh1dyOozI8N3/CYZ6wrKuPHuMgT/zQsd2Lr/reHt3qJ8WC7NUpC
	GBlYf9UsHIsdrBIsLATOqUX/kYNWAsAWznL7NASePrh+ERwpoLs16jAZjRDnR7tW7jC0
	SvgYrWfvck4sNtjWCrlE5U2NnJf/4w90B3NQhDEjMGE2lcANu63aienYxw0UWngHft4J
	kUu68zHH2jMn2rVlHYdW9J5NH2R+EimMQ8DpdW7NNqjFpT4XUYAO2J/oYgFO819iZKlp
	sOFWtgijqpKl0URzWtSEK8OIKdlv4+CeMXn8zUoxksErxRlmjt+bJbpm/ZMzsxQeFyd/
	S0Hw==
MIME-Version: 1.0
Received: by 10.224.86.194 with SMTP id t2mr11197505qal.95.1341068074339; Sat,
	30 Jun 2012 07:54:34 -0700 (PDT)
Received: by 10.229.184.84 with HTTP; Sat, 30 Jun 2012 07:54:34 -0700 (PDT)
Date: Sat, 30 Jun 2012 22:54:34 +0800
Message-ID: <CAMT9dFHSq=s04cm3Ad1c8ED1H89qw7ZGxM_WU2p8Tt3v4FpKzg@mail.gmail.com>
From: Zhou Jacky <jackyzt98@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Sat, 30 Jun 2012 20:41:50 +0000
Subject: [Xen-devel] XEN PV Linux performance
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0276380039697556843=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0276380039697556843==
Content-Type: multipart/alternative; boundary=20cf3074b93a30cc0204c3b1be87

--20cf3074b93a30cc0204c3b1be87
Content-Type: text/plain; charset=ISO-8859-1

I re-post this from Xen-User maillist.

I found that xen PV linux performance is very poor comparing with native
linux or HVMPV linux in some case such as system call (which will cause
context switch).
Here is a very simple sample:

double geTime() {
        struct timeval t;
        gettimeofday(&t, 0);
        return (double) t.tv_sec + (double) t.tv_usec / 1000000.0;
}

int geInc(int sum) {
       return sum+1;
}

int main() {
       for (i=0; i<; i++) {
     geTime();
}

In PV linux guest, It will be 10 times slower than PVHVM linux guest.
 While call getInc()  10000000 times, PV guest is a little faster then
HVMPV.
So it seems that PV linux guest has poor performance in context switch case.
How can I tune this or if there's any plan fixing this issue?
I'm looking forward to get your feedback. Thank you.

---------------------------------------------------------------------------
XEN 4.1.2 + Dom 0 kernel 3.2 + Ubuntu 12.04 guest,  Intel(R) Xeon(R) CPU
E5620

Jacky

--20cf3074b93a30cc0204c3b1be87
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-s=
ize:14px;background-color:rgb(255,255,255)">I re-post this from Xen-User ma=
illist.</span></div><div><span style=3D"color:rgb(34,34,34);font-family:ari=
al,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><br>
</span></div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-seri=
f;font-size:14px;background-color:rgb(255,255,255)">I found that xen PV lin=
ux performance is very poor comparing with native linux or HVMPV linux in s=
ome case such as system call (which will cause context switch).</span><div =
style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14px;ba=
ckground-color:rgb(255,255,255)">
Here is a very simple sample:</div><div style=3D"color:rgb(34,34,34);font-f=
amily:arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><b=
r></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font=
-size:14px;background-color:rgb(255,255,255)">
<div>double geTime()=A0{</div><div>=A0 =A0 =A0 =A0 struct timeval t;</div><=
div>=A0 =A0 =A0 =A0 gettimeofday(&amp;t, 0);</div><div>=A0 =A0 =A0 =A0 retu=
rn (double) t.tv_sec + (double) t.tv_usec / 1000000.0;</div><div>}</div></d=
iv><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size=
:14px;background-color:rgb(255,255,255)">
<br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;fo=
nt-size:14px;background-color:rgb(255,255,255)"><div>int geInc(int sum)=A0{=
</div><div>=A0 =A0 =A0 =A0return sum+1;</div><div>}</div></div><div style=
=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14px;backgro=
und-color:rgb(255,255,255)">
<div><br></div><div>int main() {</div><div>=A0 =A0 =A0 =A0for (i=3D0; i&lt;=
; i++) {</div><div><span style=3D"white-space:pre-wrap">	</span>=A0 =A0 =A0=
geTime();</div><div>}</div></div><div style=3D"color:rgb(34,34,34);font-fam=
ily:arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">
<br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;fo=
nt-size:14px;background-color:rgb(255,255,255)">In PV linux guest, It will =
be 10 times slower than PVHVM linux guest. =A0While call getInc() =A0100000=
00 times, PV guest is a little faster then HVMPV.</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14=
px;background-color:rgb(255,255,255)">So it seems that PV linux guest has p=
oor performance in context switch case.</div><div style=3D"color:rgb(34,34,=
34);font-family:arial,sans-serif;font-size:14px;background-color:rgb(255,25=
5,255)">
How can I tune this or if there&#39;s any plan fixing this issue?=A0</div><=
div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14p=
x;background-color:rgb(255,255,255)">I&#39;m looking forward to get your fe=
edback. Thank you.</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14=
px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:rgb(34,=
34,34);font-family:arial,sans-serif;font-size:14px;background-color:rgb(255=
,255,255)">
---------------------------------------------------------------------------=
</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-s=
ize:14px;background-color:rgb(255,255,255)">XEN 4.1.2 + Dom 0 kernel 3.2 + =
Ubuntu 12.04 guest, =A0Intel(R) Xeon(R) CPU E5620</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14=
px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:rgb(34,=
34,34);font-family:arial,sans-serif;font-size:14px;background-color:rgb(255=
,255,255)">
Jacky</div>

--20cf3074b93a30cc0204c3b1be87--


--===============0276380039697556843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0276380039697556843==--


From xen-devel-bounces@lists.xen.org Sat Jun 30 20:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 30 Jun 2012 20:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Sl4UJ-0006A5-Ne; Sat, 30 Jun 2012 20:41:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jackyzt98@gmail.com>) id 1Skz4M-0001bg-Ms
	for xen-devel@lists.xen.org; Sat, 30 Jun 2012 14:54:42 +0000
X-Env-Sender: jackyzt98@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1341068074!9230552!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2401 invoked from network); 30 Jun 2012 14:54:35 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jun 2012 14:54:35 -0000
Received: by qcab12 with SMTP id b12so1509065qca.32
	for <xen-devel@lists.xen.org>; Sat, 30 Jun 2012 07:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=0YcigUnfZfdPWhcRjAh4/w52q9ic38elf0fm0dTzf24=;
	b=mNIMUolPQZTPZGGVh1dyOozI8N3/CYZ6wrKuPHuMgT/zQsd2Lr/reHt3qJ8WC7NUpC
	GBlYf9UsHIsdrBIsLATOqUX/kYNWAsAWznL7NASePrh+ERwpoLs16jAZjRDnR7tW7jC0
	SvgYrWfvck4sNtjWCrlE5U2NnJf/4w90B3NQhDEjMGE2lcANu63aienYxw0UWngHft4J
	kUu68zHH2jMn2rVlHYdW9J5NH2R+EimMQ8DpdW7NNqjFpT4XUYAO2J/oYgFO819iZKlp
	sOFWtgijqpKl0URzWtSEK8OIKdlv4+CeMXn8zUoxksErxRlmjt+bJbpm/ZMzsxQeFyd/
	S0Hw==
MIME-Version: 1.0
Received: by 10.224.86.194 with SMTP id t2mr11197505qal.95.1341068074339; Sat,
	30 Jun 2012 07:54:34 -0700 (PDT)
Received: by 10.229.184.84 with HTTP; Sat, 30 Jun 2012 07:54:34 -0700 (PDT)
Date: Sat, 30 Jun 2012 22:54:34 +0800
Message-ID: <CAMT9dFHSq=s04cm3Ad1c8ED1H89qw7ZGxM_WU2p8Tt3v4FpKzg@mail.gmail.com>
From: Zhou Jacky <jackyzt98@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Sat, 30 Jun 2012 20:41:50 +0000
Subject: [Xen-devel] XEN PV Linux performance
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0276380039697556843=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0276380039697556843==
Content-Type: multipart/alternative; boundary=20cf3074b93a30cc0204c3b1be87

--20cf3074b93a30cc0204c3b1be87
Content-Type: text/plain; charset=ISO-8859-1

I re-post this from Xen-User maillist.

I found that xen PV linux performance is very poor comparing with native
linux or HVMPV linux in some case such as system call (which will cause
context switch).
Here is a very simple sample:

double geTime() {
        struct timeval t;
        gettimeofday(&t, 0);
        return (double) t.tv_sec + (double) t.tv_usec / 1000000.0;
}

int geInc(int sum) {
       return sum+1;
}

int main() {
       for (i=0; i<; i++) {
     geTime();
}

In PV linux guest, It will be 10 times slower than PVHVM linux guest.
 While call getInc()  10000000 times, PV guest is a little faster then
HVMPV.
So it seems that PV linux guest has poor performance in context switch case.
How can I tune this or if there's any plan fixing this issue?
I'm looking forward to get your feedback. Thank you.

---------------------------------------------------------------------------
XEN 4.1.2 + Dom 0 kernel 3.2 + Ubuntu 12.04 guest,  Intel(R) Xeon(R) CPU
E5620

Jacky

--20cf3074b93a30cc0204c3b1be87
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-s=
ize:14px;background-color:rgb(255,255,255)">I re-post this from Xen-User ma=
illist.</span></div><div><span style=3D"color:rgb(34,34,34);font-family:ari=
al,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><br>
</span></div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-seri=
f;font-size:14px;background-color:rgb(255,255,255)">I found that xen PV lin=
ux performance is very poor comparing with native linux or HVMPV linux in s=
ome case such as system call (which will cause context switch).</span><div =
style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14px;ba=
ckground-color:rgb(255,255,255)">
Here is a very simple sample:</div><div style=3D"color:rgb(34,34,34);font-f=
amily:arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><b=
r></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font=
-size:14px;background-color:rgb(255,255,255)">
<div>double geTime()=A0{</div><div>=A0 =A0 =A0 =A0 struct timeval t;</div><=
div>=A0 =A0 =A0 =A0 gettimeofday(&amp;t, 0);</div><div>=A0 =A0 =A0 =A0 retu=
rn (double) t.tv_sec + (double) t.tv_usec / 1000000.0;</div><div>}</div></d=
iv><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size=
:14px;background-color:rgb(255,255,255)">
<br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;fo=
nt-size:14px;background-color:rgb(255,255,255)"><div>int geInc(int sum)=A0{=
</div><div>=A0 =A0 =A0 =A0return sum+1;</div><div>}</div></div><div style=
=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14px;backgro=
und-color:rgb(255,255,255)">
<div><br></div><div>int main() {</div><div>=A0 =A0 =A0 =A0for (i=3D0; i&lt;=
; i++) {</div><div><span style=3D"white-space:pre-wrap">	</span>=A0 =A0 =A0=
geTime();</div><div>}</div></div><div style=3D"color:rgb(34,34,34);font-fam=
ily:arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">
<br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;fo=
nt-size:14px;background-color:rgb(255,255,255)">In PV linux guest, It will =
be 10 times slower than PVHVM linux guest. =A0While call getInc() =A0100000=
00 times, PV guest is a little faster then HVMPV.</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14=
px;background-color:rgb(255,255,255)">So it seems that PV linux guest has p=
oor performance in context switch case.</div><div style=3D"color:rgb(34,34,=
34);font-family:arial,sans-serif;font-size:14px;background-color:rgb(255,25=
5,255)">
How can I tune this or if there&#39;s any plan fixing this issue?=A0</div><=
div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14p=
x;background-color:rgb(255,255,255)">I&#39;m looking forward to get your fe=
edback. Thank you.</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14=
px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:rgb(34,=
34,34);font-family:arial,sans-serif;font-size:14px;background-color:rgb(255=
,255,255)">
---------------------------------------------------------------------------=
</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-s=
ize:14px;background-color:rgb(255,255,255)">XEN 4.1.2 + Dom 0 kernel 3.2 + =
Ubuntu 12.04 guest, =A0Intel(R) Xeon(R) CPU E5620</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:14=
px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:rgb(34,=
34,34);font-family:arial,sans-serif;font-size:14px;background-color:rgb(255=
,255,255)">
Jacky</div>

--20cf3074b93a30cc0204c3b1be87--


--===============0276380039697556843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0276380039697556843==--